Applied Science, Faculty of
Engineering, School of (Okanagan)
DSpace
UBCO
Daneshpajooh, Mahyar
Master of Applied Science - MASc
University of British Columbia
The concept of blockchain was introduced by Nakamoto in the Bitcoin whitepaper. Bitcoin enabled users to make payments in a fully-decentralized manner. In the past decade, researchers and engineers leveraged the Bitcoin idea and proposed blockchains with different characteristics (such as level of security, privacy, and decentralization), each focusing on a particular area. One way to classify blockchains is based on their programmability. A programmable blockchain enables developers to run their programs on top of it. This way, the execution of programs becomes decentralized so no one can manipulate the result. Currently, many dApps are built on top of programmable blockchains such as exchanges, lending protocols, etc. Bitcoin, although its promising security, doesn't have the programming capability to build dApp on it. In this work, I introduce and implement HotGate, a trustless cross-chain settlement protocol that enables users to move BTC from Bitcoin to other programmable blockchains. So users can leverage their BTC in dApps of other blockchains. Moreover, HotGate enables users to exchange their BTC for assets that exist on these blockchains. HotGate uses Relay, a fully-decentralized interoperability solution that connects blockchains directly together. This makes Hotgate a trustless protocol that is aligned with blockchain values. Moreover, HotGate introduces two mechanisms that enable users to move BTC in a fast and private manner, which are the weaknesses of the Bitcoin blockchain.
HotGate: Trustless Cross-chain Settlement ProtocolbyMahyar DaneshpajoohB.Sc., Sharif University of Technology, 2020A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMASTER OF APPLIED SCIENCEinTHE COLLEGE OF GRADUATE STUDIES(Electrical Engineering)The University of British Columbia(Okanagan)December 2022© Mahyar Daneshpajooh, 2022The following individuals certify that they have read, and recommend to the Fac-ulty of Graduate and Postdoctoral Studies for acceptance, the thesis entitled:HotGate: Trustless Cross-chain Settlement Protocolsubmitted by Mahyar Daneshpajooh in partial fulfillment of the requirements forthe degree of MASTER OF APPLIED SCIENCEExamining Committee:Chen Feng, School of EngineeringSupervisorAnas Chaaban, School of EngineeringSupervisory Committee MemberAhmad Al-Dabbagh, School of EngineeringSupervisory Committee MemberiiAbstractThe concept of blockchain was introduced by Nakamoto in the Bitcoin whitepaper[29]. Bitcoin enabled users to make payments in a fully-decentralized manner. Inthe past decade, researchers and engineers leveraged the Bitcoin idea and proposedblockchains with different characteristics (such as level of security, privacy, and de-centralization), each focusing on a particular area. One way to classify blockchainsis based on their programmability. A programmable blockchain [17] enables de-velopers to run their programs on top of it. This way, the execution of programs be-comes decentralized so no one can manipulate the result. Currently, many Decen-tralized Application (DAPP) are built on top of programmable blockchains such asexchanges, lending protocols, etc. Bitcoin, although its promising security, doesn’thave the programming capability to build dApp on it.In this work, I introduce and implement HotGate, a trustless cross-chain set-tlement protocol that enables users to move Bitcoin (BTC) from Bitcoin to otherprogrammable blockchains. So users can leverage their BTC in dApps of otherblockchains. Moreover, HotGate enables users to exchange their BTC for assetsthat exist on these blockchains. HotGate uses Relay [18], a fully-decentralizedinteroperability solution that connects blockchains directly together. This makesHotgate a trustless protocol that is aligned with blockchain values. Moreover, Hot-Gate introduces two mechanisms that enable users to move BTC in a fast and pri-vate manner, which are the weaknesses of the Bitcoin blockchain.iiiLay SummaryBitcoin is a blockchain that enables users to make payments in a fully-decentralizedmanner. However, Bitcoin is non-programmable which prevents developers tobuild any applications on top of it. HotGate is a cross-chain settlement protocolthat enables users to move BTC from Bitcoin to other programmable blockchains,so they can leverage decentralized applications built on them. HotGate does thisin a fully-decentralized manner where no third party is included. Moreover, sinceBitcoin is a slow blockchain that doesn’t preserve the privacy of users, HotGateintroduces two mechanisms that enable users to move BTC in a fast and privatemanner.ivPrefaceAll the work presented in this thesis was conducted under the supervision of Prof.Chen Feng. The dissertation is based on research done on blockchain interoper-ability and decentralized exchange protocols. Chapter 2 is a joint work of NiushaMoshrefi and myself. The rest of the thesis is mostly done and written by me. ChenFeng was involved in revising the system design, incentive design, and choosingthe material.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Decentralized Exchange . . . . . . . . . . . . . . . . . . . . . . 41.3 Blockhain Interoperability . . . . . . . . . . . . . . . . . . . . . 61.3.1 Related Works . . . . . . . . . . . . . . . . . . . . . . . 81.4 Cross-chain Settlement . . . . . . . . . . . . . . . . . . . . . . . 81.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 Trustless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11vi2.2 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 133 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Network Participants . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 Relayer . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 Fisherman . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.4 Liquidity pool providers . . . . . . . . . . . . . . . . . . 233.2.5 Fast pool providers . . . . . . . . . . . . . . . . . . . . . 243.3 Asset Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Main Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1 Cross-chain Transfer . . . . . . . . . . . . . . . . . . . . . . . . 264.1.1 Normal Cross-chain Transfer . . . . . . . . . . . . . . . . 274.1.2 Private Cross-chain Transfer . . . . . . . . . . . . . . . . 284.1.3 Fast Cross-chain Transfer . . . . . . . . . . . . . . . . . 304.2 Cross-chain Exchange . . . . . . . . . . . . . . . . . . . . . . . 324.2.1 Normal Cross-chain Exchange . . . . . . . . . . . . . . . 324.2.2 Fast Cross-chain Exchange . . . . . . . . . . . . . . . . . 345 Incentive Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1 Relayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Fisherman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Liquidity providers . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41vii8 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.1.1 Wrapped Asset . . . . . . . . . . . . . . . . . . . . . . . 438.1.2 Wrapped Token . . . . . . . . . . . . . . . . . . . . . . . 438.1.3 Burning . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.1.4 Gas Fee . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.1.5 Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . 448.1.6 Proof of Work . . . . . . . . . . . . . . . . . . . . . . . 44Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46viiiList of TablesTable 1.1 Interoperability solutions comparison . . . . . . . . . . . . . . 7Table 2.1 Cross-chain settlement solutions comparison . . . . . . . . . . 15ixList of FiguresFigure 1.1 Blockchain structure [2] . . . . . . . . . . . . . . . . . . . . 2Figure 1.2 Constant product Automated Market Maker (AMM) [1] . . . . 5Figure 3.1 How Relay works . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 4.1 Normal cross-chain transfer scenario . . . . . . . . . . . . . . 28Figure 4.2 How Coinjoin works [5] . . . . . . . . . . . . . . . . . . . . 29Figure 4.3 Fast cross-chain transfer scenario . . . . . . . . . . . . . . . 31xGlossaryDAPP Decentralized ApplicationAMM Automated Market MakerCEX Centralized ExchangeDEX Decentralized ExchangeBTC BitcoinEVM Ethereum Virtual MachineNFT Non-Fungible TokenHTLC Hash Time-Locked ContractxiAcknowledgmentsIt was an incredible experience to do research under the supervision of Chen Feng.I want to thank him for supporting and mentoring me during my studies. I wouldalso like to thank Niusha Moshrefi, who was by my side all along this path.xiiChapter 1Introduction1.1 BlockchainBlockchain is a distributed system that maintains a ledger and allows individualswho do not trust each other to agree on the updates to that ledger. The sharedledger data structure is a chain of blocks where each block points to its previousblock (see figure 1.1). Each block contains two main parts: block header andtransactions. To attach a new block to the blockchain, nodes called miners collecttransactions, verify them, create the block and propagate it in the network. Minersoften use a peer-to-peer protocol to distribute transactions and blocks. Blockchainsare categorized as decentralized systems since there is no centralized authority thatminers rely on it. Miners update the state of the ledger by running a consensusalgorithm.Researchers proposed several consensus algorithms [25]. A class of consensusalgorithms is fault-tolerant algorithms. These algorithms work correctly even if aportion of nodes are faulty. There are two types of node failures: crash failures andbyzantine failures. In the former, a node may stop working if its system crashes.In the latter, a node may behave maliciously in the network (e.g. send conflictingmessages to different nodes) [26]. Under the byzantine failure assumption, nodescannot trust each other.Before introducing blockchain, byzantine tolerant algorithms were proposedthat solve the consensus problem in a permissioned network [20]. A permissioned1Figure 1.1: Blockchain structure [2]network is a network where nodes know each other. If a new node wants to jointhe network, it should get the needed permissions and notice other nodes. Themain innovation of blockchain is enabling miners to reach consensus in a permis-sionless byzantine network where miners can join and leave the network withoutpermission.What made it possible to reach a consensus in such a network was designing aproper economic incentive mechanism. The incentive mechanism motivates minersto follow the protocol rules to maximize their profit. The resulting decentralizedsystem has several advantages over traditional centralized systems [40]:• Immutability: Blockchain’s ledger is updated when nodes reach consensus,so a single node doesn’t have the power to rewind the ledger. This is nottrue for a centralized system where the system admin can modify the ledgerwithout others’ permission.• Anti-censorship: No one can prevent a user from interacting with the blockchain.If a miner ignores a user’s transactions, the user can send transactions toother miners to include them in the blockchain. In a centralized system, thesystem admin can censor a user’s activity permanently.• Resilient System: Blockchain is maintained by a distributed set of nodesthat are independent of each other. This makes blockchain resilient againstnetwork attacks since there is no single point of failure. On the other hand, a2centralized system is controlled by a single entity which makes it vulnerableto such attacks.• Anonymity: Users interact with the blockchain without revealing their realidentity, so users’ privacy is preserved. Anonymity also helps the system tobe anti-censorship, i.e, if miners ignore transactions of a specific user, theuser can send transactions using a new identity.The blockchain concept was first introduced in the Bitcoin whitepaper [29]by Satoshi Nakamoto. Satoshi leverages the blockchain to create a decentralizedpayment network. His main goal was to introduce an alternative to traditionalbanking systems. In Bitcoin, users can send payment transactions without the needfor a centralized entity to facilitate the process.Bitcoin has a stack-based programming language called Bitcoin script. A usersends money to a receiver by creating a locking script. To spend that money, thereceiver should provide a valid unlocking script. Bitcoin script is not a Turingcomplete language so a limited range of applications can be written on it. In theliterature, Bitcoin is categorized as under non-programmable blockchain.Bitcoin has gained massive popularity over the past decade, and many othercryptocurrencies have been created since then. One notable example is Ethereum[17], a programmable blockchain that introduced the concept of smart contracts.Ethereum extends the idea of bitcoin to a network where computer programs are ex-ecuted in a decentralized way, i.e, Ethereum offers a decentralized computing net-work. Solidity is the Ethereum turning-complete programming language that en-ables users to write any application on top of it. Such applications run on EthereumVirtual Machine (EVM). Today many other blockchains (Avalanche [32], Fantom[30], etc.) leverage EVM to attract Ethereum’s developers to build on them.Applications deployed on top of a decentralized system are called dApp. Theadvantage of dApps is that users don’t trust the execution environment to runthe application correctly. Each blockchain miner runs the application separatelyto generate the result. Then miners reach a consensus on the new state of theblockchain based on the execution result.Many application has been built on top of programmable blockchains suchas exchanges, lending and borrowing platform, stablecoins, Non-Fungible Token3(NFT), etc. One of the applications that have gained a lot of attention is Decentral-ized Exchange (DEX) [42]. Currently, notable portions (around %15) of Ethereumtransactions are to interact with DEX dApps [11].1.2 Decentralized ExchangeDEX is an exchange protocol built on top of a programmable blockchain to lever-age its decentralized nature. In traditional Centralized Exchange (CEX), the CEXcompany has full control over the users’ assets. Users deposit their assets to theirCEX account and then trade them on the CEX servers. However, using DEX, usersexchange their assets directly on the blockchain without giving the assets’ custodyto third parties. DEXs have several advantages over CEXs:• Anti-censorship: A CEX can ban users’ trading activities or prevent themfrom depositing/withdrawing their assets. There are lots of examples wherea CEX froze users’ assets without even noticing them. However, users areconfident that no one can censor their trading activities in DEX since it isrunning on a blockchain. Users can trade at any time without permission.• Transparency: How an exchange matches the users’ orders affects the users’revenue. In a CEX, the CEX owner has the power to change the matchingalgorithm without informing users. Moreover, the CEX owner has the au-thority for adding/removing trading pairs. In most cases, these processes arenot transparent to the users. DEX’s policy for matching orders and adding/re-moving pairs is hard-coded in the code which is available on the blockchain.• Higher Security: In CEX, users send their assets to the CEX’s custodialaddress. If attackers gain access to the CEX’s account, they access all users’assets that are in the custody of the CEX. There are several cases where aCEX was hacked and users lost their assets. In DEX, users have completecontrol over their assets since they don’t transfer their assets to a third party.The above advantages of DEX make it fairer than CEX, i.e, no one has anadvantage over others.4Figure 1.2: Constant product Automated Market Maker (AMM) [1]The biggest challenge of DEX is its cost. Due to the scalability issues ofthe existing blockchains, the cost of submitting data and executing programs onthem is high. In an order-book exchange, users submit buy-orders and sell-orders,then, the exchange matches these orders. A naive order-book implementation on ablockchain is a costly solution that demotivates users to use the DEX.Automated Market Maker (AMM) [13] is a solution that tackles the cost prob-lem. This solution has a lower cost in comparison to an order-book DEX. In theAMM DEX, users called market makers deposit their assets in liquidity pools.Then, users exchange their assets through liquidity pools. For example, when auser wants to exchange asset A for asset B, the DEX finds the exchange rate usingthe liquidity pool of assets A/B and sends asset B to the user. Here the DEX doesn’tmatch buying/selling orders for discovering the exchange rate.AMM DEXs use different strategies to discover the exchange rate. One of thepopular approaches is the constant product strategy. In this strategy, DEX keepsthe product of assets’ quantities constant in a liquidity pool. Figure 1.2 shows howa constant product AMM works. When a user buys an asset, the quantity of thatasset in the liquidity pool decreases. So the price of the bought asset in terms ofthe sold asset increases.51.3 Blockhain InteroperabilityBitcoin led to the blockchain revolution with a large number of promising blockchainprojects developed in the past decade. These projects have different characteristics(such as underlying consensus algorithms, levels of security, and privacy), each fo-cusing on a particular area. For example, Bitcoin is a non-programmable chain thatfocuses on payment. Monero [15] and Zcash [37] are payment networks that offerhigher levels of privacy. Flow [23] is a blockchain focused on NFT and gaming butit is not decentralized as Bitcoin.The current state of the blockchain industry is siloed blockchains, preventingthe blockchain revolution from reaching its full potential. Therefore, the future suc-cess of blockchain heavily lies in interoperability that enables different blockchainsto cooperate. Having blockchain interoperability [18], users can move assets anddata between blockchains. This also creates the opportunity to build cross-chaindApps, applications that are built on top of multiple chains.Motivated by this, various solutions have been proposed for blockchain inter-operability [16] in the past few years, but each has its own limitation. Below, wereview the main solutions of blockchain interoperability and discuss their strengthsand weaknesses.• Custodians: Custodians are a set of nodes in charge of verifying data trans-mission between chains. For example, assume that a user wants to moveher assets from blockchain A to blockchain B. First, she sends a request onblockchain A. Then she asks the custodian to confirm her action and givesher assets on blockchain B. Custodians may also provide data of blockchainA on blockchain B so users and apps of blockchain B have access to it. Theweakness of the custodian solution is centralization: custodians control thedata flow between chain A and chain B. They can censor a user by not veri-fying her cross-chain data.• HTLC: Hash Time-Locked Contract (HTLC) helps users to exchange theirassets between blockchains. This solution cannot be used for moving assetsor data between chains. In this solution, a user creates and shares a puzzlewith an exchange counterparty. Then both of the users create transactions6using that puzzle. When the puzzle creator reveals the puzzle’s solution toclaim the exchanged asset, her counterparty finds the solution and uses it toclaim the exchanged asset. Although the limited use case, since the exchangeis one of the most important blockchain dApps, this solution is categorizedas one of the main interoperability solutions.• Relay: Relay [4] is a smart-contract-based solution for the interoperabil-ity problem. In this solution, Parties called Relayers submit data from thesource chain to the target chain, then, the smart contract on the target chainchecks the correctness of the submitted data. Here, the smart contract ver-ifies all cross-chain data, so no one can submit invalid data. This makesRelay as secure as the underlying chain. Also, anyone can become a Relayerand transfer data between chains which makes it fully decentralized. Theweakness of this solution is its cost since verifying data on the blockchain iscostly.In general, interoperability solutions have three important aspects:• Decentralization: An interoperability solution can involve trusted parties,or it can completely rely on the underlying blockchains.• Cost: The cost of transferring assets and data is an important factor thatmotivates users to use a protocol.• Universality: Some solutions move the whole data of one chain to another,and some solutions are limited to a specific application.Solution Decentralization Cost UniversalityCustodian Centralized Medium NoHTLC Decentralized Medium Only swapRelay Decentralized High UniversalTable 1.1: Interoperability solutions comparison71.3.1 Related WorksRelay [44] is a universal interoperability solution with the highest level of decen-tralization, however, the cost of applying it is more than other approaches. Whatmakes Relay a high-cost solution is an on-chain verification. Often, on-chain com-putation has more cost than off-chain computation since all miners run the samecode to generate the final result. However, in off-chain computation, only a limitedset of nodes (mostly one node) run the code.There are a few attempts to reduce the Relay cost. The main idea is to verifypart of the data by off-chain entities instead of verifying all the data by smart con-tracts. The main challenge of these solutions is keeping the protocol trustless sincethey rely on the off-chain entities’ verification, i.e, off-chain entities should not beable to submit the wrong data to the protocol.The first attempt to solve the Relay cost problem was Testimonium [21]. Inthis solution, instead of verifying every submitted block header on the Relay smartcontract (which is an expensive task), Testimonium optimistically accepts blockheaders until some complaints arise. In the case of a complaint, the Relay contractverifies the block header validity. If a block header passes a period called the chal-lenge period without getting challenged, the Relay contract accepts it. AlthoughTestimonium reduced the cost, it decreased the Relay speed since a block headershould pass the challenge period to consider valid. Another approach to reducingthe Relay cost is using zero-knowledge poof [37]. In zkRelay [39], the Relay con-tract verifies a zero-knowledge proof of the data validity rather than verifying thewhole data on-chain. So by using zero-knowledge proofs, most of the computationis done by the off-chain entities and only a tiny part of it is done on-chain. zkRelayprotocol can be applied for PoW blockchains. A recent solution called zkBridge[41] extends the idea to other consensus mechanisms such as Proof of Stake.1.4 Cross-chain SettlementCurrently, multiple blockchains exist in the network but they do not interact witheach other properly. By connecting these siloed chains, the range of applicationsthat users can access expands. This connection is necessary for Bitcoin, the leadingcryptocurrency in the market that isn’t programmable. Currently, Bitcoin users8cannot exchange their BTC in a trustless manner. They need to move BTC tocentralized exchanges to do so. Also, they cannot earn interest on top of their BTCsin a decentralized way. Again, their only option is to use centralized entities to doso. Building a fully decentralized cross-chain settlement protocol between Bitcoinand other programmable blockchains unlocks a huge value for Bitcoin users.Cross-chain settlement protocol [43] aims to solve the above problem. Usingsuch a protocol, users can move or exchange assets between chains [36]. Whenan asset is moved from one chain (called source chain) to another (called targetchain), the user receives an asset with an equal value called a wrapped asset. Thewrapped asset is the representation of the native asset on the target chain.Several examples show the importance of such an application. Suppose thatAlice has token A on the source chain. Now, consider the following scenarios:• Alice wants to pay Bob for her purchase. Bob only accepts token B on thetarget chain.• Alice wants to use a target chain application that only accepts token B.• Alice wants to exchange token A for token B but no DEX exists on the sourcechain (the source chain is a non-programmable blockchain).• None of the DEXs of the source chain has the trading pair A-B, however, aDEX on the target chain has this trading pair.• A DEX on the target chain offers a better rate for the trading pair of A-B incomparison to the source chain’s DEX.In all the above cases, a cross-chain settlement protocol is needed. There arefew attempts to build such an application, but the proposed solutions suffer fromweaknesses. In the next chapter, we review the main goals of the cross-chain set-tlement protocol and examine the existing solutions.1.5 ContributionsIn this thesis, I proposed Hotgate, a cross-chain settlement protocol between Bit-coin and EVM blockchains. Using Hotagte, users can transfer and exchange assetsbetween Bitcoin and other blockchains. The main contribution of this work is:9• Proposing a fully-decentralized protocol for wrapping BTC that doesn’t relyon third parties.• Introducing a mechanism for transferring BTC to other chains in a time lessthan the Bitcoin finalization time.• Designing the private transfer mechanism which unlinks transferred assetsfrom the original assets to preserve users’ privacy.• Implementing and testing Hotgate between Bitcoin and Ethereum testnets.10Chapter 2Design GoalsIn this chapter, I define the design goals of a cross-chain settlement protocol, aprotocol that enables users to move or exchange assets between chains. I alsoreview the existing cross-chain settlement solutions to see their advantages anddisadvantages.2.1 TrustlessA cross-chain settlement protocol works between two blockchains. Since decen-tralization is the main value of blockchains [40], the cross-chain settlement proto-col should be also decentralized.Being trustless means that the protocol only facilitates moving users’ assetsbetween chains, without taking custody of their assets. In custodian solutions, aset of custodians take control of users’ assets. So if they get hacked, users willlose their funds. However, in a trustless protocol, users have full control over theirfunds which makes the protocol way more secure.Furthermore, users can use a trustless protocol without permission. In custo-dian solutions, custodians may ban a user by ignoring her requests. However, noone can censor a user’s activities in trustless protocols.Design goal: The cross-chain settlement protocol should not depend on trustedthird parties (AKA custodians) for processing users’ requests.112.2 SpeedSpeed plays an important role in cross-chain settlement. Users of such a protocolprefer to receive their assets as soon as possible. If the protocol is slow, it maycause a huge loss for users. For example, if the cross-chain exchange takes a longtime for a user, the exchange rates may change a lot which makes a huge loss forthe user. Another example is an arbitrager who wants to move his assets to anotherchain to sell and gain revenue. If this process takes a long time, the arbitrageopportunity may be lost.In cross-chain settlements, two chains are involved in the process: the sourcechain and the target chain. On each chain, a transaction should be submitted toperform the cross-chain settlement. Therefore, users have to wait at least for theconfirmation time of the source blockchain plus the confirmation time of the targetchain.Executing cross-chain requests before they get finalized on the source chain hasa risk of transaction reversion, which is a threat to protocol security. For example,assume that a protocol moves BTC from Bitcoin to a target chain before requestsget finalized on Bitcoin. An attacker can leverage the protocol to move some BTCto the target chain. Then she forks the Bitcoin blockchain to exclude his request.Here, the attacker received the BTC without sending any request to Bitcoin.In general, if the source chain or the target chain is slow in confirming transac-tions, this causes inconveniences for the protocol users. For example, transferringBTC from Bitcoin to Ethereum takes more than one hour due to Bitcoin’s slowfinality. This delay is not acceptable for a user who needs to get BTC urgently.Design goal: Moving assets between chains in a time less than the sum ofthe source chain and target chain finalization time without harming the protocolsecurity.2.3 PrivacyPrivacy is a major concern for many blockchain users. They want to preservetheir privacy while interacting with the blockchain. Privacy-preserving is par-ticularly difficult for public blockchains since all the data is recorded on-chain[14]. Although blockchain users use anonymous identities, their real identities12can be leaked. For example, if a Bitcoin user buys a coffee in a coffee shop, theowner of the coffee shop can trace back all the user’s transactions recorded on theblockchain.The privacy in the cross-chain settlement is to unlink users’ assets on the sourcechain from their assets on the target chain. Since blockchains are transparent, it iseasy to link users’ transactions together, so anyone can find who moved assets fromone chain to another. This can reveal some information about users’ intentions.For example, if a user has moved assets between chains for arbitrages, moving newassets signals to users that there is an arbitrage opportunity on the target chain. Sothey can front-run her and capture the revenue.Design goal: When a user moves assets from the source chain to the targetchain, no one should be able to link the moved assets to the received assets.2.4 User ExperienceCross-chain settlement is a multi-step process that involves two blockchains. Oftenworking with a single chain is a complex process for many users, and introducinganother blockchain that needs another wallet to interact with make thing more com-plex.Sending transactions on two blockchains requires users to have a wallet withenough native coins on each chain. These requirements make the cross-chain set-tlement a complex process that is not suitable for regular users.In centralized protocols, third parties can improve the UX! (UX!). They cansend transactions on behalf of the users so users don’t need to interact with differentblockchains. However, being trustless is a priority in our design. We are lookingfor a solution that improves the UX without harming the decentralization of theprotocol.Design goal: Users can execute a cross-chain settlement by only interactingwith the source blockchain.2.5 Existing SolutionsBelow, I explain three existing solutions for cross-chain settlement and examinewhether they achieve our design goals or not.13CEX-DEX. One possible solution for a cross-chain settlement is using a CEX asan intermediary. In this case, a user sends token A to the CEX, withdraws token Aon the target chain, then, exchanges token A for token B using a DEX on the targetchain. This solution has four disadvantages:1. A centralized entity (CEX) is involved in the process, so it is not a trustlesssolution. A CEX may freeze the users’ assets when the user deposits them.2. It causes a lot of delays: depositing in and withdrawing out of exchangeoften is a slow process. The exchange may decide to give token A on thetarget chain with a long delay to the user.3. This solution doesn’t provide privacy for the user since CEX knows whodeposited and withdrew in the system.4. It creates a bad user experience: the user needs to perform three differentactions (send, withdraw, exchange), which require users to interact with bothchains and have the native tokens of both chains.Custodian Solutions. Some solutions use a network of custodians to enable cross-chain settlements. On the source chain, users send their assets to the custodians andcustodians give them their desired assets on the target blockchain. These solutionsare similar to the CEX-DEX solution, however, the custodians’ network is moredecentralized.To perform an action in such systems, a consensus should be reached amongcustodians. So these systems are safe as long as the majority of their custodiansare honest. In reality, a custodian solution has a few custodians which makes itvulnerable to collision or getting hacked.HTLC. As we discussed before, HTLCs [24] are used for exchanging assets be-tween two blockchains. This solution is trustless since no one expects users whoare willing to exchange their assets are involved in the process. Before creatingHTLCs on blockchains, users need to agree on the exchange rate. Using HTLC fora cross-chain settlement has the below downsides:141. HTLC is only useful for exchanging assets between chains, however, movingassets between chains are not possible using HTLC.2. When a user wants to perform a cross-chain exchange for a trading pair,she needs to find another user who wants to perform the reverse cross-chainexchange for the same trading pair.3. For an HTLC to be completed, users need to wait for the finalization of thetransaction on the slower blockchain.Solution Trustless Speed Privacy UXCEX-DEX Centralized Slow No BadCustodian Semi-decentralized Medium No GoodHTLC Decentralized Medium Partial MediumTable 2.1: Cross-chain settlement solutions comparisonAs we have seen, non of the existing solutions satisfied all the design goals. Inthe next chapter, I introduce HotGate, a cross-chain settlement protocol that worksbetween Bitcoin and EVM chains.15Chapter 3System ArchitectureIn this chapter, we introduce components of HotGate, a cross-chain settlementprotocol that works between Bitcoin and EVM-compatible blockchains. UsingHotGate, users can move or exchange assets between Bitcoin and an EVM chain.HotGate was designed based on the goals mentioned in the previous chapter.Although Bitcoin has the biggest market cap among all cryptocurrencies, itdoesn’t have a Turing complete programming language, so it is not possible tobuild dApps on it. One of the most-used dApps of programmable blockchains isDEX. HotGate offers a DEX for Bitcoin users who want to exchange their BTC ina decentralized manner.The main components of HotGate are Relay, asset pools, and network partici-pants. Relay connects Bitcoin to other chains in a trustless manner. Assets poolshelp users to exchange their assets and get their assets with a short delay. Networkparticipants provide the needed data and help the protocol run smoothly.3.1 RelayA bridge between two blockchains connects them. Some bridges only enable mov-ing assets from one blockchain to another, and some of them move the whole dataof one blockchain to another. The second type covers the first one.Relay [27] is an interoperability solution that enables users to access the wholedata of the source chain on the target chain. Figure 3.1 shows the summary of this16solution. Parties called Relayers submit block headers of the source chain on thetarget chain. The Relay contract checks the validity of submitted block headers bychecking the consensus mechanism of the source chain. Then, it decides whichblocks should be finalized according to the finalization rule of the source chain.Therefore, the Relay smart contract that exists on the target chain, acts as a lightclient of the source chain. In summary, Relay works in three phases:• Data submission: Relayers submit some data of the source chain on thetarget chain.• Data verification: Relay contract verifies the correctness of source chaindata.• Data finalization: Relay contract decides on the finalization of submitteddata so users can access it.HotGate uses Relay as its interoperability solution. Since the consensus mech-anism of the source chain and all the cross-chain data is verified by the Relaycontract, the security of the HotGate is equal to the security of its underlyingblockchains.In the case of Proof-of-Work source blockchains such as Bitcoin, the consensuscheck includes verifying that the submitted block header shows enough work hasbeen done, re-targeting the difficulty has been done correctly, etc. If the submittedheader is invalid (i.e. it does not belong to the main fork of the source chain), theRelay contract will reject it.After adding the new block header, HotGate checks for any previous blockheader that got finalized. In the case of Bitcoin, this gets done by using the longestchain rule. This means that if a block header gets buried under six valid blockheaders, Relay considers it finalized.If a block header is finalized by the HotGate contract, users can refer to it onthe target chain for proving the inclusion of some data on the source chain. Asblock headers include Merkle roots [28] of all transactions and states, HotGatecan perform any state or transaction inclusion verification using Merkle proofsgenerated by users. This means that the target chain has access to all the data of17the source chain. Any dApp on the target chain that wants to read some data fromthe source chain can leverage the Relay.In summary, there are two main interactions that one can have with the Relaycontract:• Block header submission: Relayers submit block headers of Bitcoin andearn rewards (see 1). If the block headers are not valid the submission willrevert, and if the block header won’t get finalized in the main Bitcoin chain,the Relayer will not earn the reward.• Checking data inclusion: Any user can query the contract to check the in-clusion of some data in a finalized block of the source chain (see 2). HotGatewill respond with true (in case the data is included in the finalized block), orfalse (otherwise).Procedure 1 SUBMITBLOCKHEADER(oldHeader, newHeader)1: Require oldHeader.length== newHeader.length== 80 bytes2: Require oldHeader.di f f icultyTarget == newHeader.di f f icultyTarget3: oldHash← sha2(sha2(oldHeader))4: newHash← sha2(sha2(newHeader))5: Require oldHeader has not been finalized6: Checks that newHeader has not been submitted before7: Require oldHash== newHeader.parentHash8: Require newHash< newHeader.di f f icultyTarget9: Blockchain[newHeader.height].push(newHeader)10: for (i= 0, i< 6, i++) do11: parentHash← oldHeader.parentHash12: oldHeader = f indHeader(parentHash,oldHeader.height)13: end for14: Runs pruneBlockchain(oldHeader)15: Sends reward to the RelayerRelay helps us to move data from Bitcoin to other EVM chains in the mostsecure and decentralized way. The Relay gives us access to the whole data of theBitcoin on the EVM chains where the Relay is implemented. For a Relay to workproperly, nodes called Relayers should provide the needed input data for it.18Procedure 2 CHECKTXINCLUSION(transactionId, proof, blockNumber)1: Require B[blockNumber][0] is finalized2: Gets the Relay fee3: transactionRoot← B[blockNumber][0].root4: merkleRoot← calculateRoot(transactionId, proo f )5: return transactionRoot == merkleRootFigure 3.1: How Relay works3.2 Network ParticipantsHotGate has different participants who help the protocol run smoothly. Theseparticipants are incentivized to participate in the protocol and act honestly. Thefive main participants of HotGate are Relayer, Keeper, fisherman, liquidity poolprovider, and fast pool provider.Relayers are in charge of transferring data from the source chain to the targetchain. Keepers facilitate cross-chain transfer and exchange for users. Fishermen19are responsible for monitoring Keepers’ activities. Liquidity pool providers andfast pool providers provide liquidity for exchange pools and fast pools. In thefollowing, we describe each role and its responsibilities.3.2.1 RelayerRelayers are nodes that get data from the source chain and submit them to thetarget chain. These nodes are crucial for HotGate since they provide the inputfor the Relay contract. In the case of Bitcoin, Relayers provide the contract withBitcoin’s block headers.To become Relayer, a node runs the Relayer script. This script connects theRelayer to a few full nodes of Bitcoin to get the latest block headers. Relayer scriptis lightweight so it can be run on a personal computer.Submitting and verifying block headers on the blockchain costs for Relayers.To compensate them for this cost, Relay takes fees from users and pays them tothe Relayers. The fee covers the gas amount used for submitting and verifying theblock header, plus %10 extra as a reward for the Relayer.The Relay contract checks the correctness of the submitted data and sends areward to the Relayer who provided the valid data faster. If a Relayer provides afalse or staled block header, this header gets rejected by the Relay contract and theRelayer loses the paid gas fee. Therefore, a malicious Relayer cannot cause anyharm to the protocol.HotGate’s Relayers network is a decentralized network. Anyone can becomea Relayer in HotGate and compete to collect rewards. Having a high bandwidthcan help a Relayer to get more rewards. It is important to note that in any case,HotGate is secure as the underlying blockchain, and as long as one honest Relayerexists in the system, HotGate has liveness.3.2.2 KeeperKeepers are nodes that facilitate users to perform cross-chain transfer and cross-chain exchange requests. They have two main roles in the systems:• Submitting requests: Users send their cross-chain settlement requests onBitcoin. Keepers collect and submit these requests to the target chain.20• Asset custody: No smart contract exists on Bitcoin. So users should sendtheir assets to parties called Keepers. Although Keepers take custody ofusers’ assets, their behaviours are monitored by fishermen so they cannot actmaliciously.In the following, we describe each of these responsibilities.Submitting Requests Keepers make the HotGate user experience smooth. Theycollect users’ cross-chain requests from Bitcoin and submit them to the targetchain. So, users perform cross-chain settlements by only interacting with Bitcoin(the chain they already have assets on it). This eliminates the need of having bothchains’ native tokens for cross-chain settlements.Keepers watch Bitcoin for users’ cross-chain settlement requests. For requeststhat Keepers collect, they create proofs of inclusion and submit them to the HotGatecontract on the target chain. HotGate contract verifies the validity of the proofusing the Relay and then executes the request. Checking request inclusion by Relaymakes the system trustless, i.e., Keepers cannot manipulate users’ requests. Theyonly move requests between chains.Submitting a transaction on the target chain and verifying data using Relaycost Keepers. Keepers pay these costs on behalf of users. In return for the servicethey provide, Keepers take fees from users, which compensates them for the costs(Relay fee and blockchain transaction fee) they have paid plus an extra reward forthe Keeper. The Keeper fee is reduced from users’ requests automatically.In HotGate, anyone can become a Keeper. As long as one active Keeper existsin the system, the liveness of the system is guaranteed. There is a competitionbetween active Keepers to collect and submit requests faster to earn more fees. Itis also possible for users to move their requests from Bitcoin to the target chain bythemselves.Asset Custody Another responsibility of Keepers is taking custody of users’ as-sets in a fully-decentralized manner. They help users to transfer or exchange theirassets between chains. When a user wants to perform a cross-chain settlement, shesends her assets on Bitcoin to a Keeper. Then the user provides proof of locking21her assets on the target chain to complete the cross-chain settlement. Keepers guar-antee that every wrapped asset on the target chain has an equal amount of backedBTC on Bitcoin.Each Keeper has a Bitcoin wallet. All activities of this wallet are controlled bythe smart contract on the target chain. This makes the HotGate protocol trustless.A node becomes a Keeper in the system by locking some amount of bond. Thisbond guarantees the system security, i.e., if the Keeper acts maliciously, the bondwill get slashed. The Bitcoin wallet address of Keepers is recorded in the HotGatesmart contract so users access it.Users move their assets from Bitcoin to the target chain by sending their as-sets to the Keeper’s wallet address. After sending, Keepers provide proof of lock-ing users’ assets to the HotGate contract. HotGate contract uses Relay to verifythe correctness of the proof. If the proof is valid, the HotGate contract mints thewrapped BTC for the user.Users can also receive BTC by burning their wrapped BTC on the target chain.The HotGate contract records users’ burn requests and gives limited time to theKeeper to send BTC to the user. After sending BTC, the Keeper needs to provideproof of it. Otherwise, the Keeper’s bond gets slashed.A Keeper is not allowed to move BTCs that have been sent to the wallet unlessa user makes a burning request. This ensures that every wrapped BTC has equallybacked BTC, so the price of these assets is equal. If a Keeper steals BTC, theKeeper’s bonds will be slashed.In summary, Keepers are responsible for keeping the users’ assets safe andresponding to them quickly. The above mechanisms ensure that the Keeper behavesappropriately and makes the HotGate protocol trustless.Keepers’ bonds play a crucial role in aligning Keepers’ incentives to act re-sponsibly. If the value of the bond becomes lower than the amount of BTC that isheld in the Keeper’s wallet, the Keeper has the incentive to steal all BTCs. To avoidthis, HotGate has a liquidation mechanism, which ensures that Keeper’s bonds arealways greater than the value held by the wallet.If the value of the Keeper’s bond becomes lower than the wallet balance (be-cause of the price fluctuations), the liquidation mechanism gets activated. Anyuser can buy Keeper’s bond using the wrapped BTC with a discount. Then, the22collected wrapped BTC is burnt in the system and the Keeper will be able to movethat amount of BTC from the wallet.3.2.3 FishermanFishermen monitor the Keepers’ activity. If a Keeper acts irresponsibly, a fisher-man will call the contract and slashes the Keeper. The incentive of the fishermanis to earn a slashing reward. There are two main scenarios in which a fishermanslashes the Keeper:• Lazy Keeper: The Keeper has a limited time to send BTC to the user whomade a burning request. If the Keeper doesn’t execute the request before thedetermined deadline, a slasher calls the HotGate contract to slash the Keeper.Then, part of the Keeper’s bond with a value equal to the user request is sentto the user and a percentage of that value is also sent to the slasher as areward.• Thief Keeper: If the Keeper steals BTC from the wallet, a slasher calls theHotGate contract. The slasher provides the transaction in which Keeper hasstolen BTCs. HotGate contract checks that the transaction doesn’t belong toany burn request and finds out the stolen amount. Then, part of the Keeper’sbond is slashed and goes on sale. The goal of this sale is to collect a numberof wrapped BTCs equal to the stolen amount. Anyone can participate tobuy the bond with a discount, paying in the wrapped BTC. The collectedwrapped BTCs are then burnt by the HotGate contract to make sure thatevery wrapped BTC has equally backed BTC.Fishermen play a crucial role in the system since they prevent Keepers, partieswho have users’ assets custody, to act maliciously.3.2.4 Liquidity pool providersThese parties provide liquidity for the liquidity pools of HotGate. Anyone canbecome a liquidity pool provider in our system and collect exchange fees fromusers using that liquidity pool. To provide liquidity for a pool, a user should haveboth tokens of that pool.23When a liquidity provider provides liquidity for a pool, it receives some amountof token called liquidity pool token which shows her share in that liquidity pool.Whenever the liquidity provider decides, she can remove liquidity from the pooland get the deposited asset plus collected fees.3.2.5 Fast pool providersThese parties provide liquidity for the Bitcoin fast pool of HotGate. Anyone canbecome a liquidity pool provider in our system and collect fees from users usingthe fast pool. To provide liquidity for the fast pool, a user should have wrappedBTC on the target chain.When a fast provider provides liquidity, it receives some amount of token calleda fast pool token which shows the share of her in the pool. Whenever the fastprovider decides, she can remove the liquidity from the pool and get the depositedasset plus collected fees.Becoming a liquidity pool provider or fast pool provider has a different risk/re-ward profile. The fast pool offers higher income for nodes but has a risk of loss offunds. We will explore this risk in the next chapter.3.3 Asset PoolsThere are two types of asset pools in HotGate which helps users to exchange theirassets and also get their assets faster on the target chain. The first is done usingliquidity pools, and the second is done using fast pools. Liquidity pool providersprovide liquidity for liquidity pools, and fast pool providers provide liquidity forfast pools.Liquidity pools Liquidity pools are double asset pools that are used for exchang-ing tokens. In an AMM DEX, the relative price of token A to token B is calculatedbased on the amount of deposited token A and deposited token B in the liquid-ity pool of the A-B trading pair. The amounts are calculated based on a constantproduct AMM scheme.Liquidity pool providers add liquidity to the liquidity pools to earn exchangefees. In return, they receive liquidity pool tokens that indicate their share of the24total collected fees.Fast pool This pool enables fast exchange and fast transfer in HotGate. It acceptswrapped BTC as liquidity. Fast pool providers provide liquidity for this pool. Theyreceive fast pool tokens that indicate their share of the total collected fees.25Chapter 4Main ScenariosIn this chapter, we explain the main functionalities of HotGate:• Cross-chain transfer: A user moves BTC from Bitcoin to the target chain• Cross-chain exchange: A user exchanges her BTC for other assets that existon the target chain.4.1 Cross-chain TransferIn cross-chain transfer, a user who has BTC on Bitcoin wants to move her BTC tothe target chain. This can happen for several reasons:• The user wants to use her BTC on some dApp that exists on the target chain.• The user wants to pay a merchant that only accepts tokens on the target chain.• Transaction fees on the target chain are lower than Bitcoin and the user wantsto make multiple payments.The cross-chain transfer has three modes:• Normal: The user will receive BTC on the target chain after her request getsfinalized on Bitcoin. This mode is useful for users who are not in hurry toreceive their assets.26• Private: The user wants to hide the link between her BTC on Bitcoin andwrapped BTC on the target chain. This mode is useful for users who don’twant their assets to be easily tracked.• Fast: The user will receive BTC on the target chain before her request getsfinalized on Bitcoin. Users who rush to receive BTC on the target chain cantake advantage of this mode by paying an extra fee.In the following, we explore the above modes.4.1.1 Normal Cross-chain TransferTo perform a normal cross-chain transfer, a user sends a request that locks BTC onBitcoin. To lock BTC, the user sends it to the Keeper wallet on the Bitcoin. Theuser gets the address of the Keeper wallet from the HotGate smart contract on thetarget chain. Figure 4.1 shows the workflow.In the request, the user determines the recipient address, Keeper fee, etc. Therecipient address is the address of the user on the target chain. Also, the userdetermines the fee amount she will pay to the Keeper to execute her request. Alldata is written in the Bitcoin transaction payload. Bitcoin payload is a special typeof Bitcoin output that allows users to write arbitrary data on the Bitcoin blockchain.The Keeper watches the target chain for transactions that send BTC to his wal-let and include users’ requests. After the request gets finalized on Bitcoin ( itreceives six confirmations), the Keeper submits it to the HotGate contract. If theKeeper submits a request before it gets finalized, the request will be rejected by theHotGate contract and the Keeper lose the paid transaction fee.To submit a request, the Keeper generates Merkle proof for it. The Merkelproof shows that the request has been included in a specific block. If the Keepersubmits a request that was not included in the given block, the Merkle proof will berejected by HotGate smart contract, and the Keeper lose the paid transaction fee.After checking the Merkle proof, the contract extracts the needed data fromthe request. Also, it finds how the amount of BTC the user has sent to the Keeperaddress. Then, the contract mints an equal amount of wrapped Bitcoin for the user.Also, it pays the Keeper fee from the minted BTC.27Figure 4.1: Normal cross-chain transfer scenarioThe wrapped BTC is a token that has equal value to the BTC. It is the repre-sentation of BTC on the target chain. Each wrapped BTC has an equally backedBTC, so the price of the wrapped BTC and BTC are the same. Also, whenever auser wants, she can burn the wrapped BTC and get an equal amount of BTC on theBitcoin. This is another factor in pegging the price of BTC and wrapped BTC. Theuser can use wrapped BTC in the target chain dApps. For example, she can lendthe wrapped BTC to another user through a lending dApp.4.1.2 Private Cross-chain TransferIn the normal cross-chain transfer, the user determines the recipient address in therequest. So anyone can link the BTC locked on Bitcoin to the BTC that is mintedfor the user. This means that the user doesn’t have privacy when moving BTCbetween chains.As discussed before, Bitcoin transaction doesn’t provide full privacy. It is easyfor users to track the transactions of a user to find the history of all the user pay-ments. There is a solution in Bitcoin called Coinjoin [34] which adds privacy toBitcoin payments (see 4.2). Assume two users who want to send one BTC. If eachuser does it separately (creates a separate transaction), the link between the recipi-ent and the receiver address is clear. However, by combining the transactions into28Figure 4.2: How Coinjoin works [5]a single transaction, the link between recipients and receivers is disappeared.To do so, users send their desired transaction inputs and outputs to a coordi-nator. The coordinator creates a transaction with the given inputs and outputs andsends it back to users for signing. After each user signed the transaction, it getsbroadcast on the network. Now when an external party looks at this transaction, itis equally possible that each sender sends money to a receiver.We leverage this technique to add privacy to HotGate. Users who want tomove BTC from Bitcoin to another chain can collaborate to add privacy to theirtransactions. Users choose a standard amount of BTC that they are willing to move(e.g. one BTC). Then, each sends the desired transaction input and the recipientaddress to a coordinator. The coordinator creates a transaction that has multiplesame-value outputs that go to the Keeper’s address. Also, the coordinator writesthe given recipient addresses in the transaction payload. Then the coordinator sendsthis transaction to users to sign. Since payloads are aggregated in a single payloadand users send BTC to the Keeper in a single transaction, the external user cannotlink the user’s Bitcoin address to the desired recipient address.Although this solution provides a level of privacy for users, it has two limita-tions:• The amount of BTC that the user wants to move should be a standard number.29• There is a need for a few counterparties who are willing to do the privatecross-chain transfer at the same time.By running the protocol for a while, we can find the most common number ofBTC that is moved by users to choose it as the standard number. Also, we cangive a discount for the private transaction to incentive most users to use this kindof transfer instead of normal cross-chain transfer to increase the number of privatetransfer users.4.1.3 Fast Cross-chain TransferWhen a user wants to transfer an asset from Bitcoin to the target chain, first shelocks the asset on Bitcoin. Then, she mints the wrapped BTC on the target chainby providing proof for the inclusion of the lock transaction. Because of Bitcoin’sslow finality, it takes around sixty minutes for the user to be able to provide theinclusion proof for the lock transaction, so, the cross-chain transfer process will beslow.The number of confirmation blocks “K” needed for a block to get finalized iscalled the finality parameter. In fast transfer, the user receives the wrapped BTC onthe target chain after her lock transaction gets buried under F (less than K) blocks.In other words, the user receives her transferred asset before her lock transactionbecomes finalized on Bitcoin, reducing the waiting time for the user.For example, suppose that Alice wants to transfer some amount of BTC fromBitcoin to the target chain (see figure 4.3). She locks this amount on Bitcoin.After this transaction gets F confirmations, she sends the fast transfer request tothe HotGate contract. Leveraging the Relay, the HotGate contract checks whetherthe lock transaction has gotten F confirmations or not. If the condition is satisfied,the contract sends an equivalent amount of BTC from the Bitcoin fast pool to Alice,extracting the fastFee. The fastFee is the fee that the fasts pool gets from a user forthe provided service.After the user request gets finalized on Bitcoin, HotGate contract mints wrappedBTC for it. Then, it sends the minted tokens to Bitcoin fast pool to compensate itfor the transferred amount.The above mechanism exposes fast pool providers to a risk: since the user30Figure 4.3: Fast cross-chain transfer scenariorequest is not finalized when the tokens get transferred from the Bitcoin fast pool,there is a probability that the transaction gets reverted [31] and the fast pool doesn’tget compensated. In this case, the fast pool providers suffer loss.There are two cases where a block with F confirmations gets rewound from thecanonical chain. First, it can rewind because of a natural fork in the blockchain.Second, an attacker can rent a mining system and try to rewind that block. Tomitigate these risks, we need to choose proper values for the below parameters:• fastFee: A user who performs a fast transfer should pay a percentage of thetransferred amount as a fee to the Bitcoin fast pool.• fastLimit: There is a limit on the amount that can be transferred in a singleBitcoin block using the fast feature.To determine the above parameters, we need to calculate the probability andcost of reversion of a block with F confirmations:• reversionProbability: The probability of reversion of an F-confirmed trans-action.• reversionCost: The cost of reverting an F-confirmed block for an attacker.31To make the fast transfer protocol secure, the below conditions should be sat-isfied:• f astFee > reversionProbability: It motivates fast pool providers to partici-pate in the protocol.• reversionCost > f astLimit: It demotivates attackers to revert an F-confirmedblock as it won’t be profitable for them to perform such an attack.4.2 Cross-chain ExchangeIn cross-chain exchange, a user who has BTC on Bitcoin wants to exchange herBTC for another token on the target chain. Currently, users move their BTC tocentralized exchanges, swap them for the desired asset and then withdraw it on thetarget chain. This solution is not in favor of users who care about decentralization.Also, it is a three-step process that makes the user experience poor.Cross-chain exchange has two modes:• Normal: The user will receive the exchanged token on the target chain afterher request on Bitcoin gets finalized. This mode is useful for users who arenot in hurry to receive their assets.• Fast: The user will receive the exchanged token on the target chain beforeher request on Bitcoin gets finalized. This mode is useful for users who rushto receive their assets on the target chain.In the following, we explore the above modes:4.2.1 Normal Cross-chain ExchangeTo perform a normal cross-chain exchange, a user sends an exchange request onBitcoin. In the request, the user determines the below information:• Recipient address: This is the address that the exchanged tokens are sent toit.• Percentage fee: This is the amount of fee that the user wants to pay theKeeper.32• Exchange token: Address of exchange token that the user is willing to re-ceive.• Output amount: The minimum amount of exchange token that the user ex-pects to receive.• Deadline: The deadline for executing the exchange request.By submitting this request, the user also locks some amount of BTC. This BTCwill be then exchanged for the desired exchange token. After the user request getsfinalized on Bitcoin, a Keeper collects it and submits it on the target chain contractby providing Merkle proof. HotGate contract then checks the inclusion proof ofthe transaction and executes it. The contract first extracts the information fromthe request, then mints the wrapped BTC for the user, and after that exchangesthe wrapped BTC for the desired exchange token using the corresponding liquiditypool.In the exchange process, three conditions are checked:• Liquidity pool existence: To exchange wrapped BTC for the exchange to-ken, the liquidity pool of this pair should exist. The user might submit anexchange token address that doesn’t have a liquidity pool with the wrappedBTC.• Deadline: When the contract wants to exchange assets, the deadline for ex-changing should not be passed. This can happen if the Keeper submitted therequest with a long delay, or if the deadline was too tight.• Output amount: The user expects to receive a minimum amount after ex-changing her wrapped BTC. If the amount that the user can receive is lessthan the expected amount, the exchange will be failed. This can happenbecause of price fluctuations.If these conditions are satisfied, the exchange will be successful and the ex-changed tokens are sent to the determined recipient address. Otherwise, the ex-change will not take place. In this case, the HotGate contract sends the wrappedBTC to the recipient’s address. This ensures that in both cases the user’s fundwon’t get stuck in the protocol.334.2.2 Fast Cross-chain ExchangeThe fast cross-chain exchange process is the combination of fast cross-chain trans-fer and normal cross-chain exchange. The user receives wrapped BTC from thefast pool and the received wrapped BTC will be exchanged through the liquiditypool. Here, by separating fast pools from liquidity pools, we separate the risks ofusers who provide liquidity for fast pools from users who provide liquidity pools.Fast cross-chain exchange is a suitable option for users who need to receivetheir exchange assets before the finalization of their request on Bitcoin. For exam-ple, when the price of BTC drops quickly, many users want to exchange their BTCfor stablecoins as fast as possible. This feature helps users to reduce their losses.34Chapter 5Incentive DesignIn this chapter, we describe the incentives of network participants for collaboratingin the protocol. The incentive mechanisms help us to achieve our design goals,otherwise, nodes will not provide their services and the protocol will stop working.5.1 RelayerAs discussed before, Relayers get block headers from Bitcoin’s full nodes andsubmit them on the target chain. So running such a node costs the Relayer. IfRelayers don’t get compensate properly, they will leave the network which harmsthe liveness of the protocol, i.e, users cannot prove that their requests have beenrecorded on Bitcoin.To compensate Relayers, HotGate takes fees from users who want to use thesubmitted block headers. HotGate calculates the required amount of fee in epochsof block headers, based on the cost of block header submission and Relay usagerate. The number of blocks in one epoch is such that we can estimate the numberof queries sent to the Relay in an epoch using the number of queries in the previousepoch. Therefore, the fee that a user needs to pay for verifying some data decreasesif the total number of requests had increased in the previous epoch.To avoid too much increase in the Relay fee, we assume a base number forqueries in an epoch. The excess fee from extra usages in previous epochs getsaccumulated in the Relay contract. This amount is used to pay the Relayers whose35block headers have been in an epoch with less than the base number of queriesusages. The amount of fee that a user pays is calculated as follows:Fee=G∗P∗Mmax(N,B)• G: block header submission gas usage• P: gas price• M: number of blocks in an epoch• N: previous epoch queries• B: base number of queriesThe Relayer reward is the amount of fee that the Relayer paid for block headersubmission multiplied by a factor greater than 1. This ensures that the Relayer getsfully compensated and earns an extra reward.We decouple the fee of a block header with the number of requests belongingto that block header. Otherwise, if a block header doesn’t include any request noone has the incentive to submit that header which harms the protocol’s liveness.5.2 KeeperKeepers lock collateral in the system which enables users to mint and burn BTC.Also, they move users’ requests from Bitcoin and submit them on the target chain.To execute the request, they need to pay the Relay fee. In summary, keepers havethree main costs:• Target chain transaction fee: Keepers submit users’ cross-chain requests onthe target chain. They pay the gas fee for executing these requests.• Relay fee: Using Relay to check the inclusion of requests has a fee. This feeis paid by the Keeper who submits the request.• Capital cost: Keepers lock some amount of collateral that they don’t haveaccess to it.36To compensate keepers for the above costs, users who perform cross-chaintransfers or exchange pay fees to keepers. This fee consist of two part:• Fixed fee: target chain transaction fee and Relay fee that keepers pay areindependent of the value that the user sent to them on Bitcoin. Keepers paythese fees in the target chain native token. To compensate them, an equalamount of BTC will be taken from the users’ locked amount and given to thecorresponding keeper.• Dynamic fee: this fee is a percentage of BTC that a user wants to transfer orexchange. It incentives keepers to lock their collateral in the system so thatusers are able to mint and burn BTC.5.3 FishermanFishermen monitor keepers’ activity and slash them if they behave maliciously.The incentive of fishermen for monitoring the system is to earn a slashing reward,which is taken from the collateral of the keeper who misbehaves.5.4 Liquidity providersLiquidity pool providers and fast pool providers earn fees from the liquidity poolsand fast pool. This fee is taken from the users who use a liquidity pool or a fastpool. In the case of a liquidity pool, this fee is a percentage of the input token thata user wants to exchange. In the case of the fast pool, the fee is a percentage ofthe token that the user receives from it. These fees are evenly distributed betweenliquidity providers.5.5 DiscussionThe incentive design plays a crucial role in Hotgate. It should motivate Hotgateparticipants (Relayer, Keeper, Fisherman, and Liquidity providers) to follow theprotocol rules and behave honestly. This guarantees the safety and liveness ofHotgate. Regarding safety, the only factor that prevents Keepers to steal users’assets is the economic incentive. Fishermen are expected to monitor Keepers and37report their malicious activities. If Keepers can bribe fishermen to stop monitoring,they can steal users’ assets. Regarding liveness, Relayers should have a properincentive to submit block headers as soon as they are created. If all Relayers leavethe protocol, the users’ requests get stuck. Or if Relayers submit block headerswith a long delay, the wrapping process becomes slow. Therefore, many users stopusing Hotgate.The proposed incentive design has not been fully analyzed. It is a complexproblem since several participants with different motivations are involved in theHotgate protocol. For example, if Keepers behave honestly for a while, fisher-men lose their incentives to monitor them and leave the network. In the absenceof fishermen, Keepers can steal users’ assets. This example shows that more in-vestigation is needed to make sure all participants’ incentives are aligned with theprotocol goals. The previous works also haven’t discussed the incentive design andit is still an open research problem.38Chapter 6ImplementationThe proposed cross-chain settlement protocol (HotGate) described in previous sec-tions is implemented [7] between the Bitcoin testnet and the Ethereum testnet(called Ropsten). Blockchain testnets are networks designed for testing smart con-tracts and dApps, so users don’t have to spend real money to test their writtencodes. Testnet networks work in the same way as the main networks, except thattheir consensus mechanism is often modified to make it easy for miners to add newblocks. Smart contracts of HotGate are written in Solidity version 8 [10]. Thecontracts are tested and deployed to Ropsten using Hardhat [6]. Contracts of theHotGate AMM DEX are forked from Uniswap V2 contracts [12].Scripts for Relayer and Keeper are written in JavaScript. They use Infura [8]for querying and sending data to Ropsten. Also, they use Blockstream [3] to getBitcoin data. The protocol is tested by launching one Keeper and one Relayer nodeon an Amazon web services (AWS) Ubuntu Server 18.04 LTS (with 2 GB memoryand 1 core processor).The tested scenarios are normal and fast cross-chain transfer and normal andfast cross-chain exchange. To choose the fast feature parameters (fastFee andfastLimit), we assume that at most %10 of the Bitcoin miners are malicious. Basedon [38], the reversion probability of an F-confirmed block is upper bounded by(4β (1−β ))F+1. Here, we set F = 2, which means users will receive their wrappedassets after 20 minutes (which is an acceptable delay). According to this formula,reversionProbability for F = 2 is upper bound by 0.046. By setting the fastFee39equal to %5, there is enough incentive for fast pool providers to deposit liquidity.To determine fastLimit, we assume that an attacker rents %10 of Bitcoin miningpower. Based on [9], it costs around $10k per block for the attacker to rent therequired mining infrastructure. So, if we assume that fastLimit is less than $10k,there is no incentive for the attacker to conduct this attack.40Chapter 7ConclusionIn this work, we propose HotGate, a cross-chain settlement protocol that enablesusers to move or exchange their assets between Bitcoin and programmable blockchains.Bitcoin has the highest market cap among all cryptocurrencies but it doesn’t offerprogrammability, so Bitcoin’s users don’t have access to any dApp. HotGate en-ables Bitcoin’s users to get access to ecosystems of multiple blockchains. Theproposed protocol is implemented between the Bitcoin testnet and the Ethereumtestnet.HotGate uses Relay, a fully decentralized interoperability protocol that con-nects blockchains directly together. So instead of relying on third parties to providevalid data of the source chain on the target chain, Relayers only provide the data,and the validity of it is checked by the smart contract.We identify two weaknesses of Bitcoin: speed and privacy. Transactions getfinalized on Bitcoin after six confirmations which take around 1 hour. To overcomethe Bitcoin latency, we introduced fast pools that give users their wrapped BTCbefore their request gets finalized on the Bitcoin by paying an extra fee. To increasethe privacy of users’ assets, we unlink users’ assets on Bitcoin from their wrappedassets on the target chain using an approach similar to mixing protocols.We also improve the user experience so that users get their wrapped assetswithout interacting with both chains. They only need to send their request onBitcoin and nodes called Keepers move their request to the target chain.In summary, the main advantages of the Hotgate protocol are:411. Decentralization: Users can move BTC from Bitcoin to other programmableblockchains without trusting third parties. All the process of moving assetsis controlled by smart contracts.2. High-speed: Instead of waiting one hour (which is the Bitcoin finalizationtime), users can move BTC from Bitcoin to other programmable blockchainsin less than 20 minutes.3. Privacy: Hotgate protects users’ privacy in transferring assets between blockchains.External observers cannot link wrapped BTC to the native BTC.4. Smooth UX: From the users’ perspectives, the process of wrapping BTChappens with one click. This means that users don’t need to interact withboth blockchains to wrap their assets.The proposed protocol also has below limitations:1. High-cost: Hotgate uses Relay to access the data of Bitcoin on other blockchains.Since Relay verifies all the data on-chain, it has a higher cost in comparisonto other solutions.2. Limited Fast Transfer: To avoid attacking the protocol, we limit the amountthat can be transferred in a fast way from Bitcoin to another blockchain.If there is a huge demand for this feature, Hotgate cannot process all therequests.3. Long Wait for Private Transfer: When a user wants to wrap BTC privately,there should be at least two other users who want to wrap the same amountof BTC privately. This makes the waiting time for the private transfer longerthan normal transfer.42Chapter 8Appendix8.1 Terminology8.1.1 Wrapped AssetAccording to [19], the definition of wrapped asset is: ”The wrapped asset is a tokenthat represents a real-world or crypto asset, and it is backed by the represented assetor assets of equal value. The backing asset is put in a vault called a “wrapper”(hence wrapped asset). It is issued on a blockchain, and it is supposed to keepthe same value as the represented asset. Tokenizing an asset means converting itsstructure to a blockchain-compliant one so that smart contracts can manage it.”8.1.2 Wrapped TokenAccording to [19], the definition of the wrapped token is: ”Wrapped tokens are aparticular category of wrapped assets that is not intended to create a crypto rep-resentation of real-world assets such as gold, stock, or fiat currencies but of othercrypto assets instead. The reason for their existence is because, as blockchains areentirely isolated from the external world, they are also isolated from each other.”Wrapped tokens help us to move the native currency of one blockchain to another.438.1.3 BurningBurning is the process of destroying some amount of wrapped tokens by its smartcontract. Assuming that the current supply of a wrapped token is Y , by burningX wrapped tokens, the total supply reduces to Y −X . Users burn their wrappedtokens to get the exact amount of the native token.8.1.4 Gas FeeAccording to [33]: ”The creator of a transaction is responsible for specifying,among other fields, a gas limit and a gas price for the transaction. The gas limit is ameasure of the cost (in computation, storage, and so on) imposed on the blockchainby the transaction. The gas price specifies how much the transaction creator is will-ing to pay per unit of gas”. Having gas limit and gas price, the cost of executing atransaction on the blockchain is gaslimit ∗gasprice.8.1.5 Merkle TreeAccording to [35]: ”Merkle trees are named after Ralph Merkle. Bitcoin and othercryptocurrencies use Merkle trees, also called hash trees, to encode and encryptblockchain data efficiently and securely. Merkle trees are created by repeatedlycalculating hashing pairs of nodes until there is only one hash left: the root hashor Merkle root, which is a summary value. They are constructed using a bottom-up approach in which each transaction is hashed, then each pair of transactions isconcatenated and hashed together, and so on until there is one hash for the entireblock.”8.1.6 Proof of WorkAccording to [22]: ” Proof of Work (PoW) contained in Bitcoin is used to pro-tect the ledger blockchain from unwanted changes. PoW on Bitcoin works in thefollowing way: All information contained in a candidate block is calculated byits hash value. This hash value generated must meet the criteria of difficulty leveldetermined by the system. If the hash value does not meet the criteria, then thecalculation will be repeated by changing the value of nonce (number once). Nonceis a value that does not have any meaning, but is intentionally added to the block44in order to generate a hash value according to the conditions. If the hash value hasnot met the value of the rule, the nonce value will be changed again until the minerfinds a hash value that meets the criteria.”45Bibliography[1] URL https://www.coindesk.com/learn/2021/08/20/what-is-an-automated-market-maker/. → pages x, 5[2] . URL https://developer.bitcoin.org/devguide/block chain.html. → pages x, 2[3] blockstream, . URL https://blockstream.com/. → page 39[4] Btc relay, a bridge between the bitcoin blockchain & ethereum smartcontracts. URL http://btcrelay.org/. → page 7[5] URL https://bitcoinmagazine.com/technical/a-comprehensive-bitcoin-coinjoin-guide.→ pages x, 29[6] hardhat. URL https://hardhat.org/. → page 39[7] implementation. URL https://github.com/MahyarDaneshpajooh/hotgate. →page 39[8] infura. URL https://www.infura.io/. → page 39[9] miner rental. URL https://www.miningrigrentals.com/rigs/sha256ab. →page 40[10] solidity. URL https://docs.soliditylang.org/en/v0.8.17/. → page 39[11] ultra sound money. URL https://ultrasound.money/. → page 4[12] uniswap v2. URL https://github.com/Uniswap/v2-core. → page 39[13] H. Adams, N. Zinsmeister, and D. Robinson. Uniswap v2 core. 2020. →page 546[14] G. Almashaqbeh and R. Solomon. Sok: Privacy-preserving computing in theblockchain era. pages 124–139, 2022.doi:10.1109/EuroSP53844.2022.00016. → page 12[15] K. M. Alonso and J. Herrera-Joancomartı´. Monero - privacy in theblockchain. IACR Cryptol. ePrint Arch., 2018:535, 2018. → page 6[16] R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia. A survey onblockchain interoperability: Past, present, and future trends, 2021. → page 6[17] V. Buterin. Ethereum white paper: A next generation smart contract &decentralized application platform. 2014. URLhttps://cryptorating.eu/whitepapers/Ethereum/Ethereum white paper.pdf.→ pages iii, 3[18] V. Buterin. Chain interoperability. 2016. URL https://www.r3.com/wp-content/uploads/2017/06/chain interoperability r3.pdf. →pages iii, 6[19] G. Caldarelli. Wrapping trust for interoperability: A preliminary study ofwrapped tokens. Information, 13(1), 2022. ISSN 2078-2489.doi:10.3390/info13010006. URL https://www.mdpi.com/2078-2489/13/1/6.→ page 43[20] M. Castro. Practical byzantine fault tolerance. 04 2001. → page 1[21] P. Frauenthaler, M. Sigwart, C. Spanring, and S. Schulte. Testimonium: Acost-efficient blockchain relay. 2020. doi:10.48550/ARXIV.2002.12837.URL https://arxiv.org/abs/2002.12837. → page 8[22] I. Gemeliarana and R. Sari. Evaluation of proof of work (pow) blockchainssecurity network on selfish mining. 02 2019.doi:10.1109/ISRITI.2018.8864381. → page 44[23] A. Hentschel, D. Shirley, and L. Lafrance. Flow: Separating consensus andcompute. 2019. doi:10.48550/ARXIV.1909.05821. URLhttps://arxiv.org/abs/1909.05821. → page 6[24] M. Herlihy. Atomic cross-chain swaps. 2018.doi:10.48550/ARXIV.1801.09515. URL https://arxiv.org/abs/1801.09515.→ page 14[25] L. Lamport. Paxos made simple. 2001. → page 147[26] L. Lamport, R. Shostak, and M. Pease. The byzantine generals problem.ACM Trans. Program. Lang. Syst., 4(3):382–401, jul 1982. ISSN0164-0925. doi:10.1145/357172.357176. URLhttps://doi.org/10.1145/357172.357176. → page 1[27] R. Lan, G. Upadhyaya, S. Tse, and M. Zamani. Horizon: A gas-efficient,trustless bridge for cross-chain transactions. 01 2021. → page 16[28] R. C. Merkle. A digital signature based on a conventional encryptionfunction. In A Conference on the Theory and Applications of CryptographicTechniques on Advances in Cryptology, CRYPTO ’87, page 369–378,Berlin, Heidelberg, 1987. Springer-Verlag. ISBN 3540187960. → page 17[29] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2009. URLhttp://www.bitcoin.org/bitcoin.pdf. → pages iii, 3[30] Q. Nguyen, A. Cronje, M. Kong, E. Lysenko, and A. Guzev. Lachesis:Scalable asynchronous bft on dag streams, 2021. URLhttps://arxiv.org/abs/2108.01900. → page 3[31] J. Niu, C. Feng, H. Dau, Y.-C. Huang, and J. Zhu. Analysis of nakamotoconsensus, revisited. Cryptology ePrint Archive, Paper 2019/1225, 2019.URL https://eprint.iacr.org/2019/1225. https://eprint.iacr.org/2019/1225. →page 31[32] T. Rocket, M. Yin, K. Sekniqi, R. Van Renesse, and E. Sirer. Scalable andprobabilistic leaderless bft consensus through metastability. 06 2019. →page 3[33] T. Roughgarden. Transaction fee mechanism design. EC ’21, page 792, NewYork, NY, USA, 2021. Association for Computing Machinery. ISBN9781450385541. doi:10.1145/3465456.3467591. URLhttps://doi.org/10.1145/3465456.3467591. → page 44[34] R. Stu¨tz, J. Stockinger, B. Haslhofer, P. Moreno-Sanchez, and M. Maffei.Adoption and actual privacy of decentralized coinjoin implementations inbitcoin, 2021. URL https://arxiv.org/abs/2109.10229. → page 28[35] H. Sa´ez de Oca´riz Borde. An overview of trees in blockchain technology:Merkle trees and merkle patricia tries. 02 2022. → page 44[36] J. Teutsch, M. Straka, and D. Boneh. Retrofitting a two-way peg betweenblockchains. 08 2019. → page 948[37] Y. Tong Lai, J. Prestwich, and G. Konstantopoulos. Flyclient -consensus-layer changes. 2019. URL https://zips.z.cash/zip-0221. → pages6, 8[38] P. Viswanath. Lecture 6: Safety of bitcoin. 2021. URLhttps://courses.grainger.illinois.edu/ece598pv/sp2021/lectureslides2021/ECE 598 PV course notes6.pdf. → page 39[39] M. Westerkamp and J. Eberhardt. zkrelay: Facilitating sidechains usingzksnark-based chain-relays. pages 378–386, 2020.doi:10.1109/EuroSPW51379.2020.00058. → page 8[40] K. Wu¨st and A. Gervais. Do you need a blockchain? pages 45–54, 2018.doi:10.1109/CVCBT.2018.00011. → pages 2, 11[41] T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y. Zhang, Y. Jia, D. Boneh, andD. Song. zkbridge: Trustless cross-chain bridges made practical, 2022. URLhttps://arxiv.org/abs/2210.00264. → page 8[42] J. Xu, K. Paruch, S. Cousaert, and Y. Feng. Sok: Decentralized exchanges(dex) with automated market maker (amm) protocols, 2021. URLhttps://arxiv.org/abs/2103.12732. → page 4[43] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias,P. Moreno-Sanchez, A. Kiayias, and W. Knottenbelt. Sok: Communicationacross distributed ledgers. IACR Cryptol. ePrint Arch., 2019:1128, 2019. →page 9[44] A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais, andW. Knottenbelt. Xclaim: Trustless, interoperable, cryptocurrency-backedassets. In 2019 IEEE Symposium on Security and Privacy (SP), pages193–210, 2019. doi:10.1109/SP.2019.00085. → page 849
Thesis/Dissertation
eng
Electrical Engineering
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivatives 4.0 International
Graduate
Feng, Chen
HotGate : trustless cross-chain settlement protocol
Text