tokenpocket下载官方app下载|以太坊白皮书

以太坊白皮书 | ethereum.org

皮书 | ethereum.org跳转至主要内容学习用法构建参与研究搜索​​​​语言 ZH帮助更新此页面本页面有新版本，但现在只有英文版。请帮助我们翻译最新版本。翻译页面没有错误！此页面未翻译，因此特意以英文显示。不再显示首页/whitepaper页面最后更新: 2023年9月25日在本页面下一代智能合约和去中心化应用平台比特币及现有概念简介历史比特币是一个状态转换系统挖矿默克尔树其它的区块链应用脚本以太坊以太坊帐户消息和交易消息以太坊状态转换函数代码执行区块链和挖矿应用代币系统金融衍生品和价值稳定的货币身份和信誉系统去中心化文件存储去中心化自治组织更多应用杂项和关注改进版 GHOST 协议的实现费用计算和图灵完备货币和发行长期供应增长率（百分比）挖矿中心化可扩展性结论注释与延伸阅读注释延伸阅读以太坊白皮书这篇介绍性论文最初由以太坊创始人 Vitalik Buterin 在 2014 年发表，前于 2015 年的项目正式发布时间。 值得一提的是，和其他社区驱动的开源软件项目一样，以太坊自发布以来一直不断发展。虽然已经过数年，但由于本文仍然可提供有用的参考并能够准确表述以太坊及其愿景，我们仍然在维护它。 若想了解以太坊的最新进展，以及以太坊协议的更新情况，我们推荐您阅读本指南。寻求此白皮书早期版本或规范版本 [自 2014 年 12 月起] 的研究人员和学者应使用此 PDF。下一代智能合约和去中心化应用平台中本聪 2009 年开发的比特币常被誉为资金和货币的一次革命性变革，作为数字资产的首个实例，它同时具有以下特点：没有实物或内在价值(opens in a new tab)支撑，也没有一个中心化的发行机构或控制者。 然而，比特币实验有另一个可以说是更重要的部分，即作为分布式共识工具的底层区块链技术，并且人们的注意力正迅速地开始转移到比特币的这个方面。 经常被提到的其他区块链技术应用包括：使用链上数字资产表示自定义货币和金融工具（“彩色币(opens in a new tab)”）、底层物理设备的所有权（“智能资产(opens in a new tab)”）、非同质化资产例如域名（“域名币(opens in a new tab)”），以及一些更复杂的应用，例如让数字资产由一段实现任意规则的代码（“智能合约(opens in a new tab)”）甚至由基于区块链的“去中心化自治组织(opens in a new tab)”(DAO) 直接控制。 以太坊打算提供一种内置完全成熟的图灵完备编程语言的区块链，这种语言可用来创建“合约”，而合约可用于编码任意状态转换函数，让用户可以创建上述任何系统以及我们尚未想象到的许多其他内容，只需用几行代码编写出想实现的逻辑即可。比特币及现有概念简介历史去中心化数字货币的概念以及财产登记等其他应用已经存在了几十年。 1980 年代和 1990 年代的匿名电子现金协议主要依赖于称为 Chaumian 盲签名的密码学原语，提供了一种具有高度隐私性的货币，但这些协议基本上未能获得关注，因为它们依赖于中心化中介。 1998 年，戴伟 (Wei Dai) 的 b-money(opens in a new tab) 成为第一个提出通过解决计算难题来创造货币及去中心化共识等想法的协议，但该协议缺乏关于如何实际实施去中心化共识的细节。 2005 年，Hal Finney 引入了“可重复使用的工作量证明(opens in a new tab)”这一概念，该系统将 b-money 的想法与 Adam Back 有计算难度的哈希现金难题相结合来创建加密货币的概念，但由于依赖可信计算作为后端，又一次未能做到完美。 2009 年，中本聪将通过公钥密码学管理所有权的成熟原语与用于跟踪货币所有者的共识算法相结合，首次真正意义上实现了一种去中心化货币，被称为“工作量证明”。工作量证明机制是该领域的一项突破，因为它同时解决了两个问题。 首先，它提供了一种简单且比较有效的共识算法，让网络中的节点能够全体对比特币账本状态的一组规范更新达成一致。 其次，它提供了一种允许自由进入共识过程的机制，解决了决定谁来影响共识的政治问题，同时防止了女巫攻击。 为此，在工作量证明中，将正式的参与壁垒（例如要求在特定清单上注册成为唯一实体）替换成经济壁垒，即共识投票过程中单个节点的权重与该节点的算力成正比。 此后，还提出了另一种称为权益证明的方法，节点权重与其货币持有量而非计算资源成正比；针对这两种方法相对优点的讨论不在本文范围内，但应该注意，这两种方法都可以作为加密货币的支柱。比特币是一个状态转换系统从技术角度讲，诸如比特币等加密货币账本可视作一种状态转换系统，该系统有一个“状态”，由全部现存比特币的所有权状态和一个“状态转换函数”组成，状态转换函数以状态和交易为输入并输出新状态作为结果。 例如，在标准的银行系统中，状态就是一个资产负债表，一笔交易是一个从 A 帐户向 B 帐户转账$X的请求，状态转换函数将从A帐户中减去$X，向 B 帐户增加$X。 如果A帐户的余额在第一步中小于$X，状态转换函数就会返回错误提示。 所以，可以如此定义：APPLY(S,TX) -> S' or ERROR

上面提到的银行系统中，状态转换函数如下：APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

但是：APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

比特币中的“状态”是指所有已铸造但尚未使用的货币（技术上称为“未使用的交易输出”或 UTXO）的集合，每个 UTXO 都有面额和所有者（由一个 20 字节的地址定义，本质上是一个加密公钥 [fn1]（注释编号））。 一个交易包括一个或多个输入以及一个或多个输出，每个输入都包含对现有 UTXO 的引用以及所有者地址相关的私钥创建的加密签名；每个输出都包含一个要添加到状态中的新 UTXO。状态转换函数 APPLY(S,TX) -> S' 的定义大体如下：对于 TX 中的每个输入：如果引用的 UTXO 不在 S 范围内，则返回错误。如果提供的签名与 UTXO 的所有者不符合，则返回错误。如果所有输入 UTXO 面值总额小于所有输出 UTXO 面值总额，则返回错误。在移除所有输入 UTXO 且添加所有输出 UTXO 后，返回 S。第一步的第一部分防止交易发送者花费不存在的比特币，第二部分防止交易发送者花费其他人的比特币，第二步确保价值守恒。 为了用于支付，比特币协议如下。 假设 Alice 想给 Bob 发送 11.7 BTC。 首先，Alice 将寻找她拥有的一组总数至少为 11.7 BTC 的可用 UTXO。 事实上，Alice 不太可能正好有 11.7 BTC；假设她能得到的最小数额是 6+4+2=12。 所以，她可以创建一笔有三个输入和两个输出的交易。 第一个输出为 11.7 BTC，所有者是 Bob 的地址，第二个输出为剩下的 0.3 BTC 找零，所有者是 Alice 自己。挖矿如果我们拥有可信任的中心化服务机构，状态转换系统可以很容易地实现；可以简单地将上述功能准确编码，使用中心化服务器的硬盘来记录状态。 然而，我们想把比特币构建成去中心化货币系统，为了确保每个人都同意交易的顺序，我们需要将状态转换系统与一个共识系统结合起来。 比特币的去中心化共识进程要求网络中的节点不断尝试将交易打包成“区块”。 网络计划大约每十分钟产生一个区块，每个区块包含一个时间戳、一个随机数、一个对上一个区块的引用（即哈希）和上一区块生成以来发生的所有交易列表。 随着时间推移就创建出了一个持续增长的区块链，它不断地更新，从而能够代表比特币账本的最新状态。检查一个区块是否有效的算法，如以下范式所示：检查该区块引用的上一个区块是否存在且有效。检查该区块的时间戳是否大于上一个区块 [fn2]（注释编号）的时间戳并且在将来 2 小时以内检查区块上的工作量证明是否有效。令前一个区块末尾的态为 S[0]。假设 TX 是该区块的交易列表，其中包含 n 个交易。 对于 0...n-1 中的所有 i，如果有任何应用程序返回错误，退出并返回 false，请设置 S[i+1] = APPLY(S[i],TX[i])。返回 true，并将 S[n] 登记为该区块末尾的状态。本质上，区块中的每笔交易都必须提供一个有效的状态转换，从交易执行前的规范状态转换到某个新状态。 注意，状态并未编码到区块。它纯粹只是校验节点记住的抽象概念，只能被任意区块从创世状态开始，按顺序加上每一个区块的每一笔交易，（安全地）计算出当前状态。 另外，需要注意矿工将交易收录进区块的顺序。如果一个区块中有 A、B 两笔交易，B 花费的是 A 创建的 UTXO，如果 A 在 B 之前，这个区块是有效的，否则，这个区块无效。“工作量证明”是出现在上表而其他系统没有的验证条件。 具体验证方法为，对每个区块进行两次 SHA256 哈希处理，得到一个 256 位的数值，该数值必须小于不断动态调整的目标数值，本文写作时目标数值大约是 2187。 工作量证明的目的是使创建区块有算力困难，从而阻止女巫攻击者恶意重新生成区块链。 因为 SHA256 是完全不可预测的伪随机函数，创建有效区块的唯一方法就是简单地不断试错，不断地增加随机数的数值，查看新的哈希数是否小于目标值。当前的目标数值是~2187，网络必须平均尝试 ~269次才能生成有效的区块。一般而言，比特币网络每隔 2016 个区块重新设定目标数值，从而保证网络中的节点平均每十分钟生成一个区块。 为了对矿工的计算工作进行激励，每一个成功生成区块的矿工有权在区块中包含一笔凭空发给他们自己 12.5 BTC 的交易。 另外，如果交易的输入额大于输出，差额部分就作为“交易费”付给矿工。 顺便提一下，这也是比特币发行的唯一机制，创世状态中并没有比特币。为了更好地理解挖矿的目的，让我们分析比特币网络出现恶意攻击者时会发生什么。 因为比特币的密码学基础是非常安全的，所以攻击者会选择攻击没有被密码学直接保护的部分：交易顺序。 攻击者的策略非常简单：向商家发送 100 个比特币以换取某种产品（最好是快速交付的数字商品）等待商品交付创建另一笔交易，将这 100 个比特币发送给自己试图让网络相信他对自己的交易是先发生的。一旦步骤 (1) 发生，几分钟后矿工将这笔交易收录到区块中，假设是编号为 270000 的区块。 大约一小时后，此区块后面将会有五个区块，每个区块间接地指向这笔交易，从而确认这笔交易。 这时卖家收到货款，并向买家发货。因为我们假设这是数字商品，交付将瞬间完成。 现在，攻击者创建另一笔交易，将相同的 100BTC 发送到自己的帐户。 如果攻击者只是单纯地向全网广播这一消息，该笔交易不会被处理；矿工将运行状态转换函数 APPLY(S,TX) ，发现这笔交易要花费已经不在状态中的 UTXO。 所以，攻击者会对区块链进行分叉，将第 269 个区块作为父区块重新生成第 270 个区块，在此区块中用新交易取代旧的。 因为区块数据是不同的，这要求重新进行工作量证明。 另外，攻击者的新版 270 区块有不同的哈希，原来的 271 到 275 的区块不指向它，所以原链和攻击者的新链是完全分离的。 规定，在发生区块链分叉时，最长链被认为是诚实的区块链，合法的矿工将会沿着原有的 275 区块挖矿，只有攻击者一人在新的 270 区块后挖矿。 攻击者为了使其区块链最长，他需要拥有比除了他以外的全网更多的算力来追赶（即“51%攻击”）。默克尔树左：仅提供默克尔树上的少量节点已经足够给出分支的合法证明。右：对默克尔树任意部分进行改变的尝试最终都会导致链上某处不一致。比特币一个重要的可扩展特性是：它的区块存储在多层次数据结构中。 一个区块的哈希实际上只是区块头的哈希，区块头是一段约 200 字节的数据，包含时间戳、随机数、上个区块的哈希和默克尔树根的哈希，而默克尔树是一个存储了该区块所有交易的数据结构。 默克尔树是一种二叉树，由一组叶节点、一组中间节点和一个根节点构成。最下面是大量包含基础数据的叶节点，每个中间节点是其两个子节点的哈希，顶部的根节点也是其两个子节点的哈希。 默克尔树的目的是允许区块数据可以零散地传送：节点可以从一个源下载区块头，从其它源下载相关树的一小部分，而依然能够确认所有的数据都是正确的。 之所以如此是因为哈希向上传播：如果一个恶意用户尝试替换一个伪造的交易到树的底部，此改动将导致树的上层节点的改动，以及更上层节点的改动，最终导致根节点的改动以及区块哈希的改动，这样协议就会将其记录为一个完全不同的区块（几乎可以肯定是带着无效的工作量证明）。默克尔树协议可以说是比特币长期持续性的基础。 比特币网络中的一个全节点——存储和处理所有区块全部数据的节点，在 2014 年 4 月需要占用 15GB 的磁盘空间，而且还以每个月超过 1GB 的速度增长。 目前，对台式计算机来说尚可接受，但是手机已经负载不了如此巨大的数据了，未来只有商业机构和爱好者才会充当完整节点。 简化支付确认协议（SPV）允许另一种节点存在，这样的节点被称为“轻节点”，它下载区块头，使用区块头确认工作量证明，然后只下载与其交易相关的默克尔树分支。 这使得轻节点只要下载整个区块链的一小部分，就可以安全地确定任何一笔比特币交易的状态和帐户的当前余额。其它的区块链应用将区块链思想应用到其它领域的想法早就出现了。 2005 年，Nick Szabo 提出了“利用所有者权限确保财产权(opens in a new tab)”这一概念，该文件描述了“复制数据库技术的新进展”将如何允许基于区块链的系统存储谁拥有哪些土地的登记表，创建了一个包括宅基地、违法占有和佐治亚州土地税等概念的复杂框架。 然而，不幸的是在那时还没有实用的复制数据库系统，所以这个协议没有被付诸实践。 不过，自 2009 年比特币的去中心化共识开发成功以来，大量区块链的其它应用开始快速出现。域名币 - 创建于 2010 年，域名币(opens in a new tab)描述成去中心化的名称注册数据库最为恰当。 在 Tor、比特币和比特信等去中心化协议中，需要某种方式来识别帐户，以便其他人可以与帐户交互，但在所有现有解决方案中，唯一可用的标识符是伪随机哈希，如 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy。 理想情况下，人们希望能够拥有名称的帐户，比如“george”。 但是，问题在于如果一个人可以创建名为“george”的帐户，那么其他人也可以按相同流程为自己注册“george”来冒充。 唯一的解决方案是“成果优先原则”范式，即第一个注册者成功后第二个注册者将失败，这个问题非常适合比特币共识协议。 域名币是应用这种想法的最早、最成功的名称注册系统实现。彩色币 - 彩色币(opens in a new tab)的作用是充当一种协议，让人们在比特币区块链上创建自己的数字货币，或者在货币只有一个单位的这种重要但琐碎情况下，创建数字代币。 在彩色币协议中，通过公开为特定的比特币 UTXO 分配一种颜色来“发行”新货币，并且该协议以递归方式将其他 UTXO 的颜色定义为与创建它们的交易所花费的输入的颜色相同（一些特殊规则适用于混合颜色输入的情况）。 这样，用户可以维护仅包含特定颜色 UTXO 的钱包，像发送普通比特币一样发送它们，并通过区块链回溯以确定他们收到的任何 UTXO 的颜色。元币 - 元币是想要拥有一个基于比特币的协议，使用比特币交易来存储元币交易，但具有不同的状态转换函数 APPLY'。 因为元币协议无法阻止无效元币交易出现在比特币区块链中，所以增加了一条规则，如果 APPLY'(S,TX) 返回错误，该协议默认为 APPLY'( S,TX) = S。 这为创建任意加密货币协议提供了一种简单的机制，可能有无法在比特币内部实现的高级功能，但开发成本非常低，因为比特币协议已经处理了挖矿和网络的复杂性。 元币已被用于实现某些类别的金融合约、名称注册和去中心化交易所。因此，一般而言，建立共识协议有两种方法：建立一个独立网络或把协议建立在比特币网络上。 前一种方法在域名币这样的应用中相当成功，但是该方法的实施非常困难，每个应用都要创建独立的区块链，建立并测试所有必须的状态转换函数和网络代码。 另外，我们预测去中心化共识技术应用将会服从幂律分布，大多数的应用太小不足以保证自身的安全，我们还注意到大量的去中心化应用，尤其是去中心化自治组织，需要进行应用之间的交互。另一方面，基于比特币的方法存在缺点，它没有继承比特币简化确认支付（SPV) 的特性。 比特币可以实现简化确认支付，因为比特币可以用区块链深度代表有效性；某种程度上，当一笔交易的祖先们距离现在足够远时，就可以安全地认为它们是合法状态的一部分。 与之相反，基于比特币区块链的元币协议不能强迫区块链剔除违反元币协议的交易。 因此，完全安全的元币协议的简化支付确认需要后向扫描所有的区块，直到比特币区块链的初始点，以确认某一交易是否有效。 目前，所有基于比特币的元币协议的“轻”实施都依赖可信任的服务器提供数据，这对主要目的之一是消除信任需要的加密货币而言，可能是一个相当次优的结果。脚本即使不对比特币协议进行扩展，它也能在一定程度上实现”智能合约”。 比特币的 UTXO 并非只能被公钥拥有，也可以被用基于堆栈的编程语言所编写的更加复杂的脚本所拥有。 在这一模式下，花费这样的 UTXO，必须提供满足脚本的数据。 事实上，甚至基本的公钥所有权机制也是通过脚本实现的：脚本将椭圆曲线签名作为输入，验证该交易和拥有此 UTXO 的地址，如果验证成功则返回 1，否则返回 0。 其它更复杂的脚本用于各种不同的应用情况。 例如，人们可以创建要求集齐三个私钥签名中的两个才能进行交易确认的脚本（多重签名），对公司帐户、安全储蓄帐户和某些商业代理来说，这种脚本是非常有用的。 脚本也能用来支付解决计算问题的奖励，人们甚至可以创建这样的脚本“如果你能够提供你已经发送一定数额的狗币给我的简化确认支付证明，该比特币 UTXO 就是你的了”，本质上，比特币系统允许不同的加密货币进行去中心化交易。然而，比特币系统的脚本语言存在一些严重的限制：缺乏图灵完备性 - 也就是说，虽然比特币脚本语言支持一个很大的计算子集，但它基本上不支持所有计算。 缺少的主要类别是循环。 这样做是为了避免交易验证期间出现无限循环；理论上，对脚本程序员来说循环是一个可以克服的障碍，因为任何循环都可以通过简单地使用 if 语句多次重复执行底层代码来模拟，但这确实会导致脚本的空间效率非常低下。 例如，实现另一种椭圆曲线签名算法可能需要 256 次重复的乘法，而每次都需要单独写在代码里。价值盲 - UTXO 脚本无法对可提取金额进行精细控制。 例如，预言机合约的一个强有力的用例是对冲合约，其中 A 和 B 存入价值 $1000 的比特币，30 天后脚本将价值 $1000 的比特币发送给 A，其余的发送给 B。这需要预言机来确定 1 个比特币的美元价值，但即便如此，与现有完全集中化的解决方案相比，这在信任和基础设施要求方面仍是一个巨大的进步。 然而，由于 UTXO 要么是全部要么是零，要实现这一目标，只能使用非常低效的破解方法，即持有许多不同面额的 UTXO（例如，面额为 2k 的 UTXO，每个 k 值都可以达到 30）并让预言机选择发送给 A 和发送给 B 的 UTXO。缺少状态 - UTXO 可以是已使用或未使用；用于保存任何其他内部状态的多阶段合约或脚本是没有机会出现的。 这使得多阶段期权合约、去中心化交易报价或两阶段加密承诺协议（这是安全计算赏金所必需的）难以创建。 这也意味着 UTXO 只能用于构建简单的一次性合约，而不是去中心化组织等更复杂的“有状态”合约，使得元协议难以实现。 二进制状态加之价值盲也意味着另一个重要应用 — 提款限制 — 是不可能实现的。区块链盲 - UTXO 看不到区块链的数据，例如随机数、时间戳和上一个区块的哈希。 由于该脚本语言无法通过随机性来创造可能的价值，它在博彩和其他几个类别的应用受到了严重限制。至此，我们已经考察了在加密货币上建立高级应用的三种方法：建立一个新的区块链、在比特币区块链上使用脚本、在比特币区块链上建立元币协议。 建立新区块链的方法可以自由地实现任意的特性，但要付出开发时间、引导工作和安全性的代价。 使用脚本的方法容易实施和标准化，但是它的功能有限。元币协议尽管非常容易实现，但是存在扩展性差的缺陷。 在以太坊系统中，我们打算建立一个替代框架，使得开发更便捷、轻客户端性能更强大，同时允许应用程序共享经济环境和区块链安全性。以太坊以太坊的目的是创建一个用于建立去中心化应用的替代协议，我们认为提供一套不同的折衷方案对大量去中心化应用非常有用，尤其是那些强调快速开发、小型和不常用应用的安全性，以及应用间高效交互能力的程序。 以太坊通过构建本质上是最终的抽象基础层来实现这一点：一种内置图灵完备编程语言的区块链，允许任何人编写智能合约和去中心化应用，并在其中设立他们自由定义的所有权规则、交易方式和状态转换函数。 域名币的主体框架只需要两行代码就可以实现，诸如货币和信誉系统等其它协议只需要不到二十行代码就可以实现。 智能合约，即包含价值、只有在满足特定条件时才能解锁的加密“盒子”，也可以在平台上构建，并且因为图灵完备性、价值知晓（value-awareness）、区块链知晓（blockchain-awareness）和多状态所增加的力量，而比比特币脚本所能提供的智能合约强大得多。以太坊帐户在以太坊中，状态由称为“帐户”的对象组成，而每个帐户都有一个 20 字节的地址，状态转换是指帐户之间价值和信息的直接转移。 一个以太坊帐户包含四个字段：nonce，用于确保每笔交易只能处理一次的计数器帐户当前的以太币余额帐户的合约代码（若有）帐户的存储（默认为空）以太币是以太坊内部的主要加密燃料，用于支付交易费。 通常有两类帐户：由私钥控制的外部帐户以及由其合约代码控制的合约帐户。 外部帐户没有代码，持有者可以通过创建和签署交易从外部帐户发送消息；在合约帐户中，每次合约帐户收到消息时，其代码都会激活，允许该帐户读取和写入内部存储，继而发送其他消息或创建合约。注意，以太坊中的“合约”不应被视为要“履行”或“遵守”的东西；相反，合约更像是存在于以太坊执行环境中的“自治代理”。当被交易或消息“触发”时，合约总是执行特定的代码段，并直接控制自已的以太币余额和键/值存储，以跟踪永久变量。消息和交易在以太坊中，术语“交易”用来指代已签名的数据包，数据包存储着将要从外部帐户发送的消息。 交易包含：消息接收者用于识别发送者身份的签名从发送者转账到接收者的以太币金额一个可选数据字段STARTGAS 值，表示允许交易运行的最大计算步骤数GASPRICE 值，表示发送者每个计算步骤支付的费用前三个是任何加密货币都有的标准字段。 默认情况下，数据字段没有函数，但虚拟机有一个操作码，合约可以使用该操作码访问数据；以这样的用例为例：如果一个合约作为区块链上的域名注册服务，那么它可能希望将传送给它的数据解释为包含两个“字段”，第一个字段是要注册的域名，第二个字段将域名注册到 IP 地址。 合约将从消息数据中读取这些值，并将其适当地存储。STARTGAS 及 GASPRICE 字段对于以太坊的反拒绝服务模型至关重要。 为了防止代码中出现无意或恶意的无限循环或其他计算浪费，要求每笔交易对代码可以执行的计算步骤设置一个限制。 计算的基本单位是燃料；通常，一个计算步骤消耗 1 份燃料，但某些操作会消耗更多燃料，因为它们在计算上更加昂贵或者增加了必须存储到状态中的数据量。 交易数据中的每个字节还需支付的费用为 5 份燃料。 收费系统的意图是要求攻击者相应支付他们消耗的每一种资源，包括计算、带宽和存储；因此，任何导致网络消耗更多这些资源的交易，都必须支付大致与增加量成比例的燃料费用。消息合约能够向其他合约发送“消息”。 消息是从未序列化的虚拟对象，只存在于以太坊执行环境中。 消息包含：消息发送者（隐含的）消息接收者随消息一起转账的以太币金额一个可选数据字段STARTGAS 值本质上消息类似于交易，只是消息是由合约而非外部参与者产生的。 当前正在运行代码的合约执行 CALL 操作码时会产生一条消息，该操作码就是用于产生并执行消息。 像交易一样，信息导致接收者帐户运行其代码。 因此，合约之间可以建立关系，方式完全与外部参与者之间建立关系相同。请注意，为交易或合约分配的燃料配额适用于该交易和所有子执行消耗的总燃料量。 例如，如果外部参与者 A 向 B 发送一笔配额为 1000 份燃料的交易，B 在向 C 发送消息需要消耗 600 份燃料，而 C 在内部执行需要消耗 300 份燃料才能返回结果，那么 B 再发送 100 份燃料就会消耗完燃料。以太坊状态转换函数以太坊状态转换函数 APPLY(S,TX) -> S' 可如下定义：检查交易格式是否正确（即具有正确数量的值）、签名是否有效以及 Nonce 值是否与发送者帐户中的 Nonce 值匹配。 若否，则返回错误。通过 STARTGAS * GASPRICE 计算出交易费，并从签名中确定发送地址。 从发送者的帐户余额中减去费用，并增加发送者的 nonce 值。 如果帐户余额不足，则返回错误。初始化 GAS = STARTGAS，并根据交易中的字节数量为每个字节扣除相应数量的燃料。将交易数值从发送者帐户转移至接收帐户。 如果接收帐户尚不存在，则创建此帐户。 如果接收帐户是合约，运行该合约的代码，直到代码运行结束或燃料耗尽。如果由于发送者资金不足或者代码运行耗尽了燃料，而导致转账失败，则回滚除支付费用之外的所有状态变化，并将费用支付给矿工帐户。否则，将所有剩余燃料的费用退还发送者，并把为所消耗燃料而支付的费用发送给矿工。例如，假设合约的代码如下：if !self.storage[calldataload(0)]:

self.storage[calldataload(0)] = calldataload(32)

注意，合约代码实际上是用低级以太坊虚拟机代码编写的；为了清晰起见，此示例是用我们的一种高级语言 Serpent 编写的，它可以编译为以太坊虚拟机代码。 假设合约的存储一开始是空的，发送了一个价值为 10 个以太币的交易，消耗 2000 份燃料，燃料价格为 0.001 个以太币，并且数据包含 64 个字节，字节 0-31 代表数字 2，字节 32-63 代表字符串 CHARLIE。 在这种情况下，状态转换函数的执行过程如下：检查交易是否有效、格式是否正确。检查交易发送者是否至少有 2000 * 0.001 = 2 个以太币。 若有，则从发送者帐户中扣除 2 个以太币。初始化燃料 = 2000 份，假设交易长度为 170 个字节，每字节费用 5 份燃料，减去 850 份燃料，剩下 1150 份燃料。从发送者帐户再减去 10 个以太币并增加到合约帐户。运行代码。 在本例中，运行比较简单：代码检查是否使用合约的索引 2 处的存储，若未使用，则通知；若使用，代码将索引 2 处的存储设置为值 CHARLIE。 假设该运行花费了 187 份燃料，所以余下的燃料数量是 1150 - 187 = 963 份燃料。向发送者帐户增加 963 * 0.001 = 0.963 个以太币，同时返回产生的状态。如果交易的接收一端没有合约，那么总交易费就等于提供的 GASPRICE 乘以交易的字节长度，并且和随交易发送的数据无关。注意，消息在回滚方面与交易相同：如果消息执行耗尽燃料，那么该消息的执行以及该执行触发的所有其他执行都会回滚，但父执行不需要回滚。 这意味着合约调用另一份合约是“安全的”，就好像 A 使用 G 份燃料调用 B，那么可以保证 A 的执行最多损耗 G 份燃料。 最后请注意，有一个创建合约的操作码 CREATE；它的执行机制通常类似于 CALL，不同之处在于执行的输出决定了新创建合约的代码。代码执行以太坊合约中的代码用一种基于堆栈的低级字节码语言编写，被称为“以太坊虚拟机代码”或“EVM 代码”。 该代码由一系列字节组成，每个字节代表一种操作。 通常，代码执行是一个无限循环，即重复执行当前程序计数器（从零开始）处的操作，然后将程序计数器增加一，直到代码执行完毕或出现错误，或者检测到 STOP 或 RETURN 指令。 操作可以访问三种数据存储空间：堆栈，一种后进先出容器，值可以在其中入栈和出栈内存，一种可无限扩展的字节数组合约的长期存储，一个键/值存储。 与堆栈和内存会在计算结束后重置不同，存储将长期持续存在。代码可以访问传入消息的值、发送者信息和数据，可以访问区块头数据，而且代码还可以返回数据字节数组作为输出。以太坊虚拟机码的正式执行模型简单得令人吃惊。 当以太坊虚拟机运行时，其完整计算状态可以由元组 (block_state, transaction, message, code, memory, stack, pc, gas) 来定义，其中 block_state 是包含所有帐户的全局状态并包括余额和存储。 在每一轮执行开始时，可以通过调用 code 的第 pc 个字节（或者如果 pc >= len(code)，则调用 0）来找到当前指令，并且每条指令在元组影响方式方面都有自己的定义。 例如，ADD 将两个项目出栈并将它们的和入栈，将 gas 减少 1 并将 pc 增加 1，SSTORE 将顶部的两个项目出栈并将第二个项目插入到合约存储中第一个项目指定的索引处。 尽管有很多通过 JIT 编译来优化以太坊虚拟机执行的方法，但只需几百行代码就可以完成以太坊的基本实现。区块链和挖矿以太坊区块链在许多方面与比特币区块链相似，但确实存在一些差异。 以太坊和比特币在区块链架构方面的主要区别在于，与比特币不同，以太坊区块包含交易列表和最新状态的副本。 此外，其他两个值、区块编号和难度也存储在区块中。 以太坊中的基本区块验证算法如下：检查被引用的前一个区块是否存在并有效。检查区块的时间戳是否大于被引用的前一个区块的时间戳，并且在将来 15 分钟以内。检查区块编号、难度、交易根、叔根和燃料限制（各种以太坊特定的低级概念）是否有效。检查区块上的工作量证明是否有效。令前一个区块末尾的态为 S[0]。令区块的交易列表为 TX，并包含 n 笔交易。 对于 0...n-1 中的所有 i，设置 S[i+1] = APPLY(S[i],TX[i])。 如果任何应用程序返回错误，或者直到此时区块中消耗的总燃料量超过 GASLIMIT，则返回错误。令 S_FINAL 为 S[n]，但添加支付给矿工的区块奖励。检查状态 S_FINAL 的默克尔树根是否等于区块头中提供的最终状态根。 如果等于，则该区块有效；否则该区块无效。这种方法乍一看效率似乎极低，因为它需要存储每个区块的全部状态，但实际上效率应该与比特币相当。 原因是状态存储在树结构中，而且在添加每个区块后只需要更改树的一小部分。 因此一般来说，在两个相邻区块之间，树的绝大部分应该是相同的，因此数据可以用指针（即子树的哈希）存储一次和引用两次。 一种称为“帕特里夏树”的特殊类型的树用于实现此目的，它包括对默克尔树概念的修改，允许高效地插入和删除节点，而不仅仅是更改。 此外，由于所有状态信息都存在于最后一个区块内，因此无需存储整个区块链历史，如果可以应用于比特币，使用这种策略计算可以节省 5-20 倍空间。一个常见的问题是合约代码在物理硬件的“哪里”执行。 该问题有一个简单的答案：合约代码的执行过程是状态转换函数定义的一部分，而该函数是区块验证算法的一部分，因此如果将交易添加到区块 B 中，由该交易产生的代码执行将在现在和将来由所有节点执行，由此下载并验证区块 B。应用通常，以太坊上有三种类型的应用。 第一类是金融应用，为用户提供更有效的方式来使用资金管理和签订合约。 包括子货币、金融衍生品、对冲合约、储蓄钱包、遗嘱，甚至最终包括某些类别的完整雇佣合约。 第二类是半金融应用，它们涉及金钱，但很大一部分功能也与资金无关；一个恰当的示例是针对解决计算难题的自动执行的赏金。 最后还有一些应用与金融毫不想关，例如在线投票和去中心化治理。代币系统区块链上的代币系统有许多应用，从代表美元或黄金等资产的子货币到公司股票等等，单个代币可以代表智能资产、不可伪造的安全优惠券，甚至可代表作为激励积分系统并与传统价值完全没有联系的代币系统。 代币系统在以太坊中非常容易实现，让人吃惊。 要理解的重点是，从根本上讲，所有货币或代币系统都是具有这样一种操作的数据库：从 A 中减去 X 个单位并将 X 个单位添加给 B，条件是 (1) A 在交易之前至少有 X 个单位并且 (2) 交易由 A 批准。实现代币系统所需要做的就是将此逻辑实现到合约中。使用 Serpent 语言实现代币系统的基本代码如下所示：def send(to, value):

if self.storage[msg.sender] >= value:

self.storage[msg.sender] = self.storage[msg.sender] - value

self.storage[to] = self.storage[to] + value

此代码本质上是本文档前面部分详细描述的“银行系统”状态转换函数的字面实现。 需要额外添加几行代码来规定在最初以及其他一些特殊情况下分配货币单位的初始步骤，理想情况下，应该添加一个函数让其他合约查询地址的余额。 但这就足够了。 理论上，基于以太坊的代币系统在作为子货币时可能具有另一个重要特征，该特征是基于比特币的链上元货币所缺乏的，那就是直接以该货币支付交易费的能力。 实现这一点的方式是：合约会保持一定数量的以太币余额，用来向发送者退还用于支付费用的以太币；合约也会通过收取费用来收集内部货币，并在持续不断的拍卖中转售货币，以此补充以太币余额。 因此，用户需要用以太币“激活”他们的帐户，但一旦帐户中有以太币，就可以重复使用，因为合约每次都会向帐户退还资金。金融衍生品和价值稳定的货币金融衍生品是“智能合约”最常见的应用，也是通过代码实现的最简单的应用之一。 实现金融合约的主要挑战在于，其中大多数合约都需要引用外部价格自动收报机；例如，一个非常理想的应用是对冲以太币（或其他加密货币）相对于美元波动的智能合约，但对冲需要合约知道以太币/美元的价值。 要实现这一点，最简单的方法是借助由特定方（例如纳斯达克）维护的“数据馈送”合约，这种合约的设计使得特定方能够根据需要更新合约并提供一个接口，允许其他合约向该合约发送消息并返回包含价格的响应。鉴于这一关键因素，对冲合约将如下所示：等待 A 方输入 1000 个以太币。等待 B 方输入 1000 个以太币。在存储中记录 1000 个以太币的美元价值（通过查询数据馈送合约计算得出），假设价值是 $x。30 天后，允许 A 或 B“重新激活”该合约，以便将价值 $x 的以太币（通过再次查询数据馈送合约获取新价格并且计算得出）发送给 A，剩余以太币发送给 B。这种合约在加密货币交易中潜力巨大。 加密货币的主要问题之一是它的波动性。尽管许多用户和商家可能希望获得处理加密资产的安全性和便利性，但他们中许多人不希望面临在一天内资金价值损失 23% 的景象。 迄今为止，最常见的解决方案是发行人支持的资产；其想法是发行人创建一种子货币，他们有权发行和撤销这种子货币单位，并且发行人可以向给他们（离线）提供一个单位指定基础资产（例如黄金、美元）的任何人提供一个单位的货币。 然后，发行人承诺向返还一个单位加密资产的任何人提供一个单位基础资产。 这种机制使得任何非加密资产“升级”为加密资产，前提是发行人是可信的。但实际上，发行人并不总是值得信赖，在某些情况下，银行基础设施过于薄弱或过于不友好，以至于无法提供此类服务。 金融衍生品提供了一种替代方案。 在这种方案中，不是由单个发行人提供资金来支持资产，而是由一个去中心化的投机者市场承担了这一角色，他们押注加密参考资产（例如以太币）的价格会上涨。 与发行人不同，投机者无法在交易中违约，因为对冲合约托管他们的资金。 请注意，这种方法不是完全去中心化的，因为仍然需要一个可信来源提供价格自动收报机，但可以说在降低基础设施要求（与成为发行者不同，发布价格馈送不需要许可证并且可能被归类为自由言论）以及减少欺诈的可能性方面，这仍是一次巨大的改进。身份和信誉系统最早的替代加密货币域名币(opens in a new tab)尝试使用类似比特币的区块链提供一种名称注册系统，通过该系统，用户可以在公共数据库中注册他们的姓名和其他数据。 主要用例是 DNS(opens in a new tab) 系统，它将诸如“bitcoin.org”等域名（在域名币的情况下，“bitcoin.bit”）映射到一个 IP 地址。 其它用例包括电子邮件身份验证系统和可能更为先进的信誉系统。 下面是一个基础合约，它在以太坊中提供与域名币类似的名称注册系统：def register(name, value):

if !self.storage[name]:

self.storage[name] = value

该合约非常简单；它完全是以太坊网络中的一个数据库，可以向其中添加但不能修改或移除。 任何人都可以把名称注册为一个值，该注册将永久保存。 更复杂的名称注册合约还包含一个“函数子句”以及一种机制，前者允许其他合约查询它，后者允许名称的“所有者”（即第一个注册者）更改数据或转让所有权。 甚至可以在该合约上添加信誉和信任网络功能。去中心化文件存储过去几年，大批受欢迎的在线文件存储初创公司不断涌现，其中最著名的是 Dropbox。Dropbox 想让用户可以上传硬盘备份、提供备份存储服务并允许用户访问备份，而用户需按月付费。 然而，在这一点上，文件存储市场有时效率相对较低。在粗略了解各种现有解决方案后会发现，主流文件存储的每月价格比整个硬盘驱动器的成本还要高，特别是在被称为“恐怖谷”的 20-200 GB 级别，既没有免费额度也没有企业级折扣。 以太坊合约让去中心化文件存储生态系统得以发展，个人用户可以在该系统中将自己的硬盘租出去以获得少量收益，而未使用的空间可用来进一步降低文件存储的成本。该系统的基础性构件就是我们所谓的“去中心化 Dropbox 合约”。 该合约的工作原理如下。 首先，用户将需要存储的数据拆分成几个区块并对每个区块加密以保护隐私，然后以此构建一个默克尔树。 然后创建一个含以下规则的合约，对于每 N 个区块，合约将从默克尔树中选择一个随机索引（使用能够被合约代码访问的上一个区块的哈希作为随机性来源），然后给予第一个实体 X 个以太币，以提供具有简化支付确认（例如证明树中特定索引处区块的所有权）的交易。 当用户想重新下载他们的文件时，可以使用微支付通道协议（例如每 32 KB 支付 1 个 szabo）收回文件；最节省费用的方法是支付者不到最后不发布交易，而是每 32 KB 之后，用一个更划算的具有相同 nonce 的交易取代原来的交易。该协议的一个重要特点是，虽然似乎用户相信许多随机节点不会丢失文件，但可以通过以下方法将这种风险降低到接近于零：通过私钥共享将文件拆分成许多部分，并通过监控合约确定每一部分仍在某个节点中。 如果合约仍在支付款项，则提供了一个加密证明，证明有人仍在存储该文件。去中心化自治组织通常意义上“去中心化自治组织”是指拥有一定数量成员或股东的虚拟实体，他们大概拥有 67% 的大多数股权，有权使用实体的资金并修改其代码。 成员集体决定组织的资金分配方式。 去中心化自治组织的资金分配方式可以是奖金、薪资或者更奇特的机制等等，比如用内部货币去奖励工作。 这在本质上复制了传统公司或者非营利组织的合法手段，但仅使用加密区块链技术进行了加强。 目前为止，许多关于去中心化自治组织的讨论都围绕着去中心化自治公司的“资本家”模式，其中有可获得红利的股东和可交易的股份；作为替代方案，有一种可能被称为“去中心化自治社区”的实体将使所有成员在决策时拥有同等权利，并在增减成员时要求 67% 的现有成员多数同意。 由于每个人只能拥有一个成员资格，所以需要群体来集体执行。下面概括了如何用代码实现去中心化自治组织。 最简单的设计就是一段自动修改的代码，如果三分之二的成员同意更改，该代码就更改。 理论上代码是不可更改的，然而通过把代码片段放入不同的合约并将合约调用的地址存储在可更改的存储中，用户可以轻易解决这一问题，使代码事实上变得可修改。 在这种去中心化自治组织合约的简单实现中，有三种交易类型，可通过交易中提供的数据行区分：[0,i,K,V] 在索引 i 处注册提案，以便将存储索引 K 的地址更改为值 V[1,i] 注册一张赞成提案 i 的投票[2,i] 如果投票有足够票数，则确认提案 i合约为每一种交易都提供有子句。 它将维护所有开放存储更改的记录以及投票支持者的列表。 合约还包括所有成员的列表。 当任何存储更改获得三分之二成员投票赞成时，一个确认交易将执行这项更改。 更复杂的框架可能还有针对发送交易、增减成员等功能的内置投票功能，甚至可以提供委任式民主(opens in a new tab)投票委托（即任何人都可以委托另外一个人代表自己投票，而且这种委托关系是可以传递的，如果 A 委托了 B，然后 B 委托了 C，那么 C 将决定 A 的投票）。 这种设计将使去中心化自治组织作为一个去中心化社区有机地成长，允许人们最终将筛选成员的任务委派给专家，但与“现有系统”不同，随着时间的推移，当个别社区成员改变他们的阵营时，专家可以很容易地加入或退出。另一个模型是去中心化公司，其中任何帐户可以拥有零份或多份股份，决策需要持有三分之二多数股份。 完整框架将包括资产管理功能，即能够出价购买或出售股份并且能够接受报价（最好是合约里有订单匹配机制）。 委托还提供委任制民主形式，普及了“董事会”的概念。更多应用1. 储蓄钱包。 假设 Alice 想安全地保管她的资金，但她担心自己的私钥丢失或被破解。 她把以太币放到和银行 Bob 签订的一个合约里，如下所示：Alice 每天最多可以单独提取 1% 的资金。Bob 每天最多可以单独提取 1% 的资金，但 Alice 可以用她的密钥创建一个交易取消 Bob 的提取权限。Alice 和 Bob 一起可以任意提取资金。通常，每天 1% 的额度对于 Alice 足够了，如果 Alice 想提取更多资金，她可以联系 Bob 寻求帮助。 如果 Alice 的密钥被破解，她可以立即找到 Bob，帮她将资金转移到一个新合约里。 如果 Alice 丢失了密钥，Bob 最终会取出资金。 如果最终发现 Bob 是恶意的，她可以取消他的提取权限。2. 作物保险。 用户可以轻松地制订金融衍生品合约，但使用的是天气而不是任何价格指数的数据馈送。 如果爱荷华州的一位农民购买了一项金融衍生品，该产品基于爱荷华的降雨情况进行反向赔付，那么如果遇到干旱，该农民将自动收到赔付资金，而且如果降雨充沛，他会很开心，因为他的作物收成会很好。 通常，这种保险可以扩展到自然灾害保险。3. 去中心化数据馈送。 对于金融差价合约，实际上有可能通过一种名为“谢林币(opens in a new tab)”的协议将数据馈送去中心化。 谢林币的基本工作原理如下。N 个相关方都向系统输入给定数据的值（以太币/美元价格），对这些值进行排序，在第 25 和第 75 百分位之间的每个人都会得到一个代币作为奖励。 每个人都有动力提供其他人都会提供的答案，而唯一能让众多参与者实际达成一致的值是显而易见的：真相。 这样就创建了一种去中心化的协议，它理论上可以提供任何数量的值，包括以太币/美元的价格、柏林的温度、甚至某个硬计算的结果。4. 智能多重签名托管。 比特币允许多重签名交易合约，例如，提供了给定五个密钥中的三个便可以使用资金。 以太坊允许更精细的控制；例如，提供五个密钥中的四个可以使用任意数额的资金，提供五个密钥中的三个可以每天最多使用 10% 的资金，提供五个密钥中的两个可以每天最多使用 0.5% 的资金。 此外，以太坊的多重签名是异步的 — 双方可以在不同时间在区块链上注册他们的签名，最后一个签名将自动发送交易。5. 云计算。 以太坊虚拟机技术还可以用来创建一个可验证的计算环境，让用户可以要求他人执行计算，然后有选择地索要证明，证实计算在某些随机选定的检查点处正确完成。 这就可以创建一个云计算市场，任何用户都可以用他们的台式机、笔记本电脑或专用服务器来参与，并且抽查与保证金双管齐下确保系统是值得信赖的（即节点不能通过欺骗获利）。 但是，这样的系统可能并不适合所有任务；例如，需要进行大量进程间通信的任务无法在大型节点云上轻易实现。 然而，其他任务则更容易实现并行；例如 SETI@home、folding@home 和遗传算法等项目可以方便地在这类平台上实现。6. 点对点赌博。 任意数量的点对点赌博协议都可以在以太坊区块链上实现，例如 Frank Stajano 和 Richard Clayton 的 Cyberdice(opens in a new tab)。 最简单的赌博协议实际上只是一种关于下一个区块哈希的差价合约，并且可以在其基础上创建更高级的协议，创建接近零费用且无法作弊的赌博服务。7. 预测市场。 如果有预言机或谢林币，预测市场也很容易实现，预测市场与谢林币一起有可能被证明是 futarchy(opens in a new tab) 的第一个主流应用，作为去中心化组织的治理协议。8. 链上去中心化市场，基于身份和信誉系统。杂项和关注改进版 GHOST 协议的实现“贪婪最重可观察子树”(GHOST) 协议是由 Yonatan Sompolinsky 和 Aviv Zohar 在 2013 年 12 月(opens in a new tab)首次提出的一项创新。 提出 GHOST 的动机是，具有快速确认时间的区块链目前由于过时率高而安全性降低 — 因为区块需要一定的时间才能通过网络传播，如果矿工 A 开采了一个区块，然后矿工 B 碰巧在矿工 A 的区块传播到 B 之前开采了另一个区块，那么矿工 B 的区块最终会被作废，不会增加网络安全。 此外，还有一个中心化问题：如果矿工 A 是一个拥有 30% 算力的矿池，而 B 拥有 10% 算力，那么 A 将面临 70% 的时间生产陈腐区块的风险（因为在其他 30% 的时间 A 产生了最后一个区块，所以会立即获得挖矿数据），而 B 将面临 90% 的时间生产陈腐区块的风险。 因此，如果区块间隔短到足以使过时率较高，则 A 将仅仅凭借其规模而显着提高效率。 结合这两种影响，快速产生区块的区块链很可能造就一个拥有足够高比例网络算力的矿池，从而对挖矿过程拥有事实上的控制。正如 Sompolinsky 和 Zohar 所描述的，GHOST 通过在计算哪条链“最长”时包含陈腐区块来解决第一个问题 - 网络安全降低；也就是说，在计算哪个区块具有最大的总工作量证明支持它时，不仅区块的父块和更远的祖先，而且该区块祖先（在以太坊行话中称为“叔块”）的陈腐子代也都被添加到计算中。 为了解决第二个问题 - 中心化偏差，我们跳出了 Sompolinsky 和 Zohar 描述的协议范畴，并且还为陈腐区块提供区块奖励：陈腐区块获得其基础奖励的 87.5%，而包含陈腐区块的侄块获得剩余的 12.5%。 不过，交易费不奖励给叔块。以太坊实现了一个简化版的 GHOST 协议，它仅仅深入七个层级。 具体而言，它的定义如下：一个区块必须指定一个父块，并且必须指定零个或多个叔块包含在区块 B 中的叔块必须具有以下属性：它必须是区块 B 的第 k 代祖先的直系子代，其中 2 <= k <= 7。它不能是 B 的祖先叔块必须是有效的区块头，但不需要是之前验证过的甚至是有效的区块叔块必须不同于前面区块中包含的所有叔块，并且不同于同一区块中包含的所有其他叔块（非双重包含）对于区块 B 中的每个叔块 U，区块 B 的矿工获得额外 3.125% 的铸币奖励，而叔块 U 的矿工获得 93.75% 的标准铸币奖励。这种限制版的 GHOST 协议，最多只能包含 7 代叔块，采用它有两个原因。 首先，无限制 GHOST 协议让计算给定区块的哪些叔块有效时过于复杂。 其次，无限制 GHOST 协议采用了以太坊中使用的补偿，取消了促使矿工在主链而不是公共攻击者的链上挖矿的激励措施。费用由于发布到区块链中的每笔交易都会给网络带来下载和验证成本，因此需要一些监管机制（通常涉及交易费）以防滥用。 比特币中使用的默认方法是收取完全自愿性质的费用，依靠矿工充当守门人并设置动态最低费用。 这种方法在比特币社区中非常受欢迎，特别是因为它是“基于市场的”，允许由矿工和交易发送者之间的供需决定价格。 然而，这种思路的问题在于，交易处理并不符合市场规律。尽管将交易处理解释为矿工向发送者提供的服务直观上很有吸引力，但实际上矿工收录的每笔交易都需要由网络中的每个节点处理，因此绝大部分交易处理成本由第三方承担，而不是由决定是否收录交易的矿工承担。 因此，公地悲剧的问题很可能发生。然而结果却是，基于市场机制中的这个缺陷，在给出一个不准确的特定简化假设时，会神奇地自我抵消。 论证如下。 假设：交易导致 k 个操作，将提供奖励 kR 给收录它的任何矿工，其中 R 由发送者设置，k 和 R 事先（大体上）对矿工可见。操作在任何节点的处理成本均为 C（即所有节点效率相同）有 N 个挖矿节点，每个节点的处理能力完全相同（即为总处理能力的 1/N）没有不挖矿的完整节点。如果预期奖励大于成本，矿工将愿意处理交易。 因此，预期奖励是 kR/N，因为矿工有 1/N 几率处理下一个区块，而矿工的处理成本仅仅是 kC。 所以，当 kR/N > kC 或者 R > NC 时，矿工将会收录交易。 请注意，R 是发送者提供的每个操作的费用，因此是发送者从交易中获得的收益的下限，NC 是整个网络共同处理一个操作的成本。 因此，矿工有动力仅收录那些总实际收益超过成本的交易。然而，现实中这些假设会存在几个重要偏差：与其他验证节点相比，矿工处理交易的成本确实更高，因为额外的验证时间会延迟区块传播，因而增加区块变陈腐的几率。确实存在不挖矿的完整节点。实际中挖矿能力的分配最终可能极端不平等。热衷于破坏网络的投机者、政敌和疯子确实存在，他们可以巧妙地设置合约，使得他们的成本远低于其他验证节点支付的成本。(1) 让矿工趋向于收录更少的交易，并且 (2) 增加 NC；因此，这两种作用会相互抵消 一部分 。如何抵消？(opens in a new tab) (3) 和 (4) 是主要问题，为了解决它们，我们简单地制订了一个 浮动上限：没有区块能够包含比 BLK_LIMIT_FACTOR 乘以长期指数移动平均值更多的操作数。 具体如下：blk.oplimit = floor(

(blk.parent.oplimit * (EMAFACTOR - 1) +

floor(parent.opcount * BLK_LIMIT_FACTOR)) /

EMA_FACTOR

)

BLK_LIMIT_FACTOR 和 EMA_FACTOR 是常量，暂时设置为 65536 和 1.5，但可能会在进一步分析后更改。还有一个因素会抑制比特币中的大区块大小：大区块将需要更长时间来传播，因此变陈腐的概率更高。 在以太坊中，燃料消耗量高的区块也可能需要更长的传播时间，因为它们的物理大小更大，而且因为它们需要更长时间来处理交易状态转换以进行验证。 这种延迟抑制因素在比特币中是一个重要的考虑因素，但在以太坊中由于 GHOST 协议而较少考虑；因此，依靠受监管的区块限制可提供更稳定的基线。计算和图灵完备重要的一点是，以太坊虚拟机是图灵完备的；这意味着以太坊虚拟机代码可以对任何设想可执行的计算进行编码，包括无限循环。 以太坊虚拟机代码以两种方式实现循环。 首先，使用一个 JUMP 指令，允许程序跳回至代码中的前一个位置，还使用一个 JUMPI 指令进行条件跳转，允许诸如 while x < 27: x = x * 2 之类的语句。 其次，合约可以调用其他合约，有可能通过递归进行循环。 这很自然地导致了一个问题：恶意用户能够通过迫使矿工和完整节点进入无限循环而不得不关机吗？ 这个问题的出现源于计算机科学中的一个难题，称为停机问题：在一般情况下，没有办法知道一个特定的程序是否会停止运行。正如状态转换部分所述，我们的解决方案要求交易设置一个允许执行的最大计算步骤数，如果超过执行时间，计算就会被回滚，但仍要支付费用。 消息的工作原理相同。 为显示我们解决方案背后的动机，请看下面的示例：攻击者创建一个运行无限循环的合约，然后向矿工发送激活该循环的交易。 矿工将处理该交易，运行无限循环直到燃料耗尽。 即使执行耗尽了燃料并中途停止，交易仍然有效，矿工仍然向攻击者索取每个计算步骤的费用。攻击者创建一个非常长的无限循环，目的是迫使矿工持续计算很长时间，以至于计算结束时，将有更多区块产生出来，这样矿工就不可能通过收录该交易来索取费用。 然而，攻击者需要为 STARTGAS 提交一个值，限制执行可以进行的计算步骤数，因此矿工将提前知道该计算将进行相当多的步骤数。攻击者看到一个合约，其中的代码形式为 send(A,contract.storage[A]); contract.storage[A] = 0，然后发送一个交易，但燃料只够运行第一步而不足以运行第二步（即进行提款但不让余额减少）。 合约作者无需担心防卫此类攻击，因为如果执行中途停止，更改会被回滚。金融合约使用九个专有数据馈送的中位数，以便最大限度降低风险。 攻击者接管其中一个数据馈送，该数据馈送设计为可通过去中心化自治组织部分描述的变量-地址-调用机制修改，并将其转换为运行无限循环，从而强制任何从金融合约索取资金的尝试都因燃料耗尽而中止。 然而，金融合约可以为消息设置一个燃料限制，防止这个问题发生。图灵完备的替代方案是图灵不完备，其中 JUMP 和 JUMPI 不存在，并且在任何给定时间每个合约只允许有一个副本存在于调用堆栈内。 在这样的系统里，上述收费系统和关于我们解决方案效果的不确定性可能都是不需要的，因为执行一个合约的成本将被它的大小决定。 此外，图灵不完备甚至不是一个很大的限制；在我们内部构想的所有合约示例中，到目前为止只有一个需要循环，甚至那个循环也可以通过将一行代码重复 26 次来消除。 考虑到图灵完备带来的严重影响和有限的益处，为什么不简单地使用一种图灵不完备语言呢？ 然而，在现实中，图灵不完备还远远不能有效地解决问题。 要想知道原因，请思考以下合约：C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

...

C49: call(C50); call(C50);

C50: (run one step of a program and record the change in storage)

现在，向 A 发送一笔交易。这样，在 51 笔交易中，我们有一个合约需要进行多达 250 个计算步骤。 矿工可以尝试提前检测这种逻辑炸弹，方法是为每个合约维护一个值，指定合约可以进行的最大计算步骤数，然后对递归调用其他合约的合约进行计算，但是这需要矿工禁止创建其他合约的合约（因为上面 26 个合约的创建和执行可以很容易地汇集到一个单独合约内）。 另一个问题是，消息的地址字段是一个变量，所以在一般情况下，甚至不可能提前知道某个合约将调用哪些其他合约。 于是，最终我们有了一个惊人的结论：图灵完备的管理惊人地容易，而在缺乏同样的控制时图灵不完备的管理惊人地困难，那为什么不直接让协议图灵完备呢？货币和发行以太坊网络包括自己的内置货币以太币，以太币扮演双重角色：提供一个主要流动资金层，实现各种数字资产之间的高效交易；更重要的是，提供一种支付交易费的机制。 为了方便起见并避免将来出现争议（参考比特币当前的 mBTC、uBTC、satoshi 争论），不同面值的名称将提前设置如下：1: wei1012：Szabo1015：finney1018：ETH这应该被视为“美元”和“美分”或“BTC”和“satoshi”概念的扩展版本。 在不久的将来，我们期望“ETH”用于普通交易，“finney”用于微型交易，“szabo”和“wei”可以在围绕费用和协议实现的技术讨论中使用；其余的面额可能会在以后变得有用，但目前不应包含在客户端中。发行模型如下：以太币将以货币销售的形式发行，价格为一个比特币可购买 1000-2000 个以太币，这种机制旨在为以太坊组织筹资和支付开发费用，且已被其他平台（如 Mastercoin 和 NXT）成功应用。 早期的购买者将从较大的折扣中获益。 发售所得的比特币将全部用来支付开发者的薪资和奖金，并用来投资以太坊和加密货币生态系统中的各种营利和非营利项目。0.099 倍的发售总量（60102216 个以太币）将分配给以太坊组织，以补偿早期贡献者，并用以太币计价的方式支付创世块诞生前的开销。0.099 倍的发售总量将作为长期储备金保留。发售后，将永久性地每年为矿工分配 0.26 倍的发售总量。分组启动时一年后5 年后货币单位1.198X1.458X2.498X购买者83.5%68.6%40.0%已支用的预售准备金8.26%6.79%3.96%已使用的售后准备金8.26%6.79%3.96%矿工0%17.8%52.0%长期供应增长率（百分比）尽管采用了线性发行方式，然而和比特币一样，以太币的长期供应增长率也趋于零。上述模型提供了两个主要选项：(1) 捐赠池的存在和规模，以及 (2) 永久增长的线性供应的存在，而比特币采用了限制供应的方法。 捐赠池存在的理由如下。 如果捐赠池不存在，并且线性发行量减少到总发售量的 0.217 倍以实现相同的通货膨胀率，那么以太币总量将减少 16.5％，而每个单位的价值将增加 19.8％。 因此为了均衡，将会多发售 19.8% 的以太币，所以每个单位的价值将再次与以前完全一样。 之后，该组织还将拥有 1.198 倍的比特币，可以考虑将其分成两部分：原有的比特币和增加的 0.198 倍比特币。 因此，这种情况完全等同于捐赠，但有一个重要区别：该组织仅持有比特币，因而没有动力支持以太币单位的价值。永久性线性供应增长模型降低了有些人认为比特币财富过度集中的风险，并为生活在当前和未来的人提供了获取货币单位的公平机会，同时又保留了让人获取并持有以太币的强效激励措施，因为长期来看，用百分比表示的“供应增长率”将趋于零。 我们还推测，由于加密货币总是会因为不小心、死亡等原因而丢失，而加密货币的损失可以被模拟为每年总供应量的百分比，因此流通中的货币总供应量实际上最终会稳定在一个等于每年发行量除以损失率的数值上（例如，在损失率为 1% 时，一旦供应量达到 26 倍，那么每年将有 0.26 倍被开采，0.26 倍丢失，形成一个平衡点）。注意，未来以太坊可能过渡到权益证明模型以确保安全，将每年发行量降低到 0 至 0.05 倍之间。 如果以太坊组织失去资助或出于任何其他原因而消失，我们将开放一个“社区合约”：任何人都有权创建未来的以太坊候选版本，唯一的条件是太币数量必须最多为 60102216 * (1.198 + 0.26 * n) 个，其中 n 是创世块产生后的年数。 创建者可以自由地通过众筹或其他方式，分配权益证明驱动的供应增加与最大允许供应增加之间的部分或全部差额，以支付开发费用。 不符合社区合约的候选版本升级可能被合理地分叉为兼容版本。挖矿中心化比特币挖矿算法的原理是，让矿工一次又一次地对区块头稍作修改的版本进行数百万次 SHA256 计算，直到最终某个节点所产生版本的哈希小于目标值（目前大约为 2192）。 然而，这种挖矿算法容易遭受两种形式的中心化攻击。 第一种，挖矿生态系统已经被 ASIC（专用集成电路）所支配，这些计算机芯片专门为特定的比特币挖矿任务而设计，因此效率提高了数千倍。 这意味着比特币挖矿不再是一种高度去中心化和平等的事业，需要巨额资本才能有效参与。 第二种，大部分比特币矿工事实上不在本地完成区块验证；而是依赖中心化矿池提供区块头。 这个问题可以说更糟：截至撰写本文时，排名前三的矿池间接控制了比特币网络中大约 50% 的处理能力，尽管当矿池或联盟试图进行 51％ 攻击时，矿工可以转换到其他矿池这一事实缓解了该问题。以太坊现在的目的是使用一种挖掘算法，要求矿工从状态中获取随机数据，从区块链的最后 N 个区块中计算一些随机选择的交易，并返回结果的哈希值。 这有两个重要好处。 首先，以太坊合约可以包含任何类型的计算，因此以太坊 ASIC 本质上是用于一般计算的 ASIC，即更好的 CPU。 其次，挖矿需要访问整个区块链，这迫使矿工存储整个区块链并至少能够验证每笔交易。 这样就消除了对中心化矿池的需求；虽然矿池仍然可以起到平衡奖励分配随机性的合法作用，但没有中心化控制的点对点矿池同样也可以很好地发挥此功能。该模型未经测试，在将合约执行作为挖矿算法使用时，在避免某些巧妙优化的过程中可能会遇到困难。 然而，这种算法有一个值得注意的特点，任何人都可以通过将专用于抑制某些 ASIC 的大量合约引入区块链中，在“井里下毒”。 由于存在经济激励，ASIC 制造商会使用这种方法互相攻击。 因此，我们正在开发的解决方案最终是一种适应性人为经济解决方案，而不是纯粹的技术解决方案。可扩展性可扩展性问题是以太坊常被关注的一个方面。 像比特币一样，以太坊也有缺陷，即网络中的每个节点都需要处理每笔交易。 使用比特币，当前区块链的大小约为 15 GB，每小时增长约 1 MB。 如果比特币网络像 Visa 一样每秒处理 2000 笔交易，它将每三秒增长 1 MB（每小时 1 GB，每年 8 TB）。 以太坊可能也会经历相似甚至更糟的增长模式，因为以太坊区块链之上还有很多应用，不像比特币区块链上只有货币，但以太坊完整节点只需存储状态而不是完整的区块链历史，这一事实让情况得到了改善。大区块链的问题是中心化风险。 如果区块链大小增加到 100 TB，可能的情况是只有极少数大型企业能运行完整节点，而所有普通用户将使用轻 SPV 节点。 在这种情况下，可能会出现这样的担忧：完整节点合伙欺诈牟利（例如更改区块奖励，给他们自己比特币等）。 轻节点无法立即检测到这一点。 当然，可能至少存在一个诚实的完整节点，几个小时之后有关诈骗的信息会通过 Reddit 这样的渠道泄露，但这时已为时过晚：将由普通用户相互组织协作将指定区块列入黑名单，这种大规模的、很可能不切实际的协作在规模上无异于发动一次成功的 51% 攻击。 就比特币而言，目前这是一个问题，但 Peter Todd 建议(opens in a new tab)对区块链进行修改，以缓解这一问题。在短期内，以太坊将使用两种其他策略来应对这个问题。 首先，因为基于区块链的挖矿算法，至少每个矿工都会被强制成为一个完整节点，为完整节点的数量创建了一个下限。 其次，更重要的是，处理完每笔交易后，我们会把一个中间状态树根收录到区块链中。 即使区块验证是中心化的，只要存在一个诚实的验证节点，就可以通过验证协议规避中心化问题。 如果矿工发布了无效区块，该区块必定是格式错误，或者是状态 S[n] 不正确。 由于已知 S[0] 是正确的，因此必然存在第一个不正确的状态 S[i]，但状态 S[i-1] 是正确的。 验证节点将提供索引 i 以及“无效证明”，该证明包括处理 APPLY(S[i-1],TX[i]) -> S[i] 所需的帕特里夏树节点的子集。 节点将能够使用这些节点来运行该部分计算，并查看生成的 S[i] 与提供的 S[i] 是否不匹配。另一种更复杂的攻击涉及恶意矿工发布不完整的区块，因此甚至不存在完整信息，致使无法确定区块是否有效。 解决方案是质询-应答协议：验证节点对目标交易索引发起“质疑”，接受到质疑信息的轻节点会对相应的区块取消信任，直到另外的节点（无论是矿工还是另一个验证者）提供一个帕特里夏树节点子集作为有效性证明。结论以太坊协议最初被设想为加密货币的升级版本，通过高度通用的编程语言提供高级功能，如区块链托管、提款限制、金融合约、博彩市场等。 以太坊协议不会直接“支持”任何应用，但图灵完备编程语言的存在意味着，理论上可以为任何交易类型或应用创建任意合约。 然而，关于以太坊更有趣的方面是，以太坊协议远远超出了货币的范畴。 围绕去中心化文件存储、去中心化计算和去中心化预测市场的协议以及许多其他这类概念，有可能大大提高计算行业的效率，并首次通过添加经济层来大力促进其他点对点协议的发展。 最后，还有大量与金钱完全无关的应用程序。以太坊协议实现的任意状态转换函数的概念提供了一个具有独特潜力的平台；而不是一种专门针对数据存储、赌博或金融领域内一系列特定应用的封闭式单用途协议，以太坊在设计上是开放式的，我们相信在今后几年中它非常适合作为大量金融和非金融协议的基础层。注释与延伸阅读注释有经验的读者可能会注意到，事实上比特币地址是椭圆曲线公钥的哈希，而非公钥本身。 然而事实上从密码学术语角度把公钥哈希称为公钥完全合理。 这是因为比特币密码学可以视为一种定制的数字签名算法。在数字签名算法中，公钥由 ECC（椭圆曲线加密算法）公钥的哈希组成，签名由连接了 ECC 签名的 ECC 公钥组成。而验证算法涉及用 ECC 公钥哈希（作为公钥提供）来检查签名中的 ECC 公钥，然后用 ECC 公钥来验证 ECC 签名。技术上来说，前 11 个区块的中位数。在内部，2 和 "CHARLIE" 都是数字 [fn3]（注释编号），后者采用大端序基数 256 表示。 数字可以至少为 0，最大为 2256-1。延伸阅读内在价值(opens in a new tab)智能资产(opens in a new tab)智能合约(opens in a new tab)B-money(opens in a new tab)可重复使用的工作量证明(opens in a new tab)利用所有者权限确保财产权(opens in a new tab)比特币白皮书(opens in a new tab)域名币(opens in a new tab)佐科三角(opens in a new tab)彩色币白皮书(opens in a new tab)万事达币白皮书(opens in a new tab)去中心化自治公司，比特币杂志(opens in a new tab)简化支付确认(opens in a new tab)默克尔树(opens in a new tab)帕特里夏树(opens in a new tab)GHOST 协议(opens in a new tab)StorJ 和自治代理，Jeff Garzik(opens in a new tab)Mike Hearn 在图灵节上谈论智能资产(opens in a new tab)以太坊递归长度前缀编码 (RLP)(opens in a new tab)以太坊默克尔帕特里夏树(opens in a new tab)Peter Todd 论默克尔求和树(opens in a new tab)有关本白皮书的历史，请参阅此维基文章(opens in a new tab)。和众多社区驱动的开源软件项目一样，以太坊自启动以来一直不断发展。 若想了解以太坊的最新进展以及如何更改以太坊协议，我们推荐您阅读本指南。本文对你有帮助吗？是否在本页面下一代智能合约和去中心化应用平台比特币及现有概念简介历史比特币是一个状态转换系统挖矿默克尔树其它的区块链应用脚本以太坊以太坊帐户消息和交易消息以太坊状态转换函数代码执行区块链和挖矿应用代币系统金融衍生品和价值稳定的货币身份和信誉系统去中心化文件存储去中心化自治组织更多应用杂项和关注改进版 GHOST 协议的实现费用计算和图灵完备货币和发行长期供应增长率（百分比）挖矿中心化可扩展性结论注释与延伸阅读注释延伸阅读网站最后更新: 2024年2月16日(opens in a new tab)(opens in a new tab)(opens in a new tab)使用以太坊查找钱包获取以太币Dapps - 去中心化应用二层网络运行节点稳定币质押ETH学习学习中心什么是以太坊？什么是以太币 (ETH)？以太坊钱包Gas fees以太坊安全和预防欺诈措施什么是 Web3？智能合约以太坊能源消耗以太坊路线图以太坊改进提案 （Eip）以太坊的历史以太坊白皮书以太坊词汇表以太坊治理区块链桥零知识证明测试中心开发者开始体验相关文档教程通过编码来学习设置本地环境生态系统社区中心以太坊基金会以太坊基金会的博客(opens in a new tab)生态系统支持方案(opens in a new tab)以太坊漏洞悬赏计划生态系统资助计划以太坊品牌资产Devcon(opens in a new tab)企业级应用主网以太坊私密以太坊企业级应用关于ethereum.org关于我们工作机会参与贡献语言支持隐私政策使用条款缓存政策联系我们(opens in a new t

Ethereum Whitepaper | ethereum.org

reum Whitepaper | ethereum.orgSkip to main contentLearnUseBuildParticipateResearchSearchLanguages ENHelp update this pageThere’s a new version of this page but it’s only in English right now. Help us translate the latest version.Translate pageNo bugs here!This page is not being translated. We've intentionally left this page in English for now.Don't show againHome/whitepaperPage last updated: August 15, 2023On this pageA Next-Generation Smart Contract and Decentralized Application PlatformIntroduction to Bitcoin and Existing ConceptsHistoryBitcoin As A State Transition SystemMiningMerkle TreesAlternative Blockchain ApplicationsScriptingEthereumEthereum AccountsMessages and TransactionsMessagesEthereum State Transition FunctionCode ExecutionBlockchain and MiningApplicationsToken SystemsFinancial derivatives and Stable-Value CurrenciesIdentity and Reputation SystemsDecentralized File StorageDecentralized Autonomous OrganizationsFurther ApplicationsMiscellanea And ConcernsModified GHOST ImplementationFeesComputation And Turing-CompletenessCurrency And IssuanceLong-Term Supply Growth Rate (percent)Mining CentralizationScalabilityConclusionNotes and Further ReadingNotesFurther ReadingEthereum WhitepaperThis introductory paper was originally published in 2014 by Vitalik Buterin, the founder of Ethereum, before the project's launch in 2015. It's worth noting that Ethereum, like many community-driven, open-source software projects, has evolved since its initial inception.While several years old, we maintain this paper because it continues to serve as a useful reference and an accurate representation of Ethereum and its vision. To learn about the latest developments of Ethereum, and how changes to the protocol are made, we recommend this guide.Researchers and academics seeking a historical or canonical version of the whitepaper [from December 2014] should use this PDF.A Next-Generation Smart Contract and Decentralized Application PlatformSatoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value(opens in a new tab)" and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins(opens in a new tab)"), the ownership of an underlying physical device ("smart property(opens in a new tab)"), non-fungible assets such as domain names ("Namecoin(opens in a new tab)"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts(opens in a new tab)") or even blockchain-based "decentralized autonomous organizations(opens in a new tab)" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.Introduction to Bitcoin and Existing ConceptsHistoryThe concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money(opens in a new tab) became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of "reusable proofs of work(opens in a new tab)", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof-of-work".The mechanism behind proof-of-work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof-of-stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.Bitcoin As A State Transition SystemFrom a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A's account by $X and increases the value in B's account by $X. If A's account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:APPLY(S,TX) -> S' or ERROR

In the banking system defined above:APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

But:APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public keyfn1). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.The state transition function APPLY(S,TX) -> S' can be defined roughly as follows:For each input in TX:If the referenced UTXO is not in S, return an error.If the provided signature does not match the owner of the UTXO, return an error.If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.Return S with all input UTXO removed and all output UTXO added.The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.MiningIf we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:Check if the previous block referenced by the block exists and is valid.Check that the timestamp of the block is greater than that of the previous blockfn2 and less than 2 hours into the futureCheck that the proof-of-work on the block is valid.Let S[0] be the state at the end of the previous block.Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.Return true, and register S[n] as the state at the end of this block.Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.The one validity condition present in the above list that is not found in other systems is the requirement for "proof-of-work". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)Wait for the delivery of the productProduce another transaction sending the same 100 BTC to himselfTry to convince the network that his transaction to himself was the one that came first.Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof-of-work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").Merkle TreesLeft: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.Right: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof-of-work).The Merkle tree protocol is arguably essential to long-term sustainability. A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof-of-work on the block headers, and then download only the "branches" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.Alternative Blockchain ApplicationsThe idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority(opens in a new tab)", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.Namecoin - created in 2010, Namecoin(opens in a new tab) is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.Colored coins - the purpose of colored coins(opens in a new tab) is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY'. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.ScriptingEven without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.However, the scripting language as implemented in Bitcoin has several important limitations:Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B.Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.Blockchain-blindness - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.EthereumThe intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.Ethereum AccountsIn Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:The nonce, a counter used to make sure each transaction can only be processed onceThe account's current ether balanceThe account's contract code, if presentThe account's storage (empty by default)"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.Messages and TransactionsThe term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:The recipient of the messageA signature identifying the senderThe amount of ether to transfer from the sender to the recipientAn optional data fieldA STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to takeA GASPRICE value, representing the fee the sender pays per computational stepThe first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.The STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.MessagesContracts have the ability to send "messages" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:The sender of the message (implicit)The recipient of the messageThe amount of ether to transfer alongside the messageAn optional data fieldA STARTGAS valueEssentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.Ethereum State Transition FunctionThe Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows:Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.For example, suppose that the contract's code is:if !self.storage[calldataload(0)]:

self.storage[calldataload(0)] = calldataload(32)

Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the string CHARLIE. The process for the state transition function in this case is as follows:Check that the transaction is valid and well formed.Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.Subtract 10 more ether from the sender's account, and add it to the contract's account.Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE, that creates a contract; its execution mechanics are generally similar to CALL, with the exception that the output of the execution determines the code of a newly created contract.Code ExecutionThe code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:The stack, a last-in-first-out container to which values can be pushed and poppedMemory, an infinitely expandable byte arrayThe contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.Blockchain and MiningThe Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:Check if the previous block referenced exists and is valid.Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the futureCheck that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.Check that the proof-of-work on the block is valid.Let S[0] be the state at the end of the previous block.Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.Let S_FINAL be S[n], but adding the block reward paid to the miner.Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.ApplicationsIn general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.Token SystemsOn-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is, is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.The basic code for implementing a token system in Serpent looks as follows:def send(to, value):

if self.storage[msg.sender] >= value:

self.storage[msg.sender] = self.storage[msg.sender] - value

self.storage[to] = self.storage[to] + value

This is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.Financial derivatives and Stable-Value CurrenciesFinancial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.Given that critical ingredient, the hedging contract would look as follows:Wait for party A to input 1000 ether.Wait for party B to input 1000 ether.Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they many not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.Identity and Reputation SystemsThe earliest alternative cryptocurrency of all, Namecoin(opens in a new tab), attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS(opens in a new tab) system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:def register(name, value):

if !self.storage[name]:

self.storage[name] = value

The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.Decentralized File StorageOver the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.Decentralized Autonomous OrganizationsThe general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:[0,i,K,V] to register a proposal with index i to change the address at storage index K to value V[1,i] to register a vote in favor of proposal i[2,i] to finalize proposal i if enough votes have been madeThe contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy(opens in a new tab)-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".Further Applications1. Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows:Alice alone can withdraw a maximum of 1% of the funds per day.Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability.Alice and Bob together can withdraw anything.Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.2. Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.3. A decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin(opens in a new tab)". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.4. Smart multisignature escrow. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.5. Cloud computing. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice(opens in a new tab), can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.7. Prediction markets. Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy(opens in a new tab) as a governance protocol for decentralized organizations.8. On-chain decentralized marketplaces, using the identity and reputation system as a base.Miscellanea And ConcernsModified GHOST ImplementationThe "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013(opens in a new tab). The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof-of-work backing it. To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%. Transaction fees, however, are not awarded to uncles.Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, it is defined as follows:A block must specify a parent, and it must specify 0 or more unclesAn uncle included in block B must have the following properties:It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.It cannot be an ancestor of BAn uncle must be a valid block header, but does not need to be a previously verified or even valid blockAn uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward.This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.FeesBecause every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums. This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price. The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it. Hence, tragedy-of-the-commons problems are very likely to occur.However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. The argument is as follows. Suppose that:A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand.An operation has a processing cost of C to any node (ie. all nodes have equal efficiency)There are N mining nodes, each with exactly equal processing power (ie. 1/N of total)No non-mining full nodes exist.A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block, and the processing cost for the miner is simply kC. Hence, miners will include transactions where kR/N > kC, or R > NC. Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.However, there are several important deviations from those assumptions in reality:The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale.There do exist nonmining full nodes.The mining power distribution may end up radically inegalitarian in practice.Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.(1) provides a tendency for the miner to include fewer transactions, and

(2) increases NC; hence, these two effects at least partially

cancel each other

out.How?(opens in a new tab)

(3) and (4) are the major issue; to solve them we simply institute a

floating cap: no block can have more operations than

BLK_LIMIT_FACTOR times the long-term exponential moving average.

Specifically:blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +

floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR and EMA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales. In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate. This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.Computation And Turing-CompletenessAn important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways. First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2. Second, contracts can call other contracts, potentially allowing for looping through recursion. This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop? The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid. Messages work in the same way. To show the motivation behind our solution, consider the following examples:An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem.The alternative to Turing-completeness is Turing-incompleteness, where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code. Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language? In reality, however, Turing-incompleteness is far from a neat solution to the problem. To see why, consider the following contracts:C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

...

C49: call(C50); call(C50);

C50: (run one step of a program and record the change in storage)

Now, send a transaction to A. Thus, in 51 transactions, we have a contract that takes up 250 computational steps. Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract). Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time. Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?Currency And IssuanceThe Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labelled:1: wei1012: szabo1015: finney1018: etherThis should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.The issuance model will be as follows:Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.0.099x the total amount sold will be maintained as a long-term reserve.0.26x the total amount sold will be allocated to miners per year forever after that point.GroupAt launchAfter 1 yearAfter 5 yearsCurrency units1.198X1.458X2.498XPurchasers83.5%68.6%40.0%Reserve spent pre-sale8.26%6.79%3.96%Reserve used post-sale8.26%6.79%3.96%Miners0%17.8%52.0%Long-Term Supply Growth Rate (percent)Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero.The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin. The justification of the endowment pool is as follows. If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable. Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before. The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x. Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year. In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block. Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development. Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.Mining CentralizationThe Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.ScalabilityOne common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour. If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year). Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd(opens in a new tab) which will alleviate this issue.In the near term, Ethereum will use two additional strategies to cope with this problem. First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes. Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect. Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i-1] is correct. The verifying node would provide the index i, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i]. Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided.Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.ConclusionThe Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language. The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer. Finally, there is also a substantial array of applications that have nothing to do with money at all.The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.Notes and Further ReadingNotesA sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself. However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself. This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.Technically, the median of the 11 previous blocks.Internally, 2 and "CHARLIE" are both numbersfn3, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1.Further ReadingIntrinsic value(opens in a new tab)Smart property(opens in a new tab)Smart contracts(opens in a new tab)B-money(opens in a new tab)Reusable proofs of work(opens in a new tab)Secure property titles with owner authority(opens in a new tab)Bitcoin whitepaper(opens in a new tab)Namecoin(opens in a new tab)Zooko's triangle(opens in a new tab)Colored coins whitepaper(opens in a new tab)Mastercoin whitepaper(opens in a new tab)Decentralized autonomous corporations, Bitcoin Magazine(opens in a new tab)Simplified payment verification(opens in a new tab)Merkle trees(opens in a new tab)Patricia trees(opens in a new tab)GHOST(opens in a new tab)StorJ and Autonomous Agents, Jeff Garzik(opens in a new tab)Mike Hearn on Smart Property at Turing Festival(opens in a new tab)Ethereum RLP(opens in a new tab)Ethereum Merkle Patricia trees(opens in a new tab)Peter Todd on Merkle sum trees(opens in a new tab)For history of the whitepaper, see this wiki(opens in a new tab).Ethereum, like many community-driven, open-source software projects, has evolved since its initial inception. To learn about the latest developments of Ethereum, and how changes to the protocol are made, we recommend this guide.Was this article helpful?YesNoOn this pageA Next-Generation Smart Contract and Decentralized Application PlatformIntroduction to Bitcoin and Existing ConceptsHistoryBitcoin As A State Transition SystemMiningMerkle TreesAlternative Blockchain ApplicationsScriptingEthereumEthereum AccountsMessages and TransactionsMessagesEthereum State Transition FunctionCode ExecutionBlockchain and MiningApplicationsToken SystemsFinancial derivatives and Stable-Value CurrenciesIdentity and Reputation SystemsDecentralized File StorageDecentralized Autonomous OrganizationsFurther ApplicationsMiscellanea And ConcernsModified GHOST ImplementationFeesComputation And Turing-CompletenessCurrency And IssuanceLong-Term Supply Growth Rate (percent)Mining CentralizationScalabilityConclusionNotes and Further ReadingNotesFurther ReadingWebsite last updated: February 16, 2024(opens in a new tab)(opens in a new tab)(opens in a new tab)Use EthereumFind walletGet ETHDapps - Decentralized applicationsLayer 2Run a nodeStablecoinsStake ETHLearnLearn HubWhat is Ethereum?What is ether (ETH)?Ethereum walletsGas feesEthereum security and scam preventionWhat is Web3?Smart contractsEthereum energy consumptionEthereum roadmapEthereum Improvement ProposalsHistory of EthereumEthereum WhitepaperEthereum glossaryEthereum governanceBlockchain bridgesZero-knowledge proofsQuiz HubDevelopersGet startedDocumentationTutorialsLearn by codingSet up local environmentEcosystemCommunity hubEthereum FoundationEthereum Foundation Blog(opens in a new tab)Ecosystem Support Program(opens in a new tab)Ethereum bug bounty programEcosystem Grant ProgramsEthereum brand assetsDevcon(opens in a new tab)EnterpriseMainnet EthereumPrivate EthereumEnterpriseAbout ethereum.orgAbout usJobsContributingLanguage supportPrivacy policyTerms of useCookie policyPress Contact(opens in a new t

[Chinese Simplified] Ethereum 白皮书中文版 · ethereum/wiki Wiki · GitHub

[Chinese Simplified] Ethereum 白皮书中文版 · ethereum/wiki Wiki · GitHub

Skip to content

Toggle navigation

Sign in

Product

Actions

Automate any workflow

Packages

Host and manage packages

Security

Find and fix vulnerabilities

Codespaces

Instant dev environments

Copilot

Write better code with AI

Code review

Manage code changes

Issues

Plan and track work

Discussions

Collaborate outside of code

Explore

All features

Documentation

GitHub Skills

Blog

Solutions

For

Enterprise

Teams

Startups

Education

By Solution

CI/CD & Automation

DevOps

DevSecOps

Resources

Learning Pathways

White papers, Ebooks, Webinars

Customer Stories

Partners

Open Source

GitHub Sponsors

Fund open source developers

The ReadME Project

GitHub community articles

Repositories

Topics

Trending

Collections

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Search

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

Sign up

You signed in with another tab or window. Reload to refresh your session.

You signed out in another tab or window. Reload to refresh your session.

You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

This repository has been archived by the owner on May 26, 2022. It is now read-only.

ethereum

/

wiki

Public archive

Notifications

Fork

2.5k

Star

14.7k

Code

Issues

34

Pull requests

7

Actions

Projects

0

Wiki

Security

Insights

Additional navigation options

Code

Issues

Pull requests

Actions

Projects

Wiki

Security

Insights

[Chinese Simplified] Ethereum 白皮书中文版

Jump to bottom

Joseph Cook edited this page May 24, 2022

·

12 revisions

This wiki has now been deprecated. Please visit ethereum.org for up-to-date information on Ethereum.

一个下一代智能合约和去中心化应用平台

如想了解更多内容，请关注微信公众号“Corey区块链技术分享”。

2009年中本聪发明的比特币经常被誉为金钱和货币的激进发展，作为数字资产的第一个例子，它同时没有人支持或者内在价值，也没有中心化的发行人或控制人。然而，可以说更重要的比特币实验的另一部分是作为分布式共识工具的底层区块链技术，并且人们的注意力正在迅速开始转向比特币的这个方面。区块链技术的常用可供选择的应用包括使用区块链数字资产来表示自定义货币和金融工具（彩色硬币），底层物理设备的所有权（智能财产），不可替代的资产，如域名（域名币），以及更复杂的应用程序，涉及让数字资产由实现任意规则的代码（智能合约）或甚至基于区块链的去中心化自治组织（DAO）直接控制。以太坊打算提供的是一个内置完全成熟的图灵完整编程语言的区块链，可用于创建“合约”，“合约”可用于编码任意状态转换函数，允许用户创建上面提到的任何系统，以及我们还没有想到的许多其他东西，只需通过在几行代码中编写逻辑。

Contents

比特币和现有概念的介绍

历史

作为一种状态转移系统的比特币

挖矿

Merkle树

替代的区块链应用程序

脚本

以太坊

哲学

以太坊账户

消息和交易

消息

以太坊状态转换函数

代码执行

区块链和挖矿

应用

令牌系统

金融衍生品和稳定价值货币

身份和声誉系统

去中心化文件存储

去中心化自治组织

其他应用

杂项和担忧

修改的GHOST实现

费用

计算和图灵完备性

货币和发行

挖矿中心化

可扩展性

结论

备注和延伸阅读

备注

延伸阅读

比特币和现有概念的介绍

历史

去中心化数字货币以及财产登记等替代应用程序的概念已存在数十年。20世纪80年代和90年代的匿名电子现金协议，主要依赖于称为Chaumian blinding的加密原语，提供了一种具有高度隐私的货币，但协议基本上未能获得欢迎，因为它们依赖于中心化的中介。1998年，Wei Dai的b-money成为第一个通过解决计算难题和去中心化共识来引入创造货币的想法的提案，但该提案很少有关于如何实际实现去中心化的共识的细节。2005年，Hal Finney介绍了一个可重复使用的工作量证明的概念，这个系统使用来自b-money的想法和Adam Back的计算难度很大的Hashcash谜题来创建加密货币的概念，但再次由于依赖于作为后端的可信计算而达不到理想的效果。2009年，中本聪首次在实践中实现了去中心化货币，将通过公钥密码学管理所有权的既定原语与用于跟踪谁拥有币的共识算法相结合，称为“工作量证明”。

工作量证明背后的机制是这个领域的突破，因为它同时解决了两个问题。首先，它提供了一种简单且适度有效的共识算法，允许网络中的节点集体就比特币分类账状态的一组规范更新达成一致。其次，它提供了一种机制，允许自由进入共识过程，解决决定谁影响共识的政治问题，同时防止sybil攻击。它通过把参与的正式障碍，例如要求在特定清单上注册为唯一实体，替换为经济障碍-共识投票过程中单个节点的权重与节点具有的计算能力成正比。从那时起，一种替代方法被提出了，称为股权证明，计算节点的权重与其货币持有量成正比，而不是计算资源;关于这两种方法的相对优点的讨论超出了本文的范围，但应该注意的是，这两种方法都可以用作加密货币的支柱。

这是一篇来自以太坊创始人Vitalik Buterin的博客文章，Ethereum pre-history。这是另一篇讲述了更多历史的博客文章。

作为一种状态转移系统的比特币

从技术角度来看，比特币等加密货币的账本可以被认为是一个状态转换系统，其中存在一个“状态”，包括所有现有比特币的所有权状态和一个“状态转换功能”，这个“状态转换功能”以一个状态和交易为输入，输出一个新的状态作为结果。例如，在标准银行系统中，状态就是一张资产负债表，一笔交易是将$X金额的货币从账户A移动到账户B的请求，状态转换函数将A账户中的值减少$X并将B账户的值增加$X。首先如果A的帐户余额少于$ X，则状态转换函数会返回错误。因此，人们可以正式定义：

APPLY(S,TX) -> S' or ERROR

在上面定义的银行系统中：

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

但是：

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

比特币中的“状态”指的是已经被挖矿但尚未花费的所有币（技术上，“未使用的交易输出”或UTXO）的集合，每个UTXO具有面额和所有者（由一个本质上是一个加密公钥的20字节地址定义fn. 1）。一笔交易包含一个或多个输入，每个输入包含对现有UTXO的引用和由与所有者地址关联的私钥生成的加密签名，每笔交易还包含一个或多个输出，每个输出包含一个要添加到状态的新UTXO。

状态转换函数APPLY(S,TX) -> S'可以大致定义如下：

对于TX中的每个输入:

如果引用的UTXO不在S中，则返回错误。

如果提供的签名与UTXO的所有者不匹配，则返回错误。

如果所有输入UTXO的面额之和小于所有输出UTXO的面额之和，则返回错误。

返回S'，删除所有输入的UTXO并添加所有输出的UTXO。

第一步的前半部分阻止交易发送者花费不存在的币，第一步的后半部分阻止交易发送者花费其他人的币，第二步强制价值守恒。为了将其用于支付，协议如下。假设Alice想要向Bob发送11.7 BTC。首先，Alice将寻找一些她拥有的可用UTXO，总计至少达到11.7 BTC。实际上，Alice将无法获得11.7 BTC;假设她能得到的最小的是6 + 4 + 2 = 12。然后，她使用这三个输入和两个输出创建一笔交易。第一个输出将是11.7 BTC，Bob的地址作为其所有者，第二个输出将是剩余的0.3 BTC“找零”，所有者是Alice自己。

挖矿

如果我们能够访问值得信赖的中心化服务，那么这个系统的实现将是微不足道的;它可以简单地完全按照描述编写代码，使用中心化服务器的硬盘驱动器来跟踪状态。然而，对于比特币，我们正在尝试建立一个去中心化的货币系统，因此我们需要将状态转移系统与一个共识系统相结合，以确保每个人都同意交易订单。比特币的去中心化共识过程要求网络中的节点不断尝试生成被称为“块”的交易包。该网络旨在每十分钟生成大约一个块，每个块包含一个时间戳，一个随机数，对前一个块的引用（例如，Hash值）以及自上一个块以来发生的所有交易的列表。随着时间的推移，这会创建一个持续的，不断增长的“区块链”，不断更新以代表比特币账本的最新状态。

在该范例中表示的用于检查块是否有效的算法如下：

检查块引用的前一个块是否存在且是否有效。

检查块的时间戳是否大于前一个块的时间戳fn. 2，以及在未来两小时之内。

检查块上的工作量证明是否有效。

把S[0]设置为前一个块末尾的状态。

假设TX是具有n个交易的块的交易列表。对于0...n-1中的所有i，设置S[i+1] = APPLY(S[i],TX[i])。如果任何应用程序返回错误，则退出并返回false。

返回true，并将S[n]注册为该块末尾的状态。

本质上，块中的每个交易必须提供从执行交易之前的规范状态到某个新状态的有效状态转换。请注意，状态不以任何方式编码在块中;它纯粹是一个被验证节点记住的抽象概念，只能通过从genesis（创世区块）状态开始并按顺序应用每个块中的每笔交易来（安全地）计算任意块。另外，请注意矿工将交易纳入区块的顺序很重要;如果一个块中有两笔交易A和B，使得B需要花费一个由A创建的UTXO，那么如果A发生在B之前，则该块将是有效的，否则无效。

上述列表中存在的其他系统中没有的一个有效性条件是“工作量证明”的要求。精确的条件是每个区块的double-SHA256散列值（被视为256位的二进制数）必须小于动态调整的目标，截至本文撰写时，该目标大约为2187。这样做的目的是使区块创建在计算上有“难度”，从而防止sybil攻击者重建对他们有利的整个区块链。因为SHA256被设计为一个完全不可预测的伪随机函数，所以创建一个有效区块的唯一方法就是试错，重复递增nonce随机数并查看新的hash是否匹配。

在当前目标 ~2187，网络必须在找到有效区块之前平均进行约 ~269次尝试;通常，每2016个区块由网络重新校准目标，因此平均每十分钟由网络中的某个节点产生一个新块。为了补偿矿工的这项计算工作，每个区块的矿工都有权包括一个不知从哪里获得12.5BTC的交易。此外，如果任何交易在其输入中的总面额高于其输出中的总面额，则差值也将作为“交易费”给矿工。顺便说一下，这也是BTC发行的唯一机制;创世区块根本没有币。

为了更好地理解挖矿的目的，让我们看看在一个恶意攻击者的事件中会发生什么。由于比特币的底层加密被认为是安全的，因此攻击者将把未直接受加密保护的比特币系统的一部分作为目标：交易顺序。攻击者的策略很简单：

将100 BTC发送给商家以换取某些产品（最好是快速交付的数字商品）

等待产品交付

制作另一笔交易，将相同的100 BTC发送给自己

试着说服网络，发送给他自己的交易是第一笔。

一旦步骤（1）发生，几分钟后，某个矿工将把交易包含在一个区块中，比如区块编号是270.大约一个小时后，在该区块之后将再添加五个区块，每个区块间接指向这笔交易并因此“确认”了它。此时，商家将接受最终确定的付款并交付产品;因为我们假设这是一种数字商品，所以交货是即时的。现在，攻击者创建了另一个将100 BTC发送给自己的交易。如果攻击者只是将其释放到野外，则这笔交易不会被处理;矿工将尝试运行APPLY(S,TX)并注意到TX消耗的是不再处于该状态的UTXO。因此，攻击者创建了一个区块链的“分叉”，开始挖掘另一个版本的区块270，该区块指向相同的父区块269，但用新交易代替旧交易。由于区块数据不同，这需要重做工作量证明。此外，攻击者的新版本的区块270具有不同的hash，因此原来的区块271至275没有“指向”它;因此，原始链和攻击者的新链是完全分开的。规则是，在一个分叉中，最长的区块链被认为是事实，因此合法的矿工将在275链上工作，而攻击者单独在270链上工作。攻击者为了让他的区块链最长，他需要拥有比网络剩余部分组合起来的计算能力更多的计算能力才能赶上（因此，“51％攻击”）。

Merkle树

左边：只需在Merkle树中显示少量节点就可以提供分支的有效性证明。

右边：任何改变Merkle树的任何部分的尝试最终都会导致链上某处的不一致。

比特币的一个重要的可扩展性特征是区块存储在多级数据结构中。区块的“hash”实际上只是区块头的hash，大约200字节的数据包含时间戳，随机数，上一个区块的hash和称为Merkle树的数据结构的根hash，Merkle树把所有交易存储在区块上。 Merkle树是一种二叉树，由一组节点组成，在树的底部有大量包含底层数据的叶子节点，以及一组中间节点，每个中间节点是两个子节点的hash，最后是一个根节点，也是由两个子节点的hash形成的，代表树的“顶部”。 Merkle树的目的是允许块中的数据逐个传递：节点只能从一个来源下载一个区块的头部，从另一个来源下载与它们相关的树的一小部分，并且仍然可以保证所有数据都是正确的。这样做的原因是哈希向上传播：如果一个恶意用户试图将假交易交换到Merkle树的底部，这种改变将导致上面的节点发生变化，然后再上面的节点也发生变化，最后改变树的根，从而改变区块的hash，使协议将其注册为完全不同的区块（几乎可以肯定是有无效的工作量证明）。

Merkle树协议对于长期可持续性而言至关重要。比特币网络中的“完整节点”，即存储和处理每个区块的节点，截至2014年4月在比特币网络中占用大约15 GB的磁盘空间，并且每月增长超过1GB字节。目前，这对于某些台式计算机而不是手机是可行的，并且稍后将来只有企业和业余爱好者才能参与。称为“简化支付验证”（SPV）的协议允许存在另一类节点，称为“轻节点”，其下载区块头，在区块头上验证工作量证明，然后仅下载与他们相关的交易相关联的“分支”。这使得轻型节点能够以强有力的安全保证来确定任何比特币交易的状态及其当前的余额，同时仅下载整个区块链的一小部分。

替代的区块链应用程序

采用底层区块链理念并将其应用于其他概念的想法也有很长的历史。1998年，Nick Szabo提出了拥有所有权的安全财产权概念，该文件描述了“复制数据库技术的新进展”将如何允许基于区块链的系统存储谁拥有土地的注册表，创建了精心设计的框架，包括田产，逆权侵占和格鲁吉亚土地税等概念。然而，遗憾的是，当时没有可用的有效复制数据库系统，因此该协议从未在实践中实施。然而，在2009年之后，一旦比特币的去中心化共识得以发展，许多替代应用程序迅速开始出现。

Namecoin - 在2010年创建，Namecoin最好被描述为去中心化名称注册数据库。在像Tor，Bitcoin和BitMessage这样的去中心化协议中，需要有一些识别帐户的方法，以便其他人可以与它们进行交互，但在所有现有解决方案中，唯一可用的标识符是伪随机哈希，如1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy。理想情况下，人们希望能够拥有一个名为比如“george”的帐户。但问题是，如果一个人可以创建一个名为“george”的帐户，那么其他人也可以使用相同的流程为自己注册“george”并冒充他们。唯一的解决方案是先申请制范例，第一个注册者成功，第二个注册失败 - 这个问题非常适合比特币共识协议.Namecoin是使用这种想法的最古老，最成功的名称注册系统实现。

Colored coins - 彩色硬币的目的是作为一种协议，允许人们创建自己的数字货币 - 或者，以一个单位货币的重要例子，数字令牌。在彩色硬币协议中，通过公开为特定比特币UTXO分配颜色来“发布”新货币，并且协议递归地将其他UTXO的颜色定义为与创建它们的交易的输入的颜色相同。 （一些特殊规则适用于混合颜色输入的场景）。这允许用户维护仅包含特定颜色的UTXO的钱包，并像普通比特币一样发送它们，通过区块链回溯以确定他们收到的任何UTXO的颜色。

Metacoins - metacoin背后的想法是拥有一个存在于比特币之上的协议，使用比特币交易来存储metacoin交易，但具有不同的状态转换功能，APPLY'。由于metacoin协议无法阻止无效的metacoin交易出现在比特币区块链中，因此添加了一条规则，即如果APPLY'(S,TX)返回错误，则协议默认为APPLY'(S,TX) = S.这提供了用于创建任意加密货币协议的简单机制，可能具有无法在比特币内部实现的高级功能，但由于挖矿和网络的复杂性已经由比特币协议处理，因此开发成本非常低。 Metacoins已被用于实现某些类别的金融合同，名称登记和去中心化交换。

因此，一般而言，建立共识协议有两种方法：构建独立网络，或者在比特币之上构建协议。前一种方法虽然在像Namecoin这样的应用程序中取得了相当的成功，但很难实现;每种单独的实现都需要引导独立的区块链，以及构建和测试所有必要的状态转换和网络代码。此外，我们预测去中心化共识技术的应用集将遵循幂律分布，其中绝大多数应用程序太小而无法保证自己的区块链，并且我们注意到存在大类去中心化应用，特别是去中心化自治组织，需要相互交流。

另一方面，基于比特币的方法存在缺陷，即它不会继承比特币的简化支付验证功能。 SPV适用于比特币，因为它可以使用区块链深度作为有效性的代理;在某些时候，一旦交易的祖先回到足够远的地方，就可以说它们是合法的状态的一部分。另一方面，基于区块链的元协议不能强制区块链不包括在其自己的协议的上下文中无效的事务。因此，完全安全的SPV元协议实现需要一直向后扫描到比特币区块链的开头，以确定特定交易是否有效。目前，基于比特币的元协议的所有“轻量级”实现依赖于可信服务器来提供数据，可以说是非常不理想的结果，尤其是当加密货币的主要目的之一是消除对信任的需求时。

脚本

即使没有任何扩展，比特币协议实际上确实促进了“智能合约”概念的弱版本。比特币中的UTXO不仅可以由公钥拥有，还可以由以简单的基于堆栈的编程语言表示的更复杂的脚本拥有。在这个范例中，花费UTXO的脚本必须提供满足脚本的数据。实际上，即使是基本的公钥所有权机制也是通过脚本实现的：脚本将椭圆曲线签名作为输入，根据交易和拥有UTXO的地址进行验证，如果验证成功则返回1，否则返回0。其他更复杂的脚本存在于各种其他使用场景中。例如，可以构建一个脚本，该脚本需要来自给定三个私钥中的两个的签名来验证（“multisig”），这对于公司帐户，安全储蓄帐户和一些商家托管情况是有用的设置。脚本也可以用来为计算问题的解决方案支付赏金，甚至可以构建一个脚本做这样的事“如果你能提供一个SPV证据证明你发送了这个面额的Dogecoin交易给我，那么这个比特币UTXO就是你的”，本质上允许去中心化的跨加密货币交换。

但是，比特币中实现的脚本语言有几个重要的局限性：

缺乏图灵完备性 - 也就是说，虽然比特币脚本语言支持大量计算，但它不支持所有计算。缺少的主要类别是循环。这样做是为了避免在交易验证期间出现无限循环;从理论上讲，它对于脚本程序员来说是一个可以克服的障碍，因为任何循环都可以通过简单地使用if语句多次重复底层代码来模拟，但它会导致脚本的空间效率非常低。例如，实现替代椭圆曲线签名算法可能需要256轮重复的乘法，每一轮乘法都单独包含在代码中。

价值盲区 - UTXO脚本无法对可以提取的金额进行细粒度控制。例如，一个强大的oracle合约用例将是一个对冲合约，其中A和B投入价值1000美元的BTC，30天后脚本将价值1000美元的BTC发送给A，其余的发送给B.这需要一个oracle确定1 BTC值多少美元，但即便如此，相对于现在可用的完全中心化解决方案而言，它在信任和基础设施需求方面是一个巨大的改进。然而，因为UTXO是要么全有要么全无的，所以实现这一目标的唯一方法是通过非常低效的侵入来获得不同面额的许多UTXO（例如，每k到30的一个UTXO为2k）并且选择哪个UTXO发送到A和哪个发送到B.

缺乏状态 - UTXO可以被花费或未花费;多阶段合约或脚本没有机会保持任何其他内部状态。这使得很难制定多阶段期权合约，去中心化交换要约或两阶段加密承诺协议（安全计算奖励所必需的）。这也意味着UTXO只能用于构建简单的一次性合约而不是更复杂的“有状态”合约，例如去中心化组织，并且使得元协议难以实现。二元状态与价值盲区相结合也意味着另一个重要的应用，即取款限制，是不可能的。

区块链盲区 - UTXO对区块链数据（如随机数，时间戳和先前区块的哈希）不了解。通过剥夺脚本语言可能有价值的随机数来源，这严重限制了赌博和其他几个类别的应用。

因此，我们看到了三种在加密货币之上构建高级应用程序的方法：构建新的区块链，在比特币之上使用脚本，以及在比特币之上构建元协议。构建新的区块链允许在构建功能集时拥有无限的自由，但代价是开发时间，引导工作和安全性。使用脚本很容易实现和标准化，但其功能非常有限，而元协议虽然容易，但却存在可伸缩性方面的缺陷。通过以太坊，我们打算构建一个替代框架，在开发简单性和更强大的轻客户端属性方面提供更大的收益，同时允许应用程序共享经济环境和区块链安全性。

以太坊

以太坊的目的是创建一个替代协议来构建去中心化的应用程序，提供我们认为对于大类去中心化的应用程序非常有用的一组不同的权衡（折衷），特别强调快速开发时间，小型和很少使用的应用程序的安全性，以及不同应用程序非常有效地交互的能力很重要。以太坊通过构建本质上最终的抽象基础层来实现这一目标：具有内置图灵完备编程语言的区块链，允许任何人编写智能合约和去中心化应用程序，在这些应用程序中，他们可以创建自己的任意规则，包括所有权，交易格式和状态转换功能。 Namecoin的简单版本可以用两行代码编写，其他协议如货币和信誉系统可以在二十以下构建。智能合约，包含价值并仅在满足某些条件时解锁的加密“盒子”也可以构建在这个平台之上，其功能远远超过比特币脚本提供的功能，因为图灵完备性的附加能力，价值意识，区块链意识和状态。

哲学

以太坊背后的设计旨在遵循以下原则：

简单性: 以太坊协议应该尽可能简单，即使以某些数据存储或时间效率低下为代价。fn. 3理想情况下，一般程序员应该能够遵循并实现整个规范， fn. 4以便充分实现加密货币带来的前所未有的民主化潜力，并进一步将以太坊作为一种向所有人开放的协议的愿景。任何增加复杂性的优化除非提供了非常实质性的好处，否则不应被包括。

普遍性: 以太坊的设计理念的一个基本部分是以太坊没有“特征”。fn. 5相反，以太坊提供了一种内部的图灵完备脚本语言，程序员可以使用它来构建任何可以在数学上定义的智能合约或交易类型。想要发明自己的金融衍生品？有了以太坊，你可以。想制作自己的货币？将其设置为以太坊合约。想要建立一个全面的守护进程或天网？你可能需要有几千个联锁合约，并且一定要慷慨地供给它们，这样做，但有了以太坊，没有什么能阻止你。

模块化: 以太坊协议的各个部分应设计为尽可能模块化和可分离的。在开发过程中，我们的目标是创建一个程序，如果要在一个地方进行一个小的协议修改，应用程序堆栈将继续运行而无需任何进一步修改。诸如Ethash（参见黄皮书附录或维基文章），修改过的Patricia树（黄皮书，wiki）和RLP（黄皮书，wiki）等创新应该是并且作为单独的功能完整的库实现。这样即使它们在以太坊中使用，即使以太坊不需要某些功能，这些功能在其他协议中仍然可用。应该最大限度地完成以太坊的发展，以便使整个加密货币生态系统受益，而不仅仅是以太坊本身。

敏捷: 以太坊协议的细节并非一成不变。虽然我们会非常明智地对高级构造进行修改，例如使用分片路线图，抽象执行，使用体现在共识中的数据可用性。稍后在开发过程中的计算测试可能会使我们发现某些修改，例如，协议架构或以太坊虚拟机（EVM）将大大提高可扩展性或安全性。如果发现任何此类机会，我们将利用它们。

无歧视和无审查: 协议不应试图主动限制或阻止特定类别的使用。协议中的所有监管机制都应设计为直接监管危害，而不是试图反对特定的不受欢迎的应用。程序员甚至可以在以太坊上运行无限循环脚本，只要他们愿意持续支付每个计算步骤的交易费用。

以太坊账户

在以太坊中，状态由称为“账户”的对象组成，每个帐户具有20字节的地址，账户之间的价值和信息的直接转移的状态转换。以太坊帐户包含四个字段：

nonce（随机数），一个用于确保每个交易只能处理一次的计数器

帐户的当前Ether(以太币)余额

帐户的合约代码（如果存在）

帐户的存储空间（默认为空）

“Ether(以太币)”是以太坊的主要内部加密燃料，用于支付交易费用。通常，有两种类型的帐户：外部拥有的帐户，由私钥控制，以及合约帐户，由合约代码控制。外部拥有的帐户没有代码，可以通过创建和签署交易从外部拥有的帐户发送消息;在合约账户中，每次合约账户收到一条消息，它的代码就激活了，允许其读取和写入内部存储并发送其他消息或依次创建合同。

请注意，以太坊中的“合约”不应被视为应该“履行”或“遵守”的东西;相反，它们更像是存活在以太坊执行环境中的“自治代理”，在被一条消息或交易“戳”时始终执行特定的代码，并且可以直接控制自己的以太币余额和自己的键/值存储以跟踪持久化的变量。

消息和交易

术语“交易”在以太坊中用于表示存储了一条要从外部拥有的帐户发送的消息的签名数据包。交易包含：

消息的接收者

一个标识发送者的签名

从发送者发送到接收者的以太币数量

可选的数据字段

STARTGAS值，表示允许交易执行的最大计算步骤数

GASPRICE值，表示发送者每个计算步骤支付的费用

前三个是任何加密货币中预期的标准字段。默认情况下，数据字段没有任何功能，但虚拟机具有被合约使用于访问数据的操作码;作为示例用例，如果一个合约作为区块链域名注册服务运行，那么它可能希望将被传递给它的数据解释为包含两个“字段”，第一个字段是要注册的域，第二个字段是该域要注册到的IP地址。合约将从消息数据中读取这些值，并将它们妥善地存储起来。

STARTGAS和GASPRICE字段对以太坊的反拒绝服务模式至关重要。为了防止代码中的意外或敌对无限循环或其他计算浪费，每笔交易都需要设置它可以使用的代码执行的计算步骤数量的限制。计算的基本单位是“gas”;通常，一个计算步骤花费1 gas，但是一些操作会花费更多的gas，因为它们的计算成本更高，或者增加了必须作为状态的一部分存储的数据量。交易数据中的每个字节还需要5 gas费用。费用系统的目的是要求攻击者按比例支付他们消耗的每种资源，包括计算，带宽和存储;因此，导致网络消耗更多这些资源的任何交易必须具有与增量大致成正比的gas费用。

消息

合约具有向其他合约发送“消息”的能力。消息是永远不会序列化的虚拟对象，仅存在于以太坊执行环境中。一条消息包含：

消息的发送者（隐含）

消息的接收者

与消息一起传输的ether数量

一个可选的数据字段

一个STARTGAS值

从本质上讲，消息就像一笔交易，除了它是由合约产生而不是外部账户。当正在执行代码的合约执行CALL操作码时会产生一条消息，该操作码生成并执行一条消息。与交易一样，消息会导致接收者帐户运行其代码。因此，合约可以以与外部账户完全相同的方式与其他合约建立关系。

请注意，交易或合约指定的gas限额适用于该交易和所有次级执行所消耗的总gas。例如，如果外部账户A向B发送了一笔1000 gas的交易，并且B在向C发送消息之前消耗了600 gas，并且C的内部执行在返回之前消耗了300 gas，那么B可以在消耗完gas之前再花费100 gas。

以太坊状态转换函数

以太坊状态转换函数APPLY(S,TX) -> S'可以定义如下：

检查交易是否格式正确（例如，具有正确数量的价值），签名是否有效，以及nonce是否与发送者帐户中的nonce匹配。如果没有，返回错误。

将交易费用计算为STARTGAS * GASPRICE，并从签名中确定发送地址。从发送者的帐户余额中减去交易费用并增加发送者的nonce。如果没有足够的余额支出，则返回错误。

初始化GAS = STARTGAS，并在每个字节中取出一定量的gas来支付交易中的字节数。

将交易价值从发送者的帐户转移到接收帐户。如果接收帐户尚不存在，就创建它。如果接收帐户是合约，则运行合约的代码，要么完成，要么直到执行消耗完gas。

如果由于发送者没有足够的资金而导致价值转移失败，或者代码执行耗尽gas，则除了支付交易费用之外回滚所有状态更改，并将交易费用添加到矿工的帐户。

否则，将所有剩余gas的费用退还给发送者，并将消耗的gas费用发送给矿工。

例如，假设合约的代码是：

if !self.storage[calldataload(0)]:

self.storage[calldataload(0)] = calldataload(32)

注意，实际上合约代码是用低级EVM代码编写的;这个例子是用Serpent编写的，这是我们的高级语言之一，这是为了清楚起见，可以被编译成EVM代码。假设合约的存储开始是空的，并且发送的交易有10个ether，2000 gas（gas价格是0.001个ether）和64个字节的数据，字节0-31表示数字2，字节32-63表示字符串CHARLIE 。fn. 6在这种情况下，状态转换功能的过程如下：

检查交易是否有效且格式正确。

检查交易发送者是否至少有2000 * 0.001 = 2 ether。如果是，则从发送者的帐户中减去2 ether。

初始化gas= 2000;假设交易是170字节长并且字节费是5 gas，减去850后便剩下1150 gas。

从发送者的帐户中再减去10 ether，并将其添加到合约的帐户中。

运行代码。在这种情况下，这很简单：它检查合约在索引2处的存储是否被使用，注意到它没有被使用，因此它将索引2处的存储设置为值CHARLIE。假设这需要187 gas，因此剩余的gas为1150 - 187 = 963

将963 * 0.001 = 0.963 ether添加回发送者的帐户，并返回结果状态。

如果在交易的接收端没有合约，则总交易费用将简单地等于提供的GASPRICE乘以交易的长度（以字节为单位），并且与交易一起发送的数据将是无关紧要的。

请注意，消息在交易回滚方面与交易等效地工作：如果消息执行耗尽gas，则该消息的执行以及该执行触发的所有其他执行都会回滚，但父执行不需要回滚。这意味着合约调用另一个合约是“安全的”，好像A用G gas呼叫B然后A的执行保证最多失去G gas。最后，请注意，有一个操作码CREATE，它创建了一个合约;它的执行机制通常类似于CALL，但执行的输出确定了一个新创建的合约的代码。

代码执行

以太坊合约中的代码是用低级的，基于堆栈的字节码语言编写的，称为“以太坊虚拟机代码”或“EVM代码”。代码由一系列字节组成，其中每个字节代表一个操作。通常，代码执行是一个无限循环，包括在当前程序计数器（从零开始）重复执行操作，然后将程序计数器递增1，直到达到代码结束或错误或检测到STOP或RETURN指令。这些操作可以访问存储数据的三种类型的空间：

堆栈，可以推入和弹出值的后进先出容器

内存，一个无限可扩展的字节数组

合约的长期存储，一个键/值存储。与堆栈和内存不同，堆栈和内存在计算结束后重置，存储会长期持久化。

代码还可以访问传入消息的值，发送者和数据，以及区块头数据，代码也可以返回数据的字节数组作为输出。

EVM代码的正式执行模型非常简单。当以太坊虚拟机运行时，其完整的计算状态可以由元组(block_state, transaction, message, code, memory, stack, pc, gas)定义，其中block_state是包含所有帐户的全局状态，包括余额和存储。在每轮执行开始时，通过获取code的第pc个字节（或者如果pc >= len(code)则为0）找到当前指令，并且每条指令在其如何影响元组方面都有自己的定义。例如，ADD将两个元素从堆栈中弹出并推入它们的总和，将gas减少1并将pc增加1，并且SSTORE将前两个元素从堆栈中弹出并将第二个元素插入到合约存储中的第一个元素的指定索引处。尽管有许多可以通过即时编译来优化以太坊虚拟机的执行的方法，但以太坊的基本实现可以在几百行代码中完成。

区块链和挖矿

以太坊区块链在许多方面类似于比特币区块链，尽管它确实存在一些差异。关于区块链架构，以太坊和比特币之间的主要区别在于，与比特币（仅包含交易清单的副本）不同，以太坊区块包含交易清单和最新状态的副本。除此之外，区块中还存储了另外两个值，即区块编号和难度。以太坊中的基本区块验证算法如下：

检查引用的前一个区块是否存在且是否有效。

检查区块的时间戳是否大于引用的前一个区块的时间戳，并且在将来不到15分钟内

检查区块编号，难度，交易根，叔根和gas限制（各种底层以太坊特定概念）是否有效。

检查区块上的工作量证明是否有效。

设S[0]为前一个区块末尾的状态。

设TX为区块的交易列表，具有n笔交易。对于0...n-1中的所有i，设置S[i+1] = APPLY(S[i],TX[i])。如果任何应用程序返回错误，或者直到此时区块中消耗的总gas超过GASLIMIT，则返回错误。

设S_FINAL为S[n]，但添加支付给矿工的区块奖励。

检查状态S_FINAL的Merkle树根是否等于区块头中提供的最终状态根。如果是，则该区块有效;否则，它无效。

这种方法乍一看似乎非常低效，因为它需要存储每个区块的整个状态，但实际上效率应该与比特币的效率相当。原因是状态存储在树结构中，并且在每个区块之后只需要更改树的一小部分。因此，通常，在两个相邻区块之间，绝大多数树应该是相同的，因此数据可以存储一次并使用指针（即，子树的hash）引用两次。一种称为“Patricia树”的特殊树用于实现此目的，包括对Merkle树概念的修改，允许有效地插入和删除节点，而不仅仅是更改节点。此外，由于所有状态信息都是最后一个区块的一部分，因此无需存储整个区块链历史记录 - 如果可以应用于比特币，则是一种可以节省5-20倍空间的策略。

一个常见问题是在物理硬件角度执行合约代码的“位置”。这有一个简单的答案：执行合约代码的过程是状态转换函数定义的一部分，状态转换函数是区块验证算法的一部分，因此如果一笔交易被添加到区块B中，那么该交易产生的代码执行将是现在和将来，由所有节点执行，下载并验证区块B.

应用

通常，在以太坊之上有三种类型的应用程序。第一类是金融应用程序，为用户提供更强大的方式来管理和使用他们的金钱合约。这包括子货币，金融衍生品，对冲合约，储蓄钱包，遗嘱，以及最终甚至一些类别的全面雇佣合约。第二类是半金融应用，其中涉及金钱，但对于正在进行的工作也存在很多的非货币方面;一个完美的例子是自我实施计算问题解决方案的赏金。最后，有一些应用和金融完全没有关系，如在线投票和去中心化治理。

令牌系统

区块链令牌系统有许多应用程序，从代表资产（如美元或黄金）的子货币到公司股票，代表智能财产的个人代币（令牌），安全的不可伪造的优惠券，甚至与传统价值无关的用作点数激励系统的代币（令牌）系统。在以太坊中，令牌系统非常容易实现。要理解的关键点是货币或令牌系统从根本上说是一个具有一个操作的数据库：从A减去X单位并将X单位赋予B，条件是（1）A在交易前至少有X个单位（2）交易由A批准。实现令牌系统所需的全部是将此逻辑实现到合约中。

在Serpent中实现令牌系统的基本代码如下：

def send(to, value):

if self.storage[msg.sender] >= value:

self.storage[msg.sender] = self.storage[msg.sender] - value

self.storage[to] = self.storage[to] + value

这基本上是本文件中上面进一步描述的“银行系统”状态转换功能的字面实现。需要添加一些额外的代码行来提供起初分配货币单位的初始步骤以及一些其他边缘情况，理想情况下会添加一个函数以让其他合约查询地址的余额。但这就是它的全部。从理论上讲，作为子货币的基于以太坊的令牌系统可能包括基于比特币的链上元货币缺乏的另一个重要特征：直接以该货币支付交易费用的能力。在这种实现方式下，合约会维护一个ether余额，合约可以用这个ether余额来退还被用于支付交易费用的ether给发送者，并且它将通过收集收取费用并在持续的拍卖中转售它们的内部货币单位来补充这种余额。因此，用户需要用ether“激活”他们的帐户，但是一旦ether在那里它就可以重复使用，因为合同每次都会退还。

金融衍生品和稳定价值货币

金融衍生产品是“智能合约”的最常见应用，也是最简单的用代码实现的应用之一。实施金融合约的主要挑战是，其中大多数合约要求参考外部价格代码;例如，一个非常受欢迎的应用是一个智能合约，它针对ether（或另一种加密货币）相对于美元的波动性进行套期保值，但这样做需要合约知道ETH/USD的价值是多少。最简单的方法是通过由特定方（例如纳斯达克）维护的“数据供应”合约，以便该方能够根据需要更新合约，并提供一个接口以便允许其他合约发送一条消息给“数据供应”合约，并且获得提供价格的回复。

鉴于这一关键因素，对冲合约将如下所示：

等待A方输入1000 ether。

等待B方输入1000 ether。

记录通过查询数据供应合约计算出的1000 ether对应的美元值到存储中，比如这是x美元。

30天后，允许A或B“重新激活”合约，以便发送价值x美元的ether（通过再次查询数据供应合约以获得新价格计算）到A，其余为B.

这种合约在密码商业方面具有巨大潜力。加密货币的一个主要问题是它是不稳定的;虽然许多用户和商家可能希望得到处理加密资产的安全性和便利性，但他们可能不希望面临在一天内损失其资金价值23％的预期。到目前为止，最常提出的解决方案是发行人背书的资产;我们的想法是，发行人创建一种子货币，在该子货币中，他们有权发行和撤销单位，并向任何向其提供（离线）一个特定标的资产（例如黄金，美元）的人提供一个单位的货币。然后，发行人承诺向发回一个加密资产单位的任何人提供一个单位的标的资产。该机制允许任何非加密资产被“提升”到加密资产中，前提是发行者可以被信任。

然而，在实践中，发行人并不总是值得信赖，在某些情况下，银行基础设施太弱或太过敌对，无法存在此类服务。金融衍生品提供了另一种选择。在这里，押注加密参考资产（例如ETH）的价格将上涨的投资者的去中心化市场，而不是提供资金来背书一个资产的单一发行人，起到了这个作用。与发行人不同，投资者不能选择在交易方面违约，因为套期保值合约将其资金存放在第三方托管账户中。请注意，这种方法并不是完全去中心化的，因为仍然需要一个可靠的来源来提供价格代码，尽管可以说这在减少基础设施需求（与发行人不同，发行价格供应不需要许可证并且很可能被归类为言论自由）方面仍然是一个巨大的改进并减少欺诈的可能性。

身份和声誉系统

最早的替代加密货币Namecoin试图使用类似比特币的区块链来提供名称注册系统，用户可以在公共数据库中将其名称与其他数据一起注册。主要引用的用例是针对DNS系统，将域名如“bitcoin.org”（或者，在Namecoin的场景下，“bitcoin.bit”）映射到IP地址。其他用例包括电子邮件身份验证和可能更高级的信誉系统。这是在以太坊上提供类似Namecoin的名称注册系统的基本合约：

def register(name, value):

if !self.storage[name]:

self.storage[name] = value

合约很简单;它只是以太坊网络中的一个数据库，可以添加到，但不能修改或删除。任何人都可以注册一个具有某值的名称，然后注册永远持久化。更复杂的名称注册合约还将具有允许其他合约查询它的“函数子句”，以及由名称“所有者”（即第一注册者）用于更改数据或转让所有权的机制。甚至可以基于它添加信誉和信任网络功能。

去中心化文件存储

在过去几年中，出现了许多流行的在线文件存储初创公司，其中最突出的是Dropbox，它试图允许用户上传其硬盘的备份并让服务存储备份并允许用户以付月费的方式访问它。但是，此时文件存储市场有时效率相对较低;粗略看一下现有的各种解决方案表明，特别是在20-200 GB级别的“恐怖谷”，既没有免费配额也没有企业级折扣，主流文件存储成本的月度价格是你支付了比一个月内整个硬盘的成本更多的金钱。以太坊合约可以允许开发去中心化文件存储生态系统，其中个人用户可以通过租用他们自己的硬盘来赚取少量资金，并且可以使用未使用的空间来进一步降低文件存储的成本。

这种设备的关键支撑部分将是我们所谓的“去中心化Dropbox合约”。该合约的工作原理如下。首先，将所需数据分成块，加密每个块以保护隐私，并从中构建Merkle树。然后创建一个合约，具有这样的规则：即每N个块，合约将在Merkle树中选择一个随机索引（使用先前的块哈希，可从合约代码访问，作为随机源），并将X ether提供给第一个为交易提供简化付款验证的实体 - 就像树中特定索引处块的所有权证明一样。当用户想要重新下载他们的文件时，他们可以使用微支付通道协议（例如，每32KB支付1 szabo）来恢复文件;最节省费用的方法是让付款人直到最后才发布交易，而是在每32KB后用相同的nonce替换稍微更有利可图的交易。

该协议的一个重要特征是，虽然看起来似乎是信任许多随机节点不会决定忘记该文件，但可以通过秘密共享将文件分成多个部分，并且观察合约看每个部分仍被某个节点占有来将风险降低到接近零。如果合约仍在支付金钱，则提供加密证据，证明某人仍然在存储该文件。

去中心化自治组织

“去中心化的自治组织”的一般概念是具有某些成员或股东的虚拟实体，其可能具有67％的多数，有权花费该实体的资金并修改其代码。成员将共同决定组织应如何分配资金。分配DAO资金的方法可以从奖金，工资到更为奇特的机制，如奖励工作的内部货币。这基本上复制了传统公司或非营利组织的法律外衣，但仅使用加密区块链技术来强制执行。到目前为止，关于DAO的大部分讨论都围绕着“去中心化自治公司”（DAC）的“资本主义”模式，其中包括股息接收股东和流通股;一种替代方案，也许被称为“去中心化自治社区”，将使所有成员在决策中拥有平等的份额，并要求67％的现有成员同意增加或删除一个成员。一个人只能拥有一个会员资格的要求需要由该集团共同执行。

关于如何编写DAO的一般概述如下。最简单的设计是一段自我修改的代码，如果三分之二的成员同意变更，则会发生变化。尽管代码在理论上是不可变的，但是人们可以轻松解决这个问题，并通过在分开的合同中包含代码块来实现事实上的可变性，并将调用的合约的地址存储在可修改的存储中。在这种DAO合同的简单实现中，将有三种交易类型，由交易中提供的数据区分：

[0,i,K,V]注册具有索引i的提议，以将存储索引K处的地址更改为值V.

[1,i]注册一个投票赞成提案i

[2,i]如果已经进行了足够的投票，最终确定提案i

然后合约将为每种交易类型都有子句。它将维护所有开放存储更改的记录，以及投票给他们的人员列表。它还有一个所有成员的清单。当任何存储更改得到三分之二的成员投票时，最终的交易可以执行更改。更复杂的架构也可以为发送交易，添加成员和删除成员等功能提供内置投票功能，甚至可以提供流动民主风格的投票授权（即任何人都可以指派某人帮他投票们，以及指派是传递性的，所以如果A指派B，B指派C，则C确定A的投票）。这种设计将允许DAO作为一个去中心化的社区有机地发展，允许人们最终委派过滤谁是专家的成员的任务，虽然不像“当前系统”专家可以随着时间的推移，随着个体社区成员改变他们的阵营，容易地出现和消失。

另一种模式是去中心化的公司，任何账户都可以拥有零股或多股，做出一个决定需要三分之二以上的股份。完整的架构将涉及资产管理功能，买卖股票报价的能力，以及接受报价的能力（最好在合约中有订单匹配机制）。代表团也将存在流动民主风格，概括了“董事会”的概念。

其他应用

1. 储蓄钱包。假设Alice希望保证她的资金安全，但担心她会丢失或有人会破解她的私钥。她将把ether放入一个与Bob和一家银行订立的合约，具体如下：

Alice一个人每天最多可以提取1％的资金。

Bob一个人每天最多可以提取1％的资金，但Alice有能力用她的密钥发起一笔交易来关闭这种能力。

Alice和Bob一起可以提取任何金额的资金。

通常情况下，每天1％对于Alice就足够了，如果Alice想要提取更多资金，她可以联系Bob寻求帮助。如果Alice的密钥遭到入侵，她会跑到Bob那里将资金转移到一份新合约上。如果她失去了她的密钥，Bob最终将把资金取出来。如果Bob被证明是恶意的，那么Alice可以关闭Bob的提取能力。

2. 农作物保险。人们可以轻松地制定金融衍生品合约，但使用天气的数据供应而不是任何价格指数。如果爱荷华州的一位农民购买的衍生品根据爱荷华州的降水量反向支付，那么如果发生干旱，农民将自动获得资金，如果有足够的降雨，农民会很高兴，因为他们的作物会很好。这一般可以扩展到自然灾害保险。

3. 去中心化的数据供应。对于差异的金融合约，实际上可以通过名为SchellingCoin的协议来使得数据供应去中心化。 SchellingCoin基本上按照如下工作：N方都将给定数据的值（例如ETH/USD价格）放入系统，值被排序，并且第25和第75百分点之间的每个人获得一个通证作为奖励。每个人都有动力提供答案，其他人也会，而且大部分人可以实际认同的唯一价值就是明显的默认：真相。这创建了一个去中心化的协议，理论上可以提供任意数量的值，包括ETH/USD价格，柏林的温度，甚至是特定困难计算的结果。

4. 智能多重签名托管。比特币允许多重签名交易合约，例如，给定五个密钥中的三个就可以花费资金。以太坊允许更细粒度;例如，五分之四可以花费所有资金，五分之三可以每天花费高达10％的资金，五分之二可以每天花费高达0.5％的资金。此外，以太坊多重签名是异步的 - 双方可以在不同时间在区块链上注册他们的签名，最后一个签名将自动发送交易。

5. 云计算。EVM技术还可用于创建可验证的计算环境，允许用户要求其他人执行计算，然后可选地请求证明某些随机选择的检查点的计算正确完成。这允许创建云计算市场，其中任何用户可以用他们的台式机，笔记本电脑或专用服务器来参与，并且可以与安全存款一起抽查来确保系统是可信的（即，节点不能有利地作弊） 。虽然这样的系统可能不适合所有任务;例如，需要高级别进程间通信的任务不能在大型节点云上轻松完成。但是，其他任务更容易并行化;像SETI@home, folding@home和基因遗传算法这样的项目可以很容易地在这样的平台上实现。

6. 点对点赌博。任意数量的点对点赌博协议，如Frank Stajano和Richard Clayton的Cyber​​dice，都可以在以太坊区块链上实现。最简单的赌博协议实际上只是下一个块hash的差异合约，并且可以从那里建立更高级的协议，创建具有接近零费用且无法作弊的赌博服务。

7. 预测市场。提供了oracle或SchellingCoin，预测市场也很容易实现，预测市场与SchellingCoin一起可能被证明是futarchy主流作为去中心化组织治理协议的第一个主流应用。

8. 链上去中心化市场，以身份和声誉系统为基础。

杂项和担忧

修改的GHOST实现

“Greedy Heaviest Observed Subtree（贪婪的最重要的观察子树）”（GHOST）协议是由Yonatan Sompolinsky和Aviv Zohar于2013年12月首次推出的创新.GHOST背后的动机是具有快速确认时间的区块链由于高过时率而目前遭受降低的安全性 - 因为区块需要一定的时间才能通过网络传播，如果矿工A挖掘一个区块，然后矿工B在矿工A的区块传播到B之前碰巧挖掘了另一个区块，那么矿工B的区块将最终被浪费掉，并且无助于网络安全。此外，存在一个集中问题：如果矿工A是具有30％哈希算力的矿池而B具有10％哈希算力，则A将有70％的时间产生过时区块的风险（因为另外30％的时间A产生了最后一个区块，因此将立即获得挖矿数据）而B将有90％的时间产生过时区块的风险。因此，如果区块间隔足够短以使过时速率变高，则仅通过其尺寸，A将大大提高效率。通过组合这两种效果，快速生成区块的区块链很可能导致一个矿池具有足够大的网络哈希算力百分比，以实际控制挖矿过程。

正如Sompolinsky和Zohar所描述的那样，GHOST通过在计算哪个链“最长”时包含过时区块来解决第一个网络安全丢失问题;也就是说，不仅是一个区块的父级和其他祖先，而且区块的祖先（在以太坊术语中，“叔区块”）的过时后代被添加到计算哪个区块具有最大的工作量证明在支撑它。为了解决中心化偏差的第二个问题，我们超越了Sompolinsky和Zohar所描述的协议，并且还提供了对过时区块的奖励：过时的区块获得其基本奖励的87.5％，并且包含过时区块的侄区块接收剩余的12.5％。但是，交易费不会给予叔区块。

以太坊实现了GHOST的简化版本，只有七个层级。具体来说，定义如下：

区块必须指定父区块，并且必须指定0个或更多叔区块

区块B中包含的叔区块必须具有以下属性：

它必须是B的第k代祖先的直接子区块，其中2 <= k <= 7。

它不能是B的祖先

叔区块必须是有效的区块头，但不需要是先前验证的甚至有效的区块

叔区块必须与先前区块中包含的所有叔区块以及同一区块中包含的所有其他叔区块不同（非双重包含）

对于区块B的每个叔区块U，B的矿工获得额外3.125％的coinbase奖励，U的矿工获得93.75％的标准coinbase奖励。

由于两个原因，这种包含最多7代的叔区块的有限版本的GHOST被使用。首先，无限的GHOST会在计算给定区块的哪些叔区块有效时包含太多复杂性。其次，在以太坊中使用的无限GHOST补偿消除了矿工在主链而不是公共攻击者链上挖矿的动机。

费用

由于发布到区块链中的每个交易都在网络上强加了需要下载和验证它的成本，因此需要一些监管机制，通常涉及交易费用，以防止滥用。在比特币中使用的默认方法是纯粹自愿收费，依靠矿工担任守门人并设定动态最小值。这种方法在比特币社区得到了非常好的支持，特别是因为它是“基于市场的”，允许矿工和交易发送者之间的供需决定价格。然而，这种推理过程的问题在于交易处理不是市场;虽然将交易处理解释为矿工向发送方提供的服务具有直观的吸引力，但实际上矿工所包含的每笔交易都需要由网络中的每个节点处理，因此绝大部分交易处理的成本都由很多第三方承担，而不是由决定是否包括它的矿工承担。因此，很可能发生公地悲剧问题。

然而，由于在市场机制中发现了这个缺陷，当给出一个特定的不准确的简化假设时，神奇地取消了它自己。论点如下。假设：

一笔交易导致k个操作，向任何包含它的矿工提供奖励kR，其中R由发送者设置，并且k和R预先（大致）对矿工可见。

一个操作对任何节点的处理成本为C（假设所有节点具有相同的效率）

有N个挖矿节点，每个节点具有完全相同的处理能力（即总数的1/N）

不存在不挖矿的完整节点。

如果预期奖励大于成本，矿工将愿意处理交易。因此，预期奖励是kR/N，因为矿工具有处理下一个区块的1/N的机会，并且矿工的处理成本仅为kC。因此，矿工将包括kR/N > kC或R > NC的交易。注意，R是发送方提供的每个操作的费用，因此是发送方从交易中获得的利益的下限，NC是处理一个操作的整个网络的成本。因此，矿工有动力仅包括总功利利益超过成本的交易。

但是，现实与这些假设有几个重要的偏差：

由于额外的验证时间延迟了区块传播，因此增加了区块过时的可能性，因此矿工确实支付了比其他验证节点更高的处理交易成本。

确实存在不挖掘的完整节点。

在现实中，矿力（挖矿权）分配可能是极端不平等的。

确实存在投机者，政治敌人和疯子，他们的utility函数可能对网络造成损害，并且他们可以巧妙地建立合约，其成本远低于其他验证节点支付的成本。

(1)为矿工提供包含较少交易的趋势(2)增加NC；因此，这两种效应至少部分地相互抵消了。How?(3)和(4)是主要问题；为了解决它们，我们只需设置一个浮动上限：没有区块可以比BLK_LIMIT_FACTOR乘以长期指数移动平均线更多的操作。特别是：

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR和EMA_FACTOR是暂时设置为65536和1.5的常量，但在进一步分析后可能会更改。

在比特币中存在另一个阻碍大区块大小的因素：大块的区块将需要更长的时间来传播，因此具有更高的成为过时区块的可能性。在以太坊中，消耗很高gas的区块也可能需要更长的时间来传播，因为它们在物理上更大，并且因为它们需要更长的时间来处理交易状态转换以进行验证。这种延迟抑制因素在比特币中是一个重要的考虑因素，但由于GHOST协议，在以太坊中则不那么重要;因此，依靠受监管的区块限制可提供更稳定的基线。

计算和图灵完备性

重要的一点是，以太坊虚拟机是图灵完备的;这意味着EVM代码可以编码任何可以实现的计算，包括无限循环。 EVM代码允许以两种方式循环。首先，有一个JUMP指令允许程序跳回到代码中的前一个位置，一个JUMPI指令执行条件跳转，允许像while x < 27: x = x * 2这样的语句.其次，合约可以调用其他合约，可能允许循环递归。这自然会导致一个问题：恶意用户是否可以通过强制矿工和所有完整节点进入无限循环来关闭它们？出现这个问题是因为计算机科学中存在一个被称为暂停问题的问题：在一般情况下，没有办法知道某个程序是否会停止。

如状态转换章节所述，我们的解决方案通过要求交易设置允许的最大计算步骤数来工作，如果执行需要更长的时间，则计算被回滚，但仍然支付费用。消息以相同的方式工作。为了展示我们解决方案背后的动机，请考虑以下示例：

攻击者创建一个运行无限循环的合约，然后将一个激活该循环的交易发送给矿工。矿工将处理交易，运行无限循环，并等待它消耗完gas。即使执行耗尽gas并且中途停止，交易仍然有效，并且矿工仍然会对每个计算步骤向攻击者索取费用。

攻击者创建了一个非常长的无限循环，其目的是迫使矿工持续计算很长的时间，以至于计算结束时会有一些更多的块出现，矿工将不可能包含交易以索取费用。但是，攻击者将被要求提交STARTGAS的值，以限制执行可以采取的计算步骤的数量，因此矿工将提前知道计算将花费过多的步骤。

攻击者看到一个包含某种形式代码的合约，如send(A,contract.storage[A]); contract.storage[A] = 0，并发送一个具有足够gas的交易来运行第一步而不是第二步（比如发起取款而不让余额减少）。合约作者不需要担心防止此类攻击，因为如果执行在中途停止，更改则会被回滚。

金融合约的工作原理是获取九个专有数据供应的中位数，以便将风险降至最低。攻击者接管其中一个数据源，它可以通过DAO章节中描述的变量地址调用（variable-address-call）机制进行修改，并将其转换为运行无限循环，从而试图强制从金融合约提取资金以耗尽gas的任何尝试。但是，金融合约可以对消息设置gas限制以防止出现此问题。

图灵完备性的替代方法是图灵不完备性，其中JUMP和JUMPI指令不存在，并且在任何给定时间只允许每个合约的一个副本在调用堆栈中存在。有了这个系统，所描述的费用系统和我们解决方案有效性的不确定性可能就没有必要了，因为执行合约的成本将受到其规模的限制。此外，图灵不完备性甚至不是那么大的限制;在我们内部构思的所有合约示例中，到目前为止只有一个需要一个循环，这个循环甚至可以通过重复26次一行代码来删除该循环。鉴于图灵完备性的严重影响以及有限的收益，为什么不简单地使用图灵不完备的语言呢？然而，实际上，图灵不完备性远非一个解决问题的巧妙方法。要了解原因，请考虑以下合约：

C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

...

C49: call(C50); call(C50);

C50: (run one step of a program and record the change in storage)

现在，向A发送一笔交易。因此，在51个交易中，我们有一个合同，需要250个计算步骤。矿工可以通过为每个合约维护一个值来指定它可以采取的最大计算步数来提前检测这种逻辑炸弹，并为递归调用其他合约的合约计算这个值，但这需要矿工禁止创建其他合约的合约（因为上述所有26个合约的创建和执行可以很容易地归成一个合约）。另一个问题是消息的地址字段是变量，因此通常甚至不可能知道给定合约将提前调用哪些其他合约。因此，总而言之，我们得出一个令人惊讶的结论：图灵完备性非常容易管理，并且非图灵完备性同样令人惊讶地难以管理，除非采取完全相同的控制措施 - 但在这种情况下让协议成为图灵完备的有何不可呢？

货币和发行

以太坊网络包括其自己的内置货币ether，其双重目的是提供主要流动性层，以实现各种类型的数字资产之间的有效交换，更重要的是，提供支付交易费用的机制。为了方便和避免未来的争论（参见比特币当前的mBTC / uBTC / satoshi辩论），面额将被预先标记：

1: wei

1012: szabo

1015: finney

1018: ether

这应该被视为“美元”和“美分”或“BTC”和“satoshi”概念的扩展版本。在不久的将来，我们希望“ether”用于普通交易，“finney”用于微交易，“szabo”和“wei”用于围绕费用和协议实现的技术讨论;剩余的面额可能会在以后变得有用，此时不应包括在客户端中。

发行模式如下：

Ether将以每个BTC 1000-2000ether的价格以货币销售形式发售，该机制旨在为以太坊组织提供资金，并支付其他平台（如Mastercoin和NXT）成功使用的开发费用。较早的买家将受益于更大的折扣。从销售中获得的BTC将完全用于向开发工程师支付工资和奖金，并投资于以太坊和加密货币生态系统中的各种营利性和非营利性项目。

销售总额的0.099倍（60102216 ETH）将分配给组织，以补偿早期贡献者并支付在创世区块之前ETH计价的费用。

售出总额的0.099倍将作为长期储备。

在那个时间点之后，销售总额的0.26倍会被每年永久分配给矿工。

Group

At launch

After 1 year

After 5 years

Currency units

1.198X

1.458X

2.498X

Purchasers

83.5%

68.6%

40.0%

Reserve spent pre-sale

8.26%

6.79%

3.96%

Reserve used post-sale

8.26%

6.79%

3.96%

Miners

0%

17.8%

52.0%

Long-Term Supply Growth Rate (percent)

尽管线性货币发行，就像比特币一样随着时间的推移，供应增长率趋于零

上述模型中的两个主要选择是：（1）捐赠池的存在和规模，以及（2）存在永久增长的线性供应，而不是像比特币那样的上限供应。捐赠池的理由如下。如果捐赠池不存在，并且线性发行减少到0.217倍以提供相同的通货膨胀率，那么ether的总量将减少16.5％，因此每个单位的价值将增加19.8％。因此，在均衡状态下，19.8%的ether会在销售中被购买，所以每个单位将再次像以前一样有价值。然后组织也将拥有1.198倍的BTC，可以认为它被分成两个片段：原始BTC和额外的0.198倍。因此，这种情况完全等同于捐赠，但有一个重要的区别：组织纯粹持有BTC，因此没有动力或被激励去支持ether的单位价值。

永久线性供应增长模型降低了某些人认为的在比特币中财富过度集中的风险，并为生活在当前和未来时代的个人提供了获得货币单位的公平机会，同时保留了获取和持有ether的强大动力，因为随着时间的推移，“供给增长率”百分比仍然趋于零。我们还认为，由于粗心，死亡等原因，币总会随着时间的流逝而丢失，而币丢失可以模拟为每年总供应量的百分比，因此流通中的货币总供应量最终将稳定在一个等于年度发行量除以损失率的值（例如，损失率为1％，一旦供应量达到26倍，那么0.26倍将被挖矿，并且每年损失0.26倍，形成均衡状态）。

请注意，在未来，以太坊很可能会转向使用权益证明模型以确保安全性，将发行需求降低到每年0到0.05倍之间。如果以太坊组织丢失资金或因任何其他原因消失，我们将公开“社会合约”：任何人都有权创建未来的以太坊候选版本，唯一的条件是ether的数量必须是最多等于60102216 * (1.198 + 0.26 * n)，其中n是创世区块后的年数。创作者可以自由地面向大众销售或分配一些或者所有权益证明驱动的供应扩张和最大允许供应扩张之间的差值，以支付开发费用。不符合社会合约的候选人升级可以无可非议地被分叉为合规版本。

挖矿中心化

比特币挖矿算法的工作原理是让矿工一次又一次地对区块头的细微修改版本计算SHA256数百万次，直到最终一个节点出现一个哈希小于目标的版本（目前大约为2192）。但是，这种挖矿算法容易受到两种集中形式的影响。首先，挖矿生态系统已经由ASIC（专用集成电路），专门设计的计算机芯片（使得对于比特币挖矿的特定任务的效率提高了数千倍）所控制和主导。这意味着比特币挖矿不再是高度去中心化的，也不再是平等的追求，二是需要数百万美元的资金才能有效参与。其次，大多数比特币矿工实际上并不在本地进行区块验证;相反，他们依靠集中式矿池来提供区块头。这个问题可能更糟糕：截至撰写本文时，排名前三的矿池间接控制着比特币网络中大约50％的处理能力，尽管当一个矿池或者矿池联盟试图发起51%攻击时矿工可以切换到其他矿池这一事实可以减轻这种影响。

目前以太坊的意图是使用一种挖矿算法，其中矿工需要从状态中获取随机数据，从区块链中的最后N个区块计算一些随机选择的交易，并返回结果的哈希。这有两个重要的好处。首先，以太坊合约可以包括任何类型的计算，因此以太坊ASIC本质上是用于一般计算的ASIC - 比如，一个更好的CPU。其次，挖矿需要访问整个区块链，迫使矿工存储整个区块链，并至少能够验证每笔交易。这消除了对集中式矿池的需求;尽管矿池仍然可以起到平衡奖励分配随机性的合法作用，但是这个功能可以被没有中央控制的点对点矿池同样很好使用。

此模型未经测试，在使用合约执行作为挖矿算法时，在避免某些聪明的优化时可能会遇到困难。然而，该算法的一个特别有趣的特点是，它允许任何人通过在区块链中引入大量专门用于阻碍某些ASIC的合约来“poison the well”。 ASIC制造商有经济刺激，所以使用这种技巧相互攻击。因此，我们正在开发的解决方案最终是一种适应性的经济人类解决方案，而不是纯粹的技术解决方案。

可扩展性

关于以太坊的一个普遍关注点是可扩展性问题。与比特币一样，以太坊也存在缺陷，即每个交易都需要由网络中的每个节点处理。当前比特币区块链的大小约为15 GB，每小时增长约1 MB。如果比特币网络每秒处理Visa的2000笔交易，它将每3秒增加1 MB（每小时1 GB，每年8 TB）。以太坊很可能会遭遇类似的增长模式，甚至可能更糟糕，因为在以太坊区块链之上会有许多应用程序，而不是像比特币那样只是一种货币，但由于以太坊完整节点仅仅需要存储状态而不是整个区块链历史这一事实，这个问题可以得到改善。

如此大的区块链大小（体量）的问题是中心化风险。如果区块链大小增加到100 TB，则可能的情况是只有极少数大型企业会运行完整节点，所有常规用户都使用轻量SPV节点。在这种情况下，可能出现的问题是所有完整节点可以勾结在一起并且都同意以某种有利可图的方式作弊（例如，改变区块奖励，给自己BTC）。轻量节点无法立即检测到这一点。当然，至少有一个诚实的完整节点可能存在，几个小时后，有关欺诈的信息会通过像Reddit这样的渠道流出，但那时为时已晚：这将由普通用户组织起来努力将给定的区块列入黑名单，这是一个巨大且可能不可行的协调问题，其规模与取得成功的51％攻击类似。在比特币的情况下，这是一个目前存在的问题，但存在一个Peter Todd建议采用的区块链修改可以缓解这一问题。

在短期内，以太坊将使用另外两种策略来应对这一问题。首先，由于基于区块链的挖矿算法，至少每个矿工都将被强制为完整节点，从而在完整节点数量上创建下限。其次，更重要的是，我们将在处理每笔交易后在区块链中包含一个中间状态树根。即使区块验证是中心化的，只要存在一个诚实的验证节点，就可以通过验证协议规避中心化问题。如果矿工发布一个无效区块，则该区块必须格式错误，或者状态S[n]不正确。由于已知S[0]是正确的，因此必然存在第一个不正确的状态S[i]，并且S[i-1]是正确的。验证节点将提供索引i，以及由需要处理APPLY(S[i-1],TX[i]) -> S[i]的Patricia树节点的子集组成的“无效证明”。节点将能够使用那些Patricia节点来运行该部分计算，并且看到生成的S[i]与提供的S[i]不匹配。

另一个更复杂的攻击将涉及恶意矿工发布不完整的区块，因此甚至不存在完整信息来确定区块是否有效。对此的解决方案是质询 - 响应协议：验证节点以目标交易索引的形式发出“质询”，并且在接收节点时，轻节点将区块视为不可信，直到另一个节点（无论是矿工还是其他验证者）提供Patricia节点的一个子集作为有效性的证明。

结论

以太坊协议最初被设想为加密货币的升级版本，通过高度通用的编程语言提供诸如链上托管，取款限制，金融合约，赌博市场等高级功能。以太坊协议不会直接“支持”任何应用程序，但是图灵完备编程语言的存在意味着理论上可以为任何交易类型或应用程序创建任意合约。然而，以太坊更有趣的是，以太坊协议远远超出了货币。围绕去中心化文件存储，去中心化计算和去中心化预测市场的协议，以及其他许多此类概念，有可能大幅提高计算机行业的效率，并通过首次增加了一个经济层而对其他点对点协议提供大量的推动。最后，还有大量与金钱无关的应用程序。

由以太坊协议实现的任意状态转换功能的概念提供了具有独特潜力的平台;而且，对于数据存储，赌博或金融领域的特定应用程序而言，以太网不是一个封闭式的单一用途协议，而是设计为开放式的，我们相信在未来的几年中，对于大量的金融和非金融协议，以太坊非常适合用作基础服务层。

备注和延伸阅读

备注

一个富有经验的读者可能会注意到，实际上一个比特币地址是椭圆曲线公钥的哈希，而不是公钥本身。但是，事实上，将pubkey哈希称为公钥本身是完全合法的加密术语。这是因为比特币的加密可以被认为是一种自定义数字签名算法，其中公钥由ECC pubkey的哈希组成，签名由与ECC签名连接的ECC pubkey组成，验证算法包括根据作为公钥提供的ECC pubkey哈希检查签名中的ECC pubkey，然后根据ECC pubkey验证ECC签名。

从技术上讲，前11个区块的中位数。

以太坊协议应该尽可能简单，但可能需要具有相当高的复杂度，例如扩展，将存储成本内部化，带宽和I / O，以确保安全性，隐私性，透明性等。在需要复杂性的地方，文档应尽可能清晰，简洁和保持最新，以便完全未受过以太坊教育的人可以学习并成为专家。

请参阅以太坊虚拟机的黄皮书（作为从头开始构建以太坊客户端的规范和参考），同时在以太坊wiki中也有许多主题，例如分片开发，核心开发，dapp开发，研究，Casper R＆D和网络协议。对于研究和未来可能的实现，有ethresear.ch。

另一种表达方式是抽象。最新的路线图计划抽象执行，允许执行引擎不一定必须遵循一个规范，但是例如它可以针对特定应用程序以及分片进行定制。 （这种执行引擎的异构性没有在路线图中明确说明。还有被Vlad Zamfir概念化了的异构分片。）

在内部，2和“CHARLIE”都是数字，后者是big-endian base 256表示。数字可以是至少0且至多2256-1。

延伸阅读

Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/

Smart property: https://en.bitcoin.it/wiki/Smart_Property

Smart contracts: https://en.bitcoin.it/wiki/Contracts

B-money: http://www.weidai.com/bmoney.txt

Reusable proofs of work: http://www.finney.org/~hal/rpow/

Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html

Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf

Namecoin: https://namecoin.org/

Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle

Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec

Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/

Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification

Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree

Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree

GHOST: https://eprint.iacr.org/2013/881.pdf

StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html

Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y

Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP

Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree

Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/

有关白皮书的历史，请参阅https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md#historical-sources-of-the-white-paper

注：此中文翻译文档是基于以太坊白皮书2018/8/22的版本6e97c9c翻译的。

翻译by林科（Corey Lin），转载请注明出处。如想了解更多内容，请关注微信公众号“Corey区块链技术分享”。

| Deutsch

| English

| Español

| Français

| 한국어

| Italiano

| Portuguese

| Română

| العربية

| فارسی

| 中文(繁体)

| 中文(简体)

| 日本語

Toggle tagle of contents

Pages 201

Home

5 strategies of contribution

[Arabic] Home in Arabic

[Arabic] العربية

[Arabic] مرحبا في صفحة الويكي للأثيريوم

[Chinese Simplified] Ethash Design Rationale中文翻译

[Chinese Simplified] Ethash中文翻译

[Chinese Simplified] Ethereum 白皮书中文版

一个下一代智能合约和去中心化应用平台

比特币和现有概念的介绍

历史

作为一种状态转移系统的比特币

挖矿

Merkle树

替代的区块链应用程序

脚本

以太坊

哲学

以太坊账户

消息和交易

消息

以太坊状态转换函数

代码执行

区块链和挖矿

应用

令牌系统

金融衍生品和稳定价值货币

身份和声誉系统

去中心化文件存储

去中心化自治组织

其他应用

杂项和担忧

修改的GHOST实现

费用

计算和图灵完备性

货币和发行

挖矿中心化

可扩展性

结论

备注和延伸阅读

备注

延伸阅读

[Chinese] Design Rationale 设计原理

[Chinese] Ethereum TOC

[Chinese] Ethereum 白皮書

[Chinese]ÐΞVp2p Wire Protocol中文翻译

[English] Patricia Tree

[English] RLP

[French] Ethereum TOC

[German] Clearinghaus

[German] Ethereum TOC

[German] RLP

[German] White Paper

[Indonesian] Ethereum akan naik karena teknologi terus dikembangkan dan ditingkatkan

[Italian] Ethereum TOC

[Italian] Impostare il proprio ambiente di sviluppo Ethereum

[Italian] Introduzione allo sviluppo su Ethereum

[Italian] Libro Bianco

[Japanese] Ethereum Development Tutorial

[Japanese] Liscence

[Japanese] Cryptocurrency Current Problems

[Japanese] Design Rationale

[Japanese] Ethereum 2.0 Phase 0 The Beacon Chain

[Japanese] Ethereum TOC

[Japanese] Ethereum Wire Protocol

[Japanese] HPOC_2015

[Japanese] Javascript API

[Japanese] libp2p whitepaper

[Japanese] Meteorを使ってDappを作ろう

[Japanese] Patricia Tree

[Japanese] Proof of Stake FAQs

[Japanese] RLP

[Japanese] Whisper

[Japanese] Whisper PoC 2 Protocol Spec

[Japanese] White Paper

[Japanese] ÐΞVp2p Wire Protocol

[Korean] White Paper

[Persian] Ethereum TOC

[Persian] White Paper

[Portuguese] White Paper

[Romanian] Cuprins

[Romanian] Limbajul de programare Serpent

[Romanian] Patricia Tree

[Romanian] RLP

[Romanian] White Paper

[Romanian] Wire Protocol

[Russian] Руководство по Solidity

[Simplified Chinese] Ethereum TOC

[Spanish] Byzantium Hard Fork changes

[Spanish] Ethereum TOC

[Spanish] Glossary

[Spanish] Home

[Spanish] Releases

[Spanish] White Paper.md

[Spanish]Proof of Stake FAQ

[Spanish]Sharding FAQ

[中文] RLP

[中文] Serpent指南

[中文] 以太坊Wiki目录

[中文] 以太坊开发计划

[中文] 以太坊术语表

[中文] 以太坊白皮书

[中文] 网络状态

[日本語] Proof of Stake FAQ

Adaptive Message IDs

Adaptive Peer Time

Alternative blockchains, randomness, economics, and other research topics

Bad Block Reporting

Bad Chain Canary

Benchmarks

Blockchain import and export instructions

Brain Wallet

Bugs

Byzantium Hard Fork changes

c value class SwitchParameter

Casper Proof of Stake compendium

CC0 license

Chain Fibers Redux

Client Version Strings

Clients

Clients, tools, dapp browsers, wallets and other projects

Consensus Datastructures

Consortium Chain Development

Contract Metadata Docs (NatSpec, ABI)

Dagger Hashimoto

Dapp Developer Resources

Dapp using Meteor

Decentralized apps (dapps)

Default Extra Data Standard

Design Rationale

Deterministic_Wallet_Spec

Distributed Preimage Archive

enode url format

ERC 735: Claim Holder Registry vs. in contract

Ethash

Ethash C API

Ethash DAG

Ethash DAG Disk Storage Format

Ethash Design Rationale

Ethereum Chain Spec Format

Ethereum Contract ABI

Ethereum Development Tutorial

Ethereum Introduction

Ethereum Natural Specification Format

Ethereum Sharding Research Compendium

Ethereum Virtual Machine (EVM) Awesome List

Ethereum White Paper

Ethereum Wire Protocol

EWasm compendium

eπ Programme

FAQ

FAQs

Geth Dapp loading proposal

Getting Ether

Getting Ether: further info

Gitter Channels

Glossary

Governance compendium

Grants and funding sources

HPOC_2015

ICAP: Inter exchange Client Address Protocol

Inter exchange Client Address Protocol (ICAP)

IPv6

JavaScript API

JSON RPC

JSON RPC Error Codes Improvement Proposal

Kademlia Peer Selection

libp2p Whitepaper

Licensing

Light client protocol

List of other Ethereum wikis and documentation

Major issues resulting in lost or stuck funds

Middleware and Dapp Project Ideas

Mining

Mist Troubleshooting Guide

Mix Features

Mix improvement proposal

Mix: The DApp IDE

Morden

Natspec Example

Network Status

newBlockFilter Improvement Proposal

Node discovery protocol

Outdated: Poll for token proposal EIP 20

Outdated: Proposal: Reversion Notification

Outdated: Proposal: Transaction Proxy Hooks

Parallel Block Downloads

Patricia Tree

Problems

Proof of Stake FAQ

Proof of Stake FAQs

R&D

Registrar ABI

Relay projects

RLP

Safety

Scaling projects and proposals and other crypto infrastructure projects

Security Categorization

Security Issue Process

Serpent [DEPRECATED]

Sharding FAQ

Sharding FAQs

Sharding introduction and implementations

Sharding introduction and R&D

Sharding introduction R&D compendium

Sharding roadmap

Solidity

Solidity Changelog

Solidity Collections

Solidity Features

Solidity Glossary

Solidity standard library

Solidity Tutorial

Solidity, Docs and ABI

Standardized_Contract_APIs

Storage projects

Subtleties

Swarm Hash

The Solidity Programming Language

Topics that span across research categories: alternative blockchains, randomness, economics, etc.

URL Hint Protocol

Useful Ðapp Patterns

web.js 0.9

Web3 Secret Storage Definition

What is Ethereum

Whisper

Whisper Overview

Whisper PoC 2 Protocol Spec

Whisper PoC 2 Wire Protocol

Whisper Wire Protocol

White Paper

Wiki: ethresear.ch Sharding Compendium

Wishlist

ÐApp Development

ÐΞVp2p Wire Protocol

Show 186 more pages…

Basics

Home

Ethereum Whitepaper

Ethereum Introduction

Uses: DAOs and dapps

Getting Ether

FAQs

Design Rationale

EVM intro: Ethereum Yellow Paper, Beige Paper and Py-EVM.

Wiki for (old) website (still a good introduction)

Glossary

R&D

Sharding introduction & R&D Compendium, FAQs & roadmap

Casper Proof-of-Stake compendium and FAQs.

Alternative blockchains, randomness, economics, and other research topics

Hard Problems of Cryptocurrency

Governance

Ethereum Virtual Machine (EVM)

Ethereum clients, tools, wallets, dapp browsers and other projects

ÐApp Development

Infrastructure

Chain Spec Format

Inter-exchange Client Address Protocol

URL Hint Protocol

Network Status

Mining

Licensing

Consortium Chain Development

Networking

Ethereum Wire Protocol

libp2p

devp2p Specifications

devp2p Whitepaper (old)

Ethereum Technologies

RLP Encoding

Patricia Tree

Web3 Secret Storage

Light client protocol

Subtleties

Solidity Documentation

NatSpec Format

Contract ABI

Bad Block Reporting

Bad Chain Canary

Ethash/Dashimoto

Ethash

Ethash Yellow Paper appendix

Ethash C API

Ethash DAG

Whisper

Whisper Proposal

Whisper Overview

PoC-1 Wire protocol

PoC-2 Wire protocol

PoC-2 Whitepaper

0x927c0E368722206312D243417dA9797424b56434

Clone this wiki locally

Footer

© 2024 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

以太坊白皮书中文翻译加详解【全文汇总版-1】 - 知乎

以太坊白皮书中文翻译加详解【全文汇总版-1】 - 知乎首发于区块链是什么鬼切换模式写文章登录/注册以太坊白皮书中文翻译加详解【全文汇总版-1】黄马褂1、【标题】标题：一个下一代的智能合约和去中心化应用平台。首先，以太坊是next generation，下一代，那么上一代是谁，当然是Bitcoin比特币。以太坊自称下一代，于是人们把它称为区块链2.0，而比特币就成了区块链1.0。然后，以太坊是一个platform，是一个平台，Vitalik把以太坊定义成一个平台，而没有定义成一个application应用，或者像中本聪那样，定义成一个system系统。平台是干嘛的，在互联网领域，平台泛指平台指进行某项工作所需要的环境或条件，也就是我们常说的，计算机硬件或软件的操作环境、运行环境，是承载各种软件或者应用的基础设施。比如，操作系统windows是个平台，工程师在windows上面开发出各种应用，比如QQ，然后我们终端用户，也就是C端用户，在windows平台上来使用QQ。同样的，ios是苹果手机的系统平台，程序员在ios上开发出各种app，比如手机百度、手机淘宝、微信，然后我们用户在苹果手机上使用这些app。而以太坊做的，就是类似windows和ios这样的平台。那以太坊这个平台拿来干嘛的？拿来跑smart contract和decentralized application，即智能合约和去中心化应用。smart contract智能合约是什么？首先看合约是什么？合约，即合同，《合同法》定义是，双方或多方当事人（自然人或法人）关于建立、变更、消灭民事法律关系的协议。合同有时也泛指发生一定权利、义务的协议，又称契约，如买卖合同、师徒合同、劳动合同以及工厂与车间订立的承包合同等。也就是说，平等的合同主体经过意思表示一致，达成了某种受法律保护的权利义务关系。合约怎么又“智能”了呢？传统的合约关系，依靠的是国家法律强制力的保障，即当其中一方违约时，有第三方权威机构比如法院、仲裁机构，对违约方按照合约约定进行制裁和惩罚。而“智能”，就体现在，合约无需依靠权威第三方来担保和执行，而是依据代码和程序的预先设定，在某种行为发生或者某些条件达成时，由程序或系统自动执行合约约定。举个最简单的例子，我把房子抵押给你，向你借了一笔款，结果借款到期我不还，你要收我的房子的产权，但我就是老赖。你怎么办？传统办法是，你向法院提起诉讼，由法院来强制执行。但这时我玩起人间蒸发呢？这事儿会不会永远拖下去呢？而智能合约智能的地方，就在于，我向你借款时，就把我的抵押物即房子所对应的产权归属预先通过程序设置好，当达到我逾期不还钱这个条件时，程序就自动把我房子的产权划到你名下，我们去房管局查房产证，就发现妈蛋这房子已经写上了你的名字，就不是我的了，这就不需要法院等第三方权威机构来介入了。这里，我们看，执行这种智能合约，需要有先决条件，比如，第一，我的房子对应的产权要在这个系统这个平台上通过数字资产或者其他形式表现出来。第二，条件的预设，必须是双方意思表示一致的，而不是某一方单方面去预设某些条件而对方不知情。第三，我的产权对应的数字资产或其他形式的资产，上链时就必须准确无误。因为不可篡改是区块链的核心特征，要是一开始数据就错了，后面又改不了，怎么办。decentralized application去中心化应用是什么？decentralized application简称Dapp。我们知道app是各种应用，微信、QQ、支付宝什么的，我们电脑上、手机上各个小图标，就是各种app。这些app又称中心化应用，中心化，就是这些app是某个公司开发的，受控制与某个公司的。公司，就是中心。那Dapp呢？举个例子秒懂！把微信app的程序写在区块链上，开源，让全世界参与的节点共同来维护微信所有数据，腾讯对微信没有了控制权，任何人也别想对微信有控制权，微信社区完全开放、自治，微信所有数据加密后存在区块链上，整个微信社区中流通着wcc[WeChatCoin，微信币]……之前市面上的区块链DAPP主要有游戏和挖矿等。比如2017年出现的以太猫CyptoKitties，之后又出现的蹭热度的百度莱茨狗、小米加密兔等区块链宠物游戏。那Dapp究竟有什么用？这不全世界最聪明的码农都还在探索嘛，别急！2、【前言】当中本聪在2009年一月第一次启动比特币区块链时，他同时引入了两个激进的未经测试的概念。第一个是“比特币”，一种去中心化的点对点在线货币，这种货币能够维持一种价值，在什么条件下维持价值呢，在没有任何支持，本身又没有任何固有价值，又没有中心化发行方的情况下。就是说，比特币生产出来时本身不具备任何价值，也没有中央银行来发行它，也没有任何权威或者中心来给它背书，但它就能维持一种价值。这种价值当然不是指它的固有价值，比如黄金，它是贵金属，开采出来它就有固有价值。而这种比特币这种价值是指它的使用价值，流通价值。当目前为止，“比特币”作为一种现金单位，已经吸引了大量的公众注意，在哪些方面引人注意呢，在两方面都引人注意，一，在政治层面上，这种现金没有中央银行发行；二，它的价格巨幅波动。但是，[与比特币]同样重要的是，中本聪伟大实验的另一方面：即，基于工作量证明的区块链让人们对交易顺序达成共识，这样一个概念。作为一种应用，比特币可以被描述为一种先申请[first-to-file]系统：如果一个人有50个比特币，同时发送这50个比特币给A和B，那么只有第一笔得到确认的交易会被处理。没有一种固有的方法来决定两笔交易哪一笔先到，这个问题阻碍了去中心化数字货币发展很多年。中本聪的区块链是第一个可信的去中心化解决方案。那么现在，注意力迅速开始转向比特币技术的第二部分，即区块链概念如何被用于货币之外的事情。通常被提及的应用，包括使用区块链的链上数字资产来代表定制货币和金融工具 ("颜色币")，相关物理设备("智能资产")的所有权，非同质资产例如域名 ("域名币")，以及更多先进的应用例如去中心化交易所、金融衍生品、点对点赌博和区块链的链上身份和信誉系统。看懂木有啊？梳理一下吧。以下这些，都是Vitalik说的，经常提到的应用：1、区块链的链上数字资产来代表定制货币和金融工具 ("颜色币")这是神马玩意儿？这是指，可以和实物相联系的币被称为彩色币。比特币脚本语言允许存储少量的metadata(信息)，这段信息可以用来代表现实生活中的实物，也就是说现实生活中的实物和区块链上的彩色币联系起来。大体是在比特币协定之上叠加新的协定，有点像互联网协议栈中，HTTP叠加于TCP/IP之上的方式。比如，彩色币发行者确定一个给定的交易输出 H:i(H为交易的杂凑值，i为输出序号)，代表一种特定的资产，并且发布一个所谓的“色彩定义”，就是指定该交易输出代表什么(例如H:i中的1聪 = 1盎司可由http://amagimetals.com兑付的黄金)。然后用户在彩色币用户端装色彩定义档。当该“色彩定义”首次发布的时候，输出H:i是拥有该彩色的唯一交易输出。彩色币这部分在白皮书下面的History的Alternative Blockchain Applications部分会再次提到。2、相关物理设备("智能资产")的所有权这就是智能合约里面对应的实体物理资产的产权3、非同质资产例如域名 ("域名币")稀缺的、难以复制的、独一无二的、有唯一性的、用户享有绝对所有权的资产4、去中心化交易所、金融衍生品、点对点赌博和区块链的链上身份和信誉系统另一个咨询到的重要领域是“智能合约”——能够根据随意预先设定的规则，自动转移数字资产的系统。例如，一个人可能有一份存储合同长这样：“A每天可以提取X个单位的现金，B每天可以提取Y个单位的现金，A和B一起来的时候可以任意提取没有限制，并且A可以关闭B的提现权”。这个合约符合逻辑的扩展就是去中心化自治组织 (DAOs)——长期智能合约，这个智能合约包含这个组织的所有资产，并且将组织的规章制度编成代码。解释一下，一个去中心化的组织(DAOs)，这个组织的一切行为都是基于数字化的，组织的所有运行规则都是按代码设置执行的，组织的所有资产也都是数字资产。它实际上是一个硬编码规则体系，而那些不是DAOs的组织，虽然也是基于区块链平台，但是决策和行为可能是由持有一定数量的代币或智能合约的“股东”来制定和执行的。DAOs的一大优势在于，部署的代码和智能合约不容易被操纵或访问，这样可以最大程度地减少欺诈、作假、腐败等风险，但是如果规则需要与时俱进，或者优化升级，想要调整代码就难了，因为它的决策是通过电子方式，通过代码规则或所有成员投票来决定的。以太坊想要提供的是这样一个区块链，它内置成熟的图灵完备的编程语言，能够被用来创建“合约”，这种合约可以被用来对任意状态转换功能进行编码，从而允许用户创建以上所述的任意系统，以及许多其他的我们还没有想象到的系统，这些只需要写几行代码来实现这些逻辑就OK了。图灵，以Alan Mathison Turing阿兰·图灵（1912年6月23日－1954年6月7日）的名称命名的。阿兰·图灵是英国计算机科学家、数学家、逻辑学家、密码分析学家和理论生物学家，被视为计算机科学与人工智能之父。图灵完备，如果一门编程语言或者一个指令集，可实现图灵机模型里面全部的功能，或者说能够满足任意数据按照一定顺序计算出结果；我们就可称其具有图灵完备性。以太坊是一个图灵完备的区块链系统，虚拟机可运行智能合约，理论上能够解决所有的可计算问题。合约可以被用来对任意状态转换功能进行编码之后，用户才可以创建出以上所述的各种系统。3、【历史】去中心化数字货币的概念，以及像财产登记之类的替代应用，已经被提出来很多年了。1980年代和1990年代的匿名电子现金协议，很大程度依赖一种叫乔姆盲签名的密码学原语，这种匿名电子现金协议为货币提供了高度的隐私性，但是这种协议没能大规模地应用起来，因为它依赖一个中心化的媒介。盲签名发布消息人先将消息盲化，让签名人对盲化的消息进行签名，最后，消息接收人对签字除去盲因子，得到签名者关于原消息的签名。盲签名就是接收人在不让签名人获取所签署消息具体内容的情况下，采取的一种特殊的数字签名技术。签名人对其所签署的消息是不可见的，即签名人不知道他所签署消息的具体内容，而签名消息也不可追踪，即当签名消息被公布后，签名人无法知道这是他哪次签署的。打个简单的比方，A要寄一封信，封在信封里，但是要让B在信上签名，又不要B看见内容。怎么办？在信封里同时加入一张复写纸，于是B在信封上签名，信封里面的信上就同时印下了B的签名，这时B既没有看见信的内容，同时又在信上签了名。另一点，A寄了很多信，都有B的盲签名，当公布出其中一封信时，B也不知道这是他哪次签的名。[翻译注意：1、provided指的是e-cash protocols provided，不是指cryptographic primitive provided或者Chaumian blinding provided，2、mostly reliant on a cryptographic primitive known as Chaumian blinding这句话只是插入语，修饰一下anonymous e-cash protocols，真正的谓语是provided。这里网上有的翻译有点小错误]1998年，Wei Dai的b-money第一次提议了通过解决计算难题和去中心化共识来创造货币的思想，但是这个提议在细节上还有缺陷，即去中心化共识如何去实施。2005年，芬尼（Hal Finney）介绍了“可重复使用的工作量证明”这一概念，即一个采用了两种方案的系统，哪两种方案？1、b-money的理念；2、亚当贝克（Adam Back）的通过有计算难度的哈希现金难题来创造加密货币的概念。但是[芬尼的这个概念]还是不够理想，因为它依赖可信的计算来支持。Wei Dai的b-money和亚当贝克（Adam Back）的Hashcash在比特币白皮书翻译与详解里面都有，不累述。因为货币是一种先申请应用，[上一篇说了，first-to-file先申请是指，假如如果一个人有50BTC，并且同时向A和B发送这50BTC，只有被首先被确认的那笔交易才会有效]，那么这种先申请应用，交易顺序通常就至关重要，去中心化货币就需要解决达成去中心共识的问题。比特币之前的货币协议遇到的主要障碍是，尽管多年以来已经有大量的关于创造安全的拜占庭容错多方共识系统的研究，但是所有的协议都只解决了部分问题。Byzantine-fault-tolerant拜占庭容错拜占庭帝国进攻敌国，敌国能抵御5支拜占庭军队，拜占庭帝国派出10支军队，这10支军队任何一支单独去进攻都毫无胜算，除非有至少6支军队（一半以上）同时进攻，才能攻下敌国。10支军队分散在敌国的四周，依靠通信兵骑马相互通信来协商进攻意向及进攻时间。问题来了！他们不确定他们中是否有叛徒。叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们怎么才能保证有6支以上军队在同一时间发起进攻，从而攻下敌国？假定军队之间的通信毫无问题。没有叛徒情况下：假如一个将军A提出一个进攻提议（比如：明天上午9点进攻，你愿意加入吗？）由通信兵分别告诉其他的将军。如果幸运，A将军收到了其他5位将军以上的同意，发起进攻。如果不幸，其他将军在此时发出不同的进攻提议（比如：明天上午10点、11点进攻，你愿意加入吗？）。由于时间上的差异，不同的将军收到并认可的进攻提议可能是不一样的，这是可能出现A提议有3个支持者，B提议有4个支持者，C提议有2个支持者等等。有叛徒情况下：一个叛徒通信兵会向不同的将军发出不同的进攻提议（比如，通知A明天上午9点进攻， 通知B明天下午1点进攻）。而一个叛徒将军也可能同意多个进攻提议（即同意明天上午9点进攻又同意明天下午1点进攻）。这种发送前后不一致的进攻提议，被称为“拜占庭错误”。而能够处理拜占庭错误的这种容错性，就称为拜占庭容错，Byzantine fault tolerance，简称为BFT。这些协议假设系统里所有的参与者是已知的，并且产生安全边界，什么安全边界呢，即“如果N方参与，那么系统可以容忍N/4的恶意参与者。”也就是说，比特币出现之前的那些电子现金协议，都设置了一个多方参与多方共识的容错机制，即假设N个人参与进来，他们不是匿名的，而是已知的，那么系统最多可以容忍四分之一的人搞破坏。只要搞破坏的人不超过四分之一，那么这个系统还会运行良好。但问题是，在一个匿名的环境里，这样的安全边界对女巫攻击是脆弱的，也就是容易受到女巫攻击，因为一个单一的攻击者可以在服务器或僵尸网络上创造上千个冒充节点，然后用这些节点来单方面控制大多数份额。sybil attack 女巫攻击在P2P网络中，因为节点可以随时加入或退出，那么为了维持网络稳定，同一份数据通常需要备份到多个分布式节点上，这叫做数据冗余机制。如果网络中存在一个恶意节点，它可以通过控制多个虚假身份，然后利用这些身份控制或影响网络的其他正常节点。比如，原来需要备份到多个节点的数据被欺骗地备份到了同一个恶意节点（该恶意节点伪装成多重身份），这就是女巫攻击。女巫攻击出自Flora Rhea Schreiberie在1973年的小说《女巫》（Sybil）改编的同名电影，讲的是一个化名Sybil Dorsett的女人被诊断为分离性身份认同障碍，兼具16种人格，分裂出16种身份。botnet 僵尸网络互联网上受到黑客集中控制的一群计算机，被黑客用来发起大规模的网络攻击，比如分布式拒绝服务攻击（DDoS）、发送海量垃圾邮件等，同时黑客控制的这些计算机所保存的信息也都可被黑客随意“取用”。前面那句话就是说，在匿名环境下，比特币出现之前的那些电子现金协议，都是不可靠的，太脆弱。中本聪的创新之处在于，他的这个想法结合了两样东西，哪两样呢？1、一个非常简单的去中心化共识协议，基于节点每10分钟打包交易进入区块来创造一条持续延长的区块链；2、节点通过获取记账权来才能参与系统的工作量证明机制。当拥有大量计算能力的节点确实有了相应的更大影响力，那么你要是想搞出比全网算力加起来还大的计算能力，就比仿照100万个节点还难。也就是说，当诚实节点控制了大系统多数，那这时你想搞出更大的算力来超所有诚实节点的算力，或者说超越全网算力，这个太难了，比你搞100万个假节点还难。也就是，中本聪的创新之处在于，当诚实节点控制了大多数，系统就会安全。因为系统基于两点来运行，1、认可最长链；2、通过竞争工作量来获得记账权。（不明白仔细看比特币白皮书翻译加详解）尽管比特币区块链模型很简单粗糙，但是它已经被证明足够好，并且可能在未来五年成为全世界超过200种数字货币和协议的基石。3.1【比特币作为一种状态转换系统】从技术角度讲，比特币账本可以被看作一个状态转换系统，这个系统里面有一种“状态”，包含了：1、所有现存比特币的所有权状态，2、一个“状态转换函数”，这里面就包含了一种状态和一笔交易，然后可以输出为一种新的状态作为结果。上图，State是前一种状态，里面包含若干地址，中间是一个状态转换系统，也就是交易过程，在原地址上进行增减和签名， State'是交易后得到的原地址新状态，因为交易后账户余额有变化了。例如，在标准的银行系统内，状态就是一本资产负债表，一笔交易就意味着一个请求，即把X元钱从A转给B，同时状态转换系统在A的账户减掉X元，在B的账户增加X元。如果A的账户余额不足X元，状态转换函数就会返回错误提示。因此，正式定义如下：APPLY(S,TX) ­> S' or ERROR这个函数的意思是，检查交易的格式是否正确（即有正确数值）、签名是否有效、随机数是否与发送者账户的随机数匹配。如是，通过；如否，返回错误。而在银行系统内定义如下：APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }But:APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR当Alice和Bob的账上各有50美元时，如果Alice转给Bob20美元，返回结果为Alice账上有30美元，Bob账上有70美元。但当Alice和Bob的账上各有50美元时，如果Alice转给Bob70美元，返回结果为错误。“状态”在比特币系统中是所有已经挖出来但是没有被花费的币的集合(技术上讲，是没有花费的交易输出，unspent transaction outputs，简称UTXO) ，每一个币都有一个面值和一个所有者(由一个20字节的地址，实际上是一个密码学公钥所定义)[1]注释[1]：一个聪明的读者可能会注意到事实上比特币地址是椭圆曲线公钥的哈希，而非公钥本身。然而事实上从密码学术语角度把公钥哈希本身称为公钥是完全合理的。这是因为比特币密码学可以被认为是一种定制化的数字签名算法，公钥由椭圆曲线公钥的哈希组成，签名由椭圆曲线签名连接的椭圆曲线公钥组成，而验证算法包括用作为公钥提供的椭圆曲线公钥哈希来检查椭圆曲线公钥，以及之后的用椭圆曲线公钥来验证椭圆曲线签名。TX : Transaction（交易）TXO : TX output（交易输出）：包含一个value值和一段脚本，该脚本规定了谁有权使用这笔交易（比如需要私钥签名）。UTXO： Unspent TXO（未花费的交易输出）：只有对“尚未使用过”的交易签名才能是有效签名。数字货币无法像金属货币（比如黄金）那样，仅靠物理转移即可转移所有权，即当A将一份黄金交给B后，A必然不再拥有这份黄金。而A将一份数字货币转给（签名）B后，A仍可以把同一笔交易转给C，因为A掌握私钥，这两份签名均为有效签名，这就构成了“双花”。因此必须有一种机制来确保每笔交易只能使用一次，即只有对“尚未使用过”的交易签名才能是有效签名。UTXO，未花费的交易输出，是比特币交易生成及验证的一个核心概念。因为所有比特币交易构成了一组链式结构，每笔交易都可以回溯到一个或多个交易的输出，而这些链条的源头实际上都是挖矿奖励，末尾则是当前未花费的交易输出。所有的未花费的输出即整个比特币网络的UTXO。因为比特币每一笔新的交易的输入必须是某笔交易未花费的输出，每一笔输入同时也需要上一笔输出所对应的私钥进行签名，并且每个比特币的节点都会存储当前整个区块链上的UTXO，整个网络上的节点通过UTXO及签名算法来验证新交易的合法性。这样，节点不需要追溯历史就可以验证新交易的合法性。一笔交易包含一个或多个输入，每笔输入包含一个对现有UTXO的引用和一个由关联所有者地址的私钥产生的密码学签名。而一个或多个输出，每个输出都包含一个被加入到状态里面的新的UTXO。状态转换函数APPLY(S,TX) ­> S'可以就被大致定义为：1、对每个交易输入：i. 如果被引用的UTXO不在状态S内，返回错误；ii. 如果签名与UTXO所有者不匹配，返回错误；2、如果所有输入的UTXO面值总额比所有输出的面值总额小，返回错误；3、返回状态S当所有UTXO输入被移除及所有UTXO输出被增加时，即当不存在以上错误时，返回到新状态S'，S'里面就已经移除了所有输入的UTXO，增加了所有输出的UTXO。第一步的前一半防止交易发送者花不存在的币，后一半防止交易发送者花其他人的币，第二步来确保交易前后价值守恒。为了将此应用与支付，协议如下：假设Alice想发送11.7个币给Bob。首先，Alice将寻找一套她已有的UTXO，总数至少要等于11.7个比特币。事实上，Alice不可能刚好有11.7个比特币，如果假设她能得到的最小数量是6+4+2=12个币的话。然后她用6+4+2这三笔输入来创建一笔交易，这笔交易有两个输出。第一笔输出是11.7个币，这11.7个币在Bob的地址上，因为Bob成了这11.7个币的所有者。第二笔输出是剩下的0.3个币，“找零”，所有者还是Alice自己。3.2【挖矿】如果我们已经接入了一个可信的中心服务，这个系统可能部署起来就普普通通的，它可以轻松通过编码来实现。但是，比特币呢我们想把它建成一个去中心化的系统，因此我们需要结合状态转换系统和共识系统这两者，以此确保每个人都认可里面的交易顺序。比特币的去中心化共识处理，需要网络中的节点持续地尝试产生交易包，称之为“区块”，就是持续地把交易打包到区块中。网络大约每10分钟产生一个区块，每个区块包含一个时间戳、一个随机数、一个对上一区块的引用 (例如hash值)，和一个自上一个区块开始已经发生的全部交易的清单。如前面的图所示。这就随时间创造了一个持续的不断延长的“区块链”，它不断的更新，以此代表最新的比特币账本状态。范例中所表达的，检查一个区块是否有效的算法，如下：1、检查本区块引用的前一个区块是否已经存在且有效；2、检查本区块的时间戳晚于前一个区块的时间戳，且早于未来2小时；3、检查本区块的工作量证明是否有效4.、用S[0]表示前一个区块的最终状态假设TX是本区块的交易清单，清单里一共有n笔交易。当i=0……n-1时，对所有的i进行状态转换，S[i+1] = APPLY(S[i],TX[i]) 。如果任何又一次转换返回错误，则退出转换，返回错误提示。如果返回正确，则将S[n]视为本区块的最终状态。本质上，区块里每一笔交易必须有一个有效的状态转换。注意，状态不是用任何方式去编码进区块的，它纯粹是一个被验证它的节点所记住的抽象概念，从创世状态开始就只能被 (牢牢地) 计算出来，把每一笔交易按顺序加入每一个区块。另外，要注意矿工把交易打包进区块的顺序；如果在一个区块中有两笔交易A和B，B花了一个由A创建的UTXO，那么如果A在B前面，这个区块有效，否则区块无效。区块验证算法有趣的部分是“工作量证明”这个概念：情况是这样，对每个区块进行SHA256哈希处理，得到一个256比特的数字，这个数字必须小于一个动态调整的目标数字，写这个白皮书的时候，这个目标数字大概是2的190次方。这样做的目的是让创建区块从计算上变得困难，从而防止女巫攻击，防止攻击者按对他们有利的方式重造区块链。因为SHA256被设计为了一种完全不可预测的伪随机函数，创建一个有效区块的唯一办法，就是简单粗暴的不断试错，重复地增加随机数，来看是否新的hash值能匹配上，也就是新的hash值是否小于目标数值。当前的目标数值是2的192次方，这意味着平均要尝试2的64次方这么多次，才能产生一个有效区块。通常，每过2016个区块后网络会调整这个目标数值，因此网络中的节点会平均每10分钟产生一个区块。为了补偿矿工的计算工作，每个区块的矿工有资格拿到一笔凭空付给他们的25个比特币。另外，如果任何一笔交易的输入比输出面值更大，那么之间的差额也就作为了给矿工的“交易费”。顺便一提，[对矿工的补偿]这是比特币发行的唯一渠道，创世状态根本不包含比特币。为了更好地理解挖矿的目的，让我们看看恶意攻击时会出现什么状况。因为比特币的底层密码学被认为是很安全的，因此攻击者会攻击比特币系统中没有密码学直接保护的部分：交易顺序。攻击者的策略很简单：1、发送100个比特币给商家，买一些商品(特别是一些可以快速传输的数字商品)2、等待商品寄出3、发起另一笔交易，把那100个比特币发给他自己4、试图让网络相信，他的给自己发出的交易是最先发出的一旦步骤1发生，几分钟后一些矿工会打包交易进入一个区块，假设打包到270000号区块。大约1小时后，在270000号区块后面有5个区块被加到链上，这5个区块每个间接指向步骤1那笔交易，然后确认它。这时，商家将接受这笔支付作为最终的，即商家认可支付成功了，然后发货，我们假设卖的是数字商品，秒发货秒收货。现在，攻击者创建另一笔交易，将这100个比特币发给自己。如果攻击者只是简单广播这笔交易，交易将不会被处理；矿工将运行(S,TX) 函数，并且注意到这笔交易花费的UTXO已经不再状态中。那么相反，攻击者会分叉这个区块链，开始把269999号区块作为父区块，在后面挖另一个版本的270000号区块，在此区块中用新的付给自己的这笔交易代替旧的付给商家的那笔交易。因为区块数据不同，这就需要重做工作量证明。另外，攻击者挖的270000号新区块的hash值也不同，因此原来的270001到270005号区块不“指向”它，所以，原来的链和攻击者的新链完全是分离的。规则是，发生分叉时，最长链 (有最大工作量证明支持的链)被认为是真实的，所以合法的矿工会沿着270005号区块继续工作，只有攻击者孤零零的一个人在270000号区块后工作。 (此处画面感十足！)攻击者为了将他的区块链变成最长链，他将需要拥有比除他之外的全网其余算力更大的算力来追赶(即发起 "51%攻击")。3.3【默克尔树】左图：这充分表明，在默克尔树里面只要少量的节点就能证明分支的有效性。右图：企图改变默克尔树任意部分，都将最终导致链上某部分的前后不一致。原图结合图梳理一下上面两句话：每笔交易信息经过hash之后都自下而上串起来，那么从最顶端往下，都能追溯到最初那笔交易，也就意味着，只需要顶部少量的节点，就能往前去追溯到过去的全部交易信息，而不必再保留之前的多余信息，只保留最新的一部分就好了，从而节省硬盘空间。这也是比特币白皮书里，回收硬盘空间那部分提到的内容。那么这时如果有人企图修改里面某个交易信息，比如右图红色部分，后面的节点就会验证到前后不一致，从而提示错误，不予验证通过。比特币一个重要的可扩展的特点是，区块存储在一个多层次的数据结构中。一个区块的hash值只能是这个区块头的hash值，即一段大约200字节的数据，包含了时间戳、随机数、前一个区块的hash值和一个数据结构的根hash，这个根hash就叫做默克尔树，默克尔树存储着区块上所有的交易信息。默克尔树是一种二叉树，这样构成的：1、一组在默克尔树底部的包含基础数据的大量叶节点，2、一组中间节点，每个中间节点是它两个子节点的hash值，3、一个单一的根节点，也是也是有它的两个子节点构成，代表默克尔树的“顶部”。默克尔树的作用是，让区块里的数据可以被逐条传输：一个节点可以从一个源头只下载一个区块的区块头，从另一个源头下载相关的默克尔树的其他小部分，并且仍然可以确定所有数据是正确的。能这样实现，原因是hash值都是向上扩散的：如果一个恶意用户试图在默克尔树的底部伪造一笔交易，这个改变将导致上面节点的调整，然后再上面节点也要调整，最终改变默克尔树的根以及这个区块的hash值，这导致协议会把这个区块记录为一个完全不同的区块（几乎肯定是无效的工作量证明）。默克尔树协议对[比特币的]长期的稳定性来说，无疑是极其重要的。在2014年4月，比特币网络中的“全节点”，一个“全节点”完整地存储和处理全部区块，需要15G的硬盘空间，并且按每月1G的速度增加。现在，这样的数据量处理，台式电脑还行，但手机搞不了了。未来不久，只有商业机构和爱好者才会来参与当全节点。一个被称为“简化支付验证” (SPV) 的协议可以让其他档次的节点也能玩耍，这些节点可以称为“轻节点”，“轻节点”只下载区块头，用区块头验证工作量证明，然后只下载跟他的交易有关的“分支”。这就让轻节点只需要下载整个区块链的一小部分，就可以安全地确认任意一笔比特币的交易状态，以及他们自己的当前余额。3.4【其他区块链应用】把区块链思维应用到其他概念上的想法早就有了。2005年，Nick Szabo提出了“所有权人授权的安全资产”的概念，在他的文档里，描述了“可复制的数据库技术的新进展”如何让基于区块链的系统来存储土地所有权的登记，创建一个包含房产权、违法占地和乔治亚州土地税的详细框架。但是，不幸的是，那时并没有一个有效的可复制数据库系统，因此该协议并没有被付诸实践。不过2009年后，随着比特币的去中心化共识被开发出来，大量的其他应用就迅速出现了：● Namecoin，2010年被创造出来，被描述为一个去中心化的名称注册数据库。在像Tor、Bitcoin和BitMessage这样的去中心化协议中，需要某些验证账户的方法人们才能互相交互，但是在现有的解决方案中，唯一的账户验证方式是用伪随机的hash值，如1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy。理想情况下，一个人可能希望有个叫“george”的账户名称。但是，问题是如果他用“george”这个名字注册了一个账户，然后其他人也可以通过同样的方式再注册叫“george”的账户，然后假装自己是真的“george”。唯一的办法是用先申请原则，即第一个注册“george”的可以注册，第二个注册“george”的就不能注册了——这个问题可以用比特币共识协议完美解决。Namecoin是最早，也是最成功的一个使用比特币理念来实施名称注册的系统。● Colored coins，颜色币，目的是，可以提供服务，提供什么服务，让人们可以在比特币区块链上创建他们自己的数字货币，或者重要的一般意义上有单位的货币即数字令牌。在颜色币协议里，人们可以通过对一个特定的比特币UTXO公开指定一种颜色，来“发行”一个新的货币，协议能够递归定义其他UTXO的颜色跟交易输入颜色相同 (有一些特定的规则来防止颜色混合输入)。这就可以让用户的钱包里只含有某种颜色的UTXO，而且像通常发送比特币一样发送这些UTXO，并且通过回溯区块链来验证他们收到的任意UTXO的颜色。● Metacoins，元币，元币的理念是，元币在比特币之上，用比特币的交易上存储元币的交易，但是有另一种不同的状态转换函数，叫APPLY'。因为元币协议不能阻止比特币区块上无效的元币交易，因此加入了一个规则，如果APPLY'(S,TX)函数返回错误指令，协议将默认APPLY'(S,TX) = S。这个先进的特点没能在比特币本身部署，但正是这个特点，为创建一个任意的加密货币协议提供了简单机制，并且开发成本很低，因为复杂的挖矿和网络已经在由比特币协议处理好了。因此，创建一个共识协议通常有两种方法：1、创建一个独立网络；2、在比特币网络上创建一个协议。前一种方式，虽然在像Namecoin的应用上相当成功，但是实施起来很困难；每个独立的实施需要一个独立的区块链，以及创建和测试所有必要的状态转换和网络代码。另外，我们预测，运用去中心化共识技术的一组应用都将遵循一种幂律分布，即大多数应用太小以至于不能保证区块链[的安全性]，我们也注意到，现有的大规模的去中心化应用，特别是去中心匿名组织，都需要相互交互。另一方面讲，基于比特币的办法也有瑕疵，它没有继承比特币可以简化支付验证的特点。简化支付验证[SPV]在比特上管用，因为它用区块链深度作为验证的代理器。从一定程度上讲，一旦一笔交易的祖先离这笔交易足够远时，即被认为这笔交易是状态的合法部分，也即一旦对应这一笔交易的很早的一笔交易来源离这笔交易足够远时，就可以认为它们是合法交易。另一方面，基于区块链的元币协议，不能强制区块链不去包含那些在他们自身协议里面被认作为非无效的交易。因此，一个完全安全的简化支付验证[SPV]元币协议实施，需要向后扫描全部的区块链直到比特币区块链的开头，来决定某些交易是无效的。当前，所有基于比特币的“轻”的元币协议，都需依靠一个可信服务器提供数据，，所有基于比特币的元币协议的“轻”实施都依赖可信任的服务器提供数据，可以说这对主要目的之一是消除信任需要的密码学货币而言，只是一个次优[不是最优]的结果。3.5【脚本】即便不进行扩展，比特币协议也可以使一个“智能合约”概念的脆弱版本变得容易实现。即，比特币协议即便不进行扩展，也可以比较容易地实现“智能合约”。比特币的UTXO不仅能被一个公钥所掌握，也可以被一种更复杂的脚本所掌握，这种更复杂的脚本是用一种简单的堆栈式编程语言表达。在这种的表达式里面，一笔花费UTXO的交易，必须提供满足脚本的数据。事实上，即便是基础的公钥所有权机制，也是通过脚本来实现的：脚本将一种椭圆曲线签名作为输入，来验证其是否匹配交易和拥有这个UTXO的地址，如果验证成功，则返回1，如果验证不成功，则返回0。另外，更为复杂的是，脚本存在于其他不同的使用情况。即，脚本用于其他不同情况则更为复杂一些。例如，可以创建一个这样的脚本，要求验证交易必须集齐给定三个私钥中的两个私钥的签名("多重签名")，这样的设置对于企业账户、安全储蓄账户和一些商业托管情况，都是非常有用的。脚本还可以被用于向可计算问题的解决方案支付赏金(也就是向解决计算问题的人支付赏金)，人们甚至可以创建这样一个脚本，就像“如果你可以提供一个简化支付验证证明(SVP证明)，证明你发送了一定面值的Dogecoin狗狗币给我，那么这个比特币UTXO就是你的”，本质上这允许去中心化的跨币兑换(即不同数字货币之间的兑换)。但是，比特币的脚本语言有一些严重限制：● 缺乏图灵完备性——就是说，尽管比特币脚本语言支持大量的计算，但它不支持一切计算。不支持的类型主要是循环语句。这主要为了避免交易验证过程中出现无限循环；理论上，脚本程序员可以克服这个障碍，因为任何循环语句都可以被轻易模仿，只需多次重复if表单语句的基础代码，但这会导致脚本低效率的利用空间。例如，实施一个代替性椭圆曲线签名算法，就可能需要256次重复乘法，而每一次都需要单独编码。● 价值盲——UTXO脚本无法精密地控制取款额度。例如，oracle contract预言机合约一个强大的应用案例可能是对冲合约，即A和B都发送价值1000美元的比特币给合约，30天后合约脚本发送价值1000美元的比特币给A，把剩下的发给B。这虽然要求预言机来判定一个比特币值多少美元，但在如今完全中心化的解决方案环境里，这已经是在信任和基础设施需求方面的巨大进步了。但是，因为UTXO是一个不可分割的整体，要实现UTXO all-or-nothing的整体性，只能通过拥有多种面值的UTXO这种低效的手段(例如，每k最多为30对应一个2^k的UTXO，) ，以及让预言机选择把哪个UTXO发给A，把哪个UTXO发给B。● 状态缺失——UTXO要么已花，要么没花；那么包含除此两状态之外其他内部状态的多级合约或者脚本就实现不了。这让多级期权合约、去中心化互换要约或者两级加密承诺协议(有必要用于确保计算赏金的协议)实现起来变得困难。这意味着UTXO只能被用于创建简单的一次性合约，而不能被用来创建更复杂的“状态”合约例如去中心化组织，UTXO也让元币协议难以实现。二元状态加上价值盲特征也使得另一种重要应用，取款限额，不可能实现。● 区块链盲——UTXO看不到区块数据，例如随机数和前一个区块的哈希值。这个缺陷，剥夺了脚本语言随机性的潜在价值，严重限制了赌博应用和其他类型的应用。因此，我们看见了在加密货币上创建高级应用的三种方式：1、创建一个新的区块链，2、在比特币系统上使用脚本，3、在比特币系统上创建元币协议。创建一个新的区块链可以无限自由地实现各种特性，但是开发时间和推进进度都是成本。使用脚本很容易实现，并且可以标准化，但是能力有限，然后元币协议虽然也很简单，但受制于其可扩展性。使用Ethereum以太坊，我们就可以创建一个通用框架，同时具有这三种方式的优点。4【以太坊】以太坊的目的在于，基于脚本、竞争币和链上元币协议三者概念进行整合和提高，让开发者可以创建任意的、基于共识的应用，这些应用具有由以上三种不同范本同时提供的可扩展性、标准化、特性完备、易于开发和协同等特征。以太坊如何来实现这些的？通过建立本质上是终极抽象的基础层：即一个内置图灵完备编程语言的区块链，这个区块链可以使任何人都能编写智能合约和去中心化应用，并在此之上可以设定他们自己的关于所有权、交易方式和状态转换函数的任意规则。域名币的基本框架写两行代码就能实现，其他协议例如货币和信誉体系等二十行代码以内也能实现。智能合约，即包含价值且只能在满足某些条件下才能解锁的加密“箱子”，也能在我们的平台上创建，并且比比特币脚本所能提供的智能合约更为强大，因为它具备图灵完备性、价值知晓特性、区块链知晓特性以及状态。4.1【以太坊账户】在以太坊中，状态是由被称为“账户”的对象组成的，每个账户有一个20字节的地址，还有可以在账户之间直接传输价值和信息的状态转换器。一个以太坊账户包含四个部分：● 随机数，即一个用来确认每笔交易只能被处理一次的计算器● 账户的当前以太币余额● 账户的合约代码，如有的话● 账户的存储空间(默认为空)“以太币”是以太坊内置的主要加密燃料，用来支付交易费。通常来讲，有两种账户类型：私钥控制的外部账户，和，合约代码控制的合约账户。外部账户没有代码，一个人可以通过创建和签名一笔交易来从外部账户发送信息；而在合约账户内，每次合约账户接收到一条信息，代码就会被激活，允许合约账户对内部存储空间进行读取和写入，并且允许发送其他消息或者依次创建合约。4.2【消息和交易】以太坊里面的“消息”类似比特币里面的“交易”，但是有三点重要不同。第一，一条以太坊消息既可以被外部实体创建，也可以被合约创建，而一笔比特币交易只能由外部创建。第二，以太坊消息可以明确选择是否包含数据。最后，以太坊消息的接收，如果是合约账户，它可以选择回应；这意味着以太坊消息也包含了函数的概念。以太坊里面的“交易”这个术语是指，被签名的数据包，这个数据包存储了从外部账户发送的消息。交易包含了消息接收，对发送者签名的验证，以太币的数量和待发送的数据，以及STARTGAS和GASPRICE燃料价格。为了防止代码的指数级增加和无限循环，需要对每一笔交易设置一个执行代码所引起的计算步骤数量的限制，包括初始消息和代码执行期间引起的任何的其他消息。STARTGAS就是这个限制，而GASPRICE是按每个计算步骤给到矿工的费用。如果执行交易过程中“gas用完了”，那么所有的状态将恢复原状——除了已经支付的交易费，而如果交易执行停止还有剩余的gas，那么剩余的gas将返还发送者。创建合约也有一种独立的交易类型和相应的消息类型；合约地址是基于账户随机数的哈希值和交易数据计算出来的。消息机制的一个重要的结论是，以太坊的“一等公民”财产——即合约与外部账户在发送消息和创建其他合约等方面拥有同等效力的理念。这可以使合约同时充当许多不同角色：例如，可以使一个去中心化组织 (这是一个合约) 的一个成员成为一个第三方托管账户 (这是另一个合约)，这个第三方托管账户为偏执地使用定制量子证明兰伯特签名的个人 (这是第三个合约)和一个自身用五把密钥来确保安全使用账户的共同签名实体 (这是第四个合约)提供第三方托管服务。梳理一下这句话：这可以使合约同时充当不同的角色：1、一个去中心化组织，这是一种合约，比如叫A2、第三方托管，这也是一种合约，叫B，3、非要使用量子兰伯特签名的偏执狂，这也是一种合约，叫C4、用五把密钥来共同管理账户的人或者组织，这也是一种合约，叫D以上句子的逻辑是，以太坊合约可以让为A里面的一个成员变成B，然后这个B为C和D提供托管或居间服务。大致是这么个意思。以太坊的优势在于，去中心化组织和托管合约无需关心合约每个参与方都是什么账户类型。4.3【以太坊状态转换函数】原图以太坊状态转换函数，APPLY(S,TX) -> S'，可定义为如下：1. 检查交易格式是否正确（比如有正确的数值），签名是否有效，和随机数是否与发送者账户的随机数相匹配。如否，返回错误。2. 计算交易费为，交易费=STARTGAS * GASPRICE，并从签名中确定发送地址。从发送者的账户余额中减去交易费并增加发送者的随机数。如果余额不足，返回错误。3. 设定初值GAS = STARTGAS，并在交易中按每字节减去一定量的gas来支付。4. 从发送者的账户转移交易价值到接收者账户。如果接收账户还不存在，则创建该接收账户。如果接收账户是一个合约，则运行合约代码直到代码运行结束或者gas用完。5. 如果因为发送者没有足够的钱，或者代码执行中用完了gas，而导致价值传输失败，则恢复原状，不过还是需要支付交易费，并将交易费加到矿工账户。6. 否则，将所有剩余gas返还给发送者，将已消耗掉的gas作为交易费用发送矿工。例如，假设合约的代码如下：if !contract.storage[msg.data[0]]:contract.storage[msg.data[0]] = msg.data[1]需要注意的是，在现实中，合约代码是用底层以太坊虚拟机（EVM）代码写成的；而为了清晰起见，上面这个合约例子是用我们的高级语言Serpent语言写成的，它可以被编译成EVM代码。假设合约存储开始为空，一笔价值10以太币的交易，gas为2000，gas价格为0.001以太币，并且两个数据字段[ 2, 'CHARLIE' ]。注：第一个三十二字节代表号码2，第二个代表CHARLIE。这样一笔交易发送后，. 状态转换函数的处理过程如下：检查交易是否有效，格式是否正确。2. 检查交易发送者至少有2000*0.001=2个以太币。如果有，从发送者账户中减去2个以太币。3. 初始设定gas = 2000，假设交易为170字节长，每字节的费用是5，减去850所以还剩1150 gas。4. 从发送者账户再减去10个以太币，给合约账户增加这10个以太币。5. 运行代码。在这个例子中，运行代码很简单：它检查索引2处的合约存储是否已使用，注意到它未被使用，然后将检查索引2处的合约存储的值设为CHARLIE。假设这消耗了187gas，于是剩余的gas为1150 - 187 = 963。6. 向发送者的账户增加963*0.001=0.963个以太币，然后返回结果状态。如果没有合约接收交易，那么所有的交易费仅仅等于GASPRICE乘以交易的字节长度，交易数据就与交易费用无关了。另外，需要注意的是，合约发起的消息可以对它们产生的计算分配gas限额，如果子计算的gas用完了，它只恢复到消息发出时的状态。因此，就像交易一样，合约可以通过对它产生的子计算设置严格的限制，来保护它们有限的计算资源。4.4【代码执行】以太坊合约里面的代码是用低级的、基于堆栈的字节码语言写的，被称之为“以太坊虚拟机代码”或“EVM代码”。这些代码由一系列的字节构成，每一个字节代表一种操作。通常来讲，代码执行是一个无限循环，该循环包含程序计数器（初始值为零）重复执行操作，每次操作都给程序计数器增加一，直到代码执行完毕或者检测到错误、STOP或者RETURN指令。执行操作可以访问三种数据存储空间：● 堆栈，一种后进先出的存储，32字节的数值可以入栈出栈● 内存，可无限扩展的字节队列● 合约的长期存储，一个秘钥/数值的存储，其中秘钥和数值都是32字节。与堆栈和内存在计算结束就重置不同的是，存储是长期保存的。代码可以访问数值、发送者和接受到的消息中的数据，就像访问区块头数据一样，代码还可以返回数据的字节队列作为输出。EVM代码的正式执行模型极其简单。当以太坊虚拟机运行时，它的完整的计算状态可以由元组(区块状态、交易、消息、代码、内存、堆栈、程序计数器、gas)来定义，这里block_state区块状态是全局状态，包含所有账户及余额和存储。每轮执行时，通过调用代码的pc-th（程序计数器）某个字节来发现当前指令，每个指令自行定义如何影响元组。例如，ADD将两个元素出栈并将它们的和入栈，将gas减1并将程序计数器加1，SSTORE将顶部的两个元素出栈并将第二个元素插入到由第一个元素定义的合约存储位置，同样减少最多200的gas并将程序计数器加1。虽然通过即时编译有很多方法来优化以太坊，但以太坊基础部署用几百行代码就可以实现。4.5【区块链和挖矿】原图虽然有一些不同，但以太坊区块链在很多方面类似于比特币区块链。以太坊和比特币主要的区别在于区块链架构。不像比特币，以太坊区块包含交易记录和最近的状态。此外，还包含两个值，区块序号和难度值。以太坊的区块确认算法如下：1、检查引用的前一个区块是否存在和有效。2、检查区块的时间戳是否比引用的前一个区块的时间戳大，而且小于未来15分钟3、检查区块序号、难度值、 交易根，叔根和gas限额（许多以太坊特有的底层概念）是否有效4、检查区块的工作量证明是否有效5、将S[0]赋值为上一个区块的STATE_ROOT6、将TX赋值为区块的交易列表，一共n笔交易。对于0……n-1，进行状态转换S[i+1] = APPLY(S[i],TX[i])。如果任何一个转换返回错误，或者程序执行到此区块时所花费的gas超过了GAS限制，返回错误。7、用S[n]给S_FINAL赋值，但向矿工支付区块奖励。8、检查S-FINAL是否与STATE_ROOT相同。如果相同，则区块有效。否则区块无效。这种方法第一眼看起来似乎效率很低，因为它需要存储每个区块的整个状态，但是事实上这种确认效率可以与比特币相当。原因是状态存储在树结构中，每增加一个区块只需要改变树结构的一小部分。因此，通常来讲，在两个相邻区块中的树结构绝大部分应该是相同的，因此一次存储数据可以用指针（子树哈希）引用两次。一种被称为“帕特里夏树”的特别树结构被用来实现这一点，包括了对默克尔树概念的调整，这种调整不仅允许改变节点，还可以很有效率的插入和删除节点。另外，因为所有的状态信息是最后一个区块的一部分，所以没有必要存储全部的区块历史——这一方法，如果能应用到比特币，经计算可以节省5-20倍的存储空间。编辑于 2018-11-09 17:19区块链(Blockchain)比特币 (Bitcoin)​赞同 68​​7 条评论​分享​喜欢​收藏​申请转载​文章被以下专栏收录区块链是什么鬼是全球骗局，还是改变

Ethereum White Paper 以太坊白皮书（中英对照版） - 知乎

Ethereum White Paper 以太坊白皮书（中英对照版） - 知乎首发于BTC深入浅出切换模式写文章登录/注册Ethereum White Paper 以太坊白皮书（中英对照版）戴新生​南京大学 法律硕士A Next-Generation Smart Contract and Decentralized Application Platform下一代智能合约和去中心化应用平台Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller. However, another - arguably more important - part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.2009年中本聪开发出比特币，经常被人们誉为货币的激进式发展，因为比特币是第一个同时没有支持和“内在价值”，也没有集中发行人或控制者的数字资产。然而，比特币实验的另一部分 —— 可以说是更加重要的部分——是作为分布式共识工具的底层区块链技术，关注正在迅速转移到比特币的其他方面。通常被引用的区块链技术的替代应用包括：使用区块链数字资产来表示自定义货币和金融工具（“彩色硬币”），基础物理设备（“智能财产”）的所有权，不可替代资产（如域名币“Namecoin”）以及更复杂的应用程序，其中涉及通过实施任意规则的一段代码（“智能合约”）甚至基于区块链的“分布式自治组织”（DAO）直接控制数字资产。以太坊计划提供的区块链是一种内置的完全成熟的图灵完备的编程语言，可用于创建编码任意状态转换功能的“合同”，允许用户创建上述任何系统，还有其他许多我们还没有想象到的，仅仅通过在几行代码中编写逻辑就可以实现。Table of Contents 目录Introduction to Bitcoin and Existing Concepts 对比特币及现有概念的介绍History 历史Bitcoin As A State Transition System 作为一种状态转换系统的比特币Mining 挖矿Merkle Trees 默克尔树Alternative Blockchain Applications 其他的区块链应用Scripting 脚本Ethereum 以太坊Ethereum Accounts 以太坊账户Messages and Transactions 消息和交易Messages 消息Ethereum State Transition Function 以太坊状态转换功能Code Execution 代码运行Blockchain and Mining 区块链和挖矿Applications 应用Token Systems 代币系统Financial derivatives and Stable-Value Currencies 金融衍生品和价值稳定的货币Identity and Reputation Systems 身份与声望系统Decentralized File Storage 去中心化文件存储Decentralized Autonomous Organizations 去中心化自治组织Further Applications 将来的应用Miscellanea And Concerns 杂集及相关Modified GHOST Implementation 被修改的GHOST实现Fees 费用Computation And Turing-Completeness 计算及图灵完备Currency And Issuance 货币及发行Mining Centralization 挖矿集中Scalability 可扩展性Conclusion 结论Notes and Further Reading 注释及延伸阅读Notes 注释Further Reading 延伸阅读Created by gh-md-toc gh-md-toc 创建Introduction to Bitcoin and Existing Concepts对比特币及现有概念的介绍History 历史The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of "reusable proofs of work", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work".分布式数字货币的概念以及财产登记等替代应用已经存在数十年了。二十世纪八十年代和九十年代的匿名电子现金协议，主要依赖于一种被称为Chaumian blinding的密码原语，它提供了一种高度隐私的货币，但由于其过于依赖一种集中式中介而未能被广泛接受。 1998年， Wei Dai 的B-money成为第一个提出通过解决数学难题和分布式共识来创造货币的提案，但是该提案没有提供关于如何实现分布式共识的细节。 2005年，Hal Finney引入了一种“可重复使用的工作量证明”的概念，该系统使用B-money的想法和Adam Back计算困难的哈希现金难题创造了一个加密货币概念，但由于需要依赖可信的后端计算而再一次没有实现。 2009年，中本聪首次实施了分布式货币，通过公钥密码体制来管理所有权与共识算法追踪谁拥有货币相结合，这一算法称为“工作l量证明”。The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.工作量证明背后的机制是这一领域的的突破，因为它同时解决了两个问题。首先，它提供了一个简单而适度有效的共识算法，允许网络中的节点共同商定对比特币账本状态的一组规范更新。其次，它提供了允许自由进入共识流程的机制，解决了由谁来影响共识的政治问题，同时防止sybil攻击。它通过用经济壁垒来取代正式的参与壁垒，正式的参与壁垒如要求在特定列表上登记为独特的实体，而经济障碍则是 - 共识投票过程中单个节点的权重与该节点带来的计算能力成正比。此后，有人提出了一种替代方法，称为股权证明，它计算一个节点的权重的方式是与其货币持有量成正比，而不是计算资源;对这两种方法相对优点的讨论超出了本文的范围，但应该指出，这两种方法都可以用作加密货币的核心支撑。Bitcoin As A State Transition System作为状态转换系统的比特币From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A's account by $X and increases the value in B's account by $X. If A's account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:从技术的角度来看，像比特币这样的加密货币账本可以被认为是一种状态转换系统，其中存在一个由所有现有比特币的所有权状态组成的“状态”和一个状态转换功能，它输入一个状态和一个交易，输出一个新状态作为结果。 例如，在标准的银行系统中，状态是资产负债表，交易是将$X从A移动到B的请求，状态转换功能将A的账户中的值减少$X，并增加B帐户的值$X。 如果A的账户首先少于$X，则状态转换函数返回一个错误。 因此，人们可以正式定义：APPLY(S,TX) -> S' or ERRORIn the banking system defined above:在银行系统定义如上（下）APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }But:但是：APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERRORThe "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[1]). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.比特币中的“状态”是已经产生和尚未用完的所有货币（技术上说是“未使用的交易输出”或UTXO）的集合，每个UTXO有一个面额和一个拥有者（由20字节地址定义） 本质上是一个密码公钥（译者注：实际与密码公钥还是有很大差别的，严格说，也该是公钥的两次hash）[1]）。 交易包含一个或多个输入，每个输入包含对现有UTXO的引用和由与所有者地址关联的私钥生成的加密签名，以及一个或多个输出，每个输出包含要添加新UTXO到状态中去。The state transition function APPLY(S,TX) -> S' can be defined roughly as follows:状态转换函数 APPLY(S,TX) -> S' 可以粗略的定义如下：For each input in TX: 对每个TX的输入If the referenced UTXO is not in S, return an error. 如果引用的UTXO不在S里面，返回错误If the provided signature does not match the of the UTXO, return an error.如果提供的签名不能被UTXO验证相符，返回错误If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error. 如果所有输入的UTXO的面额小于输出的UTXO的面额，返回错误Return S' with all input UTXO removed and all output UTXO added. 返回S’，同时移除所有的输入UTXO，增加输出的UTXO。The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change", with the owner being Alice herself.第一步的前半部分阻止交易发送人花费不存在的比特币，第一步的第二部分阻止交易送人花费其他人的比特币，同时第二步执行价值守恒。 为了使用这个付款，协议如下。 假设Alice想要将11.7 BTC发送给Bob。 首先，Alice将寻找一套她拥有的可用UTXO，总计至少为11.7 BTC。 实际上，Alice将无法准确获得11.7 BTC; 就说她能得到的接近的组合是6 + 4 + 2 = 12。 然后，她用这三个输入和两个输出创建一个交易。 第一个输出11.7 BTC到Bob所有的的地址，第二个输出将是余下的0.3 BTC“找零”，其拥有者是Alice本人。Mining 挖矿If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.如果我们能够获得值得信赖的集中式服务，这个系统将很容易实施; 它可以完全按照描述进行编码，使用中央服务器的硬盘来跟踪状态。 但是，对于比特币，我们正在试图建立一个分布式的货币体系，所以我们需要将状态交易体系与共识体系结合起来，以确保每个人都对交易顺序达成一致。 比特币的分布式共识流程要求网络中的节点不断尝试生成称为“块”的交易包。 网络每10分钟产生一个块，每个块包含一个时间戳，一个随机数，一个前一个块的引用（即散列）和一个自上一次块产生以来发生的所有交易的列表。 随着时间的推移，这会创建一个持续、不断增长的“区块链”，它的不断更新是为了代表最新的比特币账本的状态。The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:用来表达这种模式的，检查一个区块是否合法的算法，如下所示：Check if the previous block referenced by the block exists and is valid. 检查被当期区块引用的前一个区块是否存在和合法。Check that the timestamp of the block is greater than that of the previous block[2] and less than 2 hours into the future 检查当前区块的时间戳大于前一个区块，同时小于未来2小时（译注：应该就是按照当前区块加入的时间计算是否小于2小时）Check that the proof of work on the block is valid. 检查当前区块上的工作量证明是否正确Let S[0] be the state at the end of the previous block. 让S[0]作为前一个区块的末尾的状态。Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false. 假设 TX 是区块中 n 个交易的交易列表，因为所有的 i 都在 0...n-1 中, 让 S[i+1] = APPLY(S[i],TX[i]) ，如果程序返回错误，则退出并返回失败。Return true, and register S[n] as the state at the end of block. 如果返回正确，纳闷注册 S[n] 作为当前区块末尾的状态。Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.本质上，块中的每个交易必须提供从事务执行前的规范状态到新状态的有效状态转换。 请注意，状态不以任何方式编码在块中; 状态仅仅是一个被验证节点记住的抽象概念，任何区块的状态，都可以从创始状态开始，按次序加入每个块中的每一笔交易后，被（安全地）计算出来。 此外，请注意矿工处理将交易包含进区块的顺序; 如果块中有两个交易A和B，B花费由A创建的UTXO，如果A在B之前，则该块将是有效的，否则不是。The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.在上述列表中出现的，在其他系统没有发现的有效性条件，是对“工作证明”的要求。 确切的条件是，每个区块的双-SHA256散列值（被视为256位数）必须小于一个动态调整的目标，截至本文写作时约为2^187。这样做的目的是为了让创建区块变得“困难”，从而防止sybil攻击者为了私利而重建整个区块链。 因为SHA256被设计为一个完全不可预知的伪随机函数，所以创建一个有效区块的唯一方法是简单的反复尝试，不断增加随机数的值并查看新的哈希值是否匹配。At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 12.5 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.如果当前的目标值是在2^187之下，网络发现有效块之前必须平均进行2^69次尝试; 一般而言，网络每产生2016个区块后会重新校准目标值，以保证平均每10分钟由网络中的某个节点产生一个新区块。 为了补偿矿工们的计算工作，每个发现区块的矿工有权包含一笔给自己12.5比特币（不要问哪里来的）的交易进区块（译注：这就是所谓的每个区块里面的第一个交易，coinbase交易，最开始奖励是25个比特币，每4年减半，以太坊白皮书推出时已经第一次减半）。 此外，如果任何交易在其输入总额高于其输出，则差额也作为“交易费”交给矿工。 顺便说一句，这也是BTC发行的唯一机制; 创始状态根本没有比特币。In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:为了更好地理解挖矿的的目的，让我们来看看在发生恶意攻击时会发生什么。 由于比特币的基础密码学是安全的，因此攻击者将瞄准比特币系统中不受密码学直接保护的部分：交易顺序。 攻击者的策略很简单：Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good) 发送比特币给一个商户，交互一些产品（更青睐快速发货的数字产品）Wait for the delivery of the product 等待商品发货Produce another transaction sending the same 100 BTC to himself 创建另一个交易，将刚才的100比特币发送给自己Try to convince the network that his transaction to himself was the one that came first. 试图让网络相信，那笔发送给自己的交易是第一个交易。Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TXconsumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").一旦步骤（1）发生，几分钟后某些矿工将把交易包括在一个区块中，例如区块编号270000。大约一个小时后，在该区块之后将再添加五个区块，每个区块都间接地指向那笔交易并如此进行“确认”。此时，商家将接受付款并最终交付产品;因为我们假设这是一个数字商品，交货是即时的。现在，攻击者创建了另一个发送100比特币的交易。如果攻击者只是简单地将交易释放到外面，这个交易将不会被处理;矿工将尝试运行APPLY（S，TX），并注意到TX会消耗一个不在状态的UTXO。因此，攻击者创建区块链的“分支”，首先挖掘另一个版本的区块270000，指向与父区块相同的区块269999，但其中新的交易取代旧的交易。由于区块数据不同，这需要重做工作证明。此外，攻击者的新版区块270000具有不同的散列，因此原始块270001至270005不会“指向”它;因此，原始链和攻击者的新链完全分开。规则是，在一个分支中，最长的区块链被认为是事实，所以合法的矿工将在270005链上工作，而攻击者只能在270000链上工作。攻击者为了使自己的区块链最长，他需要比网络其余部分具有更多的计算能力才能赶上（因此，也叫“51％攻击”）。Merkle Trees 默克尔树Left: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.左边：在默克尔树中，仅用少量节点就足以证明一个分支的有效性Right: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.右边：任何试图对默克尔树任何部分的改变，都将导致链上某处的不一致。An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).比特币的一个重要的可扩展性特征是，区块存储在多层级数据结构中。区块的“散列”实际上只是块头的散列，一个大致200字节的数据块，包含时间戳，随机数，先前区块散列和称为Merkle树的数据结构的根散列，这个Merkle树中存储了所有交易。 Merkle树是一种二叉树，由一组节点组成，其中包含底层数据的树的底部有大量的叶节点，一组中间节点，其中每个节点是其两个子节点的散列，最后是一个单一的根节点，也是由它的两个子节点的散列形成的，代表树的“顶部”。 Merkle树的目的是允许块中的数据零散传递：一个节点可以只从一个源下载块的头部，从另一个源下载与此相关的树的小部分，并且依然可以确信所有数据都是正确的。之所以这样做，是因为哈希会向上传播：如果恶意用户试图将虚假交易替换到Merkle树的底部，则此更改将导致其上的节点发生更改，然后改变的是这个节点上面的节点，最后改变树的根，因此改变区块的散列值，导致协议将它标示为完全不同的块（几乎肯定带有无效的工作量证明）。The Merkle tree protocol is arguably essential to long-term sustainability. A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.Merkle树协议，对于长期可持续性来说可能是必不可少的。 比特币网络中的一个“完整节点”，一个用于存储和处理所有区块整体的网络，截至2014年4月，占用大约15 GB的磁盘空间，并且每月增长超过千兆字节。 目前，这对于一些台式计算机是可行的，但是手机不行，并且以后只有企业和爱好者才能参与。 被称为“简化支付验证”（SPV）的协议允许存在另一类节点，称为“轻节点”，其下载区块头部，验证区块头部的工作量证明，然后仅下载与他们的交易相关联的“分支”。 这使得轻型节点只需下载整个区块链很小的部分，就可以安全的确定任一比特币交易状态和他们的账户余额安全。Alternative Blockchain Applications 其他区块链应用The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.将底层区块链想法应用于其他领域的想法早就出现了。 2005年，Nick Szabo提出了“标示所有权的安全产权”概念，一个文件描述了“复制数据库技术的新进展”将会如何允许基于区块链的系统，用来存储谁拥有哪块土地的注册， 并创建一个精心设计的框架，包括诸如家园式，逆权管理和格鲁吉亚地税等概念。 但是，不幸的是，当时没有有效的复制数据库系统，因此该协议在实践中从未得到实施。 然而，2009年之后，当比特币的分布式共识被开发出来后，很多其他的应用迅速涌现。Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.Namecoin - 2010年创建，Namecoin最好描述为分布式名称注册数据库。 在像Tor，Bitcoin和BitMessage这样的分布式协议中，需要有一些识别帐户的方法，以便其他人可以与它们交互，但是在所有现有的解决方案中，唯一可用的标识符是伪随机哈希，如1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy。 理想情况下，人们希望能够拥有像“乔治”这样的名字。 但问题是，如果一个人可以创建一个名为“乔治”的账户，那么其他人可以使用相同的过程为自己注册“乔治”，并假冒它们。 唯一的解决方案是采用first-to-file模式，第一个注册成功，第二个失败 - 这是一个完全适合比特币共识协议的问题。 使用这种想法实现名称注册系统，Namecoin是最早、也是最成功的一个。Colored coins - the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.彩色币（Colored coins） - Colored coins的目的是作为一种协议，允许人们在比特币区块链上创建自己的数字货币 - 或者，一个重要琐碎情况下的货币单位，数字代币等。 在彩色币协议中，通过公开地为特定的比特币UTXO分配一种颜色来“发布”新币种，并且该协议递归地将其他UTXO的颜色定义为，与创建该交易花费的输入（UTXO）的颜色相同 （一些特殊的规则适用于混合颜色输入的情况）。 这允许用户维护仅包含特定颜色的UTXO的钱包，并像常规比特币一样使用它们，通过区块链回溯可以确定它们接收的任何UTXO的颜色。Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY'. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX)returns an error, the protocol defaults to APPLY'(S,TX) = S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.元币（Metacoins） - metacoin背后的想法是拥有一个生活在比特币之上的协议，使用比特币交易来存储metacoin交易，但具有不同的状态转换函数 APPLY'。 由于元币协议不能防止无效的元币交易出现在比特币区块链中，所以添加一条规则，即如果APPLY'（S，TX）返回错误，则协议默认为APPLY'（S，TX）= S。 由于挖矿和网络的复杂性已经由比特币协议处理，所以创建任意加密货币协议的机制非常简单，可能无法在比特币内部实现高级功能，但其开发成本非常低。 Metacoins已被用于实施一些类别的金融合同，名称注册和分布式交换。Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.因此，总的来说，有两种方法可以建立一个共识协议：建立一个独立的网络，或者在比特币之上构建一个协议。 前一种方法虽然在像Namecoin这样的应用程序中相当成功，但很难实现，因为每个单独的应用都需要创建一个独立的区块链，以及构建和测试所有必要的状态转换和网络代码。 此外，我们预测分布式共识技术的应用程序集将遵循幂律分布，绝大多数应用太小而不能保证自己区块链的安全，并且我们注意到存在大量的分布式应用程序，特别是分布式自治组织，需要相互交流。The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.另一方面，基于比特币的方法存在缺陷，因为它继承不了比特币的简化支付验证（SPV）功能。 SPV适用于比特币，因为它可以使用区块链深度作为有效性的代理; 在某种程度上，一旦交易的祖先足够回归，可以肯定地说它们是状态的合法组成部分。 另一方面，基于区块链的元协议，不能强制比特币区块链不要包含元协议环境中无效的交易。 因此，完全安全的SPV元协议实现需要一直向后扫描到比特币区块链的开头，以确定某些交易是否有效。 目前，基于比特币的元协议的所有“轻量级”实现依赖于可信服务器来提供数据，可以说这是一个非常不妙的结果，尤其是因为加密货币的主要目的之一，就是要消除对信任的需求。Scripting 脚本Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts". UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.即使没有任何扩展，比特币协议实际上也实现了“智能合约”概念的弱化版本。比特币中的UTXO不仅可以被公钥拥有，还可以被更复杂的脚本来拥有，这一脚本以简单的基于堆栈的编程语言来表达。在这个模式中，花费UTXO的交易必须提供满足脚本的数据。事实上，即使是基本的公钥所有权机制也是通过脚本实现的：脚本以椭圆曲线签名为输入，根据交易和拥有UTXO的地址验证它，如果验证成功则返回1，否则返回0。其他更复杂的脚本存在于各种其他用例中。例如，可以构建一个脚本，该脚本需要来自给定三个私钥中的两个的签名才能验证（多重签名“multisig”），这一设置对于公司帐户，安全储蓄帐户和一些商业托管情况很有用。脚本也可以用来支付解决计算问题的奖励，甚至你可以构建这样的脚本：“如果您可以提供SPV证据证明您已向此发送此币值的狗币（Dogecoin），则此比特币UTXO即属于您” ，本质上，比特币系统允许分布式的跨加密货币间的兑换。However, the scripting language as implemented in Bitcoin has several important limitations:然而，比特币实现的脚本语言存在几处重要的限制：Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.缺乏图灵完备性 - 也就是说，尽管比特币脚本语言支持大量计算，但它并不是支持所有计算。 缺少的主要类别是循环（loops）。 这样做是为了避免交易验证期间的无限循环; 从理论上说，这是一个脚本程序员可以克服的障碍，因为任何循环都可以简单地用 if 语句多次重复底层代码来模拟，但它确实会导致脚本在空间利用上的低效。 例如，实施替代椭圆曲线签名算法可能需要256次重复的乘法循环，每一次循环都需单独包含在代码中。Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.价值盲 - UTXO脚本无法对可撤销的金额进行精细化控制。 例如，预言合同的一个强大的用例就是套期保值合同，A和B投入1000美元的BTC，30天后脚本向A发送价值1000美元的BTC，其余的则发给B。 这就需要预言确定1 BTC价值多少美元，但即使如此，它对信任和基础设施要求方面的重大改进已经超过了现在可用的完全集中式解决方案。 然而，由于UTXO全是或全无，实现这一目标的唯一方法，是通过非常低效地分解许多不同面额的UTXO（例如，一个每达到30 的2k的UTXO），并选择哪个UTXO 发送给A和哪个给B。Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.缺乏状态 - UTXO只有用完和没有用两种状态; 多阶段合同或脚本没有机会保持任何其他内部状态。 这使得很难制定多阶段期权合约，分布式交易提议或两阶段密码承诺协议（安全计算奖励所必需的）。 这也意味着UTXO只能用于构建简单的一次性合同，而不能构建像分布式组织那样更复杂的“有状态”合同，并且使元协议难以实施。 二元状态与价值盲相结合还意味着另一个重要的应用——取款限制——不可能实现。Blockchain-blindness - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.区块链盲 - UTXO对区块链数据（例如随机数，时间戳和前一个区块哈希）视而不见。 这剥夺了脚本语言来源于随机性的潜在价值，严重限制了赌博和其他几个类别的应用。Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.综上，我们了解到在加密货币之上构建高级应用程序的三种方法：构建新的区块链，在比特币之上使用脚本，在比特币之上构建元协议。 构建新的区块链，可以在构建功能集时实现无限制的自由，但成本是开发时间，培育努力和安全保障。 使用脚本很容易实现和标准化，但其功能非常有限，而元协议虽然很容易，但在可伸缩性方面遇到问题。 通过以太坊，我们打算构建一个替代框架，在易于开发的同时提供更大的收益，以及更强大的轻客户端属性，同时允许应用程序共享经济环境和区块链安全。Ethereum 以太坊The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.以太坊的目的是为构建分散式应用程序创建一个替代协议，提供一套不同的折衷方案，我们认为这对于大量分布式应用程序非常有用，特别强调快速开发时间，小型很少使用的应用程序，以及不同应用程序的高效互动能力都很重要。以太坊通过构建本质上最终的抽象基础层来实现这一点：一种内置图灵完整编程语言的区块链，允许任何人编写智能合约和分布式应用程序，在这些应用程序中他们可以为所有权，交易格式和状态转换函数制定自己的规则。 Namecoin的一个简单版本可以用两行代码编写，其他协议，如货币和信誉系统可以在20行以内建立。因为拥有比比特币脚本所提供的功能强大得多的图灵完备性，价值知晓，区块链知晓和状态，所以智能合约，包含价值并且只有在满足特定条件时才解锁的密码“箱子”，都可以建立在平台之上。Ethereum Accounts 以太坊账户In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:在以太坊中，状态由称为“帐户”的对象组成，每个帐户都有一个20字节的地址，状态转换是账户之间的价值和信息的直接转移。 以太坊账户包含四个字段：The nonce, a counter used to make sure each transaction can only be processed once 随机数，用于确定每笔交易只能被处理一次的计算器The account's current ether balance 账户当前的以太币余额The account's contract code, if present 账户的合约代码，如果有的话The account's storage (empty by default) 账户的存储（默认为空）"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.“以太”是以太坊的主要内部加密燃料，用于支付交易费用。 一般来说，有两种类型的账户：外部所有的账户，由私钥控制；合同账户由合同代码控制。 外部所有的账户没有代码，人们从外部所有账户发送消息，以创建和签署交易; 在合同账户中，合约账户每次收到消息后，代码激活，将允许对内部存储进行读写和发送其他消息或者依次创建合约。Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.请注意，以太坊中的“合约”不应被视为应该被“履行”或“遵守”的事物; 相反，他们更像是居住在以太坊执行环境中的“自主代理人”，当被消息或交易“捅一下”时，总是执行特定的代码段，并直接控制自己的以太余额和自己的密钥/ 值存储，保持对持久变量的跟踪。Messages and Transactions 消息与交易The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:“交易”术语在以太坊中是指被外部所有账户发送的存有消息的经过签署的数据包。交易包含：The recipient of the message 消息接受人A signature identifying the sender 能证明发送者身份的签名The amount of ether to transfer from the sender to the recipient 一定数量的从发送者转移至接受者的以太币An optional data field 一个可选的数据字段A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take STARTGAS值，代表交易被执行时可以运行的最大计算步骤数A GASPRICE value, representing the fee the sender pays per computational step GASPRICE值，代表发送者为每个计算步骤支付的费用。The first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.前三个是任何加密货币中预期的标准字段。 数据字段默认没有功能，但虚拟机具有合同可以访问数据的操作码; 作为示例用例，如果合同作为区块链上的域名注册服务运行，那么它可能希望将传递给它的数据解释为包含两个“字段”，第一个字段是要注册的域名，第二个字段是域名的IP地址。 合同将从消息数据中读取这些值并将其妥善放置在存储中。The STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.对于以太坊的反拒绝服务模式，STARTGAS和GASPRICE字段至关重要。 为了防止代码中的意外或恶意的无限循环，或其他计算浪费，每个事务都需要设置它可以使用多少的代码执行步骤数。 计算的基本单位是“gas”。 通常，一个计算步骤花费1个gas，但是一些操作耗费更高的gas，因为它们在计算上更昂贵，或者增加了作为状态的一部分的必须存储的数据量。 交易数据中的每个字节也要收费5个gas。 收费系统的目的是要求攻击者按比例支付他们消费的每一种资源，包括计算量，带宽和存储量; 因此，任何导致网络消耗更多资源的交易必须具有与增量大致成比例的gas。Messages 消息Contracts have the ability to send "messages" to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains:合约具有向其他合约发送“消息”的能力。消息是从没有被序列化的，只存在于以太坊执行环境的虚拟对象。消息包含：The sender of the message (implicit) 消息发送者（固有的）The recipient of the message 消息接受者The amount of ether to transfer alongside the message 与消息一起被转移的以太币的数量An optional data field 可选的数据字段A STARTGAS value STARTGAS值Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALLopcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.从本质上讲，消息就像一个交易，除了它是由合同产生的而不是由外部参与者产生的之外。 当一个正在运行代码的协议执行CALLopcode时，将会产生和执行一条消息。 就像一个交易，一条消息导致接收人账户运行其代码。 因此，合约可以拥有与其他合约的关系，这与外部参与者之间的方式完全相同。Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.请注意，交易或合同分配的gas限额适用于该交易和所有子执行消耗的总gas。 例如，如果外部参与者A向B发送带有1000个gas的事交易，B在向C发送消息之前消耗了600个gas，并且C的内部执行在返回之前消耗300个gas，则B在用光gas之前，只可以花费另外100个gas。Ethereum State Transition Function 以太坊状态转换函数The Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows: 以太坊状态转换函数 APPLY(S,TX) -> S' 定义如下：Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error. 检查交易是否被构建完好（例如，有正确的值），签名是否正确，随机数是否与发送者账户的随机数匹配。如果不是，返回错误。Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error. 通过 STARTGAS * GASPRICE计算出交易费用，确定发生地址来自于签名，从发送者账户减去费用，同时增加发送者的随机数。如果没有足够的余额，返回错误。Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 初始化 GAS = STARTGAS，在交易中支付确定每字节数量的gas。Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas. 从发送者账户转移交易数额至接受者的账户。如果接受者的账户不存在，创建一个。如果接受者账户是一个合约，运行合约代码要么完成，要么用光了所有的gas。If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account. 如果是因为发送者没有足够的钱而导致转移失败，或者是代码运行用光了gas，除了支付的费用外，恢复所有状态的更改，并将费用支付给矿工的账户。Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner. 相反的情况，将剩余的费用找零给发送者，支付消耗的费用给矿工。For example, suppose that the contract's code is:例如，假定合约代码如下：if !self.storage[calldataload(0)]:

self.storage[calldataload(0)] = calldataload(32)Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2and bytes 32-63 representing the string CHARLIE. The process for the state transition function in this case is as follows:请注意，实际上，合约代码是用低级EVM代码编写的; 为了清晰起见，本示例使用Serpent（我们的高级语言之一）编写，并且可以编译为EVM代码。 假设，合约的存储从空开始，交易是发送：10个以太币，2000gas，0.001 gasprice 和 64字节，其中字节0-31代表数字2，字节32-63代表字符串CHARLIE。 在这种情况下状态转换函数进行如下处理：Check that the transaction is valid and well formed. 检查交易是否有效并组织完好Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account. 检查交易发送者至少拥有2000 * 0.001 = 2 个以太币，并从其账户上扣减2个以太币Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left. 初始化 gas = 2000，假定交易是170字节，每字节5gas，减去850gas，剩下 1150 gasSubtract 10 more ether from the sender's account, and add it to the contract's account. 从发送者账户减去10个以太币，将其增加到合约账户Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963 运行代码。在这个案例中，非常简单：检查合约账户的存储索引 2 是否被使用，提示没有，则将存储索引2的数据设置为 CHARLIE 。假设这花费了187gas，余下的就是 1150 - 187 = 963 gasAdd 963 * 0.0001 = 0.963 ether back to the sender's account, and return the resulting state. 返还 963 * 0.0001 = 0.963 以太币到发送者账户，同时返回结果状态。If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.如果在交易接收端没有合约，那么总的交易费用将等于所提供的GASPRICE乘以交易的长度（以字节为单位），与交易一起发送的数据无关。Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, CREATE, that creates a contract; its execution mechanics are generally similar to CALL, with the exception that the output of the execution determines the code of a newly created contract.请注意，消息在回滚方面与交易相同：如果消息执行耗尽gas，那么该消息的执行以及该执行触发的所有其他执行都会回滚，但父执行不需要回滚。 这意味着合约调用另一份合约是“安全的”，就好像A用G gas调用B，那么可以确保A的执行最多会损失G gas。 最后，请注意，有一个操作码CREATE，它创建合约; 其执行机制通常与CALL类似，例外是执行的输出决定了新创建的合约代码。Code Execution 代码执行The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code". The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data:以太坊合约中的代码采用低级，基于堆栈的字节码语言编写，被称为“以太坊虚拟机代码”或“EVM代码”。 该代码由一系列字节组成，其中每个字节表示一个操作。 一般来说，代码执行是一个无限循环，它包括在当前程序计数器（从零开始）重复执行操作，然后将程序计数器递增1，直到代码结束或错误或STOP 或RETURN指令被检测到。 这些操作可以访问三种类型的数据存储空间：The stack, a last-in-first-out container to which values can be pushed and popped 堆栈，数据压入弹出的后进先出的容器Memory, an infinitely expandable byte array 内存，一个无限扩展的字节数组The contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term. 合约的长期存储，一个键/值存储，与堆栈和内存会在计算结束后重置不同，这一存储将会长期保持，The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.代码还可以访问传入消息的值，发送者和数据以及块头数据，代码也可以返回一个字节数组作为输出。The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.EVM代码的正式执行模型非常简单。 当以太坊虚拟机正在运行时，它的完整计算状态可以由元组（block_state，transaction，message，code，memory，stack，pc，gas）定义，其中block_state是包含所有帐户的全局状态，并包含余额和存储。 在每一轮执行开始时，当前指令可以通过获取代码的pc th（译者注：类似4th，5th 等）字节来找到（如果pc> = len（code），则为0），并且每条指令都有其自己的定义，以表明它如何影响元组。 例如，ADD从堆叠中弹出两个物品并推送其总和，将gas减少1，并将pc递增1，SSTORE将顶部两项品从堆栈中弹出，并将第二项插入到合约存储器中作为索引的第一项。 虽然有很多方法可以通过即时编译来优化以太坊虚拟机的执行，但以太坊的基本实现可以通过几百行代码完成。Blockchain and Mining 区块链和挖矿The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:以太坊区块链在很多方面与比特币区块链相似，但它确实有一些区别。 以太坊和比特币在区块链架构方面的主要区别在于，与比特币不同，以太坊区块包含交易列表和最新状态的副本。 除此之外，区块块中还存储了其他两个值，区块号和难度。 以太坊中的基础的区块验证算法如下：Check if the previous block referenced exists and is valid. 检查被引用的前一区块是否存在并有效Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future 检查时间戳是否大于被引用的前一区块并且小于未来15分钟Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid. 检查区块号，难度，交易根，叔根和gas限制（各种各样底层的以太坊特有概念）是否有效。Check that the proof of work on the block is valid. 检查当前区块的工作量证明是否有效。Let S[0] be the state at the end of the previous block. 让 S[0] 作为前一区块末尾的状态Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error. 让 TX 作为区块的交易列表，包含了 n 个交易。为所有在 0...n-1的 i 进行操作, 让 S[i+1] = APPLY(S[i],TX[i])。如果任何应用返回错误，或者 gas 消耗超过了 GASLINIT 的限制，返回错误。Let S_FINAL be S[n], but adding the block reward paid to the miner. 让S_FINAL 成为 S[n]，但要增加支付给矿工的区块奖励。Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid. 检查 S_FINAL 中默克尔树根是否等于区块头部的最终状态根。如果相等则区块是有效的，否则区块无效。The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.这种方法乍一看似乎效率很低，因为它需要在每个块中存储整个状态，但实际上效率应该与比特币相当。 原因是状态存储在树状结构中，并且在每个块之后只需要改变树的一小部分。 因此，通常在两个相邻块之间，绝大多数树应该是相同的，因此数据可以被存储一次并且使用指针（即子树的散列）被引用两次。 一种称为“Patricia树”的特殊树被用来实现这一点，包括对Merkle树概念的修改，允许节点被插入和删除，而不仅仅是改变，非常高效。 此外，由于所有状态信息都是最后一个区块的一部分，因此不需要存储整个区块链历史记录 - 这一策略如果应用于比特币，可以节省出节省5-20倍的空间。A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.对于物理硬件来说，一个常见问题是“在哪里”执行合约代码。一个简单的答案：执行合同代码的过程是状态转换函数的定义的一部分，函数是区块验证算法的一部分，所以如果将一个交易添加到区块B中，则该交易导致的代码执行将是：所有节点，现在和将来，都会下载和验证区块B。Applications 应用In general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.总的来说，在以太坊之上有三种类型的应用程序。 第一类是金融应用程序，它为用户提供更强大的管理方式，让用户使用它们的资金签订合同。 这包括子货币，金融衍生品，套期保值合约，储蓄钱包，遗嘱以及最终甚至是一些类别的全面雇佣合同。 第二类是半金融应用，涉及金钱，但也有非常重要的非货币方面的工作。一个完美的例子就是为计算问题的解决自我实施奖励。 最后，还有诸如在线投票和分布式治理等应用程序，这些应用程序一点儿也没有财务属性。Token Systems 代币系统On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (1) A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.区块链上的代币系统有许多应用，从代表资产（如美元或黄金）的子货币到公司股票，还有代表智能财产的单个代币，安全不可伪造的优惠券，甚至还有与常规价值完全不相干的代币，它被用做点激励系统。 代币系统在以太坊中实现起来非常简单。 要理解的关键点是，所有货币或代币系统基本上都是一个数据库，只有一个操作：从A中减去X个单位并将X个单位给予B，但条件是（1）在交易前，A至少有X个单位和（2）交易由A批准。实现代币系统所需的一切就是将该逻辑在合约中实施。The basic code for implementing a token system in Serpent looks as follows:用Serpent编写的实现代币系统的基本代码如下：def send(to, value):

if self.storage[msg.sender] >= value:

self.storage[msg.sender] = self.storage[msg.sender] - value

self.storage[to] = self.storage[to] + valueThis is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.这实质上是对上文中进一步描述的“银行系统”状态转换函数的字面实现。需要添加一些额外的代码行，以便首先提供分配货币单位的第一步以及其他一些边缘情况；理想情况下，会添加一个函数以便让其他合同来查询地址的余额。但，这就是它的全部。从理论上讲，以太坊为基础的代币系统充当次级货币可能会包含，链式的以基于比特币元币所缺乏的，另一个重要特征：能够直接以该货币支付交易费用。这样做的方式是，合同将维护一个以太币账户，这样就可以用给发送人的以太币退款来支付交易费用，合约将通过收集被作为交易费的内部货币单位，并在一个不断运行的拍卖中再次卖掉，以实现为该账户注资。用户因此需要使用以太币来“激活”他们的账户，但是一旦以太会在那里就可以重用，因为合约每次都会退还。Financial derivatives and Stable-Value Currencies金融衍生品和价值稳定的货币Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.金融衍生工具是“智能合约”中最常见的应用，也是最简单的代码实现之一。 实施金融合同的主要挑战是，其中大部分要求参考外部价格报价器; 例如，一个非常理想的应用程序是一种智能合约，可以抵御以太币（或另一种加密货币）相对于美元的波动性，但这样做需要合约知道ETH / USD的价值。 最简单的方法是通过由特定方（例如纳斯达克）维护的“数据反馈”合同，以便该方有权根据需要更新合同，并提供一个接口，以允许其他合同向那个合同发送消息并取回提供价格的响应。Given that critical ingredient, the hedging contract would look as follows:给定关键元素，对冲合约看起来如下：Wait for party A to input 1000 ether. 等待 A 方 输入1000 以太币Wait for party B to input 1000 ether. 等待 B 方输入1000以太币Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x. 记录1000 以太币价值多少美元，这通过询问数据反馈合约后计算获得，保存，假如是 $x。After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B. 30天后，允许A或者B再次激活合约，发送价值$x 的以太币给A，具体的以太币的数值当然也是在询问数据反馈合约后计算获得，余下的以太币发送给B。Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.这样的合同在密码商务中将具有巨大的潜力。 引用加密货币的主要问题之一是不稳定; 尽管许多用户和商家可能希望使用加密资产的安全性和便利性，但他们可能不希望一天内损失其资金价值23％的前景。 到目前为止，最常见的解决方案是发行人背书资产; 这个想法是，发行人创建了一个子货币，他们有权发行和撤回货币单位，并将任何一个单位的货币提供给那些给他们（离线）提供一个单位特定基础资产（例如，黄金 ， 美元）的人。 然后，发行人承诺向发回一个单位加密资产的任何人返还一个基础资产单位。 该机制允许任何非密码资产被“提升”为密码资产，前提是发行人可以被信任。In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.然而，在实践中，发行人并不总是值得信赖的，而且在某些情况下，银行业基础设施太脆弱，或者银行不够诚信，所以这样的服务不能存在。金融衍生产品提供了另一种选择。在这里，不是单一发行人提供资金来支撑一种资产，而是一个分布式的投机者市场，他们认为加密资产（例如ETH）的价格会上涨，而扮演了投机者这个角色。 与发行人不同，投机者没有讨价还价的余地，因为对冲合约持有他们的资金托管。 请注意，这种方法并不是完全分布式的，因为仍然需要一个可信赖的来源来提供报价，尽管可以说即使如此，这也仍然是一个在降低基础设施要求（与发行商不同，发布价格反馈不需要许可证，并可能被归类为言论自由）和减少欺诈的可能性方面的巨大进步。Identity and Reputation Systems 身份和信誉系统The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:最早的替代加密货币，Namecoin试图使用类似比特币的区块链来提供名称注册系统，用户可以在公共数据库中将他们的名称与其他数据一起注册。 主要引用的用例是DNS系统，将域名（比如“bitcoin.org”）（或者在Namecoin的例子中是“bitcoin.bit”）映射到IP地址。 其他用例包括电子邮件认证和潜在的更高级的信誉系统。 以下是在以太坊提供类似Namecoin的名称注册系统的基本合约：def register(name, value):

if !self.storage[name]:

self.storage[name] = valueThe contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.合约非常简单; 所有这一切都是以太坊网络内的一个数据库，可以添加到但不能修改或删除。 任何人都可以注册一个具有一定价值的名称，然后该注册将永久保存。 一个更复杂的名称注册合同也会有一个“函数条款”，允许其他合同进行查询，以及一个为“所有者”而设的机制（即，第一注册者），所有者可以更改数据或转让所有权。 人们甚至可以在上面添加信誉和网络信任功能。Decentralized File Storage 分布式文件存储Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.在过去几年中，已经出现了一些流行的在线文件存储初创公司，其中最着名的是Dropbox，它试图允许用户上传他们硬盘的备份，提供保存备份和用户访问这些数据服务，他们为此收取月费。 但是，目前文件存储市场有时相对低效， 粗略看一下现有的各种解决方案，特别是在20-200 GB的“恐怖谷”水平上，既没有免费额度也没有企业级的折扣，你支付的主流文件存储成本的每月价格，要高于单月整个硬盘的成本。 以太坊合同可以允许开发分布式文件存储生态系统，个人用户可以通过出租自己的硬盘来赚取少量的资金，未使用的空间可以用来进一步降低文件存储成本。The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.这种装置的关键部件我们称之为“分布式Dropbox合同”。该合同的如此工作。首先，将所需数据分成块，对每个块进行隐私加密，然后构建默克尔树。然后用以下规则形成合约：每N个块，合约将在Merkle树中选择一个随机索引（可从合同代码访问，使用之前的区块散列作为随机源），并将 X 以太币赋予第一个实体，为该交易提供一个简化的支付验证（SPV） - 就像在树中特定索引处的块的所有权证明。当用户想要重新下载他们的文件时，他们可以使用微支付通道协议（例如，支付每32千字节1个szabo）来恢复文件;最节省费用的方法是付款人不到最后不要发布交易，而是，在每32千字节之后，用一个更划算的带有同样随机数的交易取代原来的那个。An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.该协议的一个重要特点是，虽然看起来像一个人相信许多不会丢失文件的随机节点，但可以通过秘密共享将文件分割成许多块，从而将风险降低到接近于零，并通过监看合约来了解每个碎片仍然在某个节点中。 如果合约仍在支付金钱，那么它提供了一个某人仍在存储该文件的密码学证据。Decentralized Autonomous Organizations 分布式自治组织The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.“分布式自治组织”的一般概念是拥有一定数量的成员或股东的虚拟实体，这些成员或股东可能拥有67％的多数股东权利，有权花费实体的资金和修改代码。成员将共同决定组织如何分配资金。分配DAO资金的方法可以，从赏金，工资，到更多如用内部货币以奖励工作这样的外来机制。这基本上复制了传统公司或非营利组织的法律外观，但仅使用加密区块链技术来执行。到目前为止，关于DAO的大部分讨论都围绕着“分布式自治公司”（DAC）的“资本主义”模式，其中包含接受分红的股东和可交易股票;另一种可能被称为“分布式自治社区”的替代方案，所有成员在决策中拥有平等的份额，增加或开除一名成员，需要得到67％现有成员的同意。一个人只能拥有一个会员资格的要求，将需要该团体共同强制执行。A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:如何编写DAO的一般概要如下。 最简单的设计只是一个自我修改的代码，如果三分之二的成员同意修改就会发生变化。 尽管代码在理论上是不可变的，但人们可以很容易地解决这个问题，通过在单独的合同中包含大部分代码，并调用那些合同的地址存储在可修改的存储中，从而具有事实上的可变性。 在这种DAO合同的简单实现中，有三种交易类型，通过交易中提供的数据进行区分：[0,i,K,V] to register a proposal with index i to change the address at storage index K to value V 注册一个提议，用索引 i 来修改存储索引 K 到 V 的地址[0,i] to register a vote in favor of proposal i 注册一个赞成建议 i 的投票 [2,i] to finalize proposal i if enough votes have been made 如果足够的投票已经做出，敲定建议 i 。The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.合同的每一项都有条款。它将保存所有开放存储更改的记录以及谁投票给他们的清单。它也会有一个所有成员的名单。当任何存储变更得到三分之二的成员投票支持时，敲定的交易来执行变更。一个更复杂的框架可能也会具有内置投票功能，例如发送交易，增加成员和删除成员等功能，甚至可以提供流动民主风格的投票授权（即任何人都可以指定某人投票给他们，因此如果A指定B投票，B指定C，则C决定A的投票）。这种设计可以使DAO作为一个分布式的社区有机地发展起来，允许人们最终将挑选合适人选的任务委派给专家，但与“现有系统”不同，随着时间的推移，当个别社区成员改变他们的阵营时，专家很容易的加入或退出。An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".另一种模式是分布式公司，任何账户可以有零或更多的股份，作出决定需要三分之二的股份支持。 一个完整的框架将涉及资产管理功能，提出购买或出售股份的能力，以及接受要约的能力（最好是在合同中使用订单匹配机制）。授权也存在流式民主风格，也就产生了“董事会”的概念。Further Applications 未来的应用1. Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows: 储蓄钱包。假设Alice想安全的保管她的资金，但是却担心自己弄丢了私钥或者有人非法侵入获得她的私钥。她把以太币放在一个与Bob的合约里，一家银行，操作如下：Alice alone can withdraw a maximum of 1% of the funds per day. Alice每天可以独自取款最多1%Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability. Bob每天可以独自取款最多1%，但是Alice有权用她的钥匙发起一个交易关闭Bob的这个权利Alice and Bob together can withdraw anything. Alice和Bob一起可以提取任意额度的资金。Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.通常情况下，Alice每天1％就足够了，如果Alice想要提取更多的资金，她可以联系鲍勃寻求帮助。 如果Alice的密钥遭到黑客攻击，她会去找Bob将资金转移到新的合约。 如果Alice失去了她的密钥，Bob将最终取出所有资金。 如果事实证明Bob是恶意的，那么她可以关闭他的取款资格。2. Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.2.作物保险。 人们可以很容易地使用天气的数据反馈而不是任何价格指数来制定金融衍生品合约。 如果爱荷华州的农民购买与爱荷华州降水量相反支付的衍生合约，那么如果出现干旱，农民将自动获得收入，如果雨水充足，农民就会因为收成良好而开心。 这一般可以扩展到自然灾害保险。3. A decentralized data feed. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.3.分布式数据反馈。 对于不同的金融合约，实际上可能通过一个名为“SchellingCoin”的协议进行分布式数据反馈。 SchellingCoin的基本工作原理如下：N方都将给定数据（例如ETH / USD价格）的值输入到系统中，对值进行排序，并且在第25和75百分位之间的每个人都获得一个代币奖励。 每个人都有动力提供其他人将提供的答案，而大量玩家可以切实达成一致的唯一价值就是明显的默认值：事实。 这创建了一个分布式的协议，理论上可以提供任意数量的值，包括ETH / USD价格，柏林温度或甚至特定的硬计算结果。4. Smart multisignature escrow. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.4.智能多重签名托管。 比特币允许多重签名交易合约，例如，给定五个密钥中的三个可以花费资金。 以太坊允许更多的粒度; 例如，五分之四的人可以消费任意数额，五分之三的人每天最高可花费10％，五分之二的人每天最高可花费0.5％。 此外，以太坊多重签名是异步的 - 双方可以在不同时间在区块链上注册其签名，最后一个签名将自动发送交易。5. Cloud computing. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.5.云计算。 EVM技术也可用于创建可验证的计算环境，这允许用户请求其他人进行计算，然后可选择的要求提供证据，这些证据来自正确完成的随机选择的检查点。 这允许创建一个云计算市场，任何用户都可以通过他们的台式机，笔记本电脑或专用服务器参与其中，现场检查和安全保证金可以确保系统是可信的（即节点不能因欺骗而获利）。 虽然这样的系统可能不适合所有的任务， 例如，需要高级别进程间通信的任务不能在大型节点云上轻松完成。 但是，其他任务更容易并行化; 诸如SETI @ home，folding @ home和遗传算法等项目可以很容易地在这样的平台之上实现。6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.6.点对点赌博。 任何数量的点对点赌博协议，例如Frank Stajano和Richard Clayton的Cyberdice，都可以在以太坊区块链上实施。 事实上最简单的赌博协议只是下一个块哈希差异的合约，并且可以从那里建立更高级的协议，以几乎为零的费用创建赌博服务，而且这些服务无法作弊。7. Prediction markets. Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.7.预测市场。 提供一个预言或SchellingCoin，预测市场也很容易实现，有SchellingCoin的预测市场可能被证明是第一个分布式组织的组织管理协议的“futarchy”主流应用。8. On-chain decentralized marketplaces, using the identity and reputation system as a base. 8.链上分布式市场，以身份与信誉系统为基础Miscellanea And Concerns 杂项和相关Modified GHOST Implementation 改进版“幽灵”协议实现The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.“Greedy Heaviest Observed Subtree”（GHOST）幽灵协议是Yonatan Sompolinsky和Aviv Zohar于2013年12月首次提出的一项创新。提出GHOST协议的背后的动机是，由于高作废率，目前快速确认的区块链受累于降低的安全性 - 因为块的网络传播需要一定的时间，如果矿工A挖出一个区块，然后矿工B在矿工A的区块传播到B之前碰巧挖掘另一个区块，那么矿工B的区块将最终浪费并且不会有助于网络安全。此外，还有一个集中化问题：如果矿工A是一个拥有30％算力的采矿池，而B拥有10％算力，那么A将有70％的时间产生作废块的风险（因为另外30％的时间A产生了最后一个块，因此将立即获取挖掘数据），而B将有90％的时间产生作废块的风险。因此，如果区块产生的间隔足够短以使作废率较高，则仅凭借其大小的优势，A将显著的更加的高效。通过将这两种效应相结合，快速生成区块的区块链将很可能导致一个采矿池具有足够百分比的网络算力，以实际控制采矿过程。As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it. To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%. Transaction fees, however, are not awarded to uncles.正如Sompolinsky和Zohar所描述的那样，GHOST通过在计算哪个链是“最长”时包含作废块来解决网络安全损失的第一个问题; 也就是说，在计算哪个区块链具有最大的工作量证明时，所包含的区块，不仅仅是一个区块的父区块和进一步的祖先区块，而且也包括作废区块后代的祖先区块（在以太坊术语中称为“叔区块”）。 为了解决第二个——中心化偏见问题，我们超越了Sompolinsky和Zohar所描述的协议，为作废区块提供奖励：一个作废区块可以获得基本奖励的87.5％，包含该作废区块的侄区块获得剩余的12.5％。 但是，交易费用不会奖给叔区块。Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, it is defined as follows:以太坊实现了一个只向下7层的简化版的GHOST。确切地说，它被定义成如下所述：A block must specify a parent, and it must specify 0 or more uncles 一个区块必须指定一个父区块，0或者多个叔区块An uncle included in block B must have the following properties: 一个被包含在B区块的叔区块必须拥有如下属性。It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7. 它必须是B区块的第k代祖先区块的直接子区块， 2 <= k <= 7。It cannot be an ancestor of B 它不能是B区块的祖先区块An uncle must be a valid block header, but does not need to be a previously verified or even valid block 叔区块必须是区块头有效的，但不必是先前验证的或者有效的区块An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion) 叔区块必须与所有的被包含在以前区块的叔区块不同，并且所有其他叔区块被包含在同一个区块中（非双重包含）For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward. 对每一个包含在B区块的叔区块U而言，挖掘出B区块的矿工获得额外的3.125%币基奖励，挖掘出U区块的矿工获得93.75%的标准的币基奖励。This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.这个限制性的GHOST版本，只有7代可使用，原因有两个。 首先，无限制的GHOST会在计算给定块的哪些叔区块合法时包含太多复杂因素。 其次，在以太坊中使用的无限制GHOST的补偿消除了激励矿工在主链挖矿，而不是成为主链的公共攻击者。Fees 费用Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums. This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price. The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it. Hence, tragedy-of-the-commons problems are very likely to occur.由于发布到区块链中的每个交易都会向网络施加需要下载和验证的成本，因此需要一些管理机制（通常涉及交易费用）来防止滥用。在比特币中使用的默认方法是纯粹自愿收费，依靠矿工作为守门人并设置动态最小值。这种方法在比特币社区中非常受欢迎，特别是因为它是“基于市场”的，允许通过矿工和交易发送者之间的供求来决定价格。然而，这种推理的问题在于，交易处理并非一个市场;尽管将交易处理作为矿工提供给发送方的服务进行交易处理具有直观的吸引力，但实际上，矿工包括的每一笔交易都需要由网络中的每个节点来处理，因此绝大多数处理交易的成本由第三方承担，而不是由作出是否将其纳入区块的决定的矿工承担。因此，很可能会发生公地悲剧问题。However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. The argument is as follows. Suppose that:然而，当给出一个特别不准确的简化假设时，这个基于市场的机制中证明了的缺陷，神奇地自行消除了。 论证如下。 假设：A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand. 一个交易导致 k 个操作，提供 kR 奖励给任何收录交易的矿工，此处R是交易发送者设置的，同时k和R（大体上）事先对于矿工是可预见的。An operation has a processing cost of C to any node (ie. all nodes have equal efficiency) 对于任何节点来说，一步操作的处理成本是C（假设所有的节点具有相同的效率）There are N mining nodes, each with exactly equal processing power (ie. 1/N of total) 这里有N个拥有相同处理能力的挖矿节点，（例如，单个节点就是 1/N）No non-mining full nodes exist.（不存在不挖矿的全节点）A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block, and the processing cost for the miner is simply kC. Hence, miners will include transactions where kR/N > kC, or R > NC. Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.如果期望的回报大于成本，矿工会愿意处理交易。 因此，期望的回报是kR / N，因为矿工有1 / N处理下一个块的机会，并且矿工的处理成本仅为kC。 因此，矿工将在区块中包含 kR / N> kC或R> NC的交易。 请注意，R是交易发送人提供的每次的操作费用，因此是交易发送人（译注：可能此处为笔误，应该为矿工）从交易中获得的收益的下限，NC是整个网络一起处理操作的成本。 因此，矿工只有动机去包含收益超过成本的那些交易。However, there are several important deviations from those assumptions in reality:然而，在现实世界，这些假设还存在几处重要的偏差：The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale. 因为额外的验证时间延迟了块的传播，从而增加了区块成为废区块的可能性，所以矿工在处理交易上所耗费的成本比其他验证节点的高。There do exist nonmining full nodes. 存在不挖矿的全节点。The mining power distribution may end up radically inegalitarian in practice. 实际上，挖矿算力分布可能最终极度不平衡。Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes. 以破坏网络为己任的投机者，政治敌人和疯子确实存在，并且他们可以巧妙地设置合约，使得他们的成本远低于其他验证节点。(1) provides a tendency for the miner to include fewer transactions, and (2) increases NC; hence, these two effects at least partially cancel each other out.How? (3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average. Specifically:（1）使得矿工包含更少的交易成为趋势，（2）增加NC; 因此，这两种效应至少部分相互抵消了。如何？ （3）和（4）是主要问题; 为了解决它们，我们只需设置一个浮动上限：任何块都不能有超过BLK_LIMIT_FACTOR 倍数的长期指数移动平均值的操作数。 具体地：blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)BLK_LIMIT_FACTOR and EMA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.BLK_LIMIT_FACTOR和EMA_FACTOR是暂时设置为65536和1.5的常量，但在进一步分析后可能会更改。There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales. In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate. This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.还有另一个因素阻碍大区块在比特币中存在：大区块需要更长的时间才能传播，因此有更高的可能性成为废区块。 在以太坊中，消耗gas较高的区块也可能需要较长的时间才能传播，因为它们物理上较大，并且处理事务状态转换需要较长的时间才能生效。 这种延迟抑制是比特币的重要考虑因素，但由于GHOST协议的存在，在Ethereum中这并不那么重要; 因此，依靠规定的区块限值可以提供更稳定的基线。Computation And Turing-Completeness计算和图灵完备An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways. First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2. Second, contracts can call other contracts, potentially allowing for looping through recursion. This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop? The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.一个重要的提醒是以太坊虚拟机是图灵完备的; 这意味着EVM代码可以编码任何可以实现的计算，包括无限循环。 EVM代码允许以两种方式循环。 第一种，有一个允许程序跳回到代码中的前一个点的JUMP指令，以及一个执行条件跳转的JUMPI指令，允许像x <27：x = x * 2这样的语句。第二种，合约可以调用其他合约，可能允许通过递归循环。 这自然会导致一个问题：恶意用户能否通过迫使他们进入无限循环来关闭矿池和完整节点？ 出现这个问题是因为计算机科学中存在一个问题，称为停止问题：在一般情况下，无法说明给定的程序是否会停止。As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid. Messages work in the same way. To show the motivation behind our solution, consider the following examples:正如状态转换部分所述，我们的解决方案的运行是通过要求交易设置允许采用的最大计算步骤数，如果执行时间更长，那么计算将会反转，但费用仍需仍会支付。 消息以相同的方式工作。 为了展示我们解决方案背后的动机，请考虑以下示例：An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.攻击者创建一个运行无限循环的合同，然后发送一个激活该循环的交易给矿工。 矿工将处理交易，运行无限循环，并等待它耗尽gas。 即使运行耗尽了gas，在运行到一半时停止了，交易仍然有效，并且矿工仍然可以要求攻击者为每个计算步骤支付费用。An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.攻击者创建了一个非常长的无限循环，其目的是迫使矿工持续计算这么长时间，所以当计算完成时，会有更多的区块产生出来，因此对于矿工（译注：负责计算非常长无限循环的矿工）来说包含交易索取费用将不再可能。 然而，攻击者将被要求提交一个STARTGAS的值，以限制可以执行的计算步骤的数量，所以矿工会提前知道计算过程需要极其大量的步骤。An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.攻击者通过某种形式的代码来查看合约，如send（A，contract.storage [A]）; contract.storage [A] = 0，并发送一个只有足够的gas来运行第一步但不是第二步的交易（即提款但不让余额下降）。 合约制定者不需要担心防范这种攻击，因为如果执行中途停止，更改将被恢复。A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem.金融合约通过采用九个专有数据反馈的中间值来降低风险。 攻击者接管其中一个数据反馈，该数据反馈旨在通过DAO部分中描述的可变地址呼叫机制进行修改，并将其转换为运行无限循环，从而强制任何尝试从金融合约索取利益的努力因耗尽gas而中止。 但是，金融合约可以设置消息的gas限制以防止此问题发生。The alternative to Turing-completeness is Turing-incompleteness, where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code. Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language? In reality, however, Turing-incompleteness is far from a neat solution to the problem. To see why, consider the following contracts:图灵完备性的替代是图灵不完备性，其中JUMP和JUMPI不存在，并且在任何给定时间只允许在调用堆栈中存在每个合约的一个副本。 在这个系统中，所描述的费用体系和我们解决方案效力的不确定性不再是必须，因为执行合同的成本将受到其规模的限制。 另外，图灵不完备性甚至也不是那么大的限制; 在我们内部构想的所有合约示例中，到目前为止，只有一个需要循环，即使那样也可以通过重复26行单行代码来消除该循环。 考虑到图灵完备性的严重影响以及有限的收益，为什么不简单地使用图灵不完备的语言呢？ 然而，事实上，图灵不完备性并不能很好地解决这个问题。 要明白为什么，请考虑以下合约：C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

...

C49: call(C50); call(C50);

C50: (run one step of a program and record the change in storage)Now, send a transaction to A. Thus, in 51 transactions, we have a contract that takes up 250computational steps. Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract). Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time. Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?现在，向A发送一笔交易。因此，在51笔交易中，我们有一份包含250个计算步骤的合约。矿工们可以尝试提前检测这种逻辑炸弹，方法是为每个合约保留一个值，限定其可以采取的最大计算步骤数，然后对递归调用其他合同的合同进行计算，但这要求矿工禁止合约创建其他合约（因为上述所有26份合约的创建和执行可以很容易地合并成一份合约）。另一个问题是，消息的地址字段是一个变量，所以一般情况下甚至不可能知道给定合约将提前调用哪些其他合约。因此，总而言之，我们得出了一个令人惊讶的结论：图灵完备性出奇地容易管理；除非有相同的控制措施，缺乏图灵完备性同样令人惊讶地难以管理 - 但在这种情况下，为什么不让协议成为图灵完备的呢？Currency And Issuance 货币和发行The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labelled:以太坊网络包括自己的内置货币，ether，它服务于如下双重目的，提供主要流动性层，以实现各种数字资产之间的有效交换，更重要的是，提供支付交易费用的机制。 为了方便和避免未来的争论（参见比特币当前的mBTC / uBTC / satoshi辩论），这些面值将被预先标记：1: wei10^12: szabo10^15: finney10^18: etherThis should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.这应该被视为“美元”和“美分”或“BTC”和“satoshi”概念的扩展版本。 在不久的将来，我们期望“ether”用于普通交易，“finney”用于微交易，“szabo”和“wei”用于费用和协议实施的技术讨论; 其余的面值可能会稍后变得有用，此时不应包含在客户端中。The issuance model will be as follows:发行模型将会是如下这样：Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.以太网将以 1000-2000ether/BTC 的价格进行货币销售，这一机制旨在为以太坊组织提供资金，并支付开发者报酬，这一方式已被其他平台（如Mastercoin和NXT）成功使用。 较早的买家将受益于较大的折扣。 从销售中获得的BTC将完全用于向开发者支付薪水和奖金，并投资于以太坊和加密货币生态系统中的各种营利和非盈利项目。0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.已售出总金额（60102216 ETH）的0.099x将分配给组织，以补偿早期贡献者，用以太币计价的方式支付在创世块诞生前的花费。0.099x the total amount sold will be maintained as a long-term reserve.已售总额的0.099将作为长期储备而保持。0.26x the total amount sold will be allocated to miners per year forever after that point.已售总额的0.26将每年被矿工挖出。Long-Term Supply Growth Rate (percent) 长期供应增长率（百分比）Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero除了线性的发行方式外，与比特币一样，随着时间的推移货币供应的增长率将无限接近0The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin. The justification of the endowment pool is as follows. If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable. Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before. The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x. Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.上述模型中的两个主要选择是（1）禀赋（译注：初始拥有的资源，详见知乎）池的存在和规模，以及（2）存在一个永久增长的线性供给，而不是像比特币那样的总量限制供给。 禀赋池存在的理由如下。 如果禀赋池不存在，线性发行量将减少到0.217x以提供相同的通货膨胀率，那么ether的总量将减少16.5％，因此每个单位的价值将增加19.8％。 因此，在平衡销售中，19.8%的ether将会被购买，所以每个单位将再次与以前一样有价值。 组织还将拥有与BTC等值的1.198x以太币，这可以被认为分为两部分：最初的BTC和额外的0.198x。 因此，这种情况与禀赋完全相同，但有一个重要区别：组织持有的是纯粹的BTC，因此并不支持以太币单位的价值。The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).永久性线性供给增长模型降低了一些人认为比特币中财富过度集中的风险，并且使得生活在当前和未来时代的个人有一个获得货币的公平机会，同时保留强烈的获取和持有动机，因为随着时间的推移，“供应增长率”百分比将趋近于零。 我们还可以从理论上证明，因为粗心大意，死亡等原因，以太币总是会随时间而减少，而以太币的流失可以模拟为每年总供给的百分比，因此流通中的货币总量实际上最终会稳定在一个数值，等于年发行额除以损失率（例如损失率为1％，一旦供应量达到26X，那么将开采0.26X，每年损失0.26X，创造均衡）。Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year. In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block. Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development. Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.请注意，在未来，以太坊很可能会转而采用权益证明模式来确保安全性，将发行要求降低至每年0至0.05X之间。 如果以太坊组织失去资金或出于任何其他原因而消失，我们将开放一个“社会契约”：任何人都有权创建一个未来候选版本的以太坊，唯一的条件是以太币的数量必须是 最多等于60102216 *（1.198 + 0.26 * n），其中n是创始块产生后的年数。 创建者可以自由地通过众筹或以其他方式分配PoS驱动的供应扩展和最大允许供应扩展之间的部分或全部差异，以支付开发费用。 不符合社区合约的候选版本的升级可能被合理地分叉为兼容版本。Mining Centralization 挖矿中心化The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.比特币挖掘算法的工作原理是，让矿工们一次又一次地对块头进行修改过的版本进行SHA256计算，直到一个节点产生一个散列值小于目标的值（当前大约在2^192）。但是，这种挖掘算法容易受到两种形式的集中管理的伤害。第一种，挖矿生态系统已经被ASIC（专用集成电路），计算机芯片所主宰，这些芯片被设计用于比特币挖矿的特定任务，因此效率高出数千倍。这意味着比特币挖掘不再是一种高度分散的和平等的追求，需要数百万美元的资金才能有效参与。第二种，大多数比特币矿工实际上并未在本地进行块验证;相反，他们依靠中央采矿池来提供块头。这个问题可以说是更糟的：截至撰写本文时，前三位的矿池共同间接控制了比特币网络中大约50％的处理能力，虽然在有矿池或联盟试图发起51%攻击时，矿工们可以转移到其他矿池，来减轻这个问题。The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.以太坊目前的意图是使用挖掘算法，矿工需要从状态中提取随机数据，计算区块链中最后N个块的一些随机选择的交易，并返回结果的散列值。 这有两个重要的好处。 首先，以太坊合约可以包括任何种类的计算，因此以太坊ASIC本质上只能当成一般计算的ASIC -例如， 一个更好的CPU。 其次，采矿需要访问整个区块链，迫使矿工存储整个区块链，并至少能够验证每笔交易。 这消除了对集中式矿池的需求; 虽然矿池仍然可以起到平衡奖励分配随机性的合法作用，但这种功能可以通过没有中央控制的对等池进行同样的服务。This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.该模型未经测试，在使用合约执行作为挖掘算法时，避免某些巧妙的优化方法可能会遇到困难。 然而，这种算法的一个值得注意的特点是，它允许任何人通过将大量合约引入专门设计用于阻碍特定ASIC的运行，这好比“井里下毒”。由于经济激励措施存在，ASIC制造商会使用这种技巧来进行互相攻击。 因此，我们正在开发的解决方案最终是一种，适应的经济人，而非纯粹的技术解决方案。Scalability 可扩展性One common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour. If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year). Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.关于以太坊的一个常见问题是可扩展性问题。 和比特币一样，以太坊也面临着每个交易需要由网络中的每个节点处理的缺陷。 使用比特币，目前区块链的规模约为15 GB，每小时增长约1 MB。 如果比特币网络每秒处理Visa 2000次交易，则每三秒钟增长1MB（每小时1GB，每年8TB）。 以太坊可能会遭受类似的增长模式，事实上更糟糕的是，在以太坊区块链上将会有许多应用程序，而不仅仅是像比特币一样的货币，但是由于事实上的改进，以太坊全节点需要存储的只是状态而不是整个区块链历史。The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue.如此大的区块链的问题是集中化风险。如果区块链大小增加到100TB，那么可能的情况是只有极少数的大型企业会运行全节点，所有普通用户都使用轻型SPV节点。在这种情况下，可能会出现这样的担忧：全部节点可以连接在一起，并且都同意以某种有利的方式作弊（例如，改变块奖励，给自己BTC）。轻节点将无法立即检测到这一点。当然，至少有一个诚实的完整节点可能存在，几个小时后，关于欺诈的信息将通过像Reddit这样的渠道流淌出来，但那时就太迟了：要由普通用户组织起来努力将给定的区块列入黑名单，这是一个巨大而且不可行的协调问题，在类似的规模上，这相当于成功抵御51％攻击。就比特币而言，目前这是一个问题，但是彼得托德提出的区块链修改建议会缓解这个问题。In the near term, Ethereum will use two additional strategies to cope with this problem. First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes. Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect. Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i-1] is correct. The verifying node would provide the index i, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i]. Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided.在短期内，以太坊将采用另外两种策略来解决这个问题。首先，由于基于区块链的挖掘算法，至少每个矿工将被迫成为一个完整的节点，从而在全节点的数量上形成了一个下限。其次，更重要的是，在处理每个交易之后，我们将在区块链中包含一个中间状态树根。即使块验证是集中式的，只要存在一个诚实的验证节点，集中问题就可以通过验证协议规避。如果一个矿工发布了一个无效块，那么该块必须格式化得很差，或者状态S [n]不正确。由于已知S [0]是正确的，所以在S [i-1]正确的情况下，必定有一些第一状态S [i]不正确。验证节点将提供索引 i 以及由需要处理APPLY（S [i-1]，TX [i]） - > S [i]的Patricia树节点的子集组成的“无效证明”。节点将能够使用这些节点来运行该部分计算，并且看到生成的S [i]与提供的S [i]不匹配。Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.另一个更复杂的攻击将涉及恶意的矿工发布不完整的块，因此甚至不存在全部信息来确定块是否有效。 对此的解决方案是 质疑-响应 协议：验证节点以目标交易索引的形式发出“质疑”，接收到信息的节点，轻节点将该块视为不可信，直到另一节点（无论是矿工还是另一验证者）提供Patricia 节点的一个子集作为有效性的证明。Conclusion 结论The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language. The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer. Finally, there is also a substantial array of applications that have nothing to do with money at all.以太坊协议最初被设想为加密货币的升级版本，通过高度通用的编程语言提供高级功能，如区块链托管，取款限制，金融合约，赌博市场等。以太坊协议不会直接“支持”任何应用程序，但是图灵完备的编程语言的存在意味着可以在理论上为任何交易类型或应用程序创建任意合约。然而，以太坊更有趣的是以太坊协议远远超出了货币。有关分布式文件存储，分布式计算和分布式预测市场的协议，以及其他几十种这样的概念，都有可能极大提高计算行业的效率，并首次通过添加经济层为其他P2P协议提供有力的支撑。最后，还有大量与金钱无关的应用程序。The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.由以太坊协议实施的任意状态转换功能的概念提供了一个具有独特潜力的平台; 而不是一个封闭式的单一用途协议，专门用于数据存储，赌博或金融领域的特定应用。以太坊在设计上是开放式的，在今后几年中，我们相信它非常适合作为大量的财务和非财务协议的基础协议。Notes and Further Reading 注释与延伸阅读Notes 注释A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself. However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself. This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.一个有经验的读者可能会注意到，实际上比特币地址是椭圆曲线公钥的散列值，而不是公钥本身。 然而，事实上，将公钥散列作为公钥本身就是完全合法的加密术语。 这是因为比特币的密码学可以被认为是一种自定义的数字签名算法，其中公钥由ECC公钥的散列组成，签名由与ECC签名串联的ECC公钥组成，并且验证算法涉及检查ECC 签名中的公钥与作为公钥提供的ECC 公钥哈希签名，然后根据ECC pubkey验证ECC签名。Technically, the median of the 11 previous blocks. 从技术上来看，前11个区块的中位数Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1.在内部，2和“CHARLIE”都是数字，后一个有巨大的base256编码格式。 数字从0到2^256-1不等。Further Reading 延伸阅读Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/Smart property: https://en.bitcoin.it/wiki/Smart_PropertySmart contracts: https://en.bitcoin.it/wiki/ContractsB-money: http://www.weidai.com/bmoney.txtReusable proofs of work: http://www.finney.org/~hal/rpow/Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.htmlBitcoin whitepaper: http://bitcoin.org/bitcoin.pdfNamecoin: https://namecoin.org/Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangleColored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/editMastercoin whitepaper: https://github.com/mastercoin-MSC/specDecentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#SimplifiedpaymentverificationMerkle trees: http://en.wikipedia.org/wiki/Merkle_treePatricia trees: http://en.wikipedia.org/wiki/Patricia_treeGHOST: https://eprint.iacr.org/2013/881.pdfStorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.htmlMike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5YEthereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLPEthereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-TreePeter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/编辑于 2018-02-23 16:09白皮书​赞同 86​​5 条评论​分享​喜欢​收藏​申请转载​文章被以下专栏收录BTC深入浅出BTC是最大的共识链链布网区块链知

以太坊开发文档 | ethereum.org

发文档 | ethereum.org跳转至主要内容学习用法构建参与研究搜索​​​​语言 ZH帮助更新此页面本页面有新版本，但现在只有英文版。请帮助我们翻译最新版本。翻译页面没有错误！此页面未翻译，因此特意以英文显示。不再显示Change page概述基础主题以太坊简介以太币简介去中心化应用程序简介Web2 与 Web3 的对比帐户交易区块以太坊虚拟机 (EVM)操作码Gas费用节点和客户端运行节点客户端多样性节点即服务节点架构轻客户端归档节点引导节点网络共识机制工作量证明矿工挖矿算法Dagger-HashimotoEthash权益证明Gasper弱主观性认证权益证明机制的奖励和惩罚权益证明攻击与防御密钥权益证明与工作量证明提出区块权益正明常见问题以太坊堆栈堆栈简介智能合约智能合约语言智能合约结构智能合约库测试用智能合约编译智能合约部署智能合约验证智能合约升级智能合约智能合约安全性智能合约形式化验证可组合性开发网络开发框架以太坊客户端APIJavaScript API后端APIJSON-RPC数据和分析区块浏览器存储集成开发环境 (IDE)编程语言DartDelphi.NETGolangJavaJavaScriptPythonRubyRust语言高级链桥标准令牌标准ERC-20：同质化代币ERC-721：非同质化代币 (NFT)ERC-777ERC-1155ERC-4626最大可提取价值 (MEV)预言机缩放乐观卷叠零知识卷叠状态通道侧链以太坊 Plasma 扩容解决方案Validium数据可用性网络层网络地址门户网络数据结构与编码默克尔前缀树递归长度前缀编码 (RLP)简单序列化 (SSZ)Web3 密钥存储定义设计基础设计和用户体验简介以太坊开发文档c上次修改时间: @cuijia(opens in a new tab), Invalid DateTime查看贡献者在本页面开发单元基础主题以太坊堆栈高级本文档旨在帮助你构建以太坊。 它介绍了以太坊概念，解释了以太坊技术栈，并记录了以太坊更复杂的应用和使用案例的高级主题。基于开源社区的努力，你可以随时提出新的主题，添加新内容，并在认为可能有用的地方提供示例。 所有文档都可以通过 GitHub 编辑 — 如果不确定如何操作，请遵循这些说明(opens in a new tab)。开发单元如果这是你首次尝试以太坊开发，我们建议从头开始，有始有终，从头到尾。基础主题以太坊简介 – 以太坊简要概述以太币简介 – ETH 简要概述去中心化应用程序简介 – 去中心化应用程序简介Web2 与 Web3 的对比 – 基于区块链的应用程序提供的基本差异帐户 – 网络中能够持有余额和发送交易的实体交易 – 转账和其他导致以太坊状态变化的行为区块 – 交易分批进行，以确保状态在所有行为者之间同步。以太坊虚拟机 (EVM) – EVM 处理以太坊网络上的所有计算操作码Gas费用 – 交易处理所需的算力，由交易汇款人使用 ETH 支付节点和客户端 – 参与网络的个人和他们运行的交易验证软件运行节点客户端多样性节点即服务节点架构轻客户端归档节点引导节点网络 – 部署以太坊，包括测试网络共识机制 – 分布式网络的各个节点如何就系统的当前状态达成共识工作量证明权益证明以太坊堆栈堆栈简介 – 以太坊/web3 堆栈概述智能合约 – 驻留在以太坊地址并在交易触发时运行功能的程序智能合约语言智能合约结构智能合约库测试用智能合约编译智能合约部署智能合约验证智能合约升级智能合约智能合约安全性智能合约形式化验证可组合性开发网络 – 用于在部署前测试 dapp 的本地区块链环境开发框架 – 方便以太坊开发的工具以太坊客户端API – 便利库，允许你的 web 应用程序与以太坊和智能合同交互JavaScript API后端APIJSON-RPC数据和分析 – 区块链数据如何汇总、组织并实施到 dapp 中区块浏览器存储 – 去中心化储存结构和机制集成开发环境 (IDE) – 写入 dapp 代码的最佳环境编程语言 – 如何使用你可能已经知道的语言开始使用以太坊DartDelphi.NETGolangJavaJavaScriptPythonRubyRust语言高级链桥 – 面向开发者的桥接概述标准 – 商定的协议，以保持项目效率和社区可及性令牌标准最大可提取价值 (MEV) – 从除了区块奖励之外的以太坊区块链中提取价值预言机 – 如何将信息注入到以太坊区块链中缩放 – 随着以太坊的发展，维护去中心化和安全的方法乐观卷叠零知识卷叠状态通道侧链以太坊 Plasma 扩容解决方案Validium数据可用性 – docs-nav-data-availability-description网络层 – 以太坊网络层的解释网络地址门户网络数据结构与编码 – 以太坊堆栈中使用的数据结构和编码方案的解释默克尔前缀树递归长度前缀编码 (RLP)简单序列化 (SSZ)Web3 密钥存储定义back-to-top ↑本文对你有帮助吗？是否下一页以太坊简介编辑页面(opens in a new tab)在本页面开发单元基础主题以太坊堆栈高级网站最后更新: 2024年2月16日(opens in a new tab)(opens in a new tab)(opens in a new tab)使用以太坊查找钱包获取以太币Dapps - 去中心化应用二层网络运行节点稳定币质押ETH学习学习中心什么是以太坊？什么是以太币 (ETH)？以太坊钱包Gas fees以太坊安全和预防欺诈措施什么是 Web3？智能合约以太坊能源消耗以太坊路线图以太坊改进提案 （Eip）以太坊的历史以太坊白皮书以太坊词汇表以太坊治理区块链桥零知识证明测试中心开发者开始体验相关文档教程通过编码来学习设置本地环境生态系统社区中心以太坊基金会以太坊基金会的博客(opens in a new tab)生态系统支持方案(opens in a new tab)以太坊漏洞悬赏计划生态系统资助计划以太坊品牌资产Devcon(opens in a new tab)企业级应用主网以太坊私密以太坊企业级应用关于ethereum.org关于我们工作机会参与贡献语言支持隐私政策使用条款缓存政策联系我们(opens in a new t

GitHub - ethereum/yellowpaper: The "Yellow Paper": Ethereum's formal specification

GitHub - ethereum/yellowpaper: The "Yellow Paper": Ethereum's formal specification

Skip to content

Toggle navigation

Sign in

Product

Actions

Automate any workflow

Packages

Host and manage packages

Security

Find and fix vulnerabilities

Codespaces

Instant dev environments

Copilot

Write better code with AI

Code review

Manage code changes

Issues

Plan and track work

Discussions

Collaborate outside of code

Explore

All features

Documentation

GitHub Skills

Blog

Solutions

For

Enterprise

Teams

Startups

Education

By Solution

CI/CD & Automation

DevOps

DevSecOps

Resources

Learning Pathways

White papers, Ebooks, Webinars

Customer Stories

Partners

Open Source

GitHub Sponsors

Fund open source developers

The ReadME Project

GitHub community articles

Repositories

Topics

Trending

Collections

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Search

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

Sign up

You signed in with another tab or window. Reload to refresh your session.

You signed out in another tab or window. Reload to refresh your session.

You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

ethereum

/

yellowpaper

Public

Notifications

Fork

495

Star

1.6k

The "Yellow Paper": Ethereum's formal specification

License

CC-BY-SA-4.0 license

1.6k

stars

495

forks

Branches

Tags

Activity

Star

Notifications

Code

Issues

85

Pull requests

23

Actions

Projects

0

Security

Insights

Additional navigation options

Code

Issues

Pull requests

Actions

Projects

Security

Insights

ethereum/yellowpaper

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

 masterBranchesTagsGo to fileCodeFolders and filesNameNameLast commit messageLast commit dateLatest commit History1,463 Commits.gitignore.gitignore  .travis.yml.travis.yml  BRANCHES.mdBRANCHES.md  Biblio.bibBiblio.bib  IEEEbib.bstIEEEbib.bst  JS.texJS.tex  LICENCE.mdLICENCE.md  Paper.reflibPaper.reflib  Paper.texPaper.tex  README.mdREADME.md  Wire.texWire.tex  build.shbuild.sh  cancel.stycancel.sty  deploykey.encdeploykey.enc  travis_deploy.shtravis_deploy.sh  View all filesRepository files navigationREADMECC-BY-SA-4.0 licenseEthereum Yellow Paper

The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Nick Savers and with contributions from many people around the world.

It is a free culture work, licensed under Creative Commons Attribution Share-Alike (CC-BY-SA) Version 4.0.

Repository Currently Outdated

The Yellow Paper is out of date. It reflects the Ethereum specification up to the Paris network upgrade ("the merge"), activated on the Ethereum mainnet at block 15_537_394 (September 2022).

It does not contain changes introduced in any post-merge upgrade.

An alternative Python Execution Layer specification is actively maintained and up to date.

Usage

If you just want to read the paper, the latest version is generally available as a PDF at https://ethereum.github.io/yellowpaper/paper.pdf. If you find that the borders for links block too much text when viewing the PDF in the browser, you can instead download it and open and view it with a PDF viewer application such as Adobe Acrobat or Evince, where the borders are less likely to display over text.

However, if you want to edit the paper, then read on. The paper comes as a single latex file Paper.tex.

It is recommended to use an IDE such as Visual Studio Code with the LaTeX Workshop extension, to edit the tex file, and show the PDF.

Another option is to separately edit the tex file and build as follows (you'll still need to clone the repo then open the yellowpaper folder):

git clone https://github.com/ethereum/yellowpaper.git

cd yellowpaper

./build.sh

This will create a PDF version of the Yellow Paper. Following building, you can also use standard pdflatex tools for compiling/preview, like http://latex.informatik.uni-halle.de/latex-online/latex.php.

Tips on editing

You can use TeX Stack Exchange; https://en.wikibooks.org/wiki/LaTeX/ (e.g. Bibliography Management and Hyperlinks); and BibTeX editor.

Versions

The previous protocol versions are listed in BRANCHES.md.

Other language versions

Chinese translated by YuanGe and GaoTianlu.

French translated by Asseth (checkout to branch 'french' ).

Vietnamese translated by KodyFanz (checkout to branch 'vietnamese').

About

The "Yellow Paper": Ethereum's formal specification

Resources

Readme

License

CC-BY-SA-4.0 license

Activity

Custom properties

Stars

1.6k

stars

Watchers

101

watching

Forks

495

forks

Report repository

Releases

No releases published

Packages

0

No packages published

Contributors

82

+ 68 contributors

Languages

TeX

99.3%

Shell

0.7%

Footer

© 2024 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

以太坊白皮书精读详解（1）——比特币及现有密码学货币概念介绍 - 知乎

以太坊白皮书精读详解（1）——比特币及现有密码学货币概念介绍 - 知乎首发于区块链商业分析切换模式写文章登录/注册以太坊白皮书精读详解（1）——比特币及现有密码学货币概念介绍无住居士学心学，致良知文/罗辑。首发于微信公众号区块链森林。前言比特币应用区块链技术创建了一个电子货币系统，以太坊则开启了区块链从比特币走向无限可能的旅程。以太坊定位为下一代智能合约和去中心化应用平台，它搭建了区块链基础设施，开发者可以利用以太坊开发智能合约和各种去中心化应用。如果我们把区块链和互联网类比，比特币就相当于互联网早期的电子邮件系统，它只有一个功能：发送邮件；以太坊则相当于一个浏览器，开发者可以开发各式各样的网站，用户可以打开浏览器看新闻资讯、听音乐、买东西、发动态。在浏览器发明以后，互联网诞生了雅虎、亚马逊、新浪、网易、搜狐、谷歌、百度、Facebook、微博。去中心化应用则相当于各式各样的网站，只不过网站是运行在中心化的服务器上的，而去中心化应用是运行在一个由无数台个人电脑及其他计算设备组成的分布式计算平台上的。这个分布式计算平台的运行规则是包括时间戳、挖矿机制、默克尔树等一系列算法、协议组成的区块链技术。至于什么是区块链的具体运行机制，以及可以在以太坊上开发什么样的应用。我们需要仔细研读这份白皮书，理清以太坊系统运行机制，发现以太坊背后的设计理念，理解以太坊的应用方式。本文的体例如下：原文中译本：以太坊白皮书的中文译文，摘自以太坊爱好者社区https://ethfans.org ，译者为巨蟹 、少平，本文在引用中对个别表述做了修改。中译本地址：https://ethfans.org/wikis/%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6英文原版地址：https://github.com/ethereum/wiki/wiki/White-Paper详解：梳理白皮书结构，解释设计机制，探讨设计理念，补充背景知识。发布说明：以太坊白皮书共分为四部分：比特币及现有密码学货币概念的介绍以太坊应用杂项和关注这份精读详解分为四篇，每篇介绍其中一章。正文题目以太坊（Ethereum ）:下一代智能合约和去中心化应用平台（A Next-Generation Smart Contract and Decentralized Application Platform）详解题目点明了以太坊的定位：下一代智能合约和去中心化应用平台。智能合约是以太坊一个标志性的能力。与比特币定义为一个电子货币系统不同，以太坊不计划做一个单一应用，而是要成为一个应用平台，一个基于区块链技术的新世界的基础设施。摘要当中本聪在2009年1月启动比特币区块链时，他同时向世界引入了两种未经测试的革命性的新概念。第一种就是比特币（bitcoin），一种去中心化的点对点的网上货币，在没有任何资产担保、内在价值或者中心发行者的情况下维持着价值。到目前为止，比特币已经吸引了大量的公众注意力, 就政治方面而言它是一种没有中央银行的货币并且有着剧烈的价格波动。然而，中本聪的伟大试验还有与比特币同等重要的一部分：基于工作量证明的区块链概念使得人们可以就交易顺序达成共识。作为应用的比特币可以被描述为一个先申请（first-to-file）系统：如果某人有50BTC并且同时向A和B发送这50BTC，只有被首先被确认的交易才会生效。没有固有方法可以决定两笔交易哪一笔先到，这个问题阻碍了去中心化数字货币的发展许多年。中本聪的区块链是第一个可靠的去中心化解决办法。现在，开发者们的注意力开始迅速地转向比特币技术的第二部分，区块链怎样应用于货币以外的领域。常被提及的应用包括使用链上数字资产来代表定制货币和金融工具（彩色币），某种基础物理设备的所有权（智能资产），如域名一样的没有可替代性的资产（域名币）以及如去中心化交易所，金融衍生品，点到点赌博和链上身份和信誉系统等更高级的应用。另一个常被问询的重要领域是“智能合约”- 根据事先任意制订的规则来自动转移数字资产的系统。例如，一个人可能有一个存储合约，形式为“A可以每天最多提现X个币，B每天最多Y个，A和B一起可以随意提取，A可以停掉B的提现权”。这种合约的符合逻辑的扩展就是去中心化自治组织（DAOs）-长期的包含一个组织的资产并把组织的规则编码的智能合约。以太坊的目标就是提供一个带有内置的成熟的图灵完备语言的区块链，用这种语言可以创建合约来编码任意状态转换功能，用户只要简单地用几行代码来实现逻辑，就能够创建以上提及的所有系统以及许多我们还想象不到的的其它系统。详解中本聪在比特币中应用的区块链技术，成为了新一轮技术创新的基石。基于工作量证明机制的区块链技术解决了一个难题：双重支付问题。我们能够低成本地使用互联网内容，是基于信息的一个特性，近乎零成本地复制。我们通过互联网消费信息、视频、音乐、软件、数据，实际上我们消费的是这些内容的复制品。然而，有一些东西，我们并不想要复制品，因为那复制品没有任何价值，比如货币，比如知识产权、地产、房产、资产等权益。我们不想花费数百万买复制品也有效的房产证，创作者们不希望自己的作品被人们无偿地复制，我们不想要在收到一个人支付的账款时，付款人又将同一笔钱同时支付给了另一个人。信息可以复制，权益不应该被复制。如果不解决双重支付问题，一切的权益就无法通过互联网交易、流通。现行的解决方案是引入权威的第三方，比如银行、房产交易中心、版权鉴定中心等。然而这些机构阻碍了交易的效率，提高了交易的成本，而且还不安全，一旦中心化机房被黑客攻击，数据会被泄露、信息会被篡改。现在，中本聪应用区块链技术解决了在分布式去中心化网络中货币交易的问题，接下来，开发者们希望将区块链技术应用在其他的领域，如金融领域的对冲合约、股权对赌协议及其他金融衍生品交易；如类金融领域的权益交易和登记，如知识产权、房产、地产、虚拟资产等；如非金融领域的去中心化自治等。以太坊的目标就是要解决以上领域的问题，成为价值互联网的基础设施，让人们可以基于以太坊创建智能合约和去中心化应用。一、比特币及现有密码学货币相关概念的介绍本章包括以下内容：去中心化数字货币的历史作为状态转换系统的比特币挖矿默克尔树替代区块链应用脚本1.去中心化数字货币的历史去中心化的数字货币概念，正如财产登记这样的替代应用一样，早在几十年以前就被提出来了。1980和1990年代的匿名电子现金协议，大部分是以乔姆盲签技术（Chaumian blinding）为基础的。这些电子现金协议提供具有高度隐私性的货币，但是这些协议都没有流行起来，因为它们都依赖于一个中心化的中介机构。1998年，戴伟（Wei Dai）的b-money首次引入了通过解决计算难题和去中心化共识创造货币的思想，但是该建议并未给出如何实现去中心化共识的具体方法。2005年，芬尼（Hal Finney）引入了“可重复使用的工作量证明机制”（reusable proofs of work）概念，它同时使用b-money的思想和Adam Back提出的计算困难的哈希现金（Hashcash）难题来创造密码学货币。但是，这种概念再次迷失于理想化，因为它依赖于可信任的计算作为后端。因为货币是一个先申请应用，交易的顺序至关重要，所以去中心化的货币需要找到实现去中心化共识的方法。比特币以前的所有电子货币协议所遇到的主要障碍是，尽管对如何创建安全的拜占庭问题容错（Byzantine-fault-tolerant）多方共识系统的研究已经历时多年，但是上述协议只解决了问题的一半。这些协议假设系统的所有参与者是已知的，并产生如“如果有N方参与到系统中，那么系统可以容忍N/4的恶意参与者”这样形式的安全边界。然而这个假设的问题在于，在匿名的情况下，系统设置的安全边界容易遭受女巫攻击，因为一个攻击者可以在一台服务器或者僵尸网络上创建数以千计的节点，从而单方面确保拥有多数份额。中本聪的创新是引入这样一个理念：将一个非常简单的基于节点的去中心化共识协议与工作量证明机制结合在一起。节点通过工作量证明机制获得参与到系统的权利，每十分钟将交易打包到“区块”中，从而创建出不断增长的区块链。拥有大量算力的节点有更大的影响力，但获得比整个网络更多的算力比创建一百万个节点困难得多。尽管比特币区块链模型非常简陋，但是实践证明它已经足够好用了，在未来五年，它将成为全世界两百个以上的货币和协议的基石。详解本节简要介绍了去中心化数字货币的发展历史，创建一个数字货币的难点就在于如何保证交易顺序，避免双重支付。在中本聪之前的尝试都没有能够成功实践。中本聪的创新是：通过时间戳服务为交易排序；通过工作量证明机制使得交易被强制按照时间顺序打包进区块；通过CPU投票制使得有效区块发展成为最长的链条。工作量证明机制使得篡改交易记录变的成本极高，成功概率极低。关于比特币的运行机制可参见万字长文 | 比特币白皮书精读详解。在本章中，V神也详细说明了比特币的运行机制。2.作为状态转换系统的比特币从技术角度讲，比特币账本可以被认为是一个状态转换系统，该系统包括所有现存的比特币所有权状态和“状态转换函数”。状态转换函数以当前状态和交易为输入，输出新的状态。例如，在标准的银行系统中，状态就是一个资产负债表，一个从A账户向B账户转账X美元的请求是一笔交易，状态转换函数将从A账户中减去X美元，向B账户增加X美元。如果A账户的余额小于X美元，状态转换函数就会返回错误提示。所以我们可以如下定义状态转换函数：APPLY(S,TX) ­> S' or ERROR在上面提到的银行系统中，状态转换函数如下：APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30,Bob: $70 }但是：APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR比特币系统的“状态”是所有已经被挖出的、没有花费的比特币（技术上称为“未花费的交易输出，unspent transaction outputs 或UTXO”）的集合。每个UTXO都有一个面值和所有者（由20个字节的本质上是密码学公钥的地址所定义[1]）。一笔交易包括一个或多个输入和一个或多个输出。每个输入包含一个对现有UTXO的引用和由与所有者地址相对应的私钥创建的密码学签名。每个输出包含一个新的加入到状态中的UTXO。在比特币系统中，状态转换函数APPLY(S,TX)->S’大体上可以如下定义：交易的每个输入：如果引用的UTXO不存在于现在的状态中（S），返回错误提示如果签名与UTXO所有者的签名不一致，返回错误提示如果所有的UTXO输入面值总额小于所有的UTXO输出面值总额，返回错误提示返回新状态S’,新状态S中移除了所有的输入UTXO，增加了所有的输出UTXO。第一步的第一部分防止交易的发送者花费不存在的比特币，第二部分防止交易的发送者花费其他人的比特币。第二步确保价值守恒。比特币的支付协议如下。假设Alice想给Bob发送11.7BTC。事实上，Alice不可能正好有11.7BTC。假设，她能得到的最小数额比特币的方式是：6+4+2=12。所以，她可以创建一笔有3个输入，2个输出的交易。第一个输出的面值是11.7BTC，所有者是Bob（Bob的比特币地址），第二个输出的面值是0.3BTC，所有者是Alice自己，也就是找零。详解什么是状态转换呢？状态：比特币系统的“状态”是所有已经被挖出的、没有花费的比特币（技术上称为“未花费的交易输出，unspent transaction outputs 或UTXO”）的集合。每个UTXO都有一个面值和所有者（由20个字节的本质上是密码学公钥的地址所定义）。UTXO 可以理解为一条账目记录，包括账户余额和地址（所有者）。转换：状态转换函数执行的就是交易，例如A账户转账给B账户X美元。为什么V神要专门讲状态转换这件事呢？因为状态的转换正是价值交易的基本形态，A转给B一笔钱，一套房子，一公顷土地，正是一种状态的转换，它有别于信息的复制。A转给B之后，这个被交易的价值就从A的账户进入了B的账户。比特币的交易遵循价值守恒定律，它要求：付款者的账户余额必须大于等于它要支付的金额；付款者必须从自己的账户余额中支付；付款者将一笔钱支付给收款者A时，它就不能再支付给B。状态转换这四个字描述了价值交易的基本形态，任何的价值交易严格遵循它。从区块链技术的角度来讲，状态转换就形成了一个交易记录，是比特币交易序列的基础组成部分，是区块中的基本元素。下一节的挖矿中讲区块链的生成。3.挖矿一个区块，每个区块包含一个时间戳、一个随机数、一个对上一个区块的引用（即哈希）和上一区块生成以来发生的所有交易列表。这样随着时间流逝就创建出了一个持续增长的区块链，它不断地更新，从而能够代表比特币账本的最新状态。依照这个范式，检查一个区块是否有效的算法如下：检查区块引用的上一个区块是否存在且有效。检查区块的时间戳是否晚于以前的区块的时间戳，而且早于未来2小时[2]。检查区块的工作量证明是否有效。将上一个区块的最终状态赋于S[0]。假设TX是区块的交易列表，包含n笔交易。对于属于0……n-1的所有i,进行状态转换S[i+1] = APPLY(S[i],TX[i])。如果任何一笔交易i在状态转换中出错，退出程序，返回错误。返回正确，状态S[n]是这一区块的最终状态。本质上，区块中的每笔交易必须提供一个正确的状态转换，要注意的是，“状态”并不是编码到区块的。它纯粹只是被校验节点记住的抽象概念，对于任意区块都可以从创世状态开始，按顺序加上每一个区块的每一笔交易，（妥妥地）计算出当前的状态。另外，需要注意矿工将交易收录进区块的顺序。如果一个区块中有A、B两笔交易，B花费的是A创建的UTXO，如果A在B以前，这个区块是有效的，否则，这个区块是无效的。区块验证算法的有趣部分是“工作量证明”概念：对每个区块进行SHA256哈希处理，将得到的哈希视为长度为256比特的数值，该数值必须小于不断动态调整的目标数值，本书写作时目标数值大约是2^190。工作量证明的目的是使区块的创建变得困难，从而阻止女巫攻击者恶意重新生成区块链。因为SHA256是完全不可预测的伪随机函数，创建有效区块的唯一方法就是简单地不断试错，不断地增加随机数的数值，查看新的哈希数值是否小于目标数值。如果当前的目标数值是2^192，就意味着平均需要尝试2^64次才能生成有效的区块。一般而言，比特币网络每隔2016个区块重新设定目标数值，保证平均每十分钟生成一个区块。为了对矿工的计算工作进行奖励，每一个成功生成区块的矿工有权在区块中包含一笔凭空发给他们自己25BTC的交易。另外，如果交易的输入大于输出，差额部分就作为“交易费用”付给矿工。顺便提一下，对矿工的奖励是比特币发行的唯一机制，创世状态中并没有比特币。为了更好地理解挖矿的目的，让我们分析比特币网络出现恶意攻击者时会发生什么。因为比特币的密码学基础是非常安全的，所以攻击者会选择攻击没有被密码学直接保护的部分：交易顺序。攻击者的策略非常简单：向卖家发送100BTC购买商品（尤其是无需邮寄的电子商品）。等待直至商品发出。创建另一笔交易，将相同的100BTC发送给自己的账户。使比特币网络相信发送给自己账户的交易是最先发出的。一旦步骤（1）发生，几分钟后矿工将把这笔交易打包到区块，假设是第270000个区块。大约一个小时以后，在此区块后面将会有五个区块，每个区块间接地指向这笔交易，从而确认这笔交易。这时卖家收到货款，并向买家发货。因为我们假设这是数字商品，攻击者可以即时收到货。现在，攻击者创建另一笔交易，将相同的100BTC发送到自己的账户。如果攻击者只是向全网广播这一消息，这一笔交易不会被处理。矿工会运行状态转换函数APPLY(S,TX)，发现这笔交易将花费已经不在状态中的UTXO。所以，攻击者会对区块链进行分叉，将第269999个区块作为父区块重新生成第270000个区块，在此区块中用新的交易取代旧的交易。因为区块数据是不同的，这要求重新进行工作量证明。另外，因为攻击者生成的新的第270000个区块有不同的哈希，所以原来的第270001到第270005的区块不指向它，因此原有的区块链和攻击者的新区块是完全分离的。在发生区块链分叉时，区块链长的分支被认为是诚实的区块链，合法的的矿工将会沿着原有的第270005区块后挖矿，只有攻击者一人在新的第270000区块后挖矿。攻击者为了使得他的区块链最长，他需要拥有比除了他以外的全网更多的算力来追赶（即51%攻击）。详解本节首先介绍了区块的内容，以及验证区块是否有效的算法。区块的算法保证了交易序列中的交易记录真实有效、严格按照时间排序，这样来形成一个全网唯一公认的交易序列。具体的步骤原文讲解的很详细，此处不再赘述。为什么要设计工作量证明这个机制呢？浪费计算资源、浪费电力、还降低了交易效率。就为了一个目的：安全工作量证明的目的是使区块的创建变得困难，从而阻止女巫攻击者恶意重新生成区块链。假如任何人不花费任何成本就可以记账，那么也就意味着任何人不花费任何成本就可以作假，伪造交易记录。攻击者对于比特币的攻击方式，就是制造双重支付。要使得双重支付生效，攻击者就必须将自己伪造的交易记录打包进区块，赶上并且超越合法的的链条。由于有工作量证明机制的存在，导致攻击者必须掌控全网51%以上的算力才有可能实现。而在比特币网络中，由于挖矿具有经济收益，矿工们激烈地竞争，想要控制全网51%的算力并不容易做到。4.默克尔树左：仅提供默克尔树（Merkle tree）上的少量节点已经足够给出分支的合法证明。右：任何对于默克尔树的任何部分进行改变的尝试都会最终导致链上某处的不一致。比特币系统的一个重要的可扩展特性是：它的区块存储在多层次的数据结构中。一个区块的哈希实际上只是区块头的哈希，区块头是包含时间戳、随机数、上个区块哈希和存储了所有的区块交易的默克尔树的根哈希的长度大约为200字节的一段数据。默克尔树是一种二叉树，由一组叶节点、一组中间节点和一个根节点构成。最下面的大量的叶节点包含基础数据，每个中间节点是它的两个子节点的哈希，根节点也是由它的两个子节点的哈希，代表了默克尔树的顶部。默克尔树的目的是允许区块的数据可以零散地传送：节点可以从一个源下载区块头，从另外的源下载与其有关的树的其它部分，而依然能够确认所有的数据都是正确的。之所以如此是因为哈希向上的扩散：如果一个恶意用户尝试在树的下部加入一个伪造的交易，所引起的改动将导致树的上层节点的改动，以及更上层节点的改动，最终导致根节点的改动以及区块哈希的改动，这样协议就会将其记录为一个完全不同的区块（几乎可以肯定是带着不正确的工作量证明的）。默克尔树协议对比特币的长期持续性可以说是至关重要的。在2014年4月，比特币网络中的一个全节点-存储和处理所有区块的全部数据的节点-需要占用15GB的内存空间，而且还以每个月超过1GB的速度增长。目前，这一存储空间对台式计算机来说尚可接受，但是手机已经负载不了如此巨大的数据了。未来只有商业机构和爱好者才会充当完整节点。简化支付确认（SPV)协议允许另一种节点存在，这样的节点被成为“轻节点”，它下载区块头，使用区块头确认工作量证明，然后只下载与其交易相关的默克尔树“分支”。这使得轻节点只要下载整个区块链的一小部分就可以安全地确定任何一笔比特币交易的状态和账户的当前余额。详解在比特币系统中，一个区块的哈希实际上只是区块头的哈希，这个数据的长度只有大约200字节，因此减少了对存储空间的要求，这就是比特币白皮书中讲到的回收硬盘空间的机制。这一机制能够实现，是因为默克尔树结构，这个结构保证了区块链的安全，即使只改动默克尔树最下部的一个节点，也将最终导致根节点的改动，这样的改动就会形成一个无效区块，而无效区块无法进入区块链条，因此，攻击者篡改区块中的交易记录的企图是不可能实现的。由于有默克尔树结构，简化支付确认机制才得以实行，每个节点不必要存储全节点也可以使用比特币系统，从而降低了用户使用门槛，系统也就可以长期持续运行。5.其它的区块链应用将区块链的思想应用到其它领域的想法早就出现了。在2005年，尼克萨博提出了“用所有权为财产冠名”的概念，文中描述了复制数据库技术的发展如何使基于区块链的系统可以应用于登记土地所有权，创建包括例如房产权、违法侵占和乔治亚州土地税等概念的详细框架。然而，不幸的是在那时还没有实用的复制数据库系统，所以这个协议没有被付诸实践。不过，自2009年比特币系统的去中心化共识开发成功以来，许多区块链的其它应用开始快速出现。域名币（namecoin）- 创建于2010年，被称为去中心化的名称注册数据库。像Tor、Bitcoin和BitMessage这样的去中心化协议，需要一些确认账户的方法，这样其他人才能够与用户进行交互。但是，在所有的现存的解决方案中仅有的可用的身份标识是象1LW79wp5ZBqaHW1jL5TciBCrhQYtHagUWy这样的伪随机哈希。理想的情况下，人们希望拥有一个带有象“george”这样的名称的账户。然而，问题是如果有人可以创建“george”账户，那么其他人同样也可以创建“george”账户来假扮。唯一的解决方法是先申请原则（first-to-file），只有第一个注册者可以成功注册，第二个不能再次注册同一个账户。这一问题就可以利用比特币的共识协议。域名币是利用区块链实现名称注册系统的最早的、最成功的系统。彩色币（Colored coins）- 彩色币的目的是为人们在比特币区块链上创建自己的数字货币，或者，在更重要的一般意义上的货币 – 数字令牌提供服务。依照彩色币协议，人们可以通过为某一特别的比特币UTXO指定颜色，发行新的货币。该协议递归地将其它UTXO定义为与交易输入UTXO相同的颜色。这就允许用户保持只包含某一特定颜色的UTXO，发送这些UTXO就像发送普通的比特币一样，通过回溯全部的区块链判断收到的UTXO颜色。元币（Metacoins）- 元币的理念是在比特币区块链上创建新的协议，利用比特币的交易保存元币的交易，但是采用了不同的状态转换函数APPLY’。因为元币协议不能阻止比特币区块链上的无效的元币交易，所以增加一个规则如果APPLY'(S,TX)返回错误，这一协议将默认APPLY'(S,TX) = S。这为创建任意的、先进的不能在比特币系统中实现的密码学货币协议提供了一个简单的解决方法，而且开发成本非常低，因为挖矿和网络的问题已经由比特币协议处理好了。因此，一般而言，建立共识协议有两种方法：建立一个独立的网络和在比特币网络上建立协议。虽然像域名币这样的应用使用第一种方法已经获得了成功，但是该方法的实施非常困难，因为每一个应用需要创建独立的区块链和建立、测试所有状态转换和网络代码。另外，我们预测去中心化共识技术的应用将会服从幂律分布，大多数的应用太小不足以保证自由区块链的安全，我们还注意到大量的去中心化应用，尤其是去中心化自治组织，需要进行应用之间的交互。另一方面，基于比特币的方法存在缺点，它没有继承比特币可以进行简化确认支付（SPV) 的特性。比特币可以实现简化确认支付，因为比特币可以将区块链深度作为有效性确认代理。在某一点上，一旦一笔交易的祖先们距离现在足够远时，就可以认为它们是合法状态的一部分。与之相反，基于比特币区块链的元币协议不能强迫区块链不包括不符合元币协议的交易。因此，安全的元币协议的简化支付确认需要后向扫描所有的区块，直到区块链的初始点，以确认某一交易是否有效。目前，所有基于比特币的元币协议的“轻”实施都依赖可信任的服务器提供数据，这对主要目的之一是消除信任需要的密码学货币而言，只是一个相当次优的结果。详解自比特币成功创建以来，出现了很多其它的区块链应用，这些应用在建立共识协议上通常采用两种方法：一种是建立一个独立的网络，一种是在比特币网络上建立协议。但是两种方法都存在一些缺陷。为一种应用建立一个独立网络的弊端：为每一种应用建立一个去中心化共识系统成本太高；大多数的应用使用人数太少，因此节点不够，也就很容易被控制，因此也就不够安全；应用之间有交互的可能，如果是每个应用一个网络，那么应用之间的交互就困难。基于比特币网络建立协议的方法存在的缺陷：不能使用简化支付确认。如果基于比特币网络建立协议，那么用户就必须下载全部节点，这样的话，用户的存储成本就太高，对于一些存储空间不足的用户，就无法使用这样的应用。如果要使用简化的区块链的话，那就需要依赖可信任的服务器，这样就中心化了，安全性就降低了。6.脚本即使不对比特币协议进行扩展，它也能在一定程度上实现”智能合约”。比特币的UTXO可以被不只一个公钥拥有，也可以被用基于堆栈的编程语言所编写的更加复杂的脚本所拥有。在这一模式下，花费这样的UTXO，必须提供满足脚本的数据。事实上，基本的公钥所有权机制也是通过脚本实现的：脚本将椭圆曲线签名作为输入，验证交易和拥有这一UTXO的地址，如果验证成功，返回1，否则返回0。更加复杂的脚本用于其它不同的应用情况。例如，人们可以创建要求集齐三把私钥中的两把才能进行交易确认的脚本（多重签名），对公司账户、储蓄账户和某些商业代理来说，这种脚本是非常有用的。脚本也能用来对解决计算问题的用户发送奖励。人们甚至可以创建这样的脚本“如果你能够提供你已经发送一定数额的的狗币给我的简化确认支付证明，这一比特币UTXO就是你的了”，本质上，比特币系统允许不同的密码学货币进行去中心化的兑换。然而，比特币系统的脚本语言存在一些严重的限制：缺少图灵完备性 – 这就是说，尽管比特币脚本语言可以支持多种计算，但是它不能支持所有的计算。最主要的缺失是循环语句。不支持循环语句的目的是避免交易确认时出现无限循环。理论上，对于脚本程序员来说，这是可以克服的障碍，因为任何循环都可以用多次重复if 语句的方式来模拟，但是这样做会导致脚本空间利用上的低效率，例如，实施一个替代的椭圆曲线签名算法可能将需要256次重复的乘法，而每次都需要单独编码。价值模糊（Value-blindness）。UTXO脚本不能为账户的取款额度提供精细的的控制。例如，预言机合约（oracle contract）的一个强大应用是对冲合约，A和B各自向对冲合约中发送价值1000美元的比特币，30天以后，脚本向A发送价值1000美元的比特币，向B发送剩余的比特币。虽然实现对冲合约需要一个预言机（oracle）决定一比特币值多少美元，但是与现在完全中心化的解决方案相比，这一机制已经在减少信任和基础设施方面有了巨大的进步。然而，因为UTXO是不可分割的，为实现此合约，唯一的方法是非常低效地采用许多有不同面值的UTXO（例如对应于最大为30的每个k，有一个2^k的UTXO)并使预言机挑出正确的UTXO发送给A和B。缺少状态 – UTXO只能是已花费或者未花费状态，这就没有给需要任何其它内部状态的多阶段合约或者脚本留出生存空间。这使得实现多阶段期权合约、去中心化的交换要约或者两阶段加密承诺协议（对确保计算奖励非常必要）非常困难。这也意味着UTXO只能用于建立简单的、一次性的合约，而不是例如去中心化组织这样的有着更加复杂的状态的合约，使得元协议难以实现。二元状态与价值盲结合在一起意味着另一个重要的应用-取款限额-是不可能实现的。区块链模糊（Blockchain-blindness）- UTXO看不到区块链的数据，例如随机数和上一个区块的哈希。这一缺陷剥夺了脚本语言所拥有的基于随机性的潜在价值，严重地限制了博彩等其它领域应用。我们已经考察了在密码学货币上建立高级应用的三种方法：建立一个新的区块链，在比特币区块链上使用脚本，在比特币区块链上建立元币协议。建立新区块链的方法可以自由地实现任意的特性，成本是开发时间和培育努力。使用脚本的方法非常容易实现和标准化，但是它的能力有限。元币协议尽管非常容易实现，但是存在扩展性差的缺陷。在以太坊系统中，我们的目的是建立一个能够同时具有这三种模式的所有优势的通用框架。详解本节探讨了通过为比特币系统添加脚本程序来实现高级应用的方法，V神得出的结论是，这样的方法能力受限。具体地说就是原文中所讲的四条：缺少图灵完备性。最主要是缺失循环语句，这就导致了脚本的低效。价值模糊（Value-blindness）。UTXO是不可分割的，一次交易的价值组合与分割需要通过多次输入和输出来实现。这样就非常低效。缺少状态 – UTXO只能是已花费或者未花费状态。如果想要用脚本来创建多阶段合约，就非常困难。区块链模糊（Blockchain-blindness）—UTXO看不到区块链的数据，例如随机数和上一个区块的哈希。这一缺陷剥夺了脚本语言所拥有的基于随机性的潜在价值，严重地限制了博彩等其它领域应用。本节和上一节探讨了在数字货币上建立高级应用的三种方法，建立一个新的区块链，在比特币区块链上使用脚本，在比特币区块链上建立元币协议。V神分别分析了三种方法的利弊。以太坊的目标是要建立一个具备三种方法优势的通用框架。本章总结这一章分析了比特币系统的机制，说明了在比特币系统中的交易形态是状态转换，接着说明了工作量证明机制和默克尔树协议，这几项是构成比特币的关键机制。状态转换是比特币交易的基本形态，也是价值交易的基本形态。工作量证明机制是区块链的安全机制，也是比特币的去中心化共识机制。默克尔树协议降低了区块链节点的存储空间，使得简化支付确认得以实现，避免了比特币系统因为节点庞大臃肿而无法在大多数计算机设备上运行。接下来V神探讨了三种创建高级应用的方法，建立一个新的区块链，在比特币区块链上使用脚本，在比特币区块链上建立元币协议，并对这三种方法做了优劣势分析。最后，V神提出以太坊的目标就是要建立一个具备三种方法优势的通用框架。这样的框架应该具备什么样的特性、拥有什么样的能力呢？它的运行机制又是什么呢？下一篇我们研读以太坊章节来解开心中疑惑。编辑于 2018-06-13 19:13比特币 (Bitcoin)区块链(Blockchain)​赞同 12​​2 条评论​分享​喜欢​收藏​申请转载​文章被以下专栏收录区块链商业分析探索区块链商业应

White Paper · ethereum/wiki Wiki · GitHub

White Paper · ethereum/wiki Wiki · GitHub

Skip to content

Toggle navigation

Sign in

Product

Actions

Automate any workflow

Packages

Host and manage packages

Security

Find and fix vulnerabilities

Codespaces

Instant dev environments

Copilot

Write better code with AI

Code review

Manage code changes

Issues

Plan and track work

Discussions

Collaborate outside of code

Explore

All features

Documentation

GitHub Skills

Blog

Solutions

For

Enterprise

Teams

Startups

Education

By Solution

CI/CD & Automation

DevOps

DevSecOps

Resources

Learning Pathways

White papers, Ebooks, Webinars

Customer Stories

Partners

Open Source

GitHub Sponsors

Fund open source developers

The ReadME Project

GitHub community articles

Repositories

Topics

Trending

Collections

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Search

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

Sign up

You signed in with another tab or window. Reload to refresh your session.

You signed out in another tab or window. Reload to refresh your session.

You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

This repository has been archived by the owner on May 26, 2022. It is now read-only.

ethereum

/

wiki

Public archive

Notifications

Fork

2.5k

Star

14.7k

Code

Issues

34

Pull requests

7

Actions

Projects

0

Wiki

Security

Insights

Additional navigation options

Code

Issues

Pull requests

Actions

Projects

Wiki

Security

Insights

White Paper

Jump to bottom

Chris Chinchilla edited this page Jun 3, 2020

·

177 revisions

As part of an ongoing effort to update and overhaul the Ethereum wiki to make it more useful to our community, the whitepaper has now moved to the following location.

ethereum.org/whitepaper/

| Deutsch

| English

| Español

| Français

| 한국어

| Italiano

| Portuguese

| Română

| العربية

| فارسی

| 中文(繁体)

| 中文(简体)

| 日本語

Toggle tagle of contents

Pages 201

Home

5 strategies of contribution

[Arabic] Home in Arabic

[Arabic] العربية

[Arabic] مرحبا في صفحة الويكي للأثيريوم

[Chinese Simplified] Ethash Design Rationale中文翻译

[Chinese Simplified] Ethash中文翻译

[Chinese Simplified] Ethereum 白皮书中文版

[Chinese] Design Rationale 设计原理

[Chinese] Ethereum TOC

[Chinese] Ethereum 白皮書

[Chinese]ÐΞVp2p Wire Protocol中文翻译

[English] Patricia Tree

[English] RLP

[French] Ethereum TOC

[German] Clearinghaus

[German] Ethereum TOC

[German] RLP

[German] White Paper

[Indonesian] Ethereum akan naik karena teknologi terus dikembangkan dan ditingkatkan

[Italian] Ethereum TOC

[Italian] Impostare il proprio ambiente di sviluppo Ethereum

[Italian] Introduzione allo sviluppo su Ethereum

[Italian] Libro Bianco

[Japanese] Ethereum Development Tutorial

[Japanese] Liscence

[Japanese] Cryptocurrency Current Problems

[Japanese] Design Rationale

[Japanese] Ethereum 2.0 Phase 0 The Beacon Chain

[Japanese] Ethereum TOC

[Japanese] Ethereum Wire Protocol

[Japanese] HPOC_2015

[Japanese] Javascript API

[Japanese] libp2p whitepaper

[Japanese] Meteorを使ってDappを作ろう

[Japanese] Patricia Tree

[Japanese] Proof of Stake FAQs

[Japanese] RLP

[Japanese] Whisper

[Japanese] Whisper PoC 2 Protocol Spec

[Japanese] White Paper

[Japanese] ÐΞVp2p Wire Protocol

[Korean] White Paper

[Persian] Ethereum TOC

[Persian] White Paper

[Portuguese] White Paper

[Romanian] Cuprins

[Romanian] Limbajul de programare Serpent

[Romanian] Patricia Tree

[Romanian] RLP

[Romanian] White Paper

[Romanian] Wire Protocol

[Russian] Руководство по Solidity

[Simplified Chinese] Ethereum TOC

[Spanish] Byzantium Hard Fork changes

[Spanish] Ethereum TOC

[Spanish] Glossary

[Spanish] Home

[Spanish] Releases

[Spanish] White Paper.md

[Spanish]Proof of Stake FAQ

[Spanish]Sharding FAQ

[中文] RLP

[中文] Serpent指南

[中文] 以太坊Wiki目录

[中文] 以太坊开发计划

[中文] 以太坊术语表

[中文] 以太坊白皮书

[中文] 网络状态

[日本語] Proof of Stake FAQ

Adaptive Message IDs

Adaptive Peer Time

Alternative blockchains, randomness, economics, and other research topics

Bad Block Reporting

Bad Chain Canary

Benchmarks

Blockchain import and export instructions

Brain Wallet

Bugs

Byzantium Hard Fork changes

c value class SwitchParameter

Casper Proof of Stake compendium

CC0 license

Chain Fibers Redux

Client Version Strings

Clients

Clients, tools, dapp browsers, wallets and other projects

Consensus Datastructures

Consortium Chain Development

Contract Metadata Docs (NatSpec, ABI)

Dagger Hashimoto

Dapp Developer Resources

Dapp using Meteor

Decentralized apps (dapps)

Default Extra Data Standard

Design Rationale

Deterministic_Wallet_Spec

Distributed Preimage Archive

enode url format

ERC 735: Claim Holder Registry vs. in contract

Ethash

Ethash C API

Ethash DAG

Ethash DAG Disk Storage Format

Ethash Design Rationale

Ethereum Chain Spec Format

Ethereum Contract ABI

Ethereum Development Tutorial

Ethereum Introduction

Ethereum Natural Specification Format

Ethereum Sharding Research Compendium

Ethereum Virtual Machine (EVM) Awesome List

Ethereum White Paper

Ethereum Wire Protocol

EWasm compendium

eπ Programme

FAQ

FAQs

Geth Dapp loading proposal

Getting Ether

Getting Ether: further info

Gitter Channels

Glossary

Governance compendium

Grants and funding sources

HPOC_2015

ICAP: Inter exchange Client Address Protocol

Inter exchange Client Address Protocol (ICAP)

IPv6

JavaScript API

JSON RPC

JSON RPC Error Codes Improvement Proposal

Kademlia Peer Selection

libp2p Whitepaper

Licensing

Light client protocol

List of other Ethereum wikis and documentation

Major issues resulting in lost or stuck funds

Middleware and Dapp Project Ideas

Mining

Mist Troubleshooting Guide

Mix Features

Mix improvement proposal

Mix: The DApp IDE

Morden

Natspec Example

Network Status

newBlockFilter Improvement Proposal

Node discovery protocol

Outdated: Poll for token proposal EIP 20

Outdated: Proposal: Reversion Notification

Outdated: Proposal: Transaction Proxy Hooks

Parallel Block Downloads

Patricia Tree

Problems

Proof of Stake FAQ

Proof of Stake FAQs

R&D

Registrar ABI

Relay projects

RLP

Safety

Scaling projects and proposals and other crypto infrastructure projects

Security Categorization

Security Issue Process

Serpent [DEPRECATED]

Sharding FAQ

Sharding FAQs

Sharding introduction and implementations

Sharding introduction and R&D

Sharding introduction R&D compendium

Sharding roadmap

Solidity

Solidity Changelog

Solidity Collections

Solidity Features

Solidity Glossary

Solidity standard library

Solidity Tutorial

Solidity, Docs and ABI

Standardized_Contract_APIs

Storage projects

Subtleties

Swarm Hash

The Solidity Programming Language

Topics that span across research categories: alternative blockchains, randomness, economics, etc.

URL Hint Protocol

Useful Ðapp Patterns

web.js 0.9

Web3 Secret Storage Definition

What is Ethereum

Whisper

Whisper Overview

Whisper PoC 2 Protocol Spec

Whisper PoC 2 Wire Protocol

Whisper Wire Protocol

White Paper

Wiki: ethresear.ch Sharding Compendium

Wishlist

ÐApp Development

ÐΞVp2p Wire Protocol

Show 186 more pages…

Basics

Home

Ethereum Whitepaper

Ethereum Introduction

Uses: DAOs and dapps

Getting Ether

FAQs

Design Rationale

EVM intro: Ethereum Yellow Paper, Beige Paper and Py-EVM.

Wiki for (old) website (still a good introduction)

Glossary

R&D

Sharding introduction & R&D Compendium, FAQs & roadmap

Casper Proof-of-Stake compendium and FAQs.

Alternative blockchains, randomness, economics, and other research topics

Hard Problems of Cryptocurrency

Governance

Ethereum Virtual Machine (EVM)

Ethereum clients, tools, wallets, dapp browsers and other projects

ÐApp Development

Infrastructure

Chain Spec Format

Inter-exchange Client Address Protocol

URL Hint Protocol

Network Status

Mining

Licensing

Consortium Chain Development

Networking

Ethereum Wire Protocol

libp2p

devp2p Specifications

devp2p Whitepaper (old)

Ethereum Technologies

RLP Encoding

Patricia Tree

Web3 Secret Storage

Light client protocol

Subtleties

Solidity Documentation

NatSpec Format

Contract ABI

Bad Block Reporting

Bad Chain Canary

Ethash/Dashimoto

Ethash

Ethash Yellow Paper appendix

Ethash C API

Ethash DAG

Whisper

Whisper Proposal

Whisper Overview

PoC-1 Wire protocol

PoC-2 Wire protocol

PoC-2 Whitepaper

0x927c0E368722206312D243417dA9797424b56434

Clone this wiki locally

Footer

© 2024 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

以太坊白皮书（原版译文）以太坊（Ethereum ）:下一代智能合约和去中心化应用平台-腾讯云开发者社区-腾讯云

皮书（原版译文）以太坊（Ethereum ）:下一代智能合约和去中心化应用平台-腾讯云开发者社区-腾讯云rectinajh以太坊白皮书（原版译文）以太坊（Ethereum ）:下一代智能合约和去中心化应用平台关注作者腾讯云开发者社区文档建议反馈控制台首页学习活动专区工具TVP最新优惠活动文章/答案/技术大牛搜索搜索关闭发布登录/注册首页学习活动专区工具TVP最新优惠活动返回腾讯云官网rectinajh首页学习活动专区工具TVP最新优惠活动返回腾讯云官网社区首页 >专栏 >以太坊白皮书（原版译文）以太坊（Ethereum ）:下一代智能合约和去中心化应用平台以太坊白皮书（原版译文）以太坊（Ethereum ）:下一代智能合约和去中心化应用平台rectinajh关注发布于 2018-05-17 16:29:306.1K0发布于 2018-05-17 16:29:30举报文章被收录于专栏：华仔的技术笔记华仔的技术笔记以太坊白皮书地址：https://github.com/ethereum/wiki/wiki/White-Paper以太坊（Ethereum ）:下一代智能合约和去中心化应用平台当中本聪在2009年1月启动比特币区块链时，他同时向世界引入了两种未经测试的革命性的新概念。第一种就是比特币（bitcoin），一种去中心化的点对点的网上货币，在没有任何资产担保、内在价值或者中心发行者的情况下维持着价值。到目前为止，比特币已经吸引了大量的公众注意力, 就政治方面而言它是一种没有中央银行的货币并且有着剧烈的价格波动。然而，中本聪的伟大试验还有与比特币同等重要的一部分：基于工作量证明的区块链概念使得人们可以就交易顺序达成共识。作为应用的比特币可以被描述为一个先申请（first-to-file）系统：如果某人有50BTC并且同时向A和B发送这50BTC，只有被首先被确认的交易才会生效。没有固有方法可以决定两笔交易哪一笔先到，这个问题阻碍了去中心化数字货币的发展许多年。中本聪的区块链是第一个可靠的去中心化解决办法。现在，开发者们的注意力开始迅速地转向比特币技术的第二部分，区块链怎样应用于货币以外的领域。常被提及的应用包括使用链上数字资产来代表定制货币和金融工具（彩色币），某种基础物理设备的所有权（智能资产），如域名一样的没有可替代性的资产（域名币）以及如去中心化交易所，金融衍生品，点到点赌博和链上身份和信誉系统等更高级的应用。另一个常被问询的重要领域是“智能合约”- 根据事先任意制订的规则来自动转移数字资产的系统。例如，一个人可能有一个存储合约，形式为“A可以每天最多提现X个币，B每天最多Y个，A和B一起可以随意提取，A可以停掉B的提现权”。这种合约的符合逻辑的扩展就是去中心化自治组织（DAOs）-长期的包含一个组织的资产并把组织的规则编码的智能合约。以太坊的目标就是提供一个带有内置的成熟的图灵完备语言的区块链，用这种语言可以创建合约来编码任意状态转换功能，用户只要简单地用几行代码来实现逻辑，就能够创建以上提及的所有系统以及许多我们还想象不到的的其它系统。目录历史 作为状态转换系统的比特币挖矿默克尔树替代区块链应用脚本以太坊 以太坊账户消息和交易以太坊状态转换功能代码执行区块链和挖矿应用 令牌系统金融衍生品身份和信誉系统去中心化文件存储去中心化自治组织进一步的应用杂项和关注 改进版幽灵协议的实施费用计算和图灵完备货币和发行挖矿的中心化扩展性综述：去中心化应用结论注解和进阶阅读历史去中心化的数字货币概念，正如财产登记这样的替代应用一样，早在几十年以前就被提出来了。1980和1990年代的匿名电子现金协议，大部分是以乔姆盲签技术（Chaumian blinding）为基础的。这些电子现金协议提供具有高度隐私性的货币，但是这些协议都没有流行起来，因为它们都依赖于一个中心化的中介机构。1998年，戴伟（Wei Dai）的b-money首次引入了通过解决计算难题和去中心化共识创造货币的思想，但是该建议并未给出如何实现去中心化共识的具体方法。2005年，芬尼（Hal Finney）引入了“可重复使用的工作量证明机制”（reusable proofs of work）概念，它同时使用b-money的思想和Adam Back提出的计算困难的哈希现金（Hashcash）难题来创造密码学货币。但是，这种概念再次迷失于理想化，因为它依赖于可信任的计算作为后端。因为货币是一个先申请应用，交易的顺序至关重要，所以去中心化的货币需要找到实现去中心化共识的方法。比特币以前的所有电子货币协议所遇到的主要障碍是，尽管对如何创建安全的拜占庭问题容错（Byzantine-fault-tolerant）多方共识系统的研究已经历时多年，但是上述协议只解决了问题的一半。这些协议假设系统的所有参与者是已知的，并产生如“如果有N方参与到系统中，那么系统可以容忍N/4的恶意参与者”这样形式的安全边界。然而这个假设的问题在于，在匿名的情况下，系统设置的安全边界容易遭受女巫攻击，因为一个攻击者可以在一台服务器或者僵尸网络上创建数以千计的节点，从而单方面确保拥有多数份额。中本聪的创新是引入这样一个理念：将一个非常简单的基于节点的去中心化共识协议与工作量证明机制结合在一起。节点通过工作量证明机制获得参与到系统的权利，每十分钟将交易打包到“区块”中，从而创建出不断增长的区块链。拥有大量算力的节点有更大的影响力，但获得比整个网络更多的算力比创建一百万个节点困难得多。尽管比特币区块链模型非常简陋，但是实践证明它已经足够好用了，在未来五年，它将成为全世界两百个以上的货币和协议的基石。作为状态转换系统的比特币从技术角度讲，比特币账本可以被认为是一个状态转换系统，该系统包括所有现存的比特币所有权状态和“状态转换函数”。状态转换函数以当前状态和交易为输入，输出新的状态。例如，在标准的银行系统中，状态就是一个资产负债表，一个从A账户向B账户转账X美元的请求是一笔交易，状态转换函数将从A账户中减去X美元，向B账户增加X美元。如果A账户的余额小于X美元，状态转换函数就会返回错误提示。所以我们可以如下定义状态转换函数：APPLY(S,TX) ­> S' or ERROR复制在上面提到的银行系统中，状态转换函数如下：APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30,Bob: $70 }复制但是：APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR复制比特币系统的“状态”是所有已经被挖出的、没有花费的比特币（技术上称为“未花费的交易输出，unspent transaction outputs 或UTXO”）的集合。每个UTXO都有一个面值和所有者（由20个字节的本质上是密码学公钥的地址所定义[1]）。一笔交易包括一个或多个输入和一个或多个输出。每个输入包含一个对现有UTXO的引用和由与所有者地址相对应的私钥创建的密码学签名。每个输出包含一个新的加入到状态中的UTXO。在比特币系统中，状态转换函数APPLY(S,TX)->S’大体上可以如下定义：交易的每个输入： 如果引用的UTXO不存在于现在的状态中（S），返回错误提示如果签名与UTXO所有者的签名不一致，返回错误提示如果所有的UTXO输入面值总额小于所有的UTXO输出面值总额，返回错误提示返回新状态S’,新状态S中移除了所有的输入UTXO，增加了所有的输出UTXO。第一步的第一部分防止交易的发送者花费不存在的比特币，第二部分防止交易的发送者花费其他人的比特币。第二步确保价值守恒。比特币的支付协议如下。假设Alice想给Bob发送11.7BTC。事实上，Alice不可能正好有11.7BTC。假设，她能得到的最小数额比特币的方式是：6+4+2=12。所以，她可以创建一笔有3个输入，2个输出的交易。第一个输出的面值是11.7BTC，所有者是Bob（Bob的比特币地址），第二个输出的面值是0.3BTC，所有者是Alice自己，也就是找零。挖矿如果我们拥有可信任的中心化服务机构，状态转换系统可以很容易地实现，可以简单地将上述功能准确编码。然而，我们想把比特币系统建成为去中心化的货币系统，为了确保每个人都同意交易的顺序，我们需要将状态转换系统与一个共识系统结合起来。比特币的去中心化共识进程要求网络中的节点不断尝试将交易打包成“区块”。网络被设计为大约每十分钟产生一个区块，每个区块包含一个时间戳、一个随机数、一个对上一个区块的引用（即哈希）和上一区块生成以来发生的所有交易列表。这样随着时间流逝就创建出了一个持续增长的区块链，它不断地更新，从而能够代表比特币账本的最新状态。依照这个范式，检查一个区块是否有效的算法如下：检查区块引用的上一个区块是否存在且有效。检查区块的时间戳是否晚于以前的区块的时间戳，而且早于未来2小时[2]。检查区块的工作量证明是否有效。将上一个区块的最终状态赋于S[0]。假设TX是区块的交易列表，包含n笔交易。对于属于0……n-1的所有i,进行状态转换S[i+1] = APPLY(S[i],TX[i])。如果任何一笔交易i在状态转换中出错，退出程序，返回错误。返回正确，状态S[n]是这一区块的最终状态。本质上，区块中的每笔交易必须提供一个正确的状态转换，要注意的是，“状态”并不是编码到区块的。它纯粹只是被校验节点记住的抽象概念，对于任意区块都可以从创世状态开始，按顺序加上每一个区块的每一笔交易，（妥妥地）计算出当前的状态。另外，需要注意矿工将交易收录进区块的顺序。如果一个区块中有A、B两笔交易，B花费的是A创建的UTXO，如果A在B以前，这个区块是有效的，否则，这个区块是无效的。区块验证算法的有趣部分是“工作量证明”概念：对每个区块进行SHA256哈希处理，将得到的哈希视为长度为256比特的数值，该数值必须小于不断动态调整的目标数值，本书写作时目标数值大约是2190。工作量证明的目的是使区块的创建变得困难，从而阻止女巫攻击者恶意重新生成区块链。因为SHA256是完全不可预测的伪随机函数，创建有效区块的唯一方法就是简单地不断试错，不断地增加随机数的数值，查看新的哈希数值是否小于目标数值。如果当前的目标数值是2192，就意味着平均需要尝试2^64次才能生成有效的区块。一般而言，比特币网络每隔2016个区块重新设定目标数值，保证平均每十分钟生成一个区块。为了对矿工的计算工作进行奖励，每一个成功生成区块的矿工有权在区块中包含一笔凭空发给他们自己25BTC的交易。另外，如果交易的输入大于输出，差额部分就作为“交易费用”付给矿工。顺便提一下，对矿工的奖励是比特币发行的唯一机制，创世状态中并没有比特币。为了更好地理解挖矿的目的，让我们分析比特币网络出现恶意攻击者时会发生什么。因为比特币的密码学基础是非常安全的，所以攻击者会选择攻击没有被密码学直接保护的部分：交易顺序。攻击者的策略非常简单：向卖家发送100BTC购买商品（尤其是无需邮寄的电子商品）。等待直至商品发出。创建另一笔交易，将相同的100BTC发送给自己的账户。使比特币网络相信发送给自己账户的交易是最先发出的。一旦步骤（1）发生，几分钟后矿工将把这笔交易打包到区块，假设是第270000个区块。大约一个小时以后，在此区块后面将会有五个区块，每个区块间接地指向这笔交易，从而确认这笔交易。这时卖家收到货款，并向买家发货。因为我们假设这是数字商品，攻击者可以即时收到货。现在，攻击者创建另一笔交易，将相同的100BTC发送到自己的账户。如果攻击者只是向全网广播这一消息，这一笔交易不会被处理。矿工会运行状态转换函数APPLY(S,TX)，发现这笔交易将花费已经不在状态中的UTXO。所以，攻击者会对区块链进行分叉，将第269999个区块作为父区块重新生成第270000个区块，在此区块中用新的交易取代旧的交易。因为区块数据是不同的，这要求重新进行工作量证明。另外，因为攻击者生成的新的第270000个区块有不同的哈希，所以原来的第270001到第270005的区块不指向它，因此原有的区块链和攻击者的新区块是完全分离的。在发生区块链分叉时，区块链长的分支被认为是诚实的区块链，合法的的矿工将会沿着原有的第270005区块后挖矿，只有攻击者一人在新的第270000区块后挖矿。攻击者为了使得他的区块链最长，他需要拥有比除了他以外的全网更多的算力来追赶（即51%攻击）。 默克尔树比特币中的简化支付确认左：仅提供默克尔树（Merkle tree）上的少量节点已经足够给出分支的合法证明。

右：任何对于默克尔树的任何部分进行改变的尝试都会最终导致链上某处的不一致。比特币系统的一个重要的可扩展特性是：它的区块存储在多层次的数据结构中。一个区块的哈希实际上只是区块头的哈希，区块头是包含时间戳、随机数、上个区块哈希和存储了所有的区块交易的默克尔树的根哈希的长度大约为200字节的一段数据。默克尔树是一种二叉树，由一组叶节点、一组中间节点和一个根节点构成。最下面的大量的叶节点包含基础数据，每个中间节点是它的两个子节点的哈希，根节点也是由它的两个子节点的哈希，代表了默克尔树的顶部。默克尔树的目的是允许区块的数据可以零散地传送：节点可以从一个源下载区块头，从另外的源下载与其有关的树的其它部分，而依然能够确认所有的数据都是正确的。之所以如此是因为哈希向上的扩散：如果一个恶意用户尝试在树的下部加入一个伪造的交易，所引起的改动将导致树的上层节点的改动，以及更上层节点的改动，最终导致根节点的改动以及区块哈希的改动，这样协议就会将其记录为一个完全不同的区块（几乎可以肯定是带着不正确的工作量证明的）。默克尔树协议对比特币的长期持续性可以说是至关重要的。在2014年4月，比特币网络中的一个全节点-存储和处理所有区块的全部数据的节点-需要占用15GB的内存空间，而且还以每个月超过1GB的速度增长。目前，这一存储空间对台式计算机来说尚可接受，但是手机已经负载不了如此巨大的数据了。未来只有商业机构和爱好者才会充当完整节点。简化支付确认（SPV)协议允许另一种节点存在，这样的节点被成为“轻节点”，它下载区块头，使用区块头确认工作量证明，然后只下载与其交易相关的默克尔树“分支”。这使得轻节点只要下载整个区块链的一小部分就可以安全地确定任何一笔比特币交易的状态和账户的当前余额。 其它的区块链应用将区块链的思想应用到其它领域的想法早就出现了。在2005年，尼克萨博提出了“用所有权为财产冠名”的概念，文中描述了复制数据库技术的发展如何使基于区块链的系统可以应用于登记土地所有权，创建包括例如房产权、违法侵占和乔治亚州土地税等概念的详细框架。然而，不幸的是在那时还没有实用的复制数据库系统，所以这个协议被没有被付诸实践。不过，自2009年比特币系统的去中心化共识开发成功以来，许多区块链的其它应用开始快速出现。 域名币（namecoin）- 创建于2010年，被称为去中心化的名称注册数据库。像Tor、Bitcoin和BitMessage这样的去中心化协议，需要一些确认账户的方法，这样其他人才能够与用户进行交互。但是，在所有的现存的解决方案中仅有的可用的身份标识是象1LW79wp5ZBqaHW1jL5TciBCrhQYtHagUWy这样的伪随机哈希。理想的情况下，人们希望拥有一个带有象“george”这样的名称的账户。然而，问题是如果有人可以创建“george”账户，那么其他人同样也可以创建“george”账户来假扮。唯一的解决方法是先申请原则（first-to-file），只有第一个注册者可以成功注册，第二个不能再次注册同一个账户。这一问题就可以利用比特币的共识协议。域名币是利用区块链实现名称注册系统的最早的、最成功的系统。 彩色币（Colored coins）- 彩色币的目的是为人们在比特币区块链上创建自己的数字货币，或者，在更重要的一般意义上的货币 – 数字令牌提供服务。依照彩色币协议，人们可以通过为某一特别的比特币UTXO指定颜色，发行新的货币。该协议递归地将其它UTXO定义为与交易输入UTXO相同的颜色。这就允许用户保持只包含某一特定颜色的UTXO，发送这些UTXO就像发送普通的比特币一样，通过回溯全部的区块链判断收到的UTXO颜色。 元币（Metacoins）- 元币的理念是在比特币区块链上创建新的协议，利用比特币的交易保存元币的交易，但是采用了不同的状态转换函数APPLY’。因为元币协议不能阻止比特币区块链上的无效的元币交易，所以增加一个规则如果APPLY'(S,TX)返回错误，这一协议将默认APPLY'(S,TX) = S。这为创建任意的、先进的不能在比特币系统中实现的密码学货币协议提供了一个简单的解决方法，而且开发成本非常低，因为挖矿和网络的问题已经由比特币协议处理好了。因此，一般而言，建立共识协议有两种方法：建立一个独立的网络和在比特币网络上建立协议。虽然像域名币这样的应用使用第一种方法已经获得了成功，但是该方法的实施非常困难，因为每一个应用需要创建独立的区块链和建立、测试所有状态转换和网络代码。另外，我们预测去中心化共识技术的应用将会服从幂律分布，大多数的应用太小不足以保证自由区块链的安全，我们还注意到大量的去中心化应用，尤其是去中心化自治组织，需要进行应用之间的交互。另一方面，基于比特币的方法存在缺点，它没有继承比特币可以进行简化确认支付（SPV) 的特性。比特币可以实现简化确认支付，因为比特币可以将区块链深度作为有效性确认代理。在某一点上，一旦一笔交易的祖先们距离现在足够远时，就可以认为它们是合法状态的一部分。与之相反，基于比特币区块链的元币协议不能强迫区块链不包括不符合元币协议的交易。因此，安全的元币协议的简化支付确认需要后向扫描所有的区块，直到区块链的初始点，以确认某一交易是否有效。目前，所有基于比特币的元币协议的“轻”实施都依赖可信任的服务器提供数据，这对主要目的之一是消除信任需要的密码学货币而言，只是一个相当次优的结果。 脚本即使不对比特币协议进行扩展，它也能在一定程度上实现”智能合约”。比特币的UTXO可以被不只被一个公钥拥有，也可以被用基于堆栈的编程语言所编写的更加复杂的脚本所拥有。在这一模式下，花费这样的UTXO，必须提供满足脚本的数据。事实上，基本的公钥所有权机制也是通过脚本实现的：脚本将椭圆曲线签名作为输入，验证交易和拥有这一UTXO的地址，如果验证成功，返回1，否则返回0。更加复杂的脚本用于其它不同的应用情况。例如，人们可以创建要求集齐三把私钥中的两把才能进行交易确认的脚本（多重签名），对公司账户、储蓄账户和某些商业代理来说，这种脚本是非常有用的。脚本也能用来对解决计算问题的用户发送奖励。人们甚至可以创建这样的脚本“如果你能够提供你已经发送一定数额的的狗币给我的简化确认支付证明，这一比特币UTXO就是你的了”，本质上，比特币系统允许不同的密码学货币进行去中心化的兑换。然而，比特币系统的脚本语言存在一些严重的限制： 缺少图灵完备性 – 这就是说，尽管比特币脚本语言可以支持多种计算，但是它不能支持所有的计算。最主要的缺失是循环语句。不支持循环语句的目的是避免交易确认时出现无限循环。理论上，对于脚本程序员来说，这是可以克服的障碍，因为任何循环都可以用多次重复if 语句的方式来模拟，但是这样做会导致脚本空间利用上的低效率，例如，实施一个替代的椭圆曲线签名算法可能将需要256次重复的乘法，而每次都需要单独编码。 价值盲（Value-blindness）。UTXO脚本不能为账户的取款额度提供精细的的控制。例如，预言机合约（oracle contract）的一个强大应用是对冲合约，A和B各自向对冲合约中发送价值1000美元的比特币，30天以后，脚本向A发送价值1000美元的比特币，向B发送剩余的比特币。虽然实现对冲合约需要一个预言机（oracle）决定一比特币值多少美元，但是与现在完全中心化的解决方案相比，这一机制已经在减少信任和基础设施方面有了巨大的进步。然而，因为UTXO是不可分割的，为实现此合约，唯一的方法是非常低效地采用许多有不同面值的UTXO（例如对应于最大为30的每个k，有一个2^k的UTXO)并使预言机挑出正确的UTXO发送给A和B。 缺少状态 – UTXO只能是已花费或者未花费状态，这就没有给需要任何其它内部状态的多阶段合约或者脚本留出生存空间。这使得实现多阶段期权合约、去中心化的交换要约或者两阶段加密承诺协议（对确保计算奖励非常必要）非常困难。这也意味着UTXO只能用于建立简单的、一次性的合约，而不是例如去中心化组织这样的有着更加复杂的状态的合约，使得元协议难以实现。二元状态与价值盲结合在一起意味着另一个重要的应用-取款限额-是不可能实现的。 区块链盲（Blockchain-blindness）- UTXO看不到区块链的数据，例如随机数和上一个区块的哈希。这一缺陷剥夺了脚本语言所拥有的基于随机性的潜在价值，严重地限制了博彩等其它领域应用。我们已经考察了在密码学货币上建立高级应用的三种方法：建立一个新的区块链，在比特币区块链上使用脚本，在比特币区块链上建立元币协议。建立新区块链的方法可以自由地实现任意的特性，成本是开发时间和培育努力。使用脚本的方法非常容易实现和标准化，但是它的能力有限。元币协议尽管非常容易实现，但是存在扩展性差的缺陷。在以太坊系统中，我们的目的是建立一个能够同时具有这三种模式的所有优势的通用框架。 以太坊以太坊的目的是基于脚本、竞争币和链上元协议（on-chain meta-protocol）概念进行整合和提高，使得开发者能够创建任意的基于共识的、可扩展的、标准化的、特性完备的、易于开发的和协同的应用。以太坊通过建立终极的抽象的基础层-内置有图灵完备编程语言的区块链-使得任何人都能够创建合约和去中心化应用并在其中设立他们自由定义的所有权规则、交易方式和状态转换函数。域名币的主体框架只需要两行代码就可以实现，诸如货币和信誉系统等其它协议只需要不到二十行代码就可以实现。智能合约-包含价值而且只有满足某些条件才能打开的加密箱子-也能在我们的平台上创建，并且因为图灵完备性、价值知晓（value-awareness）、区块链知晓（blockchain-awareness）和多状态所增加的力量而比比特币脚本所能提供的智能合约强大得多。 以太坊账户在以太坊系统中，状态是由被称为“账户”（每个账户由一个20字节的地址）的对象和在两个账户之间转移价值和信息的状态转换构成的。以太坊的账户包含四个部分：随机数，用于确定每笔交易只能被处理一次的计数器账户目前的以太币余额账户的合约代码，如果有的话账户的存储（默认为空）以太币（Ether）是以太坊内部的主要加密燃料，用于支付交易费用。一般而言，以太坊有两种类型的账户：外部所有的账户（由私钥控制的）和合约账户（由合约代码控制）。外部所有的账户没有代码，人们可以通过创建和签名一笔交易从一个外部账户发送消息。每当合约账户收到一条消息，合约内部的代码就会被激活，允许它对内部存储进行读取和写入，和发送其它消息或者创建合约。 消息和交易以太坊的消息在某种程度上类似于比特币的交易，但是两者之间存在三点重要的不同。第一，以太坊的消息可以由外部实体或者合约创建，然而比特币的交易只能从外部创建。第二，以太坊消息可以选择包含数据。第三，如果以太坊消息的接受者是合约账户，可以选择进行回应，这意味着以太坊消息也包含函数概念。以太坊中“交易”是指存储从外部账户发出的消息的签名数据包。交易包含消息的接收者、用于确认发送者的签名、以太币账户余额、要发送的数据和两个被称为STARTGAS和GASPRICE的数值。为了防止代码的指数型爆炸和无限循环，每笔交易需要对执行代码所引发的计算步骤-包括初始消息和所有执行中引发的消息-做出限制。STARTGAS就是限制，GASPRICE是每一计算步骤需要支付矿工的费用。如果执行交易的过程中，“用完了瓦斯”，所有的状态改变恢复原状态，但是已经支付的交易费用不可收回了。如果执行交易中止时还剩余瓦斯，那么这些瓦斯将退还给发送者。创建合约有单独的交易类型和相应的消息类型；合约的地址是基于账号随机数和交易数据的哈希计算出来的。消息机制的一个重要后果是以太坊的“头等公民”财产-合约与外部账户拥有同样权利，包括发送消息和创建其它合约的权利。这使得合约可以同时充当多个不同的角色，例如，用户可以使去中心化组织（一个合约）的一个成员成为一个中介账户（另一个合约），为一个偏执的使用定制的基于量子证明的兰波特签名（第三个合约）的个人和一个自身使用由五个私钥保证安全的账户（第四个合约）的共同签名实体提供居间服务。以太坊平台的强大之处在于去中心化的组织和代理合约不需要关心合约的每一参与方是什么类型的账户。 以太坊状态转换函数以太坊交易.png以太坊的状态转换函数：APPLY(S,TX) -> S'，可以定义如下：检查交易的格式是否正确（即有正确数值）、签名是否有效和随机数是否与发送者账户的随机数匹配。如否，返回错误。计算交易费用:fee=STARTGAS * GASPRICE，并从签名中确定发送者的地址。从发送者的账户中减去交易费用和增加发送者的随机数。如果账户余额不足，返回错误。设定初值GAS = STARTGAS，并根据交易中的字节数减去一定量的瓦斯值。从发送者的账户转移价值到接收者账户。如果接收账户还不存在，创建此账户。如果接收账户是一个合约，运行合约的代码，直到代码运行结束或者瓦斯用完。如果因为发送者账户没有足够的钱或者代码执行耗尽瓦斯导致价值转移失败，恢复原来的状态，但是还需要支付交易费用，交易费用加至矿工账户。否则，将所有剩余的瓦斯归还给发送者，消耗掉的瓦斯作为交易费用发送给矿工。 例如，假设合约的代码如下：if !self.storage[calldataload(0)]:

self.storage[calldataload(0)] = calldataload(32)复制需要注意的是，在现实中合约代码是用底层以太坊虚拟机（EVM）代码写成的。上面的合约是用我们的高级语言Serpent语言写成的，它可以被编译成EVM代码。假设合约存储器开始时是空的，一个值为10以太，瓦斯为2000，瓦斯价格为0.001以太并且64字节数据，第一个三十二字节的块代表号码2和第二个代表词CHARLIE。的交易发送后，状态转换函数的处理过程如下：检查交易是否有效、格式是否正确。检查交易发送者至少有2000*0.001=2个以太币。如果有，从发送者账户中减去2个以太币。初始设定gas=2000,假设交易长为170字节，每字节的费用是5，减去850，所以还剩1150。从发送者账户减去10个以太币，为合约账户增加10个以太币。运行代码。在这个合约中，运行代码很简单：它检查合约存储器索引为2处是否已使用，注意到它未被使用，然后将其值置为CHARLIE。假设这消耗了187单位的瓦斯，于是剩余的瓦斯为1150 - 187 = 963。 ６. 向发送者的账户增加963*0.001=0.963个以太币，返回最终状态。 如果没有合约接收交易，那么所有的交易费用就等于GASPRICE乘以交易的字节长度，交易的数据就与交易费用无关了。另外，需要注意的是，合约发起的消息可以对它们产生的计算分配瓦斯限额，如果子计算的瓦斯用完了，它只恢复到消息发出时的状态。因此，就像交易一样，合约也可以通过对它产生的子计算设置严格的限制，保护它们的计算资源。 代码执行以太坊合约的代码是使用低级的基于堆栈的字节码的语言写成的，被称为“以太坊虚拟机代码”或者“EVM代码”。代码由一系列字节构成，每一个字节代表一种操作。一般而言，代码执行是无限循环，程序计数器每增加一（初始值为零）就执行一次操作，直到代码执行完毕或者遇到错误，STOP或者RETURN指令。操作可以访问三种存储数据的空间： 堆栈，一种后进先出的数据存储，32字节的数值可以入栈，出栈。 内存，可无限扩展的字节队列。 合约的长期存储，一个秘钥/数值的存储，其中秘钥和数值都是32字节大小，与计算结束即重置的堆栈和内存不同，存储内容将长期保持。代码可以象访问区块头数据一样访问数值，发送者和接受到的消息中的数据，代码还可以返回数据的字节队列作为输出。EVM代码的正式执行模型令人惊讶地简单。当以太坊虚拟机运行时，它的完整的计算状态可以由元组(block_state, transaction, message, code, memory, stack, pc, gas)来定义，这里block_state是包含所有账户余额和存储的全局状态。每轮执行时，通过调出代码的第pc（程序计数器）个字节，当前指令被找到，每个指令都有定义自己如何影响元组。例如，ADD将两个元素出栈并将它们的和入栈，将gas（瓦斯）减一并将pc加一，SSTORE将顶部的两个元素出栈并将第二个元素插入到由第一个元素定义的合约存储位置，同样减少最多200的gas值并将pc加一，虽然有许多方法通过即时编译去优化以太坊，但以太坊的基础性的实施可以用几百行代码实现。 区块链和挖矿虽然有一些不同，但以太坊的区块链在很多方面类似于比特币区块链。它们的区块链架构的不同在于，以太坊区块不仅包含交易记录和最近的状态，还包含区块序号和难度值。以太坊中的区块确认算法如下：检查区块引用的上一个区块是否存在和有效。检查区块的时间戳是否比引用的上一个区块大，而且小于15分钟。检查区块序号、难度值、 交易根，叔根和瓦斯限额（许多以太坊特有的底层概念）是否有效。检查区块的工作量证明是否有效。将S[0]赋值为上一个区块的STATE_ROOT。将TX赋值为区块的交易列表，一共有n笔交易。对于属于0……n-1的i，进行状态转换S[i+1] = APPLY(S[i],TX[i])。如果任何一个转换发生错误，或者程序执行到此处所花费的瓦斯（gas）超过了GASLIMIT，返回错误。用S[n]给S_FINAL赋值, 向矿工支付区块奖励。检查S-FINAL是否与STATE_ROOT相同。如果相同，区块是有效的。否则，区块是无效的。这一确认方法乍看起来似乎效率很低，因为它需要存储每个区块的所有状态，但是事实上以太坊的确认效率可以与比特币相提并论。原因是状态存储在树结构中（tree structure），每增加一个区块只需要改变树结构的一小部分。因此，一般而言，两个相邻的区块的树结构的大部分应该是相同的，因此存储一次数据，可以利用指针（即子树哈希）引用两次。一种被称为“帕特里夏树”（“Patricia Tree”）的树结构可以实现这一点，其中包括了对默克尔树概念的修改，不仅允许改变节点，而且还可以插入和删除节点。另外，因为所有的状态信息是最后一个区块的一部分，所以没有必要存储全部的区块历史-这一方法如果能够可以应用到比特币系统中，经计算可以对存储空间有10-20倍的节省。 应用一般来讲，以太坊之上有三种应用。第一类是金融应用，为用户提供更强大的用他们的钱管理和参与合约的方法。包括子货币，金融衍生品，对冲合约，储蓄钱包，遗嘱，甚至一些种类的全面的雇佣合约。第二类是半金融应用，这里有钱的存在但也有很重的非金钱的方面，一个完美的例子是为解决计算问题而设的自我强制悬赏。最后，还有在线投票和去中心化治理这样的完全的非金融应用。令牌系统链上令牌系统有很多应用，从代表如美元或黄金等资产的子货币到公司股票，单独的令牌代表智能资产，安全的不可伪造的优惠券，甚至与传统价值完全没有联系的用来进行积分奖励的令牌系统。在以太坊中实施令牌系统容易得让人吃惊。关键的一点是理解，所有的货币或者令牌系统，从根本上来说是一个带有如下操作的数据库：从A中减去X单位并把X单位加到B上，前提条件是(1)A在交易之前有至少X单位以及(2)交易被A批准。实施一个令牌系统就是把这样一个逻辑实施到一个合约中去。用Serpent语言实施一个令牌系统的基本代码如下：def send(to, value):

if self.storage[from] >= value:

self.storage[from] = self.storage[from] value

self.storage[to] = self.storage[to] + value复制这从本质上来说是本文将要进一步描述的“银行系统”状态转变功能的一个最小化实施。需要增加一些额外的代码以提供在初始和其它一些边缘情况下分发货币的功能，理想情况下会增加一个函数让其它合约来查询一个地址的余额。就足够了。理论上，基于以太坊的充当子货币的令牌系统可能包括一个基于比特币的链上元币所缺乏的重要功能：直接用这种货币支付交易费的能力。实现这种能力的方法是在合约里维护一个以太币账户以用来为发送者支付交易费，通过收集被用来充当交易费用的内部货币并把它们在一个不断运行的拍卖中拍卖掉，合约不断为该以太币账户注资。这样用户需要用以太币“激活”他们的账户，但一旦账户中有以太币它将会被重复使用因为每次合约都会为其充值。金融衍生品和价值稳定的货币金融衍生品是“智能合约”的最普遍的应用，也是最易于用代码实现的之一。实现金融合约的主要挑战是它们中的大部分需要参照一个外部的价格发布器；例如，一个需求非常大的应用是一个用来对冲以太币（或其它密码学货币）相对美元价格波动的智能合约，但该合约需要知道以太币相对美元的价格。最简单地方法是通过由某特定机构（例如纳斯达克）维护的“数据提供“合约进行，该合约的设计使得该机构能够根据需要更新合约，并提供一个接口使得其它合约能够通过发送一个消息给该合约以获取包含价格信息的回复。当这些关键要素都齐备，对冲合约看起来会是下面的样子：等待A输入1000以太币。.等待B 输入1000以太币。通过查询数据提供合约，将1000以太币的美元价值，例如，x美元，记录至存储器。30天后，允许A或B“重新激活“合约以发送价值x美元的以太币（重新查询数据提供合约以获取新价格并计算）给A并将剩余的以太币发送给B。 这样的合约在密码学商务中有非同寻常的潜力。密码学货币经常被诟病的一个问题就是其价格的波动性；虽然大量的用户和商家可能需要密码学资产所带来的安全和便利，可他们不太会乐意面对一天中资产跌去23%价值的情形。直到现在，最为常见的推荐方案是发行者背书资产；思想是发行者创建一种子货币，对此种子货币他们有权发行和赎回，给予（线下）提供给他们一个单位特定相关资产（例如黄金，美元）的人一个单位子货币。发行者承诺当任何人送还一个单位密码学资产时。发还一个单位的相关资产。这种机制能够使任何非密码学资产被“升级“为密码学资产，如果发行者值得信任的话。 然而实践中发行者并非总是值得信任的，并且一些情况下银行体系太脆弱，或者不够诚实守信从而使这样的服务无法存在。金融衍生品提供了一种替代方案。这里将不再有提供储备以支撑一种资产的单独的发行者，取而代之的是一个由赌一种密码学资产的价格会上升的投机者构成的去中心化市场。与发行者不同，投机者一方没有讨价还价的权利，因为对冲合约把他们的储备冻结在了契约中。注意这种方法并非是完全去中心化的，因为依然需要一个可信任的提供价格信息的数据源，尽管依然有争议这依然是在降低基础设施需求（与发行者不同，一个价格发布器不需要牌照并且似乎可归为自由言论一类）和降低潜在欺诈风险方面的一个巨大的进步。身份和信誉系统最早的替代币，域名币，尝试使用一个类比特币块链来提供一个名称注册系统，在那里用户可以将他们的名称和其它数据一起在一个公共数据库注册。最常用的应用案例把象“bitcoin.org“（或者再域名币中，”bitcoin.bit“）一样的域名与一个IP地址对应的域名系统。其它的应用案例包括电子邮件验证系统和潜在的更先进的信誉系统。这里是以太坊中提供与域名币类似的的名称注册系统的基础合约：def register(name, value):

if !self.storage[name]:

self.storage[name] = value复制合约非常简单；就是一个以太坊网络中的可以被添加但不能被修改或移除的数据库。任何人都可以把一个名称注册为一个值并永远不变。一个更复杂的名称注册合约将包含允许其他合约查询的“功能条款“，以及一个让一个名称的”拥有者“（即第一个注册者）修改数据或者转让所有权的机制。甚至可以在其上添加信誉和信任网络功能。去中心化存储在过去的几年里出现了一些大众化的在线文件存储初创公司，最突出的是Dropbox，它寻求允许用户上传他们的硬盘备份，提供备份存储服务并允许用户访问从而按月向用户收取费用。然而，在这一点上这个文件存储市场有时相对低效；对现存服务的粗略观察表明，特别地在“神秘谷“20-200GB这一既没有免费空间也没有企业级用户折扣的水平上，主流文件存储成本每月的价格意味着支付在一个月里支付整个硬盘的成本。以太坊合约允许去中心化存储生态的开发，这样用户通过将他们自己的硬盘或未用的网络空间租出去以获得少量收益，从而降低了文件存储的成本。这样的设施的基础性构件就是我们所谓的“去中心化Dropbox合约“。这个合约工作原理如下。首先，某人将需要上传的数据分成块，对每一块数据加密以保护隐私，并且以此构建一个默克尔树。然后创建一个含以下规则的合约，每N个块，合约将从默克尔树中抽取一个随机索引（使用能够被合约代码访问的上一个块的哈希来提供随机性）， 然后给第一个实体X以太以支撑一个带有类似简化验证支付（SPV）的在树中特定索引处的块的所有权证明。当一个用户想重新下载他的文件，他可以使用微支付通道协议（例如每32k字节支付1萨博）恢复文件；从费用上讲最高效的方法是支付者不到最后不发布交易，而是用一个略微更合算的带有同样随机数的交易在每32k字节之后来代替原交易。这个协议的一个重要特征是，虽然看起来象是一个人信任许多不准备丢失文件的随机节点，但是他可以通过秘密分享把文件分成许多小块，然后通过监视合同得知每个小块都还被某个节点的保存着。如果一个合约依然在付款，那么就提供了某个人依然在保存文件的证据。去中心化自治组织通常意义上“去中心化自治组织（DAO, decentralized autonomous organization）”的概念指的是一个拥有一定数量成员或股东的虚拟实体，依靠比如67%多数来决定花钱以及修改代码。成员会集体决定组织如何分配资金。分配资金的方法可能是悬赏，工资或者更有吸引力的机制比如用内部货币奖励工作。这仅仅使用密码学块链技术就从根本上复制了传统公司或者非营利组织的法律意义以实现强制执行。至此许多围绕DAO的讨论都是围绕一个带有接受分红的股东和可交易的股份的“去中心化自治公司（DAC，decentralized autonomous corporation）”的“资本家”模式；作为替代者，一个被描述为“去中心化自治社区（decentralized autonomous community）”的实体将使所有成员都在决策上拥有同等的权利并且在增减成员时要求67%多数同意。每个人都只能拥有一个成员资格这一规则需要被群体强制实施。下面是一个如何用代码实现DO的纲要。最简单地设计就是一段如果三分之二成员同意就可以自我修改的代码。虽然理论上代码是不可更改的，然而通过把代码主干放在一个单独的合约内并且把合约调用的地址指向一个可更改的存储依然可以容易地绕开障碍而使代码变得可修改，在一个这样的DAO合约的简单实现中有三种交易类型，由交易提供的数据区分： [0,i,K,V] 注册索引为i 的对存储地址索引为K 至 v 的内容的更改建议。 [0,i] 注册对建议i 的投票。 [2,i] 如有足够投票则确认建议i。然后合约对每一项都有具体的条款。它将维护一个所有开放存储的更改记录以及一个谁投票表决的表。还有一个所有成员的表。当任何存储内容的更改获得了三分之二多数同意，一个最终的交易将执行这项更改。一个更加复杂的框架会增加内置的选举功能以实现如发送交易，增减成员，甚至提供委任制民主一类的投票代表（即任何人都可以委托另外一个人来代表自己投票，而且这种委托关系是可以传递的，所以如果A委托了B然后B委托了C那么C将决定A的投票）。这种设计将使DAO作为一个去中心化社区有机地成长， 使人们最终能够把挑选合适人选的任务交给专家，与当前系统不同，随着社区成员不断改变他们的站队假以时日专家会容易地出现和消失。 一个替代的模式是去中心化公司，那里任何账户可以拥有0到更多的股份，决策需要三分之二多数的股份同意。一个完整的框架将包括资产管理功能-可以提交买卖股份的订单以及接受这种订单的功能（前提是合约里有订单匹配机制）。代表依然以委任制民主的方式存在，产生了“董事会”的概念。更先进的组织治理机制可能会在将来实现；现在一个去中心化组织（DO）可以从去中心化自治组织（DAO）开始描述。DO和DAO的区别是模糊的，一个大致的分割线是治理是否可以通过一个类似政治的过程或者一个“自动”过程实现，一个不错的直觉测试是“无通用语言”标准：如果两个成员不说同样的语言组织还能正常运行吗？显然，一个简单的传统的持股式公司会失败，而象比特币协议这样的却很可能成功，罗宾·汉森的“futarchy”，一个通过预测市场实现组织化治理的机制是一个真正的说明“自治”式治理可能是什么样子的好例子。注意一个人无需假设所有DAO比所有DO优越；自治只是一个在一些特定场景下有很大优势的，但在其它地方未必可行的范式，许多半DAO可能存在。进一步的应用 储蓄钱包。 假设Alice想确保她的资金安全，但她担心丢失或者被黑客盗走私钥。她把以太币放到和Bob签订的一个合约里，如下所示，这合同是一个银行：Alice单独每天最多可提取1%的资金。Bob单独每天最多可提取1%的资金，但Alice可以用她的私钥创建一个交易取消Bob的提现权限。Alice 和 Bob 一起可以任意提取资金。 一般来讲，每天1%对Alice足够了，如果Alice想提现更多她可以联系Bob寻求帮助。如果Alice的私钥被盗，她可以立即找到Bob把她的资金转移到一个新合同里。如果她弄丢了她的私钥，Bob可以慢慢地把钱提出。如果Bob表现出了恶意，她可以关掉他的提现权限。作物保险。一个人可以很容易地以天气情况而不是任何价格指数作为数据输入来创建一个金融衍生品合约。如果一个爱荷华的农民购买了一个基于爱荷华的降雨情况进行反向赔付的金融衍生品，那么如果遇到干旱，该农民将自动地收到赔付资金而如果有足量的降雨他会很开心因为他的作物收成会很好。一个去中心化的数据发布器。 对于基于差异的金融合约，事实上通过过“谢林点”协议将数据发布器去中心化是可能的。谢林点的工作原理如下：N方为某个指定的数据提供输入值到系统（例如ETH/USD价格），所有的值被排序，每个提供25%到75%之间的值的节点都会获得奖励，每个人都有激励去提供他人将提供的答案，大量玩家可以真正同意的答案明显默认就是正确答案，这构造了一个可以在理论上提供很多数值，包括ETH/USD价格，柏林的温度甚至某个特别困难的计算的结果的去中心化协议。5.云计算。EVM技术还可被用来创建一个可验证的计算环境，允许用户邀请他人进行计算然后选择性地要求提供在一定的随机选择的检查点上计算被正确完成的证据。这使得创建一个任何用户都可以用他们的台式机，笔记本电脑或者专用服务器参与的云计算市场成为可能，现场检查和安全保证金可以被用来确保系统是值得信任的（即没有节点可以因欺骗获利）。虽然这样一个系统可能并不适用所有任务；例如，需要高级进程间通信的任务就不易在一个大的节点云上完成。然而一些其它的任务就很容易实现并行；SETI@home, folding@home和基因算法这样的项目就很容易在这样的平台上进行。6.点对点赌博。任意数量的点对点赌博协议都可以搬到以太坊的区块链上，例如Frank Stajano和Richard Clayton的Cyberdice。 最简单的赌博协议事实上是这样一个简单的合约，它用来赌下一个区块的哈稀值与猜测值之间的差额, 据此可以创建更复杂的赌博协议，以实现近乎零费用和无欺骗的赌博服务。7.预测市场。 不管是有神谕还是有谢林币，预测市场都会很容易实现，带有谢林币的预测市场可能会被证明是第一个主流的作为去中心化组织管理协议的“futarchy”应用。8.链上去中心化市场，以身份和信誉系统为基础。杂项和关注改进版幽灵协议的实施“幽灵“协议（"Greedy Heaviest Observed Subtree" (GHOST) protocol）是由Yonatan Sompolinsky 和 Aviv Zohar在2013年12月引入的创新。幽灵协议提出的动机是当前快速确认的块链因为区块的高作废率而受到低安全性困扰；因为区块需要花一定时间（设为t）扩散至全网，如果矿工A挖出了一个区块然后矿工B碰巧在A的区块扩散至B之前挖出了另外一个区块，矿工B的区块就会作废并且没有对网络安全作出贡献。此外，这里还有中心化问题：如果A是一个拥有全网30%算力的矿池而B拥有10%的算力，A将面临70%的时间都在产生作废区块的风险而B在90%的时间里都在产生作废区块。因此，如果作废率高，A将简单地因为更高的算力份额而更有效率，综合这两个因素，区块产生速度快的块链很可能导致一个矿池拥有实际上能够控制挖矿过程的算力份额。正如Sompolinsky 和 Zohar所描述的，通过在计算哪条链“最长”的时候把废区块也包含进来，幽灵协议解决了降低网络安全性的第一个问题；这就是说，不仅一个区块的父区块和更早的祖先块，祖先块的作废的后代区块（以太坊术语中称之为“叔区块”）也被加进来以计算哪一个区块拥有支持其的最大工作量证明。我们超越了Sompolinsky 和 Zohar所描述的协议以解决第二个问题 – 中心化倾向，以太坊付给以“叔区块”身份为新块确认作出贡献的废区块87.5%的奖励，把它们纳入计算的“侄子区块”将获得奖励的12.5%，不过，交易费用不奖励给叔区块。 以太坊实施了一个只下探到第五层的简化版本的幽灵协议。其特点是，废区块只能以叔区块的身份被其父母的第二代至第五代后辈区块，而不是更远关系的后辈区块（例如父母区块的第六代后辈区块，或祖父区块的第三代后辈区块）纳入计算。这样做有几个原因。首先，无条件的幽灵协议将给计算给定区块的哪一个叔区块合法带来过多的复杂性。其次，带有以太坊所使用的补偿的无条件的幽灵协议剥夺了矿工在主链而不是一个公开攻击者的链上挖矿的激励。最后，计算表明带有激励的五层幽灵协议即使在出块时间为15s的情况下也实现了了95%以上的效率，而拥有25%算力的矿工从中心化得到的益处小于3%。费用因为每个发布的到区块链的交易都占用了下载和验证的成本，需要有一个包括交易费的规范机制来防范滥发交易。比特币使用的默认方法是纯自愿的交易费用，依靠矿工担当守门人并设定动态的最低费用。因为这种方法是“基于市场的”，使得矿工和交易发送者能够按供需来决定价格，所以这种方法在比特币社区被很顺利地接受了。然而，这个逻辑的问题在于，交易处理并非一个市场；虽然根据直觉把交易处理解释成矿工给发送者提供的服务是很有吸引力的，但事实上一个矿工收录的交易是需要网络中每个节点处理的，所以交易处理中最大部分的成本是由第三方而不是决定是否收录交易的矿工承担的。于是，非常有可能发生公地悲剧。然而，当给出一个特殊的不够精确的简化假设时，这个基于市场的机制的漏洞很神奇地消除了自己的影响。论证如下。假设：一个交易带来 k 步操作, 提供奖励 kR给任何收录该交易的矿工，这里 R 由交易发布者设定， k 和 R 对于矿工都是事先（大致上）可见的。每个节点处理每步操作的成本都是 C (即所有节点的效率一致)。有 N 个挖矿节点，每个算力一致(即全网算力的1/N)。没有不挖矿的全节点。当预期奖励大于成本时，矿工愿意挖矿。这样，因为矿工有1/N 的机会处理下一个区块，所以预期的收益是 kR/N , 矿工的处理成本简单为 kC. 这样当 kR/N > kC， 即 R > NC时。矿工愿意收录交易。注意 R 是由交易发送者提供的每步费用，是矿工从处理交易中获益的下限。 NC 是全网处理一个操作的成本。所以，矿工仅有动机去收录那些收益大于成本的交易。 然而，这些假设与实际情况有几点重要的偏离：因为额外的验证时间延迟了块的广播因而增加了块成为废块的机会，处理交易的矿工比其它的验证节点付出了更高的成本。不挖矿的全节点是存在的。实践中算力分布可能最后是极端不平均的。以破坏网络为己任的投机者，政敌和疯子确实存在，并且他们能够聪明地设置合同使得他们的成本比其它验证节点低得多。 上面第1点驱使矿工收录更少的交易，第2点增加了 NC; 因此这两点的影响至少部分互相抵消了. 第3点和第4点是主要问题；作为解决方案我们简单地建立了一个浮动的上限：没有区块能够包含比BLK_LIMIT_FACTOR 倍长期指数移动平均值更多的操作数。具体地：blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) /EMA_FACTOR)BLK_LIMIT_FACTOR 和 EMA_FACTOR 是暂且被设为 65536 和 1.5 的常数，但可能会在更深入的分析后调整。 回复计算和图灵完备需要强调的是以太坊虚拟机是图灵完备的； 这意味着EVM代码可以实现任何可以想象的计算，包括无限循环。EVM代码有两种方式实现循环。首先， JUMP 指令可以让程序跳回至代码前面某处，还有允许如 while x < 27: x = x * 2 一样的条件语句的JUMPI 指令实现条件跳转。其次，合约可以调用其它合约，有通过递归实现循环的潜力。这很自然地导致了一个问题：恶意用户能够通过迫使矿工和全节点进入无限循环而不得不关机吗？ 这问题出现是因为计算机科学中一个叫停机问题的问题：一般意义上没有办法知道，一个给定的程序是否能在有限的时间内结束运行。正如在状态转换章节所述，我们的方案通过为每一个交易设定运行执行的最大计算步数来解决问题，如果超过则计算被恢复原状但依然要支付费用。消息以同样的方式工作。为显示这一方案背后的动机，请考虑下面的例子：一个攻击者创建了一个运行无限循环的合约，然后发送了一个激活循环的交易给矿工，矿工将处理交易，运行无限循环直到瓦斯耗尽。即使瓦斯耗尽交易半途停止，交易依然正确（回到原处）并且矿工依然从攻击者哪里挣到了每一步计算的费用。一个攻击者创建一个非常长的无限循环意图迫使矿工长时间内一直计算致使在计算结束前若干区块已经产生于是矿工无法收录交易以赚取费 用。然而，攻击者需要发布一个 STARTGAS 值以限制可执行步数，因而矿工将提前知道计算将耗费过多的步数。一个攻击者看到一个包含诸如 send(A,self.storage); self.storage = 0格式的合约然后发送带有只够执行第一步的费用的而不够执行第二步的交易（即提现但不减少账户余额）。合约作者无需担心防卫类似攻击，因为如果执行中途停止则所有变更都被回复。一个金融合约靠提取九个专用数据发布器的中值来工作以最小化风险，一个攻击者接管了其中一个数据提供器，然后把这个按DAO章节所述的可变地址调用机制设计成可更改的数据提供器转为运行一个无限循环，以求尝试逼迫任何从此金融合约索要资金的尝试都会因瓦斯耗尽而中止。然而，该金融合约可以在消息里设置瓦斯限制以防范此类问题。 图灵完备的替代是图灵不完备，这里 JUMP 和 JUMPI 指令不存在并且在某个给定时间每个合约只允许有一个拷贝存在于调用堆栈内。在这样的系统里，上述的费用系统和围绕我们的方案的效率的不确定性可能都是不需要的，因为执行一个合约的成本将被它的大小决定。此外，图灵不完备甚至不是一个大的限制，在我们内部设想的所有合约例子中，至今只有一个需要循环，而且即使这循环也可以被26个单行代码段的重复所代替。考虑到图灵完备带来的严重的麻烦和有限的益处，为什么不简单地使用一种图灵不完备语言呢？事实上图灵不完备远非一个简洁的解决方案。为什么？请考虑下面的合约：C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

...

C49: call(C50); call(C50);

C50: (作一个图灵机的步计算和记录结果在合约的长期存储)复制现在，发送一个这样的交易给A，这样，在51个交易中，我们有了一个需要花费2^50 步计算的合约，矿工可能尝试通过为每一个合约维护一个最高可执行步数并且对于递归调用其它合约的合约计算可能执行步数从而预先检测这样的逻辑炸弹，但是这会使矿工禁止创建其它合约的合约（因为上面26个合约的创建和执行可以很容易地放入一个单独合约内）。另外一个问题点是一个消息的地址字段是一个变量，所以通常来讲可能甚至无法预先知道一个合约将要调用的另外一个合约是哪一个。于是，最终我们有了一个惊人的结论：图灵完备的管理惊人地容易，而在缺乏同样的控制时图灵不完备的管理惊人地困难- 那为什么不让协议图灵完备呢？货币和发行以太坊网络包含自身的内置货币以太币，以太币扮演双重角色，为各种数字资产交易提供主要的流动性，更重要的是提供了了支付交易费用的一种机制。为便利及避免将来的争议期间（参见当前的mBTC/uBTC/聪的争论），不同面值的名称将被提前设置：1: 伟10^12: 萨博10^15: 芬尼10^18: 以太这应该被当作是“元”和“分”或者“比特币”和“聪”的概念的扩展版，在不远的将来，我们期望“以太”被用作普通交易，“芬尼”用来进行微交易，“萨博”和“伟”用来进行关于费用和协议实施的讨论。发行模式如下：通过发售活动，以太币将以每BTC 1337-2000以太的价格发售，一个旨在为以太坊组织筹资并且为开发者支付报酬的机制已经在其它一些密码学货币平台上成功使用。早期购买者会享受较大的折扣，发售所得的BTC将完全用来支付开发者和研究者的工资和悬赏，以及投入密码学货币生态系统的项目。0.099x （x为发售总量）将被分配给BTC融资或其它的确定性融资成功之前参与开发的早期贡献者，另外一个0.099x将分配给长期研究项目。自上线时起每年都将有0.26x（x为发售总量）被矿工挖出。发行分解永久线性增长模型降低了在比特币中出现的财富过于集中的风险，并且给予了活在当下和将来的人公平的机会去获取货币，同时保持了对获取和持有以太币的激励，因为长期来看“货币供应增长率”是趋于零的。我们还推断，随着时间流逝总会发生因为粗心和死亡等原因带来的币的遗失，假设币的遗失是每年货币供应量的一个固定比例，则最终总的流通中的货币供应量会稳定在一个等于年货币发行量除以遗失率的值上（例如，当遗失率为1%时，当供应量达到30x时，每年有0.3x被挖出同时有0.3x丢失，达到一个均衡）。image

除了线性的发行方式外，和比特币一样以太币的的供应量增长率长期来看也趋于零。image挖矿的中心化比特币挖矿算法基本上是让矿工千万次地轻微改动区块头，直到最终某个节点的改动版本的哈希小于目标值（目前是大约2190）。然而，这种挖矿算法容易被两种形式的中心化攻击。第一种，挖矿生态系统被专门设计的因而在比特币挖矿这一特殊任务上效率提高上千倍的ASICs（专用集成电路）和电脑芯片控制。这意味着比特币挖矿不再是高度去中心化的和追求平等主义的，而是需要巨额资本的有效参与。第二种，大部分比特币矿工事实上不再在本地完成区块验证；而是依赖中心化的矿池提供区块头。这个问题可以说很严重：在本文写作时，最大的两个矿池间接地控制了大约全网50%的算力，虽然当一个矿池或联合体尝试51%攻击时矿工可以转换到其它矿池这一事实减轻了问题的严重性。以太坊现在的目的是使用一个基于为每1000个随机数随机产生唯一哈希的函数的挖矿算法，用足够宽的计算域，去除专用硬件的优势。这样的策略当然不会使中心化的收益减少为零，但是也不需要。注意每单个用户使用他们的私人笔记本电脑或台式机就可以几乎免费地完成一定量的挖矿活动，但当到了100%的CPU使用率之后更多地挖矿就会需要他们支付电力和硬件成本。ASIC挖矿公司需要从第一个哈希开始就为电力和硬件支付成本。所以，如果中心化收益能够保持在(E + H) /E 以下，那么即使ASICs被制造出来普通矿工依然有生存空间。另外，我们计划将挖矿算法设计成挖矿需要访问整个区块链，迫使矿工存储完成的区块链或者至少能够验证每笔交易。这去除了对中心化矿池的需要；虽然矿池依然可以扮演平滑收益分配的随机性的角色，但这功能可以被没有中心化控制的P2P矿池完成地同样好。这样即使大部分普通用户依然倾向选择轻客户端，通过增加网络中的全节点数量也有助于抵御中心化。扩展性扩展性问题是以太坊常被关注的地方，与比特币一样，以太坊也遭受着每个交易都需要网络中的每个节点处理这一困境的折磨。比特币的当前区块链大小约为20GB，以每小时1MB的速度增长。如果比特币网络处理Visa级的2000tps的交易，它将以每三秒1MB的速度增长（1GB每小时，8TB每年）。以太坊可能也会经历相似的甚至更糟的增长模式，因为在以太坊区块链之上还有很多应用，而不是像比特币只是简单的货币，但以太坊全节点只需存储状态而不是完整的区块链历史这一事实让情况得到了改善。大区块链的问题是中心化风险。如果块链大小增加至比如100TB，可能的场景将是只有非常小数目的大商家会运行全节点，而常规用户使用轻的SPV节点。这会增加对全节点合伙欺诈牟利（例如更改区块奖励，给他们自己BTC）的风险的担忧。轻节点将没有办法立刻检测到这种欺诈。当然，至少可能存在一个诚实的全节点，并且几个小时之后有关诈骗的信息会通过Reddit这样的渠道泄露，但这时已经太晚：任凭普通用户做出怎样的努力去废除已经产生的区块，他们都会遇到与发动一次成功的51%攻击同等规模的巨大的不可行的协调问题。在比特币这里，现在这是一个问题，但Peter Todd建议的一个改动可以缓解这个问题。近期，以太坊会使用两个附加的策略以应对此问题。首先，因为基于区块链的挖矿算法，至少每个矿工会被迫成为一个全节点，这保证了一定数量的全节点。其次，更重要的是，处理完每笔交易后，我们会把一个中间状态树的根包含进区块链。即使区块验证是中心化的，只要有一个诚实的验证节点存在，中心化的问题就可以通过一个验证协议避免。如果一个矿工发布了一个不正确的区块，这区块要么是格式错，要么状态S[n]是错的。因为S[0]是正确的，必然有第一个错误状态S[i]但S[i-1]是正确的，验证节点将提供索引i，一起提供的还有处理APPLY(S[i-1],TX[i]) -> S[i]所需的帕特里夏树节点的子集。这些节点将受命进行这部分计算，看产生的S[i]与先前提供的值是否一致。另外，更复杂的是恶意矿工发布不完整区块进行攻击，造成没有足够的信息去确定区块是否正确。解决方案是质疑-回应协议：验证节点对目标交易索引发起质疑，接受到质疑信息的轻节点会对相应的区块取消信任，直到另外一个矿工或者验证者提供一个帕特里夏节点子集作为正确的证据。综述：去中心化应用上述合约机制使得任何一个人能够在一个虚拟机上建立通过全网共识来运行命令行应用（从根本上来说是），它能够更改一个全网可访问的状态作为它的“硬盘”。然而，对于多数人来说，用作交易发送机制的命令行接口缺乏足够的用户友好使得去中心化成为有吸引力的替代方案。最后，一个完整的“去中心化应用”应该包括底层的商业逻辑组件【无论是否在以太坊完整实施，使用以太坊和其它系统组合（如一个P2P消息层，其中一个正在计划放入以太坊客户端）或者仅有其它系统的方式】和上层的图形用户接口组件。以太坊客户端被设计成一个网络浏览器，但包括对“eth” Javascript API对象的支持，可被客户端里看到的特定的网页用来与以太坊区块链交互。从“传统”网页的角度看来，这些网页是完全静态的内容，因为区块链和其它去中心化协议将完全代替服务器来处理用户发起的请求。最后，去中心化协议有希望自己利用某种方式使用以太坊来存储网页。结论以太坊协议最初是作为一个通过高度通用的语言提供如链上契约，提现限制和金融合约，赌博市场等高级功能的升级版密码学货币来构思的。以太坊协议将不直接“支持”任何应用，但图灵完备编程语言的存在意味着理论上任意的合约都可以为任何交易类型和应用创建出来。然而关于以太坊更有趣的是，以太坊协议比单纯的货币走得更远，围绕去中心化存储，去中心化计算和去中心化预测市场以及数十个类似概念建立的协议和去中心化应用，有潜力从根本上提升计算行业的效率，并通过首次添加经济层为其它的P2P协议提供有力支撑，最终，同样会有大批与金钱毫无关系的应用出现。以太坊协议实现的任意状态转换概念提供了一个具有独特潜力的平台；与封闭式的，为诸如数据存储，赌博或金融等单一目的设计的协议不同，以太坊从设计上是开放式的，并且我们相信它极其适合作为基础层服务于在将来的年份里出现的极其大量的金融和非金融协议。注解与进阶阅读注解1.一个有经验的读者会注意到事实上比特币地址是椭圆曲线公钥的哈希，而非公钥本身，然而事实上从密码学术语角度把公钥哈希称为公钥完全合理。这是因为比特币密码学可以被认为是一个定制的数字签名算法，公钥由椭圆曲线公钥的哈希组成，签名由椭圆曲线签名连接的椭圆曲线公钥组成，而验证算法包括用作为公钥提供的椭圆曲线公钥哈希来检查椭圆曲线公钥，以及之后的用椭圆曲线公钥来验证椭圆曲线签名。2.技术上来说，前11个区块的中值。3.在内部，2和“CHARLIE”都是数字，后一个有巨大的base256编码格式，数字可以从0到2^256-1。进阶阅读Intrinsic value: https://tinyurl.com/BitcoinMag-IntrinsicValueSmart property: https://en.bitcoin.it/wiki/Smart_PropertySmart contracts: https://en.bitcoin.it/wiki/ContractsB-money: http://www.weidai.com/bmoney.txtReusable proofs of work: http://www.finney.org/~hal/rpow/Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.htmlBitcoin whitepaper: http://bitcoin.org/bitcoin.pdfNamecoin: https://namecoin.org/Zooko’s triangle: http://en.wikipedia.org/wiki/Zooko’s_triangleColored coins whitepaper: https://tinyurl.com/coloredcoin-whitepaperMastercoin whitepaper: https://github.com/mastercoin-MSC/specDecentralized autonomous corporations, Bitcoin Magazine: https://tinyurl.com/Bootstrapping-DACsSimplified payment verification:https://en.bitcoin.it/wiki/Scalability#SimplifiedpaymentverificationMerkle trees: http://en.wikipedia.org/wiki/Merkle_treePatricia trees: http://en.wikipedia.org/wiki/Patricia_treeGHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdfStorJ and Autonomous Agents, Jeff Garzik: https://tinyurl.com/storj-agentsMike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5YEthereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLPEthereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-TreePeter Todd on Merkle sum trees:http://sourceforge.net/p/bitcoin/mailman/message/31709140/本文参与 腾讯云自媒体分享计划，分享自作者个人站点/博客。 原始发表：2018.01.19 ，如有侵权请联系 cloudcommunity@tencent.com 删除前往查看其他本文分享自 作者个人站点/博客 前往查看如有侵权，请联系 cloudcommunity@tencent.com 删除。本文参与 腾讯云自媒体分享计划  ，欢迎热爱写作的你一起参与！其他评论登录后参与评论0 条评论热度最新登录 后参与评论推荐阅读LV.关注文章0获赞0目录以太坊（Ethereum ）:下一代智能合约和去中心化应用平台目录历史作为状态转换系统的比特币挖矿 默克尔树 其它的区块链应用 脚本 以太坊 以太坊账户 消息和交易 以太坊状态转换函数 代码执行 区块链和挖矿 应用令牌系统金融衍生品和价值稳定的货币身份和信誉系统去中心化存储去中心化自治组织进一步的应用杂项和关注改进版幽灵协议的实施费用计算和图灵完备货币和发行发行分解挖矿的中心化扩展性综述：去中心化应用结论注解与进阶阅读注解进阶阅读相关产品与服务文件存储文件存储（Cloud File Storage，CFS）为您提供安全可靠、可扩展的共享文件存储服务。文件存储可与腾讯云服务器、容器服务、批量计算等服务搭配使用，为多个计算节点提供容量和性能可弹性扩展的高性能共享存储。腾讯云文件存储的管理界面简单、易使用，可实现对现有应用的无缝集成；按实际用量付费，为您节约成本，简化 IT 运维工作。产品介绍产品文档2024新春采购节领券社区专栏文章阅读清单互动问答技术沙龙技术视频团队主页腾讯云TI平台活动自媒体分享计划邀请作者入驻自荐上首页技术竞赛资源技术周刊社区标签开发者手册开发者实验室关于社区规范免责声明联系我们友情链接腾讯云开发者扫码关注腾讯云开发者领取腾讯云代金券热门产品域名注册云服务器区块链服务消息队列网络加速云数据库域名解析云存储视频直播热门推荐人脸识别腾讯会议企业云CDN加速视频通话图像分析MySQL 数据库SSL 证书语音识别更多推荐数据安全负载均衡短信文字识别云点播商标注册小程序开发网站监控数据迁移Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档Copyright © 2013 - 2024 Tencent Cloud.All Rights Reserved. 腾讯云 版权所有登录 后参与评论00