前言

随着电视剧的爆红，SQUID游戏的人气也逐渐上升。鱿鱼10月21日上线后，价格区间发生了剧烈变化，但现在真的安全了吗？

从代码来看，Squid依赖于Ethereum提出的EIP-1967，知道于闯区块链安全实验室将从EIP-1967提案中再次讨论Squid的安全风险。

SQUID价格从0.08美元飙升至9000万美元，再飙升至3000美元。然而，令人尴尬的是，价格立即暴跌，5分钟内从3000跌至0.0007。原因是合约开发商用7,000 W鱿鱼片在短短几分钟内砸盘，导致流动性池被抽干，直至归零。

在经历了0.0007的底部后，最近短短几天游戏令牌再次涨到0.4，涨幅超过50倍，相当有气势。

EIP-1967

这个EIP标准化了逻辑合约地址的存储槽，而不是像DelegateProxy (EIP897)那样在代理合约上使用公共方法。这样做的理由是代理永远不应该向最终用户公开可能与逻辑契约冲突的功能。

首先，EIP-1967的目的是指定一个通用存储槽，用于在代理合同中的特定位置存储逻辑合同的地址。

在这个提案中，逻辑合约地址的存储槽是标准化的，而不是像DelegateProxy (EIP897)那样在代理合约上使用公共方法。

通过跟进提案，提案中定义了以下标准化存储插槽。

字节32(uint 256(keccak 256(' EIP 1967 . proxy . implementation '))-1)

字节32(uint 256(keccak 256(' EIP 1967 . proxy . beacon '))-1)

字节32(uint 256(kekcak 256(' EIP 1967 . proxy . admin '))-1)最后，通过计算，列出了三个字节32位哈希值作为推荐的存储插槽。

字节32(uint 256(keccak 256(' EIP 1967 . proxy . implementation '))-1)

//逻辑协定地址存储槽

0x 360894 a 13 ba 1a 3210667 c 828492 db 98 dca3e 2076 cc 3735 a 920 a3ca 505d 382 BBC

字节32(uint 256(keccak 256(' EIP 1967 . proxy . beacon '))-1)

//信标协定地址存储槽

0x3f 0 ad 74 e 5423 ebfd 80d 3 ef 4346578335 a9 a 72 eaee 59 ff 6 CB 3582 b 35133d 50

字节32(uint 256(keccak 256(' EIP 1967 . proxy . admin '))-1)

//管理地址存储槽

0xb 53127684 a 568 b 3173 AE 13 b 9 F8 a 6016 e 243 e 63 b 6 E8 ee 1178 d6a 717850 b5 d 6103

《EIP-1967》中提到，对于代理人来说，代理人永远不应该向最终用户披露可能与逻辑合同的功能相冲突的方法。在此计算中，keccak256的结果被缩小并转换为字节32，以隐藏正面图像，从而防止基于函数的签名攻击。

针对这种攻击，具体xsddb前四个字节函数签名的攻击思路如下：

因为函数是由函数签名(函数xsddb的前四个字节)在坚实度上标识的，所以很容易发生冲突。关于函数签名的相关知识点，请参考之前在实验室的文章。

在独立的实体文件中，编译器会检查所有外部和公共函数的函数签名冲突，但是对于代理模式的契约文件，代理契约和impl契约之间可能存在函数签名冲突。一旦发生这种冲突，将直接调用代理契约中的函数，而不是impl契约对应的函数。

除了上述目的，使用EIP-1967还有以下好处。

合同代理模式规范化：由于代理合同中缺少获取代理逻辑地址的通用接口，无法构建信息。

进行操作的通用工具。比如在区块链浏览器中，最终用户想要与底层逻辑合约而不是代理本身进行交互。

如果拥有从代理检索逻辑合约地址的通用方法将可以允许区块浏览器去显示逻辑合约的 ABI 而不是代理的 ABI。浏览器可以还检查合约在不同槽位的存储，来确定它是否确实是一个代理。

Squid安全性

通过跟进 Squid 合约，虽然我们看到合约部署者0x87230146e138d3f296a9a77e497a2a83012e9bc5 通过 renounceOwnership 方法将 _owner 设置为了 0 地址：

但是这样就可以高枕无忧了吗？在Squid的初始化中，部署者通过为ApprovedEngine传入逻辑函数地址并设置为接口实现。

但与此同时，初始化传入了参数_sir，该参数从代码中可以发现，其被存储在了存储槽(storage['0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103'])中。该地址后续可成功通过ifSir修饰器的检查并随时调用approveTo函数来部署新的逻辑合约实现。

_sir可通过升级对应的逻辑合约，进而改变了_implementation返回的对于EIP-1967中提到的槽中bytes32(uint256(keccak256("eip1967.proxy.implementation") - 1))的值通过改变Engine收到调用的时候合约执行逻辑，进而修改逻辑合约的代码：