Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

The Solidity programming language was built to address the non-deterministic way in which traditional languages such as Java compile into byte or machine specific code. The need for deterministic compilation to assembly language stems from deterministically calculating the running cost of a given Smart Contract. However, if the code, compiled byte code and variable state storage could be stored in a file in IPFS after being run and verified in a JVM, then deterministic compilation would no longer be a relevant requirement. Besides the obvious reduction in gas consumption, this design will also circumvent the Smart Contract gas limit and more complex smart contracts could be deployed.

3.
3
I. Introduction
Who am I?
● Head of Development at Otonomos BCC based in Singapore
● Full Stack Developer specializing in Blockchain and Smart Contract Applications
What is Otonomos?
● Otonomos is in the business of converting the specific section of Corporate Law
pertaining to company incorporations into self-enforcing Smart Contracts.
● We have designed and deployed our own Identity/KYC Protocol including Key
Recovery best practices.
● We have also designed a suite of Smart Contracts specifically tackling Corporate
Governance, Asset Management and optimization of real world management practices
by way of Smart Contractification

5.
5
III. The Design Pattern
Step 1: Deploy Offline SC Protocol
a. Stakeholders and Voting Mechanism
b. Logic for adding and removing stakeholders.
Step 2: Submit new ‘offline’ Txns
a. New ‘offline’ Smart Contract
b. State Change Txn on existing instance of ‘offline’
Smart Contract
Step 3: Verification Nodes
a. Listen for new Txns
b. Run State Change Function on JVM
c. Local verification of resultant state against state file.
d. If local verification passes, node will invoke verify
function on Offline SC Protocol
Step 4: Set Txn to Final
a. Once consensus is reached (Actual Votes > Required
Votes), Txn is set to final state.
b. No new txns are allowed until pending txn for a given
instance of a contract is set to final.

6.
6
IV. Key Design Considerations
● When a new ‘Offline’ Smart Contract Instance its class file should be
immutable and all future ‘valid’ txns should reference it.
● A new txn should not be allowed if there is an existing pending txn for a given
Smart Contract Instance.
● A pending txn should NOT forever block new txns.

8.
8
VI. The Challenges
● Ensuring an incorruptible verification model
➔ Nodes must not be able to ‘falsely’ verify a bad transaction
● Preventing malicious ‘offline’ smart contracts
➔ For a start ‘Offline’ Smart Contracts will run within a predefined ‘main’
application that would restrict the scope of the Offline Smart Contract
• Scalability of the Protocol
➔ Whilst the ‘Offline’ Smart Contract could theoretically be large, what
happens when a high volume of large state change txns are submitted.