叔块奖励
GHOST协议是一项不起的创新，由YonatanSompolinsky和AvivZohar在2013年10月首次提出的。它是解决快速出块伴生问题的第一个认真尝试。
GHOST的用意是解决这样一个难题：更短的出块时间会导致有更多区块“过时”因而安全性会下降——因为区块在网络中传播需要一定时间，如果矿工A挖到一个区块并向全网广播，在广播的路上，B也挖出了区块，那么B的区块是过时的，且B的本次挖矿对网络的安全没有贡献。
此外，还有一个中心化问题：如果A是一个矿池，有30%的算力，B有10%的算力。A有70%的时间产生过时的区块，而B有90%的时间产生过时区块。如果区块的产出时间间隔很短，那么过时率就会变高，则A凭借其更大的算力使挖矿效率也更高。所以，区块生成过快，容易导致网络算力大的矿池在事实上垄断挖矿过程。
根据Sompolinsky和Zohar的描述，GHOST解决了在计算哪个链是最长的链的过程中，因产生过时区块而造成的网络安全性下降的问题。也就是说，不仅是父区块和更早的区块，同时过时的旁支区块也被添加到计算哪个块具有最大的总工作量证明中去。
为了解决第二个问题：中心化问题，我们采用了另一种策略：对过时区块也提供区块奖励：挖到过时区块的奖励是该区块基础奖励的7/8；而包含过时区块的侄子区块将收到1/32的基础奖励作为赏金。但是，交易费不会奖励给叔块和侄块。
在以太坊中，过时区块只能被其兄弟区块的7代以内的直系后代区块包含为叔块。之所以这样限制是因为，首先，GHOST协议若不限制过时区块的代际距离，将会花费大量开销在计算过时区块的有效性上；其次，无限制的过时区块激励政策会让矿工失去在主链上挖矿的热情；最后，计算表明，过时区块奖励政策限制在7层内提供了大部分所需的效果，而且不会带来负面效应。
度量中心化风险的一个模拟器可见此处：https://github.com/ethereum/economic-modeling/blob/master/ghost.py
一个更高层次的讨论可见此处：https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
校对注：此处的“包含”在技术上的形式是：侄块在区块头中引用叔块的区块哈希值，然后把叔块的区块头包含在区块体内。
区块时间算法的设计决策包括:
区块时间12s：选择12秒是因为这已经是长于网络延迟的最短时间间隔了。在2013年的一份关于测量比特币网络延迟的论文中，确定了12.6秒是新产生的区块传播到95%节点的时间；然而，该论文还指出传播时间与区块大小成比例，因此在更快的货币中，我们可以期待传播时间大大减少。传播间隔时间是恒定的，约为2秒。然而，为了安全起见，在我们的分析中，我们假定区块的传播需要12秒
7代祖先以内的限制：这样设计的目的是希望只保留少量区块，而将更早之前的区块清除。已经证明7代的可引用范围就可以提供大部分所需的效果。
1代后裔的限制：：这也是出于简洁性的设计目标，而且上述的模拟器显示这不会带来很大的中心化风险。
叔块必须是有效的?：叔块必须是有效的header，而不是有效的区块。这样做也是为了简化，将区块链模型保持为线性数据结构。不过，要求叔块是有效的区块也是有效的方法。
奖金分配：7/8的挖矿基础奖励分配给叔块，1/32分给侄块，它们交易费用都是0%。如果费用占多数，从中心化的角度看，这会使叔块激励机制无效；然而，这也是为什么只要我们继续使用PoW，以太坊就会不断发行以太币的原因。
难度更新算法
目前以太坊通过以下规则进行难度更新：
难度更新规则的设计目标如下：
快速更新：区块间的时间应该随着hash算力的增减而快速调整；
低波动性：如果挖矿算力恒定，那么难度不应剧烈波动；
简单：算法的实现应相对简单；
低内存：算法不应依赖于过多的历史区块，要尽可能少的使用“内存变量”。假设有最新的十个区块，将存储在这十个区块头部的内存变量相加，这些区块都可用于算法的计算；
不可爆破：算法不应让矿工有过多篡改时间戳或者矿池反复添加或删除算力的激励
我们当前的算法在低波动性和抗爆破性上并不理想。最近，我们计划把时间戳参数改为与父区块和祖父区块比较，所以矿工只有在连续挖2个区块时，才有动力去修改时间戳。另一个更强大的模拟公式：?
https://github.com/ethereum/economic-modeling/blob/master/diffadjust/blkdiff.py?
Gas和费用
比特币中所有交易大体相同，因此它们的网络成本用单一一种单位来模拟。以太坊中的交易要更复杂，所以交易费用需要考虑到账户的许多方面，包括网络带宽费用、存储费用和计算费用。尤其重要的是，以太坊编程语言是图灵完备的，所以交易会使用任意数量的宽带、存储和计算成本；而最终会使用多少数量是无法可靠预测的。防止有人使用无限循环来实施拒绝服务式攻击是我们的一个关键目标。
以太坊交易费用的基本机制如下：
每笔交易必须指明自身愿意消耗的gas数量，以及愿意为每单元gas支付的费用，在交易执行开始时，startgas*gasprice价值的以太币会从发送者账户中扣除；
交易执行期间的所有操作，包括读写数据库、发送消息以及每一步的计算都会消耗一定数量的gas；
如果交易执行完毕，消耗的gas值小于指定的限制值，则交易执行正常，并将剩余的gas值赋予变量?gas_rem?;在交易完成后，发送者会收到返回的gas_rem*gasprice价值的以太币，而给矿工的奖励是*gasprice价值的以太币；
如果交易执行中，gas消耗殆尽，则所有的执行恢复原样，但交易仍然有效，只是交易的唯一结果是将startgas*gasprice价值的以太币支付给矿工，其他不变；
当一个合约发送消息给另一个合约，可以对这个消息引起的子执行设置一个gas限制。如果子执行耗尽了gas，则子执行恢复原样，但gas仍然消耗。，这一点还未改变，但它在未来有可能会改变。
上述提到的几点都是必须满足的，例如：
如果交易不需要指定gas限制，那么恶意用户就会发送一个有数十亿步循环的交易。没有人能够处理这样的交易，因为处理这样的交易花的时间可能很长很长；但是谁也无法预先告知网络上的矿工，这就会导致拒绝服务的漏洞产生。
一种替代严格gas计数的方法是时间限制，但它不可能有用，因为它们太主观了。
startgas*gasprice的整个值，在开始时就应该设置好，这样不至于在交易执行中造成该账户“破产”、无力继续支付gas费用。一边执行一边检查余额也不行，因为账户可以把余额放到别的地方。
如果在gas不够的情况下，交易执行不会完全复原，合约就必须采用强有力的安全措施来防止合约发生变化。
如果子限制不存在，则恶意账户可以对其他合约实施拒绝服务攻击。攻击者可以先与受害合约达成一致意见，然后在计算过程开始时插入一个无限循环，那么发送消息给受害合约或者受害合约的任何补救尝试，都会使整个交易死锁。
要求交易发送者而不是合约来支付gas，这样大大增加了开发人员的可操作性。以太坊早期的版本是由合约来支付gas的，这导致了一个相当严重的问题：每个合约必须实现“门卫”代码，确保每个传入的消息为合约提供了足够的以太币供其消耗。
gas消耗计算有以下特点：
对于任何交易，都将收取21000gas的基本费用。这些费用可用于支付运行椭圆曲线算法所需的费用以及存储交易所花费的硬盘和带宽空间。
交易可以包括无限量的“数据”。虚拟机中的某些操作码，可以让收到这样交易的合约访问这些数据。数据的“固定消耗量”规则是：每个零字节4gas，非零字节68gas。这个公式的产生是因为用户向合约发送的交易中，大部分的交易数据由一系列的32字节的参数组成，其中多数参数具有许多前导零字节。该结构看起来似乎效率不高，但由于压缩算法的存在，实际上还是很有效率的。我们希望此结构能够代替其他更复杂的机制：这些机制根据预期字节数严格包装参数，从而导致编译阶段复杂性大增。这是三明治复杂模型的一个例外，但由于成本效益比，这也是合理的模型。
用于设置账户存储项的操作码SSTORE的消耗是：1）将零值改为非零值时，消耗20000gas；2）将零值变成零值，或非零值变非零值，消耗5000gas；3）将非零值变成零值，消耗5000gas；此外，交易执行成功后会退回15000gas。退款金额上限是交易消耗gas总额的50%。这给了人们小小激励去清除存储项。我们注意到，正因为缺乏这样的激励，许多合约的存储空间没有被有效使用，从而导致了存储数据的快速膨胀。这一设计既能提供“为存储项持续收取租金”模式的大部分好处，又不会失去合约一旦确立就可以永久存在的保证。延迟退款机制是必要的，因为可以阻止拒绝服务攻击：攻击者可以发送一笔含有少量gas的交易，循环清除大量的存储项，直到用光gas，这样消耗了大量的验证算力，但实际并没有真正清除存储，也不需要付出很多gas。50%的上限的是为了确保打包交易的矿工依然能够确定执行交易的计算时间的上限。
（校对注：首先，SSTORE等状态访问操作码的gas消耗量已经随着以太坊的硬分叉而多次更改。截至2021年7月，最新的数值可见《柏林升级内容概览》；在可预见的未来，这个操作码的数值还会继续变化；其次，这里的gasrefund机制，事后证明并没有启动缓解状态数据的膨胀问题，反而恶化了该问题，因为人们可以在gasprice较低时写入大量垃圾数据，在gasprice较高时清除这些数据来获得gas，这就是“GasToken”的原理。当前已确定，在“伦敦”分叉中会改变gasrefund机制。
合约提供的消息数据是没有成本的。因为在消息调用期间不需要实质复制任何数据，调用数据可以简单地视为指向父合约memory的指针，该指针在子进程执行时不会改变。
Memory是一个可以无限扩展的数组，然而，每扩展32字节的memory就会消耗1gas的成本，不足32字节以32字节计。
某些操作码的计算时间极度依赖参数，gas开销计算是动态变化的。例如，EXP的的开销是指数级别的。复制操作码的开销是1gas+1gas/32字节。Memory扩展的开销不包含在这里。如若包含，会变成一个平方攻击向量。
如果值不是零，操作码CALL会额外消耗9000gas。这是因为任何值传输都会引起归档节点的历史存储显著增大。请注意，操作的?实际消耗?是6700；但是此基础上，我们强制增加了一个自动给予接收者的gas值，这个值最小2300。这样做是为了让接受交易的钱包至少有足够的gas来生成log。
Gas机制的另一个重要部分是gas价格本身体现出的经济学原理。比特币中，默认的方法是采取纯粹自愿的收费方式，矿工扮演守门人的角色并且动态设置收费的最小值。以太坊中允许交易发送者设置任意数目的gas。这种方式在比特币社区非常受欢迎，因为它是“市场经济”的体现：允许矿工和交易者之间依据供需关系来决定价格。然而，这种方式的问题是，交易处理并不遵循市场原则。尽管可以将交易处理看作是矿工向发送者提供的服务，但实际上矿工所处理的每个交易都必须由网络中的每个节点处理，所以交易处理的大部分成本都由第三方机构承担，而不是决定是否处理它的矿工。因此，“公地悲剧”问题很有可能发生。
当前，因为缺乏矿工在实际中的行为的明确信息，所以我们将采取一个非常简单公平的方法：投票系统，来设定单个区块可消耗的gas总额。矿工有权将在最新区块的gas上限基础上变更0.0975%(1/1024)，作为当前区块的gas上限。所以最终的gas上限应该是矿工们设置的中间值。我们希望将来能够采用软分叉的方法来使用更加精确的算法。
虚拟机
以太坊虚拟机是执行交易代码的引擎，也是以太坊与其他系统的核心区别。请注意，虚拟机应该同“合约与消息模型”分开考虑。例如，SIGNEXTEND操作码是虚拟机的一个功能，但实际上“某个合约可以调用其他合约并指定子调用的gas限定值”是“合约与消息模型”的一部分。
EVM的设计目标如下：
简单：操作码尽可能的少并且低级；数据类型尽可能少；虚拟机的结构尽可能少；
结果明确：在VM规范中，没有任何可能产生歧义的空间，结果应该是完全确定的。此外，计算步骤应该是精确的，以便可以测量gas的消耗量；
节约空间：EVM组件应尽可能紧凑；
为预期用途而特化：在VM上构建的应用应能处理20字节的地址，以及32位的自定义加密值，拥有用于自定义加密的模数运算、读取区块和交易数据与状态交互等能力；
简单安全：为了让VM不被利用，应该能够容易地让建立一套gas消耗成本模型的操作；
优化友好：应该易于优化，以便即时编译和VM的加速版本能够构建出来。
同时EVM也有如下特殊设计：
临时/永久存储的区别：我们先来看看什么是临时存储和永久存储。临时存储：存在于VM的每个实例中，并在VM执行结束后消失。永久存储：存在于区块链状态层。假设执行下面的树：
A调用B；
B设置?B.S=5，B.M=9?；
B调用C；
C调用B。
此时，如果B试图读取?B.S?，它将得到B前面存入的数据，也就是5；但如果B试图读取?B.M?，它将得到0，因为B.M是临时存储，读取它的时候是虚拟机的一个新的实例。在一个内部调用中，如果设置?B.M=13?和?B.S=17?，然后内部调用和C的调用都终止、回到了B的外部调用，此时读取M，将会看到?B.M=9?，?B.S=17?。如果B的外部调用结束，然后A再次调用B，将看到?B.M=0，B.S=17?。这个区别的目的是：1.每个执行实例都分配有内存空间，不会因为循环调用而减损，这让安全编程更加容易。2.提供一个能够快速操作的内存形式：因为需要修改树，所以存储更新必然很慢。
栈/memory模式：早期，计算状态有三种：栈，内存，存储项。在临时存储端，栈和内存的替代方案是memory-only范式，或者是寄存器和内存的混合体。在这种情况下，每个指令都有三个参数，例如：?ADDR1R2R3:M=M+M?。选择栈范式的原因很明显，它使代码缩小了4倍。
单词大小32字节：在大多数结构中，如比特币，单词大小是4或8字节。4或8字节对存储地址和加密计算来说局限性太大了。而不对大小作限制又很难建立相应安全的gas模型。32字节是一个理想大小，因为它足够存储下许多密码算法所需要的大数值以及地址，又不会因为太大而导致效率低下。
我们有自己的虚拟机：我们的虚拟机使用java、Lisp和Lua等语言开发。我们认为开发一款专业的虚拟机是值得的，因为：1）我们的VM规范比其他许多虚拟机简单的多，因为其他虚拟机为复杂性付出的代价更小，也就是说它们更容易变得复杂；然而，在我们的方案中每额外增加一点复杂性，都会给集约化发展带来障碍，并带来潜在的安全缺陷，比如共识错误，这就让我们的复杂性成本很高；2）我们的VM更加专业化，如支持32字节；3）我们不会有复杂的外部依赖，复杂的外部依赖会导致我们安装失败；4）完善的审查机制，可以具体到特殊的安全需求；即使使用外部VM，也无法节省太多工作量。
使用了可变、可扩展的memory大小：固定memory的大小是不必要的限制，太小或太大都不合适。如果内存大小是固定的，每次访问内存都需要检查访问是否超出边界，显然这样的效率并不高。
1024调用深度限制：许多编程语言在内存还没有溢出时，就因为调用深度太深而崩溃了。所以仅使用区块gas上限一种限制是不够的。
无类型：只是为了简洁。不过，DIV、SDIV、MOD、SMOD会使用有符号或无符号的操作码；转换成定点运算在所有情况下都很简单，例如，在32位长度下，a*b->(a*b)/2^32,a/b->a*2^32/b?，+、-和*在整数下不变。
校对注：在原译本中还有如下一段，但其对应段落在当前版本的原文中已经删除了：?栈大小没有限制：没什么特别理由！许多情况下，该设计不是绝对必要的；因为，gas的开销和区块gas上限总是会充当每种资源消耗的上限。
这个VM中某些操作码的功能和用意很容易理解，但也有一些不太好理解，以下是一些特殊的原因：
ADDMOD,MULMOD：大多数情况下，?mulmod(a,b,c)=a*b%c?，但在椭圆曲线算法中，使用的是32字节模数运算，直接执行?a*b%c?实际上是在执行?((a*b)%2^256)%c?，会得到完全不同的结果。在32字节的空间中执行32字节数值的?a*b%c?计算的共识非常困难且繁琐。
SIGNEXTEND：SIGNEXTEND操作码的作用是为了方便从大的有符号整数到小的有符号整数的类型转换。小的有符号整数是很有用的，因为未来的即时编译虚拟机也许有能力检测主要处理32字节整数又长时间运行的代码块，小的有符号整数能加快处理。
SHA3：在以太坊代码中，SHA3作为安全的、高强度的、不定长数据哈希映射方法，应用非常广泛。通常，在使用存储器时，需要使用Hash函数来防止恶意冲突，在验证默克尔树和类似的以太坊数据结构时也需要使用到Hash函数。重要的是，与SHA3的相似的哈希函数，如SHA256、ECRECVOR、RIPEM160，不是以操作码的形式包含在里面，而是以伪合约的形式。这样做的目的是将它们放在一个单独的类别中，如果当我们以后提出适当的“原生插件”系统时，可以添加更多这样的合约，而不需要扩展操作码。
ORIGIN：ORIGIN操作码由交易的发送者提供，主要的作用是允许合约退回支付的gas。
COINBASE:COINBASE的主要作用是：1）允许子货币对网络安全作出贡献；2）使矿工能够作为一个去中心化的经济体，来设置基于子共识的应用，如Schellingcoin。
PREVHASH：PREVHASH可用作一个半安全的随机来源。此外，允许合约求值上一个区块的默克尔树状态证明，而不需要高度复杂的“以太坊轻客户端”递归结构。
EXTCODESIZE,EXTCODECOPY：主要的作用是让合约依据模板检查其他合约的代码，甚至是在与其他合约交互前，模拟它们。见：https://lesswrong.com/lw/aq9/decision_theories_a_less_wrong_primer/
JUMPDEST：当跳转目的地限制在几个索引时，JIT虚拟机实现起来更简单。于是，我们需要：1）对有效变量跳转目的地做限制；2）激励使用静态而不是动态跳转。为了达到这两个目标，我们定下了以下规则：1）紧接着push后的跳转可以跳到任何地方，而不仅是另一个jump；2）其他的jump只能跳转到JUMPDEST。对跳转的限制是必须的，这样就可通过查看代码中的前一个操作来确定当前是一个静态跳转还是动态跳转。缺乏对静态跳转的需求是激励使用它们的原因。禁止跳转进入push数据也会加快JIT虚拟机的编译和执行。
LOG：LOG是事件的日志。
CALLCODE：该操作码允许合约使用自己的存储项，在单独的栈空间和memory中调用其他合约的“函数”。这样可以在区块链上灵活实现标准库代码。
SELFDESTRUCT：允许合约删除它自己，前提是它已经不需要存在了。SELFDESTRUCT并非立即执行，而是在交易执行完之后执行。这是因为如果允许SELFDESTRUCT在执行之后回滚，将会极大地提高缓存的复杂度，不利于高效的VM实现。
PC：尽管理论上不需要PC操作码，因为所有PC操作码的实例都可以根据将push操作的索引加入实际程序计数器来代替实现，但使用PC可以创建独立代码的位置。
原文链接:
https://eth.wiki/en/fundamentals/design-rationale
作者:?Vitalik
翻译&校对:?kim?&?阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。