Design Concepts

Ledger

Unlike traditional bitcoin-like blockchain, where all transactions are compiled in blocks in a single blockchain, block lattice (introduced by Nano) is a collection of multiple blockchains. That’s why we also call it blocklist as that’s how exactly the Lyra node database looks like - a big list (collection in nosql database terms) of blocks. Each user account adds transactions to their own blockchain. Such design enables extremely high scalability, instant authorization and settlements, super light clients, and many other features.

Transaction

Each Lyra user maintains its own blockchain called account. Each block contains a single transaction. The network does not maintain a single chain of blocks, which allows to process transactions faster.

Lyra transaction consists of send and receive blocks. The sender's wallet app generates a send block and sends it to the authorizer nodes for authorization. Once send block is authorized by the quorum of authorizers, it is added to the sender account’s blockchain.

When a recipient receives the broadcasted authorized send block, it generates receive block and sends it to the authorizers for authorization. Once authorized, the receive block is added to the recipient account’s blockchain (which is also a part of chain collection).

Comparing to traditional payment processing flow, send block processing is similar to authorization phase, while receive block corresponds to the settlement phase of the payment transaction processing. However, once send block is accepted by the network, Lyra transaction is considered irreversible, even before the receive block is created by the recipient.

Consensus Algorithm

Lyra secures its ledger using proprietary consensus algorithm based on concepts of block lattice, Delegated Proof of Stake, and Byzantine Fault Tolerance. Each concept contributes to security and performance of the system.

Each Lyra transaction is approved by a group of authorizer nodes elected through a voting process. Transaction is considered approved and final when it collects signatures from more than 2⁄3 of the current authorizers. Each transaction is located in its own block, with the blocks chained into the individual account blockchains. Authorizer nodes communicate in most efficient way because they “know” each other. Combination of these factors create highly secure and super fast authorization process.

Delegated Proof-of-Stake

Several successful attempts have been made to eliminate proof-of-work and fully replace it with proof-of-stake. Several “high-ranking” crypto projects (EOS, Tezos, Lisk, BitShares, Nano, Ark) have implemented a delegated proof-of-stake (DPOS), or based their consensus mechanism on DPOS principles (Cardano). In DPOS all participants can vote for a few nodes by delegating their coin balances to the nodes they trust. The more votes (the greater stake balance) the node receives, the higher its position and the possibility of being elected as an authorizing node.

It is preferable that the voting currency has a finite supply and be fairly distributed among the network participants. Therefore, GRFT tokens will be used as the voting currency. Account holder can vote for an authorizer by creating a savings account. Each savings account is linked to particular authorizer. The dividends come from transaction fees which the authorizer earns by participation in the authorization process. Thus, the very process of voting is “masked” for a regular account holder by the process of moving funds to the savings account. This way, all users are motivated to vote as they participate in Lyra rewards sharing, i. e. account holders become stakeholders of the Lyra system.

In traditional centralized payment systems such as Visa or PayPal, the earnings are received by the corporation that owns the network, and some part is distributed to shareholders. In Lyra, all the earnings are shared directly between the authorizers and savings account holders, with no corporate bureaucracy in the middle.

Authorizer Nodes A candidate node that receives more votes than any authorizer node becomes an authorizer, while the authorizer with least votes moves back to the candidates group. Both authorizer and candidate nodes receive rewards (Tx fees).

We suggest limiting the number of authorizer nodes to 21 active authorizers and 21 authorizer candidates (hot backup authorizers).

Note 1: The more authorizers we create the more time and space is required for reaching consensus (getting authorization).

Note 2: More authorizers does not necessarily mean more decentralization. For example, Bitcoin mining is consolidated within a few big miners and yet Bitcoin is still considered a fully decentralized blockchain.

If you have any ideas on how to improve this mechanism to make it more efficient, secure, and fair, please participate in discussion on github and leave your comments and suggestions; any ideas and opinions are welcomed and will be reviewed by the community and the team.