Zero-Knowledge Proof-of-Identity: Sybil-Resistant, Anonymous Authentication on Permissionless Blockchains and Incentive Compatible, Strictly Dominant Cryptocurrencies

05/22/2019
by   David Cerezo Sánchez, et al.
Calctopia Limited
0

Zero-Knowledge Proof-of-Identity from trusted public certificates (e.g., national identity cards and/or ePassports; eSIM) is introduced here to permissionless blockchains in order to remove the inefficiencies of Sybil-resistant mechanisms such as Proof-of-Work (i.e., high energy and environmental costs) and Proof-of-Stake (i.e., capital hoarding and lower transaction volume). The proposed solution effectively limits the number of mining nodes a single individual would be able to run while keeping membership open to everyone, circumventing the impossibility of full decentralization and the blockchain scalability trilemma when instantiated on a blockchain with a consensus protocol based on the cryptographic random selection of nodes. Resistance to collusion is also considered. Solving one of the most pressing problems in blockchains, a zk-PoI cryptocurrency is proved to have the following advantageous properties: - an incentive-compatible protocol for the issuing of cryptocurrency rewards based on a unique Nash equilibrium - strict domination of mining over all other PoW/PoS cryptocurrencies, thus the zk-PoI cryptocurrency becoming the preferred choice by miners is proved to be a Nash equilibrium and the Evolutionarily Stable Strategy - PoW/PoS cryptocurrencies are condemned to pay the Price of Crypto-Anarchy, redeemed by the optimal efficiency of zk-PoI as it implements the social optimum - the circulation of a zk-PoI cryptocurrency Pareto dominates other PoW/PoS cryptocurrencies - the network effects arising from the social networks inherent to national identity cards and ePassports dominate PoW/PoS cryptocurrencies - the lower costs of its infrastructure imply the existence of a unique equilibrium where it dominates other forms of payment

READ FULL TEXT VIEW PDF

Authors

02/17/2022

Insightful Mining Equilibria

The selfish mining attack, arguably the most famous game-theoretic attac...
05/21/2021

Pravuil: Global Consensus for a United World

Pravuil is a robust, secure, and scalable consensus protocol for a permi...
11/08/2019

On Incentive Compatible Role-based Reward Distribution in Algorand

Algorand is a recent, open-source public or permissionless blockchain sy...
01/23/2018

Decentralized Caching for Content Delivery Based on Blockchain: A Game Theoretic Perspective

Blockchains enables tamper-proof, ordered logging for transactional data...
12/04/2019

SquirRL: Automating Attack Discovery on Blockchain Incentive Mechanisms with Deep Reinforcement Learning

Incentive mechanisms are central to the functionality of permissionless ...
01/10/2019

Incentive-based integration of useful work into blockchains

Blockchains have recently gained popularity thanks to their ability to r...
03/20/2020

Blockchain Governance: An Overview and Prediction of Optimal Strategies using Nash Equilibrium

Blockchain governance is a subject of ongoing research and an interdisci...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Sybil-resistance for permissionless consensus comes at a big price since it needs to waste computation using Proof-of-Work (PoW), in addition to assuming that a majority of the participants must be honest. In contrast, permissioned consensus is able to overcome these issues assuming the existence of a Public-Key Infrastructure[DS83, DLS88, CL99] otherwise it would be vulnerable to Sybil attacks[Dou02]: indeed, it has been recently proved[PS18] that consensus without authentication is impossible without using Proof-of-Work. Proof-of-Stake, the alternative to PoW, is economically inefficient because participants must keep capital at stake which incentivise coin hoarding and ultimately leads to lower transaction volume.

Another major challenge in permissionless blockchains is scalability, both in number of participants and total transaction volume. Blockchains based on Proof-of-Work are impossible to scale because they impose a winner-take-all contest between rent-seeking miners who waste enormous amounts of resources, and their proposed replacements based on Proof-of-Stake don’t exhibit the high decentralization desired for permissionless blockchains.

The solution proposed in this paper prevents Sybil attacks without resorting to Proof-of-Work and/or Proof-of-Stake on permissionless blockchains while additionally guaranteeing anonymous identity verification: towards this goal, zero-knowledge proofs of trusted PKI certificates (i.e., national identity cards and/or ePassports) are used to limit the number of mining nodes that a single individual could run; alternatively, a more efficient solution based on mutual attestation is proposed and demonstrated practical 4.2.5. Counterintuitively, the blockchain would still be permissionless even though using government IDs because the term “permissionless” literally means “without requiring permission” (i.e., to access, to join, …) and governments would not be authorizing access to the blockchain; moreover, the goal is to be open to all countries of the world 4.3, thus its openness is indistinguishable from PoW/PoS blockchains (i.e., the union of all possible national blockchains equals a permissionless, open and global blockchain). Coincidently, the latest regulations [otCCAC18] point to the obligation to verify and use real-world identities on blockchains, and the banning of contaminant cryptocurrency mining[BG19, DC19].

Blockchain research has focused on better consensus algorithms obviating that incentives are a central aspect of permissionless blockchains and that better incentive mechanisms would improve the adoption of blockchains much more that scalability improvements. To bridge this gap, new proofs are introduced to demonstrate that mining a new cryptocurrency based on Zero-Knowledge Proof-of-Identity would strictly dominate previous PoW/PoS cryptocurrencies, thus replacing them is proved to be a Nash equilibrium; additionally, the circulation of the proposed cryptocurrency would Pareto dominate other cryptocurrencies. Furthermore, thanks to the network effects arising from the network of users of trusted public certificates, the proposed cryptocurrency could become dominant over previous cryptocurrencies and the lower costs of its infrastructure imply the existence of a unique equilibrium where it dominates other forms of payment.

1.1 Contributions

The main and novel contributions are:

  • The use of anonymous credentials in permissionless blockchains in order to prevent Sybil attacks 4: previous works[KITD17, DYSZ17] considered the use of PKI infrastructures in blockchains (i.e., permissioned ledgers) but without transforming them into anonymous credentials in order to obtain the equivalent of a permissionless blockchain. Other works have considered anonymous credentials on blockchains[GGM13, SABBD18, CDD17, FMMO18, Res18], but requiring the issuance of new credentials and not reusing previously existing ones: verifying real-world identities and issuing their corresponding digital certificates is the most expensive part of any real-world deployment.

    • The practical implementation and its perfomance evaluation 4.2.5 for national identity cards and ePassports.

  • Circumventing the impossibility of full decentralization 4.4 and the blockchain scalability trilemma.

  • A protocol for an incentive-compatible cryptocurrency 1: previous blockchains mint cryptocurrencies tied to the process of reaching a consensus on the order of the transactions, but the game-theoretic properties of this mechanism is neither clear nor explicit.

  • A proof that mining the proposed cryptocurrency is a dominant strategy over other PoW/PoS blockchains and a Nash equilibrium over previous cryptocurrencies 5.2.1, in addition to an Evolutionary Stable Strategy 5.2.2.

  • The insight that the optimal efficiency of zk-PoI resides in that it’s implementing the social optimum, unlike PoW/PoS cryptocurrencies that have to pay the Price of (Crypto-)Anarchy 5.2.3.

  • A proof that the circulation of the proposed zk-PoI cryptocurrency Pareto dominates other PoW/PoS cryptocurrencies 5.2.4.

  • A proof that the proposed cryptocurrency could become dominant over previous ones due to stronger network effects and the lack of acceptance of previous cryptocurrencies as a medium of payment 5.2.5.

  • Finally, the lower costs of its infrastructure imply the existence of a unique equilibrium where it dominates other forms of payment 5.2.6.

2 Related Literature

This section discusses how the present paper is significantly better and more innovative than previous approaches in order to fulfill the objective of providing a Sybil-resistant and permissionless blockchain with anonymous transaction processing nodes (i.e., miners). Moreover, it’s considerably cheaper than other approaches[SABBD18, BKKJ17] that would require the re-identification and issuing of new identities to the global population because the current proposal relies on the previously issued credentials of electronic national identity cards (3.5 billion issued at the time of publication) and electronic passports (1 billion issued at the time of publication).

Proof of Space[DFKP13, ABFG13] reduces the energy costs of Proof-of-Work but it’s not economically efficient. Proof of Authority[Woo15](PoA) maintains a public list of previously authorised nodes: the identities are not anonymised and the blockchain is not open to everyone (i.e., the blockchain is permissioned). Proof of Personhood[BKKJ17](PoP) can be understood as an improvement over Proof of Authority in that identities are anonymised, but the parties/gatherings used to anonymise and incorporate identities into the blockchain don’t scale to national/international populations and could compromise Sybil resistance because it’s trivial to get multiple identities by using different disguises on different parties/gatherings (i.e., they need to be validated simultaneously and without disguises): however, the present paper produces Sybil-resistant, anonymised identities on a global scale for a permissionless blockchain. Moreover, Proof of Personhood[BKKJ17] is endogenizing all the costly process of credential verification and issuing: by contrast, Zero-Knowledge Proof of Identity is exogenizing/outsourcing this costly process to governments, thus making the entire blockchain system cheaper. More recently, Private Proof-of-Stake protocols[GOT18, KKKZ18](PPoS) achieve anonymity, but the economic inefficiencies of staking capital still remain and the identities have no relation to the real world.

Pseudo-anonymous signatures[BHK18] for identity documents provide an interesting technical solution to the problem of anonymous authentication using identity documents. However, the proposed schemes present a number of shortcomings that discourage their use in the present setting: some schemes are closely tied to particular countries (i.e., the German Identity Card[BDFK12, fIS16, KHK18]), thus non-general purpose enough to include any country in the world, or flexible to adapt to future changes; they require interaction with an issuer during card initialization; they feature protocols for deanonymisation and revocation, not desired in the setting considered in this paper; the initial German scheme[fIS16] could easily be subverted[KHK16] because the formalization of pseudo-anonymous signatures is still incipient[KHK], and improvements are being worked out[BCLP14, Klu16, KHK18].

Anonymous credentials, first envisioned by David Chaum[Cha83], and first fully realised by Camenisch and Lysyanskaya[CL01] with follow-up work improving its security/performance[BCKL09, CHL05, CG10, CL04, BL12], are a centrally important building block in e-cash. The use of anonymous credentials to protect against Sybil attacks[Dou02] has already been proposed in previous works[AKMP08, BCKL07] although with different cryptographic techniques and for different goals. The main problem with anonymous credentials is that they require a first identification step to an issuing party[Res18] and that would compromise anonymity. This problem is shared with other schemes for pseudoanymization: for example, Bitnym[FWB15] requires that a Trusted Third Party must check the real identity of a user before allowing the creation of a bounded number of valid genesis pseudonyms. Decentralized Anonymous Credentials[GGM13] was first to show how to decentralise the issuance of anonymous credentials and integrate them within a blockchain (i.e., Bitcoin), but they do not re-use previously existing credentials and they still rely on Proof-of-Work for Sybil-resistance. Decentralized Blacklistable Anonymous Credentials with Reputation[YAXY17] introduce blacklistable reputation on blockchains, but users must also publish their real-world identity (i.e., non-anonymous). QuisQuis[FMMO18] introduces the novel primitive of updatable public keys in order to provide anonymous transactions in cryptocurrencies, but it doesn’t consider their Sybil-resistance. DarkID[Arn18] is a practical implementation of an anonymous decentralised identification system, but requires non-anonymous pre-authentication and doesn’t consider Sybil-resistance. A previous work[AABM17] on secure identity registration on distributed ledgers achieved anonymity from a credential issuer, but the pre-authentication is non-anonymous, it doesn’t consider Sybil-resistance and it doesn’t re-use real-world cryptographic credentials. Recently, anonymous credentials on standard smart cards have been proved practical[CDDH19], but in a different setting where the credential issuer and the verifier are the same entity.

Previous works have also considered anonymous PKIs: for example, generating pseudonyms[RPKC07] using a Certificate Authority and a separate Private Certificate Authority; however, this architecture is not coherent for a permissionless blockchain because both certificate authorities would be open to everyone and that would allow the easy linking of anonymous identities. Another recent proposal for a decentralised PKI based on a blockchain[PSRK18] does not provide anonymity, although it improves the work on cryptographic accumulators on blockchains started by Certcoin[FVY14, RY15]; another proposals introduce privacy-aware PKIs on blockchains[AG16, OP19], but they are not Sybil-resistant and do not re-use certificates from other CAs. Previously, BitNym[FWB15] introduced Sybil-resistant pseudonyms to Bitcoin, but a Trusted-Third Party must check the real identities of users before allowing the creation of a bounded number of valid genesis pseudonyms. ChainAnchor[HSP16] wasn’t Sybil-resistant and used Direct Anonymous Attestation just for anonymous authentication, but not for mutual authentication: it worked on the permissioned model, explicitly not permissionless, and the GroupOwner initially knew the true identity of members; moreover, the Permissions Issuer is supposed not to collude with the Verifier, although it has reading access to the identity database. ClaimChain[KITD17] improves the decentralised distribution of public keys in a privacy-preserving way with non-equivocation properties, but it doesn’t consider their Sybil-resistance because it’s more focused on e-mail communications. Blind Certificate Authorities[WAPaas18, WPasR16] can simultaneously validate an identity and prove a certificate binding a public key to it, without ever learning the identity, which sounds perfect for the required scenario except that it requires 3 parties and it’s impossible to achieve in the 2-party setting; moreover, it doesn’t consider Sybil-resistance.

Other approaches to anonymous identity include: Lightweight Anonymous Subscription with Efficient Revocation[KLL18], although it doesn’t consider the real-world identity of users because it’s focused on the host and its Trusted Platform Module; One Time Anonymous Certificates[AC10] extends the X.509 standard to support anonymity through group signatures and anonymous credentials, although it doesn’t consider Sybil-resistance and their group signatures require that users hold two group secret keys, a requisite that is not allowed in the current scenario because the user is not trusted to store them on the national identity card (for the very same reasons, Linkable Ring Signatures[LWW04] and Linkable Message Tagging[GP14] are not allowed as cryptographic tools whilst group signatures and Deniable Anonymous Group Authentication[SPW14] would require a non-allowed setup phase). Opaak[MSCS12] provides anonymous identities with Sybil-resistance based on the scarcity of mobile phone numbers: however, users must register by receiving an SMS message (i.e., the Anonymous Identity Provider knows the real identity of participants). Oblivious PRFs[JKR18] are not useful in the permissionless blockchains because the secret key of the OPRF would be known by everyone, and the forward secrecy of the scheme that would provide security even if the secret key is known would not be of any use because the object identifiers ObjID would be easily predictable (i.e., derived from national identifiers). SPARTA[BBF07] provides pseudonyms through a distributed third-party-based infrastructure; however, it requires non-anonymous pre-registration. UnlimitID[IHD16] provides anonymity to OAuth/OpenID protocols, although users must create keypairs and keep state between and within sessions, a requisite that is not allowed in the current scenario. Another proposal for anonymous pseudonyms with one Trusted-Third Party[YL] requires a division of roles between the TTP and the server that is not coherent in a permissionless blockchain. With Self-Certified Sybil-free Pseudonyms[MKAP08, AKMP08], the user must keep state (i.e., dispenser D) generated by the issuer during enrollment and the Sybil-free identification is based on unique featurs of the devices, not on the user identity. Another anonymous authentication using smart cards[TLW13] is only anonymous from an eavesdropping adversary, not from the authentication server itself. TATA provides a novel way to achieve Sybil-resistant anonymous authentication: members of an induction group must interact and keep a list of who has already been given a pseudonym; therefore, a list of participants could be collected, but they can’t be linked to their real-world identities; it’s not clear how to bootstrap the initial set of trusted users to get them to blindly sign each other’s certificates.

Self-sovereign identity solutions usually rely on identities from social networks, but their Sybil-resistance is very questionable because almost half of their accounts could be fake[Nic19]: in spite of this, SybilQuorum[Dan18] proposes the use of social network analysis techniques to improve their Sybil-resistance; other research projects consider privacy-preserving cryptographic credentials from federated online identities[MJW14].

Regarding the game-theoretic aspects, most papers focus on attacking only one cryptocurrency (e.g., selfish mining[ES13], miner’s dilemma[Eya14], fork after withholding[KKS17]). For a recent survey of these topics, see[AH19]. Exceptionally, “Game of Coins[SKT18] considers the competition between multiple cryptocurrencies: a manipulative miner alters coin rewards in order to move miners to other cryptocurrencies of his own interest (with a fixed cost and a finite number of steps). However, in this paper, it’s the cryptocurrency issuer who changes the rewards in order to attract miners from other cryptocurrencies by producing the most efficient cryptocurrency to mine.

PoW PoSpace PoS PPoS PoA PoP zk-PoI
(Pseudo)-Anonymity
Energy-Efficient
Economically Efficient
Permissionless ✓(*)
Table 1: Comparison of different Sybil-resistant mechanisms.
(*) Only if open to everyone, with no selective pre-invitation and no right to exclude.

3 Building Blocks

3.1 Consensus based on the Cryptographic Random Selection of Transaction Processing Nodes

The new family of consensus algorithms based on the cryptographically random selection of transaction processing nodes[PS16, DPS16, KKJG17, GHM17, HMW18] is characterised by:

Consensus algorithm Random selection method Sybil resistance
OmniLedger PVSS + collective BLS signatures [SJK16, KKJG17, BDN18] PoW/PoS
RapidChain Performance improvements over OmniLedger[ZMR18] PoS
Algorand Cryptographic sortition by a unique digital signature PoS
Dfinity BLS threshold signature scheme[BLS01] PoS
Snow White Extract public keys based on the amount of currency owned PoS

  • Transaction processing workers/nodes are randomly selected from a larger group: in the case of Dfinity[HMW18], an unbiasable, unpredictable verifiable random function (VRF) based on the BLS threshold signature scheme[BLS01] with the properties of uniqueness and non-interactivity; in the case of OmniLedger[KKJG17], the original proposal used a collective Schnorr threshold signature scheme[STV15, SJK16, KKJG17], although it has been updated to collective BLS signatures[BDN18]; in the case of Algorand, secure cryptographic sortition is generated using an elliptic curve-based verifiable random function (ECVRF-ED25519-SHA512-Elligator2[GRPV19]); in the case of Snow White, cryptographic committee reconfiguration is done by extracting public keys from the blockchain based on the amount of currency owned. For a detailed comparison of random beacon protocols, see [SJSW18].

  • Regular time intervals (also named epochs or rounds) on which randomly selected workers/nodes process the transactions.

  • Faster transaction confirmation and finality.

  • High scalability.

  • Decoupling Sybil-resistance from the consensus mechanism (PoW/PoS is about membership, not consensus).

  • PoW/PoS to protect against Sybil attacks: however, the present paper proposes the use of Zero-Knowledge Proof-of-Identity (i.e., more economically[Dia19] and environmentally efficient[KT18]).

3.2 X.509 Public Key Infrastructure

X.509 is an ITU-T standard[Uni18b] defining the format of public key certificates, itself based on the ASN.1 standard[Uni18a]: these certificates underpin most implementations of public key cryptography, including SSL/TLS and smartcards. An X.509v3 certificate has the following structure:

Certificate Version Number Serial Number Signature Algorithm ID Issuer Name Validity Period: Not Before Not After Subject Name Subject Public Key Info Public Key Algorithm Subject Public Key Issuer Unique Identifier (optional) Subject Unique Identifier (optional) Extensions (optional): Key Usage (optional) Authority Information Access (optional) Certificate Policies (optional) Basic Constraints (optional) CRL Distribution Points (optional) Subject Alternative Name (optional) Extended Key Usage (optional) Subject Key Identifier (optional) Authority Key Identifier (optional) Certificate Signature Algorithm Certificate Signature

Certificates are signed creating a certificate chain: the root certificate of an organization is a self-signed certificate that signs intermediate certificates that themselves are used to sign end-entities certificates. To obtain a signed certificate, the entity creates a key pair and signs a Certificate Signing Request (CSR) with the private key: the CSR contains the applicant’s public key that is used to verify the signature of the CSR and a unique Distinguished Name within the organization. Then, one of the intermediate certificate authorities issues a certificate binding a public key to the requested Distinguished Name and that also contains information identifying the certificate authority that vouches for this binding.

The certificate validation chain algorithm checks the validity of an end-entity certificate following the next steps:

  1. The certificates are correct regarding the ASN.1 grammar of X.509 certificates.

  2. The certificates are within their validity periods (i.e., non-expired).

  3. If access to a Certificate Revocation List is granted, the algorithm checks that none of the certificates is included (i.e., the certificate has not been revoked).

  4. The certificate chain is traversed checking that:

    1. The issuer matches the subject of the next certificate in the chain.

    2. The signature is valid with the public key of the next certificate in the chain.

  5. The last certificate is a valid self-signed certificated trusted by the end-entity checker.

Additionally, the algorithm could also check complex application policies (i.e., the certificate can be used for web server authentication and/or web client authentication).

3.3 Electronic Passports

Data Group Data Elements
Data Group 1 Document Types
Issuing State or Organizaton
Name (of Holder)
Document Number
Check Digit - Doc Number
Nationality
Date of Birth
Check Digit - DOB
Sex
Date of Expiry or Valid Until Date
Check Digit DOE/VUD
Optional Data
Check Digit - Optional Data Field
Composite Check Digit
Data Group 11 Personal Number
Data Group 15 User’s Public Key
Table 2: Data Groups from Electronic Passports

Modern electronic passports feature NFC chips[ICA15b] that contain all their printed information in digital form, using a proprietary format set by International Civil Aviation Organization[ICA15a] and not X.509 certificates 3.2 like the ones used in national identity cards: the relevant fields are contained within its Data Group 1 2 (i.e., the same information available within the Machine Readable Zone), and the Document Security Object contains a hash of all the Data Groups signed by a Document Signing Certificate issued every three months (also stored on the passports), itself signed by a Country Signing Certificate Authority (all the certificates are available online[ICA18]). Additionally, the data within the NFC chips are cryptographically protected and it’s necessary to derive the cryptographic keys by combining the passport number, date of birth and expiry date (i.e., BAC authentication).

Finally, note that the electronic identity cards of some countries can also work as ePassports (e.g., Spanish Identity Card -Documento Nacional de Identidad-).

3.4 Verifiable Computation

A public verifiable computation scheme allows a computationally limited client to outsource to a worker the evaluation of a function on inputs and : other alternative uses of these schemes allow a verifier to efficiently check computations performed by an untrusted prover . More formally, the following three algorithms are needed:

Definition 1.

(Public Verifiable Computation). A public verifiable computation scheme consists of three polynomial-time algorithms defined as follows:

  • : the key generation algorithm takes the function to be computed and security parameter ; it outputs a public evaluation key and a public verification key .

  • : the prover runs the deterministic worker algorithm taking the public evaluation key , an input supplied by the verifier and an input supplied by the prover. It outputs and a proof of ’s correctness (as well as of prover’s knowledge of ).

  • : the deterministic verification algorithm outputs if , and otherwise.

A public verification computation scheme must comply with the following properties of correctness, security, and efficiency:

  • Correctness: for any function and any inputs to , if we run and then we always get .

  • Efficiency: Keygen is a one-time setup operation amortised over many calculations and is computationally cheaper than evaluating .

  • Security: for any function and any probabilistic polynomial-time adversary , we require that

    and

    where denotes a negligible function of inputs .

Additionally, we require the public verification computation scheme to be succinct and zero-knowledge:

  • Succinctness: the generated proofs are of constant size, that is, irrespective of the size of the function and inputs and .

  • Zero-knowledge: the verifier learns nothing about the prover’s input beyond the output of the computation.

Practical implementations are Pinocchio[PGHR13] and Geppeto[CFH14], or Buffet[WSH14] and Pequin[Pro16](a simplified version of Pepper[SMBW12]).

3.4.1 Verifiable Validation of X.509 Certificates as Anonymous Credentials

The algorithm for certificate chain validation chain in section 3.2 can be implemented with the public verifiable computation scheme of section 3.4 using zk-SNARKS to obtain a verifiable computation protocol so that a certificate holder is able to prove that he holds a valid X.509 certificate chain with a unique Distinguished Name, without actually sending the public key to the verifier and selectively disclosing the contents of the certificate: in other words, we re-use existing certificate chains and PKI infrastructure without requiring any modifications, turning X.509 certificates into anonymous credentials. A previous work already demonstrated the technical and practical viability of this approach[DLFKP16]: the only handicap was that the proof generation could take a long time (e.g., more than 10 minutes) and large keys (e.g., 1 Gbyte)..

Recent research advances have improved[BGG17] the initial setup of the zk-SNARK protocol used to generate the Common-Reference String (CRS) with an MPC protocol, such that it’s secure even if all participants are malicious (except one). And faster proving times could be obtained by efficiently composing the non-interactive proving of algebraic and arithmetic statements[AGM18] since QAP-based zk-SNARKs are only efficient for arithmetic representations and not algebraic statements, but at the cost of increasing the proof size.

In this paper, a practical implementation has been completed to check a certificate chain with an additional validation policy and written as C code for Pequin[Pro16], then compiled into a public evaluation and verification keys: unfortunately, it isn’t scalable to millions of users and/or the large circuits/constraints required to cover all the typologies of national identity cards/ePassports, thus an implementation based on TEE and mutual attestation is the preferred implementation 4.2. The only zero-knowledge proof system that could be scalable enough[WZC18] works on a computer cluster, thus it doesn’t fit the setting of a single user authenticating on his own device, and a libsnark backend can’t handle more than 4 million gates requiring more than an hour of computation. Therefore, an implementation only using software means is still Work-In-Progress.

3.5 Cryptographic Accumulators

Firstly devised by Benaloh and de Mare[BdM94], a cryptographic accumulator [DHS15] is a compact binding set of elements supporting proofs of membership and more space-efficient than storing all of the elements of the set; given an accumulator, an element, and a membership witness, the element’s presence in the accumulated set can be verified. Generally speaking, an accumulator consists of four polynomial-time algorithms:

  • : given the security parameter , it instantiates the initial value of the empty accumulator.

  • : adds the element to the current state of the accumulator producing the updated accumulator value and the membership witness for .

  • : on the basis of the current state of a witness and the newly added value , it returns an updated witness .

  • : verifies the membership of using its witness on the current state of accumulator .

The following are interesting security properties of accumulators:

  • Dynamic accumulators[CL02]: accumulators supporting the removal of elements from the accumulator by means of a deletion algorithm and a witness update algorithm .

  • Universality[LLX07]: accumulators supporting non-membership proofs, , and .

  • Strong accumulators[CHKO12]: deterministic and publicly executable, meaning that it does not rely on a trusted accumulator manager.

  • Public checkable accumulators, the correctness of every operation can be publicly verified.

Recent constructions of cryptographic accumulators specifically tailored for blockchains are: a dynamic, universal, strong and publicly checkable accumulator [FVY14]; an asynchronous accumulator[RY15] with low frequency update and old-accumulator compatibility (i.e., up-to-date witnesses can be verified even against an outdated accumulator); a constant-sized, fair, public-state, additive, universal accumulator[PSRK18], and an accumulator optimised for batch and aggregation operations[BBF18].

3.6 Remote Attestation

In the terminology of Intel SGX, remote attestation is used to prove that an enclave has been established without alterations of any kind: in other words, remote parties can verify that an application is running inside an SGX enclave. Concretely, remote attestation is used to verify three properties: the identity of the application, that it has not been tampered with, and that it is running securely within an SGX enclave. Remote attestation is carried out in several stages: requesting a remote attestation from the challenger; performing a local attestation of the enclave; converting said local attestation to a remote attestation; returning the remote attestation to the challenger, and the challenger verifying the remote attestation to the Intel Attestation Service.

A detailed technical description is outside of the scope of this paper: detailed descriptions can be found in the standard technical documentation[CD16, AGJS13, M18]. Recent attacks[VBMW18] can be used to extract the secret attestation keys used to verify the identity of an SGX enclave, and microcode updates must be installed[Cor18] to prevent their exploitation: that is, it’s essential to check that parties to a remote attestation are using a safe and updated version. However, our protocols are inherently resistant to deniability attacks[GPA18] because they are based on mutual attestation.

As it would be shown in the next section 4.2, remote attestation can be used as a more efficient substitute of verifiable computation.

4 Authentication Protocols

In this section, we describe authentication protocols for Sybil-resistant, anonymous authentication using Zero-Knowledge protocols 4.1 and remote attestation 4.2.

4.1 Authentication Protocols using Zero-Knowledge

The use of zero-knowledge protocols guarantee the public-verifibility of the correctness of the Sybil-resistant, anonymous identities committed to the permissionless blockchain.

4.1.1 Security Goals

The following security goals must be met for the system to be considered secure:

  1. The registered miner’s key to the blockchain opens, but no one can shut; he can shut, but no one can open (Isaiah 22:22, [Isa00]). For the security of the system to be considered equivalent to the currently available permissionless blockchains, anyone holding a valid public certificate should be able to register a pseudo-anonymous identity on the blockchain but no one should be able to remove it (i.e., uncensorable free entry is guaranteed).

  2. Protection against malicious issuers: some certification authorities may turn against some citizens and try to cancel access to the permissionless blockchain or stole their funds.

    1. Mandatory passphrase. An issuer may counterfeit a certificate with the same unique identifiers, thus possessing a valid certificate isn’t secure enough and a passphrase is deemed mandatory.

    2. Non-bruteforceable. Operations must be computationally costly on the client side to prevent brute-forcing.

    3. No OCSP checking. Prevention against malicious blacklisting.

  3. Privacy: miner’s real identity can’t be learned by anyone.

  4. Unique pseudonyms: from each identity card/ePassport, only one unique identifier can be generated.

  5. Publicly verifiable: anyone should be able to verify the validity of the miner’s public key and its pseudonym.

4.1.2 Zero-Knowledge Protocols (X.509)

Anonymous miner registration of a new public key on a permissionless blockchain. This protocol generates a unique pseudonym for each miner, and attaches a verifiable proof that its new public key to be stored on-chain is signed with a valid public certificate included on a recognised certification authorities list, and that the new public key is linked to the blockchain-specific pseudonym that is in turn uniquely linked to the citizen’s public key certificate.

Miners holding a public key certificate must execute the following steps:

  1. Create a deterministic public/secret key pair based on a secret passphrase (no need for verifiable computation):

    The generation algorithm must be determistic because the smartcard may be unable to store them and/or the miner may loose them (i.e., as in deterministic wallets). KDF is a password-based key derivation function (e.g., PBKDF2).

  2. Obtain a signature of the previously generated public key with the miner’s public key certificate (no need for verifiable computation, this operation could be executed on a smartcard):

  3. Check the validity of the certificate chain of the miner’s public key certificate as extracted from the smartcard:

    1. Load the public key of the root certificate.

    2. Hash and verify all intermediates, based on their certificate templates, and the public key of their parent certificate starting from the root certificate and following with the verified public key from the previous intermediate certificate template.

    3. Hash and verify the miner’s public key certificate using the last verified public key returned from the previous step.

    4. Check the time validity of the miner’s public key certificate.

    5. Check that the miner’s public key certificate is contained on a list of trusted certification authorities.

  4. Obtain the unique identifier from the miner’s public key:

    Note that the unique identifier is usually contained on Serial Number of the certificate, or the Subject Alternative Name extension under different OIDs, depending on the country.

  5. Generate a deterministic pseudonym using the blockchain identifier:

    PKCS_Sign is the deterministic PKCS#1.5 signing algorithm executed on a prefixed string to obtain a unique, non-predictable secret based on the certificate’s owner. The obtained signature is appended to the blockchain identifer and the unique identifier, and then hashed to derive a unique pseudonym. Finally, the string “REG” is appended to differentiate this pseudonym from the one generated during a remove protocol and prevent replay attacks for removal reusing the generated zero-knowledge proof.

  6. Verify the signature on the miner’s public key certificate :

  7. As the is calculated offline by the smartcard, it’s also necessary to verify it using the miner’s public key certificate :

  8. Generate the zero-knowledge proof (e.g., zk-SNARK, zk-STARK or zk-SNARG) of the miner’s public key certificate , the generated pseudonym and, signature such that all the previous conditions 3-7 hold.

  9. Anonymously contact the permissionless blockchain:

    1. optionally, check the miner’s real identity on a cryptographic accumulator:

      1. establish a shared secret running a Diffie-Hellman key exchange between the prospective miner and the permissionless blockchain

      2. send attributes of the miner’s real identity encrypted with the shared secret

      3. execute the non-membership proof on the cryptographic accumulator

    2. register the generated pseudonym, the new public key , the signature and : note that they don’t reveal the miner’s real identity (, and are all keep as a secret).

The registering node of the permissionless blockchain verifies before adding the new public key, the associated pseudonym, the signature and the succinct proof : note that the miner is unable to register multiple pseudonyms, and he can only use one running node that would be signing messages with the generated secret key . Other nodes would be able to efficiently verify to confirm that the public key is a signed by someone from an allowed certificate authority, and that the pseudonym is the miner’s unique alias for the blockchain.

Taking offline registrations from a permissionless blockchain. This protocol takes offline a pseudonym and its associated public key and signature from a permissionless blockchain. Miners must execute the following steps to take offline an identity from a permissionless blockchain:

  1. Generate a zero-knowledge proof (e.g., zk-SNARK, zk-STARK or zk-SNARG) of the steps 3-7 of the previous protocol to prove secret knowledge of and that he’s able to re-generate the pseudonym, but this time appending the string “OFF” to the pseudonym.

  2. Anonymously contact the permissionless blockchain to take offline the generated pseudonym and all its associated data (including the cryptographic accumulator), attaching .

The registering node of the permissionless blockchain verifies before taking offline the pseudonym without learning the real identity of the miner (publicCert, uniqueID and signatureSecret remain secret).

4.1.3 Zero-Knowledge Protocols (ePassports)

Analogous to the zero-knowledge protocols for X.509 4.1.2, but now considering the specific details of ePassports 3.3, which usually contain a unique keypair with the public key on Data Group 15 and the private key hidden within the chip: the Active Authentication protocol can be used to sign random challenges that can be verified with the corresponding public key.

Anonymous miner registration of a new public key on a permissionless blockchain. This protocol generates a unique pseudonym for each miner, and attaches a verifiable proof that its new public key to be stored on-chain is signed with a valid public certificate included on the list of Country Signing Certificate Authorities, and that the new public key is linked to the blockchain-specific pseudonym that is in turn uniquely linked to the public key certificate of the passport holder.

Miners holding a public key certificate must execute the following steps:

  1. Create a deterministic public/secret key pair based on a secret passphrase (no need for verifiable computation):

    The publicCert is taken from the Data Group 15. KDF is a password-based key derivation function (e.g., PBKDF2).

  2. Obtain a signature of the previously generated public key with the miner’s public key certificate (no need for verifiable computation, this operation is executed within the ePassport’s chip using the Active Authentication protocol):

  3. Check the validity of the Data Security Object of the miner’s ePassport:

    1. Load the public key of the Country Signing Certificate from a trusted source [ICA18] and the Document Signing Certificate from the ePassport.

    2. Hash all the Data Groups and check their equivalence to the Data Security Object.

    3. Verify the signature of the Data Security Object using the Document Signing Certificate.

    4. Verify the signature of the Document Signing Certificate using the Country Signing Certificate.

    5. Check the time validity of the certificates.

  4. Obtain the unique identifier of the ePassport:

    Note that the unique identifier is usually contained on the Data Element “Document Number” of the Data Group 1: as it’s legally valid for the same person to own multiple passports with different Document Numbers, some countries include a unique “Personal Number” on the Data Group 11.

  5. Generate a deterministic pseudonym using the blockchain identifier:

    Sign is the Active Authentication protocol executed within the ePassport’s chip, a deterministic signing algorithm executed on a prefixed string to obtain a unique, non-predictable secret based on the certificate’s owner. The obtained signature is appended to the blockchain identifer and the unique identifier, and then hashed to derive a unique pseudonym. Finally, the string “REG” is appended to differentiate this pseudonym from the one generated during a remove protocol and prevent replay attacks for removal reusing the generated zero-knowledge proof (e.g., zk-SNARK, zk-STARK or zk-SNARG).

  6. Verify the signature on the miner’s public key certificate :

    The publicCert is taken from the Data Group 15.

  7. As the is calculated offline by the ePassport’s chip, it’s also necessary to verify it using the miner’s public key certificate :

    The publicCert is taken from the Data Group 15.

  8. Generate the zero-knowledge proof (e.g., zk-SNARK, zk-STARK or zk-SNARG) of the miner’s public key certificate , the generated pseudonym, and signature such that all the previous conditions 3-7 hold.

  9. Anonymously contact the permissionless blockchain

    1. optionally, check the miner’s real identity on a cryptographic accumulator:

      1. establish a shared secret running a Diffie-Hellman key exchange between the prospective miner and the permissionless blockchain

      2. send attributes of the miner’s real identity encrypted with the shared secret

      3. execute the non-membership proof on the cryptographic accumulator

    2. register the generated pseudonym, the new public key , the signature and : note that they don’t reveal the miner’s real identity (, and are all keep as a secret).

The registering node of the permissionless blockchain verifies before adding the new public key, the associated pseudonym, the signature and the succinct proof : note that the miner is unable to register multiple pseudonyms, and he can only use one running node that would be signing messages with the generated secret key . Other nodes would be able to efficiently verify to confirm that the public key is a signed by someone from an allowed certificate authority and that the pseudonym is the miner’s unique alias for the blockchain.

Taking offline registrations from a permissionless blockchain. This protocol takes offline a pseudonym and its associated public key and signature from a permissionless blockchain. Miners must execute the following steps to take offline an identity from a permissionless blockchain:

  1. Generate a zero-knowledge proof (e.g., zk-SNARK, zk-STARK or zk-SNARG) of the steps 3-7 of the previous protocol to prove secret knowledge of and that he’s able to re-generate the pseudonym, but this time appending the string “OFF” to the pseudonym.

  2. Anonymously contact the permissionless blockchain to take offline the generated pseudonym and all its associated data (including the cryptographic accumulator), attaching .

The registering node of the permissionless blockchain verifies before taking offline the pseudonym without learning the real identity of the miner (publicCert, uniqueID and signatureSecret remain secret).

4.1.4 Mapping to goals

The previous protocols achieve the security goals:

  1. The registered miner’s key to the blockchain opens, but no one can shut; he can shut, but no one can open. Only someone in possession of a valid public certificate can create a unique miner identity on the open blockchain and destroy it. Please note that the signing and verification of steps 2, 5, 6 and 7 are only needed if it’s required to check that the miner is the real owner of the smartcard/ePassport.

  2. Protection against malicious issuers: the passphrase is mandatory, there’s no OCSP checking and the protocol is non-bruteforceable because it requires the generation of a proof for every passphrase that is going to be tried (>60 secs per ).

  3. Privacy: miner’s real identity can’t be learned by anyone because publicCert and uniqueID are keep secret.

  4. Unique pseudonyms: from each identity card/ePassport, only one unique identifier can be generated because there’s only one uniqueID per citizen.

  5. Publicly verifiable: using the proof , anyone is able to validate the miner’s public key and its pseudonym.

Additionally, cryptographic accumulators could be added to the protocols in order to prevent multiple registrations whenever an expired certificate is renovated.

4.2 Detailed Authentication Protocols using Mutual Attestation

The use of remote attestation protocols guarantee the efficiency and scalability of the full authentication solution (i.e., it can easily scale to billions of users). By design, the architecture has detached the encrypted DB from the mining nodes to maintain the implementation as blockchain-agnostic as possible: some mining nodes may include an encrypted DB, but it’s not necessary that all mining nodes include it.

Figure 4.1: Simplified overview of mutual attestation.

4.2.1 Security Goals

The following security goals must be met for the system to be considered secure:

  1. The registered miner’s key to the blockchain opens, but no one can shut; he can shut, but no one can open (Isaiah 22:22, [Isa00]). For the security of the system to be considered equivalent to the currently available permissionless blockchains, anyone holding a valid public certificate should be able to register a pseudo-anonymous identity on the blockchain but no one should be able to remove it (i.e., uncensorable free entry is guaranteed).

  2. Protection against malicious issuers: some certification authorities may turn against some citizens and try to cancel access to the permissionless blockchain or stole their funds.

    1. Mandatory passphrase. An issuer may counterfeit a certificate with the same unique identifiers, thus possessing a valid certificate isn’t secure enough and a passphrase is deemed mandatory.

    2. Non-bruteforceable. Operations must be computationally costly on the client side to prevent brute-forcing.

    3. No OCSP checking. Prevent against malicious blacklisting.

  3. Privacy: miner’s real identity can’t be learned by anyone.

  4. Unique pseudonyms: from each identity card/ePassport, only one unique identifier can be generated.

4.2.2 Mutual Attestation for X.509 Certificates

Anonymous miner registration of a new public key on a permissionless blockchain. This protocol generates a unique pseudonym for each miner, with a new public key linked to the blockchain-specific pseudonym that is in turn uniquely linked to the citizen’s public key certificate: the mutual attestation between the parties guarantees the correctness of the execution of both parties.

The following are the steps to the protocol:

  1. The client locally generates a signature secret using its secret key:

  2. Mutual attestation between the authenticating client and the blockchain: the attestation is anonymous thanks to the use of unlinkable signatures (Enhanced Privacy ID -EPID-), and both parties obtain a temporary secret key to encrypt their communications.

  3. Client’s attested code checks the validity of the certificate chain of the miner’s public key certificate as extracted from the smartcard:

    1. Load the public key of the root certificate.

    2. Hash and verify all intermediates, based on their certificate templates, and the public key of their parent certificate starting from the root certificate and following with the verified public key from the previous intermediate certificate template.

    3. Hash and verify the miner’s public key certificate using the last verified public key returned from the previous step.

    4. Check the time validity of the miner’s public key certificate.

    5. Check that the miner’s public key certificate is contained on a list of trusted certification authorities.

  4. If the previous step concluded satisfactorily, then the client’s attested code verifies the using the miner’s public key certificate because the is calculated offline by the smartcard:

  5. If the previous step concluded satisfactorily, then the client’s attested code creates a deterministic public/secret key pair based on a secret passphrase:

    The generation algorithm must be deterministic because the smartcard may be unable to store them and/or the miner may lose them (i.e., as in deterministic wallets). KDF is a password-based key derivation function (e.g., PBKDF2).

  6. The client’s attested code generates a deterministic pseudonym using the blockchain identifier:

    and it obtains the unique identifier from the miner’s public key:

    Note that the unique identifier is usually contained on Serial Number of the certificate, or the Subject Alternative Name extension under different OIDs, depending on the country.

  7. Anonymously contact the attested encrypted database of the permissionless blockchain to register the generated pseudonym and the new public key : the uniqueID is also included using the temporary encrypted key, but it won’t be revealed to the host computer of the blockchain node because it will only be decrypted within the attested enclave.

  8. The blockchain’s attested code checks within its encrypted database that the uniqueID has never been included: then, it proceeds to store the encrypted uniqueID (i.e., this time with a database secret key that only resides within the enclaves), the generated pseudonym and the new public key .

  9. Then, the encrypted database’s attested code contacts the permissionless blockchain to register the generated pseudonym and its new public key .

Taking offline registrations from a permissionless blockchain. This protocol takes offline a pseudonym and its associated public key from a permissionless blockchain. To take offline an identity from a permissionless blockchain, miners must re-run the previous protocol to prove that the client is able to re-generate the pseudonym with the same certificate, but this time appending the string “OFF” to the pseudonym.

The registering encrypted database of the permissionless blockchain verifies that the encrypted uniqueID is included in the database before taking offline the pseudonym from the permissionless blockchain without it learning the real identity of the miner.

4.2.3 Mutual Attestation for ePassports

Analogous to the zero-knowledge protocols for X.509 4.2.2, but now considering the specific details of ePassports 3.3, which usually contain a unique keypair with the public key on Data Group 15 and the private key hidden within the chip: the Active Authentication protocol can be used to sign random challenges that can be verified with the corresponding public key.

Anonymous miner registration of a new public key on a permissionless blockchain. This protocol generates a unique pseudonym for each miner, with a new public key linked to the blockchain-specific pseudonym that is in turn uniquely linked to the citizen’s ePassport: the mutual attestation between the parties guarantees the correctness of the execution of both parties.

The following are the steps to the protocol:

  1. The client locally generates a signature secret using its secret key:

  2. Mutual attestation between the authenticating client and the blockchain: the attestation is anonymous thanks to the use of unlinkable signatures (Enhanced Privacy ID -EPID-), and both parties obtain a temporary secret key to encrypt their communications.

  3. Client’s attested code checks the validity of the Data Security Object of the miner’s ePassport:

    1. Load the public key of the Country Signing Certificate from a trusted source[ICA18] and the Document Signing Certificate from the ePassport.

    2. Hash all the Data Groups and check their equivalence to the Data Security Object.

    3. Verify the signature of the Data Security Object using the Document Signing Certificate.

    4. Verify the signature of the Document Signing Certificate using the Country Signing Certificate.

    5. Check the time validity of the certificates.

  4. If the previous step concluded satisfactorily, then the client’s attested code verifies the using the miner’s public key certificate because the is calculated offline by the ePassport’s chip:

    The publicCert is taken from the Data Group 15.

  5. If the previous step concluded satisfactorily, then the client’s attested code creates a deterministic public/secret key pair based on a secret passphrase:

    The generation algorithm must be deterministic because the ePassport is unable to store them and/or the miner may lose them (i.e., as in deterministic wallets). KDF is a password-based key derivation function (e.g., PBKDF2).

  6. The client’s attested code generates a deterministic pseudonym using the blockchain identifier:

    and it obtains the unique identifier from the ePassport:

    Note that the unique identifier is usually contained on the Data Element “Document Number” of the Data Group 1: as it’s legally valid for the same person to own multiple passports with different Document Numbers, some countries include a unique “Personal Number” on the Data Group 11. Sign is the Active Authentication protocol executed within the ePassport’s chip, a deterministic signing algorithm executed on a prefixed string to obtain a unique, non-predictable secret based on the certificate’s owner.

  7. Anonymously contact the attested encrypted database of the permissionless blockchain to register the generated pseudonym and the new public key : the uniqueID is also included using the temporary encrypted key, but it won’t be revealed to the host computer of the blockchain node because it will only be decrypted within the attested enclave.

  8. The blockchain’s attested code checks within its encrypted database that the uniqueID has never been included: then, it proceeds to store the encrypted uniqueID (i.e., this time with a database secret key that only resides within the enclaves), the generated pseudonym and the new public key .

  9. Then, the encrypted database’s attested code contacts the permissionless blockchain to register the generated pseudonym and its new public key .

Taking offline registrations from a permissionless blockchain. This protocol takes offline a pseudonym and its associated public key from a permissionless blockchain. To take offline an identity from a permissionless blockchain, miners must re-run the previous protocol to prove that the client is able to re-generate the pseudonym with the same certificate, but this time appending the string “OFF” to the pseudonym.

The registering encrypted database of the permissionless blockchain verifies that the encrypted uniqueID is included in the database before taking offline the pseudonym from the permissionless blockchain without it learning the real identity of the miner.

4.2.4 Mapping to goals

The previous protocols achieve the security goals:

  1. The registered miner’s key to the blockchain opens, but no one can shut; he can shut, but no one can open[Isa00]. Only someone in possession of a valid public certificate can create a unique miner identity on the open blockchain and destroy it. The signing and verification operations of steps 1 and 4 are only needed if it’s required to check that the miner is the real owner of the smartcard/ePassport.

  2. Protection against malicious issuers: the passphrase is mandatory, there’s no OCSP checking and the protocol is non-bruteforceable because it can be rate-limited.

  3. Privacy: miner’s real identity can’t be learned by anyone because publicCert and uniqueID are keep secret.

  4. Unique pseudonyms: from each identity card/ePassport, only one unique identifier can be generated because there’s only one uniqueID per citizen.

The proposed solution depends on the security of Intel SGX (enclave and remote attestation protocols): in order to limit the impact of side-channels attacks on Intel SGX, mining nodes featuring the role of the Attested Encrypted DB will be restricted to trustworthy nodes.

4.2.5 Performance Evaluation

# VMs Mean Time/Req. #Req./Sec Time/Connections Total time
1 VM 416 ms 4.76 210 ms 21 secs
4 VM 112 ms 16.5 59 ms 5.9 secs

A load testing scenario featuring an Intel Xeon E3-1240 3.5 GHz and running 1 or 4 virtual machines was performed (with 5 users executing 100 requests per user). Operations like reading and/or signing from the smartcard were not included in the performance evaluation. The implementation will be open-sourced.

4.3 Worldwide Coverage and Distribution

Figure 4.2: Legend: (1) National identity card is a mandatory smartcard; (2) National identity card is a voluntary smartcard; (3) No national identity card, but cryptographic identification is possible using an ePassport, driving license and/or health card; (4) Non-digital identity card.

Fortunately, there is a unique cryptographic identifier for most people in the world: figure 4.2 shows a worldmap of the distribution of national identity cards. For some countries, there is no national identity card -code 3-, but some other unique cryptographic identifier is available (e.g., ePassport[Nit09] and/or biometric passports as in figure 4.3, social security card, driving license and/or health card). Transforming these unique identifiers into anonymous credentials enables the unique identification of individuals in a permissionless blockchain without revealing their true identities, making them indistinguishable: that is, authentication is not only anonymous but permissionless since there is no need to be pre-invited. Please note the enormous cost savings resulting from this approach compared to other anonymous credential[GGM13, SABBD18, CDD17]

proposals that would require re-issuing new credentials: for example, consider that the UK’s national identity scheme was estimated at £5.4bn

[Pro08].

In some cases, an individual could obtain multiple cryptographic identifiers (e.g., multiple nationalities), but their number would still be limited and certainly less than the number of mining nodes that could be spawned on PoW permissionless blockchains. Additionally, the true identities provided by national identity cards could be used for other purposes, such as non-anonymous accounts identified by their legal identities.


Figure 4.3: Availability of biometric passports. Source (ICAO, 2019)

4.3.1 eSIM’s Public Key Infrastructure

Latest specifications of SIM cards determine that SIM’s identity and data can be downloaded and remotely provisioned to devices[GSM18]: instead of the traditional SIM card, there is an embedded SIM (i.e., eUICC[All19]) that can store multiple SIM profiles containing the operator and subscriber data that would be stored on a traditional SIM card (e.g., IMSI, ICCID, …).

A novel public key infrastructure has been created in order to protect the distribution of these new eSIM profiles[Ass17]: every certified eSIM is signed by its certified manufacturer, with a certificate that is itself signed by the GSMA root certificate issuer[GSM19]. Network operators must also get certified and obtain certificates for their Subscription Management roles.

The eSIM’s PKI provides an alternative identification system for users where national identity cards and/or ePassports are difficult to obtain, as they must be unique and non-anonymous (4.13 and 4.1.5[Ass17]), but only when the mobile operator’s KYC processes can be considered trustworthy.

4.4 Circumventing the Impossibility of Full Decentralization

Most blockchains using PKIs are consortium blockchains, thus it has become widespread that they always are permissioned and centralised. However, the term “permissionless” literally means “without requiring permission” (i.e., to access, to join, …), thus a blockchain with a PKI could be permissionless if it accepts any self-signed certificate (i.e., a behaviour conceptually equivalent to Bitcoin), or any certificate from any government in the world as described in the previous subsection 4.3. In the same way, a blockchain using PKIs doesn’t imply that its control has become centralised, it means that it accepts identities from said PKIs as described in this paper: actually, decentralization in the blockchain context strictly means that the network and the mining are distributed in a large number of nodes, thus unrelated to authentication.

A recent publication[KLK19] proves that it’s impossible for blockchains to be fully decentralised without real identity management (e.g., PoW, PoS and DPoS) because they cannot have a positive Sybil cost, defined as the additional cost that a player should pay to run multiple time nodes compared to the total cost of when those nodes are run by different players. To reflect the level of decentralization, they introduce the following definition:

Definition 2.

(-Decentralization)[KLK19]. For , and , a system is -decentralized if it satisfies the following:

  1. The size of the set of players running nodes in the consensus protocol, , is not less than (i.e., ).

  2. Define as the effective power of player as where is the set of all nodes in the consensus protocol and is the resource power of player . The ratio between the effective power of the richest player, , and the percentile player, , is less than or equal to (i.e., ).

Ideally, the number should be as high as possible (i.e., too many players do not combine into one node); and for the most resourceful and the -th percentile player running nodes, the gap between their effective power is small. Therefore, full decentralization is represented by for sufficiently large .

Definition 3.

(Sufficient Conditions for Fully Decentralized Systems)[KLK19]. The four following conditions are sufficient to reach

-decentralization with probability 1.

  1. (Give Rewards (GR-)). Nodes with any resource power earn rewards.

  2. (Non-delegation (ND-)). It is not more profitable for too many players to delegate their resource power to fewer participants than to directly run their own nodes.

  3. (No Sybil nodes (NS-)). It is not more profitable for a participant with above the -th percentile effective power to run multiple nodes than to run one node.

  4. (Even Distribution (ED-()). The ratio between the resource power of the richest and the -th percentile nodes converges in probability to a value less than 1+.

Theorem 4.

For any initial state, a system satisfying GR-, ND-, NS-, and ED- converges in probability to -decentralization. [KLK19]

As it should be obvious by now, a blockchain using zk-PoI with strong identities from trusted public certificates (e.g., national identity cards and/or ePassports 4.3) as described in this paper is the perfect candidate to achieve a fully decentralized blockchain.

Theorem 5.

A blockchain using zk-PoI with strong identities from trusted public certificates (e.g., national identity cards and/or ePassports 4.3) reaches -decentralization with probability 1.

Sketch of Proof.

A blockchain using zk-PoI with strong identities from trusted public certificates effectively limits the number of mining nodes to one per individual (ND-), independently of how resourceful they are (NS-, ED-()), while keeping membership open to everyone (i.e., achieves a large number of participants (GR-)). The presence of strong identities allows positive Sybil costs, thus the fulfillment of the sufficient conditions for fully decentralized systems[KLK19]. ∎

Preventing delegation (ND-) is the most difficult condition to meet:

  • market-enforced: richest participants could buy rights-of-use of others’ identities, but the market value of said identities (e.g., the Net Present Value of future profits obtained from the exploitation of said identities by their real owners) should wipe away almost all the profits from these exchanges.

  • strictly-enforced: miners’ software could frequently check for the presence of the physical trusted public certificate (e.g., national identity cards and/or ePassports) and/or require them when transferring funds out of their accounts.

4.5 Resistance against Dark DAOs

Dark DAOs[DKMJ18] appear as a consequence of permissionless blockchains where users can create their own multiple identities and there’s no attributability of the actions.

  1. When using real-world identities, it’s possible to establish the identity of the parties running the Dark DAO that are committing frauds (attributability) or at least, their pseudonyms: therefore, it’s possible to punish them.

  2. To prevent Dark DAOs buying real-world identities, a smart contract can be setup that pays a reward for denouncing the promoters of the fraud: the whistleblowers would be paid a multiple of what they would get from the defrauders, thus making denunciation the preferred option. Then defrauders would be banned as in step 1.

4.6 Resistance against Collusion and other Attacks

In this sub-section, we consider different avenues for attack and provide detailed defense mechanisms:

  1. Corrupt root certificate authorities

  2. Attacks against consensus protocols

  3. Resistance against collusion

  4. On achieving collusion-freeness

4.6.1 Corrupt Root Certificate Authorities

Corrupt countries may be tempted to create fake identities or frequently renovate existing ones: these countries can be easily banned out by removing them from the list of valid authorities (i.e., root X.509 certificate and/or Country Signing Certificate). Bounties in cryptocurrency could be offered for whistleblowing any corrupt attack against the long-term existence of the blockchain.

4.6.2 Attacks against Consensus Protocols

Modern consensus protocols based on the cryptographically secure random choice of the leader (e.g., [HMW18, KKJG17]) detect cheating by monitoring changes to the chain quality. The following table gathers cheating events for different consensus algorithms that could be detected and punished:

Protocol Cheater detection
Dfinity[HMW18] Equivocation: multiple blocks for same round with same rank.
Equivocation: multiple blocks with the highest priority.
All the blocks must be timely published.
All the notarizations must be timely published within one round.
OmniLedger[KKJG17] Core validators can detect rogue validators.
Withholders can be detected after multiple consecutive rounds.
5>= failed RandHound views from a rogue validator.

4.6.3 Resistance against Collusion

Consensus protocols already provide collusion-tolerance by design: an adversary controlling a high number of nodes, or equivalently all said nodes colluding for the same attack, must confront the difficulties introduced by shard re-assignment at the beginning of every new epoch. For the case of OmniLedger[KKJG17]

, the security of the validator assignment mechanism can be modeled as a random sampling problem using the binomial distribution,

assuming that each shard has less than malicious validators. Then, the failure rate of an epoch is the union bound of the failures rates of individual shards, each one calculated as the cumulative distribution over the shard size , with

being the random variable that represents the number of times we pick a malicious node. An upper bound of the epoch failure event,

, is calculated as:

where is the number of consecutive views the adversary controls, is the number of shards and is the failure rate of one individual shard. Finally, for , we obtain

4.6.4 On Achieving Collusion-Freeness

Start noticing that collusion-freeness is not about preventing malicious behaviour, only preventing that malicious players act as independently of each other as possible. Following a previous seminal work[LMas05], collusion-freeness can only be obtained under very stringent conditions: (a) the game must be finite; (b) the game must be publicly observable; and (c) the use of private channels at the beginning of the game is essential, but forbidden during the execution of the protocol. Although blockchains are publicly observable, they are also an infinite game where parties can freely communicate between them using private channels at any time: therefore, collusion-freeness is impossible in the sense of [LMas05].

Fortunately, there is a way to get around this impossibility result: forbid malicious/Byzantine behaviours requiring the use of mutual attestation for all the nodes, thus precluding any deviation from the original protocol.

Conjecture 6.

If mutual attestation is required for all the nodes, any infinite, partial-information blockchain game with publicly observable actions has a collusion-free protocol.

As mutual attestation is already required for zk-PoI 4.2, we would only be extending its use for the rest of the blockchain protocol.

5 Incentive Compatible and Strictly Dominant Cryptocurrencies

The success of cryptocurrencies is better explained by their incentive mechanisms rather than their consensus algorithms: a cryptocurrency with poor incentives (e.g., a cryptocurrency not awarding coins to miners) will not achieve any success; conversely, better incentives and much more inefficient consensus algorithm could still find some success.

Much research has been focused on conceiving better consensus algorithms for decentralised systems and cryptocurrencies[PS16, DPS16, KKJG17, GHM17, KJG16, HMW18]: unfortunately, obtaining consensus mechanisms with better incentives and economic properties is an area that is lacking much research, and the combination of all the game-theoretic results contained in this section fills this gap for the sake of achieving a focal point (i.e., Schelling point[Sch60]) in the multi-equilibria market of cryptocurrencies. Thus, a selective advantage is introduced by design over all the other cryptocurrencies, in explicit violation of the neutral model of evolution[EAK17] in order to obtain an incentive compatible and strictly dominant cryptocurrency.

5.1 Incentive-Compatible Cryptocurrency

Shard-based consensus protocols have been recently introduced in order to increase the scalability and transaction throughput of public permissionless blockchains: however, the study of the strategic behaviour of rational miners within shard-based blockchains is very recent. Unlike Bitcoin, that grants all rewards to the most recent miner, block rewards and transactions fees must be proportionally shared between all the members of the sharding committee[KJG16], and this includes incentives to remain live during all the lifecycle of the consensus protocol. Even so, existing sharding proposals[KKJG17, ZMR18] remain silent on how miners will be rewarded to enforce their good behaviour: as it’s evident, if all miners are equally rewarded without detailed consideration of their efforts, rational players will free-ride on the efforts of others.

One significant difference introduced in this paper with respect to other shard-based consensus protocols is the use of Zero-Knowledge Proof-of-Identity as the Sybil-resistance mechanism: as we will see in the following sections, it’s a significant novelty because solving Proof-of-Work puzzles is the most computationally expensive activity of consensus protocols, thus it’s no longer dominated by computational costs. This makes the necessity for an incentive-compatible protocol even more acute: the preferred rational miner’s strategy is to execute the Proof-of-Work of the initial phase of the protocol for each epoch and to refrain from the transaction verification and consensus of subsequent phases of the protocol, but still selfishly claim the rewards as if they had participated. The substitution of costly PoW for cheap Zero-Knowledge Proof-of-Identity only increases the attractiveness of this rational strategy, that can only be counteracted by using an incentive-compatible protocol.

5.1.1 A Nash Equilibrium for a Cryptocurrency on a Shard-Based Blockchain

This section is based on a stylised version of a recent game-theoretic model[MJMF18], taking into consideration that there is no cost associated with committee formation to enter each shard since we are using Zero-Knowledge Proof-of-Identity, and not costly Proof-of-Work: instead, a penalty is imposed to defective and/or cheating miners. The following is a list of symbols:

Symbol Definition
Number of shards
Number of miners
Vector of received transactions by miner in shard
Vector of transactions submitted by shard to blockchain
Minimum number of miners in each committee
Required number of miners in shard for consensus
Benefit for each transaction
Benefit of miner after adding the block
Total cost of computation for miner
Total optional costs in each epoch
Cost of transaction verification
Fixed costs in optional cost
Penalty cost
Block Reward
Number of cooperative miners in each shard
Total number of cooperative miners in all shards
Set of all cooperative miners in shard
Set of all defective miners in shard
Set of all cooperative miners
Set of all defective miners
Signed receipt of a transaction

Let denote the shard-based blockchain game, defined as a triplet where is the set of players, is the set of strategies (Cooperate , or Defect ) and is the set of payoff values. Each miner receives a reward if and only it has already cooperated with other miners within the shard, the payoff of cooperative miners in set is

(5.1)

We assume that the block reward

is uniformly distributed among shards and each cooperative miner can receive a share of it. A miner might be cooperative but all other miners may agree on a vector of transactions

that is different from his own vector of transactions (i.e., ): nonetheless, transaction rewards are uniformly distributed among all cooperative miners in each shard, proportional to all the transactions submitted to the blockchain by each shard.

The defective miners’ payoff can be calculated as

because the defective miners will have to pay a penalty and they will not receive any benefit (and it doesn’t incur in any mandatory cost such as solving PoW puzzles because we use cheap Zero-Knowledge Proof-of-Identity).

There exists a cooperative Nash equilibrium profile in game under the following conditions:

Theorem 7.

Let and denote the sets of cooperating miners and defecting miners inside each shard with miners, respectively. represents a Nash equilibrium profile in each epoch of game , if the following conditions are satisfied:

  1. In all shards , .

  2. If for a given miner in shard , with , then the number of transactions must be greater than

  3. If for a given miner in shard , with , then the number of transactions must be smaller than

Proof.

The first condition (i.e., the number of cooperative miners must be greater than ) must hold so that cooperative miners will receive benefits for transactions and block rewards.

Let be the largest set of cooperative miners in each shard, where no miner in can join to increase its payoff: if miner is among the set of cooperative miners where , then it would not unilaterally deviate from cooperation if:

which shows that , whereas in the second condition,

But if is among the cooperators whose vector of transactions is different from the output of the shard, , then it would not deviate from cooperation if:

which shows that , whereas in the third condition,

Then if represents the largest set of cooperative miners in each shard, then would be the unique cooperative Nash equilibrium of the game . ∎

As can be understood from the proof, cooperative miners have less incentive to cooperate when: 1) the number of participants increases; 2) the optional costs of computation increase ( is in the numerator or in denominator of ); 3) or in general, when the number of transactions is not large enough compared to a fixed threshold.

5.1.2 Incentive-Compatible Cryptocurrency on a Shard-Based Coordinated Blockchain

In order to increase the incentives to cooperate rather than defect, an incentive-compatible protocol enforcing cooperation based on the previously presented Nash equilibrium is introduced here 1: all miners should disclose their list of transactions to a coordinator, who then announces to each miner whether their cooperation would be in their interests based on being within the maximum subset of miners with a similar list of transactions (i.e., ), and then enforces their cooperation by checking their compliance and rewarding them properly.

function ShardTransactionsAssignment {         } function NodeSelection {     send to Coordinator    if (PresentNode() == Coordinator) {       Receive all       Max number of miners with common txs. from list of       if ()          return ‘‘All Defective’’       else {          = list of miners          Calculate and from 7          return , and       }    } } function ShardParticipation {    if ( and )       return Defect    else if ( and )       return Defect    Verify transactions    =set of verified transactions by remaining cooperative    Consensus on verified transactions    Sign BFT agreement result    return signature, agreed block’s header } function VerificationAndRewards {    Verify cooperation of for each shard    Send rewards to cooperative using (LABEL:5.1) } Algorithm 1 Incentive-Compatible Protocol on a Coordinated Shard-Based Blockchain

The protocol proceeds as follows: for the first function (i.e., ShardTransactionsAssignment), each miner receives a list of transactions to verify based on the epochRandomness and his pseudonymous identity and public key obtained by the Zero-Knowledge Proof-of-Identity.

For the second function (i.e., NodeSelection), all miners calculate a hash over their transaction list and send it to the coordinator. The coordinator finds the subset with the maximum number of miners with a common transaction list, thus calculating , , and : in each epoch, the coordinator publicly defines the list of cooperative miners and defective miners using on 7.

For the third function (i.e., ShardParticipation), all the transactions of each miner are verified and a signed consensus is reached.

For the fourth function (i.e., VerificationAndRewards), the rewards are shared between the cooperative miners and denied to those miners in that didn’t cooperate.

5.1.3 Improved Incentive-Compatible Cryptocurrency on a Shard-Based Blockchain

Although the role of a coordinator is essential to BFT protocols[KJG16], its expanded functionality in the previous incentive-compatible protocol 1 is problematic: it introduces latency and network costs due to the new obligations to report to the coordinator; moreover, it creates new opportunities for malicious miners which may report false or not follow coordinator’s instruction to cooperate or defect. The next incentive-compatible protocol significantly improves over the state of the art: the role of the coordinator is minimised, strengthing the protocol by removing the previous vulnerabilities and making it resistant to malicious miners.

Information propagation[DW18] is an essential part of any blockchain, and gossiping transactions to neighbouring miners is one of its key features. In the new incentive-protocol protocol, we require that any broadcasted/gossiped/propagated transaction gets acknowledged with a signed receipt to its sender: then, senders must attach these receipts to the consensus leaders and verification nodes in order to ease detection of defective and/or cheating miners. Miners who were gossiped transactions but didn’t participate are considered defective, and not rewarded. In other words, the signed receipts serve as snitches that denounce non-cooperative miners thus preventing that any reward gets assigned to them: at the same time, all miners are incentivised to participate in the denunciation in order to gain the rewards of non-cooperative miners and other free-riders.

function ShardTransactionsAssignment {         } function GossipTransaction {    GossipTransaction()    = AcknowledgeTransmission()    Store } function ReceiveTransaction {    =ReceiveTransaction()    ReplyTransaction(sign(hash())) } function ShardParticipation {    Verify transactions    Collect lists of for every    =set of verified transactions by remaining cooperative    Consensus on verified transactions    Sign BFT agreement result    return signature, agreed block’s header } function VerificationAndRewards {    Verify cooperation of using lists of    Send rewards to cooperative using (LABEL:5.1) } Algorithm 2 Improved Incentive-Compatible Protocol on a Shard-Based Blockchain

In order to save bandwidth, note that it’s not obligatory to send the full list of all signed transaction receipts to consensus leaders and/or verification nodes: only a random subset per each miner should be enough to catch defective miners.

Additionally, the absence of signed receipts could be used to detect the need of a change of a consensus leader (i.e., “view-change”) in BFT protocols[KJG16, KKJG17].

5.2 On Strictly Dominant Cryptocurrencies

A cryptocurrency using Zero-Knowledge Proof-of-Identity as the Sybil-resistance mechanism strictly dominates PoW/PoS cryptocurrencies: a miner having to choose between mining different cryptocurrencies, one with no costs associated with its Sybil-resistance mechanism and distributing equally the rewards, and the others using costly PoW/PoS and thus featuring mining concentration, will always choose the first one. That is, mining equally distributed cryptocurrencies using Zero-Knowledge Proof-of-Identity is a dominant strategy; in other words, the strategy of mining Bitcoin and other similar cryptocurrencies is strictly dominated by the hereby described cryptocurrency. Ceteris paribus, this cryptocurrency will have better network effects, thus better long-term valuation.

5.2.1 Strictly Dominant Cryptocurrencies and a Nash Equilibrium

The intuition behind the preference to mine fully decentralised cryptocurrencies with the lowest expenditure (i.e., lowest CAPEX/OPEX implies higher profitability), thus the search for better hash functions[CLC17, ACP16, BDK15, BCGS16], is formally proved here and then applied to the specific case of the proposed cryptocurrency.

Definition 8.

(Power-Law Fee-Concentrated (PLFC) cryptocurrency). A cryptocurrency whose distribution of mining and/or transaction fees follows a power-law (i.e., a few entities earn most of the fees/rewards), usually due to the high costs of its Sybil-resistance mechanism.

Example 9.

Proof-of-Work cryptocurrencies are Power-Law Fee-Concentrated: 90% of the mining power is concentrated in 16 miners in Bitcoin and 11 in Ethereum[GBE18].

Proof-of-Stake cryptocurrencies are Power-Law Fee-Concentrated: miners earn fees proportional to the amount of money at stake, and wealth is Pareto-concentrated[Par14].

Definition 10.

(Uniformly-Distributed Capital-Efficient (UDCE) cryptocurrency). A cryptocurrency whose distribution of mining and/or transaction fees is uniformly distributed among all the transaction processing nodes, and doesn’t require significant investments from the participating miners.

Example 11.

The proposed cryptocurrency using Zero-Knowledge Proof-of-Identity is a Uniformly-Distributed Capital-Efficient cryptocurrency.

Definition 12.

(Game of Rational Mining of Cryptocurrencies). A rational miner ranks the cryptocurrencies according to their expected mining difficulty, and chooses to mine those with lowest expected difficulty.

Example 13.

Awesome Miner[Min18a], MinerGate[Min18b], MultiMiner[Mul18a], MultiPoolMiner[Mul18b], Smart-Miner[SM19, CBGL19] and NiceHash Miner[Nic18] are practical implementations of the Game of Rational Mining of Cryptocurrencies (although also considering their prices in addition to their difficulties).

Let be the payoff or utility function for each miner, expressing his payoff in terms of the decisions or strategies of all the miners,

whese are set of the strategies of the rest of miners,

Definition 14.

A strategy strictly dominates a strategy for miner if and only if, for any that miner ’s opponents might use,

That is, no matter what the other miners do, playing is strictly better than playing for miner . Conversely, we say that the strategy is strictly dominated by : a rational miner would never play a strictly dominated strategy.

Definition 15.

A strategy is a strictly dominant strategy for miner if and only if, for any profile of opponent strategies and any other strategy that miner could choose,

We now demonstrate that mining UDCE crypto-cryptocurrencies 10 is a strictly dominant strategy with regard to PLFC cryptocurrencies 8 in the Game of Rational Mining of Cryptocurrencies 12 by showing that every miner’s expected profitability is higher in UDCE cryptocurrencies.

Theorem 16.

UDCE cryptocurrencies yield a strictly higher miner’s expected profitability compared to PLFC cryptocurrencies in the Game of Rational Mining of Cryptocurrencies.

Proof.

Let be the number of miners and the average daily minted reward per day: UDCE cryptocurrencies award an average of units of cryptocurrency to every participant miner. For every miner on the long tail of the power distribution, the amount earned with UDCE cryptocurrencies is obviously higher than with PLFC cryptocurrencies. For the few miners that dominate PLFC cryptocurrencies, their profitability is lower because they have to account for the energy[KT18] and equipment costs in the case of PoW cryptocurrencies or the opportunity cost of staking capital in volatile PoS cryptocurrencies[Dia19], meanwhile in UDCE cryptocurrencies their cost of mining is so negligible compared to PLFC cryptocurrencies that the balance of profitability is always tipped in their favour.∎

Definition 17.

The process to solve games called Iterated Deletion of Strictly Dominated Strategies (IDSDS) is defined by the next steps:

  1. For each player, eliminate all strictly dominated strategies.

  2. If any strategy was deleted during Step 1, repeat Step 1. Otherwise, stop.

If the process eliminates all but one unique strategy profile , we say it is the outcome of iterated deletion of strictly dominated strategies or a dominant strategy equilibrium.

Definition 18.

A strategy profile is a Pure-Strategy Nash Equilibrium (PSNE) if, for every player and any other strategy that player could choose,

Definition 19.

A strategy profile is a Strict Nash Equilibrium (SNE) if, for every player and any other strategy that player could choose,

Additionally, if a game is solvable by Iterated Deletion of Strictly Dominated Strategies, the outcome is a Nash equilibrium.

Theorem 20.

A UDCE cryptocurrency dominating PLFC cryptocurrencies is a Nash equilibrium.

Proof.

Mining a UDCE cryptocurrency is a strictly dominant strategy with regard to other miners mining PLFC cryptocurrencies because PLFC cryptocurrencies are strictly dominated by UCDE cryptocurrencies by Theorem 16, thus a rational miner will always prefer to miner the latter.

Thus, by the application of Iterated Deletion of Strictly Dominated Strategies (IDSDS) to the Game of Rational Mining of Cryptocurrencies 12, each miner will eliminate mining PLFC cryptocurrencies in favor of mining an UDCE cryptocurrency, leaving this as the unique outcome: therefore, mining a UDCE cryptocurrency is a dominant strategy equilibrium by Definition 17 and a Nash equilibrium by Definition 18 or by Definition 19.∎

Claim 21.

(Uniqueness of Technical Solution). The proposed technical solution using Zero-Knowledge Proof of Identity from trusted public certificates (i.e., national identity cards and/or ePassports) is the only practical and unique solution for a UCDE cryptocurrency.

Proof.

As demonstrated in the paper describing “The Sybil Attack”[Dou02], Sybil attacks are always possible unless a trusted identification agency certifies identities.

As National Identity Cards and ePassports are the only globally available source of trusted cryptographic identity (3.5B for National Identity Cards and 1B for ePassports), the only way to bootstrap a UCDE cryptocurrency is by using the proposed Zero-Knowledge Proof-of-Identity from trusted public certificates (National Identity Cards and/or ePassports). ∎

5.2.2 Strictly Dominant Cryptocurrencies and Evolutionary Stable Strategies

Another interesting viewpoint to consider in the analysis of the cryptocurrency market is the one offered by behavioural ecology and its Evolutionary Stable Strategies 22

: each cryptocurrency can be considered a unique individual in a population, genetically programmed to play a pre-defined strategy. New cryptocurrencies are introduced into the population as individuals with different mutations that define their technical features (e.g., forking the code of a cryptocurrency to change the hashing algorithm, or a zk-PoI cryptocurrency). An Evolutionary Stable Strategy

22 is a strategy that cannot be invaded by any alternative strategy, that is, it can resist to the invasion of a mutant and it’s impenetrable to them: once it’s introduced and becomes dominant in a population, natural selection is sufficient to prevent invasions from new mutant strategies.

Definition 22.

The pure strategy is an Evolutionary Stable Strategy[Joh73] if there exists such that:

for all possible deviations and for all mutation sizes . There are two conditions for a strategy to be an Evolutionary Stable Strategy: for all either

  1. , that is, it’s a Strict Nash Equilibrium 19, or,

  2. if then

Theorem 23.

Mining a UDCE cryptocurrency is an Evolutionary Stable Strategy.

Proof.

Since mining a UCDE cryptocurrency is a strictly-dominant strategy and a Strict Nash Equilibrium 20, then it is an Evolutionary Stable Strategy because it fulfills its first condition 22.

Additionally, mining a UCDE cryptocurrency based on the global network of National Identity Cards and ePassports is an Evolutionary Stable Strategy over national variants/mutants due to Claim 21. ∎

Thus, the Game of Rational Mining of Cryptocurrencies 12 is a “survival of the fittest” ecology, where the cheapest cryptocurrency to mine offering the higher profits rises above the others.

5.2.3 Obviating the Price of Crypto-Anarchy

The most cost efficient Sybil-resistant mechanism is the one provided by a trusted PKI infrastructure[Dou02] and a centralised social planner would prefer the use of National Identity Cards and/or ePassports in order to minimise costs: instead, permissionless blockchains are paying very high costs by using PoW/PoS as Sybil-resistant mechanisms. In this paper, Zero-Knowledge Proof-of-Identity is introduced as a compromise solution between both approaches, thus obtaining a very efficient Sybil-resistant mechanism with the best of both worlds.

In order to measure how the efficiency of a Sybil-resistant mechanism degrades due to the selfish behaviour of its agents (i.e., a fixed amount of block reward to be distributed among a growing and unbounded number of miners paying high energy costs, as in Bitcoin), we compare the ratio between the worst Nash equilibrium and the optimal centralised solution, a concept known as Price of Anarchy in game theory because it bounds and quantifies the costs of the selfish behavior of the agents.

Definition 24.

The Price of Anarchy[KP99]. Consider a game defined as a set of players , strategy sets for each player and utilities (where are also called the set of outcomes). Define a measure of efficiency of each outcome that we want to minimise, , and let be the set of strategies in Nash equilibria. The Price of Anarchy is given by the following ratio:

The competition game between several blockchains and their cryptocurrencies can be reformulated[ARMM18] as a congestion game[Ros73, DM96] (hereby included for completeness), more amenable to the formulations commonly used for analyzing the Price of Anarchy (the necessity for the following definitions is already intuited in the Discussion of [AH19]): as the number of miners increases, it also exponentially decreases the chance that a given miner wins the block reward by being the first to solve the mining puzzle (i.e., the system becomes increasingly congested); it has been proved that free entry is solely responsible for determining the resource usage[MGT18], and that the difficulty is not an instrument that can regulate it.

Miners, mining servers and crypto-currencies

Denote by the finite set of miners that alter the utilities of other miners if any of them change strategies and let be the set of cryptocurrencies, each associated to exactly one puzzle that miners are trying to solve. Let denote the set of Edge computing Service Providers (ESPs), or mining servers used to offload the costly computational processing.

Strategies

Let

denote the set of ordered pairs (cryptocurrency, ESP) corresponding to ESPs that miner

can rely on to solve the puzzles of a given cryptocurrency. A strategy for miner is denoted by corresponding to the cryptocurrency (puzzle) which a miner intends to solve using a given infrastructure. A strategy vector produces a load vector , where denotes the number of users mining blockchain at ESP .

Rewards, costs, and utilities

Let be the load of miners across all ESPs towards cryptocurrency Then,

For a given load vector , the time to solve the puzzle of the

cryptocurrency is exponentially distributed with expectation

. Let be the probability that puzzle is solved by time ,

The probability that a given miner using ESP is the first to solve puzzle is

where equals 1 if condition holds and 0 otherwise. For simplification, subscript can be dropped and we consider a single ESP. Then, the probability that a miner is the first to solve the puzzle is

Let denote the utility to a miner who tries to find the solution of the current puzzle associated to cryptocurrency using ESP and denote the cost of mining blockchain at ESP :

and the utility of a tagged miner to mine a cryptocurrency when there are miners associated with the same cryptocurrency is