Open liamsi opened 2 months ago
Actually, not quite: https://github.com/celestiaorg/celestia-app/pull/3423
is it possible to expose these two methods from core, and eventually move the logic to node if possible?
is it possible to expose these two methods from core, and eventually move the logic to node if possible?
Yes, should be very, very easy!
and eventually move the logic to node if possible?
Also. Do you mind opening an issue in node for that? NVM: https://github.com/celestiaorg/celestia-node/issues/3364
In addition to the subscribeBlock
, bridge nodes rely on several other RPC endpoints from the celestia-core SignClient interface. Most can be replaced by implemented by the cosmos-sdk gRPC. Below is a comprehensive list of RPC methods used by bridge nodes, along with the corresponding gRPC methods in cosmos-sdk that can fetch the same data:
BlockByHeight
BlockByHeight + GetValidatorSetByHeight
BlockByHeight
(Commit field)GetValidatorSetByHeight
GetSyncing
Additional functionalities like ProveShares
and DataRootInclusionProof
are also missing in gRPC and should be proxied.
Decide on adding missing functionality to existing services (e.g. cosmos.base.tendermint.v1beta1.Service) or add a new service that is specific to node/celestia. The latter is probably cleaner and preferable.
An additional point is that the block gRPC API should be designed to support larger blocks, so we won't need to rework it as block sizes increase.
Additional functionalities like ProveShares and DataRootInclusionProof are also missing in gRPC and should be proxied.
Full nodes should be able to handle these queries themselves since they have all the relevant data. I think ProveShares
should really be deprecated and removed on the celestia-app side because it's a DoS vector (you need to build the square everytime)
add a new service that is specific to node/celestia. The latter is probably cleaner and preferable.
I think we should just add it as a new service. Generally we should reduce the amount of bespoke code we have in cosmos-sdk if we eventually plan to unfork oursleves
Summary
Node has to use core's/comet's RPC additionally to gRPC. That is very confusing. The current app API is not sufficient and lead to bad design decisions in celestia-node which led to proposals that will manifest these even further https://github.com/celestiaorg/celestia-node/issues/2931
Problem Definition
Node currently uses both RPC (comet) and gRPC (app). Apparently,
the onlyone reason for that is only comet's RPC exposes proofs for state queries currently, or rather ABCI queries (see #3422). Another reason, is that bridge nodes currently get their block data via RPC. That is also not ideal as the block data should be binary/protobuf encoded instead of a large JSON file.If these two changed, celestia-node could solely rely on app's gRPC.
One of the places
The only placewhere node uses rpc is here:Proposal