Ethereum

Maybe some crazy thought but I'm wondering if there is a direct and smart way to enshrine Tornado Cash / Railgun tech in the Ethereum base layer. While I understand that the base layer should remain as simple as possible—and I agree with that principle—it's worth considering that we've already spent considerable time prioritising other features over privacy-by-default at the foundational level.

𝐖𝐨𝐫𝐤𝐢𝐧𝐠 𝐨𝐧 𝐰𝐡𝐚𝐭'𝐬 𝐧𝐞𝐱𝐭.

https://github.com/pcaversaccio

Auditoooor at ChainSecurity
—
EPFL Cybersec MSc.
—
CTF player w/ 0rganizers
—
Hacker & Cypherpunk
—
🌸

Great point - we can combine both I think.

In my view, block producers can inherently filter based on arbitrary criteria. It doesn't really matter if it's built-in or not. The most neutral setup is a diverse set of block producers, combined with encrypted mempools to reinforce their credible neutrality.

Solidity Engineer | Researcher | Onchain Degen | DMs Open | https://github.com/0xCooki

it's much harder to censor txs at the base layer than on the application layer (a validator can simply censor a tx if you send it to one of the TC addresses, but what if you have a builtin precompile address that you call in a complex call trace?). Also, I envision a privacy-first Ethereum roadmap and I want to have builtin features for that. Let's see if they want to put a precompile address on an OFAC list...

Why are the smart contracts insufficient?

I really liked the way eip 7503 would achieve this (eip7503.org) 
But I would preferably have something like this tested live on L2 for years before we implement it or something similar at L1. The catastrophic scenario is an inflation bug that goes unnoticed for a very long time if an attacker manage to prove invalid statements and can therefore double spend their previously burned ETH

if you do it too explicity it makes ethereum ripe for sanctions.

Stealth addresses might help. But that’s not protocol level