-
Notifications
You must be signed in to change notification settings - Fork 123
ethCC Scalability Report
A few talks about how to ensure the correctness of the plasma chain. All were some variant of watchtowers. Watchtowers are entities to which a user can outsource the task of watching the chain to ensure correctness. While there is nothing particularly bad about these kind of solutions, it does bring about unnecessary complexity and risk that is completely unnecessary with zero-knowledge proofs.
Next to 0x, the only other project doing kind of the same as we is Liquidity Network. They are also working on 2nd layer scalability and have some special kind of front-running/FIFO system with cryptographic puzzles we should definitely take a look at.
These are the guys that do decentralized identity on Ethereum using zk-SNARKs usinh JS as a language. For zk-SNARKs they are looking into optimizing their JS compiler and creating proofs using distributed computing, so nothing really new. The overhead of this system also makes it not suitable for applications that do any significant kind of work inside a SNARK.
Talk was mostly about their general vision on scalability, not in depth about how their DEX works with STARKs. But there was definitely some interesting information given.
First of all an estimated timeline for some things they are working about.
Liquidity aggregation -> Network transport (using libp2p) -> Trade execution (TEC) -> Trade Settlement (0x)
Not that much information was given about this setup. We already know they were working on a TEC. No other details were provided.
The libp2p was new for me. I don't know much about networking, but the use of libp2p would allow 2 parties to directly match orders with each other without a relayer and without knowing each other. So as I understand it centralized relayers wouldn't really be needed anymore (but I assume they would still have their advantages).
The same as above with STARKs before Trade Settlement.
This was called still very experimental (even more so than SNARKs because STARKs are newer). The verification cost for a STARK starts at 5M gas. 4,5M of the gas is used for sending these pretty large STARK proofs in the calldata, the actual verification computation only costs 500,000 gas (they first thought that these computations were impossible on current Ethereum, but they got it working some way with solidity assembly). The verification cost and the proof size increases very slowly with the number of constraints in the circuit.
They are not going to depend on Ethereum for data availability. They are looking into using a simple setup where there would be a small group of nodes (the number 20 was used here, I think they called it a consortium) which would all have to sign the data necessary for rebuilding the merkle trees. Data availability is ensured as long as 1 of these nodes actually shares the data with everyone.
Loopring Foundation
nothing here