BR112020006407A2 - message-accredited blockchains - Google Patents

Abstract

In a transaction system in which transactions are organized into blocks, a new Br block of valid transactions is constructed, in relation to a sequence of previous blocks B0, B1, ..., Br ~ 1, by making an entity determine a quantity Q from the previous blocks, make an entity use a secret key in order to compute an S series exclusively associated with Q and the entity, make the entity compute from S an amount T which is S itself, a function of S and / or hash value of S, have the entity determine whether T has a given property, and, if T has the given property, have the entity digitally sign Br and make available S and a digitally signified version of Br, where the entity is selected based on a random value that varies according to a digital signature of Br.

Description

"BLOCKCHAINS ACCREDITED BY MESSAGE" TECHNICAL FIELD

[0001] This order relates to the field of electronic transactions and, more particularly, to the security field of the content of transaction block strings for electronic transactions.

BACKGROUND OF THE INVENTION

[0002] A blockchain consists of an expandable sequence of blocks: 1, 2, ..., where each block consists of several transactions, the hash of the previous block and other data, for example, the block number, time information , etc. The useful properties of a blockchain are that each user in the system eventually knows the content of each block, no one can change the content or order of the blocks and any valid transaction will eventually enter a block in the chain.

[0003] Users can digitally sign and, thus, each user has at least one public key and a corresponding secret key. In a blockchain, in general, public keys are known, but not necessarily the user who owns it. Consequently, a public key can be identified with its owner.

[0004] A blockchain works by propagating messages (for example, blocks, transactions, etc.). Typically, but not exclusively, messages are propagated by transmitting them in a peer-to-peer manner or via retransmissions.

[0005] Several blockchain systems show that a block is certified by digital signatures of a sufficient number of users on the system. On some systems, such certified users belong to a fixed set of users. In some other systems, they belong to a dynamically altered set. This is preferable due to the fact that an opponent would find it difficult to corrupt a dynamically altered set, particularly if the set is not only dynamic, but unpredictable as well.

[0006] A particularly effective way of selecting a set of users in a variable but unpredictable way is the cryptographic draw used by Algorand. Here, a user i belongs to a set of users with power to act in some steps s during the production of the number of blocks r based on the result of a computation that i performed through a secret key of his, using the entries be , and possibly other entries and other data (for example, the fact that the user has entered the system at least k blocks before block r, for some given integer k). For example, the computation of i may involve the digital signature of i, from such entries, hashing of and checking whether the hash is less than a given target t. (In fact, like any other series, a hashed value can be interpreted in some other standard way as a number.) If this is the case, then it is defined as the credential of i for step 5 on the block r. This credential proves to anyone that i, in fact, has the right to produce a message (preferably signed) as the message for step s in round r, that is, in the process that aimed to produce block r. In fact, i's digital signatures can be verified by anyone, and anyone can hash a given value and then verify that the result is, in fact, less than (or equal to) a given number. Consequently, i can propagate both and in Algorand, the credential is computed against a long-term key, while the signature is computed using a temporary key, which i uses only to authenticate a message: your message.

[0007] In fact, an honest i erases such a temporary secret key as soon as he uses it to signal

[0008] Using temporary keys that are erased after use prevents an opponent from corrupting i, after propagating forces i to signal a different message about step s of round r. The system, however, is based on an appropriate procedure to assure others that it is a temporary key of i devoted to authenticating your message for step s of round r. Such a guarantee may require that additional data be stored and / or transmitted. It would therefore be a good thing to lessen this need. Particularly, to certify the blocks of a blockchain.

[0009] It is therefore desirable to provide public records and electronic money systems that do not need to rely on a central authority and do not suffer from the inefficiency and insecurity of known decentralized approaches.

SUMMARY OF THE INVENTION

[0010] 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, in relation to a sequence of previous blocks B0, B1,. . . , Br-1, when making an entity determine a quantity Q of the previous blocks, make an entity use a secret key in order to compute an S series exclusively associated with Q and the entity, make the entity compute from S a quantity T which is S itself, a function of S and / or hash value of S, make the entity determine whether T has a given property, and, if T has the given property, make the entity digitally signal Br and make available S and a digitally signed version of Br, where the entity is selected based on a random value that varies according to a digital signature of Br. The secret key can be a secret signaling key corresponding to a public key of the entity and S is a digital signature of Q by the entity. T can be a number and satisfy the property if T is less than a given number p. S can be made available by making S deductible from Br. Each user can have a balance in the transaction system and p can vary for each user according to each user's balance. The random value can be a hash of the entity's digital signature. The entity can be selected if the random value is below a threshold that is chosen to make a minimum number of entities in the transaction system able to digitally signal Br.

[0011] Also according to the system described in this document, select a subset of users in a blockchain system to check a new Br block in relation to a sequence of previous blocks B0, B1,. . . , Br-x, includes making at least one of the users digitally sign the new Br block together with other information to produce a digital signature, having at least one of the users determine a hash value of the digital signature, making at least some of the users compare the hash value to a predetermined limit and have the subset of users make the digital signature available to verify the new Br block in response to the hash value being below a predetermined limit for each of the subset of the users. A private user among users can digitally signal the new Br block only if the private user among users verifies the information provided in the new Br block. The default value can be chosen to make the subset of users contain a minimum number of users . The blockchain system can be used in a transaction system where transactions are organized in blocks.

[0012] According to the system described in this document, a blockchain can perform the certification of at least one series of data m making a set S of user verify that m has at least one given property, making users digitally signal m, in response to the verification of m by users and making users make available digital signatures of m which are accredited signatures of m. The digital signature of m can be accredited if the digital signature satisfies a given additional property. The digital signature of m can satisfy a given additional property if a hash of the digital signature is less than a given target number. The data series m can be certified by at least a given number of accredited signatures of m.

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

[0014] The present invention does not require temporary keys to certify blocks. Typically, a new block is first prepared (for example, proposed and / or agreed upon by at least some users) and then certified. It is not certain how a B block is prepared: it can be prepared in one or multiple steps, even with the use of temporary keys. However, you want to certify it without relying on temporary keys. The certification of a block B ensures that certain valuable properties apply to the block. A typical primary property is to enable a user, even a user who has not participated or observed the preparation of a B block, to verify that B has been added to the blockchain or even that B is the r-th block in the blockchain. Another valuable property (often called termination) ensures that B will not disappear from the blockchain, due to a softfork, even in the presence of a partition of the communication network on which the blockchain protocol is executed.

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

[0016] In the system of the invention, multiple users i (even all users), who saw evidence that B was properly prepared, digitally signal B.1 These signatures may be related to long-term (as opposed to temporary) keys . Such signatures, however, count towards the certification of B if they satisfy a given property P. In the preferred modality, a digital signature of i of B,, SIGi (B), has the given property if (a) its hash (interpreted as a number) is less than a given target t, and preferably if i joined the blockchain at least k blocks before B. It is noted that anyone can verify the digital signature of i from B, compute its hash and verify that the result is not, in fact, greater than t. Additionally, anyone can verify when i joined the blockchain and thus that he joined the blockchain at least k blocks before. Such GIS i (B) can be considered a specialized credential from i to B as well as an accredited signature. Thus, in the system of the invention, the credentials are linked to a specific block, rather than to a given step in production 1 Digitally signaling a quantity Q includes digitally signaling a hashed verified version of Q, digitally signaling Q with other data. In this document, it is assumed that the digital signature is such that, for each message m, each user has a single signature m, regardless of how the public key can be chosen.

of the r-th block. Consequently, a user i can have a credential for a given block B, but not for another block B '. On the other hand, for example, in Algorand, a user with an appropriate credential for stage s in round r could signal whatever he wanted in that stage and round. A block certificate, therefore, consists of a given number of n signatures accredited to B. It is noted that a block B can have more than one certificate, if there are more than n accredited signatures of B.

[0017] The efficiency of the system of the invention derives from the fact that a suitable GIS (B) proves that both i certifies B and that i has the right to certify B. In a traditional system, i might have to first obtain a credential for the step s of round r in which you consent to certify B and then certify B by a separate signature. Thus, at least two signatures, instead of one, are required and may need to be stored and / or transmitted as part of a B certificate. Additionally, if B's signature i is temporary, some proof of that the temporary key used was, in fact, the key that i needed to use only for step s and round r.

[0018] The security of the system is derived from an adequate choice of target t and the number n of signatures sufficient to certify a block. For example, p is the maximum percentage of malicious users on the system. Typically, malicious users are in the minority - for example, p <1/3. So ten can be chosen so that, with sufficiently high probability, (a) for any possible block value B ', there are n or more accredited signatures from honest users to form a certificate for B' and (b) on any certificate of B ', at least one accredited subscription belongs to an honest user.

[0019] In addition, the set of honest users who are accredited to certify a B block is sufficiently random that an opponent cannot predict who they are and corrupt them before they certify the block. On the other hand, after an honest user i certifies a B block and propagates SIGi (B), the opponent has no advantage in corrupting i. In fact, SIGi (B) is already being virally propagated throughout the network, and the adversary cannot interrupt this propagation process. Secondly, if, after corrupting i, the opponent forces you to digitally signal a different B 'block, then SIGi (B') may not have a hash that is less than having a fair probability of finding n digital signatures of B ', the opponent could have to corrupt more than a fraction of the users.

[0020] As part of the system of the invention, a user i may not have a unique credential for B (or none), but also a credential with a weight (essentially a credential associated with several votes). In fact, the weight of credentials from i to B may depend on how much money i has in the system. In fact, instead of having a single t for all users, each user i can have his own target ti which is higher than the highest the higher the amount of money i. And the weight of the credential from i to B may depend on how small the SIGi hash (B) is in relation to you. For simplicity, but without limitation, the present system will continue to be described by treating a user i with a credential of weight m to B as m users, in which each has a credential (weight 1) for B.

[0021] So far, certification of a B block has been discussed through a sufficient number of B-accredited signatures. More generally, however, the system of the invention applies to blockchains where at least one given message m is certified by a sufficient number of digital signatures accredited by m. Such a message may not be a block, but a more general data series. Consequently, such hand certification can guarantee that different properties of hand apply in relation to those applicable or desirable for blocks. For example, but without any limitation, the property that m has been approved by a sufficient fraction of a set of users in the system or by at least one honest user in S. In fact, users in S who have an accredited subscription to m can form a sample selected at random enough from users in S. Thus, the fact that a sufficient number of accredited signatures of m has been produced indicates that, with sufficiently high probability, a given fraction of users in S or at least one honest user on S approves m.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The modalities of the system described in this document are explained in more detail in accordance with the figures in the drawings, which are briefly described as follows.

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

[0025] 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.

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

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

[0028] Figure 5 is a schematic diagram that illustrates the Merkle trees corresponding to the first blocks built on a block tree.

DETAILED DESCRIPTION OF VARIOUS MODALITIES

[0029] The system described in this document provides a mechanism 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 the calculations that are performed to propagate the transaction in a verifiable and reliable manner.

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

[0031] Figure 2 summarizes diagrammatically and conceptually the first stage of a round r in the Algorand system, in which each of some selected users proposes their own candidate for the tenth block. Specifically, the step begins with the users in the system, a, ..., z, individually going through the secret cryptographic draw 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 entitled to produce a block. In the example in Figure 2, only users b, d and h are selected to propose a block, and their credentials, respectively, are e. Each selected user i assembles his own proposed block,, temporarily signals the same (that is, digitally signals the same with a temporary key, as explained later) and propagates to the network together with his own credential. The leader of the round is the selected user whose credential has the lowest hash. The figure indicates the leader as a user d. Thus, your proposed block,, is the one to be given as input to the Binary agreement protocol.

[0032] Figure 3 summarizes diagrammatically and conceptually the Algorand process to reach agreement and certification of 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 stage currently coincides with the first stage of Algorand, BA * preferred Byzantine agreement protocol. Each step of this protocol is performed by a different “committee” of players, selected at random by secret cryptographic draw (not shown in this figure). Consequently, the users selected to perform each step can be totally different. The number of BA * Steps may vary. Figure 3 represents a BA * execution involving 7 steps: from step 2 of Algorand to step 8 of Algorand. In the example in Figure 3, the users selected to perform step 2 are a, e and q. Each user i ∈ {a, e, q} propagates his credential to the network, which proves that i has, in fact, the right to send a message in step 2 of round r of Algorand, and his appropriate message from that step, temporarily signaled . Steps 3 through 7 are not shown. In the last step 8, the figure shows that the selected users corresponding b, f and x who reached agreement on Br as the block officiate round r propagate their own temporary signatures of Br block (together, these signatures certify Br) and their own credentials, proving who have the right to act in step 8.

[0033] 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 series of length ≤ 3, stores a value vx. If x is ≤ 2 in length, then vx = H (vx0, vx1). For the Merkle tree in Figure 4.a, Figure 4.B illustrates the authentication path of the v010 value.

[0034] Figure 5 schematically illustrates the Merkle trees, corresponding to the first 8 blocks built in a block tree, built within a complete binary tree of depth

3. In Figure 5.i, the nodes marked by an integer belong to the Merkle Ti tree. The content of the nodes marked by i (respectively, by i) is temporary (respectively, permanent).

[0035] 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 handle all types of transactions as well.

[0036] The system described in this document has a very flexible design and can be implemented in different but related ways. Its flexibility is illustrated by detailing two possible modalities of its overall project. From them, those skilled in the art can understand how to derive all kinds of other deployments as well.

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

1. INTRODUCTION

[0038] Money is becoming increasingly virtual. It has been estimated that about 80% of US dollars today exist only as registry entries. Other financial instruments are following suit.

[0039] In an ideal world, in which one could count on a universally trusted central entity, immune to all possible cyber attacks, money and other financial transactions could be just electronic. Unfortunately, you don't live in such a world. Consequently, decentralized cryptocurrencies, such as Bitcoin, and “smart contract” systems, such as Ethereum, have been proposed. At the heart of these systems is a shared record that reliably records a sequence of transactions, as varied as payments and contracts, in an inviolable way. The technology of choice to guarantee such inviolability is blockchain. Blockchains are behind applications, such as cryptocurrencies, financial applications and the Internet of Things. Several techniques for managing blockchain-based records have been proposed: proof of work, proof of participation, practical Byzantine fault tolerance or some combination.

[0040] Currently, however, records can be inefficient for management. For example, Bitcoin's proof-of-work approach requires a vast amount of computing, is costly, and bad at scale. Additionally, it, in fact, concentrates power in the hands of a few.

[0041] It is intended, therefore, to present a new method for implementing a public registry that offers the convenience and efficiency of a centralized system executed by a reliable and inviolable authority, without the inefficiencies and weaknesses of current decentralized deployments. The present approach is called Algorand, due to the fact that algorithmic randomness is used to select, based on the record built so far, a set of verifiers that are responsible for building the next block of valid transactions. Naturally, it is guaranteed that such selections are probably immune to manipulation and unpredictable until the last minute, but also that they are ultimately universally clear.

[0042] Algorand's approach is quite democratic, in the sense that neither in principle nor in fact creates different classes of users (such as “miners” and “ordinary users” in Bitcoin). In Algorand, "all power resides in all users".

[0043] A notable feature of Algorand is that its transaction history can branch out only with very low probability (for example, one in a trillion, that is, even 10-18). Algorand can also address some legal and political concerns.

[0044] Algorand's approach applies to blockchains and, more generally, to any method for generating an inviolable sequence of blocks. A new method is presented - alternative to and more efficient than blockchains - that can be of independent interest.

1.1 BITCOIN ASSUMPTION AND PROBLEMS OF THE TECHNIQUE

[0045] Bitcoin is a very ingenious system and has inspired a great deal of subsequent research. However, it is also problematic. Its underlying assumption and technical problems will be summarized - which are actually shared by essentially all cryptocurrencies that, like Bitcoin, are based on proof of work.

[0046] For this summary, it is enough 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 some amount of money from one public key to another. Essentially, Bitcoin organizes all payments processed in a block chain, Β1, Β2,. . ., each consisting of multiple payments, so that all payments from B1, considered in any 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.

[0047] 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, diffuses in all subsequent blocks, making it easier to observe any change in the payment history . (As can be seen, this is achieved by including a cryptographic hash of the previous block in each block.) Such a block structure is called a blockchain.

[0048] Assumption: Honest Majority of Computational Power Bitcoin assumes that no malicious entity (nor a coalition of coordinated malicious entities) controls most of the computational power devoted to block generation. Such an entity, in fact, could have the ability to modify the blockchain and thus rewrite the payment history as desired. In particular, you could make a payment to get the benefits paid and then “erase” any trace of it.

[0049] 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 public keys in the system, the 500 most powerful supercomputers can only display a mere 12.8% percent of the total computational power required by Bitcoin players. This amount of computing could increase greatly, significantly more users could join the system.

[0050] Problem of Technique 2: Power Concentration Today, due to the exorbitant amount of computing required, it is expected that a user, trying to generate a new block using a common desktop computer (especially a cell phone), lose money. In fact, to compute a new block with an ordinary computer, the expected cost of electricity needed to power the computation exceeds the expected reward. Only by using specially constructed groups of computers (which do nothing but "undermine new blocks") would it be expected to produce a profit by generating new blocks. As a result, there are actually two separate classes of users today: ordinary users, who make only payments, and specialized mining groups, who only look for new blocks.

[0051] It should not be surprising that, recently, the total computing power for block generation is found within only five groups. Under such conditions, the assumption that most computing power is honest becomes less credible.

[0052] Problem of Technique 3: Ambiguity In Bitcoin, blockchain is not necessarily exclusive. In fact, its last portion often forks: the blockchain can be - for example - according to one user and according to another user. Only after several blocks have been added to the chain can you be reasonably sure that the first blocks will be the same for all users. Thus, the payments contained in the last block of the chain cannot be counted on immediately. It is more prudent to wait and observe whether the block becomes deep enough in the blockchain and thus stable enough.

[0053] Separately, concerns about law enforcement and monetary policy have also arisen over Bitcoin.2 2 The (pseudo) anonymity offered by Bitcoin payments can be misused for money laundering and / or the financing of criminals or terrorist organizations . Traditional banknotes or gold bars, which at first

1.2 ALGORAND, IN A SUMMARY

[0054] The Algorand environment works in a very difficult environment. In short,

[0055] (a) Environments Without Permission and With Permission. Algorand works efficiently and securely in an environment without permission, in which many users are allowed arbitrarily to enter the system at any time, without any veto or permission of any kind. Obviously, Algorand works even better in an environment with permission.

[0056] (b) Very Adverse Environments. Algorand resists a very strong opponent, who can

[0057] (1) instantly corrupt any user you want, any time 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.)

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

[0059] (3) schedule the delivery of all messages, provided that each message sent by an honest user reaches all (or sufficiently many of) the honest users within a time λm, which depends only on the size of m.

[0060] Main Properties Despite the presence of offering perfect anonymity, they can impose some challenge, however the physicality of these currencies substantially delays money transfers, in order to allow some degree of monitoring by law enforcement agencies. The ability to "print money" is one of the most basic powers of a nation. In principle, therefore, the massive adoption of an independently floating currency may restrict that power. Currently, however, Bitcoin is far from being a threat to monetary policies. due to their scalability problems, they may never be.

strong opponent in Algorand

[0061] • The amount of computation required is minimal. Essentially, no matter how many users are present on the system, each of the fifteen hundred users needs to perform at most a few seconds of computation.

[0062] • A new block is generated quickly and, in fact, will never leave the blockchain. That is, Algorand's blockchain can branch out only with negligible probability (i.e. less than one in a trillion or 10-18). Thus, users can relay payments contained in a new block as soon as the block appears.

[0063] • All power is with the users themselves. Algorand is a really distributed system.

[0064] In particular, there are no exogenous entities (such as “miners” in Bitcoin), which can control which transactions are recognized. ALGORAND TECHNIQUES.

[0065] 1. A NEW AND QUICK BYZANTINE AGREEMENT PROTOCOL. Algorand generates a new block using a binary, message passing, cryptographic bypass protocol, BA *. The BA * protocol not only satisfies some additional properties (which will be discussed shortly), but it is also very fast. In general, its binary input version consists of a 3-step circuit, in which one player i sends a single message mi to all other players. Executed in a complete and synchronized network, with more than 2/3 of the players being honest, with probability> 1/3, after each protocol circuit ends in agreement. (It is emphasized that the BA * protocol satisfies the original definition of the Byzantine agreement, without any weakening.)

[0066] Algorand leverages this binary BA protocol to reach agreement, in the present different communication model, on each new block. The agreement on the block is then certified through a prescribed digital signature number from the appropriate verifiers and propagated through the network.

[0067] 2. SECRET CRYPTOGRAPHIC DRAWING. Although very fast, the BA * protocol could benefit from additional speed when run by millions of users. Consequently, Algorand chooses BA players * to be a much smaller subset of all users. To avoid a different type of power concentration problem, each new Br block will be built and agreed, through a new execution of BA *, by a separate set of selected verifiers, SVr. At first, selecting such a set can be as difficult as selecting Br directly. This problem is solved by an innovative approach called secret cryptographic draw. The draw in the practice of selecting officers at random from a large set of eligible individuals. (The draw has been practiced for centuries: for example, by the republics of Athena, Florence and Venice. In modern judicial systems, random selection is often used to choose juris. Random sampling has also been advocated for elections.) In a decentralized system Obviously, choosing random currencies to randomly select the members of each set of SVr verifiers is problematic. Thus, cryptography is used in order to select each set of verifiers, among the population of all users, in a way that is guaranteed in an automatic way (that is, without requiring message exchange) and random. In a similar way, a user is selected, the leader, responsible for proposing the new Br block, and the SVr set of verifiers, responsible for reaching the agreement in the block proposed by the leader. The system of the invention leverages some information, Qr-1, which are deductible from the contents of the previous block and are not manipulable even in the presence of a very strong opponent.

[0068] 3. THE QUANTITY (SEED) Qr. The last Br-1 block in the blockchain is used in order to automatically determine the next set of verifiers and leader responsible for building the new Br block. The challenge of this approach is that, just choosing a payment slightly different from the previous round, the opponent strongman gains enormous control over the next leader. Even if you controlled only 1 / 1,000 of the players / money in the system, you could guarantee that all the leaders were malicious. (See Intuition Section 4.1.) This challenge is central to all evidence-based approaches to participation and, as far as is known, has not, to date, been satisfactorily solved.

[0069] To meet this challenge, a carefully defined quantity, Qr, was purposely built and continuously updated, which is probably not only unpredictable, but also not influenced by the strong opponent. Qr can be called the r-th seed, since it is from Qr that Algorand selects, through a secret cryptographic draw, all users who have a special role in the generation of the r-th block. The Qr seed will be deductible from the Br-1 block.

[0070] 4. SECRET CREDENTIALS. Using the last current block, Br-1, at random and unambiguously, in order to choose the set of verifiers and the leader responsible for building the new block, Br, is not enough. Since Br-1 needs to be known before generating Br, the last non-liable amount of deductible Br-1 Qr-1 must also be known. Consequently, so are the verifiers and the leader responsible for computing the Br block. Thus, the strong opponent can immediately corrupt all of them, before entering into any discussion about Br, in order to obtain complete control over the block they certify.

[0071] To avoid this problem, leaders (and in fact verifiers too) secretly learn their role, but can compute an appropriate credential, which can provide everyone who, in fact, has that role. When a user privately realizes that he is the leader for the next block, he secretly assembles his own proposed new block and then disseminates it (so that he can be certified) along with his own credential. Thus, although the opponent immediately realizes who is the leader of the next block and although it may corrupt it immediately, it will also be too late for the opponent to influence the choice of a new block. In fact, it cannot “retrieve” the leader's message as much as a strong government can put a message virally spread by WikiLeaks back into the bottle.

[0072] As can be seen, the exclusivity of the leader cannot be guaranteed, nor that anyone with certainty knows who the leader is, including the leader himself! But in Algorand, unambiguous progress will be guaranteed.

[0073] 5. SUBSTITUIBILITY OF THE PLAYER. After proposing a new block, the leader may also “die” (or be corrupted by the opponent), due to the fact that his work has been completed. But for SVr checkers, it is less simple. In fact, being responsible for certifying the new Br block with sufficient signatures, they must first execute the Byzantine agreement in the block proposed by the leader. The problem is that, no matter how efficient it is, BA * requires multiple steps and the honesty of> 2/3 of its players. This is a problem due to the fact that, for efficiency reasons, the BA * player set consists of the small SVr set randomly selected from the set of all users. Thus, the strong opponent, while unable to corrupt 1/3 of all users, can certainly corrupt all members of SVr.

[0074] Fortunately, it will be proved that the BA * protocol, executed by propagating messages in a peer-to-peer manner, is replaceable by player. This innovative requirement means that the protocol correctly and efficiently reaches consensus even if each of its steps is performed by a completely new set of players, selected at random and independently. Thus, with millions of users, each small set of players associated with a BA * stage is more likely to have an empty intersection with the next set.

[0075] Additionally, the stages of players of different stages of BA * will probably have a totally different cardinality. In addition, the members of each set do not know what the next set of players will be and do not secretly pass any internal state.

[0076] Replaceable player ownership is really essential to defeat the dynamic and very strong opponent faced. Replaceable player protocols are believed to be essential in many contexts and applications. In particular, they will be essential to safely execute small sub-protocols embedded in a larger universe with a dynamic opponent, who, being able to corrupt even a small fraction of the total players, has no difficulty in corrupting all players in the smaller sub-protocol.

[0077] An Additional Property / Technique: Lazy Honesty An honest user follows their prescribed instructions, which include 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. Obviously, some "absences" between honest players, such as those due to the sudden loss of connectivity and the need to restart, are automatically tolerated (due to the fact that some players can always be considered to be temporarily malicious).

It is noteworthy, however, that Algorand can simply be adapted to work on a new model, in which honest users are offline most of the time. Another new model can be informally introduced as follows.

[0078] Lazy Honesty. Generally speaking, a user i is more honest lazy if (1) he follows all of his prescribed instructions when asked to participate in the protocol, and (2) he is asked to participate in the protocol only rarely, with adequate advance notice.

[0079] With such a relaxed notion of honesty, you can be even more confident that honest people will be available when needed, and Algorand guarantees that, when that is the case,

[0080] The system operates safely even if, at a given point in time, most of the participating players are malicious. 2 PRELIMINARY

2.1 CRYPTOGRAPHIC PRIMITIVES

[0081] Verification by Ideal Hash. It is based on an efficiently computable cryptographic hash function, H, which maps arbitrarily long series to fixed-length binary series. Following a long tradition, H is modeled as a random oracle, essentially a function that maps each possible series s to a randomly selected (and then fixed) binary series, H (s), of the chosen length.

[0082] In the present described modalities, H has outputs of 256 bits in length. In fact, such a length is short enough to make the system efficient and long enough to make the system safe. For example, H is intended to be resistant to collision. That is, it can be difficult to find two different series x and y, so that H (x) = H (y). When H is a random oracle with outputs 256 bits long,

finding any such pair of series is, in fact, difficult. (Trying at random and based on the birthday paradox, could require 2256/2 = 2128 tests.)

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

[0084] Given a security parameter k, a sufficiently high integer, a user i uses G to produce a pair of k bit keys (ie series): a “public” pki key and a “secret” signaling key ”Correlated ski. Essentially, a public key does not “betray” its corresponding secret key. That is, even given knowledge of pki, no one but i can compute ski in less than an astronomical time.

[0085] User i uses ski to digitally signal messages. For each possible message (binary series) m, i first checks by hash m and then executes the S algorithm on outputs H (m) and ski in order to produce the series of k bits.

3

[0086] The binary series is called digital signature of i of m (in relation to pki) and can be more simply denoted by sigi (m), when the public key pki is clear from the context.

[0087] Anyone who knows pki can use it to check the digital signatures produced by i. Specifically, in outputs (a) the public key pki of a player i, (b) a message m (c) a series s, that is, the supposed digital signature of i of message m, the algorithm of 3 Since H is resilient to the collision, it is practically impossible that by signing m, "accidentally signing" a different message verification V emits YES or NO.

[0088] The necessary properties from a digital signature scheme are:

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

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

[0091] (Following strong security requirements, this is true even if someone can get a signature on any other message.)

[0092] Consequently, to prevent anyone else from signaling messages in their favor, a player i needs to keep his signaling key secret (hence the term "secret key") and allow anyone to check the messages he signs, i have an interest in making your pki key public (hence the term “public key”).

[0093] Signatures with Message Recoverability In general, a m message 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 subscriber and the message are easily computable from a signature, it is defined

[0094] Exclusive Digital Signage. Digital signature schemes (G, S, V) that satisfy the additional property below are also considered.

[0095] 3. Exclusivity. It is difficult to find pk ', m, s and s' series, so that

[0096] (Note that the exclusive property is also maintained for the pk 'series that are not legitimately generated public keys. In particular, however, the exclusive property implies that if someone used the specific key generator G for compute a public key pk together with a secret key correlated sk and, thus, knew sk, it could be essentially impossible for him to find two different digital signatures of the same message in relation to pk.)

COMMENTS

[0097] • FROM EXCLUSIVE SIGNATURES TO VERIFIABLE RANDOM FUNCTIONS. In relation to a digital signature scheme with the exclusive property, the mapping m → H (sigi (m)) associates to each possible series m a series of 256 bits, randomly selected, exclusive and the accuracy of this mapping can be proven given the sigi (m) signature.

[0098] That is, the ideal hash check and the digital signature scheme that satisfy the exclusivity property provide an elementary implementation of a verifiable random function (VRF).

[0099] 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 exclusivity property, the verifiable random functions produce outputs that are guaranteed to be sufficiently random. In other words, VRFi (m) is essentially random and unpredictable until it is produced. In contrast, 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 series of k bits that is (lexicographically) small (that is, whose first few bits could always be 0s). Note, however, that since H is an ideal hash function, H (SIGi (m)) will always be a random 256-bit series. In the preferred modalities, extensive use of hash verification digital signatures is made, which satisfy the exclusivity property precisely so that each message m and each user i is assigned a unique random number. If Algorand is deployed with VRFs, H (SIGi (m)) can be replaced by VRFi (m). In particular, a user i does not need to compute SIGi (m) first, then H (SIGi (m)) (in order, for example, to compare H (SIGi (m)) with a number p). VRFi (m) can be directly computed. In short, it must be understood that H (SIGi (m)) can be interpreted as VRFi (m) or as a sufficiently random number, easily computed by player i, but unpredictable by others, unambiguously associated with i and m.

[00100] • THREE DIFFERENT NEEDS FOR DIGITAL SIGNATURES. In Algorand, a user i relies on digital signatures to

[00101] (1) Authenticate i own payments. In this application, the keys can be “long-term” (that is, used to signal many messages over a period of time) and originate from a common signature scheme.

[00102] (2) Generate credentials that prove that i has the right to act in some stages of a round r. Here, the keys may be long-term, but they must originate from a scheme that satisfies the exclusive property.

[00103] (3) Authenticate the message i sent at each stage in which it operates. Here, the keys need to be temporary (that is, destroyed after their first use), but they can originate from a common signature scheme.

[00104] • A SMALL COST SIMPLIFICATION. For the sake of simplicity, each user i is expected to have a unique long-term key. Consequently, such a key must originate from a signature scheme with the exclusive property. 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 REGISTRATION

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

[00106] 1. The Initial State. The money is associated with individual public keys (privately generated and owned by users). pk1,. . . , pkj are the initial public keys and a1,. . . , aj, their respective initial amounts of currency units, then the initial state is

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

[00108] 2. Payments. pk is a public key that currently has α ≥ 0 currency units, pk 'another public key and a' non-negative number not greater than a. So, a (valid) payment is a digital signature, related to pk, which specifies the transfer of a 'currency units from pk to pk', along with some additional information. In the symbols,

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

[00110] The payer is named pk (or its owner), each pk '(or its owner) a beneficiary and a' as the payment amount

[00111] Free Admission Through Payments. It is observed that users can enter the system whenever they want, generating their own public / 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.

[00112] 3. The Magic Record. In the Idealized System, all payments are valid and appear in an inviolable list L of payment sets “posted in the sky” for all to see:

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

[00114] Discussion.

[00115] ● More General Payments and Outgoing Transaction Not Spent. More generally, if a public key pk has a quantity a, then a valid payment of pk can transfer the quantities respectively to the keys as long as

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

[00117] 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 adhere to the present simpler forms of payments and keys that have a unique amount associated with them.

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

[00119] In the ideal system, an active user continuously stores and updates the latest state information or would otherwise have to reconstruct it, either from scratch or from the last time he computed it. (In addition, below we show how to increase Algorand in order to enable its users to reconstruct the current state in an efficient manner.)

[00120] ● Security and “Privacy”. Digital signatures ensure that no one can forge a payment from another user. In a payment, public keys and quantity are not hidden, but sensitive information is. In fact, only H (I) appears in e, since H is an ideal hash function, H (I) is a random 256-bit value, so there is no way to imagine what I was, other than simply imagining . In addition, to prove what I was (for example, to prove the reason for payment), the payer can only reveal I. The accuracy of the revealed I can be verified by computing H (I) and comparing the resulting value with the last item from. In fact, since H is resilient to collision, it is difficult to find a second I 'value so that H (I) = H (I').

2.3 BASIC NOTIONS AND NOTES

[00121] Keys, Users and Owners Unless otherwise specified, each public key ("key" for abbreviation) is long-term and pertains to a digital signature scheme with exclusive property. A public key i enters the system when another public key j already in the system makes a payment to i.

[00122] For color, keys are personified. It refers to a key i in the masculine, says that i is honest, that i sends and receives messages, etc. User is a synonym for key. When you want to distinguish a key from the person to whom it belongs, the terms “digital key” and “owner” are used, respectively.

[00123] Systems without permission and with permission. A system is without permission, if a digital key is free for integration at any time and an owner can have multiple digital keys; and with permission otherwise.

[00124] Exclusive Representation Each object in Algorand has an exclusive representation. In particular, each set is ordered in a pre-specified manner: for example, first lexicographically at x, then at y, etc.

[00125] Same Speed Watches There is no global clock: instead, each user has their own clock. The user's clocks need not be synchronized in any way. However, it is assumed that everyone has the same speed.

[00126] For example, when it is 12pm according to the clock of one user i, it can be 2:30 pm according to the clock of another user j, but when it is 12:01 according to the clock of i, there will be 2 : 31 according to the clock of j. In other words, “one minute is the same (sufficient, essentially the same) for each user”.

[00127] Algorand rounds is organized in logical units, r - 0, 1,. . ., round calls.

[00128] Superscripts are consistently used to indicate rounds. To indicate that a non-numeric quantity Q (e.g., a series, a public key, a set, a digital signature,

etc.) calls a round r, simply write Qr. Only when Q is a genuine number (as opposed to a binary series interpretable as a number), is Q (r) written, so that the symbol r cannot be interpreted as the exponent of Q.

[00129] In a (at the beginning of a) round r> 0, the set of all public keys is, and the state of the system is

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

[00131] For round 0, PK0 is the set of initial public keys, and S0 is the initial state. It is assumed that both PK0 and S0 are common knowledge in the system. For the sake of simplicity, at the beginning of round r, they are also PK1,. . . , PKr and S1, ... , Sir

[00132] In a round r, the state of the system changes from Sr to Sr + 1: symbolically, Round r: Sr → Sr + 1.

[00133] Payments In Algorand, users continuously make payments (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. To know,

[00134] The payment is individually valid in a round r (it is a round r payment, for short), if (1), its quantity a is less than or equal to e (2) it does not appear in any official payment set PAYr 'to r' <r. (As explained below,

the second condition means that it has not yet been effective.

[00135] A set of payments for round r of i is collectively valid if the sum of their quantities is at most.

[00136] Payment Sets A set of round payments r P is a set of payments round r so that, for each user i, payments from i in P (possibly none) are collectively valid. The set of all round pay sets r is. A set of round payments r P is maximum if no superset of P is a set of round payments r.

[00137] It is actually suggested that a payment also specifies a round and cannot be valid in any external round [ρ, ρ + k], for some fixed non-negative integer k.4

[00138] Official Payment Sets For each round r, Algorand publicly selects (in a manner described later) a single (possibly empty) set of payments, PAYr, the official set of payments for the round. (Essentially, PAYr represents round payouts r that “actually” took place.)

[00139] 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 belonging to the official PAYr payment set for a given round r; and (2) PAYr determines the status of the next round, Sr + 1, from that of the current round, Mr. Symbolically, PAYr: Sr → Sr + 1.

This simplifies the verification of whether ρ has become "effective" (that is, it simplifies the determination of whether any set of PAY payments r contains. When k = 0, if and then i needs to resubmit ρ.

[00140] Specifically,

[00141] 1. the set of public keys of round 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

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

[00143] In short, as in the Ideal System, each Sr + 1 state is deductible from the history of previous payments:

2.4 BLOCKS AND PROVEN BLOCKS

[00144] In Algorand0, the Br block corresponding to a round r specifies: r itself; the payout set for round r, PAYr; an amount to be explained, and the hash of the previous block, H (Br-1). Thus, starting from some fixed block B0, we have a traditional blockchain:

[00145] In Algorand, the authenticity of a block is really proven by separate information, a CERTr “block certificate”, which makes Br a proven block,. The Magic Record, therefore, is implemented by the sequence of the proven blocks,

[00146] Discussion As can be seen, CERTr consists of a set of digital signatures for H (Br), those of most SVr members, together with proof that each of these members does in fact belong to SVr. You can, of course, include CERT certificates in the blocks themselves, but it is conceptually cleaner to keep them separate.)

[00147] In Bitcoin, each block needs to satisfy a special property, that is, it needs to “contain a cryptographic puzzle solution”, which makes the block generation computationally intensive and forks both inevitable and not rare. In contrast, Algorand's blockchain has two main advantages: it is generated with minimal computation and will not fork with overwhelmingly high probability. Each Bi block is surely final as soon as it enters the blockchain.

2.5 ACCEPTABLE FAILURE PROBABILITY

[00148] To analyze Algorand security, the acceptable probability, F, is specified that something goes wrong (for example, that a set of SV verifiers does not have an honest majority). As in the case of the output length of the cryptographic hash function H, also F is a parameter. But, as in this case, it is useful to define F as a concrete value, in order to obtain a more intuitive understanding of the fact that it is, in fact, possible, in Algorand, to obtain efficiency both sufficient security and sufficient efficiency. To emphasize that F is the parameter that can be defined as desired, in the first and second modes, F = 10-12 and = 10-18, respectively.

[00149] Discussion It is observed that 10-12 is actually less than one in a trillion, and it is believed that such choice of F is appropriate in the present application. It is emphasized that 10-12 is not the probability with which the opponent can forge payments from an honest user. All payments are digitally flagged, so if the proper digital signatures are used, the probability of forging a payment is well below 10-12 and is, in fact, essentially 0. The bad event that can be tolerated with probability F is that Algorand's blockchain forks.

It is observed that, with the present environment of F and one-minute rounds, a fork in the Algorand blockchain is expected to occur as rarely as (approximately) once in 1.9 million years. In contrast, in Bitcoin, a fork occurs quite frequently.

[00150] A more demanding person can define F in a lower value. For this purpose, in the second modality, it is considered to define F in 10-18. It can be observed that, assuming that a block is generated every second, 1018 is the estimated number of seconds that have elapsed by the Universe so far: from the Big Bang to the present moment. Thus, with F = 10 -18, if a block is generated in one second, it would be expected by the age of the Universe to see a bifurcation.

2.6 THE ADVERSE MODEL

[00151] Algorand is designed to be safe on a very adverse model. Explains yourself.

[00152] Honest and Malicious Users A user is honest if he follows 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) to deviate arbitrarily from his prescribed instructions.

[00153] The Adversary The Adversary is an efficient algorithm (technically polynomial time), personified by color, which can immediately make malicious any user you want, at any time you want (subject only to a limit higher than the number of users that can corrupt ).

[00154] The opponent fully controls and perfectly coordinates all malicious users. He acts on your behalf, including receiving and sending all your messages and may allow you to deviate from your prescribed instructions in arbitrary ways. Or you can simply isolate a corrupted user by sending and receiving messages. It is clarified that no one else automatically knows that a user i is malicious, although the malice of i can be seen in the actions that the opponent causes him to take.

[00155] This strong opponent, however,

[00156] • It does not have unlimited computing power and cannot successfully forge the digital signature of an honest user, except with negligible probability; and

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

[00158] In addition, your ability to attack honest users is limited by one of the following assumptions.

[00159] Honest Majority of Money A continuum of Honest Majority (HMM) assumptions is considered: namely, for each non-negative integer k and h real> 1/2,

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

[00161] 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 among many individuals is difficult to achieve. Perhaps coordination only takes place within separate groups of malicious players. But since you can't be sure about the level of coordination that malicious users can have, prevention is better.

[00162] Assuming that the opponent can corrupt secretly, dynamically and immediately users is also pessimistic. After all, realistically, gaining complete control of a user's operations could take some time.

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

10,000.

[00164] It is noted that the previous HMM assumptions and the Honest Majority of Computing Power assumptions are related in the sense that, since the computing power can be purchased with money, if malicious users have most of the money , then, they can obtain most of the computing power.

2.7 THE COMMUNICATION MODEL

[00165] The propagation of messages - that is, “transmission by pair” 5 - is expected to be the only means of communication and it is assumed that each message propagated reaches almost all honest users in a timely manner. It is essentially assumed that each message m propagated by an honest user reaches, within a given amount of time depending on the length of m, all honest users. (It is really enough that m reaches a high enough percentage of honest users.) 3 THE BA * PROTOCOL IN A TRADITIONAL ENVIRONMENT

[00166] 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 a strong opponent, Algorand needs to rely on a BA 5 protocol. Essentially, as in Bitcoin, when a user propagates a message m, each active user i who receives m for the first time, selects randomly and independently a suitably small number of active users, 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.

that satisfies the new player substitutability constraint. Additionally, for Algorand to be efficient, such a BA protocol needs to be very efficient.

[00167] 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 protocol BA, BA *, is introduced for SC networks and completely ignoring the player substitutability problem. The BA * protocol is a separate value contribution. In fact, this is the most efficient cryptographic BA protocol for SC networks known to date.

[00168] To use the same within the present Algorand protocol, BA * was modified a little, in order to represent the present model and different communication context.

[00169] We begin by recalling the model in which BA * operates and the notion of Byzantine agreement.

3.1 COMPLETE SYNCHRONIZED NETWORKS AND

CORRELATED ADVERSARIES

[00170] In a SC network, there is a common clock, indicating at each integral moment r = 1, 2,. . .

[00171] At each click of time even, each player i instantly and simultaneously sends a single message (possibly the empty message) to each player j, including himself. Each is correctly received at time click r + 1 by player j, together with the identity of issuer i.

[00172] Again, in a communication protocol, a player is honest if he follows his prescribed instructions and is otherwise malicious. All malicious players are fully controlled and perfectly coordinated by the opponent, who, in particular, immediately receives all messages addressed to malicious players and choose the messages they send.

[00173] The opponent can immediately make malicious any honest user who wants to in any odd time click he wants, subject only to a possible upper limit t to the number of malicious players. In other words, the opponent "cannot interfere with messages already sent by an honest user i", which will be sent normally.

[00174] The opponent also has the additional ability to instantly see, in each even round, the messages that currently honest players send, and instantly use that information to choose the messages that malicious players send at the same time stamp.

3.2 THE NOTION OF A BYZANTINE AGREEMENT

[00175] The notion of Byzantine agreement may have been first introduced for the binary case, that is, when each initial value consists of a bit. However, it was quickly extended to arbitrary initial values. A BA protocol means one of arbitrary value.

[00176] Definition 3.1. In a synchronized network, P is a protocol of n players, whose set of players is common knowledge among players, t is a positive integer, so that n ≥ 2t + 1. P is said to be a protocol according Byzantine (n, t) of arbitrary value (respectively, binary) with strength σ idez (0, 1) if, for each set of values, V does not contain the special symbol (respectively, for V = {0, 1}), in an execution where at most t the players are malicious and where each player i starts with an initial value vi ∈ V, each honest player j stops with probability 1 to issue an outi value in order to satisfy, with probability at least σ , the following two conditions:

[00177] 1. Agreement: There is a way out so that outi = out for all honest players i.

[00178] 2. Consistency: if, for some value for all players i, then out = v.

[00179] Output is called the output of P, and each output is output of player i.

3.3 THE NOTATION OF BA #

[00180] In the present BA protocols, a player is needed to count how many players send a given message at a given stage. Consequently, for every possible value v that can be sent,

[00181] (or just #i (v) when s is clear) is the number of players j from each i who received v in step s.

[00182] Recalling that a player i receives exactly one message from each player j, if the number of players is n, then, for all i and s,

3.4 THE NEW BA BBA BINARY PROTOCOL *

[00183] In this section, we present a new binary protocol BA, BBA *, which is based on the honesty of more than two thirds of the players and is very fast: no matter what the malicious players may do, each execution of this main circuit it is not just trivially executed, but it puts players in agreement with 1/3 probability.

[00184] In BBA *, each player has his own public key of a digital signature scheme that satisfies the exclusive signature property. Since this protocol is intended to run on a complete synchronized network, there is no need for a player to signal each of their messages.

[00185] 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.)

[00186] The protocol requires a minimum configuration: a common random series r; regardless of player keys. (In Algorand, r is actually replaced by the quantity Qr.)

[00187] The BBA * protocol is a 3-step circuit, in which players repeatedly exchange Boolean values, and different players can leave this circuit at different times. A player i leaves this circuit by propagating, at some stage, a special value of 0 * or a special value of 1 *, thus instructing all players to “simulate” that, respectively, they received 0 and 1 of i in all future steps. (Alternatively: it is assumed that the last message received by a player j from another player i was a bit b. So, at any stage where he receives no message from i, j acts as if i had sent bit b.)

[00188] The protocol uses a counter that represents how many times its 3-step circuit has been executed. At the beginning of BBA *, (You can think of γ as a global counter, but it is actually increased by each individual player at each moment that the circuit is run.)

[00189] There are n ≥ 3t + 1, where t is the maximum possible number of malicious players. A binary series x is identified with the integer whose binary representation (with possible leaders 0s) is x; and lsb (x) denotes the least significant bit of x. BBA PROTOCOL *

[00190] (COMMUNICATION) STEP 1. [Fixed Currency Step at 0] Each player i sends bi.

1.1 If i then define bi = 0, send 0 *, issue outi = 0 and HALTS.

1.2 If so, i defines bi = 1.

1.3 Otherwise, i defines bi = 0.

[00191] (COMMUNICATION) STEP 2. [Fixed Currency Step at 1] Each player i sends bi.

2.1 If so, i defines bi = 1, sends 1 * m and emits outi = 1, and HALTS.

2.2 If so, i defines bi = 0.

2.3 Otherwise, i defines bi = 1.

[00192] (COMMUNICATION) STEP 3. [Coin Step Genuinely Launched] Each player i sends bi e

3.1 If so, i defines bi = 0.

3.2 If so, i defines bi = 1.

3.3 Otherwise, if Si = {j ϵ N, which sends i an appropriate message in this step 3}, i define increases by 1; and returns to Step 1.

[00193] Theorem 3.1. Whenever n ≥ 3t + 1, BBA * is a binary (n, t) -BA protocol with solidity 1.

[00194] A proof of Theorem 3.1 can be found at https://people.csail.mit.edu/silvio/ Selected- ScientificPapers / DistributedComputation / BYZANTINEAGREEMENTMADET RIVIAL.15 pdf.

3.5 CLASSIFIED CONSENSUS AND THE GC PROTOCOL

[00195] It is recalled, for arbitrary values, a notion of consensus much weaker than Byzantine agreement.

[00196] Definition 3.2. P is a protocol in which the set of all players is common knowledge, and each player i privately knows an arbitrary initial value

[00197] It is said that P is a consensus protocol classified by (n, t) if, in each execution with n players, at most t of which are malicious, each honest player i stops issuing a value-class pair ( vi, gi), where gi ∈ {0, 1, 2}, in order to satisfy the following three conditions:

1. For all honest players i and j,

2. For all honest players i and j,

3. If for some value v, then, and for all honest players i.

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

GC PROTOCOL

[00199] STEP 2. Each player i sends to all players.

[00200] STEP 3. Each player i sends all players the series x if and only if

[00201] DETERMINATION OF OUTPUT. Each player i issues the pair (vi, gi) computed as follows: • If, for some x, then e. • If, for some x, then, and • Otherwise, and

[00202] Since the GC protocol is a protocol in the literature, it is known that the following theorem remains.

[00203] Theorem 3.2. If then GC is a diffusion protocol classified by (n, t).

3.6 THE BA PROTOCOL *

[00204] The BA protocol of arbitrary value BA * will now be described by means of the binary BA protocol BBA * and the consensus protocol classified GC. Below, the starting value of each player i is PROTOCOL BA *

[00205] STEPS 1 AND 2. Each player i performs GC, at the entrance in order to compute a pair (vi, gi).

[00206] STEP 3,. . . Each player i executes BBA * - with initial input 0, if gi = 2, and 1 otherwise - in order to compute the bit output.

[00207] DETERMINATION OF OUTPUT. Each player i issues vi, if outputi = 0, and otherwise.

[00208] Theorem 3.3. Whenever n ≥ 3t + 1, BA * is a protocol (n, t) -BA with solidity 1.

[00209] Proof. Consistency was first proven and then the Agreement.

[00210] PROOF OF CONSISTENCY. It is assumed that, for some value, v. Then, by property 3 of the classified consensus, after the execution of the GC, all honest players issue (v, 2). Consequently, 0 is the starting bit for all honest players at the end of the BBA * execution. Thus, by the Binary Byzantine Agreement Agreement property, at the end of the BA * execution, outi = 0 for all honest players. This implies that the exit of each honest player i in the

BA * is vi = v.

[00211] PROOF OF AGREEMENT. Since BBA * is a binary BA protocol, or

[00212] (A) outi = 1 for every honest player i, or

[00213] (B) outi = 0 for every honest player i.

[00214] In case A, all honest players issue at BA *, and thus the Agreement remains. Now consider case B. In this case, in the execution of BBA *, the starting bit of at least one honest player i is 0. (In fact, if the starting bit of all honest players is 1, then, for the Consistency property from BBA *, we would have outj = 1 for every honest j.) Consequently, after the execution of GC, i issues the pair (v, 2) for some value v. Thus, by property 1 of the classified consensus, gj> 0 for all honest players j. Consequently, by property 2 of the classified consensus, vj = v for all honest players j. This implies that, at the end of the BA *, each honest player already issues v.

Thus, the Agreement also remains in case B.

[00215] Since both Consistency and the Agreement remain, BA * is a BA protocol of arbitrary value. ■

[00216] The BA * Protocol also works in transmission networks and, in fact, satisfies the player's capacity for substitution, which is crucial for Algorand to be safe in the very contradictory model provided.

[00217] The Substitution Capacity of the BBA * and BA * Player now allows the provision of some intuition as to why the BA * and BBA * protocols can be adapted to run on a network where communication is through transmission point to point, satisfying the player's substitution ability. For concreteness, it is assumed that the network has 10M of users and that each stage x of BBA * (or BA *) is performed by a committee of 10,000 players, who were randomly selected through secret cryptographic draw and thus have credentials proving to be qualified to send messages in step x. It is assumed that each message sent at a certain stage specifies the stage number, is digitally signed by its sender and includes the credential proving that its sender is qualified to speak at that stage.

[00218] Firstly, if the percentage h of honest players is sufficiently greater than 2/3 (for example, 75%), then, most likely, the committee selected at each stage has an honest 2/3 majority required.

[00219] Additionally, the fact that the 10,000 randomly selected strong committee changes at each stage does not prevent the BBA * or BA * from functioning correctly. In fact, in each protocol, a player i in step s reacts only to the multiplicity with which, in step s - 1, he received a certain message m. Since you are on a transmission network, all messages sent in step s - 1 will reach (immediately, for the purpose of this intuition) all users, including those selected to play in step s. Furthermore, due to the fact that all messages sent in step s - 1 specify the step number and include the credential that the sender was, in fact, authorized to speak in step s - 1. Consequently, if he was selected also in step s - 1 or not, a user i selected to play in step s is perfectly capable of correctly counting the multiplicity with which he received a message from the correct step s - 1. It doesn't matter, at all, whether he was playing 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

[00220] As discussed, at a very high level, an Algorand round 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 emerges). Second, a randomly selected committee of users is selected and reaches 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 the committee members. These digital signatures are propagated so that everyone is sure what the new block is. (This includes circulating subscribers' credentials and authenticating only the hash of the new block, ensuring that everyone is guaranteed to learn the block, once the hash is made clear).

[00221] In the following two sections, two modalities of the basic Algorand project are presented, which work respectively under the assumption of an appropriate majority of honest users. Section ?? shows how to adopt these modalities to work under the assumption of an honest majority of money.

[00222] provides only that> 2/3 of the committee members are honest. Additionally, in, the number of steps to reach the Byzantine agreement is limited by a suitably high number, so that it is guaranteed that the agreement is most likely to be reached within a fixed number of steps (but potentially requiring longer time than the steps of In the remote case where the agreement is not yet reached in the last step, the committee agrees with the empty block, which is always valid.

[00223] It provides that the number of honest members in a committee is always greater than or equal to a fixed limit tH (which guarantees that, in great probability, at least 2/3 of the members of the committee are honest). Additionally, it allows the Byzantine agreement to be reached in an arbitrary number of steps (but potentially in a shorter time than

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

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

4.1 A COMMON CORE

[00226] Objectives Ideally, for each round r, Algorand should satisfy the following properties:

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

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

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

[00230] Certainly, ensuring perfect accuracy alone 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. Thus, Algorand adopts a more realistic objective. Informally, letting h denote the percentage of users who are honest, h> 2/3, Algorand's goal is

[00231] Ensuring, with great probability, perfect accuracy and completeness close to h.

[00232] Privileging accuracy over completeness seems to be a reasonable choice: payments not processed in one round can be processed in the next, but forks should be avoided if possible.

[00233] Byzantine Agreement Conducted Disregarding excessive time and communication for a moment, perfect Accuracy could be guaranteed as follows. At the beginning of round r, each user i proposes his own candidate block. Then, all users reach the Byzantine agreement in only one of the candidate blocks. According to the introduction, the BA protocol employed requires an honest 2/3 majority and is eligible for player substitution. Each of its steps can be performed by a small randomly selected set of verifiers, which do not share any internal variables.

[00234] Unfortunately, this approach does not work well. This is due to the fact that the candidate blocks proposed by honest users are, most likely, totally different from each other. In fact, every honest user sees different payments. Thus, while payment sets seen by different honest users can have many overlaps, it is unlikely that all honest users will purposely build the same block. Consequently, the BA protocol consistency agreement is never linked, only agreement one is, and thus the agreement can always be reached in rather than in a good block.

[00235] avoids this problem as follows. First, a leader for the round is selected. Then, propagate your own candidate block. Finally, users reach agreement on the block they actually receive from. Due to the fact that, whenever it is honest, both Perfect Accuracy and Completeness 1 remain, it ensures that you are honest with probability. close to h.

[00236] Leader Selection In Algorand, the r-th block is of the form

[00237] As already mentioned in the introduction, the Qr-1 quantity is carefully constructed so as to be essentially unmanageable by the very strong opponent. (Later in this section, some intuition will be provided as to why this is the case). At the start of a round r, all users know the blockchain so far, B0,. . . , Br-1, from which they deduce the set of users from each previous round: that is,. A potential leader of round r is a user i so that

[00238] Explain yourself. Note that, since the quantity Qr-1 is deductible from the Br-1 block, because of the message recoverability property of the underlying digital signature scheme. In addition, the underlying subscription scheme satisfies the exclusivity property.

Thus, it is a binary chain exclusively associated with i and r.

Consequently, since H is a random oracle, it is a 256-bit string of random length exclusively associated with i and r. The symbol "." in front of is the decimal point (in this case, binary), so that it is the binary expansion of a random 256-bit number between 0 and 1 exclusively associated with i and r. Thus, the probability that ri is less than or equal to p is essentially

P.

[00239] The probability p is chosen so that, with a high (ie, 1 - F) probability, at least one potential verifier is honest. (In fact, p is chosen to be the least such probability). Note that since i is the only one with the ability to compute his own signatures, he alone can determine if he is a potential verifier in round 1. However, by revealing his own credential, i can prove to anyone that he is a potential verifier of the round r.

[00240] The leader is defined as being the potential leader whose hash verified credential is less than the hash verified credential of another potential leader j: that is,

[00241] Note that since a malicious person may not reveal his credential, the correct leader of round r may never be known, and that, preventing improbable ties, he is, in fact, the only leader of round r.

[00242] Finally, a final but important detail is presented: a user i can be a potential leader (and thus the leader) of a round r only if he belongs to the system for at least k rounds. This guarantees the non-manipulability of Qr and all future Q quantities. In fact, one of the potential leaders will actually determine Qr.

[00243] Verifier Selection Each step s> 1 of round r is performed by a small set of verifiers,. Again, each tester is randomly selected from among users already in the k system before r, and again using the special quantity Qr-1. Specifically, it is a checker on whether

[00244] Again, only i know if he belongs to SVr, s, but if that is the case, he could prove it by displaying his credential

. A verifier i ∈ sends a message, in step s of round r, and that message includes your credential to allow verifiers f in the next step to recognize that it is a legitimate message from step s.

[00245] The probability p 'is chosen to ensure that, in SVr, s, #bom is the number of honest users and #mau is the number of malicious users, with a high probability that the following two conditions will remain .

[00246] For the modality

[00247] (1) #bom> 2 · # bad and

[00248] (2) #bom + 4 · #mau <2n, where n is the expected cardinality of SVr, s.

[00249] For the Algorand'2 modality:

[00250] (1) #bom> tH e

[00251] (2) #bom + 2 # bad <2tH, where tH is a specified limit.

[00252] 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 players to digitally sign the new Br block, (b) only one block per round can have the required number of signatures, and (c) the BA protocol used has (at each stage) the honest 2/3 majority required.

[00253] Generation of Clarification Block If the leader of round r is honest, then the corresponding block is in the form

[00254] where the PAYr payment set is maximum, (remember that all payment sets are, by definition,

collectively valid).

[00255] In another way (that is, if it is malicious), Br has one of the following two possible forms:

[00256] In the first form, it is a set of payments (not necessarily maximum) and can be e i is a potential leader of round r. (However, i may not be the leader. This may in fact happen if you keep your credential secret and don't reveal yourself).

[00257] The second form appears when, in the execution of round r of the BA protocol, all honest players issue the default value, which is the empty block in this order. (By definition, possible outputs from a BA protocol include a default value, generally denoted by See section 3.2.)

[00258] Note that, although payment sets are empty in both cases, and are syntactically different blocks and arise in two different situations: respectively, "everything went well enough in the execution of the BA protocol" and "something went wrong in the BA protocol, and the default value was issued ”.

[00259] It is now intuitively described how the generation of the Br block proceeds in round r of In the first stage, each eligible player, that is, each player verifies whether he is a potential leader. If this is the case, then i, with the use of all the payments he has seen so far, and the current blockchain, are asked to secretly prepare a maximum payment set, and secretly assemble his candidate block, Br = . That is, it not only includes as its second component, the newly prepared set of payments, but also, as its third component, its own signature of Qr-1, the third component of the last block,. Finally, it propagates its message from step 1 of round r, which includes (a) its candidate block (b) its appropriate signature from its candidate block (that is, its signature from the hash of and (c) its own credential that proves that he is, in fact, a potential tester for round r.

[00260] (Note that until an honest i produces his message the Opponent has no idea that i is a potential tester. If he wants to corrupt potential honest leaders, the Opponent can also corrupt random honest players. However, since he see that it already contains the credential of i, the opponent knows and could corrupt i, but cannot prevent what is virally propagated from reaching all users in the system).

[00261] In the second step, each selected verifier already tries to identify the leader of the round. Specifically, it already takes the credentials from step 1, contained in the appropriate step 1 message it received; hash checks all the same, that is, computes finds the credential, whose hash is lexicographically minimal; and considers as the leader of the round.

[00262] Remember that each credential considered is a digital signature of Qr-1, which is uniquely determined by ie that H is the random oracle, and thus that each is a 256-bit string of random length unique to each potential leader i of round r.

[00263] From this, it can be concluded that, if the 256-bit Qr-1 chain itself is random and independently selected, these would be the hash-verified credentials of all potential leaders of round r. In fact, all potential leaders are well defined, and so are their credentials (actually computed or not). Furthermore, the set of potential leaders in round r is a random subset of users in round r - k, and an honest potential leader i always builds and propagates his message appropriately containing the credential of i. So, since the percentage of honest users is h, no matter what potential malicious leaders may do (for example, reveal or hide their own credentials), the potential leader's credential verified by minimal hash belongs to an honest user, who is necessarily identified by everyone as the leader of round r. Consequently, if the 256-bit string Qr-1 itself is random and independently selected, with probability exactly h (a) the leader is honest and (b) for all verifiers in step 2 honest j.

[00264] In reality, the credentials verified by are, yes, randomly selected, but depend on that it is not randomly and independently selected. Careful analysis, however, ensures that it is sufficiently unmanageable to ensure that the leader of a round is honest with a probability close enough to h: namely,

[00265] For example, if h = 80%, then 0.7424.

[00266] Having identified the leader of the round (which they do correctly when the leader is honest), the task of the verifiers in step 2 is to start the execution of BA * using as initial values what they believe to be the leader block. In reality, in order to minimize the amount of communication required, a verifier no longer uses, as its input, the value for the Byzantine protocol, the block it actually received from (the user already believes to be the leader), but the leader, but the hash of that block, that is,. Thus, upon the termination of the BA protocol, the verifiers of the last stage do not compute the Br block of round r, but compute (authenticate and propagate) H (Br). Consequently, since H (Br) is digitally signed by sufficiently many verifiers from the last stage of the BA protocol, users in the system will realize that H (Br) is the hash of the new block. However, they must also recover (or wait for, since the execution is quite asynchronous) the Br block itself, which the protocol guarantees is actually available, no matter what the opponent may do.

[00267] Asynchrony and Timing and have a significant degree of asynchrony. This is due to the fact that the opponent has great latitude in the delivery schedule of the messages being propagated. Additionally, whether the total number of steps in a round is limited or not, there is a contribution of variance by the number of steps actually taken.

[00268] As soon as he learns the B0 certificates,. . . , Br-1, a user i computes Qr-1 and starts to work in round r, checking if he is a potential leader or a verifier in some stages s of round r.

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

[00270] For example, he can expect to receive at least a certain number of messages from the verifiers in the previous step (as in, or wait long enough to ensure that he receives messages from sufficiently many verifiers in the previous step (as in

[00271] The Seed Qr and the Retrospective Parameter k Remember that, ideally, the quantities Qr should be random and independent, although it is sufficient that they are sufficiently not manipulable by the opponent.

[00272] At first glance, one could choose Qr-1 to match H (PAYr-1). An elementary analysis reveals, however, that malicious users can take advantage of this selection mechanism. 6 Some additional effort shows that countless other alternatives, based on traditional block quantities, are easily exploitable by being found at the beginning of round r - 1. Thus, Qr-2 = PAYr-2 is publicly known, 6 and the Opponent privately knows who the potential leaders he controls are. It is assumed that the opponent controls 10% of the users, and that, with a very high probability, a malicious user w is the potential leader of the round r - 1. That is, it is assumed that H (SIGw (r - 2, 1, Qr-2)) is so small that it is highly unlikely that an honest potential leader will actually be the leader of the r - 1 round. (Remember that since potential leaders were chosen through a secret cryptographic draw mechanism , the Adversary doesn't know who the potential honest leaders are). The opponent, therefore, is in the enviable position of choosing the PAY payout set that he wants to make the official payout set for round r - 1 the same. However, he can do more. He can also ensure that, with high probability, (*) one of his malicious users is also the leader of round r, so that he can freely select which PAYr will be. (And so on. At least for a long time, that is, as long as these high probability events actually occur). To guarantee (*), the Opponent acts as follows. Let PAY 'be the set of payouts that the Opponent prefers for round r - 1. Then, he computes H (PAY') and checks whether, for any already malicious player z, SIG z (r, 1, H (PAY ')) is particularly small, that is, small enough that, with a fairly high probability z, is the leader of round r. If this is the case, then he instructs w to choose his candidate block to be. Otherwise, he has two other malicious users x and y to continue generating a new payment from each other, until, for some malicious user z (or even for some fixed user z), he is particularly small as well. This experiment will stop very quickly. And when it stops, the Opponent asks w to propose the candidate block

Opponent to ensure that malicious leaders are frequent. Instead, the new quantity Qr is specifically and inductively defined in order to have the ability to prove that it is not manipulable by the Adversary. Namely, if Br is not the empty block, and otherwise.

[00273] The intuition of why this construction of Qr works is as follows. Suppose for a moment that Qr-1 is truly random and independently selected. So, is it also Qr? When you are honest, the answer is (roughly) yes. This is because of the fact that

[00274] is a random function. When it is malicious, however, Qr is no longer uniquely defined from Qr-1 and there are at least two separate values for Qr. One remains and the other is H (Qr-1, r). First, it is argued that, although the second choice is somewhat arbitrary, a second choice is absolutely mandatory. The reason for this is that a malicious one can always cause completely different candidate blocks to be received by honest second-stage verifiers.7 Once this is the case, it can be easy to ensure that the block recently agreed through the round's BA r will be the standard block and thus will not contain anyone's digital signature of Qr-1. But the system must continue and, for that, it needs a leader for round r. If that leader is automatically and openly 7 For example, to keep it simple (but extreme), "when the time for the second stage is almost expiring", you could directly email a different candidate block Bi to each user i. In this way, whoever the verifiers in step 2 are, they will receive totally different blocks.

selected, then the Opponent will trivially corrupt you. If selected by the previous Qr-1 through the same process, then you will again be the leader in round r + 1. It is specifically proposed to use the same secret cryptographic draw mechanism, but applied to a new quantity Q: namely, H (Qr-1, r). Having this quantity as the output of H ensures that the output is random, and including r as the second input of H, while all other uses of H have either a single input or at least three inputs, “guarantee” that such Qr is independently selected. Again, the specific choice of alternative Qr does not matter, what matters is that he has two choices for Qr, and thus he can double his chances of having another malicious user as the next leader.

[00275] The options for Qr can be even more numerous for the opponent who controls a malicious one. For example, letting x, y, and z be three potential malicious leaders of round r

[00276] so that

[00277] and be particularly small. That is, so small that there is a good chance that it is less than the hash verified credential of each potential honest leader. Then, by asking x to hide his credential, the opponent has a good chance of y becoming the leader of round r - 1. This implies that he has another option for Qr: namely,. Similarly, the Opponent may request that both x and y retain their credentials, so that z becomes the leader of the round r - 1, gaining another option for Qr: namely,

[00278] Certainly, however, each of these and other options has a non-zero chance of failing, due to the fact that the adversary cannot predict the hash of the digital signatures of potential honest users.

[00279] A careful Markov chain analysis shows that, no matter what options the opponent chooses to make in round r - 1, as long as he cannot inject new users into the system, he cannot decrease the likelihood of an honest user being the leader of the round r + 40 far below h. This is the reason why potential leaders in round r are required to be existing users in round r - k. It is a way of ensuring that, in round r - k, the opponent cannot change the probability that an honest user will become the leader of round r. In fact, no matter what users he may add to the system in rounds r - k through r, they are ineligible to become potential leaders (and, a fortiori, the leader) of round r. Thus, the retrospective parameter k is ultimately a safety parameter. (Although, as you can see in the ?? section, it can also be a type of "convenience parameter").

[00280] Temporary Keys Although the execution of the protocol cannot generate a bifurcation, except with insignificant probability, the opponent could generate a bifurcation, in the r-th block, after the legitimate r block has been generated.

[00281] Approximately, once Br has been generated, the Opponent has learned who the verifiers of each stage of round r are. Thus, it could therefore corrupt all of them and compel them to certify a new block. Since this fake block can only be propagated after the legitimate one, users who have been paying attention would not be deceived.8 However, it would be syntactically correct, and it is desired to be prevented 8 Consider corrupting the news anchor of a major TV network and produce and broadcast today a newscast that shows Secretary Clinton winning the last presidential election. Most would recognize this as a scam. But someone coming out of a coma can be tricked.

to be manufactured.

[00282] This is done by means of a new rule. Essentially, members of the SVr, one-step verifier set of round r use temporary 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 verifier is subsequently corrupted, the Opponent cannot force him to sign anything else that he did not originally sign.

[00283] Of course, it must be ensured that it is impossible for the Opponent to compute a new key and convince an honest user that it is the right temporary key for the i ∈ SVr, s verifier for use in step s.

4.2 COMMON SUMMARY OF NOTES, NOTIONS AND

PARAMETERS

[00284] Notations

[00285] • r ≥ 0: the current round number.

[00286] • s ≥ 1: the current stage number in round r.

[00287] • Br: the block generated in round r.

[00288] • PKr: the set of public keys at the end of round r - 1 and at the beginning of round r.

[00289] • Sr: the system situation at the end of round r - 1 and at the beginning of round r.9

[00290] • PAYr: the set of payments contained in Br.

[00291] • leader of the round r. choose the set of In a system that is not synchronous, the notion of "end of round r - 1" and 9 "beginning of round r" needs to be carefully defined. Mathematically, PK r and Sr are computed from the initial situation S0 and blocks B1,. . . , Br-1.

PAYr payments of round r (and determines the next Qr).

[00292] • Qr: the seed of round r, a quantity (ie, binary chain) that is generated at the end of round r, is used to choose the verifiers for round r + 1. Qr is independent of the sets of payments in blocks and cannot be manipulated by

[00293] • SVr, s: the set of verifiers chosen for step s of round r.

[00294] • SVr: the set of verifiers chosen for round r,

[00295] • MSVr, s and HSVr, s: respectively the set of malicious scanners and the set of honest scanners in SVr, s.

and

[00296] • 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.

[00297] Note that n1 << n, since you need at least one honest member in SVr, 1, but at least a majority of honest members in each SVr, s for s> 1.

[00298] • 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 honest money, depending on the assumption used, in each Pkrr is at least h.

[00299] • H: a cryptographic hash function, modeled as a random oracle.

[00300] •: A special chain of the same length as the H outlet.

[00301] • F ∈ (0, 1): the parameter that specifies the allowed error probability. A probability ≤ F is considered "insignificant", and a probability ≥ 1 - F is considered "large".

[00302] • ph ∈ (0, 1): the probability that the leader of a round r, is honest. Ideally, ph - h. With the Opponent's existence, the ph value will be determined in the analysis.

[00303] • the retrospective parameter. That is, round r - k is when the checkers for round r are chosen from - to 10,

[00304] • p1 ∈ (0, 1): for the first stage of round r, a user in round r - k is chosen to be in SVr, 1 with probability

[00305] • p ∈ (0, 1): for each s> 1 of round r, a user in round r - k is chosen to be in SVr, s with probability

[00306] • CERTr: the certificate for Br. The same is a set of tH signatures of H (Br) of appropriate verifiers in round r.

[00307] • is a proven block.

[00308] A user i knows Br if he has (and successfully checks) both parts of the proven block. Note that the CERTr seen by different users may be different.

[00309] • the time (local) in which a user i knows Br. In the Algorand protocol, each user has his own clock. The clocks of different users do not need to be synchronized, but they must have the same speed. For the purpose of analysis only, a reference clock is considered and the players' related times are measured in relation to it.

[00310] • and, respectively, the time (local) in which 10 Strictly speaking, "r - k" must be "max {0, r - k}”.

a user i starts and ends his execution of step s of round r.

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

[00312] The parameter Λ defines the upper time limit for propagating a single block of 1 MB.

[00313] The parameter λ defines the upper time limit for propagating a small message per verifier in a Step s> 1.

[00314] It is assumed that Λ ≤ 4λ.

[00315] Notions

[00316] • Selection of verifier.

[00317] For each round r and stage Each user i ∈ PKr-k privately computes his signature using his long-term key and decides whether i ∈ SVr, s or not. If i ∈ SVr, s, then, is the credential (r, s) of i, compactly denoted by

[00318] For the first stage of the round r, SVr, 1 and are similarly defined, with p replaced by p1. Verifiers in SVr, 1 are potential leaders.

[00319] • Selection of leader.

[00320] User i ∈ SVr, 1 is the leader of round r, denoted by for all potential leaders j ∈ SVr, 1. Whenever the hashes of two player credentials are compared, in the unlikely event of links, the protocol always breaks the links lexicographically according to (the long-term public keys of) potential leaders.

[00321] By definition, the hash value of the player's credential is also the lowest of all users in PKr-k. Note that a potential leader cannot privately decide whether he is the leader or not, without seeing the credentials of other potential leaders.

[00322] Since the hash values are uniformly random, when SVr, 1 is not empty, it always exists and is honest with probability of at least h. Parameter n1 is large enough to ensure that each SVr, 1 is not likely to be empty.

[00323] • Block structure.

[00324] A non-empty block is of the form and an empty block is of the form

[00325] Note that a non-empty block may still contain an empty PAYr payment set, if no payments occur in that round or if the leader is malicious. However, a non-empty pad implies that your identity and credential have all been revealed over time. The protocol guarantees that, if the leader is honest, then the block is not likely to be empty.

[00326] • Qr seed.

[00327] If Br is not empty, then, otherwise,

[00328] Parameters

[00329] • Relationships between several parameters.

[00330] - Checkers and potential leaders of round r are selected from users in PKr-k, where k is chosen so that the opponent cannot predict Qr-1 back to round r - k - 1 with better probability than F: otherwise, he will be able to introduce malicious users to round r - k, all of whom will be potential leaders / verifiers in round r, succeeding in having a malicious leader or a malicious majority in SVr, s for some steps are desired by him.

[00331] - For step 1 of each round r, n1 is chosen so that, with great probability,

[00332] • Exemplary choices of important parameters.

[00333] - H outputs are 256 bits long.

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

[00335] - Λ = 1 minute and = 15 seconds.

[00336] • Initialization of the protocol.

[00337] The protocol starts at time 0 with r = 0. Since there is no “B-1” or “CERT-1”, syntactically, B-1 is a public parameter with its third component specifying Q-1, and all users know B-1 at time 0. 5 ALGORAND'1

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

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

[00340] In the ?? section, it is shown how to replace the above assumption with the honest majority majority assumption.

5.1 ADDITIONAL NOTES AND PARAMETERS

[00341] Notations

[00342] • the maximum number of steps in the binary BA protocol, a multiple of 3.

[00343] • a random variable that represents the number of Bernoulli tests needed to see a 1, when each test is 1 with probability and there are at most m / 3 tests.

[00344] If all tests fail, then. Lr will be used to define the upper limit of the time required to generate the block

Br.

[00345] • the number of signatures required in the final terms of the protocol.

[00346] • CERTr: the certificate for Br. The same is a set of tH signatures of H (Br) of appropriate verifiers in round r.

[00347] Parameters

[00348] • Relationships between several parameters.

[00349] - For each stage s> 1 of round r, n is chosen so that, with great probability, and

[00350] 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 are very likely to remain.

[00351] - m is chosen so that Lr <m / 3 is very likely.

[00352] • Exemplary choices of important parameters.

[00353] - F = 10-12.

[00354] - n ≈ 1500, k = 40 and m = 180.

5.2 IMPLEMENTATION OF TEMPORARY KEYS IN ALGORAND'1

[00355] As already mentioned, it is desired that a verifier i ∈ SVr, s digitally sign his message of step s in round r, in relation to a temporary public key with the use of a temporary secret key which he destroys promptly after the use. Thus, an efficient method is needed to ensure that each user can verify that it is, in fact, the key to verify i de's signature.

This is done by a (to the best understanding) new use of identity-based subscription schemes.

[00356] 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 player, A computes, via SMK, a secret signature key skU in relation to the public key U1, and privately provides skU to U. (In fact, in a digital signature scheme based on in identity, a U user's public key is U itself!) So, if A destroys the SMK after computing the secret keys of the users he wants to enable to produce digital signatures and not keep any secret keys computed, then U is the only one who can digitally sign messages in relation to public key U. Thus, anyone who knows “the name of U” automatically knows U's public key and can thus verify U's signatures (possibly also using the public master key PMK).

[00357] In this order, authority A is user i, and the set of all possible users U coincides with the round-step pair (r, s) in - for example - where r 'is a given round, at + 3 the upper limit for the number of steps that can occur within a round. In this way, so that everyone who sees the signature of i can, with great probability, immediately verify the same for the first million rounds r after r '.

[00358] In other words, i first generates PMK and SMK. He then publishes that PMK is the master public key of i for any round r and uses SMK to produce and privately store the secret key for each triple (i, r, s) ∈ S. With that done, he destroys the SMK.

If it determines that it is not part of SVr, s, then i can leave it alone (as the protocol does not require it to authenticate any message in step s of round r). Otherwise, i first uses it to digitally sign your message and then destroys

[00359] Note that i can publish his first public master key when he first enters the system. That is, the same payment that takes i to the system (in a round r 'or in a round close to r') can also specify, in the request for i, that the public master key of i for any round is PMK —for example , including a pair of the shape

[00360] Also note that, since m + 3 is the maximum number of steps in a round, assuming that a round takes one minute, the stash of temporary keys thus produced will last for i for almost two years. At the same time, these temporary secret keys will not take long to be produced by i. Using an elliptical curve-based system with 32B keys, each secret key is computed in a few microseconds. So, if m + 3 = 180, then all 180M secret keys can be computed in less than an hour.

[00361] When the current round is approaching to handle the next million rounds, i generates a new pair of and informs you of your next temporary key stash by having - for example - insert a new block, either as a separate “transaction” or as some additional information that is part of a payment. In doing so, i informs everyone that he / she should use PMK 'to check i's temporary signatures for the next million rounds. And so on.

[00362] (Note that, after this basic approach, other ways to deploy temporary keys without using identity-based signatures are certainly possible. For example, through Merkle trees.11)

[00363] Other ways to deploy temporary keys are certainly possible - for example, through Merkle trees.

5.3 CORRESPONDENCE OF THE STEPS OF ALGORAND'1 WITH THOSE OF BA *

[00364] As stated, a round in has a maximum of m + 3 stages.

[00365] STEP 1. In this step, each potential leader i computes and propagates his candidate block together with his own credential,.

[00366] Remember that this credential explicitly identifies i. This is because of the fact that

[00367] The potential verifier i also propagates, as part of its message, its appropriate digital signature of. Not dealing with a payment or a credential, this i signature is related to your temporary public key, that is, it propagates

[00368] Given the conventions, instead of propagating and it could have propagated However, in the analysis, 11 In this method, i generates a pair of public-secret keys for each round-step pair (r, s) in - for example - Then, he orders these public keys in a canonical way, stores the j-th public key on the j-th leaf of a Merkle tree and computes the root value Ri, which he publishes. When he wants to sign a message related to the key i not only provides the actual signature, but also the authentication path for in relation to Ri. Note that this authentication path also proves that it is stored on the j-th sheet. From that idea, the rest of the details can be easily completed.

you need to have explicit access to

[00369] STEPS 2. In this step, each verifier i defines to be the potential leader whose hash verified credential is the lowest and to be the block proposed by. Since, for efficiency, if you want to agree with H (Br), instead of directly with Br, i propagate the message that he would have propagated in the first stage of BA * with initial value That is, he propagates after temporarily signing the same , obviously. (Namely, after signing the same in relation to the right temporary public key, which in this case is Obviously also, i also transmits its own credential.

[00370] Since the first stage of BA * consists of the first stage of the consensus protocol classified GC, step 2 of Algorand 'corresponds to the first stage of the GC.

[00371] STEPS 3. In this step, each verifier i ∈ SVr, 2 performs the second stage of BA *. That is, he sends the same message that he would have sent in the second stage of the GC. Again, i's message is temporarily signed and accompanied by i's credential. (From now on, it will be omitted that a verifier temporarily signs your message and also propagates your credential).

[00372] STEP 4. In this step, each verifier i ∈ SVr, 4 computes the GC output, (vi, gi) and temporarily signs and sends the same message that he would send in the third stage of BA *, that is, in the first BBA * step, with the initial bit 0 if gi = 2, and 1 otherwise.

[00373] STEP s = 5,. . . , m + 2. Such a stage, if reached, corresponds to stage s - 1 of BA * and thus stage s - 3 of BBA *.

[00374] 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 is reached by information that prove that the Br block has already been chosen. In this case, i interrupts his own execution of round r of Algorand 'and begins to execute his instructions for round- (r + 1).

[00375] Consequently, the instructions of a verifier in addition to the instructions corresponding to step s - 3 of BBA *, include verifying whether the execution of BBA * has stopped in a previous step s'. Since BBA * can only stop at a Currency Set at 0 stage or a Currency Set at 1 stage, the instructions distinguish whether

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

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

[00378] In fact, in case A, the Br block is not empty, so additional instructions are needed to ensure that i properly reconstructs Br, along with its appropriate CERTr certificate. In case B, block Br is empty, so i is instructed to define and compute CERTr.

[00379] If, during its execution of step s, i does not see any evidence that the Br block has already been generated, then it sends the same message that it would have sent in step s - 3 of BBA *.

[00380] STEP m + 3. If, during the step, you see that the Br block has already been generated in a previous s' step, then it proceeds as explained above.

[00381] Otherwise, instead of sending the same message that he could have sent in stage m of BBA *, i is instructed, based on the information in his possession, to compute Br and its corresponding CERTr certificate.

[00382] Remember, in fact, that the upper limit of the total number of steps in a round per m + 3 is defined.

5.4 THE REAL PROTOCOL

[00383] Remember that in each s of a round r, a verifier i ∈ SVr, s uses its long-term public-secret key pair to produce its credential, just as in the case s = 1. The verifier i use your temporary secret key to sign your message (r, s) For simplicity, when res are clear, write instead of to denote the appropriate temporary signature of i of a value x in step s of the re ESIGi (x) round instead of to denote. Step 1: Block Proposal

[00384] Instructions for each user i ∈ PKr-k: User i starts his own Stage 1 of round r as soon as he is aware of Br-1.

[00385] • User i computes Qr-1 from the third component of Br-1 and checks whether or not.

[00386] • If so, i interrupts its own execution of Step 1 immediately.

[00387] • If i ∈ SVr, 1, that is, if i is a potential leader, then he collects the payments from round r that have been propagated to him so far and computes a set of maximum payments from them. Then, it computes its “candidate block” Finally, it computes the message destroys its temporary secret key and then propagates

[00388] 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 he receives and successfully checks, 12 player i propagates it as usual. For all other messages (r, 1) that player i successfully receives and verifies, he propagates these only if the hash value of the credential they contain is the least of the hash values of the credentials contained in all messages (r, 1) that he has successfully received and verified so far. Furthermore, as suggested by Georgios Vlachos, it is useful that each potential leader i also propagate his credential separately: these small messages travel faster than blocks, guarantee timely propagation of those, where the credentials contained have small hash values, while making those with large hash values disappear quickly.

[00389] Stage 2: The First Stage of the GC Classified Consensus Protocol

[00390] Instructions for each user i ∈ PKr-k: User i starts his own Step 2 of round r as soon as he is aware of Br-1.

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

[00392] • If so, i interrupts its own execution of Step 2 immediately.

[00393] • If then after waiting for a certain amount of time i act as follows.

[00394] 1. It finds the user so that, for all credentials that are part of the messages (r, l) 12 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 for your proposer or not.

successfully verified, he has received so far.13

[00395] 2. If he received from a valid message 14, then i define otherwise i define 15

[00396] 3. i computes the message destroys your temporary secret key and then propagates

[00397] Stage 3: The Second Stage of the GC

[00398] Instructions for each user i ∈ PKr-k: User i starts his own step 3 of round r as soon as he is aware of Br-1.

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

[00400] • If so, i interrupts its own execution of step 3 immediately.

[00401] • If i ∈ Svr, 3, r, 3, then after waiting for an amount of time i acts as follows.

[00402] 1. If there is a value so that, among all the valid messages he received, more than 2/3 of them are of the form without any contradiction, 16 then he computes the 13 Essentially, the user i decides privately that the leader of round r is user l. 14 Again, the player's signatures and hashes are all successfully verified, and em is a set of payments valid for round r - although i don't check whether it is maximum for or not. 15 The message signals that player i considers the next block hash or considers the next block to be empty. 16 That is, he did not receive two valid messages containing and a different j, respectively, from player j. Henceforth, except in the Final Conditions defined below, whenever an honest player wants messages in a certain way, messages that contradict each other are never counted or considered valid.

message otherwise, it computes

[00403] 2. i destroys your temporary secret key and then propagates

[00404] Step 4: Exit from GC and The First Stage from BBA *

[00405] Instructions for each user User i starts his own step 4 of round r as soon as he is aware of

[00406] • User i computes from the third component of B and checks whether or not.

[00407] • If so, i interrupts its own execution of step 4 immediately.

[00408] • If, after waiting for a certain amount of time, act as follows.

[00409] 1. It computes vi and gi, the GC output, as follows.

[00410] (a) If there is a value so that, of all the valid messages he received, more than 2/3 of them are of the form, then he defines and

[00411] (b) Otherwise, if there is a value so that, of all the valid messages he received, more than 1/3 of the 17 messages are of the form, then he defines and

[00412] (c) Otherwise, it defines and

[00413] 2. It computes bi, the entry of BBA *, as follows:

[00414] and otherwise.

17 It can be proved that the v 'in case (b), if any, needs to be exclusive.

[00415] 3. It computes the message destroys your temporary secret key and then propagates

[00416] Stage s, 5 ≤ s ≤ m + 2, s - 2 mod 0 mod 3: One Currency Stage Set at 0 BBA *

[00417] Instructions for each user User i starts his own step s of round r as soon as he is aware of Br-1.

[00418] • User i computes Qr-1 from the third component of Br-1 and checks if i ∈ SVr, s.

[00419] • then, i interrupts its own execution of step s immediately.

[00420] • If i ∈ SVr, s, then it acts as follows.

[00421] - He waits until an amount of time has passed.

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

[00423] (a) mod 3 - that is, step s' is a Fixed Currency step at 0,

[00424] (b) i received at least 18 valid messages and

[00425] (c) i received a valid message with v =

[00426] then, i interrupts its own execution of step s (and, in fact, of round r) immediately without propagating anything; define e 18 Such message from player j is counted even if player i has also received a message from j that signals 1. Similar things to the Final Condition

1. As shown in the analysis, this is done to ensure that all honest users know Br within time λ from each other.

define your own CERTr as the set of messages from substep (b) .19

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

[00428] mod 3 - that is, step s' is a Fixed Currency step in 1, and

[00429] (b) i received at least tH 20 valid messages

[00430] then, i interrupts its own execution of step s (and, in fact, of round r) immediately without propagating anything; defines and defines its own CERTr as the subset message set (b ').

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

[00432] He defines vi as the vote of the majority in the second components of all valid that he received.

[00433] It computes bi as follows.

[00434] If more than 2/3 of all the valid ones you received are of the form, then, define

[00435] Otherwise, if more than 2/3 of all 19 User i now knows Br and his own round r ends. It still helps to propagate messages as a generic user, but does not initiate any propagation as a checker (r, s). In particular, it helped to propagate all messages in its CERTr, which is sufficient for this protocol. It is noted that it must also define for the binary BA protocol, but bi is not necessary in this case anyway. Similar things for all future instructions. 20 In that case, it doesn't matter what they are.

that you received are of the form, then define

[00436] Otherwise, it defines

[00437] It computes the message destroys your temporary secret key and then propagates

[00438] Stage s, 6 ≤ s ≤ m + 2, s - 2 mod 1 mod 3: One Currency Stage Set at 1 BBA *

[00439] Instructions for each user i ∈ PKr-k: User i starts his own step s of round r as soon as he is aware of Br-1.

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

[00441] • If i ∉ SVr, s, then i stops its own execution of step s immediately.

[00442] • If i ∈ SVr, s, then it performs the following.

[00443] - He waits until an amount of time has passed.

[00444] - Final Condition 0: The same instructions as for the Fixed Currency stages at 0.

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

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

[00447] He defines vi as the vote of the majority in the second components of all valid that he received.

[00448] It computes bi as follows.

[00449] If more than 2/3 of all the valid ones you received are of the form, then, define

[00450] Otherwise, if more than 2/3 of all the valid ones you received are of the form, then, define

[00451] Otherwise, it defines

[00452] It computes the message destroys your temporary secret key and then propagates

[00453] Stage s, 7 ≤ s ≤ m + 2, s - 2 mod 2 mod 3: One Genuine Launched BBA Stage *

[00454] Instructions for each user i and PKr-k: User i starts his own step s of round r as soon as he is aware of Br-1.

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

[00456] • If so, i interrupts its own execution of step s immediately.

[00457] • If, then, he performs the following.

[00458] - He waits until an amount of time has passed.

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

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

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

[00462] He defines vi as the vote of the majority of the second components of all valid that he received.

[00463] It computes bi as follows.

[00464] If more than 2/3 of all the valid ones you received are of the form, then, define

[00465] Otherwise, if more than 2/3 of all the valid ones you received are of the form, then, define

[00466] Otherwise, it is the set of verifiers (r, s - 1) from whom he received a valid message He defines

[00467] It computes the message destroys your temporary secret key and then propagates

[00468] Stage m + 3: The Last Stage of BBA * 21

[00469] Instructions for each user User i starts his own stage m + 3 of round r as soon as he is aware of Br-1.

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

[00471] • If so, i interrupts its own execution of step m + 3 immediately.

[00472] • If, then, he performs the following.

[00473] - He waits until an amount of time has passed.

21 With enormous probability, BBA * ended before this stage, and this stage is specified for completeness.

[00474] - Final Condition 0: The same instructions as for the Fixed Currency stages at 0.

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

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

[00477] It defines

[00478] It computes the message destroy your temporary secret key and then propagate to certify Br. 22

[00479] Reconstruction of Round Block r by Non-Verifiers

[00480] Instructions for each user i in the system: User i starts his own round r as soon as he is aware of Br-1 and waits for the block information as follows.

[00481] If, during such a wait and at any point in time, there exists a series v and a step s' so that

[00482] (a) mod 3,

[00483] (b) i received at least tH valid messages and

[00484] (c) i received a valid message

[00485] then, i stops its own execution of the round immediately; define and define your own CERTr as 22 A certificate from step m + 3 does not have to include ESIG i (outi). This is included for uniformity only: certificates now have a uniform format, no matter what stage they are generated.

set of messages from substep (b).

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

[00487] (a) mod 3, and

[00488] (b ’) i received at least tH valid messages

[00489] then, i interrupts its own execution of the round immediately; defines and defines its own CERTr as the subset message set (b ').

[00490] - If, during such a wait and at any point in time, i has received at least tH valid messages then i interrupts his own execution of round r immediately, defines and defines his own CERTr as the set of messages for 1 and 6 ALGORAND WITH TEMPORARY KEYS

[00491] Essentially, in Algorand, the blocks are generated in rounds. In a round r

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

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

[00494] The preferred BA protocol is BA *. The proposal stage of the block can be considered stage 1, so that the BA * stages are 2.3, ...

[00495] Only one suitable user i, selected randomly according to the users in the system, has the right to send a message in step s of round r. Algorand is very fast and secure due to the fact that such a user i verifies that he has the right to speak. If this is the case, user i actually obtains a proof, a credential. If it is your turn to speak in step s of round r, i propagates both your credential and digitally signed message on the network. The credential proves to other users that they should consider the message

[00496] A necessary condition for user i to have the right to speak in step s of round r is that he was already in the system a few rounds ago. Specifically, k wheels before round r, where k is a parameter called the “retrospective” parameter. That is, to be eligible to speak in round r, i must belong to PKr-k, the set of all public keys / users already in the system in round r - k. (Users can be identified with their public keys.) This condition is easy to verify in the sense that it is a derivable form of blockchain.

[00497] The other condition is that

[00498] where p is a given probability that controls the expected number of verifiers in SVr, s, that is, the set of users with the right to speak in step s of round r. If this condition is met, then i's credential is defined as being

[00499] Obviously, only i can find out if it belongs to SVr, s, all other users, who are unaware of i's secret signaling key, have no idea of it. However, if i ∈ SVr, s, then i can demonstrate that this is the case for anyone by spreading their credentials given the blockchain so far.

It is recalled the fact that (1) Qr-1 is easily computable from the previous block, Br-1, although sufficiently many blocks essentially unpredictable before, and (2) anyone can verify digital signatures of i (in relation to your long-term key in the system).

[00500] It is also recalled that, in the Algorand versions so far, a verifier i ∈ SVr, s digitally signals your step-s-round-r message in relation to a temporary public key that anyone can, given the blockchain, genuinely realizing that it corresponds to step i of round r. This “temporary signature” is denoted because it is using lowercase letters in order to differentiate it from the signatures of i with its “long term” key, which is denoted by capital letters.

[00501] In short, a user in SVr, s propagates two separate messages in step s of round r: (a) this credential and (b) his step-s-round-r message digitally signed (temporarily), After doing so, i deletes his secret temporary key corresponding to

[00502] This use of temporary keys prevents an opponent who sufficiently corrupts many round checkers r after the Br block has been produced can generate a different round r block.

[00503] It is recalled that, in fact, the verifiers of step 1 are the potential leaders and that their messages of step-1-round-r are the blocks he proposes. (The leader of the round r is defined as the potential leader whose hash verified credential is less. In the case of unlikely ties, you can choose the potential leader who is lexicographically the first.) For any step s> 1, the message it is your “control message”, that is, your message in the BA BA * protocol.

[00504] Separating a verification credential from that message (digitally signed) has two main advantages:

[00505] A1 Ensures that, in the first stage, in which several potential leaders propagate their proposed new blocks, users can quickly identify the leader of the round when he is honest. In fact, all credentials, and in particular the credentials for step 1, are very small, while the proposed blocks can be large. (The actual block proposed by can be identified shortly afterwards.)

[00506] A2 Enables the implementation of lazy honesty. That is, it allows a user i to secretly perceive in anticipation of which rounds and stages they need to act. 7 ALGORAND WITH BLOCKCHAINS ACCREDITED BY

MESSAGE

[00507] A new Algorand modality is described first, which eliminates the use of temporary keys to finally certify a block, but uses temporary keys for all other steps.

[00508] Then, it will be described now how to get rid of temporary keys in Algorand in all stages, but the first stage of block proposal.

[00509] Block Proposal The new modality uses the same step 1 as the previous one. Thus, a potential leader i of round r signals his proposed block in relation to his corresponding temporary key; erases the corresponding secret temporary key; and then propagate your own credential and signature

[00510] Byzantine Agreement In round r, each step s of the BA * protocol remains the same as the previous one. Thus, in particular, a verifier propagates its credential and its own digitally signed step-s-round-r message in relation to its temporary public key r-s and deletes the corresponding secret temporary key. However, the following change is applied to the final condition of the first currency stage set at 1 and all subsequent BBA stages *.

[00511] It is assumed that a user i, in such step s, reached the final condition for the first time. So, this may be the case where

[00512] • for some bit b, i received at least tH valid messages with the same e

[00513] • i received a valid message with

[00514] Consequently, if i is a verifier in SVr, s, then, in previous Algorand modalities, he could interrupt the execution immediately and he could learn the Br block, for which he could be in possession of CERTr. It is recalled that CERTr consisted of a number of temporary digital signatures. Reference is now made to such CERTr as a “temporary certificate” from Br.

[00515] In the new Algorand modality, user i can be an arbitrary user in which k is a retrospective parameter, instead of a checker in SVr, s (which necessarily belongs to Such an arbitrary user now no longer interrupts i ( simulation) its execution of the round A. Instead, using its long-term secret key, it produces a data signature that indicates that it considers block B to be final and that it ensures that the signature has an adequate chance of For example, without any intended limitation, i computes

[00516] where B is the last newly constituted block on the blockchain. If H (si) <p, then i propagates Sj, and is called s as an accredited certification signature. (Here, p is a given parameter in [0, 1].)

[00517] A given limit T of such signatures constitutes a non-temporary certificate for B.

[00518] Now, only non-temporary certificates really matter. Temporary certificates can be considered just a “stepping stone” towards real non-temporary certificates.

[00519] An honest user, who sees a final certificate for a Br block, no longer contributes to the generation or final certification of a block of round r.

[00520] Analysis Although non-temporary certificates consist of long-term signatures, the modality remains secure. Essentially, this is due to the fact that, for proper choices of p and T, the opponent cannot feasibly find any X series for which he can produce T Sj signatures as

[00521] where all j are corrupted users and H (sj) ≤ p.

[00522] (In this application, T could be quite small - for example, around 500. This is due to the fact that it is sufficient that at least one of the T signatures is from an honest user. In fact, T may be much smaller due to the fact that it is sufficient to produce non-temporary certificates very often, but not necessarily for each block.)

[00523] It is also observed that, in the new modality, the adversary cannot flood the network, forcing honest users to propagate “arbitrary accredited certification signatures” computed by corrupted users. In fact, although any malicious J ∈ PKr-k could find some arbitrary series Xj so that by proper use of propagation rules, the signature will never be relayed by an honest user. In fact, a user u will forward a signature not only if (1) and (2), but also if (3) H (B) is the hash of a B block for which u has seen a non-temporary certificate.

[00524] In fact, it would be possible to replace condition 3 above with the weaker one:

[00525] 3 '. H (B) is the hash of a B block for which u has itself seen a sufficiently large subset of a possible temporary certificate.

[00526] In fact, when an honest user i saw a full temporary certificate for B, then (in the absence of partitions), the other honest users must have seen B approved by a large number of verifiers from the appropriate step. This number is really sufficient to identify the only block that has a chance of being certified on a non-temporary basis.

[00527] Elimination of Temporary Keys in Other Steps The above modality requires a minimum number of changes to the original Algorand protocol. It now explains how to avoid temporary keys at each stage, except the first. The idea is that, for each step s> 1, there are no step-s checkers. Instead, for each round r, each user internally performs step s as if it were a verifier on SVr, s, in order to compute their step-s-round-r message internally. At that point, instead of digitally signaling with your temporary key, you check if you have the right to propagate the message as follows.

Firstly, i checks if it was in the k system rounds ago: that is, if this is the case, then i digitally signals with its long-term key, together with the quantity Qr-1; for example, computes and verifies that the signature hash is ≤ p, for a given probability p. If that is the case, then i has the right to propagate and actually propagate. It is observed that given, anyone can verify that i had the right to propagate. In step s + 1, users only consider step-s messages propagated by entitled users.

[00528] An honest user, who has (at least internally) the step executed in round r, does not perform or participate in the execution of that step anymore. 8 SCOPE

[00529] Note that the mechanism described in this document is applicable to other blockchain systems in which it is desirable to randomly choose a subset of users for a particular purpose, such as verification, in a generally verifiable manner. Thus, the system described in this document can be adapted to other blockchain schemes, such as Ethereum or Litecoin, or even blockchain schemes that are not directly related to the currency.

[00530] The system described in this document can be adapted to be applied and combined with mechanisms presented in any or all of the documents in PCT / US2017 / 031037, deposited on May 4, 2017, 15 / 551,678 deposited on 17 August 2017, 62 / 564,670 deposited on September 28, 2017, 62 / 567,864 deposited on October 4, 2017, 62 / 570,256 deposited on October 10, 2017, 62 / 580,757 deposited on November 2, 2017, 62 / 607,558 deposited on December 19, 2017, 62 / 632,944 deposited on February 20, 2018 and 62 / 643,331 deposited on March 15, 2018, all of which are incorporated by reference in this document.

[00531] The software implementations 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 can be non-temporary and include a computer hard drive, ROM, RAM, flash memory, laptop storage media, such as a CD-ROM, a DVD-ROM, a flash drive, an SD card and / or another unit with, for example, a universal serial bus (USB) interface, and / or any other non-temporary or tangible computer-readable computer or media in which executable code can be stored and executed by a processor . The system described in this document can be used in connection with any appropriate operating system.

[00532] 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 examples only, and the scope and true spirit of the invention are indicated by the following claims.

Claims (16)

1. Method for, in a transaction system in which transactions are organized in blocks, an entity to build a new Br block of valid transactions, in relation to a sequence of previous blocks B0, B1,. . . , Br-1, in which the method is characterized by the fact that it comprises: making the entity determine a quantity Q of the previous blocks; make the entity use a secret key to compute an S series exclusively associated with Q and the entity; make the entity compute from S an amount T that is at least one of: S itself, a function of S and a hash value of S; make the entity determine whether T has a given property; and if T has the given property, make the entity digitally sign Br and make available S and a digitally signated version of Br, where the entity is selected based on a random value that varies according to a digital signature of Br. 2. Method, according to claim 1, characterized by the fact that the secret key is a secret signaling key corresponding to an entity's public key and S is a digital signature of Q by the entity. 3. Method, according to claim 1, characterized by the fact that T is a number and satisfies the property if T is less than a given number p. 4. Method, according to claim 2, characterized by the fact that S is made available making S deductible from Br. 5. Method, according to claim 2, characterized by the fact that each user has a balance in the transaction system, and p varies for each user according to each user's balance. 6. Method, according to claim 1, characterized by the fact that the random value is a hash of the entity's digital signature. 7. Method, according to claim 6, characterized by the fact that the entity is selected if the random value is below a limit that is chosen to cause a minimum number of entities in the transaction system to digitally signal Br. 8. Method for selecting a subset of users in a blockchain system to verify a new Br block in relation to a sequence of previous blocks B0, B1,. . . , Br-1, in which the method is characterized by the fact that it comprises: making at least some of the users digitally sign the new Br block together with other information to produce a digital signature; having at least some of the users determine a digital signature hash value; make at least some of the users compare the hash value to a predetermined limit; and make the subset of users available the digital signature to verify the new Br block in response to the hash value being below a predetermined limit for each one of the subset of users. 9. Method, according to claim 8, characterized by the fact that a private user among the users digitally signals the new Br block only if the private user among the users verifies the information provided in the new Br block. 10. Method, according to claim 8, characterized by the fact that the predetermined value is chosen to make the subset of users contain a minimum number of users. 11. Method according to claim 8, characterized by the fact that the blockchain system is used in a transaction system in which transactions are organized in blocks. 12. Method in a blockchain to cause certification of at least a series of data m, in which the method is characterized by the fact that it comprises: making a set S of users verify that m has at least one given property; make users digitally flag m in response to users checking for m; and make users make available digital signatures of m which are accredited signatures of m. 13. Method, according to claim 12, characterized by the fact that the digital signature of m is accredited if the digital signature satisfies a given additional property. 14. Method, according to claim 13, characterized by the fact that the digital signature of m satisfies the given additional property if a hash of the digital signature is less than a given target number. 15. Method, according to claim 12, characterized by the fact that the data series m is certified by at least a given number of accredited signatures of m. 16. 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 15.