变更记录
- 2022-09-10：初始草案 (@zmanian)
状态
已接受摘要
为默认的 Cosmos SDK 质押模块增加一种半同质化的流动性质押原语。此变更升级了权益证明机制，使其能够支持更安全的设计、降低整体货币发行量，并可与 Stride、Persistence、Quicksilver、Lido 等众多流动性质押协议集成。背景
Cosmos Hub 的最初版本实现了一种开创性的权益证明机制，包含委托、惩罚、协议内奖励分配以及自适应发行。对于 2016 年而言，这一设计代表了最先进水平，并已被许多 L1 区块链在没有重大修改的情况下部署使用。 随着权益证明和区块链使用场景逐渐成熟，这一设计已经显得过时，不应再被视为良好的基础权益证明发行模型。在应用专用区块链的世界中，不可能存在一种放之四海而皆准的区块链，但 Cosmos SDK 仍然致力于提供一个良好的基础实现，并且这个实现应适用于 Cosmos Hub。 传统质押设计最重要的缺陷在于，它与链上交易、借贷、衍生品等协议的组合性较差，这些协议通常统称为 DeFi。传统质押实现会通过自适应提高无风险利率来抽走这些应用所需的流动性。本质上，它使 DeFi 与质押安全性在一定程度上彼此不兼容。 Osmosis 团队采用了 Superfluid 和 Interfluid 质押的思路，使参与 DeFi 应用的资产也能用于权益证明。这要求与一组被内置支持的 DeFi 应用进行紧密集成，因此并不适合 Cosmos SDK。 还需要注意的是，默认 IBC 实现中已经提供了 Interchain Accounts，可用于对委托进行再质押。因此，流动性质押事实上已经可行，而这些变更只是改善了流动性质押的用户体验。中心化交易所同样会对已质押资产进行再质押，这也给去中心化带来了挑战。本文 ADR 的立场是，采用协议内流动性质押是更优结果，并提供新的调节手段来激励质押权的去中心化。 这些对质押模块的变更已开发超过一年，并已获得大量计划构建质押用户体验的行业参与者采纳。Informal 团队内部的经济学分析也审查了这些变更的影响，而这项审查促成了豁免委托系统的开发。该系统通过一个可调参数来帮助治理调节委托代理问题的风险，这个参数称为豁免因子。决策
我们在 Cosmos SDK 中实现半同质化流动性质押系统以及豁免因子系统。尽管这些代币化份额被登记为同质化资产，但它们的可替代性极为有限，只能在代币化时所创建的特定委托记录之间互换。这些资产可用于 OTC 交易，但与 DeFi 的组合性有限。其主要预期用例是改善流动性质押提供方的用户体验。 引入一个新的治理参数，用于定义豁免代币化份额与已发行代币化份额之间的比率，称为豁免因子。更大的豁免因子意味着可用更少的豁免委托支持发行更多的代币化份额。如果治理层对流动性质押市场的演进情况感到满意，提高该值是合理的。 质押系统将移除最小自委托，预期由豁免委托系统取而代之。豁免委托系统允许多个账户以团队成员、合作伙伴等身份，在不混同资金的情况下证明其与验证者运营者之间的经济利益一致性。一旦治理层调整了豁免因子，在流动性质押被广泛采用后，验证者业务的增长很可能需要委托豁免机制。 当份额被代币化时，其底层份额会转移到一个模块账户中，奖励也会发送到该模块账户，并归属于对应的 TokenizedShareRecord。 不再提供覆盖 TokenizedShares 对应验证者投票的机制。MsgTokenizeShares
MsgTokenizeShares 消息用于将已委托代币创建为代币化份额。任何拥有正数委托金额的委托人都可以执行此消息；执行后，账户中的相应委托金额会消失，并获得份额代币。份额代币的面额由底层委托所属的验证者和记录 id 决定。
用户可以将其部分或全部委托进行代币化。
他们将收到面额为 cosmosvaloper1xxxx/5 的份额，其中 5 是该验证者运营者对应的记录 id。
如果账户是 VestingAccount，MsgTokenizeShares 将执行失败。用户需要先将已归属的代币转移到新账户，并经历解绑期。相比为追踪已归属代币而引入复杂的记账逻辑，我们认为这是一个可接受的权衡。
系统会检查该验证者当前未赎回的代币化份额总量，是否超过豁免委托总额乘以豁免因子。若代币化份额超过此上限，则执行失败。
MsgTokenizeSharesResponse 会返回生成的代币数量及其面额。
MsgRedeemTokensforShares
MsgRedeemTokensforShares 消息用于通过份额代币赎回委托。任何持有份额代币的用户都可以执行此消息。执行后，对应委托将出现在该用户名下。
MsgTransferTokenizeShareRecord
MsgTransferTokenizeShareRecord 消息用于转移由代币化委托金额所产生奖励的所有权。用户在将其委托代币化时会创建 tokenize share record，在全部份额代币被赎回后该记录会被删除。
该设计适用于那些不会赎回代币化份额，而可能希望持续保持份额处于代币化状态的流动性质押方案。
MsgExemptDelegation
MsgExemptDelegation 消息用于将一笔委托标记为某验证者的豁免委托。如果豁免因子大于 0，这将允许该验证者发行更多委托份额。
该设计使链能够强制要求参与流动性质押方案的验证者维持一定数量的自委托。
影响
向后兼容性
将豁免因子设为 0 时，该模块的行为与传统质押相同。唯一显著的变化是移除了最小自绑定要求；而在没有任何代币化份额时，也不存在激励去豁免委托的动机。正面影响
这种方式应能支持与流动性质押提供方的集成，并改善用户体验。它为基础质押模块在非指数型发行政策下实现安全性提供了一条路径。Changelog
- 2022-09-10: Initial Draft (@zmanian)
Status
ACCEPTEDAbstract
Add a semi-fungible liquid staking primitive to the default Cosmos SDK staking module. This upgrades proof of stake to enable safe designs with lower overall monetary issuance and integration with numerous liquid staking protocols like Stride, Persistence, Quicksilver, Lido etc.Context
The original release of the Cosmos Hub featured the implementation of a ground breaking proof of stake mechanism featuring delegation, slashing, in protocol reward distribution and adaptive issuance. This design was state of the art for 2016 and has been deployed without major changes by many L1 blockchains. As both Proof of Stake and blockchain use cases have matured, this design has aged poorly and should no longer be considered a good baseline Proof of Stake issuance. In the world of application specific blockchains, there cannot be a one size fits all blockchain but the Cosmos SDK does endeavour to provide a good baseline implementation and one that is suitable for the Cosmos Hub. The most important deficiency of the legacy staking design is that it composes poorly with on chain protocols for trading, lending, derivatives that are referred to collectively as DeFi. The legacy staking implementation starves these applications of liquidity by increasing the risk free rate adaptively. It basically makes DeFi and staking security somewhat incompatible. The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi appliactions can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK. It’s also important to note that Interchain Accounts are available in the default IBC implementation and can be used to rehypothecate delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. These changes to the staking module have been in development for more than a year and have seen substantial industry adoption who plan to build staking UX. The internal economics at Informal team has also done a review of the impacts of these changes and this review led to the development of the exempt delegation system. This system provides governance with a tuneable parameter for modulating the risks of principal agent problem called the exemption factor.Decision
We implement the semi-fungible liquid staking system and exemption factor system within the cosmos sdk. Though registered as fungible assets, these tokenized shares have extremely limited fungibility, only among the specific delegation record that was created when shares were tokenized. These assets can be used for OTC trades but composability with DeFi is limited. The primary expected use case is improving the user experience of liquid staking providers. A new governance parameter is introduced that defines the ratio of exempt to issued tokenized shares. This is called the exemption factor. A larger exemption factor allows more tokenized shares to be issued for a smaller amount of exempt delegations. If governance is comfortable with how the liquid staking market is evolving, it makes sense to increase this value. Min self delegation is removed from the staking system with the expectation that it will be replaced by the exempt delegations system. The exempt delegation system allows multiple accounts to demonstrate economic alignment with the validator operator as team members, partners etc. without co-mingling funds. Delegation exemption will likely be required to grow the validators’ business under widespread adoption of liquid staking once governance has adjusted the exemption factor. When shares are tokenized, the underlying shares are transferred to a module account and rewards go to the module account for the TokenizedShareRecord. There is no longer a mechanism to override the validators vote for TokenizedShares.MsgTokenizeShares
The MsgTokenizeShares message is used to create tokenize delegated tokens. This message can be executed by any delegator who has positive amount of delegation and after execution the specific amount of delegation disappear from the account and share tokens are provided. Share tokens are denominated in the validator and record id of the underlying delegation.
A user may tokenize some or all of their delegation.
They will receive shares with the denom of cosmosvaloper1xxxx/5 where 5 is the record id for the validator operator.
MsgTokenizeShares fails if the account is a VestingAccount. Users will have to move vested tokens to a new account and endure the unbonding period. We view this as an acceptable tradeoff vs. the complex book keeping required to track vested tokens.
The total amount of outstanding tokenized shares for the validator is checked against the sum of exempt delegations multiplied by the exemption factor. If the tokenized shares exceeds this limit, execution fails.
MsgTokenizeSharesResponse provides the number of tokens generated and their denom.