KissChain is a technical proposal for getting rid of tedious issues related to proof-of-stake blockchains, instead of solving them, by following the KISS principle (Keep It Stupid, Simple).
The first issue is the sophisticated but imperfect heuristics used to workaround network inconsistencies inherent to P2P networks, caused by accidental or malicious behaviors from participating nodes. KissChain does not tolerate such inconsistencies, nodes are rewarded for matching the network requirements, or banned. In case of inconsistency the whole network is down, entering cacophony mode, it is then forced to identify with certainty bad nodes, ban them, and starts over minting the chain from where it was before the inconsistency happened. There are no sophisticated tricks and tweaks to continue minting the blockchain despite problems inherent to P2P networks, but a strong all-or-nothing heuristic KISS signal that needs to be dealt with right away with no mercy by the totality of the network.
The second issue is the selection of blockchain forks candidates. KissChain blocks are not broadcast to the network, so there is no block head to choose from. All nodes compute the very same block at the very same time internally, which is made possible by the requirements mentioned in the first point.
In order to participate in minting new blocks and receive transaction fees, nodes need to purchase/register reward-keypair(s) on the blockchain (1). Buying/registering a new reward-key on the blockchain is like buying new rig hardware, the more there is on a node, the more the chances to win new block discovery is high. Where the proof-of-work secures the network by the physical constraint of computing power, here it is secured by the physical constraint of having access to a private key.
For each new block, a simple checksum hash needs to be computed internally by every nodes at the same time, it is made of the previous head block’s nonce appended by the ordered sum of outgoing transactions addresses (2), it must have the same length in bits as the public-reward-keys (e.g. 256 bits), the public-reward-key that is the closest to this hash is the winner (LSH-like nearest neighbor matching). The node that happens to be the winner (who owns the corresponding private-reward-key) has to claim the block by signing the totality of its data (block’s head index on the chain, ordered transactions in full, plus its reward transaction) and broadcast its claim for other nodes to validate and add it to their blockchain’s head. If the block is not claimed, it can be for multiple reasons, blockchain fork (nodes not working on the very same block of transactions because of accidental or malicious cacophony), network latency, or simply the winning node being down. But these cases can be dealt with securely, as explained below.
In order to make sure that every node of the network is working on the very same block of transactions at the very same time, some rigorous synchronization has to be set up, with carrot and stick for the participating nodes. First thing is to prevent transactions from being constantly broadcast. Otherwise, because of propagation delay, the data of the new block would always be in an inconsistent state among the different nodes. As the delay for having data propagated to 99% of a P2P network appears to be about 40 seconds (3), an arbitrary pulse window of 20 seconds is set up for nodes to initiate the broadcast of their transactions (they need to synchronize at startup via NTP), followed by 40 seconds of retention of new transactions (meanwhile these new transactions are being queued in each node, waiting for the next pulse), for letting the time to all the transactions to reach the totality of the network. Therefore, there is one broadcast pulse every minute (20+40 seconds), as well as one new block. If any node do not play the game (wrongdoing, misconfiguration, bad QoS, etc.) that triggers cacophony mode, the network will have to identify and ban them (4) at the next pulse. On the other hand, nodes that provide good synchronization, QoS, etc. will be rewarded by receiving a part of the fees of the transactions that they have initially broadcast. To do so, transactions and their entry node need to identify each other reciprocally. Each transaction identifies the entry node chosen for broadcast, as well as the node signs the transaction (or preferably a whole transactions’ batch in a single network packet). Node identification is done via one of its reward-key(s).
If some transactions are sent too late, not reaching the totality (99.9%) of the network (likely to be initially broadcast around the 55th second, just before the end of the 20+40 seconds pulse, instead of the dedicated initial 20 seconds pulse window, because of intentional cacophony malice or misconfiguration, bad QoS being more unlikely for such a long lag), then the blockchain’s working head will be forked into multiple heads. Therefore, the probability of finding the next block will be divided by the number of different forked heads (proportionally to the respective number of nodes working on each forked head). In an arbitrary case scenario where the blockchain gets forked into 3 equally distributed heads, each representing 33.3% of the nodes, the respective chances to find each of these 3 different forked blocks is divided by 3 (for each forked head block there is a 66.6% chance that the winning reward-key is working on another block, therefore won’t claim it). Thus, after 2 or 3 iteration pulses (or even only one), the entirety of the network will find the block discovery/validation rate dramatically drop, which will trigger a strong heuristic signal for every nodes, that will make them enter cacophony mode. Then, nodes stop emitting transactions, and broadcast the blocks they are working on after the cacophony was detected (and maybe one or two blocks before that, as an uncertainty margin), as well as the signature of the block’s hash by one of their reward-key(s) (5). Then, after few seconds/minutes, all the nodes will have gathered a reference copy of all different versions of blocks being worked on, along with the number of times they have been signed (aka in which proportions a specific version of a block were spread amongst the network). All nodes now have the same complete and accurate snapshot of the total topology and consistency the network, few blocks backward from the blockchain’s head, before the fork happened. No sophisticated heuristics nor heterogeneous statistical guessing need to be made here, nodes can simply and independently compare blocks with the very same algorithm, very same data and find the very same result. Whitelisting every nodes that had their transactions registered on every blocks (meaning they were broadcast on time), banning those that are on some blocks but not other popular ones (6), therefore the network self-heals by purging bad nodes, and resume minting by rolling back to the last block that was minted before the cacophony started.
In the case of a node entering cacophony mode because being in the fringe of the network or out-of-sync (thus not receiving transactions on proper time), other nodes won’t be in cacophony mode, so the node will find itself lonely by not receiving any/enough different block versions (along with their signed hashes), therefore it will know that there is no cacophony, but bad QoS or configuration, this will need to be fixed by resync NTP, reconfigure, change peers, sysadmin intervention, etc. They’ll have to catch up quickly not to miss their chance to win a block discovery.
In the case of a block not being claimed because of the winner node being down or under DDoS attack (7), the network would enter in cacophony mode as well, but figure out that it is consistent, therefore simply blacklisting the winning public-reward-key of the unclaimed block, until it gets unlocked by a dedicated unlock message, signed with its corresponding private-reward-key when the node gets back online.