1703865463
我们再举一个比特币脚本应用的例子。假设爱丽丝是鲍勃的客户,需要持续向鲍勃支付小额费用,例如,鲍勃是爱丽丝的手机流量提供商,根据爱丽丝每分钟使用的流量计费。但是,每分钟支付一次是不现实的:即使技术上做得到,交易手续费也让人吃不消。
1703865464
1703865465
我们希望可以把每分钟的费用累积起来,最后一次性支付。为了实现这种想法,爱丽丝先发起一个MULTISIG交易,把可能花费的最大金额转到MULTISIG地址,但这个交易需要爱丽丝与鲍勃两个人的签名才能生效。爱丽丝在使用流量的时候,每隔一分钟就签名一次,向鲍勃支付这分钟所产生的流量费用,然后把剩余的钱转给自己,每分钟重复一次,直到挂机为止。请注意,这些交易只有爱丽丝的签名,还没有鲍勃的签名,因此,交易还没被放进区块链里。爱丽丝挂机之后,会告诉鲍勃“我用好了,你可以切断我的服务了”,此时,爱丽丝将不再支付费用,鲍勃也将切断服务,然后在爱丽丝发送的最后一个交易里签名,把它放入区块链里。
1703865466
1703865467
随着每个交易付给鲍勃的币越来越多,爱丽丝的币就会越来越少。最后一个交易会一次性向鲍勃支付所有的流量费,然后把剩余的币还给爱丽丝。整个过程中,爱丽丝单独签名的交易不会进入区块链(上面没有鲍勃的签名),最后它们都会被丢弃掉。
1703865468
1703865469
从技术上讲,所有这些交易都是双重支付。在介绍绿色地址时,我们特别提到防止双重支付的重要性,但在本例中,我们却主动创造了大量的双重支付。实际上,如果双方都是正常运作的话,鲍勃只会在最后一个交易上签名,所以我们在区块链上看不到中间产生的那些双重支付交易。
1703865470
1703865471
还有一个微妙的细节:如果鲍勃没有在最后一个交易上签名呢?他可能会说,“就让那些币待在第三方托管地址里吧。”这样一来,爱丽丝就会失去她一开始转到MULTISIG地址的所有比特币。但我们有一个聪明的办法来解决这个问题,那就是我们前面看到的一个代码——锁定时间。
1703865472
1703865473
锁定时间
1703865474
1703865475
为了避免上面说的这个问题,在小额支付协议开始之前,爱丽丝与鲍勃要签订一个交易,约定向爱丽丝退还所有的比特币,但是这个“退款”行为被上了锁,直到锁定时间到了为止。爱丽丝发起MULTISIG交易把比特币转入第三方托管之后,在向网络宣布这笔交易之前,她会从鲍勃那里要求这个退款交易。这样,如果过了t时间鲍勃还没有在最后一个交易上签名的话,她可以通过这个退款交易收回所有的比特币。
1703865476
1703865477
退款交易被锁定t时间是什么意思呢?还记得我们在第3章3.2节提到元数据的时候,有一个参数是“lock_time”,当时我们还没有解释。在此参数后面填上非零数值t, 这个值告诉矿工在记账的时候,要等待t时间之后才能把这笔交易记入区块链。这个交易在放入区块后,经过确定的区块数或者时间才生效。通过这个方式,人们可以发起一笔未来交易,当然,只有资金在未来时间点之前未被花费掉,这笔未来交易才会被执行。这在小额支付的例子里非常有效,它是爱丽丝的定心丸,能够确保在鲍勃最后没有签字的情况下她能拿回自己的比特币。
1703865478
1703865479
通过上面的例子,我们展示了比特币脚本可以轻易实现很多功能。我们虽然只讨论了三个例子,但其实人们研究过许多其他的功能。比如多人彩票系统,这个系统涉及一些十分复杂的多步操作协议,以及不同的锁定时间和第三方托管账户,来防止玩家作弊。还可以通过脚本语言实现多人混币,使得比特币更难被追踪。我们会在第6章展开讨论。
1703865480
1703865481
智能合约
1703865482
1703865483
所谓智能合约(smart contracts),就是那些不同于需要通过法律或者仲裁机构来保护执行的普通合约,智能合约是比特币系统里可以用技术手段来强制执行的合约,我们已经看到,比特币有非常好的特性让我们可以用脚本、矿工和交易验证——而不是通过中心化权威机构——来实现第三方托管协议或是小额支付。
1703865484
1703865485
智能合约的研究目前已经非常深入,能够实现非常多很复杂的功能,但比特币脚本语言的设计也有很多缺陷,还是有很多现实需要的智能合约无法用比特币的工作控制语言来实现[1]。不过这里我们就不一一细谈了。
1703865486
1703865487
[1]但已经有很多有意义的探索,比如以太坊等实现了图灵完备的智能合约。——译者注
1703865488
1703865489
1703865490
1703865491
1703865493
区块链技术驱动金融:数字货币与智能合约技术 3.4 比特币的区块
1703865494
1703865495
现在,我们已经了解了单个交易是如何创建的,但是在第2章里提到,所有交易都是被打包放入区块的,为什么要这么做呢?其实这是为了性能优化,如果每一个交易都要矿工单独去达成共识,那整个系统的交易处理速度将会变得非常慢。而如果我们把大量交易组织起来放入一个区块,得到的哈希链就更短,大大提高了验证区块链数据结构的效率。
1703865496
1703865497
区块链(块链)非常聪明地把两个基于哈希值的数据结构结合起来:第一个数据结构是区块的哈希链,每一个区块都有一个区块头部,里面有一个哈希指针指向上一个区块。第二个数据结构是一个树状数据结构,也就是以树状结构把区块内所有交易的哈希值进行排列存储。也叫梅克尔树(请参考第1章),它以一种非常高效的形式把所有交易组织起来。为了证明某个交易在某个区块内,可以通过树内路径来进行搜索,而树的长度就是区块内所包含的交易数目的对数(见图3.7)。
1703865498
1703865499
我们在第2章中提到过(在第5章还将继续涉及),区块头部还包含了挖矿谜题[1]相关的信息。还记得,区块头部的哈希函数必须以一大堆零开头才有效,此外,区块头部还要包含一个矿工可以修改的“临时随机数”、一个时间戳和一个点数(点数用来表示找到这个区块的难度)。区块头部是挖矿过程中唯一哈希值化的,所以要验证一个区块的链,只要检查区块头部即可。在区块头部唯一的交易数据是交易树的树根——“mrkl_root”。
1703865500
1703865501
1703865502
1703865503
1703865504
图3.7 比特币的区块链有两个哈希结构
1703865505
1703865506
注:一个就是把区块联结在一起的哈希链,另一个就是区块内部的交易哈希值梅克尔树。
1703865507
1703865508
每个区块的梅克尔树上都有一个有意思的交易,叫作币基交易(见图3.8)。这就类似于财奴币里的造币交易。这个交易创造新的比特币,它看上去像是一个普通的交易,但有几点不同:
1703865509
1703865510
1703865511
1703865512
[
上一页 ]
[ :1.703865463e+09 ]
[
下一页 ]