BR112020012449A2 - fast and resilient block chains to partition - Google Patents

Abstract

It is a transaction system in which transactions are organized in blocks, in which a new Br block of valid transactions is built, with respect to a sequence of previous blocks B0, ..., Br-1, making an entity determines a quantity Q from the previous blocks, causing an entity to use a secret key in order to compute a line S solely associated with Q and the entity, causing the entity to compute, from S, a quantity T which is one of: S by itself, a function of S and / or a hash value of S, causing the entity to determine the possibility of T having a certain property and, if T has a certain property, causing the entity digitally signs a hash value H of Br and makes S, Br available and a digitally signed version of H, where Br can be proposed at different stages of cycle r and can be proposed again multiple times during cycle r, and an entity can check a hash value H of u block B regardless of whether the entity has received B.

Description

Descriptive report of the invention patent for “QUICK AND RESILIENT BLOCK CHAINS TO PARTITION”

CROSS REFERENCE TO RELATED ORDERS

[0001] This application claims the priority of Provisional Patent Application No. US 62 / 607,558, filed on December 19, 2017, and entitled FASTER BYZANTINE AGREEMENT IN PROPAGATION NETWORKS WITH> 2/3 HONEST MAJORITY, and Provisional Patent Application No. US 62 / 632,944, filed on February 20, 2018, and entitled ALGORAND, and Provisional Patent Application No. US 62 / 643,331, filed on March 15, 2018, and entitled INCENTIVES AND TRANSACTION FEES IN ALGORAND, and the Application for Provisional Patent No. 62 / 777,410, filed on December 10, 2018, and entitled VIRTUAL BLOCKCHAIN PROTOCOLS FOR FAIR ELECTRONIC EXCHANGE, and Provisional Patent Application No. 62 / 778,482, filed on December 12, 2018, and entitled VIRTUAL BLOCKCHAIN PROTOCOLS FOR FAIR ELECTRONIC EXCHANGE, which are all incorporated by reference into this document.

TECHNICAL FIELD

[0002] This request refers to the field of electronic transactions and, more particularly, to the field of distributed public reasons, which ensure the contents of sequence of transaction blocks and the verification of electronic payments.

BACKGROUND OF THE INVENTION

[0003] A chain of blocks consists of an expandable sequence of blocks: B1, B2,. . . , where each block consists of a number of transactions, the hash of the previous block, and other data — for example, the block index, timing information, etc. Useful properties of a chain of blocks are that (P1) there is a single block that corresponds to each index 1, 2,. . . , (P2) each user in the system eventually learns the content of each block, (P3) no one can change the content or order of the blocks, and (P4) any valid transaction will eventually enter a block in the chain.

[0004] Users can digitally sign messages, so each user has at least one public key and a corresponding secret key. In a chain of blocks, in general, a person knows the public keys, but not necessarily the user knows who owns it. Consequently, a public key can be identified with its owner.

[0005] Several block chain systems require that a block be certified by enough digital signatures of users in the system. In some systems, such certifying users belong to a fixed set of users. In some other systems they belong to a set with dynamic changes. The latter is preferred, due to the fact that an opponent would have a hard time corrupting a set of dynamic changes, particularly if the set is not only dynamic, but also unpredictable.

[0006] A particularly effective way of selecting a set of users in a verifiable but unpredictable way is the cryptographic election technique that is described in published PCT patent application No. PCT / US2017 / 031037, which is incorporated by reference to this document. Here, a user i belongs to a set of empowered users to act at some stage s during the production of block number r based on the result of a computation that i performs by means of his secret key, with the use of ser, and possibly other entries and other data (for example, the fact that the user has joined the system at least k blocks before block r, for some given integer k). For example, the computation of i may involve digital signature of i, 𝑆𝑖𝑟, 𝑠, from such entries, hashing of 𝑆𝑖𝑟, 𝑠 and checking whether the hash is less than a certain limit t. (In fact, like any other line, a hashed value can be interpreted in some standard way as a number.) In this case, 𝜎𝑖𝑟, 𝑠 = 𝑆𝑖𝑟, 𝑠 is defined as the credential of i for step s on block r . This credential proves to anyone that i is, in fact, authorized to produce a message (preferably signed) 𝑚𝑖𝑟, 𝑠, your vote message, for step s in cycle r, in the process intended to produce block r. In fact, i's digital signatures can be verified by anyone, and anyone can hash a certain amount, and then check the possibility that the result will actually be less than (or equal to) a certain number.

[0007] A chain of blocks works to propagate messages (for example, blocks, transactions, voting messages, digital signatures, etc.). Typically, but not exclusively, messages are propagated by rumors of them in a point-to-point manner, or by means of transfers. Several block chain systems require the propagation network to guarantee the delivery of messages propagated by each honest user to other honest users in a limited delay. Some additionally require that users have (almost) aligned system clocks, so that users propagate messages in a synchronized manner — for example, users enter step 2 in generating block 100 at 11:20 am EST, where messages from votes for this step are delivered at 11h20m05 EST, and users then enter step 3 of block 100. A less stringent and therefore preferable requirement, as imposed by Algorand, is that users' watches have (almost ) the same speed, but the actual times shown on the clocks can be arbitrarily distant from each other. A user starts his own step in the generation of block r based on the messages he received from the propagation network, and finishes it based on messages received and how far his own clock has progressed since he started his step.

[0008] When the propagation network meets this requirement, Algorand guarantees that the adversary cannot prevent the chain of blocks from functioning properly (including obtaining the properties P1 — P4). However, this depends on the opponent not attacking the propagation network by itself. Such attacks include any effort that the adversary can take to breach the delimited message delivery delay to a sufficiently large number of users — for example, by splitting users into two equal-sized groups and controlling the delivery of messages. message channels between them, so that a message propagated by a user in group 1 may have an indefinite delay before reaching any user in group 2.

[0009] It is therefore desirable to weaken this requirement and provide chains of blocks and electronic money systems that do not suffer from the inefficiencies and insecurities of known decentralized approaches.

SUMMARY OF THE INVENTION

[0010] According to the system described in this document, an entity manages a transaction system in which transactions are organized in a sequence of blocks that are certified by digital signatures of a sufficient number of verifiers through the proposition of the entity of a hash of a B 'block that includes new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1, if no r-th block Br has been certified, and by proposing the hash entity of block Br, if the r-th block Br has been verified by a sufficient number of other entities. A block can be certified by the entity only in response to confirming transactions for the block and confirming that the block was built and propagated by an entity in charge of building and propagating the block.

The entity can propose a hash value by digitally signing the hash value to provide a digitally signed version of the hash value and the entity can propagate the digitally signed version of the hash value to a network that includes other entities.

If no rth block Br has been certified, the entity can also digitally sign and propagate block B '. The entity can determine a quantity Q from the previous blocks and can use a secret key to compute a line S solely associated with Q and compute, from S, a quantity T that is S in itself, a function of S and / or a hash value of S and the entity can determine the possibility of proposing a hash value by determining the possibility of T having a certain property.

S can be a signature of Q under a secret entity key, T can be a hash of S and T can have a certain property if T is less than a certain limit.

The entity can be part of a network of entities and a specific entity among the entities can build and propagate the Br block.

The rth block Br can be determined as certified by the entity if the entity receives an indication that at least a predetermined number of entities individually certifies a hash value corresponding to the rth block Br.

In response to the entity receiving the indication that a predetermined number of entities individually certified the rth block Br, the entity can increment r to start adding additional blocks to the block sequence.

A specific entity among the entities can be individually chosen by a predetermined number of entities as a leader.

The rth block Br can be determined as certifiable by the entity if the entity receives an indication that at least a predetermined number of entities individually verifies receipt of an indication that the specific entity among the entities has provided a hash value corresponding to the r - th block Br for each of the predetermined number of entities.

[0011] Additionally in accordance with the system described in this document, an entity manages a transaction system in which transactions are organized in a sequence of certified blocks by receiving, by the entity, a hash value of a Br block from from another entity that generated the block based on new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1, of the certification, by the entity, of the Br block in response to a sufficient number of other entities having indicated the receipt of the hash value of the Br block from the other entity and the hash value to be valid for the Br block, of the generation by the entity of a new block B 'based on new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1 in response to an insufficient number of other entities indicating the receipt of the hash value of the block Br from the other entity, where B 'is different from Br, and of the increment, by the entity, of r to start adding additional blocks to the sequence of blocks in response to the entity receiving the indication that a predetermined number of entities individually certified the rth block Br or a predetermined number of entities individually certified the new block B '. The blocks can be certified by digital signatures. New blocks can be proposed by different entities among the entities until receipt of the indication that a predetermined number of entities has individually certified a previously proposed block. The entity can provide an indication that a new block should be generated in response to the hash value not being valid for block Br. The entity can generate a new block B 'based on new valid transactions with respect to a sequence of blocks B0 certificates,. . . , Br-1 in response to a sufficient number of other entities to provide an indication that a new block should be generated. The entity may provide an indication that the hash value of the Br block must be propagated in response to a sufficient number of other entities to indicate that the hash value of the Br block has been received from the other entity and that the hash value is valid for the Br block. .

[0012] Additionally, according to the system described in this document, an entity verifies a proposed hash value of a new Br block of transactions with respect to a certain sequence of blocks, B0,. . . , Br-1, without access to the new Br block in a transaction system in which transactions are organized in blocks and the blocks are certified by a set of digital signatures when causing the entity to determine a quantity Q of the previous blocks, that the entity compute a digital signature S of Q, cause the entity to compute, from S, a quantity T that is S by itself, a function of S and / or hash value of S, cause the entity determine the possibility of T having a certain property and, if T has a certain property, have the entity check the proposed hash value of the new Br block regardless of confirmation that the proposed hash value corresponds to the new Br block. The entity can propagate the proposed hash value of the new Br block before receiving the new Br block.

[0013] Additionally according to the system described in this document, in a transaction system in which transactions are organized in blocks, a new Br block of valid transactions is constructed, with respect to a sequence of previous blocks B0, B1,. . . , Br-1, when making an entity determine a quantity Q from the previous blocks, make the entity use a secret key in order to compute a line S solely associated with Q, make the entity compute, the from S, a quantity T that is S in itself, a function of S and / or a hash value of S, make the entity determine the possibility of T having a certain property and, if T has a certain property, cause the entity to compute a hash value

H of Br, digitally sign H and make available to others S, Br and a digitally signed version of H. The secret key can be a secret signature key that corresponds to an entity's public key and S is a digital signature of Q by the entity . T can be a binary expansion of a number and satisfy a given property if T is less than a given number p. S can be made available by becoming S deductible from Br. Each user can have a balance in the transaction system and p can vary for each user according to the balance of each user.

[0014] Additionally according to the system described in this document, select a subset of users in a block chain system to check a data line m against a sequence of previous blocks B0,. . . , Br-1, includes making at least some of the users determine a quantity Q from the previous blocks, making at least some of the users compute a digital signature S of Q and other information, making at least some of the users determine a hash value of the digital signature, have at least some of the users compare the hash value to a predetermined limit, and have the subset of users digitally sign m together with other information and make it available to other S and a digitally version signed in response to the hash value being below a predetermined limit for each of the subset of users. The digital signature can be accredited if the hash value is below a predetermined limit. Each user can have a balance in the transaction system and the predetermined limit can vary for each user according to the balance of each user. The predetermined limit for each user can be chosen to make the subset of users contain a minimum number of users. The data line m can be a hash value of a new block Br. The data line m can be verified by at least a certain number of accredited signatures of m.

[0015] Additionally according to the system described in this document, select a subset of users in a block chain system to verify a new block Br with respect to a sequence of previous blocks B0,. . . , Br-1, includes making at least some of the users determine a quantity Q of the previous blocks, making at least some of the users compute a digital signature S of Q and other information, making at least some of the users determining a hash value of the digital signature, make at least some of the users compare the hash value to a predetermined limit, make the subset of the users determine whether Br is valid with respect to B0,. . . , Br-1 in response to the hash value being below a predetermined limit for each of the subset of users and having the subset of users digitally sign a hash value of Br together with other information and make it available to other S and a digitally signed version of H. A specific user among users can digitally sign the new Br block only if the specific user among the users verifies the information provided in the new Br block. Each user can have a balance in the transaction system and the limit predetermined amount can vary for each user according to the balance of each user. The predetermined limit for each user can be chosen to make the subset of users contain a minimum number of users. The Br block can be certified by at least a certain number of H-accredited signatures from users who have determined that Br is valid with respect to B0,. . . , Br-1.

[0016] In addition to the system described in this document, the computer software, provided in a non-transitory, computer-readable medium, includes executable code that implements any of the steps described in this document.

[0017] The present invention does not require the requirement to delay message delivery from the propagation network for the safety of new certification blocks. A new block is first prepared (for example, proposed, propagated and / or agreed upon by at least some users) and is then certified. A user who has received a newly constructed block, a hash value for a new block and / or accredited signatures within a desired time frame proceeds to verify and / or certify the new block. However, we want to certify a new block even when messages propagated on the network can be delayed indefinitely. The certification of a block B ensures that certain valuable properties apply to the block. A typical primary property is to allow a user, even a user who has not participated or observed the preparation of a B block, to determine that B has been added to the block chain, or even that B is the r-th block in the block chain. . Another valuable property (often called termination) ensures that B will not disappear from the block chain, due to a soft-fork, even in the presence of a communication network partition on which the block chain protocol is executed. A network partition can cause users to be separated into multiple groups, with messages propagated from one group that does not reach users in other groups. A partition can be resolved after an indefinite amount of time, after which the network again guarantees message delivery after delimited delays.

[0018] Assuming that a block B was prepared, in any way and in any number of steps. Realizing that a block has been properly prepared requires time and effort, and the verification of various evidences. A B certificate consists of a specified number of digital signatures from users with valid credentials. Such a certificate from B ensures that users who produced such signatures participated in or observed the preparation of B. At least it ensures that if one of the digital signatures on the certificate was produced by an honest user, then that user verified that B was properly prepared.

[0019] In the system described in this document, while a user collects evidence for a block B that is properly prepared as the r-th block in the block chain with respect to previous blocks B0,. . . , Br-1, the user can construct and propose a new block B 'as the rth block in the block chain with respect to B0,. . . , Br-1 if it has evidence that a B certificate was not generated in the system. A user proposes B ', determining a quantity Q from the previous blocks, computing a line S solely associated with Q using a secret key, computing, from S, a quantity T that is S by itself, a function of S and / or a hash value of S, determining the possibility of T having a certain property and, if T has a certain property, computing a hash value H 'of B', digitally signing H 'and making available to other S, B' and a digitally signed version of H '. The secret key can be a secret signature key that corresponds to an entity's public key and S is a digital signature of Q by the entity. T can be a binary expansion of a number and satisfy a given property if T is less than a given number p. S can be made available by making S deductible from B '. Each user can have a balance in the transaction system and p can vary for each user according to the balance of each user.

[0020] In the system described in this document, while a user collects evidence for a block B that is properly prepared as the r-th block in the block chain with respect to previous blocks B0,. . . , Br-1, the user can again propose B as the r-th block in the block chain if it has evidence that a B certificate may have been generated in the system, but was not made available for it. A user can resubmit B without having received B by itself, but instead have received a certain number of digital signatures from users with valid credentials that verify a hash value of B. A user can resubmit B by determining a quantity Q from previous blocks, compute a line S uniquely associated with Q using a secret key, compute from S a quantity T that is S in itself, a function of S, and / or a hash value of S, determine the possibility of T having a certain property and, if T has a certain property, digitally sign a hash value of B and make available to others S and a digitally signed version of H. The secret key can be a security key secret signature that corresponds to an entity's public key and S is a digital signature of Q by the entity. T can be a binary expansion of a number and satisfy a given property if T is less than a given number p. S can be made available by making S deductible from B '. Each user can have a balance in the transaction system and p can vary for each user according to the balance of each user.

[0021] The proposition of new blocks and the proposal again of existing blocks can occur an indefinite number of times during the generation of a r-th block of the block chain and can be carried out by different users. A B block can have more than one certificate generated from different steps. However, during the generation of a r-block of the block chain, one and only one block will have a certificate and, thus, it will be considered by users as the r-block of the block chain.

[0022] The effectiveness of the system described in this document stems from the following facts. First, a user i can check and / or re-propose a hash value of a B block before the user can receive B by itself. Second, a new block B 'can be proposed as the r-

th block before all users can have collected evidence that a previously proposed block B as the rth block does not have a certificate generated in the system. In fact, B 'can be proposed as soon as a user has collected such evidence. Third, a previously proposed B block as the r-th block in the block chain can be proposed again before all users can have collected evidence that a certificate for B may have been generated in the system, but not be available for all. In fact, B can be proposed again as soon as a user has collected such evidence.

[0023] An evidence can consist of a set of accredited signatures properly formed to verify a line of data m. Evidence for different purposes may consist of different numbers of signatures. The security of the system described in this document derives from appropriate choices of predetermined limits that users compare the hash values of their signatures for when checking different data lines, and from adequate choices of numbers of signatures sufficient to form evidence for different purposes . For example, let p be a maximum percentage of malicious users on the system. Typically, malicious users are in a minority - for example, p <1/3. Then, the predetermined limit and the sufficient number of signatures that form a certificate for a block can be chosen so that, with sufficiently high probability, (a) for any possible value of block B, there are n or more accredited signatures from honest users to form a certificate for B and (b) on any B certificate, more than 2/3 of accredited signatures belong to honest users.

[0024] The system described in this document is agnostic about the possibility of ephemeral keys being used in the block chain: when users propose new blocks, re-propose existing blocks or check data lines, users can use long-term secret keys to generate accredited signatures, where keys can be used repeatedly throughout the life of the system, or users can use ephemeral secret keys where a key is used only once, or users can use long-term key combinations and ephemeral keys.

[0025] As part of the system described in this document, a user i may not only have an accredited signature to participate in the generation of a block, but also an accredited signature with a weight (essentially an accredited signature associated with a number of votes) . In fact, the weight of i's credential signing to participate in the generation of a block may depend on how much money i has in the system. In fact, instead of having a single predetermined limit t for all users to participate in block generation, each user i can have his own limit ti which is greater than the upper amount of money i. And a user i may have different limits for participating in block generation in different ways — for example, proposing a new block, proposing a block again, or checking a line of data m of a specific format. For simplicity, but without any desired limitation, the description of the system that treats a user i with an accredited subscription of weight-n as n users, in which each has an accredited subscription (weight-1) will continue.

[0026] Below, after quickly recalling the traditional Algorand system, an example of the preferred modality is provided, without any desired limitation, based on Algorand.

BRIEF DESCRIPTIONS OF THE DRAWINGS

[0027] The modalities of the system described in this document are explained in more detail, according to the figures in the drawings, which are briefly described as follows.

[0028] Figure 1 is a schematic representation of a network and computing stations, according to a modality of the system described in this document.

[0029] Figure 2 is a schematic and conceptual summary of the first stage of the Algorand system, in which a new block of transactions is proposed.

[0030] Figure 3 is a schematic and conceptual summary of the agreement and certification for a new block in the Algorand system.

[0031] Figure 4 is a schematic diagram that illustrates a Merkle tree and an authentication path for a value contained in one of its nodes.

[0032] Figure 5 is a schematic diagram that illustrates the 8 Merkle trees corresponding to its first 8 blocks built in a block tree.

[0033] Figure 6 is a schematic representation of a partitioned network and computing stations, according to a system modality described in this document.

DETAILED DESCRIPTION OF THE VARIOUS MODALITIES

[0034] The system described in this document provides mechanisms to distribute transaction verification and propagation so that no entity is solely responsible for performing calculations to verify and / or propagate transaction information. Instead, each of the participating entities shares in the calculations that are made to propagate the transaction in a verifiable and reliable manner.

[0035] Referring to Figure 1, a diagram 20 shows a plurality of computing workstations 22a to 22c connected to a data network 24, such as the Internet. Workstations 22a through 22c communicate via network 24 to provide distributed transaction verification and propagation, as described in more detail elsewhere in this document. The system can accommodate any number of workstations with the ability to provide the functionality described in this document, as long as workstations 22a through 22c have the ability to communicate with each other. Each of workstations 22a through 22c can independently perform processing to propagate transactions to all other workstations in the system and to verify transactions, as described in more detail elsewhere in this document.

[0036] Figure 2 summarizes diagrammatically and conceptually the first stage of an r cycle in the Algorand system, in which each of some selected users proposes their own candidate for the r-th block. Specifically, the step begins with the users in the system, a,. . . , z, individually goes through the secret cryptographic election process, which decides which users are selected to propose a block, and in which each user selected secretly computes a credential that proves that he is authorized to produce a block. Only users b, d and h are selected to propose a block, and their credentials respectively computed are 𝜎𝑏𝑟, 1, 𝜎𝑑𝑟, 𝑎1 and 𝜎ℎ𝑟, 1. Each selected user i assembles his own proposed block, 𝐵𝑖𝑟, ephemerally signs the same (that is, digitally signs the same with an ephemeral key, as explained later), and propagates to the network together with his own credential. The leader of the cycle is the selected user whose credential has the lowest hash. The Figure indicates the leader as the user d. Thus, its proposed block, 𝐵𝑑𝑟, is the one to be provided as an input to the Binary agreement protocol.

[0037] Figure 3 summarizes diagrammatically and conceptually Algorand's process to obtain the agreement and certify a proposed block as the r-th official block, Br. Since Algorand's first step is to propose a new block, this process begins with the second stage. This step, in fact, coincides with the first step of Algorand's preferred Byzantine settlement protocol, 𝐵𝐴 ∗. Each step of this protocol is performed by a different “committee” of participants, randomly selected by secret cryptographic election (not shown in this Figure). Consequently, the users selected to perform each step can be totally different. The number of de ∗ Steps may vary. Figure 3 depicts an execution of 𝐵𝐴 ∗ that involves 7 steps: from step 2 of Algorand to 8 of Algorand. The users selected to perform step 2 are a, e and q. Each user i ∈ {a, e, q} propagates his credential, 𝜎𝑖𝑟, 2 to the network, which proves that i is, in fact, authorized to send a message in step 2 of Algorand cycle r, and his appropriate message from that step , 𝑚𝑖𝑟, 𝑠, ephemerally signed. Steps 3 through 7 are not shown. In the last step 8, the Figure shows that the selected selected users, b, fex, reached agreement on Br as the official block of cycle r, propagated their own ephemeral signatures of the Br block (together, these signatures certify Br) and their own credentials, showing that they are authorized to act in Step 8.

[0038] Figure 4 schematically illustrates a Merkle tree and one of its authentication paths. Specifically, the Figure

4. A illustrates a complete Merkle tree of depth 3. Each node x, where x is denoted by a binary line of length ≤ 3, stores a value νx. If x has length ≤ 2, then νx = H (νx0, νx1). For the Merkle tree of Figure 4.a, Figure 4.B illustrates the authentication path of the value ν010.

[0039] Figure 5 schematically illustrates the 8 Merkle trees, corresponding to the first 8 blocks built in a block tree, built in a complete binary tree of depth 3. In Figure 5.i, the nodes marked by an integer belong to the Merkle Ti tree. The contents of nodes marked by i (respectively, by i) are temporary (respectively, permanent).

[0040] The description in this document focuses on transactions that are payments and the description of the system in this document as a cash platform. Those skilled in the art will realize that the system described in this document can also manage all types of transactions.

[0041] The system described in this document has a very flexible design and can be implemented in several ways, however related. Its flexibility is illustrated by detailing two possible modalities of its general project. From there, those skilled in the art can also observe how to derive all types of other deployments.

[0042] To facilitate the understanding of the invention, and to allow the internal cross-reference of its various parts, its presentation was organized in numbered and titled sections. The first sections are common for both detailed modalities. 1. INTRODUCTION

[0043] Money has become increasingly virtual. It has been estimated that about 80% of dollars in the United States currently exist only as accounting records. Other financial instruments are the following process.

[0044] In an ideal world, in which you can count on a central entity that is universally trusted, immune to all possible cyber attacks, money and other financial transactions can only be electronic. Unfortunately, we don't live in such a world. Consequently, decentralized cryptocurrencies, like Bitcoin, and “smart contract” systems, like Ethereum, have been proposed. At the heart of these systems is a shared reason that reliably records a sequence of transactions, as varied as there are payments and contracts, in a tamper-proof manner. The technology of choice to guarantee such tamper-proof quality is the block chain. Block chains are behind applications like cryptocurrencies, financial applications and the Internet of Things. Several techniques for managing reasons based on the chain of blocks have been proposed: proof of work, proof of participation, tolerance to practical Byzantine failure, or some combination of them.

[0045] Currently, however, the reasons may be ineffective for management. For example, Bitcoin's proof of work approach requires a vast amount of computing, this is superfluous and insufficiently scalable. Furthermore, it does concentrate power in some hands.

[0046] Therefore, we want to present a new method for implementing a public reason that offers the convenience and effectiveness of a centralized system executed by a trusted and inviolable authority, without the inefficiencies and weaknesses of current decentralized deployments. This approach is called Algorand, due to the fact that algorithmic randomness is used to select, based on the reason constructed so far, a set of verifiers that are in charge of building the next block of valid transactions. Naturally, it is guaranteed that such selections are likely to be immune to manipulation and unpredictable until the last minute, but also that they are ultimately universally clear.

[0047] Algorand's approach is very democratic, in the sense that neither in principle nor in fact it creates different classes of users (such as “mined” and “ordinary users” in Bitcoin). At Algorand, “all power resides in all users”.

[0048] A notable feature of Algorand is that its transaction history can branch out only with a very small probability (for example, one in a trillion, that is, or even 10-18). THE

Algorand can also address some legal and political issues.

[0049] Algorand's approach applies to block chains and, more generally, to any method for generating a tamper-proof block sequence. A new method is actually presented - alternative, and more effective than, block chains - that may be of independent interest.

1.1 BITCOIN ASSUMPTION AND PROBLEMS OF THE TECHNIQUE

[0050] Bitcoin is a very ingenious system and has inspired a lot of subsequent research. However, it is also problematic. Summing up its assumption and underlying technical problems - which are, in fact, shared by essentially all cryptocurrencies that, like Bitcoin, are based on proof of work.

[0051] For this summary, it is sufficient to remember that, in Bitcoin, a user can have multiple public keys of a digital signature scheme, that money is associated with public keys, and that a payment is a digital signature that transfers part of the amount of money from one public key to another. Essentially, Bitcoin organizes all payments processed into a block chain, B1, B2,. . . , where each consists of multiple payments, so that all payments from B1, considered in one order, followed by those from B2, in any order, etc., constitute a sequence of valid payments. Each block is generated, on average, every 10 minutes.

[0052] This sequence of blocks is a chain, due to the fact that it is structured in order to guarantee that any change, even in a single block, penetrates all subsequent blocks, making it easier to locate any change in the payment history. (As will be noted, this is achieved by including a cryptographic hash of the previous one in each block.) Such a block structure is called a block chain.

[0053] Assumption: Most Honest Power

Computational Bitcon assumes that no malicious entity (nor a coalition of coordinated malicious entities) controls most of the computational power destined for block generation. Such an entity, in fact, would have the ability to modify the block chain and thereby rewrite the payment history as desired. In particular, you could make a payment ℘, get the benefits paid, and then “erase” any trace of ℘.

[0054] Technique Problem 1: Computational Residue Bitcoin's proof of work approach to block generation requires an extraordinary amount of computation. Currently, with only a few hundred thousand public keys in the system, the 500 most powerful supercomputers can only gather just 12.8% per cent of the total computing power required by Bitcoin participants. This amount of computing would be greatly increased if significantly more users joined the system.

[0055] Problem of Technique 2: Concentration of Power Currently, due to the amount of exorbitant computing required, a user, who tries to generate a new block using an ordinary desktop computer (not even a cell phone), expects to lose money . In fact, to compute a new block with an ordinary computer, the expected costs of electricity needed to power the computation exceed the expected reward. Only by using clusters of specially assembled computers (which do nothing but "mine new blocks"), does a person expect to make a profit by generating new blocks. Consequently, today there are, in fact, two distinct classes of users: ordinary users, who make only payments, and specialized mining clusters, which only look for new blocks.

[0056] It should therefore not be a surprise that,

recently, the total computing power for block generation is in just five clusters. In such conditions, the assumption that most of the computational power is honest becomes less credible.

[0057] Problem of Technique 3: Ambiguity In Bitcoin, the block chain is not necessarily unique. In fact, its last portion often forks: the chain of blocks can be —for example— B1,. . . , Bk, B'k + 1, B'k +2, according to a user, and B1,. . . , Bk, B "k + 1, B" k + 2, B "k + 3 according to another user. Only after several blocks have been added to the chain, can a person have reasonable assurance that the first k + 3 blocks will be the same for all users, so a person cannot immediately transfer payments in the last block of the chain. It is more prudent to wait and observe the possibility that the block will become deep enough in the block chain and thus stable enough.

[0058] Separately, law enforcement and monetary policy concerns have also emerged regarding Bitcoin.1

1.2 ALGORAND, IN SUMMARY

[0059] Configuration Algorand works in a very rigid configuration. Briefly,

[0060] (a) Environment without permission and with permission. Algorand works effectively and securely even in an environment totally without permission, where arbitrarily many users are allowed to join the system at any time, without any verification or permission of any kind. Evidently, Algorand still works 1O (pseudo) anonymity offered by payments with Bitcoin can be used improperly for money laundering and / or for the financing of criminal individuals or terrorist organizations. Traditional banknotes or gold bars, which in principle offer perfect anonymity, should pose the same challenge, but the physicality of these currencies substantially slows down money transfers in order to allow monitoring to some degree by law enforcement agencies agencies. The ability to “print money” is one of the basic powers of a nation-state. In principle, therefore, the mass adoption of an independently floating currency can hide this power. Currently, however, Bitcoin is far from being a threat to government monetary policies, and due to its scalable problems, it may never be.

best in an environment with permission.

[0061] (b) Very Adversary Environments. Algorand supports a very powerful Opponent, who can

[0062] (1) instantly corrupt any user you want, anytime you want, as long as, in an environment without permission, 2/3 of the money in the system belongs to an honest user. (In an environment with permission, regardless of money, it is enough that 2/3 of users are honest.)

[0063] (2) to fully control and perfectly coordinate all corrupted users; and

[0064] (3) schedule the delivery of all messages, provided that each message sent by an honest user reaches all (or sufficiently many among) honest users in a time λm, which depends solely on the size of m. Main Properties Regardless of the presence of the powerful opponent, at Algorand

[0065] ● The amount of computing required is minimal. Essentially, no matter how many users are present in the system, each of the fifteen hundred users must perform at most a few seconds of computation.

[0066] ● A new block is generated quickly and will never actually leave the block chain. That is, Algorand's chain of blocks can branch out with only insignificant probability (that is, less than one in a trillion or 10-18). In this way, users can transfer payments contained in a new block as soon as the block appears.

[0067] ● All power resides in the users themselves. Algorand is a truly distributed system. In particular, there are no exogenous entities (such as “miners” in Bitcoin), who can control which transactions are recognized.

Algorand Techniques.

[0068] 1. A NEW AND FAST PROTOCOL OF BYZANTINE AGREEMENT. Algorand generates a new block using a Byzantine (BA) binary message passing and inventive cryptographic protocol, 𝐵𝐴 ∗. The 𝐵𝐴 ∗ protocol not only satisfies some additional properties (which will be discussed shortly), but it is also very fast. Briefly, its binary input version consists of a 3-step loop, in which one participant i sends a single message mi to all other participants. Executed in a complete and synchronized network, in which more than 2/3 of the participants are honest, with a probability of> 1/3, after each cycle the protocol ends in agreement. (It should be noted that the 𝐵𝐴 ∗ protocol meets the original definition of the Byzantine agreement, without any weakening.)

[0069] Algorand leverages its binary BA protocol to obtain the agreement, in its different communication model, in each new block. The agreed block is then certified, using a prescribed digital signature number from the appropriate verifiers, and propagated through the network.

[0070] 2. SECRET CRYPTOGRAPHIC ELECTION. Although it is very fast, the ∗ ∗ protocol would benefit from additional speed when run by millions of users. Consequently, Algorand chooses the participants of 𝐵𝐴 ∗ as a much smaller subset of the set of all users. In order to avoid a different type of power concentration problem, each new Br block will be built and agreed upon, through a new execution of 𝐵𝐴 ∗, by a separate set of selected verifiers, SVr. In principle, selecting such a set can be as difficult as selecting Br directly. This potential problem is analyzed through an innovative approach that is called secret cryptographic election. Election is the practice of selecting officers at random from a large set of eligible individuals. (Election has been practiced for centuries: for example, by the republics of Athens, Florence and Venice. In modern judicial systems, random selection is normally used to choose juries. Random sampling has also been recommended for elections.) In a decentralized system Of course, choosing the random coins needed to randomly select the members of each SVr checker set is problematic. In this way, cryptography is used in order to select each set of verifiers, from the population of all users, so that it is guaranteed to be automatic (that is, that does not require any message exchange) and random. Similarly, a user is selected, the leader, in charge of proposing the new Br block, and the SVr verifier set, in charge of obtaining agreement on the block proposed by the leader. The inventive system enhances some information, Qr-1, which is deductible from the contents of the previous block and is non-manipulable even in the presence of a very strong opponent.

[0071] 3. THE QUANTITY (SEED) Qr. The last Br-1 block in the block chain is used to automatically determine the next set of verifier and leader in charge of building the new Br block. The challenge with this approach is that by choosing a slightly different payment in the cycle previous, the powerful Opponent gains enormous control over the next leader. Even if you only controlled 1 / 1,000 of the participants / money in the system, it can guarantee that all leaders are malicious. (See Intuition Section 4.1.) This challenge is central to all evidence-based approaches, and to the best of our knowledge, it has not, so far, been satisfactorily solved.

[0072] To meet this challenge, a separate and carefully defined quantity, Qr, was purposely built, and is continually updated, which is probably not just unpredictable,

but also not influenced by the powerful adversary. Qr can be referred to as the r-th seed, as from Qr that Algorand selects, through secret cryptographic election, all users who will play a special role in the generation of the r-th block. The Qr seed will be deductible from the Br-1 block.

[0073] 4. SECRET CREDENTIALS. The random and unambiguous use of the current current block, Br-1, in order to choose the verifier set and the leader in charge of building the new block, Br, is not enough. Since Br-1 must be known before generating Br, the last non-influenced Qr-1 deductible amount of Br-1 must also be known. Consequently, so should the verifiers and the leader in charge of computing the Br block. In this way, the powerful Adversary can immediately corrupt all of these, before they enter into any discussion about Br, in order to gain complete control over the block that the those certify.

[0074] To prevent this problem, leaders (and fact checkers too) secretly learn their roles, but they can compute an appropriate credential, with the ability to prove to everyone that they do indeed have such a role. When a user confidently realizes that he is the leader for the next block, he first secretly assembles his own proposed new block, and then disseminates the same (so that it can be certified) together with his own credential. Thus, although the Adversary immediately realizes who the leader of the next block is, and although it may corrupt it immediately, it will be too late for the Opponent to influence the choice of a new block. In fact, it cannot “return” the leader's message, just as a powerful government cannot contain a message spread virally through WikiLeaks.

[0075] As will be noted, the uniqueness of the leader cannot be guaranteed, nor that everyone will know who the leader is, including the leader himself! But at Algorand, unambiguous progress will be guaranteed.

[0076] 5. SUBSTITUTION OF PARTICIPANT. After proposing a new block, the leader may also “die” (or be corrupted by the opponent), due to the fact that his work is complete. But for SVr checkers, things are less simple. In fact, to be in charge of certifying the new Br block with a sufficient number of signatures, they must first execute the Byzantine agreement in the block proposed by the leader. The problem is that, no matter how effective it is, ∗ ∗ requires multiple steps and the honesty of> 2/3 of its participants. This is a problem, due to the fact that, for reasons of efficiency, the set of participants of 𝐵𝐴 ∗ consists of the smallest set of SVr randomly selected from the set of all users. In this way, the powerful Opponent, while unable to corrupt 1/3 of all users, can certainly corrupt all members of SVr!

[0077] Fortunately it will be proved that the 𝐵𝐴 ∗ protocol, executed by propagating messages in a point-to-point manner, is a participant substitute. This innovative requirement means that the protocol correctly and effectively obtains consensus even if each of its stages is carried out by an entirely new and randomly selected and independently selected set of participants. Thus, with millions of users, each small set of participants associated with a 𝐵𝐴 ∗ step is more likely to have an empty intersection with the next set.

[0078] In addition, sets of participants from different stages of 𝐵𝐴 ∗ are likely to have totally different cardinalities. Additionally, the members of each set do not know what the next set of participants will be, and do not secretly pass any internal state.

[0079] Replaceable participant ownership is, in fact, crucial to defeating the dynamic and very powerful opponent that is contemplated. It is believed that replaceable participant protocols will prove crucial in different contexts and applications. In particular, they will be crucial to safely execute small sub-protocols incorporated in a larger universe of participants with a dynamic opponent, who, having the ability to corrupt even a small fraction of the total participants, has no difficulty in corrupting all participants in the sub-protocol. smaller.

[0080] An Additional Property / Technique: Indolent Honesty An honest user follows their prescribed instructions, which includes being online and executing the protocol. Since Algorand has only modest computing and communication requirements, being online and executing the protocol “in the background” is not a big sacrifice. Of course, some “absences” among honest participants, such as those due to a sudden loss of connectivity or the need to restart, are automatically tolerated (due to the fact that some participants can always be considered to be temporarily malicious). It should be noted, however, that Algorand can simply be adapted to work on a new model, in which honest users must be offline most of the time. Our new model can be informally introduced as follows.

[0081] Indolent honesty. In short, a user i is indolent, but honest if (1) he follows all of his prescribed instructions, when he is asked to participate for the protocol, and (2) he is asked to participate for the protocol only rarely, and with prior notice proper.

[0082] With such a relaxed notion of honesty, one can be even more confident that honest people will be on hand when needed, and Algorand guarantees that, when appropriate,

[0083] The system operates safely even if, at a certain point in time, most of the participating participants are malicious. 2 PRELIMINARY

2.1 Primitive Cryptography

[0084] Ideal Hashing. An efficient computational cryptographic hash function, H, must be transferred, which arbitrarily maps long lines to fixed-length binary lines. Following an ancient tradition, H is modeled as a random oracle, essentially a function that maps each possible s line to a random and independently selected (and then fixed) binary line, H (s), of the chosen length.

[0085] In our described modalities, H has outputs of 256-bits in length. In fact, such a length is short enough to make the system effective and long enough to make the system safe. For example, H is wanted to be resilient to collision. That is, it must be difficult to find two different lines x and y so that H (x) = H (y). When H is a random oracle with 256-bit long outputs, finding any such pair of lines is indeed difficult. (To try randomly, and to transfer in the birthday paradox would require 2256/2 = 2128 tests.)

[0086] Digital Signature. Digital signatures allow users to authenticate information to each other without sharing any secret keys. A digital signature scheme consists of three fast algorithms: a probabilistic key generator G, a signaling algorithm S and a verification algorithm V.

[0087] Given a security parameter k, a sufficiently high integer, a user i uses G to produce a pair of k-bit keys (ie lines): a "public" key pki and a signaling key " secret "compatible ski. Crucially, a public key does not "betray" its corresponding secret key. That is, even given the knowledge of pki,

none other than i has the capacity to compute ski in less than astronomical time.

[0088] User i uses ski to digitally sign messages. For each possible message (binary line) m, i first mixes m, then executes the S algorithm on the H (m) and ski inputs to produce the k-bit line 𝑠𝑖𝑔𝑝𝑘𝑖 (𝑚) ≜ 𝑆 (𝐻 (𝑚) , 𝑠𝑘𝑖) .2

[0089] The binary line sigpki (m) is called digital signature of i of m (with respect to pki), and can be more simply denoted by sigi (m), when the public key pki is clear from the context.

[0090] Anyone who knows pki can use it to check the digital signatures produced by i. Specifically, in entries (a) the public key pki of a participant i, (b) a message m, and (c) a line s, that is, supposed digital signature of i of message m, the verification algorithm V emits YES or not.

[0091] The required properties of a digital signature scheme are:

[0092] 1. Legitimate signatures are always verified: If s = sigi (m), then V (pki, m, s) = YES; and

[0093] 2. Digital signatures are difficult to falsify: Without knowledge of ski the time to find a line s so that V (pki, m, s) = YES, for a message m never signed by i, is astronomically large .

[0094] (Following strong security requirements, this is true even if a person can obtain the signature of any other message.)

[0095] Consequently, to prevent any other 2 Since H is resilient to collision, it is practically impossible that by signing m a person "accidentally signs" a different m 'message.

person signs messages on his behalf, a participant i must keep his ski subscription key secret (thus the term “secret key”), and to allow anyone to check the messages he signed, i have an interest in publishing your pki key (thus the term “public key”).

[0096] Signatures with Ability to Retrieve Message In general, a message m is not recoverable from its sigi (m) signature. In order to virtually deal with digital signatures that satisfy the conceptually convenient "message recoverability" property (that is, to ensure that the signer and the message are easily computable from a signature, 𝑆𝐼𝐺𝑝𝑘𝑖 (𝑚) = ( 𝑖, 𝑚, 𝑠𝑖𝑔𝑝𝑘𝑖 (𝑚)) and 𝑆𝐼𝐺𝑖 (𝑚) = (𝑖, 𝑚, 𝑠𝑖𝑔𝑖 (𝑚)), if pki is clear.

[0097] Unique Digital Signature. Digital signature schemes (G, S, V) that satisfy the following additional property are also considered.

[0098] 3. Singularity. It is difficult to find lines pk ', m, s, and s' so that s ≠ s 'and V (pk', m, s) = V (pk ', m, s') = 1.

[0099] (Note that the singularity property also maintains pk 'lines that are not legitimately generated public keys. In particular, however, the singularity property implies that if a person used the specific key generator G to compute a public key pk in conjunction with a secret key compatible with sk, and thus knew sk, it would be essentially impossible for him to find two different digital signatures of the same message with respect to pk.)

[00100] ● FROM UNIQUE SIGNATURES FOR VERIFIABLE AND RANDOM FUNCTIONS. With respect to a digital signature scheme with the singularity property, the mapping m → H (sigi (m)) associates with each possible line m, a randomly selected and unique 256-bit line, and the accuracy of this mapping can be provided given the sigi (m) signature.

[00101] That is, the ideal hashing and digital signature scheme that satisfy the singularity property essentially provide an elementary implementation of a verifiable random function (VRF).

[00102] A VRF is a special type of digital signature. VRFi (m) can be written to indicate such a special signature of i in a message m. In addition to satisfying the singularity property, the verifiable random functions produce outputs that are guaranteed to be sufficiently random. That is, VRFi (m) is essentially random, and unpredictable until it is produced. On the other hand, SIGi (m) does not have to be sufficiently random. For example, user i can choose his public key so that SIGi (m) is always a line of k-bits that is (lexicographically) small (that is, whose first bits can always be 0s). It is observed, however, that, since H is an ideal hash function, H (SIGi (m)) will always be a random 256-bit line. In the preferred modalities, digital hashing signatures are used extensively that satisfy the singularity property precisely because they have the ability to associate each message m and each user i with a unique random number. If a person implants Algorand with VRFs, one can replace H (SIGi (m)) with VRFi (m). In particular, a user i does not need to first compute SIGi (m), then H (SIGi (m)) (in order, for example, to compare H (SIGi (m)) with a number p). It can directly compute VRFi (m). In summary, it must be understood that

H (SIGi (m)) can be interpreted as VRFi (m), or as a sufficiently random number, easily computed by participant i, but unpredictable for anyone else, unambiguously associated with i and m.

[00103] ● THREE DIFFERENT NEEDS FOR DIGITAL SIGNATURES. At Algorand, a user i relies on digital signatures to

[00104] (1) Authenticate i's own payments. In this descriptive report, the keys can be “long-term” (that is, used to sign many messages over a long period of time) and result from a common signature scheme.

[00105] (2) Generate credentials that prove that i is authorized to act in some stages of a cycle r. Here, the keys may be long-term, but they must result from a scheme that satisfies the uniqueness property.

[00106] (3) Authenticate the message i sent at each stage in which it operates. Here, the keys must be ephemeral (that is, destroyed after their first use), but they may result from a common signature scheme.

[00107] ● A LOW COST SIMPLIFICATION. For simplicity, it is desired that each user i has a single long-term key. Consequently, such a key must result from a signature scheme with the property of uniqueness. Such simplicity has a small computational cost. Typically, in fact, unique digital signatures are slightly more expensive to produce and verify than ordinary signatures.

2.2 The Idealized Public Registry

[00108] Algorand tries to imitate the following payment system, based on an idealized public record.

[00109] 1. The Initial State. The money is associated with individual public keys (privately generated and owned by users). Be pk1,. . . , pkj as the initial public keys and a1,. . . , aj their respective initial quantities of money units, then, the initial state is S0 = (pk1, a1),. . . , (pkj, aj),

[00110] which is assumed to be common knowledge in the system.

[00111] 2. Payments. Let pk be a public key that currently has ≥ 0 units of money, pk ’as another public key, and a 'as a non-negative number not greater than a. So, a (valid) payment ℘ is a digital signature, with respect to pk, which specifies the transfer of currency units to 'from pk to pk', together with some additional information. In symbols, ℘ = 𝑆𝐼𝐺𝑝𝑘 (𝑝𝑘, 𝑝𝑘 ′, 𝑎 ′, 𝐼, 𝐻 (𝔗)),

[00112] Where I represents any additional information deemed useful but not sensitive (for example, time information and a payment identifier), and 𝔗 any additional information deemed sensitive (for example, the reason for payment, possibly the identities of the owners of the pk and the pk ', and so on).

[00113] Referring to pk (or its owner) as the taxpayer, for each pk '(or its owner) as a beneficiary, and to a' as the payment amount ℘.

[00114] Free Membership Through Payments. It is observed that users can join the system whenever they want, generating their own public key / secret key pairs. Consequently, the public key pk 'that appears in the payment ℘ above may be a newly generated public key that has never “owned” any money before.

[00115] 3. The Magic Record. In the Idealized System, all payments are valid and appear in an L tamper-proof list of payment sets “posted at the top” for everyone to observe: L = PAY1, PAY2,. . . ,

[00116] Each PAYr + 1 block consists of all payments made since the appearance of the PAYr block. In the ideal system, a new block appears after a fixed (or finite) amount of time. Discussion

[00117] ● More General Payments and Outgoing Transaction Not Spent. More generally, if the public key pk has a quantity a, then a valid payment ℘ of pk can transfer the quantities a'1, a'2,. . . , respectively for the keys pk'1, pk'2,. . . , as long as ∑𝑗 𝑎′𝑗 ≤ 𝑎.

[00118] In Bitcoin and similar systems, money owned by a public key pk is segregated in separate amounts, and a payment p made per pk must transfer such segregated amount to in its entirety. If pk wishes to transfer only a fraction a '<a de a to another key, then it must also transfer the balance, the transaction output does not spend, to another key, possibly pk by itself.

[00119] Algorand also works with keys that have segregated quantities. However, in order to focus on the innovative aspects of Algorand, it is conceptually simpler to maintain the simplest forms of payments and keys that have a unique amount associated with them.

[00120] ● Current State. The Idealized Scheme does not directly provide information about the current state of the system (that is, how many units of money each public key has). This information is deductible from the Magic Record.

[00121] In the ideal system, an active user continuously stores and updates the most recent state information, or would otherwise have to reconstruct it, from scratch or from the last time he computed it. (Also, later on it will be shown how to augment Algorand to allow its users to reconstruct the current state effectively.)

[00122] ● Security and “Privacy”. Digital signatures ensure that no person can falsify another user's payment. In a payment ℘, public keys and quantity are not hidden, but sensitive information 𝔗 is. In fact, only 𝐻 (𝔗) appears in ℘, and since H is an ideal hash function, 𝐻 (𝔗) is a random 256-bit value, so there is no way to know which 𝔗 was better simply by guesswork. Also, to prove what the 𝔗 was (for example, to prove the reason for payment) the taxpayer can only reveal 𝔗. The accuracy of the revealed 𝔗 can be verified by computing 𝐻 (𝔗) and comparing the resulting value with the last item of ℘. In fact, since H is resilient to collision, it is difficult to find a second value 𝔗 ′ so that 𝐻 (𝔗) = 𝐻 (𝔗 ′).

2.3 Basic notions and notations

[00123] Keys, Users and Owners Unless otherwise specified, each public key ("key" for short) is long-term and related to a digital signature scheme with the property of uniqueness. A public key i joins the system when another public key j already in the system makes a payment to i.

[00124] As for the color, keys are personified. A key i is referred to as "he", i is considered to be honest, i sends and receives messages, etc. The user is a synonym for key. When it is desired to distinguish a key from the person to whom it belongs, the term “digital key” and “owner” are used respectively.

[00125] Systems Without Permission and With Permission. A system is without permission, if a digital key is free to join at any time and an owner can have multiple digital keys; and otherwise, you have permission.

[00126] Unique Representation Each object in Algorand has a unique representation. In particular, each set {(x, y, z,...): X ∈ X, y ∈ Y, z ∈ Z,. . .} is ordered in a pre-specific way: for example, first lexicographically in x, then in y, etc.

[00127] Same Speed Watches There is no global clock: instead, each user has their own clock. User clocks do not need to be synchronized in any way. Assuming, however, that they have the same speed.

[00128] For example, when it is 24 h, according to the clock of a user i, it may be 2:30 pm according to the clock of another user j, but when it is 24h01, according to the clock i, it will be 2:31 pm according to j clock. In other words, “one minute is the same (sufficient, essentially the same) for all users”.

[00129] Cycles Algorand is organized in logical units, r = 0, 1,. . . , called cycles.

[00130] Superscripts are consistently used to indicate cycles. To indicate that a non-numeric quantity Q (for example, a line, a public key, a set, a digital signature, etc.) refers to a cycle r, simply write Qr. Only when Q is a real number (as opposed to a binary line interpretable as a number), is Q (r) written, so that the symbol r cannot be interpreted as the exponent of Q.

[00131] In the (beginning of a) cycle r> 0, the set of all public keys is PKr, and the system state is (𝑟) 𝑆 𝑟 = {(𝑖, 𝑎𝑖,…) ∶ 𝑖 ∈ 𝑃𝐾 𝑟} , (𝑟)

[00132] where 𝑎𝑖 is the amount of money available for public key i. It is observed that PKr is deductible from Sr, and that Sr can also specify other components for each public key i.

[00133] For cycle 0, PK0 is the set of initial public keys, and S0 is the initial state. Both PK0 and S0 are assumed to be common knowledge in the system. For simplicity, at the beginning of cycle r, they are also PK1,. . . , PKr and S1,. . . , Sir

[00134] In a cycle r, the system state changes from Sr to Sr + 1: symbolically, Cycle r: Sr → Sr + 1.

[00135] Payments At Algorand, users make payments continuously (and disseminate them in the manner described in subsection 2.7). A payment ℘ from a user i ∈ PKr has the same format and semantics as in the Ideal System. Namely, ℘ = 𝑆𝐼𝐺𝑖 (𝑖, 𝑖 ′, 𝑎, 𝐼, 𝐻 (𝔗))

[00136] Payment ℘ is individually valid in a cycle r (it is a payment in cycle r for short) if (1) its quantity is (𝑟) less than or equal to 𝑎𝑖 and (2) does not appear in any set of PAYr 'official payments to r' <r. (As explained below, the second condition means that ℘ has not yet become effective.

[00137] A set of payments of cycle-r of i is (𝑟) collectively valid if the sum of its quantities is at most 𝑎𝑖.

[00138] Payment Sets A set of payments of cycle r is a set of payments of cycle r so that, for each user i, payments of i in Ƥ (possibly none) are collectively valid. The set of all r-cycle payment sets is ℙ𝔸𝕐 (𝑟). A set of r-cycle payments Ƥ is maximum if no superset of Ƥ is a set of r-cycle payments.

[00139] It is actually suggested that a payment ℘ also specify a cycle 𝜌, ℘ = 𝑆𝐼𝐺𝑖 (𝜌, 𝑖, 𝑖 ′, 𝑎, 𝐼, 𝐻 (𝔗)) and cannot be valid on any cycle outside [ρ, ρ + k], for some fixed non-negative integer k.3

[00140] Official Payment Sets For each cycle r, Algorand publicly selects (in a manner described later) a single set of payments (possibly empty), PAYr, the official payment set for the cycle. (Essentially, PAYr represents the cycle payments that “really” occurred.)

[00141] As in the Ideal System (and Bitcoin), (1) the only way for a new user to enter the system is to be the recipient of a payment that belongs to the official PAYr payment set of a given cycle r; and (2) PAYr determines the state of the next cycle, Sr + 1, from that of the current cycle, Mr. Symbolically, PAYr: Sr → Sr + 1.

[00142] Specifically,

[00143] 1. the set of public keys of cycle r + 1, PKr + 1, consists of the union of PKr and the set of all beneficiary keys that appear, for the first time, in PAYr payments; and

[00144] 2. The amount of money ai (r + 1) that a user i has in cycle r + 1 is the sum of ai (r) —that is, the amount of money i owned in the previous cycle (0 if i ∉ PKr) - and the sum of amounts paid there, according to PAYr payments.

[00145] In summary, as in the Ideal System, each Sr + 1 state is deductible from the previous payment history: PAY0,. . . , PAYr.

2.4 Proven Blocks And Blocks 3 This simplifies the verification of the possibility that p has become “effective” (that is, it simplifies the determination of the possibility of some PAYr payment set containing ℘. When k = 0, if ℘ = 𝑆𝐼𝐺𝑖 (𝑟, 𝑖, 𝑖 ′, 𝑎, 𝐼, 𝐻 (𝔗)) and ℘ ∉ PAYr, then i must again submit ℘.

[00146] In Algorand0, the Br block that corresponds to a cycle r specifies: r by itself; the set of payments in cycle r, PAYr; an amount 𝑆𝐼𝐺ℓ𝑟 (𝑄 𝑟 − 1), to be explained and the hash of the previous block, H (Br-1). Thus, starting from some fixed block B0, we have a traditional block chain: 𝐵1 = (1, 𝑃𝐴𝑌1, 𝑆𝐼𝐺ℓ1 (𝑄0), 𝐻 (𝐵0)), 𝐵2 = (2, 𝑃𝐴𝑌 2, 𝑆𝐼𝐺ℓ2 (𝑄1 ), 𝐻 (𝐵1)),. . .

[00147] At Algorand, the authenticity of a block is really proven by a separate piece of information, a “certified block” CERTr, which turns Br into a proven block, ̅̅ 𝐵̅̅𝑟. The Magic Record, therefore, is implemented by the sequence of the proven blocks, ̅̅̅1̅, 𝐵 𝐵 ̅̅̅̅2,…

[00148] Discussion As will be noted, CERTr consists of a set of digital signatures for H (Br), those of most SVr members, together with proof that each of such members, in fact, belongs to SVr. You can, of course, include CERTr certificates in the blocks themselves, but it turns out that it is conceptually clearer to keep them separate.)

[00149] In Bitcoin each block must satisfy a special property, that is, it must “contain a crypto-enigma solution”, which makes the block generation computationally intensive and forks both inevitably and in common. On the other hand, Algorand's block chain has two main advantages: they are generated with minimal computation, and will not branch out with excessively high probability. Each Bi block is surely final as soon as it enters the block chain.

2.5 Acceptable Probability of Failure

[00150] To analyze Algorand's security, specify the probability, F, with which one is willing to accept that something may be wrong (for example, that an SVr verifier set does not have an honest part). As in the case of the output length of the cryptographic hash function H, also F is a parameter. But, as in such a case, it is considered useful to set F to a concrete value, in order to obtain a more intuitive understanding of the fact that it is, in fact, possible, at Algorand, to enjoy sufficient security and sufficient efficiency simultaneously. To emphasize that F is the parameter that can be the set, as desired, in the first and second modalities, respectively, F = 10-12 and F = 10-18 are configured.

[00151] Discussion It is noted that 10-12 is, in fact, less than one in a trillion, and it is believed that such a choice of F is appropriate in our order. It is emphasized that 10-12 is not the probability that the Adversary can falsify an honest user's payments. All payments are digitally signed, so if the proper digital signatures are used, the likelihood of falsifying a payment is much less than 10-12, and it is, in fact, essentially 0. The unfavorable event that is set to tolerate with probability F is that the Algorand block chain forks. It is observed that, with the configuration of F and cycles lasting one minute, it is expected that a bifurcation will occur in Algorand's block chain as infrequently as (approximately) once every 1.9 million years. On the other hand, in Bitcoin, a fork often occurs.

[00152] A more demanding person can set F to a lower value. For this purpose, in the second modality, the establishment of F to 10-18 is considered. It is observed that, assuming that a block is generated every second, 1018 is the estimated number of seconds taken by the Universe so far: from the Big Bang to the present time. Thus, with F = 10-18, if a block is generated in one second, one must wait for the age of the Universe to observe the bifurcation.

2.6 The Opponent Model

[00153] Algorand is designed to be safe in a very adversarial model. Let’s explain.

[00154] Honest and Malicious Users A user is honest if he follows all his protocol instructions, and is perfectly capable of sending and receiving messages. A user is malicious (that is, Byzantine, in the language of distributed computing) if he can deviate arbitrarily from his prescribed instructions.

[00155] The Adversary The Adversary is an effective algorithm (technically polynomial time), personified by color, that can immediately make malicious any user you want, at any time you want (subject only to an upper limit for the number of users that can even corrupt).

[00156] Adversary fully controls and perfectly coordinates all malicious users. It performs all actions on their behalf, including receiving and sending all their messages, and may allow them to deviate from their prescribed instructions in arbitrary ways. Or it can simply isolate a corrupted user who sends and receives messages. It is clarified that no one else automatically learns that a user i is malicious, although the malice of i can transpire through the actions that the Opponent did with what he did.

[00157] This powerful opponent, however,

[00158] ● It does not have unlimited computational power and cannot successfully falsify the digital signature of an honest user, except with insignificant probability; and

[00159] ● It cannot interfere in any way with the exchange of messages between honest users.

[00160] Additionally, this ability to attack honest users is limited by one of the following assumptions.

[00161] Most Honesty of Money Considered

a continuation of the Most Honest Money (HMM) assumptions: namely, for each non-negative integer number k and real h> 1/2,

[00162] HHMk> h: honest users in each cycle r had a fraction greater than h of all the money in the system in cycle r - k.

[00163] Discussion. Assuming that all malicious users coordinate their actions perfectly (as if controlled by a single entity, the Adversary) is a very pessimistic hypothesis. Perfect coordination between many individuals is difficult to achieve. Perhaps coordination only takes place in separate groups of malicious participants. But, since you can't be sure about the level of coordination that malicious users can enjoy, it's best to be safe.

[00164] Assuming that the Adversary can secretly, dynamically and immediately corrupt users is also pessimistic. After all, realistically, taking complete control of a user's operations should take time.

[00165] The assumption of HMMk> h implies, for example, that if a cycle (on average) is deployed in one minute, then most of the money in a given cycle will remain in honest hands for at least two hours, if k = 120, and at least one week, if k = 10,000.

[00166] It is observed that the previous HMM assumptions and the Most Honest Part of Computational Power assumptions are related in the sense that, since the computing power can be taken with money, if malicious users have most of the money , then, they can obtain most of the computing power.

2.7 The Communication Model

[00167] It is desired that the message propagation - that is,

“Point-to-point rumor” 4— is the only means of communication, and it is assumed that all messages propagated will reach almost all honest users immediately. Assuming essentially that each message propagated by the honest user reaches, in a certain amount of time depending on the length of the message, all honest users. (It is actually sufficient that it reaches a sufficiently high percentage of honest users.) 3 The 𝑩𝑨 ∗ Protocol In A Traditional Configuration

[00168] As already emphasized, the Byzantine agreement is a key ingredient of Algorand. In fact, it is through the use of such a BA protocol that Algorand is not affected by bifurcations. However, to be safe against the powerful Opponent, Algorand must transfer on a BA protocol that satisfies the new participant substitution constraint. In addition, for Algorand to be effective, such a BA protocol must be very effective.

[00169] BA protocols were first defined for an idealized communication model, complete synchronized networks (SC networks). Such a model allows for a simpler design and analysis of BA protocols. Consequently, in this section, a new BA protocol, 𝑩𝑨 ∗, is introduced for SC networks that ignores the problem of substitution of participant as a whole. The 𝑩𝑨 ∗ protocol is a separate value contribution. In fact, it is the most effective cryptographic BA protocol for SC networks known to date.

[00170] To use the same in the Algorand protocol, 𝑩𝑨 ∗ was modified a little, in order to consider the different communication model and context.

[00171] We started by remembering the model in which 𝑩𝑨 ∗ operates 4Essentially, as in Bitcoin, when a user propagates a message m, all active users i who receive m for the first time, randomly and independently select a suitably small number of users assets, their “neighbors”, to whom they refer m, possibly even receiving recognition from them. The propagation of m ends when no user receives m for the first time.

and the notion of a Byzantine agreement.

3.1 Complete Synchronized Networks And Compatible Opponents

[00172] In an SC network, there is a common clock, functioning at each time of integer r = 1, 2,. . .

[00173] Every time click r, each participant i 𝑟 instantly and simultaneously sends a single message 𝑚𝑖, 𝑗 (possibly the empty message) to each participant j, includes himself 𝑟. Each 𝑚𝑖, 𝑗 is correctly received at the click of time r + 1 by participant j, together with the identity of sender i.

[00174] Again, in a communication protocol, a participant is honest if he follows all the prescribed instructions, and, otherwise, malicious. All malicious participants are fully controlled and perfectly coordinated by the Adversary, who, in particular, immediately receives all messages addressed to the malicious participants, and chooses the messages they send.

[00175] The Adversary can immediately make any honest user malicious as he wishes at any odd-time click he wishes, subject only to a possible upper limit t for the number of malicious participants. In other words, the Opponent "cannot interfere with messages already sent by an honest user i", which will be delivered as it normally is.

[00176] The Adversary also has the additional ability to instantly observe, at each same cycle, the messages that honest participants currently send, and instantly use that information to choose the messages that malicious participants send at the same time.

3.2 The Concept of a Byzantine Agreement

[00177] The notion of Byzantine agreement may have been first introduced for the binary case, that is, when all initial values consist of a bit. However, it was quickly extended to arbitrary initial values. By a BA protocol, it is intended to mean an arbitrary value one.

[00178] Definition 3.1. In a synchronized network, either Ƥ a protocol of n-participants, whose set of participants is common knowledge among the participants, t is a positive integer so that n ≥ 2t + 1. Ƥ is considered to be an arbitrary value ( respectively, binary; (n, t) - Byzantine agreement protocol with integrity σ ∈ (0, 1) if, for each set of V values that do not contain the special symbol ⊥ (respectively, for V = {0, 1}) , in an execution in which at most t the participants are malicious and in which each participant i starts with an initial value νi ∈ V, all honest participants j are interrupted with probability 1, emitting an value outi ∈ V ∪ {⊥ } in order to satisfy, with probability at least σ, the following two conditions:

[00179] 1. Agreement: There is out ∈ V ∪ {⊥} so that outi = out for all honest participants i.

[00180] 2. Consistency: if, for some value v ∈ V, νi = v for all participants i, then out = v.

[00181] Referring to out as a departure from Ƥ, and each outi as a departure from participant i.

[00182] 3.3 The BA Notation No.

[00183] In BA protocols, a participant is required to count how many participants sent him a certain message at a certain stage. Consequently, for each possible value v that can be sent, 𝑛º𝑖𝑠 (𝑣)

[00184] (or just nºi (v) when s is clear) is the number of participants j from which i received v in step s.

[00185] Remembering that a participant i receives exactly one message from each participant j, if the number of participants is n, then, for all i and s, ∑𝑣 𝑛º𝑖𝑠 (𝑣) = 𝑛.

3.4 The New Binary Protocol 𝑩𝑩𝑨 ∗

[00186] This section presents a new binary BA protocol, 𝑩𝑩𝑨 ∗, which depends on the honesty of more than two thirds of the participants and is very fast: regardless of what the malicious participants may accomplish, each execution of their main loop does not it is only trivially executed, but it also makes participants agree on 1/3 probability.

[00187] In 𝑩𝑩𝑨 ∗, each participant has their own public key of a digital signature scheme that satisfies the unique signature property. Since this protocol is intended to run on a complete synchronized network, there is no need for a participant to sign each of their messages.

[00188] Digital signatures are used to generate a random bit common enough in Step 3. (In Algorand, digital signatures are used to authenticate all other messages as well.)

[00189] The protocol requires a minimum configuration: a common random line r, regardless of the participants' keys. (In Algorand, r is actually replaced by the quantity Qr.)

[00190] The 𝑩𝑩𝑨 ∗ Protocol is a 3-step loop, in which participants repeatedly exchange Boolean values, and different participants can leave this loop at different times. A participant i leaves this loop by propagating, at some stage, a special value 0✱ or a special value 1✱, thus instructing all participants to “pretend” that they respectively receive 0 and 1 from i in all future steps. (Put another way: it is assumed that the last message received by a participant j from another participant i was a bit b. So, at any stage in which he does not receive any message from i, j acts as if i had sent bit b.)

[00191] The protocol uses a ϒ counter, which represents how many times its 3-step loop has been executed. At the beginning of 𝑩𝑩𝑨 ∗, ϒ = 0. (One can think of ϒ as a global counter, but in fact the same is increased for each individual participant each time the loop is executed.)

[00192] There are n ≥ 3t + 1, where t is the maximum possible number of malicious participants. A binary line x is identified with the integer whose binary representation (with possible results 0s) is x; and lsb (x) denotes the least significant bit of x. PROTOCOL 𝑩𝑩𝑨 ∗ (COMMUNICATION) STEP 1. [Stage Currency-Fixed-In-0] Each participant i sends bi.

1.1 𝑆𝑒 𝑛º1𝑖 (0) ≥ 2𝑡 + 1, so i sets bi = 0, sends 0✱, issues outi = 0, and PARA.

1.2 𝑆𝑒 𝑛º1𝑖 (1) ≥ 2𝑡 + 1, so i sets bi = 1.

1.3 Otherwise, i sets bi = 0. (COMMUNICATION) STEP 2. [Step Currency-Fixed-In-1] Each participant i sends bi.

2.1 𝑆𝑒 𝑛º2𝑖 (1) ≥ 2𝑡 + 1, so i sets bi = 1, sends 1✱, issues outi = 1, and PARA.

2.2 𝑆𝑒 𝑛º2𝑖 (0) ≥ 2𝑡 + 1, so i sets bi = 0.

2.3 Otherwise, i sets bi = 1. (COMMUNICATION) STEP 3. [Coin-Genuinely-Launched Step] Each participant i sends bi and 𝑆𝐼𝐺𝑖 (𝑟, ϒ).

3.1 𝑆𝑒 𝑛º3𝑖 (0) ≥ 2𝑡 + 1, so i sets bi = 0.

3.2 𝑆𝑒 𝑛º3𝑖 (1) ≥ 2𝑡 + 1, so i sets bi = 1.

3.3 Otherwise, let Si = {j ∈ N send i an appropriate message in this step 3}, i configure 𝑏𝑖 = 𝑐 ≜ 𝑙𝑠𝑏 (𝑚𝑖𝑚𝑗∈𝑆𝑖 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, ϒ))); increases ϒi by 1; and go back to Step 1.

[00193] Theorem 3.1. Whenever n ≥ 3t + 1, 𝑩𝑩𝑨 ∗ is a binary (n, t) -BA protocol with integrity 1.

[00194] A proof of Theorem 3.1 can be found at https://people.csail.mit.edu/silvio/SelectedScientificPapers / DistributedComputation / BYZANTINEAGREEMENTMADETRIVIA L.15pdf.

3.5 GRADUATED CONSENSUS AND THE GC PROTOCOL

[00195] Recalling, for arbitrary values, a notion of consensus much weaker than the Byzantine agreement.

[00196] Definition 3.2. Let Ƥ be a protocol in which the set of all participants is common knowledge, and each participant i confidentially knows an arbitrary initial value v'1.

[00197] Ƥ is considered to be a consensus protocol (n, t) - graduated if, in all executions with n participants, at most t of which are malicious, every honest participant i interrupts the emission of a value-pair degree (vi, gi), where gi ∈ {0, 1, 2}, in order to satisfy the following three conditions:

1. For all honest participants i and j, | gi - gj | ≤ 1.

2. For all honest participants i and j, gi, gj> 0 ⇒ vi = vj.

3. If v’1 = ... = v’n = v for some value v, then vi = v and gi = 2 for all honest participants i.

[00198] The following two-step GC protocol is a graduated consensus protocol in the literature. To make the Algorand'1 protocol steps in section 4.1 compatible, GC steps 2 and 3 are respectively named. (In fact, the first stage of Algorand'1 refers to something else: namely, to propose a new block.)

GC PROTOCOL

[00199] STEP 2. Each participant i sends v'i to all participants.

[00200] STEP 3. Each participant i sends line x to all participants if and only if 𝑛º2𝑖 (𝑥) ≥ 2𝑡 + 1.

[00201] DETERMINATION OF OUTPUT. Each participant i issues the pair (vi, gi) computed as the following: ● If, for some x, 𝑛º3𝑖 (𝑥) ≥ 2𝑡 + 1, then vi = x and gi = 2. ● If, for some x, 𝑛º3𝑖 ( 𝑥) ≥ 𝑡 + 1, then νi = x and gi = 1. ● Otherwise, νi = ⊥ and gi = 0.

[00202] Since the GC protocol is a protocol in the literature, it is known what the following theorem refers to.

[00203] Theorem 3.2. If n ≥ 3t + 1, then GC is a graduate (n, t) -diffusion protocol.

3.6 THE PROTOCOL 𝑩𝑨 ∗

[00204] The BA protocol of BA ∗ of arbitrary value is now described by means of the binary BA protocol 𝑩𝑩𝑨 ∗ and the graduated GC consensus protocol. Below, the initial value of each participant i is v'i. PROTOCOL 𝑩𝑨 ∗ STEPS 1 AND 2. Each participant i performs GC, at entry v'i, in order to compute a pair (νi, gi). STEP 3,. . . Each participant i executes 𝑩𝑩𝑨 ∗ - with initial input 0, if gi = 2, and 1, otherwise - in order to compute the outi bit. DETERMINATION OF OUTPUT. Each participant i issues νi if outi = 0, and ⊥, otherwise.

[00205] Theorem 3.3. Whenever n ≥ 3t + 1, 𝑩𝑨 ∗ is a (n, t) -BA protocol with integrity 1.

[00206] Proof. Consistency is first tested, and then the Agreement.

[00207] PROOF OF CONSISTENCY. Assuming that, for some value v ∈ V, v'i = v. Then, by the graduated consensus property 3, after the execution of the KM, all honest participants issue (v, 2). Consequently, 0 is the starting bit for all honest participants at the end of the execution of ∗ ∗. Thus, by the ownership of the Binary Byzantine Agreement Agreement, at the end of the execution of 𝑩𝑨 ∗, outi = 0 for all honest participants. This implies that the exit of each honest participant i in 𝑩𝑨 ∗ is = v. ⬜

[00208] PROOF OF AGREEMENT. Since 𝑩𝑩𝑨 ∗ is a binary BA protocol, or (A) outi = 1 for every honest participant i, or (B) outi = 0 for every honest participant i.

[00209] In case A, all honest participants issue ⊥ in 𝑩𝑨 ∗ and, thus, the Agreement remains. Case B is now considered. In this case, in the execution of 𝑩𝑩𝑨 ∗, the starting bit of at least one honest participant i is 0. (In fact, if the starting bit of all honest participants is 1, then, by the property of Consistency of 𝑩𝑩𝑨 ∗, would have outj = 1 for all honest j.) Consequently, after the execution of GC, i issues the pair (v, 2) for some value v. Thus, by graduated consensus property 1, gj> 0 for all honest participants j. Consequently, by graduated consensus property 2, vj = v for all honest participants j. This implies that, at the end of 𝑩𝑨 ∗, all honest participants already issue v. Thus, the Agreement also remains in case B. ⬜

[00210] Since both Consistency and the Agreement remain, 𝑩𝑨 ∗ is a BA protocol of arbitrary value. ⬛

[00211] The 𝑩𝑨 ∗ Protocol also works on rumored networks, and, in fact, satisfies the participant substitution property that is crucial for Algorand to be safe in the very adversary model intended.

[00212] The Participant Replacement of 𝑩𝑩𝑨 ∗ and 𝑩𝑨 𝑩𝑨. Some intuition is now provided as to why the 𝑩𝑨 ∗ and 𝑩𝑩𝑨 ∗ protocols can be adapted to run on a network in which communication is carried out through point-to-point rumor, satisfying participant substitution. For concreteness, it is assumed that the network has 10M users and that each step x of 𝑩𝑩𝑨 ∗ (or 𝑩𝑨 ∗) is performed by a committee of 10,000 participants, who were randomly selected through secret cryptographic election, and thus have credentials that prove they are authorized to send messages in step x. Assuming that each message sent at a particular stage specifies the stage number, it is digitally signed by its sender, and includes the credential that proves that its sender is authorized to speak at that stage.

[00213] First of all, if the percentage h of honest participants is sufficiently greater than 2/3 (for example, 75%), then, with immense probability, the committee selected at each stage has the 2/3 of most honest required.

[00214] Furthermore, the fact that the randomly selected committee of 10,000 is changed at each stage does not prevent the correct work of 𝑩𝑩𝑨 ∗ or 𝑩𝑨 ∗. In fact, in any protocol, a participant i in step s only reacts to the multiplicity with which, in Step s - 1, he received a certain message m. Since you are on a rumored network, all messages sent in Step s - 1 will arrive (immediately, for the purpose of this intuition) to all users, including those selected to participate in step s. Due in addition to all messages sent in step s - 1 specifying the step number and including the credential that the sender was, in fact, authorized to speak in step s - 1. Consequently, the possibility that it was also selected in step s - 1 or not, a user i selected to participate in step s is perfectly capable of correctly counting the multiplicity with which he has received a message of correct step s - 1. No matter what the possibility of having participated at all stages so far or not. All users are “in the same boat” and can therefore be easily replaced by other users. 4 Two Algorand Modalities

[00215] As discussed, at a very high level, an Algorand cycle proceeds ideally as follows. First, a randomly selected user, the leader, proposes and circulates a new block. (This process includes initially selecting a few potential leaders and then ensuring that, at least a good fraction of the time, a single common leader will emerge.) Second, a committee of randomly selected users is selected, and obtains the Byzantine agreement in the block proposed by the leader. (This process includes that each step of the BA protocol is performed by a separately selected committee.) The agreed block is then digitally signed by a certain limit (TH) of committee members. These digital signatures are propagated so that everyone is assured of what the new block is. (This includes circulating the signers' credentials, and authenticating only the hash of the new block, ensuring that everyone is guaranteed to learn the block, once their hash is clear.)

[00216] In the next two sections, two modalities of the basic design of Algorand are presented, Algorand'1 and Algorand'2, which respectively work under an assumption of a larger adequate of honest users. Section 7 showed how to adopt these modalities to work under an assumption of an honest majority of money.

[00217] Algorand'1 only predicts that> 2/3 of the committee members are honest. In addition, at Algorand'1, the number of steps to obtain the Byzantine agreement is capped by a suitably high number, so that the agreement is guaranteed to be reached with immense probability in a fixed number of steps (but potentially requiring time) greater than the steps of Algorand'2). In the remote case where the agreement is not reached by the last step, the committee agrees on the empty block, which is always valid.

[00218] Algorand'2 predicts that the number of honest members on a committee is always greater than or equal to a fixed limit tH (which guarantees that, with immense probability, at least 2/3 of the committee members are honest). In addition, Algorand'2 allows the Byzantine agreement to be reached in an arbitrary number of steps (but potentially in a shorter time than Algorand'1).

[00219] Those skilled in the art will realize that many variants of these basic modalities can be derived. In particular, it is easy, given Algorand'2, to modify Algorand'1 to allow reaching the Byzantine agreement in an arbitrary number of steps.

[00220] Both modalities share the following core, notations, notions and parameters.

4.1 A Common Core

[00221] Objectives Ideally, for each cycle r, Algorand should satisfy the following properties:

[00222] 1. Perfect Accuracy. All honest users agree with the same Br block.

[00223] 2. Completeness 1. With probability 1, block Br was chosen by an honest user.

[00224] (In fact, a malicious user can always choose a block whose payment set contains payments from only his "friends".)

[00225] Of course, ensuring perfect accuracy in itself is trivial: everyone always chooses the official PAYr payment set to be empty. But in this case, the system would have completeness 0. Unfortunately, ensuring both perfect accuracy and completeness 1 is not easy in the presence of malicious users. Algorand, therefore, adopts a more realistic objective. Informally, by allowing h to denote the percentage of users who are honest, h> 2/3, Algorand's goal is to

[00226] Guarantee, with immense probability, perfect accuracy and completeness close to h.

[00227] Prioritizing accuracy over completeness seems like a reasonable choice: payments not processed in one cycle can be processed in the next, but one should avoid forks, if possible.

[00228] Resulting Byzantine Agreement Disregarding time and excessive communication for a moment, Perfect accuracy can be guaranteed as follows. At the beginning of cycle r, each user i proposes his own candidate block 𝐵𝑖𝑟. Then, all users reach the Byzantine agreement in only one of the candidate blocks. As per the introduction, the BA protocol employed requires an honest majority of 2/3 and is participant replaceable. Each of its steps can be performed by a small, randomly selected set of verifiers, which does not share any internal variables.

[00229] Unfortunately, this approach does not work well. This is due to the fact that the candidate blocks proposed by honest users are likely to be completely different from each other. In fact, every honest user sees different payments. Thus, while the payment sets observed by different honest users can have a lot to overlap, it is unlikely that all honest users will build a proposal for the same block. Consequently, consistency, according to the BA protocol, is never limiting, only agreement one is, and thus the agreement can always be reached in ⊥ instead of in a good block.

[00230] Algorand 'avoids this problem as follows. First, a leader for cycle r, ℓr, is selected. Then, ℓr propagates its own candidate block, 𝐵ℓ𝑟𝑟. Finally, users reach the agreement on the block that they actually received from ℓr. Because, whenever ℓr is honest, Perfect Accuracy and Completeness 1 remain, Algorand 'guarantees that ℓr is honest with probability close to h.

[00231] Leader Selection In Algorand’s, the rth block is of the form Br = (r, PAYr, SIGℓr (Qr-1), H (Br-1).

[00232] As already mentioned in the introduction, the Qr-1 quantity is carefully constructed so as to be essentially unmanageable by the very powerful Adversary. (Later in this section, some intuition will be provided as to why this is the case.) At the beginning of a cycle r, all users know the block chain so far, B0,. . . , Br-1, from which they deduce the set of users from each previous cycle: that is, PK1,. . . , PKr-1. A potential leader of cycle r is a user i so that .H (SIGi (r, 1, Qr-1)) ≤ p.

[00233] Let us explain. It is observed that, since the quantity Qr-1 is deductible from the Br-1 block, due to the message recovery capacity property of the underlying digital signature scheme. Additionally, the underlying signature scheme satisfies the uniqueness property. Thus, SIGi (r, 1, Qr-1) is a binary line uniquely associated with i and r. Consequently, since H is a random oracle, H (SIGi (r, 1, Qr-1)) is a random 256-bit long line uniquely associated with i and r. The symbol "." in front of H (SIGi (r, 1, Qr-1)) is the decimal point (in this case, binary), so that 𝑟𝑖 ≜. 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, 1, 𝑄 𝑟 − 1)) is the binary expansion of a random 256-bit number between 0 and 1 uniquely associated with i and r. Thus, the probability that ri is less than or equal to p is essentially p.

[00234] The probability p is chosen so that, with immense probability (that is, 1 - F), at least one potential tester is honest. (If so, p is chosen as the least such probability.)

[00235] It is observed that, since i is the only one with the capacity to compute his own signatures, he alone can determine the possibility of him being a potential verifier of cycle 1. However, revealing his credential itself, 𝜎𝑖𝑟 ≜ 𝑆𝐼𝐺𝑖 (𝑟, 1, 𝑄𝑟 − 1), i can prove to anyone that it is a potential verifier of cycle r.

[00236] The leader ℓr is defined as the potential leader whose hashed credential is less than the hashed credential of all other potential leaders j: that is, 𝐻 (𝜎ℓ𝑟, 𝑠 𝑟, 𝑠 𝑟) ≤ 𝐻 (𝜎𝑗).

[00237] It is observed that, since a malicious ℓr may not reveal his credential, the correct leader of cycle r may never be known, and that, preventing unlikely relationships, ℓr is, in fact, the only leader of cycle r.

[00238] Finally, a last but important detail will be shown: a user i can be a potential leader (and, therefore, the leader) of a cycle r only if it belongs to the system for at least k cycles. This guarantees the inability to handle Qr and all future Q quantities. In fact, one of the potential leaders will actually determine Qr.

[00239] Verifier Selection Each step s> 1 of cycle r is performed by a small set of verifiers, SVr, s. Again, each verifier i ∈ SVr, s is randomly selected from the users already in the system cycles k before r, and again through the special quantity Qr-1. Specifically, i ∈ PKr-k is a verifier on SVr, s, if .H (SIGi (r, s, Qr-1)) ≤ p '.

[00240] Again, only i know the possibility that it belongs to SVr, s, but, if this is the case, it can prove it by displaying its encial, 𝑠 ≜ 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄𝑟 −1)). A verifier i ∈ SVr, s sends a message 𝑚𝑖𝑟, 𝑠, in step s of cycle r, and that message includes its credential 𝜎𝑖𝑟, 𝑠, in order to allow verifiers f in the next step to recognize that 𝑚𝑖𝑟, 𝑠 is a message of legitimate step-s.

[00241] The p 'probability is chosen to ensure that, in SVr, s, allowing the good number to be the number of honest users and bad number to be the number of malicious users, with immense probability of the following two conditions to stay.

[00242] For the Algorand'1 modality: (1) good number> 2 · bad number and (2) good number + 4 · bad number <2 n, where n is the expected cardinality of SVr, s.

[00243] For the Algorand'2 mode: (1) good number> tH and (2) good number + 2 bad number <2tH, where tH is a specified time.

[00244] These conditions imply that, with sufficiently high probability, (a) in the last stage of the BA protocol, there will be at least a certain number of honest participants to digitally sign the new Br block, (b) only one block per cycle can have the required number of signatures, and (c) the BA protocol used has (at each stage) the most honest 2/3 required.

[00245] Generation of Clarification Block If the leader of cycle-r ℓr is honest, then the corresponding block is of the form 𝐵𝑟 = (𝑟, 𝑃𝐴𝑌 𝑟, 𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1)),

[00246] where the PAYr payment set is maximum, (remember that all payment sets are, by definition, collectively valid.) Otherwise (that is, if ℓr is malicious), Br has one of the following two Possible forms: 𝐵𝑟 = (𝑟, 𝑃𝐴𝑌 𝑟, 𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1)) and 𝐵𝑟 = 𝐵𝜀𝑟 ≜ (𝑟, ∅, 𝑄𝑟 − 1, 𝐻 (𝐵𝑟 − 1)).

[00247] In the first form, PAYr is a set of payments (not necessarily maximum) and can be 𝑃𝐴𝑌 𝑟 = ∅; and i is a potential leader of cycle r. (However, i may not be the ℓr leader. This may, in fact, occur if ℓr keeps his credential secret and does not reveal himself.)

[00248] The second form appears when, in the execution of the BA protocol cycle, all honest participants issue the default value, which is the empty block 𝐵𝜀𝑟 in the order. (By definition, the possible outputs of a BA protocol include a default value, generically denoted by ⊥. See section 3.2.)

[00249] It is observed that, although payment sets are empty in both cases, 𝐵𝑟 = (𝑟, ∅, 𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1)) and are syntactically different blocks and appear in two different situations: respectively, “everything happened easily enough in the execution of the BA protocol”, and “something went wrong in the BA protocol, and the default value was issued”.

[00250] It is now intuitively described how the generation of the Br block continues in the Algorand 'cycle r. In the first stage, each eligible participant, that is, each participant i ∈ PKr-k, checks the possibility that he is a potential leader. If this is the case, then i is asked to use all the payments it has observed to date and the current block chain, B0,. . . , Br-1, secretly prepare a set of maximum payments, 𝑃𝐴𝑌𝑖𝑟, and secretly join your candidate block, 𝐵𝑟 = (𝑟, 𝑃𝐴𝑌𝑖𝑟, 𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1)). That is, not only does it include 𝐵𝑖𝑟, as its second component, the set of payments just prepared, but also, as its third component, its own signature of Qr-1, the third component of the last block, Br-1. Finally, it propagates its cycle-r step-1 message, 𝑚𝑖𝑟, 1, which includes (a) its candidate block 𝐵𝑖𝑟, (b) its proper signature from its candidate block (ie, its signature from the hash of 𝐵𝑖𝑟 ) and (c) his own credential 𝜎𝑖𝑟, 1, which proves that he is, in fact, a potential verifier of cycle r.

[00251] (Note that until an honest i produces his message 𝑚𝑖𝑟, 1, the Opponent has no idea that i is a potential verifier. If he wants to corrupt potential honest leaders, the Opponent can also corrupt honest participants However, since it observes 𝑚𝑖𝑟, 1, since it contains the credential of i, the Opponent knows and can corrupt i, but cannot prevent 𝑚𝑖𝑟, 1, which is viral propagated, from reaching all users on the system.)

[00252] In the second step, each verifier selected j ∈ SVr, 2 tries to identify the leader of the cycle. Specifically, it already adopts the credentials of step-1, 𝜎𝑖𝑟, 1 1,…, 𝜎𝑖𝑟, 1 𝑛, contained in the appropriate message of step-1 𝑚𝑖𝑟, 1 that it received; hashes all of them, that is, computes 𝐻 (𝜎𝑖𝑟, 1 1),…, 𝐻 (𝜎𝑖𝑟, 1 𝑛); finds the credential 𝜎ℓ𝑟, 1 𝑗, whose hash is lexicographically minimal; and considers ℓ𝑗𝑟 as the leader of cycle r.

[00253] Recalling that each credential considered is a digital signature of Qr-1, that SIGi (r, 1, Qr-1) is uniquely determined by ie Qr-1, that H is the random oracle and, thus, that each H (SIGi (r, 1, Qr-1) is a single random 256-bit long line for each potential leader i of cycle r.

[00254] From this it can be concluded that, if the 256-bit Qr-1 line was itself random and independently selected, then it would also be the hashed credentials of all potential leaders of cycle r. In fact, all potential leaders are well defined, and so are their credentials (regardless of whether or not they are actually counted). Furthermore, the set of potential leaders in cycle r is a random subset of users in cycle r - k, and an honest potential leader i always adequately builds and propagates his message 𝑚𝑖𝑟, which contains the credential of i. Thus, since the percentage of honest users is h, regardless of what potential malicious leaders may do (for example, revealing or hiding their own credentials), the potential leader credential with minimal hash belongs to an honest user, who is necessarily identified by everyone as the leader ℓr of cycle r. Consequently, if the 256-bit Qr-1 line were randomly selected and independently selected, with probability exactly h (a) the leader ℓr is honest and (b) ℓj = ℓr for all honest step-2 j verifiers .

[00255] In fact, hashed credentials are, yes, randomly selected, but depend on Qr-1, which is not random and independently selected. Careful analysis, however, ensures that Qr-1 is sufficiently non-manipulable to ensure that the leader of a cycle is honest with probability h 'close enough to h: namely, h'> h2 (1 + h - h2). For example, if h = 80%, then h '> 0.7424.

[00256] Identifying the leader of the cycle (what they do correctly when the leader ℓr is honest), the task of the verifiers in step-2 is to start executing 𝐵𝐴 ∗ using initial values that they believe to be the leader block. In fact, in order to minimize the amount of communication required, a verifier j ∈ SVr, 2 does not use, as input value v'j for the Byzantine protocol, the Bj block that it actually received from ℓj (user j believes to be the leader), but the leader, but the hash of such a block, that is, v'j = H (Bi). Thus, upon completion of the BA protocol, the verifiers of the last stage do not compute the Br block of the desired r-cycle, but compute (authenticate and propagate) H (Br). Consequently, since H (Br) is digitally signed by enough verifiers from the last step of the BA protocol, users in the system will realize that H (Br) is the hash of the new block. However, they also need to recover (or wait for, since the execution is quite asynchronous) the Br block by itself, whose protocol guarantees that it is, in fact, available, regardless of what the Opponent may accomplish.

[00257] Asynchrony and Timing Algorand'1 and Algorand'2 have a significant degree of asynchrony. This is due to the fact that the Opponent has a large latitude in the delivery schedule of the messages that are propagated. In addition, regardless of whether the total number of steps in a cycle is limited or not, there is a contribution of variance by the number of steps actually performed.

[00258] As soon as he learns the B0 certificates,. . . , Br-1, a user i computes Qr-1 and begins to work in cycle r, checking the possibility that he is a potential leader, or a verifier in some stages s of cycle r.

[00259] Assuming that i must act in step s, in view of the discussed asynchrony, i depends on several strategies to ensure that he has enough information before acting.

[00260] For example, it can expect to receive at least a certain number of messages from the verifiers in the previous step (as in Algorand'1), or wait long enough to ensure that it receives enough messages from verifiers from previous step (as in Algorand'2).

[00261] The Seed Qr and the Look Back Parameter k Recalling that, ideally, the quantities Qr should be random and independent, although it is sufficient that they are sufficiently not manipulable by the Opponent.

[00262] At first glance, one can choose Qr-1 to match H (PAYr-1). An elementary analysis reveals, however, that malicious users can take advantage of this selection mechanism.5 An additional effort shows that a diversity of other alternatives, based on traditional block quantities, are easily exploitable by the Adversary to ensure that malicious leaders are very frequently asked questions. Our new Qr quantity is specifically and inductively defined instead so as to have the ability to prove that it is not manipulable by the Adversary. Namely, 𝑄𝑟 ≜ 𝐻 (𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1), 𝑟), if Br is not the empty block, and 𝑄𝑟 ≜ 𝐻 (𝑄𝑟 − 1, 𝑟), otherwise.

[00263] The intuition of the reason for this construction of Qr to work is as follows. Assuming for a moment that Qr-1 is actually random and independently selected. So, is it also Qr? When ℓr is honest the answer is (in general terms) yes. This is due to 5 If it is at the beginning of the r - 1 cycle. Thus, Qr-2 = PAYr-2 is publicly known, and the Opponent confidentially knows who the potential leaders are controlling. Assuming that the Adversary controls 10% of users, and that, with very high probability, a malicious user w is the potential leader of the r - 1 cycle. That is, it is assumed that H (SIGw (r - 2, 1 , Qr-2)) is so small that it is highly unlikely that a potential honest leader will actually be the leader of the r - 1 cycle. (Recalling that, since potential leaders are chosen through a secret cryptographic election mechanism, the Opponent does not know who the potential honest leaders are.) The Opponent, therefore, is in an unfeasible position to choose the PAY 'set of payments that he wants, and to make it become the official set of payments in cycle r - 1. However, the same can do more. It can also guarantee that, with high probability, (*) one of its malicious users is also the leader of cycle r, so that it can freely select which PAYr it will be. (And so on. At least for a long time, that is, as long as these high probability events actually occur.) To be sure (*), the Opponent acts as follows. Let PAY 'be the set of payments that the Adversary prefers for cycle r - 1. Then, it computes H (PAY') and checks the possibility of, for some already malicious participant z, SIGz (r, 1, H (PAY ')) be particularly small, that is, small enough that, with very high probability, z is the leader of cycle r. If this is the case, then it instructs w to choose its candidate block to be 𝐵𝑖𝑟 − 1 = (𝑟 - 1, 𝑃𝐴𝑌 ′, 𝐻 (𝐵𝑟 − 2)). Otherwise, it has two other malicious users x and y to continue generating a new payment ℘ ', from one to the other, even to some malicious user z (or even some fixed user z) H (SIGZ (PAY 'U {℘})) is also particularly small. This experiment will stop very quickly. And when it happens, the Opponent asks w to propose the candidate block 𝐵𝑖𝑟 − 1 = (𝑟 - 1, 𝑃𝐴𝑌 ′, ∪ {℘}, 𝐻 (𝐵𝑟 − 2)).

𝐻 (𝑆𝐼𝐺ℓ𝑟 (∙), 𝑟) ∶ {0.1} 256 → {0.1} 256

[00264] be a random function. When ℓr is malicious, however, Qr is no longer unambiguously defined from Qr-1 and ℓr. There are at least two separate values for Qr. One remains 𝑄𝑟 ≜ 𝐻 (𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1), 𝑟), and the other is H (Qr-1, r). It is first argued that, although the second choice is somewhat arbitrary, a second choice is absolutely mandatory. The reason for this is that a malicious ℓr can always cause completely different candidate blocks to be received by honest second-stage verifiers.6 Once this is the case, it is easy to ensure that the block finally agreed through the BA protocol of cycle r will be that standard, and thus will not contain the digital signature of any person in Qr-1. But the system must continue, and for that, it needs a leader for cycle r. If that leader is automatically and openly selected, then the Opponent will trivially corrupt him. If selected by the previous Qr-1 through the same process, then ℓr will again be the leader in the r + 1 cycle. It is specifically proposed to use the same secret cryptographic election mechanism, but applied to a new quantity Q: namely, H (Qr-1, r). With this quantity as the output of H, the output is guaranteed to be random, and by including r as the second input of H, while all other uses of H were a single input or at least three inputs, “guarantee” that such a Qr is independently selected. Again, the specific choice of alternative Qr does not matter, what matters is that ℓr has two choices for Qr, and thus can double his chances of having another malicious user as the next leader.

[00265] The options for Qr can even be more 6 For example, to simplify (but in an extreme way), “when the time of the second stage is about to expire”, ℓr can directly send an email to a candidate block Bi different for each user i. In this way, whoever the verifiers in step-2 may be, they will have received totally different blocks.

numerous for the Adversary who controls a malicious ℓr. For example, let x, y and z be three potential malicious leaders of cycle r so that 𝐻 (𝜎𝑥𝑟, 1) <𝐻 (𝜎𝑦𝑟, 1) <𝐻 (𝜎𝑧𝑟, 1)

[00266] and 𝐻 (𝜎𝑧𝑟, 1) is particularly small. That is, so small that there is a good chance that 𝐻 (𝜎𝑧𝑟, 1) is less than the hashed credential of each potential honest leader. Then, by asking x to hide its credential, the Opponent has a good chance of making y become the leader of cycle r - 1. This implies that he has another option for Qr: namely, H (SIGy ( Qr-1), r). Similarly, the Opponent may request that both x and y retain their credentials, so that z becomes the leader of the r - 1 cycle and gains another option for Qr: namely, H (SIGZ (Qr-1 ), r).

[00267] Of course, however, each of these and other options has a non-zero chance of failing, due to the Adversary being unable to predict the hash of the digital signatures of honest potential users.

[00268] A careful analysis similar to the careful Markov chain shows that, regardless of what options the Opponent chooses to perform in the r - 1 cycle, as long as he cannot inject new users into the system, he cannot decrease the probability of an honest user be the leader of the r + 40 cycle far below h. This is why potential leaders in cycle r are required to be existing users in cycle r - k. It is a way of ensuring that, in the r - k cycle, the Opponent cannot change the probability that an honest user will become the leader of the r cycle. In fact, regardless of which users it can add to the system in cycles r - k to r, they are ineligible to become potential leaders (and, a fortiori, the leader) of cycle r. Thus, the look back parameter k is ultimately a safety parameter. (Although, as will be seen in the section ??, it can also be a type of “convenience parameter”.)

[00269] Ephemeral Keys Although the execution of the protocol cannot generate a bifurcation, except with insignificant probability, the Opponent can generate a bifurcation, in the r-th block, after the legitimate r block has been generated.

[00270] In general, once Br has been generated, the Adversary has learned who the verifiers of each stage of cycle r are. Thus, it can therefore corrupt all of these and ̃𝑟. Since this fake block obliges them to certify a new block 𝐵 it can be propagated only after the legitimate one, in which the users who ̃𝑟 would have paid attention not to be deceived.7 Nevertheless, it is syntactically correct and it is desired to prevent it from being manufactured.

[00271] This is done through a new rule. Essentially, members of the SVr, one-step verifier set of cycle r use ephemeral public keys 𝑝𝑘𝑖𝑟, 𝑠 to digitally sign their messages. These keys are for single use only and their corresponding secret keys 𝑝𝑘𝑖𝑟, 𝑠 are destroyed once used. Thus, if a checker is later corrupted, the Opponent cannot force him to sign anything that he did not originally sign.

[00272] Naturally, it must be ensured that it is impossible for the Opponent to compute a new key 𝑝̃ 𝑟, 𝑠 𝑖 and convince an honest user that this is the correct ephemeral key of the i ∈ SVr, s verifier to use in step s.

4.2 Common Summary of Notations, Notions, and Notations Parameters

[00273] ● r ≥ 0: the current cycle number.

[00274] ● s ≥ 1: the current step number in cycle r.

7 It is considered to corrupt the news anchor of a large TV network, and to produce and broadcast a news program that shows Secretary Clinton winning the last presidential election. Most of us would recognize that this is a scam. But someone who was waking up from a coma could be tricked.

[00275] ● Br: the block generated in cycle r.

[00276] ● PKr: the set of public keys at the end of cycle r - 1 and at the beginning of cycle r.

[00277] ● Sr: the system status at the end of cycle r - 1 and at the beginning of cycle r.8

[00278] ● PAYr: the set of payments contained in Br.

[00279] ● ℓr: r-cycle leader. escolher chooses the PAYr payment set of cycle r (and determines the next Qr).

[00280] ● Qr: the seed of cycle r, a quantity (ie, binary line) that is generated at the end of cycle r and is used to choose verifiers for cycle r + 1. Qr is independent of the payment sets in the blocks and cannot be manipulated by ℓr.

[00281] ● SVr, s: the set of verifiers chosen for step s of cycle r.

[00282] ● SVr: the set of verifiers chosen for cycle r, SVr = Us≥1SVr, s.

[00283] ● M SVr, s and H SVr, s: respectively the set of malicious scanners and the set of honest scanners in SVr’s. MSVr’s ∪ HSVr’s = SVr’s and MSVr’s ∩ HSVr’s = Ø

[00284] ● 𝑛1 ∈ ℤ + and 𝑛 ∈ ℤ +: respectively, the expected numbers of potential leaders in each SVr, 1, and the expected numbers of verifiers in each SVr, s, for s> 1.

[00285] Note that n1 << n, since it requires at least one honest member in SVr, 1, but at least a majority of the honest members in each SVr, s for s> 1.

[00286] ● h ∈ (0, 1): a constant greater than 2/3. h is the reason for honesty in the system. That is, the fraction of honest users or 8 In a system that is not synchronized, the notation of “the end of cycle r - 1” and “the beginning of cycle r” needs to be carefully defined. Mathematically PKr and Sr are computed from the initial state S0 and blocks B1,. . ., Br-1.

honest money, depending on the assumption used, in each PKr is at least h.

[00287] ● H: a cryptographic hash function, modeled as a random oracle.

[00288] ● ⊥: A special line of the same length as the H output.

[00289] ● F ∈ (0, 1): the parameter that specifies the permitted error probability. A probability ≤ F is considered “insignificant”, and a probability ≥ 1 - F is considered “immense”.

[00290] ● 𝑝ℎ ∈ (0.1): the probability that the leader of a cycle r, ℓr, is honest. Ideally 𝑝ℎ = ℎ. With the Opponent's existence, the value of 𝑝ℎ will be determined in the analysis.

[00291] ● k ∈ ℤ +: the look back parameter. That is, cycle r - k is where the checkers for cycle r are chosen from - namely, SVr ⊆ PKr-k.9

[00292] ● 𝑝1 ∈ (0.1): for the first stage of cycle r, a user in cycle r - k is chosen to be in SVr, 1 with probability 𝑝1 ≜ 𝑛1. | 𝑃𝐾𝑟 − 𝑘 |

[00293] ● 𝑝 ∈ (0,1): for each step s> 1 of cycle r, a user 𝑛 in cycle r - k is chosen to be in SVr, s with probability 𝑝 ≜. | 𝑃𝐾𝑟 − 𝑘 |

[00294] ● CERTr: the certificate for Br. It is a set of tH signatures of H (Br) of the appropriate verifiers in cycle r.

[00295] ● ̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅ 𝐵𝑟 ≜ (𝐵𝑟, 𝐶𝐸𝑅𝑇 𝑟) is a proven block.

[00296] A user i knows Br if he has (and successfully checks) both parts of the tested block. It is noted that the CERTr observed by different users may be different.

[00297] ● 𝒯𝑖 𝑟: the time (local) at which a user i meets Br. No 9 Strictly speaking, “r - k” must be “max {0, r - k}”.

Algorand protocol each user has his own clock. Watches from different users do not need to be synchronized, but they must have the same speed. For analysis purposes only, it is considered a reference clock and measurement of the participants' related times in relation to it.

[00298] ● 𝛼𝑖𝑟, 𝑠 and 𝛽𝑖𝑟, 𝑠: respectively (local) time that a user i starts and ends his execution of Step s of cycle r.

[00299] ● Λ and λ: essentially, the upper limits for, respectively, the time required to perform Step 1 and the time required for any other step of the Algorand protocol.

[00300] The parameter Λ limits the time to propagate a single block of 1 MB in a superior way.

[00301] The parameter λ limits the time to propagate a small message per verifier in a step s> 1.

[00302] It is assumed that Λ ≤ 4λ. Notations

[00303] ● Selection of verifier.

[00304] For each cycle r and step s> 1, 𝑆𝑉 𝑟, 𝑠 ≜ {𝑖 ∈ 𝑃𝐾 𝑟 − 𝑘 ∶. 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄𝑟 − 1)) ≤ 𝑝}. Each i ∈ PKr-k user computes his signature confidentially using his long-term key and decides whether or not i ∈ SVr, s. If i ∈ SVr, s, then SIGi (r, s, Qr-1) is the credential (r, s) of i, briefly denoted by 𝜎𝑖𝑟, 𝑠.

[00305] For the first stage of the cycle r, SVr, 1 and 𝜎𝑖𝑟, 1 are very similarly defined, where p is replaced by p1.

[00306] Verifiers in SVr’1 are potential leaders.

[00307] ● Selection of leader.

[00308] User i ∈ SVr, 1 is the leader of cycle r, denoted by ℓr, if 𝐻 (𝜎𝑖𝑟, 1) ≤ 𝐻 (𝜎𝑗𝑟, 1) for all potential leaders j ∈ SVr, 1. Whenever the hashes of two participants 'credentials are compared, in the unlikely event of relationships, the protocol always breaks relationships lexicographically according to the potential leaders' long-term public keys.

[00309] By definition, the hash value of the ℓr participant credential is also the lowest of all users in PKr-k. It is observed that a potential leader cannot confidently decide whether he is the leader or not, without observing the other credentials of potential leaders.

[00310] Since hash values are uniform at random, when SVr, 1 is non-empty, ℓr always exists and is honest with probability of at least h. Parameter n1 is large enough to ensure that each SVr, 1 is non-empty with immense probability.

[00311] ● Structure in blocks.

[00312] A non-empty block is of the form 𝐵𝑟 = (𝑟, 𝑃𝐴𝑌 𝑟, 𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1), and an empty block is of the form 𝐵𝜀𝑟 = (𝑟, ∅, 𝑄𝑟 − 1, 𝐻 (𝐵𝑟 − 1)).

[00313] It is noted that a non-empty block may still contain an empty PAYr payment set, if no payments occur in that cycle or if the leader is malicious. However, a non-empty block implies that identidader's identity, his credential 𝜎ℓ𝑟, 1 𝑟 and 𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1) were all promptly revealed. The protocol guarantees that, if the leader is honest, then the block will be non-empty with immense probability.

[00314] ● Qr seed.

[00315] If Br is not empty, then 𝑄𝑟 ≜ 𝐻 (𝑆𝐼𝐺ℓ𝑟 (𝑄𝑟 − 1), 𝑟), otherwise, 𝑄𝑟 ≜ 𝐻 (𝑄𝑟 − 1, 𝑟). Parameters

[00316] ● Relationships between several parameters.

[00317] - Verifiers and potential leaders of cycle r are selected from users in PKr-k, in k it is chosen so that the Opponent cannot predict Qr-1 in cycle r - k - 1 with a better probability than F : otherwise, it will have the ability to introduce malicious users to cycle r - k, where everyone will be potential leaders / verifiers in cycle r, who are successful in having a malicious leader or most malicious in SVr, s to some steps are desired for the same.

[00318] - For Step 1 of each cycle r, n1 is chosen so that with immense probability, 𝑆𝑉 𝑟, 1 ≠ ∅.

[00319] ● Exemplary choices of important parameters.

[00320] - H outputs are 256 bits long.

[00321] - h = 80%, n1 = 35.

[00322] - Λ = 1 minute and λ = 15 seconds.

[00323] ● Initialization of the protocol.

[00324] The protocol starts at moment 0 with r = 0. Since there is no “B-1” or “CERT-1”, syntactically B-1 is a public parameter with its third component that specifies Q-1, and all Users know B-1 at the moment 0. 5 Algorand'1

[00325] In this section, a version of Algorand 'is built that works under the following assumption.

[00326] ASSUMPTION OF A HONEST PART OF USERS: More than 2/3 of users in each PKr are honest.

[00327] Section 7 shows how to replace the above assumption with the desired Most Honest Part of Money assumption.

5.1 Notations And Additional Parameters Notations

[00328] ● m ∈ ℤ +: the maximum number of steps in the binary BA protocol, a multiple of 3.

[00329] ● Lr ≤ m / 3: a random variable that represents the number of Bernoulli tests necessary to observe a 1, when each 𝑝ℎ test is probable and there is a maximum of m / 3 tests. If all tests 2 fail, then 𝐿𝑟 ≜ 𝑚⁄3. 𝐿𝑟 will be used to limit the time needed to generate Br block 2.

[00330] ● 𝑡𝐻 = + 1: the number of signatures required 3 in the final conditions of the protocol.

[00331] ● CERTr: the certificate for Br. It is a set of tH signatures of H (Br) of the appropriate verifiers in cycle r. Parameters

[00332] ● Relationships between several parameters.

[00333] - For each step s> 1 of cycle r, n is chosen so that, with immense probability, | HSVr, s | > 2 | MSVr, s | e | HSVr, s | + 4 | MSVr, s | <2n.

[00334] The closer to 1 the h value is, the smaller n needs to be. In particular, Chernoff limits (variants of) are used to ensure that the desired conditions remain with immense probability.

[00335] - m is chosen so that Lr <m / 3 with immense probability.

[00336] ● Exemplary choices of important parameters.

[00337] - F = 10-12.

[00338] - n ≈ 1,500, k = 40 and m = 180.

5.2 Implementation of Ephemeral Keys in Algorand'1

[00339] As already mentioned, it is desired that a verifier i ∈ SVr, s digitally sign his message 𝑚𝑖𝑟, 𝑠 of step s in cycle r, in relation to an ephemeral public key 𝑝𝑘𝑖𝑟, 𝑠 with the use of an ephemeral secret key 𝑠𝑘𝑖𝑟, 𝑠 which it readily destroys after use. It is needed,

thus, an effective method to ensure that each user can verify that 𝑝𝑘𝑖𝑟, 𝑠 is, in fact, the key that is used to verify the signature of i of 𝑚𝑖𝑟, 𝑠. This is done by (to the best of our knowledge) a new use of identity-based subscription schemes.

[00340] At a high level, in such a scheme, a central authority A generates a public master key, PMK, and a corresponding secret master key, SMK. Given the identity, U, of a U participant, A computes, via SMK, a secret signature key skU with respect to the public key U, and confidentially generates skU for U. (In fact, in a digital signature scheme with based on identity, a user's public key is U by itself!) Thus, if A destroys SMK after computing the secret keys of the users he wants to allow to produce digital signatures, and not keep any secret keys computed, so U is the only one who can digitally sign messages with respect to public key U. Thus, anyone who knows “U's name” automatically knows U's public key, and thus can verify U's signatures. (possibly also using the PMK public master key).

[00341] In this application, authority A is user i, and the set of all possible users U coincides with the cycle-step pair (r, s) in - say— S = {i} x {r ' ,. . . , r '+ 106} x {1,. . . , m + 3}, where r ’is a given cycle, and m + 3 is the upper limit for the number of steps that can occur in a cycle. Thus, 𝑝𝑘𝑖𝑟, 𝑠 ≜ (𝑖, 𝑟, 𝑠), so that all todos, 𝑠 𝑟, 𝑠 who observe the signature of i 𝑆𝐼𝐺𝑝𝑘 𝑟, 𝑠 (𝑚𝑖) can, with immense probability 𝑖, immediately verify it when to the first million cycles r after r '.

[00342] In other words, i first generates PMK and SMK. Then, it publishes that PMK is the master public key of i for any cycle r ∈ [r ', r' + 106], and uses SMK to confidentially produce and store the secret key 𝑠𝑘𝑖𝑟, 𝑠 for each trio (i, r , s) ∈ S. This being accomplished, it destroys SMK. If it determines that it is not part of SVr, s, then i can leave 𝑠𝑘𝑖𝑟, 𝑠 alone (since the protocol does not require it to authenticate any message in Step s of cycle r). Otherwise, i first uses 𝑠𝑘𝑖𝑟, 𝑠 to digitally sign your message 𝑚𝑖𝑟, 𝑠 and then destroys 𝑠𝑘𝑖𝑟, 𝑠.

[00343] It is noted that i can publish its first public master key when it first enters the system. That is, the same payment p that takes i to the system (in a cycle r 'or in a cycle close to r'), can also specify, at the request of i, that the public master key of i for any cycle r ∈ [r ', r' + 106] is PMK —for example, including a shape pair (PMK, [r ', r' + 106]).

[00344] It is also observed that, since m + 3 is the maximum number of steps in a cycle, it is assumed that a cycle takes one minute, in which the deposit of ephemeral keys thus produced will last i for almost two years. At the same time, these ephemeral secret keys will not take long to be produced. Using an elliptical curve based system with 32B keys, each secret key is computed in a few microseconds. Thus, if m + 3 = 180, then all 180 M secret keys can be computed in less than an hour.

[00345] When the current cycle is close to r '+ 106, to handle the next million cycles, i generates a new pair (PMK', SMK '), and informs you of your next ephemeral key deposit - for example - causing SIGi (PMK ', [r' + 106 + 1, r '+ 2 · 106 + 1]) to enter a new block, with a separate “transaction” or as some additional information that is part of a payment. When this is done, i informs everyone that he should use PMK 'to check i's ephemeral signatures over the next million cycles. And so on.

[00346] (It is noted that, following this basic approach, other ways to deploy ephemeral keys without using identity-based signatures are certainly possible. For example, through Merkle trees.10) Other ways to deploy ephemeral keys are certainly possible - for example, through Merkle trees.

5.3 Match the steps of Algorand'1 with those of 𝑩𝑨 ∗

[00347] As stated, a cycle in Algorand'1 has a maximum of m + 3 steps.

[00348] STEP 1. In this step, each potential leader i computes and propagates his candidate block 𝐵𝑖𝑟, together with his own credential, 𝜎𝑖𝑟, 1.

[00349] Remember that this credential explicitly identifies i. This is due to 𝜎𝑖𝑟, 1 ≜ 𝑆𝐼𝐺𝑖 (𝑟, 1, 𝑄𝑟 − 1).

[00350] The potential verifier i also propagates, as part of its message, its appropriate digital signature 𝐻 (𝐵𝑖𝑟). Without dealing with a payment or a credential, this signature of i has to do with its ephemeral public key 𝑝𝑘𝑖𝑟, 1: that is, it propagates 𝑠𝑖𝑔𝑝𝑘𝑟, 1 (𝐻 (𝐵𝑖𝑟)). 𝑖

[00351] Given the conventions, instead of propagating 𝐵𝑖𝑟 and 𝑠𝑖𝑔𝑝𝑘𝑟, 1 (𝐻 (𝐵𝑖𝑟)), it could have propagated 𝑆𝐼𝐺𝑝𝑘 𝑟, 1 (𝐻 (𝐵𝑖𝑟)). However, in the analysis, it is necessary to have explicit access to 𝑠𝑖𝑔𝑝𝑘𝑟, 1 (𝐻 (𝐵𝑖𝑟)). 𝑖

[00352] STEPS 2. In this step, each verifier i configures ℓ𝑟𝑖 as the potential leader whose hashed credential is the smallest, and 𝐵𝑖𝑟 as the block proposed by ℓ𝑟𝑖. Since, for efficiency purposes, you want to agree 10In this method, i generates a pair of public secret keys (𝑝𝑘𝑖𝑟, 𝑠, 𝑠𝑘𝑖𝑟, 𝑠) for each pair of cycle steps (r, s) in - say - {r ', ..., r' + 106} x {1, ..., m + 3}. Then, it sorts these public keys in a conical way, stores the j-th public key on the j-th leaf of a Merkle tree and computes the value of the root Ri, which it publishes. When he wants to sign a message with respect to the key 𝑝𝑘𝑖𝑟, 𝑠, i not only provides an actual signature, but also the authentication path for 𝑝𝑘𝑖𝑟, 𝑠 with respect to Ri. Note that this authentication path also proves that 𝑝𝑘𝑖𝑟, 𝑠 is stored on the j-th sheet. By forming this idea, the rest of the details can be easily completed.

with H (Br), instead of directly with Br, i propagates the message that it would have propagated in the first stage of 𝐵𝐴 ∗ with initial value 𝑣′𝑖 = 𝐻 (𝐵𝑖𝑟). That is, the same propagates ν'i, after ephemerally signing the same, evidently. (Namely, after signing it with respect to the right ephemeral public key, which in this case is 𝑝𝑘𝑖𝑟, 2. Also of course, i also transmits its own credential.

[00353] Since the first stage of 𝐵𝐴 ∗ consists of the first stage of the graduated GC consensus protocol, Stage 2 of Algorand 'corresponds to the first stage of GC.

[00354] STEPS 3. In this step, each verifier i ∈ SVr, 2 performs the second step of 𝐵𝐴 ∗. That is, it sends the same message that it would have sent in the second stage of KM. Again, i's message is ephemerally signed and accompanied by i's credential. (From now on, it will be omitted to say that a verifier ephemerally signs your message and also propagates your credential.)

[00355] STEP 4. In this step, each verifier i ∈ SVr, 4 computes the GC output, (vi, gi), and ephemerally signs and sends the same message that it would have sent in the third step of 𝐵𝐴 ∗, that is , in the first step of 𝐵𝐵𝐴 ∗, with initial bit 0 if gi = 2, and 1, otherwise.

[00356] STEP s = 5,. . . , m + 2. Such a step, if reached, corresponds to step s - 1 of 𝐵𝐴 ∗ and thus step s - 3 of 𝐵𝐵𝐴 ∗.

[00357] Since the propagation model is sufficiently asynchronous, one should consider the possibility that, in the middle of such step s, a verifier i ∈ SVr, s will be reached by the information that prove for the same as the Br block already was chose. In this case, i stops its own Algorand 'cycle execution r, and starts executing its cycle instructions- (r + 1).

[00358] Consequently, the instructions of a verifier i ∈ SVr, s, in addition to the instructions corresponding to Step s - 3 of 𝐵𝐵𝐴 ∗, include verifying the possibility that the execution of 𝐵𝐵𝐴 ∗ may have been stopped in a previous step s'. Since 𝐵𝐵𝐴 ∗ can only stop at a Currency-Fixed-at-0 or a Currency-Fixed-at-1 step, the instructions distinguish the possibility of

[00359] A (Final Condition 0): s' - 2 ≡ 0 mod 3, or

[00360] B (Final Condition 1): s' - 2 ≡ 1 mod 3.

[00361] In fact, in case A, the Br block is not empty, so additional instructions are needed to ensure that i properly rebuild Br, together with its appropriate CERTr certificate. In case B, the Br block is empty and, thus, i is instructed to configure 𝐵𝑟 = 𝐵𝜀𝑟 = (𝑟, ∅, 𝑄𝑟 − 1, 𝐻 (𝐵𝑟 − 1)) and compute CERTr.

[00362] If, during the execution of step s, i does not observe any evidence that block Br has already been generated, then it sends the same message that it would have sent in step s - 3 of 𝐵𝐵𝐴 ∗.

[00363] STEP m + 3. If, during step m + 3, i ∈ SVr, m + 3 observes that the Br block has already been generated in a previous step s', then it continues as explained above.

[00364] Otherwise, instead of sending the same message that he would have sent in step m of 𝐵𝐵𝐴 ∗, i is instructed, based on the information in his possession, to compute Br and its corresponding CERTr certificate.

[00365] It is recalled, in fact, that the total number of steps in a cycle is limited to m + 3.

5.4 The Royal Protocol

[00366] Remember that at each stage s of a cycle r, a verifier i ∈ SVr, s uses its long-term public-secret key pair to produce its credential, 𝜎𝑖𝑟, 𝑠 ≜ 𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄𝑟 − 1), as well as GIS (Qr-1) in the case s = 1. Verifier i uses his secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 to sign his message (r, s) 𝑚𝑖𝑟, 𝑠. For simplicity, when r and s are clear,

write 𝑒𝑠𝑖𝑔𝑖 (𝑥) instead of 𝑠𝑖𝑔𝑝𝑘 𝑟, 𝑠 (𝑥) to denote the appropriate ephemeral signature i of i of a value x in step s of cycle r, and write 𝐸𝑆𝐼𝐺𝑖 (𝑥) instead of 𝑆𝐼𝐺𝑝𝑘𝑟, 𝑠 (𝑥) to denote (𝑖, 𝑥, 𝑒𝑠𝑖𝑔𝑖 (𝑥)). 𝑖 Step 1: Block Proposal

[00367] Instructions for each user i ∈ PKr-k: User i starts his own Step 1 of cycle r as soon as he meets Br-1.

[00368] ● User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, 1.

[00369] ● If i ∉ SVr, 1, then i for its own execution of Step 1 immediately.

[00370] ● If i ∈ SVr, 1, that is, if i is a potential leader, then it collects the r-cycle payments that have been propagated to it so far and computes a maximum payment set 𝑃𝐴𝑌𝑖𝑟 from them.

[00371] Then, it computes its “candidate block” 𝐵𝑖𝑟 = (𝑟, 𝑃𝐴𝑌𝑖𝑟, 𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝐻 (𝐵𝑟 − 1)). Finally, it computes the message 𝑚𝑖𝑟, 1 = (𝐵𝑖𝑟, 𝑒𝑠𝑖𝑔𝑖 (𝐻 (𝐵𝑖𝑟)), 𝜎𝑖𝑟, 1), destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 1 and then propagates 𝑚𝑖𝑟, 1.

[00372] Observation. In practice, to shorten the overall execution of Step 1, it is important that messages (r, 1) are selectively propagated. That is, for each user i in the system, for the first message (r, 1) that the user successfully receives and verifies, 11 participant i propagates the table as normal. For all other messages (r, 1) that participant i successfully receives and verifies, it propagates these only if the hash value of those credentials contains the smallest within the hash values of the credentials contained in all messages (r, 1) that he has received and 11 That is, all signatures are correct and both the block and its hash are valid - although i do not check whether the set of payments included is maximum or not for its bidder.

has successfully verified so far. Additionally, as suggested by Georgios Vlachos, it is useful that each potential leader i also propagate his sua, 1 credential separately: those small messages travel faster than the blocks, guarantee the immediate propagation of 𝑚𝑖𝑟, 1 in which the contained credentials have hash values while making those with large hash values disappear quickly. Step 2: The First Step of the GC Graduate Consensus Protocol

[00373] Instructions for each user i ∈ PKr-k: User i starts his own Step 2 of cycle r as soon as he meets Br-1.

[00374] • User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr’2.

[00375] ● If i ∉ SVr, 2, then i for its own execution of Step 2 immediately.

[00376] ● If i ∈ SVr'2, then, after waiting for an amount of time 𝑡2 ≜ λ + Λ, i acts as follows.

[00377] 1. It finds the user ℓ so that 𝐻 (𝜎ℓ𝑟, 1) ≤ 𝐻 (𝜎j𝑟, 1) for all credentials 𝜎j𝑟, 1 that are part of the messages successfully verified (r, 1) as the same received so far.12

[00378] 2. If he received from ℓ a valid message 𝑚ℓ𝑟, 1 = (𝐵ℓ𝑟, 𝑒𝑠𝑖𝑔ℓ (𝐻 (𝐵ℓ𝑟)), 𝜎ℓ𝑟, 1), 13 then, i configures 𝑣′𝑖 ≜ 𝐻 (𝐵ℓ𝑟); otherwise, i configures 𝑣′𝑖 ≜⊥.

[00379] 3. i computes message 𝑚𝑖𝑟, 2 ≜ Essentially, user i privately decides that the leader of cycle r is user ℓ. 12 Again, participant ℓ signatures and hashes are all successfully verified, and 13 𝑃𝐴𝑌ℓ𝑟 in 𝐵ℓ𝑟 is a valid set of payments for cycle r - although i does not check whether 𝑃𝐴𝑌ℓ𝑟 is maximum for ℓ or not.

(𝐸𝑆𝐼𝐺𝑖 (𝑣′𝑖), 𝜎𝑖𝑟, 2), 14 destroys your ephemeral secret key 𝑠𝑘𝑖𝑟, 2 and then propagates 𝑚𝑖𝑟, 2. Step 3: The Second GC Step

[00380] Instructions for each user i ∈ PKr-k: User i starts his own Step 3 of cycle r as soon as he meets Br-1.

[00381] ● User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, 3.

[00382] ● If i ∉ SVr, 3, then i stops its own execution of Step 3 immediately.

[00383] ● If i ∈ SVr, 3, then, after waiting for an amount of time 𝑡3 ≜ 𝑡2 + 2𝜆 = 3𝜆 + Λ, i acts as follows.

[00384] 1. If there is a value v '≠ ⊥ so that, of all the valid messages 𝑚𝑗𝑟, 2 that he received, more than 2/3 of them are in the form (𝐸𝑆𝐼𝐺𝑗 (𝑣 ′), 𝜎𝑗𝑟, 2 ), without any contradiction, 15 then, it computes the message 𝑚𝑖𝑟, 3 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑣 ′), 𝜎𝑖𝑟, 3). Otherwise, it computes 𝑚𝑖𝑟, 3 ≜ (𝐸𝑆𝐼𝐺𝑖 (⊥), 𝜎𝑖𝑟, 3).

[00385] 2. i destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 3 and then propagates 𝑚𝑖𝑟, 3. Step 4: Exit From GC And The First Step From 𝑩𝑩𝑨 ∗

[00386] Instructions for each user i ∈ PKr-k: User i starts his own Step 4 of cycle r as soon as he meets Br-1.

[00387] ● User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, 4.

𝑟, 2 14 The message 𝑚𝑖 signals that the participant i considers v'1 as the hash of the next block or considers the next block as empty. That is, he did not receive two valid messages containing 𝐸𝑆𝐼𝐺 (𝑣 ′) and one different 𝐸𝑆𝐼𝐺 (𝑣 ′ ′) 𝑗 𝑗, respectively, from participant j. Here and below, except in the Final Conditions defined later, whenever an honest participant wants messages in a certain way, messages that contradict each other are never counted or considered valid.

[00388] ● If i ∉ SVr, 4, then i stops its own execution of Step 4 immediately.

[00389] ● If i ∈ SVr, 4, then, after waiting for an amount of time 𝑡4 ≜ 𝑡3 + 2𝜆 = 5𝜆 + Λ, i acts as follows.

[00390] 1. The same computes vi and gi, a GC output, as follows.

[00391] (a) If there is a value v '≠ ⊥ so that, of all the valid messages 𝑚𝑗𝑟, 3 that it received, more than 2/3 of them are in the form (𝐸𝑆𝐼𝐺𝑗 (𝑣 ′), 𝜎𝑗𝑟, 3), then, it configures 𝑣𝑖 ≜ 𝑣 ′ and 𝑔𝑖 ≜ 2.

[00392] (b) Otherwise, if there is a value v '≠ ⊥ so that, of all the valid messages 𝑚𝑗𝑟, 3 that he received, more than 1/3 of them are in the form (𝐸𝑆𝐼𝐺𝑗 (𝑣 ′ ), 𝜎𝑗𝑟, 3), then it configures 𝑣𝑖 ≜ 𝑣 ′ and 𝑔𝑖 ≜ 1.16

[00393] (c) Otherwise, it configures 𝑣𝑖 ≜ 𝐻 (𝐵𝜀𝑅) and 𝑔𝑖 ≜ 0.

[00394] 2. The same computes bi, the entry of 𝐵𝐵𝐴 ∗, as follows:

[00395] 𝑏𝑖 ≜ 0 if 𝑔𝑖 = 2, and 𝑏𝑖 ≜ 1 otherwise.

[00396] 3. It computes the message 𝑚𝑖𝑟, 4 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 4), destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 4 and then propagates 𝑚𝑖𝑟, 4.

[00397] Step s, 5 ≤ s ≤ m + 2, s - 2 mod 0 mod 3: One Coin-Fixed-In-0 Step of 0 ∗

[00398] Instructions for each user i ∈ PKr-k: User i starts his own Step s of cycle r as soon as he meets Br-1.

16 It can be proved that the v 'in case (b), if any, must be exclusive. 𝑟, 2 𝑚𝑖 signals that participant i considers v’1 as the hash of the next block or considers the next block as empty.

[00399] ● User i computes Qr-1 from the third component of Br-1 and checks the possibility of i ∈ SVr, s.

[00400] ● If i ∉ SVr, s, then i for its own execution of Step s immediately.

[00401] ● If i ∈ SVr, s, then it acts as follows.

[00402] - The same waits until an amount of time 𝑡𝑠 ≜ 𝑡𝑠 − 1 + 2𝜆 = (2𝑠 - 3) 𝜆 + Λ has elapsed.

[00403] - Final Condition 0: If, during such a wait and at any point in time, there is a line v ≠ ⊥ and a step s' so that

[00404] (a) 5 ≤ s' ≤ s, s' - 2 ≡ 0 mod 3 - that is, Step s' is a Fixed-Currency-In-0, 2𝑛 step

[00405] (b) i received at least 𝑡𝐻 = + 1 valid 3 ′ −1 ′ −1 messages 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣), 𝜎𝑗𝑟, 𝑠), 17 and

[00406] (c) i received a valid message 𝑚𝑗𝑟, 1 = (𝐵𝑗𝑟, 𝑒𝑠𝑖𝑔𝑗 (𝐻 (𝐵𝑗𝑟)), 𝜎𝑗𝑟, 1) with 𝑣 = 𝐻 (𝐵𝑗𝑟), then i for its own execution of Step s (e , in fact, cycle r) immediately without propagating anything; sets 𝐵𝑟 = 𝐵𝑗𝑟; and configure your own CERTr as the set of ′ −1 messages 𝑚𝑗𝑟, 𝑠 of substep (b) .18

[00407] - Final Condition 1: If, during such a wait and at any point in time, there is a step s' so that

[00408] (a ') 6 ≤ s' ≤ s, s '- 2 ≡ 1 mod 3 - that is, Step s' is step 17 Such message from participant j is counted even if participant i has also received a message from j that signs for 1. Things similar to Final Condition 1. As shown in the review, this is done to ensure that all honest users know B r in time λ from each other. 18 User i now knows Br and his own cycle r ends. It still helps to propagate messages as a generic user, but does not initiate any propagation as a verifier (r, s). In particular, it helped to propagate all messages in that CERTr, which is sufficient for our protocol. Note that it must also set deve ≜ 0 for the binary BA protocol, but bi is not necessary in this case anyway. Similar things for all future instructions.

Fixed-Currency-In-1, and

[00409] (b ’) i received at least tH valid messages ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠), 19

[00410] then, i for its own execution of Step s (and, in fact, of cycle r) immediately without propagating anything; configures 𝐵𝑟 = ′ −1 𝐵𝜀𝑟 and configures its own CERTr as the set of messages 𝑚𝑗𝑟, 𝑠 substep (b ').

[00411] - Otherwise, at the end of the wait, user i performs the following.

[00412] It configures νi as the vote of most vj's in the second components of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received.

[00413] The same computes bi as the following.

[00414] If more than 2/3 of all 𝑚𝑗𝑟, 𝑠 − 1 valid that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the same configures 𝑏𝑖 ≜ 0 .

[00415] Otherwise, if more than 2/3 of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the even sets 𝑏𝑖 ≜ 1.

[00416] Otherwise, it configures 𝑏𝑖 ≜ 0.

[00417] It computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagates 𝑚𝑖𝑟, 𝑠.

[00418] Step s, 6 ≤ s ≤ m + 2, s - 2 ≡ 1 mod 3: One Coin-Fixed-In-1 Step of 𝐵𝐵𝐴 ∗

[00419] Instructions for each user i ∈ PKr-k: User i 19 In this case, it doesn't matter which vj's are.

begins its own Stage s of cycle r as soon as it meets Br-1.

[00420] ● User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, s.

[00421] ● If i ∉ SVr, s, then i for its own execution of Step s immediately.

[00422] ● If i ∈ SVr, s then it does the following.

[00423] - The same waits until an amount of time 𝑡𝑠 ≜ (2𝑠 - 3) 𝜆 + Λ has elapsed.

[00424] - Final Condition 0: The same instructions as for the Fixed-Currency-In-0 steps.

[00425] - Final Condition 1: The same instructions as for the Fixed-Currency-In-0 steps.

[00426] - Otherwise, at the end of the wait, user i performs the following.

[00427] The same configures νi as the vote of most vj's in the second components of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received.

[00428] The same computes bi as the following.

[00429] If more than 2/3 of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the same configures 𝑏𝑖 ≜ 0.

[00430] Otherwise, if more than 2/3 of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the even sets 𝑏𝑖 ≜ 1.

[00431] Otherwise, it configures 𝑏𝑖 ≜ 1.

[00432] It computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagates 𝑚𝑖𝑟, 𝑠.

Step s, 7 ≤ s ≤ m + 2, s - 2 mod 2 mod 3: One Currency Step - Genuinely-Launched from 𝐵𝐵𝐴 ∗

[00433] Instructions for each user i ∈ PKr-k: User i starts his own Step s of cycle r as soon as he meets Br-1.

[00434] ● User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, s.

[00435] ● If i ∉ SVr, s, then i for its own execution of Step s immediately.

[00436] ● If i ∈ SVr, s then it does the following.

[00437] - The same waits until an amount of time 𝑡𝑠 ≜ (2𝑠 - 3) 𝜆 + Λ has elapsed.

[00438] - Final Condition 0: The same instructions as for the Fixed Currency-In-0 steps.

[00439] - Final Condition 1: The same instructions as for the Fixed-Currency-In-0 steps.

[00440] - Otherwise, at the end of the wait, user i performs the following.

[00441] The same configures νi as the vote of most vj's in the second components of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received.

[00442] The same computes bi as the following.

[00443] If more than 2/3 of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the same configures 𝑏𝑖 ≜ 0.

[00444] Otherwise, if more than 2/3 of all valid 𝑚𝑗𝑟, 𝑠 − 1 that he received are of the form (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the even sets 𝑏𝑖 ≜ 1.

[00445] Otherwise, let 𝑆𝑉𝑖𝑟, 𝑠 − 1 be the set of verifiers

(r, s - 1) from which he received a valid message 𝑚𝑗𝑟, 𝑠 − 1. It configures 𝑏𝑖 ≜ 𝑙𝑠𝑏 (𝑚𝑖𝑛𝑗∈𝑆𝑉 𝑟, 𝑠 − 1 𝐻 (𝜎𝑗𝑟, 𝑠 − 1)). 𝑖

[00446] It computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagates 𝑚𝑖𝑟, 𝑠. Stage m + 3: The Last Stage of 𝐵𝐵𝐴 ∗ 20

[00447] Instructions for each user i ∈ PKr-k: User i starts his own Stage m + 3 of cycle r as soon as he meets Br-1.

[00448] • User i computes Qr-1 from the third component of Br-1 and checks whether or not i ∈ SVr, m + 3.

[00449] ● If i ∉ SVr, m + 3, then i stops its own execution of Step m + 3 immediately.

[00450] ● If i ∈ SVr, m + 3, then it does the following.

[00451] - It waits until an amount of time 𝑡𝑚 + 3 ≜ 𝑡𝑚 + 2 + 2𝜆 = (2𝑚 + 3) 𝜆 + Λ has elapsed.

[00452] - Final Condition 0: The same instructions as for the Fixed Currency-In-0 steps.

[00453] - Final Condition 1: The same instructions as for the Fixed-Currency-In-0 steps.

[00454] - Otherwise, at the end of the wait, user i performs the following.

[00455] It configures 𝑜𝑢𝑡𝑖 ≜ 1 and 𝐵𝑟 ≜ 𝐵𝜀𝑟.

[00456] The same computes the message 𝑚𝑖𝑟, 𝑚 + 3 = (𝐸𝑆𝐼𝐺𝑖 (𝑜𝑢𝑡𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝐻 (𝐵𝑟)), 𝜎𝑖𝑟, 𝑚 + 3), destroys your secret ephemeral key 20 With an immense probability that 𝐵𝐵𝐴 ∗ ended before this stage, and that stage is specified for completeness.

𝑠𝑘𝑖𝑟, 𝑚 + 3 and then propagate 𝑚𝑖𝑟, 𝑚 + 3 to certify Br.21

[00457] Reconstruction of the R-Cycle Block by Non-Verifiers

[00458] Instructions for each user i in the system: User i starts his own cycle r as soon as he knows Br-1, and waits for block information as follows.

[00459] - If, during such a wait and at any point in time, there is a line v and a step s' so that

[00460] (a) 5 ≤ s '≤ m + 3 with s' - 2 ≡ 0 mod 3,

[00461] (b) i received at least tH valid messages ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣), 𝜎𝑗𝑟, 𝑠), and r, 1

[00462] (c) i received a valid message 𝑚𝑗𝑟, 1 = (𝐵𝑗𝑟, 𝑒𝑠𝑖𝑔𝑗 (𝐻 (𝐵𝑗𝑟)), 𝜎𝑗𝑟, 1) with 𝑣 = 𝐻𝐵𝑗𝑟, then i for its own execution of cycle r immediately; sets 𝐵𝑟 = 𝐵𝑗𝑟; and configure your own CERTr ′ −1 as the set of messages 𝑚𝑗𝑟, 𝑠 of substep (b).

[00463] - If, during such a wait and at any point in time, there is a step s' so that

[00464] (a ’) 6 ≤ s '≤ m + 3 with s' - 2 ≡ 1 mod 3, and

[00465] (b ') i received at least tH valid messages ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠), then i for its own execution of cycle r immediately; sets 𝐵𝑟 = 𝐵𝜀𝑟; and configure your own CERTr ′ −1 as the set of messages 𝑚𝑗𝑟, 𝑠 substep (b ').

[00466] - If, during such a wait and at any point in time, i received at least tH valid messages 𝑚𝑗𝑟, 𝑚 + 3 = 21 A certificate from Step m + 3 does not need to include ESIG i (outi). This is included for the purpose of uniformity only: certificates now have a uniform format regardless of which stage they were generated.

(𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝐻 (𝐵𝜀𝑟)), 𝜎𝑗𝑟, 𝑚 + 3), then, i for its own execution of cycle r immediately, sets 𝐵𝑟 = 𝐵𝜀𝑟 and sets its own CERTr as the set of messages 𝑚𝑗𝑟, 𝑚 +3 to 1 and 𝐻 (𝐵𝜀𝑟). 6 Algorand'2

[00467] In this section, a version of Algorand 'is built that works under the following assumption.

[00468] ASSUMPTION OF A HONEST PART OF USERS: More than 2/3 of users in each PKr are honest.

[00469] Section 7 shows how to replace the above assumption with the desired Most Honest Part of Money assumption.

6.1 Notations and Additional Parameters for Algorand'2 Notations

[00470] ● μ ∈ ℤ +: a pragmatic upper limit for the number of steps that, with immense probability, will actually be performed in one cycle. (As will be noted, the μ parameter controls how many ephemeral keys a user prepares in advance for each cycle.)

[00471] ● Lr: a random variable that represents the number of Bernoulli tests needed to observe a 1, when each test 𝑝ℎ is 1 with probability. Lr will be used to limit the time required to generate the Br block in a superior way.

[00472] ● tH: a lower limit for the number of honest verifiers in a step s> 1 of cycle r, so that with the immense probability (given n and p), there are> tH honest verifiers in SVr, s. Parameters

[00473] ● Relationships between several parameters.

[00474] - For each step s> 1 of cycle r, n is chosen so that, with immense probability, | HSVr, s | > tH and | HSVr, s | + 2 | MSVr, s | <2tH.

[00475] It is observed that the two inequalities above together imply | HSVr, s | > 2 | MSVr, s |: that is, there is an honest majority of 2/3 among the selected verifiers.

[00476] The closer to 1 the h value is, the smaller n needs to be. In particular, Chernoff limits (variants of) are used to ensure that the desired conditions remain with immense probability.

[00477] ● Specific choices of important parameters.

[00478] - F = 10-18.

[00479] - n ≈ 4,000, tH ≈ 0.69n, k = 70.

6.2 Implementation of Ephemeral Keys in Algorand'2

[00480] Recalling that a verifier i ∈ SVr, s digitally signs his message 𝑚𝑖𝑟, 𝑠 of steps s in cycle r, with respect to an ephemeral public key 𝑝𝑘𝑖𝑟, 𝑠, with the use of an ephemeral secret key 𝑠𝑘𝑖𝑟, 𝑠 that it immediately destroys after use. When the number of possible steps that a cycle can perform is capped by a given integer μ, it has already been observed how to handle practically ephemeral keys. For example, as explained in Algorand'1 (where μ = m + 3), to handle all of your possible ephemeral keys, from a cycle r 'to a cycle r' + 106, i generates a pair (PMK, SMK ), where PMK is the public master key of an identity-based subscription scheme, and SMK is its corresponding secret master key. User i publishes PMK and uses SMK to generate the secret key for each possible ephemeral public key (and destroys SMK after doing so). The set of ephemeral public keys of i for the relevant cycles is S = {i} x {r ',. . . , r '+ 106} x {1,. . . , μ}. (As discussed, as cycle r '+ 106 approaches, i “updates” its pair (PMK, SMK).)

[00481] In practice, if μ is large enough, an Algorand'2 cycle will have no more than μ steps. In principle, however, there is a remote possibility that for some cycle r the number of steps actually performed will exceed μ. When this happens, i would not be able to sign your message 𝑚𝑖𝑟, 𝑠 for any step s> μ, due to the fact that it had prepared in advance only μ secret keys for cycle r. In addition, it cannot prepare and publish a new ephemeral key deposit, as previously discussed. In fact, to do this, it would need to insert a new public master key PMK 'in a new block. But, if cycle r performs more and more steps, no new blocks would be generated.

[00482] However, there are solutions. For example, i can 𝑟, 𝜇 use the last ephemeral key of cycle r, 𝑝𝑘𝑖, as follows. It generates another deposit of key pairs for cycle r - for example, (1) generate 𝑃𝑀𝐾, ̅̅̅̅̅̅ another master key pair (̅̅̅̅̅̅̅ 𝑆𝑀𝐾); (2) use this pair to generate another, 6 ̅̅̅ ̅̅̅, 𝜇 + 1,…, 𝑠𝑘 say, 106 ephemeral keys 𝑠𝑘 ̅̅̅ ̅̅̅, 𝜇 + 10, corresponding to 𝑖 𝑖 𝑟, 𝜇 steps μ + 1, .. ., μ + 106 of cycle r; (3) use 𝑠𝑘𝑖 to digitally sign ̅̅̅̅̅̅̅ 𝑟, 𝜇 𝑃𝑀𝐾 (and any message (r, μ) if i ∈ SVr, μ), with respect to 𝑝𝑘𝑖; and (4) 𝑟, 𝜇 delete ̅̅̅̅̅̅ 𝑆𝑀𝐾 and 𝑠𝑘𝑖. If i becomes a verifier in a step μ + s with 𝑟, 𝜇 + 𝑠 s ∈ {1,. . . , 106}, then, i digitally signs your message (r, μ + s) 𝑚𝑖 with respect to your new key ̅̅ 𝑝𝑘̅̅ 𝑟, 𝜇 + 𝑠 = (𝑖, 𝑟, 𝜇 + 𝑠). Of course, in order to 𝑖 verify this signature from i, others need to be certain that this key ̅̅̅̅̅̅̅. Thus, public corresponds to the new public master key of i 𝑃𝑀𝐾 ̅̅̅̅̅̅̅ with respect to this signature, i transmits its digital signature from 𝑃𝑀𝐾 𝑟, 𝜇 to 𝑝𝑘𝑖.

[00483] Of course, this approach can be repeated, as many times as necessary, if cycle r continues for more and more stages! The last secret ephemeral key is used to authenticate a new master public key, and thus another ephemeral key store for cycle r. And so on.

6.3 The Royal Algorand'2 Protocol

[00484] Remember again that, at each step s of a cycle r, a verifier i ∈ SVr, s uses its long-term public-secret key pair to produce its credential, 𝜎𝑖𝑟, 𝑠 ≜ 𝑆𝐼𝐺𝑖 (𝑟, 𝑠 , 𝑄𝑟 − 1), as well as GIS (Qr-1) in the case s = 1. Verifier i uses its ephemeral key pair, (𝑝𝑘𝑖𝑟, 𝑠, 𝑠𝑘𝑖𝑟, 𝑠), to sign any other message m that may be required . For simplicity, esigi (m) is written instead of 𝑠𝑖𝑔𝑝𝑘𝑟, 𝑠 (𝑚), to denote adequada appropriate ephemeral signature of i de m at this stage, and ESIGi (m) is written instead of 𝑠𝑖𝑔𝑝𝑘𝑟, 𝑠 (𝑚 ) ≜ (𝑖, 𝑚, 𝑒𝑠𝑖𝑔𝑖 (𝑚)). 𝑖 Stage 1: Block Proposal

[00485] Instructions for each user i ∈ PKr-k: User i starts his own Step 1 of cycle r as soon as he has CERTr-1, which allows i to compute unambiguously H (Br-1) and Qr -1.

[00486] ● User i uses Qr-1 to check whether or not i ∈ SVr, 1. If i ∉ SVr, 1, it does nothing for Step 1.

[00487] ● If i ∈ SVr, 1, that is, if i is a potential leader, then he does the following.

[00488] (a) If i have observed B0,. . . , Br-1 by themselves 𝑗 (any 𝐵 𝑗 = 𝐵𝜀 can easily be derived from its hash value in CERTj and is thus assumed to be “observed”), then collects the r-cycle payments that have been propagated to the same so far and computes a set of maximum payments 𝑃𝐴𝑌𝑖𝑟 from it.

[00489] (b) If i has not observed all B0,. . . , Br-1 still, then, it sets 𝑃𝐴𝑌𝑖𝑟 = 𝜙.

[00490] (c) Next, i computes its “candidate block” 𝐵𝑖𝑟 = (𝑟, 𝑃𝐴𝑌𝑖𝑟, 𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝐻𝐵𝑟 − 1).

[00491] (c) Finally, i computes the message 𝑚𝑖𝑟, 1 = (𝐵𝑖𝑟, 𝑒𝑠𝑖𝑔𝑖 (𝐻 (𝐵𝑖𝑟)), 𝜎𝑖𝑟, 1), destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 1 and then propagates two messages, 𝑚𝑖𝑟, 1 and (𝑆𝐼𝐺𝑖 (𝑄𝑟 − 1), 𝜎𝑖𝑟, 1), separately, but simultaneously.22 Selective Propagation

[00492] To shorten the overall execution of Step 1 and the complete cycle, it is important that the messages (r, 1) are selectively propagated. That is, for each user already in the system,

[00493] ● For the first message (r, 1) that it received and successfully verified, 23 the possibility of it containing a block or being just a credential and a Qr-1 signature, the participant already propagates the same as normal.

[00494] ● For all other messages (r, 1) that the participant already receives and verifies successfully, he propagates these only if the hash value of his credential contains the smallest within the hash values of the credentials contained in all messages ( r, 1) that it has successfully received and verified so far.

[00495] ● However, if j receives two different messages of the form 𝑚𝑖𝑟, 1 from the same participant i, 24 the same discards the second regardless of what is the credential hash value of i.

[00496] It is observed that, under selective propagation it is useful for each potential leader i to propagate his credential 𝜎𝑖𝑟, 1 separately from 𝑚𝑖𝑟, 1: 25 those small messages that travel faster than the blocks, guarantee the immediate propagation of 𝑚𝑖𝑟, 1 where the credentials contained have small hash values, while causing those with large hash values to disappear quickly. Step 2: The First Step of the Graduate Consensus Protocol 22 When i is the leader, GIS (Qr-1) allows others to compute Qr = H (GIS (Qr-1), r). In other words, all signatures are corrected and, if it is of the form 𝑚𝑖𝑟, 1, both the block and its hash are valid - although i does not verify the possibility of the included set of payments being maximum for its bidder or not. 24 Which means that i is malicious. 25 Thanks to Georgios Vlachos for suggesting this.

GC

[00497] Instructions for each user i ∈ PKr-k: User i starts his own Step 2 of cycle r as soon as he has CERTr-1.

[00498] ● User i expects a maximum amount of time 𝑡2 ≜ 𝜆 + Λ. While waiting, i act as follows.

[00499] 1. After waiting for time 2λ, he finds the user ℓ so that 𝐻 (𝜎ℓ𝑟, 1) ≤ 𝐻 (𝜎𝑗𝑟, 1) for all credentials 𝜎𝑗𝑟, 1 that are part of the messages successfully verified (r , 1) that it has received so far.26

[00500] 2. If it received a Br-1 block, which is compatible with the hash value H (Br-1) contained in CERTr-1.27 and if it received from mensagem a valid message 𝑚 𝑟, 1 𝑟 𝑟 𝑟, 1 28 ℓ = (𝐵ℓ, 𝑒𝑠𝑖𝑔ℓ (𝐻 (𝐵ℓ)), 𝜎ℓ), then i stops waiting and sets 𝑣′1 ≜ (𝐻 (𝐵ℓ𝑟), ℓ).

[00501] 3. Otherwise, when time t2 runs out, i sets 𝑣′1 ≜⊥.

[00502] 4. When the value of v'i has been established, i computes Qr-1 from CERTr-1 and checks whether or not i ∈ SVr, 2.

[00503] 5. If i ∈ SVr, 2, i computes the message 𝑚𝑖𝑟, 2 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑣 ′ 𝑖), 𝜎𝑖𝑟, 2), 29 destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 2 and then propagates 𝑚𝑖𝑟, 2 . Otherwise, I stop without propagating anything. Step 3: The Second GC Step 26 Essentially, user i confidentially decides that the leader of cycle r is user ℓ. 27 Evidently, if CERTr-1 indicates that 𝐵𝑟 − 1 = 𝐵𝜀𝑟 − 1, then i probably already “received” Br- 1 by the time it has CERTr-1. 28 Again, participant signatures ℓ and hashes are all successfully verified, and 𝑃𝐴𝑌ℓ𝑟 at 𝐵ℓ𝑟 is a set of payments valid for cycle r - although i does not check whether or not 𝑃𝐴𝑌ℓ𝑟 be maximum for ℓ. If 𝐵ℓ𝑟 contains an empty payment set, then there is really no need to i observe Br-1 before checking whether 𝐵ℓ𝑟 is valid or not. 29 The message 𝑚𝑖𝑟, 2 signals that the participant i considers the first component of v'i as the hash of the next block, or considers the next block as empty.

[00504] Instructions for each user i ∈ PKr-k: User i starts his own Step 3 of cycle r as soon as he has CERTr-1.

[00505] ● User i expects a maximum amount of time 𝑡3 ≜ 𝑡2 + 2𝜆 = 3𝜆 + Λ. While waiting, i act as follows.

[00506] 1. If there is a value v, so that it has received at least tH valid messages 𝑚𝑗𝑟, 2 of the form (𝐸𝑆𝐼𝐺𝑖 (𝑣), 𝜎𝑗𝑟, 2), without any contradiction, 30 then the same for de wait and set v '= v.

[00507] 2. Otherwise, when time t3 runs out, it sets v '= ⊥.

[00508] 3. When the value of v 'has been established, i computes Qr-1 from CERTr-1 and checks whether or not i ∈ SVr, 3.

[00509] 4. If i ∈ SVr, 3, then i computes the message 𝑚𝑖𝑟, 3 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑣 ′), 𝜎𝑖𝑟, 3), destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 3 and then propagates 𝑚𝑖𝑟, 3 . Otherwise, I stop without propagating anything. Step 4: GC Output and The First de ∗ Step

[00510] Instructions for each user i ∈ PKr-k: User i starts his own Step 4 of cycle r as soon as i finishes his own Step 3.

[00511] ● User i waits a maximum amount of time 2λ.31 While waiting, i acts as follows.

[00512] 1. The same computes vi and gi, the GC output, as follows.

That is, he did not receive two valid messages containing ESIGj (v) and a different 𝐸𝑆𝐼𝐺1 (𝑣̂), respectively, from participant j. Here and from here, except in the Final Conditions defined above, whenever an honest participant wants messages in a certain way, messages that contradict each other are never counted or considered to be valid.

31 Thus, the maximum total amount of time since i starts your Step 1 of cycle r can be 𝑡4 ≜ 𝑡3 + 2𝜆 + 5𝜆 + Λ.

[00513] (a) If there is a value v '≠ ⊥ so that it has received at least tH valid messages 𝑚𝑙𝑟, 3 = (𝐸𝑆𝐼𝐺𝑗 (𝑣 ′), 𝜎𝑗𝑟, 3), then it stops waiting and sets 𝑣𝑖 ≜ 𝑣 ′ and 𝑔1 ≜ 2.

[00514] (b) If it has received at least tH valid messages 𝑚𝑗𝑟, 3 = (𝐸𝑆𝐼𝐺𝑗 (⊥), 𝜎𝑗𝑟, 3), then it stops waiting and configures 𝑣𝑖 ≜⊥ and 𝑔1 ≜ 0.32

[00515] (c) Otherwise, when the 2λ time runs out, if 𝑡 there is a value v '≠ ⊥ so that it has received at least ⌈ 𝐻 ⌉ 2 𝑟, 𝑗 valid messages 𝑚𝑗 = (𝐸𝑆𝐼𝐺𝑗 (𝑣 ′), 𝜎𝑗𝑟, 3), then, it configures 𝑣1 ≜ 𝑣 ′ and 𝑔𝑖 ≜ 1.33

[00516] (d) Otherwise, when the 2λ time runs out, it configures 𝑣𝑖 ≜⊥ and ≜⊥ ≜ 0.

[00517] 2. When the values vi and gi have been established, i computes bi, the entry of 𝐵𝐵𝐴 ∗, as follows: 𝑏𝑖 ≜ 0, if 𝑔𝑖 = 2, and 𝑏𝑖 ≜ 1, otherwise.

[00518] 3. i computes Qr-1 from CERTr-1 and checks whether or not i ∈ SVr, 4.

[00519] 4. If i ∈ SVr, 4, it computes the message 𝑚𝑖𝑟, 4 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 4), destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 4 and propagates 𝑚𝑖𝑟, 4 . Otherwise, I stop without propagating anything. Step s, 5 ≤ s ≤ m + 2, s - 2 mod 0 mod 3: One Coin-Fixed-In-0 Step of 0 ∗

[00520] Instructions for each user i ∈ PKr-k: User i starts his own Step s of cycle r as soon as he finishes his 32 Regardless of whether Step (b) is in the protocol or does not affect its accuracy. However, the presence of Step (b) allows Step 4 to finish in less than 2λ time if enough Step-3 verifiers have “signed ⊥”. 33 It can be proved that the v 'in that case, if any, must be unique.

Step s - 1 itself.

[00521] ● User i waits a maximum amount of time 2λ.34 While waiting, i acts as follows.

[00522] - Final Condition 0: If at any point there is a line v ≠ ⊥ and a step s' so that

[00523] (a) 5 ≤ s' ≤ s, s' - 2 ≡ 0 mod 3 - that is, Step s' is a Coin-Fixed-In-0 step,

[00524] (b) i received at least tH valid messages ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣), 𝜎𝑗𝑟, 𝑠), 35 and

[00525] (c) i received a valid message (𝑆𝐼𝐺𝑗 (𝑄𝑟 − 1), 𝜎𝑗𝑟, 1) with j being the second component of v,

[00526] then, i stops waiting and ends its own execution of Step s (and, in fact, of cycle r) immediately without propagating anything like a checker (r, s); sets H (Br) as the first component of v; and configure your own CERTr as the set of ′ −1 messages 𝑚𝑗𝑟, 𝑠 from step (b) in conjunction with (𝑆𝐼𝐺𝑗 (𝑄𝑟 − 1), 𝜎𝑗𝑟, 1) .36

[00527] - Final Condition 1: If at any point there is a step s' so that

[00528] (a ') 6 ≤ s' ≤ s, s '- 2 mod 1 mod 3 - that is, Step s' is step 34 Thus, the maximum total amount of time since i starts its Step 1 of the cycle r can be 𝑡𝑠 ≜ 𝑡𝑠 − 1 + 2𝜆 = (2𝑠 - 3) 𝜆 + Λ. 35 Such a message from participant j is counted even if participant i has also received a message from j that signs for 1. Things similar to Final Condition 1. As shown in the analysis, this is done to ensure that all honest users know CERTr on time λ from each other. 36 User i now knows H (Br) and his own cycle r ends. It just needs to wait until the really Br block is propagated to it, which can take an additional time. It still helps to propagate messages as a generic user, but does not initiate any propagation as a verifier (r, s). In particular, it helped to propagate all messages in that CERTr, which is sufficient for our protocol. Note that it must also set deve ≜ 0 for the binary BA protocol, but bi is not necessary in this case anyway. Similar things for all future instructions.

Fixed-Currency-In-1, and

[00529] (b ’) i received at least tH valid messages ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 = (𝐸𝑆𝐼𝐺𝑖 (1), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠), 37

[00530] then, i stops waiting and ends its own execution of Step s (and, in fact, of cycle r) immediately without propagating anything like a checker (r, s); sets 𝐵𝑟 = 𝐵𝜀𝑟; and configures its own ′ −1 CERTr as the message set 𝑚𝑗𝑟, 𝑠 substep (b ').

[00531] - If at any point it received at least tH ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 valid in the form (𝐸𝑆𝐼𝐺𝑖 (1), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠), then the same stops waiting and sets 𝑏1 ≜ 1.

[00532] - If at any point it received at least tH ′ −1 ′ −1 𝑚𝑗𝑟, 𝑠 valid in the form (𝐸𝑆𝐼𝐺𝑖 (0), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠), but they do not agree on the same v then stops waiting and sets 𝑏𝑖 ≜ 0.

[00533] - Otherwise, when the time 2λ runs out, i sets 𝑏𝑖 ≜ 0.

[00534] - When the bi value has been established, i computes Qr-1 from CERTr-1 and checks the possibility of i ∈ SVr, s.

[00535] - If i ∈ SVr, s, i computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), where vi is the value that was computed in Step 4, destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagate 𝑚𝑖𝑟, 𝑠. Otherwise, I stop without propagating anything.

[00536] Stage s, 6 ≤ s ≤ m + 2, s - 2 ≡ 1 mod 3: One-∗ Coin-Fixed-In-1 Stage

[00537] Instructions for each user i ∈ PKr-k: User i starts his own Step s of cycle r as soon as he finishes his 37 In this case, it doesn't matter which vj's are.

Step s - 1 itself.

[00538] ● User i expects a maximum amount of time 2λ. While waiting, i act as follows.

[00539] - Final Condition 0: The same instructions as in a fixed-currency-in-0 stage.

[00540] - Final Condition 1: The same instructions as in a fixed-currency-in-0 stage.

[00541] - If at any point it received at least tH 𝑚𝑗𝑟, 𝑠 − 1 valid in the form (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then it stops waiting and configures 𝑏𝑖 ≜ 0.38

[00542] - Otherwise, when time 2λ runs out, i configures 𝑏𝑖 ≜ 1.

[00543] - When the value of bi has been established, i computes Qr-1 from CERTr-1 and checks the possibility of i ∈ SVr, s.

[00544] - If i ∈ SVr, s, i computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), where vi is the value that was computed in Step 4, destroys your secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagate 𝑚𝑖𝑟, 𝑠. Otherwise, I stop without propagating anything.

[00545] Step s, 7 ≤ s ≤ m + 2, s - 2 mod 2 mod 3: One Etapa ∗ Coin-Genuinely-Launched Step

[00546] Instructions for each user i ∈ PKr-k: User i starts his own Step s of cycle r as soon as he finishes his own step s - 1.

[00547] ● User i expects a maximum amount of time 2λ. While waiting, i act as follows.

[00548] - Final Condition 0: The same instructions as in a 38 It is observed that receiving t valid messages (r, s - 1) that sign for 1 would mean the

H Final Condition 1.

Fixed-Currency-In-0 stage.

[00549] - Final Condition 1: The same instructions as in a fixed-currency-in-0 stage.

[00550] - If at any point it received at least tH 𝑚𝑗𝑟, 𝑠 − 1 valid in the form (𝐸𝑆𝐼𝐺𝑗 (0), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then it stops waiting and configures 𝑏𝑖 ≜ 0.

[00551] - If at any point it received at least tH 𝑚𝑗𝑟, 𝑠 − 1 valid in the form (𝐸𝑆𝐼𝐺𝑗 (1), 𝐸𝑆𝐼𝐺𝑗 (𝑣𝑗), 𝜎𝑗𝑟, 𝑠 − 1), then the same stops waiting and configures 𝑏𝑖 ≜ 1.

[00552] - Otherwise, when time 2λ runs out, let 𝑆𝑉𝑖𝑟, 𝑠 − 1 be the set of verifiers (r, s - 1) from which it has received a valid message 𝑚𝑗𝑟, 𝑠 − 1, i configures 𝑏𝑖 ≜ 𝑙𝑠𝑏 (𝑚𝑖𝑛𝑗∈𝑆𝑉 𝑟, 𝑠 − 1 𝐻 (𝜎𝑗𝑟, 𝑠 − 1)). 𝑖

[00553] - When the value has been established, i computes Qr-1 from CERTr-1 and checks the possibility of i ∈ SVr, s.

[00554] - If i ∈ SVr, s, i computes the message 𝑚𝑖𝑟, 𝑠 ≜ (𝐸𝑆𝐼𝐺𝑖 (𝑏𝑖), 𝐸𝑆𝐼𝐺𝑖 (𝑣𝑖), 𝜎𝑖𝑟, 𝑠), where vi is the value that was computed in Step 4, destroys its secret ephemeral key 𝑠𝑘𝑖𝑟, 𝑠 and then propagate 𝑚𝑖𝑟, 𝑠. Otherwise, I stop without propagating anything.

[00555] Observation. In principle, as considered in subsection 6.2, the protocol can arbitrarily perform many steps in the same cycle. If this happens, as discussed, a user i ∈ SVr, s with s> μ has exhausted his deposit of pre-generated ephemeral keys and needs to authenticate his message (r, s) 𝑚𝑖𝑟, 𝑠 by a “cascade” of ephemeral keys. In this way, the message from i becomes a little longer and the transmission of these longer messages will take a little longer. Consequently, after so many steps in a given cycle, the value of the parameter λ will automatically be increased slightly. (But this is reverted to the original λ once a new block is produced and a new cycle begins.) Reconstruction of the R-Cycle Block by Non-Verifiers

[00556] Instructions for each user i in the system: User i starts his own cycle r as soon as he has CERTr-1.

[00557] ● i follows the instructions for each step of the protocol, participates in the propagation of all messages, but does not start any propagation in one step if it does not have a verifier in it.

[00558] ● i ends its own cycle r by entering Final Condition 0 or Final Condition 1 at some stage, with the corresponding CERTr.

[00559] ● From there, it starts its r + 1 cycle while waiting to receive the real block Br (unless it has already received this one), whose hash H (Br) was linked by CERTr. Again, if CERTr indicates that 𝐵 𝑟 = 𝐵𝜀𝑟, i knows Br the moment it has CERTr. 7 Algorand 'Protocol With Most Honest Money

[00560] Now, finally, it will be shown how to replace the Most Honest Share of Users assumption with the much more significant Most Honest Share of Money assumption. The basic idea is (in a way of proof of proof) "to select a user i ∈ PKr-k to belong to SVr, s with a weight (that is, decision-making power) proportional to the amount of money owned by i". 39

[00561] By the assumption of HMM, one can choose the possibility that the quantity must belong to the cycle r - k or no (beginning 39 It must be said pKr-k-2.000 in order to replace the continuous participation. For simplicity, since a person may wish to require continuous participation in any way, PKr-k is used as before, in order to perform one less parameter.

do) cycle r. Assuming that continuous participation does not bother, the last choice is chosen. (To remove continuous participation, one must choose the other choice. Better said, for the amount of money owned in the cycle r - k - 2,000.)

[00562] There are many ways to implement this idea. The simplest way would be to have each key retain a maximum of 1 unit of money and then select n users i randomly from PKr-k so (𝑟) that 𝑎𝑖 = 1. The Simplest Deployment

[00563] The next simplest deployment may be to require that each public key has a maximum amount of M money, for some fixed M. The M value is small enough compared to the total amount of money in the system, so that the probability that a key belongs to the set of verifiers of more than one step in - say - k cycles is insignificant. Then, a key i ∈ PKr-k, which has a (𝑟) amount of money 𝑎𝑖 in cycle r, is chosen to belong to SVr, s if (𝑟) 𝑟 − 1) 𝑎𝑖. 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄) ≤ 𝑝..

𝑀

[00564] And everything happens as before. A More Complex Deployment

[00565] The last deployment “forced a rich participant in the system to have many keys”.

[00566] An alternative deployment, described below, generalizes the notion of state and considers that each user i consists of K + 1 copies (i, v), each of which is independently selected as 𝑟, 𝑠 𝑟, 𝑠 a verifier, and will have its own ephemeral key (𝑝𝑘𝑖, 𝑣, 𝑠𝑘𝑖, 𝑣) in one step (𝑟) s of a cycle r. The K value depends on the amount of money 𝑎𝑖 that i has in cycle r.

[00567] It is now observed how such a system works in more detail.

[00568] Number of Copies Let n be the expected target cardinality of each verifier set, and let the amount of money be owned by a user i in cycle r. Let Ar be the total amount of money owned by users in PKr-k in cycle r, that is, (𝑟) 𝐴𝑟 = ∑ 𝑎𝑖. 𝑖∈𝑃𝐾𝑟 − 𝑘

[00569] If i is a PKr-k user, then copies of i are (i, 1),. . . , (i, K + 1), where (𝑟) 𝑛.𝑎𝑖 𝐾 = ⌊ ⌋. 𝐴𝑟 (𝑟)

[00570] EXAMPLE n = 1,000, Ar = 109 and 𝑎𝑖 = 3.7 million are allowed. So, 103. (3.7 .106) 𝐾 = ⌊ ⌋ = ⌊3.7⌋ = 3. 109

[00571] Verifiers and Credentials i is allowed to be a PKr-k user with K + 1 copies.

[00572] For each v = 1,. . . , K, copy (i, v) belongs to SVr, s 𝑟, 𝑠 automatically. That is, the credential of i is 𝜎𝑖, 𝑣 ≜ 𝑆𝐼𝐺𝑖 ((𝑖, 𝑣), 𝑟, 𝑠, 𝑄𝑟 − 1), 𝑟, 𝑠 but the corresponding condition becomes. 𝐻 (𝜎𝑖, 𝑣) ≤ 1, which is always true.

[00573] For copying (i, K + 1), for each Step s of cycle r, i checks the possibility of (𝑟) 𝑛. 𝐻 (𝑆𝐼𝐺𝑖 ((𝑖, 𝐾 + 1), 𝑟, 𝑠, 𝑄𝑟 − 1)) ≤ 𝑎𝑖 - 𝐾. 𝐴𝑟

[00574] If so, the copy (i, K + 1) belongs to SVr, s. To prove this, i propagates the credential 𝑟, 1 𝜎𝑖, 𝐾 + 1 = 𝑆𝐼𝐺𝑖 ((𝑖, 𝐾 + 1), 𝑟, 𝑠, 𝑄𝑟 − 1). (𝑟)

[00575] EXAMPLE As in the previous example, let n = 1K, 𝑎𝑖 = 3.7 M, Ar = 1B, and i have 4 copies: (i, 1),. . . , (i, 4). Then, the first 3 copies belong to SVr, s automatically. For the 4th, conceptually, Algorand 'independently launches a biased currency, whose probability for Cara is 0.7. The copy (i, 4) is selected if and only if the currency gives Cara.

[00576] (Of course, this biased coin launch is implemented by hashing, signing and comparing - as was done throughout this order - in order to allow i to prove its result.)

[00577] Business as usual Explaining how verifiers are selected and how their credentials are computed at each stage of a cycle r, the execution of a cycle is similar to the one already explained. 8 Algorand With The Assumption Of No Network Partition

[00578] Essentially, at Algorand, the blocks are generated in cycles. In an r cycle,

[00579] (1) A suitably accredited leader proposes a new bloc and then

[00580] (2) Properly accredited users execute, through several stages, an appropriate Byzantine agreement (BA) protocol in the proposed block.

[00581] The preferred BA protocol is 𝐵𝐴 ∗. The proposal block stage can be considered as step 1, so that the steps of 𝐵𝐴 ∗ are 2, 3, ...

[00582] Only one suitable user i, randomly selected from among the users in the system, is authorized to send a message 𝑚𝑖𝑟, 𝑠 in step s of cycle r. Algorand is very fast and secure due to such a user i check the possibility of him being allowed to speak. If that is the case, user i actually obtains a proof, a credential. If it is your turn to speak in step s of cycle r, i propagates both your credential, 𝜎𝑖𝑟, 𝑠 and your digitally signed message 𝑚𝑖𝑟, na on the network. The credential proves to other users that they must take the message 𝑚𝑖𝑟, 𝑠 into account.

[00583] A necessary condition for user i to be authorized to speak in step s of cycle r is that it was already in the system a few cycles ago. Specifically, k cycles before cycle r, where k is a parameter called the “look back” parameter. That is, to be eligible to speak in cycle r, i must belong to PKr-k, the set of all public keys / users already in the system in cycle r - k. (Users can be identified with their public keys.) This condition is easy to verify in the sense that it is derivable from the block chain.

[00584] The other condition is that 𝐻 (𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄𝑟 − 1)) <𝑝

[00585] where p is a certain probability that controls the expected number of verifiers in SVr, s, that is, the set of users authorized to speak in step s of cycle r. If this condition is met, then i's credential is defined as 𝜎𝑖𝑟, 𝑠 ≜ 𝑆𝐼𝐺𝑖 (𝑟, 𝑠, 𝑄𝑟 − 1).

[00586] Of course, only i can verify the possibility that it belongs to SVr, s. All other users, who lack knowledge about i's secret signature key, have no idea about that. However, if i ∈ SVr, s, then i can demonstrate that this is the case for anyone propagating their credential 𝜎𝑖𝑟, 𝑠 given the chain of blocks so far. Recalling, in fact, that (1) Qr-1 is easily computable from the previous block, Br-1, although essentially enough blocks are unpredictable enough before, and (2) anyone can check the digital signatures of i ( regarding your long-term key in the system).

[00587] Bearing in mind that, in Algorand versions so far, new blocks are proposed only once in a cycle r, - that is, in step 1. The BA protocol allows users to reach a consensus on one of these (or the empty block), and do not additionally propose new blocks or again propose blocks that have already been proposed for cycle r. When the network is not partitioned and the upper limits for the time to propagate messages are met, users reach consensus effectively and safely. 9 Algorand Resistant Against Network Partition

[00588] A new Algorand modality is now described, Algorand2, which dispenses with the assumption of any network partitions. The new protocol is presented under the assumption of Most Honest Users (HMU). Using the same approach as in Section 7, the HMU assumption can be replaced by the Most Honest Money (HMM) assumption.

9.1 Communication Model

[00589] When the network is not partitioned, small messages take time λ to propagate to all honest users, and blocks take time λ to propagate to all honest users, as before. When the network is partitioned into more than one group of users, the opponent determines whether a message m propagated by a user from one group will be delivered to users in other groups, who in other groups will receive m and when they will receive m. A network partition can be resolved at an indefinite time in the future and messages propagated during the partition are delivered to all users after the partition is resolved. For simplicity, but without any desired limitation, the new modality is described assuming that messages propagated during a network partition are delivered to all users immediately after the partition is resolved. For example, if a network partition lasts from time t1 to time t2, and M is the set of messages propagated during the partition, then all users receive messages in M for time t2. Those skilled in the art will realize that the system described in this document can handle other situations in which messages in M take a certain amount of time to reach all users or are propagated again by the users who receive them.

9.2 Parameter Choices

[00590] The expected committee size n and the tH limit are chosen according to the following conditions. Let PK be the set of users, HPK and MPK respectively the set of honest and malicious users. Let HPK1 be an arbitrary subset of HPK half the size. When each user i ∈ PK is selected independently and 𝑛 randomly with probability 𝑝 = | 𝑃𝐾 |, be HSV1 and MSV, respectively, the set of those selected from HPK1 and MPK. So, with immense probability, | HSV1 | + | MSV | <tH.

[00591] Furthermore, let HSV be the group of those selected from among HPK. So, with immense probability, | HSV | ≥ tH.

[00592] It is observed that the two conditions above imply | HSV | > 2 | MSV |.

[00593] For example, when h = 80% and PK is large enough, one can choose n = 3,500 and tH = 2,625.

9.3 General Structure

[00594] Cycles. The protocol generates a block at each cycle. A cycle consists of periods 1, 2, ... and a period consists of steps 1, 2, .... At any point in time, each user i is working on exactly one cycle-period pair. In particular, r.p is used to refer to period p of cycle r.

[00595] In step 1 of period 1, users propose new blocks. In step 1 of the following periods, users propose new blocks or resubmit blocks that have already been proposed in previous periods.

[00596] Committees. Each step s of the r.p period has a committee chosen by cryptographic self-selection, denoted by SVr, p, s. The same look-back parameter is used as in Section 4.1, denoted by k. For example, k = 70. A user i is eligible to be selected on the cycle-r committees if i ∈ PKr-k. The committee for Step 1 of each period has an expected size n1 (for example, 35) and all other committees have an expected size n. The committee members for Step 1 are called potential leaders.

[00597] It is noted that for simplicity, but without the desired limitation, the new modality is described in this document with the same committee size expected n for all the different stages of step 1 of each period. Those skilled in the art will realize that different committees can be of different sizes and can observe how to derive all types of other deployments as well.

[00598] Keys. All credentials for cryptographic self-selection are signed with long-term user keys for a digital signature scheme with unique signatures, so are the random Qr seeds specified in the blocks. All other messages are signed using ephemeral keys from corresponding steps. In general, SIGi (m) will be used to denote the signature of user i for message m, without specifying the keys.

[00599] It is noted that, for simplicity, but without the desired limitation, the new modality is described in this document with ephemeral keys. Those skilled in the art can observe how to derive other deployments with accredited message block chains, including using techniques introduced in existing versions of Algorand.

[00600] Definition 9.1. Credential: The user credential of 𝑟, 𝑝, 𝑠 i 𝜎𝑖 for a cycle r, period p and step s is SIGi (Qr-1, r, p, s).

[00601] A committee member for a stage will always propagate his corresponding credential together with his message for that stage, and the propagation of credentials will not be explicitly mentioned.

[00602] Definition 9.2. Leader: The leader ℓr.p for the period r.p is 𝑟, 𝑝, 1 user arg 𝑚𝑖𝑛𝑗∈𝑆𝑉 𝑟, 𝑝, 1 𝐻 (𝜎𝑖).

[00603] When a user i identifies his own leader for the 𝑟, 𝑝, 1 period rp, ℓi, rp, i configures ℓi, rp, as the user arg 𝑚𝑖𝑛𝑗∈𝑆𝑖 𝐻 (𝜎𝑗), where Si is the set of potential leaders from which i received valid credentials.

[00604] Definition 9.3. Valid block: It is called a proposed block during cycle r valid if and only if all its transactions are valid with respect to blocks B0, B1, · · ·, Br-1 and the specified Qr seed so it follows the rules of protocol.

[00605] Voting messages. Committee members generate three types of vote messages.

[00606] Definition 9.4. Cert-vote: The cert-vote of user i for a value v for the period r.p is the SIGi signature (v, “cert”, r.p).

[00607] It is said that a user i cert-votes for a value v for the period r.p when it propagates SIGi (v, "cert", r.p).

[00608] Definition 9.5. Soft-vote: The soft-vote of user i for a value v for the period r.p is the SIGi signature (v, “soft”, r.p).

[00609] It is said that a user i soft-vote for a value v for period p when it propagates SIGi (v, “soft”, r.p).

[00610] Definition 9.6. Next-vote: The next-vote of user i for a value v for the period r.p and step s is the SIGi signature (v, “next”, r.p.s).

[00611] It is said that a user i performs next-votes a value v when it propagates SIGi (v, “next”, r.p.s) .40

[00612] The v values that will be voted on are values in the range of the H hash function or a special symbol ⊥ of the same length, but outside the range of H.41

[00613] Timers. Each user i keeps a timer clock, which it resets to 0 every time it starts a new period. As long as i stays in the same period, the clock keeps counting. Individual user timers do not need to be synchronized or nearly synchronized. The only requirement is that they have the same speed.

9.4 The Royal Algorand2 Protocol

[00614] In the protocol below, blocks and credentials of potential leaders from different periods are selectively propagated as in Section 5. Cycle r, Period 1

[00615] The following are period 1 instructions for a generic user i. If user i is not on the committee for a specific stage, he still computes his vote for that stage, but does not propagate the same.

[00616] At the moment when user i starts his own 40 In each period, soft-votes are generated only in one step, and in the same way are cert-votes. Thus, they do not need to specify the corresponding stage. Next-votes can be generated in multiple steps and need to specify the step numbers. 41 The block structure in this manuscript is the same as in existing versions of Algorand, with the header of a block B, Header (B), which contains everything in B except the current set of payments. As in the original protocol, potential leaders can be asked to propagate the headers of their proposed blocks together with the hashes, to allow users to start an r + 1 cycle before observing the real Br block. In this case, see ⊥ are the same length as possible hash-header pairs. Headers will be ignored in the protocol description below.

cycle-r, it starts Period 1 and resets the clock to 0.

[00617] STEP 1: [Block Proposal] User i performs the following when clock = 0.

[00618] ● If i is a potential leader, then he prepares his proposed block 𝐵𝑖𝑟, 1, which contains his signature SIGi (Qr-1, r) to define his proposed seed 𝑄𝑖𝑟 .42 The same propagates 𝐻 (𝐵𝑖𝑟, 1), and immediately afterwards it also propagates the block by itself.

[00619] STEP 2: [The Filtering Step] User i performs the following when clock = 2λ.

[00620] ● He identifies his leader ℓi, r.p and soft-votes on his proposed leader block hash.43

[00621] STEP 3: [The Certification Stage] Be 𝑇 ≜ Λ + 𝜆. User i does the following when I watch ∈ (2λ, T).

[00622] ● If i observes a valid block B, together with tH soft-votes for H (B), then i cert-votes H (B).

[00623] STEP 4: [The First Finalization Stage] User i performs the following when clocking = T.

[00624] ● If i made a cert-vote on some value v in Step 3.44 then it performs next-votes v;

[00625] ● Otherwise, it performs next-votes ⊥.

[00626] STEP 5: [The Second Finalization Stage] User i performs the following when I watch ∈ [T, T + L), where L is equal to, say, 50 Λ.45 42 That is, 𝑄𝑖𝑟 = 𝐻 (𝑆𝐼𝐺𝑖 (𝑄 𝑟 − 1, 𝑟)). 43 i is not required to have observed the real block before soft-voting. 44 If i is not in SVr, 1.3, he can still make a cert-vote in some v “by himself”, without propagating his vote. 45 If the Opponent cannot dynamically corrupt users, then it is sufficient to make Step 5 last until time ∞ and no additional steps, as in the version with permission from

[00627] ● If i observe a valid block B, together with tH soft-votes for H (B), then i performs next-votes H (B).

[00628] STEPS s ≥ 6: [Consecutive Finalization Steps]

[00629] ● If s is even, then i follows the same voting instruction as in Step 4 when clocked = T + (s - 4) L / 2.

[00630] ● Otherwise (that is, s is odd), i follows the same voting instruction as in Step 5 when I watched ∈ [T + (s - 5) L / 2, T + (s - 3) L /two). Cycle r, Period p ≥ 2

[00631] The following are p-period instructions for a generic user i. Again, if user i is not on the committee for a specific stage, he still computes his vote for the stage, but does not propagate the same.

[00632] User i starts period p at the moment when he receives tH next-votes for some value v (which can be equal to ⊥) for the same step s of period p - 1, and only if he does not period p '> p. User i sets his starting value for 𝑝 the period p, 𝑠𝑡𝑖, for v. The moment i starts the period p, it ends all previous periods and resets clocki to 0.

[00633] STEP 1: [Block Proposal] If user i is a potential leader, then he performs the following when clock = 0.

[00634] ● If i observed tH next-votes for ⊥ for the same protocol. Additional steps are used to ensure that the protocol recovers after a partition is resolved, even if the Opponent has pocketed all messages from Step 4 and Step 5 and corrupted all committee members in Step 4 and Step 5, so that they cannot resend their messages after the partition. A smaller L helps to speed up partition resolution in the worst case, while a larger L reduces the amount of messages that need to be re-propagated once the partition is resolved.

𝑟, 𝑝 step s of the period p - 1.46 then, i proposes a new block 𝐵𝑖, which defines 𝑟, 𝑝 its proposed seed 𝑄𝑖𝑟 as H (Qr-1, r) .47 The same propagates 𝐻 (𝐵𝑖), and soon afterwards it also propagates the block by itself;

[00635] ● Otherwise (that is, i received only tH next-votes 𝑝 for some v ≠ ⊥ for the same period s of the period p - 1, and 𝑠𝑡𝑖 = 𝑣), i 𝑝 proposes ando propagating the same ; 48

[00636] STEP 2: [The Filtering Step] User i performs the following when clock = 2λ.

[00637] ● If i sent tH next-votes to ⊥ for the same step s of period p - 1.49 then i identifies its leader ℓi, p for period p and soft-votes to the value v proposed by ℓi ,P;

[00638] ● Otherwise (that is, i received only tH next-votes 𝑝 for v ≠ ⊥ for the same step s of the period p - 1, and 𝑠𝑡𝑖 = 𝑣), i performs soft- 𝑝 votes 𝑠𝑡𝑖.

[00639] STEP 3: [The Certification Stage] User i performs the following when I watch ∈ (2λ, T), T = Λ + λ.

[00640] ● If i observes a valid block B, together with tH soft-votes for H (B), then i cert-votes H (B).

[00641] STEP 4: [The First Finalization Stage] User i performs the following when clocking = T.

46 In extreme cases, a user i can simultaneously observe t next-votes for ⊥ and t

H H next-votes for some v ≠ ⊥ for period p - 1. It is free to set its starting value to ⊥ or v in this case, but the Block Proposal step always prioritizes ⊥. 47 In other words, a recently proposed block for a period p ≥ 2 is as if there was no leader for this one, and the corresponding seed Qr is defined in the same way as in the original Algorand protocol when Br is the empty block. 48 In this case, honest enough users have observed a valid block B so that v = H (B), and it is not required that i by itself have observed B. 49 It is noted that these votes can reach there during their time ( 0, 2λ], so the starting value of i is not necessarily ⊥.

[00642] ● If i cert-voted for some value v in Step 3, then it performs next-votes v;

[00643] ● Otherwise, if i has observed tH next-votes for ⊥ for the same step s of period p - 1, it performs next-vote for ⊥. 𝑝

[00644] ● Otherwise, it performs next-vote 𝑠𝑡𝑖.

[00645] STEP 5.1: [The Second Stage of Finalization] User i performs the following when clocking ∈ [T, T + L).

[00646] ● If i observe a valid block B, together with tH soft-votes for H (B), then i performs next-votes H (B).

[00647] STEP 5.2: [The Second Finalization Stage] User i performs the following when I watch ∈ [T, T + L) .50

[00648] ● If i did not cert-vote in Step 3 and the same observes tH next-votes for T for the same step s of period p - 1, then i performs next-vote ⊥.

[00649] STEPS S ≥ 6: [Consecutive Finalization Steps]

[00650] ● If s is even, then i follows the same voting instruction as in Step 4 when clocked = T + (s - 4) L / 2.

[00651] ● Otherwise (that is, s is odd), i follows the same voting instructions as in Steps 5.1 and 5.2 in parallel when I watched ∈ [T + (s - 5) L / 2, T + (s - 3) L / 2). Change Cycles

[00652] Instructions for each user i ∈ PK:

[00653] ● At any point while i is working on a cycle r, if i observe a line v ≠ ⊥ and a period r'.p with r '≥ r so that

[00654] - i received at least tH cert-votes for v for 50 Steps 5.1 and 5.2 are made into different stages so that they have different committees.

period r'.p, 51 and

[00655] - i received the block header corresponding to v, 52

[00656] then, i performs cert-vote v for the period r'.p, 53 configures his own CERTr ’as the set of cert-vote for v and cycle r '+ 1 begins.

[00657] Referring to Figure 6, a diagram 20 'shows a first plurality of computing workstations 22a to 22c connected to a first portion 24' of a data network, such as the Internet, and a second plurality of stations computing jobs 22a 'to 22c' connected to a second 24 ”portion of the data network. Workstations 22a to 22c communicate with each other via the first 24 'portion of the network and workstations 22a' to 22c 'communicate with each other via the second 24' portion of the network. However, unlike diagram 20 in Figure 1, workstations 22a to 22c do not communicate with workstations 22a 'to 22c' due to the network being partitioned in the first part 24 'and the second part 24 ”by a partition mechanism 26. Partition mechanism 26 can be any mechanism that suppresses communication between parts 24 ', 24 ”of the network. It is observed that the partition mechanism 26 can be purposely inserted into the network by an adversary or it can occur due to an unanticipated network interruption caused by natural or man-made phenomena, such as a power failure or a network switching error . In the system described in this document, each of the workstations 22a to 22c, 22a 'to 22c' performs the steps set out above, but the first plurality of workstations 22a to 22c does not communicate with the second 51 A certificate vote from participant j is counted even if participant i also received a message from j by cert-voting for a different amount for the same period. As shown in the analysis, this is done to ensure that all honest users know each other's CERT in time λ. 52 The header defines the seed Q r 'and, as mentioned earlier, strictly speaking, the header is part of v by itself. 53 For the theoretical analysis it is not necessary that i propagate his vote, due to the fact that he has already helped to propagate the tH cert-votes that he received. However, having i propagate your vote when i ∈ SVr ', p, 3 helps other users to observe a certificate faster in reality.

plurality of workstations 22a 'to 22c'. That is, each of entities 22a to 22c manages a transaction system locally in part 24 ’while each of entities 22a’ to 22c ’manages a transaction system locally in part 24’. Only one of the parties 24 ’, 24”, at most, has enough users (entities) to generate certified blocks. After partition mechanism 26 is removed and parts 24 ', 24 ”converge to a single network (such as network 24, discussed above in connection with Figure 1), all workstations 22a to 22c, 22a' to 22c 'communicate with each other and have the ability to continue operation at the same point (block) in the chain. After the partition mechanism 26 is removed, each of the entities 22a to 22c, 22a 'to 22c' manages a unique transaction system on the network in which all the entities 22a to 22c, 22a 'to 22c' communicate with each other.

[00658] Analysis: Even when the network is partitioned, the new modality remains safe - that is, at most one block is certified for each cycle r. At a high level, this is due to honest users cert-voting at most once in each period of cycle r, and the choice of committee size at the limit tH ensure that in each period rp, at most one hash value H ( B) from a valid block B can obtain a certificate. To observe this from a different direction, it is assumed that a period r.p generated tH cert-votes for a valid block B and tH cert-votes for another valid block B 'with respect to B0,. . . , Br-1, then, the conditions for how n and tH are chosen imply that at least one honest user has made cert-vote for the hash values of both B and B ', which contradicts the fact that an honest user has made cert -vote at most once in the rp period

[00659] If in any period rp, a valid block B obtained a certificate - that is, at least tH cert-votes for its hash value H (B), then, in all future periods p '> p (if the same are ever achieved), B will be the only block that can obtain a certificate in the period r.p '. In fact, an honest user does not next-vote for ⊥ in the r.p period if he / she has done a cert-vote for H (B) in r.p. Thus, by the same choices of n and tH, at no stage s ≥ 4 of the period r.p will there be tH next-votes for ⊥ or for any other value v ≠ H (B). Thus, an honest user moves to period R. (p + 1) only if he has received at least tH next-votes for H (B). Consequently, H (B) will be the only value that is proposed (again) in step 1 of period R. (p + 1), the only value that honest users will soft-vote in step 2 of period R. (p + 1 ), and consequently the only value that they will make cert-vote in step 3 and next-vote in step s ≥ 4 of period r (p + 1). By an inductive argument, the same is true for all consecutive periods.

[00660] It is observed that, when the network is partitioned, B that obtained a certificate in an period r.p does not mean that honest users will receive the certificate. In fact, during a network partition an adversary controls how messages are delivered to the system. It can, for example, allow all messages to be delivered properly except those with cert-vote, where it does not allow cert-votes from one group of users to be delivered to other groups. Nevertheless, B who obtained a certificate implies that users who are honest enough have made a cert-vote for the same and will not make a next-vote for any other, which prevents any other block from being certified in the r.p period and any future period.

[00661] The effectiveness of the new modality results from two parts. First, when the network is not partitioned, consensus on the r-th block is obtained quickly. In fact, if the leader of step 1 of period r.1 is honest, then all honest users immediately cert-vote for their proposed block B, B obtained a certificate after step 3 of the rp period, and all users honest people end cycle r after that.

[00662] Similarly, if cycle r has reached a period p ≥ 2 and the leader ℓ for period p is honest, then the block recently proposed or proposed again by ℓ is certified in step 3 and all honest users terminate cycle r after that. This is due to the fact that, if ℓ has observed tH next-votes for period ⊥ p - 1 and proposed a new block, then those next-votes will reach all honest users in time λ and they will soft-vote for de proposal. Otherwise, ℓ observed only tH next-votes for the H (B) hash of a valid block B of the period p - 1 and proposed again (B). All starting values of honest users of the period p are ⊥ or H (B), and no matter what the case, they soft-vote for H (B) - due to the fact that they follow the leader's proposal in the previous case, and due to the fact that they vote for their own starting values in the last case.

[00663] In addition, if a certificate for any valid B block is generated in an r.p period, then, all honest users end cycle r shortly thereafter. This is due to the fact that if at least tH cert-votes for B result from honest users, then all honest users will receive the same ones in time λ and end cycle r in which B is the r-th block. If any set of tH cert-votes for B contains at least one malicious user, malicious users can choose not to submit their cert-votes and honest users do not receive a certificate for B immediately. However, the choices of n and tH ensure that a certificate for B contains at least one honest user i, and i received tH soft-votes for B before he made a cert-vote. Since i propagated these soft votes and the network is not partitioned, all honest users will receive them in time λ and will next-vote for H (B) in step

5.1. Consequently, all honest users start the period r. (P + 1) with a starting value H (B) and will soft-vote for it in step 2 of the period r. (P + 1), regardless of the leader of the period A. (p + 1) to be honest or not. As a result, honest users will cert-vote for H (B) in step 3, B now has a certificate for honest users, and all honest users will receive the same and end cycle r in time λ.

[00664] The choices of Qr seeds and the cryptographic election used in the new modality ensures that each period p of cycle r has an honest leader with high probability, as in the original Algorand protocol, and the detailed analysis missing on the effectiveness of the new modality when there is no network partition it follows from that.

[00665] Second, after the network partition is resolved, the protocol will recover and reach consensus quickly. In fact, if some honest users received a certificate for a B block in cycle r during the partition and moved to cycle r + 1, then, once the partition is resolved, all honest users will receive such certificate for B and will move to cycle r + 1. Also, be the most distant period in cycle r + 1 that an honest user i reached during the partition. Then, all next-votes that allowed i to move to the period (r + 1) .p will reach other honest users after the partition is resolved, and they will also move to the period (r + 1) .p. The protocol will then continue from there as usual, following the same analysis as when there is no network partition. If no honest user is moved from cycle r to cycle r + 1 during the partition, then all honest users are in the same cycle, but perhaps at different times. In this case, let p be the furthest period in cycle r that an honest user i reached during the partition. Similarly, after the partition is resolved, all next-votes that allowed i to move to the r.p period will reach other honest users and they will also move to the r.p. Again, the protocol will continue from there as usual.

[00666] In summary, the new modality is safe and does not suffer a soft fork even when the network is partitioned. It generates blocks efficiently when the network is not partitioned, and recover quickly after a network partition is resolved. 10 Scope

[00667] It is noted that the mechanism described in this document is applicable to other block chain systems in which it is desirable to prevent more than one block from being certified during a network partition and to restore live transmission quickly after the partition is resolved. In this way, the system described in this document can be adapted for other block chain schemes, even schemes that are not directly related to exchange.

[00668] The system described in this document can be adapted to be applied to and combined with mechanisms established in any or all of the documents nº PCT / US2017 / 031037, deposited on May 4, 2017, 15 / 551,678 deposited on 17 August 2017, 16 / 096,107 deposited on October 24, 2018, PCT / US2018 / 053360 deposited on September 28, 2018, PCT / US2018 / 054311 deposited on October 4, 2018, 62 / 632,944 deposited on February 20, 2018, 62 / 643,331 deposited on March 15, 2018, 62 / 777,410 deposited on December 10, 2018 and 62 / 778,482 deposited on December 12, 2018, the contents of which are incorporated by reference to this document.

[00669] The software deployments of the system described in this document may include executable code that is stored in a computer-readable medium and executed by one or more processors. The computer-readable medium may be non-transitory and includes a computer hard drive, ROM, RAM, flash memory, portable computer storage media such as a CD-ROM, a DVD-ROM,

a flash drive, an SD card and / or another drive with, for example, a universal serial bus (USB) interface, and / or any other tangible or non-transitory computer readable medium or suitable computer memory on which the code executable can be stored and run by a processor. The system described in this document can be used in connection with any suitable operating system.

[00670] Other embodiments of the invention will be apparent to persons skilled in the art from a consideration of the specification or practice of the invention disclosed in this document. It is intended that the descriptive report and the examples are considered as exemplifiers only, and the scope and true spirit of the invention are indicated by the following claims.

Claims (20)

1. Method for an entity to manage a transaction system in which transactions are organized in a sequence of blocks that are certified by digital signatures from a sufficient number of verifiers, the method being characterized by the fact that it comprises: the entity propose a hash of a B 'block that includes new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1 if no r-th block Br has been certified; and the entity proposes a hash of the Br block if the rth block Br has been verified by a sufficient number of other entities. 2. Method, according to claim 1, characterized by the fact that a block is certified by the entity only in response to the confirmation of transactions for the block and the confirmation that the block was built and propagated by an entity in charge of building and propagate the block. 3. Method, according to claim 1, characterized by the fact that the entity proposes a hash value by digitally signing the hash value to provide a digitally signed version of the hash value and in which the entity propagates the digitally signed version of the value hash to a network that includes other entities. 4. Method, according to claim 3, characterized by the fact that, if no rth block Br has been certified, the entity also digitally signs and propagates block B '. 5. Method, according to claim 1, characterized by the fact that the entity determines a quantity Q from the previous blocks and uses a secret key in order to compute a line S solely associated with Q and computes, from S , a quantity T that is at least one of: S by itself, a function of S and hash value of S and in which the entity determines the possibility of proposing a hash value determining the possibility of T having a certain property. 6. Method, according to claim 5, characterized by the fact that S is a signature of Q under a secret key of the entity, T is a hash of S and T has a certain property if T is less than a certain limit. 7. Method, according to claim 1, characterized by the fact that the entity is part of a network of entities and in which a specific entity among the entities builds and propagates the Br block. 8. Method, according to claim 7, characterized by the fact that the rth block Br is determined as certified by the entity if the entity receives an indication that at least a predetermined number of entities individually certifies a hash value that corresponds to the r-th block Br. 9. Method, according to claim 8, characterized by the fact that, in response to the entity receiving the indication that a predetermined number of entities individually certified the rth block Br, the entity increments r to start adding additional blocks to the block sequence. 10. Method, according to claim 7, characterized by the fact that the specific entity among the entities is individually chosen by a predetermined number of entities as a leader. 11. Method, according to claim 10, characterized by the fact that the rth block Br is determined as certifiable by the entity if the entity receives an indication that at least a predetermined number of entities verifies the receipt of an indication that the specific entity among the entities provided a hash value corresponding to the rth block Br for each of the predetermined number of entities. 12. Method for an entity to manage a transaction system in which transactions are organized in a sequence of certified blocks, the method being characterized by the fact that it comprises: the entity receives a hash value from a Br block from another entity that generated the block based on new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1; the entity certifies the Br block in response to a sufficient number of other entities having indicated that it has received the hash value of the Br block from the other entity and the hash value is valid for the Br block; the entity generates a new B 'block based on new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1 in response to an insufficient number of other entities indicating the receipt of the hash value of block Br from the other entity, where B 'is different from Br; and the entity increments r to begin adding additional blocks to the block sequence in response to the entity receiving the indication that a predetermined number of entities individually certified the rth block Br or a predetermined number of entities individually certified the new block B ' . 13. Method, according to claim 12, characterized by the fact that the blocks are certified by digital signatures. 14. Method, according to claim 12, characterized by the fact that new blocks are proposed by different entities among the entities until they receive the indication that a predetermined number of entities individually certified a previously proposed block. 15. Method, according to claim 12, characterized by the fact that the entity provides an indication that a new block must be generated in response to the hash value not being valid for the Br block. 16. Method, according to claim 15, characterized by the fact that the entity generates a new B 'block based on new valid transactions with respect to a sequence of B0 certified blocks,. . . , Br-1 in response to a sufficient number of other entities to provide an indication that a new block should be generated. 17. Method, according to claim 12, characterized by the fact that the entity provides an indication that the hash value of the Br block must be propagated in response to a sufficient number of the other entities having indicated the receipt of the hash value of the block Br from the other entity and the hash value is valid for the Br block. 18. Method for an entity to verify a proposed hash value of a new Br block of transactions with respect to a given sequence of blocks, B0,. . . , Br-1, without access to the new Br block in a transaction system in which transactions are organized in blocks and the blocks are certified by a set of digital signatures, the method being characterized by the fact that it comprises: making that the entity determines a quantity Q from the previous blocks; cause the entity to compute a digital signature S of Q; make the entity compute, from S, a quantity T that is at least one of: S by itself, a function of S and hash value of S; make the entity determine the possibility of T having a certain property; and if T has a certain property, have the entity check the proposed hash value of the new Br block regardless of confirmation that the proposed hash value corresponds to the new Br block. 19. Method, according to claim 18, characterized by the fact that the entity propagates the proposed hash value of the new Br block before receiving the new Br block. 20. Computer software, provided in a non-transitory, computer-readable medium, characterized by the fact that it comprises: executable code that implements the method, according to any one of claims 1 to 19.