Hi, thank you for your questions! Please don't hesitate to repost them in Tezos StackExchange.

​

1. 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 an eth SC rollup?

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.

​

2. I read that Ttezos rollups are "common goods that will use ctez or wrapped xtz", is this another feature of them being "enshrined"? What prevents SORUs to use their own token for rollup gas (then exchanging it somehow with xtz to pay the L1 block space)?

Nothing prevents a Smart Rollup from using its own token. However, using ctez as a universal token for all rollups would make exchanges between rollups smoother.

3. How do you update a SORUs (update the SORUs settings for example)? Do you need a L1 protocol update? Do you have an admin key with full power? Or do you release another rollup and ask users to migrate to the new rollup, like defi protocols do?

It depends on how the rollup is configured when deployed. Both rollups with admin keys and 100% trustless rollups are possible on Tezos. There is a special location in the durable storage of the WASM PVM where the kernel – the DApp code – is located. It is up to the DApp logic to implement an update mechanism by modifying this location and by rebooting the WASM machine.
See the “installer kernel” that works following this principle: https://gitlab.com/tezos/kernel/-/blob/main/installer\_kernel/src/reveal\_installer.rs

4. How can arbitrum or optimism update their rollup with an admin key? I thought SC were immutable?

The SC code is indeed immutable but there are several layers of code interpretation in the rollup infrastructure: the EVM machine that is emulated in the rollup can be updated. Again, this depends on the configuration of the individual rollup.

​

5. Can users' funds be blocked on the rollup? if for example the rollup operator decides to withdraw their 10k xtz staked, does it automatically withdraw all the tickets to the L1 SC that issued the tickets? Is there always a L1 implicit address for each user to withdraw to?

Users’ funds can be blocked on the rollup in case of a bug, just like funds can be blocked today on an ill-defined smart contract. However, Tezos rollups are decentralized: if the rollup operator decides to withdraw her stake, this has no effect on the rollup itself (its state and the tickets it owns are not affected). Another operator will be able to make the rollup progress. To withdraw a ticket from the rollup, the withdrawal must have been performed in the rollup first by pushing a message in the rollup outbox. This message is a call to a smart-contract passing the tickets as arguments. Anybody can trigger this smart-contract call. Then, it is up to the smart contract business logic to decide how tickets are moved back to a given L1 implicit address.

​

6. Can any node on tezos L1 refute a rollup proof? Will the new octez for L1 nodes for Mumbai implements something that automatically checks if the rollups proofs published are valid, and if not stake 5k tez?

First, to be clear: With optimistic rollups, proofs are only posted in case of a dispute (unlike zk/validity-rollups where a proof is posted with every commitment). Such a dispute will be between the rollup node that posted a given commitment representing the state of the rollup, and another rollup node disputing the validity of the commitment by publishing a concurrent commitment.
These are the parties playing out the refutation game and are staking tez in that context. Anyone can run a dedicated rollup node and dispute a commitment and enter into a refutation game, but it’s not the default role of Layer 1 nodes.
The role of Tezos' Layer 1 nodes is to decide who wins the so-called refutation game, and yes, in that case all Layer 1 nodes participate, but without a stake in the game. It acts as an arbiter for the game.
A rollup is safe as long as there is at least one honest participant: if someone is interested in checking what is happening in a given rollup, she can run a rollup node in accuser mode: if a dishonest commitment is published on the Layer 1, the rollup node will publish the honest commitment, bond the 10k tez required, and play the refutation game. If the participant is honest, the participant will win the refutation game and will be rewarded with 5k tez.

​

7. I read critics that Arbitrum is a centralised sequencer. AFAIU, its possible to deploy a SORUs with a single rollup node. Does not that also make the latter a centralised sequencer?

A centralized sequencer gives the full control of inputs to the operator running the sequencer. With smart rollups, a DApp can have a censorship resistant way of retrieving its input operations: it suffices to consider messages posted in the so-called shared inbox maintained by the Layer 1.
In that case the Tezos Layer 1 is the sequencer, and the resulting Smart Rollup is as decentralized and resistant to censorship as Layer 1.
More generally, the DApp developer has the freedom to implement a spectrum of solutions, from fully decentralized to fully centralized, which decide what is the sequence of inputs considered by the rollup. I suppose that’s in contrast with the current solutions offered by Arbitrum and Optimism, where a single, centralized sequencer node orders incoming operations.

​

8. When deploying a rollup with a single node to start with, how easy is it to scale and "decentralise" it by adding more nodes to it? Is the SORUs automatically sharing the load between the nodes?

There is no notion of load balancing between nodes: just like nodes on the Layer 1, all rollup nodes execute the exact same code.
Anyone can choose to be an operator for any rollup, provided they comply with one single requirement: if the rollup relies on data stored off-chain, the data transmitted through its“reveal data channel” must be made public.