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

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

posted 2 years ago

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?

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.

Jl_DefiEdge

posted 2 years ago

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?

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.

Gonzacolo

posted 2 years ago

edited 2 years ago

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.

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)

03/27/2024 - Notes, updates and next steps:

The snapshot to signal sentiment was successful, with more than 99M votes in favor and less than 1% against the proposal.

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)

04/18/2024 - Notes:

https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/54?u=gonzacolo

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.

Gonzacolo

posted 2 years ago

edited 2 years ago

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.

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)

03/27/2024 - Notes, updates and next steps:

The snapshot to signal sentiment was successful, with more than 99M votes in favor and less than 1% against the proposal.

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)

04/18/2024 - Notes:

https://forum.arbitrum.foundation/t/tally-front-end-interface-to-force-transaction-inclusion-during-sequencer-downtime/21247/54?u=gonzacolo

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.

krst from delegate.l2beat.eth

10.0M TOKEN

posted 2 years ago

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.

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.

krst from delegate.l2beat.eth

10.0M TOKEN

posted 2 years ago

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.

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.

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.

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

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

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