Boundary Node Roadmap

Roadmap
61

There’s CNS as an initiative to decentralize name resolution, and when the local HTTP Proxy integrates with CNS, that would be an e2e decentralized solution.

This requires additional software to be installed on a user’s computer though and we still need to cater for the scenario of a user encountering a Dapp on the IC without any pre-installed software. I think in the long run, having native browser integrations will be the best solution, but we’re probably quite a bit away from that right now.

For CS/SSL, there’s DANE, which would work very well with CNS, but this would require browsers to support it.

2 Likes
62

I agree, something like this could be very cool! Without some kind of monetary incentive, it’s hard to imagine that there would be many (if any at all) groups willing to run general gateways that would serve any canister. Without solving that problem, it would end up as Dfinity running a general gateway and a few dapps running their own individual gateways. If there’s a monetary incentive, we can make the situation much more federated.

4 Likes
63

Are there still going to be or can there be community owned boundary nodes? Or are the NNS controlled boundary nodes replacing community owned ones?

1 Like
64

Hey @timo

It depends on what you mean by a boundary node. At a high level, today’s boundary nodes consist of two parts: the API endpoints (query/call/status/read_state) and the HTTP gateway (which translates browser requests to API calls).

The API boundary node will only handle the API endpoints. These nodes form the edge of the IC and mostly take care of routing the API calls to the right replica nodes. These API boundary nodes will be handled the same way as replicas today: nodes are provided by node providers and the NNS decides, which node will be turned into an API boundary node and what version it runs.

The HTTP gateway (and many other gateways) are like an additional layer around the IC that translate one protocol into API calls. These gateways will be community operated. Our goal is to provide a HTTP gateway reference implementation that can then be run in different forms (e.g., as a container, VM, or as a Cloudflare worker).

Does that answer your question?

7 Likes
65

Is there an earlier version which we can get our hands on ?

We would like to do a POC to read on-chain data at a very high frequency with zero downtime or timeouts.

2 Likes
66

Hi Boundary Node and Gateway Team,

I wonder is there any possibility of writing custom TCP based protocols in the ICP echo system. What all are the options currently to send/receive sensor data from IoT devices. Where should I start if I want to implement a MQTT on the ICP? Or is this a too high expectation now :slight_smile:

Thanks

2 Likes
67

Sorry new to this forum. How can I run a node? Do I need to hold ICP to run a node?

68

Hi @tomvictor

At the moment, you would have to create a gateway, some external service that translates between whatever protocol you want and the IC API.

The guys from Omnia Networks (@massimoalbarello and @ilbert) have built a websocket gateway and are interested in IoT as well. It’s probably good to chat with them. They have a discord server here.

2 Likes
69

Hey @Metaicp

You can find more information about becoming a node provider on the Internet Computer Wiki.

1 Like
70

See how to become an icp node provider - Google Search

71

Hey, the trading of NFTs are very slow for years (on entrepot.app), I was talked that’s because there are very limited boundary nodes, is it? Can you guys solve the slow issue asap?

72

Hello @daijianlin

I replied in your original thread: Trading is very slow is it the issue of limited boundary nodes? - #2 by rbirkner

1 Like
73

Whats up to date? Boundary nodes once again not sustain traffic when motoko claim happened. What is on the roadmap to make them more resilient when high traffic happens on the boundary nodes?

1 Like
74

What is the latest on the boundary node roadmap? Has the distinction between HTTP Gateway and API node been fully realized? Can community members now independently run an HTTP Gateway?

3 Likes
75

Hello everyone,

Thanks @lastmjs for reminding me to provide an update. It has been long overdue :slight_smile:

Progress:

The beginning of the year looked a bit different than planned. Due to (or rather thanks to) periods of increased load on the boundary nodes, we dedicated significant effort on improving the current boundary nodes, eliminating bottlenecks, and tackling tech debt.

Besides that, we have been working on the decentralization of the boundary node: the API boundary nodes.

Boundary Node Performance

As many of you might have noticed, there were multiple instances in the past two months during which the boundary nodes reached capacity. While this underscores the popularity of the IC, it’s detrimental to user experience.

Step-by-step, we improved the boundary nodes and removed a lot of tech debt. I will just highlight a few examples here:

  • Switched all boundary node internal communication from TCP sockets to UNIX sockets (e.g., nginx to icx-proxy, or nginx to ic-boundary).
  • Improved our logging infrastructure to use less CPU.
  • Eliminated all njs-modules in nginx (Yes, nginx supports JavaScript and they are inefficient).

At the moment, we are in the process of benchmarking the boundary nodes to better quantify the improvements. We will post an update once that is done.

Preparing for the API BN rollout

Besides the performance improvements, we have been continuously working on the boundary node decentralization. I am happy to report that almost all work is done and we are getting closer to making an NNS proposal to deploy the first API boundary node.

  • IPv4-enabled Nodes: The code is complete and released. The first node providers have already onboarded node machines with IPv4 addresses assigned. The focus is now on the rollout and we are encouraging all node providers to add IPv4 support to some of their nodes.

  • Discovery Library: All the code to enable clients to discover all API boundary nodes in a certified manner has been merged and is in the process of being rolled out. This will most likely be fully functional with the next replica and agent release (for now only agent-rs).

  • Orchestrator: We are currently working on wrapping things up. The last bigger work item is the configuration of the firewall.

HTTP Gateway

As we are nearing the rollout of the API boundary nodes, we are starting to pick up the work on the HTTP gateway. The goal is to build one binary, similar to ic-boundary. However, to get something “working” as fast as possible, we are at the moment working on an “interim” HTTP gateway. This will come in the form of a docker container, which is easily deployable, allowing anyone to run their own HTTP gateway.

Outlook:

We have a few tasks left before the first API boundary nodes can be deployed under the management of the NNS. Once that is done, we will shift our focus to building the HTTP gateway, ic-gateway.

We will continue to keep you updated on our progress and look forward to hearing your feedback and addressing any questions you may have!

10 Likes
76

Looking forward to the HTTP gateway image!

How many replicas are you proposing to turn into API Boundary Nodes?

77

We don’t have a clear number yet, but most likely in the same order as we have boundary nodes today and then adapt that according to the needs.

78

The IPv4 function is pretty important for us. Could you please elaborate how our canister can access the IPv4 boundary nodes?

1 Like
79

Hey @w3tester

What is your use-case and what do you mean with “how our canister can access the IPv4 boundary nodes”. IPv4 on the API boundary nodes is only used for incoming connections (i.e., clients can connect to the IC using IPv4). If you are thinking about HTTP outcalls with IPv4, then this will not (yet?) be enabled by the API boundary nodes.

80

Hello @rbirkner, our use case is to pull twitter API data within a canister. They only support IPv4 access atm. It seems this update will not help us then…