In this section, we provide the notation and syntax as well as the formal definitions of the ledger, which we need for the rest of this chapter. We work in the GUC model described in Section 2.4 and rely on the communication model for blockchain communication introduced in Section 3.4.
For the Perun protocol, we assume a fixed set of parties P = {P1, . . . ,Pn} that use the channel network system. We assume that before the protocol starts, a public-key infrastructure setup phase is executed by some trusted party. To simplify the protocol description, we denote the signature of P ∈P on a message m as SignP(m). We say that a tuple (x1, . . . , xn, σ) is signed by P if σ is a valid signature of P on (x1, . . . , xn), i.e., Vrfy(pkP,(x1, . . . , xn), σ) = 1. We emphasize that the use of a PKI is only an abstraction that helps to describe our protocols. In practice, the trusted setup can easily be realized by posting public keys on the blockchain. To keep the model as simple as possible, we do not include the transaction fees in our modeling.
We use keyword attributes attr to refer to certain values in (channel) tuples.
Formally, an attribute tuple is a function from its set of attributes to {0,1}∗. To
improve readability, the value of an attribute attr in a tuple T (i.e., T(attr)) is
referred to as T.attr.
All messages start with a keyword (e.g., lc-open). All communication with the
environment Z and with the ideal functionalities is instantaneous. To account for the blockchain delay, we allow the adversary to delay a reaction of the functionality
to a message by at most ∆ rounds. We write that some action is executed within time ∆. This means that the exact round until when this action is completed is
up to the adversary to decide, but ∆ is an upper bound.
We introduce two functionsπandθthat help to manage the balances of channels.
The balance function π :{P,Q} →R≥0 describes the current channel balance
or coin distribution between two parties P and Q. Adding q ∈R≥0 coins to
the account ofP in π results in a updated balance functionπ0 which is equal
toπ for party Qand for partyP, π0(P) = π(P) +q. Removingq coinsfrom
P’s account is shorthand for writingπ0(P) =π(P)−q.
The transfer function θ:{P,Q} →R describes the balance change for an up- date by specifying a redistribution. In particular it specifies how many coins are sent from one party (negative amount) to another (positive amount), hence the following must hold: θ(P) +θ(Q) = 0. Transferring q coins from
P toQ results in a transfer functionθ such thatθ(P) =−q and θ(Q) =q.
These functions can be added in a natural way, i.e., if f and g are transfer or
balance functions for the same parties P and Q, then h = f +g is a function h:{P,Q} →R≥0 defined as h(P) :=f(P) +g(P) and h(Q) := f(Q) +g(Q).
4.2.1 Channels Syntax
We define a ledger channel over the set of partiesP as an attribute tupleβ of the
form:
β = (β.id, β.Alice, β.Bob, β.cash)
and a virtual payment channelγ over P as an attribute tuple of the form: γ = (γ.id, γ.Alice, γ.Ingrid, γ.Bob, γ.cash, γ.subchan, γ.validity).
Every channel has an identifier δ.id ∈ {0,1}∗. The two parties δ.Alice, δ.Bob ∈ P
are two distinct elements of P called the end-users of δ. If δ = γ is a virtual
channel, then the party γ.Ingrid is also an element of P (distinct from δ.Alice
and δ.Bob) and it is sometimes called the intermediary. We define the set of end-users of δ as δ.end-users = {δ.Alice, δ.Bob} (note that when δ is a virtual
channel, then this set does not contain δ.Ingrid). If δ is a virtual channel then δ.all-usersdenotes the set {δ.Alice, δ.Bob, δ.Ingrid}, and ifδ is a ledger channel then
to the opposite end-party (or counterparty) in a channel, we define the short- cut δ.other-party : δ.end-users → δ.end-users as δ.other-party(δ.Alice) = δ.Bob and δ.other-party(δ.Bob) =δ.Alice, respectively. The attributeδ.cashis a balance func-
tion for the parties δ.end-users.
Virtual channels have more attributes than ledger channels. The attribute
δ.subchan is a function subchan: γ.end-users → {0,1}∗ which references the iden-
tifiers of the sub-channels γ.subchan(γ.Alice) and γ.subchan(γ.Bob) over which γ
is constructed. Second, the time parameter γ.validity ∈ N denotes the channel validity, i.e., the round until which the virtual payment channel stays open.
4.2.2 The Ledger Functionality
We aim to prove the security of the Perun protocol in the Global UC (GUC)
model (cf. Section 2.4) as it allows functionalities to access by functionalities from different sessions. In particular, we model the ledger L as a global functionality, which makes it available both in the real and ideal world, and moreover, can be used over multiple protocol executions [46, 41].
Functionality L
Functionality L runs with a set of parties P = {P1. . . ,Pn} and stores a valuepi ∈N≥0 for every partyPi, i∈[n] which denotes the number of coins that party Pi ∈P owns. It accepts queries of the following types:
Initialization Upon receiving message (init, p1, . . . , pn) from the Environ- ment Z (via Sim or A) such that pi ∈ N≥0 for all i ∈ [n], store this
tuple.
Add Coins Upon receiving a message (add,Pi, q) (for Pi ∈P and q ∈N≥0)
from an ideal functionality F let pi := pi+q. We say that the func- tionality F added q coins to Pi’s account in L
Remove Coins Upon receiving a message (remove,Pi, q) (for Pi ∈ P and
pi > q ∈ N≥0) from an ideal functionality F let pi := pi −q. We say that the functionality F removed q coins from Pi’s account in L
The state of the ledger L is public, and it maintains a non-negative vector of natural numbers (p1, . . . , pn), wherepi corresponds to the current amount of coins in partyPi’s account. The parties cannot directly access the ledger. Instead, their accounts are maintained via the smart contract functionalityC (in the real world)
or via the ideal functionality FChannels (in the ideal world). These functionalities
can add or remove coins on a parties’ account on the ledger by sending add or
remove messages. We assume that the communication of ideal functionalities and
the ledger is instant; this corresponds to the fact that contracts update the state of the ledger immediately after their execution. We model the blockchain delay (cf. Section 3.4) by modeling delays when contract functionalities, i.e.,C are triggered. We allow the environment Z (over the simulator Sim in the ideal world and
over A in the real world) to freely remove money from the accounts of corrupted parties. This corresponds to the fact that we are not interested in preventing corrupt parties from acting irrationally and losing money.