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

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.
proof of consensus on L2 to L1 via the threshold signature to control the L1 assets by the L2 chain and its entities (SCs).
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.

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.

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

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

Bartosz Kusmierz

2022/05/17 09:43:14

What about Hans' ideas? I thought he claims that Turing complete, UTXO based computations can be enabled with his new approach (Edited)

Evaldas

2022/05/17 13:26:53

it is not about ideas. Just misunderstanding what Turing complete means (Edited)

2022/05/17 13:46:46

We might also add a consequence that if 1/3 of the committee nodes is corrupted, then there is no possibility of accesing the funds (even though no fraud was commited) (Edited)

2022/05/18 08:29:17

51% or even less

One example of problems with mining when 33% of hashing power is in the hands of single entity is "selfish mining" https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf (Edited)

Dave de Fijter

2022/05/19 07:45:37

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).

Say a chain has 12 validators collectively having a stake of 1 million$, and there is 1 million$ worth of tokens connected to that chain (with NFTs and other native tokens that might or might not be listed or might not be part of some oracle impossible to get the right value for). Now say all validators are staking 83k$ each (even distribution, best possible scenario since the value can be lower if it's uneven). That would mean a slashing security of 750k$ because 9 validators are 2/3+1. (Edited)

2022/05/19 07:46:57

I think the concept of knowing the value of a chain is pretty flawed since it's too complex and comes with too many assumptions and potential things to go wrong (especially if you need to rely on external factors and things like failing oracles). Also every chain would need enough stake so the chain is pretty much limited to the amount of stake attached where with the zk route the shared L1 security applies to all attached chains. (Edited)

2022/05/19 08:10:22

wrong state commitment signed by the supermajority of validators. This information is publicly available on L1

What if colluding validators move the tokens without providing a state commitment, bypassing ISC altogether but just creating a threshold signature for moving all funds away? There will be proof of that on L1 obviously but there might not be a commitment per se? (Edited)

2022/05/19 08:17:47

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.

It's not quite possible to reliably determine the value on a chain (NFT, native assets without proper value information publicly available, need for reliable Oracles which even dedicated solutions like ChainLink fail in regularly (see LUNA pause of ChainLink Oracle causing major losses recently)). What is this 20% based on, at all time? That is pretty limiting I think. (Edited)

2022/05/19 08:19:15

The primary market ask right now for decentralized smart contract solutions is DeFi, the top 10 single chain solutions all have $1 billion or more worth of value locked in their chains with Ethereum topping at $70 billion. With multiple chains and a limited set of validators I don't see this working with any substantial amount of TVL on a chain against these stakes, also considering the current IOTA market cap. (data: https://defillama.com/chains) (Edited)

2022/05/19 08:21:43

trustlessly

Only under the assumption the amount of stake is high enough to ensure validators won't collude from a game theoretical standpoint. It's also under the assumption we can figure out the value within a chain reliably and trustlessly (which I think we can't fully do). While it might be suitable for some lower TVL solutions I don't think it's suitable for the bigger numbers in the game. (Edited)

2022/05/19 08:23:06

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.

Besides slashing the full stake there is no intervening right? The 2/3 +1 of validators of the chain always decides even if someone objects, once they collude there's nothing we can do beyond that point besides the slashing. (Edited)

2022/05/19 08:34:55

the main motivation to have as much validators as possible in the committee, comes from the validators themselves

From a security perspective the more the better but do you think we can overcome technical limitations around consensus to have bigger numbers of validators per committee as currently possible? (Edited)

2022/05/19 08:37:17

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**

Even without the decentralization ISC still offers a powerful setup with lots of options for situations where the committee can be fixed, this indeed does not make sense to do and should co-exist next to whatever else we come up with regardless. (Edited)

2022/05/19 08:43:02

It will have to be built on real world identities and hierarchies of trust based on real world reputation and business interest.**

For the best user experience, yes, but I think it's not strictly needed with some effort to trust a third party or third parties here given everyone can generate a validity proof under the assumption the data is available (which does not strictly has to happen under a trusted setup I think) and the method for generating the proof is public (which it should be). Solutions like ZkSync for example offer a sort of hybrid (zkPorter) very similar to optimistic rollups just for the off-chain DA (Edited)

2022/05/19 08:44:23

This approach would be similar to the game-theoretical security of Ethereum optimistic rollups.

Under the assumption the stake will be lower as the value locked on chain this is likely not sufficient for a lot of high value use-cases unless we become a market leader in this space (chicken/egg problem) (Edited)

2022/05/19 09:18:21

anybody who has access to the state

State access is not a given and under full control of the validators, it can be censored or completely opaque, so you need a proper, verifiable DA solution for it. (Edited)

2022/05/19 09:19:50

we can skip the idea of the market for validators

While true rotating committees in a non-predictable way regularly will make it practically harder to get validators to collude. (Edited)

2022/05/19 09:56:23

That is true. Value relies on oracles. This is not good as a part of a fundamental concept. That is why the goal should be just making it impossible to withdraw all assets from the chain in ine step. I am asking to invent solutions,, not just to burry drafts :) (Edited)

2022/05/19 09:56:55

See above. Oracles are not acceptable, that is clear (Edited)

2022/05/19 09:58:33

ISC is decentralized! You understanding it wrong! (Edited)

Andreas Penzkofer

2022/05/22 16:02:24

What if in a rollup solution the calldata is posted atomic together with the rest of the data? E.g. in the case of IOTA the max transaction size is 64kB. Thus for state commitment post + call data that fits within this, it can be proofably complete and would have no DA problem (Edited)

2022/05/24 07:48:01

posting 1000 TPS of call data to L1 is not a good idea imo. We post the commitment to all call data as a part of the state commitment, but the data itself stays on L2 (Edited)

2022/05/24 07:49:36

besides, in IOTA both versions consumed outputs are pruned, no DA anyway

2022/05/23 09:16:35

performance

what is the definition of performance here. they are slow to calculate, O(1hour). However, they are related to the input size by a reasonable power relation. Thus batches for validity proofs can be small and frequent. As a consequence the throughput can be high (Edited)

2022/05/23 09:19:41

Distribution and redundancy of the state data in special *data availability layers* is the answer

alternatively, if we dont care about throughput, we can put everything on-Tangle. In that case no DA exists, since the data can be proofably complete. or in other words the proof plus data is atomic (Edited)

2022/05/23 09:25:30

The latter makes it impossible just to copy approaches of the Ethereum optimistic rollups.

i am curious. once our blocks get accepted confirmed, there are no double spends. as such this resembles a global state. would you still see a difference between the "accepted confirmed" global state and the ETH global state? (Edited)

2022/05/23 09:27:27

**atomic**

what is the process that makes this state transition atomic? (Edited)

2022/05/23 09:28:24

is the state transition on L2 only accepted once the state anchor is confirmed accepted on L1?

2022/05/23 09:34:30

ICP claims that their NNS has 100 nodes and they use BFT (synchronous) consensus. Is this because thay have super fast nodes (like EOS)? (Edited)

2022/05/23 09:36:28

any party which has access to the state

what happens if 2/3 of the commitee is malicious and witholds the information about inputs to the other committee members. does this not also pose a DA problem? (Edited)

2022/05/23 09:51:10

DA is enforced in Polka using DA committees (Edited)

2022/05/24 07:46:15

it is an illusion of enforcement. They provide it because it is encoded into the protocol (or it is (already on L1). The same way we can enforce too

2022/05/23 12:14:58

governor

governer = owner of the chain? (Edited)

2022/05/23 12:50:14

the entity which makes top decisions such as validator selection, rotations, etc. It can be centralized or decentralized

2022/05/23 12:44:54

by absense

absence to everybody: transactions are pruned for some reason in Hornet, not sure about Goshimmer. I think it is contraversial decision to get rid of transactions (Edited)

2022/05/23 12:50:42

indication of misbehavior

but how will they report the inability to have DA? i see several paths: 1. fishermen build a committee that signs on L1 that they had access on L2. e.g. using threshold signatures 2. every node interested in the SCC runs a DA sampling and data is distributed to nodes using erasure coding. by doing so w.h.p. nodes can be sure that fishermen had access to the whole state transition data 3. the committee submits the data to a DAC / DA layer which signs the availability on L1 (Edited)

2022/05/24 06:39:59

even with proofs containing relatively simple transactions it is slow. See Mina's 1-2 TPS. When it comes to Turing equivalent computations, a VM, the block time becomes 10-30 min. With 1000 TPS that would mean 600.000-1.8 mil transactions per block, which gives ever less realistic figures. meawhile 1000 TPS on normal VM is realistic, assuming 10-15 sec block time. This can only be imrpoved with special HW/ASICs, but will never be cheap (Edited)

2022/05/24 07:07:39

yes, in the L1 you could put all the data, however it severely limits throughput (Edited)

2022/05/24 07:20:05

roughly: the SC program must receive same inputs in any node where it is executed. Eth global state is equivalent to the state of ISC chain. The IOTA ledger acquires deterministic global state after global finality only, big delay. So, global state exists, however for participants may perceive it differently. This is a consequence of parallelism in UTXO. Analoguies with relativistic view of the physical world holds (Edited)

2022/05/24 07:27:45

yes, it is a DA problem, essentially refusing to communicate with the outer bubble. Nothing can be done with it, the system is souvereign. It only can be punished post factum (Edited)

2022/05/24 07:29:22

moving funds means state transition on L1. Stealing would mean invalid state transition or absense of data to check it validity (Edited)

2022/05/24 08:12:02

what is the reason we cannot use the confirmation, which is in the order of 2second? it is global for each node, since no two nodes will disagree on the confirmation of a transaction. Is the problem that SCC need to interact with each other and this is where partial order is introduced? (Edited)

2022/05/17 09:45:21

We might also add potential changes to L1 to fit better needs of potential partners (Edited)

2022/05/17 13:29:05

what to add? It is misunderstanding what is possible with utxo, what is not and what is needed (Edited)

2022/05/17 13:31:48

Do you mean UTXO? (Edited)

2022/05/17 13:45:44

permission of the chain validators

Unless we consider on-leger requests only (Edited)

2022/05/17 13:54:37

that is right, but this writeup is not intended to be accurate (Edited)

2022/05/17 15:17:27

our L1 transactions don't have access to the global ledger state (Edited)

2022/05/17 15:19:03

L1 access not enough. Still exact inputs is the result of the consensus among validators (Edited)

2022/05/19 09:20:34

Q. What is the function of the *root chain*?

In addition it could also control the (inflationary) supply of the Assembly token if we distribute it. (Edited)

2022/05/19 09:57:47

No, 30-40 is a reasonable assumption for BFTs (Edited)

2022/05/19 09:59:43

See in the text: DA is not enforceable, even in ethereum rollups! Thinking about it must be changed (Edited)

2022/05/19 10:31:09

Yes, and few other functions (Edited)

2022/05/22 20:15:35

governing controller

Will we require a controller to provide some form of collateral? (Edited)

2022/05/22 20:31:00

20% of the proven stake.

Does it make sense for the root committee to approve such cross transfers? (Edited)

2022/05/23 09:09:23

**Assembly promise

do we have any additional information about what our promise is. I would like to read up on that (Edited)

2022/05/23 09:18:18

in particular when using parrallel SC chains (Edited)

2022/05/23 09:34:45

are available to all L2 validators

unless all calldata is published atomic on L1 together with the anchor (Edited)

2022/05/23 09:53:13

absence to whom? (Edited)

2022/05/23 09:53:37

which nodes on L2 ? (Edited)

2022/05/23 09:57:21

The feature block

i suggest to expand this paragraph a bit. i did not understand it (Edited)

2022/05/23 12:03:00

*status quo*

would be good to discribe in a few words / give a brief idea what distinguishes status quo from the new approach (Edited)

2022/05/23 12:12:09

speed

speed in blockchain speed (tps) or speed in finalization times (which is transaction speed)? (Edited)

2022/05/23 12:43:31

yes, thanks :) (Edited)

2022/05/23 12:45:41

any nodes or not nodes, e.g. wallets. (Edited)

2022/05/23 12:46:33

yes, this is very specific parlance of the Stadust, sorry. Go in details is not intention here (Edited)

2022/05/23 12:47:31

in throughput, i.e. TPS (Edited)

2022/05/23 12:52:02

4. use rollup solution and store all calldata on L1 (Edited)

2022/05/23 12:52:56

rollups

optimistic rollup or optimistic off-chain solution? (Edited)

2022/05/24 07:24:21

on-chain calldata is on the L1 ledger already. However, we need off-chain requesting to achieve reasonable throughput (Edited)

2022/05/24 07:25:20

there are other reasons why calldata cannot be on L1 of high throughput systems (Edited)

2022/05/24 08:07:45

what is the minimum tps we want to achieve per SCC? Maybe we can live with 10 tps per SCC (Edited)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.