Due to the network providers in China, many home users do not have a public IP address. Most of them are only given private IP addresses by their providers, which results in slower node synchronization. Therefore, it is necessary to add a feature allowing users to specify a node, so they can manually choose which node to connect to.
The second issue is the limit on the number of connections imposed by providers. If there are too many connections, it may lead to a temporary network ban. There should be a configuration option allowing users to adjust the number of connections.
These options can be modified in the Advanced CLI, but they cannot be changed in space-acres.
This does sound appealing on the surface, but if I simplify it, you’re asking for ability for a member of decentralized network to permanently connect to a centralized point. This kind of defeats the purpose because that single connection point can now control what those connected to it are seeing or not seeing, can censor their blocks/votes, etc.
So this is not a real solution to a problem because it creates more problems, hence there will not be such option in Space Acres.
This doesn’t mean the issue isn’t real, it absolutely is, but we need actually geographically distributed network, not a centralized one.
We already plan to have bootstrap nodes in mainland China to improve bootstrapping process and we will hopefully have enough nodes on the network for such clients to connect to.
Interesting, do you have any specifics on this from recent history? We have switched back from UDP/QUIC to TCP and Space Acres just like CLI uses fairly conservative limits by default (which can be increased in advanced settings of Space Acres). There are already changes that will be included in mainnet and pre-mainnet tests that will reuse connections as much as possible, improving situation further.
Reducing connections to even lower value will result in a horrible experience where everything will be very slow to download, but bad experience for our users is not desirable.
As explained above, there are reasons why they are not present in Space Acres. Both suggestions combined are effectively suggesting to turn distributed P2P application into a thin client of a farming pool, which is extremely undesirable.
I’m open to suggestions on how we can improve situations for farmers in China, but we need to find a way that doesn’t compromise the values with which the network was built. As you can see a few improvements on top of Gemini 3h were already done before mainnet and I’m always looking for fresh ideas to improve the situation further.
What I meant is that they can purchase a VPS server with a dedicated IP from a data center like Alibaba Cloud, set up their own node on the server, and then connect by themselves. There is no public node provided for them to connect to.
In China, there are three network operators. Based on my tests, China Telecom has a higher tolerance for high connection counts and high upstream usage. The other two operators, if using the default parameters, may experience disconnection from the network within half a day. However, if the number of connections for all farms is adjusted to 10-20, they can run for a much longer period.
As mentioned above, the two suggestions I made will not lead to centralization. On the contrary, if you don’t address these two issues, many people might opt for using mining pools for simplicity.
In my ideal scenario, users could purchase a cloud VPS to set up their own node and then use a simple GUI version to remotely connect to the node they set up on their VPS. At the same time, they can lower the number of farm connections to reduce network load and avoid being blocked by network operators. This configuration better suits the current network environment in China.
That is still a bit backwards and not something I expect the target audience of Space Acres to do. Wouldn’t it be possible to set up Wireguard VPN in that case instead?
While I understand and appreciate that they want to participate in the network, from the grand scheme of things nodes and farmers that can only have 10 connections and even then not guaranteed to stay online are not helping the network all that much. So in some sense it is better for them to not be on the network than to be with 10 connections and being unable to server the data to anyone anyway.
Again, having VPN to a server that does allow for higher number of connections will help with connections issue, but not with bandwidth.
I see, the context helped a lot, thanks!
Now I’m wondering if VPN to a server will be an easier and more general option.
While a VPN can indeed achieve this functionality, it is better not to use a VPN in China.
Regarding the issue of farm connection counts, if you say that having only 10 connections is unnecessary, many people have also set extremely low connection counts in the CLI. Their technical personnel have modified certain aspects, allowing them to farm hundreds of terabytes or even several petabytes with very minimal upstream bandwidth, while their rewards are not any less than ours. Could this be a design flaw?
Even within the country? I understand why reaching outside might be problematic.
I’m not saying it is “unnecessary”, I’m saying it doesn’t really help the rest of the network as much as it could. While yes, they contribute to consensus and that is helpful, they are not really providing data availability service and are physically unable to. I really hope that those with petabytes of storage can manage to have a decent Internet connection even in China, having 10 peers is ridiculous in that setup and not something we should encourage.
I wouldn’t call it a flaw in the protocol, I am not aware of the way to force them using higher number of connections, but it is definitely undesirable. I’m not sure adding such a feature into Space Acres for even more people to do that is a really bright idea. I’m more interested in what we can do to make the default experience better for Chinese and other users without them configuring anything.
I do get the point about pools and agree with it BTW.
I think it should be like the CLI, allowing users to customize the configuration. If users find it troublesome, they will most likely choose to join a mining pool.
Although mining pools consolidate most of the computing power, I think the nodes of the mining pools probably won’t provide much upstream bandwidth, so their overall contribution to the network is likely very low.
This is a complicated issue, and I don’t have a good solution for it either.
As for what you mentioned, adding a bootstrap node in a data center within China, I think this approach might be feasible, but it hasn’t been tried yet.
How is connecting to a node is substantially different than using a VPN though? The net result is very similar (except you will probably not be able to serve any data to the network at all without VPN).
Space Acres is intentionally not like CLI, it is supposed to “just work”. If user is comfortable renting a server and pointing node to it, they might as well run CLI locally as well.
I don’t think this is an issue that is specific to Space Acres, so, ideally, we’d find a solution that improves things for everyone without extra configuration necessary.
They do participate, but we don’t have a goal for absolutely everyone to be able to participate, even those who can’t physically maintain connectivity with the rest of the network. There are reasonable requirements and having connectivity with the world is one of them.
Improving connectivity for everyone is a solution, connecting through a rented server is awkward and can already be done with CLI, but it is less than ideal. Going through centralized nodes is not a real solution though.
I would like to mention what you brought up last time about adding bootstrap nodes in China. In other blockchain projects, we can set up our own bootstrap nodes, but for Autonomys, I’m not sure whether we can set up our own bootstrap nodes or if they can only be created by the official team. I have extra servers, and I would like to test using a bootstrap node located in China on the Taurus testnet to see if it can make node synchronization smoother. If we can test this before the mainnet launch, that would be ideal.
You absolutely can. Those that are in the chain spec will be initially set up by the foundation, but more will be added over time, potentially community-run as well. You can always override those with CLI options of course.
Bootstrapping is important, but it is only one step, it doesn’t fix connectivity at large. I discussed this at libp2p community call last week and I think there are things we can do to try and improve the situation, but it’ll take time to actually implement it.
I want to ask:
Currently, there are about three official bootstrap nodes.
If I add the specified bootstrap node parameter in the startup command,
will it primarily use the bootstrap nodes in the China region?
Yes, but I don’t understand why would you possibly want that. Bootstrap node in China doesn’t mean you’ll be getting peers from China since DHT is not based on geographical conditions. Moreover, that node is already struggling due to low network bandwidth available in Alibaba Cloud comparing to other providers, to it is possible that by doing that you will simply remain offline completely.
DSN is easier since it remembers peers from last startup and will actually not use bootstrap node after first time if it can avoid it, but Substrate doesn’t have such feature unfortunately and reconnects to the bootstrap node on every restart.