Blockchain Design Patterns and Tactics

Design Patterns for Blockchain Applications

Off-chain patterns

In both settings, the questions of on-chaining versus off-chaining is recurring: What exactly has to be on the chain and what can be off the chain, while retaining the overall properties and benefits associated with blockchains? ¹

Three challenges: ¹

1. We need to find a way to store data off the chain without giving up its manipulation-resistance.
2. As all on-chain data is publicly visible, techniques for trustless but privacy-preserving off-chain storage should be developed
3. Off-chain computations on private data which can be verified on-chain without revealing said data would augment the set of possible use cases

Challenge Response Pattern

Context: In some cases, state transitions are cheap to compute, but checking whether a given state is a final state is expensive. ¹

Solution:

• The state check is performed off-chain on the client side
• A client can notify a smart contract when a final state has been reached
• Other clients can prove claims wrong by providing a valid state rtansition
• The computation never has to be performed on-chain

Example:

The end game condition for chess is too expensive to check on-chain. The players, however, can easily check the condition off-chain.

Hence, instead of checking the end game condition in a smart contract, a player simply claims check mate. If the claim was false, his opponent can simply prove him wrong by submitting a valid move.

If the claim was true and the opponent cannot submit a valid move, the winner is paid out.

Off-chain signatures pattern

Context: two network participants know that they will perform a set of transactions in the future. They wan to reduce the cost of these transactions or want to hide them from other network participants. ¹

Solution:

• Two participants together specify a smart contract including a function, which applies an external state given as argument to the contract state. This function includes a signature check to ensure that both participants agree with the state change.
• Both parties can make deposits to the contract.
• Then participants perform transactions purely off-chain and peer-to-peer, without involving the blockchain:
  • One participant computes a new state, wraps it in a transaction, signs it, and sends it to his counterpart.
  • The recipient checks teh new state, signs the transaction as well in case he agrees and sends it back to the sender
• The transaction, signed by both parties, can be sent to the smart contract at any point in time.

Implementation:

• This pattern requires an off-chain peer-to-peer communication channel to exchange off-chain transactions.
• In the Ethereum ecosystem, the Whisper Messaging Protocol can be used for this purpose.
• Lightning and Raiden networks are implementation of this pattern as payment networks.

Content-addressable storage

Context: a large amount of data is associated with a smart contract, but storing data on-chain is too expensive. ¹

Solution:

• Store data off-chain in a content-addressible storage system
• Store the reference in the smart contract
• Clients use the smart contract to retrieve the reference and retrieve the data

Implementation:

• IPFS and Swarm

Delegated Computation Pattern

Context: ¹

• A node participating in a blockchain network wants to prove a property of its private data without publishing it (e.g., proving it has the right user ID or access cookies, without revealing that cookie)
• A node wants to perform a computation that is too complex to be executed on-chain

Solution:

• Outsource computation to an untrusted third party
• Generate a proof of correct execution along with the result.
• Instead of executing the computation itself, the verification of the proof-of-correct execution can happen on-chain
• Non-interactive zero-knowledge proofs, such as zero-knowledge Succinct Non-interactive ARgument of Knowledge (zkSNARKSs) can be used to hide the information from the untrusted third party as well.

Low contract footprint pattern

Context: the transaction fee depends on the complexity of the contract function as well as its use of storage. ¹

Solution:

• Do not check conditions on-chain after a state change
• Optimize for writes, not reads. Reading from a smart contract is a local off-chain operation and does not require an on-chain transaction. Minimize writes and store inforamtion free of redundancy.