I actually had the same reserves. But then, I didn’t see a reason why we shouldn’t just have this hosted in several places, which means, starting anywhere is better than not starting at all.
1 Like
I voted for on Snapshot because I think having a user-friendly app for forcing transaction inclusion is important and the proposal is reasonable.
2 Likes
Regarding hosting the site on IPFS, I agree with you. It should indeed be available there, though this alone might not be sufficient. This is where Vercel, AWS, and other services become relevant.
As I’ve mentioned in another comment, the entire project will be open-source, including both the front-end and back-end components. This strategy enables anyone to offer a similar service in a permissionless manner.
For OffChain Labs or the Arbitrum Foundation, it would be significantly easier to assess if our solution is robust enough to be the official one, rather than having to build their own from scratch just to provide the first version of the product.
Nevertheless, I concur with @JoJo that having something is better than nothing.
With all this in mind, we encourage multiple organizations, individuals, and parties to host their versions of this dApp. We will gladly provide support for this task if necessary.
Regarding the proposal, we could introduce an additional milestone:
i. Deploy and maintain an additional IPFS-hosted version of the dApp. This will ensure there’s at least one fully decentralized version of the dApp running indefinitely (we are open to utilizing other protocols, such as Arweave or Fleek).
From our side, we are committed to delivering a solution that meets the demands.
I am confident in my team’s skills and our ability to execute this properly.
2 Likes
Very cool to see thought going into this! I wanted to point out one potential issue in this proposal that might be good to clarify.
Since Arbitrum has no mempool with transactions going directly to the sequencer, it doesn’t seem like there’s a straightforward approach to monitoring transactions not accepted by the sequencer which also limits how well you can support manually entering a hash since the tool wouldn’t have the backing data. Manually providing the transaction data could work, though you’d need to figure out how users would acquire that data.
The UC Berkeley prototype approach of relying on the eth_sign API works though I’m not sure how wide wallet support is and it’s incompatible with existing frontends. I could also imagine a system with some sort of custom RPC that captured transactions as they were submitted that a user could connect their wallet to.
4 Likes
On behalf of the Arbitrum delegates who entrusted their voting power to me and the answers provided by @Gonzacolo, I’m voting FOR the Front-end interface to force transaction inclusion during sequencer downtime proposal at the Snapshot stage.
The cost and timeline are reasonable, the team seems knowledgeable and open to feedback, and the proposal aims to make the “force inclusion” functionality more accessible to users, which is inherently valuable for the Arbitrum ecosystem. Providing a user-friendly interface to ensure transactions are included during sequencer downtime will enhance the user experience and resilience of the network.
Considering these factors, I believe this proposal deserves support at the Snapshot stage.
1 Like
cp0x voted FOR this proposal.
Although I hope that the sequencer will work without failures, this tool will come in handy as a safety net.
1 Like
Hi @Gonzacolo, thanks for the proposal. We believe it’s important to provide a non-developer friendly UI to force transaction inclusions (possibly regardless of sequencer being down or not for less trust assumptions.)
Since the US Berkeley team has already provided a prototype and if they are willing to collaborate with your team, this step would be significantly reduced?
2 Likes
Even though the input from UC Berkeley could potentially reduce the technical research workload, WakeUp needs to complete the first milestone independently to ensure the rest of the project development proceeds smoothly.
However, if the time required to cover this milestone is significantly less, efforts will be redirected towards other tasks aimed at enhancing the proposal.
2 Likes
@hkalodner, thank you for mentioning it.
@0xMilton, my co-founder (who is significantly more technical than I am), is informed about the proposal and has already begun considering different approaches to tackle the challenges.
Nevertheless, we have already initiated contact with Berkeley to exchange viewpoints, and it would be ideal to do the same with you if possible.
1 Like
After considering the proposal and community feedback, we’ve decided to support this because it makes the Arbitrum network easier for everyone to use during sequencer downtimes. We see value in creating a simple way and increasing accessibility for users to keep their transactions going even when there are problems. The community has given great input, and some previous prototypes, e.g., UC Berkeley, could potentially help reduce some of the development efforts.
We’re also wondering, in terms of security, if there’s anything we should worry about, especially with people entering transactions themselves.
1 Like
@Curia, not really, at least not more 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.
Most likely, for the sake of end-user simplicity, we’ll end up “whitelisting” these messages (verifiable on the open source repository), resulting in a simple interface that offers a few but very useful options.
Something similar to SuperBridge, but tailored for Arbitrum.
1 Like
Michigan Blockchain is voting in favor of developing a front-end interface to maintain transaction continuity in case of the sequencer failure. We think this aligns well with providing uninterrupted transaction access as well as ensuring transparency through the open-source approach. We hope that this transaction interface upholds the security measures of the sequencer including fraud proofs and economic penalties for malicious actors, ultimately ensuring the same functionality as the original sequencer.
2 Likes
I have to confess that I initially contemplated refraining from responding to this proposal.
However, by analyzing and asking for feedback here and there, I now understand the importance of having infra UI/UX so that we can better understand Arbitrum’s internal processes, such as sequencers.
In favor of decentralization, the existence of service providers seeking to solve these pains is valuable.
I genuinely don’t know if this is the best mechanism, but the reason why I vote IN FAVOR is because at this moment we are in a standby of resources or grants (DDA soon to be sent on chain, PL in process, etc).
I would love to understand why this proposal did not pass through the foundation in the first place, as a learning experience. However, interesting to see the execution of this project.
2 Likes
I will be voting “For” this proposal on Tally.
As a broad concept, making this functionality more accessible to users will be a useful tool as a backup plan in the event of sequencer downtime. So I am glad to see this being taken on by a team.
Initial concerns I had when reading the post seem to have been asked and addressed by other users. Probably my largest being if this type of risk extends past those who interact with the contract. With that being addressed here & here, I am comfortable with the project as pressent. Things such as ongoing support being factored into the ARB ask are nice additions too - the flexibility of the proposing team is appreciated.
The team looks to have a good technical background and the request amt / the timeline both look reasonable as well. So no issues there.
Probably my only thought for improvement would be if there was a milestone attached to funding. It could be as simple as the initial 35k is paid out now and the 10k service & maintenance fee is paid once the project is completed. Given the relative amount asked I don’t see a huge issue to the point I wouldn’t approve regardless, but I think it’s worth bringing up now at the Snapshot stage as a discussion point.
Edit: Updating (5.21.2024) here to save forum space. My opinion has remained unchanged of the above since the snapshot vote. I have voted “For” Tally, and look forward to seeing the end product.
2 Likes
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
Actually, I think it’s essential that third parties (not one, but many, under different jurisdictions, infrastructure providers, etc.) host such frontends. One of the use cases for this frontend is when the main provider is trying to censor you (for example, because of a court order that requires them to censor a certain group of people), in that case it’s necessary to have independent providers serving this.
4 Likes
@bob-rossi, thank you for your support.
From our side, there are no issues with receiving the $10,000 in ARB tied to the final milestone once all prior deliverables have been successfully completed. This arrangement could serve as a solid incentive to ensure the proper completion, and ultimately, it won’t affect our plans; we have no intention of spending the funds prematurely.
I’m not entirely familiar with the process after Tally. If you could provide some guidance on this aspect, we would be more than willing to revise the proposal accordingly before its on-chain submission.
2 Likes
I’m not entirely familiar with the process after Tally. If you could provide some guidance on this aspect, we would be more than willing to revise the proposal accordingly before its on-chain submission.
To be 100% honest, operationally I couldn’t tell you the actual step-by-step to have the funding come in milestones. To the point any guesses I’d have would probably do more harm then good 
. So I’ll defer to others.
2 Likes
Voting FOR this proposal, already expressed my opinion here.
As we are committing 10k ARB for long term support I would like, after launch, to set up some follow up initiatives to further diversify the front ends as other have mentioned.
2 Likes
The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.
2 Likes