Hybrid POWS Works
At first, the mining process would begin in a traditional PoW manner where miners would compete to solve a cryptographic problem. According to this implementation, the blocks being mined do not contain any transactions (they are more like templates instead), so the new blocks that are added to the blockchain will only include a header and the winning miner's reward address. At this moment, the system will switch to PoS. Based on the information contained in this header, a set of random validators is selected to sign the new block. Here, the chance of a validator to be selected would depend on the number of coins he or she holds. The more coins a validator has, the higher the probability of him/her being selected. Once these selected validators have completed the signature of the block, the template will become a complete block. If some of the validators are not available for signing the block, they will be selected to sign the next block and a new set of validators will be selected until the current block gets the correct number of signatures. The transaction fee will be distributed among the miner and the validators who participated in the signature of the block.
FICHAIN TRUSTLESS GOVERNANCE SYSTEM
Fichain supports on-chain governance with delegated voting. Validators’ votes are public and act as default votes for their entire delegation pool, while delegators’ votes are private, and override the default vote provided by their validator.
Achieving consensus across digital currency communities has always been a difficult problem to solve. As we all know, the struggle to upgrade Bitcoin via protocols has been affecting the development of the community over the past two to three years, while the over-centralized governance system adopted by Zcash or similar has certainly deterred active participation across the community. Currently, none of the decision-making processes used in this crypto-economics can preserve the system’s ability to adapt in the face of technical challenges and accommodate the ideological differences among community stakeholders without compromising the integrity of blockchain’s decentralized value proposition
Proposals
Fichain users can propose votes by escrowing a minimum amount of $FIB. They do this by creating a transaction with a CreateProposal description, which consumes some amount of $FIB from the transaction’s balance, and creates a new escrow note with the same amount. The note is escrowed in the sense that it is recorded separately and is not included in the note commitment tree until voting completes.
Stakeholders make and enforce the blockchain’s consensus rules, set a course for future development, and decide how the project’s treasury is used to fund it. Fireal Mobile Chain is similar to Bitcoin’s, but with major aspects of Governance baked into the protocol.
Proposals can either be normal or emergency proposals. In either case, the voting period begins immediately, in the next block after the proposal has been committed to the chain. Normal proposals have a fixed-length voting period, while emergency proposals are accepted as soon as a 2/3 majority of the stake is reached.
To align incentives, block rewards are split between Proof-of-Work (POW) miners, stakeholders and the Decred Treasury, which funds the project:
Because validators provide default votes for their delegation pool, an emergency proposal can in principle be accepted immediately, without any input from delegators. This allows time-critical resolution of emergencies (e.g., deploying an 0day hotfix); the 2/3 majority of the stake required is already sufficient to arbitrarily rewrite the chain state.
Proof of Work: miners play a similar role for Fireal Mobile Chain as they do for Bitcoin, but with Fireal Mobile Chain they only receive 49% of the block reward.
Proof of Stake: Voting is central to Fireal’s governance. FIREAL holders can time-lock (or “stake”) FIREAL to obtain voting tickets. Tickets are randomly called to vote on-chain; this involves both approving the work of PoW miners and voting Yes/No on any open Rule change proposal 51% of the block reward goes to the holders of the tickets that voted in that block.
Proposals can also be withdrawn by their proposer prior to the end of the voting period. This is done by creating a transaction with a WithdrawProposal description, and allows the community to iterate on proposals as the (social) governance process occurs. For instance, a chain upgrade proposal can be withdrawn and re-proposed with a different source hash if a bug is discovered while upgrade voting is underway. Withdrawn proposals cannot be accepted, even if the vote would have passed, but they can be vetoed.
Voting
Stakeholder votes are of the form (Xy,Xn,Xa,Xv), representing the weights for yes, no, abstain, and veto respectively. Most stakeholders would presumably set all but one weight to 0. Stakeholders vote by proving ownership of some amount of bonded stake (their voting power) prior to the beginning of the voting period.
To do this, they create a transaction with a Vote description. This description identifies the validator v and the proposal, proves spend authority over a note recording y dPEN(v), and reveals the note’s nullifier. Finally, it proves vote consistency Y=Xy+Xn+Xa+Xv , produces a new note with y dPEN(v), and includes EncD(xi), an encryption of the vote weights to the validators’ decryption key.
The proof statements in a Vote description establishing spend authority over the note are almost identical to those in a Spend description. However, there are two key differences. First, rather than proving that the note was included in a recent note commitment tree state, it always uses the root of the note commitment tree at the time that voting began, establishing that the note was not created after voting began. Second, rather than checking the note’s nullifier against the global nullifier set and marking it as spent, the nullifier is checked against a snapshot of the nullifier set at the time that voting began (establishing that it was unspent then), as well as against a per-proposal nullifier set (establishing that it has not already been used for voting). In other words, instead of marking that the note has been spent in general, we only mark it as having been spent in the context of voting on a specific proposal.
This change allows multiple proposals to be voted on concurrently, at the cost of linkability. While the same note can be used to vote on multiple proposals, those votes, as well as the subsequent spend of the note, will have the same nullifier and thus be linkable to each other. However, the Vote descriptions are shielded, so an observer only learns that two opaque votes were related to each other.
We suggest that wallets roll over the note the first time it is used for voting by creating a transaction with Vote, Spend, and Output descriptions. This mitigates linkability between Vote and Spend descriptions, and means that votes on any proposals created after the first vote are unlinkable from prior votes.
Counting Votes
At the end of each epoch, validators collect the encrypted votes from each delegation pool, aggregate the encrypted votes into encrypted tallies and decrypt the tallies. These intermediate tallies are revealed, because it is not possible to batch value flows over time intervals longer than one epoch. In practice, this provides a similar dynamic as existing (transparent) on-chain governance schemes, where tallies are public while voting is ongoing.
At the end of the voting period, the per-epoch tallies are summed. For each validator v, the votes for each option are summed to determine the portion of the delegation pool that voted; the validator’s vote acts as the default vote for the rest of the delegation pool. Finally, these per-validator subtotals are multiplied by the voting power adjustment function θv(e) to obtain the final vote totals.
If the vote was not vetoed, the escrowed note from the Proposal description is included in the note commitment tree, so that it can be spent by the proposer. Otherwise, it is not, and the funds are burned.
Last updated