Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DPoS Design #3

Open
sgomzin opened this issue Oct 9, 2019 · 1 comment
Open

DPoS Design #3

sgomzin opened this issue Oct 9, 2019 · 1 comment

Comments

@sgomzin
Copy link
Collaborator

@sgomzin sgomzin commented Oct 9, 2019

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.

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 it is still considered fully decentralized blockchain.

Question: How to improve this mechanism to make it more efficient, secure, and fair.
Please review the proposed design and and leave your comments and suggestions; any ideas and opinions are welcomed and will be reviewed by the community and the team.

Design Concepts in Lyra Docs

@wizd

This comment has been minimized.

Copy link

@wizd wizd commented Oct 11, 2019

I have two questions:

Do the Authorizers be elected dynamically and continuously all the time? If it does, there should be a "tick" to sync all nodes. whats the tick system works like?

A complete transaction needs 4 messages:
1, Sender Req to Authorizers;
2, Authorizers Confirm to Sender;
3, Authorizers Signaling the Receiver;
4, Receiver Confirm to Authorizers;
And Authorizers should communicate to others like 20 nodes. So one successful transaction depends on 44 messages. To achieve high TPS like 10k, An Authorizer node has 440k messages to be processed per second. If one message consists of 1k data, the bandwidth requirement for Authorizer is 4+Gbps. Is that right?

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.