陈东泽(Eurychen)| 东泽煮粥 - 所见所闻所学所想,煮成一锅粥

Recent content on 陈东泽(Eurychen)| 东泽煮粥 - 所见所闻所学所想,煮成一锅粥

马上订阅 陈东泽(Eurychen)| 东泽煮粥 - 所见所闻所学所想,煮成一锅粥 RSS 更新: https://eurychen.me/index.xml

第1天,读以太坊白皮书 | 5天掌握以太坊 dApp 开发

2020年5月26日 16:18

0 前言

对我来说,了解一个产品最高效的方法就是阅读说明书。在阅读 以太坊白皮书 之后,认为很多概念比较晦涩,在没有实际开发经验的前提下阅读起来比较吃力。因此我会把其中重要又不容易理解的部分单独讲解,来帮助你们读懂以太坊白皮书。

1 比特币解决了拜占庭将军问题

1.1 拜占庭将军问题

比特币以前的所有电子货币协议所遇到的主要障碍是,尽管对如何创建安全的拜占庭问题容错(Byzantine-fault-tolerant)多方共识系统的研究已经历时多年,但是上述协议只解决了问题的一半。这些协议假设系统的所有参与者是已知的,并产生如“如果有N方参与到系统中,那么系统可以容忍N/4的恶意参与者”这样形式的安全边界。然而这个假设的问题在于,在匿名的情况下,系统设置的安全边界容易遭受女巫攻击,因为一个攻击者可以在一台服务器或者僵尸网络上创建数以千计的节点,从而单方面确保拥有多数份额。

—以太坊白皮书

这里提到了一个概念拜占庭问题容错。也可以称之为拜占庭将军问题( Byzantine Generals Problem ),是由 莱斯利·兰波特 在其同名论文中提出的分布式对等网络通信容错问题。

一组拜占庭将军分别各率领一支军队共同围困一座城市。为了简化问题,将各支军队的行动策略限定为进攻或撤离两种。因为部分军队进攻部分军队撤离可能会造成灾难性后果,因此各位将军必须通过投票来达成一致策略,即所有军队一起进攻或所有军队一起撤离。因为各位将军分处城市不同方向,他们只能通过信使互相联系。在投票过程中每位将军都将自己投票给进攻还是撤退的信息通过信使分别通知其他所有将军,这样一来每位将军根据自己的投票和其他所有将军送来的信息就可以知道共同的投票结果而决定行动策略。

系统的问题在于,将军中可能出现叛徒,他们不仅可能向较为糟糕的策略投票,还可能选择性地发送投票信息。假设有7位将军投票,其中1名叛徒。6名忠诚的将军中出现了3人投进攻,3人投撤离的情况。这时候叛徒可能故意给3名投进攻的将领送信表示投票进攻,而给3名投撤离的将领送信表示投撤离。这样一来在3名投进攻的将领看来,投票结果是4人投进攻,从而发起进攻;而在3名投撤离的将军看来则是4人投撤离。这样各支军队的一致协同就遭到了破坏。

拜占庭将军问题本质上是个信任问题,比特币之前的电子货币可以达到容忍N/4的恶意参与者,即系统出现小于N/4个叛徒时依然可以正常运行,但是利用女巫攻击(类似利用多个IP刷量的行为)可以创造大量节点从而恶意篡改投票结果。

1.2 比特币的出现解决拜占庭将军问题

中本聪的创新是引入这样一个理念:将一个非常简单的基于节点的去中心化共识协议与工作量证明机制结合在一起。节点通过工作量证明机制获得参与到系统的权利,每十分钟将交易打包到“区块”中,从而创建出不断增长的区块链。拥有大量算力的节点有更大的影响力,但获得比整个网络更多的算力比创建一百万个节点困难得多。尽管比特币区块链模型非常简陋,但是实践证明它已经足够好用了,在未来五年,它将成为全世界两百个以上的货币和协议的基石。

—以太坊白皮书

比特比解决拜占庭将军的方法是让将军决定之前先计算一道计算复杂但是容易验证的数学题,将军的决策不同题目也会不同。

先计算出来的将军公布计算结果和进攻或撤退指令。其它将军先验证结果正确性,如果正确则执行命令,验证错误则不执行。

这就是比特币的 POW( 工作量证明 )机制,通过计算一个数值( nonce ),使得拼揍上交易数据后内容的 Hash 值满足规定的上限 (计算数学题)。在节点成功找到满足的 Hash 值之后,会马上对全网进行广播打包区块 (公布计算结果),网络的节点收到广播打包区块,会立刻对其进行验证 (其它将军验证)

如果验证通过,则表明已经有节点成功解密,自己就不再竞争当前区块打包,而是选择接受这个区块,记录到自己的账本中,然后进行下一个区块的竞争猜谜。网络中只有最快解谜的区块,才会添加的账本中,其他的节点进行复制,这样就保证了整个账本的唯一性。

假如节点有任何的作弊行为,都会导致网络的节点验证不通过,直接丢弃其打包的区块,这个区块就无法记录到总账本中,作弊的节点耗费的成本就白费了,因此在巨大的挖矿成本下,也使得矿工自觉自愿的遵守比特币系统的共识协议,也就确保了整个系统的安全。

1.3 Account Model 和 UTXO

比特币系统的“状态”是所有已经被挖出的、没有花费的比特币(技术上称为“未花费的交易输出,unspent transaction outputs 或UTXO”)的集合。

—以太坊白皮书

理解这段话我们就必须搞清楚 UTXO 是什么。 其实 Account Model 和 UTXO( unspent transaction outputs ) ,是当前区块链世界里两种 保存交易记录的方式

1.3.1 Account Model

以太坊采用的 Account Model 很好理解,就好像人人都有自己的账户一样。在以太坊的世界里,余额就直接保存在账户地址中,使用区块链浏览器就可以非常直观的查询每笔一交易的细节;

1.3.2 UTXO ( unspent transaction outputs )

然而,我们在区块链浏览器中观察 Bitcoin 的转账记录,却总是让人摸不到头脑。

数据来源 btc.com

相比以太坊,比特币的转账记录一下子多出来了好多个输入与输出。出现这种难以读懂的原因,正是因为比特币采用了 UTXO 模型。 在比特币的世界里,并没有记录账户余额,确定账户余额的方法就是回顾所有之前的转账记录从而计算出余额;(这听起来好傻呀)

UTXO 模型整体来说就确保输入 == 输出

举个例子: Joe 转给 Eury 3BTC,Eric 转给了 Eury 2BTC,那么 Eury 就得到了两笔 UTXO 合计 5BTC; 这时候 Eury 要转给 Judy 4.5 BTC,但是为了满足 输入==输出,4.5BTC 与 Eury 的 UTXO 5BTC 相差了 0.5BTC,所以 Eury就要发出两笔交易来满足 输入 == 输出的条件:

  • 第一笔:Eury –> Judy 4.5BTC
  • 第二笔:Eury –> Eury(自己) 0.5BTC

UTXO 使用起来如此繁琐,那么为何还要使用呢?

这是因为 UTXO 可以有效的防止 Double Spending,也就是双花攻击;矿工要验证的是在交易中某一笔 UTXO 是否被发送过。如果 UTXO 被花费过那么 unspent transaction outputs 当然就不是 unspent。验证就会失败,有内鬼终止交易。

还有就是 UTXO 可以隐匿自己的交易目的,相对于 Account Model 具有一定的匿名性。

但是 UTXO 的缺点也是很致命的,就是Stateless,这使得在比特币上构建应用的开发成本极高且运行效率低下。以太坊白皮书提出比特币的 UTXO 模式的目的就是指出了比特币在脚本运行上的不足,并且突出自己解决了区块链上运行脚本的问题。

2 以太坊原理简述

2.1 以太坊好比电脑租用商

以太坊的目的是基于脚本、竞争币和链上元协议(on-chain meta-protocol)概念进行整合和提高,使得开发者能够创建任意的基于共识的、可扩展的、标准化的、特性完备的、易于开发的和协同的应用。

—以太坊白皮书

这句话翻译过来就是:以太坊集大家之所成,能够让开发者使用简易的开发语言在以太坊平台上开发应用。

这就好比,以太坊的区块链中运行着好多个等待租用的电脑,我们可以把写好的代码发布到电脑中运行。发布的过程就相当于租用以太坊上面的计算机,是需要消耗手续费,而手续费的多少取决于发布的代码执行时消耗的性能。我们租用计算机就要按需付费,而这些费用支持着“电脑”的运转,也正是矿工的挖矿所得。

例如这是我于2018年5月创建的 LORDLESS LESS Token 的 ERC20 智能合约,相当于我租用了以太坊上的一台电脑运行了我编写的 ERC20 合约代码;发布费用是...

剩余内容已隐藏

查看完整文章以阅读更多