管理 EOSIO 资源

EOSIO 链在资源管理方面的不足通过最近各条链上出现的一些事件露出了全貌。简而言之,就是 REX(资源交易所)质押池中可购得的 CPU 资源价格十分低廉,以致于人们使用成本过低,可能会出现过度使用 EOSIO 网络资源的情况。这样的过度使用可能会洗劫一空已质押的 REX 资源,造成系统关闭,不再支持使用。从 EOSPlay 被盗 30,000 个 EOS EIDOS 事件开始,数周来,这样的情况就一直在 EOS 主网上发酵。除偷窃与拥堵外,可能还会出现利用此情况的其他形式的攻击。为了能够更好地使用 EOSIO 网络,我们必须解决这个问题。

Telos 也受到了这次风波的一定影响。我们躲过了菠菜游戏,因为运行在 Telos 上的菠菜项目很少,存在数量受限,基本无法形成这样的攻击。我们遭遇了类似的空气币挖矿,但影响较小。大部分原因可能在于有 EOS 的前车之鉴,大部分 Telos 用户已经很清楚会经历 “ 瀑布 ”,因此没有参与。Telos 不会因为躲过了这两回就自满。随着有越来越多的项目部署在 Telos 上,且 Telos 的市值不断提升,Telos 可能会吸引更多攻击。事实上,有着这么高的 REX 质押量,在 Telos 上操作攻击的成本比在其他 EOSIO 链更低。不过,Telos 一直以来都选择直面问题,解决问题。Telos 社区面对这些隐患,迅速行动了起来。

TRIM 计划

许多 EOSIO 社区内的成员都指出本次问题源于系统设计的漏洞。的确如此,设计上存在着不足。当问题暴露,必须着力解决问题,升级系统。TRIM 计划旨在解决这些问题,改善 Telos 资源管理方式,确保网络能为用户所用,降低因攻击造成网络瘫痪的几率。

尽管不少熟悉 EOSIO 软件的朋友想了很多方法,但一直没有出现单一解决方案。这不是代码漏洞,而是基于系统设计出现的边缘攻击。因此,要升级网络资源管理方式,需要引入多项操作来确保升级的有效性,每项操作都分别针对攻击中的一部分。可能,每项单独拎出来都无法足够有效。这是问题的本质:有些问题有明显的解决方案,有些还是需要增加更多屏障来更好地保护网络。

TRIM 方案由 7 个步骤组成,希望能够给予用户与节点更多的自由,确保网络的可用性,避免出现限制用户使用质押或购买网络资源的情况。在寻求更高可用性的同时,Telos 绝不允许任何中心化组织对可自由使用资源的用户进行控制。

TRIM 方案如下:

1.为增加 REX 购买难度,防止 REX 锁定,限制每个账号从 REX 可购买资源的最高比例,向节点开放白名单。更新 REX 算法,购买份额可配置,节点在需要时可进行管理。

2. 为确保每一位 Telos 用户都享有一定量的免费交易,Telos 经济发展计划 (TED Plan)拿出来一部分资源购置了一个REX池,用来满足每个用户每日或每周一定量免费交易所需的CPU/NET 资源需求。

3. 为了支持高频交易用户在无需管理资源的情况下频繁交易,从钱包或浏览器端可发行工作型通证,以换取一定次数的交易行为。

4. 为了使攻击更加昂贵,可以通过修改 REX bancor 算法,为 REX 购买设置一个可由节点配置的底价。

5. 让用户在没有抵押资源的情况下就可以使用 DAPP,鼓励所有 DAPP 开发团队使用 ONLY_BILL_FIRST_AUTHORIZER 功能。

6. 让用户适应网络的高峰情况,将 Telos 主网调整为低容忍模式。

7. 为减少攻击方对主网的访问,在 API 节点运营团队的监控下,针对特定 DAPP API 对主网攻击的账号,将限制其攻击合约的访问,同时,BP 团队将配合将账号列入黑名单。

以上防御措施将不对 Telos 主网的去中心化特性造成影响,也不会出现中心化组织的监督措施。

方案实施

以下将具体说明如何执行 TRIM 计划中的 7 个步骤。

1. 为增加 REX 购买难度,防止 REX 被锁定,限制每个账号从 REX 可购买资源的最高比例,向节点开放白名单。更新 REX 算法,实现购买份额的可配置化,节点在需要时可进行管理。

一种攻击情况(EOS 上已经出现了这样的攻击)是,一个账号购买全部 REX 资源,造成系统瘫痪。我在前面的文章(解决 EOSIO REX 过度使用问题)里提到过,限制单一账号可购买的 REX 资源数量将会提高攻击的成本,但更重要地是,这会鼓励需要大量使用资源的项目方质押他们所需的 CPU 与 NET 资源。

来自 Teleology 节点的 Ryan Jones 已经将修改执行代码编写完成。正在准备在 Telos 测试网上进行测试,它允许节点进行修改,允许节点向特定账号开放白名单,这样他们就能购买更多 REX 资源。在测试结束后,节点将执行代码。

在需求增加时,为了能提升购买 REX 的价格,REX 将使用 Bancor 算法来设定价格。为了防止价格走向极端,针对随时可购买的 REX 资源总量设置了上线。然而,这一限制不必设置得过低。REX 资源出售量一旦达到总额的 80%就会停止。最优值尚不确定,但应该会比这高。EOS 现在的情况表明,在这样情况下, REX 可以迅速且低价地暂停。

最简单的操作方法是应用新代码来提升这个值。不过与其艰难地重新编写,不如开放投票,使其可配置。当节点达成 2/3+1 的选票,就可以在无需引入新代码的情况下,更新这个值。

为了实现这一操作,Telos 核心开发者们(TCD)必须更新且测试代码,再将代码交由节点执行。

2. 为了确保 Telos 用户能够拥有一定量的免费交易,分配 TED 计划(Telos 经济发展计划)中的一部分资金,用以购买 REX 资源,满足每天或每周免费交易所需的 CPU/NET 资源需求。

在 Telos 上创建新账号是免费的,但是这些账号只拥有非常低的 CPU 与 NET 质押额(分别为 0.9 与 0.1 TLOS)。如果无人申领,账号将回收,可创建更多免费账号。为了确保每个账号每天或每周都可以进行一定量的免费交易,可创建专门的资源池。TED 的计划是有效的,通过按月从预留资金中拨出一部分来购买REX资源这种方式来创建起这个资源池,而不是简单地增加REX 奖励池来筹集资金。(当 TED 计划在几年后逐渐收尾,这部分资金将投入专门针对此项目的永久质押池)。对 REX 质押者来说,这样的设计并不会影响他们的收益,对于 REX 购买者而言,REX 资源价格将会上升,因为一部分资源投入了这个资源池。

这样设计的目的是为了保证每个 Telos 账户就算在没有质押任何资源或购买任何资源的情况下,每天或每周都可进行一定量的免费交易。具体免费交易额度将由节点设定,起始值设定在每天 3-5 笔或每周 20 笔较为合理。

来自 CalEOS 的 Jesse Schulman 正在编写这部分代码,不过 Greymass 最近也开发了可达成类似效果的应用。为了能够实现这个设计,TCD 将评估各种不同的方式,采用或创建最优代码,再将其交由节点执行。

3. 为了支持高频交易用户在无需管理资源的情况下频繁交易,从钱包或浏览器端可发行工作型通证,以换取一定次数的交易行为。

针对每日或每周都进行高频交易的用户,超过免费资源池限额一般需要质押 TLOS 来换取更多资源,或者从 REX 中购买资源。对于那些不熟悉 EOSIO,或不愿进行资源管理的用户来说,作为中间缓冲方式,钱包和浏览器可使用通证来为用户提供免费资源。这将为高频交易用户提供更多的选择,对普通互联网用户更加友好,大众更容易接受。

来自 Telos Miami 的 Marlon Williams 正在用 SQRL 代币进行设计,该代币支持用户在交易的时候消耗 SQRL,从而不必消耗自己的资源。其他钱包也可以使用相似的通证实现这样的设置,这样可以大大便利那些不想要管理资源的高频交易用户。这也可以在 REX 外形成另一个市场,为系统提供更高效率。

4. 为了使攻击更加昂贵,可以通过修改 REX bancor 算法,为 REX 购买设置一个可由节点配置的底价。

在 eosio.rex 系统合约中,REX 资源价格由 Bancor 合约决定。然而,Bancor 合约与大型去中心化网络的治理比起来较为僵硬,不够理想。在细看 REX 所用的 Bancor 算法一文中提到,算法主要受 “连接器权重” 操作和每种通证在合约中的数量影响。EOSIO 上出现的一些缺陷都可归结于低效的可管理性,比如在上线时 EOS RAM 价格的暴涨。Telos 通过修改合约中的 RAM 初始数量一定程度上缓解了问题,不会出现像 EOS 上那样疯狂的投机行为,但是仍然无法高效管理基于 Bancor 的合约。这会对 REX 资源价格有较大的影响,因为资源数量在不断变化。连接器权重控制是并不实用,我们需要更好的算法,可以在 Bancor 算法中引入资源底价,这可允许 REX 以更高的价格进行交易,从而提高资源攻击的成本。

现在,TLOS 对 REX 的比例是 1:3,000。这意味着 1 个 TLOS 可购买使用 1 个月的 3,000 CPU 的资源。这意味着资源十分廉价,一定程度上鼓励了攻击。这是 TED 计划中高质押奖励带来的副作用。TRIM 计划或将在一定程度上提高价格。

设置节点可调整的底价,大概在 1:600 到1:800 之间,虽然这样的资源价格对普通用户来说仍然十分低廉,但对那些想要钻空子滥用网络资源的用户来说已经足够贵了。这样的调整会带来两个正向的变化:在 REX 中质押资源的用户可拿到更高的回报,因为池子里有其他的资金在汇入;TLOS 价格将提高,因为会有更多用户将其用于质押来储备资源,从而增加其价值。

为了实现这样的设计,TCD 必须更新代码,测试,并由节点执行。

5. 让用户在没有抵押资源的情况下也可使用 DAPP,鼓励所有 DAPP 开发团队使用 ONLY_BILL_FIRST_AUTHORIZER 功能。

10月 EOSIO v1.8 协议功能的激活,为 Telos 的运行带来了不少的改进,其中 ONLY_BILL_FIRST_AUTHORIZER 功能是跟本方案最相关的,它可以让项目方为用户提供主网资源(例如 SQRL 通证可用于支付用户的交易)。鼓励项目方使用这个功能,用户在使用应用时,无需自行管理主网资源。这也意味着,只有在 DAPP 交互范围以外的场景,才会用到之前提到的让主网为用户提供操作所需的资源以及打造特殊用途的通证来支付主网资源。

实现这个步骤,不需要在系统层写新代码,只需要让 Telos 的 DAPP 开发团队知道如何使用这个新功能。Telos 生态中的 DAPP 已经开始准备,针对这些变化,新开发的以及现有的应用已了解如何来调整。

6. 让用户适应网络的高峰情况,将 Telos 主网调整为低容忍模式。

Telos 主网目前的活跃度跟主网性能的极限还有很大的差距,在这种情况下,主网有很高的容忍度,为资源用尽的用户可提供操作所需要的资源。这么做,用户可能会习惯抵押非常少量的 TLOS 以换取主网资源。如果用户养成了这个习惯,主网活跃度又突然暴增,主网没有能力再为用户提供操作资源了,那么用户真的只能依赖与他们自己所抵押的网络资源进行操作,这也是今天 EOS 遇到的情况。

高容忍度的主网,能让用户在抵押很少的情况下做很频繁的操作,不过当主网活跃度暴增时,欠缺资源额度的用户将会受到很大打击。

通过降低主网的容忍度,减少对抵押不足用户的支持,Telos 的用户将能更好的应对主网活跃度上涨的情况。这样的调整,配合 TRIM 提案中的其他步骤,将鼓励所有用户及项目方随时有足够的网络资源储备,也将鼓励更多的通证质押,可降低恶意资源攻击所造成的影响,也可能会看到 TLOS 通证因此获得了更高的需求而上涨。TRIM 计划的实施,轻度用户将不会受到影响,重度用户将需要学习如何有效的质押资源,以应对不同的主网使用环境。这个步骤预计会是整个计划中比较后期执行的一步,以确保轻度用户的主网体验。

7. 为减少攻击方对主网的访问,在 API 节点运营团队的监控下,针对特定 DAPP API 对主网攻击的账号,将限制其攻击合约的访问,同时,BP 团队将配合将账号列入黑名单。

绝大部分的 Telos 用户是通过节点团队、项目方、或第三方管理的 API 与主网互动。Telos 有要求节点必须提供公开的 API 让大众能访问主网,但没有要求 API 必须接受所有类型的操作,对于不是节点的团队,Telos 对他们的 API 所提供的操作类型,没有任何要求或限制,Telos 系统是非常自由的。Telos 是真正的去中心化网络,没有人可以阻止应用部署于 Telos 主网,但如果支持 Telos 的 API 管理团队,对特定的应用不认可,那么他们的 API 可以不支持这个应用。有些 API 管理团队,因为必须符合当地法规,也会需要这么做。

如果有应用没办法获得其他 API 的支持,应用方可以搭建 API,为应用的用户提供访问的通道。用户如果想与被限制的合约做互动,也可以自己开发 API。这是去中心化系统的实践。

如果有项目出现了对主网有伤害的行为,在 API 管理团队的确认下,可以对其项目进行阻挡,项目方也可告知用户有哪些第三方或自己提供的 API 允许应用的访问。所以如果有类似 “资源挖矿” 的项目出现了,阻塞了主网,API 团队可以对其进行限制,这个限制很有可能不是完全隔离项目,但能降低项目对主网造成的阻塞,让主网依然可用。一个更强硬的 API 措施,是让 BP 团队阻挡特定的应用或合约与 API 交互。在 Telos 治理文件中(尤其是 regproducer 协议)明确禁止删除或更改交易以获得利益,但没有禁止 BP 为了维护主网安全及合规等理由而阻挡交易,这也是所谓的将账号或合约 “加入黑名单” 的动作。如果有账号攻击主网,是可以将它列入黑名单的,其他理由包括违反国家法规或窃盗等行为。

当一个 BP 团队将账号列入黑名单时,其他 BP 团队有可能依然在允许这个账号的交易,这些都是个别团队所做的选择,如果 Telos 社区用户认为有 BP 的行为是不对的,社区可以投票将行为不当的 BP 投下去,同时如果有 2/3+1 的 BP 都认为 BP 阻挡特定的交易是违反 regproducer 协议的,他们可以对阻挡交易的 BP 进行制裁。这是 DPOS 生态该有的治理系统。

所以当主网的运行遭遇威胁时,Telos 生态中的每个 BP 团队可以做出他们对事件的判断,看是否有需要将特定的合约列入黑名单,BP 将需要对 Telos 社区负责任,BP 团队必须做出自己的决定,而不是等待链上投票的结果。这不是主网对项目方的封杀,而是各别参与者自行做出的决定。只有在多数 BP 都决定要封锁一个应用时,封锁才能够生效,如果生效的封锁不是社区成员想要的,那么社区可以把做出封杀决定的 BP 投下去,如此,任何被 BP 列入黑名单的应用,都是得到 Telos 社区认同的。

计划执行

与 TED 计划不同之处,TRIM 计划围绕主网运行及功能,这些都是 Telos BP 有权利可以做修正的。所以不需要对治理系统做出修正,在 2/3+1 的 Telos BP 共识下,他们就可以做出调整。

TRIM 计划的执行,也不需要在协议层上做大改动。每次主网有 EOSIO 代码更新,生态成员都需要做很多测试工作,这提高了主网的运营成本,同时也拖延了对事件的反应周期,因为 Telos 核心开发成员与 BP 团队对系统层的更新都格外小心,因此我们倾向让 Telos 核心代码近似 EOSIO 参考代码。TRIM 计划的几个步骤已经启动,有些步骤还需要代码的开发、测试及部署,有些需要做生态教育及推广。当 TRIM 计划完全上线,Telos 主网将会有多个防范措施,有效阻挡外来的恶意攻击,用户的资源管理也将更简化,只有重度用户及项目方需要花时间做资源管理。TRIM 计划将有效进化 Telos 区块链的可用性及稳定性。

支持

本次 TRIM 计划由以下 Telos 节点与团队支持执行:

GoodBlock, Telos Miami, CalEOS, Infinitybloc, BlindBlocArt, EOSZA, Teleology, Cryptosuvi, Scatter, EOS Tribe, Telos DAC, Telos Voyager.


免责声明:EOSwriter 不为本页面内容或产品背书,我们尽全力为读者提供所能获得的重要信息。在做与本文内容相关的决策前,建议读者进行完整的独立研究分析,并为自己的决策负完全的责任。在此声明,本文非投资建议。