Avalanche: uma nova família de protocolos de consenso

Avalanche Platform Whitepaper

作者 Team Rocket and Emin Gün Sirer · 2018

🇺🇸 English (原文)

🇧🇷 Português (译文)

Abstract

Avalanche Platform 2020/06/30 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer Abstract. This paper provides an architectural overview of the ﬁrst release of the Avalanche platform, codenamed Avalanche Borealis. For details on the economics of the native token, labeled $AVAX, we 5 guide the reader to the accompanying token dynamics paper [2]. Disclosure: The information described in this paper is preliminary and subject to change at any time. Furthermore, this paper may contain “forward-looking statements.”1 Git Commit: 7497e4a4ba0a1ea2dc2a111bc6deefbf3023708e 1 Introduction 10 This paper provides an architectural overview of the Avalanche platform. The key focus is on the three key diﬀerentiators of the platform: the engine, the architectural model, and the governance mechanism. 1.1 Avalanche Goals and Principles Avalanche is a high-performance, scalable, customizable, and secure blockchain platform. It targets three broad use cases: 15 – Building application-speciﬁc blockchains, spanning permissioned (private) and permissionless (public) deployments. – Building and launching highly scalable and decentralized applications (Dapps). – Building arbitrarily complex digital assets with custom rules, covenants, and riders (smart assets). 1 Forward-looking statements generally relate to future events or our future performance. This includes, but is not limited to, Avalanche’s projected performance; the expected development of its business and projects; execution of its vision and growth strategy; and completion of projects that are currently underway, in development or otherwise under consideration. Forward-looking statements represent our management’s beliefs and assumptions only as of the date of this presentation. These statements are not guarantees of future performance and undue reliance should not be placed on them. Such forward-looking statements necessarily involve known and unknown risks, which may cause actual performance and results in future periods to diﬀer materially from any projections expressed or implied herein. Avalanche undertakes no obligation to update forward-looking statements. Although forward-looking statements are our best prediction at the time they are made, there can be no assurance that they will prove to be accurate, as actual results and future events could diﬀer materially. The reader is cautioned not to place undue reliance on forward-looking statements.

Resumo

Avalanche Plataforma 30/06/2020 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer Resumo. Este artigo fornece uma visão geral da arquitetura da primeira versão da plataforma Avalanche, codinome Avalanche Borealis. Para obter detalhes sobre a economia do nativo token, denominado $AVAX, nós 5 guie o leitor para o artigo de dinâmica token [2] que o acompanha. Divulgação: As informações descritas neste documento são preliminares e estão sujeitas a alterações a qualquer momento. Além disso, este documento pode conter “declarações prospectivas”.1 Confirmação do Git: 7497e4a4ba0a1ea2dc2a111bc6deefbf3023708e 1 Introdução 10 Este artigo fornece uma visão geral da arquitetura da plataforma Avalanche. O foco principal está nos três principais diferenciais da plataforma: o motor, o modelo arquitetônico e o mecanismo de governança. 1.1 Avalanche Metas e Princípios Avalanche é uma plataforma blockchain de alto desempenho, escalonável, personalizável e segura. Tem como alvo três amplos casos de uso: 15 – Construindo blockchains específicos do aplicativo, abrangendo com permissão (privado) e sem permissão (público) implantações. – Construir e lançar aplicativos altamente escaláveis e descentralizados (Dapps). – Construir ativos digitais arbitrariamente complexos com regras, acordos e acessórios personalizados (ativos inteligentes). 1 As declarações prospectivas geralmente estão relacionadas a eventos futuros ou ao nosso desempenho futuro. Isto inclui, mas não é limitado ao desempenho projetado de Avalanche; o desenvolvimento esperado dos seus negócios e projetos; execução da sua visão e estratégia de crescimento; e conclusão de projetos que estão atualmente em andamento, em desenvolvimento ou caso contrário, está em consideração. As declarações prospectivas representam as crenças e suposições de nossa administração somente a partir da data desta apresentação. Estas declarações não são garantias de desempenho futuro e não se deve confiar neles. Tais declarações prospectivas envolvem necessariamente riscos, que podem fazer com que o desempenho e os resultados reais em períodos futuros sejam materialmente diferentes de quaisquer projeções expressa ou implícita aqui. Avalanche não assume nenhuma obrigação de atualizar declarações prospectivas. Embora declarações prospectivas são nossa melhor previsão no momento em que são feitas, não pode haver garantia de que elas provará ser preciso, pois os resultados reais e eventos futuros podem diferir materialmente. O leitor é alertado para não confiar indevidamente em declarações prospectivas.

Introduction

10 This paper provides an architectural overview of the Avalanche platform. The key focus is on the three key diﬀerentiators of the platform: the engine, the architectural model, and the

Introdução

10 Este artigo fornece uma visão geral da arquitetura da plataforma Avalanche. O foco principal está nos três principais diferenciais da plataforma: o motor, o modelo arquitetônico e o

The Engine

60 Discussion of the Avalanche platform begins with the core component which powers the platform: the consensus engine. Background Distributed payments and – more generally – computation, require agreement between a set of machines. Therefore, consensus protocols, which enable a group of nodes to achieve agreement, lie at the heart of blockchains, as well as almost every deployed large-scale industrial distributed system. The topic 65 has received extensive scrutiny for almost ﬁve decades, and that eﬀort, to date, has yielded just two families of protocols: classical consensus protocols, which rely on all-to-all communication, and Nakamoto consensus, which relies on proof-of-work mining coupled with the longest-chain-rule. While classical consensus protocols can have low latency and high throughput, they do not scale to large numbers of participants, nor are they robust in the presence of membership changes, which has relegated them mostly to permissioned, mostly 70 static deployments. Nakamoto consensus protocols [5, 7, 4], on the other hand, are robust, but suﬀer from high conﬁrmation latencies, low throughput, and require constant energy expenditure for their security. The Snow family of protocols, introduced by Avalanche, combine the best properties of classical consensus protocols with the best of Nakamoto consensus. Based on a lightweight network sampling mechanism, they achieve low latency and high throughput without needing to agree on the precise membership of the 75 system. They scale well from thousands to millions of participants with direct participation in the consensus protocol. Further, the protocols do not make use of PoW mining, and therefore avoid its exorbitant energy expenditure and subsequent leak of value in the ecosystem, yielding lightweight, green, and quiescent protocols. Mechanism and Properties The Snow protocols operate by repeated sampling of the network. Each node 80 polls a small, constant-sized, randomly chosen set of neighbors, and switches its proposal if a supermajority supports a diﬀerent value. Samples are repeated until convergence is reached, which happens rapidly in normal operations. We elucidate the mechanism of operation via a concrete example. First, a transaction is created by a user and sent to a validating node, which is a node participating in the consensus procedure. It is then 85 propagated out to other nodes in the network via gossiping. What happens if that user also issues a conﬂicting

4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer transaction, that is, a doublespend? To choose amongst the conﬂicting transactions and prevent the doublespend, every node randomly selects a small subset of nodes and queries which of the conﬂicting transactions the queried nodes think is the valid one. If the querying node receives a supermajority response in favor of one transaction, then the node changes its own response to that transaction. Every node in the network 90 repeats this procedure until the entire network comes to consensus on one of the conﬂicting transactions. Surprisingly, while the core mechanism of operation is quite simple, these protocols lead to highly desirable system dynamics that make them suitable for large-scale deployment. – Permissionless, Open to Churn, and Robust. The latest slew of blockchain projects employ classical consensus protocols and therefore require full membership knowledge. Knowing the entire set of par95 ticipants is suﬃciently simple in closed, permissioned systems, but becomes increasingly hard in open, decentralized networks. This limitation imposes high security risks to existing incumbents employing such protocols. In contrast, Snow protocols maintain high safety guarantees even when there are wellquantiﬁed discrepancies between the network views of any two nodes. Validators of Snow protocols enjoy the ability to validate without continuous full membership knowledge. They are, therefore, robust 100 and highly suitable for public blockchains. – Scalable and Decentralized A core feature of the Snow family is its ability to scale without incurring fundamental tradeoﬀs. Snow protocols can scale to tens of thousands or millions of nodes, without delegation to subsets of validators. These protocols enjoy the best-in-class system decentralization, allowing every node to fully validate. First-hand continuous participation has deep implications for the security 105 of the system. In almost every proof-of-stake protocol that attempts to scale to a large participant set, the typical mode of operation is to enable scaling by delegating validation to a subcommittee. Naturally, this implies that the security of the system is now precisely as high as the corruption cost of the subcommittee. Subcommittees are furthermore subject to cartel formation. In Snow-type protocols, such delegation is not necessary, allowing every node operator to have a ﬁrst110 hand say in the system, at all times. Another design, typically referred to as state sharding, attempts to provide scalability by parallelizing transaction serialization to independent networks of validators. Unfortunately, the security of the system in such a design becomes only as high as the easiest corruptible independent shard. Therefore, neither subcommittee election nor sharding are suitable scaling strategies for crypto platforms. 115 – Adaptive. Unlike other voting-based systems, Snow protocols achieve higher performance when the adversary is small, and yet highly resilient under large attacks. – Asynchronously Safe. Snow protocols, unlike longest-chain protocols, do not require synchronicity to operate safely, and therefore prevent double-spends even in the face of network partitions. In Bitcoin, for example, if synchronicity assumption is violated, it is possible to operate to independent forks of the 120 Bitcoin network for prolonged periods of time, which would invalidate any transactions once the forks heal. – Low Latency. Most blockchains today are unable to support business applications, such as trading or daily retail payments. It is simply unworkable to wait minutes, or even hours, for conﬁrmation of transactions. Therefore, one of the most important, and yet highly overlooked, properties of consensus protocols is the 125 time to ﬁnality. Snow* protocols reach ﬁnality typically in ≤1 second, which is signiﬁcantly lower than both longest-chain protocols and sharded blockchains, both of which typically span ﬁnality to a matter of minutes.

Comparative chart between the three known families of consensus protocols: Classical, Nakamoto, and Snow/Avalanche

Avalanche Platform 2020/06/30 5 – High Throughput. Snow protocols, which can build a linear chain or a DAG, reach thousands of transactions per second (5000+ tps), while retaining full decentralization. New blockchain solutions that claim 130 high TPS typically trade oﬀdecentralization and security and opt for more centralized and insecure consensus mechanisms. Some projects report numbers from highly controlled settings, thus misreporting true performance results. The reported numbers for $AVAX are taken directly from a real, fully implemented Avalanche network running on 2000 nodes on AWS, geo-distributed across the globe on low-end machines. Higher performance results (10,000+) can be achieved through assuming higher bandwidth 135 provisioning for each node and dedicated hardware for signature veriﬁcation. Finally, we note that the aforementioned metrics are at the base-layer. Layer-2 scaling solutions immediately augment these results considerably. Comparative Charts of Consensus Table 1 describes the diﬀerences between the three known families of consensus protocols through a set of 8 critical axes. 140 Nakamoto Classical Snow Robust (Suitable for Open Settings) + - + Highly Decentralized (Allows Many Validators) + - + Low Latency and Quick Finality (Fast Transaction Conﬁrmation) - + + High Throughput (Allows Many Clients) - + + Lightweight (Low System Requirements) - + + Quiescent (Not Active When No Decisions Performed) - + + Safety Parameterizable (Beyond 51% Adversarial Presence) - - + Highly Scalable - - + Table 1. Comparative chart between the three known families of consensus protocols. Avalanche, Snowman, and Frosty all belong to the Snow* family.

O motor

Comparative chart between the three known families of consensus protocols: Classical, Nakamoto, and Snow/Avalanche

60 A discussão da plataforma Avalanche começa com o componente principal que alimenta a plataforma: o mecanismo de consenso. Contexto Os pagamentos distribuídos e – mais geralmente – a computação, exigem acordo entre um conjunto de máquinas. Portanto, os protocolos de consenso, que permitem a um grupo de nós chegar a um acordo, estão no coração de blockchains, bem como quase todos os sistemas distribuídos industriais de grande escala implantados. O tópico 65 recebeu amplo escrutínio por quase cinco décadas, e esse esforço, até o momento, rendeu apenas duas famílias de protocolos: protocolos de consenso clássicos, que dependem da comunicação de todos para todos, e consenso de Nakamoto, que depende da mineração proof-of-work juntamente com a regra da cadeia mais longa. Embora os protocolos de consenso clássicos podem ter baixa latência e alto rendimento, eles não se adaptam a um grande número de participantes, nem são robusto na presença de mudanças de membros, o que os relegou principalmente a permissões, principalmente 70 implantações estáticas. Os protocolos de consenso de Nakamoto [5, 7, 4], por outro lado, são robustos, mas sofrem de altas latências de confirmação, baixo rendimento e exigem gasto constante de energia para sua segurança. A família de protocolos Snow, introduzida por Avalanche, combina as melhores propriedades dos protocolos de consenso clássicos com o melhor do consenso de Nakamoto. Com base em um mecanismo leve de amostragem de rede, eles alcançam baixa latência e alto rendimento sem a necessidade de concordar com a composição precisa do 75 sistema. Eles variam de milhares a milhões de participantes com participação direta no protocolo de consenso. Além disso, os protocolos não fazem uso da mineração PoW e, portanto, evitam sua exorbitante gasto de energia e subsequente vazamento de valor no ecossistema, produzindo energia leve, verde e inativa protocolos. Mecanismo e propriedades Os protocolos Snow operam por amostragem repetida da rede. Cada nó 80 pesquisa um conjunto pequeno, de tamanho constante e escolhido aleatoriamente de vizinhos e muda sua proposta se uma maioria absoluta suporta um valor diferente. As amostras são repetidas até que a convergência seja alcançada, o que acontece rapidamente em operações normais. Elucidamos o mecanismo de operação através de um exemplo concreto. Primeiro, uma transação é criada por um usuário e enviado para um nó de validação, que é um nó participante do procedimento de consenso. É então 85 propagado para outros nós da rede por meio de fofoca. O que acontece se esse usuário também emitir uma mensagem conflitante4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer transação, ou seja, um gasto duplo? Para escolher entre as transações conflitantes e evitar o gasto duplo, cada nó seleciona aleatoriamente um pequeno subconjunto de nós e consulta quais das transações conflitantes os nós consultados acham que é o válido. Se o nó de consulta receber uma resposta majoritária a favor de uma transação, então o nó altera sua própria resposta a essa transação. Cada nó da rede 90 repete esse procedimento até que toda a rede chegue a um consenso sobre uma das transações conflitantes. Surpreendentemente, embora o mecanismo central de operação seja bastante simples, esses protocolos levam a resultados altamente dinâmica de sistema desejável que os torna adequados para implantação em larga escala. – Sem permissão, aberto à rotatividade e robusto. A última série de projetos blockchain empregam clássicos protocolos de consenso e, portanto, exigem pleno conhecimento dos membros. Conhecendo todo o conjunto do par95 participantes é suficientemente simples em sistemas fechados e autorizados, mas torna-se cada vez mais difícil em sistemas abertos e redes descentralizadas. Esta limitação impõe elevados riscos de segurança aos operadores existentes que empregam tais protocolos. Em contraste, os protocolos Snow mantêm altas garantias de segurança mesmo quando há discrepâncias bem quantificadas entre as visualizações de rede de dois nós quaisquer. Validadores de protocolos Snow aproveite a capacidade de validar sem conhecimento completo e contínuo de associação. São, portanto, robustos 100 e altamente adequado para blockchains públicos. – Escalável e Descentralizada Uma característica central da família Snow é sua capacidade de escalar sem incorrer em compensações fundamentais. Os protocolos Snow podem ser dimensionados para dezenas de milhares ou milhões de nós, sem delegação a subconjuntos de validators. Esses protocolos desfrutam da melhor descentralização de sistema da categoria, permitindo cada nó para validar totalmente. A participação contínua em primeira mão tem implicações profundas para a segurança 105 do sistema. Em quase todos os protocolos proof-of-stake que tentam escalar para um grande conjunto de participantes, o modo típico de operação é permitir o escalonamento delegando a validação a um subcomitê. Naturalmente, isto implica que a segurança do sistema é agora precisamente tão elevada quanto o custo da corrupção do subcomitê. Além disso, os subcomités estão sujeitos à formação de cartéis. Nos protocolos do tipo Snow, tal delegação não é necessária, permitindo que cada operador do nó tenha um primeiro110 dizer manualmente no sistema, em todos os momentos. Outro design, normalmente chamado de fragmentação de estado, tenta para fornecer escalabilidade paralelizando a serialização de transações para redes independentes de validators. Infelizmente, a segurança do sistema em tal projeto torna-se apenas tão alta quanto o mais fácil de ser corrompido. fragmento independente. Portanto, nem a eleição do subcomitê nem a fragmentação são estratégias de escalonamento adequadas para plataformas criptográficas. 115 – Adaptativo. Ao contrário de outros sistemas baseados em votação, os protocolos Snow alcançam maior desempenho quando o O adversário é pequeno e, ainda assim, altamente resiliente sob grandes ataques. – Assincronamente seguro. Os protocolos Snow, diferentemente dos protocolos de cadeia mais longa, não exigem sincronicidade para operar com segurança e, portanto, evitar gastos duplos, mesmo diante de partições de rede. Em Bitcoin, por exemplo, se a suposição de sincronicidade for violada, é possível operar para bifurcações independentes do 120 Bitcoin rede por períodos prolongados de tempo, o que invalidaria qualquer transação uma vez que os forks curar. – Baixa latência. A maioria dos blockchains hoje não são capazes de oferecer suporte a aplicativos de negócios, como negociação ou pagamentos de varejo. É simplesmente impraticável esperar minutos, ou mesmo horas, pela confirmação das transações. Portanto, uma das propriedades mais importantes, e ainda assim altamente negligenciadas, dos protocolos de consenso é a 125 tempo para a finalidade. Os protocolos Snow atingem a finalização normalmente em ≤1 segundo, o que é significativamente menor do que protocolos de cadeia mais longa e blockchains fragmentados, ambos os quais normalmente abrangem a finalidade de um assunto de minutos.Avalanche Plataforma 30/06/2020 5 – Alto rendimento. Os protocolos Snow, que podem construir uma cadeia linear ou um DAG, alcançam milhares de transações por segundo (mais de 5.000 tps), mantendo a descentralização total. Novas soluções blockchain que afirmam 130 alto TPS normalmente negocia descentralização e segurança e opta por sistemas mais centralizados e inseguros mecanismos de consenso. Alguns projetos relatam números provenientes de ambientes altamente controlados, reportando assim verdadeiros resultados de desempenho. Os números relatados para $AVAX são obtidos diretamente de uma rede Avalanche real e totalmente implementada, executada em 2.000 nós na AWS, distribuída geograficamente em todo o mundo em redes de baixo custo. máquinas. Resultados de desempenho mais altos (10.000+) podem ser alcançados assumindo maior largura de banda 135 provisionamento para cada nó e hardware dedicado para verificação de assinatura. Por fim, notamos que o as métricas mencionadas acima estão na camada base. As soluções de escalonamento da camada 2 aumentam imediatamente esses resultados consideravelmente. Gráficos Comparativos de Consenso A Tabela 1 descreve as diferenças entre as três famílias conhecidas de protocolos de consenso através de um conjunto de 8 eixos críticos. 140 Nakamoto Clássico Neve Robusto (adequado para configurações abertas) + - + Altamente descentralizado (permite muitos validadores) + - + Baixa latência e finalização rápida (confirmação rápida de transação) - + + Alto rendimento (permite muitos clientes) - + + Leve (baixos requisitos de sistema) - + + Quiescente (não ativo quando nenhuma decisão é executada) - + + Segurança parametrizável (além de 51% de presença adversária) - - + Altamente escalável - - + Tabela 1. Gráfico comparativo entre as três famílias conhecidas de protocolos de consenso. Avalanche, boneco de neve e Todos Frosty pertencem à família Snow.

Platform Overview

In this section, we provide an architectural overview of the platform and discuss various implementation details. The Avalanche platform cleanly separates three concerns: chains (and assets built on top), execution environments, and deployment. 3.1 Architecture 145 Subnetworks A subnetwork, or subnet, is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by one subnet, and a subnet can validate arbitrarily many blockchains. A validator may be a member of arbitrarily many subnets. A subnet decides who may enter it, and may require that its constituent validators have certain properties. The Avalanche platform supports the creation and operation of arbitrarily many subnets. In order to create a new subnet 150 or to join a subnet, one must pay a fee denominated in $AVAX.

6 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer The subnet model oﬀers a number of advantages: – If a validator doesn’t care about the blockchains in a given subnet, it will simply not join that subnet. This reduces network traﬃc, as well as the computational resources required of validators. This is in contrast to other blockchain projects, in which every validator must validate every transaction, even 155 those they don’t care about. – Since subnets decide who may enter them, one can create private subnets. That is, each blockchain in the subnet is validated only by a set of trusted validators. – One can create a subnet where each validator has certain properties. For example, one could create a subnet where each validator is located in a certain jurisdiction, or where each validator is bound by some 160 real-world contract. This may be beniﬁcial for compliance reasons. There is one special subnet called the Default Subnet. It is validated by all validators. (That is, in order to validate any subnet, one must also validate the Default Subnet.) The Default Subnet validates a set of pre-deﬁned blockchains, including the blockchain where $AVAX lives and is traded. Virtual Machines Each blockchain is an instance of a Virtual Machine (VM.) A VM is a blueprint for a 165 blockchain, much like a class is a blueprint for an object in an object-oriented programming language. The interface, state and behavior of a blockchain is deﬁned by the VM that the blockchain runs. The following properties of a blockchain, and other, are deﬁned by a VM: – The contents of a block – The state transition that occurs when a block is accepted 170 – The APIs exposed by the blockchain and their endpoints – The data that is persisted to disk We say that a blockchain “uses” or “runs” a given VM. When creating a blockchain, one speciﬁes the VM it runs, as well as the genesis state of the blockchain. A new blockchain can be created using a pre-existing VM, or a developer can code a new one. There can be arbitrarily many blockchains that run the same VM. 175 Each blockchain, even those running the same VM, is logically independent from others and maintains its own state. 3.2 Bootstrapping The ﬁrst step in participating in Avalanche is bootstrapping. The process occurs in three stages: connection to seed anchors, network and state discovery, and becoming a validator. 180 Seed Anchors Any networked system of peers that operates without a permissioned (i.e. hard-coded) set of identities requires some mechanism for peer discovery. In peer-to-peer ﬁle sharing networks, a set of trackers are used. In crypto networks, a typical mechanism is the use of DNS seed nodes (which we refer

Avalanche Platform 2020/06/30 7 to as seed anchors), which comprise a set of well-deﬁned seed-IP addresses from which other members of the network can be discovered. The role of DNS seed nodes is to provide useful information about the set 185 of active participants in the system. The same mechanism is employed in Bitcoin Core [1], wherein the src/chainparams.cpp ﬁle of the source code holds a list of hard-coded seed nodes. The diﬀerence between BTC and Avalanche is that BTC requires just one correct DNS seed node, while Avalanche requires a simple majority of the anchors to be correct. As an example, a new user may choose to bootstrap the network view through a set of well established and reputable exchanges, any one of which individually are not trusted. 190 We note, however, that the set of bootstrap nodes does not need to be hard-coded or static, and can be provided by the user, though for ease of use, clients may provide a default setting that includes economically important actors, such as exchanges, with which clients wish to share a world view. There is no barrier to become a seed anchor, therefore a set of seed anchors can not dictate whether a node may or may not enter the network, since nodes can discover the latest network of Avalanche peers by attaching to any set of seed 195 anchors. Network and State Discovery Once connected to the seed anchors, a node queries for the latest set of state transitions. We call this set of state transitions the accepted frontier. For a chain, the accepted frontier is the last accepted block. For a DAG, the accepted frontier is the set of vertices that are accepted, yet have no accepted children. After collecting the accepted frontiers from the seed anchors, the state transitions that 200 are accepted by a majority of the seed anchors is deﬁned to be accepted. The correct state is then extracted by synchronizing with the sampled nodes. As long as there is a majority of correct nodes in the seed anchor set, then the accepted state transitions must have been marked as accepted by at least one correct node. This state discovery process is also used for network discovery. The membership set of the network is deﬁned on the validator chain. Therefore, synchronizing with the validator chain allows the node to discover 205 the current set of validators. The validator chain will be discussed further in the next section. 3.3 Sybil Control and Membership Consensus protocols provide their security guarantees under the assumption that up to a threshold number of members in the system could be adversarial. A Sybil attack, wherein a node cheaply ﬂoods the network with malicious identities, can trivially invalidate these guarantees. Fundamentally, such an attack can only be 210 deterred by trading oﬀpresence with proof of a hard-to-forge resource [3]. Past systems have explored the use of Sybil deterrence mechanisms that span proof-of-work (PoW), proof-of-stake (PoS), proof-of-elapsed-time (POET), proof-of-space-and-time (PoST), and proof-of-authority (PoA). At their core, all of these mechanisms serve an identical function: they require that each participant have some “skin in the game” in the form of some economic commitment, which in turn provides an economic 215 barrier against misbehavior by that participant. All of them involve a form of stake, whether it is in the form of mining rigs and hash power (PoW), disk space (PoST), trusted hardware (POET), or an approved identity (PoA). This stake forms the basis of an economic cost that participants must bear to acquire a voice. For instance, in Bitcoin, the ability to contribute valid blocks is directly proportional to the hash-power of the proposing participant. Unfortunately, there has also been substantial confusion between consensus protocols

8 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer versus Sybil control mechanisms. We note that the choice of consensus protocols is, for the most part, orthogonal to the choice of the Sybil control mechanism. This is not to say that Sybil control mechanisms are drop-in-replacements for each other, since a particular choice might have implications about the underlying guarantees of the consensus protocol. However, the Snow* family can be coupled with many of these known mechanisms, without signiﬁcant modiﬁcation. 225 Ultimately, for security and to ensure that the incentives of participants are aligned for the beneﬁt of the network, $AVAX choose PoS to the core Sybil control mechanism. Some forms of stake are inherently centralized: mining rig manufacturing (PoW), for instance, is inherently centralized in the hands of a few people with the appropriate know-how and access to the dozens of patents required for competitive VLSI manufacturing. Furthermore, PoW mining leaks value due to the large yearly miner subsidies. Similarly, 230 disk space is most abundantly owned by large datacenter operators.Further, all sybil control mechanisms that accrue ongoing costs, e.g. electricity costs for hashing, leak value out of the ecosystem, not to mention destroy the environment. This, in turn, reduces the feasibility envelope for the token, wherein an adverse price move over a small time frame can render the system inoperable. Proof-of-work inherently selects for miners who have the connections to procure cheap electricity, which has little to do with the miners’ ability 235 to serialize transactions or their contributions to the overall ecosystem. Among these options, we choose proof-of-stake, because it is green, accessible, and open to all. We note, however, that while the $AVAX uses PoS, the Avalanche network enables subnets to be launched with PoW and PoS. Staking is a natural mechanism for participation in an open network because it enables a direct economic argument: the probability of success of an attack is directly proportional to a well-deﬁned monetary cost 240 function. In other words, the nodes that stake are economically motivated to not engage in behavior that might hurt the value of their stake. Additionally, this stake does not incur any additional upkeep costs (other then the opportunity cost of investing in another asset), and has the property that, unlike mining equipment, is fully consumed if used in a catastrophic attack. For PoW operations, mining equipment can be simply reused or – if the owner decides to – entirely sold back to the market. 245 A node wishing to enter the network can freely do so by ﬁrst putting up a stake that is immobilized during the duration of participation in the network. The user determines the amount duration of the stake. Once accepted, a stake cannot be reverted. The main goal is to ensure that nodes substantially share the same mostly stable view of the network. We anticipate setting the minimum staking time on the order of a week. 250 Unlike other systems that also propose a PoS mechanism, $AVAX does not make usage of slashing, and therefore all stake is returned when the staking period expires. This prevents unwanted scenarios such as a client software or hardware failure leading to a loss of coins. This dovetails with our design philosophy of building predictable technology: the staked tokens are not at risk, even in the presence of software or hardware ﬂaws. 255 In Avalanche, a node that wants to participate issues a special stake transaction to the validator chain. Staking transactions name an amount to stake, the staking key of the participant that is staking, the duration, and the time that validation will start. Once the transaction is accepted, the funds will be locked until the end of the staking period. The minimal allowed amount is decided and enforced by the system. The stake amount placed by a participant has implications for both the amount of inﬂuence the participant has in the

Avalanche Platform 2020/06/30 9 consensus process, as well as the reward, as discussed later. The speciﬁed staking duration, must be between δmin and δmax, the minimum and maximum timeframes for which any stake can be locked. As with the staking amount, the staking period also has implications for the reward in the system. Loss or theft of the staking key cannot lead to asset loss, as the staking key is used only in the consensus process, not for asset transfer. 265 3.4 Smart Contracts in $AVAX At launch Avalanche supports standard Solidity-based smart contracts through the Ethereum virtual machine (EVM). We envision that the platform will support a richer and more powerful set of smart contract tools, including: – Smart contracts with oﬀ-chain execution and on-chain veriﬁcation. 270 – Smart contracts with parallel execution. Any smart contracts that do not operate on the same state in any subnet in Avalanche will be able to execute in parallel. – An improved Solidity, called Solidity++. This new language will support versioning, safe mathematics and ﬁxed point arithmetic, an improved type system, compilation to LLVM, and just-in-time execution. If a developer requires EVM support but wants to deploy smart contracts in a private subnet, they 275 can spin-up a new subnet directly. This is how Avalanche enables functionality-speciﬁc sharding through the subnets. Furthermore, if a developer requires interactions with the currently deployed Ethereum smart contracts, they can interact with the Athereum subnet, which is a spoon of Ethereum. Finally, if a developer requires a diﬀerent execution environment from the Ethereum virtual machine, they may choose to deploy their smart contract through a subnet that implements a diﬀerent execution environment, such as DAML 280 or WASM. Subnets can support additional features beyond VM behavior. For example, subnets can enforce performance requirements for bigger validator nodes that hold smart contracts for longer periods of time, or validators that hold contract state privately. 4 Governance and The $AVAX Token 4.1 The $AVAX Native Token 285 Monetary Policy The native token, $AVAX, is capped-supply, where the cap is set at 720, 000, 000 tokens, with 360, 000, 000 tokens available on mainnet launch. However, unlike other capped-supply tokens which bake the rate of minting perpetually, $AVAX is designed to react to changing economic conditions. In particular, the objective of $AVAX’s monetary policy is to balance the incentives of users to stake the token versus using it to interact with the variety of services available on the platform. Participants in the platform 290 collectively act as a decentralized reserve bank. The levers available on Avalanche are staking rewards, fees, and airdrops, all of which are inﬂuenced by governable parameters. Staking rewards are set by on-chain governance, and are ruled by a function designed to never surpass the capped supply. Staking can be induced by increasing fees or increasing staking rewards. On the other hand, we can induce increased engagement with the Avalanche platform services by lowering fees, and decreasing the staking reward.

10 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer Uses Payments True decentralized peer-to-peer payments are largely an unrealized dream for the industry due to the current lack of performance from incumbents. $AVAX is as powerful and easy to use as payments using Visa, allowing thousands of transactions globally every second, in a fully trustless, decentralized manner. Furthermore, for merchants worldwide, $AVAX provides a direct value proposition over Visa, namely lower 300 fees. Staking: Securing the System On the Avalanche platform, sybil control is achieved via staking. In order to validate, a participant must lock up coins, or stake. Validators, sometimes referred to as stakers, are compensated for their validation services based on staking amount and staking duration, amongst other properties. The chosen compensation function should minimize variance, ensuring that large stakers do not 305 disproportionately receive more compensation. Participants are also not subject to any “luck” factors, as in PoW mining. Such a reward scheme also discourages the formation of mining or staking pools enabling truly decentralized, trustless participation in the network. Atomic swaps Besides providing the core security of the system, the $AVAX token serves as the universal unit of exchange. From there, the Avalanche platform will be able to support trustless atomic swaps natively on 310 the platform enabling native, truly decentralized exchanges of any type of asset directly on Avalanche. 4.2 Governance Governance is critical to the development and adoption of any platform because – as with all other types of systems – Avalanche will also face natural evolution and updates. $AVAX provides on-chain governance for critical parameters of the network where participants are able to vote on changes to the network and 315 settle network upgrade decisions democratically. This includes factors such as the minimum staking amount, minting rate, as well as other economic parameters. This enables the platform to eﬀectively perform dynamic parameter optimization through a crowd oracle. However, unlike some other governance platforms out there, Avalanche does not allow unlimited changes to arbitrary aspects of the system. Instead, only a pre-determined number of parameters can be modiﬁed via governance, rendering the system more predictable 320 and increasing safety. Further, all governable parameters are subject to limits within speciﬁc time bounds, introducing hysteresis, and ensuring that the system remains predictable over short time ranges. A workable process for ﬁnding globally acceptable values for system parameters is critical for decentralized systems without custodians. Avalanche can use its consensus mechanism to build a system that allows anyone to propose special transactions that are, in essence, system-wide polls. Any participating node may 325 issue such proposals. Nominal reward rate is an important parameter that aﬀects any currency, whether digital or ﬁat. Unfortunately, cryptocurrencies that ﬁx this parameter might face various issues, including deﬂation or inﬂation. To that end, the nominal reward rate is subject to governance, within pre-established boundaries. This will allow token holders to choose on whether $AVAX is eventually capped, uncapped, or even deﬂationary.

Key non-consensus governable parameters used in the Avalanche platform including staking and fee settings

Avalanche Platform 2020/06/30 11 Transaction fees, denoted by the set F, are also subject to governance. F is eﬀectively a tuple which describes the fees associated with the various instructions and transactions. Finally, staking times and amounts are also governable. The list of these parameters is deﬁned in Figure 1. – $\Delta$: Staking amount, denominated in AVAX. This value deﬁnes the minimal stake required to be placed as bond before participating in the system. – $\delta_{\min}$: The minimal amount of time required for a node to stake into the system. – $\delta_{\max}$: The maximal amount of time a node can stake. – $\rho : (\pi\Delta, \tau\delta_{\min}) \rightarrow \mathbb{R}$: Reward rate function, also referred to as minting rate, determines the reward a participant can claim as a function of their staking amount given some number of $\pi$ publicly disclosed nodes under its ownership, over a period of $\tau$ consecutive $\delta_{\min}$ timeframes, such that $\tau\delta_{\min} \leq \delta_{\max}$. – F : the fee structure, which is a set of governable fees parameters that specify costs to various transactions. Fig. 1. Key non-consensus parameters used in Avalanche. All notation is redeﬁned upon ﬁrst use. In line with the principle of predictability in a ﬁnancial system, governance in $AVAX has hysteresis, meaning that changes to parameters are highly dependent on their recent changes. There are two limits 335 associated with each governable parameter: time and range. Once a parameter is changed using a governance transaction, it becomes very diﬃcult to change it again immediately and by a large amount. These diﬃculty and value constraints relax as more time passes since the last change. Overall, this keeps the system from changing drastically over a short period of time, allowing users to safely predict system parameters in the short term, while having strong control and ﬂexibility for the long term. 340

Visão geral da plataforma

Nesta seção, fornecemos uma visão geral da arquitetura da plataforma e discutimos várias implementações detalhes. A plataforma Avalanche separa claramente três preocupações: cadeias (e ativos construídos em cima), execução ambientes e implantação. 3.1 Arquitetura 145 Sub-redes Uma sub-rede, ou sub-rede, é um conjunto dinâmico de validators trabalhando juntos para alcançar consenso no estado de um conjunto de blockchains. Cada blockchain é validado por uma sub-rede e uma sub-rede pode validar arbitrariamente muitos blockchains. Um validator pode ser membro de muitas sub-redes arbitrariamente. Uma sub-rede decide quem pode entrar nele e pode exigir que seus validators constituintes tenham certas propriedades. O Avalanche plataforma suporta a criação e operação de muitas sub-redes arbitrariamente. Para criar uma nova sub-rede 150 ou para ingressar em uma sub-rede é necessário pagar uma taxa denominada em $AVAX.

Key non-consensus governable parameters used in the Avalanche platform including staking and fee settings

6 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer O modelo de sub-rede oferece uma série de vantagens: – Se um validator não se importa com os blockchains em uma determinada sub-rede, ele simplesmente não ingressará nessa sub-rede. Isso reduz o tráfego de rede, bem como os recursos computacionais exigidos dos validators. Isto está em contraste com outros projetos blockchain, nos quais cada validator deve validar todas as transações, mesmo 155 aqueles com quem eles não se importam. – Como as sub-redes decidem quem pode entrar nelas, é possível criar sub-redes privadas. Ou seja, cada blockchain em a sub-rede é validada apenas por um conjunto de validators confiáveis. – Pode-se criar uma sub-rede onde cada validator possui certas propriedades. Por exemplo, pode-se criar um sub-rede onde cada validator está localizado em uma determinada jurisdição ou onde cada validator está vinculado a algum 160 contrato do mundo real. Isto pode ser benéfico por razões de conformidade. Existe uma sub-rede especial chamada Sub-rede Padrão. É validado por todos os validators. (Isto é, para para validar qualquer sub-rede, é necessário também validar a sub-rede padrão.) A sub-rede padrão valida um conjunto de blockchains predefinidos, incluindo o blockchain onde $AVAX reside e é negociado. Máquinas Virtuais Cada blockchain é uma instância de uma Máquina Virtual (VM). Uma VM é um modelo para um 165 blockchain, assim como uma classe, é um projeto para um objeto em uma linguagem de programação orientada a objetos. O interface, estado e comportamento de um blockchain são definidos pela VM que o blockchain executa. O seguinte propriedades de um blockchain e outras são definidas por uma VM: – O conteúdo de um bloco – A transição de estado que ocorre quando um bloco é aceito 170 – As APIs expostas pelo blockchain e seus endpoints – Os dados que são persistidos no disco Dizemos que um blockchain “usa” ou “executa” uma determinada VM. Ao criar um blockchain, especifica-se a VM ele é executado, bem como o estado de gênese do blockchain. Um novo blockchain pode ser criado usando um pré-existente VM ou um desenvolvedor pode codificar um novo. Pode haver muitos blockchains arbitrariamente executando a mesma VM. 175 Cada blockchain, mesmo aqueles que executam a mesma VM, é logicamente independente dos outros e mantém sua próprio estado. 3.2 Inicialização O primeiro passo para participar do Avalanche é o bootstrapping. O processo ocorre em três etapas: conexão para semear âncoras, descoberta de rede e estado e se tornar um validator. 180 Âncoras de sementes Qualquer sistema de rede de pares que opera sem permissão (ou seja, codificado) conjunto de identidades requer algum mecanismo para descoberta de pares. Nas redes de compartilhamento de arquivos peer-to-peer, um conjunto de rastreadores são usados. Em redes criptográficas, um mecanismo típico é o uso de nós de sementes DNS (aos quais nos referimosAvalanche Plataforma 30/06/2020 7 como âncoras iniciais), que compreendem um conjunto de endereços IP iniciais bem definidos a partir dos quais outros membros do a rede pode ser descoberta. A função dos nós iniciais do DNS é fornecer informações úteis sobre o conjunto 185 de participantes ativos no sistema. O mesmo mecanismo é empregado em Bitcoin Core [1], em que o O arquivo src/chainparams.cpp do código-fonte contém uma lista de nós iniciais codificados. A diferença entre BTC e Avalanche é que o BTC requer apenas um nó inicial DNS correto, enquanto Avalanche requer um simples maioria das âncoras está correta. Por exemplo, um novo usuário pode optar por inicializar a visualização da rede através de um conjunto de bolsas bem estabelecidas e respeitáveis, nenhuma das quais individualmente não é confiável. 190 Observamos, no entanto, que o conjunto de nós de bootstrap não precisa ser codificado ou estático e pode ser fornecido pelo usuário, embora, para facilidade de uso, os clientes possam fornecer uma configuração padrão que inclua economia atores importantes, como bolsas, com os quais os clientes desejam compartilhar uma visão de mundo. Não há barreira para tornar-se uma âncora de semente, portanto, um conjunto de âncoras de semente não pode ditar se um nó pode ou não entrar a rede, uma vez que os nós podem descobrir a rede mais recente de Avalanche pares anexando-se a qualquer conjunto de sementes 195 âncoras. Descoberta de rede e estado Uma vez conectado às âncoras de semente, um nó consulta o conjunto mais recente de transições de estado. Chamamos esse conjunto de transições de estado de fronteira aceita. Para uma cadeia, a fronteira aceita é o último bloco aceito. Para um DAG, a fronteira aceita é o conjunto de vértices que são aceitos, mas possuem não há filhos aceitos. Depois de coletar as fronteiras aceitas das âncoras de sementes, as transições de estado que 200 são aceitos pela maioria das âncoras de sementes é definido como aceito. O estado correto é então extraído sincronizando com os nós amostrados. Contanto que haja uma maioria de nós corretos na âncora de semente definido, então as transições de estado aceitas devem ter sido marcadas como aceitas por pelo menos um nó correto. Este processo de descoberta de estado também é usado para descoberta de rede. O conjunto de membros da rede é definido na cadeia validator. Portanto, a sincronização com a cadeia validator permite que o nó descubra 205 o conjunto atual de validators. A cadeia validator será discutida mais detalhadamente na próxima seção. 3.3 Controle e adesão de Sybil Os protocolos de consenso fornecem suas garantias de segurança sob a suposição de que até um número limite dos membros do sistema pode ser contraditório. Um ataque Sybil, em que um nó inunda a rede de forma barata com identidades maliciosas, podem invalidar trivialmente essas garantias. Fundamentalmente, tal ataque só pode ser 210 dissuadido pela troca de presença com a prova de um recurso difícil de falsificar [3]. Sistemas anteriores exploraram o uso de mecanismos de dissuasão Sybil que abrangem proof-of-work (PoW), proof-of-stake (PoS), prova de tempo decorrido (POET), prova de espaço e tempo (PoST) e prova de autoridade (PoA). Na sua essência, todos estes mecanismos têm uma função idêntica: exigem que cada participante tenha alguma “pele no jogo” na forma de algum compromisso económico, que por sua vez proporciona uma vantagem económica 215 barreira contra o mau comportamento desse participante. Todos eles envolvem uma forma de aposta, seja na forma de plataformas de mineração e hash energia (PoW), espaço em disco (PoST), hardware confiável (POET) ou uma identidade aprovada (PoA). Esta aposta constitui a base de um custo económico que os participantes devem suportar para adquirir voz. Para por exemplo, em Bitcoin, a capacidade de contribuir com blocos válidos é diretamente proporcional ao poder hash do participante proponente. Infelizmente, também tem havido uma confusão substancial entre protocolos de consenso8 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer versus mecanismos de controle Sybil. Observamos que a escolha de protocolos de consenso é, em sua maior parte, ortogonal à escolha do mecanismo de controle Sybil. Isto não quer dizer que os mecanismos de controlo da Sybil sejam substituições imediatas entre si, uma vez que uma escolha específica pode ter implicações sobre o garantias do protocolo de consenso. No entanto, a família Snow* pode ser associada a muitos destes conhecidos mecanismos, sem modificação significativa. 225 Em última análise, por questões de segurança e para garantir que os incentivos dos participantes estejam alinhados em benefício da a rede, $AVAX escolhe PoS para o mecanismo central de controle Sybil. Algumas formas de participação são inerentemente centralizado: a fabricação de plataformas de mineração (PoW), por exemplo, é inerentemente centralizada nas mãos de alguns pessoas com o conhecimento adequado e acesso às dezenas de patentes necessárias para VLSI competitivo fabricação. Além disso, a mineração PoW perde valor devido aos grandes subsídios anuais aos mineradores. Da mesma forma, 230 o espaço em disco é propriedade em grande parte de grandes operadores de datacenter. Além disso, todos os mecanismos de controle Sybil que acumulam custos contínuos, por ex. custos de eletricidade para hashing, vazamento de valor do ecossistema, sem mencionar destruir o meio ambiente. Isto, por sua vez, reduz o envelope de viabilidade para o token, em que um evento adverso a mudança de preços em um pequeno período de tempo pode tornar o sistema inoperante. A prova de trabalho seleciona inerentemente mineiros que têm conexões para adquirir eletricidade barata, o que tem pouco a ver com a capacidade dos mineiros 235 para serializar transações ou suas contribuições para o ecossistema geral. Dentre essas opções, escolhemos proof-of-stake, porque é verde, acessível e aberto a todos. Notamos, no entanto, que embora o $AVAX use PoS, a rede Avalanche permite que sub-redes sejam lançadas com PoW e PoS. O staking é um mecanismo natural de participação numa rede aberta porque permite um impacto económico direto. argumento: a probabilidade de sucesso de um ataque é diretamente proporcional a um custo monetário bem definido 240 função. Em outras palavras, os nós que apostam são motivados economicamente para não se envolverem em comportamentos que pode prejudicar o valor da sua participação. Adicionalmente, esta participação não incorre em quaisquer custos adicionais de manutenção (outros depois o custo de oportunidade de investir em outro ativo), e possui a propriedade que, diferentemente dos equipamentos de mineração, é totalmente consumido se usado em um ataque catastrófico. Para operações PoW, o equipamento de mineração pode ser simplesmente reutilizados ou – se o proprietário decidir – totalmente vendidos de volta ao mercado. 245 Um nó que deseja entrar na rede pode fazê-lo livremente, primeiro colocando uma aposta que está imobilizada durante a duração da participação na rede. O usuário determina o valor da duração da aposta. Uma vez aceita, uma aposta não pode ser revertida. O principal objetivo é garantir que os nós compartilhem substancialmente o mesma visão praticamente estável da rede. Prevemos definir o tempo mínimo staking na ordem de um semana. 250 Ao contrário de outros sistemas que também propõem um mecanismo PoS, $AVAX não faz uso de slashing, e portanto, toda a aposta será devolvida quando o período staking expirar. Isso evita cenários indesejados, como uma falha de software ou hardware cliente levando à perda de moedas. Isso se encaixa com nossa filosofia de design de construção de tecnologia previsível: os tokens apostados não correm risco, mesmo na presença de software ou falhas de hardware. 255 Em Avalanche, um nó que deseja participar emite uma transação de participação especial para a cadeia validator. As transações de staking nomeiam um valor para apostar, a chave staking do participante que é staking, a duração, e a hora em que a validação começará. Assim que a transação for aceita, os fundos ficarão bloqueados até o final do período staking. O valor mínimo permitido é decidido e aplicado pelo sistema. A aposta quantia colocada por um participante tem implicações tanto para a quantidade de influência que o participante tem noAvalanche Plataforma 30/06/2020 9 processo de consenso, bem como a recompensa, conforme discutido posteriormente. A duração staking especiﬁcada deve estar entre δmin e δmax, os prazos mínimo e máximo para os quais qualquer aposta pode ser bloqueada. Tal como acontece com o staking valor, o período staking também tem implicações para a recompensa no sistema. Perda ou roubo do A chave staking não pode levar à perda de ativos, pois a chave staking é usada apenas no processo de consenso, não para ativos transferência. 265 3.4 Contratos inteligentes em $AVAX No lançamento, Avalanche suporta smart contracts padrão baseados em Solidity por meio da máquina virtual Ethereum (EVM). Prevemos que a plataforma suportará um conjunto mais rico e poderoso de smart contract ferramentas, incluindo: – Contratos inteligentes com execução off-chain e verificação on-chain. 270 – Contratos inteligentes com execução paralela. Quaisquer smart contracts que não operem no mesmo estado em qualquer sub-rede em Avalanche poderá ser executada em paralelo. – Um Solidity melhorado, chamado Solidity++. Esta nova linguagem suportará versionamento e matemática segura e aritmética de ponto fixo, um sistema de tipos aprimorado, compilação para LLVM e execução just-in-time. Se um desenvolvedor precisar de suporte EVM, mas quiser implantar smart contracts em uma sub-rede privada, ele 275 pode criar uma nova sub-rede diretamente. É assim que Avalanche permite a fragmentação específica de funcionalidade por meio de as sub-redes. Além disso, se um desenvolvedor precisar de interações com o Ethereum smart atualmente implantado contratos, eles podem interagir com a sub-rede Athereum, que é uma colher de Ethereum. Finalmente, se um desenvolvedor requer um ambiente de execução diferente da máquina virtual Ethereum, eles podem optar por implantar seu smart contract através de uma sub-rede que implementa um ambiente de execução diferente, como DAML 280 ou WASM. As sub-redes podem suportar recursos adicionais além do comportamento da VM. Por exemplo, as sub-redes podem impor requisitos de desempenho para nós validator maiores que mantêm smart contracts por períodos de tempo mais longos, ou validators que mantêm estado de contrato de forma privada. 4 Governança e o token $AVAX 4.1 O token nativo $AVAX 285 Política Monetária O token nativo, $AVAX, é de fornecimento limitado, onde o limite é definido em 720.000.000 tokens, com 360.000.000 tokens disponíveis no lançamento da mainnet. No entanto, ao contrário de outros tokens de fornecimento limitado que asse a taxa de cunhagem perpetuamente, $AVAX is designed to react to changing economic conditions. In particular, the objective of $A política monetária da AVAX é equilibrar os incentivos dos usuários para apostar no token em vez de usá-lo para interagir com a variedade de serviços disponíveis na plataforma. Participantes da plataforma 290 actuar colectivamente como um banco de reserva descentralizado. As alavancas disponíveis em Avalanche são staking recompensas, taxas, e lançamentos aéreos, todos influenciados por parâmetros governáveis. As recompensas de aposta são definidas pela governança em cadeia e são governadas por uma função projetada para nunca ultrapassar o fornecimento limitado. O piqueteamento pode ser induzido aumentando as taxas ou aumentando as recompensas staking. Por outro lado, podemos induzir um maior envolvimento com os serviços da plataforma Avalanche, reduzindo as taxas e diminuindo a recompensa staking.10 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer Usos Pagamentos Os verdadeiros pagamentos descentralizados peer-to-peer são em grande parte um sonho não realizado para a indústria devido a a actual falta de desempenho dos titulares. $AVAX é tão poderoso e fácil de usar quanto pagamentos usando Visa, permitindo milhares de transações globalmente a cada segundo, de maneira descentralizada e totalmente sem confiança. Além disso, para comerciantes de todo o mundo, a $AVAX oferece uma proposta de valor direta em relação à Visa, nomeadamente menor 300 taxas. Staking: Protegendo o Sistema Na plataforma Avalanche, o controle Sybil é obtido via staking. Em ordem para validar, o participante deve trancar moedas ou apostar. Os validadores, às vezes chamados de stakers, são compensados por seus serviços de validação com base no valor de staking e duração de staking, entre outros propriedades. A função de compensação escolhida deve minimizar a variância, garantindo que os grandes apostadores não 305 recebem desproporcionalmente mais compensação. Os participantes também não estão sujeitos a nenhum fator de “sorte”, como em Mineração PoW. Tal esquema de recompensa também desencoraja a formação de pools de mineração ou staking que possibilitem verdadeiramente participação descentralizada e sem confiança na rede. Swaps atômicos Além de fornecer a segurança central do sistema, o $AVAX token serve como unidade universal de troca. A partir daí, a plataforma Avalanche será capaz de suportar swaps atômicos confiáveis nativamente em 310 a plataforma que permite trocas nativas e verdadeiramente descentralizadas de qualquer tipo de ativo diretamente em Avalanche. 4.2 Governança A governança é fundamental para o desenvolvimento e adoção de qualquer plataforma porque – como acontece com todos os outros tipos de sistemas – Avalanche também enfrentará evolução e atualizações naturais. $AVAX fornece governança na cadeia para parâmetros críticos da rede onde os participantes podem votar em alterações na rede e 315 resolver decisões de atualização de rede democraticamente. Isso inclui fatores como o valor mínimo de staking, taxa de cunhagem, bem como outros parâmetros econômicos. Isso permite que a plataforma execute com eficácia a otimização dinâmica de parâmetros por meio de uma multidão oracle. No entanto, ao contrário de algumas outras plataformas de governação por aí, Avalanche não permite alterações ilimitadas em aspectos arbitrários do sistema. Em vez disso, apenas um um número predeterminado de parâmetros pode ser modificado através da governança, tornando o sistema mais previsível 320 e aumentando a segurança. Além disso, todos os parâmetros governáveis estão sujeitos a limites dentro de prazos específicos, introduzindo histerese e garantindo que o sistema permaneça previsível em curtos intervalos de tempo. Um processo viável para encontrar valores globalmente aceitáveis para os parâmetros do sistema é fundamental para sistemas descentralizados sem custodiantes. Avalanche pode usar seu mecanismo de consenso para construir um sistema que permita ninguém proponha transações especiais que são, em essência, pesquisas que abrangem todo o sistema. Qualquer nó participante pode 325 emitir tais propostas. A taxa de recompensa nominal é um parâmetro importante que afeta qualquer moeda, seja ela digital ou fiduciária. Infelizmente, as criptomoedas que fixam esse parâmetro podem enfrentar vários problemas, incluindo deflação ou inflação. Para tal, a taxa de recompensa nominal está sujeita a governação, dentro de limites pré-estabelecidos. Isto irá permitir que os detentores de token escolham se $AVAX será eventualmente limitado, ilimitado ou mesmo deflacionário.Avalanche Plataforma 30/06/2020 11 As taxas de transação, indicadas pelo conjunto F, também estão sujeitas à governança. F é efetivamente uma tupla que descreve as taxas associadas às diversas instruções e transações. Finalmente, staking horários e valores também são governáveis. A lista desses parâmetros está definida na Figura 1. – ∆: Valor do staking, denominado em $AVAX. Este valor define a aposta mínima necessária para ser colocada como vínculo antes de participar do sistema. – δmin: A quantidade mínima de tempo necessária para um nó fazer piquetagem no sistema. – δmax: A quantidade máxima de tempo que um nó pode apostar. – ρ: (π∆, τδmin) →R: A função de taxa de recompensa, também conhecida como taxa de cunhagem, determina a recompensa a o participante pode reivindicar em função de seu valor staking dado um certo número de nós π divulgados publicamente sob sua propriedade, durante um período de τ intervalos de tempo δmin consecutivos, de modo que τδmin ≤δmax. – F: a estrutura de taxas, que é um conjunto de parâmetros de taxas governáveis que especificam custos para diversas transações. Figura 1. Principais parâmetros não consensuais usados em Avalanche. Toda a notação é redefinida na primeira utilização. Em linha com o princípio da previsibilidade num sistema financeiro, a governação no $AVAX tem histerese, o que significa que as alterações nos parâmetros são altamente dependentes de suas alterações recentes. Existem dois limites 335 associado a cada parâmetro governável: tempo e intervalo. Depois que um parâmetro é alterado usando uma governança transação, torna-se muito difícil alterá-la novamente imediatamente e em grande quantidade. Essas dificuldades e as restrições de valor diminuem à medida que o tempo passa desde a última alteração. No geral, isso evita que o sistema mudando drasticamente em um curto período de tempo, permitindo aos usuários prever com segurança os parâmetros do sistema no curto prazo, ao mesmo tempo em que possui forte controle e flexibilidade no longo prazo. 340

Governance

1.1 Avalanche Goals and Principles Avalanche is a high-performance, scalable, customizable, and secure blockchain platform. It targets three broad use cases: 15 – Building application-speciﬁc blockchains, spanning permissioned (private) and permissionless (public) deployments. – Building and launching highly scalable and decentralized applications (Dapps). – Building arbitrarily complex digital assets with custom rules, covenants, and riders (smart assets). 1 Forward-looking statements generally relate to future events or our future performance. This includes, but is not limited to, Avalanche’s projected performance; the expected development of its business and projects; execution of its vision and growth strategy; and completion of projects that are currently underway, in development or otherwise under consideration. Forward-looking statements represent our management’s beliefs and assumptions only as of the date of this presentation. These statements are not guarantees of future performance and undue reliance should not be placed on them. Such forward-looking statements necessarily involve known and unknown risks, which may cause actual performance and results in future periods to diﬀer materially from any projections expressed or implied herein. Avalanche undertakes no obligation to update forward-looking statements. Although forward-looking statements are our best prediction at the time they are made, there can be no assurance that they will prove to be accurate, as actual results and future events could diﬀer materially. The reader is cautioned not to place undue reliance on forward-looking statements.

2 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer The overarching aim of Avalanche is to provide a unifying platform for the creation, transfer, and trade of 20 digital assets. By construction, Avalanche possesses the following properties: Scalable Avalanche is designed to be massively scalable, robust, and eﬃcient. The core consensus engine is able to support a global network of potentially hundreds of millions of internet-connected, low and highpowered devices that operate seamlessly, with low latencies and very high transactions per second. 25 Secure Avalanche is designed to be robust and achieve high security. Classical consensus protocols are designed to withstand up to f attackers, and fail completely when faced with an attacker of size f + 1 or larger, and Nakamoto consensus provides no security when 51% of the miners are Byzantine. In contrast, Avalanche provides a very strong guarantee of safety when the attacker is below a certain threshold, which can be parametrized by the system designer, and it provides graceful degradation when the attacker exceeds 30 this threshold. It can uphold safety (but not liveness) guarantees even when the attacker exceeds 51%. It is the ﬁrst permissionless system to provide such strong security guarantees. Decentralized Avalanche is designed to provide unprecedented decentralization. This implies a commitment to multiple client implementations and no centralized control of any kind. The ecosystem is designed to avoid divisions between classes of users with diﬀerent interests. Crucially, there is no distinction between miners, 35 developers, and users. Governable and Democratic $AVAX is a highly inclusive platform, which enables anyone to connect to its network and participate in validation and ﬁrst-hand in governance. Any token holder can have a vote in selecting key ﬁnancial parameters and in choosing how the system evolves. Interoperable and Flexible Avalanche is designed to be a universal and ﬂexible infrastructure for a multitude 40 of blockchains/assets, where the base $AVAX is used for security and as a unit of account for exchange. The system is intended to support, in a value-neutral fashion, many blockchains to be built on top. The platform is designed from the ground up to make it easy to port existing blockchains onto it, to import balances, to support multiple scripting languages and virtual machines, and to meaningfully support multiple deployment scenarios. 45 Outline The rest of this paper is broken down into four major sections. Section 2 outlines the details of the engine that powers the platform. Section 3 discusses the architectural model behind the platform, including subnetworks, virtual machines, bootstrapping, membership, and staking. Section 4 explains the governance model that enables dynamic changes to key economic parameters. Finally, in Section 5 explores various peripheral topics of interest, including potential optimizations, post-quantum cryptography, and realistic 50 adversaries.

Avalanche Platform 2020/06/30 3 Naming Convention The name of the platform is Avalanche, and is typically referred to as “the Avalanche platform”, and is interchangeable/synonymous with “the Avalanche network”, or – simply – Avalanche. Codebases will be released using three numeric identiﬁers, labeled “v.[0-9].[0-9].[0-100]”, where the ﬁrst number identiﬁes major releases, the second number identiﬁes minor releases, and the third number 55 identiﬁes patches. The ﬁrst public release, codenamed Avalanche Borealis, is v. 1.0.0. The native token of the platform is called “$AVAX”. The family of consensus protocols used by the Avalanche platform is referred to as the Snow* family. There are three concrete instantiations, called Avalanche, Snowman, and Frosty.

Governança

1.1 Avalanche Metas e Princípios Avalanche é uma plataforma blockchain segura, escalonável, personalizável e de alto desempenho. Tem como alvo três amplos casos de uso: 15 – Construindo blockchains específicos do aplicativo, abrangendo com permissão (privado) e sem permissão (público) implantações. – Construir e lançar aplicativos altamente escaláveis e descentralizados (Dapps). – Construir ativos digitais arbitrariamente complexos com regras, acordos e acessórios personalizados (ativos inteligentes). 1 As declarações prospectivas geralmente estão relacionadas a eventos futuros ou ao nosso desempenho futuro. Isto inclui, mas não é limitado ao desempenho projetado de Avalanche; o desenvolvimento esperado dos seus negócios e projetos; execução da sua visão e estratégia de crescimento; e conclusão de projetos que estão atualmente em andamento, em desenvolvimento ou caso contrário, está em consideração. As declarações prospectivas representam as crenças e suposições de nossa administração somente a partir da data desta apresentação. Estas declarações não são garantias de desempenho futuro e não se deve confiar neles. Tais declarações prospectivas envolvem necessariamente riscos, que podem fazer com que o desempenho e os resultados reais em períodos futuros sejam materialmente diferentes de quaisquer projeções expressa ou implícita aqui. Avalanche não assume nenhuma obrigação de atualizar declarações prospectivas. Embora declarações prospectivas são nossa melhor previsão no momento em que são feitas, não pode haver garantia de que elas provará ser preciso, pois os resultados reais e eventos futuros podem diferir materialmente. O leitor é alertado para não confiar indevidamente em declarações prospectivas.2 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer O objetivo geral de Avalanche é fornecer uma plataforma unificadora para a criação, transferência e comércio de 20 ativos digitais. Por construção, Avalanche possui as seguintes propriedades: Escalável Avalanche foi projetado para ser extremamente escalável, robusto e eficiente. O principal mecanismo de consenso é capaz de suportar uma rede global de potencialmente centenas de milhões de dispositivos conectados à Internet, de baixa e alta potência, que operam perfeitamente, com baixas latências e transações muito altas por segundo. 25 O Secure Avalanche foi projetado para ser robusto e atingir alta segurança. Os protocolos de consenso clássicos são projetado para suportar até f atacantes e falhar completamente quando confrontado com um invasor de tamanho f + 1 ou maior, e o consenso de Nakamoto não oferece segurança quando 51% dos mineiros são bizantinos. Em contraste, Avalanche fornece uma garantia de segurança muito forte quando o invasor está abaixo de um determinado limite, que pode ser parametrizado pelo projetista do sistema e fornece degradação elegante quando o invasor excede 30 esse limite. Ele pode manter garantias de segurança (mas não de vivacidade) mesmo quando o invasor excede 51%. É o primeiro sistema sem permissão a fornecer garantias de segurança tão fortes. O Avalanche descentralizado foi projetado para fornecer descentralização sem precedentes. Isto implica um compromisso para múltiplas implementações de clientes e nenhum tipo de controle centralizado. O ecossistema é projetado para evitar divisões entre classes de usuários com interesses diferentes. Crucialmente, não há distinção entre mineiros, 35 desenvolvedores e usuários. Governável e Democrático $AVAX é uma plataforma altamente inclusiva, que permite que qualquer pessoa se conecte ao seu rede e participar na validação e em primeira mão na governança. Qualquer titular de token pode votar em na seleção dos principais parâmetros financeiros e na escolha de como o sistema evolui. Interoperável e flexível Avalanche foi projetado para ser uma infraestrutura universal e flexível para uma infinidade 40 de blockchains/assets, onde a base $AVAX é usada para segurança e como unidade de conta para troca. O O sistema destina-se a suportar, de uma forma neutra em termos de valor, muitos blockchains a serem construídos em cima. A plataforma foi projetado desde o início para facilitar a portabilidade de blockchains existentes para ele, para importar saldos, para oferecer suporte a diversas linguagens de script e máquinas virtuais e oferecer suporte significativo a diversas implantações cenários. 45 Esboço O restante deste documento está dividido em quatro seções principais. A seção 2 descreve os detalhes do motor que alimenta a plataforma. A Seção 3 discute o modelo arquitetônico por trás da plataforma, incluindo sub-redes, máquinas virtuais, inicialização, associação e staking. A Seção 4 explica a governança modelo que permite mudanças dinâmicas nos principais parâmetros económicos. Finalmente, na Seção 5 explora vários tópicos periféricos de interesse, incluindo otimizações potenciais, criptografia pós-quântica e sistemas realistas 50 adversários.

Avalanche Plataforma 30/06/2020 3 Convenção de nomenclatura O nome da plataforma é Avalanche e normalmente é chamada de “Avalanche plataforma”, e é intercambiável/sinônimo de “a rede Avalanche”, ou – simplesmente – Avalanche. As bases de código serão lançadas usando três identificadores numéricos, rotulados como “v.[0-9].[0-9].[0-100]”, onde o O primeiro número identifica os lançamentos principais, o segundo número identifica os lançamentos secundários e o terceiro número 55 identifica manchas. O primeiro lançamento público, codinome Avalanche Borealis, é v. O nativo token da plataforma é chamado “$AVAX”. A família de protocolos de consenso usados pela plataforma Avalanche é conhecida como família Snow*. Existem três instanciações concretas, chamadas Avalanche, Snowman e Gelado.

Discussion

5.1 Optimizations Pruning Many blockchain platforms, especially those implementing Nakamoto consensus such as Bitcoin, suﬀer from perpetual state growth. This is because – by protocol – they have to store the entire history of transactions. However, in order for a blockchain to grow sustainably, it must be able to prune old history. 345 This is especially important for blockchains that support high performance, such as Avalanche. Pruning is simple in the Snow* family. Unlike in Bitcoin (and similar protocols), where pruning is not possible per the algorithmic requirements, in $AVAX nodes do not need to maintain parts of the DAG that are deep and highly committed. These nodes do not need to prove any past history to new bootstrapping nodes, and therefore simply have to store active state, i.e. the current balances, as well as uncommitted 350 transactions. Client Types Avalanche can support three diﬀerent types of clients: archival, full, and light. Archival nodes store the entire history of the $AVAX subnet, the staking subnet, and the smart contract subnet, all the

12 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer way to genesis, meaning that these nodes serve as bootstrapping nodes for new incoming nodes. Additionally these nodes may store the full history of other subnets for which they choose to be validators. Archival 355 nodes are typically machines with high storage capabilities that are paid by other nodes when downloading old state. Full nodes, on the other hand, participate in validation, but instead of storing all history, they simply store the active state (e.g. current UTXO set). Finally, for those that simply need to interact securely with the network using the most minimal amount of resources, Avalanche supports light clients which can prove that some transaction has been committed without needing to download or synchronize history. Light 360 clients engage in the repeated sampling phase of the protocol to ensure safe commitment and network wide consensus. Therefore, light clients in Avalanche provide the same security guarantees as full nodes. Sharding Sharding is the process of partitioning various system resources in order to increase performance and reduce load. There are various types of sharding mechanisms. In network sharding, the set of participants is divided into separate subnetworks as to reduce algorithmic load; in state sharding, participants agree on 365 storing and maintaining only speciﬁc subparts of the entire global state; lastly, in transaction sharding, participants agree to separate the processing of incoming transactions. In Avalanche Borealis, the ﬁrst form of sharding exists through the subnetworks functionality. For example, one may launch a gold subnet and another real-estate subnet. These two subnets can exist entirely in parallel. The subnets interact only when a user wishes to buy real-estate contracts using their gold holdings, 370 at which point Avalanche will enable an atomic swap between the two subnets. 5.2 Concerns Post Quantum Cryptography Post-quantum cryptography has recently gained widespread attention due to the advances in the development of quantum computers and algorithms. The concern with quantum computers is that they can break some of the currently deployed cryptographic protocols, speciﬁcally digital 375 signatures. The Avalanche network model enables any number of VMs, so it supports a quantum-resistant virtual machine with a suitable digital signature mechanism. We anticipate several types of digital signature schemes to be deployed, including quantum resistant RLWE-based signatures. The consensus mechanism does not assume any kind of heavy crypto for its core operation. Given this design, it is straightforward to extend the system with a new virtual machine that provides quantum secure cryptographic primitives. 380 Realistic Adversaries The Avalanche paper [6] provides very strong guarantees in the presence of a powerful and hostile adversary, known as a round-adaptive adversary in the full point-to-point model. In other terms, the adversary has full access to the state of every single correct node at all times, knows the random choices of all correct nodes, as well as can update its own state at any time, before and after the correct node has the chance to update its own state. Eﬀectively, this adversary is all powerful, except for 385 the ability to directly update the state of a correct node or modify the communication between correct nodes. Nonetheless, in reality, such an adversary is purely theoretical since practical implementations of the strongest possible adversary are limited at statistical approximations of the network state. Therefore, in practice, we expect worst-case-scenario attacks to be diﬃcult to deploy.

Avalanche Platform 2020/06/30 13 Inclusion and Equality A common problem in permissionless currencies is that of the “rich getting 390 richer”. This is a valid concern, since a PoS system that is improperly implemented may in fact allow wealth generation to be disproportionately attributed to the already large holders of stake in the system. A simple example is that of leader-based consensus protocols, wherein a subcommittee or a designated leader collects all the rewards during its operation, and where the probability of being chosen to collect rewards is proportional to the stake, accruing strong reward compounding eﬀects. Further, in systems such as Bitcoin, 395 there is a “big get bigger” phenomenon where the big miners enjoy a premium over smaller ones in terms of fewer orphans and less lost work. In contrast, Avalanche employs an egalitarian distribution of minting: every single participant in the staking protocol is rewarded equitably and proportionally based on stake. By enabling very large numbers of people to participate ﬁrst-hand in staking, Avalanche can accommodate millions of people to participate equally in staking. The minimum amount required to participate in the 400 protocol will be up for governance, but it will be initialized to a low value to encourage wide participation. This also implies that delegation is not required to participate with a small allocation. 6 Conclusion In this paper, we discussed the architecture of the Avalanche platform. Compared to other platforms today, which either run classical-style consensus protocols and therefore are inherently non-scalable, or make usage of 405 Nakamoto-style consensus that is ineﬃcient and imposes high operating costs, the Avalanche is lightweight, fast, scalable, secure, and eﬃcient. The native token, which serves for securing the network and paying for various infrastructural costs is simple and backwards compatible. $AVAX has capacity beyond other proposals to achieve higher levels of decentralization, resist attacks, and scale to millions of nodes without any quorum or committee election, and hence without imposing any limits to participation. 410 Besides the consensus engine, Avalanche innovates up the stack, and introduces simple but important ideas in transaction management, governance, and a slew of other components not available in other platforms. Each participant in the protocol will have a voice in inﬂuencing how the protocol evolves at all times, made possible by a powerful governance mechanism. Avalanche supports high customizability, allowing nearly instant plug-and-play with existing blockchains. 415

Discussão

5.1 Otimizações Removendo muitas plataformas blockchain, especialmente aquelas que implementam o consenso Nakamoto, como Bitcoin, sofrem com o crescimento perpétuo do Estado. Isto porque – por protocolo – eles têm que armazenar todo o histórico de transações. No entanto, para que um blockchain cresça de forma sustentável, deve ser capaz de podar a velha história. 345 Isto é especialmente importante para blockchains que suportam alto desempenho, como Avalanche. A poda é simples na família Snow*. Ao contrário de Bitcoin (e protocolos semelhantes), onde a poda não é possível de acordo com os requisitos algorítmicos, em $AVAX os nós não precisam manter partes do DAG que são profundos e altamente comprometidos. Esses nós não precisam provar nenhum histórico passado para nova inicialização nós e, portanto, simplesmente precisa armazenar o estado ativo, ou seja, os saldos atuais, bem como os não confirmados 350 transações. Os tipos de cliente Avalanche podem suportar três tipos diferentes de clientes: arquivamento, completo e leve. Arquivo os nós armazenam todo o histórico da sub-rede $AVAX, da sub-rede staking e da sub-rede smart contract, todos os12 Kevin Sekniqi, Daniel Laine, Stephen Buttolph e Emin G¨un Sirer caminho para a gênese, o que significa que esses nós servem como nós de inicialização para novos nós de entrada. Além disso esses nós podem armazenar o histórico completo de outras sub-redes para as quais escolhem ser validators. Arquivo 355 nós são normalmente máquinas com alta capacidade de armazenamento que são pagas por outros nós durante o download estado antigo. Os nós completos, por outro lado, participam da validação, mas em vez de armazenar todo o histórico, eles simplesmente armazene o estado ativo (por exemplo, conjunto UTXO atual). Finalmente, para aqueles que simplesmente precisam interagir com segurança com a rede usando a quantidade mínima de recursos, Avalanche oferece suporte a clientes leves que podem provar que alguma transação foi confirmada sem a necessidade de baixar ou sincronizar o histórico. Luz 360 os clientes se envolvem na fase de amostragem repetida do protocolo para garantir o compromisso seguro e toda a rede consenso. Portanto, os clientes leves em Avalanche fornecem as mesmas garantias de segurança que os nós completos. Sharding Sharding é o processo de particionar vários recursos do sistema para aumentar o desempenho e reduzir a carga. Existem vários tipos de mecanismos de fragmentação. No sharding de rede, o conjunto de participantes é dividido em sub-redes separadas para reduzir a carga algorítmica; na fragmentação de estado, os participantes concordam em 365 armazenar e manter apenas subpartes específicas de todo o estado global; por último, na fragmentação de transações, os participantes concordam em separar o processamento das transações recebidas. No Avalanche Borealis, a primeira forma de sharding existe através da funcionalidade de sub-redes. Para por exemplo, pode-se lançar uma sub-rede ouro e outra sub-rede imobiliária. Essas duas sub-redes podem existir inteiramente em paralelo. As sub-redes interagem apenas quando um usuário deseja comprar contratos imobiliários usando suas posses de ouro, 370 ponto em que Avalanche permitirá uma troca atômica entre as duas sub-redes. 5.2 Preocupações Criptografia pós-quântica A criptografia pós-quântica ganhou recentemente ampla atenção devido aos avanços no desenvolvimento de computadores e algoritmos quânticos. A preocupação com a quântica computadores é que eles podem quebrar alguns dos protocolos criptográficos atualmente implantados, especificamente 375 assinaturas. O modelo de rede Avalanche permite qualquer número de VMs, por isso suporta uma rede resistente a quantum máquina virtual com um mecanismo de assinatura digital adequado. Prevemos vários tipos de assinatura digital esquemas a serem implantados, incluindo assinaturas baseadas em RLWE com resistência quântica. O mecanismo de consenso não assume nenhum tipo de criptografia pesada para sua operação principal. Dado esse design, é fácil ampliar o sistema com uma nova máquina virtual que fornece primitivas criptográficas seguras quânticas. 380 Adversários realistas O artigo Avalanche [6] fornece garantias muito fortes na presença de um adversário poderoso e hostil, conhecido como adversário adaptável a rodadas no modelo ponto a ponto completo. Em outros termos, o adversário tem acesso total ao estado de cada nó correto em todos os momentos, conhece o escolhas aleatórias de todos os nós corretos, bem como pode atualizar seu próprio estado a qualquer momento, antes e depois do o nó correto tem a chance de atualizar seu próprio estado. Efetivamente, este adversário é todo-poderoso, exceto 385 a capacidade de atualizar diretamente o estado de um nó correto ou modificar a comunicação entre o nó correto nós. No entanto, na realidade, tal adversário é puramente teórico, uma vez que as implementações práticas do o adversário mais forte possível é limitado a aproximações estatísticas do estado da rede. Portanto, em Na prática, esperamos que os ataques no pior cenário sejam difíceis de implementar.Avalanche Plataforma 30/06/2020 13 Inclusão e Igualdade Um problema comum em moedas sem permissão é o dos “ricos que ficam 390 mais rico”. Esta é uma preocupação válida, uma vez que um sistema PoS implementado indevidamente pode de fato permitir a geração de riqueza seja desproporcionalmente atribuída aos já grandes detentores de participação no sistema. Um Um exemplo simples é o dos protocolos de consenso baseados em líderes, em que um subcomitê ou um líder designado coleta todas as recompensas durante sua operação, e onde a probabilidade de ser escolhido para coletar recompensas é proporcional à aposta, acumulando fortes efeitos de composição de recompensa. Além disso, em sistemas como Bitcoin, 395 existe um fenômeno “grande fica maior”, onde os grandes mineradores desfrutam de um prêmio sobre os menores em termos de menos órfãos e menos trabalho perdido. Em contraste, Avalanche emprega uma distribuição igualitária de cunhagem: cada participante do protocolo staking é recompensado de forma equitativa e proporcional com base na aposta. Ao permitir que um grande número de pessoas participem em primeira mão em staking, Avalanche pode acomodar milhões de pessoas participem igualmente em staking. O valor mínimo necessário para participar do 400 o protocolo estará sujeito à governança, mas será inicializado com um valor baixo para encorajar uma ampla participação. Isto também implica que a delegação não é obrigada a participar com uma pequena dotação. 6 Conclusão Neste artigo, discutimos a arquitetura da plataforma Avalanche. Em comparação com outras plataformas hoje, que executam protocolos de consenso de estilo clássico e, portanto, são inerentemente não escaláveis, ou fazem uso de 405 Consenso ao estilo Nakamoto que é ineficiente e impõe altos custos operacionais, o Avalanche é leve, rápido, escalonável, seguro e eficiente. O token nativo, que serve para proteger a rede e pagar por vários custos de infraestrutura é simples e compatível com versões anteriores. $AVAX tem capacidade além de outras propostas para alcançar níveis mais elevados de descentralização, resistir a ataques e escalar para milhões de nós sem qualquer quórum ou eleição de comitê e, portanto, sem impor quaisquer limites à participação. 410 Além do mecanismo de consenso, Avalanche inova na pilha e apresenta soluções simples, mas importantes ideias em gerenciamento de transações, governança e uma série de outros componentes não disponíveis em outras plataformas. Cada participante do protocolo terá voz para influenciar a forma como o protocolo evolui em todos os momentos, possível graças a um poderoso mecanismo de governação. Avalanche suporta alta personalização, permitindo plug-and-play quase instantâneo com blockchains existentes. 415