This is the first dialogue transcript released by Sin7Y, where we invited anonymous experts in the industry to provide some ideas and directions about EVM to think about - the problems currently under solving in a Q&A format. Transcript How to prove that the prover has performed the correct contact logic? Q: So you will have call data start being onchain, This will define the "to contract" then we need to load that contracts byte code from storage and make sure these are the opcodes the state proof passes to the EVM proof. A: So the process follows: Q: Prover loads contract bytecodes from storage; Bytecodes are checked in state proof and then passed to EVM proof. But how do you ensure the bytecodes used in state proof and EVM proof are indeed loaded from the storage? Is it ensured in the circuit or do you need to use plookup technology like the HERMEZ scheme? Yeah plookup can be used to build a key-value mapping. A: Any thoughts on native-based zkEVM VS. compiler-based zkEVM? Alex from ZKSync said native-based zkEVM(which I think we do now) is 'more complex by an order of magnitude. Q: The compiler-based approach will change a lot. The security properties of smart contracts, specifically it will require new audits with the new EVM behavior in mind. It will require developers to learn these new behaviors and be careful of them while they build smart contracts. A mistake that has been observed in the past was assuming that if someone builds something, developers would learn how to use it. Something we can learn from the optimistic rollup teams is that it's very important to be able to support developers without requiring them to rebuild everything. A: Both approaches make sense, so both are worth exploring； However, some voices are more convinced that the EVM emulation approach will work. And we need to be careful about how complex your compiler can become while working on the compiler-based approach. What do you think of using zk-friendly for compiler-zkEVM VS. native approach? Q: This is a tricky question. I would say that we can know for sure after implementation. But I am worried about security and how developers adjust to the new EVM even the language is the same. That is part of the reason some teams go with the pure EVM. A: Halo2 algorithm may need a trust setup if KZG10 is replaced with IPA. Why don't we use the Plonk algorithm directly？ Q: True. I think a trusted setup is acceptable for now. Longer-term, teams may want to be able to switch to another quantum secure polynomial commitment scheme that doesn't require a trusted setup. So now, developers are trying to architect things in a way that will allow this. This means trying to avoid adding/multiply kate commitments. With kate, this can be done in commitment form. But with Starks, developers have to do this element by element which would be prohibitively expensive. A: There are two circuits(state circuit and EVM circuit) in the current zkevm scheme and maybe more (signatures circuit), Do you think recursive snarks are applicable? Q: Yes, probably there will be 3 or maybe 4. Recursion allows for cheap onchain verification hopefully a single pairing check. Like recursive aggregative plonk, multiple proofs are verified one time onchain. A: Any idea of replacing Keccak with snark-friendly zkevm and concerns? Q: It is one of the routes to reduce the size of the circuit. The concern about replacing keccak is compatibility reasons and that you will have to change solidity compiler because they use keccak for some optimization and also for computing the location in storage to store a mapping element.
Proving time costs might not matter as much because developers can just work hard on making proofs very fast and even if it costs a bunch extra we are okay with that because current transaction fees are so high. A: Is it possible to add the zk-friendly hash to the precompiled contract and the solidity compiler to the same hash, so that it can replace keccak? Q: It is possible to add it via hard fork though it probably gonna be hard to convince people to do that. It's also possible to adjust solidity to use something else other than keccak. A: How is Halo2 lib api compared to zksync API? Q: Using halo2 can speed up development. It lets developers define polynomials very easily, which is the basic component. The big problem with halo2 lib is the halo2 polynomial commitment, but we can change that to using kate instead. A: What do you think of the workload of introducing a zk-friendly op, like Poseidon hash? Q: If you don't need to modify the compiler of solidity, you can just replace the keccak hash with Poseidon hash in the bytecodes complied by the native solidity compiler and add a precompiled Poseidon hash contract used for calculating the index of storage. I think this is probably not a lot of work. But I realized recently that solidity uses keccak to decide where to store items in storage. For example, mapping uses it. So if you change this hash function would also have to change the node + evm testing infra to also use this hash function. A: A question about upgrading the EVM. EIP1559 is hard to implement in zkEVM, even if we make it, how do we make another new EVM change(e.g EIP3855) after zkEVM is complete? Q: Once that is deployed, you can't have an upgrade feature without some big security problems. Because if you can upgrade the L2 then you can always upgrade the L2 to a new version that gives all the money to you. With that setting, the platform will probably have to do a yearly zkevm new version where everyone needs to migrate to that new version. Just like Uniswap v1 and v2 have less value inside them. A: About Sin7Y Sin7Y is a non-profit research organization backed by L2 Labs Foundation. It explores the most important and edgy topics in the crypto industry - EVM, layer2, sidechain, cross-chain, and anonymous payment solutions, etc. The goal for the dialogue is to bring like-minded people together to form a long-term sustainable development of the think tank to educate and enhance the efficiency of problem-solving.

Uniswap

Chain

BUNCH

fees

2022 - HackerNoon Contributor of the Year - Algorithms

2022 - HackerNoon Contributor of the Year - Architecture

2022 - HackerNoon Contributor of the Year - Blockchain

2022 - HackerNoon Contributor of the Year - Optimization

2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Optimization

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Blockchain

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Sin7Y Researchers Dialogues - Thoughts on Ethereum Virtual Machine (EVM)

Sin7Y Researchers Dialogues - Thoughts on Ethereum Virtual Machine (EVM)

Too Long; Didn't Read

Companies Mentioned

Coins Mentioned

Sin7Y

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Sin7Y Researchers Dialogues - Thoughts on Ethereum Virtual Machine (EVM)

Too Long; Didn't Read

Companies Mentioned

Coins Mentioned

Sin7Y

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES