August 8, 2019
This technical design and architecture for contracts on Plasma is the product of the Plasma community conducting research on enforcement of contracts between ledgers, with the technical goal being inter-chain trust minimization (with speed/data/fullnode-validation trade-offs). This document does not assert any endorsement of any particular project or effort. However, implementation efforts in Plasma Cash have been helpful in creating sufficient understanding in producing this (with sufficient peer-review, conceptually complete, but further optimizable) design and architecture for Plasma.
Let's presume thousands of participants want to participate in a contract. The contract takes in input from thousands of participants spread over an hour, with external value bonded (e.g. the Plasma chain interacting with ETH). The bonded value has conditional payments set contingent upon the output state. All inputs and bonds are fed into the contract and compact settlement data is published. The participant then take that settlement data, apply it to their bonded outputs, then funds flow between the participants.
While Plasma currently allows for synchronization and net-settlement of inter-chain payments with many participants, there are currently two issues to be resolved to make inter-chainstate contracts useful with minimized trust in the Plasma chain:
If one wants to do OTC transactions in an inter-chainstate interaction, one can use a cross-chain atomic swap (and can be made inside a Lightning channel). However, channels and atomic swaps cannot inherently compute contracts on many parties in an enforceable manner, e.g. hundreds of participants which could disconnect and go offline at any time within a single state machine.
For state channels, all participants (usually two-party) are presumed to be live (online) at all times. This assures that all participants have data as they only sign off on subsequent states if and only if all necessary enforcement data is given to the other participant. This is a relatively straightforward situation compared to many-party interactions as the state only moves forward with the agreement of all parties. If one took this approach for 100 participants, this would mean that all parties would need to sign off on the new state before the contract moves forward. This lacks viability as if even one out of the hundred participants fails or refuses to sign off on the state, then the entire system halts.
This construction optimizes for minimal state and computation for the underlying asset with increased throughput requirements for the Plasma chain, with higher liveness assumptions.
Plasma is an inter-chain enforcement construction. As a design principle, there are different levels of trust minimization of inter-blockchain state (some may be used in combination or complimentary):
These possibilities are not exclusive, they may be a chain which operates under Sidechain assumptions for certain types of problems, and others which are enforceable Plasma contract state transitions. For example, many can delegate computation to a federated peg sidechain to compute on funds which have "no owner", in reality, as with all sidechains the federation has authority to control the state transition. In other words, one could exclusively do Plasma Payments where users delegate funds directly to the federation/validators during computational state transitions and after computation the funds are transferred back to users -- only the state before and after computation is enforceable. This document specifies moving from that construction from Plasma Payments to one where the global state transition itself is enforced.
There is another design consideration not listed in the three examples above, which is interactive computation of cross-chain state (Truebit), as well as computational proofs of cross-chain state (ZK-SNARKS/STARKS). This is presumed to be orthogonal to the problem of cross-chain state as the principal problems are around data unavailability risks (and possibly large datasets for availability proofs) for this particular problem.
The Plasma Contracts construction also presumes an underwriter ("Settlement Agent") as in prior efforts around providing capital (e.g. "Plasma Debit" constructions), but does not require the entity to be the same as the chain operators, nor does it require persistent capital lockup by a single operator, the capital is only locked up during the commitment/computation process itself and can have many ephemeral participants.
The key aspect of this design for netting high-volume many-to-many transactions which require globally synchronized computation in Plasma is that by binding conditional statements which are locally enforced, global enforcement can be inferred if a third party/parties are willing to provide a backstop on the computation. In other words, if a transaction sets a condition, then in order for all conditions to resolve correctly, then any inaccurate computation on the global state results in a loss for the participant(s) signing off on the state. Therefore if a set of participants provide a backstop on the computation by providing fully-collateralized settlement, then it would be the Settlement Agents which lose as a result of improper computation. The Settlement Agent therefore underwrites the state transition and only does so after fully validating the state transition themselves.
One is able to transact between many participants and share a global state transition without significant computational complexity in enforcement on the root chain by having third parties underwrite the state transition after it has occurred (we call these participants "Settlement Agents"). The Settlement Agents are not similar to traditional clearing houses or entities, as they are trust minimized -- traditional roles of being entrusted with correct settlement is not inherent to this construction.
Individual actors are only willing to continue transacting on the Plasma chain if they can have full data availability of the Plasma chain. If there is halting or data unavailability of any part of the chain state, it is presumed that all participants will exit and not continue transacting. UTXOs are spendable according to the current valid state and all state transitions are chains of valid conditional spends/circuits from an output. All UTXOs are presumed to be a specific indivisible denomination.
When a user submits a transaction on the Plasma chain to participate in a contract with many participants, they encode in the transaction rules on acceptance of the state transition. For example, if a contract exchange 1 ABC for at least 1 XYZ upon some triggered condition, the globally published batch exchange rate after computation of committed bids must be at least 1:1. For the individual user, their condition has been met, so they don't actually care whether any other participant has correct execution! Every user has these conditions attached, and thereby the transaction transitions can become globally enforceable. These conditions, as well as all possible dispute circuits/codepaths, are encoded and committed to the output itself. Imagine thousands of conditions, each condition is a restriction on the possible collective end-state. This restriction binds the Settlement Agent to deliver on that end state if they agree that it is correct, therefore a Settlement Agent will only sign if they receive at least an equal amount, and the only way to guarantee this is by only signing if the specific correct state transition has occurred.
These problems described above are two classes of interrelated problems which must be solved (data availability and global enforcement of state transitions). For the user, the data availability problem is that if one was exchanging 1 ABC for 1 XYZ, then one does not know which XYZ they will receive or whether they are even receiving a valid XYZ output. If the computation of the globally published data is invalid (e.g. the exchange rate isn't the correct cross price), then some people may be owed more XYZ than can be delivered.
These two problems may be resolved via non-custodial Settlement Agents by requiring them to use their capital to attest on correct execution to achieve summing/netting.
An overview of the flow:
While the image below may look complex, the root chain only needs to use the content in green, all other aspects are effectively node/client-side only and they continue participating only if the execution is correct.
The result is that the Settlement Agents are minimizing computational risk, as they are explicitly signing off on the computation in step 6 (and possibly 7).
As much of the computation is deferred to user validation and the Settlement Agent, the root chain contract/script only needs to primarily deal with interaction of root state commitments, Confirm/Revoke User UTXO Tx, (post-trade) Confirm On-chain Funds Commitments Txes, Finalize Settlement commitment / SA Commit Bitfield Txes, and Confirm Force Revoke UTXO Tx. All other output paths are inherent to the Plasma chain itself and do not need to be analyzed by the root chain. The watcher of any disputes can provide any sufficient and necessary data as each of those transactions have committed to the state at time of transaction creation. All transaction data must be committed to the state when creating the transaction to assist in this activity. In the event the committed state is invalid, the Plasma validators must not include it in the block. Similarly, if the users and validators have inserted invalid data into the block, the Settlement Agents will refuse to underwrite the chainstate.
In the most extreme designs (likely out of scope for many implementations), it is even possible to have full disassociation of chain validation between chainstates, meaning that a Plasma chain can transact without validating the external chain as a consensus rule (with some additional work, such as the user committing to which Settlement Agents it agrees with in step 2, with some other trade-offs). This means that while a Plasma chain may likely be primarily rooted in one chain, the chain itself can support other chains without requiring yet another blockchain to watch. This is possible because it is the users who are validating the external chains and committing to outputs which they have validated themselves. Each alternate root chain state would have wholly different contracts (and therefore different participants/transactions) as transactions would be committing to different sets of data. The alternate root chain still needs to support the Plasma design, however.
Every output being updated is merkelized and committed to a specific contract round.
The prior individual outputs are spent in the Plasma chain and converted to a bound state conditional upon the current owner (Settlement Agent) signing off on it. If the Settlement Agent refuses to sign off, their funds are returned in the event a signature is not produced. In the event of it being returned due to non-signature or invalid chain state, it can either be withdrawn on-chain or updated inside the Plasma chain back to the original owner.
To set the capital as committed, the output is updated to be spendable conditionally upon an output which is either a dispute which cancels the withdrawal (via a proof it has already been spent, with no locktime), a timeout withdrawal (with a locktime), or an output which commits to the contract conditions defined by all parties which is spendable with witness data provided at a later date (signature by SA, recipient, total amount consumed by all participants, proof of a valid finalization transaction occurring at the correct time). These three possible conditions set up the path for the settlement capital. Note that the third condition is entirely opt-in, but once signed off on then becomes non-revocable (unless a finalization transaction is not published, then it times out and the funds become again spendable by the SA).
The SA's possible codepaths have either them getting their money back, or them signing off on giving it conditionally upon them receiving the same amount atomically (presuming correct root chain non-reorganization and non-censorship).
There is a problem of how to compactly compute the UTXO ownership on the state transition on a globally released state (e.g. an exchange rate or oracle result).
It is absolutely necessary for global consensus on the transfer of the UTXO ownership; one must know which UTXO one owns provided a certain result is published.
The complexity is when one puts in an order, one must be able to reserve a certain amount of outputs and claim them upon a particular price.
This requires being able to transfer funds at the exact condition for all state transitions, as well as knowledge of which UTXOs one will receive. There are multiple possible ways to solve this.
A simple solution would be to require all commitments to produce outputs which can execute at all possible returned values. For example, if a transaction will be executed based on a clearing price, then all possible clearing prices should be able to be made. This can simply be done by requiring transaction deposits to include all powers of two up to the total amount being transacted. If a user doesn't have outputs for all powers of two, then one can trade for those outputs before issuing one's order.
Each Settlement Agent commitment must have a standard amount of outputs of each type. This is to ensure ease of calculation when the validators commit that a sufficient value and number of outputs are available. Settlement Agents can provide multiple commitments (with multiple bitfield slots) if they are providing a significant amount of capital.
For the second problem of knowing UTXO state claims, the User Confirm/Revoke Tx commits to:
While there are more capital efficient methods consuming less liquidity, it increases complexity, e.g. committing to all possible contract output states in a merkle tree.
Note that the Settlement Agent has not yet committed to the total settlement UTXO set (as they had not yet known the entire committed UTXO set when they did the Allocate UTXO Tx).
It's required to define conditions for successful execution of transaction state as these are locally computed. The theory is that one sort of doesn't care what everyone else does in the future as long as these conditions hold. One cannot rely on correct execution of anything in the future, therefore, these are the conditions which are held as inviolable. When multiple participants have transactions using the same output conditions, execution of participants' states thereby become bound and constrained to a single possible correct output state. This constraint limits the Settlement Agents to only want to sign off on the correct state.
The ability to withdraw on the root chain implies the transfer of ownership.
As with other withdrawal mechanisms, it's presumed that proofs of spentness cancels the withdrawal (the current UTXO state is not the state attested to by the withdrawer) and is not described here for succinctness. Note that witnesses may be necessary for proofs of spentness when the withdrawer is responding to a withdrawal challenge and therefore the challenge bonds should be sufficiently high to account for this.
All parties compute the state transition with all transactions (and other associated data) as an input.
The Settlement Agent then signs a commitment to:
After sufficient Settlement Agent signatures, the validators publish on the root chain a bitfield of all Settlement Agents which have signed, with a commitment to the state transition result, merkle root of all Settlement Agents, and the total funds being exchanged by all parties (ordered by denomination).
There is a dispute period whereby any Settlement Agent can disagree with this finalization transaction published by the validators. In the event of successful dispute, the finalization transaction is cancelled. Possible disputes include (but not limited to):
After the dispute period, in the event of no disputes, the state transition is locked in and the contract state transition or trades are finalized.
To claim/withdraw, it is most likely more efficient to do a payment on the Plasma chain which results in a simple output. In the event the Plasma chain has halted, the SA can withdraw from the users' output by providing:
What is being made here is a proof ensuring that the User's output condition has been fulfilled, as well as that the SA has sufficient authorization for the User's output. If the SA has not signed off on the state transition or their funds were not used, they can claim their original locked funds in the Plasma chain (with a simple spend) or the root chain (by providing proof that they were not in the bitfield OR a time delay for a dispute by a user with a User Commit Tx to prove they were the rightful owner).
When the withdrawal is initiated and proven, there is a subsequent delay to prove there has been no subsequent spends.
The offset position is an optimization needed to calculate which output is being claimed. As each bit in the bitfield are providing a specific number of UTXO denominations, the transaction asserts which SA's bit is being used for settlement, since we don't want to manually count bits. It's faster to provide the offset and verify it by doing a log2 of an array of bits to count the number of bits enabled (and therefore it verifies the offset being asserted). This now verifies that the SA has signed off on the Finalization Tx.
In essence, the SA as provided proof that they can claim a UTXO from a User Commit Tx output since they have provided an equally valued UTXO for the contract.
In the other side, the User can claim a different UTXO from a SA. The user must provide:
This lets the User claim a specific output from the SA. Note that in this case the User is claiming the SA's funds locked up from the Allocate UTXOs step. When the SA is claiming from the Users' funds, it is the funds locked up in the User Commit Tx.
When the withdrawal is initiated and proven, there is a subsequent delay to prove there has been no subsequent spends.
In the event the User has not seen the User Commit Tx due to data unavailability, and the user has not seen proof of inclusion for the User Commit Tx, the user may not know whether their transaction/order has executed. Consequently, the user may attempt to withdraw from the User Allocate Tx. If this is invalid, the SA who is the rightful owner can submit proof of inclusion for the User Commit Tx (which the user may use later) in the root chain. The Plasma chain can penalize the user with any reserve funds (does not need to be consensus enforceable on the root chain in simple designs). It's presumed that the user is keeping some funds for transaction fees and penalty deposits in a sidechain construction on the Plasma chain in de minimis amounts (fees entrusted in a federation, all other value is in a Plasma construction, this can be further decentralized but requires more code in the exit game).
These interactive exits are only necessary in the event of large long-term directional fund flows, the Plasma chain halting, or the system going byzantine. It's presumed that transacting inside the Plasma chain makes the need for elaborate exits unnecessary in most cases. However, note that any fee economics presumptions should consider that these spentness proofs may need to be provided if someone attempts to withdraw a spent output which has been locked in this transaction -- this requires a larger proof to be broadcast in the future by a 3rd party (the current owner of the UTXO, which may not be the prior user which participated in the contract).
With research on the constructions which is possible to minimize trust, it's clear that game theoretic summation via Settlement Agents (the above construction), as well as assurance contracts may be a primary construction necessary for inter-blockchain state. Nearly all other constructions can compose those constructions as well as UTXO conditions to create enforcement. Most other contracts either rely upon oracles or can be minimized to an output condition. Plasma Cash and Plasma Contracts as a design consideration aggressively pushes the state construction to be removed from consensus validation (the source of where the benefits arise in Plasma), consequently it takes the position of ensuring data availability and inter-blockchain assurances with the trade-off of higher client-side validation and partial liveness (and non-reorg) requirements of the root chain. Unlike Counterparty-like constructions of client-side validation, however, this construction supports smart contracting with both deposits and withdrawals which consequently supports true value exchange.
These roles of ensuring correct computation of summed transacted values and assurance contracts reflect the roles that clearing corporations/agencies have provided in the traditional financial systems.
It's presumed that there will be open pre-signed offers to exchange Plasma Cash UTXOs for a microscopic fee by participants who want to increase/decrease their denominations. Settlement Agents will likely also serve this role as they will be holding many UTXOs as well. Users submitting transactions committing capital should include units of all powers of two up to the value being transacted to ensure exact precision of post-execution state.
Further research is possible to construct the ordering of the Confirm Tx, but it is possible by requiring all users in the child chain to create transactions and to have a single Settlement Agent issue transactions on behalf of the user. The SA would still consume a bit on the root chain bitfield specific to that child chain. As only the deltas between child chains are transacted, this would result in a significant storage savings in Plasma chain validation (one would monitor the child chains in which they hold UTXOs, as well as the Plasma Chain and root chains holding funds). The SA would be only transacting the netted value in the top level Plasma chain. Censorship risks may be higher in nested chains. Again, this requires greater research but would be a source of client-side validation improvements but not necessary unless there is extremely high volume.
This class of problem is limited to many-to-many state transitions, as most other use cases are resolvable with Plasma already or aren't relevant. While Plasma had a design goal of scalability in smart contract execution, guarantees about using this for long-term UTXO entry scalability is undefined; it should be obvious that root-chain storage of funds is the most robust (one can rapidly move money in and out of the Plasma chain by doing a cross-chain swap). We can classify different types/levels of state transitions with many parties:
Special thanks for the engineers working on implementations of Plasma, their leadership allows for research to have materialized and hopefully assist in implementation efforts.
This post depends upon the following (alphabetical non-exclusive list of) people who have participated in the Plasma Cash design, in addition to the many people in the community (apologies for not being sufficiently exhaustive): Ben Jones, Dan Robinson, Georgios Konstantopoulos, Joseph Poon, Karl Floersch, Kelvin Fichter, Vitalik Buterin, Xuanji Li.
Relevant documents (please contact to add more relevant historical references):
Dan Robinson - Plasma Debit: Arbitrary-denomination payments in Plasma Cash
Kelvin Fichter - Simple Fast Withdrawals
Vitalik Buterin - Minimum Viable Plasma
Dan Robinson - Plasma with client-side validation (Plasma Cash)
Vitalik Buterin - Plasma with much less per-user data checking (Plasma Cash)
Georgios Konstantopoulos - Paper summarizing the community's Plasma Cash research
Vitalik Buterin - RSA Accumulators for Plasma Cash history reduction
Karl Floersch - PoS Plasma Cash with Sharded Validation
Kelvin Fichter - Plasma XT: Plasma Cash with much less per-user data checking (checkpointing)
Sourabh Niyogi - Plasma Cash with Sparse Merkle Trees, Bloom filters, and Probabilistic Transfers
Xuanji Li - One proposal for plasma cash with coin splitting and merging