[RFP Submission] OP Stack Zero Knowledge Proof

• wangtsiao - No Role

  June 9, 2023, 11:53 p.m.
  Magic
  S 4 Intent: Technical Decentralization Proposed Mission: Implement a zkVM (RISCV 64 or MIPS) that adheres Cannon 12 ’s virtual machine architecture. Proposal Tier: Fledgling Baseline grant amount: 250 k OP Alliance Lead: Tsiao Contract Info: Twitter: https://twitter.com/qiaowang 1999 21 Discord: wangtsiao# 0685 Email: wangtsiao@gmail.com L 2 recipient address: 0 x 7 dc 04 FB 18731032 eD 89236961 B 1 a 13 E 3 d 6102 AE 6 Please list the members of your Alliance and link to any previous work: Tsiao - a developer, cryptography enthusiast. He has profound experience in zero knowledge proof (ZKP) technology. Prior to the proposal, he did the following ZKP-related activities. He systematically studied ZKP at university and actively participated in zku-cohort- 3 where he gained exceptional skills in writing circuits. Additionally, he has participated in CTF competitions and achieved several first prizes, showcasing his expertise in computer security. Wenbin - a developer with more than five years of experience blockchain technology, specializing in consensus and layer 2 solutions. Proficiency in permissionless blockchain development, with a deep understanding of multi-signature algorithm, multi-party secure computing, and optimistic Layer 2 solutions. Before applying, he served as the one of core developer for a well-known modular Layer 2 blockchain project. What makes your Alliance best-suited to execute this Mission? We are an alliance with experience in both engineering and theory. We have a strong interest in ZKP. We have well-established mechanism in place to distribute benefits among our alliance members. Each person will receive a financial reward commensurate with his workload, fostering a strong sense of unity among us. What sets up apart from from freelencers is our philosophy that prioritizing product delivery. We consistently meet our planned timelines and firmly believe in the importance of timely project completion. Completing the mission aligns with our goals. There is a high probability that we will continue to maintain the zkVM project even after completing this mission. Please describe your proposed solution based on the above Solution Criteria (if applicable): We have two options and eagerly anticipate further discussions with the OP team to select one of them. Implement a zkMIPS which is nearly equivalent to Cannon 12 ’s virtual machine. Implement a zkRISCV 64 . Considering that Wave Computing announced 4 the cessation of MIPS ISA development in March 2021 and the decreasing number of MIPS devices, we have concerns about the availability of MIPS compilers in future versions of Go. Therefore, we propose the RISCV 64 route. zkMIPS Our solution is implementing a zkMIPS which is nearly equivalent to Cannon’s MIPS virtual machine (VM). The term ‘nearly’ indicates that we will optimize the VM to be zkSNARKs friendly. Our solution support OP’s fault proof. In the near future, we anticipate a smooth transition from Cannon’s MIPS VM to zkMIPS VM with minimal adjustments to the existing code in Cannon’s implementation. We conducted a thorough survey and found serveral zkVMs; however, none of them meet the requirements of OP stack. risc 0 2 : a riscv 32 zkVM, but the riscv 32 ISA is not supported by the golang compiler. It is based on zkSTARK with FRI polynomial commitment, which means it has high verifier cost. zkWASM 1 : a wasm zkVM, supported by the golang compiler, but it lacks the key component for fault proof, such as pre-image and hint, which are descripted in OP’s spec. miden-vm, ola-vm, valida-vm: They are all define their own ISA tailored to gain higher prover performance, non of these ISAs are supported by the golang compiler. pse/zkevm 1 , scroll-zkevm, polygon-zkevm: They are zkEVMs. Compare to OP, they are purely different ways to implement layer 2 . That means they can not be utilized to implement zk fault proof. Besides this, somewhat they all suffer poor proof generation time. Here we bench 4 the zkEVM inside risc 0 and pse/zkEVM on a 16 cores, 128 GB RAM machine, the results show they can not generate proof for ERC 20 transfer within 1 minute. zkVM ISA Proof System / Commit Scheme Proof Size Verifier Cost Support Golang Support Cannon Fault Proof risc 0 RISCV 32 zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: miden-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: ola-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: pse/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: scroll/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: polygon/zkevm EVM zkSTARK / FRI+KZG $O( 1 )$ $O( 1 )$ :x: :x: zkWasm WASM halo 2 / IPA $O(log \ n)$ $O(log \ n)$ :white_check_mark: :x: zkMIPS MIPS halo 2 / KZG → HyperNova / Folding $O( 1 )$ $O( 1 )$ :white_check_mark: :white_check_mark: We denote circuit size as $n$, The above table lists various zkVMs and their corresponding instruction set architecture (ISA), proof system / polynomial commitment scheme, etc. As a latecomer, zkMIPS will be designed to avoid the disadvantages of the above zkVMs, here are our goals. zkMIPS should support mips ISA, produce assertion proof for any golang program. zkMIPS should support the pre-image and hint components in fault proof, which plays a crucial role in Cannon. zkMIPS should have a considerable prover performance. This is achived by utilzing GPU and adopting cut-edge ZKP algorithm. zkMIPS should have a cheap cost for verifying proof. It is important because the verifier is a contract on L 1 , the gas price is expensive. In the short term we will utilize plonkish, custom gates, lookup tables to implement zkMIPS, and we plan to utilze GPU to accelerate the proof generation. Our long term vision is implementing a zkMIPS based on folding, which proposed in Nova 2 , and it enables ~ 50 x prover performance. The zkMIPS should support the following 55 instructions: 'addi', 'addiu', 'addu', 'and', 'andi', 'b', 'beq', 'beqz', 'bgez', 'bgtz', 'blez', 'bltz', 'bne', 'bnez', 'clz', 'divu', 'j', 'jal', 'jalr', 'jr', 'lb', 'lbu', 'lui', 'lw', 'lwr', 'mfhi', 'mflo', 'move', 'movn', 'movz', 'mtlo', 'mul', 'multu', 'negu', 'nop', 'not', 'or', 'ori', 'sb', 'sll', 'sllv', 'slt', 'slti', 'sltiu', 'sltu', 'sra', 'srl', 'srlv', 'subu', 'sw', 'swr', 'sync', 'syscall', 'xor', 'xori' It also should implement Preimage and Hint read and wirte for system call. The keccak 256 in Preimage is the most heavy part for ZKP. Poseidon 1 is an arithmetization-oriented hash function, meaning that it is ZKP friendly, so we plan to use Posidon instead of keccak 256 . zkRISCV 64 I won’t go too much details about zkRISCV 64 , because the difference between zkMIPS is trivial. It use RISCV 64 ISA and also support OP’s fault proof system. But there are some drawbacks to implement zkRISCV 64 , I hope discussing with OP gov and make the decision together. For zkRISCV 64 , we need re-implement Cannon 12 with RISCV 64 , this will increase the development time. For zkRISCV 64 , there are much more instructions and registers to implement, the larger feature intructions set makes audit heavy. This will also increase the development time. Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work: Here is our step-by-step plan. Write a specification for the VM, including each component’s corresponding ZKP circuit. It should be clear and easy to implement. Implement the zkVM following the specification, we plan to write ZKP circuit based on halo 2 proof system with KZG 2 commitment scheme. Unit testing for each VM instruction, then integration testing of several go language programs, just like cannon did. Enable provers to utilize GPU to accelerate generating proofs. Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal: We will give a clear specification for the zkVM before Aug 4 th AOE. We will implemented the memory and stack proof before Aug 25 th AOE. We will implemented the instructions set before Sep 15 th AOE. We will done integration testing for the zkVM before Sep 29 th AOE. Please list any additional support your team would require to execute this mission (financial, technical, etc.): Ideally, we can start the building without supporting, but an well-performing server after building (i.e., at test stage) would help. Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: Ideally, we can start the building without but the small financial grant would help. Please check the following to make sure you understand the terms of the Optimism Foundation RFP program: I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual 1 I confirm that I have read and understand the grant policies I understand that I will be expected to following the public grant reporting requirements outlined here

  The post outlines a proposal by an alliance led by Tsiao to implement a zkVM (RISC-V 64 or MIPS) following Cannon 10's virtual machine architecture, aiming for technical decentralization. The alliance members Tsiao and Wenbin are detailed, presenting their expertise in ZKP and blockchain technology. The proposal considers the advantages and disadvantages of zkMIPS and zkRISC-V 64, highlighting the goal of supporting fault-proof systems. The plan includes steps for specifications, implementation, testing, and deadlines for different phases. Support is requested for server access and possible upfront cash grants. The alliance expresses willingness to adhere to the terms and policies of the Optimism Foundation RFP program.
  Likes: 7 Replies: 0
  Likers: lee0007, raho, jengajojo, maintainer.eth, MinimalGravitas, grapebaba, Luckyhooman.eth
  No replies yet.
• wangtsiao - No Role

  June 9, 2023, 11:53 p.m.
  S 4 Intent: Technical Decentralization Proposed Mission: Implement a zkVM (RISCV 64 or MIPS) … S 4 Intent: Technical Decentralization Proposed Mission: Implement a zkVM (RISCV 64 or MIPS) that adheres Cannon’s virtual machine architecture. Proposal Tier: Fledgling Baseline grant amount: 250 k OP Alliance Lead: Tsiao Contract Info: Twitter: https://twitter.com/qiaowang 1999 Discord: wangtsiao# 0685 Email: wangtsiao@gmail.com L 2 recipient address: 0 x 7 dc 04 FB 18731032 eD 89236961 B 1 a 13 E 3 d 6102 AE 6 Please list the members of your Alliance and link to any previous work: Tsiao - a developer, cryptography enthusiast. He has profound experience in zero knowledge proof (ZKP) technology. Prior to the proposal, he did the following ZKP-related activities. He systematically studied ZKP at university and actively participated in zku-cohort- 3 where he gained exceptional skills in writing circuits. Additionally, he has participated in CTF competitions and achieved several first prizes, showcasing his expertise in computer security. Wenbin - a developer with more than five years of experience blockchain technology, specializing in consensus and layer 2 solutions. Proficiency in permissionless blockchain development, with a deep understanding of multi-signature algorithm, multi-party secure computing, and optimistic Layer 2 solutions. Before applying, he served as the one of core developer for a well-known modular Layer 2 blockchain project. What makes your Alliance best-suited to execute this Mission? We are an alliance with experience in both engineering and theory. We have a strong interest in ZKP. We have well-established mechanism in place to distribute benefits among our alliance members. Each person will receive a financial reward commensurate with his workload, fostering a strong sense of unity among us. What sets up apart from from freelencers is our philosophy that prioritizing product delivery. We consistently meet our planned timelines and firmly believe in the importance of timely project completion. Completing the mission aligns with our goals. There is a high probability that we will continue to maintain the zkVM project even after completing this mission. Please describe your proposed solution based on the above Solution Criteria (if applicable): We have two options and eagerly anticipate further discussions with the OP team to select one of them. Implement a zkMIPS which is nearly equivalent to Cannon’s virtual machine. Implement a zkRISCV 64 . Considering that Wave Computing announced the cessation of MIPS ISA development in March 2021 and the decreasing number of MIPS devices, we have concerns about the availability of MIPS compilers in future versions of Go. Therefore, we propose the RISCV 64 route. zkMIPS Our solution is implementing a zkMIPS which is nearly equivalent to Cannon’s MIPS virtual machine (VM). The term ‘nearly’ indicates that we will optimize the VM to be zkSNARKs friendly. Our solution support OP’s fault proof. In the near future, we anticipate a smooth transition from Cannon’s MIPS VM to zkMIPS VM with minimal adjustments to the existing code in Cannon’s implementation. We conducted a thorough survey and found serveral zkVMs; however, none of them meet the requirements of OP stack. risc 0 : a riscv 32 zkVM, but the riscv 32 ISA is not supported by the golang compiler. It is based on zkSTARK with FRI polynomial commitment, which means it has high verifier cost. zkWASM: a wasm zkVM, supported by the golang compiler, but it lacks the key component for fault proof, such as pre-image and hint, which are descripted in OP’s spec. miden-vm, ola-vm, valida-vm: They are all define their own ISA tailored to gain higher prover performance, non of these ISAs are supported by the golang compiler. pse/zkevm, scroll-zkevm, polygon-zkevm: They are zkEVMs. Compare to OP, they are purely different ways to implement layer 2 . That means they can not be utilized to implement zk fault proof. Besides this, somewhat they all suffer poor proof generation time. Here we bench the zkEVM inside risc 0 and pse/zkEVM on a 16 cores, 128 GB RAM machine, the results show they can not generate proof for ERC 20 transfer within 1 minute. zkVM ISA Proof System / Commit Scheme Proof Size Verifier Cost Support Golang Support Cannon Fault Proof risc 0 RISCV 32 zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: miden-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: ola-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: pse/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: scroll/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: polygon/zkevm EVM zkSTARK / FRI+KZG $O( 1 )$ $O( 1 )$ :x: :x: zkWasm WASM halo 2 / IPA $O(log \ n)$ $O(log \ n)$ :white_check_mark: :x: zkMIPS MIPS halo 2 / KZG → HyperNova / Folding $O( 1 )$ $O( 1 )$ :white_check_mark: :white_check_mark: We denote circuit size as $n$, The above table lists various zkVMs and their corresponding instruction set architecture (ISA), proof system / polynomial commitment scheme, etc. As a latecomer, zkMIPS will be designed to avoid the disadvantages of the above zkVMs, here are our goals. zkMIPS should support mips ISA, produce assertion proof for any golang program. zkMIPS should support the pre-image and hint components in fault proof, which plays a crucial role in Cannon. zkMIPS should have a considerable prover performance. This is achived by utilzing GPU and adopting cut-edge ZKP algorithm. zkMIPS should have a cheap cost for verifying proof. It is important because the verifier is a contract on L 1 , the gas price is expensive. In the short term we will utilize plonkish, custom gates, lookup tables to implement zkMIPS, and we plan to utilze GPU to accelerate the proof generation. Our long term vision is implementing a zkMIPS based on folding, which proposed in Nova, and it enables ~ 50 x prover performance. The zkMIPS should support the following 55 instructions: 'addi', 'addiu', 'addu', 'and', 'andi', 'b', 'beq', 'beqz', 'bgez', 'bgtz', 'blez', 'bltz', 'bne', 'bnez', 'clz', 'divu', 'j', 'jal', 'jalr', 'jr', 'lb', 'lbu', 'lui', 'lw', 'lwr', 'mfhi', 'mflo', 'move', 'movn', 'movz', 'mtlo', 'mul', 'multu', 'negu', 'nop', 'not', 'or', 'ori', 'sb', 'sll', 'sllv', 'slt', 'slti', 'sltiu', 'sltu', 'sra', 'srl', 'srlv', 'subu', 'sw', 'swr', 'sync', 'syscall', 'xor', 'xori' It also should implement Preimage and Hint read and wirte for system call. The keccak 256 in Preimage is the most heavy part for ZKP. Poseidon is an arithmetization-oriented hash function, meaning that it is ZKP friendly, so we plan to use Posidon instead of keccak 256 . zkRISCV 64 I won’t go too much details about zkRISCV 64 , because the difference between zkMIPS is trivial. It use RISCV 64 ISA and also support OP’s fault proof system. But there are some drawbacks to implement zkRISCV 64 , I hope discussing with OP gov and make the decision together. For zkRISCV 64 , we need re-implement Cannon with RISCV 64 , this will increase the development time. For zkRISCV 64 , there are much more instructions and registers to implement, the larger feature intructions set makes audit heavy. This will also increase the development time. Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work: Here is our step-by-step plan. Write a specification for the VM, including each component’s corresponding ZKP circuit. It should be clear and easy to implement. Implement the zkVM following the specification, we plan to write ZKP circuit based on halo 2 proof system with KZG commitment scheme. Unit testing for each VM instruction, then integration testing of several go language programs, just like cannon did. Enable provers to utilize GPU to accelerate generating proofs. Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal: We will give a clear specification for the zkVM before Aug 4 th AOE. We will implemented the memory and stack proof before Aug 25 th AOE. We will implemented the instructions set before Sep 15 th AOE. We will done integration testing for the zkVM before Sep 29 th AOE. Please list any additional support your team would require to execute this mission (financial, technical, etc.): Ideally, we can start the building without supporting, but an well-performing server after building (i.e., at test stage) would help. Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: Ideally, we can start the building without but the small financial grant would help. Please check the following to make sure you understand the terms of the Optimism Foundation RFP program: I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual I confirm that I have read and understand the grant policies I understand that I will be expected to following the public grant reporting requirements outlined here
  Likes: 7 Replies: 0

  View More
  Likers: lee0007, raho, jengajojo, maintainer.eth, MinimalGravitas, grapebaba, Luckyhooman.eth
  No replies yet.
• wangtsiao - No Role

  June 10, 2023, 3:53 a.m.
  S 4 Intent: Technical Decentralization Proposed Mission: Implement a zkVM (RISCV 64 or MIPS) … S 4 Intent: Technical Decentralization Proposed Mission: Implement a zkVM (RISCV 64 or MIPS) that adheres Cannon 10 ’s virtual machine architecture. Proposal Tier: Fledgling Baseline grant amount: 250 k OP Alliance Lead: Tsiao Contract Info: Twitter: https://twitter.com/qiaowang 1999 20 Discord: wangtsiao# 0685 Email: wangtsiao@gmail.com L 2 recipient address: 0 x 7 dc 04 FB 18731032 eD 89236961 B 1 a 13 E 3 d 6102 AE 6 Please list the members of your Alliance and link to any previous work: Tsiao - a developer, cryptography enthusiast. He has profound experience in zero knowledge proof (ZKP) technology. Prior to the proposal, he did the following ZKP-related activities. He systematically studied ZKP at university and actively participated in zku-cohort- 3 where he gained exceptional skills in writing circuits. Additionally, he has participated in CTF competitions and achieved several first prizes, showcasing his expertise in computer security. Wenbin - a developer with more than five years of experience blockchain technology, specializing in consensus and layer 2 solutions. Proficiency in permissionless blockchain development, with a deep understanding of multi-signature algorithm, multi-party secure computing, and optimistic Layer 2 solutions. Before applying, he served as the one of core developer for a well-known modular Layer 2 blockchain project. What makes your Alliance best-suited to execute this Mission? We are an alliance with experience in both engineering and theory. We have a strong interest in ZKP. We have well-established mechanism in place to distribute benefits among our alliance members. Each person will receive a financial reward commensurate with his workload, fostering a strong sense of unity among us. What sets up apart from from freelencers is our philosophy that prioritizing product delivery. We consistently meet our planned timelines and firmly believe in the importance of timely project completion. Completing the mission aligns with our goals. There is a high probability that we will continue to maintain the zkVM project even after completing this mission. Please describe your proposed solution based on the above Solution Criteria (if applicable): We have two options and eagerly anticipate further discussions with the OP team to select one of them. Implement a zkMIPS which is nearly equivalent to Cannon 10 ’s virtual machine. Implement a zkRISCV 64 . Considering that Wave Computing announced 4 the cessation of MIPS ISA development in March 2021 and the decreasing number of MIPS devices, we have concerns about the availability of MIPS compilers in future versions of Go. Therefore, we propose the RISCV 64 route. zkMIPS Our solution is implementing a zkMIPS which is nearly equivalent to Cannon’s MIPS virtual machine (VM). The term ‘nearly’ indicates that we will optimize the VM to be zkSNARKs friendly. Our solution support OP’s fault proof. In the near future, we anticipate a smooth transition from Cannon’s MIPS VM to zkMIPS VM with minimal adjustments to the existing code in Cannon’s implementation. We conducted a thorough survey and found serveral zkVMs; however, none of them meet the requirements of OP stack. risc 0 2 : a riscv 32 zkVM, but the riscv 32 ISA is not supported by the golang compiler. It is based on zkSTARK with FRI polynomial commitment, which means it has high verifier cost. zkWASM 1 : a wasm zkVM, supported by the golang compiler, but it lacks the key component for fault proof, such as pre-image and hint, which are descripted in OP’s spec. miden-vm, ola-vm, valida-vm: They are all define their own ISA tailored to gain higher prover performance, non of these ISAs are supported by the golang compiler. pse/zkevm 1 , scroll-zkevm, polygon-zkevm: They are zkEVMs. Compare to OP, they are purely different ways to implement layer 2 . That means they can not be utilized to implement zk fault proof. Besides this, somewhat they all suffer poor proof generation time. Here we bench 4 the zkEVM inside risc 0 and pse/zkEVM on a 16 cores, 128 GB RAM machine, the results show they can not generate proof for ERC 20 transfer within 1 minute. zkVM ISA Proof System / Commit Scheme Proof Size Verifier Cost Support Golang Support Cannon Fault Proof risc 0 RISCV 32 zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: miden-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: ola-vm Custom zkSTARK / FRI $O(log^ 2 \ n)$ $O(log^ 2 \ n)$ :x: :x: pse/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: scroll/zkevm EVM halo 2 / KZG $O( 1 )$ $O( 1 )$ :x: :x: polygon/zkevm EVM zkSTARK / FRI+KZG $O( 1 )$ $O( 1 )$ :x: :x: zkWasm WASM halo 2 / IPA $O(log \ n)$ $O(log \ n)$ :white_check_mark: :x: zkMIPS MIPS halo 2 / KZG → HyperNova / Folding $O( 1 )$ $O( 1 )$ :white_check_mark: :white_check_mark: We denote circuit size as $n$, The above table lists various zkVMs and their corresponding instruction set architecture (ISA), proof system / polynomial commitment scheme, etc. As a latecomer, zkMIPS will be designed to avoid the disadvantages of the above zkVMs, here are our goals. zkMIPS should support mips ISA, produce assertion proof for any golang program. zkMIPS should support the pre-image and hint components in fault proof, which plays a crucial role in Cannon. zkMIPS should have a considerable prover performance. This is achived by utilzing GPU and adopting cut-edge ZKP algorithm. zkMIPS should have a cheap cost for verifying proof. It is important because the verifier is a contract on L 1 , the gas price is expensive. In the short term we will utilize plonkish, custom gates, lookup tables to implement zkMIPS, and we plan to utilze GPU to accelerate the proof generation. Our long term vision is implementing a zkMIPS based on folding, which proposed in Nova 2 , and it enables ~ 50 x prover performance. The zkMIPS should support the following 55 instructions: 'addi', 'addiu', 'addu', 'and', 'andi', 'b', 'beq', 'beqz', 'bgez', 'bgtz', 'blez', 'bltz', 'bne', 'bnez', 'clz', 'divu', 'j', 'jal', 'jalr', 'jr', 'lb', 'lbu', 'lui', 'lw', 'lwr', 'mfhi', 'mflo', 'move', 'movn', 'movz', 'mtlo', 'mul', 'multu', 'negu', 'nop', 'not', 'or', 'ori', 'sb', 'sll', 'sllv', 'slt', 'slti', 'sltiu', 'sltu', 'sra', 'srl', 'srlv', 'subu', 'sw', 'swr', 'sync', 'syscall', 'xor', 'xori' It also should implement Preimage and Hint read and wirte for system call. The keccak 256 in Preimage is the most heavy part for ZKP. Poseidon 1 is an arithmetization-oriented hash function, meaning that it is ZKP friendly, so we plan to use Posidon instead of keccak 256 . zkRISCV 64 I won’t go too much details about zkRISCV 64 , because the difference between zkMIPS is trivial. It use RISCV 64 ISA and also support OP’s fault proof system. But there are some drawbacks to implement zkRISCV 64 , I hope discussing with OP gov and make the decision together. For zkRISCV 64 , we need re-implement Cannon 10 with RISCV 64 , this will increase the development time. For zkRISCV 64 , there are much more instructions and registers to implement, the larger feature intructions set makes audit heavy. This will also increase the development time. Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work: Here is our step-by-step plan. Write a specification for the VM, including each component’s corresponding ZKP circuit. It should be clear and easy to implement. Implement the zkVM following the specification, we plan to write ZKP circuit based on halo 2 proof system with KZG 2 commitment scheme. Unit testing for each VM instruction, then integration testing of several go language programs, just like cannon did. Enable provers to utilize GPU to accelerate generating proofs. Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal: We will give a clear specification for the zkVM before Aug 4 th AOE. We will implemented the memory and stack proof before Aug 25 th AOE. We will implemented the instructions set before Sep 15 th AOE. We will done integration testing for the zkVM before Sep 29 th AOE. Please list any additional support your team would require to execute this mission (financial, technical, etc.): Ideally, we can start the building without supporting, but an well-performing server after building (i.e., at test stage) would help. Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: Ideally, we can start the building without but the small financial grant would help. Please check the following to make sure you understand the terms of the Optimism Foundation RFP program: I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual 1 I confirm that I have read and understand the grant policies I understand that I will be expected to following the public grant reporting requirements outlined here
  Likes: 7 Replies: 0

  View More
  Likers: lee0007, raho, jengajojo, maintainer.eth, minimalgravitas, grapebaba, butterbum
  No replies yet.
• lavande - This user is a moderator

  June 12, 2023, 5:38 p.m.
  Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP) 4… Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP) 44 . You don’t need to post your application to Foundation Mission (RFPs) to the forum, you just need to reply with this information directly on the github issue (bobby has already linked this proposal there but making sure the process is clear for others reading this.)
  Likes: 1 Replies: 0

  View More
  Likers: wangtsiao
  No replies yet.
• lavande - This user is a moderator

  June 12, 2023, 5:38 p.m.
  Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP). Y… Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP). You don’t need to post your application to Foundation Mission (RFPs) to the forum, you just need to reply with this information directly on the github issue (bobby has already linked this proposal there but making sure the process is clear for others reading this.)
  Likes: 1 Replies: 0

  View More
  Likers: wangtsiao
  No replies yet.
• lavande - This user is a moderator

  June 12, 2023, 9:38 p.m.
  Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP) 4… Exciting to see this proposal! I believe this is an application to this Foundation Mission (RFP) 40 . You don’t need to post your application to Foundation Mission (RFPs) to the forum, you just need to reply with this information directly on the github issue (bobby has already linked this proposal there but making sure the process is clear for others reading this.)
  Likes: 1 Replies: 0

  View More
  Likers: wangtsiao
  No replies yet.