Add Support for EIP-4788
Constitutional
Proposal to add support for EIP-4788 within the Aribitrum Nitro stack.
The integration of EIP-4788 into Arbitrum’s Nitro stack represents a significant step forward in enhancing the functionality and interoperability of the Arbitrum network. EIP-4788, which introduces a standardized method for accessing Ethereum’s state from Layer 2 (L2) solutions, is crucial for the continued growth and scalability of the Ethereum ecosystem. By supporting EIP-4788, Arbitrum can provide developers with more robust tools to build decentralized applications that benefit from and contribute to the future of Ethereum interoperability.
This proposal aims to address the growing demand for seamless interaction between L1 (L1) and L2 solutions. As the Ethereum network continues to expand, the ability to access and utilize Ethereum’s state from L2 becomes increasingly important.
Furthermore, supporting EIP-4788 aligns with Arbitrum’s commitment to innovation and leadership in the L2 space. By adopting this improvement proposal, Arbitrum will solidify its position as a forward-thinking platform that prioritizes the needs of its developers and users. This integration will pave the way for more advanced and scalable dApps, ultimately contributing to the broader adoption and success of the Ethereum ecosystem.
The rationale behind integrating EIP-4788 into Arbitrum’s Nitro stack is multifaceted, addressing both technical and strategic objectives that are crucial for the advancement of the Arbitrum network and the broader Ethereum ecosystem.
We believe including EIP-4788 in nitro rollups would improve their composability in a number of ways:
Additionally, the implementation of this EIP does not affect the reorg risk of the rollup. Reorg risk is mainly dependent on when L1 inputs (e.g. delayed inbox) are read into the L2. For Arbitrum specifically, this risk varies depending on the delayed sequencer configuration. Note that reorg risk arises from the execution sequencer reading in latest L1 headers via a subscription (more details in the “Steps to Implement” section).
finalize-distance: reorg risk increases the shorter the distanceuse-merge-finality: default mode, low reorg riskrequire-full-finality: no reorg riskThe active EigenLayer AVS operator set for EigenDA (and other AVSs) is stored within L1 state. Access to trusted L1 state which holds this active operator set enables trust minimized verification of DA certifications on L2s/3s. This simplifies and unifies efforts to bridge L1 state to L2s/L3s, avoiding the need for bespoke solutions for alt-DA integrations
Lagrange is a ZK co-processor that provides a queryable verifiable database over the current and historical state of Ethereum. It does so by generating ZK storage proofs against Ethereum state. Access to trusted L1 state gives Lagrange an L1 state root to verify their ZK storage proofs against.
This RIP introduces a comprehensive interoperability standard for intent-based cross-chain function calls, which are validated and settled through storage proofs. These storage proofs necessitate access to a trusted L1 state, which serves as the foundational reference for the connected L2 solutions that are settling transactions via their respective native bridges.
This proposal introduces a method to make cross-rollup transactions contingent on the shared L1 history of communicating L2 rollups. This naturally relies on trustless access to L1 state within L2 rollups.
This ERC can enable trustless reads of L1 state but only if there’s access to trusted L1 state on the L2 to verify storage proofs against. The actual data is pulled by off-chain actors and is not inherently trusted.
Access to trusted L1 history and state would facilitate the implementation of this L1SLOAD precompile by giving a reference point from which to query the storage slot from the L1. This precompile requires an explicit association between an L2 and an L1 block.
See the official EIP for detailed specifications.
In Geth, the EIP-4788 beacon root precompile contract is configured and deployed at genesis. Beacon root updates are applied as direct system level transactions against the precompile. Arbitrum Nitro supports the WebAssembly (wasm) instruction set, enabling it to utilize Geth itself within the L2 state machine. This capability allows Nitro to support EIP-4788 through its Geth implementation.
When the ParentBeaconRoot field on the execution header is populated, a beacon root update is applied with the new beacon root. On L1, this field is set by the consensus client calling the execution client. Since there is no consensus client on L2, this field must be manually set within the chain derivation process.
Unlike the OP stack, Nitro does not use the engine API to talk to Geth. It instead wraps Geth in a custom sequencer implementation (gethexec sequencer) which talks to the Geth execution engine. The execution engine exposes an API to sequence transactions and accepts an L1IncomingMessageHeader struct as an input. An additional field for ParentBeaconRoot could be added to the struct here.
The main issue at this point is that the L1 headers processed by the gethexec sequencer are not tied to the actual L1 transactions derived from the delayed inbox. The header update fn runs in a loop reading from subscription to newHeads of the L1. This design materially increases reorg risk if we start reading in the latest L1 beacon root in addition to block number.
Instead of reading in L1 headers via a subscription to the latest L1 head, the gethexec sequencer should read L1 headers via the delayed sequencer and delayed inbox.
The updateLatestParentChainBlock function could be made public and exposed to the delayed sequencer, which already has access to the gethexec sequencer to sequence delayed transactions. The delayed sequencer is already reading in L1 headers and also ensures that these headers match the configured finality level.
The delayed sequencer could then write the corresponding L1 header at the correct finality level to the gethexec sequencer when it sequences delayed transactions. Once the ParentBeaconRoot reaches the execution engine, a direct system-level transaction can be created targeting the beacon root precompile before the block is created.
TBD
N/A
Add Support for EIP-4788
Constitutional
Proposal to add support for EIP-4788 within the Aribitrum Nitro stack.
The integration of EIP-4788 into Arbitrum’s Nitro stack represents a significant step forward in enhancing the functionality and interoperability of the Arbitrum network. EIP-4788, which introduces a standardized method for accessing Ethereum’s state from Layer 2 (L2) solutions, is crucial for the continued growth and scalability of the Ethereum ecosystem. By supporting EIP-4788, Arbitrum can provide developers with more robust tools to build decentralized applications that benefit from and contribute to the future of Ethereum interoperability.
This proposal aims to address the growing demand for seamless interaction between L1 (L1) and L2 solutions. As the Ethereum network continues to expand, the ability to access and utilize Ethereum’s state from L2 becomes increasingly important.
Furthermore, supporting EIP-4788 aligns with Arbitrum’s commitment to innovation and leadership in the L2 space. By adopting this improvement proposal, Arbitrum will solidify its position as a forward-thinking platform that prioritizes the needs of its developers and users. This integration will pave the way for more advanced and scalable dApps, ultimately contributing to the broader adoption and success of the Ethereum ecosystem.
The rationale behind integrating EIP-4788 into Arbitrum’s Nitro stack is multifaceted, addressing both technical and strategic objectives that are crucial for the advancement of the Arbitrum network and the broader Ethereum ecosystem.
We believe including EIP-4788 in nitro rollups would improve their composability in a number of ways:
Additionally, the implementation of this EIP does not affect the reorg risk of the rollup. Reorg risk is mainly dependent on when L1 inputs (e.g. delayed inbox) are read into the L2. For Arbitrum specifically, this risk varies depending on the delayed sequencer configuration. Note that reorg risk arises from the execution sequencer reading in latest L1 headers via a subscription (more details in the “Steps to Implement” section).
finalize-distance: reorg risk increases the shorter the distanceuse-merge-finality: default mode, low reorg riskrequire-full-finality: no reorg riskThe active EigenLayer AVS operator set for EigenDA (and other AVSs) is stored within L1 state. Access to trusted L1 state which holds this active operator set enables trust minimized verification of DA certifications on L2s/3s. This simplifies and unifies efforts to bridge L1 state to L2s/L3s, avoiding the need for bespoke solutions for alt-DA integrations
Lagrange is a ZK co-processor that provides a queryable verifiable database over the current and historical state of Ethereum. It does so by generating ZK storage proofs against Ethereum state. Access to trusted L1 state gives Lagrange an L1 state root to verify their ZK storage proofs against.
This RIP introduces a comprehensive interoperability standard for intent-based cross-chain function calls, which are validated and settled through storage proofs. These storage proofs necessitate access to a trusted L1 state, which serves as the foundational reference for the connected L2 solutions that are settling transactions via their respective native bridges.
This proposal introduces a method to make cross-rollup transactions contingent on the shared L1 history of communicating L2 rollups. This naturally relies on trustless access to L1 state within L2 rollups.
This ERC can enable trustless reads of L1 state but only if there’s access to trusted L1 state on the L2 to verify storage proofs against. The actual data is pulled by off-chain actors and is not inherently trusted.
Access to trusted L1 history and state would facilitate the implementation of this L1SLOAD precompile by giving a reference point from which to query the storage slot from the L1. This precompile requires an explicit association between an L2 and an L1 block.
See the official EIP for detailed specifications.
In Geth, the EIP-4788 beacon root precompile contract is configured and deployed at genesis. Beacon root updates are applied as direct system level transactions against the precompile. Arbitrum Nitro supports the WebAssembly (wasm) instruction set, enabling it to utilize Geth itself within the L2 state machine. This capability allows Nitro to support EIP-4788 through its Geth implementation.
When the ParentBeaconRoot field on the execution header is populated, a beacon root update is applied with the new beacon root. On L1, this field is set by the consensus client calling the execution client. Since there is no consensus client on L2, this field must be manually set within the chain derivation process.
Unlike the OP stack, Nitro does not use the engine API to talk to Geth. It instead wraps Geth in a custom sequencer implementation (gethexec sequencer) which talks to the Geth execution engine. The execution engine exposes an API to sequence transactions and accepts an L1IncomingMessageHeader struct as an input. An additional field for ParentBeaconRoot could be added to the struct here.
The main issue at this point is that the L1 headers processed by the gethexec sequencer are not tied to the actual L1 transactions derived from the delayed inbox. The header update fn runs in a loop reading from subscription to newHeads of the L1. This design materially increases reorg risk if we start reading in the latest L1 beacon root in addition to block number.
Instead of reading in L1 headers via a subscription to the latest L1 head, the gethexec sequencer should read L1 headers via the delayed sequencer and delayed inbox.
The updateLatestParentChainBlock function could be made public and exposed to the delayed sequencer, which already has access to the gethexec sequencer to sequence delayed transactions. The delayed sequencer is already reading in L1 headers and also ensures that these headers match the configured finality level.
The delayed sequencer could then write the corresponding L1 header at the correct finality level to the gethexec sequencer when it sequences delayed transactions. Once the ParentBeaconRoot reaches the execution engine, a direct system-level transaction can be created targeting the beacon root precompile before the block is created.
TBD
N/A
My name is Bo Du. I don't work for the Arb Foundation or Offchain Labs. I'm a co-founder of an interoperability project on Ethereum called Polymer. We're focused on rollup <> rollup connectivity.
We collaborated and chatted with a number of folks at different organizations (e.g. Base, Eco, Lagrange, Eigenlayer etc.) on this proposal.
My name is Bo Du. I don't work for the Arb Foundation or Offchain Labs. I'm a co-founder of an interoperability project on Ethereum called Polymer. We're focused on rollup <> rollup connectivity.
We collaborated and chatted with a number of folks at different organizations (e.g. Base, Eco, Lagrange, Eigenlayer etc.) on this proposal.
I think you're correct. Changes to merkleization in Ethereum forks could potentially affect SSZ proof verifier code.
In most cases, regenerating a proof should be sufficient.
However, if things like the hash function used changes then it would break existing SSZ proof verifier code.
https://github.com/base-org/RIP-7755-poc/blob/main/contracts/src/libraries/SSZ.sol
I think you're correct. Changes to merkleization in Ethereum forks could potentially affect SSZ proof verifier code.
In most cases, regenerating a proof should be sufficient.
However, if things like the hash function used changes then it would break existing SSZ proof verifier code.
https://github.com/base-org/RIP-7755-poc/blob/main/contracts/src/libraries/SSZ.sol
We can see that this proposal is not yet complete, and since it is an entirely technical proposal, we believe that in order for it to move on to the next stage, it should be completed and drafted in as much detail as possible. Beyond that, we would like to know if it has been previously discussed with developers from the DAO or the Foundation.
It would also be good to see a testing phase included in the proposal before its implementation.
Hey @shakeshack thank you for this proposal. I’m generally in favor of upgrades and better interoperability between Ethereum and Arbitrum. Before moving on, I think it would be nice to have a more clear timeline and a testing phase as it was already mentioned in the discussion. Apart from that, I don’t see why we shouldn’t integrate EIP-4788.
Hey @0xDonPepe , based on what I’ve been reading, EIP-7688 helps smart contracts interact with consensus data structures so they won’t need modifications with each network upgrade, making future changes smoother. EIP-4788, on the other hand, allows smart contracts in the execution layer to access and verify data from the consensus layer, enhancing interoperability and trustless verification which is especially useful for applications like bridges.
As for Version 20 Atlas, from what I gathered in this post https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957 , it’s focused on adding support for Dencun and data availability, allowing Arbitrum to post transaction data as blobs on Ethereum through EIP-4844. This upgrade does advance Arbitrum’s alignment with Ethereum but primarily in terms of data scalability.
Hey @0xDonPepe , based on what I’ve been reading, EIP-7688 helps smart contracts interact with consensus data structures so they won’t need modifications with each network upgrade, making future changes smoother. EIP-4788, on the other hand, allows smart contracts in the execution layer to access and verify data from the consensus layer, enhancing interoperability and trustless verification which is especially useful for applications like bridges.
As for Version 20 Atlas, from what I gathered in this post https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957 , it’s focused on adding support for Dencun and data availability, allowing Arbitrum to post transaction data as blobs on Ethereum through EIP-4844. This upgrade does advance Arbitrum’s alignment with Ethereum but primarily in terms of data scalability.
On the broader point, I believe Arbitrum should proactively adapt to each relevant upgrade Ethereum implements. Arbitrum’s future is closely tied to Ethereum’s, and every improvement in scalability, security, and decentralization directly benefits Layer 2 solutions. Keeping Arbitrum’s architecture aligned with Ethereum’s roadmap will help continue attracting users and developers. Projects tend to gravitate toward platforms that stay in sync with Ethereum’s developments, as upgrades like these build trust and credibility.
Given this rationale, I'm fully in favor of this proposal.
Cheers to all.
Basically echoing the previous comments. The EIP seems like a good upgrade and in general it should be added, but I would still like to see a detailed plan on execution and timeline and also someone from a more technical perspective explaining the implications this may have.
Thanks for putting this forward.
Thank you for the proposal @shakeshack, we’re supportive of integrating EIP-4788 into Arbitrum’s Nitro stack.
However, we think that before the DAO votes for the integration, we need the Arbitrum Foundation and OffChain Labs to assess the complexity, risks, and considerations as they should be provided along with this proposal.
Thank you for the proposal @shakeshack, we’re supportive of integrating EIP-4788 into Arbitrum’s Nitro stack.
However, we think that before the DAO votes for the integration, we need the Arbitrum Foundation and OffChain Labs to assess the complexity, risks, and considerations as they should be provided along with this proposal.
We see that you’ve included some rationale, and it includes native interop standards as well. It would be helpful if you could share more on how these align with the broader interoperability direction for the entire Ethereum ecosystem, that Vitalik discussed in the “Uniting Contributors Across Ethereum For An Interoperable Future” panel.
Our stand is FOR with caveats on feedback on how this aligns with the broader Ethereum drive towards interoperability and technical integration evaluation from Arbitrum Foundation and OffChain Labs
Good proposal!
I believe that the implementations in EigenLayer and ZK-co-processors will contribute to the sustainable growth of the Ethereum ecosystem. Together, these tools enhance Ethereum’s scalability, improve developer flexibility, and reduce resource use, fostering a more robust ecosystem. This proposal positions Arbitrum as a leader in innovative L2 solutions, supporting its commitment to Ethereum scalability and providing essential tools for developers. Do you consider a gradual implementation of this EIP necessary to optimize stability and reduce potential interoperability conflicts with other chains?
Hello! Thanks for the proposal.
In addition to the previous questions, can you give a bit of context on why are you proposing this/who you are? As it is a new account it would be nice to have this type of info.
Thank you for the proposal. I don’t have a strong technical background, so I would like to hear feedback from others and the specialy the foundation.
However, I believe that simplifying the L1 state bridge to L2/3s is a crucial step, especially if Eigen AVS plays a significant role in the future.
Thank you for this proposal. I believe that enhancing the functionality and interoperability of the Arbitrum network is the correct move. However, I suggest that the proposal should be more comprehensive, including specifics such as the team or personnel responsible, the task timeline, and the required budget.
Didn't AIP: ArbOS Version 20 “Atlas” add EIP-4788?
I'll be that guy and +1 @jameskbh's question, it seems traditionally these types of technical upgrades come posted from the @Arbitrum account - can we get clarity on who the OP is and why it is coming from them over the traditional process?
Beyond that, I'd like to see more detail on the timeline before voting.
We can see that this proposal is not yet complete, and since it is an entirely technical proposal, we believe that in order for it to move on to the next stage, it should be completed and drafted in as much detail as possible. Beyond that, we would like to know if it has been previously discussed with developers from the DAO or the Foundation.
It would also be good to see a testing phase included in the proposal before its implementation.
Hey @shakeshack thank you for this proposal. I’m generally in favor of upgrades and better interoperability between Ethereum and Arbitrum. Before moving on, I think it would be nice to have a more clear timeline and a testing phase as it was already mentioned in the discussion. Apart from that, I don’t see why we shouldn’t integrate EIP-4788.
Hey @0xDonPepe , based on what I’ve been reading, EIP-7688 helps smart contracts interact with consensus data structures so they won’t need modifications with each network upgrade, making future changes smoother. EIP-4788, on the other hand, allows smart contracts in the execution layer to access and verify data from the consensus layer, enhancing interoperability and trustless verification which is especially useful for applications like bridges.
As for Version 20 Atlas, from what I gathered in this post https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957 , it’s focused on adding support for Dencun and data availability, allowing Arbitrum to post transaction data as blobs on Ethereum through EIP-4844. This upgrade does advance Arbitrum’s alignment with Ethereum but primarily in terms of data scalability.
Hey @0xDonPepe , based on what I’ve been reading, EIP-7688 helps smart contracts interact with consensus data structures so they won’t need modifications with each network upgrade, making future changes smoother. EIP-4788, on the other hand, allows smart contracts in the execution layer to access and verify data from the consensus layer, enhancing interoperability and trustless verification which is especially useful for applications like bridges.
As for Version 20 Atlas, from what I gathered in this post https://forum.arbitrum.foundation/t/aip-arbos-version-20-atlas/20957 , it’s focused on adding support for Dencun and data availability, allowing Arbitrum to post transaction data as blobs on Ethereum through EIP-4844. This upgrade does advance Arbitrum’s alignment with Ethereum but primarily in terms of data scalability.
On the broader point, I believe Arbitrum should proactively adapt to each relevant upgrade Ethereum implements. Arbitrum’s future is closely tied to Ethereum’s, and every improvement in scalability, security, and decentralization directly benefits Layer 2 solutions. Keeping Arbitrum’s architecture aligned with Ethereum’s roadmap will help continue attracting users and developers. Projects tend to gravitate toward platforms that stay in sync with Ethereum’s developments, as upgrades like these build trust and credibility.
Given this rationale, I'm fully in favor of this proposal.
Cheers to all.
Basically echoing the previous comments. The EIP seems like a good upgrade and in general it should be added, but I would still like to see a detailed plan on execution and timeline and also someone from a more technical perspective explaining the implications this may have.
Thanks for putting this forward.
Thank you for the proposal @shakeshack, we’re supportive of integrating EIP-4788 into Arbitrum’s Nitro stack.
However, we think that before the DAO votes for the integration, we need the Arbitrum Foundation and OffChain Labs to assess the complexity, risks, and considerations as they should be provided along with this proposal.
Thank you for the proposal @shakeshack, we’re supportive of integrating EIP-4788 into Arbitrum’s Nitro stack.
However, we think that before the DAO votes for the integration, we need the Arbitrum Foundation and OffChain Labs to assess the complexity, risks, and considerations as they should be provided along with this proposal.
We see that you’ve included some rationale, and it includes native interop standards as well. It would be helpful if you could share more on how these align with the broader interoperability direction for the entire Ethereum ecosystem, that Vitalik discussed in the “Uniting Contributors Across Ethereum For An Interoperable Future” panel.
Our stand is FOR with caveats on feedback on how this aligns with the broader Ethereum drive towards interoperability and technical integration evaluation from Arbitrum Foundation and OffChain Labs
Good proposal!
I believe that the implementations in EigenLayer and ZK-co-processors will contribute to the sustainable growth of the Ethereum ecosystem. Together, these tools enhance Ethereum’s scalability, improve developer flexibility, and reduce resource use, fostering a more robust ecosystem. This proposal positions Arbitrum as a leader in innovative L2 solutions, supporting its commitment to Ethereum scalability and providing essential tools for developers. Do you consider a gradual implementation of this EIP necessary to optimize stability and reduce potential interoperability conflicts with other chains?
Hello! Thanks for the proposal.
In addition to the previous questions, can you give a bit of context on why are you proposing this/who you are? As it is a new account it would be nice to have this type of info.
Thank you for the proposal. I don’t have a strong technical background, so I would like to hear feedback from others and the specialy the foundation.
However, I believe that simplifying the L1 state bridge to L2/3s is a crucial step, especially if Eigen AVS plays a significant role in the future.
Thank you for this proposal. I believe that enhancing the functionality and interoperability of the Arbitrum network is the correct move. However, I suggest that the proposal should be more comprehensive, including specifics such as the team or personnel responsible, the task timeline, and the required budget.
Didn't AIP: ArbOS Version 20 “Atlas” add EIP-4788?
I'll be that guy and +1 @jameskbh's question, it seems traditionally these types of technical upgrades come posted from the @Arbitrum account - can we get clarity on who the OP is and why it is coming from them over the traditional process?
Beyond that, I'd like to see more detail on the timeline before voting.
Questions: 1. Treatment of reorganization risk: The proposal mentions that the issue of reorganization risk is addressed through delayed sequencer and delayed inbox, but will the specific implementation have an impact on current network performance or processing efficiency? Is further testing or simulation required? 2. The proposal does not mention in detail the development and maintenance costs for Arbitrum after implementation, for example, will it require long-term optimization or major changes to the existing Nitro stack structure? These need to be clarified. 3. What specific benefits does EIP-4788 bring to developers, such as application scenarios or performance improvements? How many developers have expressed demand or interest in this feature? Is there any relevant survey or feedback to support this direction? Recommendations: 1. It is recommended to divide the proposal into multiple phases, such as proof of concept, test network deployment, main network optimization, etc., and set goals and time nodes for each phase to make it easier for the community to track progress. 2. consider encouraging development teams to develop real-world use cases based on EIP-4788 through a hackathon or developer funding program, especially those projects that demonstrate interoperability and enhanced functionality. 3. It is recommended that teams add specific impact analysis of network performance, user experience, and ecological development to their proposals to ensure that the community has a clear understanding of the potential impact of this proposal.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
Thank you for the proposal.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
Thank you for the proposal.
Because of this proposal, we got the opportunity to read more about EIP-4788. It seems that the benefits of composability, especially with EigenLayer AVS being on Arbitrum, would enable new innovative dApps on Arbitrum.
Though the roll-up seems to have less risk, we would expect a report by an ARDC v2 Security Member to make a confident vote on the proposal.
We would also appreciate sharing specific video links to explain EIP-4788 to a non-technical audience. The resource shared in the Abstract is a good one but difficult to assess the risks associated with it.
We will further delve into it and help shape the proposal if it has a clear advantage for the DAO.
Hey there!
Super excited to see EIP-4788 in action—it’s such a valuable addition! With the ability to validate values directly from the beacon chain, the doors open to a ton of new possibilities.
Hey there!
Super excited to see EIP-4788 in action—it’s such a valuable addition! With the ability to validate values directly from the beacon chain, the doors open to a ton of new possibilities.
While I don’t come from a deeply technical background, I’ve been digging into this proposal to get a better understanding. Along the way, I came across EIP-7688, which seems designed to address compatibility issues that could arise in a hard fork by transitioning the beacon state object to a stable format.
Could you give us a quick rundown on EIP-7688 and whether it’s relevant here? My understanding is that without stable proofs, protocols would need to support continuous upgrades, limiting the potential for true immutability. Does that sound right?
I support your concern that such updates need to be seen from the Foundation.
The proposal itself is good, but such updates certainly need to be carried out with great caution and with audits.
Questions: 1. Treatment of reorganization risk: The proposal mentions that the issue of reorganization risk is addressed through delayed sequencer and delayed inbox, but will the specific implementation have an impact on current network performance or processing efficiency? Is further testing or simulation required? 2. The proposal does not mention in detail the development and maintenance costs for Arbitrum after implementation, for example, will it require long-term optimization or major changes to the existing Nitro stack structure? These need to be clarified. 3. What specific benefits does EIP-4788 bring to developers, such as application scenarios or performance improvements? How many developers have expressed demand or interest in this feature? Is there any relevant survey or feedback to support this direction? Recommendations: 1. It is recommended to divide the proposal into multiple phases, such as proof of concept, test network deployment, main network optimization, etc., and set goals and time nodes for each phase to make it easier for the community to track progress. 2. consider encouraging development teams to develop real-world use cases based on EIP-4788 through a hackathon or developer funding program, especially those projects that demonstrate interoperability and enhanced functionality. 3. It is recommended that teams add specific impact analysis of network performance, user experience, and ecological development to their proposals to ensure that the community has a clear understanding of the potential impact of this proposal.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
Thank you for the proposal.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
Thank you for the proposal.
Because of this proposal, we got the opportunity to read more about EIP-4788. It seems that the benefits of composability, especially with EigenLayer AVS being on Arbitrum, would enable new innovative dApps on Arbitrum.
Though the roll-up seems to have less risk, we would expect a report by an ARDC v2 Security Member to make a confident vote on the proposal.
We would also appreciate sharing specific video links to explain EIP-4788 to a non-technical audience. The resource shared in the Abstract is a good one but difficult to assess the risks associated with it.
We will further delve into it and help shape the proposal if it has a clear advantage for the DAO.
Hey there!
Super excited to see EIP-4788 in action—it’s such a valuable addition! With the ability to validate values directly from the beacon chain, the doors open to a ton of new possibilities.
Hey there!
Super excited to see EIP-4788 in action—it’s such a valuable addition! With the ability to validate values directly from the beacon chain, the doors open to a ton of new possibilities.
While I don’t come from a deeply technical background, I’ve been digging into this proposal to get a better understanding. Along the way, I came across EIP-7688, which seems designed to address compatibility issues that could arise in a hard fork by transitioning the beacon state object to a stable format.
Could you give us a quick rundown on EIP-7688 and whether it’s relevant here? My understanding is that without stable proofs, protocols would need to support continuous upgrades, limiting the potential for true immutability. Does that sound right?
I support your concern that such updates need to be seen from the Foundation.
The proposal itself is good, but such updates certainly need to be carried out with great caution and with audits.