EOS资源解决方案越来越依靠项目方，而不是终端用户

Greymass 今日发推宣布推出 Greymass Fuel，旨在给应用程序（dapp）提供“为终端用户承担资源成本（CPU/NET）的一站式解决方案”。它集成现有的 EOSIO 应用程序，允许 EOSIO 生态系统的应用程序开发人员开发和使用。

由于 Greymass API 基础结构可以处理整个过程，同时仍支持所有的常规 EOSIO 功能。因此开发人员无需安装其他服务器/基础架构即可运行，能够使用 Fuel 来支付用户的资源成本。

自从 EOSIO V1.8 版本上线以来，EOS 资源问题的解决方案也越来越多了，不但许多 EOS 项目方在努力，而且一些 EOS 钱包也在努力，如 MEET ONE 推出的流畅模式，和 TP 推出的顺畅模式，都是在探索 EOS 资源问题的解决方案。

从一个终端用户的角度来看，EOS 技术的使用门槛不是一般的高，创建一个 EOS 账号要付费，有了账号后，无论是账号间的转账，还是给 EOS 节点投票参与社区治理，都是需要消耗一定的资源的，而且资源还不是一种，分别有CPU算力资源、NET 网络资源以及 RAM 存储资源，每种资源的用途以及获得的途径还不相同，例如 CPU/NET 是通过抵押 EOS 来获得，RAM 是通过向系统购买来获得。如果资源不够了，可以再买 EOS 通过抵押获得资源，或者到租赁市场去租赁，这些都需要专门的学习。

EOS的使用门槛，对原有的圈内用户来说是很高的门槛，对于一个刚刚接触区块链的人来说门槛更高，可能会因为太复杂而直接放弃，一上来就要学习这么多知识点，确实是有不小的难度的。

EOS 的账户体系设计的这么复杂，有好处也有弊端，复杂从某种程度上来说也意味着灵活，例如 EOS 账号，它的权限除了默认的 Owner、Active 权限之外，还可以根据自己的需要进行自定义权限，例如可以专门增加一个自定义权限，该权限只能投票，这样设置后，掌握专门投票自定义权限私钥的人只能投票，不能做其他操作，例如不能把账号中的 EOS 转走，从而保证了 EOS 账号的安全。

除了自定义权限，EOS 账号还实现了多签管理，对于同一个 EOS 账号来说，可以把密钥分配给不同的人管理，然后可以设置一个权限阀值，便于实现分级管理，例如一个项目方的 EOS 账号，老板可以和经理共同管理，任何一个领导不能单独对账号中的 EOS 资产进行转账等操作，从而保障了 EOS 账号的安全。

无论是自定义权限，还是多签功能，EOS 灵活的账号体系设计，可以实现更高级别的安全管理，但是，这对于普通用户来说，也是极高的门槛，一个普通的 EOS 用户，其实使用这些复杂操作的机会并不多，普通用户使用最多的就是转账了。

这些灵活的账户体系设计，是不是很适合 B 端项目方？也不应该把这些复杂的操作直接展现终端用户，展现给用户面前的界面应该是非常简洁的，也非常容易理解的，这当然需要 B 端项目方的努力了。

其实，项目方也在朝减化 EOS 操作、降低 EOS 使用门槛的方向努力，我们看看 MYKEY 所做的努力就可以感受到，例如在 MYKEY 中用户根本不需要去了解什么是 CPU、NET，也不用去抵押、赎回，展现给终端用户的是网络费用这个我们熟悉的概念，在 EOS 上执行操作时，是需要网络费用的，没有网络费用怎么办？往里边充就是了，这要比 EOS 上那些复杂的专业名词容易理解多了。

除了 MYKEY，MEET ONE 也在资源方面做出了探索，例如最近推出的流畅模式，把 CPU、NET 这些概念全部都打包了，取而代之的是资源包，用户开启流畅模式后，哪还需要知道是什么 CPU、什么是 NET 呢，买点资源包就可以操作 EOS 账号了，这比抵押、赎回要简单多了。 TP 的顺畅模式原理一样。

除了 EOS 钱包方，目前许多 EOS DAPP 也开始尝试资源代付模式，用户在玩 DAPP 时的资源费用由项目方来承担，用户不用担心资源不足了。

EOS 资源解决方案越来越依靠项目方，而不是终端用户，其实站在用户的角度来看，开一个账号要付费，然后使用账号时资源还要付费，这对于许多已经习惯了互联网产品的用户来看是很难接受的，一个很明显的趋势是用户将免费顺畅的使用 EOS 账号，而复杂的 EOS 资源体系，以及资源费用将会由 EOS 项目方来承担。

—-

编译者/作者：子衿Q

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。