A Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels
11A Blockchain-based Iterative Double Auction Protocol usingMultiparty State Channels
TRUC D. T. NGUYEN,
University of Florida
MY T. THAI ∗ , University of FloridaAlthough the iterative double auction has been widely used in many different applications, one of the majorproblems in its current implementations is that they rely on a trusted third party to handle the auction process.This imposes the risk of single point of failures, monopoly, and bribery. In this paper, we aim to tackle thisproblem by proposing a novel decentralized and trustless framework for iterative double auction based onblockchain. Our design adopts the smart contract and state channel technologies to enable a double auctionprocess among parties that do not need to trust each other, while minimizing the blockchain transactions.In specific, we propose an extension to the original concept of state channels that can support multipartycomputation. Then we provide a formal development of the proposed framework and prove the security of ourdesign against adversaries. Finally, we develop a proof-of-concept implementation of our framework usingElixir and Solidity, on which we conduct various experiments to demonstrate its feasibility and practicality.CCS Concepts: •
Security and privacy → Software and application security ; Distributed systemssecurity ; •
Computer systems organization → Peer-to-peer architectures .Additional Key Words and Phrases: iterative double auction, blockchain, state channel, trustless
ACM Reference Format:
Truc D. T. Nguyen and My T. Thai. 2020. A Blockchain-based Iterative Double Auction Protocol using MultipartyState Channels.
ACM Trans. Internet Technol.
1, 1, Article 1 (January 2020), 23 pages. https://doi.org/10.1145/3389249
Blockchain, the technology that underpins the great success of Bitcoin [18] and various othercryptocurrencies, has incredibly emerged as a trending research topic in both academic institutesand industries associations in recent years. With great potential and benefits, the blockchaintechnology promises a new decentralized platform for the economy such that the possibility ofcensorship, monopoly, and single point of failures can be eliminated [26]. The technology, in itssimplest form, can be seen as a decentralized database or digital ledger that contains append-onlydata blocks where each block is comprised of valid transactions, timestamp and the cryptographichash of the previous block. By design, a blockchain system is managed by nodes in a peer-to-peernetwork and operates efficiently in a decentralized fashion without the need of a central authority.Specifically, it enables a trustless network where participants of the system can settle transactionswithout having to trust each other. With the aid of the smart contracts technology, a blockchain ∗ My T. Thai is the corresponding author.Authors’ addresses: Truc D. T. Nguyen, [email protected], University of Florida, Gainesville, Florida, 32611; My T. Thai,[email protected], University of Florida, Gainesville, Florida, 32611.Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without feeprovided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice andthe full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored.Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requiresprior specific permission and/or a fee. Request permissions from [email protected].© 2020 Association for Computing Machinery.1533-5399/2020/1-ART1 $15.00https://doi.org/10.1145/3389249 ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. a r X i v : . [ c s . CR ] J u l :2 Truc D. T. Nguyen and My T. Thai system can enable a wide range of applications that go beyond financial transactions [29]. In thecontext of blockchain, smart contracts are defined as self-executing and self-enforcing programsthat are stored on chain. They are intended to facilitate and verify the execution of terms andconditions of a contract within the blockchain system. By employing this technology, applicationsthat previously require a trusted intermediary can now operate in a decentralized manner whileachieving the same functionality and certainty. For that reason, blockchain and smart contractstogether have inspired many decentralized applications and stimulated scientific research in diversedomains [1, 2, 4, 14, 19, 20, 22].An auction is a market institution in which traders or parties submit bids that can be an offerto buy or sell at a given price [9]. A market can enable only buyers, only sellers, or both to makeoffers. In the latter case, it is referred as a two-sided or double auction . A double auction processcan be one-shot or iterative (repeated). The difference between them is that an iterative doubleauction process has multiple, instead of one, iterations [21]. In each iteration, each party submits abid illustrating the selling/buying price and supplying/demanding units of resource. This processgoes on until the market reaches Nash Equilibrium (NE). In practice, the iterative double auctionhas been widely used for decentralized resource allocations among rational traders, especiallyfor divisible resources, such as energy trading [8, 14], mobile data offloading [11], or resourceallocation in autonomous networks [12]. In these applications, in each iteration, players submittheir individual bids, respectively, to an auctioneer who later calculates to determine the resourceallocation with respect to the submitted bids. However, current implementations of double auctionsystems require a centralized and trusted auctioneer to regulate the auction process. This results inthe risk of single point of failures, monopoly, and bribery.Although many research work have tried to develop a trading system combining the iterativedouble auction and blockchain [14, 28], nonetheless, they still need a trusted third-party to handlethe auction process. In this work, we leverage blockchain and smart contracts to propose a generalframework for iterative double auction that is completely decentralized and trustless . We arguethat, due to the low throughput of blockchain, a naive and straightforward adoption of blockchainsmart contracts to eliminate the trusted third-party would result in significantly high latencyand transaction fees. To overcome this problem, we adopt the state channel technology [6] withextension to support computation among more than two parties, so that we can enable efficient off-chain execution of decentralized applications without changing the trust assumption. Specifically,we propose a double auction framework operating through a state channel that can be coupled toexisting double auction algorithms to run the auction process efficiently.To demonstrate the feasibility and practicality of our solution, we develop a proof-of-conceptimplementation of the proposed solution. This proof-of-concept is built based on our novel de-velopment framework that can be used to deploy any distributed protocols using blockchain andstate channels, which is also introduced in this paper. Based on the proof-of-concept, we conductexperiments and measure the performance in various aspects, the results suggest that our proposedsolution can carry out a double auction process on blockchain that is both time- and cost-savingwith a relatively small overhead. Contributions.
We summarize our contributions as follows: • We introduce a novel decentralized and trustless framework for iterative double auction basedon blockchain. With this framework, existing double auction algorithms can efficiently runon a blockchain network without suffering the high latency and fees of on-chain transactions. • We enhance the state channel technology, which is currently limited to two participants, tosupport multiparty computation. Based on this enhancement, we present a formal develop-ment of our solution, in which we develop a Universally Composable (UC)-style model [3]
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:3 for the double auction protocol and prove the security properties of our design using thesimulation-based UC framework. • To validate our proposed solution, we develop a proof-of-concept implementation of theframework to demonstrate its feasibility. For this implementation, we also introduce a noveldevelopment framework for distributed computing using blockchain and state channel. Theframework is developed using the Elixir programming language and the system can bedeployed on an Ethereum blockchain [7].
Organization.
The remainder of this paper is organized as follows. The related work is summarizedin Section 2. Section 3 discusses the integration of Blockchain and double auction to establish somesecurity goals for the system. We first present a straw-man design and then provide a high-levelview of our framework. Then, we provide formal security definitions and specifications with adetailed security analysis of our framework in Section 4. Section 5 presents the proof-of-conceptimplementation along with the system evaluation. Finally, Section 6 concludes the paper.
Double auction based on blockchain.
As blockchain is an emerging technology, there has beenmany research work addressing double auction with blockchain. Recently, Thakur et al [27]published a paper on distributed double auction for peer to peer energy trading. The authors usethe McAfee mechanism to process the double auction on smart contracts. In [17], the authorspresented BlockCloud, which is a service-centric blockchain architecture that supports doubleauction. The auction model in this work uses a trade-reduction mechanism. However, the doubleauction mechanism in these work is one-shot and is only applicable to single-unit demands. Forapplications like energy or wireless spectrum allocation, these models greatly limit users’ capabilityto utilize the products [25].In [14] and [28] , the authors propose blockchain-based energy trading using double auction.The auction mechanism is implemented as an iterative process which can be used for divisiblegoods. Although the system presented in these papers employs blockchain, the double auctionprocess is still facilitated by a central entity. The blockchain is only used for settling payments. Ourwork is fundamentally different as we aim to design a framework that can regulate the iterativedouble auction process in a decentralized and trustless fashion.
State channel.
Although there has been many research effort on payment channels [5, 15, 16],the concept of state channel has only emerged in recent years. As payment channel is limited topayment transactions, state channel is a generalization of payment channel in which users canexecute complex smart contracts off-chain while still maintaining the trustless property. Instead ofexecuting the contracts on-chain and having all the transactions validated by every blockchainnodes, the state channel technologies allow users to update the states off-chain with the optionto raise disputes on-chain. Thus, it offers an efficient solution to address the scalability issue ofblockchain systems. Dziembowski et al. [6] is the first work that present formal specifications ofstate channels. However, the authors did not develop any proof-of-concept implementation tovalidate their protocol.One problem with the original concept of state channels is that they only support executionbetween two parties, which is not applicable to our scenario since we are dealing with a system ofmultiple parties. For that reason, based on the work in [6], we extend the state channel technologyto a multiparty state channel that can support computation among multiple users. Our extensionalso provides additional functionalities to handle dynamic changes of system participants. Basedon this multiparty state channel, we design our double auction framework and analyze its securityproperties in the UC model.
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :4 Truc D. T. Nguyen and My T. Thai
In this section, we formally define the double auction model that is used in this work. Moreover,beginning with a straw-man design, we present the high-level design of our framework and itssecurity goals.
We consider a set of parties that are connected to a blockchain network. We divide the set of partiesinto a set B of buyers who require resources from a set S of sellers. These two sets are disjoint. Thedemand of a buyer i ∈ B is denoted as d i and the supply of a seller j ∈ S is denoted as s j . In thiswork, we adopt the auction model proposed in [30], which elicits hidden information about partiesin order to maximize social welfare, as a general iterative double auction process that converges toa Nash Equilibrium (NE).A bid profile of a buyer i ∈ B is denoted as b i = ( β i , x i ) where β i is the buying price per unitof resource and x i is the amount of resource that i wants to buy. Likewise, a bid profile of a seller j ∈ S is denoted as b j = ( α j , y j ) where α j is the selling price per unit of resource and y j is theamount of resource that j wants to supply.The auction process consists of multiple iterations. At an iteration k , the buyers and sellers submittheir bid profiles b ( k ) i and b ( k ) j , respectively, to the auctioneer. Then, a double auction algorithmwill be used to determine the best response b ( k + ) i and b ( k + ) j for the next iteration. This processgoes on until the auction reaches NE, at which the bid demand and supply ( x i , y j ) will converge toan optimal value that maximizes the social welfare. An example of such algorithm can be referredto [30]. The pseudo code for a centralized auctioneer is presented in Algorithm 1. Algorithm 1 k ← while not NE do Receive bid profiles b ( k ) i and b ( k ) j from buyers and sellersCompute best responses b ( k + ) i and b ( k + j ) j Send b ( k + ) i and b ( k + ) j back to sellers and buyersk ← k + 1 end while In this section, we present a design of the trading system. The trading mechanism must meet thefollowing requirements:(a) Decentralized: the auction process is not facilitated by any central middleman(b) Trustless: the parties do not have to trust each other.(c) Non-Cancellation: parties may attempt to prematurely abort from the protocol to avoidpayments. These malicious parties must be financially penalized.Based on the requirements, we will first show a straw-man design of the system which has somedeficiencies in terms of latency and high transaction fee. Then, we will propose a trading systemusing state channels to address those problems.In this system, we deploy a smart contract to the blockchain to regulate the trading process. Priorto placing any bid, all parties must make a deposit to the smart contract. If a party tries to cheat by
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:5
Fig. 1. Auction phase prematurely aborting the trading process, he or she will lose that deposit and the remaining partieswill receive compensation. Therefore, the deposit deters parties from cheating. At the end of thetrading process, these deposits will be returned to the parties.In this straw-man design, the auction process will be executed on-chain, that is, the smartcontract will act as an auctioneer and thus will execute Algorithm 1. As the auction process consistsof multiple iterations, the system will follow the activity diagram in Figure 1 at each iteration.At an iteration k , all buyers and sellers submit their bids b ( k ) i and b ( k ) j , respectively, to the smartcontract. In order to avoid unresponsiveness, a timeout is set for collecting bids. Should any partiesfail to meet this deadline, the system considers that they aborted the process.The smart contract then determines the best response b ( k + ) i and b ( k + j ) j for buyers and sellers,respectively, until the trading system reaches NE. This design works, however, has two maindisadvantages:(1) Transaction latency: each message exchanged between parties and the smart contract istreated as a blockchain transaction which takes time to get committed.(2) High computational complexity on the smart contract which means that the blockchain willrequire high transaction fees.These disadvantages come from the fact that a transaction in a blockchain network has to beconfirmed by all the validators. In other words, with this design, the buyers and sellers are havingthe entire blockchain to process their auction, which is very inefficient and, thus, not practical. Inthe following section, we will propose another design to overcome these issues. As the double auction process involves multiple iterations, state channel [6] is a proper solution toaddress the deficiencies of the straw-man design. Instead of processing the auction on-chain, theparties will be able to update the states of the auction off-chain. Whenever something goes wrong(e.g., some parties try to cheat), the users always have the option of referring back to the blockchain
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :6 Truc D. T. Nguyen and My T. Thai
Fig. 2. Multiparty state channel: overview for the certainty of on-chain transactions. Since the original concept of state channel only supportsthe computation between two parties, in this work, we propose an extension to support multipartycomputation that can work with the double auction. This section illustrates a high-level view ofhow we can conduct a double auction using the multiparty state channel.In the same manner as the straw-man design, the parties deploy a smart contract to the blockchain.However, this smart contract does not regulate the auction process, but instead acts as a judge toresolve disputes. The parties must also make a deposit to this contract prior to the auction. Figure 2illustrates the overview of the operations in the multiparty state channel.After deploying the smart contract, the parties can now begin the auction process in a statechannel . At each iteration k of the auction, we define two operations: (1) collecting bids and (2)determining the best responses. Denoting the set of parties as P = B ∪ S = { p , p , ..., p n } , in thefirst operation, each party broadcasts a blockchain transaction containing its bid b ( k ) p i to all otherparties. Note that this transaction is a valid blockchain transaction and it is only broadcasted locallyamong the parties. Upon receiving that transaction, each party has to verify the transaction’ssignature. After this operation, each party now has the bid profiles of all other parties.Then we move to the second operation of determining the best response. A party will be chosento compute the best responses, in fact, it does not matter who will execute this computation becausethe results will later be verified by other parties. Therefore, this party can be chosen randomlyor based on the amount of deposit to the smart contract. Let p k be the one who carries out thecomputation at iteration k , G k be the result that consists of the best response b ( k + ) p i for each party p i , p k will broadcast a blockchain transaction containing G k to all other parties. Upon receiving thistransaction, each party has to verify the result G k , then signs it and broadcasts another transactioncontaining G k to all other parties. This action means that the party agrees with G k . After this step,each party will have G k together with the signatures of all parties.When the auction process reaches NE, a party will send the final G k together with all thesignatures to the smart contract. The smart contract then verifies the G k and if there is no dispute,the state channel is closed. Finally, the payment will be processed on-chain and the smart contractrefunds the initial deposit to all parties. The entire process is summarized in the sequence diagramin Figure 3.As can be seen, the blockchain is invoked only two times and thus saves tons of transaction feescomparing to the straw-man design. Moreover, as the transactions are not sent to the blockchain,the latency is only limited by the communication network among the parties. We can also seethat the bid profiles are only known among the involving parties, not to the entire blockchain,thus enhances the privacy. In this section, we only provide a very abstract workflow of the system ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:7
Fig. 3. Sequence diagram of the double auction process. Here we single out one party p k to elucidate theinteractions among parties without considering the security and privacy. In the following sections, we provide more detailoperations of the proposed protocol as well as how we ensure the system is secured. Before we present the formal development of our solution, we establish the threat model as well assecurity and privacy goals for our system. In this work, we consider a computationally efficientadversary who can corrupt any subset of parties. By corruption, the attacker can take full controlover a party which includes acquiring the internal state and all the messages destined to that party.Moreover, it can send arbitrary messages on the corrupted party’s behalf.With respect to the adversarial model, we define the security and privacy notions of interest asfollows: • Unforgeability: We use the ECDSA signature scheme which is believed to be unforgeableagainst chosen message attack [13]. This signature scheme is currently being used by theEthereum blockchain [29]. • Non-Repudiation: Once a party has submitted a bid, the system assures that he or she mustnot be able to deny having made the relevant bid. • Public Verifiability: All parties can be publicly verified if they have been following the auctionprotocol correctly. • Robustness: The auction process can tolerate invalid bids and dishonest participants who arenot following the auction protocol correctly.
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :8 Truc D. T. Nguyen and My T. Thai • Input independence: Each party does not see others’ bid before committing to their own. • Liveness: In an optimistic case when all parties are honest, the computation is processedwithin a small amount of time (off-chain messages only). When some parties are corrupted,the computation is completed within a predictable amount of time.
In this section, we describe the ideal functionality of our system that defines how a double auctionprocess is operated using the multiparty state channel technology. We show that the ideal function-ality achieves the security goals. Afterwards, we present the design of our protocol that realizesthe ideal functionality. Finally, a detailed security proof in the UC framework is given.
The entities in our system are modeled as interactive Turing machines that communicate witheach other via a secure and authenticated channel. The system operates in the presence of anadversary A who, upon corruption of a party p , seizes the internal state of p and all the incomingand outgoing packets of p . We denote P = B ∪ S = { p , p , ..., p n } as the set of n parties.We assume that P is known before opening the state channel and |P | ≥
2. The blockchain isrepresented as an append-only ledger L that is managed by a global ideal functionality F L (suchas [6]). The state of F L is defined by the current balance of all accounts and smart contracts’ state;and is publicly visible to all parties. F L supports the functionalities of adding or subtracting one’sbalance. We also denote F ( x ) as retrieving the current value of the state variable x from an idealfunctionality F .We further assume that any message destined to F L can be seen by all parties (in the samemanner as blockchain transactions are publicly visible). For simplicity, we assume that all partieshave enough fund in their accounts for making deposits to the smart contract. Furthermore, eachparty and the ideal functionality will automatically discard any messages originated from a partythat is not in P or the message’s signature is invalid. In this work, we assume a synchronous communication network. We definea round as a unit of time corresponding to the maximum delay needed to transmit an off-chainmessage between a pair of parties. Any modifications on F L and smart contracts take at most ∆ ∈ N rounds, this ∆ reflects the fact that updates on the blockchain are not instant but can becompleted within a predictable amount of time. Furthermore, each party can retrieve the currentstate of F L and smart contracts in one round. One cryptographic primitive that is used in our model is the commit-ment scheme. A commitment scheme consists of two following algorithms ( Com , V r f ) : • Com ( m , r ) : given a message m , random nonce r , returns commitment c • V r f ( c , R ) : given a commitment c , and R ≜ ( m , r ) , where m is a message, r is a random nonce,returns 1 iff c = Com ( m , r ) , otherwise returns 0.We assume that there is no adversary A that can generate a commitment c and the tuples ( m , r ) , ( m ′ , r ′ ) , such that c = Com ( m , r ) = Com ( m ′ , r ′ ) . Simply speaking, a party cannot alter the valueafter they have committed to it. First, we define the ledger’s ideal functionality F L . Based on section 4.1, the F L supports addingand subtracting one’s balance, hence, we give the corresponding definition in Figure 4. ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:9
Functionality F L Store a vector ( x , x , ..., x n ) that denotes the balance of n parties. Adding and subtracting balances. • On input update ( p i , s ) :(1) If s ≥
0, set x i = x i + s (2) If s < x i ≥ − s , set x i = x i + s (3) Otherwise, reply with an error () message and stop. Fig. 4. Ledger’s functionality F L The formal definition of the ideal functionality F auction is presented in Figure 5. As can be seen,it supports the following functionalities: • Open channel • Determine best response • Revocation • Close channelAs indicated in [6], a state channel should be able to guarantee the consensus on creation andclosing. The state channel creation is initiated by receiving a create () message from a party. Thefunctionality then waits for receiving create () from all other parties within 1 + ( n − ) ∆ rounds. Ifthis happens then the functionality removes a deposit from each party’s balance on the blockchain.Since all parties have to send the create () message, we achieve the consensus on creation.Each iteration k of the double auction process starts with receiving the best _ response ( k ) messagefrom a party. Then all parties must submit a commitment of their bids. After that, all parties mustsubmit the true bid that matches with the commitment they sent before. Any party fails to submitin time or does not submit the true bid will be eliminated from the double auction process. Withthe commitment step, one party cannot see the other parties’ bid prior to placing his or her ownbid, this satisfies the Input independence .When one party fails to behave honestly, it will be eliminated from the auction process and willnot receive the deposit back. A party can voluntarily abort an auction process by sending a revoke () message and it will receive the deposit back. Then, the auction can continue with the remainingparties. Therefore, the functionality satisfies the Robustness . Moreover, a malicious party cannotdelay the execution of the protocol for an arbitrary amount of time, because after timeout, theexecution still proceeds. In the best case, when everyone behaves honestly and does not terminatein the middle of the auction process, the computation is processed within O ( ) rounds, otherwise, O ( ∆ ) rounds. Thus, the Liveness is satisfied.In the end, the state channel begins its termination procedure upon receiving a close () messagefrom a party. Next, it awaits obtaining the close () messages from the remaining parties within1 + (|P | − ∆ rounds. If all the parties are unanimous in closing the state channel, the functionalityreturns the deposit back to all parties’ account. Otherwise, the state channel remains open. As allparties have to send the close () message to close the state channel, we achieve the consensus onclosing. This section discusses in details the double auction protocol based on state channel that realizesthe F auction . The protocol includes two main parts: 1) a Judge contact and 2) Off-chain protocol. ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :10 Truc D. T. Nguyen and My T. Thai
Functionality F auction Open channel. • On input create () from p i (1) For each party p j , j (cid:44) i , wait to receive create () . If not receiving after 1 + ( n − ) ∆ roundsthen stop.(2) Otherwise, instruct F L to remove a deposit from each of the party’s account on theblockchain within ∆ rounds.(3) channel = created Determine best response. • On input best _ response ( k ) from p i – Commitment:(1) For each party p i , wait until receiving C ( k ) i = Com ( b ( k ) i , r ( k ) i ) from p i where b ( k ) i is the bidand r ( k ) i is a random nonce.(2) If any party p i fails to submit the commitment within 1 round, remove p i from P thenstop. – Reveal and compute:(1) For each party p i , wait until receiving R ( k ) i = ( b ( k ) i , r ( k ) i ) from p i .(2) If any party p i fails to submit within 1 round or V r f ( C ( k ) i , R ( k ) i ) =
0, remove p i from P then stop.(3) Compute best response G k based on b = { b ( k ) i | p i ∈ P} (4) Send G k to all parties in 1 round. Revocation. • On input revoke () from p i : within ∆ rounds(1) remove p i from P , add the deposit to p i ’s balance on the blockchain Close channel. • On input close () from p i : if p i (cid:60) P then stop. Otherwise:(1) Within 1 + (|P | − ∆ rounds, wait for receiving close () from p j , j (cid:44) i (2) If fails to receive then stop.(3) Else, within ∆ rounds, add the deposit to every party p i ’s balance on the blockchain, where p i ∈ P (4) channel = ⊥ Fig. 5. Ideal functionality F auction Judge contract.
The main functionality of this contract is to regulate the state channel and handledisputes. Every party is able to submit a state that everyone has agreed on to this contract. However,the contract only accepts the state with the highest version number. Once a party submits a state G , the contract will wait for some deadline T for other parties to raise disputes. See Figure 6 forthe functionality of the Judge contract. Note that the contract F Judдe has a state variable channel which indicates whether the channel is opened or not. If the channel is not opened ( channel = ⊥ ),the three functionalities "State submission", "Revocation", and "Close channel" cannot be executed.In the same manner, if the channel is already opened ( channel = created ) then the functionality"Open channel" cannot be executed. ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:11
Contract F Judдe
Open channel. • On input create () from p i : – For each party p j , j (cid:44) i , wait to receive create () . If not receiving after ∆ rounds then stop. – Otherwise: ∗ channel = created . ∗ instruct F L to remove a deposit from each of the party’s account on the blockchainwithin ∆ rounds. ∗ Initialize bestV ersion = − state = ∅ , f laд = ⊥ , the set of parties P State submission. • On input state _ submit ( p r , v , G , proo f ) from p i (1) if p r (cid:44) ⊥ , wait for (|P | − ) ∆ rounds. Then, if it receives state _ submit ( p ′ r , v ′ , G ′ , proo f ′ ) ,such that p ′ r = p r , from all parties except p r and p i , then remove p r from P (2) if v ≤ bestV ersion then stop.(3) Verify the signatures of P on G and verify the state G using proo f . If failed then stop(4) bestV ersion = v (5) state = G (6) f laд = dispute (7) Set f laд = ⊥ after a deadline of T rounds unless bestV ersion is changed. Revocation. • On input revoke () from p i : within ∆ rounds(1) remove p i from P , instruct F L to add the deposit to p i ’s balance on the blockchain Close channel. • On input close () from p i : if p i (cid:60) P then stop. Otherwise:(1) If f laд = dispute then stop.(2) Within 1 + (|P | − ) ∆ rounds, wait for receiving close () from p j , j (cid:44) i (3) If fails to receive then stop.(4) Else, within ∆ rounds, add the deposit to every party p i ’s balance on the blockchain, where p i ∈ P (5) channel = ⊥ Fig. 6. Judge contract
As the contract always maintains the valid state on which all parties have agreed (by verifyingall the signatures), we can publicly verify if all parties are following the protocol. A dishonest partywho attempts to submit an outdated state will be detected as the smart contract is public, that statewould be then overwritten by a more recent state. When the state channel is closed, the contractis now holding the latest state with the final bids of all the parties, and by the immutability ofblockchain, no bidder can deny having made the relevant bid. Therefore, this contract satisfies the
Non-Repudiation and
Public Verifiability goals.
Off-chain protocol .
In this section, we present the off-chain protocol that operates among partiesin a double auction process. In the same manner as F auction , the protocol consists of four parts:(1) Create state channel, (2) Determine best response, (3) Revocation, and (4) Close state channel. ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :12 Truc D. T. Nguyen and My T. Thai
Protocol : Create state channelParty p i : On input create () from environment(1) Send create () to F Judдe and wait for 1 + ( n − ) ∆ rounds.Party p j (cid:44) i : Upon p i sends create () to F Judдe (2) Send create () to F Judдe and wait for ( n − ) ∆ rounds.For each party:(3) If F Judдe ( channel ) = created then outputs created () to the environment. Fig. 7. Protocol : Create state channel
Protocol:
Submit ( p i , p r , v , G ) Party p i (1) If p r = ⊥ and v ≤ F judдe ( bestV ersion ) then stop.(2) Otherwise, construct proo f for G and send state _ submit ( p r , v , G , proo f ) to F Judдe in ∆ rounds.(3) Wait until F judдe ( f laд ) = ⊥ then stop. Party p j (cid:44) i : On F judдe ( f laд ) = dispute (4) If the latest valid state G k has k > F judдe ( bestV ersion ) then construct proo f for G k and send state _ submit (⊥ , k , G k , proo f ) to F Judдe in ∆ rounds.(5) Wait until F judдe ( f laд ) = ⊥ then stop. Fig. 8. Protocol:
Submit
Figure 12 illustrates the connections among these parts as well as the execution order of theprotocol.First, to create a new state channel, the environment sends a message create () to one of theparties. Let’s denote this initiating party as p i . The detailed protocol is shown in Figure 7. p i willsend a create () message to the smart contract F Judдe which will take ∆ rounds to get confirmed onthe blockchain. As this message is visible to the whole network, any p j (cid:44) i can detect this event andalso send a create () message to F Judдe . To detect this event, each p j needs to retrieve the currentstate of blockchain which takes 1 round and as there are n − p j , p i has to wait 1 + ( n − ) ∆ rounds. If all parties agree on creating the state channel, this process will be successful and thechannel will be opened. After that, the smart contract will take a deposit from the account of eachparty.When parties run into dispute, they will have to resolve on-chain. In specific, the procedure Submit () as shown in Figure 8 allows any party to submit the current state to the smart contract.However, as stated above, F Judдe only considers the valid state that has the highest version number.In this procedure, we also define a proo f of a state G . Based on the algorithm used for doubleauction, this proo f is anything that can verify whether the calculation of G in an iteration is corrector not. For example, proo f can be all the valid bids in that iteration. When any party submits a state,the F Judдe will raise the state variable f laд = dispute . Upon detecting this event, other partiescan submit their states if they have higher version numbers. After a deadline of T rounds, if none ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:13
Protocol: Determine best responseParty p i : On input best _ response ( k ) from the environment(1) Broadcast C ( k ) i = Com ( b ( k ) i , r ( k ) i ) to other parties and wait for 1 round. Then go to step 4.Party p j (cid:44) i : On input C ( k ) i from p i (2) Broadcast C ( k ) j = Com ( b ( k ) j , r ( k ) j ) to other parties and wait for 1 round.(3) If there exists a party p l (cid:44) j such that it doesn’t receive C ( k ) l then execute Submit ( p l , k − , G k − ) and stop.Party p i (4) If there exists a party p j such that it doesn’t receive C ( k ) j then execute Submit ( p j , k − , G k − ) and stop.(5) Broadcast R ( k ) i = ( b ( k ) i , r ( k ) i ) to other parties and wait for 1 round. Then go to step 8.Party p j (cid:44) i : On input R ( k ) i from p i (6) Broadcast R ( k ) j = ( b ( k ) j , r ( k ) j ) to other parties and wait for 1 round.(7) If there exists a party p l (cid:44) j such that it doesn’t receive R ( k ) l or V r f ( C ( k ) l , R ( k ) l ) = Submit ( p l , k − , G k − ) and stop.Party p i (8) If there exists a party p j such that it doesn’t receive R ( k ) j or V r f ( C ( k ) j , R ( k ) j ) then execute Submit ( p j , k − , G k − ) and stop.(9) Compute best response G k , siд G k p i = siдn p i ( G k ) and broadcast best _ response ( G k , siд G k p i ) toother parties. Wait for 1 round then go to step 13.Party p j (cid:44) i : On input best _ response ( G k , siд G k p i ) from p i (10) Verify G k (11) If G k is not correct then execute Submit ( p i , k − , G k − ) and stop.(12) Otherwise, let siд G k p j = siдn p j ( G k ) and broadcast veri f ied ( G k , siд G k p j ) to other parties. Thenwait for 1 round. For each party:(13) If there exists a party p l (cid:44) i such that it doesn’t receive veri f ied ( G k , siд G k p l ) then execute Submit ( p l , k − , G k − ) and stop. Fig. 9. Protocol : Determine best response of the parties can submit a newer state, F Judдe will set f laд = ⊥ to conclude the dispute period.Furthermore, we also note that this procedure also supports eliminating any dishonest party thatdoes not follow the protocol by setting the parameter p r to that party. This function requires aunanimous agreement among the remaining honest parties. If a party p i wants to eliminate a party p r , it will need other parties, except p r , to call the Submit () protocol to remove p r from P .Next, in Figure 9, we present the protocol for determining the best response which only consistsof off-chain messages if all the parties are honest. In each iteration k , this process starts when ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :14 Truc D. T. Nguyen and My T. Thai
Protocol : RevocationParty p i : On input revoke () from the environment(1) Send revoke () to F Judдe in ∆ rounds then stop. Party p j (cid:44) i : On changes of F judдe (P) (2) Update the local P with F judдe (P) Fig. 10. Protocol : Revocation
Protocol : Close state channelParty p i : On input close () from environment(1) If F Judдe ( f laд ) = dispute then stop.(2) Send close () to F Judдe and wait for 1 + (|P | − ) ∆ rounds. Then go to step 4Party p j (cid:44) i : Upon p i sends close () to F Judдe (3) Send close () to F Judдe and wait for (|F auction (P)| − ) ∆ rounds.For each party:(4) Wait for ∆ rounds and check if F Judдe ( channel ) = ⊥ then outputs closed () to the environment. Fig. 11. Protocol : Close state channel the environment sends best _ response ( k ) to a party p i . Again, this does not violate the trustlessproperty since p i can be any party chosen at random. First, p i broadcasts the commitment C ( k ) i ofits bid which only takes one round since this is an off-chain message. Other parties upon receivingthis message will also broadcast their commitments. Then, p i proceeds to broadcast the opening R ( k ) i of its bid and hence, other parties upon receiving this R ( k ) i also broadcast their openings. If anyparty refuses to send their bids or sends an invalid bid, other parties will call the Submit procedureto eliminate that dishonest party from the auction process. Thus, that party will lose all the deposit.In practice, one may consider refunding a portion of deposit back to that party. To achieve this,we only need to modify the first line of the functionality "State submission" in F Judдe to return aportion of deposit to p r .During the auction process, some parties may want to abort the auction process. In order toavoid losing the deposit, they must use the Revocation protocol described in Figure 10 to senda revoke () message to F Judдe . In this case, they will get the deposit back in full and be removedfrom the set P . Other parties upon detecting this operation also update their local P to ensure theconsistency.Finally, Figure 11 illustrates the protocol for closing the state channel. One technical point inthis protocol is that we must check whether there is any ongoing dispute. If so then we must notclose the channel. In the same way of opening the channel, a party p i also initiates the request bysending a message close () to the smart contract. Upon detecting this event, other parties may alsosend close () . If all parties agreed on closing the channel, they will get the deposit back. ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:15
Fig. 12. Connections and execution order of the functionalities of the proposed protocol. The "Revocation"functionality can be triggered any time between "Create state channel" and "Close state channel". Any disputeoccurred during the "Determine best response" requires a call to the "Submit" functionality.
In this section, we prove the security of our solution in the UC model. We denote EXEC π , A , E asthe outputs of the environment E when interacting with the parties running the protocol π andthe adversary A . From [15], we have the following definition: Definition 4.1 (UC-security).
A protocol π UC-realizes an ideal functionality F if for any adver-sarial A , there exists a simulator S such that for any environment E the outputs EXEC π , A , E andEXEC F , S , E are computationally indistinguishableThe main goal of this analysis is to prove that the off-chain protocol UC-realizes the idealfunctionality F auction by constructing a simulator S in the ideal world that translates everyattacker in the real world, such that the two worlds are indistinguishable. To achieve that, we needto ensure the consistency of timings, i. e., the environment E must receive the same message in thesame round in both worlds. Furthermore, in any round, the internal state of each party must beidentical between the two worlds, which will make E unable to perceive whether it is interactingwith the real world or the ideal one.Per Canetti [3], the strategy for proving the UC-security is constructing the simulator S thathandles the corrupted parties and simulates the (F judдe , F L ) -hybrid world while interacting with F auction . The simulator will maintain a copy of the hybrid world internally so that it can turn everybehavior in the hybrid world into an indistinguishable one in the real world. We further assume thatupon receiving a message from a party, the ideal functionality F auction will leak that message tothe simulator. For simplicity, we do not elaborate these operations when constructing the simulator.Since S locally runs a copy of the hybrid world, S knows the behavior of the corrupted parties andthe messages sent from A to F Judдe , therefore, S can instruct the F auction to update the ledger L in the same manner as the hybrid word.In specification of the off-chain protocol, the protocol Submit in Figure 8 is called as a sub-routineof the protocol Determine best response in Figure 9. Hence, we first define a simulator for theprotocol Submit by proving the following lemma:Lemma 4.2. Under the assumptions given in section 4.1, we can construct a simulator for the protocolSubmit in the ideal world such that the view of E remains the same in both the ideal world and the (F judдe , F L ) -hybrid world. Proof. Let p i be the party that calls the Submit () protocol, we define S _ Submit () as the simulatorof the protocol Submit () . If p i is corrupted, upon p i sends state _ submit ( p r , v , G , proo f ) to F Judдe
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :16 Truc D. T. Nguyen and My T. Thai (1) S _ Submit () waits for ∆ rounds. If p r = ⊥ then stop.(2) Otherwise, S _ Submit () waits for (|P | − ) ∆ rounds(3) If all parties p j (cid:44) { i , r } send state _ submit ( p r , v , G , proo f ) to F Judдe then instruct F auction toremove p r from P .If p j (cid:44) i is corrupted, S _ Submit () also updates its P in the same round as the real world if F Judдe updates P .Since the protocol Submit () can potentially change the internal state of the F judдe and the partiesby removing a party from P , the S _ Submit () ensures that F auction also performs the same operationin the same round. Hence, the view of both worlds are consistent. □ Finally, we prove the following theorem:Theorem 4.3.
Under the assumptions given in section 4.1, the proposed off-chain protocol UC-realizesthe ideal functionality F auction in the (F judдe , F L ) -hybrid model. Proof. We provide the description of S for each of the functionalities as follows. Open channel.
Let p i be the party that initiates the request. We inspect the following cases: • p i is corrupted: Upon p i sends create () to F Judдe (1) S waits for ∆ rounds(2) Then sends create () to F auction to make sure that F auction receives create () in the sameround as F Judдe . Then wait for 1 + ( n − ) ∆ rounds(3) if F auction ( channel ) = created then sends created () to E on behalf of p i . • p j (cid:44) i is corrupted: Upon p i sends create () to F auction (1) S waits for ∆ rounds(2) If p j sends create () to F Judдe then S sends create () to F auction and wait for ( n − ) ∆ rounds(3) if F auction ( channel ) = created then sends created () to E on behalf of p j In all cases above, according to Figure 7, p i or p j will output created () to E if F auction ( channel ) = created . Hence, S also outputs created () in the same round. Therefore, the environment E receivesthe same outputs in the same round in both worlds. Close channel.
Let p i be the party that initiates the request. We inspect the following cases: • p i is corrupted : Upon p i sends close () to F Judдe (1) if F judдe ( f laд ) = dispute then stop. Otherwise, S waits for ∆ rounds(2) Then sends close () to F auction to make sure that F auction receives close () in the same roundas F Judдe . Then wait for 1 + (F auction (|P |) − ) ∆ rounds(3) Wait for another ∆ round and check if F auction ( channel ) = ⊥ then sends close () to E onbehalf of p i . • p j (cid:44) i is corrupted: Upon p i sends close () to F auction (1) S waits for ∆ rounds(2) If p j sends close () to F Judдe then S sends close () to F auction and wait for (|F auction (P)|− ) ∆ rounds(3) Wait for another ∆ round and check if F auction ( channel ) = ⊥ then sends closed () to E onbehalf of p j .The indistinguishability in the view of E between the two worlds holds in the same manner as Open channel . Revocation.
Let p i be the party that initiates the request. We inspect the following cases: • p i is corrupted : Upon p i sends revoke () to F Judдe (1) S waits for ∆ rounds ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:17 (2) Then sends revoke () to F auction to make sure that F auction receives revoke () in the sameround as F Judдe . • p j (cid:44) i is corrupted: Upon p i sends revoke () to F auction (1) If p j updates the local P then S also updates its P .In both cases, S ensures that the messages exchanged between the entities are identical in bothworlds. Moreover, since P is updated according to the real world, thus the internal state of the eachparty are also identical. Therefore, the view of E between the two worlds are indistinguishable. Determine best response.
Based on lemma 4.2, we define S _ Submit () as the simulator of theprotocol Submit () in the ideal world. Let p i be the party that calculates the best responses. In eachiteration k , we inspect the following cases: • p i is corrupted: Upon p i broadcasts C ( k ) i to other parties(1) Send C ( k ) i to F auction and wait for 1 round.(2) If F auction removes any party then stop. If p i executes the Submit () then S also calls the S _ Submit () in the same round.(3) Otherwise, if p i broadcasts R ( k ) i to other parties then S sends R ( k ) i to F auction and waits for1 round. Else, stop.(4) If F auction removes any party then stop. If p i executes the Submit () then S also calls the S _ Submit () in the same round. Otherwise, wait for 1 round(5) Receive G k from F auction and wait for 1 round.(6) If p i executes the Submit () then S also calls the S _ Submit () in the same round. Otherwise,stop. • p j (cid:44) i is corrupted: Upon p i sends best _ response ( k ) to F auction (1) Wait until p i sends C ( k ) i to F auction , then forwards that C ( k ) i to p j in the same round.(2) If p j broadcasts C ( k ) j to other parties then S sends C ( k ) j to F auction . Else, execute S _ Submit () to eliminate the party that made p j refuse to broadcast and stop.(3) Wait for 1 round. If p i sends R ( k ) i to F auction , then forwards that R ( k ) i to p j in the sameround. Otherwise, stop.(4) If p j broadcasts R ( k ) j to other parties then S sends R ( k ) j to F auction . Else, execute S _ Submit () to eliminate the party that made p j refuse to broadcast and stop.(5) Wait for 1 round, if S doesn’t receive G k from F auction then stop. Otherwise, S forwardsthat G k to p j .(6) If p j executes the Submit () then S also calls the S _ Submit () in the same round. Otherwise,stop.Since the messages exchanged between any entities are exact in both worlds, the indistinguisha-bility in the view of E between the two worlds holds. □ In this section, we present an evaluation of our proposed double auction framework by runningsome experiments on a proof-of-concept implementation. Before that, we introduce our noveldevelopment framework for distributed computing on state channels.
To the best of our knowledge, this is the first work that builds a functioning programming frameworkthat can be used to deploy any distributed protocols using blockchain and state channels. We use
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :18 Truc D. T. Nguyen and My T. Thai the Elixir programming language to implement the protocol for the participating parties that runon Erlang virtual machines (EVM). The smart contract for the state channel is implemented usingthe Solidity programming language, which is the official language for realizing smart contracts onEthereum. Hence, the whole system can be deployed on an Ethereum blockchain.The Elixir implementation of the participating parties is designed around the Actor programmingmodel [10]. This model realizes actors as the universal primitive of concurrent computation thatuse message-passing as the communication mechanism. In response to a message, an actor canmake local decisions, send messages to other actors, or dynamically generate more actors. Sinceactors in Elixir are "location transparent", when sending a message, whether the recipient actor ison the same machine or on another machine, the EVM can manage to deliver the message in bothcases. In our framework, each of the parties is treated as a separate actor, and they communicatewith each other using asynchronous message-passing mechanism. Furthermore, in other for theparties to interact with the smart contract, we leverage a remote procedure call protocol encodedin JSON (JSON-RPC) provided by Ethereum. The actors also listen for triggered events (e.g., thechannel is opening) from the smart contract and carry out appropriate action.To develop a distributed computing system using our framework, one would only have to definethe followings:(1) The state of the system at each iteration.(2) The operation to be executed at each iteration.(3) The off-chain messages to be exchanged among the parties of the system.(4) The rule to resolve disputes.To demonstrate the feasibility of this development framework, we use it to develop a proof-of-concept implementation of the proposed double auction protocol in the next section.
We create a proof-of-concept implementation of our proposed double auction protocol using ourdevelopment framework as illustrated above. Our implementation of the Judge contract closelyresembles the protocol from Figure 6, it is developed in the Truffle framework [24], and laterdeployed on an Ethereum testnet managed by Ganache [23]. Our main goal was to illustratethe feasibility and practicality of our off-chain protocols when interacting with the Judge smartcontracts. As regards the commitment scheme, we used the SHA-256 hash function with a randomstring of 64 characters.One crucial evaluation criteria when working with smart contracts on the Ethereum blockchainare costs incurred by transaction fees. In Ethereum, these fees are calculated using a specialunit called "gas", the fee is paid by the sender of a transaction to the miner that validates thattransaction. Transactions in an Ethereum blockchain can provide inputs to and execute smartcontract’s functions. The amount of gas used for each transaction is determined by the amount ofdata it sends and the computational effort that it will take to execute certain operations. In addition,depending on the exchange rate between gas and ETH (Ethereum’s currency), we can determine thefinal cost in ETH. In practice, this exchange rate is decided by the person who issues transactionsdepending on how much they want to prioritize their transactions in the mining pool. As we areusing the Ganache testnet, in our calculation, we use the default gas price of 1 gas = 2 × − Ether.To deploy the Judge contract, we have to pay 3387400 gas, which corresponds to 0.0677 ETH.Using an exchange rate of 1 ETH = 152.49 USD (as of Nov 2019), the deployment of the contractcosts approximately 10.3 USD. We also note that our proof-of-concept implementation did not aimto optimize the deployment cost since we implement every functionality on a single smart contract.To mitigate this cost, we would only need to transfer all functionalities of the Judge contract into
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:19 (a) Straw-man design (b) Using state channelFig. 13. Cumulative gas consumption over time an external library. Hence, this library only requires one-time deployment, instances of the Judgecontract can refer to this library and re-use its functionalities. Therefore, we can save much of thedeployment cost since we don’t have to re-deploy all the functionalities with each instance of theJudge contract. Thus, in the following section, we disregard this deployment cost when evaluatingthe performance of our system.
For the experiments, we run the system on machines equipped with an Intel Core i7-8550U CPU 1.8GHz and 16 GB of RAM. The mean latency for transmitting a 32-byte message from one party toanother is about 101.2 ms. We assume that, in the beginning, the parties of the system collected thepublic keys of each other. Moreover, each party also created an account on the Ethereum testnet.Since this is a one-time setup procedure, we do not take it into consideration when evaluating oursystem. To receive events from the Judge contract, each party periodically checks for triggeredevents from the Judge contract every 100 ms. To illustrate the double auction process, we follow thesetup of a numerical experiment in [30] that consists of 10 parties in total, in which 6 are buyersand 4 are sellers. The auction process takes a total of 300 iterations to reach NE.First, we implemented the straw-man design as described in Section 3.2. Figure 13a shows thecumulative gas consumption over time. As can be seen, the gas consumption increases linearly withthe iterations. This happens because each iteration requires parties to send on-chain transactionsto the smart contract. In sum, the straw-man design used 121913080 gas, which corresponds to2.44 ETH. This means the design incurs a cost of about 372 USD to carry out the double auctionprocess. Furthermore, if we consider the Ethereum’s block time of 15 seconds per block, it couldtake over 75 minutes to complete the process (assuming that the waiting time in the mining pool isnegligible).Next, we run the double auction on our proof-of-concept implementation. If all the partiesunanimously agree to create the state channel, they need to issue 10 on-chain transactions thatcost about 0.0117 ETH (each party needs to send 1 transaction to the smart contract). For closingthe state channel, they need another 10 transactions that cost about 0.0109 ETH. The whole doubleauction process is executed off-chain and doesn’t cost any gas or ETH. In Figure 13b, which showsthe cumulative gas consumption over time, we can observe that only the first and last iterationincurs some amount of gas to create and close the state channel, respectively. As a result, the
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :20 Truc D. T. Nguyen and My T. Thai
Table 1. The estimated costs for executing the transactions as well as the message complexity of the proposeddouble auction protocol when running with 10 parties. state _ submit function of the Judge contract, this costs about 52845 gas. After that,another party would submit a more recent state that can overwrite that outdated state, this costsanother 52845 gas. Consequently, the cost for settling a disagreement would be about 0.0021 ETHfor both the dishonest and honest party.Another scenario that is worth looking into is the dynamic leave of parties. The two casessupported by our system are (1) eliminating dishonest parties and (2) voluntarily aborting theauction process. In the former case, when eliminating a party via the state _ submit function, itrequires 9 on-chain transactions that cost a total of 0.0122 ETH. In the latter case, using theRevocation protocol, only the leaving party needs to issue a transaction that costs about 0.0011ETH.To analyze the execution cost, we focus on the cost of computing digital signatures and messagecomplexity since these are additional work that the parties have to perform apart from computingbest responses. As in the protocol design, in each iteration, each party has to sign the current stateand broadcast it to all other parties. A state of an iteration is defined as the list of parties’ bestresponses and it is about 80 bytes (each party’s bid profile is 8 bytes). The time it takes to sign thestate is about 1.4 ms and to verify the signature is about 0.8 ms. As for broadcasting bids amongparties, a commitment of 32 bytes (using SHA-256 hash function) is sent and later accompaniedby the opening of 72 bytes (including the bid and the random string). This incurs a total of 270off-chain messages that are transmitted per iteration with the total size of 23 KB. If we consider thewhole auction process that involves 300 iterations, the total size of the messages transmitted amongthe parties is only 6.9 MB. This emphasizes the practicality of our proposed solution because oflow transmission overhead.Finally, we measure the end-to-end latency of the auction process. For the creating and closingstate channel, each will take one block time (i.e., about 15 seconds in Ethereum). The 300 iterationsof determining best responses takes only about 8.3 minutes. To test the scalability, we observehow the system latency changes when we increase the number of parties. For a fair comparison,we fix the number of iterations for the double auction process to 300. In Figure 14a, we show theend-to-end latency with 10, 40, 70, and 100 parties. The total time to create and close the statechannel remains the same because each operation only needs one block time as a block in Ethereumcan store about 380 transactions. When we increase the number of parties to 40, the system needs833.4 seconds to finish the auction process. The rise in the latency comes from the fact that the size ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:21 (a) (b)Fig. 14. End-to-end latency of the state at each iteration increases (from 80 bytes to 320 bytes), hence, it takes longer to transmitthe state as well as to compute the digital signatures. However, we note that with 40 parties, thislatency is only 1.6 times as much as the latency with 10 parties. Likewise, when we increase thenumber of parties by 9 times (to 100 parties), the latency only increases by 2.9 times. Therefore, wecan see that the proposed solution is able to scale with the number of parties.To better capture the performance of our system under heavy load, Figure 14b illustrates theend-to-end delay with thousands of trading parties over 300 iterations. For creating and closingstate channel, it would take 6, 12, 16, 22, and 28 block time with 1000, 2000, 3000, 4000, and 5000parties, respectively. As can be seen, the latency increases linearly with the number of parties.Under this load, the size of the state reaches 40000 bytes at 5000 parties, and the end-to-end latencyis dominated by the time it takes to transmit the state at each iteration. Therefore, the performanceof our system is only limited by the underlying communication channel.In summary, the proof-of-concept implementation has demonstrated that our solution is bothfeasible and practical, all the functionalities work according to the design in Section 4. Withcomparison to the straw-man design, our implementation has resulted in a gigantic saving ofmoney and time. Moreover, as the proposed solution induces a relatively small overhead, it is ablesupport a high number of trading parties.
In this paper, we have proposed a novel framework based on blockchain that enables a completedecentralized and trustless iterative double auction. That is, all parties can participate in the auctionprocess without having to rely on an auctioneer and they do not have to trust one another. Withan extension of the state channel technology, we were able to specify a protocol that reduces theblockchain transactions to avoid high transaction fee and latency. We have provided a formalspecification of the framework and our protocol was proven to be secured in the UC model. Finally,we have developed a proof-of-concept implementation and perform experiments to validate thefeasibility and practicality of our solution.
ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020. :22 Truc D. T. Nguyen and My T. Thai
REFERENCES [1] Nurzhan Zhumabekuly Aitzhan and Davor Svetinovic. 2016. Security and privacy in decentralized energy tradingthrough multi-signatures, blockchain and anonymous messaging streams.
IEEE Transactions on Dependable and SecureComputing (2016).[2] Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. 2016. Medrec: Using blockchain for medical dataaccess and permission management. In
Open and Big Data (OBD), International Conference on . IEEE, 25–30.[3] Ran Canetti. 2001. Universally composable security: A new paradigm for cryptographic protocols. In
Proceedings 2001IEEE International Conference on Cluster Computing . IEEE, 136–145.[4] Thang N Dinh and My T Thai. 2018. Ai and blockchain: A disruptive integration.
Computer
51, 9 (2018), 48–53.[5] Stefan Dziembowski, Lisa Eckey, Sebastian Faust, and Daniel Malinowski. 2019. Perun: Virtual payment hubs overcryptocurrencies. In . IEEE, 106–123.[6] Stefan Dziembowski, Sebastian Faust, and Kristina Hostáková. 2018. General State Channel Networks. In
Proceedingsof the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18) . ACM, New York, NY, USA,949–966. https://doi.org/10.1145/3243734.3243856[7] Ethereum. [n. d.]. ethereum/sharding. https://github.com/ethereum/sharding/blob/develop/docs/doc.md[8] M Nazif Faqiry and Sanjoy Das. 2016. Double-sided energy auction in microgrid: Equilibrium under price anticipation.
IEEE Access
The Double Auction Market: Institutions, Theories,and Evidence (1993), 3–25.[10] C Hewitt, P Bishop, and R Steiger. 1973. A Universal Modular Actor Formalism for Artificial Intelligence. IJCAI3. In
Proceedings of the 3rd International Joint Conference on Artificial Intelligence . 235–245.[11] George Iosifidis, Lin Gao, Jianwei Huang, and Leandros Tassiulas. 2013. An iterative double auction for mobile dataoffloading. In . IEEE, 154–161.[12] George Iosifidis and Iordanis Koutsopoulos. 2010. Double auction mechanisms for resource allocation in autonomousnetworks.
IEEE Journal on Selected Areas in Communications
28, 1 (2010).[13] Don Johnson, Alfred Menezes, and Scott Vanstone. 2001. The elliptic curve digital signature algorithm (ECDSA).
International journal of information security
1, 1 (2001), 36–63.[14] Jiawen Kang, Rong Yu, Xumin Huang, Sabita Maharjan, Yan Zhang, and Ekram Hossain. 2017. Enabling localizedpeer-to-peer electricity trading among plug-in hybrid electric vehicles using consortium blockchains.
IEEE Transactionson Industrial Informatics
13, 6 (2017), 3154–3164.[15] Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency andprivacy with payment-channel networks. In
Proceedings of the 2017 ACM SIGSAC Conference on Computer and Commu-nications Security . ACM, 455–471.[16] Andrew Miller, Iddo Bentov, Ranjit Kumaresan, and Patrick McCorry. 2019. Sprites and state channels: Paymentnetworks that go faster than lightning.
Financial Cryptography and Data Security (2019).[17] Zhongxing Ming, Shu Yang, Qi Li, Dan Wang, Mingwei Xu, Ke Xu, and Laizhong Cui. [n. d.]. Blockcloud: A Blockchain-based Service-centric Network Stack. ([n. d.]).[18] Satoshi Nakamoto. 2008. Bitcoin: A peer-to-peer electronic cash system. (2008).[19] Lan N Nguyen, Truc DT Nguyen, Thang N Dinh, and My T Thai. 2019. OptChain: Optimal Transactions Placement forScalable Blockchain Sharding. In .IEEE, 525–535.[20] Truc DT Nguyen, Hoang-Anh Pham, and My T Thai. 2018. Leveraging Blockchain to Enhance Data Privacy inIoT-Based Applications. In
International Conference on Computational Social Networks . Springer, 211–221.[21] Simon Parsons, Marek Marcinkiewicz, Jinzhong Niu, and Steve Phelps. 2006. Everything you wanted to know aboutdouble auctions, but were afraid to (bid or) ask. (2006).[22] Muhammad Saad, Victor Cook, Lan Nguyen, My T Thai, and Aziz Mohaisen. 2019. Partitioning Attacks on Bitcoin:Colliding Space, Time, and Logic. In
Personal andubiquitous computing
18, 4 (2014), 939–950.[26] Melanie Swan. 2015.
Blockchain: Blueprint for a new economy . " O’Reilly Media, Inc.".[27] Subhasis Thakur, Barry P Hayes, and John G Breslin. 2018. Distributed double auction for peer to peer energy tradeusing blockchains. In .ACM Trans. Internet Technol., Vol. 1, No. 1, Article 1. Publication date: January 2020.
Blockchain-based Iterative Double Auction Protocol using Multiparty State Channels 1:23
IEEE, 1–8.[28] Jian Wang, Qianggang Wang, and Niancheng Zhou. 2018. A Decentralized Electricity Transaction Mode of MicrogridBased on Blockchain and Continuous Double Auction. In .IEEE, 1–5.[29] Gavin Wood. 2014. Ethereum: A secure decentralised generalised transaction ledger.
Ethereum project yellow paper