Consensus Algorithm for Nano

Hi everyone,

I had recently made a post on reddit.

This is my further work on the concept.

An account is allowed to assign its voting weight to two representatives:


                                           Fig -1

The rules are as follows:

  1. Directly Elected Representative nodes
  • The accounts assign their voting weight to the nodes and any node whose voting weight is > 0.1% of the total supply is a permanent representative(PR), and the PRs vote on the transactions — pretty much what we have right now.

  • The role of these nodes is to have a byzantine fault tolerant ledger of the PRs in the Local Representative nodes. A PR of local representative nodes is a tree of nodes and accounts (see fig-2). The ledger will have these trees.

  • These nodes will also act as a fall back, in case the local representative nodes are corrupted (explained on the paragraphs following the fig-2).

  • The ledger is updated every week and shared with the nodes of Local Representative nodes.

  1. Local Representative nodes:
  • The system has a value X, such that anyone with X nano can run a local rep node (Having X nano is enough for running both types of representative nodes).

  • Each local representative nodes know who the PRs in directly elected representative nodes are.

  • Local rep nodes (N nodes) are allowed to assign their voting weights to another local rep node as long as the total voting weight of N+1 nodes is not greater than 0.25% of the total supply of nano.

  • A local rep with more than 0.1% of the voting weight, all gotten directly from some accounts, is a PR.

  • A local rep will require 0.2% of the voting weight to be a PR, if the local rep is getting the voting weights from other local reps as well.



                                                    Fig -2

Until X day of Week 1, the accounts are allowed to change their local reps. At the beginning of Week 2, the directly elected nodes will a new ledger of PRs in local nodes from Week 1. The PRs of local representative nodes will vote on the validity of the ledger sometime in Week 2 and update their ledger at the beginning of Week 3. If a consensus can’t be reached, the local representative nodes will not update their ledger, but maintain the status quo — in case there is a collusion among the PRs in directly elected rep.

Beginning of Week 4, the directly elected nodes will have Week 3’s ledger with the PRs of the local representative nodes. Like before, the ledger is shared with the local reps, however, the directly nodes will also check if the consensus was reached among the nodes on Week 2’s ledger.

If the consensus wasn’t reached on Week 2 as well as Week 3’s ledger, on Week 5, the directly elected nodes will check if the accounts have cancelled the local reps, and have assigned the vote solely to the directly elected nodes.

When the majority of the accounts have cancelled the local reps, the PRs of the directly elected nodes will take over the roles of local reps, until the local representative nodes that agree on the ledger of the directly elected nodes are created.

If there indeed was a collusion among the PRs of directly elected representatives, the accounts have Week 2, Week 3, and Week 4 to change their directly elected PRs.

In essence, local reps have power as long as there is no collusion among them. If there is a collusion, the power of the network falls back to the hands of directly elected nodes. And if there is a collusion among directly elected nodes, since they do not have much power, the network will have sufficient time to discard the information from them, and remain in a safe status quo until it is resolved.

  1. The vote of the PRs of local representative nodes will have the final say on all matters of the network. For example, in our case(the system with two sets of nodes), they will vote on the transactions made by an account, and the value X mentioned above.
    Suppose, instead of just two sets of nodes, we had 3 sets of nodes. Let’s call the third node health nodes. The representatives of the health nodes are directly elected. And in our system, we have streamlined a transaction coming from an account to be signed by its local representative first (except when it is a change rep transaction. The change rep transaction is voted by the PRs of directly elected reps).
    We could have the health representatives analyze the network. If the network is getting spammed, it would be coming from a representative. The health network then votes if it is the representative who is spamming the network, and send this information to the local representative nodes to vote on and ban the spamming rep.
    If it is a legit representative with the transaction needs, they could come to, maybe, reddit or some platform, and give their info to the PRs of local representative nodes, so that they can manually reject the information from the health network. In worst case, being a representative might take some time.
    If the network is getting spammed by too many representatives, and the local representative nodes having to vote on these kinds of transactions have lowered the CPS of legit transactions, then the local representatives could temporarily handover the banning power to the health network.

This basically is the design of the system; the directly elected nodes count and know who the PRs in their nodes are, as well as the PRs and their associated nodes and accounts in local representative nodes. Local representative nodes count and know who the PRs in the directly elected nodes are, but get the information about the PRs in their nodes from directly elected nodes.

As for the privacy; if an account wants to send anonymous transaction, it could create two blocks. The sender information on the current block will be replaced by the address of the local representative of the account, and the other block will have the sender information required to vote on the transaction. Only the block with the local representative address will be cemented. The representative could keep a ledger of who and where it has allowed its name to be used, or go tor.

Edit: Some name changes were made.

What's the main problem this is trying to solve?

1 Like

Decentralization. But having multiple node softwares should solve any problem that requires allocation of more resources, in a system like nano.

How is Nano's current implementation of ORV consensus not already decentralized? Consensus on protocol rules/decisions is already determined in a decentralized way by collective node operator actions and PR vote weight distribution. Your proposal seems very complex, and I'm not understanding what benefit it brings over what we already have

It is decentralized, but it doesn't address the centralizing force that's there.

Also, in general, when a network is hosting an asset (nano in our case), the network becomes an asset itself. The case in point is the derogatory word rent-seekers of the network. The question is, why are there rent-seekers in the network? One reason is the lack of technology to solve an spam attack. The other being, it is a direct incentive to run a node so that the network exists.

As much as one wants to believe there doesn't have to be a direct incentive to run a node, it is only true as long as the receivers are willing to run the nodes -- for they are the ones receiving it, so the burden of how they are gonna receive it should fall on them.

The market is these receivers and it is competitive. Why would a capitalist not simply use the network instead of running a representative node? What's gonna prevent him? And if he decides to do so, how could the added and unasked burden that falls on the current node operators be addressed? In this sense, in addition to lack of tech to solve an spam attack, it is also the lack of proper decentralized consensus algorithm that justifies the word rent-seekers.

The paradigm that I am proposing (treating nano as just a ledger supported by multiple node softwares) should solve the spam attacks as well.

Suppose there is another set of nodes (directly elected) -- 4 sets of nodes total. This new set of nodes will vote on the transactions from a new integration node. Only when the new integration node has passed a time test (some kind of a loop) set by the health nodes, the transactions from the new node will get voted by the local representative nodes. Thus, making the local representative nodes the core of the network that is hard to attack.

There are no rent-seekers in a network that doesn't pay fees. What are you on about?
About lack of tech to solve spam... spam now is just normal transactions, they will have low priority but they are still transactions as normal. The network can scale with them now because all nodes agree on block priority.

The following algorithm could probably be used to prevent double spend in this scenario:

Let's call this new set of nodes integration-representative nodes.

An account has a label that identifies it with the type of integration node that was last used. We have two types of integration nodes. One that has already integrated into the local representative nodes, and the other one whose transactions get voted by integration-representative nodes.

As long as the current transaction from an account is voted by the same set of representative nodes that had voted on the previous transaction, there is no double spend.


  1. All transactions are checked to see if the integration node was switched.

  2. If the integration node was switched (Suppose it was switched to an integration node of local representative nodes from a new integration node in integration-representative nodes):

    1. The current transaction will be cemented by local representative nodes with a special non confirming vote on it, and will be sent to the integration-representative nodes for voting.
    2. The local representative nodes will wait for the confirmation of the transaction from the integration-representative nodes.
    3. If a new transaction is made while waiting, the transaction is discarded.
    4. When the local representative nodes get the confirmation of the transaction from the integration representative nodes, the label is changed and the local representative nodes will vote on the following transactions from this account.

The integration nodes in local representative nodes could set a rule such that we never get to step 3 -- we could have the health-node enforce the rule such that any integration node that does this will be considered a spam integration node.

Why do you want to introduce hierarchy and single point of failure to a decentralized network?

I am sorry, I am not understanding what you mean by single point of failure. To me it seems indifferent to the failure we might have in the current system.

I believe you meant a PR of local representative nodes is hierarchical. It would be ideal, if it could be engineered to be cooperative instead of hierarchical. Like, suppose there are 3 representative nodes with 0.08% of the voting weight each. And the current tps of the network is 120,000. Ideally, these three would cooperate to vote on 40,000 tps each, or, cooperate to vote on the transactions in the ratio of x:y:z commanded by the one with the higher resources.

That's not how "votes" work... votes in ORV are just a signature saying "I'm node xyz and I saw block #123". Then my node will check xyz signature, search for frontier blocks whose rep is node xyz, and sum the balances. Once enough "votes" are seen, my node will cement the block.
That's it, that's how it works.

A decentralized system with 0 nanos required to be a representative node.

Requiring certain amount of nanos to be a representative node will disenfranchise start ups with limited capital to participate in the network.

As the resources required to run a node is a capital in and of itself, it is in the interest of any node operator to lessen the resources required to run a node -- resources required to run a node increases as the size/tps of the network increases.

If the local representative nodes have a side chain, and are allowed to make a recommendation transaction to directly elected nodes   for a new node who won't be requiring any nanos to be a representative node, it will not just help with the increase in demand of resources by the network, it will also help create a whole incentive scheme.

As the system matures, let's say to a point A, the local representative nodes will no longer be required to have any nanos to be a representative node. The could sell it.

Any new node will still require X nanos, or will be required to be recommended by a local representative node from its   quota to be a representative node.

The incentive scheme:

The above design has 4 sets of nodes:

  1. Directly elected nodes
  2. Local representative nodes
  3. Health/Sentinel nodes
  4. Integration representative nodes

An integration representative node is a phase of a local representative node -- once an integration node passes the test set by the sentinel nodes, it gets to be a local representative node.

The local representative nodes are the core of the network where the nano transactions happen.

Any receiver who wants to receive nano would want to run a local representative node because otherwise it could be costlier to receive nano.

Once a receiver is running a local representative node, it is in the best interest of the receiver as well as the network to have a representative node who have assigned their voting weight to them and now these two (could be more) are now voting in the transactions in the ratio of x:y (x+y being the tps of the network).

So, basically, out of the four sets of representative nodes that we currently have, only the local representative nodes and the integration representative nodes provide an incentive for a receiver to run a node.

There really is no capital incentive for a receiver to run a directly elected node, or a sentinel node, as well.

As the directly elected nodes will be voting on the recommendation for a new node transactions, the directly elected nodes could set a quota; A local representative node is allowed to make x recommendation in y time frame, and if it wants to make more recommendation transactions than its quota, the transactions will cost p amount paid as a fee to the PRs of the directly elected nodes -- p being set by the directly elected nodes.

In this design, the sentinel nodes are essential part of the network to prevent the spam attacks. However, a receiver who is running a local representative node, or is in an integration node phase, may or may not run a sentinel node (if each one of them are running   the   sentinel node as well, any incentive scheme will just be a gimmick).

The PRs of the sentinel nodes are paid their dues by the local representative nodes.

However, an account can not assign its voting weight to a sentinel node. Only a local representative account can assign its voting weight to some sentinel node. The sentinel nodes can cluster together to form a PR using the algorithm from this post.

If a system is designed this way, it enlivens the competitiveness in the economics of the sentinel nodes where the PRs of the sentinel nodes charge the local representative nodes a fee.

Lets say, the algorithm to prevent the spams involves monitoring the transactions in the network and discerning spam transactions from the real ones. This requires each local representative node to run a sentinel node that is capable of monitoring its parent local representative node transactions. This will lead us to the following equation;


2 x local representative nodes = sentinel nodes ("2x" because just as much resources might be required for the sentinel node to monitor itself as well)

In a sound system, the total resources at the set of sentinel nodes is always greater than that of the total resources at the set of local representative nodes.

Unless each local representative nodes are running a sentinel node that they are supposed to run, the algorithm is inadequate to incentivize the sentinel nodes to do their job, because not every one will run it. And if forced up on by the protocol, it is a barrier to decentralization.

The PRs of sentinel nodes could create a billing system where each local representative node is charged a certain amount based on the number of transactions it does and the resources it has put on a sentinel node.

If each and every local representative nodes (and integration nodes) are running a sentinel node that they are supposed to run, and the grouping together of these sentinel nodes to form the PRs are exactly the same as in the local representative nodes, local representative nodes will be paying themselves in the sentinel nodes, making the incentive scheme a gimmick.

They will probably be paid at the sentinel nodes for running a sentinel node. So, that will probably be redundant.