您可能从未了解过 EOS 的潜在优势：它不像以太坊那样会消耗用户资金
本文内容感谢 Dexaran and 的提供以及EOS GO的支持
一些被严重低估的 EOS 主要的优势：
1.沟通模式。安全的生态系统。不会发生代币丢失和资金消耗的情况。
2.链上地址的分配和记录。不再发生跨链冲突以及将代币发送到不存在的地址的情况。
3.可升级的合约。不再有无法解决的黑客入侵智能合约的事情，在以太坊上就有例如 TheDAO 和 Parity Multisig 的黑客事故。
一些看起来很明显，但是 99％ 的加密社区成员不了解的优势
我观察了 Daniel Larimer 对 EOS 与 ETH 的比较。他强调了缺少针对 ETH 2.0 的迁移计划，EOS 的可扩展性以及其他一些方面相比之下有优势。但是，似乎大多数用户和开发人员在实践中都不了解 EOS 设计和结构的优势。
如果您问自己，EOS 比以太坊有什么优势，您首先会想到什么？可扩展性、性能、人性化的地址、免费交易、博彩 Dapp、可升级合约，还是为将来设置交易的能力？
当然，以上提及的这些都很重要，但要是我们可以去了解更多关于以太坊为什么永远不会被广泛采用的原因，这对我们理解 EOS 的优势来说也是很重要的。
请让我透露一些事实：以太坊正在消耗其用户的资金。在本文我不是谈论交易费、交易劣势或类似的事情。我在这里谈论的是不安全标准在其中的广泛采用以及以太坊开发人员的心态。
如果用户在使用您的项目时丢失了资金，那真的很糟糕。
这是世界总财富与加密货币的比较。加密货币行业还很年轻，当然了离完美还有很长的距离，这是公认的。它仍处于活跃的开发阶段，并且发展飞快。
我们所有人都在想象当加密货币被广泛采用时世界将发生怎样的变化，但是请认清以下目前的形势，大公司或保守的企业都不会使用会意外消耗其资金的平台。去中心化是好事，区块链是好事，炒作是好事，容易筹资是好事，但要是这里要是会有一个一不小心就会没掉资金的风险，那么前面所述的所有“好事”都失去了吸引力。
一般情况下，公司不希望用户因为任何原因而损失资金，即使是“用户错误”或其他原因。
政府不希望公民损失其资金。财务结构、部门和组织的首要目标是确保公民不能使用会轻易失去财产的系统。
在我们的行业中，许多人忘记了此类系统的用途。许多人指责用户没有负起属于自己的责任，但是从另一种角度来看，这是设计的缺陷。加密行业的一种规范是，用户可以将比特币发送到错误的地址，并可能由于这样的一个错误而失去全部毕生积蓄。在这个新的世界里，用户只要稍加不注意，就会丢失私钥并丢失资产，这是常见的。
开发人员倾向于通过说“不是系统的错误，而是用户的错误”来指责受害者。
那么请让我提醒您：我们在这里使用资金。我们内心是要求这里也能拥有像金融系统那样健全的模式的。我绝对相信，必须认真对待，并且必须为客户提供“安全的”解决方案是我们应该要承担的责任 。
如果您只是一个用户，以太坊将如何消耗您的资金
默认情况下，ERC20 代币不安全。而且是全部不安全。
ERC20 代币标准缺少事件发出/处理机制。它在这里和这里描述为什么不安全的原因。
应当注意，事件处理是开发人员在编程中的标准做法。这就是 EOS 中提到的通信模型。
缺少事件处理会导致严重的问题。这对于社交媒体应用程序或计算机游戏可能是一件好事。比如您喜欢其他人的帖子但是并不能表达（count）您的喜欢，结果可能只是您不太常打开这个软件。
但是，就 ERC20 代币而言，这是一个很严重的问题，已经导致数百万美元的损失。 并且“损失”的资金每天都在增长。截至 2017 年 12 月 27 日，在 7 份 ERC20 代币合约中损失了 3,200,000 美元（请前往 EIP-223 查看讨论以获取出处）。目前，以太坊生态系统共有数十个甚至数百个 ERC20 代币，因此我们这里提到的只是全部问题的一小部分。
这不是以太坊作为软件的问题，因为 Geth 或 Parity 都没有在其默认部署中强制使用 ERC20 代币。这是以太坊作为项目的问题，因为用户在使用过程中不断损失资金。
ERC20：问题
缺乏事件处理会导致合约无法响应代币转帐。主要会导致两个问题：（1）那些不打算与代币一起使用的合约不能拒绝转入的代币；（2）那些要与代币一起使用的合约不能在用户选择了错误功 能的情况下，再进行注册代币和执行转移的操作。
在第一种情况下，整个以太坊生态系统的合约成为潜在的“代币陷阱”，如果未实施特殊的紧急提现功能，就会出现只能接收代币但无法将其发送回去的情况。
在第二种情况下，必须接收代币的 DApp 或其他合约无法将其记入发送代币的用户。
奇怪的是，这不适用于以太币。如果您尝试将以太币发送到不打算与以太币一起使用的合约，那么转账将被后备功能抓取，并且交易将被还原。
有人会说这不是安全问题，而是用户错误。这是不正确的，因为这绝对是代币标准的设计缺陷。要是我们总是想要依赖于没有人会犯错误的假设中，那这种模型就不适用于金融解决方案和大规模采用平台。
我已经提出了一种解决方案，ERC223 代币标准。还有其他一些解决方案，但是采用 ERC20 代币的方法很多。例如 Vitalik Butern 就有对关于此问题的评论。
后果
这导致许多以太坊代币持有人遭受严重损失。代币丢失的数量每天都在增加，用户现在仍在丢失他们的资金，但是没有人在乎，也没有人可以拿到这些资金，因为在以太坊上合约不可升级。
ERC20 代币标准成为以太坊最广泛采用和支持的标准。这意味着如果说要是您的代币是 ERC20 的，说服交易所上线您的代币不是太难，但是如果您为代币使用不同的替代标准，则很难在交易所被上线。我们看到的结果是， 大多数 ICO 开发人员继续使用 ERC20 标准，因为它更容易快速筹集资金。大规模采用的力量是巨大的，交易所的规则在这个情况中扮演着重要角色。
许多开发人员一直在使用 ERC20 标准，他们知道这将给用户带来经济损失。在这里引用 STORJ 联合创始人的回应：“我们决定在经过多次测试的代码中犯错误”
对于许多项目而言，事实证明，它们在启动后使用了错误的代币标准。他们本可以解决问题，但是合约（和代币）在以太坊上是不可变的，因此无法实施修补程序。他们中的大多数决定保留当前的部署方式。这可以通过可升级的合约解决。可升级合约对于生态系统的安全起着至关重要的作用。
示例：在 BNB 智能合约中损失了 436,000 美元
这是 BNB ERC20 代币智能合约 的内容。
该合约中在 2009 年 10 月 22 日拥有 23,458 个代币。可以看出，用户将代币意外地转移到了合约中。该合约无意持有代币，也不能使用其持有的代币进行操作，如无法从合约中提取代币。这些代币只是丢失了，因为由于缺少 ERC20 标准中的事件处理机制，合约无法拒绝它们。
BNB 只是问题的一小部分。还有更多的 ERC20 代币被“卡在”合约中。截至目前已经损失了数百万美元。
这是另一个在记录的案例，说明用户如何将代币发送到合约并由于标准中描述的缺陷而丢失了代币：由于缺少 ERC20 中的事件处理，用户损失了 130,000 美元。
我们应当注意，这是一个非常常见的用户错误，但是用户没有任何理由将代币存入代币合约。而当我们考虑去中心交易所合约时，情况将会发生变化。将您的资金存入交易所是加密行业的标准做法。当所有交易者希望将资金记入在其余额中时，将其资金存入交易所生成的给定地址。
在交易所将代币记入“转账人地址”是一个好主意，但使用 ERC20 进行这个操作是不可能的。这意味着所有 ERC20 代币交换都是巨大的代币陷阱，当用户选择了错误的功能时，它们将无法记入存款的数据中。
在以太坊上建立完全去中心化的 ERC20 代币交换绝对是不可能的。交易所必须具有代币提现功能，这将使所有者能够提取“卡死”的代币。否则，该交易所将无法安全使用。
链上地址分配
在以太坊中，地址是从私钥派生的。这是一个简单的示例，它将说明您可以从 64 个符号的任何序列中得出“以太坊地址”：密钥生成器。
这种方法很简单，它允许免费创建地址。但是，有两个重要问题我们需要面对：
-
不属于任何人的地址仍然有效
-
跨链碰撞
发送到错误的地址
在大多数协议（如比特币，以太坊和许多其他协议）中，用户将其资金发送到“有效”但不受任何人控制的地址的能力被视为一种规范。但是，如果从另一个角度看待这个问题的话，我们将会最终得到这样一个结论：这不是大众采用的金融体系会去运作的形式。
生成 EOS 地址的不便是一个问题，但是要解决更大的问题，必须付出合理的代价。付费地址的问题是可以解决的。例如，某方可以建立一定数量的资金来为用户生成地址。这就是 Wombat 钱包现在正在做的事情。
从非拥有地址收回资金的问题，到识别哪些地址是拥有和哪些不拥有但“从密码学角度来看有效”的问题，在区块链的历史中还是没有找到解决办法。
跨链冲突
以太坊地址的推导方法假设一个私钥对不同链（也就是分叉链或姐妹链）上的相同地址有效。在一个链中有效的一个地址对于所有依赖类似地址生成方案的替代链也有效。
这对于以太坊和以太坊 CLassic 特别重要，该问题主要影响合约。如上所述，合约旨在处理进来的交易，拒绝不正确的交易。例如，如果用户将 ETH 发送给没有计划接收付款的合约时，此合约将拒绝该交易，转账也不会发生。
但是，如果用户尝试将其资金发送到某些备用链上的相同地址，转账则会发生，因为备用链上该地址没有合约。例：
-
合约已部署在 ETH 链上
-
每当用户向合约发送 ETH 时，交易都会被拒绝
-
每当用户将 ETC、UBQ、EXP、CLO、MUSICOIN 或其他分叉币发送到合约地址时，该用户就会永久失去这笔转账的资金
-
奖励：每当用户在任何链上向合约中发送 ERC20 代币时，他也将永久丢失其代币
尽管它看起来像一个愚蠢的理论问题，但这是一个必须解决的实际问题。这里有一个真实的例子：ETC 链上的 GNT 合约损失了 58,000 美元。
有一个解决方案：同开发人员必须将虚拟合约部署到任何分叉链上。该合约还必须包含 ERC20 提现功能。实际上，这不太可能发生，并且由于跨链冲突，用户将继续亏损。如 GNT 示例所示，即使开发人员想要 解决问题，他们也可能无法解决。
显而易见的是，这种地址生成方法不适用于任何考虑了区块链间可操作性的系统。
EOS 声明其设计时考虑了互操作性，并且 EOS 的体系结构解决了与此相关的一些重要问题。
可升级合约：您能想到的最合理的事情
可升级性对于安全性至关重要。
编写无错误的代码是不可能的。最好的开发人员专注于编写可靠且可维护的代码，但是任何说一段代码没有错误的人都没有经过认真研究。
SpaceX 经历了其软件 Mariner-1 中的错误，该软件因软件错误而崩溃，成本为1850万美元，Solidity 编程语言的创建者 Gavin Wood开发了 Parity Multisig 智能合约，使其遭到了两次黑客入侵，这是另一个例子的一个错误，最终花了10年时间才修复。
即使是最有能力的开发人员有时也会犯错误。即使是最有能力的审计师有时也发现不了错误。作为软件安全审核员，我可以说不可能保证软件没有错误。更好的方法是设计软件以使其具有容错能力，并最大程度地减少错误（如果可能发生）的后果。
正式验证、更好的编程语言、自动异常检测系统、自动测试或安全审核这些都无法确保该软件不会出错。
程序不需要变化是一个遥不可及的神话。有些软件在启动多年之后，可能才会发现 一个错误。这是一个主要的安全缺陷，使不可变的系统无法使用。这不适用于万一出错，后果就会极其可怕的金融系统。
McAfeeDEX 安全审计显示，以太坊不适合开发人员构建去中心化 p2p 交易所的需求
我最近参加了 McAfeeDEX 的安全审计。 DEX 是旨在在以太坊上构建的 Dapp。您可以在此处找到审计报告。
有很多以太坊问题会影响已审计的 DEX：
-
最大的问题是 ERC20 缺少事件处理。
-
跨链冲突也是一个问题。
-
无法终止或升级合约对于这种交易已经是一个问题。
McAfeeDEX 基于 EtherDelta 代码。我可以得出结论，EtherDelta 和 所有以太坊代币交易所都容易出现此问题。
有人可能会争辩说，这不是这种交易所或以太坊的问题，而是事实是，如果用户使用这种交易所，他们将失去资金，而如果使用 EOS 交易所，他们将不会失去资金，所以我别无选择。而不是建议使用 EOS。
如果开发人员改为在 EOS 上构建软件，则开发人员将自动消除所有这些问题。
从刚开始的那一天起，我就是一个以太坊合约的开发者和审计师，我从内部了解它。对我来说很明显，以太坊是不可行的，而且很久以前我就已经明确指出过。
结论
EOS 具有许多根本上重要的协议功能，例如（1）通信模型和安全代币标准，（2）链上地址分配，（3）合约的可升级性。对单纯的用户来说，这些似乎是“小遮瑕优势”，但实际上它要复杂得 多。
列举的每一个功能都解决了一项重要的问题，否则可能导致灾难性后果。对于旨在尽可能容错的大规模采用的财务系统来说，以上提及的功能都是绝对且必要的。
不幸的是，以太坊和许多其他类似以太坊的协议缺乏此功能。这使它们不适用于各种用例。
免责声明：以上作者表达的观点不一定代表 EOS GO 的观点。 EOS GO 是一个社区，在这里 EOS GO 博客是一个供作者表达不同想法和观点的平台。当前存在的任何引荐链接均由作者直接放置，EOS Go 不会从中获取任何利益。要了解有关 EOS GO 和 EOS 的更多信息，请加入我们的社交媒体。
EOS GO 由 EOS ASIA 资助，由每一个您提供支持。通过在您的名字上加上 eos go 并加入 EOS GO 电报组来为整个进程贡献力量吧！