relayd

command
v6.1.0+incompatible Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jan 28, 2019 License: BSD-3-Clause Imports: 11 Imported by: 0

README

relayd 方案实现

实现

  • 作为一个独立的进程,运行信息可以配置,守护进程(supervisor),跨平台,高性能。
  • 连接多个比特币节点数,进行数据筛选,防止节点的攻击。
  • relayd 连接chain33通过GRPC实现,连接btcd可以通过websockets,或者HTTPS,两者都要实现。
  • 本地监听通过GRPC或者HTTP来实现,监听外部消息。
  • 定时获取btc链的同步信息,以及定时获取chain33的订单信息,以及触发超时信息工作。
  • 心跳检查,连接chain33与btc两个TCP连接。

关注那些信息

  • 各个区块头部,可以到blockinfo.org网站获取。
  • SPV验证需要的信息。
  • 指定交易的相关信息。

SPV

  1. 从网络上获取并保存最长链的所有block header至本地;
  2. 计算该交易的hash值tx_hash;
  3. 定位到包含该tx_hash所在的区块,验证block header是否包含在已知的最长链中;
  4. 从区块中获取构建merkle tree所需的hash值;
  5. 根据这些hash值计算merkle_root_hash;
  6. 若计算结果与block header中的merkle_root_hash相等,则交易真实存在。
  7. 根据该block header所处的位置,确定该交易已经得到多少个确认。

验证交易

  • 根据指定的交易hash,获取指定的信息
  • 根据hash是否能找到交易。
  • 交易双方的address(地址),必须保证被转账人的地址正确。
  • 金额是否正确。
  • 交易上链确认时间timestamp(时间戳),必须在 10m + hash.time <= hash.time <= hash.time + 2h 范围内。
  • 确认交易是否被上链。即SPV的验证。

relay executor合约执行交易

  • 确认交易,需要外界的触发
  • relay合约执行交易需要被外界出发,意味着订单的状态:pending、locking、confirming、canceled、timeout、finished等状态。
  • 订单状态:
    • pending: 挂单人发起挂单。
    • locking: 接单人接收单,锁住该订单,不允许被其他占用。
    • confirming: 接单人已经转账,正在确认转成是否成功的订单状态。
    • finished: 订单完成,交易已经得到确认。
    • canceled: 挂担人取消订单,只能处于timeout、pending状态的单子才能被取消。
    • timeout: pending状态的单一直无人接受,时间超时;lock状态的单一直没有人去撮合,时间超时; conforming状态的单,一直无法确定转账成功。
  • unlock:准确说是一个动作,去解锁正在locking的订单,不能把它划分到订单的状态中,解锁完成立,订单马进入到pending状态。
  • 状态装换图:


                      +--------------|---------------|
                    pending ---+ locking ---+ confirming ---+ finished
                    |                |               |
                    |                |               |
                    |----------------|---------------|------+ cancel
                    |                |               |
                    |                +               |
                     -----------+ timeout +----------


分析:
初始状态有一种:pending
中间状态有两种:locking、confirming
最终状态有三种:finished、cancel、timeout.

挂单方有unlock和撤单两种操作,unlock是在其他状态基础上取消到pending,撤单是撤销到canceled状态
接单方只有unlock操作, 是在其他状态基础上取消到pending

locking状态unlock需要等待12个小时或者12*6个BTC block  因为BTC交易等待的时间很长
confirming 状态,撤销需要等待4*12小时或者4*12*6个BTC block

finish状态要等待BTC n个块之后,n缺省为6,可以由买BTC的一方设定

注意:为了安全考虑,目前只允许特殊的账户发送BTC Header信息,目前是testNet的genesis addr,正式使用时候要修改

结论:
状态的转换需要外部事件的触发。

预言机(触发机)

  • 发送交易,触发链执行交易,执行合约。
  • 订单的状态相互之间转换,这种状态转换需要等待外界的触发程序去触发链去执行,怎么实现触发程序?,是否需要relayd去充当?

答疑

  • 会有人问,随便发送个hash,怎么确定交易? 答:不正确的hash,relayd得不到正确的查询,返回错误,取消chain33订单的unlock状态。
  • 如果转账不正确,怎确认? 答:根据relayd获取的金额进行确认,查看是否正确。
  • 双花问题:即在chain33这条链上怎么确认?同样是交易,chain33会检查,另外executor(relay)执行时,会检查hash是否被记录过,即:hash锁定。即只有转账人才能确定,锁定转账人。
  • 双花问题:认证交易是否属于这个转账人,在不知道用户私钥的情况下。仅仅就是一个交易hash怎么判断?两次交易,怎么挂钩?挂钩任意一个吗?
  • 双花问题:hash代表的价值是否被双向挂钩无法确定,即,解决双花问题,chain33的的订单关联的锁定btc的地址,需要被锁定,意味着,btc地址占时锁定在chain33的订单上。 锁定时间从订单的开始到结束。

Documentation

The Go Gopher

There is no documentation for this package.

Directories

Path Synopsis

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL