UNL protocol ideas

[wojake]

I have a concern regarding HotPocket dApps that act as layer-2 smart contracts for payment networks like the XRP Ledger but I need to be sure that my understanding is correct 😄 :

If a person gets hold of the application's filesystem, source code, configurations and its nodes' IP address, could they partake in the app's network as a node?

Let's ignore any third party code on the app's source code that mitigates this problem, is this possible?

[ravinsp]

@wojake This is solved by the UNL. Every HotPocket node only performs consensus with other nodes that are in its UNL. So if a new node wanted to partake in consensus, the existing cluster must add the new node into the UNL. If the new node is not in the existing cluster's UNL, it could only observe consensus but not influence it.

A contract could also make consensus to be fully private among the UNL as well by using "private" consensus mode. Then the consensus messages will only be exchanged between UNL nodes only. This would make it impossible for a new node to even observe/listen-in too.

[ravinsp]

I'd also like to add that, in order to "discover" an existing cluster, a new node only has to know the contract id, and just one of the existing UNL node's public key and ip:port. It doesn't even need to have the source code. Just establishing a link to one of the existing UNL nodes will make the new node "auto-sync" the existing unl, source code, ledger history etc.. It will essentially become a clone automatically but will possess passive observation ability only.

[wojake]

Thank you! I did take that into account but considering that nodes are autonomously running the code, meaning that the nodes' operator aren't necessarily managing their nodes' UNL manually. Since this is all autonomous, if the node were to stay for a consistent amount of time, they may be added to a large portion of the nodes' UNL.

This is all assuming that any connected non-UNL peers are going to be added to nodes' UNL if they connect for a long enough period of time and not a unique way that the application uses to add and remove nodes from a number of its nodes' UNL (ie on-chain governance or other plethora of ways to instruct nodes to add a certain node to their UNL).

In my current understanding, this may be a problem since the HotPocket nodes' operators aren't necessarily participating in a certain application's consensus by managing their nodes' UNL manually.

[wojake]

I just can't think of any other way to manage a node's UNL naturally, by code and not manually except through governance decided by parties that aren't necessarily the operator(s) of the underlying node(s).

[ravinsp]

"if the node were to stay for a consistent amount of time they may be added" - There's no such rule in HotPocket. In order to make such a thing happen the Dapp code would need to have this rule in its code to auto add any new node that's been there long enough. Understandably such a scheme can be exploited easily. Obviously the Dapp needs some sensible set of rules that fits its purpose to allow new "external" parties to join or the Dapp itself needs to be self-governing in such a way that it would manage its own cluster and spread itself among different nodes. We think the latter will be the most sustainable/dynamic way to do it. A nomadic contract would create new nodes itself and get them joined to the UNL so there's no "external" party or trust criteria. In this case the "operator" of the cluster is the contract itself.

It's already possible to do this with HotPocket and Evernode libraries within your contract with some thinking and coding. We also do plan to make this easier using some more libraries which will help you do this within your contract.

[wojake]

Ah yes, sorry about the confusion since I separated the This is all assuming that any connected non-UNL peers are going to be added to nodes' UNL if they connect for a long enough period of time on another paragraph. Let's discuss and share ideas here if anyone is wiling to share their approach to this.

[wojake]

@lathanbritz I'd appreciate it if we could have conversations on UNL management here instead of Twitter? It'll be much more easier for everyone to read and contribute in one page.

I have a few structures that I may want to publicize here which would manage a HP cluster's majority UNLs

[shortthefomo]

My tweets were around the XRPL's UNL not hot pockets, I was exploring the possibility of putting a XRPL UNL into a contract in evernode but managing the XRPL UNL not that of the contract it's self.

I have not even put any amount of thought into management of the UNL of the contracts.

[wojake]

https://github.com/EvernodeXRPL/membership-contract by @kithminisg & @chalith <3