search

ava-labs / coreth

Code and wrapper to extract Ethereum blockchain functionalities without network/consensus, for building custom blockchain services.
Other
183 stars 139 forks source link

eth_baseFee returns null on `v1.11.11` #660

Closed exp0nge closed 1 month ago

exp0nge commented 1 month ago

Describe the bug When calling eth_baseFee, it returns null on the latest release

{
  "jsonrpc" : "2.0",
  "method" : "eth_baseFee",
  "params" : [ ],
  "id" : 0
}
{
  "jsonrpc" : "2.0",
  "id" : 0,
  "result" : null
}

To Reproduce We are running a local network version:

--config-file=/build/dev/config/config.json --chain-config-dir=/build/dev/config --sybil-protection-enabled=false" --network-id=local

config.json:

{
    "pruning-enabled": false,
    "http-host": "0.0.0.0",
    "staking-enabled": false,
    "bootstrap-ips": [],
    "bootstrap-ids": [],
    "snow-sample-size": 1,
    "snow-quorum-size": 1,
    "snow-mixed-query-num-push-vdr": 1
}

C/config.json

{
  "gasLimit": 15000000,
  "pruning-enabled": false, 
  "offline-pruning-enabled": false,
  "eth-apis": [
      "public-eth",
      "public-eth-filter",
      "net",
      "web3",
      "internal-public-eth",
      "internal-public-blockchain",
      "internal-public-transaction-pool",
      "internal-public-account",
      "debug-tracer",
      "internal-public-debug",
      "internal-private-debug"
    ]
}

We pull the linux-amd64 image into a debian base image.

Expected behavior The current base fee is returned

Screenshots If applicable, add screenshots to help explain your problem.

Logs If applicable, please include the relevant logs that indicate a problem and/or the log directory of your node. By default, this can be found at ~/.avalanchego/logs/.

Metrics If applicable, please include any metrics gathered from your node to assist us in diagnosing the problem.

Operating System Debian

Additional context Add any other context about the problem here.

Avalanche Bug Bounty program can be found here.

michaelkaplan13 commented 1 month ago

Thanks for reporting this.

Are you running an AvalancheGo binary directly, or using the Avalanche CLI?

Could you also provide the full request information including the URL?

When I run a local network using the Avalanche CLI and AvalancheGo v1.11.11, I do not see this behavior:


$ avalanche network start
Backend controller started, pid: 6011, output at: /.../.avalanche-cli/runs/server_20240924_102837/avalanche-cli-backend.log
Installing avalanchego-v1.11.11...
avalanchego-v1.11.11 installation successful
A new network snapshot image is available. Replacing the current one.
Starting previously deployed and stopped snapshot
Booting Network. Wait until healthy...
Node logs directory: /.../.avalanche-cli/runs/network_20240924_102839/node<i>/logs

Network ready to use.

+--------------------------------------------------------------------------+
|                                   NODES                                  |
+-------+------------------------------------------+-----------------------+
| NAME  | NODE ID                                  | LOCALHOST ENDPOINT    |
+-------+------------------------------------------+-----------------------+
| node1 | NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg | http://127.0.0.1:9650 |
+-------+------------------------------------------+-----------------------+
| node2 | NodeID-MFrZFVCXPv5iCn6M9K6XduxGTYp891xXZ | http://127.0.0.1:9652 |
+-------+------------------------------------------+-----------------------+
| node3 | NodeID-NFBbbJ4qCmNaCzeW7sxErhvWqvEQMnYcN | http://127.0.0.1:9654 |
+-------+------------------------------------------+-----------------------+
| node4 | NodeID-GWPcbFJZFfZreETSoWjPimr846mXEKCtu | http://127.0.0.1:9656 |
+-------+------------------------------------------+-----------------------+
| node5 | NodeID-P7oB2McjBGgW2NXXWVYjV8JEDFoW9xDE5 | http://127.0.0.1:9658 |
+-------+------------------------------------------+-----------------------+

$ curl --location 'http://127.0.0.1:9650/ext/bc/C/rpc' \
> --header 'Content-Type: application/json' \
> --data '{
>     "jsonrpc": "2.0",
>     "method": "eth_baseFee",
>     "params": [],
>     "id": 67
> }'
{"jsonrpc":"2.0","id":67,"result":"0x34630b8a00"}
exp0nge commented 1 month ago

@michaelkaplan13 We're using the binary directly.

Here's the curl:

$ curl http://localhost:9650/ext/bc/C/rpc -X POST -H "Content-Type: application/json" --data '{"jsonrpc" : "2.0","id" : 0,"method" : "eth_baseFee","params" : [ ]}'
{"jsonrpc":"2.0","id":0,"result":null}

Attached are the docker logs: avax-11-log.txt

Based on your comment, it looks like CLI might be doing an extra setup to get this working

exp0nge commented 1 month ago

Another difference I think is CLI creates a non-standard local network ID based on the fact that it generates a new genesis file

michaelkaplan13 commented 1 month ago

Looks like the issue was just the timestamp of the default genesis block in AvalancheGo. Created a PR to fix it here https://github.com/ava-labs/avalanchego/pull/3413

Thanks again for calling this out.

exp0nge commented 1 month ago

Looks like the issue was just the timestamp of the default genesis block in AvalancheGo. Created a PR to fix it here ava-labs/avalanchego#3413

Thanks again for calling this out.

Thanks! Do you have rough estimate of when this will make into a release? Debating if I should swap to building from source to patch this ourselves versus waiting for a release versus getting a custom genesis state going (like CLI).

michaelkaplan13 commented 1 month ago

Looks like the issue was just the timestamp of the default genesis block in AvalancheGo. Created a PR to fix it here ava-labs/avalanchego#3413 Thanks again for calling this out.

Thanks! Do you have rough estimate of when this will make into a release? Debating if I should swap to building from source to patch this ourselves versus waiting for a release versus getting a custom genesis state going (like CLI).

There aren't currently any releases planned, so my best guess would be a couple weeks or so.

Alternatively, as a basic workaround, if you send any transaction on the local C-Chain it should be included in a block and advance the chain timestamp to the current time, which should solve the base fee API response issue.

exp0nge commented 1 month ago

Looks like the issue was just the timestamp of the default genesis block in AvalancheGo. Created a PR to fix it here ava-labs/avalanchego#3413 Thanks again for calling this out.

Thanks! Do you have rough estimate of when this will make into a release? Debating if I should swap to building from source to patch this ourselves versus waiting for a release versus getting a custom genesis state going (like CLI).

There aren't currently any releases planned, so my best guess would be a couple weeks or so.

Alternatively, as a basic workaround, if you send any transaction on the local C-Chain it should be included in a block and advance the chain timestamp to the current time, which should solve the base fee API response issue.

Will look into submitting a raw tx to advance.

I was looking at running a custom network since I thought that would be useful and I used the gensis_local.json (except for the network-id value). In that, I took a look at that file - I don't understand the correlation to the fix given this value was 0 for a long time in the history of this file. This leaves me unsure if this is the only broken diff in local network

exp0nge commented 1 month ago

@michaelkaplan13 I've tried to submit a signed tx to advance, but the tx does not get mined in:

Legacy tx:

curl localhost:9650/ext/bc/C/rpc -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params": ["0xf86780850826299e00825208948db97c7cece249c2b98bdc0226cc4c2a57bf52fc0180830150f4a0207fe80fc8061897b492b8dd2b11ddb848cce3183c8e68469fcfb52b5ca37020a01385efacda067e2b2051a48081325a3e086d4360d9d98b6e5cf36577be293f86"],"id":1}'
{
  "chainId": "43112",
  "type": "LegacyTransaction",
  "valid": true,
  "hash": "0xb49d8e7a0bafd52beb2a15824e5171c153d7cc7531eeb0ccec44c198ef8f6c56",
  "nonce": "0",
  "gasPrice": "35000000000",
  "gasLimit": "21000",
  "from": "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC",
  "to": "0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc",
  "v": "0150f4",
  "r": "207fe80fc8061897b492b8dd2b11ddb848cce3183c8e68469fcfb52b5ca37020",
  "s": "1385efacda067e2b2051a48081325a3e086d4360d9d98b6e5cf36577be293f86",
  "value": "1"
}

I see node logs:

[09-25|20:13:59.554] INFO <C Chain> internal/ethapi/api.go:1791 Submitted transaction                    hash=0xb49d8e7a0bafd52beb2a15824e5171c153d7cc7531eeb0ccec44c198ef8f6c56 from=0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC nonce=0 recipient=0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC value=1 type=0 gasFeeCap=35,000,000,000 gasTipCap=35,000,000,000 gasPrice=35,000,000,000
[09-25|20:13:59.554] INFO <C Chain> core/state_processor.go:237 Activating new precompile                name=warpConfig config="{\"blockTimestamp\":1607144400,\"quorumNumerator\":0}"

eth_baseFee also returns null as this does not get mined in. Was there a particular style to get this to get mined in?

edit gas price too low, here's a valid tx that updates the base fee

❯ curl localhost:9650/ext/bc/C/rpc -X POST -H "Content-Type: application/json" --data '{"jsonrpc" : "2.0","id" : 0,"method" : "eth_baseFee","params" : [ ]}'
{"jsonrpc":"2.0","id":0,"result":null}
❯ curl localhost:9650/ext/bc/C/rpc -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params": ["0xf86780853b1ad24664825208948db97c7cece249c2b98bdc0226cc4c2a57bf52fc0180830150f3a0a43182d15035bee193ae20e8044ff9b87380923c8b5edc006ac1feff1faffc89a05f0be21eca79dd77639070c6d39473ce5d0e0e7ce2a7a76e02cf69c83f97bee8"],"id":1}'

{"jsonrpc":"2.0","id":1,"result":"0x5d7307ae78baa9dc5ab0ceb3760ddcd3a57198e055e37cd94a84b08f4eec8b8b"}
❯ curl localhost:9650/ext/bc/C/rpc \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"method":"eth_getTransactionReceipt","params":["0x5d7307ae78baa9dc5ab0ceb3760ddcd3a57198e055e37cd94a84b08f4eec8b8b"],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"result":{"blockHash":"0x0b4e83b96498f28883db0e0a0422e12d1ca7cfa32d9130c1da81dad387343533","blockNumber":"0x1","contractAddress":null,"cumulativeGasUsed":"0x5208","effectiveGasPrice":"0x3b1ad24664","from":"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc","gasUsed":"0x5208","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc","transactionHash":"0x5d7307ae78baa9dc5ab0ceb3760ddcd3a57198e055e37cd94a84b08f4eec8b8b","transactionIndex":"0x0","type":"0x0"}}
❯ docker logs wallet-avalanche-node-1
...
[09-25|20:56:48.462] INFO <C Chain> internal/ethapi/api.go:1791 Submitted transaction                    hash=0x5d7307ae78baa9dc5ab0ceb3760ddcd3a57198e055e37cd94a84b08f4eec8b8b from=0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC nonce=0 recipient=0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC value=1 type=0 gasFeeCap=253,853,058,660 gasTipCap=253,853,058,660 gasPrice=253,853,058,660
[09-25|20:56:48.462] INFO <C Chain> core/state_processor.go:237 Activating new precompile                name=warpConfig config="{\"blockTimestamp\":1607144400,\"quorumNumerator\":0}"
[09-25|20:56:48.463] INFO <C Chain> miner/worker.go:457 Commit new mining work                   number=1 hash=0b4e83..343533 uncles=0 txs=1 gas=21000 fees=0.005330914232 elapsed="572.467µs"
[09-25|20:56:48.463] INFO <C Chain> core/state_processor.go:237 Activating new precompile                name=warpConfig config="{\"blockTimestamp\":1607144400,\"quorumNumerator\":0}"
[09-25|20:56:48.463] INFO <C Chain> proposervm/pre_fork_block.go:173 built block {"blkID": "5ypEgQCDk87aBBjjF1i45YuWLeSkaMe49AFJ2ByAzsMqZeRVZ", "height": 1, "parentTimestamp": "[01-01|00:00:00.000]"}
[09-25|20:56:48.463] INFO <C Chain> core/state_processor.go:237 Activating new precompile                name=warpConfig config="{\"blockTimestamp\":1607144400,\"quorumNumerator\":0}"
❯ curl localhost:9650/ext/bc/C/rpc -X POST -H "Content-Type: application/json" --data '{"jsonrpc" : "2.0","id" : 0,"method" : "eth_baseFee","params" : [ ]}'
{"jsonrpc":"2.0","id":0,"result":"0x2a33578480"}
michaelkaplan13 commented 1 month ago

Glad that worked!

I believe the change was a result of an update to how coreth sources the upgrade timestamps from AvalancheGo. Prior to that update, the upgrades activated at timestamp 0 also, but now they activate at the InitiallyActiveTime, so the genesis timestamp had to be changed to not be before then.

If you're modifying the genesis file already for the network ID, it is also safe to make that same change to the C-Chain genesis timestamp too 👍

exp0nge commented 1 month ago

To summarize (and for posterity), the options available:

  1. doing one tx before interacting with the chain will provide correct responses (above: https://github.com/ava-labs/coreth/issues/660#issuecomment-2375169409)
  2. initializing a custom network with the updated value provided in the fix PR above will also serve to fix the same thing but at the "chain" level more directly (of course this is not needed once the release is cut with the fix). I'll leave the configs that worked for us here:

dev-c-config.json dev-config.json genesis.json

we invoke the bin via: 

avalanchego --network-id="network-1337" --config-file=/build/dev/config/config.json --chain-config-dir=/build/dev/config --sybil-protection-enabled=false --api-admin-enabled=true --index-enabled=true --network-max-reconnect-delay=1s --http-host 0.0.0.0