感谢社区的支持，以及在不同领域/场景下讨论 zk 的应用，这对于我个人而言激发了我更多的思考
Q3 总结
成果总结和回顾
项目组层面
尽管项目组成员在 ZK 上有了一定的理解力，对于接下来的研究方向有了更加清晰的理解（folding，lookup，commitment costs）但是项目组在第一季度缺乏 Check 机制，没有有效的把控项目进度的管理。
链接了 Starknet 的 Max
Nebra 的调研
公共层面上参加了一次由 LxDAO 举办的圆桌（感谢 Bruce）
链接上了 HyperOrcale 与 Scroll
确保了芯片开发方面的顾问人选以及密码学加速硬件设计方向的实验室的人
semaphore 的研究 zupass
确认了 ZK 不友好操作的原因，但还未进行详细推导
在社区层面上提供了一些 ZK 相关的建议
确认了下一个季度的研究方向（folding，lookup，commitment costs）
相关产出材料
新成员加入
0xhhh 作为顾问加入
Suke 作为顾问加入
成员自评
Harold
已经达成：目前对于 snark stark 清晰的概念理解，正在进行 Plonk 相关的研究
未达成 原第一季度的目标数对于主流协议有深刻的理解，但目前只知道一个整体的框架和流程，但对于内部细节原理还不了解。
Kenway
已经达成：Pinocchio Protocol，Semaphore
未达成：理解业内的进度还没有做
York
zk-stark / zk-SNACK 数学原理/算法原理/考察 综述方面，完成了zksynic/scroll/loopring/ARBEVM+/polygon/starknet/6个zk/zkevm 相关技术社区/项目的调研对原理有一定了解，对优劣势的有理解；
未达成：综述
TODO 从负责人的角度出发，当前暴露的问题
Q4 计划
Q3 目标
要面向硬核的性价比的方案，而非市场主流的比较卷的方案
Q3 提出来的问题
- 产品卖给谁
- EVM 的变动
- EVM 兼容性对开发者和生态的影响识别
- ZKP，在将实际 evm 操作转换为代数电路时，或者说针对任意的代数电路，有多少东西是能够被抽取出来进行加速的？能否被拆解成可以被复用的算子
- 硬件加速的提升 Banchmark
对 Q3 问题的解答
在Q3季度中，项目度对于当前的zkevm赛道的参与者进行了初步的调研，已经经过了线上和线下的接触后，在区块链的语境下，zk 作为 rollup 解决方案是不缺乏建设者及使用者的，基于这个大的前提下，我作为负责人的身份对Q3的问题进行相关的推理及解答
- 针对产品卖给谁这个问题，当前 zk 场景目前不缺少使用者，当前可以把项目进行抽象不去考虑对方实际是中心化还是去中心化的（即产品本身是项目方本身使用，还是项目生态参与者进行使用，这个不重要，当然目前更大的客户还是前者）所以说，产品卖给谁这个问题变成了如何把产品卖给我们的客户，那么从性价比的方面来考虑，除了服务器本身的价格之外，比如 AWS，还有就是能够提供的运维服务以及针对 ZK 场景的定制化体验（Docker with percific library）
- 在思考和对比了不同类型的 ZKEVM 之后，以及当下业内的 ZKVM 项目，例如 Risc-0，HyperOrcale 这种项目之后，项目组达成的后续研发目标不是继续关注于 EVM 及 opcode。而是应该关注于更加根本的事情。ZK 本身是一种对承诺的证明，那么针对 EVM 状态机从状态 A 到状态 B 所做出的 ZKProof，即 prover( Statement = EVM_status_i trans to EVM_status_i_plus_1) 或是说，针对 VM 状态机从状态 A 到状态 B 的转变，即 prover( Statement = VM_status_i trans to VM_status_i_plus_1) 。这两种不同的Proof生成过程对于我们来说是等价的，因为加速硬件本身应该关注的是 Prover 生成 Proof 的效率，而不是他为了什么东西而生成证明，故 EVM 未来的改动对于项目组本身而言的风险是非常低的
- 基于上述的论述，因为我们接下来会更加聚焦于底层的加速，位于上层的 EVM 变动不会再成为障碍，反而因为我们将来会提供更加广泛的加速场景，这会至少会使得 EVM 的演进不会受到一些重型项目的掣肘
- 基于上述的论述，当前应该被抽象的算子优化应该是 Proof 生成（commitment costs）的优化所以，问题4的提问方向有误，应该从更基础的一层来进行拆解算子的这个动作，即不同协议中 Prover 生成 Proof 时，产生大量消耗的性能卡点是什么？且这个问题目前是已经形成部分答案的 即 MSM 和 FFT
- 硬件提升的 Banchmark 目前没有做，但是这个问题应该要在 Q4 以及 2024Q1 中进行解决
Q4 应该解决的问题
ZK 协议本身的进展和迭代是很快的，Plonk，Plookup，HyperPlonk，UniPlonk，Hola2，等等。但归根结底，现在市面上多数的协议都是 Plonk 的变种。那么追本溯源 Q4 应该面对的第一个问题就是
协议 Plonk 及其相关的工程能力是全员至少应该完成的目标
- 激励项 Hola2
- 激励项 Hyperplonk
当完成该问题之后，下一个问题是什么？项目组认为，基于 Plonk 及其他算法识别出来的流程有着重要的意义，在基于 IOP 的抽象框架下，输出 ZK 协议的整体对于我们应该专注于哪些加速点至关重要，那么第二个问题就是：
ZK协议流程进行抽象化之后输出的框架 即 folding，lookup，commitment costs 发生的位置，以及 FFT MSM 在何处被调用
- Lasso Jolt 的 Lookup实现
- 激励项 FFT MSM 的计算过程及相关加速库的研究
其他问题 & 事项
- 对市面上的ZK L2的设施进行深入研究，Polygon，Scroll，Starnet
- Risc-0 的研究 因为其是当下最为领先的 ZKVM
- 与 Nebra 的合作 这个会拆分成另一个提案进行说明 同时也包括了 Plancker 作为投资方应该做到的 Evaluation 责任
工作流程改进
Check 机制
每个月一到两次的进度检查及同步，
工作证明机制 研究的文章，阅读的内容需要有明确的输出和证明，没有输出和证明的工作内容视为无效工作
月薪是否应该与工作证明机制挂钩，或者纳入评判的标准？
每日的进度同步
基于 Q3 目标的展望及演进
在我做调研的过程中，经常冒出来一些莫名其妙的公式/名词/术语，说实话挺怀疑人生的，就像当时学统计学的时候，冒出来的各种分布，各种特性一样令人头晕；后来就是没辙，硬啃，中文英文材料一起上，啃累了就睡觉，睡醒了之后摸摸鱼吃个冻披萨继续。当然除了每天起床之后还是头一样的大之外（可能更大，现在的日子舒服多了。在 Q3 中，产生了很多思考，也感谢 Xhash 的鼎力相助，我们能在北京碰头进行更进一步的讨论。
ZK 当下的热度离不开以太坊及区块链，但 ZK 未来的发展和区块链是并行的。它面向的场景会带来更多的想象力，在经过Q3阶段的调研和感受后，ZK 协议层上的演进，以及基于 ZK 的应用都是在飞速发展的，那么 Plancker 怎么去参与到这个生态中来？符合 Plancker 愿景的目标是什么？
最终的愿景应该是打造 ZK 设计时需要的协议/工具箱；
我个人认为的答案还是提供加速服务。通过给算法中的密集型工作提供加速服务来持续建立通往协议的切实道路。（感谢Link与焦哥提供的思路）
进一步解释
ZK 设计时需要的协议/工具箱：参照 TEE GP 标准，OpenSSL 等的设计，以 Hash 函数举例，设计的 Hash 算法或者是 Hash 的硬件实现上（以底层视角出发），设计 TA 比如文件加密，密钥管理派生的 APP （从应用层视角出发）。围绕着 Hash 的开发都是 基于 Init-Update-Final 模型的，那么如果能够在 ZK 领域中能够建立这样一个类似的模型，比如 对常见的 FFT MSM 操作，及其他的操作都有相应的实现的话，那么未来我们能更加深度的参与到 ZK 的演进中，与此同时，通过这种协议，硬件公司们也能够按照这一层抽象进行开发。所以我认为最终能达成这一协议是能够实现 Plancker 想要建设人来数字未来的愿景的