polygon zkEVM有关问题探究
- Duanraudon
- 更新于 2023-03-22 10:11
- 阅读 1519
polygon zkEVM有关问题探究
1.生成证明是在那个地方生成的证明，
是在一个叫做zkProver的地方生成的证明。
2.证明里面的数据是什么？
一个proof的例子（可以把这块的数据理解为对明文加密后的密文）：
0x1d9aa57f0075a235cb1c137ee2265b50653daf796facfa4483bc5ebbfdb2206d0f7e1ab0e269831bd3eefecc577e6f0ba3eb108b84c5a7f0cee15f077560f64422b53fe58b77666016d713a2f43ead6b39757a24dede1404962fc6571d03caae0a5ecc84a35a934bd66db2f98baa6b02a29ee37b49b9e4598cfba91ece69f16f2d1151e8fe0e389452d21f10cf1669d6ed08ecd87cbf708ea33d3423057c6e5c09e8b422e2756226b71af57d565a496b95078a6c1e896617ab70332b5889f3411df1f622a68dc0bd44da5062d5185421623252e6ce8e93907f8094c0de6b6d332b90fc943ccc481ef230d48659b743d1ec0f465dd285e461e25d0a5f9c497cf82aa094557ec1c772107c647aee46c4c8475333ec368943f763ac884a26e9283111e8f5c6a8d674f9da428103423a2e1130fb82e0e9c2cb67ac8b67d392b21b9a1beab9bf87862e47f20c543f2ac0180b43df0911a9ee6358220a5e5a756168c30543f1f0240ae1ad76e25d842cdd75f30516c4b42613e09197a70e54861f15911b1b963dafb90356d0191468171efdcbb16b0f406df739df5f212ade11c265fd12235420949227e03ebd2f22981a58b35cd0f337d69f43f751f495b6a04a1d13070f733b6ee7c9e42e3e0a335f6e0ce59de7e6f055240d266c7ed0574ad826022f24e8842a371360bdfb01e4637849c158dbeeaa7ea5184005595668a877bda72592ad5ea4ac8e54aa00ba7ff54eef1bc22b499dc42224ef3583a75e3ec6cf1b2d486e1df52bc240a698a315f8307d3bd4b06bb3e615f15b89ac32329d7e4f1029f71353b25f59eecf3507433f35a3d5e3ea88cbb199bb304c9fb77764b36872031c9a2e6aeb591a8b126545dbf5818db82f32a9df555d33680d9ff1eefee87926af8c7c3aaf766f1ee9b1fad4309984fec8ad1fc6d593b7ecda8a8d1569028e23567fcc6866c53cbffdb198f3761eb44705808eaa6791ce68201bcf9655678f1950435c5ce6d6a1de537de5edada66a363249e0c82f3a2441dae6f58386121f11fbc9233c4d32e5ad37e86059a95f6ba6ee7768eb922d4f0b739fe894bc892b
3.证明是由什么数据生成来的？
3.1.polygon 官方zkProver数据生成流转图
为了简单起见，我们可以认为zkProver是由以下四个部分组成的。
- The Executor or the Main State Machine Executor
- STARK递归组件
- CIRCOM库
- zk-SNARK验证器
3.1.1.The Executor
The Executor处理 zkEVM 的执行。 这是使用由 Polygon zkEVM 团队专门开发的新的零知识汇编语言（或 zkASM）解释 EVM 字节码的地方。
它需要交易、新旧状态、Sequencer 的 ChainID等等作为输入。 还需要；
- PIL，它是多项式列表，寄存器列表
- ROM，存储与执行相关的指令列表
执行器设置每批有效交易必须满足的多项式约束。 团队专门开发的另一种语言称为多项式恒等式语言（或 PIL），用于对所有多项式约束进行编码。Executor 在 PIL 硬件之上执行所有指令并生成提交的多项式； 这是状态机周期，或所有状态的列表。 它还生成一些公共数据，这些数据构成了 zk-SNARK 验证器输入的一部分。
3.1.2.STARK 递归组件
一旦主状态机执行器将交易和相关数据转换为已提交的多项式，STARK 递归组件将采用以下输入；
-
承诺的多项式
-
常数多项式
-
脚本，它是指令列表
采取这些是为了生成 zk-STARK 证明。 为了促进快速 zk-STARK 证明，STARK 递归组件使用快速 Reed-Solomon Interactive Oracle Proofs of Proximity (RS-IOPP)，也称为 FRI，用于每个 zk-proof。 该组件被称为 STARK 递归，因为；
→ 它实际上产生了几个 zk-STARK 证明， → 将它们整理成几个 zk-STARK 证明的捆绑包， → 并为每个捆绑包生成进一步的 zk-STARK 证明， → 捆绑的最终 zk-STARK 证明也仅用一个 zk-STARK 证明进行整理和证明。
这样，数百个 zk-STARK 证明只用一个 zk-STARK 证明来表示和证明。
3.1.3.CIRCOM Library
STARK 递归组件生成的单个 zk-STARK 证明是 CIRCOM 组件的输入。 CIRCOM 是 zkProver 中使用的电路库，用于为 STARK 递归组件生成的 zk-STARK 证明生成见证。最初的 CIRCOM 论文将其描述为定义算术电路的电路编程语言和生成的编译器。
- 包含一组关联的 Rank-1 约束系统 (R1CS) 约束的文件
- 以及一个程序（用 C++ 或 WebAssembly 编写）有效地计算对算术电路所有连线的有效分配
算术电路主要用作标准模型，用于研究涉及多项式的计算的复杂性。 CIRCOM 组件使用来自 STARK 递归组件的 zk-STARK 证据和验证者数据作为输入来生成witness。 实际上，这个 witness 是一个 Arithmetic circuit，根据其 R1CS 限制声明。
3.1.4.zk-SNARK 证明者
zkProver 的最后一个组件是 zk-SNARK Prover，特别是 Rapid SNARK。 Rapid SNARK 是一个 zk-SNARK 证明生成器，用 C++ 和 Intel Assembly 编写，可以非常快速地生成 CIRCOM 输出的证明。 关于 zkProver，Rapid SNARK 将作为输入
- 来自 CIRCOM 的证人
- STARK 验证者数据，它规定了 Rapid SNARK 必须如何处理数据，然后生成 zk-SNARK 证明。
polygon zkEVM zkProver 数据生成简述：zkProver | Components Of zkProver
3.2.polygon较详细数据生成展示和流转图
L2 Transcation:
{
"from": "0x617b3a3528F9cDd6630fd3301B9c8911F7Bf063D",
"to": "0x4d5Cf5032B2a844602278b01199ED191A86c93ff",
"nonce": 0,
"value": "3000000000000000000",
"gasLimit": 100000,
"gasPrice": "1000000000",
"chainId": 1000
}| batch: | # | Name | Type | Data |
|---|---|---|---|---|
| 2 | batches.transactions | bytes | （太长省略） | |
| 2 | batches.globalExitRoot | bytes32 | 0x183cee25db7a15c68e30ca03c91b96b65a6e563ebb913bde6126aad1594302a5 | |
| 2 | batches.timestamp | uint64 | 1678073112 | |
| 2 | batches.minForcedTimestamp | uint64 | 0 |
executor input:
{
"oldStateRoot": "0x3ca39a7b5b419d1c50c89a8d15d1234f6cbc8baadb465efb609832bbc19f9026",
"newStateRoot": "0x892742ae37044a99aeae16d98e54d788b8114aaa073c46b685bcc3e21e6b5921",
"oldAccInputHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"newAccInputHash": "0x21db0483a0ff157e55b26413da95a77328e68de50f0314e9148277272002051b",
"newLocalExitRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"oldNumBatch": 0,
"newNumBatch": 1,
"chainID": 1000,
"batchL2Data": "0xee80843b9aca00830186a0944d5cf5032b2a844602278b01199ed191a86c93ff8829a2241af62c0000808203e8808030b042c001e60b5e93c5d20786896d6ee49161492162f0f2a06fbaa4e74e94d779539c219adbb6bacf96dd0d10a44b1e30cade645363216f77b7938c2437ed391c",
"globalExitRoot": "0x090bcaf734c4f06c93954a827b45a6e8c67b8e0fd1e0a35a1c5982d6961828f9",
"timestamp": 1944498031,
"sequencerAddr": "0x617b3a3528F9cDd6630fd3301B9c8911F7Bf063D",
"batchHashData": "0xd66c1d128f14f032913ef2f21a06ec02ff389fc47c5b80f0acfb1262e80eadd7",
"contractsBytecode": {},
"db": {
"0x3ca39a7b5b419d1c50c89a8d15d1234f6cbc8baadb465efb609832bbc19f9026": [
"cddc57c0d0fdd4ed",
"d24df1950f2d8f15",
"4c2f3e938869b82d",
"649e63bfe1247ba4",
"b69b044f5e694795",
"f57d81efba5d4445",
"339438195426ad0a",
"3efad1dd58c2259d",
"0000000000000001",
"0000000000000000",
"0000000000000000",
"0000000000000000"
],
"0x3efad1dd58c2259d339438195426ad0af57d81efba5d4445b69b044f5e694795": [
"00000000dea00000",
"0000000035c9adc5",
"0000000000000036",
"0000000000000000",
"0000000000000000",
"0000000000000000",
"0000000000000000",
"0000000000000000"
]
}
}4.在哪个环节进行的验证？
聚合器收集数据，将其发送给zkProver接收其输出，最后将信息发送给POE智能合约以验证来自证明者的有效性证明是否正确。
5.证明验证又是如何验证的？
5.1链下调用代码
zkEVM-Node聚合器部分代码（etherman/etherman.go）：
tx, err := etherMan.PoE.VerifyBatchesTrustedAggregator(
&opts,
pendStateNum,
lastVerifiedBatch,
newVerifiedBatch,
newLocalExitRoot,
newStateRoot,
proof,
)5.1链上验证方法
zkevm-contracts部分方法（contracts/PolygonZkEVM.sol）：
位置定位：
verifyBatchesTrustedAggregator ---> _verifyAndRewardBatches ---> rollupVerifier.verifyProof ---> verifyProof(contracts/verifiers/FflonkVerifier.sol)
6.证明生成和验证成功后，后面又做了什么业务流程处理?
在证明生成和验证成功后，后续的业务流程处理包括智能合约的状态更新以及相应的事件触发等。具体来说，智能合约的状态更新会被写入到侧链的状态数据库中，同时会触发一系列的事件，如日志记录、通知等，以便应用程序进行后续的业务逻辑处理。
