Post- ReSum/Marseille thoughts on smart contract strategy

The writeup covers some topics discussed in Marseille May 11-12, 2022. It takes into account:

• the validity proof approach to smart contracts on IOTA (an alternative to the IOTA Smart Contracts (ISC)).
• the fraud proof approach to smart contract on IOTA. This is going further along the path of already developed concept and platform of the IOTA Smart Contracts (ISC).
• the strategy on Assembly promise (deserves separate writeup, not here)

The main accent of the writeup is to provide input for finalization of the strategic decisions. In particular, feasibility assesment of the fraud proof approach: shall we follow the fraud proof path or abandon it and wait for (zk) validity proved computations.

Note: here we use validity proof approach instead of ZK rollups, and fraud proof approach instead of optimistic rollups because the latter naming is bringing too many of Ethereum assumptions which are not correct in the context of IOTA.

The validity proof path

The validity proof path is quite clear, here is just a short summary.

The main trait of the zk-based validity proof approach is that it can make any (Turing-equivalent) computations trustless. This makes it extremely attractive in the context of the distributed ledger transactions. It has good chances to become a game changer in the DLT sphere and even elsewhere.

Currently validity proofs/ZKP are perceived by the cryptosphere as a silver bullet for solving unfamous blockchain scalability and cross-chain composability problems.

For IOTA, however, the primary problem to solve is its inability to embed Turing-equivalent computations into the L1 level of UTXO transactions by its fundamental design.

It is obvious that IOTA should make efforts to the direction of validity proofs and zk techniques in general. The rough strategy would be:

• implement validity proof unlock condition in the Stardust's ledger, also know as Dark Matter upgrade of the Stardust ledger
• attract partners for developing L2 zkVM solutions on that basis for smart contracts

The main problem with the validity proof approach is performance and, consequently, throughput. Currently it is many orders of magnitude less than the straight VM calculations in combination with the distributed consensus.

Another important aspect is that validity proof approach requires special solutions to ensure data avalability. This is due to the fact that computations of ZK proofs are inherently centralized, therefore state data availability becomes a problem in the contexts where the whole state is needed. Distribution and redundancy of the state data in special data availability layers is the answer.

The availability of the zk-prover function itself is achievable through permissionless distributed market of provers.

Important: validity proof approach is an almost complete alternative to the current approach in the IOTA Smart Contacts on several levels. The concept of zk smart contracts on IOTA must be built essentially from scratch.

The IOTA Smart Contracts (ISC)

We descibe here the main assumptions and consquences of ISC. These are crucial to understand before deciding whether we shall follow up on ISC along the fraud proofs path, or we stay with status quo.

By status quo here we understand developing ISC as is, leaving the worries about validator selection and ensuring security to whoever builds the system.

By fraud proof path we understand extending the ISC with the concept of misbehavior and platform with functions of fraud detection, fraud proving, staking (validator copllaterals) and pinishing for misbehavior. That would be following of the rough plan for Assebly security.

The fraud proof path encompass significant engneering challenges and will require significant efforts and time. The question is it worth pursuing.

The concept and platform of the IOTA Smart Contracts (ISC) has been developed in last several years. It also have had a big impact on the latest concept of the IOTA UTXO ledger specs, both on Goshimer and the Stardust.

The ISC is the basis for the public Assembly promise. The later encompasses many assumptions from ISC.

When assessing the fraud proof path to smart contracts, the state of the art of IOTA Smart Contacts comes as a prerequisite. It is because of lack of alternatives to it, due to (a) desired characteristics of the IOTA SC platform such as high throughput and (b) due to fundamental traits of the IOTA L1. The latter makes it impossible just to copy approaches of the Ethereum optimistic rollups.

Fundamental assumptions of ISC

1. L1+L2 ledger. Each state transitions on the L2 ledger of the ISC chain is atomic together with the L1 state transition (L1 anchor transaction).
   This is different from Eth optimistic rollups, where L1 and L2 ledgers are decoupled and therefore require additional trust (a bridge) for deposit/withdraw between L1 and L2. The L2 ledger state in ISC is committed to the L1 via the state anchoring. The state anchoring only guarantees immutability of the L2 state, it does not guarantee validity of it.
2. proof of consensus on L2 to L1 via the threshold signature to control the L1 assets by the L2 chain and its entities (SCs).
3. committee of validators: a permissioned BFT setup of the L2 consensus. It is goes together with the proof of consensus in the form of the owneship of distributed keys and DKG procedure.

Consequences

The assumptions above has fundamental consequences:

• All trust on the state transition is on the committee of validators. It means, if committee (i.e. \(2f+1\) of members) wants to commit a fraud, nothing could stop it.
  This could lead to rug pulling (unless mitigated by the restrictions of on the L1, more below).
• impossibility of the L1+L2 state rollback after the finality. It also means, if fraud happens, it is final and the hard fork of L1 and L2 from the state snapshot is the only option.
• The fraud can only be detected post factum (post-finality). It means, we can only punish for fraud, not prevent it (with validity proofs we can prevent fraud).
• the inputs to the state transition are available to all L2 validators, however parties outside the committee setup are not able to access the state without permission of the chain validators (DA problem). Same time, any party which has access to the state, immediately has all information about the inputs
• State availability (DA) is completely up to the validators of the ISC chain. It means, they will share the state only if they want (motivated) to do so. Same time, this is not any different from any other souvereign (not-permissionless) system.

Definition of misbehavior and fraud

By misbehavior we understand:

• direct fraud: state transition not conforming to the deterministic prescriptions of the VM. This includes stealing assets of user by the colluding supermajority of validators. The fraud proof in this case includes:
  • proof of inclusion of all inputs. This information is contained in L1 and L2
  • wrong state commitment signed by the supermajority of validators. This information is publicly available on L1
• data availability fraud is an inability to deliver valid state update (state mutation, the block) within some period of time \(T_F\) after finalization of the state transition on L1. The latter is public, permissionless information. In practice it means the access nodes which are not validators are not able to synchronize the valid state for time \(T_F\) from the moment when anchor of the new state was confirmed on the L1

Extensions of L1 (Stardust) needed to support fraud proofs

These are rough ideas what is missing on the current Stadust ledger to support fraud proofs on L2. The list may not be final.

How to prevent rug pulling on L1?

It can be done by filling some gaps in current functionality of L1. (TODO real requirements)
We need extensions of the Stardust UTXO ledger:

• Staking/delegation output type. This would be a modification of the Alias output. The Staking output will hold staked assets. The chain will be able to prove the stake by transiting the Staking output in the anchor but only a governing controller will controll the funds
• The Alias output validation will include limiting of sending funds outside the scope of control of the Alias output (withdraw) to a part of the proven stake. For example, it won't be possible to withdraw/send cross-chain more funds than 20% of the proven stake.

The above essentially solves the rug pulling problem on L1, i.e. independently from the trust to the committee, trustlessly.

• Some questions remain: the above is easy with the iotas only, however when we want to limit withdrawal of native tokens and NFTs, we might need more sophisticated L1 machinery
• The above does not prevent rug pulling completely, just makes it impossible to do it in one step.
• In general, this kind of machinery must make removal of assets from the chain a lengthy process so that meanwhile fraud detection and enforcement mechanism had time to intervene.

Trustless commitment to the (sub)essence of the transaction

The Stardust protocol abandons transactions as a thing of the ledger state. The node only gives you outputs (UTXOs) while transactions, the real atomic state transitions, are not provided, even containing unspent UTXOs. The thinking behind is that (a) not needed and (b) they better be pruned because redundant.

Transaction prunning on L1 is contraversial. It creates several "trust/security breaches" on the level 2, because signature is contained only in transaction.

It requires presence of special mechanisms in the protocol to mitigate that:

• Sender feature block in the UTXO. Without it would not be possible to identify originator (signer) of the transaction because this information is not avaialable in UTXOs
• Input commitment at the transaction level to prevent faked output attack. The solution is commitment to outputs consumed by the transaction in the essence of the transaction, aka input commitment. That invalidates trasaction which was constructed using faked outputs.

There's one more problem caused by absense of transactions: L2 has no way to check if the VM run on same inputs produces the same transaction essence, because outputs does not contain that info nor even commitment to it. Note, that we need to check transaction essence, not the whole transaction, because fishermen context can't reproduce signatures nor has access to it.

The draft solution for this is to extend the protocol with one more very special feature block with tentative name commitment to sub-essence (I know, it is ugly). Logic is similar to the Sender block.

The feature block will be present only in the Alias output. If present, it will be enforced by the validation rules to contain the commitment to sub-essence, a hash commitment to the essence of the transaction with all zeroes in the place of the very block. Or, equivalently, hash of all essence data, except the very commitment to the sub-essence.

This solution would allow valid commitment to the essence of the tx to be contained and enforced in the Alias output.

Other, more general solutions are possible too.

Other support from L1

The fraud proof have to contain proofs of inclusion (PoI) of the input to the state transition in order to be able to check the validity of the fraud proof off-ledger (aka off-chain).

Currently IOTA L1 nodes, neither Hornet, not Goshimmer, do not provide any PoIs for the requested ledger state elements (namely, UTXOs). This is not a trustless client/node protocol, i.e. to trust even existence of the UTXO the L2 client have to run its own node.

The expected function would be:

• for the Hornet to provide PoI of the output to the commitment stored to the milestone
• for Goshimmer the same, PoI of the output into the ledger state committed by the finalizing milestone

Distribution and trust in ISC

ISC status quo assumptions makes it a consortium blockhain, similar to Hyperledger.

The validators of the committee is a permissioned setup, i.e. a validator cannot decide to be one by itself.

Contrary to what many think, consortium setup is a distributed, not a centralized setup. Analogy would be a democratic parlament, a decentralized yet permissioned system.

The committee of validators becomes such through the consortium agreement, which, in general, is decentralized and essentially, leaderless (all parties legally equal, possible coordination is just a formally technical function). The consortium agreement among validators in ISC takes form of the distributed key generation (DKG) procedure which is a form of BFT consensus on a distributed secret key.

The above leads to 2 important conclusions:

• ISC setup is trustless for its validators
  Entities, organizations or persons running validator nodes in the committee of validators for the chain, are secure to transact on the ledger because:

  • each committee member participates in the committee by consensus among them all (decentralization)
  • each validator should not trust other participant to have the valid ledger state. The conspiracy inside commitee among \(2f+1\) (67%) of validators is the only way to break it.
  • the "trustlessness threshold" among validators in ISC is higher than it is in the permissionless Nakamoto-style consensus, where conspiracy threshold usually is 51% or even less (IOTA has 33% ??)
  • the main motivation to have as much validators as possible in the committee, comes from the validators themselves

• ISC setup is not trustless for the outside participants. Outside participant have to trust the committee of validators as a whole (not individually). It means, generaly speakling outside world have to assume the ISC chain may be fraudulent due to collusion among \(2f+1\) validators.
  The governor of the ISC chain may be decentralized (DAO) or centralized entity. Trust-wise, the governor is an outside user wrt the chain/committee. For this reason, in most corporate consortium setups of ISC chains same entities both govern and validate the ISC chain.

The above makes ISC a powerfull and very performant (100000+ TPS) multi-chain platform for decentralized consortiums on the network: DEXes, consortiums in energy, food and other logistics, consortiums in insurance and other finance sectors, in the distributed ledgers for the public sector, such as pan-EU ledger etc. At the moment (and most likely several years ahead), speed and cost of transaction of the zk-based provers is no match for the above.

(Side note. In contrast, in the permissionless Nakamoto-style DLTs, 
the distributed ledger looks a trustless environment for the outside user, 
assuming:
- the user can access any random validator node to ask for 
the commitment to the state and proofs of inclusion of its elements
- the user can run the validator node by its own will at any time
- there's no 51% collusion among validators

This makes permissionless/"unstoppable" ledgers perfect for 
use-cases such as crypto. Of course, permissionless ledgers 
suffer from well known limitations such as low performance, 
non-scalability and high transaction cost. )

Strategic options with smart contracts in IOTA

We skip the validity proof approach here because it is not an option but a parallel alternative to ISC.

1. Scrap ISC altogether.
   Consequences: no SCs on IOTA (unless zk SCs via Dark Matter much later). Problems how to deliver on the Assembly promise <– does not make sense

• Status quo of the ISC concept (aka embrace assumptions) and betting on validity proof approach to deliver zk-SCs.
  Consequences: we have to reposition IOTA SCs and sell the ISC as a platform to the corporate world: crypto-consortiums, exchanges, companies, EU etc. This would create problems with the Assembly promise
  The most important: we would have to build ISC ecosystem by different principles from what crypto communities are used to. It will have to be built on real world identities and hierarchies of trust based on real world reputation and business interest. This is very different from usual anonymity and financial motivation of miners, hodlers and believers.

• Fraud proof approach. Make ISC as trustless as possible for the outside (non-committee) participants (for the validators it is already trustless).
  Once we cannot prevent the fraud, we can only punish for misbehavior (see above the definition of fraud/misbehavior).
  This approach would be similar to the game-theoretical security of Ethereum optimistic rollups.

Now we want to assess the Fraud proof approach.

The generic problem and solution

The generic problem of trust in DLT sphere elsewhere is known as principal-agent problem.

The fraud proof approach is a solution of it by hiring the 3rd trusted party, the auditor or fishermen, which monitors the operations of the chain/committee on behalf of users and submits fraud proofs in case of misbehavior to the enforcing party.

The key points:

• the chain must be motivated to share state data to the fishermen as the data availibility cannot be enforced. The strong motivation for openness to public auditing is earning credibility for the users.
• otherwise, the fishermen function itself is completely permissionless: anybody who has access to the state can check its correctness. It means any number of fishermen can be attracted to audit the chain and witness credibility of it: the open and permissionless market of fishermen.
• the above makes trust to fishermen distributed
• the synchronicity assumption of state availability in \(T_F\) time is necessary. This is similar to the dispute period of the Ethereum optimistic rollups.
• the above is how real-world hierarchies of trust works in the human society, markets and the corporate environments, including financial services. The notion of provably correct things (validity proofs) does not exist in real world environments. Therefore, any permissioned entities are intentionally exposed for public auditing whenever they want to be trusted

Some Q&As

• Q. Does it matter how the validators are chosen and how they form the committee?
  A.: in general, no. The only thing which matters is what skin-in-the-game they put.
  This means we can skip the idea of the market for validators together with related complexity. It is up to the governor to select validators and we should not care about it.

• Q. To whom validators have to submit stakes/collaterals?
  A. To a 3rd trusted party called root chain. Unlike in Ethereum, we can't use IOTA L1 for this. The root chain may be run on a distributed trust (a committee, say high mana nodes and similar). The root chain can also be a trustless zkRootChain, which provides validity proofs to L1 (the Dark Matter).

• Q. What is the function of the root chain?
  A. Control stakes (collaterals). Validate submitted fraud proofs. Enforce (punish, slash etc)

• Q. Who will detect the misbehavior?
  A. auditors, a motivated entities, running a special type of extended access nodes called fishermen.

• Q. How the necessary data will be available to detect the fraud.
  A. The fishermen will be syncing the chain's state by the blocks delivered from the validator nodes and the L1 state commitments. The inability to sync the state (i.e. to access the state) will be indication of misbehavior too. While one instance of such misbehavior may happen due to technical reasons (e.g. internet outage), if all or majority of access nodes which are connected to different validators can't sync the state which they see on L1, it is a strong indication of misbehavior.

• Q. Does this approach bring benefits to the ISC as a platform?
  A. Yes. It allows positioning of ISC in the same shelf as Eth optimistic rollups, however with some strong advantages

• Q. Does this approach brings benefits for the delivery of the Assembly promise?
  A. Yes. Otherwise we do not know clear alternatives for the utility of the Assembly token. In the fraud proof approach utility if the Assembly token will naturally come with using it for staking as collaterals and paying gas and other fees to SCs

• Q. Cost-benefit analysis of status quo vs fraud proofs path?
  A. That is what we can only assess by doing detailed planning of the fraud proof approach. The development scope seems significant but doable.

A sketch of the MVP plan

• spec the fraud proof
• spec the fraud detection, submission and enforcement workflow/protocol
• develop fishermen extension of the access node
• develop root smart contracts on Solo (staking, fraud proof validation, enforcement)
• identify gaps on L2 and L1. Spec solutions