AVA Platform Whitepaper – Serkan
Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
Abstract. This paper provides an architectural overview of the rst release of the AVA platform,
codenamed AVA Borealis5 . For details on the economics of the native token, labelled $AVA, we guide
the reader to the accompanying token dynamics paper [3].
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: 1c3cbae03be49ae218a35e0a79ecb74aaf801c05
10 1 Introduction
This paper provides an architectural overview of the AVA platform. The key focus is on the three key di erentiators
of the platform: the engine, the architectural model, and the governance mechanism.
1.1 AVA Goals and Principles
AVA is a high-performance, scalable, customizable, and secure blockchain platform. It targets three broad use
15 cases:
{ Building application-speci c blockchains, spanning permissioned (private) and permissionless (public)
deployments.
{ Building and launching highly scalable and decentralized applications (Dapps).
{ Building arbitrarily complex digital assets with custom rules, covenants, and riders (smart assets).
1 Forward-looking statements generally relate to future events or our future performance. This includes, but is not
limited to, AVA’s projected performance; the expected development of its business and projects; execution of its
vision and growth strategy; and completion of projects that are currently underway, in development or otherwise
under consideration. Forward-looking statements represent our management’s beliefs and assumptions only as of
the date of this presentation. These statements are not guarantees of future performance and undue reliance should
not be placed on them. Such forward-looking statements necessarily involve known and unknown risks, which may
cause actual performance and results in future periods to di er materially from any projections expressed or implied
herein. Ava undertakes no obligation to update forward-looking statements. Although forward-looking statements
are our best prediction at the time they are made, there can be no assurance that they will prove to be accurate,
as actual results and future events could di er materially. The reader is cautioned not to place undue reliance on
forward-looking statements.
2 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
The overarching 20 aim of AVA is to provide a unifying platform for the creation, transfer, and trade of digital
assets.
By construction, AVA possesses the following properties:
Scalable AVA is designed to be massively scalable, robust, and ecient. The core consensus engine is able
to support a global network of potentially hundreds of millions of internet-connected, low and high-powered
25 devices that operate seamlessly, with low latencies and vey high transactions per second.
Secure AVA 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, AVA provides
a very strong guarantee of safety when the attacker is below a certain threshold, which can be parametrized
30 by the system designer, and it provides graceful degradation when the attacker exceeds this threshold. It can
uphold safety (but not liveness) guarantees even when the attacker exceeds 51%. It is the rst permissionless
system to provide such strong security guarantees.
Decentralized AVA 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
35 divisions between classes of users with di erent interests. Crucially, there is no distinction between miners,
developers, and users.
Governable and Democratic $AVA is a highly inclusive platform, which enables anyone to connect to its
network and participate in validation and rst-hand in governance. Any token holder can have a vote in
selecting key nancial parameters and in choosing how the system evolves.
40 Interoperable and Flexible AVA is designed to be a universal and
exible infrastructure for a multitude of
blockchains/assets, where the base $AVA 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
45 scenarios.
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
50 peripheral topics of interest, including potential optimizations, post-quantum cryptography, and realistic
adversaries.
AVA Platform 2020/02/12 3
Naming Convention The name of the platform is AVA, and is typically referred to as the AVA platform”,
and is interchangeable/synonymous with the AVA network”, or { simply { AVA. Codebases will be released
using three numeric identi ers, labelled v.[0–9].[0–9].[0–100]”, where the rst number identi es major
releases, the second number 55 identi es minor releases, and the third number identi es patches. The rst
public release, codenamed AVA Borealis, is v. 1.0.0. The native token of the platform is called $AVA”.
The family of consensus protocols used by the AVA platform is referred to as the Snow* family. There are
three concrete instantiations, called Avalanche, Snowman, and Frosty.
2 The Engine
60 Discussion of the AVA platform begins with the core component which powers the platform: the consensus
engine.
Background Distributed payments and { more generally { computation, require agreement between a set
of machines. Therefore, consensus protocols, which enable a group of nodes to achieve agreement, lie at the
heart of blockchains, as well as almost every deployed large-scale industrial distributed system. The topic
65 has received extensive scrutiny for almost ve decades, and that e ort, to date, has yielded just two families
of protocols: classical consensus protocols, which rely on all-to-all communication, and Nakamoto consensus,
which relies on proof-of-work mining coupled with the longest-chain-rule. While classical consensus protocols
can have low latency and high throughput, they do not scale to large numbers of participants, nor are they
robust in the presence of membership changes, which has relegated them mostly to permissioned, mostly
70 static deployments. Nakamoto consensus protocols [5, 7, 4], on the other hand, are robust, but su er from
high con rmation latencies, low throughput, and require constant energy expenditure for their security.
The Snow* family of protocols, introduced by Avalanche, combine the best properties of classical consensus
protocols with the best of Nakamoto consensus. Based on a lightweight network sampling mechanism,
they achieve low latency and high throughput without needing to agree on the precise membership of the
75 system. They scale well from thousands to millions of participants with direct participation in the consensus
protocol. Further, the protocols do not make use of PoW mining, and therefore avoid its exorbitant
energy expenditure and subsequent leak of value in the ecosystem, yielding lightweight, green, and quiescent
protocols.
Mechanism and Properties The Snow* protocols operate by repeated sampling of the network. Each node
80 polls a small, constant-sized, randomly chosen set of neighbors, and switches its proposal if a supermajority
supports a di erent value. Samples are repeated until convergence is reached, which happens rapidly in
normal operations.
We elucidate the mechanism of operation via a concrete example. First, a transaction is created by
a user and sent to a validating node, which is a node participating in the consensus procedure. It is then
85 propagated out to other nodes in the network via gossiping.What happens if that user also issues a con
icting
transactions, that is, a doublespend? To choose amongst the con
icting transactions and prevent the doublespend,
every node randomly selects a small subset of nodes and queries which of the con
icting transactions
4 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
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
repeats this procedure until 90 the entire network comes to consensus on one of the con
icting transactions.
Surprisingly, while the core mechanism of operation is quite simple, these protocols lead to highly
desirable system dynamics that make them suitable for large-scale deployment.
{ Permissionless, Open to Churn, and Robust. The latest slew of blockchain projects which employ classical
consensus protocols and therefore require full membership knowledge. Knowing the entire set of
95 participants is suciently 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
well-quanti ed discrepancies between the network views of any two nodes. Validators of Snow* protocols
enjoy the ability to validate without continuous full membership knowledge. They are, therefore, robust
100 and highly suitable for public blockchains.
{ Scalable and Decentralized A core feature of the Snow family is its ability to scale without incurring
fundamental tradeo s. Snow protocols can scale to tens of thousands or millions of nodes, without delegation
to subsets of validators. These protocols enjoy the best-in-class system decentralization, allowing
every node to fully validate. First-hand continuous participation has deep implications for the security
105 of the system. In almost every proof-of-stake protocol that attempts to scale to a large participant set,
the typical mode of operation is to enable scaling by delegating validation to a subcommittee. Naturally,
this implies that the security of the system is now precisely as high as the corruption cost of the
subcommittee. Subcommittees are furthermore subject to cartel formation.
In Snow-type protocols, such delegation is not necessary, allowing every node operator to have a rst110
hand say in the system, at all times. Another design, typically referred to as state sharding, attempts
to provide scalability by parallelizing transaction serialization to independent networks of validators.
Unfortunately, the security of the system in such a design becomes only as high as the easiest corruptible
independent shard. Therefore, neither subcommittee election nor sharding are suitable scaling strategies
for crypto platforms.
115 { Adaptive. Unlike other voting-based systems, Snow* protocols achieve higher performance when the
adversary is small, and yet highly resilient under large attacks.
{ Asynchronously Safe. Snow* protocols, unlike longest-chain protocols, do not require synchronicity to
operate safely, and therefore prevent double-spends even in the face of network partitions. In Bitcoin, for
example, it if synchronicity assumption is violated, it is possible to operate to independent forks of the
120 Bitcoin network for prolonged periods of time, which would invalidate any transactions once the forks
heal.
{ Low Latency. Most blockchains today are unable to support business applications, such as trading or daily
retail payments. It is simply unworkable to wait minutes, or even hours, for con rmation of transactions.
Therefore, one of the most important, and yet highly overlooked, properties of consensus protocols is the
125 time to nality. Snow* protocols reach nality typically in 1 second, which is signi cantly lower than
both longest-chain protocols and sharded blockchains, both of which typically span nality to a matter
of minutes.
{ 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
AVA Platform 2020/02/12 5
high 130 TPS typically trade o decentralization and security and opt for more centralized and insecure consensus
mechanisms. Some projects report numbers from highly controlled settings, thus misreporting true
performance results. The reported numbers for $AVA are taken directly from a real, fully implemented
AVA 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 provisioning
135 for each node and dedicated hardware for signature veri cation. Finally, we note that the aforementioned
metrics are at the base-layer. Layer-2 scaling solutions immediately augment these results considerably.
Comparative Charts of Consensus Table 1 describes the di erences between the three known families
of consensus protocols through a set of 8 critical axes.
Nakamoto Classical Snow*
Robust (Suitable for Open Settings) + — +
Highly Decentralized (Allows Many Validators) + — +
Low Latency and Quick Finality (Fast Transaction Con rmation) — + +
High Throughput (Allows Many Clients) — + +
Lightweight (Low System Requirements) — + +
Quiescent (Not Active When No Decisions Performed) — + +
Safety Parameterizable (Beyond 51% Adversarial Presence) — — +
Highly Scalable — — +
Table 1. Comparative chart between the three known families of consensus protocols. Avalanche, Snowman, and
Frosty all belong to the Snow* family.
3 Platform Overview
140 In this section, we provide an architectural overview of the platform and discuss various implementation
details. The AVA platform cleanly separates three concerns: chains (and assets built on top), execution
environments, and deployment.
3.1 Architecture
Subnetworks The modern internet architecture is described as having a narrow waist” architecture, where
145 there is a single communication protocol stack in the middle, composed of HTTP/TLS/IP/TCP protocols,
and a very large array of networks at the bottom and applications at the top. Such a design was not planned,
but rather became nascent as the internet evolved and re ned in function. Such architectural model is in
stark contrast to how blockchain platforms have been developed to date. Nearly all blockchain platforms
follow a monolithic architecture, typically inspired simply by Bitcoin’s model. Naturally, this presents a large
150 set of limitations that prevent blockchain platforms from many use cases.
AVA is designed under the same architectural model as the internet, and thus it is designed to be
extensible, modular, and composable. The AVA platform has multiple, logically separate subnetworks, each
6 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
supporting their own execution environments, rulesets, and validators. When creating a new subnetwork,
one can specify a multitude of parameters, including { but not limited to { the following:
155 { Who may propose and validate blocks?
{ What constitutes a valid block?
{ The genesis state of the chain.
{ What state transition occurs when a block is accepted?
{ What RPC endpoints are exposed?
160 { What to save to the database, and when?
The subnet architecture, therefore, allows anyone to deploy their own blockchain that ts their custom
requirements. Everything is ultimately a subnetwork in AVA, including the subnetwork where the native
token, $AVA, resides. The subnetwork where $AVA resides, labeled by ID-0, is special due to the following
properties:
165 1. Every validator in the AVA network is also a validator of the $AVA token subnetwork.
2. Any cross-subnetwork transactions, such as asset transfers, are managed by the $AVA token subnetwork.
3. Creation of a new subnetwork pays fees in $AVA, which is required in order to modify the staking
subnetwork.
We note that subnets are not isolated networks. They are fully interoperable with the rest of the network,
170 meaning that they can atomically transact with other subnets.
Virtual Machines In order to launch a new subnet, a developer will rst write the code for the corresponding
virtual machine, or VM. VMs provide the blueprint for deploying subnets in AVA. When ready to
create a subnet, the developer speci es the VM to use, as well as the genesis state of that VM. The behavior
of a chain/DAG on a given subnet is de ned entirely by the VM that the subnet uses. Naturally, since a
175 subnet is just an instance of a VM, there can be arbitrarily many subnets that use the same VM. However,
although many subnets may use the same VM, they maintain their own state, which is independent from
that of other subnets. For simplicity, we sometimes write that a subnet uses” a VM or that a subnet runs”
a VM. In both cases we mean that the subnet is an instance of that VM.
AVA supports the development of a rich marketplace of virtual machines that can enjoy strict compli180
ance rulesets, privacy, and innovative new features. Such a
exible repository of FSSs allows both hobbyist
developers as well as large enterprises to deploy fully compliant and interoperable business and system logic.
The AVA token provides the core infrastructure for enabling the security of the system while simultaneously
providing the universal unit of exchange (i.e. interoperation) between any assets deployed on AVA.
3.2 Bootstrapping
185 The rst step in participating in AVA is bootstrapping. The process occurs in three stages: connection to seed
anchors, network and state discovery, and becoming a validator.
AVA Platform 2020/02/12 7
Seed Anchors Any networked system of peers that operates without a permissioned (i.e. hard-coded)
set of identities requires some mechanism for peer discovery. In peer-to-peer le sharing networks, a set of
trackers are used. In crypto networks, a typical mechanism is the use of DNS seed nodes (which we refer
to as seed 190 anchors), which comprise a set of well-de ned seed-IP addresses from which other members of
the network can be discovered. The role of DNS seed nodes is to provide useful information about the set
of active participants in the system. The same mechanism is employed in Bitcoin Core [1], wherein the
src/chainparams.cpp le of the source code holds a list of hard-coded seed nodes. The di erence between
BTC and AVA is that BTC requires just one correct DNS seed node, while AVA requires a simple majority
195 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. 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
200 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 AVA peers by attaching to any set of seed 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
205 no accepted children. After collecting the accepted frontiers from the seed anchors, the state transitions that
are accepted by a majority of the seed anchors is de ned to be accepted. The correct state is then extracted
by synchronizing with the sampled nodes. As long as there is a majority of correct nodes in the seed anchor
set, then the accepted state transitions must have been marked as accepted by at least one correct node.
This state discovery process is also used for network discovery. The membership set of the network is
210 de ned on the validator chain. Therefore, synchronizing with the validator chain allows the node to discover
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 foods the network
215 with malicious identities, can trivially invalidate these guarantees. Fundamentally, such an attack can only be
deterred by trading o presence with proof of a hard-to-forge resource [2]. 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
220 some skin in the game” in the form of some economic commitment, which in turn provides an economic
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
8 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
instance, in Bitcoin, the ability to contribute valid blocks is directly proportional to the hash-power of the
proposing 225 participant. Unfortunately, there has also been substantial confusion between consensus protocols
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
230 mechanisms, without signi cant modi cation.
Ultimately, for security and to ensure that the incentives of participants are aligned for the bene t
of the network, $AVA 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
235 manufacturing. Furthermore, PoW mining leaks value due to the large yearly miner subsidies. Similarly, 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
240 have the connections to procure cheap electricity, which has little to do with the miners’ ability 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 $AVA uses PoS, the AVA
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
245 argument: the probability of success of an attack is directly proportional to a well-de ned monetary cost
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
250 reused or { if the owner decides to { entirely sold back to the market.
A node wishing to enter the network can freely do so by rst putting up a stake that is immobilized
during the duration of participation in the network. The user determines the amount duration of the stake.
Once accepted, a stake cannot be reverted. The main goal is to ensure that nodes substantially share the
same mostly stable view of the network. We anticipate setting the minimum staking time on the order of a
255 week.
Unlike other systems that also propose a PoS mechanism, $AVA 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
260 hardware
aws.
In AVA, 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
AVA Platform 2020/02/12 9
end of the staking period. The minimal allowed amount is decided and enforced by the system. The stake
amount placed by 265 a participant has implications for both the amount of in
uence the participant has in the
consensus process, as well as the reward, as discussed later. The speci ed staking duration, must be between
min and max, the minimum and maximum timeframes for which any stake can be locked. As with the
staking amount, the staking period also has implications for the reward in the system. Loss or theft of the
staking key cannot lead to asset loss, as the staking key is used only in the consensus process, not for asset
270 transfer.
3.4 Smart Contracts in $AVA
At launch AVA 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:
275 { Smart contracts with o -chain execution and on-chain veri cation.
{ Smart contracts with parallel execution. Any smart contracts that do not operate on the same state in
any subnet in AVA will be able to execute in parallel.
{ An improved Solidity, called Solidity++. This new language will support versioning, safe mathematics
and xed point arithmetic, an improved type system, compilation to LLVM, and just-in-time execution.
280 If a developer requires EVM support but wants to deploy smart contracts in a private subnet, they
can spin a new subnet directly. This is how AVA enables functionality-speci c sharding through the subnets.
Furthermore, if a developer requires interactions with the currently deployed Ethereum smart contracts,
they can interact with the Athereum subnet, which is a spoon of Ethereum. Finally, if a developer requires a
di erent execution environment from the Ethereum virtual machine, they may choose to deploy their smart
285 contract through a subnet that implements a di erent execution environment, such as DAML 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 $AVA Token
290 4.1 The $AVA Native Token
Monetary Policy The native token, $AVA, is capped-supply. However, unlike other capped-supply tokens
which bake the rate of minting perpetually, $AVA is designed to react to changing economic conditions.
In particular, the objective of $AVA’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
295 platform collectively act as a decentralized reserve bank. The levers available on AVA are staking rewards,
fees, and airdrops, all of which are in
uenced by governable parameters. Staking rewards are set by on-chain
governance, and are ruled by a function designed to never surpass the capped supply. Staking can be induced
10 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
by increasing fees or increasing staking rewards. On the other hand, we can induce increased engagement
with the AVA platform services by lowering fees, and decreasing the staking reward.
300 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. $AVA is as powerful and easy to use as payments with
Visa, allowing thousands of transactions globally every second, in a fully trustless, decentralized manner.
Furthermore, for merchants worldwide, $AVA provides a direct value proposition over Visa, namely lower
305 fees.
Staking: Securing the System On the AVA 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 disproportionately
310 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 AVA token serves as the universal unit
of exchange. From there, the AVA platform will be able to support trustless atomic swaps natively on the
315 platform enabling native, truly decentralized exchanges of any type of asset directly on AVA.
4.2 Governance
Governance is critical to the development and adoption of any platform because { as with all other types of
systems { AVA will also face natural evolution and updates. $AVA provides on-chain governance for critical
parameters of the network where participants are able to vote on changes to the network and settle network
320 upgrade decisions democratically. This includes factors such as the minimum staking amount, minting rate,
as well as other economic parameters. This enables the platform to e ectively perform dynamic parameter
optimization through a crowd oracle. However, unlike some other governance platforms out there, AVA does
not allow unlimited changes to arbitrary aspects of the system. Instead, only a pre-determined number of
parameters can be modi ed via governance, rendering the system more predictable and increasing safety.
325 Further, all governable parameters are subject to limits within speci c time bounds, introducing hysteresis,
and ensuring that the system remains predictable over short time ranges.
A workable process for nding globally acceptable values for system parameters is critical for decentralized
systems without custodians. AVA 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 issue
330 such proposals.
AVA Platform 2020/02/12 11
Nominal reward rate is an important parameter that a ects any currency, whether digital or at. Unfortunately,
cryptocurrencies that x this parameter might face various issues, including de
ation or in
ation.
To that end, the nominal reward rate is subject to governance, within pre-established boundaries. This will
allow token holders to choose on whether $AVA is eventually capped, uncapped, or even de
ationary.
Transaction fees, denoted by the set F335 , are also subject to governance. F is e ectively a tuple which describes
the fees associated with the various instructions and transactions. Finally, staking times and amounts
are also governable. The list of these parameters is de ned in Figure 1.
{ : Staking amount, denominated in $AVA. This value de nes the minimal stake required to be placed as
bond before participating in the system.
{ min : The minimal amount of time required for a node to stake into the system.
{ max : The maximal amount of time a node can stake.
{ : (; min) ! 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 publicly disclosed nodes
under its ownership, over a period of consecutive min timeframes, such that min 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 AVA. All notation is rede ned upon rst use.
In line with the principle of predictability in a nancial system, governance in $AVA has hysteresis,
meaning that changes to parameters are highly dependent on their recent changes. There are two limits
340 associated with each governable parameter: time and range. Once a parameter is changed using a governance
transaction, it becomes very dicult to change it again immediately and by a large amount. These diculty
and value constraints relax as more time passes since the last change. Overall, this keeps the system from
changing drastically over a short period of time, allowing users to safely predict system parameters in the
short term, while having strong control and
exibility for the long term.
345 5 Discussion
5.1 Optimizations
Pruning Many blockchain platforms, especially those implementing Nakamoto consensus such as Bitcoin,
su er from perpetual state growth. This is because { by protocol { they have to store the entire history of
transactions. However, in order for a blockchain to grow sustainably, it must be able to prune old history.
350 This is especially important for blockchains that support high performance, such as AVA.
Pruning is simple in the Snow* family. Unlike in Bitcoin (and similar protocols), where pruning is not
possible per the algorithmic requirements, in $AVA 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
12 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
nodes, and therefore simply have to store active state, i.e. the current balances, as well as uncommitted
355 transactions.
Client Types AVA can support three di erent types of clients: archival, full, and light. Archival nodes store
the entire history of the $AVA subnet, the staking subnet, and the smart contract subnet, all the 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 nodes are
360 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, AVA supports light clients which can prove that some
transaction has been committed without needing to download or synchronize history. Light clients engage
365 in the repeated sampling phase of the protocol to ensure safe commitment and network wide consensus.
Therefore, light clients in AVA 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
370 storing and maintaining only speci c subparts of the entire global state; lastly, in transaction sharding,
participants agree to separate the processing of incoming transactions.
In AVA Borealis, the rst form of sharding exists through the subnetworks functionality. For example,
one may launch a gold subnet and another real-estate subnet. These two subnets can exist entirely in parallel.
The subnets interact only when a user wishes to buy real-estate contracts using their gold holdings, at which
375 point AVA will enable an atomic swap between the two subnets.
5.2 Concerns
Post Quantum Cryptography Post-quantum cryptography has recently gained widespread attention
due to the advances in the development of quantum computers and algorithms. The concern with quantum
computers is that they can break some of the currently deployed cryptographic protocols, speci cally digital
380 signatures. The AVA 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.
385 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
AVA Platform 2020/02/12 13
random choices of all correct nodes, as well as can update its own state at any time, before and after the
correct node has the chance to update its own state. E ectively, this adversary is all powerful, except for
the ability to directly 390 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 dicult to deploy.
Inclusion and Equality A common problem in permissionless currencies is that of the rich getting richer”.
395 This is a valid concern, since a PoS system that is improperly implemented may in fact allow wealth generation
to be disproportionately attributed to the already large holders of stake in the system. A simple example
is that of leader-based consensus protocols, wherein a subcommittee or a designated leader collects all the
rewards during its operation, and where the probability of being chosen to collect rewards is proportional
to the stake, accruing strong reward compounding e ects. Further, in systems such as Bitcoin, there is a
400 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, AVA employs an egalitarian distribution of minting: every single
participant in the staking protocol is rewarded equitably and proportionally based on stake. By enabling
very large numbers of people to participate rst-hand in staking, AVA can accommodate millions of people
to participate equally in staking. The minimum amount required to participate in the protocol will be up for
405 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 AVA platform. Compared to other platforms today, which
either run classical-style consensus protocols and therefore are inherently non-scalable, or make usage of
410 Nakamoto-style consensus that is inecient and imposes high operating costs, the AVA is lightweight, fast,
scalable, secure, and ecient. The native token, which serves for security the network and paying for various
infrastructural costs is simple and backwards compatible. $AVA 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.
415 Besides the consensus engine, AVA innovates up the stack, and introduces simple but important ideas
in transaction management, governance, and a slew of other components not available in other platforms.
Each participant in the protocol will have a voice in in
uencing how the protocol evolves at all times, made
possible by a powerful governance mechanism. AVA supports high customizability, allowing nearly instant
plug-and-play with existing blockchains.
420 References
1. Bitcoin: bitcoin/bitcoin (Oct 2018), https://github.com/bitcoin/bitcoin
2. Douceur, J.R.: The sybil attack. In: InternationalWorkshop on Peer-to-Peer Systems. pp. 251{260. Springer (2002)
14 Kevin Sekniqi, Daniel Laine, Stephen Buttolph, and Emin Gun Sirer
3. Dynamics, A.C.: (2019), https://ava.network/pdfs/ava-borealis-cd.pdf
4. Eyal, I., Gencer, A.E., Sirer, E.G., van Renesse, R.: Bitcoin-ng: A scalable blockchain protocol. In: 13th USENIX
Symposium on Networked 425 Systems Design and Implementation, NSDI 2016, Santa Clara, CA, USA, March 16–18,
2016. pp. 45{59 (2016), https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/eyal
5. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)
6. Rocket, T.: Snow
ake to Avalanche: A novel metastable consensus protocol family for cryptocurrencies. IPFS
(2018),
430 https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV
7. Wood, G.: Ethereum: A secure decentralised generalised transaction ledger (2014
Published at Thu, 13 Feb 2020 07:46:33 +0000
