-
Notifications
You must be signed in to change notification settings - Fork 20.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/geth: implement dev mode for post-merge #27327
Conversation
Haven't looked at the code, but why would one want to pass jwtsecret? Shouldn't it just be |
@holiman yup. That's something I've noted in todo list above. Trying to address those today. |
GasLimit: gasLimit, | ||
BaseFee: big.NewInt(params.InitialBaseFee), | ||
Difficulty: big.NewInt(1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it a bit weird that the genesis block has a non-zero difficulty:
> eth.getBlock(0).difficulty
131072
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was very difficult genecizing this genesis block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difficulty formula is undefined for difficulties <131072
. There is a minimum difficulty, and below that, the spec can be interpreted in two different ways, depending on at what exact step one decides to apply the minimum threshold.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For testing use-cases it would be nice to also have a way of setting safe and finalized blocks through clmock. As well as pushing withdrawals. Possibly adding a dev
namespace in the RPC for this purpose?
Okay. This is getting closer. Two items still need to be addressed:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few questions
GasLimit: gasLimit, | ||
BaseFee: big.NewInt(params.InitialBaseFee), | ||
Difficulty: big.NewInt(1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was very difficult genecizing this genesis block
params/config.go
Outdated
Clique *CliqueConfig `json:"clique,omitempty"` | ||
Ethash *EthashConfig `json:"ethash,omitempty"` | ||
Clique *CliqueConfig `json:"clique,omitempty"` | ||
Dev *DeveloperModeConfig `json:"dev,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just my 2 cents here: I feel this is overkill, because you can just pass it as a command line option, and use that parameter when instantiating the CLMock
. So you could reduce the footprint of that PR by not adding more config here, since it's really only used in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but it must be persisted in the case where dev mode is not being used ephemerally. Hence I add DeveloperModeConfig
so that the period will be stored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
must it, though? if you need it to remain active, all you need to do is add --dev
to your command line. Not going to die on that hill, just feel the PR could be simpler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In dev mode: When you specify --datadir
and --dev
together it persists the chain. if the datadir is omitted, the chain is ephemeral (cleared on shutdown).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also feel this is overkill? Is there ever really a use case to have a dev mode genesis? ChainConfig
is used quite a bit and so we should be confident in the addition here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In DeveloperModeConfig
, there is only a single field period
. It's totally fine to use another value in the next restart I think. We can have a default value for it, e.g. 12s or so, and users can change it by CLI flag.
This comment was marked as resolved.
This comment was marked as resolved.
Alright, I've addressed the remaining issues that I listed above. Adding a few unit tests and then hopefully, this should be ready for merge. |
It occurs to me that it probably makes sense to implement a way to shim-in support for withdrawals. I'll try to think about how this will work. |
23ee876
to
4645e03
Compare
Okay, I've addressed most of the feedback that @lightclient has provided (thanks for that!). The only remaining question is where to put the It can either live under |
I think I lean towards just putting the files into |
Some UX quirks...
When running it, it keep spitting out this:
And that's while I'm not doing anything, just letting it idle. Seems unnecessary? |
simulated_beacon/api.go
Outdated
func (api *API) AddWithdrawal(ctx context.Context, withdrawal *types.Withdrawal) error { | ||
api.simBeacon.mu.Lock() | ||
defer api.simBeacon.mu.Unlock() | ||
return api.simBeacon.withdrawals.add(withdrawal) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is IMO a bit odd. I guess you wanted to split this up into a standalone API in order to make the distinction more clear about what is the public API-surface and what is the actual implementation?
The thing which is a bit odd, IMO, is that you have this external wrapper which reaches in and locks/unlocks an internal mutex inside teh simBeacon
. Either move the mutex to this API
, or, probably better, move the locking so the SimulatedBeacon
controls it's own locks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this type would be a 'pure' wrapper:
func (api *API) AddWithdrawal(ctx context.Context, withdrawal *types.Withdrawal) error { | |
api.simBeacon.mu.Lock() | |
defer api.simBeacon.mu.Unlock() | |
return api.simBeacon.withdrawals.add(withdrawal) | |
} | |
func (api *API) AddWithdrawal(ctx context.Context, withdrawal *types.Withdrawal) error { | |
return api.simBeacon.withdrawals.add(withdrawal) | |
} |
You could even (maybe?) turn this whole file into
type API SimulatedBeacon
func (api *API) AddWithdrawal(ctx context.Context, withdrawal *types.Withdrawal) error {
return api.addWithdrawal(withdrawal)
}
func (api *API) SetFeeRecipient(ctx context.Context, feeRecipient *common.Address) {
api.feeRecipient = *feeRecipient
}
Depends on your preference I guess, but it's less code at least
The last change also requires a change here:
--- a/simulated_beacon/simulated_beacon.go
+++ b/simulated_beacon/simulated_beacon.go
@@ -216,7 +216,7 @@ func RegisterAPIs(stack *node.Node, c *SimulatedBeacon) {
stack.RegisterAPIs([]rpc.API{
{
Namespace: "dev",
- Service: &API{c},
+ Service: (*API)(c),
Version: "1.0",
},
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved the mutex-handling for controlling access for fee recipient and the withdrawals list into SimulatedBeacon
/withdrawals
and pulled them out of the api. This should make things a bit cleaner.
…ullNode. rename feeTarget->feeRecipient and remove getter function
…d in the next payload
…Beacon fields into constructor. Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
26cc87c
to
ba286e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Hi,
Using random account for testing is not a good idea, especially with automation test environment. |
@hadv if you want to fund specific accounts, transfer ether from the coinbase account. There isn't a need for the ability to pre-allocate specific accounts at genesis. |
When using web3j for automation testing, we need Credentials to send fund; but we didn't have Credentials of coinbase account |
v1.12.1 geth changes the default ChainConfig returned with DeveloperGenesisBlock from AllCliqueProtocolChanges to AllDevChainProtocolChanges. Since the dev chain config is not set to clique mode and is set as post-TTD with TTD=0, there needs to be a non-ethhash based consensus engine running in order for blocks to be produced. See the upstream geth change here: ethereum/go-ethereum#27327 This commit copies the initailization code for how geth is started up in dev mode with the simulated beacon node to our test L1 setup code. It also enables FullSync mode on the L1, since otherwise SimluatedBeacon.sealBlock would fail when calling the ConsensusAPI.ForkChoiceUpdatedV2 as it would still be syncing if it was in SnapSync mode. UseMergeFinality was also disabled on the TestDelayedSequencerConfig since the SimulatedBeacon seems to have different finalization behavior.
I've just opened issue #28449 related to this issue - is it possible to run a private Shanghai-EVM-compatible PoA network without |
This change adds back the 'geth --dev' mode of operation, using a cl-mocker. --------- Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: rjl493456442 <garyrong0905@gmail.com> Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
This reverts commit 7818ec3.
This reverts commit 7818ec3.
Opening this as a draft to get eyes on it in its current state, and get feedback if there are obvious things that should be changed.
Currently works with the command:
./build/bin/geth --dev