Permissionless and asynchronous asset transfer

Most modern asset transfer systems use consensus to maintain a totally ordered chain of transactions. It was recently shown that consensus is not always necessary for implementing asset transfer. More efficient, asynchronous solutions can be built using reliable broadcast instead of consensus. This approach has been originally used in the closed (permissioned) setting. In this paper, we extend it to the open (permissionless) environment. We present Pastro, a permissionless and asynchronous asset-transfer implementation, in which quorum systems, traditionally used in reliable broadcast, are replaced with a weighted Proof-of-Stake mechanism. Pastro tolerates a dynamic adversary that is able to adaptively corrupt participants.


Introduction
Inspired by advances in peer-to-peer data replication [25,31], a lot of efforts are currently invested in designing an algorithm for consistent and efficient exchange of assets in dynamic settings, where the set of participants, actively involved in processing transactions, varies over time. Sometimes such systems are called permissionless, emphasizing the fact that they assume no trusted mechanism to regulate who and when can join the system. In particular, permissionless protocols should tolerate the notorious Sybil attack [7], where the adversary creates an unbounded number of "fake" identities.
Sharing data in a permissionless system is a hard problem. To solve it, we have to choose between consistency and efficiency. Assuming that the network is synchronous and that the adversary can only possess less than half of the total computing power, Bitcoin [25] and Ethereum [31] make sure that participants reach consensus on the order in which they access and modify the shared data. For this purpose, these systems employ a proof-of-work (PoW) mechanism to artificially slow down active participants (miners). The resulting algorithms are notoriously slow and waste tremendous amounts of energy.
Other protocols obviate the energy demands using proof-of-stake [2,4,18], proof-of-space [9], or proof of space-time [24]. However, these proposals still resort to synchronous networks, randomization, non-trivial cryptography and/or assume a trusted setup system.
In this paper, we focus on a simpler problem, asset transfer, enabling a set of participants to exchange assets across their accounts. It has been shown [15,16] that this problem does not require consensus. Assuming that every account is operated by a dedicated user, there is no need for the users to agree on a total order in which transactions must be processed: one can build an asset transfer system on top of the reliable broadcast abstraction instead of consensus. Unlike consensus [11], reliable broadcast allows for simple asynchronous solutions, enabling efficient asset transfer implementations that outperform their consensus-based counterparts [6].
Conventionally, a reliable broadcast algorithm assumes a quorum system [12,22]. Every delivered message should be certified by a quorum of participants. Any two such quorums must have a correct participant in common and in every run, at least one quorum should consist of correct participants only. In a static f -resilient system of n participants, these assumptions result in the condition f < n/3. In a permissionless system, where the Sybil attack is enabled, assuming a traditional quorum system does not appear plausible. Indeed, the adversary may be able to control arbitrarily many identities, undermining any quorum assumptions.
In this paper, we describe a permissionless asset-transfer system based on weighted quorums. More precisely, we replace traditional quorums with certificates signed by participants holding a sufficient amount of assets, or stake. One can be alerted by this assumption, however: the notion of a "participant holding stake" at any given moment of time is not well defined in a decentralized consensus-free system where assets are dynamically exchanged and participants may not agree on the order in which transactions are executed. We resolve this issue using the notion of a configuration. A configuration is a partially ordered set of transactions that unambiguously determines the active system participants and the distribution of stake among them. As has been recently observed, configurations form a lattice order [20] and a lattice agreement protocol [10,20,21] can be employed to make sure that participants properly reconcile their diverging opinions on which configurations they are in.
Building on these abstractions, we present the Pastro protocol to settle asset transfers, despite a dynamic adversary that can choose which participants to compromise during the execution, taking their current stake into account. The adversary is restricted, however, to corrupt participants that together own less than one third of stake in any active candidate configuration. Intuitively, a configuration (a set of transactions) is an active candidate configuration if all its transactions can be accepted by a correct process. At any moment of time, we may have multiple candidate configurations, and the one-third stake assumption must hold for each of them.
Note that a superseded configuration that has been successfully replaced with a new one can be compromised by the adversary. To make sure that superseded configurations cannot deceive slow participants that are left behind the reconfiguration process, we employ a forward-secure digital signature scheme [1,8], recently proposed for Byzantine fault-tolerant reconfigurable systems [21]. The mechanism allows every process to maintain a single public key and a "one-directional" sequence of matching private keys: it is computationally easy to compute a new private key from an old one, but not vice versa. Intuitively, before installing a new configuration, one should ask holders of > 2/3 of stake of the old one to upgrade their private keys and destroy the old ones.
We believe that Pastro is the right alternative to heavy-weight consensus-based replicated state machines, adjusted to applications that do not require global agreement on the order on their operations [20,27]. Our solution does not employ PoW [25,31] and does not rely on complex cryptographic constructions, such as a common coin [4,26]. More importantly, unlike recently proposed solutions [14,28], Pastro is resistant against a dynamic adversary that can choose which participants to corrupt in a dynamic manner, depending on the execution.
In this paper, we first present Pastro in its simplest version, as our primary message is a possibility result: a permissionless asset-transfer system can be implemented in an asynchronous way despite a dynamic adversary. We then discuss multiple ways of improving and generalizing our system. In particular, we address the issues of maintaining a dynamic amount of assets via an inflation mechanism and the performance of the system by delegation and incremental updates.
Road map. We overview related work in Section 2. In Section 3, we describe our model and recall basic definitions, followed by the formal statement of the asset transfer problem in Section 4. In Section 5, we describe Pastro and outline its correctness arguments in Section 6. We conclude with practical challenges to be addressed as well as related open questions in Section 7. Detailed proofs and the discussion of optimizations as well as delegation, fees, inflation, and practical aspects of using forward-secure digital signatures are deferred to the appendix.

Related Work
The first and still the most widely used permissionless cryptocurrencies are blockchainbased [5]. To make sure that honest participants agree (with high probability) on the order in which blocks of transactions are applied, the most prominent blockchains rely on proofof-work [25,31] and assume synchronous communication. The approach exhibits bounded performance, wastes an enormous amount of energy, and its practical deployment turns out to be hardly decentralized (https://bitcoinera.app/arewedecentralizedyet/). To mitigate these problems, more recent proposals suggest to rely on the stake rather than on energy consumption. E.g., in next version of Ethereum [30], random committees of a bounded number of validators are periodically elected, under the condition that they put enough funds at stake. Using nontrivial cryptographic protocols (verifiable random functions and common coins), Algorand [13] ensures that the probability for a user to be elected is proportional to its stake, and the committee is reelected after each action, to prevent adaptive corruption of the committee.
In this paper, we deliberately avoid reaching consensus in implementing asset transfer, and build atop asynchronous reliable broadcast, following [15,16]. It has been recently shown that this approach results in a simpler, more efficient and more robust implementation than consensus-based solutions [6]. However, in that design a static set of of processes is assumed, i.e., the protocol adheres to the permissioned model.
In [14], a reliable broadcast protocol is presented, that allows processes to join or leave the system without requiring consensus. ABC [28] proposes a direct implementation of a cryptocurrency, under the assumption that the adversary never corrupts processes holding 1/3 or more stake. However, both protocols [14,28] assume a static adversary: the set of corrupted parties is chosen at the beginning of the protocol.
In contrast, our solution tolerates an adversary that dynamically selects a set of corrupted parties, under the assumption that not too much stake is compromised in an active candidate configuration. Our solution is inspired by recent work on reconfigurable systems that base upon the reconfigurable lattice agreement abstraction [20,21]. However, in contrast to these general-purpose reconfigurable constructions, our implementation is much lighter. In D I S C 2 0 2 1

28:4
Permissionless and Asynchronous Asset Transfer our context, a configuration is just a distribution of stake, and every new transaction is a configuration update. As a result, we can build a simpler protocol that, unlike conventional asynchronous reconfigurable systems [20,21,29], does not bound the number of configuration updates for the sake of liveness.

Preliminaries
Processes and channels. We assume a set Π of potentially participating processes. In our model, every process acts both as a replica (maintains a local copy of the shared data) and as a client (invokes operations on the data). 1 In the proofs and definitions, we make the standard assumption of existence of a global clock not accessible to the processes. At any moment of time, a process can be correct or Byzantine. We call a process correct as long as it faithfully follows the algorithm it has been assigned. A process is forever-correct if it remains correct forever. A correct process may turn Byzantine, which is modelled as an explicit event in our model (not visible to the other processes). A Byzantine process may perform steps not prescribed by its algorithm or prematurely stop taking steps. Once turned Byzantine, the process stays Byzantine forever.
We assume a dynamic adversary that can choose the processes to corrupt (to render Byzantine) depending on the current execution (modulo some restrictions that we discuss in the next section). In contrast, a static adversary picks up the set of Byzantine processes a priori, at the beginning of the execution.
In this paper we assume that the computational power of the adversary is bounded and, consequently, the cryptographic primitives used cannot be broken.
We also assume that each pair of processes is connected via reliable authenticated channel. If a forever-correct process p sends a message m to a forever-correct process q, then q eventually receives m. Moreover, if a correct process q receives a message m from a correct process p, then p has indeed sent m to q.
For the sake of simplicity, we assume that the set Π of potentially participating processes is finite. 2 Weak reliable broadcast (WRB). In this paper we assume a weak reliable broadcast primitive to be available. The implementation of such primitive ensures the following properties: If a correct process delivers a message m from a correct process p, then m was previously broadcast by p; If a forever-correct process p broadcasts a message m, then p eventually delivers m; If a forever-correct process delivers m, then every forever-correct process eventually delivers m.
This weak reliable broadcast primitive can be implemented via a gossip protocol [17].
Forward-secure digital signatures. Originally, forward-secure digital signature schemes [1,8] were designed to resolve the key exposure problem: if the signature (private) key used in the scheme is compromised, then the adversary is capable to forge any previous (or future) signature. Using forward secure signatures, it is possible for the private key to be updated arbitrarily many times with the public key remaining fixed. Also, each signature is associated with a timestamp. This helps to identify messages which have been signed with the private keys that are already known to be compromised.
To generate a signature with timestamp t, the signer uses secret key sk t . The signer can update its secret key and get sk t2 from sk t1 if t 1 < t 2 ≤ T . However "downgrading" the key to a lower timestamp, from sk t2 to sk t1 , is computationally infeasible. As in recent work on Byzantine fault-tolerant reconfigurable systems [21], we model the interface of forward-secure signatures with an oracle which associates every process p with a timestamp st p . The oracle provides the following functions: FSSign(m, t) returns a signature for a message m and a timestamp t if t ≥ st p , otherwise ⊥; FSVerify(m, p, s, t) returns true if s ̸ = ⊥ and it was generated by process p using FSSign(m, t), false otherwise.
In most of the known implementations of forward-secure digital signature schemes the parameter T should be fixed in advance, which makes number of possible private key updates finite. At the same time, some forward-secure digital schemes [23] allow for an unbounded number of key updates (T = +∞), however the time required for an update operation depends on the number of updates. Thus, local computational time may grow indefinitely albeit slowly. We discuss these two alternative implementations and reason about the most appropriate one for our problem in the technical report [19].
Verifiable objects. We often use certificates and verifiable objects in our protocol description. We say that object obj ∈ O is verifiable in terms of a given verifying function is a set of all possible certificates for objects of set O. A certificate σ obj is valid for obj (in terms of a given verifying function) iff Verify(obj, σ obj ) = true. The actual meaning of an object "verifiability", as well as of a certificate validness, is determined by the verifying function.

Asset Transfer: Problem Statement
Before defining the asset transfer problem formally, we introduce the concepts used later.

Transactions.
A transaction is a tuple tx = (p, τ, D). Here p ∈ Π is an identifier of a process inside the system that initiates a transaction. We refer to p as the owner of tx. The map τ : Π → Z + 0 is the transfer function, specifying the amount of funds received by every process q ∈ Π from this transaction. 3 D is a finite set of transactions that tx depends on, i.e., tx spends the funds p received through the transactions in D. We refer to D as the dependency set of tx.
Let T denote the set of all transactions. The function value : T → V is defined as follows: value(tx) = q∈Π tx.τ (q). T contains one special "initial" transaction tx init = (⊥, τ init , ∅) with value(tx init ) = M and no sender. This transaction determines the initial distribution of the total amount of "stake" in the system (denoted M ).
For all other transactions it holds that a transaction tx is valid if the amount of funds spent equals the amount of funds received: value(tx) = t∈t.D t.τ (tx.p). For simplicity, we assume that T contains only valid transactions: invalid transactions are ignored.
Transactions defined this way, naturally form a directed graph where each transaction is a node and edges represent dependencies.
We say that transactions tx i and tx j issued by the same process conflict iff the intersection of their dependency sets is non-empty: A correct member of an asset-transfer system does not attempt to double spend, i.e., it never issues transactions which share dependencies and are therefore conflicting.
Transactions are equipped with a boolean function VerifySender : Here σ tx is a certificate that confirms that tx was indeed issued by its owner process p. One may treat a transaction's certificate as p's digital signature of tx. Asset-transfer system. An asset-transfer system (AS) maintains a partially ordered set of transactions T p and exports one operation: Transfer(tx, σ tx ) adding transaction tx to the set T p . Recall that tx = (p, τ, D), where p is the owner of transaction, τ is a transfer map, D is the set of dependencies, and σ tx is a matching certificate.
In a distributed AS implementation, every process p holds the set of "confirmed" transactions T p it is aware of, i.e., a local copy of the state. A transaction is said to be confirmed if some correct process p adds tx to its local copy of the state T p . Set T p can be viewed as the log of all confirmed transactions a process p is aware of. Let T p (t) denote the value of T p at time t.
An AS implementation then satisfies the following properties: Consistency: For every process p correct at time t, T p (t) contains only verifiable and nonconflicting transactions. Moreover, for every two processes p and q correct at time t and t ′ resp.: . Monotonicity: For every correct process p, T p can only grow with time: for all t < t ′ , . Validity: If a forever-correct process p invokes Transfer(tx, σ tx ) at time t, then there exists t ′ > t such that tx ∈ T p (t ′ ). Agreement: For a process p correct at time t and a forever-correct process q, there exists Here, σ tx ∈ Σ T is a certificate for transaction tx = (p, τ, D). A certificate protects the users from possible theft of their funds by other users. As we assume that cryptographic techniques (including digital signatures) are unbreakable, the only way to steal someone's funds is to steal their private key.
A natural convention is that a correct process never submits conflicting transactions. When it comes to Byzantine processes, we make no assumptions. Our specification ensures that if two conflicting transactions are issued by a Byzantine process, then at most one of them will ever be confirmed. In fact, just a single attempt of a process to cheat may lead to the loss of its funds as it can happen that neither of the conflicting transactions is confirmed and thus may preclude the process from making progress.
Transaction set as a configuration. For simplicity, we assume that the total amount of funds in the system is a publicly known constant M ∈ Z + (fixed by the initial transaction tx init ) that we call system stake. 4 A set of transactions C ∈ 2 T is called a configuration. A configuration C is valid if no two transactions tx i , tx j ∈ C are conflicting. In the rest of this paper, we only consider valid configurations, i.e., invalid configurations appearing in protocol messages are ignored by correct processes without being mentioned explicitly in the algorithm description.
The initial configuration is denoted by C init , and consists of just one initial transaction A valid configuration C determines the stake (also known as balance) of every process p as the difference between the amount of assets sent to p and the amount of assets sent by p in the transactions of C: stake(q, C) = tx∈C tx.τ (q) − tx∈C∧tx.p=q value(tx). Intuitively, a process joins the asset-transfer system as soon as it gains a positive stake in a configuration and leaves once its stake turns zero.
Functions members and quorums are defined as follows: Intuitively, members of the system in a given configuration C are the processes that received money at least once, and a set of processes is considered to be a quorum in configuration C, if their total stake in C is more than two-thirds of the system stake.

Configuration lattice.
Recall that a join-semilattice (we simply say a lattice) is a tuple (L, ⊑), where L is a set of elements provided with a partial-order relation ⊑, such that for any two elements a ∈ L and b ∈ L, there exists the least upper bound for the set {a, b}, i.e., an element c ∈ L such that a ⊑ c, b ⊑ c and ∀d ∈ L: if a ⊑ d and b ⊑ d, then c ⊑ d. The least upper bound of elements a ∈ L and b ∈ L is denoted by a ⊔ b. ⊔ is an associative, commutative and idempotent binary operator on L. It is called the join operator.
The configuration lattice is then defined as (C, ⊑), where C is the set of all valid configurations, ⊑=⊆ and ⊔ = ∪.

Pastro Asset Transfer: Algorithm
In this section we present Pastro -an implementation of an asset-transfer system. We start with the main building blocks of the algorithm, and then proceed to the description of the Pastro protocol itself. We bundle parts of Pastro algorithm that are semantically related in building blocks called objects, each offering a set of operations, and combine them to implement asset transfer.
Transaction Validation. The Transaction Validation (TV) object is a part of Pastro ensuring that transactions that a correct process p adds to its local state T p do not conflict.
A correct process p submits a transaction tx = (p, τ, D) and a matching certificate to the object by invoking an operation Validate(tx, σ tx ). The operation returns a set of transactions txs ∈ 2 T together with a certificate σ txs ∈ Σ 2 T . We call a transaction set verifiable iff it is verifiable in terms of a function VerifyTransactionSet(txs, σ txs ). Intuitively, the function returns true iff certificate σ txs confirms that set of transactions txs is validated by sufficiently many system members.
Formally, TV satisfies the following properties: TV-Verifiability: If an invocation of Validate returns ⟨txs, σ txs ⟩ to a correct process, then VerifyTransactionSet(txs, σ txs ) = true; TV-Inclusion: If Validate(tx, σ tx ) returns ⟨txs, σ txs ⟩ to a correct process, then tx ∈ txs; TV-Validity: The union of returned verifiable transaction sets consists of non-conflicting verifiable transactions. In our algorithm, we use one Transaction Validation object TxVal.

Permissionless and Asynchronous Asset Transfer
Adjustable Byzantine Lattice Agreement. Our asset-transfer algorithm reuses elements of an implementation of Byzantine Lattice Agreement (BLA), a Lattice Agreement [10] protocol that tolerates Byzantine failures. We introduce Adjustable Byzantine Lattice Agreement (ABLA), an abstraction that captures safety properties of BLA. An ABLA object is parameterized by a lattice (L, ⊑) and a boolean function VerifyInputValue : L × Σ L → {true, false}. An input value of a given ABLA object is verifiable if it complies with VerifyInputValue.
ABLA exports one operation: where v ∈ L is an input value and σ v ∈ Σ L is a matching certificate. It also exports function VerifyOutputValue : L × Σ L → {true, false}. The Propose operation returns a pair ⟨w, σ w ⟩, where w ∈ L is an output value and σ w ∈ Σ L is a matching certificate. An output value w of an ABLA object is verifiable if it complies with function VerifyOutputValue.
An ABLA object satisfies the following properties: ABLA-Validity : Every verifiable output value w is a join of some set of verifiable input values; ABLA-Verifiability: If an invocation of Propose returns ⟨w, σ w ⟩ to a correct process, then VerifyOutputValue(w, σ w ) = true; ABLA-Inclusion: If Propose(v, σ v ) returns ⟨w, σ w ⟩, then v ⊑ w; ABLA-Comparability: All verifiable output values are comparable. In our algorithm, we use two ABLA objects, ConfigLA and HistLA.
Combining TV and ABLA. Let ConfigLA be an ABLA object parameterized as follows: that is a part of TV. The function VerifyConfiguration(C, σ C ) is an alias for ConfigLA.VerifyOutputValue(C, σ C ). Using this object, the processes produce comparable configurations, i.e., transaction sets related by containment (⊆).
HistLA is an ABLA object used to produce sets of configurations that are all related by containment. Under the assumption that every input (a set of configurations) to the object only contains comparable configurations, the outputs are related by containment and configurations in these sets are comparable. We can see these sets as sequences of ordered configurations. Such sets are called histories, as was recently suggested for asynchronous Byzantine fault-tolerant reconfiguration [21]. It was shown that histories allow us to access only O(n) configurations, when n configurations are concurrently proposed. A history h is called verifiable if it complies with VerifyHistory(h, σ h ).
Formally, the ABLA object HistLA is parameterized as follows: (L, ⊑) = (2 2 T , ⊆). The requirement that the elements of an input are comparable is established via the HistLA.VerifyOutputValue(H, σ H ).  Thus, the only valid input values for the HistLA object consist of verifiable output values of the ConfigLA object. At the same time, the only valid input values for the ConfigLA object are verifiable transaction sets, returned from the TxVal object. And, the only valid inputs for a TxVal object are signed transactions. In this case, all verifiable histories are related by containment (comparable via ⊆), and all configurations within one verifiable history are related by containment (comparable via ⊆) as well. Such a pipeline helps us to guarantee that all configurations of the system are comparable and contain non-conflicting transactions. Hence, such configurations can act as a consistent representation of stake distribution that changes with time.

VerifyHistory(H, σ H ) is an alias for
To get a high-level idea of how Pastro works, imagine a conveyor belt (Figure 1). Transactions of different users are submitted as inputs, and as outputs, they obtain sets of configurations. Then one can choose the configuration representing the largest resulting set and install it in the system, changing the funds distribution in the system.

Algorithm overview.
We assume that blocks of code (functions, operations, callbacks) are executed sequentially until they complete or get interrupted by a wait condition (wait for . . . ). Some events, e.g., receiving a message, may trigger callbacks (marked with keyword upon). However, they are not executed immediately, but firstly placed in an event queue, waiting for their turn.
By "let var = expression" we denote an assignment to a local variable (which can be accessed only from the current function, operation, or callback), and by "var ← expression" we denote an assignment to a global variable (which can be accessed from anywhere by the same process).
We denote calls to a weak reliable broadcast primitive with WRB-broadcast⟨. . . ⟩ and WRB-deliver⟨. . . ⟩. Besides, we assume a weak uniform reliable broadcast (WURB) primitive, a variant of uniform reliable broadcast [3]. WURB ensures an additional property compared to WRB: if the system remains static (i.e., the configurations stop changing) and a correct process delivers message m, then every forever-correct process eventually delivers m. The primitive helps us to ensure that if configuration C is never replaced with a greater one, then every forever-correct process will eventually learn about such a configuration C. To achieve this semantics, before triggering the deliver callback, a correct process just needs to ensure that a quorum of replicas have received the message [3]. The calls to WURB should be associated with some configuration C, and are denoted as WURB-broadcast⟨. . . , C⟩ and WURB-deliver⟨. . . , C⟩.
The algorithm uses one TV object TxVal and two ABLA objects: ConfigLA and HistLA. We list the pseudocode for the implementation of the TxVal object in Appendix A, Figure 5. The implementations of ConfigLA and HistLA are actually the same, and only differ in their parameters, we therefore provide one generalized implementation for both objects (Appendix A, Figure 6).
Every process maintains variables history, T p and C cur , accessible everywhere in the code. T p is the latest installed configuration by the process p, by C cur we denote the configuration starting from which the process needs to transfer data it stores to greater configurations, and history is the current verifiable history (along with its certificate σ hist ).
The main part of Pastro protocol (depicted in Figure 2) exports one operation Transfer(tx, σ tx ).
In this operation, we first set the local variables that store intermediate results produced in this operation, to null values ⊥. Next, the Validate operation of the Transaction Validation object TxVal is invoked with the given transaction tx and the corresponding certificate σ tx . The set of transactions txs and certificate σ txs returned from the TV object are then used as an input for Propose operation of ConfigLA. Similarly, the result returned D I S C 2 0 2 1 from ConfigLA "wrapped in" a singleton set, is used as an input for Propose operation of HistLA. The returned verifiable history is then broadcast in the system. We consider operation Transfer(tx, σ tx ) to complete by a correct process p once process p broadcasts message ⟨NewHistory, h, σ⟩ at line 9 or if p stops the current Transfer by executing line 17. Basically, the implementation of Transfer operation follows the logic described before and depicted in Figure 1. If a correct process delivers a message ⟨NewHistory, h, σ⟩, where σ is a valid certificate for history h that is greater than its local estimate history, it "restarts" the first step that it has not yet completed in Transfer operation (lines [18][19][20][21][22][23]. For example, if a correct process p receives a message ⟨NewHistory, h, σ h ⟩, where σ h is a valid certificate for h and history ⊂ h while being in ConfigLA, it restarts this step in order to access a greater configuration. The result of ConfigLA will still be returned to p in the place it has called ConfigLA.Propose. Intuitively, we do this in order to reach the most "up-to-date" configuration ("up-to-date" stake holders).
The State Transfer Protocol (Figure 3) helps us to ensure that the properties of the objects (TxVal, ConfigLA and HistLA) are satisfied across configurations that our system goes through. As system stake is redistributed actively with time, quorums in the system change as well and, hence, we need to pass the data that some quorum knows in configuration C to some quorum of any configuration C ′ : C ⊏ C ′ , that might be installed after C. The protocol is executed by a correct process after it delivers a verifiable history h, such that C ∈ h and C cur ⊏ C.
The height of a configuration C is the number of transactions in it (denoted as height(C) = |C|). Since all configurations installed in Pastro are comparable, height can be used as a unique identifier for an installed configuration. We also use height as the timestamp for forward-secure digital signatures. When a process p answers requests in configuration C, it signs the message with timestamp height(C). The process p invokes UpdateFSKey(height(C ′ )) when it discovers a new configuration C ′ : C ⊏ C ′ . Thus, processes that still consider C as the current configuration (and see the corresponding stake distribution) cannot be deceived by a process p, that was correct in C, but not in a higher installed configuration C ′ (e.g., p spent all its stake by submitting transactions, which became part of configuration C ′ , thereby lost its weight in the system, and later became Byzantine).
The implementation of verifying functions ( Figure 4) and a description of the auxiliary functions used in the pseudocode are delegated to Appendix A.
Implementing Transaction Validation. The implementation of the TV object TxVal is depicted in Figure 5 (Appendix A). The algorithm can be divided into two phases.
In the first phase, process p sends a message request that contains a set of transactions sentTxs to be validated to all members of the current configuration. Every correct process q that receives such messages first checks whether the transactions have actually been issued by their senders. If yes, q adds the transactions in the message to the set of transactions it has seen so far and checks whether any transaction from the ones it has just received conflicts with some other transaction it knows about. All conflicting transactions are placed in set conflictTxs. After q validates transactions, it sends a message ⟨ValidateResp, txs, conflictTxs, sig, sn⟩. Here, txs is the union of verifiable transactions received by p from q just now and all other non-conflicting transactions p is aware of so far. Process p then verifies a received message ⟨ValidateResp, txs q , conflictTxs q , sig q , sn⟩. The message received from q is considered to be valid by p if q has signed it with a private key that corresponds to the current configuration, all the transactions from txs q have valid certificates, and if for any verifiable transaction tx from conflictTxs there is a verifiable transaction tx also from conflictTxs, such that tx conflicts with tx ′ . If the received message is valid and txs q equals sentTxs, then p adds signature of process q and its validation result to its local set acks 1 . In case sentTxs ⊂ txs q , the whole phase is restarted. The first phase is considered to be completed as soon as p collects responses from some quorum of processes in acks 1 .
Such implementation of the first phase makes correct process p obtain certificate not only for its transaction, but also for other non-conflicting transactions issued by other processes. This helping mechanism ensures that transactions of forever-correct processes are eventually confirmed and become part of some verifiable configuration. In the second phase, p collects signatures from a weighted quorum of the current configuration. If p successfully collects such a set of signatures, then the configuration it saw during the first phase was active (no greater configuration had been installed) and it is safe for p to return the obtained result. This way the so-called "slow reader" attack [21] is anticipated.
If during any of the two phases p receives a message with a new verifiable history that is greater (w.r.t. ⊆) than its local estimate and does not contain last issued transaction by p, the described algorithm starts over. We guarantee that the number of restarts in TxVal in Pastro protocol is finite only for forever-correct processes (please refer to the technical report [19] for a detailed proof). Note that we cannot guarantee this for all correct processes as during the protocol execution some of them can become Byzantine.
In the implementation, we assume that the dependency set of a transaction only includes transactions that are confirmed (i.e., included in some installed configuration), otherwise they are considered invalid. Implementing Adjustable Byzantine Lattice Agreement. The generalized implementation of ABLA objects ConfigLA and HistLA is specified by Figure 6 (Appendix A). The algorithm is generally inspired by the implementation of Dynamic Byzantine Lattice Agreement from [21], but there are a few major differences. Most importantly, it is tailored to work even if the number of reconfiguration requests (i.e., transactions) is infinite. Similarly to the Transaction Validation implementation, algorithm consists of two phases.
In the first phase, process p sends a message that contains the verifiable inputs it knows to other members and then waits for a weighted quorum of processes of the current configuration to respond with the same set. If p receives a message with a greater set (w.r.t. ⊆), it restarts the phase. The validation process performed by the processes is very similar to the one used in Transaction Validation object implementation.
The second phase, in fact, is identical to the second phase of the Transaction Validation implementation. We describe it in the pseudocode for completeness.
As with Transaction Validation, whenever p delivers a verifiable history h, such that it is greater than its own local estimate and h does not contain last issued transaction by p, the described algorithm starts over. Similarly to TxVal, it is guaranteed that the number of restarts a forever-correct process make in both ConfigLA and HistLA is finite.

Proof of Correctness
In this section, we outline the proof that Pastro indeed satisfies the properties of an asset-transfer system. First, we formulate a restriction we impose on the adversary that is required for our implementation to be correct. Informally, the adversary is not allowed to corrupt one third or more stake in a "candidate" configuration, i.e., in a configuration that can potentially be used for adding new transactions. The adversary is free to corrupt a configuration as soon as it is superseded by a strictly higher one. We then sketch the main arguments of our correctness proof (the detailed proof is available in [19]).

Adversarial restrictions
A configuration C is considered to be installed if some correct process has triggered the special event InstalledConfig(C). We call a configuration C a candidate configuration if some correct process has triggered a NewHistory(h) event, such that C ∈ h. We also say that a configuration C is superseded if some correct process installed a higher configuration C ′ . An installed (resp., candidate) configuration C is called an active (resp., an active candidate) configuration as long as it is not superseded. Note that at any moment of time t, every active installed configuration is an active candidate configuration, but not vice versa. We expect the adversary to obey the following condition: Configuration availability: Let C be an active candidate configuration at time t and let correct(C, t) denote the set of processes in members(C) that are correct at time t. Then C must be available at time t: Note that the condition allows the adversary to compromise a candidate configuration once it is superseded by a more recent one. As we shall see, the condition implies that our algorithm is live. Intuitively, a process with a pending operation will either eventually hear from the members of a configuration holding "enough" stake which might allow it to complete its operation or will learn about a more recent configuration, in which case it can abandon the superseded configuration and proceed to the new one.

Proof outline
Consistency. The consistency property states that (1) as long as process p is correct, T p contains only verifiable non-conflicting transactions and (2) if processes p and q are correct at times t and t ′ respectively, then T p (t) ⊆ T q (t ′ ) or T q (t ′ ) ⊆ T p (t). To prove that Pastro D I S C 2 0 2 1 satisfies this property, we show that our implementation of TxVal meets the specification of Transaction Validation and that both ConfigLA and HistLA objects satisfy the properties of Adjustable Byzantine Lattice Agreement. Correctness of HistLA ensures that all verifiable histories are related by containment and the correctness of ConfigLA guarantees that all verifiable configurations are related by containment (i.e., they are comparable). Taking into account that the only possible verifiable inputs for HistLA are sets that contain verifiable output values (configurations) of ConfigLA, we obtain the fact that all configurations of any verifiable history are comparable as well. As all installed configurations (all C such that a correct process triggers an event InstalledConfig(C)) are elements of some verifiable history, they all are related by containment too. Since T p is in fact the last configuration installed by a process p, we obtain (2). The fact that every p stores verifiable non-conflicting transactions follows from the fact that the only possible verifiable input values for ConfigLA are the output transaction sets returned by TxVal. As TxVal is a correct implementation of Transaction Validation, then union of all such sets contain verifiable non-conflicting transactions. Hence, the only verifiable configurations that are produced by the algorithm cannot contain conflicting transactions. From this we obtain (1).
Monotonicity. This property requires that T p only grows as long as p is correct. The monotonicity of Pastro follows from the fact that correct processes install only greater configurations with time, and that the last installed configuration by a correct process p is exactly T p . Thus, if p is correct at time t ′ , then for all t < t ′ : Validity. This property requires that a transfer operation for a transaction tx initiated by a forever-correct process will lead to tx being included in T p at some point in time. In order to prove this property for Pastro, we show that a forever-correct process p may only be blocked in the execution of a Transfer operation if some other process successfully installed a new configuration. We argue that from some moment of time on every other process that succeeds in the installation of configuration C will include the transaction issued by p in the C. We also show that if such a configuration C is installed then eventually every forever-correct process installs a configuration C ′ : C ⊑ C ′ . As T p is exactly the last configuration installed by p, eventually any transaction issued by a forever-correct process p is included in T p .

Agreement.
In the end we show that the Pastro protocol satisfies the agreement property of an asset-transfer system. The property states the following: for a correct process p at time t and a forever-correct process q, there exists t ′ ≥ t such that T p (t) ⊆ T p (t ′ ). Basically, it guarantees that if a transaction tx was considered confirmed by p when it was correct, then any forever-correct process will eventually confirm it as well. To prove this, we show that if a configuration C is installed by a correct process, then every other forever-correct process will install some configuration C ′ , such that C ⊑ C ′ . Taking into account the fact that T p is a last configuration installed by a process p, we obtain the desired.

Concluding Remarks
Pastro is a permissionless asset transfer system based on proof of stake. It builds on lattice agreement primitives and provides its guarantees in asynchronous environments where less than one third of the total stake is owned by malicious parties.

Enhancements and optimizations.
To keep the presentation focused, so far we described only the core of the Pastro protocol. However, there is a number of challenges that need to be addressed before the protocol can be applied in practice. In particular the communication, computation and storage complexity of the protocol can be improved with carefully constructed messages and signature schemes. Also, mechanisms for stake delegation as well as fees and inflation are necessary. Note that these are non-trivial to implement in an asynchronous system because there is no clear agreement on the order in which transactions are added to the system or on the distribution of stake at the moment when a transaction is added to the system. We discuss these topics as well as the practical aspects of using forward-secure signatures in the technical report [19].
Open questions. In this paper, we demonstrated that it is possible to combine asynchronous cryptocurrencies with proof-of-stake in presence of a dynamic adversary. However, there are still plenty of open questions. Perhaps, the most important direction is to study hybrid solutions which combine our approach with consensus in an efficient way in order to support general-purpose smart contracts. Further research is also needed in order to improve the efficiency of the solution and to measure how well it will behave in practice compared to consensus-based solutions. Finally, designing proper mechanisms in order to incentivize active and honest participation is a non-trivial problem in the harsh world of asynchrony, where the processes cannot agree on a total order in which transactions are executed.

A Pseudocode
Verifying and auxiliary functions. We provide implementations of required verifying functions used in ConfigLA and HistLA in Figure 4. The implementation of function VerifySender(tx, σ tx ) is not presented there, as it simply consists in verifying that σ tx is a valid signature for tx under tx.p's public key. We use the following auxiliary functions in the pseudocode to keep it concise: VerifySenders(txs) -returns true iff ∀⟨tx, σ tx ⟩ ∈ txs : VerifySender(tx, σ tx ) = true, otherwise returns false; VerifyValues(vs) -returns true if ∀⟨v, σ⟩ ∈ vs : VerifyInputValue(v, σ) = true, otherwise returns false; ContainsQuorum(acks, C) -returns true if ∃Q ∈ quorums(C) such that ∀q ∈ Q⟨q, . . . ⟩ ∈ acks, otherwise returns false; HighestConf(h) -returns the highest (w.r.t. ⊑) configuration in given history h; firsts() -method that, when invoked on a set of tuples S, returns a set of first elements of tuples from set S; ConflictTransactions(txs) -for a given set of verifiable transactions txs returns a set conflictTxs such that conflictTxs ⊆ txs and for any ⟨tx, σ tx ⟩ ∈ conflictTxs there exists ⟨tx ′ , σ tx ′ ⟩ ∈ conflictTxs such that tx conflicts with tx ′ ; CorrectTransactions(txs) -returns a set of transactions correctTxs such that correctTxs ⊆ txs, ⟨tx, σ tx ⟩ ∈ correctTxs iff ⟨tx, σ tx ⟩ ∈ txs, σ tx is a valid certificate for tx and ∄⟨tx ′ , σ tx ′ ⟩ ∈ txs, such that tx conflicts with tx ′ .