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?

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