UniswapV3Pool禁止DelegateCall的设计目的是什么？

UniswapV3Pool继承的NoDelegateCall合约，核心逻辑是在关键函数执行前检查当前执行上下文的address(this)是否等于合约部署时的自身地址——如果不等，说明是通过delegatecall调用的，直接回滚交易。这种限制绝非无用，它是针对Solidity合约特性的关键安全防护，具体设计目的如下：

• 阻断恶意存储篡改：Uniswap V3 Pool的所有核心状态（流动性数据、手续费累积、头寸信息等）都存在自身的存储槽中。如果允许外部合约通过delegatecall调用Pool的代码，Pool的逻辑会直接操作调用者合约的存储。恶意合约可以刻意构造存储布局，让Pool的写入/读取操作篡改错误的存储位置，比如伪造流动性头寸、篡改手续费余额，最终实现资产窃取或破坏Pool正常运转。
• 避免逻辑上下文混乱：Pool的所有函数逻辑都是基于自身存储结构设计的。delegatecall会让代码在陌生的存储上下文运行，很容易出现逻辑错误——比如读取到错误的价格数据、计算错误的流动性变化，这些都会直接破坏交易对的价格机制和资金安全。禁止delegatecall能确保代码只在自己的存储环境中执行，逻辑行为完全可控。
• 缩小攻击面，抵御权限/重入类攻击：虽然Uniswap已有重入保护，但delegatecall可能被用来绕过权限检查。比如，利用delegatecall时msg.sender保持原始调用者的特性，恶意合约可以让Pool的权限校验函数误判调用者身份，执行本应受限的操作。禁止delegatecall能彻底封死这类利用路径，强化合约的安全边界。
• 保证逻辑确定性：Uniswap的核心数学模型（比如AMM价格曲线、流动性计算）要求状态绝对一致。允许delegatecall会引入外部存储的不确定性，相同的交易输入可能因为调用者的存储状态不同产生不同结果，破坏去中心化交易的公平性和可预测性。

你觉得这个限制“无作用”，是因为正常调用场景下address(this)必然等于合约自身地址，检查不会触发。但它是针对异常恶意调用的预防性措施，平时隐形存在，一旦遇到攻击尝试就会立刻阻断风险。

内容的提问来源于stack exchange，提问作者Nikita Duginets