Is it possible to start a beacon node point to an infura endpoint?

[yrong]

➜  lodestar git:(v1.12.0) ./lodestar beacon --dataDir="$ethereum_data_dir" --network=goerli --eth1=true --rest.namespace="*" --checkpointSyncUrl=https://sync-goerli.beaconcha.in  --eth1.providerUrls=https://goerli.infura.io/v3/$INFURA_PROJECT_ID

Dec-13 23:40:22.084[]                 info: Lodestar network=goerli, version=v1.12.0/7000473, commit=7000473fbddf2765d5b6897d5d6f6064c1042ad5
Dec-13 23:40:22.089[]                 info: Connected to LevelDB database path=/tmp/snowbridge/ethereum/chain-db
Dec-13 23:40:22.090[]                 info: Fetching checkpoint state checkpointSyncUrl=https://sync-goerli.beaconcha.in
Dec-13 23:40:46.891[]                 info: Download completed stateId=finalized
Dec-13 23:40:57.217[]                 info: Initializing beacon from a valid checkpoint state slot=7164352, epoch=223886, stateRoot=0x30c8f0cce155bdbf05a881f698aa063098079c8141ab5c70b44b440194a89f7f, isWithinWeakSubjectivityPeriod=true
Dec-13 23:41:15.156[network]          info: running libp2p instance in worker thread
Dec-13 23:41:15.742[network]          info: libp2p worker started peer=16Uiu2HAm6aYS16q7DpBChgFXHnQwUJS3zx62owF5SGJJVQwwfkQJ
Dec-13 23:41:16.132[network]          info: PeerId 16Uiu2HAm6aYS16q7DpBChgFXHnQwUJS3zx62owF5SGJJVQwwfkQJ, Multiaddrs /ip4/0.0.0.0/tcp/9000
Dec-13 23:41:16.222[rest]             info: Started REST API server address=http://127.0.0.1:9596
Dec-13 23:41:16.223[]                 warn: Low peer count peers=0
Dec-13 23:41:16.223[]                 info: Searching peers - peers: 0 - slot: 7164506 - head: (slot -154) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884
Dec-13 23:41:16.127[network]          info: discv5 worker started peerId=16Uiu2HAm6aYS16q7DpBChgFXHnQwUJS3zx62owF5SGJJVQwwfkQJ, initialENR=enr:-IO4QFUH5kLJA8BiYYr9yRE21jpfFNqyyU7QIigmGJ8bvuHkI3kcCbhDtxIOLXC3mE5rMcR-j9GNC1lABtvzmtvzBY4BgmlkgnY0iXNlY3AyNTZrMaECpbY_sF4h3Dxrxzbx9FppdHSMnPucHHR9DBi1Okh2EiODdGNwgiMog3VkcIIjKA, bindAddr4=/ip4/0.0.0.0/udp/9000
Dec-13 23:41:18.002[]                 info: Searching peers - peers: 0 - slot: 7164506 - head: (slot -154) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884
Dec-13 23:41:30.003[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164507 - head: (slot -155) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 15
Dec-13 23:41:34.489[execution]       error: Execution client went offline oldState=ONLINE, newState=OFFLINE
Dec-13 23:41:42.016[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164508 - head: (slot -156) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 15
Dec-13 23:41:54.001[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164509 - head: (slot -157) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 19
Dec-13 23:42:06.106[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164510 - head: (slot -158) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 22
Dec-13 23:42:18.437[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164511 - head: (slot -159) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 21
Dec-13 23:42:30.151[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164512 - head: (slot -160) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 23
Dec-13 23:42:42.341[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164513 - head: (slot -161) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 23
Dec-13 23:42:42.949[eth1]            error: Eth1Provider faced error state=ERROR, lastErrorAt=8:02:23 AM - Too Many Requests: {"jsonrpc":"2.0","error":{"code":-32005,"message":"batch item count exceeded"}}
Error: Too Many Requests: {"jsonrpc":"2.0","error":{"code":-32005,"message":"batch item count exceeded"}}
    at JsonRpcHttpClient.fetchJsonOneUrl (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/provider/jsonRpcHttpClient.ts:288:15)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at JsonRpcHttpClient.fetchJson (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/provider/jsonRpcHttpClient.ts:229:16)
    at file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/provider/jsonRpcHttpClient.ts:188:40
    at JsonRpcHttpClient.wrapWithEvents (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/provider/jsonRpcHttpClient.ts:208:24)
    at Eth1Provider.getBlocksByNumber (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/provider/eth1Provider.ts:151:23)
    at Eth1DepositDataTracker.updateBlockCache (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/eth1DepositDataTracker.ts:294:19)
    at Eth1DepositDataTracker.update (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/eth1DepositDataTracker.ts:207:31)
    at Eth1DepositDataTracker.runAutoUpdate (file:///Users/yangrong/Projects/snowbridge/lodestar/packages/beacon-node/src/eth1/eth1DepositDataTracker.ts:169:29)
Dec-13 23:42:54.002[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164514 - head: (slot -162) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 37
Dec-13 23:43:06.002[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164515 - head: (slot -163) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 35
Dec-13 23:43:18.001[]                 info: Syncing - ? left - 0.00 slots/s - slot: 7164516 - head: (slot -164) 0x72e2…9448 - exec-block: syncing(10206409 0x7111…) - finalized: 0x7d0d…a26e:223884 - peers: 35

From log seems it's syncing but fails to advance(execution block always at 10206409), not sure if it has something to do with the rate limit control of Infura nodes or the bad network myself.

Hope someone sheds light on this and any help will be appreciated.

[nflaig]

You can use Infura as eth1 provider (--eth1.providerUrls) but you can't use it as execution client (--execution.urls). To properly validate and process the chain you need to run the execution client yourself.

There are workarounds available to run Lodestar without an execution client but those are not recommended in production.

I can give you some suggestions if you could provide more details about your specific use case.

[yrong]

There are workarounds available to run Lodestar without an execution client.

Thanks for the reply. Yes, I just want to run a beacon API node without an execution client. Is that possible?

[nflaig]

It is kinda possible but really depends on your use case and has some limitations. You can run Lodestar without requiring an execution client by passing --execution.engineMock --eth1 false flags. The mock will not do any payload verification hence this is insecure and I would only recommend it for development.

The mock currently also has a limitation that it requires the parent hash of a block to be present otherwise it will consider itself as syncing. If you use checkpoint sync, the parent hash of previous block will not be set which could be an issue.

lodestar/packages/beacon-node/src/execution/engine/mock.ts

Lines 171 to 174 in 5b38552

	if (!this.validBlocks.has(parentHash)) {
	// if requisite data for the payload's acceptance or validation is missing
	// return {status: SYNCING, latestValidHash: null, validationError: null}
	return {status: ExecutionPayloadStatus.SYNCING, latestValidHash: null, validationError: null};

Depending on the data you need from the beacon API this might not be an issue. Alternatively, you could remove this line and rebuild Lodestar. We could also look into adding a flag to disable the parent hash check in the engine mock.

[yrong]

Cool, I made the hack as you suggested and it does work!

Btw: Seems there is one more change required in commit FYI.

The mock will not do any payload verification hence this is insecure and I would only recommend it for development.

Thanks for the reminder! Yes, I understand it's not safe to skip payload verification in production mode, other than that is there any other risk in your experience? More context here is that we're the bridge to relay the beacon header/block/state to another chain and use that to verify other messages. So actually execution node is not required in our use case.

[nflaig]

Btw: Seems there is one more change required in commit FYI.

Interesting, last time I tried this it worked without that change, thanks for the reference

other than that is there any other risk in your experience?

The main risk it that your node does not validate the transactions on the execution layer included in block received over gossip. Assuming a majority of honest nodes on the network I don't think that is as problematic. Another limitation of course is that your node can't produce blocks but if you are not running with an attached validator this does not matter.

So actually execution node is not required in our use case.

Execution node is always required if you want confidence that the data you retrieve from your beacon node is correct.