Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
A New Smart Contract Design Pattern:
ETHEREUM + IPFS + JVM = Offline SCs
CONCEPT ONLY
Mano Thanabalan
Head of Development
...
2
Agenda
I. Introduction
II. Why a new Design Pattern?
III. The Design Pattern
IV. Key Design Considerations
V. The Build
...
3
I. Introduction
Who am I?
● Head of Development at Otonomos BCC based in Singapore
● Full Stack Developer specializing i...
4
II. Why a new Design Pattern?
● To explore the possibilities of ‘Offline’ Smart Contracts
● To create a Language Agnosti...
5
III. The Design Pattern
Step 1: Deploy Offline SC Protocol
a. Stakeholders and Voting Mechanism
b. Logic for adding and ...
6
IV. Key Design Considerations
● When a new ‘Offline’ Smart Contract Instance its class file should be
immutable and all ...
7
V. The Build
● The ‘Offline’ Smart Contract Protocol
● Github
● The Verification Node Application
● Design a ‘main’ appl...
8
VI. The Challenges
● Ensuring an incorruptible verification model
➔ Nodes must not be able to ‘falsely’ verify a bad tra...
Upcoming SlideShare
Loading in …5
×

A New Smart contract Design Pattern : Concept Proposal for an Ethereum, IPFS and JVM powered dApp - Mano Thanabalan, Otonomos

1,387 views

Published on

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.

Mano Thanabalan, Otonomos

Published in: Technology

A New Smart contract Design Pattern : Concept Proposal for an Ethereum, IPFS and JVM powered dApp - Mano Thanabalan, Otonomos

  1. 1. A New Smart Contract Design Pattern: ETHEREUM + IPFS + JVM = Offline SCs CONCEPT ONLY Mano Thanabalan Head of Development Otonomos BCC Singapore
  2. 2. 2 Agenda I. Introduction II. Why a new Design Pattern? III. The Design Pattern IV. Key Design Considerations V. The Build VI. The Challenges VII. Q&A
  3. 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
  4. 4. 4 II. Why a new Design Pattern? ● To explore the possibilities of ‘Offline’ Smart Contracts ● To create a Language Agnostic Smart Contract Protocol ● To address Ethereum Smart Contract design challenges ➔ Size and Scale Limitations of Smart Contracts, i.e. gaslimit ➔ Limited feature set of Solidity vs more mature high-level languages ➔ Virtual Machine – EVM versus JVM ● To explore the mechanics of ‘offline’ Smart Contracts and its application in new use cases and applications ➔ EtherOpt - Offline Crypto Options Order Book ➔ Otonomos - Offline Company Smart Contracts ➔ Blockchain Powered AI
  5. 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. 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.
  7. 7. 7 V. The Build ● The ‘Offline’ Smart Contract Protocol ● Github ● The Verification Node Application ● Design a ‘main’ application to run the Java Class ● Design a Standard Smart Contract Interface ● Design Authentication and Verification Logic ● Design Spam and Malicious code control logic ● The ‘Offline’ Smart Contract Design Guidelines ● Set of best practices to ensure deployable Smart Contracts.
  8. 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.

×