Is there a way to manage the nodes’ joining the network in algo’s blockchain?
Or
how to change algo into a permissioned blockchain?
Sorry, I don’t know. I’m glad to know what is your definition of “permission blockchain”.
It is possible to create a private network, on which you can decide the full distribution of the Algo:
If you restrict connections to the relay nodes, this should act as a permissioned blockchain.
I’ve just started looking at the possibility of running a private network for commercial purposes. (A client has looked at Hyperledger and can see the benefits of having multiple chains in the implementation, some of which would be private.)
Jason’s article about how to “Create a Private Network” is a good primer but the first sentence underlines the fact that much more would be required to set up a robust and secure private network.
Is anyone else looking into this topic right now?
@fabrice, I agree that a private network could be achieved by limiting access to relay nodes. Such a restriction could be achieved in multiple places (e.g. network firewall, node firewall, blockchain configuration etc.) but if these approaches are dependent on specific IP addresses (or ranges of addresses) then it creates a complex interaction between the administration of the blockchain infrastructure application and the administration of the network infrastructure.
IP addresses are not fixed! If I am running a relay node and need to shift that node onto a new platform then all other nodes, which have a need to connect to my node in a private network, would need to update their configuration to allow my new IP address (and possibly deny my old IP address). The administrative effort involved in a modestly sized network will quickly become significant. For a private network to function effectively and securely then this administration must be undertaken rigorously and timely.
A permissioned blockchain, on the other hand, typically shifts the administration away from the nodes’ network addresses and uses a cryptographic certificate mechanism to permit access.
The certificate identities of the nodes permitted to access a private network are stored on a public network. (This public network need not be mainnet - though there are very good reasons to consider it - but could be a more private network that all consortium partners can access.) Permission can also be revoked by posting a transaction on the same network.
The permission to join a private network as a relay node or participation/archival node is then managed and secured purely by certificate identity and not network identity.
(Paranoid organisations may also wish to layer network security restrictions on top - if they are prepared for the increased administration effort.)
My ideal approach would be to use the mainnet as the focal point to spawn other networks. If a spawned network were intended to be another publicly accessible network (like testnet) then there would be some form of wild-card entry indicating open access for all. If a spawned network were intended to be a permissioned (private) network then tokens, posted on the mainnet, referring to the spawned network would provide the certificate identities of the nodes permitted to join the spawned network.
A hierarchy of networks might exist - all anchored back to mainnet.
[Perhaps, one day, when mainnet becomes excessively large, it might spawn a new mainnet (e.g. mainnet2) and tokens created that do not rely on the history of what occurred on mainnet can be processed by nodes that don’t need to carry the baggage of the mainnet. Just a thought.]
There’s a lot here, so I’m going to pick only the IP addresses issue -
the Algorand network ( and any private network for that matter ), fully supports automatic resolution of relay servers via SRV records and DNS servers. That’s how all the three public networks are working ( mainnet, testnet and betanet ).
There is no reason you wouldn’t be able to do it yourself, and all you’ll need to do is to configure the DNSBootstrapID field in the config.json file.
This area of the implementation is usually gets less attention, since it requires more setup, and it’s no longer free - someone need to pay some money to register a domain name, and some more to manage the DNS & SRV entries.
When you’ll get to that point, don’t hesitate to open explicit question about now. I’ll be happy to provide more details.
Hi @tsachi,
Thanks for the pointers - I’m a little way off setting up a rig to test this out though. I have access to a domain and the DNS config skills so it shouldn’t be a problem when I’m ready.
However, the topic I was most interested in probing was the “permissioned” aspect of a private blockchain.
Automatic DNS resolution of relay servers (in a private network) is great and provides an effective way to set up the core of the network. However, when a non-relay node wants to communicate with the relay network how can the relay nodes know whether the non-relay node is permitted to join?
Is there anything like a certificate registration mechanism that provides such permissioned access?
@rmb, filtering incoming connection is an area which was left aside purposefully.
You can achieve that using existing network solutions, such as nginx - and dial the security to your needs.
I agree - but this it bolting on something else which is divorced from the blockchain.
I think I have enough infromation for now. Much appreciated.
I think making an entirely private chain is pretty simple and all within the realms of standard networking constructs. Providing secure access from outside that private network could be handled with things like envoy on both sides acting as a secure tunnel with mTLS.
Where it gets more interesting I think is how co-chains will work - ie: the Marshall Island’s SOV co-chain. How will it run as entirely independent private/secure co-chain yet still allow transactions against mainnet. Since they don’t really ‘exist’ yet formally, I’m sure we’ll find out more in time.
1 Like
I agree that it is within the realms of standard networking constructs - but this would still be a bolt-on rather than an integral part of a permissioned, private blockchain.
If any one operator of a “private” node did not adhere to the network bolt-on policies across all the nodes they operate then the security of the “private” network would be compromised.