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.