Deploying the first API boundary nodes

Governance
1

Hello everyone,

I’m pleased to announce that we’re nearing the deployment of the first API boundary nodes under NNS control. Before we proceed, we need to submit a proposal for monitoring access from DFINITY datacenters. This will allow us to observe the health of the API boundary nodes and address any issues.

Following this, we will propose converting some unassigned nodes into API boundary nodes. This marks the first step towards the new boundary node architecture, detailed here.

Feel free to ask any questions. We will update this thread with the proposals as we submit them.

19 Likes
2

We have just submitted the proposal to allow access to all “monitoring and observability” ports from the DFINITY datacenters. You can find proposal 130319 here and vote on it.

In particular, this proposal provides access to the following ports:

  • 7070: orchestrator dashboard
  • 9091: orchestrator metrics
  • 9100: node exporter metrics
  • 9324: ic-boundary metrics
  • 19100: metrics proxy metrics
  • 19531: systemd-journal-gatewayd (logs)

For now this firewall rule has no effect, but will be used as soon as the first API boundary node is deployed.

5 Likes
3

And we have just submitted the proposal to turn two unassigned nodes into API boundary nodes. You can find proposal 130337 here and vote on it.

5 Likes
4

We have liftoff! :rocket:

Both proposals have been adopted and the first two API boundary nodes are live! Right now, they are not yet taking any production traffic as that is still routed through the existing boundary nodes. However, as we make progress towards the new boundary node architecture, we will gradually add more API boundary nodes and start shifting traffic to them.

The first two API boundary nodes are live and are happy to serve any requests you might have. If you want to try it out, you can for example query the total ckBTC supply using the follow command:

dfx canister call mxzaz-hqaaa-aaaar-qaada-cai icrc1_total_supply '()' --network https://bc1-dll02.blockchaindevlabs.com --query

or

dfx canister call mxzaz-hqaaa-aaaar-qaada-cai icrc1_total_supply '()' --network https://br1-dll01.aviatelabs.co --query
8 Likes
5

Awesome, congralutations to the team! :partying_face:

2 Likes
6

Why can’t I open https://bc1-dll02.blockchaindevlabs.com

7

The API boundary nodes only serve the API endpoints und /api/v2/... as defined in the interface spec.

When you try to open the root, you just get a 404 back. You can see it the best on the command line:

$ curl -sLv https://bc1-dll02.blockchaindevlabs.com
...
* Server certificate:
*  subject: CN=bc1-dll02.blockchaindevlabs.com
*  start date: Jun 13 08:16:02 2024 GMT
*  expire date: Sep 11 08:16:01 2024 GMT
*  subjectAltName: host "bc1-dll02.blockchaindevlabs.com" matched cert's "bc1-dll02.blockchaindevlabs.com"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
...
< HTTP/2 404
< content-length: 0
< date: Thu, 13 Jun 2024 11:57:59 GMT
<
* Connection #0 to host bc1-dll02.blockchaindevlabs.com left intact
8

What is the difference between bc1-dll02.blockchaindevlabs.com and icp0.io

9

bc1-dll02.blockchaindevlabs.com is the domain of an API boundary node and icp0.io is a domain of today’s boundary nodes.

I guess that doesn’t really help much. So what does it mean:
We are redesigning the edge of the Internet Computer. Today, there are boundary nodes (or “today’s boundary nodes”) and they do mainly two things:

  1. translate your browser’s HTTP requests into API calls;
  2. route API calls to the right subnet and replica.

This is what is running under icp0.io and ic0.app. These domains serve both purposes: you can directly access canisters using CANISTER_ID.icp0.io and you can directly submit API calls using icp0.io/api/v2/....

The new edge will, at a very high level, split today’s boundary nodes into two entities: API boundary nodes and HTTP gateways. API boundary nodes only serve the API endpoints, while the HTTP gateways mainly provide the capability to access canisters directly from your browser.

Ultimately, bc1-dll02.blockchaindevlabs.com/api/v2/... serves the same purpose as icp0.io/api/v2....

For more information about the new edge of the Internet Computer, check this thread about the boundary node roadmap.

2 Likes
10

Hi @rbirkner, thank you for all of the awesome work you and your team have been doing :folded_hands:

As of today, if a user would like to access a website hosted on the IC, what are their options for accessing it in a way that is least susceptible to an attack. Assume the user signs into the site and deals with large sums of crypto (so if an attacker can control what the user sees on the frontend and how it interacts with the backend, then they can control what happens to the funds).

Take https://waterneuron.fi/ as an example, which is also accessible via https://n3i53-gyaaa-aaaam-acfaq-cai.icp0.io/

1 Like
11

Hey @Lorimer

Thank you for the kind words! I really appreciate the support. :folded_hands:

Regarding your question, there are three ways to access canister frontends on the IC via the HTTP Gateway Protocol:

  • The most convenient option is using one of the DFINITY-operated HTTP Gateways, allowing users to access sites directly from their browsers without extra setup.
  • If users prefer not to rely on DFINITY’s gateways, other operators or a dapp team (e.g., WaterNeuron) could run its own HTTP gateway (either catch-all like DFINITY or dapp specific). This requires additional infrastructure and maintenance. Users still need to trust these operators, but they have more options.
  • For maximum control, users can run a local HTTP gateway, eliminating reliance on external parties. A proof-of-concept can be found here: HTTP proxy.

If you only need to do API canister calls, you can directly target the API boundary nodes using the agents and completely bypass any centralized infrastructure.

3 Likes
12

Thanks @rbirkner :slightly_smiling_face: What sort of trust assumptions need to be made about the boundary node that gets used? Presumably the node could act as a man in the middle and modify the request :thinking:

13

Good question:

HTTP Gateways need to be fully trusted as they take your HTTP request, transform it into an IC API request (usually query call), verify the certification of the query response, and then turn the query response into an HTTP response. The HTTP gateway can modify, inject, drop at any step of that. Here, you are trading convenience for security: you are trusting the gateway operator.

API boundary nodes on the other hand don’t have to be trusted. The worst an API BN can do, is to drop or delay your request or the corresponding response. This is the case as you as a client sign the request and the replica signs the response.

1 Like
14

Thanks @rbirkner! I could definitely do with diving deeper into this topic. Ideally I’d love there to be a way for all users to be able to depend on IC websites, even the less tech savvy ones (without having to make trust assumptions). I have some additional thoughts / questions.

Presumably if there are multiple domain names, and each one is controlled by a different entity, one could validate that all domains serve binary equivalent assets (given certain requests), providing DNS consensus. Is this an approach you could see working?

If there’s no need for any significant trust assumptions about boundary nodes, is it not possible to extend this safety to http gateways? For arguments sake, if an API call to a boundary node returned a byte stream representing and HTML page (and/or other assets), couldn’t this be served up by the browser (theoretically speaking)? I guess I’m trying to understand why the security that’s offered for API calls to boundary nodes cannot also be applied for HTTP request/responses.

Given that DNS is all about not having to memorise an IP address, theoretically a user could just visit the IP address directly, rather than entering a domain name. I guess that only gets you this far though → https://193.118.59.140/

I’m mostly thinking out loud, but I’d really appreciate your insights relating to these thoughts.

1 Like