Unable to start the node about node HOT 13 CLOSED

@brandonfrulla That seems to work, thanks for the suggestion.

Update: quickly hit the free tier limits though...

node_1  | ERROR[02-24|15:58:23.243] error getting latest header              err="429 Too Many Requests: {\"jsonrpc\":\"2.0\",\"id\":5644,\"error\":{\"code\":429,\"message\":\"Your app has exceeded its compute units per second capacity. If you have retries enabled, you can safely ignore this message. If not, check out https://docs.alchemy.com/reference/throughput\"}}"

from node.

Also see l1.rpckind:

   --l1.rpckind value              The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, nethermind, debug_geth, erigon, basic, any (default: basic) [$OP_NODE_L1_RPC_KIND]

E.g. if you specify --l1.rpckind=alchemy it'll use an alchemy-specific RPC method for receipt-fetching, reducing the load & credit usage of the RPC provider. If you use a free endpoint without this, you might hit rate-limits or compute-credits usage limits faster.

from node.

Thanks Proto, that got it started. perhaps we can add something about this to the README.

from node.

Hmmm, looks like it's failing here.

Maybe it's not liking what it gets back from the L1 node in the previous call. Is your L1 node syncing ok and confirmed to be syncing Goerli instead of some other testnet/mainnet?

from node.

Looks like the L1 node is not accepting a block-hash argument in the eth_getProof RPC call, and instead expecting a hex-encoded uint64.

Which L1 RPC provider / client are you using?

The execution-apis spec defined support for a block-hash argument in early January (after most L1 clients already support it, some L1 providers might be lagging behind, see ethereum/execution-apis#326);

Try --l1.trustrpc, it will fallback to using eth_getStorageAt (i.e. load the required value, without verifying it) which might still work with blockhash argument.

from node.

Hi, thanks for the fast responses.

I'm using an Ankr endpoint as defined from here: https://www.ankr.com/rpc/eth/eth_goerli/

Is there another suggested free tier provider that I should use?

from node.

Hey @lookfirst, perhaps try this one? I haven't composed the node on my end yet, so keen to see the results

https://opt-mainnet.g.alchemy.com/v2/
src: https://docs.alchemy.com/docs/how-to-add-alchemy-rpc-endpoints-to-metamask#4.-fill-in-the-required-information

from node.

@protolambda I just tried this with an Erigon node and get the same failure seen here.

from node.

@roberto-bayardo due to the flat DB design of Erigon they do not support eth_getProof I believe, try --l1.trustrpc to fallback to eth_getStorageAt which Erigon does support.

from node.

I'm going to close this, the solution is to just try another API provider. If someone wants to open up issues about specific providers, that's probably the correct thing to do.

from node.

@protolambda Thanks. It seems this is the call that is quickly rate limited...

from node.

@lookfirst During sync it'll backoff on temporary errors like rate-limits. Although maybe not during the initial start part where it traverses to a starting point (we're working on improving this).

I also imagine that the combination of a free endpoint + not using the receipts-fetching optimization means that it'll quickly run up the RPC credit usage, and start limiting things. We are trying our best to optimize RPC usage, but free endpoints are really meant for a metamask wallet sending a tx and fetching some balances, not syncing a rollup node. I think we can keep an op-node in sync with free-tier usage of most RPC providers, but while catching up it'll probably hit some limits.

from node.

@protolambda Thanks... yea, I probably should just use a paid one... just being lazy and trying to get up to speed more quickly, can migrate to a paid one soon.

from node.