免责声明

这部分内容仍在编写中,相关机制和数值都可能发生变化。

基本概念

什么是 Cosmos 验证人?

Cosmos Hub 基于 CometBFT,依赖一组验证人来保障网络安全。验证人的职责是运行一个全节点,并通过广播投票参与共识;这些投票包含由验证人私钥签名的加密签名。验证人负责将新区块提交到区块链中,并因此获得收益。验证人还必须通过对提案进行投票来参与治理。验证人的权重由其总质押量决定。

什么是质押?

Cosmos Hub 是一条公开的权益证明(PoS)区块链,这意味着验证人的权重由作为抵押而绑定的质押代币(ATOM)数量决定。这些 ATOM 可以由验证人自己直接自我委托,也可以由其他 ATOM 持有者委托给该验证人。 系统中的任何用户都可以通过发送 create-validator 交易来声明自己想成为验证人,从而成为验证人候选者。 验证人的权重(即投票权)决定其是否为活跃验证人。活跃验证人集合的规模限制为某个数量,且该数量会随时间变化。

什么是全节点?

全节点是运行某条链的二进制程序(即其软件)的服务器,会完整验证区块链中的交易和区块,并保留全部历史活动的完整记录。全节点不同于裁剪节点,后者只处理区块头和一小部分交易。运行全节点比运行裁剪节点需要更多资源。验证人可以选择运行全节点或裁剪节点,但必须确保保留足够多的区块,以便能够验证新区块。 当然,即使用户不打算成为验证人,也完全可以并且鼓励运行全节点。 你可以在加入主网教程中找到关于要求的更多细节。

什么是委托人?

委托人是那些无法或不想自己运行验证人的 ATOM 持有者。ATOM 持有者可以将 ATOM 委托给某个验证人,并以此换取该验证人收益中的一部分。关于收益如何分配的细节,请参见本文档中的质押的激励是什么?和什么是验证人佣金?。 由于委托人与其验证人共享收益,他们也会共同承担风险。如果验证人行为不当,其每个委托人都会按委托份额比例遭受部分罚没。正因如此,委托人在进行委托前必须对验证人做好充分尽职调查。将质押分散到多个验证人上,则是另一层保护。 委托人在系统中扮演关键角色,因为他们负责选择验证人。成为委托人并不是一个被动角色。委托人必须主动监控其验证人的行为,并参与治理。关于如何成为委托人,请阅读委托人 FAQ。

成为验证人

如何成为验证人?

网络中的任何参与者都可以通过发送 create-validator 交易来表明自己想成为验证人,在该交易中必须填写以下参数:
  • 验证人的 PubKey: 与该 Tendermint/CometBFT PubKey 对应的私钥用于签署 prevotes 和 precommits。
  • 验证人地址: 用于在应用层公开标识你的验证人的地址。与该地址对应的私钥用于委托、解绑、领取奖励以及参与治理。
  • 验证人名称(moniker)
  • 验证人网站(可选)
  • 验证人描述(可选)
  • 初始佣金率:验证人向委托人收取的区块奖励和手续费佣金比例。
  • 最高佣金率: 该验证人可收取的最高佣金率。这个参数是固定的,在 create-validator 交易处理后不可更改。
  • 佣金最大变更率: 验证人佣金每日可上调的最大幅度。这个参数是固定的,在 create-validator 交易处理后不可更改。
验证人创建后,ATOM 持有者就可以向其委托 ATOM,从而实际上为该验证人的资金池增加质押。某个地址的总质押量由委托人绑定的 ATOM 与验证人自绑定的 ATOM 共同组成。 在所有已表明意向的验证人候选者中,总质押量最高的 180 个会被指定为验证人。如果某个验证人的总质押量跌出前 180 名,该验证人就会失去验证人权限。在其质押量重新进入前 180 之前,将无法参与共识,也无法获得奖励。随着时间推移,验证人的最大数量可能会通过链上治理提案增加。

测试网

我如何加入测试网?

测试网是在正式上线前测试你的验证人配置的绝佳环境。 参与测试网也是向社区表明你已经准备好并且能够运营验证人的一种好方式。详情请参见加入公共测试网文档。

补充概念

有哪些不同类型的密钥?

有两类密钥:
  • Tendermint/CometBFT 密钥:用于签署共识投票的唯一密钥。
    • 它关联一个公钥 cosmosvalconspub(要获取该值,请运行 gaiad tendermint show-validator)
    • 它会在使用 gaiad init 创建节点时生成。
  • 应用密钥:该密钥由 gaiad 二进制创建,用于签署交易。应用密钥关联的公钥以前缀 cosmospub 开头,地址以前缀 cosmos 开头。
Tendermint/CometBFT 密钥和应用密钥都派生自通过 gaiad keys add 命令生成的账户密钥。 注意: 验证人的 operator key 直接关联到一个应用密钥,并使用专门为此保留的 cosmosvaloper 和 cosmosvaloperpub 前缀。

验证人可能处于哪些不同状态?

验证人通过 create-validator 交易创建后,会处于以下三种状态之一:
  • in validator set:验证人在活跃集合中并参与共识。验证人会获得奖励,并可能因不当行为被罚没。
  • jailed:验证人存在不当行为,已被关禁闭,即处于验证人集合之外。
    • 如果被关禁闭是因为离线时间过长(即在最近 10,000 个区块中错过超过 95%),验证人可以发送 unjail 交易以重新进入验证人集合。
    • 如果被关禁闭是因为双签,验证人将无法解除关禁闭。
  • unbonded:验证人不在活跃集合中,因此不会签署区块。验证人不会被罚没,也不会获得任何奖励。仍然可以向 unbonded 状态的验证人委托 ATOM。从 unbonded 验证人处撤销委托是立即生效的,也就是说这些代币不受解绑期限制。

什么是自我委托?如何增加我的自我委托?

自我委托是指验证人将 ATOM 委托给自己。可以使用你的验证人 application 应用密钥发送 delegate 交易来增加委托数量。

什么是 validator bond?如何增加我的 validator bond?

validator bond 是委托人向验证人委托 ATOM 的一种方式。验证人运营者也可以向自己进行 validator bond。可以从任何已委托给你的验证人的账户发送 ValidatorBond 交易,以增加 validator bond 数量。在验证人接受来自流动性质押提供方的委托之前,必须先具备 validator bond。因此,这会要求验证人先投入自身利益,才能被流动性质押提供方托付委托。这会抑制恶意行为,并使验证人能够与流动性质押提供方协商其合作关系。

成为活跃(已绑定)验证人,是否有必须委托的最少 ATOM 数量?

最低值是 1 ATOM。但当前网络的安全实际上由远高于此的数值支撑。你可以在 Mintscan 验证人页面查看进入活跃验证人集合所需的最低 ATOM 数量。

委托人如何选择他们的验证人?

委托人可以根据自己的主观标准自由选择验证人。选择标准包括:
  • 验证人已进行 validator bond 的 ATOM 数量: 验证人向自己进行 validator bond 的 ATOM 数量。更高的自我委托 ATOM 数量表明验证人愿意共同承担自身行为带来的风险和后果,或者其在社区中拥有足够的信誉,以至于其他人愿意代表该验证人提供 validator bond。
  • 已委托的 ATOM 数量: 委托给某个验证人的 ATOM 总量。较高的投票权说明社区信任该验证人。但更大的验证人也会降低网络的去中心化程度,因此建议委托人考虑将 ATOM 委托给规模较小的验证人。
  • 佣金率: 验证人在将收益分配给委托人之前,对收益收取的佣金比例。
  • 历史表现: 委托人会审查计划委托对象验证人的过往记录。这些记录包括过去对提案的投票情况以及历史平均在线率。
  • 社区贡献: 另一项(更主观的)标准是验证人为社区作出的贡献,例如教育内容、参与社区渠道、对开源软件的贡献等。
除了这些标准之外,验证人还会发送 create-validator 交易来提供网站地址,以完善自己的履历。验证人必须通过某种方式建立声誉,才能吸引委托人。例如,一个良好的做法是让第三方审计其配置。不过请注意,CometBFT 团队本身既不认可也不执行任何审计。有关尽职调查的更多信息,请参见博客文章 A Delegator’s Guide to Staking。

职责

验证人是否需要公开身份?

不需要。每个委托人都可以根据自己的标准来评估验证人。验证人在自我提名时可以登记一个网站地址,以便按自己的意愿宣传其运营情况。有些委托人更偏好网站上清晰展示验证人运营团队及其履历,而另一些验证人则可能更倾向于以拥有良好历史表现的匿名验证人身份出现。

验证人的职责是什么?

验证人有两项主要职责:
  • 能够持续运行正确版本的软件: 验证人必须确保其服务器始终在线,并且其私钥没有泄露。
  • 积极参与治理: 验证人必须对每一项提案进行投票。
此外,验证人还应当成为社区中的活跃成员。验证人必须始终了解生态系统的当前状态,以便能够轻松适应任何变化。

“参与治理”具体包括什么?

Cosmos Hub 上的验证者和委托人可以对提案进行投票,以更改运行参数(例如区块 gas 上限)、协调升级,或就任何特定事项作出决定。 验证者在治理系统中扮演特殊角色。作为系统支柱,验证者必须对每一项提案投票。这一点尤为重要,因为未投票的委托人会继承其验证者的投票结果。

质押意味着什么?

质押 ATOM 可以被视为对验证活动的一笔安全保证金。当验证者或委托人想取回部分或全部保证金时,他们会发送一笔 unbonding 交易。随后,这些 ATOM 会进入 3 周的解绑期;在此期间,如果验证者在解绑流程开始前存在潜在的不当行为,这些 ATOM 仍可能被罚没。 验证者及其关联的委托人会获得区块奖励、手续费,并有权参与治理。如果验证者出现不当行为,其总质押中的一部分会被罚没。这意味着,所有向该验证者绑定 ATOM 的委托人,都会按其绑定质押的比例受到惩罚。因此,委托人会被激励将代币委托给他们预期能够安全运行的验证者。

验证者能带着其委托人的 ATOM 跑掉吗?

通过向验证者委托,用户委托的是投票权。验证者拥有的投票权越多,其在共识和治理过程中的权重就越大。这并不意味着验证者托管了其委托人的 ATOM。验证者无法带走其委托人的资金。 尽管委托资金不会被验证者窃取,但如果验证者遭遇罚没事件,委托人的代币仍可能被按较小比例罚没,这也是为什么我们鼓励在选择验证者时做好尽职调查。

验证者多久会被选中提议下一个区块一次?频率会随着已绑定 ATOM 数量增加而提高吗?

被选中提议下一个区块的验证者称为提议者。每个提议者都是按确定性方式选出的。被选中的频率与验证者的投票权(即已绑定的 ATOM 数量)成正比。例如,如果所有验证者的总绑定质押为 100 ATOM,而某个验证者的总质押为 10 ATOM,那么该验证者将提议约 ~10% 的区块。

Cosmos Hub 的验证者是否必须验证 Cosmos 生态中的其他区块链?

这取决于情况,目前不要求验证者去验证其他区块链。但是,当 Cosmos Hub 上线首个版本的跨链安全时,委托人可以投票决定是否让某些区块链通过跨链安全获得保护。在这些情况下,验证者也必须在这些链上执行验证。

验证者如何安全地退出 Cosmos Hub 的验证?

如果验证者只是简单关闭其节点,这会导致验证者及其委托人因离线而被罚没。在 Cosmos Hub 上安全退出验证者节点的唯一方式,是通过 UnbondValidator 消息对验证者执行解绑。这样一来,验证者会被监禁并移出活跃验证者集合,但不会被罚没。随后,他们便可以关闭节点,而无需承担代币受损的风险。 强烈建议在这样做时通知你的委托人,因为在验证者被监禁后,他们仍会继续绑定在你的验证者名下。他们需要手动解绑,而且他们偏好的钱包应用可能不会提醒到这一点。

激励

质押的激励是什么?

验证者质押池中的每个成员都会获得不同类型的收益:
  • 区块奖励: 由验证者运行的应用的原生代币(例如 Cosmos Hub 上的 ATOM)会通过增发产生区块奖励。这些奖励的存在,是为了激励 ATOM 持有者绑定其质押。未绑定的 ATOM 会随着时间被稀释。
  • 交易手续费: Cosmos Hub 维护了一份可用于支付手续费的代币许可列表。初始手续费代币是 atom。
这部分总收益会按照各验证者的权重分配到各自的质押池中。随后,在每个验证者的质押池内部,收益会按各委托人的质押占比分配。分配前,验证者会先从委托人应得的收益中收取佣金。

什么是验证者佣金?

验证者质押池获得的收益会在验证者及其委托人之间分配。验证者可以对分配给委托人的那部分收益收取佣金。该佣金以百分比表示。每个验证者都可以自由设置其初始佣金、每日最大佣金变更率以及最大佣金。Cosmos Hub 会强制执行每个验证者自行设置的这些参数。最大佣金上限一经设定便不可更改。不过,只要不超过最大佣金,验证者创建后仍可以调整实际佣金率。

运行验证者的激励是什么?

由于验证者会从其委托人的质押奖励中收取佣金,因此他们获得的收益按比例高于委托人。 验证者在治理中也发挥着重要作用。如果委托人不投票,他们会继承验证者的投票结果。这种投票继承机制使验证者在生态中承担重大责任。

区块奖励如何分配?

区块奖励会按照投票权比例分配给所有验证者。这意味着,尽管每个验证者都会随每次奖励获得 ATOM,但所有验证者的相对权重会随着时间保持不变。 例如,10 个验证者拥有相同的投票权,佣金率均为 1%。在这个例子中,一个区块的奖励为 1000 ATOM,且每个验证者都有 20% 的自质押 ATOM。这些代币不会直接给到提议者。相反,它们会平均分配给所有验证者。因此,每个验证者的质押池现在都有 100 ATOM。这 100 ATOM 会按照每个参与者的质押占比分配:
  • 佣金:100*80%*1% = 0.8 ATOM
  • 验证者获得:100\*20% + Commission = 20.8 ATOM
  • 所有委托人获得:100\*80% - Commission = 79.2 ATOM
随后,每个委托人都可以按其在验证者质押池中的质押占比,领取 79.2 ATOM 中属于自己的部分。

手续费如何分配?

手续费的分配方式类似,不同之处在于:如果区块提议者包含的预提交超过严格要求的最低数量,那么它可以从自己提议区块的手续费中获得额外奖金。 当某个验证者被选为下一个区块的提议者时,它必须至少包含前一个区块 2/3 的预提交。然而,包含超过 2/3 的预提交会带来额外奖金。该奖金是线性的:如果提议者包含 2/3 的预提交(区块有效所需的最低值),奖金为 1%;如果包含 100% 的预提交,奖金为 5%。当然,提议者也不能等待过久,否则其他验证者可能会超时并轮到下一位提议者。因此,验证者需要在等待更多签名与错失下一个区块提议机会的风险之间取得平衡。该机制旨在激励提出非空区块、改善验证者之间的网络连接,并减轻审查。 为了用一个具体例子说明上述概念,假设有 10 个质押数量相同的验证者。每个验证者的佣金率均为 1%,并且有 20% 的自委托 ATOM。现在有一个成功出块,共收取 1025.51020408 ATOM 手续费。 首先,会征收 2% 的税。对应的 ATOM 会进入储备池。储备池中的资金可以通过治理分配,用于资助赏金和升级。
  • 2% * 1025.51020408 = 20.51020408 ATOM 会进入储备池。
现剩余 1005 ATOM。在本例中,提议者在其区块中包含了 100% 的签名,因此可获得 5% 的全部奖金。 通过下面这个简单方程可以求出每个验证者的奖励 R: 9*R + R + R*5% = 1005 ⇔ R = 1005/10.05 = 100
  • 对于提议验证者:
    • 质押池获得 R + R * 5%:105 ATOM
    • 佣金:105 * 80% * 1% = 0.84 ATOM
    • 验证者奖励:105 * 20% + Commission = 21.84 ATOM
    • 委托人奖励:105 * 80% - Commission = 83.16 ATOM(每个委托人都可以按其质押占比领取其中属于自己的部分)
  • 对于每个非提议验证者:
    • 质押池获得 R:100 ATOM
    • 佣金:100 * 80% * 1% = 0.8 ATOM
    • 验证者奖励:100 * 20% + Commission = 20.8 ATOM
    • 委托人奖励:100 * 80% - Commission = 79.2 ATOM(每个委托人都可以按其质押占比领取其中属于自己的部分)

罚没条件是什么?

如果验证者出现不当行为,其被委托的质押会被部分罚没。以下两类故障会导致验证者及其委托人的资金被罚没:
  • 双重签名: 如果有人在链 A 上报告某个验证者在链 A 和链 B 上对同一高度的两个区块进行了签名,并且链 A 与链 B 共享共同祖先,那么该验证者会在链 A 上被罚没 5%。
  • 宕机: 如果验证者在最近 10,000 个区块中错过超过 95%(约 ~19 小时),则会被罚没 0.01%。

验证者是否必须自委托 ATOM?

不,他们不需要自委托。尽管验证者没有义务进行自委托,但委托人可能希望其验证者在质押池中持有自委托的 ATOM。换句话说,验证者也要共同承担风险。 不过请注意,出于安全原因,一些验证者也可能选择通过不同地址进行自委托。

如何防止质押集中到少数头部验证者手中?

社区应当以聪明且自我保护的方式行事。当比特币中的某个矿池获得过多算力时,社区通常会停止向该矿池贡献算力。Cosmos Hub 依赖同样的效应。此外,当委托人切换到其他验证者时,他们无需经历解绑期,这消除了为了提升去中心化而快速重新委托代币的障碍。

流动性质押模块

什么是流动性质押模块?

流动性质押模块是一组安全特性,通过以下方式缓解流动性质押风险:
  • 将可进行流动性质押的代币总量限制为全部已质押代币的 X%。
  • 引入一项要求:验证者必须绑定验证者保证金代币,才有资格接收来自流动性质押提供方的委托。
  • 将验证者份额中可进行流动性质押的部分限制为其总份额的 X%。
流动性质押模块还通过在有限场景下让委托可转移来改进流动性质押的用户体验,从而允许委托人将其委托转换为流动性质押头寸,而无需等待解绑期。 如需详细的技术说明,请参阅 Cosmos SDK 中的 ADR-061,或流动性质押模块在 Cosmos Hub 上的论坛帖子。

谁可以进行验证者绑定?

验证者本人可以,其他任何委托给该验证者的地址也可以。

如何进行验证者绑定?

在向某个验证者完成委托后,委托人(或验证者运营者)可以通过签署一条 ValidatorBond 消息,将其对该验证者的委托转换为验证者绑定。 ValidatorBond 消息由质押模块提供,可按如下方式执行:
gaiad tx staking validator-bond cosmosvaloper13h5xdxhsdaugwdrkusf8lkgu406h8t62jkqv3h <delegator> --from mykey  
验证者绑定不支持部分转换:当委托人或验证者将其在某个特定验证者上的份额转换为验证者绑定时,其对该验证者的全部委托都会被转换为验证者绑定。如果验证者或委托人只希望将部分委托转换为验证者绑定,应先将这部分资金转移到一个单独地址,再从该地址执行验证者绑定;或者在将委托转换为验证者绑定之前,先把不想用于验证者绑定的资金重新委托给其他验证者。 要将验证者绑定转换回标准委托,只需解除这些份额的绑定。

委托人或验证者如何将其委托标记为验证者绑定?

在向某个验证者完成委托后,签署一条 ValidatorBond 消息即可。

验证者绑定是否适用额外的罚没条件?

不会。在发生罚没时,验证者绑定的罚没比例与普通绑定相同。

我可以解除我的验证者绑定吗?

如果某个验证者的验证者绑定所提供的全部流动性质押容量都已被使用,则委托给该验证者的验证者绑定无法解除。如果有新的容量可用(无论是由于流动性质押代币被赎回,还是新增了验证者绑定),则现有的验证者绑定就可以取消委托。 示例:假设验证者绑定系数为 250,验证者 V 绑定了 2 ATOM,此时流动性质押提供方会向验证者 V 委托 500 ATOM。现在,验证者 V 无法移除其任何验证者绑定,因为验证者 V 的验证者绑定所提供的全部流动性质押容量都已被占用。 如果流动性质押提供方向验证者 V 解除委托 250 ATOM,那么验证者 V 现在可以移除 1 ATOM 的验证者绑定。 相反,如果 ICF 或某位社区成员再向验证者 V 增加 1 ATOM 的验证者绑定,那么验证者 V 现在也可以移除 1 ATOM 的验证者绑定。

我可以将一部分代币用于验证者绑定,剩余部分按普通方式委托吗?

ValidatorBond 消息会将委托给某个验证者的全部余额转换为验证者绑定。若要将部分代币用于验证者绑定、其余部分按普通方式委托,请使用两个地址:第一个地址用于委托并执行 ValidatorBond,第二个地址仅用于普通委托。

技术要求

硬件要求是什么?

初期所需的硬件规格适中,并会随着网络使用量增加而提升。参与测试网是进一步了解相关要求的最佳方式。你可以在加入主网文档中查看当前的硬件建议。 建议验证者部署哨兵节点,以保护验证者节点免受 DDoS 攻击。

软件要求是什么?

除了运行 Cosmos Hub 节点之外,验证者还应实现监控、告警和管理方案。你可以使用若干工具。

带宽要求是什么?

相较于以太坊或比特币等链,Cosmos 网络具备非常高的吞吐能力。 我们建议数据中心中的节点仅连接到云中的可信全节点,或连接到彼此在线下有社会信任关系的其他验证者。这样的连接策略可以减轻数据中心节点缓解拒绝服务攻击的负担。 最终,随着网络使用量不断增加,每天需要数 GB 带宽是非常现实的情况。

如何进行密钥管理?

验证者应运行支持 ed25519 密钥的 HSM。可选方案包括:
  • YubiHSM 2
  • Ledger Nano S
  • Ledger BOLOS SGX enclave
  • Thales nShield support
Interchain Foundation 不会推荐某一种方案优于其他方案。我们鼓励社区继续加强相关工作,以改进 HSM 和密钥管理的安全性。

验证者在运维方面应有哪些预期?

运行高效的运维体系,是避免意外解除绑定或被罚没的关键。运维必须能够响应攻击和故障,同时维持数据中心中的安全性与隔离性。

维护要求是什么?

验证者应定期进行软件更新,以适配链升级和缺陷修复。建议考虑使用 Cosmovisor 对这一过程进行部分自动化。 在链升级期间,相关进展会在 Interchain Discord 的私密频道中讨论。如果你的验证者位于活跃集内,我们鼓励你联系版主申请加入该频道。

验证者如何保护自己免受拒绝服务攻击?

拒绝服务攻击是指攻击者向某个 IP 地址发送海量互联网流量,从而阻止该 IP 地址上的服务器连接到互联网。 攻击者会扫描网络,试图获知各个验证者节点的 IP 地址,并通过流量洪泛切断它们的通信连接。 一种推荐的缓解方式,是让验证者使用哨兵节点架构来谨慎设计其网络拓扑。 验证者节点通常只应连接到其信任的全节点,因为这些全节点要么由验证者自己运营,要么由其在线下有社会信任关系的其他验证者运营。验证者节点通常运行在数据中心中。大多数数据中心都会提供到主要云服务提供商网络的直连链路。验证者可以利用这些链路连接到云中的哨兵节点。这样做可将拒绝服务攻击的压力从验证者节点本身转移到其哨兵节点上,同时也可能要求在现有哨兵节点遭受攻击时快速启动或启用新的哨兵节点。 哨兵节点可以快速启动,也可以更换其 IP 地址。由于通往哨兵节点的链路位于私有 IP 空间中,基于互联网的攻击无法直接干扰这些链路。这种策略能够显著提高验证者区块提案和投票成功传递到网络其余部分的概率。 有关哨兵节点的更多细节,请参阅CometBFT 文档或论坛中的哨兵节点架构概览。

Disclaimer

This is work in progress. Mechanisms and values are susceptible to change.

General Concepts

What is a Cosmos validator?

The Cosmos Hub is based on CometBFT that relies on a set of validators to secure the network. The role of validators is to run a full node and participate in consensus by broadcasting votes that contain cryptographic signatures signed by the validator’s private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. Validators must also participate in governance by voting on proposals. Validators are weighted according to their total stake.

What is staking?

The Cosmos Hub is a public Proof-Of-Stake (PoS) blockchain, meaning that the weight of validators is determined by the amount of staking tokens (ATOM) bonded as collateral. These ATOM tokens can be self-delegated directly by the validator or delegated to the validator by other ATOM holders. Any user in the system can declare their intention to become a validator by sending a create-validator transaction to become validator candidates. The weight (i.e. voting power) of a validator determines whether they are an active validator. The active validator set is limited to an amount that changes over time.

What is a full node?

A full node is a server running a chain’s binary (its software) that fully validates transactions and blocks of a blockchain and keeps a full record of all historic activity. A full node is distinct from a pruned node that processes only block headers and a small subset of transactions. Running a full node requires more resources than a pruned node. Validators can decide to run either a full node or a pruned node, but they need to make sure they retain enough blocks to be able to validate new blocks. Of course, it is possible and encouraged for users to run full nodes even if they do not plan to be validators. You can find more details about the requirements in the Joining Mainnet Tutorial.

What is a delegator?

Delegators are ATOM holders who cannot, or do not want to, run a validator themselves. ATOM holders can delegate ATOM to a validator and obtain a part of their revenue in exchange. For details on how revenue is distributed, see What is the incentive to stake? and What are validators commission? in this document. Because delegators share revenue with their validators, they also share risks. If a validator misbehaves, each of their delegators are partially slashed in proportion to their delegated stake. This penalty is one of the reasons why delegators must perform due diligence on validators before delegating. Spreading their stake over multiple validators is another layer of protection. Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role. Delegators must actively monitor the actions of their validators and participate in governance. For details on being a delegator, read the Delegator FAQ.

Becoming a Validator

How to become a validator?

Any participant in the network can signal that they want to become a validator by sending a create-validator transaction, where they must fill out the following parameters:
  • Validator’s PubKey: The private key associated with this Tendermint/CometBFT PubKey is used to sign prevotes and precommits.
  • Validator’s Address: Application level address that is used to publicly identify your validator. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance.
  • Validator’s name (moniker)
  • Validator’s website (Optional)
  • Validator’s description (Optional)
  • Initial commission rate: The commission rate on block rewards and fees charged to delegators.
  • Maximum commission: The maximum commission rate that this validator can charge. This parameter is fixed and cannot be changed after the create-validator transaction is processed.
  • Commission max change rate: The maximum daily increase of the validator commission. This parameter is fixed cannot be changed after the create-validator transaction is processed.
After a validator is created, ATOM holders can delegate ATOM to them, effectively adding stake to the validator’s pool. The total stake of an address is the combination of ATOM bonded by delegators and ATOM self-bonded by the validator. From all validator candidates that signaled themselves, the 180 validators with the most total stake are the designated validators. If a validator’s total stake falls below the top 180, then that validator loses its validator privileges. The validator cannot participate in consensus or generate rewards until the stake is high enough to be in the top 180. Over time, the maximum number of validators may be increased via on-chain governance proposal.

Testnet

How can I join the testnet?

The testnet is a great environment to test your validator setup before launch. Testnet participation is a great way to signal to the community that you are ready and able to operate a validator. For details, see Join the Public Testnet documentation.

Additional Concepts

What are the different types of keys?

There are two types of keys:
  • Tendermint/CometBFT key: A unique key that is used to sign consensus votes.
    • It is associated with a public key cosmosvalconspub (To get this value, run gaiad tendermint show-validator)
    • It is generated when the node is created with gaiad init.
  • Application key: This key is created from the gaiad binary and is used to sign transactions. Application keys are associated with a public key that is prefixed by cosmospub and an address that is prefixed by cosmos.
The Tendermint/CometBFT key and the application key are derived from account keys that are generated by the gaiad keys add command. Note: A validator’s operator key is directly tied to an application key and uses the cosmosvaloper and cosmosvaloperpub prefixes that are reserved solely for this purpose.

What are the different states a validator can be in?

After a validator is created with a create-validator transaction, the validator is in one of three states:
  • in validator set: Validator is in the active set and participates in consensus. The validator is earning rewards and can be slashed for misbehavior.
  • jailed: Validator misbehaved and is in jail, i.e. outside of the validator set.
    • If the jailing is due to being offline for too long (i.e. having missed more than 95% out of the last 10,000 blocks), the validator can send an unjail transaction in order to re-enter the validator set.
    • If the jailing is due to double signing, the validator cannot unjail.
  • unbonded: Validator is not in the active set, and therefore not signing blocks. The validator cannot be slashed and does not earn any reward. It is still possible to delegate ATOM to an unbonded validator. Undelegating from an unbonded validator is immediate, meaning that the tokens are not subject to the unbonding period.

What is self-delegation? How can I increase my self-delegation?

Self-delegation is a delegation of ATOM from a validator to themselves. The delegated amount can be increased by sending a delegate transaction from your validator’s application application key.

What is validator bond? How can I increase my validator bond?

Validator bond is a delegation of ATOM from a delegator to a validator. Validator operators can validator bond to themselves. The validator bond amount can be increased by sending a ValidatorBond transaction from any account delegated to your validator. Validator bond is required before a validator can accept delegations from liquid staking providers. As such it forces validators to put “skin in the game” in order to be entrusted with delegations from liquid staking providers. This disincentivizes malicious behavior and enables the validator to negotiate its relationship with liquid staking providers.

Is there a minimum amount of ATOM that must be delegated to be an active (bonded) validator?

The minimum is 1 ATOM. But the network is currently secured by much higher values. You can check the minimum required ATOM to become part of the active validator set on the Mintscan validator page.

How do delegators choose their validators?

Delegators are free to choose validators according to their own subjective criteria. Selection criteria includes:
  • Amount of validator-bonded ATOM: Number of ATOM a validator validator-bonded to themselves. A validator with a higher amount of self-delegated ATOM indicates that the validator is sharing the risk and consequences for their actions, or has enough goodwill from the community so that others post validator bond on the validator’s behalf.
  • Amount of delegated ATOM: Total number of ATOM delegated to a validator. A high voting power shows that the community trusts this validator. Larger validators also decrease the decentralization of the network, so delegators are suggested to consider delegating to smaller validators.
  • Commission rate: Commission applied on revenue by validators before the revenue is distributed to their delegators.
  • Track record: Delegators review the track record of the validators they plan to delegate to. This track record includes past votes on proposals and historical average uptime.
  • Community contributions: Another (more subjective) criteria is the work that validators have contributed to the community, such as educational content, participation in the community channels, contributions to open source software, etc.
Apart from these criteria, validators send a create-validator transaction to signal a website address to complete their resume. Validators must build reputation one way or another to attract delegators. For example, a good practice for validators is to have a third party audit their setup. Note though, that the CometBFT team does not approve or conduct any audits themselves. For more information on due diligence, see the A Delegator’s Guide to Staking blog post.

Responsibilities

Do validators need to be publicly identified?

No, they do not. Each delegator can value validators based on their own criteria. Validators are able to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators prefer a website that clearly displays the team operating the validator and their resume, while other validators might prefer to be anonymous validators with positive track records.

What are the responsibilities of a validator?

Validators have two main responsibilities:
  • Be able to constantly run a correct version of the software: Validators must ensure that their servers are always online and their private keys are not compromised.
  • Actively participate in governance: Validators are required to vote on every proposal.
Additionally, validators are expected to be active members of the community. Validators must always be up-to-date with the current state of the ecosystem so that they can easily adapt to any change.

What does ‘participate in governance’ entail?

Validators and delegators on the Cosmos Hub can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, or make a decision on any given matter. Validators play a special role in the governance system. As pillars of the system, validators are required to vote on every proposal. It is especially important since delegators who do not vote inherit the vote of their validator.

What does staking imply?

Staking ATOM can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, ATOM undergoes a 3-week unbonding period during which they are liable to being slashed for potential misbehaviors committed by the validator before the unbonding process started. Validators, and by association delegators, receive block rewards, fees, and have the right to participate in governance. If a validator misbehaves, a certain portion of their total stake is slashed. This means that every delegator that bonded ATOM to this validator gets penalized in proportion to their bonded stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely.

Can a validator run away with their delegators’ ATOM?

By delegating to a validator, a user delegates voting power. The more voting power a validator have, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators’ ATOM. A validator cannot run away with its delegator’s funds. Even though delegated funds cannot be stolen by their validators, delegators’ tokens can still be slashed by a small percentage if their validator suffers a slashing event, which is why we encourage due diligence when selecting a validator.

How often is a validator chosen to propose the next block? Does frequency increase with the quantity of bonded ATOM?

The validator that is selected to propose the next block is called the proposer. Each proposer is selected deterministically. The frequency of being chosen is proportional to the voting power (i.e. amount of bonded ATOM) of the validator. For example, if the total bonded stake across all validators is 100 ATOM and a validator’s total stake is 10 ATOM, then this validator is the proposer ~10% of the blocks.

Are validators of the Cosmos Hub required to validate other zones in the Cosmos ecosystem?

This depends, currently no validators are required to validate other blockchains. But when the first version of Interchain Security is launched on the Cosmos Hub, delegators can vote to have certain blockchains secured via Interchain Security. In those cases, validators are required to validate on these chains as well.

How can a validator safely quit validating on the Cosmos Hub?

If a validator simply shuts down their node, this would result in the validator and their delegators getting slashed for being offline. The only way to safely exit a validator node running on the Cosmos Hub is by unbonding the validator with the UnbondValidator message. As a result, the validator gets jailed and kicked out of the active set of validators, without getting slashed. They can then proceed to shut down their node without risking their tokens. It’s highly advised to inform your delegators when doing this, as they will still be bonded to your validator after it got jailed. They will need to manually unbond and they might not have been made aware of this via their preferred wallet application.

Incentives

What is the incentive to stake?

Each member of a validator’s staking pool earns different types of revenue:
  • Block rewards: Native tokens of applications (e.g. ATOM on the Cosmos Hub) run by validators are inflated to produce block provisions. These provisions exist to incentivize ATOM holders to bond their stake. Non-bonded ATOM are diluted over time.
  • Transaction fees: The Cosmos Hub maintains an allow list of tokens that are accepted as fee payment. The initial fee token is the atom.
This total revenue is divided among validators’ staking pools according to each validator’s weight. Then, within each validator’s staking pool the revenue is divided among delegators in proportion to each delegator’s stake. A commission on delegators’ revenue is applied by the validator before it is distributed.

What is a validator commission?

Revenue received by a validator’s pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate, and maximum commission. The Cosmos Hub enforces the parameter that each validator sets. The maximum commission rate is fixed and cannot be changed. However, the commission rate itself can be changed after the validator is created as long as it does not exceed the maximum commission.

What is the incentive to run a validator?

Validators earn proportionally more revenue than their delegators because of the commission they take on the staking rewards from their delegators. Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This voting inheritance gives validators a major responsibility in the ecosystem.

How are block rewards distributed?

Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains ATOM with each reward, all validators maintain equal weight over time. For example, 10 validators have equal voting power and a commission rate of 1%. For this example, the reward for a block is 1000 ATOM and each validator has 20% of self-bonded ATOM. These tokens do not go directly to the proposer. Instead, the tokens are evenly spread among validators. So now each validator’s pool has 100 ATOM. These 100 ATOM are distributed according to each participant’s stake:
  • Commission: 100*80%*1% = 0.8 ATOM
  • Validator gets: 100\*20% + Commission = 20.8 ATOM
  • All delegators get: 100\*80% - Commission = 79.2 ATOM
Then, each delegator can claim their part of the 79.2 ATOM in proportion to their stake in the validator’s staking pool.

How are fees distributed?

Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if the proposer includes more than the strict minimum of required precommits. When a validator is selected to propose the next block, the validator must include at least 2/3 precommits of the previous block. However, an incentive to include more than 2/3 precommits is a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer must not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators, and mitigates censorship. For a concrete example to illustrate the aforementioned concept, there are 10 validators with equal stake. Each validator applies a 1% commission rate and has 20% of self-delegated ATOM. Now comes a successful block that collects a total of 1025.51020408 ATOM in fees. First, a 2% tax is applied. The corresponding ATOM go to the reserve pool. The reserve pool’s funds can be allocated through governance to fund bounties and upgrades.
  • 2% * 1025.51020408 = 20.51020408 ATOM go to the reserve pool.
1005 ATOM now remain. For this example, the proposer included 100% of the signatures in its block so the proposer obtains the full bonus of 5%. To solve this simple equation to find the reward R for each validator: 9*R + R + R*5% = 1005 ⇔ R = 1005/10.05 = 100
  • For the proposer validator:
    • The pool obtains R + R * 5%: 105 ATOM
    • Commission: 105 * 80% * 1% = 0.84 ATOM
    • Validator’s reward: 105 * 20% + Commission = 21.84 ATOM
    • Delegators’ rewards: 105 * 80% - Commission = 83.16 ATOM (each delegator is able to claim its portion of these rewards in proportion to their stake)
  • For each non-proposer validator:
    • The pool obtains R: 100 ATOM
    • Commission: 100 * 80% * 1% = 0.8 ATOM
    • Validator’s reward: 100 * 20% + Commission = 20.8 ATOM
    • Delegators’ rewards: 100 * 80% - Commission = 79.2 ATOM (each delegator is able to claim their portion of these rewards in proportion to their stake)

What are the slashing conditions?

If a validator misbehaves, their delegated stake is partially slashed. Two faults can result in slashing of funds for a validator and their delegators:
  • Double signing: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator gets slashed by 5% on chain A.
  • Downtime: If a validator misses more than 95% of the last 10,000 blocks (roughly ~19 hours), they are slashed by 0.01%.

Are validators required to self-delegate ATOM?

No, they do not need to self-delegate. Even though there is no obligation for validators to self-delegate, delegators may want their validator to have self-delegated ATOM in their staking pool. In other words, validators share the risk. Note however that it’s possible that some validators decide to self-delegate via a different address for security reasons.

How to prevent concentration of stake in the hands of a few top validators?

The community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool. The Cosmos Hub relies on the same effect. Additionally, when delegators switch to another validator, they are not subject to the unbonding period, which removes any barrier to quickly redelegating tokens in service of improving decentralization.

Liquid Staking Module

What is the liquid staking module?

The Liquid Staking Module is a set of safety features that mitigate liquid staking risks by:
  • limiting the total amount of tokens that can be liquid staked to X% of all staked tokens.
  • introducing a requirement that validators validator-bond tokens to be eligible for delegations from liquid staking providers.
  • limiting the portion of validators’s shares that can be liquid staked to X% of their total shares.
The Liquid Staking Module also improves liquid staking UX by making delegations transferable under limited scenarios, to allow delegators to convert their delegations into liquid staking positions without having to wait the unbonding period. For a detailed and technical description, please see ADR-061 in the Cosmos SDK or the Liquid Staking Module Cosmos Hub forum post.

Who can validator bond?

The validator themselves, but also any other address delegated to the validator.

How can I validator bond?

Once delegated to a validator, a delegator (or validator operator) can convert their delegation to a validator into Validator Bond by signing a ValidatorBond message. The ValidatorBond message is exposed by the staking module and can be executed as follows:
gaiad tx staking validator-bond cosmosvaloper13h5xdxhsdaugwdrkusf8lkgu406h8t62jkqv3h <delegator> --from mykey  
There are no partial Validator Bonds: when a delegator or validator converts their shares to a particular validator into Validator Bond, their entire delegation to that validator is converted to Validator Bond. If a validator or delegator wishes to convert only some of their delegation to Validator Bond, they should transfer those funds to a separate address and Validator Bond from that address, or redelegate the funds that they do not wish to validator bond to another validator before converting their delegation to validator bond. To convert Validator Bond back into a standard delegation, simply unbond the shares.

How does a delegator or validator mark their delegation as a validator bond?

Once delegated to a validator, sign a ValidatorBond message.

Are validator bonds subject to additional slashing conditions?

No, in the event of a slash, a validator bond is slashed at the same rate as a regular bond.

Can I unbond my validator bond?

If all the liquid staking capacity made available by a validator’s validator bond is utilized, validator bond delegated to that validator cannot be unbonded. If new capacity becomes available (either by redemption of liquid staking tokens or addition or new validator bond), then existing validator bond can be undelegated. Example: Suppose the validator bond factor is 250 and Validator V bonds 2 ATOM, then liquid staking providers delegate 500 ATOM to Validator V. Now Validator V cannot remove any of their validator bond because the full liquid staking capacity made available by Validator V’s validator bond is consumed. If liquid staking providers undelegate 250 ATOM from Validator V, Validator V can now remove 1 ATOM of validator bond. If, instead, the ICF or a community member validator bonds 1 additional ATOM to Validator V, Validator V can now remove 1 ATOM of validator bond.

Can I validator bond some of my tokens and delegate the remaining portion normally?

The ValidatorBond message converts the full balance delegated to a validator into validator bond. To validator bond some tokens and delegate the remaining portion normally, use two addresses: the first will delegate + ValidatorBond, and the second will just delegate.

Technical Requirements

What are hardware requirements?

A modest level of hardware specifications is initially required and rises as network use increases. Participating in the testnet is the best way to learn more. You can find the current hardware recommendations in the Joining Mainnet documentation. Validators are recommended to set up sentry nodes to protect your validator node from DDoS attacks.

What are software requirements?

In addition to running a Cosmos Hub node, validators are expected to implement monitoring, alerting, and management solutions. There are several tools that you can use.

What are bandwidth requirements?

The Cosmos network has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. We recommend that the data center nodes connect only to trusted full nodes in the cloud or other validators that know each other socially. This connection strategy relieves the data center node from the burden of mitigating denial-of-service attacks. Ultimately, as the network becomes more heavily used, multigigabyte per day bandwidth is very realistic.

How to handle key management?

Validators are expected to run an HSM that supports ed25519 keys. Here are potential options:
  • YubiHSM 2
  • Ledger Nano S
  • Ledger BOLOS SGX enclave
  • Thales nShield support
The Interchain Foundation does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management.

What can validators expect in terms of operations?

Running an effective operation is key to avoiding unexpected unbonding or slashing. Operations must be able to respond to attacks and outages, as well as maintain security and isolation in the data center.

What are the maintenance requirements?

Validators are expected to perform regular software updates to accommodate chain upgrades and bug fixes. It is suggested to consider using Cosmovisor to partially automate this process. During an chain upgrade, progress is discussed in a private channel in the Interchain Discord. If your validator is in the active set we encourage you to request access to that channel by contacting a moderator.

How can validators protect themselves from denial-of-service attacks?

Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet. An attacker scans the network, tries to learn the IP address of various validator nodes, and disconnects them from communication by flooding them with traffic. One recommended way to mitigate these risks is for validators to carefully structure their network topology using a sentry node architecture. Validator nodes are expected to connect only to full nodes they trust because they operate the full nodes themselves or the trust full nodes are run by other validators they know socially. A validator node is typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This mitigation shifts the burden of denial-of-service from the validator’s node directly to its sentry nodes, and can require that new sentry nodes are spun up or activated to mitigate attacks on existing ones. Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet-based attack cannot disturb them directly. This strategy ensures that validator block proposals and votes have a much higher chance to make it to the rest of the network. For more sentry node details, see the CometBFT Documentation or the Sentry Node Architecture Overview on the forum.