celestiaorg
Split Bootstrapper into Separate Node Type
Implementation ideas
Summary:
Currently, the Celestia Node supports three types of nodes: bridge, full, and light. Both bridge and full nodes can function as bootstrappers. However, we have observed that when these nodes are also serving data, the bootstrapping function can be degraded or become unavailable, especially under heavy network load. To improve reliability and separation of concerns, we propose creating a dedicated bootstrapper node type.
Problem:
- Observed Issues: During periods of high network load, the bootstrapping function of nodes serving data becomes degraded or unavailable. This has been consistently observed by the DevOps team.
- Separation of Concerns: Having dedicated bootstrapper nodes will allow for independent upgrades and maintenance without impacting nodes that serve data.
- Disk Usage: The disk usage of
bridgeandfullnodes is quite high. By running dedicated bootstrapper nodes, we can avoid handling application data, thus reducing resource consumption.
Proposed Solution:
- Introduce a new node type dedicated solely to the bootstrapping function.
- Ensure this new bootstrapper node does not serve data, focusing entirely on network bootstrapping tasks.
Benefits:
- Reliability: Improved reliability of the bootstrapping function under all network conditions.
- Maintainability: Easier and independent upgrades for bootstrapper nodes.
- Performance: Reduced load on nodes that serve data, potentially improving overall network performance.
- Resource Efficiency: Lower disk usage and resource consumption for bootstrapper nodes, as they will not need to handle application data.
Additional Context: The separation of bootstrapper functionality will align with best practices in system design, providing a more robust and maintainable architecture for the Celestia network.
cc. @walldiss
I agree with this direction, but one major problem needs to be solved here. We assume bootstrappers serve headers, and with this proposal, they won't anymore. The go-header relies on the notion of trusted peers, and bootstrappers serve this role by default.
One of the simple solutions is to keep bootstrappers serving headers but not data. So bootstrappers could be LNs that won't even do sampling.
This is great idea and should help to improve quality of bootstraper service and also make it easy for anyone to launch one. We can separate trusted peers config from bootstrapers. It will allow to easily add community ran bootsrappers, while keeping security of hardcoded trusted peers. It would separate configureation for bootsraping and serving headers for subjective initialization.
This is great idea and should help to improve quality of bootstraper service and also make it easy for anyone to launch one. We can separate trusted peers config from bootstrapers. It will allow to easily add community ran bootsrappers, while keeping security of hardcoded trusted peers. It would separate configureation for bootsraping and serving headers for subjective initialization.
What benefit does it bring us to split bootstrapping and the trusted peers?
If we can only let the community run bootstrappers and not the trusted peers, what effect does it have on the network if our trusted peers are unavailable?