Light Node & Fast Catch-up

Proposals
3

Integrating Light Node, Fast Catch-up, and --hotsync for a Unified Node Approach

Dear @chportma,

Thank you for your insightful response and for sharing the “Light Node & Fast Catch-up” proposal. I fully agree with the concept of light nodes to address node size and synchronization challenges. Building upon your ideas, I propose merging the light node concept into the --hotsync proposal to develop a unified node model. This would create a versatile node type that adapts to different network needs and operator resources.

Proposing a Unified Node Model with Self-Healing Mechanism

By combining the light node concept with the --hotsync proposal, we can create a unified node type that functions in two modes: light and full archival. Here’s how this model would work:

  1. Initial Synchronization as a Light Node: When a new node starts, it operates as a light node, synchronizing only the current state and minimal history. This allows the node to become operational within minutes, facilitating immediate participation in network activities.
  2. Parallel Full Sync Process: In the background, the node begins synchronizing the full blockchain data, allowing operators to choose whether to remain a light node or transition into a full archival node over time. This process runs without interrupting core functions.
  3. Dynamic Mode Switching with Self-Healing: Nodes can switch seamlessly between light and full modes based on configurable settings or resource availability. This self-healing mechanism makes nodes adaptable to network conditions and operator preferences, enhancing overall robustness.

Decentralized Data Assembly with Geographical Optimization

To further decentralize and optimize data retrieval, the node would sync data from multiple peers rather than relying on a single source:

  • Data Packages from Multiple Peers: Nodes can assemble data from multiple sources to balance network load and prevent centralization risks. Employing cryptographic verification methods ensures data integrity and guards against malicious data.
  • Geographical Region Settings: Nodes could prioritize syncing from nearby peers, reducing latency and balancing traffic geographically to improve performance.

Leveraging the Upcoming P7 Update

The P7 update’s changes to the block hash structure provide an excellent opportunity to implement these enhancements:

  • Fast Catch-up with Finalization Proofs: By downloading one block per day from P7 onwards, nodes can verify the chain’s state securely and quickly without downloading the entire history.
  • Simplified Synchronization: Using the P7 genesis block as the starting point for light nodes simplifies synchronization and improves overall network resilience.

Addressing Archival Nodes and Indexers

While the focus is on light nodes, archival nodes remain crucial for preserving the full blockchain history. @NHS raised an important point about the need for sufficient archival nodes to ensure history isn’t lost if several nodes go offline. Here’s how we factor this into the proposal:

  • Indexers as History Providers: Indexers can act as off-chain history providers, offering quick access to historical data. However, the data from indexers can always be verified against archival nodes, maintaining trust and accuracy.
  • Ensuring Sufficient Archival Nodes: We should encourage running multiple independent archival nodes across the network to maintain data redundancy and ensure history preservation. Entities interested in historical data, such as businesses, could be incentivized to operate archival nodes. Implementing a replication strategy where archival nodes mirror each other can further ensure the resilience of historical data.
  • Community Involvement in Archival Nodes: By emphasizing the importance of archival nodes for long-term data access (e.g., tax compliance, proof of historical transactions), we can encourage community members and organizations to contribute to the network by operating archival nodes.

Summary of the Unified Node Model

This unified node model combines the advantages of both light and full nodes, offering a flexible solution that adapts to the needs of the Concordium network:

  • Simplified Node Management: A single node type that can operate in light or full mode reduces complexity for operators.
  • Enhanced Network Participation: Lowering the entry barrier allows more participants to run nodes, strengthening the network’s decentralization and security.
  • Optimized Resource Utilization: Nodes can dynamically adjust based on available resources, ensuring efficient use of network and hardware capacity.
  • Decentralization and Redundancy: By obtaining data from multiple peers and running sufficient archival nodes, we enhance decentralization and ensure network resilience.

Summary

By merging the light node and --hotsync concepts, we can create a unified and flexible node model that improves user experience, network scalability, and decentralization. This proposal addresses immediate needs, such as reducing sync times and lowering node size, while maintaining the integrity of the network with archival nodes and finalization proofs. The self-healing mechanism allows nodes to start quickly as light nodes and transition seamlessly into full nodes, ensuring both accessibility and robustness.

We welcome any feedback or suggestions on this approach and are eager to collaborate further to refine these ideas and contribute to Concordium’s continued growth and resilience.

Thank you once again for your guidance and collaboration. We look forward to your response.