深入浅出 Flexible Transactions （弹性交易）

fih39505qcn

深入浅出 Flexible Transactions （弹性交易）

今天Flexible Transactions被提交为一个BIP0134，看到了进一步的细节，就可以更好理解这个提议的内涵了，这里给国内币圈的朋友介绍一下

Flexible这个词的翻译不容易，字面上来说Flexible可翻成灵活，但通常国外在工程中使用这个词是指系统可伸可屈限制较少的一种特性，灵活显得不是很专业

网上查到，flexible working hours 是个企业里常见的词组，中文翻译为弹性工时，我觉得较为准确的把握了其本质且较为专业。所以建议可把Tom Zander 的这个技术提案翻译为“弹性交易”



弹性交易是怎么回事呢？还是用账簿的例子较好理解

先重温一下现有的比特币交易（汇款单）的格式（我仍然是做了适当简化，把一些不重要的字段忽略了）：




整个汇款单是由输入和输出两大部分组成，这里在汇款单头上有个绿色的01 00 00 00，是交易版本号，比特币目前为止这个号都是1，以倒序十六进制形式写就是01 00 00 00，说明比特币的汇款单格式版本一直没有改过

这里付款方一侧最下面一栏有串数据ffffffff，是一个之前定义不是很严格的数据，现在被用来实现CSV的功能（覆盖已经发出却未确认的交易），而在收款方一侧最下面也有一串数据00000000，是用来指定币被锁定的时间，也即在多少时间后才可以花

（这里顺便提一句，之前比特币软分叉都修改了交易提供了不同或更多的功能，却没有修改版本号，就是靠修改ffffffff这类未明确定义的字段来提供新功能。但这显然不是个长远之计，因为这种未明确定义的字段是用一个少一个的）



在弹性交易的格式下，汇款单就变成了这样：





因为前一笔交易的哈希值和前一笔交易的TXID基本是一回事，所以看起来弹性交易和现有的交易格式区别不大，仅仅在于：

1. 把交易版本号改成了04 00 00 00
2. 把包含付款公钥和签名的脚本移出来放到交易最后面（签名只签该脚本之前的上半部分，解决交易延展性问题，也就是隔离见证的原理）
3. 去掉了原来的两栏ffffffff和00000000
4. 交易最尾端增加了一个中止符2C 00 00 00


可以看到，这整个的格式看起来比现有的比特币交易格式更简单了，怎么可能实现未来更多的功能，所谓有弹性的交易？


差别在背后的实现里。弹性交易的每一栏，都包含着自我注释性的定义，不像比特币现在的交易里，完全只是数据，定义完全靠节点运行的软件来诠释

拿金额一栏为例：比如说转账5个聪，目前比特币交易里金额一栏就是直接写0500 0000 0000 0000（八个字节，十六进制）。而在弹性交易的方案里，则要写三个数：第一个是名称（4），第二个是格式（0），第三个才是具体的金额（5）。转换成二进制，就是写成100 000 101，其中前两位合并成一个2位十六进制数20，金额则写为十六进制的05，结果就是2005。可以看到2005只有2个字节，比起比特币目前的8个字节，节省了3/4的空间

这就是弹性的一个意义所在：通过对每个字段的自我诠释，就彻底避免了为某些字段专门保留固定长度的冗余空间，从而提高了代码的有效性。减少的代码显然可以降低交易的尺寸。当然了，金额是最简单的一栏，会有明显效果，对于其他的脚本栏和签名栏，这种编码方式相信不会提供太大的压缩效果，最终按TOM的实验证明，一个弹性交易的数据大小要比现有的比特币交易少大约3%，所以尺寸上只有微小的优势

弹性交易更大的价值在于其交易中每一栏自我诠释的方式。这使得开发者可以在未来的比特币交易中自己添加更多的新栏而不会引起旧节点拒绝接受的情况（运行弹性交易的节点可能并不知道新字段的意义，但并不拒绝接受新的字段，也就是处理交易是有弹性的，其实这就是软分叉的思路）。我还是认为软分叉只适合于应用在较小的功能性的改进上，对于改变系统共识的大的改动不应该用软分叉

一句话总结，弹性交易通过对比特币交易格式的重新构建，使得未来可近乎无限制地以软分叉的方式实现几乎任何功能。不过这不仅需要一个硬分叉实现，也是个对比特币交易底层所进行的大幅度改动，逻辑的改动量也不小，需要很多的测试。但TOM已经有可运行的代码，可见硬分叉就是比较容易实现新功能。同时也可看到，TOM是具有相当高的比特币底层开发能力的人才

有兴趣的可去GITHUB看看
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki
https://github.com/bitcoinclassi ... actmessageformat.md