Research PoS implementations

[garious]

Is there any way we can incorporate an existing PoS implementation? Maybe Proof of Authority?

[garious]

No, we probably won't incorporate an existing PoS implementation. Thanks to proof of history, our proof of stake voting ends up being a fairly straightforward generalization of the spending plan contracts. We'll create a new entry type called Block that will point to an Entry ID and include a contract that does a 2/3 multisig vote with an expiration in num_hashes. Once the votes are on the ledger, the entry and all prior may be coalesced. Note that the block the votes are in does not need to be finalized before the entries are coalesced. Signature verification is sufficient.

[garious]

Just to add to my previous comment, if the block that the votes are in needed to be finalized, then you'd never finalize. That also implies that votes need to survive rollback. That means that both leader and verifiers need to cache votes until they are in a block that's been finalized, and that implies that votes are broadcast to all nodes, not just the leader.

[garious]

Problems that need to solved here:

• Proof to anyone interpreting the chain that consensus has been reached
• Survive a leader handoff without leaving space for a timing attack (@aeyakovenko groks this better than I do)
• Calculate bond

So far my comments have only been about the first.

[garious]

Recommended reading from @ericlwilliams:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://arxiv.org/abs/1406.5694

[garious]

DFINITY's threshold relay looks promising and is similar in spirit to Proof of History. It's a VRF that can likely be integrated into our VDF to further simplify consensus.

[bgorlick]

I was going to suggest their threshold relay as well as one option to consider. I'm giving it some thought still.

[bgorlick]

Cardano also recently posted this after tweeting "Proof of Stake - Finally Solved"
Composable Proof-of-Stake Blockchains with Dynamic Availability
Web: https://iohk.io/research/papers/#AQZE2XCV
PDF: https://api.zotero.org/groups/478201/items/PV8BKNA2/file/view?key=Qcjdk4erSuUZ8jvAah59Asef

[garious]

Thanks @bgorlick, I'll be reviewing that closely. Excited to see this on Page 14:

For brevity, whenever in the protocol we say that a party uses the clock to update, τ, ep, and sl we mean
the following step:
Send (clock-read,sidC ) to Gclock; receive the current time τ and update ep := dτ /Re and slot index
sl = τ , accordingly.

[garious]

We're rolling our own PoH-based PoS solution. As it relates to previously mentioned implementations above, it implements a VRF on top of our VDF. It samples the PoH counter every X hashes, and will hash the counter (not the hash) to use as a seed in leader selection. Likewise, we implement dynamic availability with a very similar mechanism. We sample the live nodes from gossip, grab their stakes from the Bank at a given PoH hash, and use that PoH-count-derived seed to randomly create the leader schedule, weighted by stake.

Adding all the dirty details to the consensus RFC is being tracked under #445.