Node Implementation - Voting¶
Part of work in progress Living Whitepaper
This page is part of the Living Whitepaper revisions currently underway to replace the original static whitepaper. These efforts include the Protocol Design and Node Implementation sections of the docs, which will cover and expand on details and topics covered in the original whitepaper.
See the bottom of the page for related whitepaper sections and other related details. Some of the sections and headers on this page may be in draft form or just suggestions/framework for later consideration. If you are interested in helping with revisions please connect with us on the
#documentation channel on our Discord server.
When a block is processed, Principal Representatives evaluate whether they can generate a vote for the block (dependent blocks already confirmed, etc.). If they can, they generate the vote and publish to all other PRs they are aware of in addition to
2*sqrt(peers) of non-PR nodes. To reduce the load on PRs nodes, they do not republish incoming votes - only Non-PR nodes republish other votes to
1/2*sqrt(peers) to ensure enough coverage across the rest of the network.
Due to the direct 1:1 relationship between PR nodes, their latency is mostly geographic/network based. For Non-PRs, there is some gossiping via the random distribution, so the number of hops required is what makes up a majority of the latency and the geographic and network latency is less of a factor.
Rep crawler (PRs only)¶
Online weight calculator¶
Active transactions loop¶
Existing whitepaper sections related to this page:
Other content related to this page: