💙 你是DApp吗？我们正在用推广方式帮助DApp吸引更多用户 点击这里联系我们
← 查看所有文章
2019-12-03

谈谈最近 EOS 提案在长期效用上的影响

本文内容感谢 Dexaran 的提供以及 EOS GO 的支持

the-impact-of-recent-eos-proposals-medium

最近关于 EOS 的更新，我想要谈谈我个人的一些看法：

  1. [重新构想EOSIO 的资源分配(https://medium.com/@bytemaster/eosio-resource-allocation-reimagined-f219e8d489c)。

  2. ONLY_BILL_FIRST_AUTHORIZER。

  3. BM 的区块链治理提案。

  4. RAM 机制。

但在我继续陈述上述提案的价值之前，我希望读者能够明白在评估 EOS 以及它发展方向的时候应该先明白一些东西。

EOS 存在的原因

EOSIO 最初为 DApp 开发平台而生。我建议阅读这篇文章，以便更好地了解 DApp 应该是什么，它来自哪里以及它们会从中获得什么好处。

我比较想要引用软件开发的定义：

可以出于多种目的开发软件，其中最常见的三种是满足特定客户/企业的特定需求（使用定制软件的情况），以满足某些潜在用户的感知需求（比如商业用户和开源软件），或供个人使用（例如，科学家可以编写软件来自动化日常任务）。

这也适用于去中心化应用程序。

去中心化应用程序出现并在加密行业中变得流行，因为与现有的开发客户端-服务器应用程序的方法相比，它们具有许多优势。显然，没有必要使用一个对替代方案没有任何优势的平台，因此 DApp 开发平台(如 EOS)会不会去用，取决于在该平台上开发的 DApp 相对于替代软件开发方法能够多出多少优势。

我们应该记住，并非 EOS 上部署的每个应用程序都是 DApp。 EarnBet 的这篇文章以及他们的 30 天通知中也对此进行了描述：

在过去的一个月中，所有去中心化应用程序都发生了一系列的中断，对于那些不太幸运的应用程序，在此期间的交易为零。没有中断的 DApp 根本就不是 dApp，而是中心化伪装为带着 Scatter 登录名的“d” App。

去中心化的应用程序必须完全在链上工作，而不受链下服务和服务器的任何干扰。否则，这种链下服务和服务器将成为该应用程序系统的故障点，并因此丧失所有去中心化的优势，从而将 EOS 应用程序变成伪装为 “d” App 的传统中心化客户端-服务器应用程序。

应当指出，EOSIO 的主要目标是运行开发的应用程序，并确保 100％ 的正常运行时间以及公众可访问性。因此，EOS 的主要用途是它能够用作已开发的去中心化应用程序的分发平台。

去中心化应用程序的优势和 EOS 的潜在效用

为了了解 EOS 智能合约的开发过程和功能，我之前开发了游戏原型并在 EOS 主网上启动了合约。我也提出了在开发过程中遇到的许多问题，您可以在此处阅读有关此内容的文章。

1. 去中心化应用程序具有抗审查性。

如果您在专用的服务器上运行应用程序，将可能会出现某方人员通过关闭服务器来侵犯应用程序的可操作性。但是，对于 EOS 智能合约而言，情况不同，没有私钥或者无权修改合约代码的任何人都无法访问该合约。这将是 EOS 的一个优势，但事实证明，如果没有链下服务器的帮助，大多数去中心化的应用程序都无法在 EOS 上运行。在这种情况下，链下帮助的服务器再次成为该系统的故障点这一事实也毁掉了“审查保留”的优势。

智能合约的抗审查性可能是 EOS 作为开发平台的优势，但是只有最简单的应用程序才具有真正的抗审查性，并且能够在 EOS 平台的帮助下独立工作而不受任何第三方干扰。

审查和中心化故障点的实例：Scatter 节点和 EOS BP 的 API节点有一半在俄罗斯被“墙”了。我不知道问题到底是出在俄罗斯政府、我的网络提供商还是说负责墙掉节点的网络提供商使用硬件的开发人员。但结果就是，节点被“墙”了，只有那些能在有 VPN 的或能更改 Scatter 后台节点的用户才能访问 DApp。幸运的是，EOS 拥有相对大量的 API 节点，并且大部分还是可以运行的。然而，同样的审查方法也可能被用于破坏任何使用中心化服务器的 DApp 的可操作性，因此 EOS 无法解决任何需要使用链下服务器运行的 DApp 的审查阻力问题。

2. EOS 作为一个分发平台。

分发已开发软件是另一个要考虑的重点。开发应用程序后，必须将其交付给终端用户（它不是“个人使用应用程序”）。

在传统的客户端-服务器应用程序系统中，开发人员必须要操心维护联机服务器并确保服务器正常运行。如果服务器必须保存一些关键数据或使用资金进行操作，则会给应用程序开发人员带来额外的开销。应用程序的开发人员必须考虑所有安全措施，以确保服务器提供商不能出于个人目的盗用资金或操纵应用程序的可操作性。

EOS 可以用作公共分发平台，需要保证 100％ 正常的运行时间，从而可以显着改善应用程序开发流程。 EOS 可以消除应用程序开发人员与服务器提供商之间信任的需要，因为 EOS 可以充当不记名的分发分类帐。

EOS 上大多数应用程序仍然依赖中心化服务器在运行这一事实，也抵消了所有这些优点。

3. 内置的获利功能。

这是目前 EOS 作为开发平台最明显的优势。

区块链和加密货币提供了一种比其他任何更简单的货币化应用程序方法。此外，2016-2017 年的大多数 ICO 筹集了比实际需要更多的资金，因此区块链行业非常适合筹款，EOS 也是如此。

4.去中心化的应用程序是不可信的神话。

这实际上是不正确的。

作为安全工程师和智能合约审核员，我可以说从始至终都需要信任：（1）在开发人员控制中心化应用程序的情况下，用户相信开发人员不会通过操纵应用程序故意侵犯用户的权益。 （2）对于去中心化的应用程序和智能合约，用户相信合约的开发者在开发过程中没有犯任何可能侵犯用户权益的错误。

智能合约无法完全解决信任问题。智能合约可以解决的唯一问题是透明度问题。在中心化应用程序的情况下，应用程序的所有者可能会侵犯某些用户的权限，但将无法证明这一点。在智能合约的情况下，每个操作在区块链中都是透明可用的，每个交易都被记录下来，并且没有办法让侵犯某用户权益的行为默默地进行。

EOS 绝对可以解决应用程序开发人员和用户的透明性问题。

资源分配模型

提案中的资源分配模型更新了假设：通过抵押 EOS 取消了拥有“按比例分配” CPU 的永久权利。

当前的资源占用和 REX 租用模型为 EOS 带来了巨大的实用性。提案中的资源分配模型更新将极大地削弱该实用程序，从而转向支持营利性的应用程序。

让我们按开发目的回到软件的主要类型：

  • 定制软件（旨在满足客户的特定需求）

  • 开源 / 商业软件（旨在满足某些潜在用户的感知需求）

  • 个人使用软件

新的资源模型将要求软件开发人员为其在 EOS 区块链上运行的应用程序付费，这极大地限制了 EOS 作为开发个人软件（例如单人游戏、连续计算节点或流程建模平台的效用。为了透明分发和公共可用性而在公共分类帐上部署的软件）或非营利软件的开发。

如果 EOS 的主要目标是用作商业用途的区块链，而不仅仅是在启动阶段就开发各种应用程序的平台，那么可以认为此步骤是适当的。但是，最近的 EarnBET 的通知强调 EOS 在用于商业应用程序时仍然遇到问题：

在为期一年的 ICO 中，EOS 称自己为“EOS：商业规模的区块链”。公司或企业将不会建立在区块链上，在该区块链上，任何时候看似无价值的资源挖矿方案都可能将一些应用程序挤出网络。

就我个人而言，由于智能合约的公开可审核性和透明性，以及软件开发人员和服务器提供商之间的信任消除，我已经看到 EOS 作为个人/定制软件开发和发布平台的各种用例。在我看来，限制这个用例将导致 EOS 作为一个平台效用的损失。

分发平台的示例：github

Github 可用于非常广泛的任务中。它的主要用途是作为一个版本控制系统，并确保团队合作以及公开表示的开源代码。Github 还用于各种各样的活动中，如组织业务流程、托管文章、托管单页应用程序和网站。可以开发一个单机游戏在 JS 和主机在 github repo，这样用户可以直接从源代码玩它(例如 github 中 clumsy bird 游戏)。

部署 ONLY_BILL_FIRST_AUTHORIZER

我强烈建议阅读 EOSIO 系统设计注意事项时，涵盖用户资源成本的文章的内容，以了解 EOS 功能的实现细节。

需要注意的最重要的一点是，应用程序有必要共同签署将由应用程序支付的交易。这不能从智能合约中完成，这需要一个私钥，它具有代表应用程序执行此操作的权限。

当前的 ONLY_BILL_FIRST_AUTHORIZER 实现存在以下问题:

  1. 它几乎不可能用于真正去中心化的应用程序，因为这些应用程序不会将部分逻辑转移到链下服务中。

  2. 它引入了一些安全问题。

在应用程序工作流程中扮演着重要角色的服务器的存在对于 DApp 来说是不可接受的

Aaron Cox 在他的文章中建议使用以下方法来使用 ONLY_BILL_FIRST_AUTHORIZER 功能:

  1. 应用程序创建，用户首先签名，然后到服务层…

第三个场景通过采用原始流程并添加第三个组件来解决前两种方法的明显问题。

这个新组件是一个“服务层”，作为终端用户不可见的后端服务在服务器上运行和保护。虽然此模型增加了基于 eosio 的应用程序整体架构设计的复杂性，但它允许在完全独立于应用程序之外的安全、非分布式环境中创建签名。

如前所述，去中心化的应用程序必须完全在链上工作，而不受任何链下服务和服务器的干扰。否则，它们就不是“去中心化的”应用程序，而是伪装成“d”App 的传统中心化客户端-服务器应用程序。

使用 ONLY_BILL_FIRST_AUTHORIZER 的安全问题

建议的使应用程序为用户资源付费的方式需要“服务层”或某些服务器来操作密钥，这些密钥将用于共同签署应用程序要为其付费的交易。

在服务器上存储私钥的要求是出于安全考虑。密钥所有者与服务器提供者之间需要信任是一个严重的问题，因为没有人可以保证服务器提供者将始终按照其应有的方式行事。有一个人为因素，并且涉及社会工程的某些非法活动的可能性可能导致影响服务器提供商的某些方访问私钥。

这可能导致私钥和资金（如果私钥具有从“d” App 帐户发送交易的权限）被盗。

我们有真实例子可以说明人为因素如何导致盗窃：Classic Ether Wallet 被黑导致了 30 万美元的盗窃。

应用程序开发人员必须：

  1. 正确设置其 DApp 帐户的权限以及将要使用的私钥。

  2. 切勿公开有权向任何第三方服务/服务器转账的私钥。

但是，在链下服务的情况下，“d”App 的用户无法验证应用程序在链下进行的操作。链下服务具有零透明度、可审核性和可验证性。对于“d” App 的用户来讲，这需要信任应用程序开发人员已经正确管理了密钥，并且在服务器提供商决定执行某些非法操作的情况下，资金也不会被盗。这也是一个安全问题。

尽管可以正确处理 ONLY_BILL_FIRST_AUTHORIZER 的实现，但仍然存在很多问题。

要使DApp能够支付用户的资源，需要做些什么

有必要实现一个功能，该功能允许智能合约确定部署合约的帐户是否希望为执行操作所需的资源付费。

有必要让应用程序能够通过智能合约的内部逻辑支付用户资源，而不需要任何第三方服务层。

区块链治理提案

我建议创建 6 个抵押池，分别为 3 个月、6 个月、12 个月、2 年、 5 年、10 年。在一个代币供应为 1B 的网络中，每个池将以每隔一分钟的形式积累到每年收 500 万个代币(假设网络以 100% 的可靠性运行)。用户可以购买该池，以获得按比例分配的池收益。用户的投票权重基于他们对每个池所有权的百分比之和。这代表了每年 3% 的通胀支付给不同的抵押池。

这是一个非常合理的建议，我相信这是朝着完善 EOS 治理体系的正确方向迈出的重要一步。

最初的EOS治理系统没有考虑到并非每个用户（或拥有EOS的帐户）都会有参与决策的意愿。 无论EOS代币的持有人对决策有多大兴趣，向所有人授予平等的投票权会导致以下事实：授予无动力参与决策的人的投票权，或有兴趣投票却缺少投票权重的人。

代币化治理系统的问题是代币的所有者必须明确表示自己愿意参与决策制定以授予其投票权。否则，无论他／她拥有多少代币，都应该没有投票权。

交易员行为就是一个很好的例子。交易者和长期投资者拥有大量的 EOS。然而，他们想要的一切都是会给他们带来巨大收益的好交易。他们对技术不感兴趣，也不知道一旦交易结束，还会有什么。他们倾向于看图表，这是他们中一些人的全职工作。他们拥有多种资产，而 EOS 只是他们投资组合的一部分。你不可能更深入地研究每一项你要在一周后出售的资产，所以这群 EOS 持有者没有机会参与决策，甚至没有意愿这样做。

因此，他们倾向于将他们的 EOS 存储在交易所，而不关心交易所如何处理这些 EOS。一些交易所有自己的 EOS BP，他们会利用客户的资金为自己投票，并在短期内赚到一些钱。事实上，他们的客户并不关心这一点，这使得交易所在理论上可以这样做。

然而，我对所述提案的细节有一些疑问。

首先，它规定所有 6 个抵押池将有相同数量的资金(500 万/年)。然而，可能出现的情况是，没有足够的激励措施来鼓励用户使用长期锁仓的池。将资金(即 EOS)锁定在将冻结资金 5 年或 10 年的资金池的风险，远远大于将 EOS 锁定 3 个月的风险。然而，分配的预算是相同的。与风险(即锁定时间)与分配预算对比例可能让人值得这么做，以便用资金来激励与相关风险抗衡。

我想引用治理提案中“预期结果”的部分:

预期的结果

交易所将无法使用用户代币进行投票，因为大多数控制权都与长期的抵押合约挂钩。

应该指出的是，这一假设不一定适用于现实的当前情况。交易所仍然可以用它们的用户资金进行投票，但它们需要保留一个单独的流动性余额部分，用于处理提现的情况。

交易所可以基于这样一个假设，即用户不会立刻要求提取所有资金。也就是说，交易所可以锁定其总余额的很大一部分(比如 50%)来投票，但仍然可以参与投票。

不太可能所有的用户都开始要求提现，耗尽一家大型交易所的全部“流动预算”。即使发生这种情况，交易所也可以用它的资金购买剩余不足的资金来处理，因为一旦“投票锁定期”结束，交易所仍然可以收回这些资金。

RAM 机制

EOS 中 RAM 的主要问题是：

  1. 一旦被第三方智能合约使用，用户将失去对其 RAM 的控制。

  2. RAM 持有人被激励参与决策，但与 EOS 持有人不同，他们没有投票权 / 权利。

  3. RAM 投机。

RAM 的管理问题

在 EOS 中，合约可以(1)为用户数据付费，或者(2)要求用户为合约使用的数据分配 RAM。例如，代币合约可能要求用户分配一些 RAM 来存储余额变量。

另一方面，一旦用户确认他正在为合约分配 RAM，那么他就不再控制“他的”RAM。

尽管 RAM 是属于用户的，但只有合约才能释放它。用户必须相信合约开发人员已经实现了清除 RAM 的功能。不负责任的开发人员或恶意的人可以实现一个合约，这样它将消耗 RAM，而用户没有任何可能可以恢复它。

我们应该考虑到最近 RUTM 的炒作。合约开发人员可以实现它，这样用户在合约使用 RAM 时就无法清除内存。也有可能通过实现一个将消耗大量用户 RAM 的合约来危害整个生态系统，然后破坏这个合约，使它不再返回 RAM。在这种情况下，一个有恶意的人可以从 EOS 生态系统的总 RAM 供应中永久地减去他的合约消耗的RAM数量。

RAM 和 EOS 治理

当我们谈论管理系统时，我们常常忽略了一件重要的事情——那些持有 RAM 的人目前没有投票权，但他们同时也是那些被激励做出决策以提高 EOS 效用的参与者。大内存持有者大多是 DApp 和使用 EOS 作为开发平台的用户。与许多期望从 EOS 价格变动中获得经济收益的 EOS 持有者相比，这些投资者更有动力去改善 EOS 生态系统。

尽管在《帕累托原则下放权力》一文中也对此进行了强调。这是非常重要的事情，为了确保公平的投票分配，我们必须解决这个问题。

对 RAM 的投机

RAM 的价格由 EOS 市场决定。然而，加密市场容易出现投机和抛售行为，RAM 也不例外。但是我们都知道，RAM 的投机抛售并不适合 EOS 生态系统，因为它可能会影响平台的效用，并且会不自然地增加 dapp 的成本。

购买 RAM 需要支付 0.5％ 的费用，但这不足以阻止投机行为，正如已经在现实中上演的那样。

最近的 RUTM 事件使我能够在 25 分钟后执行演示性的买入和卖出，并获得 2％ 的利润（这足以使短线交易者参与进来）。 RUTM RAM 的暴涨让价格变得咄咄逼人，价格呈现的绝对不是自然需求。

RAM Price

如果目标是更难推测 RAM 定价，那么 0.5％ 的费用并不足可以实现此目标。

要了解下周所有关于 EOSIO 的新闻，请不要忘记加入到我们的电报频道，在 Twitter 上关注我们并将我们的网站添加到浏览器的书签中吧！

EOS GO 由 EOS ASIA 资助，由每一个您提供支持。通过在您的名字上加上 eos go 并加入 EOS GO 电报组来为整个进程贡献力量吧！