A maximally simple L1 privacy roadmap

25

These next-level ambitions are all promising and important to explore. However, I think more people need to start paying attention to the basics when it comes to privacy.

Have you tried passing your wallet/browser through mitmproxy or burpsuite and checked out just how much information is broadcasted to various endpoints in the cloud? If you use a browser extension wallet, you may be surprised to see traffic that is not visible in Chrome/Firefox developer tools Network tab.
Now see how much you are actually able to prevent leaking by using the wallet settings. Disable any analytics, use your own RPC node, disable optional third-party features, and try again. Compare reality to the privacy policy of the wallet.

The state of privacy in mainstream wallets have gone increasingly worrying over time and I don’t see much talk about that. The features discussed in this thread don’t mean much if balance- and history requests in practice use proprietary unconfigurable vendor servers. Addressing that is not an unsolved technical issue but one where wallet vendors have faced little scrutiny and pushback from the community.

Some deviations and options:

  • Konkret Wallet is one budding initiative showing a different approach to the browser wallets.
  • Trezor actually provides the option to do self-hosted and private account-indexing via BlockBook (but on the other hand their connector module is idiomatiacally loading from the cloud…)
  • TrueBlocks is a great way for expert users with the resources to self-host indexing

All are pretty obscure if not neglected. I think we need to start practice what we preach and addressing the here and now while we consider future possibilities.

1 Like
26

Continuing on the above:
The comment focuses a bit on browser wallets but the points and exercise are equally valid for household hardware and mobile wallets. You may be surprised just how difficult or even unviable it is to use certain hardware wallets privately and/or in an airgapped scenario today.

A bit tangential to the main topic of privacy but related to the larger security story: Just how long-term reliable is a hardware wallet if the vendor-provided app suites for end users won’t function without connections to public cloud servers? How robust its integrations if the vendor SDK and examples integrate with their server endpoints for basic functionality? Are we satisfied with the supply-chain security situation of various modules pulling runtime code from github, npm, and elsewhere? And back to privacy again: How many of these endpoints are TLS-terminated at either Cloudflare, Akamai, or one of the big 4 clouds? How confident are you in the integrity of those with the developing situation in US gov? I think those who understand the implications of such questions should do some research on their own in 2025 before recommending particular vendors to end-users.

Not naming names here because the issue is systemic enough and I really hope this triggers some readers to take a fresh look at the environment we are in.

1 Like
27

We can have ENS as main identity address making sure user can create variation of that address as sub identity same like we have wallet derivation path from seedphrase.

One user might want to remember one Seed but want to use multiple addresses for niche usecases/apps which we should support as decentralised identity so user can navigate addresses to right identity to use. @vbuterin

28

Can’t wait for some of these ideas to be implemented. I worry that many users will find it overwhelming and give up. Some users may think they have more privacy than they have, if they use a combination of features but don’t have the right mental models for how they overlap.

We need to build shared mental models on privacy that builders and users can reference, for clarity and efficiency. Otherwise I suspect we’ll see misunderstandings and duplication that may be very expensive in terms of time and mistakes.

29

Good observation @TimDaub. Our work on Addresso throws a different light on things.

When @vbuterin writes that we need to move to “one address per application”, I’d argue that it will definitely need at least one per application.

Rather than entailing “significant convenience sacrifices”, it should in fact be more intuitive, just as convenient, and, critically, more human. Which for the avoidance of any doubt I also consider to be ‘more Ethereum’! :smiley:

We have been given a most beautiful gift … an open source way for anyone to create abundant keypairs with associated UUIDs (wallet addresses) at zero cost without permission almost instantly.

We have been ignoring this abundance for no other reason I can see than received “wisdom”, and yet the abundance is ripe with abstraction potential.

Such abstraction helps us pursue humanity-centered rather than computing-centered design goals, but I won’t attempt to relitigate my essay here! (“Human identity: the number one challenge in computer science”)

If you’re looking for something a little more bite-sized, I can offer the following table.

There’s no doubt that Name Services have their applications, I’d just argue that human identity isn’t one of them if we’re not to render web3 the mother of all bureaucratic machines.

QUALITY WEB3 NAMING SERVICES e.g. ENS ADDRESSO
Inspiration DNS — a naming system for computers, services, and other resources on the Internet or similar networks. Human life.
Who does the naming? The entity that controls the address the name resolves to. We do. The beholders. Everyone making sense of their world.
Relativity Non-relative. As desired, e.g. “Mom”, “The school”.
Contexts Non-contextual. As desired, e.g. “Bob at work”, “Fred the electrician”.
Descriptive Not usually because descriptions are relative and/or contextual. As desired, e.g. “Tall Sarah”, “Kraken my original CEX”.
Abstraction Partial. The human-readable name is an abstraction of an address. Fully. Abstracts a person from a singular non-contextual name and therefore from singular addresses.
Plurality Works against plurality. Acclaimed for setting things up as if we’ll have very few wallets: “Keep your identity consistent across all services and platforms effortlessly. Say goodbye to juggling multiple usernames.” Ready for a near-future where each of us has hundreds of wallet addresses as contexts vary and as privacy demands. The variety is essential but will be abstracted away.
Privacy The Cypherpunk’s Manifesto notes “Privacy is the power to selectively reveal oneself to the world.” It’s very hard to do that when you present one (or one dominant) name to the world. Privacy is enhanced with relativity, contextual variation, subjective description, abstraction, and plurality.
1 Like
30

One practical reason we’ve not been able to scale this as a privacy solution is we’re largely limited by asset allocation today. In other words, if all my assets are associated with one key today I can’t suddenly control them with another key easily (EoA issue due to needing to transfer) or cheaply (smart account issue due to gas costs + funds still get correlated AFAIK). I don’t believe this is an unsolvable problem though, just one that we’ve not developed a scalable solution for so the friction defaults the user behavior to reusing the same account for simplicity and cost savings.

31

Thanks @kdenhartog. Yes, that corresponds precisely to how we’d sum it up :pray:

We’ve concluded that any form of resolution will necessarily require local-first, peer-replicating software. So that’s what we’ve been building. And that’s the design challenge we’d love to work with everyone here to crack.

1 Like
33

There is a way to create many temporary Ethereum accounts using identity-based signatures (IBS).

The basic idea is that a user publishes a master IBS public key, and then anyone who wants to send assets or messages to that user can generate a unique, temporary address derived from an identity string — such as "user@example.com#session42" — and send assets there.

The user, who holds the corresponding master secret key, can then derive the private key for any of these temporary addresse and spend from them.

The hardest problem to solve here is gas, since to send from a temporary address you would need to first get enough gas into it.

34

Why do envious people delete my comments?!

We will already launch a full-fledged web4 social network Allmint (without backend, with smart contract engin) and such ETH privacy technology will be very useful for ours users! Thanks

37

Now that RISC-V is trending again — not just as an architecture, but as a philosophy of open, verifiable systems — I can’t help but mention Cartesi.
This is not just another rollup — Cartesi allows you to run full Linux applications in a RISC-V machine, living off-chain, while still maintaining on-chain verification. In other words, Cartesi brings the power of traditional computing stacks to the blockchain world.

Why is this important?

  • RISC-V + Linux = a familiar environment for devs.
  • Off-chain verifiable computations = scaling without security trade-offs.
  • Access to the entire open-source Linux ecosystem = unlimited possibilities for Web3 apps.

Want to build Web3 services with actual computing power like Web2? Look no further than Cartesi.

39

Heh, the post does sound enthusiastic. I just genuinely believe it’s one of the more underappreciated projects in the space.

What caught my attention is the way Cartesi bridges the gap between traditional software development and blockchain. Running full Linux environments inside a verifiable off-chain context isn’t something you see every day. It opens up dev possibilities that aren’t feasible with traditional smart contracts alone.

Most rollups focus purely on scalability — Cartesi adds actual computing flexibility on top of that. So when I saw RISC-V trending again, I thought it was worth spotlighting a project that’s been quietly pushing innovation in that direction for years.

1 Like
41

There’s a bit of an elephant in the room wrt tx privacy imho. I’ll start with an example from web2.

Recommendation engines work by looking at a user’s data - if the user’s YouTube usage was private (from YT), YT wouldn’t be able to recommend content, which many users apparently see as a good thing. Tons of internet denizens applaud what Big Tech does with their data, mainly due to only perceiving the good bits. (If they can be called that, and let’s face it, it is useful sometimes.)

While the airdrop meta seems to have largely faded, it often built on a similar principle. Let’s take Optimism Airdrop 1 as an example. I am picking it because it illustrates my point well, but also because iirc many in the community found its criteria praiseworthy. Looking at the list, DAO voting, multisig signing, and Gitcoin contributions are all listed. Would those be from the same address if we were following good privacy hygiene? There was a bonus for ‘overlap’, meaning a single address that met multiple criteria received an allocation greater than the sum of its parts, which would mean that having separate addresses for the voting, signing, and contributions would not have received as much in aggregate. Even worse, many airdrops took to at least attempting to scout out sybils/airdrop farmers, meaning that one user using fresh addresses for each DAO and multisig might not even reap the benefits of having multiple eligible addresses.

We often want aggregation and signal. The idea of onchain identity to some degree views this as axiomatic. There are almost certainly ways that people can retain a ‘main’ account, and use proofs where necessary to prove their ownership of others privately, but my gut feeling is that this would change the UX in a number of applications, and if made user-friendly, would almost certainly need to be handled by wallets in order to be more intuitive. This itself would still open the door to something similar to the current data consent modals in web2 - imagine “the following dApp would like to view your activity in the following addresses”. How many of us will blindly click through most of the time anyway?

The other issue is just how much metadata txs have. Even if the tx doesn’t originate from the same address, it seems inevitable that there will always be some level of data leakage that in aggregate can be correlated to identify the hidden hand signing the transactions. If they don’t, I wonder if that inherently means sacrificing some of the UX we have today.

I’m hoping for good rebuttals. I want to believe that there can be actual privacy, not just theater, without sacrificing UX.

42

Hey - let me know what you think about the BITE protocol we are working on

43

.املك مجموعه كبيره من ens ولا استطيع السيطره عليها

44

I stopped interacting with the ethereum space back in 2022, major reasons being lack of focus on privacy and lack of focus on real world use cases. This post again does not explicitly mention real world use cases.

I’m currently working on supporting whistleblowers.

Here is what would be helpful IMO for this use case:

  • ethereum browser client or light client that runs on tails over Tor with javascript disabled.
  • an app to publish documents to ethereum blobdata or similar. IMO information is more important than payments.

See also: https://samuelshadrach.com/raw/text_english_html/my_research/us_govt_whistleblower_guide.html

Advanced users only: You can connect your tails setup to Tor instead of keeping it airgapped, purchase ETH using a gift card or similar, wash it using Tornado or similar, then publish your tarball directly to ethereum blobdata. This ensures mirroring to multiple nuclear states without trusting journalists.

45

Hey @vbuterin, as in Europe we deal with GDPR regulation to manage user data and privacy. I published a small blog to envision how GDPR can be addressed in permissionless networks like Ethereum. Have a look here, I look forwaard if what described match your vision: A pathway for GDPR data management & privacy for Ethereum

46

TEEs are not a perfect solution : they can be attacked via side-channels, hardware bugs (like SGX vulnerabilities), or trust issues with hardware vendors

1 Like