Are you a TCR token TCR holder?

Convert 1:1 to TCR token MYC here.

Need more information?
Read the announcement

Analysing Governance and Voting on Blockchain

James Olsen, Mihir Faujdar

 - 16 min read
Analysing Governance and Voting on Blockchain bannner

Analysing where governance on blockchain, often typified through decentralised autonomous organisations (DAOs), sits in relation to other forms of political and corporate governance is important to constructing the future of decentralised finance (DeFi). Where blockchain represents the future of decentralisation, in contrast to millennia of gradual centralisation, there is a growing realisation that the benefits of these often opposing philosophies are not necessarily mutually exclusive. Vulnerabilities on blockchain networks made so by cryptonomic and cryptographic shortcomings in these said networks’ approaches to classical challenges of voting, consensus, and decision-making have caused at times great damage to a number of entities. What these classical challenges are, and some proposals on how they can be confronted appropriately, are put forth within this article.

Contents:

FAQ
History
  Governance
  Voting
Cryptonomic Governance
Cryptographic Voting
  Introduction to BLS Signatures
  Cryptographic Functions
  Applications
Conclusion

FAQ

What are BLS Signatures?

Boneh-Lynn-Shacham (BLS) signatures are created through the application of a specific use-case of elliptic curves. Given satisfaction of the properties of this use-case, these signatures can be used in such a manner that many signatures can be aggregated together to form a single signature that can be verified easily. This not only reduces the amount of computational storage and network communication required for these signatures, but also allows those with access only to aggregated signatures to calculate how many signatures in total were aggregated. In extension it is also possible to aggregate many public keys from nodes signing a message together into a single public key that can be used to verify the associated aggregated signature. Therefore it allows for great computational efficiencies to use BLS signatures to sign messages across a large network.

Why are BLS Signatures useful?

There are numerous instance where using BLS signatures are useful. Primarily being researched currently for application to the consensus layer of Ethereum, BLS signatures will allow for large networks of nodes to attest to the validity of a block without any need to store each individual public key and signature of each node on-chain. In contrast it would typically be the case that this data would need to be stored in large magnitudes within each block, greatly reducing the possible transaction throughput of any single block. Outside of Ethereum though there are numerous other applications in the field of blockchain. In a generalised application, any network where there is expected to be a significant number of nodes contributing to signing a given piece of data, BLS signatures can reduce the storage and computation requirements of validating these signatures and counting the number of them.

History

Governance

Governance has been a contentious topic of philosophy for millennia. History has demonstrated a tendency for individuals to crave guidance, leadership, and stability. It is not by chance alone that in a few hundred generations there has been a substantial transition from nomadic hunter-gatherer societies to centralised urban bureaucracies. Along this journey it has been observed the crowning of emperors, dictators, presidents, and religious heads, among many other revered and influential figures. Without these aspirations for governance a society often lacks the potential and ability to bring about greater wealth and security - often provided through participation in larger markets. As individuals have come together to form progressively more centralised entities (even more complex societies) there has been an ability to grow secondary and tertiary industries that unlock the opportunities to create more complex and larger market. Working towards and building a collective future is substantially more advantageous from a rational actor perspective when one does not need to worry about factors such as influential groups of malicious actors.

There are some that would rather dismiss the guarantees of a stable society as embodied by the existence of anarchist and libertarian groups among others. Though these individuals usually do not need to worry about influential malicious actors for instance, in part due to continual governance of the society around them. In alignment with these specific groups the majority of individuals do tend to have a limit on the degree of centralisation that is willingly accepted, with dictatorships and monarchies being removed at various points throughout history to be replaced by less centralised entities. French revolutionary history is perhaps an apt example of the often inconclusive debate of the scale of centralisation that society desires. Absolute monarchy was replaced with a revolutionary commune, replacing centralisation with increased civil rights, prior to an abrupt switch back into an empire under Napoleon. Following on from these tumultuous decades there were a further four republics, two kingdoms, and one empire in the next 150 years. France is also not an isolated case in the example of societies shifting loyalty between forms of governance.

If there was a question that was core to the question of what form governance should take upon in a society, it is the question of how to prevent the realisation of the fears of extremes. Extremes of tyranny and anarchy, both proposing severe challenges. Challenges open to exploitation in an incredibly malicious manner. One possible solution would be to gravitate towards a solution that exists somewhere in the middle of these extremes, however, this ignores the possible advantages associated with centralisation and decentralisation. In many ways the answer to the question of the extremes, paradoxically, is the existence of governance that is both centralised and decentralised. One that would provide the infrastructure to facilitate trade, the armies to protect against malicious actors, the public funds to raise the living standards for the population, and the judicial systems to discourage criminal enterprise all while guaranteeing that the decision-making involved is decentralised. How to realise these goals is no obvious path, and the possible advantages and consequences of such goals remain relatively unexplored.

Possible perceptions of the metrics of centralisation and decentralisation. Possible perceptions of the metrics of centralisation and decentralisation.

In many ways blockchain networks facilitate the expression of these questions and goals in a manner that is potentially integral to the operation of multiple elements of society. Being able to access the resources required for survival (i.e. money) is one such element of society; an element that can be restricted by those in control of governance. It is this potential restriction that often facilitates desires for distributed finance (DeFi) and cryptocurrency more generally. However, such systems are often incredibly inefficient, and often unable to continue functioning as intended, without significant investment and guidance from more centralised authorities. This is the paradox faced by many blockchain developers over recent years as there is a push to revolutionise the way traditional finances are done. Intentions to bring about governance, often through decentralised autonomous organisations (DAOs), in some blockchain networks is often an admission of some of the advantages of regulation and stability that society so often desires. The efficiency of a more centralised market, resistant to crashes and some forms of malicious action, can be combined with the benefits of more transparent transactions to offer an improvement upon traditional systems.

It is this attempt to find the ideal implementation of a shared instead of opposing centralisation-decentralisation scale that typifies current discussions of governance on blockchain, as well as governance across society. Throughout the twentieth century the number of monarchies and dictatorships across the world decreased on average (more or less) - in part due to the collapse of the European empires following WW1 and WW2, and in other parts due to increasing political discourse. In their places oligarchies, republics, and democracies have typically arisen (with some notable exceptions). While these systems of governance tended towards adopting greater standards of decentralisation, it can be argued that such changes have not been linear but have been brought about with increased decentralisation and centralisation equally in some instances. To understand how such changes can come about is reliant on perusing the history of voting as explained in the next section. However, in short, these changing forms exist to allow greater proportions of society to be represented in the decision-making process, borrowing some of the same philosophies that DAOs have relied upon.

Voting

Voting has often existed throughout society as a form of distributing the authority of decision-making, though typically it only originally allowed for landed elite males to partake in decision-making. These individuals would often vote in close friends, business associates, and family to the highest positions of authority, limiting any diversity of governance. These votes were often rewarded with disproportionally distributed funding and rights to the landed elite males of said society. While the problems of this approach often appear obvious to many in their current understanding of political history, at the time it was believed that the large magnitude of unlanded individuals and minorities in a society would use their collective voting power to turn otherwise civilised nations (those perceived to have been constructed by the landed elite) into a rule of the commune (or some other form approaching anarchy and absolute decentralisation).

There are strong parallels that can be witnessed in blockchain communities, even on topics such as consensus, where there is disagreement on where voting power should lie and how it should be weighted. It is often conceptualised more recently as the question of ‘governance and economic exposure’ - is it right for two individuals to have equal voting impact on governance if they have disproportionate stakes in the governance of a society? How much weight should be provided for which characteristics of an individual? It is clear that wealth alone is not a sufficient enough indicator of one’s economic exposure unless that wealth is intrinsically linked to the fortunes of a given society (which it rarely is). It has only been recently that commonly held views on the rights of unlanded individuals (and to a lesser extent minorities) for voting have gradually changed in contrast to almost all preceding history.

Demonstration of the cycle of governance and economic exposure between malicious and honest actors. Demonstration of the cycle of governance and economic exposure between malicious and honest actors.

In reaction to the industrial revolution which served as a significant economic and societal adjustment for individuals around the world there was a need to contend with the challenges of poorer working conditions, rising living costs, and increasing consciousness to recognise these changes. These challenges led to the growth of social movements that expanded rights to voting in comparatively short amounts of time (the span of only a few generations). It was along this rapid journey that the ‘tragedy of the commons’ became increasingly focused upon as the embodiment of the prior mentioned concerns of the landed elite. In these situations framed by that of the revolutionary periods of the nineteenth century has come the arrival of this new problem that has also more recently been framed by the need for governance on blockchain networks, how to decentralise the way in which voting is able to influence the governance of a society. In transition from dictatorships and monarchies were proposals for oligarchies, republics, and democracies.

Primarily the question raised by these choices of governance is less so about whose votes can contribute, and more so about how these votes are weighted. The more equally weighted the distribution of voting power is across all individuals the closer the system is in regards to a democracy. The less equally weighted the distribution the closer the system is in regards to an oligarchy. Republics tend to inhabit some sort of placement between the two alternate systems. Equality of the distribution of voting power can be seen in some ways as proportional to the decentralisation of the governance in question, though as alluded to previously there are other factors that can be adjusted in these systems to increase or decrease centralisation in addition (where it is seen that centralisation and decentralisation are not necessarily opposing). Increased decentralisation propagates governance exposure across a network which may not necessarily share equal economic exposure. It is this particular point that has been repeated a number of times that forms a central need of any DAO - to ensure all who own governance tokens (i.e. in positions of power) are relatively exposed to the risks of their governance actions on their own wealth (i.e. loss of resources).

This is especially relevant for DAOs as even those that desire a more ‘democratic’ system of governance, instead of ‘republican’ or ‘oligarchical’, must contend with the challenges of Sybil resistance. Any vulnerabilities to Sybil attacks would mean there is no way to properly ascertain distinct identities between nodes. For instance one may observe a million nodes, but in a system that is vulnerable to these attacks it may be that only one individual (or entity) controls all these nodes. Hence voting with the intention of a ‘democratic’ system requires cryptonomic principles to ensure that no one identity can accrue disproportionate control over governance. To achieve Sybil resistance there are three possible principles that can be applied. Any combination of two or all of the principles are most likely to ensure greater Sybil resistance in a system. It can be noted that the costs of each of these principles increase linearly with the number of nodes being used - therefore it serves as a resistance against a single individual attempting to collect many nodes together to increase their authority on a given network.

Entry Cost

To participate in some system (i.e. vote) there is a requirement to satisfy an initial cost prior to any opportunity for gaining value from said participation.

Existence Cost

To continue to participate in some system (i.e. continue voting) each action of participation (i.e. each occasion of voting) must require the satisfaction of an ongoing cost that is applied on each occasion. This ensures that an individual cannot continue to extract value from participation without paying some cost that is ideally linked to the possible value.

Exit Cost

To cease participation in some system (i.e. to no longer partake in voting) there is a requirement to satisfy a final cost to guarantee that value must have been extracted from participation in a greater magnitude to continued participation to justify exiting.

Cryptonomic Governance

While there are a number of possible mechanisms that can be put into place to ensure that there exists some combination of Sybil resistance principles within a system, this article will take the opportunity to present more specific variations. Such variations will also be put forth within the context of another important cryptonomic constraint of blockchain networks, Byzantine-Fault Tolerance. To put into brief terms, Byzantine-Fault Tolerance is the set of findings and solutions brought forward in confrontation of the Byzantine Generals Problem which asks how network consensus can remain secure assuming malicious actors are interfering with consensus. Of note, once more in brief terms, is that if malicious actors control more than a third of consensus resources (i.e. voting power) they can censor consensus decisions, and if they control more than half of consensus resources they can control consensus decisions. Therefore, considering the implications of these findings can be seen to be pivotal to any voting mechanisms put forth in regards to governance on a blockchain network. More detailed summaries of the implications of Byzantine-Fault Tolerance, specifically in relation to Ethereum but also applicable to other blockchains, can be found in previously published articles.

Initially it would be conceived that entry costs must be considered and combined with analysis of Byzantine-Fault Tolerance. For most systems it is typical to have an entry cost involve the purchase of some governance tokens to be able to participate in the decision-making of some system. While generally this could be done at a fixed cost to satisfy any Sybil resistance requirements (i.e. purchasing the last 10% of tokens is as expensive as purchasing the first 10% of tokens) there is also an opportunity for a dynamic cost for the purposes of Byzantine-Fault Tolerance (i.e. purchasing the last 10% of tokens is more/less expensive than purchasing the first 10% of tokens). In conceptual reasoning this may be beneficial as it would indicate that the more control an individual or entity wants over the decision-making of some system, the exponentially more resources they need to dedicate. Where it can be seen that purchasing no governance tokens would be allowing for the system to remain at a stable state, and purchasing more tokens would allow for decrease in stability (and centralisation) up to a certain point, bringing about such change should require exponentially increasing investment.

It is difficult to define if there exists some rule that may define how these costs should change, and if the increase in change of cost should be exponential, super-exponential, or perhaps even logarithmic or quadratic. Especially the latter applies if the only question is stability of the system at all costs, though if this is expanded to include the need for increases in decentralisation as well as centralisation some other formula might be needed. Some formula could be developed to account for the maximum number of possible controllers of governance at a given moment, making the cost to reach control of half of consensus equivalent to buying out all other shares of the governance tokens. More aptly though it could be considered that reaching each ‘milestone’ of Byzantine-Fault Tolerance requires an equivalent investment.

Illustration of a possible formula for dividing governance tokens into ‘tiered’ exponential prices. Illustration of a possible formula for dividing governance tokens into ‘tiered’ exponential prices.

As stipulated within the diagram tiers can be set up to ensure that the tokens being sold by the issuer have a certain value attached given their genuine value to purchasing nodes. As an example it could be equally expensive to reach a third of all consensus control (to allow for censorship), as it is to reach majority consensus control (to make final decisions) and to reach two-thirds of all consensus control (to prevent the issuer from being able to censor changes). Here it is said that ‘censoring’ changes is to prevent the possibility of a change to the system occurring. In addition any participation in decision-making could incur an existence cost involving each decision having an associated cost to an individual’s cumulative percentage of governance tokens. By keeping a fixed cost per a decision it is noted that even if an individual or entity distributed control over governance across multiple nodes they would need to pay a fixed cost for the votes made by each node. Hence, the rational decision would be to accrue all governance across a single node for each individual to reduce existence costs.

However this would be similar to having a form of ‘regressive’ tax for partaking in decision-making, and it is possible that a ‘progressive’ tax would be fairer on nodes. If proper accommodation has been made for governance tokens having an appropriate exposure to economic risk at a linear relationship, those with less governance tokens will see linearly less value for their decision-making. Therefore, having to pay a fixed cost from this linearly decreasing value could be seen as a significant detriment to holding governance tokens initially if one is not aiming to control as much of the decision-making as possible. Without ‘regressive’ forms of taxation though there is no negative value to distributing governance tokens across as many nodes as possible. Ultimately it would depend from project to project what decision is made. If ensuring Sybil resistance is important enough. Alternatively exit costs could be applied through some creating an inflationary supply of governance tokens (which could also double as an existence cost). As the number of governance tokens available increases, the value of the existing governance tokens as well as their impact on decision-making reduces. Therefore, not continuing to purchase more tokens or withdrawing from one’s hold of any governance tokens would mean that value was lost over the course of partaking in governance on the system unless their governance provided additional value to their economic exposure beyond any cost. This which would typically require acting in an honest manner for the health of the system.

However, another possible problem to decentralised governance is to consider the barriers and challenges to being able to call about regular periods of voting. Assuming that governance tokens are distributed fairly to ensure that decision-making is distributed fairly, it can also be assumed that decision-making must occur in regular atomic intervals. If this is not the case then it is possible to come upon situations where decisions must either be avoided or must be packaged together into batches. Costs associated with voting is directly equivalent to the multiple of how many individuals are involved with voting, and how often voting is called for. The latter cost cannot be avoided (without batching that can ideally be avoided), but the former can be avoided by reducing any expenses involved with aggregating a large number of votes.

Cryptographic Voting

Introduction to BLS Signatures

In the field of cryptography, there is a digital signature scheme known as BLS (Boneh-Lynn-Shacham) that allows the verification of single or multiple distinct signatures corresponding to one or more messages. The scheme depends on a set of parameters preset according to the selected pairing-friendly curve and variant type. There has been fundamental adoption of pairing-friendly curves by different international standards and applications. In particular to applications, the prominent use has been by cryptocurrencies such as Ethereum, ZCash, and Chia Network. Inherently, there are two variant types to base the curve’s parameters: minimal-signature-size and minimal-pubkey-size. The difference between the types is a trade-off made for the size of the signature and public key. Since the premise of this article is governance using BLS signatures, the primary focus will be on the BLS12_381 curve, as adopted by Ethereum. The following are sections for describing the basic functionalities of the scheme.

Cryptographic Functions

Key Pair Generation

Generating a private and public key pair involves using the two functions: KeyGen() and SkToPk(), accordingly. The first function outputs a secret key SK based on the input parameter IKM (input key material). When executed a uniformly random integer existing in the range of 1 ≤ SK < r, where r is the order of subgroups G1 and G2, is outputted. Additionally, it can accept an optional parameter key_info for creating multiple independent keys using the same input. For security, it is essential for IKM to be high in entropy with a minimum length of 32 bytes, being infeasible to obtain from heuristic approaches. The second function SkToPk(), derives the public key PK from the argument SK using scalar multiplication. This process involves adding the point P along the elliptic curve to itself exactly SK times. As depicted below P is the base coordinate on the elliptic curve for the subgroup G1.

AGVB_004.jpg

x = 3685416753713387016781088315183077757961620795782546409894578378688607592378376318836054947676345821548104185464507
y = 1339506544944476473020471379941921221584933875938349620426543736416511423956333506472724655353366534992391756441569

Signing

The Sign() function accepts two parameters, including the owner’s secret key SK and message M. The first step involves deriving the public key PK from the secret key SK. Following this process, concatenation is performed with PK and the message M to enable signature verification with only the knowledge of both. Since the expected format of this concatenation PK || M is in bytes, it is deserialised to a point Q on the elliptic curve. The point Q is scalar multiplied with the secret key SK, and a serialisation occurs on the result for conversion into bytes. The resulting bytes is the signature S of the message M.

Aggregation and Verification

The BLS scheme allows the aggregation of signatures into a single signature for scenarios involving multiple participants. There are multiple mechanisms available for then verifying that this single signature was both the aggregation of n signatures and that each one of the aggregated signatures would have been valid. When multiple participants sign the same message, all the public keys can be aggregated together as a single public key for simplifying verification. The FastAggregateVerify() function achieves this by accepting the following parameters: n public keys, a corresponding aggregate signature and the message. For each public key PK deserialisation to an elliptic curve point is performed and each is summed together to yield a point that is serialised back into a public key. The final result will be a single public key that is submitted to the function CoreVerify() that also takes in the message M and signature S. Inside the CoreVerify() function, there is a number of boolean checks for verification. The final result of this function is a boolean value TRUE or FALSE depending on the success of verification.

Depiction of how multiple points on an elliptic curve can be summed together where, for example, P and Q are two different public keys. Depiction of how multiple points on an elliptic curve can be summed together where, for example, P and Q are two different public keys.

Another type of function AggregateVerify() enables aggregation of both multiple public keys and messages. The process of aggregation is similar to FastAggregateVerify() with the following differences: it performs extra aggregation for the messages and uses CoreAggregateVerify() instead of CoreVerify(). During the aggregation process in AggregateVerify(), there is a concatenation for each public key with the corresponding message appended to the list mprime_i. Subsequently, the CoreAggregateVerify() function accepts the following parameters: public keys, list mprime_i, and signature S. It performs similar boolean checks to CoreVerify() for resulting in a TRUE or FALSE value, depending on the validity.

Applications

Ethereum

This scheme is used in the consensus layer of Ethereum to aggregate the signatures of validators, who cast their vote by signing the proposer’s block. Because a maximum of 131072 validators can vote on a block, it would be inefficient for nodes to individually verify each vote due to the large count. Hence, BLS allows aggregation of all signatures for allowing nodes to efficiently verify participation of validators. The benefit of aggregation can be brought to the application layer of Ethereum with the help of a precompile contract. In Ethereum, a precompiled contract is a native contract hard-coded in the node’s software. Smart contracts deployed on-chain can invoke its functions to mitigate gas costs for certain operations. As of today, nine precompiled contracts are available that mainly provide cryptographic functionalities. To learn more about all these functionalities, please refer once more to previously published articles. Once Ethereum transitions into Proof of Stake, there have been discussions about implementing EIP-2347 for adding BLS-12 precompile in the first post-merge hardfork, named Shanghai. It is important to mention that this consideration is not final and can be changed depending on how developers view its priority compared to other EIPs. However, if BLS-12 precompile gets added to the protocol, it unlocks interesting use cases for the application layer, ranging from large scale signature networks to on-chain light clients for trustless bridging.

Example of 512 nodes being able to attest to the validity of a transaction with one signature. Example of 512 nodes being able to attest to the validity of a transaction with one signature.

Signature Network

Smart contracts contain programmable logic for allowing execution of computation with the limitation of gas limit on blocks. Executing these contracts takes place in a distributed manner by a global network, providing the following benefits: immutability, transparency, and high availability. Incorporating these benefits into traditional governance methods or structures through smart contracts can result in fairness in participation and a reduction in the possibility of corruption. Today, these forms of governance structures exist on Ethereum as Decentralised Autonomous Organisations, short for DAOs. These types of organisations provide on-chain governance according to their purpose. Due to the scalability limitations of Ethereum, from a technological perspective, it can be computationally infeasible to allow any form of governance that deals with a large count of participants. With the support of the BLS-12 precompile in the EVM, smart contracts can address the scalability limitations by allowing aggregation and verification of BLS signatures, messages, and public keys. It would become practical to have on-chain governance on a grander scale. The concept involves having a scalable number of participants for signing a common message. Here, ‘message’ can represent anything, for example, a proposal or multi-sig wallet, and can have consensus based on a majority of signatures from participants equivalent to or greater than a threshold. This concept is applicable in use cases where there is a need for mass-scale social consensus. The construction of such a concept is possible with a smart contract and P2P networking technology. The following sections cover the specifics of the concept in terms of design and operation.

Signature Smart Contract

The signature smart contract is responsible for managing a large set of participants by keeping track of their participation, incentivising correct behaviour and punishing malicious behaviour conducted off-chain. There is a requirement for each participant to deposit a predetermined amount of currency ETH as collateral, earning them eligibility and accountability to partake in voting. By depositing an amount, each participate takes the role of becoming an ‘attestor’. Fundamentally, the functionality and features of the smart contract would include.

  • mapping(address ⇒ index): A public mapping of Ethereum addresses to the indexes of attestors.
  • Attestors[]: A dynamically sized array of attestors where every time a participant successfully places a deposit, there is an additional entry of Attestor, assigned with an index value to be the length of the array.
  • deposit(amount, pubKey): It allows new participants to join the network by depositing a fixed amount of ETH. There is also a requirement for placements of deposits to be made within a time frame. Upon successful deposit, there is a configurable amount of waiting period to become eligible as an attestor. The waiting period increases Sybil resistance against attempts by slashed participants who decide to rejoin the network with the intention of causing disruptions. The deposit can be a one-time transaction in the lifetime of an attestor and reusable in future voting events. Since key-pair generation occurs off-chain, participants also include their public key in the transaction when calling this function.
  • withdrawDeposit(): Attestors are eligible to withdraw their deposit after a period, as long as their history is free of any slashings. This period includes the finalisation time of votes followed by a waiting duration for added security. The period is activated whenever the attestor calls this function.
  • widthdrawRewards(): Those that earn rewards either for correctly submitting the aggregation of votes or attesting to the validity of aggregation can claim incentives after the finalisation and waiting period. The amount of rewards distributed is a configurable parameter that is specified upon deploying the contract.
  • submitVote(signature, message): Attestors can call this function to submit their signature through a transaction instead of broadcasting it to the network. This function is a fallback solution for allowing participants to combat censorship that occurs off-chain, for example, if the selected participant manipulates participation by excluding specific signatures from aggregation. Valid submission of a vote using this method guarantees the attestor’s participation; however, it incurs transaction fees.
  • submitAggregateVote(aggregateSignature, aggregatePubKey, message, bitfield, count): A randomly selected participant is responsible for performing aggregation of signatures and public keys and publishing the result along with the relevant information needed for verification, including message, bitfield, and count. This participant takes the role of ‘Aggregator’ and submits the information in the form of a transaction. The message is a unique 32-byte hash value that the participants commonly sign. The bitfield is an array of bit values, where each element is either 0 or 1, revealing which participants had signed. Lastly, the count is the sum of all the bit values in bitfield, that are 1’s. Once the smart contract verifies the aggregated signature, public key, and message using the BLS-12 precompile, it will store the bitfeld and count for future verification by committees. This function also ensures that only the assigned aggregator can submit the vote by checking the transaction’s origin.
  • attest(signature): After the aggregator successfully submits the aggregation, the contract assigns 500 attestors to a committee using on-chain randomness. After the merge, it will be possible for the EVM to allow smart contracts to have randomness using the RANDAO opcode. Each committee member is responsible for validating the aggregation submission by the aggregator, conducting the verification off-chain. If the information, such as aggregateSignature, aggregatePubKey, message, bitfield and count, are correct, they are required to submit a transaction within a configurable amount of timeframe by calling this function and including their signature. Otherwise, if the information is invalid, there is no submission of transaction.
  • confirm(): Once the period for submitting attestations is over, any participant, an attestor or aggregator, can call this function to initialise the confirmation process. Upon calling this function, the contract will check if the aggregator’s submission has received enough attestations from the committee by comparing it to a configurable threshold. If the number of attestations is equal to or greater than the threshold, the contract accepts the aggregation as valid and allocates rewards to the aggregator and members of the committee that correctly attested. Committee members that failed to attest correctly are penalised by having their deposit cleared.

P2P Network

Additionally, participants are required to run a client for maintaining peer connections and broadcasting messages off-chain. The client also has access to Ethereum’s state and the ability to send transactions to the Ethereum network. When attestors broadcast their signatures to the P2P network, the aggregator will collect as many signatures as possible. During this process, the aggregator will check whether each signature is distinct and originates from the public key of a participant that is an attestor. Once there are a sufficient number of signatures, the aggregator performs an aggregation of signatures and the corresponding public keys. It also generates a collection of bit values, where each value is mapped to the index of attestor whose signature was aggregated. This method of submitting signatures is an efficient approach for allowing a large number of signatures to be verified on-chain without adding overhead on Ethereum. If each participant submitted a transaction on-chain, it would lead to transaction flooding in the mempool and, as result, surge the gas costs, if the number of participants was high in count, for example, above 100000.

Conclusion

Balancing between centralisation and decentralisation in governance of, and voting in, blockchain networks is in many regards an adaptation of the problems that have confronted political and corporate systems throughout history. While there has been a gradual tendency to transition towards centralisation given the benefits to a society that can be yielded through a more organised and cohesive unit, blockchain represents an opposition to this movement. However, it is a simplification to say that blockchain does, or should, aim for decentralisation in contrast to centralisation. Rather paradoxically it appears the case that an argument can be made for simultaneous increases in centralisation and decentralisation within the same system. Adopting such an approach can allow for great developments in the fields of governance and voting; an approach that can be provided through cryptonomic and cryptographic protocols.

Swaps logo

More Leverage. Less Overhead