Avalanche: Eine neue Familie von Konsensprotokollen

Avalanche Platform Whitepaper

بقلم Team Rocket and Emin Gün Sirer · 2018

وضع فردي avalabs.org

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.

Zusammenfassung

Avalanche Plattform 30.06.2020 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Zusammenfassung. Dieses Dokument bietet einen Architekturüberblick über die erste Version der Avalanche-Plattform. Codename Avalanche Borealis. Einzelheiten zur Wirtschaftlichkeit des nativen token mit der Bezeichnung $AVAX finden Sie hier 5 Führen Sie den Leser zum begleitenden token Dynamikpapier [2]. Offenlegung: Die in diesem Dokument beschriebenen Informationen sind vorläufig und können jederzeit geändert werden. Darüber hinaus kann dieses Papier „zukunftsgerichtete Aussagen“1 enthalten Git-Commit: 7497e4a4ba0a1ea2dc2a111bc6deefbf3023708e 1 Einführung 10 Dieses Dokument bietet einen Architekturüberblick über die Avalanche-Plattform. Der Schwerpunkt liegt auf den drei Schlüsseln Unterscheidungsmerkmale der Plattform: die Engine, das Architekturmodell und der Governance-Mechanismus. 1.1 Avalanche Ziele und Prinzipien Avalanche ist eine leistungsstarke, skalierbare, anpassbare und sichere blockchain-Plattform. Es zielt auf drei ab breite Anwendungsfälle: 15 – Erstellen anwendungsspezifischer blockchains, die berechtigte (private) und erlaubnislose (öffentliche) umfassen Bereitstellungen. – Erstellen und Starten hochskalierbarer und dezentraler Anwendungen (Dapps). – Aufbau beliebig komplexer digitaler Assets mit benutzerdefinierten Regeln, Vereinbarungen und Fahrern (intelligente Assets). 1 Zukunftsgerichtete Aussagen beziehen sich im Allgemeinen auf zukünftige Ereignisse oder unsere zukünftige Leistung. Dies schließt ein, ist es aber nicht beschränkt auf die geplante Leistung von Avalanche; die erwartete Entwicklung seines Geschäfts und seiner Projekte; Ausführung seiner Vision und Wachstumsstrategie; und Abschluss von Projekten, die derzeit laufen, sich in der Entwicklung befinden oder ansonsten in Erwägung gezogen. Zukunftsgerichtete Aussagen spiegeln die Überzeugungen und Annahmen unseres Managements wider erst ab dem Datum dieser Präsentation. Diese Aussagen stellen keine Garantien für zukünftige Leistungen dar und sind unzulässig Man sollte sich nicht auf sie verlassen. Solche zukunftsgerichteten Aussagen betreffen zwangsläufig Bekanntes und Unbekanntes Risiken, die dazu führen können, dass die tatsächlichen Leistungen und Ergebnisse in zukünftigen Zeiträumen erheblich von den Prognosen abweichen hierin ausgedrückt oder impliziert. Avalanche übernimmt keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren. Obwohl Bei zukunftsgerichteten Aussagen handelt es sich um unsere bestmöglichen Vorhersagen zum Zeitpunkt ihrer Äußerung. Wir können nicht garantieren, dass dies der Fall ist werden sich als korrekt erweisen, da tatsächliche Ergebnisse und zukünftige Ereignisse erheblich abweichen können. Der Leser wird davor gewarnt sich unangemessen auf zukunftsgerichtete Aussagen zu verlassen.

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

Einführung

10 Dieses Dokument bietet einen Architekturüberblick über die Avalanche-Plattform. Der Schwerpunkt liegt auf den drei Schlüsseln Unterscheidungsmerkmale der Plattform: die Engine, das Architekturmodell und die

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.

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

Avalanche Platform 2020/06/30 5 – High Throughput. Snow protocols, which can build a linear chain or a DAG, reach thousands of transactions per second (5000+ tps), while retaining full decentralization. New blockchain solutions that claim 130 high TPS typically trade 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.

Der Motor

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

60 Die Diskussion der Avalanche-Plattform beginnt mit der Kernkomponente, die die Plattform antreibt: dem Konsens-Engine. Hintergrund Verteilte Zahlungen und – allgemeiner – Berechnungen erfordern eine Vereinbarung zwischen einer Gruppe von Maschinen. Daher liegen Konsensprotokolle vor, die es einer Gruppe von Knoten ermöglichen, eine Einigung zu erzielen Herzstück von blockchains sowie fast jedem eingesetzten großen industriellen verteilten System. Das Thema 65 wurde fast fünf Jahrzehnte lang eingehend untersucht, und dieser Versuch hat bis heute nur zwei Familien hervorgebracht von Protokollen: klassische Konsensprotokolle, die auf All-to-All-Kommunikation basieren, und Nakamoto-Konsens, Dies basiert auf proof-of-work-Mining in Verbindung mit der Longest-Chain-Regel. Während klassische Konsensprotokolle können eine geringe Latenz und einen hohen Durchsatz haben, sie lassen sich jedoch nicht auf eine große Anzahl von Teilnehmern skalieren, und das ist auch nicht der Fall robust angesichts von Mitgliedschaftsänderungen, die sie größtenteils in die Erlaubnisliste verwiesen haben 70 statische Bereitstellungen. Nakamoto-Konsensprotokolle [5, 7, 4] hingegen sind robust, leiden aber unter Hohe Bestätigungslatenzen, geringer Durchsatz und ein konstanter Energieaufwand für ihre Sicherheit. Die von Avalanche eingeführte Snow-Protokollfamilie kombiniert die besten Eigenschaften klassischer Konsensprotokolle mit den besten Eigenschaften des Nakamoto-Konsenses. Basierend auf einem einfachen Netzwerk-Sampling-Mechanismus, Sie erreichen eine geringe Latenz und einen hohen Durchsatz, ohne dass die genaue Mitgliedschaft vereinbart werden muss 75 System. Sie skalieren gut von Tausenden bis zu Millionen von Teilnehmern mit direkter Beteiligung am Konsensprotokoll. Darüber hinaus nutzen die Protokolle kein PoW-Mining und vermeiden daher dessen exorbitante Nutzung Energieverbrauch und daraus resultierender Wertverlust im Ökosystem, was zu leichten, umweltfreundlichen und geräuscharmen Produkten führt Protokolle. Mechanismus und Eigenschaften Die Snow-Protokolle funktionieren durch wiederholtes Abtasten des Netzwerks. Jeder Knoten 80 fragt eine kleine, zufällig ausgewählte Menge von Nachbarn mit konstanter Größe ab und ändert seinen Vorschlag, wenn eine Supermehrheit vorliegt unterstützt einen anderen Wert. Die Proben werden wiederholt, bis die Konvergenz erreicht ist, was schnell geschieht Normalbetrieb. Wir verdeutlichen die Funktionsweise anhand eines konkreten Beispiels. Zunächst wird eine Transaktion erstellt einem Benutzer übermittelt und an einen Validierungsknoten gesendet, bei dem es sich um einen Knoten handelt, der am Konsensverfahren teilnimmt. Dann ist es so 85 durch Klatschen an andere Knoten im Netzwerk weitergegeben. Was passiert, wenn dieser Benutzer auch eine widersprüchliche Meldung ausgibt?4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Transaktion, also ein Doublespend? Um zwischen den widersprüchlichen Transaktionen auszuwählen und doppelte Ausgaben zu verhindern, wählt jeder Knoten zufällig eine kleine Teilmenge von Knoten aus und fragt ab, welche der widersprüchlichen Transaktionen Die abgefragten Knoten halten es für gültig. Wenn der abfragende Knoten eine positive Mehrheitsantwort erhält einer Transaktion ändert der Knoten seine eigene Antwort auf diese Transaktion. Jeder Knoten im Netzwerk 90 wiederholt diesen Vorgang, bis sich das gesamte Netzwerk über eine der widersprüchlichen Transaktionen einig ist. Obwohl der grundlegende Funktionsmechanismus recht einfach ist, führen diese Protokolle überraschenderweise zu sehr hohen Ergebnissen wünschenswerte Systemdynamik, die sie für den Einsatz in großem Maßstab geeignet macht. – Erlaubnisfrei, offen für Abwanderung und robust. Die neuesten blockchain-Projekte verwenden klassische Elemente Konsensprotokolle und erfordern daher umfassende Mitgliedschaftskenntnisse. Den gesamten Par95-Satz kennen Teilnehmer sind in geschlossenen, zugelassenen Systemen ausreichend einfach, werden jedoch in offenen, zugelassenen Systemen zunehmend schwieriger. dezentrale Netzwerke. Diese Einschränkung birgt hohe Sicherheitsrisiken für die bestehenden Arbeitsplätze der etablierten Unternehmen solche Protokolle. Im Gegensatz dazu gewährleisten Snow-Protokolle hohe Sicherheitsgarantien, selbst wenn es gut quantifizierte Diskrepanzen zwischen den Netzwerkansichten zweier beliebiger Knoten gibt. Validatoren von Snow-Protokollen Genießen Sie die Möglichkeit zur Validierung ohne kontinuierliche Vollmitgliedschaftskenntnisse. Sie sind daher robust 100 und sehr gut geeignet für öffentliche blockchains. – Skalierbar und dezentral Ein Kernmerkmal der Snow-Familie ist ihre Fähigkeit, ohne Kostenaufwand zu skalieren grundlegende Kompromisse. Snow-Protokolle können auf Zehntausende oder Millionen von Knoten skaliert werden, ohne dass eine Delegation an Teilmengen von validators erforderlich ist. Diese Protokolle verfügen über die beste Systemdezentralisierung ihrer Klasse und ermöglichen Jeder Knoten muss vollständig validiert werden. Die kontinuierliche Teilnahme aus erster Hand hat tiefgreifende Auswirkungen auf die Sicherheit 105 des Systems. In fast jedem proof-of-stake-Protokoll, das versucht, auf eine große Teilnehmergruppe zu skalieren, Die typische Vorgehensweise besteht darin, eine Skalierung zu ermöglichen, indem die Validierung an einen Unterausschuss delegiert wird. Dies bedeutet natürlich, dass die Sicherheit des Systems jetzt genau so hoch ist wie die Korruptionskosten des Systems Unterausschuss. Darüber hinaus unterliegen Unterausschüsse der Kartellbildung. In Protokollen vom Typ Snow ist eine solche Delegation nicht erforderlich, sodass jeder Knotenbetreiber über ein First110 verfügen kann Hand sagen Sie jederzeit im System. Ein anderes Design, das typischerweise als State Sharding bezeichnet wird, versucht Bereitstellung von Skalierbarkeit durch Parallelisierung der Transaktionsserialisierung in unabhängigen Netzwerken von validators. Leider wird die Sicherheit des Systems bei einem solchen Design nur so hoch wie die einfachste Korrumpierbarkeit unabhängige Scherbe. Daher sind weder Unterausschusswahl noch Sharding geeignete Skalierungsstrategien für Krypto-Plattformen. 115 – Adaptiv. Im Gegensatz zu anderen abstimmungsbasierten Systemen erzielen Snow-Protokolle eine höhere Leistung, wenn die Der Gegner ist klein und dennoch äußerst widerstandsfähig gegenüber großen Angriffen. – Asynchron sicher. Snow-Protokolle erfordern im Gegensatz zu Protokollen mit der längsten Kette keine Synchronität arbeiten sicher und verhindern so doppelte Ausgaben, selbst bei Netzwerkpartitionen. Im Bitcoin, Wenn beispielsweise die Synchronizitätsannahme verletzt wird, ist es möglich, mit unabhängigen Zweigen des zu operieren 120 Bitcoin Netzwerk für längere Zeiträume, was alle Transaktionen nach der Gabelung ungültig machen würde heilen. – Geringe Latenz. Die meisten blockchains sind heute nicht in der Lage, Geschäftsanwendungen wie Handel oder Tagesgeschäfte zu unterstützen Massenzahlungen. Es ist einfach nicht praktikabel, Minuten oder sogar Stunden auf die Bestätigung von Transaktionen zu warten. Daher ist eine der wichtigsten und dennoch häufig übersehenen Eigenschaften von Konsensprotokollen die 125 Zeit bis zur Endgültigkeit. Snow-Protokolle erreichen ihre Endgültigkeit typischerweise in ≤1 Sekunde, was deutlich kürzer ist als Sowohl Protokolle mit der längsten Kette als auch Shard-blockchains, die typischerweise beide die Endgültigkeit einer Angelegenheit umfassen von Minuten.Avalanche Plattform 30.06.2020 5 – Hoher Durchsatz. Snow-Protokolle, die eine lineare Kette oder einen DAG aufbauen können, erreichen Tausende von Transaktionen pro Sekunde (5000+ tps) und behalten gleichzeitig die vollständige Dezentralisierung bei. Neue blockchain-Lösungen, die Anspruch haben 130 hoch TPS tauschen typischerweise Dezentralisierung und Sicherheit aus und entscheiden sich für mehr Zentralisierung und Unsicherheit Konsensmechanismen. Einige Projekte melden Zahlen aus stark kontrollierten Umgebungen und melden daher falsch echte Leistungsergebnisse. Die gemeldeten Zahlen für $AVAX stammen direkt aus einem echten, vollständig implementierten Avalanche-Netzwerk, das auf 2000 Knoten auf AWS läuft und im Low-End-Bereich geografisch über den ganzen Globus verteilt ist Maschinen. Höhere Leistungsergebnisse (10.000+) können durch die Annahme einer höheren Bandbreite erzielt werden 135 Bereitstellung für jeden Knoten und dedizierte Hardware für die Signaturüberprüfung. Abschließend stellen wir fest, dass die Die oben genannten Metriken befinden sich auf der Basisebene. Layer-2-Skalierungslösungen verbessern diese Ergebnisse sofort erheblich. Vergleichende Konsensdiagramme Tabelle 1 beschreibt die Unterschiede zwischen den drei bekannten Familien von Konsensprotokollen über einen Satz von 8 kritischen Achsen. 140 Nakamoto Klassisch Schnee Robust (geeignet für offene Einstellungen) + - + Stark dezentralisiert (ermöglicht viele Validatoren) + - + Geringe Latenz und schnelle Endgültigkeit (schnelle Transaktionsbestätigung) - + + Hoher Durchsatz (ermöglicht viele Clients) - + + Leicht (Geringe Systemanforderungen) - + + Ruhend (nicht aktiv, wenn keine Entscheidungen getroffen werden) - + + Sicherheit parametrierbar (mehr als 51 % gegnerische Präsenz) - - + Hoch skalierbar - - + Tabelle 1. Vergleichsdiagramm zwischen den drei bekannten Familien von Konsensprotokollen. Avalanche, Schneemann und Frosty gehören alle zur Familie 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.

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

Avalanche Platform 2020/06/30 11 Transaction fees, denoted by the set F, are also subject to governance. F is 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

Plattformübersicht

In diesem Abschnitt geben wir einen Überblick über die Architektur der Plattform und diskutieren verschiedene Implementierungen Details. Die Avalanche-Plattform trennt drei Bereiche sauber: Ketten (und darauf aufbauende Assets) und Ausführung Umgebungen und Bereitstellung. 3.1 Architektur 145 Subnetzwerke Ein Subnetzwerk oder Subnetz ist eine dynamische Gruppe von validators, die zusammenarbeiten, um einen Konsens zu erzielen über den Zustand einer Menge von blockchains. Jeder blockchain wird von einem Subnetz validiert, und ein Subnetz kann validieren beliebig viele blockchains. Ein validator kann Mitglied beliebig vieler Subnetze sein. Ein Subnetz entscheidet wer es betreten darf, und kann verlangen, dass die darin enthaltenen validators bestimmte Eigenschaften haben. Der Avalanche Die Plattform unterstützt den Aufbau und Betrieb beliebig vieler Subnetze. Um ein neues Subnetz zu erstellen 150 oder um einem Subnetz beizutreten, muss man eine Gebühr in $AVAX zahlen.

6 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Das Subnetzmodell bietet eine Reihe von Vorteilen: – Wenn einem validator die blockchains in einem bestimmten Subnetz egal sind, wird er diesem Subnetz einfach nicht beitreten. Dies reduziert den Netzwerkverkehr und die für validators erforderlichen Rechenressourcen. Das ist drin Im Gegensatz zu anderen blockchain-Projekten, bei denen jeder validator sogar jede Transaktion validieren muss 155 diejenigen, die ihnen egal sind. – Da Subnetze darüber entscheiden, wer sie betreten darf, kann man private Subnetze erstellen. Das heißt, jeder blockchain in Das Subnetz wird nur durch eine Reihe vertrauenswürdiger validators validiert. – Man kann ein Subnetz erstellen, in dem jeder validator bestimmte Eigenschaften hat. Beispielsweise könnte man eine erstellen Subnetz, in dem sich jeder validator in einer bestimmten Gerichtsbarkeit befindet oder in dem jeder validator an einen bestimmten Gerichtsstand gebunden ist 160 realer Vertrag. Dies kann aus Compliance-Gründen von Vorteil sein. Es gibt ein spezielles Subnetz namens Standardsubnetz. Es wird von allen validators validiert. (Das heißt, in der Reihenfolge Um ein Subnetz zu validieren, muss auch das Standard-Subnetz validiert werden.) Das Standard-Subnetz validiert eine Reihe von vordefinierte blockchains, einschließlich des blockchain, in dem $AVAX lebt und gehandelt wird. Virtuelle Maschinen Jede blockchain ist eine Instanz einer virtuellen Maschine (VM). Eine VM ist eine Blaupause für eine 165 blockchain, ähnlich wie eine Klasse ein Entwurf für ein Objekt in einer objektorientierten Programmiersprache ist. Die Schnittstelle, Status und Verhalten eines blockchain werden durch die VM definiert, die der blockchain ausführt. Folgendes Eigenschaften eines blockchain und andere werden von einer VM definiert: – Der Inhalt eines Blocks – Der Zustandsübergang, der auftritt, wenn ein Block akzeptiert wird 170 – Die von blockchain bereitgestellten APIs und ihre Endpunkte – Die Daten, die auf der Festplatte gespeichert werden Wir sagen, dass ein blockchain eine bestimmte VM „verwendet“ oder „ausführt“. Beim Erstellen eines blockchain gibt man die VM an es läuft, sowie der Genesis-Status von blockchain. Ein neuer blockchain kann unter Verwendung eines bereits vorhandenen erstellt werden VM oder ein Entwickler kann eine neue programmieren. Es kann beliebig viele blockchains geben, die dieselbe VM ausführen. 175 Jeder blockchain, auch diejenigen, die dieselbe VM ausführen, ist logisch unabhängig von anderen und behält seine bei eigener Staat. 3.2 Bootstrapping Der erste Schritt bei der Teilnahme an Avalanche ist das Bootstrapping. Der Prozess erfolgt in drei Phasen: Verbindung um Anker zu säen, Netzwerke und Zustände zu entdecken und ein validator zu werden. 180 Seed-Anker Jedes vernetzte System von Peers, das ohne autorisierte (d. h. fest codierte) Netzwerke arbeitet. Eine Reihe von Identitäten erfordert einen Mechanismus zur Peer-Erkennung. In Peer-to-Peer-Filesharing-Netzwerken gibt es eine Reihe von Es kommen Tracker zum Einsatz. Ein typischer Mechanismus in Kryptonetzwerken ist die Verwendung von DNS-Seed-Knoten (auf die wir verweisen).Avalanche Plattform 30.06.2020 7 als Seed-Anker), die aus einer Reihe wohldefinierter Seed-IP-Adressen bestehen, von denen andere Mitglieder von Das Netzwerk kann entdeckt werden. Die Rolle von DNS-Seed-Knoten besteht darin, nützliche Informationen über die Gruppe bereitzustellen 185 der aktiven Teilnehmer am System. Der gleiche Mechanismus wird in Bitcoin Core [1] verwendet, wobei der Die Datei src/chainparams.cpp des Quellcodes enthält eine Liste hartcodierter Seed-Knoten. Der Unterschied zwischen BTC und Avalanche besteht darin, dass BTC nur einen korrekten DNS-Seed-Knoten erfordert, während Avalanche einen einfachen erfordert Die meisten Anker sind korrekt. Ein neuer Benutzer könnte sich beispielsweise dafür entscheiden, die Netzwerkansicht zu booten über eine Reihe gut etablierter und seriöser Börsen, von denen jeder einzelne nicht vertrauenswürdig ist. 190 Wir weisen jedoch darauf hin, dass der Satz von Bootstrap-Knoten nicht fest codiert oder statisch sein muss und dies auch sein kann Vom Benutzer bereitgestellt, aus Gründen der Benutzerfreundlichkeit können Kunden jedoch eine Standardeinstellung bereitstellen, die wirtschaftlich ist wichtige Akteure, wie z. B. Börsen, mit denen Kunden ihre Weltanschauung teilen möchten. Es gibt kein Hindernis dafür zu einem Seed-Anker werden, daher kann eine Reihe von Seed-Ankern nicht vorschreiben, ob ein Knoten eintreten darf oder nicht Das Netzwerk, da Knoten das neueste Netzwerk von Avalanche-Peers erkennen können, indem sie sich an einen beliebigen Seed-Satz anhängen 195 Anker. Netzwerk- und Zustandserkennung Sobald ein Knoten mit den Seed-Ankern verbunden ist, fragt er nach dem neuesten Satz von Zustandsübergänge. Wir nennen diese Menge von Zustandsübergängen die akzeptierte Grenze. Für eine Kette die akzeptierte Grenze ist der letzte akzeptierte Block. Für eine DAG ist die akzeptierte Grenze die Menge der Scheitelpunkte, die akzeptiert werden, aber dennoch vorhanden sind keine akzeptierten Kinder. Nachdem der Staat die akzeptierten Grenzen von den Seed-Ankern erfasst hat, übergeht er diese 200 von der Mehrheit der Seed-Anker akzeptiert werden, gilt als akzeptiert. Anschließend wird der korrekte Zustand extrahiert durch Synchronisierung mit den abgetasteten Knoten. Solange es eine Mehrheit korrekter Knoten im Seed-Anker gibt gesetzt, dann müssen die akzeptierten Zustandsübergänge von mindestens einem korrekten Knoten als akzeptiert markiert worden sein. Dieser Zustandserkennungsprozess wird auch für die Netzwerkerkennung verwendet. Der Mitgliedersatz des Netzwerks ist in der Kette validator definiert. Daher ermöglicht die Synchronisierung mit der Kette validator dem Knoten die Erkennung 205 der aktuelle Satz von validators. Die validator-Kette wird im nächsten Abschnitt weiter besprochen. 3.3 Sybil-Kontrolle und Mitgliedschaft Konsensprotokolle stellen ihre Sicherheitsgarantien unter der Annahme bereit, dass bis zu einer Schwellenwertzahl Die Anzahl der Mitglieder im System könnte kontrovers sein. Ein Sybil-Angriff, bei dem ein Knoten das Netzwerk kostengünstig überflutet mit böswilligen Identitäten können diese Garantien trivialerweise außer Kraft setzen. Grundsätzlich kann ein solcher Angriff nur sein 210 abgeschreckt, indem man die Präsenz mit dem Beweis einer schwer zu fälschenden Ressource [3] tauscht. Frühere Systeme haben die Verwendung untersucht von Sybil-Abschreckungsmechanismen, die proof-of-work (PoW), proof-of-stake (PoS) und den Nachweis der verstrichenen Zeit umfassen (POET), Proof-of-Space-and-Time (PoST) und Proof-of-Authority (PoA). Im Kern erfüllen alle diese Mechanismen eine identische Funktion: Sie erfordern, dass jeder Teilnehmer dies tut ein gewisser „Skin in the Game“ in Form eines wirtschaftlichen Engagements, das wiederum einen wirtschaftlichen Nutzen mit sich bringt 215 Barriere gegen Fehlverhalten dieses Teilnehmers. Bei allen handelt es sich um eine Form des Einsatzes, sei es in der Form von Mining-Rigs und hash Strom (PoW), Speicherplatz (PoST), vertrauenswürdiger Hardware (POET) oder einer genehmigten Identität (PoA). Dieser Einsatz bildet die Grundlage für die wirtschaftlichen Kosten, die die Teilnehmer tragen müssen, um eine Stimme zu erhalten. Für Beispielsweise ist in Bitcoin die Fähigkeit, gültige Blöcke beizutragen, direkt proportional zur hash-Leistung des vorgeschlagener Teilnehmer. Leider kam es auch bei den Konsensprotokollen zu erheblicher Verwirrung8 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer versus Sybil-Kontrollmechanismen. Wir stellen fest, dass die Wahl der Konsensprotokolle größtenteils orthogonal zur Wahl des Sybil-Kontrollmechanismus. Das soll nicht heißen, dass Sybil-Kontrollmechanismen vorhanden sind Drop-in-Replacements für einander, da eine bestimmte Wahl Auswirkungen auf den Basiswert haben kann Garantien des Konsensprotokolls. Allerdings kann die Familie Snow* mit vielen dieser bekannten Arten gekoppelt werden Mechanismen, ohne nennenswerte Modifikation. 225 Letztendlich aus Sicherheitsgründen und um sicherzustellen, dass die Anreize der Teilnehmer zum Wohle von ausgerichtet sind Im Netzwerk wählt $AVAX PoS zum zentralen Sybil-Kontrollmechanismus. Einige Formen des Einsatzes sind von Natur aus zentralisiert: Die Herstellung von Mining-Rigs (PoW) beispielsweise ist von Natur aus in den Händen einiger weniger zentralisiert Menschen mit dem entsprechenden Know-how und Zugang zu den Dutzenden Patenten, die für wettbewerbsfähige VLSI erforderlich sind Herstellung. Darüber hinaus verliert das PoW-Mining aufgrund der hohen jährlichen Miner-Subventionen an Wert. Ebenso, 230 Der Speicherplatz befindet sich größtenteils im Besitz großer Rechenzentrumsbetreiber. Darüber hinaus verfügen alle Sybil-Kontrollmechanismen die laufende Kosten verursachen, z.B. Stromkosten für hashing, Wertverlust aus dem Ökosystem, ganz zu schweigen davon zerstören die Umwelt. Dies wiederum verringert den Machbarkeitsrahmen für token, was nachteilig ist Preisschwankungen über einen kurzen Zeitraum können dazu führen, dass das System nicht mehr funktionsfähig ist. Proof-of-Work wählt grundsätzlich aus Bergleute, die über die Verbindungen verfügen, um billigen Strom zu beschaffen, was wenig mit der Fähigkeit der Bergleute zu tun hat 235 um Transaktionen oder deren Beiträge zum gesamten Ökosystem zu serialisieren. Unter diesen Optionen wählen wir proof-of-stake, weil es grün, zugänglich und offen für alle ist. Wir weisen jedoch darauf hin, dass dabei das $AVAX verwendet wird PoS, das Netzwerk Avalanche ermöglicht den Start von Subnetzen mit PoW und PoS. Das Abstecken ist ein natürlicher Mechanismus für die Teilnahme an einem offenen Netzwerk, da es eine direkte wirtschaftliche Nutzung ermöglicht Argument: Die Erfolgswahrscheinlichkeit eines Angriffs ist direkt proportional zu wohldefinierten monetären Kosten 240 Funktion. Mit anderen Worten: Die beteiligten Knoten sind wirtschaftlich motiviert, sich nicht auf ein solches Verhalten einzulassen könnten den Wert ihres Einsatzes beeinträchtigen. Darüber hinaus fallen für diesen Einsatz keine weiteren Unterhaltskosten (sonstige) an dann die Opportunitätskosten der Investition in einen anderen Vermögenswert) und verfügt über das Eigentum, das im Gegensatz zu Bergbauausrüstung wird vollständig verbraucht, wenn es bei einem katastrophalen Angriff verwendet wird. Für PoW-Operationen kann Bergbauausrüstung einfach sein wiederverwendet oder – wenn der Eigentümer dies wünscht – vollständig an den Markt zurückverkauft. 245 Ein Knoten, der dem Netzwerk beitreten möchte, kann dies frei tun, indem er zunächst einen immobilisierten Pfahl setzt während der Dauer der Teilnahme am Netzwerk. Der Nutzer bestimmt die Höhe der Einsatzdauer. Sobald ein Einsatz angenommen wurde, kann er nicht mehr rückgängig gemacht werden. Das Hauptziel besteht darin, sicherzustellen, dass die Knoten im Wesentlichen gemeinsam genutzt werden gleiche weitgehend stabile Sicht auf das Netzwerk. Wir gehen davon aus, dass die Mindestzeit staking in der Größenordnung von a liegt Woche. 250 Im Gegensatz zu anderen Systemen, die ebenfalls einen PoS-Mechanismus anbieten, nutzt $AVAX kein Slashing und Daher werden alle Einsätze nach Ablauf des Zeitraums staking zurückgegeben. Dies verhindert unerwünschte Szenarien wie z ein Software- oder Hardwarefehler des Clients, der zum Verlust von Münzen führt. Dies passt zu unserer Designphilosophie des Aufbaus vorhersehbarer Technologie: Die abgesteckten tokens sind nicht gefährdet, selbst wenn Software vorhanden ist oder Hardwarefehler. 255 In Avalanche gibt ein Knoten, der teilnehmen möchte, eine spezielle Stake-Transaktion an die validator-Kette aus. Zu den Stake-Transaktionen gehören der zu setzende Betrag, der staking-Schlüssel des Teilnehmers, der staking ist, die Dauer, und die Zeit, zu der die Validierung beginnt. Sobald die Transaktion akzeptiert wird, wird das Geld bis zum gesperrt Ende des Zeitraums staking. Der minimal zulässige Betrag wird vom System festgelegt und durchgesetzt. Der Einsatz Der von einem Teilnehmer platzierte Betrag hat Auswirkungen auf das Ausmaß des Einflusses, den der Teilnehmer auf das Unternehmen hatAvalanche Plattform 30.06.2020 9 Konsensprozess sowie die Belohnung, wie später besprochen. Die angegebene Dauer staking muss zwischen liegen δmin und δmax, die minimalen und maximalen Zeitrahmen, für die jeder Einsatz gesperrt werden kann. Wie bei der staking Betrag, der Zeitraum staking hat auch Auswirkungen auf die Belohnung im System. Verlust oder Diebstahl des Der Schlüssel staking kann nicht zu einem Vermögensverlust führen, da der Schlüssel staking nur im Konsensprozess und nicht für Vermögenswerte verwendet wird übertragen. 265 3.4 Intelligente Verträge in $AVAX Beim Start unterstützt Avalanche standardmäßige Solidity-basierte smart contracts über die virtuelle Maschine Ethereum (EVM). Wir gehen davon aus, dass die Plattform einen umfangreicheren und leistungsfähigeren Satz von smart contract unterstützen wird. Werkzeuge, darunter: – Intelligente Verträge mit Off-Chain-Ausführung und On-Chain-Verifizierung. 270 – Intelligente Verträge mit paralleler Ausführung. Alle smart contracts, die nicht mit demselben Status in arbeiten Jedes Subnetz in Avalanche kann parallel ausgeführt werden. – Eine verbesserte Solidity, genannt Solidity++. Diese neue Sprache wird Versionierung und sichere Mathematik unterstützen und Festkomma-Arithmetik, ein verbessertes Typsystem, Kompilierung in LLVM und Just-in-Time-Ausführung. Wenn ein Entwickler EVM-Unterstützung benötigt, aber smart contracts in einem privaten Subnetz bereitstellen möchte, muss er 275 kann direkt ein neues Subnetz aufbauen. Auf diese Weise ermöglicht Avalanche funktionsspezifisches Sharding die Subnetze. Wenn ein Entwickler außerdem Interaktionen mit dem aktuell bereitgestellten Ethereum smart Verträge können sie mit dem Athereum-Subnetz interagieren, das ein Löffel von Ethereum ist. Schließlich, wenn ein Entwickler eine andere Ausführungsumgebung als die virtuelle Maschine Ethereum erfordert, können sie sich für die Bereitstellung entscheiden ihre smart contract über ein Subnetz, das eine andere Ausführungsumgebung wie DAML implementiert 280 oder WASM. Subnetze können über das VM-Verhalten hinaus zusätzliche Funktionen unterstützen. Beispielsweise können Subnetze erzwingen Leistungsanforderungen für größere validator-Knoten, die smart contracts über längere Zeiträume halten, oder validators, die den Vertragsstatus privat halten. 4 Governance und der $AVAX-Token 4.1 Der $AVAX Native Token 285 Geldpolitik Das native token, $AVAX, ist begrenztes Angebot, wobei die Obergrenze auf 720.000.000 tokens festgelegt ist. mit 360.000.000 tokens, die beim Mainnet-Start verfügbar sind. Allerdings im Gegensatz zu anderen tokens mit begrenzter Versorgung, die Um die Prägerate kontinuierlich zu erhöhen, besteht die Geldpolitik von \(AVAX is designed to react to changing economic conditions. In particular, the objective of \)AVAX darin, die Anreize der Benutzer auszugleichen, token zu setzen. im Gegensatz zur Verwendung zur Interaktion mit der Vielfalt der auf der Plattform verfügbaren Dienste. Teilnehmer der Plattform 290 fungieren gemeinsam als dezentrale Reservebank. Die auf Avalanche verfügbaren Hebel sind staking Belohnungen, Gebühren, und Luftabwürfe, die alle durch steuerbare Parameter beeinflusst werden. Die Einsatzprämien werden durch die On-Chain-Governance festgelegt und von einer Funktion gesteuert, die darauf ausgelegt ist, das begrenzte Angebot niemals zu überschreiten. Das Abstecken kann induziert werden durch Erhöhung der Gebühren oder Erhöhung der staking Prämien. Andererseits können wir ein stärkeres Engagement herbeiführen mit den Avalanche-Plattformdiensten durch Senkung der Gebühren und Reduzierung der staking-Prämie.10 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Verwendungsmöglichkeiten Zahlungen Echte dezentrale Peer-to-Peer-Zahlungen sind für die Branche aufgrund von weitgehend ein unerfüllter Traum die derzeitige mangelnde Leistung der etablierten Betreiber. $AVAX ist genauso leistungsstark und einfach zu verwenden wie Zahlungen Visa ermöglicht weltweit jede Sekunde Tausende von Transaktionen auf völlig vertrauenswürdige und dezentralisierte Weise. Darüber hinaus bietet $AVAX für Händler weltweit ein direktes Wertversprechen gegenüber Visa, nämlich einen niedrigeren 300 Gebühren. Abstecken: Sichern des Systems Auf der Plattform Avalanche wird die Sybil-Kontrolle über staking erreicht. In Ordnung Zur Validierung muss ein Teilnehmer Münzen oder Einsätze sperren. Validatoren, manchmal auch Staker genannt, sind es wurden für ihre Validierungsdienste unter anderem basierend auf staking Betrag und staking Dauer entschädigt Eigenschaften. Die gewählte Kompensationsfunktion sollte die Varianz minimieren und sicherstellen, dass dies bei großen Spielern nicht der Fall ist 305 erhalten unverhältnismäßig mehr Entschädigung. Die Teilnehmer unterliegen auch keinen „Glücksfaktoren“ wie z PoW-Mining. Ein solches Belohnungssystem verhindert auch die Bildung von Mining- oder staking-Pools, was es wirklich ermöglicht dezentrale, vertrauenslose Teilnahme am Netzwerk. Atomic Swaps Neben der Bereitstellung der Kernsicherheit des Systems dient $AVAX token als universelle Einheit des Austausches. Von da an wird die Avalanche-Plattform in der Lage sein, vertrauenswürdige Atom-Swaps nativ zu unterstützen 310 Die Plattform ermöglicht den nativen, wirklich dezentralen Austausch von Vermögenswerten aller Art direkt auf Avalanche. 4.2 Regierungsführung Governance ist für die Entwicklung und Einführung jeder Plattform von entscheidender Bedeutung, denn – wie bei allen anderen Arten auch von Systemen – Avalanche wird ebenfalls einer natürlichen Weiterentwicklung und Aktualisierungen ausgesetzt sein. $AVAX bietet On-Chain-Governance für kritische Parameter des Netzwerks, wobei die Teilnehmer über Änderungen am Netzwerk abstimmen können und 315 Entscheidungen zur Netzwerkmodernisierung demokratisch regeln. Dazu gehören Faktoren wie der Mindestbetrag staking, Prägerate sowie andere wirtschaftliche Parameter. Dadurch kann die Plattform eine dynamische Parameteroptimierung mithilfe einer Crowd oracle effektiv durchführen. Allerdings im Gegensatz zu einigen anderen Governance-Plattformen Da draußen erlaubt Avalanche keine unbegrenzten Änderungen an beliebigen Aspekten des Systems. Stattdessen nur ein Eine vorab festgelegte Anzahl von Parametern kann über Governance geändert werden, wodurch das System vorhersehbarer wird 320 und Erhöhung der Sicherheit. Darüber hinaus unterliegen alle regelbaren Parameter innerhalb bestimmter Zeitgrenzen Grenzen. Einführung einer Hysterese und Sicherstellung, dass das System über kurze Zeiträume vorhersehbar bleibt. Für dezentrale Systeme ohne Verwalter ist ein praktikabler Prozess zur Ermittlung global akzeptabler Werte für Systemparameter von entscheidender Bedeutung. Avalanche kann seinen Konsensmechanismus nutzen, um ein System aufzubauen, das dies ermöglicht Jeder kann spezielle Transaktionen vorschlagen, bei denen es sich im Wesentlichen um systemweite Umfragen handelt. Jeder teilnehmende Knoten kann 325 solche Vorschläge machen. Der nominale Belohnungssatz ist ein wichtiger Parameter, der sich auf jede Währung auswirkt, egal ob digital oder fiat. Leider können Kryptowährungen, die diesen Parameter beheben, mit verschiedenen Problemen konfrontiert sein, einschließlich Deflation oder Inflation. Zu diesem Zweck unterliegt der nominale Belohnungssatz einer Steuerung innerhalb vorab festgelegter Grenzen. Das wird Erlauben Sie token-Inhabern, zu entscheiden, ob $AVAX letztendlich begrenzt, unbegrenzt oder sogar deflationär sein soll.Avalanche Plattform 30.06.2020 11 Transaktionsgebühren, die mit der Menge F bezeichnet werden, unterliegen ebenfalls der Governance. F ist praktisch ein Tupel, das die mit den verschiedenen Anweisungen und Transaktionen verbundenen Gebühren beschreibt. Schließlich staking Zeiten und Beträge sind ebenfalls regierbar. Die Liste dieser Parameter ist in Abbildung 1 definiert. – ∆: Einsatzbetrag, denominiert in $AVAX. Dieser Wert definiert den Mindesteinsatz, der platziert werden muss Bevor Sie am System teilnehmen, müssen Sie eine Bindung eingehen. – δmin: Die minimale Zeit, die ein Knoten benötigt, um sich in das System einzubinden. – δmax: Die maximale Zeit, die ein Knoten einsetzen kann. – ρ : (π∆, τδmin) →R : Belohnungsratenfunktion, auch Minting-Rate genannt, bestimmt die Belohnung a Der Teilnehmer kann einen Anspruch in Abhängigkeit von seinem staking-Betrag bei gegebener Anzahl von π öffentlich bekannt gegebenen Knoten erheben in seinem Besitz, über einen Zeitraum von τ aufeinanderfolgenden δmin Zeitrahmen, so dass τδmin ≤δmax. – F: die Gebührenstruktur, bei der es sich um eine Reihe regelbarer Gebührenparameter handelt, die die Kosten für verschiedene Transaktionen angeben. Abb. 1. Wichtige Nicht-Konsens-Parameter, die in Avalanche verwendet werden. Bei der ersten Verwendung wird die gesamte Notation neu definiert. Im Einklang mit dem Prinzip der Vorhersehbarkeit in einem Finanzsystem weist die Governance in $AVAX eine Hysterese auf. Dies bedeutet, dass Änderungen an Parametern stark von den letzten Änderungen abhängen. Es gibt zwei Grenzen 335 jedem regelbaren Parameter zugeordnet: Zeit und Bereich. Sobald ein Parameter mithilfe einer Governance geändert wird Bei einer Transaktion wird es sehr schwierig, sie sofort und in großem Umfang wieder zu ändern. Diese Schwierigkeiten und Wertbeschränkungen lockern sich, je mehr Zeit seit der letzten Änderung vergeht. Insgesamt hält dies das System davon ab sich innerhalb kurzer Zeit drastisch ändern, sodass Benutzer die Systemparameter im sicher vorhersagen können kurzfristig und bietet gleichzeitig eine starke Kontrolle und Flexibilität auf lange Sicht. 340

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

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.

Regierungsführung

1.1 Avalanche Ziele und Prinzipien Avalanche ist eine leistungsstarke, skalierbare, anpassbare und sichere blockchain-Plattform. Es zielt auf drei ab breite Anwendungsfälle: 15 – Erstellen anwendungsspezifischer blockchains, die berechtigte (private) und erlaubnislose (öffentliche) umfassen Bereitstellungen. – Erstellen und Starten hochskalierbarer und dezentraler Anwendungen (Dapps). – Aufbau beliebig komplexer digitaler Assets mit benutzerdefinierten Regeln, Vereinbarungen und Fahrern (intelligente Assets). 1 Zukunftsgerichtete Aussagen beziehen sich im Allgemeinen auf zukünftige Ereignisse oder unsere zukünftige Leistung. Dies schließt ein, ist es aber nicht beschränkt auf die geplante Leistung von Avalanche; die erwartete Entwicklung seines Geschäfts und seiner Projekte; Ausführung seiner Vision und Wachstumsstrategie; und Abschluss von Projekten, die derzeit laufen, sich in der Entwicklung befinden oder ansonsten in Erwägung gezogen. Zukunftsgerichtete Aussagen spiegeln die Überzeugungen und Annahmen unseres Managements wider erst ab dem Datum dieser Präsentation. Diese Aussagen stellen keine Garantien für zukünftige Leistungen dar und sind unzulässig Man sollte sich nicht auf sie verlassen. Solche zukunftsgerichteten Aussagen betreffen zwangsläufig Bekanntes und Unbekanntes Risiken, die dazu führen können, dass die tatsächlichen Leistungen und Ergebnisse in zukünftigen Zeiträumen erheblich von den Prognosen abweichen hierin ausgedrückt oder impliziert. Avalanche übernimmt keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren. Obwohl Bei zukunftsgerichteten Aussagen handelt es sich um unsere bestmöglichen Vorhersagen zum Zeitpunkt ihrer Äußerung. Wir können nicht garantieren, dass dies der Fall ist werden sich als korrekt erweisen, da tatsächliche Ergebnisse und zukünftige Ereignisse erheblich abweichen können. Der Leser wird davor gewarnt sich unangemessen auf zukunftsgerichtete Aussagen zu verlassen.2 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Das übergeordnete Ziel von Avalanche ist die Bereitstellung einer einheitlichen Plattform für die Erstellung, Übertragung und den Handel von 20 digitale Vermögenswerte. Konstruktionsbedingt besitzt Avalanche die folgenden Eigenschaften: Skalierbar Avalanche ist auf enorme Skalierbarkeit, Robustheit und Effizienz ausgelegt. Die zentrale Konsensmaschine ist in der Lage, ein globales Netzwerk von potenziell Hunderten Millionen mit dem Internet verbundenen Geräten mit geringer und hoher Leistung zu unterstützen, die nahtlos, mit geringen Latenzen und sehr hohen Transaktionen pro Sekunde funktionieren. 25 Secure Avalanche ist auf Robustheit und hohe Sicherheit ausgelegt. Klassische Konsensprotokolle sind Entwickelt, um bis zu f-Angreifern standzuhalten und vollständig zu versagen, wenn sie einem Angreifer der Größe f + 1 gegenüberstehen oder größer, und der Nakamoto-Konsens bietet keine Sicherheit, wenn 51 % der Bergleute Byzantiner sind. Im Gegensatz dazu Avalanche bietet eine sehr starke Sicherheitsgarantie, wenn der Angreifer einen bestimmten Schwellenwert unterschreitet kann vom Systemdesigner parametrisiert werden und sorgt für eine sanfte Verschlechterung, wenn der Angreifer die Grenze überschreitet 30 dieser Schwelle. Es kann Sicherheitsgarantien (jedoch keine Lebendigkeitsgarantien) aufrechterhalten, selbst wenn der Angreifer 51 % überschreitet. Es ist das erste erlaubnislose System, das derart starke Sicherheitsgarantien bietet. Dezentralisiert Avalanche soll eine beispiellose Dezentralisierung ermöglichen. Dies impliziert eine Verpflichtung auf mehrere Client-Implementierungen und keine zentralisierte Kontrolle jeglicher Art. Das Ökosystem ist darauf ausgelegt, zu vermeiden Trennungen zwischen Benutzerklassen mit unterschiedlichen Interessen. Entscheidend ist, dass es keinen Unterschied zwischen Bergleuten gibt, 35 Entwickler und Benutzer. Regierbares und demokratisches $AVAX ist eine äußerst integrative Plattform, die es jedem ermöglicht, sich mit ihr zu verbinden Vernetzen Sie sich und beteiligen Sie sich an der Validierung und aus erster Hand an der Governance. Jeder token-Inhaber kann abstimmen Auswahl wichtiger Finanzparameter und Entscheidung darüber, wie sich das System entwickelt. Interoperabel und flexibel Avalanche ist als universelle und flexible Infrastruktur für eine Vielzahl konzipiert 40 von blockchains/assets, wobei die Basis $AVAX zur Sicherheit und als Rechnungseinheit für den Umtausch verwendet wird. Die Das System soll wertneutral viele darauf aufbauende blockchains unterstützen. Die Plattform ist von Grund auf so konzipiert, dass es einfach ist, vorhandene blockchains darauf zu portieren, Salden zu importieren Unterstützung mehrerer Skriptsprachen und virtueller Maschinen sowie sinnvolle Unterstützung mehrerer Bereitstellungen Szenarien. 45 Gliederung Der Rest dieses Dokuments ist in vier Hauptabschnitte unterteilt. Abschnitt 2 beschreibt die Einzelheiten dazu Motor, der die Plattform antreibt. In Abschnitt 3 wird das Architekturmodell hinter der Plattform erörtert, einschließlich Subnetzwerke, virtuelle Maschinen, Bootstrapping, Mitgliedschaft und staking. Abschnitt 4 erläutert die Governance Modell, das dynamische Änderungen wichtiger wirtschaftlicher Parameter ermöglicht. Schließlich werden in Abschnitt 5 verschiedene untersucht Randthemen von Interesse, einschließlich potenzieller Optimierungen, Post-Quanten-Kryptographie und realistischer 50 Gegner.

Avalanche Plattform 30.06.2020 3 Namenskonvention Der Name der Plattform lautet Avalanche und wird üblicherweise als „der Avalanche“ bezeichnet. Plattform“ und ist austauschbar/synonym mit „dem Netzwerk Avalanche“ oder – einfach – Avalanche. Codebasen werden unter Verwendung von drei numerischen Kennungen mit der Bezeichnung „v.[0-9].[0-9].[0-100]“ veröffentlicht, wobei die Die erste Nummer identifiziert Hauptversionen, die zweite Nummer identifiziert Nebenversionen und die dritte Nummer 55 identifiziert Patches. Die erste öffentliche Veröffentlichung mit dem Codenamen Avalanche Borealis ist Version 1.0.0. Der Einheimische token der Plattform heißt „$AVAX“. Die von der Avalanche-Plattform verwendete Familie von Konsensprotokollen ist wird als Snow*-Familie bezeichnet. Es gibt drei konkrete Instanziierungen mit den Namen Avalanche, Snowman und Frostig.

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

Diskussion

5.1 Optimierungen Beschneidung vieler blockchain-Plattformen, insbesondere derjenigen, die den Nakamoto-Konsens implementieren, wie Bitcoin, leiden unter ständigem Staatswachstum. Dies liegt daran, dass sie laut Protokoll den gesamten Verlauf von speichern müssen Transaktionen. Damit ein blockchain jedoch nachhaltig wachsen kann, muss er in der Lage sein, alte Geschichte zu beschneiden. 345 Dies ist besonders wichtig für blockchains, die eine hohe Leistung unterstützen, wie z. B. Avalanche. Bei der Snow*-Familie ist das Beschneiden einfach. Anders als in Bitcoin (und ähnlichen Protokollen), wo das Beschneiden nicht erfolgt Gemäß den algorithmischen Anforderungen ist es möglich, dass in $AVAX-Knoten Teile der DAG nicht verwaltet werden müssen sind tiefgründig und sehr engagiert. Diese Knoten müssen keine Vorgeschichte für neues Bootstrapping nachweisen Knoten und müssen daher lediglich den aktiven Zustand, d. h. die aktuellen Salden, sowie den nicht festgeschriebenen Zustand speichern 350 Transaktionen. Clienttypen Avalanche kann drei verschiedene Clienttypen unterstützen: Archival, Full und Light. Archiv Knoten speichern den gesamten Verlauf des $AVAX-Subnetzes, des staking-Subnetzes und des smart contract-Subnetzes12 Kevin Sekniqi, Daniel Laine, Stephen Buttolph und Emin Gün Sirer Weg zur Entstehung, was bedeutet, dass diese Knoten als Bootstrapping-Knoten für neue eingehende Knoten dienen. Zusätzlich Diese Knoten können den vollständigen Verlauf anderer Subnetze speichern, für die sie sich als validators entscheiden. Archiv 355 Knoten sind typischerweise Maschinen mit hoher Speicherkapazität, die beim Herunterladen von anderen Knoten bezahlt werden Alter Zustand. Vollständige Knoten hingegen nehmen an der Validierung teil, speichern jedoch nicht den gesamten Verlauf Speichern Sie einfach den aktiven Status (z. B. den aktuellen UTXO-Satz). Schließlich für diejenigen, die einfach sicher interagieren müssen Da das Netzwerk die geringste Menge an Ressourcen beansprucht, unterstützt Avalanche Light-Clients, die dies können Beweisen Sie, dass eine Transaktion festgeschrieben wurde, ohne dass der Verlauf heruntergeladen oder synchronisiert werden muss. Licht 360 Kunden beteiligen sich an der wiederholten Sampling-Phase des Protokolls, um ein sicheres Engagement und ein netzwerkweites Netzwerk zu gewährleisten Konsens. Daher bieten Light-Clients in Avalanche die gleichen Sicherheitsgarantien wie vollständige Knoten. Sharding Sharding ist der Prozess der Partitionierung verschiedener Systemressourcen, um die Leistung zu steigern und Belastung reduzieren. Es gibt verschiedene Arten von Sharding-Mechanismen. Beim Netzwerk-Sharding die Gruppe der Teilnehmer ist in separate Teilnetzwerke unterteilt, um die algorithmische Belastung zu reduzieren; Beim State Sharding sind sich die Teilnehmer einig 365 Speicherung und Pflege nur bestimmter Teilbereiche des gesamten globalen Zustands; schließlich beim Transaktions-Sharding, Die Teilnehmer verpflichten sich, die Verarbeitung eingehender Transaktionen getrennt durchzuführen. In Avalanche Borealis existiert die erste Form des Shardings durch die Subnetzwerk-Funktionalität. Für Beispielsweise könnte man ein Gold-Subnetz und ein weiteres Immobilien-Subnetz starten. Diese beiden Subnetze können vollständig vorhanden sein parallel. Die Subnetze interagieren nur, wenn ein Benutzer mit seinen Goldbeständen Immobilienverträge kaufen möchte. 370 Zu diesem Zeitpunkt ermöglicht Avalanche einen atomaren Austausch zwischen den beiden Subnetzen. 5.2 Bedenken Post-Quanten-Kryptographie Die Post-Quanten-Kryptographie hat in letzter Zeit große Aufmerksamkeit erlangt aufgrund der Fortschritte in der Entwicklung von Quantencomputern und Algorithmen. Die Sorge um Quanten Der Nachteil von Computern besteht darin, dass sie einige der derzeit eingesetzten kryptografischen Protokolle, insbesondere digitale, brechen können 375 Unterschriften. Das Netzwerkmodell Avalanche ermöglicht eine beliebige Anzahl von VMs und unterstützt somit eine Quantenresistenz virtuelle Maschine mit einem geeigneten digitalen Signaturmechanismus. Wir erwarten verschiedene Arten digitaler Signaturen einzusetzende Systeme, einschließlich quantenresistenter RLWE-basierter Signaturen. Der Konsensmechanismus setzt für seinen Kernbetrieb keinerlei schwere Krypto voraus. Aufgrund dieses Designs ist es einfach Erweitern Sie das System um eine neue virtuelle Maschine, die quantensichere kryptografische Grundelemente bereitstellt. 380 Realistische Gegner Das Avalanche Papier [6] bietet sehr starke Garantien in Gegenwart eines mächtiger und feindlicher Gegner, im vollständigen Punkt-zu-Punkt-Modell als rundenadaptiver Gegner bekannt. In Mit anderen Worten, der Gegner hat zu jeder Zeit vollen Zugriff auf den Zustand jedes einzelnen korrekten Knotens, weiß das Zufallsauswahl aller korrekten Knoten, außerdem kann der eigene Status jederzeit vor und nach dem aktualisiert werden Der richtige Knoten hat die Möglichkeit, seinen eigenen Status zu aktualisieren. Tatsächlich ist dieser Gegner allmächtig, außer 385 die Möglichkeit, den Status eines korrekten Knotens direkt zu aktualisieren oder die Kommunikation zwischen korrekten Knoten zu ändern Knoten. Dennoch ist ein solcher Gegner in Wirklichkeit rein theoretisch, da die praktische Umsetzung des Der stärkste mögliche Gegner ist auf statistische Näherungen des Netzwerkzustands beschränkt. Daher in In der Praxis gehen wir davon aus, dass Angriffe im schlimmsten Fall nur schwer durchzuführen sind.Avalanche Plattform 30.06.2020 13 Inklusion und Gleichheit Ein häufiges Problem bei erlaubnislosen Währungen ist das „Reichwerden“. 390 reicher“. Dies ist eine berechtigte Sorge, da ein unsachgemäß implementiertes PoS-System dies tatsächlich ermöglichen kann Die Schaffung von Wohlstand wird überproportional den bereits großen Anteilseignern des Systems zugeschrieben. A Ein einfaches Beispiel sind leiterbasierte Konsensprotokolle, bei denen ein Unterausschuss oder ein benannter Leiter eingesetzt wird sammelt während seines Betriebs alle Belohnungen ein und die Wahrscheinlichkeit, für das Sammeln von Belohnungen ausgewählt zu werden, ist hoch proportional zum Einsatz, was zu starken Belohnungseffekten führt. Darüber hinaus gilt in Systemen wie Bitcoin 395 Es gibt ein „Groß wird größer“-Phänomen, bei dem die großen Bergleute einen Vorteil gegenüber den kleineren genießen von weniger Waisenkindern und weniger Arbeitsausfällen. Im Gegensatz dazu verwendet Avalanche eine egalitäre Verteilung der Prägung: Jeder einzelne Teilnehmer am staking-Protokoll wird gerecht und proportional auf der Grundlage seines Einsatzes entlohnt. Indem Avalanche einer sehr großen Anzahl von Menschen die direkte Teilnahme an staking ermöglicht, kann dies berücksichtigt werden Millionen von Menschen sollen gleichermaßen an staking teilnehmen. Der Mindestbetrag, der für die Teilnahme erforderlich ist 400 Das Protokoll unterliegt der Governance, wird jedoch auf einen niedrigen Wert initialisiert, um eine breite Beteiligung zu fördern. Dies bedeutet auch, dass die Delegation nicht verpflichtet ist, sich mit einem geringen Kontingent zu beteiligen. 6 Fazit In diesem Artikel haben wir die Architektur der Avalanche-Plattform besprochen. Im Vergleich zu anderen Plattformen heute die entweder Konsensprotokolle im klassischen Stil ausführen und daher von Natur aus nicht skalierbar sind oder diese nutzen 405 Konsens im Nakamoto-Stil, der ineffizient ist und hohe Betriebskosten verursacht; der Avalanche ist leichtgewichtig, schnell, skalierbar, sicher und effizient. Der native token, der zur Sicherung des Netzwerks und zur Bezahlung dient verschiedenen Infrastrukturkosten ist einfach und abwärtskompatibel. $AVAX verfügt über Kapazitäten, die andere Vorschläge übertreffen um ein höheres Maß an Dezentralisierung zu erreichen, Angriffen zu widerstehen und auf Millionen von Knoten ohne Quorum zu skalieren oder Gremienwahl, und somit ohne Beteiligungsbeschränkungen. 410 Neben der Konsens-Engine erweitert Avalanche den Stack und führt einfache, aber wichtige Elemente ein Ideen für Transaktionsmanagement, Governance und eine Reihe anderer Komponenten, die auf anderen Plattformen nicht verfügbar sind. Jeder Teilnehmer des Protokolls hat jederzeit Einfluss darauf, wie sich das Protokoll weiterentwickelt. Möglich gemacht durch einen leistungsstarken Governance-Mechanismus. Avalanche unterstützt eine hohe Anpassbarkeit und ermöglicht Fast sofortiges Plug-and-Play mit vorhandenen blockchains. 415