DAPoS: Delegated Asynchronous Proof-of-Stake

ICARUS NETWORK
Search…
ICARUS NETWORK
What is Icarus Network?
Introduction
The ledger
Transactions
DAPoS: Delegated Asynchronous Proof-of-Stake
The ICA Token
Icarus Artifact Network
Actors and Roles
ICA Token Distribution
Private Sale Information
DAPoS: Delegated Asynchronous Proof-of-Stake
One of the most exciting developments out of Icarus is the novel Delegated Asynchronous Proof-of-Stake (DAPoS) consensus algorithm. DAPoS is used to ensure that all network participants maintain an identical world state. DAPoS uses elected Delegates like Dan Larimers DPoS consensus, but operates on the gossiping of individual transactions rather than relying on the sequential distribution of blocks. DAPoS maximizes scalability of transaction throughput by minimizing the Delegates’ co-dependency. Once transaction information is evenly distributed between Delegates, each Delegate autonomously and deterministically accepts the Transaction into their chain and reports the validity of the Transaction. Work done by Delegates is redundant for the Byzantine security of the network.
Decentralization vs Scalability
There is a classic two-of-three trilemma with consensus algorithms: decentralization, scalability, and security. Without sacriﬁcing security, we are left with an inherent tradeoﬀ between decentralization and scalability. DAPoS is inherently more centralized than other consensus algorithms to achieve the level of scalability necessary for enterprise-level applications. Decentralization is not lost, however, since the Delegates are held accountable for their actions by their constituents, the Stakeholders. If the elected powers act maliciously or unreliably, the Stakeholders have the power to replace the incumbents with more trustworthy Delegates. Delegated consensus oﬀers the scalability of a centralized system, but leaves the power of governance decentralized in the hands of the Stakeholders.
To ensure the stability of the Icarus network at launch, Icarus will control all of the initial Delegates. Once we believe the network to be stable and there is suﬃcient voter turnout, we will turn full Delegate control over to community-elected Delegates. The responsibility of Transaction validation will then fall entirely onto the community. Stakeholders are welcome to elect as many Delegates as they deem appropriate, with the consideration of scalability vs decentralization. In comparable delegated systems like Steemit, Stakeholders have elected around 90 Delegates.

Bookkeepers
Icarus utilizes the work of Bookkeepers (sometimes referred to as Learners) to help Stake- holders hold Delegates accountable for their responsibilities, and to help the Delegates distribute information to the Stakeholders eﬃciently. Bookkeepers are responsible for executing the transactions accepted into the ledger by the Delegates. This makes the Delegates themselves a subset of the Bookkeepers. The Bookkeepers also record the states of the Delegates, so unresponsive Delegates can be reported and replaced quickly, all while providing an audit trail of accountability in case of a Delegate fork. Bookkeepers can also help reduce administrative stress from the Delegates, like syncing the chain. Anyone can elect to run a Bookkeeper node to help the network.
Bookkeepers can each be thought of as independent network scanners that end users can query.
Decentralizing the responsibility of reporting on the ledger will eliminate the single point-of-failure stress carried by traditional network scanners. Icarus intends to build an interface with which end users can compare the states of the various Bookkeeper accounts.

Delegate Elections
To ensure everyone using the Icarus network has a say in its governance, the delegated quorum of validator nodes is elected based on stake-based voting. Delegates are the most important actors to the consensus and security of the Icarus network, so they should be chosen carefully. We fully encourage the community to elect Delegates that have shown their commitment and interest in helping the network by participating as a Bookkeeper, announcing their candidacy on a public forum, and revealing their validator machine hardware specs.
Stakeholders are entitled to one vote per full ICA, rounded down. Stakeholders cast their votes as transactions of the Election type. Votes are submitted to the election as a percentage of account balance (σ [a]b). All Stakeholders can vote on the three properties of the Election State (σ [e]): the number of Delegates, the ordered list of preferred Delegates, and the salary of the elected Delegates. Delegate election cycles happen on the hour every hour, where p is the calculated median of all the Election transactions’ Delegate count votes. At the launch of the network, while Icarus controls all of the nodes, Icarus will set the salary rate to 1 ICA/hour and remove our stake in the Delegate salary as the Stakeholder voter turnout increases.
Eliminating Transaction Fees Icarus believes transaction fees seriously inhibit the adoption of a wide variety of applications, so the Icarus network is a decentralized application infrastructure without transaction fees of any kind. Transaction fees exist in most systems to solve for two problems: (1) validator compensation and (2) preventing network spam. Compensating Delegates with time-based salary instead of transaction-based commission disincentivizes price-gouging in times of high network trafﬁc. To prevent the network spam usually inhibited by transaction fees in other systems, Icarus implements stake-based rate-limiting. Stake in the network is weighed as balance ownership of the system’s native currency, the ICA, and bandwidth is eﬃciently monitored and allocated by dynamic fractional reserves .

​
Transactions
The ICA Token
Last modified 1yr ago
Copy link