Hi @Britcoin! At NFT.NYC right now so I don’t have a time to answer. But how about this - I’ll answer until I run out of time. In exchange, would you mind posting these questions on StackExchange? That’s where we’re trying to aggregate techincal Q&A for now.
I keep hearing that TPS are not a problem but the latency - its possible to increase TPS but not latency. Why?
And
All transactions are still submitted to L1 before reaching the sequencer for L2. If this is the case then I still need to wait 15s for my operation to be submitted?
I’ll answer these together.
The idea of rollups is to use the L1 to settle the order of operations, and execute the result of those operations off-chain. The idea of optimistic rollups is to delegate the validation of that off-chain to set of rollup validators who stake on the result of operations and can slash each other whenever a problem is detected via a mechanism called the refutation game.
Hence, you can’t have latency lower than the latency of the L1, since that’s what provides the inputs to the rollup. But you can have higher throughput through vertical scalability. While Tezos can on a Raspberry Pi, there’s no problem with requiring a 128-core machine with 1TB of RAM to keep up with your epic blockchain gaming rollup or whatever.
That’s rollups, pure and simple. But many rollups in the Ethereum ecosystem add an off-chain sequencer to the mix. By forcing transactions to go through a sequencer, the sequencer can provide optimistic results on the execution instantly, before they’re included in the L1. Naively implemented, the sequencer could sensor anyone with impunity; however, it’s fairly straightforward to include a “delayed inbox” that allows anyone to include an operation in the rollup via the L1 in the case of censorship or the sequencer goes down. Smart Rollups don’t ship with a sequencer out of the box since it doesn’t make sense for every application; however, we’re developing demo projects that demonstrate how to integrate a sequencer for optimistic low latency in your app.
That’s all for now.
When you develop a rollup app, the kernel (basically, the code run by the rollup - think of it as a smart contract written in WASM and excuted off-chain) takes in inputs, computes something, and writes outputs. The inputs are all from the L1, and the outputs are to your rollups persistent storage. A special place in persistent storage is used as the outbox for communicating back to the L1.
Is it possible to get another blogpost about SCORUs that describes various examples/scenarios?
Yes. Me and another SORU dev are working on this. In the meantime, check out https://twitter.com/danhines09/status/1645878625294598145?s=20
I read often that SCORU is superior compared to other Layer 2 solutions (e.g. Arbitrum, Optimism, Polygon). But I would like to know the facts, why is that the case?
I’ll try to tackle this in another blog post. Explaining the comparisons concisely is still a challenge for me. But if you look at the above Twitter thread, and then start digging into https://l2beat.com, you’ll see Smart Rollups excel in many dimensions. We have a lot of polishing to do, but no other solution has what we have. I attribute this directly to our ability to ship upgrades quickly. Enshrined rollups took <2 years to ship to mainnet. I’d love to see a prediction market on when an enshrined rollup EIP hits mainnet on Ethereumm.
That’s all I got for now. Great questions! I can’t express how valuable prompts for information-sharing like this are to the core teams.
