拓冰网站定制 
EIP-1102 主动选择账户暴露Opt-in Account Exposuredapp 与以太坊浏览器环境的账户授权协议全解析【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-1102 是 Ethereum Improvement Proposal 仓库EIPS 目录中一份 Interface 类标准草案它定义了一套 dapp去中心化应用与启用以太坊的 DOM 环境即注入window.ethereumprovider 的浏览器钱包如 MetaMask之间的通信协议在用户批准之前环境可以选择不向任何网站暴露任何账户。本文以 EIPS/eip-1102.md 为主体结合同仓库的 EIP-1193 Provider API、EIP-1474 RPC 规范 与 EIP-2255 钱包权限系统完整梳理该协议的背景动机、eth_requestAccounts方法定义、dapp 初始化流程、实现约束及其在后续标准中的演进。读完本文你将掌握现代以太坊 dapp 连接钱包 的底层协议原理并能正确实现基于eth_requestAccounts的账户授权流程。一、背景为什么需要主动选择的账户暴露在 EIP-1102 提出之前约 2018 年上一代启用以太坊的浏览器环境遵循一种固定模式在页面加载时向window.ethereum注入一个已经填充好用户账户的 provider全程不经过用户同意。这类环境包括早期的 Mist 等浏览器。这种自动暴露模式存在两个层面的安全风险隐私风险恶意网站无需任何授权即可查看用户的详细账户信息地址列表、余额、交易历史等可用于跟踪、指纹识别甚至钓鱼。交易风险恶意网站可以借已注入的账户任意发起未经请求的交易例如通过eth_sendTransaction在用户不知情的情况下转移资产或触发合约操作。EIP-1102 的摘要明确指出该协议让启用以太坊的 DOM 环境在用户批准账户访问之前选择不暴露任何账户。也就是说账户访问的主动权从网站自动获得转变为用户显式授予。二、核心概念与方法定义EIP-1102 的规范部分首先确立了文档用语遵循 RFC-2119 中 MUST / MUST NOT / SHOULD / MAY 等关键词的语义随后定义了协议的核心入口。2.1eth_requestAccounts协议的主方法由启用以太坊的 DOM 环境暴露的 provider 需定义一个新的 RPC 方法eth_requestAccounts。调用该方法可能触发一个用户界面让用户针对当前 dapp 批准或拒绝账户访问。该方法返回一个Promise解析resolve时携带一个账户数组Arraystring若账户不可用例如用户拒绝了访问则以Error拒绝reject。规范给出的类型签名如下ethereum.send(eth_requestAccounts): PromiseArraystring注意该签名出现在 2018 年的 EIP-1102 中当时使用的是早期 provider 的send调用约定后续 provider API 的演进如 EIP-1193 的request({ method, params })改变了调用形式但方法名eth_requestAccounts被完整保留并成为事实标准。2.2Provider#enable()已废弃的等价入口EIP-1102 同时定义了ethereum.enable()方法调用它会触发相同的用户批准/拒绝界面同样返回Promise用户批准时解析为账户数组拒绝时以Error拒绝。ethereum.enable(): Promiseany注意该文档明确标注此方法已废弃DEPRECATED应优先使用 RPC 方法eth_requestAccounts。这也是钱包生态中后来enable()被逐步淘汰的规范源头。三、协议流程从自动注入到先请求后使用EIP-1102 用伪代码对比了旧式与新式的 dapp 初始化流程这是理解协议的关键。3.1 旧式 dapp 初始化LegacySTART dapp IF web3 is defined CONTINUE dapp IF web3 is undefined STOP dapp旧式流程只判断web3对象是否存在只要web3存在dapp 就直接继续运行——而该对象内已经预置了账户。网站无需任何询问即可读取账户并发起交易。3.2 新式 dapp 初始化ProposedSTART dapp IF provider is defined REQUEST[1] account access IF user approves RESOLVE[2] account access CONTINUE dapp IF user rejects REJECT[3] account access STOP dapp IF provider is undefined STOP dapp新式流程中dapp 必须先显式请求账户访问并根据用户的批准结果决定是否继续[1] REQUESTdapp必须MUST通过调用暴露在window.ethereum上的 provider 的eth_requestAccountsRPC 方法来请求账户。此调用可能MAY触发允许用户批准或拒绝账户访问的用户界面。该方法必须返回一个Promise解析为包含一个或多个用户账户的数组或在没有可用账户例如用户拒绝了访问时拒绝。[2] RESOLVEeth_requestAccounts返回的Promise必须以用户账户数组解析。[3] REJECT如果因任何原因没有可用账户eth_requestAccounts返回的Promise必须以一个信息充分的Error拒绝。这套请求 → 批准 → 继续 / 拒绝 → 停止的状态机是后来所有钱包连接弹窗交互的规范原型。3.3 示例初始化代码规范给出了完整的 JavaScript 示例try { // Request account access if needed const accounts await ethereum.send(eth_requestAccounts); // Accounts now exposed, use them ethereum.send(eth_sendTransaction, { from: accounts[0], /* ... */ }) } catch (error) { // User denied account access }流程要点先调用eth_requestAccounts请求账户访问可能弹出授权界面拿到accounts数组后再使用账户发起eth_sendTransaction若用户拒绝Promise 被拒绝代码进入catch分支——dapp 应在此优雅降级例如提示用户授权后才能使用。在现代 EIP-1193 provider 中同样的逻辑通常写作const accounts await window.ethereum.request({ method: eth_requestAccounts });四、对浏览器环境的约束ConstraintsEIP-1102 对启用以太坊的 DOM 环境浏览器/钱包扩展提出了明确的规范约束原文逐条列出浏览器必须MUST在window.ethereum上暴露一个 provider。浏览器必须MUST定义eth_requestAccountsRPC 方法。浏览器可以MAY在解析/拒绝eth_requestAccounts的 promise 之前等待一次用户交互。如果eth_requestAccounts的 promise 被解析浏览器必须至少包含一个账户。如果没有可用账户浏览器必须以一个信息充分的错误拒绝该 promise。这些约束共同保证了协议的不变量未获用户批准时零账户可见一旦批准则至少返回一个账户拒绝路径必须有可诊断的错误信息。五、Rationale协议的设计动机与价值EIP-1102 的 Rationale 部分解释了为何要改变既有模式上一代环境自动暴露账户的模式未能保护用户隐私也未能维持安全的用户体验不受信任的网站既能查看详细的账户信息又能任意代表用户发起交易。尽管大多数用户可能会拒绝不受信任网站上的未经请求的交易但一个账户访问协议应当让这种未经请求的请求在机制上不可能发生。该提案确立的新模式是dapp 必须请求访问用户账户。这直接强化了用户隐私——浏览器可以隐藏用户账户并阻止不受信任网站上未经请求的交易请求。5.1 即时价值Immediate value-add用户可以在不受信任的网站上拒绝账户访问从而隐藏账户。用户可以在不受信任的网站上拒绝账户访问从而阻止未经请求的交易。5.2 长期价值Long-term value-adddapp 可以基于用户同意请求特定的账户信息。dapp 可以基于用户同意请求特定的用户信息如 uPort、DID 等去中心化身份。dapp 可以基于用户同意请求特定的网络。dapp 可以基于用户同意请求上述多种能力的组合。这一按需请求、用户授权的思想正是后来 EIP-2255 钱包权限系统wallet_requestPermissions/wallet_getPermissions的雏形——从一次性授权全部账户演进为可细粒度、带 caveats 约束的权限请求。六、与仓库其他 EIP 的关系协议在生态中的位置EIP-1102 并非孤立存在它与 EIPs 仓库中的多份标准紧密耦合共同构成现代以太坊钱包连接栈。6.1 依赖 EIP-1474RPC 方法规范EIP-1102 的 front matter 声明requires: 1474。EIP-1474 是 Ethereum JSON-RPC 方法规范定义了eth_accounts、eth_sendTransaction、eth_chainId等方法的参数、返回值和错误码约定。eth_requestAccounts作为 provider 层的新方法建立在 EIP-1474 所规范的 JSON-RPC 通信语义之上——例如eth_accounts返回此客户端拥有的地址列表而eth_requestAccounts则负责在返回账户前先取得用户同意。6.2 被 EIP-1193 引用与继承Provider APIEIP-1193Ethereum Provider JavaScript APIFinal 状态在安全考量——用户账户暴露与账户变更一节中明确建议为保护用户隐私默认不应暴露任何账户而应支持用于显式请求账户访问的 RPC 方法如eth_requestAccounts见 EIP-1102或wallet_requestPermissions见 EIP-2255。同时EIP-1193 定义了与账户授权直接相关的错误码dapp 在实现 EIP-1102 流程时应当识别| 状态码 | 名称 | 说明 | | - | - | - | | 4001 | User Rejected Request | 用户拒绝了请求例如拒绝了账户授权弹窗 | | 4100 | Unauthorized | 请求的方法和/或账户尚未获得用户授权 |当用户点击拒绝时provider 应抛出code: 4001的ProviderRpcErrordapp 据此在catch分支中区分用户主动拒绝与其他错误。6.3 与 EIP-2255 的演进关系从单一授权到权限系统EIP-2255Final引入了wallet_getPermissions与wallet_requestPermissions将 EIP-1102 的请求账户泛化为请求任意敏感方法的权限并支持 caveats限制条件如过期时间、限定方法。两者可视为同一设计哲学的两代实现EIP-1102 解决默认零账户 显式请求的隐私基线EIP-2255 解决授权一次、复用多次 可衰减的用户体验问题。6.4 后续演进多钱包与命名空间EIP-1102 规定的window.ethereum单点注入在生态发展中暴露出多钱包竞态问题EIP-6963 提出用window事件机制替代window.ethereum命名空间实现多钱包发现同时建议钱包保留window.ethereum兼容EIP-5749 提出window.evmproviders方案EIP-5593 则要求仅在高安全上下文secure context中注入 provider。这些提案均以 EIP-1102/EIP-1193 定义的 provider 形态为基础属于协议栈的演进而非替代。七、向后兼容与实现现状7.1 向后兼容Backwards compatibilityEIP-1102 明确指出该提案的兼容性影响对dapp 开发者必须按照上述协议请求访问用户账户不能再假设页面加载即可读取账户对dapp 浏览器钱包开发者必须只按上述协议暴露用户账户未获用户批准时不得自动填充账户。这意味着一处契约的双向变更dapp 侧从被动读取改为主动请求钱包侧从自动注入改为按需授权。7.2 实现与状态EIP-1102 的 front matter 记录其状态为Stagnant停滞类型为 Standards Track / Interface创建于 2018-05-04作者为 Paul Bouchon 与 Erik Marks。文档的 Implementation 一节记录MetaMask 团队实现了上述策略。尽管该 EIP 文档本身处于停滞状态但其核心方法eth_requestAccounts通过 EIP-1193 的推荐和各大钱包的广泛实现实际上成为以太坊 dapp 连接钱包 的事实标准调用方式并持续至今。八、协议要点速查与实践清单面向 dapp 开发者将 EIP-1102 的规范落为可执行的实现清单不要假设账户已可用页面加载后默认账户列表为空任何账户读取都必须先经过授权流程。统一入口通过window.ethereum或按 EIP-6963 发现机制获得的 provider调用eth_requestAccounts。处理批准与拒绝Promise 解析为账户数组至少一个账户后继续业务拒绝时现代 provider 对应4001错误给出用户可理解的提示并停止后续交易操作。废弃enable()不要使用已废弃的ethereum.enable()统一使用eth_requestAccounts。隐私优先将用户不授权则不暴露任何账户视为钱包与 dapp 双方共同遵守的契约。九、总结EIP-1102 是以太坊账户访问需用户显式同意这一原则的规范源头。它以eth_requestAccounts为核心通过先请求、后使用拒绝即停止的协议流程终结了上一代浏览器环境自动暴露账户的隐私与安全缺陷。今天主流 dapp 中点击连接钱包 → 弹出授权 → 获取账户的交互范式正是 EIP-1102 所定义协议的延续其思想经由 EIP-1193 的 Provider API、EIP-2255 的权限系统以及 EIP-6963 的多钱包发现机制不断演进构成了以太坊 Web3 应用安全交互的基石。该文档版权以 CC0 放弃遵循仓库 LICENSE.md 约定可在 EIPS/eip-1102.md 查看全文规范。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-1102 主动选择账户暴露（Opt-in Account Exposure）：dapp 与以太坊浏览器环境的账户授权协议全解析
EIP-1102 主动选择账户暴露Opt-in Account Exposuredapp 与以太坊浏览器环境的账户授权协议全解析【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-1102 是 Ethereum Improvement Proposal 仓库EIPS 目录中一份 Interface 类标准草案它定义了一套 dapp去中心化应用与启用以太坊的 DOM 环境即注入window.ethereumprovider 的浏览器钱包如 MetaMask之间的通信协议在用户批准之前环境可以选择不向任何网站暴露任何账户。本文以 EIPS/eip-1102.md 为主体结合同仓库的 EIP-1193 Provider API、EIP-1474 RPC 规范 与 EIP-2255 钱包权限系统完整梳理该协议的背景动机、eth_requestAccounts方法定义、dapp 初始化流程、实现约束及其在后续标准中的演进。读完本文你将掌握现代以太坊 dapp 连接钱包 的底层协议原理并能正确实现基于eth_requestAccounts的账户授权流程。一、背景为什么需要主动选择的账户暴露在 EIP-1102 提出之前约 2018 年上一代启用以太坊的浏览器环境遵循一种固定模式在页面加载时向window.ethereum注入一个已经填充好用户账户的 provider全程不经过用户同意。这类环境包括早期的 Mist 等浏览器。这种自动暴露模式存在两个层面的安全风险隐私风险恶意网站无需任何授权即可查看用户的详细账户信息地址列表、余额、交易历史等可用于跟踪、指纹识别甚至钓鱼。交易风险恶意网站可以借已注入的账户任意发起未经请求的交易例如通过eth_sendTransaction在用户不知情的情况下转移资产或触发合约操作。EIP-1102 的摘要明确指出该协议让启用以太坊的 DOM 环境在用户批准账户访问之前选择不暴露任何账户。也就是说账户访问的主动权从网站自动获得转变为用户显式授予。二、核心概念与方法定义EIP-1102 的规范部分首先确立了文档用语遵循 RFC-2119 中 MUST / MUST NOT / SHOULD / MAY 等关键词的语义随后定义了协议的核心入口。2.1eth_requestAccounts协议的主方法由启用以太坊的 DOM 环境暴露的 provider 需定义一个新的 RPC 方法eth_requestAccounts。调用该方法可能触发一个用户界面让用户针对当前 dapp 批准或拒绝账户访问。该方法返回一个Promise解析resolve时携带一个账户数组Arraystring若账户不可用例如用户拒绝了访问则以Error拒绝reject。规范给出的类型签名如下ethereum.send(eth_requestAccounts): PromiseArraystring注意该签名出现在 2018 年的 EIP-1102 中当时使用的是早期 provider 的send调用约定后续 provider API 的演进如 EIP-1193 的request({ method, params })改变了调用形式但方法名eth_requestAccounts被完整保留并成为事实标准。2.2Provider#enable()已废弃的等价入口EIP-1102 同时定义了ethereum.enable()方法调用它会触发相同的用户批准/拒绝界面同样返回Promise用户批准时解析为账户数组拒绝时以Error拒绝。ethereum.enable(): Promiseany注意该文档明确标注此方法已废弃DEPRECATED应优先使用 RPC 方法eth_requestAccounts。这也是钱包生态中后来enable()被逐步淘汰的规范源头。三、协议流程从自动注入到先请求后使用EIP-1102 用伪代码对比了旧式与新式的 dapp 初始化流程这是理解协议的关键。3.1 旧式 dapp 初始化LegacySTART dapp IF web3 is defined CONTINUE dapp IF web3 is undefined STOP dapp旧式流程只判断web3对象是否存在只要web3存在dapp 就直接继续运行——而该对象内已经预置了账户。网站无需任何询问即可读取账户并发起交易。3.2 新式 dapp 初始化ProposedSTART dapp IF provider is defined REQUEST[1] account access IF user approves RESOLVE[2] account access CONTINUE dapp IF user rejects REJECT[3] account access STOP dapp IF provider is undefined STOP dapp新式流程中dapp 必须先显式请求账户访问并根据用户的批准结果决定是否继续[1] REQUESTdapp必须MUST通过调用暴露在window.ethereum上的 provider 的eth_requestAccountsRPC 方法来请求账户。此调用可能MAY触发允许用户批准或拒绝账户访问的用户界面。该方法必须返回一个Promise解析为包含一个或多个用户账户的数组或在没有可用账户例如用户拒绝了访问时拒绝。[2] RESOLVEeth_requestAccounts返回的Promise必须以用户账户数组解析。[3] REJECT如果因任何原因没有可用账户eth_requestAccounts返回的Promise必须以一个信息充分的Error拒绝。这套请求 → 批准 → 继续 / 拒绝 → 停止的状态机是后来所有钱包连接弹窗交互的规范原型。3.3 示例初始化代码规范给出了完整的 JavaScript 示例try { // Request account access if needed const accounts await ethereum.send(eth_requestAccounts); // Accounts now exposed, use them ethereum.send(eth_sendTransaction, { from: accounts[0], /* ... */ }) } catch (error) { // User denied account access }流程要点先调用eth_requestAccounts请求账户访问可能弹出授权界面拿到accounts数组后再使用账户发起eth_sendTransaction若用户拒绝Promise 被拒绝代码进入catch分支——dapp 应在此优雅降级例如提示用户授权后才能使用。在现代 EIP-1193 provider 中同样的逻辑通常写作const accounts await window.ethereum.request({ method: eth_requestAccounts });四、对浏览器环境的约束ConstraintsEIP-1102 对启用以太坊的 DOM 环境浏览器/钱包扩展提出了明确的规范约束原文逐条列出浏览器必须MUST在window.ethereum上暴露一个 provider。浏览器必须MUST定义eth_requestAccountsRPC 方法。浏览器可以MAY在解析/拒绝eth_requestAccounts的 promise 之前等待一次用户交互。如果eth_requestAccounts的 promise 被解析浏览器必须至少包含一个账户。如果没有可用账户浏览器必须以一个信息充分的错误拒绝该 promise。这些约束共同保证了协议的不变量未获用户批准时零账户可见一旦批准则至少返回一个账户拒绝路径必须有可诊断的错误信息。五、Rationale协议的设计动机与价值EIP-1102 的 Rationale 部分解释了为何要改变既有模式上一代环境自动暴露账户的模式未能保护用户隐私也未能维持安全的用户体验不受信任的网站既能查看详细的账户信息又能任意代表用户发起交易。尽管大多数用户可能会拒绝不受信任网站上的未经请求的交易但一个账户访问协议应当让这种未经请求的请求在机制上不可能发生。该提案确立的新模式是dapp 必须请求访问用户账户。这直接强化了用户隐私——浏览器可以隐藏用户账户并阻止不受信任网站上未经请求的交易请求。5.1 即时价值Immediate value-add用户可以在不受信任的网站上拒绝账户访问从而隐藏账户。用户可以在不受信任的网站上拒绝账户访问从而阻止未经请求的交易。5.2 长期价值Long-term value-adddapp 可以基于用户同意请求特定的账户信息。dapp 可以基于用户同意请求特定的用户信息如 uPort、DID 等去中心化身份。dapp 可以基于用户同意请求特定的网络。dapp 可以基于用户同意请求上述多种能力的组合。这一按需请求、用户授权的思想正是后来 EIP-2255 钱包权限系统wallet_requestPermissions/wallet_getPermissions的雏形——从一次性授权全部账户演进为可细粒度、带 caveats 约束的权限请求。六、与仓库其他 EIP 的关系协议在生态中的位置EIP-1102 并非孤立存在它与 EIPs 仓库中的多份标准紧密耦合共同构成现代以太坊钱包连接栈。6.1 依赖 EIP-1474RPC 方法规范EIP-1102 的 front matter 声明requires: 1474。EIP-1474 是 Ethereum JSON-RPC 方法规范定义了eth_accounts、eth_sendTransaction、eth_chainId等方法的参数、返回值和错误码约定。eth_requestAccounts作为 provider 层的新方法建立在 EIP-1474 所规范的 JSON-RPC 通信语义之上——例如eth_accounts返回此客户端拥有的地址列表而eth_requestAccounts则负责在返回账户前先取得用户同意。6.2 被 EIP-1193 引用与继承Provider APIEIP-1193Ethereum Provider JavaScript APIFinal 状态在安全考量——用户账户暴露与账户变更一节中明确建议为保护用户隐私默认不应暴露任何账户而应支持用于显式请求账户访问的 RPC 方法如eth_requestAccounts见 EIP-1102或wallet_requestPermissions见 EIP-2255。同时EIP-1193 定义了与账户授权直接相关的错误码dapp 在实现 EIP-1102 流程时应当识别| 状态码 | 名称 | 说明 | | - | - | - | | 4001 | User Rejected Request | 用户拒绝了请求例如拒绝了账户授权弹窗 | | 4100 | Unauthorized | 请求的方法和/或账户尚未获得用户授权 |当用户点击拒绝时provider 应抛出code: 4001的ProviderRpcErrordapp 据此在catch分支中区分用户主动拒绝与其他错误。6.3 与 EIP-2255 的演进关系从单一授权到权限系统EIP-2255Final引入了wallet_getPermissions与wallet_requestPermissions将 EIP-1102 的请求账户泛化为请求任意敏感方法的权限并支持 caveats限制条件如过期时间、限定方法。两者可视为同一设计哲学的两代实现EIP-1102 解决默认零账户 显式请求的隐私基线EIP-2255 解决授权一次、复用多次 可衰减的用户体验问题。6.4 后续演进多钱包与命名空间EIP-1102 规定的window.ethereum单点注入在生态发展中暴露出多钱包竞态问题EIP-6963 提出用window事件机制替代window.ethereum命名空间实现多钱包发现同时建议钱包保留window.ethereum兼容EIP-5749 提出window.evmproviders方案EIP-5593 则要求仅在高安全上下文secure context中注入 provider。这些提案均以 EIP-1102/EIP-1193 定义的 provider 形态为基础属于协议栈的演进而非替代。七、向后兼容与实现现状7.1 向后兼容Backwards compatibilityEIP-1102 明确指出该提案的兼容性影响对dapp 开发者必须按照上述协议请求访问用户账户不能再假设页面加载即可读取账户对dapp 浏览器钱包开发者必须只按上述协议暴露用户账户未获用户批准时不得自动填充账户。这意味着一处契约的双向变更dapp 侧从被动读取改为主动请求钱包侧从自动注入改为按需授权。7.2 实现与状态EIP-1102 的 front matter 记录其状态为Stagnant停滞类型为 Standards Track / Interface创建于 2018-05-04作者为 Paul Bouchon 与 Erik Marks。文档的 Implementation 一节记录MetaMask 团队实现了上述策略。尽管该 EIP 文档本身处于停滞状态但其核心方法eth_requestAccounts通过 EIP-1193 的推荐和各大钱包的广泛实现实际上成为以太坊 dapp 连接钱包 的事实标准调用方式并持续至今。八、协议要点速查与实践清单面向 dapp 开发者将 EIP-1102 的规范落为可执行的实现清单不要假设账户已可用页面加载后默认账户列表为空任何账户读取都必须先经过授权流程。统一入口通过window.ethereum或按 EIP-6963 发现机制获得的 provider调用eth_requestAccounts。处理批准与拒绝Promise 解析为账户数组至少一个账户后继续业务拒绝时现代 provider 对应4001错误给出用户可理解的提示并停止后续交易操作。废弃enable()不要使用已废弃的ethereum.enable()统一使用eth_requestAccounts。隐私优先将用户不授权则不暴露任何账户视为钱包与 dapp 双方共同遵守的契约。九、总结EIP-1102 是以太坊账户访问需用户显式同意这一原则的规范源头。它以eth_requestAccounts为核心通过先请求、后使用拒绝即停止的协议流程终结了上一代浏览器环境自动暴露账户的隐私与安全缺陷。今天主流 dapp 中点击连接钱包 → 弹出授权 → 获取账户的交互范式正是 EIP-1102 所定义协议的延续其思想经由 EIP-1193 的 Provider API、EIP-2255 的权限系统以及 EIP-6963 的多钱包发现机制不断演进构成了以太坊 Web3 应用安全交互的基石。该文档版权以 CC0 放弃遵循仓库 LICENSE.md 约定可在 EIPS/eip-1102.md 查看全文规范。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考