1/ EIP-6780 coming with the Dencun update to Ethereum modifies SELFDESTRUCT so that smart contracts can destroy themselves only in the transactions in which they were created.
3/ If we don’t sustainably exhaust the block space on an L2, there won’t be a gas war on that network, and the gas prices for executing transactions should remain low
1/ This blog post on classification of ZK-EMVs by
@VitalikButerin
is becoming a classic. Let's go through it.
Type 1: Fully Ethereum-Equivalent
Type 2: Fully EVM-Equivalent
Type 3: Almost EVM-Equivalent
Type 4: High-Level-Language Equivalent
5/ Since there is no smart contract code on chain, this wallet doesn’t need to have the smart contract risk. There is nothing to hack. So unless someone can deploy the same wallet, which would require compromising the deployment process, the funds can’t be moved.
4/ The other part that users pay for are data. But L3s post data on L2s that post that same data on L1s (or other DAs in case of validiums). The savings don't appear to be there either
The Future Computing Research workshops by
@DelendumV
belong to my favourite events packed with deep research content.
Jens Groth is giving a talk at this beautiful venue right now.
Zircuit will be doing a talk about Sequencer-Level Security on Saturday March 2 at 2:45pm MST at the Seamount Stage at ETH Denver. We’ll go technical and take a look under the hood of this mechanic.
@EthereumDenver
@ZircuitL2
6/ This is all very neat, but as far as I know, ephemeral smart contracts never took off. I don’t know why. While everything will now have to happen only in the constructor, the use case of CREATE2 + SELFDESTRUCT combo will remain valid and supported even after the Decun upgrade.
In the initial phase,
@ZircuitL2
intentionally uses so-called “template proofs” to roll up its state in a timely manner for the chain to reach finality fast. Over time, as the proving system matures and becomes more optimized, these will become unnecessary and every block will be
1/ I received an interesting sequencer-level security question after my talk at
#ETHDenver2024
: would Zircuit’s sequencer reorder some transactions to prevent hacks.
7/ The redemption of the LP tokens for all the fractions would be possible only if all the fractions were present in that AMM pool. But in that case, the amount ETH in the pool will exactly match the original provision, because x * y = k.
8/ Many of these operations are computationally difficult to produce a ZK proof for, and therefore we can have ZK-EVMs that don't include them. Those are Type 3 ZK-EVMs, and they can generally make more changes to how they work with the memory and stack, and to the opcodes.
@0xCygaar
This debate is the reason why we chose the design for sequencer-level security for Zircuit that I present at ETH Denver. It’s proactive, not reactive. I think that the right decision for Blast is clear, but it’s hard to make that call and go against the established ethos.
9/ Type 4 ZK-EVMs do not need to be based on EVM. We insist that there is equivalence at the programming language level targeting the EVM, such as Solidity, but it can be compiled into anything that is friendlier for ZK, and it does not need to originally be an EVM at all.
10/ These ephemeral blob transactions can be used to post rollup data cheaply. This means that the cost of operating (and therefore using) a rollup (like Zircuit) will go down.
5/ Sandwich attacks are the case when reordering could help. But with an objective honest centralized sequencer, sandwiching someone else’s transaction doesn’t seem to be repeatedly feasible in the first place.
What's the future of Layer 2s?
How to make really secure rollup?
What's the best way to onboard devs to your project?
New
@epicweb3
podcast with
@dr_zircuit
, co-founder
@ZircuitL2
!
Had a great time discussing L2s and rollups in general!
Available everywhere:
📍Youtube -
4/ One can best imagine it in the context of an on-chain smart contract wallet. You “open it” by creating it when you want to use the assets that it holds, and then you “close it” by destroying the contract. No smart contract exists on chain in between.
3/ As for the winners of Best Hackathon Project on Zircuit, congratulations again to Donation Appreciation and Art Land Sphere who placed first and second respectively 🏆
3/ Reordering could be effective only if there are sequences of transactions that execute a hack together. Identifying such transaction dependencies would be computationally quite hard. Additionally, reordering could only be applied if the nonces of transactions allow it.
4/ This means that we would likely need more accounts transacting at the same time, sort of executing the hack together, to be able to reorder anything (again, disregarding the sandwich attacks for a moment). Hacks usually don’t happen this way. Or at least don’t need to.
2/ L2s have plenty of block space. Blocks are being created in the order of seconds, and they can be very large. Every L2 has probably space to accommodate at 100x bandwidth of what they do now
2/ I gave it quite a bit of thought, and got to the conclusion that it might not be fruitful. Reordering transactions could be useful to prevent sandwich attacks, but I don’t think it would be very effective otherwise.
2/ We had a great conversation about the promise of ZK technologies for the future, the current state, and the challenges.
Huge shoutout to the organizing team for putting together an amazing conference, and all the fellow panelists for a fruitful discussion!
1/ It was my pleasure to present the sequencer level security demo for the first time at
@EthPrague
I'd like to give a few shoutouts to the people who made this conference memorable ⬇️
5/ Lastly, a huge thank you to the organizers for arranging a great event and giving us a platform to showcase what we're building.
I'm proud to have shared the finished SLS technology at
@EthPrague
and now we will continue our work to reach mainnet.
2/ Thank you to the hackers who submitted projects for Best Hackathon Project on Zircuit. Your work helps us enhance our network and it's exciting to see new projects being built on
@ZircuitL2
2/ You then take those ERC20 tokens, pair them with ETH, and provision as liquidity into an AMM pool based on the Uniswap idea x * y = k where k is a constant. Your NFT can be fractionally traded. But…
3/ Additionally, since their addresses are derived only from the CREATE2 parameters, they can be deployed repeatedly to the same address. Therefore, they can be deployed on chain when we need them, and removed when we don’t need them. This has implications.
3/ We don't have Type 1 rollups because the EVM wasn't designed with ZK proofs in mind, and contains elements that are hard for ZK. For example, proving the sha3 hash function (keccak) is hard for some ZK systems.
5/ EIP 4844 adds a new type of transaction altogether: blob transactions. These let users submit truly ephemeral data to the blockchain. They post so-called blobs, which just contain data.
4/ If we could work with floating point numbers and infinitesimal math in smart contracts, the formula says that the “very last fraction” of the NFT should cost infinity of ETH.
6/ As a result, the only party able to withdraw all the fractions from the AMM pool to redeem back the NFT would be the original LP provider. Interesting, right?
5/ Since we can’t, the smart contract math will just revert on something like division by 0 (the exact error will depend on the specific implementation) during an attempt to purchase the last ERC20 token from the pool.
7/ The 0x01 provides the ecrecover() function used for checking signatures. The 0x02 provides keccak(), and there's more hashing, cryptography, and algebra hidden in the rest of them.