AICon上海|与字节、阿里、腾讯等企业共同探索Agent 时代的落地应用 了解详情
写点什么

为什么在以太坊上构建项目注定会失败

  • 2018-10-05
  • 本文字数:4587 字

    阅读完需:约 15 分钟

很多人问我,为什么我们在 Stellar 协议上构建我们的 Token(代币)项目,而我的回答很简单。如果,我们在 ERC-20 标准(以太坊)上构建我们的项目,那么它就会失败。事实上,我认为,几乎所有由以太坊区块链支持的项目都会失败,原因如下。

那是 2017 年 6 月,我和联合创始人 Will 在讨论用 Blockchain 还是 DLT(Distributed Ledger Technology,简称 DLT,分布式账本技术),来解决在零售品牌空间的忠诚度这个大问题。答案是显而易见的,我们可以扩展我们现有的 online-to-offline(简称 O2O,线上对线下)平台以获取忠诚度,并利用分布式账本技术完成了很多工作。

我们接下来的任务是评估现有的区块链,看看哪个是我们可以用来构建项目或解决方案的。显而易见的选择是以太坊,因为当时很多项目在广泛地使用它,围绕着它有很多炒作,因为他们有支持智能合约的 ERC-20 标准。最终,我们决定采用 Stellar 协议,并且我们为此感到高兴,下面是整个过程的总结以及我们如何达到今天的成就。

当时,以太坊对于 Blockchain 世界来说仍然是新鲜事物,它基本上是一个分布式编程平台(用于自治组织和无主应用软件的脚本软件)。Vitalik Buterin(以太坊的联合创始人)他自己也说:

“以太坊是个模块化、具有状态、图灵完备的合约脚本编写系统……我们的目标是为去中心化的应用程序提供平台。”

现在,如果您打算构建一个真正的去中心化项目,其不具有中央决策制定功能,那么以太坊是个很好的选择。但是,大多数区块链公司不需要智能合约来执行他们的核心业务逻辑或希望规避法律或管辖权问题。他们只想发行数字资产和处理交易。这正是以太坊让您失望的地方。

如果您在构建一个项目,要发行代币同时需要快速又低成本地进行交易,那么,以太坊总是会失败的。我们的项目涉及发行代币,这些代币在交易近乎于实时发生的零售环境中使用,这是个问题。

通过所有从用户体验开始的技术项目,并从那里开始工作,如果使用以太坊区块链,那么从一开始,我们就会有大麻烦。为了确认这个问题,我们观察了今年(2018 年)4 月到 5 月间进行的测试。所有的结果和方法都可以在 GitHub 上找到。

第一个问题:您最热心的用户将会有最糟糕的体验。

以太坊按每个账户排队交易,而矿工不会按等待时间对交易进行优先排序。事实上,鉴于交易拥有相等的 gas 价格,矿工随机分配它们。因此,一个活跃账户构建了一个交易队列,而以太坊没有解决它的机制。对高容量的账户,结果就是不断增加的交易滞后。

以太坊用两个数字处理交易,一个是交易随机数(我们称之为“nonce”)和一个账户随机数,为了清楚起见,我们有时称之为“计数(count)”。交易随机数按顺序排列账户交易;账户随机数在它们中的任意一个被挖出时进行计数。当提交一个带着其 nonce 的新交易时,以太坊把这个 nonce 与当前的计数值进行比较,以决定该做什么。如果该交易的 nonce 的值比计数值低,则该交易被忽略。如果 nonce 值更高些,那么交易延迟。只有 nonce 值匹配计数值时,该交易才被移入区块中。下图是其工作原理的简化示意图:

这实际上与您在速食店或像 DMW 这样的政府办公室看到的“取号”系统类似,同时,这也是防止重放攻击的相当普遍的做法。

很多其他的区块链也在做类似的事。但是,以太坊的交易到区块(transaction-to-block)算法(或者,真的,没有这个)给在您的 DMV 窗口中工作的人们出了一条妙计,也即,这些矿工没有必要对队列中的下一个数字负责。正如您在下图中所见的,以太坊挖矿是由少数精选采矿池控制的,四个最大的矿工占有 70% 的以太坊哈希率。

矿工通常对将要接受的交易有自己的标准。很多矿工只接受具有高 gas 价格(high-gas-price)的交易。有些只接受自己的交易。像这样的矿工在从您的队列中取得某些东西之前让区块空间不被使用。因此,现在想象一下一个 DMW,其中的某些窗口在告诉人们“抱歉,我无法帮忙”,而每秒有更多的人进入等候空间,并且,甚至在您可以和某人交谈之前,所有需要帮助的人们都在您的面前。瞧,您对以太坊如何处理交易就有了一些了解。

我们不曾料到它是这样工作的,直到我们尝试实施 Kik 的负载规范:480 个账户,平均每个提交 1 txn/ 分钟,持续 3 小时。总共是 86400 个交易,平均每秒 8 个。

我们利用 ETH 的 gas 加气站的标准对 gas 进行了测试,预计确认时间的中位数大约是 30 秒,但是,13 个小时之后,一半以上的交易没有进入区块。我们在 13 小时 50 分钟时停止了测试,50.1% 的交易丢失了。(注意:如果您希望查看我们的工作,可以在我们的 GitHub 中找到原始数据。)我们认为,我们已经搞砸了,但是,事情不是这样的。我们刚创建了很多长队列,一些傻子一样的交易已经在那里无所事事地等了一天。

当您读到有关“以太坊交易时间”的内容时,公布的数字几乎总是单一的、一次性事务。它们不属于应用程序级别的环境。我们再次进行了 Kik 测试,以真正确保我们所做的一切都正确,又用了 6.9 个以太币,但是,我们得到了几乎一样的结果。

这是从这次试验中获得的典型经验,这只是刚好首先是字母数字的账户。您可以看到等待时间随着交易的积压而增加。

在摘要中讨论“结算时间”是一回事。但是,从实际的用户体验角度考虑一下上述数据。您的以太坊应用软件被用得越多,它就越慢。仅仅过了 3 小时,其交易就要花 8 个小时来确认。

当然,Kik 的测试规范表明,我们应该提交 3 小时的交易,然后停下来,这就是我们所做的。在现实中,您无法建立停机时间以让计数赶上来,因此,理论上,交易队列只是变得越来越糟糕。当然,在实践中,随着您的以太坊应用程序变得没响应,用户们就会离开,这有助于它赶上来。

这是来自第二个测试的性能分布。我去掉了最慢的 5%,这样,长尾效应不会影响整个画面。

作为对比,这是 Kik(在 Stellar 上)运行同样规范的测量值

我只是从他们的博文中抓取了这张图,但是我没有原始数据,因此,我无法在同一张图中显示我的数据。但是,利用计算机的“魔力”,我至少能叠加这条曲线。

一切看起来都是可比的,直到您注意到 x 轴。我们在以太坊上测到的等待时间要长 3000 倍。简而言之,就是个排队问题。

这个性能问题目前是以太坊的基本组成部分。像分片或 Casper 在理论上是可行的,但是,这些将是复杂的修复,分层叠加在以太坊几乎最大的复杂性上。像闪电网络(lightning)这样的可以依靠比特币固有的简单性,而没有什么基本回落。摩天大楼通常是建在岩床之上,而不是建在另一座摩天大楼之上,但是,这是很多以太坊扩展解决方案所要做的事情。

唯一可靠的性能改进是在 gas 上花费更多,希望每个账户队列可以更快通过。事实上,我们在那 3 个小时试验中这么做了,我们之所以这么做,是因为“我们应该尽力做我们能做的来使之工作”的承诺。

之前的两个测试使用了“标准”以太坊 Gas Station 的推荐。第三次测试我们使用了“快速”等级(当时约为 4 Gwei),在我们的 480 个账户上花了 11.8 个以太币。

性能提升了(只是 Kik 在 Stellar 上的速度的 5 百分之一),但是,还是不够快。形成积压,并且支付进程在那里无所事事。

第 2 个问题:广泛采用的成本极其高昂

对高级用户也是这样。但是,以太坊也不适合另一种形式的采用,您也许看到像 Etsy 的应用程序,我不知道,不是一些人更深入,而是有很多人时不时地登入。这是因为以太坊应用软件的每个用户成本随着用户数量的增加而飞速提高,并且,这是为什么当有人尝试进行多用户登录使用以太坊,您就看到价格会飙升 70 倍之多

我们在寻找排队问题的解决方法时,不经意间捕捉到了这个数据。为了防止交易堆积,我们重构了 Kik 的规范如下:不是少数账户提交大量交易,而是让一大堆账户(28800 个)的每一个只进行一个交易。为了坚持最初测试的指导方针(总共 8 个 txn/x),我们在一个小时内提交了这些交易。

奇怪的是,这实际对性能没有多大帮助。确认时间的中位数是 23 分钟,事实上比上面的“快速”测试还要慢。更奇怪的是,我们提交的这第一批交易的其中一些是最后被确认的:

我们知道账户队列不应该是问题。事实证明,我们的交易刚一上线,矿工们的费用就飙升。因此,我们最早按测试之前的“标准”价格提交的交易很快就付不起费用了。它们在低优先级上徘徊了好几个小时。

我们发现了以太坊的另一个负强化循环。添加用户马上就会涨价。在现实中,单位数的增加会降低单位价格。基本上,整个私营部门是建立在“规模经济”这个理念之上。但是在这里:每个增量用户马上提高了每个用户的成本。这像是怪异的经济学。

您可以看到,在我们进行测试的那短短一个小时中,价格爬升了约有 6 倍之多。

同样,内置的测试时间限制让一切看起来比实际更可持续。将该图外推,把指针放在中间某处。持续两周稳定使用后,单位用户成本看上去会是多少?如果是两年呢?

上述测试每小时的成本是 1445 美元。当 gas 的价格较低时,标准速度大约是 1Gwei,并且它每秒只能处理 8 个交易。要进行基本测试,那么一年的成本是 1260 万美元。

如果在实际业务上应用这个成本结构,那么可以看到,以太坊的费用已经是不可持续的高。例如,Paypal 每秒大约处理 240 个交易。抛开为了能实现这个目标要进行的性能修复,并将我刚才提到的动态提升的价格放一边。如果 PayPal 构建于以太坊上并支付我们观察到的价格,那么去年他们将在网络上花费 3 亿 8 千万美元。那将是他们 21% 的净收入,而且,那是在假设可以维持价格不变的情况下。

以太坊的理想版本不适合这个世界上最有利润的交易业务。那么实际版本又如何为我们工作呢?

现在怎么办?

Vitalik Buterin 说过:

“如果你想在不能扩展的以太坊上构建去中心化的 Uber 和 Lyft,那是会搞砸的。不可以。”

我建议您看看所引用的这句话的整体情况,它表明,以太坊团队的 4 个最重要的成员说了我在这里已经说过的话。当今天高利润的 ICO 变成明天的警示故事时,对于处于该生态系统中的每个人都没好处,大家都知道这一点。

毫无疑问,以太坊社区是区块链中最强大的,没有 Vitalik 的愿景,很有可能就完全没有代币经济。这不是以太坊的错,开发人员在问技术人员从来没有交付的东西。是人们在追逐去年的 ICO 热钱,不管什么是正确的工具。

以太坊的问题始于误入歧途的企业家。不要成为他们中的另一个。

如果您在构建交易应用程序,该协议将不支持您的用户所期望的行为。我对以太坊的雄心壮志和复杂性怀有深深的敬意,但是,我把它看作区块链的高级时装。美丽、错综复杂、高大上的概念、高尚。但是,不应该是您拿来用的。

如果您想要无信任、分布式的计算(如果这真是您要构建的),那么绝对要用它。如果您从未打算实际发布什么东西,那么用以太坊就太对了,另外,如果您能找得到他们的话,问问那些 50% 多的 ICO 项目,他们卖掉代币后就消失得无影无踪 。他们已经击中了费米悖论中的大过滤器(Great Filter)。像是波多黎各的荧光海滩,就亮了那么一下。

但是,如果您想建立一个像我们一样的业务:如果您计划一个典型的用户到用户的服务,不需要把您的业务逻辑绑定在智能合约上;如果您计划发行数字资产,以及高容量的交易是您战略的核心部分的话,那么选一个为之优化的平台。像我们所做的,在 Stellar 上进行构建。

阅读英文原文: Why Building Projects on Ethereum are Destined to Fail.

感谢杜小芳对本文的策划和审校。

2018-10-05 18:252390
用户头像

发布了 199 篇内容, 共 88.2 次阅读, 收获喜欢 295 次。

关注

评论

发布
暂无评论
发现更多内容

kubernetes灰度发布

CTO技术共享

开源 签约计划第三季 8月月更

Kubernetes 运维经验分享

CTO技术共享

开源 签约计划第三季 8月月更

Spring(一、快速入门)

开源 Spring5 8月月更

Kubernetes 原生接口

CTO技术共享

开源 签约计划第三季 8月月更

Centos7安装系统安装docker

Geek_8d9022

2022秋招前端面试题(二)(附答案)

helloworld1024fd

前端面试

Kubernetes 虚拟机部署弊端

CTO技术共享

开源 签约计划第三季 8月月更

Kubernetes 部署策略

CTO技术共享

开源 签约计划第三季 8月月更

数字化转型怎么就那么的难?!

BizFree

数字化转型 工业互联网 智能制造

Kubernetes 怎么优雅升级

CTO技术共享

开源 签约计划第三季 8月月更

STM32的启动过程 — startup_xxxx.s文件解析(MDK和GCC双环境)

矜辰所致

stm32 arm 8月月更 stm32启动流程 startup_xxxx.s

kubernetes 常见架构图

CTO技术共享

开源 签约计划第三季 8月月更

kubernetes日常命令

CTO技术共享

开源 签约计划第三季 8月月更

架构实战营模块九作业

融冰

Kubernetes微服务、容器介绍

CTO技术共享

开源 签约计划第三季 8月月更

2022秋招前端面试题(一)(附答案)

helloworld1024fd

前端面试

Spring Cloud 入门 -- 搭建Eureka注册中心 实现服务者与消费者的服务调用

Bug终结者

Java 云原生 8月月更

Kubernetes微服务框架

CTO技术共享

开源 签约计划第三季 8月月更

Kubernetes 架构知识

CTO技术共享

开源 签约计划第三季 8月月更

ES6新特性——generator

猫猫巧克力

8月月更

Go-Excelize API源码阅读(二)——OpenFile()

Regan Yue

Go 开源 源码刨析 源码解读 8月月更

Kubernetes 污点和容忍

CTO技术共享

开源 签约计划第三季 8月月更

GItHub又火了!2022最全 Java面试手册终于开源了,包含了29个知识点

Java工程师

Java 面试

Kubernetes 集群故障案例

CTO技术共享

开源 签约计划第三季 8月月更

架构实战营毕业总结

融冰

Kubernetes DevOps 工具

CTO技术共享

开源 签约计划第三季 8月月更

纯色山鹪莺

猫猫巧克力

Kubernetes 开源未来

CTO技术共享

开源 签约计划第三季 8月月更

【LeetCode】 数组中的字符串匹配Java题解

Albert

LeetCode 8月月更

阿里大神级 最新Elasticsearch 笔记,抓紧学起来!

冉然学Java

elasticsearch 编程 分布式 java; 程序员、

IPv6地址规划

穿过生命散发芬芳

ipv6 8月月更

为什么在以太坊上构建项目注定会失败_语言 & 开发_Cameron Wall_InfoQ精选文章