From 87d64aeb95397753a8e98a227510c5e0d24f189d Mon Sep 17 00:00:00 2001 From: Ivan Ivanitskiy Date: Sat, 22 Jun 2019 23:06:30 +0300 Subject: [PATCH 1/4] readme started --- README.md | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 45090c9..4b644b0 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,24 @@ -# lazy-snark -off-chain computation of zk-snark proofs +# LAZY SNARK +### trustless off-chain zk-proof verification +##Abstract +In Ethereum, it is expensive to check zk-proofs on-chain, so we propose to use Fluence to do heavy-lifting off-chain and only go on-chain to challenge incorrect data/proof combination. +##Why +Let us say, we need to verify zk-proofs in Ethereum smart contract. The problem is that zk-proof verification is a heavy computational task and thus costs a lot of gas. As a result, checking proofs on-chain is not only expensive, but also takes a lot of space in the block. This may lead to serious problems, e.g. in case of mass exit. +##What +We suggest checking proofs on Fluence instead. This option does not has gas problem, is much cheaper, but is also trustless. +...................................................... +##How it works +The process includes the following entities: +-Ethereum smart contract that stores (data, proof) pairs and implements on-chain proof verification. In case the proof is not correct, the smart contract rewards the user who checked this proof with ether. +-Operator who uploads (data, proof) pairs to the smart contract. +-Fluence instance that also implements proof verification, but off-chain. It also stores all the check results. +-Fisherman aka the user of our system. The fisherman wants to find false proofs to check them in a smart contract and get a reward. + +Here is the workflow: +1. The operator uploads (data, proof) to the smart contract. +2. The fisherman takes (data, proof) from the smart contract and uploads it to the Fluence instance. +3. The Fluence instance checkes the proof. +4. a) If the proof is correct, it is stored by the Fluence instance with TRUE flag. Other fishermen can see it an will not check this proof again. + b) If the proof is false, the fisherman checks the same proof in the smart contract. In that case the fisherman is sure that the proof is FALSE and thus the fisherman will get the reward. + +To better understand the workflow, please review the scheme. From 03dc55dd6efde6ebf8722111bfc9d5129f973cc5 Mon Sep 17 00:00:00 2001 From: Ivan Ivanitskiy Date: Sat, 22 Jun 2019 23:11:40 +0300 Subject: [PATCH 2/4] readme indentation fixed --- README.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 4b644b0..d31b715 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,17 @@ -# LAZY SNARK -### trustless off-chain zk-proof verification -##Abstract +# LAZY SNARK: trustless off-chain zk-proof verification. +## Abstract In Ethereum, it is expensive to check zk-proofs on-chain, so we propose to use Fluence to do heavy-lifting off-chain and only go on-chain to challenge incorrect data/proof combination. -##Why +## Why Let us say, we need to verify zk-proofs in Ethereum smart contract. The problem is that zk-proof verification is a heavy computational task and thus costs a lot of gas. As a result, checking proofs on-chain is not only expensive, but also takes a lot of space in the block. This may lead to serious problems, e.g. in case of mass exit. -##What -We suggest checking proofs on Fluence instead. This option does not has gas problem, is much cheaper, but is also trustless. -...................................................... -##How it works +## What +We suggest checking proofs on Fluence instead. This option does not has gas problem, is much cheaper, but is also trustless. + +## How it works The process includes the following entities: --Ethereum smart contract that stores (data, proof) pairs and implements on-chain proof verification. In case the proof is not correct, the smart contract rewards the user who checked this proof with ether. --Operator who uploads (data, proof) pairs to the smart contract. --Fluence instance that also implements proof verification, but off-chain. It also stores all the check results. --Fisherman aka the user of our system. The fisherman wants to find false proofs to check them in a smart contract and get a reward. +- Ethereum smart contract that stores (data, proof) pairs and implements on-chain proof verification. In case the proof is not correct, the smart contract rewards the user who checked this proof with ether. +- Operator who uploads (data, proof) pairs to the smart contract. +- Fluence instance that also implements proof verification, but off-chain. It also stores all the check results. +- Fisherman aka the user of our system. The fisherman wants to find false proofs to check them in a smart contract and get a reward. Here is the workflow: 1. The operator uploads (data, proof) to the smart contract. From c377a1d8498e2c5caeed8702c55fef5171f74f59 Mon Sep 17 00:00:00 2001 From: Evgeny Marchenko Date: Sun, 23 Jun 2019 09:54:34 +0300 Subject: [PATCH 3/4] ... --- truffle/contracts/VerifierProxy.sol | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/truffle/contracts/VerifierProxy.sol b/truffle/contracts/VerifierProxy.sol index 62477bb..1de53ff 100644 --- a/truffle/contracts/VerifierProxy.sol +++ b/truffle/contracts/VerifierProxy.sol @@ -1,11 +1,11 @@ pragma solidity ^0.5.4; pragma experimental ABIEncoderV2; -import "./Structs.sol"; +import "./IVerifier.sol"; import "./Verifier.sol"; -contract VerifierProxy is Structs { +contract VerifierProxy is IVerifier { Verifier internal verifier; constructor(Verifier ver) public { From daaa54f136b048b52d9ee34b8be6de03094f2406 Mon Sep 17 00:00:00 2001 From: Ivan Ivanitskiy Date: Sun, 23 Jun 2019 10:19:15 +0300 Subject: [PATCH 4/4] readme indentation fixed more --- README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index d31b715..2af1c1c 100644 --- a/README.md +++ b/README.md @@ -10,14 +10,15 @@ We suggest checking proofs on Fluence instead. This option does not has gas prob The process includes the following entities: - Ethereum smart contract that stores (data, proof) pairs and implements on-chain proof verification. In case the proof is not correct, the smart contract rewards the user who checked this proof with ether. - Operator who uploads (data, proof) pairs to the smart contract. -- Fluence instance that also implements proof verification, but off-chain. It also stores all the check results. -- Fisherman aka the user of our system. The fisherman wants to find false proofs to check them in a smart contract and get a reward. +- Fluence back end that also implements proof verification, but off-chain. It also stores all the check results. +- Arweave front-end. The user performs all the actions via the front.end. +- The user of our system. The user wants to find false proofs to check them in a smart contract and get a reward. Here is the workflow: 1. The operator uploads (data, proof) to the smart contract. -2. The fisherman takes (data, proof) from the smart contract and uploads it to the Fluence instance. -3. The Fluence instance checkes the proof. -4. a) If the proof is correct, it is stored by the Fluence instance with TRUE flag. Other fishermen can see it an will not check this proof again. - b) If the proof is false, the fisherman checks the same proof in the smart contract. In that case the fisherman is sure that the proof is FALSE and thus the fisherman will get the reward. +2. The user takes (data, proof) from the smart contract and uploads it to the back end (Fluence). +3. The back end checkes the proof. +4. a) If the proof is correct, it is stored by the back end with TRUE flag. Other users can see it an will not check this proof again. + b) If the proof is false, the user checks the same proof in the smart contract. In that case the user is sure that the proof is FALSE and thus the user will get the reward. To better understand the workflow, please review the scheme.