This AIP introduces a number of improvements to Arbitrum chains, including support for the EVM Shanghai upgrade and the PUSH0 opcode, along with miscellaneous bug fixes. These improvements are now audited and ready for adoption, including by Arbitrum Orbit chains, Arbitrum One, and Arbitrum Nova. This proposal concerns the latter two, as they are governed by the Arbitrum DAO. On a high level an ArbOS upgrade can be seen as Arbitrum's equivalent of a hardfork - more can be read about the subject over in https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695
Recent versions of go-ethereum already includes support for the changes to the EVM made in the Shanghai L1 upgrade, but we need to enable them for Arbitrum chains. Instead of using a time based activation, it’s better to activate support based on the ArbOS version, which makes sure that even if the upgrade is delayed, Shanghai support will take effect uniformly and without causing divergences with out of date node software.
PRs:
https://github.com/OffchainLabs/nitro/pull/1583
https://github.com/OffchainLabs/nitro/pull/1664
https://github.com/OffchainLabs/nitro/pull/1712
Retryable fees previously always used the network fee account, instead of also using the infrastructure fee account. The infrastructure fee account should be paid fees from the basefee, and the network fee account should be paid any surplus fees when the gas price is elevated. That was correctly implemented for normal transactions, but retryables only dealt with the network fee account. Retryable redemption also reported an incorrect gas usage in the block header. This matters to Arbitrum Nova, where the infrastructure fee account pays out some fees to the Data Availability Committee members, but the network fee account does not.
PRs: https://github.com/OffchainLabs/nitro/pull/1789 https://github.com/OffchainLabs/nitro/pull/1980
This change doesn’t affect the actual chain owner set, but the list being returned by the ArbOwnerPublic precompile was incorrect for Arbitrum Nova due to an internal ArbOS issue. To be clear, this does not affect who was able to make chain owner actions. As intended, only the DAO is able to make chain owner actions on Arbitrum One and Arbitrum Nova. This change only affects the list of chain owners presented by the ArbOwnerPublic precompile.
PRs: https://github.com/OffchainLabs/nitro/pull/1525 https://github.com/OffchainLabs/nitro/pull/1768
Some precompile methods such as ArbSys’s arbBlockHash method took up all gas when reverting. That meant that if a transaction called arbBlockHash with an out-of-range block number, it’d use up all the gas when reverting.
PR: https://github.com/OffchainLabs/nitro/pull/1490
The L1RewardReceipient and L1RewardRate were previously not exposed via precompiles. This change adds methods to get them to ArbGasInfo so that the current chain configuration can be easily checked.
PR: https://github.com/OffchainLabs/nitro/pull/1775
This shouldn’t matter in practice, but it was theoretically for a staticcall from the chain owner to the ArbOwner precompile to emit a log. In the EVM, staticcalls should never be able to emit logs. This PR fixes the Arbitrum precompile logic to disallow emitting logs in staticcall contexts.
PR: https://github.com/OffchainLabs/nitro/pull/1562
This shouldn’t matter for Arbitrum One and Arbitrum Nova, because these parameters were already corrected in AIP-7. However, it’s included in ArbOS version 11 so that any Arbitrum Orbit chains automatically get the correct parameters.
PR: https://github.com/OffchainLabs/nitro/pull/1549
The canonical version of ArbOS 11 this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash df93361a1293574903f28fbbbe0469a3ea5c644d
That commit builds a WASM module root of 0xf4389b835497a910d7ba3ebfb77aa93da985634f3c052de1290360635be40c4a, which is a hash of the code that’s put on-chain for fraud proofs. You can verify this WASM module root on a x86_64 computer (i.e. not on ARM which builds slightly different symbol names) with Docker setup by checking out the previously mentioned commit of the nitro repository, running git submodule update --init --recursive, and then running docker build . --target module-root-calc --tag wavm-machine && docker run --rm wavm-machine cat /workspace/target/machines/latest/module-root.txt This uses Docker to perform a reproducible build of the WebAssembly code used in fraud proofs, and outputs its hash.
The above code has audited by Trail of Bits - the audit report can be viewed in https://drive.google.com/file/d/1uwA1PK3AB9ggHMqaw91mubu5WHcEp398/view?usp=sharing
The Action smart contracts used to execute the on-chain upgrade can be viewed in
https://github.com/ArbitrumFoundation/governance/pull/170
Action contract addresses: SetArbOneArbOS11ModuleRootAction SetNovaArbOS11ModuleRootAction SetArbOS11VersionAction SetArbOS11VersionAction
The above code has audited by Trail of Bits - the audit report can be viewed in https://drive.google.com/file/d/1N3197Z7DuqBpu9qdt-GWPewe8HQakfLY/view?usp=sharing
The current ArbOS version used on Arbitrum One and Arbitrum Nova is ArbOS 10, corresponding to the Arbitrum Nitro consensus-v10 git tag. You can verify this by running the previously mentioned steps to build the WASM module root on that git tag, which produces the WASM module root 0x6b94a7fc388fd8ef3def759297828dc311761e88d8179c7ee8d3887dc554f3c3, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
To audit the code difference from ArbOS 10 to ArbOS 11, you could simple generate a full nitro diff with git diff consensus-v10 df93361a1293574903f28fbbbe0469a3ea5c644d (and also generate a diff of the go-ethereum submodule mentioned in that nitro diff). However, that includes a lot of code that isn’t part of the WASM module root. To filter down to just the replay binary which defines the state transition function, you can start by generating a list of files in the nitro and go-ethereum repositories included by the replay binary in either ArbOS 10 or ArbOS 11 with bash:
#!/usr/bin/env bash
set -e
mkdir -p ~/tmp # this script uses ~/tmp as scratch space and output
# this script should be run in the nitro repository
git checkout df93361a1293574903f28fbbbe0469a3ea5c644d
git submodule update --init --recursive
make solgen
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/offchainlabs/nitro/' | sed '[email protected]/offchainlabs/nitro/@@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v11-nitro-files.txt
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/ethereum/go-ethereum/' | sed '[email protected]/ethereum/go-ethereum/@go-ethereum/@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v11-geth-files.txt
rm -r contracts
git checkout consensus-v10
git submodule update --init --recursive
make solgen
rm -r blockscout
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/offchainlabs/nitro/' | sed '[email protected]/offchainlabs/nitro/@@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v10-nitro-files.txt
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/ethereum/go-ethereum/' | sed '[email protected]/ethereum/go-ethereum/@go-ethereum/@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v10-geth-files.txt
sort -u ~/tmp/consensus-v10-nitro-files.txt ~/tmp/consensus-v11-nitro-files.txt > ~/tmp/replay-binary-nitro-dependencies.txt
sort -u ~/tmp/consensus-v10-geth-files.txt ~/tmp/consensus-v11-geth-files.txt | sed 's@^[./]*go-ethereum/@@' > ~/tmp/replay-binary-geth-dependencies.txt
Now, ~/tmp/replay-binary-dependencies.txt contains a list of dependencies of the replay binary that were present in ArbOS 10 or 11. To use that to generate a smaller diff of the nitro repository, you can run:
git diff consensus-v10 df93361a1293574903f28fbbbe0469a3ea5c644d -- cmd/replay $(cat ~/tmp/replay-binary-nitro-dependencies.txt)
For the go-ethereum submodule, you can first find out what go-ethereum commit ArbOS 10 and 11 used:
$ git ls-tree consensus-v10 go-ethereum 128 ↵
160000 commit 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 go-ethereum
$ git ls-tree df93361a1293574903f28fbbbe0469a3ea5c644d go-ethereum
160000 commit abe584818e104dd5b4fdb8f60381a14eede896de go-ethereum
Those commit hashes are the go-ethereum commit hashes pinned by each nitro commit. Then, you can again use git diff and the files generated by the earlier script to generate a diff limited to code used by the replay binary:
# this should be run inside the go-ethereum submodule folder
git diff 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt)
This diff also includes the diff between upstream go-ethereum versions v1.10.25 and v1.11.6, as ArbOS 10 used the former and ArbOS 11 uses the latter. To filter out that difference, you can use this tool to find the intersection of two git diffs: https://gist.github.com/PlasmaPower/795af590f88cfb5e21c5ad9b8a32afdf
We can use that to find the intersection of the diff of ArbOS 11’s go-ethereum against ArbOS 10’s go-ethereum and the diff of ArbOS 11’s go-etheruem against upstream go-ethereum v1.11.6:
# this should be run inside the go-ethereum submodule folder
git diff 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-10-vs-11-geth.diff
git diff v1.11.6 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-11-vs-upstream-geth.diff
diff-intersection.py ~/tmp/arbos-10-vs-11-geth.diff ~/tmp/arbos-11-vs-upstream-geth.diff
In addition, you can pass the following arguments to diff-intersection.py to ignore files that are included by the replay binary but whose components are not used: --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'
Note that by default, diff-intersection.py does a line based intersection. To instead do an intersection based on chunks in the diff, known as hunks in git terminology, you can add the --only-hunks flag.
This AIP introduces a number of improvements to Arbitrum chains, including support for the EVM Shanghai upgrade and the PUSH0 opcode, along with miscellaneous bug fixes. These improvements are now audited and ready for adoption, including by Arbitrum Orbit chains, Arbitrum One, and Arbitrum Nova. This proposal concerns the latter two, as they are governed by the Arbitrum DAO. On a high level an ArbOS upgrade can be seen as Arbitrum's equivalent of a hardfork - more can be read about the subject over in https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695
Recent versions of go-ethereum already includes support for the changes to the EVM made in the Shanghai L1 upgrade, but we need to enable them for Arbitrum chains. Instead of using a time based activation, it’s better to activate support based on the ArbOS version, which makes sure that even if the upgrade is delayed, Shanghai support will take effect uniformly and without causing divergences with out of date node software.
PRs:
https://github.com/OffchainLabs/nitro/pull/1583
https://github.com/OffchainLabs/nitro/pull/1664
https://github.com/OffchainLabs/nitro/pull/1712
Retryable fees previously always used the network fee account, instead of also using the infrastructure fee account. The infrastructure fee account should be paid fees from the basefee, and the network fee account should be paid any surplus fees when the gas price is elevated. That was correctly implemented for normal transactions, but retryables only dealt with the network fee account. Retryable redemption also reported an incorrect gas usage in the block header. This matters to Arbitrum Nova, where the infrastructure fee account pays out some fees to the Data Availability Committee members, but the network fee account does not.
PRs: https://github.com/OffchainLabs/nitro/pull/1789 https://github.com/OffchainLabs/nitro/pull/1980
This change doesn’t affect the actual chain owner set, but the list being returned by the ArbOwnerPublic precompile was incorrect for Arbitrum Nova due to an internal ArbOS issue. To be clear, this does not affect who was able to make chain owner actions. As intended, only the DAO is able to make chain owner actions on Arbitrum One and Arbitrum Nova. This change only affects the list of chain owners presented by the ArbOwnerPublic precompile.
PRs: https://github.com/OffchainLabs/nitro/pull/1525 https://github.com/OffchainLabs/nitro/pull/1768
Some precompile methods such as ArbSys’s arbBlockHash method took up all gas when reverting. That meant that if a transaction called arbBlockHash with an out-of-range block number, it’d use up all the gas when reverting.
PR: https://github.com/OffchainLabs/nitro/pull/1490
The L1RewardReceipient and L1RewardRate were previously not exposed via precompiles. This change adds methods to get them to ArbGasInfo so that the current chain configuration can be easily checked.
PR: https://github.com/OffchainLabs/nitro/pull/1775
This shouldn’t matter in practice, but it was theoretically for a staticcall from the chain owner to the ArbOwner precompile to emit a log. In the EVM, staticcalls should never be able to emit logs. This PR fixes the Arbitrum precompile logic to disallow emitting logs in staticcall contexts.
PR: https://github.com/OffchainLabs/nitro/pull/1562
This shouldn’t matter for Arbitrum One and Arbitrum Nova, because these parameters were already corrected in AIP-7. However, it’s included in ArbOS version 11 so that any Arbitrum Orbit chains automatically get the correct parameters.
PR: https://github.com/OffchainLabs/nitro/pull/1549
The canonical version of ArbOS 11 this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash df93361a1293574903f28fbbbe0469a3ea5c644d
That commit builds a WASM module root of 0xf4389b835497a910d7ba3ebfb77aa93da985634f3c052de1290360635be40c4a, which is a hash of the code that’s put on-chain for fraud proofs. You can verify this WASM module root on a x86_64 computer (i.e. not on ARM which builds slightly different symbol names) with Docker setup by checking out the previously mentioned commit of the nitro repository, running git submodule update --init --recursive, and then running docker build . --target module-root-calc --tag wavm-machine && docker run --rm wavm-machine cat /workspace/target/machines/latest/module-root.txt This uses Docker to perform a reproducible build of the WebAssembly code used in fraud proofs, and outputs its hash.
The above code has audited by Trail of Bits - the audit report can be viewed in https://drive.google.com/file/d/1uwA1PK3AB9ggHMqaw91mubu5WHcEp398/view?usp=sharing
The Action smart contracts used to execute the on-chain upgrade can be viewed in
https://github.com/ArbitrumFoundation/governance/pull/170
Action contract addresses: SetArbOneArbOS11ModuleRootAction SetNovaArbOS11ModuleRootAction SetArbOS11VersionAction SetArbOS11VersionAction
The above code has audited by Trail of Bits - the audit report can be viewed in https://drive.google.com/file/d/1N3197Z7DuqBpu9qdt-GWPewe8HQakfLY/view?usp=sharing
The current ArbOS version used on Arbitrum One and Arbitrum Nova is ArbOS 10, corresponding to the Arbitrum Nitro consensus-v10 git tag. You can verify this by running the previously mentioned steps to build the WASM module root on that git tag, which produces the WASM module root 0x6b94a7fc388fd8ef3def759297828dc311761e88d8179c7ee8d3887dc554f3c3, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
To audit the code difference from ArbOS 10 to ArbOS 11, you could simple generate a full nitro diff with git diff consensus-v10 df93361a1293574903f28fbbbe0469a3ea5c644d (and also generate a diff of the go-ethereum submodule mentioned in that nitro diff). However, that includes a lot of code that isn’t part of the WASM module root. To filter down to just the replay binary which defines the state transition function, you can start by generating a list of files in the nitro and go-ethereum repositories included by the replay binary in either ArbOS 10 or ArbOS 11 with bash:
#!/usr/bin/env bash
set -e
mkdir -p ~/tmp # this script uses ~/tmp as scratch space and output
# this script should be run in the nitro repository
git checkout df93361a1293574903f28fbbbe0469a3ea5c644d
git submodule update --init --recursive
make solgen
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/offchainlabs/nitro/' | sed '[email protected]/offchainlabs/nitro/@@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v11-nitro-files.txt
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/ethereum/go-ethereum/' | sed '[email protected]/ethereum/go-ethereum/@go-ethereum/@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v11-geth-files.txt
rm -r contracts
git checkout consensus-v10
git submodule update --init --recursive
make solgen
rm -r blockscout
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/offchainlabs/nitro/' | sed '[email protected]/offchainlabs/nitro/@@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v10-nitro-files.txt
go list -f "{{.Deps}}" ./cmd/replay | tr -d '[]' | sed 's/ /\n/g' | grep 'github.com/ethereum/go-ethereum/' | sed '[email protected]/ethereum/go-ethereum/@go-ethereum/@' | while read dir; do find "$dir" -type f -name '*.go' -maxdepth 1; done | grep -v '_test\.go$' > ~/tmp/consensus-v10-geth-files.txt
sort -u ~/tmp/consensus-v10-nitro-files.txt ~/tmp/consensus-v11-nitro-files.txt > ~/tmp/replay-binary-nitro-dependencies.txt
sort -u ~/tmp/consensus-v10-geth-files.txt ~/tmp/consensus-v11-geth-files.txt | sed 's@^[./]*go-ethereum/@@' > ~/tmp/replay-binary-geth-dependencies.txt
Now, ~/tmp/replay-binary-dependencies.txt contains a list of dependencies of the replay binary that were present in ArbOS 10 or 11. To use that to generate a smaller diff of the nitro repository, you can run:
git diff consensus-v10 df93361a1293574903f28fbbbe0469a3ea5c644d -- cmd/replay $(cat ~/tmp/replay-binary-nitro-dependencies.txt)
For the go-ethereum submodule, you can first find out what go-ethereum commit ArbOS 10 and 11 used:
$ git ls-tree consensus-v10 go-ethereum 128 ↵
160000 commit 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 go-ethereum
$ git ls-tree df93361a1293574903f28fbbbe0469a3ea5c644d go-ethereum
160000 commit abe584818e104dd5b4fdb8f60381a14eede896de go-ethereum
Those commit hashes are the go-ethereum commit hashes pinned by each nitro commit. Then, you can again use git diff and the files generated by the earlier script to generate a diff limited to code used by the replay binary:
# this should be run inside the go-ethereum submodule folder
git diff 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt)
This diff also includes the diff between upstream go-ethereum versions v1.10.25 and v1.11.6, as ArbOS 10 used the former and ArbOS 11 uses the latter. To filter out that difference, you can use this tool to find the intersection of two git diffs: https://gist.github.com/PlasmaPower/795af590f88cfb5e21c5ad9b8a32afdf
We can use that to find the intersection of the diff of ArbOS 11’s go-ethereum against ArbOS 10’s go-ethereum and the diff of ArbOS 11’s go-etheruem against upstream go-ethereum v1.11.6:
# this should be run inside the go-ethereum submodule folder
git diff 941aa323e5cbbde1d5806eb4e3dd70553c5a1298 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-10-vs-11-geth.diff
git diff v1.11.6 abe584818e104dd5b4fdb8f60381a14eede896de -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-11-vs-upstream-geth.diff
diff-intersection.py ~/tmp/arbos-10-vs-11-geth.diff ~/tmp/arbos-11-vs-upstream-geth.diff
In addition, you can pass the following arguments to diff-intersection.py to ignore files that are included by the replay binary but whose components are not used: --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'
Note that by default, diff-intersection.py does a line based intersection. To instead do an intersection based on chunks in the diff, known as hunks in git terminology, you can add the --only-hunks flag.
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/11?u=krst
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/11?u=krst
https://forum.arbitrum.foundation/t/treasure-delegate-communication-thread/18873/5#arbos-version-11-1
https://twitter.com/CarlZielinski/status/1730776268054933525
Voting For. It is important for Arbitrum to keep growing and improving as a product. I trust the teams involved with writing / auditing the code properly vetted this update.
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/7?u=krst
https://twitter.com/CarlZielinski/status/1730776268054933525
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/6?u=treasuredao
https://forum.arbitrum.foundation/t/treasure-delegate-communication-thread/18873/5#arbos-version-11-1
https://twitter.com/CarlZielinski/status/1730776268054933525
Voting For. It is important for Arbitrum to keep growing and improving as a product. I trust the teams involved with writing / auditing the code properly vetted this update.
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/7?u=krst
https://twitter.com/CarlZielinski/status/1730776268054933525
https://forum.arbitrum.foundation/t/aip-arbos-version-11/19696/6?u=treasuredao
Could you please clarify if the January 27th date mentioned is for a testnet hard fork? If so, is there an anticipated timeline for the mainnet hard fork?
Treasure DAO’s Arbitrum Representative Council (ARC) will vote FOR this proposal on Snapshot.
We wholeheartedly endorse the ongoing technological advancements of Arbitrum, aiming to foster an improved ecosystem for both users and builders alike. In alignment with this vision, our vote is in favor of the ArbOS Version 11 proposal, as we believe it positively contributes to the progression and enhancement of the Arbitrum ecosystem.
Could you please clarify if the January 27th date mentioned is for a testnet hard fork? If so, is there an anticipated timeline for the mainnet hard fork?
Treasure DAO’s Arbitrum Representative Council (ARC) will vote FOR this proposal on Snapshot.
We wholeheartedly endorse the ongoing technological advancements of Arbitrum, aiming to foster an improved ecosystem for both users and builders alike. In alignment with this vision, our vote is in favor of the ArbOS Version 11 proposal, as we believe it positively contributes to the progression and enhancement of the Arbitrum ecosystem.
I appreciate the comprehensive efforts put into the ArbOS Version 11 proposal. The inclusion of the EVM Shanghai upgrade and the PUSH0 opcode demonstrates a proactive approach to ensuring compatibility with the latest Ethereum advancements, which is crucial for Arbitrum's continued relevance and efficiency.
The fixes addressing retryable transaction fees and the precompile gas usage issues reflect a keen attention to technical details, enhancing the overall robustness of the system. Additionally, the efforts to improve transparency through the introduction of L1 pricing parameter visibility are commendable.
I appreciate the comprehensive efforts put into the ArbOS Version 11 proposal. The inclusion of the EVM Shanghai upgrade and the PUSH0 opcode demonstrates a proactive approach to ensuring compatibility with the latest Ethereum advancements, which is crucial for Arbitrum's continued relevance and efficiency.
The fixes addressing retryable transaction fees and the precompile gas usage issues reflect a keen attention to technical details, enhancing the overall robustness of the system. Additionally, the efforts to improve transparency through the introduction of L1 pricing parameter visibility are commendable.
I support the thorough implementation process detailed in the proposal, particularly the inclusion of security audits for the smart contract upgrades. This approach underscores a commitment to security and reliability, essential for maintaining trust in the Arbitrum ecosystem.
Overall, I believe that the ArbOS Version 11 upgrade aligns well with the goals of technical excellence and ecosystem growth. Therefore, I endorse this proposal and look forward to its successful implementation.
Would love some clarity on these questions.
Mainnet update is live now
The proposal to enable ArbOS Version 11 has passed.
In order to continue syncing with the chain, Arbitrum nodes should upgrade to v2.2.2 as soon as possible. A docker image can be found in Docker Hub.
The upgrade is expected to come into effect around January 27th, so please upgrade your nodes before then.
The proposal is now live for an onchain vote https://www.tally.xyz/gov/arbitrum/proposal/77069694702187027448745871790562515795432836429094222862498991082283032976814
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
The frequency and timing of maintenance ArbOS upgrades are mostly dependent on three factors.
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
The frequency and timing of maintenance ArbOS upgrades are mostly dependent on three factors.
The frequency of Ethereum Layer 1 hardforks. For Arbitrum to keep its developer experience compatible with that of Ethereum Layer 1, whenever a hardfork on the base chain makes a change to an aspect of how it works, Arbitrum needs to be updated to include support for those features. This is examplified by the change mentioned on the original post with the PUSH0 instruction.
Bugs identified in the Layer 2 system. The Arbitrum Foundation has a running bug bounty program that rewards whitehats for helping identify potential issues that might affect the Arbitrum ecosystem. On top of that, the Foundation also engages with security professionals that audit and report findings on the functioning of the system. Worth noting that these initiatives are additive to any security work the DAO may wish to explore and fund to help secure the protocol. These various initiatives result in bugs being identified at times, which are then addressed via upgrades to the system (which can be enabled by a DAO onchain vote or a Security Council emergency action).
Implementation and security confidence on the changes. The frequency of ArbOS upgrades to address the two points above are also impacted by how much work is necessary in order to implement the changes as well as gain confidence in the security of the implementations. Different features and bugs have varying degrees of complexity and impact on the system.
The Foundation plans to fund the engineering and security work necessary for Arbitrum to remain feature compatible with Ethereum, which includes ArbOS upgrades for the future execution layer hardforks (such as the Dencun).
- Impact on Gas Fees: How will the changes introduced in ArbOS Version 11, especially those related to retryable transaction fees and precompile methods, impact overall gas fees for end users on the Arbitrum network?
These are primarily system changes that won't have a noticeable impact on end user gas fees. It will allow for a better developer experience when interacting with Arbitrum.
- Impact on Gas Fees: How will the changes introduced in ArbOS Version 11, especially those related to retryable transaction fees and precompile methods, impact overall gas fees for end users on the Arbitrum network?
These are primarily system changes that won't have a noticeable impact on end user gas fees. It will allow for a better developer experience when interacting with Arbitrum.
- Compatibility and Integration: With the implementation of the EVM Shanghai upgrade, what are the anticipated challenges in ensuring seamless integration with existing smart contracts and dApps on Arbitrum, and how are these being addressed?
This ArbOS upgrade will allow developers to consume features available on the EVM Shanghai upgrade, such as the PUSH0 opcode.
- Future Upgrades and Scalability: How does ArbOS Version 11 position Arbitrum in terms of scalability and future upgrades? Are there plans for further enhancements that build upon this version to support the growing ecosystem?
These are system changes to ensure the code running Arbitrum is up to date. The Shanghai code updates ensure the Arbitrum ecosystem maintains feature parity with the latest EVM.
I appreciate the comprehensive efforts put into the ArbOS Version 11 proposal. The inclusion of the EVM Shanghai upgrade and the PUSH0 opcode demonstrates a proactive approach to ensuring compatibility with the latest Ethereum advancements, which is crucial for Arbitrum's continued relevance and efficiency.
The fixes addressing retryable transaction fees and the precompile gas usage issues reflect a keen attention to technical details, enhancing the overall robustness of the system. Additionally, the efforts to improve transparency through the introduction of L1 pricing parameter visibility are commendable.
I appreciate the comprehensive efforts put into the ArbOS Version 11 proposal. The inclusion of the EVM Shanghai upgrade and the PUSH0 opcode demonstrates a proactive approach to ensuring compatibility with the latest Ethereum advancements, which is crucial for Arbitrum's continued relevance and efficiency.
The fixes addressing retryable transaction fees and the precompile gas usage issues reflect a keen attention to technical details, enhancing the overall robustness of the system. Additionally, the efforts to improve transparency through the introduction of L1 pricing parameter visibility are commendable.
I support the thorough implementation process detailed in the proposal, particularly the inclusion of security audits for the smart contract upgrades. This approach underscores a commitment to security and reliability, essential for maintaining trust in the Arbitrum ecosystem.
Overall, I believe that the ArbOS Version 11 upgrade aligns well with the goals of technical excellence and ecosystem growth. Therefore, I endorse this proposal and look forward to its successful implementation.
Would love some clarity on these questions.
Mainnet update is live now
The proposal to enable ArbOS Version 11 has passed.
In order to continue syncing with the chain, Arbitrum nodes should upgrade to v2.2.2 as soon as possible. A docker image can be found in Docker Hub.
The upgrade is expected to come into effect around January 27th, so please upgrade your nodes before then.
The proposal is now live for an onchain vote https://www.tally.xyz/gov/arbitrum/proposal/77069694702187027448745871790562515795432836429094222862498991082283032976814
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
The frequency and timing of maintenance ArbOS upgrades are mostly dependent on three factors.
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
The frequency and timing of maintenance ArbOS upgrades are mostly dependent on three factors.
The frequency of Ethereum Layer 1 hardforks. For Arbitrum to keep its developer experience compatible with that of Ethereum Layer 1, whenever a hardfork on the base chain makes a change to an aspect of how it works, Arbitrum needs to be updated to include support for those features. This is examplified by the change mentioned on the original post with the PUSH0 instruction.
Bugs identified in the Layer 2 system. The Arbitrum Foundation has a running bug bounty program that rewards whitehats for helping identify potential issues that might affect the Arbitrum ecosystem. On top of that, the Foundation also engages with security professionals that audit and report findings on the functioning of the system. Worth noting that these initiatives are additive to any security work the DAO may wish to explore and fund to help secure the protocol. These various initiatives result in bugs being identified at times, which are then addressed via upgrades to the system (which can be enabled by a DAO onchain vote or a Security Council emergency action).
Implementation and security confidence on the changes. The frequency of ArbOS upgrades to address the two points above are also impacted by how much work is necessary in order to implement the changes as well as gain confidence in the security of the implementations. Different features and bugs have varying degrees of complexity and impact on the system.
The Foundation plans to fund the engineering and security work necessary for Arbitrum to remain feature compatible with Ethereum, which includes ArbOS upgrades for the future execution layer hardforks (such as the Dencun).
- Impact on Gas Fees: How will the changes introduced in ArbOS Version 11, especially those related to retryable transaction fees and precompile methods, impact overall gas fees for end users on the Arbitrum network?
These are primarily system changes that won't have a noticeable impact on end user gas fees. It will allow for a better developer experience when interacting with Arbitrum.
- Impact on Gas Fees: How will the changes introduced in ArbOS Version 11, especially those related to retryable transaction fees and precompile methods, impact overall gas fees for end users on the Arbitrum network?
These are primarily system changes that won't have a noticeable impact on end user gas fees. It will allow for a better developer experience when interacting with Arbitrum.
- Compatibility and Integration: With the implementation of the EVM Shanghai upgrade, what are the anticipated challenges in ensuring seamless integration with existing smart contracts and dApps on Arbitrum, and how are these being addressed?
This ArbOS upgrade will allow developers to consume features available on the EVM Shanghai upgrade, such as the PUSH0 opcode.
- Future Upgrades and Scalability: How does ArbOS Version 11 position Arbitrum in terms of scalability and future upgrades? Are there plans for further enhancements that build upon this version to support the growing ecosystem?
These are system changes to ensure the code running Arbitrum is up to date. The Shanghai code updates ensure the Arbitrum ecosystem maintains feature parity with the latest EVM.
We begin by expressing our gratitude for the presented proposal. The parameters we consider when making decisions are:
1- What are coming with EVM Shangai upgrade.
2- What are the effects on the Arbitrum ecosystem.
We begin by expressing our gratitude for the presented proposal. The parameters we consider when making decisions are:
1- What are coming with EVM Shangai upgrade.
2- What are the effects on the Arbitrum ecosystem.
With EVM Shangai upgrade, EIP-1559 and EIP-4844 protocols are implemented into Arbitrum. Aside, in this implementations procceses, Go-Ethereum Libraries will be developed for harmony between EVM and Arbitrum chain. With EIP-1559, gas fees will be more stabilized. With EIP-4844, gas fees will decrease depending on reduction in block load since with EIP-4844, some of the onchain data will be save as off-chain.
However, Fizzy tests for this implementation process and their results are not shared with us. According to the moderator's comment, the reason for not sharing this detail is to avoid prolonging the application process. Additionally, the moderator mentioned various measures taken regarding this issue. In a general overview, As ITU Blockchain Delegation Commitee, we vote in favour of this proposal.
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 voted in favour of the upgrade during temp-check and we committed to fully reviewing the code of the proposed upgrade before voting on-chain to ensure that there’s nothing in it that shouldn’t be there.
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 voted in favour of the upgrade during temp-check and we committed to fully reviewing the code of the proposed upgrade before voting on-chain to ensure that there’s nothing in it that shouldn’t be there.
After reviewing the proposed upgrade and finding no issues, we’ll be voting in favour of the proposal.
One thing we want to bring up however is that we should try to improve the process to verify the diff between two versions (e.g. the current one and the proposed one).
Wow! The team at Arbitrum did so much work! Great!
Curia fully supports the upcoming upgrade and will vote FOR. We understand that this update will bring our EVM in line with Ethereum's Shanghai upgrade. It also includes adding and fixing bugs in precompiled contracts, making them more effective for use on Arbitrum. This is a positive development for the Arbitrum ecosystem.
We begin by expressing our gratitude for the presented proposal. The parameters we consider when making decisions are:
1- What are coming with EVM Shangai upgrade.
2- What are the effects on the Arbitrum ecosystem.
We begin by expressing our gratitude for the presented proposal. The parameters we consider when making decisions are:
1- What are coming with EVM Shangai upgrade.
2- What are the effects on the Arbitrum ecosystem.
With EVM Shangai upgrade, EIP-1559 and EIP-4844 protocols are implemented into Arbitrum. Aside, in this implementations procceses, Go-Ethereum Libraries will be developed for harmony between EVM and Arbitrum chain. With EIP-1559, gas fees will be more stabilized. With EIP-4844, gas fees will decrease depending on reduction in block load since with EIP-4844, some of the onchain data will be save as off-chain.
However, Fizzy tests for this implementation process and their results are not shared with us. According to the moderator's comment, the reason for not sharing this detail is to avoid prolonging the application process. Additionally, the moderator mentioned various measures taken regarding this issue. In a general overview, As ITU Blockchain Delegation Commitee, we vote in favour of this proposal.
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 voted in favour of the upgrade during temp-check and we committed to fully reviewing the code of the proposed upgrade before voting on-chain to ensure that there’s nothing in it that shouldn’t be there.
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 voted in favour of the upgrade during temp-check and we committed to fully reviewing the code of the proposed upgrade before voting on-chain to ensure that there’s nothing in it that shouldn’t be there.
After reviewing the proposed upgrade and finding no issues, we’ll be voting in favour of the proposal.
One thing we want to bring up however is that we should try to improve the process to verify the diff between two versions (e.g. the current one and the proposed one).
Wow! The team at Arbitrum did so much work! Great!
Curia fully supports the upcoming upgrade and will vote FOR. We understand that this update will bring our EVM in line with Ethereum's Shanghai upgrade. It also includes adding and fixing bugs in precompiled contracts, making them more effective for use on Arbitrum. This is a positive development for the Arbitrum ecosystem.
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’ll be voting FOR the proposal during temp-check as we agree with the proposed upgrades & fixes and their scope.
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’ll be voting FOR the proposal during temp-check as we agree with the proposed upgrades & fixes and their scope.
However, we want to point out that even though both audits by Trail of Bits did not reveal any issues with the code associated with the proposed upgrade, there hasn’t been an analysis to ensure that the upgrades and fixes will do what they’re intended to and nothing more.
Having said that, we’ll ensure to extensively review the proposed changes before voting during the on-chain vote to avoid any unintended consequences following the upgrade.
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
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’ll be voting FOR the proposal during temp-check as we agree with the proposed upgrades & fixes and their scope.
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’ll be voting FOR the proposal during temp-check as we agree with the proposed upgrades & fixes and their scope.
However, we want to point out that even though both audits by Trail of Bits did not reveal any issues with the code associated with the proposed upgrade, there hasn’t been an analysis to ensure that the upgrades and fixes will do what they’re intended to and nothing more.
Having said that, we’ll ensure to extensively review the proposed changes before voting during the on-chain vote to avoid any unintended consequences following the upgrade.
Also, we’d love to learn if there’s any roadmap that could be shared with the DAO in regards to any future OS upgrades.
