# From Offchian to Client Side-区块链的扩容极限

对区块链系统来说，扩容是一个永恒的话题，数轮牛熊转换，每一轮都有新项目以更高的性能为卖点而大放异彩，尽管很多是以牺牲抗审查能力，抗单点故障与去中心化做到的，但可以看出，区块链用户对于性能的渴求。

设计一个富状态的单体高性能区块链系统，似乎难以避免地会走向偏中心化的排序与极高配置的节点，那么一个支付专用的区块链系统，在不妥协去中心化的前提下，极限TPS可以做到多少呢？考虑到Payfi，稳定币转账仍然是区块链占比极大的一块业务，所以对这个议题进行探索依然是意义重大的。

更何况，到了AI Agent时代，Agent之间的资产流动的需求可能是真人的数万倍，限制AI的只有算力和网速，而碳基的人则受限于各种生理与物理极限，如果要满足Agent之间对资产流动的性能要求，当前的转账系统还需要更快。

首先需要分析的是，对于支付专用的区块链系统，瓶颈在哪？交易执行，网络通信，状态爆炸？要知道，对于简单的转账，目前大部分普通的机器都能处理非常高的TPS，所以我认为最主要的问题的网络通信与状态大小：

+ 网络通信问题的关键在于，减少每笔交易占据全网DA同步的字节数。
+ 状态问题的关键在于，减少用户信息对链上空间的占用，所以我们需要无状态区块链，或者Client side state。

接下来，我将探讨市面上已有的一些方案，并针对支付专用的区块链系统的设计给出一些想法。

## Hermez 1.0

Hermez 1.0 是一个支付专用的zkRollup系统，虽然这个系统本身早已停运，Hermez团队也已被Polygon收购去进行zkEVM的开发了，但通过了解Hermez，可以看到zkRollup在处理这个问题上的极限能力。

通常的一笔ETH转账交易至少需要109字节，如果转移的是稳定币，则需要的更多，而Hermez 1.0，一笔交易只需要14字节，由于使用了zk，signature本身可以在zk proof中得到验证而无需占用DA，这就节省了65字节。


假设区块最大为1MB，出块时间为12s，那么吞吐量为 87381 Byte/s，由于Hermez的交易大小为 14字节，那么理论上的极限值为 6241 TPS，当然我们还需要考虑zk证明的时间，以及各种可能的延迟，根据Hermez的论述，在测试网上达到的极限值的 2000 TPS。

由于这个方案本身的简洁性，我们可以认为支付专用的zkRollup的极限性能，大概就是几千到一万TPS左右，而这应该也就是非Client-Side系统，同时保证一定去中心化程度的极限TPS。

## RGB与Taproot Assets

当我们把目光转向BTC生态，RGB作为Client-Size Validation的鼻祖，为我们开启了新的视野，即让更多的工作在客户端进行，从而尽可能减少链上痕迹。

RGB最核心的思想为：Client-Size Validation以及Single-Use seal，即将一个链下状态去链上UTXO绑定，由于UTXO花费的唯一性，从而实现抗双花，而客户端在接收RGB资产时，需要独自验证所收到资产的整个历史链条的有效性，由此，RGB保证了交易序列的抗双花与有效性。

Taproot Assets是另一个CSV资产协议，其利用Taproot的Taptree做了一些改造，使其更适合资产发行与转移，但是基本原理依然是CSV与Single-Use Seal。

相比铭文和符文，RGB具有更小的链上足迹，同时也具有更好的隐私性，除了涉及到的交易方，其他人在链上无法看到UTXO与链下状态的关联性，但是当发生转账时，交易接收方将可以看到整个交易链条所有的交易历史。

但是这类资产存在一个问题，即任何一笔交易都要与一笔真正的链上交易一一对应，从而使得它们只能用在BTC上，为BTC增加发行新资产的能力，而无法起到扩容的作用，唯一做到的是在表示复杂状态时，不用占用过多链上空间。

但是当我们把目光看向更远处，就会发现CSV其实已经开启了一个扩容的新方向，这将在论述后面的方案时提到。

## Shielded CSV

[ShieldedCSV/ShieldedCSV](https://github.com/ShieldedCSV/ShieldedCSV/releases/tag/2024-09-20)

Shielded CSV在RGB的基础上进一步扩展了隐私性，不仅交易无关方在链上看不到转账链条，哪怕交易接收方也无法看到交易链条之前发生过的交易，其使用了递归零知识证明，使得接收方通过验证zk证明，就能验证一整个交易链条的有效性，和其他的zk隐私方案一样，Shielded CSV也存在一个不断累积的Nullifier状态，所有的节点需要监听全网以获得Nullifier，避免接收到无效交易。

由于此方案需要每个节点实时监听BTC网络，从而缺乏一定的实用性，但是我们可以从中学到的是，通过递归零知识证明，CSV协议将可以无需验证整个交易链条来保证有效性了，而仅需验证一个递归证明，RGB当前正在探索这个方向（[STARKy RGB: making RGB compatible with zk-STARKs · RGB-WG · Discussion #265](https://github.com/orgs/RGB-WG/discussions/265)）。

## Payment Channel

支付通道可以说是最早的Layer2方案，闪电网络也一直被认为是BTC扩容的希望，但闪电网络的落地却一直推进缓慢。

Payment Channel的机制为，交易双方可以共同存储资金到一个多签地址，并在一定时间内双方的交易都仅由双方处理，而不涉及任何链上交易，并且通过一些博弈机制，使得任何交易都可以即时确认，从而实现了交易的时间维度的压缩，并且通过HTLC和PTLC等机制，Channel可以实现多跳，即A-B存在channel，B-C存在Channel，那么即使A和C没有直接通道连接，也可以通过B作为中继，实现资产交易。

某种意义上，我觉得支付通道是非常适合作为AI Agent之间的资金流动方式的，因为它延迟极低，并且处理速度只取决于网速以及机器本地的执行速度。

但由于当前支付通过还存在很多问题，所以推进并没有很好，以闪电网络为例，现有的闪电网络最核心的问题有以下一些:

+ inbound 流动性问题，即当双方建立通道时，建立通道时防止的流动性决定了最大可接收资产的数量，假设A和B建立了一个通道，A放0.01BTC进去，B放0.005BTC进去，那么A最多只能收到B的0.005BTC，反之亦然。
+ 资金效率问题，一个新加入闪电网络的节点，很可能是不具备任何入账流动性的，因为入账流动性需要其他方锁定资产进来，如果缺乏激励，很难找到有节点会自愿提供新节点的入账流动性。
+ rebalance问题，现实世界的资金流动，总是不平衡的，有些节点往往只收款，有些节点往往只发送资金，到最后网络就不平衡了，需要有方法使得网络的资金分布重新归于平衡。

上面的问题，当前都需要一笔链上交易才能，入账流动性不够可以通过一笔新的链上交易存钱进来，rebalance大部分时候也需要通过链上交易来使得交易平衡，一笔链上交易就需要数百KB的链上DA，从而使得闪电网络的使用体验和成本，并没有声称的那么高。

要解决这个问题，一方面可以通过经济激励来做，这是UTXOStack当前在推进的工作，通过质押，使得一部分人的闲置资金可以为闪电网络提供流动性，从而赚取费用。

另一方面，支付通道还可以进一步和其他压缩方案结合，从而极大减少通道调整与平衡的成本。

## IntMax2

IntMax2是一个很有意思的项目，因为它结合了非常多前述方案的技术，比如 Client-Size State，递归零知识证明，zkRollup。用户将在本地维护一个余额集以及余额有效性的证明，在发送时，用户使用自己的余额以及有效性证明构建转账，接收方收到以后将使用相关证明更新自己的余额。


IntMax2理论上可以获得很高的TPS，但是有一个很影响体验的点是，一次转账涉及到太多的多轮交互，包括发送方与Block Builder的多轮交互，发送方与接收方的交互，这些问题将影响IntMax2的实用性。

## Polygon Miden

相比IntMax2，Polygon Miden是一个更全面的zkRollup，其综合了Client-Side Proving，混合UTXO和Account Model的异构状态模型，还考虑了状态爆炸问题，同时保持其交易的隐私性。

在Polygon Miden中，存在两类状态表达：Account，Note，其中Account具有调用接口，类似EVM的合约账户，而Note具有脚本，类似UTXO，Polygon Miden的交易模式是，一笔交易中，Account会消费一些Notes，同时创建另一些Notes，Account之间的通信将只能通过Note来传递，所以这是一种异步通信，类似Actor Model。

在 Polygon Miden 的状态中，存在三颗树，Account，Notes，Nullifier。

Account树使用SMT，维持当前存在的账户索引，对于Onchain Account，其所有的状态数据都会被zkRollup的状态存储，以便公开共享给整个网络执行，此外还存在offchain Account，链上只存在一个Account Hash，其具体的内容将全部由客户端存储，也就是说，无论一个账户持有多少资产，其真正占用的链上状态空间永远只有一个Hash。

Notes树使用Merkle Mountain Range，存储了所有被创建过的Notes。

Nullifier使用SMT，存储了所有被消耗了的Notes，Nullifier的设计几乎可以在所有基于UTXO的隐私区块链中看到。

通过这种异构状态模型，Polygon Miden可以让需要隐私和低成本的用户，只使用Offchain Account，用户可以使用Offchain Account创建一个Note，该Note表示给另一个Account转账，另一个Account消费这个Note，增加自己Account中某一类资产的余额。

在这个过程中，发送方的账户内容，接收方的账户内容，以及Note的内容，对整个zkRollup都是不公开的，zkRollup只能看到Account Tree中某个Account的Hash发送了变化，Notes Tree中又增加了一项。


由于整个执行都被递归零知识证明所压缩，那么它的链上足迹也是足够小的。

由此，Polygon Miden实现了通过递归零知识证明使得链上足迹小，通过客户端状态存储减少链上状态。

## Client-Side zkRollup for Channel

经过上面的分析，我们可以看到递归zkRollup可以实现交易空间维度的压缩，从而均摊掉每笔交易的链上DA占用，而Channel可以实现交易在时间维度的压缩，可以让交易在一段时间内复用同一个链上DA占用。

那么，假如结合zkRollup和Channel，实现一个 Client-Side zkRollup for Channel，那么是不是就可以同时在空间和时间维度对交易进行压缩，从而实现极致的扩容呢？

在此，我对这样的区块链系统架构进行一个脑洞，首先它是一个基于UTXO模型的Rollup，并且具有以下特征：

+ 用户自己持有的所有UTXO，都将使用SMT进行压缩，链上只有每个用户UTXO Tree的RootHash，而每个用户需要自己保管好自己的UTXO Set，当然此处使用Account Tree是相同的效果，即树里面记录了用户所有资产的信息。
+ 用户可以发起一笔交易，从UTXO Tree中构建出一个游离UTXO。
+ 游离UTXO的脚本具有一定的编程能力，或者转为支付通道设计的电路，则两个用户可以使用各自的游离UTXO构建通道的Funding Tx，并进行闪电网络操作。
+ 当需要注资时，用户发起交易生成一个新的游离UTXO，并使用另一笔交易进行注资，由于递归证明的压缩，只要这两笔交易在同一个batch中，这个游离UTXO作为中间过程就不会占用任何链上DA。
+ 当需要取款时，多签控制的UTXO将拆分成多个游离UTXO，然后用户将游离UTXO携带的资产并入自己的UTXO Tree。
+ 仅考虑支付时，无需考虑极致的隐私性，所以不设计Nullifier Tree。

通过这样的设计，可以实现以最小链上DA占用，实现最大的TPS，真正需要占用DA的仅有通道的创建，注资，退出。而由于支付通道即时确认的穿透性，即使中间隔了一层，支付通道依然可以像直接对接一层一样，可以即时确认。当然，上述设计也可以作为一个一层区块链而存在，类似Mina。

而用户的UTXO Set，用户构建的交易，在链上都是不存储的，链上只能看到某些Account的Account Hash在变化，一个游离UTXO被创建然后又被消费，换而言之，链上只能看到StateDiff，并且在同一个区块内部的State Diff也是被压缩的。