BM：防止意外的 RAM 消耗

　　北京时间8月28日晚十点十三分，BM 在 Medium发布了文章《Preventing Unexpected RAM Consumption》（《防止意外的 RAM 消耗》），提出建议防止意外的 RAM 消耗。并对于一些用户和基于 EOSIO 的智能合约无意中将其 RAM 资源用于恶意合约的第三方的情况进行分析。根据此提议的更改，现有合约必须获得直接授权以消耗一些用户可用的 RAM。以下由 IMEOS 翻译全文，转载须注明出处。

　　BM 原文参见：https://medium.com/eosio/preventing-unexpected-ram-consumption-8029a9342659

　　一些用户和基于 EOSIO 的智能合约的 RAM 资源无意中被恶意第三方创建的特殊智能合约所消耗。发生这种情况的原因是对使合约能够通知事件其他合约功能设计的误解，例如一个收入转账。恶意合约利用这个通知功能，在没有通知对方获取同意的情况下，用随机数据填满其他人的 RAM 资源，并且无法释放这些数据。

　　概述

　　没有 Token 被偷窃

　　正确执行的合约不容易受到攻击

　　治理流程可以修正与各方意图相悖的代码表现

　　出块者-对于保护的措施只有缓解的选项是可行的

　　长期的升级可以使默认的行为更加安全

　　没有 Token 丢失

　　恶意合约利用了智能合约开发者和用户对开发中智能合约最佳实践的误解。这种攻击类似于估计破坏而不是盗窃，一旦 EOS 治理程序可以审查和纠正这种情况就对于相关方不会有长期损害。

　　防止滥用的最佳实践

　　希望每个用户都可以审查一下他们会与之交互的合约，或者交由信任的第三方代他们去审查合约。这意味着审查者应该谨慎地与使用通知功能的智能合约交互。例如消耗他们的 CPU 和 RAM，发送 Token 到他们不信任的智能合约。

　　开发者以编程方式发送 Token 到一个不信任的第三方指定账号，应该通过一个没有可用RAM 资源的账号中继传送。这既适用于中心化交易所处理用户提款，也适用于去中心化交易所通过智能合约操作。有几个可信任的中继合约可用。

　　许多钱包的开发者已经采取行动去提醒用户交易时可能会消耗 RAM 资源。

　　通过治理程序释放消耗的RAM

　　我认为代码的意图正如用户和开发者所理解的那样，就应该被强制执行。如果一个恶意合约很明显的利用用户意图和代码实际效果之间的不匹配，那么当恶意合约的始作俑者和那些与之牵连的人进行争议仲裁时， BP 们有权将恶意合约列入黑名单。

　　如果仲裁发现代码的行为违背与代码有关联的各方的意图，那么当选的出块者可以更新代码，使结果与各方的原始意图尽可能的匹配。在这种情况下，代码将被更新以释放意外消耗的 RAM 资源，并且将来不会消耗 RAM。

　　为什么这是 EOSIO 的一个功能？

　　目前有很多针对这个功能导致 RAM 被滥用的案例。最基本的案例是想要接受用户资金存款的游戏合约。交易所将实施代码以处理来自代币合约的转账通知，然后将交易所的余额记入发送人。在这种情况下，交易所和存款用户可以合理地授权交易合约消费用户的 RAM 来存储他们的余额。交易所不一定要将用户的余额存储在他们自己的 RAM 中，因为当许多帐户向交易所发送微小余额可以启用不同的攻击。

　　EOSIO有一个相关的功能，内联 actions，允许合约作为当前交易的一部分调用另一个合约的代码。与 action 通知功能不同，内联 actions 仅限于分配生成内联 actions 的合约的资源。Action 通知依靠着原始 action 所分配的资源权限。

　　防止意外行为继续发生

　　虽然现在的设计有很多正当用途，但我们认为现在代码的默认行为与用户和开发者的直觉思维相反运行。为了简化不太常见的使用案例，必须采取措施，防止滥用而导致正常使用更加复杂。

　　接下来我们建议只有接收通知的一方才有权利消耗 RAM。这样可以安全地将 Token 发送到任何合约而不必担心它会意外消耗。交易所能够安全的处理提款，无需在处理提款请求前去审查部署到用户账号的合约。

　　在此提议下，现有合约必须获得直接授权才能消耗一些用户可用的 RAM。在接受用户的存入之前，交易所合约将要求用户“开立账户以预留用于存储其余额的空间”。然后，传入的存入通知将简单地增加预先分配的 RAM，而不是分配新的 RAM。

　　提议升级路径

　　

　　原标题：BM：防止意外的 RAM 消耗|bm|代码|交易所