一些用户和基于EOSIO的智能合约的RAM资源无意中被恶意第三方创建的特殊智能合约所消耗。发生这种情况的原因是对使合约能够通知事件其他合约功能设计的误解，例如一个收入转账。恶意合约利用这个通知功能，在没有通知对方获取同意的情况下，用随机数据填满其他人的RAM资源，并且无法释放这些数据。5 s' j( p4 g" V. z
7 Q# W- `9 Y) U8 ]* [+ i
    概述  Y: s8 y$ A' v' w! A8 A

! z+ ?- u7 M$ s9 B; j) w    1.没有Token被偷窃$ `4 G! ^1 e1 p6 v! A

7 T/ ^6 |% D. A# s$ T: g  L2 h    2.正确执行的合约不容易受到攻击
' s2 P, ]3 ~4 ~) X/ ]9 X! a+ j* e2 R6 ?
    3.治理流程可以修正与各方意图相悖的代码表现
, m6 ^$ |# D! E. @7 N5 a# G  N* B
/ W+ T) O8 Q( f: {  ?# Q    4.出块者-对于保护的措施只有缓解的选项是可行的
8 n3 Q' G+ f, p! B( M+ n
1 `: A# z  F! D% f    5.长期的升级可以使默认的行为更加安全7 X0 ?! k0 n- p3 D- e7 J9 ?

/ @+ A7 [- f  Z    没有Token丢失4 I) l7 R. u5 Y; U! ~. ?

  V3 [5 y+ K3 \$ C    恶意合约利用了智能合约开发者和用户对开发中智能合约最佳实践的误解。这种攻击类似于估计破坏而不是盗窃，一旦EOS治理程序可以审查和纠正这种情况就对于相关方不会有长期损害。* e- H( N5 m6 ?
; F* v( t. H+ i% s- i
    防止滥用的最佳实践: ]# _+ E" V0 G" g. K7 f* Y; d

0 W) ]- k% X1 k! T7 L- G3 E    希望每个用户都可以审查一下他们会与之交互的合约，或者交由信任的第三方代他们去审查合约。这意味着审查者应该谨慎地与使用通知功能的智能合约交互。例如消耗他们的CPU和RAM，发送Token到他们不信任的智能合约。8 |. E1 f' G9 w  J  I+ n" U1 V# i* y

% R+ |- k& I" O9 {% y9 Z    开发者以编程方式发送Token到一个不信任的第三方指定账号，应该通过一个没有可用RAM资源的账号中继传送。这既适用于中心化交易所处理用户提款，也适用于去中心化交易所通过智能合约操作。有几个可信任的中继合约可用。
% v5 ?0 B+ P7 \# u5 W, a
/ M9 @3 t( i2 Q$ P7 @    许多钱包的开发者已经采取行动去提醒用户交易时可能会消耗RAM资源。
/ Y6 i7 z; t7 A; H5 Y
+ t9 l  g4 G1 T) g5 c    通过治理程序释放消耗的RAM+ b* q0 e5 C6 u1 `2 t
3 u0 `/ m- \4 D% Q
    我认为代码的意图（【翻译】“代码的意图”即法律）正如用户和开发者所理解的那样，就应该被强制执行。如果一个恶意合约很明显的利用用户意图和代码实际效果之间的不匹配，那么当恶意合约的始作俑者和那些与之牵连的人进行争议仲裁时，BP们有权将恶意合约列入黑名单。! v$ {7 L! b, j( n7 }, r& a
) t6 A) I( B8 f3 i
    如果仲裁发现代码的行为违背与代码有关联的各方的意图，那么当选的出块者可以更新代码，使结果与各方的原始意图尽可能的匹配。在这种情况下，代码将被更新以释放意外消耗的RAM资源，并且将来不会消耗RAM。) j1 P8 `8 j* Q8 R4 L+ c$ B
; n; G% ?' {9 ]1 e- W1 \9 u
    为什么这是EOSIO的一个功能？
2 s) w( f) G/ K* t- K9 {6 D) [3 Y, Z# v& C$ J6 y7 C% N
    目前有很多针对这个功能导致RAM被滥用的案例。最基本的案例是想要接受用户资金存款的游戏合约。交易所将实施代码以处理来自代币合约的转账通知，然后将交易所的余额记入发送人。在这种情况下，交易所和存款用户可以合理地授权交易合约消费用户的RAM来存储他们的余额。交易所不一定要将用户的余额存储在他们自己的RAM中，因为当许多帐户向交易所发送微小余额可以启用不同的攻击。
: k! f+ W( l6 E/ J( y. g( r4 k6 |7 \8 N2 @5 I4 d& n5 L
    EOSIO有一个相关的功能，内联actions，允许合约作为当前交易的一部分调用另一个合约的代码。与action通知功能不同，内联actions仅限于分配生成内联actions的合约的资源。Action通知依靠着原始action所分配的资源权限。
. E6 a4 l& |3 g: F; b# Y
  R7 \8 i+ E* b1 D* K* c8 @    防止意外行为继续发生
& r: @' b& Y& E6 r8 c0 f
- V( F& \% f1 S, H    虽然现在的设计有很多正当用途，但我们认为现在代码的默认行为与用户和开发者的直觉思维相反运行。为了简化不太常见的使用案例，必须采取措施，防止滥用而导致正常使用更加复杂。
5 v5 d4 i9 Y4 g) s8 y) w0 l6 A& w. U8 A( @
    接下来我们建议只有接收通知的一方才有权利消耗RAM。这样可以安全地将Token发送到任何合约而不必担心它会意外消耗。交易所能够安全的处理提款，无需在处理提款请求前去审查部署到用户账号的合约。+ s4 U( C) i& m( N0 C6 R1 w* f$ l! c
9 _7 ^1 |, x/ I5 |: x' `. Y3 j
    在此提议下，现有合约必须获得直接授权才能消耗一些用户可用的RAM。在接受用户的存入之前，交易所合约将要求用户“开立账户以预留用于存储其余额的空间”。然后，传入的存入通知将简单地增加预先分配的RAM，而不是分配新的RAM。5 W7 r6 M9 B" A: D2 _- A

% B$ m5 [& C2 r) l    提议升级路径, ~$ f; D  W5 e/ i; j5 V
3 M3 N3 d% i* P" [7 o
    我们正在准备一个仅限于出块者的升级，它将改变默认行为，以防止action通知的接收者（例如token转账通知）意外消耗发送者的RAM。如果所有的BP都采用这个升级，那么就不太需要滥用的缓解措施了。不幸的是，这个缓解措施可能会破坏有效合约，直到他们可以在action通知处理期间更新到不依赖用户账号上的RAM分配。5 u0 S: ?/ M" o, B# J
/ F$ L5 s8 z6 Q
    幸运的是，升级合约以采用最新最佳实践的过程应该相对简单。
% ]! B! Z% h( @4 e
/ [+ E6 ^0 @3 m0 v: D8 u1 {    是否所有节点都采用这个仅限于出块者的升级将会是下一次公投的一部分。: D4 D6 V$ \+ z2 X4 x/ f1 M
8 y# o3 D2 l1 d; I* B1 b! \
    结论+ H/ J) H5 U& X4 _% k
0 n. P7 m( W2 T' v
    EOSIO正在如当初设计的一般运行，当你正确使用它的时候，它就是安全的。我们相信，对于大多数的情况，我们可以更轻松地使用EOSIO，并与EOS社区合作开发最强大的整体解决方案。$ I5 a7 i+ r' a  w2 [2 x2 @

$ O+ y0 m8 l7 ^( J    =END=