Design of public ledger
Our goal
Define a desired functionality of public ledger
Design a system which achieve public ledger with high reliability
Functionality
Persistence: once an honest player reports a transaction “deep enough” in the ledger, then all other honest players will report it indefinitely whenever they are asked, and at exactly the same position in the ledger
Liveness: as long as a transaction comes from an honest account holder and is provided by the environment to all honest players, then it will be inserted into the honest players’ ledgers, assuming the environment keeps providing it as an input for a sufficient number of rounds
Joseph Y. Halpern Rafael Pass (Cornell University)
Show that the combination of ∆-weak growth and T-consistency is necessary and sufficient to achieve ∆-✷-common knowledge among the honest agents that the contract is in all of their ledgers.
∆-✷-common knowledge of a formula ϕ holds among the honest agents if each honest agent knows that within ∆ all the honest agents will know from that point on that within ∆ all the honest agents will know from that point on . . .ϕ.
Stefan Tai, Jacob Eberhardt and Markus Klems (Technische Universitat Berlin)
Components
Layer1
Sybil control
Fault controllability
Layer2
Perspective to design reliable public ledger
Participants' dynamicity
Decentralization
Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert van Renesse and Emin Gün Sirer
Yujin Kwon∗, Jian Liu†, Minjeong Kim∗, Dawn Song†, Yongdae Kim∗ (∗KAIST †University of California, Berkeley)
Lin William Cong, Zhiguo He (University of Chicago) Jiasun Li
what if the assumptions break?
Censorship resistance
Trade-off
Time to finality, decentralization, overhead
Marko Vukoli´c (IBM Research - Zurich)