Rationale
Back in December we asked for devs interested in pushing this initiative forward since it’s something we always say users can do on arbitrum, but in reality, it’s not the case since we don’t have a user-friendly frontend to force transaction inclusion during sequencer downtime. WakeUp Labs answered this call and we’re very excited to see it finally taking shape. As a delegate, I think the DAO should support devs more and encourage them to build on arbitrum.
One thing I think will be crucial in executing this proposal is ensuring good communication between the DAO and WakeUp Labs. Apart from this, we agree with @krst’s statement that this should be OS from the start. We’re down to help with anything that might be needed and are excited to see further developments.
The Princeton Blockchain Club is voting in favor of this proposal.
We believe that having an accessible way to force-include transactions on L1 deserves funding and further attention. If the sequencer if misbehaving (due to legal threats, a hack, etc), it’s important that users have a trustless alternative. Although we’ve had the capability to do this for a while, it’s not too useful if only a few skilled developers/researchers can feasibly bypass the sequencer.
We liked @imatomster and the rest of Blockchain at Berkeley’s prototype, and hopefully some further collaboration can happen there. As other delegates have mentioned, please consider open-sourcing the project relatively early in the development cycle - building in the open should prove helpful for your team and the community.
Having a multisig pay out depending on what milestones are reached would be nice to have as well. (The ask is relatively low though, so that might not be worth the effort)
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal
We Abstained from this proposal vote on Snapshot.
As a web3 gaming DAO this proposal’s focus is not our domain of expertise. For that reason, we are keen to follow the lead of other more technical minded delegate as they evaluate the need, value and pricing of proposals such as this.
We would also encourage small-medium sized prospective DAO service providers to utilize existing grants frameworks such as Questbook, Plurality Labs where possible. This would allow relevant subject matter experts to evaluate the merits of a proposal and make funding decisions accordingly.
Considering today is April 1st, and taking into account that we have been publicly working on the proposal since at least mid-February, engaging in discussions with community members in person at EthDenver, through L2 Beat’s office hours, and in Arbitrum’s public debates, I am convinced we are prepared to move forward with the final steps.
The proposal will transition to its definitive version. Alongside changing the title, the notes will be removed and listed below this point to maintain a historical record.
03/11/2024 - Notes:
Some changes have been made in this proposal, thanks to the feedback provided by @cp0x, @maxlomu and @frisson.
03/19/2024 - Notes #1:
I made some minor fixes and added a few sentences in the last milestone to provide also a service instance on IPFS. The idea was provided by @dk3.
03/19/2024 - Notes #2:
I have slightly extended the duration of Milestones 1 and 3, given the proposal’s significance. It makes sense to present it to more community members or even in community calls to receive feedback. Consequently, the overall deadlines have also been adjusted.
I have clarified how the project’s open-source aspects will be managed, as they had not been clear previously.
Thanks to feedback provided by L2BEAT’s governance team. (cc: @krst)
I emphasized the importance of the project being open source from the start, following feedback from several governance participants.
I highlighted the importance of enabling other projects to deploy their own instances of this service, a consideration I had overlooked before.
Following community feedback, I improved the proposal’s wording, syntax, and added necessary clarifications. (cc: @hkalodner)
I am in discussions with the Tally team to devise a suitable payment distribution strategy for the project.
In the next few days, I’ll:
[DONE] - Summarize the proposal’s changes in a particular comment, and provide a “final” version of the proposal.
[DONE] - Outline a payment schedule aligned with Tally’s capabilities.
[DONE] - Schedule an open call with the community, hosted by WakeUp, to discuss the proposal one last time.
[DONE] - Set a new deadline to provide feedback.
[DONE] - Determine the Tally’s submission date. [05/15/2024]
04/01/2024 - Notes
Throughout the weekend, the Tally team assisted me in setting up the draft in Tally, along with its corresponding payment schedule, based on the platform’s available options.
Finally, we decided that, should the Proposal be approved:
A payment of 20% of the total grant required will be made on May 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.
These conditions are much more aligned with the powers of the foundation, and also with the feedback received in the forum.
04/05/2024 - Notes:
I added two features to the proposal to reduce security risks:
A banner at the top of the website to verify that the URL is correct and not a phishing site.
In the public GitHub, we will clarify the URLs of the projects we confirm are correctly implemented. (Like a white list)
An Open Call will be offered to discuss the Proposal described above. It will be hosted in a Google Meet session by WakeUp Labs, and the recording will be available on the WakeUp channel on YouTube.
The objective is to explain the proposal one more time, answer questions, and provide an open space for discussion on a particular topic for the last time.
The session will last 20 minutes (10’ for explanation and 10’ for questions, extending if necessary).
The session will take place on Wednesday, 04/03/2024, at 16:00 UTC.
You should be able to schedule the call by clicking: here
Open Call - Discussion & Explanation of Proposal - Arbitrum <> WakeUp Labs
Wednesday, April 3 · 6:00 – 6:30pm
Time zone: Europe/Madrid
Video call link: https://meet.google.com/bvz-njro-spw
Once the Open Call session has been conducted, and some tasks on the Tally team’s side completed, the on-chain publication of the application on Tally will proceed.
I do not want to conclude without expressing my gratitude to all the Delegates and community members for their feedback and overwhelming support.
It’s important that we continue to receive any comments or feedback even now, to ensure we arrive at a final proposal that is robust and in alignment with the interests and concerns of the community.
Thank you very much again for your support and oversight throughout this process.
Thank you for the comprehensive proposal to enhance transaction inclusion during a possible Arbitrum Sequencer downtime. Your dedication to OpenSource principles and commitment to long-term maintenance are commendable. However, I have a few questions to ensure a thorough understanding of the project’s scope and implications:
Given the critical nature of the proposed interface, how do you plan to address potential security vulnerabilities and ensure the integrity of transactions processed during Sequencer downtime?
Could you elaborate on the mechanisms to prevent abuse or misuse of the interface, particularly in situations where users attempt to force-include transactions for nefarious purposes?
As the service relies on hosting and maintenance for its operational continuity, what measures are in place to guarantee uninterrupted service availability, especially during Network congestion or unexpected technical challenges?
Your insights into these aspects would provide valuable clarity. I am looking forward to your response.
In principle, there are no more risks than being a regular crypto user. When you force-include transactions, you’re essentially sending a message to Layer 2 by bypassing the sequencer, that’s all. This method is mainly used for withdrawing ETH or tokens via a bridge, though any message can be sent this way. The risk should only be associated with the contract with which that message interacts.
In crypto, malicious agents exist. What one of these players could do is take our front-end and create a replica that interacts with other contracts. From the public GitHub, we can clarify which URLs of the projects we confirm are correctly implemented. Additionally, we can add a banner at the top of the website to verify that the URL is correct and not a phishing site, as is often done with other dapps.
(In fact, they are very good ideas; I will formally add them to the proposal.)
We will host our service on AWS, with the corresponding dedication to ensure it performs correctly. Almost everything is running on AWS, so critical failures would affect more than just us. Furthermore, we will offer an instance on IPFS, as some users recommended in the forum. Another important particularity, strongly supported by the L2 beat team, is that for the service to be truly useful in the event of catastrophic occurrences, empowering more teams to deploy their own instances is crucial. That’s why from the WakeUp side, we will help other teams and individuals to launch their own instance of the service.
I voted for in this proposal in Temp Check. I think the cost and budget make sense in the context of having a front end to force enable txns in case of sequencer problems. I think it will be useful especially for sufficient non-technical users that might be affected in a potential scenario. I also like the idea of open sourcing the project.
For Arbitrum (and L2s in general) to be ready for mainstream adoption, a user-friendly interface to force include a transaction to Ethereum mainnet is a requirement in the event of sequencer downtime. To remain competitive with other ecosystems, Arbitrum should have its own canonical interface (see: https://superbridge.app/ as referenced by @maxlomu).
The budget seems reasonable given the work being performed and the criticality of the service, but we also agree with @krst’s remarks on the need to build open source from the start and for the payments to be milestone-based with a reasonable upfront payment. We have no reservations on a third party hosting this interface and believe its likely that once this is live, multiple instances will be stood up for redundancy.
As the grant is revocable and will be vested gradually, it involves using new contracts integrated into the Tally platform. Because of this, next week we will speak with the OZ team to review the process and ensure there are no risks!
In our proposal, we have defined a payment mechanism based on feedback from forum participants:
A payment of 20% of the total grant will be made on May 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, should the performance be unsatisfactory.
This is only possible through the use of “new” contracts developed by Hedgey and implemented on the Tally platform.
Since this is the first time these mechanisms will be used to facilitate governance processes in Arbitrum and they interact with the DAO’s funds, they will undergo an audit by the OpenZeppelin team.
Because of this, the payment schedule, as well as the kickoff date, will be postponed by one month.
Despite this, we are very excited that these new mechanisms, already tested, audited, and implemented, allow for greater flexibility for everyone who will submit proposals in the future.
We will announce the results of the audit and notify you through this medium when the proposal is live on Tally.
OpenZeppelin, as the Security Member of the ARDC, was asked to review the draft proposal using Hedgey for payment streaming. We completed our analysis and posted the deliverable in the ARDC forum which you can find here.
Overall, we believe the proposal will execute successfully and meets the security expectations of the proposer and delegates. We encourage delegates to read our full analysis for more details.
I decided to vote (on chain) in FAVOR of this proposal.
Initially, I was unsure about the proposal due to my lack of understanding of its functionality. However, after taking the time to review it and considering the ARDC forum’s analysis by OpenZeppelin, I recognize the significant value in having access to explanations or translations of such technical proposals.
It is crucial to have initiatives that allow more users to mitigate potential risks or centralization points within the ecosystem.
I would love to understand more about the execution process and how this tool will be extended to reach a wider audience and be optimally utilized.
Glad this proposal made it to Tally, I will be voting “For”.
It’s important to increase accessibility for non-developers to mainnet tx inclusion during sequencer downtime. Will the website be hosted on both IPFS and third-party services in the end?