原始文献 / 论坛帖 / Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Bitcointalk · 2010-06-17 18:46:08 UTC
Bitcoin 的特性决定了：一旦 0.1 发布，核心设计就终身冻结了。正因为这样，我想让它支持我能想到的所有交易类型。但问题是，每种东西都要专门的支持代码和数据字段，不管用不用都得带着，而且一次只覆盖一个特例。这样下去特例会爆炸。解决办法是脚本，它把问题一般化了：交易双方可以把自己的交易描述成一个谓词，由节点网络来求值。节点只需要理解交易到"判断发送方的条件是否满足"这个程度。
脚本实际上就是个谓词。它就是个求值得真或假的等式。Predicate 这个词又长又陌生，所以我叫它 script。
收款方对脚本做模板匹配。目前收款方只接受两种模板：直接付款和比特币地址。以后版本可以加更多交易类型的模板，跑那个版本及更高版本的节点就能收。新交易所有版本的节点都能验证、打包进区块，哪怕它们读不懂。
这个设计支持种类极多的可能交易类型，都是我几年前设计好的。托管交易、保证金合约、第三方仲裁、多方签名等等。如果 Bitcoin 大规模流行起来，这些都是我们将来想探索的，但都得在一开始就设计好，确保以后能做。
我不认为第二个兼容实现的 Bitcoin 会是个好主意。这么多设计都依赖所有节点步调一致、算出完全相同的结果，第二个实现会是网络的祸害。MIT 协议跟其他所有协议和商业用途都兼容，所以从协议角度也没必要重写。
英文原文
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.