Front-end interface to force transaction inclusion during sequencer downtime
[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 exceptional 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. With a background in working with large corporations, Milton possesses the technical expertise and strategic vision necessary to drive the success of our project.
- 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, ensuring the effective achievement of the project’s goals.
- 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. This diverse background brings a fresh perspective and innovative thinking to our project, enabling us to understand user needs and craft tailored solutions that resonate with our target audience.
Proposal Details
Technical Implementation
- 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.
- 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.
- 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.
- 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.
- Confirmation Display: Ensure the interface provides feedback once the transaction has successfully been processed.
- Processing Time Consideration: Account for the approximately 24-hour processing period to prevent errors or transaction duplication across chains.
- 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:
- 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.
- Endpoint Development (1.5 weeks, $ARB 3500):
Creation of endpoints to interact with the backend logic.
- 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.
- Design Phase (4 weeks, $ARB 5000):
Additional time allocated for the design process, ensuring a user-friendly experience.
- 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.
- 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.
- 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: Tally: Front-end interface to force transaction inclusion during sequencer downtime Proposals
OpenZeppelin did a security analysis of this proposal here: https://forum.arbitrum.foundation/t/security-analysis-of-using-hedgey-for-proposal-payment-vesting/23780
