Avalanche : une nouvelle famille de protocoles de consensus
Abstract
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 first 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 differentiators 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-specific 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 differ 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 differ materially. The reader is cautioned not to place undue reliance on forward-looking statements.
Résumé
Avalanche Plateforme 30/06/2020 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer Résumé. Cet article fournit un aperçu architectural de la première version de la plateforme Avalanche, nom de code Avalanche Borealis. Pour plus de détails sur l'économie du token natif, étiqueté $AVAX, nous 5 guidez le lecteur vers le document de dynamique token ci-joint [2]. Divulgation : Les informations décrites dans ce document sont préliminaires et sujettes à modification à tout moment. De plus, ce document peut contenir des « déclarations prospectives ».1 Validation Git : 7497e4a4ba0a1ea2dc2a111bc6deefbf3023708e 1 Introduction 10 Cet article fournit un aperçu architectural de la plate-forme Avalanche. L'accent est mis sur les trois éléments clés différenciateurs de la plateforme : le moteur, le modèle architectural et le mécanisme de gouvernance. 1.1 Avalanche Buts et principes Avalanche est une plateforme blockchain hautes performances, évolutive, personnalisable et sécurisée. Il cible trois cas d'utilisation généraux : 15 – Création de blockchain spécifiques à l'application, couvrant les autorisations (privées) et sans autorisation (publiques) déploiements. – Création et lancement d’applications hautement évolutives et décentralisées (Dapps). – Créer des actifs numériques arbitrairement complexes avec des règles, des clauses et des avenants personnalisés (actifs intelligents). 1 Les déclarations prospectives se rapportent généralement à des événements futurs ou à nos performances futures. Cela inclut, mais n'est pas limité aux performances projetées de Avalanche ; l'évolution attendue de son activité et de ses projets ; exécution de sa vision et de sa stratégie de croissance ; et la réalisation de projets actuellement en cours, en développement ou sinon à l'étude. Les déclarations prospectives représentent les convictions et hypothèses de notre direction. seulement à compter de la date de cette présentation. Ces déclarations ne constituent pas des garanties de performances futures et des il ne faut pas s’y fier. Ces déclarations prospectives impliquent nécessairement des informations connues et inconnues. risques, qui peuvent faire en sorte que la performance réelle et les résultats des périodes futures diffèrent sensiblement des projections. exprimé ou implicite dans les présentes. Avalanche n'assume aucune obligation de mettre à jour les déclarations prospectives. Bien que les déclarations prospectives constituent notre meilleure prédiction au moment où elles sont faites, rien ne garantit qu'elles s’avérera exact, car les résultats réels et les événements futurs pourraient différer sensiblement. Le lecteur est averti de ne pas de se fier indûment aux déclarations prospectives.
Introduction
Introduction
10 This paper provides an architectural overview of the Avalanche platform. The key focus is on the three key differentiators of the platform: the engine, the architectural model, and the
Introduction
10 Cet article fournit un aperçu architectural de la plate-forme Avalanche. L'accent est mis sur les trois éléments clés différenciateurs de la plateforme : le moteur, le modèle architectural et le
The Engine
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 five decades, and that effort, 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 suffer from high confirmation 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 different 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 conflicting
4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin G¨un Sirer transaction, that is, a doublespend? To choose amongst the conflicting transactions and prevent the doublespend, every node randomly selects a small subset of nodes and queries which of the conflicting 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 conflicting 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 sufficiently 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 wellquantified 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 tradeoffs. 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 first110 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 confirmation of transactions. Therefore, one of the most important, and yet highly overlooked, properties of consensus protocols is the 125 time to finality. Snow* protocols reach finality typically in ≤1 second, which is significantly lower than both longest-chain protocols and sharded blockchains, both of which typically span finality to a matter of minutes.
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 offdecentralization 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 verification. 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 differences 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 Confirmation) - + + 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.
Le moteur
60 La discussion sur la plateforme Avalanche commence par le composant principal qui alimente la plateforme : le moteur de consensus. Contexte Les paiements distribués et – plus généralement – le calcul nécessitent un accord entre un ensemble de machines. Par conséquent, les protocoles de consensus, qui permettent à un groupe de nœuds de parvenir à un accord, se situent au cœur du processus. cœur des blockchain, ainsi que de presque tous les systèmes distribués industriels déployés à grande échelle. Le sujet 65 a fait l’objet d’un examen approfondi pendant près de cinq décennies, et cet effort, à ce jour, n’a donné que deux familles de protocoles : les protocoles de consensus classiques, qui reposent sur une communication de tous à tous, et le consensus de Nakamoto, qui repose sur le minage proof-of-work associé à la règle de la chaîne la plus longue. Alors que les protocoles de consensus classiques peuvent avoir une faible latence et un débit élevé, ils ne s'adaptent pas à un grand nombre de participants et ne sont pas non plus robustes en présence de changements d'adhésion, ce qui les a relégués pour la plupart dans des groupes autorisés, principalement 70 déploiements statiques. Les protocoles de consensus de Nakamoto [5, 7, 4], en revanche, sont robustes, mais souffrent de des latences de confirmation élevées, un faible débit et nécessitent une dépense énergétique constante pour leur sécurité. La famille de protocoles Snow, introduite par Avalanche, combine les meilleures propriétés des protocoles de consensus classiques avec le meilleur du consensus de Nakamoto. Basé sur un mécanisme d'échantillonnage de réseau léger, ils atteignent une faible latence et un débit élevé sans avoir besoin de se mettre d'accord sur l'appartenance précise du groupe. 75 système. Ils s'étendent bien de milliers à des millions de participants avec une participation directe au protocole de consensus. De plus, les protocoles n’utilisent pas le minage PoW et évitent donc son coût exorbitant. dépense énergétique et fuite de valeur ultérieure dans l'écosystème, produisant des produits légers, verts et silencieux protocoles. Mécanisme et propriétés Les protocoles Snow fonctionnent par échantillonnage répété du réseau. Chaque nœud 80 interroge un petit ensemble de voisins de taille constante, choisis au hasard, et change de proposition en cas de majorité qualifiée prend en charge une valeur différente. Les échantillons sont répétés jusqu'à ce que la convergence soit atteinte, ce qui se produit rapidement en opérations normales. Nous élucidons le mécanisme de fonctionnement via un exemple concret. Premièrement, une transaction est créée par un utilisateur et envoyé à un nœud de validation, qui est un nœud participant à la procédure de consensus. C'est alors 85 propagés à d’autres nœuds du réseau via des commérages. Que se passe-t-il si cet utilisateur émet également un message4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer transaction, c'est-à-dire une double dépense ? Pour choisir parmi les transactions en conflit et éviter les doubles dépenses, chaque nœud sélectionne au hasard un petit sous-ensemble de nœuds et demande laquelle des transactions en conflit les nœuds interrogés pensent que c'est le nœud valide. Si le nœud interrogeant reçoit une réponse majoritaire en faveur d'une transaction, le nœud modifie sa propre réponse à cette transaction. Chaque nœud du réseau 90 répète cette procédure jusqu'à ce que l'ensemble du réseau parvienne à un consensus sur l'une des transactions conflictuelles. Étonnamment, bien que le mécanisme de fonctionnement de base soit assez simple, ces protocoles conduisent à des résultats très élevés. dynamique de système souhaitable qui les rend adaptés à un déploiement à grande échelle. – Sans autorisation, ouvert au désabonnement et robuste. La dernière série de projets blockchain emploie des méthodes classiques protocoles consensuels et nécessitent donc une connaissance approfondie des membres. Connaître l'ensemble du par95 participants est suffisamment simple dans des systèmes fermés et autorisés, mais devient de plus en plus difficile dans des systèmes ouverts et autorisés. réseaux décentralisés. Cette limitation impose des risques de sécurité élevés aux opérateurs historiques actuels qui emploient de tels protocoles. En revanche, les protocoles Snow maintiennent des garanties de sécurité élevées même lorsqu'il existe des écarts bien quantifiés entre les vues du réseau de deux nœuds quelconques. Validateurs des protocoles Snow profitez de la possibilité de valider sans connaissance continue et complète de l’adhésion. Ils sont donc robustes 100 et convient parfaitement aux blockchain publics. – Évolutif et décentralisé Une caractéristique essentielle de la famille Snow est sa capacité à évoluer sans encourir des compromis fondamentaux. Les protocoles Snow peuvent s'étendre à des dizaines de milliers ou des millions de nœuds, sans délégation à des sous-ensembles de validator. Ces protocoles bénéficient de la meilleure décentralisation du système, permettant chaque nœud pour valider complètement. La participation directe et continue a de profondes implications pour la sécurité 105 du système. Dans presque tous les protocoles proof-of-stake qui tentent de s'adapter à un grand nombre de participants, le mode de fonctionnement typique consiste à permettre la mise à l’échelle en déléguant la validation à un sous-comité. Naturellement, cela implique que la sécurité du système est désormais aussi élevée que le coût de la corruption du système. sous-commission. Les sous-comités sont en outre sujets à la formation de cartels. Dans les protocoles de type Snow, une telle délégation n'est pas nécessaire, permettant à chaque opérateur de nœud d'avoir un premier dire à la main dans le système, à tout moment. Une autre conception, généralement appelée fragmentation d'état, tente pour assurer l'évolutivité en parallélisant la sérialisation des transactions sur des réseaux indépendants de validator. Malheureusement, la sécurité du système dans une telle conception ne devient qu'à la hauteur de la sécurité la plus facile à corrompre. fragment indépendant. Par conséquent, ni l’élection d’un sous-comité ni le partage ne constituent des stratégies de mise à l’échelle appropriées. pour les plateformes de cryptographie. 115 – Adaptatif. Contrairement à d'autres systèmes basés sur le vote, les protocoles Snow atteignent des performances supérieures lorsque le L'adversaire est petit, mais très résilient face à des attaques de grande envergure. – Sûr de manière asynchrone. Les protocoles Snow, contrairement aux protocoles à chaîne la plus longue, ne nécessitent pas de synchronisme pour fonctionner en toute sécurité et éviter ainsi les doubles dépenses, même face aux partitions réseau. En Bitcoin, par exemple, si l'hypothèse de synchronicité n'est pas respectée, il est possible d'opérer sur des fourches indépendantes du 120 Bitcoin réseau pendant des périodes prolongées, ce qui invaliderait toute transaction une fois la fourchette guérir. – Faible latence. La plupart des blockchain d'aujourd'hui ne sont pas en mesure de prendre en charge les applications professionnelles, telles que le trading ou les opérations quotidiennes. paiements de détail. Il est tout simplement irréalisable d'attendre des minutes, voire des heures, pour la confirmation d'une transaction. Par conséquent, l’une des propriétés les plus importantes, et pourtant très négligée, des protocoles de consensus est la 125 le temps de la finalité. Les protocoles Snow atteignent généralement leur finalité en ≤ 1 seconde, ce qui est significativement inférieur à à la fois les protocoles à chaîne la plus longue et les blockchain fragmentés, qui couvrent généralement tous deux la finalité d'un sujet. de minutes.Avalanche Plateforme 2020/06/30 5 – Haut débit. Les protocoles Snow, qui peuvent construire une chaîne linéaire ou un DAG, atteignent des milliers de transactions par seconde (plus de 5 000 tps), tout en conservant une décentralisation totale. De nouvelles solutions blockchain qui prétendent 130 élevé TPS fait généralement un compromis entre décentralisation et sécurité et opte pour des solutions plus centralisées et moins sécurisées. mécanismes de consensus. Certains projets rapportent des chiffres provenant de contextes hautement contrôlés, donnant ainsi des informations erronées. de véritables résultats de performance. Les chiffres rapportés pour $AVAX proviennent directement d'un réseau Avalanche réel et entièrement implémenté, fonctionnant sur 2 000 nœuds sur AWS, géodistribués à travers le monde sur des réseaux bas de gamme. machines. Des résultats de performances plus élevés (10 000+) peuvent être obtenus en supposant une bande passante plus élevée 135 provisionnement pour chaque nœud et matériel dédié pour la vérification de la signature. Enfin, nous notons que le les métriques susmentionnées se trouvent au niveau de la couche de base. Les solutions de mise à l'échelle de couche 2 augmentent immédiatement ces résultats considérablement. Tableaux comparatifs de consensus Le tableau 1 décrit les différences entre les trois familles connues de protocoles de consensus à travers un ensemble de 8 axes critiques. 140 Nakamoto Classique Neige Robuste (adapté aux paramètres ouverts) + - + Hautement décentralisé (permet de nombreux validateurs) + - + Faible latence et finalité rapide (confirmation rapide des transactions) - + + Débit élevé (permet à de nombreux clients) - + + Léger (faible configuration système requise) - + + Au repos (non actif lorsqu'aucune décision n'est effectuée) - + + Sécurité paramétrable (au-delà de 51 % de présence adverse) - - + Hautement évolutif - - + Tableau 1. Tableau comparatif entre les trois familles connues de protocoles de consensus. Avalanche, bonhomme de neige et Frosty appartient tous à la famille Snow.
Platform Overview
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 offers 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 traffic, 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 benificial 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-defined 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 defined by the VM that the blockchain runs. The following properties of a blockchain, and other, are defined 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 specifies 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 first 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 file 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-defined 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 file of the source code holds a list of hard-coded seed nodes. The difference 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 defined 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 defined 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 floods the network with malicious identities, can trivially invalidate these guarantees. Fundamentally, such an attack can only be 210 deterred by trading offpresence 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 significant modification. 225 Ultimately, for security and to ensure that the incentives of participants are aligned for the benefit 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-defined 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 first 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 flaws. 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 influence the participant has in the
Avalanche Platform 2020/06/30 9 consensus process, as well as the reward, as discussed later. The specified 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 off-chain execution and on-chain verification. 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 fixed 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-specific 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 different execution environment from the Ethereum virtual machine, they may choose to deploy their smart contract through a subnet that implements a different 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 influenced 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 effectively 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 modified via governance, rendering the system more predictable 320 and increasing safety. Further, all governable parameters are subject to limits within specific time bounds, introducing hysteresis, and ensuring that the system remains predictable over short time ranges. A workable process for finding 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 affects any currency, whether digital or fiat. Unfortunately, cryptocurrencies that fix this parameter might face various issues, including deflation or inflation. 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 deflationary.
Avalanche Platform 2020/06/30 11 Transaction fees, denoted by the set F, are also subject to governance. F is effectively 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 defined in Figure 1. – \(\Delta\): Staking amount, denominated in AVAX. This value defines 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 redefined upon first use. In line with the principle of predictability in a financial 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 difficult to change it again immediately and by a large amount. These difficulty 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 flexibility for the long term. 340
Présentation de la plateforme
Dans cette section, nous fournissons un aperçu architectural de la plateforme et discutons de diverses mises en œuvre détails. La plateforme Avalanche sépare clairement trois préoccupations : les chaînes (et les actifs construits au-dessus), l'exécution environnements et déploiement. 3.1 Architecture 145 Sous-réseaux Un sous-réseau, ou sous-réseau, est un ensemble dynamique de validator travaillant ensemble pour parvenir à un consensus. sur l'état d'un ensemble de blockchains. Chaque blockchain est validé par un sous-réseau, et un sous-réseau peut valider arbitrairement de nombreux blockchain. Un validator peut être membre d'un nombre arbitraire de sous-réseaux. Un sous-réseau décide qui peut y entrer, et peut exiger que ses validators constituants possèdent certaines propriétés. Le Avalanche La plate-forme prend en charge la création et l’exploitation d’un nombre arbitraire de sous-réseaux. Afin de créer un nouveau sous-réseau 150 ou pour rejoindre un sous-réseau, il faut payer des frais libellés en $AVAX.
6 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer Le modèle de sous-réseau offre de nombreux avantages : – Si un validator ne se soucie pas des blockchain dans un sous-réseau donné, il ne rejoindra tout simplement pas ce sous-réseau. Cela réduit le trafic réseau, ainsi que les ressources de calcul requises des validator. C'est dans contrairement aux autres projets blockchain, dans lesquels chaque validator doit valider chaque transaction, même 155 ceux dont ils ne se soucient pas. – Puisque les sous-réseaux décident qui peut y accéder, on peut créer des sous-réseaux privés. Autrement dit, chaque blockchain dans le sous-réseau est validé uniquement par un ensemble de validator de confiance. – On peut créer un sous-réseau où chaque validator possède certaines propriétés. Par exemple, on pourrait créer un sous-réseau où chaque validator est situé dans une certaine juridiction, ou où chaque validator est lié par certains 160 contrat du monde réel. Cela peut être bénéfique pour des raisons de conformité. Il existe un sous-réseau spécial appelé sous-réseau par défaut. Il est validé par tous les validator. (C'est-à-dire pour pour valider n'importe quel sous-réseau, il faut également valider le sous-réseau par défaut.) Le sous-réseau par défaut valide un ensemble de blockchain prédéfinis, y compris le blockchain où $AVAX vit et est échangé. Machines virtuelles Chaque blockchain est une instance d'une machine virtuelle (VM). Une VM est un modèle pour un 165 blockchain, tout comme une classe, est un modèle pour un objet dans un langage de programmation orienté objet. Le L'interface, l'état et le comportement d'un blockchain sont définis par la VM que le blockchain exécute. Ce qui suit les propriétés d'un blockchain, et autres, sont définies par une VM : – Le contenu d'un bloc – La transition d'état qui se produit lorsqu'un bloc est accepté 170 – Les API exposées par le blockchain et leurs points de terminaison – Les données conservées sur le disque On dit qu'un blockchain « utilise » ou « exécute » une VM donnée. Lors de la création d'un blockchain, on précise la VM il fonctionne, ainsi que l'état de genèse du blockchain. Un nouveau blockchain peut être créé à l'aide d'un La VM, ou un développeur, peut en coder une nouvelle. Il peut y avoir arbitrairement plusieurs blockchain qui exécutent la même VM. 175 Chaque blockchain, même ceux exécutant la même VM, est logiquement indépendant des autres et conserve son propre État. 3.2 Amorçage La première étape pour participer à Avalanche est le bootstrap. Le processus se déroule en trois étapes : connexion pour semer des ancres, la découverte de réseaux et d'états, et devenir un validator. 180 Seed Anchors Tout système en réseau de pairs qui fonctionne sans autorisation (c'est-à-dire codé en dur) un ensemble d’identités nécessite un mécanisme de découverte par les pairs. Dans les réseaux de partage de fichiers peer-to-peer, un ensemble de des trackers sont utilisés. Dans les réseaux cryptographiques, un mécanisme typique est l'utilisation de nœuds DNS seed (que nous référonsAvalanche Plateforme 2020/06/30 7 comme ancres de départ), qui comprennent un ensemble d'adresses IP de départ bien définies à partir desquelles les autres membres de le réseau peut être découvert. Le rôle des nœuds de départ DNS est de fournir des informations utiles sur l'ensemble 185 de participants actifs au système. Le même mécanisme est utilisé dans Bitcoin Core [1], dans lequel le Le fichier src/chainparams.cpp du code source contient une liste de nœuds seed codés en dur. La différence entre BTC et Avalanche est que BTC ne nécessite qu'un seul nœud DNS correct, tandis que Avalanche nécessite un simple nœud DNS. la majorité des ancres sont correctes. À titre d'exemple, un nouvel utilisateur peut choisir d'amorcer la vue réseau à travers un ensemble d’échanges bien établis et réputés, dont aucun individuellement n’est digne de confiance. 190 Nous notons cependant que l'ensemble des nœuds d'amorçage n'a pas besoin d'être codé en dur ou statique, et peut être fourni par l'utilisateur, mais pour faciliter l'utilisation, les clients peuvent fournir un paramètre par défaut qui inclut économiquement des acteurs importants, comme les échanges, avec lesquels les clients souhaitent partager une vision du monde. Il n'y a aucun obstacle à devenir une ancre de départ, donc un ensemble d'ancres de départ ne peut pas dicter si un nœud peut ou non entrer le réseau, puisque les nœuds peuvent découvrir le dernier réseau de pairs Avalanche en s'attachant à n'importe quel ensemble de graines 195 ancres. Découverte du réseau et de l'état Une fois connecté aux ancres de départ, un nœud recherche le dernier ensemble de transitions d'état. Nous appelons cet ensemble de transitions d’état la frontière acceptée. Pour une chaîne, la frontière acceptée est le dernier bloc accepté. Pour un DAG, la frontière acceptée est l'ensemble des sommets qui sont acceptés, mais qui ont pas d'enfants acceptés. Après avoir collecté les frontières acceptées à partir des ancres de départ, les transitions d'état qui 200 sont acceptés par une majorité des ancres de semences est défini comme étant accepté. L'état correct est ensuite extrait en se synchronisant avec les nœuds échantillonnés. Tant qu'il y a une majorité de nœuds corrects dans l'ancre de départ défini, alors les transitions d'état acceptées doivent avoir été marquées comme acceptées par au moins un nœud correct. Ce processus de découverte d'état est également utilisé pour la découverte de réseau. L’ensemble des membres du réseau est défini sur la chaîne validator. Par conséquent, la synchronisation avec la chaîne validator permet au nœud de découvrir 205 l'ensemble actuel de validators. La chaîne validator sera abordée plus en détail dans la section suivante. 3.3 Sybil Contrôle et adhésion Les protocoles de consensus fournissent leurs garanties de sécurité en supposant que jusqu'à un certain nombre de seuils des membres du système pourrait être contradictoire. Une attaque Sybil, dans laquelle un nœud inonde le réseau à moindre coût avec des identités malveillantes, peuvent invalider trivialement ces garanties. Fondamentalement, une telle attaque ne peut être 210 dissuadé par l'échange de présence avec la preuve d'une ressource difficile à forger [3]. Les systèmes antérieurs ont exploré l'utilisation des mécanismes de dissuasion Sybil qui couvrent proof-of-work (PoW), proof-of-stake (PoS), preuve du temps écoulé (POET), preuve d'espace et de temps (PoST) et preuve d'autorité (PoA). À la base, tous ces mécanismes remplissent une fonction identique : ils exigent que chaque participant ait une certaine « peau dans le jeu » sous la forme d’un engagement économique, qui à son tour fournit un avantage économique. 215 barrière contre les mauvaises conduites de ce participant. Tous impliquent une forme de participation, que ce soit sous la forme de plates-formes minières et d'alimentation hash (PoW), d'espace disque (PoST), de matériel de confiance (POET) ou d'une identité approuvée (PoA). Cet enjeu constitue la base d'un coût économique que les participants doivent supporter pour acquérir une voix. Pour Par exemple, dans Bitcoin, la capacité de contribuer à des blocs valides est directement proportionnelle à la puissance hash du participant proposant. Malheureusement, il y a également eu une confusion importante entre les protocoles de consensus8 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer par rapport aux mécanismes de contrôle Sybil. Nous notons que le choix des protocoles consensuels est, pour l'essentiel, orthogonal au choix du mécanisme de commande Sybil. Cela ne veut pas dire que les mécanismes de contrôle Sybil sont des remplacements immédiats les uns pour les autres, car un choix particulier peut avoir des implications sur le sous-jacent garanties du protocole de consensus. Cependant, la famille Snow* peut être couplée à plusieurs de ces produits connus. mécanismes, sans modification significative. 225 En fin de compte, pour des raisons de sécurité et pour garantir que les incitations des participants sont alignées au bénéfice de le réseau, $AVAX choisit PoS comme mécanisme de contrôle principal de Sybil. Certaines formes de participation sont intrinsèquement centralisé : la fabrication de plates-formes minières (PoW), par exemple, est intrinsèquement centralisée entre les mains de quelques des personnes possédant le savoir-faire approprié et ayant accès aux dizaines de brevets nécessaires pour un VLSI compétitif fabrication. De plus, l’exploitation minière PoW perd de la valeur en raison des importantes subventions annuelles accordées aux mineurs. De même, 230 l'espace disque appartient en grande partie aux grands opérateurs de centres de données. De plus, tous les mécanismes de contrôle Sybil qui génèrent des coûts permanents, par ex. les coûts d'électricité pour hashing, la valeur des fuites hors de l'écosystème, sans parler détruire l'environnement. Ceci, à son tour, réduit l'enveloppe de faisabilité pour le token, dans lequel un une évolution des prix sur une courte période peut rendre le système inutilisable. La preuve de travail sélectionne intrinsèquement des mineurs qui ont les connexions nécessaires pour se procurer de l’électricité à bas prix, ce qui n’a pas grand-chose à voir avec la capacité des mineurs 235 pour sérialiser les transactions ou leurs contributions à l’écosystème global. Parmi ces options, nous choisissons proof-of-stake, parce qu'il est vert, accessible et ouvert à tous. Nous notons cependant que même si $AVAX utilise PoS, le réseau Avalanche permet de lancer des sous-réseaux avec PoW et PoS. Le jalonnement est un mécanisme naturel de participation à un réseau ouvert car il permet un échange économique direct. Argument : la probabilité de succès d’une attaque est directement proportionnelle à un coût monétaire bien défini 240 fonction. En d’autres termes, les nœuds concernés sont économiquement motivés à ne pas s’engager dans un comportement qui pourrait nuire à la valeur de leur participation. De plus, cette participation n'entraîne aucun coût d'entretien supplémentaire (autres puis le coût d'opportunité d'investir dans un autre actif), et possède la propriété qui, contrairement à l'équipement minier, est entièrement consommé s’il est utilisé lors d’une attaque catastrophique. Pour les opérations PoW, l'équipement minier peut être simplement réutilisés ou – si le propriétaire le décide – entièrement revendus sur le marché. 245 Un nœud souhaitant entrer dans le réseau peut le faire librement en posant d'abord un enjeu immobilisé. pendant la durée de la participation au réseau. L'utilisateur détermine le montant et la durée de la mise. Une fois acceptée, une mise ne peut être annulée. L'objectif principal est de garantir que les nœuds partagent substantiellement le même vue globalement stable du réseau. Nous prévoyons de fixer le temps minimum staking sur ordre d'un semaine. 250 Contrairement à d'autres systèmes qui proposent également un mécanisme PoS, $AVAX n'utilise pas de slashing, et par conséquent, toutes les mises sont restituées à l'expiration de la période staking. Cela évite des scénarios indésirables tels que une panne logicielle ou matérielle client entraînant une perte de pièces. Cela correspond à notre philosophie de conception de construire une technologie prévisible : les token jalonnés ne sont pas en danger, même en présence de logiciels ou défauts matériels. 255 Dans Avalanche, un nœud qui souhaite participer émet une transaction de participation spéciale sur la chaîne validator. Les transactions de staking nomment un montant à miser, la clé staking du participant qui est staking, la durée, et l'heure à laquelle la validation commencera. Une fois la transaction acceptée, les fonds seront bloqués jusqu'à ce que le fin de la période staking. Le montant minimum autorisé est décidé et appliqué par le système. L'enjeu Le montant placé par un participant a des implications à la fois sur le degré d'influence du participant dans leAvalanche Plateforme 2020/06/30 9 processus de consensus, ainsi que la récompense, comme nous le verrons plus loin. La durée staking spécifiée doit être comprise entre δmin et δmax, les délais minimum et maximum pendant lesquels toute mise peut être verrouillée. Comme avec le Montant staking, la période staking a également des implications sur la récompense dans le système. La perte ou le vol du La clé staking ne peut pas entraîner une perte d'actifs, car la clé staking est utilisée uniquement dans le processus de consensus, pas pour les actifs. transfert. 265 3.4 Contrats intelligents en $AVAX Au lancement, Avalanche prend en charge les smart contract standards basés sur Solidity via la machine virtuelle Ethereum (EVM). Nous prévoyons que la plateforme prendra en charge un ensemble plus riche et plus puissant de smart contract des outils, notamment : – Contrats intelligents avec exécution hors chaîne et vérification en chaîne. 270 – Contrats intelligents avec exécution parallèle. Tous les smart contract qui ne fonctionnent pas sur le même état dans n'importe quel sous-réseau dans Avalanche pourra s'exécuter en parallèle. – Un Solidity amélioré, appelé Solidity++. Ce nouveau langage prendra en charge le versioning et les mathématiques sécurisées et l'arithmétique à virgule fixe, un système de types amélioré, la compilation vers LLVM et l'exécution juste à temps. Si un développeur nécessite la prise en charge de EVM mais souhaite déployer des smart contract dans un sous-réseau privé, il 275 peut créer directement un nouveau sous-réseau. C'est ainsi que Avalanche permet le partitionnement spécifique à des fonctionnalités via les sous-réseaux. De plus, si un développeur a besoin d'interactions avec le logiciel intelligent Ethereum actuellement déployé contrats, ils peuvent interagir avec le sous-réseau Athereum, qui est une cuillère de Ethereum. Enfin, si un développeur nécessite un environnement d'exécution différent de la machine virtuelle Ethereum, ils peuvent choisir de déployer leur smart contract via un sous-réseau qui implémente un environnement d'exécution différent, tel que DAML 280 ou WASM. Les sous-réseaux peuvent prendre en charge des fonctionnalités supplémentaires au-delà du comportement des VM. Par exemple, les sous-réseaux peuvent appliquer les exigences de performances pour les nœuds validator plus gros qui contiennent des smart contract pendant des périodes plus longues, ou validators qui détiennent un contrat en privé. 4 Gouvernance et jeton $AVAX 4.1 Le jeton natif $AVAX 285 Politique monétaire Le token natif, $AVAX, est une offre plafonnée, où le plafond est fixé à 720 000 000 tokens, avec 360 000 000 token disponibles au lancement du réseau principal. Cependant, contrairement aux autres token à approvisionnement plafonné qui En fonction du taux de frappe perpétuel, la politique monétaire de \(AVAX is designed to react to changing economic conditions. In particular, the objective of \)AVAX consiste à équilibrer les incitations des utilisateurs à miser sur le token. plutôt que de l’utiliser pour interagir avec la variété de services disponibles sur la plateforme. Participants à la plateforme 290 agissent collectivement comme une banque de réserve décentralisée. Les leviers disponibles sur Avalanche sont staking récompenses, frais, et les parachutages, qui sont tous influencés par des paramètres gouvernables. Les récompenses de mise sont fixées par la gouvernance en chaîne et sont régies par une fonction conçue pour ne jamais dépasser l'offre plafonnée. Le jalonnement peut être induit en augmentant les frais ou en augmentant les récompenses staking. D’un autre côté, nous pouvons induire un engagement accru avec les services de la plateforme Avalanche en réduisant les frais et en diminuant la récompense staking.10 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer Utilisations Paiements Les véritables paiements peer-to-peer décentralisés sont en grande partie un rêve non réalisé pour l'industrie en raison de le manque de performance actuel des opérateurs historiques. $AVAX est aussi puissant et facile à utiliser que les paiements utilisant Visa, permettant des milliers de transactions dans le monde chaque seconde, de manière totalement décentralisée et sans confiance. De plus, pour les commerçants du monde entier, $AVAX offre une proposition de valeur directe par rapport à Visa, à savoir une valeur inférieure 300 frais. Jalonnement : sécurisation du système Sur la plateforme Avalanche, le contrôle sybil est réalisé via staking. Afin pour valider, un participant doit verrouiller des pièces ou miser. Les validateurs, parfois appelés « jalonneurs », sont rémunérés pour leurs services de validation sur la base du montant staking et de la durée staking, entre autres propriétés. La fonction de rémunération choisie doit minimiser la variance, garantissant que les gros intervenants ne 305 reçoivent de manière disproportionnée une plus grande compensation. Les participants ne sont également soumis à aucun facteur de « chance », comme dans Exploitation minière PoW. Un tel système de récompense décourage également la formation de pools miniers ou de staking permettant de véritablement participation décentralisée et sans confiance au réseau. Swaps atomiques En plus de fournir la sécurité de base du système, le $AVAX token sert d'unité universelle d'échange. À partir de là, la plate-forme Avalanche sera en mesure de prendre en charge les échanges atomiques sans confiance de manière native sur 310 la plateforme permettant des échanges natifs et véritablement décentralisés de tout type d'actifs directement sur Avalanche. 4.2 Gouvernance La gouvernance est essentielle au développement et à l’adoption de toute plateforme car, comme pour tous les autres types des systèmes – Avalanche sera également confronté à une évolution et des mises à jour naturelles. $AVAX fournit une gouvernance en chaîne pour les paramètres critiques du réseau où les participants peuvent voter sur les modifications apportées au réseau et 315 régler démocratiquement les décisions de mise à niveau du réseau. Cela inclut des facteurs tels que le montant minimum de staking, taux de frappe, ainsi que d'autres paramètres économiques. Cela permet à la plate-forme d'effectuer efficacement une optimisation dynamique des paramètres via une foule oracle. Cependant, contrairement à certaines autres plateformes de gouvernance là-bas, Avalanche ne permet pas de modifications illimitées des aspects arbitraires du système. Au lieu de cela, seul un un nombre prédéterminé de paramètres peut être modifié via la gouvernance, rendant le système plus prévisible 320 et accroître la sécurité. De plus, tous les paramètres gouvernables sont soumis à des limites dans des délais précis, introduire une hystérésis et garantir que le système reste prévisible sur de courtes périodes. Un processus réalisable pour trouver des valeurs globalement acceptables pour les paramètres du système est essentiel pour les systèmes décentralisés sans gardiens. Avalanche peut utiliser son mécanisme de consensus pour créer un système qui permet à quiconque de proposer des transactions spéciales qui sont, par essence, des sondages à l'échelle du système. Tout nœud participant peut 325 émettre de telles propositions. Le taux de récompense nominal est un paramètre important qui affecte toute monnaie, qu'elle soit numérique ou foncière. Malheureusement, les crypto-monnaies qui corrigent ce paramètre peuvent être confrontées à divers problèmes, notamment la déflation ou l'inflation. À cette fin, le taux de récompense nominal est soumis à une gouvernance, dans des limites préétablies. Cela va permettre aux détenteurs de token de choisir si $AVAX est finalement plafonné, non plafonné ou même déflationniste.Avalanche Plateforme 2020/06/30 11 Les frais de transaction, désignés par l'ensemble F, sont également soumis à la gouvernance. F est en fait un tuple qui décrit les frais associés aux différentes instructions et transactions. Enfin, staking fois et montants sont également gouvernables. La liste de ces paramètres est définie sur la figure 1. – ∆ : Montant du Staking, libellé en $AVAX. Cette valeur définit la mise minimale requise pour être placée comme caution avant de participer au système. – δmin : Le temps minimal requis pour qu'un nœud s'implante dans le système. – δmax : La durée maximale qu'un nœud peut miser. – ρ : (π∆, τδmin) →R : La fonction du taux de récompense, également appelée taux de frappe, détermine la récompense a le participant peut réclamer en fonction de son montant staking étant donné un certain nombre de nœuds π divulgués publiquement dont il est propriétaire, sur une période de τ δmin consécutives, telle que τδmin ≤δmax. – F : la structure des frais, qui est un ensemble de paramètres de frais gouvernables qui spécifient les coûts de diverses transactions. Fig. 1. Principaux paramètres non consensuels utilisés dans Avalanche. Toute notation est redéfinie lors de la première utilisation. Conformément au principe de prévisibilité dans un système financier, la gouvernance dans $AVAX a une hystérésis, ce qui signifie que les modifications apportées aux paramètres dépendent fortement de leurs modifications récentes. Il y a deux limites 335 associés à chaque paramètre gouvernable : temps et plage. Une fois qu'un paramètre est modifié à l'aide d'une gouvernance transaction, il devient très difficile de le changer à nouveau immédiatement et pour un montant important. Ces difficultés et les contraintes de valeur se relâchent à mesure que le temps s'écoule depuis le dernier changement. Globalement, cela empêche le système de changeant radicalement sur une courte période de temps, permettant aux utilisateurs de prédire en toute sécurité les paramètres du système dans le à court terme, tout en bénéficiant d'un contrôle et d'une flexibilité forts sur le long terme. 340
Governance
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-specific 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 differ 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 differ 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 efficient. 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 first 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 different 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 first-hand in governance. Any token holder can have a vote in selecting key financial parameters and in choosing how the system evolves. Interoperable and Flexible Avalanche is designed to be a universal and flexible 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 identifiers, labeled “v.[0-9].[0-9].[0-100]”, where the first number identifies major releases, the second number identifies minor releases, and the third number 55 identifies patches. The first 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.
Gouvernance
1.1 Avalanche Buts et principes Avalanche est une plateforme blockchain hautes performances, évolutive, personnalisable et sécurisée. Il cible trois cas d'utilisation généraux : 15 – Création de blockchain spécifiques à l'application, couvrant les autorisations (privées) et sans autorisation (publiques) déploiements. – Création et lancement d’applications hautement évolutives et décentralisées (Dapps). – Créer des actifs numériques arbitrairement complexes avec des règles, des clauses et des avenants personnalisés (actifs intelligents). 1 Les déclarations prospectives se rapportent généralement à des événements futurs ou à nos performances futures. Cela inclut, mais n'est pas limité aux performances projetées de Avalanche ; l'évolution attendue de son activité et de ses projets ; exécution de sa vision et de sa stratégie de croissance ; et la réalisation de projets actuellement en cours, en développement ou sinon à l'étude. Les déclarations prospectives représentent les convictions et hypothèses de notre direction. seulement à compter de la date de cette présentation. Ces déclarations ne constituent pas des garanties de performances futures et des il ne faut pas s’y fier. Ces déclarations prospectives impliquent nécessairement des informations connues et inconnues. risques, qui peuvent faire en sorte que la performance réelle et les résultats des périodes futures diffèrent sensiblement des projections. exprimé ou implicite dans les présentes. Avalanche n'assume aucune obligation de mettre à jour les déclarations prospectives. Bien que les déclarations prospectives constituent notre meilleure prédiction au moment où elles sont faites, rien ne garantit qu'elles s’avérera exact, car les résultats réels et les événements futurs pourraient différer sensiblement. Le lecteur est averti de ne pas de se fier indûment aux déclarations prospectives.2 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer L'objectif primordial de Avalanche est de fournir une plate-forme unificatrice pour la création, le transfert et le commerce de 20 actifs numériques. Par construction, Avalanche possède les propriétés suivantes : Évolutif Avalanche est conçu pour être massivement évolutif, robuste et efficace. Le principal moteur de consensus est capable de prendre en charge un réseau mondial de centaines de millions d'appareils connectés à Internet, de faible ou de forte puissance, qui fonctionnent de manière transparente, avec de faibles latences et des transactions par seconde très élevées. 25 Secure Avalanche est conçu pour être robuste et offrir une sécurité élevée. Les protocoles de consensus classiques sont conçu pour résister jusqu'à f attaquants, et échouer complètement face à un attaquant de taille f + 1 ou plus grande, et le consensus de Nakamoto n’offre aucune sécurité alors que 51 % des mineurs sont byzantins. En revanche, Avalanche apporte une très forte garantie de sécurité lorsque l'attaquant est en dessous d'un certain seuil, ce qui peut être paramétré par le concepteur du système et fournit une dégradation progressive lorsque l'attaquant dépasse 30 ce seuil. Il peut maintenir les garanties de sécurité (mais pas de vivacité) même lorsque l'attaquant dépasse 51 %. C'est le premier système sans autorisation à fournir des garanties de sécurité aussi solides. Décentralisé Avalanche est conçu pour fournir une décentralisation sans précédent. Cela implique un engagement à plusieurs implémentations client et aucun contrôle centralisé d’aucune sorte. L'écosystème est conçu pour éviter divisions entre classes d’utilisateurs ayant des intérêts différents. Surtout, il n'y a aucune distinction entre les mineurs, 35 développeurs et utilisateurs. Gouvernable et démocratique $AVAX est une plateforme hautement inclusive, qui permet à chacun de se connecter à son réseau et participer à la validation et à la gouvernance. Tout détenteur de token peut voter sélectionner les paramètres financiers clés et choisir la façon dont le système évolue. Interopérable et flexible Avalanche est conçu pour être une infrastructure universelle et flexible pour une multitude 40 de blockchains/actifs, où la base $AVAX est utilisée à des fins de sécurité et comme unité de compte pour l'échange. Le Le système est destiné à prendre en charge, de manière neutre en termes de valeur, de nombreux blockchain à construire dessus. La plateforme est conçu dès le départ pour faciliter le portage de blockchain existants, l'importation de soldes, prendre en charge plusieurs langages de script et machines virtuelles, et prendre en charge de manière significative plusieurs déploiements scénarios. 45 Aperçu Le reste de cet article est divisé en quatre sections principales. La section 2 présente les détails de moteur qui alimente la plateforme. La section 3 traite du modèle architectural derrière la plate-forme, y compris sous-réseaux, machines virtuelles, démarrage, adhésion et staking. La section 4 explique la gouvernance modèle qui permet des changements dynamiques dans les paramètres économiques clés. Enfin, dans la section 5, nous explorons diverses sujets d'intérêt périphériques, y compris les optimisations potentielles, la cryptographie post-quantique et les 50 adversaires.
Avalanche Plateforme 2020/06/30 3 Convention de dénomination Le nom de la plateforme est Avalanche et est généralement appelé « le Avalanche ». plateforme », et est interchangeable/synonyme de « le réseau Avalanche », ou – simplement – Avalanche. Les bases de code seront publiées en utilisant trois identifiants numériques, intitulés « v.[0-9].[0-9].[0-100] », où le le premier numéro identifie les versions majeures, le deuxième numéro identifie les versions mineures et le troisième numéro 55 identifie les correctifs. La première version publique, nommée Avalanche Borealis, est la version 1.0.0. Le natif token de la plateforme s’appelle « $AVAX ». La famille de protocoles de consensus utilisée par la plateforme Avalanche est appelée la famille Snow*. Il existe trois instanciations concrètes, appelées Avalanche, Snowman et Glacial.
Discussion
Discussion
5.1 Optimizations Pruning Many blockchain platforms, especially those implementing Nakamoto consensus such as Bitcoin, suffer 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 different 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 specific subparts of the entire global state; lastly, in transaction sharding, participants agree to separate the processing of incoming transactions. In Avalanche Borealis, the first 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, specifically 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. Effectively, 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 difficult 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 effects. 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 first-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 inefficient and imposes high operating costs, the Avalanche is lightweight, fast, scalable, secure, and efficient. 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 influencing 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
Discussion
5.1 Optimisations Élagage de nombreuses plateformes blockchain, en particulier celles mettant en œuvre le consensus Nakamoto telles que Bitcoin, souffrent d’une croissance étatique perpétuelle. En effet, par protocole, ils doivent stocker l’intégralité de l’historique des transactions. Cependant, pour qu’un blockchain se développe de manière durable, il doit être capable d’élaguer l’histoire ancienne. 345 Ceci est particulièrement important pour les blockchain qui prennent en charge des performances élevées, tels que Avalanche. La taille est simple dans la famille Snow*. Contrairement à Bitcoin (et aux protocoles similaires), où l'élagage n'est pas possible selon les exigences algorithmiques, dans $AVAX, les nœuds n'ont pas besoin de maintenir des parties du DAG qui sont profonds et très engagés. Ces nœuds n'ont pas besoin de prouver d'antécédents pour un nouveau bootstrap. nœuds, et doivent donc simplement stocker l'état actif, c'est-à-dire les soldes actuels, ainsi que les soldes non engagés 350 transactions. Types de clients Avalanche peut prendre en charge trois types de clients différents : archivage, complet et léger. Archivage Les nœuds stockent l'historique complet du sous-réseau $AVAX, du sous-réseau staking et du sous-réseau smart contract, tous les12 Kevin Sekniqi, Daniel Laine, Stephen Buttolph et Emin G¨un Sirer chemin vers la genèse, ce qui signifie que ces nœuds servent de nœuds d’amorçage pour les nouveaux nœuds entrants. De plus ces nœuds peuvent stocker l'historique complet des autres sous-réseaux pour lesquels ils choisissent d'être validator. Archivage 355 les nœuds sont généralement des machines dotées de capacités de stockage élevées qui sont payées par d'autres nœuds lors du téléchargement ancien état. Les nœuds complets, en revanche, participent à la validation, mais au lieu de stocker tout l'historique, ils stockez simplement l'état actif (par exemple, l'ensemble UTXO actuel). Enfin, pour ceux qui ont simplement besoin d'interagir en toute sécurité avec le réseau utilisant la quantité de ressources la plus minimale, Avalanche prend en charge les clients légers qui peuvent prouver qu'une transaction a été validée sans avoir besoin de télécharger ou de synchroniser l'historique. Lumière 360 les clients s'engagent dans la phase d'échantillonnage répétée du protocole pour garantir un engagement sûr et à l'échelle du réseau consensus. Par conséquent, les clients légers dans Avalanche offrent les mêmes garanties de sécurité que les nœuds complets. Sharding Le Sharding est le processus de partitionnement de diverses ressources système afin d'augmenter les performances. et réduire la charge. Il existe différents types de mécanismes de partitionnement. Dans le partage de réseau, l'ensemble des participants est divisé en sous-réseaux distincts afin de réduire la charge algorithmique ; dans le partage d'état, les participants s'accordent sur 365 stocker et maintenir uniquement des sous-parties spécifiques de l'ensemble de l'état global ; enfin, dans le sharding des transactions, les participants conviennent de séparer le traitement des transactions entrantes. Dans Avalanche Borealis, la première forme de partitionnement existe via la fonctionnalité de sous-réseaux. Pour par exemple, on peut lancer un sous-réseau aurifère et un autre sous-réseau immobilier. Ces deux sous-réseaux peuvent exister entièrement dans parallèle. Les sous-réseaux interagissent uniquement lorsqu'un utilisateur souhaite acheter des contrats immobiliers en utilisant ses avoirs en or, 370 à ce stade, Avalanche permettra un échange atomique entre les deux sous-réseaux. 5.2 Préoccupations Cryptographie post-quantique La cryptographie post-quantique a récemment attiré une grande attention en raison des progrès dans le développement des ordinateurs et des algorithmes quantiques. Le souci du quantum ordinateurs est qu'ils peuvent briser certains des protocoles cryptographiques actuellement déployés, en particulier numériques. 375 signatures. Le modèle de réseau Avalanche autorise n'importe quel nombre de machines virtuelles, il prend donc en charge un système résistant aux quantiques. machine virtuelle avec un mécanisme de signature numérique approprié. Nous prévoyons plusieurs types de signature numérique schémas à déployer, y compris les signatures basées sur RLWE à résistance quantique. Le mécanisme du consensus ne suppose aucun type de cryptographie lourde pour son fonctionnement principal. Compte tenu de cette conception, il est simple de étendez le système avec une nouvelle machine virtuelle qui fournit des primitives cryptographiques sécurisées quantiques. 380 Adversaires réalistes Le document Avalanche [6] offre de très fortes garanties en présence d'un adversaire puissant et hostile, connu comme un adversaire adaptatif dans le modèle point à point complet. Dans en d’autres termes, l’adversaire a à tout moment un accès complet à l’état de chaque nœud correct, connaît le choix aléatoires de tous les nœuds corrects, et peut mettre à jour son propre état à tout moment, avant et après le Le nœud correct a la possibilité de mettre à jour son propre état. En effet, cet adversaire est tout puissant, à l'exception de 385 la possibilité de mettre à jour directement l'état d'un nœud correct ou de modifier la communication entre le bon nœud nœuds. Néanmoins, en réalité, un tel adversaire est purement théorique puisque les mises en œuvre pratiques du l’adversaire le plus puissant possible sont limités aux approximations statistiques de l’état du réseau. Par conséquent, dans En pratique, nous nous attendons à ce que les attaques correspondant aux pires scénarios soient difficiles à déployer.Avalanche Plateforme 2020/06/30 13 Inclusion et égalité Un problème courant dans les monnaies sans autorisation est celui du « devenir riche ». 390 plus riche ». Il s’agit d’une préoccupation légitime, puisqu’un système PoS mal mis en œuvre peut en fait permettre la création de richesse soit attribuée de manière disproportionnée aux détenteurs déjà importants de participations dans le système. Un Un exemple simple est celui des protocoles de consensus basés sur les dirigeants, dans lesquels un sous-comité ou un leader désigné collecte toutes les récompenses au cours de son fonctionnement, et où la probabilité d'être choisi pour collecter les récompenses est proportionnel à la mise, générant de forts effets cumulatifs de récompense. De plus, dans des systèmes tels que Bitcoin, 395 il existe un phénomène de « grand devenir plus grand » dans lequel les grands mineurs bénéficient d'une prime par rapport aux plus petits en termes de de moins d'orphelins et de moins de travail perdu. En revanche, Avalanche emploie une répartition égalitaire de la frappe : chaque participant au protocole staking est récompensé équitablement et proportionnellement en fonction de sa participation. En permettant à un très grand nombre de personnes de participer directement à staking, Avalanche peut accueillir des millions de personnes à participer de manière égale à staking. Le montant minimum requis pour participer au 400 le protocole sera soumis à la gouvernance, mais il sera initialisé à une valeur faible pour encourager une large participation. Cela implique également que la délégation n'est pas tenue de participer avec une petite allocation. 6 Conclusion Dans cet article, nous avons discuté de l'architecture de la plateforme Avalanche. Par rapport aux autres plateformes actuelles, qui soit exécutent des protocoles de consensus de style classique et sont donc intrinsèquement non évolutifs, soit utilisent 405 Consensus à la Nakamoto, inefficace et imposant des coûts de fonctionnement élevés, le Avalanche est léger, rapide, évolutif, sécurisé et efficace. Le token natif, qui sert à sécuriser le réseau et à payer divers coûts d’infrastructure sont simples et rétrocompatibles. $AVAX a une capacité au-delà des autres propositions pour atteindre des niveaux de décentralisation plus élevés, résister aux attaques et évoluer vers des millions de nœuds sans aucun quorum ou l'élection d'un comité, et donc sans imposer de limites à la participation. 410 Outre le moteur de consensus, Avalanche innove et introduit des éléments simples mais importants des idées en matière de gestion des transactions, de gouvernance et une multitude d'autres composants non disponibles sur d'autres plates-formes. Chaque participant au protocole aura une voix pour influencer l'évolution du protocole à tout moment, rendu possible par un mécanisme de gouvernance puissant. Avalanche prend en charge une personnalisation élevée, permettant Plug-and-play presque instantané avec les blockchain existants. 415