I originally envisaged the below concepts as a Nano-like network with contracts called "Norc" (portmanteau of Nano Oracle) which would have its own coin while retaining ORV and Block Lattice. Its representatives would have also been running as Nano Nodes to read from Nano's Block Lattice and use that to make decisions. I'll continue to refer to these ideas jointly as Norc, but I now believe these ideas function better as a part of Nano's own protocol.
Agreement on global order of transactions is vital to contracts. The Time Chain is a unique blockchain designed for this purpose. Its "private key" is public, so anyone can attempt to write to it. Representatives will have an internal stopwatch. Let's say we want a block written roughly every minute. At time T, each representative resets their internal stopwatch. Reps regularly check their stopwatch. When time T + 1 minute passes, a rep writes a block to the Time Chain containing an integer value of T + 1. This block is voted on like any other, except other reps will reject it unless they agree T + 1 has passed. To avoid forks, block identifiers are incremental so T + 1 is guaranteed to be identical to T + 1 if it's produced in a valid manner. Once a T + 1 block is confirmed locally, the rep accepts T + 1 to be the new time, and they reset their stopwatch to repeat the process for T + 2.
The block lattice prohibits the writing of transactions to individuals' private accounts. Enter the Vault: a conditionally writable data structure. Vaults act as accounts where funds stay for a duration. To facilitate conditional transactions, we need the concepts of Locking and Unlocking funds based on Time and Events, and the act of Unlocking must allow sending to an address defined within a contract. Consensus allows Unlock blocks (sends) from a Vault only when the prior Lock block (receive) has its contractual conditions met.
Every contract requires its own Vault. A Vault consists of a chain of every Time block up to some time ahead in the future. Any number of Lock blocks can be attached to the Time blocks. Some Lock blocks may require another Lock block when a counterparty is needed (e.g. trades or mixing). Some Contracts may allow Event blocks to be attached to a Lock block with the purpose of recording relevant state prior to its parent Time block. This allows, for example, to record a Nano transaction that the Lock block contractually required. Lock and Event blocks must be written before consensus reaches the Time block. Unlock blocks may be appended to the Lock/Event block as long as the conditions set by the Lock block and Contract are met.
With separate Vaults for each contract, a vulnerability in one contract won't affect the others. With Time blocks in the Vault, it's easy to reason about and limit the scope of what's relevant to Users and Nodes.
And thus, we essentially have Nano upgraded to incorporate Contracts with only a few basic new concepts: a Time chain and Time blocks, Vaults with Lock, Unlock, and Event blocks, and a set of pre-defined Contracts integrated into the protocol.
Thinking about attacks:
- Securing Lock blocks: Lock blocks should be created only by the Sender. So the Lock block's hash must utilize multisig of the Contract and the Sender
Examples of possible contracts:
Possible contracts if token support is added:
The Vault requires a new data structure
The Vault may need some unique storage optimization for consensus and pruned nodes
When there are counter-party Lock blocks, competition to become a counter-party may lead to expensive fork resolution
Determining how to add/update/end contracts in a decentralized manner