A Consensus Protocol for e-Democracy
AA Consensus Protocol for e-Democracy
Ouri Poupko Nimrod TalmonAugust 3, 2020
Abstract
Given that Proof-of-Work (PoW) and Proof-of-Stake (PoS) are plu-tocratic, and other common consensus protocols are mostly permission-based, we look for a consensus protocol that will suit the needs of e-Democracy. In particular, what we need is a distributed ledger that willrecord and, to the possible extent, execute the public will. We propose acombination of any given permission-based protocol together with a trustgraph between the nodes, which supplies the required permission for newnodes. As a result, the consensus protocol reaches consensus at every it-eration between a known list of agents and then updates this list betweeniterations. This paper is based on prior work that shows the conditionsunder which a community can grow while maintaining a bounded num-ber of byzantines [9]. It combines a permission-based consensus protocol(such as pBFT [5]) with a community expansion algorithm (such as theone in the prior work) to arrive at a consensus protocol in which the setof agents can change in time, while being sybil-resilient.
In e-Democracy operating via a distributed ledger, we would want the nodes tobe the citizens; i.e., one person - one vote, all the way down to the consensusinfrastructure. We start by noticing that in an e-Democracy based on a dis-tributed ledger there are two types of required consensuses: mining consensus and voting consensus . Mining consensus
To maintain a distributed ledger all participating nodesneed to be in consensus about what is written in the ledger. One key to achievesuch consensus is the separation between what is claimed and the validity of theclaim. In a slightly different view it is the difference between agreeing that Alicevotes for Bob and agreeing that Bob is the chosen leader. We call the ”whatis claimed” consensus - the mining consensus. It is easier to agree on ”what isclaimed” (Alice votes for Bob), especially as cryptography gives Alice a way toprove that this is what she said, by signing this statement with her private key.If one node in the distributed ledger refuses to register her claim, she can easilyturn to another node for the registration process.The threat model for this consensus is the byzantine problem - the problemof confusion between the ranks. This is the problem where some of the honest nodes believe that the majority of the nodes agree one way, and some other honest nodes believe that the majority of the nodes agree another way. If Alice1 a r X i v : . [ c s . S I] J u l s malicious, this can lead to a double spend attack where Alice convinces someof the nodes that there is consensus (over majority of honest nodes) that shevoted for Bob, and in the same time she convinces some other nodes that thereis a consensus (over majority of honest nodes) that she voted for Carol. Thisthreat model is completely resolved (using pBFT [5] for example) if the numberof participants is at least n = 3 f + 1, where f is the number of byzantines. Voting consensus
The consensus over the democratic validity of the claim(or agreeing that Bob is the chosen leader) is what we call the voting consensus.In some social manner, it is harder to achieve, since people tend to disagreeeven on objective facts when it compromises their emotional believes. However,given an agreed voting mechanism (including a reliable registrar) and given anagreed list of voters, it is easy to reach a democratic decision simply by countingmajority of votes.The threat model for this consensus is when the corrupted voters infiltrateenough Sybil voters in order to overcome majority. In this attack everyonewill reach consensus that Carol is the leader, even though majority of genuineidentities (honest and corrupted) voted for Bob. The way to overcome thisthreat, given a known bound on the ratio of Sybils, is to require super-majorityof votes. This method looses liveness (that is, the community is stuck in thecurrent state of affairs) when n < f + 1, however this is a linear degradation.If n = 3 f + 1, then a super-majority of 2 f + 1 should be required, meaning thateven a single genuine identity (together with f sybils) can block any proposal. To reach voting consensus we need to have a trusted list of voters. To have atrusted list of voters we need a trusted registration system with mining consen-sus. It is not clear however how to achieve mining consensus without havingvoting consensus over who is a valid miner. This is the bootstrap problem. Oneway to solve it is by trusting a group of founders to build a small communityand grow the community step by step. This however gives a great deal of powerto the founders in moulding the shape of the community. Our approach in gen-eral is to distribute the decision making power of the group among all membersof the group, in a way that each new member, once joined, will have exactlyhis proportional share in the decisions of the group, including in processes thatstarted before he joined. Specifically in this paper we deal with two basic pro-cesses, 1 - deciding who is in the group, and 2 - logging the group history. Thesetwo functions merge on the specific task of logging the history of who is in thegroup (who joins when).There is a plethora of academic and industry work about consensus pro-tocols. Largely, they are divided into permissionless protocols, like POW andPOS, where anyone can freely join the group of agents running the protocol,and permissioned protocols, where all the agents maintain a list of all partic-ipating agents and the protocol reach consensus explicitly among this group.Known permissionless protocols lean on resources burning or owning that makethem less ideal for democratic governance. POW has a negative impact on theenvironment and POS is plutocratic. Permissioned protocols are simpler, butthey are not distributed enough. This paper describes a consensus protocol thatis semi-permissioned. It starts with a permissioned protocol, but distribute the2ermission authority among all agents. This way it maintains the simplicity ofpermissioned protocols, while gaining the scalability of permissionless protocols.
We refer to Proof-of-Work (POW) and to bitcoin [8] as its first outstandingimplementation, as a starting point to our discussion. proof of work enables thecreation of a distributed ledger which is permissionless. Anyone can join thenetwork that is running the distributed ledger, without affecting the safety ofthe protocol, or even improving the safety, as it grows as the network is furtherdistributed. However it holds grave consequences. In order to achieve safety ina permissionless group, the participants keep competing among themselves insolving the small hash problem, all for the sake of creating an order betweenthem. A computation whose output is completely useless once the order is de-cided. As a result, the bitcoin network of processing units consumes more powerthan an average country [2]. The second problem is that the POW protocol isplutocratic by nature. Richer participants can invest more in hardware, whichmakes them even more stronger and richer participants.Proof-of-Stake (POS) [1] can resolve the electricity power arm racing prob-lem. the order of participation can be determined by the amount of stake theparticipant has in the network. It is also permissionless. Anyone can join andas more participants join the system gets more robust. There is no need forsolving useless problems. Yet, again, by design, POS is plutocratic as well.On the other end of the scale, pBFT [5] is considered the flag protocol forpermissioned distributed ledger. If the group of participants is known, tworounds of verification messages among the group are enough to reach consensus.As the number of messages for each consensus round is of order O ( n ), thisprotocol does not scale well for more then several hundreds, or at most thousandsof participants.There are multiple attempts to create distributed ledger protocols that letanyone join on their own act. Byzcoin [6] uses POW as a Proof-of-Membership,and then uses pBFT for a more efficient consensus among the members. Needto elaborate further.The Proof-of-Identity concept relies on some off-chain mechanism to identifythe participants, which can then prove their identity with cryptographic meansto participate in the distributed ledger network. Though the concept is widelydiscussed, we did not encounter yet a distributed ledger implementation usingit. In Proof-of-Personhood [3] Borge et al. propose to conduct pseudonym par-ties, where group of people physically meet in one place to create cryptographictokens for the participants. Though they discuss scalability briefly by proposingto conduct multiple parties simultaneously in different regions, it is hard to seesuch parties scale to worldwide proportions.Two versions of Ethereum, parity and geth, implement the aura and cliqueconsensus protocols that use Proof-of-Authority. A Proof-of-Authority proto-col [4] uses a chosen set of miners which in turn put their reputation as a stake.The Stellar protocol, Federated byzantine agreement [7], runs the consensusprotocol within quorum slices. Each node marks which quorum slices it trusts(and hence part of). The protocol ensures that consensus is achieved betweenquorums with intersection, but it does not guarantee global consensus.3n 1997, Rubinstein and Kasher propose [10] to look on the question of who isa member of a given society as a social choice question, aggregating the opinionsof the members of the society themselves. It is in the spirit of this approachthat we proposed [9] a method for a sybil resilient community growth. We present our protocol in stages, analyzing each stage and its validity. Insection 3 we start with a simple protocol that only adds new nodes in eachiteration. In section 4 we handle the case of nodes leaving the trust graph. Wefinalize with a complete protocol in section 5, that not only adds and removesnodes, but also carefully merges history between joined communities.
We put forward our two main tools, namely a consensus protocol and a functionthat maintains a sybil-resilient community.
Among permissioned protocols, pBFT is probably the most common referencesolution. We take it as an example for the combined protocol proposed inhere,but generalize it as follows. A permissioned consensus protocol in the contextof this paper has the following characteristics.
Definition 1 ( Consensus ) . A Consensus function is a protocol that adheres tothe following requirements:1. It is a replicated state machine, where each node maintains an internalstate and a set of accepted events. The state machine is deterministic,and all nodes start from the same initial state, therefore if all nodes agreeon the order of incoming events, then all nodes maintain the same stateall the time.2. It is asynchronic in the sense that the network connecting the nodes mayfail to deliver messages, delay them, duplicate them or deliver them outof order. We do assume one relaxation to this requirement, that by someunknown bounded time a message delivered from a proper node to anotherproper node will eventually arrive.3. It maintains safety, that is it satisfies linearizability between operations,similar to a centralized implementation.4. It maintains this list of requirements under the assumption that less than β cp · n nodes are faulty. Formally, the
Consensus function returns either true or false , whether allnodes accept the given event as the next event. This is a slight adaptation tothe more common implementation of a replicated state machine, where an eventstays in queue until it is accepted by the consensus protocol. We do it for theclarity of the protocols to follow. 4 .2 Resilient Community Function In a prior work [9] we identify the conditions under which a community cangrow while maintaining a bound on the number of sybils. For the purpose ofthis work we generalize the following community growth function:
Definition 2 ( ResilientCommunity ) . A ResilientCommunity function is aprotocol that adhere to the following requirements:1. It accepts as input a graph G = ( A, V, E ) where V = H (cid:93) C (cid:93) S (honest,corrupt and sybils respectively) and A ⊂ V is a set of nodes with boundednumber of corrupt and sybils.2. It accepts as input an additional set of nodes A (cid:48) ⊂ V .3. It assumes a bounded number of corrupt nodes in A : | A ∩ C || A | ≤ γ .4. It assumes a bounded number of byzantine in A : | ( A ∩ C ) ∪ ( A ∩ S ) || A | ≤ .5. it outputs true if | ( A ∪ A (cid:48) ) ∩ ( C ∪ S ) || ( A ∪ A (cid:48) ) | ≤ β rc . In plain words, the above function examine the graph as the users add nodesto the community A . The function accepts the new set of nodes, if it canguarantee that the number of byzantine in the community stays below β rc .Our community growth method [9] achieves that by inspecting the connectivityof the graph. We also assume, though it is not articulated above, that thereis always a way to add new nodes to the graph under the above conditions(liveness), so a community that maintains a bound on the number of corruptnodes can continue to grow iteratively. The protocol in this section describes the handling of a new event sent to thereplicated state machine. It starts with running a permissioned consensus pro-tocol that adheres to the requirements in definition 1. This consensus protocoluses the list of nodes of the graph that the replicated state machine stores in itscurrent state as the list of agents that should reach consensus. Once the event isaccepted, the protocol updates the graph structure according to the communitygrowth procedure described in definition 2.It is custom in distributed ledgers, like bitcoin, to differentiate between thecomputer nodes that participate in the consensus protocol (the miners) andthe users that sign the transactions to be logged in the ledger (the clients). Inthe approach given here there is one pool of identities. Both the nodes thatparticipate in the consensus protocol, and the users that sign the transactionsto add edges to the graph, are the same identities. When an edge is createdbetween v and v , it is v and v that sign the transaction, and it is the same v and v that will participate in the consensus protocol, once they enter thecommunity A . 5 rotocol 1 Semi permissioned consensus protocol – event handling init state with an empty graph init logger with an empty log function HandleEvent ( state , event ) G ← state .getGraph() ( A, V, E ) ← G .deconstruct() if IsValid ( event ) then if Consensus ( A , event ) then logger .log ( event ) if event .getType() is CONNECT IN G then edges ← event .getEdges() for all edge ∈ edges do E ← E ∪ { edge } end for end if if event .getType() is EXTEND COMMUNITY then A (cid:48) ← event .getCommunity() C ← CorruptionOracle ( A ∪ A (cid:48) ) C ← ResilientCommunity ( G , A (cid:48) ) if C and C then A ← A ∪ A (cid:48) end if end if end if end if end function Note that the weakness of the
ResilientCommunity protocol is that it dependson an external assumption that the number of corrupt nodes within the com-munity A is bounded. We capture this external assumption by the followingoracle definition. Definition 3 ( CorruptionOracle ) . A CorruptionOracle is a magic functionthat verifies that the corrupt nodes portion in a community A is less than γ . The protocol starts with an empty graph and log. This guarantees that allreplicas start with the same initial state. When the consensus community A is empty we assume that the Consensus function will accept any event it isgiven (if no one objects, then everyone agree). We discuss the bootstrapping ofthe protocol further in subsection 3.3. The first thing the protocol does is toextract the graph structure from its internal state (lines 4,5). Once the validityof the input event is checked, the protocol runs the consensus protocol, and ifsuccessful (all replicas accept the event), it is written to the log (added to theledger). The protocol then reacts to two types of special events. The first (lines9-14) simply adds edges (and possibly new nodes that are connected to them)to the underlying graph G . The second (lines 15-22) is a request to grow theconsensus community A . It is accepted under two conditions, that the oracleverifies that the bound on corrupt identities is not crossed, and that the resilient6ommunity method verifies that the bound on byzantines was not exceeded. Theprotocol is then ready to handle the next event. Under the assumption that honest nodes in the generation of the communitygraph (nodes without edges to sybil nodes) will behave honestly also in theconsensus protocol (will not be faulty), as long as the amount of corrupt nodesis bounded, protocol 1 is a valid consensus protocol. More formally:
Proposition 1 (Honests are honest) . Let γ be the required bound on corruptnodes in definition 2 to achieve a bound β rc on the ratio of byzantine nodes.Assume:1. β rc ≤ β cp .2. A node v ∈ H is not faulty in the consensus protocol.3. CorruptionOracle ensures less than γ corrupt nodes in every iteration ofprotocol 1.Then Protocol 1 maintains the requirements of definition 1.Proof. The call to
ResilientCommunity in line 18, together with assumption3, assure that the ratio of byzantine nodes in the graph is not more than β rc .Assumption 1 assures that the ratio of byzantine nodes is also not more than β cp . It follows from assumption 2 that requirement 4 in definition 1 holds. Allother requirements are indifferent to protocol 1.In the sybil resilient community growth paper [9] we showed that using ver-tex expansion a community can keep the byzantine ratio below β as long as thevertex expansion of the graph is higher than γβ . We also showed that a graphwith vertex expansion Φ v ≥ is quite feasible. It follows from proposition 1that if the community can make sure, that in any given point in time the ratioof corrupt identities in the community is less than , then it can maintain acommunity with less than sybil identities, and over all less than byzan-tines. Under these conditions such a community can safely use protocol 1 as aconsensus protocol within the community.The assumption that honests are honest marks one end of the spectrum.At the other end we can make an opposite assumption that there is no in-tersection between byzantines-to-the-consensus-protocol and byzantines-to-the-resilient-community-protocol. Under this assumption protocol 1 can tolerate upto β cp byzantines of the first type (anarchists) and β rc byzantines of the secondtype (corrupt and sybils). Proposition 2 (Anarchists are not corrupt) . Let γ be the required bound oncorrupt nodes in definition 2 to achieve a bound β rc on the ratio of byzantinenodes. Assume:1. CorruptionOracle ensures less than γ corrupt nodes in every iteration ofprotocol 1.2. An additional procedure AnarchistOracle (not listed in protocol 1) en-sures less than β cp faulty nodes in every iteration of protocol 1. hen Protocol 1 maintains the requirements of definition 1.Proof. As long as some external protocol ensures that less then β cp nodes arefaulty, the Consensus procedure maintains its requirements, regardless of theunderlying graph between the nodes. Protocol 1 therefore maintains the samerequirements as well.
To better understand the interplay between nodes of the consensus protocol andthe clients that commit transactions, consider first the code for the main loopof the protocol.
Protocol 2
Semi permissioned consensus protocol – main loop function MainLoop ( neighbour ) if neighbour is not empty then history ← neighbour .getLog() for all event ∈ history do HandleEvent ( state , event ) end for end if while true do event ← wait for event HandleEvent ( state , event ) end while end function To demonstrate the interplay further, consider the following inefficient, yetexplanatory example.
Step 1:
The first computer A starts running. It initializes with an emptygraph. Step 2: A receives an event to add B and C to its underlying graph G . Step 3: A receives an event to add B and C to the community of trustednodes.Note that at this point we expect that the Consensus procedure, when run-ning the consensus protocol on an empty set of nodes, will return true (if no oneobjects, then everyone agrees). Therefore the first two events are consensuallyaccepted. Secondly, at this point node A is blocked from receiving any furtherevents, as such event will only be accepted by consensus among the set { B, C } ,but nodes B and C are not yet in the network. From A ’s perspective, both B and C are byzantine at this point. Step 4:
Computers B and C start running, initialized with an empty graph. Step 5:
Computers B and C join the network of A by querying it for thehistory of events. B and C then run the history of events locally and reachthe same internal state as A . 8igure 1: Interplay between computer nodes in the network and identity nodesin the graph. Each rectangle is a computer. The graph within represents itsinternal state.From this point all three nodes are synchronized and can run the consensusprotocol together to continue accepting new events. Note that A can participatein this process, though all three nodes, when aiming for consensus, adhere onlyto the messages from B and C , as A is not part of the trust graph. Removing an edge from a trust graph in the above setting is problematic. Whilethe community can add nodes one at a time while maintaining graph connec-tivity, when removing an edge the graph might split in the middle, and it isnot clear which are the nodes that should be removed. A better solution forcommunity growth, with the ability also to shrink back, should probably includenot only the possibility to create edges between nodes that wish to be in thecommunity, but also marking nodes as ’bad’ nodes that should not appear inthe graph. One way to do it might be through creating edges with negativeweights, to capture that node v states that node v should not be in the com-munity. This will require directional graphs, as one can expect pairs of nodes toagree simultaneously to be part of the same community, but it will be strange todemand from v to get the permission of v to repel him from the community.For now we propose the following notion of nodes and edges removal (seeprotocol 3), which will partially allow the community to shrink, as long as ittake precaution to remove edges in a valid order. In short, the protocol acceptsa request to remove a set of nodes from A if the graph remains highly connectedwithout it. Specifically, it tests whether the graph remains resilient (line 6)9nd if the bound on corrupt nodes is maintained (line 7). If the conditions donot hold, then it disregards the request to remove the nodes, and do nothing.Removing edges from the underlying graph G is done unconditionally (lines12-19), as long as the edges are not in A . Protocol 3
Semi permissioned consensus protocol – edge removal . . . function HandleEvent ( state , event ) . . . if event .getType() is REDUCE COMMUNITY then A (cid:48) ← event .getCommunity() C ← ResilientCommunity ( A \ A (cid:48) ) C ← CorruptionOracle ( A \ A (cid:48) ) if C and C then A ← A \ A (cid:48) end if end if if event .getType() is DISCONNECT IN G then edges ← event .getEdges() for all edge ∈ edges do if edge / ∈ A then E ← E \ { edge } end if end for end if . . . end functionObservation 1 (Communities can always shrink) . There is always an order ofevents that will cause a community to shrink all the way to an empty graph.
The observation holds due to the symmetry between protocol 3 and proto-col 1. Both make sure that in every modification of A the community remainsresilient and corruption free before and after the change. In both protocols theaddition and removal of edges outside A is without conditions. These symme-tries ensure that an ‘undo’ path of events is always feasible. That is, growingthe community with a series of growing steps, and then shrinking it back in areverse order of events will safely shrink the community back to its initial state.There are two cases where the protocol should allow to safely remove a nodefrom the community. The first is when a node is discovered to be a sybil node.The second is when a genuine node (honest or corrupt) represent an identity thatceased to exist (either passed away or decided to disconnect from the ledger).It is not clear how to always remove a node, when it is situated in a bottleneckthat may split the community into two loosely connected parts. We assume,however, that it is always possible to remove any individual node by creatingnew connections (edges) between the two parts to increase their connectivity.10 Joining Communities
Up until now new nodes joining the ledger started from scratch, by reading theledger from another node and updating their internal state to be aligned withthe state of the community (see subsection 3.3). In this section we want toconsider the more sophisticated scenario where two communities (two sets ofnodes), each with its own ledger and history, wish to join together to become asingle community. Distributed ledgers are by nature closed environments, as thestate of each replica cannot depend on reading of any external inputs, as thereare no guarantees that all replicas will read the same input. For this reason, onedistributed ledger cannot read the state of another distributed ledger. Nodesparticipating in one distributed ledger all start from the same initial state, andthey all read the same history of events. Two different set of nodes, in twodifferent current state, have no way to reach the same internal state, even iffrom one point onward they will always accept the same events. More thenthat, even if one ledger had a magical way to bring itself up to date with thestate of the second ledger, there is no way to enforce the second ledger (thesecond set of nodes) to do the same. The merge must be symmetric. Yet, aseach ledger is external environment to the second ledger, there is no methodicalway to guarantee symmetric execution.We therefore look at the merging process as two unidirectional processes.Ledger 1 accepts an event that triggers the assimilation of ledger 2, while ina separate and unrelated event, ledger 2 starts the assimilation of ledger 1. Ifthe result is identical (hash value of the state is the same) then the union of allreplicas of both ledgers are in the same state, and are now ready to consumethe next event and reach consensus over it over the joined group of replicas.As discussed, the ledgers cannot resolve if the result is identical by themselvesand only an external intervention (as human intervention) can arbitrate thequestion and conclude that the ledgers are indeed merged. Actually, from theledgers perspective, they are never fully merged, as each ledger will indefinitelymaintain the history before the merge which is different then the history of thesecond ledger.The symmetric assimilation of each other’s state is implementation depen-dent. A ledger of currency might need to modify the addresses of all accounts,to avoid conflict between accounts with the same id in both ledgers. A smartcontract of voting might need to carefully identify the combined community,while merging duplicates, and then join together all gathered votes between thetwo communities. We therefore cannot represent a method for this process inthe scope of this paper, but we do assume that any distributed ledger applica-tion must have a way to correctly merge two partial states into one joined state.The correctness of this merge is not only application dependent, but it mightalso be preference dependent. One community may prefer to treat duplicatecurrency account as separate accounts (accidentally having the same id) whileanother community may prefer to treat duplicate accounts as duplicate accountsof the same agent, and therefore prefer to merge them together into one joinedaccount.
Definition 4 ( MergeStates ) . A MergeState is an implementation specific ex-ternal function that receives two different states and returns a single state that s a safe merge of the two states and symmetric, in the following sense: MergeState(state1,state2)=MergeState(state2,state1)
Protocol 4 combines the previous protocols, with the addition that whenadding nodes to the community of trusted agents, their history is added to theinternal state of the distributed ledger. As explained, this process is unidirec-tional. When community A reads the history of community A (cid:48) and adds it tothe distributed ledger, it does not merge with the nodes of community A (cid:48) , onlycreate a local copy of their history within the ledger of community A . If thesame process will simultaneously occur within the network of community A (cid:48) ,then the two communities will be aligned (in the same internal state) and willbe able to jointly handle any future events. Alternatively, community A (cid:48) canwait silent until community A finishes to update the joined ledger, and thendiscard their ( A (cid:48) ) ledger and join the ledger of A in a similar method to the onepresented in subsection 3.3. Successfully merging two ledgers of two communi-ties is therefore an external process that is controlled by the operators of thissystem and cannot be fully automated. However, Protocol 4 gives the necessaryconditions for such an external process to succeed. We showed a safe way to integrate a consensus protocol with a communitygrowth protocol – based on a trust graph – to conduct and manage a distributedledger within a community where all members are taking part in the ledgermaintaining process. We showed the conditions under which the safety of theconsensus protocol is maintained. For future work it will be of interest to run astochastic simulation of the above protocol.
References [1] Proof of stake faq. https://eth.wiki/en/concepts/proof-of-stake-faqs, 2019.[2] Bitcoin energy consumption index. https://digiconomist.net/bitcoin-energy-consumption, 2018.[3] Maria Borge, Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser,Nicolas Gailly, and Bryan Ford. Proof-of-personhood: Redemocratizingpermissionless cryptocurrencies. In , pages 23–26, 2017.[4] Poa network: public ethereum sidechain with proof of authority consensusby independent validators. https://poa.network/.[5] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance.In
Proceedings of the third symposium on Operating systems design andimplementation , page 173, New Orleans, Louisiana, USA, 1999. USENIXAssociation.[6] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, IsmailKhoffi, Linus Gasser, and Bryan Ford. Enhancing bitcoin security and12 rotocol 4
Semi permissioned consensus protocol – the whole protocol init state with an empty graph and logger with an empty log function HandleEvent ( state , event ) G ← state .getGraph() ( A, V, E ) ← G .deconstruct() if IsValid ( event ) then if Consensus ( A , event ) then logger .log ( event ) if event .getType() is CONNECT IN G then edges ← event .getEdges() for all edge ∈ edges do E ← E ∪ { edge } end for end if if event .getType() is DISCONNECT IN G then edges ← event .getEdges() for all edge ∈ edges do if edge / ∈ A then E ← E \ { edge } end if end for end if if event .getType() is EXTEND COMMUNITY then A (cid:48) ← event .getCommunity() history ← A (cid:48) .getLog() init otherState with an empty state for all event ∈ history do HandleEvent ( otherState , event ) end for joinedState ← MergeState ( state , otherState ) C ← CorruptionOracle ( A ∪ A (cid:48) ) C ← ResilientCommunity ( A ∪ A (cid:48) ) C ← IsValid ( joinedState ) if C and C and C then A ← A ∪ A (cid:48) state ← joinedState end if end if if event .getType() is REDUCE COMMUNITY then A (cid:48) ← event .getCommunity() C ← ResilientCommunity ( A \ A (cid:48) ) C ← CorruptionOracle ( A \ A (cid:48) ) if C and C then A ← A \ A (cid:48) end if end if end if end if end function Proceedingsof the 25th USENIX Conference on Security Symposium
Computer Science Theory and Applications ,pages 359–371. Springer International Publishing, 2019.[10] Ariel Rubinstein and Asa Kasher. On the question ”who is a j?”: A socialchoice approach.