avatar
Pandit | Ξ🦇🔊

Following0Followers (X)7.57KPosts297Likes2.31K
avatar

A contract that keeps running after a failed call has no reliable way today to tell whether the callee reverted on purpose or simply ran out of gas the sender chose. That gap is the root of insufficient gas griefing, and a new draft proposal tries to close it at the EVM level. EIP-8456, opened for discussion on Ethereum Magicians on Monday, adds an instruction called CALLSTATUS, tentatively at opcode 0xA5 for 2 gas. It pushes the completion status of the most recent call or create operation in the current frame as three bits. Bit 0 means a revert, bit 1 means an exceptional halt such as out of gas, and bit 2 means something in a frame below halted. The author points out that the only evidence today is gasleft() arithmetic after the call, and that every repricing fork has broken those thresholds. The proposed two-dimensional gas of EIP-8037 would make that arithmetic even weaker, since its reservoir isn't visible through the GAS opcode. So why the third bit? Most real calls pass through intermediaries like proxies, OpenZeppelin's functionCall wrapper, Multicall3 or ERC-1271 signature checkers. If only the direct callee's ending were reported, a wrapper that catches an out-of-gas halt and reverts with a reason would look like a deliberate revert. The draft keeps a sticky flag that travels up every frame, so a sender who only controls gas can never make a caller read a plain revert. It reports outcomes rather than causes, and a callee can still produce a halt on purpose with INVALID. It only protects code written after it ships, because deployed contracts won't read it. There are no external reviews yet, the opcode number is still open, and a prototype plus tests for 58 listed cases is still pending. Link - https://t.co/KnByUBgWrY

avatar

Most Ethereum wallets still show your entire financial history to anyone who has your address, and the Ethereum Foundation is now framing that as a security hole rather than a privacy nice-to-have. On Monday, the Foundation posted that the past week's attacks and exploits made one point clearer to them, which is that privacy and security can't be treated as separate goals. Their line was that you can worry less about an attacker using your onchain history against you when privacy is the default. The post quoted an update on Kohaku, the Foundation's privacy-first wallet tooling project. The JavaScript repo splits it into packages that a wallet team can pick up one at a time. There are libraries for Privacy Pools and Tornado Cash, plus a Railgun library the README currently marks as under maintenance. A plugins package defines a standard interface for shielded pool protocols, so a wallet can talk to all of them the same way. A provider package abstracts over ethers, viem, Helios and Colibri. The repo also ships a post-quantum ERC-4337 account. Rust crates live in a separate sister repository. I like that this is shaped as an SDK rather than yet another privacy wallet asking users to move funds. The idea is that existing wallets add shielded flows without each team reimplementing three protocols. The README is blunt about where things stand. Some parts are marked as not ready for production, and the packages contain unaudited code. Ambire's Jordan Enev said last Friday that the team has spent months testing the integrations, and no public launch date has been given. Vitalik and Nicolas Consigny are scheduled to demo Kohaku with Ambire on Ethereum mainnet at @EFDevcon next Tuesday, according to the session listing. here is the repo - https://t.co/egNbLgAo0J

avatar

Your terminal can now talk back to you, and the funny thing is that it does it without calling any cloud API. On Saturday, Ollama shipped 0.40.11 with text-to-speech on macOS. The first speech model is Phonon, a family of small TTS models from Gradium. You pull it with ollama pull phonon and run it like any other model. The bit developers will actually care about is the API. Phonon works with the OpenAI-compatible /v1/audio/speech endpoint on localhost. If your code already uses the OpenAI SDK for speech, the docs say you only need a new base URL. The response streams while audio is being generated, so playback can start before the full text is done. You can even pipe a chat model's reply straight into Phonon, and it starts speaking after the first sentence. Output is 24 kHz mono, as WAV by default or raw 16-bit PCM if you ask for it. The docs list some limits that are easy to trip over. Each request takes up to 4,096 characters, although ollama run splits longer text for you. Prices, symbols, emails and URLs get spelled out, while numeric dates are read as written, so the docs suggest writing dates out in words. Unsupported options like speed or instructions return a 400 error instead of being quietly ignored. The licensing deserves a careful read before you ship anything. The default English phonon model is Apache 2.0. The 40M French, German, Spanish, Portuguese and multilingual variants are CC BY-NC 4.0, which rules out commercial use. Ollama also says that on an M5 Max MacBook Pro it ran 35 percent faster than Gradium's own runtime, which is their benchmark rather than an independent one. Speech is Apple Silicon only for now, with Windows and Linux support listed as coming soon.

avatar

An Ethereum L2 that accepts zero signatures sounds like a security bug, but BB84 is doing it on purpose to dodge quantum attacks. Last weekend, its founder, who posts as Hadamard, published the design on Ethereum Research and asked for critical feedback. BB84 is an OP Stack rollup on mainnet, live since September 30, where L2 transactions carry no ECDSA at all. Each account is the tip of a keccak-256 hash chain built from a secret, with 1,000 steps by default. To spend, your wallet reveals the previous value in the chain, which anyone can verify by hashing once. Inside the L2, the only assumption left is preimage resistance of keccak-256, which Grover's algorithm cuts to about 2^128 work. Revealing a secret makes it public, so the protocol adds a commit and reveal step to bind each preimage to one transaction first. Two new transaction types in op-geth handle this, and the sender check replaces ecrecover. Authorisation is consumed even when the call reverts, and if a wallet misses the renewal step on the last link, that address is dead. The post includes a front-running flaw the team found while writing it. Commits carry no signature, so a new commit used to replace a pending one, and an attacker could rebind a revealed secret to their own payment. A rule that took effect on October 21 makes the first commit win. The limits are spelled out plainly. L1 deposits and withdrawals still use ECDSA. There are no fault proofs yet, and by the post's own account the chain would not even reach L2BEAT Stage 0. The sequencer is run by the team, and 160-bit addresses leave about 2^80 quantum second-preimage resistance. The post also asks whether hash-chain accounts could become an EIP-7702 or native account abstraction validation mode on general L2s.

avatar

OpenZeppelin made Chainlink the default for cross-chain and compliance in its token tooling, and if you tick the compliance box, your token's license changes. A week ago, OpenZeppelin announced a strategic partnership with Chainlink. CCIP and ACE, Chainlink's cross-chain protocol and its Automated Compliance Engine, are now built into the Contracts Wizard, OpenZeppelin's AI tooling and its docs. The ERC20, Stablecoin and RWA generators all offer both options. Picking the CCIP option makes the token expose the mint and burn calls a Chainlink burn-and-mint pool needs, behind the token's own permissions. It also names an administrator for CCIP registration. That part keeps whatever license you chose, because no Chainlink code goes in. The ACE option is different. It forwards transfers, mints and burns to a Policy Engine that you deploy and configure. OpenZeppelin's own docs say tokens using ACE fall under BUSL-1.1, and production use has to satisfy the ACE license and its additional use grants. For years, a generated OpenZeppelin token carried whatever license you picked, usually MIT. A single checkbox now changes that, and a junior dev in a hurry may never notice. The generator doesn't register your pool, set permissions or write your policies. Attaching a Policy Engine doesn't configure any policy, and you stay responsible for meeting whatever rules apply to you. The announcement also mentions a migration path from OpenZeppelin Defender to Chainlink's Runtime Environment. None of this is hidden, and for an RWA team that already wants Chainlink, it saves real integration work. I just want builders to choose it on purpose, not because the wizard put it there.

avatar

Smart contract maxis, Your Solidity compiler may have quietly deleted a store you needed, and you'd never see it in your source. Solidity 0.8.38 came out last Thursday. It fixes a bug in the Yul optimiser that sat in every release from 0.8.19 to 0.8.37. The optimizer keeps notes on what's in memory and storage. It uses those notes to replace a load with a value it already knows, and to skip a store that writes what's already there. To decide whether two addresses can overlap, it describes each one as a base variable plus an offset. Same base, different offset, so they must be different slots. Those descriptions were cached. Then someone reassigns the base variable. The optimiser doesn't always notice. Now it compares an address built from the old value with one built from the new value as if they shared a base. It decides they're different, but at runtime they point to the same place. The result is a stale note. A later load can return an old value. A store you needed can get removed. A keccak256 over that location can hash outdated data. Only code compiled with the optimizer on is exposed. With via-IR, any code can hit it, even without inline assembly. With the default legacy pipeline, only some inline assembly and compiler-generated helpers. Unoptimized builds are safe. The team rates it low severity, and they did something I wish every compiler team did. They recompiled every verified contract in the Sourcify database with and without the fix, and the bytecode was identical for all of them. So it's rare. Rare isn't the same as never, especially if your code is fresh and not deployed yet. The bug came in through the Ethereum Foundation bug bounty, and a second report showed plain Solidity without assembly can trigger it.