Boundless订单完整生命周期

Kaito Launchpad近日上新了Boundless，作者因此对Boundless展开了技术研究

一个order在boundless的完整执行流程：

上传zkVM ELF(user)->提交order(user->market)->锁定订单(prover->market)->计算多个单证明任务(prover)->聚合orders(prover)->提交订单(prover->market->merkle tree)->用户调用(CA -> verify router -> verify)

_

聚合orders的状态由两个ZKvm维护，分别是set_builder&Assessor。
set_builder负责储存多个proofs的claim状态，Assessor负责证明订单完整性。需要注意的是，最后生成的Groth16证明用到的是set_builder的数据，这与下文的verify流程有关

需要证明一个order共需要三个数据，分别是claim,seal,journal。Boundless通过event的方式将claim,seal,journal储存在链记录中，claim还被压缩在Groth16证明内，用户调用合约时提供seal和journal，结合Groth16内的claim完成证明

—————
set_builder ZK疑似没对单个proof进行完整验证，也就是说存在一种可能，我们可以构造一个合法但非order指定的ZK证明，声明这个证明指向的是order要求的ELF，在这个证明中可以任意输出journal。

我相信boundless团队不会犯下如此低级的错误，上述原因大概率是我自己没找到约束这一点的函数，等有空了我自己再找找吧