注：本文来自@AurtrianAjian推特，其贡献于BTCStudy.org，原推文内容由MarsBit整理如下：
BRC-20、上链的意义与“客户端验证”：为什么你不该继续购买用这些“协议”发行的token——它们根本不能被称为协议
比特币协议中有且只有一种东西：UTXO，比特币交易的输出，它的数额代表它的价值，它的“ScriptPubKey”表示它的花费条件。
可以用来编写脚本公钥的操作码是由比特币的共识规则提供的。这些操作码的意义在于编程验证条件，从而为一笔比特币UTXO设定花费条件；但它并不能用来定义任意我们想要的规则。
Curve Finance创始人通过OTC已出售1.06亿枚CRV:8月4日消息，Nansen分析师Sandra Leow汇总的链上数据显示，Curve Finance创始人Michael Egorov通过OTC的方式总共出售1.06亿枚CRV代币，换取4240万美元资金。[2023/8/4 16:18:52]
也就是说，比特币脚本并不能用来创造一种不是比特币的UTXO，也不能用来制作任意的安全机制。
所以，如果你想要在比特币链上发行资产，你永远只能依靠“链下协议”，举凡Omni、Counterparty、RGB、Taro、Ordinals，都不例外。
加州州长否决一项加密货币许可和监管法案:金色财经报道，加利福尼亚州州长Gavin Newsom否决一项加密货币许可和监管法案。该法案被视为可能是纽约州BitLicense的加州版本。
由美国国会议员Tim Grayson发起的Assembly Bill 2269将为任何希望促进加密交易的人创建一个许可制度。（CoinDesk）[2022/9/24 7:18:20]
关键在于，既然脚本公钥不能被任意编程，则这些链下协议所发行的资产，无论往链上写入什么数据，都不可能转化成这些资产的安全机制。举例，假如你发行了一种资产，无论你往链上写入什么数据，都不可能要求比特币网络来控制这种资产不通胀。
Symmetry推出Solana链上资产管理基础设施Symmetry Engine:7月20日消息，DeFi协议Symmetry在Solana上发布链上资产管理基础设施Symmetry Engine。
据悉，Symmetry Engine是SDK集合，包含Funds SDK、Liquidity SDK等功能，允许开发人员在链上构建资产管理应用程序，可以轻松创建、管理、自动化、跟踪、买卖指数和链上主动管理基金。（The Crypto Basic）[2022/7/20 2:25:39]
Omni协议使用OP_RETURN输出记录交易数据、OrdinalsNFT利用特定的格式加载内容，但这些东西都无法进入脚本公钥，都无法成为有意义的安全机制。
慢雾：Equalizer Finance被黑主要在于FlashLoanProvider合约与Vault合约不兼容:据慢雾区消息，6 月 7 日，Equalizer Finance 遭受闪电贷攻击。慢雾安全团队以简讯形式将攻击原理分享如下：
1. Equalizer Finance 存在 FlashLoanProvider 与 Vault 合约，FlashLoanProvider 合约提供闪电贷服务，用户通过调用 flashLoan 函数即可通过 FlashLoanProvider 合约从 Vault 合约中借取资金，Vault 合约的资金来源于用户提供的流动性。
2. 用户可以通过 Vault 合约的 provideLiquidity/removeLiquidity 函数进行流动性提供/移除，流动性提供获得的凭证与流动性移除获得的资金都受 Vault 合约中的流动性余额与流动性凭证总供应量的比值影响。
3. 以 WBNB Vault 为例攻击者首先从 PancekeSwap 闪电贷借出 WBNB
4. 通过 FlashLoanProvider 合约进行二次 WBNB 闪电贷操作，FlashLoanProvider 会先将 WBNB Vault 合约中 WBNB 流动性转给攻击者，随后进行闪电贷回调。
5. 攻击者在二次闪电贷回调中，向 WBNB Vault 提供流动性，由于此时 WBNB Vault 中的流动性已经借出一部分给攻击者，因此流动性余额少于预期，则攻击者所能获取的流动性凭证将多于预期。
6. 攻击者先归还二次闪电贷，然后从 WBNB Vault 中移除流动性，此时由于 WBNB Vault 中的流动性已恢复正常，因此攻击者使用添加流动性获得凭证所取出的流动性数量将多于预期。
7. 攻击者通过以上方式攻击了在各个链上的 Vault 合约，耗尽了 Equalizer Finance 的流动性。
此次攻击的主要原因在于 Equalizer Finance 协议的 FlashLoanProvider 合约与 Vault 合约不兼容。慢雾安全团队建议协议在进行实际实现时应充分考虑各个模块间的兼容性。[2022/6/8 4:09:22]
那么，如何增设这些自定义的规则呢？
答案是：我们要让资产的买方运行额外的验证程序，验证卖方所卖出的资产的属性，这就是所谓的“客户端验证”。比如，买方验证卖方所卖出的资产具有资产发行者的签名，以验证它是“真币”；
要让资产“附身”于某一个UTXO，从而让比特币交易变成链外交易的证据、防止同一个资产被重复花费。
这些自定义的规则，假设它能在客户端验证的基础上支撑其一个安全的协议，当然可以写入到比特币区块链，但是，这样的操作并不能增加安全性，因为真正的安全性来自于客户端验证。比特币协议做的事情，只是阻止UTXO重复花费，同时允许运用比特币脚本，为这样的资产编写在比特币链上转移的方法。
当前Inscription将内容通过见证脚本暴露出来的方法，仅仅起到了上文所述的的作用，即标记特殊的比特币交易、阻止重复花费，但是，只要它不要求客户端运行额外的验证，就无法为这些NFT也好FT也好增加定制化的规则。
然而，将资产附着到UTXO上并不需要你将资产的内容完全公布上链；将为资产转移而提供的数据写到链上将耗费大量空间，经济性极差。这都是没有意义的事，将这些数据在链下提供给买方就可达成同样的效果
所以，请停止买入使用Inscription方法发行的Token，直到这些Token的开发者提供允许客户端验证的规则，否则你买入的就是空气，得不到任何的保护。开发者们，如果你真的在乎你的用户，请先设想这样的客户端验证规则并实现这样的客户端。
许多朋友从别的社区进入这个生态，往往带着固有的认知来理解比特币，但在别的链上有意义的事，在比特币上不一定有意义。
请好好理解比特币，理解客户端验证范式，理解将一切其余资产都交给链外协议的智慧。通过消耗区块空间来获得可编程性的做法，注定在可扩展性和隐私性上面临可悲的结局
如果你想寻找在“客户端验证”上最完整的想法，请了解RGB协议：
https://btcstudy.org/tags/RGB/
RGB的钱包和工具库：
https://rgb.info/zh/home/
另一个RGB网站：https://rgb.tech/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。