关于区块链智能合约的第一件事是它们不是合约、智能合约，也不一定在区块链上。
要了解区块链智能合约的第一件事是它们不是合约、智能合约，也不是必须在区块链上。事实上，它们的名字很奇怪。
让我们以相反的顺序解决这些问题，我们应该在此过程中确切地找出智能合约实际上是什么。首先，介绍什么是交易，什么不是交易。
交易和非交易简介
最著名的区块链是像比特币这样的加密货币。2关于货币的事情——无论是虚拟的还是非虚拟的——是你主要想做的是使用它们买卖东西。你想要的是一个简单的交易模型：“一旦我为你提供这项服务，你就会给我这个数量的货币。”我们知道这是如何运作的，因为每次我们在商店或网上购买东西时，都会发生这样的情况：起始状态是“我有x数量”，交易完成后的状态是“我有xy数量，并且你有y数量。”4这是在你完成交易之前你关心的从一种状态转移到另一种状态。大多数加密货币都被设置为支持这种类型的构造。
这很好，但一些聪明的人意识到实际上有很多不同的方法可以做到这一点。以太坊是非交易结构大获成功的地方，Solidity是最著名的例子。我很高兴地说，两者都是开源项目。为什么不在我交出我正在交出的任何东西之前需要满足一组更复杂的条件?而且——这是一个聪明的地方——为什么不写那些可以被计算机执行的代码呢?你可能希望货币——或其他任何东西——只在一段时间后释放，或者如果股票价格保持在一组特定的范围内，或者如果某个人继续担任总理，5或者如果没有意外eclipse在接下来的五天内。6你也可能有复杂的依赖关系：只有当我连续三周写一篇新文章并且没有人对其中任何一个写令人不快的评论时才完成。7编写这段代码，如果条件满足，然后进入下一个状态。
不仅适用于区块链
开始解决那些“非”陈述。
现在，在区块链中，重要的是一旦状态发生变化，您就确保将其记录在区块链上，以便它是公开的，没有人可以更改或挑战它。但是区块链技术还有其他用途，正如我在“区块链是一个安全主题吗?”中解释的那样。无许可系统，通常被称为分布式账本技术(DLT)，非常适合非交易状态模型，主要是因为对它们感兴趣的人是封闭的组织团体，他们希望以前满足复杂的条件集他们移动到下一个状态。根据最严格的定义，这些不是区块链。银行和其他金融机构可能是DLT获得吸引力的最明显例子，但它们在供应链领域非常有用，例如，您可能会遇到有关不断变化的市场利率、可用性和运输时间或成本的条件，这可能所有这些都会影响所提供的商品或服务的最终价格。
没那么聪明
智能合约可以是智能的，但对我来说，这意味着复杂并且能够对意外或不太可能的情况做出反应。我认为人们称它们为“智能”是因为它们体现在代码中，而不是出于我上面建议的原因。
我认为这实际上是一件非常好的事情，因为我认为我们不希望他们表达我的意思。我所知道的“智能合约”的大多数用法是两个或多个组织根据一组已知且受充分约束的条件就系统的一组可能结果达成一致。这就是合同的一般含义，虽然我也即将与命名法的那部分争论，但在这种情况下它是相当合适的。
通常，您想要的不是意外或不太可能的情况以及人工智能/机器学习类型的智能处理，因为如果您这样做了，那么结果可能会令人惊讶，并且可能会让一个或多个人不高兴当事人。简单——或者至少很容易定义——是你想要内置到系统中的一个关键属性。例如，Solidity项目似乎至少意识到了其中的一些陷阱，并建议使用智能合约的人采用形式验证，但正如我们将在下面看到的，这只是触及了问题的表面。
不是合同
当然，有一些合同——“在现实生活中”的合同——用于管理复杂和意外的情况。它们存在于明确的法律管辖范围内。构成它们的单词和短语受特定和明确定义的过程的约束，当合同条件不满足或违反时，会受到已知的制裁和惩罚。经常有挑战这些的情况，但同样存在应对此类挑战的明确机制。
目前，“智能合约”不符合对合约的这种描述。将法律合同措辞映射到计算机代码是一个非常复杂的过程，并且代码处理容易出现的错误类型在司法系统中没有一个很好的类比。还有管辖权的问题。这通常在合同条款中描述，但如果“智能合同”的处理发生在与相关方不同的司法管辖区，甚至是未知的司法管辖区，该怎么办?这应该重要吗?这有关系吗?我不知道，我也不知道一旦人们开始以具有法律强制力的方式依赖这些结构，我也不知道还有什么其他问题会从木制品中爬出来，但我怀疑它们会受到欢迎。
同样，当IT人员谈论软件合同时，他们谈论的是完全不同的东西：这是系统在已知输入和启动条件的上下文中所宣传的行为，这对我们也没有帮助。
这和安全有什么关系?
一旦交易——或“智能合约”——完成并进入区块链或分布式账本，它几乎是不可变的，根据定义。但是在它完成之前呢?好吧，本文开头描述的这种类型的简单交易是原子的——它们发生或不发生，用行话来说，它们是“不可分割和不可约的”。对于大多数目的，它们是瞬时的。
“智能合约”并非如此。它们需要处理，因此会随着时间的推移而存在。这意味着在处理它们时，它们会受到任何系统都可能容易受到攻击的各种攻击。标准清单是：
- 保密。“智能合约”的状态可能会受到窥探，这可能导致不对称的知识或泄露给未经批准的各方。
- 正直。这是许多“智能合约”的噩梦。如果一个实体——无论是基础合同的一方与否——可以(有意或无意地)改变执行“智能合约”的代码的内部状态，那么该“智能合约”的结果将不会像它们一样预期是这样，并且任何相关方都可能有充分的理由对结果提出异议。更重要的是，这样的纠纷甚至可能不依赖于丧失诚信的证据，而只是依赖于怀疑。在执行上下文中证明运行时完整性——更不用说在它被证明丢失时进行缓解——是极其困难的。
- 可用性。如果一方发现与“智能合约”相关的条件对他们不利，他们可能会试图影响构成“智能合约”的系统任何部分的可用性，无论是代码本身、系统的输入或系统的输出。其中任何一个都可能对现实生活的结果产生重大影响。
这篇文章的开头似乎是对命名约定的迂腐攻击。我想可能会很清楚，8我对“智能合约”这个词感到不舒服，这主要是因为我认为它让一些人认为这些结构是他们所不具备的。反过来，这可能意味着人们会在不合适的情况下使用它们。
人们还担心，因为文字会带来包袱，这会导致人们没有充分考虑安全性对这些结构的影响。我认为影响可能非常大。所以，如果你正在研究这些结构，请睁大眼睛。我在这篇文章中没有过多地谈论缓解措施，但存在一些缓解措施。
