Metafund观点：USDT 不会暴雷
USDT 是市场上最大的雷，这应该是行业中绝大多数人的观点，在前两个月 USDT 疯狂增发的时候，不少文章都表示 USDT 这样毫无节制的增发，风险越来越大，暴雷随时有可能发生。 这篇文章想告诉大家：我们认为，Tether 的商业模式决定它很难暴雷。这个观点并不是认可 USDT 的合规或者可信，只是通过一些现象来阐述我们的观点。 「众人贪婪我恐慌」这句话，被提起过无数次，大意就是大家都认定的一个方向，可能就不是事情发展的最终方向。 在上一篇《USDT : 一个点对点的电子现金系统》的留言中，有读者问，「Tether 为什么不暴雷？」当大家都认为 USDT 有风险，Tether 会暴雷的时候，事情真的有可能就不会朝着大家预想的方向发展。Tether 真正的风险大家思考一个问题，发行 USDT 的 Tether 公司，最怕的是什么风险。是监管吗？ 2018 年 11 月，美国司法部开始调查 Tether 公司，调查他们是否参与非法操控比特币。这大概是 Tether 公司与监管机构最早的交锋；2019 年 4 月，纽约总检察长办公室先是指责 BitFinex 与 Tether 公司合谋...
MetafundCosmos 生态跨链的能力和地方：龙头项目 Osmosis 详解
Osmosis 的一个生态系统与正常的生态系统连接时，我们的一个良好的当前运行系统还形成了正常的运行时间，但在未来的时候，IB 的生态系统和生态系统正常连接，但正常的生态系统与生态系统正常连接时会发生什么变化。 Cosmos 作为跨链项目，曾经沉寂，但在过去的内部，随着生态系统的丰富，Cosmo 生态系统早期的生态系统越来越小，成为跨链解决方案的强劲参与者。 Osmosis是Cosmos生态内的龙头DEX，在过去一年内TVL不断增长，目前稳居10+亿美元，FDV达到~55亿美元，在Coinmarket Cap排名第211位。 链是区块链世界的链公如何划分主题，跨链跨链跨链跨链跨链的跨链开放。方式，能够更好地理解当前跨链解决方案所面临的挑战。 本文目录： 一、产品机制：桥+DEX 1.1 桥：IBC作为跨链的进行 1.2 作为DEX：自由调节参数的AMM协议 1.3 其他功能及互操作性的未来 2. 经济证：PR+多种质通押带来高A 2.1 代币功能 2.2 代币分配 3.运营现实：生态内龙头，生态外待桥接团队及融资优势及风险一、产品机制：桥+DEX Osmosis是一条独立的链...
Metafund通往 Web3.0 的入口：零知识证明与 EVM
作者：宋嘉吉 任鹤义摘要Web2.0通向Web3.0征程中，有哪些实用的入口技术？ **在Web2.0向Web3.0演化的过程中，数据、资产账户互通和应用程序的互操作是两个尤为关键的问题。**前者涉及到不同生态之间的共识传递，这里包括了链上、链下共识传递；后者则是程序应用部署过程中的务实问题。虽然Web3.0世界如星辰大海般的浩渺，Web2.0向Web3.0进化过程中需要在实用技术、信用传导机制方面不断探索。 **目前，零知识证明和EVM是当下非常实用的的两种技术，成为Web2.0向Web3.0演化的两个重要入口。**零知识证明提供了一种方便实用的验证方法，使得在Web3.0之外（链外）的数据/账户能够方便取得链上验证，获得Web3.0生态的信任，为数据/资产互通提供可能。同时，目前所谓的Web3.0生态，主要基于以太坊构建，对接以太坊生态流量成为进入Web3.0世界的重要入口。因此，EVM成为极为实用的基础设施和技术。Web2.0生态也可以通过兼容EVM，尝试与以太坊对接，实现应用程序的互操作。 **零知识证明可以分担计算功能，链上只负责安全和验证。**将零知识证明和区块链的一...
Metafund观点：USDT 不会暴雷
USDT 是市场上最大的雷，这应该是行业中绝大多数人的观点，在前两个月 USDT 疯狂增发的时候，不少文章都表示 USDT 这样毫无节制的增发，风险越来越大，暴雷随时有可能发生。 这篇文章想告诉大家：我们认为，Tether 的商业模式决定它很难暴雷。这个观点并不是认可 USDT 的合规或者可信，只是通过一些现象来阐述我们的观点。 「众人贪婪我恐慌」这句话，被提起过无数次，大意就是大家都认定的一个方向，可能就不是事情发展的最终方向。 在上一篇《USDT : 一个点对点的电子现金系统》的留言中，有读者问，「Tether 为什么不暴雷？」当大家都认为 USDT 有风险，Tether 会暴雷的时候，事情真的有可能就不会朝着大家预想的方向发展。Tether 真正的风险大家思考一个问题，发行 USDT 的 Tether 公司，最怕的是什么风险。是监管吗？ 2018 年 11 月，美国司法部开始调查 Tether 公司，调查他们是否参与非法操控比特币。这大概是 Tether 公司与监管机构最早的交锋；2019 年 4 月，纽约总检察长办公室先是指责 BitFinex 与 Tether 公司合谋...
MetafundCosmos 生态跨链的能力和地方：龙头项目 Osmosis 详解
Osmosis 的一个生态系统与正常的生态系统连接时，我们的一个良好的当前运行系统还形成了正常的运行时间，但在未来的时候，IB 的生态系统和生态系统正常连接，但正常的生态系统与生态系统正常连接时会发生什么变化。 Cosmos 作为跨链项目，曾经沉寂，但在过去的内部，随着生态系统的丰富，Cosmo 生态系统早期的生态系统越来越小，成为跨链解决方案的强劲参与者。 Osmosis是Cosmos生态内的龙头DEX，在过去一年内TVL不断增长，目前稳居10+亿美元，FDV达到~55亿美元，在Coinmarket Cap排名第211位。 链是区块链世界的链公如何划分主题，跨链跨链跨链跨链跨链的跨链开放。方式，能够更好地理解当前跨链解决方案所面临的挑战。 本文目录： 一、产品机制：桥+DEX 1.1 桥：IBC作为跨链的进行 1.2 作为DEX：自由调节参数的AMM协议 1.3 其他功能及互操作性的未来 2. 经济证：PR+多种质通押带来高A 2.1 代币功能 2.2 代币分配 3.运营现实：生态内龙头，生态外待桥接团队及融资优势及风险一、产品机制：桥+DEX Osmosis是一条独立的链...
Metafund通往 Web3.0 的入口：零知识证明与 EVM
作者：宋嘉吉 任鹤义摘要Web2.0通向Web3.0征程中，有哪些实用的入口技术？ **在Web2.0向Web3.0演化的过程中，数据、资产账户互通和应用程序的互操作是两个尤为关键的问题。**前者涉及到不同生态之间的共识传递，这里包括了链上、链下共识传递；后者则是程序应用部署过程中的务实问题。虽然Web3.0世界如星辰大海般的浩渺，Web2.0向Web3.0进化过程中需要在实用技术、信用传导机制方面不断探索。 **目前，零知识证明和EVM是当下非常实用的的两种技术，成为Web2.0向Web3.0演化的两个重要入口。**零知识证明提供了一种方便实用的验证方法，使得在Web3.0之外（链外）的数据/账户能够方便取得链上验证，获得Web3.0生态的信任，为数据/资产互通提供可能。同时，目前所谓的Web3.0生态，主要基于以太坊构建，对接以太坊生态流量成为进入Web3.0世界的重要入口。因此，EVM成为极为实用的基础设施和技术。Web2.0生态也可以通过兼容EVM，尝试与以太坊对接，实现应用程序的互操作。 **零知识证明可以分担计算功能，链上只负责安全和验证。**将零知识证明和区块链的一...
Subscribe to Metafund
Subscribe to Metafund
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
账户抽象允许我们使用智能合约逻辑来指定交易的效果，以及费用支付和验证逻辑。这带来了许多重要的安全好处，例如多重签名和智能恢复钱包，能够在不更换钱包的情况下更换密钥以及量子安全性。
许多帐户抽象的方法已在不同程度上被提出并得到了实施，参见：EIP-86、EIP-2938，以及两年前的这篇文章。今天，由于开发者们希望专注于合并与分片，这些 EIP 的开发陷入了僵局，而 ERC-4337 这种不需要任何共识更改的替代方案已经取得了很大进展。
ERC-4337 尝试通过额外的协议手段实现和 EIP-2938 相同的事情。用户需要发送称为用户操作（user operations）的链外消息，这些消息由区块提议者（proposer）或为区块提议者生成 bundles 的构建者（builder）批量收集并打包成单笔交易。提议者或构建者负责过滤操作以确保他们只接受支付费用的操作。用户操作有一个单独的 mempool 存储池，连接到这个存储池的节点会进行 ERC-4337 特定的验证，以确保用户操作在转发之前能够支付费用。
ERC-4337 作为一个纯自愿的 ERC 可以做很多事情。然而，在一些关键领域，它比真正的协议内解决方案更弱：
现有用户如果不将其所有资产和活动移动到新帐户，则无法升级；
额外的 gas 开销（基本 UserOperation 用户操作约 42 k，而基本交易约为 21 k）；
较少受益于协议内抗审查技术（例如 crLists），它以交易为目标并会错过用户操作（user operation）
而实现最佳效果的一条现实途径，是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。这并不一定需要大家专门承诺遵守 ERC-4337。相反，可以将协议内支持设计为更通用，并支持 ERC-4337 及其替代方案和改进。
在这里，我将列出其中的一些 EIP，并说明它们可以按什么顺序实施。
为了让现有的 EOA 钱包升级到 ERC-4337 钱包，我们可以制作一个 EIP，允许 EOA 执行设置其合约代码的操作。一旦 EOA 做到了这一点，这种转变就不可逆转。从那时起，该帐户将仅用作智能合约钱包。幸运的是，由于 ERC-4337 帐户是 DELEGATECALL 代理，因此如果需要，以后可以将钱包转换为与其他 ERC 兼容的智能合约。
关于如何实施此升级过程有一些提案：
1、「replace code」交易类型
这还没有作为正式的 EIP 引入，但方法很简单：添加一个新的 EIP-2718 交易类型，只需将帐户码替换为 calldata。
2、AUTH_USURP (EIP-5003)
EIP-5003 是 EIP-3074（AUTH 和 AUTHCALL）的扩展提案，它引入了新的 AUTHUSURP 操作码。如果使用 EIP-3074 机制，EOA 地址 A 已授权另一个地址 B 代表它行事，则 AUTHUSURP 允许 B 设置 A 的代码。
这种方法比「replace code」路线更复杂，只有当我们打算采用 EIP-3074 时，这才有意义。
在更长远的未来，我们可能希望进行强制转换，以简化协议，并使合约成为唯一的帐户类型，从协议中取消 ECDSA。一种可能的方法是添加一个覆盖规则，从某个区块开始，没有 code 的账户被视为具有特定标准化「ERC-4337 EOA 钱包」code 的账户。
这可以通过「poking」过程来完成，其中任何源自 EOA 的交易都将其转换，并且任何触及具有非零 nonce 的 EOA 交易都会将其转换。也可以一次性通过整个状态来完成。
合约内 ECRECOVER 验证：一些智能合约依赖于这样的假设，即如果你向特定账户提供 ECRECOVER 的签名，你就拥有该账户。如果 EOA 转换为合约，然后更改其验证密钥，则原始密钥仍然能够在这些特定上下文中「代表」帐户。这可通过开始鼓励所有此类项目更改为使用 EIP-1271 验证，而不是在帐户有 code 的情况下使用 ECRECOVER。
尚未检测到的账户：强制转换面临的一个挑战是拥有资产（如 ERC20 s、ERC721 s，但不是 ETH）但尚未发送或接收任何交易的账户，因此协议无法可靠检测到这些账户。协议必须保留将此类账户永久转换为默认钱包的功能，或者需要有一个截止期（例如部署后 4 年），在此之后尚未转换的帐户将被烧毁。
EOA 只检查不可转让性：一些应用程序实施合约内检查以仅允许 EOA 与其交互。这通常是为了强制执行不可转让性。从根本上来说，这是一个坏主意，并且与转向智能合约以提高安全性的目标不相容。因此，不应鼓励这种做法，而应鼓励应用依赖原所有者恢复程序来使转移无法执行。
ERC-4337 钱包面临更高的 gas 成本（基本 ERC-4337 操作约 42000 gas，而基本常规交易需要 21000 gas），原因如下：
1、需要支付大量的单个存储读/写成本，在 EOA 的情况下，这些成本会捆绑到一笔 21000 gas 的付款中：
（1）编辑包含 pubkey+nonce (~5000) 的存储 slot；
（2）用户操作调用数据成本（约 4500，通过压缩可减少到约 2500）；
（3）ECRECOVER (~3000)；
（4）首次访问钱包本身 (~2600)
（5）首次访问收款人账户 (~2600)
（6）将 ETH 转入收款人账户 (~9000)
（7）编辑存储以支付费用（~5000）
（8）访问包含代理 (~2100) 的存储 slot，然后访问代理本身 (~2600)；
2、除了上述存储读/写成本之外，合约还需要执行「业务逻辑」（解包 UserOperation、对其进行哈希、洗牌变量等）
3、需要消耗 gas 来支付日志费用（EOA 不发布日志）；
4、一次性合约创建成本（约 32000 gas，加上代理中每个 code byte 200 gas，再加上设置代理地址的 20000 gas）
其中很多问题将在 Verkle 树 witness gas cost EIP 以及 write gas cost reform EIP 中自动解决，以更精简的系统取代大量存储成本。例如，pubkey 和 nonce 可以存储在 slot 0…63 中，这将访问它们的成本降低到 1000 以下。用户在转移 ETH 和支付费用时支付的费用会更少，因为目标账户和接收账户只需要被首次访问一次。
还有更多的 EIP 可以帮助我们实现简化。例如：
禁止智能合约逻辑使用 slot 0 的自愿 ERC，将允许它用于存储代理，从而使其受益于更便宜的 gas 成本。
「code address」字段可以使代理更轻松，消耗的 gas 更少。
「snappy compression」预编译可以更轻松地使用 ABI 对象，而无需为所有零字节支付 calldata gas 成本。
这是一个需要更多研究的领域。
这是一个长期的问题，因为只有启用了完全的协议提议者/构建者（proposer/builder）分离方案后，crLists 才真正适用。挑战在于，我们希望提议者能够识别「值得」包含的用户操作（即他们支付足够的费用），以便协议可以迫使它们被包含在下一个有空间的区块中。
这要求在协议中明确「验证」和「执行」的概念。对于用户操作，必须有一种已定义的方法来验证该操作，以及有一种已定义的方法来执行该操作，这样如果某个操作被验证，则执行该操作的尝试将是保证支付费用的，除非被读取的状态在验证期间被修改。这些操作可以通过嵌入 ABI 方法来实现，如果实现了 EOF EIP，也可以通过添加专用的 EOF 部分来实现。
幸运的是，这不需要我们把 ERC-4337 当作一个最终标准，而是纳入 ERC-4337 所支持的一个较弱概念，其他在很大程度上不同的 ERC 也可以轻松支持它。
原因是，ERC-4337 和 EIP-2938 的复杂性很大程度上与解决更强的 DoS 抗性问题有关：不可能使一个操作取消数百个其他操作，因为这将允许廉价地对 mempool 进行垃圾交易攻击。这需要对帐户验证可访问的内容施加限制。在这里，我们可以做一些更简单的事情：只记录在验证过程中触摸了哪些状态对象，如果这些状态对象中的任何一个被编辑，则不需要包含。
这使得个人账户可以在审查抵制和灵活性之间选择自己的权衡。在极端情况下，如果账户愿意，可以通过 Uniswap 在验证期间支付费用，但由于任何人都可以发送影响 Uniswap 状态的交易，因此此类账户实际上没有抗审查保证。
crList 设计的大致轮廓如下：
提议可以包含一个 crList，它指定要包含的操作列表，以及每个操作读取的状态对象 (key, value）对的列表。接受 crList 的构建者（或其他任何人）必须检查所有操作是否通过 validate 检查。
执行 crList 中的每个操作都需要该区块，除非该区块没有足够的剩余 gas，或者执行时的当前状态已经编辑了该操作读取的状态对象之一。
ERC-4337 的剩余复杂性将仅用于 mempool 安全。原则上，可以有多个相互竞争的 ERC 以不同的方式实现该目标，只要它们都遵循相同的验证和执行标准。
这种方法的一个缺点是它与签名聚合不完全兼容（正如 ERC-4337 试图做的那样）：因为协议不「理解」聚合方案，它不能强制聚合，恶意构建者可能纳入未聚合的操作，并迫使发送者为其支付全部 gas。但这种不便可以说是适度的。
将 ERC-4337 全面投入生产。理想情况下，可以使用签名聚合功能对其进行扩展，以实现 rollup 友好性。
应该有接入 ERC-4337 的易于使用的浏览器钱包。
考虑实现签名聚合和压缩，以使 ERC-4337 对 L2 更加友好；
在 L2 协议中引导 ERC-4337 生态，其中 gas 成本问题会较少；
实施 Verkle 树，添加 EIP 以降低 gas 成本；
添加可选的 EOA-to-ERC-4337 转换；
在 PBS 推出的同时或不久之后添加 crList 逻辑；
考虑强制转换；
1、考虑编写一个在协议层包含 ERC-4337 等效帐户和交易的 EIP，并推动其在 L2 中的采用；
2、使用一种通过 axuliary 区块工作的抗审查解决方案，消除用户操作对以太坊协议的可读的需要；
账户抽象允许我们使用智能合约逻辑来指定交易的效果，以及费用支付和验证逻辑。这带来了许多重要的安全好处，例如多重签名和智能恢复钱包，能够在不更换钱包的情况下更换密钥以及量子安全性。
许多帐户抽象的方法已在不同程度上被提出并得到了实施，参见：EIP-86、EIP-2938，以及两年前的这篇文章。今天，由于开发者们希望专注于合并与分片，这些 EIP 的开发陷入了僵局，而 ERC-4337 这种不需要任何共识更改的替代方案已经取得了很大进展。
ERC-4337 尝试通过额外的协议手段实现和 EIP-2938 相同的事情。用户需要发送称为用户操作（user operations）的链外消息，这些消息由区块提议者（proposer）或为区块提议者生成 bundles 的构建者（builder）批量收集并打包成单笔交易。提议者或构建者负责过滤操作以确保他们只接受支付费用的操作。用户操作有一个单独的 mempool 存储池，连接到这个存储池的节点会进行 ERC-4337 特定的验证，以确保用户操作在转发之前能够支付费用。
ERC-4337 作为一个纯自愿的 ERC 可以做很多事情。然而，在一些关键领域，它比真正的协议内解决方案更弱：
现有用户如果不将其所有资产和活动移动到新帐户，则无法升级；
额外的 gas 开销（基本 UserOperation 用户操作约 42 k，而基本交易约为 21 k）；
较少受益于协议内抗审查技术（例如 crLists），它以交易为目标并会错过用户操作（user operation）
而实现最佳效果的一条现实途径，是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。这并不一定需要大家专门承诺遵守 ERC-4337。相反，可以将协议内支持设计为更通用，并支持 ERC-4337 及其替代方案和改进。
在这里，我将列出其中的一些 EIP，并说明它们可以按什么顺序实施。
为了让现有的 EOA 钱包升级到 ERC-4337 钱包，我们可以制作一个 EIP，允许 EOA 执行设置其合约代码的操作。一旦 EOA 做到了这一点，这种转变就不可逆转。从那时起，该帐户将仅用作智能合约钱包。幸运的是，由于 ERC-4337 帐户是 DELEGATECALL 代理，因此如果需要，以后可以将钱包转换为与其他 ERC 兼容的智能合约。
关于如何实施此升级过程有一些提案：
1、「replace code」交易类型
这还没有作为正式的 EIP 引入，但方法很简单：添加一个新的 EIP-2718 交易类型，只需将帐户码替换为 calldata。
2、AUTH_USURP (EIP-5003)
EIP-5003 是 EIP-3074（AUTH 和 AUTHCALL）的扩展提案，它引入了新的 AUTHUSURP 操作码。如果使用 EIP-3074 机制，EOA 地址 A 已授权另一个地址 B 代表它行事，则 AUTHUSURP 允许 B 设置 A 的代码。
这种方法比「replace code」路线更复杂，只有当我们打算采用 EIP-3074 时，这才有意义。
在更长远的未来，我们可能希望进行强制转换，以简化协议，并使合约成为唯一的帐户类型，从协议中取消 ECDSA。一种可能的方法是添加一个覆盖规则，从某个区块开始，没有 code 的账户被视为具有特定标准化「ERC-4337 EOA 钱包」code 的账户。
这可以通过「poking」过程来完成，其中任何源自 EOA 的交易都将其转换，并且任何触及具有非零 nonce 的 EOA 交易都会将其转换。也可以一次性通过整个状态来完成。
合约内 ECRECOVER 验证：一些智能合约依赖于这样的假设，即如果你向特定账户提供 ECRECOVER 的签名，你就拥有该账户。如果 EOA 转换为合约，然后更改其验证密钥，则原始密钥仍然能够在这些特定上下文中「代表」帐户。这可通过开始鼓励所有此类项目更改为使用 EIP-1271 验证，而不是在帐户有 code 的情况下使用 ECRECOVER。
尚未检测到的账户：强制转换面临的一个挑战是拥有资产（如 ERC20 s、ERC721 s，但不是 ETH）但尚未发送或接收任何交易的账户，因此协议无法可靠检测到这些账户。协议必须保留将此类账户永久转换为默认钱包的功能，或者需要有一个截止期（例如部署后 4 年），在此之后尚未转换的帐户将被烧毁。
EOA 只检查不可转让性：一些应用程序实施合约内检查以仅允许 EOA 与其交互。这通常是为了强制执行不可转让性。从根本上来说，这是一个坏主意，并且与转向智能合约以提高安全性的目标不相容。因此，不应鼓励这种做法，而应鼓励应用依赖原所有者恢复程序来使转移无法执行。
ERC-4337 钱包面临更高的 gas 成本（基本 ERC-4337 操作约 42000 gas，而基本常规交易需要 21000 gas），原因如下：
1、需要支付大量的单个存储读/写成本，在 EOA 的情况下，这些成本会捆绑到一笔 21000 gas 的付款中：
（1）编辑包含 pubkey+nonce (~5000) 的存储 slot；
（2）用户操作调用数据成本（约 4500，通过压缩可减少到约 2500）；
（3）ECRECOVER (~3000)；
（4）首次访问钱包本身 (~2600)
（5）首次访问收款人账户 (~2600)
（6）将 ETH 转入收款人账户 (~9000)
（7）编辑存储以支付费用（~5000）
（8）访问包含代理 (~2100) 的存储 slot，然后访问代理本身 (~2600)；
2、除了上述存储读/写成本之外，合约还需要执行「业务逻辑」（解包 UserOperation、对其进行哈希、洗牌变量等）
3、需要消耗 gas 来支付日志费用（EOA 不发布日志）；
4、一次性合约创建成本（约 32000 gas，加上代理中每个 code byte 200 gas，再加上设置代理地址的 20000 gas）
其中很多问题将在 Verkle 树 witness gas cost EIP 以及 write gas cost reform EIP 中自动解决，以更精简的系统取代大量存储成本。例如，pubkey 和 nonce 可以存储在 slot 0…63 中，这将访问它们的成本降低到 1000 以下。用户在转移 ETH 和支付费用时支付的费用会更少，因为目标账户和接收账户只需要被首次访问一次。
还有更多的 EIP 可以帮助我们实现简化。例如：
禁止智能合约逻辑使用 slot 0 的自愿 ERC，将允许它用于存储代理，从而使其受益于更便宜的 gas 成本。
「code address」字段可以使代理更轻松，消耗的 gas 更少。
「snappy compression」预编译可以更轻松地使用 ABI 对象，而无需为所有零字节支付 calldata gas 成本。
这是一个需要更多研究的领域。
这是一个长期的问题，因为只有启用了完全的协议提议者/构建者（proposer/builder）分离方案后，crLists 才真正适用。挑战在于，我们希望提议者能够识别「值得」包含的用户操作（即他们支付足够的费用），以便协议可以迫使它们被包含在下一个有空间的区块中。
这要求在协议中明确「验证」和「执行」的概念。对于用户操作，必须有一种已定义的方法来验证该操作，以及有一种已定义的方法来执行该操作，这样如果某个操作被验证，则执行该操作的尝试将是保证支付费用的，除非被读取的状态在验证期间被修改。这些操作可以通过嵌入 ABI 方法来实现，如果实现了 EOF EIP，也可以通过添加专用的 EOF 部分来实现。
幸运的是，这不需要我们把 ERC-4337 当作一个最终标准，而是纳入 ERC-4337 所支持的一个较弱概念，其他在很大程度上不同的 ERC 也可以轻松支持它。
原因是，ERC-4337 和 EIP-2938 的复杂性很大程度上与解决更强的 DoS 抗性问题有关：不可能使一个操作取消数百个其他操作，因为这将允许廉价地对 mempool 进行垃圾交易攻击。这需要对帐户验证可访问的内容施加限制。在这里，我们可以做一些更简单的事情：只记录在验证过程中触摸了哪些状态对象，如果这些状态对象中的任何一个被编辑，则不需要包含。
这使得个人账户可以在审查抵制和灵活性之间选择自己的权衡。在极端情况下，如果账户愿意，可以通过 Uniswap 在验证期间支付费用，但由于任何人都可以发送影响 Uniswap 状态的交易，因此此类账户实际上没有抗审查保证。
crList 设计的大致轮廓如下：
提议可以包含一个 crList，它指定要包含的操作列表，以及每个操作读取的状态对象 (key, value）对的列表。接受 crList 的构建者（或其他任何人）必须检查所有操作是否通过 validate 检查。
执行 crList 中的每个操作都需要该区块，除非该区块没有足够的剩余 gas，或者执行时的当前状态已经编辑了该操作读取的状态对象之一。
ERC-4337 的剩余复杂性将仅用于 mempool 安全。原则上，可以有多个相互竞争的 ERC 以不同的方式实现该目标，只要它们都遵循相同的验证和执行标准。
这种方法的一个缺点是它与签名聚合不完全兼容（正如 ERC-4337 试图做的那样）：因为协议不「理解」聚合方案，它不能强制聚合，恶意构建者可能纳入未聚合的操作，并迫使发送者为其支付全部 gas。但这种不便可以说是适度的。
将 ERC-4337 全面投入生产。理想情况下，可以使用签名聚合功能对其进行扩展，以实现 rollup 友好性。
应该有接入 ERC-4337 的易于使用的浏览器钱包。
考虑实现签名聚合和压缩，以使 ERC-4337 对 L2 更加友好；
在 L2 协议中引导 ERC-4337 生态，其中 gas 成本问题会较少；
实施 Verkle 树，添加 EIP 以降低 gas 成本；
添加可选的 EOA-to-ERC-4337 转换；
在 PBS 推出的同时或不久之后添加 crList 逻辑；
考虑强制转换；
1、考虑编写一个在协议层包含 ERC-4337 等效帐户和交易的 EIP，并推动其在 L2 中的采用；
2、使用一种通过 axuliary 区块工作的抗审查解决方案，消除用户操作对以太坊协议的可读的需要；
No activity yet