The Truth about Smart Contracts



  • by Jimmy Song

    Bitcoin Educator, Developer and Entrepreneur/PGP

    https://medium.com/@jimmysong/the-truth-about-smart-contracts-ae825271811f

    The Truth about Smart Contracts

    Much like the words “blockchain”, “AI” and “cloud”, “smart contract” is one of those phrases that get a lot of hype.

    After all, what can be better than being able to trust what will happen instead of using the judicial system? The promises of smart contracts include:

    • Enforcing contracts automatically, trustlessly and impartially

    • Taking out the middle men in contract construction, contract execution and contract enforcement

    • (By implication) Removing lawyers

    I sympathize with the hype. After all, how much more efficient could things be if we could just remove the need for trusting the other party to execute?

    What the heck is a smart contract, anyway? And isn’t that the domain of Ethereum? Isn’t this the way of the future? Why would you stand in the way of progress?

    In this article, I’m going to examine what smart contracts are and the engineering reality that goes with it (spoiler: it’s not so simple and very hard to secure).

    What is a Smart Contract?

    A normal contract is an agreement between two or more parties that binds them to something in the future. Alice may pay Bob some money in return for use of Bob’s house (aka rent). Charlie may agree to repair any damage to Denise’s car in the future in return for a monthly payment (aka car insurance).

    What’s different about a “smart” contract is that the conditions are both evaluated and executed by computer code making it trustless. So if Alice agrees to pay Bob $500 for a couch for delivery 3 months from now (aka couch future), some code can determine whether the conditions are true (has Alice paid Bob? has it been 3 months yet?) and do the execution (deliver the couch from escrow) without giving either party the ability to back out.

    The key feature of a smart contract is that it has trustless execution. That is, you don’t need to rely on a third party to execute various conditions. Instead of relying on the other party to make good on their word or even worse, relying on lawyers and the legal system to remedy things should something go wrong, a smart contract executes what’s supposed to happen timely and objectively.

    Smart Contracts are Pretty Dumb

    The use of the word “smart” implies that these contracts have some innate intelligence. They don’t. The smart part of the contract is in not needing the other party’s cooperation to execute the agreement. Instead of having to kick out the renters that aren’t paying, a “smart” contract would lock the non-paying renters out of their apartment. The execution of the agreed-to consequences are what make smart contracts powerful, not in the contracts innate intelligence.

    A truly intelligent contract would take into account all the extenuating circumstances, look at the spirit of the contract and make rulings that are fair even in the most murky of circumstances. In other words, a truly smart contract would act like a really good judge. Instead, a “smart contract” in this context is not intelligent at all. It’s actually very rules based and follows the rules down to a T and can’t take any secondary considerations or the “spirit” of the law into account.

    In other words, making a contract trustless means that we really can’t have any room for ambiguity, which brings up the next problem.

    Smart Contracts are Really Hard

    Because of a lot of centralized marketing from Ethereum, there’s a mistaken belief that Smart Contracts only exist in Ethereum. This is not true. Bitcoin has had, from the very beginning in 2009, a pretty extensive smart contract language called Script. In fact, smart contracts existed before Bitcoin as far back as 1995. The difference between Bitcoin’s smart contract language and Ethereum’s is that Ethereum’s is Turing-complete . That is, Solidity (ETH’s smart contract language) allows for more complicated contracts at the expense of making them more difficult to analyze.

    image

    To be clear, smart contracts existed even before Bitcoin, I just like the cartoon

    There are some significant consequences of complexity. While complex contracts can allow for more complicated situations, a complex contract is also very difficult to secure. Even in normal contracts, the more complicated the contract it is, the harder it gets to enforce as complications add more uncertainty and room for interpretation. With smart contracts, security means handling every possible way in which a contract could get executed and making sure that the contract does what the authors intend.

    image

    Image result for smart contract cartoon

    Execution in a Turing-complete context is extremely tricky and hard to analyze. Securing a Turing-complete smart contract becomes the equivalent of proving that a computer program does not have bugs. We know this is very difficult, as nearly every computer program in existence has bugs.

    Consider that writing normal contracts takes years of study and a very hard bar exam to be able to write competently. Smart contracts require at least that level of competence and yet currently, many are written by newbies that don’t understand how secure it needs to be. This is very clear from the various contracts that have been shown to be flawed.

    Bitcoin’s solution to this problem is to simply not have Turing-completeness. This makes the contracts easier to analyze as the possible states of the program are easier to enumerate and examine.

    Ethereum’s solution is to place the burden on the smart-contract writers. It is up to the contract writers to make sure that the contract does what they intend.

    Smart Contracts Aren’t Really Contracts (at least on ETH)

    While leaving the responsibility of securing contracts to the writers sounds good in theory, in practice, this has had some serious centralizing consequences.

    Ethereum launched with the idea that “code is law”. That is, a contract on Ethereum is the ultimate authority and nobody could overrule the contract. The idea was to make clear to smart contract developers that they’re on their own. If you screwed up in making your own smart contract, then in a sense, you deserve it. This came to a crashing halt when the DAO event happened.

    DAO stands for “Decentralized Autonomous Organization” and a fund was created in Ethereum as a way to show what the platform could do. Users could deposit money to the DAO and get returns based on the investments that the DAO made. The decisions themselves would be crowd-sourced and decentralized. The DAO raised $150M in ETH when ETH was trading at around $20. This all sounded good in theory, but there was a problem. The code wasn’t secured very well and resulted in someone figuring out a way to drain the DAO out of money.

    Many called the person draining the DAO of money a “hacker”. In the sense that the “hacker” found a way to take money from the contract in a way not intended by the creators, this is true. But in a broader sense, this was not a hacker at all, just someone that was taking advantage of the quirks in the smart contract to their advantage. This isn’t very different than a creative CPA figuring out a tax loophole to save their clients money.

    What happened next is that Ethereum decided that code no longer is law and reverted all the money that went into the DAO. In other words, the contract writers and investors did something stupid and the Ethereum developers decided to bail them out.

    image

    The fallout of this incident is well documented. Ethereum Classic was born, preserving the DAO as written and conserving the “code is law” principle. In addition, developers began shying away from using the Turing-completeness property of Ethereum as it’s proven to be hard to secure. ERC20 and ERC721 standards are the most frequently used smart contract templates in Ethereum and it’s important to point out that both types of contracts can be written without any Turing-completeness.

    Smart Contracts Only Work with Digital Bearer Instruments

    Even without Turing-completeness, smart contracts sound really good. After all, who likes having to go to court to get something that rightfully belongs to them trustlessly? Isn’t using a smart contract much easier than normal contracts?

    For example, wouldn’t real estate benefit from smart contracts? Alice can prove she owns the house. Bob can send money for the house and get the house in exchange. No questions of ownership, trustless, fast execution by machine, no need for judges, bureaucrats or title insurance. Sounds amazing, right?

    There are two problems here. The first is that smart contract execution by a centralized party is not really trustless. You still have to trust the centralized party to execute. Trustlessness is the key feature, so centralized execution doesn’t really make sense. To make smart contracts really trustless, you need a platform that’s actually decentralized.

    That leads us to the second problem. In a decentralized context, smart contracts only work if there’s some definitive link between the digital version and the physical version. That is, whenever the digital version of the house changes ownership the physical version has to also change ownership. There’s a need for the digital world to “know” about the physical world. This is known as the “Oracle problem”.

    When Alice transfers the house to Bob, the smart contract needs to know that she actually transferred the house to Bob. There are several ways of doing this but they all have the same essential problem. There has to be some trust in some third party to verify the events in the physical world.

    image

    For example, the house could be represented as a non-fungible token on Ethereum. Alice could transfer the house to Bob in an atomic swap for some amount of ETH. Here’s the problem. Bob needs to trust that the token actually represents the house. There has to be some Oracle that ensures the transfer of the house token to him actually means that the house is his legally.

    Furthermore, even if a government authority says that the token actually represents the house, what then happens if the token is stolen? Does the house now belong to the thief? What if the token is lost? Is the house not available to be sold anymore? Can the house token be re-issued? If so, by whom?

    There is an intractable problem in linking a digital to a physical asset whether it be fruit, cars or houses at least in a decentralized context. Physical assets are regulated by the jurisdiction you happen to be in and this means they are in a sense trusting something in addition to the smart contract you’ve created. This means that possession in a smart contract doesn’t necessarily mean possession in the real world and suffers from the same trust problem as normal contracts. A smart contract that trusts a third party removes the killer feature of trustlessness.

    Even digital assets like ebooks, health records or movies suffer from the same problem. The “rights” to these these digital assets are ultimately decided by some other authority and an Oracle needs to be trusted.

    And in this light, Oracles are just dumbed down versions of judges. Instead of getting machine-only execution and simplified enforcement, what you actually get is the complexity of having to encode all possible outcomes with the subjectivity and risk of human judgment. In other words, by making a contract “smart”, you’ve drastically made it more complex to write while still having to trust someone.

    The only things that can work without an Oracle are digital bearer instruments. Essentially, both sides of the trade need to not just be digital, but be bearer instruments. That is, ownership of the token cannot have dependencies outside of the smart contracting platform. Only when a smart contract has digital bearer instruments can a smart contract really be trustless.

    Conclusion

    I wish smart contracts could be more useful than they actually are. Unfortunately, much of what we humans think of as contracts bring in a whole bunch of assumptions and established case law that don’t need to be explicitly stated.

    Furthermore, it turns out utilizing Turing completeness is an easy way to screw up and cause all sorts of unintended behavior. We should be labeling smart contract platforms Turing-vulnerable, not Turing-complete. The DAO incident also proved that there’s a “spirit” of the contract which is implicitly trusted and helps resolve disputes more so than we realize.

    Smart contracts are simply too easy to screw up, too difficult to secure, too hard to make trustless and have too many external dependencies to work for most things. The only real place where smart contracts actually add trustlessness is with digital bearer instruments on decentralized platforms like Bitcoin.

    Thanks to Michael Flaxman and Rigaut-Luczak Lola.



  • 中文译本:

    --

    正如“区块链”、“人工智能”和“云”一样,“智能合约”也是那些被大肆宣传的词语之一。

    毕竟,有什么能比相信将会发生的事情而不是使用司法系统更好呢?智能合约的承诺包括:

    1.自动地、诚信地、公平的执行合同
    2.在合同建立、合同执行和合同施行中,去除中间人
    3.(暗示)去除律师

    对于以上宣传我表示支持。

    毕竟,如果我们去除信任另一方将会执行的需要,那么做事情的效率究竟会提高多少呢?

    究竟什么是智能合约呢?这难道不是以太坊的范畴吗?这难道不是未来要走的道路吗?你为什么要阻挠进步呢?

    在本文中,我将阐述什么是智能合约以及与之相关的工程实践(提示:这不那么简单,很难保证)。

    什么是智能合约呢?

    一个常规的合同是双方或多方建立的未来对各方有一定约束的协议。Alice 将付给 Bob 一些钱作为使用 Bob 的房子的回报(也就是租金)。

    Charlie 同意在未来修理Denise的车的任何损坏作为 Denise 每月支付钱给 Charlie 的回报(也即汽车保险)。

    “智能”合约的不同之处在于合约的条件是通过计算机代码来进行评估和执行,使其去信任化。

    所以如果 Alice 同意支付 Bob 500美元购买沙发,沙发三个月交货(即沙发期货),一些代码可以确定条件是否正确(Alice是否已经支付给Bob?已经过去3个月了吗?)并执行合约(从第三方托管处交付沙发),而不让任何一方违约。

    智能合约的关键特性是去信任化执行,也就是说,你将不在需要依赖第三方执行各种各样的条件。

    智能合约将不再依赖对方履行诺言或者更糟的依赖律师和司法系统来解决问题,而是及时、客观的执行约定的事宜。

    智能合约是相当愚蠢的

    “智能”一词的使用意味着这些合约有一些与生俱来的智慧,但实际他们没有。

    合约的智能部分是通过不需要对方合作执行协议来体现的。智能合约不再将不按时支付房租的租客赶出房子,而是会将他们锁在门外。已经同意的因果关系的执行,使得智能合约强大,而不是合约与生俱来的智慧。

    一个真正的智能合约会考虑所有情有可原的情况,依照合约精神,即使在非常阴暗的情况下,也会做出公平的裁决

    换句话说,一个真正的智能合约将扮演真正好法官的角色。

    反而在这种环境下“智能合约”一点也不智能。这是真正的以规则为基础,遵循规则到底,并且不能考虑任何次要的原因或者法律的“精神”。

    换言之,使合约去信任化是指我们真正没有任何可能造成问题的模棱两可的地方。

    智能合约是真的很难

    因为智能合约很多来自以太坊这个中心化市场,所有这里有一个误解,以为智能合约只存在于以太坊,这是不对的。在2009年初,比特币就已经有了一个相当广泛的智能合约语言叫做脚本(Script)。

    实际上,智能合约的存在可以追溯到1995年。比特币智能合约与以太坊的不同在于以太坊是图灵完备。也就是说,Solidity(以太坊智能合约语言)允许更复杂的合约,但代价是让这些合约更难分析。

    为了将智能合约的存在甚至早于比特币表述的更清楚,我喜欢用卡通来进行描述。 这有一些复杂性的重要的结果。

    虽然复杂合约允许更复杂的情况,但是一个复杂合约也很难安全。

    即便在常规的合约中,合约越复杂,就越难执行,因为复杂的合约会增加更多的不确定性和解释的空间。而智能合约,安全就意味着合约可以按照每一个可能的方式执行,并确保符合合约作者的意图。

    在图灵完备环境中的执行是极其棘手和难以分析。确保一个图灵完备智能合约安全就像证明计算机程序没有漏洞。我们知道这非常困难,因为现今存在的所有计算机程序都有漏洞。

    考虑到写常规的合约需要多年的学习并经过严格的律师资格考试才能胜任。

    智能合约要求至少要与常规合同相当的能力,但是目前不是,很多智能合约都是新手编写的,他们不明白它需要非常安全。

    从各种有缺陷的合约中可以清楚的看到这一点。

    比特币对于这一问题的解决方法很简单,不具备图灵完备性。这使得合约更容易分析,因为程序的各种可能的状态更容易列举和检测。

    以太坊的解决方法是将这个责任赋予了给智能合约的编写者。合约的编写者要确保合约执行的是他们的意图。

    智能合约并不是真正的合约(至少在以太坊不是)

    虽然将合约安全性的责任让作者承担听起来是很不错的理论,但在实践中,这将会导致中心化的结果。

    以太坊以“代码就是法律”理念发行,即以太坊合约是最高权威,任何人都不能推翻合约。这个理念是为了让智能合约的开发者清楚他们是独立的。

    如果你搞砸了自己的智能合约,从某种意义上说,你是值得的。当DAO事件发生,这种情况就会戛然而止。(DAO:去中心化自治组织)
    DAO 全称 Decentralized Autonomous Organization(去中心化自治组织),在以太坊创立了一个基金,以展示平台可以做什么。用户可以将钱存入 DAO,根据 DAO 所做的投资获得回报。

    这些决定本身将是众筹和去中心化的。当以太坊交易价为20美元的时候,DAO 筹集到1.5亿美元。这些听起来都是不错的理论,但有一个问题。代码没有得到很好的安全保证,导致有人计算出一种方式可以把钱从 DAO 抽走。

    许多人把“抽钱的人”称为“黑客”。

    从某种意义上说,“黑客”找到了一种非创建者意愿的从合约中获取资金的方式,这是真的。

    但从更广泛的意义上来说,这根本不是一个黑客,只是一个利用了智能合同的特点转化为他们的优势。

    这和一个富有创造力的注册会计师并没有什么不同,他们想要找到一个税收漏洞来节省他们的客户的钱。

    接下来发生了什么呢?以太坊决定代码不再是法律,并将进入DAO所有的资金进行了恢复,也就是说,合约作者和投资者做了一些愚蠢的事情,开发人员决定帮他们摆脱困境。

    这一事件的附带后果被真实记录。以太坊经典诞生时,保留了DAO作为书写,保存了“代码就是法律”的原则。而且,开发者开始规避使用以太坊的图灵完备特性,因为它被证实很难保证安全。

    ERC20和ERC721标准是以太坊中使用最频繁的智能合约模板,必须指出的是两种类型的合约都可以在没有任何图灵完备性的情况下编写。

    智能合约只适用于数字承载仪器

    即使没有图灵完整性,智能合约听起来也不错。

    毕竟谁也不喜欢不得不上法庭才能合理的获得属于他们自己的东西?难道使用智能合约不比常规合同简单的多?

    例如,智能合约不会使房地产受益吗?Alice 可以证明她拥有这套房子。Bob可以支付款项来换取房子。没有所有权、去信任的问题,无需法官、官僚或者产权保险。听起来很棒,对吗?

    这里有两个问题。第一,集中进行智能合约的执行并不是真正的信任化。你仍然需要向信任集中的执行方。去信任化是关键特性,因此集中执行并没有真正的意义。为了使智能合约真正的去信任化,你需要一个真正却中心化的平台。

    这引出了我们第二个问题。在去中心化的环境中,只有在数字信息和实物存在某种明确关系时,智能合约才会有效。也就是说,每当房子的数字信息改变所有权时,实物也必须改变所有权。

    数字世界需要“了解”物理世界。这被称为“预言家问题”。

    当 Alice 将房子转交给 Bob 时,智能合约需要知道她实际确实将房子交给了 Bob。

    有好几种方法可以做到这一点,但是他们都有同样的关键问题,必须有一定信任程度的第三方来验证核实现实世界的物质。

    举个例子,房子可以被以太坊上的不可替代的代币代表。Alice 可以将房子转交给 Bod 同时获得一定数量的以太坊,这就是问题所在。Bob 需要相信这代币实际上真的代表了房子。必须有一些圣人(预言家)保证房子代币转移给他实际就意味着他合法的获得了房子。

    此外,即使政府表示代币实际就代表房子,但当代币被盗后悔发生什么呢?房子现在就属于小偷的了吗?如果代币丢失了怎么办?房子就不能再出售了吗?房子的代币可以重新签发吗?如果可以,由谁签发呢?

    将数字资产和物质资产联系起来是一个很棘手的问题,至少在去中心化的环境中国是这样,无论这物质是水果、汽车还是房子。

    物质资产是受你所在区域的司法管辖,这意味着除了你创建的智能合约外,他们在某种程度上相信这些事物。

    这意味着智能合约中的占有并不一定意味着现实世界中的占有,同样面临和常规合约一样的信任问题。需要信任第三方的智能合约就不在具备去信任化杀手的特征。

    即使是电子书、健康记录或者电影等数字资产,也面临同样的问题。这些数字资产的“权利”最终需要其他权威机构决定,预言需要被信任。

    从这角度来讲,预言家只是法官版本的降低。你实际得到的不是机器执行和简化实施,而是不得不编码带有人类主观判断风险的所有可能的结果。

    换句话说,通过是合约变得“智能”,你将合约的编写变得更加复杂,而且仍旧需要信任一些人。

    可以无预言进行的唯一事情就是数字承载设备。从本质上讲,交易双方不仅需要数字化,也需要数字承载的设备。也就是说,代币的所有权不能有在智能合约平台之外的依赖性。只有当智能合约具有数字承载设备时,智能合约才能真正的去信任化。

    结论

    我希望智能合约能比实际更有用。不幸的是,我们人类所认为的合约增加了一大堆的不需要明确阐明的假设和既定的例法。

    此外,事实证明利用图灵完备是一种极易被攻击并引起各种意外行为的方式。我们应该将智能合约平台标记为图灵脆弱而不是图灵完备。DAO事件也证明合约的“精神”是隐含信任的,并比我们认识到更有助于解决纠纷。

    智能合约太容易被攻击,太难以保护,难以去信任化,并且在处理大多数事务时有太多的外部依赖。智能合约真正实际增加去信任化的地方是类似比特币那样的带有数字承载设备的去中心化平台。


    这篇文章非常深度,希望能给大家带来一些帮助。

    作者:虫洞社区
    链接:https://juejin.im/post/5ba757586fb9a05cf039e61b
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。



  • 已通读原文。基本上,三四级水平+有道词典帮助,通读英文原文是没问题的。作者写的还挺好懂。

    作为bitcoin布道者,作者指出智能合约并不智能(至少是基于ETH的智能合约),并给出了自己的理由。主要的症结在于:并不智能(古板执行rules,没有灵活空间;功能越复杂,安全越脆弱;DAO的黑历史反应出了中心化仲裁或补救机制,并非真正的去中心)

    不可否认,作者的文章颇有价值。但bitcoin用了很久实现了比较高的去中心化,(但矿池这么集中,也称不上完全的去中心);以不够去中心来评价ETH的智能合约,以及不够trustless 站得住脚,但也有些怪怪的。

    不去评价BTC和ETH,我更关心PRESSone。
    联想到PRESSone的业务,我有如下的一些关联思考,抛砖引玉:

    1、PRESSone处理的是一切可以hash的内容,即文中所说的digital assets ,所以无需担忧物理世界与数字世界的贯通问题

    2、ETH因为把智能合约的责任交给合约作者,以此让ETH的智能合约功能更为丰富和强大,但这导致合约的可靠性大幅度降低。而在PRESSone中,PRS项目团队开发了 PRSC语言,一方面让合约的开发变得简单,也确保了合约具备一定的安全可靠。另外PRS网络将存在合约商店,并首先由PRS项目方发起和提供一些基础模板,其后才交给市场(开发者与律师)来提供更多丰富或完善的合约模板,并提供合约模板的交易和流通。通过市场机制来筛选出最可靠,最适用的模板。

    3、本文反复强调了智能合约的关键特征是trustlessness,并以此来判断某种智能合约是否为真的智能合约。从这点来说,目前除了BTC,几乎所有的项目依然还处于比较高的中心化程度,甚至某些所谓的区块链项目,除了借用了区块链通证经济的思维,本质上就是一个中心化的、古典互联网项目。

    以上。