Zen’s contract lifecycle
Public blockchains trade massive redundancy for robust consensus on transaction history and ownership. But this redundancy makes it expensive to put data on a blockchain and to do computation there. Zen supports smart contracts — code running on a blockchain — and to make Zen a secure platform, miners have to be compensated, both for storing those contracts and for running their code.
Of course, Zen isn’t the only smart contract-capable platform. The first decentralized smart contract platform was… Bitcoin! In Bitcoin, you can write a script to say the conditions for spending some coins. Chained transactions can implement quite complex contracts — although there’s a limit.
The relevant property of Bitcoin for this post is that Bitcoin contracts are single-use. Every script locks exactly one output — to use the same contract again, you have to put the script into Bitcoin’s blockchain again. Schnorr signatures, which let one signature unlock multiple outputs, are in a way a step towards more efficient Bitcoin smart contracts. Single-use contracts may be inefficient in some cases, but they mean that every use of the contract is paid for: miners compete to mine blocks that run the contract and collect its fee, after which the other miners no longer need to store the contract in RAM.
Ethereum contracts are at the opposite extreme — currently, you can create a contract, put it into the Ethereum blockchain, and then use it forever. While very pleasant for the contract creator, this puts the burden on all miners to store the contract — all contracts — in memory indefinitely, in order to remain competitive. Those miners don’t get paid for storing the contract — only the miner who first puts it into the blockchain gets any compensation
Zen contracts are pay-per-block. That means that the contract creator pays to put a contract into the Zen blockchain, where it stays until the payment runs out. The contract then deactivates, and neither miners nor users need to remember its code. If anyone wants to use the contract again, they can pay to reactivate it — and it will reappear in the blockchain completely unchanged, as if it never deactivated.
Who receives the payment for activating a contract? Unlike either Bitcoin or Ethereum, the payment, called the contract sacrifice, is given to all miners who find a block while the contract is active, compensating them for the cost of storing it in RAM. On the other hand, most of the cost of running the contract applies only when the contract runs. Just as in Bitcoin, miners choose whether or not to include the transaction which represents running the contract, so all the transaction fee for running a contract goes to the miner who includes the transaction. Of course, the contract can be run any number of times while it remains active.
There’s no need to think too hard about how long to activate a contract for — anyone can extend any active contract, without paying excessive fees. Extending is efficient because the nodes are already storing the contract in memory: no need to repeat its code.
Zen makes a clear distinction between transaction fees and contract sacrifices. Why? Well, miners can see the transaction fee before deciding to include a transaction — they have the choice to turn down a fee that they don’t want. For this reason, Zen transaction fees can be set to any amount (like Bitcoin) and paid in any type of asset or assets (er, not like Bitcoin). Contract sacrifices are paid to miners in the future. What do those miners want? We can’t ask them — we don’t even know who they are going to be. The solution is to require contract sacrifices be of the one asset which motivates all miners — the Zen protocol’s native scarce token. This makes activating contracts the principal use of the Zen native token.
For miners and fully-validating nodes, this is all there is to the Zen contract lifecycle. Contracts activate with a contract sacrifice, entering the active contract set. They stay active while the sacrifice pays out to miners, maybe getting an extension with a new contract sacrifice. Then, when the sacrifice runs out, they leave the active contract set, and can be forgotten until reactivated.
What about light clients? Keeping the entire blockchain on a mobile phone is impractical. Bitcoin has SPV. While not entirely reliable, this gives decent security guarantees by letting full nodes prove Bitcoin transactions exist in blocks with a certain amount of proof-of-work built on top of them. Ethereum attempts something similar, going so far as allowing proofs that contracts exist using a data structure called a Patricia tree. Patricia trees are efficient for full nodes to update, which is important given that most of the data — the contracts — remain the same in each block.
Zen enables lightweight validation with a recently invented data structure called an efficient sparse merkle tree. ESMTs are like Patricia trees in that they have fast updates and enable proofs that data is present. Unlike Patricia trees, they have a simple description — they’re not really that different to Bitcoin’s binary merkle trees — and they support efficient proofs that data isn’t present. That means a light client can request and receive immediate proof that a contract isn’t active anymore, excluding a whole class of attacks.
Zen’s pay-per-block contracts, and efficient light client support, make it possible for all users of the Zen protocol, whether miners, businesses, or individuals, to transact securely, without any participant unfairly bearing the cost. Beyond these basic requirements for a financial blockchain, the Zen protocol design enables new, more private ways to use smart contracts, such as having a contract act as a guarantor without even being seen on-chain unless a dispute arises. We look forward to discussing these contract design-patterns in a forthcoming post.