Overview
Here we introduce Flink, a zero fee, high speed and secure network that is optimized for enterprise use, but can also be run by individuals on commodity hardware. The system is optimized for fast transactions and is based on a peering algorithm that connects the most influential nodes in a way that minimizes block confirmation latency. The system follows a similar architecture to Nano, which is based on a block lattice. Each account has its own blockchain, which is shown on Figure 1. Here, the account chain can only be updated by the account holder. Since the blockchain of the accounts can be changed independently, we do not need a common block to fill up with transactions and the conrmation latency is greatly reduced.
Figure 1: Block-lattice data structure.
Acount based
Instead of a UTXO transaction design, as used in Bitcoin and many other cryptocurrencies, an account-based design was chosen instead. The advantage of such an approach is simplicity, speed, and usually lower memory requirements. The only disadvantage of this approach is anonymity, which is more difficult to ensure in a DLT design. For this 2nd layer, solutions are planned.
Sending Funds
Because each account blockchain can only be changed by the account holder. A money transfer can only be done with two transactions. First, account A performs a send transaction to account B, then account B requests the transaction by a new receive transaction. This approach is more complicated compared to blockchains like Ethereum and Bitcoin, but the advantages lie in the confirmation process, which can be asynchronous and therefore very scalable.
Figure 2: Node weight assignment from accounts.
Consensus Algorithm
Consensus is achieved using a voting-based consenous algorithm and recently PoV (Proof of Vote) consensus algorithms become well known in the scientific literature. Like PoW, they are Byzantine fault-tolerant, secure and stable. As in ORV (Open Representative Voting), voting weights are determined by the account holder's selection of a representative. The representative is assigned a voting weight relative to the balance of all accounts assigned to him, as shown in the Figure 2. This approach is particularly suitable for feeless systems, since the cost of validating a transaction is low and without risk. With PoW (Proof of Work) the cost is very high and with PoS (Proof of Stake) there is potential risk when staking the currency. Flooding the network directly with votes would lead to message overload and would be slow and ineffcient. To limit the number of votes and messages, some systems choose a middleman who then performs the validation process. While this increases performance, it decreases resilience to a potential attack. Here, we describe a consensus process in which the system is not flooded with votes, but the node receiving the block is tasked with procuring all the necessary vote weights to satisfy the [Wt/2 + 1] < Wc condition, where Wt is the total weight of all the coins and Wc is the weight of the collected votes. First, the node receiving the new block collects the votes of the nodes one by one so that the majority rule is satisfied. Once the votes are collected and the majority rule is satisfied, a voting package is created with the new block and all the votes. This is then sent to all nodes using the network flooding procedure described below, shown on Figure 3.
Figure 3: New block voting process.