[Question coming from reddit]
What makes the tezos rollups "enshrined" as compared to smart contract ETH rollups? Is it because the rollups have special treatment by the L1: specific sr addresses, inbox and withdrawals process etc which makes them more "efficient"? If so, what is the improvement order we are talking about in gas fee, performance etc vs a eth SC rollup?
Response from whalesniper
ETH rollups are built into specific contracts. So imagine I deploy my own KT1 which has a multisig and a bunch of rollup commitment logic or whatever. This rollup is built on Ethereum smart contracts but the base Layer 1 blockchain is only running a solidity contract, and makes no guarantees about the sequencing or settlement of the rollup data.
So yes, Tezos rollups get special treatment by the L1 which gives better security guarantees. You'll see arthur talk cryptically about other rollups being "multisigs", meaning they arent guaranteed by the ETH L1, but a consortium of private keys held off-chain.
I think one would be able to implement similar use-cases in both enshrined & non-enshrined styles, but I think one key is that ETH core rollup tech will always be limited by the Solidity language. Tezos rollups are built to support any number of languages, and either way the Tezos L1 can simply upgrade to integrate anything else we need.
Response from Daniel Hines
"Enshrined" means that rollups have a first-class representation in the protocol - the protocol itself receives messages intended for L2, processes state commitments from rollup nodes, and arbitrates challenges to state commitments via refutations games. This has many interesting advantages, and IMO is a prime example of Tezos value-prop as a self-ammending protocol. I'll outline some that come to mind:
Security: Designing a secure rollup bridge is difficult. Designing one in the challenging of setting of a smart contract execution environment is even more difficult. Native code is much easier to write, reason about, test, benchmark, etc.
Performance: By running the refutation game in native code as opposed to an interpreted smart contract language, we can afford rollups more compute per operation (and lower fees).
Governance: Highly related to security, the semantics of rollups (at least on L1) are governed by the usual Tezos governance process, which, over 5 years and 12 upgrades, has a pretty good track record. Note, this doesn't account for upgrades to the rollup kernel itself, the governance of which is determined by the kernel implementation, much like a smart contract (more details further down).
Human resource efficiency: SORU is a cross-team project, with deep support from Nomadic Labs, Trili Tech, and Marigold (and maybe others?). Dozens of engineers are working on the infrastructure. Different engineers bring different emphases (security, performance, UX, etc.). The result is that code velocity is very high right now. Because the L1 infrastructure is enshrined, every rollup will benefit simultaneously as upgrades are pushed via the usual amendment process and Octez release cycles.
UX: Because they are first-class, we can tailor the protocol for a better UX, and toolmakers (indexers, wallets, SDK's like Taquito, etc.) have a stronger common denominator to target. As @whalesniper mentioned, tickets will go along way toward rollup interop, and I think this will be a big deal for both UX and security.
Response from nomadic lab
Indeed, having smart rollup infrastructure directly implemented as a protocol component makes the system more efficient, opening more possibilities for sophisticated mechanisms. For example, we were able to implement a shared inbox between all rollups running on top of Tezos paving the way for a form of broadcasting of messages targeting several rollups at once.
See this blog post for more details.
