在过去的一个多月中，我们正在 UniSat 的若干产品内，特别是给开发者的 API 中，逐步实现对于 Alkanes 协议的支持。有趣的是，在充分的调研之后，我们发现实际的开发工作比我们预期的少，进展也比预期的稍快。我们会简单分析其原因，同时也会分享一些工作中的观察和发现。
回到若干周前，真正打动我们开展相关工作的是，Alkanes 在消化和吸收了 Runes 等协议的优点之后，所构造出的一个即时可用的合约执行环境。
具体地说，Alkanes 协议具有如下两个主要的优势：
对类似 Runes 的基于 UTXO 资产模型的继承和优化
Runes 已经向我们展示了这种模型的实用性和可靠性。我们惊讶地发现，Alkanes 通过创新性地融合 Runes 协议的方案，在合约的环境下建立起了新的优势。
由于资产的所有权与 UTXO 直接绑定，用户仅通过普通交易就可以发送资产，无需像 ERC20 这样的协议那样，每一笔转账都需要与合约交互。也就是说，作为最常见的操作，一笔典型的转账可以做到无智能合约调用（contract-Less asset transfer）。与非 UTXO 虚拟机（如 EVM) 相比，这极大地降低了性能开销，避免了大量的状态维护。使得虚拟机可以把有限的系统资源用在更高级的业务逻辑上。
同时，由于 Alkanes 完全兼容 Runes 的资产识别标准（如 OP_RETURN 编码格式），我们在实现钱包、浏览器等基础设施时，可以基本做到较低成本的代码复用，在实际工作中，这可以显著提高开发效率，降低开发者的迁移门槛。
已然可用的创新比特币智能合约开源框架
我们知道，在比特币生态中，有很多团队在进行智能合约相关的探索和开发，他们为自己的工作起了很多有趣的名字，如 BTCfi 等等。而 Alkanes 在有限的开发时间内，通过巧妙地利用 WebAssembly 的相对成熟的基础设施，在其他大部分团队还在做方向性的探讨和摸索时，已经在比特币主网上落地了一套相对可用的智能合约开源框架。不得不说，我们在研究时，对系统的完成度是比较吃惊的。
Alkanes 提供的智能合约方案，扩展了 BTC 生态的能力边界。其模块化架构允许开发者直接部署功能完备的合约（如 AMM、质押、时间锁等），无需为每类功能修改底层索引器或协议规则。作为索引器的常年维护者，我们很自然地对这样的方案感到亲切和方便。
小结
使用外部虚拟机而非比特币自身的脚本来扩展比特币的合约能力，这正在成为一个流行的做法。总的来说这种探索对于系统是有益的，特别是它在维护了比特币内核的简单，稳定和内聚力的同时，有效扩展了系统的能力边界，使得系统拥有更大的自由度（当然也带来了相应的复杂度）。进一步说，在小心地覆盖了 Runes 已有优势的基础上，通过正交地展示一个新的维度（WASM 合约能力），Alkanes 可以被认为是一个从功能角度试图挖掘更多潜力的进化版本。
说完了两个主要的优势，这里我们也简要分析一下其目前存在的不足和改良空间：
合约代码的安全性和健壮性带来的潜在风险
由于合约不是常见的 Solidity 开发环境，开发者会需要重新写出那些在 EVM 上已经成熟的合约代码，这对于大多数开发者来说构成了挑战。并且由于缺少足够的审计和合约代码验证平台，用户无法确认代币合约是否被恶意植入后门（如隐藏增发逻辑）。当前仅能依赖项目方主动提供源码，若合约未经验证即上线，存在资产被操控的高风险，这是需要开发者和用户注意的。
操作不当导致的资产烧毁风险
选择使用基于 UTXO 的资产模型，为用户的理解和管理带来一定的挑战，对于尚未准确识别该协议的钱包而言，这会带来烧毁的风险，Runes 的 UTXO 在没有携带 OP_RETURN 的交易下，会把资产转移到首个非 OP_RETURN 输出上，Alkanes 没有继承这个特性，所以烧毁风险更高，这也是需要开发者和用户注意的。
工程设计和实现的成熟度亟需提升
目前 Alkanes 处于早期，在工程上有大量亟需改善之处。以下我们在设计和实现各举一例，以引起协议维护者的注意，积极推动协议的改良和进化。
（设计问题一例）序号偏移可能引发全局错误识别的风险。协议依赖连续编号分配合约 ID，一旦某个序号因故障偏移（如索引运行版本或者运行环境等因素），后续所有资产转移指令将连锁失效。此设计缺陷可能临时性地导致后续所有资产暂时不可用，这要求各个索引方需要保持高度一致，对比 Runes 等协议（仅局部代币错误）存在系统性隐患。
（实现问题一例）目前 Alkanes 官方索引的单区块处理耗时根据 Alkanes 交易数量可能高达 1-2 分钟，且随交易量增加呈线性上升趋势。如果 OP_RETURN 的限制被解除，允许批量构造 OP_RETURN，可能会存在针对索引的 DDOS 攻击，若未来交易激增（如热门代币铸造），可能引发严重拥堵，难以支撑高频应用场景（如 DeFi 交易）。索引性能需要进一步持续而深入的优化，以应对未来潜在应用可能带来的挑战。
比特币区块链本身存在的固有限制
交易顺序依赖矿工打包。以太坊中，交易可以通过 nonce 来保证一定的先后顺序。但 BTC 上则退化为交易自身被打包的顺序，这导致了 Alkanes 协议下的合约交互的顺序完全无法保证。一个用户的两笔连续操作在区块打包前无法确定，在对顺序有较高要求的合约上，比较容易出现合约交互失败的情况。
OP_RETURN 数据段的容量限制。比特币当前 OP_RETURN 限制 80 字节，这对合约单次交互所能传递的数据有较大的限制，使得某些功能无法使用一般的方式实现。
再次小结
从积极面对和解决问题的角度出发，我们认为当前系统还存在大量可以改进的空间，为了系统的健康发展，还有很多工作需要被完成。我们的期望和建议是，应当有意识地控制系统的复杂度，保持克制，谨慎地增加系统的控制变量和抽象维度；不要贪图一时的方便，引入太多可能成为历史包袱的负担。
关于比特币的可编程性
在积极推动 Alkanes 发展的同时，我们不应忽视 BestInSlots 在 brc-20 上的可编程性探索。这是一条不寻常的道路，我们对于其进展保持密切的关注，并随时准备好为其提供支持。一个简单快速的比较是，应用了 EVM 和 Solidity 的 brc-20 programmable module 对区块链开发者更加友好，虚拟机行为更稳定可预测，但继承了更多的历史负担；而使用 WebAssembly 的 Alkanes 拥有的潜在优势是，（作为现代执行环境）有机会实现更高的性能，更有效的资源管理，同时新写出的脚本代码未经实战检验，也可能带来更多未知的风险。我们期待着随着各自系统的交付与完善，能够做出更深入的分析和总结。
关于比特币生态的发展
2023 年，不同协议关注的焦点还在各自的原始特性上。时间推移至 2025 年，低垂的果实已经摘完，新的维度的竞争才刚刚拉开序幕。UniSat 已经做好了热身，我们与相关的团队保持密切和深入的交流，并准备好随时积极地为开发者和用户提供来自一手的战地经验和工具支持。
与那个夏天不同的是，这一次主网的潜在拥堵发生时，有了健壮的 Fractal Bitcoin 网络，我们将不再像那时一样，面对拥堵目瞪口呆，束手无策。在不远的未来，也许会有一次实战机会，让我们得以检验哪些技术方案可以在真实的战场上存活下来，得以成为比特币的有效扩展系统。
同时，我们会逐步加大投入，对 Fractal Bitcoin 做进一步的升级和改造，以使得它对于现代的合约执行环境更加友好。我们期望 Fractal 在提供了一个能够更快速确认，区块容量更大的宽松环境的基础上，让更多不同类型的合约受到更少的约束，得到更多更充分的发挥的机会，从而帮助比特币生态更充分地绽放。
好听的故事打动人心，而能够深刻改变和成就系统的，是健壮的，可以运行，可以扩展的代码。