企业官网建设流程全解析

EIP-779 深度解读：以太坊 DAO 硬分叉（DAO Fork）Meta EIP 完整规范

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

导读：EIP-779 是以太坊历史上最特殊的一次网络升级——DAO Fork 的官方 Meta EIP。它不修改任何协议规则（EVM 操作码、交易格式、区块结构全部不变），而是通过一次"不规则状态变更"将 DAO 及其子合约中的以太币余额定向转移至 WithdrawDAO 合约。本文以 EIPS/eip-779.md 为骨架，结合本仓库中其他 Meta EIP 与相关文档，完整还原该硬分叉的激活条件、账户清单、合约字节码与区块头约束，帮助你从协议规范层面理解这次历史性升级的每一个细节。

一、背景：什么是 Hardfork Meta EIP

在以太坊 EIP 体系中，Meta EIP 描述的是围绕以太坊本身的过程或事件，而非直接修改协议。根据 EIPS/eip-1.md 的定义，Meta EIP 常被用来记录"一次网络升级（硬分叉）包含了哪些变更"，因此也被称为 Hardfork Meta EIP。EIPS/eip-233.md 进一步规范了这类 Meta EIP 的正式流程：硬分叉一旦提上日程就应立即创建 Draft 状态的 Meta EIP，其中包含硬分叉代号、激活区块号、时间线以及拟纳入的 EIP 列表；分叉激活后，该 Meta EIP 应进入 Final 状态。

本仓库中的同类文档可以帮你建立坐标系：

• EIPS/eip-606.md——Homestead 硬分叉 Meta EIP，EIP-779 在requires字段中声明依赖它（即 DAO Fork 建立在 Homestead 之后的协议基础上）；
• EIPS/eip-608.md——Tangerine Whistle（EIP-150）硬分叉 Meta EIP，其requires: 150, 779反向引用了 EIP-779；
• EIPS/eip-7568.md——柏林到 Shapella 的硬分叉 Meta 回填文档，说明了 Meta EIP 在以太坊升级记录中的延续价值。

而 EIP-779 的特殊之处在于：它是唯一一个不以"纳入哪些 EIP"为核心内容的硬分叉 Meta EIP——DAO Fork 根本没有改变协议，它改变的只有链上状态本身。

二、EIP-779 概览：元数据与定位

先看该 EIP 的头部前置信息（preamble）：

摘要（Abstract）给出了一句话定性：

与其它硬分叉不同，DAO Fork 没有改变协议；所有 EVM 操作码、交易格式、区块结构等均保持不变。DAO Fork 是一次"不规则状态变更"（irregular state change），将一批账户（"child DAO" 合约）中的以太币余额转移到指定账户（WithdrawDAO 合约）。

"不规则状态变更"是理解这次升级的关键概念：常规硬分叉通过修改客户端代码来改变规则（例如某个操作码的 Gas 成本、某条交易的有效性条件），而 DAO Fork 直接对**世界状态（world state）**动手——在某一区块高度，把特定一组地址的余额按照预先确定的规则改写。规则没有变，变的是状态；这正是它不需要改动任何 EVM 语义、却能引起链分叉（最终分裂出 ETC 与 ETH）的原因。

三、核心规范：激活条件与账户清单 L

3.1 激活条件

- Codename: DAO Fork - Activation: - Block == 1,920,000 on Mainnet

主网第 1,920,000 个区块是 DAO Fork 的精确激活点。原文指出，更完整的原始规范见其 References 中列出的 slock.it 博客《Hard Fork Specification》与以太坊基金会博客《To Fork or Not to Fork》两篇文章，EIP-779 本身是对该规范的便捷摘要。

3.2 账户清单 L 的构成规则

在区块 1,880,000 处，以下四类账户被编码进清单L：

• The DAO：0xbb9bc244d798123fde783fcc1c72d3bb8c189413（DAO 主合约）
• 其 extraBalance：0x807640a13483f8ac783c557fcdf27be11ea4ac7a（DAO 的附加余额合约）
• DAO 创建者的所有子合约（child DAO）：创建者地址为0x4a574510c7014e4ae985403536074abe582adfc8，其下所有通过 split 操作产生的子 DAO 均被纳入
• 每个子合约的 extraBalance：每个子 DAO 同样配有对应的 extraBalance 账户

原文在<details>折叠块中给出了完整的参考清单 L（共 113 个地址），为保证规范的可追溯性，此处完整保留：

0xd4fe7bc31cedb7bfb8a345f31e668033056b2728, 0xb3fb0e5aba0e20e5c49d252dfd30e102b171a425, 0x2c19c7f9ae8b751e37aeb2d93a699722395ae18f, 0xecd135fa4f61a655311e86238c92adcd779555d2, 0x1975bd06d486162d5dc297798dfc41edd5d160a7, 0xa3acf3a1e16b1d7c315e23510fdd7847b48234f6, 0x319f70bab6845585f412ec7724b744fec6095c85, 0x06706dd3f2c9abf0a21ddcc6941d9b86f0596936, 0x5c8536898fbb74fc7445814902fd08422eac56d0, 0x6966ab0d485353095148a2155858910e0965b6f9, 0x779543a0491a837ca36ce8c635d6154e3c4911a6, 0x2a5ed960395e2a49b1c758cef4aa15213cfd874c, 0x5c6e67ccd5849c0d29219c4f95f1a7a93b3f5dc5, 0x9c50426be05db97f5d64fc54bf89eff947f0a321, 0x200450f06520bdd6c527622a273333384d870efb, 0xbe8539bfe837b67d1282b2b1d61c3f723966f049, 0x6b0c4d41ba9ab8d8cfb5d379c69a612f2ced8ecb, 0xf1385fb24aad0cd7432824085e42aff90886fef5, 0xd1ac8b1ef1b69ff51d1d401a476e7e612414f091, 0x8163e7fb499e90f8544ea62bbf80d21cd26d9efd, 0x51e0ddd9998364a2eb38588679f0d2c42653e4a6, 0x627a0a960c079c21c34f7612d5d230e01b4ad4c7, 0xf0b1aa0eb660754448a7937c022e30aa692fe0c5, 0x24c4d950dfd4dd1902bbed3508144a54542bba94, 0x9f27daea7aca0aa0446220b98d028715e3bc803d, 0xa5dc5acd6a7968a4554d89d65e59b7fd3bff0f90, 0xd9aef3a1e38a39c16b31d1ace71bca8ef58d315b, 0x63ed5a272de2f6d968408b4acb9024f4cc208ebf, 0x6f6704e5a10332af6672e50b3d9754dc460dfa4d, 0x77ca7b50b6cd7e2f3fa008e24ab793fd56cb15f6, 0x492ea3bb0f3315521c31f273e565b868fc090f17, 0x0ff30d6de14a8224aa97b78aea5388d1c51c1f00, 0x9ea779f907f0b315b364b0cfc39a0fde5b02a416, 0xceaeb481747ca6c540a000c1f3641f8cef161fa7, 0xcc34673c6c40e791051898567a1222daf90be287, 0x579a80d909f346fbfb1189493f521d7f48d52238, 0xe308bd1ac5fda103967359b2712dd89deffb7973, 0x4cb31628079fb14e4bc3cd5e30c2f7489b00960c, 0xac1ecab32727358dba8962a0f3b261731aad9723, 0x4fd6ace747f06ece9c49699c7cabc62d02211f75, 0x440c59b325d2997a134c2c7c60a8c61611212bad, 0x4486a3d68fac6967006d7a517b889fd3f98c102b, 0x9c15b54878ba618f494b38f0ae7443db6af648ba, 0x27b137a85656544b1ccb5a0f2e561a5703c6a68f, 0x21c7fdb9ed8d291d79ffd82eb2c4356ec0d81241, 0x23b75c2f6791eef49c69684db4c6c1f93bf49a50, 0x1ca6abd14d30affe533b24d7a21bff4c2d5e1f3b, 0xb9637156d330c0d605a791f1c31ba5890582fe1c, 0x6131c42fa982e56929107413a9d526fd99405560, 0x1591fc0f688c81fbeb17f5426a162a7024d430c2, 0x542a9515200d14b68e934e9830d91645a980dd7a, 0xc4bbd073882dd2add2424cf47d35213405b01324, 0x782495b7b3355efb2833d56ecb34dc22ad7dfcc4, 0x58b95c9a9d5d26825e70a82b6adb139d3fd829eb, 0x3ba4d81db016dc2890c81f3acec2454bff5aada5, 0xb52042c8ca3f8aa246fa79c3feaa3d959347c0ab, 0xe4ae1efdfc53b73893af49113d8694a057b9c0d1, 0x3c02a7bc0391e86d91b7d144e61c2c01a25a79c5, 0x0737a6b837f97f46ebade41b9bc3e1c509c85c53, 0x97f43a37f595ab5dd318fb46e7a155eae057317a, 0x52c5317c848ba20c7504cb2c8052abd1fde29d03, 0x4863226780fe7c0356454236d3b1c8792785748d, 0x5d2b2e6fcbe3b11d26b525e085ff818dae332479, 0x5f9f3392e9f62f63b8eac0beb55541fc8627f42c, 0x057b56736d32b86616a10f619859c6cd6f59092a, 0x9aa008f65de0b923a2a4f02012ad034a5e2e2192, 0x304a554a310c7e546dfe434669c62820b7d83490, 0x914d1b8b43e92723e64fd0a06f5bdb8dd9b10c79, 0x4deb0033bb26bc534b197e61d19e0733e5679784, 0x07f5c1e1bc2c93e0402f23341973a0e043f7bf8a, 0x35a051a0010aba705c9008d7a7eff6fb88f6ea7b, 0x4fa802324e929786dbda3b8820dc7834e9134a2a, 0x9da397b9e80755301a3b32173283a91c0ef6c87e, 0x8d9edb3054ce5c5774a420ac37ebae0ac02343c6, 0x0101f3be8ebb4bbd39a2e3b9a3639d4259832fd9, 0x5dc28b15dffed94048d73806ce4b7a4612a1d48f, 0xbcf899e6c7d9d5a215ab1e3444c86806fa854c76, 0x12e626b0eebfe86a56d633b9864e389b45dcb260, 0xa2f1ccba9395d7fcb155bba8bc92db9bafaeade7, 0xec8e57756626fdc07c63ad2eafbd28d08e7b0ca5, 0xd164b088bd9108b60d0ca3751da4bceb207b0782, 0x6231b6d0d5e77fe001c2a460bd9584fee60d409b, 0x1cba23d343a983e9b5cfd19496b9a9701ada385f, 0xa82f360a8d3455c5c41366975bde739c37bfeb8a, 0x9fcd2deaff372a39cc679d5c5e4de7bafb0b1339, 0x005f5cee7a43331d5a3d3eec71305925a62f34b6, 0x0e0da70933f4c7849fc0d203f5d1d43b9ae4532d, 0xd131637d5275fd1a68a3200f4ad25c71a2a9522e, 0xbc07118b9ac290e4622f5e77a0853539789effbe, 0x47e7aa56d6bdf3f36be34619660de61275420af8, 0xacd87e28b0c9d1254e868b81cba4cc20d9a32225, 0xadf80daec7ba8dcf15392f1ac611fff65d94f880, 0x5524c55fb03cf21f549444ccbecb664d0acad706, 0x40b803a9abce16f50f36a77ba41180eb90023925, 0xfe24cdd8648121a43a7c86d289be4dd2951ed49f, 0x17802f43a0137c506ba92291391a8a8f207f487d, 0x253488078a4edf4d6f42f113d1e62836a942cf1a, 0x86af3e9626fce1957c82e88cbf04ddf3a2ed7915, 0xb136707642a4ea12fb4bae820f03d2562ebff487, 0xdbe9b615a3ae8709af8b93336ce9b477e4ac0940, 0xf14c14075d6c4ed84b86798af0956deef67365b5, 0xca544e5c4687d109611d0f8f928b53a25af72448, 0xaeeb8ff27288bdabc0fa5ebb731b6f409507516c, 0xcbb9d3703e651b0d496cdefb8b92c25aeb2171f7, 0x6d87578288b6cb5549d5076a207456a1f6a63dc0, 0xb2c6f0dfbb716ac562e2d85d6cb2f8d5ee87603e, 0xaccc230e8a6e5be9160b8cdf2864dd2a001c28b6, 0x2b3455ec7fedf16e646268bf88846bd7a2319bb2, 0x4613f3bca5c44ea06337a9e439fbc6d42e501d0a, 0xd343b217de44030afaa275f54d31a9317c7f441e, 0x84ef4b2357079cd7a7c69fd7a37cd0609a679106, 0xda2fef9e4a3230988ff17df2165440f37e8b1708, 0xf4c64518ea10f995918a454158c6b61407ea345c, 0x7602b46df5390e432ef1c307d4f2c9ff6d65cc97, 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, 0x807640a13483f8ac783c557fcdf27be11ea4ac7a

注意清单末尾两项正是 DAO 主合约与它的 extraBalance——它们是本次状态变更的直接参与者，而清单其余部分则覆盖了所有被拆分出来的子 DAO 及其附属余额账户。

3.3 状态转移的执行时刻

在第 1,920,000 区块开始时，L中所有账户的全部以太币（ether）将被转移到部署在0xbf4ed7b27f1d666546e30d74d50d173d20bca754的合约中。这是一个确定性的、一次性完成的状态改写，不需要任何用户交互或合约调用。

四、WithdrawDAO 合约：源码、部署与字节码

4.1 Solidity 源码

接收资金的 WithdrawDAO 合约由以下 Solidity 代码编译而来（编译器版本v0.3.5-2016-07-01-48238c9）：

// Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754 contract DAO { function balanceOf(address addr) returns (uint); function transferFrom(address from, address to, uint balance) returns (bool); uint public totalSupply; } contract WithdrawDAO { DAO constant public mainDAO = DAO(0xbb9bc244d798123fde783fcc1c72d3bb8c189413); address public trustee = 0xda4a4626d3e16e094de3225a751aab7128e96526; function withdraw(){ uint balance = mainDAO.balanceOf(msg.sender); if (!mainDAO.transferFrom(msg.sender, this, balance) || !msg.sender.send(balance)) throw; } function trusteeWithdraw() { trustee.send((this.balance + mainDAO.balanceOf(this)) - mainDAO.totalSupply()); } }

从代码结构可以解读出这套"退款机制"的设计：

• DAO接口只声明了退款流程所需的三个成员：balanceOf(address)读取某地址余额、transferFrom(from, to, balance)执行转账（返回布尔值）、totalSupply记录代币总供应量。它是对主 DAO 合约最小接口的抽象，实际调用目标固定为主 DAO 地址0xbb9bc244d798123fde783fcc1c72d3bb8c189413（mainDAO常量）。
• withdraw()是面向受害者的退款入口：先通过mainDAO.balanceOf(msg.sender)查询调用者在主 DAO 中的余额，再调用transferFrom(msg.sender, this, balance)把等量代币从调用者划转到 WithdrawDAO，最后用msg.sender.send(balance)将以太币原路退回；两步中任一步失败即throw回滚。
• trusteeWithdraw()是托管人兜底通道：把"合约自身余额 + 主 DAO 中本合约余额 − 主 DAO 总供应量"的差额发送给 trustee（0xda4a4626d3e16e094de3225a751aab7128e96526），用于处理无人领取的零头或异常余额。

4.2 部署记录与字节码

该合约部署于主网区块1883496，部署交易哈希为：

0xfeae1ff3cf9b6927d607744e3883ea105fb16042d4639857d9cfce3eba644286

其**部署代码（creation code）**为：

0x606060405273da4a4626d3e16e094de3225a751aab7128e96526600060006101000a81548173ffffffffffffffffffffffffffffffffffffffff02191690830217905550610462806100516000396000f360606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156

部署完成后，链上驻留的**运行时字节码（runtime bytecode）**为：

0x60606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156

从字节码层面可以印证源码结构：函数选择器0x3ccfd60b（withdraw()）、0x2e6e504a（trusteeWithdraw()）、0xeedcf50a（mainDAO）、0xfdf97cb2（trustee）均被编入分发逻辑；bb9bc244d798123fde783fcc1c72d3bb8c189413与da4a4626d3e16e094de3225a751aab7128e96526两个地址常量分别硬编码于mainDAO与trustee的读写路径中。部署代码以0x6060604052...开头（编译器版本的元数据/初始化序列），并以6101...6000396000f3风格的前缀附带回退/返回逻辑——这些细节表明它出自 2016 年中期（v0.3.5）的 Solidity 编译器，属于当时典型的合约部署模式。

五、区块头约束：dao-hard-fork标记

除了状态转移本身，规范还对区块提出了明确的 MUST 级要求：

Blocks with block numbers in the range [1_920_000, 1_920_009]MUSThave0x64616f2d686172642d666f726b(hex encoded ASCII stringdao-hard-fork) in theextraDatafield of the block.

即：区块号落在[1,920,000, 1,920,009]区间内的 10 个区块，其extraData字段必须包含十六进制值0x64616f2d686172642d666f726b——它正是 ASCII 字符串dao-hard-fork的十六进制编码。这是一个供链上审计与验证的"分叉锚点"：任何遵守规范的客户端在打包/校验该区间区块时，都能据此确认自己正处于 DAO Fork 激活窗口内。对于协议实现者，这条约束相当于一个额外的共识检查点，与"账户清单 L 的状态改写"共同构成这次硬分叉的完整可验证定义。

六、从源码结构看：为什么它是"状态分叉"而非"协议分叉"

将 EIP-779 与仓库中的其他 Hardfork Meta EIP 对比，可以更清楚地看出它的独特性：

• EIPS/eip-606.md（Homestead）列出Included EIPs：EIP-2（Homestead 硬分叉变更）、EIP-7（DELEGATECALL）、EIP-8（devp2p 网络层前向兼容）——每一项都在改规则；
• EIPS/eip-608.md（Tangerine Whistle）列出 EIP-150（IO 密集型操作的 Gas 成本变更）——同样改规则；
• 而 EIP-779 的规范部分没有任何Included EIPs列表，取而代之的是一张地址清单 + 一段部署字节码 + 一条 extraData 约束。整份规范的全部可执行语义，就是"在 1920000 区块把这些地址的余额搬过去，并给前后 10 个区块打上标记"。

从实现角度可以推断：常规硬分叉需要在客户端代码中切换 EVM 行为（如新的 Gas 表、新的操作码语义），而 DAO Fork 的实现则是在区块处理管线中插入一段状态修正逻辑——在执行该区块前，先对世界状态按清单 L 做余额改写，再校验 extraData 标记。这也是为什么它被准确描述为"irregular state change"：共识规则未变，共识状态被直接干预。

七、仓库中的关联证据与延伸阅读

EIP-779 在以太坊升级时间线中的位置，可以从本仓库多个文档中交叉印证：

• EIPS/eip-2228.md 在列举主网区块引用的规范时，将 EIP-779 与 EIP-2、EIP-150、EIP-155、EIP-190、EIP-225、EIP-1013、EIP-2028、EIP-2387 并列，说明它被官方视为主网历史升级的权威引用之一；
• EIPS/eip-608.md 的requires: 150, 779表明后续的 Tangerine Whistle 硬分叉在文档依赖关系上继承了 EIP-779（DAO Fork 之后的链上状态是后续升级的基线）；
• EIPS/eip-7568.md 说明了 Meta EIP 从柏林升级起一度被弃用、又在后续被重新启用的历史，反衬出 DAO Fork 时代以 Meta EIP 记录硬分叉的规范性。

若要进一步理解本主题，建议按以下顺序阅读仓库内文档：

1. EIPS/eip-1.md——理解 Meta EIP 在 EIP 分类体系中的位置；
2. EIPS/eip-233.md——理解 Hardfork Meta EIP 的形式化流程与模板；
3. EIPS/eip-606.md 与 EIPS/eip-608.md——对比常规硬分叉 Meta EIP 的结构；
4. 回到 EIPS/eip-779.md 本体，逐条核对本文引用的清单与字节码。

八、总结

EIP-779 用最简洁的规范形态，记录了一次在以太坊历史上空前（此后也未再出现过）的"不规则状态变更"：不触碰任何 EVM 语义，仅凭一份 113 个地址的清单、一段 WithdrawDAO 合约字节码和一条extraData约束，就在区块 1,920,000 完成了数千个账户的余额重定向。它既是理解 DAO 事件技术细节的一手规范，也是研究"状态级干预 vs 规则级升级"这一协议设计问题的经典案例——对于研究以太坊历史、共识分叉机制或 Meta EIP 规范的开发者而言，这份文档都是不可绕过的原始材料。

注：本文全部规范内容均直接取自 EIPS/eip-779.md；原文的完整参考文献（slock.it 的硬分叉规范说明与以太坊基金会的分叉讨论文章）可在该文档的 References 一节查看。依据 EIP-1 的规定，EIP-779 的版权与相关权利已通过 CC0 放弃（见 LICENSE.md），可自由引用与传播。

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs