How does ZK work?
Let’s say you want to make a sequence of transactions on rhino.fi. For example you may want to swap Bitcoin for Matic using our cross-chain feature. Then you want to buy some USDT and finally sell some Avax.
A normal ‘proving engine’ (usually a smart contract) would have to prove each of these transactions separately and post an individual record on the main Ethereum blockchain to demonstrate your updated balance, and thus your ability to make the next trade. That not only takes time, it drains your funds because you need to pay gas fees each time the blockchain updates itself.
However, with StarkWare’s ZK technology, we can batch all these transactions together, prove them off-chain, and then provide a single proof of all the activity to the layer 1 Ethereum blockchain. Ethereum performs some quick calculations, and then updates the chain.
So the amount of work we have to do on the congested layer 1, and thus the amount of gas we have to pay, is kept to a minimum.
Of course, this places a considerable burden on the technology itself. On-chain computation provides transparency and proven security, so our off-chain engine needs to be able to deliver the correct results, no matter the pressure it is subjected to.
Not only that, but one of the main USPs of ZK technology is that it can validate a trade or swap without requiring any actual information about the transaction itself. In other words, it doesn’t need to reveal the individual transaction details, or any details about the people making them. This makes the technology extremely private, but it also requires some complex engineering at the back end.
So ZK leaders like StarkWare have created an engine with two separate parts:
- A prover, which goes through all the transactions, performs rigorous computation to ensure they’re correct, and generates a proof – essentially, a stamp of approval which confirms that all the transactions happened in the right order, and according to the rules of the blockchain.
- A verifier, an on-chain contract which checks the proof and commits a state change (updates the blockchain with the user’s new balance) if the proof is valid.
And here’s the critical bit: When checking the proofs, the verifier challenges the prover to complete a series of complex calculations, using information that it could not possess unless it had done the correct computation when generating the proofs in the first place.
A good way to think of this is like a maze, which offers a reward for anyone who follows the correct route. A series of doors have been placed along this route, with a number above it.
Upon completion of the route, the challenger (or the prover) has to provide all the numbers to the maze-master in the correct sequence. By doing so, they prove that they have followed the correct path without revealing any essential details, so their disclosure is useless to anyone who may be listening in.
It would, theoretically, be possible for the prover to ‘guess’ the correct information, so to minimise this risk, the verifier sets a large number of challenges – so large, in fact, that the chances of inaccuracy are miniscule.
When the engine submits a proof and the on-chain verifier recognises it as valid, there’s no need to then repeat the full calculations on layer 1. Simply by verifying the proof, Ethereum knows we’ve followed the right steps.
The StarkWare verifier is open source and is deployed to the main Ethereum chain, therefore its correctness can be confirmed by any interested third parties.
