Vlad
Vlad
In addition to the `subscribeBlock`, bridge nodes rely on several other RPC endpoints from the [celestia-core SignClient interface](https://github.com/celestiaorg/celestia-core/blob/e10afb386109910f90458d6f20f6358c50cad58b/rpc/client/interface.go#L66). Most can be replaced by implemented by the cosmos-sdk gRPC. Below is...
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.
otel deps were updated in another PR
It is open to discussion whether it should be solely by commitment or commitment+namespace. Technically both are possible to implement and it is up to the users if they are...
> rollup may want to run a light node for the sequencer and point it to a dedicated bridge node that can provide blob retrievability and submission through a SLA...
Issue mentions request to use RPC only for blob retrieval. However as you mentioned headers and samples are needed for particular users. So perhaps those should be provided from RPC:...
We should consider creating a testing app that imports the Celestia client and runs a test suite over the network. This will enable us to: - Test RPC locally within...
The biggest challenge with those metrics implementation is to make sure they are reported in time by grpc stack itself. Do you have an idea how those can be observed?
Issue implies as fact that invalid blocks can be accepted by the node and be stored. Before implementing the solution for rollback we need to identify the root issue of...