changing default listen address for cometbft's RPC service to 0.0.0.0

[jchappelow]

Taking a conservative stance, we have kept the default listen address of cometbft's RPC service to 127.0.0.1. When configuring a node to function as a trusted RPC provider from cometbft's header verification during statesync, it is necessary to expose this.

Note that it is NOT necessary for every snapshot provider to expose this however. The actual snapshot chunks are provided over P2P. This RPC provider is a special trusted provider for verifying block headers and providing trusted (checkpoint) heights+hashes. The intent as per cometbft is to point to something like "https://header-authority.networkx.org/" and have most or all nodes that wish to perform statesync use that.

However, in practice, Kwil users tend to need to expose the RPC service on every node that is creating snapshots. This is understandable, if not exactly the intended way to use the chain.statesync.rpc_servers setting.

[jchappelow]

Perhaps a better explanation is by example with Ethereum's beacon (consensus) chain mechanism for snapshot based sync. There are "checksum" providers like https://beaconstate.ethstaker.cc/ and several others listed at https://eth-clients.github.io/checkpoint-sync-endpoints/ which are publicly available to provide the "trusted" heights and hashes, which are used for validation of the actual snapshot sync process that uses P2P.

Our system is similar, although our provider powers header verification as well as serving trusted heights+hashes.

[jchappelow]

This may be safe. I am looking at the exposed comet endpoints and they don't include explicitly "unsafe" ones by default like /dial_peer or unsafe_flush_mempool.

Effective config written to abci/config/config.toml includes:

# TCP or UNIX socket address for the gRPC server to listen on
# NOTE: This server only supports /broadcast_tx_commit
grpc_laddr = ""

# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool
unsafe = false

So users won't be able to abuse websockets (I think) or use the "unsafe" endpoints.

Here are the ones that are exposed:

/abci_info?
/abci_query?path=_&data=_&height=_&prove=_
/block?height=_
/block_by_hash?hash=_
/block_results?height=_
/block_search?query=_&page=_&per_page=_&order_by=_
/blockchain?minHeight=_&maxHeight=_
/broadcast_evidence?evidence=_
/broadcast_tx_async?tx=_
/broadcast_tx_commit?tx=_
/broadcast_tx_sync?tx=_
/check_tx?tx=_
/commit?height=_
/consensus_params?height=_
/consensus_state?
/dump_consensus_state?
/genesis?
/genesis_chunked?chunk=_
/header?height=_
/header_by_hash?hash=_
/health?
/net_info?
/num_unconfirmed_txs?
/status?
/subscribe?query=_
/tx?hash=_&prove=_
/tx_search?query=_&prove=_&page=_&per_page=_&order_by=_
/unconfirmed_txs?limit=_
/unsubscribe?query=_
/unsubscribe_all?
/validators?height=_&page=_&per_page=_

Subscriptions, which are easily abused, supposedly only work if websocket is enabled (is it?).

• dump_consensus_state seems ok but a little suspect.
• unconfirmed_txs could be a problem if it returns the full txns not just hashes (I haven't tried).
• check_tx is somewhat of an attack vector as it could be expensive, although it's probably no worse than broadcast.
• the block_search and tx_search endpoints worry me the most as they could be expensive
• net_info leaks the listen addresses (and thus internal machine config) as well as it's peers

Overall, my feeling is it is alright to expose, but I wish we could filter the endpoints.

Last thing is that these are the REST endpoints, and the JSON-RPC service might have others not listed here.

[brennanjl]

The only other concern is regarding private mode. If an RPC is in private mode, we need to disable access to the comet rpc, and probably do not want it at 0.0.0.0 by default.