治理机制：规则如何改变
治理机制是形成和落实决策的一组安排，涉及谁能提出修改、如何收集意见、按什么条件决定，以及由谁实施。阅读治理说明时，先确定治理对象：基础协议升级、应用参数调整和组织资金管理，可能采用不同流程。
链下治理与链上治理
以太坊基础协议采用链下治理，依靠不同利益相关方讨论、技术评审和升级协调；运行在以太坊上的应用则可以采用链上治理。EIP即以太坊改进提案，用于描述潜在功能或流程，提出后仍需评估、实现和测试。
链上治理把投票等环节放到区块链上，部分系统还支持按通过的提案执行代码。判断其适用范围，要看合约实际拥有的权限：应用治理投票不能直接改变底层网络规则。
提案、投票权与委托
提案是供讨论或表决的具体变更；提案门槛约束提交资格。投票权是计票使用的权重，委托则允许指定代表使用相应权重参与表决。理解这些术语时，应分别核对提交权、表决权和执行权，避免把它们视为同一种权限。
OpenZeppelin的Governor提供模块化治理框架，可配置投票权、法定票数和计票方式。其ERC20Votes支持历史投票权记录与委托；快照用于按指定历史时点确定权重，减少同一批代币转移后被重复计票的问题。
法定票数与通过条件
法定票数指提案需要满足的最低票量要求；通过条件则决定赞成和反对等票数如何影响结果。二者要分别检查，赞成票占优不一定意味着提案通过。
在OpenZeppelin的GovernorCountingSimple模块中，赞成票和弃权票计入法定票数。这是特定模块的规则，不能推广为所有治理系统的共同标准；弃权也不能直接理解为赞成。
投票延迟、投票期与执行
投票延迟是提案创建后到投票启动前的等待安排，投票期是接受投票的窗口。相关参数可能按区块数或时间戳计量，阅读数值时必须同时确认单位。
时间锁用于在执行前设置等待阶段。提案通过后是否还需排队、等待或触发执行，取决于系统配置，因此表决通过与变更生效应分别理解。
常见问题：社区共识是否等于投票结果
社区共识描述不同参与方对变更形成的广泛认可，未必能用单次投票衡量。以太坊协议治理涉及开发者、节点运营者及用户等群体，代码实现还需要被采用。
分叉意味着协议规则发生分歧或变更；若不同群体持续运行互不兼容的规则，可能形成链分裂。讨论治理效果时，应结合参与、实现和采用情况，不能仅凭一个表决结果下结论。