tag:blogger.com,1999:blog-8436330762136344379.post864017000515244012..comments2024-03-26T06:02:24.273-04:00Comments on Metadata: PigPaxos: Devouring the communication bottlenecks in distributed consensusMurathttp://www.blogger.com/profile/07842046940394980130noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-8436330762136344379.post-48688290180034121382020-03-25T18:59:13.433-04:002020-03-25T18:59:13.433-04:00How it is related to zookeper's hierarchical q...How it is related to zookeper's hierarchical quorums?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8436330762136344379.post-52029619769401771312020-03-18T16:42:43.022-04:002020-03-18T16:42:43.022-04:00Why scale a consensus group so large though? Havin...Why scale a consensus group so large though? Having a consensus group with so many members just seems a bit unnecessary. You don't need that much fault tolerance, so rather you can keep the consensus group small and just replicate the updates / state machine snapshots to other members outside of the consensus protocol. The smaller consensus group takes care of the consensus and fault tolerance (3-7 members typically) and you can focus on deploying those members in an optimal way for supporting all the other members outside of the consensus group. For replicating to the members outside of consensus you can use the communication techniques you describe to make it more efficient, so that you don't have hundreds of members receiving updates from a small set of consensus nodes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8436330762136344379.post-69036033807708347542020-03-18T13:54:39.945-04:002020-03-18T13:54:39.945-04:00The following paper, where I'm a co-author, ha...The following paper, where I'm a co-author, has an alternative Paxos consensus that is fully BFT. It looks quite similar to what you are proposing here. Have a look ;)<br /><br /><a href="https://eprint.iacr.org/2017/406.pdf" rel="nofollow">OmniLedger</a>Ineitihttps://www.blogger.com/profile/10090683556259775231noreply@blogger.com