AIP: BOLD - permissionless validation for Arbitrum

Proposals
82

I’m voting FOR on Tally. Infura has a strong track record in the ecosystem and they have already been running successfully for a while, participating in the DAC, so it seems straightforward to continue the process and whitelist them. As for BoLD, I have no concerns; permissionless validation is clearly the way to go.

The only aspect I didn’t like in this proposal, as mentioned in the TG discussion, was the bundling of these two distinct proposals. They should have been presented separately. If quorum is indeed an issue, then we need to discuss how to resolve it.

83

Tally: I voted FOR in this proposal, and the reasoning follows:

BOLD activation: one more step to make Arbitrum more decentralized
Whitelist Infura: They already are running validators and this is an enhancement for the network.

84

I’m voting FOR this proposal. While the technical details can be a bit tricky to follow, I really appreciate the effort put into the FAQ document—it makes things much clearer. Seeing Arbitrum take another step towards deeper decentralization is exciting and sets a strong example for others. Thrilled to support this next chapter!

85

I am voting FOR both proposals bundled in the Tally vote. Arbitrum has established itself as a leader in L2 decentralization, and it is inspiring to witness its continued progress toward becoming the first major Stage 2 Ethereum rollup.

This commitment to decentralization and permissionlessness was a key reason Kleros chose Arbitrum as the foundation for deploying its V2 there. We are excited to see this proposal advance, as it will significantly strengthen Arbitrum’s infrastructure and, by extension, enhance the robustness of the Kleros V2 Court operating on it.

86

gm, voting in favor of both proposals on Tally, consistent with the reasons previously outlined.

87

Voting FOR Activate Arbitrum BoLD + Infura Nova Validator Whitelist

I mean BOLD strengthens security by reducing risks with withdrawals while improving efficiency.

Moreover, opening up to permissionless validators is a good move - it means more people can join, the system becomes more decentralized, and trust grows because no one can control everything :slight_smile:

I don’t know Infura that well, but as I searched they’re a trusted name in blockchain. With them onboard, transactions should stay secure and consistent

88

Voting FOR this proposal.

Adding additional security and censorship resistant capabilities with withdraws is a no-brainer, especially as rollups start to differentiate themselves between fully decentralized and more app-chain like.

Opening to additional validators is also a good move and will hopefully bring more interest into this necessary role as well as new actors to the community.

While going with Infura is fine, we would like to see some additional information on how success on this program will be measured. Is it number of new validators added? Additional information or KPIs. If these can be set out at the start it will make it easier to track the impact of the pgoram and support further expansions of it in the future as needed.

89

Voting for BoLD on Tally, consistent with the reasons previously mentioned in our rationale here AIP: BOLD - permissionless validation for Arbitrum - #51 by mcfly.

90

This Upgrade is another step towards a better future for Arbitrum!!

I think that the Arbitrum BoLD upgrade is a great idea because it makes the network more secure and open to everyone by allowing anyone to help validate without special permissions.

But how will the teams monitoring the upgrade ensure readiness during the restricted execution timeframe?

And how will whitelisting Infura impact the validation and operation of Arbitrum Nova?

91

voting FOR the current onchain proposal because while I disagree with the way the bundling of these 2 different proposals happened, I’m FOR both of them. We should have more reputable validators like the one from Infura, and BoLD will improve our chain.

92

I’m voting FOR on Tally, **because it is important to continue upgrading technology that strengthens the connection between arbritrum one and etherum. The time required for the buffer (2 days) is fair and I like that more validators monitor the network to fortify the security with a decentralized approach.

93

After reviewing the comments and discussion, voting FOR this proposal.

94

Voted For: Overall, I am super happy with the BoLD upgrade. This upgrade will help the Arbitrum chain reach a higher-level Fraud Proof mechanism. This move will help Arbitrum stay in the lead on the list of rollups on the l2beat site. Leading by example here. I support the proposal. Also, I believe we should whitelist Infuras Nova Validator. Infura has been participating with Arbitrum for a long time and I see no reason to not whitelist them.

95

After reading the report over and over again, it is clear to me that the core of the proposal is to upgrade the dispute resolution protocols of Arbitrum One and Nova by adopting the new BOLD protocol to improve decentralisation, security, and optimise the efficiency of validation, and I support this proposal at TALLY for the following reasons:
1. The BOLD protocol significantly improves the decentralisation and security of Arbitrum, which is key to the long-term development of the ecosystem.
2. it reduces potential risks in the implementation of the technology through testnet validation and public auditing.
3. The economic mechanism for verifiers and challengers is well-designed, and the cost for malicious actors is significantly higher. But my personal recommendations:
1. the DAO should oversee the entire implementation process and report progress to the community on a regular basis.
2. set up a clear decentralisation roadmap for Nova, and gradually reduce privilege dependency.
3. Regularly review the effectiveness of BOLD implementation and dynamically adjust the strategy based on feedback.

96

The following 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’re voting FOR the proposal.

We voted in favor of the proposal during temp-check back in June while committing to doing a deep-dive of the proposed upgrade before casting our vote onchain.

After reviewing the executable associated with the proposal, we can confirm that it matches the described upgrade and that no undisclosed changes are taking place. Having said that, we want to highlight the fact that, in the future, there should be some sort of code walk-through for such upgrades.

The upgrade is complex and multifaceted, and it’s difficult even for experienced developers and researchers (such as those on our team) to grasp all the changes. Offchain Labs should provide a code walkthrough for both the executable and the new implementations. We are already happy to commit to helping prepare such a walkthrough for any future upgrade.

As far as the upgrade is concerned, we’d like to point out that the current challenge period for Arbitrum One and Nova is set to 6d 8h because of an incorrect assumption made on pre-PoS block times. In the code, the challenge period is defined in terms of the number of blocks, which currently is set to 45818 blocks. Given the current fixed block time of 12s, this results in a challenge period of less than 7 days. In the near future, we (L2BEAT) will enforce a minimum of 7d for the challenge period in optimistic rollups for the Stage 1 designation.

This upgrade shows that the period is still set to be 6d 8h, which is technically below the requirement. If we use a looser definition of the challenge period and include the “grace period” of 2 days, then the requirement is satisfied (8d 8h). Given that, we expect to see the challenge period back to 7d regardless of the grace period for Stage 2 designation since the Security Council will not be able to act during that timeframe.

Lastly, we want to take the opportunity to raise the question of what happens if Ethereum changes its block times once again. See, for example, EIP-7782. Is there a contingency plan for such a change?

5 Likes
97

I voted in favor of this proposal on Tally. The proposal aligns with Arbitrum’s long-term strategic goals and offers both technical and governance optimizations. Here are my personal views:

  1. I noticed the official replies from the Arbitrum team in the comments, which clearly explained that the BOLD protocol enables permissionless validation, significantly reduces the risk of delay attacks, and improves the efficiency of on-chain dispute resolution. This is an important step for Arbitrum towards full decentralization, which provided me with substantial insights.

  2. The proposal includes a comprehensive audit by Trail of Bits, public testnet deployment, and mathematical safety proofs, ensuring the reliability and security of the BOLD protocol. Additionally, the new protocol enhances Arbitrum’s technical capabilities and competitiveness, while allowing Orbit chains to adopt this technology, benefiting the entire ecosystem.
    Offchain Labs will cover all engineering and audit costs, so the DAO will not incur additional expenses. Moreover, the proposal provides clear implementation steps and timelines, reducing uncertainties during the execution process.

98

I am voting FOR this proposal in Tally. I believe an upgrade such as this one would put Arbitrum a step closer in achieving its roadmap in becoming a Stage 2 rollup. This will increase decentralization and would set Arbitrum apart from other Layer2 solutions that are still not close to this achievement.

After putting in some time to read this proposal and the information on OffchainLabs’ github this upgrade will keep the protocol secure while increasing inclusivity. About the risks outlined in the proposal, I believe that contract bugs and implementation risks are just standard technical hurdles and the fact that BOLD has been running in testnet for a while helps mitigate these problems. The risk of remaining partially centralized in an ecosystem that values decentralization are far greater.

I agree with krst’s point that technical proposals of this scope should ideally include a more detailed walkthrough from the proposers. I’m nonetheless confident in backing BOLD given the extensive testing period and the thorough documentation provided by the team.

Regarding potential block time changes in Ethereum such as the EIP-7782, I’m far from an expert in the matter but a possible solution would be to make the dispute window parameters such as to be upgradeable values instead of constants. This would allow the protocol to adapt to future Ethereum upgrades of this nature.

99

The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.

We are voting FOR this proposal in Tally voting.

Combining the two proposals was a good idea.

As previously mentioned, adding Infura to the whitelisted Node Validator was due, given their record as an Arbitrum validator and their contribution to the Ethereum ecosystem at large.

Hence, we foresee no risks associated with this.

The BoLD upgrade is an achievement we have been striving for since the beginning. Given that due diligence has been performed at the highest level, we feel confident in voting for this upgrade and look forward to seeing all green slices soon. The initial grace period of 2 days is a good starting point, but we believe extending it to 5 days should be considered later.

100

As in @web3citizenxyz representation. Voting FOR in this proposal. Below the rationale:

1 Like
101

I vote FOR this proposal in Tally

Regarding BOLD:

We are now in 2025, the year in which Arbitrum must reach stage 2 of roll-up decentralization.

Since the TGE, Arbitrum has made immense progress toward decentralization, and achieving permissionless validation (meaning allowing proposers and challengers of state assertions) is a fundamental step toward greater security for its users.

Something to note is that I do not have a technical background, so my vote should not be interpreted as an endorsement of having conducted a security check on the code to be implemented. Nevertheless, I base my vote on the trust placed in the excellent team of developers at OCL and the review conducted by highly trusted actors.

Regarding Infura:

Infura is one of the most active infrastructure providers, with an amazing track record. It makes sense to whitelist a Nova validator operated by them.