1. 首页
  2. 资讯
  3. 技术指南

分布式合同

原文来源:https://en.bitcoin.it/wiki/Contracts,有删改。

原文作者:Mike Heam

译者:骨髓行走

合同:

分布式合同是一种通过区块链使用比特币来让人们达成一致的方法。该合同不是什么万能的东西,但是它会允许你以一种最低信任度的方法来解决普通的问题。最低限度的信任常常让事情变得方便,它会使人们的判断在不知情的情况下就能做出,因此也实现了完全的自动化。

通过设计与比特币交互的低信任度协议,一些全新的产品将被创造出来:

智能资产:一种通过区块链可以被原子地交易和借贷的资产。

可转让虚拟资产:某种可被交易但不可被复制的电子物品。

代理:自主程序,维持他们自己的用来购买服务时间的钱包。代理通过出售服务来赚钱。如果供不应求,代理能“大量生产孩子”(译者:不是很明白),这些产物是否存活则取决于他们是否能获得足够的业务。

分布式市场:一种实现点对点债券和股票交易的方法,它使得比特币发展成国际金融体系的一个强大的竞争者。

Ripple货币交换:基于社交网络的,用以实现分布式货币交换的一种手段

本文也给出了一些更小的例子

许多比特币合同之下的点子起初是Nick Szabo在他有创意的论文《在公共网络上形成和保持关系》中描述出来的。本文是由Mike Heam撰写的。如果你有什么新的想法,请联系他。

理论部分:

每笔比特币交易都有一个或更多的输入和输出。每个输入和输出有一个小小的,纯功能性的东西与之伴随—-名曰脚本。脚本包含着在简化形式的交易里的签名。

每笔交易有一个与之伴随的加锁时间,这使得直到未来某个时间达成一致之前,该交易都处于悬而未决和能够替换的状态。如果一个交易的加锁时间到了,我们可以说这就是交易终止之时。

每笔交易的输入都有一个序列号。在一个只有价值转移的普通交易中,序列号全是UINT_MAX,加锁时间是0.如果加锁时间还没到,但所有的序列号是UINT_MAX,该交易也会被判定为终止。序列号能够用来发布新版的交易,无需使其他输入签名无效化。例如,每个在交易上的输入都来自于不同的部分,每个输入可能会以0序列号作为开始,且这些数字可以独立增加。

签名验证存在弹性,因为形成交易的签署可以受到SIGHASH标记的控制,该标记附在签名的尾部。用这种方法,合同能够这样被构造:一个部分签名仅仅就是一部分,使得其他部分的改变无需与这一部分有关。SIGHASH标记有两部分,一个模式和ANYONECANPAY修饰符:

1.SIGHASH_ALL:这是默认值。它指出了已签名的交易的一切信息,除了输入脚本。对输入脚本进行签名也是明显会让形成交易泡汤的,所以它们通常空着。只有脚本没被签名。直观来看,脚本意味着“如果人人都放钱进去且输出是这样,我也同意放进去。”

2.SIGHASH_NONE:输出没被签名,它可以是任何东西。使用这个标记用以说明“我同意放钱进去,只要人人都放进去,但是我不在乎输出是什么。”该模式允许其他人通过改变他们的输入序列号来更新交易

3.SIGHASH_SINGLE:与2中的标记一样,输入被签,但序列号是空着的,所以其他人能够创造新版本的交易。然而,被签的唯一输出与输入处于相同的位置。用这个标记来说明“我同意,只要我的输出是我想要的,我不在乎别人”

SIGHASH_ANYONECANPAY修饰符可以与上述三种模式结合。当设置时,只有那个输入被签名,其他的输入则随意是什么。

脚本包含着CHECKMULTISIG的操作码。该代码提供了一个取法(n of m)检验:你提供多个公钥,详细说明那些必须显示出来的有效签名数字。签名数字可以比公钥的个数少。一个输出需要通过如下设置花费两个签名,

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

创造安全的合同有下述两个普遍的模式:
1.交易在P2P网络之外传递,以部分完整或者无效形式存在。

2.两个交易将被用到:一个(合同)被创造和签名但是没有立刻被广播。另外,另一个交易(支付)在合同被同意加锁时得以广播,此后合同也被广播。

这保证了人们总是知道他们正在同意什么。

同时,这些功能使我们在区块链的顶部构建了有意思的全新的金融工具

举例:提供存款

设想你在一个网站上打开了一个账户,想通过操作建立信用,但是你没有之前存在的名声可以利用。一个解决方案是通过向网站支付一些钱来购买信用。但是如果在某些时点你关闭了账户,你也许想把那笔钱拿回来。你没有信任那个网站到可以把钱存到账户里的程度。另一个风险就是网站可能随时跑路。

目标是证明你做出了某种牺牲,让网站知道你不是个垃圾邮件程序(译者:即前文所说的让网站信任你),但是你不想让他们能够花费你的钱。并且如果操作系统消失了,你最后希望把钱拿回来。

我们能以一个合同来解决上面的问题

1.用户和网站彼此互送一个新产生的公钥。

2.用户建立交易TX1(支付)放入10BTC到输出并且需要用户和网站都签名,但是不广播它。他们使用上一步中的公钥。

3.用户将TX1的哈希发送给网站

4.网站产生一个交易TX2(合同)。TX2花费TX1的币并且将币返还给用户,这通过第一步中用户提供的地址实现。注意TX1需要两个签名,因此这个交易不能被完成。N加锁时间被设置,它约定了一段时间(比如令N为6,6个月)。这个输入上的序列号被设置为0

5.最后,那个未完成的交易(只有一半签名)被送回给用户。用户检查合同正如预期-那么币就会最终返还给他。但是,除非事情有所改变,这一切只在上面约定的6个月之后完成。因为序列号是0,合同如果双方都同意的话是可以修改的(参见前文的理论部分)。因此在输入中的脚本没有被完成,在用户签名的地方应该只有0.他通过对合同签名并将新签名放在合适的地方来修复这个问题。

6.用户广播TX1,在广播TX2。

至此,那10个比特币处于一种用户和网站都不能单独使用的状态。在六个月之后,合同生效用户将会得到返还的币,即使网站跑路了。

如果用户希望早点关闭他的账户又该如何呢?网站创造一个新版本的TX2,将N加锁时间设置为0,输入的序列号设置为UINT_MAX,之后重新签名。网站将持有的TX返给用户,也签了名。用户之后广播交易,早点终止合同。

如果6个月的时限将至用户想保留他的账户呢?同理:合同可以用一个新的N加锁时间重新签署,一个高于之前的序列号且重新广播2乘以32次。不管发生什么,双方必须同意才能改合同。

显然,如果用户结果是坏人(例如垃圾邮件),网站将不会允许更早的关闭合同。如果有许多这种坏人,存款的规模可以增加或者合同的长度也可以增加来防止这些坏人。

后文还有几个例子,在此不一一列举。有兴趣的可以参考英文原文。

声明:登载此文出于传递更多信息之目的,观点仅代表作者本人,绝不代表Hi区块链赞同其观点或证实其描述。
提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。

特此通告:由于运营管理等问题,本站已转让出售。