“In Ignis verification of transactions by users is replaced by the following approach: operator(s) proposing blocks must submit a SNARK proving that the new block is correct, which is verified automatically by the smart contract. No incorrect block can ever be included by an operator, so users do not need to always be online and constantly monitor transaction activity.
Unfortunately, data availability remains an open challenge which does not seem possible to solve without trade-offs. Ignis follows the onchain data approach proposed by Vitalik Buterin. A small piece of data (9 bytes in our case) from every transaction is posted to EVM, in order to guarantee that everybody can reconstruct the Merkle state.”
In far more simple terms, you send funds to a smart contract which keeps accounts of transactions through the use of snarks as we’ll detail later. We naturally had a test-run to see how it works. It starts with a deposit on the Rinkeby Testnet:
Now the dapp tells us we have 0.01 testnet eth. We try to send a tenth of it to the testing address, but nothing happens. It may have been due to the Brave Browser, so we drop the shield. We’re also told to try adding a 0 where it says Nonce. It works.
We have to make eight such transactions because they’re sort of bundled into blocks. Then our 0.01 eth shows as just 0.003 eth. Someone else presumably made a transaction in the meantime because we only made seven. At that point, it said pending for a few seconds and then showed the following screen:
It all works and fairly smoothly. Our work here done so we want our remaining eth back. We tried a partial exit, but that’s apparently under the hood so we had to wait for 7 more transactions (totaling 8 with the partial exit). We try instead a full exit and get this:
All of it fairly simple on the surface. No difference from an end-users’ perspective between this and an on-chain transaction.
On-chain, in fact, they’ll have to pay a fee and then wait a bit, as we did for two transactions: depositing and withdrawing. There are fees here too, but far lower. Just as there is some waiting of one eth block for full verification.
We spoke to Alex Gluchowski, a developer at the Ethereum Foundation (EF), to get a far better understanding of how all this works.
How long does it take for something to happen?
Alex Gluchowski: Current block size is 8, so there must be 8 transactions from you or anybody else for transfers to work. Once the block of 8 is full, the block will be committed and you’ll see pending change in the balance.
So I made 8 transactions to the test address, where do I see them?
Alex Gluchowski: We don’t have a block explorer yet, unfortunately, but if you register another account and send some ETH there, you will see its balance increase.
I apologize for the current user experience. This demo is mainly to demonstrate that SNARKs are fully functional. In production environment obviously things will be completely automated and smoother.
So basically this is condensing 8 transactions into one onchain transaction?
Yes, in production it will be up to 1600 transactions.
So you’d have to wait for 1600 tx before the screen does anything? Or is that just a User Interface (UI) thing?
That’s a UI thing, it can be padded. Users will wait very limited time. The whole system makes most sense under high load, otherwise you could simply use normal ETH transactions.
Wouldn’t it be a lot cheaper here? It costs 9 bytes per transaction. Each eth transaction is 28 bytes? Here it’s 1,000 gas per transaction. Eth transactions are usually 28,000 gas.
Block verification costs 600k gas at the moment. So it becomes cheaper if you have at least 40 transactions in a block.
How many txs can a block handle?
1600, optimizations on the way to push it up. Also with some tricks we can reduce verification costs.
So that’s 375 gas per tx?
Correct, plus the onchain part ( slightly over 600).
If I understand this at a high level, you’re basically depositing funds to the smart contract, and then the smart contract keeps account of txs through zk snarks?
You don’t have to be online or anything?
Not at all. The Ethereum Virtual Machine (EVM) takes care of the verification, operator(s) can not cheat.
And then obviously these can be private transactions? So how is this different from Aztec’s use of ZKSnarks?
This might be possible in the future, but not now, since the transaction data is posted onchain. Privacy would make transaction cost much higher. Take a look at the gas costs of AZTEC transactions under that link.
How would this be affected by storage rent and/or pruning?
Not at all, we take minimal use of storage, O(1). Constant amount of variables in the contract, regardless of the load or number of accounts.
The eth is in the smart contract, so it could be hacked and drained? Are you using any sort of, don’t want to call it backdoor but fail-safe mechanism lets say? That would lead to: have you had or are you planning any audits and then when do you hope this might launch on mainnet?
Very good questions. Obviously everything will be open-sourced and meticulously audited before going into production.
As with any smart contract, there is a risk of a bug which can be exploited. In our case, the contracts are the less risky part though, because they are relatively small.
The more difficult part is the SNARK circuits. Besides, we will have to conduct a Trusted Setup ceremony (similar to the Powers of Tau in zcash). This is a tricky part and we will write separately about it.
I can not comment on the launch on mainnet yet. All I can say is that we don’t have any big uncertainties now, it’s a matter of Engineering.
What’s the difficult part in the SNARK circuits?
The circuits themselves must be thoroughly audited by highly competent cryptographers. If you want to better understand SNARKs, take a look at Vitalik’s blog post series, they are brilliant.
Not sure if you saw the AMD news yesterday. I think it was Justin Drake that suggested specialized snarks hardware would add efficiency. Would that apply here?
Yes, exactly. This hardware is capable to push the cost per transaction waaaaaaay down. And to make the latency lower.
In regards to the trusted set-up, I thought that was relevant just for privacy?
Unfortunately no. Trusted Setup is the ugly part here. It is required to make SNARKs work in general
So you can mess with eth ownership if it’s not set-up correctly? I think you need just one key to be destroyed though?
If ALL AND EVERY of the trusted setup participants collude together, they could fake any proof and steal ETH. If at least one party is honest, everything is fine.
So there’s a big ceremony with, let’s say, Buterin, Consensys, AMD, etc. etc., then it would become very trustworthy for me. So this is an open question yet.
I see you’re from EF, so I guess this project was supported by an EF grant? Or is it actually being developed inhouse at the foundation?
It’s supported equally by EF and Matter Inc.
They seem to be a start-up focused solely on this. VC backed do you know or grants?
Petr Korolev: Hi. I’m CEO of Matter Inc. We are bootstrapping Plasma from our own funds now. We work close with Ethereum Foundation. We are hoping to continue developing with grant support.
The final question, how exactly is this Plasma?
Alex Gluchowski: It’s Plasma in the following sense: it’s a scaling solution, in which sidechain blocks are cryptographically committed to the mainchain. Thus sidechain operators can not arbitrarily mess with the block content.
Differences are: on the upside, verification by SNARKs instead of users; on the downside, data availability is YET not solved offchain (though the data availability cost is an order of magnitude better in terms of gas).
“Data availability is YET not solved offchain.” Doees this apply to the OMG plasma as well? Do you know how they plan to get around it?
Alex Gluchowski: Sorry, I’m not familiar with the current status of the OMG Plasma, but to the best of my knowledge nobody else is using SNARKs for scaling Ethereum yet.
Coda does, but they are a separate cryptocurrency and use a different approach (recursive SNARKs), which in my opinion has more challenges.
Mário Buči, who appears to be working on Lighthouse and was testing Ignis, clarified that everytime there are 8 transactions on the sidechain, “they are checked and collected by the operator(s) into a block, and the proof is sent to the main contract on the main ethereum blockchain. So the confirmation on the main net is equal to confirmation on the sidechain (so roughly every 14s).”
That makes it somewhat interesting because we don’t have to deal with routing here or any of the other Lightning Network problems. Besides security, the only problem instead seems to be whether enough people will want to use it.
One aspect that might limit such usage may be that you have to lock your eth. Whether that’s a feature or a bug, however, may well depend on just how secure the smart contract turns out to be.
That won’t be known for years. Bugs are to be expected in this space. Here we have the further complexities of the snark circuits. All will have to go very slowly. If however all is proven robust, then it may well be safer to keep the eth in the smart contract.
This solution, however, makes far more sense on the backend of a dapp or even MetaMask, rather than a stand alone dapp. It appears to be quite a lot cheaper even in the current set-up. With specialized hardware and other improvements, it might reach the stage where no dapp can be competitive without using it.
Plain Plasma may give it competition, which can only be good as far as end users are concerned, with on-chain sharding giving both competition, making it even better for our dwindling testrun eth funds which have contributed a fair bit to the miners.
Ignis can work on top of sharding. So the potential 50x gain on the current “dumb” blockchain becomes 50x gain on top of the 100x or 1,000x gains that sharding will provide.
That gets us to world level scaling before quadratic sharding. The year of no-action, thus, has begun.