这是《从比特币到以太坊：比特币区块链》后续，如果你还没读过，请先读这篇文章。理解以太坊所需要的背景都这这篇文章中了。
还记你得刚学编程时，第一次使用“对象”的感觉吗？还记你第一次尝试函数式编程的样子吗？这些编程范式，你还记得用了多久才把它们从懵懂的概念进化为直觉的？其实，学习面象区块链编程很像面向对象与函数式编程：刚开始很绕，渐渐的就明白了。我们在这个系列的上半篇，通过比特币的区块链，了解了区块链大致是如何运行的。这下半篇，我们就来探索一下以太坊的区块链，进而学习面向区块链编程。从长远上讲，学会如何结构化区块链内的互交，并把它培养成直觉，对学习者是有极大裨益的。
首先，把《以太坊白皮书》的前三章看完。这三章主要讲帐户，转帐和消息。要是有兴趣也可以把剩下的读完，但其实只要把这系列的上半部份读完，你就已经理解了底层技术的基础了。和读《比特币白皮书》一样，第一遍读要是有什么不懂的，不要着急，慢慢的就明白了。
从现在起，从合同的角度思考问题！
智能合同其实就是存储在区块链里的代码。只要再加一个用户界面，智能合同就可以作去中心化应用（dapps）的后端了。用你已有的对比特币的理解，可以把一个比特比交易想成一个具有三个输入和两个输出的程序（比特币对输入和输出的定义并不是这样的，但先不要在乎细节）。输入指的是要交易的比特币总和，转账人的地址和收款人的地址。输出就是转账后，余额更新后的这两个账户。被矿工挖出来的交易记录是公开的，里面记着一个有某些输入的程序曾经运行过并产生了某些输出。在比特币里，这种转账程序就是唯一存在的程序，每个节点因此都能根据输入正确的验证输出。
以太坊把程序的限度，从简单的转账，扩展到了一切能在图灵机上编写的程序。要是你计算机课上忙着睡觉了的话，这意思就是任何能被编程的东西，也同样能在以太坊上被编程。
以太坊能有这样的复杂性是因为每个网络节点上都运行着一个虚拟机（叫以太坊虚拟机，或EVM）。EVM和其它任何的虚拟机没什么不同。举个例子，你可能已经熟悉Java Virtual Machine （JVM）。JVM代码在任何装有它的机器里，同样的输入会产生同样的输出。相似地，EVM也能让以太坊区块链代码，在同样在输入下产生公认正确的输出。
比特币区块链的完整节点里存有从零区块到现在的所有记录；以太坊的完整节点里，还多了静态代码（若是存在），与之相关的账户信息，和代码此时的状态。
想象存储在账户内的一个简单程序，它只接受数字输入，然后把这输入的数字加到一个累计的数字上，再用新的总和来代替旧的。有两个账户和这个合同账户进行了交易，一个输入了5，另一个输入了2。现在在区块链里的信息有：
-
合同账户和它的静态代码。
-
这个合同账户的目前存储状态，即总和为7。
-
一个这个账户过去的账户存储状态，即总和为5。
-
一个这个账户过去的账户存储状态，即总和为0。
-
三个转账记录：一个是代码最开始的存储，一个是某账户输入的5，另一个是某账户输入的2。
想象一个类似的程序，（必然地）储存在另一个账户里。这个程序除了有上面的功能，还存有一个线性的数组，里面存储着有两个字段的结构（结构指的是结构化的排列数据的模板），每个结构里存有寄帐人的地址，和寄帐人输入的数字。有两个账户和这个合同地址进行了交易，一个输入了5，一个输入了2。现在区块链里的信息有：
-
合同账户和它的静态代码。
-
这个账户的目前存储状态，即总和为7，和一个含有两个结构的数组。
-
一个这个账户过去的存储状态，即总和为5，和一个含有一个结构的数组。
-
一个这个账户过去的存储状态，即总和为0，和一个空的数组。
-
三个转账记录，一个是代码最开始的存储，一个是某账户输入的5，另一个是某账户输入的2。
现在我们可以轻松地重新构建这个账户之前的状态，并查看都有哪些账户和它有过交易，从而创建了现在的状态。可这种模式应该尽量避免。为什么呢？用上面的例子来说，所有存储在数组里的数据都可以方便的用区块链本身构建出来。读到这里，心眼儿不老实的读者可能已经想到了多种轰炸区块链的方法了。下面我们来学习一下以太坊是如何预防节点的硬盘和CPU被僵尸攻击（DoS）的，以及这些预防措施对开发者和用户意味着什么。从某些角度讲，对开发者来说这意味着要写入数据时要小心谨慎。
油费（gas price）
怎么防止有人上传10TB的静态代码合同，把所有网络节点的存储空间都耗尽呢？或者让CPU无休止的做无用功？和比特币一样，在以太坊上交易是有手续费的，以来激励矿工来处理交易和保护网络，不同的是以太坊是以“油费”的形式来收费的。就像汽车跑单位距离需要特定加仑的汽油，以太坊上的交易每运行单位CPU周期或储存单位数据也要花费特定的以太。因为以太本身是珍贵稀有的，所以就预防了僵尸攻击。区块链上的亿万富翁，想要烧钱搞恶作剧是可以让网络变慢一会儿的，但挖出这些恶意交易的矿工们也会赚上一笔的。
这对开发者和用户意味着什么呢？虽然读取本地区块链是免费的，但写入和运算是花钱的。储存更是尤其昂贵，因为任何写入的信息都会被永久的储存着。相比之下，CPU运算很便宜。正是因为任何程序所有的历史状态都被记录着，改变一个账户的存储状态，在一般程序里被认为是对已分配内存的操作，在区块链中却算作写入操作。以太坊是图灵完备的，谁也拦不住你写一个视频解码器然后发布在区块链上；只不过估计你没钱运行它。假设这样的程序的代码至少有几千行，即使把它上传到区块链上也不会便宜。一个帮助人们理解以太坊合同实际能力的启发是：这个功能是否能在一个1999年的智能手机上实现？
作为开发者，这意味着你得认真思考代码的效率。虽然存储效率尤其重要，但是CPU的每个周期也是要花用户的钱的。两个同样功能的合同，最有效率的那个才能生存下来。
知道了理论上的无限可能和现实中的各种限制：那么是什么让以太坊如此的炫酷？
现实中的例子
在同我们一起充满激情的讨论智能合同的无限可能，包括无基础设施的政府，和其它改变世界的想法前，作为开胃菜，我们来一起学习一个生活中简单的智能合同的例子。
假设我的乐队刚刚录制完一个全新的专辑，然后我们打算分享给我们的粉丝。可我们是朋克青年（译者注：朋克思想即反对体制，提倡个体自由），不管是iTunes还是YouTube，都是体制内的。所以我们打算把专辑印制100份限量版黑胶唱片，然后记录并只邀请购买者去我们认为最棒的酒吧观看独家表演。一般来讲我们会用类似PayPal之类的服务来收款，它再在每个交易里收取一些费用。我们收到钱后就发货，然后再在表格软件上记录这个交易，这样等到第101人要买的时候我们就不会忘了拒绝。这个计划听起来就不够稳妥，所以难怪艺人和粉丝宁可付中介费也要用类似Ticketmaster和Bandcamp的中介公司。幸运的是，乐队鼓手有编写以太坊智能合同的经验，我们就决定编写一个“购买记录表”来完成我们的计划。
这个记录表合同很简单，只有三个函数：purchase，provePurchase，和claimAlbum。粉丝在网页上通过purchase函数往合同账户里转入指定数额的以太。只要转入的钱大于等于售价，合同中的计数器就会累加。寄款人的以太坊地址和领认次数组成一个结构，保存在一个数组里。要是转账后计数器超过100，交易就会失败（并退款）。
购买成功后，粉丝会发给我们收唱片的地址。但在寄出前，claimAlbum函数会在数组里的各个结构中查找付款人的地址并将领认次数加1。只有领认次数为1的时候我们的网页才会接受这个收货地址，之后再发货。为了保证我们只接受完成付款的人们的收货地址，而且只发一份唱片，我们要求提交地址时用户与claimAlbum的转账（译者注：与区块链函数的互动都称为转账）必须使用与purchase函数的转账同样的以太账户。
那怎么防止表演当天没买专辑的人混进来呢？这时候就要用到provePurchase函数了。 只需在门口放个iPad，人们就可以用购买专辑的账户和provePurchase验证之前的交易了。如果这些账户存在于合同的数组里，就知道他们确实购买了专辑，provePurchase也就会返回True。看门的就会放行。
不仅如此，粉丝也能在购买前，验证我们的专辑是否真的是独家的。以太坊上的合同的地址是内容决定的，也就是说源码进了区块链后是可以被它的哈希散列找到的。合同源码若是开源的话，人们就可以独立的用源码的散列来验证区块上的合同的功能性。
这里描述的例子只是一个非常简化的实现，但你应该可以从中看到智能合同是如何免除中介的。Ujo Music，比方说，用更加稳固和易用的方式，实现了流媒体和转售的微支付，并让艺人有更多的掌控权。不仅如此，艺人可以保留100%的收入的。一般人们付苹果公司30%的利润得到的安全性，区块链也可以给你，而且几乎免费。
欢迎来到区块链的世界
现在我们有能力写任意复杂度的代码，把它存在区块链上，再通过它的哈希值去找它，并知道调用里面的函数后，这代码会在所有的节点上运行。代码输出的结果可以通过验证其过往的状态来达到所有节点的共识。这些复杂的函数交易就象比特币的转账一样被矿工挖出。我们上传到区块链的代码叫合同，也就是去中心化应用（dapps）的后台。“智能合同”这个比喻其实很好的解释了以太坊动作的方式，包括优势（合同无法破坏，任何的输入都会产生可预测的输出，并且记录无法修改）和劣势（比请律师便宜，但是不完全免费）。
大家一起共建和谐未来吧！
原文：https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106
作者：Mike Goldin