Skip to content
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

You cannot set the miner.gasPrice to 0 or the txpool.pricelimit to 0 in private chains #27517

Closed
bradbrown-gtmn opened this issue Jun 19, 2023 · 13 comments

Comments

@bradbrown-gtmn
Copy link

          You cannot set the miner.gasPrice to 0, if you try, you'll see a warning in the logs: 
WARN [12-01|11:51:18.506] Sanitizing invalid miner gas price       provided=0    updated=1,000,000,000

Geth explicitly does not allow this because accepting 0 priced transactions would mean that you also accept/pool them from the network and propagate them, which is essentially a very potent DoS vector (I can send arbitrary junk tx from arbitrary non-existing account since there's no cost).

Originally posted by @karalabe in #26285 (comment)

It makes no sense to limit the functionality of geth for developers using private chains because of a potential "attack vector" possibly experienced by geth nodes attached to real networks. You cannot send arbitrary junk tx to my private chain, since it is private and my ports aren't open. Please allow developers to continue to choose to use zero gas transactions in their private chains.

@karalabe
Copy link
Member

You can't really have true zero gas price post 1559 though. The basefee must always be burnt.

It makes no sense to limit the functionality of geth for developers using private chains

Do note, that Geth is an implementation of Ethereum. There never was nor ever will be a promise to support anything else. Our private network support is meant to run testnets for local testing, it is not meant to run alternative production L1s with different rule sets.

You are welcome to use our code - it's open source after all - but wherever you diverge from Ethereum mainnet behavior, it's up to you to support your fork.

@bradbrown-gtmn
Copy link
Author

"Our private network support is meant to run testnets for local testing, it is not meant to run alternative production L1s with different rule sets."

I'm trying to run a testnet for local testing, using transactions with 0 gas costs so that I don't have to fiddle with and set up automation scripts for allocating gas money. Five months ago, I was able to do this just fine. That convenience let me just get right into testing the functionality of Ethereum smart contracts, to be deployed on the Ethereum mainnet. I am not "running alternative production L1s with different rulesets", I am trying to test smart contracts to be deployed on the mainnet.

It's one thing that such a feature should be wanted simply as a quality of life feature for developers, it's another thing that it already existed and it was removed, and there seems to be no adequate reasoning for removing it from the perspective of a developer testing their smart contracts prior to mainnet deployment.

@karalabe
Copy link
Member

karalabe commented Jun 19, 2023 via email

@bradbrown-gtmn
Copy link
Author

I was able to do it without London enabled, genesis looks like

  ..., "homesteadBlock": 0,
  "eip150Block": 0,
  "eip155Block": 0,
  "eip158Block": 0,
  "byzantiumBlock": 0,
  "constantinopleBlock": 0,
  "petersburgBlock": 0,
  "istanbulBlock": 0,
  "berlinBlock": 0, ...

This setup no longer works. There are more comments about it in #26285 (comment), but they are all unanswered.

@karalabe
Copy link
Member

Hmm, ok. So some hard forks only change the EVM internals, but others also introduce behavioural changes to other parts of the code too (e.g. tx pooling). Whilst we do take care during a transition period to be able to operate in both "old" and "new" feature sets, eventually we need to start removing old modes of operation (that are not EVM related) as it's a significant burden to tiptoe around code that is not exercised any more.

We removed Ethash in a similar vein and will remove Clique too because those require the network to do forward sync whereas Ethereum mainnet nowadays operates on sync directed via the beacon chain (backwards). It is a huge piece of code everywhere to keep both modes of operation and track all the attack vectors and mitigations for both.

Similarly, transaction pooling is constantly evolving, we are introducing blob transactions now which requires a complete overhaul of the tx pooling and there's no reason to re-introduce old mechanisms into the new transaction pools that serve no purpose any more.

My only suggestion is that you need to keep up with the Ethereum hard forks on private networks too as our code base is constantly evolving to track the current network behaviour and we don't have the capacity to be indefinitely backwards compatible to all past versions of network that someone uses.

@bradbrown-gtmn
Copy link
Author

Do you not agree that this feature would still be very convenient and useful for Ethereum mainnet smart contract developers right now, and would remain convenient and useful for as long as Ethereum transactions require some form of gas? That enabling 0-gas transactions in developer private chains would allow developers to test the functionality of their smart contracts without needing to manage the gas of every address involved in testing? The beacon chain still uses gas, doesn't it, so this would apply to that, too?

@bradbrown-gtmn
Copy link
Author

And even more importantly, if "We removed Ethash in a similar vein and will remove Clique too" is true, then why does the documentation page (https://geth.ethereum.org/docs/fundamentals/private-network) about private networks recommend either of those at all? Is there any documentation about making a private Beacon chain (perhaps one where gas costs can be made zero for development convenience)?

@chenjia404
Copy link
Contributor

You can easily get gas for private chains

@bradbrown-gtmn
Copy link
Author

Was taking a look at the documentation again, noticed that it explicitly says that enabling dev mode "Sets the gas price to 0".
https://geth.ethereum.org/docs/developers/dapp-developer/dev-mode
image
@karalabe Geth's sanitizing of a gas price of 0 and allowing a gas price of 0 for dev mode is contradictory, and it is clear that one or the other is an issue that needs to be fixed.
As for why I'm not using dev mode, I am developing a multi-chain app and have many private Geth instances running and I need them to have different chain IDs. Whoever created the dev mode built-in to Geth must have thought it would be funny for the chain ID to be hardcoded as 1337.

@jsvisa
Copy link
Contributor

jsvisa commented Jul 31, 2023

@GTMN-bradbrown as you can see the document is outdated, and should be updated

image

@bradbrown-gtmn
Copy link
Author

I cannot understand why the documentation should be updated to reflect that developers can no longer set their gas costs to zero on private test chains for the purpose of development intended to support the Ethereum Mainnet.
There are no security risks.
It is more convenient for developers.
Obviously, at some point, this feature was available, or else the documentation (and the geth binary help reflects this, too) wouldn't state this.

This is very clearly a nice feature that has been removed and nobody can provide an adequate or relevant reason. I am baffled.

@rmlearney-digicatapult
Copy link

rmlearney-digicatapult commented Nov 3, 2023

@bradbrown-gtmn we solved this by setting:

baseFeePerGas: 0x1 in genesis.json

and adding the following switch at startup time:

--gpo.ignoreprice 0

This sets a gas price of 2. While not zero, it's a decent workaround.

@holiman
Copy link
Contributor

holiman commented May 15, 2024

nobody can provide an adequate or relevant reason. I am baffled.

As @karalabe has explained:

You can't really have true zero gas price post 1559 though. The basefee must always be burnt.

Geth is an implementation of Ethereum. There never was nor ever will be a promise to support anything else. Our private network support is meant to run testnets for local testing, it is not meant to run alternative production L1s with different rule sets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
@karalabe @holiman @chenjia404 @jsvisa @rmlearney-digicatapult @bradbrown-gtmn and others