「此次黑客攻击主要是利用 imBTC 资产 ERC777 标准的漏洞进行了重入攻击。回调机制允许黑客反复将伪造的 imBTC 作为抵押物借出款项。」
——dForce 公告
上述安全事件得到初步解决，为受害者（比如橙皮书老哥在 DeFi 里亏光又回本的两天）感到高兴。被攻击的细节也已经得到了披露，但究竟是什么导致了漏洞，仍有不同的声音。
有的认为是 ERC777 的不足；有的认为是兼容性的问题；有的认为 imBTC 实现的问题。在此，我觉得有些概念必须明确，才能方便我们对事实的探讨。
协议：汉语中的「协议」一词具有多义性。我们这里指的协议，不是法律意义上的「合约 / 契约 (Contract)」，也不是「软件许可证 (License)」，而是通信中的「协议 (Protocol)」。在电信领域，协议是通信系统中的两个或多个实体交换信息的系统规则。
标准：标准是「为了在一定的范围内获得最佳秩序，经协商一致制定并由公认机构批准，共同使用的和重复使用的一种规范性文件。」
THORChain将在主网上推出借贷协议 THORFi Lending:8月14日消息，去中心化跨链交易协议THORChain已发布借贷协议THORFi Lending，并获得节点运营商批准。借贷功能将在主网上推出，届时抵押品将仅限于BTC与ETH。[2023/8/14 16:24:21]
标准不一定是协议，因为标准不只是通信领域的。而协议也不一定是标准，因为标准必须得到规范的确认。但通信标准一定是通信协议。因此，标准必须由一些指定的组织颁布。比较知名的标准组织有 ISO、ITU、IETF 等。例如 TCP 作为一种传输标准，就是 IETF 颁发的 RFC-793 所决定的。
ERC777 是协议吗？
是的。
当然我个人倾向于另外一种表达，ERC777 包含了协议。ERC777 定义了一种代币类型，规定了代币合约的属性、开放的接口及实现的功能，用于规范以太坊地址与 ERC777 代币合约间的通信，这是通过接口完成的。但 ERC777 也包含了通信协议外的东西，例如 decimals() 这个函数用来查询 token 的精度，这显然是通信协议，但按照 ERC777 的要求必须返回 18，这就不属于通信协议的范畴。
数据：Solana 24小时TVL下降31.77%，其生态项目Solend TVL下降50.67%:金色财经报道，据Defillama监测，Solana的TVL从8.558亿美元下降到5.839亿美元，24小时骤减31.77%。此外，Solana上借贷协议Solend的TVL从2.553亿美元下降到1.174亿美元，24小时骤减50.67%。[2022/11/9 12:36:59]
ERC777 是标准吗？
是的。从名字就能看出来。
EIP 777: ERC777 Token Standard (ERC 代币标准)。
这里隐含了一点是什么呢，如果你发行了一个 token，说它是 ERC777 的 token，那么必须要实现此标准定义的所有接口。同时，这个 token 必须回溯兼容 ERC20 标准。这是什么意思呢？
什么是兼容性？
兼容性是指硬件之间、软件之间或是软硬件组合系统之间的相互协调工作的程度。
Solend发起提案提议授予Solend Labs紧急权力以临时接管巨鲸账户:6月19日消息，Solana 生态借贷协议 Solend 发起治理提案，提议：对占借款总额 20% 以上的巨鲸制定特殊的保证金要求。如果用户的借款超过主池所有借款的 20%，则需要 35% 的特殊清算门槛。该政策将在提案获得批准后生效；授予 Solend Labs 紧急权力以暂时接管鲸鱼的账户，以便清算可以在场外交易中执行，避免将 Solana 推到极限，这将通过智能合约升级来完成。一旦鲸鱼的账户达到安全水平，紧急权力将被撤销。该提案将于 5.5 个小时后投票截止。
此前消息，Solend 创始人 Rooter 发推敦促某个巨鲸（3oSE 开头地址）尽快偿还贷款，否则会进一步降低 SOL 价格，让其他账户面临清算。Solend 已临时禁用其 Main Pool 的 USDC、USDT 和 SOL 借款。[2022/6/19 4:38:35]
根据标准文档，ERC777 对 ERC20 是 backward compabitlity，这是什么意思呢？
JustLend就“是否将SUNOLD市场储备金比例调至100%”开启社区自治投票:据官方消息，JustLend 就“是否将SUNOLD市场储备金比例调至 100%”开启社区自治投票。用户现可通过访问JustLend官方网站或JustLend平台治理页面进行提案投票。
JustLend是波场TRON网络官方借贷平台，用于建立基于波场TRON资产的供求变化，以算法计算得出利率的资金池。[2021/6/18 23:47:10]
向后兼容（backward compatibility），又称向下兼容（downward compatibility），回溯兼容，在计算机中指在一个程序、库或硬件更新到较新版本后，用旧版本程序创建的文档或系统仍能被正常操作或使用（包括输入数据）、在旧版本库的基础上开发的程序仍能正常编译运行，或较旧版的硬件仍可在新版使用的情况。
什么意思，如果我们把 ERC20 看作旧版本，把 ERC777 看成新版本。回溯兼容指的就是，ERC20 的任何接口，在 ERC777 中都得到了实现。换句话说，假设一个 token 直接从 ERC20 升级到了 ERC777 （实际上不可能，但我们可以做这样的假设），原先通信方式仍然有效，但这不代表最终的结果是一致的。这点非常重要！首先来看一个例子。
Portbase已完成与区块链集装箱物流平台TradeLens的第一阶段集成:荷兰阿姆斯特丹港口及鹿特丹港口负责管理港口数字基础设施的子公司Portbase已完成与TradeLens的第一阶段集成，后者是由马士基（Maersk）和IBM共同开发的一个基于区块链的数字集装箱物流平台。（Offshore Energy）[2020/9/1]
关于兼容性的例子
SQL 注入
「SQL 注入是一种将 SQL 代码添加到输入参数中，传递到服务器解析并执行的一种攻击手法。」
简单说，用户可以通过公开的接口来实现对数据库的攻击。例如：
我们在登录网站时，会输入用户名和密码，服务器后台会判断用户名密码是否匹配，来决定是否能让用户登录。
假设我们在输入时，用户名输入：user'-- （注意--后面有个空格，单引号闭合 user 左边的单引号），密码随意输入，如：111，然后点击提交按钮。等价于 SQL 语句：
SELECT * FROM user WHERE username = 'user'-- 'AND password = '111'
由于「--」之后的部分被注释掉了，无论密码是正确或者是错误的，用户都可以成功登录。
当然，实际上的代码没有这么简单。你如果看了这段话尝试去攻击网站，是不会成功的。
这和兼容性有什么关系呢？解释一下。
假设 一个网站遵循用户协议 U20，只允许用户名是字母，因此用户无法输入 ' 和-这两个符号。当然不仅前端输入框限制，后端也会检查每个字符是否都符合条件。换句话说，在接口传递参数的时候，不允许这两个符号出现，这个接口是符合 U20 的。这时，不会出现示例中的 SQL 注入问题。（但不确定是否其它注入可能。）
某天，网站的用户协议进行了升级，变成了 U777，新的用户可以使用 ' 和- 作为用户名了，接口也需要进行升级。U777 对 U20 当然是回溯兼容的，因为旧的用户仍然可以使用用户名登录，也可以使用旧的界面和接口登录。而新的用户则需要前端和后端代码升级后才能登录。
如果前端和后端只是简单地对上述两个字符不加限制，势必会导致上述 SQL 注入问题。但这个要怪罪接口升级吗？
很显然，不是的。协议只是保证符合规范地将用户的输入传递给后端，协议升级后，这仍然正确地完成了。而新的字符带来的风险，是需要后端代码重新评估的，也可以认为后端代码与新的协议不兼容。
这是后端代码的问题吗？这是协议升级的问题吗？都不是。而是因为协议升级后，让用户产生了足以摧毁系统的超能力。
再把话题扯远一点，列车的最高速度从 20km/h 提到 100km/h，铁轨仍然和列车兼容。但噪音是否会造成沿途居民的影响，道口是否需要提高安全等级呢？这显然是要重新审视的。
应该怎么做？
回溯兼容不代表安全，因为新的特性必然具有外部性，而这个外部性是让其它实体很难预期的，所谓「安全是动态的」。回到刚才的例子，有两种做法。
一是提前对各种外部性进行判断。后端代码非常谨慎，假装不知道用户的输入是受限的，按照全字符集来进行处理，这样无论协议怎么升级，后端都是安全的。
二是灵活但审慎的策略。在协议升级时前，重新评估安全性，并做好修改和测试工作后重新部署。
根据例子的复杂度，两种做法都是可行的。更重要的是，为了避免重复劳动，提高效率，减少安全问题出现的可能，应当对共性问题进行标准化尝试。
例如，用户登录是个逻辑简单，且非常普遍的场景。为了防止 SQL 注入，就有例如 Prepared Statement 之类的标准化做法，完全不需要闭门造车。而回到开头的那个问题，我更想引用慢雾的一段话「第三方 DeFi 平台在接入的时候，应需要充分考虑平台本身的业务逻辑与接入代币之间的兼容性，才能避免因兼容性发生不必要的安全问题。而不是简单的将问题归咎于协议和代币提供方。」
为什么 ERC777 难以得到推广
为什么 ERC777 兼容了 ERC20，且提供了比 ERC20 更强大的功能，仍然不能得到广泛的应用呢？除了 ERC20 代币已经广泛使用，大家宁肯忍受它的缺点，使用 approve and transferFrom 这种并不那么安全的方法，也不愿或无法升级外，还有一个重要的原因是：光兼容 ERC20 是不够的，还需要兼容现有的其它协议。如果每个协议都要单独评估应用 ERC777 的风险，成本太高，且容易造成误解，这显然不利于它的推广。
我们是否可以把公共的常用功能抽象出来，形成标准的实现？例如「存款」这个操作，如果它有针对不同代币标准的标准参考实现，那么许多问题出现的概率就会降到很低。
至少，我们也应该小心所有和我们打交道的人，每个合约都要小心所有与其打交道的合约，来避免出现不必要的安全问题。因为「不断地他添来另外的你我 / 使我们丰富而且危险。」（穆旦，《诗八首》，1942 年。）
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。