Frost on Nostr: ...
晚上测试环境搭好操作了一下，果然是猜想的那样客户端侧验证：链上交易是通过私钥签名花费的 taproot UTXO，merkle tree 相关的 proof 全部存在本地文件夹。
[mint 交易](https://mempool.space/zh/testnet/tx/71c5796512f6b5600262d2242911a9b4ce50d5fda5aec224c54adfc67f349d4d)：也就是 genesis tx，asset 铸造在 tb1p0 这个 UTXO 上。
[第一次 send 交易](https://mempool.space/zh/testnet/tx/0c62d6cfce4570ddc55b60b5978f68d0321a8b7d3a55a1aea0ee98abf6f22659)：asset 从 tb1p0 转到 tb1p8，而 tb1gp 是找零。
[第二次 send 交易](https://mempool.space/zh/testnet/tx/8df1f41b0b3e2ee153533fe30e60c824be616608bd13725fe65786df86c9c930)：tp1pg 转到 tb1p5，tb1p009 是找零。
在文件夹 `~/.tapd/data/testnet/proofs/ASSET_ID/` 下保存的是**历史所有** UTXO 的 proof，可以证明每个 UTXO 里面的 P2TR 哈希是怎么算出来的。合约的语义通过已经上链的交易得到了证明。
每个客户端本地存用的 proof 相当于原来一条链所有交易数据的**子集**，因为现在只需关心自己的 UTXO 牵涉到的所有历史，最坏情况也是所有 UTXO 汇聚到一个地址变成了 proof 全集，所以每个人都是子集比 btc 这个 L1 每个人都是全集总会省那么一点硬盘的，虽然我怀疑到底能省多少（因为 UTXO 流转链条越来越长，有向无环图越牵涉到部分的越来越广，可能会近似于全集。这个可节省比例可以通过分析现有 btc 所有的历史 UTXO 有向无环图的情况计算出来）。
另外转账时，首先需要对 tapscript 这棵树协商达成共识，然后才生成链上交易发送出去。双方直接协商 PSBT 需要双方同时在线（直连，或者通过钱包运营商服务器中转）。
[mint 交易](https://mempool.space/zh/testnet/tx/71c5796512f6b5600262d2242911a9b4ce50d5fda5aec224c54adfc67f349d4d)：也就是 genesis tx，asset 铸造在 tb1p0 这个 UTXO 上。
[第一次 send 交易](https://mempool.space/zh/testnet/tx/0c62d6cfce4570ddc55b60b5978f68d0321a8b7d3a55a1aea0ee98abf6f22659)：asset 从 tb1p0 转到 tb1p8，而 tb1gp 是找零。
[第二次 send 交易](https://mempool.space/zh/testnet/tx/8df1f41b0b3e2ee153533fe30e60c824be616608bd13725fe65786df86c9c930)：tp1pg 转到 tb1p5，tb1p009 是找零。
在文件夹 `~/.tapd/data/testnet/proofs/ASSET_ID/` 下保存的是**历史所有** UTXO 的 proof，可以证明每个 UTXO 里面的 P2TR 哈希是怎么算出来的。合约的语义通过已经上链的交易得到了证明。
每个客户端本地存用的 proof 相当于原来一条链所有交易数据的**子集**，因为现在只需关心自己的 UTXO 牵涉到的所有历史，最坏情况也是所有 UTXO 汇聚到一个地址变成了 proof 全集，所以每个人都是子集比 btc 这个 L1 每个人都是全集总会省那么一点硬盘的，虽然我怀疑到底能省多少（因为 UTXO 流转链条越来越长，有向无环图越牵涉到部分的越来越广，可能会近似于全集。这个可节省比例可以通过分析现有 btc 所有的历史 UTXO 有向无环图的情况计算出来）。
另外转账时，首先需要对 tapscript 这棵树协商达成共识，然后才生成链上交易发送出去。双方直接协商 PSBT 需要双方同时在线（直连，或者通过钱包运营商服务器中转）。
quoting nevent1q…ca6j开始看所谓客户端验证是什么范式，于是感觉我可能理解错了如何利用 taproot 交易来减少数据上链的方式：它似乎是用方式一（私钥签名）花掉 taproot UTXO，在链上进行转账，但同时在链下要揭露 tapscript 这棵树等内容作为证据，这些证据不用上链，而是由接收方保管整个证据历史，并且通过一个客户端进行验证每一个证据（跟链上通过方式二脚本路径花掉 taproot UTXO类似地验证方式）。
这样一个 UTXO 语法上是否有效由链上保证，而语义（合约的含义）上是否有效由链下的跟 UTXO 流转过程中产生的一连串证据历史来保证。客户端侧需要验证整个历史
。
那这样每个 UTXO 随着转手次数增长，并且和别的 UTXO 同时花费过，附加在它身上的证据历史不是越来越庞大？它的历史证据跟一条区块链本身类似了。
文档还是太模糊了，打算把环境搭建起来实际跑一下，看它的交易到底是怎么样的。
nevent1q…99gm