Vitalik Buterin：以太坊是否应该封装更多功能？

关于协议极简主义的前期哲学

在当时被称为「以太坊 2.0」的前期历史中，人们强烈期望创立一个洁净，简略和漂亮的协议，该协议尽或许少地测验经过自身来构建，并将简直全部这类作业都留给用户。理想状况下，协议仅仅一个虚拟机，而验证一个区块仅仅一个虚拟机调用。

「状况转化函数」（处理区块的函数）将仅仅单个 VM 调用，全部其他逻辑将经过合约发生：一些体系级合约，但主要是由用户供给的合约。这个模型的一个十分好的功用是，即便是整个硬分叉也能够被描绘为关于区块处理器合约而言的单笔买卖，该买卖将经过链下或链上管理进行同意，然后以晋级的权限运转。

2015 年的这些评论特别适用于咱们考虑的两个范畴：账户笼统和扩容。在扩容的状况下，咱们的主意是测验创立一个最大程度的笼统办法的扩容，感觉就像上面图表的天然扩展。合约能够调用大多数以太坊节点未存储的数据，协议将检测到这一点，并经过某种十分通用的扩展核算功用来处理调用。从虚拟机的视点来看，该调用将进入某个独自的子体系，然后一段时刻后奇特地返回正确的答案。

咱们对这种思路进行了简短的探究，但很快就抛弃了，由于咱们太专注于验证任何类型的区块链扩容都是或许的。尽管咱们稍后会看到，数据可用性采样和 ZK-EVM 的结合意味着以太坊扩容的一个或许的未来实践上看起来十分挨近这个愿景！另一方面，关于帐户笼统，咱们从一开始就知道某种完成是或许的，因而研究当即开始测验使一些尽或许挨近「买卖仅仅一个调用」的纯粹起点的东西变为现实。

在处理买卖和从发送方地址宣布实践的底层 EVM 调用之间，会呈现许多的样板代码，之后还会呈现更多的样板代码。咱们如何将这些代码尽或许削减到挨近于零？

这儿的主要代码之一是 validate_transaction(state, tx)，它担任检查买卖的 nonce 和签名是否正确。从一开始，帐户笼统的实践方针就是答运用户用自己的验证逻辑替换根本的非增量验证和 ECDSA 验证，这样用户就能够更轻松地运用社交恢复和多签名钱包等功用。因而，找到一种办法将 apply_transaction 从头架构为一个简略的 EVM 调用，这不仅仅是一个「为了使代码洁净而使代码洁净」的使命；相反，它是关于将逻辑移动到用户的帐户代码中，为用户供给所需的灵活性。

可是，坚持让 apply_transaction 包括尽或许少的固定逻辑的做法终究带来了许多应战。咱们能够看下最早的帐户笼统提案之一 EIP-86 。

假如按原样包括 EIP-86 ，它将下降 EVM 的杂乱性，代价是许多添加以太坊仓库其他部分的杂乱性，需求在其他地方编写本质上完全相同的代码，除了引进全新的怪异类别之外，例如具有相同哈希值的同一买卖或许会在链中多次呈现，更不用说多重失效问题了。

账户笼统中的多重失效问题。在链上包括的一笔买卖或许会使内存池中的数千笔其他买卖无效，然后使内存池很简略被廉价地充斥。

从那时起，帐户笼统分阶段发展。EIP-86 后来变成了 EIP-208 ，终究呈现了实践可行的 EIP-2938 。

可是，EIP-2938 一点也不精约。其内容包括：

· 新的买卖类型

· 三个新买卖范围的大局变量

· 两个新的操作码，包括十分笨拙的 PAYgas 操作码，用于处理 gas 价格和 gas 限制检查，作为 EVM 履行断点，以及暂时存储 ETH 以一次性付出费用

· 一组杂乱的挖矿和转播策略，包括买卖验证阶段制止的操作码列表

为了在不涉及以太坊核心开发人员（专注于优化以太坊客户端和完成兼并）的状况下完成账户笼统，EIP-2938 终究被从头架构为完全是协议外的 ERC-4337 。

由于这是一个 ERC，它不需求硬分叉，而且在技能上存在于「以太坊协议之外」。所以……问题处理了吗？事实证明并非如此。ERC-4337 当时的中期路线图实践上涉及终究将 ERC-4337 的大部分转变为一系列协议功用，这是一个有用的辅导示例，能够了解为什么要考虑这条途径。

封装 ERC-4337 

有几个要害原因评论了终究将 ERC-4337 从头归入协议：

gas功率：在 EVM 内部进行的任何操作都会导致必定程度的虚拟机开销，包括在运用比如存储槽之类 gas 费贵重的功用时功率低下。现在，这些额外的低功率加起来至少要耗费 2 万 gas，乃至更多。将这些组件放入协议中是消除这些问题的最简略办法。

代码bug 危险：假如 ERC-4337 「进口点合约」有一个满意可怕的 bug，全部与 ERC-4337 兼容的钱包都或许看到他们全部的资金枯竭。用协议内功用取代合约会发生一种隐含的职责，即经过硬分叉修正代码过错，然后消除用户的资金枯竭危险。

支撑EVM 操作码，如 txt.origin。ERC-4337 自身使 txt.origin 返回将一组用户操作打包到买卖中的「绑缚器（bundler）」的地址。原生帐户笼统能够处理这个问题，办法是使 txt.origin 指向发送买卖的实践帐户，使其运作办法与 EOA 相同。

抗检查：提议者/构建者别离的应战之一是检查单笔买卖变得更简略。在以太坊协议能够辨认单笔买卖的国际中，包括列表能够极大地缓解这个问题，该列表答应提议者指定在简直全部状况下有必要包括在接下来两个插槽中的买卖列表。可是协议外的 ERC-4337 将「用户操作」封装在单笔买卖中，使得用户操作对以太坊协议不透明；因而，以太坊协议供给的包括列表将无法对 ERC-4337 用户操作供给检查阻力。封装 ERC-4337 ，并运用户操作成为一种「恰当的」买卖类型，将处理这个问题。

值得一提的是，在现在的办法下，ERC-4337 比「根本」以太坊买卖要贵得多：买卖本钱为 21, 000 gas，而 ERC-4337 的本钱约为 42, 000 gas。

理论上，应该有或许对 EVM gas 本钱体系进行调整，直到协议内本钱和协议外拜访存储的本钱相匹配；当其他类型的存储编辑操作更廉价时，搬运 ETH 没有理由需求花费 9000 gas。事实上，与即将到来的 Verkle 树转化相关的两个 EIP 实践上企图做到这一点。可是，即便咱们这样做了，有一个清楚明了的原因能够解释为什么不管 EVM 变得多么高效，封装的协议功用都将不可防止地比 EVM 代码廉价得多：封装代码不需求为预加载付出 gas。

功用齐全的 ERC-4337 钱包很大，编译并放到链上的这个完成占用了约 12, 800 字节。当然，你能够一次部署这段代码，并运用 DELEGATECALL 来答应每个独自的钱包调用它，可是依然需求在运用它的每个区块中拜访该代码。在 Verkle 树 gas 本钱 EIP 下， 12, 800 字节将组成 413 个 chunk，拜访这些 chunk 将需求付出 2 倍的 witness branch_cost（总共 3, 800 gas）和 413 倍的 witness chunk_cost（总共 82, 600 gas）。这乃至还没有开始提到 ERC-4337 进口点自身，在 0.6.0 版别中，链上有 23, 689 字节（依据 Verkle 树 EIP 规则，约有 158, 700 个 gas 要加载）。

这就导致了一个问题：实践拜访这些代码的 gas 本钱有必要以某种办法在买卖中分摊。ERC-4337 运用的当时办法不是很好：bundle 中的第一笔买卖耗费了一次性存储/代码读取本钱，使其比其他买卖贵重得多。协议内封装将答应这些公一起享库成为协议的一部分，全部人都能够免费拜访。

咱们能从这个比如中学到什么，什么时候更普遍地进行封装？

在这个比如中，咱们看到了在协议中封装账户笼统方面的一些不同的根本原理。

当固定本钱较高时，「将杂乱性推向边际」的依据商场的办法最简略失败。事实上，长时刻的账户笼统路线图看起来每个区块都有许多固定的本钱。244, 100 gas 用于加载标准化钱包代码是一回事；可是聚合或许会为 ZK-SNARK 验证添加数十万的 gas，以及证明验证的链上本钱。没有一种办法能够在不引进许多商场低功率的状况下向用户收取这些本钱，而将其中一些功用转化为全部人都能够免费拜访的协议功用则能够很好地处理这个问题。

社区范围内对代码bug 的呼应。假如一些代码片段被全部用户或十分广泛的用户运用，那么区块链社区承当硬分叉的职责来修正呈现的任何过错一般更有意义。ERC-4337 引进了许多的大局同享代码，从长远来看，经过硬分叉修正代码中的过错无疑比导致用户丢失许多 ETH 更合理。

有时，能够经过直接运用协议的功用来完成其更强办法。这儿的要害比如是协议内的抗检查功用，如包括列表：协议内的包括列表能够比协议外的办法更好地保证检查阻力，为了运用户级操作真正受益于协议内的包括列表，单个用户级操作需求对协议「易读」。另一个不为人知的比如是， 2017 年年代的以太坊权益证明设计对权益密钥进行了账户笼统，这被抛弃了并转而支撑封装 BLS，由于 BLS 支撑一种「聚合」机制，有必要在协议和网络层面完成，这能够使处理许多签名的功率更高。

但重要的是要记住，与现状相比，即便是封装协议内账户笼统，依然是一种巨大的「去封装化」。现在，尖端以太坊买卖只能从外部具有的账户（EOA）发起，这些账户运用单个 secp 256 k 1 椭圆曲线签名进行验证。帐户笼统消除了这一点，并将验证条件留给用户自行定义。因而，在这个关于账户笼统的故事中，咱们也看到了对立封装的最大理由：灵活地满意不同用户的需求。

让咱们经过检查最近被考虑封装的其他几个特征示例来进一步充实这个故事。咱们将特别重视：ZK-EVM，提议者-构建者别离，私有内存池，流动性质押和新的预编译。

封装 ZK-EVM

让咱们把注意力搬运到以太坊协议的另一个潜在封装方针：ZK-EVM。现在，咱们有许多的 ZK-rollup，它们都有必要编写适当相似的代码来验证 ZK-SNARK 中相似以太坊区块的履行。有一个适当多样化的独立完成生态体系：PSE ZK-EVM、 Kakarot 、 Polygon ZK-EVM、 Linea 、Zeth 等等。

EVM ZK-rollup 范畴最近的一个争议与如何处理 ZK 代码中或许呈现的 bug 有关。现在，全部这些正在运转的体系都有某种办法的「安全理事会」机制，能够在呈现 bug 的状况下操控证明体系。上一年，我企图创立一个标准化的框架，以鼓舞项目清晰他们对证明体系的信赖程度，以及对安全理事会的信赖程度，并跟着时刻的推移，逐渐削减对该安排的权利。

从中期来看，rollup 或许依赖于多个证明体系，而安全理事会只要在两个不同的证明体系发生分歧的极点状况下才有权利。

可是，有一种感觉是，其中一些作业感觉是多余的。咱们现已有了以太坊根底层，它有一个 EVM，咱们现已有了一个处理完成中 bug 的作业机制：假如有 bug，客户端将进行更新来修正，然后链持续运作。从有 bug 的客户端视点来看，似乎现已终究承认的区块将不再承认，但至少咱们不会看到用户丢失资金。相同，假如 rollup 仅仅想坚持与 EVM 等同的效果，那么它们需求施行自己的管理来不断更改其内部 ZK-EVM 规则以匹配对以太坊根底层的晋级，这感觉是过错的，由于终究它们是在以太坊根底层自身之上构建的，它知道何时晋级以及依据什么新规则。

由于这些 L2 ZK-EVM 根本上运用与以太坊完全相同的 EVM，咱们能否以某种办法将「验证 EVM 在 ZK 中的履行」归入协议功用，并经过运用以太坊的社会共识来处理异常状况，如 bug 和晋级，就像咱们现已为根底层 EVM 履行自身所做的那样？

这是一个重要而赋有应战性的话题。

关于原生 ZK-EVM 中数据可用性的一个或许的争辩主题是有状况性（statefulness）。假如 ZK-EVM 不需求携带「见证（witness）」数据，它们的数据功率就会高得多。也就是说，假如某个特定的数据现已在之前的某个区块中被读取或写入，咱们能够简略地假定证明者能够拜访它，而且不必再次使它可用。这不仅仅是不从头加载存储和代码；事实证明，假如一个 rollup 正确地紧缩了数据，那么与无状况紧缩相比，有状况紧缩最多能够节省 3 倍的数据。

这意味着关于 ZK-EVM 预编译，咱们有两个选项：

1. 预编译要求全部数据在同一区块中可用。这意味着 prover 能够是无状况的，但也意味着运用这种预编译的 ZK-rollup 比运用自定义代码的 rollup 要贵重得多。

2. 预编译答应pointer 指向从前履行运用或生成的数据。这使得 ZK-rollup 挨近最优，但它更杂乱，并引进了一种有必要由 prover 存储的新状况。

咱们能从中学到什么？以某种办法将 ZK-EVM 验证封装有一个很好的理由：rollup 现已在构建自己的自定义版别，而且以太坊乐意将其多个完成和链下社会共识的权重置于 L1 上履行 EVM，这感觉是过错的，可是做完全相同作业的 L2 有必要完成涉及安全理事会的杂乱小东西。但另一方面，细节中有一个大问题：有不同版别的 ZK-EVM，它们的本钱和收益不同。有状况和无状况的区分仅仅触及了表面；测验支撑「近 EVM（almost-EVM）」，这些定制代码现已被其他体系证明，这或许会暴露出更大的设计空间。因而，封装 ZK-EVM 既带来了期望，也带来了应战。

封装提议者与构建者别离（ePBS）

MEV 的鼓起使区块出产成为一种大规模经济活动，杂乱的参与者能够出产出比默许算法发生更多收入的区块，而默许算法仅仅观察买卖的内存池并包括它们。到现在为止，以太坊社区企图经过运用 MEV- Boost  等协议外的提议者-构建者别离（proposer-builder separation）方案来处理这个问题，该方案答应常规验证者（「提议者」）将区块构建外包给专门的参与者（「构建者」）。

可是，MEV-Boost 在一个新的参与者类别中进行了信赖假定，称为中继（relay）。在曩昔的两年里，有许多人提议创立「封装 PBS」。这样做的好处是什么？在这种状况下，答案十分简略：经过直接运用协议功用构建的 PBS 比不运用它们构建的 PBS 更强大（在具有更弱的信赖假定的意义上）。这与封装协议内价格预言机的状况相似——尽管在这种状况下，也存在强烈的对立定见。

封装私有内存池

当用户发送买卖时，该买卖当即公开并对全部人可见，乃至在它被包括在链上之前。这使得许多运用程序的用户简略遭到经济进犯，例如抢先买卖。

最近，有许多项目专门致力于创立「私有内存池」（或「加密内存池」），它将用户的买卖加密，直到它们被不可逆转地被接遭到一个区块中。

可是，问题是，这样的方案需求一种特别的加密：为了防止用户涌入体系并率先进行解密，加密有必要在买卖确实被不可逆转地被承受后自动解密。

为了完成这种办法的加密，有各种不同权衡的技能。Jon Charbonneau 曾做过很好的描绘：

对中心化运营商进行加密，例如  Flashbots Protect。

时刻锁加密，该加密办法经过必定的次序核算过程后，任何人都能够解密，而且不能并行化；

阈值加密，信赖一个诚实的多数委员会来解密数据。详细建议请参见关闭信标链概念。

可信硬件，如 SGX。

不幸的是，每一种加密办法都有不同的弱点。虽然关于每个处理方案，都有一部分用户乐意信赖它，但没有一个处理方案的信赖程度足以让它实践上被 Layer 1 承受。因而，至少在延迟加密得到完善或其他一些技能突破之前，在 Layer 1 封装反提早买卖功用似乎是一个困难的命题，即便它是一个满意有价值的功用，许多运用程序处理方案现已呈现。

封装流动性质押

以太坊 DeFi 用户的一个一起需求是能够同时运用他们的 ETH 进行质押和作为其他运用程序中的抵押品。另一个常见的需求仅仅是为了便利：用户期望能够在没有运转节点并坚持其一直在线的杂乱性的状况下进行质押（并保护线上质押密钥）。

到现在为止，满意这两种需求的最简略质押「接口」仅仅一种 ERC 20 代币：将你的 ETH 转化为「质押 ETH」，持有它，然后再转化回来。事实上， Lido  和  Rocket   Pool  等流动性质押供给商现已开始这样做了。可是，流动性质押有一些天然的中心化机制在起效果：人们天然会进入最大版别的质押 ETH，由于它是最了解和最具流动性的。

每个版别的质押 ETH 都需求有一些机制来确定谁能够成为底层节点运营商。它不能是无限制的，由于这样进犯者就会加入并运用用户的资金扩展进犯。现在，排名前两位的是 Lido 和  Rocket Pool ，前者具有 DAO 白名单节点运营商，后者答应任何人在存入 8 枚 ETH 的状况下运转一个节点。这两种办法有不同的危险：Rocket Pool 办法答应进犯者对网络进行 51% 的进犯，并迫运用户付出大部分本钱；至于 DAO 办法，假如某质押代币占主导地位，就会导致一个单一的、或许遭到进犯的管理小东西操控全部以太坊验证者的很大一部分。值得肯定的是，像 Lido 这样的协议现已施行了防范措施，但一层防护或许还不行。

在短期内，一种挑选是鼓舞生态体系参与者运用多样化的流动性质押供给商，以削减一家独大带来体系性危险的或许性。可是，从长时刻来看，这是一种不稳定的平衡，过度依赖道德压力来处理问题是危险的。一个天然的问题呈现了：在协议中封装某种功用以使流动性质押不那么中心化是否有意义？

这儿的要害问题是：什么样的协议内功用？简略地创立一个协议内可代替的「质押 ETH」代币存在一个问题，即它要么有必要有一个封装以太坊范围内管理来挑选谁来运转节点，要么是开放的，但这会把它变成进犯者的东西。

一个风趣的主意是 Dankrad Feist 关于流动性质押最大化的文章。首先，咱们咬紧牙关，假如以太坊遭到 51% 进犯，或许只要 5% 的进犯 ETH 被罚没。这是一个合理的权衡；现在有超过 2600 万枚 ETH 被质押，其中三分之一（约 800 万枚 ETH）的进犯本钱是过度的，特别是考虑到有多少种「模型外」进犯能够以更低的本钱完成。事实上，相似的权衡现已在「超级委员会」关于施行 single-slot finality 的提案中进行了讨论。

假如咱们承受只要 5% 的进犯 ETH 被罚没，那么超过 90% 的质押 ETH 将不会遭到罚没的影响，因而它们能够作为协议内可代替流动性质押代币，然后被其他运用程序运用。

这条途径很风趣。但它依然留下了一个问题：详细封装什么？Rocket Pool 的运作办法与此十分相似：每个节点运营商供给一些资金，流动性质押者供给其他的资金。咱们能够简略地调整一些常量，将最大罚没赏罚限制为 2 枚 ETH，Rocket Pool 现有的 rETH 将变得无危险。

经过简略的协议调整，咱们还能够做其他聪明的工作。例如，假定咱们想要一个体系，有两种「层」的质押：节点运营商（高抵押品要求）和储户（没有最低抵押品要求，能够随时加入和脱离），但咱们依然期望经过赋予一个随机抽样的储户委员会权利来防止节点运营商的中心化，比如建议有必要包括的买卖列表（出于抗检查的原因），在不活动泄漏期间操控分叉挑选，或许需求在区块上签名。这能够经过一种根本上脱离协议的办法来完成，办法是调整协议，要求每个验证器供给（i）一个常规的质押密钥，以及（ii）一个 ETH 地址，该地址能够在每个槽间被调用以输出二级质押密钥。该协议将赋予这两项密钥权利，但在每个槽中挑选第二个密钥的机制能够留给质押池协议。直接封装一些功用或许依然更好，但值得注意的是，这种「包括一些东西，把其他东西留给用户」的设计空间是存在的。

封装更多预编译

预编译（或「预编译合约」）是完成杂乱加密操作的以太坊合约，其逻辑在客户端代码中原生完成，而不是 EVM 智能合约代码。预编码是以太坊开发之初采用的一种折衷方案：由于虚拟机的开销关于某些十分杂乱和高度专业化的代码来说太大了，咱们能够在本地代码中完成一些对重要运用程序有价值的要害操作，以使其更快。现在，这根本上包括一些特定的散列函数和椭圆曲线运算。

现在有人在推进为 secp 256 r 1 添加预编译，这是一种与用于根本以太坊账户的 secp 256 k 1 略有不同的椭圆曲线，由于它得到了可信硬件模块的杰出支撑，因而广泛运用它能够提高钱包安全性。近年来，社区还推进为 BLS-12-377、BW 6-761、广义配对和其他功用添加预编译。

对这些要求更多预编译文件的反驳是，之前添加的许多预编译（例如 RIPEMD 和 BLAKE）终究的运用量远低于预期，咱们应该从中吸取教训。与其为特定操作添加更多的预编译，咱们也许应该专注于一种更温和的办法，该办法依据 EVM- MAX  和休眠但一直可恢复的 SIMD 提案等思维，这将使 EVM 完成能够以更低的本钱履行广泛的代码类。也许即便是现有的很少运用的预编译也能够被删除，并用相同函数的 EVM 代码完成（不可防止地功率较低）代替。也就是说，依然有或许存在特定的加密操作，这些操作的价值足以加快，因而将它们作为预编译添加是有意义的。

咱们从这全部中学到了什么？

尽或许少封装的愿望是能够理解的，也是好的；它源自  Unix  哲学传统，即创立极简的软件，能够很简略地适运用户的不同需求，防止软件胀大的咒骂。可是，区块链不是个人核算操作体系，而是社会体系。这意味着在协议中封装某些功用是有意义的。

在许多状况下，这些其他的比如与咱们在帐户笼统中看到的相似。但咱们也学到了一些新的教训：

封装功用能够帮助防止仓库中其他区域的中心化危险：

一般，坚持根本协议的最小化和简略性会将杂乱性推到一些协议之外的生态体系。从 Unix 哲学的视点来看，这很好。可是，有时存在协议外生态体系将中心化的危险，一般（但不仅仅是）由于高固定本钱。封装有时能够削减事实上的中心化。

封装太多内容，或许会过度扩展协议的信赖和管理负担：

这是前一篇关于「不要让以太坊共识过载」文章的主题：假如封装一个特定的功用削弱了信赖模型，并使以太坊作为一个全体变得更加「片面」，这就削弱了以太坊的可信中立性。在这些状况下，最好将特定功用作为以太坊之上的机制，而不是企图将其引进以太坊自身。在这儿，加密内存池是最好的比如，它或许有点难以封装，至少在延迟加密技能改善之前是这样。

封装太多内容或许会使协议过于杂乱：

协议杂乱性是一种体系性危险，在协议中添加太多功用会添加这种危险。预编译就是最好的比如。

长时刻来看，封装功用或许会适得其反，由于用户的需求是不可预测的：

一个许多人以为很重要而且会被许多用户运用的功用，很或许在实践中并没有被常常运用。

此外，流动性质押、ZK-EVM 和预编译案例显示了一条中间道路的或许性：最小可行封装（minimal viable enshrinement）。协议不需求封装整个功用，而能够包括处理要害应战的特定部分，使该功用易于完成，而不会过于偏执或过于狭窄。这样的比如包括：

与其封装一个完好的流动性质押体系，不如改变质押赏罚规则，让去信赖流动性质押更可行；

与其封装更多的预编译器，不如封装 EVM-MAX 和/或 SIMD，以使更广泛的操作类别更简略有效地完成；

能够简略地封装 EVM 验证，而不是封装 rollup 的整个概念。

咱们能够将前面的图表扩展如下：

有时候，去封装一些东西是有意义的，去除很少运用的预编译就是一个比如。帐户笼统作为一个全体，正如前面提到的，也是一种重要的去封装办法。假如咱们想支撑现有用户的向后兼容性，那么该机制实践上或许与去封装预编译的机制惊人地相似：其中一个提案是 EIP-5003，它将答应 EOA 将其帐户转化为具有相同（或更好）功用的合约。

哪些功用应该被引进协议，哪些功用应该留给生态体系的其他层，这是一个杂乱的权衡。跟着咱们对用户需求的理解以及可用主意和技能套件的不断改善，这种权衡有望跟着时刻的推移而持续改善。

此时快讯

【Stride暂时搁置将STRD转换为ATOM的计划】金色财经报道，Cosmos的流动质押区块链Stride将暂停将其原生代币STRD转换为Cosmos Hub的ATOM代币的计划，这一决定是在伊斯坦布尔Cosmoverse宣布最初想法后经过一周公开讨论后做出的。团队称：“经过一周的公开讨论，Cosmos Hub+Stride 社区已暂停 STRD/ATOM 转换，可以认为它被搁置了，但并没有完全放弃”。