Technical implementation of smart contracts in Dynamo Cryptocurrency

Introduction

This article will detail the mechanism used to create and execute smart contacts in Dynamo. Dynamo is a unique cryptocurrency implementation based on BTC fork, using a hybrid UTXO/account design. The primary design goals were ease of implementation, minimal security impact and ease of use. This was achieved by leveraging OP_RETURN data to secure contracts in the main blockchain.

Contract creation

Contracts are created by issuing an OP_RETURN command with a special preamble. This signature signals the full node that the transaction will create a contract. The transactions are submitted via the RPC interface like any other transactions and are stored, and relayed, in the mempool, until mined.

The mining software hashes the OP_RETURN transaction like any other transaction and returns a mined block to the full node for validation. Other than increasing the OP_RETURN relay size, no other changes to consensus or mining were required to implement up to this point.

The mining software returns the assembled block to the full node for acceptance. The full node recognizes the contract signature, validates the contract, stores the newly created contract in a local database and cache memory and then relays the block as normal. Any incoming relayed block will likewise be validated and stored. The contract address is deterministically calculated from the sender address and block hash, so each full node will assign the same address.

Any outputs which are sent to an OP_RETURN transaction are provably un-spendable and dropped from the mempool. The funds, if any, which are sent in the contract creation command are loaded into the internal contract balance. Sufficient funds must accompany the transaction to mine the contract.

Contract execution

Once a contract has been mined into the blockchain it can be executed. It is executed by sending outputs to the contract address. The execution command contains the name of the function to run and may optionally contain additional data which is exposed internally to the contract when it executes. The execution command contains a special signature OP_RETURN. Again, all funds are provably un-spendable and are therefore loaded into the contract balance (less mining and execution fees).

The execution command is loaded to the mempool where a miner will eventually retrieve it for execution.

The mining software recognizes the execution signature and runs the contract in a sandboxed VM. The RPC for getblocktemplate includes all necessary data to execute any contracts which are being called — contract code, current state and persistent data.

If the contract sends funds to any address, those UTXO are created as part of the coinbase transaction and the amount is subtracted from the contract balance.

Once the miner has completed a block, including all contract executions, the block is submitted to the full node.

The full node then executes all contracts stored in the block and verifies the state updates and coinbase transactions. If validation passes, the block is added to the chain and relayed to peer nodes. Those full nodes then perform the same validation of executing all contracts, etc.

State and persistent storage

Contracts have state and associated persistent storage.

Contract state consists of the current contract balance and the number of times the contract has been executed. The execution count is included in order to ensure that hash values update for each execution even if the balance does not change. Contract state is stored as an OP_RETURN UTXO data element with a value of 0 in the coinbase transaction of any block which contains contract executions.

Contract persistent storage is similarly created in the coinbase transaction, however only delta state is stored due to the potentially large amount of data.

The full node uses these empty UTXO coinbase transactions to verify correct execution (e.g. that it comes up with the same results as the miner). Once verified these transactions are relayed in the block to other full nodes which perform the same verification. These transactions also serve as a full audit trail of every action taken on the contract and are permanently secured in the blockchain.

The block size limit has been increased to 10mb to accommodate the anticipated additional data and the consensus time has been reduced to 15 seconds to improve throughput and limit the number of transactions per block.

Conclusion

I have presented a work-in-progress implementation of a fully UTXO based smart contract execution environment which makes minimal changes to BTC core and secures all contract execution and data using native BTC consensus mechanisms.

The reference implementation of the full node and mining software is available on github which can be found on the Dynamo foundation website https://dynamocoin.org