最近在 X 上的一场讨论引发了 Solana 开发者和 meme 代币爱好者的关注。一切始于 @cavemanloverboy 的一条帖子，他指出了一段让人困惑的关于 Solana 运行时常量管理的代码。

有问题的代码涉及跨程序调用（Cross-Program Invocation, CPI）成本，也就是在 Solana 区块链上一个程序调用另一个程序所需的计算开销。以下是引发讨论的代码片段：

如你所见，有一个默认成本，以及当特定功能（SIMD_0339）激活时的调整成本。@cavemanloverboy 认为这是不必要的折腾，这一点很容易理解——这种条件逻辑会让代码库变得凌乱。

这时 Trent.sol 出场了——Anza 的首席抱怨者（此前在 Solana Labs 负责 curmudgeon ops），他在转发该帖时给出了尖锐的建议：「如果常量存放在运行时拥有并由 feature gate 程序控制的账户里，我们就不需要这些愚蠢的代码了。我们也不用等到 epoch 边界去改变它们。」

我们来拆解一下。Solana 中的 feature gates（功能门控）是允许新功能在网络中逐步推出的机制。它们在 epoch 边界（大约两天的周期）被激活。Trent 的想法是将这些常量——比如调用成本——存储在运行时拥有的特殊账户里。由 feature gate 程序来管理这些账户，意味着不必在各处硬编码条件判断，就能更动态地进行变更。

对在 Solana 上创建和交易 meme 代币的人来说，这可能是个改变游戏规则的想法。meme 代币依赖速度和低成本，任何能减少更新等待时间或简化核心代码的改进，都可能带来更顺畅的交易和更快的创新。试想一下，部署一个新 meme 功能时不必等待下一个 epoch——这种敏捷性可以让 Solana 在快速变化的加密梗圈中保持领先。

该讨论串还有人戏谑地回复，问何时会出现一个“FeatGate111111111111111111111111111111111111”，调侃 Solana 的程序地址——系统程序的地址看起来经常像一长串 1。

如果你在 Solana 上构建项目或只是交易 meme 代币，留意这样的讨论很有必要。它们暗示了生态系统为了保持高效与对开发者友好而在不断演进。更多上下文请查看原始线程 这里。