托管服务和应用Escrow Services and Applications

Lab 3: Escrow Services and Applications

Introduction

Consider a buyer and a seller, who do not necessarily trust each other, get engaged in a transaction. A problem with a circular dependency is who should make the first move? Should the buyer sends her payment to the seller before the seller sends the product? or the reverse? Traditionally, if the seller is large retailers with significant reputation, like Walmart, the buyer may feel comfortable to make the first move and send the payment, with the implicit trust assumption that Walmart will ship the good. For smaller sellers, buyers typically pay to a trusted third-party, such as eBay or Amazon. If the buyer does not receive the item, this third-party can mediate the dispute and refund the buyer. The functionality of this third-party is escrow.

代码提供-右侧点击下载即可。付费下载购买Code provided-click download on the right. Paid download purchase

System design

In this lab, we develop a blockchain-based escrow service (with physical goods). In real life, the escrow model that will be described next is used in the now-ceased Silk Road. The system model consists of four parties: a buyer, a seller, an escrow contract and a mediator (or arbitrator). In the beginning, Bob the Buyer sends the payment (or security deposit) to a contract address called escrow address from which neither Bob or Alice can withdraw unilaterally. After the transaction occurs in the physical world, if both the seller and buyer agree on the transaction state (success or failure), the escrow contract is notified to transfer the payment according (to the seller or to the buyer). In the case of dispute, an off-chain mediator (or arbitrator as in the figure) can investigate what happened and decide which party can withdraw funds from the escrow address. The workflow of escrow service is listed below:

  1. The buyer sends a security deposit to the escrow service.
  2. (Case 1): The transaction is successful and is agreed upon between the buyer and the seller. Signaled by both parties, the escrow service proceeds to send the deposit to the seller.
  3. (Case 2): The transaction fails and the failed state is agreed upon between the buyer and seller. Signaled by both parties, the escrow service proceeds to refund the buyer.
  4. (Case 3): There is a dispute about the state of transaction. For instance, the buyer may think the transaction finishes successfully but the seller may think the opposite. In this case, an off-chain trusted party is used to arbitrate the transaction state and will tell the escrow service of her decision. Depending on the result, the escrow service may refund the buyer or pay the seller.
  • Note that in all cases, the escrow service should collect certain amount of security deposit for the service fee (e.g., 1% of the security deposit).

Contract design diagram

A system design to implement the above workflow is to write a smart contract that plays the role of escrow service. Here, your escrow smart contract relies on, in addition to its own contract address, three externally owned addresses (EOA): a seller, a buyer and an offline mediator. Each account possesses certain tokens. Minimally, the system runs two smart contracts, an escrow contract and a token contract. And the addresses (EOAs) are hard-coded.

In the following, you will design and implement a Ethereum-based escrow service, iteratively. First (in Task 1 and 2), you will implement the basic two-contract design described as above. Then (in Task 3), you will be asked to base the escrow service on Ether, instead of escrow-specific token. After that (in Task 4), you will extend the design by supporting account and product managements/registration.

Task 1: Token contract

In this task, you are required to implement a simple token and use it to support the smart escrow contract.

  • Implement a simple token contract SimpleToken that supports function transfer(address sender, address recipient, uint256 amount)
  • Use the token to back the accounts of buyer and seller in the smart escrow contract.

Task 2: Escrow contract supporting buyer-seller agreement

Implement the smart escrow contract that supports the following functions:

  • MakeDeposit() which allows the buyer to send the payment/security deposit to the smart contract. The payment should be the price of product plus service fee (1%).
  • ApproveTxSuccess() which allows only the buyer or seller to send their approval and to signal the success of transaction. Only both parties approve, the contract sends the payment to the seller.
  • ApproveTxFail() which allows only the buyer or seller to send their approval and to signal the failure of transaction. Only both parties approve, the contract refunds the payment back to the buyer.

Task 3: Escrow contract supporting dispute resolution

Dispute occurs when the seller sends ApproveTxFail() and the buyer sends ApproveTxSuccess() (or vice versa). When this happens, the escrow contract enters the following time-lock logic: It will wait for the input of an off-chain mediator via function Arbitrate(). If such an input is not received for the 2 minutes, the contract will time-out and refund the deposit to the buyer.

  • Implement Function Timelock(), such that the smart contract waits for 2 minutes (or 12 Ethereum blocks) for the event of Arbitrate() invocation. If the timeout is reached, it refunds. The function Timelock() can be called by ApproveTxSuccess()/ApproveTxFail() after a dispute state occurs and should do two things:
    • Record current time/block height (depends on how you’re measuring the time)
    • Change the transaction state to dispute (Transaction is marked as dispute)
  • Implement Function Arbitrate() which is supposed to be called by account mediator. The mediator decides the transaction state and the function takes action to refund the buyer (upon the transaction failure) and to pay for the seller (upon the transaction success).
    • Arbitrate() method should check the difference between time/block heights in addition to the transaction state

Task 4: Revised escrow contract supporting Ether

Revise your escrow contract so that it supports the escrow between Ether owners.

Task 5: Account management

Implement a management contract that supports account/product registration, destroy, etc. Your smart contracts should eventually support multiple buyers/sellers on multiple products.

Bonus Task (30%)

Deploy and run the code of all previous tasks on our on-campus Blockchain. Include screenshots of the results in your report. You can use [this tutorial] as a reference of how to deploy smart contracts on the on-campus Blockchain.

Deliverable

  • For all tasks, you should 1) submit your smart-contract code, and 2) show the screenshot of the program execution.

Q/A

  • How to implement timeout on smart contract?
    • Hint: You can implement the timeout differently: one design is to rely on an off-chain party to send probe request periodically, which after timeout, triggers the escrow contract to refund/withdraw the deposit.
    • Alternatively, you can make refund and withdraw as two functions callable by the buyer and seller, respectively. These functions, before refund and withdraw, will need to check if timeout holds.
  • How can the “escrow”account send ether to either the seller account, or refund ether back to the buyer account?
    • Hint: You can use functions address.transfer() or address.send(). Such a function transfers ether from the escrow-contract account to the address, which can be either seller or buyer account.
    • Hint: To send ether to the escrow contract, you can send a regular transaction from off-chain.
    • 实验3:托管服务和应用
      介绍
      考虑不一定彼此信任的买方和卖方进行交易。循环依赖的问题是谁应该采取第一步?买方应该在卖方发送产品之前先将付款发送给卖方吗?还是相反?传统上,如果卖方是声誉卓著的大型零售商(如沃尔玛),那么买方可能会很乐意采取先举并发送付款的隐性信任假设,即沃尔玛将发货。对于较小的卖家,买家通常向可信赖的第三方付款,例如eBay或Amazon。如果买家未收到该物品,则该第三方可以调解争议并向买家退款。该第三方的功能是托管。系统设计
      在本实验中,我们开发了基于区块链的托管服务(包括实物商品)。在现实生活中,现在将终止的“丝绸之路”中将使用下面将描述的代管模型。系统模型由四方组成:买方,卖方,代管合同和调解员(或仲裁员)。最初,买方Bob将付款(或保证金)发送到一个称为托管地址的合同地址,Bob或Alice都不能从该地址单方面取款。在实体世界中发生交易之后,如果买卖双方都同意交易状态(成功或失败),则将代管合同通知根据(向卖方或买方)转移付款。在发生争议的情况下,链下调解员(或图中的仲裁员)可以调查发生的情况,并确定哪一方可以从托管地址提取资金。托管服务的工作流程如下:买方将保证金发送到托管服务。
      (情况1):交易成功,并且在买卖双方之间达成协议。在双方的信号下,托管服务继续将定金发送给卖方。
      (情况2):交易失败,并且买卖双方在失败状态上达成共识。在双方的信号下,托管服务将继续退款给买家。
      (案例3):关于交易状态存在争议。例如,买方可能认为交易成功完成,但卖方可能认为相反。在这种情况下,将使用链下可信任方来仲裁交易状态,并将委托决定告知托管服务。根据结果​​,托管服务可能会退还买家或向卖家付款。
      请注意,在所有情况下,托管服务都应收取一定数量的保证金作为服务费(例如,保证金的1%)。
      合同设计图实现上述工作流程的系统设计是编写一个充当托管服务角色的智能合约。在这里,您的托管智能合约除了依赖其自己的合约地址外,还依赖于三个外部拥有的地址(EOA):卖方,买方和离线调解员。每个帐户都拥有某些令牌。最低限度,系统运行两个智能合约,一个托管合约和一个令牌合约。地址(EOA)是硬编码的。

      在下文中,您将迭代设计和实现基于以太坊的托管服务。首先(在任务1和2中),您将实现上述基本的两合同设计。然后(在任务3中),将要求您将托管服务基于Ether,而不是托管特定的令牌。之后(在任务4中),您将通过支持帐户和产品管理/注册来扩展设计。

      任务1:代币合约
      在此任务中,您需要实现一个简单的令牌并将其用于支持智能托管合同。

      实现支持功能转移的简单令牌合约SimpleToken(地址发送者,地址接收者,uint256金额)
      使用令牌来支持智能托管合同中的买方和卖方账户。
      任务2:托管合同支持买卖双方协议
      实施支持以下功能的智能托管合同:

      MakeDeposit()允许买方将付款/保证金发送到智能合约。付款应为产品价格加上服务费(1%)。
      ApproveTxSuccess(),仅允许买方或卖方发送批准书,并表示交易成功。只有双方同意,合同才会将付款发送给卖方。
      ApproveTxFail()仅允许买方或卖方发送批准书,并指示交易失败。只有双方同意,合同才会将付款退还给买方。
      任务3:托管合同支持争议解决
      当卖方发送ApproveTxFail()而买方发送ApproveTxSuccess()时发生争执(反之亦然)。发生这种情况时,托管合同将输入以下时间锁定逻辑:它将等待通过功能Arbitrate()输入链下中介的信息。如果在2分钟内未收到此类输入,则

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » 托管服务和应用Escrow Services and Applications

提供最优质的资源集合

立即查看 了解详情