SmartDec team won Decentralized Web Hackathon in Minsk, Belarus, on June 22, 2019. The hackathon was sponsored by Fluence and Arweave companies and implied using their technologies. We managed to unite both tools as well as Ethereum smart contracts in one system without violating common sense. Also, we closely discussed our project with the Fluence team. I will share what we came up with concerning both our project and desired Fluence features.

Fluence and Arweave

Fluence provides “a permissionless distributed cloud for databases and web applications.” Arweave enables you to “permanently host your web apps and pages, simply and quickly.’’ We used these technologies for the back end and the front end of our system, respectively. Here, I have very briefly described the mentioned systems. For the detailed descriptions, please, see their websites (Fluence, Arweave).

Project description

In Ethereum, it is expensive to check zero-knowledge proofs on-chain. So, we propose to use Fluence to do heavy-lifting off-chain and only go on-chain to challenge incorrect proofs. Our project should help existing Ethereum projects that rely on zk-proofs save money and gas in the block while maintaining trustlessness.

Why

Let’s say, there is a project that needs to verify zk-proofs in Ethereum smart contract. The problem is that on-chain zk-proof verification is a heavy computational task and thus costs a lot of gas. As a result, checking proofs on-chain is expensive, and may stall in case of network congestion.

What

We suggest checking proofs on Fluence instead. This option does not have the gas problem. Thus, it is much cheaper. Also, it won’t affect the Ethereum network so much since it doesn’t require a lot of gas. Besides, it is trustless (Fluence level guarantees) and the results of the checks are public.

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 challenges the invalid proof with ether.

Proof supplier who uploads (data, proof) pairs to the smart contract. The proof supplier stakes ether to the smart contract. In case the proof supplier provides an invalid proof, his or her stake is slashed: a part of the stake is given to the one who challenged the proof as a reward.

Fluence back end that implements off-chain proof verification. It also stores proof verification results.

Ethereum project user aka proof consumer. The user checks whether the proof supplier has provided is valid and challenges invalid ones using smart contract to get a reward.

Arweave front end. The user performs all the actions via the front end. Also, proof verification results from the Fluence back end are displayed in the front end.

Here is the workflow:

The proof supplier uploads (data, proof) to the smart contract. The user takes (data, proof) from the smart contract and sends it to the Fluence back end. The back end checks the proof. The following actions depend on the result of the check:

a. If the proof is valid, it is stored by the back end with TRUE flag. Other users can see it in the front end and will not check this proof again.

b. If the proof is invalid, it is stored by the back end with a FALSE flag. The user challenges this 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 below.

Benefits

LAZY SNARK (not to be confused with Lady Stark) provides the following benefits compared to checking zk-proofs on-chain:

It doesn’t require much gas. One zk-proofs verification in Ethereum will take 10% of gas in the block. LAZY SNARK won’t.

It is ~10 times cheaper than verifying zk-proofs in Ethereum smart contract. Checking zk-proof on-chain costs ~$1 (gasprice and ETH price on June 23, 2019). Checking them in Fluence costs ~$0.01. Since we still need to put data and proofs on-chain, the whole system operation will cost 10 times less than checking the proofs on-chain.

LAZY SNARK provides the following benefits compared to checking zk-proofs locally:

Verifying proofs with Fluence is nearly as good as checking them on-chain. All the proof check results are available on Fluence via Arweave front end.

The results are public, so everyone will be able to see which proofs are valid and which proof suppliers are honest.

The results are public, so the users who seek for invalid proofs won’t check the proofs that have already been checked.

Use cases

LAZY SNARK can be used in the following cases (and not only in these):

Plasma implementations that require zk-proofs. The proof supplier, in this case, will also act as a user (proof supplier). The proof supplier will send the proofs to the Fluence back end to prove to the community that the proof supplier is honest.

Mixers. People deposit ether to the smart contract from one address and withdraw it using another address. They provide zk-proof that it is their ether without revealing their identity. Other users check that all the money has been withdrawn by their owners.

Private money like ZkDai. They utilize zk-proofs to provide privacy.

Games.

Many other systems that use zk-proofs. For now, they are mostly limited to money-like systems, hence the examples above. However, it is only a matter of imagination what other use cases need zk-proofs’ scalability, and trustlessness.

Further improvements

After the hackathon, we closely worked together with the Fluence team to improve the project and think of desired Fluence features.

We considered the viability of such a project in real life. We concluded that the current design has one conceptual flaw. The user has to initiate the proof check in Fluence via the front end manually or using a script. Thus, the hypothetic Plasma user needs to be online and interact with the front end to get Fluence level guarantees. However, the user could check the proofs locally instead and get even more solid guarantees — on his or her own. The need to trust the Fluence network vanishes. Besides, local check is the cheapest option.

We discussed this with the Fluence team and came up with the following architecture. Plasma operator (e.g. proof supplier) should live inside the Fluence network and be punished by Fluence validators in case of cheating. Thus we get Plasma with Fluence guarantees and without the need to work in the front end or run scripts.

Unsolved problems

However, there are still a bunch of unsolved problems:

Providing a trustless channel between Fluence and Ethereum

Foreseeing all the possible cheats, both from operator and user sides

Implementing an operator as a Fluence application

We continue working together with the Fluence team on improving the idea and the implementation.

Thanks

We are very grateful to the Fluence, Arweave, and Cyber Academy teams for organizing Decentralized Web Hackathon. It was a great experience and pleasure to be a part of this event. Also, we thank all the mentors that helped us and the Fluence team for the close and productive further work. Besides, I thank my colleagues Evgeny Marchenko, Alexander Drygin, and Igor Sobolev for joining and winning this hackathon with me. Guys, you’re great!

Left to right: Ivan Ivanitskiy, Igor Sobolev, Alexander Drygin, Evgeny Marchenko.