Merge pull request #5 from smartkek/ivan/readme

readme indentation fixed
This commit is contained in:
Ivan Ivanitskiy 2019-06-22 23:12:55 +03:00 committed by GitHub
commit 09eaafcd4f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.