软件开发与架构领域 -体系化知识分享

理清软件领域各种似是而非的概念,深刻理解本质

第13课 微支付通道(MicroPayment Channel) -- 迄今为止最透彻的讲解了

有兴趣朋友也可以进一步关注公众号“架构之道与术”, 获取原文。
或扫描如下二维码:
这里写图片描述

这1课很关键,微支付通道将是后面闪电网络、隔离见证的基础,微支付通道不能搞透彻,后面的闪电网络、隔离见证就更晕菜了。

问题的提出
在前面第3课 “区块链”到底长什么样?我们说过,现在的比特币网络每秒钟最多处理6到7笔交易,并且每笔交易还需要手续费。

如果买卖双方有大量的小额交易,微额交易,比如1个宽带提供商向外提供带宽服务,按小时付费。那大量的小额交易,不仅会让比特币网络负担沉重,而且手续费也不划算。

所以有人就提出了,在买卖双方,建立1个支付通道,专门支持双方的小额支付,不需要经过比特币网络。这个通道除了建立、关闭的时候,要和比特币网络通信,其他时间,都是双方点到点的通信。

问题的难点
我们知道,比特币网络至所以是可靠的、值得信任的,1个很重要的原因是因为每笔交易都是公开的,每1笔交易都是on-chain,都会得到网络上每个节点的认可,所以交易的任何1方没办法反悔、抵赖。

现在你要搞链下交易,off-chain Transaction,交易只有你们俩自己知道,没有了区块链网络这个信任的第3方,怎么保证交易的1方不会反悔、抵赖?

这个问题很有意思,接下来我们看看,微支付通道是如何解决这个问题的。

nLockTime
在第12课 nLockTime(CLTV)与Sequence number(CSV),介绍了Transaction数据结构里面的1个关键属性。微支付通道的建立,必须依赖这个属性。下面就看一下这个过程是怎么建立的。

微支付通道建立过程
考虑如下场景:A是用户,B是一个数据提供商,B需要把1个100G的大数据文件发给A,价值是100元。

为了降低风险,A不想1次性把100元给B,而是每接收到1G的数据,给B支付1元。

那就需要100次的交易。现在看一下,微支付通道如何解决这个问题:

Step1:
用户A发起1笔交易,把100元打到1个公共账号上面(这个公共账号同时需要A,B的公钥,也就是前面所说的多重签名)。这笔钱,需要A,B2个人同时出具私钥,才能把钱取出来。这笔交易叫做保证金交易(Funding Transaction)。

Step2:
以此同时,用户A发起1笔退款交易(Refund Transaction)。这笔退款交易的输入,就是Step1里面的交易,其目的是把Step1里面的100元,再返回给用户A。这笔交易的nLockTime为一个>0的值,也就是该笔交易是Hold在那的,不会立即生效。
具体怎么做呢? 用户A先把这笔交易发给B,让B用B的死钥签名(也就是写在scriptSig里面),再返回给A,A把这个Refund Transaction 攒在手上,这笔交易其实是A的一个保底的措施,保证前面的100元不会永远拿不回来。

Step3:
我们知道,在Step2的Refund Transaction里面,有2个输出:A,100元;B,0元。
现在把Step2的Refund Transaction拷贝1份,调整一下输出:A, 99元;B, 1元。也就是付给B1元。
然后A把这个交易发给B,B保留这个交易,不广播到网络上。

等A收到B的新的1G文件之后,重新调整输出,变成: A,98;B,2元。A,B重新签名,A再把这个交易发给B。

如此,不断继续下去:
A: 98,B,2;
A:97,B,3;
。。
A:1, 99。

这些交易,称为updated Transaction(或者叫做Commitment Transaction),只会在A,B之间传递,不会广播到网络上。

Step4:
等A收到最后的1个G的文件,发起1个Settlement Transaction。这里交易里面,
A:0元, B:100元。
其nLockTime = 0,B收到这个交易,广播到网络上,交易立即生效,B收到100元。

微支付通道的巧妙之处
(1)整个过程,我们会看到,只有Step1的Funding Transaction和Step4的Settlement Transaction会广播到网络上,1头1尾,2个交易。

(2)如何避免B跑路,A的钱永远锁死在公共账号里面?
在第1步里面,A把钱打到了1个公共账号上面。如果B跑了,A的钱不是永远提不出来了?实际不是这样操作的:实际是,A会等到Step2里面,拿到Refunding Transaction之后,A才会把Step1里面的Transaction发给B,同时广播到网络上面。
Refunding Transaction就相当于A攒在手里的,B的把柄。A不用把这个交易广播出去,等到B跑路了,再拿出来广播到网络上。

(3)如何避免A跑路,B拿不到自己的钱?
在Step3里面,每个update Transaction,都有A,B共同的签名。如果A跑路了,B就把最新的update Transaction广播到网络上,该交易被执行,B就会拿到最新的钱。
update Transaction,就相当于B攒在手里的,A的把柄。
update transaction有个特点,每1次update transaction的nLockTime,都是逐级减小的,所以B把最新的update transaction广播到网络上之后,肯定会被最先打包,最先执行。先前其他的update transaction就不会被执行了。

(4)如何避免B篡改交易内容,比如调大给自己的分成比例?
任何1笔交易里面,都是先让B签名,再返回给A,A再签名,再发给B。
每笔交易里面都有A,B的双重签名,B改了交易内容,和A的签名就对不上了,反过来,A改了交易内容,就和B的签名对不上了。
所以A,B都不可能更改篡改交易内容!!

(5)如何防止A双花这笔钱?
在Step2里面,A拿到了Refund Transaction,A把这个交易广播到网络上,拿回这100元,再花到别处呢?
做不到。因为Refund Transaction有nLockTime,处于锁定状态。并且这个nLockTime > 后面的任何1笔updated Transaction的值。

说到这,我们就明白了,A,B如何做到在off-chain的情况下,保证双方都没办法反悔、抵赖交易:
A手上拿的有B的把柄,B手上拿的有A的把柄。任何1方中途中断,另我1方,把这个把柄广播到区块链网络,就可以执行合约,拿到属于自己的钱。

微支付通道的缺点
上面说的微支付通道,解决了A给B转账的,大量小额交易问题,但它也有几个缺点:
(1)它是单向的,只能用来A给B转账。如果反过来,需要另外再建立1个B到A的通道。
(2)nLockTime的限制。假设B跑路了,A也要等到Refund Transaction的nLockTime到期了,才能拿回自己的钱;同样,假设A跑路了,B也要等到updated Transaction的nLockTime到期了,拿到属于自己的钱。

这些问题都如何解决呢,这就要看接下来的“闪电网络”了。

相关链接:
《第12课 nLockTime(CLTV)与Sequence number(CSV)》
《第11课 账号被黑客盗取怎么办? – 多重签名(MultiSig)与P2SH》
《第10课 交易安全性如何保证? – scriptSig/scriptPubKey/Script Engine》

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

第13课 微支付通道(MicroPayment Channel) -- 迄今为止最透彻的讲解了

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭