Conversation
🦋 Changeset detectedLatest commit: 952b526 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov Report
@@ Coverage Diff @@
## develop #1798 +/- ##
===========================================
+ Coverage 74.79% 75.16% +0.37%
===========================================
Files 81 81
Lines 2698 2702 +4
Branches 433 435 +2
===========================================
+ Hits 2018 2031 +13
+ Misses 680 671 -9
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Upstream changes can be found here: ethereum/go-ethereum@6487c00 |
|
c8f0076 to
b28fd40
Compare
|
there's a fair bit of EIP-2929 (expected since it's access lists depends on it). Would it be possible to cleanly split this PR into two; the EIP-2929 implementation and another for EIP-2930 rebased on top? Or is the refactor pervasive enough that it won't matter. It would be easier for me to review if this were split up. |
I can definitely split this up more to make it easier to review |
Ok so EIP-2930 is not included as part of this pull request. There are no typed transactions, its EIP-2929, EIP-3529 and EIP-2565 |
55743a2 to
274bd43
Compare
Add in the berlin precompile maps. This code is adopted from upstream. This includes the implementation of EIP-2565 which makes the modular exponentiation precompile found at `address(5)` cheaper. https://eips.ethereum.org/EIPS/eip-2565 The berlin precompile set includes setting the `eip2565` field to true on the `bigExpMod` struct. This implementation is directly taken from upstream. ethereum/go-ethereum@eb21c65
b98aac2 to
3207853
Compare
These scripts can be used to set up a local development environment to test out sending transactions against If the `DEVELOPMENT` env var is set, then the initial genesis state will include funds for the signer address. This prevents the need to deposit funds or manually edit the genesis json file.
The hardfork block will need to be determined and the genesis json file will need to be recreated. This will by default set the height to 0 so that the development networks start with berlin activated.
Add integration tests to test the hardfork logic
| @@ -0,0 +1,58 @@ | |||
| import { task } from 'hardhat/config' | |||
There was a problem hiding this comment.
How is this file used?
There was a problem hiding this comment.
I use this file to assert that the block hashes of two separate replicas/sequencers match.
| ) | ||
| const preBerlinTrace = await env.l2Provider.send( | ||
| 'debug_traceTransaction', | ||
| ['0x2bb346f53544c5711502fbcbd1d78dc4fb61ca5f9390b9d6d67f1a3a77de7c39'] |
There was a problem hiding this comment.
Where does this transaction hash come from?
There was a problem hiding this comment.
All the nightly transaction hashes come from a run of the hardfork integration tests before the HF activated on nightly. This lets us prove that the gas schedule was correct before the HF activated without overrides.
| ) | ||
| const preBerlinTrace = await env.l2Provider.send( | ||
| 'debug_traceTransaction', | ||
| [tx.hash, { overrides: { berlinBlock: tip.number * 2 } }] |
There was a problem hiding this comment.
I assume berlin should be enabled by default in the integration tests, is this not the case?
There was a problem hiding this comment.
It is enabled by default. To disable it, we move the activation block out by some amount. In this case we're using tip.number * 2 to account for how nightly is continually ingesting transactions in the background and we need more buffer.
|
Does this include all of the EIPs from Berlin? |
|
I think if this does not include all of the EIPs from Berlin, we should probably not call it Berlin. Maybe we can call it Berlondon, lol. |
|
It doesn't contain EIP-2718 and EIP-2930 - basically anything to do with typed transactions. |
|
Generally this LGTM with the caveat that I don't think we should call the fork Berlin if we're not actually 1:1 with Berlin yet. |
## Description This PR adds a CI workflow for e2e testing tools using kurtosis.
Description
Implement the first hard fork to happen on Optimism. It is called "Berlin" but it actually includes 2 EIPs from Berlin and 1 from London. Thoughts on using a different name or is Berlin fine?
The features include:
This will make the network have the same gas metering as mainnet ethereum, while not supporting typed transactions.
EIP 2929 adds the concept of warm and cold storage through access lists. Optimism previously increased the cost of state accessing opcodes above the Istanbul costs to prevent denial of service attacks on the network. These attacks are prohibitively expensive as the base hardware requirement for an L2 node is higher than the base requirement for a L1 node.
EIP 2565 reduces the cost of the modular exponentiation precompile, found at
address(5)EIP 3529 bricks gas token by reducing refunds from
selfdestruct. If gas token was allowed, then users would be able to speculate on L1 gas prices on L2 due to the L2 fees being driven by L1 fees.We need to ensure that this PR can sync existing mainnet without any execution divergences. It should because the existing
genesis.jsonfile does not define aberlinBlockhardfork height. We will need to determine the hardfork height and then have all nodes rungeth initwith the newgenesis.json. Once consensus is established around the height at which we will be hardforking, we will make the newgenesis.jsonavailable. The only change that needs to happen is defining theberlinBlockfield.All node operators must upgrade their software as this is a hardfork. There will be ample communications to ensure that everybody is properly upgraded.
The opcode gas changes for EIP 2929 and EIP 3529 are in 4a85d6b58246da8f1284c12e118407fe8b89802f