新消息:Helius 收购 Light Protocol
治理横幅
博客/研究

Solana 治理:全面分析

研究员X 上的 Lostin
阅读需 29 分钟

可行洞察

  • Solana 上的治理投票不具约束力,仅提供建议,主要用于反映社区态度。让验证者在全面实施前表明立场,有助于指导开发并尽量减少争议。最终决策发生在验证者选择运行哪个软件时。提案即使在投票后也可能发生变化,因此治理最终体现的是共识,而非强制执行。
  • SOL 代币持有者通过将质押的 SOL 委托给投票选择符合其价值观或偏好的验证者,间接参与治理。这是一种比例代表制,可将验证者视为当选代表。Solana 质押者将质押份额委托给验证者,每个验证者的投票权取决于其获委托的质押份额。
  • Solana 的治理投票使用 SPL 代币进行。验证者会按活跃质押份额比例获得代币,并将这些代币发送到代表不同投票选项的指定地址。验证者可以自由地将票数分配给多个选项。投票一旦提交即为最终结果,无法更改。
  • 所有破坏共识的协议更新都通过功能门激活,这类更新是不向后兼容的硬分叉。与 Bitcoin 或 Ethereum 在出现分歧时可能因硬分叉造成永久链分裂不同,Solana 的方法可确保功能门在特定 slot 于整个集群中激活。验证者会提前升级,从而避免链分裂。
  • Solana 早期开发阶段的多项经济变更——尤其是引入销毁 50% 的优先费——并未经过正式治理投票,因为当时的治理系统尚不成熟。
  • 当前的治理投票模式——仅限验证者投票——是在 2023 年 10 月的一次咨询投票后确立的。超过 170 个验证者参与,代表总质押份额的 14.3%,其中超过 70% 的质押份额支持仅限验证者投票,认为这是最务实、高效的起点。
  • 最近针对 SIMD-228 的投票以 74.3% 的参与率创下纪录,按参与者数量和市值计算,成为历史上规模最大的区块链治理活动。价值 350 亿美元的 2.81 亿 SOL 和 900 多个验证者共投出超过 1,000 票。Coinbase、Kraken 和 Bybit 等大型交易所验证者首次积极参与,凸显 Solana 日益增长的机构参与度。
  • Solana 治理流程中一个反复出现的问题,是委托人在决策中的作用有限。目前没有正式机制让委托人表达偏好或推翻验证者的决定,因此验证者的投票可能与其委托人的偏好相冲突。
  • Solana 治理投票中法定人数的作用也引发了担忧。实践中,法定人数可能产生不良激励,参与者会策略性地不投票,以阻止提案达到规定门槛。SIMD-228 的投票模式中就出现了这种情况。
  • Solana Foundation Delegation Program 将质押 SOL 总量的 10%(4,101 万枚)委托给 897 个验证者,从而放大了这些验证者的投票权。对近期 SIMD-288 投票的分析表明,SFDP 质押份额主要用于反对该提案。如果这些质押份额转而投 YES,提案就会通过。如果 SFDP 委托的质押份额弃权,提案仍会失败,但差距会缩小——64.77%,而非实际的 61.39%。
  • 哪些事项需要治理投票仍不明确。2025 年 3 月,针对 SIMD-218 (IVC) 的计划投票在各方形成共识、认为其无需治理批准后被撤回。同样,SIMD-123 虽已通过,但它是否属于经济变更并不明确,可以说未必需要正式投票。

引言

治理是去中心化的关键组成部分,从协议升级和经济政策,到验证者行为与社区标准,都受其影响。运作良好的治理系统能够提升透明度、公平性和信任,而糟糕的治理可能导致混乱、停滞或权力集中。

Solana 的治理仍处于早期发展阶段。与许多区块链网络一样,它上线时并没有一套完全成熟或正式化的治理框架。相反,这套框架在社区实践、技术限制和经验教训的共同塑造下逐步演变。完善 Solana 治理是一项持续迭代的工作。

Solana 生态系统由多种相互重叠的利益相关者群体组成:代币持有者、质押者、用户、验证者、RPC 运营商、应用开发者和核心协议工程师。每个群体都有不同的视角、激励和目标。这些激励在某些方面可能一致,但往往也会出现分歧,尤其是在资源分配、协议控制和经济政策方面。

在去中心化系统中,治理既关乎代码,也关乎社会共识。区块链常被描述为“代码即法律”,但历史已经证明,当社区共识要求改变时,代码能够改变,也确实会改变。因此,治理机制的设计及其随时间演进的能力,与最初的技术架构同样重要。

本报告旨在阐明 Solana 治理的结构、演变和现状。报告全面介绍网络内部的决策方式,并将其治理与其他区块链生态系统进行比较。全文分为四个主要部分:

  • Solana 治理的要素 – 探讨 Solana 治理流程的核心组成部分,包括 SIMD、功能门激活和正式链上投票。
  • 治理投票分析 – 详细概述迄今为止的所有正式治理投票,包括结果、投票者行为和参与度指标。
  • 挑战与建议 – 探讨 Solana 当前治理模式面临的关键问题,并在适当情况下给出可行建议。
  • 与其他网络的比较 – 介绍 Cosmos 和 Ethereum 同类生态系统的治理方式,重点分析可为改进 Solana 提供参考的实践。

虽然按顺序阅读本报告的体验最佳,但每个部分均可独立成篇、单独阅读。

Solana 治理的要素

下表概述了 Solana 的治理系统,采用的分析框架改编自 Schädler、Lustenberger 和 Spychiger(2023 年)的论文 分析区块链治理中的决策。我们对该框架进行了调整,以体现 Solana 生态系统中的具体机制和动态。

链下链上
决策者客户端团队(Anza、Firedancer)验证者运营商
激励提高网络采用率
技术改进:IBRL
提高网络采用率
通胀佣金
区块奖励
MEV 佣金
访问权限公开 / 开放Mainnet 验证者
协调渠道SIMD Github
Solana Tech Discord
Solana 论坛
社交渠道
无
批准条件无达到投票法定人数

Solana 协议的修改遵循多阶段流程,具体取决于变更的性质和影响。关键因素包括变更是否会破坏共识、对利益相关者的影响,以及相关争议或复杂程度。破坏共识的变更,是指会导致运行不同软件版本的节点对区块链状态产生分歧的任何协议更新。 

下表概述了不同规模变更通常涉及的步骤。“大型变更”是指可能产生经济影响的变更。

变更规模小型变更中型变更大型变更
示例代码重构新核心程序经济参数修改
是否破坏共识否是是
是否需要 SIMD否是是
是否需要治理投票否否是
是否需要跨客户端实现否是是
是否需要激活功能门否是是

下面将详细介绍功能门激活、SIMD 和治理投票的流程。

功能门激活

Anza 和 Firedancer 的核心开发团队经常发布新功能,包括 syscall、原生程序和会破坏共识的经济变更。这些功能在创建后会纳入新的客户端软件版本,并默认通过功能标志停用。最近迁移为 Core BPF 程序的功能门程序,会将每项新功能作为一个账户进行跟踪。与每个功能门关联的核心贡献者拥有该功能门独有的私钥。当足够多的已质押验证者升级到新版本,且该版本被认为稳定后,运行时功能开关会通过一条指令手动激活,该功能将在下一个 epoch 开始时于网络所有节点上线。激活的确切顺序和时间可通过功能门时间表进行跟踪。功能激活与集群无关,依次在 Testnet、Devnet 和 Mainnet 上进行,从而在 Mainnet 最终激活前逐步建立对新版本的信心。

“版本下限”是集群当前支持的最低软件版本。随着新功能门激活,版本下限会提高到包含该功能的软件版本。Solana 的新功能激活遵循固定节奏,通常安排在工作日办公时间内的 epoch 边界。版本过渡期间会暂停激活,并在 95% 的质押份额升级到新的次要版本(例如从 2.2 升级到 2.3)约两个 epoch 后恢复。

功能门激活是不向后兼容的硬分叉,需要所有参与者采用才能生效。如果验证者没有升级到能够识别已激活功能门的版本,就无法继续验证全局状态,并会与网络产生分歧。

与 Bitcoin 或 Ethereum 在出现分歧时可能因硬分叉造成永久链分裂不同,Solana 的方法确保功能门在特定 slot 于整个集群中激活。验证者必须提前升级,从而避免链分裂。因此,功能门会改变共识规则,属于硬分叉,但不会产生相互竞争的链。

新的客户端版本还会包含许多不会破坏共识的变更,例如代码重构和效率优化,这些变更无需使用功能门。

Solana 改进文档(SIMD)

任何对 Solana 核心组件的重大变更,都必须提供正式的 Solana 改进文档(SIMD)提案。“重大”变更通常是指会改变网络协议、交易有效性或互操作性的变更。小型代码重构或客观的性能改进等非重大变更无需提交提案。提案应说明功能的设计理由,并提供足够的文档以便理解实现方式。 

虽然任何人都可以提交 SIMD,无需许可,但大多数 SIMD 都由全职改进核心协议的客户端团队开发者提交。

提案分为两类: 

  • 标准提案:影响 Solana 核心功能(例如共识、网络和 API 接口)
  • 元提案:处理代码库之外的流程或准则

SIMD 通常会经历构想审查、起草、评审和接受阶段。正式评审在 GitHub 上公开进行,提案作者负责收集 Agave 和 Firedancer 客户端团队相关核心贡献者的反馈。这些贡献者会综合考虑安全性、取舍和向后兼容性,决定接受、修订或撤回提案。

作者没有义务实现自己的提案,但通常建议由作者实施,因为这是确保提案成功完成的最佳方式。提案获接受后,通常会附带用于跟踪功能实现的问题,并且一般需要通过 Solana 的功能门机制激活。 

并非所有功能门激活都需要 SIMD,但大多数都会附带一份 SIMD,以提供背景、理由和提议变更的标准化记录。

治理投票

会对协议产生重大改变的 SIMD,尤其是影响经济参数的 SIMD,需要经过治理投票。Solana 的治理流程由验证者社区的资深成员主导,只聚焦关键问题,以保持参与度并避免治理疲劳。因此,每年只会举行少数几次投票。  

治理投票主要用于衡量各方对提议变更的态度。让验证者在全面实施前表明立场,有助于指导开发并尽量减少争议。在缺乏广泛共识的情况下实施变更可能引发摩擦,尤其是当超过三分之一的网络拒绝采用时。

投票使用 SPL 代币进行。每个活跃验证者的身份账户会按其以 lamports 计量的活跃质押份额比例获得代币。随后,验证者可将这些代币发送到代表不同投票选项的指定地址,其中包括弃权选项。验证者可自由地将票数分配给多个选项,例如将 80% 分配给 YES、20% 分配给 NO,以便灵活体现质押者的不同偏好。投票一旦提交即为最终结果,无法更改。

在这种结构下,SOL 代币持有者通过将质押的 SOL 委托给投票选择符合其价值观或偏好的验证者,间接参与治理。这是一种比例代表制,可将验证者视为当选代表。Solana 质押者将质押份额委托给验证者,每个验证者的投票权取决于其活跃质押份额。

链上治理的局限

Solana 治理归根结底不具约束力,仅提供建议。实践中,真正的投票发生在验证者选择运行哪个软件版本时。治理投票可以反映社区的广泛支持或反对,但不能强制验证者采用任何特定代码。提案甚至可能在投票后发生变化,而验证者仍完全控制其基础设施上运行的内容。这种动态意味着,治理更侧重于传递共识信号,而不是强制执行结果。

在这种背景下,Anza、Jump 和 Jito 等核心贡献者,以及 Helius 和 Triton 等基础设施提供商,都拥有显著的非正式影响力。验证者不太可能反对这些群体,以免失去质押份额或与网络失去同步,因此这些实体可以有效影响升级结果,无论其是否拥有正式决策权。

在验证者拒绝升级的极端情况下,可能发生分叉。Ethereum 2016 年的 DAO Fork 导致 Ethereum Classic 诞生,至今仍是一个警示案例。随着 Solana 治理流程的演进,明确表态投票、软件发布和验证者实际采用之间的关系,将有助于确保透明度,并规避链分裂的尾部风险。

治理投票分析

Solana 的早期治理:2020-2022 年

Solana 最初的治理方式与当前框架大不相同。早期治理以功能提案程序为核心,验证者可使用按质押份额加权的 SPL 代币对协议变更投票。当新的功能版本可供激活时,验证者会按其活跃质押份额比例获得投票代币。在两周期限内将这些代币返还到指定账户,即可表示同意激活提议的功能。当支持份额达到 67% 的质押门槛后,变更会在下一个 epoch 直接于链上启用。

功能提案程序曾多次用于在 Testnet 和 Mainnet 上开展验证者治理投票,其中最引人注目的是激活当前的通胀计划。

提案日期集群提案详情
PICO 通胀2020 年 12 月Testnet 和 Mainnet在全面通胀前启用 0.01% 的通胀,用于验证目的
全面通胀2021 年 1 月/2 月Testnet 和 Mainnet按照通胀计划启用全面通胀
最低质押委托额2022 年 9 月Testnet引入 1 SOL 的最低质押委托额

这些早期治理投票的在线记录很少,因为原 Solana 论坛已下线,现在只能通过 Wayback Machine 的存档版本访问。

尽管这种机制引入了一定程度的链上协调,但也受到广泛批评。验证者无法表达异议——系统只统计 YES 票,没有正式方式表示反对或弃权。该系统还会形成批准变更的社会压力,尤其是在大量工程工作已经投入实现之后。 

更重要的是,该系统无法提前传递信号。这意味着复杂功能可能在尚不确定能否被接受的情况下就开始构建,导致效率低下并浪费开发时间。

总体而言,功能提案程序是 Solana 治理历程中重要的早期一步,而其局限也为如今更灵活的治理机制提供了经验。

值得注意的是,这一早期阶段的多项重大经济变更——例如引入销毁 50% 的优先费——并未经过正式治理投票,这反映出当时治理系统仍处于起步阶段。

Solana 当前的治理:2023 年至今

在使用功能提案程序后,Solana 逐步演变为当前的治理投票系统。迄今共举行了五次正式治理投票:

首次咨询投票

塑造 Solana 当前治理框架的一项关键早期决策,是确定哪些人应参与投票流程。社区面前有三个选项:

  1. 仅限验证者投票,按质押份额加权
  2. 验证者和质押账户参与,允许委托人推翻其验证者的投票
  3. 验证者、质押账户和其他利益相关者参与,例如 RPC 运营商和开发者

超过 170 个验证者参与了咨询投票,代表总质押份额的 14.3%。在参与投票的质押份额中,超过 70% 支持仅限验证者投票,24% 支持验证者与委托人共同参与的模式。此次投票没有设置最低参与门槛。

仅限验证者投票被视为最务实、高效的起点,因为相关基础设施已经存在,并经过实际测试。涉及委托人或其他利益相关者的复杂系统被认为时机尚早,可能给刚起步的治理流程带来负担。社区也承认,随着治理机制成熟,可以通过未来的提案引入并完善其他投票模式。

治理投票模式

首次咨询投票后,又进行了四次治理投票,均设有相同的三个选项:YES、NO 和弃权。这些选项用于表明是否同意提议的 SIMD。提案要获得通过,YES 和 NO 合计票数中必须至少有三分之二赞成(即投 YES)。 

SIMD-33:及时投票积分以压倒性支持获批,YES 票占 98.4%。这项没有争议的共识变更消除了验证者此前通过延迟提交投票获得的收益,解决了激励错位问题,从而改善网络行为和公平性。

SIMD-96:向验证者支付全部优先费以 77.7% 的 YES 票通过。这项经济提案旨在将 100% 的优先费支付给验证者,以遏制侧通道交易处理。该提案虽然能有效协调激励,但也因小幅增加通胀,以及被认为相较 SOL 持有者更偏袒验证者而引发了一些争议。

SIMD-123:协议内分配区块奖励以 74.91% 的 YES 票获批。该提案引入了一种可选的标准化机制,让验证者能够直接向质押者分配区块奖励。尽管已有多个验证者通过更手动的方式执行这一操作,但将其纳入协议仍引发了有关竞争压力的争论,有人担心这可能导致区块奖励佣金率“竞相降至零”。

SIMD-228:基于市场的发行机制未获通过,只有 61.39% 投了 YES。该提案旨在让 Solana 的通胀率更灵敏地响应质押参与度,并认为当前发行量过高、无法响应收益需求,导致网络为安全性支付过高成本。

反对者担心该提案会影响小型验证者的经济可行性,并给质押收益带来更多不确定性。此次投票争议极大,引发了广泛讨论,也凸显出各方对 Solana 长期经济模式的不同看法。

如需了解详细投票行为,建议读者参阅 SIMD-96、SIMD-123 和 SIMD-228 的开源投票仪表板。此外,我们还提供了一份电子表格,可在此查看投票数据。

SIMD-228 和 SIMD-123 设定了 33% 质押参与率的法定人数门槛,其中包括弃权票。相比之下,SIMD-96 和 SIMD-33 等早期提案没有最低参与要求,无论总质押份额中有多少参与投票,提案都可能通过。

参与率

投票参与率随时间呈上升趋势。2023 年 10 月的首次咨询投票参与度很低,仅有 14.3% 的质押份额参与。此后参与率稳步提高,并在 2025 年 3 月针对基于市场的发行机制 SIMD-228 的投票中达到 74.3%。迄今另外三次投票的参与率相对稳定,介于 51.2% 至 57.1% 之间。

按参与者数量和所代表的总市值计算,SIMD-228 投票成为加密货币历史上规模最大的治理活动。辩论期间,Solana 的市值与 Bitcoin 在 2017 年年中区块大小之争期间的市值相当,凸显了这一决定的重要性。共有价值 350 亿美元的 2.81 亿 SOL 参与投票,900 多个验证者提交了超过 1,000 票。值得注意的是,包括 Coinbase、Kraken 和 Bybit 在内的大型交易所验证者首次积极参与 Solana 的链上治理,表明机构在网络决策流程中的参与日益增加。近期参与度的上升,尤其是美国实体参与度的提高,也可能部分归因于现任政府领导下更有利的区块链监管环境。

问题与建议

下一部分将探讨治理投票流程中的主要挑战,并在相关情况下提出改善透明度、安全性和效率的建议。

质押者参与不足

Solana 治理流程中一个反复出现的问题,是委托人在决策中的作用有限。尽管验证者使用按质押份额加权的治理权对提案投票,但没有正式机制让委托人表达偏好或推翻验证者的决定。这可能导致验证者的投票与委托人的利益相冲突,使质押者无法直接影响治理结果。

拥有数千名委托人的验证者很难收集每个人的投票偏好,而质押者的参与率通常也很低。一些验证者会在投票前咨询其最大委托人,并根据他们的偏好拆分票数,以部分解决这个问题。另一些验证者则尝试使用仿照现有代币投票系统的自定义工具,按质押比例向质押者发行新的治理代币。不过,这仍是针对特定验证者的解决方案,而非全协议统一的功能。

反对质押者参与的人指出,大多数委托人并非技术人员,很少密切关注治理决策,也不具备做出知情决策所需的区块链机制和权衡取舍方面的深入知识。然而,支持者认为,只依赖验证者会造成利益冲突。如果提案会损害验证者自身的经济利益,期待大多数验证者投票支持有利于网络的提案并不现实。

潜在改进包括在验证者与委托人之间建立更好的沟通渠道,例如治理仪表板、态度跟踪工具,甚至针对治理活动的钱包通知。本报告后续章节将再次讨论这个主题,并分析 Cosmos 生态系统的做法。

治理讨论面临的挑战

去中心化生态系统中的有效治理依赖清晰、高信噪比的沟通。然而,在近期 SIMD-288 提案期间,激烈争论、人身攻击和派系斗争造成了不健康的治理环境,最终阻碍了富有成效的讨论。Solana 关键提案的讨论可能因不同平台之间的低效和信号质量下降而受到影响。GitHub 和 Solana 官方论坛上的技术讨论能够提供结构化且深入的辩论,但当讨论进入 Discord 和 Twitter 后,有意义的交流有时会演变为口水战和人身攻击,降低整体决策质量。

此外,大多数参与者只在投票前的最后几天加入讨论,没有充分利用整个讨论期。鼓励更早参与并更合理地设计治理时间线,例如确保关键讨论远早于最终投票窗口进行,可以帮助缓解这些问题。

治理电话会议已被证明行之有效,可以促进直接交流、快速澄清,并减少恶意干扰或误导的机会。要维持建设性的治理流程,必须加强审核、推动结构化讨论,并重视基于事实的分析,而非对抗性争论。

治理提案捆绑

每项提案单独投票通常最有利于治理决策,因为投票者可以根据每个问题自身的价值进行判断。捆绑提案的一个主要问题是无意识偏见:对某个问题立场强烈的投票者,可能会无意间让这一立场影响自己对其他问题的看法,即使这些问题彼此无关。这会降低做出细致决策的可能性,并可能阻碍原本有益的变更实施。

另一项风险是,捆绑会增加操作复杂度,使错误更容易发生。在 SIMD-228 和 SIMD-123 的联合投票期就出现了这种情况:少量原本用于 SIMD-123 的代币被误发到 SIMD-228 的弃权地址。此类错误虽然少见,但会扭曲投票结果,削弱人们对治理流程的信心。

不过,支持捆绑提案的一方认为,将多个决策合并到更少的投票期,可以减少投票疲劳并提高参与率。虽然这可能提高参与度,但会牺牲决策的清晰度和精确性。此外,当捆绑提案较为复杂时,通常需要在投票开始前延长讨论和评审期,让投票者——尤其是通常在最后一刻才参与的人——有足够时间充分理解和评估每个组成部分。

更有效的方法可能是在条件允许时将治理提案分开,确保每个问题都得到独立评估。如果确实需要捆绑,应清楚说明理由。

投票法定人数

Solana 治理投票中法定人数的作用引发了担忧。实践中,法定人数可能产生不良激励,参与者会策略性地不投票,以阻止提案达到规定门槛。在近期 SIMD-228 投票中,这一点在 NO 阵营中尤为明显:在前两个投票 epoch 期间,他们发现弃权比主动投票反对提案更有效。 

持续公开的票数会影响参与行为。如果预期结果已经符合自己的偏好,一些验证者可能选择不投票。为了防止操纵法定人数,一种潜在改进方式是延迟显示票数,直到投票期结束。

鉴于这些挑战,越来越多的人支持重新评估或取消法定人数要求,以鼓励更直接、透明的治理参与。

SFDP 的影响

截至撰写本文时,Solana Foundation Delegation Program 已向 897 个验证者委托 SOL,占网络所有活跃验证者的 66%。委托总量为 4,101 万 SOL,占质押 SOL 总量的 10%。读者可以参阅 Helius 博客此前发布的 SFDP 报告,了解该计划及其委托策略的完整详情。

在当前治理模式下,加入该计划的验证者实际上获得了更大的投票权,并代表 Solana Foundation 投票。我们对近期 SIMD-288 治理投票的内部分析和公开仪表板证实,SFDP 质押份额对投票结果发挥了重要作用。在此次投票中,SFDP 质押份额主要用于投 NO 反对提案。如果由 SFDP 控制且投了 NO 或弃权的质押份额转而投 YES,提案就会通过。如果所有由 SFDP 控制的质押份额都保持中立并弃权,提案仍会失败,但差距会更小——64.77%,而非实际的 61.39%(通过需要 66.6%)。

明确发起投票的标准

2025 年 3 月的治理投票原本包含三项提案:SIMD-228、SIMD-123 和 SIMD-218:中间投票积分(IVC)。IVC 会在验证者为子区块投票时,自动回填所有父区块的积分,从而不再需要由验证者运行、用于优化 Tower BFT(Solana 的 pBFT 共识算法变体)投票积分的修改版软件。

讨论期间,各方逐渐形成共识,认为 SIMD-218 不应需要治理批准。该变更被广泛视为错误修复,而不是实质性协议变更,因为它只是增强或修正及时投票积分(TVC)升级。TVC 已经通过治理投票,并获得社区的强力支持。Solana Tech Discord 上针对验证者进行的非正式调查也强化了这一观点,几乎所有人都表示同意。

此外,Anza 的工程师指出,SIMD-123:协议内分配区块奖励并不像其名称暗示的那样属于经济变更。该提案引入了一种可选的协议内方法,用于向质押者分配区块奖励,将多个验证者已经通过其他方式执行的做法正式化,并将此前的协议外活动标准化。

这引出了几个重要的治理问题:

  • 谁来决定提案是否需要投票?目前没有官方机构或结构化流程来判断提案应进入治理程序,还是直接实施。
  • “实质性协议变更”的定义仍然模糊。常规升级与需要正式治理干预的变更之间界线不清,目前的定义高度依赖“经济影响”这一相对模糊的概念。

安全问题

当前的治理提案投票流程依赖第三方工具 solgov-distributor,该工具由社区成员 Laine 开发和托管。它是 Jito 最初开发的一个基于 Merkle 的代币分发器的分叉。尽管 Laine 是备受尊重的社区成员,但依赖外部控制的工具会引入信任假设和安全风险。

  • 可变性 – 工具及其文档均可变,这意味着它们随时可能被单方面修改。
  • 使用验证者身份密钥对 – 验证者需要构建 CLI,并使用其验证者身份密钥对领取代币,而这些密钥对高度敏感。任何依赖外部软件与此类关键凭据交互的流程都会带来安全风险。
  • 依赖单个维护者 – 正式治理流程不应在缺乏正式安全保障或独立审计的情况下,关键依赖外部第三方。

其他投票机制

目前已有一个 SPL 功能提案工具(文档见此处),最初用于支持链上治理。不过,近期的治理流程并未采用这种方法,而是使用了 solgov-distributor,这引发了是否有必要增加这一工具的疑问。

原则上,SPL 代币系统已经提供了分发治理投票权的原生方法。流程发起者可以直接向所有验证者分发 SPL 代币,让他们使用标准 spl-token CLI 投票,无需依赖外部工具。这将消除不必要的依赖,并增强投票流程的去信任化程度。

即将推出的链上治理工具:SIMD-133

即将推出的 SIMD-133:获取 Epoch 质押份额计划很快在 Mainnet 激活。它会引入新的治理工具,让程序能够在链上获取质押权重。目前,链上程序无法获知当前 epoch 的质押分布,以及每个投票账户获得了多少委托质押份额。

借助 SIMD-133,治理程序可以通过新的 sysvar 在链上生成验证者质押数量快照,无需再使用链下或手动质押验证流程。这将大幅简化现有治理流程,并消除手动核对质押份额的需求。

与其他网络的比较

Cosmos

Cosmos SDK 链采用以委托人为中心的治理模式,质押者可以通过 Keplr 和 Leap 等常用钱包直接推翻验证者的投票。这意味着,虽然验证者最初会使用其全部质押权重投票,但持不同意见的委托人可以将自己的质押份额重新分配给其他投票选项。例如,如果某个验证者持有总质押份额的 2%,但一名质押权重为 1% 的委托人持不同意见,该委托人可以单独投票,将验证者的有效投票权降至 1%,并把自己的 1% 转移到其他选项。

该系统确保委托人始终拥有最终决定权,形成透明、易用且高效的治理流程。Cosmos 的治理参与高度可见,因为投票直接集成到钱包和区块浏览器中,所有利益相关者都能轻松访问。

在 Cosmos ATOM 减半投票(提案 848,2023 年 11 月)中,质押者和验证者表现出不同的投票行为。该提案旨在将最高通胀率降至 10%:

  • 94.93% 的质押者投 YES,支持设置通胀上限。
  • 只有 53.44% 的验证者投 YES,因为许多验证者希望保留更高的收入来源。

这种分歧凸显了质押者直接参与的重要性,可以确保治理决策反映更广泛的社区态度,而不仅仅是验证者的偏好。

Cosmos 治理模块嵌入协议层,强化了其作为区块链核心功能的地位。某些治理决策可以在链上自动执行,从而提高透明度和问责性。 

这种模式虽然提供了民主的治理结构,但依赖积极参与,并假设委托人拥有做出知情决策所需的时间和知识。Cosmos 提供了一套颇具吸引力的替代治理框架,Solana 可以对其进行研究,以确定潜在的改进方向。

Ethereum

Ethereum 治理采用社会化链下流程,而非直接按质押份额投票。决策流程主要依赖 Ethereum 改进提案(EIP)、核心开发者和社区共识。

Ethereum 的变更通过 EIP 提出,相当于 Solana 的 SIMD。这些 EIP 概述 Ethereum 协议的新功能、标准或升级。Ethereum 意见征求(ERC)则定义应用层功能的标准,例如 ERC-20 代币和 ERC-721 NFT。这些提案会在 Ethereum 研究论坛(Ethereum Magicians)、热门 Ethereum 活动(例如 Devcon、ETHDenver、ETHCC)、GitHub 和核心开发者电话会议中公开讨论。更广泛的社区也会在 Discord、Farcaster 和 X 等平台上讨论提案,参与治理。

与 Cosmos 或 Solana 不同,Ethereum 不使用基于质押或代币投票的方式进行协议决策。Ethereum 转向权益证明后,验证者在共识中发挥了更积极的作用,但不会正式投票。相反,各方通过技术辩论和广泛的社区支持达成粗略共识。Ethereum 的协议变更高度依赖维护 Ethereum 执行客户端和共识客户端(例如 Geth、Nethermind、Prysm)的核心开发者。

重大升级通过硬分叉激活,需要验证者和节点运营商升级软件。验证者通过决定是否采用新升级来执行网络规则。虽然并不常见,但如果提议的变更争议较大且缺乏共识,可能导致链分裂,过去的 DAO Fork(2016 年,Ethereum Classic)以及影响较小的 Ethereum 向权益证明过渡(2022 年,EthereumPoW)都出现过这种情况。

Ethereum 的社会治理模式优先考虑技术共识和社区讨论,而不是正式投票机制。这让 Ethereum 保持了灵活性和去中心化,但也意味着变更需要经过漫长的讨论和社会协调,而不是直接进行基于代币的治理。此外,ETH 持有者或质押者没有正式方式对提案投票,限制了用户的直接影响力。

结论

Solana 的治理系统仍在发展,并受到现实实验和社区意见的共同塑造。本报告分析了其核心组成部分——SIMD、功能激活和链上投票,同时回顾了迄今所有正式投票、主要挑战,以及与 Cosmos 和 Ethereum 等同类网络的比较。 

Solana 生态系统植根于强大的工程驱动文化,比起长时间辩论,它更重视快速迭代和执行。高速升级让 Solana 有别于许多同类网络,但也与依赖长期社区讨论和广泛社会协调的治理模式产生张力,为如何在速度和包容性决策之间取得平衡带来独特挑战。

Solana 的治理仍在成形,但有一点很明确:社区参与度从未如此之高。随着更多利益相关者积极塑造网络,Solana 拥有独特机会,可以建立一套与其雄心、速度和不断壮大的生态系统相匹配的治理模式。

其他资源

订阅 Helius

及时了解 Solana 开发的最新动态,并在我们发布新内容时收到更新

放大图片