IC Network Boundary Node Architecture Transformation: Boosting Security, Scalability, and Decentralization
ICP‘s new architecture will differentiate between HTTP Gateways and API Boundary Nodes. This article will explore these boundary nodes, the system improvements, and the disaster recovery mechanisms.
The Internet Computer Protocol (ICP) is preparing to introduce major updates to its boundary node architecture, aiming to bolster the network's security, stability, and scalability. The new architecture will differentiate between two node types—HTTP Gateways and API Boundary Nodes—and focus on disaster recovery and event handling. This article will explore these boundary nodes, the improvements in the system, and the disaster recovery mechanisms that will ensure the resilience of the ICP network.
1. What Are Boundary Nodes?
Boundary nodes are a crucial part of the ICP network, facilitating the interaction between users and the underlying blockchain. They act as gateways, converting user requests from standard web browsers into canister (smart contract) API calls. These nodes ensure that the requests are routed efficiently across the network, distributing the load among replica nodes in different subnets. Additionally, boundary nodes provide caching services to improve performance.
In a Web2 environment, external data interactions are often handled through APIs like RESTful or GraphQL APIs. Applications make HTTP requests to external services for data, such as fetching financial data or weather forecasts. In the decentralized blockchain space, however, applications cannot directly communicate with external data sources. To solve this, blockchain projects typically use oracles, which act as intermediaries to bring off-chain data onto the blockchain.
ICP’s design aims to minimize reliance on external systems. While it can integrate with oracles like Chainlink, ICP’s core idea is to handle data through boundary nodes and canisters, where external data is passed directly into the ICP network via HTTPS requests. This approach is akin to Web2 API calls but is fully decentralized, ensuring greater security and transparency.
2. Core Improvements in the ICP Boundary Node Architecture
The ICP boundary node roadmap focuses on two main areas of improvement: architecture separation and enhanced functionalities.
2.1 Architecture Separation: HTTP Gateways and API Boundary Nodes
Previously, a single boundary node handled multiple tasks, such as managing user requests and API calls. This integrated design could become overburdened during periods of high traffic or in the event of attacks. To address this, ICP is separating the architecture into two specialized components: HTTP Gateways and API Boundary Nodes.
HTTP Gateways serve as endpoints that terminate TLS (Transport Layer Security), handling user requests by converting them into API canister calls. They can be likened to reverse proxy servers in Web2, translating requests into blockchain-compatible formats and ensuring secure data transmission. In essence, HTTP Gateways provide security and serve as the user's access point to the network.
API Boundary Nodes, on the other hand, are responsible for routing API requests to the appropriate subnets and replica nodes within the ICP network. These nodes manage canister calls, apply rate-limiting, and offer caching services. In Web2, this role is similar to that of an API gateway, but in ICP, it operates within a decentralized architecture, ensuring efficient request handling without centralized control.
The reason for separating HTTP Gateways and API Boundary Nodes is that they have different levels of trust. HTTP Gateways need more trust because they handle tasks like ending TLS connections and managing service workers that contain the IC’s public keys. On the other hand, API Boundary Nodes don’t need as much trust. They will be managed and rewarded through the NNS, similar to how replicas are managed today.
This setup gives users different ways to access the IC network, based on their preferences:
Regular Browsers: Users can pick an HTTP Gateway by choosing a domain (similar to selecting a website). It’s easy to use, but you still have to trust the gateway operator.
IC-native Clients: These are apps with IC’s public keys, allowing users to connect directly to the IC without needing an HTTP Gateway.
In short, most users will likely use HTTP Gateways for convenience, but native clients provide a more direct, secure option without relying on any specific gateway. However, API Boundary Nodes will still be an essential part of the system, helping to route traffic between users and the IC’s replica nodes, all while being managed in a decentralized way by NNS.
Source：https://forum.dfinity.org/
2.2 Enhanced Functionalities: Caching, Rate Limiting, and Security
In addition to architectural separation, the boundary nodes will be equipped with enhanced caching and rate-limiting capabilities. Caching helps reduce the load from duplicate requests, and rate-limiting prevents traffic spikes that could lead to denial-of-service (DoS) attacks.
Another key improvement is the integration of advanced monitoring tools, which will enable boundary nodes to detect potential system issues proactively. Automated recovery mechanisms will ensure that any disruptions are swiftly addressed, minimizing network downtime and ensuring uninterrupted service.
3. Disaster Recovery and Event Handling
With the introduction of NNS-managed API Boundary Nodes, disaster recovery and event handling are becoming critical aspects of maintaining system stability.
3.1 API Boundary Node Disaster Recovery
Currently, boundary nodes are operated by DFINITY and have not experienced complete failure. However, as the management of boundary nodes shifts to the NNS, it is important to consider how the network will continue operating if the boundary nodes fail.
Imagine a scenario where all boundary nodes cease to function, potentially bringing the network to a halt. To prevent such a situation, the system needs a backup plan. This is similar to having a secondary hard drive when your computer crashes so that you can continue working without relying on the malfunctioning system.
Solution: DFINITY proposes whitelisting specific IP addresses within the firewall. These IP addresses would act as backup access points, bypassing the faulty boundary nodes and directly connecting to the NNS. This ensures that users can still submit proposals and cast votes, even in the event of a boundary node failure.
3.2 Rate Limiting in Event Handling
Consider a scenario where a shopping website experiences a surge in traffic during a Black Friday sale. To prevent server overload, the website would limit the number of requests it processes per second. Similarly, the ICP network needs a rate-limiting mechanism to handle sudden spikes in requests, such as during a service outage or an attack.
In the past, DFINITY has used temporary rate limits and filtering rules to protect the system from high loads or vulnerabilities, such as during memory leaks or when system resources were exhausted. As the management of boundary nodes transitions to NNS, a more decentralized mechanism is required.
Solution: DFINITY suggests creating a "rate-limiting container," a tool that monitors and limits the number of requests API Boundary Nodes can process. Authorized administrators can temporarily adjust these limits to safeguard the system from excessive traffic. After the event concludes, all adjustments will be publicly audited, ensuring transparency and security.
4. Design Goals of the Boundary Node Architecture
The upgraded boundary node architecture is built around several design goals:
4.1 No Single Point of Trust
One of the key objectives is to ensure users do not have to trust a single entity when interacting with ICP. By eliminating single points of failure, ICP enhances its decentralized nature. The architecture allows for multiple node operators, reducing reliance on centralized systems and improving overall availability.
HTTP Gateways will be self-managed, enabling anyone to run one under their own domain with personal policies. Users can choose the HTTP gateway they trust most, thereby achieving the "no single point of trust" goal.
API Boundary Nodes will be managed and rewarded through NNS, similar to current replicas, with most provided by third parties.
4.2 Usability
The new design allows users to access ICP services through standard web browsers like Chrome or Firefox, without requiring any additional plugins or configurations. This user-friendly approach lowers the barrier to entry, making it easier for users to engage with Web3 applications on ICP.
4.3 Censorship Resistance and Legal Compliance
Each node operator can comply with local laws without impacting the operation of other nodes. For example, a node may restrict specific services based on local regulations, while others continue to function globally, ensuring that ICP remains accessible to users worldwide without regional legal constraints.
4.4 Openness
The new boundary node architecture promotes openness by allowing anyone to operate boundary nodes, maximizing community management through the NNS. Community members will play a crucial role in both running HTTP Gateways and API Boundary Nodes.
Conclusion
The Internet Computer's boundary node architecture updates represent significant advancements in network decentralization, security, and usability. By separating the architecture into HTTP Gateways and API Boundary Nodes, ICP enhances the efficiency and reliability of the network. Moreover, the improved disaster recovery mechanisms and rate-limiting features ensure that ICP remains resilient in the face of challenges. These updates position ICP as a robust and scalable platform for the growing demands of Web3 applications.
Reference
[1]https://forum.dfinity.org/t/incident-handling-with-the-new-boundary-node-architecture/36390
 | A guest post by
|