南阳做网站公司电话,263网站建设怎么样,网站在线优化检测,wordpress修正用户注册页面1. 引言
本文重点讨论Polygon Miden所设计的UTXO账户混合状态模型#xff0c;以实现某些有趣的属性。
Miden的目标是#xff1a;【即越具有隐私性#xff0c;其可扩展性越好】
构建可扩展去中心化的rollup采用支持隐私的架构
Miden支持灵活的交易模式#xff1a;
公开…1. 引言
本文重点讨论Polygon Miden所设计的UTXO账户混合状态模型以实现某些有趣的属性。
Miden的目标是【即越具有隐私性其可扩展性越好】
构建可扩展去中心化的rollup采用支持隐私的架构
Miden支持灵活的交易模式
公开交易无状态交易私人交易本地交易
2. 何为去中心化zkRollup
常规zkRollup方案是
L2用户将L2交易提交给operators由 operators将L2交易打包为区块由operators生成对应区块状态转换的ZK proof并将该ZK proof提交给L1 去中心化zkRollup方案的
安全性继承自L1独立于L1的L2链可有其自己的共识机制可有permissionless的operators集合
构建去中心化rollup的挑战有
1共识机制2execution bloat执行膨胀3state bloat状态膨胀
本文重点关注执行膨胀和状态膨胀。 所谓执行膨胀是指网络需执行所有交易 产块者需执行某区块内的所有交易网络中的其它节点也需要重新执行该区块内的所有交易 所谓状态膨胀是指状态大小随时间增长 节点需要全量状态来验证区块。节点需要全量状态来生成新的区块。
3. Miden解决方案UTXO账户混合状态模型
执行膨胀和状态膨胀会带来如下问题
1中心化问题需要强大如大磁盘大内存等的机器来运行节点。2缺少隐私性问题网络中的每个人可看到链上发生的每笔交易细节。Everyone sees everything每个人都需要重新执行所有交易并维护全量状态。3不可持续性问题not sustainable永远增长的状态。其增长速度超过了单个硬件机器配置的增长速度。
为此希望所构建的解决方案能
1使执行膨胀最小化即 所有交易包括网络交易仅执行一次【ZKP可实现】可由不同的网络参与者并行执行交易【要求并发状态模型】本地执行对不影响 具有共享状态账户 的交易其可在本地执行并在本地证明 2使状态膨胀最小化即 轻量验证节点验证节点可丢弃绝大多数状态即nullifier DB无需维护全量状态即可验证区块【ZKP可实现】动态裁剪产块者可独立决定维护哪些状态即无需维护全量状态即可生成新的区块【要求并发状态模型】由吞吐量驱动状态大小状态大小主要依赖于当前TPS而不是账户总数也不是notes总数。 当前的区块链状态模型主要有2大类
1基于账户的状态模型其具有如下特征 适于表达智能合约不太适于并行交易执行不利于匿名 2基于UTXO的状态模型其具有如下特征 不太适于表达智能合约适于并行交易执行各个UTXO是相互独立的。适于实现匿名
Miden借助 账户模型 UTXO模型 ZK proofs来实现
Actor-based model with concurrent off-chain state即具备链下并行状态的、基于actor的模型。
3. Miden的交易模型actor-based model with concurrent off-chain state
常规的actor模型是指
actors为具有“inboxes”的状态机actors之间通过消息传递来通信消息的生成和消费是异步的
对应到Miden中的actor模型为
账户维护了 状态 对外暴露的Miden VM程序接口消息以notes来表示notes中携带了 资产 花费该资产的“spend script”为Miden VM程序不同于以太坊中仅需要1笔交易来实现资产转移。由于消息的生成和消费是异步的即意味着当在2个账户之间转移资产时需要2笔交易。 1笔交易用于创建note。另1笔交易用于消费该note。
3.1 Miden中的交易解析
与以太坊中的交易不同Miden中的交易
总是仅包含一个账户其无法关联更多账户消费0个或多个notes通过执行某note的“spend script”来消费该note生成0个或多个notes Miden交易执行的流程为 通过执行note1的script来消费note1note1的script会调用账户的接口函数如receive()函数来接收资产从而使得note1可将其资产传给账户的函数可修改该账户的状态并创建新的notes。重复以上流程来消费note2。note scripts会依次顺序执行。
3.2 Miden中交易的证明
由于Miden中的交易仅关联单个账户因此看立即为交易生成ZK proofMiden中采用STARK证明系统Winterfell
交易的正确执行可在单个STARK proof中证明所有交易的STARK proofs可并行生成
3.3 Miden中区块的证明 基本流程为
对区块内的一堆tx proofs进行递归聚合来获得batch proof然后再对batch proof进行递归聚合来获得block proof最后对block进行递归聚合来生成最终提交给L1的validity proof如称为Epoch proof
需注意的是
以上递归聚合流程可并行进行以上tx proofs可并行生成以上batch proofs可并行生成以上block proofs不可并行生成 还有一个很有趣的点在于
tx proofs可在用户本地生成batch proofs、block proofs、Epoch proofs需在网络中生成如由产块者生成。
3.4 Miden中的本地交易和网络交易
传统的交易执行流程为
prepare为交易准备输入execute执行该交易prove为该交易生成证明 其中网络交易中由网络如产块者来执行交易并为该交易生成证明。本地交易中由用户在本地准备交易输入、执行该交易、为该交易生成证明。而 产块者不需要执行该交易也不需要为该交易生成证明。产块者仅需要聚合该交易proof。
本地交易和网络交易这2种交易模式的对比情况为
3.5 Miden中共享状态处理逻辑
以Uniswap为具有共享状态的账户为例有多个账户与其交互需对共享状态进行处理
2个用户独立执行交易tx1和交易tx2分别创建了note1和note2。这2笔交易的目标都是uniswap account。产块者创建交易tx3并执行交易tx3。交易tx3会消费note1和note2然后输出note3和note4。note3和note4分别 以 其note1和note2的原始account为目标。 然后这2个用户独立执行交易tx4和交易tx5来分别消费note3和note4。
即
与具有共享状态账户 进行交互的交易其必须为网络交易而不能是本地交易。
4. Miden中的状态模型
Miden rollup中的状态主要分为3大类
1account DB存储所有账户的当前状态。以Spare Merkle tree作为数据存储结构来将account IDs 映射到 account Hashes。不过Miden提供了2种不同的存储账户到数据库的方式 1.1on-chain state链上状态对于具有链上状态的账户节点会存储该账户的整个状态。与以太坊的账户存储模式相同。1.2off-chain state链下状态对于具有链下状态的账户节点仅存储该账户的哈希值。 由用户自己来负责存储其账户的实际状态。 2notes DB存储了目前为止所创建的所有notes。采用Merkle Mountain RangeMMR数据结构来存储为append-only accumulator。其叶子节点为某区块内所创建的一组notes。 选择Merkle Mountain RangeMMR数据结构的原因在于 即使丢弃了大多数节点notes也可添加到MMR。inclusion witness永远不会不新鲜但其可能需要扩展。 3nullifier DB用于跟踪所有已消费的notes。采用Sparse Merkle tree作为数据结构来存储用于映射note hash 到 0/1。其中1表示已消费0表示未消费。nullifiers被组织成epochs如4到6个月。实际有稍微更成熟的数据结构即每个epoch共用一棵树然后又创建新的树给下一epoch使用。节点仅需要维护最近2个epochs的nullifiers。
由区块 n n n引起的状态变更示意为 Miden状态增长驱动因素为
1account DB 增长主要来源为具有链上状态的账户数 的增加增长次要来源为账户总数 的增加裁剪策略为忽略链上账户数据但保留这些账户的哈希值 2notes DB 增长主要来源为未消费的public notes的数量 的增加增长次要来源为未消费的notes数量 的增加裁剪策略为忽略链上note数据 3nullifier DB 增长主要来源为吞吐量TPS 的增加增长次要来源为nullifier epoch长度 的增加裁剪策略为无
参考资料
[1] 2022年10月在哥伦比亚波哥大举行的DevCon 6中Polygon Miden联合创始人Bobbin Threadbare分享的视频Using a Hybrid UTXO and Account-based State Model in a ZK Rollup by Bobbin Threadbare
Miden系列博客
zk、zkVM、zkEVM及其未来Polygon L2扩容方案揭秘混合Rollup探秘 Metis、Fraxchain、Aztec、Miden和OlaPolygon Miden扩展以太坊功能集的ZK-optimized rollup
