前言随着电视剧的爆红，鱿鱼游戏的热度逐渐上升，鱿鱼自10月21日上线以来，价格区间变化很大。但是现在真的安全吗？
Squid在代码方面依赖于以太坊提出的EIP-1967，知道创宇区块链安全实验室将从EIP-1967提案讨论Squid的安全风险。
鱿鱼价格从0.08元飙升至9万元，飙升至3000美元。然而尴尬的是，价格立刻崩盘，5分钟从3000跌到0.0007。原因是合同开发商在短短几分钟内用7,000 W鱿鱼砸了市场，导致流动资金池被抽干，直至归零。
游戏代币在经历了底部的0.0007后，短短几天又涨到了0.4，涨幅超过50倍。可以说声势不小。
EIP-1967这个EIP标准化了逻辑契约地址的存储槽，而不是像DelegateProxy (EIP897)那样标准化了代理契约上的公共方法。这样做的理由是代理不应该向最终用户公开可能与逻辑契约冲突的功能。
首先，EIP-1967的目的是指定一个通用存储槽，用于在代理契约中的特定位置存储逻辑契约的地址。
在这个提议中，逻辑契约地址的存储槽是标准化的，而不是在代理契约上使用公共方法，如DelegateProxy (EIP897)。
通过跟进提案，提案中定义了以下标准化存储槽。
bytes 32(UINT 256(keccak 256(' EIP 1967 . proxy . implementation ')-1)bytes 32(UINT 256(keccak 256(' EIP 1967 . proxy . beacon ')-1)bytes 32(UINT 256(keccak 256(' EIP 1967 . proxy . admin ')-1)最后通过计算，将三个字节32位的哈希值列为推荐存储槽。
bytes 32(UINT 256(keccak 256(' EIP 1967 . proxy . implementation ')-1)//逻辑地址存储槽0x 360894 a 13 ba 1a 3210667 c 828492 db 98 da 3 e 2076 cc 3735 a 920 a3 ca 505d 382 BBC字节32(UINT 256(' EIP 1967 . proxy . beacon ')-1)//信标地址存储槽0xA3f0ad74E542
在EIP-1967中提到，对于代理人来说，代理人永远不应该向最终用户披露可能与逻辑契约的功能相冲突的方法。在这个计算中，keccak256结果被还原并转换成bytes32以隐藏前面的图像，从而防止基于函数签名的攻击。
针对这种攻击，哈希后的前四个字节函数签名的攻击思路如下：
因为solidity是通过函数签名来标识一个函数的，而函数签名是函数hash后的前4个字节，所以非常容易发生碰撞。函数签名的相关知识点可以参考实验室之前的文章。
在独立的solidity文件中，编译器自己会检查是否所有的外部和公共函数都有函数签名冲突。但是，对于代理模式的合同文件，代理合同和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收到调用的时候合约执行逻辑，进而修改逻辑合约的代码：
针对该修改逻辑合约进行攻击已屡见不鲜，在几天前 bzx 就曾因"开发方被钓鱼导致私钥被盗"，进而代理合约被修改并影响到了流动性提供者，攻击者不仅转走了原本合约内的资金，还尝试转移对合约进行了approve的账户的资产。
事件参考（https://bzx.network/blog/prelminary-post-mortem）
最后，通过追溯该Squid的部署合约，我们可以发现该合约的具体部署Transaction:
https://bscscan.com/tx/0xcaa4186f7e4dacd856835cb92a8518c88b098a33348a42168f99a0c57b7291c7
而在此 Transaction 中，传入合约的参数最后一个参数则为 _sir 地址：0x6bdb3b0fd9f39427a07b8ab33bac32db67eb4e38
当然，还存在多种方法拿到该地址如：
并且该sir后门地址至今仍非常活跃：
后记Squid 经过了暴跌与暴涨，但本质上仍没有完成去中心化，合约依然存在诸多安全风险。在频繁和大幅度的涨跌中，常有参与者忘记了本心，最后导致亏空的结局。
