Vitalik Buterin

Vitalik Buterin

@lens/vitalik

mi pinxe lo crino tcati
Earth
53632Followers

Posts

3 days agovia Firefly

(yes, even the shrimp matter. Many people have the impression that shrimp welfare is some kind of nerd thought experiment gone crazy, but the reality is, well ... ask your bot about "eyestalk ablation")

3 days agovia Firefly

Sent another 64 ETH to the Animal Welfare Fund. I encourage others to think and act more in support of our non-human cousins too! The extreme suffering we're imposing on them in the billions is not something we talk about often, but it continues to be one of the larger blights on humanity. And I'm getting optimistic that this century we can finally end it. Farming practices are improving, synthetic alternatives are improving. Also, in my recent experience, good old low-tech vegetarian and vegan food has improved massively worldwide over the last ten years; I encourage anyone who has tried it long before and given up to take second look; there are far more healthier and tastier options today than the "pasta and salad" you would often get ten years ago.

4 days agovia Firefly

"Even more bugs are inevitable, software is all going to become probabilistic now" is cope. "AI bug-finding means we have to embrace closed-source now" is a psyop. Writing buggy code has moved from hard to trivial. Writing secure code has moved from impossible to hard.

4 days agovia Firefly

This theorem (left) means, the only way you can make proofs for two different things in the same position in the same Merkle tree, is by breaking the underlying hash function. As a reviewer, you don't have to verify how Merkle branches are implemented or how the theorem is proven (right), you just have to verify what the theorem says, and that Lean verifies it. And the beautiful thing is that you can even write live production code (including eg. CLI tools) directly in Lean.

Post image: This theorem (left) means, the only way you can make proofs for two different th
Post image: This theorem (left) means, the only way you can make proofs for two different th
4 days agovia Firefly

Getting increasingly bullish on just vibe-coding the important things in Lean. eg. see: https://github.com/Verified-zkEVM/ArkLib https://blog.zksecurity.xyz/posts/end-coding/

5 days agovia Firefly

I continue to not like the idea of calling the name you have in government documents a "real name". It subtly reinforces the idea that government is some kind of uniquely privileged root of reality. If you want to be boring and neutral, "legal name" is fine.

9 days agovia Firefly

"A prediction market is only as good as its oracle" I'm glad we're finally seeing PMs start to move to oracles that are both not centralized and not financialized. Next step is to make attester voting private. https://x.com/llamaonthebrink/status/2051059628817981871

10 days agovia Firefly

Keyed nonces are not just a way to add stronger in-protocol support for privacy solutions. They are also a potential first foray into a new state scaling strategy for Ethereum: create new types of storage that are more optimized for handling categories of use cases that we care about, with restrictions on their use that make them usable at extreme scale while preserving the protocol's decentralization. Let's zoom in on this case (in-protocol nullifiers). Let's say we get to 2000 TPS of privacy-preserving transactions onchain, for eight years. Then we get 2^11 tx/sec * 2^25 sec/year * 2^3 years = 2^39 [ie. 500 billion] nullifiers stored onchain (the challenge with nullifiers is that they are fundamentally not possible to prune). It's actually far easier to keep Ethereum decentralized if we have 500 billion nullifiers onchain in a dedicated nullifier store, than if we just let them grow in the current state. The reason is that the more restrictive structure of nullifiers (only used to check validity, and we can require the nullifier ID to be explicitly specified in the tx) enables more decentralized ways of handling them. This includes: * Sharding: each node (incl builders) can hold a small percentage of nullifiers, and make sure to have a connection to an honest peer in each other shard * Bloom filters: see this somewhat wacky idea here for reducing the VOPS requirement for nullifiers to ~8 bits per nullifier: https://docs.fileverse.io/d/020001fc0012#k=UT7Btd6tyqHgOj47t-TX06F8D6OpcpM_2PKdf7s4tGE Both techniques are not possible to use for dynamically accessible state. And so builders would have to download the full 16 TB to become viable (not just optimal, viable!), and privacy protocol users would not be able to use FOCIL without providing a Merkle branch proving that their nullifier is unspent, and there would be very few nodes capable of providing such a branch... Zooming back out, the moral of the story is that fully dynamic state is much harder to handle at extreme scale (tens to hundreds of TB) than state that is more controlled and restricted in how it can be used. And so if we can move the majority of usage into these more specialized forms of state (which we can make much cheaper in terms of gas), then we can keep Ethereum decentralized, and highly scalable, and keep the fully dynamic state available for applications (eg. defi) that really need its full functionality. https://firefly.social/post/x/2051632978942390479

27 days agovia Firefly

The kind people at @eth_limo have warned me that there has been an attack on their DNS registrar. So please do not visit vitalik.eth.limo or other eth.limo pages until they confirm that things are back to normal. You can check my blog via IPFS directly here: https://bafybeiaql2jo3fu5b7c4lmpoi5drh5sam7yt652shwdgwbky4o7uw33u2u.ipfs.dweb.link/

about 1 month agovia Firefly

My self-sovereign / local / private / secure LLM setup, April 2026 https://vitalik.eth.limo/general/2026/04/02/secure_llms.html