In this document we will explore Lucidity's on-chain Proof-of-Stake consensus called Andromeda. It is meant to be a tool to build Sidechains with Generalized State Transitions.
Andromeda is an on-chain Proof-of-Stake consensus mechanism. Andromeda derives consensus by allowing a set of verifiers to vote on what the consensus should be at any given time.
Voting happens in phases via a commit-reveal mechanism. The on-chain consensus is fully decentralized and does not require central management.
There is a Verifier Registry which can be owned, managed, federated, etc. Within the Verifier Registry, verifiers are able to deposit and set tokens at stake.
Andromeda then connects to the specified Verifier Registry and counts each of the verifier's votes based on the number of tokens they have at stake.
The Andromeda smart contract does not enforce what constitutes as valid consensus, (e.g. it does not extend a consensus round if 2/3rd of the verifiers didn't vote.)
The core purpose of Andromeda is to make it easy and simple to build decentralized sidechain applications. The idea is that an entity may build their sidechain application using any language on any platform, as long as the app can derive its state in a deterministic way.
The point of memorializing a sidechain app's state on the rootchain is to enable Proof-of-Stake plasma sidechains such as those used in Plasma MVP, Plasma Cash, and Lucidity's Plasma Bank.
- Make election independent from commissioner or any other participants.
- Make it easy to use, so verifiers do not need to wonder about closing or opening election.
Election cycle is made of two phases:
- proposal phase - where verifier makes blind proposal
- revealing (and calculating) phase - when verifier reveals its proposal and all revealed data are counted
Verifier provides its blind proposal. Contract save in
Verifier reveals its vote. Contract count (this is PoS, so weight of vote is base on verifier balance) it and save real-time results.
- Time frame for each phase is calculated base on block numbers not timestamp.
- Duration of phases are set when deploy and can't be change
- There is no gap between phases.
- You can miss any phase and nothing bad will happen.
- In case all verifiers miss all two phases, there will be empty block at
- In case verifier proposed but did not reveal in current cycle, this proposal will be ignored, but information about proposal will be present on blockchain.
- There is no way to reveal "old" proposals.
||Only for verifier|
||Only for verifier|
||Only for owner|
|getCurrentElectionCycleBlock||-||uint256 - current block number with reference to whole cycle|
|getFirstCycleBlock||-||uint256 - first block number (blockchain block) of current cycle|
||uint256 - number of votes|
||uint256 - number of addresses|
Contract is designed in a way, that every verifier should be able to use it by executing
reveal() once per cycle. Other data like duration of phases can be easily collected by watching events.
In general, this is how the perfect cycle should looks like:
- Verifier makes proposal
- Verifier calculate block number (base on
LogBlocksPerPhaseevent) and wait until reveal phase starts.
- Verifier reveals its vote.
It is very simple to calculate and figure out, what is the current phase. When you are watching
LogBlocksPerPhase event (or you can directly call for duration value) you already know the value of duration variable:
cycleDuration = (blocksPerPhase * 2 )
Now you khow how many blocks it takes to do whole cycle. You can calculate current phase base on blockchain block number:
currentBlockPhase = blockchain.blockNumber % cycleDuration
currentBlockPhase tells us, what is the current phase of cycle i.e: if each phase will take 5 blocks (whole cycle will be 0…9), current block on blockchain is 5789 then current phase block will be:
5789 % (5 * 2) = 9
means we are at the last block of reveal phase, that is last block for a whole cycle.
The smart contracts are still in development and we are releasing them as open-source to receive feedback on our concepts, ideas, and code. There is still work to be done to add things like delegation, locking of tokens, etc. Please review the code and reach out to us with any comments or questions!
- Project8 Framework: https://github.com/luciditytech/token-incentivized-sidechains
- Plasma Cash: https://github.com/luciditytech/lucidity-plasma-cash
- Plasma MVP: https://github.com/luciditytech/lucidity-plasma