A New Smart Contract Design Pattern:

ETHEREUM + IPFS + JVM = Offline SCs

CONCEPT ONLY

Mano Thanabalan
Head of Development
Otonomos BCC Singapore
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

2
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

3
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

4
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.

5
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.

6
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.

7
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.