12 月 2 日，Runes 中文社区邀请到 Omnity Network 的创始人 Louis Liu 以及 bitcoin 生态的资深 Builder，围绕 Omnity 即将推出的全新的 Bitcoin 可编程性扩展执行层协议 Runes Exchange Environment（REE），展开了一场围绕 BTCFi 构建技术相关的硬核讨论：💡REE 协议可以将 Bitcoin 交易延迟的速度提升 100 倍。💡REE 可以避免 MEV：采用 SIGHASH_ALL 签名。💡RichSwap 已经承诺将协议收入捐赠给符文 HOPE•YOU•GET•RICH🌟嘉宾 Tim 老师 ，Founder @Shell Finance，刚刚发布了迄今为止首个在 Bitcoin 一层主网构建并且成功上线的超额抵押稳定币协议。https://x.com/RunesCC/status/1864322604510896503🌟嘉宾 Kay 哥，Founder @GeoMarks ，打造了 Bitcoin 链上成就凭证体系，应该说是第一个在拓展和放大 Bitcoin 链上数据价值的项目。最近启动了 Runes 符文勋章的铸造：https://x.com/RunesCC/status/1864911422427402303
以下为完整的 AMA 内容，Enjoy～
主持人 Jasmine：我们知道 Omnity 之前在做 Omnity Hub 跨链协议，为什么会启动 REE 这样的 Bitcoin 可编程性扩展协议的构建？Louis：Omnity 团队一直致力于比特币 DeFi 的基础设施建设。我们早在去年就关注到了比特币生态中的 Ordinals inscriptions 和 BRC20 标准的出现以及当时即将发布的符文，这些发展促使我们在今年年初全面进入比特币生态。在分析比特币生态的发展时，我们认为在基础设施层面，最大的障碍是无信任跨链。因为 Layer2 已经有很多了，同时还有很多 DeFi 非常成熟的公链，如果能有一种快速、安全、便捷的方法将比特币资产转过去，他们都可以为 BTC 资产提供非常好的 DeFi 服务。
Omnity Hub 是一个全链上的跨链架构，是完全基于智能合约实现的跨链协议，不依赖任何链下进程或中心化组件。
Omnity Hub 目前支持比特币生态中最主流的三类可互换资产：BTC、符文 Runes 和铭文 Brc20。支持十几条 EVM 兼容链，还有 Solana、Osmosis 还有 ICP（Omnity Hub 协议本身运行在 ICP 上）。预计在本月，还将增加对 Sui 和 Ton 的支持。目前协议进展顺利，得到了多个合作伙伴和社区的信任，跨链 TVL 已经将近 400 万美元。
https://omnity.network/hub
在 Omnity Hub 的发展过程中，我们发现 BTC Layer 2 确实能够解决比特币在性能和可编程性上的不足。
然而问题在于：跨链这件事本身的体验，仍然较差。
因为比特币的速度很慢，采用 POW 机制，交易确认需要等待多次确认，保守一点是 6 个区块，激进一点是 4 个区块，才能确认一笔跨链交易。也就是说，从比特币链跨链到其他链，通常需要等候大约 1 小时才能完成交易确认。
与此同时，跨链桥曾经产生过很多安全问题，导致不少用户比较惧怕使用跨链桥。
这让我们思考，是否应该在比特币一层上直接实现 DeFi ？
虽然比特币的交易费用较高且确认时间较慢，但也并不是任何时候 blockspace 都很满，而且现在比特币上面的交易大部分是 Runes 符文相关的铸造和转账，真正的 DeFi 交易相对较少。
如果能够突破比特币一层上的可编程性限制，或许能够促进比特币资产的大规模增长。
当比特币 DeFi 交易量和资产量达到一定程度时，才有可能溢出到二层，BTC Layer2 的优势才有可能发挥出来。现在的问题是：比特币一层就没有水（缺乏足够的流动性），导致二层更加干涸（发展受限）。
因此，我们在学习同行的经验的基础上，也做了一些创新，推出了 REE 协议。并且在 11 月底发布了👉《REE 的白皮书》
Omnity 预计在明年第一季度推出 REE 协议平台，以及第一款基于 REE 的 DeFi 协议，是我们开发的符文 AMM DEX，作为 REE 协议的示范应用，帮助开发者理解 REE 的技术架构。
主持人 Jasmine：REE 相较于其他 Bitcoin 一层可编程扩展协议，有哪些技术优势呢？Louis：比特币一层的可编程性方案并不并多，REE 白皮书中列出了四个技术路线：我的个人看法是，不要对 Op_cat 重启抱有过于乐观的期望。BCH 和 BSV 在几年之前就启用了以 OP_CAT 为代表的一批操作符。以 BCH 为例，在 百亿美元市值的生态系统全力推动之下，结果也并不理想。其实在比特币主网上，单纯启用 OP_CAT 堆可编程性的编辑的增加效果是非常有限，很难在一层实现复杂的 DeFi 应用。举个简单的例子，如果你想进行乘法计算，但没有乘法操作符，只能靠 Op_cat 绕来绕去，所以还是不要期望太高。目前有一些项目在使用它，但就像上次 Liquidium 创 所说，DLC 的技术的潜力已经被挖掘殆尽，他们也在寻求更好、更强的技术方案。3、「索引器扩展 /Indexer Extension」，最近密集地出现了一批比特币执行层的可编程性拓展方案，大部分是基于索引器扩展构建的。4、REE 采用的是技术路线又有所不同，我们在白皮书里给这个方案起了个名字叫 DMC，就是 Decentralized Multisig Coordination，去中心化多签协调。那「DMC/ 去中心化多签协调」和「Indexer Extension/ 索引器扩展」相比，在 bitcoin 主网可编程性拓展上的区别和最终效果上又是如何呢？ 我们可以沿着大家相对熟悉的「Indexer Extension/ 索引器扩展」 这条技术路线来进行推演。 大家知道比特币的第二层是由 Ordinals 和 inscriptions 技术启动的，包括 BRC20，都是可以在比特币链上存储数据，并通过 Indexer 解析：这些数据可以表示资产所有权的生成和转移。 所以要拓展可编程性的时候，最直接的想法就是往 Indexer 上放一个执行环境，在执行环境里运行程序就可以实现可编程性。 但是，Indexer 和 Meta Protocol 是深度绑定的，比如 BRC20、符文（Runes）和铭文（Inscription）都是元协议。要提供可编程性，通常需要定义一个全新的 Meta Protocol ，以及 Meta Protocol 怎么去触发执行环境里的程序，而且输出也能回到 Meta Protocol 的规则上，最后启动这个新索引器（Indexer），并号召大家将程序部署到你的索引器上来运行。 这样的方案，执行环境和资产标准之间是深度耦合的，最终只能产生一个封闭的系统。我不能断言这种方式是否可行，但我认为不太符合规律。💡我们需要的是一个开放的系统，大家可以专注于各自领域，一起协作来推动 BTCFi 的发展。我认为执行环境应该与现有通用的资产标准兼容：因为大家已经接受了 Ordinals、BRC20 和 Runes 等标准，尤其是 Runes，它是基于 UTXO 的，可以很好地和 Bitcoin 执行环境配合起来。所以，要评判 Bitcoin 可编程性拓展协议的一个标准是：支持已经得到广泛共识的资产协议，而不是再创造一套全新的资产协调。那「Indexer Extension/ 索引器扩展」的技术方案，该如何支持现有资产协议呢？比如如何支持符文呢？▣ 就是在 Runestone 里定义一些新的标签，但这不算是好的实践，因为符文的文档规范里明确指出：标签都是为协议预留的，共计 128 种标签。 你用就意味着 Casey 不能用，或者说 Casey 用了，就会覆盖掉你使用的标签定义。这不仅是对符文协议的设计者不礼貌，而且将会和原有 Runes 协议形成竞争，如果发展起来甚至可以说是对符文协议的一种劫持。▣ 而且 OP_RETURN 容量总共就 80 个字节，符文已经占了很多，剩余也就十几个或二十几个字节，「扩展符文标准」这种方式能带来的可编程性拓展非常受限。如果扩展 Runes 协议标签，只靠 Indexer 来支持，那么假设 indexer 索引到了符文交易， indexer 上的程序该如何介入这笔交易呢？这里要解决三大问题：因为比特币的基本逻辑是，花费 UTXO 来生成新的 Output，而这些新的 Output 的解锁条件通常是某个 Key 的签名。其实这种通过程序持有 Key 并参与 Bitcoin 交易的方式，实际上已经非常常见。所有 DEX、所有的 CEX、所有的中心化的比特币服务都是程序拥有 KEY：用户把资产转给程序，程序按照规则交易，再最后提币的时候程序再把资产转给你，但这些方式都是中心化的。2、能否让去中心化的程序拥有 Key，并且能在比特币网络上进行操作呢？那去中心化的程序一定是在比特币之外的另外一条区块链上，而且要有 MPC/ 多方安全计算 和 TSS/ 门限签名的一条链。这样的链上的智能合约可以控制 Key 来持有比特币资产。资产就可以发给智能合约，其他用户可以和智能合约进行交易。本质上，就是 Indexer 要变成一条链，在把程序变成智能合约，智能合约持有 Key，进而实现对资产的控制。3、Indexer 处理交易时会受到比特币网络的延迟影响。比特币交易需要进入区块链后才能被索引，整个过程会很慢，比如你发一笔交易要等 10 分钟进块，然后再等 10 分钟，才能收到 Indexer 发回来的交易，一来一回就是 20 分钟。这个用户体验是不可接受的。解决办法就是：逆转比特币链与 indexer/ 执行层之间的关系。 在现有模型中，交易是先提交给比特币区块链，再经过执行层处理，结果再返回区块链进行结算。这样会导致两次交易处理，特别慢而且还是双倍的成本。 逆转关系后：就是先将请求发给执行层 /indexer/ 智能合约，执行完成后再将结果提交到比特币区块链进行结算。💡这样就可以大幅降低延迟，Latency 可以缩短 100 倍。因为你发了这个请求给执行层，执行完成后，它可以根据下一个状态马上接受你的或者其他用户的下一个请求，最后交易进块的时候，虽然比特币还是 10 分钟一个块，但是这一串执行层交易可以一起进块。 对比之下，执行层的延迟 /latency 就是几秒钟，而比特币一次交易需要 10 分钟，采用先提交给执行层计算，就可以把交易速度提高 100 倍。所以「索引器扩展 /Indexer Extension」是一个外推法方案，想要做好 DeFi，就需要做到刚才说的三个关键的升级：▣ 让 Indexer 上的程序可以控制 Key，控制资产。▣ 把 Indexer 变成一条链，或者链上的智能合约，实现去中心化。▣ 逆转现有模型交互顺序：先将请求发送给 Indexer 执行层，再将结果提交到 BTC 去看了上进行结算如果这三个升级实现后，其实「索引器扩展 /Indexer Extension」就变成了 Arch 和 REE 协议采用的 DMC 去中心化多签协调方案：▣ Arch Network 是自己创建一条新链，运行 SVM（Solana 虚拟机），上面有智能合约。用户签署 PSBT，将交易发送到智能合约，智能合约再签署 PSBT，最终得到完全签名的交易，并广播到比特币网络，同样不等交易进块，就可以执行下一笔交易。▣ REE 是用 ICP 这条已经存在的链，REE 的智能合约运行在 ICP 上，完成 DMC 去中心化多签协调。最后，我们再明确一下什么是「DMC/ 去中心化多签协调」：💡多签是比特币原生概念，意味着多个用户（例如张三、李四、王五）可以各自签署输入构成一笔交易，并广播到比特币网络。一个用户和多个协议（协议 A、协议 B、协议 C）也可以共同签署并广播到比特币网络。REE 方案将协议和智能合约之间的多签过程转到区块链上，实现了去中心化，所以叫去中心化的多方协调。 我认为，DMC 是在比特币一层实现完全可编程的最佳技术路线。主持人 Jasmine：Tim 老师，Shell Finance 协议应该就是使用 DLC 实现的 Bitcoin 超额抵押稳定币协议，不知道有没有什么想要交流的？Tim：对，事实上 DLC 目前也并非图灵完备，它只能支持有限的合约能力 之所以选择使用 DLC，是因为它能在这种有限的功能范围内，满足我们特定业务的需求。其他的方案，正如 Louis 所说，都有各自的局限性，且有些方案还不够成熟。未来 Shell Finance 探索 V2 方案，我们的选择有两条路：第一条是向上走，如果明年 OP_CAT 能在主网成功通过，我们将全面采用 OP_CAT，使用 Script 脚本语言进行重构，让所有计算和验证过程都在比特币的底层和 UTXO 模型上进行，从而提供更高的可扩展性。如果 OP_CAT 无法通过，我们可能会选择 Louis 提出的这条 DMC 技术路线。💡对于 Arch 和 REE 的差异，在我看来核心在于谁的共识更强：▣ ICP 毕竟是市值排名前 30 的一条链，并且已经经过了完整的运行周期，没有发生什么故障。▣ 而 Arch 主网还未上线，有没有可能出现双花？回滚？都是未知的。ICP 虽然在 DeFi Summer 上一轮周期里没有什么重大的发展和突破，但 ICP 很早就预见到 Bitcoin 生态的生命力，所以花了很大的成本去完全兼容 Bitcoin 客户端，这让 ICP 很有机会在这一轮周期与 Biticoin 或者 BTCFi 形成共振。Kay 哥：在做 AMM Swap 的时候，最麻烦的问题之一是部分成交：PSBT 会限制交易的拆分与部分支付的灵活性。我看到 REE 引入了 Exchange- Pool 模型，这个架构是如何处理 PSBT 去实现部分成交的交易需求呢？Louis：首先，REE 的 Exchange 就是是指 ICP 上的智能合约，ICP 的智能合约可以控制 0 到多个 Key，这些 Key 是来自 ICP 的 Chain Key 子网。▣ Chain Key 子网执行 MPC/ 多方安全计算 和 TSS/ 门限签名 ，也就是它有一个根分片私钥。▣ ICP 上的所有的智能合约都自己的 ID，都可以去 Chain Key 子网用根私钥导出自己的 Key。▣ 有了 Key 就可以得到对应的比特币地址，所以智能合约就有比特币地址。而且 ICP 智能合约可以通过 Chain Key 子网对任意数据进行签名，包括比特币交易和 PSBT，ECDSA 和 Schnorr 两种比特币签名都支持。Exchange- Pool 模型的 Pool 其实就是 Key，例如用符文 $DOG 换比特币，那么在这个 Exchange 里就需要一个 pool，持有符文 $DOG 和比特币两种资产。最简单的设计就是：Pool 里有两个 UTXO，一个是 $DOG，一个是比特币。这些 UTXO 的来源是在创建池时，由流动性提供者（LP）存入的，假设说是 100 万个 $DOG 和 1 个 BTC。当交易者（trader）想进行交换时，比如用比特币换 $DOG，前端就发请求给 Exchange 智能合约，问提供 0.1 个比特币，能获得多少 $DOG？假设系统的回应是「10 万个 $DOG」，它不仅告诉交换的数量，还会返回池中的两个 UTXO。这时前端就可以构建一个 PSBT，包含 3 个 UTXO 的输入：5、OP_RETURN，用于分配前两个输出的符文。用户认可交易条件就签署 PSBT。前端把 PSBT 提交给 REE 的协调者（Orchestrator）智能合约。协调者验证 PSBT 的输入和输出是否符合 REE 的规范，也会去 Omnity 开发符文链上索引器检查输入的资产类型和数量。协调者完成验证后，把 PSBT 传递给 Exchange 智能合约。Exchange 智能合约检查 PSBT 携带的交易条件是它之前给出过的，就把签署 2 个 Pool 的输入。这时 PSBT 的 3 个输入都已经签名。协调者会通过比特币子网接口，从 ICP 链上直接将交易广播到比特币网络，完成比特币交易的结算。Kay 哥：我的理解是，REE 的 Pool 使用 Taproot 地址，并且这个 Pool 是由一个 Key 控制，Key 是由 ICP 上的智能合约控制，然后 ICP 具备去中心化地控制 Key 去签名的能力。Louis：是的，这也是 DeFi 所必须的，因为绝大多数 DeFi 交易都是用户与资产池之间的交易，而非用户之间的直接交易。我们之所以选择在 ICP 上进行开发，主要因为它具备三个优势：1、在于 Chain Key 子网的高安全性。这个 MPC/TSS 网络，其实并不是给 Bitcoin 或者其他链集成开发的。ICP 本身是分片区块链，子网间发消息验证都基于 Chain Key 子网，所以它是 ICP 分片体系的核心。 从 ICP 第一天上线，Chain Key 就开始运行了,保护着几十亿美元的加密资产至今。2、ICP 提供 Bitcoin 子网集成。Bitcoin 子网的每个节点都运行比特币全节点，跟随 Bitcoin 网络共识。而且比特币子网是与比特币网络是 P2P 协议连接。因此 ICP 智能合约可以通过 Bitcoin 子网发送比特币交易，读取比特币状态。 3、Omnity 为实现全链上的符文跨链，将符文 Ord Indexer 移植到了 ICP 链上。所以 REE 访问符文协议数据也在链上完成。具备这三个条件，REE 的实现就比较容易，也避免了中心化问题。Kay 哥：您提到 REE 的交易延迟低于比特币的确认时间，我有些疑惑，因为最终 PSBT 还是需要广播到比特币主网，等待区块确认。为什么说交易延迟会比比特币的确认时间短呢？不是仍然需要等待 10 分钟吗？Louis：TPS 和延迟是计算系统性能的两个方面，而延迟对用户体验影响更大。还用刚才的例子，你用 0.1 个比特币换了 10 万个 $DOG，几秒钟之后交易成功，REE 就认可你有了 10 万个 $DOG。也就是说，虽然交易还没进比特币区块，但是 REE 认可它有效，所以你马上可以做下一笔交易：比如用这个 10 万 $DOG 去做抵押。这时第二笔交易依赖第一笔交易，在 memepool 里 面属于父子交易，在下一个比特币的区块会把这两笔交易一起打包进去。所以我们称之为乐观执行、批量结算。从用户的感知上来看，交易的延迟就是几秒钟。Memepool 接受的父子交易的串接不能超过 25 笔，这是每个 Pool 的结算上限，但不是 REE 的上限：因为每个 Exchange 可以管理多个独立运行的 pool。也就是说，Bitcoin 一个区块可以为一个 Pool 最多结算 25 笔交易。如果需要更大吞吐量，就通过增加新的 Pool 来实现。Tim：关于父子交易递归引用，比特币全节点已经全面支持 RBF（Replace-By-Fee）。这意味着广播的交易可以被替换，REE 如何处理？Louis：REE 交易禁用了 RBF。但是一个 UTXO 如果在 REE 被使用，同时又在 Memepool 里被其他交易使用，会导致 REE 的双花问题（Double Spend）。REE 采用了「乐观执行」和「批量结算」策略。乐观执行允许在没有最终确认的情况下继续执行交易，但如果出现不乐观的情况，就需要回滚交易。在 REE 白皮书中提到，Pool 应该形成状态链（State Chain）结构：Pool 每次执行交易，就把 Pool State，包括 UTXO 数据复制一份，放到状态链的头。1、如果需要回滚某笔交易，就把这笔交易之后的状态链切掉，恢复到执行前的状态。2、如果这笔交易已经有了四个或五个确认，状态链的尾部会被切除。REE 的第一个 Exchange，RichSwap，会实现状态管理通用逻辑，后续的 BTCFi 应用可以参照这个模版来写。主持人 Jasmine：比特币交易的确认时间大约是十分钟，这意味着黑客有充足的时间来部署合约攻击。请问 REE 是否有应对像 sandwich attack 等攻击的方案？Louis：实际上，我们很难判断是否遭遇攻击，关键在于确保 REE 状态与比特币链上的状态最终一致。比特币本身链上不存在双花问题，但链上可能会发生重组。而比特币的内存 mempool 是一个分布式数据库，它并非总是完全一致。 因此，从一个内存池获取的信息并不一定是最终的，有可能被证实为错误或者被其他交易覆盖，这些情况都需要考虑进去。 ICP 在链上有比特币子网，可以读取比特币区块链的状态，读 Memepool 的状态，这些事件会传递给 REE 的协调器（orchestrator），让协调器知道哪笔交易出现了变化或者被哪些交易覆盖。 根据确认的情况，协调器会判断交易是否已经完成，并决定是否需要回滚。如果交易已成功广播出去，但后来被其他交易覆盖，REE 协调器会通知 Exchanges，这笔交易需要回滚。 这种情况会导致用户刚开始看到交易成功，后来又发现交易被回滚了，是不好的响用户体验。 因此 REE 完善输入检查，并且尽量缩短交易处理的时间，包括缩短比特币链和内存池状态变化的感知时间，从而尽量减少最终一致性确认的延迟。我们有信心把延迟控制在秒级，让绝大多数乐观执行的交易不需要回滚，从而让 REE 的 BTCFi 有良好的用户体验。Kay 哥：magiceden 的防狙击功能采用了 SIGHASH_ALL 的签名方式，以防止交易输出被替换，REE 是否也有类似的机制？Louis：REE 采用了 SIGHASH_ALL 的签名类型，Output 是不能被取代的，这跟 Arch Network 的处理区别很大。在 Arch Network 中，用户签署了 PSBT 后，协议仍然可以修改 PSBT，添加新的输入和输出。而 REE 使用的是 SIGHASH_ALL，用户签署后，智能合约只能选择是否签署，而不能修改这个 PSBT。REE 选择 SIGHASH_ALL 的签名，让 Output 不能被取代，主要是为了避免 MEV。假设 ICP 节点的运营商合谋，故意将一笔交易提到前面，这样 MEV 交易会成功，而用户的交易则会失败：失败的交易无法被三明治攻击。也就是说，前面的交易是否盈利，攻击者自己要承担风险。主持人 Jasmine：关于明年一季度将推出的 RichSwap，Louis 还有什么要补充的吗？Louis：关于RichSwap，REE 白皮书中也提到了，希望它能够成为示范性应用。AMM DEX 可以成为 DeFi 流动性枢纽，能够帮助后续项目更快地启动流动性。另外，RichSwap 会内建符文价值捕获机制：BTCFi 可以将协议收入捐赠给自己符文的池子——将某个协议的 BTC 放入池中，但不进行兑换，实际上是在推高该符文的价格，这是一种相对简单通用的价值捕获手段。💡RichSwap 已经承诺将协议收入捐赠给符文 HOPE•YOU•GET•RICH。 其他项目也可以考虑采用这种方式实现价值捕获。大致上，这就是我们希望通过 RichSwap 达成的几个目标。社区成员 A 提问：使用 REE 的话，gas 会更低嘛？REE 中的交易和比特币主网的一层交易是相同的。我们在技术上能做的就是尽量让这个交易更小，把成本降下来，但本质上它仍然是一笔比特币主网交易。Tim：比如稳定币这类 token 一般会采取按需发行，不需要的时候会销毁。RichSwap 的 LP token 是否属于业务 token？如果采用 Runes 协议，他没有 mint 和 burn 的功能，如何按需发行和销毁呢？Louis：RichSwap 并不会发行 LP Token，而是在 Pool 上记录 LP 的份额。LP Token 的好处是可以用于衍生交易。如果发 LP Token，需要确保其具备流动性，短期内也无法用于抵押，缺少和其他协议组合的机会。RichSwap 目标之一就是帮助开发者理解 Exchange-Pool 模型，并且仿照开发出像借贷、稳定币等应用。因此我们希望 RichSwap 的实现尽量简洁。当然，有些 Exchange 不可避免地要去发行符文，像 l aunchpad 之类。目前 Runes 原生就没有动态的 supply，那怎么办呢？可以一次性发行，将总供应量锁定在智能合约中，再按需释放。社区成员 B 提问：REE 是否能够直接或间接与现实资产进行对标？Louis：REE 也许应该和 EVM 来对标吧。REE 本身没有自己的代币，也不收取 Gas 费用。 REE 是开发平台，应用可以选择发行自己的 Token ，例如 RichSwap 选择将协议收入捐赠给 RICH 符文。社区成员 C 提问：REE 是否专门针对符文 Runes 设计的协议？Louis：理论上，REE 的技术路线可以兼容任何基于 UTXO 的资产标准。但目前，比特币排名前三的就是 BTC、符文和铭文，BTC 不用说一定支持，而铭文不是完全基于 UTXO 的。我们认为符文在比特币生态中的潜力最大，因此将符文作为 REE 主要支持的代币标准，在命名上，就定义成符文交易环境。符文协议标准，可以发各种类型的代币，包括实用代币（Utility Token）、治理代币（Governance Token）、稳定币（Stablecoins）等。目前主要障碍就是缺乏交易环境，而 REE 正是为了填补这一空白，希望由此催生众多 BTCFi 应用。社区成员 D 提问：是否有合作伙伴正在基 于 REE 进行开发？Louis：我们与一些同行进行了交流，反馈总体上是积极的。REE 在安全性和用户体验上的平衡大家都比较认可。关键问题是我们需要推出基于 REE 的第一个 RichSwap，通过实战来验证和证明 REE 的技术优势。比如，REE 能够实现几秒的低延迟，交易批量结算，并且实际需要回滚的比例也极低。让开发者看到，REE 确实可以支持用户体验良好、高度可靠的 DeFi 应用。我们相信就会有很多比特币开发者会选择在 REE 上构建。社区成员 E 提问：如果有开发者有兴趣在 REE 平台上进行开发，该如何和 Omnity 联系？Louis：关注 Omnity Twitter 吧。文档、代码实例和公开测试网会一步一步提供出来。有了这些，开发者就可以在 REE 平台上进行开发了。REE 的 BTCFi 协议其实就是 ICP 的智能合约，只是多了几个 REE 要求的方法。有了这几个方法，智能合约就可以被 REE Orchestrator 调用起来，并接收到状态通知。如果大家有兴趣基于 REE 构建 BTCFi 应用，我建议可以先着手熟悉 ICP 智能合约开发。免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议，不代表 RunesCC 立场。
| 关注「Runes 中文社区」
Runes 中文社区，旨在为大家提供 Runes 协议赛道相关资讯、研报和工具，构建交流和共建的平台。
▣ 请进 Telegram 群：https://t.me/RunesCC
| 往期精选
《REE：图灵完备的无跨链比特币执行层 ｜白皮书中文翻译》
《RunesCC 发起人 MiX 谈 Runes 符文的跨链安全性》
《深挖 RSIC 生态的故事元素及神秘信息》
《打符文小技巧之钱包管理》
《金狗博士：史诗铭文旁观者侧记》
《2 号符文 Decentralized 首场中文 AMA 回顾》
