Criticism about scaling consensus and Data Availability capacity

What do you think of this tweet? ( https://twitter.com/doganeth_en/status/1619781973693833216?s=20&t=q1IEVeCIBzmy259F3xMenQ) If an answer is given, it will be marvelous. Tweet is about reconciliation and scaling Data Availability capacity"

Let me try to answer some of the questions raised in the referenced post (quotes from the post).

The problem about Oasis is that Oasis scales Execution with TEE (SGX)

This is not actually true as Oasis scaling does not rely on TEEs (btw, this is how we can also support non-confidential ParaTimes like Emerald). The only reason for why we need TEEs is to enable privacy of general computation.

The data availability design of ParaTimes is such that data (both transactions and state snapshots) can be replicated by nodes that do not even run TEEs. Execution proofs also do not rely on TEEs but use discrepancy detection and resolution with randomized committees and configurable security parameters in addition to remote attestation (for confidential ParaTimes). So even breaking an enclave will not enable you to forge execution proofs.

Also note that components in the Oasis stack are modular and have been since the start. The storage/DA component can obviously always be improved or even complemented with something else and things should continue to function as before. One could even imagine complementing existing storage/DA with EIP-4844 once that becomes more practical and production-ready.

Zk and Fraud proofs are not easy to build, so i can get the choose.

This is actually not the reason. Neither ZK nor fraud proofs can magically support general confidential computation and this is what Oasis brings to Web3.

3 Likes

Thanks for your brief