You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We operate an Arc mainnet (chain id 5042) full node (arc-node-consensus v0.8.0 + arc-node-execution, AWS ap-northeast-1) in --follow mode, syncing from public RPC endpoints (rpc.mainnet.arc.io, Alchemy, QuickNode). We would like to be onboarded for sentry peering so the consensus layer can sync over libp2p (--p2p.persistent-peers <SENTRY_MULTIADDRS>) and the execution layer over devp2p, as described in docs/running-an-arc-node.md for RPC-provider nodes.
Why
In follow mode the CL pulls each block from the follow endpoints only after they have served it (the log shows SYNC REQUIRED: Falling behind … Requesting sync from peer … Sent value request every block). Measured on our node this puts the node 60–75 ms behind the providers' own newHeads notifications, so a self-hosted node cannot serve pinned-block eth_call/eth_getBlockReceipts earlier than a third-party RPC. Direct sentry peering is the only way we see to run a self-sufficient, low-latency node.
Are there requirements (bandwidth, IP allowlisting, uptime, --p2p.persistent-peers-only, public RPC exposure) we should prepare for?
If sentry peering is validator-only for now, is there a planned timeline for opening it to independent operators, or an alternative lower-latency block feed?
We can provide our node's public IP and libp2p peer id, and are happy to run with --p2p.persistent-peers-only and IP allowlisting on 27000. Thank you.
Request
We operate an Arc mainnet (chain id 5042) full node (
arc-node-consensusv0.8.0 +arc-node-execution, AWS ap-northeast-1) in--followmode, syncing from public RPC endpoints (rpc.mainnet.arc.io, Alchemy, QuickNode). We would like to be onboarded for sentry peering so the consensus layer can sync over libp2p (--p2p.persistent-peers <SENTRY_MULTIADDRS>) and the execution layer over devp2p, as described indocs/running-an-arc-node.mdfor RPC-provider nodes.Why
In follow mode the CL pulls each block from the follow endpoints only after they have served it (the log shows
SYNC REQUIRED: Falling behind … Requesting sync from peer … Sent value requestevery block). Measured on our node this puts the node 60–75 ms behind the providers' ownnewHeadsnotifications, so a self-hosted node cannot serve pinned-blocketh_call/eth_getBlockReceiptsearlier than a third-party RPC. Direct sentry peering is the only way we see to run a self-sufficient, low-latency node.Questions
--p2p.persistent-peers-only, public RPC exposure) we should prepare for?We can provide our node's public IP and libp2p peer id, and are happy to run with
--p2p.persistent-peers-onlyand IP allowlisting on 27000. Thank you.