Was “Arbitrum down” today? Practically speaking, for most users, for ~45 minutes, yes.

But if I want to get nit-picky and pedantic (and you know I do) I could argue that it was not! 🧵
(1/x)

Meet the SequencerInbox.inboxAcc; this little bytes array represents the canonical ordering of all messages that get processed by the Arbitrum chain; once a message gets in there, its result is fully determined i.e., the validators handle the rest.
(2/x)

github.com/OffchainLabs/a…
But okay so how does a message get included? One of two ways; well, actually, three ways. We’ll start with the most common case, case 1: Direct-inclusion by
**The Sequencer**

(3/x)
Meet the Sequencer. The Sequencer is a party with the special right to call addSequencerL2Batch; this puts a batch of messages directly into our friend inboxAcc; you give your Sequencer a message, the sequencer posts it in the inbox, done.
(4/x)
github.com/OffchainLabs/a…
Case 2: “Message from L1 included by the Sequencer.” A message’s journey doesn’t need to begin with a hand-off to the Sequencer; it can also start via an L1 txn — this txn adds a message to the "delayed" inbox (it'll get added to inboxAcc eventually) (5/x) github.com/OffchainLabs/a…
… a common case here being deposits from L1 to L2. The Sequencer will typically push these messages into inboxAcc within 10 minutes or so (see includeDelayedMessages)
(6/x)
github.com/OffchainLabs/a…
The discerning solidity reader, however, will notice that the Sequencer can choose how many of these message to include, and may very well opt to never include any at all! Which brings us to 🥁🥁🥁 case 3: Message from L1 force-included on L2.

(7/x)
If a message has been sitting in the Sequencer’s inbox longer than the maxDelay, *any user* can call forceInclusion, which pops the message out of the delayed inbox and puts it into inboxAcc.

(8/x)
github.com/OffchainLabs/a…
Which is to say: even if the Sequencer completely burst into flames (or something), Arbitrum (via "case 3") can continue to process messages via permissionless L1 txn's — i.e.,with the censorship resistance of L1 😎.

(9/x)
Okay so then what’s the catch? Why did users *experience* ~45 minutes of downtime when the Sequencer went down? Why isn’t everyone just doing this "case 3" thing?

(10/x)
Well, for one, there’s that hand-waved-detail above of the user having to wait for the maxDelay to pass.

Q: "Okay so then why have the delay at all? Why not just let users force-include their txns immediately/ very quickly?"

(11/x)
A: Well, the only (?) point of having a Sequencer at all (arguably) is to offer users the nice UX of fast soft-confirmations on their txns before anything gets published on L1. The Sequencer can do this if it has a short-term view of what will/won't be entering the inbox.
(12/x)
I.e., if the Sequencer delivers Alice a soft-conf receipt, and then Bob can immediately force-include a transaction on chain, the state the Sequencer promised Alice may no longer hold true.
(13/x)
Consider also an L1 reorg: if the reorged state conflicts with the state of force-included transactions, it effectively causes an L2 reorg as well. Again, the sequencer's promise is negated due to no malice on the Sequencer's part.
(14/x)
But also, alas, tooling to publish-on-chain and-force-include a txn isn't available and easy to use at the moment. "Why not?!?" Well, um, we've been busy, and since at this beta-stage we still have trusted guardrails in place anyway, this sort of thing hasn't been a priority.
...but yes — claiming that something is possible in principle, and having smooth, usable, well documented tooling to actually do it are different things. As we progressively decentralize, we plan on closing that gulf. Hold us to it.
(15/x)
...or, better yet still — join and help us get there! We're building cool stuff, and there's still much to be done 🔵

-fin
jobs.lever.co/offchainlabs/

• • •

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

Keep Current with Daniel “Arbitrum has never gone down" Goldman

Daniel “Arbitrum has never gone down

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 @DZack23

14 Sep
Which is faster, Arbitrum or Solana? Today, we find out.
might delete
Harry's obv too busy rn to be on twitter so I'm good
Read 5 tweets
21 Dec 18
I'm generally enthusiastic about the potential for the Lightning Network, but I'm noticing many are fast-forwarding to "LN will solve all of our problems soon!" without understanding the limitations / potential pain-points, temporary or otherwise. Ramble-y thread:
Liveness: in short, if you want to *receive* funds and not just send them, then you need to maintain some degree of internet access; otherwise (for all you know) your funds could be gone. You can mitigate the liveness requirement various ways — i.e., being "live" doesn't ...
... need to entail running a full node, you only have to be live ever-so-often, perhaps planned "breaks" so you can go backpacking, etc. — but unless you trust a third party (watchtower) you can't eliminate the liveness requirement entirely.
Read 20 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!

:(