- 2022-04-15: proposed
@renaynay @Wondertan
This ADR serves as a tracking document for celestia-node's technical requirements for the planned incentivized testnet.
All epics/tracking issues have been linked in the sub-headers of technical requirements.
Top-level features will include a link to the epic-style tracking issue as well which can be used for a further detailed breakdown of the individual feature requirements.
- DA node: any node type implemented in celestia-node
- DA network: the p2p network of celestia-node
In order to expose the state of the daser
and make it accessible via the public API, there needs to be a mechanism to
track the state of the daser
in a similar way to how SyncState
does it. DASState
will capture basic information
about the state of the daser
, such as the latest sampled header.
The daser
's current implementation is very basic in that it performs two sampling routines:
- samples over latest
ExtendedHeader
s received viaheadersub
- samples over all
ExtendedHeader
s between the lastDAS
ed header (checkpoint) and the latestExtendedHeader
in the network
The issue with the above approach is that there is a possibility that the daser
would sample over an ExtendedHeader
which it has already sampled. The only way to keep track of which heights have already been sampled is to implement a
share cache that would cache the results of sampling processes on disk in such a way that tracks which heights have been
sampled and whether it was successful or not.
The catch-up routine of the DASer
currently exits the catch-up routine upon error and logs out an instruction to
restart the node in order to continue sampling. Instead, there should be retry logic and potentially the graceful
shutdown of DASer
and potentially node.
The public API is currently being drafted here. There are several components that will go into implementing the overall design as well as the individual module implementations.
Bad Encoding Fraud Proof (continuation)
The full implementation of bad encoding fraud proof (BEFP) generation, propagation and handling is required for the incentivized testnet. At the moment, generation and broadcasting of BEFPs is still in review.
One of the biggest priorities for incentivized testnet is to test a lot of the assumptions we are working under in terms of sampling in realistic network conditions with a variety of topologies.
Among the most important test cases, the following are required:
In terms of testing infrastructure, testground will be considered. A proof of concept will be done in order to accomplish the above tests.
All DA node types will support sending transactions and querying state-related information, meaning DA nodes will need an account. So far, the standard key utility from cosmos-SDK has been made available via CLI for all node types, however more robust key/wallet management via the node's public API is required.
The current implementation of HeaderExchange
has to be improved and hardened as there is a hard dependency on trusted
peers at the moment. Some high-level improvement requirements are:
- Read/write deadlines on libp2p streams
- Server-side request limits
- Server-side maximum request size configuration
- Adjacency of a batched
ExtendedHeader
response must be verified inHeaderEx
upon receiving the response - Request retries
- Cycling peers for requests
More detail can be found in the issue linked in the header.
All node types must have metrics collection and tracing of hot paths implemented.