Ethereum Workshop and LunchBadger

We’re pleased to announce the first public hands on test drive of LunchBadger. We’re powering one of the ethereum workshop meetup events in Los Angeles this Thursday, January 26. If you’re in the area – please check it out!

At the workshop, James Young, CTO of VidRoll (one of the key founding members of adChain) will be covering the concept of going “off-chain” and presenting important practical patterns to make decentralize application (dapp) development easier.

Off-Chain Re-cap

If you hadn’t tuned in previously, please check out the first part of this series introducing the concept of going “off-chain” and why it’s an important concept for developing dapps on top of Ethereum. We also covered how LunchBadger is making off-chain development easier for Ethereum. In this part, we’re going cover the best practice pattern for developing “off-chain”.

The Verification Pattern

Going “off-chain” means replicating part of the same key concepts that Ethereum provides: trustless and auditable transacting across two or more parties for practically any given use case.

With LunchBadger, we have an easy way to develop dapps and dynamically inject the smart contract into Ethereum. The trick now is to replicate a minimal portion of logic to ensure that we can transact “off-chain” while preserving the above stated key concepts. Doing so, gives us the creative freedom to address any use case without the limitations of throughput that you would encounter if you were to try to run the entire of the dapp in the smart contract itself – not to mention the cost!

The verification pattern consists of a couple key entities and processes:

Observer

Hash Generation and Verification

Memorialization

Reconciliation

Observer

The observer is exactly what you’re guessing – an observer to the interaction between participants. The observer also as acts as a sort of official notary and escrow to initiate and close the interaction between the transacting parties.

Physically, the observer is embodied in a set of logic that accompanies the dapp that you are developing. In the workshop, the observer is bundled in the tic-tac-toe project, but it’s run as a separate entity. The observer can potentially be separate from the tic-tac-toe game itself and even re-used for other interactions other than tic-tac-toe. Think of a “game” referee observer that anyone can access and run through an IPFS address.

Hash Generation and Verification

Transacting among participants means acknowledging the previous transaction and leaving an auditable trail for one’s own transaction. A simple way to do this is to take one’s identity and transaction and generating a hash with subsequent transactions hashing the previous transaction’s hash to form a “chain”, akin to the way blockchains chain previous hashes starting from a the “chain” in blockchain. The chain of hashes is verified by the observer to make sure that each participant acknowledges the previous transaction, performs their own operation and creates the hash for their own transaction.

Memorialization

The “enforcement” of trust and honesty off-chain begins with recording the details of the transaction that are about to be processed within the official Ethereum instance. All relevant information that pertains to the “contract” part of the smart contract are initialized “on-chain” by the observer, including: the identities of those participating, a reference to the agreed upon code that will be run off-chain, the amount of ether associated with each participant and the Solidity code of the smart contract itself. We call this initialization process – memorialization. Effectively, it tells the world at large publicly that there is a record of an interaction that is about to take place off-chain and here are the pertinent details on who’s involved, what’s running off-chain and the final outcome that is expected to be recorded after the interaction has been completed off-chain.

Reconciliation

The enforcement of trust and honesty off-chain ends with the final execution of the smart contract to transact the final outcome to all involved parties pending the result of the interaction off-chain. The observer invokes the final reconciliation method to execute the final outcome and close the smart contract. If there is some form of dispute that had arisen during the off-chain process, the details of that are also recorded in case the final outcome will need to be reversed in the future. Reconciliation ensures that the agreed upon terms are executed and are publicly recorded for full auditability.

Tic-Tac-Toe: The Workshop Example

The verification pattern has many components. James and the LunchBadger team have put together a reference implementation of this pattern to illustrate processing interactions off-chain but memorializing and reconciling them on-chain.

We’ve done this with a simple game of tic-tac-toe. We all know how to play tic-tac-toe and what the rules are. In the workshop, we’re going to have groups of three – 2 players and 1 observer.

Two players register with the tic-tac-toe game. The observer acts as a kind of referee to make sure the rules of the game are followed and acts as a public witness.

It’s worth mentioning that there is still a cost to process “off-chain”. Under a more realistic scenario, the players would ante in ether to participate in the game. The ether anted would cover the cost for the observer’s services, the cost to run only what’s necessary on-chain, and reward the winner. The monetary cost has been overridden for the purposes of the workshop example.

Here’s a diagram to show the different components of the verification pattern for the flow of the tic-tac-toe interaction being executed with its off-chain and on-chain pieces.

Tic-Tac-Toe Flow

(1) The tic-tac-toe game’s logic is embodied in the Game model in LunchBadger as well as the JS based client code. The game starts up and serves static assets for tic-tac-toe game to the browser and an microservice based API starts running.

(2) The observer logic is run as part of the Game model and the entire backend of the game is called observer microservice.

(3) The observer injects the tic-tac-toe Solidity contract into Ethereum testrpc and the contracts’ methods are exposed by LunchBadger dynamically to be used by the observer and called as a REST API when necessary. The Solidity contract contains only the contractual obligations for running tic-tac-toe.

(4) Two players using Chrome with Metamask installed load the tic-tac-toe game client portion in their browser and their address hashes are registered within the tic-tac-toe game. Once two players are registered, the observer memorializes the start of the game in Ethereum on-chain.

(5) Each player generates a set of transactions with their corresponding hashes. The chain of hashes is conveniently kept within LunchBadger’s memory db.

(6) The observer verifies this chain of hashes to make sure that each move from each player is acknowledged and authenticated.

(7) Once the game concludes with either a victor or a dispute, the outcome of the game is recorded through the reconciliation process by executing the final instructions in the Solidity contract. In the event of a winner, the reconciliation process could entail recording who won, how much they won, credit the observer for its surfaces, and finally crediting the winner.

Subscribe to our Newsletter

Sign up for our private beta – your feedback helps prioritize our roadmap with the most value realized within the shortest amount of time

Learn about the inaugural feature set we’re striving for to make APIs repeatedly fast, easy and manageable as you evolve through the API lifecycle itself.

Sign up for the latest development on APIs and microservices.

Next Post