RFC - Super Nodes

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
Post Reply
Posts: 69
Joined: Tue Sep 18, 2012 10:09 am

RFC - Super Nodes

Post by dangermouse »

Below is a proposal detailing possible implentation of Super Nodes in Timekoin.

I have tried to use the general Timekoin idea for them. I do think they will be needed as the network grows, if only for peer discovery. I also think they could play a role in maintaining transaction history and making it easier to look-up public-key balances and make checks.

Anwyay, let me know your thoughts as it is just an idea I thought I would throw in the pot so to speak.


Possible Super Node implementation in Timekoin

Super Nodes

In short, Super Nodes maintain transaction history consistency, maintain public key balance information, maintain a list of peers for new network connects and deal objectively with transaction history discrepancies.

Super Nodes are network elected nodes that are partially trusted to keep track of public key balances and the full "official" transaction history. They provide a short cut for filling transaction history gaps and a way for peers to check balances for public keys quickly and easily. They may also participate in storing the old archived transaction history and providing hash data on previous transactions.

Election of Super Nodes
Super Nodes are elected by the network itself and broadly speaking, are elected on the basis of 3 super nodes per 50,000 public keys identified as being present within the network. The election is points based (which are awarded to a candidate super node based on time events) and any peer can put itself forward to become a Super Node. Super Nodes are elected every 30 days but only half the Super Nodes are replaced and the election is weighted. A candidate Super Node (a node which has generated a peer message saying it wishes to be elected as a Super Node) is awarded points based on the following criteria:

Time spent in the election list (1 automatic point per six days listed in the election queue)
Time spent acting as an existing Super Node (10 automatic points)
Random Election amongst all candidate peers (10 points)

No peer can elect itself or award points to itself and the node with the total highest points wins the election process. The above criteria make it slightly more likely for an existing Super Node to be elected again but also introduces a random element that would refresh the Super Node list periodically.

A typical election for a Super Node could thus go as follows:

Node A is already a Super Node (10 Points already for being a Super Node)
Node B is a new candidate (0 Points)
Node C is a new candidate but has been in the list longer than Node B (5 Points)

Candidate nodes participate in a random election. Node B wins and is awarded 10 points, Node A already has 10 points as it is an existing Super Node, Node C has been in the list longer and has 5 points. New Random election between only Nodes B and A as they now have the same number of points. Node C has lost and will not be elected in this election cycle.

Had Node A been elected in this cycle it would have automatically won the election as it would have had 20 points. Had node B been elected it would have automatically won the election as it would have had 15 points.

If a node does not wish to become a super node (it involves significant traffic) a user can disable their peer participating in the election process, however, in the event of a no Super Node position a forced election may elevate a peer to Super Node position without the consent.

A newly elected Super Node, contacts the existing Super Nodes (not one of the ones that has been “demoted”) and checks its transaction history against the Super Nodes history, if there are any discrepancies it replaces its own data with that from the Super Nodes. This helps to maintain network consistency. It also checks the current balance data and again, if there are any discrepancies, it replaces the data with that from the Super Nodes.

Super Node Shadow Mode

This enables a node to act like a super node. Suited mainly for business use of the network, it enables a node to maintain complete consistency with the other Super Nodes by ensuring its transaction history and balance information matches that of the Super Nodes. It will maintain a connection with every single Super Node as well as other peers that connect to it to send transactions. When it receives a transaction from a normal peer it will not accept that transaction until it has been verified by all Super Nodes. It will also download the complete transaction history and balance information from a Super Node to enable swift local checking and acceptance of timekoins from peers.

This mode would automatically be activated for any peer joining the Super Node election queue to ensure their transaction history is consisent with the existing Super Nodes.

Super Nodes and their network role
Each time a normal user node issues a transaction it sends a copy of the transaction to a random Super Node. The Super Node checks the balance and issues a Confirmation Transaction (CT) - this is first sent out to other Super Nodes who will do the same thing, each Super Node will check its records and then sign the transaction off by issuing its own CT. As each Super Node issues a CT it updates its Balance Information for that Public Key ensuring that all other nodes can also know what the new balance is for a given public key.

A normal user node can use this CT to check its own transaction history and its own balance information for public keys (a normal node would only keep track of public keys it has transacted with)

If a client user node has a full history of transactions and balances (such as would be required for business use or Super Node Shadow Mode) then when it adds together every transaction it should equal the balance on the very latest CT issued by a Super Node. If there is a discrepancy it would send a Discrepancy Check Transaction to a Super Node along with a complete list of all the transactions it holds for that particular public key. The Super Node will check this against its own list and respond (at a later time) with a compilation of transactions it has recorded as "official" for a particular public key. The enquiring user node will adopt this data as the official list of transactions and then verify by contacting other Super Nodes and sending them a copy of the balance and transaction hashes.

Each Super Node must be in contact with all other Super Nodes to share the Super Node data - there must therefore be at least 3 Super Nodes in a startup network and if one Super Node drops away due to connectivity then a new election would take place. Super Nodes will send copies of the balance transaction to each other and provided their balances (and transaction history) is in synch, will accept transactions as correct from each other. If there is a discrepancy the Super Node will check with its other Super Node peers and accept a majority.

Dealing with network wide data inconsitencies

If there is no majority ruling on the data, the node will itself issue a Self Certified Discrepancy Check. This will make the Super Node send out a message asking all peers it is aware of (including client user nodes) to send any and all transactions it has for a particular public key.

The node will then go through each transaction and every 500 transactions it will create a transaction hash with a list of the transaction id's and send this to another Super Node, that node will then check its own transactions against the hash and if it agrees will perform the same process to another Super Node peer.

Any dispreancies between Super Nodes will be resolved by majority and failing that, by a final random election to determine which Super Node will be regarded as the one with the correct data. Once agreed each node will adopt the elected Super Nodes data as the official record, thus maintaining the transaction history consistency across the network and ensuring that any falsely injected records are weeded out. All peers are consulted for their transaction histories for the data under suspicision – this ensures the network remains democratically involved in the process.

Corrupting Super Nodes
The process described above should minimise the ability for “false” Super Nodes to contaminate the network as the network itself chooses the Super Nodes and even if the network was flooded with false election data, the normal peers should be able to weed this out. As a normal peer must be connected for a minimum of 14 days to get in the queue to become a Super Node, this helps to prevent bot-nets taking over the Super Node positions. Electing to become a Super Node would result in significant traffic due to the fact that the Super Nodes transaction databases would have to be mirrored – it is likely this would be noticeable.

Initial Peer Node Activity
When a client user node first starts up with no history it will connect to a Super Node and advertise its public key and request a list of random peers. Essentially a client user node connects to a Super Node only to check a public key balance (which it then caches) and to check for transactions sent to itself from other peers it may not have a connection to or recived yet. The client user node will then contact other Super Nodes and verify the information sent by that Super Node is correct with the comparison of relevant hashes.

A client user node is responsible for its own transaction history and for sending this to peers. Super Nodes merely cache the history to enable connecting peers to pick-up transactions they may have missed by being temporarily offline, etc. A client user node can fill in transaction history gaps from other peers, however, it will connect to Super Nodes to check the hash of these and request the Super Node's copy of the data in the event of a discrepancy.

Any discrepancies between Super Nodes will be handled between the Super Nodes themselves. Client user nodes can only inform a Super Node and other peers of a transaction discrepancy.

When a node receives a transaction from another peer, it connects to a Super Node and sends a copy of the transaction hash only to the Super Node, the Super Node will respond with a confirmation of the hash. If a Super Node does not have the transaction in its history, it will request the client user node send the full transaction data to it and will then propogate it to other Super Nodes and other peers.

A client user node will contact a Super Node and request an up-to-date hash of public key balances it has cached.

No Super Nodes
If there are no Super Nodes, the network will immediately elect three, if no-one chooses to be a Super Node then a forced election takes place. If the network splits, when it reconnects with each other it will force half of the Super Nodes on each side to be relected and half to be retained (prevents bot-nets from taking over the Super Nodes by creating a private network and then reconnecting it after modifying the transaction history). If it has split more than once, each split is treated seperately. Ie a split may have to wait a random period of time before becoming reconnected with other peers. This should massively slow down the ability of external parties to take over the network and should prevent the 51% attack and a bot-net attack on the network.
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: RFC - Super Nodes

Post by warmach »

I am intrigued by the idea. The "purists" will complain that it is a form of centralizing the network. But I like it because it gives the peer network a set of trusted nodes. From a business perspective, having a set of trusted nodes to query would be extremely helpful for balance checks and possible transaction lookups.

Couple of ideas to add...

1. Have some incentive to be a super node. I.e. allow one extra coin per genereation.

2. Set a minimum number of super nodes, preferably an odd number.

3. Allow clients to submit a "pending" transaction to the super nodes. A pending transaction is one that has not been yet committed to a block. The super node would then update the balance ledger and prevent a key from spending more timekoins than it has. Once a block is processed, the super node(s) check the block against the pending transactions to verify the transaction was included. Again, the balance is then re-verified.

Those are my quick thoughts....
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: RFC - Super Nodes

Post by warmach »

I think this idea has more merit now that we have a transaction history virus that seems to be re-infecting the network constantly.
Post Reply