BRICK: Asynchronous Payment Channels

Zeta AvarikiotiETH Zurich

Eleftherios Kokoris-KogiasEPFL

Roger WattenhoferETH Zurich

Dionysis ZindrosNKUA, IOHK

Abstract—Off-chain protocols (channels) are a promisingsolution to the scalability and privacy challenges of blockchainpayments. Current proposals, however, require synchrony as-sumptions to preserve the safety of a channel, leaking to anadversary the exact amount of time needed to control the networkfor a successful attack. In this paper, we introduce BRICK,the first payment channel that remains secure under networkasynchrony and concurrently provides correct incentives. Thecore idea is to incorporate the conflict resolution process withinthe channel by introducing a rational committee of externalparties, called Wardens. Hence, if a party wants to close a channelunilaterally, it can only get the committee’s approval for the lastvalid state. BRICK provides sub-second latency because it does notemploy heavy-weight consensus. Instead, BRICK uses consistentbroadcast to announce updates and close the channel, a light-weight abstraction that is powerful enough to preserve safetyand liveness to any rational parties. Furthermore, we considerpermissioned blockchains, where the additional property of au-ditability might be desired for regulatory purposes. We introduceBRICK+, an off-chain construction that provides auditability ontop of BRICK without conflicting with its privacy guarantees. Weformally define the properties our payment channel constructionshould fulfill, and prove that both BRICK and BRICK+ satisfythem. We also design incentives for BRICK such that honestand rational behavior aligns. Finally, we provide a referenceimplementation of the smart contracts in Solidity.

I. INTRODUCTION

The prime solution to the scalability challenge [11] oflarge-scale blockchains, are the so-called channels [14], [42],[46]. The idea is that any two parties that interact (often) witheach other can set up a joint account on the blockchain, i.e., achannel. Using this channel, the two parties can transact off-chain, sending money back and forth by just sending each othersigned messages. The two parties are relying on the blockchainas a fail-safe mechanism in case of disputes.

The security guarantees of a channel are ensured by adispute handling mechanism. If one party tries to cheat theother party, in particular by trying to close a channel on theunderlying blockchain in an invalid (outdated) state, then theattacked party has a window of time (td) to challenge the fraudattempt. Hence, a channel is secure as long as all parties ofthe channel are frequently – at least once in td time – onlineand monitoring the blockchain. This is problematic in realnetworks [37], as one party may simply execute a denial ofservice (DoS) attack on the other party. To add insult to injury,the parameter td is public; the attacking party hence knows theexact duration of the denial of service attack.

The issue is well-known in the community, and therewere solution attempts using semi-trusted third parties calledwatchtowers [3], [17], [27], [36]. The idea is that worri-some channel parties can hire watchtowers which watch theblockchain on their behalf in case they were being attacked.

So instead of DoSing a single machine of the channel partner,the attacker might need to DoS the channel partner as wellas its watchtower(s). This certainly needs more effort as theadversary must detect a watchtower reacting and then block thedispute from appearing on-chain. However, if large amounts ofmoney are in a channel, it will easily be worth the investment.

While DoS attacks are also possible in blockchains such asthe Bitcoin blockchain, DoS attacks on channels have a sub-stantially different threat level. A DoS attack on a blockchain ismerely a liveness attack: One may prevent a transaction fromentering the blockchain at the time of the attack. However,the parties involved with the transaction will notice this, andcan simply re-issue their transaction later. A DoS attack ona channel, on the other hand, will steal all the funds thatwere in the channel. Once the fraudulent transaction is in theblockchain, uncontested for td time, the attack succeeds, andnobody but the cheated party (and its watchtowers) will knowany better.

Channels need a more fundamental solution. Not unlikeblockchains, introducing timing parameters may be okay forliveness. Security on the other hand should be guaranteed evenif the network behaves completely asynchronously.

To address these issues we introduce BRICK, a novelincentive-compatible payment channel construction that doesnot rely on any timing assumption for the delivery of messagesto be secure. BRICK provides proactive security, detectingand preventing fraud before it appears on-chain. As a result,BRICK can guarantee the security of channels even undercensorship1 [37] or any liveness2 attack (see Appendix A).

To achieve these properties, BRICK needs to address threekey challenges. The first challenge is how to achieve thisproactive check without using a single trusted third party thatapproves every transaction. The core idea of BRICK is toprovide proactive security to the channel instead of reactivedispute resolution. To this end, BRICK employs a group ofWardens. If there is a dispute, the Wardens make sure thecorrect state is the only one available for submission on-chain,regardless of the amount of time it takes to make this final statevisible.

The second challenge for BRICK is cost. To simulatethis trusted third party, it would need the Wardens to runcostly asynchronous consensus [33] for every update. Instead,in BRICK we show that a light-weight consistent broadcastprotocol is enough to preserve both safety and liveness.

1This censoring ability is encompassed by the chain-quality property [22]of blockchain systems which is rightly bound to the synchrony of the network.

2Liveness states that a transaction will be eventually included on-chain aslong as it is provided to all honest parties for a long enough time period [22].

arX

iv:1

905.

1136

0v4

[cs

.DC

] 1

9 Ju

n 20

20

A final challenge of BRICK that we address are incentives.While the Wardens may be partially Byzantine, we additionallywant honest behavior to be their dominant strategy. Unfortu-nately, existing watchtower solutions do not align the expectedand rational behavior of the watchtower, hence a watchtoweris reduced to a trusted third party. Specifically, Monitors [17],Watchtowers [27], and DCWC [3] pay the watchtower uponfraud. Given that the use of a watchtower is public knowledge,any rational channel party will not commit fraud and hence thewatchtower will never be paid. Therefore, there is no actualincentive for a third party to offer a watchtower service. Onthe other hand, Pisa [36] pays the watchtower regularly everytime a transaction is executed on the channel. The watchtoweralso locks collateral on the blockchain in case it misbehaves.However, Pisa’s collateral is not linked to the channel or theparty that employed the watchtower. Hence, a watchtower thatis contracted by more than one channel can double-assign thecollateral, making Pisa vulnerable to bribing attacks. Evenif the incentives of Pisa get fixed, punishing a misbehavingwatchtower in Pisa is still a synchronous protocol (though fora longer period). In BRICK, we employ both rewards and pun-ishment to design the appropriate incentives such that honestand rational behavior of Wardens align, while no synchronyassumptions are required, i.e., the punishment of misbehavingWardens is not conditional on timing assumptions.

We also present BRICK+, a channel construction suitablefor regulated environments such as supporting a fiat cur-rency [49]. BRICK+ needs to additionally provide auditabilityof transactions without forfeiting privacy [25] and while pre-serving the accountability of the auditor. To resolve this wechange BRICK in two ways. First, the state updates are nolonger just private but also interconnected in a tamper-evidenthash-chain. Essentially, the Wardens maintain a single hash(constant-size storage cost) which is the head of the hash-chainof the state history. Second, to provide accountability for theauditor, we require that the auditor posts the access requeston-chain [30]. Only then will the Wardens provide the auditorthe necessary metadata to verify the state history received fromthe parties of the channel.

To evaluate our channel construction we deploy our pro-tocol on a large-scale testbed and show that the overhead ofan update is around the round-trip latency of the network (inour case 0.1 seconds). Unlike existing channels, the partiesin BRICK need not wait for the dispute transaction to appearon-chain. Hence, our dispute resolution mechanism is threeorders of magnitude faster than existing blockchain systemsthat need to wait until the transaction is finalized on-chain. Weadditionally implement the on-chain operations of BRICK in aSolidity smart contract that can be deployed on the Ethereumblockchain. We provide gas measurements for typical oper-ations on the smart contract illustrating that it is practical.Our smart contract implementation is well tested and can beadopted towards a real deployment of BRICK.

In summary, this paper makes the following contributions:

• We introduce BRICK, the first incentive-compatible off-chain construction that operates securely with offlinechannel participants under full asynchrony with sub-second latency.

• We introduce BRICK+, a modified BRICK channel con-struction, that enables external auditors to lawfully requestaccess to the channels history while maintaining privacy.

• We define the desired channel properties and show theyhold for BRICK under a hybrid model of rational andbyzantine participants (channel parties and Wardens).Specifically, we present elaborate incentive mechanisms(rewards and punishments) for the Wardens to maintainthe channel properties under collusion or bribing.

• We evaluate the practicality of BRICK by fully imple-menting its on-chain functionality in Solidity for theEthereum blockchain. We measure its operational costs interms of gas and illustrate that its deployment is practical.

II. BACKGROUND AND PRELIMINARIES

In this section, we provide the necessary introduction topayment channels. Furthermore, we introduce the necessarydistributed abstractions that our constructions build upon.

A. Blockchain Scalability & Layer 2

One of the major problems of blockchain protocols isthe limited transaction throughput that is associated withthe underlying consensus mechanism, originally introducedin Bitcoin [40]. Nakamoto consensus demands that everyparticipant of the system verifies and stores a replica of theentire history of transactions, i.e., the blockchain, to guaranteethe safety and liveness of the transaction ledger. However, thisrequirement leads to blockchain systems with limited blocksize and block creation time. If we increase size or decreasetime, we implicitly enforce participants to verify and storemore data, which in turn leads to centralization and additionaladvantages for participants that invest in more infrastructure.Thus, blockchain systems that use the Nakamoto or similarconsensus mechanisms face a scalability problem. Notably,Bitcoin handles at most seven transactions per second [11],while current digital monetary systems, such as Visa, handletens of thousands.

Proposed solutions for the throughput limitation ofblockchain systems can be categorized in two groups. On-chain solutions that attempt to create faster blockchain pro-tocols [13], [31], [32], and off-chain solutions that use theblockchain only as a fail-safe mechanism and move thetransaction load offline, where the bottleneck is the networkspeed. While on-chain solutions lead to the design of newpromising blockchain systems, they typically require strongertrust assumptions and they are not applicable to existingblockchain systems (without a hard fork). In contrast, off-chain (layer 2) solutions are built on top of the consensuslayer of the blockchain and operate independently. Essentially,off-chain solutions allow two parties3 to create a “channel”on the blockchain through which they can transact fast andsecure; this solution is known as payment channel [14], [46].

Payment channels allow transactions between two parties tobe executed instantly off-chain while maintaining the guaran-tees of the blockchain. Essentially, the underlying blockchainacts as a “judge” in case of fraud. There are multiple proposalson how to construct payment channels [12], [14], [42], [46],but all proposals share the same core idea: The two parties

3Note that a channel can also be created between multiple parties [8].

2

create a joint account on the blockchain (funding transaction).Every time the parties want to make a transaction they updatethe distribution of the capital between them accordingly andthey both sign the new transaction as if it would be publishedon the blockchain (update transaction)4. To close the channel, aparty publishes the latest update transaction either unilaterallyor along with the counter-party with a closing transaction.

The various proposals differ in the way they handle dis-putes, i.e., the case where one of the parties misbehaves andattempts to close the channel with a transaction that is not thelatest update transaction, thus violating the safety property.Lightning channels [42] penalize the misbehaving party byassigning the money of the channel to the counter-party incase of fraud. To achieve this, every time an update transactionis signed each party releases a secret to the counterparty.That secret enables the counterparty to claim the money ofthe channel in case the party publishes the previous updatetransaction (breach remedy). However, this transaction is validonly for a window of time since the party should, in caseof no fraud, eventually be able to spend its money fromthe channel. This dispute period is enforced with a (relative)timelock. On the other hand, Duplex channels [14] guaranteethat the latest update transaction will become valid before anyprevious update transaction, again utilizing timelocks. In bothcases, the liveness of the underlying blockchain and timelocksare crucial to the safety of the payment channel solution.Additionally, both solutions require online participants thatfrequently monitor the blockchain to ensure safety.

B. Consistent Broadcast

Consistent broadcast [44] is a distributed protocol run by anode that wants to send a message to a set of peers reliably. Itis called consistent because it guarantees that if a correct peerdelivers a message m with sequence number s and anothercorrect peer delivers message m′ with sequence number s,then m = m′. Thus, the sender cannot equivocate. In otherwords, the protocol maintains consistency among the deliveredmessages with the same sender and sequence numbers butmakes no provisions that any parties do deliver the messages.In our system we only care about the consistency of sequencenumbers, as any party of the channel can be the sender of amessage m even after m is correctly broadcast. We allow thisin order to remove the need for parties to share the proof thatthe transaction is committed, as there is no incentive to do so.

III. PROTOCOL OVERVIEW

In this section, we present the system and threat modelwe consider, a high-level overview of BRICK and BRICK+together with the goals we want to achieve.

A. System Model

We make the usual cryptographic assumptions: the par-ticipants are computationally bounded and cryptographically-secure communication channels, hash functions, signatures,and encryption schemes exist. We assume the underlyingblockchain maintains a distributed ledger that has the prop-erties of persistence and liveness as defined in [22]. We also

4By definition, a channel requires the participation and signature of everyparty of the channel to update the channel’s state in order to maintain security.

assume that any message sent by an honest party will bedelivered to any other honest party within a polynomial numberof rounds. We do not make any additional assumptions (e.g.,known bounds for message delivery). Furthermore, we donot require a “perfect” blockchain system since BRICK cantolerate temporary liveness attacks. Specifically, if an adversarytemporarily violates the liveness property of the underlyingblockchain, this may result in violating the liveness propertyof channels but will not affect the safety.

B. Threat Model

We initially assume that at least one party in the channelis honest to simplify the security analysis. However, later,we show that the security analysis holds as long as the“richest” party of the channel is rational and intentionallydeviates from the protocol if it can increase its profit (utilityfunction). Regarding the committee, we assume that there areat most f out of n = 3f + 1 Byzantine Wardens and wedefine a threshold t = 2f + 1 to achieve the liveness andsafety properties. The non-byzantine part of the committee isassumed rational; we first prove the protocol goals for t honestWardens, and subsequently align the rational behavior to thisthrough incentives.

C. BRICK Overview

Both parties of a channel agree on a committee of Wardensbefore opening the channel. The Wardens commit their iden-tities on the blockchain during the funding transaction of thechannel (opening of the channel). After opening the channelon the blockchain, the channel can only be closed either bya transaction published on the blockchain and signed by bothparties or by a transaction signed by one of the parties and athreshold (t) of honest Wardens. Thus, the committee acts aspower of attorney for the parties of the channel. Furthermore,BRICK employs correct incentives for the t rational Wardensto follow the protocol, hence it can withstand t = 2f + 1rational and f Byzantine Wardens, while the richest channelparty is assumed rational and the other byzantine.

A naive solution would then instruct the committee to runasynchronous consensus on every new update, which wouldcost O(n4) [33] per transaction, a rather big overhead forthe critical path of our protocol5. Instead in Brick, consensusis not necessary for update transactions, as we only provideguarantees to rational parties (if both parties misbehave one ofthem might lose its funds). As a result, every time a new updatestate occurs in the channel (i.e., a transaction), the parties run aconsistent broadcast protocol (cost of O(n)) with the commit-tee. Specifically, a party announces to each Warden that a stateupdate has occurred. This announcement is a monotonicallyincreasing sequence number to guarantee that the new stateis the freshest state, signed by both parties of the channel tosignal that they are in agreement. If the consistent broadcastprotocol succeeds (t Wardens acknowledge reception) then thiscan serve as proof for both parties that the state update is safe.After this procedure terminates correctly, both parties proceedto the execution of the off-chain state.

5For this step, we would require a fully asynchronous consensus protocolwithout a trusted setup. To the best of our knowledge, [33] has the lowestcommunication complexity of O(n4).

3

At the end of the life-cycle of a channel, a dispute mightoccur, leading to the unilateral closing of the channel. Evenin this case, we can still guarantee the security and livenessof the closing with consistent broadcast. The crux of the ideais that if 2f + 1 Wardens accepted the last sequence numberbefore receiving the closing request (hence the counterpartyhas committed), then at least one honest Warden will notaccept the closing at the old sequence number. Instead, theWarden will reply to the party that it can only close at thestate represented by the last sequence number. As a resultwe define a successful closing to be at the maximum of allproposed states, which guarantees safety. Although counter-intuitive, this closing process is safe because the transactionsare already totally ordered and agreed to by the parties of thechannel; thus, the committee simply acts as shared memoryof the last sequence number.

D. BRICK+ Overview

BRICK+ is designed to enable payment channels in a per-missioned, regulated setting, for example, a centrally-bankedcryptocurrency. In such a setting, there will be an auditor(e.g., the IRS) that can check all the transactions inside achannel as these transactions might be taxable or illegal. Thisis a realistic case as the scalability in payment channels comesfrom a persistent relationship that models well B2B and B2Crelationships that are usually taxed. In this setting, we assumethat the auditor can punish the parties and the committee exter-nally of the system, hence our goal is to enhance transparencyeven if misbehavior is detected retroactively.

In order to convert BRICK into BRICK+ we must ensurethat (a) nothing happens without the committee’s approval and(b) a sufficient audit trail is left on-chain to stop regulatorsfrom misbehaving. We resolve the first issue by disabling theparties’ ability to close the channel without the participation ofthe committee. For the second challenge, the parties generatea hashchain of (blinded) states and sequence numbers andWardens always remember the head of the hashchain togetherwith the last sequence number. To prevent the auditor frommisbehaving, we force the auditor to post a “lawful accessrequest” [21] on-chain to convince the channel parties toinitiate the closing of the channel for audit purposes and sendthe state history to the auditor.

E. Reward Allocation & Collateral

To avoid bribing attacks, we enforce the Wardens to lockcollateral in the channel. The total amount of collateral isproportional to the value of the channel meaning that if thecommittee size is large, then the collateral per Warden issmall. More details on the necessary amount of collateral arethoroughly discussed in Sections IV and VIII. Additionally,the committee is incentivized to actively participate in thechannel with a small reward that each Warden gets when theyacknowledge a state update of the channel. This reward isgiven with a unidirectional channel [25], which does not sufferfrom the problems BRICK solves. Moreover, the Wardens thatparticipate in the closing state of the channel get an additionalreward, hence the Wardens are incentivized to assist a partywhen closing in collaboration with the committee is necessary.

F. Protocol Goals

To define the goals of BRICK, we first need to define thenecessary properties of a channel construction. Intuitively, achannel should ensure similar properties with a blockchainsystem, i.e., a party cannot cheat another party out of itsfunds, and any party has the prerogative to eventually spend itsfunds at any point in time. The first property, when applied tochannels, means that no party can cheat the channel funds ofthe counterparty, and is encapsulated by Safety. The secondproperty for a channel solution is captured by Liveness; ittranslates to any party having the prerogative to eventuallyclose the channel at any point in time. We say that a channelis closed when the locked funds of the channel are spent on-chain, while a channel update refers to the off-chain changeof the channel’s state.

In addition, we define Privacy which is not guaranteed inmany popular blockchains, such as Bitcoin [40] or Ethereum[48], but constitutes an important practical concern for anyfunctional monetary (cryptocurrency) system. Furthermore, wedefine another optional property, Auditability, which allowsauthorized external parties to audit the states of the channel,thus making the channel construction suitable for use ona regulated currency. The first three properties are met byBRICK, while the latter is only available in BRICK+.

First, we define some characterizations on the state of thechannel, namely, validity and commitment. Later, we definethe properties for the channel construction. Each state of thechannel has a discrete sequence number that reflects the orderof the state. We assume the initial state of the channel hassequence number 1 and every new state has a sequence numberone higher than the previous state agreed by both parties. Wedenote by si the state with sequence number i.

Definition 1. A state of the channel, si, is valid if the followinghold:

• Both parties of the channel have signed the state si.

• The state si is the freshest state, i.e., no subsequent statesi+1 is valid.

• The committee has not invalidated the state. The commit-tee can invalidate the state si if the channel closes in thestate si−1.

Definition 2. A state of the channel is committed if it wassigned by at least 2f + 1 Wardens or is valid and part of ablock in the persistent6 part of the blockchain.

Definition 3 (Safety). A BRICK channel will only close in thefreshest committed state.

Definition 4 (Liveness). Any valid operation (update, close)on the state of the channel will eventually7 be committed (orinvalidated).

Definition 5 (Privacy). No unauthorized 8 external (to thechannel) party learns about the state of the channel (e.g., thecurrent distribution of funds between the parties of a payment

6The part of the chain where the probability of fork is negligible hencethere is transaction finality, e.g., 6 blocks in Bitcoin.

7Depending on the message delivery.8Authorized parties are potential auditors of the channel, as described in

BRICK+.

4

Protocol 1: OpenInput: Channel parties A,B, Wardens W1,W2, . . . ,Wn,

initial state s1, closing fee F .Goal: Open a BRICK payment channel.

1. Both parties A,B sign:open(H(W1), H(W2), . . . ,H(Wn), t, s1, F ).

2. Register to {M,σ(M)} the announcement ofProtocol Update(A,B, s1).

3. Execute Protocol ConsistentBroadcast(M,σ(M), A,B,W1,W2, . . . ,Wn).

4. Publish to the blockchainσ(open(H(W1), H(W2), . . . ,H(Wn), t, F )).

channel) unless at least one of the parties initiate the closingof the channel.

Definition 6 (Auditability). All committed states of the chan-nel are verifiable by an authorized third party.

IV. BRICK DESIGN

In this section, we first present the BRICK architecture, andlater the additional incentive mechanisms.

BRICK consists of three phases: Open, Update, and Close.We assume the existence of a smart contract (self-executedcode run on a blockchain). The BRICK smart contract hastwo functions, Open and Close, that receive the inputs of theprotocols and verify that they adhere to the abstractly definedprotocols specified below.

Algorithm 1 describes the first phase, Open, which is theopening of a channel between two parties. In this phase,the parties create the initial funding transaction, similarly toother known payment channels such as [14], [42]. However,in BRICK we also define three additional parameters duringthis phase; we include in the funding transaction the hashesof the public keys of the Wardens of the channel, denotedby W1,W2, . . . ,Wn, the threshold t, and a closing fee F .This fee will be awarded to the responsive Wardens in thelast phase, Close, if and only if the closing of the channelis done in collaboration with the committee. In this case, thefirst t Wardens that assisted in closing the channel will berewarded with the amount F/t. In addition, each Warden locksa collateral in the BRICK smart contract which will be claimedby the parties of the channel during phase Close if a Wardenmisbehaves (e.g., receives a bribe).

The second phase of the protocol consists of twosub-protocols, Update (Protocol 2) and ConsistentBroadcast (Protocol 3). Both algorithms are executed con-secutively every time an update occurs, i.e., when the state ofthe channel changes. During Update, the parties of the chan-nel agree on a new state and create an announcement, whichthey to the committee using Consistent Broadcast. Toagree on a new state, both parties sign the hash of the newstate9. This way both parties commit to the new state of thechannel, while none of the parties can unilaterally close thechannel without the collaboration of either the counterparty

9Blinding the commitment to the state is not necessary for BRICK, but wedo it for compatibility with BRICK+.

Protocol 2: UpdateInput: Channel parties A,B, current state s.Goal: Create announcement M,σ(M) (sequence

number of new state signed by both parties).

1. Both parties A,B sign and exchange: {H(si, ri), i},where ri is a random number and si the current state.

2. After receiving the signature of the counterparty on{H(si, ri), i}, each party sends to the counterparty itssignature on the sequence number σ(i) thus creatingthe announcement {M,σ(M)}(M = i).

Protocol 3: Consistent BroadcastInput: Channel parties A,B, Wardens W1,W2, . . . ,Wn,announcement {M,σ(M)}.

Goal: Inform the committee of the new update stateand verify the validity of the new state.

1. Each party broadcasts to all the WardensW1,W2, . . . ,Wn the announcement {M,σ(M)}alongside a fee r.

2. Each Warden Wj , upon receiving {M,σ(M)},verifies that both parties’ signatures are present, andthe sequence number is exactly one higher than thepreviously stored sequence number. If the Warden haspublished a closing state, it ignores the state update.Otherwise, Wj stores the announcement {M,σ(M)}(replacing the previous announcement), signs M , andsends the signature σWj

(M) to the parties that payedthe update fee r.

3. Each party, upon receiving at least t signatures onthe announcement M , considers the state committedand proceeds to the state transition.

or the committee. The announcement, on the other hand,is the new sequence number signed by both parties of thechannel10. The signed sequence number allows the Wardensto verify agreement has been reached between the channelparties on the new state, while the state of the channel remainsprivate. Furthermore, if a party wants to close the channelunilaterally, the Wardens can provide a signature on the storedannouncement σWi

(M, close). Consequently, the BRICK smartcontract, given the signed hash of the freshest state by a party,can verify that the state corresponds to the maximum sequencenumber submitted by the Wardens and the presence of theappropriate signatures, and then close the channel in the correctstate.

In Protocol 3, for every state update, each party sends to allWardens the announcement including a small update fee forwatching the channel. Then, each Warden replies to every partythat sent the announcement by signing the announcement. TheWarden’s signature can be used later to penalize the Warden(a party can claim the Warden’s collateral) in case the Wardencolludes with a party and signs a previous state to close thechannel.

10We abuse the notation of signature σ to refer to the multisig of both Aand B.

5

Fig. 1: Typical workflow of BRICK for a state update. (1) Alice and Bob agree on a new state update. (2) They individually broadcast that they reached agreement on a new stateto the committee (with an associated fee). (3) When a threshold of the committee replies that the state is committed, each sender (Alice or Bob) executes this update as persistent.

Protocol 4: Optimistic Close

Input: Channel parties A,B, state s.Goal: Close a channel on state s, assuming both parties

are responsive and in agreement.

1. A party p ∈ {A,B} broadcasts the request close(s).2. Both parties A,B sign the state s (if they agree) and

exchange their signatures.3. The party p (or any other channel party) publishes

the signed by both parties state, σA,B(s) on-chain.

The last phase of the protocol, Close, can be implementedin two different ways: the first is similar to the traditionalapproach for closing a channel (Protocol 4: OptimisticClose) where both parties collectively sign the freshest state(closing transaction) and publish it on-chain. However, in casea channel party is not responding to new state updates orclosing requests, the counterparty can unilaterally close thechannel in collaboration with the committee of the channel.In Protocol 5: Pessimistic Close, a party initiates thelast phase of the protocol by requesting from each Warden itssignature on the last committed sequence number. A Warden,upon receiving the closing request, publishes on-chain a clos-ing announcement, i.e., the stored sequence number signedalong with a flag close. When t closing announcements areon the persistent part of the chain, the party recovers thestate that corresponds to the maximum sequence number fromthe closing announcements si. Then, the party publishes statesi and the random number ri along with the signatures ofboth parties on the corresponding hash and sequence numberσ(H(si, ri), i) on-chain. As soon as these data are included ina (permanent), the BRICK smart contract verifies and closes thechannel. In particular, the smart contract (a) recovers from thesubmitted state and salt the hash H(si, ri) and the maximumsequence number i, (b) verifies that the signatures of bothparties are on the message {H(si, ri), i}, and (c) there are tsubmitted announcements that correspond to Warden identitiescommitted on-chain in Protocol 1. If all verifications check thesmart contract closes the channel in the submitted state andrewards F/t to the first t participating Wardens.

Incentivizing Honest Behavior

BRICK actually works without the fees, if we assumeone honest party and t honest Wardens. However, our goalis to have no honest assumptions and instead align rational

Protocol 5: Pessimistic CloseInput: Party p ∈ {A,B}, Wardens W1,W2, . . . ,Wn,state si, random number ri.

Goal: Close a channel on state si with the assist of thecommittee.

1. Party p broadcasts to the Wardens W1,W2, . . . ,Wn

the request close().2. Each Warden Wj publishes on-chain a signature onthe (last) stored announcement σWj (M, close) andstops signing new state updates.

3. Party p, upon verifying t on-chain signedannouncements by the Wardens, recovers the max(i)that is included in the announcements. Then, party ppublishes on-chain the state si, the random numberr − i and the signature of both parties on{H(si, ri), i}

4. After the state is included in a (permanent) block, thesmart contract recovers {H(si, ri), i}, verifies bothparties’ signatures and the Wardens identities, and thencloses the channel in state si. The first t Wardenswhose signature are published on-chain get an equalfraction of the closing fee F/t.

behavior to honest through incentives. There are three incentivemechanisms in BRICK:

1) Update Fee (r). The parties establish a one-way chan-nel [25] with each Warden where they send a smallpayment every time they want a signature for a stateupdate. Note that the update fee is awarded to the Wardensat step 1 of Protocol 3.

2) Closing Fee (F ). During phase Open (Protocol 1), theparties lock a closing fee F in the channel, which is splitonly among the first t Wardens that participate in Protocol5. If the channel closes optimistically (Protocol 4), theclosing fee returns to the parties.

3) Warden Collateral. During phase Open, each Wardenlocks collateral at least equal to the amount locked in thechannel v divided by f . The collateral is either returnedto the Warden at the closing of the channel or claimed bya channel party that provides a proof-of-fraud. A proof-of-fraud consists of two conflicting messages signed bythe same Warden: (a) a signature on an announcementon a state update of the channel, and (b) a signature onan announcement for closing on a previous state of thechannel.

6

In case, a party submits the closing announcements and atmost f proofs-of-fraud, to close the channel we execute asecond closing process excluding the Wardens that com-mitted fraud. Then, the channel closes in the state withthe maximum sequence number of the announcementssubmitted by a total of t non-excluded Wardens. On theother hand, if a party submits the closing announcementsand at least f+1 proofs-of-fraud, the party that submittedthe proofs-of-fraud claims only the collateral and theentire channel balance is awarded to the counterparty.Lastly, if no proofs-of-fraud are submitted the channelcloses as described in Protocol 5.

We further demand that the size of the committee is atleast n > 7, hence f > 2. As a result, we guarantee thereis at least one channel party with locked funds greater thaneach individual Warden’s collateral, v

2 > vf . This restriction

along with the aforementioned incentive mechanisms ensureresistance to collusion and bribing of the committee, meaningthat following the protocol is the dominant strategy for therational Wardens.

V. BRICK ANALYSIS

We first prove BRICK satisfies Safety and Liveness assum-ing at least one honest channel party and at least t honestWardens. Furthermore, we note that BRICK achieves Privacyeven if all Wardens are byzantine while the channel partiesare rational. Then, we show that rational Wardens that want tomaximize their profit will follow the protocol specification, forthe incentive mechanisms presented in Section IV. Essentially,we show that BRICK enriched with the proposed incentivemechanisms is dominant-strategy incentive-compatible. Wecomplete our analysis by showing that BRICK security holdsas long as the richest channel party is rational in Appendix B.

A. Security Analysis under one Honest Participant and tHonest Wardens

Theorem 1. BRICK achieves safety under asynchrony assum-ing one byzantine party and f byzantine Wardens.

Proof: In BRICK there are two ways to close a channel(phase Close), either by invoking Protocol 4 or by invokingProtocol 5. In the first case (Optimistic Close), bothparties agree on closing the channel in a specific state (whichis always the freshest valid state 11). As long as this valid stateis published in a block in the persistent part of the blockchain,it is considered to be committed. Thus, safety is guaranteed.

In the second case, when Protocol 5: PessimisticClose is invoked, a party has decided to close the channelunilaterally in collaboration with the committee. The BRICKsmart contract verifies that the state is valid, i.e., the signaturesof both parties are present and the sequence number of thatstate is the maximum from the submitted announcements.Given the validity of the closing state, it is enough to show thatthe channel cannot close in a state with a sequence numbersmaller than the one in the freshest committed state. Thisholds because even if the channel closes in a valid but not yet

11We assume that if the parties want to close the channel in a previousstate, they will still create a new state similar to the previous one but with anupdated sequence number.

committed state with sequence number larger than the freshestcommitted state, this state will eventually become the freshestcommitted state (similarly to Protocol 4).

Let us denote by si the closing state of the channel.Suppose that there is a committed state sk such that k > i,thus si is not the freshest state agreed by both parties. Wewill prove safety by contradiction. For the channel to closeat si at least t = 2f + 1 Wardens have provided a signedclosing announcement, and the maximum sequence number ofthese announcements is i. Otherwise the BRICK smart contractwould not have accepted the closing state as valid. Accordingto the threat model, at most n− t = f Wardens are Byzantine,thus at least f + 1 honest Wardens have submitted a closingannouncement. Hence, none of the f + 1 honest Wardenshave received and signed the announcement of any state withsequence number greater than i. However, in phase Update& Consistent Broadcast, an update state is considered to becommitted, according to Protocol 3 (line 3), if and only if ithas been signed by at least t = 2f +1 Wardens. Since at mostn−(f+1) = 3f+1−f−1 = 2f < 2f+1 Wardens have seen(and hence signed) the state sk, the state sk is not committed.Contradiction.

We note that safety is guaranteed even if both partiescrash. This holds because a state update requires unanimousagreement between the parties of the channel, i.e., both partiessign the hash of the new state.

Theorem 2. BRICK achieves liveness under asynchrony as-suming one byzantine party and f byzantine Wardens.

Proof: We will show that every possible valid operationis either committed or invalidated. There are two distinctoperations: close and update. We say that operation closeapplies in a state s if this state was published on-chain eitherin collaboration of both parties (Protocol 4) or unilaterally bya channel party as the closing state (Protocol 5, step 3).

If the operation is close and not committed, either the par-ties did not agree on this operation (Optimistic Close),or a verification of the smart contract failed (PessimisticClose). In both cases, the operation is not valid.

Suppose now the operation is close and never invalidated.Then, if it is an optimistic close, all the parties of the channelhave signed the closing state since it is valid. Since at leastone party is honest the transaction will be broadcast to theblockchain. Assuming the blockchain has liveness, the statewill be eventually included in a block in the persistent part ofthe blockchain and thus will be eventually committed. On theother hand, if it is a pessimistic close and not invalidated, thesmart contact verifications were successful therefore the statewas committed.

Suppose the operation is a valid update and it was nevercommitted. Since the operation is valid and at least one partyof the channel is honest, the Wardens eventually received thestate update (Consistent Broadcast). However, the newstate was never committed, therefore at least f + 1 Wardensdid not sign the update state. We assumed at most f ByzantineWardens, hence at least one honest Warden did not sign thevalid update state. According to Protocol 3 (line 2), an honestWarden does specific verifications and if the verifications holdthe Warden signs the new state. Thus, for the honest Warden

7

that did not sign, one of the verifications failed. If the firstverification fails, then a signature from the parties of thechannel is missing thus the state is not valid. Contradiction.The second verification concerns the sequence number andcannot fail, assuming at least one honest channel party. Thus,the Warden has published previously a closing announcementon-chain and ignores the state update. In this case, either (a) theclosing state of the channel is the new state - submitted byanother Warden that received the update before the closingrequest - or (b) the closing state had a smaller sequence numberfrom the new state. In the first case (a), the new state iscommitted eventually (on-chain), while in the second case (b)the new state is invalidated as the channel closed in a previousstate.

For the last case, suppose the operation is a valid updateand it was never invalidated. We will show the state update waseventually committed. Suppose the negation of the argumenttowards contradiction. We want to prove that an update statethat is not committed is either not valid or invalidated. Thereasoning of the proof is similar to the previous case.

Lastly, BRICK achieves privacy even against byzantineWardens since they only receive the sequence number of eachstate update in a channel. Therefore, as long as parties donot intentionally reveal any information to anyone external,privacy is maintained. We note, however, that in a network withmultiple channels each channel needs to maintain a unique idwhich will be included in the announcement to avoid replayattacks.

B. Incentivizing Rational Wardens

In this section, we show that rational watchtowers thatwant to maximize their profit follow the protocol, i.e., thatdeviating from the honest protocol execution can only resultin decreasing a Warden’s expected payoff. We consider eachphase of BRICK separately, and evaluate the Warden’s payofffor each possible action.

Open: During the opening of the channel, we assume theWardens follow Protocol 1 and commit the requested collateralon-chain (BRICK smart contract). Otherwise, the parties simplyreplace the unresponsive/misbehaving Wardens.

Update: In Protocol 2 the Wardens do not participate.Thereby, the only action by the Wardens is step 2 of Protocol 3.A Warden can deviate as follows:

• The Warden can simply ignore the party’s request toupdate the state (does not reply to the party), since theupdate fee is already collected. At first sight, this gamelooks like a fair exchange game, which is impossible tosolve without a trusted third party [18]. Furthermore, wecannot use a blockchain to solve it [41] as the whole pointof state channels is to reduce the number of transactionsthat go on-chain. Fortunately, the state update game isa repeated game where Wardens want to increase theirexpected rewards in the long term. Thereby, they knowthat if they receive an update fee from a party and do notrespond, then the party will stop using them (there is ffault tolerance in BRICK), thus their expected payoff forthe repeated game will decrease.

• The Warden sends its signature on the new state butdoes not store the new announcement. In this case, if

a party requests to close unilaterally the Warden cannotparticipate and thence collect the closing fee. Therefore,the Warden’s expected payoff decreases.

• The Warden replies to the party although it has publisheda closing announcement on-chain. Then, the party canpenalize the Warden by claiming its collateral.

• The Warden does not perform the necessary verifications.Then, the Warden might unintentionally commit fraud bysigning an invalid state, hence allow the party to claimthe collateral.

Close: Wardens do not participate in the optimistic close(Protocol 4). As a result, we only evaluate the possible actionsa Warden can deviate from the honest execution of Protocol 5.

• The Warden does not publish a closing announcement on-chain. In this case, the Warden can attempt to enforce ahostage situation on the funds of the channel in collabora-tion with other Wardens in order to blackmail the channelparties. However, to enforce a hostage situation on thechannel’s funds, at least f + 1 Wardens must collude,hence at least one rational Warden must participate.However, a rational Warden cannot be certain that theother Wardens will indeed maintain the hostage situationor participate in the consensus thus claim the closing fee(only the first t Wardens get paid); therefore, we reduceour problem to the prisoner’s dilemma problem. As aresult, the only strong Nash equilibrium for a rationalWarden is to immediately publish a closing announcementon-chain in order to claim later the closing fee.

• The Warden signs later a new state update. Then, theWarden allows the party receiving the signed announce-ment with higher sequence number than the closingannouncement to create a proof-of-fraud and claim theWarden’s collateral.

• The Warden publishes on-chain a closing announcementthat is not the stored one12. However, the Warden hasalready sent a signature on an announcement with a highersequence number, therefore the party can create a proof-of-fraud and claim the Warden’s collateral. Hence, anyrational Warden will request as a bribe an amount at leastmarginally higher than the collateral to perform the fraud.We will show that no rational party will provide such abribe to any rational Warden. Thus, all rational Wardenswill honestly follow the protocol and submit the storedannouncement for closing the channel.To that end, let us denote by pA the payoff function ofparty A (the cheating party wlog). The payoff function de-pends on the channel balance of party A when requestingto close the channel, denoted by cA (0 ≥ cA ≥ v, where vis the total channel funds), the collateral the party claimsthrough proofs-of-fraud, and the total amount spent forbribing rational Wardens. Formally,

pA = cA + xv

f− b

( vf+ ε

)where x is the number of proofs-of-fraud submitted bythe party, b the number of bribed rational Wardens, and εthe marginal gain over the collateral the Wardens require

12We assume the Warden will only sign as closing an announcement thatused to be valid in an attempt to commit fraud. Otherwise, the party will claimthe Warden’s when the smart contract verifications fail.

8

to be bribed. Note that each Warden has locked vf as

collateral. Further, note that the Byzantine Wardens donot require a bribe but act arbitrarily malicious, meaningthat they will provide a proof-of-fraud to party A withoutany compensation.Next, we analyze all potential strategies for party A anddemonstrate that the payoff function maximizes when theparty does not bribe any rational Warden, but closes thechannel in the freshest committed state. There are fourdifferent outcomes in the strategy space of party A:1) The channel closes using Protocol 5. Then, pA = cA.2) Party A submits the proofs-of-fraud only from the

Byzantine Wardens and the channel closes in thefreshest committed state (by the remaining t rationalWarden). Then, pA = cA+f v

f = cA+v. Note that thepayoff function in this case maximizes for x = f .

3) Party A bribes b > 0 rational Wardens and the channelcloses in the freshest committed state. Then, pA ≤ cA+(f + b) vf − b(

vf + ε) = cA + v− bε ≤ cA + v− ε. The

first inequality holds because the bribed Wardens mightbe part of the second set of t closing announcements,in which case they do not contribute to the claimedcollateral.

4) Party A bribes b > 0 rational Wardens and the channelcloses in a state other than the freshest committed state.Let us denote by y the number of rational Wardens thatprovide a proof-of-fraud to the party, and m the numberof submitted proofs-of-fraud that belong to ByzantineWardens. Then, the possible actions in this strategy aredepicted in Table I. Note that at least f+1 misbehaving

TABLE I: Potential actions to close the channel in a “fraudu-lent” state.

Action Proof-of-fraud Close Total

Byzantine m f −m f

Bribed y f + 1− (f −m) y + m + 1(rational) = m + 1

Total m + y f + 1 -

Wardens are required to close the state in a previousstate since we assume there can be f slow rationalWardens that have not yet received the update states.In this case, the payoff function is

pA ≤ v +(m+ y

) vf−(y +m+ 1

)( vf+ ε

)= v − v

f− ε

(y +m+ 1

)≤ v − v

f− ε

where the first inequality holds since 0 ≥ cA ≥ v.Therefore, the payoff function maximizes in case the partyfollows the second strategy, i.e., when the channel closesin the freshest committed state and no rational Wardensare bribed.

We notice that in any possible deviation of the protocolsthe Warden’s expected payoff decreases, thus the dominantstrategy of a rational Warden is to follow the protocols.

VI. BRICK+ DESIGN

In this section, we describe the BRICK+ system design,while the security analysis for BRICK+ can be found inAppendix C.

BRICK+ consists, similarly to BRICK, of three phases,Open, Update, and Close. However, BRICK+ has one addi-tional functionality, Audit, that allows an authorized third partyto audit the states of a channel. Invoking this functionalitythough enforces the closing of the channel. The Audit func-tionality is illustrated in Figure 3 (Appendix C) and describedin detail in Protocol 6.

To enable the Audit functionality and therefore achieveAuditability, we disable Protocol 4: Optimistic Close,and enforce the parties to close in collaboration with thecommittee. This way we guarantee that all states of the channelare available to the committee and hence to the potentialauditor for verification. Moreover, we modify Protocol 2 andProtocol 3 (phase Update) such that the Wardens store a hash-chain of the state history instead of the sequence number of thefreshest valid state they received. Thereby, we ensure that theparties cannot present an alternate state history to the auditoras it achieves fork-consistency [35].

The Audit functionality is initiated by an authorized thirdparty, the auditor, who publishes an access request on-chain.Then, the Wardens of the channel verify the validity of theaccess request and initiate the closing of the channel bypublishing the closing announcements (head of the hash-chainof the state history) on-chain (Protocol 5: PessimisticClose). After the execution of Protocol 5, the closing stateis on-chain and both the (honest) Wardens and parties of thechannel have a consistent view of the channel history. Bothparties send to the auditor the entire state history. The auditorthen verifies the state history received from both parties bycomputing the hash-chain and comparing the last hash withthe hash that corresponds to the maximum sequence numberpublished by the Wardens (i.e., the hash that corresponds tothe closing state of the channel). If the parties misbehave andsend an alternate state history the auditor can pursue externalpunishment (e.g., legal action).

VII. EVALUATION OF BRICK

In this section we evaluate both the cost of consistentbroadcast as well as the cost of BRICK’s on-chain operations.The key questions we want to answer are: (a) How does thecost of deploying BRICK change as we increase the numberof Wardens (i.e., the security and fault tolerance), and (b) howdoes the cost of the off-chain part scale now that we need tointeract with the Wardens every time in order to protect againstnetwork attacks.

a) Solidity Smart Contract: To evaluate the cost ofdeployment of BRICK on Ethereum, we have implementedthe on-chain operations in the form of a smart contract inSolidity13. We measured the gas cost of deploying andoperating the smart contract on the Ethereum blockchain.Our results are illustrated in Figure 2. Our gas measurements

13The source code of the smart contract is released under the opensource MIT license and is available anonymously at https://github.com/ndss2020-brick-submission/brick.

9

Protocol 6: AuditInput: Auditor A of channel c, audit smart contract with

access on the information published on the blockchain,from Protocol 1.

Goal: Audit of the channel.

1. The auditor A publishes on-chain the access requestfor channel c.

2. Each Warden of the channel, upon verifying thevalidity of the access request, initiates the closingphase of the channel (Protocol 5), and publishes onchain the stored announcement (head of the hash-chainof state history).

3. After the execution of Protocol 5, the channel isclosed on-chain in a committed state s. Then, bothparties of the channel send to the auditor the statehistory.

4. The auditor collects from the blockchain the hashespublished by the Wardens and selects the hash thatcorresponds to the maximum sequence number (i.e.,corresponds to the closing state s). Then, the auditor,upon receiving the state history from both parties,verifies it by re-creating the hash-chain. If a party doesnot respond to the access request or presents a differentstate history the auditor pursues external punishment.

are conducted using prices as of May 2020, namely the fiatprice of 1 ETH = 195.37 EUR and a gas price of 20 Gwei(for convenience, prices on the diagram are shown in bothEUR and Ether). The contract was implemented in Solidity0.5.16 and measurements were performed using using thesolc 0.6.8 compiler with optimizations enabled, deployed ona local ganache-cli blockchain using truffle and web3. Themeasurements concern the deployment of the smart contract,the opening of the channel, optimistically closing the channel,and pessimistically closing the channel. The contract allowsthe parties to specify the number n of Wardens they desireto involve as well as their identities. To aid with the EVMimplementation, we opted for the secp256k1 elliptic curvesignature scheme [10], [26], as the signatures generated by itcan be verified in a gas-efficient manner in Solidity using theecrecover precompiled smart contract [48]. Additionally,the signature scheme makes off-chain signatures compatiblewith on-chain accounts and as such signatures made off-chain can be verified using public keys available on-chain. Wemeasured the gas cost for Warden values of n = 3 to 30. Werecommend the value of n = 13 as highlighted in the figure,since it is safe, has good performance and aligns the incentivescorrectly.

Once the contract is deployed on the Ethereum network,Alice funds it first. Subsequently, once Alice’s funding transac-tion is finalized, Bob funds it. Once Bob’s funding transactionis finalized, the collateral can be calculated and so the Wardenscan fund it in any order simultaneously. When all Wardenshave funded the contract, any of the two parties can open thechannel. At any time prior to opening the channel, any party orWarden can withdraw their money, at which point the channelis cancelled and can no longer be opened, but allows the restof the parties to withdraw as well, in any order. Once thechannel is open, the parties can continue exchanging states

off-chain. If multiple BRICK channels are used, then the costof smart contract deployment can be amortized over all ofthem by abstracting the common functionality into a Soliditylibrary. However, the opening and closing costs are recurrent.We remark here that our cost of deployment (≈ 9 EUR)is comparable to other state channel smart contracts whichperform different operations under different assumptions (e.g.,at current prices, the deployment of the 3 Pisa [36] contractsamounts to ≈ 17 EUR).

When the parties wish to close the channel optimistically,initially Alice submits a transaction to the smart contractrequesting the channel to close. This request contains Alice’sclaimed closing state (namely, Alice’s value at closing time,as Bob’s value at closing time can be deduced from this).Once Alice’s transaction is confirmed, if Bob is in agreement,he submits a transaction to the smart contract to signal hisagreement. The smart contract then returns Alice’s and Bob’svalues as well as Wardens’ collateral. Care must be takento check that the sum of Alice’s value and Bob’s value atthe closing state does not exceed the sum of their values attheir initial state, so that sufficient funds remain to returnthe Wardens’ collateral. If Bob does not agree with Alice’sclaim, the channel becomes unusable and must be closedpessimistically (Alice can no longer make an optimistic claimon a different state). The optimistic close operation measuresthe cumulative gas cost of the two transactions from bothparties. The cost is minimal and should be the normal pathsince parties need not pay closing fees.

Finally, the channel can be closed pessimistically at anytime. To do this, the party who wishes to close the channelrequests this from the Wardens. Each Warden then submitsa transaction to the smart contract containing the sequencenumber they have seen last, together with Alice’s and Bob’soff-chain signature on it. These can be submitted in any order.The signatures of Alice and Bob on the sequence number areverified on-chain; this incurs the majority of gas cost for thepessimistic close. The party who wishes to close the channelmonitors the chain for such claims and remembers any ofthem that are fraudulent. As soon as t (honest or adversarial)claims have been recorded, either Alice or Bob can send atransaction to the smart contract to close the channel. Thetransaction is accompanied by the fraud proofs the closingparty was able to assemble, namely the latest announcementfor each Warden who made a claim on an earlier sequencenumber. These announcements contain the signature of theWarden on the plaintext which consists of the smart contractaddress and the sequence number. As smart contracts haveunique addresses, including the smart contract address in theplaintext ensures that the same Warden can participate inmultiple BRICK channels simultaneously using the same publickey14. Closing the channel releases the funds of the participantparties and slashes any malicious Wardens. After the channelhas been closed, any honest Wardens who wish to redeem theircollateral and their corresponding fee can do so by issuing afurther transaction to the smart contract. The pessimistic closeoperation was measured when no fraud proofs are providedand includes the transaction of each of the t Wardens and

14If BRICK is deployed on multiple alt-etherea, each Warden must use adifferent key in each, or the smart contract must be modified to have theWarden sign the CHAIN_ID together with the address and sequence number.

10

0.00

0.01

0.02

0.03

0.04

0.05

0.06

0.07

Ethe

r

5 10 15 20 25 30Number n of Wardens

0

2

4

6

8

10

12

14EU

RGas cost of a Brick channel

Cost of deploymentCost of openingCost of pessimistic closeCost of optimistic closeRecommended n

Fig. 2: The on-chain gas cost of deploying and operatingBRICK in the form of an Ethereum smart contract.

the final transaction by one of the parties. Additionally, itwas assumed that, while the counterparty is unresponsive ormalicious, the Wardens were responsive and all submitted thesame sequence number (hence limiting the need for multiplesignature validations).

b) Consistent Broadcast: We have also implementedconsistent broadcast in Golang using the Kyber [34] crypto-graphic library and the cothority [15] framework. In Table IIwe evaluate our protocol on Deterlab [16] using 36 physicalmachines, each having four Intel E5-2420 v2 CPUs and 24GB RAM. To have a realistic wide area network, we imposea 100ms roundtrip latency on the links between Wardens anda 35Mbps bandwidth limit.

As illustrated the overhead of using a committee is almostequal to a round-trip latency (100ms). The small overhead isdue to the party sending the messages in sequence, hencethe last message is sent with a small delay d > 0. This isobserved in the total latency which is close to 100 + d ms.This latency in BRICK defines the time parties must wait toexecute a transaction safely, meaning that BRICK provides fastfinality. These numbers are three orders of magnitude fasterthan current blockchains, such as Ethereum where blocks aregenerated on average every 12sec and finality is guaranteedafter 6 minutes. Furthermore, channels are independent andembarrassingly parallel which means that we can deploy asmany as we want without significantly increasing the overhead.In contrast to synchronous channel solutions where finalityunder our model is guaranteed only after channel closure,BRICK provides fast finality (rtt).

TABLE II: Microbenchmark of BRICK

Number of Wardens 7 34 151

Consistent Broadcast 0.1138 sec 0.118 sec 0.1338 sec

VIII. DISCUSSION, LIMITATIONS, AND EXTENSIONS

This section briefly outlines several of BRICK’s importantremaining limitations, possible extensions, and discussion ondesign choices.

Byzantine players: If both channel parties are byzantinethen the Wardens’ collateral can be locked arbitrarily longsince the parties can simply crash forever. This is why inthe threat model, we assume that at least the richest channelparty is rational to correctly align the incentives. The secondthreshold assumption of BRICK is that at most f out of the3f + 1 Wardens are byzantine. This threshold is necessaryto maintain safety and is in accordance to well known lowerbounds for asynchronous consistent broadcast.

Warden Unilateral Exit: As mentioned above, if bothparties become malicious they might hold the Wardens’ collat-eral hostage. A similar situation is indistinguishable from theparties not transacting often. As a result the Wardens mightwant to exit the channel. A potential extension can supportthis in two ways.

The first functionality we can incorporate in BRICK, iscommittee replacement. In particular, we can allow a Wardento withdraw its service as long as there is another Wardenwilling to take its place. In this case, we simply replace thecollateral and Warden identities with an update of the fundingtransaction on-chain, paid by the Warden that requests towithdraw its service.

Second, if a significant number (e.g, 2f + 1) of Wardensdeclare they want to exit, the smart-contract can release themand convert the channel to a synchronous channel [36]. Theparties will now be able to close the channel unilaterally bydirectly publishing the last valid state. If the counterparty triesto cheat and publishes an old state, the party (or any remainingwatchtower) can catch the dispute on-time and additionallyclaim the (substantial) closing fee.

Committee Selection: Each channel has its own group ofWardens, i.e., the committee is independently selected for eachchannel by the channel parties. The scalability of the systemis not affected by the use of a committee since each channelhas its own independent committee of Wardens. The size ofthe committee for each channel can vary but is constrained bythe threat model. If we assume at least one honest party in thechannel, a single rational Warden is enough to guarantee thecorrect operation of BRICK. Otherwise, we require more than7 Wardens to avoid hostage situations from colluding channelparties (see Section IV).

The main purpose of introducing a Warden committeeis to increase the fault tolerance of the protocol. The costof maintaining the channel security for the parties is notdependent on the committee size, but on the value of thechannel. If the parties chose a small committee size, thecollateral per Warden is high, thus the update fees are few buthigh. On the other hand, if the parties employ many Wardens,the collateral per Warden is low, thus the update fees are manybut low. In summary, the cost of security is proportional tothe value of the channel and independent of the size of thecommittee.

Consensus vs Consistent Broadcast: Employing consistentbroadcast in a blockchain system typically implies no conflict

11

resolution as there is no liveness guarantee if the senderequivocates. This is not an issue in channels since a validupdate needs to be signed by both parties and we providesafety guarantees only to honest and rational parties15.

The state updates in channels are totally ordered by theparties and each sequence number should have a uniquecorresponding state. Thereby, it in not the role of the Wardencommittee to enforce agreement, but merely to verify thatagreement was reached, and act as a shared memory forthe parties. For this reason, state machine replication (orconsensus) protocols are not necessary. Consistent broadcastis tailored for BRICK as it offers the only necessary property,equivocation protection.

BRICK Security under Execution Fork Attacks: We canextend BRICK to run asynchronous consensus [33] duringthe closing phase in order to defend against execution forkattacks [28]. This would add an one-off overhead duringclose but would make BRICK resilient against extreme con-ditions [2]. For example, in case of temporary dishonestmajority the adversary can attack the persistence16 of theunderlying blockchain, meaning that the adversary can double-spend funds. The same holds for all channel constructionsso far; if the adversary can violate persistence, the disputeresolution can be reversed, hence funds can be cheated out ofa channel party.

For BRICK there is limited protection as the adversarycan only close on the last committed state or the freshestvalid (but not committed) state. With consensus during close,BRICK maintains safety (i.e., no party loses channel funds)even when persistence is violated. A malicious party can onlyclose the channel in the state that the consensus decides to belast, thus a temporary take-over can only affect the channel’sliveness. Therefore, BRICK can protect both against livenessand persistence attacks17 on the underlying blockchain addingan extra layer of protection, and making it safer to transact onBRICK than on the underlying blockchain.

Update Fees: Currently in BRICK, the Wardens (commit-tee) get rewarded on every state update via a one-way channel.Ideally, these rewards would be included in the state updateof the channel. However, even if we modify the update ofthe state to increase the fees on every update, the parties canalways invoke the Optimistic Close protocol, and updatethe channel state to their favor when closing. Therefore, theincentives mechanism is not robust if the update rewards ofthe Wardens are included in the update states.

Collateral: The collateral for each Warden is v/f , where vis the total value of the channel and f the number of byzantineWardens. This is slightly higher than v/(f + 1) that is thelowest amount for which security against bribing attacks isguaranteed when both channel parties and Wardens are rationalunder asynchrony. Towards a contradiction, we can simplyconsider a channel where Wardens lock a total collateral c < v.Then any rational party that has less than v−c−ε value in the

15Of course if a party crashes we cannot provide liveness, but safety holds.16Persistence states that once a transaction is included in the permanent part

of one honest party’s chain, then it will be included in every honest partysblockchain, i.e., the transaction cannot change.

17We assume the channel to be created long before these attacks take place,so the adversary cannot fork the transaction that creates the channel.

freshest state will bribe the Wardens c+ ε coins and close thechannel in a previous state where the party holds the total valuev of the channel. In a synchronous network, this attack wouldnot work since the other parties would have enough time todispute. However, under asynchrony (or simple offline partiesassumption [36]) there is no such guarantee. This requirementhighlights a trade-off for replacing trust: online participationwith synchrony requirements or appropriate incentive mecha-nisms to compel the honest behavior of rational players.

BRICK+ Channel Close: In BRICK, the parties can closethe channel in agreement at any time without the need forcommittee intervention (Optimistic Close). However,BRICK+ does not allow this function; a channel can only closein collaboration with the committee. Otherwise, the channelparties can update the channel and alter the history withoutaccountability. In case of malicious behavior of the committee(which is outside the threat model of this work), we assumethat the parties can alert the auditor who can pursue externalpunishment to enforce the Wardens to be responsive.

Decentralization: In previous payment channel solutions aparty only hires a watchtower if it can count on it in case of anattack. In other words, watchtowers in older protocols are theequivalent of insurance companies. If the attack succeeds, thewatchtower should reimburse the cheated channel party [36].After all, it is the watchtower’s fault for not checking theblockchain when needed. However, in light of network attacks(which are prevalent in blockchains [1], [24]), only a few,centrally connected miners will be willing to take this risk.BRICK provides an alternative, that proactively protects fromsuch attacks and we expect to provide better decentralizationproperties with minimal overhead and fast finality.

IX. RELATED WORK

In this work we presented BRICK, the first incentive-compatible payment channel that provides safety even whenparts of the network are disconnected. We exhibit the dif-ferences of BRICK to other channel constructions, such asLightning, as well as other watchtower solutions, such asMonitors, Pisa and Cerberus in Table III. Specifically, weobserve that BRICK is the only Layer 2 solution that maintainssecurity under an asynchronous network and offline channelparties while assuming rational Wardens. Further, BRICK issecure even when the blockchain substrate is censored, andalso when the network is congested. Finally, an extension toBRICK that we describe in Section VIII enables protectionagainst small scale persistence attacks making it more securethan the underlying blockchain.

Payment channels were originally introduced bySpilman [46], as a unidirectional off-chain solution, meaningthat the sender can send to the receiver incremental paymentsoff-chain via the channel, as long as the sender has enoughcapital on the channel. Later, bidirectional channels wereintroduced independently by Poon et al. with LightningNetwork [42], and Decker and Wattenhofer with Duplex

18The party needs to be able to deliver messages and punish the watchtowerwithin a large synchrony bound T.

19The watchtower needs to lock collateral per-channel, equal to the chan-nel’s value. Current implementation of Pisa does not provide this.

20Possible if consensus is run for closing the channel as described inSection VIII.

12

TABLE III: Comparison with previous workSafe under Lightning [42] Monitors [17] Pisa [36] Cerberus [4] Brick

Asynchronous Network 7 7 7 7 3

Offline Parties 7 3 T � td18 T � td

18 3

Rational Players 7 7 ∼19 3 3Censorship 7 7 7 7 3Congestion 7 7 7 7 3

Forks 7 7 7 7 320

Bitcoin Compatible 3 3 7 3 7

Micropayment Channels [14]. Bidirectional channels allowedthe capital locked in the channel to be moved in bothdirections from sender to receiver and back, like in a row ofan abacus. All these solutions though require timelocks toguarantee safety and thus make strong synchrony assumptionsthat sometimes fail in practice. BRICK, on the other hand, isthe first bidirectional channel solution that does not requiretimelocks and operates securely under full asynchrony.

Another safety requirement of the original payment channelproposals is that the participants of a channel are obligated tobe frequently online, actively watching the blockchain. To ad-dress this issue, recent proposals introduced third-parties in thechannel to act as proxies for the participants of the channel incase of fraud. This idea was initially discussed by Dryja [17],who introduced third-parties on Lightning channels, knownas Monitors or Watchtowers [27]. Later, Avarikioti et al.proposed DCWC [3], a less centralized distributed protocolfor the watchtower service, where every full node can act asa watchtower for multiple channels depending on the networktopology. In both these works, the watchtowers are paid uponfraud. Hence, the solutions are not incentive-compatible sincein case a watchtower is employed no rational party will commitfraud on the channel and thus the watchtowers will never bepaid. This means there will be no third parties offering such aservice unless we assume they are altruistic.

In parallel, McCorry et al. [36] proposed Pisa, a protocolthat enables the delegation of Sprites [38] channels’ safetyto third-parties called Custodians. Although Pisa proposesboth rewards and penalties similarly to BRICK, it fails tosecure the channels against bribing attacks. Particularly, thewatchtower’s collateral can be double-spent since it is not tiedto the channel/party that employed the watchtower. More im-portantly, similarly to Watchtowers and DCWC, Pisa demandsa synchronous network and a perfect blockchain, meaning thattransactions must not be censored, to guarantee the safetyof channels. On the contrary, BRICK is provably secure un-der rational parties and watchtowers and operates under fullasynchrony. Similarly to Watchtowers and Pisa, BRICK alsomaintains privacy from external to the channel parties, i.e., allthe off-chain update states are visible only to the parties of thechannel (not to the Wardens).

Concurrently to this work, Avarikioti et al. introducedCerberus channels [4], a modification of Lightning channelsthat incorporates rational watchtowers to Bitcoin channels.Although Cerberus channels are incentive-compatible, theystill require timelocks. Thus, in contrast to BRICK, theirsecurity depends on the synchrony assumptions and a perfectblockchain that cannot be censored. Furthermore, Cerberuschannels do not guarantee privacy from the watchtowers, asopposed to BRICK and BRICK+, where unauthorized externalparties have no information on the state of the channel.

State Channels, Payment Networks, and Sidechains

Payment channels are specifically-tailored solutions thatsupport only payments between users. To extend this solutionto handle smart contracts [47] that allow arbitrary operationsand computations, state channels were introduced [38]. Re-cently, multiple state channel constructions have emerged,but they mainly focus on the routing problem of channelnetworks. In particular, Sprites [38] improve on the worst-case delay for releasing the collateral of the intermediatenodes on the payment network for multi-hop payments. Inparallel, Perun [19], [20] proposes a virtual payment hub,where every party can connect to and hence establish a “virtualchannel” with any other party connected to the hub. In a similarmanner, Counterfactual [9] presents “meta-channels”, whichare generalized state channels (not application-specific) withthe same functionality as “virtual channels”. However, all theseconstructions use the same foundations, i.e., the same concepton the operation of two-party channels. And as the fundamentalchannel solutions are flawed the whole construction inheritsthe same problems (synchrony and availability assumptions).BRICK’s design could potentially extend to an asynchronousstate channel solution if there existed a valuation function forthe states of the contract ( i.e., a mapping of each state to amonetary value for the parties) to correctly align incentives. Inthis case, the channel can evolve as long as the parties updatethe state, while in case of of an uncooperative counterpartythe honest party can always pessimistically close the channelat the last agreed state and continue execution on-chain.

Another solution for scaling blockchains is sidechains [5],[23], [29]. In this solution, the workload of the blockchain(main chain) is transferred in other chains, the sidechains,which are “pegged” to the main chain. Although the solutionis kindred to channels, it differs significantly in one aspect:in channels, the states updates are totally ordered and unan-imously agreed by the parties thus a consensus process isnot necessary. On the contrary, sidechains must operate aconsensus process to agree on the validity of a state update.BRICK lies in the intersection of the two concepts; the statesare totally ordered and agreed by the parties, whereas Wardensmerely remember that agreement was reached at the last stateannounced.

Finally, an extension to payment channels is paymentchannel networks (PCN) [6], [39], [43], [45]. The core ideaof PCN is that users that do not have a direct channel canroute payments using the channels of other users. WhileBRICK presents a novel channel construction that is safeunder asynchrony, enabling asynchronous multi-hop paymentsremains an open question.

13

X. ACKNOWLEDGEMENTS

We would like to thank Jakub Sliwinski for his valuablediscussion and feedback as well as his impactful contributionto this work.

REFERENCES

[1] M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking Bitcoin: Large-scale Network Attacks on Cryptocurrencies,” 38th IEEE Symposium onSecurity and Privacy, May 2017.

[2] G. Avarikioti, L. Kappeli, Y. Wang, and R. Wattenhofer, “Bitcoin se-curity under temporary dishonest majority,” in Financial Cryptographyand Data Security (FC), 2019, pp. 466–483.

[3] G. Avarikioti, F. Laufenberg, J. Sliwinski, Y. Wang, and R. Watten-hofer, “Towards secure and efficient payment channels,” CoRR, vol.abs/1811.12740, 2018.

[4] Z. Avarikioti, O. S. T. Litos, and R. Wattenhofer, “Cerberus Channels:Incentivizing Watchtowers for Bitcoin,” in Financial Cryptography andData Security (FC), Kota Kinabalu, Sabah, Malaysia, February 2020.

[5] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller,A. Poelstra, J. Timon, and P. Wuille, “Enabling blockchain innovationswith pegged sidechains,” 2014, https://blockstream.com/sidechains.pdf.

[6] V. Bagaria, J. Neu, and D. Tse, “Boomerang: Redundancy improves la-tency and throughput in payment networks,” in Financial Cryptographyand Data Security (FC), 2020.

[7] G. Bracha, “Asynchronous byzantine agreement protocols,” Informationand Computation, vol. 75, no. 2, pp. 130–143, 1987.

[8] C. Burchert, C. Decker, and R. Wattenhofer, “Scalable funding ofbitcoin micropayment channel networks,” Royal Society open science,vol. 5, no. 8, p. 180089, 2018.

[9] J. Coleman, L. Horne, and L. Xuanji, “Counterfactual: Generalized statechannels,” 2018, https://l4.ventures/papers/statechannels.pdf.

[10] N. T. Courtois, M. Grajek, and R. Naik, “Optimizing sha256 in bitcoinmining,” in International Conference on Cryptography and SecuritySystems. Springer, 2014, pp. 131–144.

[11] K. Croman et al., “On scaling decentralized blockchains,” in Inter-national Conference on Financial Cryptography and Data Security.Springer, 2016, pp. 106–125.

[12] C. Decker, R. Russell, and O. Osuntokun, “eltoo: A simple layer2protocol for bitcoin,” 2018, https://blockstream.com/eltoo.pdf.

[13] C. Decker, J. Seidel, and R. Wattenhofer, “Bitcoin MeetsStrong Consistency,” in 17th International Conference onDistributed Computing and Networking (ICDCN), Singapore,January 2016. [Online]. Available: http://www.tik.ee.ethz.ch/file/ed3e5da74fbca5584920e434d9976a12/peercensus.pdf

[14] C. Decker and R. Wattenhofer, “A fast and scalable payment networkwith bitcoin duplex micropayment channels,” in Stabilization, Safety,and Security of Distributed Systems, A. Pelc and A. A. Schwarzmann,Eds. Cham: Springer International Publishing, 2015, pp. 3–18.

[15] “DeDiS cothority,” Sep. 2016, https://www.github.com/dedis/cothority.[16] “DeterLab Network Security Testbed,” September 2012. [Online].

Available: http://isi.deterlab.net/[17] T. Dryja, “Unlinkable outsourced channel monitoring,” Scaling Bitcoin

Milan, 2016.[18] S. Dziembowski, L. Eckey, and S. Faust, “Fairswap: How to fairly

exchange digital goods,” in Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security. ACM, 2018,pp. 967–984.

[19] S. Dziembowski, L. Eckey, S. Faust, J. Hesse, and K. Hostakova,“Multi-party virtual state channels,” in Annual International Conferenceon the Theory and Applications of Cryptographic Techniques. Springer,2019, pp. 625–656.

[20] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski, “Perun: Virtualpayment hubs over cryptocurrencies,” in 2019 IEEE Symposium onSecurity and Privacy (SP), 2017, pp. 327–344.

[21] J. Feigenbaum, “Multiple Objectives of Lawful-Surveillance Protocols(Transcript of Discussion),” in Cambridge International Workshop onSecurity Protocols. Springer, 2017, pp. 9–17.

[22] J. Garay, A. Kiayias, and N. Leonardos, “The Bitcoin backboneprotocol: Analysis and applications,” in EUROCRYPT 2015. Springer,2015, pp. 281–310. [Online]. Available: https://eprint.iacr.org/2014/765.pdf

[23] P. Gazi, A. Kiayias, and D. Zindros, “Proof-of-Stake Sidechains,” in2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp.139–156.

[24] A. Gervais, H. Ritzdorf, G. O. Karame, and S. Capkun, “Tamperingwith the Delivery of Blocks and Transactions in Bitcoin,” in22nd ACM SIGSAC Conference on Computer and CommunicationsSecurity. ACM, 2015, pp. 692–705. [Online]. Available: https://eprint.iacr.org/2015/578.pdf

[25] L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais,“Sok: Off the chain transactions,” IACR Cryptology ePrint Archive, vol.2019, p. 360, 2019. [Online]. Available: https://eprint.iacr.org/2019/360

[26] N. Gura, A. Patel, A. Wander, H. Eberle, and S. C. Shantz, “Comparingelliptic curve cryptography and rsa on 8-bit cpus,” in Internationalworkshop on cryptographic hardware and embedded systems. Springer,2004, pp. 119–132.

[27] A. Hertig, “Bitcoin Lightning Fraud? Laolu Is Building a’Watchtower’ to Fight It,” 2018, https://www.coindesk.com/laolu-building-watchtower-fight-bitcoin-lightning-fraud.

[28] G. O. Karame, E. Androulaki, and S. Capkun, “Double-spendingfast payments in Bitcoin,” in 19th ACM Conference on Computerand communications security. ACM, 2012, pp. 906–917. [Online].Available: https://eprint.iacr.org/2012/248.pdf

[29] A. Kiayias and D. Zindros, “Proof-of-Work Sidechains,” in Inter-national Conference on Financial Cryptography and Data Security.Springer, 2019, pp. 21–34.

[30] E. Kokoris-Kogias, E. C. Alp, S. D. Siby, N. Gaillya, P. Jovanovic,L. Gasser, and B. Ford, “Hidden in Plain Sight: Storing and Manag-ing Secrets on a Public Ledger,” Cryptology ePrint Archive, Report2018/209, 2018.

[31] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, andB. Ford, “Enhancing Bitcoin Security and Performance with StrongConsistency via Collective Signing,” in Proceedings of the 25th USENIXConference on Security Symposium, 2016, pp. 279–296.

[32] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, andB. Ford, “OmniLedger: A Secure, Scale-Out, Decentralized Ledger viaSharding,” in 2018 IEEE Symposium on Security and Privacy, 2018,pp. 583–598.

[33] E. Kokoris-Kogias, A. Spiegelman, D. Malkhi, and I. Abraham, “Boot-strapping Consensus Without Trusted Setup: Fully Asynchronous Dis-tributed Key Generation,” Cryptology ePrint Archive Report 2019/1015,Cryptology ePrint Archive, Report 2019/1015, Tech. Rep., 2019.

[34] “The Kyber Cryptography Library,” 2010 – 2018.[35] D. Mazieres and D. Shasha, “Building secure file systems out of

byzantine storage,” in Proceedings of the twenty-first annual symposiumon Principles of distributed computing. ACM, 2002, pp. 108–117.

[36] P. McCorry, S. Bakshi, I. Bentov, S. Meiklejohn, and A. Miller, “Pisa:Arbitration outsourcing for state channels,” in Proceedings of the 1stACM Conference on Advances in Financial Technologies. ACM, 2019,pp. 16–30.

[37] A. Miller, “Feather-forks: enforcing a blacklist with sub-50% hashpower,” https://bitcointalk.org/index.php?topic=312668.0, 2013.

[38] A. Miller, I. Bentov, S. Bakshi, R. Kumaresan, and P. McCorry, “Spritesand state channels: Payment networks that go faster than lightning,”in Financial Cryptography and Data Security - 23rd InternationalConference, FC 2019, 2019, pp. 508–526.

[39] P. Moreno-Sanchez, A. Kate, and M. Maffei, “Silentwhispers: Enforcingsecurity and privacy in decentralized credit networks,” 2017.

[40] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[41] H. Pagnia and F. C. Gartner, “On the impossibility of fair exchange

without a trusted third party,” Technical Report TUD-BS-1999-02,Darmstadt University of Technology, Germany, Tech. Rep., 1999.

[42] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off-chaininstant payments,” 2015.

[43] P. Prihodko, S. Zhigulin, M. Sahno, A. Ostrovskiy, and O. Osuntokun,“Flare : An approach to routing in lightning network white paper,” 2016.

14

[44] M. K. Reiter, “Secure agreement protocols: Reliable and atomic groupmulticast in rampart,” in Proceedings of the 2nd ACM Conference onComputer and Communications Security. ACM, 1994, pp. 68–80.

[45] S. Roos, P. Moreno-Sanchez, A. Kate, and I. Goldberg, “Settlingpayments fast and private: Efficient decentralized routing for path-basedtransactions,” arXiv preprint arXiv:1709.05748, 2017.

[46] J. Spilman, “Anti dos for tx replacement,” Bitcoin Developers Forum,2013, accessed: 2020-01-20.

[47] N. Szabo, “Formalizing and securing relationships on public networks,”First Monday, vol. 2, no. 9, 1997.

[48] G. Wood et al., “Ethereum: A secure decentralised generalised transac-tion ledger,” 2014.

[49] K. Wust, K. Kostiainen, V. Capkun, and S. Capkun, “Prcash: Fast,private and regulated transactions for digital currencies,” in FinancialCryptography and Data Security (FC), 2019, pp. 158–178.

APPENDIX

A. Attack against existing channel constructions

Here we present a concrete attack against Pisa [36]. Thisattack applies to any channel construction that has a time-outdispute process. The attack is simple and relies on delayingthe appearance of the dispute transaction on-chain until thedispute window expires. The attack is as follows:

1) Alice and Bob establish a state-channel. As Pisa con-structs, both Alice and Bob chose their favorite watch-tower and provably assign to them the job of watchingthe chain.

2) Alice sends multiple coins to Bob through state changesS1, S2, ..., Sn.

3) Alice request the closure of the channel with state S1

where Alice holds more coins that Sn.4) Bob or Bob’s watchtower detects the attack and sends on

the network a dispute transaction for Sn.5) Alice attacks Bob in one of the following ways:

a) Congests the blockchain so that the dispute transactionfor Sn does not appear on-chain until after the disputewindow expires.

b) Depending on the blockchain, Alice can censor thedispute transaction for Sn without congesting the net-work [37].

c) If Alice is a classic asynchronous network adver-sary [7], Alice can delay the delivery of the disputetransaction for Sn until after the dispute window.

6) Since the dispute transaction for Sn appears after thedispute window expires, the safety of the channels isviolated.

In Pisa this attack might cause the watchtower to bepunished although the watchtower did not misbehave. In otherchannels [27], [38], that do not employ or do not collateralizewatchtowers, this attack leads to direct value loss for Bob.These attacks do not apply in BRICK and BRICK+ since theadversary can only temporarily thwart liveness of the closefunction.

B. Incentivizing Rational Parties

In this section, we show that the security of BRICK holdsas long as the richest party of the channel is rational - the otherparty can be byzantine. We argue for every phase separately.

Open: Naturally, if a party is not incentivized to open achannel then that channel will never be opened. We assumethe parties have some business interest to use the blockchainand since transacting on channels is faster and cheaper theywill prefer it. Deviating from the protocol at this phase ismeaningless.

Update: During the execution of Protocol 2, any partycan deviate from the protocol by not signing the hash ofthe new state. In this case, the new state will not be validand thus cannot be committed and will not be executed.No party can increase its profit from such behavior directly(attacking the safety of the channel). The same argument holdsin case the party signs the hash but not the sequence number.Moreover, attempting to attack the liveness of the channel isnot profitable since the counterparty can always request toclose in collaboration with the committee by invoking Protocol5: Pessimistic Close.

Lastly, channel parties can collude and stop updating thechannel (liveness attack) in order to enforce a hostage situationon the Wardens’ collateral. However, the committee size isat least n > 7. Thereby, from the pigeonhole principle thereis at least one party in the channel that has locked funds atleast equal to v

2 > vf , i.e., the richest party of the channel.

Thus, the richest channel party locks an amount larger thaneach Warden’s collateral which means that this party’s costis larger than a Wardens. Since we assume the richest partyis rational, at any time this party is incentivized to close thechannel in collaboration with the committee. Thus, the richestparty (if rational) will not deviate from the honest executionof Protocol 2.

During the execution of Consistent Broadcast, aparty can deviate in the following ways:

• First, a party can choose not to broadcast the announce-ment to the committee or part of the committee. In thiscase, the party has signed the new state, which is nowa valid state. This state will be considered committedfor the counterparty after the execution of Protocol 3.We show a rational party cannot increase its payoff bynot broadcasting the announcement to all Wardens. Todemonstrate this, we consider two cases; either the newstate is beneficial to the party or not. If the new state isbeneficial to party A, then this state is not beneficial forthe counterparty (e.g., B payed A for a service). Thus, ifthe committee has not received the freshest state, party Bcan “rightfully” close the channel in the previous state.Hence, the expected payoff of party A decreases. On theother hand, suppose the new state is not beneficial toparty A and it chooses not to send the announcement tothe committee. Then, either the counterparty will havethe state committed or the state will not be executed.From the safety property of the channels, party A cannotsuccessfully close the channel in a previous state if thestate was committed. Hence, party A does not increaseits payoff. On the other hand, if party A does not requestthe signature of a Warden that will later commit fraud,then the party cannot construct a proof-of-fraud to claimthe Warden’s collateral and therefore the party’s payoffdecreases.

• Second, a party can broadcast different messages to thecommittee or parts of the committee. During the execution

15

of Protocol 3, the Wardens verify the parties’ signatures,thus an invalid message will not be acknowledged from anhonest Warden. If the messages are valid (both parties’signatures are present), the parties have misbehaved incollaboration. This can lead to a permanent partition ofthe view of the committee regarding the state history, butat most one of the states can be committed (get the 2f +1 signatures). Thus, this strategy has the same caveatsas the previous one, where the party can only lose fromfollowing it.

• Lastly, the party can choose not to proceed to the statetransition. This is outside the scope of the paper and aproblem of a different nature (a fair exchange problem).

Overall, a rational party cannot increase its payoff by deviatingfrom Protocol 2 or Protocol 3.

Close: In this phase, there are two different options:Optimistic Close and Pessimistic Close.In the first case, where Protocol 4 is executed, a party candeviate from it in the following ways:

• It is the party requesting the closing of the channel ina cheating state. The counterparty will not sign the statesince it is being cheated, else it would not be a cheatingstate. Thus, safety is guaranteed and the party cannotprofit from this strategy.

• It is the party requesting the closing of the channel andnever publishes the signed closing state. In line 2 of Pro-tocol 4, the signatures on the state are exchanged betweenthe parties, hence the counterparty will eventually publishthe closing state. Note that we assume that the closingparty sends its signature first with the closing request.

• It is the party that got the closing request and does notsign the state. In this case, the party requesting to close thechannel can invoke the Pessimistic Close protocoland close the channel in collaboration with the committeein the freshest committed state.

Thus, any potential deviation from Protocol 4 cannot increasethe payoff of a party executing the protocol.In the second case, where Protocol 5 is executed, a party candeviate from it in the following ways:

• The party that requested to close is not responsive,meaning that the party does not publish the closing state.In this case, either the party is the richest of the channelor not. If the party is the richest of the two then theparty’s cost of not responding is higher than that of thecounterparty and any other Warden’s cost. Therefore, theparty is not the richest of the channel. In this case, thecounterparty which wants to close the channel, can usethe on-chain closing announcements of the Wardens andpublish the closing state. In both cases, the party thatrequested close cannot increase its payoff by not revealingthe closing state, but only lose from locking its channelfunds for a longer period of time that necessary (since noupdates are possible).

• The party that requested to close the channel publishesan invalid closing state (e.g., random state, previouslyvalid state, a committed state that is not the freshest).However, the smart contract will not close the channel inthis state because some verification will fail. Therefore,

Protocol 7: Update for BRICK+

Input: Channel parties A,B, current state s, previoushead of hashchain Hp.

Goal: Create announcement {M,σ(M), Hs} (sequencenumber of new state and head of hash chain).

1. Both parties A,B sign and exchange:{Hs = H(Hp, H(si, ri), i)}, where ri is a randomnumber and si the current state.

2. After receiving the signature of the counterparty onHs, the party uses it to create the announcement{M,σ(M), Hs}(M = i).

the party will simply lose the blockchain fee for the on-chain transaction and will not gain any profit. Note thatfor a rational party to successfully commit fraud, at leastone rational V-B.

To summarize, if the richest channel party deviates fromthe honest protocol execution at any phase, it cannot increaseits payoff. Therefore, the richest rational party will follow theprotocol, hence honest behavior for the richest party is thedominant strategy.

C. BRICK+ Security Analysis

In this section, we first prove the BRICK+ goals, namelySafety, Liveness, Privacy and Auditability assuming 2f + 1honest Wardens, and later we argue that rational Wardens willnot deviate from the protocol.

Throughout this section, we assume the richest channelparty is rational, thus it will not deviate from honest behaviorif it will be discovered and punished. Furthermore, we assumethe auditor is also rational, meaning that the auditor will onlydeviate from the protocol to gain more profit (hence the needfor a smart contract to do the fair exchange between the auditorand the committee). However, the auditor will not punish aparty arbitrarily with no proof, since the auditor is supposedto be an external trusted authority (e.g., judge, regulator, taxoffice etc.). Lastly, we assume the threat model of Section III-Aregarding Wardens.

Theorem 3. BRICK+ achieves safety under asynchrony in oursystem model.

Proof: It follows from Theorem 1, since all modificationson BRICK do not affect the safety property.

Theorem 4. BRICK+ achieves liveness under asynchrony inour system model.

Proof: It follows from Theorem 2, since all modificationson BRICK do not affect the liveness property.

Theorem 5. BRICK+ achieves privacy assuming byzantineWardens and parties that want to maintain privacy.

Proof: Suppose an external party learns about the stateof the channel during the protocol execution. This means thateither the external party intercepted a message (between theparties of the channel or between the parties and the com-mittee) or it is a Warden. In the first case, we assume secure

16

Fig. 3: Typical workflow of BRICK+ for an audit update. (1) The auditor starts the audit by posting the request on chain, (2)the committee closes the channel, and (3) the parties transfer the state to the auditor. Finally, (4) the auditor cross-checks theclaims of the party and the committee.

communication channels thus a computationally-bounded ad-versary cannot get any information from the messages betweenthe parties. In the latter case, the Wardens receive during theUpdate phase a message with Hs = H(Hp, H(si, ri), i) forany valid state update (assuming honest parties that do notintentionally reveal the state). If the Warden extracts the stateof the channel si from the H(si, ri) (since it knows Hp), theWarden reverted the hash function. Therefore, the hash func-tion is not pre-image resistant for a computationally-boundedadversary and hence not cryptographically-secure. This contra-dicts the system model, where we assumed cryptographically-secure hash functions.

Furthermore, the audit request, which is the first step ofthe audit functionality, does not leak any information on thechannel since the auditor is an external to the channel party.According to Protocol 6, the parties publish the closing stateon-chain to close the channel (Protocol 5). Thus, privacy ispreserved since by definition it is only guaranteed until at leastone of the parties initiates the closing of the channel.

Theorem 6. BRICK+ achieves auditability under asynchronyin our system model.

Proof: Since both the Wardens and a party of the channelare rational, Protocol 6 will not complete (a valid closingstate will not be published) unless the request for access isvalid, hence the auditor is authorized. Thus, to prove BRICK+satisfies auditability, it is enough to prove that every committedstate is verifiable by a third party.

Towards contradiction, suppose s is the earliest (least fresh)committed state that is not verifiable (since there is at leastone). This means that state s is replaced by another state s′either in the history of all parties or in the hash-chain thatproduced the hash-head corresponding to the closing state.If s is not part of the hash-chain, but it is committed, thenthe parties misbehaved and sent to at least one Warden adifferent state. Note that the Warden cannot misbehave sincethe announcement must have the signatures of both parties.Furthermore, two different states cannot be simultaneouslycommitted since this would require two quorums of 2f + 1

Wardens that signed different state updates, thus at leastf + 1 Byzantine Wardens. Contradiction to our threat model.Therefore, state s is not part of the state history providedby the parties. In both cases, the auditor punishes the parties(externally). And since we assume one party of the channelis rational (and the external punishment exceeds the potentialgain of cheating), the party will not misbehave. Thus, everycommitted state is verifiable.

17