撰文：浙大链协，BiHelix，ScaleBit & BTC Security Lab
Intro： Why BTC L2
2023 年铭文生态的爆火，使得 BTC 拓展性问题的优先级迅速升高。各类彩色币（Colored Coin - 在比特币区块链上通过附加信息给比特币赋予额外属性或意义的方法，比如 BRC20）使原生比特币交易产生拥堵，BTC L2 作为解决这个问题的关键，会成为 2024 年的关键叙事。本文将带大家深入了解 RGB、BitVM 以及基于闪电网络的 Nostr 这三个潜力巨大的 BTC L2 解决方案。
RGB 协议
什么是 RGB
RGB 是一套适用于比特币和闪电网络的可扩展且保密的智能合约协议，由 LNP/BP 标准协会开发。它采用了私有和共同所有权的概念，是一种图灵完备的、无信任的分布式计算形式，不需要引入代币的非区块的去中心化协议。需要明确的是，RGB 中没有网络，也没有区块链，它是一种客户端验证技术，是一个部分状态智能合约系统。
RGB 协议发展历程
RGB 协议历史
RGB 最初由来自 BHB Network 的 Giacomo Zucco 于 2016 年设想为 “基于非区块链的资产系统”，同年，Peter Todd 提出了一次性密封（Single-use seal）和客户端验证（Client-Side Validation）的概念。受到这些重要思想的启发，RGB 于 2018 年被提出。2019 年，核心开发者 Maxim Orlovsky 开始推动 RGB，并参与了了绝大部分 RGB 协议的代码开发和底层标准设计。Maxim Orlovsky 和 Giacomo Zucco 共同成立了 LNP/BP 标准协会（https：//www。lnp-bp。org），旨在推动 RGB 从概念诞生到实际应用的阶段。该协会得到 Fulgur Ventures 、 Bitfinex 、Hojo 基金会、Pandora Prime 和 DIBA 的支持。经过大量开发工作， 2023 年 4 月，RGB 发布了版本 V0。10 ，这是第一个稳定可用的版本。2024 年 1 月，RGB 核心开发者表示会在上半年尽早推出版本 V0。11。
RGB 协议最新进展
RGB V0。10 的新特性介绍，在其他研报中已有详细分析。而 V0。11 目前尚未正式推出，这里展示一些开发者和社区的最新动态：
- 即将增加对于 L-BTC 的支持
- RGB 资产与 Liquid 的资产的互操作性和跨链桥会有更新
但是， RGB V0。11 将与 V0。10 不兼容，这会导致目前的项目迁移成本很大，同时由于开发进度缓慢，目前很多项目都处于坐等 V0。11 发布的状态。
RGB 设计思想和运行原理
RGB 智能合约采用客户端验证，这意味着所有数据都保存在比特币交易之外，即比特币区块链或闪电通道状态。这使得系统能够在闪电网络之上运行，而无需对 BTC 主网或闪电网络协议进行任何更改。这为协议的可扩展性和隐私性奠定了基础。
RGB 使用在比特币 UTXO 上定义的一次性密封，这为拥有智能合约状态历史记录的任何一方提供了验证其唯一性的能力。换句话说，RGB 利用比特币脚本来实现其安全模型以及所有权和访问权的定义。
RGB 是状态转换的有向无环图（DAG），其中合约彼此完全隔离，除了合约所有者（或所有者向其披露合约信息的各方）之外，没有人知道它的存在。
有向无环图（DAG）是一种特殊的图形结构，可以用来形象地解释复杂的系统或关系。我们可以将有向无环图中的每条边想象为城市中的一条单行道，这就是 “有向” 的概念。而假设在这些道路中，无论你怎么行驶，都不可能回到起点形成一个闭环，这就意味着 “无环”。在有向无环图中，也是如此，不存在一个节点序列使得你可以从一个节点出发，经过一系列的边，再回到这个节点。
将这个概念应用于 RGB 系统中，我们可以将每个合约视为图中的一个节点，而合约之间的关系（比如所有权的转移）可以视为有方向的边。这样的结构保证了合约间的关系清晰、有序，且不会形成闭环，即一个合约不会直接或间接地影响到自己。
这样的设计确保了状态传递中的承诺是唯一且不可篡改的，防止了双花，实现了状态转移的有效和一致。
深入 RGB 合约
在了解 RGB 架构设计的基本思想后，我们来看合约部分。在当前的智能合约世界中，要求智能合约创建者组织或自行执行智能合约代码的开发。在 RGB 的设计哲学中则认为，这是一种不好的做法，会导致更高的合约代码漏洞和多次黑客攻击。故 RGB 意在降低开发中的漏洞风险与审计需求，引入了「合约模式（Schema）」的概念。「合约模式」是智能合约的实际代码，发行者可以将其用作 “合约模板”，无需他们对某个随机外包商为其编写的定制代码进行编码或审核。
灵活的可扩展性和良好的互操作性
RGB 合约是通过声明式的方式定义的，而非命令式编程。这意味着合约的逻辑不是通过一系列命令或步骤定义的，而是通过一套规则来描述其行为和状态转换，是一个状态变化的有向无环图（DAG）。而局部状态操作，则是 Schema 的关键所在。RGB 合约中的操作是局部的，而不是全局的。每个节点（或状态）都有自己的规则，并且只负责自己的状态转换。这与以太坊等平台上的全局算法不同，后者要求每个状态都遵循相同的算法。这一特性使得 RGB 足够灵活可扩展，同时也兼具良好的互操作性。
简易的智能合约编写
Schema 定义了状态转换中允许哪些类型的全局和拥有的状态、密封、元数据。RGB 使用 Contractum 语言来编写程序 RGB Schemas 和 AluVM（算术逻辑单元虚拟机），从而简化 RGB 智能合约的编写。AluVM 基于寄存器设计，不提供随机内存访问，非常适合智能合约、远程代码执行、分布式和边缘计算等领域，为各种高级智能合约的用例提供了基础。
RGB 如何确保安全和隐私
从 RGB 自身设计上看
- 非全局广播的隐私性：上面我们已经提到，RGB 的客户端验证意味着验证过程仅发生在直接涉及的对等点之间，而不是整个网络。这种并非全局广播的方法增强了隐私性和抗审查性，因为合约状态的细节仅对相关参与者可见，矿工也无法看到交易细节
- 沙盒环境的数据私有性：另一方面，RGB 将所有操作数据存储在 stash 中。由于 RGB 不是基于区块链的，存储不会复制到其他对等节点。由用户本地控制的存储减少了外部攻击和数据泄露的风险，确保了数据的私有性。RGB 是一个计算平台，RGB 将每个程序（“智能合约”）隔离在其沙箱环境中，这比基于区块链的平台提供了更好的可扩展性和安全性。
- 同样，链下数据也就意味着存在丢失风险。
- 验证和存储以外，发票系统也能确保安全和隐私。RGB 中的合约操作通过创建发票来进行，发票可以包含多种合约操作请求。通过让用户明确指定和验证合约操作，提高了操作的准确性和安全性。同时，发票系统支持在用户之间私下传输合约操作请求，增强交易隐私。通过发票和特定的命令来执行状态转移，如代币转移。
从与 BTC 交互的层面来看
- RGB 的设计是与 UTXO 高度绑定的。与 BTC 主网交互过程中，用户创建链下合约来发行 RGB 资产并将它们分配给比特币的 UTXO，这一点和闪电网络非常像，随后在链下通过上面介绍的方式进行资产转移、合约交互和验证。
- RGB 受益于 Schnorr 签名带来的更好的多签、基于适配器的签名协议和点时间锁合约（PTLC），但它的收益纯粹是基于比特币的收益（即间接的）。RGB 内部没有任何需要签名的内容（因此 Schnorr 在内部没有进行任何更改），也没有使用比特币脚本（因此新的 Tapscript 没有任何用处）。
由 ScaleBit 联合发起成立的 BTC Security Lab，是一家专门成立的 BTC 安全实验室，正在致力于研究 RGB 协议的最新进展，旨在保护其合约安全，共同推动 RGB 协议的日益更新壮大及 BTC 生态的基础设施建设。
RGB 生态项目一览
1.BiHelix
BiHelix 是一个基于比特币原生区块链，结合 RGB 协议和闪电网络构建优化节点的比特币生态基础设施。旨在让开发者更易于使用，增加比特币的使用场景，并解决了比特币区块链面临的可扩展性和图灵不完备性的挑战。为矿工、验证者、节点服务商、交易所、用户打造更加公平的去中心化加密世界。作为第一个基于 RGB 协议构建的基础设施，BiHelix 将打造下一代比特币大规模应用场景。目前项目暂未开启交互，处于研发阶段，敬请期待。
项目特点
1.低用户门槛
使用 SLR（Security-Lightning-RGB）协议，将 RGB 和闪电网络重新封装，引入闪电节点的创新解决方案，实现全球通用支付。
2.高可靠性和高可扩展性
采用成熟的云服务架构，充分利用 rust-lightning 的特性，以支持通道工厂的功能，高效地管理通道，批量创建通道。
3.安全和隐私保护
将状态数据进行链下传输和存储，采用递归零知识证明等技术令多部分支付和路径选择随机化从而实现隐私保护。
4.开发者友好
提供完备的开发工具，包括开源的开发文档、工具等，同时引入 Schema 社会共识机制，以便开发者可以轻松构建应用程序。
IRIS Wallet，Bitfinex 团队开发的第一个 Android 钱包，致力于 RGB 集成和 RGB 相关工具，支持可替代和不可替代资产（fungible and non-fungible assets）。 Iris Wallet 支持从发行到支出和接收的 RGB 资产操作，将所有功能包装在一个熟悉的钱包应用程序中，并尽可能多地抽象出技术细节。目前这还是一个实验性应用程序，建议仅用于少量比特币和低价值资产。
3.DIBA
DIBA 是第一个在比特币上使用 RGB Protocol 的智能合约和闪电网络的 NFT 市场。它旨在帮助塑造人们对比特币区块链上非托管艺术资产的理解。
4.Bitmask
该钱包由 DIBA 创建，是 RGB 生态的首个 NFT 钱包，可在 Web 浏览器中运行，并与类似以太坊上的 MetaMask 一样与 RGB 合约进行交互。目前更新频繁，等待 V0。11 发布。
Pandora Prime 是一家位于这是一家总部位于 Verify Valley 的瑞士公司，同时也是 LNP/BP 的创始成员。
Pandora Prime 致力于使用 RGB 智能合约和闪电网络的结合来开创比特币金融（Bitcoin Finance）。他们从比特币上的可编程资产 （RGBTC 和 CHFN ）开始，这些资产可以通过闪电网络在交易吞吐量方面扩展到 VISA/MasterCard 级别，同时提供轻松交换这些资产的设施。目前，他们的产品包括 MyCitadel（钱包）、RGB Explorer（浏览器）和 Pandora Network 等。
MyCitadel 是 Pandora Prime 的一个品牌，MyCitadel 是第一个支持 RGB 的图形用户界面钱包，由 RGB 开发人员于 2021 年创建。它提供跨平台桌面钱包和 iOS/iPad 钱包。移动钱包可以处理可替代性的 RGB 资产。
RGB Explorer 是由 Pandora Prime 开发的第一个提供 RGB 资产注册和智能合约的浏览器。目前支持 RGB 20、RGB 21、RGB 25 ，可以显示的资产有 LNPBP、RGBTC、dCHF 和 RGBEX 这四种。
8.Bitlight Labs（旧名 Cosminmart）
Bitlight Labs 开发基于 RGB 协议的基础设施，预备在闪电网络上部署多个应用程序，包括 RGB 实用钱包 Bitlight Wallet 以及在闪电网络和 RGB 协议上建立 BitcoinFi 自动化做市商的 Bitswap。
RGB Memes & NFT
1.PPRGB(X： @PepeRgb20)
PPRGB 目前在 Liquid 网络发行，等待 RGBV0。11 版本后会映射到 rgb 上，（RGB v0。11 版本也在做和 Liquid 对接相关代码功能）。
2.MRGB 铭文
MRGB 铭文是一种基于 RGB 协议的客户端状态验证和智能合约系统的通证。该通证在比特币生态系统的第二层和第三层（链外）运行，并且将提供开源底层协议代码，使所有 BRC20 公链能够直接使用该系统。
这一创新将为 BRC20 公链带来巨大的潜力，包括降低 GAS 消耗、加快交易速度以及提升整 体性能。通过采用 MRGB 系统，BRC20 公链将能够更高效地处理交易，并降低用户的交易成本。与此同时，MRGB 铭文通证还将作为交易过程中的消耗品，从而增加了 BTC 的流动性和可扩展性。
3.Single-Use-Seal(X： @Single_Use_Seal)
海豹 ，是 RGB20 和 RGB21 上 10k PFP 集合、稀有 UDA 和代币，命名取自 Peter Todd 提出的 Single Use Seal（一次性密封），目前在等待 Bitlight 和 Bitmask 钱包更新 v0。11 RGB 版本，之后会在上面发行。
4.Bitman(X： @bitmancity)
会在 diba 上发行 10k UDA，可能是是 wl+public sale，宗旨是 “传递 btc 的精神”，项目立意不错，会发 wl 给 BTC 生态贡献者，公售大部分捐给 LNP/BP。
BitVM
Why BitVM？
BitVM（Bitcoin Virtual Machine） 引入了一个系统，可以在比特币区块链上验证任何计算，并且不会影响其安全性或改变网络。这一发展为复杂计算（例如图灵完备的智能合约）打开了大门，所有计算都在链外进行处理，以减少比特币区块链的拥塞。
「简单概括，BitVM 是一个能在比特币网络上表达图灵完备合约的计算模型。」与 RGB 一样，BitVM 无需修改网络的共识规则。
2023 年 10 月 9 日，区块链开发商 ZeroSync 的联合创始人 Robin Linus 公布了 BitVM 的白皮书。相比于 RGB，BitVM 年轻许多 。
BitVM 的设计架构
架构
与乐观 Rollup（Optimistic Rollups）和 MATT 提议（Merkelize All The Things）相似，基于欺诈证明和挑战 - 响应协议，不需要改变比特币的共识规则。BitVM 证明了比特币在编码欺诈证明的大型 Taptrees 中是图灵完备的。
门电路设计
Bit Value Commitment 是最基本的组件，允许提交者设置特定位的值为 “0” 或 “1”。任何可计算函数都可以表示为布尔电路，构成逻辑门承诺。通过 NAND 门（通用逻辑门）来构建，每个门都有自己的承诺。通过组合门承诺来表达任何电路。每个执行步骤都在 Tapleaf 中被承诺，并且在同一个 Taproot 地址中组合。
BitVM 利用比特币的 Taproot 升级，通过创建一个类似于二进制电路的结构（称为 taptree）来实现其功能。在这个系统中，每个 UTXO 的花费条件，由 Script 脚本中的指令表示，形成程序的基本单元。这些指令在 Taproot 地址内生成二进制输出（0 或 1），从而构建出整个 taptree。taptree 的输出可以被视作一个二进制电路的运行结果，类似于一个可执行的程序。taptree 能够执行的程序复杂度取决于组成它的 Taproot 地址的数量和复杂性。简而言之，BitVM 通过将比特币的 Script 指令转化为二进制操作，实现了在比特币网络上运行更复杂程序的能力。
参与角色为两方
目前模型局限于两方，目前无法扩充参与者。此外，为了使 BitVM 正常工作，需要进行大量的预签名（链下计算），这导致 BitVM 实际相当复杂，可能存在效率不足的问题。
欺诈证明与挑战 - 响应协议
证明者与挑战者进行都在一个交易中存入同等数量的 BTC 进行对赌 （ 作为输入 ），而这个交易输出将包含一个逻辑电路。通过在设置阶段预签名一系列交易来实现对于错误声明的反驳。BitVM 被比作 Optimistic Rollups（乐观卷积），因为它在链外执行大部分计算，并且在出现争议时将其中一些计算提交到链上以解决争议。
- 乐观汇总是一种第 2 层扩展解决方案，它通过将计算和数据存储移至链下来减轻基础层的负载。然后它捆绑多个交易并将它们发布到主链。
- 乐观汇总假设所有交易都是有效的。然而，如果网络参与者意识到发生了不诚实行为，他们可以发起欺诈证明。欺诈证明是某人计算不准确的证据。它们是在检查后产生的。
链下计算
BitVM 上的几乎所有活动都在链外进行。这包括启动计算任务、共享数据和验证提交的声明。BitVM 通常不在比特币区块链上运行计算。仅当因涉嫌欺诈而存在争议时，计算活动和验证才会在链上发布。然而，如果存在争议，争议程序的一小部分确实在链上运行，仅足以找出哪一方不诚实。
有了上述前置知识，我们可以更好地理解 BitVM 两方互动的具体原理。
BitVM 的两方互动模型，涉及一个证明者（Prover）和一个验证者（Verifier）。在这个系统中，证明者首先创建并提交智能合约或程序，随后将资金发送到一个共同控制的主根地址。这些资金被以 2-of-2 多重签名的方式保管。证明者还需向验证者共享足够的信息，以证明他们的程序能产生承诺的输出。
验证者的任务是运行证明者的代码，并验证输出是否符合预期。如果输出不符合预期，验证者将对证明者发起挑战。这一挑战 - 响应的交互过程涉及在链下的数据交换和预签名交易的使用，以验证计算的正确性。
在发现计算错误时，验证者可以通过链上的欺诈证明来公开证明者的不诚实行为。在 BitVM 系统中，如果证明者的响应被证实是错误的，他们将输掉赌注并丧失资金。相反，如果所有答案都是正确的，证明者将保留他们的资金。这种经济激励机制旨在防止不诚实行为。
最终，这种互动保证了只有在出现争议时，计算验证才会转移到比特币区块链上，从而在链外执行绝大多数计算。这种设计既保持了比特币网络的高效性，又提供了在比特币上运行更复杂程序的能力。
BitVM 的安全性
从架构设计角度分析，BitVM 的安全性主要基于以下几个方面：
欺诈证明（Fraud Proofs）
在发生争议时，验证者可以通过欺诈证明来挑战提出者的错误声明。这种机制类似于 Optimistic Rollups ，不需要改变比特币的共识规则。
挑战 - 响应协议
BitVM 使用挑战 - 响应协议，其中提出者和验证者在协议的设置阶段预先签署一系列交易。这些交易在争议发生时用于解决问题。
链外计算与链上确认
BitVM 允许在链外执行复杂计算，而只有在出现争议时，相关的验证和解决才会在链上进行。这种方法减少了链上资源的消耗，同时保持了比特币区块链的完整性和安全性。
存款和惩罚机制
如果提出者作出不正确的声明，验证者可以没收其存款。这种机制确保了攻击者总是会因为错误的行为而损失存款。
双方合约机制
使得 BitVM 上隐私性更佳，降低了交易成本，但是相比 EVM 的多方机制，通用性有所下降。
Nostr 协议
什么是 Nostr 协议
Nostr 全名为「Notes and Other Stuff Transmitted by Relays」，直译为「中继器传输的笔记与其他内容」。从协议全称不难看出，这是一个传输协议，并且，有中继器存在，说明这并不是一个 P2P 传输协议。[Github 代码]（https：//github。com/nostr-protocol）更新记录显示，这一项目启动于 2020 年 11 月。该协议旨在创建一个抵制审查的全球社交网络的最简单的开放协议， 是一个去中心化的社交协议，它允许用户创建、发布和订阅任何类型的内容，而不受任何中心化的平台或机构的控制或干预。Nostr 的灵感来自于比特币与闪电网络，它使用了类似的密码学和共识机制，以及一种基于事件的数据结构，称为 Nostr 网络（Nostr Network）。
Nostr 协议的组成
公私密钥对
一个公私密钥对即是一个 Nostr 账户。Nostr 账户并不基于传统的用户名、密码体系，而是使用类似加密货币的公钥、私钥体系。为方便理解，可以把公钥当成用户名，把私钥当成密码。要注意的是，私钥一旦丢失无法像密码那样可以重置。公钥以 npub1 为前缀，私钥以 nsec1 为前缀。使用前要确保公钥、私钥妥善保存，因为其一旦丢失无法找回。
客户端
Nostr 本身只是一种协议，用来在互联网上发送信息。用户需要一款客户端软件来使用 Nostr 协议。客户端可以是网页、桌面软件或者手机 App。客户端从中继器读取信息，并且将新生成的数据发送给中继器以便其他客户端读取。信息包含签名，这些签名可以确保数据由真实的发送方发送。客户端使用私钥来创建签名。第一次使用桌面或者手机客户端，需要将私钥存储其中。通过私钥可以得到公钥。如果使用网页客户端，不推荐直接将私钥保存其中，最好使用插件来保存私钥。
中继器
可以将中继器理解为 Nostr 协议的后端服务器。Nostr 客户端将信息发送给中继器，中继器会（也可能不会）存储这些信息并将信息广播给所有与他们相连的客户端。需要注意的是，中继器并非一成不变，相反他们会随着时间的推移变动很大。Nostr 协议依赖中继器来存储和检索数据，如果用户感觉自己的客户端速度很慢，那是因为所连接的中继器速度慢，可以考虑增加一些其他的中继器。
NIPs
Nostr 实施标准（A Nostr Implementation Possibilty， 简称 NIP），用来规范兼容 Nostr 的中继器和客户端软件，哪些必须、哪些应当、哪些可以实施。「NIP 」是概述 Nostr 协议工作原理的参考文档。Nostr 是一种去中心化协议，并不被某一个中心化机构所垄断（比如推特）。这意味着协议的发展方向取决于所有参与者，我们可以建议和倡导变革，并对他人提供的想法提供反馈。作为协议社区的积极成员，大家对 Nostr 网络的后续发展方向都有一定的话语权。主代码库中的 NIPs 已经通过，可以通过 pull request 添加新的想法。
以下列举一下较为重要的 NIPs：
- NIP-04： 消息加密，利用 secp256k1 算法来完成 Diffie-Hellman 密钥交换，点对点加密
- NIP-05： 映射公钥到域名，方便记忆，比如作者的公钥是 npub10jprg9n3ecjlpez0fyg7y7yvpl66drtjv8rv0hfllxpdxhesuwzs4c2kw6，映射到了 @NomandJames 这个域名上面
- NIP-06： 助记词，和加密货币钱包的助记词类似
- NIP-13： 工作量证明。此概念的提出早于比特币的出现，现被广泛应用在区块链 POW 共识层中，以太坊 whisper 协议中也有应用。它的原理是在客户端发送消息之前，要先完成一个计算密集型的工作量证明，接受信息的中继服务器会验证这个证明的有效性。提供这个证明意味着花费了算力，提高了发送垃圾信息堵塞中继的门槛。
- NIP-22： 消息时间戳。告知中继服务器消息创造的时间，以便中继选择性的接收消息。时间戳可以设置为过去或者未来。
- NIP-40： 过期时间。告知中继服务器消息过期的时间，以便中继删除。
- NIP-57： 闪电网络打赏链接。
- NIP-65： 中继服务推荐列表。
事件
事件是 Nostr 上唯一的 `Object` 结构。每一个事件结构都有一个类别（`kind`）。类别用来标记事件的种类（用户实施了哪种操作或者接收了哪种信息）。
Nostr 协议的运作
Nostr 协议是通过中继器运作的。这些中继器允许同一个中继器上的用户间互相发送 Json 文件。
将通过下面简化的图文举例，来方便大家理解：
图表中包含 3 个中继器（Relay）和 3 个用户（Client）。图中每一位用户使用的客户端都不相同（也不在同一个平台）。
图表中的读、写情况如下：
- Bob 可以看到 Alice 的所有推文，但无法看到 Mary 的任何推文（Bob 甚至不知道 Mary 的存在）。
- Alice 可以看到 Bob 的所有推文，但无法看到 Mary 的任何推文（Alice 也不知道 Mary 的存在）。
- Mary 可以看到 Bob 和 Alice 的推文。因为 Mary 只向中继器 3 写入数据，她可以从中继器 2（保存 Bob 和 Alice 的数据）读取数据。
深入 Nostr 合约
鉴于 Nostr 协议作为一个非常轻量级的开放协议，为去中心化的社交媒体平台提供了协议规范，我们试做简单的协议代码分析：
该协议的基础是一个 WebSocket 服务器（称为 nostr-relay），它的处理和存储是一个非常简单的数据结构，称为 Event。它如下所示：
{
"id"： <32-bytes sha256 of the the serialized event data>
"pubkey"： <32-bytes hex-encoded public key of the event creator>，
"created_at"： <unix timestamp in seconds>，
"kind"： <integer>，
"tags"： [
["e"， <32-bytes hex of the id of another event>， <recommended relay URL>]，
["p"， <32-bytes hex of the key>， <recommended relay URL>]，
。。。 //other kinds of tags may be included later
]
"content"： <arbitrary string>，
"sig"： <64-bytes signature of the sha256 hash of the serialized event data， which is the same as the "id" field>，
}
事件始终是签名的（使用 Schnorr 类型签名），并且它们之中包含可能具有不同语义含义的结构化数据。BIP340 中定义的 Schnorr 类型 XOnlyPubkeys（目前与比特币 Taproot 一起使用）在整个协议中用作 “身份”。
nostr-client 是一个 APP，可以与 nostr-relay 通信，并可以使用订阅器订阅任何一组事件。
筛选器表示客户端感兴趣的所有 Nostr 事件集。
客户无需注册或创建帐户，因为客户端会使用用户的公钥进行标识。每次客户端连接到中继时，它都会提交用户的订阅筛选器，只要它们已连接，中继就会将 “感兴趣的事件” 流式传输到客户端。
中继可以缓存客户端订阅，但并非必须如此。客户端应该在 “客户端” 处理所有事情，而中继可能像石头一样愚蠢。
Clients 之间不会互相交谈。但 Relays 可以。这将允许中继为客户端获取它没有的数据，而客户端可以订阅其连接的中继之外的事件。
乍一看，这给人一种 Nostr 作为协议毫无用处的形象，（为什么不直接签署和转储原始 JSON 并让客户端弄清楚呢？），但更深入地看，“哑服务器，智能客户端” 模型可以在去中心化协议设计中，发现具有一些巨大优势的工程。
充分去中心化为 Nostr 主要特点
Nostr 作为社交应用的协议层，该协议通过 Relay 传输 Notes 和其他 Stuff，不依赖于任何中心化服务器，其充分的去中心化，允许任何 App 应用自由的接入，通过分布式网络提供一个开放且无需许可的社交平台。因此，Nostr 甚至并不为用户提供可以直接操作的 C 端产品，而是专注于在协议层实现社交的必要基础设施。而产品化的能力则由第三方 App 提供。且各款不同 App 之间的用户，其社交行为是可互通的。
Nostr 的优势在于它提供了一种真正的自由和开放的社交网络，它不受任何中心化的权力或利益的影响或威胁，用户可以自由地表达自己的观点和信仰，不用担心被审查、封禁或取消；内容创作者可以自由地设置自己的激励模式，不用担心被剥夺收入或受到不公平的竞争。Nostr 的用户还可以自由地选择自己的社交圈子，不用担心被操纵、误导或剥夺隐私。
Nostr 与传统的社交媒体有很大的不同，它还有以下几个特点和优势：
去中心化
Nostr 不依赖任何中心化的服务器或平台，而是通过比特币网络来传输和存储信息。这样，用户就不用担心自己的数据被窃取、审查或删除，也不用受制于任何第三方的规则或政策。
自主
Nostr 让用户自己控制自己的数据和身份，用户可以自由地选择自己想要关注和信任的人，也可以自由地表达自己的观点和想法。用户不用担心被封号、屏蔽或降级，也不用忍受广告或推荐的干扰。同时对特定用户的可认证性，使用户易于识别垃圾信息和机器人信息。
开放
Nostr 是一个开放的协议，任何人都可以参与和贡献。用户可以自己开发和使用不同的客户端，也可以自己搭建和运行节点（node），节点是一种可以转发和存储 Nostr 信息的服务器。用户还可以自己创建和使用不同的类型（type）和标签（tag），这些是用于区分和分类 Nostr 信息的元数据。简洁灵活的事件（`Event`）格式支持各种类型的发布：社交媒体帖子、长格式内容、富媒体、电子商务等。同时 Nostr 与闪电网络相结合，实现了新的 [物超所值（value-for-value）、更加公平的商业模式。
Nostr 协议的安全隐患
私钥管理
Nostr 协议使用公私密钥对作为账户，用户需要自己妥善管理私钥。私钥一旦丢失，就无法找回。这对于大多数用户来说可能是一个挑战，因为他们可能没有足够的技术知识和经验来安全地管理私钥。
中继器选择
在 Nostr 协议中，用户需要自己选择和验证中继器。如果用户选择了一个不可信或者恶意的中继器，他们的信息可能会被泄露、篡改或者删除。
信息传播
在 Nostr 协议中，用户发送的信息不会在多个中继之间传播。这意味着，如果用户的信息没有被足够多的中继接收和存储，那么他们的信息可能会丢失或者无法被其他用户看到。
孤岛效应加剧
在 Nostr 协议中，中继器可以自由地选择是否接收和存储用户的信息。这可能导致一些中继器选择只接收和存储他们认为有价值或者符合他们利益的信息，而忽视或者拒绝其他的信息。
恶意协议扩展
Nostr 协议定义了一些基本的事件类型和功能，但是它也允许客户端和中继器选择性地实现一些额外的功能。这可能导致一些客户端和中继器实现了一些不安全或者恶意的功能，从而影响用户的安全和隐私。
信息处理方面
碍于 Nostr 协议没有共识层，对于时间戳和 UNIX 时间差距很大的消息，一些中继并没有进行处理，这使得客户端存在利用时间差伪造消息的可能。
Nostr 生态一览
Nostr 协议主要支持者为 Twitter 联合创始人 Jack Dorsey，早在 2022 年 12 月，Dorsey 向 Nostr 捐赠了 14。17 个比特币（约合 245，000 美元），以支持其开发，在他的 X 个人资料上，至今仍高调的显示着其个人 Nostr 地址，可见其对协议的喜爱。
Damus：Nostr 协议的主要应用
Damus 是一个支持基于闪电网络的比特币小费打赏社交 App，以打赏的方式来取代目前更为常见的「Like」或点赞，而闪电网络的低费率也让打赏的网络成本低到可以几乎忽略不计。
Nostr 协议的应用除了 Damus 之外，还有通讯工具 Anigma、文本共享工具 Sendtr、在线下棋小游戏 Jeste 等。
TGFB：Nostr 协议的主要合作媒体
TGFB 是一个基督教的比特币教育平台，它的目标是教育和装备基督徒理解比特币，并用它来宣传上帝荣耀和造福全人类。
其中很大一部分板块是留给 Nostr 协议的内容宣传播客，由 Jon 和 Jordan 主持，从基督教的角度探讨 Nostr 这个去中心化的社交协议的内涵和外延。作为欧美乃至全球都传教甚广的基督教，与美国全民皆知，且 sec 通过了 etf 的 Bitcoin，加上基于用户体量庞大的闪电网络之上建立的 Nostr 社交协议，三者结合，将带来一大批 Nostr 协议的拥护者和支持者，这无疑对 Nostr 协议生态的发展起到绝佳的推动作用。
Nostr 衍生协议
Nostr + Taproot assets
Nostr Assets Protocol 是一个开源协议，它将 Taproot 资产和以 Satoshis （Sats，聪）为单位的原生比特币支付引入 Nostr 生态系统，同时该协议支持与包括闪电网络和 Taproot 资产在内的其他支付协议进行交互。
用户一旦引入资产，就可以使用 Nostr 的公钥和私钥在 Nostr 协议层发送和接收它们。而资产的结算和安全仍然依赖于闪电网络，毕竟 Nostr 资产协议本身并不发行资产，只是通过协议将资产引入 Nostr 资产平台。
Nostr Assets 通过用 Nostr 消息来控制（托管）钱包，即帮助用户更好的进行转账 / 交易等基础功能，建立在 Nostr 的技术之上，但是跟 Nostr 是两个完全不同的协议。
Nostr Assets Protocol 的全托管服务是指用户将自己的比特币或其他资产存入一个由 Nostr Assets Protocol 控制的钱包，然后通过 Nostr 消息来发送指令，进行代币的部署、铸造和转移。
需要注意的是，全托管服务存在一定的争议：Nostr Assets Protocol 的托管钱包可能存在安全风险，用户无法完全控制自己的资产，如果平台被黑客攻击或者跑路，用户可能会损失所有的资产。
同时，Nostr 在 10 月 30 日上线后资产充值人数较多，多次出现网站关停维护的情况，引发了用户对其团队背景、项目可靠性的质疑。11 月 8 日，Nostr Assets Protocol 官方账号在一篇推文下回复了中文评论，目前部分用户对该项目方的真实身份和靠谱程度存疑。 而 Nostr 官方也一直对该 拓展协议中跟协议同名的 Token 持极为强烈的反对态度。
Nostr + Inscription
Noscription 是一个基于 Nostr 的实验性代币协议，它允许用户在 Nostr 上创建和交易类似于 brc-20 的代币，而非类似 Taproot assets 的代币。
三者对比
协议落地
BitVM 对于计算能力提出极高要求，目前仅有理论可执行性。商业落地方面 RGB 更胜一筹，且已经有很多应用。（RGB 的技术组织 LNP/BP 中开发人员很少且非盈利，开发进度缓慢）。Nostr 碍于 Socialfi 通用的瓶颈同样未能进一步推进协议应用生态。
隐私保护
RGB 和 BitVM 都是链下计算，但是 RGB 协议意味着第三方无法跟踪 RGB 资产在区块链上的历史，只有当用户收到资产时，才会了解资产的历史。这点 BitVM 无法做到。Nostr 协议作为社交协议，传播信息的中继器具有极高未知性，可能出现信息泄露，闭塞，丢失等问题，以及利用漏洞恶意篡改的恶劣行为
BTC 原生性
RGB 和 BitVM 都不需要对比特币进行协议更改；Nostr 则建立在原生闪电网络的基础上，原生性都相对较好，开发体验丝滑
协议的安全性
RGB 协议在链下执行，沙盒环境保证了数据的安全。发票系统也从设计上保证了数据的安全。与 BTC 交互层面来看，使用类似于闪电网络的模式进行资产发行。
BitVM 采用 Rollup 的模式，同样是数据链下执行。虚拟机的特性加上欺诈证明与挑战 - 响应模式确保了 BitVM 的安全。
Nostr 采用中继器的模式，中继器间信息传递的巧妙设计加上加密算法，使得 Nostr 协议中的信息足够安全。
在 Web3 行业中，目前并没有一家专门关注比特币生态安全的实验室。BTC Security Lab 的成立填补了这一空白，为比特币生态提供了专业的安全支持与研究。ScaleBit 与 BiHelix 希望能够引领比特币生态安全赛道，为整个行业树立安全标准，推动生态系统的健康发展。
生态与商业化
Nostr 协议作为社交协议，其用户体量和流量热度能超过 Bit VM 和 RGB 协议二者，其生态的协议拓展和应用商业化相对剩余二者更加完善。
RGB 协议发布已久，目前生态项目也比较多，很多都处于等待 RGB V0。11 发布的状态。
BitVM 白皮书发布距今只有几个月，目前生态还没有建立。
三者协议未来会应运而生诸多 Socialfi、GameFi、DeFi 领域的 Dapp，为 BTC 生态带来新一波的热度。
特别感谢 Ausdin。eth， 0xLayman， Echo， Venus 对本次报告作出的贡献。
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
