This list is good but IMO too narrowly RPC-focused when thinking about data-harvesting third party services. That is ok for a typical Ethereum wallet of 2018, but (sadly!) not anymore. Unfortunately, a contemporary Ethereum wallet pings a prospering jungle of centralized servers and services for:
gas prices
price feeds
tx simulation
scam checkers
gas-less transactions
cross-chain balances
multisigs with off-chain signature services
a range of indexer data, typically for token balances
All of them reveal some level of personal data. Minimally that is “IP 1.2.3.4 is doing something with Ethereum right now” but usually it is much more and much more personal. So I’d say that we need a general purpose anonymous transport layer, beyond just anonymizing simple RPC calls.
Instead of submitting as “pinnaple-green-swordwish” many “normal” users want to have notifications in form “Tim submitted his proposal” (for those who has been granted notion about account connection to the sender identity) but keep the submission private.
Especially in case of on-chain governance this allows better level of UX and reducing halo.
This requires reveal only commit and have 3rd party to host pool of proposals that later is batch revealed, ongoing UX goals for Rankify.it / Peeramid.network looks like this:
Bot: @Bob sent a proposal. // public commitment & signed by Bob and trusted server holding nullifier
Bot: @Alice sent a proposal.
Bot: @Georg hurry up!
Bot: @Georg sent a proposal.
Bot: New proposals: A;B;C; // Server reveals & nullifies pool of proposals
// Voting phase begins <..>
// Tally, posts proofs of data integrity
Bot: Winning proposal was C, it was sent by @Bob
Current plans is to have marketplace for such private pools, enabling users to pick whatever trust guarantees they want (chose between Lit, ICP, TEE, Self hosted MPC etc).
@vbuterin Im having hard time to classify that though, does that fit in your categorization under privacy pools or aggregation?
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.
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.
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
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.
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’!
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.
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.
Thanks @kdenhartog. Yes, that corresponds precisely to how we’d sum it up
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.
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.
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
This is a great idea. Eat up Monero’s market share. ETH developers must be more aggressive. They should also turn the tables on layer 2’s like Base that are causing ETH inflation and not paying their fair share. Layer 1 should just incorporate all the features and cannibalize those selfish, centralized scamchains like base. Base needs to pay a tax or die. Other coins like monero need to be cannibalized. And with MegaETH layer 1 should aim to eat up all the TVL of Solana. Let’s play PacMan!
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.
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.
Hehe, sorry. Been around too long and seen too many of such things so I automatically thought you’d be related to the project.
What I love about RISC-V is that it’s lit a fire beneath the chairs of the L2 leeches like Base from Coinbase. They don’t understand that one must not poison the wells they drink from.
ETH as a token (and therefore Ethereum as a layer 1) needs a stronger force defending it, one that is prepared to “Die on this hill”.
