Algorand: Ampliando Acordos Bizantinos para Criptomoedas

Algorand: Scaling Byzantine Agreements for Cryptocurrencies

โดย Jing Chen and Silvio Micali · 2017

โหมดเดี่ยว arxiv.org

Abstract

Abstract

A public ledger is a tamperproof sequence of data that can be read and augmented by everyone. Public ledgers have innumerable and compelling uses. They can secure, in plain sight, all kinds of transactions —such as titles, sales, and payments— in the exact order in which they occur. Public ledgers not only curb corruption, but also enable very sophisticated applications —such as cryptocurrencies and smart contracts. They stand to revolutionize the way a democratic society operates. As currently implemented, however, they scale poorly and cannot achieve their potential. Algorand is a truly democratic and efficient way to implement a public ledger. Unlike prior implementations based on proof of work, it requires a negligible amount of computation, and generates a transaction history that will not "fork" with overwhelmingly high probability. Algorand is based on (a novel and super fast) message-passing Byzantine agreement. For concreteness, we shall describe Algorand only as a money platform.

Resumo

Um livro-razão público é uma sequência de dados inviolável que pode ser lida e aumentada por qualquer pessoa. Os livros-razão públicos têm usos inúmeros e atraentes. Eles podem proteger, à vista de todos, todos os tipos de transações —como títulos, vendas e pagamentos— na ordem exata em que ocorrem. Os livros-razão públicos não apenas reduzem a corrupção, mas também permitem aplicações muito sofisticadas — como criptomoedas e smart contracts. Eles irão revolucionar a forma como uma sociedade democrática opera. No entanto, tal como estão actualmente implementados, eles têm uma fraca escalabilidade e não conseguem atingir o seu potencial. Algorand é uma forma verdadeiramente democrática e eficiente de implementar um livro-razão público. Ao contrário do anterior implementações baseadas em prova de trabalho, requer uma quantidade insignificante de computação e gera um histórico de transações que não será “fork” com probabilidade extremamente alta. Algorand é baseado em um acordo bizantino de transmissão de mensagens (novo e super rápido). Para ser mais concreto, descreveremos Algorand apenas como uma plataforma monetária.

Introduction

Introduction

Money is becoming increasingly virtual. It has been estimated that about 80% of United States dollars today only exist as ledger entries [5]. Other financial instruments are following suit. In an ideal world, in which we could count on a universally trusted central entity, immune to all possible cyber attacks, money and other financial transactions could be solely electronic. Unfortunately, we do not live in such a world. Accordingly, decentralized cryptocurrencies, such as Bitcoin [29], and "smart contract" systems, such as Ethereum, have been proposed [4]. At the heart of these systems is a shared ledger that reliably records a sequence of transactions, ∗This is the more formal (and asynchronous) version of the ArXiv paper by the second author [24], a paper itself based on that of Gorbunov and Micali [18]. Algorand's technologies are the object of the following patent applications: US62/117,138 US62/120,916 US62/142,318 US62/218,817 US62/314,601 PCT/US2016/018300 US62/326,865 62/331,654 US62/333,340 US62/343,369 US62/344,667 US62/346,775 US62/351,011 US62/653,482 US62/352,195 US62/363,970 US62/369,447 US62/378,753 US62/383,299 US62/394,091 US62/400,361 US62/403,403 US62/410,721 US62/416,959 US62/422,883 US62/455,444 US62/458,746 US62/459,652 US62/460,928 US62/465,931

as varied as payments and contracts, in a tamperproof way. The technology of choice to guarantee such tamperproofness is the blockchain. Blockchains are behind applications such as cryptocurrencies [29], financial applications [4], and the Internet of Things [3]. Several techniques to manage blockchain-based ledgers have been proposed: proof of work [29], proof of stake [2], practical Byzantine fault-tolerance [8], or some combination. Currently, however, ledgers can be inefficient to manage. For example, Bitcoin's proof-of-work approach (based on the original concept of [14]) requires a vast amount of computation, is wasteful and scales poorly [1]. In addition, it de facto concentrates power in very few hands. We therefore wish to put forward a new method to implement a public ledger that offers the convenience and efficiency of a centralized system run by a trusted and inviolable authority, without the inefficiencies and weaknesses of current decentralized implementations. We call our approach Algorand, because we use algorithmic randomness to select, based on the ledger constructed so far, a set of verifiers who are in charge of constructing the next block of valid transactions. Naturally, we ensure that such selections are provably immune from manipulations and unpredictable until the last minute, but also that they ultimately are universally clear. Algorand's approach is quite democratic, in the sense that neither in principle nor de facto it creates different classes of users (as "miners" and "ordinary users" in Bitcoin). In Algorand "all power resides with the set of all users". One notable property of Algorand is that its transaction history may fork only with very small probability (e.g., one in a trillion, that is, or even \(10^{-18}\)). Algorand can also address some legal and political concerns. The Algorand approach applies to blockchains and, more generally, to any method of generating a tamperproof sequence of blocks. We actually put forward a new method —alternative to, and more efficient than, blockchains— that may be of independent interest. 1.1 Bitcoin's Assumption and Technical Problems Bitcoin is a very ingenious system and has inspired a great amount of subsequent research. Yet, it is also problematic. Let us summarize its underlying assumption and technical problems —which are actually shared by essentially all cryptocurrencies that, like Bitcoin, are based on proof-of-work. For this summary, it suffices to recall that, in Bitcoin, a user may own 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 processed payments in a chain of blocks, \(B_1, B_2, \ldots\), each consisting of multiple payments, such that, all payments of \(B_1\), taken in any order, followed by those of \(B_2\), in any order, etc., constitute a sequence of valid payments. Each block is generated, on average, every 10 minutes. This sequence of blocks is a chain, because it is structured so as to ensure that any change, even in a single block, percolates into all subsequent blocks, making it easier to spot any alteration of the payment history. (As we shall see, this is achieved by including in each block a cryptographic hash of the previous one.) Such block structure is referred to as a blockchain. Assumption: Honest Majority of Computational Power Bitcoin assumes that no malicious entity (nor a coalition of coordinated malicious entities) controls the majority of the computational power devoted to block generation. Such an entity, in fact, would be able to modify the blockchain,

and thus re-write the payment history, as it pleases. In particular, it could make a payment \(\wp\), obtain the benefits paid for, and then "erase" any trace of \(\wp\). Technical Problem 1: Computational Waste Bitcoin's proof-of-work approach to block generation requires an extraordinary amount of computation. Currently, with just a few hundred thousands public keys in the system, the top 500 most powerful supercomputers can only muster a mere 12.8% percent of the total computational power required from the Bitcoin players. This amount of computation would greatly increase, should significantly more users join the system. Technical Problem 2: Concentration of Power Today, due to the exorbitant amount of computation required, a user, trying to generate a new block using an ordinary desktop (let alone a cell phone), expects to lose money. Indeed, for computing a new block with an ordinary computer, the expected cost of the necessary electricity to power the computation exceeds the expected reward. Only using pools of specially built computers (that do nothing other than "mine new blocks"), one might expect to make a profit by generating new blocks. Accordingly, today there are, de facto, two disjoint classes of users: ordinary users, who only make payments, and specialized mining pools, that only search for new blocks. It should therefore not be a surprise that, as of recently, the total computing power for block generation lies within just five pools. In such conditions, the assumption that a majority of the computational power is honest becomes less credible. Technical Problem 3: Ambiguity In Bitcoin, the blockchain is not necessarily unique. Indeed its latest portion often forks: the blockchain may be —say— \(B_1, \ldots, B_k, B'_{k+1}, B'_{k+2}\), according to one user, and \(B_1, \ldots, B_k, B''_{k+1}, B''_{k+2}, B''_{k+3}\) according another user. Only after several blocks have been added to the chain, can one be reasonably sure that the first \(k + 3\) blocks will be the same for all users. Thus, one cannot rely right away on the payments contained in the last block of the chain. It is more prudent to wait and see whether the block becomes sufficiently deep in the blockchain and thus sufficiently stable. Separately, law-enforcement and monetary-policy concerns have also been raised about Bitcoin.1 1.2 Algorand, in a Nutshell Setting Algorand works in a very tough setting. Briefly, (a) Permissionless and Permissioned Environments. Algorand works efficiently and securely even in a totally permissionless environment, where arbitrarily many users are allowed to join the system at any time, without any vetting or permission of any kind. Of course, Algorand works even better in a permissioned environment. 1The (pseudo) anonymity offered by Bitcoin payments may be misused for money laundering and/or the financing of criminal individuals or terrorist organizations. Traditional banknotes or gold bars, that in principle offer perfect anonymity, should pose the same challenge, but the physicality of these currencies substantially slows down money transfers, so as to permit some degree of monitoring by law-enforcement agencies. The ability to "print money" is one of the very basic powers of a nation state. In principle, therefore, the massive adoption of an independently floating currency may curtail this power. Currently, however, Bitcoin is far from being a threat to governmental monetary policies, and, due to its scalability problems, may never be.

(b) Very Adversarial Environments. Algorand withstands a very powerful Adversary, who can (1) instantaneously corrupt any user he wants, at any time he wants, provided that, in a permissionless environment, 2/3 of the money in the system belongs to honest user. (In a permissioned environment, irrespective of money, it suffices that 2/3 of the users are honest.) (2) totally control and perfectly coordinate all corrupted users; and (3) schedule the delivery of all messages, provided that each message \(m\) sent by a honest user reaches 95% of the honest users within a time \(\lambda_m\), which solely depends on the size of \(m\). Main Properties Despite the presence of our powerful adversary, in Algorand • The amount of computation required is minimal. Essentially, no matter how many users are present in the system, each of fifteen hundred users must perform at most a few seconds of computation. • A New Block is Generated in less than 10 minutes, and will de facto never leave the blockchain. For instance, in expectation, the time to generate a block in the first embodiment is less than \(\Lambda + 12.4\lambda\), where \(\Lambda\) is the time necessary to propagate a block, in a peer-to-peer gossip fashion, no matter what block size one may choose, and \(\lambda\) is the time to propagate 1,500 200B-long messages. (Since in a truly decentralized system, \(\Lambda\) essentially is an intrinsic latency, in Algorand the limiting factor in block generation is network speed.) The second embodiment has actually been tested experimentally ( by ?), indicating that a block is generated in less than 40 seconds. In addition, Algorand's blockchain may fork only with negligible probability (i.e., less than one in a trillion), and thus users can relay on the payments contained in a new block as soon as the block appears. • All power resides with the users themselves. Algorand is a truy distributed system. In particular, there are no exogenous entities (as the "miners" in Bitcoin), who can control which transactions are recognized. Algorand's Techniques. 1. A New and Fast Byzantine Agreement Protocol. Algorand generates a new block via a new cryptographic, message-passing, binary Byzantine agreement (BA) protocol, BA⋆. Protocol BA⋆not only satisfies some additional properties (that we shall soon discuss), but is also very fast. Roughly said, its binary-input version consists of a 3-step loop, in which a player \(i\) sends a single message \(m_i\) to all other players. Executed in a complete and synchronous network, with more than 2/3 of the players being honest, with probability > 1/3, after each loop the protocol ends in agreement. (We stress that protocol BA⋆satisfies the original definition of Byzantine agreement of Pease, Shostak, and Lamport [31], without any weakenings.) Algorand leverages this binary BA protocol to reach agreement, in our different communication model, on each new block. The agreed upon block is then certified, via a prescribed number of digital signature of the proper verifiers, and propagated through the network. 2. Cryptographic Sortition. Although very fast, protocol BA⋆would benefit from further speed when played by millions of users. Accordingly, Algorand chooses the players of BA⋆to be

a much smaller subset of the set of all users. To avoid a different kind of concentration-of-power problem, each new block \(B^r\) will be constructed and agreed upon, via a new execution of BA⋆, by a separate set of selected verifiers, \(SV^r\). In principle, selecting such a set might be as hard as selecting \(B^r\) directly. We traverse this potential problem by an approach that we term, embracing the insightful suggestion of Maurice Herlihy, cryptographic sortition. Sortition is the practice of selecting officials at random from a large set of eligible individuals [6]. (Sortition was practiced across centuries: for instance, by the republics of Athens, Florence, and Venice. In modern judicial systems, random selection is often used to choose juries. Random sampling has also been recently advocated for elections by David Chaum [9].) In a decentralized system, of course, choosing the random coins necessary to randomly select the members of each verifier set \(SV^r\) is problematic. We thus resort to cryptography in order to select each verifier set, from the population of all users, in a way that is guaranteed to be automatic (i.e., requiring no message exchange) and random. In essence, we use a cryptographic function to automatically determine, from the previous block \(B^{r-1}\), a user, the leader, in charge of proposing the new block \(B^r\), and the verifier set \(SV^r\), in charge to reach agreement on the block proposed by the leader. Since malicious users can affect the composition of \(B^{r-1}\) (e.g., by choosing some of its payments), we specially construct and use additional inputs so as to prove that the leader for the \(r\)th block and the verifier set \(SV^r\) are indeed randomly chosen. 3. The Quantity (Seed) \(Q^r\). We use the the last block \(B^{r-1}\) in the blockchain in order to automatically determine the next verifier set and leader in charge of constructing the new block \(B^r\). The challenge with this approach is that, by just choosing a slightly different payment in the previous round, our powerful Adversary gains a tremendous control over the next leader. Even if he only controlled only 1/1000 of the players/money in the system, he could ensure that all leaders are malicious. (See the Intuition Section 4.1.) This challenge is central to all proof-of-stake approaches, and, to the best of our knowledge, it has not, up to now, been satisfactorily solved. To meet this challenge, we purposely construct, and continually update, a separate and carefully defined quantity, \(Q^r\), which provably is, not only unpredictable, but also not influentiable, by our powerful Adversary. We may refer to \(Q^r\) as the \(r\)th seed, as it is from \(Q^r\) that Algorand selects, via secret cryptographic sortition, all the users that will play a special role in the generation of the \(r\)th block. 4. Secret Crytographic Sortition and Secret Credentials. Randomly and unambiguously using the current last block, \(B^{r-1}\), in order to choose the verifier set and the leader in charge of constructing the new block, \(B^r\), is not enough. Since \(B^{r-1}\) must be known before generating \(B^r\), the last non-influentiable quantity \(Q^{r-1}\) contained in \(B^{r-1}\) must be known too. Accordingly, so are the verifiers and the leader in charge to compute the block \(B^r\). Thus, our powerful Adversary might immediately corrupt all of them, before they engage in any discussion about \(B^r\), so as to get full control over the block they certify. To prevent this problem, leaders (and actually verifiers too) secretly learn of their role, but can compute a proper credential, capable of proving to everyone that indeed have that role. When a user privately realizes that he is the leader for the next block, first he secretly assembles his own proposed new block, and then disseminates it (so that can be certified) together with his own credential. This way, though the Adversary will immediately realize who the leader of the next block is, and although he can corrupt him right away, it will be too late for the Adversary to influence the choice of a new block. Indeed, he cannot "call back" the leader's message no more

than a powerful government can put back into the bottle a message virally spread by WikiLeaks. As we shall see, we cannot guarantee leader uniqueness, nor that everyone is sure who the leader is, including the leader himself! But, in Algorand, unambiguous progress will be guaranteed. 5. Player Replaceability. After he proposes a new block, the leader might as well "die" (or be corrupted by the Adversary), because his job is done. But, for the verifiers in \(SV^r\), things are less simple. Indeed, being in charge of certifying the new block \(B^r\) with sufficiently many signatures, they must first run Byzantine agreement on 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, because, for efficiency reasons, the player set of BA⋆consists the small set \(SV^r\) randomly selected among the set of all users. Thus, our powerful Adversary, although unable to corrupt 1/3 of all the users, can certainly corrupt all members of \(SV^r\)! Fortunately we'll prove that protocol BA⋆, executed by propagating messages in a peer-topeer fashion, is player-replaceable. This novel requirement means that the protocol correctly and efficiently reaches consensus even if each of its step is executed by a totally new, and randomly and independently selected, set of players. Thus, with millions of users, each small set of players associated to a step of BA⋆most probably has empty intersection with the next set. In addition, the sets of players of different steps of BA⋆will probably have totally different cardinalities. Furthermore, the members of each set do not know who the next set of players will be, and do not secretly pass any internal state. The replaceable-player property is actually crucial to defeat the dynamic and very powerful Adversary we envisage. We believe that replaceable-player protocols will prove crucial in lots of contexts and applications. In particular, they will be crucial to execute securely small sub-protocols embedded in a larger universe of players with a dynamic adversary, who, being able to corrupt even a small fraction of the total players, has no difficulty in corrupting all the players in the smaller sub-protocol. An Additional Property/Technique: Lazy Honesty A honest user follows his prescribed instructions, which include being online and run the protocol. Since, Algorand has only modest computation and communication requirement, being online and running the protocol "in the background" is not a major sacrifice. Of course, a few "absences" among honest players, as those due to sudden loss of connectivity or the need of rebooting, are automatically tolerated (because we can always consider such few players to be temporarily malicious). Let us point out, however, that Algorand can be simply adapted so as to work in a new model, in which honest users to be offline most of the time. Our new model can be informally introduced as follows. Lazy Honesty. Roughly speaking, a user \(i\) is lazy-but-honest if (1) he follows all his prescribed instructions, when he is asked to participate to the protocol, and (2) he is asked to participate to the protocol only rarely, and with a suitable advance notice. With such a relaxed notion of honesty, we may be even more confident that honest people will be at hand when we need them, and Algorand guarantee that, when this is the case, The system operates securely even if, at a given point in time, the majority of the participating players are malicious.

1.3 Closely Related work Proof-of-work approaches (like the cited [29] and [4]) are quite orthogonal to our ours. So are the approaches based on message-passing Byzantine agreement or practical Byzantine fault tolerance (like the cited [8]). Indeed, these protocols cannot be run among the set of all users and cannot, in our model, be restricted to a suitably small set of users. In fact, our powerful adversary my immediately corrupt all the users involved in a small set charged to actually running a BA protocol. Our approach could be considered related to proof of stake [2], in the sense that users' "power" in block building is proportional to the money they own in the system (as opposed to —say— to the money they have put in "escrow"). The paper closest to ours is the Sleepy Consensus Model of Pass and Shi [30]. To avoid the heavy computation required in the proof-of-work approach, their paper relies upon (and kindly credits) Algorand's secret cryptographic sortition. With this crucial aspect in common, several significant differences exist between our papers. In particular, (1) Their setting is only permissioned. By contrast, Algorand is also a permissionless system. (2) They use a Nakamoto-style protocol, and thus their blockchain forks frequently. Although dispensing with proof-of-work, in their protocol a secretly selected leader is asked to elongate the longest valid (in a richer sense) blockchain. Thus, forks are unavoidable and one has to wait that the block is sufficiently "deep" in the chain. Indeed, to achieve their goals with an adversary capable of adaptive corruptions, they require a block to be \(\text{poly}(N)\) deep, where \(N\) represents the total number of users in the system. Notice that, even assuming that a block could be produced in a minute, if there were \(N = 1M\) users, then one would have to wait for about 2M years for a block to become \(N^2\)-deep, and for about 2 years for a block to become \(N\)-deep. By contrast, Algorand's blockchain forks only with negligible probability, even though the Adversary corrupt users immediately and adaptively, and its new blocks can immediately be relied upon. (3) They do not handle individual Byzantine agreements. In a sense, they only guarantee "eventual consensus on a growing sequence of values". Theirs is a state replication protocol, rather than a BA one, and cannot be used to reach Byzantine agreement on an individual value of interest. By contrast, Algorand can also be used only once, if so wanted, to enable millions of users to quickly reach Byzantine agreement on a specific value of interest. (4) They require weakly synchronized clocks. That is, all users' clocks are offset by a small time \(\delta\). By contrast, in Algorand, clocks need only have (essentially) the same "speed". (5) Their protocol works with lazy-but-honest users or with honest majority of online users. They kindly credit Algorand for raising the issue of honest users going offline en masse, and for putting forward the lazy honesty model in response. Their protocol not only works in the lazy honesty model, but also in their adversarial sleepy model, where an adversary chooses which users are online and which are offline, provided that, at all times, the majority of online users are honest.2 2The original version of their paper actually considered only security in their adversarial sleepy model. The original version of Algorand, which precedes theirs, also explicitly envisaged assuming that a given majority of the online players is always honest, but explicitly excluded it from consideration, in favor of the lazy honesty model. (For instance, if at some point in time half of the honest users choose to go off-line, then the majority of the users on-line may very well be malicious. Thus, to prevent this from happening, the Adversary should force most of his corrupted players to go off-line too, which clearly is against his own interest.) Notice that a protocol with a majority of lazy-but-honest players works just fine if the majority of the users on-line are always malicious. This is so, because a sufficient number of honest players, knowing that they are going to be crucial at some rare point in time, will elect not to go off-line in those moments, nor can they be forced off-line by the Adversary, since he does not know who the crucial honest players might be.

(6) They require a simple honest majority. By contrast, the current version of Algorand requires a 2/3 honest majority. Another paper close to us is Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol, by Kiayias, Russell, David, and Oliynykov [20]. Also their system appeared after ours. It also uses crytpographic sortition to dispense with proof of work in a provable manner. However, their system is, again, a Nakamoto-style protocol, in which forks are both unavoidable and frequent. (However, in their model, blocks need not as deep as the sleepy-consensus model.) Moreover, their system relies on the following assumptions: in the words of the authors themselves, "(1) the network is highly synchronous, (2) the majority of the selected stakeholders is available as needed to participate in each epoch, (3) the stakeholders do not remain offline for long periods of time, (4) the adaptivity of corruptions is subject to a small delay that is measured in rounds linear in the security parameter." By contrast, Algorand is, with overwhelming probability, fork-free, and does not rely on any of these 4 assumptions. In particular, in Algorand, the Adversary is able to instantaneously corrupt the users he wants to control.

Introdução

O dinheiro está se tornando cada vez mais virtual. Estima-se que cerca de 80% dos Estados Unidos dólares hoje existem apenas como entradas contábeis [5]. Outros instrumentos financeiros estão a seguir o exemplo. Num mundo ideal, em que pudéssemos contar com uma entidade central de confiança universal, imunes a todos os ataques cibernéticos possíveis, o dinheiro e outras transações financeiras poderiam ser exclusivamente eletrónicas. Infelizmente, não vivemos num mundo assim. Conseqüentemente, criptomoedas descentralizadas, como como Bitcoin [29], e sistemas “smart contract”, como Ethereum, foram propostos [4]. Em o coração desses sistemas é um livro-razão compartilhado que registra de forma confiável uma sequência de transações, ∗Esta é a versão mais formal (e assíncrona) do artigo ArXiv do segundo autor [24], um artigo em si baseado no de Gorbunov e Micali [18]. As tecnologias de Algorand são objeto do seguinte pedidos de patente: US62/117.138 US62/120.916 US62/142.318 US62/218.817 US62/314.601 PCT/US2016/018300 US62/326.865 62/331.654 US62/333.340 US62/343.369 US62/344.667 US62/346.775 US62/351.011 US62/653.482 US62/352.195 US62/363.970 US62/369.447 US62/378.753 US62/383.299 US62/394.091 US62/400.361 US62/403.403 US62/410.721 US62/416.959 US62/422.883 US62/455.444 US62/458.746 US62/459.652 US62/460.928 US62/465.931tão variados quanto pagamentos e contratos, de forma inviolável. A tecnologia escolhida para garantir tal inviolabilidade é o blockchain. Blockchains estão por trás de aplicativos como criptomoedas [29], aplicações financeiras [4] e Internet das Coisas [3]. Várias técnicas para gerenciar livros contábeis baseados em blockchain foram propostos: prova de trabalho [29], prova de aposta [2], tolerância prática a falhas bizantinas [8], ou alguma combinação. Atualmente, no entanto, os livros contábeis podem ser ineficientes de gerenciar. Por exemplo, Bitcoin de proof-of-work abordagem (baseada no conceito original de [14]) requer uma grande quantidade de computação, é um desperdício e escala mal [1]. Além disso, concentra de facto o poder em muito poucas mãos. Desejamos, portanto, propor um novo método para implementar um livro público que ofereça a conveniência e eficiência de um sistema centralizado administrado por uma autoridade confiável e inviolável, sem as ineficiências e fraquezas das atuais implementações descentralizadas. Chamamos nossa abordagem Algorand, porque usamos aleatoriedade algorítmica para selecionar, com base no livro-razão construído até agora, um conjunto de verificadores encarregados de construir o próximo bloco de transações válidas. Naturalmente, garantimos que tais seleções sejam comprovadamente imunes a manipulações e imprevisíveis até no último minuto, mas também que, em última análise, sejam universalmente claros. A abordagem de Algorand é bastante democrática, no sentido de que nem em princípio nem de facto cria diferentes classes de usuários (como “mineradores” e “usuários comuns” em Bitcoin). Em Algorand “todos o poder reside no conjunto de todos os usuários”. Uma propriedade notável de Algorand é que seu histórico de transações pode bifurcar-se apenas com valores muito pequenos probabilidade (por exemplo, um em um trilhão, isto é, ou mesmo 10-18). Algorand também pode abordar algumas questões legais e preocupações políticas. A abordagem Algorand aplica-se a blockchains e, mais geralmente, a qualquer método de geração uma sequência de blocos inviolável. Na verdade, propusemos um novo método - alternativo e mais eficiente do que blockchains— que pode ser de interesse independente. 1.1 Suposição e problemas técnicos de Bitcoin Bitcoin é um sistema muito engenhoso e inspirou muitas pesquisas subsequentes. Ainda assim, também é problemático. Vamos resumir a sua suposição subjacente e os problemas técnicos - que na verdade, são compartilhados por essencialmente todas as criptomoedas que, como Bitcoin, são baseadas em proof-of-work. Para este resumo, basta lembrar que, em Bitcoin, um usuário pode possuir múltiplas chaves públicas de um esquema de assinatura digital, que o dinheiro está associado a chaves públicas e que um pagamento é um assinatura digital que transfere alguma quantia de dinheiro de uma chave pública para outra. Essencialmente, Bitcoin organiza todos os pagamentos processados em uma cadeia de blocos, B1, B2, . . ., cada um consistindo de múltiplos pagamentos, de modo que todos os pagamentos de B1, efetuados em qualquer ordem, seguidos pelos de B2, em qualquer ordem, etc., constituem uma sequência de pagamentos válidos. Cada bloco é gerado, em média, a cada 10 minutos. Esta sequência de blocos é uma cadeia, pois está estruturada de forma a garantir que qualquer alteração, mesmo em um único bloco, se infiltra em todos os blocos subsequentes, facilitando a detecção de qualquer alteração de o histórico de pagamentos. (Como veremos, isto é conseguido incluindo em cada bloco um código criptográfico hash do anterior.) Essa estrutura de bloco é referida como blockchain. Suposição: Maioria Honesta do Poder Computacional Bitcoin assume que nenhum mal-intencionado entidade (nem uma coalizão de entidades maliciosas coordenadas) controla a maioria dos recursos computacionais poder dedicado à geração de blocos. Tal entidade, de fato, seria capaz de modificar o blockchain,e assim reescrever o histórico de pagamentos, como desejar. Em particular, poderia fazer um pagamento \(\wp\), obter os benefícios pagos e então “apagar” qualquer vestígio de \(\wp\). Problema Técnico 1: Resíduos Computacionais Abordagem de Bitcoin proof-of-work para bloquear a geração requer uma quantidade extraordinária de computação. Atualmente, com apenas algumas centenas milhares de chaves públicas no sistema, os 500 supercomputadores mais poderosos só conseguem reunir apenas 12,8% do poder computacional total exigido dos jogadores Bitcoin. Isto a quantidade de computação aumentaria muito, caso um número significativamente maior de usuários ingressasse no sistema. Problema Técnico 2: Concentração de Poder Hoje, devido à quantidade exorbitante de cálculo necessário, um usuário, tentando gerar um novo bloco usando um desktop comum (sem falar em um celular), espera perder dinheiro. Na verdade, para calcular um novo bloco com um computador comum, o custo esperado da eletricidade necessária para alimentar o cálculo excede a recompensa esperada. Somente usando pools de computadores especialmente construídos (que não fazem nada além de “minerar novos blocos”), pode-se pode esperar obter lucro gerando novos blocos. Assim, hoje existem, de facto, dois classes distintas de usuários: usuários comuns, que apenas fazem pagamentos, e pools de mineração especializados, que apenas procuram novos blocos. Portanto, não deveria ser surpresa que, recentemente, o poder computacional total para blocos geração está dentro de apenas cinco grupos. Nessas condições, a suposição de que a maioria dos o poder computacional é honesto torna-se menos credível. Problema Técnico 3: Ambiguidade Em Bitcoin, blockchain não é necessariamente único. Na verdade sua última parte frequentemente se bifurca: o blockchain pode ser —digamos— B1, . . . , Bk, B' k+1, B′ k+2, de acordo com um usuário e B1, . . . , Bk, B'' k+1, B'' k+2, B'' k+3 de acordo com outro usuário. Somente depois de vários blocos terem sido adicionado à cadeia, podemos ter certeza razoável de que os primeiros k + 3 blocos serão os mesmos para todos os usuários. Assim, não se pode confiar desde já nos pagamentos contidos no último bloco de a corrente. É mais prudente esperar e ver se o bloco se torna suficientemente profundo no blockchain e, portanto, suficientemente estável. Separadamente, também foram levantadas preocupações de aplicação da lei e de política monetária sobre Bitcoin.1 1.2 Algorand, em poucas palavras Configuração Algorand funciona em ambientes muito difíceis. Resumidamente, (a) Ambientes sem permissão e com permissão. Algorand funciona de forma eficiente e segura, mesmo em um ambiente totalmente sem permissão, onde muitos usuários podem ingressar arbitrariamente no sistema a qualquer momento, sem qualquer verificação ou permissão de qualquer tipo. Claro, Algorand funciona ainda melhor em um ambiente permitido. 1O (pseudo) anonimato oferecido pelos pagamentos Bitcoin pode ser utilizado indevidamente para lavagem de dinheiro e/ou financiamento de indivíduos criminosos ou organizações terroristas. Notas tradicionais ou barras de ouro, que em princípio oferecem perfeita anonimato, deveriam representar o mesmo desafio, mas a fisicalidade destas moedas desacelera substancialmente o fluxo de dinheiro transferências, de modo a permitir algum grau de monitorização por parte das agências de aplicação da lei. A capacidade de “imprimir dinheiro” é um dos poderes básicos de um Estado-nação. Em princípio, portanto, a enorme a adopção de uma moeda flutuante independente pode restringir este poder. Atualmente, porém, Bitcoin está longe de ser uma ameaça às políticas monetárias governamentais e, devido aos seus problemas de escalabilidade, poderá nunca o ser.(b) Ambientes muito adversários. Algorand resiste a um Adversário muito poderoso, que pode (1) corromper instantaneamente qualquer usuário que desejar, a qualquer momento que desejar, desde que, de forma ambiente sem permissão, 2/3 do dinheiro do sistema pertence ao usuário honesto. (Em um ambiente permitido, independentemente do dinheiro, basta que 2/3 dos usuários sejam honestos.) (2) controlar totalmente e coordenar perfeitamente todos os usuários corrompidos; e (3) programar a entrega de todas as mensagens, desde que cada mensagem seja enviada por um usuário honesto atinge 95% dos usuários honestos dentro de um tempo \(\lambda\)m, que depende apenas do tamanho de m. Propriedades Principais Apesar da presença do nosso poderoso adversário, em Algorand • A quantidade de cálculo necessária é mínima. Essencialmente, não importa quantos usuários estejam presente no sistema, cada um dos mil e quinhentos usuários deve realizar no máximo alguns segundos de computação. • Um novo bloco é gerado em menos de 10 minutos e, de fato, nunca sairá do blockchain. Por exemplo, na expectativa, o tempo para gerar um bloco na primeira modalidade é menor do que Λ + 12,4\(\lambda\), onde Λ é o tempo necessário para propagar um bloco, em uma fofoca ponto a ponto moda, não importa o tamanho do bloco escolhido, e \(\lambda\) é o tempo para propagar 1.500 mensagens de 200Blong. (Uma vez que num sistema verdadeiramente descentralizado, Λ é essencialmente uma latência intrínseca, em Algorand o fator limitante na geração de blocos é a velocidade da rede.) A segunda modalidade tem na verdade foi testado experimentalmente ( por ?), indicando que um bloco é gerado em menos de 40 segundos. Além disso, blockchain de Algorand pode bifurcar apenas com probabilidade insignificante (ou seja, menos de um em um trilhão), e assim os usuários podem contar com os pagamentos contidos em um novo bloco assim que o bloco aparece. • Todo o poder reside nos próprios usuários. Algorand é um sistema verdadeiramente distribuído. Em particular, não existem entidades exógenas (como os “mineradores” em Bitcoin), que podem controlar quais transações são reconhecidos. Técnicas de Algorand. 1. Um novo e rápido protocolo de acordo bizantino. Algorand gera um novo bloco via um novo protocolo de acordo bizantino (BA) binário, criptográfico e de passagem de mensagens, BA⋆. Protocolo BA⋆não apenas satisfaz algumas propriedades adicionais (que discutiremos em breve), mas também é muito rápido. Grosso modo, sua versão de entrada binária consiste em um loop de 3 etapas, no qual um jogador i envia um único mensagem mi para todos os outros jogadores. Executado em rede completa e síncrona, com mais mais de 2/3 dos jogadores sendo honestos, com probabilidade > 1/3, após cada loop o protocolo termina em acordo. (Enfatizamos que o protocolo BA⋆ satisfaz a definição original do acordo bizantino de Pease, Shostak e Lamport [31], sem quaisquer enfraquecimentos.) Algorand aproveita este protocolo BA binário para chegar a um acordo, em nossas diferentes comunicações modelo, em cada novo bloco. O bloco acordado é então certificado, através de um número prescrito de assinatura digital dos verificadores apropriados e propagada pela rede. 2. Classificação criptográfica. Embora muito rápido, o protocolo BA⋆ se beneficiaria com mais velocidade quando jogado por milhões de usuários. Assim, Algorand escolhe os jogadores da BA⋆para seremum subconjunto muito menor do conjunto de todos os usuários. Para evitar um tipo diferente de concentração de poder problema, cada novo bloco Br será construído e acordado, através de uma nova execução de BA⋆, por um conjunto separado de verificadores selecionados, SV r. Em princípio, selecionar tal conjunto pode ser tão difícil quanto selecionando Br diretamente. Atravessamos este problema potencial através de uma abordagem que denominamos, abrangendo a sugestão perspicaz de Maurice Herlihy, classificação criptográfica. Sortição é a prática de selecionar funcionários aleatoriamente de um grande conjunto de indivíduos elegíveis [6]. (A classificação foi praticada ao longo dos séculos: por exemplo, pelas repúblicas de Atenas, Florença e Veneza. No sistema judicial moderno sistemas, a seleção aleatória é frequentemente usada para escolher os júris. A amostragem aleatória também foi recentemente defendido para as eleições por David Chaum [9].) Num sistema descentralizado, é claro, escolher o moedas aleatórias necessárias para selecionar aleatoriamente os membros de cada conjunto de verificadores SV r é problemático. Recorremos assim à criptografia para selecionar cada conjunto de verificadores, da população de todos os usuários, de uma forma garantidamente automática (ou seja, sem necessidade de troca de mensagens) e aleatória. Em essência, usamos uma função criptográfica para determinar automaticamente, a partir do bloco anterior Br−1, um usuário, o líder, encarregado de propor o novo bloco Br, e o conjunto verificador SV r, em cobrar para chegar a um acordo sobre o bloco proposto pelo líder. Como usuários mal-intencionados podem afetar composição de Br−1 (por exemplo, escolhendo alguns de seus pagamentos), construímos e usamos especialmente entradas adicionais para provar que o líder do r-ésimo bloco e o conjunto verificador SV r são de fato escolhido aleatoriamente. 3. A Quantidade (Semente) Qr. Usamos o último bloco Br−1 em blockchain para determinar automaticamente o próximo conjunto de verificadores e líder responsável pela construção do novo bloco Ir. O desafio desta abordagem é que, ao escolher apenas um pagamento ligeiramente diferente no rodada anterior, nosso poderoso Adversário ganha um tremendo controle sobre o próximo líder. Mesmo que ele controlava apenas 1/1000 dos jogadores/dinheiro no sistema, ele poderia garantir que todos os líderes fossem malicioso. (Veja a Seção Intuição 4.1.) Este desafio é central para todas as abordagens proof-of-stake, e, tanto quanto sabemos, não foi, até agora, resolvido de forma satisfatória. Para enfrentar esse desafio, construímos propositalmente e atualizamos continuamente um relatório separado e cuidadosamente quantidade definida, Qr, que provavelmente é, não apenas imprevisível, mas também não influenciável, pelos nossos adversário poderoso. Podemos nos referir a Qr como a r-ésima semente, pois é de Qr que Algorand seleciona, através de triagem criptográfica secreta, todos os usuários que desempenharão um papel especial na geração do quarto bloco. 4. Classificação criptográfica secreta e credenciais secretas. Usando de forma aleatória e inequívoca o último bloco atual, Br−1, para escolher o conjunto de verificadores e o líder responsável da construção do novo bloco, Br, não é suficiente. Como Br−1 deve ser conhecido antes de gerar Br, a última quantidade não-influenciável Qr−1 contida em Br−1 também deve ser conhecida. Assim, então são os verificadores e o líder encarregados de calcular o bloco Br. Assim, nosso poderoso Adversário pode corromper imediatamente todos eles, antes que se envolvam em qualquer discussão sobre Br, de modo a obter controle total sobre o bloco que certificam. Para evitar este problema, os líderes (e também os verificadores) aprendem secretamente sobre o seu papel, mas podem computar uma credencial adequada, capaz de provar a todos que de fato desempenham esse papel. Quando um usuário percebe secretamente que ele é o líder do próximo bloco, primeiro ele monta secretamente seu próprio novo bloco proposto e, em seguida, divulga-o (para que possa ser certificado) juntamente com o seu próprio credencial. Desta forma, embora o Adversário perceba imediatamente quem é o líder do próximo bloco é, e embora ele possa corrompê-lo imediatamente, será tarde demais para o Adversário influenciar a escolha de um novo bloco. Na verdade, ele não pode mais “revogar” a mensagem do líderdo que um governo poderoso pode colocar de volta na garrafa uma mensagem espalhada de forma viral pelo WikiLeaks. Como veremos, não podemos garantir a singularidade do líder, nem que todos tenham certeza de quem é o líder. é, incluindo o próprio líder! Mas, em Algorand, um progresso inequívoco será garantido. 5. Substituibilidade do Jogador. Depois de propor um novo bloco, o líder pode muito bem “morrer” (ou ser corrompido pelo Adversário), porque seu trabalho está cumprido. Mas, para os verificadores em SV r, as coisas são menos simples. Com efeito, estando encarregado de certificar o novo bloco Br com um número suficiente de assinaturas, eles devem primeiro conseguir um acordo bizantino sobre o bloco proposto pelo líder. O problema é que, não importa quão eficiente seja, BA⋆requer múltiplas etapas e a honestidade de > 2/3 de seus jogadores. Isto é um problema porque, por razões de eficiência, o conjunto de jogadores de BA⋆consiste no pequeno conjunto SV r selecionado aleatoriamente entre o conjunto de todos os usuários. Assim, o nosso poderoso Adversário, embora incapaz de corromper 1/3 de todos os usuários, certamente pode corromper todos os membros do SV r! Felizmente provaremos que o protocolo BA⋆, executado pela propagação de mensagens ponto a ponto, é substituível pelo jogador. Este novo requisito significa que o protocolo corretamente e atinge consenso de forma eficiente, mesmo que cada uma de suas etapas seja executada por um método totalmente novo e aleatório. e conjunto de jogadores selecionados independentemente. Assim, com milhões de usuários, cada pequeno conjunto de jogadores associado a um passo de BA⋆provavelmente possui interseção vazia com o próximo conjunto. Além disso, os conjuntos de jogadores de diferentes etapas do BA⋆provavelmente terão cardinalidades. Além disso, os membros de cada conjunto não sabem quem será o próximo conjunto de jogadores. ser, e não passar secretamente por nenhum estado interno. A propriedade do jogador substituível é realmente crucial para derrotar o dinâmico e muito poderoso Adversário que imaginamos. Acreditamos que os protocolos de jogadores substituíveis serão cruciais em muitos contextos e aplicações. Em particular, eles serão cruciais para executar pequenos subprotocolos com segurança inserido em um universo maior de jogadores com um adversário dinâmico, que, sendo capaz de corromper até mesmo uma pequena fração do total de jogadores, não tem dificuldade em corromper todos os jogadores no menor subprotocolo. Uma propriedade/técnica adicional: honestidade preguiçosa Um usuário honesto segue o que lhe foi prescrito instruções, que incluem estar online e executar o protocolo. Desde então, Algorand tem apenas modesto exigência de computação e comunicação, estar online e rodando o protocolo “no histórico” não é um grande sacrifício. Claro, algumas “ausências” entre jogadores honestos, como aqueles devido à perda repentina de conectividade ou à necessidade de reinicialização, são automaticamente tolerados (porque sempre podemos considerar esses poucos jogadores como temporariamente maliciosos). Destaquemos, porém, que Algorand pode ser simplesmente adaptado para funcionar em um novo modelo, no qual usuários honestos sejam off-line na maior parte do tempo. Nosso novo modelo pode ser apresentado informalmente da seguinte maneira. Honestidade preguiçosa. Grosso modo, um usuário i é preguiçoso, mas honesto se (1) seguir todas as instruções prescritas. instruções, quando ele for solicitado a participar do protocolo, e (2) ele for solicitado a participar ao protocolo apenas raramente e com um aviso prévio adequado. Com uma noção tão relaxada de honestidade, podemos estar ainda mais confiantes de que as pessoas honestas serão à mão quando precisarmos deles, e Algorand garantimos que, quando for o caso, O sistema funciona de forma segura mesmo que, num determinado momento, a maioria dos jogadores participantes são maliciosos.1.3 Trabalho intimamente relacionado As abordagens de prova de trabalho (como as citadas [29] e [4]) são bastante ortogonais às nossas. Assim são os abordagens baseadas no acordo bizantino de passagem de mensagens ou na tolerância prática a falhas bizantinas (como o citado [8]). Na verdade, estes protocolos não podem ser executados entre o conjunto de todos os utilizadores e não podem, em nosso modelo, fique restrito a um conjunto adequadamente pequeno de usuários. Na verdade, nosso poderoso adversário, meu corromper imediatamente todos os usuários envolvidos em um pequeno conjunto encarregado de realmente executar um protocolo BA. Nossa abordagem poderia ser considerada relacionada à prova de aposta [2], no sentido de que o “poder” dos usuários na construção de blocos é proporcional ao dinheiro que possuem no sistema (em oposição a —digamos— para o dinheiro que colocaram em “escrow”). O artigo mais próximo do nosso é o Sleepy Consensus Model of Pass e Shi [30]. Para evitar o computação pesada necessária na abordagem proof-of-work, seu artigo se baseia (e gentilmente créditos) Classificação criptográfica secreta de Algorand. Com este aspecto crucial em comum, vários existem diferenças significativas entre nossos artigos. Em particular, (1) Sua configuração é apenas permitida. Por outro lado, Algorand também é um sistema sem permissão. (2) Eles usam um protocolo estilo Nakamoto e, portanto, seus blockchain se bifurcam com frequência. Embora dispensando proof-of-work, em seu protocolo um líder selecionado secretamente é solicitado a alongar o válido mais longo (em um sentido mais rico) blockchain. Assim, os garfos são inevitáveis e é preciso esperar que o bloco está suficientemente “profundo” na cadeia. Na verdade, para atingir seus objetivos com um adversário capazes de corrupções adaptativas, eles exigem que um bloco seja poli(N) profundo, onde N representa o número total de usuários no sistema. Observe que, mesmo assumindo que um bloco poderia ser produzido em um minuto, se houvesse N = 1 milhão de usuários, seria necessário esperar cerca de 2 milhões de anos para um bloco para se tornar N 2 de profundidade, e por cerca de 2 anos para um bloco se tornar N-profundo. Em contraste, O blockchain de Algorand bifurca-se apenas com probabilidade insignificante, mesmo que o Adversário corrompa usuários imediatamente e de forma adaptativa, e seus novos blocos podem ser imediatamente confiáveis. (3) Eles não tratam de acordos bizantinos individuais. De certa forma, eles apenas garantem “eventual consenso sobre uma sequência crescente de valores”. O protocolo deles é de replicação de estado, em vez do que um BA, e não pode ser usado para chegar a um acordo bizantino sobre um valor individual de juros. Por outro lado, Algorand também pode ser usado apenas uma vez, se desejado, para permitir que milhões de usuários acessem rapidamente chegar a um acordo bizantino sobre um valor específico de juros. (4) Eles exigem relógios fracamente sincronizados. Ou seja, todos os relógios dos usuários são adiantados por um pequeno intervalo de tempo δ. Por outro lado, em Algorand, os relógios precisam apenas ter (essencialmente) a mesma “velocidade”. (5) Seu protocolo funciona com usuários preguiçosos, mas honestos, ou com a maioria honesta dos usuários online. Eles gentilmente creditam Algorand por levantar a questão de usuários honestos ficarem off-line em massa e por apresentando o modelo de honestidade preguiçosa em resposta. O protocolo deles não funciona apenas nos preguiçosos modelo de honestidade, mas também em seu modelo adversário sonolento, onde um adversário escolhe quais usuários estão on-line e quais estão off-line, desde que, em todos os momentos, a maioria dos usuários on-line seja honesta.2 2A versão original do seu artigo, na verdade, considerava apenas a segurança no seu modelo adversário sonolento. O versão original de Algorand, que precede a deles, também explicitamente prevista assumindo que uma determinada maioria do os jogadores online são sempre honestos, mas excluíram-no explicitamente de consideração, em favor do modelo de honestidade preguiçosa. (Por exemplo, se em algum momento metade dos usuários honestos optar por ficar off-line, então a maioria dos usuários on-line pode muito bem ser malicioso. Assim, para evitar que isso aconteça, o Adversário deveria forçar a maior parte de seus jogadores corrompidos também fiquem off-line, o que claramente vai contra o seu próprio interesse.) Observe que um protocolo com maioria de jogadores preguiçosos, mas honestos, funciona muito bem se a maioria dos usuários on-line for sempre mal-intencionada. Isto é assim, porque um número suficiente de jogadores honestos, sabendo que serão cruciais em algum momento raro, elegerá não ficar off-line nesses momentos, nem podem ser forçados a ficar off-line pelo Adversário, já que ele não sabe quem é o jogadores honestos e cruciais podem ser.(6) Eles exigem uma maioria simples e honesta. Por outro lado, a versão atual de Algorand requer uma maioria honesta de 2/3. Outro artigo próximo de nós é Ouroboros: um protocolo Blockchain de prova de participação comprovadamente seguro, por Kiayias, Russell, David e Oliynykov [20]. Além disso, o sistema deles apareceu depois do nosso. Também usa classificação criptográfica para dispensar prova de trabalho de maneira comprovável. No entanto, seus O sistema é, novamente, um protocolo do estilo Nakamoto, no qual as bifurcações são inevitáveis e frequentes. (No entanto, em seu modelo, os bloqueios não precisam ser tão profundos quanto o modelo de consenso sonolento.) Além disso, seu sistema baseia-se nas seguintes suposições: nas palavras dos próprios autores, “(1) o a rede é altamente síncrona, (2) a maioria das partes interessadas selecionadas está disponível conforme necessário para participar em cada época, (3) as partes interessadas não permanecem off-line por longos períodos de tempo, (4) a adaptabilidade das corrupções está sujeita a um pequeno atraso que é medido em rodadas lineares em o parâmetro de segurança.” Por outro lado, Algorand é, com grande probabilidade, livre de bifurcação e não se baseia em nenhuma dessas quatro suposições. Em particular, em Algorand, o Adversário é capaz de corromper instantaneamente os usuários que ele deseja controlar.

Preliminaries

Preliminaries

2.1 Cryptographic Primitives Ideal Hashing. We shall rely on an efficiently computable cryptographic hash function, H, that maps arbitrarily long strings to binary strings of fixed length. Following a long tradition, we model H as a random oracle, essentially a function mapping each possible string s to a randomly and independently selected (and then fixed) binary string, H(s), of the chosen length. In this paper, H has 256-bit long outputs. Indeed, such length is short enough to make the system efficient and long enough to make the system secure. For instance, we want H to be collisionresilient. That is, it should be hard to find two different strings x and y such that H(x) = H(y). When H is a random oracle with 256-bit long outputs, finding any such pair of strings is indeed difficult. (Trying at random, and relying on the birthday paradox, would require \(2^{256/2} = 2^{128}\) trials.) Digital Signing. Digital signatures allow users to to authenticate information to each other without sharing any sharing any secret keys. A digital signature scheme consists of three fast algorithms: a probabilistic key generator G, a signing algorithm S, and a verification algorithm V . Given a security parameter k, a sufficiently high integer, a user i uses G to produce a pair of k-bit keys (i.e., strings): a “public” key pki and a matching “secret” signing key ski. Crucially, a public key does not “betray” its corresponding secret key. That is, even given knowledge of pki, no one other than i is able to compute ski in less than astronomical time. User i uses ski to digitally sign messages. For each possible message (binary string) m, i first hashes m and then runs algorithm S on inputs H(m) and ski so as to produce the k-bit string \(\text{sig}_{pk_i}(m) \triangleq S(H(m), sk_i)\).³ 3Since H is collision-resilient it is practically impossible that, by signing m one “accidentally signs” a different message m′.

The binary string sigpki(m) is referred to as i’s digital signature of m (relative to pki), and can be more simply denoted by sigi(m), when the public key pki is clear from context. Everyone knowing pki can use it to verify the digital signatures produced by i. Specifically, on inputs (a) the public key pki of a player i, (b) a message m, and (c) a string s, that is, i’s alleged digital signature of the message m, the verification algorithm V outputs either YES or NO. The properties we require from a digital signature scheme are: 1. Legitimate signatures are always verified: If s = sigi(m), then V (pki, m, s) = Y ES; and 2. Digital signatures are hard to forge: Without knowledge of ski the time to find a string s such that V (pki, m, s) = Y ES, for a message m never signed by i, is astronomically long. (Following the strong security requirement of Goldwasser, Micali, and Rivest [17], this is true even if one can obtain the signature of any other message.) Accordingly, to prevent anyone else from signing messages on his behalf, a player i must keep his signing key ski secret (hence the term “secret key”), and to enable anyone to verify the messages he does sign, i has an interest in publicizing his key pki (hence the term “public key”). In general, a message m is not retrievable from its signature sigi(m). In order to virtually deal with digital signatures that satisfy the conceptually convenient “retrievability” property (i.e., to guarantee that the signer and the message are easily computable from a signature, we define \[\text{SIG}_{pk_i}(m) = (i, m, \text{sig}_{pk_i}(m))\] and \[\text{SIG}_i(m) = (i, m, \text{sig}_i(m)), \text{ if } pk_i \text{ is clear.}\] Unique Digital Signing. We also consider digital signature schemes (G, S, V ) satisfying the following additional property. 3. Uniqueness. It is hard to find strings pk′, m, s, and s′ such that \(s \neq s'\) and \(V(pk', m, s) = V(pk', m, s') = 1\). (Note that the uniqueness property holds also for strings pk′ that are not legitimately generated public keys. In particular, however, the uniqueness property implies that, if one used the specified key generator G to compute a public key pk together with a matching secret key sk, and thus knew sk, it would be essentially impossible also for him to find two different digital signatures of a same message relative to pk.) Remarks • From Unique signatures to verifiable random functions. Relative to a digital signature scheme with the uniqueness property, the mapping \(m \rightarrow H(\text{sig}_i(m))\) associates to each possible string m, a unique, randomly selected, 256-bit string, and the correctness of this mapping can be proved given the signature sigi(m). That is, ideal hashing and digital signature scheme satisfying the uniqueness property essentially provide an elementary implementation of a verifiable random function, as introduced and by Micali, Rabin, and Vadhan [27]. (Their original implementation was necessarily more complex, since they did not rely on ideal hashing.)

• Three different needs for digital signatures. In Algorand, a user i relies on digital signatures for (1) Authenticating i’s own payments. In this application, keys can be “long-term” (i.e., used to sign many messages over a long period of time) and come from a ordinary signature scheme. (2) Generating credentials proving that i is entitled to act at some step s of a round r. Here, keys can be long-term, but must come from a scheme satisfying the uniqueness property. (3) Authenticating the message i sends in each step in which he acts. Here, keys must be ephemeral (i.e., destroyed after their first use), but can come from an ordinary signature scheme. • A small-cost simplification. For simplicity, we envision each user i to have a single longterm key. Accordingly, such a key must come from a signature scheme with the uniqueness 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 Ledger Algorand tries to mimic the following payment system, based on an idealized public ledger. 1. The Initial Status. Money is associated with individual public keys (privately generated and owned by users). Letting pk1, . . . , pkj be the initial public keys and a1, . . . , aj their respective initial amounts of money units, then the initial status is \[S^0 = (pk_1, a_1), \ldots, (pk_j, a_j),\] which is assumed to be common knowledge in the system. 2. Payments. Let \(pk\) be a public key currently having \(a \geq 0\) money units, \(pk'\) another public key, and \(a'\) a non-negative number no greater than \(a\). Then, a (valid) payment \(\wp\) is a digital signature, relative to pk, specifying the transfer of a′ monetary units from pk to pk′, together with some additional information. In symbols, \[\wp = \text{SIG}_{pk}(pk, pk', a', I, H(I)),\] where I represents any additional information deemed useful but not sensitive (e.g., time information and a payment identifier), and I any additional information deemed sensitive (e.g., the reason for the payment, possibly the identities of the owners of pk and the pk′, and so on). We refer to pk (or its owner) as the payer, to each pk′ (or its owner) as a payee, and to a′ as the amount of the payment ℘. Free Joining Via Payments. Note that users may join the system whenever they want by generating their own public/secret key pairs. Accordingly, the public key pk′ that appears in the payment ℘above may be a newly generated public key that had never “owned” any money before. 3. The Magic Ledger. In the Idealized System, all payments are valid and appear in a tamper-proof list L of sets of payments “posted on the sky” for everyone to see: \[L = PAY^1, PAY^2, \ldots\]

Each block PAY r+1 consists of the set of all payments made since the appearance of block PAY r. In the ideal system, a new block appears after a fixed (or finite) amount of time. Discussion. • More General Payments and Unspent Transaction Output. More generally, if a public key pk owns an amount a, then a valid payment ℘of pk may transfer the amounts a′ 1, a′ 2, . . ., respectively to the keys pk′ 1, pk′ 2, . . ., so long as P j a′ \(j \leq a\). In Bitcoin and similar systems, the money owned by a public key pk is segregated into separate amounts, and a payment ℘made by pk must transfer such a segregated amount a 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 unspent transaction output, to another key, possibly pk itself. Algorand also works with keys having segregated amounts. However, in order to focus on the novel aspects of Algorand, it is conceptually simpler to stick to our simpler forms of payments and keys having a single amount associated to them. • Current Status. The Idealized Scheme does not directly provide information about the current status of the system (i.e., about how many money units each public key has). This information is deducible from the Magic Ledger. In the ideal system, an active user continually stores and updates the latest status information, or he would otherwise have to reconstruct it, either from scratch, or from the last time he computed it. (In the next version of this paper, we shall augment Algorand so as to enable its users to reconstruct the current status in an efficient manner.) • Security and “Privacy”. Digital signatures guarantee that no one can forge a payment by another user. In a payment ℘, the public keys and the amount are not hidden, but the sensitive information I is. Indeed, only H(I) appears in ℘, and since H is an ideal hash function, H(I) is a random 256-bit value, and thus there is no way to figure out what I was better than by simply guessing it. Yet, to prove what I was (e.g., to prove the reason for the payment) the payer may just reveal I. The correctness of the revealed I can be verified by computing H(I) and comparing the resulting value with the last item of ℘. In fact, since H is collision resilient, it is hard to find a second value I′ such that H(I) = H(I′). 2.3 Basic Notions and Notations Keys, Users, and Owners Unless otherwise specified, each public key (“key” for short) is longterm and relative to a digital signature scheme with the uniqueness property. A public key i joins the system when another public key j already in the system makes a payment to i. For color, we personify keys. We refer to a key i as a “he”, say that i is honest, that i sends and receives messages, etc. User is a synonym for key. When we want to distinguish a key from the person to whom it belongs, we respectively use the term “digital key” and “owner”. Permissionless and Permissioned Systems. A system is permissionless, if a digital key is free to join at any time and an owner can own multiple digital keys; and its permissioned, otherwise.

Unique Representation Each object in Algorand has a unique representation. In particular, each set \(\{(x, y, z, \ldots) : x \in X, y \in Y, z \in Z, \ldots\}\) is ordered in a pre-specified manner: e.g., first lexicographically in x, then in y, etc. Same-Speed Clocks There is no global clock: rather, each user has his own clock. User clocks need not be synchronized in any way. We assume, however, that they all have the same speed. For instance, when it is 12pm according to the clock of a user i, it may be 2:30pm according to the clock of another user j, but when it will be 12:01 according to i’s clock, it will 2:31 according to j’s clock. That is, “one minute is the same (sufficiently, essentially the same) for every user”. Rounds Algorand is organized in logical units, r = 0, 1, . . ., called rounds. We consistently use superscripts to indicate rounds. To indicate that a non-numerical quantity Q (e.g., a string, a public key, a set, a digital signature, etc.) refers to a round r, we simply write Qr. Only when Q is a genuine number (as opposed to a binary string interpretable as a number), do we write Q(r), so that the symbol r could not be interpreted as the exponent of Q. At (the start of a) round r > 0, the set of all public keys is PKr, and the system status is Sr = n i, a(r) i , . . .  : \(i \in PK^{r_o}\) , where a(r) i is the amount of money available to the public key i. Note that PKr is deducible from Sr, and that Sr may also specify other components for each public key i. For round 0, PK0 is the set of initial public keys, and S0 is the initial status. Both PK0 and S0 are assumed to be common knowledge in the system. For simplicity, at the start of round r, so are PK1, . . . , PKr and S1, . . . , Sr. In a round r, the system status transitions from Sr to Sr+1: symbolically, \[\text{Round } r: S^r \longrightarrow S^{r+1}.\] Payments In Algorand, the users continually make payments (and disseminate them in the way described in subsection 2.7). A payment \(\wp\) of a user \(i \in PK^r\) has the same format and semantics as in the Ideal System. Namely, ℘= SIGi(i, i′, a, I, H(I)) . Payment ℘is individually valid at a round r (is a round-r payment, for short) if (1) its amount a is less than or equal to a(r) i , and (2) it does not appear in any official payset PAY r′ for r′ < r. (As explained below, the second condition means that ℘has not already become effective. A set of round-r payments of i is collectively valid if the sum of their amounts is at most a(r) i . Paysets A round-r payset P is a set of round-r payments such that, for each user i, the payments of i in P (possibly none) are collectively valid. The set of all round-r paysets is PAY(r). A round-r payset P is maximal if no superset of P is a round-r payset. We actually suggest that a payment \(\wp\) also specifies a round \(\rho\), \(\wp = \text{SIG}_i(\rho, i, i', a, I, H(I))\), and cannot be valid at any round outside \([\rho, \rho + k]\), for some fixed non-negative integer \(k\).4 4This simplifies checking whether ℘has become “effective” (i.e., it simplifies determining whether some payset \(PAY^r\) contains \(\wp\). When \(k = 0\), if \(\wp = \text{SIG}_i(r, i, i', a, I, H(I))\), and \(\wp \notin PAY^r\), then \(i\) must re-submit \(\wp\).

Official Paysets For every round r, Algorand publicly selects (in a manner described later on) a single (possibly empty) payset, PAY r, the round’s official payset. (Essentially, PAY r represents the round-r payments that have “actually” happened.) As in the Ideal System (and Bitcoin), (1) the only way for a new user j to enter the system is to be the recipient of a payment belonging to the official payset PAY r of a given round r; and (2) PAY r determines the status of the next round, Sr+1, from that of the current round, Sr. Symbolically, \(PAY^r: S^r \longrightarrow S^{r+1}\). Specifically, 1. the set of public keys of round r + 1, PKr+1, consists of the union of PKr and the set of all payee keys that appear, for the first time, in the payments of PAY r; and 2. the amount of money a(r+1) i that a user i owns in round r + 1 is the sum of ai(r) —i.e., the amount of money \(i\) owned in the previous round (0 if \(i \notin PK^r\))— and the sum of amounts paid to i according to the payments of PAY r. In sum, as in the Ideal System, each status Sr+1 is deducible from the previous payment history: PAY 0, . . . , PAY r. 2.4 Blocks and Proven Blocks In Algorand0, the block Br corresponding to a round r specifies: r itself; the set of payments of round r, PAY r; a quantity Qr, 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: B1 = (1, PAY 1, Q0, H(B0)), B2 = (2, PAY 2, Q1, H(B1)), B3 = (3, PAY 3, Q2, H(B2)), . . . In Algorand, the authenticity of a block is actually vouched by a separate piece of information, a “block certificate” CERT r, which turns Br into a proven block, Br. The Magic Ledger, therefore, is implemented by the sequence of the proven blocks, B1, B2, . . . Discussion As we shall see, CERT r consists of a set of digital signatures for H(Br), those of a majority of the members of SV r, together with a proof that each of those members indeed belongs to SV r. We could, of course, include the certificates CERT r in the blocks themselves, but find it conceptually cleaner to keep it separate.) In Bitcoin each block must satisfy a special property, that is, must “contain a solution of a crypto puzzle”, which makes block generation computationally intensive and forks both inevitable and not rare. By contrast, Algorand’s blockchain has two main advantages: it is generated with minimal computation, and it will not fork with overwhelmingly high probability. Each block Bi is safely final as soon as it enters the blockchain.

2.5 Acceptable Failure Probability To analyze the security of Algorand we specify the probability, F, with which we are willing to accept that something goes wrong (e.g., that a verifier set SV r 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 that case, we find it useful to set F to a concrete value, so as to get a more intuitive grasp of the fact that it is indeed possible, in Algorand, to enjoy simultaneously sufficient security and sufficient efficiency. To emphasize that F is parameter that can be set as desired, in the first and second embodiments we respectively set F = 10−12 and F = 10−18 . Discussion Note that 10−12 is actually less than one in a trillion, and we believe that such a choice of F is adequate in our application. Let us emphasize that 10−12 is not the probability with which the Adversary can forge the payments of an honest user. All payments are digitally signed, and thus, if the proper digital signatures are used, the probability of forging a payment is far lower than 10−12, and is, in fact, essentially 0. The bad event that we are willing to tolerate with probability F is that Algorand’s blockchain forks. Notice that, with our setting of F and one-minute long rounds, a fork is expected to occur in Algorand’s blockchain as infrequently as (roughly) once in 1.9 million years. By contrast, in Bitcoin, a forks occurs quite often. A more demanding person may set F to a lower value. To this end, in our second embodiment we consider setting F to 10−18. Note that, assuming that a block is generated every second, 1018 is the estimated number of seconds taken by the Universe so far: from the Big Bang to present time. Thus, with F = 10−18, if a block is generated in a second, one should expect for the age of the Universe to see a fork. 2.6 The Adversarial Model Algorand is designed to be secure in a very adversarial model. Let us explain. Honest and Malicious Users A user is honest if he follows all his protocol instructions, and is perfectly capable of sending and receiving messages. A user is malicious (i.e., Byzantine, in the parlance of distributed computing) if he can deviate arbitrarily from his prescribed instructions. The Adversary The Adversary is an efficient (technically polynomial-time) algorithm, personified for color, who can immediately make malicious any user he wants, at any time he wants (subject only to an upperbound to the number of the users he can corrupt). The Adversary totally controls and perfectly coordinates all malicious users. He takes all actions on their behalf, including receiving and sending all their messages, and can let them deviate from their prescribed instructions in arbitrary ways. Or he can simply isolate a corrupted user sending and receiving messages. Let us clarify that no one else automatically learns that a user i is malicious, although i’s maliciousness may transpire by the actions the Adversary has him take. This powerful adversary however, • Does not have unbounded computational power and cannot successfully forge the digital signature of an honest user, except with negligible probability; and

• Cannot interfere in any way with the messages exchanges among honest users. Furthermore, his ability to attack honest users is bounded by one of the following assumption. Honesty Majority of Money We consider a continuum of Honest Majority of Money (HMM) assumptions: namely, for each non-negative integer k and real h > 1/2, HHMk > h: the honest users in every round r owned a fraction greater than h of all money in the system at round r −k. Discussion. Assuming that all malicious users perfectly coordinate their actions (as if controlled by a single entity, the Adversary) is a rather pessimistic hypothesis. Perfect coordination among too many individuals is difficult to achieve. Perhaps coordination only occurs within separate groups of malicious players. But, since one cannot be sure about the level of coordination malicious users may enjoy, we’d better be safe than sorry. Assuming that the Adversary can secretly, dynamically, and immediately corrupt users is also pessimistic. After all, realistically, taking full control of a user’s operations should take some time. The assumption HMMk > h implies, for instance, that, if a round (on average) is implemented in one minute, then, the majority of the money at 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. Note that the HMM assumptions and the previous Honest Majority of Computing Power assumptions are related in the sense that, since computing power can be bought with money, if malicious users own most of the money, then they can obtain most of the computing power. 2.7 The Communication Model We envisage message propagation —i.e., “peer-to-peer gossip”5— to be the only means of communication. Temporary Assumption: Timely Delivery of Messages in the Entire Network. For most part of this paper we assume that every propagated message reaches almost all honest users in a timely fashion. We shall remove this assumption in Section 10, where we deal with network partitions, either naturally occurring or adversarially induced. (As we shall see, we only assume timely delivery of messages within each connected component of the network.) One concrete way to capture timely delivery of propagated messages (in the entire network) is the following: For all reachability \(\rho > 95\%\) and message size \(\mu \in \mathbb{Z}^+\), there exists \(\lambda_{\rho,\mu}\) such that, if a honest user propagates \(\mu\)-byte message \(m\) at time \(t\), then \(m\) reaches, by time \(t + \lambda_{\rho,\mu}\), at least a fraction \(\rho\) of the honest users. 5Essentially, as in Bitcoin, when a user propagates a message m, every active user i receiving m for the first time, randomly and independently selects a suitably small number of active users, his “neighbors”, to whom he forwards m, possibly until he receives an acknowledgement from them. The propagation of m terminates when no user receives m for the first time.

The above property, however, cannot support our Algorand protocol, without explicitly and separately envisaging a mechanism to obtain the latest blockchain —by another user/depository/etc. In fact, to construct a new block Br not only should a proper set of verifiers timely receive round-r messages, but also the messages of previous rounds, so as to know Br−1 and all other previous blocks, which is necessary to determine whether the payments in Br are valid. The following assumption instead suffices. Message Propagation (MP) Assumption: For all \(\rho > 95\%\) and \(\mu \in \mathbb{Z}^+\), there exists \(\lambda_{\rho,\mu}\) such that, for all times \(t\) and all \(\mu\)-byte messages \(m\) propagated by an honest user before \(t - \lambda_{\rho,\mu}\), \(m\) is received, by time \(t\), by at least a fraction \(\rho\) of the honest users. Protocol Algorand ′ actually instructs each of a small number of users (i.e., the verifiers of a given step of a round in Algorand ′, to propagate a separate message of a (small) prescribed size, and we need to bound the time required to fulfill these instructions. We do so by enriching the MP assumption as follows. For all \(n\), \(\rho > 95\%\), and \(\mu \in \mathbb{Z}^+\), there exists \(\lambda_{n,\rho,\mu}\) such that, for all times \(t\) and all \(\mu\)-byte messages \(m_1, \ldots, m_n\), each propagated by an honest user before \(t - \lambda_{n,\rho,\mu}\), \(m_1, \ldots, m_n\) are received, by time \(t\), by at least a fraction \(\rho\) of the honest users. Note • The above assumption is deliberately simple, but also stronger than needed in our paper.6 • For simplicity, we assume \(\rho = 1\), and thus drop mentioning \(\rho\). • We pessimistically assume that, provided he does not violate the MP assumption, the Adversary totally controls the delivery of all messages. In particular, without being noticed by the honest users, the Adversary he can arbitrarily decide which honest player receives which message when, and arbitrarily accelerate the delivery of any message he wants.7

Preliminares

2.1 Primitivos criptográficos Hashing ideal. Contaremos com uma função criptográfica hash eficientemente computável, H, que mapeia cadeias arbitrariamente longas em cadeias binárias de comprimento fixo. Seguindo uma longa tradição, modelamos H como um oracle aleatório, essencialmente uma função que mapeia cada string s possível para um aleatório e string binária selecionada independentemente (e então fixa), H(s), do comprimento escolhido. Neste artigo, H tem saídas longas de 256 bits. Na verdade, esse comprimento é curto o suficiente para tornar o sistema eficiente e longo o suficiente para torná-lo seguro. Por exemplo, queremos que H seja resistente a colisões. Ou seja, deveria ser difícil encontrar duas strings diferentes x e y tais que H(x) = H(y). Quando H é um oracle aleatório com saídas longas de 256 bits, encontrar qualquer par de strings é de fato difícil. (Tentar aleatoriamente e confiar no paradoxo do aniversário exigiria 2.256/2 = 2.128 testes.) Assinatura digital. As assinaturas digitais permitem que os usuários autentiquem informações entre si sem compartilhar nenhuma chave secreta. Um esquema de assinatura digital consiste em três algoritmos: um gerador de chave probabilística G, um algoritmo de assinatura S e um algoritmo de verificação V. Dado um parâmetro de segurança k, um número inteiro suficientemente alto, um usuário i usa G para produzir um par de Chaves de k bits (ou seja, strings): uma chave “pública” pki e uma chave de assinatura “secreta” correspondente ski. Crucialmente, um a chave pública não “trai” sua chave secreta correspondente. Ou seja, mesmo com conhecimento de pki, não outro além de mim é capaz de calcular esqui em menos de um tempo astronômico. O usuário i usa ski para assinar mensagens digitalmente. Para cada mensagem possível (string binária) m, primeiro hashes m e então executa o algoritmo S nas entradas H(m) e ski para produzir a string de k bits sigpki(m) \(\triangleq\)S(H(m), esqui) .3 3Como H é resistente a colisões, é praticamente impossível que, ao assinar m, alguém “assine acidentalmente” uma mensagem diferente mensagem m'.A string binária sigpki(m) é chamada de assinatura digital de i de m (relativa a pki) e pode ser denotado mais simplesmente por sigi(m), quando a chave pública pki está clara no contexto. Qualquer pessoa que conheça o pki pode usá-lo para verificar as assinaturas digitais produzidas pelo i. Especificamente, em insere (a) a chave pública pki de um jogador i, (b) uma mensagem m e (c) uma string s, ou seja, i é alegado assinatura digital da mensagem m, o algoritmo de verificação V produz SIM ou NÃO. As propriedades que exigimos de um esquema de assinatura digital são: 1. Assinaturas legítimas são sempre verificadas: Se s = sigi(m), então V (pki, m, s) = Y ES; e 2. Assinaturas digitais são difíceis de falsificar: sem conhecimento de esqui, é hora de encontrar uma string como essa. que V (pki, m, s) = Y ES, para uma mensagem m nunca assinada por i, é astronomicamente longo. (Seguindo os fortes requisitos de segurança de Goldwasser, Micali e Rivest [17], isso é verdade mesmo que se possa obter a assinatura de qualquer outra mensagem.) Assim, para evitar que qualquer outra pessoa assine mensagens em seu nome, um jogador deve manter o seu assinando a chave secreta de esqui (daí o termo “chave secreta”) e para permitir que qualquer pessoa verifique as mensagens ele assina, tenho interesse em divulgar sua chave pki (daí o termo “chave pública”). Em geral, uma mensagem m não é recuperável a partir da sua assinatura sigi(m). Para negociar virtualmente com assinaturas digitais que satisfaçam a propriedade de “recuperabilidade” conceitualmente conveniente (ou seja, para garantir que o signatário e a mensagem sejam facilmente computáveis a partir de uma assinatura, definimos SIGpki(m) = (i, m, sigpki(m)) e SIGi(m) = (i, m, sigi(m)), se pki estiver claro. Assinatura digital exclusiva. Consideramos também esquemas de assinatura digital (G, S, V ) que satisfazem a seguinte propriedade adicional. 3. Singularidade. É difícil encontrar strings pk′, m, s e s′ tais que ̸= s′ e V (pk′, m, s) = V (pk′, m, s′) = 1. (Observe que a propriedade de exclusividade também é válida para strings pk′ que não são geradas legitimamente chaves públicas. Em particular, porém, a propriedade de unicidade implica que, se alguém usasse a propriedade gerador de chave especificado G para calcular uma chave pública pk junto com uma chave secreta correspondente sk, e, portanto, sabia que sk, seria essencialmente impossível também para ele encontrar dois dispositivos digitais diferentes. assinaturas de uma mesma mensagem relativa a pk.) Observações • De assinaturas exclusivas a funções aleatórias verificáveis. Em relação a um digital esquema de assinatura com a propriedade de exclusividade, o mapeamento m \(\to\) H(sigi(m)) associa-se a cada string m possível, uma string única de 256 bits selecionada aleatoriamente e a exatidão disso o mapeamento pode ser provado dada a assinatura sigi(m). Ou seja, esquema ideal de hashing e assinatura digital que satisfaz a propriedade de exclusividade essencialmente fornecer uma implementação elementar de uma função aleatória verificável, conforme introduzida e por Micali, Rabin e Vadhan [27]. (Sua implementação original era necessariamente mais complexa, já que eles não dependiam do hashing ideal.)• Três necessidades diferentes para assinaturas digitais. Em Algorand, um usuário depende de recursos digitais assinaturas para (1) Autenticação dos próprios pagamentos do i. Nesta aplicação, as chaves podem ser de “longo prazo” (ou seja, usadas para assinar muitas mensagens durante um longo período de tempo) e vêm de um esquema de assinatura comum. (2) Gerar credenciais provando que i tem o direito de agir em alguma etapa s de uma rodada r. Aqui, as chaves podem ser de longo prazo, mas devem vir de um esquema que satisfaça a propriedade de exclusividade. (3) Autenticar a mensagem que envio em cada etapa em que atua. Aqui, as chaves devem ser efêmero (ou seja, destruído após seu primeiro uso), mas pode vir de um esquema de assinatura comum. • Uma simplificação de pequeno custo. Para simplificar, imaginamos que cada usuário i tenha uma única chave de longo prazo. Conseqüentemente, tal chave deve vir de um esquema de assinatura com a exclusividade propriedade. Essa simplicidade tem um pequeno custo computacional. Normalmente, na verdade, digital único as assinaturas são um pouco mais caras para produzir e verificar do que as assinaturas comuns. 2.2 O livro-razão público idealizado Algorand tenta imitar o seguinte sistema de pagamento, baseado em um livro-razão público idealizado. 1. O Status Inicial. O dinheiro está associado a chaves públicas individuais (geradas de forma privada e propriedade dos usuários). Deixando pk1, . . . , pkj são as chaves públicas iniciais e a1, . . . , e seus respectivos quantias iniciais de unidades monetárias, então o status inicial é S0 = (pk1, a1), . . . , (pkj, aj) , que é assumido como conhecimento comum no sistema. 2. Pagamentos. Seja pk uma chave pública atualmente com \(\geq\)0 unidades monetárias, pk′ outra chave pública chave, e a′ um número não negativo não maior que a. Então, um pagamento (válido) \(\wp\)é um pagamento digital assinatura, relativa a pk, especificando a transferência de a′ unidades monetárias de pk para pk′, juntamente com algumas informações adicionais. Em símbolos, \(\wp\)= SIGpk(pk, pk′, a′, I, H(I)), onde I representa qualquer informação adicional considerada útil, mas não sensível (por exemplo, tempo informações e um identificador de pagamento) e qualquer informação adicional considerada sensível (por exemplo, o motivo do pagamento, possivelmente as identidades dos proprietários do pk e do pk′, e assim por diante). Referimo-nos a pk (ou seu proprietário) como pagador, a cada pk′ (ou seu proprietário) como beneficiário e a a′ como o valor do pagamento \(\wp\). Adesão gratuita por meio de pagamentos. Observe que os usuários podem ingressar no sistema quando quiserem, gerando seus próprios pares de chaves pública/secreta. Assim, a chave pública pk′ que aparece em o pagamento \(\wp\)acima pode ser uma chave pública recém-gerada que nunca “possuíu” nenhum dinheiro antes. 3. O Livro Mágico. No Sistema Idealizado, todos os pagamentos são válidos e aparecem em formato inviolável lista L de conjuntos de pagamentos “postados no céu” para que todos possam ver: L = PAGUE 1, PAGUE 2, . . . ,Cada bloco PAY r+1 consiste no conjunto de todos os pagamentos efetuados desde o aparecimento do bloco PAGAR R. No sistema ideal, um novo bloco aparece após um período de tempo fixo (ou finito). Discussão. • Pagamentos mais gerais e resultados de transações não gastas. De forma mais geral, se uma chave pública pk possui um valor a, então um pagamento válido \(\wp\)of pk pode transferir os valores a′ 1, uma' 2, . . ., respectivamente às chaves pk′ 1, pk' 2, . . ., desde que P eu' j \(\leq\)a. Em Bitcoin e sistemas similares, o dinheiro pertencente a um pacote de chave pública é segregado em valores, e um pagamento \(\wp\)feito por pk deve transferir esse valor segregado em sua totalidade. Se pk deseja transferir apenas uma fração a′ < a de a para outra chave, então ele também deve transferir a fração saldo, a saída da transação não gasta, para outra chave, possivelmente o próprio pk. Algorand também funciona com chaves com valores segregados. Contudo, para focar no aspectos novos de Algorand, é conceitualmente mais simples manter nossas formas de pagamento mais simples e chaves com um único valor associado a elas. • Status atual. O Esquema Idealizado não fornece diretamente informações sobre o atual status do sistema (ou seja, sobre quantas unidades monetárias cada chave pública possui). Esta informação é dedutível do Magic Ledger. No sistema ideal, um usuário ativo armazena e atualiza continuamente as informações de status mais recentes, ou ele teria que reconstruí-lo, seja do zero, ou desde a última vez que ele calculou. (Na próxima versão deste artigo, aumentaremos Algorand para permitir seu usuários reconstruam o status atual de maneira eficiente.) • Segurança e “Privacidade”. As assinaturas digitais garantem que ninguém pode falsificar um pagamento outro usuário. Em um \(\wp\) de pagamento, as chaves públicas e o valor não ficam ocultos, mas sim o sensível informação que eu sou. Na verdade, apenas H(I) aparece em \(\wp\), e como H é uma função hash ideal, H(I) é um valor aleatório de 256 bits e, portanto, não há como descobrir o que eu era melhor do que simplesmente adivinhando. No entanto, para provar o que eu era (por exemplo, para provar o motivo do pagamento), o o pagador pode apenas revelar I. A exatidão do I revelado pode ser verificada calculando H(I) e comparando o valor resultante com o último item de \(\wp\). Na verdade, como H é resiliente a colisões, é difícil encontrar um segundo valor I′ tal que H(I) = H(I′). 2.3 Noções e notações básicas Chaves, usuários e proprietários A menos que especificado de outra forma, cada chave pública (“chave” para abreviar) é de longo prazo e relativa a um esquema de assinatura digital com a propriedade de exclusividade. Uma chave pública que eu juntei o sistema quando outra chave pública j já no sistema faz um pagamento para i. Para a cor, personificamos as chaves. Referimo-nos a uma chave i como “ele”, dizemos que sou honesto, que envio e recebe mensagens, etc. Usuário é sinônimo de chave. Quando queremos distinguir uma chave de a quem pertence, utilizamos respectivamente os termos “chave digital” e “proprietário”. Sistemas sem permissão e com permissão. Um sistema não tem permissão se uma chave digital for gratuita aderir a qualquer momento e um proprietário pode possuir várias chaves digitais; e é permitido, caso contrário.Representação Única Cada objeto em Algorand possui uma representação única. Em particular, cada conjunto {(x, y, z, . . .) : x \(\in\)X, y \(\in\)Y, z \(\in\)Z, . . .} é ordenado de uma maneira pré-especificada: por exemplo, primeiro lexicograficamente em x, depois em y, etc. Relógios da mesma velocidade Não existe um relógio global: cada usuário tem seu próprio relógio. Relógios do usuário não precisa ser sincronizado de forma alguma. Assumimos, no entanto, que todos eles têm a mesma velocidade. Por exemplo, quando são 12h de acordo com o relógio de um usuário i, podem ser 14h30 de acordo com o relógio de outro usuário j, mas quando for 12h01 de acordo com o relógio de i, serão 2h31 de acordo para o relógio de j. Ou seja, “um minuto é igual (suficientemente, essencialmente igual) para todos os usuários”. Rodadas Algorand está organizado em unidades lógicas, r = 0, 1, . . ., chamadas rodadas. Usamos consistentemente sobrescritos para indicar rodadas. Para indicar que uma quantidade não numérica Q (por exemplo, uma string, uma chave pública, um conjunto, uma assinatura digital, etc.) refere-se a uma rodada r, simplesmente escrevemos Qr. Somente quando Q for um número genuíno (em oposição a uma sequência binária interpretável como um número), faça escrevemos Q(r), de modo que o símbolo r não possa ser interpretado como o expoente de Q. No (início de uma) rodada r > 0, o conjunto de todas as chaves públicas é PKr e o status do sistema é Sr = n eu, um (r) eu,. . .  : eu \(\in\)PKro , onde um(r) eu é a quantidade de dinheiro disponível para a chave pública i. Observe que PKr é dedutível de Sr, e esse Sr também pode especificar outros componentes para cada chave pública i. Para a rodada 0, PK0 é o conjunto de chaves públicas iniciais e S0 é o status inicial. Tanto PK0 quanto S0 são considerados de conhecimento comum no sistema. Para simplificar, no início da rodada r, então são PK1, . . . , PKr e S1, . . . , Sr. Numa rodada r, o status do sistema transita de Sr para Sr+1: simbolicamente, Rodada r: Sr −→Sr+1. Pagamentos Em Algorand, os usuários realizam pagamentos continuamente (e os divulgam na forma descrito na subseção 2.7). Um pagamento \(\wp\)de um usuário i \(\in\)PKr tem o mesmo formato e semântica como no Sistema Ideal. Ou seja, \(\wp\)= SIGi(i, i′, a, I, H(I)) . O pagamento \(\wp\)é individualmente válido em uma rodada r (é um pagamento redondo, para abreviar) se (1) seu valor a é menor ou igual a a(r) i, e (2) não aparece em nenhum conjunto de pagamentos oficial PAY r′ para r′ < r. (Conforme explicado abaixo, a segunda condição significa que \(\wp\) ainda não entrou em vigor. Um conjunto de pagamentos redondos de i é coletivamente válido se a soma de seus valores for no máximo a(r) eu. Conjuntos de pagamentos Um conjunto de pagamentos redondo P é um conjunto de pagamentos redondos tais que, para cada usuário i, os pagamentos de i em P (possivelmente nenhum) são coletivamente válidos. O conjunto de todos os conjuntos de pagamentos da rodada r é PAY(r). Um round-r payset P é máximo se nenhum superconjunto de P for um payset round-r. Na verdade, sugerimos que um pagamento \(\wp\)também especifica uma rodada \(\rho\), \(\wp\)= SIGi(\(\rho\), i, i′, a, I, H(I)) , e não pode ser válido em qualquer rodada fora de [\(\rho\), \(\rho\) + k], para algum inteiro não negativo fixo k.4 4Isso simplifica a verificação se \(\wp\)se tornou “eficaz” (ou seja, simplifica a determinação se algum conjunto de salários PAGAR r contém \(\wp\). Quando k = 0, se \(\wp\)= SIGi(r, i, i′, a, I, H(I)) e \(\wp\)/\(\in\)PAY r, então devo reenviar \(\wp\).Pagamentos oficiais Para cada rodada r, Algorand seleciona publicamente (da maneira descrita mais adiante) um único conjunto de pagamentos (possivelmente vazio), PAY r, o conjunto de pagamentos oficial da rodada. (Essencialmente, PAY r representa os pagamentos redondos que “realmente” aconteceram.) Assim como no Sistema Ideal (e Bitcoin), (1) a única maneira de um novo usuário j entrar no sistema deve ser o destinatário de um pagamento pertencente ao conjunto de pagamentos oficial PAY r de uma determinada rodada r; e (2) PAY r determina o status da próxima rodada, Sr+1, daquele da rodada atual, Sr. Simbolicamente, PAGAR r: Sr −→Sr+1. Especificamente, 1. o conjunto de chaves públicas da rodada r + 1, PKr+1, consiste na união de PKr e no conjunto de todos chaves de beneficiário que aparecem, pela primeira vez, nos pagamentos de PAY r; e 2. a quantidade de dinheiro a(r+1) eu que um usuário i possui na rodada r + 1 é a soma de ai(r) - ou seja, o quantidade de dinheiro que possuo na rodada anterior (0 se i̸\(\in\)PKr) - e a soma das quantias pago a i de acordo com os pagamentos de PAY r. Em suma, tal como no Sistema Ideal, cada estado Sr+1 é dedutível do histórico de pagamentos anteriores: PAGUE 0, . . . , PAGUE R. 2.4 Blocos e Blocos Comprovados Em Algorand0, o bloco Br correspondente a uma rodada r especifica: o próprio r; o conjunto de pagamentos de rodada r, PAGAR r; uma quantidade Qr, a ser explicada, e o hash do bloco anterior, H(Br−1). Assim, partindo de algum bloco fixo B0, temos um blockchain tradicional: B1 = (1, PAGUE 1, Q0, H(B0)), B2 = (2, PAGUE 2, Q1, H(B1)), B3 = (3, PAGUE 3, Q2, H(B2)), . . . Em Algorand, a autenticidade de um bloco é na verdade comprovada por uma informação separada, um “certificado de bloco” CERT r, que transforma Br em um bloco comprovado, Br. O livro mágico, portanto, é implementado pela sequência dos blocos comprovados, B1, B2, . . . Discussão Como veremos, o CERT r consiste em um conjunto de assinaturas digitais para H(Br), aquelas de um maioria dos membros do SV r, juntamente com uma prova de que cada um desses membros pertence efectivamente para SV r. Poderíamos, é claro, incluir os certificados CERT r nos próprios blocos, mas conceitualmente mais limpo para mantê-lo separado.) Em Bitcoin cada bloco deve satisfazer uma propriedade especial, ou seja, deve “conter uma solução de um crypto puzzle”, o que torna a geração de blocos computacionalmente intensiva e bifurcações inevitáveis e não raro. Por outro lado, blockchain de Algorand tem duas vantagens principais: é gerado com cálculo mínimo e não será bifurcado com probabilidade extremamente alta. Cada bloco Bi é final com segurança assim que entrar em blockchain.2,5 Probabilidade de falha aceitável Para analisar a segurança de Algorand especificamos a probabilidade, F, com a qual estamos dispostos a aceitar que algo dê errado (por exemplo, que um conjunto verificador SV r não tenha uma maioria honesta). Como no caso do comprimento de saída da função criptográfica hash H, também F é um parâmetro. Mas, como nesse caso, achamos útil definir F para um valor concreto, de modo a obter uma estimativa mais intuitiva. compreensão do fato de que é de fato possível, em Algorand, desfrutar simultaneamente de segurança suficiente e eficiência suficiente. Para enfatizar que F é um parâmetro que pode ser definido conforme desejado, na primeira e segundas modalidades, definimos respectivamente F = 10−12 e F = 10−18 . Discussão Observe que 10-12 é, na verdade, menos que um em um trilhão, e acreditamos que tal a escolha de F é adequada em nossa aplicação. Vamos enfatizar que 10−12 não é a probabilidade com o qual o Adversário pode falsificar os pagamentos de um usuário honesto. Todos os pagamentos são digitalmente assinado e, portanto, se as assinaturas digitais adequadas forem usadas, a probabilidade de falsificar um pagamento é muito inferior a 10-12 e é, na verdade, essencialmente 0. O evento ruim que estamos dispostos a tolerar com probabilidade F é que as bifurcações de Algorand blockchain. Observe que, com nossa configuração de F e rodadas de um minuto, espera-se que uma bifurcação ocorra no blockchain de Algorand tão raramente quanto (aproximadamente) uma vez em 1,9 milhões de anos. Por outro lado, em Bitcoin, bifurcações ocorrem com bastante frequência. Uma pessoa mais exigente pode definir F para um valor mais baixo. Para este fim, em nossa segunda modalidade consideramos definir F como 10−18. Observe que, supondo que um bloco seja gerado a cada segundo, 1018 é o número estimado de segundos que o Universo levou até agora: desde o Big Bang até o presente tempo. Assim, com F = 10−18, se um bloco for gerado em um segundo, deve-se esperar para a idade de o Universo para ver uma bifurcação. 2.6 O modelo adversário Algorand foi projetado para ser seguro em um modelo muito adversário. Deixe-nos explicar. Usuários honestos e maliciosos Um usuário é honesto se seguir todas as instruções do protocolo e é perfeitamente capaz de enviar e receber mensagens. Um usuário é malicioso (ou seja, bizantino, no linguagem da computação distribuída) se ele puder desviar-se arbitrariamente de suas instruções prescritas. O Adversário O Adversário é um algoritmo eficiente (tecnicamente em tempo polinomial), personificado pela cor, que pode imediatamente tornar malicioso qualquer usuário que ele quiser, a qualquer hora que ele quiser (sujeito apenas para um limite superior ao número de usuários que ele pode corromper). O Adversário controla totalmente e coordena perfeitamente todos os usuários maliciosos. Ele realiza todas as ações em seu nome, incluindo receber e enviar todas as suas mensagens, e pode permitir que eles se desviem de suas instruções prescritas de maneira arbitrária. Ou ele pode simplesmente isolar um usuário corrompido enviando e recebimento de mensagens. Deixe-nos esclarecer que ninguém mais fica sabendo automaticamente que um usuário i é malicioso, embora a maldade de i possa transparecer nas ações que o Adversário o faz tomar. Este poderoso adversário, no entanto, • Não possui poder computacional ilimitado e não consegue forjar com sucesso o digital assinatura de um usuário honesto, exceto com probabilidade insignificante; e• Não poderá interferir de forma alguma nas trocas de mensagens entre usuários honestos. Além disso, sua capacidade de atacar usuários honestos é limitada por uma das seguintes suposições. Honestidade Maioria do Dinheiro Consideramos um continuum de Maioria Honesta de Dinheiro (HMM) suposições: ou seja, para cada inteiro não negativo k e h real > 1/2, HHMk > h: os usuários honestos em cada rodada r possuíam uma fração maior que h de todo o dinheiro em o sistema na rodada r −k. Discussão. Supondo que todos os usuários mal-intencionados coordenem perfeitamente suas ações (como se fossem controlados por uma única entidade, o Adversário) é uma hipótese bastante pessimista. Coordenação perfeita entre também muitos indivíduos é difícil de alcançar. Talvez a coordenação só ocorra dentro de grupos separados de jogadores maliciosos. Mas, como não se pode ter certeza sobre o nível de coordenação dos usuários mal-intencionados podemos aproveitar, é melhor prevenir do que remediar. Presumir que o Adversário possa corromper secreta, dinâmica e imediatamente os usuários também é pessimista. Afinal, de forma realista, assumir o controle total das operações de um usuário deve levar algum tempo. A suposição HMMk > h implica, por exemplo, que, se uma rodada (em média) for implementada em um minuto, então, a maior parte do dinheiro em uma determinada rodada permanecerá em mãos honestas por pelo menos duas horas, se k = 120, e pelo menos uma semana, se k = 10.000. Observe que as suposições do HMM e a maioria honesta anterior do poder de computação suposições estão relacionadas no sentido de que, uma vez que o poder computacional pode ser comprado com dinheiro, se usuários mal-intencionados possuírem a maior parte do dinheiro, eles poderão obter a maior parte do poder de computação. 2.7 O modelo de comunicação Prevemos que a propagação de mensagens — isto é, “fofoca entre pares”5 — seja o único meio de comunicação. Suposição temporária: entrega oportuna de mensagens em toda a rede. Para na maior parte deste artigo assumimos que toda mensagem propagada atinge quase todos os usuários honestos em tempo hábil. Removeremos essa suposição na Seção 10, onde tratamos de redes partições, sejam de ocorrência natural ou induzidas adversamente. (Como veremos, apenas assumimos entrega oportuna de mensagens dentro de cada componente conectado da rede.) Uma maneira concreta de capturar a entrega oportuna de mensagens propagadas (em toda a rede) é o seguinte: Para toda alcançabilidade \(\rho\) > 95% e tamanho de mensagem \(\mu\) \(\in\)Z+, existe \(\lambda\) \(\rho\),\(\mu\) tal que, se um usuário honesto propagar uma mensagem m de \(\mu\) bytes no tempo t, então m atinge, no tempo t + \(\lambda\) \(\rho\),\(\mu\), pelo menos uma fração \(\rho\) dos usuários honestos. 5Essencialmente, como em Bitcoin, quando um usuário propaga uma mensagem m, todo usuário ativo recebe m pela primeira vez, seleciona aleatoriamente e de forma independente um número adequadamente pequeno de usuários ativos, seus “vizinhos”, para os quais ele encaminha m, possivelmente até que ele receba um reconhecimento deles. A propagação de m termina quando nenhum usuário recebe m pela primeira vez.A propriedade acima, no entanto, não pode suportar nosso protocolo Algorand, sem prever explícita e separadamente um mecanismo para obter o blockchain mais recente - por outro usuário/depositório/etc. Na verdade, para construir um novo bloco Br, não apenas um conjunto adequado de verificadores deve receber atempadamente rodadas-r mensagens, mas também as mensagens das rodadas anteriores, para conhecer o Br−1 e todos os outros blocos, o que é necessário para determinar se os pagamentos em Br são válidos. O seguinte suposição, em vez disso, é suficiente. Suposição de propagação de mensagens (MP): Para todo \(\rho\) > 95% e \(\mu\) \(\in\)Z+, existe \(\lambda\) \(\rho\),\(\mu\) tal que, para todos os tempos t e todas as mensagens de \(\mu\) bytes m propagadas por um usuário honesto antes de t −\(\lambda\) \(\rho\), \(\mu\), m é recebido, no tempo t, por pelo menos uma fração \(\rho\) dos usuários honestos. O protocolo Algorand ′ na verdade instrui cada um de um pequeno número de usuários (ou seja, os verificadores de um dada etapa de uma rodada em Algorand ′, para propagar uma mensagem separada de tamanho (pequeno) prescrito, e precisamos limitar o tempo necessário para cumprir essas instruções. Fazemo-lo enriquecendo o MP suposição da seguinte forma. Para todo n, \(\rho\) > 95% e \(\mu\) \(\in\)Z+, existe \(\lambda\)n,\(\rho\),\(\mu\) tal que, para todos os tempos t e todos \(\mu\)-byte mensagens m1, . . . , mn, cada um propagado por um usuário honesto antes de t −\(\lambda\)n,\(\rho\),\(\mu\), m1, . . . , mn são recebidos, no tempo t, por pelo menos uma fração \(\rho\) dos usuários honestos. Nota • A suposição acima é deliberadamente simples, mas também mais forte do que o necessário em nosso artigo.6 • Para simplificar, assumimos \(\rho\) = 1 e, portanto, deixamos de mencionar \(\rho\). • Presumimos pessimistamente que, desde que não viole a suposição do MP, o Adversário controla totalmente a entrega de todas as mensagens. Em particular, sem ser notado pelos honestos usuários, o Adversário pode decidir arbitrariamente qual jogador honesto recebe qual mensagem quando, e acelerar arbitrariamente a entrega de qualquer mensagem que desejar.7

The BA Protocol BA⋆in a Traditional Setting

The BA Protocol BA⋆in a Traditional Setting

As already emphasized, Byzantine agreement is a key ingredient of Algorand. Indeed, it is through the use of such a BA protocol that Algorand is unaffected by forks. However, to be secure against our powerful Adversary, Algorand must rely on a BA protocol that satisfies the new player-replaceability constraint. In addition, for Algorand to be efficient, such a BA protocol must be very efficient. BA protocols were first defined for an idealized communication model, synchronous complete networks (SC networks). Such a model allows for a simpler design and analysis of BA protocols. 6Given the honest percentage h and the acceptable failure probability F, Algorand computes an upperbound, N, to the maximum number of member of verifiers in a step. Thus, the MP assumption need only hold for \(n \leq N\). In addition, as stated, the MP assumption holds no matter how many other messages may be propagated alongside the mj’s. As we shall see, however, in Algorand messages at are propagated in essentially non-overlapping time intervals, during which either a single block is propagated, or at most N verifiers propagate a small (e.g., 200B) message. Thus, we could restate the MP assumption in a weaker, but also more complex, way. 7For instance, he can immediately learn the messages sent by honest players. Thus, a malicious user i′, who is asked to propagate a message simultaneously with a honest user i, can always choose his own message m′ based on the message m actually propagated by i. This ability is related to rushing, in the parlance of distributed-computation literature.

Accordingly, in this section, we introduce a new BA protocol, BA⋆, for SC networks and ignoring the issue of player replaceability altogether. The protocol BA⋆is a contribution of separate value. Indeed, it is the most efficient cryptographic BA protocol for SC networks known so far. To use it within our Algorand protocol, we modify BA⋆a bit, so as to account for our different communication model and context, but make sure, in section X, to highlight how BA⋆is used within our actual protocol Algorand ′. We start by recalling the model in which BA⋆operates and the notion of a Byzantine agreement. 3.1 Synchronous Complete Networks and Matching Adversaries In a SC network, there is a common clock, ticking at each integral times r = 1, 2, . . . At each even time click r, each player i instantaneously and simultaneously sends a single message mr i,j (possibly the empty message) to each player j, including himself. Each mr i,j is received at time click r + 1 by player j, together with the identity of the sender i. Again, in a communication protocol, a player is honest if he follows all his prescribed instructions, and malicious otherwise. All malicious players are totally controlled and perfectly coordinated by the Adversary, who, in particular, immediately receives all messages addressed to malicious players, and chooses the messages they send. The Adversary can immediately make malicious any honest user he wants at any odd time click he wants, subject only to a possible upperbound t to the number of malicious players. That is, the Adversary “cannot interfere with the messages already sent by an honest user i”, which will be delivered as usual. The Adversary also has the additional ability to see instantaneously, at each even round, the messages that the currently honest players send, and instantaneously use this information to choose the messages the malicious players send at the same time tick. Remarks • Adversary Power. The above setting is very adversarial. Indeed, in the Byzantine agreement literature, many settings are less adversarial. However, some more adversarial settings have also been considered, where the Adversary, after seeing the messages sent by an honest player i at a given time click r, has the ability to erase all these messages from the network, immediately corrupt i, choose the message that the now malicious i sends at time click r, and have them delivered as usual. The envisaged power of the Adversary matches that he has in our setting. • Physical Abstraction. The envisaged communication model abstracts a more physical model, in which each pair of players (i, j) is linked by a separate and private communication line li,j. That is, no one else can inject, interfere with, or gain information about the messages sent over li,j. The only way for the Adversary to have access to li,j is to corrupt either i or j. • Privacy and Authentication. In SC networks message privacy and authentication are guaranteed by assumption. By contrast, in our communication network, where messages are propagated from peer to peer, authentication is guaranteed by digital signatures, and privacy is non-existent. Thus, to adopt protocol BA⋆to our setting, each message exchanged should be digitally signed (further identifying the state at which it was sent). Fortunately, the BA protocols that we consider using in Algorand do not require message privacy.

3.2 The Notion of a Byzantine Agreement The notion of Byzantine agreement was introduced by Pease Shostak and Lamport [31] for the binary case, that is, when every initial value consists of a bit. However, it was quickly extended to arbitrary initial values. (See the surveys of Fischer [16] and Chor and Dwork [10].) By a BA protocol, we mean an arbitrary-value one. Definition 3.1. In a synchronous network, let \(P\) be a \(n\)-player protocol, whose player set is common knowledge among the players, \(t\) a positive integer such that \(n \geq 2t + 1\). We say that \(P\) is an arbitrary-value (respectively, binary) \((n, t)\)-Byzantine agreement protocol with soundness \(\sigma \in (0, 1)\) if, for every set of values \(V\) not containing the special symbol \(\bot\) (respectively, for \(V = \{0, 1\}\)), in an execution in which at most \(t\) of the players are malicious and in which every player \(i\) starts with an initial value \(v_i \in V\), every honest player \(j\) halts with probability 1, outputting a value \(\text{out}_i \in V \cup \{\bot\}\) so as to satisfy, with probability at least \(\sigma\), the following two conditions: 1. Agreement: There exists \(\text{out} \in V \cup \{\bot\}\) such that \(\text{out}_i = \text{out}\) for all honest players \(i\). 2. Consistency: if, for some value \(v \in V\), \(v_i = v\) for all honest players, then \(\text{out} = v\). We refer to out as P’s output, and to each outi as player i’s output. 3.3 The BA Notation # In our BA protocols, a player is required to count how many players sent him a given message in a given step. Accordingly, for each possible value \(v\) that might be sent, \(\#_i^s(v)\) (or just \(\#_i(v)\) when \(s\) is clear) is the number of players \(j\) from which \(i\) has received \(v\) in step \(s\). 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\), \(\sum_v \#_i^s(v) = n\). 3.4 The Binary BA Protocol BBA⋆ In this section we present a new binary BA protocol, BBA⋆, which relies on the honesty of more than two thirds of the players and is very fast: no matter what the malicious players might do, each execution of its main loop brings the players into agreement with probability 1/3. Each player has his own public key of a digital signature scheme satisfying the unique-signature property. Since this protocol is intended to be run on synchronous complete network, there is no need for a player i to sign each of his messages. Digital signatures are used to generate a sufficiently common random bit in Step 3. (In Algorand, digital signatures are used to authenticate all other messages as well.) The protocol requires a minimal set-up: a common random string r, independent of the players’ keys. (In Algorand, r is actually replaced by the quantity Qr.) Protocol BBA⋆is a 3-step loop, where the players repeatedly exchange Boolean values, and different players may exit this loop at different times. A player i exits this loop by propagating, at some step, either a special value 0∗or a special value 1∗, thereby instructing all players to “pretend” they respectively receive 0 and 1 from i in all future steps. (Alternatively said: assume

that the last message received by a player j from another player i was a bit b. Then, in any step in which he does not receive any message from i, j acts as if i sent him the bit b.) The protocol uses a counter \(\gamma\), representing how many times its 3-step loop has been executed. At the start of BBA⋆, \(\gamma = 0\). (One may think of \(\gamma\) as a global counter, but it is actually increased by each individual player every time that the loop is executed.) There are \(n \geq 3t + 1\), where \(t\) is the maximum possible number of malicious players. A binary string \(x\) is identified with the integer whose binary representation (with possible leadings 0s) is \(x\); and \(\text{lsb}(x)\) denotes the least significant bit of \(x\). Protocol BBA⋆ (Communication) Step 1. [Coin-Fixed-To-0 Step] Each player \(i\) sends \(b_i\). 1.1 If \(\#_i^1(0) \geq 2t + 1\), then \(i\) sets \(b_i = 0\), sends \(0^*\), outputs \(\text{out}_i = 0\), and HALTS. 1.2 If \(\#_i^1(1) \geq 2t + 1\), then \(i\) sets \(b_i = 1\). 1.3 Else, \(i\) sets \(b_i = 0\). (Communication) Step 2. [Coin-Fixed-To-1 Step] Each player \(i\) sends \(b_i\). 2.1 If \(\#_i^2(1) \geq 2t + 1\), then \(i\) sets \(b_i = 1\), sends \(1^*\), outputs \(\text{out}_i = 1\), and HALTS. 2.2 If \(\#_i^2(0) \geq 2t + 1\), then \(i\) sets \(b_i = 0\). 2.3 Else, \(i\) sets \(b_i = 1\). (Communication) Step 3. [Coin-Genuinely-Flipped Step] Each player \(i\) sends \(b_i\) and \(\text{SIG}_i(r, \gamma)\). 3.1 If \(\#_i^3(0) \geq 2t + 1\), then \(i\) sets \(b_i = 0\). 3.2 If \(\#_i^3(1) \geq 2t + 1\), then \(i\) sets \(b_i = 1\). 3.3 Else, letting \(S_i = \{j \in N \text{ who have sent } i \text{ a proper message in this step 3}\}\), \(i\) sets \(b_i = c \triangleq \text{lsb}(\min_{j \in S_i} H(\text{SIG}_i(r, \gamma)))\); increases \(\gamma_i\) by 1; and returns to Step 1. Theorem 3.1. Whenever \(n \geq 3t + 1\), BBA⋆ is a binary \((n, t)\)-BA protocol with soundness 1. A proof of Theorem 3.1 is given in [26]. Its adaptation to our setting, and its player-replaceability property are novel. Historical Remark Probabilistic binary BA protocols were first proposed by Ben-Or in asynchronous settings [7]. Protocol BBA⋆is a novel adaptation, to our public-key setting, of the binary BA protocol of Feldman and Micali [15]. Their protocol was the first to work in an expected constant number of steps. It worked by having the players themselves implement a common coin, a notion proposed by Rabin, who implemented it via an external trusted party [32].

3.5 Graded Consensus and the Protocol GC Let us recall, for arbitrary values, a notion of consensus much weaker than Byzantine agreement. Definition 3.2. Let P be a protocol in which the set of all players is common knowledge, and each player i privately knows an arbitrary initial value v′ i. We say that \(P\) is an \((n, t)\)-graded consensus protocol if, in every execution with \(n\) players, at most \(t\) of which are malicious, every honest player \(i\) halts outputting a value-grade pair \((v_i, g_i)\), where \(g_i \in \{0, 1, 2\}\), so as to satisfy the following three conditions: 1. For all honest players \(i\) and \(j\), \(|g_i - g_j| \leq 1\). 2. For all honest players \(i\) and \(j\), \(g_i, g_j > 0 \Rightarrow v_i = v_j\). 3. If \(v'_1 = \cdots = v'_n = v\) for some value \(v\), then \(v_i = v\) and \(g_i = 2\) for all honest players \(i\). Historical Note The notion of a graded consensus is simply derived from that of a graded broadcast, put forward by Feldman and Micali in [15], by strengthening the notion of a crusader agreement, as introduced by Dolev [12], and refined by Turpin and Coan [33].8 In [15], the authors also provided a 3-step (n, t)-graded broadcasting protocol, gradecast, for \(n \geq 3t + 1\). A more complex \((n, t)\)-graded-broadcasting protocol for \(n > 2t + 1\) has later been found by Katz and Koo [19]. The following two-step protocol GC consists of the last two steps of gradecast, expressed in our notation. To emphasize this fact, and to match the steps of protocol Algorand ′ of section 4.1, we respectively name 2 and 3 the steps of GC. Protocol GC Step 2. Each player i sends v′ i to all players. Step 3. Each player \(i\) sends to all players the string \(x\) if and only if \(\#_i^2(x) \geq 2t + 1\). Output Determination. Each player \(i\) outputs the pair \((v_i, g_i)\) computed as follows: • If, for some \(x\), \(\#_i^3(x) \geq 2t + 1\), then \(v_i = x\) and \(g_i = 2\). • If, for some \(x\), \(\#_i^3(x) \geq t + 1\), then \(v_i = x\) and \(g_i = 1\). • Else, \(v_i = \bot\) and \(g_i = 0\). Theorem 3.2. If \(n \geq 3t + 1\), then GC is a \((n, t)\)-graded broadcast protocol. The proof immediately follows from that of the protocol gradecast in [15], and is thus omitted.9 8In essence, in a graded-broadcasting protocol, (a) the input of every player is the identity of a distinguished player, the sender, who has an arbitrary value v as an additional private input, and (b) the outputs must satisfy the same properties 1 and 2 of graded consensus, plus the following property 3′: if the sender is honest, then vi = v and gi = 2 for all honest player i. 9Indeed, in their protocol, in step 1, the sender sends his own private value v to all players, and each player i lets v′ i consist of the value he has actually received from the sender in step 1.

3.6 The Protocol BA⋆ We now describe the arbitrary-value BA protocol BA⋆via the binary BA protocol BBA⋆and the graded-consensus protocol GC. Below, the initial value of each player i is v′ i. Protocol BA⋆ Steps 1 and 2. Each player i executes GC, on input v′ i, so as to compute a pair (vi, gi). Step 3, . . . Each player i executes BBA⋆—with initial input 0, if gi = 2, and 1 otherwise— so as to compute the bit outi. Output Determination. Each player \(i\) outputs \(v_i\), if \(\text{out}_i = 0\), and \(\bot\) otherwise. Theorem 3.3. Whenever \(n \geq 3t + 1\), BA⋆ is a \((n, t)\)-BA protocol with soundness 1. Proof. We first prove Consistency, and then Agreement. Proof of Consistency. Assume that, for some value \(v \in V\), \(v'\) i = v. Then, by property 3 of graded consensus, after the execution of GC, all honest players output (v, 2). Accordingly, 0 is the initial bit of all honest players in the end of the execution of BBA⋆. Thus, by the Agreement property of binary Byzantine agreement, at the end of the execution of BA⋆, outi = 0 for all honest players. This implies that the output of each honest player i in BA⋆is vi = v. ✷ Proof of Agreement. Since BBA⋆is a binary BA protocol, either (A) outi = 1 for all honest player i, or (B) outi = 0 for all honest player i. In case A, all honest players output \(\bot\) in BA⋆, and thus Agreement holds. Consider now case B. In this case, in the execution of BBA⋆, the initial bit of at least one honest player i is 0. (Indeed, if initial bit of all honest players were 1, then, by the Consistency property of BBA⋆, we would have outj = 1 for all honest j.) Accordingly, after the execution of GC, i outputs the pair (v, 2) for some value v. Thus, by property 1 of graded consensus, gj > 0 for all honest players j. Accordingly, by property 2 of graded consensus, vj = v for all honest players j. This implies that, at the end of BA⋆, every honest player j outputs v. Thus, Agreement holds also in case B. ✷ Since both Consistency and Agreement hold, BA⋆is an arbitrary-value BA protocol. Historical Note Turpin and Coan were the first to show that, for \(n \geq 3t + 1\), any binary \((n, t)\)-BA protocol can be converted to an arbitrary-value (n, t)-BA protocol. The reduction arbitrary-value Byzantine agreement to binary Byzantine agreement via graded consensus is more modular and cleaner, and simplifies the analysis of our Algorand protocol Algorand ′. Generalizing BA⋆for use in Algorand Algorand works even when all communication is via gossiping. However, although presented in a traditional and familiar communication network, so as to enable a better comparison with the prior art and an easier understanding, protocol BA⋆works also in gossiping networks. In fact, in our detailed embodiments of Algorand, we shall present it directly for gossiping networks. We shall also point out that it satisfies the player replaceability property that is crucial for Algorand to be secure in the envisaged very adversarial model.

Any BA player-replaceable protocol working in a gossiping communication network can be securely employed within the inventive Algorand system. In particular, Micali and Vaikunthanatan have extended BA⋆to work very efficiently also with a simple majority of honest players. That protocol too could be used in Algorand.

O protocolo BA BA⋆ em um ambiente tradicional

Como já enfatizado, o acordo bizantino é um ingrediente chave de Algorand. Na verdade, é através o uso de um protocolo BA que Algorand não seja afetado por bifurcações. No entanto, para estarmos seguros contra os nossos Adversário poderoso, Algorand deve contar com um protocolo BA que satisfaça a nova capacidade de substituição do jogador restrição. Além disso, para que Algorand seja eficiente, tal protocolo BA deve ser muito eficiente. Os protocolos BA foram definidos pela primeira vez para um modelo de comunicação idealizado, síncrono completo redes (redes SC). Tal modelo permite um projeto e análise mais simples de protocolos BA. 6Dada a porcentagem honesta h e a probabilidade de falha aceitável F, Algorand calcula um limite superior, N, ao número máximo de membros dos verificadores em uma etapa. Assim, a suposição de MP só precisa ser válida para n \(\leq\)N. Além disso, como afirmado, a suposição de MP é válida, não importa quantas outras mensagens possam ser propagadas ao lado o mj. Como veremos, entretanto, em Algorand as mensagens são propagadas em tempo essencialmente não sobreposto intervalos, durante os quais um único bloco é propagado, ou no máximo N verificadores propagam um pequeno (por exemplo, 200B) mensagem. Assim, poderíamos reafirmar o pressuposto do MP de uma forma mais fraca, mas também mais complexa. 7Por exemplo, ele pode aprender imediatamente as mensagens enviadas por jogadores honestos. Assim, um usuário malicioso i′, que é solicitado a propagar uma mensagem simultaneamente com um usuário honesto i, pode sempre escolher sua própria mensagem m′ com base em a mensagem m realmente propagada por i. Essa habilidade está relacionada à pressa, no jargão da computação distribuída literatura.Assim, nesta seção, apresentamos um novo protocolo BA, BA⋆, para redes SC e ignorando a questão da substituibilidade do jogador. O protocolo BA⋆é uma contribuição de valor separado. Na verdade, é o protocolo BA criptográfico mais eficiente para redes SC conhecido até agora. Para usá-lo em nosso protocolo Algorand, modificamos BA⋆ um pouco, de modo a levar em conta nossos diferentes modelo de comunicação e contexto, mas certifique-se, na seção X, de destacar como BA⋆é usado dentro do nosso protocolo real Algorand ′. Começamos por relembrar o modelo em que BA⋆opera e a noção de acordo bizantino. 3.1 Redes Síncronas Completas e Adversários Correspondentes Em uma rede SC, existe um relógio comum, marcando a cada tempo integral r = 1, 2, . . . A cada clique par em r, cada jogador i envia instantânea e simultaneamente um único mensagem senhor i,j (possivelmente a mensagem vazia) para cada jogador j, incluindo ele mesmo. Cada senhor i,j é recebido naquele momento clique em r + 1 do jogador j, junto com a identidade do remetente i. Novamente, num protocolo de comunicação, um jogador é honesto se seguir todas as instruções prescritas. instruções e malicioso de outra forma. Todos os jogadores maliciosos são totalmente controlados e perfeitamente coordenado pelo Adversário, que, em particular, recebe imediatamente todas as mensagens dirigidas a jogadores maliciosos e escolhe as mensagens que eles enviam. O Adversário pode imediatamente tornar malicioso qualquer usuário honesto que ele quiser, a qualquer momento, clicar ele deseja, sujeito apenas a um possível limite máximo para o número de jogadores mal-intencionados. Isto é, o Adversário “não pode interferir nas mensagens já enviadas por um usuário honesto i”, o que será entregue normalmente. O Adversário também tem a capacidade adicional de ver instantaneamente, em cada rodada par, o mensagens que os jogadores atualmente honestos enviam e usam instantaneamente essas informações para escolher as mensagens que os jogadores maliciosos enviam ao mesmo tempo são marcadas. Observações • Poder Adversário. A configuração acima é muito contraditória. Na verdade, no acordo bizantino literatura, muitos ambientes são menos antagônicos. No entanto, algumas configurações mais adversárias também foi considerado, onde o Adversário, após ver as mensagens enviadas por um jogador honesto, em um determinado momento clique em r, tem a capacidade de apagar todas essas mensagens da rede, imediatamente corrupto i, escolha a mensagem que o agora malicioso i envia na hora clique em r, e faça com que eles entregue normalmente. O poder previsto do Adversário corresponde ao que ele tem em nosso cenário. • Abstração Física. O modelo de comunicação previsto abstrai um modelo mais físico, em que cada par de jogadores (i, j) está ligado por uma linha de comunicação separada e privada li,j. Ou seja, ninguém mais pode injetar, interferir ou obter informações sobre as mensagens enviadas. li, j. A única maneira de o Adversário ter acesso a li,j é corromper i ou j. • Privacidade e Autenticação. Nas redes SC a privacidade e a autenticação das mensagens são garantidas por suposição. Por outro lado, na nossa rede de comunicação, onde as mensagens são propagadas ponto a ponto, a autenticação é garantida por assinaturas digitais e a privacidade é inexistente. Assim, para adotar o protocolo BA⋆ ao nosso cenário, cada mensagem trocada deverá ser assinada digitalmente (identificando ainda o estado para o qual foi enviado). Felizmente, os protocolos BA que usamos considere usar em Algorand não requer privacidade de mensagem.3.2 A noção de um acordo bizantino A noção de acordo bizantino foi introduzida por Pease Shostak e Lamport [31] para o caso binário, isto é, quando todo valor inicial consiste em um bit. No entanto, foi rapidamente prorrogado para valores iniciais arbitrários. (Veja as pesquisas de Fischer [16] e Chor e Dwork [10].) Por um BA protocolo, queremos dizer um de valor arbitrário. Definição 3.1. Em uma rede síncrona, seja P um protocolo de n jogadores, cujo conjunto de jogadores é comum conhecimento entre os jogadores, t um número inteiro positivo tal que n \(\geq\)2t + 1. Dizemos que P é um valor arbitrário (respectivamente, binário) (n, t) - Protocolo de acordo bizantino com solidez \(\sigma\) \(\in\) (0, 1) se, para cada conjunto de valores V que não contém o símbolo especial \(\bot\) (respectivamente, para V = {0, 1}), em um execução em que no máximo t dos jogadores são maliciosos e em que cada jogador i começa com um valor inicial vi \(\in\)V , todo jogador honesto j para com probabilidade 1, gerando um valor outi \(\in\)V \(\cup\){\(\bot\)} de modo a satisfazer, com probabilidade pelo menos \(\sigma\), as duas condições seguintes: 1. Acordo: Existe out \(\in\)V \(\cup\){\(\bot\)} tal que outi = out para todos os jogadores honestos i. 2. Consistência: se, para algum valor v \(\in\)V , vi = v para todos os jogadores honestos, então out = v. Referimo-nos a out como saída de P e a cada outi como saída do jogador i. 3.3 A notação BA # Em nossos protocolos BA, um jogador é obrigado a contar quantos jogadores lhe enviaram uma determinada mensagem em um determinado passo. Assim, para cada valor possível v que possa ser enviado,

s

eu(v) (ou apenas #i(v) quando s estiver limpo) é o número de jogadores j dos quais i recebeu v na etapa s. Lembrando que um jogador i recebe exatamente uma mensagem de cada jogador j, se o número de jogadores é n, então, para todos i e s, P v#s eu(v) = n. 3.4 O Protocolo Binário BA BBA⋆ Nesta seção apresentamos um novo protocolo BA binário, BBA⋆, que depende da honestidade de mais mais de dois terços dos jogadores e é muito rápido: não importa o que os jogadores maliciosos possam fazer, cada execução de seu loop principal faz com que os jogadores concordem com a probabilidade 1/3. Cada jogador tem sua própria chave pública de um esquema de assinatura digital que satisfaz a assinatura única. propriedade. Como este protocolo se destina a ser executado em rede completa síncrona, não há necessidade de um jogador assinar cada uma de suas mensagens. Assinaturas digitais são usadas para gerar um bit aleatório suficientemente comum na Etapa 3. (Em Algorand, assinaturas digitais também são usadas para autenticar todas as outras mensagens.) O protocolo requer uma configuração mínima: uma string aleatória comum r, independente da posição dos jogadores. chaves. (Em Algorand, r é na verdade substituído pela quantidade Qr.) O protocolo BBA⋆é um loop de 3 etapas, onde os jogadores trocam repetidamente valores booleanos e diferentes jogadores podem sair deste ciclo em momentos diferentes. Um jogador i sai deste loop propagando, em alguma etapa, um valor especial 0∗ou um valor especial 1∗, instruindo assim todos os jogadores a “fingir” que recebem respectivamente 0 e 1 de i em todas as etapas futuras. (Alternativamente dito: assumirque a última mensagem recebida por um jogador j de outro jogador i foi um pouco b. Então, em qualquer passo em que ele não recebe nenhuma mensagem de i, j age como se eu tivesse enviado a ele o bit b.) O protocolo utiliza um contador \(\gamma\), representando quantas vezes seu loop de 3 etapas foi executado. No início do BBA⋆, \(\gamma\) = 0. (Pode-se pensar em \(\gamma\) como um contador global, mas na verdade é aumentado por cada jogador individual toda vez que o loop é executado.) Existem n \(\geq\)3t + 1, onde t é o número máximo possível de jogadores maliciosos. Um binário a string x é identificada com o inteiro cuja representação binária (com possíveis 0s iniciais) é x; e lsb(x) denota o bit menos significativo de x. Protocolo BBA⋆ (Comunicação) Etapa 1. [Coin-Fixed-To-0 Step] Cada jogador envia bi. 1.1 Se #1 i (0) \(\geq\)2t + 1, então i define bi = 0, envia 0∗, gera outi = 0, e PARA. 1.2 Se #1 i (1) \(\geq\)2t + 1, então, então i define bi = 1. 1.3 Caso contrário, i define bi = 0. (Comunicação) Etapa 2. [Coin-Fixed-To-1 Step] Cada jogador envia bi. 2.1 Se #2 i (1) \(\geq\)2t + 1, então i define bi = 1, envia 1∗, saídas outi = 1, e PARA. 2.2 Se #2 i (0) \(\geq\)2t + 1, então defino bi = 0. 2.3 Caso contrário, i define bi = 1. (Comunicação) Etapa 3. [Etapa da Moeda Genuinamente Invertida] Cada jogador i envia bi e SIGi(r, \(\gamma\)). 3.1 Se #3 i (0) \(\geq\)2t + 1, então i define bi = 0. 3.2 Se #3 i (1) \(\geq\)2t + 1, então i define bi = 1. 3.3 Caso contrário, deixando Si = {j \(\in\)N que enviou i uma mensagem adequada nesta etapa 3}, i define bi = c \(\triangleq\)lsb(minj\(\in\)Si H(SIGi(r, \(\gamma\)))); aumenta \(\gamma\)i em 1; e retorna ao Passo 1. Teorema 3.1. Sempre que n \(\geq\)3t + 1, BBA⋆é um protocolo binário (n, t)-BA com solidez 1. Uma prova do Teorema 3.1 é dada em [26]. Sua adaptação ao nosso ambiente e sua capacidade de substituição do jogador propriedade são novos. Observação histórica Protocolos BA binários probabilísticos foram propostos pela primeira vez por Ben-Or em configurações assíncronas [7]. O protocolo BBA⋆é uma nova adaptação, para nossa configuração de chave pública, do protocolo BA binário de Feldman e Micali [15]. Seu protocolo foi o primeiro a funcionar da maneira esperada. número constante de etapas. Funcionou fazendo com que os próprios jogadores implementassem uma moeda comum, uma noção proposta por Rabin, que a implementou por meio de uma parte externa confiável [32].3.5 Consenso Graduado e Protocolo GC Recordemos, para valores arbitrários, uma noção de consenso muito mais fraca do que o acordo bizantino. Definição 3.2. Seja P um protocolo no qual o conjunto de todos os jogadores é de conhecimento comum, e cada jogador i conhece em particular um valor inicial arbitrário v′ eu. Dizemos que P é um protocolo de consenso com classificação (n, t) se, em cada execução com n jogadores, em a maioria dos quais são maliciosos, todo jogador honesto pára de produzir um par de valor-grau (vi, gi), onde gi \(\in\){0, 1, 2}, de modo a satisfazer as três condições a seguir: 1. Para todos os jogadores honestos i e j, |gi −gj| \(\leq\)1. 2. Para todos os jogadores honestos i e j, gi, gj > 0 ⇒vi = vj. 3. Se v′ 1 = \(\cdots\) =v′ n = v para algum valor v, então vi = v e gi = 2 para todos os jogadores honestos i. Nota Histórica A noção de consenso graduado é simplesmente derivada daquela de consenso graduado. transmitido, apresentado por Feldman e Micali em [15], ao fortalecer a noção de um cruzado acordo, conforme introduzido por Dolev [12], e refinado por Turpin e Coan [33].8 Em [15], os autores também forneceram um protocolo de transmissão graduado em 3 etapas (n, t), gradecast, para n \(\geq\)3t+1. Um protocolo de transmissão graduado (n, t) mais complexo para n> 2t + 1 foi encontrado posteriormente por Katz e Koo [19]. O seguinte protocolo GC de duas etapas consiste nas duas últimas etapas do gradecast, expressas em nosso notação. Para enfatizar este fato, e para corresponder às etapas do protocolo Algorand ′ da seção 4.1, nós nomeie respectivamente 2 e 3 as etapas do GC. Protocolo GC Passo 2. Cada jogador envia v′ eu para todos os jogadores. Etapa 3. Cada jogador i envia a todos os jogadores a string x se e somente se #2 eu(x) \(\geq\)2t + 1. Determinação de saída. Cada jogador i gera o par (vi, gi) calculado da seguinte forma: • Se, para algum x, #3 i (x) \(\geq\)2t + 1, então vi = x e gi = 2. • Se, para algum x, #3 eu (x) \(\geq\)t + 1, então vi = x e gi = 1. • Caso contrário, vi = \(\bot\) e gi = 0. Teorema 3.2. Se n \(\geq\)3t + 1, então GC é um protocolo de transmissão com classificação (n, t). A prova segue imediatamente aquela da classificação do protocolo em [15] e, portanto, é omitida.9 8Em essência, num protocolo de transmissão gradual, (a) a entrada de cada jogador é a identidade de um distinto jogador, o remetente, que tem um valor arbitrário v como uma entrada privada adicional, e (b) as saídas devem satisfazer o mesmas propriedades 1 e 2 do consenso graduado, mais a seguinte propriedade 3′: se o remetente for honesto, então vi = v e gi = 2 para todos os jogadores honestos i. 9Na verdade, no protocolo deles, na etapa 1, o remetente envia seu próprio valor privado v para todos os jogadores, e cada jogador i deixa v' consisto no valor que ele realmente recebeu do remetente na etapa 1.3.6 O Protocolo BA⋆ Descrevemos agora o protocolo BA de valor arbitrário BA⋆por meio do protocolo BA binário BBA⋆e o protocolo de consenso graduado GC. Abaixo, o valor inicial de cada jogador i é v′ eu. Protocolo BA⋆ Etapas 1 e 2. Cada jogador i executa GC, na entrada v′ i, para calcular um par (vi, gi). Etapa 3, . . . Cada jogador i executa BBA⋆ - com entrada inicial 0, se gi = 2, e 1 caso contrário - então como calcular o bit outi. Determinação de saída. Cada jogador i gera vi, se outi = 0, e \(\bot\)caso contrário. Teorema 3.3. Sempre que n \(\geq\)3t + 1, BA⋆é um protocolo (n, t)-BA com solidez 1. Prova. Primeiro provamos a consistência e depois a concordância. Prova de consistência. Suponha que, para algum valor v \(\in\)V , v′ i = v. Então, pela propriedade 3 de consenso graduado, após a execução do GC, todos os jogadores honestos produzem (v, 2). Assim, 0 é a parte inicial de todos os jogadores honestos no final da execução do BBA⋆. Assim, pelo Acordo propriedade do acordo bizantino binário, ao final da execução de BA⋆, outi = 0 para todos os honestos jogadores. Isto implica que a saída de cada jogador honesto i em BA⋆é vi = v. ✷ Prova de acordo. Como BBA⋆é um protocolo BA binário, (A) outi = 1 para todo jogador honesto i, ou (B) outi = 0 para todos os jogadores honestos i. No caso A, todos os jogadores honestos produzem \(\bot\)em BA⋆ e, portanto, o acordo é válido. Considere agora o caso B. Em neste caso, na execução de BBA⋆, o bit inicial de pelo menos um jogador honesto i é 0. (Na verdade, se inicial de todos os jogadores honestos fosse 1, então, pela propriedade Consistência do BBA⋆, teríamos outj = 1 para todos os j honestos.) Assim, após a execução do GC, i gera o par (v, 2) para alguns valor v. Assim, pela propriedade 1 do consenso graduado, gj > 0 para todos os jogadores honestos j. Assim, por propriedade 2 do consenso graduado, vj = v para todos os jogadores honestos j. Isto implica que, no final do BA⋆, todo jogador honesto j produz v. Assim, o acordo também é válido no caso B. ✷ Como tanto a Consistência quanto o Acordo são válidos, BA⋆é um protocolo BA de valor arbitrário. Nota Histórica Turpin e Coan foram os primeiros a mostrar que, para n \(\geq\)3t+1, qualquer binário (n, t)-BA O protocolo pode ser convertido em um protocolo de valor arbitrário (n, t)-BA. O valor arbitrário de redução O acordo bizantino para o acordo bizantino binário via consenso gradual é mais modular e mais limpo e simplifica a análise do nosso protocolo Algorand Algorand ′. Generalizando BA⋆para uso em Algorand Algorand funciona mesmo quando toda a comunicação é via fofocando. Contudo, embora apresentado numa rede de comunicação tradicional e familiar, por assim dizer para permitir uma melhor comparação com o estado da técnica e uma compreensão mais fácil, o protocolo BA⋆works também em redes de fofoca. Na verdade, em nossas concretizações detalhadas de Algorand, iremos apresentá-lo diretamente para redes de fofocas. Devemos também salientar que satisfaz a substituibilidade do jogador propriedade que é crucial para que Algorand esteja seguro no modelo muito adversário previsto.

Qualquer protocolo substituível por jogador BA trabalhando em uma rede de comunicação de fofoca pode ser empregado com segurança dentro do sistema inventivo Algorand. Em particular, Micali e Vaikunthanatan estenderam o BA⋆ para trabalhar de forma muito eficiente também com uma maioria simples de jogadores honestos. Isso o protocolo também pode ser usado em Algorand.

Two Embodiments of Algorand

Two Embodiments of Algorand

As discussed, at a very high level, a round of Algorand ideally proceeds 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 Byzantine agreement on the block proposed by the leader. (This process includes that each step of the BA protocol is run by a separately selected committee.) The agreed upon block is then digitally signed by a given threshold (\(t_H\)) of committee members. These digital signatures are circulated so that everyone is assured of which is the new block. (This includes circulating the credential of the signers, and authenticating just the hash of the new block, ensuring that everyone is guaranteed to learn the block, once its hash is made clear.) In the next two sections, we present two embodiments of Algorand, \(\text{Algorand}'_1\) and \(\text{Algorand}'_2\), that work under a majority-of-honest-users assumption. In Section 8 we show how to adopts these embodiments to work under a honest-majority-of-money assumption. \(\text{Algorand}'_1\) only envisages that \(> 2/3\) of the committee members are honest. In addition, in \(\text{Algorand}'_1\), the number of steps for reaching Byzantine agreement is capped at a suitably high number, so that agreement is guaranteed to be reached with overwhelming probability within a fixed number of steps (but potentially requiring longer time than the steps of \(\text{Algorand}'_2\)). In the remote case in which agreement is not yet reached by the last step, the committee agrees on the empty block, which is always valid. \(\text{Algorand}'_2\) envisages that the number of honest members in a committee is always greater than or equal to a fixed threshold \(t_H\) (which guarantees that, with overwhelming probability, at least \(2/3\) of the committee members are honest). In addition, \(\text{Algorand}'_2\) allows Byzantine agreement to be reached in an arbitrary number of steps (but potentially in a shorter time than \(\text{Algorand}'_1\)). It is easy to derive many variants of these basic embodiments. In particular, it is easy, given \(\text{Algorand}'_2\), to modify \(\text{Algorand}'_1\) so as to enable to reach Byzantine agreement in an arbitrary number of steps. Both embodiments share the following common core, notations, notions, and parameters. 4.1 A Common Core Objectives Ideally, for each round \(r\), Algorand would satisfy the following properties: 1. Perfect Correctness. All honest users agree on the same block \(B_r\). 2. Completeness 1. With probability 1, the payset of \(B_r\), \(PAY^r\), is maximal.10 10Because paysets are defined to contain valid payments, and honest users to make only valid payments, a maximal \(PAY^r\) contains the "currently outstanding" payments of all honest users.

Of course, guaranteeing perfect correctness alone is trivial: everyone always chooses the official payset \(PAY^r\) to be empty. But in this case, the system would have completeness 0. Unfortunately, guaranteeing both perfect correctness and completeness 1 is not easy in the presence of malicious users. Algorand thus adopts a more realistic objective. Informally, letting \(h\) denote the percentage of users who are honest, \(h > 2/3\), the goal of Algorand is Guaranteeing, with overwhelming probability, perfect correctness and completeness close to \(h\). Privileging correctness over completeness seems a reasonable choice: payments not processed in one round can be processed in the next, but one should avoid forks, if possible. Led Byzantine Agreement Perfect Correctness could be guaranteed as follows. At the start of round \(r\), each user \(i\) constructs his own candidate block \(B^r_i\), and then all users reach Byzantine agreement on one candidate block. As per our introduction, the BA protocol employed requires a \(2/3\) honest majority and is player replaceable. Each of its step can be executed by a small and randomly selected set of verifiers, who do not share any inner variables. Unfortunately, this approach has no completeness guarantees. This is so, because the candidate blocks of the honest users are most likely totally different from each other. Thus, the ultimately agreed upon block might always be one with a non-maximal payset. In fact, it may always be the empty block, \(B_\varepsilon\), that is, the block whose payset is empty. well be the default, empty one. \(\text{Algorand}'\) avoids this completeness problem as follows. First, a leader for round \(r\), \(\ell_r\), is selected. Then, \(\ell_r\) propagates his own candidate block, \(B^r_{\ell_r}\). Finally, the users reach agreement on the block they actually receive from \(\ell_r\). Because, whenever \(\ell_r\) is honest, Perfect Correctness and Completeness 1 both hold, \(\text{Algorand}'\) ensures that \(\ell_r\) is honest with probability close to \(h\). (When the leader is malicious, we do not care whether the agreed upon block is one with an empty payset. After all, a malicious leader \(\ell_r\) might always maliciously choose \(B^r_{\ell_r}\) to be the empty block, and then honestly propagate it, thus forcing the honest users to agree on the empty block.) Leader Selection In Algorand's, the \(r\)th block is of the form \(B_r = (r, PAY^r, Q_r, H(B_{r-1})\). As already mentioned in the introduction, the quantity \(Q_{r-1}\) is carefully constructed so as to be essentially non-manipulatable by our very powerful Adversary. (Later on in this section, we shall provide some intuition about why this is the case.) At the start of a round \(r\), all users know the blockchain so far, \(B_0, \ldots, B_{r-1}\), from which they deduce the set of users of every prior round: that is, \(PK^1, \ldots, PK^{r-1}\). A potential leader of round \(r\) is a user \(i\) such that \[.\!H\!\left(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\right) \leq p.\] Let us explain. Note that, since the quantity \(Q_{r-1}\) is part of block \(B_{r-1}\), and the underlying signature scheme satisfies the uniqueness property, \(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\) is a binary string uniquely associated to \(i\) and \(r\). Thus, since \(H\) is a random oracle, \(H\!\left(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\right)\) is a random 256-bit long string uniquely associated to \(i\) and \(r\). The symbol "." in front of \(H\!\left(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\right)\) is the decimal (in our case, binary) point, so that \(r_i \triangleq .\!H\!\left(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\right)\) is the binary expansion of a random 256-bit number between 0 and 1 uniquely associated to \(i\) and \(r\). Thus the probability that \(r_i\) is less than or equal to \(p\) is essentially \(p\). (Our potential-leader selection mechanism has been inspired by the micro-payment scheme of Micali and Rivest [28].) The probability \(p\) is chosen so that, with overwhelming (i.e., \(1 - F\)) probability, at least one potential verifier is honest. (If fact, \(p\) is chosen to be the smallest such probability.)

Note that, since \(i\) is the only one capable of computing his own signatures, he alone can determine whether he is a potential verifier of round 1. However, by revealing his own credential, \(\sigma^r_i \triangleq \text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\), \(i\) can prove to anyone to be a potential verifier of round \(r\). The leader \(\ell_r\) is defined to be the potential leader whose hashed credential is smaller that the hashed credential of all other potential leader \(j\): that is, \(H(\sigma^{r,s}_{\ell_r}) \leq H(\sigma^{r,s}_j)\). Note that, since a malicious \(\ell_r\) may not reveal his credential, the correct leader of round \(r\) may never be known, and that, barring improbable ties, \(\ell_r\) is indeed the only leader of round \(r\). Let us finally bring up a last but important detail: a user \(i\) can be a potential leader (and thus the leader) of a round \(r\) only if he belonged to the system for at least \(k\) rounds. This guarantees the non-manipulatability of \(Q_r\) and all future Q-quantities. In fact, one of the potential leaders will actually determine \(Q_r\). Verifier Selection Each step \(s > 1\) of round \(r\) is executed by a small set of verifiers, \(SV^{r,s}\). Again, each verifier \(i \in SV^{r,s}\) is randomly selected among the users already in the system \(k\) rounds before \(r\), and again via the special quantity \(Q_{r-1}\). Specifically, \(i \in PK^{r-k}\) is a verifier in \(SV^{r,s}\), if \[.\!H\!\left(\text{SIG}_i\!\left(r, s, Q_{r-1}\right)\right) \leq p'.\] Once more, only \(i\) knows whether he belongs to \(SV^{r,s}\), but, if this is the case, he could prove it by exhibiting his credential \(\sigma^{r,s}_i \triangleq H(\text{SIG}_i\!\left(r, s, Q_{r-1}\right))\). A verifier \(i \in SV^{r,s}\) sends a message, \(m^{r,s}_i\), in step \(s\) of round \(r\), and this message includes his credential \(\sigma^{r,s}_i\), so as to enable the verifiers f the nest step to recognize that \(m^{r,s}_i\) is a legitimate step-\(s\) message. The probability \(p'\) is chosen so as to ensure that, in \(SV^{r,s}\), letting \(\#good\) be the number of honest users and \(\#bad\) the number of malicious users, with overwhelming probability the following two conditions hold. For embodiment \(\text{Algorand}'_1\): (1) \(\#good > 2 \cdot \#bad\) and (2) \(\#good + 4 \cdot \#bad < 2n\), where \(n\) is the expected cardinality of \(SV^{r,s}\). For embodiment \(\text{Algorand}'_2\): (1) \(\#good > t_H\) and (2) \(\#good + 2\#bad < 2t_H\), where \(t_H\) is a specified threshold. These conditions imply that, with sufficiently high probability, (a) in the last step of the BA protocol, there will be at least given number of honest players to digitally sign the new block \(B_r\), (b) only one block per round may have the necessary number of signatures, and (c) the used BA protocol has (at each step) the required \(2/3\) honest majority. Clarifying Block Generation If the round-\(r\) leader \(\ell_r\) is honest, then the corresponding block is of the form \[B_r = \left(r,\; PAY^r,\; \text{SIG}_{\ell_r}\!\left(Q_{r-1}\right),\; H\!\left(B_{r-1}\right)\right),\] where the payset \(PAY^r\) is maximal. (recall that all paysets are, by definition, collectively valid.) Else (i.e., if \(\ell_r\) is malicious), \(B_r\) has one of the following two possible forms: \[B_r = \left(r,\; PAY^r,\; \text{SIG}_i\!\left(Q_{r-1}\right),\; H\!\left(B_{r-1}\right)\right)\] and \[B_r = B^r_\varepsilon \triangleq \left(r,\; \varnothing,\; Q_{r-1},\; H\!\left(B_{r-1}\right)\right).\]

In the first form, \(PAY^r\) is a (non-necessarily maximal) payset and it may be \(PAY^r = \varnothing\); and \(i\) is a potential leader of round \(r\). (However, \(i\) may not be the leader \(\ell_r\). This may indeed happen if if \(\ell_r\) keeps secret his credential and does not reveal himself.) The second form arises when, in the round-\(r\) execution of the BA protocol, all honest players output the default value, which is the empty block \(B^r_\varepsilon\) in our application. (By definition, the possible outputs of a BA protocol include a default value, generically denoted by \(\bot\). See section 3.2.) Note that, although the paysets are empty in both cases, \(B_r = \left(r,\; \varnothing,\; \text{SIG}_i\!\left(Q_{r-1}\right),\; H\!\left(B_{r-1}\right)\right)\) and \(B^r_\varepsilon\) are syntactically different blocks and arise in two different situations: respectively, "all went smoothly enough in the execution of the BA protocol", and "something went wrong in the BA protocol, and the default value was output". Let us now intuitively describe how the generation of block \(B_r\) proceeds in round \(r\) of \(\text{Algorand}'\). In the first step, each eligible player, that is, each player \(i \in PK^{r-k}\), checks whether he is a potential leader. If this is the case, then \(i\) is asked, using of all the payments he has seen so far, and the current blockchain, \(B_0, \ldots, B_{r-1}\), to secretly prepare a maximal payment set, \(PAY^r_i\), and secretly assembles his candidate block, \(B_r = \left(r,\; PAY^r_i,\; \text{SIG}_i\!\left(Q_{r-1}\right),\; H\!\left(B_{r-1}\right)\right)\). That is, not only does he include in \(B^r_i\), as its second component the just prepared payset, but also, as its third component, his own signature of \(Q_{r-1}\), the third component of the last block, \(B_{r-1}\). Finally, he propagate his round-\(r\)-step-1 message, \(m^{r,1}_i\), which includes (a) his candidate block \(B^r_i\), (b) his proper signature of his candidate block (i.e., his signature of the hash of \(B^r_i\), and (c) his own credential \(\sigma^{r,1}_i\), proving that he is indeed a potential verifier of round \(r\). (Note that, until an honest \(i\) produces his message \(m^{r,1}_i\), the Adversary has no clue that \(i\) is a potential verifier. Should he wish to corrupt honest potential leaders, the Adversary might as well corrupt random honest players. However, once he sees \(m^{r,1}_i\), since it contains \(i\)'s credential, the Adversary knows and could corrupt \(i\), but cannot prevent \(m^{r,1}_i\), which is virally propagated, from reaching all users in the system.) In the second step, each selected verifier \(j \in SV^{r,2}\) tries to identify the leader of the round. Specifically, \(j\) takes the step-1 credentials, \(\sigma^{r,1}_{i_1}, \ldots, \sigma^{r,1}_{i_n}\), contained in the proper step-1 message \(m^{r,1}_i\) he has received; hashes all of them, that is, computes \(H\!\left(\sigma^{r,1}_{i_1}\right), \ldots, H\!\left(\sigma^{r,1}_{i_n}\right)\); finds the credential, \(\sigma^{r,1}_{\ell_j}\), whose hash is lexicographically minimum; and considers \(\ell^r_j\) to be the leader of round \(r\). Recall that each considered credential is a digital signature of \(Q_{r-1}\), that \(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right)\) is uniquely determined by \(i\) and \(Q_{r-1}\), that \(H\) is random oracle, and thus that each \(H(\text{SIG}_i\!\left(r, 1, Q_{r-1}\right))\) is a random 256-bit long string unique to each potential leader \(i\) of round \(r\). From this we can conclude that, if the 256-bit string \(Q_{r-1}\) were itself randomly and independently selected, than so would be the hashed credentials of all potential leaders of round \(r\). In fact, all potential leaders are well defined, and so are their credentials (whether actually computed or not). Further, the set of potential leaders of round \(r\) is a random subset of the users of round \(r - k\), and an honest potential leader \(i\) always properly constructs and propagates his message \(m^r_i\), which contains \(i\)'s credential. Thus, since the percentage of honest users is \(h\), no matter what the malicious potential leaders might do (e.g., reveal or conceal their own credentials), the minimum hashed potential-leader credential belongs to a honest user, who is necessarily identified by everyone to be the leader \(\ell_r\) of the round \(r\). Accordingly, if the 256-bit string \(Q_{r-1}\) were itself randomly and independently selected, with probability exactly \(h\) (a) the leader \(\ell_r\) is honest and (b) \(\ell_j = \ell_r\) for all honest step-2 verifiers \(j\). In reality, the hashed credential are, yes, randomly selected, but depend on \(Q_{r-1}\), which is

not randomly and independently selected. We shall prove in our analysis, however, that \(Q_{r-1}\) is sufficiently non-manipulatable to guarantee that the leader of a round is honest with probability \(h'\) sufficiently close to \(h\): namely, \(h' > h^2(1 + h - h^2)\). For instance, if \(h = 80\%\), then \(h' > .7424\). Having identified the leader of the round (which they correctly do when the leader \(\ell_r\) is honest), the task of the step-2 verifiers is to start executing the BA using as initial values what they believe to be the block of the leader. Actually, in order to minimize the amount of communication required, a verifier \(j \in SV^{r,2}\) does not use, as his input value \(v'_j\) to the Byzantine protocol, the block \(B_j\) that he has actually received from \(\ell_j\) (the user \(j\) believes to be the leader), but the the leader, but the hash of that block, that is, \(v'_j = H(B_i)\). Thus, upon termination of the BA protocol, the verifiers of the last step do not compute the desired round-\(r\) block \(B_r\), but compute (authenticate and propagate) \(H(B_r)\). Accordingly, since \(H(B_r)\) is digitally signed by sufficiently many verifiers of the last step of the BA protocol, the users in the system will realize that \(H(B_r)\) is the hash of the new block. However, they must also retrieve (or wait for, since the execution is quite asynchronous) the block \(B_r\) itself, which the protocol ensures that is indeed available, no matter what the Adversary might do. Asynchrony and Timing \(\text{Algorand}'_1\) and \(\text{Algorand}'_2\) have a significant degree of asynchrony. This is so because the Adversary has large latitude in scheduling the delivery of the messages being propagated. In addition, whether the total number of steps in a round is capped or not, there is the variance contribute by the number of steps actually taken. As soon as he learns the certificates of \(B_0, \ldots, B_{r-1}\), a user \(i\) computes \(Q_{r-1}\) and starts working on round \(r\), checking whether he is a potential leader, or a verifier in some step \(s\) of round \(r\). Assuming that \(i\) must act at step \(s\), in light of the discussed asynchrony, \(i\) relies on various strategies to ensure that he has sufficient information before he acts. For instance, he might wait to receive at least a given number of messages from the verifiers of the previous step, or wait for a sufficient time to ensure that he receives the messages of sufficiently many verifiers of the previous step. The Seed \(Q_r\) and the Look-Back Parameter \(k\) Recall that, ideally, the quantities \(Q_r\) should random and independent, although it will suffice for them to be sufficiently non-manipulatable by the Adversary. At a first glance, we could choose \(Q_{r-1}\) to coincide with \(H\!\left(PAY^{r-1}\right)\), and thus avoid to specify \(Q_{r-1}\) explicitly in \(B_{r-1}\). An elementary analysis reveals, however, that malicious users may take advantage of this selection mechanism.11 Some additional effort shows that myriads of other 11We are at the start of round \(r - 1\). Thus, \(Q_{r-2} = PAY^{r-2}\) is publicly known, and the Adversary privately knows who are the potential leaders he controls. Assume that the Adversary controls 10% of the users, and that, with very high probability, a malicious user \(w\) is the potential leader of round \(r - 1\). That is, assume that \(H\!\left(\text{SIG}_w\!\left(r - 2, 1, Q_{r-2}\right)\right)\) is so small that it is highly improbable an honest potential leader will actually be the leader of round \(r - 1\). (Recall that, since we choose potential leaders via a secret cryptographic sortition mechanism, the Adversary does not know who the honest potential leaders are.) The Adversary, therefore, is in the enviable position of choosing the payset \(PAY'\) he wants, and have it become the official payset of round \(r - 1\). However, he can do more. He can also ensure that, with high probability, () one of his malicious users will be the leader also of round \(r\), so that he can freely select what \(PAY^r\) will be. (And so on. At least for a long while, that is, as long as these high-probability events really occur.) To guarantee (), the Adversary acts as follows. Let \(PAY'\) be the payset the Adversary prefers for round \(r - 1\). Then, he computes \(H(PAY')\) and checks whether, for some already malicious player \(z\), \(\text{SIG}_z(r, 1, H(PAY'))\) is particularly small, that is, small enough that with very high probability \(z\) will be the leader of round \(r\). If this is the case, then he instructs \(w\) to choose his candidate block to be

alternatives, based on traditional block quantities are easily exploitable by the Adversary to ensure that malicious leaders are very frequent. We instead specifically and inductively define our brand new quantity \(Q_r\) so as to be able to prove that it is non-manipulatable by the Adversary. Namely, \(Q_r \triangleq H(\text{SIG}_{\ell_r}(Q_{r-1}), r)\), if \(B_r\) is not the empty block, and \(Q_r \triangleq H(Q_{r-1}, r)\) otherwise. The intuition of why this construction of \(Q_r\) works is as follows. Assume for a moment that \(Q_{r-1}\) is truly randomly and independently selected. Then, will so be \(Q_r\)? When \(\ell_r\) is honest the answer is (roughly speaking) yes. This is so because \[H(\text{SIG}_{\ell_r}(\cdot), r) : \{0, 1\}^{256} \longrightarrow \{0, 1\}^{256}\] is a random function. When \(\ell_r\) is malicious, however, \(Q_r\) is no longer univocally defined from \(Q_{r-1}\) and \(\ell_r\). There are at least two separate values for \(Q_r\). One continues to be \(Q_r \triangleq H(\text{SIG}_{\ell_r}(Q_{r-1}), r)\), and the other is \(H(Q_{r-1}, r)\). Let us first argue that, while the second choice is somewhat arbitrary, a second choice is absolutely mandatory. The reason for this is that a malicious \(\ell_r\) can always cause totally different candidate blocks to be received by the honest verifiers of the second step.12 Once this is the case, it is easy to ensure that the block ultimately agreed upon via the BA protocol of round \(r\) will be the default one, and thus will not contain anyone's digital signature of \(Q_{r-1}\). But the system must continue, and for this, it needs a leader for round \(r\). If this leader is automatically and openly selected, then the Adversary will trivially corrupt him. If it is selected by the previous \(Q_{r-1}\) via the same process, than \(\ell_r\) will again be the leader in round \(r+1\). We specifically propose to use the same secret cryptographic sortition mechanism, but applied to a new Q-quantity: namely, \(H(Q_{r-1}, r)\). By having this quantity to be the output of \(H\) guarantees that the output is random, and by including \(r\) as the second input of \(H\), while all other uses of \(H\) have one or 3+ inputs, "guarantees" that such a \(Q_r\) is independently selected. Again, our specific choice of alternative \(Q_r\) does not matter, what matter is that \(\ell_r\) has two choice for \(Q_r\), and thus he can double his chances to have another malicious user as the next leader. The options for \(Q_r\) may even be more numerous for the Adversary who controls a malicious \(\ell_r\). For instance, let \(x\), \(y\), and \(z\) be three malicious potential leaders of round \(r\) such that \[H\!\left(\sigma^{r,1}_x\right) < H\!\left(\sigma^{r,1}_y\right) < H\!\left(\sigma^{r,1}_z\right)\] and \(H\!\left(\sigma^{r,1}_z\right)\) is particulary small. That is, so small that there is a good chance that \(H\!\left(\sigma^{r,1}_z\right)\) is smaller of the hashed credential of every honest potential leader. Then, by asking \(x\) to hide his credential, the Adversary has a good chance of having \(y\) become the leader of round \(r - 1\). This implies that he has another option for \(Q_r\): namely, \(\text{SIG}_y\!\left(Q_{r-1}\right)\). Similarly, the Adversary may ask both \(x\) and \(y\) of withholding their credentials, so as to have \(z\) become the leader of round \(r - 1\) and gaining another option for \(Q_r\): namely, \(\text{SIG}_z\!\left(Q_{r-1}\right)\). Of course, however, each of these and other options has a non-zero chance to fail, because the Adversary cannot predict the hash of the digital signatures of the honest potential users. \(B^{r-1}_i = (r - 1, PAY', H(B_{r-2})\). Else, he has two other malicious users \(x\) and \(y\) to keep on generating a new payment \(\wp'\), from one to the other, until, for some malicious user \(z\) (or even for some fixed user \(z\)) \(H(\text{SIG}_z(PAY' \cup \{\wp\}))\) is particularly small too. This experiment will stop quite quickly. And when it does the Adversary asks \(w\) to propose the candidate block \(B^{r-1}_i = (r - 1, PAY' \cup \{\wp\}, H(B_{r-2})\). 12For instance, to keep it simple (but extreme), "when the time of the second step is about to expire", \(\ell_r\) could directly email a different candidate block \(B_i\) to each user \(i\). This way, whoever the step-2 verifiers might be, they will have received totally different blocks.

A careful, Markov-chain-like analysis shows that, no matter what options the Adversary chooses to make at round \(r - 1\), as long as he cannot inject new users in the system, he cannot decrease the probability of an honest user to be the leader of round \(r + 40\) much below \(h\). This is the reason for which we demand that the potential leaders of round \(r\) are users already existing in round \(r - k\). It is a way to ensure that, at round \(r - k\), the Adversary cannot alter by much the probability that an honest user 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 look-back parameter \(k\) ultimately is a security parameter. (Although, as we shall see in section 7, it can also be a kind of "convenience parameter" as well.) Ephemeral Keys Although the execution of our protocol cannot generate a fork, except with negligible probability, the Adversary could generate a fork, at the \(r\)th block, after the legitimate block \(r\) has been generated. Roughly, once \(B_r\) has been generated, the Adversary has learned who the verifiers of each step of round \(r\) are. Thus, he could therefore corrupt all of them and oblige them to certify a new block \(\overset{f}{B_r}\). Since this fake block might be propagated only after the legitimate one, users that have been paying attention would not be fooled.13 Nonetheless, \(\overset{f}{B_r}\) would be syntactically correct and we want to prevent from being manufactured. We do so by means of a new rule. Essentially, the members of the verifier set \(SV^{r,s}\) of a step \(s\) of round \(r\) use ephemeral public keys \(pk^{r,s}_i\) to digitally sign their messages. These keys are single-use-only and their corresponding secret keys \(sk^{r,s}_i\) are destroyed once used. This way, if a verifier is corrupted later on, the Adversary cannot force him to sign anything else he did not originally sign. Naturally, we must ensure that it is impossible for the Adversary to compute a new key \(\overset{g}{p}{}^{r,s}_i\) and convince an honest user that it is the right ephemeral key of verifier \(i \in SV^{r,s}\) to use in step \(s\). 4.2 Common Summary of Notations, Notions, and Parameters Notations - \(r \geq 0\): the current round number. - \(s \geq 1\): the current step number in round \(r\). - \(B_r\): the block generated in round \(r\). - \(PK^r\): the set of public keys by the end of round \(r - 1\) and at the beginning of round \(r\). - \(S^r\): the system status by the end of round \(r - 1\) and at the beginning of round \(r\).14 - \(PAY^r\): the payset contained in \(B_r\). - \(\ell_r\): round-\(r\) leader. \(\ell_r\) chooses the payset \(PAY^r\) of round \(r\) (and determines the next \(Q_r\)). - \(Q_r\): the seed of round \(r\), a quantity (i.e., binary string) that is generated at the end of round \(r\) and is used to choose verifiers for round \(r + 1\). \(Q_r\) is independent of the paysets in the blocks and cannot be manipulated by \(\ell_r\). 13Consider corrupting the news anchor of a major TV network, and producing and broadcasting today a newsreel showing secretary Clinton winning the last presidential election. Most of us would recognize it as a hoax. But someone getting out of a coma might be fooled. 14In a system that is not synchronous, the notion of "the end of round \(r - 1\)" and "the beginning of round \(r\)" need to be carefully defined. Mathematically, \(PK^r\) and \(S^r\) are computed from the initial status \(S^0\) and the blocks \(B_1, \ldots, B_{r-1}\).

  • \(SV^{r,s}\): the set of verifiers chosen for step \(s\) of round \(r\).
  • \(SV^r\): the set of verifiers chosen for round \(r\), \(SV^r = \cup_{s \geq 1} SV^{r,s}\).
  • \(MSV^{r,s}\) and \(HSV^{r,s}\): respectively, the set of malicious verifiers and the set of honest verifiers in \(SV^{r,s}\). \(MSV^{r,s} \cup HSV^{r,s} = SV^{r,s}\) and \(MSV^{r,s} \cap HSV^{r,s} = \varnothing\).
  • \(n_1 \in \mathbb{Z}^+\) and \(n \in \mathbb{Z}^+\): respectively, the expected numbers of potential leaders in each \(SV^{r,1}\), and the expected numbers of verifiers in each \(SV^{r,s}\), for \(s > 1\). Notice that \(n_1 \ll n\), since we need at least one honest honest member in \(SV^{r,1}\), but at least a majority of honest members in each \(SV^{r,s}\) for \(s > 1\).
  • \(h \in (0, 1)\): a constant greater than \(2/3\). \(h\) is the honesty ratio in the system. That is, the fraction of honest users or honest money, depending on the assumption used, in each \(PK^r\) is at least \(h\).
  • \(H\): a cryptographic hash function, modelled as a random oracle.
  • \(\bot\): A special string of the same length as the output of \(H\).
  • \(F \in (0, 1)\): the parameter specifying the allowed error probability. A probability \(\leq F\) is considered "negligible", and a probability \(\geq 1 - F\) is considered "overwhelming".
  • \(p_h \in (0, 1)\): the probability that the leader of a round \(r\), \(\ell_r\), is honest. Ideally \(p_h = h\). With the existence of the Adversary, the value of \(p_h\) will be determined in the analysis.
  • \(k \in \mathbb{Z}^+\): the look-back parameter. That is, round \(r - k\) is where the verifiers for round \(r\) are chosen from — namely, \(SV^r \subseteq PK^{r-k}\).15
  • \(p_1 \in (0, 1)\): for the first step of round \(r\), a user in round \(r - k\) is chosen to be in \(SV^{r,1}\) with probability \(p_1 \triangleq \frac{n_1}{|PK^{r-k}|}\).
  • \(p \in (0, 1)\): for each step \(s > 1\) of round \(r\), a user in round \(r - k\) is chosen to be in \(SV^{r,s}\) with probability \(p \triangleq \frac{n}{|PK^{r-k}|}\).
  • \(CERT^r\): the certificate for \(B_r\). It is a set of \(t_H\) signatures of \(H(B_r)\) from proper verifiers in round \(r\).
  • \(\overline{B_r} \triangleq (B_r, CERT^r)\) is a proven block. A user \(i\) knows \(\overline{B_r}\) if he possesses (and successfully verifies) both parts of the proven block. Note that the \(CERT^r\) seen by different users may be different.
  • \(\tau^r_i\): the (local) time at which a user \(i\) knows \(\overline{B_r}\). In the Algorand protocol each user has his own clock. Different users' clocks need not be synchronized, but must have the same speed. Only for the purpose of the analysis, we consider a reference clock and measure the players' related times with respect to it.
  • \(\alpha^{r,s}_i\) and \(\beta^{r,s}_i\): respectively the (local) time a user \(i\) starts and ends his execution of Step \(s\) of round \(r\).
  • \(\Lambda\) and \(\lambda\): essentially, the upper-bounds to, respectively, the time needed to execute Step 1 and the time needed for any other step of the Algorand protocol. Parameter \(\Lambda\) upper-bounds the time to propagate a single 1MB block. (In our notation, \(\Lambda = \lambda_{\rho, 1\text{MB}}\). Recalling our notation, that we set \(\rho = 1\) for simplicity, and that blocks are chosen to be at most 1MB-long, we have \(\Lambda = \lambda_{1,1,1\text{MB}}\).) 15Strictly speaking, "\(r - k\)" should be "\(\max\{0, r - k\}\)".

Parameter \(\lambda\) upperbounds the time to propagate one small message per verifier in a Step \(s > 1\). (Using, as in Bitcoin, elliptic curve signatures with 32B keys, a verifier message is 200B long. Thus, in our notation, \(\lambda = \lambda_{n, \rho, 200\text{B}}\).) We assume that \(\Lambda = O(\lambda)\). Notions - Verifier selection. For each round \(r\) and step \(s > 1\), \(SV^{r,s} \triangleq \{i \in PK^{r-k} : .\!H(\text{SIG}_i(r, s, Q_{r-1})) \leq p\}\). Each user \(i \in PK^{r-k}\) privately computes his signature using his long-term key and decides whether \(i \in SV^{r,s}\) or not. If \(i \in SV^{r,s}\), then \(\text{SIG}_i(r, s, Q_{r-1})\) is \(i\)'s \((r, s)\)-credential, compactly denoted by \(\sigma^{r,s}_i\). For the first step of round \(r\), \(SV^{r,1}\) and \(\sigma^{r,1}_i\) are similarly defined, with \(p\) replaced by \(p_1\). The verifiers in \(SV^{r,1}\) are potential leaders. - Leader selection. User \(i \in SV^{r,1}\) is the leader of round \(r\), denoted by \(\ell_r\), if \(H(\sigma^{r,1}_i) \leq H(\sigma^{r,1}_j)\) for all potential leaders \(j \in SV^{r,1}\). Whenever the hashes of two players' credentials are compared, in the unlikely event of ties, the protocol always breaks ties lexicographically according to the (long-term public keys of the) potential leaders. By definition, the hash value of player \(\ell_r\)'s credential is also the smallest among all users in \(PK^{r-k}\). Note that a potential leader cannot privately decide whether he is the leader or not, without seeing the other potential leaders' credentials. Since the hash values are uniform at random, when \(SV^{r,1}\) is non-empty, \(\ell_r\) always exists and is honest with probability at least \(h\). The parameter \(n_1\) is large enough so as to ensure that each \(SV^{r,1}\) is non-empty with overwhelming probability. - Block structure. A non-empty block is of the form \(B_r = (r, PAY^r, \text{SIG}_{\ell_r}(Q_{r-1}), H(B_{r-1}))\), and an empty block is of the form \(B^r_\varepsilon = (r, \varnothing, Q_{r-1}, H(B_{r-1}))\). Note that a non-empty block may still contain an empty payset \(PAY^r\), if no payment occurs in this round or if the leader is malicious. However, a non-empty block implies that the identity of \(\ell_r\), his credential \(\sigma^{r,1}_{\ell_r}\) and \(\text{SIG}_{\ell_r}(Q_{r-1})\) have all been timely revealed. The protocol guarantees that, if the leader is honest, then the block will be non-empty with overwhelming probability. - Seed \(Q_r\). If \(B_r\) is non-empty, then \(Q_r \triangleq H(\text{SIG}_{\ell_r}(Q_{r-1}), r)\), otherwise \(Q_r \triangleq H(Q_{r-1}, r)\). Parameters - Relationships among various parameters. — The verifiers and potential leaders of round \(r\) are selected from the users in \(PK^{r-k}\), where \(k\) is chosen so that the Adversary cannot predict \(Q_{r-1}\) back at round \(r - k - 1\) with probability better than \(F\): otherwise, he will be able to introduce malicious users for round \(r - k\), all of which will be potential leaders/verifiers in round \(r\), succeeding in

having a malicious leader or a malicious majority in \(SV^{r,s}\) for some steps \(s\) desired by him. — For Step 1 of each round \(r\), \(n_1\) is chosen so that with overwhelming probability, \(SV^{r,1} \neq \varnothing\). - Example choices of important parameters. — The outputs of \(H\) are 256-bit long. — \(h = 80\%\), \(n_1 = 35\). — \(\Lambda = 1\) minute and \(\lambda = 10\) seconds. - Initialization of the protocol. The protocol starts at time 0 with \(r = 0\). Since there does not exist "\(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.

Duas Modalidades de Algorand

Conforme discutido, em um nível muito alto, uma rodada de Algorand idealmente procede da seguinte forma. Primeiro, aleatoriamente o usuário selecionado, o líder, propõe e circula um novo bloco. (Este processo inclui inicialmente selecionando alguns líderes potenciais e depois garantindo que, pelo menos uma boa fração do tempo, um surge um único líder comum.) Em segundo lugar, um comitê de usuários selecionado aleatoriamente é selecionado e chega a um acordo bizantino sobre o bloco proposto pelo líder. (Este processo inclui que cada etapa do protocolo BA é executada por um comitê selecionado separadamente.) O bloco acordado é então assinado digitalmente por um determinado limite (TH) de membros do comitê. Essas assinaturas digitais são circulados para que todos tenham certeza de qual é o novo bloco. (Isto inclui a circulação do credencial dos signatários, e autenticando apenas o hash do novo bloco, garantindo que todos tem a garantia de aprender o bloco, uma vez que seu hash seja esclarecido.) Nas próximas duas seções, apresentamos duas modalidades de Algorand, Algorand ′ 1 e Algorand ′ 2, que funcionam sob a suposição da maioria dos usuários honestos. Na Seção 8 mostramos como adotar essas incorporações para trabalhar sob uma suposição de maioria honesta de dinheiro. Algorand ′ 1 prevê apenas que > 2/3 dos membros do comitê sejam honestos. Além disso, em Algorand ′ 1, o número de passos para chegar a um acordo bizantino é limitado a um nível adequadamente elevado número, de modo que é garantido que o acordo será alcançado com probabilidade esmagadora dentro de um número fixo de etapas (mas potencialmente exigindo mais tempo do que as etapas de Algorand ′ 2). No caso remoto em que o acordo ainda não foi alcançado na última etapa, a comissão concorda com a bloco vazio, que é sempre válido. Algorand ′ 2 prevê que o número de membros honestos em uma comissão seja sempre maior do que ou igual a um limite fixo tH (o que garante que, com probabilidade esmagadora, pelo menos 2/3 dos membros do comitê são honestos). Além disso, Algorand ′ 2 permite que o acordo bizantino ser alcançado em um número arbitrário de etapas (mas potencialmente em um tempo menor que Algorand ′ 1). É fácil derivar muitas variantes destas modalidades básicas. Em particular, é fácil, dado Algorand ′ 2, para modificar Algorand ′ 1, de modo a permitir chegar a um acordo bizantino de forma arbitrária número de etapas. Ambas as modalidades compartilham o seguinte núcleo, notações, noções e parâmetros comuns. 4.1 Um núcleo comum Objetivos Idealmente, para cada rodada r, Algorand satisfaria as seguintes propriedades: 1. Correção Perfeita. Todos os usuários honestos concordam com o mesmo bloco Br. 2. Completude 1. Com probabilidade 1, o conjunto de pagamentos de Br, PAY r, é máximo.10 10Como os conjuntos de pagamentos são definidos para conter pagamentos válidos e os usuários honestos para fazer apenas pagamentos válidos, um valor máximo PAY r contém os pagamentos “atualmente pendentes” de todos os usuários honestos.É claro que garantir a correção perfeita por si só é trivial: todo mundo sempre escolhe o modelo oficial. payset PAY r fique vazio. Mas neste caso, o sistema teria completude 0. Infelizmente, garantir tanto a correção perfeita quanto a integridade 1 não é fácil na presença de malware usuários. Algorand adota assim um objetivo mais realista. Informalmente, deixando h denotar a porcentagem de usuários honestos, h > 2/3, o objetivo de Algorand é Garantindo, com probabilidade esmagadora, correção perfeita e completude próxima de h. Privilegiar a correcção em detrimento da integralidade parece ser uma escolha razoável: os pagamentos não processados em uma rodada pode ser processada na próxima, mas deve-se evitar garfos, se possível. Acordo Bizantino Liderado A correção perfeita pode ser garantida da seguinte forma. No início da rodada r, cada usuário i constrói seu próprio bloco candidato Br i , e então todos os usuários alcançam o Byzantine acordo sobre um bloco candidato. De acordo com nossa introdução, o protocolo BA empregado requer uma maioria honesta de 2/3 e é substituível pelo jogador. Cada uma de suas etapas pode ser executada por um pequeno e conjunto de verificadores selecionados aleatoriamente, que não compartilham nenhuma variável interna. Infelizmente, esta abordagem não tem garantias de integridade. Isso ocorre porque o candidato blocos de usuários honestos são provavelmente totalmente diferentes uns dos outros. Assim, em última análise O bloco acordado pode sempre ser aquele com um conjunto de pagamentos não máximo. Na verdade, pode ser sempre o bloco vazio, B\(\varepsilon\), ou seja, o bloco cujo payset está vazio. bem, será o padrão, vazio. Algorand ′ evita esse problema de completude da seguinte maneira. Primeiro, um líder para a rodada r, \(\ell\)r, é selecionado. Então, \(\ell\)r propaga seu próprio bloco candidato, Br \(\ell\)r. Finalmente, os usuários chegam a um acordo sobre o bloqueio eles realmente recebem de \(\ell\)r. Porque, sempre que \(\ell\)r for honesto, perfeita correção e integridade 1 ambos são válidos, Algorand ′ garante que \(\ell\)r é honesto com probabilidade próxima de h. (Quando o líder é malicioso, não nos importamos se o bloco acordado é aquele com um conjunto de pagamentos vazio. Afinal, um o líder malicioso \(\ell\)r pode sempre escolher Br de forma maliciosa \(\ell\)r para ser o bloco vazio e, honestamente propagá-lo, forçando assim os usuários honestos a concordar com o bloco vazio.) Seleção de Líder Em Algorand's, o r-ésimo bloco tem a forma Br = (r, PAY r, Qr, H(Br−1). Como já mencionado na introdução, a quantidade Qr−1 é cuidadosamente construída de modo a ser essencialmente não manipulável pelo nosso poderoso Adversário. (Mais adiante nesta seção, iremos fornecer alguma intuição sobre por que isso acontece.) No início de uma rodada r, todos os usuários sabem o blockchain até agora, B0, . . . , Br−1, a partir do qual eles deduzem o conjunto de usuários de cada rodada anterior: que é, PK1, . . . , PKr−1. Um potencial líder da rodada r é um usuário i tal que .H SIGi r, 1, Qr−1 \(\leq\)p. Deixe-nos explicar. Observe que, como a quantidade Qr−1 faz parte do bloco Br−1, e o subjacente esquema de assinatura satisfaz a propriedade de exclusividade, SIGi r, 1, Qr−1 é uma string binária exclusivamente associado a i e r. Assim, como H é um oracle aleatório, H SIGi r, 1, Qr−1 é um aleatório de 256 bits string longa associada exclusivamente a i e r. O símbolo “.” na frente de H SIGi r, 1, Qr−1 é o ponto decimal (no nosso caso, binário), de modo que ri \(\triangleq\).H SIGi r, 1, Qr−1 é a expansão binária de um número aleatório de 256 bits entre 0 e 1 associado exclusivamente a i e r. Assim a probabilidade de que ri é menor ou igual a p é essencialmente p. (Nosso mecanismo de seleção de líderes potenciais tem sido inspirado no esquema de micropagamento de Micali e Rivest [28].) A probabilidade p é escolhida de modo que, com probabilidade esmagadora (ou seja, 1 −F), pelo menos um o verificador potencial é honesto. (Se for verdade, p é escolhido como a menor probabilidade.)Observe que, como i é o único capaz de calcular suas próprias assinaturas, só ele pode determinar se ele é um verificador potencial da primeira rodada. No entanto, ao revelar sua própria credencial, \(\sigma\)r eu \(\triangleq\)SIGi r, 1, Qr−1 , posso provar a qualquer um que sou um verificador potencial da rodada r. O líder \(\ell\)r é definido como o líder potencial cuja credencial hashed é menor que a hashed credencial de todos os outros líderes potenciais j: isto é, H(\(\sigma\)r,s \(\ell\)r ) \(\leq\)H(\(\sigma\)r,s j). Observe que, como um \(\ell\)r malicioso pode não revelar sua credencial, o líder correto da rodada r pode nunca será conhecido, e que, salvo laços improváveis, \(\ell\)r é de fato o único líder da rodada r. Vamos finalmente trazer um último mas importante detalhe: um usuário pode ser um líder em potencial (e, portanto, o líder) de uma rodada r somente se ele pertencer ao sistema por pelo menos k rodadas. Isso garante a não manipulabilidade de Qr e de todas as quantidades Q futuras. Na verdade, um dos potenciais líderes irá realmente determinar Qr. Seleção do Verificador Cada passo s > 1 da rodada r é executado por um pequeno conjunto de verificadores, SV r,s. Novamente, cada verificador i \(\in\)SV r,s é selecionado aleatoriamente entre os usuários já presentes no sistema k rodadas. antes de r, e novamente através da quantidade especial Qr−1. Especificamente, i \(\in\)PKr−k é um verificador em SV r,s, se .H SIGi r, s, Qr−1 \(\leq\)p′. Mais uma vez, só eu sei se ele pertence a SV r,s, mas, se for esse o caso, ele poderia provar isso exibindo sua credencial \(\sigma\)r,s eu \(\triangleq\)H(SIGi r, s, Qr−1 ). Um verificador i \(\in\)SV r,s envia uma mensagem, mr,s eu, em etapa s da rodada r, e esta mensagem inclui sua credencial \(\sigma\)r,s i , de modo a permitir que os verificadores do passo para reconhecer que o senhor,s eu é uma mensagem legítima de etapas. A probabilidade p′ é escolhida de modo a garantir que, em SV r,s, sendo #good o número de usuários honestos e #bad o número de usuários mal-intencionados, com grande probabilidade o seguinte duas condições são válidas. Para concretização Algorand ′ 1: (1) #bom > 2 \(\cdot\) #ruim e (2) #bom + 4 \(\cdot\) #ruim < 2n, onde n é a cardinalidade esperada de SV r,s. Para concretização Algorand ′ 2: (1) #bom > tH e (2) #bom + 2#ruim < 2tH, onde tH é um limite especificado. Estas condições implicam que, com probabilidade suficientemente alta, (a) na última etapa do BA protocolo, haverá pelo menos um determinado número de jogadores honestos para assinar digitalmente o novo bloco Br, (b) apenas um bloco por rodada poderá ter o número necessário de assinaturas, e (c) o BA utilizado o protocolo tem (em cada etapa) a maioria honesta necessária de 2/3. Esclarecendo a geração de blocos Se o líder da rodada r for honesto, então o bloco correspondente é da forma Br = r, PAGAR r, SIG\(\ell\)r Qr−1 , H Br−1 , onde o payset PAY r é máximo. (lembre-se de que todos os conjuntos de pagamentos são, por definição, válidos coletivamente.) Caso contrário (ou seja, se \(\ell\)r for malicioso), Br terá uma das duas formas possíveis a seguir: Br = r, PAGAR r, SIGi Qr-1 , H Br−1 e Br = Br \(\varepsilon\) \(\triangleq\) r, \(\emptyset\), Qr−1, H Br−1 .Na primeira forma, PAY r é um conjunto de pagamentos (não necessariamente máximo) e pode ser PAY r = \(\emptyset\); e eu sou um potencial líder da rodada r. (No entanto, posso não ser o líder \(\ell\)r. Isso pode realmente acontecer se \(\ell\)r mantém em segredo sua credencial e não se revela.) A segunda forma surge quando, na execução da rodada R do protocolo BA, todos os jogadores honestos produza o valor padrão, que é o bloco vazio Br \(\varepsilon\) em nossa aplicação. (Por definição, o possível as saídas de um protocolo BA incluem um valor padrão, genericamente denotado por \(\bot\). Consulte a seção 3.2.) Observe que, embora os paysets estejam vazios em ambos os casos, Br = r, \(\emptyset\), SIGi Qr-1 , H Br−1 e irmão \(\varepsilon\) são blocos sintaticamente diferentes e surgem em duas situações diferentes: respectivamente, “todos correu bem na execução do protocolo BA” e “algo deu errado no Protocolo BA, e o valor padrão foi gerado”. Vamos agora descrever intuitivamente como ocorre a geração do bloco Br na rodada r de Algorand ′. Na primeira etapa, cada jogador elegível, ou seja, cada jogador i \(\in\)PKr−k, verifica se é um potencial líder. Se for esse o caso, então me perguntam, usando todos os pagamentos que ele viu até agora, e o atual blockchain, B0, . . . , Br−1, para preparar secretamente um conjunto de pagamento máximo, PAY r eu, e secretamente monta seu bloco candidato, Br = r, PAGUE r eu, SIGi Qr-1 , H Br−1 . Isto é, ele não apenas incluir no Br i, como segundo componente o conjunto de pagamentos recém-preparado, mas também, como terceiro componente, sua própria assinatura de Qr−1, a terceira componente do último bloco, Br−1. Finalmente, ele propagou seu mensagem round-r-step-1, senhor,1 i , que inclui (a) seu bloco candidato Br eu, (b) sua assinatura adequada de seu bloco candidato (ou seja, sua assinatura do hash do Br i , e (c) sua própria credencial \(\sigma\)r,1 eu, provando que ele é de fato um verificador potencial da rodada r. (Observe que, até que um i honesto produza sua mensagem mr,1 i, o Adversário não tem ideia de que i é um verificador potencial. Se ele quiser corromper potenciais líderes honestos, o Adversário poderia muito bem jogadores honestos aleatórios corruptos. No entanto, uma vez que ele vê o Sr.,1 i , uma vez que contém a credencial de i, o O adversário sabe e pode corromper-me, mas não pode impedir o senhor,1 i , que é propagado viralmente, de atingindo todos os usuários do sistema.) Na segunda etapa, cada verificador selecionado j \(\in\)SV r,2 tenta identificar o líder da rodada. Especificamente, j usa as credenciais da etapa 1, \(\sigma\)r,1 i1 , . . . , \(\sigma\)r,1 in , contido na mensagem apropriada da etapa 1 mr,1 eu ele recebeu; hashes todos eles, ou seja, calcula H  \(\sigma\)r,1 e1  , . . . , H  \(\sigma\)r,1 em  ; encontra a credencial, \(\sigma\)r,1 \(\ell\)j , cujo hash é lexicograficamente mínimo; e considera \(\ell\)r j para ser o líder da rodada r. Lembre-se que cada credencial considerada é uma assinatura digital de Qr−1, que o SIGi r, 1, Qr−1 é determinado exclusivamente por i e Qr−1, que H é aleatório oracle e, portanto, cada H(SIGi r, 1, Qr−1 é uma longa string aleatória de 256 bits exclusiva para cada líder potencial i da rodada r. Disto podemos concluir que, se a string de 256 bits Qr-1 fosse ela mesma aleatória e independentemente selecionados, então seriam as credenciais hashed de todos os líderes potenciais da rodada r. Na verdade, todos líderes potenciais são bem definidos, assim como suas credenciais (sejam realmente computadas ou não). Além disso, o conjunto de líderes potenciais da rodada r é um subconjunto aleatório dos usuários da rodada r −k, e um líder potencial honesto eu sempre constrói e propaga adequadamente sua mensagem, Sr. eu, que contém a credencial de i. Assim, como o percentual de usuários honestos é h, não importa qual seja o potenciais líderes mal-intencionados possam fazer (por exemplo, revelar ou ocultar suas próprias credenciais), o mínimo A credencial de líder potencial hashed pertence a um usuário honesto, que é necessariamente identificado por todos ser o líder \(\ell\)r da rodada r. Conseqüentemente, se a string de 256 bits Qr-1 fosse ela mesma aleatória e selecionado independentemente, com probabilidade exatamente h (a) o líder \(\ell\)r é honesto e (b) \(\ell\)j = \(\ell\)r para todos verificadores honestos da etapa 2 j. Na realidade, as credenciais hashed são, sim, selecionadas aleatoriamente, mas dependem de Qr−1, que énão selecionados de forma aleatória e independente. Provaremos em nossa análise, entretanto, que Qr−1 é suficientemente não manipulável para garantir que o líder de uma rodada seja honesto com a probabilidade h′ suficientemente próximo de h: ou seja, h′ > h2(1 + h −h2). Por exemplo, se h = 80%, então h′ > 0,7424. Tendo identificado o líder da rodada (o que eles fazem corretamente quando o líder \(\ell\)r é honesto), a tarefa dos verificadores da etapa 2 é começar a executar o BA usando como valores iniciais o que eles acreditam ser o bloco do líder. Na verdade, para minimizar a quantidade de comunicação necessária, um verificador j \(\in\)SV r,2 não usa, como seu valor de entrada v′ j para o protocolo bizantino, o bloco Bj que ele realmente recebeu de \(\ell\)j (o usuário j acredita ser o líder), mas o líder, mas o hash desse bloco, ou seja, v′ j = H(Bi). Assim, após o término do protocolo BA, os verificadores da última etapa não calcula o bloco round-r desejado Br, mas calcula (autentica e propagar) H(Br). Assim, uma vez que H(Br) é assinado digitalmente por um número suficiente de verificadores do última etapa do protocolo BA, os usuários do sistema perceberão que H(Br) é o hash do novo bloco. Entretanto, eles também devem recuperar (ou esperar, já que a execução é bastante assíncrona) o próprio bloco Br, que o protocolo garante que está realmente disponível, não importa o que o Adversário poderia fazer. Assincronia e Tempo Algorand ′ 1 e Algorand ′ 2 têm um grau significativo de assincronia. Isso ocorre porque o Adversário tem grande liberdade para programar a entrega das mensagens que estão sendo enviadas. propagado. Além disso, quer o número total de passos numa ronda seja limitado ou não, há a variância contribui com o número de passos realmente dados. Assim que ele souber dos certificados de B0, . . . , Br−1, um usuário i calcula Qr−1 e começa a trabalhar na rodada r, verificando se ele é um líder em potencial ou um verificador em algumas etapas da rodada r. Supondo que devo agir na etapa s, à luz da assincronia discutida, baseio-me em vários estratégias para garantir que ele tenha informações suficientes antes de agir. Por exemplo, ele pode esperar para receber pelo menos um determinado número de mensagens dos verificadores de passo anterior, ou esperar um tempo suficiente para garantir que ele receba as mensagens de pessoas suficientemente muitos verificadores da etapa anterior. O Seed Qr e o Parâmetro Look-Back k Lembre-se que, idealmente, as quantidades Qr deveriam aleatórios e independentes, embora seja suficiente que sejam suficientemente não manipuláveis por o Adversário. À primeira vista, poderíamos escolher Qr−1 para coincidir com H PAGUE r−1 , e assim evitar especifique Qr−1 explicitamente em Br−1. Uma análise elementar revela, contudo, que utilizadores maliciosos podem aproveitar esse mecanismo de seleção.11 Alguns esforços adicionais mostram que miríades de outros 11Estamos no início da rodada r −1. Assim, Qr−2 = PAY r−2 é conhecido publicamente, e o Adversário é privado sabe quem são os líderes potenciais que ele controla. Suponha que o Adversário controle 10% dos usuários, e que, com probabilidade muito alta, um usuário malicioso w é o líder potencial da rodada r −1. Ou seja, suponha que H SIGw r −2, 1, Qr −2 é tão pequeno que é altamente improvável que um líder potencial honesto seja realmente o líder da rodada r −1. (Lembre-se que, uma vez que escolhemos líderes potenciais através de um mecanismo secreto de classificação criptográfica, o Adversário não sabe quem são os líderes potenciais honestos.) O Adversário, portanto, está na invejável posição de escolher o conjunto de pagamentos PAY ′ que ele deseja, e torná-lo o conjunto de pagamentos oficial da rodada r −1. No entanto, ele pode fazer mais. Ele também pode garantir que, com alta probabilidade, () um de seus usuários maliciosos será o líder também da rodada r, para que ele possa escolher livremente qual será o PAY r. (E assim por diante. Pelo menos por um longo tempo, isto é, contanto que esses eventos de alta probabilidade realmente ocorram.) Para garantir (), o Adversário age da seguinte forma. Vamos PAGAR' seja o conjunto de pagamentos que o Adversário prefere para a rodada r −1. Então, ele calcula H(PAY ′) e verifica se, para algum o jogador já malicioso z, SIGz(r, 1, H(PAY ′)) é particularmente pequeno, ou seja, pequeno o suficiente para que com valores muito altos probabilidade z será o líder da rodada r. Se for esse o caso, então ele instrui w a escolher seu bloco candidato a seralternativas, baseadas em quantidades de blocos tradicionais, são facilmente exploráveis pelo Adversário para garantir que líderes maliciosos são muito frequentes. Em vez disso, definimos específica e indutivamente nossa marca nova quantidade Qr para poder provar que ela não é manipulável pelo Adversário. Ou seja, Qr \(\triangleq\)H(SIG\(\ell\)r(Qr−1), r), se Br não for o bloco vazio, e Qr \(\triangleq\)H(Qr−1, r) caso contrário. A intuição de por que esta construção de Qr funciona é a seguinte. Suponha por um momento que Qr−1 é verdadeiramente selecionado de forma aleatória e independente. Então, será assim Qr? Quando \(\ell\)r é honesto, o a resposta é (grosso modo) sim. Isto é assim porque H(SIG\(\ell\)r( \(\cdot\) ), r) : {0, 1}256 −→{0, 1}256 é uma função aleatória. Quando \(\ell\)r é malicioso, entretanto, Qr não é mais definido univocamente a partir de Qr−1 e \(\ell\)r. Existem pelo menos dois valores separados para Qr. Um continua a ser Qr \(\triangleq\)H(SIG\(\ell\)r(Qr−1), r), e o outro é H(Qr−1, r). Vamos primeiro argumentar que, embora a segunda escolha seja um tanto arbitrária, uma segunda escolha é absolutamente obrigatória. A razão para isso é que um \(\ell\)r malicioso sempre pode causar blocos candidatos totalmente diferentes a serem recebidos pelos verificadores honestos da segunda etapa.12 Uma vez for esse o caso, é fácil garantir que o bloco finalmente acordado através do protocolo BA de round r será o padrão e, portanto, não conterá a assinatura digital de Qr-1 de ninguém. Mas o sistema deve continuar e, para isso, precisa de um líder para a rodada r. Se este líder for automaticamente e selecionado abertamente, então o Adversário irá corrompê-lo trivialmente. Se for selecionado pelo anterior Qr−1 através do mesmo processo, então \(\ell\)r será novamente o líder na rodada r+1. Propomos especificamente usam o mesmo mecanismo secreto de classificação criptográfica, mas aplicado a uma nova quantidade Q: a saber, H(Qr−1, r). Ter essa quantidade como a saída de H garante que a saída seja aleatória, e incluindo r como a segunda entrada de H, enquanto todos os outros usos de H têm uma ou mais de 3 entradas, “garante” que tal Qr seja selecionado de forma independente. Novamente, nossa escolha específica da alternativa Qr não importa, o que importa é que \(\ell\)r tem duas opções para Qr e, portanto, ele pode dobrar suas chances ter outro usuário mal-intencionado como o próximo líder. As opções para Qr podem ser ainda mais numerosas para o Adversário que controla um \(\ell\)r malicioso. Por exemplo, sejam x, y e z três líderes potenciais maliciosos da rodada r, tais que H \(\sigma\)r,1 x  < H \(\sigma\)r,1 sim  < H \(\sigma\)r,1 z  e H  \(\sigma\)r,1 z  é particularmente pequeno. Isto é, tão pequeno que há uma boa chance de que H  \(\sigma\)r,1 z  é menor da credencial hashed de todo líder potencial honesto. Então, pedindo a x para esconder seu credencial, o Adversário tem uma boa chance de fazer com que y se torne o líder da rodada r −1. Isto implica que ele tem outra opção para Qr: a saber, SIGy Qr-1 . Da mesma forma, o Adversário pode peça a x e y que retenham suas credenciais, de modo que z se torne o líder da rodada r −1 e ganhando outra opção para Qr: a saber, SIGz Qr-1 . É claro, porém, que cada uma dessas e outras opções tem uma chance diferente de zero de falhar, porque o O adversário não pode prever o hash das assinaturas digitais dos usuários potenciais honestos. Br−1 eu = (r −1, PAY ′, H(Br−2). Caso contrário, ele tem dois outros usuários maliciosos x e y para continuar gerando um novo pagamento \(\wp\)′, de um para outro, até que, para algum usuário malicioso z (ou mesmo para algum usuário fixo z) H (SIGz (PAY ′ \(\cup\){\(\wp\)})) é particularmente pequeno também. Esta experiência irá parar rapidamente. E quando isso acontece, o Adversário pede que você proponha o bloco candidato Br−1 eu = (r −1, PAGUE ′ \(\cup\){\(\wp\)}, H(Br−2). 12Por exemplo, para simplificar (mas extremo), “quando o tempo da segunda etapa estiver prestes a expirar”, \(\ell\)r poderia enviar por e-mail diretamente um bloco candidato Bi diferente para cada usuário i. Dessa forma, sejam quem forem os verificadores da etapa 2, eles terá recebido blocos totalmente diferentes.Uma análise cuidadosa, semelhante à cadeia de Markov, mostra que, independentemente das opções que o Adversário escolha fazer na rodada r −1, desde que ele não possa injetar novos usuários no sistema, ele não poderá diminuir o probabilidade de um usuário honesto ser o líder da rodada r + 40 muito abaixo de h. Esta é a razão que exigimos que os potenciais líderes da rodada r sejam usuários já existentes na rodada r −k. É uma forma de garantir que, na rodada r −k, o Adversário não possa alterar muito a probabilidade de que um usuário honesto se torna o líder da rodada r. Na verdade, não importa quais usuários ele adicione ao sistema nas rodadas r −k até r, eles são inelegíveis para se tornarem líderes em potencial (e a fortiori o líder) da rodada r. Assim, o parâmetro de lookback k é, em última análise, um parâmetro de segurança. (Embora, como veremos na seção 7, também pode ser uma espécie de “parâmetro de conveniência”.) Chaves Efêmeras Embora a execução do nosso protocolo não possa gerar um fork, exceto com probabilidade desprezível, o Adversário poderia gerar uma bifurcação, no bloco r, após o legítimo o bloco r foi gerado. Grosso modo, uma vez gerado Br, o Adversário sabe quem são os verificadores de cada etapa. da rodada r são. Assim, ele poderia corromper todos eles e obrigá-los a certificar um novo bloco f Ir. Como esse bloco falso pode ser propagado somente após o bloco legítimo, os usuários que foram prestar atenção não seria enganado.13 No entanto, f Br estaria sintaticamente correto e nós deseja evitar que seja fabricado. Fazemos isso por meio de uma nova regra. Essencialmente, os membros do conjunto verificador SV r,s de uma etapa s da rodada r use chaves públicas efêmeras pkr,s eu para assinar digitalmente suas mensagens. Essas chaves são de uso único e suas chaves secretas correspondentes skr,s eu são destruídos uma vez usados. Dessa forma, se um verificador for corrompido mais tarde, o Adversário não pode forçá-lo a assinar qualquer outra coisa que ele não tenha assinado originalmente. Naturalmente, devemos garantir que seja impossível para o Adversário calcular uma nova chave g pr,s eu e convencer um usuário honesto de que é a chave efêmera correta do verificador i \(\in\)SV r,s para usar na etapa s. 4.2 Resumo comum de notações, noções e parâmetros Notações • r \(\geq\)0: o número da rodada atual. • s \(\geq\)1: o número do passo atual na rodada r. • Br: bloco gerado na rodada r. • PKr: o conjunto de chaves públicas no final da rodada r −1 e no início da rodada r. • Sr: o status do sistema no final da rodada r −1 e no início da rodada r.14 • PAY r: o payset contido no Br. • \(\ell\)r: líder da rodada r. \(\ell\)r escolhe o payset PAY r da rodada r (e determina o próximo Qr). • Qr: a semente da rodada r, uma quantidade (ou seja, string binária) que é gerada no final da rodada r e é usado para escolher verificadores para a rodada r + 1. Qr é independente dos paysets nos blocos e não pode ser manipulado por \(\ell\)r. 13Considere corromper o âncora de uma grande rede de TV e produzir e transmitir hoje um noticiário mostrando a secretária Clinton vencendo a última eleição presidencial. A maioria de nós reconheceria isso como uma farsa. Mas alguém que sai do coma pode ser enganado. 14Num sistema que não é síncrono, a noção de “fim da ronda r −1” e “início da ronda r” precisam ser cuidadosamente definidos. Matematicamente, PKr e Sr são calculados a partir do status inicial S0 e dos blocos B1, . . . , Br−1.• SV r,s: o conjunto de verificadores escolhidos para a etapa s da rodada r. • SV r: o conjunto de verificadores escolhidos para a rodada r, SV r = \(\cup\)s\(\geq\)1SV r,s. • MSV r,s e HSV r,s: respectivamente, o conjunto de verificadores maliciosos e o conjunto de verificadores honestos em SV r,s. MSV r,s \(\cup\)HSV r,s = SV r,s e MSV r,s ∩HSV r,s = \(\emptyset\). • n1 \(\in\)Z+ e n \(\in\)Z+: respectivamente, os números esperados de potenciais líderes em cada SV r,1, e os números esperados de verificadores em cada SV r,s, para s > 1. Observe que n1 << n, já que precisamos de pelo menos um membro honesto e honesto em SV r,1, mas pelo menos uma maioria de membros honestos em cada SV r,s para s > 1. • h \(\in\)(0, 1): uma constante maior que 2/3. h é o índice de honestidade no sistema. Ou seja, o fração de usuários honestos ou dinheiro honesto, dependendo da suposição utilizada, em cada PKr é pelo menos h. • H: uma função criptográfica hash, modelada como uma oracle aleatória. • \(\bot\): Uma string especial do mesmo comprimento que a saída de H. • F \(\in\)(0, 1): parâmetro que especifica a probabilidade de erro permitida. Uma probabilidade \(\leq\)F é considerada “desprezível”, e uma probabilidade \(\geq\)1 −F é considerada “esmagadora”. • ph \(\in\)(0, 1): a probabilidade de o líder de uma rodada r, \(\ell\)r, ser honesto. Idealmente ph = h. Com a existência do Adversário, o valor de ph será determinado na análise. • k \(\in\)Z+: o parâmetro de retrospectiva. Ou seja, a rodada r −k é onde os verificadores da rodada r estão escolhido entre —ou seja, SV r \(\subseteq\)PKr−k.15 • p1 \(\in\)(0, 1): para o primeiro passo da rodada r, um usuário da rodada r −k é escolhido para estar em SV r,1 com probabilidade p1 \(\triangleq\) n1 |P Kr−k|. • p \(\in\)(0, 1): para cada passo s > 1 da rodada r, um usuário da rodada r −k é escolhido para estar em SV r,s com probabilidade p \(\triangleq\) n |P Kr−k|. • CERT r: o certificado para Br. É um conjunto de assinaturas tH de H(Br) de verificadores apropriados em rodada R. • Br \(\triangleq\)(Br, CERT r) é um bloco comprovado. Um usuário i conhece Br se possuir (e verificar com sucesso) ambas as partes do bloco provado. Observe que o CERT visto por diferentes usuários pode ser diferente. • τr i: a hora (local) em que um usuário i conhece Br. No protocolo Algorand cada usuário tem seu próprio relógio. Os relógios de diferentes usuários não precisam ser sincronizados, mas devem ter a mesma velocidade. Apenas para efeitos de análise, consideramos um relógio de referência e medimos a velocidade dos jogadores. tempos relacionados em relação a ele. • \(\alpha\)r,s eu e \(\beta\)r,s i : respectivamente o horário (local) em que um usuário i inicia e termina sua execução da Etapa s de rodada R. • Λ e \(\lambda\): essencialmente, os limites superiores para, respectivamente, o tempo necessário para executar a Etapa 1 e o tempo necessário para qualquer outra etapa do protocolo Algorand. O parâmetro Λ limita superiormente o tempo para propagar um único bloco de 1 MB. (Em nossa notação, Λ = \(\lambda\) \(\rho\),1MB. Lembrando nossa notação, que definimos \(\rho\) = 1 para simplificar, e que os blocos são escolhido para ter no máximo 1 MB, temos Λ = \(\lambda\)1,1,1MB.) 15A rigor, “r −k” deveria ser “max{0, r −k}”.O parâmetro \(\lambda\) limita o tempo para propagar uma pequena mensagem por verificador em uma Etapa s > 1. (Usando, como em Bitcoin, assinaturas de curvas elípticas com chaves de 32B, uma mensagem do verificador tem 200B de comprimento. Assim, em nossa notação, \(\lambda\) = \(\lambda\)n,\(\rho\),200B.) Assumimos que Λ = O(\(\lambda\)). Noções • Seleção do verificador. Para cada rodada r e etapa s > 1, SV r,s \(\triangleq\){i \(\in\)PKr−k : .H(SIGi(r, s, Qr−1)) \(\leq\)p}. Cada o usuário i \(\in\)PKr−k calcula privadamente sua assinatura usando sua chave de longo prazo e decide se i \(\in\)SV r,s ou não. Se i \(\in\)SV r,s, então SIGi(r, s, Qr−1) é a credencial de i(r, s), denotada de forma compacta por \(\sigma\)r,s eu. Para a primeira etapa da rodada r, SV r,1 e \(\sigma\)r,1 eu são definidos de forma semelhante, com p substituído por p1. O verificadores em SV r,1 são líderes em potencial. • Seleção de líderes. O usuário i \(\in\)SV r,1 é o líder da rodada r, denotado por \(\ell\)r, se H(\(\sigma\)r,1 eu) \(\leq\)H(\(\sigma\)r,1 j) para todo potencial líderes j \(\in\)SV r,1. Sempre que os hashes das credenciais de dois jogadores são comparados, no improvável Em caso de empate, o protocolo sempre rompe o vínculo lexicograficamente de acordo com o (público de longo prazo chaves dos) líderes potenciais. Por definição, o valor hash da credencial do jogador \(\ell\)r também é o menor entre todos os usuários em PKr-k. Observe que um líder potencial não pode decidir privadamente se ele é o líder ou não, sem ver as credenciais dos outros líderes potenciais. Como os valores de hash são uniformes aleatoriamente, quando SV r,1 não é vazio, \(\ell\)r sempre existe e é honesto com probabilidade pelo menos h. O parâmetro n1 é grande o suficiente para garantir que cada SV r,1 não é vazio com probabilidade esmagadora. • Estrutura de bloco. Um bloco não vazio tem a forma Br = (r, PAY r, SIG\(\ell\)r(Qr−1), H(Br−1)), e um bloco vazio é da forma Br ǫ = (r, \(\emptyset\), Qr−1, H(Br−1)). Observe que um bloco não vazio ainda pode conter um conjunto de pagamentos PAY r vazio, se nenhum pagamento ocorrer em nesta rodada ou se o líder for malicioso. No entanto, um bloco não vazio implica que a identidade de \(\ell\)r, sua credencial \(\sigma\)r,1 \(\ell\)r e SIG\(\ell\)r(Qr−1) foram todos revelados em tempo hábil. O protocolo garante que, se o líder for honesto, então o bloco não estará vazio com uma probabilidade esmagadora. • Semente Qr. Se Br não for vazio, então Qr \(\triangleq\)H(SIG\(\ell\)r(Qr−1), r), caso contrário Qr \(\triangleq\)H(Qr−1, r). Parâmetros • Relações entre vários parâmetros. — Os verificadores e potenciais líderes da rodada r são selecionados entre os usuários do PKr−k, onde k é escolhido de modo que o Adversário não possa prever Qr−1 na rodada r −k −1 com probabilidade melhor que F: caso contrário, ele poderá introduzir usuários maliciosos para a rodada r −k, todos os quais serão potenciais líderes/verificadores na rodada r, tendo sucesso em

ter um líder malicioso ou uma maioria maliciosa em SV r,s para algumas etapas desejadas por ele. — Para a Etapa 1 de cada rodada r, n1 é escolhido de modo que com probabilidade esmagadora, SV r,1 ̸= \(\emptyset\). • Exemplos de escolhas de parâmetros importantes. — As saídas de H têm 256 bits. — h = 80%, n1 = 35. — Λ = 1 minuto e \(\lambda\) = 10 segundos. • Inicialização do protocolo. O protocolo começa no tempo 0 com r = 0. Como não existe “B−1” ou “CERT −1”, sintaticamente B−1 é um parâmetro público com seu terceiro componente especificando Q−1, e todos os usuários conheça B−1 no tempo 0.

Algorand ′

\(\text{Algorand}^\prime\)

1 In this section, we construct a version of \(\text{Algorand}^\prime\) working under the following assumption. Honest Majority of Users Assumption: More than 2/3 of the users in each \(PK^r\) are honest. In Section 8, we show how to replace the above assumption with the desired Honest Majority of Money assumption. 5.1 Additional Notations and Parameters Notations • \(m \in \mathbb{Z}^+\): the maximum number of steps in the binary BA protocol, a multiple of 3. • \(L_r \leq m/3\): a random variable representing the number of Bernoulli trials needed to see a 1, when each trial is 1 with probability \(\frac{p_h}{2}\) and there are at most \(m/3\) trials. If all trials fail then \(L_r \triangleq m/3\). \(L_r\) will be used to upper-bound the time needed to generate block \(B_r\). • \(t_H = \frac{2n}{3} + 1\): the number of signatures needed in the ending conditions of the protocol. • \(CERT_r\): the certificate for \(B_r\). It is a set of \(t_H\) signatures of \(H(B_r)\) from proper verifiers in round \(r\). Parameters • Relationships among various parameters. — For each step \(s > 1\) of round \(r\), \(n\) is chosen so that, with overwhelming probability, \(|HSV^{r,s}| > 2|MSV^{r,s}|\) and \(|HSV^{r,s}| + 4|MSV^{r,s}| < 2n\). The closer to 1 the value of \(h\) is, the smaller \(n\) needs to be. In particular, we use (variants of) Chernoffbounds to ensure the desired conditions hold with overwhelming probability. — \(m\) is chosen such that \(L_r < m/3\) with overwhelming probability. • Example choices of important parameters. — \(F = 10^{-12}\). — \(n \approx 1500\), \(k = 40\) and \(m = 180\).

5.2 Implementing Ephemeral Keys in \(\text{Algorand}'_1\)

As already mentioned, we wish that a verifier \(i \in SV^{r,s}\) digitally signs his message \(m_i^{r,s}\) of step \(s\) in round \(r\), relative to an ephemeral public key \(pk_i^{r,s}\), using an ephemeral secrete key \(sk_i^{r,s}\) that he promptly destroys after using. We thus need an efficient method to ensure that every user can verify that \(pk_i^{r,s}\) is indeed the key to use to verify \(i\)'s signature of \(m_i^{r,s}\). We do so by a (to the best of our knowledge) new use of identity-based signature schemes. 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 player U, A computes, via SMK, a secret signature key skU relative to the public key U, and privately gives skU to U. (Indeed, in an identity-based digital signature scheme, the public key of a user U is U itself!) This way, if A destroys SMK after computing the secret keys of the users he wants to enable to produce digital signatures, and does not keep any computed secret key, then U is the only one who can digitally sign messages relative to the public key U. Thus, anyone who knows “U’s name”, automatically knows U’s public key, and thus can verify U’s signatures (possibly using also the public master key PMK). In our application, the authority A is user \(i\), and the set of all possible users U coincides with the round-step pair \((r, s)\) in —say— \(S = \{i\} \times \{r', \ldots, r' + 10^6\} \times \{1, \ldots, m+3\}\), where \(r'\) is a given round, and \(m + 3\) the upperbound to the number of steps that may occur within a round. This way, \(pk_i^{r,s} \triangleq (i, r, s)\), so that everyone seeing \(i\)'s signature \(\text{SIG}_{pk_i^{r,s}}^{r,s}(m_i^{r,s})\) can, with overwhelming probability, immediately verify it for the first million rounds \(r\) following \(r'\). In other words, \(i\) first generates \(PMK\) and \(SMK\). Then, he publicizes that \(PMK\) is \(i\)'s master public key for any round \(r \in [r', r' + 10^6]\), and uses \(SMK\) to privately produce and store the secret key \(sk_i^{r,s}\) for each triple \((i, r, s) \in S\). This done, he destroys \(SMK\). If he determines that he is not part of \(SV^{r,s}\), then \(i\) may leave \(sk_i^{r,s}\) alone (as the protocol does not require that he aunthenticates any message in Step \(s\) of round \(r\)). Else, \(i\) first uses \(sk_i^{r,s}\) to digitally sign his message \(m_i^{r,s}\), and then destroys \(sk_i^{r,s}\). Note that \(i\) can publicize his first public master key when he first enters the system. That is, the same payment \(\wp\) that brings \(i\) into the system (at a round \(r'\) or at a round close to \(r'\)), may also specify, at \(i\)'s request, that \(i\)'s public master key for any round \(r \in [r', r' + 10^6]\) is \(PMK\) —e.g., by including a pair of the form \((PMK, [r', r' + 10^6])\). Also note that, since \(m + 3\) is the maximum number of steps in a round, assuming that a round takes a minute, the stash of ephemeral keys so produced will last \(i\) for almost two years. At the same time, these ephemeral secret keys will not take \(i\) too long to produce. Using an elliptic-curve based system with 32B keys, each secret key is computed in a few microseconds. Thus, if \(m + 3 = 180\), then all 180M secret keys can be computed in less than one hour. When the current round is getting close to \(r' + 10^6\), to handle the next million rounds, \(i\) generates a new \((PMK', SMK')\) pair, and informs what his next stash of ephemeral keys is by —for example— having \(\text{SIG}_i(PMK', [r' + 10^6 + 1, r' + 2 \cdot 10^6 + 1])\) enter a new block, either as a separate "transaction" or as some additional information that is part of a payment. By so doing, \(i\) informs everyone that he/she should use \(PMK'\) to verify \(i\)'s ephemeral signatures in the next million rounds. And so on. (Note that, following this basic approach, other ways for implementing ephemeral keys without using identity-based signatures are certainly possible. For instance, via Merkle trees.16) 16In this method, \(i\) generates a public-secret key pair \((pk_i^{r,s}, sk_i^{r,s})\) for each round-step pair \((r, s)\) in —say—

Other ways for implementing ephemeral keys are certainly possible —e.g., via Merkle trees. 5.3 Matching the Steps of \(\text{Algorand}'_1\) with those of \(\text{BA}^\star\) As we said, a round in \(\text{Algorand}'_1\) has at most \(m + 3\) steps. Step 1. In this step, each potential leader \(i\) computes and propagates his candidate block \(B_i^r\), together with his own credential, \(\sigma_i^{r,1}\). Recall that this credential explicitly identifies \(i\). This is so, because \(\sigma_i^{r,1} \triangleq \text{SIG}_i(r, 1, Q_{r-1})\). Potential verifier \(i\) also propagates, as part of his message, his proper digital signature of \(H(B_i^r)\). Not dealing with a payment or a credential, this signature of \(i\) is relative to his ephemeral public key \(pk_i^{r,1}\): that is, he propagates \(\text{sig}_{pk_i^{r,1}}(H(B_i^r))\). Given our conventions, rather than propagating \(B_i^r\) and \(\text{sig}_{pk_i^{r,1}}(H(B_i^r))\), he could have propagated \(\text{SIG}_{pk_i^{r,1}}(H(B_i^r))\). However, in our analysis we need to have explicit access to \(\text{sig}_{pk_i^{r,1}}(H(B_i^r))\). Steps 2. In this step, each verifier \(i\) sets \(\ell_i^r\) to be the potential leader whose hashed credential is the smallest, and \(B_i^r\) to be the block proposed by \(\ell_i^r\). Since, for the sake of efficiency, we wish to agree on \(H(B_r)\), rather than directly on \(B_r\), \(i\) propagates the message he would have propagated in the first step of \(\text{BA}^\star\) with initial value \(v'_i = H(B_i^r)\). That is, he propagates \(v'_i\), after ephemerally signing it, of course. (Namely, after signing it relative to the right ephemeral public key, which in this case is \(pk_i^{r,2}\).) Of course too, \(i\) also transmits his own credential. Since the first step of \(\text{BA}^\star\) consists of the first step of the graded consensus protocol GC, Step 2 of \(\text{Algorand}^\prime\) corresponds to the first step of GC. Steps 3. In this step, each verifier \(i \in SV^{r,2}\) executes the second step of \(\text{BA}^\star\). That is, he sends the same message he would have sent in the second step of GC. Again, \(i\)'s message is ephemerally signed and accompanied by \(i\)'s credential. (From now on, we shall omit saying that a verifier ephemerally signs his message and also propagates his credential.) Step 4. In this step, every verifier \(i \in SV^{r,4}\) computes the output of GC, \((v_i, g_i)\), and ephemerally signs and sends the same message he would have sent in the third step of \(\text{BA}^\star\), that is, in the first step of \(\text{BBA}^\star\), with initial bit 0 if \(g_i = 2\), and 1 otherwise. Step \(s = 5, \ldots, m + 2\). Such a step, if ever reached, corresponds to step \(s - 1\) of \(\text{BA}^\star\), and thus to step \(s - 3\) of \(\text{BBA}^\star\). Since our propagation model is sufficiently asynchronous, we must account for the possibility that, in the middle of such a step \(s\), a verifier \(i \in SV^{r,s}\) is reached by information proving him that block \(B_r\) has already been chosen. In this case, \(i\) stops his own execution of round \(r\) of \(\text{Algorand}^\prime\), and starts executing his round-\((r + 1)\) instructions. \(\{r', \ldots, r' + 10^6\} \times \{1, \ldots, m + 3\}\). Then he orders these public keys in a canonical way, stores the \(j\)th public key in the \(j\)th leaf of a Merkle tree, and computes the root value \(R_i\), which he publicizes. When he wants to sign a message relative to key \(pk_i^{r,s}\), \(i\) not only provides the actual signature, but also the authenticating path for \(pk_i^{r,s}\) relative to \(R_i\). Notice that this authenticating path also proves that \(pk_i^{r,s}\) is stored in the \(j\)th leaf. The rest of the details can be easily filled.

Accordingly, the instructions of a verifier \(i \in SV^{r,s}\), in addition to the instructions corresponding to Step \(s - 3\) of \(\text{BBA}^\star\), include checking whether the execution of \(\text{BBA}^\star\) has halted in a prior Step \(s'\). Since \(\text{BBA}^\star\) can only halt is a Coin-Fixed-to-0 Step or in a Coin-Fixed-to-1 step, the instructions distinguish whether A (Ending Condition 0): \(s' - 2 \equiv 0 \bmod 3\), or B (Ending Condition 1): \(s' - 2 \equiv 1 \bmod 3\). In fact, in case A, the block \(B_r\) is non-empty, and thus additional instructions are necessary to ensure that \(i\) properly reconstructs \(B_r\), together with its proper certificate \(CERT_r\). In case B, the block \(B_r\) is empty, and thus \(i\) is instructed to set \(B_r = B_\epsilon^r = (r, \emptyset, H(Q_{r-1}, r), H(B_{r-1}))\), and to compute \(CERT_r\). If, during his execution of step \(s\), \(i\) does not see any evidence that the block \(B_r\) has already been generated, then he sends the same message he would have sent in step \(s - 3\) of \(\text{BBA}^\star\). Step \(m + 3\). If, during step \(m + 3\), \(i \in SV^{r,m+3}\) sees that the block \(B_r\) was already generated in a prior step \(s'\), then he proceeds just as explained above. Else, rather then sending the same message he would have sent in step \(m\) of \(\text{BBA}^\star\), \(i\) is instructed, based on the information in his possession, to compute \(B_r\) and its corresponding certificate \(CERT_r\). Recall, in fact, that we upperbound by \(m + 3\) the total number of steps of a round. 5.4 The Actual Protocol Recall that, in each step \(s\) of a round \(r\), a verifier \(i \in SV^{r,s}\) uses his long-term public-secret key pair to produce his credential, \(\sigma_i^{r,s} \triangleq \text{SIG}_i(r, s, Q_{r-1})\), as well as \(\text{SIG}_i(Q_{r-1})\) in case \(s = 1\). Verifier \(i\) uses his ephemeral secret key \(sk_i^{r,s}\) to sign his \((r, s)\)-message \(m_i^{r,s}\). For simplicity, when \(r\) and \(s\) are clear, we write \(esig_i(x)\) rather than \(sig_{pk_i^{r,s}}(x)\) to denote \(i\)'s proper ephemeral signature of a value \(x\) in step \(s\) of round \(r\), and write \(\text{ESIG}_i(x)\) instead of \(\text{SIG}_{pk_i^{r,s}}(x)\) to denote \((i, x, esig_i(x))\). Step 1: Block Proposal Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 1 of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,1}\) or not. \(\bullet\) If \(i \notin SV^{r,1}\), then \(i\) stops his own execution of Step 1 right away. \(\bullet\) If \(i \in SV^{r,1}\), that is, if \(i\) is a potential leader, then he collects the round-\(r\) payments that have been propagated to him so far and computes a maximal payset \(PAY_i^r\) from them. Next, he computes his "candidate block" \(B_i^r = (r, PAY_i^r, \text{SIG}_i(Q_{r-1}), H(B_{r-1}))\). Finally, he computes the message \(m_i^{r,1} = (B_i^r, esig_i(H(B_i^r)), \sigma_i^{r,1})\), destroys his ephemeral secret key \(sk_i^{r,1}\), and then propagates \(m_i^{r,1}\).

Remark. In practice, to shorten the global execution of Step 1, it is important that the \((r, 1)\)- messages are selectively propagated. That is, for every user \(i\) in the system, for the first \((r, 1)\)- message that he ever receives and successfully verifies,17 player \(i\) propagates it as usual. For all the other \((r, 1)\)-messages that player \(i\) receives and successfully verifies, he propagates it only if the hash value of the credential it contains is the smallest among the hash values of the credentials contained in all \((r, 1)\)-messages he has received and successfully verified so far. Furthermore, as suggested by Georgios Vlachos, it is useful that each potential leader \(i\) also propagates his credential \(\sigma_i^{r,1}\) separately: those small messages travel faster than blocks, ensure timely propagation of the \(m_j^{r,1}\)'s where the contained credentials have small hash values, while make those with large hash values disappear quickly. Step 2: The First Step of the Graded Consensus Protocol \(\text{GC}\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 2 of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,2}\) or not. \(\bullet\) If \(i \notin SV^{r,2}\) then \(i\) stops his own execution of Step 2 right away. \(\bullet\) If \(i \in SV^{r,2}\), then after waiting an amount of time \(t_2 \triangleq \lambda + \Lambda\), \(i\) acts as follows. 1. He finds the user \(\ell\) such that \(H(\sigma_\ell^{r,1}) \leq H(\sigma_j^{r,1})\) for all credentials \(\sigma_j^{r,1}\) that are part of the successfully verified \((r, 1)\)-messages he has received so far.a 2. If he has received from \(\ell\) a valid message \(m_\ell^{r,1} = (B_\ell^r, esig_\ell(H(B_\ell^r)), \sigma_\ell^{r,1})\),b then \(i\) sets \(v'_i \triangleq H(B_\ell^r)\); otherwise \(i\) sets \(v'_i \triangleq \bot\). 3. \(i\) computes the message \(m_i^{r,2} \triangleq (\text{ESIG}_i(v'_i), \sigma_i^{r,2})\),c destroys his ephemeral secret key \(sk_i^{r,2}\), and then propagates \(m_i^{r,2}\). aEssentially, user \(i\) privately decides that the leader of round \(r\) is user \(\ell\). bAgain, player \(\ell\)'s signatures and the hashes are all successfully verified, and \(PAY_\ell^r\) in \(B_\ell^r\) is a valid payset for round \(r\) —although \(i\) does not check whether \(PAY_\ell^r\) is maximal for \(\ell\) or not. cThe message \(m_i^{r,2}\) signals that player \(i\) considers \(v'_i\) to be the hash of the next block, or considers the next block to be empty. 17That is, all the signatures are correct and both the block and its hash are valid —although \(i\) does not check whether the included payset is maximal for its proposer or not.

Step 3: The Second Step of \(\text{GC}\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 3 of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,3}\) or not. \(\bullet\) If \(i \notin SV^{r,3}\), then \(i\) stops his own execution of Step 3 right away. \(\bullet\) If \(i \in SV^{r,3}\), then after waiting an amount of time \(t_3 \triangleq t_2 + 2\lambda = 3\lambda + \Lambda\), \(i\) acts as follows. 1. If there exists a value \(v' \neq \bot\) such that, among all the valid messages \(m_j^{r,2}\) he has received, more than \(2/3\) of them are of the form \((\text{ESIG}_j(v'), \sigma_j^{r,2})\), without any contradiction,a then he computes the message \(m_i^{r,3} \triangleq (\text{ESIG}_i(v'), \sigma_i^{r,3})\). Otherwise, he computes \(m_i^{r,3} \triangleq (\text{ESIG}_i(\bot), \sigma_i^{r,3})\). 2. \(i\) destroys his ephemeral secret key \(sk_i^{r,3}\), and then propagates \(m_i^{r,3}\). aThat is, he has not received two valid messages containing \(\text{ESIG}_j(v')\) and a different \(\text{ESIG}_j(v'')\) respectively, from a player \(j\). Here and from here on, except in the Ending Conditions defined later, whenever an honest player wants messages of a given form, messages contradicting each other are never counted or considered valid.

Step 4: Output of \(\text{GC}\) and The First Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 4 of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,4}\) or not. \(\bullet\) If \(i \notin SV^{r,4}\), then \(i\) his stops his own execution of Step 4 right away. \(\bullet\) If \(i \in SV^{r,4}\), then after waiting an amount of time \(t_4 \triangleq t_3 + 2\lambda = 5\lambda + \Lambda\), \(i\) acts as follows. 1. He computes \(v_i\) and \(g_i\), the output of \(\text{GC}\), as follows. (a) If there exists a value \(v' \neq \bot\) such that, among all the valid messages \(m_j^{r,3}\) he has received, more than \(2/3\) of them are of the form \((\text{ESIG}_j(v'), \sigma_j^{r,3})\), then he sets \(v_i \triangleq v'\) and \(g_i \triangleq 2\). (b) Otherwise, if there exists a value \(v' \neq \bot\) such that, among all the valid messages \(m_j^{r,3}\) he has received, more than \(1/3\) of them are of the form \((\text{ESIG}_j(v'), \sigma_j^{r,3})\), then he sets \(v_i \triangleq v'\) and \(g_i \triangleq 1\).a (c) Else, he sets \(v_i \triangleq H(B_\epsilon^r)\) and \(g_i \triangleq 0\). 2. He computes \(b_i\), the input of \(\text{BBA}^\star\), as follows: \(b_i \triangleq 0\) if \(g_i = 2\), and \(b_i \triangleq 1\) otherwise. 3. He computes the message \(m_i^{r,4} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,4})\), destroys his ephemeral secret key \(sk_i^{r,4}\), and then propagates \(m_i^{r,4}\). aIt can be proved that the \(v'\) in case (b), if exists, must be unique.

Step \(s\), \(5 \leq s \leq m + 2\), \(s - 2 \equiv 0 \bmod 3\): A Coin-Fixed-To-0 Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,s}\). \(\bullet\) If \(i \notin SV^{r,s}\), then \(i\) stops his own execution of Step \(s\) right away. \(\bullet\) If \(i \in SV^{r,s}\) then he acts as follows. – He waits until an amount of time \(t_s \triangleq t_{s-1} + 2\lambda = (2s - 3)\lambda + \Lambda\) has passed. – Ending Condition 0: If, during such waiting and at any point of time, there exists a string \(v \neq \bot\) and a step \(s'\) such that (a) \(5 \leq s' \leq s\), \(s' - 2 \equiv 0 \bmod 3\) —that is, Step \(s'\) is a Coin-Fixed-To-0 step, (b) \(i\) has received at least \(t_H = \frac{2n}{3} + 1\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(0), \text{ESIG}_j(v), \sigma_j^{r,s'-1})\),a and (c) \(i\) has received a valid message \(m_j^{r,1} = (B_j^r, esig_j(H(B_j^r)), \sigma_j^{r,1})\) with \(v = H(B_j^r)\), then, \(i\) stops his own execution of Step \(s\) (and in fact of round \(r\)) right away without propagating anything; sets \(B_r = B_j^r\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of sub-step (b).b – Ending Condition 1: If, during such waiting and at any point of time, there exists a step \(s'\) such that (a') \(6 \leq s' \leq s\), \(s' - 2 \equiv 1 \bmod 3\) —that is, Step \(s'\) is a Coin-Fixed-To-1 step, and (b') \(i\) has received at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s'-1})\),c then, \(i\) stops his own execution of Step \(s\) (and in fact of round \(r\)) right away without propagating anything; sets \(B_r = B_\epsilon^r\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of sub-step (b'). – Otherwise, at the end of the wait, user \(i\) does the following. He sets \(v_i\) to be the majority vote of the \(v_j\)'s in the second components of all the valid \(m_j^{r,s-1}\)'s he has received. He computes \(b_i\) as follows. If more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 0\). Else, if more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 1\). Else, he sets \(b_i \triangleq 0\). He computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\), destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\). aSuch a message from player \(j\) is counted even if player \(i\) has also received a message from \(j\) signing for 1. Similar things for Ending Condition 1. As shown in the analysis, this is done to ensure that all honest users know \(B_r\) within time \(\lambda\) from each other. bUser \(i\) now knows \(B_r\) and his own round \(r\) finishes. He still helps propagating messages as a generic user, but does not initiate any propagation as a \((r, s)\)-verifier. In particular, he has helped propagating all messages in his \(\text{CERT}^r\), which is enough for our protocol. Note that he should also set \(b_i \triangleq 0\) for the binary BA protocol, but \(b_i\) is not needed in this case anyway. Similar things for all future instructions. cIn this case, it does not matter what the \(v_j\)'s are.

Step \(s\), \(6 \leq s \leq m + 2\), \(s - 2 \equiv 1 \bmod 3\): A Coin-Fixed-To-1 Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,s}\) or not. \(\bullet\) If \(i \notin SV^{r,s}\), then \(i\) stops his own execution of Step \(s\) right away. \(\bullet\) If \(i \in SV^{r,s}\) then he does the follows. – He waits until an amount of time \(t_s \triangleq (2s - 3)\lambda + \Lambda\) has passed. – Ending Condition 0: The same instructions as Coin-Fixed-To-0 steps. – Ending Condition 1: The same instructions as Coin-Fixed-To-0 steps. – Otherwise, at the end of the wait, user \(i\) does the following. He sets \(v_i\) to be the majority vote of the \(v_j\)'s in the second components of all the valid \(m_j^{r,s-1}\)'s he has received. He computes \(b_i\) as follows. If more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 0\). Else, if more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 1\). Else, he sets \(b_i \triangleq 1\). He computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\), destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\).

Step \(s\), \(7 \leq s \leq m + 2\), \(s - 2 \equiv 2 \bmod 3\): A Coin-Genuinely-Flipped Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,s}\) or not. \(\bullet\) If \(i \notin SV^{r,s}\), then \(i\) stops his own execution of Step \(s\) right away. \(\bullet\) If \(i \in SV^{r,s}\) then he does the follows. – He waits until an amount of time \(t_s \triangleq (2s - 3)\lambda + \Lambda\) has passed. – Ending Condition 0: The same instructions as Coin-Fixed-To-0 steps. – Ending Condition 1: The same instructions as Coin-Fixed-To-0 steps. – Otherwise, at the end of the wait, user \(i\) does the following. He sets \(v_i\) to be the majority vote of the \(v_j\)'s in the second components of all the valid \(m_j^{r,s-1}\)'s he has received. He computes \(b_i\) as follows. If more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 0\). Else, if more than \(2/3\) of all the valid \(m_j^{r,s-1}\)'s he has received are of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he sets \(b_i \triangleq 1\). Else, let \(SV_i^{r,s-1}\) be the set of \((r, s - 1)\)-verifiers from whom he has received a valid message \(m_j^{r,s-1}\). He sets \(b_i \triangleq \text{lsb}(\min_{j \in SV_i^{r,s-1}} H(\sigma_j^{r,s-1}))\). He computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\), destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\).

Step \(m + 3\): The Last Step of \(\text{BBA}^\star\)a Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(m + 3\) of round \(r\) as soon as he knows \(B_{r-1}\). \(\bullet\) User \(i\) computes \(Q_{r-1}\) from the third component of \(B_{r-1}\) and checks whether \(i \in SV^{r,m+3}\) or not. \(\bullet\) If \(i \notin SV^{r,m+3}\), then \(i\) stops his own execution of Step \(m + 3\) right away. \(\bullet\) If \(i \in SV^{r,m+3}\) then he does the follows. – He waits until an amount of time \(t_{m+3} \triangleq t_{m+2} + 2\lambda = (2m + 3)\lambda + \Lambda\) has passed. – Ending Condition 0: The same instructions as Coin-Fixed-To-0 steps. – Ending Condition 1: The same instructions as Coin-Fixed-To-0 steps. – Otherwise, at the end of the wait, user \(i\) does the following. He sets \(out_i \triangleq 1\) and \(B_r \triangleq B_\epsilon^r\). He computes the message \(m_i^{r,m+3} = (\text{ESIG}_i(out_i), \text{ESIG}_i(H(B_r)), \sigma_i^{r,m+3})\), destroys his ephemeral secret key \(sk_i^{r,m+3}\), and then propagates \(m_i^{r,m+3}\) to certify \(B_r\).b aWith overwhelming probability \(\text{BBA}^\star\) has ended before this step, and we specify this step for completeness. bA certificate from Step \(m + 3\) does not have to include \(\text{ESIG}_i(out_i)\). We include it for uniformity only: the certificates now have a uniform format no matter in which step they are generated.

Reconstruction of the Round-\(r\) Block by Non-Verifiers Instructions for every user \(i\) in the system: User \(i\) starts his own round \(r\) as soon as he knows \(B_{r-1}\), and waits for block information as follows. – If, during such waiting and at any point of time, there exists a string \(v\) and a step \(s'\) such that (a) \(5 \leq s' \leq m + 3\) with \(s' - 2 \equiv 0 \bmod 3\), (b) \(i\) has received at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(0), \text{ESIG}_j(v), \sigma_j^{r,s'-1})\), and (c) \(i\) has received a valid message \(m_j^{r,1} = (B_j^r, esig_j(H(B_j^r)), \sigma_j^{r,1})\) with \(v = H(B_j^r)\), then, \(i\) stops his own execution of round \(r\) right away; sets \(B_r = B_j^r\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of sub-step (b). – If, during such waiting and at any point of time, there exists a step \(s'\) such that (a') \(6 \leq s' \leq m + 3\) with \(s' - 2 \equiv 1 \bmod 3\), and (b') \(i\) has received at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s'-1})\), then, \(i\) stops his own execution of round \(r\) right away; sets \(B_r = B_\epsilon^r\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of sub-step (b'). – If, during such waiting and at any point of time, \(i\) has received at least \(t_H\) valid messages \(m_j^{r,m+3} = (\text{ESIG}_j(1), \text{ESIG}_j(H(B_\epsilon^r)), \sigma_j^{r,m+3})\), then \(i\) stops his own execution of round \(r\) right away, sets \(B_r = B_\epsilon^r\), and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,m+3}\) for 1 and \(H(B_\epsilon^r)\). 5.5 Analysis of \(\text{Algorand}'_1\) We introduce the following notations for each round \(r \geq 0\), used in the analysis. \(\bullet\) Let \(T^r\) be the time when the first honest user knows \(B_{r-1}\). \(\bullet\) Let \(I^{r+1}\) be the interval \([T^{r+1}, T^{r+1} + \lambda]\). Note that \(T^0 = 0\) by the initialization of the protocol. For each \(s \geq 1\) and \(i \in SV^{r,s}\), recall that \(\alpha_i^{r,s}\)

and \(\beta_i^{r,s}\) are respectively the starting time and the ending time of player \(i\)'s step \(s\). Moreover, recall that \(t_s = (2s - 3)\lambda + \Lambda\) for each \(2 \leq s \leq m + 3\). In addition, let \(I_0 \triangleq \{0\}\) and \(t_1 \triangleq 0\). Finally, recall that \(L_r \leq m/3\) is a random variable representing the number of Bernoulli trials needed to see a 1, when each trial is 1 with probability \(\frac{p_h}{2}\) and there are at most \(m/3\) trials. If all trials fail then \(L_r \triangleq m/3\). In the analysis we ignore computation time, as it is in fact negligible relative to the time needed to propagate messages. In any case, by using slightly larger \(\lambda\) and \(\Lambda\), the computation time can be incorporated into the analysis directly. Most of the statements below hold “with overwhelming probability,” and we may not repeatedly emphasize this fact in the analysis.

5.6 Main Theorem Theorem 5.1. The following properties hold with overwhelming probability for each round \(r \geq 0\): 1. All honest users agree on the same block \(B_r\). 2. When the leader \(\ell_r\) is honest, the block \(B_r\) is generated by \(\ell_r\), \(B_r\) contains a maximal payset received by \(\ell_r\) by time \(\alpha_{\ell_r}^{r,1}\), \(T^{r+1} \leq T^r + 8\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). 3. When the leader \(\ell_r\) is malicious, \(T^{r+1} \leq T^r + (6L_r + 10)\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). 4. \(p_h = h^2(1 + h - h^2)\) for \(L_r\), and the leader \(\ell_r\) is honest with probability at least \(p_h\). Before proving our main theorem, let us make two remarks. Remarks. • Block-Generation and True Latency. The time to generate block \(B_r\) is defined to be \(T^{r+1} - T^r\). That is, it is defined to be the difference between the first time some honest user learns \(B_r\) and the first time some honest user learns \(B_{r-1}\). When the round-\(r\) leader is honest, Property 2 our main theorem guarantees that the exact time to generate \(B_r\) is \(8\lambda + \Lambda\) time, no matter what the precise value of \(h > 2/3\) may be. When the leader is malicious, Property 3 implies that the expected time to generate \(B_r\) is upperbounded by \((\frac{12}{p_h} + 10)\lambda + \Lambda\), again no matter the precise value of \(h\).18 However, the expected time to generate \(B_r\) depends on the precise value of \(h\). Indeed, by Property 4, \(p_h = h^2(1 + h - h^2)\) and the leader is honest with probability at least \(p_h\), thus \(E[T^{r+1} - T^r] \leq h^2(1 + h - h^2) \cdot (8\lambda + \Lambda) + (1 - h^2(1 + h - h^2))((\frac{12}{h^2(1 + h - h^2)} + 10)\lambda + \Lambda)\). For instance, if \(h = 80\%\), then \(E[T^{r+1} - T^r] \leq 12.7\lambda + \Lambda\). • \(\lambda\) vs. \(\Lambda\). Note that the size of the messages sent by the verifiers in a step \(\text{Algorand}^\prime\) is dominated by the length of the digital signature keys, which can remain fixed, even when the number of users is enormous. Also note that, in any step \(s > 1\), the same expected number \(n\) of verifiers can be used whether the number of users is 100K, 100M, or 100M. This is so because \(n\) solely depends on \(h\) and \(F\). In sum, therefore, barring a sudden need to increase secret key length, the value of \(\lambda\) should remain the same no matter how large the number of users may be in the foreseeable future. By contrast, for any transaction rate, the number of transactions grows with the number of users. Therefore, to process all new transactions in a timely fashion, the size of a block should also grow with the number of users, causing \(\Lambda\) to grow too. Thus, in the long run, we should have \(\lambda \ll \Lambda\). Accordingly, it is proper to have a larger coefficient for \(\lambda\), and actually a coefficient of 1 for \(\Lambda\). Proof of Theorem 5.1. We prove Properties 1–3 by induction: assuming they hold for round \(r - 1\) (without loss of generality, they automatically hold for "round -1" when \(r = 0\)), we prove them for round \(r\). 18Indeed, \(E[T^{r+1} - T^r] \leq (6E[L_r] + 10)\lambda + \Lambda = (6 \cdot \frac{2}{p_h} + 10)\lambda + \Lambda = (\frac{12}{p_h} + 10)\lambda + \Lambda\).

Since \(B_{r-1}\) is uniquely defined by the inductive hypothesis, the set \(SV^{r,s}\) is uniquely defined for each step \(s\) of round \(r\). By the choice of \(n_1\), \(SV^{r,1} \neq \emptyset\) with overwhelming probability. We now state the following two lemmas, proved in Sections 5.7 and 5.8. Throughout the induction and in the proofs of the two lemmas, the analysis for round 0 is almost the same as the inductive step, and we will highlight the differences when they occur. Lemma 5.2. [Completeness Lemma] Assuming Properties 1–3 hold for round \(r-1\), when the leader \(\ell_r\) is honest, with overwhelming probability, • All honest users agree on the same block \(B_r\), which is generated by \(\ell_r\) and contains a maximal payset received by \(\ell_r\) by time \(\alpha_{\ell_r}^{r,1} \in I_r\); and • \(T^{r+1} \leq T^r + 8\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). Lemma 5.3. [Soundness Lemma] Assuming Properties 1–3 hold for round \(r - 1\), when the leader \(\ell_r\) is malicious, with overwhelming probability, all honest users agree on the same block \(B_r\), \(T^{r+1} \leq T^r + (6L_r + 10)\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). Properties 1–3 hold by applying Lemmas 5.2 and 5.3 to r = 0 and to the inductive step. Finally, we restate Property 4 as the following lemma, proved in Section 5.9. Lemma 5.4. Given Properties 1–3 for each round before \(r\), \(p_h = h^2(1 + h - h^2)\) for \(L_r\), and the leader \(\ell_r\) is honest with probability at least \(p_h\). Combining the above three lemmas together, Theorem 5.1 holds. ■ The lemma below states several important properties about round \(r\) given the inductive hypothesis, and will be used in the proofs of the above three lemmas. Lemma 5.5. Assume Properties 1–3 hold for round \(r - 1\). For each step \(s \geq 1\) of round \(r\) and each honest verifier \(i \in HSV^{r,s}\), we have that (a) \(\alpha_i^{r,s} \in I_r\); (b) if player \(i\) has waited an amount of time \(t_s\), then \(\beta_i^{r,s} \in [T^r + t_s, T^r + \lambda + t_s]\) for \(r > 0\) and \(\beta_i^{r,s} = t_s\) for \(r = 0\); and (c) if player \(i\) has waited an amount of time \(t_s\), then by time \(\beta_i^{r,s}\), he has received all messages sent by all honest verifiers \(j \in HSV^{r,s'}\) for all steps \(s' < s\). Moreover, for each step \(s \geq 3\), we have that (d) there do not exist two different players \(i, i' \in SV^{r,s}\) and two different values \(v, v'\) of the same length, such that both players have waited an amount of time \(t_s\), more than 2/3 of all the valid messages \(m_j^{r,s-1}\) player \(i\) receives have signed for \(v\), and more than 2/3 of all the valid messages \(m_j^{r,s-1}\) player \(i'\) receives have signed for \(v'\). Proof. Property (a) follows directly from the inductive hypothesis, as player \(i\) knows \(B_{r-1}\) in the time interval \(I_r\) and starts his own step \(s\) right away. Property (b) follows directly from (a): since player \(i\) has waited an amount of time \(t_s\) before acting, \(\beta_i^{r,s} = \alpha_i^{r,s} + t_s\). Note that \(\alpha_i^{r,s} = 0\) for \(r = 0\). We now prove Property (c). If \(s = 2\), then by Property (b), for all verifiers \(j \in HSV^{r,1}\) we have \(\beta_i^{r,s} = \alpha_i^{r,s} + t_s \geq T^r + t_s = T^r + \lambda + \Lambda \geq \beta_j^{r,1} + \Lambda\).

Since each verifier \(j \in HSV^{r,1}\) sends his message at time \(\beta_j^{r,1}\) and the message reaches all honest users in at most \(\Lambda\) time, by time \(\beta_i^{r,s}\) player \(i\) has received the messages sent by all verifiers in \(HSV^{r,1}\) as desired. If \(s > 2\), then \(t_s = t_{s-1} + 2\lambda\). By Property (b), for all steps \(s' < s\) and all verifiers \(j \in HSV^{r,s'}\), \(\beta_i^{r,s} = \alpha_i^{r,s} + t_s \geq T^r + t_s = T^r + t_{s-1} + 2\lambda \geq T^r + t_{s'} + 2\lambda = T^r + \lambda + t_{s'} + \lambda \geq \beta_j^{r,s'} + \lambda\). Since each verifier \(j \in HSV^{r,s'}\) sends his message at time \(\beta_j^{r,s'}\) and the message reaches all honest users in at most \(\lambda\) time, by time \(\beta_i^{r,s}\) player \(i\) has received all messages sent by all honest verifiers in \(HSV^{r,s'}\) for all \(s' < s\). Thus Property (c) holds. Finally, we prove Property (d). Note that the verifiers \(j \in SV^{r,s-1}\) sign at most two things in Step \(s - 1\) using their ephemeral secret keys: a value \(v_j\) of the same length as the output of the hash function, and also a bit \(b_j \in \{0, 1\}\) if \(s - 1 \geq 4\). That is why in the statement of the lemma we require that \(v\) and \(v'\) have the same length: many verifiers may have signed both a hash value \(v\) and a bit \(b\), thus both pass the 2/3 threshold. Assume for the sake of contradiction that there exist the desired verifiers \(i, i'\) and values \(v, v'\). Note that some malicious verifiers in \(MSV^{r,s-1}\) may have signed both \(v\) and \(v'\), but each honest verifier in \(HSV^{r,s-1}\) has signed at most one of them. By Property (c), both \(i\) and \(i'\) have received all messages sent by all honest verifiers in \(HSV^{r,s-1}\). Let \(HSV^{r,s-1}(v)\) be the set of honest \((r, s - 1)\)-verifiers who have signed \(v\), \(MSV_i^{r,s-1}\) the set of malicious \((r, s - 1)\)-verifiers from whom \(i\) has received a valid message, and \(MSV_i^{r,s-1}(v)\) the subset of \(MSV_i^{r,s-1}\) from whom \(i\) has received a valid message signing \(v\). By the requirements for \(i\) and \(v\), we have \(\text{ratio} \triangleq \frac{|HSV^{r,s-1}(v)| + |MSV_i^{r,s-1}(v)|}{|HSV^{r,s-1}| + |MSV_i^{r,s-1}|} > \frac{2}{3}\). (1) We first show \(|MSV_i^{r,s-1}(v)| \leq |HSV^{r,s-1}(v)|\). (2) Assuming otherwise, by the relationships among the parameters, with overwhelming probability \(|HSV^{r,s-1}| > 2|MSV^{r,s-1}| \geq 2|MSV_i^{r,s-1}|\), thus \(\text{ratio} < \frac{|HSV^{r,s-1}(v)| + |MSV_i^{r,s-1}(v)|}{3|MSV_i^{r,s-1}|} < \frac{2|MSV_i^{r,s-1}(v)|}{3|MSV_i^{r,s-1}|} \leq \frac{2}{3},\) contradicting Inequality 1. Next, by Inequality 1 we have \(2|HSV^{r,s-1}| + 2|MSV_i^{r,s-1}| < 3|HSV^{r,s-1}(v)| + 3|MSV_i^{r,s-1}(v)| \leq 3|HSV^{r,s-1}(v)| + 2|MSV_i^{r,s-1}| + |MSV_i^{r,s-1}(v)|.\) Combining with Inequality 2, \(2|HSV^{r,s-1}| < 3|HSV^{r,s-1}(v)| + |MSV_i^{r,s-1}(v)| \leq 4|HSV^{r,s-1}(v)|,\) which implies \(|HSV^{r,s-1}(v)| > \frac{1}{2}|HSV^{r,s-1}|.\)

Similarly, by the requirements for \(i'\) and \(v'\), we have \(|HSV^{r,s-1}(v')| > \frac{1}{2}|HSV^{r,s-1}|.\) Since an honest verifier \(j \in HSV^{r,s-1}\) destroys his ephemeral secret key \(sk_j^{r,s-1}\) before propagating his message, the Adversary cannot forge \(j\)'s signature for a value that \(j\) did not sign, after learning that \(j\) is a verifier. Thus, the two inequalities above imply \(|HSV^{r,s-1}| \geq |HSV^{r,s-1}(v)| +\) \(|HSV^{r,s-1}(v')| > |HSV^{r,s-1}|\), a contradiction. Accordingly, the desired \(i, i', v, v'\) do not exist, and Property (d) holds. ■ 5.7 The Completeness Lemma Lemma 5.2. [Completeness Lemma, restated] Assuming Properties 1–3 hold for round \(r-1\), when the leader \(\ell_r\) is honest, with overwhelming probability, - All honest users agree on the same block \(B_r\), which is generated by \(\ell_r\) and contains a maximal payset received by \(\ell_r\) by time \(\alpha_{\ell_r}^{r,1} \in I_r\); and - \(T^{r+1} \leq T^r + 8\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). Proof. By the inductive hypothesis and Lemma 5.5, for each step \(s\) and verifier \(i \in HSV^{r,s}\), \(\alpha_i^{r,s} \in I_r\). Below we analyze the protocol step by step. Step 1. By definition, every honest verifier \(i \in HSV^{r,1}\) propagates the desired message \(m_i^{r,1}\) at time \(\beta_i^{r,1} = \alpha_i^{r,1}\), where \(m_i^{r,1} = (B_i^r, \text{esig}_i(H(B_i^r)), \sigma_i^{r,1})\), \(B_i^r = (r, PAY_i^r, \text{SIG}_i(Q_{r-1}), H(B_{r-1}))\), and \(PAY_i^r\) is a maximal payset among all payments that \(i\) has seen by time \(\alpha_i^{r,1}\). Step 2. Arbitrarily fix an honest verifier \(i \in HSV^{r,2}\). By Lemma 5.5, when player \(i\) is done waiting at time \(\beta_i^{r,2} = \alpha_i^{r,2} + t_2\), he has received all messages sent by verifiers in \(HSV^{r,1}\), including \(m_{\ell_r}^{r,1}\). By the definition of \(\ell_r\), there does not exist another player in \(PK^{r-k}\) whose credential's hash value is smaller than \(H(\sigma_{\ell_r}^{r,1})\). Of course, the Adversary can corrupt \(\ell_r\) after seeing that \(H(\sigma_{\ell_r}^{r,1})\) is very small, but by that time player \(\ell_r\) has destroyed his ephemeral key and the message \(m_{\ell_r}^{r,1}\) has been propagated. Thus verifier \(i\) sets his own leader to be player \(\ell_r\). Accordingly, at time \(\beta_i^{r,2}\), verifier \(i\) propagates \(m_i^{r,2} = (\text{ESIG}_i(v'_i), \sigma_i^{r,2})\), where \(v'_i = H(B_{\ell_r}^r)\). When \(r = 0\), the only difference is that \(\beta_i^{r,2} = t_2\) rather than being in a range. Similar things can be said for future steps and we will not emphasize them again. Step 3. Arbitrarily fix an honest verifier \(i \in HSV^{r,3}\). By Lemma 5.5, when player \(i\) is done waiting at time \(\beta_i^{r,3} = \alpha_i^{r,3} + t_3\), he has received all messages sent by verifiers in \(HSV^{r,2}\). By the relationships among the parameters, with overwhelming probability \(|HSV^{r,2}| >\) \(2|MSV^{r,2}|\). Moreover, no honest verifier would sign contradicting messages, and the Adversary cannot forge a signature of an honest verifier after the latter has destroyed his corresponding ephemeral secret key. Thus more than 2/3 of all the valid \((r, 2)\)-messages \(i\) has received are from honest verifiers and of the form \(m_j^{r,2} = (\text{ESIG}_j(H(B_{\ell_r}^r)), \sigma_j^{r,2})\), with no contradiction. Accordingly, at time \(\beta_i^{r,3}\) player \(i\) propagates \(m_i^{r,3} = (\text{ESIG}_i(v'), \sigma_i^{r,3})\), where \(v' = H(B_{\ell_r}^r)\).

Step 4. Arbitrarily fix an honest verifier \(i \in HSV^{r,4}\). By Lemma 5.5, player \(i\) has received all messages sent by verifiers in \(HSV^{r,3}\) when he is done waiting at time \(\beta_i^{r,4} = \alpha_i^{r,4} + t_4\). Similar to Step 3, more than 2/3 of all the valid \((r, 3)\)-messages \(i\) has received are from honest verifiers and of the form \(m_j^{r,3} = (\text{ESIG}_j(H(B_{\ell_r}^r)), \sigma_j^{r,3})\). Accordingly, player \(i\) sets \(v_i = H(B_{\ell_r}^r)\), \(g_i = 2\) and \(b_i = 0\). At time \(\beta_i^{r,4} = \alpha_i^{r,4} + t_4\) he propagates \(m_i^{r,4} = (\text{ESIG}_i(0), \text{ESIG}_i(H(B_{\ell_r}^r)), \sigma_i^{r,4})\). Step 5. Arbitrarily fix an honest verifier \(i \in HSV^{r,5}\). By Lemma 5.5, player \(i\) would have received all messages sent by the verifiers in \(HSV^{r,4}\) if he has waited till time \(\alpha_i^{r,5} + t_5\). Note that \(|HSV^{r,4}| \geq t_H\).19 Also note that all verifiers in \(HSV^{r,4}\) have signed for \(H(B_{\ell_r}^r)\). As \(|MSV^{r,4}| < t_H\), there does not exist any \(v' \neq H(B_{\ell_r}^r)\) that could have been signed by \(t_H\) verifiers in \(SV^{r,4}\) (who would necessarily be malicious), so player \(i\) does not stop before he has received \(t_H\) valid messages \(m_j^{r,4} = (\text{ESIG}_j(0), \text{ESIG}_j(H(B_{\ell_r}^r)), \sigma_j^{r,4})\). Let \(T\) be the time when the latter event happens. Some of those messages may be from malicious players, but because \(|MSV^{r,4}| < t_H\), at least one of them is from an honest verifier in \(HSV^{r,4}\) and is sent after time \(T^r + t_4\). Accordingly, \(T \geq T^r + t_4 > T^r + \lambda + \Lambda \geq \beta_{\ell_r}^{r,1} + \Lambda\), and by time \(T\) player \(i\) has also received the message \(m_{\ell_r}^{r,1}\). By the construction of the protocol, player \(i\) stops at time \(\beta_i^{r,5} = T\) without propagating anything; sets \(B_r = B_{\ell_r}^r\); and sets his own \(\text{CERT}^r\) to be the set of \((r, 4)\)-messages for 0 and \(H(B_{\ell_r}^r)\) that he has received. Step \(s > 5\). Similarly, for any step \(s > 5\) and any verifier \(i \in HSV^{r,s}\), player \(i\) would have received all messages sent by the verifiers in \(HSV^{r,4}\) if he has waited till time \(\alpha_i^{r,s} + t_s\). By the same analysis, player \(i\) stops without propagating anything, setting \(B_r = B_{\ell_r}^r\) (and setting his own \(\text{CERT}^r\) properly). Of course, the malicious verifiers may not stop and may propagate arbitrary messages, but because \(|MSV^{r,s}| < t_H\), by induction no other \(v'\) could be signed by \(t_H\) verifiers in any step \(4 \leq s' < s\), thus the honest verifiers only stop because they have received \(t_H\) valid \((r, 4)\)-messages for 0 and \(H(B_{\ell_r}^r)\). Reconstruction of the Round-\(r\) Block. The analysis of Step 5 applies to a generic honest user \(i\) almost without any change. Indeed, player \(i\) starts his own round \(r\) in the interval \(I_r\) and will only stop at a time \(T\) when he has received \(t_H\) valid \((r, 4)\)-messages for \(H(B_{\ell_r}^r)\). Again because at least one of those messages are from honest verifiers and are sent after time \(T^r + t_4\), player \(i\) has also received \(m_{\ell_r}^{r,1}\) by time \(T\). Thus he sets \(B_r = B_{\ell_r}^r\) with the proper \(\text{CERT}^r\). It only remains to show that all honest users finish their round \(r\) within the time interval \(I_{r+1}\). By the analysis of Step 5, every honest verifier \(i \in HSV^{r,5}\) knows \(B_r\) on or before \(\alpha_i^{r,5} + t_5 \leq\) \(T^r + \lambda + t_5 = T^r + 8\lambda + \Lambda\). Since \(T^{r+1}\) is the time when the first honest user \(i_r\) knows \(B_r\), we have \(T^{r+1} \leq T^r + 8\lambda + \Lambda\) as desired. Moreover, when player \(i_r\) knows \(B_r\), he has already helped propagating the messages in his \(\text{CERT}^r\). Note that all those messages will be received by all honest users within time \(\lambda\), even if 19Strictly speaking, this happens with very high probability but not necessarily overwhelming. However, this probability slightly effects the running time of the protocol, but does not affect its correctness. When \(h = 80\%\), then \(|HSV^{r,4}| \geq t_H\) with probability \(1 - 10^{-8}\). If this event does not occur, then the protocol will continue for another 3 steps. As the probability that this does not occur in two steps is negligible, the protocol will finish at Step 8. In expectation, then, the number of steps needed is almost 5.

player \(i_r\) were the first player to propagate them. Moreover, following the analysis above we have \(T^{r+1} \geq T^r + t_4 \geq \beta_{\ell_r}^{r,1} + \Lambda\), thus all honest users have received \(m_{\ell_r}^{r,1}\) by time \(T^{r+1} + \lambda\). Accordingly, all honest users know \(B_r\) in the time interval \(I_{r+1} = [T^{r+1}, T^{r+1} + \lambda]\). Finally, for \(r = 0\) we actually have \(T^1 \leq t_4 + \lambda = 6\lambda + \Lambda\). Combining everything together, Lemma 5.2 holds. ■ 5.8 The Soundness Lemma Lemma 5.3. [Soundness Lemma, restated] Assuming Properties 1–3 hold for round \(r - 1\), when the leader \(\ell_r\) is malicious, with overwhelming probability, all honest users agree on the same block \(B_r\), \(T^{r+1} \leq T^r + (6L_r + 10)\lambda + \Lambda\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\). Proof. We consider the two parts of the protocol, GC and \(\text{BBA}^\star\), separately. GC. By the inductive hypothesis and by Lemma 5.5, for any step \(s \in \{2, 3, 4\}\) and any honest verifier \(i \in HSV^{r,s}\), when player \(i\) acts at time \(\beta_i^{r,s} = \alpha_i^{r,s} + t_s\), he has received all messages sent by all the honest verifiers in steps \(s' < s\). We distinguish two possible cases for step 4. Case 1. No verifier \(i \in HSV^{r,4}\) sets \(g_i = 2\). In this case, by definition \(b_i = 1\) for all verifiers \(i \in HSV^{r,4}\). That is, they start with an agreement on 1 in the binary BA protocol. They may not have an agreement on their \(v_i\)'s, but this does not matter as we will see in the binary BA. Case 2. There exists a verifier \(\hat{i} \in HSV^{r,4}\) such that \(g_{\hat{i}} = 2\). In this case, we show that (1) \(g_i \geq 1\) for all \(i \in HSV^{r,4}\), (2) there exists a value \(v'\) such that \(v_i = v'\) for all \(i \in HSV^{r,4}\), and (3) there exists a valid message \(m_\ell^{r,1}\) from some verifier \(\ell \in SV^{r,1}\) such that \(v' = H(B_\ell^r)\). Indeed, since player \(\hat{i}\) is honest and sets \(g_{\hat{i}} = 2\), more than 2/3 of all the valid messages \(m_j^{r,3}\) he has received are for the same value \(v' \neq \bot\), and he has set \(v_{\hat{i}} = v'\). By Property (d) in Lemma 5.5, for any other honest \((r, 4)\)-verifier \(i\), it cannot be that more than 2/3 of all the valid messages \(m_j^{r,3}\) that \(i'\) has received are for the same value \(v'' \neq v'\). Accordingly, if \(i\) sets \(g_i = 2\), it must be that \(i\) has seen > 2/3 majority for \(v'\) as well and set \(v_i = v'\), as desired. Now consider an arbitrary verifier \(i \in HSV^{r,4}\) with \(g_i < 2\). Similar to the analysis of Property (d) in Lemma 5.5, because player \(\hat{i}\) has seen > 2/3 majority for \(v'\), more than \(\frac{1}{2}|HSV^{r,3}|\) honest \((r, 3)\)-verifiers have signed \(v'\). Because \(i\) has received all messages by honest \((r, 3)\)-verifiers by time \(\beta_i^{r,4} = \alpha_i^{r,4} + t_4\), he has in particular received more than \(\frac{1}{2}|HSV^{r,3}|\) messages from them for \(v'\). Because \(|HSV^{r,3}| > 2|MSV^{r,3}|\), \(i\) has seen > 1/3 majority for \(v'\). Accordingly, player \(i\) sets \(g_i = 1\), and Property (1) holds. Does player \(i\) necessarily set \(v_i = v'\)? Assume there exists a different value \(v'' \neq \bot\) such that player \(i\) has also seen > 1/3 majority for \(v''\). Some of those messages may be from malicious verifiers, but at least one of them is from some honest verifier \(j \in HSV^{r,3}\): indeed, because \(|HSV^{r,3}| > 2|MSV^{r,3}|\) and \(i\) has received all messages from \(HSV^{r,3}\), the set of malicious verifiers from whom \(i\) has received a valid \((r, 3)\)-message counts for < 1/3 of all the valid messages he has received.

By definition, player j must have seen > 2/3 majority for \(v''\) among all the valid (r, 2)-messages he has received. However, we already have that some other honest (r, 3)-verifiers have seen

2/3 majority for \(v'\) (because they signed \(v'\)). By Property (d) of Lemma 5.5, this cannot happen and such a value \(v''\) does not exist. Thus player i must have set \(v_i = v'\) as desired, and Property (2) holds. Finally, given that some honest (r, 3)-verifiers have seen > 2/3 majority for \(v'\), some (actually, more than half of) honest (r, 2)-verifiers have signed for \(v'\) and propagated their messages. By the construction of the protocol, those honest (r, 2)-verifiers must have received a valid message \(m_\ell^{r,1}\) from some player \(\ell \in SV^{r,1}\) with \(v'\) = \(H(B_\ell^r)\), thus Property (3) holds. \(\text{BBA}^\star\). We again distinguish two cases. Case 1. All verifiers \(i \in HSV^{r,4}\) have \(b_i = 1\). This happens following Case 1 of GC. As \(|MSV^{r,4}|\) < \(t_H\), in this case no verifier in \(SV^{r,5}\) could collect or generate \(t_H\) valid (r, 4)-messages for bit 0. Thus, no honest verifier in \(HSV^{r,5}\) would stop because he knows a non-empty block \(B_r\). Moreover, although there are at least \(t_H\) valid \((r, 4)\)-messages for bit 1, \(s' = 5\) does not satisfy \(s' - 2 \equiv 1 \mod 3\), thus no honest verifier in \(HSV^{r,5}\) would stop because he knows \(B_r = B_\epsilon^r\). Instead, every verifier \(i \in HSV^{r,5}\) acts at time \(\beta_i^{r,5} = \alpha_i^{r,5} + t_5\), by when he has received all messages sent by \(HSV^{r,4}\) following Lemma 5.5. Thus player \(i\) has seen > 2/3 majority for 1 and sets \(b_i = 1\). In Step 6 which is a Coin-Fixed-To-1 step, although \(s' = 5\) satisfies \(s' - 2 \equiv 0 \mod 3\), there do not exist \(t_H\) valid \((r, 4)\)-messages for bit 0, thus no verifier in \(HSV^{r,6}\) would stop because he knows a non-empty block \(B_r\). However, with \(s' = 6\), \(s' - 2 \equiv 1 \mod 3\) and there do exist \(|HSV^{r,5}| \geq t_H\) valid \((r, 5)\)-messages for bit 1 from \(HSV^{r,5}\). For every verifier \(i \in HSV^{r,6}\), following Lemma 5.5, on or before time \(\alpha_i^{r,6} + t_6\) player \(i\) has received all messages from \(HSV^{r,5}\), thus \(i\) stops without propagating anything and sets \(B_r = B_\epsilon^r\). His \(\text{CERT}^r\) is the set of \(t_H\) valid \((r, 5)\)-messages \(m_j^{r,5} = (\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,5})\) received by him when he stops. Next, let player \(i\) be either an honest verifier in a step \(s > 6\) or a generic honest user (i.e., non-verifier). Similar to the proof of Lemma 5.2, player \(i\) sets \(B_r = B_\epsilon^r\) and sets his own \(\text{CERT}^r\) to be the set of \(t_H\) valid \((r, 5)\)-messages \(m_j^{r,5} = (\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,5})\) he has received. Finally, similar to Lemma 5.2, \(T^{r+1} \leq \min_{i \in HSV^{r,6}} \alpha_i^{r,6} + t_6 \leq T^r + \lambda + t_6 = T^r + 10\lambda + \Lambda,\) and all honest users know \(B_r\) in the time interval \(I_{r+1}\), because the first honest user \(i\) who knows \(B_r\) has helped propagating the \((r, 5)\)-messages in his \(\text{CERT}^r\). Case 2. There exists a verifier \(\hat{i} \in HSV^{r,4}\) with \(b_{\hat{i}} = 0\). This happens following Case 2 of GC and is the more complex case. By the analysis of GC, in this case there exists a valid message \(m_\ell^{r,1}\) such that \(v_i = H(B_\ell^r)\) for all \(i \in HSV^{r,4}\). Note that the verifiers in \(HSV^{r,4}\) may not have an agreement on their \(b_i\)'s. For any step \(s \in \{5, \ldots, m + 3\}\) and verifier \(i \in HSV^{r,s}\), by Lemma 5.5 player \(i\) would have received all messages sent by all honest verifiers in \(HSV^{r,4} \cup \cdots \cup HSV^{r,s-1}\) if he has waited for time \(t_s\).

We now consider the following event E: there exists a step \(s^* \geq 5\) such that, for the first time in the binary BA, some player \(i^* \in SV^{r,s^*}\) (whether malicious or honest) should stop without propagating anything. We use "should stop" to emphasize the fact that, if player \(i^*\) is malicious, then he may pretend that he should not stop according to the protocol and propagate messages of the Adversary's choice. Moreover, by the construction of the protocol, either (E.a) \(i^*\) is able to collect or generate at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(0), \text{ESIG}_j(v), \sigma_j^{r,s'-1})\) for the same \(v\) and \(s'\), with \(5 \leq s' \leq s^*\) and \(s' - 2 \equiv 0 \mod 3\); or (E.b) \(i^*\) is able to collect or generate at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s'-1})\) for the same \(s'\), with \(6 \leq s' \leq s^*\) and \(s' - 2 \equiv 1 \mod 3\). Because the honest \((r, s' - 1)\)-messages are received by all honest \((r, s')\)-verifiers before they are done waiting in Step \(s'\), and because the Adversary receives everything no later than the honest users, without loss of generality we have \(s' = s^*\) and player \(i^*\) is malicious. Note that we did not require the value v in E.a to be the hash of a valid block: as it will become clear in the analysis, v = \(H(B_\ell^r)\) in this sub-event. Below we first analyze Case 2 following event E, and then show that the value of \(s^*\) is essentially distributed accordingly to \(L_r\) (thus event E happens before Step m + 3 with overwhelming probability given the relationships for parameters). To begin with, for any step \(5 \leq s < s^*\), every honest verifier \(i \in HSV^{r,s}\) has waited time \(t_s\) and set \(v_i\) to be the majority vote of the valid \((r, s-1)\)-messages he has received. Since player \(i\) has received all honest \((r, s-1)\)-messages following Lemma 5.5, since all honest verifiers in \(HSV^{r,4}\) have signed \(H(B_\ell^r)\) following Case 2 of GC, and since \(|HSV^{r,s-1}| > 2|MSV^{r,s-1}|\) for each \(s\), by induction we have that player \(i\) has set \(v_i = H(B_\ell^r)\). The same holds for every honest verifier \(i \in HSV^{r,s^*}\) who does not stop without propagating anything. Now we consider Step \(s^*\) and distinguish four subcases. Case 2.1.a. Event E.a happens and there exists an honest verifier \(i' \in HSV^{r,s^*}\) who should also stop without propagating anything. In this case, we have \(s^* - 2 \equiv 0 \mod 3\) and Step \(s^*\) is a Coin-Fixed-To-0 step. By definition, player \(i'\) has received at least \(t_H\) valid (r, \(s^* - 1\))-messages of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v), \sigma_j^{r,s^*-1})\). Since all verifiers in \(HSV^{r,s^*-1}\) have signed \(H(B_\ell^r)\) and \(|MSV^{r,s^*-1}| < t_H\), we have v = \(H(B_\ell^r)\). Since at least \(t_H - |MSV^{r,s^*-1}| \geq 1\) of the (r, \(s^* - 1\))-messages received by \(i'\) for 0 and v are sent by verifiers in \(HSV^{r,s^*-1}\) after time \(T^r + t_{s^*-1} \geq T^r + t_4 \geq T^r + \lambda + \Lambda \geq \beta_{\ell}^{r,1} + \Lambda\), player \(i'\) has received \(m_\ell^{r,1}\) by the time he receives those (r, \(s^* - 1\))-messages. Thus player \(i'\) stops without propagating anything; sets \(B_r = B_\ell^r\); and sets his own \(\text{CERT}^r\) to be the set of valid (r, \(s^* - 1\))-messages for 0 and v that he has received. Next, we show that, any other verifier \(i \in HSV^{r,s^*}\) has either stopped with \(B_r = B_\ell^r\), or has set \(b_i = 0\) and propagated \((\text{ESIG}_i(0), \text{ESIG}_i(H(B_\ell^r)), \sigma_i^{r,s^*})\). Indeed, because Step \(s^*\) is the first time some verifier should stop without propagating anything, there does not exist a step \(s' < s^*\) with \(s' - 2 \equiv 1 \mod 3\) such that \(t_H\) \((r, s' - 1)\)-verifiers have signed 1. Accordingly, no verifier in \(HSV^{r,s^*}\) stops with \(B_r = B_\epsilon^r\).

Moreover, as all honest verifiers in steps {4, 5, . . . , \(s^* - 1\)} have signed \(H(B_\ell^r)\), there does not exist a step \(s' \leq s^*\) with \(s' - 2 \equiv 0 \mod 3\) such that \(t_H\) \((r, s' - 1)\)-verifiers have signed some \(v'' \neq H(B_\ell^r)\) —indeed, \(|MSV^{r,s'-1}| < t_H\). Accordingly, no verifier in \(HSV^{r,s^*}\) stops with \(B_r \neq B_\epsilon^r\) and \(B_r \neq B_\ell^r\). That is, if a player \(i \in HSV^{r,s^*}\) has stopped without propagating anything, he must have set \(B_r = B_\ell^r\). If a player \(i \in HSV^{r,s^*}\) has waited time \(t_{s^*}\) and propagated a message at time \(\beta_i^{r,s^*} = \alpha_i^{r,s^*} + t_{s^*}\), he has received all messages from \(HSV^{r,s^*-1}\), including at least \(t_H - |MSV^{r,s^*-1}|\) of them for 0 and v. If i has seen > 2/3 majority for 1, then he has seen more than \(2(t_H - |MSV^{r,s^*-1}|)\) valid (r, \(s^* - 1\))-messages for 1, with more than \(2t_H - 3|MSV^{r,s^*-1}|\) of them from honest (r, \(s^* - 1\))-verifiers. However, this implies \(|HSV^{r,s^*-1}| \geq t_H - |MSV^{r,s^*-1}| + 2t_H - 3|MSV^{r,s^*-1}| > 2n - 4|MSV^{r,s^*-1}|\), contradicting the fact that \(|HSV^{r,s^*-1}| + 4|MSV^{r,s^*-1}| < 2n\), which comes from the relationships for the parameters. Accordingly, i does not see > 2/3 majority for 1, and he sets \(b_i = 0\) because Step \(s^*\) is a Coin-Fixed-To-0 step. As we have seen, \(v_i = H(B_\ell^r)\). Thus i propagates \((\text{ESIG}_i(0), \text{ESIG}_i(H(B_\ell^r)), \sigma_i^{r,s^*})\) as we wanted to show. For Step \(s^* + 1\), since player \(i'\) has helped propagating the messages in his \(\text{CERT}^r\) on or before time \(\alpha_{i'}^{r,s^*} + t_{s^*}\), all honest verifiers in \(HSV^{r,s^*+1}\) have received at least \(t_H\) valid (r, \(s^* - 1\))-messages for bit 0 and value \(H(B_\ell^r)\) on or before they are done waiting. Furthermore, verifiers in \(HSV^{r,s^*+1}\) will not stop before receiving those (r, \(s^* - 1\))- messages, because there do not exist any other \(t_H\) valid \((r, s' - 1)\)-messages for bit 1 with \(s' - 2 \equiv 1 \mod 3\) and \(6 \leq s' \leq s^* + 1\), by the definition of Step \(s^*\). In particular, Step \(s^* + 1\) itself is a Coin-Fixed-To-1 step, but no honest verifier in \(HSV^{r,s^*}\) has propagated a message for 1, and \(|MSV^{r,s^*}| < t_H\). Thus all honest verifiers in \(HSV^{r,s^*+1}\) stop without propagating anything and set \(B_r = B_\ell^r\): as before, they have received \(m_\ell^{r,1}\) before they receive the desired (r, \(s^* - 1\))-messages.20 The same can be said for all honest verifiers in future steps and all honest users in general. In particular, they all know \(B_r = B_\ell^r\) within the time interval \(I_{r+1}\) and \(T^{r+1} \leq \alpha_{i'}^{r,s^*} + t_{s^*} \leq T^r + \lambda + t_{s^*}\). Case 2.1.b. Event E.b happens and there exists an honest verifier \(i' \in HSV^{r,s^*}\) who should also stop without propagating anything. In this case we have \(s^* - 2 \equiv 1 \mod 3\) and Step \(s^*\) is a Coin-Fixed-To-1 step. The analysis is similar to Case 2.1.a and many details have been omitted. 20If \(\ell\) is malicious, he might send out \(m_\ell^{r,1}\) late, hoping that some honest users/verifiers have not received \(m_\ell^{r,1}\) yet when they receive the desired certificate for it. However, since verifier \(\hat{i} \in HSV^{r,4}\) has set \(b_{\hat{i}} = 0\) and \(v_{\hat{i}} = H(B_\ell^r)\), as before we have that more than half of honest verifiers \(i \in HSV^{r,3}\) have set \(v_i = H(B_\ell^r)\). This further implies more than half of honest verifiers \(i \in HSV^{r,2}\) have set \(v_i = H(B_\ell^r)\), and those (r, 2)-verifiers have all received \(m_\ell^{r,1}\). As the Adversary cannot distinguish a verifier from a non-verifier, he cannot target the propagation of \(m_\ell^{r,1}\) to (r, 2)-verifiers without having the non-verifiers seeing it. In fact, with high probability, more than half (or a good constant fraction) of all honest users have seen \(m_\ell^{r,1}\) after waiting for \(t_2\) from the beginning of their own round r. From here on, the time \(\lambda'\) needed for \(m_\ell^{r,1}\) to reach the remaining honest users is much smaller than \(\Lambda\), and for simplicity we do not write it out in the analysis. If \(4\lambda \geq \lambda'\) then the analysis goes through without any change: by the end of Step 4, all honest users would have received \(m_\ell^{r,1}\). If the size of the block becomes enormous and \(4\lambda < \lambda'\), then in Steps 3 and 4, the protocol could ask each verifier to wait for \(\lambda'/2\) rather than \(2\lambda\), and the analysis continues to hold.

As before, player \(i'\) must have received at least \(t_H\) valid (r, \(s^* - 1\))-messages of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s^*-1})\). Again by the definition of \(s^*\), there does not exist a step \(5 \leq s' < s^*\) with \(s' - 2 \equiv 0 \mod 3\), where at least \(t_H\) \((r, s' - 1)\)-verifiers have signed 0 and the same v. Thus player \(i'\) stops without propagating anything; sets \(B_r = B_\epsilon^r\); and sets his own \(\text{CERT}^r\) to be the set of valid (r, \(s^* - 1\))-messages for bit 1 that he has received. Moreover, any other verifier \(i \in HSV^{r,s^*}\) has either stopped with \(B_r = B_\epsilon^r\) , or has set \(b_i = 1\) and propagated \((\text{ESIG}_i(1), \text{ESIG}_i(v_i), \sigma_i^{r,s^*})\). Since player \(i'\) has helped propagating the (r, \(s^* - 1\))-messages in his \(\text{CERT}^r\) by time \(\alpha_{i'}^{r,s^*} + t_{s^*}\), again all honest verifiers in \(HSV^{r,s^*+1}\) stop without propagating anything and set \(B_r = B_\epsilon^r\) . Similarly, all honest users know \(B_r = B_\epsilon^r\) within the time interval \(I_{r+1}\) and \(T^{r+1} \leq \alpha_{i'}^{r,s^*} + t_{s^*} \leq T^r + \lambda + t_{s^*}\). Case 2.2.a. Event E.a happens and there does not exist an honest verifier \(i' \in HSV^{r,s^*}\) who should also stop without propagating anything. In this case, note that player \(i^*\) could have a valid \(\text{CERT}_{i^*}^r\) consisting of the \(t_H\) desired (r, \(s^* - 1\))-messages the Adversary is able to collect or generate. However, the malicious verifiers may not help propagating those messages, so we cannot conclude that the honest users will receive them in time \(\lambda\). In fact, \(|MSV^{r,s^*-1}|\) of those messages may be from malicious (r, \(s^* - 1\))-verifiers, who did not propagate their messages at all and only send them to the malicious verifiers in step \(s^*\). Similar to Case 2.1.a, here we have \(s^* - 2 \equiv 0 \mod 3\), Step \(s^*\) is a Coin-Fixed-To-0 step, and the (r, \(s^* - 1\))-messages in \(\text{CERT}_{i^*}^r\) are for bit 0 and v = \(H(B_\ell^r)\). Indeed, all honest (r, \(s^* - 1\))-verifiers sign v, thus the Adversary cannot generate \(t_H\) valid (r, \(s^* - 1\))-messages for a different \(v'\). Moreover, all honest (r, \(s^*\))-verifiers have waited time \(t_{s^*}\) and do not see > 2/3 majority for bit 1, again because \(|HSV^{r,s^*-1}| + 4|MSV^{r,s^*-1}| < 2n\). Thus every honest verifier \(i \in HSV^{r,s^*}\) sets \(b_i = 0\), \(v_i = H(B_\ell^r)\) by the majority vote, and propagates \(m_i^{r,s^*} =\) \((\text{ESIG}_i(0), \text{ESIG}_i(H(B_\ell^r)), \sigma_i^{r,s^*})\) at time \(\alpha_i^{r,s^*} + t_{s^*}\). Now consider the honest verifiers in Step \(s^* + 1\) (which is a Coin-Fixed-To-1 step). If the Adversary actually sends the messages in \(\text{CERT}_{i^*}^r\) to some of them and causes them to stop, then similar to Case 2.1.a, all honest users know \(B_r = B_\ell^r\) within the time interval \(I_{r+1}\) and \(T^{r+1} \leq T^r + \lambda + t_{s^*+1}\). Otherwise, all honest verifiers in Step \(s^* + 1\) have received all the (r, \(s^*\))-messages for 0 and \(H(B_\ell^r)\) from \(HSV^{r,s^*}\) after waiting time \(t_{s^*+1}\), which leads to > 2/3 majority, because \(|HSV^{r,s^*}| > 2|MSV^{r,s^*}|\). Thus all the verifiers in \(HSV^{r,s^*+1}\) propagate their messages for 0 and \(H(B_\ell^r)\) accordingly. Note that the verifiers in \(HSV^{r,s^*+1}\) do not stop with \(B_r = B_\ell^r\), because Step \(s^* + 1\) is not a Coin-Fixed-To-0 step. Now consider the honest verifiers in Step \(s^* + 2\) (which is a Coin-Genuinely-Flipped step). If the Adversary sends the messages in \(\text{CERT}_{i^*}^r\) to some of them and causes them to stop, then again all honest users know \(B_r = B_\ell^r\) within the time interval \(I_{r+1}\) and \(T^{r+1} \leq T^r + \lambda + t_{s^*+2}\).

Otherwise, all honest verifiers in Step \(s^* + 2\) have received all the (r, \(s^* + 1\))-messages for 0 and \(H(B_\ell^r)\) from \(HSV^{r,s^*+1}\) after waiting time \(t_{s^*+2}\), which leads to > 2/3 majority. Thus all of them propagate their messages for 0 and \(H(B_\ell^r)\) accordingly: that is they do not “flip a coin” in this case. Again, note that they do not stop without propagating, because Step \(s^* + 2\) is not a Coin-Fixed-To-0 step. Finally, for the honest verifiers in Step \(s^* + 3\) (which is another Coin-Fixed-To-0 step), all of them would have received at least \(t_H\) valid messages for 0 and \(H(B_\ell^r)\) from \(HSV^{s^*+2}\), if they really wait time \(t_{s^*+3}\). Thus, whether or not the Adversary sends the messages in \(\text{CERT}_{i^*}^r\) to any of them, all verifiers in \(HSV^{r,s^*+3}\) stop with \(B_r = B_\ell^r\), without propagating anything. Depending on how the Adversary acts, some of them may have their own \(\text{CERT}^r\) consisting of those \((r, s^*-1)\)-messages in \(\text{CERT}_{i^*}^r\), and the others have their own \(\text{CERT}^r\) consisting of those (r, \(s^* + 2\))-messages. In any case, all honest users know \(B_r = B_\ell^r\) within the time interval \(I_{r+1}\) and \(T^{r+1} \leq T^r + \lambda + t_{s^*+3}\). Case 2.2.b. Event E.b happens and there does not exist an honest verifier \(i' \in HSV^{r,s^*}\) who should also stop without propagating anything. The analysis in this case is similar to those in Case 2.1.b and Case 2.2.a, thus many details have been omitted. In particular, \(\text{CERT}_{i^*}^r\) consists of the \(t_H\) desired \((r, s^*-1)\)-messages for bit 1 that the Adversary is able to collect or generate, \(s^* - 2 \equiv 1 \mod 3\), Step \(s^*\) is a Coin-Fixed-To-1 step, and no honest \((r, s^*)\)-verifier could have seen > 2/3 majority for 0. Thus, every verifier \(i \in HSV^{r,s^*}\) sets \(b_i = 1\) and propagates \(m_i^{r,s^*} = (\text{ESIG}_i(1), \text{ESIG}_i(v_i), \sigma_i^{r,s^*})\) at time \(\alpha_i^{r,s^*} + t_{s^*}\). Similar to Case 2.2.a, in at most 3 more steps (i.e., the protocol reaches Step \(s^* + 3\), which is another Coin-Fixed-To-1 step), all honest users know \(B_r = B_\epsilon^r\) within the time interval \(I_{r+1}\). Moreover, \(T^{r+1}\) may be \(\leq T^r + \lambda + t_{s^*+1}\), or \(\leq T^r + \lambda + t_{s^*+2}\), or \(\leq T^r + \lambda + t_{s^*+3}\), depending on when is the first time an honest verifier is able to stop without propagating. Combining the four sub-cases, we have that all honest users know \(B_r\) within the time interval \(I_{r+1}\), with \(T^{r+1} \leq T^r + \lambda + t_{s^*}\) in Cases 2.1.a and 2.1.b, and \(T^{r+1} \leq T^r + \lambda + t_{s^*+3}\) in Cases 2.2.a and 2.2.b. It remains to upper-bound \(s^*\) and thus \(T^{r+1}\) for Case 2, and we do so by considering how many times the Coin-Genuinely-Flipped steps are actually executed in the protocol: that is, some honest verifiers actually have flipped a coin. In particular, arbitrarily fix a Coin-Genuinely-Flipped step \(s'\) (i.e., \(7 \leq s' \leq m + 2\) and \(s' - 2 \equiv 2 \mod 3\)), and let \(\ell' \triangleq \arg \min_{j \in SV^{r,s'-1}} H(\sigma_j^{r,s'-1})\). For now let us assume \(s' < s^*\), because otherwise no honest verifier actually flips a coin in Step \(s'\), according to previous discussions. By the definition of \(SV^{r,s'-1}\), the hash value of the credential of \(\ell'\) is also the smallest among all users in \(PK^{r-k}\). Since the hash function is a random oracle, ideally player \(\ell'\) is honest with probability at least h. As we will show later, even if the Adversary tries his best to predict the output of the random oracle and tilt the probability, player \(\ell'\) is still honest with probability

at least \(p_h = h^2(1 + h - h^2)\). Below we consider the case when that indeed happens: that is, \(\ell' \in HSV^{r,s'-1}\). Note that every honest verifier \(i \in HSV^{r,s'}\) has received all messages from \(HSV^{r,s'-1}\) by time \(\alpha_i^{r,s'} + t_{s'}\). If player i needs to flip a coin (i.e., he has not seen > 2/3 majority for the same bit \(b \in \{0, 1\}\)), then he sets \(b_i = \text{lsb}(H(\sigma_{\ell'}^{r,s'-1}))\). If there exists another honest verifier \(i' \in HSV^{r,s'}\) who has seen > 2/3 majority for a bit \(b \in \{0, 1\}\), then by Property (d) of Lemma 5.5, no honest verifier in \(HSV^{r,s'}\) would have seen > 2/3 majority for a bit \(b' \neq b\). Since \(\text{lsb}(H(\sigma_{\ell'}^{r,s'-1})) = b\) with probability \(1/2\), all honest verifiers in \(HSV^{r,s'}\) reach an agreement on b with probability \(1/2\). Of course, if such a verifier \(i'\) does not exist, then all honest verifiers in \(HSV^{r,s'}\) agree on the bit \(\text{lsb}(H(\sigma_{\ell'}^{r,s'-1}))\) with probability \(1\). Combining the probability for \(\ell' \in HSV^{r,s'-1}\), we have that the honest verifiers in \(HSV^{r,s'}\) reach an agreement on a bit \(b \in \{0, 1\}\) with probability at least \(\frac{p_h}{2} = \frac{h^2(1+h-h^2)}{2}\). Moreover, by induction on the majority vote as before, all honest verifiers in \(HSV^{r,s'}\) have their \(v_i\)'s set to be \(H(B_\ell^r)\). Thus, once an agreement on b is reached in Step \(s'\), \(T^{r+1}\) is either \(\leq T^r + \lambda + t_{s'+1}\) or \(\leq T^r + \lambda + t_{s'+2}\), depending on whether \(b = 0\) or \(b = 1\), following the analysis of Cases 2.1.a and 2.1.b. In particular, no further Coin-Genuinely-Flipped step will be executed: that is, the verifiers in such steps still check that they are the verifiers and thus wait, but they will all stop without propagating anything. Accordingly, before Step \(s^*\), the number of times the Coin-GenuinelyFlipped steps are executed is distributed according to the random variable \(L_r\). Letting Step \(s'\) be the last Coin-Genuinely-Flipped step according to \(L_r\), by the construction of the protocol we have \(s' = 4 + 3L_r\). When should the Adversary make Step \(s^*\) happen if he wants to delay \(T^{r+1}\) as much as possible? We can even assume that the Adversary knows the realization of \(L_r\) in advance. If \(s^*\) > \(s'\) then it is useless, because the honest verifiers have already reached an agreement in Step \(s'\). To be sure, in this case \(s^*\) would be \(s' + 1\) or \(s' + 2\), again depending on whether \(b = 0\) or \(b = 1\). However, this is actually Cases 2.1.a and 2.1.b, and the resulting \(T^{r+1}\) is exactly the same as in that case. More precisely, \(T^{r+1} \leq T^r + \lambda + t_{s^*} \leq T^r + \lambda + t_{s'+2}\). If \(s^*\) < \(s' - 3\) —that is, \(s^*\) is before the second-last Coin-Genuinely-Flipped step— then by the analysis of Cases 2.2.a and 2.2.b, \(T^{r+1} \leq T^r + \lambda + t_{s^*+3} < T^r + \lambda + t_{s'}\). That is, the Adversary is actually making the agreement on \(B_r\) happen faster. If \(s^* = s' - 2\) or \(s' - 1\) —that is, the Coin-Fixed-To-0 step or the Coin-Fixed-To-1 step immediately before Step \(s'\)— then by the analysis of the four sub-cases, the honest verifiers in Step \(s'\) do not get to flip coins anymore, because they have either stopped without propagating, or have seen > 2/3 majority for the same bit \(b\). Therefore we have \(T^{r+1} \leq T^r + \lambda + t_{s^*+3} \leq T^r + \lambda + t_{s'+2}\).

In sum, no matter what \(s^*\) is, we have \(T^{r+1} \leq T^r + \lambda + t_{s'+2} = T^r + \lambda + t_{3L_r+6}\) \(= T^r + \lambda + (2(3L_r + 6) - 3)\lambda + \Lambda\) \(= T^r + (6L_r + 10)\lambda + \Lambda\), as we wanted to show. The worst case is when \(s^* = s' - 1\) and Case 2.2.b happens. Combining Cases 1 and 2 of the binary BA protocol, Lemma 5.3 holds. ■ 5.9 Security of the Seed \(Q_r\) and Probability of An Honest Leader It remains to prove Lemma 5.4. Recall that the verifiers in round \(r\) are taken from \(PK^{r-k}\) and are chosen according to the quantity \(Q_{r-1}\). The reason for introducing the look-back parameter \(k\) is to make sure that, back at round \(r - k\), when the Adversary is able to add new malicious users to \(PK^{r-k}\), he cannot predict the quantity \(Q_{r-1}\) except with negligible probability. Note that the hash function is a random oracle and \(Q_{r-1}\) is one of its inputs when selecting verifiers for round \(r\). Thus, no matter how malicious users are added to \(PK^{r-k}\), from the Adversary's point of view each one of them is still selected to be a verifier in a step of round \(r\) with the required probability \(p\) (or \(p_1\) for Step 1). More precisely, we have the following lemma. Lemma 5.6. With \(k = O(\log_{1/2} F)\), for each round \(r\), with overwhelming probability the Adversary did not query \(Q_{r-1}\) to the random oracle back at round \(r - k\). Proof. We proceed by induction. Assume that for each round \(\gamma < r\), the Adversary did not query \(Q_{\gamma-1}\) to the random oracle back at round \(\gamma - k\).21 Consider the following mental game played by the Adversary at round \(r - k\), trying to predict \(Q_{r-1}\). In Step 1 of each round \(\gamma = r - k, \ldots, r - 1\), given a specific \(Q_{\gamma-1}\) not queried to the random oracle, by ordering the players \(i \in PK^{\gamma-k}\) according to the hash values \(H(\text{SIG}_i(\gamma, 1, Q_{\gamma-1}))\) increasingly, we obtain a random permutation over \(PK^{\gamma-k}\). By definition, the leader \(\ell_\gamma\) is the first user in the permutation and is honest with probability \(h\). Moreover, when \(PK^{\gamma-k}\) is large enough, for any integer \(x \geq 1\), the probability that the first \(x\) users in the permutation are all malicious but the \((x + 1)\)st is honest is \((1 - h)^x h\). If \(\ell_\gamma\) is honest, then \(Q_\gamma = H(\text{SIG}_{\ell_\gamma}(Q_{\gamma-1}), \gamma)\). As the Adversary cannot forge the signature of \(\ell_\gamma\), \(Q_\gamma\) is distributed uniformly at random from the Adversary's point of view and, except with exponentially small probability,22 was not queried to \(H\) at round \(r - k\). Since each \(Q_{\gamma+1}, Q_{\gamma+2}, \ldots, Q_{r-1}\) respectively is the output of \(H\) with \(Q_\gamma, Q_{\gamma+1}, \ldots, Q_{r-2}\) as one of the inputs, they all look random to the Adversary and the Adversary could not have queried \(Q_{r-1}\) to \(H\) at round \(r - k\). Accordingly, the only case where the Adversary can predict \(Q_{r-1}\) with good probability at round \(r - k\) is when all the leaders \(\ell_{r-k}, \ldots, \ell_{r-1}\) are malicious. Again consider a round \(\gamma \in \{r - k \ldots, r - 1\}\) and the random permutation over \(PK^{\gamma-k}\) induced by the corresponding hash values. If for some \(x \geq 2\), the first \(x - 1\) users in the permutation are all malicious and the \(x\)-th is honest, then the Adversary has \(x\) possible choices for \(Q_\gamma\): either of the form \(H(\text{SIG}_i(Q_{\gamma-1}, \gamma))\), where \(i\) is one of 21As \(k\) is a small integer, without loss of generality one can assume that the first \(k\) rounds of the protocol are run under a safe environment and the inductive hypothesis holds for those rounds. 22That is, exponential in the length of the output of \(H\). Note that this probability is way smaller than \(F\).

the first \(x - 1\) malicious users, by making player \(i\) the actually leader of round \(\gamma\); or \(H(Q_{\gamma-1}, \gamma)\), by forcing \(B_\gamma = B_\gamma^\epsilon\). Otherwise, the leader of round \(\gamma\) will be the first honest user in the permutation and \(Q_{r-1}\) becomes unpredictable to the Adversary. Which of the above \(x\) options of \(Q_\gamma\) should the Adversary pursue? To help the Adversary answer this question, in the mental game we actually make him more powerful than he actually is, as follows. First of all, in reality, the Adversary cannot compute the hash of a honest user's signature, thus cannot decide, for each \(Q_\gamma\), the number \(x(Q_\gamma)\) of malicious users at the beginning of the random permutation in round \(\gamma + 1\) induced by \(Q_\gamma\). In the mental game, we give him the numbers \(x(Q_\gamma)\) for free. Second of all, in reality, having the first \(x\) users in the permutation all being malicious does not necessarily mean they can all be made into the leader, because the hash values of their signatures must also be less than \(p_1\). We have ignored this constraint in the mental game, giving the Adversary even more advantages. It is easy to see that in the mental game, the optimal option for the Adversary, denoted by \(\hat{Q}_\gamma\), is the one that produces the longest sequence of malicious users at the beginning of the random permutation in round \(\gamma + 1\). Indeed, given a specific \(Q_\gamma\), the protocol does not depend on \(Q_{\gamma-1}\) anymore and the Adversary can solely focus on the new permutation in round \(\gamma + 1\), which has the same distribution for the number of malicious users at the beginning. Accordingly, in each round \(\gamma\), the above mentioned \(\hat{Q}_\gamma\) gives him the largest number of options for \(Q_{\gamma+1}\) and thus maximizes the probability that the consecutive leaders are all malicious. Therefore, in the mental game the Adversary is following a Markov Chain from round \(r - k\) to round \(r - 1\), with the state space being \(\{0\} \cup \{x : x \geq 2\}\). State 0 represents the fact that the first user in the random permutation in the current round \(\gamma\) is honest, thus the Adversary fails the game for predicting \(Q_{r-1}\); and each state \(x \geq 2\) represents the fact that the first \(x - 1\) users in the permutation are malicious and the \(x\)-th is honest, thus the Adversary has \(x\) options for \(Q_\gamma\). The transition probabilities \(P(x, y)\) are as follows. • \(P(0, 0) = 1\) and \(P(0, y) = 0\) for any \(y \geq 2\). That is, the Adversary fails the game once the first user in the permutation becomes honest. • \(P(x, 0) = h^x\) for any \(x \geq 2\). That is, with probability \(h^x\), all the \(x\) random permutations have their first users being honest, thus the Adversary fails the game in the next round. • For any \(x \geq 2\) and \(y \geq 2\), \(P(x, y)\) is the probability that, among the \(x\) random permutations induced by the \(x\) options of \(Q_\gamma\), the longest sequence of malicious users at the beginning of some of them is \(y - 1\), thus the Adversary has \(y\) options for \(Q_{\gamma+1}\) in the next round. That is, \(P(x, y) = \left(\sum_{i=0}^{y-1} (1 - h)^i h\right)^x - \left(\sum_{i=0}^{y-2} (1 - h)^i h\right)^x = (1 - (1 - h)^y)^x - (1 - (1 - h)^{y-1})^x\). Note that state 0 is the unique absorbing state in the transition matrix \(P\), and every other state \(x\) has a positive probability of going to 0. We are interested in upper-bounding the number \(k\) of rounds needed for the Markov Chain to converge to 0 with overwhelming probability: that is, no matter which state the chain starts at, with overwhelming probability the Adversary loses the game and fails to predict \(Q_{r-1}\) at round \(r - k\). Consider the transition matrix \(P^{(2)} \triangleq P \cdot P\) after two rounds. It is easy to see that \(P^{(2)}(0, 0) = 1\) and \(P^{(2)}(0, x) = 0\) for any \(x \geq 2\). For any \(x \geq 2\) and \(y \geq 2\), as \(P(0, y) = 0\), we have \(P^{(2)}(x, y) = P(x, 0)P(0, y) + \sum_{z \geq 2} P(x, z)P(z, y) = \sum_{z \geq 2} P(x, z)P(z, y)\).

Letting \(\bar{h} \triangleq 1 - h\), we have \(P(x, y) = (1 - \bar{h}^y)^x - (1 - \bar{h}^{y-1})^x\) and \(P^{(2)}(x, y) = \sum_{z \geq 2} [(1 - \bar{h}^z)^x - (1 - \bar{h}^{z-1})^x][(1 - \bar{h}^y)^z - (1 - \bar{h}^{y-1})^z]\). Below we compute the limit of \(\frac{P^{(2)}(x,y)}{P(x,y)}\) as \(h\) goes to 1 —that is, \(\bar{h}\) goes to 0. Note that the highest order of \(\bar{h}\) in \(P(x, y)\) is \(\bar{h}^{y-1}\), with coefficient \(x\). Accordingly, \(\lim_{h \to 1} \frac{P^{(2)}(x, y)}{P(x, y)} = \lim_{\bar{h} \to 0} \frac{P^{(2)}(x, y)}{P(x, y)} = \lim_{\bar{h} \to 0} \frac{P^{(2)}(x, y)}{x\bar{h}^{y-1} + O(\bar{h}^y)}\) \(= \lim_{\bar{h} \to 0} \frac{\sum_{z \geq 2} [x\bar{h}^{z-1} + O(\bar{h}^z)][z\bar{h}^{y-1} + O(\bar{h}^y)]}{x\bar{h}^{y-1} + O(\bar{h}^y)} = \lim_{\bar{h} \to 0} \frac{2x\bar{h}^y + O(\bar{h}^{y+1})}{x\bar{h}^{y-1} + O(\bar{h}^y)}\) \(= \lim_{\bar{h} \to 0} \frac{2x\bar{h}^y}{x\bar{h}^{y-1}} = \lim_{\bar{h} \to 0} 2\bar{h} = 0\). When \(h\) is sufficiently close to 1,23 we have \(\frac{P^{(2)}(x, y)}{P(x, y)} \leq \frac{1}{2}\) for any \(x \geq 2\) and \(y \geq 2\). By induction, for any \(k > 2\), \(P^{(k)} \triangleq P^k\) is such that • \(P^{(k)}(0, 0) = 1\), \(P^{(k)}(0, x) = 0\) for any \(x \geq 2\), and • for any \(x \geq 2\) and \(y \geq 2\), \(P^{(k)}(x, y) = P^{(k-1)}(x, 0)P(0, y) + \sum_{z \geq 2} P^{(k-1)}(x, z)P(z, y) = \sum_{z \geq 2} P^{(k-1)}(x, z)P(z, y)\) \(\leq \sum_{z \geq 2} \frac{P(x, z)}{2^{k-2}} \cdot P(z, y) = \frac{P^{(2)}(x, y)}{2^{k-2}} \leq \frac{P(x, y)}{2^{k-1}}\). As \(P(x, y) \leq 1\), after \(1 - \log_2 F\) rounds, the transition probability into any state \(y \geq 2\) is negligible, starting with any state \(x \geq 2\). Although there are many such states \(y\), it is easy to see that \(\lim_{y \to +\infty} \frac{P(x, y)}{P(x, y + 1)} = \lim_{y \to +\infty} \frac{(1 - \bar{h}^y)^x - (1 - \bar{h}^{y-1})^x}{(1 - \bar{h}^{y+1})^x - (1 - \bar{h}^y)^x} = \lim_{y \to +\infty} \frac{\bar{h}^{y-1} - \bar{h}^y}{\bar{h}^y - \bar{h}^{y+1}} = \frac{1}{\bar{h}} = \frac{1}{1 - h}\). Therefore each row \(x\) of the transition matrix \(P\) decreases as a geometric sequence with rate \(\frac{1}{1-h} > 2\) when \(y\) is large enough, and the same holds for \(P^{(k)}\). Accordingly, when \(k\) is large enough but still on the order of \(\log_{1/2} F\), \(\sum_{y \geq 2} P^{(k)}(x, y) < F\) for any \(x \geq 2\). That is, with overwhelming probability the Adversary loses the game and fails to predict \(Q_{r-1}\) at round \(r - k\). For \(h \in (2/3, 1]\), a more complex analysis shows that there exists a constant \(C\) slightly larger than 1/2, such that it suffices to take \(k = O(\log_C F)\). Thus Lemma 5.6 holds. ■ Lemma 5.4. (restated) Given Properties 1–3 for each round before \(r\), \(p_h = h^2(1 + h - h^2)\) for \(L_r\), and the leader \(\ell_r\) is honest with probability at least \(p_h\). 23For example, \(h = 80\%\) as suggested by the specific choices of parameters.

Proof. Following Lemma 5.6, the Adversary cannot predict \(Q_{r-1}\) back at round \(r - k\) except with negligible probability. Note that this does not mean the probability of an honest leader is \(h\) for each round. Indeed, given \(Q_{r-1}\), depending on how many malicious users are at the beginning of the random permutation of \(PK^{r-k}\), the Adversary may have more than one options for \(Q_r\) and thus can increase the probability of a malicious leader in round \(r + 1\) —again we are giving him some unrealistic advantages as in Lemma 5.6, so as to simplify the analysis. However, for each \(Q_{r-1}\) that was not queried to \(H\) by the Adversary back at round \(r - k\), for any \(x \geq 1\), with probability \((1 - h)^{x-1} h\) the first honest user occurs at position \(x\) in the resulting random permutation of \(PK^{r-k}\). When \(x = 1\), the probability of an honest leader in round \(r + 1\) is indeed \(h\); while when \(x = 2\), the Adversary has two options for \(Q_r\) and the resulting probability is \(h^2\). Only by considering these two cases, we have that the probability of an honest leader in round \(r + 1\) is at least \(h \cdot h + (1 - h)h \cdot h^2 = h^2(1 + h - h^2)\) as desired. Note that the above probability only considers the randomness in the protocol from round \(r - k\) to round \(r\). When all the randomness from round 0 to round \(r\) is taken into consideration, \(Q_{r-1}\) is even less predictable to the Adversary and the probability of an honest leader in round \(r + 1\) is at least \(h^2(1 + h - h^2)\). Replacing \(r + 1\) with \(r\) and shifts everything back by one round, the leader \(\ell_r\) is honest with probability at least \(h^2(1 + h - h^2)\), as desired. Similarly, in each Coin-Genuinely-Flipped step \(s\), the "leader" of that step —that is the verifier in \(SV^{r,s}\) whose credential has the smallest hash value, is honest with probability at least $h^2(1 + h - h^2)\(. Thus \)p_h = h^2(1 + h - h^2)\( for \)L_r$ and Lemma 5.4 holds. ■

Algorand ′

1 Nesta seção, construímos uma versão de Algorand ′ trabalhando sob a seguinte suposição. Suposição da maioria honesta dos usuários: Mais de 2/3 dos usuários em cada PKr são honestos. Na Seção 8, mostramos como substituir a suposição acima pela desejada Maioria Honesta de Suposição de dinheiro. 5.1 Notações e parâmetros adicionais Notações • m \(\in\)Z+: número máximo de passos no protocolo BA binário, múltiplo de 3. • Lr \(\leq\)m/3: uma variável aleatória que representa o número de tentativas de Bernoulli necessárias para ver um 1, quando cada tentativa é 1 com probabilidade ph 2 e há no máximo m/3 tentativas. Se todas as tentativas falharem então Lr\(\triangleq\)m/3. Lr será usado para limitar o tempo necessário para gerar o bloco Br. • tH = 2n 3 + 1: o número de assinaturas necessárias nas condições finais do protocolo. • CERT r: o certificado para Br. É um conjunto de assinaturas tH de H(Br) de verificadores apropriados em rodada R. Parâmetros • Relações entre vários parâmetros. — Para cada passo s > 1 da rodada r, n é escolhido de modo que, com probabilidade esmagadora, |HSV r,s| > 2|MSV r,s| e |HSV r,s| + 4|MSV r,s| <2n. Quanto mais próximo de 1 for o valor de h, menor será n. Em particular, usamos (variantes de) Chernoffbounds para garantir que as condições desejadas se mantenham com uma probabilidade esmagadora. — m é escolhido de modo que Lr < m/3 com probabilidade esmagadora. • Exemplos de escolhas de parâmetros importantes. — F = 10−12. — n \(\approx\)1500, k = 40 e m = 180.5.2 Implementando chaves efêmeras em Algorand ′ 1 Como já mencionado, desejamos que um verificador i \(\in\)SV r,s assine digitalmente sua mensagem mr,s eu de passo s na rodada r, relativo a uma chave pública efêmera pkr,s i , usando uma chave secreta efêmera skr,s eu isso ele destrói prontamente após o uso. Portanto, precisamos de um método eficiente para garantir que cada usuário possa verifique se pkr,s eu é de fato a chave a ser usada para verificar a assinatura do senhor,s eu. Fazemo-lo através de um (da melhor forma do nosso conhecimento) novo uso de esquemas de assinatura baseados em identidade. Em um nível elevado, em tal esquema, uma autoridade central A gera uma chave mestra pública, PMK, e uma chave mestra secreta correspondente, SMK. Dada a identidade, U, de um jogador U, A calcula, via SMK, um skU de chave de assinatura secreta relativo à chave pública U, e fornece skU de forma privada para U. (Na verdade, em um esquema de assinatura digital baseado em identidade, a chave pública de um usuário U é o próprio U!) Desta forma, se A destruir o SMK após calcular as chaves secretas dos usuários que ele deseja habilitar para produz assinaturas digitais e não mantém nenhuma chave secreta computada, então U é o único que pode assinar digitalmente mensagens relativas à chave pública U. Assim, qualquer pessoa que saiba o “nome de U”, conhece automaticamente a chave pública de U e, portanto, pode verificar as assinaturas de U (possivelmente usando também o chave mestra pública PMK). Em nossa aplicação, a autoridade A é o usuário i, e o conjunto de todos os usuários possíveis U coincide com o par de passos redondos (r, s) em —digamos— S = {i}\(\times\){r′, . . . , r′ +106}\(\times\){1, . . . , m+3}, onde r′ é um dado rodada e m + 3 o limite superior para o número de etapas que podem ocorrer dentro de uma rodada. Isto caminho, pkr,s eu \(\triangleq\)(i, r, s), para que todos vejam a assinatura de i SIGr,s pkr,s eu (sr.,s i) pode, com esmagadora probabilidade, verifique-a imediatamente para o primeiro milhão de rodadas r após r′. Em outras palavras, primeiro gero PMK e SMK. Em seguida, ele divulga que PMK é o mestre do i chave pública para qualquer rodada r \(\in\)[r′, r′ + 106], e usa SMK para produzir e armazenar o segredo de forma privada chave skr,s eu para cada triplo (i, r, s) \(\in\)S. Feito isso, ele destrói SMK. Se ele determinar que não está parte de SV r,s, então posso deixar skr,s eu sozinho (já que o protocolo não exige que ele autentique qualquer mensagem na Etapa s da rodada r). Caso contrário, primeiro uso skr,s eu para assinar digitalmente sua mensagem, Sr. eu, e então destrói skr,s eu. Observe que posso divulgar sua primeira chave mestra pública quando ele entrar no sistema pela primeira vez. Isto é, o mesmo pagamento \(\wp\)que traz i para o sistema (em uma rodada r′ ou em uma rodada próxima de r′), também pode especifique, a pedido de i, que a chave mestra pública de i para qualquer rodada r \(\in\)[r′, r′ + 106] é PMK - por exemplo, por incluindo um par da forma (PMK, [r′, r′ + 106]). Observe também que, como m + 3 é o número máximo de passos em uma rodada, assumindo que uma rodada leva um minuto, o estoque de chaves efêmeras assim produzido durará quase dois anos. Ao mesmo tempo, essas chaves secretas efêmeras não levarão muito tempo para serem produzidas. Usando uma curva elíptica baseada sistema com chaves de 32B, cada chave secreta é computada em alguns microssegundos. Assim, se m + 3 = 180, então, todas as 180 milhões de chaves secretas podem ser computadas em menos de uma hora. Quando a rodada atual estiver se aproximando de r′ + 106, para lidar com o próximo milhão de rodadas, i gera um novo par (PMK′, SMK′) e informa qual é seu próximo estoque de chaves efêmeras —por exemplo— fazer com que SIGi(PMK′, [r′ + 106 + 1, r′ + 2 \(\cdot\) 106 + 1]) insira um novo bloco, seja como um “transação” separada ou como alguma informação adicional que faz parte de um pagamento. Ao fazer isso, i informa a todos que devem usar PMK′ para verificar as assinaturas efêmeras de i no próximo milhões de rodadas. E assim por diante. (Observe que, seguindo esta abordagem básica, outras formas de implementar chaves efêmeras sem o uso de assinaturas baseadas em identidade é certamente possível. Por exemplo, via Merkle trees.16) 16Neste método, i gera um par de chaves públicas-secretas (pkr,s eu, skr,s eu ) para cada par de etapas redondas (r, s) em —digamos—Outras maneiras de implementar chaves efêmeras são certamente possíveis — por exemplo, via Merkle trees. 5.3 Correspondendo às etapas de Algorand ′ 1 com os de BA⋆ Como dissemos, uma rodada em Algorand ′ 1 tem no máximo m + 3 passos. Passo 1. Nesta etapa, cada líder potencial i calcula e propaga seu bloco candidato Br eu, juntamente com sua própria credencial, \(\sigma\)r,1 eu. Lembre-se de que esta credencial identifica explicitamente i. Isto é assim porque \(\sigma\)r,1 eu \(\triangleq\)SIGi(r, 1, Qr−1). O verificador potencial i também propaga, como parte de sua mensagem, sua assinatura digital própria de H(Br eu). Não se tratando de um pagamento ou de uma credencial, esta assinatura de i é relativa ao seu efêmero público chave pkr,1 i: isto é, ele propaga sigpkr,1 eu (H(Br eu)). Dadas as nossas convenções, em vez de propagar o Br eu e sigpkr,1 eu (H(Br i)), ele poderia ter SIGpkr propagado,1 eu (H(Br eu)). No entanto, na nossa análise, precisamos de ter acesso explícito a sigpkr,1 eu (H(Br eu)). Etapa 2. Nesta etapa, cada verificador i define \(\ell\)r eu serei o líder em potencial cuja credencial hashed é o menor e Br i será o bloco proposto por \(\ell\)r eu. Como, por uma questão de eficiência, desejar concordar com H(Br), em vez de diretamente com Br, i propaga a mensagem que ele teria propagado na primeira etapa de BA⋆com valor inicial v′ eu = H(Br eu). Ou seja, ele propaga v′ eu, depois de assiná-lo efêmeramente, é claro. (Nomeadamente, depois de assiná-lo relativamente ao direito efémero chave pública, que neste caso é pkr,2 i.) Claro, também transmito sua própria credencial. Como a primeira etapa de BA⋆consiste na primeira etapa do protocolo de consenso graduado GC, Etapa 2 de Algorand ′ corresponde ao primeiro passo do GC. Passo 3. Neste passo, cada verificador i \(\in\)SV r,2 executa o segundo passo de BA⋆. Ou seja, ele envia o mesma mensagem que ele teria enviado na segunda etapa do GC. Novamente, a mensagem de i é efêmera assinado e acompanhado da credencial do i. (De agora em diante, deixaremos de dizer que um verificador assina efêmeramente sua mensagem e também propaga sua credencial.) Etapa 4. Nesta etapa, cada verificador i \(\in\)SV r,4 calcula a saída de GC, (vi, gi), e efêmeramente assina e envia a mesma mensagem que teria enviado na terceira etapa do BA⋆, ou seja, no primeiro passo do BBA⋆, com bit inicial 0 se gi = 2, e 1 caso contrário. Etapa s = 5, . . . , m + 2. Tal passo, se alguma vez alcançado, corresponde ao passo s −1 de BA⋆ e, portanto, a etapa s −3 do BBA⋆. Como nosso modelo de propagação é suficientemente assíncrono, devemos levar em conta a possibilidade que, no meio de tal passo s, um verificador i \(\in\)SV r,s é alcançado por informações que o comprovam aquele bloco Br já foi escolhido. Neste caso, i interrompe sua própria execução da rodada r de Algorand ′ e começa a executar suas instruções round-(r + 1). {r', . . . , r′ + 106} \(\times\) {1, . . . , m + 3}. Então ele ordena essas chaves públicas de forma canônica, armazena a j-ésima chave pública digita a j-ésima folha de um Merkle tree e calcula o valor da raiz Ri, que ele divulga. Quando ele quer assinar uma mensagem relativa à chave pkr,s eu , não apenas forneço a assinatura real, mas também o caminho de autenticação para pkr,s eu em relação a Ri. Observe que este caminho de autenticação também prova que pkr,s eu é armazenado na j-ésima folha. O resto do detalhes podem ser facilmente preenchidos.Assim, as instruções de um verificador i \(\in\)SV r,s, além das instruções correspondentes para a Etapa s −3 do BBA⋆, inclui a verificação se a execução do BBA⋆ foi interrompida em um momento anterior Passo s′. Como o BBA⋆ só pode parar em uma etapa fixada em moeda em 0 ou em uma etapa fixada em moeda em 1, o instruções distinguem se A (Condição Final 0): s′ −2 ≡0 mod 3, ou B (Condição Final 1): s′ −2 ≡1 mod 3. Na verdade, no caso A, o bloco Br não está vazio e, portanto, são necessárias instruções adicionais para garantir que i reconstrói Br adequadamente, juntamente com seu certificado adequado CERT r. No caso B, o bloco Br está vazio e, portanto, i é instruído a definir Br = Br \(\varepsilon\) = (r, \(\emptyset\), H(Qr−1, r), H(Br−1)), e para calcular CERT r. Se, durante a execução do passo s, i não vir nenhuma evidência de que o bloco Br já tenha foi gerado, então ele envia a mesma mensagem que teria enviado na etapa s −3 do BBA⋆. Passo m + 3. Se, durante o passo m + 3, i \(\in\)SV r,m+3 vê que o bloco Br já foi gerado em uma etapa anterior s′, então ele prossegue conforme explicado acima. Caso contrário, em vez de enviar a mesma mensagem que ele teria enviado na etapa m do BBA⋆, i é instruído, com base nas informações em sua posse, a calcular Br e seu correspondente certificado CERT r. Lembre-se, de fato, que limitamos em m + 3 o número total de etapas de uma rodada. 5.4 O protocolo real Lembre-se que, em cada passo s de uma rodada r, um verificador i \(\in\)SV r,s usa seu par de chaves secretas públicas de longo prazo para produzir sua credencial, \(\sigma\)r,s eu \(\triangleq\)SIGi(r, s, Qr−1), bem como SIGi Qr-1 no caso s = 1. Verificador i usa sua chave secreta efêmera skr,s eu para assinar sua mensagem (r, s) mr,s eu. Por simplicidade, quando r e s são claro, escrevemos esigi(x) em vez de sigpkr,s i (x) para denotar a assinatura efêmera adequada de um valor de i x na etapa s da rodada r e escreva ESIGi(x) em vez de SIGpkr,s i (x) para denotar (i, x, esigi (x)). Etapa 1: bloquear proposta Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 1 da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,1 ou não. • Se i /\(\in\)SV r,1, então i interrompe imediatamente a sua própria execução do Passo 1. • Se i \(\in\)SV r,1, ou seja, se i for um líder em potencial, então ele recebe os pagamentos da rodada r que foram foi propagado para ele até agora e calcula um conjunto de pagamento máximo PAY r eu deles. A seguir, ele calcula seu “bloco de candidatos” Br eu = (r, PAGAR r eu, SIGi(Qr−1), H(Br−1)). Finalmente, ele calcula a mensagem senhor,1 eu = (Br eu , esigi(H(Br eu )), \(\sigma\)r,1 i ), destrói sua chave secreta efêmera skr,1 eu, e então propaga senhor,1 eu.Observação. Na prática, para encurtar a execução global do Passo 1, é importante que o (r, 1)- as mensagens são propagadas seletivamente. Ou seja, para cada usuário i no sistema, para o primeiro (r, 1)- mensagem que ele recebe e verifica com sucesso,17 o jogador i a propaga normalmente. Para todos os outras mensagens (r, 1) que o jogador i recebe e verifica com sucesso, ele as propaga apenas se o hash o valor da credencial que contém é o menor entre os valores hash das credenciais contidas em todas as mensagens (r, 1) que ele recebeu e verificou com sucesso até agora. Além disso, como sugerido por Georgios Vlachos, é útil que cada líder potencial i também propague sua credencial \(\sigma\)r,1 eu separadamente: essas pequenas mensagens viajam mais rápido que os blocos, garantem a propagação oportuna do mr,1 j's onde as credenciais contidas têm valores hash pequenos, enquanto fazem aquelas com valores hash grandes desaparecer rapidamente. Etapa 2: A primeira etapa do GC do protocolo de consenso graduado Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 2 da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,2 ou não. • Se i /\(\in\)SV r,2 então i interrompe imediatamente a sua própria execução do Passo 2. • Se i \(\in\)SV r,2, então depois de esperar um período de tempo t2 \(\triangleq\) \(\lambda\) + Λ, i age da seguinte forma. 1. Ele encontra o usuário \(\ell\) tal que H(\(\sigma\)r,1 \(\ell\)) \(\leq\)H(\(\sigma\)r,1 j ) para todas as credenciais \(\sigma\)r,1 j que fazem parte as mensagens (r, 1) verificadas com sucesso que ele recebeu até agora.a 2. Se ele recebeu de \(\ell\) uma mensagem válida mr,1 \(\ell\) = (Br \(\ell\), esig\(\ell\)(H(Br \(\ell\))), \(\sigma\)r,1 \(\ell\)),b então eu defino v' eu \(\triangleq\)H(Br \(\ell\)); caso contrário, eu defino v′ eu \(\triangleq\) \(\bot\). 3. eu calculo a mensagem senhor,2 eu \(\triangleq\)(ESIGi(v′ eu), \(\sigma\)r,2 i ),c destrói sua chave secreta efêmera skr,2 i , e então propaga mr,2 eu. aEssencialmente, o usuário i decide em particular que o líder da rodada r é o usuário \(\ell\). bNovamente, as assinaturas do jogador \(\ell\) e os hashes foram todos verificados com sucesso e PAGUE r \(\ell\)no Brasil \(\ell\)é um conjunto de pagamento válido para rodada r - embora eu não verifique se PAY r \(\ell\)é máximo para \(\ell\)ou não. cA mensagem senhor,2 eu sinaliza que o jogador i considera v′ i é o hash do próximo bloco, ou considera o próximo bloco fique vazio. 17Ou seja, todas as assinaturas estão corretas e tanto o bloco quanto seu hash são válidos —embora eu não verifique se o conjunto de pagamentos incluído é máximo para o seu proponente ou não.

Etapa 3: A segunda etapa do GC Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 3 da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,3 ou não. • Se i /\(\in\)SV r,3, então i interrompe imediatamente a sua própria execução do Passo 3. • Se i \(\in\)SV r,3, então depois de esperar um período de tempo t3 \(\triangleq\)t2 + 2\(\lambda\) = 3\(\lambda\) + Λ, i age da seguinte forma. 1. Se existe um valor v′ ̸= \(\bot\)tal que, entre todas as mensagens válidas mr,2 j ele recebeu, mais de 2/3 deles são da forma (ESIGj(v′), \(\sigma\)r,2 j ), sem qualquer contradição,a então ele calcula a mensagem mr,3 eu \(\triangleq\)(ESIGi(v′), \(\sigma\)r,3 eu). Caso contrário, ele calcula mr,3 eu \(\triangleq\) (ESIGi(\(\bot\)), \(\sigma\)r,3 eu). 2. eu destruo sua chave secreta efêmera skr,3 i , e então propaga mr,3 eu. aOu seja, ele não recebeu duas mensagens válidas contendo ESIGj(v′) e um ESIGj(v′′) diferente respectivamente, de um jogador j. Aqui e daqui em diante, exceto nas Condições Finais definidas posteriormente, sempre que um jogador honesto deseja mensagens de um determinado formato, mensagens contraditórias nunca são contadas ou consideradas válidas.Etapa 4: Resultado do GC e a primeira etapa do BBA⋆ Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 4 da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,4 ou não. • Se i /\(\in\)SV r,4, então i his interrompe imediatamente a execução do Passo 4. • Se i \(\in\)SV r,4, então depois de esperar um período de tempo t4 \(\triangleq\)t3 + 2\(\lambda\) = 5\(\lambda\) + Λ, i age da seguinte forma. 1. Ele calcula vi e gi, a saída do GC, como segue. (a) Se existe um valor v′ ̸= \(\bot\)tal que, entre todas as mensagens válidas mr,3 j ele tem recebidos, mais de 2/3 deles são da forma (ESIGj(v′), \(\sigma\)r,3 j ), então ele define vi \(\triangleq\)v′ e gi \(\triangleq\)2. (b) Caso contrário, se existir um valor v′ ̸= \(\bot\)tal que, entre todas as mensagens válidas senhor,3 j ele recebeu, mais de 1/3 deles são da forma (ESIGj(v′), \(\sigma\)r,3 j), então ele define vi \(\triangleq\)v′ e gi \(\triangleq\)1.a (c) Caso contrário, ele define vi \(\triangleq\)H(Br ǫ ) e gi \(\triangleq\)0. 2. Ele calcula bi, a entrada de BBA⋆, como segue: bi \(\triangleq\)0 se gi = 2, e bi \(\triangleq\)1 caso contrário. 3. Ele calcula a mensagem mr,4 eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,4 i ), destrói seu efêmero chave secreta skr,4 i , e então propaga mr,4 eu. aPode-se provar que v′ no caso (b), se existir, deve ser único.

Etapa s, 5 \(\leq\)s \(\leq\)m + 2, s −2 ≡0 mod 3: Uma etapa de BBA⋆ com moeda fixada em 0 Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir da terceira componente de Br−1 e verifica se i \(\in\)SV r,s. • Se i /\(\in\)SV r,s, então i interrompe imediatamente a sua própria execução do Passo s. • Se i \(\in\)SV r,s então ele age da seguinte forma. – Ele espera até que um período de tempo ts \(\triangleq\)ts−1 + 2\(\lambda\) = (2s −3)\(\lambda\) + Λ tenha passado. – Condição Final 0: Se, durante essa espera e em qualquer momento, existir uma string v ̸= \(\bot\)e um passo s′ tal que (a) 5 \(\leq\)s′ \(\leq\)s, s′ −2 ≡0 mod 3 - isto é, a etapa s′ é uma etapa fixada em moeda em 0, (b) recebi pelo menos tH = 2n 3 + 1 mensagens válidas mr,s′−1 j = (ESIGj(0), ESIGj(v), \(\sigma\)r,s′−1 j ),a e (c) recebi uma mensagem válida senhor,1 j = (Br j , esigj(H(Br j )), \(\sigma\)r,1 j ) com v = H(Br j ), então, eu interrompo sua própria execução do Passo s (e de fato da rodada r) imediatamente, sem propagar qualquer coisa; define Br = Br j; e define seu próprio CERT r como o conjunto de mensagens senhor,s′−1 j da subetapa (b).b – Condição Final 1: Se, durante essa espera e em qualquer momento, existir um passo s′ tal que (a') 6 \(\leq\)s′ \(\leq\)s, s′ −2 ≡1 mod 3 - isto é, a etapa s′ é uma etapa fixada em moeda para 1, e (b') i recebeu pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,s′−1 j ),c então, eu interrompo sua própria execução do Passo s (e de fato da rodada r) imediatamente, sem propagar qualquer coisa; define Br = Br ǫ; e define seu próprio CERT r como o conjunto de mensagens senhor,s′−1 j da subetapa (b'). – Caso contrário, ao final da espera, o usuário i faz o seguinte. Ele define vi como o voto majoritário dos vj nos segundos componentes de todos os votos válidos. senhor,s−1 j é o que ele recebeu. Ele calcula bi da seguinte maneira. Se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)0. Caso contrário, se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(1), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)1. Caso contrário, ele define bi \(\triangleq\)0. Ele computa a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i ), destrói seu efêmero chave secreta skr,s i e então propaga mr,s eu. aEssa mensagem do jogador j é contada mesmo que o jogador i também tenha recebido uma mensagem de j assinando por 1. Coisas semelhantes para a Condição Final 1. Conforme mostrado na análise, isso é feito para garantir que todos os usuários honestos saibam Br dentro do tempo \(\lambda\) um do outro. bO usuário i agora conhece Br e seus próprios acabamentos de rodada. Ele ainda ajuda a propagar mensagens como um usuário genérico, mas não inicia nenhuma propagação como um verificador (r, s). Em particular, ele ajudou a propagar todas as mensagens em seu CERT r, o que é suficiente para o nosso protocolo. Observe que ele também deve definir bi \(\triangleq\)0 para o protocolo BA binário, mas bi não é necessário neste caso de qualquer maneira. Coisas semelhantes para todas as instruções futuras. cNeste caso, não importa quais são os vj’s.Etapa s, 6 \(\leq\)s \(\leq\)m + 2, s −2 ≡1 mod 3: Uma etapa de BBA⋆ fixada em moeda para 1 Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,s ou não. • Se i /\(\in\)SV r,s, então i interrompe imediatamente a sua própria execução do Passo s. • Se i \(\in\)SV r,s então ele faz o seguinte. – Ele espera até que um período de tempo ts \(\triangleq\)(2s −3)\(\lambda\) + Λ tenha passado. – Condição Final 0: As mesmas instruções das etapas Coin-Fixed-To-0. – Condição Final 1: As mesmas instruções das etapas Coin-Fixed-To-0. – Caso contrário, ao final da espera, o usuário i faz o seguinte. Ele define vi como o voto majoritário dos vj nos segundos componentes de todos os votos válidos. senhor,s−1 j é o que ele recebeu. Ele calcula bi da seguinte maneira. Se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)0. Caso contrário, se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(1), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)1. Caso contrário, ele define bi \(\triangleq\)1. Ele computa a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i ), destrói seu efêmero chave secreta skr,s i e então propaga mr,s eu.

Etapa s, 7 \(\leq\)s \(\leq\)m + 2, s −2 ≡2 mod 3: Uma etapa de BBA⋆ com moeda genuinamente invertida Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,s ou não. • Se i /\(\in\)SV r,s, então i interrompe imediatamente a sua própria execução do Passo s. • Se i \(\in\)SV r,s então ele faz o seguinte. – Ele espera até que um período de tempo ts \(\triangleq\)(2s −3)\(\lambda\) + Λ tenha passado. – Condição Final 0: As mesmas instruções das etapas Coin-Fixed-To-0. – Condição Final 1: As mesmas instruções das etapas Coin-Fixed-To-0. – Caso contrário, ao final da espera, o usuário i faz o seguinte. Ele define vi como o voto majoritário dos vj nos segundos componentes de todos os votos válidos. senhor,s−1 j é o que ele recebeu. Ele calcula bi da seguinte maneira. Se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)0. Caso contrário, se mais de 2/3 de todos os mr,s−1 válidos j que ele recebeu são da forma (ESIGj(1), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele define bi \(\triangleq\)1. Caso contrário, seja SV r,s−1 eu ser o conjunto de (r, s −1)-verificadores dos quais ele recebeu um valor válido mensagem senhor,s-1 j . Ele define bi \(\triangleq\)lsb(minj\(\in\)SV r,s−1 eu H(\(\sigma\)r,s−1 j )). Ele computa a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i ), destrói seu efêmero chave secreta skr,s i e então propaga mr,s eu.

Etapa m + 3: A última etapa do BBA⋆a Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa m + 3 da rodada r assim que ele conhece Br−1. • O usuário i calcula Qr−1 a partir do terceiro componente de Br−1 e verifica se i \(\in\)SV r,m+3 ou não. • Se i /\(\in\)SV r,m+3, então i interrompe imediatamente a sua própria execução do Passo m + 3. • Se i \(\in\)SV r,m+3 então ele faz o seguinte. – Ele espera até que um período de tempo tm+3 \(\triangleq\)tm+2 + 2\(\lambda\) = (2m + 3)\(\lambda\) + Λ tenha passado. – Condição Final 0: As mesmas instruções das etapas Coin-Fixed-To-0. – Condição Final 1: As mesmas instruções das etapas Coin-Fixed-To-0. – Caso contrário, ao final da espera, o usuário i faz o seguinte. Ele definei \(\triangleq\)1 e Br \(\triangleq\)Br ǫ. Ele calcula a mensagem mr,m+3 eu = (ESIGi(outi), ESIGi(H(Br)), \(\sigma\)r,m+3 eu ), destrói seu chave secreta efêmera skr,m+3 eu , e então propaga mr,m+3 eu para certificar Br.b aCom probabilidade esmagadora, BBA⋆terminou antes desta etapa e especificamos esta etapa para completude. bUm certificado da Etapa m + 3 não precisa incluir ESIGi(outi). Nós o incluímos apenas por uniformidade: o os certificados agora têm um formato uniforme, independentemente da etapa em que são gerados.Reconstrução do Bloco Round-r por Não-Verificadores Instruções para cada usuário i no sistema: O usuário i inicia sua própria rodada r assim que souber Br−1, e espera pelas informações do bloco como segue. – Se, durante essa espera e em qualquer momento, existir uma string v e um passo s′ tal isso (a) 5 \(\leq\)s′ \(\leq\)m + 3 com s′ −2 ≡0 mod 3, (b) recebi pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(0), ESIGj(v), \(\sigma\)r,s′−1 j ) e (c) recebi uma mensagem válida senhor,1 j = (Br j , esigj(H(Br j )), \(\sigma\)r,1 j ) com v = H(Br j ), então, i interrompe imediatamente sua própria execução da rodada r; define Br = Br j; e define seu próprio CERT r ser o conjunto de mensagens mr,s′−1 j do subpasso (b). – Se, durante essa espera e em qualquer momento, existir uma etapa s′ tal que (a') 6 \(\leq\)s′ \(\leq\)m + 3 com s′ −2 ≡1 mod 3, e (b') i recebeu pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,s′−1 j ), então, i interrompe imediatamente sua própria execução da rodada r; define Br = Br ǫ; e define seu próprio CERT r ser o conjunto de mensagens mr,s′−1 j da subetapa (b'). – Se, durante essa espera e em qualquer momento, recebi pelo menos mensagens válidas senhor,m+3 j = (ESIGj(1), ESIGj(H(Br ǫ )), \(\sigma\)r,m+3 j ), então eu interrompo sua própria execução da rodada r imediatamente, define Br = Br ǫ , e define seu próprio CERT r como o conjunto de mensagens mr,m+3 j por 1 e H(Br ǫ). 5.5 Análise de Algorand ′ 1 Introduzimos as seguintes notações para cada rodada r \(\geq\)0, utilizada na análise. • Seja T r o momento em que o primeiro usuário honesto conhece Br−1. • Seja Ir+1 o intervalo [T r+1, T r+1 + \(\lambda\)]. Observe que T 0 = 0 pela inicialização do protocolo. Para cada s \(\geq\)1 e i \(\in\)SV r,s, lembre-se que ar,s eu e \(\beta\)r,s eu são respectivamente o horário de início e o horário de término da etapa s do jogador i. Além disso, lembre-se que ts = (2s −3)\(\lambda\) + Λ para cada 2 \(\leq\)s \(\leq\)m + 3. Além disso, sejam I0 \(\triangleq\){0} e t1 \(\triangleq\)0. Finalmente, lembre-se que Lr \(\leq\)m/3 é uma variável aleatória que representa o número de tentativas de Bernoulli precisava ver um 1, quando cada tentativa é 1 com probabilidade ph 2 e há no máximo m/3 tentativas. Se tudo as tentativas falham então Lr \(\triangleq\)m/3. Na análise ignoramos o tempo de cálculo, pois é de facto insignificante em relação ao tempo necessário para propagar mensagens. Em qualquer caso, usando \(\lambda\) e Λ ligeiramente maiores, o tempo de cálculo pode ser incorporado diretamente na análise. A maioria das declarações abaixo são sustentadas “com esmagadora probabilidade”, e não podemos enfatizar repetidamente esse fato na análise.5.6 Teorema Principal Teorema 5.1. As seguintes propriedades são válidas com probabilidade esmagadora para cada rodada r \(\geq\)0: 1. Todos os usuários honestos concordam com o mesmo bloco Br. 2. Quando o líder \(\ell\)r é honesto, o bloco Br é gerado por \(\ell\)r, Br contém um conjunto de pagamentos máximo recebido por \(\ell\)r no tempo \(\alpha\)r,1 \(\ell\)r , T r+1 \(\leq\)T r + 8\(\lambda\) + Λ e todos os usuários honestos conhecem Br na época intervalo Ir+1. 3. Quando o líder \(\ell\)r é malicioso, T r+1 \(\leq\)T r + (6Lr + 10)\(\lambda\) + Λ e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1. 4. ph = h2(1 + h −h2) para Lr, e o líder \(\ell\)r é honesto com probabilidade pelo menos ph. Antes de provar nosso teorema principal, façamos duas observações. Observações. • Geração de blocos e latência real. O tempo para gerar o bloco Br é definido como T r+1 −T r. Ou seja, é definido como a diferença entre a primeira vez que um usuário honesto aprende Br e a primeira vez que algum usuário honesto aprende Br−1. Quando o líder da rodada é honesto, a Propriedade 2 é nossa o teorema principal garante que o tempo exato para gerar Br é 8\(\lambda\) + Λ tempo, não importa o que o valor preciso de h > 2/3 pode ser. Quando o líder é malicioso, a Propriedade 3 implica que o o tempo esperado para gerar Br é limitado por (12 ph + 10)\(\lambda\) + Λ, novamente não importa a precisão valor de h.18 Entretanto, o tempo esperado para gerar Br depende do valor preciso de h. Na verdade, pela Propriedade 4, ph = h2(1 + h −h2) e o líder é honesto com probabilidade pelo menos ph, portanto E[T r+1 −T r] \(\leq\)h2(1 + h −h2) \(\cdot\) (8\(\lambda\) + Λ) + (1 −h2(1 + h −h2))(( 12 h2(1 + h −h2) + 10)\(\lambda\) + Λ). Por exemplo, se h = 80%, então E[T r+1 −T r] \(\leq\)12,7\(\lambda\) + Λ. • \(\lambda\) versus Λ. Observe que o tamanho das mensagens enviadas pelos verificadores em uma etapa Algorand ′ é dominado pelo comprimento das chaves de assinatura digital, que podem permanecer fixas, mesmo quando o número de usuários é enorme. Observe também que, em qualquer passo s > 1, o mesmo número esperado n de verificadores pode ser usado se o número de usuários for 100 mil, 100 milhões ou 100 milhões. Isso ocorre porque n apenas depende de h e F. Em suma, portanto, salvo uma necessidade repentina de aumentar o comprimento da chave secreta, o valor de \(\lambda\) deve permanecer o mesmo, não importa quão grande seja o número de usuários no futuro previsível. Por outro lado, para qualquer taxa de transação, o número de transações cresce com o número de usuários. Portanto, para processar todas as novas transações em tempo hábil, o tamanho de um bloco deve também cresce com o número de usuários, fazendo com que Λ também cresça. Assim, no longo prazo, deveríamos ter \(\lambda\) << Λ. Conseqüentemente, é apropriado ter um coeficiente maior para \(\lambda\) e, na verdade, um coeficiente de 1 para Λ. Prova do Teorema 5.1. Provamos as Propriedades 1–3 por indução: assumindo que elas são válidas para a rodada r −1 (sem perda de generalidade, eles são válidos automaticamente para “rodada -1” quando r = 0), nós os provamos para rodada R. 18De fato, E[T r+1 −T r] \(\leq\)(6E[Lr] + 10)\(\lambda\) + Λ = (6 \(\cdot\) 2 ph + 10)\(\lambda\) + Λ = ( 12 ph + 10)\(\lambda\) + Λ.Como Br−1 é definido exclusivamente pela hipótese indutiva, o conjunto SV r,s é definido exclusivamente para cada etapa s da rodada r. Pela escolha de n1, SV r,1 ̸= \(\emptyset\)com probabilidade esmagadora. Nós agora enuncie os dois lemas a seguir, provados nas Seções 5.7 e 5.8. Durante toda a indução e em nas provas dos dois lemas, a análise para a rodada 0 é quase a mesma que a etapa indutiva, e destacaremos as diferenças quando elas ocorrerem. Lema 5.2. [Lema da completude] Assumindo que as propriedades 1–3 são válidas para a rodada r−1, quando o líder \(\ell\)r é honesto, com probabilidade esmagadora, • Todos os usuários honestos concordam com o mesmo bloco Br, que é gerado por \(\ell\)r e contém um valor máximo conjunto de pagamentos recebido por \(\ell\)r no tempo \(\alpha\)r,1 \(\ell\)r \(\in\)Ir; e • T r+1 \(\leq\)T r + 8\(\lambda\) + Λ e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1. Lema 5.3. [Lema de Solidez] Assumindo que as Propriedades 1–3 são válidas para a rodada r −1, quando o líder \(\ell\)r é malicioso, com probabilidade esmagadora, todos os usuários honestos concordam com o mesmo bloco Br, T r+1 \(\leq\) T r + (6Lr + 10)\(\lambda\) + Λ e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1. As propriedades 1–3 são válidas aplicando os Lemas 5.2 e 5.3 a r = 0 e à etapa indutiva. Finalmente, reafirmamos a Propriedade 4 como o seguinte lema, provado na Seção 5.9. Lema 5.4. Dadas as propriedades 1–3 para cada rodada antes de r, ph = h2(1 + h −h2) para Lr, e o o líder \(\ell\)r é honesto com probabilidade de pelo menos ph. Combinando os três lemas acima, o Teorema 5.1 é válido. ■ O lema abaixo afirma várias propriedades importantes sobre o round r dado o indutivo hipótese, e será usada nas provas dos três lemas acima. Lema 5.5. Suponha que as propriedades 1–3 sejam válidas para a rodada r −1. Para cada etapa s \(\geq\)1 da rodada r e cada verificador honesto i \(\in\)HSV r,s, temos que (a) \(\alpha\)r,s eu \(\in\)Ir; (b) se o jogador i esperou um período de tempo ts, então \(\beta\)r,s eu \(\in\)[T r + ts, T r + \(\lambda\) + ts] para r > 0 e \(\beta\)r,s eu = ts para r = 0; e (c) se o jogador i esperou um período de tempo ts, então no tempo \(\beta\)r,s eu, ele recebeu todas as mensagens enviado por todos os verificadores honestos j \(\in\)HSV r,s′ para todas as etapas s′ < s. Além disso, para cada passo s \(\geq\)3, temos que (d) não existem dois jogadores diferentes i, i′ \(\in\)SV r,s e dois valores diferentes v, v′ do mesmo duração, tal que ambos os jogadores esperaram um período de tempo ts, mais de 2/3 de todos os mensagens válidas senhor,s−1 j jogador que recebo assinou por v, e mais de 2/3 de todos os válidos mensagens senhor,s-1 j o jogador que i′ recebe assinou por v′. Prova. A propriedade (a) segue diretamente da hipótese indutiva, pois o jogador i conhece Br−1 no intervalo de tempo Ir e inicia seus próprios passos imediatamente. A propriedade (b) segue diretamente de (a): uma vez que jogador i esperou um certo tempo ts antes de agir, \(\beta\)r,s eu = \(\alpha\)r,s eu + ts. Observe que \(\alpha\)r,s eu = 0 para r = 0. Provamos agora a Propriedade (c). Se s = 2, então pela Propriedade (b), para todos os verificadores j \(\in\)HSV r,1 temos \(\beta\)r,s eu = \(\alpha\)r,s eu + ts \(\geq\)T r + ts = T r + \(\lambda\) + Λ \(\geq\) \(\beta\)r,1 j +Λ.Como cada verificador j \(\in\)HSV r,1 envia sua mensagem no tempo \(\beta\)r,1 j e a mensagem chega a todos os honestos usuários em no máximo Λ tempo, por tempo \(\beta\)r,s eu jogador i recebeu as mensagens enviadas por todos os verificadores em HSV r,1 conforme desejado. Se s > 2, então ts = ts−1 + 2\(\lambda\). Pela Propriedade (b), para todas as etapas s′ < s e todos os verificadores j \(\in\)HSV r,s′, \(\beta\)r,s eu = \(\alpha\)r,s eu + ts \(\geq\)T r + ts = T r + ts−1 + 2\(\lambda\) \(\geq\)T r + ts′ + 2\(\lambda\) = T r + \(\lambda\) + ts′ + \(\lambda\) \(\geq\) \(\beta\)r,s′ j +\(\lambda\). Como cada verificador j \(\in\)HSV r,s′ envia sua mensagem no tempo \(\beta\)r,s′ j e a mensagem chega a todos os honestos usuários em no máximo \(\lambda\) tempo, por tempo \(\beta\)r,s eu jogador i recebeu todas as mensagens enviadas por todos os verificadores honestos em HSV r,s′ para todo s′ < s. Assim, a Propriedade (c) é válida. Finalmente, provamos a Propriedade (d). Observe que os verificadores j \(\in\)SV r,s−1 sinalizam no máximo duas coisas em Etapa s −1 usando suas chaves secretas efêmeras: um valor vj do mesmo comprimento que a saída do Função hash, e também um bit bj \(\in\){0, 1} se s −1 \(\geq\)4. É por isso que no enunciado do lema exigimos que v e v′ tenham o mesmo comprimento: muitos verificadores podem ter assinado um valor hash v e um bit b, portanto, ambos ultrapassam o limite de 2/3. Suponha, por contradição, que existam os verificadores desejados i, i′ e os valores v, v′. Observe que alguns verificadores maliciosos no MSV r,s−1 podem ter assinado v e v′, mas cada um deles honesto O verificador em HSV r,s−1 assinou no máximo um deles. Pela propriedade (c), tanto i quanto i′ receberam todas as mensagens enviadas por todos os verificadores honestos em HSV r,s−1. Seja HSV r,s−1(v) o conjunto de verificadores honestos (r, s −1) que assinaram v, MSV r,s−1 eu o conjunto de verificadores maliciosos (r, s −1) dos quais i recebeu uma mensagem válida, e MSV r,s−1 eu (v) o subconjunto de MSV r,s−1 eu de quem recebi uma assinatura de mensagem válida v. Pelos requisitos para eu e v, temos razão \(\triangleq\)|HSV r,s−1(v)| + |MSV r,s−1 eu (v)| |HSV r,s−1| + |MSV r,s−1 eu |

2 3. (1) Nós primeiro mostramos |MSV r,s−1 eu (v)| \(\leq\)|HSV r,s−1(v)|. (2) Supondo o contrário, pelas relações entre os parâmetros, com probabilidade esmagadora |HSV r,s−1| > 2|MSV r,s−1| \(\geq\)2|MSV r,s−1 eu |, assim razão < |HSV r,s−1(v)| + |MSV r,s−1 eu (v)| 3|MSV r,s−1 eu | < 2|MSV r,s−1 eu (v)| 3|MSV r,s−1 eu | \(\leq\)2 3, contradizendo a desigualdade 1. A seguir, pela Desigualdade 1 temos 2|HSV r,s−1| + 2|MSV r,s−1 eu | < 3|HSV r,s−1(v)| + 3|MSV r,s−1 eu (v)| \(\leq\) 3|HSV r,s−1(v)| + 2|MSV r,s−1 eu | + |MSV r,s−1 eu (v)|. Combinando com a Desigualdade 2, 2|HSV r,s−1| < 3|HSV r,s−1(v)| + |MSV r,s−1 eu (v)| \(\leq\)4|HSV r,s−1(v)|, o que implica |HSV r,s−1(v)| > 1 2|HSV r,s−1|.Da mesma forma, pelos requisitos para i′ e v′, temos |HSV r,s−1(v′)| > 1 2|HSV r,s−1|. Como um verificador honesto j \(\in\)HSV r,s−1 destrói sua chave secreta efêmera skr,s−1 j antes de propagar sua mensagem, o Adversário não pode falsificar a assinatura de j para um valor que j não assinou, após aprendendo que j é um verificador. Assim, as duas desigualdades acima implicam |HSV r,s−1| \(\geq\)|HSV r,s−1(v)| + |HSV r,s−1(v′)| > |HSV r,s−1|, uma contradição. Consequentemente, os desejados i, i′, v, v′ não existem, e A propriedade (d) é válida. ■ 5.7 O lema da completude Lema 5.2. [Lema da completude, reformulado] Assumindo que as propriedades 1–3 são válidas para a rodada r−1, quando o líder \(\ell\)r é honesto, com probabilidade esmagadora, • Todos os usuários honestos concordam com o mesmo bloco Br, que é gerado por \(\ell\)r e contém um valor máximo conjunto de pagamentos recebido por \(\ell\)r no tempo \(\alpha\)r,1 \(\ell\)r \(\in\)Ir; e • T r+1 \(\leq\)T r + 8\(\lambda\) + Λ e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1. Prova. Pela hipótese indutiva e Lema 5.5, para cada etapa s e verificador i \(\in\)HSV r,s, ar,s eu \(\in\)Ir. Abaixo analisamos o protocolo passo a passo. Etapa 1. Por definição, todo verificador honesto i \(\in\)HSV r,1 propaga a mensagem desejada mr,1 eu em tempo \(\beta\)r,1 eu = \(\alpha\)r,1 eu, onde senhor,1 eu = (Br eu , esigi(H(Br eu )), \(\sigma\)r,1 eu), irmão eu = (r, PAGAR r eu, SIGi(Qr−1), H(Br−1)), e PAGUE r i é um conjunto de pagamentos máximo entre todos os pagamentos que vi até o momento \(\alpha\)r,1 eu. Etapa 2. Fixe arbitrariamente um verificador honesto i \(\in\)HSV r,2. Pelo Lema 5.5, quando o jogador i termina esperando no tempo \(\beta\)r,2 eu = \(\alpha\)r,2 eu + t2, ele recebeu todas as mensagens enviadas pelos verificadores em HSV r,1, incluindo senhor,1 \(\ell\)r. Pela definição de \(\ell\)r, não existe outro jogador em PKr−k cuja credencial seja hash valor é menor que H(\(\sigma\)r,1 \(\ell\)r). Claro, o Adversário pode corromper \(\ell\)r depois de ver que H(\(\sigma\)r,1 \(\ell\)r) é muito pequeno, mas a essa altura o jogador \(\ell\)r destruiu sua chave efêmera e a mensagem mr,1 \(\ell\)r foi propagado. Assim, o verificador i define seu próprio líder como o jogador \(\ell\)r. Assim, no tempo \(\beta\)r,2 eu, verificador i propaga mr,2 eu = (ESIGi(v′ eu), \(\sigma\)r,2 eu), onde v′ eu = H(Br \(\ell\)r). Quando r = 0, a única diferença é que \(\beta\)r,2 eu = t2 em vez de estar em um intervalo. Coisas semelhantes podem ser ditas para passos futuros e não os enfatizarei novamente. Etapa 3. Fixe arbitrariamente um verificador honesto i \(\in\)HSV r,3. Pelo Lema 5.5, quando o jogador i termina esperando no tempo \(\beta\)r,3 eu = \(\alpha\)r,3 eu + t3, ele recebeu todas as mensagens enviadas pelos verificadores em HSV r,2. Pelas relações entre os parâmetros, com probabilidade esmagadora |HSV r,2| > 2|MSV r,2|. Além disso, nenhum verificador honesto assinaria mensagens contraditórias, e o Adversário não pode falsificar a assinatura de um verificador honesto depois que este último tiver destruído seu correspondente chave secreta efêmera. Assim, mais de 2/3 de todas as mensagens (r, 2) válidas que recebi são de verificadores honestos e da forma mr,2 j = (ESIGj(H(Br \(\ell\)r)), \(\sigma\)r,2 j ), sem contradição. Assim, no tempo \(\beta\)r,3 eu jogador i propaga mr,3 eu = (ESIGi(v′), \(\sigma\)r,3 eu ), onde v′ = H(Br \(\ell\)r).Etapa 4. Fixe arbitrariamente um verificador honesto i \(\in\)HSV r,4. Pelo Lema 5.5, o jogador i recebeu todos mensagens enviadas pelos verificadores no HSV r,3 quando ele termina de esperar no tempo \(\beta\)r,4 eu = \(\alpha\)r,4 eu +t4. Semelhante a Etapa 3, mais de 2/3 de todas as mensagens (r, 3) válidas que recebi são de verificadores honestos e da forma senhor,3 j = (ESIGj(H(Br \(\ell\)r)), \(\sigma\)r,3 j). Assim, o jogador i define vi = H(Br \(\ell\)r), gi = 2 e bi = 0. No tempo \(\beta\)r,4 eu = \(\alpha\)r,4 eu +t4 ele propaga senhor,4 eu = (ESIGi(0), ESIGi(H(Br \(\ell\)r)), \(\sigma\)r,4 eu). Etapa 5. Fixe arbitrariamente um verificador honesto i \(\in\)HSV r,5. Pelo Lema 5.5, jogador eu teria recebeu todas as mensagens enviadas pelos verificadores no HSV r,4 se ele esperou até o tempo \(\alpha\)r,5 eu + t5. Observe que |HSV r,4| \(\geq\)tH.19 Observe também que todos os verificadores em HSV r,4 assinaram para H(Br \(\ell\)r). Como |MSV r,4| < tH, não existe v′ ̸= H(Br \(\ell\)r) que poderia ter sido assinado por tH verificadores em SV r,4 (que seriam necessariamente maliciosos), então o jogador i não para antes de ter recebeu mensagens válidas mr,4 j = (ESIGj(0), ESIGj(H(Br \(\ell\)r)), \(\sigma\)r,4 j). Seja T o momento em que o último evento acontece. Algumas dessas mensagens podem ser de jogadores maliciosos, mas porque |MSV r,4| < tH, pelo menos um deles é de um verificador honesto em HSV r,4 e é enviado após o tempo Tr+t4. Assim, T \(\geq\)T r +t4 > T r +\(\lambda\)+Λ \(\geq\) \(\beta\)r,1 \(\ell\)r +Λ, e no momento T o jogador i também recebeu a mensagem senhor,1 \(\ell\)r. Pela construção do protocolo, o jogador i para no tempo \(\beta\)r,5 eu = T sem propagar qualquer coisa; define Br = Br \(\ell\)r; e define seu próprio CERT r como o conjunto de (r, 4) mensagens para 0 e H(Br \(\ell\)r) que ele recebeu. Etapa s > 5. Da mesma forma, para qualquer passo s > 5 e qualquer verificador i \(\in\)HSV r,s, o jogador i teria recebeu todas as mensagens enviadas pelos verificadores no HSV r,4 se ele esperou até o tempo \(\alpha\)r,s eu + ts. Pelo mesma análise, jogador i para sem propagar nada, configurando Br = Br \(\ell\)r (e definindo seu próprio CERT r corretamente). É claro que os verificadores maliciosos podem não parar e podem propagar mensagens, mas porque |MSV r,s| <tH, por indução nenhum outro v′ poderia ser assinado pelos verificadores tH em qualquer passo 4 \(\leq\)s′ < s, portanto, os verificadores honestos só param porque receberam o valor válido (r, 4)-mensagens para 0 e H(Br \(\ell\)r). Reconstrução do Bloco Round-r. A análise do Passo 5 aplica-se a uma abordagem honesta genérica. usuário eu quase sem nenhuma alteração. Na verdade, o jogador i inicia sua própria rodada r no intervalo Ir e só irá parar no instante T quando tiver recebido tH mensagens válidas (r, 4) para H(Br \(\ell\)r). Novamente porque pelo menos uma dessas mensagens é de verificadores honestos e é enviada após o tempo T r + t4, o jogador i tem também recebeu senhor,1 \(\ell\)r pelo tempo T. Assim, ele define Br = Br \(\ell\)r com o CERT r adequado. Resta apenas mostrar que todos os usuários honestos terminam sua rodada r dentro do intervalo de tempo Ir+1. Pela análise da Etapa 5, todo verificador honesto i \(\in\)HSV r,5 conhece Br em ou antes de \(\alpha\)r,5 eu + t5 \(\leq\) Tr + \(\lambda\) + t5 = Tr + 8\(\lambda\) + Λ. Como T r+1 é o momento em que o primeiro usuário honesto conhece Br, temos T r+1 \(\leq\)T r + 8\(\lambda\) + Λ conforme desejado. Além disso, quando o jogador conhece o Br, ele já ajudou a propagar as mensagens em seu CERT r. Observe que todas essas mensagens serão recebidas por todos os usuários honestos dentro do tempo \(\lambda\), mesmo que 19Estritamente falando, isto acontece com uma probabilidade muito elevada, mas não necessariamente esmagadora. No entanto, isso a probabilidade afeta ligeiramente o tempo de execução do protocolo, mas não afeta sua correção. Quando h = 80%, então |HSV r,4| \(\geq\)tH com probabilidade 1 −10−8. Se este evento não ocorrer, o protocolo continuará por mais um 3 etapas. Como a probabilidade de isso não ocorrer em duas etapas é insignificante, o protocolo terminará na Etapa 8. Em expectativa, então, o número de etapas necessárias é quase 5.player ir foi o primeiro player a propagá-los. Além disso, seguindo a análise acima, temos T r+1 \(\geq\)T r + t4 \(\geq\) \(\beta\)r,1 \(\ell\)r + Λ, portanto, todos os usuários honestos receberam mr,1 \(\ell\)r por tempo T r+1 + \(\lambda\). Assim, todos os usuários honestos conhecem Br no intervalo de tempo Ir+1 = [T r+1, T r+1 + \(\lambda\)]. Finalmente, para r = 0 temos na verdade T 1 \(\leq\)t4 + \(\lambda\) = 6\(\lambda\) + Λ. Combinando tudo junto, O lema 5.2 é válido. ■ 5.8 O Lema da Solidez Lema 5.3. [Lema da Solidez, reformulado] Assumindo que as Propriedades 1–3 são válidas para a rodada r −1, quando o líder \(\ell\)r é malicioso, com grande probabilidade, todos os usuários honestos concordam com o mesmo bloco Br, T r+1 \(\leq\)T r + (6Lr + 10)\(\lambda\) + Λ e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1. Prova. Consideramos as duas partes do protocolo, GC e BBA⋆, separadamente. GC. Pela hipótese indutiva e pelo Lema 5.5, para qualquer passo s \(\in\){2, 3, 4} e qualquer passo honesto verificador i \(\in\)HSV r,s, quando o jogador i atua no tempo \(\beta\)r,s eu = \(\alpha\)r,s eu +ts, ele recebeu todas as mensagens enviadas por todos os verificadores honestos nas etapas s′ < s. Distinguimos dois casos possíveis para o passo 4. Caso 1. Nenhum verificador i \(\in\)HSV r,4 define gi = 2. Neste caso, por definição bi = 1 para todos os verificadores i \(\in\)HSV r,4. Ou seja, eles começam com um acordo sobre 1 no protocolo BA binário. Eles podem não ter um acordo sobre seus vis, mas isso não importa, como veremos no BA binário. Caso 2. Existe um verificador ˆi \(\in\)HSV r,4 tal que gˆi = 2. Neste caso, mostramos que (1) gi \(\geq\)1 para todo i \(\in\)HSV r,4, (2) existe um valor v′ tal que vi = v′ para todo i \(\in\)HSV r,4, e (3) existe uma mensagem válida mr,1 \(\ell\) de algum verificador \(\ell\) \(\in\)SV r,1 tal que v′ = H(Br \(\ell\)). Na verdade, como o jogador ˆi é honesto e define gˆi = 2, mais de 2/3 de todas as mensagens válidas mr,3 j ele recebeu são para o mesmo valor v′ ̸= \(\bot\), e ele definiu vˆi = v′. Pela Propriedade (d) no Lema 5.5, para qualquer outro verificador honesto (r, 4) i, não pode ser que mais de 2/3 de todas as mensagens válidas mr,3 j que i′ recebeu têm o mesmo valor v′′ ̸= v′. Conseqüentemente, se i definir gi = 2, deve ser que i tenha visto > 2/3 de maioria para v′ também e defina vi = v′, conforme desejado. Agora considere um verificador arbitrário i \(\in\)HSV r,4 com gi < 2. Semelhante à análise de Propriedade (d) no Lema 5.5, porque o jogador ˆi obteve > 2/3 de maioria para v′, mais de 1 2|HSV r,3| honesto (r, 3)-verificadores assinaram v′. Porque recebi todas as mensagens de verificadores honestos (r, 3) de tempo \(\beta\)r,4 eu = \(\alpha\)r,4 eu + t4, ele recebeu em particular mais de 1 2|HSV r,3| mensagens deles para v'. Porque |HSV r,3| > 2|MSV r,3|, i obteve > 1/3 de maioria para v′. Assim, jogador i define gi = 1 e a propriedade (1) é válida. O jogador i necessariamente define vi = v′? Suponha que exista um valor diferente v′′ ̸= \(\bot\)tal que o jogador i também obteve > 1/3 de maioria para v′′. Algumas dessas mensagens podem ser de mensagens maliciosas verificadores, mas pelo menos um deles é de algum verificador honesto j \(\in\)HSV r,3: de fato, porque |HSV r,3| > 2|MSV r,3| e recebi todas as mensagens do HSV r,3, o conjunto de malware verificadores de quem i recebeu uma mensagem válida (r, 3) conta como <1/3 de todas as mensagens válidas mensagens que recebeu.Por definição, o jogador j deve ter visto > 2/3 de maioria para v′′ entre todas as mensagens (r, 2) válidas ele recebeu. No entanto, já temos que alguns outros verificadores (r, 3) honestos viram Maioria de 2/3 para v′ (porque assinaram v′). Pela Propriedade (d) do Lema 5.5, isso não pode acontecer e tal valor v′′ não existe. Assim, o jogador i deve ter definido vi = v′ conforme desejado, e Propriedade (2) é válida. Finalmente, dado que alguns verificadores (r, 3) honestos viram uma maioria > 2/3 para v′, alguns (na verdade, mais da metade dos verificadores) honestos (r, 2) assinaram v′ e propagaram suas mensagens. Pela construção do protocolo, aqueles verificadores (r, 2) honestos devem ter recebido um valor válido. mensagem senhor,1 \(\ell\) de algum jogador \(\ell\) \(\in\)SV r,1 com v′ = H(Br \(\ell\)), portanto a Propriedade (3) é válida. BBA⋆. Novamente distinguimos dois casos. Caso 1. Todos os verificadores i \(\in\)HSV r,4 possuem bi = 1. Isso acontece seguindo o Caso 1 do GC. Como |MSV r,4| < tH, neste caso não há verificador em SV r,5 poderia coletar ou gerar mensagens válidas (r, 4) para o bit 0. Assim, nenhum verificador honesto em HSV r,5 pararia porque conhece um bloco não vazio, o Ir. Além disso, embora existam pelo menos tH mensagens (r, 4) válidas para o bit 1, s′ = 5 não satisfaz s′ −2 ≡1 mod 3, portanto, nenhum verificador honesto em HSV r,5 pararia porque sabe que Br = Br ǫ. Em vez disso, todo verificador i \(\in\)HSV r,5 atua no tempo \(\beta\)r,5 eu = \(\alpha\)r,5 eu + t5, quando ele tiver recebido todos mensagens enviadas pelo HSV r,4 seguindo o Lema 5.5. Assim, o jogador i obteve > 2/3 de maioria para 1 e define bi = 1. Na Etapa 6, que é uma etapa Coin-Fixed-To-1, embora s′ = 5 satisfaça s′ −2 ≡0 mod 3, há não existem mensagens válidas (r, 4) para o bit 0, portanto, nenhum verificador em HSV r,6 pararia porque ele conhece um bloco não vazio, Ir. No entanto, com s′ = 6, s′ −2 ≡1 mod 3 e existem |HSV r,5| \(\geq\)tH mensagens válidas (r, 5) para o bit 1 do HSV r,5. Para cada verificador i \(\in\)HSV r,6, seguindo o Lema 5.5, no tempo ou antes dele \(\alpha\)r,6 eu + jogador t6 eu recebeu todas as mensagens do HSV r,5, então paro sem propagar nada e configuro Br = Br ǫ. Seu CERT r é o conjunto de tH mensagens válidas (r, 5) mr,5 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,5 j) recebido por ele quando ele para. Em seguida, seja o jogador i um verificador honesto na etapa s > 6 ou um usuário honesto genérico (ou seja, não verificador). Semelhante à prova do Lema 5.2, o jogador i define Br = Br ǫ e define o seu próprio CERT r como o conjunto de tH mensagens válidas (r, 5) mr,5 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,5 j) ele tem recebido. Finalmente, semelhante ao Lema 5.2, Tr+1 \(\leq\) min i\(\in\)HSV r,6 \(\alpha\)r,6 eu + t6 \(\leq\)T r + \(\lambda\) + t6 = T r + 10\(\lambda\) + Λ, e todos os usuários honestos conhecem Br no intervalo de tempo Ir+1, porque o primeiro usuário honesto i que sabe que Br ajudou a propagar as mensagens (r, 5) em seu CERT r. Caso 2. Existe um verificador ˆi \(\in\)HSV r,4 com bˆi = 0. Isto acontece seguindo o Caso 2 do GC e é o caso mais complexo. Pela análise do GC, neste caso existe uma mensagem válida mr,1 \(\ell\) tal que vi = H(Br \(\ell\)) para todo i \(\in\)HSV r,4. Nota que os verificadores no HSV r,4 podem não ter um acordo sobre seus bi’s. Para qualquer passo s \(\in\){5, . . . , m + 3} e verificador i \(\in\)HSV r,s, pelo Lema 5.5 jogador eu teria recebeu todas as mensagens enviadas por todos os verificadores honestos em HSV r,4 \(\cup\) \(\cdots\) \(\cup\)HSV r,s−1 se ele esperou por tempo ts.Consideramos agora o seguinte evento E: existe um passo s∗\(\geq\)5 tal que, pela primeira vez tempo no BA binário, algum jogador i∗\(\in\)SV r,s∗(seja malicioso ou honesto) deveria parar sem propagar nada. Usamos “deveria parar” para enfatizar o fato de que, se o jogador i∗ é malicioso, então ele pode fingir que não deveria parar de acordo com o protocolo e propagar mensagens da escolha do Adversário. Além disso, pela construção do protocolo, quer (E.a) i∗é capaz de coletar ou gerar pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(0), ESIGj(v), \(\sigma\)r,s′−1 j ) para os mesmos v e s′, com 5 \(\leq\)s′ \(\leq\)s∗and s′ −2 ≡0 mod 3; ou (E.b) i∗é capaz de coletar ou gerar pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,s′−1 j ) para o mesmo s′, com 6 \(\leq\)s′ \(\leq\)s∗e s′ −2 ≡1 mod 3. Porque as mensagens honestas (r, s′ −1) são recebidas por todos os verificadores honestos (r, s′) antes de terminam de esperar na Etapa s′, e porque o Adversário recebe tudo o mais tardar no usuários honestos, sem perda de generalidade temos s′ = s∗e o jogador i∗é malicioso. Observe que não exigimos que o valor v em E.a fosse o hash de um bloco válido: como ficará claro na análise, v = H(Br \(\ell\)) neste subevento. Abaixo analisamos primeiro o Caso 2 após o evento E, e depois mostramos que o valor de s∗é essencialmente distribuído de acordo com Lr (portanto, o evento E acontece antes da Etapa m + 3 com esmagadora probabilidade, dadas as relações dos parâmetros). Para começar, para qualquer etapa 5 \(\leq\)s < s∗, todo verificador honesto i \(\in\)HSV r,s esperou o tempo ts e definiu vi como o voto majoritário do mensagens válidas (r, s−1) que ele recebeu. Como o jogador i recebeu todas as mensagens honestas (r, s−1) seguindo o Lema 5.5, uma vez que todos os verificadores honestos em HSV r,4 assinaram H(Br \(\ell\)) seguinte caso 2 do GC, e já que |HSV r,s−1| > 2|MSV r,s−1| para cada s, por indução temos aquele jogador i definiu vi = H(Br \(\ell\)). O mesmo vale para todo verificador honesto i \(\in\)HSV r,s∗que não para sem propagar qualquer coisa. Agora consideramos a Etapa s∗ e distinguimos quatro subcasos. Caso 2.1.a. O evento E.a acontece e existe um verificador honesto i′ \(\in\)HSV r,s∗que deveria também pare sem propagar nada. Neste caso, temos s∗−2 ≡0 mod 3 e o passo s∗ é um passo Coin-Fixed-To-0. Por definição, o jogador i′ recebeu pelo menos tH mensagens válidas (r, s∗−1) da forma (ESIGj(0), ESIGj(v), \(\sigma\)r,s∗−1 j ). Como todos os verificadores em HSV r,s∗−1 assinaram H(Br \(\ell\)) e |MSV r,s∗−1| <tH, temos v = H(Br \(\ell\)). Como pelo menos tH −|MSV r,s∗−1| \(\geq\)1 das (r, s∗−1)-mensagens recebidas por i′ para 0 e v são enviados por verificadores em HSV r,s∗−1 após o tempo T r +ts∗−1 \(\geq\)T r +t4 \(\geq\)T r +\(\lambda\)+Λ \(\geq\) \(\beta\)r,1 \(\ell\) +Λ, jogador i′ recebeu mr,1 \(\ell\) no momento em que ele recebe essas mensagens (r, s∗−1). Assim jogador i′ para sem propagar nada; define Br = Br \(\ell\); e define seu próprio CERT r para ser o conjunto de mensagens (r, s∗−1) válidas para 0 e v que ele recebeu. A seguir, mostramos que qualquer outro verificador i \(\in\)HSV r,s∗ parou com Br = Br \(\ell\), ou definiu bi = 0 e propagou (ESIGi(0), ESIGi(H(Br \(\ell\))), \(\sigma\)r,s eu). Na verdade, porque Step s∗ é a primeira vez que algum verificador deve parar sem propagar nada, não há existe uma etapa s′ < s∗com s′ −2 ≡1 mod 3 tal que tH (r, s′ −1)-verificadores assinaram 1. Conseqüentemente, nenhum verificador em HSV r,s∗para com Br = Br ǫ.Além disso, como todos os verificadores honestos nas etapas {4, 5, . . . , s∗−1} assinaram H(Br \(\ell\)), existe não existe uma etapa s′ \(\leq\)s∗com s′ −2 ≡0 mod 3 tal que tH (r, s′ −1)-verificadores assinaram algum v′′ ̸= H(Br \(\ell\)) —de fato, |MSV r,s′−1| < tH. Conseqüentemente, nenhum verificador em HSV r,s∗stops com Br̸= Br ǫ e Br̸= Br \(\ell\). Isto é, se um jogador i \(\in\)HSV r,s∗ parou sem propagando qualquer coisa, ele deve ter definido Br = Br \(\ell\). Se um jogador i \(\in\)HSV r,s∗ esperou o tempo ts∗ e propagou uma mensagem no momento \(\beta\)r,s∗ eu = \(\alpha\)r,s∗ eu + ts∗, ele recebeu todas as mensagens do HSV r,s∗−1, incluindo pelo menos tH −|MSV r,s∗−1| deles para 0 e v. Se eu obtive uma maioria > 2/3 para 1, então ele viu mais de 2(tH −|MSV r,s∗−1|) mensagens (r, s∗−1) válidas para 1, com mais que 2tH −3|MSV r,s∗−1| deles de verificadores (r, s∗−1) honestos. No entanto, isso implica |HSV r,s∗−1| \(\geq\)tH−|MSV r,s∗−1|+2tH−3|MSV r,s∗−1| > 2n−4|MSV r,s∗−1|, contradizendo o fato de que |HSV r,s∗−1| + 4|MSV r,s∗−1| < 2n, que vem dos relacionamentos para os parâmetros. Assim, não vejo > 2/3 maioria para 1, e ele define bi = 0 porque a etapa s∗ é uma etapa com moeda fixada em 0. Como temos visto, vi = H(Br \(\ell\)). Assim i se propaga (ESIGi(0), ESIGi(H(Br \(\ell\))), \(\sigma\)r,s i) como queríamos mostrar. Para a Etapa s∗+ 1, já que o jogador i′ ajudou a propagar as mensagens em seu CERT r no ou antes do tempo \(\alpha\)r,s∗ eu' + ts∗, todos os verificadores honestos em HSV r,s∗+1 receberam pelo menos mensagens válidas (r, s∗−1) para o bit 0 e valor H(Br \(\ell\)) antes ou antes de terminarem esperando. Além disso, os verificadores em HSV r,s∗+1 não irão parar antes de receber aqueles (r, s∗−1)- mensagens, porque não existem outras tH mensagens válidas (r, s′ −1) para o bit 1 com s′ −2 ≡1 mod 3 e 6 \(\leq\)s′ \(\leq\)s∗+ 1, pela definição do Passo s∗. Em particular, Passo s∗+ 1 em si é uma etapa Coin-Fixed-To-1, mas nenhum verificador honesto em HSV r,s∗ propagou uma mensagem para 1 e |MSV r,s∗| < tH. Assim, todos os verificadores honestos em HSV r,s∗+1 param sem propagar nada e definem Br = irmão \(\ell\): como antes, eles receberam mr,1 \(\ell\) antes de receberem as mensagens (r, s∗−1) desejadas.20 O mesmo pode ser dito de todos os verificadores honestos em etapas futuras e de todos os usuários honestos em geral. Em particular, todos eles sabem Br = Br \(\ell\)dentro do intervalo de tempo Ir+1 e T r+1 \(\leq\) \(\alpha\)r,s∗ eu' + ts∗\(\leq\)T r + \(\lambda\) + ts∗. Caso 2.1.b. O evento E.b acontece e existe um verificador honesto i′ \(\in\)HSV r,s∗que deveria também pare sem propagar nada. Neste caso, temos s∗−2 ≡1 mod 3 e o passo s∗ é um passo Coin-Fixed-To-1. A análise é semelhante ao Caso 2.1.a e muitos detalhes foram omitidos. 20Se \(\ell\) for malicioso, ele poderá enviar mr,1 \(\ell\) tarde, esperando que alguns usuários/verificadores honestos não tenham recebido mr,1 \(\ell\) ainda quando receberem o certificado desejado por isso. No entanto, como o verificador ˆi \(\in\)HSV r,4 definiu bˆi = 0 e vˆi = H(Br \(\ell\)), como antes de termos que mais da metade dos verificadores honestos i \(\in\)HSV r,3 definiram vi = H(Br \(\ell\)). Isto implica ainda mais mais da metade dos verificadores honestos i \(\in\)HSV r,2 definiram vi = H(Br \(\ell\)), e todos os verificadores (r, 2) receberam mr,1 \(\ell\). Como o O adversário não consegue distinguir um verificador de um não-verificador, ele não pode visar a propagação de mr,1 \(\ell\) para (r, 2)-verificadores sem que os não-verificadores o vejam. Na verdade, com alta probabilidade, mais da metade (ou uma boa fração constante) de todos os usuários honestos viram mr,1 \(\ell\) depois de esperar por t2 desde o início de sua própria rodada r. A partir daqui, o tempo \(\lambda\)′ necessário para mr,1 \(\ell\) alcançar os usuários honestos restantes é muito menor que Λ e, para simplificar, não escreva na análise. Se 4\(\lambda\) \(\geq\) \(\lambda\)′ então a análise prossegue sem qualquer alteração: ao final da Etapa 4, todos usuários honestos teriam recebido mr,1 \(\ell\). Se o tamanho do bloco se tornar enorme e 4\(\lambda\) < \(\lambda\)′, então nas Etapas 3 e 4, o protocolo poderia pedir a cada verificador que esperasse por \(\lambda\)′/2 em vez de 2\(\lambda\), e a análise continua válida.Como antes, o jogador i′ deve ter recebido pelo menos tH mensagens válidas (r, s∗−1) da forma (ESIGj(1), ESIGj(vj), \(\sigma\)r,s∗−1 j ). Novamente pela definição de s∗, não existe um passo 5 \(\leq\)s′ < s∗com s′ −2 ≡0 mod 3, onde pelo menos tH (r, s′ −1)-verificadores assinaram 0 e o mesmo v. Assim o jogador i′ para sem propagar nada; define Br = Br ǫ; e conjuntos seu próprio CERT r seja o conjunto de mensagens (r, s∗−1) válidas para o bit 1 que ele recebeu. Além disso, qualquer outro verificador i \(\in\)HSV r,s∗ parou com Br = Br ǫ , ou definiu bi = 1 e propagado (ESIGi(1), ESIGi(vi), \(\sigma\)r,s∗ eu ). Já que o jogador i′ ajudou a propagar as mensagens (r, s∗−1) em seu CERT r no tempo \(\alpha\)r,s∗ eu' + ts∗, novamente todos os verificadores honestos em HSV r,s∗+1 para sem propagar nada e define Br = Br ǫ . Da mesma forma, todos os honestos os usuários sabem Br = Br ǫ dentro do intervalo de tempo Ir+1 e T r+1 \(\leq\) \(\alpha\)r,s∗ eu' + ts∗\(\leq\)T r + \(\lambda\) + ts∗. Caso 2.2.a. O evento E.a acontece e não existe um verificador honesto i′ \(\in\)HSV r,s∗quem também deve parar sem propagar nada. Neste caso, observe que o jogador i∗ poderia ter um CERT válido r i∗consistindo no tH desejado (r, s∗−1)-mensagens que o Adversário é capaz de coletar ou gerar. No entanto, o malicioso verificadores podem não ajudar a propagar essas mensagens, por isso não podemos concluir que o honesto os usuários os receberão no tempo \(\lambda\). Na verdade, |MSV r,s∗−1| dessas mensagens podem ser de verificadores (r, s∗−1) maliciosos, que não propagaram suas mensagens e apenas enviaram para os verificadores maliciosos na etapa s∗. Semelhante ao Caso 2.1.a, aqui temos s∗−2 ≡0 mod 3, a etapa s∗ é uma etapa com moeda fixada em 0, e as mensagens (r, s∗−1) no CERT r i∗são para o bit 0 e v = H(Br \(\ell\)). Na verdade, todos honestos (r, s∗−1)-verificadores assinam v, portanto o Adversário não pode gerar as mensagens (r, s∗−1) válidas para um v′ diferente. Além disso, todos os verificadores (r, s∗) honestos esperaram o tempo ts∗ e não veem > 2/3 da maioria para o bit 1, novamente porque |HSV r,s∗−1| + 4|MSV r,s∗−1| <2n. Assim, todo verificador honesto i \(\in\)HSV r,s∗conjuntos bi = 0, vi = H(Br \(\ell\)) pela maioria dos votos e propaga mr,s∗ eu = (ESIGi(0), ESIGi(H(Br \(\ell\))), \(\sigma\)r,s∗ eu ) no tempo \(\alpha\)r,s∗ eu + ts∗. Agora considere os verificadores honestos na Etapa s∗+ 1 (que é uma etapa de Moeda Fixada em 1). Se o O adversário realmente envia as mensagens no CERT r i∗para alguns deles e faz com que eles pare, então semelhante ao Caso 2.1.a, todos os usuários honestos sabem Br = Br \(\ell\)dentro do intervalo de tempo Ir+1 e T r+1 \(\leq\)T r + \(\lambda\) + ts∗+1. Caso contrário, todos os verificadores honestos na Etapa s∗+1 receberam todas as mensagens (r, s∗) para 0 e H(Br \(\ell\)) do HSV r,s∗após o tempo de espera ts∗+1, o que leva a > 2/3 da maioria, porque |HSV r,s∗| > 2|MSV r,s∗|. Assim, todos os verificadores em HSV r,s∗+1 propagam suas mensagens para 0 e H(Br \(\ell\)) em conformidade. Observe que os verificadores em HSV r,s∗+1 não param em Br = Br \(\ell\), porque a etapa s∗+ 1 não é uma etapa com moeda fixada em 0. Agora considere os verificadores honestos na Etapa s∗+2 (que é uma etapa de Inversão Genuína da Moeda). Se o Adversário enviar as mensagens em CERT r i∗para alguns deles e faz com que parem, então, novamente, todos os usuários honestos sabem Br = Br \(\ell\)dentro do intervalo de tempo Ir+1 e T r+1 \(\leq\)T r + \(\lambda\) + ts∗+2.Caso contrário, todos os verificadores honestos na Etapa s∗+ 2 receberam todas as mensagens (r, s∗+ 1) para 0 e H(Br \(\ell\)) do HSV r,s∗+1 após o tempo de espera ts∗+2, o que leva a uma maioria > 2/3. Assim todos eles propagam suas mensagens para 0 e H(Br \(\ell\)) respectivamente: é isso que eles fazem não “jogue uma moeda” neste caso. Novamente, observe que eles não param sem se propagar, porque a etapa s∗+ 2 não é uma etapa com moeda fixada em 0. Finalmente, para os verificadores honestos na Etapa s∗+3 (que é outra etapa de Moeda Fixada em 0), todos deles teriam recebido pelo menos tH mensagens válidas para 0 e H(Br \(\ell\)) de HSV s∗+2, se eles realmente esperarem o tempo ts∗+3. Assim, quer o Adversário envie ou não as mensagens no CERT r i∗para qualquer um deles, todos os verificadores em HSV r,s∗+3 param com Br = Br \(\ell\), sem propagar qualquer coisa. Dependendo de como o Adversário age, alguns deles podem ter seu próprio CERT r consistindo naquelas (r, s∗−1)-mensagens em CERT r i∗, e os outros têm seu próprio CERT r consistindo nessas mensagens (r, s∗+ 2). De qualquer forma, todos os usuários honestos saiba Br = Br \(\ell\)dentro do intervalo de tempo Ir+1 e T r+1 \(\leq\)T r + \(\lambda\) + ts∗+3. Caso 2.2.b. O evento E.b acontece e não existe um verificador honesto i′ \(\in\)HSV r,s∗quem também deve parar sem propagar nada. A análise neste caso é semelhante àquelas no Caso 2.1.b e Caso 2.2.a, portanto muitos detalhes foram omitidos. Em particular, CERT r i∗consiste nas tH mensagens desejadas (r, s∗−1) para o bit 1 que o Adversário é capaz de coletar ou gerar, s∗−2 ≡1 mod 3, Etapa s∗é um Etapa Coin-Fixed-To-1, e nenhum verificador (r, s∗) honesto poderia ter visto > 2/3 de maioria para 0. Assim, todo verificador i \(\in\)HSV r,s∗define bi = 1 e propaga mr,s∗ eu = (ESIGi(1), ESIGi(vi), \(\sigma\)r,s∗ eu ) no tempo \(\alpha\)r,s∗ eu + ts∗. Semelhante ao Caso 2.2.a, em no máximo mais 3 etapas (ou seja, o protocolo atinge a Etapa s∗+3, que é outra etapa Coin-Fixed-To-1), todos os usuários honestos sabem Br = Br ǫ dentro do intervalo de tempo Ir+1. Além disso, T r+1 pode ser \(\leq\)T r+\(\lambda\)+ts∗+1, ou \(\leq\)T r+\(\lambda\)+ts∗+2, ou \(\leq\)T r + \(\lambda\) + ts∗+3, dependendo de quando é a primeira vez que um verificador honesto é capaz de parar sem propagação. Combinando os quatro subcasos, temos que todos os usuários honestos conhecem Br dentro do intervalo de tempo Ir+1, com T r+1 \(\leq\)T r + \(\lambda\) + ts∗ nos casos 2.1.a e 2.1.b, e T r+1 \(\leq\)T r + \(\lambda\) + ts∗+3 nos Casos 2.2.a e 2.2.b. Resta limitar s∗ e, portanto, T r+1 para o Caso 2, e fazemos isso considerando como muitas vezes as etapas Coin-Genuinely-Flipped são realmente executadas no protocolo: isto é, alguns verificadores honestos realmente jogaram uma moeda ao ar. Em particular, corrija arbitrariamente uma etapa s′ de moeda genuinamente invertida (ou seja, 7 \(\leq\)s′ \(\leq\)m + 2 e s′ −2 ≡2 mod 3), e seja \(\ell\)′ \(\triangleq\)arg minj\(\in\)SV r,s′−1 H(\(\sigma\)r,s′−1 j ). Por enquanto vamos assumir s′ < s∗, porque de outra forma nenhum verificador honesto realmente joga uma moeda na Etapa s′, de acordo com discussões. Pela definição de SV r,s′−1, o valor hash da credencial de \(\ell\)′ também é o menor entre todos os usuários em PKr-k. Como a função hash é uma oracle aleatória, idealmente o jogador \(\ell\)′ é honesto com probabilidade pelo menos h. Como mostraremos mais tarde, mesmo que o Adversário tente ao máximo prever o saída do aleatório oracle e inclina a probabilidade, o jogador \(\ell\) ′ ainda é honesto com a probabilidadepelo menos ph = h2(1 + h −h2). Abaixo consideramos o caso em que isso realmente acontece: isto é, \(\ell\)′ \(\in\)HSV r,s′−1. Observe que todo verificador honesto i \(\in\)HSV r,s′ recebeu todas as mensagens do HSV r,s′−1 por tempo \(\alpha\)r,s′ eu +ts′. Se o jogador i precisar jogar uma moeda (ou seja, ele não obteve > 2/3 da maioria por o mesmo bit b \(\in\){0, 1}), então ele define bi = lsb(H(\(\sigma\)r,s′−1 \(\ell\)′ )). Se existir outro honesto verificador i′ \(\in\)HSV r,s′ que viu > 2/3 maioria para um bit b \(\in\){0, 1}, então por Propriedade (d) do Lema 5.5, nenhum verificador honesto em HSV r,s′ teria visto > 2/3 de maioria por um tempo b′̸=b. Como lsb(H(\(\sigma\)r,s′−1 \(\ell\)′ )) = b com probabilidade 1/2, todos os verificadores honestos em HSV r,s′ alcançam um acordo sobre b com probabilidade 1/2. É claro que, se tal verificador i′ não existir, então todos verificadores honestos em HSV r,s′ concordam com o bit lsb(H(\(\sigma\)r,s′−1 \(\ell\)′ )) com probabilidade 1. Combinando a probabilidade para \(\ell\)′ \(\in\)HSV r,s′−1, temos que os verificadores honestos em HSV r,s′ chegar a um acordo sobre um bit b \(\in\){0, 1} com probabilidade pelo menos ph 2 = h2(1+h−h2) 2 . Além disso, por indução na votação majoritária como antes, todos os verificadores honestos em HSV r,s′ têm seus vi definidos ser H(Br \(\ell\)). Assim, uma vez alcançado um acordo sobre b na Etapa s′, T r+1 é ou \(\leq\)T r + \(\lambda\) + ts′+1 ou \(\leq\)T r + \(\lambda\) + ts′+2, dependendo se b = 0 ou b = 1, seguindo a análise dos Casos 2.1.a e 2.1.b. Em particular, nenhuma etapa adicional de Coin-Genuinely-Flipped será executada: isto é, os verificadores em tais passos ainda verificam se eles são os verificadores e, portanto, esperam, mas todos irão parar sem propagar qualquer coisa. Assim, antes do Passo s∗, o número de vezes que os passos Coin-GenuinelyFlipped são executados é distribuído de acordo com a variável aleatória Lr. Deixando o Passo s′ ser a última etapa de Coin-Genuinely-Flipped de acordo com Lr, pela construção do protocolo nós temos s′ = 4 + 3Lr. Quando o Adversário deve fazer o Step s∗ acontecer se ele quiser atrasar T r+1 tanto quanto possível? Podemos até assumir que o Adversário conhece antecipadamente a realização de Lr. Se s∗> s′ então é inútil, porque os verificadores honestos já chegaram a um acordo em Passo s′. Com certeza, neste caso s∗seria s′ +1 ou s′ +2, novamente dependendo se b = 0 ou b = 1. No entanto, na verdade estes são os Casos 2.1.a e 2.1.b, e o T r+1 resultante é exatamente o o mesmo que nesse caso. Mais precisamente, T r+1 \(\leq\)T r + \(\lambda\) + ts∗\(\leq\)T r + \(\lambda\) + ts′+2. Se s∗< s′ −3 —isto é, s∗está antes da penúltima etapa de lançamento genuíno da moeda— então por a análise dos Casos 2.2.a e 2.2.b, T r+1 \(\leq\)T r + \(\lambda\) + ts∗+3 < T r + \(\lambda\) + ts′. Ou seja, o Adversário está na verdade fazendo com que o acordo sobre o Br aconteça de forma mais rápida. Se s∗= s′ −2 ou s′ −1 - isto é, a etapa Coin-Fixed-To-0 ou a etapa Coin-Fixed-To-1 imediatamente antes da Etapa s' - então, pela análise dos quatro subcasos, os verificadores honestos em A etapa s′ não consegue mais lançar moedas, porque elas pararam sem se propagar, ou viram maioria > 2/3 para o mesmo bit b. Portanto temos T r+1 \(\leq\)T r + \(\lambda\) + ts∗+3 \(\leq\)T r + \(\lambda\) + ts′+2.Em suma, não importa qual seja s∗, temos T r+1 \(\leq\)T r + \(\lambda\) + ts′+2 = T r + \(\lambda\) + t3Lr+6 = T r + \(\lambda\) + (2(3Lr + 6) −3)\(\lambda\) + Λ = T r + (6Lr + 10)\(\lambda\) + Λ, como queríamos mostrar. O pior caso é quando s∗= s′ −1 e o Caso 2.2.b acontece. Combinando os Casos 1 e 2 do protocolo BA binário, o Lema 5.3 é válido. ■ 5.9 Segurança do Qr Semente e Probabilidade de um Líder Honesto Resta provar o Lema 5.4. Lembre-se de que os verificadores na rodada r são retirados de PKr−k e são escolhidos de acordo com a quantidade Qr−1. A razão para introduzir o parâmetro lookback k é garantir que, na rodada r −k, quando o Adversário for capaz de adicionar novos usuários mal-intencionados para PKr−k, ele não pode prever a quantidade Qr−1 exceto com probabilidade desprezível. Observe que o A função hash é uma oracle aleatória e Qr−1 é uma de suas entradas ao selecionar verificadores para a rodada r. Assim, não importa quão usuários mal-intencionados sejam adicionados ao PKr-k, do ponto de vista do Adversário, cada um deles ainda é selecionado para ser um verificador em uma etapa de rodada r com a probabilidade necessária p (ou p1 para a Etapa 1). Mais precisamente, temos o seguinte lema. Lema 5.6. Com k = O(log1/2 F), para cada rodada r, com probabilidade esmagadora o Adversário não consultou Qr−1 para o oracle aleatório na rodada r −k. Prova. Procedemos por indução. Suponha que para cada rodada \(\gamma\) < r, o Adversário não questionou Q\(\gamma\)−1 ao aleatório oracle na rodada \(\gamma\) −k.21 Considere o seguinte jogo mental jogado por o Adversário na rodada r −k, tentando prever Qr−1. Na Etapa 1 de cada rodada \(\gamma\) = r −k,. . . , r −1, dado um Q\(\gamma\)−1 específico não consultado ao aleatório oracle, ordenando os jogadores i \(\in\)PK\(\gamma\)−k de acordo com os valores hash H(SIGi(\(\gamma\), 1, Q\(\gamma\)−1)) cada vez mais, obtemos uma permutação aleatória sobre PK\(\gamma\)−k. Por definição, o líder \(\ell\) \(\gamma\) é o primeiro usuário na permutação e é honesto com probabilidade h. Além disso, quando PK\(\gamma\)−k é grande suficiente, para qualquer número inteiro x \(\geq\)1, a probabilidade de que os primeiros x usuários na permutação sejam todos malicioso, mas o (x + 1)st é honesto é (1 −h)xh. Se \(\ell\) \(\gamma\) for honesto, então Q\(\gamma\) = H(SIG\(\ell\) \(\gamma\)(Q\(\gamma\)−1), \(\gamma\)). Como o Adversário não pode falsificar a assinatura de \(\ell\) \(\gamma\), Q\(\gamma\) é distribuído uniformemente aleatoriamente do ponto de vista do Adversário e, exceto com probabilidade exponencialmente pequena,22 não foi questionado para H na rodada r −k. Desde cada Q\(\gamma\)+1, Q\(\gamma\)+2, . . . , Qr−1 respectivamente é a saída de H com Q\(\gamma\), Q\(\gamma\)+1, . . . , Qr−2 como uma das entradas, todos eles parecem aleatórios para o Adversário e o Adversário não poderia ter consultado Qr−1 para H em rodada r −k. Conseqüentemente, o único caso em que o Adversário pode prever Qr−1 com boa probabilidade na rodada r−k é quando todos os líderes \(\ell\)r−k,. . . , \(\ell\)r−1 são maliciosos. Considere novamente uma rodada \(\gamma\) \(\in\){r−k . . . , r−1} e a permutação aleatória sobre PK\(\gamma\)−k induzida pelos valores hash correspondentes. Se para alguns x \(\geq\)2, os primeiros x −1 usuários na permutação são todos maliciosos e o x-ésimo é honesto, então o O adversário tem x escolhas possíveis para Q\(\gamma\): qualquer uma da forma H(SIGi(Q\(\gamma\)−1, \(\gamma\))), onde i é um dos 21Como k é um número inteiro pequeno, sem perda de generalidade pode-se assumir que as primeiras k rodadas do protocolo são executadas sob um ambiente seguro e a hipótese indutiva é válida para essas rodadas. 22Isto é, exponencial no comprimento da saída de H. Observe que esta probabilidade é bem menor que F.os primeiros x-1 usuários mal-intencionados, ao tornar o jogador i o verdadeiro líder da rodada \(\gamma\); ou H(Q\(\gamma\)−1, \(\gamma\)), por forçando B\(\gamma\) = B\(\gamma\) ǫ . Caso contrário, o líder da rodada \(\gamma\) será o primeiro usuário honesto na permutação e Qr−1 torna-se imprevisível para o Adversário. Qual das x opções de Q\(\gamma\) acima o Adversário deve seguir? Para ajudar o adversário responder a esta pergunta, no jogo mental nós realmente o tornamos mais poderoso do que ele realmente é, como segue. Em primeiro lugar, na realidade, o Adversário não pode calcular o hash do valor de um usuário honesto. assinatura, portanto não pode decidir, para cada Q\(\gamma\), o número x(Q\(\gamma\)) de usuários mal-intencionados no início da permutação aleatória na rodada \(\gamma\) + 1 induzida por Q\(\gamma\). No jogo mental, damos a ele o números x(Q\(\gamma\)) gratuitamente. Em segundo lugar, na realidade, ter os primeiros x usuários na permutação, todos ser malicioso não significa necessariamente que todos possam ser transformados em líderes, porque o hash os valores de suas assinaturas também devem ser menores que p1. Ignoramos essa restrição na mente jogo, dando ao Adversário ainda mais vantagens. É fácil perceber que no jogo mental a opção ótima para o Adversário, denotada por ˆQ\(\gamma\), é aquele que produz a maior sequência de usuários maliciosos no início do aleatório permutação na rodada \(\gamma\) + 1. Na verdade, dado um Q\(\gamma\) específico, o protocolo não depende de Q\(\gamma\)−1 mais e o Adversário pode focar apenas na nova permutação na rodada \(\gamma\) + 1, que tem o mesma distribuição para o número de usuários mal-intencionados no início. Assim, em cada rodada \(\gamma\), o ˆQ\(\gamma\) mencionado acima dá a ele o maior número de opções para Q\(\gamma\)+1 e, portanto, maximiza a probabilidade de que os líderes consecutivos sejam todos maliciosos. Portanto, no jogo mental o Adversário segue uma Cadeia de Markov da rodada r −k para arredondar r −1, com o espaço de estados sendo {0} \(\cup\){x : x \(\geq\)2}. O estado 0 representa o fato de que o o primeiro usuário na permutação aleatória na rodada atual \(\gamma\) é honesto, portanto o Adversário falha no jogo para previsão de Qr−1; e cada estado x \(\geq\)2 representa o fato de que os primeiros x −1 usuários no permutações são maliciosas e o x-ésimo é honesto, portanto o Adversário tem x opções para Q\(\gamma\). O as probabilidades de transição P(x, y) são as seguintes. • P(0, 0) = 1 e P(0, y) = 0 para qualquer y \(\geq\)2. Ou seja, o Adversário falha no jogo assim que o primeiro o usuário na permutação torna-se honesto. • P(x, 0) = hx para qualquer x \(\geq\)2. Ou seja, com probabilidade hx, todas as x permutações aleatórias têm seus primeiros usuários são honestos, portanto o Adversário falha no jogo na próxima rodada. • Para qualquer x \(\geq\)2 e y \(\geq\)2, P(x, y) é a probabilidade de que, entre as x permutações aleatórias induzida pelas x opções de Q\(\gamma\), a sequência mais longa de usuários mal-intencionados no início de alguns deles são y −1, portanto o Adversário tem y opções para Q\(\gamma\)+1 na próxima rodada. Isto é, P(x, y) = y−1 X eu=0 (1 −h)ih !x - y−2 X eu=0 (1 −h)ih !x = (1 −(1 −h)y)x −(1 −(1 −h)y−1)x. Observe que o estado 0 é o único estado absorvente na matriz de transição P, e todos os outros estados x tem uma probabilidade positiva de ir para 0. Estamos interessados em limitar superiormente o número k de rodadas necessárias para a Cadeia de Markov convergir para 0 com probabilidade esmagadora: isto é, não Não importa em que estado a cadeia comece, com uma probabilidade esmagadora de que o Adversário perca o jogo e falha em prever Qr−1 na rodada r −k. Considere a matriz de transição P (2) \(\triangleq\)P \(\cdot\) P após duas rodadas. É fácil ver que P (2) (0, 0) = 1 e P (2)(0, x) = 0 para qualquer x \(\geq\)2. Para qualquer x \(\geq\)2 e y \(\geq\)2, como P(0, y) = 0, temos P(2)(x, y) = P(x, 0)P(0, y) + X z\(\geq\)2 P(x, z)P(z, y) = X z\(\geq\)2 P(x, z)P(z, y).Deixando ¯h \(\triangleq\)1 −h, temos P(x, y) = (1 −¯hy)x −(1 −¯hy−1)x e P(2)(x,y) = X z\(\geq\)2 [(1 −¯hz)x −(1 −¯hz−1)x][(1 −¯hy)z −(1 −¯hy−1)z]. Abaixo calculamos o limite de P (2)(x,y) P(x,y) à medida que h vai para 1 - isto é, ¯h vai para 0. Observe que o maior a ordem de ¯h em P(x, y) é ¯hy−1, com coeficiente x. Assim, limão h \(\to\) 1 P(2)(x,y) P(x, y) =lim ¯h \(\to\) 0 P(2)(x,y) P(x, y) =lim ¯h \(\to\) 0 P(2)(x,y) x¯hy−1 + O(¯hy) = limão ¯h \(\to\) 0 P z\(\geq\)2[x¯hz−1 + O(¯hz)][z¯hy−1 + O(¯hy)] x¯hy−1 + O(¯hy) =lim ¯h \(\to\) 0 2x¯hy + O(¯hy+1) x¯hy−1 + O(¯hy) = limão ¯h \(\to\) 0 2x¯h x¯hy−1 = lim ¯h \(\to\) 0 2¯h = 0. Quando h está suficientemente próximo de 1,23, temos P(2)(x,y) P(x, y) \(\leq\)1 2 para qualquer x \(\geq\)2 e y \(\geq\)2. Por indução, para qualquer k > 2, P (k) \(\triangleq\)P k é tal que • P (k)(0, 0) = 1, P (k)(0, x) = 0 para qualquer x \(\geq\)2, e • para qualquer x \(\geq\)2 e y \(\geq\)2, P(k)(x, y) = P(k−1)(x, 0)P(0, y) + X z\(\geq\)2 P(k−1)(x, z)P(z, y) = X z\(\geq\)2 P(k−1)(x, z)P(z, y) \(\leq\) X z\(\geq\)2 P(x,z) 2k−2 \(\cdot\) P(z, y) = P(2)(x, y) 2k−2 \(\leq\)P(x, y) 2k−1. Como P(x, y) \(\leq\)1, após 1−log2 F rodadas, a probabilidade de transição para qualquer estado y \(\geq\)2 é insignificante, começando com qualquer estado x \(\geq\)2. Embora existam muitos desses estados, é fácil ver que limão y→+∞ P(x, y) P(x, y + 1) = limão y→+∞ (1 −¯hy)x −(1 −¯hy−1)x (1 −¯hy+1)x −(1 −¯hy)x = limão y→+∞ ¯hy−1 −¯hy ¯hy −¯hy+1 = 1 ¯h = 1 1-h. Portanto, cada linha x da matriz de transição P diminui como uma sequência geométrica com taxa 1 1-h > 2 quando y é grande o suficiente, e o mesmo vale para P (k). Assim, quando k é grande o suficiente, mas ainda assim na ordem de log1/2 F, P y\(\geq\)2 P (k)(x, y) < F para qualquer x \(\geq\)2. Ou seja, com uma probabilidade esmagadora o Adversário perde o jogo e não consegue prever Qr−1 na rodada r −k. Para h \(\in\)(2/3, 1], mais análise complexa mostra que existe uma constante C ligeiramente maior que 1/2, tal que é suficiente tomar k = O(logC F). Assim, o Lema 5.6 é válido. ■ Lema 5.4. (reapresentado) Dadas as propriedades 1–3 para cada rodada antes de r, ph = h2(1 + h −h2) para Lr, e o líder \(\ell\)r é honesto com probabilidade de pelo menos ph. 23Por exemplo, h = 80% conforme sugerido pelas escolhas específicas de parâmetros.

Prova. Seguindo o Lema 5.6, o Adversário não pode prever Qr−1 na rodada r −k, exceto com probabilidade desprezível. Observe que isso não significa que a probabilidade de um líder honesto seja h para cada rodada. Na verdade, dado o Qr-1, dependendo de quantos usuários mal-intencionados existem no início do a permutação aleatória de PKr−k, o Adversário pode ter mais de uma opção para Qr e portanto, pode aumentar a probabilidade de um líder malicioso na rodada r + 1 - mais uma vez estamos dando a ele algumas vantagens irrealistas como no Lema 5.6, de modo a simplificar a análise. No entanto, para cada Qr−1 que não foi questionado a H pelo Adversário na rodada r −k, por qualquer x \(\geq\)1, com probabilidade (1 −h)x−1h o primeiro usuário honesto ocorre na posição x no resultado permutação aleatória de PKr−k. Quando x = 1, a probabilidade de um líder honesto na rodada r + 1 é na verdade h; enquanto quando x = 2, o Adversário tem duas opções para Qr e a probabilidade resultante é h2. Somente considerando estes dois casos, temos que a probabilidade de um líder honesto na rodada r + 1 é pelo menos h \(\cdot\) h + (1 −h)h \(\cdot\) h2 = h2(1 + h −h2) conforme desejado. Observe que a probabilidade acima considera apenas a aleatoriedade no protocolo da rodada r −k para arredondar r. Quando toda a aleatoriedade da rodada 0 à rodada r é levada em consideração, Qr−1 é ainda menos previsível para o Adversário e a probabilidade de um líder honesto na rodada r + 1 é de pelo menos h2(1 + h −h2). Substituindo r + 1 por r e retrocedendo tudo em uma rodada, o líder \(\ell\)r é honesto com probabilidade de pelo menos h2(1 + h −h2), conforme desejado. Da mesma forma, em cada etapa s de inversão genuína da moeda, o “líder” dessa etapa - que é o verificador em SV r,s cuja credencial tem o menor valor hash, é honesto com probabilidade de pelo menos h2(1 + h-h2). Assim ph = h2(1 + h −h2) para Lr e o Lema 5.4 é válido. ■

Algorand ′

\(\text{Algorand}^\prime\)

2 In this section, we construct a version of \(\text{Algorand}^\prime\) working under the following assumption. Honest Majority of Users Assumption: More than 2/3 of the users in each \(PK^r\) are honest. In Section 8, we show how to replace the above assumption with the desired Honest Majority of Money assumption. 6.1 Additional Notations and Parameters for \(\text{Algorand}^\prime\) 2 Notations • \(\mu \in \mathbb{Z}^+\): a pragmatic upper-bound to the number of steps that, with overwhelming probability, will actually taken in one round. (As we shall see, parameter \(\mu\) controls how many ephemeral keys a user prepares in advance for each round.) • \(L_r\): a random variable representing the number of Bernoulli trials needed to see a 1, when each trial is 1 with probability \(\frac{p_h}{2}\). \(L_r\) will be used to upper-bound the time needed to generate block \(B_r\). • \(t_H\): a lower-bound for the number of honest verifiers in a step \(s > 1\) of round \(r\), such that with overwhelming probability (given \(n\) and \(p\)), there are \(> t_H\) honest verifiers in \(SV^{r,s}\). Parameters • Relationships among various parameters. — For each step \(s > 1\) of round \(r\), \(n\) is chosen so that, with overwhelming probability,

\(|HSV^{r,s}| > t_H\) and \(|HSV^{r,s}| + 2|MSV^{r,s}| < 2t_H\). Note that the two inequalities above together imply \(|HSV^{r,s}| > 2|MSV^{r,s}|\): that is, there is a 2/3 honest majority among selected verifiers. The closer to 1 the value of \(h\) is, the smaller \(n\) needs to be. In particular, we use (variants of) Chernoffbounds to ensure the desired conditions hold with overwhelming probability. • Example choices of important parameters. — \(F = 10^{-18}\). — \(n \approx 4{,}000\), \(t_H \approx 0.69n\), \(k = 70\). 6.2 Implementing Ephemeral Keys in \(\text{Algorand}^\prime\) 2 Recall that a verifier \(i \in SV^{r,s}\) digitally signs his message \(m_i^{r,s}\) of step \(s\) in round \(r\), relative to an ephemeral public key \(pk_i^{r,s}\), using an ephemeral secrete key \(sk_i^{r,s}\) that he promptly destroys after using. When the number of possible steps that a round may take is capped by a given integer \(\mu\), we have already seen how to practically handle ephemeral keys. For example, as we have explained in \(\text{Algorand}'_1\) (where \(\mu = m + 3\)), to handle all his possible ephemeral keys, from a round \(r'\) to a round \(r' + 10^6\), \(i\) generates a pair \((PMK, SMK)\), where \(PMK\) public master key of an identity based signature scheme, and \(SMK\) its corresponding secret master key. User \(i\) publicizes \(PMK\) and uses \(SMK\) to generate the secret key of each possible ephemeral public key (and destroys \(SMK\) after having done so). The set of \(i\)'s ephemeral public keys for the relevant rounds is \(S = \{i\} \times \{r', \ldots, r' + 10^6\} \times \{1, \ldots, \mu\}\). (As discussed, as the round \(r' + 10^6\) approaches, \(i\) "refreshes" his pair \((PMK, SMK)\).) In practice, if \(\mu\) is large enough, a round of \(\text{Algorand}'_2\) will not take more than \(\mu\) steps. In principle, however, there is the remote possibility that, for some round \(r\) the number of steps actually taken will exceed \(\mu\). When this happens, \(i\) would be unable to sign his message \(m_i^{r,s}\) for any step \(s > \mu\), because he has prepared in advance only \(\mu\) secret keys for round \(r\). Moreover, he could not prepare and publicize a new stash of ephemeral keys, as discussed before. In fact, to do so, he would need to insert a new public master key \(PMK'\) in a new block. But, should round \(r\) take more and more steps, no new blocks would be generated. However, solutions exist. For instance, \(i\) may use the last ephemeral key of round \(r\), \(pk_i^{r,\mu}\), as follows. He generates another stash of key-pairs for round \(r\) —e.g., by (1) generating another master key pair \((PMK, SMK)\); (2) using this pair to generate another, say, \(10^6\) ephemeral keys, \(sk_i^{r,\mu+1}, \ldots, sk_i^{r,\mu+10^6}\), corresponding to steps \(\mu+1, \ldots, \mu+10^6\) of round \(r\); (3) using \(sk_i^{r,\mu}\) to digitally sign \(PMK\) (and any \((r, \mu)\)-message if \(i \in SV^{r,\mu}\)), relative to \(pk_i^{r,\mu}\); and (4) erasing \(SMK\) and \(sk_i^{r,\mu}\). Should \(i\) become a verifier in a step \(\mu + s\) with \(s \in \{1, \ldots, 10^6\}\), then \(i\) digitally signs his \((r, \mu + s)\)- message \(m_i^{r,\mu+s}\) relative to his new key \(pk_i^{r,\mu+s} = (i, r, \mu + s)\). Of course, to verify this signature of \(i\), others need to be certain that this public key corresponds to \(i\)'s new public master key \(PMK\). Thus, in addition to this signature, \(i\) transmits his digital signature of \(PMK\) relative to \(pk_i^{r,\mu}\). Of course, this approach can be repeated, as many times as necessary, should round \(r\) continue for more and more steps! The last ephemeral secret key is used to authenticate a new master public key, and thus another stash of ephemeral keys for round \(r\). And so on.

6.3 The Actual Protocol \(\text{Algorand}'_2\) Recall again that, in each step \(s\) of a round \(r\), a verifier \(i \in SV^{r,s}\) uses his long-term public-secret key pair to produce his credential, \(\sigma_i^{r,s} \triangleq \text{SIG}_i(r, s, Q^{r-1})\), as well as \(\text{SIG}_i(Q^{r-1})\) in case \(s = 1\). Verifier \(i\) uses his ephemeral key pair, \((pk_i^{r,s}, sk_i^{r,s})\), to sign any other message \(m\) that may be required. For simplicity, we write \(\text{esig}_i(m)\), rather than \(\text{sig}_{pk_i^{r,s}}(m)\), to denote \(i\)'s proper ephemeral signature of \(m\) in this step, and write \(\text{ESIG}_i(m)\) instead of \(\text{SIG}_{pk_i^{r,s}}(m) \triangleq (i, m, \text{esig}_i(m))\). Step 1: Block Proposal Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 1 of round \(r\) as soon as he has \(\text{CERT}^{r-1}\), which allows \(i\) to unambiguously compute \(H(B^{r-1})\) and \(Q^{r-1}\). • User \(i\) uses \(Q^{r-1}\) to check whether \(i \in SV^{r,1}\) or not. If \(i \notin SV^{r,1}\), he does nothing for Step 1. • If \(i \in SV^{r,1}\), that is, if \(i\) is a potential leader, then he does the following. (a) If \(i\) has seen \(B^0, \ldots, B^{r-1}\) himself (any \(B^j = B^j_\epsilon\) can be easily derived from its hash value in \(\text{CERT}^j\) and is thus assumed "seen"), then he collects the round-\(r\) payments that have been propagated to him so far and computes a maximal payset \(PAY_i^r\) from them. (b) If \(i\) hasn't seen all \(B^0, \ldots, B^{r-1}\) yet, then he sets \(PAY_i^r = \emptyset\). (c) Next, \(i\) computes his "candidate block" \(B_i^r = (r, PAY_i^r, \text{SIG}_i(Q^{r-1}), H(B^{r-1}))\). (c) Finally, \(i\) computes the message \(m_i^{r,1} = (B_i^r, \text{esig}_i(H(B_i^r)), \sigma_i^{r,1})\), destroys his ephemeral secret key \(sk_i^{r,1}\), and then propagates two messages, \(m_i^{r,1}\) and \((\text{SIG}_i(Q^{r-1}), \sigma_i^{r,1})\), separately but simultaneously.a aWhen \(i\) is the leader, \(\text{SIG}_i(Q^{r-1})\) allows others to compute \(Q^r = H(\text{SIG}_i(Q^{r-1}), r)\).

Selective Propagation To shorten the global execution of Step 1 and the whole round, it is important that the \((r, 1)\)- messages are selectively propagated. That is, for every user \(j\) in the system, • For the first \((r, 1)\)-message that he ever receives and successfully verifies,a whether it contains a block or is just a credential and a signature of \(Q^{r-1}\), player \(j\) propagates it as usual. • For all the other \((r, 1)\)-messages that player \(j\) receives and successfully verifies, he propagates it only if the hash value of the credential it contains is the smallest among the hash values of the credentials contained in all \((r, 1)\)-messages he has received and successfully verified so far. • However, if \(j\) receives two different messages of the form \(m_i^{r,1}\) from the same player \(i\),b he discards the second one no matter what the hash value of \(i\)'s credential is. Note that, under selective propagation it is useful that each potential leader \(i\) propagates his credential \(\sigma_i^{r,1}\) separately from \(m_i^{r,1}\):c those small messages travel faster than blocks, ensure timely propagation of the \(m_i^{r,1}\)'s where the contained credentials have small hash values, while make those with large hash values disappear quickly. aThat is, all the signatures are correct and, if it is of the form \(m_i^{r,1}\), both the block and its hash are valid —although \(j\) does not check whether the included payset is maximal for \(i\) or not. bWhich means \(i\) is malicious. cWe thank Georgios Vlachos for suggesting this.

Step 2: The First Step of the Graded Consensus Protocol GC Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 2 of round \(r\) as soon as he has \(\text{CERT}^{r-1}\). • User \(i\) waits a maximum amount of time \(t_2 \triangleq \lambda + \Lambda\). While waiting, \(i\) acts as follows. 1. After waiting for time \(2\lambda\), he finds the user \(\ell\) such that \(H(\sigma_\ell^{r,1}) \leq H(\sigma_j^{r,1})\) for all credentials \(\sigma_j^{r,1}\) that are part of the successfully verified \((r, 1)\)-messages he has received so far.a 2. If he has received a block \(B^{r-1}\), which matches the hash value \(H(B^{r-1})\) contained in \(\text{CERT}^{r-1}\),b and if he has received from \(\ell\) a valid message $m_\ell^{r,1} = (B_\ell^r, \text{esig}\ell(H(B\ell^r)), \sigma_\ell^{r,1})\(,c then \)i\( stops waiting and sets \)v'i \triangleq (H(B\ell^r), \ell)$. 3. Otherwise, when time \(t_2\) runs out, \(i\) sets \(v'_i \triangleq \bot\). 4. When the value of \(v'_i\) has been set, \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,2}\) or not. 5. If \(i \in SV^{r,2}\), \(i\) computes the message \(m_i^{r,2} \triangleq (\text{ESIG}_i(v'_i), \sigma_i^{r,2})\),d destroys his ephemeral secret key \(sk_i^{r,2}\), and then propagates \(m_i^{r,2}\). Otherwise, \(i\) stops without propagating anything. aEssentially, user \(i\) privately decides that the leader of round \(r\) is user \(\ell\). bOf course, if \(\text{CERT}^{r-1}\) indicates that \(B^{r-1} = B^{r-1}_\epsilon\), then \(i\) has already "received" \(B^{r-1}\) the moment he has \(\text{CERT}^{r-1}\). cAgain, player \(\ell\)'s signatures and the hashes are all successfully verified, and \(PAY_\ell^r\) in \(B_\ell^r\) is a valid payset for round \(r\) —although \(i\) does not check whether \(PAY_\ell^r\) is maximal for \(\ell\) or not. If \(B_\ell^r\) contains an empty payset, then there is actually no need for \(i\) to see \(B^{r-1}\) before verifying whether \(B_\ell^r\) is valid or not. dThe message \(m_i^{r,2}\) signals that player \(i\) considers the first component of \(v'_i\) to be the hash of the next block, or considers the next block to be empty.

Step 3: The Second Step of GC Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 3 of round \(r\) as soon as he has \(\text{CERT}^{r-1}\). • User \(i\) waits a maximum amount of time \(t_3 \triangleq t_2 + 2\lambda = 3\lambda + \Lambda\). While waiting, \(i\) acts as follows. 1. If there exists a value \(v\) such that he has received at least \(t_H\) valid messages \(m_j^{r,2}\) of the form \((\text{ESIG}_j(v), \sigma_j^{r,2})\), without any contradiction,a then he stops waiting and sets \(v' = v\). 2. Otherwise, when time \(t_3\) runs out, he sets \(v' = \bot\). 3. When the value of \(v'\) has been set, \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,3}\) or not. 4. If \(i \in SV^{r,3}\), then \(i\) computes the message \(m_i^{r,3} \triangleq (\text{ESIG}_i(v'), \sigma_i^{r,3})\), destroys his ephemeral secret key \(sk_i^{r,3}\), and then propagates \(m_i^{r,3}\). Otherwise, \(i\) stops without propagating anything. aThat is, he has not received two valid messages containing \(\text{ESIG}_j(v)\) and a different \(\text{ESIG}_j(\hat{v})\) respectively, from a player \(j\). Here and from here on, except in the Ending Conditions defined later, whenever an honest player wants messages of a given form, messages contradicting each other are never counted or considered valid.

Step 4: Output of GC and The First Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step 4 of round \(r\) as soon as he finishes his own Step 3. • User \(i\) waits a maximum amount of time \(2\lambda\).a While waiting, \(i\) acts as follows. 1. He computes \(v_i\) and \(g_i\), the output of GC, as follows. (a) If there exists a value \(v' \neq \bot\) such that he has received at least \(t_H\) valid messages \(m_j^{r,3} = (\text{ESIG}_j(v'), \sigma_j^{r,3})\), then he stops waiting and sets \(v_i \triangleq v'\) and \(g_i \triangleq 2\). (b) If he has received at least \(t_H\) valid messages \(m_j^{r,3} = (\text{ESIG}_j(\bot), \sigma_j^{r,3})\), then he stops waiting and sets \(v_i \triangleq \bot\) and \(g_i \triangleq 0\).b (c) Otherwise, when time \(2\lambda\) runs out, if there exists a value \(v' \neq \bot\) such that he has received at least \(\lceil \frac{t_H}{2} \rceil\) valid messages \(m_j^{r,3} = (\text{ESIG}_j(v'), \sigma_j^{r,3})\), then he sets \(v_i \triangleq v'\) and \(g_i \triangleq 1\).c (d) Else, when time \(2\lambda\) runs out, he sets \(v_i \triangleq \bot\) and \(g_i \triangleq 0\). 2. When the values \(v_i\) and \(g_i\) have been set, \(i\) computes \(b_i\), the input of \(\text{BBA}^\star\), as follows: \(b_i \triangleq 0\) if \(g_i = 2\), and \(b_i \triangleq 1\) otherwise. 3. \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,4}\) or not. 4. If \(i \in SV^{r,4}\), he computes the message \(m_i^{r,4} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,4})\), destroys his ephemeral secret key \(sk_i^{r,4}\), and propagates \(m_i^{r,4}\). Otherwise, \(i\) stops without propagating anything. aThus, the maximum total amount of time since \(i\) starts his Step 1 of round \(r\) could be \(t_4 \triangleq t_3 + 2\lambda = 5\lambda + \Lambda\). bWhether Step (b) is in the protocol or not does not affect its correctness. However, the presence of Step (b) allows Step 4 to end in less than \(2\lambda\) time if sufficiently many Step-3 verifiers have "signed \(\bot\)." cIt can be proved that the \(v'\) in this case, if exists, must be unique.

Step \(s\), \(5 \leq s \leq m + 2\), \(s - 2 \equiv 0 \mod 3\): A Coin-Fixed-To-0 Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he finishes his own Step \(s - 1\). • User \(i\) waits a maximum amount of time \(2\lambda\).a While waiting, \(i\) acts as follows. – Ending Condition 0: If at any point there exists a string \(v \neq \bot\) and a step \(s'\) such that (a) \(5 \leq s' \leq s\), \(s' - 2 \equiv 0 \mod 3\) —that is, Step \(s'\) is a Coin-Fixed-To-0 step, (b) \(i\) has received at least \(t_H\) valid messages \(m_j^{r,s'-1} = (\text{ESIG}_j(0), \text{ESIG}_j(v), \sigma_j^{r,s'-1})\),b and (c) \(i\) has received a valid message \((\text{SIG}_j(Q^{r-1}), \sigma_j^{r,1})\) with \(j\) being the second component of \(v\), then, \(i\) stops waiting and ends his own execution of Step \(s\) (and in fact of round \(r\)) right away without propagating anything as a \((r, s)\)-verifier; sets \(H(B^r)\) to be the first component of \(v\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of step (b) together with \((\text{SIG}_j(Q^{r-1}), \sigma_j^{r,1})\).c – Ending Condition 1: If at any point there exists a step \(s'\) such that (a') \(6 \leq s' \leq s\), \(s' - 2 \equiv 1 \mod 3\) —that is, Step \(s'\) is a Coin-Fixed-To-1 step, and (b') \(i\) has received at least \(t_H\) valid messages $m_j^{r,s'-1} = (\text{ESIG}j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s'-1})$,d then, \(i\) stops waiting and ends his own execution of Step \(s\) (and in fact of round \(r\)) right away without propagating anything as a \((r, s)\)-verifier; sets \(B^r = B^r_\epsilon\); and sets his own \(\text{CERT}^r\) to be the set of messages \(m_j^{r,s'-1}\) of sub-step (b'). – If at any point he has received at least \(t_H\) valid \(m_j^{r,s-1}\)'s of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he stops waiting and sets \(b_i \triangleq 1\). – If at any point he has received at least \(t_H\) valid \(m_j^{r,s-1}\)'s of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), but they do not agree on the same \(v\), then he stops waiting and sets \(b_i \triangleq 0\). – Otherwise, when time \(2\lambda\) runs out, \(i\) sets \(b_i \triangleq 0\). – When the value \(b_i\) has been set, \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,s}\). – If \(i \in SV^{r,s}\), \(i\) computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\) with \(v_i\) being the value he has computed in Step 4, destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\). Otherwise, \(i\) stops without propagating anything. aThus, the maximum total amount of time since \(i\) starts his Step 1 of round \(r\) could be $t_s \triangleq t + 2\lambda = (2s - 3)\lambda + \Lambda$. bSuch a message from player \(j\) is counted even if player \(i\) has also received a message from \(j\) signing for 1. Similar things for Ending Condition 1. As shown in the analysis, this is to ensure that all honest users know \(\text{CERT}^r\) within time \(\lambda\) from each other. cUser \(i\) now knows \(H(B^r)\) and his own round \(r\) finishes. He just needs to wait until the actually block \(B^r\) is propagated to him, which may take some additional time. He still helps propagating messages as a generic user, but does not initiate any propagation as a \((r, s)\)-verifier. In particular, he has helped propagating all messages in his \(\text{CERT}^r\), which is enough for our protocol. Note that he should also set \(b_i \triangleq 0\) for the binary BA protocol, but \(b_i\) is not needed in this case anyway. Similar things for all future instructions. dIn this case, it does not matter what the \(v_j\)'s are. 65

Step \(s\), \(6 \leq s \leq m + 2\), \(s - 2 \equiv 1 \mod 3\): A Coin-Fixed-To-1 Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he finishes his own Step \(s - 1\). • User \(i\) waits a maximum amount of time \(2\lambda\). While waiting, \(i\) acts as follows. – Ending Condition 0: The same instructions as in a Coin-Fixed-To-0 step. – Ending Condition 1: The same instructions as in a Coin-Fixed-To-0 step. – If at any point he has received at least \(t_H\) valid \(m_j^{r,s-1}\)'s of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he stops waiting and sets \(b_i \triangleq 0\).a – Otherwise, when time \(2\lambda\) runs out, \(i\) sets \(b_i \triangleq 1\). – When the value \(b_i\) has been set, \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,s}\). – If \(i \in SV^{r,s}\), \(i\) computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\) with \(v_i\) being the value he has computed in Step 4, destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\). Otherwise, \(i\) stops without propagating anything. aNote that receiving \(t_H\) valid \((r, s - 1)\)-messages signing for 1 would mean Ending Condition 1. Step \(s\), \(7 \leq s \leq m + 2\), \(s - 2 \equiv 2 \mod 3\): A Coin-Genuinely-Flipped Step of \(\text{BBA}^\star\) Instructions for every user \(i \in PK^{r-k}\): User \(i\) starts his own Step \(s\) of round \(r\) as soon as he finishes his own step \(s - 1\). • User \(i\) waits a maximum amount of time \(2\lambda\). While waiting, \(i\) acts as follows. – Ending Condition 0: The same instructions as in a Coin-Fixed-To-0 step. – Ending Condition 1: The same instructions as in a Coin-Fixed-To-0 step. – If at any point he has received at least \(t_H\) valid \(m_j^{r,s-1}\)'s of the form \((\text{ESIG}_j(0), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he stops waiting and sets \(b_i \triangleq 0\). – If at any point he has received at least \(t_H\) valid \(m_j^{r,s-1}\)'s of the form \((\text{ESIG}_j(1), \text{ESIG}_j(v_j), \sigma_j^{r,s-1})\), then he stops waiting and sets \(b_i \triangleq 1\). – Otherwise, when time \(2\lambda\) runs out, letting \(SV_i^{r,s-1}\) be the set of \((r, s - 1)\)-verifiers from whom he has received a valid message \(m_j^{r,s-1}\), \(i\) sets \(b_i \triangleq \text{lsb}(\min_{j \in SV_i^{r,s-1}} H(\sigma_j^{r,s-1}))\). – When the value \(b_i\) has been set, \(i\) computes \(Q^{r-1}\) from \(\text{CERT}^{r-1}\) and checks whether \(i \in SV^{r,s}\). – If \(i \in SV^{r,s}\), \(i\) computes the message \(m_i^{r,s} \triangleq (\text{ESIG}_i(b_i), \text{ESIG}_i(v_i), \sigma_i^{r,s})\) with \(v_i\) being the value he has computed in Step 4, destroys his ephemeral secret key \(sk_i^{r,s}\), and then propagates \(m_i^{r,s}\). Otherwise, \(i\) stops without propagating anything. Remark. In principle, as considered in subsection 6.2, the protocol may take arbitrarily many steps in some round. Should this happens, as discussed, a user \(i \in SV^{r,s}\) with \(s > \mu\) has exhausted

his stash of pre-generated ephemeral keys and has to authenticate his \((r, s)\)-message \(m_i^{r,s}\) by a "cascade" of ephemeral keys. Thus \(i\)'s message becomes a bit longer and transmitting these longer messages will take a bit more time. Accordingly, after so many steps of a given round, the value of the parameter \(\lambda\) will automatically increase slightly. (But it reverts to the original \(\lambda\) once a new block is produced and a new round starts.) Reconstruction of the Round-\(r\) Block by Non-Verifiers Instructions for every user \(i\) in the system: User \(i\) starts his own round \(r\) as soon as he has \(\text{CERT}^{r-1}\). • \(i\) follows the instructions of each step of the protocol, participates the propagation of all messages, but does not initiate any propagation in a step if he is not a verifier in it. • \(i\) ends his own round \(r\) by entering either Ending Condition 0 or Ending Condition 1 in some step, with the corresponding \(\text{CERT}^r\). • From there on, he starts his round \(r + 1\) while waiting to receive the actual block \(B^r\) (unless he has already received it), whose hash \(H(B^r)\) has been pinned down by \(\text{CERT}^r\). Again, if \(\text{CERT}^r\) indicates that \(B^r = B^r_\epsilon\), the \(i\) knows \(B^r\) the moment he has \(\text{CERT}^r\). 6.4 Analysis of \(\text{Algorand}'_2\) The analysis of \(\text{Algorand}'_2\) is easily derived from that of \(\text{Algorand}'_1\). Essentially, in \(\text{Algorand}'_2\), with overwhelming probability, (a) all honest users agree on the same block \(B^r\); the leader of a new block is honest with probability at least \(p_h = h^2(1 + h - h^2)\).

Algorand ′

2 Nesta seção, construímos uma versão de Algorand ′ trabalhando sob a seguinte suposição. Suposição da maioria honesta dos usuários: Mais de 2/3 dos usuários em cada PKr são honestos. Na Seção 8, mostramos como substituir a suposição acima pela desejada Maioria Honesta de Suposição de dinheiro. 6.1 Notações e parâmetros adicionais para Algorand ′ 2 Notações • \(\mu\) \(\in\)Z+: um limite superior pragmático para o número de etapas que, com probabilidade esmagadora, será realmente obtido em uma rodada. (Como veremos, o parâmetro \(\mu\) controla quantos eventos efêmeros chaves que um usuário prepara antecipadamente para cada rodada.) • Lr: uma variável aleatória que representa o número de tentativas de Bernoulli necessárias para obter 1, quando cada tentativa é 1 com probabilidade ph 2. Lr será usado para limitar o tempo necessário para gerar bloco Ir. • tH: um limite inferior para o número de verificadores honestos em uma etapa s > 1 da rodada r, tal que com probabilidade esmagadora (dados n e p), existem > tH verificadores honestos em SV r,s. Parâmetros • Relações entre vários parâmetros. — Para cada passo s > 1 da rodada r, n é escolhido de modo que, com probabilidade esmagadora,

|HSV r,s| >tH e |HSV r,s| + 2|MSV r,s| < 2tH. Observe que as duas desigualdades acima juntas implicam |HSV r,s| > 2|MSV r,s|: isto é, há é uma maioria honesta de 2/3 entre os verificadores selecionados. Quanto mais próximo de 1 for o valor de h, menor será n. Em particular, usamos (variantes de) Chernoffbounds para garantir que as condições desejadas se mantenham com uma probabilidade esmagadora. • Exemplos de escolhas de parâmetros importantes. — F = 10−18. — n \(\approx\)4000, tH \(\approx\)0,69n, k = 70. 6.2 Implementando chaves efêmeras em Algorand ′ 2 Lembre-se que um verificador i \(\in\)SV r,s assina digitalmente sua mensagem mr,s eu da etapa s na rodada r, em relação a uma chave pública efêmera pkr,s i , usando uma chave secreta efêmera skr,s eu que ele destrua prontamente depois de usar. Quando o número de passos possíveis que uma rodada pode dar é limitado por um determinado inteiro \(\mu\), já vimos como lidar de forma prática com chaves efêmeras. Por exemplo, como nós explicaram em Algorand ′ 1 (onde \(\mu\) = m + 3), para lidar com todas as suas possíveis chaves efêmeras, de uma rodada r′ para uma rodada r′ + 106, i gera um par (PMK, SMK), onde PMK mestre público chave de um esquema de assinatura baseado em identidade e SMK sua chave mestra secreta correspondente. Usuário eu divulga PMK e usa SMK para gerar a chave secreta de cada chave pública efêmera possível (e destrói SMK depois de fazer isso). O conjunto de chaves públicas efêmeras de i para o relevante rodadas é S = {i} \(\times\) {r′,. . . , r′ + 106} \(\times\) {1, . . . , \(\mu\)}. (Conforme discutido, à medida que a rodada r′ + 106 se aproxima, eu “atualizo” seu par (PMK, SMK).) Na prática, se \(\mu\) for grande o suficiente, uma rodada de Algorand ′ 2 não levará mais do que \(\mu\) passos. Em princípio, no entanto, existe a possibilidade remota de que, para alguma rodada r, o número de etapas realmente tomadas excederá \(\mu\). Quando isso acontecer, eu não conseguirei assinar a mensagem dele, Sr. eu para qualquer passo s > \(\mu\), porque ele preparou antecipadamente apenas \(\mu\) chaves secretas para a rodada r. Além disso, ele não poderia preparar e divulgar um novo estoque de chaves efêmeras, conforme discutido anteriormente. Na verdade, fazer então, ele precisaria inserir uma nova chave mestra pública PMK′ em um novo bloco. Mas, deveria arredondar r Se você desse mais e mais passos, nenhum novo bloco seria gerado. No entanto, existem soluções. Por exemplo, posso usar a última chave efêmera da rodada r, pkr,\(\mu\) eu , como segue. Ele gera outro estoque de pares de chaves para a rodada r - por exemplo, (1) gerando outro par de chaves mestras (PMK, SMK); (2) usar este par para gerar outras, digamos, 106 chaves efêmeras, sk r,\(\mu\)+1 eu , . . . , sk r,\(\mu\)+106 eu , correspondendo às etapas \(\mu\)+1, ..., \(\mu\)+106 da rodada r; (3) usando skr,\(\mu\) eu para digitalmente assine PMK (e qualquer mensagem (r, \(\mu\)) se i \(\in\)SV r,\(\mu\)), relativa a pkr,\(\mu\) eu ; e (4) apagar SMK e skr,\(\mu\) eu . Devo me tornar um verificador em uma etapa \(\mu\) + s com s \(\in\){1, . . . , 106}, então eu assino digitalmente seu (r, \(\mu\) + s)- mensagem senhor,\(\mu\)+s eu em relação à sua nova chave pk r,\(\mu\)+s eu = (eu, r, \(\mu\) + s). Claro, para verificar esta assinatura de i, outros precisam ter certeza de que esta chave pública corresponde à nova chave mestra pública PMK de i. Assim, além desta assinatura, i transmite sua assinatura digital de PMK relativa a pkr,\(\mu\) eu . É claro que esta abordagem pode ser repetida quantas vezes forem necessárias, caso a rodada r continue para mais e mais passos! A última chave secreta efêmera é usada para autenticar um novo público mestre chave e, portanto, outro estoque de chaves efêmeras para a rodada r. E assim por diante.6.3 O protocolo real Algorand ′ 2 Lembre-se novamente que, em cada etapa s de uma rodada r, um verificador i \(\in\)SV r,s usa seu segredo público de longo prazo par de chaves para produzir sua credencial, \(\sigma\)r,s eu \(\triangleq\)SIGi(r, s, Qr−1), bem como SIGi Qr-1 no caso s = 1. O verificador i usa seu par de chaves efêmeras, (pkr,s eu, skr,s i ), para assinar qualquer outra mensagem m que possa ser necessário. Para simplificar, escrevemos esigi(m), em vez de sigpkr,s i (m), para denotar o efêmero próprio de i assinatura de m nesta etapa e escreva ESIGi(m) em vez de SIGpkr,s eu (m) \(\triangleq\)(eu, m, esigi(m)). Etapa 1: bloquear proposta Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 1 da rodada r assim que tiver CERT r−1, que permite que i calcule H(Br−1) e Qr−1 de forma inequívoca. • O usuário i usa Qr−1 para verificar se i \(\in\)SV r,1 ou não. Se i /\(\in\)SV r,1, ele não faz nada na Etapa 1. • Se i \(\in\)SV r,1, ou seja, se i for um líder potencial, então ele faz o seguinte. (a) Se eu vi B0, . . . , o próprio Br−1 (qualquer Bj = Bj ǫ pode ser facilmente derivado de seu valor hash no CERT j e, portanto, é assumido como “visto”), então ele coleta os pagamentos da rodada r que foram foi propagado para ele até agora e calcula um conjunto de pagamento máximo PAY r eu deles. (b) Se eu não vi todo B0,. . . , Br−1 ainda, então ele define PAY r eu = \(\emptyset\). (c) Em seguida, i calcula seu “bloco de candidatos” Br eu = (r, PAGAR r eu, SIGi(Qr−1), H(Br−1)). (c) Finalmente, i calcula a mensagem mr,1 eu = (Br eu , esigi(H(Br eu )), \(\sigma\)r,1 i ), destrói seu efêmero chave secreta skr,1 i , e então propaga duas mensagens, mr,1 eu e (SIGi(Qr−1), \(\sigma\)r,1 eu), separadamente, mas simultaneamente.a aQuando i é o líder, SIGi(Qr−1) permite que outros calculem Qr = H(SIGi(Qr−1), r).

Propagação Seletiva Para encurtar a execução global do Passo 1 e de toda a rodada, é importante que o (r, 1)- as mensagens são propagadas seletivamente. Ou seja, para cada usuário j no sistema, • Para a primeira mensagem (r, 1) que ele recebe e verifica com sucesso, se ela contém um bloco ou é apenas uma credencial e uma assinatura de Qr−1, o jogador j o propaga normalmente. • Para todas as outras mensagens (r, 1) que o jogador j recebe e verifica com sucesso, ele propaga somente se o valor hash da credencial que ela contém for o menor entre os valores hash das credenciais contidas em todas as mensagens (r, 1) que ele recebeu e verificou com sucesso para longe. • Entretanto, se j receber duas mensagens diferentes no formato mr,1 eu do mesmo jogador i,b ele descarta o segundo, não importa qual seja o valor hash da credencial de i. Observe que, na propagação seletiva, é útil que cada líder potencial i propague seu credencial \(\sigma\)r,1 eu separadamente do senhor,1 i:c essas pequenas mensagens viajam mais rápido que os blocos, certifique-se propagação oportuna do mr,1 i é onde as credenciais contidas têm valores hash pequenos, enquanto fazer com que aqueles com valores hash grandes desapareçam rapidamente. aOu seja, todas as assinaturas estão corretas e, se for no formato mr,1 i , tanto o bloco quanto seu hash são válidos —embora j não verifique se o conjunto de pagamentos incluído é máximo para i ou não. bO que significa que eu sou malicioso. cAgradecemos a Georgios Vlachos por sugerir isso.Etapa 2: A primeira etapa do GC do protocolo de consenso graduado Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 2 da rodada r assim que tiver CERT r-1. • O usuário i espera um tempo máximo t2 \(\triangleq\) \(\lambda\) + Λ. Enquanto espero, ajo da seguinte maneira. 1. Depois de esperar pelo tempo 2\(\lambda\), ele encontra o usuário \(\ell\) tal que H(\(\sigma\)r,1 \(\ell\)) \(\leq\)H(\(\sigma\)r,1 j) para todos credenciais \(\sigma\)r,1 j que fazem parte das mensagens (r, 1) verificadas com sucesso que ele recebeu até agora.a 2. Se ele tem recebido um bloquear Br−1, qual partidas o hash valor H(Br−1) contido no CERT r−1,b e se ele recebeu de \(\ell\)uma mensagem válida mr,1 \(\ell\) = (Irmão \(\ell\), esig\(\ell\)(H(Br \(\ell\))), \(\sigma\)r,1 \(\ell\)),c então eu paro de esperar e defino v′ eu \(\triangleq\)(H(Br \(\ell\)), \(\ell\)). 3. Caso contrário, quando o tempo t2 acabar, i define v′ eu \(\triangleq\) \(\bot\). 4. Quando o valor de v′ i foi definido, eu calcula Qr−1 a partir do CERT r−1 e verifica se i \(\in\)SV r,2 ou não. 5. Se i \(\in\)SV r,2, i calcula a mensagem mr,2 eu \(\triangleq\)(ESIGi(v′ eu), \(\sigma\)r,2 i),d destrói seu efêmero chave secreta skr,2 i , e então propaga mr,2 eu. Caso contrário, eu para sem propagar qualquer coisa. aEssencialmente, o usuário i decide em particular que o líder da rodada r é o usuário \(\ell\). bClaro, se CERT r−1 indicar que Br−1 = Br−1 ǫ , então eu já “recebi” Br−1 no momento em que ele recebeu CERT r-1. cNovamente, as assinaturas do jogador \(\ell\) e os hashes foram todos verificados com sucesso e PAGUE r \(\ell\)no Brasil \(\ell\)é um conjunto de pagamento válido para rodada r - embora eu não verifique se PAY r \(\ell\)é máximo para \(\ell\)ou não. Se irmão \(\ell\) contém um conjunto de pagamentos vazio, então na verdade, não há necessidade de ver Br−1 antes de verificar se Br \(\ell\)é válido ou não. dA mensagem senhor,2 eu sinaliza que o jogador i considera o primeiro componente de v′ i será o hash do próximo bloco, ou considera o próximo bloco vazio.

Etapa 3: A segunda etapa do GC Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 3 da rodada r assim que tiver CERT r-1. • O usuário i espera um tempo máximo t3 \(\triangleq\)t2 + 2\(\lambda\) = 3\(\lambda\) + Λ. Enquanto espero, eu ajo como segue. 1. Se existe um valor v tal que ele recebeu pelo menos mensagens válidas mr,2 j de a forma (ESIGj(v), \(\sigma\)r,2 j ), sem qualquer contradição,a então ele para de esperar e define v' = v. 2. Caso contrário, quando o tempo t3 acabar, ele define v′ = \(\bot\). 3. Quando o valor de v′ for definido, i calcula Qr−1 a partir do CERT r−1 e verifica se i \(\in\)SV r,3 ou não. 4. Se i \(\in\)SV r,3, então i calcula a mensagem mr,3 eu \(\triangleq\)(ESIGi(v′), \(\sigma\)r,3 i ), destrói seu chave secreta efêmera skr,3 i , e então propaga mr,3 eu. Caso contrário, eu paro sem propagar qualquer coisa. aOu seja, ele não recebeu duas mensagens válidas contendo ESIGj(v) e um ESIGj(ˆv) diferente respectivamente, de um jogador j. Aqui e daqui em diante, exceto nas Condições Finais definidas posteriormente, sempre que um jogador honesto deseja mensagens de um determinado formato, mensagens contraditórias nunca são contadas ou consideradas válidas.

Etapa 4: Resultado do GC e a primeira etapa do BBA⋆ Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia sua própria Etapa 4 da rodada r assim que ele termina seu próprio Passo 3. • O usuário i espera um tempo máximo 2\(\lambda\).a Enquanto espera, i age da seguinte forma. 1. Ele calcula vi e gi, a saída do GC, como segue. (a) Se existe um valor v′ ̸= \(\bot\)tal que ele recebeu pelo menos tH mensagens válidas senhor,3 j = (ESIGj(v′), \(\sigma\)r,3 j ), então ele para de esperar e define vi \(\triangleq\)v′ e gi \(\triangleq\)2. (b) Se ele recebeu pelo menos as mensagens válidas mr,3 j = (ESIGj(\(\bot\)), \(\sigma\)r,3 j ), então ele para esperando e define vi \(\triangleq\) \(\bot\) e gi \(\triangleq\)0.b (c) Caso contrário, quando o tempo 2\(\lambda\) acabar, se existir um valor v′ ̸= \(\bot\)tal que ele tenha recebeu pelo menos ⌈tH 2 ⌉mensagens válidas senhor,j j = (ESIGj(v′), \(\sigma\)r,3 j ), então ele define vi \(\triangleq\)v′ e gi \(\triangleq\)1.c (d) Caso contrário, quando o tempo 2\(\lambda\) acabar, ele define vi \(\triangleq\) \(\bot\) e gi \(\triangleq\)0. 2. Quando os valores vi e gi forem definidos, i calcula bi, a entrada de BBA⋆, como segue: bi \(\triangleq\)0 se gi = 2, e bi \(\triangleq\)1 caso contrário. 3. i calcula Qr−1 a partir do CERT r−1 e verifica se i \(\in\)SV r,4 ou não. 4. Se i \(\in\)SV r,4, ele calcula a mensagem mr,4 eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,4 i ), destrói seu chave secreta efêmera skr,4 i , e propaga mr,4 eu. Caso contrário, eu para sem propagar qualquer coisa. aAssim, o tempo total máximo desde que i inicia sua Etapa 1 da rodada r poderia ser t4 \(\triangleq\)t3 + 2\(\lambda\) = 5\(\lambda\) + Λ. bSe a Etapa (b) estiver ou não no protocolo, isso não afeta sua correção. No entanto, a presença da Etapa (b) permite que a Etapa 4 termine em menos de 2\(\lambda\) se um número suficiente de verificadores da Etapa 3 tiver “assinado \(\bot\)”. cPode-se provar que v′ neste caso, se existir, deve ser único.Etapa s, 5 \(\leq\)s \(\leq\)m + 2, s −2 ≡0 mod 3: Uma etapa de BBA⋆ com moeda fixada em 0 Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele termina seu próprio Passo s −1. • O usuário i espera um tempo máximo 2\(\lambda\).a Enquanto espera, i age da seguinte forma. – Condição Final 0: Se em algum ponto existe uma string v ̸= \(\bot\) e um passo s′ tal que (a) 5 \(\leq\)s′ \(\leq\)s, s′ −2 ≡0 mod 3 - isto é, a etapa s′ é uma etapa fixada em moeda em 0, (b) recebi pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(0), ESIGj(v), \(\sigma\)r,s′−1 j ),b e (c) i recebeu uma mensagem válida (SIGj(Qr−1), \(\sigma\)r,1 j) com j sendo o segundo componente de v, então, eu para de esperar e termina sua própria execução do Passo s (e de fato da rodada r) imediatamente, sem propagar nada como um verificador (r, s); define H(Br) como o primeiro componente de v; e define seu próprio CERT r como o conjunto de mensagens mr,s′−1 j da etapa (b) junto com (SIGj(Qr−1), \(\sigma\)r,1 j ).c – Condição Final 1: Se em algum ponto existir um passo s′ tal que (a') 6 \(\leq\)s′ \(\leq\)s, s′ −2 ≡1 mod 3 - isto é, a etapa s′ é uma etapa fixada em moeda para 1, e (b') i recebeu pelo menos tH mensagens válidas mr,s′−1 j = (ESIGj(1), ESIGj(vj), \(\sigma\)r,s′−1 j ),d então, eu para de esperar e termina sua própria execução do Passo s (e de fato da rodada r) certo afastado sem propagar nada como um verificador (r, s); define Br = Br ǫ; e define o seu próprio CERT r será o conjunto de mensagens mr,s′−1 j da subetapa (b'). – Se em qualquer ponto ele tem recebido em menos o válido senhor,s−1 j é de o formulário (ESIGj(1), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele para de esperar e define bi \(\triangleq\)1. – Se em qualquer ponto ele tem recebido em menos o válido senhor,s−1 j é de o formulário (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), mas eles não concordam sobre o mesmo v, então ele para esperando e define bi \(\triangleq\)0. – Caso contrário, quando o tempo 2\(\lambda\) acabar, i define bi \(\triangleq\)0. – Quando o valor bi for definido, i calcula Qr−1 a partir do CERT r−1 e verifica se eu \(\in\)SV r,s. – Se i \(\in\)SV r,s, i calcula a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i) com vi sendo o valor que ele calculou na Etapa 4, destrói sua chave secreta efêmera skr,s eu, e então propaga senhor,s eu. Caso contrário, paro sem propagar nada. aAssim, o tempo total máximo desde que i inicia sua Etapa 1 da rodada r poderia ser ts \(\triangleq\)ts−1 + 2\(\lambda\) = (2s −3)\(\lambda\) + Λ. bEssa mensagem do jogador j é contada mesmo que o jogador i também tenha recebido uma mensagem de j assinando por 1. Coisas semelhantes para a Condição Final 1. Conforme mostrado na análise, isso é para garantir que todos os usuários honestos saibam CERT r dentro do tempo \(\lambda\) um do outro. cO usuário i agora conhece H(Br) e sua própria rodada termina. Ele só precisa esperar até que o bloco Br esteja propagado para ele, o que pode levar algum tempo adicional. Ele ainda ajuda a propagar mensagens como um usuário genérico, mas não inicia nenhuma propagação como um verificador (r, s). Em particular, ele ajudou a propagar todas as mensagens em seu CERT r, que é suficiente para o nosso protocolo. Observe que ele também deve definir bi \(\triangleq\)0 para o protocolo BA binário, mas bi não é necessário neste caso de qualquer maneira. Coisas semelhantes para todas as instruções futuras. dNeste caso, não importa quais são os vj’s. 65Etapa s, 6 \(\leq\)s \(\leq\)m + 2, s −2 ≡1 mod 3: Uma etapa de BBA⋆ fixada em moeda para 1 Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele termina seu próprio Passo s −1. • O usuário i espera um tempo máximo de 2\(\lambda\). Enquanto espero, ajo da seguinte maneira. – Condição Final 0: As mesmas instruções da etapa Coin-Fixed-To-0. – Condição Final 1: As mesmas instruções da etapa Coin-Fixed-To-0. – Se em qualquer ponto ele tem recebido em menos o válido senhor,s−1 j é de o formulário (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele para de esperar e define bi \(\triangleq\)0.a – Caso contrário, quando o tempo 2\(\lambda\) acabar, i define bi \(\triangleq\)1. – Quando o valor bi for definido, i calcula Qr−1 a partir do CERT r−1 e verifica se eu \(\in\)SV r,s. – Se i \(\in\)SV r,s, i calcula a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i) com vi sendo o valor que ele calculou na Etapa 4, destrói sua chave secreta efêmera skr,s eu, e então propaga senhor,s eu. Caso contrário, paro sem propagar nada. aObserve que receber mensagens válidas (r, s −1) assinadas para 1 significaria a Condição Final 1. Etapa s, 7 \(\leq\)s \(\leq\)m + 2, s −2 ≡2 mod 3: Uma etapa de BBA⋆ com moeda genuinamente invertida Instruções para cada usuário i \(\in\)PKr−k: O usuário i inicia suas próprias etapas da rodada r assim que ele termina seu próprio passo s −1. • O usuário i espera um tempo máximo de 2\(\lambda\). Enquanto espero, ajo da seguinte maneira. – Condição Final 0: As mesmas instruções da etapa Coin-Fixed-To-0. – Condição Final 1: As mesmas instruções da etapa Coin-Fixed-To-0. – Se em qualquer ponto ele tem recebido em menos o válido senhor,s−1 j é de o formulário (ESIGj(0), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele para de esperar e define bi \(\triangleq\)0. – Se em qualquer ponto ele tem recebido em menos o válido senhor,s−1 j é de o formulário (ESIGj(1), ESIGj(vj), \(\sigma\)r,s−1 j ), então ele para de esperar e define bi \(\triangleq\)1. – Caso contrário, quando o tempo 2\(\lambda\) acabar, deixando SV r,s−1 eu seja o conjunto de (r, s −1)-verificadores de a quem ele recebeu uma mensagem válida mr,s−1 j , i define bi \(\triangleq\)lsb(minj\(\in\)SV r,s−1 eu H(\(\sigma\)r,s−1 j )). – Quando o valor bi for definido, i calcula Qr−1 a partir do CERT r−1 e verifica se eu \(\in\)SV r,s. – Se i \(\in\)SV r,s, i calcula a mensagem mr,s eu \(\triangleq\)(ESIGi(bi), ESIGi(vi), \(\sigma\)r,s i) com vi sendo o valor que ele calculou na Etapa 4, destrói sua chave secreta efêmera skr,s eu, e então propaga senhor,s eu. Caso contrário, paro sem propagar nada. Observação. Em princípio, conforme considerado na subseção 6.2, o protocolo pode levar arbitrariamente muitas passos em alguma rodada. Caso isso aconteça, conforme discutido, um usuário i \(\in\)SV r,s com s > \(\mu\) esgotou

seu estoque de chaves efêmeras pré-geradas e precisa autenticar sua mensagem (r, s) mr,s eu por um “cascata” de chaves efêmeras. Assim, a mensagem de i torna-se um pouco mais longa e a transmissão é mais longa as mensagens levarão um pouco mais de tempo. Assim, depois de tantas etapas de uma determinada rodada, o valor de o parâmetro \(\lambda\) aumentará ligeiramente automaticamente. (Mas ele reverte para o \(\lambda\) original uma vez que um novo bloco é produzido e uma nova rodada começa.) Reconstrução do Bloco Round-r por Não-Verificadores Instruções para cada usuário i no sistema: O usuário i inicia sua própria rodada r assim que tiver CERT r-1. • sigo as instruções de cada etapa do protocolo, participa da propagação de todos mensagens, mas não inicia nenhuma propagação em uma etapa se ele não for um verificador nela. • i termina sua própria rodada r inserindo a Condição Final 0 ou a Condição Final 1 em alguma etapa, com o CERT r correspondente. • A partir daí, ele inicia sua rodada r + 1 enquanto espera para receber o bloco real Br (a menos que ele já recebeu), cujo hash H(Br) foi definido pelo CERT r. Novamente, se CERT r indica que Br = Br ǫ, o i conhece Br no momento em que possui CERT r. 6.4 Análise de Algorand ′ 2 A análise de Algorand ′ 2 é facilmente derivado daquele de Algorand ′ 1. Essencialmente, em Algorand ′ 2, com probabilidade esmagadora, (a) todos os usuários honestos concordam com o mesmo bloco Br; o líder de um novo O bloco é honesto com probabilidade de pelo menos ph = h2(1 + h −h2).

Handling Offline Honest users

Handling Offline Honest users

As we said, a honest user follows all his prescribed instructions, which include that of being online and running the protocol. This is not a major burden in Algorand, since the computation and bandwidth required from a honest user are quite modest. Yet, let us point out that Algorand can be easily modified so as to work in two models, in which honest users are allowed to be offline in great numbers. Before discussing these two models, let us point out that, if the percentage of honest players were 95%, Algorand could still be run setting all parameters assuming instead that \(h = 80\%\). Accordingly, Algorand would continue to work properly even if at most half of the honest players chose to go offline (indeed, a major case of "absenteeism"). In fact, at any point in time, at least 80% of the players online would be honest. From Continual Participation to Lazy Honesty As we saw, \(\text{Algorand}'_1\) and \(\text{Algorand}'_2\) choose the look-back parameter \(k\). Let us now show that choosing \(k\) properly large enables one to remove the Continual Participation requirement. This requirement ensures a crucial property: namely, that the underlying BA protocol \(\text{BBA}^\star\) has a proper honest majority. Let us now explain how lazy honesty provides an alternative and attractive way to satisfy this property.

Recall that a user \(i\) is lazy-but-honest if (1) he follows all his prescribed instructions, when he is asked to participate to the protocol, and (2) he is asked to participate to the protocol only very rarely —e.g., once a week— with suitable advance notice, and potentially receiving significant rewards when he participates. To allow Algorand to work with such players, it just suffices to "choose the verifiers of the current round among the users already in the system in a much earlier round." Indeed, recall that the verifiers for a round \(r\) are chosen from users in round \(r - k\), and the selections are made based on the quantity \(Q_{r-1}\). Note that a week consists of roughly 10,000 minutes, and assume that a round takes roughly (e.g., on average) 5 minutes, so a week has roughly 2,000 rounds. Assume that, at some point of time, a user \(i\) wishes to plan his time and know whether he is going to be a verifier in the coming week. The protocol now chooses the verifiers for a round \(r\) from users in round \(r - k - 2{,}000\), and the selections are based on \(Q_{r-2{,}001}\). At round \(r\), player \(i\) already knows the values \(Q_{r-2{,}000}, \ldots, Q_{r-1}\), since they are actually part of the blockchain. Then, for each \(M\) between 1 and 2,000, \(i\) is a verifier in a step \(s\) of round \(r + M\) if and only if

\[H\bigl(\text{SIG}_i(r + M,\, s,\, Q_{r+M-2{,}001})\bigr) \leq p\]

Thus, to check whether he is going to be called to act as a verifier in the next 2,000 rounds, \(i\) must compute \(\sigma^{M,s}_i = \text{SIG}_i(r + M,\, s,\, Q_{r+M-2{,}001})\) for \(M = 1\) to \(2{,}000\) and for each step \(s\), and check whether \(H(\sigma^{M,s}_i) \leq p\) for some of them. If computing a digital signature takes a millisecond, then this entire operation will take him about 1 minute of computation. If he is not selected as a verifier in any of these rounds, then he can go off-line with an "honest conscience". Had he continuously participated, he would have essentially taken 0 steps in the next 2,000 rounds anyway! If, instead, he is selected to be a verifier in one of these rounds, then he readies himself (e.g., by obtaining all the information necessary) to act as an honest verifier at the proper round. By so acting, a lazy-but-honest potential verifier \(i\) only misses participating to the propagation of messages. But message propagation is typically robust. Moreover, the payers and the payees of recently propagated payments are expected to be online to watch what happens to their payments, and thus they will participate to message propagation, if they are honest.

Lidando com usuários honestos off-line

Como dissemos, um usuário honesto segue todas as instruções prescritas, que incluem a de estar online e executando o protocolo. Este não é um grande fardo em Algorand, uma vez que o cálculo e a largura de banda exigida de um usuário honesto é bastante modesta. No entanto, vamos salientar que Algorand pode ser facilmente modificável para funcionar em dois modelos, nos quais usuários honestos podem ficar off-line em grandes números. Antes de discutir estes dois modelos, salientamos que, se a percentagem de jogadores honestos eram 95%, Algorand ainda poderia ser executado definindo todos os parâmetros assumindo que h = 80%. Conseqüentemente, Algorand continuaria a funcionar corretamente mesmo que no máximo metade dos jogadores honestos optaram por ficar off-line (na verdade, um caso importante de “absenteísmo”). Na verdade, em qualquer momento, pelo menos 80% dos jogadores online seriam honestos. Da participação contínua à honestidade preguiçosa Como vimos, Algorand ′ 1 e Algorand ′ 2 escolha o parâmetro de retrospectiva k. Vamos agora mostrar que escolher k adequadamente grande permite remover o requisito de participação contínua. Este requisito garante uma propriedade crucial: a saber, que o protocolo BA subjacente BBA⋆tem uma maioria honesta adequada. Vamos agora explicar o quão preguiçoso a honestidade fornece uma maneira alternativa e atraente de satisfazer essa propriedade.

Lembre-se de que um usuário i é preguiçoso, mas honesto se (1) seguir todas as instruções prescritas, quando ele é convidado a participar do protocolo e (2) ele é convidado a participar apenas do protocolo muito raramente - por exemplo, uma vez por semana - com aviso prévio adequado e potencialmente recebendo recompensas quando ele participa. Para permitir que Algorand trabalhe com tais players, basta “escolher os verificadores do rodada atual entre os usuários que já estão no sistema em uma rodada muito anterior.” Na verdade, lembre-se que os verificadores para uma rodada r são escolhidos entre os usuários da rodada r −k, e as seleções são feitas com base na quantidade Qr−1. Observe que uma semana consiste em aproximadamente 10.000 minutos e suponha que um rodada leva aproximadamente (por exemplo, em média) 5 minutos, então uma semana tem cerca de 2.000 rodadas. Suponha que, em algum momento, um usuário deseja planejar seu tempo e saber se ele estará um verificador na próxima semana. O protocolo agora escolhe os verificadores para uma rodada r entre os usuários em arredondar r −k −2.000, e as seleções são baseadas em Qr−2.001. Na rodada r, jogador que eu já conheço os valores Qr −2.000, . . . , Qr−1, uma vez que na verdade fazem parte do blockchain. Então, para cada M entre 1 e 2.000, i é um verificador em uma etapa s da rodada r + M se e somente se .H SIGi r + M, s, Qr+M−2.001 \(\leq\)p. Assim, para verificar se ele será chamado para atuar como verificador nas próximas 2.000 rodadas, devo calcular \(\sigma\)M,s eu =SIGi r + M, s, Qr+M−2.001 para M = 1 a 2.000 e para cada etapa s, e verifique se .H(\(\sigma\)M,s eu ) \(\leq\)p para alguns deles. Se o cálculo de uma assinatura digital levar um milissegundo, então toda esta operação levará cerca de 1 minuto de cálculo. Se ele não for selecionado como verificador em qualquer uma dessas rodadas, ele poderá ficar off-line com uma “consciência honesta”. Se ele tivesse continuamente participou, ele teria essencialmente dado 0 passos nas próximas 2.000 rodadas de qualquer maneira! Se, em vez disso, ele é selecionado para ser um verificador em uma dessas rodadas, então ele se prepara (por exemplo, obtendo todos as informações necessárias) para atuar como um verificador honesto na rodada apropriada. Ao agir assim, um verificador de potencial preguiçoso, mas honesto, apenas deixa de participar da propagação. de mensagens. Mas a propagação de mensagens é normalmente robusta. Além disso, os pagadores e os beneficiários de espera-se que os pagamentos propagados recentemente estejam on-line para observar o que acontece com seus pagamentos, e assim participarão da propagação da mensagem, se forem honestos.

Protocol Algorand ′ with Honest Majority of Money

Protocol \(\text{Algorand}^\prime\) with Honest Majority of Money

We now, finally, show how to replace the Honest Majority of Users assumption with the much more meaningful Honest Majority of Money assumption. The basic idea is (in a proof-of-stake flavor) "to select a user \(i \in PK^{r-k}\) to belong to \(SV^{r,s}\) with a weight (i.e., decision power) proportional to the amount of money owned by \(i\)."24 By our HMM assumption, we can choose whether that amount should be owned at round \(r - k\) or at (the start of) round \(r\). Assuming that we do not mind continual participation, we opt for the latter choice. (To remove continual participation, we would have opted for the former choice. Better said, for the amount of money owned at round \(r - k - 2{,}000\).) There are many ways to implement this idea. The simplest way would be to have each key hold at most 1 unit of money and then select at random \(n\) users \(i\) from \(PK^{r-k}\) such that \(a_i^{(r)} = 1\). 24We should say \(PK^{r-k-2{,}000}\) so as to replace continual participation. For simplicity, since one may wish to require continual participation anyway, we use \(PK^{r-k}\) as before, so as to carry one less parameter.

The Next Simplest Implementation The next simplest implementation may be to demand that each public key owns a maximum amount of money \(M\), for some fixed \(M\). The value \(M\) is small enough compared with the total amount of money in the system, such that the probability a key belongs to the verifier set of more than one step in —say— \(k\) rounds is negligible. Then, a key \(i \in PK^{r-k}\), owning an amount of money \(a_i^{(r)}\) in round \(r\), is chosen to belong to \(SV^{r,s}\) if

\[H\left(\text{SIG}_i\left(r, s, Q^{r-1}\right)\right) \leq p \cdot \frac{a_i^{(r)}}{M}.\]

And all proceeds as before. A More Complex Implementation The last implementation "forced a rich participant in the system to own many keys". An alternative implementation, described below, generalizes the notion of status and consider each user \(i\) to consist of \(K + 1\) copies \((i, v)\), each of which is independently selected to be a verifier, and will own his own ephemeral key \((pk_{i,v}^{r,s}, sk_{i,v}^{r,s})\) in a step \(s\) of a round \(r\). The value \(K\) depends on the amount of money \(a_i^{(r)}\) owned by \(i\) in round \(r\). Let us now see how such a system works in greater detail. Number of Copies Let \(n\) be the targeted expected cardinality of each verifier set, and let \(a_i^{(r)}\) be the amount of money owned by a user \(i\) at round \(r\). Let \(A^r\) be the total amount of money owned by the users in \(PK^{r-k}\) at round \(r\), that is,

\[A^r = \sum_{i \in PK^{r-k}} a_i^{(r)}.\]

If \(i\) is an user in \(PK^{r-k}\), then \(i\)'s copies are \((i, 1), \ldots, (i, K + 1)\), where

\[K = \left\lfloor \frac{n \cdot a_i^{(r)}}{A^r} \right\rfloor.\]

Example. Let \(n = 1{,}000\), \(A^r = 10^9\), and \(a_i^{(r)} = 3.7\) millions. Then,

\[K = \left\lfloor \frac{10^3 \cdot (3.7 \cdot 10^6)}{10^9} \right\rfloor = \lfloor 3.7 \rfloor = 3.\]

Verifiers and Credentials Let \(i\) be a user in \(PK^{r-k}\) with \(K + 1\) copies. For each \(v = 1, \ldots, K\), copy \((i, v)\) belongs to \(SV^{r,s}\) automatically. That is, \(i\)'s credential is \(\sigma_{i,v}^{r,s} \triangleq \text{SIG}_i((i, v), r, s, Q^{r-1})\), but the corresponding condition becomes \(H(\sigma_{i,v}^{r,s}) \leq 1\), which is always true. For copy \((i, K + 1)\), for each Step \(s\) of round \(r\), \(i\) checks whether

\[H\left(\text{SIG}_i\left((i, K + 1), r, s, Q^{r-1}\right)\right) \leq \frac{a_i^{(r)} \cdot n}{A^r} - K.\]

If so, copy \((i, K + 1)\) belongs to \(SV^{r,s}\). To prove it, \(i\) propagates the credential

\[\sigma_{i,K+1}^{r,1} = \text{SIG}_i\left((i, K + 1), r, s, Q^{r-1}\right).\]

Example. As in the previous example, let \(n = 1\text{K}\), \(a_i^{(r)} = 3.7\text{M}\), \(A^r = 1\text{B}\), and \(i\) has 4 copies: \((i, 1), \ldots, (i, 4)\). Then, the first 3 copies belong to \(SV^{r,s}\) automatically. For the 4th one, conceptually, \(\text{Algorand}^\prime\) independently rolls a biased coin, whose probability of Heads is 0.7. Copy \((i, 4)\) is selected if and only if the coin toss is Heads. (Of course, this biased coin flip is implemented by hashing, signing, and comparing —as we have done all along in this paper— so as to enable \(i\) to prove his result.) Business as Usual Having explained how verifiers are selected and how their credentials are computed at each step of a round \(r\), the execution of a round is similar to that already explained.

Protocolo Algorand ′ com maioria honesta de dinheiro

Agora, finalmente, mostramos como substituir a suposição da maioria honesta dos usuários pela hipótese muito mais suposição significativa da Maioria Honesta do Dinheiro. A ideia básica é (em um sabor proof-of-stake) “selecionar um usuário i \(\in\)PKr−k para pertencer a SV r,s com um peso (ou seja, poder de decisão) proporcional a a quantidade de dinheiro possuída por i.”24 Pela nossa suposição HMM, podemos escolher se essa quantia deve ser detida na rodada r −k ou no (início da) rodada r. Supondo que não nos importamos com a participação contínua, optamos por a última escolha. (Para eliminar a participação contínua, teríamos optado pela primeira opção. Melhor dizendo, pela quantidade de dinheiro possuída na rodada r −k −2.000.) Existem muitas maneiras de implementar essa ideia. A maneira mais simples seria manter cada tecla pressionada no máximo 1 unidade de dinheiro e então selecione aleatoriamente n usuários i de PKr−k tal que a(r) eu = 1. 24Deveríamos dizer PKr−k−2.000 para substituir a participação contínua. Por simplicidade, uma vez que se pode querer exigir de qualquer forma, com participação contínua, usamos PKr-k como antes, para carregar um parâmetro a menos.

A próxima implementação mais simples A próxima implementação mais simples pode ser exigir que cada chave pública possua uma quantidade máxima de dinheiro M, para algum M fixo. O valor M é pequeno o suficiente comparado com a quantidade total de dinheiro dinheiro no sistema, de modo que a probabilidade de uma chave pertencer ao conjunto verificador de mais de um intervir —digamos— k rodadas é insignificante. Então, uma chave i \(\in\)PKr−k, possuindo uma quantia de dinheiro a(r) eu na rodada r, é escolhido para pertencer a SV r,s se .H SIGi r, s, Qr−1 \(\leq\)p \(\cdot\) uma(r) eu M . E tudo continua como antes. Uma implementação mais complexa A última implementação “forçou um participante rico no sistema a possuir muitas chaves”. Uma implementação alternativa, descrita abaixo, generaliza a noção de status e considera cada usuário i consiste em K + 1 cópias (i, v), cada uma das quais é selecionada independentemente para ser um verificador, e possuirá sua própria chave efêmera (pkr,s eu,v, skr,s i,v) em uma etapa s de uma rodada r. O valor K depende sobre a quantidade de dinheiro a(r) eu propriedade de i na rodada r. Vejamos agora como esse sistema funciona com mais detalhes. Número de cópias Seja n a cardinalidade esperada desejada de cada conjunto de verificadores e seja a(r) eu seja a quantidade de dinheiro pertencente a um usuário i na rodada r. Seja Ar a quantidade total de dinheiro possuído pelos usuários em PKr−k na rodada r, ou seja, Ar = X i\(\in\)P Kr−k um(r) eu. Se i for um usuário em PKr−k, então as cópias de i são (i, 1), . . . , (i, K + 1), onde K = $ n \(\cdot\) uma(r) eu Ar % . Exemplo. Seja n = 1.000, Ar = 109 e a(r) eu = 3,7 milhões. Então, K = 103 \(\cdot\) (3,7 \(\cdot\) 106) 109  = ⌊3,7⌋= 3 . Verificadores e credenciais Seja eu um usuário em PKr−k com K + 1 cópias. Para cada v = 1,. . . , K, copy (i, v) pertence a SV r,s automaticamente. Ou seja, a credencial de i é \(\sigma\)r,s i,v \(\triangleq\)SIGi((i, v), r, s, Qr−1), mas a condição correspondente torna-se .H(\(\sigma\)r,s i,v) \(\leq\)1, que é sempre verdadeiro. Para cópia (i, K + 1), para cada etapa s da rodada r, i verifica se .H SIGi (eu, K + 1), r, s, Qr−1 \(\leq\)a(r) eu n Ar-K.

Se sim, a cópia (i, K + 1) pertence a SV r,s. Para provar isso, i propaga a credencial \(\sigma\)r,1 i,K+1 = SIGi (eu, K + 1), r, s, Qr−1 . Exemplo. Como no exemplo anterior, seja n = 1K, a(r) eu = 3,7M, Ar = 1B e i tem 4 cópias: (i, 1), . . . , (eu, 4). Então, as primeiras 3 cópias pertencem a SV r,s automaticamente. Para o 4º, conceitualmente, Algorand ′ lança independentemente uma moeda viciada, cuja probabilidade de cara é 0,7. Copiar (i, 4) é selecionado se e somente se o lançamento da moeda for Cara. (É claro que esse lançamento de moeda tendencioso é implementado hashing, assinando e comparando - como fazemos fiz o tempo todo neste artigo - para me permitir provar seu resultado.) Negócios como sempre Tendo explicado como os verificadores são selecionados e como suas credenciais são calculada a cada etapa de uma rodada r, a execução de uma rodada é semelhante à já explicada.

Handling Forks

Handling Forks

Having reduced the probability of forks to 10−12 or 10−18, it is practically unnecessary to handle them in the remote chance that they occur. Algorand, however, can also employ various fork resolution procedures, with or without proof of work. One possible way of instructing the users to resolve forks is as follows: • Follow the longest chain if a user sees multiple chains. • If there are more than one longest chains, follow the one with a non-empty block at the end. If all of them have empty blocks at the end, consider their second-last blocks. • If there are more than one longest chains with non-empty blocks at the end, say the chains are of length r, follow the one whose leader of block r has the smallest credential. If there are ties, follow the one whose block r itself has the smallest hash value. If there are still ties, follow the one whose block r is ordered the first lexicographically.

Tratamento de forks

Tendo reduzido a probabilidade de bifurcações para 10-12 ou 10-18, é praticamente desnecessário lidar com na remota chance de ocorrerem. Algorand, no entanto, também pode empregar vários fork procedimentos de resolução, com ou sem comprovação de trabalho. Uma forma possível de instruir os usuários a resolver bifurcações é a seguinte: • Siga a cadeia mais longa se um usuário vir várias cadeias. • Se houver mais de uma cadeia mais longa, siga aquela com um bloco não vazio no final. Se todos eles têm blocos vazios no final, considere seus penúltimos blocos. • Se houver mais de uma cadeia mais longa com blocos não vazios no final, digamos que as cadeias sejam de comprimento r, siga aquele cujo líder do bloco r possui a menor credencial. Se houver laços, siga aquele cujo bloco r tem o menor valor hash. Se ainda houver empates, siga o aquele cujo bloco r é ordenado lexicograficamente em primeiro lugar.

Handling Network Partitions

Handling Network Partitions

As said, we assume the propagation times of messages among all users in the network are upperbounded by \(\lambda\) and \(\Lambda\). This is not a strong assumption, as today's Internet is fast and robust, and the actual values of these parameters are quite reasonable. Here, let us point out that \(\text{Algorand}^\prime_2\) continues to work even if the Internet occasionally got partitioned into two parts. The case when the Internet is partitioned into more than two parts is similar. 10.1 Physical Partitions First of all, the partition may be caused by physical reasons. For example, a huge earthquake may end up completely breaking down the connection between Europe and America. In this case, the malicious users are also partitioned and there is no communication between the two parts. Thus

there will be two Adversaries, one for part 1 and the other for part 2. Each Adversary still tries to break the protocol in its own part. Assume the partition happens in the middle of round \(r\). Then each user is still selected as a verifier based on \(PK^{r-k}\), with the same probability as before. Let \(HSV^{r,s}_i\) and \(MSV^{r,s}_i\) respectively be the set of honest and malicious verifiers in a step \(s\) in part \(i \in \{1, 2\}\). We have

\[|HSV^{r,s}_1| + |MSV^{r,s}_1| + |HSV^{r,s}_2| + |MSV^{r,s}_2| = |HSV^{r,s}| + |MSV^{r,s}|.\]

Note that \(|HSV^{r,s}| + |MSV^{r,s}| < |HSV^{r,s}| + 2|MSV^{r,s}| < 2t_H\) with overwhelming probability. If some part \(i\) has \(|HSV^{r,s}_i| + |MSV^{r,s}_i| \geq t_H\) with non-negligible probability, e.g., 1%, then the probability that \(|HSV^{r,s}_{3-i}| + |MSV^{r,s}_{3-i}| \geq t_H\) is very low, e.g., \(10^{-16}\) when \(F = 10^{-18}\). In this case, we may as well treat the smaller part as going offline, because there will not be enough verifiers in this part to generate \(t_H\) signatures to certify a block. Let us consider the larger part, say part 1 without loss of generality. Although \(|HSV^{r,s}| < t_H\) with negligible probability in each step \(s\), when the network is partitioned, \(|HSV^{r,s}_1|\) may be less than \(t_H\) with some non-negligible probability. In this case the Adversary may, with some other non-negligible probability, force the binary BA protocol into a fork in round \(r\), with a nonempty block \(B_r\) and the empty block \(B^r_\epsilon\) both having \(t_H\) valid signatures.25 For example, in a Coin-Fixed-To-0 step \(s\), all verifiers in \(HSV^{r,s}_1\) signed for bit 0 and \(H(B_r)\), and propagated their messages. All verifiers in \(MSV^{r,s}_1\) also signed 0 and \(H(B_r)\), but withheld their messages. Because \(|HSV^{r,s}_1| + |MSV^{r,s}_1| \geq t_H\), the system has enough signatures to certify \(B_r\). However, since the malicious verifiers withheld their signatures, the users enter step \(s + 1\), which is a Coin-Fixed-To-1 step. Because \(|HSV^{r,s}_1| < t_H\) due to the partition, the verifiers in \(HSV^{r,s+1}_1\) did not see \(t_H\) signatures for bit 0 and they all signed for bit 1. All verifiers in \(MSV^{r,s+1}_1\) did the same. Because \(|HSV^{r,s+1}_1| + |MSV^{r,s+1}_1| \geq t_H\), the system has enough signatures to certify \(B^r_\epsilon\). The Adversary then creates a fork by releasing the signatures of \(MSV^{r,s}_1\) for 0 and \(H(B_r)\). Accordingly, there will be two \(Q_r\)'s, defined by the corresponding blocks of round \(r\). However, the fork will not continue and only one of the two branches may grow in round \(r + 1\). Additional Instructions for \(\text{Algorand}^\prime_2\). When seeing a non-empty block \(B_r\) and the empty block \(B^r_\epsilon\), follow the non-empty one (and the \(Q_r\) defined by it). Indeed, by instructing the users to go with the non-empty block in the protocol, if a large amount of honest users in \(PK^{r+1-k}\) realize there is a fork at the beginning of round \(r + 1\), then the empty block will not have enough followers and will not grow. Assume the Adversary manages to partition the honest users so that some honest users see \(B_r\) (and perhaps \(B^r_\epsilon\)), and some only see \(B^r_\epsilon\). Because the Adversary cannot tell which one of them will be a verifier following \(B_r\) and which will be a verifier following \(B^r_\epsilon\), the honest users are randomly partitioned and each one of them still becomes a verifier (either with respect to \(B_r\) or with respect to \(B^r_\epsilon\)) in a step \(s > 1\) with probability \(p\). For the malicious users, each one of them may have two chances to become a verifier, one with \(B_r\) and the other with \(B^r_\epsilon\), each with probability \(p\) independently. Let \(HSV^{r+1,s}_{1;B_r}\) be the set of honest verifiers in step \(s\) of round \(r+1\) following \(B_r\). Other notations such as \(HSV^{r+1,s}_{1;B^r_\epsilon}\), \(MSV^{r+1,s}_{1;B_r}\) and \(MSV^{r+1,s}_{1;B^r_\epsilon}\) are similarly defined. By Chernoff bound, it is easy 25Having a fork with two non-empty blocks is not possible with or without partitions, except with negligible probability.

to see that with overwhelming probability,

\[|HSV^{r+1,s}_{1;B_r}| + |HSV^{r+1,s}_{1;B^r_\epsilon}| + |MSV^{r+1,s}_{1;B_r}| + |MSV^{r+1,s}_{1;B^r_\epsilon}| < 2t_H.\]

Accordingly, the two branches cannot both have \(t_H\) proper signatures certifying a block for round \(r + 1\) in the same step \(s\). Moreover, since the selection probabilities for two steps \(s\) and \(s^\prime\) are the same and the selections are independent, also with overwhelming probability

\[|HSV^{r+1,s}_{1;B_r}| + |MSV^{r+1,s}_{1;B_r}| + |HSV^{r+1,s^\prime}_{1;B^r_\epsilon}| + |MSV^{r+1,s^\prime}_{1;B^r_\epsilon}| < 2t_H,\]

for any two steps \(s\) and \(s^\prime\). When \(F = 10^{-18}\), by the union bound, as long as the Adversary cannot partition the honest users for a long time (say \(10^4\) steps, which is more than 55 hours with \(\lambda = 10\) seconds26), with high probability (say \(1 - 10^{-10}\)) at most one branch will have \(t_H\) proper signatures to certify a block in round \(r + 1\). Finally, if the physical partition has created two parts with roughly the same size, then the probability that \(|HSV^{r,s}_i| + |MSV^{r,s}_i| \geq t_H\) is small for each part \(i\). Following a similar analysis, even if the Adversary manages to create a fork with some non-negligible probability in each part for round \(r\), at most one of the four branches may grow in round \(r + 1\). 10.2 Adversarial Partition Second of all, the partition may be caused by the Adversary, so that the messages propagated by the honest users in one part will not reach the honest users in the other part directly, but the Adversary is able to forward messages between the two parts. Still, once a message from one part reaches an honest user in the other part, it will be propagated in the latter as usual. If the Adversary is willing to spend a lot of money, it is conceivable that he may be able to hack the Internet and partition it like this for a while. The analysis is similar to that for the larger part in the physical partition above (the smaller part can be considered as having population 0): the Adversary may be able to create a fork and each honest user only sees one of the branches, but at most one branch may grow. 10.3 Network Partitions in Sum Although network partitions can happen and a fork in one round may occur under partitions, there is no lingering ambiguity: a fork is very short-lived, and in fact lasts for at most a single round. In all parts of the partition except for at most one, the users cannot generate a new block and thus (a) realize there is a partition in the network and (b) never rely on blocks that will "vanish". Acknowledgements We would like to first acknowledge Sergey Gorbunov, coauthor of the cited Democoin system. Most sincere thanks go to Maurice Herlihy, for many enlightening discussions, for pointing out that pipelining will improve Algorand's throughput performance, and for greatly improving the 26Note that a user finishes a step \(s\) without waiting for \(2\lambda\) time only if he has seen at least \(t_H\) signatures for the same message. When there are not enough signatures, each step will last for \(2\lambda\) time.

exposition of an earlier version of this paper. Many thanks to Sergio Rajsbaum, for his comments on an earlier version of this paper. Many thanks to Vinod Vaikuntanathan, for several deep discussions and insights. Many thanks to Yossi Gilad, Rotem Hamo, Georgios Vlachos, and Nickolai Zeldovich for starting to test these ideas, and for many helpful comments and discussions. Silvio Micali would like to personally thank Ron Rivest for innumerable discussions and guidance in cryptographic research over more than 3 decades, for coauthoring the cited micropayment system that has inspired one of the verifier selection mechanisms of Algorand. We hope to bring this technology to the next level. Meanwhile the travel and companionship are great fun, for which we are very grateful.

Lidando com partições de rede

Como dito, assumimos que os tempos de propagação das mensagens entre todos os usuários da rede são limitados por \(\lambda\) e Λ. Esta não é uma suposição forte, já que a Internet de hoje é rápida e robusta, e os valores reais desses parâmetros são bastante razoáveis. Aqui, vamos ressaltar que Algorand ′ 2 continua a funcionar mesmo que a Internet ocasionalmente seja dividida em duas partes. O caso quando a Internet é dividida em mais de duas partes de maneira semelhante. 10.1 Partições Físicas Em primeiro lugar, a partição pode ser causada por motivos físicos. Por exemplo, um grande terremoto pode acabarão por quebrar completamente a ligação entre a Europa e a América. Neste caso, o usuários mal-intencionados também são particionados e não há comunicação entre as duas partes. Assim

haverá dois Adversários, um para a parte 1 e outro para a parte 2. Cada Adversário ainda tenta quebrar o protocolo em sua própria parte. Suponha que a partição aconteça no meio da rodada r. Então cada usuário ainda é selecionado como um verificador baseado em PKr−k, com a mesma probabilidade de antes. Deixe HSV r,s eu e MSV r,s eu respectivamente seja o conjunto de verificadores honestos e maliciosos em uma etapa s da parte i \(\in\){1, 2}. Nós temos |HSV r,s 1 | + |MSV r,s 1 | + |HSV r,s 2 | + |MSV r,s 2 | = |HSV r,s| + |MSV r,s|. Observe que |HSV r,s| + |MSV r,s| < |HSV r,s| + 2|MSV r,s| < 2tH com probabilidade esmagadora. Se alguma parte i tiver |HSV r,s eu | + |MSV r,s eu | \(\geq\)tH com probabilidade não desprezível, por exemplo, 1%, então o probabilidade de que |HSV r,s 3−eu| + |MSV r,s 3−eu| \(\geq\)tH é muito baixo, por exemplo, 10−16 quando F = 10−18. Neste caso, podemos muito bem tratar a parte menor como estando off-line, porque não haverá verificadores suficientes em esta parte para gerar as assinaturas para certificar um bloco. Consideremos a parte maior, digamos a parte 1, sem perda de generalidade. Embora |HSV r,s| < tH com probabilidade desprezível em cada passo s, quando a rede é particionada, |HSV r,s 1 | pode ser menor que tH com alguma probabilidade não desprezível. Neste caso o Adversário pode, com alguma outra probabilidade não desprezível, forçar o protocolo BA binário em uma bifurcação na rodada r, com um bloco não vazio Br e o bloco vazio Br ǫ ambos com assinaturas válidas.25 Por exemplo, em um Coin-Fixed-To-0 step s, todos os verificadores em HSV r,s 1 assinado para o bit 0 e H(Br), e propagou seus mensagens. Todos os verificadores em MSV r,s 1 também assinaram 0 e H(Br), mas retiveram suas mensagens. Porque |HSV r,s 1 | + |MSV r,s 1 | \(\geq\)tH, o sistema possui assinaturas suficientes para certificar o Br. No entanto, desde o verificadores maliciosos retiveram suas assinaturas, os usuários entram na etapa s + 1, que é uma etapa Coin-Fixed-To1. Porque |HSV r,s 1 | < tH devido à partição, os verificadores em HSV r,s+1 1 não vi assinaturas para o bit 0 e todas assinadas para o bit 1. Todos os verificadores em MSV r,s+1 1 fez o mesmo. Porque |HSV r,s+1 1 | + |MSV r,s+1 1 | \(\geq\)tH, o sistema possui assinaturas suficientes para certificar Br ǫ. O Adversário em seguida, cria uma bifurcação liberando as assinaturas do MSV r,s 1 para 0 e H(Br). Assim, haverá dois Qr’s, definidos pelos blocos correspondentes da rodada r. No entanto, a bifurcação não continuará e apenas um dos dois ramos poderá crescer na rodada r + 1. Instruções adicionais para Algorand ′ 2. Ao ver um bloco não vazio Br e o bloco vazio bloco BR ǫ , segue o não vazio (e o Qr definido por ele). Na verdade, ao instruir os usuários a usarem o bloco não vazio no protocolo, se um grande quantidade de usuários honestos em PKr+1−k percebem que há uma bifurcação no início da rodada r +1, então o o bloco vazio não terá seguidores suficientes e não crescerá. Suponha que o adversário consiga particionar os usuários honestos para que alguns usuários honestos vejam Br (e talvez Br ǫ), e alguns só veem irmão ǫ. Porque o Adversário não pode dizer qual deles será um verificador seguindo Br e qual será um verificador seguindo o Ir. ǫ , os usuários honestos são particionados aleatoriamente e cada um deles ainda torna-se um verificador (seja em relação a Br ou em relação a Br ǫ) em uma etapa s > 1 com probabilidade pág. Para os usuários mal-intencionados, cada um deles pode ter duas chances de se tornar um verificador, uma com Br e outro com Br ǫ, cada um com probabilidade p independentemente. Seja HSV r+1,s 1;Br seja o conjunto de verificadores honestos nas etapas s da rodada r+1 após Br. Outras notações como HSV r+1,s 1;Brǫ , MSV r+1,s 1;Br e MSV r+1,s 1;Brǫ são definidos de forma semelhante. Por Chernoffbound, é fácil 25Ter uma bifurcação com dois blocos não vazios não é possível com ou sem partições, exceto com partições insignificantes probabilidade.ver isso com uma probabilidade esmagadora, |HSV r+1,s 1;Br | + |HSV r+1,s 1;Brǫ | + |MSV r+1,s 1;Br | + |MSV r+1,s 1;Brǫ | < 2tH. Conseqüentemente, as duas filiais não podem ter ambas as assinaturas adequadas certificando um bloco para rodada r + 1 na mesma etapa s. Além disso, uma vez que as probabilidades de seleção para duas etapas s e s′ são as iguais e as seleções são independentes, também com probabilidade esmagadora |HSV r+1,s 1;Br | + |MSV r+1,s 1;Br | + |HSV r+1,s′ 1;Brǫ | + |MSV r+1,s′ 1;Brǫ | < 2tH, para quaisquer duas etapas s e s′. Quando F = 10−18, pelo sindicato, desde que o Adversário não possa particionar os usuários honestos por um longo tempo (digamos 104 etapas, o que equivale a mais de 55 horas com \(\lambda\) = 10 segundos26), com alta probabilidade (digamos 1−10−10) no máximo uma ramificação terá as assinaturas adequadas para certificar um bloco na rodada r + 1. Finalmente, se a partição física criou duas partes com aproximadamente o mesmo tamanho, então o probabilidade de que |HSV r,s eu | + |MSV r,s eu | \(\geq\)tH é pequeno para cada parte i. Seguindo uma análise semelhante, mesmo que o Adversário consiga criar uma bifurcação com alguma probabilidade não desprezível em cada parte para a rodada r, no máximo um dos quatro ramos pode crescer na rodada r + 1. 10.2 Partição Adversária Em segundo lugar, a partição pode ser causada pelo Adversário, de modo que as mensagens propagadas pelos usuários honestos de uma parte não alcançará diretamente os usuários honestos da outra parte, mas o Adversário é capaz de encaminhar mensagens entre as duas partes. Ainda assim, uma vez que uma mensagem de um parte chega a um usuário honesto na outra parte, será propagada nesta última como de costume. Se o O adversário está disposto a gastar muito dinheiro, é concebível que ele consiga hackear o Internet e particione-o assim por um tempo. A análise é semelhante à da parte maior da partição física acima (a parte menor parte pode ser considerada como tendo população 0): o Adversário pode ser capaz de criar uma bifurcação e cada usuário honesto vê apenas um dos ramos, mas no máximo um ramo pode crescer. 10.3 Partições de rede em soma Embora possam ocorrer partições de rede e uma bifurcação em uma rodada possa ocorrer nas partições, não há ambigüidade persistente: um garfo dura muito pouco e, na verdade, dura no máximo uma única rodada. Em todas as partes da partição, exceto no máximo uma, os usuários não podem gerar um novo bloco e, portanto, (a) perceber que há uma partição na rede e (b) nunca confiar em blocos que irão “desaparecer”. Agradecimentos Gostaríamos de agradecer primeiro a Sergey Gorbunov, co-autor do citado sistema Democoin. Os mais sinceros agradecimentos a Maurice Herlihy, pelas muitas discussões esclarecedoras, por apontar que o pipelining melhorará o desempenho da taxa de transferência de Algorand e melhorará muito o 26Observe que um usuário termina uma etapa s sem esperar pelo tempo 2\(\lambda\) somente se ele tiver visto pelo menos as assinaturas para o mesma mensagem. Quando não há assinaturas suficientes, cada etapa durará 2\(\lambda\).

exposição de uma versão anterior deste artigo. Muito obrigado a Sergio Rajsbaum, pelos seus comentários sobre uma versão anterior deste artigo. Muito obrigado a Vinod Vaikuntanathan, por várias discussões profundas e percepções. Muito obrigado a Yossi Gilad, Rotem Hamo, Georgios Vlachos e Nickolai Zeldovich por começar a testar essas ideias e por muitos comentários e discussões úteis. Silvio Micali gostaria de agradecer pessoalmente a Ron Rivest pelas inúmeras discussões e orientações em pesquisa criptográfica ao longo de mais de 3 décadas, pela coautoria do sistema de micropagamento citado que inspirou um dos mecanismos de seleção de verificadores de Algorand. Esperamos levar esta tecnologia para o próximo nível. Enquanto isso a viagem e o companheirismo são muito divertidos, pelos quais estamos muito gratos.