Lecture 18: Proof of Stake Longest Chain Lecture 18: Proof of Stake Longest Chain
PoS version of longest-chain protocol in Proof of Stake system, with enhancements like dynamic stake, improved security threshold, and new fork choice rules. Details on determining stake, using latest stake, key grinding attack, and stale stake concept.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Lecture 18: Proof of Stake Longest Chain Lecture 18: Proof of Stake Longest Chain PoS version of longest-chain protocol Improvements Dynamic Stake Improving security threshold closer to 0.5 Reducing NaS New Fork Choice Rules
Previous Lecture Previous Lecture PoS-LC Security replace PoW lottery by PoS lottery transactions not part of lottery time included as part of lottery Static stake defined in the genesis
This lecture This lecture Improvements to PoS-LC Dynamic Stake challenges new fork choice rule Improving security threshold closer to 0.5 Reducing NaS New Fork Choice Rules
Determining Stake Determining Stake PoS-LC proposal lottery Hash(public_key, hash(parent.header), time) < threshold x stake Desired properties random proposer proposal probability is proportional to fraction of stake Stake fixed determined by Genesis
Use Latest Stake Use Latest Stake Current Stake calculate stake based on ledger at parent block ledger may not be stable, but proposal lottery can be verified Key Grinding Attack a large set of public keys kept ready make a transaction to your own public_key set such that succeeds the PoS lottery note that hash(parent.header) is part of PoS lottery hash of block formed has the property that the next block
Key Grinding Attack Key Grinding Attack At time t use public_key_1 (with coin_1 stake) to participate in PoS lottery make transaction of coin_1 from public_key_1 to public_key_2 At time t+1 lottery use public_key_2 (with newly deposited stake) to participate in PoS because current stake of ledger is used, coin_1 is now counted public_key_2 is chosen such that the lottery succeeds Summary: if adversary succeeds at time t, it succeeds at t+1, and for eternity
Stale Stake Stale Stake Idea use stake that is old example: use ledger from block s blocks upstream on the chain any s > 1 can be chosen Intuition previous key grinding attack doesn t succeed hard to influence a block that is not an immediate child prior attack works only if s consecutive blocks can be mined
Delicate Key Grinding Attack Delicate Key Grinding Attack Key grinding attack works only if s consecutive blocks can be mined Refinement mine s blocks in private will take longer than honest miners win the lottery in public but once s blocks in private are mined, then adversary can mine every time going forward release a long sequence of blocks once you overtake the public (honest) chain
Acceptance of Stale Blocks Acceptance of Stale Blocks Delicate Key Grinding Attack release a long sequence of blocks once you overtake the public (honest) chain Solution don t accept sequence of blocks more than s long Problems only online users can implement solution ideally offline users follow protocol and be consistent temporary network splits lead to permanent consistency split
New Fork Choice Rule New Fork Choice Rule Solution don t accept sequence of blocks more than s long works but not acceptable New fork choice rule implements the solution implicitly Start from the Genesis only consider chains s-deep or more (otherwise longest chain rule) adopt the fork that has the earliest time stamp of block s-deep s-truncated longest chain rule
Security of Security of s s- -truncated longest chain rule truncated longest chain rule Error event adversary mines s blocks faster than honest participants Error Probability depends on s; smaller the s, the easier the error event same calculation as Nakamoto s Poisson race Take s large enough decoupled from security of k-deep confirmation rule rule composes with a different faster confirmation method (Prism)
Security Threshold of Security Threshold of PoS PoS PoS-LC Security limited by NaS Race between (honest) chain and (adversarial) NaS tree PoS Lottery Hash(public_key, hash(parent.header), time) < threshold x stake Adversary deviates can grow on all blocks (even Genesis)
NaS Tree and Longest Chain Longest chain NaS Tree G A scalable PoS blockchain in the open setting, Fan and Zhou, 2016
Security of Security of PoS PoS Longest Chain Longest Chain Honest participants grow chain as a Poisson process growth rate linear in time Adversary grows a NaS tree in private longest chain length Security against Private attack or
Improving Security Threshold Improving Security Threshold PoW Ideally tolerate up to 50% adversarial mining power PoS protocol can also tolerate 50% adversarial stake Need to cut down NaS tree growth NaS is potent because PoS lottery can be conducted on any block Hash(public_key, hash(parent.header), time) < threshold x stake
Restricting Restricting NaS NaS Tree Tree Need to cut down NaS tree growth NaS is potent because PoS lottery can be conducted on any block Hash(public_key, hash(parent.header), time) < threshold x stake Idea 1 Only Genesis block used for PoS lottery hash(parent.header) is not part of PoS lottery but part of block data structure and protected via signature New PoS lottery Hash(public_key, hash(Genesis), time) < threshold x stake
Restricted Restricted NaS NaS Tree Tree Idea 1: New PoS lottery Hash(public_key, hash(Genesis), time) < threshold x stake Adverarsary can still conduct NaS Not a tree Many (correlated) chains Similar to PoW but without work conservation Security can tolerate up to 50% adversarial stake Ouroboros: A Provably Secure PoS Blockchain, Kiayis, Russel, David and Olinyikov
