Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

arxiv.org

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#51

Post by lovelearning »

dgacmu wrote: post #17
lovelearning wrote: post #16

A cited paper's title is "There is more consensus in Egalitarian parliaments." Are terms like "democracy" and "parliament" common terms in distributed computing theory? Or are these intentionally clickbaity/humorous paper titles?

The original Paxos paper was termed "The Part-Time Parliament", and was explained -- I'm serious here -- not as a distributed systems protocol, but as a discussion about how electors on a Greek island could vote despite wandering in and out of the room. (Lamport). It set the stage for a series of papers using that theme. We continued on that theme when picking the title for the EPaxos paper, and these folks built on…

Thank you for explaining!

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#52

Post by kachapopopow »

keiferski wrote: post #11
kachapopopow wrote: post #9

Earlier quoted context omitted.

I think EU federation is pretty good, but I feel very dumbfounded every time dumb decisions that do not benefit member states are made, too much empathy too early I guess.

The EU is pretty good at its intended purpose, which is to tie together European countries in a non-hostile and economically-productive way. But it seems pretty obviously not very good at any real executive action. Which is, again, by design.

not having elected 'idiots' run a highly complex government structure

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#53

Post by chrisweekly »

AnthonyMouse wrote: post #40
chrisweekly wrote: post #37

Earlier quoted context omitted.

> "Making democracy work" should be about training better leaders and getting them into the system. AND fixing the (fundamentally broken) system by reducing the influence of money.

"Reducing the influence of money" is fairly inconsistent with what money is. If anyone can influence anything in any way then having money is going to help them do it. What you need is a way to reduce corruption , i.e. create a structure where diverting public funds to special interests or passing laws that limit competition can be vetoed by someone with the right structural incentives to actually prevent it.

I can't tell if you're being pedantic, or somehow misunderstood my point. To be painfully crystal clear, I meant "reducing the influence of money [ON ELECTIONS, via eg campaign finance reform, and/or related measures designed to correct the structural problems that currently make it corrupt by default]"

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#54

Post by mjevans »

dgacmu wrote: post #35
mjevans wrote: post #30

Earlier quoted context omitted.

I forget the term, it might be Dependency Graph. Hypothetically lets say there's a synchronized quantum every 60 seconds. Order of operations might not matter if transactions within that window do not touch any account referenced by other transactions. However every withdrawal is also a deposit. If Z withdraws from Y, and Y withdraws from X, and X also withdraws from Z there's a related path. Order also matters if an…

Those transfers would be represented as having dependencies on both accounts they touch, and so would be forced to be ordered. Transfer(a, b, $50) And Transfer(b, c, $50) Are conflicting operations. They don't commute because of the possibility that b could overdraft. So the programmer would need to list (a, b) as the dependencies of the first transaction and (b, c) as the second. Doing so would prevent concurrent su…

As I was implying with chains after the toy example, the issue of ordering matters when there's a long sequence of operations that touches many accounts. How easy is it to track all of the buckets touched when for every source there could be a source upstream from any other transaction?

A temporary table could hold that sort of data in a format that makes sense for rolling back the related transactions and then replying them 'on the slow path' (if order matters).

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#55

Post by kingkawn »

Xss3 wrote: post #43
kingkawn wrote: post #22

Earlier quoted context omitted.

Occupy did not fail, it successfully shifted the entire national political conversation of the United States toward considerations of the class warfare being waged by the wealthy against the general population in ways that are continuing to publicly echo in campaigns and policy discussion ever since

The fact they get brought up in such conversations still is proof of that, however i would counter that they failed in their main stated objectives and were dismantled, beaten, even ridiculed in public for it. They became a stark reminder that the rich are far too powerful.

Ridicule is part of the process of folding a series of ideas into mainstream thought

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#56

Post by AuthAuth »

I'm struggling to grasp this paper. The title makes it sound like its talking about democratic processes in the real world but then reading makes me think its a technical paper on computing. Then the comments talk about a mix.

Is anyone able to provide a simple overview of whats being covered here? To me it seems impossible to run a government with no leader and humans having to vote on everything and trust each other. It would be very inefficient not having someone to break ties and make executive choices.

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#57

Post by hinkley »

grogers wrote: post #44
hinkley wrote: post #41

One of the big gaps in Raft is that it’s hard to manage leader election on a heterogenous network. Everyone has or knows a story about the tiny branch office we keep for the CTO’s nephew or that engineer who decided to move to Colorado and quit if he couldn’t work from there, getting elected leader and the whole system limping to a halt. In the case of Raft it would benefit I think from having an instant runoff elect…

If a node thinks it's better suited as leader, it can always force an election immediately for the next term. Things could go badly if you're wrong though

There are variants that have members than can vote but can’t lead, and I believe also ones where there are silent shareholders that are aware of part of the state of the system but don’t vote. Those would be particularly useful for autoscaling groups, where you’re not affecting the quorum count.

I think consul’s sidecar works this way but I’ve ever set it up, only used it.

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#58

Post by keybored »

Nevermark wrote: post #50
keybored wrote: post #34

Earlier quoted context omitted.

Then it has never existed.

It is commonly recognized that Democracy could not exist at a granularity where everyone verifiably gets to contribute to every decision (even if only to abstain), including throughout the resolution of unsettled downstream decisions during implementation of settled upstream decisions. This is very much not a surprise to anyone. For any Democratic system to work, it must include systems of delegation. One can usefull…

Is this democracy according to the math department? This does not conflict with the claim I made.

Re: Making Democracy Work: Fixing and Simplifying Egalitarian Paxos

#59

Post by otrack »

dgacmu wrote: post #19

otrack et al.: Thank you and congratulations! It's gratifying seeing the wheels of research make progress. My appreciation of formal and machine-checked proofs has grown since we wrote the original EPaxos paper; I was delighted at the time at the degree to which Iulian was able to specify the protocol in TLA+, but now in hindsight wish we (or a later student) had made the push to get the recovery part formalized as w…

Thank you, dgacmu! We are currently working on a TLA+ specification with master's students, and we plan to verify it with TLC and Apalache. I discovered that Iulian's TLA+ specification was missing a ballot variable [1] by injecting a trace, because exhaustive exploration was not tractable. Therefore, state-space explosion is likely to become a problem (systems of interest contain 7–9 processes with non‑transitive conflicts). In that case, intermediate abstractions will be necessary, which may naturally lead us to theorem proving.

Once the specification is ready, I'll post about it here. :)

[1] https://arxiv.org/abs/1906.10917

Post reply on HN