This AIP proposes a number of improvements to Arbitrum chains, including the capability to leverage EIP 4844 to post batches of L2 transactions as Blobs on L1 Ethereum at a cheaper price. The proposal also includes support for most of the changes included in Ethereum's Dencun upgrade. The proposed ArbOS 20 "Atlas" upgrade will be ready for adoption by any Arbitrum Chain; this proposal concerns the Arbitrum One and Nova chains, as they are governed by the Arbitrum DAO. On a high level, an ArbOS upgrade can be seen as Arbitrum’s equivalent of a hard fork - more can be read about the subject over in Arbitrum ArbOs upgrades.
Please note that ArbOS Version 20 "Atlas" is an upgrade that builds upon ArbOS version 11 which has been adopted by the ArbitrumDAO - this proposal increments the version number to 20 instead of 12 due to technical details that allow for better Orbit chain customizability.
With ArbOS 20 "Atlas", any Arbitrum chain that settles on L1 Ethereum will be able to post transactions as either calldata or “blob-data” - the latter of which is to be introduced in EIP-4844 as part of Ethereum’s Dencun upgrade.
Some notes on how this is implemented for Arbitrum:
This AIP includes a number of upgrades that enable Arbitrum chains to utilize EIP-4844:
Nitro core changes:
Current full code diff can be viewed via this link: https://github.com/OffchainLabs/nitro/compare/consensus-v11...finalize-arbos-20. Alternatively, the code diffs are attached below:
PRs:
Nitro smart contract changes:
Current Full Diff: https://github.com/OffchainLabs/nitro-contracts/compare/main...arbos-20-diff
PRs:
Ethereum’s Dencun upgrade is technically a combination of two upgrades: one to the Execution Layer and another to the Consensus Layer, named Cancun and Deneb, respectively. While the Consensus Layer upgrades are not applicable to Nitro (since Nitro is Arbitrum One and Arbitrum Nova’s execution engine), some of the Execution Layer changes are, including EIP-1153 as described above. The full Cancun network upgrade specification for Ethereum can be found here.
Nitro’s upgrade to ArbOS 20 "Atlas" adds support for three specific EIPs from Cancun, those being:
TSTORE and TLOAD, offering a cheaper option than storage for data that’s discarded at the end of a transaction.MCOPY EVM opcode introduced in EIP-5656 for cheaper memory copying.SELFDESTRUCT EVM opcode, as outlined in EIP-6780.Since Nitro uses Geth at the Core, the above 3 EIPs were implemented by merging in a Cancun-supported version of Geth upstream. More specifically, Geth version 1.13.1 was merged into Nitro’s go-ethereum fork here:
https://github.com/OffchainLabs/go-ethereum/pull/284
With the above merged, the below PR is used to enable the Cancun fork in ArbOS 20 "Atlas".
https://github.com/OffchainLabs/go-ethereum/pull/285
Ethereum’s Dencun upgrade includes various proposals that impact both the execution layer and the consensus layer, as mentioned earlier. Among the execution layer changes, there are two EIPs that are explicitly not included in ArbOS 20. This section briefly covers the scope of the two excluded EIPs and a rationale for why they are not included in ArbOS 20.
BLOBBASEFEE opcodeThis EIP adds a new opcode to the EVM that returns the base fee of the current blob and is identical to the BASEFEE opcode introduced in EIP-3198. This is applicable for Ethereum because it enables blob data users, such as rollup contracts or infrastructure, to programmatically account for the blob gas price.
This opcode is excluded from ArbOS 20 "Atlas" because Arbitrum chains are not currently planned to support receiving blobs from other chains, like an L3 Orbit chain. Calls to the BLOBBASEFEE opcode on Arbitrum One and Nova after the ArbOS 20 "Atlas" upgrade will revert.
This EIP commits a given block’s beacon chain root to the payload header for that particular block as a hash - essentially exposing beacon chain roots to the EVM. This is applicable for Ethereum because it improves the trust assumptions for a variety of applications that rely on data in the consensus layer. Examples of use cases that this would benefit include: staking pool, restaking constructions, smart contract bridges, and more.
This EIP is excluded from ArbOS 20 "Atlas" because Arbitrum’s execution engine (i.e. Nitro) does not have a consensus layer and relies on Ethereum consensus for data security and data finality. Calls to the beacon root opcode on Arbitrum One and Nova after the ArbOS 20 "Atlas" upgrade will revert.
The canonical version of ArbOS 20 this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash cf2eadfcc1039eca9594c4f71477a50f550d7749 and can be viewed in https://github.com/OffchainLabs/nitro/commit/cf2eadfcc1039eca9594c4f71477a50f550d7749.
The Action smart contracts used to execute the on-chain upgrade can be viewed in https://github.com/ArbitrumFoundation/governance/pull/244.
The current ArbOS version used on Arbitrum One and Arbitrum Nova is ArbOS 11, corresponding to the Arbitrum Nitro consensus-v11git 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 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
To audit the code difference from ArbOS 11 to ArbOS 20 "Atlas", you could simply generate a full nitro diff with git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 (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 11 or ArbOS 20 "Atlas" 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 cf2eadfcc1039eca9594c4f71477a50f550d7749
git submodule update --init --recursive
make .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-v20-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-v20-geth-files.txt
git checkout consensus-v11
git submodule update --init --recursive
make .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
sort -u ~/tmp/consensus-v11-nitro-files.txt ~/tmp/consensus-v20-nitro-files.txt > ~/tmp/replay-binary-nitro-dependencies.txt
sort -u ~/tmp/consensus-v11-geth-files.txt ~/tmp/consensus-v20-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 11 or ArbOS 20 "Atlas". To use that to generate a smaller diff of the nitro repository, you can run:
git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 -- cmd/replay $(cat ~/tmp/replay-binary-nitro-dependencies.txt)
The fraud prover is not part of the on-chain upgrade, but may be helpful in understanding the fraud proving smart contract changes and other components:
git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 -- arbitrator/prover arbitrator/wasm-libraries/ arbitrator/arbutil ':!**/Cargo.lock' ':!**/kzg-trusted-setup.json'
For the go-ethereum submodule, you can first find out what go-ethereum commit ArbOS 11 and 20 "Atlas" used:
$ git ls-tree consensus-v11 go-ethereum
160000 commit abe584818e104dd5b4fdb8f60381a14eede896de go-ethereum
$ git ls-tree cf2eadfcc1039eca9594c4f71477a50f550d7749 go-ethereum
160000 commit 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 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 abe584818e104dd5b4fdb8f60381a14eede896de 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt)
This diff also includes the diff between upstream go-ethereum versions v1.11.6 and v1.13.3, as ArbOS 11 used the former and ArbOS 20 "Atlas" uses the latter. To filter out that difference, you can use this tool to find the intersection of two git diffs: Git diff intersection finder
We can use that to find the intersection of the diff of ArbOS 20 "Atlas"’s go-ethereum against ArbOS 11’s go-ethereum and the diff of ArbOS 20’s go-etheruem against upstream go-ethereum v1.13.3:
# this should be run inside the go-ethereum submodule folder
git diff abe584818e104dd5b4fdb8f60381a14eede896de 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-11-vs-20-geth.diff
git diff v1.13.3 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-20-vs-upstream-geth.diff
diff-intersection.py ~/tmp/arbos-11-vs-20-geth.diff ~/tmp/arbos-20-vs-upstream-geth.diff --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'
The above command ignores files that are included by the replay binary but whose components are not used with these arguments: --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'. To also review those diffs, you can remove those arguments.
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.
The current proposal is currently undergoing security audits. As the audit is finalized, the proposal will be updated accordingly and the audit report will be made available to the public.
Even though the audit isn't complete, the proposal is mature and ready to be discussed and considered for adoption by the DAO.
This AIP proposes a number of improvements to Arbitrum chains, including the capability to leverage EIP 4844 to post batches of L2 transactions as Blobs on L1 Ethereum at a cheaper price. The proposal also includes support for most of the changes included in Ethereum's Dencun upgrade. The proposed ArbOS 20 "Atlas" upgrade will be ready for adoption by any Arbitrum Chain; this proposal concerns the Arbitrum One and Nova chains, as they are governed by the Arbitrum DAO. On a high level, an ArbOS upgrade can be seen as Arbitrum’s equivalent of a hard fork - more can be read about the subject over in Arbitrum ArbOs upgrades.
Please note that ArbOS Version 20 "Atlas" is an upgrade that builds upon ArbOS version 11 which has been adopted by the ArbitrumDAO - this proposal increments the version number to 20 instead of 12 due to technical details that allow for better Orbit chain customizability.
With ArbOS 20 "Atlas", any Arbitrum chain that settles on L1 Ethereum will be able to post transactions as either calldata or “blob-data” - the latter of which is to be introduced in EIP-4844 as part of Ethereum’s Dencun upgrade.
Some notes on how this is implemented for Arbitrum:
This AIP includes a number of upgrades that enable Arbitrum chains to utilize EIP-4844:
Nitro core changes:
Current full code diff can be viewed via this link: https://github.com/OffchainLabs/nitro/compare/consensus-v11...finalize-arbos-20. Alternatively, the code diffs are attached below:
PRs:
Nitro smart contract changes:
Current Full Diff: https://github.com/OffchainLabs/nitro-contracts/compare/main...arbos-20-diff
PRs:
Ethereum’s Dencun upgrade is technically a combination of two upgrades: one to the Execution Layer and another to the Consensus Layer, named Cancun and Deneb, respectively. While the Consensus Layer upgrades are not applicable to Nitro (since Nitro is Arbitrum One and Arbitrum Nova’s execution engine), some of the Execution Layer changes are, including EIP-1153 as described above. The full Cancun network upgrade specification for Ethereum can be found here.
Nitro’s upgrade to ArbOS 20 "Atlas" adds support for three specific EIPs from Cancun, those being:
TSTORE and TLOAD, offering a cheaper option than storage for data that’s discarded at the end of a transaction.MCOPY EVM opcode introduced in EIP-5656 for cheaper memory copying.SELFDESTRUCT EVM opcode, as outlined in EIP-6780.Since Nitro uses Geth at the Core, the above 3 EIPs were implemented by merging in a Cancun-supported version of Geth upstream. More specifically, Geth version 1.13.1 was merged into Nitro’s go-ethereum fork here:
https://github.com/OffchainLabs/go-ethereum/pull/284
With the above merged, the below PR is used to enable the Cancun fork in ArbOS 20 "Atlas".
https://github.com/OffchainLabs/go-ethereum/pull/285
Ethereum’s Dencun upgrade includes various proposals that impact both the execution layer and the consensus layer, as mentioned earlier. Among the execution layer changes, there are two EIPs that are explicitly not included in ArbOS 20. This section briefly covers the scope of the two excluded EIPs and a rationale for why they are not included in ArbOS 20.
BLOBBASEFEE opcodeThis EIP adds a new opcode to the EVM that returns the base fee of the current blob and is identical to the BASEFEE opcode introduced in EIP-3198. This is applicable for Ethereum because it enables blob data users, such as rollup contracts or infrastructure, to programmatically account for the blob gas price.
This opcode is excluded from ArbOS 20 "Atlas" because Arbitrum chains are not currently planned to support receiving blobs from other chains, like an L3 Orbit chain. Calls to the BLOBBASEFEE opcode on Arbitrum One and Nova after the ArbOS 20 "Atlas" upgrade will revert.
This EIP commits a given block’s beacon chain root to the payload header for that particular block as a hash - essentially exposing beacon chain roots to the EVM. This is applicable for Ethereum because it improves the trust assumptions for a variety of applications that rely on data in the consensus layer. Examples of use cases that this would benefit include: staking pool, restaking constructions, smart contract bridges, and more.
This EIP is excluded from ArbOS 20 "Atlas" because Arbitrum’s execution engine (i.e. Nitro) does not have a consensus layer and relies on Ethereum consensus for data security and data finality. Calls to the beacon root opcode on Arbitrum One and Nova after the ArbOS 20 "Atlas" upgrade will revert.
The canonical version of ArbOS 20 this proposal aims to adopt is implemented in the Arbitrum Nitro git commit hash cf2eadfcc1039eca9594c4f71477a50f550d7749 and can be viewed in https://github.com/OffchainLabs/nitro/commit/cf2eadfcc1039eca9594c4f71477a50f550d7749.
The Action smart contracts used to execute the on-chain upgrade can be viewed in https://github.com/ArbitrumFoundation/governance/pull/244.
The current ArbOS version used on Arbitrum One and Arbitrum Nova is ArbOS 11, corresponding to the Arbitrum Nitro consensus-v11git 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 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4, which is what the rollup contract’s wasmModuleRoot() method returns for both Arbitrum One and Arbitrum Nova.
To audit the code difference from ArbOS 11 to ArbOS 20 "Atlas", you could simply generate a full nitro diff with git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 (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 11 or ArbOS 20 "Atlas" 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 cf2eadfcc1039eca9594c4f71477a50f550d7749
git submodule update --init --recursive
make .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-v20-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-v20-geth-files.txt
git checkout consensus-v11
git submodule update --init --recursive
make .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
sort -u ~/tmp/consensus-v11-nitro-files.txt ~/tmp/consensus-v20-nitro-files.txt > ~/tmp/replay-binary-nitro-dependencies.txt
sort -u ~/tmp/consensus-v11-geth-files.txt ~/tmp/consensus-v20-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 11 or ArbOS 20 "Atlas". To use that to generate a smaller diff of the nitro repository, you can run:
git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 -- cmd/replay $(cat ~/tmp/replay-binary-nitro-dependencies.txt)
The fraud prover is not part of the on-chain upgrade, but may be helpful in understanding the fraud proving smart contract changes and other components:
git diff consensus-v11 cf2eadfcc1039eca9594c4f71477a50f550d7749 -- arbitrator/prover arbitrator/wasm-libraries/ arbitrator/arbutil ':!**/Cargo.lock' ':!**/kzg-trusted-setup.json'
For the go-ethereum submodule, you can first find out what go-ethereum commit ArbOS 11 and 20 "Atlas" used:
$ git ls-tree consensus-v11 go-ethereum
160000 commit abe584818e104dd5b4fdb8f60381a14eede896de go-ethereum
$ git ls-tree cf2eadfcc1039eca9594c4f71477a50f550d7749 go-ethereum
160000 commit 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 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 abe584818e104dd5b4fdb8f60381a14eede896de 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt)
This diff also includes the diff between upstream go-ethereum versions v1.11.6 and v1.13.3, as ArbOS 11 used the former and ArbOS 20 "Atlas" uses the latter. To filter out that difference, you can use this tool to find the intersection of two git diffs: Git diff intersection finder
We can use that to find the intersection of the diff of ArbOS 20 "Atlas"’s go-ethereum against ArbOS 11’s go-ethereum and the diff of ArbOS 20’s go-etheruem against upstream go-ethereum v1.13.3:
# this should be run inside the go-ethereum submodule folder
git diff abe584818e104dd5b4fdb8f60381a14eede896de 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-11-vs-20-geth.diff
git diff v1.13.3 1acd9c64ac5804729475ef60aa578b4ec52fa0e6 -- $(cat ~/tmp/replay-binary-geth-dependencies.txt) > ~/tmp/arbos-20-vs-upstream-geth.diff
diff-intersection.py ~/tmp/arbos-11-vs-20-geth.diff ~/tmp/arbos-20-vs-upstream-geth.diff --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'
The above command ignores files that are included by the replay binary but whose components are not used with these arguments: --ignore-files 'core/blockchain*.go' arbitrum_types/txoptions.go 'rawdb/**' 'rpc/**'. To also review those diffs, you can remove those arguments.
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.
The current proposal is currently undergoing security audits. As the audit is finalized, the proposal will be updated accordingly and the audit report will be made available to the public.
Even though the audit isn't complete, the proposal is mature and ready to be discussed and considered for adoption by the DAO.
The Event Horizon Community Voted to Support this Proposal ehARB-4: EventHorizon.vote/vote
Check our governance forum post for rationale
The Event Horizon Community Voted to Support this Proposal ehARB-4: EventHorizon.vote/vote
Check our governance forum post for rationale
DAOStewards is in support of these upgrade changes
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/26?u=mcfly
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/25?u=krst
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/23?u=karelvuong
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/22?u=bob-rossi
we are voting in favor of this upgrade. first - it’s necessary for for compatibility with L1 second - this should reduce transaction fees
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/18?u=princetonblockchain
该 AIP 提出了对 Arbitrum 链的多项改进，包括利用 EIP 4844 以更便宜的价格在 L1 以太坊上以 Blob 形式发布批量 L2 交易的能力。该提案还包括对以太坊 Dencun 升级中包含的大部分更改的支持，以及对 Arbitrum One 和 Nova 批量发布的 2 项改进。拟议的 ArbOS 20“Atlas”升级将可供任何 Arbitrum 链采用；该提案涉及 Arbitrum One 和 Nova 链，因为它们受 Arbitrum DAO 管辖。在较高的层面上，ArbOS 升级可以被视为 Arbitrum 的硬分叉 - 可以在Arbitrum ArbOs 升级中阅读有关该主题的更多信息。 该 AIP 结合了以下两个温度检查：AIP：ArbOS 版本 20“Atlas”和AIP：批量海报管理器和排序器收件箱最终修复- 两者均已通过。 请注意，ArbOS 版本 20“Atlas”是基于 ArbitrumDAO 采用的ArbOS 版本 11 的升级- 由于技术细节允许更好的 Orbit 链可定制性，该提案将版本号增加到 20 而不是 12。
Vote FOR to enhance security with batch poster key rotations, ensuring system stability even if keys are compromised. Prev. vote error.
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/16?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/15?u=krst
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/14?u=krst
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/11?u=princetonblockchain
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/12?u=princetonblockchain
Can't wait to see all the benefits that EIP 4844 will bring to Arbitrum.
Debated abstaining, since I don't have the technical understanding to FULLY grok this, but it seems like an improvement worth supporting.
Excited to see how much cheaper Arbitrum gets after the next hard fork gives us blobs :-D
Not enough technical knowledge here. I'll dive in the following ones.
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/6?u=maxlomu
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/3?u=bob-rossi
DAOStewards is in support of these upgrade changes
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/26?u=mcfly
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/25?u=krst
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/23?u=karelvuong
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/22?u=bob-rossi
we are voting in favor of this upgrade. first - it’s necessary for for compatibility with L1 second - this should reduce transaction fees
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/18?u=princetonblockchain
该 AIP 提出了对 Arbitrum 链的多项改进，包括利用 EIP 4844 以更便宜的价格在 L1 以太坊上以 Blob 形式发布批量 L2 交易的能力。该提案还包括对以太坊 Dencun 升级中包含的大部分更改的支持，以及对 Arbitrum One 和 Nova 批量发布的 2 项改进。拟议的 ArbOS 20“Atlas”升级将可供任何 Arbitrum 链采用；该提案涉及 Arbitrum One 和 Nova 链，因为它们受 Arbitrum DAO 管辖。在较高的层面上，ArbOS 升级可以被视为 Arbitrum 的硬分叉 - 可以在Arbitrum ArbOs 升级中阅读有关该主题的更多信息。 该 AIP 结合了以下两个温度检查：AIP：ArbOS 版本 20“Atlas”和AIP：批量海报管理器和排序器收件箱最终修复- 两者均已通过。 请注意，ArbOS 版本 20“Atlas”是基于 ArbitrumDAO 采用的ArbOS 版本 11 的升级- 由于技术细节允许更好的 Orbit 链可定制性，该提案将版本号增加到 20 而不是 12。
Vote FOR to enhance security with batch poster key rotations, ensuring system stability even if keys are compromised. Prev. vote error.
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/16?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/15?u=krst
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/14?u=krst
https://forum.arbitrum.foundation/t/aip-batch-poster-manager-and-sequencer-inbox-finality-fix/20995/11?u=princetonblockchain
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/12?u=princetonblockchain
Can't wait to see all the benefits that EIP 4844 will bring to Arbitrum.
Debated abstaining, since I don't have the technical understanding to FULLY grok this, but it seems like an improvement worth supporting.
Excited to see how much cheaper Arbitrum gets after the next hard fork gives us blobs :-D
Not enough technical knowledge here. I'll dive in the following ones.
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/6?u=maxlomu
https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957/3?u=bob-rossi
The below response portrays the views of the @AranaDigital governance team, represented by @farfel.eth.
We are voting For as we see the improvements outlined in this proposal as aligning Arbitrum's fee structure to enable the network to accommodate higher transaction throughput while decreasing costs for users. This is crucial for sustaining Arbitrum's attractiveness in a competitive Layer 2 environment. Although we anticipate a decrease in revenue, it's a necessary step to ensure Arbitrum remains competitive in pricing. The expectation is that increased transaction volume will offset the reduction in marginal revenues, ultimately restoring total revenue to its previous level—and hopefully surpassing it.
The below response portrays the views of the @AranaDigital governance team, represented by @farfel.eth.
We are voting For as we see the improvements outlined in this proposal as aligning Arbitrum's fee structure to enable the network to accommodate higher transaction throughput while decreasing costs for users. This is crucial for sustaining Arbitrum's attractiveness in a competitive Layer 2 environment. Although we anticipate a decrease in revenue, it's a necessary step to ensure Arbitrum remains competitive in pricing. The expectation is that increased transaction volume will offset the reduction in marginal revenues, ultimately restoring total revenue to its previous level—and hopefully surpassing it.
For visibility (thanks @raam): If you are looking to understand more ArbOS internals, from a technical standpoint, you might be interested in https://forum.arbitrum.foundation/t/arbos-code-walkthrough/22102
Vote: For
I am strongly in favor, as I consider them to be among the most critical advancements in our space at the moment.
Vote: For
I am strongly in favor, as I consider them to be among the most critical advancements in our space at the moment.
The reality is that a substantial portion of new users are inclined to dip their toes into the ecosystem with minimal initial investments. Given this trend, the cost of transactions can pose a considerable deterrent, eroding the efficiency of their trading activities from the outset.
From my perspective, the true value of these developments may not lie solely in the measurable reduction of gas fees. Instead, I anticipate a more significant outcome the potential surge in transaction volume. This is because the lowered entry barriers are likely to encourage a wave of new users who find the prospect of engaging with DeFi platforms more approachable and less intimidating compared to CeFi options. Really looking forward to this!
Reporting some small typos:
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
For visibility (thanks @raam): If you are looking to understand more ArbOS internals, from a technical standpoint, you might be interested in https://forum.arbitrum.foundation/t/arbos-code-walkthrough/22102
Vote: For
I am strongly in favor, as I consider them to be among the most critical advancements in our space at the moment.
Vote: For
I am strongly in favor, as I consider them to be among the most critical advancements in our space at the moment.
The reality is that a substantial portion of new users are inclined to dip their toes into the ecosystem with minimal initial investments. Given this trend, the cost of transactions can pose a considerable deterrent, eroding the efficiency of their trading activities from the outset.
From my perspective, the true value of these developments may not lie solely in the measurable reduction of gas fees. Instead, I anticipate a more significant outcome the potential surge in transaction volume. This is because the lowered entry barriers are likely to encourage a wave of new users who find the prospect of engaging with DeFi platforms more approachable and less intimidating compared to CeFi options. Really looking forward to this!
Reporting some small typos:
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
Reporting some small typos:
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
should be [...] > ~/tmp/consensus-v11-geth-files.txt instead
git diff consensus-11 d84f1ba899f6f5aba06c4c3a06c0f9abb5a52b6d -- arbitrator/prover arbitrator/wasm-libraries/ arbitrator/arbutil ':!**/Cargo.lock' ':!**/kzg-trusted-setup.json'
should be git diff consensus-v11 [...]
Я бы рекомендовал скачать все, что важно, на всякий случай!
When you submit a transaction on Arbitrum, the Arbitrum sequencer collects it and orders it along with other transactions. This allows you to receive a fast notification from Metamask.
The sequencer blocks are then typically aggregated together before being posted to Ethereum. That's why it is mentioned that the sequencer posts batches frequently. This enables the chain to keep growing/processing transactions.
When you submit a transaction on Arbitrum, the Arbitrum sequencer collects it and orders it along with other transactions. This allows you to receive a fast notification from Metamask.
The sequencer blocks are then typically aggregated together before being posted to Ethereum. That's why it is mentioned that the sequencer posts batches frequently. This enables the chain to keep growing/processing transactions.
The sequencer is the same entity as the batch poster and is controlled by a single address on a hot wallet. This means that if the keys of this address are lost or compromised, we could end up in a position where the entity that enables the chain to keep growing is not available anymore.
The DAO would have to take action because on Arbitrum, the 'escape hatch' (force inclusion mechanism) not only enables escape but also allows the DAO to elect a new sequencer. The goal of this proposal is to avoid the need to reach that point by having another entity called the batch poster manager. This manager can say, 'Hey, this batch poster address is compromised, so now this is the new address responsible for posting batches on Ethereum.' You can think of it as a protocol add-on that is useful/would intervene only in case of an issue.
Hope that helps.
Reporting some small typos:
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
should be [...] > ~/tmp/consensus-v11-geth-files.txt instead
git diff consensus-11 d84f1ba899f6f5aba06c4c3a06c0f9abb5a52b6d -- arbitrator/prover arbitrator/wasm-libraries/ arbitrator/arbutil ':!**/Cargo.lock' ':!**/kzg-trusted-setup.json'
should be git diff consensus-v11 [...]
Я бы рекомендовал скачать все, что важно, на всякий случай!
When you submit a transaction on Arbitrum, the Arbitrum sequencer collects it and orders it along with other transactions. This allows you to receive a fast notification from Metamask.
The sequencer blocks are then typically aggregated together before being posted to Ethereum. That's why it is mentioned that the sequencer posts batches frequently. This enables the chain to keep growing/processing transactions.
When you submit a transaction on Arbitrum, the Arbitrum sequencer collects it and orders it along with other transactions. This allows you to receive a fast notification from Metamask.
The sequencer blocks are then typically aggregated together before being posted to Ethereum. That's why it is mentioned that the sequencer posts batches frequently. This enables the chain to keep growing/processing transactions.
The sequencer is the same entity as the batch poster and is controlled by a single address on a hot wallet. This means that if the keys of this address are lost or compromised, we could end up in a position where the entity that enables the chain to keep growing is not available anymore.
The DAO would have to take action because on Arbitrum, the 'escape hatch' (force inclusion mechanism) not only enables escape but also allows the DAO to elect a new sequencer. The goal of this proposal is to avoid the need to reach that point by having another entity called the batch poster manager. This manager can say, 'Hey, this batch poster address is compromised, so now this is the new address responsible for posting batches on Ethereum.' You can think of it as a protocol add-on that is useful/would intervene only in case of an issue.
Hope that helps.
If the proposal to enable ArbOS Version 20 Atlas passes, nodes will need to be updated to continue syncing with the chain.
Arbitrum nodes should upgrade to v2.3.0 . A docker image can be found in Docker Hub.
If the proposal to enable ArbOS Version 20 Atlas passes, nodes will need to be updated to continue syncing with the chain.
Arbitrum nodes should upgrade to v2.3.0 . A docker image can be found in Docker Hub.
Audit report for the changes are available in ArbOS 20 - Summary Report.pdf|attachment (622.9 KB)
Audit report for the changes are available in ArbOS 20 - Summary Report.pdf|attachment (622.9 KB)
There will be a Walkthrough & AMA call (which has been added to the Governance Calendar) to answer any questions and discuss the details of this technical AIP on Tuesday, February 13!
Walkthrough & AMA for Live Technical AIPs Tuesday, February 13 · 2:00 – 2:45pm UTC Video call link: https://meet.google.com/bhs-owyn-chs
There will be a Walkthrough & AMA call (which has been added to the Governance Calendar) to answer any questions and discuss the details of this technical AIP on Tuesday, February 13!
Walkthrough & AMA for Live Technical AIPs Tuesday, February 13 · 2:00 – 2:45pm UTC Video call link: https://meet.google.com/bhs-owyn-chs
There will be a Walkthrough & AMA call (which has been added to the Governance Calendar) to answer any questions and discuss the details of this technical AIP on Tuesday, February 13!
Walkthrough & AMA for Live Technical AIPs Tuesday, February 13 · 2:00 – 2:45pm UTC Video call link: https://meet.google.com/bhs-owyn-chs
There will be a Walkthrough & AMA call (which has been added to the Governance Calendar) to answer any questions and discuss the details of this technical AIP on Tuesday, February 13!
Walkthrough & AMA for Live Technical AIPs Tuesday, February 13 · 2:00 – 2:45pm UTC Video call link: https://meet.google.com/bhs-owyn-chs
Question @Arbitrum - Will the audit be published before the DAO is required to vote on Tally?
Yup, will be shared here before an onchain vote starts.
Question @Arbitrum - Will the audit be published before the DAO is required to vote on Tally?
Yup, will be shared here before an onchain vote starts.
These discussions showcase a robust community engagement and support for the upgrade. The consensus among various stakeholders, including representative councils and individual voters showcase the Offchain Labs team's ability to enhance the deliver. The anticipated improvements, such as cost reductions for transactions through blob storage and the introduction of new OPCODEs, are widely welcomed. The audit report's availability and the resolution of a high-severity issue further bolster confidence in the upgrade's technical solidity.
We are in support for this ArbOS Version 20 "Atlas" upgrade. The proactive approach in addressing technical issues, coupled with the emphasis on cost efficiency and ecosystem enhancement, sets a commendable standard for blockchain development. This upgrade not only promises to improve transactional efficiency but also aligns with the broader goals of scalability and user accessibility. The collective anticipation for a more efficient and inclusive ecosystem reflects a shared vision for the future of decentralized finance, underscoring the importance of community-led governance in achieving sustainable technological advancement.
These discussions showcase a robust community engagement and support for the upgrade. The consensus among various stakeholders, including representative councils and individual voters showcase the Offchain Labs team's ability to enhance the deliver. The anticipated improvements, such as cost reductions for transactions through blob storage and the introduction of new OPCODEs, are widely welcomed. The audit report's availability and the resolution of a high-severity issue further bolster confidence in the upgrade's technical solidity.
We are in support for this ArbOS Version 20 "Atlas" upgrade. The proactive approach in addressing technical issues, coupled with the emphasis on cost efficiency and ecosystem enhancement, sets a commendable standard for blockchain development. This upgrade not only promises to improve transactional efficiency but also aligns with the broader goals of scalability and user accessibility. The collective anticipation for a more efficient and inclusive ecosystem reflects a shared vision for the future of decentralized finance, underscoring the importance of community-led governance in achieving sustainable technological advancement.
As a future conversation, given these cost reductions through blob storage, what else can there be done to reduce costs in this line, or is this the ultimate endgoal?
Vote: FOR
Why: The upgrade nails it on multiple fronts. First off, fixing that high-severity bug pre-vote shows the team's on their A-game. Compatibility with Ethereum's latest, especially with EIP-4844, is a game changer for us on the gas front - cheaper transactions are always a win. The move towards more democratic and transparent governance processes is something I can get behind, adding fairness and integrity. Plus, having dug through the audit and seeing only one issue, quickly patched, gives me tons of confidence. In short, this upgrade's got the tech chops, cost savings, and better governance we've been looking for. Solid work by the Arbitrum team, and it's a straightforward decision to back this.
he 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.
When we voted in favor of the proposal during temp-check, we committed ourselves to go through the proposed changes and the associated executable code in-depth before casting our vote on-chain.
he 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.
When we voted in favor of the proposal during temp-check, we committed ourselves to go through the proposed changes and the associated executable code in-depth before casting our vote on-chain.
After reviewing the changes, and ensuring that the computed wasmModuleRoot matches what's in the proposal’s executable, we’ve found nothing worrisome. As such, we’ll be voting in favour of the proposal.
I will be maintain my Snapshot "For" vote for the final On-Chain Tally vote. I will echo that I trust the Arbitrum team's ability and technical expertise in this manner.
Thank you to the team for providing the Security Assement report before voting. This step gives me even more confidence in the vote and it is appreciated. After reading the report, it looks like there was only 1 possible issue which was promptly resolved during the process.
Our team cp0x is voting in favor of this upgrade. First of all - it's necessary for for compatibility with L1. Second - this should reduce transaction fees.
After reviewing the audit report, the Princeton Blockchain Club is voting in favor of the combined Atlas upgrade and Batch Poster Improvements proposal on Tally.
The only high-severity issue (TOB-ARBOS20-2) was discovered and fixed during the auditing process. Looks good to us!
The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.
Despite its technical complexity, the Batch Poster Manager and Sequencer Inbox Finality Fix brings security benefits to the ecosystem with minimal risks. The DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).
After reviewing the proposal, we will vote in support of this proposal. The introduction of a batch poster to assist and the possibility of changing addresses for the rollup are positive steps toward enhancing the network's security. This proposal appears to have beneficial impacts with minimal risks. Upon examining the smart contract aspect, we found that it pertains to managing permissions, which presents no concerns. Furthermore, it has undergone an audit by Trail of Bits, a reputable firm in the web3 audit space, assuring us of its integrity and security.
I have voted in favor of this proposal as it presents a necessary improvement and streamlines the process of altering the batch poster keys.
I'm voting in favor of this upgrade since the transactions costs will be reduced in the network and it is compatible with the reasoning for blobs in L1. I'm not aware of any technical issue at the moment of writting this comment
The Savvy DeFi DAO's Arbitrum Council has voted in favor of this proposal
The introduction of shielded voting adds integrity. Additionally, a dedicated week for candidates to apply makes the process fairer, more competitive, and accessible, eliminating unfair advantages and providing more time for application finalization.
The Savvy DeFi DAO's Arbitrum Council has voted in favor of this proposal
The introduction of shielded voting adds integrity. Additionally, a dedicated week for candidates to apply makes the process fairer, more competitive, and accessible, eliminating unfair advantages and providing more time for application finalization.
Overall, these changes enhance the democratic nature of the Security Council elections, making them more equitable and transparent.
Treasure’s Arbitrum Representative Council voted “For” this proposal on the On-Chain Tally vote.
As described above, we continue to have full confidence in the Offchain Labs team’s ability to continually enhance the Arbitrum ecosystem through their technical expertise. While we depend on our more technically inclined delegates and community members to raise any concerns, it’s evident that the proposed improvements offer undeniable value with no apparent challenges.
These discussions showcase a robust community engagement and support for the upgrade. The consensus among various stakeholders, including representative councils and individual voters showcase the Offchain Labs team's ability to enhance the deliver. The anticipated improvements, such as cost reductions for transactions through blob storage and the introduction of new OPCODEs, are widely welcomed. The audit report's availability and the resolution of a high-severity issue further bolster confidence in the upgrade's technical solidity.
We are in support for this ArbOS Version 20 "Atlas" upgrade. The proactive approach in addressing technical issues, coupled with the emphasis on cost efficiency and ecosystem enhancement, sets a commendable standard for blockchain development. This upgrade not only promises to improve transactional efficiency but also aligns with the broader goals of scalability and user accessibility. The collective anticipation for a more efficient and inclusive ecosystem reflects a shared vision for the future of decentralized finance, underscoring the importance of community-led governance in achieving sustainable technological advancement.
These discussions showcase a robust community engagement and support for the upgrade. The consensus among various stakeholders, including representative councils and individual voters showcase the Offchain Labs team's ability to enhance the deliver. The anticipated improvements, such as cost reductions for transactions through blob storage and the introduction of new OPCODEs, are widely welcomed. The audit report's availability and the resolution of a high-severity issue further bolster confidence in the upgrade's technical solidity.
We are in support for this ArbOS Version 20 "Atlas" upgrade. The proactive approach in addressing technical issues, coupled with the emphasis on cost efficiency and ecosystem enhancement, sets a commendable standard for blockchain development. This upgrade not only promises to improve transactional efficiency but also aligns with the broader goals of scalability and user accessibility. The collective anticipation for a more efficient and inclusive ecosystem reflects a shared vision for the future of decentralized finance, underscoring the importance of community-led governance in achieving sustainable technological advancement.
As a future conversation, given these cost reductions through blob storage, what else can there be done to reduce costs in this line, or is this the ultimate endgoal?
Vote: FOR
Why: The upgrade nails it on multiple fronts. First off, fixing that high-severity bug pre-vote shows the team's on their A-game. Compatibility with Ethereum's latest, especially with EIP-4844, is a game changer for us on the gas front - cheaper transactions are always a win. The move towards more democratic and transparent governance processes is something I can get behind, adding fairness and integrity. Plus, having dug through the audit and seeing only one issue, quickly patched, gives me tons of confidence. In short, this upgrade's got the tech chops, cost savings, and better governance we've been looking for. Solid work by the Arbitrum team, and it's a straightforward decision to back this.
he 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.
When we voted in favor of the proposal during temp-check, we committed ourselves to go through the proposed changes and the associated executable code in-depth before casting our vote on-chain.
he 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.
When we voted in favor of the proposal during temp-check, we committed ourselves to go through the proposed changes and the associated executable code in-depth before casting our vote on-chain.
After reviewing the changes, and ensuring that the computed wasmModuleRoot matches what's in the proposal’s executable, we’ve found nothing worrisome. As such, we’ll be voting in favour of the proposal.
I will be maintain my Snapshot "For" vote for the final On-Chain Tally vote. I will echo that I trust the Arbitrum team's ability and technical expertise in this manner.
Thank you to the team for providing the Security Assement report before voting. This step gives me even more confidence in the vote and it is appreciated. After reading the report, it looks like there was only 1 possible issue which was promptly resolved during the process.
Our team cp0x is voting in favor of this upgrade. First of all - it's necessary for for compatibility with L1. Second - this should reduce transaction fees.
After reviewing the audit report, the Princeton Blockchain Club is voting in favor of the combined Atlas upgrade and Batch Poster Improvements proposal on Tally.
The only high-severity issue (TOB-ARBOS20-2) was discovered and fixed during the auditing process. Looks good to us!
The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.
Despite its technical complexity, the Batch Poster Manager and Sequencer Inbox Finality Fix brings security benefits to the ecosystem with minimal risks. The DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).
After reviewing the proposal, we will vote in support of this proposal. The introduction of a batch poster to assist and the possibility of changing addresses for the rollup are positive steps toward enhancing the network's security. This proposal appears to have beneficial impacts with minimal risks. Upon examining the smart contract aspect, we found that it pertains to managing permissions, which presents no concerns. Furthermore, it has undergone an audit by Trail of Bits, a reputable firm in the web3 audit space, assuring us of its integrity and security.
I have voted in favor of this proposal as it presents a necessary improvement and streamlines the process of altering the batch poster keys.
I'm voting in favor of this upgrade since the transactions costs will be reduced in the network and it is compatible with the reasoning for blobs in L1. I'm not aware of any technical issue at the moment of writting this comment
The Savvy DeFi DAO's Arbitrum Council has voted in favor of this proposal
The introduction of shielded voting adds integrity. Additionally, a dedicated week for candidates to apply makes the process fairer, more competitive, and accessible, eliminating unfair advantages and providing more time for application finalization.
The Savvy DeFi DAO's Arbitrum Council has voted in favor of this proposal
The introduction of shielded voting adds integrity. Additionally, a dedicated week for candidates to apply makes the process fairer, more competitive, and accessible, eliminating unfair advantages and providing more time for application finalization.
Overall, these changes enhance the democratic nature of the Security Council elections, making them more equitable and transparent.
Treasure’s Arbitrum Representative Council voted “For” this proposal on the On-Chain Tally vote.
As described above, we continue to have full confidence in the Offchain Labs team’s ability to continually enhance the Arbitrum ecosystem through their technical expertise. While we depend on our more technically inclined delegates and community members to raise any concerns, it’s evident that the proposed improvements offer undeniable value with no apparent challenges.
I will be maintain my Snapshot "For" vote for the final On-Chain Tally vote. I will echo that I trust the Arbitrum team's ability and technical expertise in this manner.
Thank you to the team for providing the Security Assement report before voting. This step gives me even more confidence in the vote and it is appreciated. After reading the report, it looks like there was only 1 possible issue which was promptly resolved during the process.
Look forward to this upgrade, as I'll always be a fan of anything that can help with scalability!
The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.
Despite its technical complexity, the Batch Poster Manager and Sequencer Inbox Finality Fix brings security benefits to the ecosystem with minimal risks. The DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).
We commend @sam.ng and @dzack23 for providing clear explanations that helped us better understand the proposal.
Additionally, having Trail of Bits, a reputable firm, validate the proposal ensures integrity and security in its execution.
We will closely follow the development of the report before making our final decision when the proposal is ready to go on chain, ensuring that it only performs as intended.
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 in favour of the proposal as the proposed fixes make sense from a security perspective. We’ll make sure to check the proposed code before the on-chain vote to ensure it only does what it’s supposed to.
Our team voted FOR this proposal. A detailed explanation of the essence of this proposal and competent answers to our questions and comments make it clear that this is a thoughtful and proven update for the Arbitrum network.
The Princeton Blockchain Club is voting in favor of these batch posting improvements on Snapshot, as they both increase Arbitrum's resiliency.
The batch poster manager role is nice to have in case of key compromise, and the new values for futureBlocks and futureSeconds are in line with our understanding of ETH PoS checkpointing / Casper FFG.
The Princeton Blockchain Club is voting in favor of these batch posting improvements on Snapshot, as they both increase Arbitrum's resiliency.
The batch poster manager role is nice to have in case of key compromise, and the new values for futureBlocks and futureSeconds are in line with our understanding of ETH PoS checkpointing / Casper FFG.
Kudos to @sam.ng and @dzack23 for the TL;DRs and further explanations for the changes! Should be helpful for all delegates.
Hope to see good audit results, as usual.
The Princeton Blockchain Club is voting in favor of the ArbOS v20 upgrade on Snapshot. We remain excited about the cost-saving potential of blobs and the addition of new OPCODEs to keep the EVM version up to date.
We look forward to the audit results before voting onchain!
The Princeton Blockchain Club is voting in favor of the ArbOS v20 upgrade on Snapshot. We remain excited about the cost-saving potential of blobs and the addition of new OPCODEs to keep the EVM version up to date.
We look forward to the audit results before voting onchain!
Thank you for the explanation, I will echo @JoJo that I think having some type of explanation like this tied to technical proposals would be very helpful for the delegates!
As I've said with other votes of this nature, I will be voting "For" this as I trust the knowledge and expertise of teams involved with these types of updates. As well as other more technical delegates to flag any oversights. I do believe based on the explanations I've seen in this thread that as a broad concept this will be a great added security feature and think it should be implemented.
I support this proposal based on the information provided. I specifically appreciate the focus on improving security and resilience without compromising the trust model.
Also, thanks a lot for the ELI5s! Those should be part of every technical thread.
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.
After reviewing the proposed upgrade on a surface level, we’ll be voting in its favour during temp check. We’ll perform a deeper review of the code of the proposed changes before the on-chain vote.
Treasure’s Arbitrum Representative Council voted “For” this proposal.
We have full confidence in the Offchain Labs team's ability to continually enhance the Arbitrum ecosystem through their technical expertise. We rely on other more technical focused delegates and community members to flag any concerns if they arise, but there seems no challenge to the value of the improvements proposed here.
Treasure’s Arbitrum Representative Council voted “For” this proposal.
We have full confidence in the Offchain Labs team's ability to continually enhance the Arbitrum ecosystem through their technical expertise. While we depend on our more technically inclined delegates and community members to raise any concerns, it's evident that the proposed improvements offer undeniable value with no apparent challenges.
The Savvy DeFi DAO's Arbitrum Council has unanimously voted IN FAVOR of this proposal.
Given that Atlas enables cost reductions for transactions through the utilization of blob storage formats for data, alongside other valuable ecosystem features, we understand the importance of implementing these updates.
The Savvy DeFi DAO's Arbitrum Council has unanimously voted IN FAVOR of this proposal.
Given that Atlas enables cost reductions for transactions through the utilization of blob storage formats for data, alongside other valuable ecosystem features, we understand the importance of implementing these updates.
Additionally, obtaining audit results from OffchainLabs before going On Chain would be greatly appreciated to further support the upgrade and advancement of the ecosystem.
I voted for this temp check on Snapshot. I appreciate the security-minded improvement from Offchain Labs!
I voted for this temp check proposal on Snapshot. Excited for 4844 support!
this actually helps a truckload thanks <3 <3 <3
- Why exactly this value and why such a significant increase?
The old value of 12 blocks was set while Ethereum still used proof of work, where finality is probabilistic and essentially subjective. With POS, 64 blocks is two epochs / gives absolute finality, so that value is used as the cutoff point. To be sure: this just means that if there is an L1 reorg of less than 64 blocks after a batch transaction is signed, the tx will not revert.
I have a technical questions. The current contract says that we have following values:
futureBlocks : 12 futureSeconds : 3600
But now you suggest replacing the value by 6 times.
futureSeconds is 3600 and doesn't depends on futureBlocks * 12. Why we need to decrease futureSeconds when we increase futureBlocks?
Penn Blockchain/FranklinDAO supports these updates to ArbOS. We're excited to see support for blobs and transient storage to improve Ethereum scalability and state growth problems, and the explanations for why certain EIPs and opcodes were excluded are logical and appreciated.
Penn Blockchain/FranklinDAO supports this proposal - the extra permissions of will allow for update of Batch Poster address without need for a DAO vote which would take longer in cases of compromise. Also the extended MaxTimeVariation could help prevent invalid batches due to re-orgs, which we think is important and should have been updated earlier.
ELI5 for batch poster manager: Instead of the sequencer only posting batches from a single address, it has a hot wallet and a cold wallet; it posts batches from the hot wallet and can swap out the hot wallet address with a new one using the cold wallet.
Voting "For" - I trust the Arbitrum team's ability grow and build the protocol on a technical level, and appreciate their work on this!
Would dare to say that like most (but not all) in this forum I can probably understand about 0.1% of what is written here. And an ELI5 would be beneficial for everybody, so if someone wants to chim in please do, also understanding that this can be simplified up to a certain point.
Beside this, good that there are not critical findings in the audit. And, above all, I trust our offchain overlords to deliver on this so voting yes.
I will be maintain my Snapshot "For" vote for the final On-Chain Tally vote. I will echo that I trust the Arbitrum team's ability and technical expertise in this manner.
Thank you to the team for providing the Security Assement report before voting. This step gives me even more confidence in the vote and it is appreciated. After reading the report, it looks like there was only 1 possible issue which was promptly resolved during the process.
Look forward to this upgrade, as I'll always be a fan of anything that can help with scalability!
The Savvy DeFi DAO’s Arbitrum Council has decisively voted FOR this proposal.
Despite its technical complexity, the Batch Poster Manager and Sequencer Inbox Finality Fix brings security benefits to the ecosystem with minimal risks. The DAO would still have the same ability to revoke the Sequencer role; i.e., the DAO could update the batch poster manager (along with any batch posters).
We commend @sam.ng and @dzack23 for providing clear explanations that helped us better understand the proposal.
Additionally, having Trail of Bits, a reputable firm, validate the proposal ensures integrity and security in its execution.
We will closely follow the development of the report before making our final decision when the proposal is ready to go on chain, ensuring that it only performs as intended.
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 in favour of the proposal as the proposed fixes make sense from a security perspective. We’ll make sure to check the proposed code before the on-chain vote to ensure it only does what it’s supposed to.
Our team voted FOR this proposal. A detailed explanation of the essence of this proposal and competent answers to our questions and comments make it clear that this is a thoughtful and proven update for the Arbitrum network.
The Princeton Blockchain Club is voting in favor of these batch posting improvements on Snapshot, as they both increase Arbitrum's resiliency.
The batch poster manager role is nice to have in case of key compromise, and the new values for futureBlocks and futureSeconds are in line with our understanding of ETH PoS checkpointing / Casper FFG.
The Princeton Blockchain Club is voting in favor of these batch posting improvements on Snapshot, as they both increase Arbitrum's resiliency.
The batch poster manager role is nice to have in case of key compromise, and the new values for futureBlocks and futureSeconds are in line with our understanding of ETH PoS checkpointing / Casper FFG.
Kudos to @sam.ng and @dzack23 for the TL;DRs and further explanations for the changes! Should be helpful for all delegates.
Hope to see good audit results, as usual.
The Princeton Blockchain Club is voting in favor of the ArbOS v20 upgrade on Snapshot. We remain excited about the cost-saving potential of blobs and the addition of new OPCODEs to keep the EVM version up to date.
We look forward to the audit results before voting onchain!
The Princeton Blockchain Club is voting in favor of the ArbOS v20 upgrade on Snapshot. We remain excited about the cost-saving potential of blobs and the addition of new OPCODEs to keep the EVM version up to date.
We look forward to the audit results before voting onchain!
Thank you for the explanation, I will echo @JoJo that I think having some type of explanation like this tied to technical proposals would be very helpful for the delegates!
As I've said with other votes of this nature, I will be voting "For" this as I trust the knowledge and expertise of teams involved with these types of updates. As well as other more technical delegates to flag any oversights. I do believe based on the explanations I've seen in this thread that as a broad concept this will be a great added security feature and think it should be implemented.
I support this proposal based on the information provided. I specifically appreciate the focus on improving security and resilience without compromising the trust model.
Also, thanks a lot for the ELI5s! Those should be part of every technical thread.
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.
After reviewing the proposed upgrade on a surface level, we’ll be voting in its favour during temp check. We’ll perform a deeper review of the code of the proposed changes before the on-chain vote.
Treasure’s Arbitrum Representative Council voted “For” this proposal.
We have full confidence in the Offchain Labs team's ability to continually enhance the Arbitrum ecosystem through their technical expertise. We rely on other more technical focused delegates and community members to flag any concerns if they arise, but there seems no challenge to the value of the improvements proposed here.
Treasure’s Arbitrum Representative Council voted “For” this proposal.
We have full confidence in the Offchain Labs team's ability to continually enhance the Arbitrum ecosystem through their technical expertise. While we depend on our more technically inclined delegates and community members to raise any concerns, it's evident that the proposed improvements offer undeniable value with no apparent challenges.
The Savvy DeFi DAO's Arbitrum Council has unanimously voted IN FAVOR of this proposal.
Given that Atlas enables cost reductions for transactions through the utilization of blob storage formats for data, alongside other valuable ecosystem features, we understand the importance of implementing these updates.
The Savvy DeFi DAO's Arbitrum Council has unanimously voted IN FAVOR of this proposal.
Given that Atlas enables cost reductions for transactions through the utilization of blob storage formats for data, alongside other valuable ecosystem features, we understand the importance of implementing these updates.
Additionally, obtaining audit results from OffchainLabs before going On Chain would be greatly appreciated to further support the upgrade and advancement of the ecosystem.
I voted for this temp check on Snapshot. I appreciate the security-minded improvement from Offchain Labs!
I voted for this temp check proposal on Snapshot. Excited for 4844 support!
this actually helps a truckload thanks <3 <3 <3
- Why exactly this value and why such a significant increase?
The old value of 12 blocks was set while Ethereum still used proof of work, where finality is probabilistic and essentially subjective. With POS, 64 blocks is two epochs / gives absolute finality, so that value is used as the cutoff point. To be sure: this just means that if there is an L1 reorg of less than 64 blocks after a batch transaction is signed, the tx will not revert.
I have a technical questions. The current contract says that we have following values:
futureBlocks : 12 futureSeconds : 3600
But now you suggest replacing the value by 6 times.
futureSeconds is 3600 and doesn't depends on futureBlocks * 12. Why we need to decrease futureSeconds when we increase futureBlocks?Penn Blockchain/FranklinDAO supports these updates to ArbOS. We're excited to see support for blobs and transient storage to improve Ethereum scalability and state growth problems, and the explanations for why certain EIPs and opcodes were excluded are logical and appreciated.
Penn Blockchain/FranklinDAO supports this proposal - the extra permissions of will allow for update of Batch Poster address without need for a DAO vote which would take longer in cases of compromise. Also the extended MaxTimeVariation could help prevent invalid batches due to re-orgs, which we think is important and should have been updated earlier.
ELI5 for batch poster manager: Instead of the sequencer only posting batches from a single address, it has a hot wallet and a cold wallet; it posts batches from the hot wallet and can swap out the hot wallet address with a new one using the cold wallet.
Voting "For" - I trust the Arbitrum team's ability grow and build the protocol on a technical level, and appreciate their work on this!
Would dare to say that like most (but not all) in this forum I can probably understand about 0.1% of what is written here. And an ELI5 would be beneficial for everybody, so if someone wants to chim in please do, also understanding that this can be simplified up to a certain point.
Beside this, good that there are not critical findings in the audit. And, above all, I trust our offchain overlords to deliver on this so voting yes.
- Why exactly this value and why such a significant increase?
The old value of 12 blocks was set while Ethereum still used proof of work, where finality is probabilistic and essentially subjective. With POS, 64 blocks is two epochs / gives absolute finality, so that value is used as the cutoff point. To be sure: this just means that if there is an L1 reorg of less than 64 blocks after a batch transaction is signed, the tx will not revert.
- Now
futureSecondsis 3600 and doesn’t depends onfutureBlocks * 12.Why we need to decreasefutureSecondswhen we increasefutureBlocks?
You're right that the current value of futureSeconds is higher than the equivalent for future blocks. In practice, this doesn't really matter since the contract's conditional is conjunctive (both need to pass for the tx to succeed), so the "lower" time value is the one that actually takes effect. Still, for this upgrade, the futureSeconds value is set to correspond to the new futureBlocks value, for clarity and simplicity.
We will support the ArbOS Version 20 "Atlas" proposal driven by its potential to lower transaction costs, ensure compatibility with Ethereum's upgrades, and introduce operational efficiencies.
Voted for. Excited for the benefits coming from the EIP4844 in particular. Question @Arbitrum - Will the audit be published before the DAO is required to vote on Tally?
Voting "for", we all trust our dear arbi lords, plus the enhancements for Orbit can only make life easier for the adoption
Excited to finally see blobs and transient storage support! Hope the audits go well!
- Why exactly this value and why such a significant increase?
The old value of 12 blocks was set while Ethereum still used proof of work, where finality is probabilistic and essentially subjective. With POS, 64 blocks is two epochs / gives absolute finality, so that value is used as the cutoff point. To be sure: this just means that if there is an L1 reorg of less than 64 blocks after a batch transaction is signed, the tx will not revert.
- Now
futureSecondsis 3600 and doesn’t depends onfutureBlocks * 12.Why we need to decreasefutureSecondswhen we increasefutureBlocks?
You're right that the current value of futureSeconds is higher than the equivalent for future blocks. In practice, this doesn't really matter since the contract's conditional is conjunctive (both need to pass for the tx to succeed), so the "lower" time value is the one that actually takes effect. Still, for this upgrade, the futureSeconds value is set to correspond to the new futureBlocks value, for clarity and simplicity.
We will support the ArbOS Version 20 "Atlas" proposal driven by its potential to lower transaction costs, ensure compatibility with Ethereum's upgrades, and introduce operational efficiencies.
Voted for. Excited for the benefits coming from the EIP4844 in particular. Question @Arbitrum - Will the audit be published before the DAO is required to vote on Tally?
Voting "for", we all trust our dear arbi lords, plus the enhancements for Orbit can only make life easier for the adoption
Excited to finally see blobs and transient storage support! Hope the audits go well!