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

Proposals Finalized AIPs
1

[Non-Constitutional AIP] Front-end interface to force transaction inclusion during sequencer downtime

Abstract

WakeUp Labs proposal outlines the development of a simple but effective front-end interface that enables users to force-include transactions directly on L1 when the Arbitrum Sequencer is down, aiming to increase trust among end-users navigating the Arbitrum ecosystem.

Inspired by a few community discussions (Link 1 & Link 2) , and validated historical events like: Sequencer Downtime 1, Sequener Downtime 2, Historical Sequencer Status and L2BEAT status.
This tool aims to empower users with the ability to bypass the Sequencer in situations where it is unavailable or censoring transactions, thus aligning with Arbitrum’s vision for progressive decentralization.

WakeUp Labs has a proven track record of expertise in crafting blockchain tools and infrastructure. Their contributions extend to collaborating on open-source projects for major DAOs, enhancing Ethereum Foundation-funded initiatives, building complex DeFi protocols, SmartContracts and offering a developer platform that facilitates robust and scalable API calls for smart contract deployment without requiring Solidity programming skills. (Currently operating even on the Arbitrum blockchain).

Introduction

The Arbitrum Sequencer is a critical component of the network, responsible for submitting users’ transactions to L1.

Under the current system, the Sequencer is a potential single point of failure; if compromised, it could delay or prevent the processing of transactions.

There are ways to bypass it, but non-developer users lack that capability.

This proposal seeks to mitigate such risks by providing a user-friendly alternative transaction submission pathway, thereby enhancing the network’s resilience, user autonomy, and their confidence in the Arbitrum ecosystem.

For the service to be truly useful in the event of catastrophic occurrences, empowering more teams to deploy their own instances is crucial. Thus, to boost the project’s reliability and significantly enhance its value to the Arbitrum DAO, it is essential to embrace an OpenSource approach from the beginning.

Rationale

  • Decentralization and user empowerment: By enabling direct L1 transaction submissions, users can circumvent Sequencer outages or censorship, maintaining their ability to transact without interruption. This capability is crucial for ensuring the network’s operational integrity and aligns with the principle of progressive decentralization.
  • Enhancing trustless security: The proposed interface would serve as a valuable tool in rare situations where the Sequencer fails to perform its duties. It ensures that the Arbitrum Rollup maintains its trustless security model, even when permissioned components of the system are not functioning correctly.

WakeUp Labs core team

  • Milton Berman, co-founder and CEO, brings extensive experience as a CTO in a decentralized identity project supported by IDB Lab and Bitcoin NGO. He has also worked as a Product Owner at Rootstock blockchain and as a CTO in a mobile game studio company.
  • Maximiliano del Hoyo, co-founder and CBDO, has a diverse background in software and finance. His previous experience at notable companies like Microsoft and Nestle provides him with the necessary knowledge and network to navigate the intersection of technology and business.
  • Gonzalo Silman, co-founder and COO, possesses a unique blend of expertise in economics (former university professor), finance, and entrepreneurial experience in creating gaming products for LATAM communities.

Proposal Details

Technical Implementation

  1. OpenSource from Day One: Given that the project should be 100% trustless, as clearly outlined in its ‘Rationale’ above, we believe that the entire project, including both the Back-End and Front-End, should be OpenSource from the beginning. One of our goals is for this service to be run from different instances and by different providers; therefore, it will be a top priority to ensure that this repository is well-documented and our support is readily available so that any team or community project can implement it.

  2. Transaction Monitoring: Develop functionality to listen for user transactions on L2 that are not included by the Sequencer, with guidance from the Arbitrum SDK documentation.

  3. Manual Transaction Hash Input: In cases where automatic detection is not feasible, provide a user interface for manually entering the transaction hash or implement manually the previous transaction in the new solution.

    • Step 2 and 3 might not be resolved as outlined in the proposal due to Arbitrum’s specific traits. However, a solution will be proposed and explained in both the technical documentation and the research document from milestone 1.

  4. L1 Transaction Replication: Implement mechanisms to replicate the intended L2 transaction on L1, using “Forced Withdrawal” type transactions to push the L2 transaction from L1.

  5. Confirmation Display: Ensure the interface provides feedback once the transaction has successfully been processed.

  6. Processing Time Consideration: Account for the approximately 24-hour processing period to prevent errors or transaction duplication across chains.

  7. Hosting, Service & Maintenance: WakeUp will host the service, ensuring it runs 24/7, even on IPFS. For the first three months, we will fine-tune and iterate the service. Additionally, should any problems occur, the WakeUp team is committed to identifying and resolving these issues for a minimum of the next two years.

Development Roadmap & Budget Allocation:

  1. Technical Research, POC, Documentation and Testing (4 weeks, $ARB 9000):
    Deep dive into the Delayed Inbox functionality and its integration, along with creating a PoC and validating the necessity of a new internal tool for transaction monitoring and sequencer status. We will also carefully check that our solution doesn’t disrupt the proper functioning of Arbitrum; if it does, we will enable this instance only when the official sequencer is not operating correctly. This research conducted by the WakeUp Team will be made public, and the community will be able to view it, both in a summary Twitter Thread and in an Article shared on the OSS Github repository once completed.
    This document will also consider the security measures that must be taken into account when carrying out the development.

  2. Endpoint Development (1.5 weeks, $ARB 3500):
    Creation of endpoints to interact with the backend logic.

  3. Logic Integration and Testing (2.5 weeks, $ARB 3500):
    Connecting the frontend to the endpoints and verifying the operational logic, and test heavily the MVP.

  4. Design Phase (4 weeks, $ARB 5000):
    Additional time allocated for the design process, ensuring a user-friendly experience.

  5. UI Development (3 weeks, $ARB 5500):
    Crafting an aesthetic and intuitive user interface inspired by existing high-quality designs.
    To enhance user security, we will add a banner at the top of the website to ensure the URL is correct and guard against phishing sites.

  6. Enhancing Documentation Clarity and Usability (3 weeks, $ARB 6000):
    Finalizing and clearly documenting the open-source codebase. As detailed above, any team should be able to run their own instance of the service, so it’s crucial that everything is sufficiently clear. There, we will also add a list of URLs for instances set up by others that we can confirm are correctly implemented.

    • This process will not be linear. Since the project will be OpenSource from the beginning, it may not be sufficiently organized until milestone 6 is reached. This is why significant community contributions, like PRs or entirely new pieces of code, will be more practical after this milestone is completed.

  7. Service & Maintenance after Launch (24 months, $ARB 10000).
    We commit to hosting the site on Vercel or AWS, ensuring 24/7 operation for at least 24 months. Once a stable version has been achieved and properly tested, an instance will also be running on IPFS to ensure a 100% decentralized option. While this may not be the most performant option, it will be available for at least these 2 years. After evaluating its performance, we will attempt to provide it indefinitely. Initially, the WakeUp team will refine the website based on feedback from users and the Arbitrum community and will conduct continuous testing to ensure its reliability. Any issues, such as downtime or crashes, will be promptly addressed by the WakeUp team for at least the next two years.

Budget, Resources and Payment Schedule

  • Estimated Timeframe: Approximately 4.5 months for full implementation, including design phases; followed by 3 months dedicated to post-launch iterations and 24 months of hosting, monitoring, and bug fixing to address any possible error.

  • Development Team: One full-time senior Solidity developer for the core implementation and research, in coordination with the entire WakeUp Labs engineering team, plus additional design and developer resources for the UI/UX phase. The proposal also includes a Senior Developer working part-time for post-launch maintenance.
    Gonzalo or Milton from the core team will also keep track of the project as PO.

  • Payment Schedule & Terms:

    • A payment of 20% of the total grant required will be made on June 1st, as a “Kick off payment”.
    • The remainder of the grant will be vested gradually, on a second-by-second basis, until approximately September (Over 4 months after the kickoff).
    • The security council / The Arbitrum Foundation reserves the right to revoke the payment stream at any moment, to be used in case of unsatisfactory performance.

  • Total Cost: 42.500 $ARB

Conclusion

Developing a front-end interface to enable force-including transactions during Sequencer downtime is a crucial requirement in the Arbitrum ecosystem. This proposal aims to empower users by ensuring transaction capabilities even when the Sequencer is unavailable. By doing so, it aligns with Arbitrum’s goals of decentralization and enhancing user autonomy.

For the solution to be truly useful in critical cases, we must ensure that other projects can run their own instances of this service. This is why the project is conceived as OpenSource from the very beginning, and the WakeUp Labs team will actively assist teams wanting to implement it.

Furthermore, WakeUp will be responsible for maintaining the service operational and implementing minor improvements for a minimum of 2 years.

Notes:

Some changes have been made throughout the proposal; you can see the details here:

11 Likes
2

Hi,
As far as I understand (The Sequencer and Censorship Resistance | Arbitrum Docs), even if the sequencer is not working, it sends data:

Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly 24 hours, as specified by maxTimeVariation.delayBlocks / maxTimeVariation.delaySeconds . A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances

1 Like
3

Hi @cp0x , you’re right about the data transmission during Sequencer downtime.

Arbitrum offers mechanisms for transaction inclusion, but, as you mentioned, they require a 24-hour delay and may cause transaction reordering. Additionally, these mechanisms are intended for technical users.

Our proposal acknowledges these first two issues without altering them.
Instead, we aim to develop a user interface that demystifies and simplifies access to these mechanisms.

This interface will make the forced inclusion process more straightforward and understandable, enhancing Arbitrum’s usability during critical times and strengthening user trust.

1 Like
4

On the other hand, if there’s a concern that this could disrupt the proper functioning of Arbitrum, we could enable it only in instances where the official sequencer is not operating correctly.

1 Like
5

I also think another suggestion should be taken into account:
https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xbecc45a6beb55a708e25195f34db2f5ff757e0da5ff55171ca731b39428e27c3
It introduces a “batch poster manager” role with the ability to grant/revoke batch-posting affordance.

1 Like
6

From what I understand, those changes have been approved.

The first one, regarding the poster manager, is already in the “Develop” branch, while the other is pending to be merged into “Main”.

Thanks for sharing this with us. We should keep these changes in mind, but I believe in our case, it’s all about sending from L1 to L2, regardless of the role in the Sequencer or the MaxTime Variation.

All these technical questions will be resolved when our Tech Lead starts the in-depth technical research necessary for the implementation.

It would be interesting that once Milestone 1 is completed, we could also deliver a clear and consciously crafted document about the technical research conducted.

I think this would contribute to the community, and we could release it in the format of an Article + Twitter Thread to ensure its documentation and attach it to the OSS GitHub once finished.

2 Likes
7

Hey @Gonzacolo, thanks for posting this.

I find the idea of creating a user-friendly tool to bypass the sequencer and force include transactions very valuable for decentralization, similar to what Superchain offers with https://superbridge.app. The costs seem reasonable to me as well.

I am interested in understanding how can we make sure that the tool is available in the future.

  • What happens after the initial 3 months of support?
  • Will the UI remain functional?

Could you elaborate on the long-term options available for the DAO to ensure the tool remains operational and supported

5 Likes
8

@maxlomu,

Indeed, SuperBridge was my point of reference.

The entire project will be open source, including both front-end and back-end components.
With this approach, anyone can offer a similar service if there’s a need.

When crafting the proposal, I envisioned the first three months of support as a period for iterating on the project based on feedback received.

But you are right; I hadn’t considered the need for long-term website operation.

We could turn the last milestone into:

Website Hosting & Maintenance after Launch (24 months, $ARB 10000).

  • We commit to hosting the site on Vercel or AWS, ensuring it runs 24/7 for at least 24 months.
  • During the initial 3 months, the WakeUp team will use feedback from users and the Arbitrum community to refine and iterate the website, continuing to test the system and guaranteeing its functionality for the future.
  • Should any issues arise, such as the website going down, crashes, or other malfunctions, the WakeUp team will address and resolve these issues for at least the next two years.
1 Like
9

I think creating a user friendly interface to force transaction inclusion during sequencer downtime is an important initiative that we should fund as a DAO. I’m in favor of this proposal.

The only gap I see here is that, as far as I can tell, WakeUP Labs is new to the DAO. I would normally like to see a service provider having executed on something successfully for the DAO before being funded for an end-to-end initiative like this. With that said, the cost is relatively low and I’m probably willing to take the leap. Would love to see any examples of relevant past work to help de-risk.

10

We have engaged with the Arbitrum Stack at least, on two separate occasions, though we have not publicly disclosed these projects within the DAO:

  1. Arbitrum has been integrated into our Developer Platform [Dev Environment], enabling users to deploy Smart Contracts effortlessly thanks to our APIs.

  2. We created a certificate collection for attendees of the “Eth Argentina” conference, but it was never launched due to organizational reasons.

Here you can see our Arbitrum owner wallet, and the final SC:

On the other hand, we’ve been actively collaborating with our clients to provide high-tech solutions.
Our projects have included the tokenization of soccer players, the development of APIs for indexing blockchain data, and even an AAVE fork.

Indeed, this project marks our first initiative in creating something specifically designed for Arbitrum. However, we’re enthusiastic about the opportunity to establish a mutually beneficial partnership.

We enjoy a strong reputation within the Argentine community, and last week in Denver, I had the opportunity to meet personally with several members of the Arbitrum DAO and foundation.
I hope this can help to alleviate any concerns you may have.

We’re looking forward to your response and to discussing the next steps.

2 Likes
11

Thanks for sharing examples of past work and connection with the DAO!

1 Like
12

The “Batch Poster Manager” upgrade has already been approved as part of the ArbOS 20 upgrade (it’s scheduled to go live next week).

The Batch Poster Manager is unrelated to what’s being proposed here; the Batch Poster Manager makes it easier for the Sequencer to rotate out its address for a new one; this doesn’t help if the Sequencer is offline or censoring.

The core contracts already have a censorship resistant “force inclusion” path that doesn’t rely on the Sequencer at all; this proposal is about developing a user interface to make this functionality more accessible to users.

2 Likes
13

03/11/2024 - Notes:

Some changes have been made in this proposal, thanks to the feedback provided by @cp0x, @maxlomu and @frisson.

1 Like
14

Hey!

Recently led a team from UC Berkeley at Blockchain at Berkeley to build out a front-end interface to allow transaction submission and inclusion on Arbitrum One from Ethereum!

You can check out the deployed app here:
Arbitrum Bypasser

Arbitrum shouted it out here:
Arbitrum Tweet

Just a prototype though, we used sendL2Message and signL2Message to presign a message and send it to a bridge for it to be received by the Delayed Inbox.

2 Likes
15

Hey @imatomster, it’s indeed an amazing prototype!

I just read the full explanation and saw the website! Congratulations!

My idea is to build a platform that fully aligns with the Arbitrum style and branding, and later incorporate the link to the solution here:

Of course, the website should also include an explanation of how it works.

This idea is all about providing certainty and security to end-users.

I just followed you on Twitter and sent you a message.

If the proposal advances, it would be fantastic to have you on board to receive your feedback and share your experience. It would also be great to take a look at what you have built; our developers would be excited to collaborate.

Having people who have already been involved in similar projects and who understand the motivation behind it, while leaving the entire project open-source and working with a super user-friendly interface, will undoubtedly lead it to success.

1 Like
16

Chiming in here on behalf of the UADP: We think that overall, this is a smart and proper thing to do. The sequencer and network will likely inevitably experience downtime in the future. When this happens, there needs to be some “insurance” in place from a front end perspective to decrease pandemonium and this does exactly that. Additionally, the team has good experience and the cost is very appropriate. Consequently, we see little to no downside in this.

2 Likes
17

This, provided in a way that is user friendly, is a good value add. In time of peril (aka: when everything pumps or dumps) nothing work usually, so alternative routes are needed. Voting for on this proposal.

1 Like
18

Just to clarify,
this development does not affect the Arbitrum code in any way - is this only front-end development for the convenience of users?

19

For something as critical as this in a SHTF scenario, I have mixed feelings about a third party hosting the front end. I am also not sure how a pinned IPFS site would function under heavy load. Wonder if there are other ways of implementing this in a scaleable and trustless manner.

1 Like
20

Hi @cp0x,

As previously stated by other participants in the discussion, the development will not affect the existing functionality of Arbitrum.

In fact, we plan to use the tools and SDKs provided by Offchain Labs to efficiently execute the proposal. We intend to work with this repository:

While this solution is currently available to developers, it remains inaccessible to end-users. Our proposal aims to bridge this gap, making the functionality available to them.

Furthermore, as detailed in the proposal, the document for the first milestone will comprehensively cover all aspects of the technical implementation before we proceed.

1 Like