Tally: Front-end interface to force transaction inclusion during sequencer downtime

The below response reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

We are voting FOR this proposal in the temperature check.

We believe that the ability to force include transactions that bypass the sequencer is essential to maintaining the permissionless and censorship-resistant nature of rollups. Moreover, this ability is essential to ensure that the funds we hold on L2s are truly secured by Ethereum L1, as this very functionality allows users to withdraw their assets regardless of whether the original project tries to censor them or even ceases to exist.

While Arbitrum’s internal mechanisms maintain the technical possibility, they are not accessible to most users who don’t have the technical capacity to use them. This proposal aims to bridge this gap and provides an easy-to-use interface for people to use in case of emergency. We are fully supportive of such an initiative and are open to contributing to it.

Here are some non-blocking remarks we’d like the proposer to take into consideration:

  • The Arbitrum community needs to be involved in this proposal’s scoping and design phase. Therefore it might be useful to extend the time for this phase (3 weeks in the proposal) to allow community members enough time and space to provide their insights and feedback. In-between community calls to discuss possible approaches would be appreciated.
  • This mechanism needs to be easily deployable by different entities so that we can end up with several backup deployments as in a case of emergency single deployments are likely to be heavily overloaded. However, it is crucial to consider security as well, as it will be an easy target for malicious actors to spawn their own malicious copies of such a frontend to steal users’ funds. It’s important to provide users with ways to ensure they’re using a proper tool.
  • While we appreciate that the code is already intended to be open source, we believe that it should be built in the open from the start, rather than just be open-sourced at the end (which is step 7 in the current plan), so that the project is more likely to attract external contributors and others can review it along the way
  • On a final note, it might be a good idea for any such a proposal to have the payment split into tranches released by multisig. So that some amount is paid out upfront and the rest is paid upon completion of specific milestones.

To wrap up - we find this proposal valuable, will be voting for it, and hope to see it implemented soon.

4 Likes