The boundary nodes are the gateway to the Internet Computer (IC), which allow users to seamlessly access the canister smart contracts running on it: through stock browsers users are served web-content fully from the chain. To this end, the boundary nodes translate the users’ requests into API canister calls, route these calls to the subnet running the canister and load balance among the subnet’s replica nodes. In addition, boundary nodes provide caching and other services for improved performance.
At the end of last year, the NNS community adopted a motion proposal outlining the long-term research and development directions for the boundary nodes. In this post, we provide an update and provide an outlook on the future of the boundary nodes.
We just completed a major milestone by moving the boundary nodes to the same platform as the replica nodes. More specifically, boundary nodes now use the same host- and guest-OS architecture as the replica nodes, which is based on standard Ubuntu and often referred to as “IC-OS”. Thanks to this change, we can build on existing best practices and prepare the boundary nodes to be community-managed via the Network Nervous System (NNS). This is a key precondition to further decentralize the deployment and management of boundary nodes.
In the following, we present the target architecture we aim for and highlight the main features we will work on to reach this target.
Future Boundary-Node Architecture
Design Goals
The design goals for the boundary node target architecture are:
- No single point of trust: users can interact with the IC without having to trust a single entity. Besides significantly reducing trust assumptions, this requirement increases the IC’s availability as there is no single point of failure.
- Useability: users can conveniently access the IC using stock browsers as it is already possible today, i.e. standard web browsers with no additional modifications or add-ons.
- Censorship resistance and legal compliance: individual boundary node owners are able to independently comply with local legal frameworks, e.g., blocking gambling services in a particular geography, without restricting other boundary nodes. This requirement ensures that boundary nodes do not have to comply with the least common denominator globally.
- Open: anyone can run a boundary node and we aim to maximize the functionality managed by the IC community through the NNS.
HTTP Gateways and API Boundary Nodes
To understand the new architecture, we first have to look at today’s boundary nodes, which serve mainly two roles: (1) they act as HTTP gateways and (2) they serve as endpoints for API canister calls.
The future boundary architecture foresees the decomposition of today’s boundary nodes into two different kinds of nodes, each assuming one of these roles.
- HTTP gateways: provide an endpoint to the users that terminates TLS, serves the service worker and translates the users’ HTTP requests to API canister calls.
- API boundary nodes: provide an endpoint that handles API canister calls by routing them to the correct subnet and replica node, and provides caching and rate-limiting to protect the IC.
This decomposition is motivated by different trust assumptions. HTTP gateways require users’ trust as they terminate TLS and serve the service worker, which contains the IC’s public keys. In contrast, API boundary nodes come with significantly lower trust assumptions.
The following figure depicts the new architecture using HTTP gateways and API boundary nodes. Next, we will explain how this architecture achieves the design goals.
Community-owned Boundary Nodes
In order to achieve the “no single point of trust” goal, boundary nodes must be owned and controlled by multiple parties:
- HTTP gateways will be self-managed, which means that anyone can run an HTTP gateway under their own domain with their own policies without NNS-approval. Then, DFINITY will just be one of many HTTP gateway owners and users can choose the gateway they trust most and through which they access the IC. Hence, there will be no “single point of trust” and we achieve the “censorship resistance and legal compliance” design goal.
- API boundary nodes will be managed and rewarded through the NNS akin to the replicas today (shaded blue area). The vast majority of the API boundary nodes will be provided by third parties (green) and a few by DFINITY (pink).
In summary, community members will both run HTTP gateways and API boundary nodes.
Access Paths
Depending on a user’s tech-savviness and usability preferences, this architecture allows to access the IC through different paths:
- Stock browser: A user can choose their trusted HTTP gateways by picking the corresponding domain. Thereby we achieve the “useability” design goal. While this path comes with a choice of a HTTP gateway, it still requires the trust in a single gateway owner.
- IC-native clients contain the IC’s public keys and can access the API boundary nodes directly (red arrows). In the future, there will be many different native clients such as mobile applications and web-extensions. We also plan to develop a web-extension for the browser, which translates HTTP requests for the IC into API canister calls directly in the browser allowing users to completely bypass the HTTP gateway.
In conclusion, for convenience, users will rely on HTTP gateways but if they choose a native client, they don’t need HTTP gateways. API boundary nodes are always part of the path from a client to a replica node but they are truly decentralized and under the control of the NNS.
DNS
Ultimately, we plan to further reduce the required trust by building a decentralized DNS infrastructure directly on the IC. However, we haven’t worked out a concrete architecture yet.
Upcoming Features
In addition to the new boundary node architecture, we are working on improving the user experience and the security of the IC. In particular, we are working on:
- Search engine optimization (SEO): By the end of September, we will rollout an update to the boundary nodes allowing search engines to index canisters on ic0.app and enabling previews on social media (e.g., Twitter cards). We achieve that by letting crawlers and bots bypass the service worker similar to raw.ic0.app.
- Asset caching: In November, we will release an update that enables asset caching as introduced in DFX 0.11.1. This update allows the browser and service worker to cache static assets and therefore improve the load times experienced by dapp users.
- Custom domains: After that, we will start working on bringing custom domains to the IC. While it is already possible today, it requires extra developer effort by handling the SSL certificate and a server to host the service worker (see Documentation). Our goal is to seamlessly integrate the domains into the existing boundary nodes, in the future HTTP gateways, such that developers can use friendly domain names with minimal effort – only the DNS record of the domain has to be adapted.
In the longer term, we focus on increasing privacy and integrity to improve the overall security. We aim to seal the boundary nodes and provide means for users to validate their integrity. To this end, we use hardware-based trusted execution, specifically, we are relying on AMD SEV-SNP, and allow users to remotely attest the authenticity of the boundary nodes’ hard- and software. In addition, we are working on an enhanced response certification that prevents malicious replicas and boundary nodes from modifying the HTTP responses.
Next Steps & Roadmap
Q4 2022:
- The boundary nodes team focuses on the useability features:
- enabling SEO (ETA: end of September)
- asset caching (ETA: November)
- supporting custom domains (no specific ETA, but the intent is to finish by the end of the year)
- The order of magnitude: months.
Q1 2023:
- The team starts implementing the new boundary node architecture that decomposes boundary nodes into “HTTP gateways” and “API Boundary Nodes”.
- As of today, there is no specific ETA for this decomposition (it could go into Q2 for example), but decomposing will include:
- Anybody being able to run an HTTP gateway (no NNS approval needed)
- Anybody being able to run an API Boundary node (NNS approval needed) and get rewarded for it.
- The order of magnitude: months.
- As the team knows more, the team will update on this thread.
We hope this post addresses a lot of the questions the community has raised about boundary nodes in the past months. We look forward to your feedback on how we plan to strike a balance between decentralization, useability, and security.
