I just saw A LOT of excitement about fast confirmations on newly deployed @Uniswap on @optimismPBC , but how does it really work, and can users trust them? Finally, isn't a single sequencer that provides such confirmations a threat to decentralization? Let's talk it through👇👇👇
2/ First, things first — sequencers are privileged actors in many rollup systems (@optimismPBC , @arbitrum, @StarkWareLtd , @zksync ). They receive transactions from users, order them and submit them in batches to L1.
3/ The main reason why they exist is the simplicity and efficiency of having a single coordinator. At this stage, there is usually a single sequencer per rollup, and it's run by the creators of a rollup.
4/ A sequencer is a single actor responsible for ordering txs. Thanks to this, after receiving a user's tx, a sequencer can instantly mine it and send an instant confirmation back to the user. This dramatically improves UX.
5/ If you're worried that sequencers can do arbitrary MEV then you're absolutely right but I leave this topic to a separate discussion (we are gonna touch this at the end)... Don't tell @EdgarArout 😏
6/ It's all great when a "good guy" sequencer is an honest actor but what if the sequencer goes rogue, lying to the users and trying to break the network? Let's dive deeper🤿
7/ Most important question: can sequencer steal users' funds? Short answer: NO. Validity of state transition is ensured by a rollup architecture (fraud proofs in optimistic rollups or validity proofs in zkrollups).
8/ Can it censor user txs? - Yes, actually it can. A sequencer is usually a JSON RPC node. Similar to Infura, it can even lie about the state of the network or censor users tx.
9/ Luckily censorship is not a huge problem as all rollup systems have a way to post L2 tx via uncensorable L1. The protocol then forces the sequencer to include the user's tx into a rollup within few minutes.
10/ If sequencer lies about the state, users would need to run their own nodes recreating the rollup state based on batches posted to L1. This might sound bad but it's actually the same situation as on L1 🤷‍♂️
11/ Finally, can sequencer lie about instant confirmation? Yes, as mentioned before, the sequencer can lie about the current network state and about the inclusion of the user's tx.
12/ For example, sequencer could reply back to the user that their trade was successful but in a reality it reverted (or the other way around). The user would only realize this after recreating the rollup state from L1.
13/ A rollup tx is not finalized until it's posted on L1. That's why web3 libs for rollups usually allow devs to easily build UIs so they wait until tx is mined on L1.
14/ Future solutions to this problem can involve sequencer signing a confirmation of receiving user's tx. If tx wouldn't end up in a rollup user could slash the sequencer. This could be automated by watchtower-like services.
15/ You see this is what's really excites me about this -- it's only the beginning for sequencer tech. In the near future, we will see more sophisticated designs that solve a lot of problems that I've just mentioned.
16/ Instead of running a single permissioned sequencer, we can run a whole permissionless PoS network of sequencers. Each L1 batch would be created by a randomized sequencer from a bigger set. This would make resilience and censorship resistance much better.
17/ Of course, each sequencer would need to post some kind of bond so it can be slashed when it misbehaves.
18/ Other projects like @arbitrum, experiment with a fair protocol that tries to discover the “true” ordering of txs. eprint.iacr.org/2020/269.pdf

h/t @sgoldfed
19/ Instead of fighting MEV, it can be embraced by MEV auctions where parties bid against each other to be able to run a sequencer for some time (but this idea has some problems).
20/ You can read a little bit more about design space for rollups in @VitalikButerin's article on rollups: vitalik.ca/general/2021/0… ("Who can submit a batch?" section)
21/ To sum up, IMO sequencers strike the right balance between decentralization and speed. What we see now is basically just an MVP of sequencer tech and a lot of smart people work hard on improving it 💡 Future looks bright!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kris Kaczor 🦆

Kris Kaczor 🦆 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @krzKaczor

21 May
1/ It's high time for @optimismPBC vs @arbitrum. I know you've been waiting for it so let's go!🔥🔥🔥

Long 🧵 Image
2/ Let me start with similarities, they both:

• are rollups ie. real L2s and they store all txs on L1
• are optimistic meaning they use fraud proofs
3/
• use sequencers for instant "finality"
• have generic cross-chain messaging allowing creation of advanced token bridges like @MakerDAO's fast withdrawal bridge: forum.makerdao.com/t/announcing-t…
Read 21 tweets
9 May
TypeChain v5 is finally here!🔥

👉Incremental generation and typed getContractFactory (!) with @HardhatHQ
👉No more index signature for @ethersproject - catches more mistakes early
👉By default doesn't generate overloads when not needed - less clutter

github.com/ethereum-ts/Ty…
I also couldn't help myself from adding a readme section with current users of TypeChain. All these awesome companies/protocols (and many others!) use TC: @MakerDAO (duh), @Uniswap, @AaveAave, @optimismPBC, and @zksync.
Browse full changelog at: github.com/ethereum-ts/Ty…
Read 4 tweets
4 May
A really cool deep dive into zkEVM by @gluk64 :

One of the interesting things is that zkEVM takes YUL as input and uses LLVM to generate the bytecode of the circuit. This means few things: 👇
First of all, the @zksync team didn't have to reimplement the whole solc but rather write only the LLVM backend. While this for sure is still not a trivial task, it makes bug surface smaller and toolchain audits easier.
Smart contracts written in other languages like Vyper or YUL+ can be ported to zkEVM too.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(