Speedster A TEE-assisted State Channel System

Jinghui Liao1 Fengwei Zhang2 3 Wenhai Sun4 Weisong Shi11Department of Computer Science Wayne State University

2Department of Computer Science and Engineering Southern University of Science and Technology3Research Institute of Trustworthy Autonomous Systems Southern University of Science and Technology

4Department of Computer and Information Technology Purdue Universityjinghuiwayneedu zhangfwsustecheducn whsunpurdueedu weisongwayneedu

ABSTRACT

State channel network is the most popular layer-2 solution to theissues of scalability high transaction fees and low transactionthroughput of public Blockchain networks However the existingworks have limitations that curb the wide adoption of the tech-nology such as the expensive creation and closure of channelsstrict synchronization between the main chain and off-chain chan-nels frozen deposits and inability to execute multi-party smartcontracts

In this work we present Speedster an account-based state-channel system that aims to address the above issues To this endSpeedster leverages the latest development of secure hardwareto create dispute-free certified channels that can be operated effi-ciently off the Blockchain Speedster is fully decentralized andprovides better privacy protection It supports fast native multi-party contract execution which is missing in prior TEE-enabledchannel networks Compared to the Lightning Network Speedsterimproves the throughput by about 10 000times and generates 97 lesson-chain data with a comparable network scale

KEYWORDS

Multi-party State Channel Layer-2 Scalability Offchain SmartContracts

1 INTRODUCTION

Blockchain (aka layer-1 main chain) has been deemed a disruptivetechnology to build decentralized trust and foster innovative ap-plications in both public and private sectors However scalabilityhas become a great concern in practice when adopting the decen-tralized infrastructure For example the Bitcoin network [79] canonly handle approximately 3 500 transactions in every new blockdue to the block size limitation [18] and process 7 transactions persecond (119905119901119904) on average [19 79] The issue has also haunted othermajor Blockchain networks which are based on a similar designprinciple such as Ethereum [25] Modifying the on-chain protocolshelps alleviate the problem for instance using alternative consen-sus algorithms [77] and improving the information propagation[67 99] Nevertheless changes at layer-1 Blockchain level may ad-versely affect the existing participants with undesired costs [45 60]Shifting to layer-2 payment channels [24 66 76 82] is consideredan effective remedy by carrying out micropayment transactionsoff the Blockchain to avoid the expensive on-chain overhead Statechannels [1 41 76] further advances this off-chain innovation by

Fengwei Zhang is the corresponding author

enabling stateful transactions and smart contract execution Promis-ing as it is the state channel also has the following limitations

(L1) Opening a new channel needs to freeze the deposit of chan-nel participants during the whole life cycle of the channel whichsignificantly affects the liquidity and network effectiveness Everytime a channel is created or closed an associated transaction isrequired to signal the main chain thus incurring additional transac-tion fees and waiting time for block confirmation [1 63 66 76 82]

(L2) The current dispute resolution in the state channel is notrobust and vulnerable to the denial-of-service (DoS) attack A ma-licious channel participant can send an outdated channel state tothe Blockchain while DoS-ing the victim to prevent the submissionof the lasted channel state

(L3) With the help of Hashed Timelock Contract (HTLC) [66]the architectural complexity is reduced and multi-hop transactionbecomes feasible in the state channel network However HTLCalso raises many privacy concerns with the intermediate nodes [3949 50 68] and leads to a multitude of attacks such as wormholeattacks [69] bribery attacks [90] and DoS attacks [58 87]

(L4) Despite the ambition of the instant processing of off-chaintransactions [66] the complex routing and state updating mecha-nisms give rise to a non-negligible overhead thus considerably de-grading promised performance The actual throughput of the statechannels is still unsatisfactory (tens of 119905119901119904 measured in [39 64 76])

(L5) The state exchange is confined within a pairwise chan-nel which poses fundamental challenges for creating and execut-ing multi-party smart contracts Though a multi-party state chan-nel can be recursively established using the virtual channel tech-niques [30 38 39] the associated expensive cost is still a concernfor implementation

Technical contributions We present Speedster to ad-dress the above limitations The main idea of Speedster is thatevery user creates and funds an off-chain account protected by theenclave an instance of a Trusted Execution Environment (TEE)As Speedster transfers the on-chain trust with the Blockchainto the off-chain trust with enclaves we significantly reduce thedesign complexity to accomplish a plethora of innovations suchas multi-party channels and lightweight protocols for channelconfidentiality authenticity finalization and dispute resolutionSpeedster outperforms the conventional state channel networksin terms of security performance and functionality

In Speedster a node does not need to send on-chain transactionto openclose a channel Only one deposit transaction is neededto initialize a TEE-enabled account for each off-chain participant

arX

iv2

104

0128

9v1

[cs

CR

] 3

Apr

202

1

Later a participating node can directly createclose channels withany other nodes completely off the main chain with the balance intheir enclave accounts Therefore Speedster is a fully decentralizedstate channel network that enjoys instant channel creationclosureand enhanced privacy by eliminating HTLC-based multi-hoppingand routing [58 69 87 90]

Speedster adopts a novel certificate-based off-chain transactionprocessing model where the channel state is retained in the enclaveSpeedster modifies the state before sending out or after receivingtransactions to make sure the state submitted to the Blockchainis always up to date As a result an attacker cannot roll back toold states by DoS-ing counterparts and fool the Blockchain into abiased decision

Off-chain multi-party smart contracts can be enabled and effi-ciently executed in Speedster With the certificate-based channelsSpeedster naturally supports interactions among multiple partiesThe state information can be correctly exchanged across multiplechannels of the same account

By leveraging the off-chain enclave trust Speedster replacesthe costly public-key algorithms with efficient symmetric-key op-erations for transaction generation and verification Experimentalresults show that Speedster increases the throughput by four or-ders of magnitude compared to the Lightning Network the mostpopular payment channel network in practice

Evaluation

Speedster is intentionally designed to be compatible with dif-ferent major TEE platforms for availability and usability such asAMD [4] Intel [75] and ARM [10] We evaluate its cross-platformperformance to show the advantage over other popular layer-2 de-signs Specifically wemigrate eEVM [31] a full version of EthereumVirtual Machine (EVM) [42] into Speedster and execute unmodi-fied Ethereum smart contracts off-chain We develop a set of bench-mark contracts to show the unique features and performance ofSpeedster Through thorough experiments we present the spec-ification for running Speedster the much-improved transactionthroughput and the capability of executing different kinds of smartcontracts that traditional state channels cannot support The exper-iments include

bull Transaction load test To test the transaction throughputdirectly between two parties without loading any smart con-tractbull Instant state sharing Participants can update and share theirstates instantly this is an important performance indicatorfor time-sensitive applications such as racing games anddecentralized financial servicesbull ERC20 contracts To show the performance of off-chain fundexchangebull Gomoku contract To show the performance of the turn-based contractsbull Paper-Scissors-Rock contract To illustrate the fairness (forin-parallel execution) in Speedster channelbull Monopoly contract To test the multi-party state channelcapability of Speedster we load a Monopoly smart contractthat is executed by four players alternately

The evaluation results show that Speedster is efficient and takesonly 002119898119904 014119898119904 and 2049119898119904 to process a value-transfer trans-action on Intel AMD and ARM platforms respectively which leadsto much higher throughput than that of Lightning network Thesource code of Speedster is available at httpsbitly3a32ju7

2 BACKGROUND

In this section we provide the background of the technologies thatwe use in our system

21 Blockchain and Smart Contract

Blockchain is a distributed ledger that leverages cryptography tomaintain a transparent immutable and verifiable transaction record[25 79] In contrast to the permissioned Blockchain [7 86] per-missionless Blockchain [95] is publicly accessible but constrainedby the inefficient consensus protocols such as the Nakamoto con-sensus in Bitcoin [55 79] on top of the asynchronous networkinfrastructure which leads to a series of performance bottlenecksin practice See [47 84 91 102] for detailed discussion

Smart contracts in Blockchain complement the ledger functionsby providing essential computations In general a smart contractis a program that is stored as a transaction on the BlockchainOnce being called the contract will be executed by all the nodesin the network The whole network will verify the computationresult through consensus protocols thus creating a fair and trust-less environment to foster a range of novel decentralized appli-cations [73 103] A well-known example is the Ethereum smartcontract [25 26] which runs inside the EVM [42] EVM needs to beset up on every full Ethereum node to create an isolated environ-ment from the network file system and IO services for contractexecution The user transactions will be taken as input to the con-tract inside the EVM

22 Layer-2 Channels

Layer-2 technologies are proposed to address the scalability con-cerns [97] short storage for historical transactions [96] etc forthe layer-1 Blockchain

Payment channel is the first attempt to use an off-chain infras-tructure to process micropayments between two parties withoutfrequent main chain involvement To create a channel each partyneeds to send a transaction to the Blockchain to lock in a certainamount of deposit on the main chain until a transaction is issuedlater to close the channel When the channel is open transactionscan be sent back and forth between participants as long as they donot surpass the committed channel capacity

Payment channel network (PCN) is built on top of the individualpayment channels to route transactions for any pair of partieswho may not have direct channel connections [58 66 76] HashedTimelock Contract is exploited to guarantee balance security alongthe payment route ie the balances of the involved nodes arechanged in compliance with the prescribed agreement PCN greatlyrelieves the users from costly channel creation and managementbut it also brings up concerns about the privacy with intermediaterouting nodes and the formation of the centrality of the network

2

Later a participating node can directly createclose channels withany other nodes completely off the main chain with the balance intheir enclave accounts Therefore Speedster is a fully decentralizedstate channel network that enjoys instant channel creationclosureand enhanced privacy by eliminating HTLC-based multi-hoppingand routing [58 69 87 90]

Speedster adopts a novel certificate-based off-chain transactionprocessing model where the channel state is retained in the enclaveSpeedster modifies the state before sending out or after receivingtransactions to make sure the state submitted to the Blockchainis always up to date As a result an attacker cannot roll back toold states by DoS-ing counterparts and fool the Blockchain into abiased decision

Off-chain multi-party smart contracts can be enabled and effi-ciently executed in Speedster With the certificate-based channelsSpeedster naturally supports interactions among multiple partiesThe state information can be correctly exchanged across multiplechannels of the same account

By leveraging the off-chain enclave trust Speedster replacesthe costly public-key algorithms with efficient symmetric-key op-erations for transaction generation and verification Experimentalresults show that Speedster increases the throughput by four or-ders of magnitude compared to the Lightning Network the mostpopular payment channel network in practice

Evaluation

Speedster is intentionally designed to be compatible with dif-ferent major TEE platforms for availability and usability such asAMD [4] Intel [75] and ARM [10] We evaluate its cross-platformperformance to show the advantage over other popular layer-2 de-signs Specifically wemigrate eEVM [31] a full version of EthereumVirtual Machine (EVM) [42] into Speedster and execute unmodi-fied Ethereum smart contracts off-chain We develop a set of bench-mark contracts to show the unique features and performance ofSpeedster Through thorough experiments we present the spec-ification for running Speedster the much-improved transactionthroughput and the capability of executing different kinds of smartcontracts that traditional state channels cannot support The exper-iments include

bull Transaction load test To test the transaction throughputdirectly between two parties without loading any smart con-tractbull Instant state sharing Participants can update and share theirstates instantly this is an important performance indicatorfor time-sensitive applications such as racing games anddecentralized financial servicesbull ERC20 contracts To show the performance of off-chain fundexchangebull Gomoku contract To show the performance of the turn-based contractsbull Paper-Scissors-Rock contract To illustrate the fairness (forin-parallel execution) in Speedster channelbull Monopoly contract To test the multi-party state channelcapability of Speedster we load a Monopoly smart contractthat is executed by four players alternately

The evaluation results show that Speedster is efficient and takesonly 002119898119904 014119898119904 and 2049119898119904 to process a value-transfer trans-action on Intel AMD and ARM platforms respectively which leadsto much higher throughput than that of Lightning network Thesource code of Speedster is available at httpsbitly3a32ju7

2 BACKGROUND

In this section we provide the background of the technologies thatwe use in our system

21 Blockchain and Smart Contract

Blockchain is a distributed ledger that leverages cryptography tomaintain a transparent immutable and verifiable transaction record[25 79] In contrast to the permissioned Blockchain [7 86] per-missionless Blockchain [95] is publicly accessible but constrainedby the inefficient consensus protocols such as the Nakamoto con-sensus in Bitcoin [55 79] on top of the asynchronous networkinfrastructure which leads to a series of performance bottlenecksin practice See [47 84 91 102] for detailed discussion

Smart contracts in Blockchain complement the ledger functionsby providing essential computations In general a smart contractis a program that is stored as a transaction on the BlockchainOnce being called the contract will be executed by all the nodesin the network The whole network will verify the computationresult through consensus protocols thus creating a fair and trust-less environment to foster a range of novel decentralized appli-cations [73 103] A well-known example is the Ethereum smartcontract [25 26] which runs inside the EVM [42] EVM needs to beset up on every full Ethereum node to create an isolated environ-ment from the network file system and IO services for contractexecution The user transactions will be taken as input to the con-tract inside the EVM

22 Layer-2 Channels

Layer-2 technologies are proposed to address the scalability con-cerns [97] short storage for historical transactions [96] etc forthe layer-1 Blockchain

Payment channel is the first attempt to use an off-chain infras-tructure to process micropayments between two parties withoutfrequent main chain involvement To create a channel each partyneeds to send a transaction to the Blockchain to lock in a certainamount of deposit on the main chain until a transaction is issuedlater to close the channel When the channel is open transactionscan be sent back and forth between participants as long as they donot surpass the committed channel capacity

Payment channel network (PCN) is built on top of the individualpayment channels to route transactions for any pair of partieswho may not have direct channel connections [58 66 76] HashedTimelock Contract is exploited to guarantee balance security alongthe payment route ie the balances of the involved nodes arechanged in compliance with the prescribed agreement PCN greatlyrelieves the users from costly channel creation and managementbut it also brings up concerns about the privacy with intermediaterouting nodes and the formation of the centrality of the network

2

State channel network extends PCN by allowing for stateful activ-ities such as off-chain smart contract [30 38ndash41] However record-ing and updating states across multiple parties are still expensivedue to the sophisticated trust management and protocol design Forexample the current multi-party state channel [30 38] is realizedthrough recursive virtual channel establishment [39ndash41] whichintroduces non-negligible complexity and overhead

Regardless of the technical differences of the above layer-2 tech-nologies they all need to involve the inefficient Blockchain forchannel creation closure or dispute resolution Moreover privacyand instability [87] concerns also arise and hamper the wide adop-tion of those technologies

23 Trusted Execution Environment

Trusted Execution Environment provides a secure isolated envi-ronment (or enclave) in a computer system to execute programswith sensitive data Enclave protects the data and code insideagainst inference and manipulation by other programs outsidethe trusted computing base (TCB) Intel Software Guard eXten-sions (SGX) [6 51 75] and AMD Secure Encrypted Virtualization(SEV) [5 57] are two popular general-purpose hardware-assistedTEEs developed for the x86 architecture Precisely the TCB ofSGX is a set of new processor instructions and data structuresthat are introduced to support the execution of the enclave TheTCB of AMD SEV is the SEV-enabled virtual machine protected byan embedded 32-bit microcontroller (ARM Cortex-A5) [57] Otherprominent TEE examples include TrustZone [10] and CCA [9] onARM MultiZone [46] and KeyStone [62] on RISC-V and AppleSecure Enclave in T2 chip [8] To demonstrate the cross-platformcapability of Speedster we implement a prototype that can run onIntel AMD and ARM machines and we make Speedster designgeneral enough for other TEE platforms not limited to the testedenvironments

Remote attestation [81] is used to verify the authenticity of theenclave before executing enclave programs Specifically to preventattackers from simulating the enclave a TEE-enabled processor usesa hard-coded root key to cryptographically sign the measurementof the enclave including the initial state code and data Note thateven if one TEE processor sets up multiple enclaves with the sameset of functions their respective measurements will be distinctivelydifferent As such everyone can publicly verify the authenticity ofthe established enclave with help from vendors

3 THREAT MODEL AND DESIGN GOALS

In this section we present the threat model and design goals ofSpeedster

31 Threat Model

We assume that nodes in the system run on TEE-enabled platformsand all parties trust the enclaves after the successful attestation Anadversary may compromise the operating system of a target nodeand further control the systemrsquos software stack

In Speedster we use TEE as a secure abstraction to make the de-sign and security independent of the specific platforms We providerigorous security proofs to show the reliability and robustness ofSpeedster However like any secure function theoretical security

could be compromised by erroneous implementations Thereforeto be consistent with prior work [29 35 64] we additionally con-sider attacks on specific TEE platforms in our implementation forcompleteness which does not indicate the insecurity of the generaldesign of Speedster See Section 6 for the detailed discussion forthe particular platforms

Similar to prior research [30 38ndash41] this work also assumes aBlockchain abstraction to provide desired ledger functions suchas transparent and immutable storage and verifiable computationswith smart contracts Speedster assumes that the Blockchain nodesare equipped with adequate resources for computation and stor-age so that we only concentrate on the off-chain related design(see Section 51 for more discussion on the TEE and Blockchainabstractions)

32 Design Goals

In this subsection we elaborate on the main design goals of Speed-sterEfficient Channel System (L1 L2 L4) The current layer-2 chan-nel system design principle derails from the promised efficiency foroff-chain micropayment processing As discussed in Section 22 theexisting systems need expensive interactions with the Blockchainfor various channel operations in terms of time and economic costsUsers are required to trust the intermediate nodes and pay extrafees for transaction forwarding and state updating

In this work we attempt to devise a functionally efficient off-chain network that aims to significantly reduce the channel costfor creation and closure and eliminate the dispute in light of unsyn-chronized communicationsFully Decentralized Channel Network (L3 L4) Due to the ex-pensive channel cost a node in layer-2 currently cannot afford toestablish direct channel connections with all other nodes in thesystem Multi-hopping addresses the problem but raises privacyconcerns about the emergent centralized payment hubs [39 50 83]which is at odds with the decentralization promise of Blockchain

In contrast we aim to build a fully decentralized channel networkto allow users to freely set up direct channels with intended partiesthus eliminating centrality concerns Note that none of the existingwork can support this function [63 64 66 76]Efficient Multi-Party State Channel (L5) Sharing states amongmultiple parties is instrumental for many real-world applicationssuch as voting auctioning and gaming However most off-chainstate channels only support pairwise state exchange [37 39] Theinvolvement of more channel participants depends on interme-diaries which complicates the network setup and trust manage-ment [30 38]

Speedster targets a more efficient multi-party state channel bystreamlining the architectural design for easy setup and use Thestate information of one Speedster node can be freely shared withother parties of interest without worrying about the additional costin prior workOther Goals Besides Speedster also aims to (1) preserve theprivacy of transactions (see Section 6 for detailed security definitionand analysis) (2) be abstract and general enough to not rely on anyspecific TEE platform

3

enclaveCertified Channel

State(cert0 cert1 119888119896)

Blockchain (contractSpeedster)

P0 P1

prog119890119899119888119897119886119907119890

enclave

prog119890119899119888119897119886119907119890

Figure 1 Framework of Speedster A channel is opened

directly between enclaves of two users Off-chain trans-

actions are processed by prog119890119899119888119897119886119907119890 in the enclave The

contractSpeedster is deployed on the Blockchain to record the

states of the nodes The initial state of the enclave is syn-

chronized from the Blockchain

4 SPEEDSTER DESIGN

In this section we first introduce the architecture of Speedsterand then detail the design

41 System Architecture

Speedster contains two components the state channel core pro-gram prog119890119899119888119897119886119907119890 executed inside the enclave and the on-chain smartcontract contractSpeedster running on the Blockchain Figure 1 showsthe high-level architecture of Speedster in which two participantsare connected by a Certified Channel (see Definition 1)Prog119890119899119888119897119886119907119890 The program runs in the enclave prog119890119899119888119897119886119907119890 createsand manages an enclave account for a Speedster node It executescommands from the user to open and close channels as well asconstructs and processes channel transactions To verify the enclaveauthenticity it also generates measurements for remote attestationContractSpeedster contractSpeedster is a smart contract deployedon the Blockchain to manage the on-chain state of Speedsteraccount To register an account a deposit has to be sent to thiscontract and recorded in the Blockchain Later the information canbe used to initialize the enclave state It also handles transactionsto claim fund for Speedster account

42 Workflow

In this subsection we outline the workflow of Speedster including(1) node initialization (2) enclave state attestation (3) channel keyestablishment (4) channel certification and (5) multi-party statechannel establishment (optional) The workflow is illustrated inFigure 2

Node Initialization In this step an account acc119890119899119888119897119886119907119890 along witha pair of keys pk and sk is opened in the enclave after the programprog119890119899119888119897119886119907119890 is loaded into the enclave for the first time The enclavekeeps sk private and publishes pk as the account address that can beused to deposit acc119890119899119888119897119886119907119890 on the Blockchain To ensure the authen-ticity of the opened account acc119890119899119888119897119886119907119890 for following off-chain attesta-tions an initial deposit transaction needs to be generated to registeracc119890119899119888119897119886119907119890 with the Blockchain After the Blockchain confirms the

(3) Key Establishment

Certified Channel

Terminate

(1)Initialization

Multi-party Channel

E

msg1 = tx

msg2 = 120532att

msg3 = pk

(2) Attestation

ChannelKey

(4) Certify

Initialized State

(5)

fail

Figure 2 Workflow of node initialization and certified chan-

nel creation E is the environment including the Blockchain

and the channel users who pass input to Speedster nodes

transaction the user loads relevant information into the enclave asa registration proof to initialize the enclave state state0 = (tx0 aux0)a tuple that contains the deposit transaction tx0 and auxiliary infor-mation aux0 where tx0 can be more than one deposit and aux0 can bethe current balance or account-related configuration informationFurther deposits are allowed to update the initial state state0

Enclave State Attestation Step 2 is enclave attestation that needsto be carried out to authenticate the enclave environment includingthe state0 Note that we add the initial state state0 and the publickey pk into the enclave measurement 120590119886119905119905 = ΣSig(msk (prog119890119899119888119897119886119907119890 pk state0)) lowast where Σ is a digital signature scheme and msk is themanufacturer-generated secret key for the processor [81]

The initial state reflects the starting point of acc119890119899119888119897119886119907119890 whichshould match the recorded state on the Blockchain If a node passesthe attestation it means that the acc119890119899119888119897119886119907119890 is set up with the correcton-chain deposit and should be trusted for the subsequent off-chaintransactions

Channel Key Establishment Once the enclave account is verifiedthe channel participants start to generate the shared channel key byleveraging any secure two-party key agreement protocols [15 22]

Channel Certification In this step an identifier denoted as ccid =H(119878119874119877119879 (pk0 pk1)) is assigned for the channel whereH is a hashfunction and 119878119874119877119879 can be any function used to make sure both par-ties agree on the same order of pkrsquos thus leading to the identical ccidNext both ends create a certificate cert119894 = ΣSig(sk119894 pk1minus119894 )119894isin01for the other party by including the target public key pk as theidentifier With the cert a channel user can claim the fund receivedfrom counterpart on the Blockchain when channel is closed

Multi-party State Channel Establishment This step is optionalfor establishing the multi-party state channel To this end a groupchannel-key is generated for securely sharing the channel statesamong participants This step cannot complete until after all thenecessary two-party channels have been established Note that thegroup key only works for the multi-party state channel functionand coexists with the keys for direct channels (see Section 43)

lowastSpecific implementation may vary depending on the underlying platform4

43 Key Functions

Certified Channel One main challenge by incorporating TEEinto the Blockchain is that current Blockchain implementationdoes not support remote attestation for TEE platforms As a resultBlockchain cannot verify the authenticity of the transactional ac-tivities from layer-2 To address the problem we propose CertifiedChannel defined below

Definition 1 (Certified Channel) A channel in Speedsteris called Certified Channel if it is established between two attestedenclave accounts and both participants have the certificate cert issuedby the other party

With the Certified Channel Blockchain is agnostic to the enclaveattestation and offloads this task to the layer-2 nodes As long as anode can present a valid certificate issued by the other channel partyBlockchain will trust this enclave node and associated transactionsIn this way the balance security is guaranteed by the attestedenclaves

Dispute-free Channels The main reason for the disputes exist-ing in prior state channel networks is that it is challenging forBlockchain to discern the old states in an asynchronous networkThe victim nodemay be intentionally blocked to favor the attackerrsquosclaim when closing the channel [64 66 82] With Certified ChannelSpeedster relies on enclaves to correctly update its state beforesending out and after receiving transactions The node locks thechannel states if it intends to send a ldquoclaim transaction to theBlockchain As a result channel states are always up to date andthe channel can be unilaterally and safely closed without worryingabout unstable network connections In this regard Speedster isfree from expensive on-chain dispute resolution operations

Fully Decentralized Channel Network We envision a fully de-centralized channel network (FDCN) will significantly improve thelayer-2 network stability which also aligns with the decentralizeddesign principle of Blockchain We define a fully decentralizedchannel network as follows

Definition 2 (Fully Decentralized Channel Network) Apaymentstate channel network where a node can establish directchannel connections with other nodes efficiently off the chain andprocess transactions without relying on intermediaries is a Fully De-centralized Channel Network

It is economically impossible to turn the current state channelnetwork into an FDCN because it will lock in a significant amountof collaterals in the main chain Speedster addresses this issue byadopting an account-based channel creation to use the on-chaindeposit for openingmultiple channels off-chain Another immediatebenefit of FDCN is the elimination of intermediaries for transactionrouting thus relieving users from additional fees operational costsand security and privacy concerns

Multi-Party State Channel As discussed in Section 32 design-ing a multi-party state channel is a fundamental challenge butnecessary for many off-chain smart contract use cases such as themulti-party games Next we detail our design

Multi-party channel establishment Before establishing the groupchannel we assume that a peer-to-peer channel has already been

set up between each pair of members beforehand With 119899 knownparticipants of a multi-party channel to be created we first generatethe channel id ccid by hashing the sorted public keys of all partici-pants as follows ccid = H(119878119874119877119879 (pk119894 119894isin[119873 ] )) Then a group keygk can be generated with any secure multi-party key exchangealgorithm [12 16 20]

The group key gk is bind with ccid and only transactions with atag of the matched ccid can use the key for encryption and decryp-tion As a result a transaction in a multi-party channel only needsto be encrypted once and then broadcast to other members

Figure 3 An example of executing a multi-party

transfer contract among A B and C assuming

SORT(pk119860)gtSORT(pk119861)gtSORT(pk119862 ) (+) and (-) in the ta-

bles represent the current balance after transactions in each

Certified Channel respectively

Coordinated transaction execution To avoid ambiguity of thetransaction execution in a multi-party smart contract scenariotransactions from different parties need to be ordered before pro-cessed In a distributed network a trusted time source is hardto get for coordination To address this issue we let each party119894 takes turn to send its transactions by the order derived fromSORT(pk119894 119894isin[119873 ] ) Specifically all the nodes are mute after thechannel key is created except for the one with the highest orderby the SORT function Moving forward all other nodes need towait for their turn to issue transactions Figure 3 shows an exampleof the execution of a value-transfer multi-party contract amongthree-channel members A B and C In the figure Certified Chan-nels are opened between any two member nodes The nodes sendtransactions tx119894 tx119894+1 and tx119894+2 in the multi-party state channelidentified by ccid successively The figure also shows the balancechange of A with other two channel members after each round ofcommunication Note that the total balance of underlying CertifiedChannels at any time should not surpass the allocated amount bythe node for this multi-party channel Moreover channel membersare also relieved from the concerns of disputes thanks to the unsyn-chronized state which is inherited from the underlying CertifiedChannels

5

5 ΠSpeedster PROTOCOL

In this section we first introduce the abstracted ideal functionalitiesin Speedster and then formally present the concrete Speedsterprotocol ΠSpeedster

51 Ideal Functionality

In ΠSpeedster two ideal functionalities are assumed a Blockchainabstraction F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] and a TEE abstraction G119886119905119905 for-mally defined in [81] As a result the design and security of Speed-ster are independent of the specific Blockchain and TEE implemen-tations as long as they can provide the required functions Specifi-cally we define F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] as an ideal functionality thatmodels the behavior of Blockchain F119887119897119900119888119896119888ℎ119886119894119899 defines a smart-contract enabled append-only ledger The parameter 119862119900119899119905119903119886119888119905 isthe smart contract function of the Blockchain F119887119897119900119888119896119888ℎ119886119894119899 has aninternal 119878119905119900119903119886119892119890 that contains the Blockchain data associated withtransaction IDs To append a transaction to the Blockchain a usersends a transaction to F119887119897119900119888119896119888ℎ119886119894119899 which will subsequently triggerthe function ldquoappend to execute the transaction (see Figure 10 in theAppendix for details)G119886119905119905 [81] provides an abstraction for the general-purpose TEE-

enabled secure processor During initialization G119886119905119905 creates a keypair as the manufacture key (msk mpk) while msk is preserved in theprocessor and the mpk could be accessed through ldquogetpk commandIn such an ideal functionality user first creates an enclave and loadsprog119890119899119888119897119886119907119890 into enclave by sending an ldquoinstall command To call thefunctions in prog119890119899119888119897119886119907119890 user sends ldquoresume command to G119886119905119905 alongwith the parameters All operations through the ldquoresume commandof G119886119905119905 is signed with msk by default to ensure the authenticitywhereas Certified Channel leverages symmetric-key authenticatedencryption instead of digital signatures Therefore we add a switch

to ldquoresume command to be able to turn off the signature and onlywhen the switch is set execution output through ldquoresume is signed(see Figure 9 in the Appendix for detail)

52 Speedster Protocol ΠSpeedster

We formally present the protocol ΠSpeedster into two parts the pro-gram prog119890119899119888119897119886119907119890 in Figure 4 that runs the enclave and the smartcontract contractSpeedster running on the Blockchain shown in Fig-ure 5 In the protocol we let P denotes a user R as the counterpartusers in a channel and tx represents an on-chain transaction Toexecute an off-chain smart contract in prog119890119899119888119897119886119907119890 we define a func-tion Contractcid (middot) which is parameterized with a smart contractid cid Contractcid (middot) consumes the channel state and node balanceto ensure the balance consistent across channels Contractcid (middot)generates output outp based on the input and updates the channelstate

Node Initialization For the first time to boot up a Speedsternode a node sends the ldquoinstall command to the enclave to loadprog119890119899119888119897119886119907119890 Then the node calls the function (1) of prog119890119899119888119897119886119907119890 bysending message (ldquoinit) to create an enclave account acc119890119899119888119897119886119907119890 withkey pair (sk pk) For attestation purpose a measurement 120590119886119905119905 ofthe enclave is generated with the prog119890119899119888119897119886119907119890 the public key pk ofacc119890119899119888119897119886119907119890 and the node initial state state0

Protocol ΠSpeedster (P0P1P2 P119873 ]

Program prog119890119899119888119897119886119907119890Initially

bal = empty certs = empty channels = empty state0 = perp

(1) On receive(ldquoinit)(pk sk) larr$KGen(1119899) generate acc119890119899119888119897119886119907119890mpk = G119886119905119905 getpk()return (pkmpk)

(2) On receive (ldquodeposit tx)parse tx as (_ pkrsquo $val 120590)assert $val ge 0 assert Verify(pk tx 120590)bal += $val add tx to state0

(3) On receive (ldquoopen cid R inp)ccid = H(119878119874119877119879 pkR pk)abort if channels[ccid] neperpcklarr$ 0 1lowast channel keycp = pk pkR (st outp) = Contractcid (sk bal

minusrarr0 cp)append (ccid (ck cid st cp)) to channels

120590 = sign(sk pk119877 ∥inp∥state0) cert = (pk∥pk119877 ∥inp∥120590)return (cert state0 outp)

(4) On receive (ldquoopenMulti cid ccidlowast)for each ccidprime isin ccidlowast

assert channels[ccidprime] neperpextract pkprime from channels[ccidprime]

cp = pkprimelowast cup pk ccid = H(119878119874119877119879 (cp))assert channels[ccid] = perpgklarr$ 0 1lowast Group key

(st outp) = Contractcid (sk119894 stateminusrarr0 cp)

append (ccid (gk cid st cp)) to channels

ct = Enc (gk outp)return (ct)

(5) On receive (ldquoauthenticate ccid R cert)abort if certs[ccid][pkR] neperpparse cert as (aux 120590) Verify (pkR aux 120590)extract state0rsquo from aux check state0rsquo on Blockchaincerts[ccid][pkR] = cert

(6) On receive (ldquosend ccid inp)assert certs[b] neperp(ck cid st cp) = channles[ccid](stacute outp) = Contractcid (sk state st inp)update channels[ccid] to (ck cid stacute cp)aux = (pk∥inp∥strsquo∥outp) ct = Enc (ck aux)return (ct)

(7) On receive (ldquoclaim)freeze send functiontx = certlowast∥state 120590 = Sign (sktx)return (tx∥120590)

Figure 4 prog119890119899119888119897119886119907119890 program of ΠSpeedster

6

Protocol ΠSpeedster (P0P1P2 P119873 ]

contractSpeedsterParameters

119871119890119889119892119890119903 Append only public ledger of F119887119897119900119888119896119888ℎ119886119894119899119862119900119894119899 Blockchain function that convert value into coins

On receive (ldquodeposit tx) from Passert tx notin 119871119890119889119892119890119903

execute tx on the 119861119897119900119888119896119888ℎ119886119894119899append tx to 119871119890119889119892119890119903

On receive (ldquoclaim tx) from Pparse tx as (certlowast state) state contains channel dataFor each cert in certlowast

parse cert to (toacute fromacute 120590 )abort if Verify(120590 cert) fails verify the certextract $119907119886119897 from state[from]assert $119907119886119897 ne 0 and toacute = Psend(from P Coin($119907119886119897 )) if $119907119886119897 gt 0send(P from Coin(minus$119907119886119897)) otherwise

append(tx) to 119871119890119889119892119890119903

On receive (ldquoread tx) from Poutput 119871119890119889119892119890119903 [tx]

Figure 5 On-chain smart contract contractSpeedster of

ΠSpeedster

Deposit To deposit a node needs to complete the following stepsFirst it sends a tx to contractSpeedster on the main chain The transac-tion includes the pk of the enclave account acc119890119899119888119897119886119907119890 as the accountaddress Next the node calls the the function (2) of prog119890119899119888119897119886119907119890 bysending message ldquodeposit and passing tx as a parameter Finallyprog119890119899119888119897119886119907119890 verifies the signature of tx and updates the local initialstate state0

Certified Channel Each certified channel in ΠSpeedster is iden-tified by a channel ID ccid A shared channel key ck is produced inthis step The certificate cert of the channel is created using publickeys of both parties To prevent rollback attacks on 120590119886119905119905 prog119890119899119888119897119886119907119890generates a signature 120590119886119905119905 by signing the tuple (state0 pk119894 119894isin01 prog119890119899119888119897119886119907119890 ) for each channel after function (3) returns The tupleis signed under the manufacture secret key msk to reflect the roottrust of the hardware The cert is verified in function (5)

Multi-Party State Channel A multi-party state channel is builtupon the existing certified channels To create a multi-party statechannel a node calls the function (4) of prog119890119899119888119897119886119907119890 by sendingldquoopenMulti message and passes a set of ccid to inform the underlyingcertified channels with other nodes We abstract out the process ofmulti-party shared key generation which could be replaced by anysecure multi-party key negotiation protocol [12 16 20]

Transaction To send a channel transaction a node calls thefunction (6) of prog119890119899119888119897119886119907119890 by sending ldquosend command to prog119890119899119888119897119886119907119890through G119886119905119905 resume(middot) and passing the target ccid along with othernecessary parameters in inp Then prog119890119899119888119897119886119907119890 executes inp with the

associated contract by calling Contractcid (middot) and updates the chan-nel state accordingly A channel transaction is constructed over thepublic key of pk the new channel state stateprime the input inp and theoutput outp Then the transaction is encrypted by an authenticatedencryption schemesuch as AES-GCM with the channel key ck

Claim To claim the fund that P has received from the channeltransactions the node issues a ldquoclaim call to the function (7) ofprog119890119899119888119897119886119907119890 prog119890119899119888119897119886119907119890 first freezes all two-party channels and ex-tracts all the certs from those channels The certs and the local nodestate state constitute the claim transaction tx prog119890119899119888119897119886119907119890 then signstxwith the private key sk of acc119890119899119888119897119886119907119890 and returns the signed transac-tion that is further forwarded by the node to the contractSpeedster Inthe end contractSpeedster verifies and executes the claim transactionon the Blockchain to redeem the fund for the node

6 SECURITY AND PRIVACY ANALYSIS

We formalize a Universal Composability (UC) [11 27 61 64] idealfunctionality FSpeedster (shown in Figure 8 in the Appendix) torealize the security goals of ΠSpeedster

Participants of FSpeedster are denoted as P The internal com-munication among participants is protected through an authen-ticated encryption scheme Following [27] [29] we parameterizeFSpeedster with a leakage function ℓ (middot) 0 1lowast minusrarr 0 1lowast to demon-strate the amount of privacy leaked from the message that is en-crypted by the authenticated encryption scheme The security ofΠSpeedster is given in Theorem 1

Theorem 1 (UC-Security of ΠSpeedster) If the adopted au-thenticated encryption AE is IND-CCA secure and digital signaturescheme Σ is EU-CMA secure then the protocol ΠSpeedster securely UC-realizes the ideal functionality FSpeedster in the (G119886119905119905 F119887119897119900119888119896119888ℎ119886119894119899)-hybrid model for static adversaries

As defined in Theorem 1 we now formally present the proofthat the protocol ΠSpeedster securely UC-realizes ideal function-ality FSpeedster by showing that an ideal world simulator S cansimulate the behavior of a real-world adversary A The securityof ΠSpeedster is proved by showing that S can indistinguishablysimulate the behavior of A for all environment E [27]

Proof Let E be an environment and A be a real-world proba-bilistic polynomial time adversary [27] who simply relays messagesbetween E and dummy parties To show thatΠSpeedster UC-realizesFSpeedster we specify below a simulator S such that no environ-ment can distinguish an interaction between ΠSpeedster and Afrom an interaction with FSpeedster and S That is for any E Sshould satisfy

forallE EXECEΠSpeedster A asymp EXECEFSpeedster S

Construction of S Please refer Appendix A for the construc-tion detail

Indistinguishability We show that the execution of the real-world and ideal-world is indistinguishable for all E from the view ofA by a series of hybrid steps that reduce the real-world executionto the ideal-world executionbull Hybrid 1198670 is the real-world execution of Speedster

7

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

enclaveCertified Channel

State(cert0 cert1 119888119896)

Blockchain (contractSpeedster)

P0 P1

prog119890119899119888119897119886119907119890

enclave

prog119890119899119888119897119886119907119890

Figure 1 Framework of Speedster A channel is opened

directly between enclaves of two users Off-chain trans-

actions are processed by prog119890119899119888119897119886119907119890 in the enclave The

contractSpeedster is deployed on the Blockchain to record the

states of the nodes The initial state of the enclave is syn-

chronized from the Blockchain

4 SPEEDSTER DESIGN

In this section we first introduce the architecture of Speedsterand then detail the design

41 System Architecture

Speedster contains two components the state channel core pro-gram prog119890119899119888119897119886119907119890 executed inside the enclave and the on-chain smartcontract contractSpeedster running on the Blockchain Figure 1 showsthe high-level architecture of Speedster in which two participantsare connected by a Certified Channel (see Definition 1)Prog119890119899119888119897119886119907119890 The program runs in the enclave prog119890119899119888119897119886119907119890 createsand manages an enclave account for a Speedster node It executescommands from the user to open and close channels as well asconstructs and processes channel transactions To verify the enclaveauthenticity it also generates measurements for remote attestationContractSpeedster contractSpeedster is a smart contract deployedon the Blockchain to manage the on-chain state of Speedsteraccount To register an account a deposit has to be sent to thiscontract and recorded in the Blockchain Later the information canbe used to initialize the enclave state It also handles transactionsto claim fund for Speedster account

42 Workflow

In this subsection we outline the workflow of Speedster including(1) node initialization (2) enclave state attestation (3) channel keyestablishment (4) channel certification and (5) multi-party statechannel establishment (optional) The workflow is illustrated inFigure 2

Node Initialization In this step an account acc119890119899119888119897119886119907119890 along witha pair of keys pk and sk is opened in the enclave after the programprog119890119899119888119897119886119907119890 is loaded into the enclave for the first time The enclavekeeps sk private and publishes pk as the account address that can beused to deposit acc119890119899119888119897119886119907119890 on the Blockchain To ensure the authen-ticity of the opened account acc119890119899119888119897119886119907119890 for following off-chain attesta-tions an initial deposit transaction needs to be generated to registeracc119890119899119888119897119886119907119890 with the Blockchain After the Blockchain confirms the

(3) Key Establishment

Certified Channel

Terminate

(1)Initialization

Multi-party Channel

E

msg1 = tx

msg2 = 120532att

msg3 = pk

(2) Attestation

ChannelKey

(4) Certify

Initialized State

(5)

fail

Figure 2 Workflow of node initialization and certified chan-

nel creation E is the environment including the Blockchain

and the channel users who pass input to Speedster nodes

transaction the user loads relevant information into the enclave asa registration proof to initialize the enclave state state0 = (tx0 aux0)a tuple that contains the deposit transaction tx0 and auxiliary infor-mation aux0 where tx0 can be more than one deposit and aux0 can bethe current balance or account-related configuration informationFurther deposits are allowed to update the initial state state0

Enclave State Attestation Step 2 is enclave attestation that needsto be carried out to authenticate the enclave environment includingthe state0 Note that we add the initial state state0 and the publickey pk into the enclave measurement 120590119886119905119905 = ΣSig(msk (prog119890119899119888119897119886119907119890 pk state0)) lowast where Σ is a digital signature scheme and msk is themanufacturer-generated secret key for the processor [81]

The initial state reflects the starting point of acc119890119899119888119897119886119907119890 whichshould match the recorded state on the Blockchain If a node passesthe attestation it means that the acc119890119899119888119897119886119907119890 is set up with the correcton-chain deposit and should be trusted for the subsequent off-chaintransactions

Channel Key Establishment Once the enclave account is verifiedthe channel participants start to generate the shared channel key byleveraging any secure two-party key agreement protocols [15 22]

Channel Certification In this step an identifier denoted as ccid =H(119878119874119877119879 (pk0 pk1)) is assigned for the channel whereH is a hashfunction and 119878119874119877119879 can be any function used to make sure both par-ties agree on the same order of pkrsquos thus leading to the identical ccidNext both ends create a certificate cert119894 = ΣSig(sk119894 pk1minus119894 )119894isin01for the other party by including the target public key pk as theidentifier With the cert a channel user can claim the fund receivedfrom counterpart on the Blockchain when channel is closed

Multi-party State Channel Establishment This step is optionalfor establishing the multi-party state channel To this end a groupchannel-key is generated for securely sharing the channel statesamong participants This step cannot complete until after all thenecessary two-party channels have been established Note that thegroup key only works for the multi-party state channel functionand coexists with the keys for direct channels (see Section 43)

lowastSpecific implementation may vary depending on the underlying platform4

43 Key Functions

Certified Channel One main challenge by incorporating TEEinto the Blockchain is that current Blockchain implementationdoes not support remote attestation for TEE platforms As a resultBlockchain cannot verify the authenticity of the transactional ac-tivities from layer-2 To address the problem we propose CertifiedChannel defined below

Definition 1 (Certified Channel) A channel in Speedsteris called Certified Channel if it is established between two attestedenclave accounts and both participants have the certificate cert issuedby the other party

With the Certified Channel Blockchain is agnostic to the enclaveattestation and offloads this task to the layer-2 nodes As long as anode can present a valid certificate issued by the other channel partyBlockchain will trust this enclave node and associated transactionsIn this way the balance security is guaranteed by the attestedenclaves

Dispute-free Channels The main reason for the disputes exist-ing in prior state channel networks is that it is challenging forBlockchain to discern the old states in an asynchronous networkThe victim nodemay be intentionally blocked to favor the attackerrsquosclaim when closing the channel [64 66 82] With Certified ChannelSpeedster relies on enclaves to correctly update its state beforesending out and after receiving transactions The node locks thechannel states if it intends to send a ldquoclaim transaction to theBlockchain As a result channel states are always up to date andthe channel can be unilaterally and safely closed without worryingabout unstable network connections In this regard Speedster isfree from expensive on-chain dispute resolution operations

Fully Decentralized Channel Network We envision a fully de-centralized channel network (FDCN) will significantly improve thelayer-2 network stability which also aligns with the decentralizeddesign principle of Blockchain We define a fully decentralizedchannel network as follows

Definition 2 (Fully Decentralized Channel Network) Apaymentstate channel network where a node can establish directchannel connections with other nodes efficiently off the chain andprocess transactions without relying on intermediaries is a Fully De-centralized Channel Network

It is economically impossible to turn the current state channelnetwork into an FDCN because it will lock in a significant amountof collaterals in the main chain Speedster addresses this issue byadopting an account-based channel creation to use the on-chaindeposit for openingmultiple channels off-chain Another immediatebenefit of FDCN is the elimination of intermediaries for transactionrouting thus relieving users from additional fees operational costsand security and privacy concerns

Multi-Party State Channel As discussed in Section 32 design-ing a multi-party state channel is a fundamental challenge butnecessary for many off-chain smart contract use cases such as themulti-party games Next we detail our design

Multi-party channel establishment Before establishing the groupchannel we assume that a peer-to-peer channel has already been

set up between each pair of members beforehand With 119899 knownparticipants of a multi-party channel to be created we first generatethe channel id ccid by hashing the sorted public keys of all partici-pants as follows ccid = H(119878119874119877119879 (pk119894 119894isin[119873 ] )) Then a group keygk can be generated with any secure multi-party key exchangealgorithm [12 16 20]

The group key gk is bind with ccid and only transactions with atag of the matched ccid can use the key for encryption and decryp-tion As a result a transaction in a multi-party channel only needsto be encrypted once and then broadcast to other members

Figure 3 An example of executing a multi-party

transfer contract among A B and C assuming

SORT(pk119860)gtSORT(pk119861)gtSORT(pk119862 ) (+) and (-) in the ta-

bles represent the current balance after transactions in each

Certified Channel respectively

Coordinated transaction execution To avoid ambiguity of thetransaction execution in a multi-party smart contract scenariotransactions from different parties need to be ordered before pro-cessed In a distributed network a trusted time source is hardto get for coordination To address this issue we let each party119894 takes turn to send its transactions by the order derived fromSORT(pk119894 119894isin[119873 ] ) Specifically all the nodes are mute after thechannel key is created except for the one with the highest orderby the SORT function Moving forward all other nodes need towait for their turn to issue transactions Figure 3 shows an exampleof the execution of a value-transfer multi-party contract amongthree-channel members A B and C In the figure Certified Chan-nels are opened between any two member nodes The nodes sendtransactions tx119894 tx119894+1 and tx119894+2 in the multi-party state channelidentified by ccid successively The figure also shows the balancechange of A with other two channel members after each round ofcommunication Note that the total balance of underlying CertifiedChannels at any time should not surpass the allocated amount bythe node for this multi-party channel Moreover channel membersare also relieved from the concerns of disputes thanks to the unsyn-chronized state which is inherited from the underlying CertifiedChannels

5

5 ΠSpeedster PROTOCOL

In this section we first introduce the abstracted ideal functionalitiesin Speedster and then formally present the concrete Speedsterprotocol ΠSpeedster

51 Ideal Functionality

In ΠSpeedster two ideal functionalities are assumed a Blockchainabstraction F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] and a TEE abstraction G119886119905119905 for-mally defined in [81] As a result the design and security of Speed-ster are independent of the specific Blockchain and TEE implemen-tations as long as they can provide the required functions Specifi-cally we define F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] as an ideal functionality thatmodels the behavior of Blockchain F119887119897119900119888119896119888ℎ119886119894119899 defines a smart-contract enabled append-only ledger The parameter 119862119900119899119905119903119886119888119905 isthe smart contract function of the Blockchain F119887119897119900119888119896119888ℎ119886119894119899 has aninternal 119878119905119900119903119886119892119890 that contains the Blockchain data associated withtransaction IDs To append a transaction to the Blockchain a usersends a transaction to F119887119897119900119888119896119888ℎ119886119894119899 which will subsequently triggerthe function ldquoappend to execute the transaction (see Figure 10 in theAppendix for details)G119886119905119905 [81] provides an abstraction for the general-purpose TEE-

enabled secure processor During initialization G119886119905119905 creates a keypair as the manufacture key (msk mpk) while msk is preserved in theprocessor and the mpk could be accessed through ldquogetpk commandIn such an ideal functionality user first creates an enclave and loadsprog119890119899119888119897119886119907119890 into enclave by sending an ldquoinstall command To call thefunctions in prog119890119899119888119897119886119907119890 user sends ldquoresume command to G119886119905119905 alongwith the parameters All operations through the ldquoresume commandof G119886119905119905 is signed with msk by default to ensure the authenticitywhereas Certified Channel leverages symmetric-key authenticatedencryption instead of digital signatures Therefore we add a switch

to ldquoresume command to be able to turn off the signature and onlywhen the switch is set execution output through ldquoresume is signed(see Figure 9 in the Appendix for detail)

52 Speedster Protocol ΠSpeedster

We formally present the protocol ΠSpeedster into two parts the pro-gram prog119890119899119888119897119886119907119890 in Figure 4 that runs the enclave and the smartcontract contractSpeedster running on the Blockchain shown in Fig-ure 5 In the protocol we let P denotes a user R as the counterpartusers in a channel and tx represents an on-chain transaction Toexecute an off-chain smart contract in prog119890119899119888119897119886119907119890 we define a func-tion Contractcid (middot) which is parameterized with a smart contractid cid Contractcid (middot) consumes the channel state and node balanceto ensure the balance consistent across channels Contractcid (middot)generates output outp based on the input and updates the channelstate

Node Initialization For the first time to boot up a Speedsternode a node sends the ldquoinstall command to the enclave to loadprog119890119899119888119897119886119907119890 Then the node calls the function (1) of prog119890119899119888119897119886119907119890 bysending message (ldquoinit) to create an enclave account acc119890119899119888119897119886119907119890 withkey pair (sk pk) For attestation purpose a measurement 120590119886119905119905 ofthe enclave is generated with the prog119890119899119888119897119886119907119890 the public key pk ofacc119890119899119888119897119886119907119890 and the node initial state state0

Protocol ΠSpeedster (P0P1P2 P119873 ]

Program prog119890119899119888119897119886119907119890Initially

bal = empty certs = empty channels = empty state0 = perp

(1) On receive(ldquoinit)(pk sk) larr$KGen(1119899) generate acc119890119899119888119897119886119907119890mpk = G119886119905119905 getpk()return (pkmpk)

(2) On receive (ldquodeposit tx)parse tx as (_ pkrsquo $val 120590)assert $val ge 0 assert Verify(pk tx 120590)bal += $val add tx to state0

(3) On receive (ldquoopen cid R inp)ccid = H(119878119874119877119879 pkR pk)abort if channels[ccid] neperpcklarr$ 0 1lowast channel keycp = pk pkR (st outp) = Contractcid (sk bal

minusrarr0 cp)append (ccid (ck cid st cp)) to channels

120590 = sign(sk pk119877 ∥inp∥state0) cert = (pk∥pk119877 ∥inp∥120590)return (cert state0 outp)

(4) On receive (ldquoopenMulti cid ccidlowast)for each ccidprime isin ccidlowast

assert channels[ccidprime] neperpextract pkprime from channels[ccidprime]

cp = pkprimelowast cup pk ccid = H(119878119874119877119879 (cp))assert channels[ccid] = perpgklarr$ 0 1lowast Group key

(st outp) = Contractcid (sk119894 stateminusrarr0 cp)

append (ccid (gk cid st cp)) to channels

ct = Enc (gk outp)return (ct)

(5) On receive (ldquoauthenticate ccid R cert)abort if certs[ccid][pkR] neperpparse cert as (aux 120590) Verify (pkR aux 120590)extract state0rsquo from aux check state0rsquo on Blockchaincerts[ccid][pkR] = cert

(6) On receive (ldquosend ccid inp)assert certs[b] neperp(ck cid st cp) = channles[ccid](stacute outp) = Contractcid (sk state st inp)update channels[ccid] to (ck cid stacute cp)aux = (pk∥inp∥strsquo∥outp) ct = Enc (ck aux)return (ct)

(7) On receive (ldquoclaim)freeze send functiontx = certlowast∥state 120590 = Sign (sktx)return (tx∥120590)

Figure 4 prog119890119899119888119897119886119907119890 program of ΠSpeedster

6

Protocol ΠSpeedster (P0P1P2 P119873 ]

contractSpeedsterParameters

119871119890119889119892119890119903 Append only public ledger of F119887119897119900119888119896119888ℎ119886119894119899119862119900119894119899 Blockchain function that convert value into coins

On receive (ldquodeposit tx) from Passert tx notin 119871119890119889119892119890119903

execute tx on the 119861119897119900119888119896119888ℎ119886119894119899append tx to 119871119890119889119892119890119903

On receive (ldquoclaim tx) from Pparse tx as (certlowast state) state contains channel dataFor each cert in certlowast

parse cert to (toacute fromacute 120590 )abort if Verify(120590 cert) fails verify the certextract $119907119886119897 from state[from]assert $119907119886119897 ne 0 and toacute = Psend(from P Coin($119907119886119897 )) if $119907119886119897 gt 0send(P from Coin(minus$119907119886119897)) otherwise

append(tx) to 119871119890119889119892119890119903

On receive (ldquoread tx) from Poutput 119871119890119889119892119890119903 [tx]

Figure 5 On-chain smart contract contractSpeedster of

ΠSpeedster

Deposit To deposit a node needs to complete the following stepsFirst it sends a tx to contractSpeedster on the main chain The transac-tion includes the pk of the enclave account acc119890119899119888119897119886119907119890 as the accountaddress Next the node calls the the function (2) of prog119890119899119888119897119886119907119890 bysending message ldquodeposit and passing tx as a parameter Finallyprog119890119899119888119897119886119907119890 verifies the signature of tx and updates the local initialstate state0

Certified Channel Each certified channel in ΠSpeedster is iden-tified by a channel ID ccid A shared channel key ck is produced inthis step The certificate cert of the channel is created using publickeys of both parties To prevent rollback attacks on 120590119886119905119905 prog119890119899119888119897119886119907119890generates a signature 120590119886119905119905 by signing the tuple (state0 pk119894 119894isin01 prog119890119899119888119897119886119907119890 ) for each channel after function (3) returns The tupleis signed under the manufacture secret key msk to reflect the roottrust of the hardware The cert is verified in function (5)

Multi-Party State Channel A multi-party state channel is builtupon the existing certified channels To create a multi-party statechannel a node calls the function (4) of prog119890119899119888119897119886119907119890 by sendingldquoopenMulti message and passes a set of ccid to inform the underlyingcertified channels with other nodes We abstract out the process ofmulti-party shared key generation which could be replaced by anysecure multi-party key negotiation protocol [12 16 20]

Transaction To send a channel transaction a node calls thefunction (6) of prog119890119899119888119897119886119907119890 by sending ldquosend command to prog119890119899119888119897119886119907119890through G119886119905119905 resume(middot) and passing the target ccid along with othernecessary parameters in inp Then prog119890119899119888119897119886119907119890 executes inp with the

associated contract by calling Contractcid (middot) and updates the chan-nel state accordingly A channel transaction is constructed over thepublic key of pk the new channel state stateprime the input inp and theoutput outp Then the transaction is encrypted by an authenticatedencryption schemesuch as AES-GCM with the channel key ck

Claim To claim the fund that P has received from the channeltransactions the node issues a ldquoclaim call to the function (7) ofprog119890119899119888119897119886119907119890 prog119890119899119888119897119886119907119890 first freezes all two-party channels and ex-tracts all the certs from those channels The certs and the local nodestate state constitute the claim transaction tx prog119890119899119888119897119886119907119890 then signstxwith the private key sk of acc119890119899119888119897119886119907119890 and returns the signed transac-tion that is further forwarded by the node to the contractSpeedster Inthe end contractSpeedster verifies and executes the claim transactionon the Blockchain to redeem the fund for the node

6 SECURITY AND PRIVACY ANALYSIS

We formalize a Universal Composability (UC) [11 27 61 64] idealfunctionality FSpeedster (shown in Figure 8 in the Appendix) torealize the security goals of ΠSpeedster

Participants of FSpeedster are denoted as P The internal com-munication among participants is protected through an authen-ticated encryption scheme Following [27] [29] we parameterizeFSpeedster with a leakage function ℓ (middot) 0 1lowast minusrarr 0 1lowast to demon-strate the amount of privacy leaked from the message that is en-crypted by the authenticated encryption scheme The security ofΠSpeedster is given in Theorem 1

Theorem 1 (UC-Security of ΠSpeedster) If the adopted au-thenticated encryption AE is IND-CCA secure and digital signaturescheme Σ is EU-CMA secure then the protocol ΠSpeedster securely UC-realizes the ideal functionality FSpeedster in the (G119886119905119905 F119887119897119900119888119896119888ℎ119886119894119899)-hybrid model for static adversaries

As defined in Theorem 1 we now formally present the proofthat the protocol ΠSpeedster securely UC-realizes ideal function-ality FSpeedster by showing that an ideal world simulator S cansimulate the behavior of a real-world adversary A The securityof ΠSpeedster is proved by showing that S can indistinguishablysimulate the behavior of A for all environment E [27]

Proof Let E be an environment and A be a real-world proba-bilistic polynomial time adversary [27] who simply relays messagesbetween E and dummy parties To show thatΠSpeedster UC-realizesFSpeedster we specify below a simulator S such that no environ-ment can distinguish an interaction between ΠSpeedster and Afrom an interaction with FSpeedster and S That is for any E Sshould satisfy

forallE EXECEΠSpeedster A asymp EXECEFSpeedster S

Construction of S Please refer Appendix A for the construc-tion detail

Indistinguishability We show that the execution of the real-world and ideal-world is indistinguishable for all E from the view ofA by a series of hybrid steps that reduce the real-world executionto the ideal-world executionbull Hybrid 1198670 is the real-world execution of Speedster

7

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

43 Key Functions

Certified Channel One main challenge by incorporating TEEinto the Blockchain is that current Blockchain implementationdoes not support remote attestation for TEE platforms As a resultBlockchain cannot verify the authenticity of the transactional ac-tivities from layer-2 To address the problem we propose CertifiedChannel defined below

Definition 1 (Certified Channel) A channel in Speedsteris called Certified Channel if it is established between two attestedenclave accounts and both participants have the certificate cert issuedby the other party

With the Certified Channel Blockchain is agnostic to the enclaveattestation and offloads this task to the layer-2 nodes As long as anode can present a valid certificate issued by the other channel partyBlockchain will trust this enclave node and associated transactionsIn this way the balance security is guaranteed by the attestedenclaves

Dispute-free Channels The main reason for the disputes exist-ing in prior state channel networks is that it is challenging forBlockchain to discern the old states in an asynchronous networkThe victim nodemay be intentionally blocked to favor the attackerrsquosclaim when closing the channel [64 66 82] With Certified ChannelSpeedster relies on enclaves to correctly update its state beforesending out and after receiving transactions The node locks thechannel states if it intends to send a ldquoclaim transaction to theBlockchain As a result channel states are always up to date andthe channel can be unilaterally and safely closed without worryingabout unstable network connections In this regard Speedster isfree from expensive on-chain dispute resolution operations

Fully Decentralized Channel Network We envision a fully de-centralized channel network (FDCN) will significantly improve thelayer-2 network stability which also aligns with the decentralizeddesign principle of Blockchain We define a fully decentralizedchannel network as follows

Definition 2 (Fully Decentralized Channel Network) Apaymentstate channel network where a node can establish directchannel connections with other nodes efficiently off the chain andprocess transactions without relying on intermediaries is a Fully De-centralized Channel Network

It is economically impossible to turn the current state channelnetwork into an FDCN because it will lock in a significant amountof collaterals in the main chain Speedster addresses this issue byadopting an account-based channel creation to use the on-chaindeposit for openingmultiple channels off-chain Another immediatebenefit of FDCN is the elimination of intermediaries for transactionrouting thus relieving users from additional fees operational costsand security and privacy concerns

Multi-Party State Channel As discussed in Section 32 design-ing a multi-party state channel is a fundamental challenge butnecessary for many off-chain smart contract use cases such as themulti-party games Next we detail our design

Multi-party channel establishment Before establishing the groupchannel we assume that a peer-to-peer channel has already been

set up between each pair of members beforehand With 119899 knownparticipants of a multi-party channel to be created we first generatethe channel id ccid by hashing the sorted public keys of all partici-pants as follows ccid = H(119878119874119877119879 (pk119894 119894isin[119873 ] )) Then a group keygk can be generated with any secure multi-party key exchangealgorithm [12 16 20]

The group key gk is bind with ccid and only transactions with atag of the matched ccid can use the key for encryption and decryp-tion As a result a transaction in a multi-party channel only needsto be encrypted once and then broadcast to other members

Figure 3 An example of executing a multi-party

transfer contract among A B and C assuming

SORT(pk119860)gtSORT(pk119861)gtSORT(pk119862 ) (+) and (-) in the ta-

bles represent the current balance after transactions in each

Certified Channel respectively

Coordinated transaction execution To avoid ambiguity of thetransaction execution in a multi-party smart contract scenariotransactions from different parties need to be ordered before pro-cessed In a distributed network a trusted time source is hardto get for coordination To address this issue we let each party119894 takes turn to send its transactions by the order derived fromSORT(pk119894 119894isin[119873 ] ) Specifically all the nodes are mute after thechannel key is created except for the one with the highest orderby the SORT function Moving forward all other nodes need towait for their turn to issue transactions Figure 3 shows an exampleof the execution of a value-transfer multi-party contract amongthree-channel members A B and C In the figure Certified Chan-nels are opened between any two member nodes The nodes sendtransactions tx119894 tx119894+1 and tx119894+2 in the multi-party state channelidentified by ccid successively The figure also shows the balancechange of A with other two channel members after each round ofcommunication Note that the total balance of underlying CertifiedChannels at any time should not surpass the allocated amount bythe node for this multi-party channel Moreover channel membersare also relieved from the concerns of disputes thanks to the unsyn-chronized state which is inherited from the underlying CertifiedChannels

5

5 ΠSpeedster PROTOCOL

In this section we first introduce the abstracted ideal functionalitiesin Speedster and then formally present the concrete Speedsterprotocol ΠSpeedster

51 Ideal Functionality

In ΠSpeedster two ideal functionalities are assumed a Blockchainabstraction F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] and a TEE abstraction G119886119905119905 for-mally defined in [81] As a result the design and security of Speed-ster are independent of the specific Blockchain and TEE implemen-tations as long as they can provide the required functions Specifi-cally we define F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] as an ideal functionality thatmodels the behavior of Blockchain F119887119897119900119888119896119888ℎ119886119894119899 defines a smart-contract enabled append-only ledger The parameter 119862119900119899119905119903119886119888119905 isthe smart contract function of the Blockchain F119887119897119900119888119896119888ℎ119886119894119899 has aninternal 119878119905119900119903119886119892119890 that contains the Blockchain data associated withtransaction IDs To append a transaction to the Blockchain a usersends a transaction to F119887119897119900119888119896119888ℎ119886119894119899 which will subsequently triggerthe function ldquoappend to execute the transaction (see Figure 10 in theAppendix for details)G119886119905119905 [81] provides an abstraction for the general-purpose TEE-

enabled secure processor During initialization G119886119905119905 creates a keypair as the manufacture key (msk mpk) while msk is preserved in theprocessor and the mpk could be accessed through ldquogetpk commandIn such an ideal functionality user first creates an enclave and loadsprog119890119899119888119897119886119907119890 into enclave by sending an ldquoinstall command To call thefunctions in prog119890119899119888119897119886119907119890 user sends ldquoresume command to G119886119905119905 alongwith the parameters All operations through the ldquoresume commandof G119886119905119905 is signed with msk by default to ensure the authenticitywhereas Certified Channel leverages symmetric-key authenticatedencryption instead of digital signatures Therefore we add a switch

to ldquoresume command to be able to turn off the signature and onlywhen the switch is set execution output through ldquoresume is signed(see Figure 9 in the Appendix for detail)

52 Speedster Protocol ΠSpeedster

We formally present the protocol ΠSpeedster into two parts the pro-gram prog119890119899119888119897119886119907119890 in Figure 4 that runs the enclave and the smartcontract contractSpeedster running on the Blockchain shown in Fig-ure 5 In the protocol we let P denotes a user R as the counterpartusers in a channel and tx represents an on-chain transaction Toexecute an off-chain smart contract in prog119890119899119888119897119886119907119890 we define a func-tion Contractcid (middot) which is parameterized with a smart contractid cid Contractcid (middot) consumes the channel state and node balanceto ensure the balance consistent across channels Contractcid (middot)generates output outp based on the input and updates the channelstate

Node Initialization For the first time to boot up a Speedsternode a node sends the ldquoinstall command to the enclave to loadprog119890119899119888119897119886119907119890 Then the node calls the function (1) of prog119890119899119888119897119886119907119890 bysending message (ldquoinit) to create an enclave account acc119890119899119888119897119886119907119890 withkey pair (sk pk) For attestation purpose a measurement 120590119886119905119905 ofthe enclave is generated with the prog119890119899119888119897119886119907119890 the public key pk ofacc119890119899119888119897119886119907119890 and the node initial state state0

Protocol ΠSpeedster (P0P1P2 P119873 ]

Program prog119890119899119888119897119886119907119890Initially

bal = empty certs = empty channels = empty state0 = perp

(1) On receive(ldquoinit)(pk sk) larr$KGen(1119899) generate acc119890119899119888119897119886119907119890mpk = G119886119905119905 getpk()return (pkmpk)

(2) On receive (ldquodeposit tx)parse tx as (_ pkrsquo $val 120590)assert $val ge 0 assert Verify(pk tx 120590)bal += $val add tx to state0

(3) On receive (ldquoopen cid R inp)ccid = H(119878119874119877119879 pkR pk)abort if channels[ccid] neperpcklarr$ 0 1lowast channel keycp = pk pkR (st outp) = Contractcid (sk bal

minusrarr0 cp)append (ccid (ck cid st cp)) to channels

120590 = sign(sk pk119877 ∥inp∥state0) cert = (pk∥pk119877 ∥inp∥120590)return (cert state0 outp)

(4) On receive (ldquoopenMulti cid ccidlowast)for each ccidprime isin ccidlowast

assert channels[ccidprime] neperpextract pkprime from channels[ccidprime]

cp = pkprimelowast cup pk ccid = H(119878119874119877119879 (cp))assert channels[ccid] = perpgklarr$ 0 1lowast Group key

(st outp) = Contractcid (sk119894 stateminusrarr0 cp)

append (ccid (gk cid st cp)) to channels

ct = Enc (gk outp)return (ct)

(5) On receive (ldquoauthenticate ccid R cert)abort if certs[ccid][pkR] neperpparse cert as (aux 120590) Verify (pkR aux 120590)extract state0rsquo from aux check state0rsquo on Blockchaincerts[ccid][pkR] = cert

(6) On receive (ldquosend ccid inp)assert certs[b] neperp(ck cid st cp) = channles[ccid](stacute outp) = Contractcid (sk state st inp)update channels[ccid] to (ck cid stacute cp)aux = (pk∥inp∥strsquo∥outp) ct = Enc (ck aux)return (ct)

(7) On receive (ldquoclaim)freeze send functiontx = certlowast∥state 120590 = Sign (sktx)return (tx∥120590)

Figure 4 prog119890119899119888119897119886119907119890 program of ΠSpeedster

6

Protocol ΠSpeedster (P0P1P2 P119873 ]

contractSpeedsterParameters

119871119890119889119892119890119903 Append only public ledger of F119887119897119900119888119896119888ℎ119886119894119899119862119900119894119899 Blockchain function that convert value into coins

On receive (ldquodeposit tx) from Passert tx notin 119871119890119889119892119890119903

execute tx on the 119861119897119900119888119896119888ℎ119886119894119899append tx to 119871119890119889119892119890119903

On receive (ldquoclaim tx) from Pparse tx as (certlowast state) state contains channel dataFor each cert in certlowast

parse cert to (toacute fromacute 120590 )abort if Verify(120590 cert) fails verify the certextract $119907119886119897 from state[from]assert $119907119886119897 ne 0 and toacute = Psend(from P Coin($119907119886119897 )) if $119907119886119897 gt 0send(P from Coin(minus$119907119886119897)) otherwise

append(tx) to 119871119890119889119892119890119903

On receive (ldquoread tx) from Poutput 119871119890119889119892119890119903 [tx]

Figure 5 On-chain smart contract contractSpeedster of

ΠSpeedster

Deposit To deposit a node needs to complete the following stepsFirst it sends a tx to contractSpeedster on the main chain The transac-tion includes the pk of the enclave account acc119890119899119888119897119886119907119890 as the accountaddress Next the node calls the the function (2) of prog119890119899119888119897119886119907119890 bysending message ldquodeposit and passing tx as a parameter Finallyprog119890119899119888119897119886119907119890 verifies the signature of tx and updates the local initialstate state0

Certified Channel Each certified channel in ΠSpeedster is iden-tified by a channel ID ccid A shared channel key ck is produced inthis step The certificate cert of the channel is created using publickeys of both parties To prevent rollback attacks on 120590119886119905119905 prog119890119899119888119897119886119907119890generates a signature 120590119886119905119905 by signing the tuple (state0 pk119894 119894isin01 prog119890119899119888119897119886119907119890 ) for each channel after function (3) returns The tupleis signed under the manufacture secret key msk to reflect the roottrust of the hardware The cert is verified in function (5)

Multi-Party State Channel A multi-party state channel is builtupon the existing certified channels To create a multi-party statechannel a node calls the function (4) of prog119890119899119888119897119886119907119890 by sendingldquoopenMulti message and passes a set of ccid to inform the underlyingcertified channels with other nodes We abstract out the process ofmulti-party shared key generation which could be replaced by anysecure multi-party key negotiation protocol [12 16 20]

Transaction To send a channel transaction a node calls thefunction (6) of prog119890119899119888119897119886119907119890 by sending ldquosend command to prog119890119899119888119897119886119907119890through G119886119905119905 resume(middot) and passing the target ccid along with othernecessary parameters in inp Then prog119890119899119888119897119886119907119890 executes inp with the

associated contract by calling Contractcid (middot) and updates the chan-nel state accordingly A channel transaction is constructed over thepublic key of pk the new channel state stateprime the input inp and theoutput outp Then the transaction is encrypted by an authenticatedencryption schemesuch as AES-GCM with the channel key ck

Claim To claim the fund that P has received from the channeltransactions the node issues a ldquoclaim call to the function (7) ofprog119890119899119888119897119886119907119890 prog119890119899119888119897119886119907119890 first freezes all two-party channels and ex-tracts all the certs from those channels The certs and the local nodestate state constitute the claim transaction tx prog119890119899119888119897119886119907119890 then signstxwith the private key sk of acc119890119899119888119897119886119907119890 and returns the signed transac-tion that is further forwarded by the node to the contractSpeedster Inthe end contractSpeedster verifies and executes the claim transactionon the Blockchain to redeem the fund for the node

6 SECURITY AND PRIVACY ANALYSIS

We formalize a Universal Composability (UC) [11 27 61 64] idealfunctionality FSpeedster (shown in Figure 8 in the Appendix) torealize the security goals of ΠSpeedster

Participants of FSpeedster are denoted as P The internal com-munication among participants is protected through an authen-ticated encryption scheme Following [27] [29] we parameterizeFSpeedster with a leakage function ℓ (middot) 0 1lowast minusrarr 0 1lowast to demon-strate the amount of privacy leaked from the message that is en-crypted by the authenticated encryption scheme The security ofΠSpeedster is given in Theorem 1

Theorem 1 (UC-Security of ΠSpeedster) If the adopted au-thenticated encryption AE is IND-CCA secure and digital signaturescheme Σ is EU-CMA secure then the protocol ΠSpeedster securely UC-realizes the ideal functionality FSpeedster in the (G119886119905119905 F119887119897119900119888119896119888ℎ119886119894119899)-hybrid model for static adversaries

As defined in Theorem 1 we now formally present the proofthat the protocol ΠSpeedster securely UC-realizes ideal function-ality FSpeedster by showing that an ideal world simulator S cansimulate the behavior of a real-world adversary A The securityof ΠSpeedster is proved by showing that S can indistinguishablysimulate the behavior of A for all environment E [27]

Proof Let E be an environment and A be a real-world proba-bilistic polynomial time adversary [27] who simply relays messagesbetween E and dummy parties To show thatΠSpeedster UC-realizesFSpeedster we specify below a simulator S such that no environ-ment can distinguish an interaction between ΠSpeedster and Afrom an interaction with FSpeedster and S That is for any E Sshould satisfy

forallE EXECEΠSpeedster A asymp EXECEFSpeedster S

Construction of S Please refer Appendix A for the construc-tion detail

Indistinguishability We show that the execution of the real-world and ideal-world is indistinguishable for all E from the view ofA by a series of hybrid steps that reduce the real-world executionto the ideal-world executionbull Hybrid 1198670 is the real-world execution of Speedster

7

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

5 ΠSpeedster PROTOCOL

In this section we first introduce the abstracted ideal functionalitiesin Speedster and then formally present the concrete Speedsterprotocol ΠSpeedster

51 Ideal Functionality

In ΠSpeedster two ideal functionalities are assumed a Blockchainabstraction F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] and a TEE abstraction G119886119905119905 for-mally defined in [81] As a result the design and security of Speed-ster are independent of the specific Blockchain and TEE implemen-tations as long as they can provide the required functions Specifi-cally we define F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] as an ideal functionality thatmodels the behavior of Blockchain F119887119897119900119888119896119888ℎ119886119894119899 defines a smart-contract enabled append-only ledger The parameter 119862119900119899119905119903119886119888119905 isthe smart contract function of the Blockchain F119887119897119900119888119896119888ℎ119886119894119899 has aninternal 119878119905119900119903119886119892119890 that contains the Blockchain data associated withtransaction IDs To append a transaction to the Blockchain a usersends a transaction to F119887119897119900119888119896119888ℎ119886119894119899 which will subsequently triggerthe function ldquoappend to execute the transaction (see Figure 10 in theAppendix for details)G119886119905119905 [81] provides an abstraction for the general-purpose TEE-

enabled secure processor During initialization G119886119905119905 creates a keypair as the manufacture key (msk mpk) while msk is preserved in theprocessor and the mpk could be accessed through ldquogetpk commandIn such an ideal functionality user first creates an enclave and loadsprog119890119899119888119897119886119907119890 into enclave by sending an ldquoinstall command To call thefunctions in prog119890119899119888119897119886119907119890 user sends ldquoresume command to G119886119905119905 alongwith the parameters All operations through the ldquoresume commandof G119886119905119905 is signed with msk by default to ensure the authenticitywhereas Certified Channel leverages symmetric-key authenticatedencryption instead of digital signatures Therefore we add a switch

to ldquoresume command to be able to turn off the signature and onlywhen the switch is set execution output through ldquoresume is signed(see Figure 9 in the Appendix for detail)

52 Speedster Protocol ΠSpeedster

We formally present the protocol ΠSpeedster into two parts the pro-gram prog119890119899119888119897119886119907119890 in Figure 4 that runs the enclave and the smartcontract contractSpeedster running on the Blockchain shown in Fig-ure 5 In the protocol we let P denotes a user R as the counterpartusers in a channel and tx represents an on-chain transaction Toexecute an off-chain smart contract in prog119890119899119888119897119886119907119890 we define a func-tion Contractcid (middot) which is parameterized with a smart contractid cid Contractcid (middot) consumes the channel state and node balanceto ensure the balance consistent across channels Contractcid (middot)generates output outp based on the input and updates the channelstate

Node Initialization For the first time to boot up a Speedsternode a node sends the ldquoinstall command to the enclave to loadprog119890119899119888119897119886119907119890 Then the node calls the function (1) of prog119890119899119888119897119886119907119890 bysending message (ldquoinit) to create an enclave account acc119890119899119888119897119886119907119890 withkey pair (sk pk) For attestation purpose a measurement 120590119886119905119905 ofthe enclave is generated with the prog119890119899119888119897119886119907119890 the public key pk ofacc119890119899119888119897119886119907119890 and the node initial state state0

Protocol ΠSpeedster (P0P1P2 P119873 ]

Program prog119890119899119888119897119886119907119890Initially

bal = empty certs = empty channels = empty state0 = perp

(1) On receive(ldquoinit)(pk sk) larr$KGen(1119899) generate acc119890119899119888119897119886119907119890mpk = G119886119905119905 getpk()return (pkmpk)

(2) On receive (ldquodeposit tx)parse tx as (_ pkrsquo $val 120590)assert $val ge 0 assert Verify(pk tx 120590)bal += $val add tx to state0

(3) On receive (ldquoopen cid R inp)ccid = H(119878119874119877119879 pkR pk)abort if channels[ccid] neperpcklarr$ 0 1lowast channel keycp = pk pkR (st outp) = Contractcid (sk bal

minusrarr0 cp)append (ccid (ck cid st cp)) to channels

120590 = sign(sk pk119877 ∥inp∥state0) cert = (pk∥pk119877 ∥inp∥120590)return (cert state0 outp)

(4) On receive (ldquoopenMulti cid ccidlowast)for each ccidprime isin ccidlowast

assert channels[ccidprime] neperpextract pkprime from channels[ccidprime]

cp = pkprimelowast cup pk ccid = H(119878119874119877119879 (cp))assert channels[ccid] = perpgklarr$ 0 1lowast Group key

(st outp) = Contractcid (sk119894 stateminusrarr0 cp)

append (ccid (gk cid st cp)) to channels

ct = Enc (gk outp)return (ct)

(5) On receive (ldquoauthenticate ccid R cert)abort if certs[ccid][pkR] neperpparse cert as (aux 120590) Verify (pkR aux 120590)extract state0rsquo from aux check state0rsquo on Blockchaincerts[ccid][pkR] = cert

(6) On receive (ldquosend ccid inp)assert certs[b] neperp(ck cid st cp) = channles[ccid](stacute outp) = Contractcid (sk state st inp)update channels[ccid] to (ck cid stacute cp)aux = (pk∥inp∥strsquo∥outp) ct = Enc (ck aux)return (ct)

(7) On receive (ldquoclaim)freeze send functiontx = certlowast∥state 120590 = Sign (sktx)return (tx∥120590)

Figure 4 prog119890119899119888119897119886119907119890 program of ΠSpeedster

6

Protocol ΠSpeedster (P0P1P2 P119873 ]

contractSpeedsterParameters

119871119890119889119892119890119903 Append only public ledger of F119887119897119900119888119896119888ℎ119886119894119899119862119900119894119899 Blockchain function that convert value into coins

On receive (ldquodeposit tx) from Passert tx notin 119871119890119889119892119890119903

execute tx on the 119861119897119900119888119896119888ℎ119886119894119899append tx to 119871119890119889119892119890119903

On receive (ldquoclaim tx) from Pparse tx as (certlowast state) state contains channel dataFor each cert in certlowast

parse cert to (toacute fromacute 120590 )abort if Verify(120590 cert) fails verify the certextract $119907119886119897 from state[from]assert $119907119886119897 ne 0 and toacute = Psend(from P Coin($119907119886119897 )) if $119907119886119897 gt 0send(P from Coin(minus$119907119886119897)) otherwise

append(tx) to 119871119890119889119892119890119903

On receive (ldquoread tx) from Poutput 119871119890119889119892119890119903 [tx]

Figure 5 On-chain smart contract contractSpeedster of

ΠSpeedster

Deposit To deposit a node needs to complete the following stepsFirst it sends a tx to contractSpeedster on the main chain The transac-tion includes the pk of the enclave account acc119890119899119888119897119886119907119890 as the accountaddress Next the node calls the the function (2) of prog119890119899119888119897119886119907119890 bysending message ldquodeposit and passing tx as a parameter Finallyprog119890119899119888119897119886119907119890 verifies the signature of tx and updates the local initialstate state0

Certified Channel Each certified channel in ΠSpeedster is iden-tified by a channel ID ccid A shared channel key ck is produced inthis step The certificate cert of the channel is created using publickeys of both parties To prevent rollback attacks on 120590119886119905119905 prog119890119899119888119897119886119907119890generates a signature 120590119886119905119905 by signing the tuple (state0 pk119894 119894isin01 prog119890119899119888119897119886119907119890 ) for each channel after function (3) returns The tupleis signed under the manufacture secret key msk to reflect the roottrust of the hardware The cert is verified in function (5)

Multi-Party State Channel A multi-party state channel is builtupon the existing certified channels To create a multi-party statechannel a node calls the function (4) of prog119890119899119888119897119886119907119890 by sendingldquoopenMulti message and passes a set of ccid to inform the underlyingcertified channels with other nodes We abstract out the process ofmulti-party shared key generation which could be replaced by anysecure multi-party key negotiation protocol [12 16 20]

Transaction To send a channel transaction a node calls thefunction (6) of prog119890119899119888119897119886119907119890 by sending ldquosend command to prog119890119899119888119897119886119907119890through G119886119905119905 resume(middot) and passing the target ccid along with othernecessary parameters in inp Then prog119890119899119888119897119886119907119890 executes inp with the

associated contract by calling Contractcid (middot) and updates the chan-nel state accordingly A channel transaction is constructed over thepublic key of pk the new channel state stateprime the input inp and theoutput outp Then the transaction is encrypted by an authenticatedencryption schemesuch as AES-GCM with the channel key ck

Claim To claim the fund that P has received from the channeltransactions the node issues a ldquoclaim call to the function (7) ofprog119890119899119888119897119886119907119890 prog119890119899119888119897119886119907119890 first freezes all two-party channels and ex-tracts all the certs from those channels The certs and the local nodestate state constitute the claim transaction tx prog119890119899119888119897119886119907119890 then signstxwith the private key sk of acc119890119899119888119897119886119907119890 and returns the signed transac-tion that is further forwarded by the node to the contractSpeedster Inthe end contractSpeedster verifies and executes the claim transactionon the Blockchain to redeem the fund for the node

6 SECURITY AND PRIVACY ANALYSIS

We formalize a Universal Composability (UC) [11 27 61 64] idealfunctionality FSpeedster (shown in Figure 8 in the Appendix) torealize the security goals of ΠSpeedster

Participants of FSpeedster are denoted as P The internal com-munication among participants is protected through an authen-ticated encryption scheme Following [27] [29] we parameterizeFSpeedster with a leakage function ℓ (middot) 0 1lowast minusrarr 0 1lowast to demon-strate the amount of privacy leaked from the message that is en-crypted by the authenticated encryption scheme The security ofΠSpeedster is given in Theorem 1

Theorem 1 (UC-Security of ΠSpeedster) If the adopted au-thenticated encryption AE is IND-CCA secure and digital signaturescheme Σ is EU-CMA secure then the protocol ΠSpeedster securely UC-realizes the ideal functionality FSpeedster in the (G119886119905119905 F119887119897119900119888119896119888ℎ119886119894119899)-hybrid model for static adversaries

As defined in Theorem 1 we now formally present the proofthat the protocol ΠSpeedster securely UC-realizes ideal function-ality FSpeedster by showing that an ideal world simulator S cansimulate the behavior of a real-world adversary A The securityof ΠSpeedster is proved by showing that S can indistinguishablysimulate the behavior of A for all environment E [27]

Proof Let E be an environment and A be a real-world proba-bilistic polynomial time adversary [27] who simply relays messagesbetween E and dummy parties To show thatΠSpeedster UC-realizesFSpeedster we specify below a simulator S such that no environ-ment can distinguish an interaction between ΠSpeedster and Afrom an interaction with FSpeedster and S That is for any E Sshould satisfy

forallE EXECEΠSpeedster A asymp EXECEFSpeedster S

Construction of S Please refer Appendix A for the construc-tion detail

Indistinguishability We show that the execution of the real-world and ideal-world is indistinguishable for all E from the view ofA by a series of hybrid steps that reduce the real-world executionto the ideal-world executionbull Hybrid 1198670 is the real-world execution of Speedster

7

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

Protocol ΠSpeedster (P0P1P2 P119873 ]

contractSpeedsterParameters

119871119890119889119892119890119903 Append only public ledger of F119887119897119900119888119896119888ℎ119886119894119899119862119900119894119899 Blockchain function that convert value into coins

On receive (ldquodeposit tx) from Passert tx notin 119871119890119889119892119890119903

execute tx on the 119861119897119900119888119896119888ℎ119886119894119899append tx to 119871119890119889119892119890119903

On receive (ldquoclaim tx) from Pparse tx as (certlowast state) state contains channel dataFor each cert in certlowast

parse cert to (toacute fromacute 120590 )abort if Verify(120590 cert) fails verify the certextract $119907119886119897 from state[from]assert $119907119886119897 ne 0 and toacute = Psend(from P Coin($119907119886119897 )) if $119907119886119897 gt 0send(P from Coin(minus$119907119886119897)) otherwise

append(tx) to 119871119890119889119892119890119903

On receive (ldquoread tx) from Poutput 119871119890119889119892119890119903 [tx]

Figure 5 On-chain smart contract contractSpeedster of

ΠSpeedster

Deposit To deposit a node needs to complete the following stepsFirst it sends a tx to contractSpeedster on the main chain The transac-tion includes the pk of the enclave account acc119890119899119888119897119886119907119890 as the accountaddress Next the node calls the the function (2) of prog119890119899119888119897119886119907119890 bysending message ldquodeposit and passing tx as a parameter Finallyprog119890119899119888119897119886119907119890 verifies the signature of tx and updates the local initialstate state0

Certified Channel Each certified channel in ΠSpeedster is iden-tified by a channel ID ccid A shared channel key ck is produced inthis step The certificate cert of the channel is created using publickeys of both parties To prevent rollback attacks on 120590119886119905119905 prog119890119899119888119897119886119907119890generates a signature 120590119886119905119905 by signing the tuple (state0 pk119894 119894isin01 prog119890119899119888119897119886119907119890 ) for each channel after function (3) returns The tupleis signed under the manufacture secret key msk to reflect the roottrust of the hardware The cert is verified in function (5)

Multi-Party State Channel A multi-party state channel is builtupon the existing certified channels To create a multi-party statechannel a node calls the function (4) of prog119890119899119888119897119886119907119890 by sendingldquoopenMulti message and passes a set of ccid to inform the underlyingcertified channels with other nodes We abstract out the process ofmulti-party shared key generation which could be replaced by anysecure multi-party key negotiation protocol [12 16 20]

Transaction To send a channel transaction a node calls thefunction (6) of prog119890119899119888119897119886119907119890 by sending ldquosend command to prog119890119899119888119897119886119907119890through G119886119905119905 resume(middot) and passing the target ccid along with othernecessary parameters in inp Then prog119890119899119888119897119886119907119890 executes inp with the

associated contract by calling Contractcid (middot) and updates the chan-nel state accordingly A channel transaction is constructed over thepublic key of pk the new channel state stateprime the input inp and theoutput outp Then the transaction is encrypted by an authenticatedencryption schemesuch as AES-GCM with the channel key ck

Claim To claim the fund that P has received from the channeltransactions the node issues a ldquoclaim call to the function (7) ofprog119890119899119888119897119886119907119890 prog119890119899119888119897119886119907119890 first freezes all two-party channels and ex-tracts all the certs from those channels The certs and the local nodestate state constitute the claim transaction tx prog119890119899119888119897119886119907119890 then signstxwith the private key sk of acc119890119899119888119897119886119907119890 and returns the signed transac-tion that is further forwarded by the node to the contractSpeedster Inthe end contractSpeedster verifies and executes the claim transactionon the Blockchain to redeem the fund for the node

6 SECURITY AND PRIVACY ANALYSIS

We formalize a Universal Composability (UC) [11 27 61 64] idealfunctionality FSpeedster (shown in Figure 8 in the Appendix) torealize the security goals of ΠSpeedster

Participants of FSpeedster are denoted as P The internal com-munication among participants is protected through an authen-ticated encryption scheme Following [27] [29] we parameterizeFSpeedster with a leakage function ℓ (middot) 0 1lowast minusrarr 0 1lowast to demon-strate the amount of privacy leaked from the message that is en-crypted by the authenticated encryption scheme The security ofΠSpeedster is given in Theorem 1

Theorem 1 (UC-Security of ΠSpeedster) If the adopted au-thenticated encryption AE is IND-CCA secure and digital signaturescheme Σ is EU-CMA secure then the protocol ΠSpeedster securely UC-realizes the ideal functionality FSpeedster in the (G119886119905119905 F119887119897119900119888119896119888ℎ119886119894119899)-hybrid model for static adversaries

As defined in Theorem 1 we now formally present the proofthat the protocol ΠSpeedster securely UC-realizes ideal function-ality FSpeedster by showing that an ideal world simulator S cansimulate the behavior of a real-world adversary A The securityof ΠSpeedster is proved by showing that S can indistinguishablysimulate the behavior of A for all environment E [27]

Proof Let E be an environment and A be a real-world proba-bilistic polynomial time adversary [27] who simply relays messagesbetween E and dummy parties To show thatΠSpeedster UC-realizesFSpeedster we specify below a simulator S such that no environ-ment can distinguish an interaction between ΠSpeedster and Afrom an interaction with FSpeedster and S That is for any E Sshould satisfy

forallE EXECEΠSpeedster A asymp EXECEFSpeedster S

Construction of S Please refer Appendix A for the construc-tion detail

Indistinguishability We show that the execution of the real-world and ideal-world is indistinguishable for all E from the view ofA by a series of hybrid steps that reduce the real-world executionto the ideal-world executionbull Hybrid 1198670 is the real-world execution of Speedster

7

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

bull Hybrid 1198671 behaves the same as 1198670 except that S generates keypair (sk pk) for digital signature scheme Σ for each dummy partyP and publishes the public key pk WheneverA wants to call G119886119905119905 S faithfully simulates the behavior of G119886119905119905 and relay output to P119894 Since S perfectly simulates the protocol E could not distinguish1198671 from 1198670bullHybrid1198672 is similar to1198671 except thatS also simulatesF119887119897119900119888119896119888ℎ119886119894119899 Whenever A wants to communicate with F119887119897119900119888119896119888ℎ119886119894119899 S emulatesthe behavior of F119887119897119900119888119896119888ℎ119886119894119899 internally E cannot distinguish be-tween 1198672 and 1198671 as S perfectly emulates the interaction betweenA and F119887119897119900119888119896119888ℎ119886119894119899 bull Hybrid 1198673 behaves the same as 1198672 except that IfA invokes G119886119905119905with a correct install message with program prog119890119899119888119897119886119907119890 then forevery correct ldquoresume message S records the tuple (outp 120590) fromG119886119905119905 where outp is the output of running prog119890119899119888119897119886119907119890 in G119886119905119905 and 120590is the signature generated inside the G119886119905119905 using the sk generatedin 1198671 Let Ω denote all such possible tuples If (outp 120590) notin Ω thenS aborts otherwise S delivers the message to counterpart 1198673 isindistinguishable from1198672 by reducing the problem to the EUF-CMAof the digital signature scheme IfA does not send one of the correcttuples to the counterpart it will fail on attestation Otherwise Eand A can be leveraged to construct an adversary that succeeds ina signature forgerybull Hybrid 1198674 behaves the same as 1198673 except that S generates achannel key ck for each channel WhenA communicates with G119886119905119905on sending transaction through channel S records ct from G119886119905119905 where ct is the ciphertext of encrypted transaction using the ck

of that channel Let Ω denote all such possible strings If ct notin Ωthen S aborts otherwise S delivers the message to counterpart1198674 is indistinguishable from 1198673 by reducing the problem to theIND-CCA of the authenticated encryption scheme As A does nothold control of ck it can not distinguish the encryption of a randomstring and Ωbull Hybrid 1198675 is the execution in the ideal-world 1198675 is similar to1198674 except that S emulates all real-world operations As we dis-cussed above S could faithfully map the real-world operations intoideal-world execution from the view of A Therefore no E coulddistinguish the execution from the real-world protocol ΠSpeedsterand A with S and FSpeedster

Theorem 1 also implies stronger privacy protection comparedto conventional paymentstate channel networks in that (1) Allchannels in Speedster are created directly between participants Nointermediate node is required to relay transactions thus alleviatingthe privacy concerns introduced by HTLC [39 49 50 68] (2) thetransaction in off-chain channels is encrypted by AES-GCM and onlythe enclaves of participants can decrypt it Therefore transactionconfidentiality is ensured by Speedster

Preventing Double-Spending Attacks Each processor has aunique built-in key hard-coded in the CPU [4 6] to differentiatetheir identities during attestation Moreover the processor gener-ates and assigns each enclave a unique identifier [4 51] ensuringthat even enclaves created by the same processor are distinctiveTo prevent the double-spending attacks in the channel prog119890119899119888119897119886119907119890updates the balance before sending transactions to the peers Once

the state is updated it can not be rolled back Therefore no fundcould be spent multiple times in Speedster

Defending Against TEE Attacks The hardware-assisted TEEserves as a way to replace complex software-based cryptographicoperations Promising as it is recent research shows that TEE imple-mentations on specific platforms are vulnerable to the side-channelattacks [48 78 85 92 94] rollback attacks [21 33 70] and incorrectimplementation and configurations [13 23 53 80] In Speedsterwe use the TEE abstraction without relying on a specific platformThe design is generalized for different environments and the secu-rity has been proven in Theorem 1 On the other hand we offersuggestions and proactively implement mitigations for the abovevulnerabilities from both hardware and software levels For ex-ample we use SEV-SE [4] to protect against specific speculativeside-channel attacks and TCB rollback attacks We also update themicrocode of IntelAMDARM TEE to the latest version Besidesproper implementation of the system can also help mitigate knownside-channel vulnerabilities [52] Speedster uses a side-channel-attack resistant cryptographic library [71] and requires that allnodes are running on the latest version of the firmware to defendagainst known TEE attacks Further an adversary may launch aDoS attack against the node by blocking the Internet connection ofthe victim or abruptly shut down the OS to force stop the enclavefunctions These DoS attacks are not the focus of this work but canbe addressed by adopting a committee enforcement design [29 64]The state of a channel node is jointly managed by a committeeof TEE nodes to tolerate Byzantine fault Despite the inevitableperformance loss in light of the complexity of the committee chainSpeedster still outperforms the prior work by enabling efficientmulti-party state processing and management in a fully decentral-ized fashion (see Section 43 and Section 724)

7 IMPLEMENTATION AND EVALUATION

In this section we first overview the implementation of Speedsteron various platforms (ie Intel AMD and ARM) Then we elaborateon the configurations of the underlying platforms and present theevaluation results of Speedster

71 Implementation of Speedster

We build a Virtual Machine (VM) on top of the open-source C++ de-veloped Ethereum Virtual Machine eEVM [31] which allows Speed-ster to run Ethereum smart contracts off-the-shelf The crypto-graphic library used in prog119890119899119888119897119886119907119890 is mbedTLS [71] an open-sourceSSL library ported to TEE [32 100] For this work we adopt 1)SHA256 to generate secret seeds in the enclave and to get the hashvalue of a claim transaction 2) AES-GCM [74] to authentically en-crypt transactions in the state channel and 3) ECDSA [56] to signthe cert and the claim transaction We also customize the OpenEn-clave [32] to compile the prototype for Intel and ARM platformsFor AMD SEV we use VMs as the enclaves to run prog119890119899119888119897119886119907119890 Thehost can communicate with the enclave via the socket To highlightthe advantages of Speedster the performances of a few functionsare tested as discussed below

Direct Transactions (Trade) This function is implemented in C++and allows users to directly transfer fund or share messages through

8

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

channels without calling an off-chain smart contract Before send-ing a transaction out the sender first updates the local enclave state( eg the account balance) and then marks the transaction as ldquosentThe communication between the sender and receiver enclaves isprotected by AES-GCM

Instant State Sharing We implement an instant state sharingfunction in C++ to allow a user to create direct channels withother users off-chain We also remove costly signature operationsfor transactions and replace it with AES-GCM thereby significantlyreducing the communication overhead and enabling instant in-formation exchange (like high-quality videoaudio sharing) whilepreserving privacy This is difficult to realize with prior researchefforts using asymmetric cryptographic functions [64 66 76]

Faster Fund Exchange We implement a ERC20 contract [93] with50 LOC in Solidity [34] to demonstrate the improved performanceof Speedster in executing off-chain smart contracts This can beattributed to the elimination of asymmetric signature operationsfor its off-chain transactions

Sequential Contract Execution To highlight the performance ofSpeedster in executing sequential transaction contracts we im-plement the popular two-party Gomoku chess smart contract with132 LOC in Solidity Furthermore players cannot reuse locked fund

until the game ends thus nullifying all benefits from cheating thesystem

Parallel Contract Execution Applications that need users to actsimultaneously such as Rock-Paper-Scissors (RPS) are not easyto achieve in conventional sequentially structured state channelsSpeedster supports applications running in parallel faithfully man-ages the states and only reveals the final results to players Weimplement a typical two-party RPS game with 64 LOC in Solidityto demonstrate this

Multi-party Applications To test the ability of multi-party off-chain smart contract executions a Monopoly game smart contractwith 231 LOC in Solidity is implemented In this game players taketurns to roll two six-sided dice to decide how many steps to moveforward in turn and how to interact with other players

72 Evaluation

SGX platform We test Speedster with a quad-core 36 GHz In-tel(R) E3-1275 v5 CPU [54] with 32 GB memory The operatingsystem that we use is Ubuntu 18043 TLS with Linux kernel version500-32-generic We also deploy LN nodes [65] as the baseline forcomparison on another physical machine with the same configura-tionsSEV platform We evaluate Speedster on an SEV platform with 64GB DRAM and an SEV-enabled AMD Epyc 7452 CPU [3] which has32 cores and a base frequency of 235 GHz The operating systeminstalled on the AMD machine is Ubuntu 18044 LTS with an AMDpatched kernel of version 4200-sev [4] The version of the QEMUemulator that we use to run the virtual machine is 2120-dirty Thevirtual machine runs Ubuntu 1804 LTS with the kernel version4150-101-generic and 4 CPU cores

TrustZone platform The evaluation of TrustZone is carried out inthe QEMU cortex-a57 virtual machine with 1 GBmemory and Linuxbuildroot 41467-g333dc9e97-dirty as the kernel

Table 1 Line of code in Speedster

Component Code LOC Total()

Shared eEVM [31] C++ 253k 253k

SGXTrustZoneprog119890119899119888119897119886119907119890 C++ 31k 54kother C++ 23k

AMD SEVprog119890119899119888119897119886119907119890 C++ 37k 78kother C++ 41k

721 Code Size To port eEVM into Speedster we added extra650 LOC to eEVM In general the eEVM contains 32119896 LOC in C++and another 221119896 LOC coming from its reliance

Speedster is evaluated on Intel AMD and ARM platformswith around 385119896 LOC in total as shown in Table 1 Specifically253119896 LOC comes from the contract virtual machine eEVM [31]which is shared with all cases prog119890119899119888119897119886119907119890 has 31119896 LOC in C++ forSGXTrustZone and 37119896 LOC for AMD SEV The contractSpeedsterdeployed on the Blockchain is implemented with 109 LOC in Solid-ity

722 Time Cost for Transaction Authentication In the Speedsterprototype we use AES-GCM to replace ECDSA that is adopted in pre-vious channel projects for transaction authentication By trustingthe secure enclave Speedster uses efficient symmetric operationsto realize both confidentiality and authenticity of transactions atthe same time Figure 6 shows the comparison of the performancebetween ECDSA and AES-GCM when processing data of the size 128bytes 256 bytes and 1024 bytes respectively This experiment iscarried out on Intel AMD and ARM platforms with four operationsECDSA sign ECDSA verify AES-GCM encrypt and AES-GCM decryptECDSA is evaluated under secp256k1 curve The key size of ECDSAis 256 bits while that of AES-GCM is 128 bits

100 101 102 103 104 105

Time( s)

trustzone_ecdsa_sign

trustzone_ecdsa_verf

trustzone_aes_enc

trustzone_aes_dec

sgx_ecdsa_sign

sgx_ecdsa_verf

sgx_aes_enc

sgx_aes_dec

sev_ecdsa_sign

sev_ecdsa_verf

sev_aes_enc

sev_aes_dec 128 bytes256 bytes1024 bytes

Figure 6 Performance comparison between ECDSA and

AES-GCM enabled transaction security on SGX SEV andTrust-

Zone platforms

9

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

Figure 6 is plotted on a log scale We can see that regardless of thetested platform AES-GCM is 3minus4 orders of magnitude faster BesidesAES-GCM performs better with small-sizedmessagesWith increaseddata size the time cost of ECDSA remains constant while that ofAES-GCM grows This is because ECDSA always signs a constanthash digest rather than the actual data In practice the averagetransaction size on the Ethereum is 405 bytes [43] Therefore usingsymmetric-key operations will significantly boost the transaction-related performance

723 Transaction Performance We evaluate Speedster on thetime cost for transactions in a direct channel under the test casesin Section 71 on Intel AMD and ARM platforms In this experi-ment we use the popular layer-2 network the LN as the baselineWe measure the time cost for transactions over a direct channelwhich may include the time cost for transaction generation andconfirmation corresponding contract execution transmission inthe local network and other related activities in a life cycle ofan off-chain transaction We test Speedster in AES-GCM mode toreflect our intended symmetric-key design Additionally we alsotest the batching transaction performance as a comparison withTeeChain [64]

Table 2 Local time cost for end-to-end transaction (119898119904)

Payment ERC20 Gomuku RPC

LN 192630 NA NA NASEVAES-GCM 01372 01382 06667 01365SGXAES-GCM 00205 03500 04500 01930TZAES-GCM 20496 40148 95092 37215

The experiment result is an average of 10000 trials and is shownin Table 2 with the implemented smart contracts ERC20 Gomokuand rock-paper-scissor (RPC)

Evaluation on SGX The evaluation of Speedster on the SGXplatform is carried out by running two Speedster instances onthe same SGX machine Direct transaction without contract execu-tion takes 00205119898119904 with AES-GCM which is four orders of magni-tude faster compared to LN When calling smart contracts it takes01930119898119904 minus 04500119898119904 to process a contract-calling transaction

Evaluation on AMD As there is no available AMD cloud virtualmachine that supports SEV we only evaluate Speedster on theAMD platform by running the prog119890119899119888119897119886119907119890 in two Ubuntu guestvirtual machines as the enclaves To protect the code and data ofprog119890119899119888119897119886119907119890 that runs in the enclave we only allow users to accessprog119890119899119888119897119886119907119890 by calling the related interface through the socket

For the direct transaction SEVAES-GCM takes an average of01372119898119904 When invoking smart contracts the time cost varies fordifferent applications As shown in Table 2 RPC (01365119898119904) andERC20 (01382119898119904) are faster than Gomoku (06667119898119904) due to theirsimple logic and fewer steps to take

Evaluation on ARM As the evaluation of ARM TrustZone runsupon the QEMU emulator the performance of ARM is the worstNevertheless the evaluation result in Table 2 shows that prog119890119899119888119897119886119907119890takes 20496119898119904 to run direct transactions which is around 9times betterthan LN For the smart contract execution it takes 30 minus 90119898119904 toprocess contract transactions

Table 3 Channel performance

Throughput (119905119901119904) Latency (119898119904)

LN(lnd) Speedster Change(times) LN(lnd) Speedster

Payment 14 72143 5153times 548183 80483ERC20 NA 30920 NA NA 82490RPC NA 53355 NA NA 80743Gomoku NA 2549 NA NA 82866

Real-world Evaluation To evaluate the performance of Speed-ster in the real world we deploy Speedster on two Azure StandardDC1s_v2 (1 vCPUs 4 GB memory) virtual machines which arebacked by the 37GHz Intel XEON E-2288G processor one in EastUS and the other in West Europe as shown in Figure 7 The kernelof the virtual machine is 530-1034-azure and the operating systemis version 18045 LTS LN node is deployed and evaluated on themachine as a baseline to highlight the significant performance im-provement of Speedster Table 3 shows the evaluation result Thethroughput of LN is 14119905119901119904 while Speedster achieves 72 143119905119901119904 onpayment operation 5 000times more efficient than LN Specifically thelatency to execute a Speedster transaction is around 80119898119904 closeto the RTT between testing hosts while the latency to run an LNpayment transaction is around 500119898119904

TeeChain is a TEE-supported payment channel network [64]We tried hard to run a head-to-head comparison with it but failedto do so dagger Instead we provide insights for a theoretical comparisonTeeChain nodes coupled with committee chains to defend againstnode failure Speedster can be adapted to a similar design butinevitably sacrifices the performance Dagger In this regard the through-put of the committee-based Speedster will be comparable withthat of TeeChain However Speedster is much more efficient inoff-chain channel creationclosure (see Section 725 ) and supportsmulti-party state processing

Azure Standard DC1s_v2

West Europe

Enclave

Azure Standard DC1s_v2

East USRTT80ms

Bandwidth 281MbpsEnclave

Figure 7 Network setup for the evaluation

724 Channel System Comparison Speedster supports efficientmulti-party state channel creation and closure To highlight theadvantages of Speedster we compare Speedsterwith other majorexisting channel projects Table 4 shows the difference in termsof the following features Direct off-chain channel openclosuredynamic deposit (dynamically adjusting fund in an existing channelon demand [64]) symmetric-key operations for transactions (usingsymmetric encryption algorithms to ensure the authenticity and

daggerThough TeeChain is open source we were not able to successfully run the projecteven after we contacted the author of TeeChainDaggerEach fund spending needs to be approved by the committee using a multi-signature

10

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

Table 4 Feature comparison with other channel projects

FeaturesChannel Projects

LN [66] TeeChan [63] TeeChain [64] DMC [36] SFMC [24] Perun [39] Celer [37] Speedster

Direct Off-chain Channel Open

Direct Off-chain Channel Close

Dynamic Deposit

Off-Chain Contract Execution

Fully Distributed

Multi-Party State Channel

Dispute-Free

Duplex Channel

privacy of the off-chain transaction) off-chain smart contract ex-ecution full decentralization (see Definition 2) multi-party statechannel dispute-free and duplex channel (where both participantsof a channel can send fund back and forth)

We compare the functions provided by Speedster and TeeChainTeeChain is not a fully decentralized channel network Despitethe dynamic deposit and bilateral termination [64] every channelopened in TeeChain has to be associated with a deposit lockedon the main chain As a result similar to the Lightning networkcreating many channels requires freezing a significant amountof collateral on the Blockchain and incurring expensive on-chainoperations Therefore it is not realistic to build direct channelsfor any pair of nodes in the network Alternatively TeeChain stilllargely depends on HTLC for transaction routing in practice whichleads to privacy concerns On the contrary a deposit in Speedstercan be shared bymultiple off-chain channels Direct channels can beefficiently established Further TeeChain does not support the off-chain smart contract execution and multi-party state channels Thepairwise channel structure of TeeChain confines the state within thechannel In contrast due to balance sharing and Certified Channelstates across multiple channels can be managed and exchangedauthentically in the same Speedster account

In Perun [39] virtual channels can also be opened and closedoff the Blockchain but once the channel is created the underlyingledger channels have to be locked The minimum funds acrossthe ledger channels determine the available capacity As shown inTable 4 Speedster is the only off-chain state channel project

that accomplishes all the listed functions

725 Main Chain Cost Similar to the previous work [24 64] weevaluate the main chain cost (1) the number of required on-chaintransactions and (2) the number of pairs of public keys and signa-tures that are written to the Blockchain (defined as Blockchain costin [24])

We select a set of representative channel projects to evaluateand be compared with Speedster In particular we choose LN [66](the most popular payment channel system in reality) DMC [36](a duplex payment channel) TeeChain [64] (a TEE-based chan-nel project) and SFMC [24] (it also supports off-chain channelopenclosure) The comparison is carried out by analyzing eachproject under bilateral termination [64] ie a channel is closedwithout disputes The result is shown in Table 5 We take LN and

TeeChain for example to demonstrate the cost efficiency of Speed-ster

Before opening an LN channel each node has to send one on-chain transaction with a Blockchain Cost (BC) of 1 to commit adeposit in the channel Then each LN channel has to send one on-chain transaction with a BC of 2 To close this channel one of thechannelrsquos participants needs to send a transaction with the latestchannel state and signatures from both sides to the Blockchain

In TeeChain [64] a group of committee nodes handles and dy-namically associates deposits with channels Thus at least oneldquodeposit transaction is needed to set up the system with a BC of1 + 1199012 where 119901 is the size of the committee Since TeeChain canalso close the channel off the chain there is no associated costfor that All committee members in TeeChain use the same119898-out-of-119901 multi-signature for each ldquodeposit transaction so the BC is1 + 1199012 +119898

In contrast a deposit to a Speedster can be freely allocated todifferent channels Therefore we only need 1 ldquodeposit transactionto initialize the account and create 119888 channels There is no cost forchannel opening and closing as Speedster can do it completelyoffline To claim the remaining fund from active channels one on-chain transaction needs to be sent Assuming that one depositand one claim transactions are shared by 119888 channels on averageSpeedster requires 2119888 on-chain transactions with a BC of 2119888 foreach channel on average

In summary we observe that Speedster needs 80 less on-chain transactions than LN and the same number of transactionsas TeeChain when 119888 ge 2 and one deposit when a 2-out-of-3 multi-signature is used for each TeeChain channel For the BC of eachchannel Speedster outperforms LN by at least 66 when 119888 ge 2and 97 if 119888 ge 11 [17] Compared to TeeChain Speedster reducesover 84 BC when 119888 ge 2

8 DISCUSSION

In this section we discuss other aspects of Speedster ie partialclaim from acc119890119899119888119897119886119907119890 unavailability of TEE and cross-chain statechannel

Partial Claim In Speedster one ldquoclaim transaction can be usedto freeze all the channels that belong to the same user and to with-draw all the fund from these channelsWe can also extend the currentfunction to support the partial claim In other words the user can

11

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

Table 5 Number of on-chain transactions and Blockchain Costs (BC) per channel

Payment ChannelSetup Open Channel Close Channel Claim Total

Notx BC Notx BC Notx BC Notx BC Notx BC

LN [66] 2 2 1 2 1 2 NA NA 4 6

TeeChain [64] 1 1+1199012 off chain off chain off chain off chain 1 1+1199012+119898 2 2+119901+119898

DMC [36] NA NA 1 2 1 2 NA NA 2 4

SFMC [24] 1119888 p119888 off chain off chain off chain off chain 1119888 119901119888 2119888 2119901119888

Speedster 1119888 1119888 off chain off chain off chain off chain 1119888 1119888 2119888 2119888

decide to claim a portion of the total funds in a channel As a resultthe partially-claimed channel can still operate as normal

Single Node Failure Our work is consistent with prior TEE-basedresearch that the availability of TEE is out of the investigationNevertheless we briefly discuss how to ensure the channel balancesafety when TEE fails to work correctly such as power failure andnetwork issues First unavailability will not cause a user to losestate The state of a faulty node can be recovered by authenticatedstates from other correct nodes Alternatively Speedster can alsoadopt committee-based protocols [29 64] to manage the accountstate Since the committee is only responsible for the channel setupit does not affect the channel performance such as throughput andother unique functionalities of Speedster compared to prior worksuch as TeeChain

Cross-chain State Channel Running inside the enclave prog119890119899119888119897119886119907119890does not rely on any particular Blockchain platform to operateTherefore it is possible to generate multiple enclave accounts anddeposit frommultiple Blockchain projects to these accounts Ideallythis would allow Speedster to create a cross-chain state channelthat could significantly reduce related costs We will leave this asour future work

Unilateral Certified Channel The current Certified Channel isbilateral which requires both participants to run in TEE-enablednodes and to issue certs This will be a burden to manage certs forthe nodes that intend to receive from other nodes In the futurework we plan to improve the protocol to enable a user to createunilateral Certified Channel where only the sender is required torun in the enclave

9 RELATEDWORK

HTLC Privacy and Security HTLC is one of the fundamentalbuilding blocks in the current layer-2 channel design to facilitatetransactions between parties without direct channel connections[66 82] But HTLC has privacy issues [39 49 50 68] and is vulner-able to various attacks [58 69 87 90] MAPPCN [89] MHTLC [68]AMHL [69] and CHTLC [98] tried to address the privacy issuesintroduced by HTLC by adding additional countermeasures MAD-HTLC [90] presented the mutual assured destruction HTLC thatcould mediate the bribery attack Nevertheless they introduce extraoverhead and still require HTLC Perun [39] enabled a user to cre-ate a virtual payment channel to avoid HTLC but it can only spantwo ledger channels In contrast Speedster allows all nodes toconnect directly without relying on HTLC and expensive on-chainoperations

Efficient Channel Network Multi-hop transactions in existingchannel networks [66 82] incurs non-negligible overhead with ca-pacity and scalability issues Current channel design addresses theproblem with distinct focuses For example MicroCash [2] intro-duced the escrow setup that supports concurrent micropaymentsSprites [76] is built on LN and reduced the latency of LN in multi-hop transactions Celer [37] leveraged a provably optimal valuetransfer routing algorithm to improve the HTLC routing perfor-mance Pisa [72] enabled the party to delegate itself to a third partyin case it goes off-line REVIVE [58] rebalanced the fund in chan-nels to increase the scalability of the payment channel networkLiquidity Network [44 59] used hubs to connect users which raisesprivacy and centralization concerns Speedster is a fully decen-tralized account-based channel network which outperforms theexisting channel networksMulti-PartyChannelNetwork Several relatedworks offermulti-party paymentstate channel solutions Based on Perun Dziem-bowski et al proposed the first multi-party state channel [38] thatoperates recursively among participants Burchert et al [24] pre-sented a multi-party channel with timelocks by adding a new layerbetween the Blockchain and the payment channel Hydra [28] intro-duced an isomorphic multi-party state channel by directly adoptingthe layer-1 smart contract system Speedster establishes a multi-party channel directly among participants without intermediariesthus reducing cost and enhancing securityBlockchain projects based on trusted hardware Using trustedhardware provides promising solutions to the issues in BlockchainFor instance Town Crier [101] used SGX to implement authenti-cated data feed for smart contracts Ekiden [29] and FastKitten [35]proposed Blockchain projects that can elevate the confidentialityof the smart contract In Tesseract [14] credits could be exchangedacross multiple chains Obscuro [88] built a privacy-preservingBitcoin mixer All these projects are intended for layer-2

For layer 2 TeeChan [63] was built on top of the Lightningnetwork and created new channels instantly off-chain Howeverit still requires synchronization with Blockchain and cannot cre-ate multiple channels with a single deposit Based on TeeChanTeeChain [64] was proposed to set up a committee for each nodeand dynamically allocate the deposit to channels but it is a paymentchannel system and still requires HTCL for multi-hop transactionsIn contrast Speedster is a fully decentralized multi-party statechannel system and provides better privacy protection

12

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

10 CONCLUSION

Speedster is the first account-based state channel system whereoff-chain channels can be freely openedclosed using the existingaccount balance without involving Blockchain Speedster intro-duces Certified Channel to eliminate the expensive operations fortransaction processing and dispute resolution To the best of ourknowledge Speedster is the first channel system that achievesFDCN thus eliminating the risks and overhead introduced by HTLConce for allWithCertified Channel and FDCN Speedster is capableof executing multi-party state channel efficiently The practicalityof Speedster is validated on different TEE platforms (ie Intel SGXAMD SEV and ARM TrustZone) The experimental results showmuch-improved performance compared to LN and other layer-2channel networks

REFERENCES

[1] Ian Allison 2016 Ethereumrsquos Vitalik Buterin explains how state channelsaddress privacy and scalability

[2] Ghada Almashaqbeh Allison Bishop and Justin Cappos 2019 Microcash Prac-tical concurrent processing of micropayments arXiv preprint arXiv191108520(2019)

[3] AMD [nd] AMD EPYCtrade 7452 httpswwwamdcomenproductscpuamd-epyc-7452 Accessed 2020-04-27

[4] AMD [nd] AMD ESEAMD SEV httpsgithubcomAMDESEAMDSEVAccessed 2020-04-27

[5] AMD [nd] Secure Encrypted Virtualization (SEV) httpsdeveloperamdcomsev

[6] Ittai Anati Shay Gueron Simon Johnson and Vincent Scarlata 2013 Innovativetechnology for CPU based attestation and sealing In Proceedings of the 2ndinternational workshop on hardware and architectural support for security andprivacy Vol 13

[7] Elli Androulaki Artem Barger Vita Bortnikov Christian Cachin KonstantinosChristidis Angelo De Caro David Enyeart Christopher Ferris Gennady Lavent-man Yacov Manevich et al 2018 Hyperledger fabric a distributed operatingsystem for permissioned blockchains In Proceedings of the Thirteenth EuroSysConference 1ndash15

[8] Apple 2019 Apple T2 Secure Chip httpssupportapplecomguidesecuritysecure-enclave-overview-sec59b0b31ff1web1

[9] ARM [nd] Arm Confidential Compute Architecture httpsdeveloperarmcomarchitecturesarchitecture-security-features accessed 2021-03-31

[10] ARM 2019-12-13 Arm TrustZone Technology httpsdeveloperarmcomip-productssecurity-iptrustzone

[11] Christian Badertscher Ueli Maurer Daniel Tschudi and Vassilis Zikas 2017Bitcoin as a transaction ledger A composable treatment In Annual InternationalCryptology Conference Springer 324ndash356

[12] Rana Barua Ratna Dutta and Palash Sarkar 2003 Extending Jouxrsquos protocol tomulti party key agreement In International Conference on Cryptology in IndiaSpringer 205ndash217

[13] Gal Beniamini 2017 Trust Issues Exploiting TrustZone TEEs Google ProjectZero Blog (2017)

[14] Iddo Bentov Yan Ji Fan Zhang Lorenz Breidenbach Philip Daian and Ari Juels2019 Tesseract Real-time cryptocurrency exchange using trusted hardware InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communica-tions Security ACM 1521ndash1538

[15] Daniel J Bernstein 2006 Curve25519 new Diffie-Hellman speed records InInternational Workshop on Public Key Cryptography Springer 207ndash228

[16] GP Biswas 2008 DiffiendashHellman technique extended to multiple two-partykeys and one multi-party key IET Information Security 2 1 (2008) 12ndash18

[17] bitcoinvisualscom 2021 Average Channels per Node httpsbitcoinvisualscomlightning

[18] blockchaincom 2021 Average Block Size httpswwwblockchaincomchartsavg-block-size

[19] blockchaincom 2021 Bitcoin Transaction Rate httpswwwblockchaincomenchartstransactions-per-secondtimespan=all

[20] Dan Boneh and Mark Zhandry 2017 Multiparty key exchange efficient traitortracing and more from indistinguishability obfuscation Algorithmica 79 4(2017) 1233ndash1285

[21] Marcus Brandenburger Christian Cachin Matthias Lorenz and Ruumldiger Kapitza2017 Rollback and forking detection for trusted execution environments usinglightweight collective memory In 2017 47th Annual IEEEIFIP InternationalConference on Dependable Systems and Networks (DSN) IEEE 157ndash168

[22] Emmanuel Bresson Olivier Chevassut and David Pointcheval 2007 Provablysecure authenticated group Diffie-Hellman key exchange ACM Transactions on

Information and System Security (TISSEC) 10 3 (2007) 10ndashes[23] Robert Buhren Christian Werling and Jean-Pierre Seifert 2019 Insecure Until

Proven Updated Analyzing AMD SEVrsquos Remote Attestation In Proceedings ofthe 2019 ACM SIGSAC Conference on Computer and Communications Security1087ndash1099

[24] Conrad Burchert Christian Decker and Roger Wattenhofer 2018 Scalablefunding of Bitcoin micropayment channel networks Royal Society open science5 8 (2018) 180089

[25] Vitalik Buterin et al 2014 Ethereum A next-generation smart contract and de-centralized application platform URL httpsgithub comethereumwikiwiki5BEnglish 5D-White-Paper (2014)

[26] Vitalik Buterin et al 2014 A next-generation smart contract and decentralizedapplication platform white paper (2014)

[27] Ran Canetti 2001 Universally composable security A new paradigm for cryp-tographic protocols In Proceedings 42nd IEEE Symposium on Foundations ofComputer Science IEEE 136ndash145

[28] Manuel MT Chakravarty Sandro Coretti Matthias Fitzi Peter Gazi PhilippKant Aggelos Kiayias and Alexander Russell 2020 Hydra Fast IsomorphicState Channels IACR Cryptol ePrint Arch 2020 (2020) 299

[29] Raymond Cheng Fan Zhang Jernej Kos Warren He Nicholas Hynes NoahJohnson Ari Juels Andrew Miller and Dawn Song 2019 Ekiden A platform forconfidentiality-preserving trustworthy and performant smart contracts In 2019IEEE European Symposium on Security and Privacy (EuroSampP) IEEE 185ndash200

[30] Tom Close 2019 Nitro Protocol IACR Cryptology ePrint Archive 2019 (2019)219

[31] Microsoft Corporation 2019 EVM httpsgithubcommicrosofteEVM[32] Microsoft Corporation 2019 openenclave httpsgithubcommicrosoft

openenclave[33] Victor Costan and Srinivas Devadas 2016 Intel SGX Explained IACR Cryptology

ePrint Archive 2016 086 (2016) 1ndash118[34] Chris Dannen 2017 Introducing Ethereum and solidity Vol 318 Springer[35] Poulami Das Lisa Eckey Tommaso Frassetto David Gens Kristina Hostaacutekovaacute

Patrick Jauernig Sebastian Faust and Ahmad-Reza Sadeghi 2019 FastKit-ten practical smart contracts on bitcoin In 28th USENIX Security Symposium(USENIX Security 19) 801ndash818

[36] Christian Decker and Roger Wattenhofer 2015 A fast and scalable paymentnetwork with bitcoin duplex micropayment channels In Symposium on Self-Stabilizing Systems Springer 3ndash18

[37] Mo Dong Qingkai Liang Xiaozhou Li and Junda Liu 2018 Celer NetworkBring Internet Scale to Every Blockchain arXiv preprint arXiv181000037 (2018)

[38] Stefan Dziembowski Lisa Eckey Sebastian Faust Julia Hesse and KristinaHostaacutekovaacute 2019 Multi-party virtual state channels In Annual InternationalConference on the Theory and Applications of Cryptographic Techniques Springer625ndash656

[39] Stefan Dziembowski Lisa Eckey Sebastian Faust and Daniel Malinowski 2019Perun Virtual payment hubs over cryptocurrencies In 2019 IEEE Symposiumon Security and Privacy (SP) 327ndash344

[40] Stefan Dziembowski Sebastian Faust and Kristina Hostakova 2018 Founda-tions of State Channel Networks IACR Cryptology ePrint Archive 2018 (2018)320

[41] Stefan Dziembowski Sebastian Faust and Kristina Hostaacutekovaacute 2018 Generalstate channel networks In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 949ndash966

[42] ethereum 2020-05-02 Ethereum Virtual Machine (EVM) AwesomeList httpsgithubcomethereumwikiwikiEthereum-Virtual-Machine-(EVM)-Awesome-List

[43] etherscanio 2021 Ethereum Blockchain Size httpsetherscaniochartsyncchaindefault

[44] Guillaume Felley Arthur Gervais and Roger Wattenhofer 2018 Towards UsableOff-Chain Payments (2018)

[45] William Foxley 2019 As Bitcoin Cash Hard Forks Unknown Mining PoolContinues Old Chain https shorturlat svATX (2019)

[46] Cesare Garlati 2019 Multi Zone Trusted Execution Environment Free AndOpen API In RISC-V Workshop

[47] Arthur Gervais Ghassan O Karame Karl Wuumlst Vasileios Glykantzis HubertRitzdorf and Srdjan Capkun 2016 On the security and performance of proofof work blockchains In Proceedings of the 2016 ACM SIGSAC conference oncomputer and communications security 3ndash16

[48] Johannes Goumltzfried Moritz Eckert Sebastian Schinzel and Tilo Muumlller 2017Cache attacks on Intel SGX In Proceedings of the 10th European Workshop onSystems Security ACM 2

[49] Matthew Green and Ian Miers 2017 Bolt Anonymous payment channels fordecentralized currencies In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security ACM 473ndash489

[50] Jordi Herrera-Joancomarti Guillermo Navarro-Arribas Alejandro Ranchal Pe-drosa Perez-Sola Cristina and Joaquin Garcia-Alfaro 2019 On the difficultyof hiding the balance of lightning network channels PhD Dissertation Deacutept

13

Reacuteseaux et Service de Teacuteleacutecom (Institut Mines-Teacuteleacutecom-Teacuteleacutecom SudParis [51] Matthew Hoekstra Reshma Lal Pradeep Pappachan Vinay Phegade and Juan

Del Cuvillo 2013 Using innovative instructions to create trustworthy softwaresolutions In HASP ISCA 11

[52] Intel [nd] Security Best Practices for Side Channel Resistancehttpssoftwareintelcomsecurity-software-guidanceinsightssecurity-best-practices-side-channel-resistance accessed 2020-08-18

[53] Intel 2019 Intelreg Processors Voltage Settings Modification Advisory httpswwwintelcomcontentwwwusensecurity-centeradvisoryintel-sa-00289html

[54] Intel 2019-12-3 Intelreg Xeonreg Processor E3 v5 Family httpsarkintelcomcontentwwwusenarkproducts88177intel-xeon-processor-e3-1275-v5-8m-cache-3-60-ghzhtml

[55] Markus Jakobsson and Ari Juels 1999 Proofs of work and bread puddingprotocols In Secure Information Networks Springer 258ndash272

[56] Don Johnson Alfred Menezes and Scott Vanstone 2001 The elliptic curvedigital signature algorithm (ECDSA) International journal of information security1 1 (2001) 36ndash63

[57] David Kaplan Jeremy Powell and Tom Woller 2016 AMD memory encryptionWhite paper (2016)

[58] Rami Khalil and Arthur Gervais 2017 Revive Rebalancing off-blockchain pay-ment networks In Proceedings of the 2017 ACM SIGSAC Conference on Computerand Communications Security ACM 439ndash453

[59] Rami Khalil Arthur Gervais and G Felley 2018 NOCUST-A Non-Custodial2nd-Layer Financial Intermediary IACR Cryptol ePrint Arch 2018 (2018) 642

[60] Christina Kim 2019 Ethereumrsquos Istanbul Upgrade Arrives Early Causes TestnetSplit https shorturlatbEQ29 (2019)

[61] Ahmed Kosba Andrew Miller Elaine Shi Zikai Wen and Charalampos Papa-manthou 2016 Hawk The blockchain model of cryptography and privacy-preserving smart contracts In 2016 IEEE symposium on security and privacy (SP)IEEE 839ndash858

[62] Dayeol Lee David Kohlbrenner Shweta Shinde Dawn Song and KrsteAsanović 2019 Keystone A framework for architecting tees arXiv preprintarXiv190710119 (2019)

[63] Joshua Lind Ittay Eyal Peter Pietzuch and Emin Guumln Sirer 2016 TeechanPayment channels using trusted execution environments arXiv preprintarXiv161207766 (2016)

[64] Joshua Lind Oded Naor Ittay Eyal Florian Kelbert Emin Guumln Sirer and Pe-ter Pietzuch 2019 Teechain a secure payment network with asynchronousblockchain access In Proceedings of the 27th ACM Symposium on OperatingSystems Principles 63ndash79

[65] lnd 2019 Lightning Network Daemon httpsgithubcomlightningnetworklnd

[66] loomxio [nd] Loom A new architecture for a high performance blockchainhttpsloomxio Accessed 2019-054-18

[67] Loi Luu Viswesh Narayanan Chaodong Zheng Kunal Baweja Seth Gilbert andPrateek Saxena 2016 A secure sharding protocol for open blockchains In Pro-ceedings of the 2016 ACM SIGSAC Conference on Computer and CommunicationsSecurity ACM 17ndash30

[68] Giulio Malavolta Pedro Moreno-Sanchez Aniket Kate Matteo Maffei and Sri-vatsan Ravi 2017 Concurrency and privacy with payment-channel networksIn Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communi-cations Security ACM 455ndash471

[69] Giulio Malavolta Pedro Moreno-Sanchez Clara Schneidewind Aniket Kateand Matteo Maffei 2019 Anonymous multi-hop locks for blockchain scalabilityand interoperability In Network and Distributed System Security Symposium(NDSS)

[70] Sinisa Matetic Mansoor Ahmed Kari Kostiainen Aritra Dhar David SommerArthur Gervais Ari Juels and Srdjan Capkun 2017 ROTE Rollback protectionfor trusted execution In 26th USENIX Security Symposium (USENIX Securityrsquo17)1289ndash1306

[71] mbedorg [nd] mbedtlsAn open source portable easy to use readable andflexible SSL library httpstlsmbedorg Accessed 2019-12-3

[72] Patrick McCorry Surya Bakshi Iddo Bentov Sarah Meiklejohn and AndrewMiller 2019 Pisa Arbitration outsourcing for state channels In Proceedings ofthe 1st ACM Conference on Advances in Financial Technologies ACM 16ndash30

[73] Patrick McCorry Siamak F Shahandashti and Feng Hao 2017 A smart contractfor boardroom voting with maximum voter privacy In International Conferenceon Financial Cryptography and Data Security Springer 357ndash375

[74] David McGrew and John Viega 2004 The Galoiscounter mode of operation(GCM) Submission to NIST Modes of Operation Process 20 (2004)

[75] Frank McKeen Ilya Alexandrovich Alex Berenzon Carlos V Rozas HishamShafi Vedvyas Shanbhogue and Uday R Savagaonkar 2013 Innovative instruc-tions and software model for isolated execution In HASPISCA 10

[76] Andrew Miller Iddo Bentov Surya Bakshi Ranjit Kumaresan and Patrick Mc-Corry 2019 Sprites and state channels Payment networks that go faster than

lightning In International Conference on Financial Cryptography and Data Secu-rity Springer 508ndash526

[77] Du Mingxiao Ma Xiaofeng Zhang Zhe Wang Xiangwei and Chen Qijun 2017A review on consensus algorithm of blockchain In 2017 IEEE InternationalConference on Systems Man and Cybernetics (SMC) IEEE 2567ndash2572

[78] Kit Murdock David Oswald Flavio D Garcia Jo Van Bulck Daniel Gruss andFrank Piessens 2020 Plundervolt Software-based Fault Injection Attacksagainst Intel SGX In 2020 IEEE Symposium on Security and Privacy (SP)

[79] Satoshi Nakamoto 2016 Bitcoin A peer-to-peer electronic cash system httpbitcoinorgbitcoinpdf

[80] Zhenyu Ning and Fengwei Zhang 2019 Understanding the security of armdebugging features In 2019 IEEE Symposium on Security and Privacy (SP) IEEE602ndash619

[81] Rafael Pass Elaine Shi and Florian Tramer 2017 Formal abstractions forattested execution secure processors In Annual International Conference on theTheory and Applications of Cryptographic Techniques Springer 260ndash289

[82] Raiden 2017 The Raiden Network httpsraidennetwork[83] Elias Rohrer Julian Malliaris and Florian Tschorsch 2019 Discharged Payment

Channels Quantifying the Lightning Networkrsquos Resilience to Topology-BasedAttacks arXiv preprint arXiv190410253 (2019)

[84] Fahad Saleh 2020 Blockchain without waste Proof-of-stake Available at SSRN3183935 (2020)

[85] Michael Schwarz Samuel Weiser Daniel Gruss Cleacutementine Maurice and StefanMangard 2017 Malware guard extension Using SGX to conceal cache attacks InInternational Conference on Detection of Intrusions andMalware and VulnerabilityAssessment Springer 3ndash24

[86] Tim Swanson 2015 Consensus-as-a-service a brief report on the emergence ofpermissioned distributed ledger systems Report available online (2015)

[87] Saar Tochner Stefan Schmid and Aviv Zohar 2019 Hijacking Routes in PaymentChannel Networks A Predictability Tradeoff arXiv preprint arXiv190906890(2019)

[88] Muoi Tran Loi Luu Min Suk Kang Iddo Bentov and Prateek Saxena 2018Obscuro A bitcoin mixer using trusted execution environments In Proceedingsof the 34th Annual Computer Security Applications Conference 692ndash701

[89] Somanath Tripathy and Susil Kumar Mohanty 2020 Mappcn Multi-hop anony-mous and privacy-preserving payment channel network In International Con-ference on Financial Cryptography and Data Security Springer 481ndash495

[90] Itay Tsabary Matan Yechieli and Ittay Eyal 2020 MAD-HTLC because HTLCis crazy-cheap to attack arXiv preprint arXiv200612031 (2020)

[91] Andrew Urquhart 2016 The inefficiency of Bitcoin Economics Letters 148(2016) 80ndash82

[92] Jo Van Bulck Marina Minkin Ofir Weisse Daniel Genkin Baris Kasikci FrankPiessens Mark Silberstein Thomas F Wenisch Yuval Yarom and Raoul Strackx2018 Foreshadow Extracting the Keys to the Intel SGX Kingdom with Tran-sient Out-of-Order Execution In 27th USENIX Security Symposium (USENIXSecurityrsquo18) 991ndash1008

[93] Fabian Vogelsteller and Vitalik Buterin 2015 Erc-20 token standard EthereumFoundation (Stiftung Ethereum) Zug Switzerland (2015)

[94] Nico Weichbrodt Anil Kurmus Peter Pietzuch and Ruumldiger Kapitza 2016AsyncShock Exploiting synchronisation bugs in Intel SGX enclaves In EuropeanSymposium on Research in Computer Security Springer 440ndash457

[95] Karl Wuumlst and Arthur Gervais 2018 Do you need a blockchain In 2018 CryptoValley Conference on Blockchain Technology (CVCBT) IEEE 45ndash54

[96] wwwblockchaincom 2020 Blockchain Size httpswwwblockchaincomchartsblocks-size

[97] wwwblockchaincom 2021 Average Confirmation Time httpswwwblockchaincomchartsavg-confirmation-timetimespan=allampdaysAverageString=7

[98] Bin Yu Shabnam Kasra Kermanshahi Amin Sakzad and Surya Nepal 2019Chameleon hash time-lock contract for privacy preserving payment channelnetworks In International Conference on Provable Security Springer 303ndash318

[99] Mahdi Zamani Mahnush Movahedi and Mariana Raykova 2018 RapidchainScaling blockchain via full sharding In Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security 931ndash948

[100] Fan Zhang 2017 mbedtls-SGX a SGX-friendly TLS stack (ported from mbedtls)httpsgithubcombl4ck5unmbedtls-SGX

[101] Fan Zhang Ethan Cecchetti Kyle Croman Ari Juels and Elaine Shi 2016 Towncrier An authenticated data feed for smart contracts In Proceedings of the2016 aCM sIGSAC conference on computer and communications security ACM270ndash282

[102] Fan Zhang Ittay Eyal Robert Escriva Ari Juels and Robbert Van Renesse 2017REM Resource-Efficient Mining for Blockchains IACR Cryptology ePrint Archive2017 (2017) 179

[103] Yuanyu Zhang Shoji Kasahara Yulong Shen Xiaohong Jiang and JianxiongWan 2018 Smart contract-based access control for the internet of things IEEEInternet of Things Journal 6 2 (2018) 1594ndash1605

14

FSpeedster [ℓP0P1P2 P119873 ]Initially

bals = empty certs = empty channels= empty states0 = emptyFor each P119894 (pk119894 sk119894 ) larr$KGen(1119899)

(1) On receive (ldquodeposit tx) from P119894 where 119894 isin [119873 ]parse tx as (pkrsquo $val _ 120590)Verify signature of tx abort if falsebals[P119894 ] += $valappend (tx $val) to states0 [P119894 ]leak (ldquodeposit tx) to A

(2) On receive (ldquoopen cid P119895 ) from P119894 where 119894 119895 isin [119873 ] andP119894 ne P119895

ccidlarr$ 0 1lowaststateccid = Contractcid (pk119894

minusrarr0 perp)append (ccid ( cid stateccid R P119894 )) to channels

leak (ldquoopen ccid cid P119894 P119895 ) to A

(3) On receive (ldquoauthenticate ccid P119895 cert) from P119894 where119894 119895 isin [119873 ] and 119894 ne 119895

assert certs[ccid][P119894 ] = perpcerts[ccid][P119894 ] = certleak (P119894 P119895 ldquoauthenticate cert) to Aawait ldquoOK from Asend(ldquoauthenticate cert) to P119895

(4) On receive (ldquoopenMulti cid ccidlowast) from P119894 where119894 isin [119873 ] and R ne P119894

ccidlarr$ 0 1lowaststate = Contractcid (P119894

minusrarr0 perp)collect dummy parties Plowast in channels ccidlowastappend (ccid (cid state Plowast)) to certs

leak (ldquoopenMulti ccid cid ccidlowast) to A

(5) On receive (ldquosend ccid inp) from P119894 where 119894 isin [119873 ](cid state Plowast) = certs[ccid] abort if perp(statersquo outp) = Contract119888119894119889 (P119894 state 119894119899119901)aux = (P119894 ∥119903 ∥inp∥stateprime∥outp)leak (ldquosend ccid ℓ (aux)) to A await ldquoOK from Asend(aux) to each member of Plowast except P119894

(6) On receive (ldquoclaim) from P119894 where i isin [N]construct an on-chain claim transaction tx

leak(ldquoclaim tx) to A await ldquoOK from Asend(tx) to Blockchain

Figure 8 Ideal functionality of FSpeedster Internal commu-

nications are assumed to be encrypted with authenticated

encryption

A CONSTRUCTION OF SS simulates A FSpeedster internally S forwards any input 119890 fromE to A and records the traffic going to and from A(1) Deposit If P119894 is honest S obtains (ldquodeposit tx) from FSpeedsterand emulates a call of ldquodeposit to G119886119905119905 through ldquoresume interface

Otherwise S reads tx from E and emulates message (ldquodeposit tx)to FSpeedster with the identity of P119894 then sends the ldquodeposit callto G119886119905119905 (2) Open Channel When P119894 is honest S emulates a call of ldquoopento G119886119905119905 on receiving (ldquoopenccid cid P119894 P119895 ) from FSpeedster

When P119894 is corruptedbull S obtains a public key pk and a smart contract id cid from Ethen generate a random string as inp S sends the message(ldquoopen cid R inp) to FSpeedster and collect the output withthe identity of P119894 Then S emulates a ldquoresume call to G119886119905119905with the same messages (ldquoopen cidR inp) on behalf of P119894and collect the output from G119886119905119905 bull Upon receiving (ldquoopen ccid cid P119894 P119895 ) from FSpeedster Sobtains inp from E and emulates a ldquoresume call to G119886119905119905sending message (ldquoopen cid P119895 inp) on behalf of P119894 andrecord the output from G119886119905119905

(3) Channel Authentication Upon receiving message (P119894 P119895 ldquoau-thenticate cert) from FSpeedster of an honest P119894 S records cert Semulates a ldquoresume call to G119886119905119905 sending message (ldquoauthenticateccid P119895 cert) Then S sends an ldquoOK command to FSpeedster

If P119894 is corrupted S obtains a public key pk a channel idccidfrom E a sk from a signature challenger SCh then generates arandom string as119898 S computes 120590 = ΣSig(sk pk∥119898) then sendsthe message (ldquoauthenticate pk ccid (pk119894 ∥pk∥119898∥120590)) to FSpeedsterand collect the output with the identity of P119894 Then S emulatesa ldquoresume call to G119886119905119905 with the same messages on behalf of P119894and collect the output from G119886119905119905 (4) Multi-party Channel Uponreceiving message (ldquoopenMulti ccid cid ccidlowast) from FSpeedster ofan honest P119894 S emulates a ldquoresume call to G119886119905119905 sending message(ldquoopenMulti cid ccidlowast) Then relay the output to P119894

While dealing with a corrupted party P119894 bull S queries a set of channel id ccidlowast and a smart contract idfrom E Then S sends the message (ldquoopenMulti cid ccidlowast)to FSpeedster and collects the output with P119894 rsquos identity ThenS emulates a ldquoresume call to G119886119905119905 with the same messageson behalf of P119894 and collects the output from G119886119905119905 bull Upon receiving message (ldquoopenMulti ccid cid ccidlowast) fromFSpeedster S emulates a ldquoresume call to G119886119905119905 sending mes-sage (ldquoopenMulti cid ccidlowast) Then relay the output to P119894

(5)Channel TransactionUpon receivingmessage (ldquosend ccid ℓ (aux))from FSpeedster of P119894 S requests a key from a challenger Ch whogenerates AE keys S generates a random string 119903 and computes119898 = AE Enc(key 119903 ) of which |119898 | = |ℓ (aux) | S emulates a ldquore-sume call to G119886119905119905 sending message (ldquoreceive ccid119898) on behalf ofP119894 Then relay the output to P119894

While dealing with a corrupted party P119894 bull S queries a channel id ccid and a random string inp = 0 1lowastfrom E Then S sends the message (ldquosend cid ccidlowast) toFSpeedster on P119894 rsquos behalf and collects the output Then Semulates a ldquoresume call to G119886119905119905 with the same messages onbehalf of P119894 and collects the output from G119886119905119905 bull Upon receiving message (ldquosend ccid ℓ (aux)) from FSpeedsterS requests a key from Ch S computes119898 = AE Enc(keyminusrarr0 )of which |119898 | = |ℓ (aux) | S emulates a ldquoresume call to G119886119905119905

15

F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] initializationOn initialize 119878119905119900119903119886119892119890 = empty

public query interfaceOn receive read(119894119889) from Poutput 119878119905119900119903119886119892119890 [119894119889] or perp if not found

public append interfaceOn receive append(tx) from Pabort if 119878119905119900119903119886119892119890 [tx119894119889] neperpif 119862119900119899119905119903119886119888119905 (tx) = 119905119903119906119890

119878119905119900119903119886119892119890 [tx119894119889] = tx

output (success)else

output (failure)

Figure 10 Ideal functionality of Blockchain modeling an

append-only ledger

sending message (ldquoreceive ccid 119898) on behalf of P119894 Thenrelay the output to P119894

(6)ClaimUpon receivingmessage (ldquoclaim tx) ofP119894 fromFSpeedsterS emulates a ldquoresume call to G119886119905119905 sending message (ldquoclaim tx)on behalf of P119894 Then and send ldquoOK to FSpeedster and relay theoutput to the Blockchain

While P119894 is corrupted S sends message (ldquoclaim) to FSpeedsteron behalf of P119894 and collects the output Then S emulates a ldquoresumecall to G119886119905119905 with the same message on behalf of P119894 and collects theoutput from G119886119905119905 then relay the output to the Blockchain

G119886119905119905 [Σ 119903119890119892] initializationOn initialize (mpkmsk) = ΣKGen(1119899)119879 = empty

public query interfaceOn receive getpk() from some P send mpk to P

Enclave operations

local interface mdash install an enclaveOn receive install(119894119889119909 prog) from some P isin 119903119890119892if P is honest assert 119894119889119909 = 119904119894119889

generate nonce 119890119894119889 isin 0 1_ store 119879 [119890119894119889P] = (119894119889119909 prog 0) send 119890119894119889 to P

local interface mdash resume an enclaveOn receive resume(119890119894119889 119894119899119901 119904119908119894119905119888ℎ = 119900119899) from someP isin 119903119890119892let (119894119889119909 prog119898119890119898) = 119879 [119890119894119889P] abort if not foundlet (119900119906119905119901119898119890119898) = prog(119894119899119901119898119890119898)update 119879 [119890119894119889P] = (119894119889119909 prog119898119890119898)if 119904119908119894119905119888ℎ is set to 119900119899

let 120590 = ΣSigmsk (119894119889119909 119890119894119889 prog 119900119906119905119901)send (119900119906119905119901 120590) to P

otherwisesend (119900119906119905119901perp) to P

Figure 9 A global functionality modeling an SGX-like se-

cure processor Compared to [81] a switch is added to the

ldquoresume command to allow users to disable the signature

The default value of 119904119908119894119905119888ℎ is set to ldquoon

16

• Abstract
• 1 Introduction
• 2 Background
• • 21 Blockchain and Smart Contract
  • 22 Layer-2 Channels
  • 23 Trusted Execution Environment
  • • 3 Threat Model and Design Goals
    • • 31 Threat Model
      • 32 Design Goals
      • • 4 Speedster Design
        • • 41 System Architecture
          • 42 Workflow
          • 43 Key Functions
          • • 5 Lg Protocol
            • • 51 Ideal Functionality
              • 52 Speedster Protocol Lg
              • • 6 Security and Privacy Analysis
                • 7 Implementation and Evaluation
                • • 71 Implementation of Speedster
                  • 72 Evaluation
                  • • 8 Discussion
                    • 9 Related Work
                    • 10 Conclusion
                    • References
                    • A Construction of S

F119887119897119900119888119896119888ℎ119886119894119899 [119862119900119899119905119903119886119888119905] initializationOn initialize 119878119905119900119903119886119892119890 = empty

public query interfaceOn receive read(119894119889) from Poutput 119878119905119900119903119886119892119890 [119894119889] or perp if not found

public append interfaceOn receive append(tx) from Pabort if 119878119905119900119903119886119892119890 [tx119894119889] neperpif 119862119900119899119905119903119886119888119905 (tx) = 119905119903119906119890

119878119905119900119903119886119892119890 [tx119894119889] = tx

output (success)else

output (failure)

Figure 10 Ideal functionality of Blockchain modeling an

append-only ledger

sending message (ldquoreceive ccid 119898) on behalf of P119894 Thenrelay the output to P119894

(6)ClaimUpon receivingmessage (ldquoclaim tx) ofP119894 fromFSpeedsterS emulates a ldquoresume call to G119886119905119905 sending message (ldquoclaim tx)on behalf of P119894 Then and send ldquoOK to FSpeedster and relay theoutput to the Blockchain

While P119894 is corrupted S sends message (ldquoclaim) to FSpeedsteron behalf of P119894 and collects the output Then S emulates a ldquoresumecall to G119886119905119905 with the same message on behalf of P119894 and collects theoutput from G119886119905119905 then relay the output to the Blockchain

G119886119905119905 [Σ 119903119890119892] initializationOn initialize (mpkmsk) = ΣKGen(1119899)119879 = empty

public query interfaceOn receive getpk() from some P send mpk to P

Enclave operations

local interface mdash install an enclaveOn receive install(119894119889119909 prog) from some P isin 119903119890119892if P is honest assert 119894119889119909 = 119904119894119889

generate nonce 119890119894119889 isin 0 1_ store 119879 [119890119894119889P] = (119894119889119909 prog 0) send 119890119894119889 to P

local interface mdash resume an enclaveOn receive resume(119890119894119889 119894119899119901 119904119908119894119905119888ℎ = 119900119899) from someP isin 119903119890119892let (119894119889119909 prog119898119890119898) = 119879 [119890119894119889P] abort if not foundlet (119900119906119905119901119898119890119898) = prog(119894119899119901119898119890119898)update 119879 [119890119894119889P] = (119894119889119909 prog119898119890119898)if 119904119908119894119905119888ℎ is set to 119900119899

let 120590 = ΣSigmsk (119894119889119909 119890119894119889 prog 119900119906119905119901)send (119900119906119905119901 120590) to P

otherwisesend (119900119906119905119901perp) to P

Figure 9 A global functionality modeling an SGX-like se-

cure processor Compared to [81] a switch is added to the

ldquoresume command to allow users to disable the signature

The default value of 119904119908119894119905119888ℎ is set to ldquoon

16

• Abstract
• 1 Introduction
• 2 Background
• • 21 Blockchain and Smart Contract
  • 22 Layer-2 Channels
  • 23 Trusted Execution Environment
  • • 3 Threat Model and Design Goals
    • • 31 Threat Model
      • 32 Design Goals
      • • 4 Speedster Design
        • • 41 System Architecture
          • 42 Workflow
          • 43 Key Functions
          • • 5 Lg Protocol
            • • 51 Ideal Functionality
              • 52 Speedster Protocol Lg
              • • 6 Security and Privacy Analysis
                • 7 Implementation and Evaluation
                • • 71 Implementation of Speedster
                  • 72 Evaluation
                  • • 8 Discussion
                    • 9 Related Work
                    • 10 Conclusion
                    • References
                    • A Construction of S