一、治理：决定规则如何改变
治理是形成决策并推动变更的制度与过程。阅读治理说明时，首先要确定治理对象：是底层协议规则，还是某个应用的参数、合约权限或资金管理。两者可能位于同一条链上，却不采用同一套决策机制。
以太坊治理页面介绍的是协议变更协调，涉及提案、讨论、实现、测试与升级，并非给日常使用应用或发送交易设置审批程序。
二、链上治理与链下治理
链上治理通常通过区块链记录表决，并按合约规则判断结果；链下治理主要通过讨论和协调形成变更决策。以太坊协议采用链下治理，但其上的DAO可以采用链上治理。因此，“部署在以太坊上”不等于“沿用以太坊协议治理方式”。
区分两者应看决定如何形成，而不只是看讨论在哪里发生。链上表决前也可以有论坛讨论；链下形成的协议决策最终也需要落实为代码。
三、提案、EIP与社区共识
提案是供讨论和评估的变更方案。EIP即以太坊改进提案，其中Core EIP用于正式描述核心协议变更。提出方案不等于获得采纳，进入讨论也不等于确定上线。
社区共识不是所有人完全一致，也不能简单等同于持币投票结果。以太坊协议变更需要不同利益相关方协调；开发者实现代码，与节点运营者采用新软件，是不同环节。理解流程时，应分别检查技术规格、实现进展和采用情况。
四、投票权、委托与快照
OpenZeppelin Governor是一套模块化治理合约框架，投票权来源、计票规则等可按模块配置。其ERC20Votes机制支持投票权委托和历史记录，治理可依据指定快照读取权重，而不是一直使用账户当前余额。
投票权表示表决权重；委托表示让另一个账户代表相应权重参与表决，不应理解为转移代币所有权。快照则回答“以哪个时点的权重为准”。分析某次投票时，应同时确认权重来源、委托状态与快照时点。
五、提案门槛、法定票数与时间参数
提案门槛限制谁能提交方案；法定票数（quorum）要求表决达到规定的有效参与量；通过条件则决定赞成与反对结果是否满足要求。三者分别对应提交资格、参与要求和结果判断，不能互相替代。
在GovernorCountingSimple中，赞成票与弃权票计入quorum，反对票不计入；这不是所有治理系统的统一规则。votingDelay表示投票前的等待间隔，votingPeriod表示投票窗口长度，单位须与治理时钟一致，可能是区块数或时间戳，不能直接混用。
六、常见问题：通过是否等于执行
不一定。表决通过是决策状态，执行是实际实施变更；配置时间锁时，还涉及排队与等待。因此，判断方案是否生效，要继续查看执行条件及状态，不能只看投票结果。
链下治理也不等于没有规则，链上治理也不保证自动消除分歧。理解任何治理流程，都应依次确认：谁能提案、谁有表决或协调角色、怎样判定通过、由谁执行，以及参与者能否拒绝采用变更。