Fully automated luxury smart contract

Designed for builders, devs & autonomous agents to push the boundaries of @Ethereum's performance, Surge Rollup is built on @TaikoXYZ stack and will be: - Stage 2 at launch - Based & ultra sound using $ETH for gas - Gigagas, leveraging the Nethermind Client’s performance - & more

⚡️Supercharging @ethereum while keeping it decentralized, secure & stable. Introducing Surge Rollup, an ULTRABASED rollup for builders, devs & agents to push Ethereum’s limits- & Surge Power-Ups, open source upgrades for based rollups. Learn more: Surge.WTF or 👇

The latest @thedailygwei Refuel is ready for your consumption! ⛽ Today's topics: - ETH is money 💸 - Pectra upgrade split 🪓 - Why layer 2's 🤔 - and much more ➕ Watch 👇 youtu.be/LdyXcxrsuuU

EOF (EVM Object Format): Full Guide Everything you need to know as a Web3 Builder in 30 mins: ➡️ (0:00) Intro ➡️ (0:41) Why EOF ➡️ (2:20) Current EVM vs EOF EVM ➡️ (4:31) EOF example ➡️ (10:53) Stack too Deep Error Solved ➡️ (13:21) EOF Advantages ➡️ (24:50) Disadvantages ➡️ (26:48) Community Against EOF ➡️ (29:18) Conclusion Like & RT ❤️

I have been told that I need to "do less philosophizing and do more ethereum bullposting". Hence, here is an ethereum bullpost, courtesy of stable diffusion 3 inpainting gimp.

Happy 9th birthday Ethereum!! Our @ethereumfilm documentary team released a short film “Community.eth” to celebrate 100% of mint proceeds go to @protocolguild to support Ethereum R&D maintainers zora.co/collect/base:0x8bbce…

1/ You can now find all Ethereum ETF onchain flows here 🫡 dashboard: dune.com/hildobby/eth-etfs

The goal is to replace the current Merkle Patricia state tree (MPT), because the current MPT is *very* unfriendly to stateless clients: a worst-case stateless proof for an Ethereum block is ~300 MB (think: spam reads on 24kB contracts), and even the average case sucks because the tree is width-16. It's also very SNARK-unfriendly. The alternative we've looked at so far is Verkle trees vitalik.eth.limo/general/202… , which use elliptic curves and IPA-based proofs; with verkle trees and associated gas cost changes ( eips.ethereum.org/EIPS/eip-4… ) the theoretical worst-case proof size drops to ~32 bytes * depth 6 * 15789 accesses = 3 MB; the average case is a few hundred kB. The other alternative is binary trees. But raw binary proofs are a little too large (average case ~1 MB, worst case ~12 MB), and so we want to wrap them in a STARK. But the challenge with STARKs historically has been proving time. Recently, @StarkWareLtd folks have had a series of breakthroughs proving over 500k hashes/sec on a high-end Macbook (!!), meaning that even in a theoretical worst case, they would be able to generate a STARK for a block stateless witness within one second. But this is based on the Poseidon hash function, which is relatively new and untested, and so many consider it too immature for L1 today. The more conservative approach would be to use SHA256 (or rather, the SHA256 compression function), which is very safe, but also very complex, and much slower to prove (specifically, ~20-50x slower). But there has been work on improving modern proving systems even further, and it looks like proving "conservative" hash functions might be closer to viable than we thought! Binius is particularly adaptable to this, because you can do all kinds of binary operations directly without needing lookup arguments, and there have recently been great improvements to its proof size ( irreducible.com/posts/better… ), but there has been great process with circle STARKs too. A totally different conservative approach that we started talking about last week, is using lattice-based hash functions, which Ajtai's is one example of. These are arithmetically simple, making them quite prover-friendly, but they also derive their security from lattice hardness assumptions. And it turns out that they are actually more compact than I expected: there's a "conservative" option that's a mere 64 bytes long (compared to 32 bytes for all the other hashes) alonrosen.net/PAPERS/lattice… , and we're starting to explore more aggressive options that are 32 bytes long. These are very prover-friendly, my napkin estimate is that they are only ~2-4x worse than Poseidon.

The last week of Ethereum state tree research be like...

This is possibly the dumbest crypto FUD I’ve ever read

Why is my feed full of people pretending like over a billion in day 1 ETF volume is not a big deal

ETH BTC chart right now

Introducing Clear: the complete framework for interactive theorem proving in web3. A formal verification tool for @solidity_lang smart contracts that expresses any on-paper verification into mechanized proofs. 🖇 medium.com/nethermind-eth/cl…

Two big things people and media get wrong. 1. "crypto mining is using too much energy." correction. #Bitcoin is using too much energy. 2. "crypto will allow tokenization of real world assets." correction. #Ethereum will allow tokenization of real world assets.

The latest @thedailygwei Refuel is ready for your consumption! ⛽ Today's topics: - EthStaker survey results 🥩 - Obol Charon v1 live 👍 - Here for the culture ✊ - and much more ➕ Watch 👇 youtu.be/9TM00XTugtQ

The tech has improved! Kudos: @URozmej @ben_a_adams

For the past two weeks, we’ve been testing @nethermind's latest release, 1.27, which features significantly reduced block processing times. A picture is worth a thousand words - here’s a screenshot from our dashboard showing the improvements:

The latest @thedailygwei Refuel is ready for your consumption! ⛽ Today's topics: - Ethereum H2 tailwinds 🚀 - The Burn research 🔥 - Protocol Guild chat 🤔 - and much more ➕ Watch 👇 youtu.be/u0E9d4BbG3U

Introducing state "compression" in #Ethereum (aka, Verkle trie) where you only need the current state root of the chain, and you can run a stateless validator not needing to store any state (blocks come with the witness of state changes). You think I am done? Introducing Block History "compression" (aka EIP-4444) where you dont need to store historical blocks of ethereum anymore. They are accessible from portal network and era files hosted on multiple servers and torrent. All you need to know is the hash of the finalized block provided to you by the CL client. This solves increasing storage requirements of validators on ethereum.