fluencelabs/lazy-snark
1
0
Fork 0
mirror of https://github.com/fluencelabs/lazy-snark synced 2025-04-25 06:52:14 +00:00
Code Issues Projects Releases Wiki Activity

readme indentation fixed more

Browse Source
This commit is contained in:
Ivan Ivanitskiy 2019-06-23 10:19:15 +03:00
parent 03dc55dd6e
commit daaa54f136
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@ -10,14 +10,15 @@ We suggest checking proofs on Fluence instead. This option does not has gas prob
The process includes the following entities: 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. - 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. - 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. - Fluence back end 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. - 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: Here is the workflow:
1. The operator uploads (data, proof) to the smart contract. 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. 2. The user takes (data, proof) from the smart contract and uploads it to the back end (Fluence).
3. The Fluence instance checkes the proof. 3. The back end 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. 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 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. 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. To better understand the workflow, please review the scheme.