I think we agree that there must not be a world where all nodes prune history. So, for many reasons other than UTXO, we rely on some nodes keeping history. Then the question is more how does a user check if there are utxos. One option is using a wallet. Very similar to what other chains are doing, e.g. zcash, mondero or bitcoin, one can have a lightclient baked into the wallet, and use the p2p to request utxos filtered by recipient from archive/full nodes.
Very similar applies to privacy protocols where users also need to reconstruct trie leaves to create the proof against a recent merkle root. I see the problem more in the fact that we donāt have node types that are lightweight (partial stateful) while allowing you to still sync utxos for certain filtered recipients - but this is something that can be built - weāre super early with this proposal.
I think there are two separate gaps here worth keeping apart, because one is buildable and one is a genuine trade.
Discovery vs. privacy (the deeper one). The light-client model you describe, filtering UTXOs by recipient over p2p, works for transparent payments but breaks exactly in the stealth-address case the proposal highlights. Any query efficient enough to find my money identifies whatās mine to whoever serves it. The alternative is downloading everything and scanning blind, which is why the chains you cite as precedent have famously heavy wallet sync. That trade canāt be incentivized away, only mitigated (scannable hint tags, viewing keys, filter downloads). The concern: the openings format chosen now decides which mitigations remain possible later. Itās a one-way door disguised as an implementation detail. Does the spec need to reserve room for a detection hint today, even if unused?
Retention (the solvable one). āSome nodes will keep openingsā currently has no answer to why they would. But the fix can be built from parts already in the proposal: escrow a tiny retention bounty at UTXO creation, claimable by whoever furnishes the opening at spend, verified against the openings root youāre already committing per block. Creator-pays internalizes the cost where it belongs, the bounty travels with the UTXO, and as a bonus it prices dust-minting griefing out of existence. Spender-pays retrieval fees or staked custody challenges are alternatives, but creator-pays needs the least new machinery.
Retention is unclaimed design space; discovery is an inherent tension. Separating them seems useful before the format sets.
Stealth addresses can be complementary and useful but I donāt see it having the same properties. If following ERC-5564 as intended, then you still see the full flow of transactions. A mixer or shielded pool has to eventually be used to break the link from sender. In the shielded pool example I shared however, nothing would be revealed at all. Not sender, recipient, nor amount.
Now if data is not in object but one can bundle transactions here, then yes true compromises can be made to achieve some level of parity. For the shielded pool example, you could technically emit an event log that includes the additional data. The problem with that though is it becomes much costlier and complicated to prove client-side in a zkSNARK. Another option to avoid that is instead hash that data as a commitment and insert into a separate merkle tree in a smart contract. Then in the zkSNARK, I am proving the inclusion of both UTXO note and its corresponding commitment in their respective trees. Thatās quite fast and cheap to do client-side but tradeoff would be high gas cost of each commitment inserted into the separate merkle tree. There are ways to make it more gas efficient but still unideal. Compared to both of those options, just having data in the UTXO object would be much simpler and cost-efficient.
To counterpoint my escrow example, that also can be bundled with a transaction to some smart contract that maps UTXO note to an unlocked_at timestamp and then later escrow address can check it as a verify frame and release funds as new UTXO note to recipient. I donāt know if thereās anything to gain from using native UTXOs for that specific use-case, even if its a sort of private escrow, if it has to update state in another smart contract. Iāll admit though, the escrow example was only to prove multiple use-cases open up with data included. I think there can be many more.
Also, I donāt think a verifier would need to be enshrined for this. From my understanding of EIP-8141, you can verify an zk proof in a frame. If that is false, then it would be an incredible bummer.
Agree, and your data field solves a second problem too: discovery. Once flows are stealth or shielded, filter-by-recipient breaks by design, and wallets either reveal themselves to a serving node or trial-scan everything, which is why Zcash/Monero sync is so heavy. Every known mitigation needs the same thing: a small scanning aid attached to each output. The cheapest, a view tag Ć la EIP-5564, is one byte per payment for roughly 256x faster scanning with negligible leak.
That aid and your encrypted note are just different payloads for one slot. So the unified ask is small: one variable-length, versioned, protocol-opaque data field in the opening. Costs a length prefix now; adding it after deployment is an encoding fork. Two independent use cases converging on the same field before the spec is final seems like good evidence itās structural.
WIP EIP-8304 could be a better fit to prevent false-positive cases and get a client-side log completeness proofs for free. The problem with historical data still stands as system contract would only keep roots for ~30 days.
But realtime client-side logs indexing currently is indeed unrealistic and even existing projects that utilize ERC-5564 changed their architecture to not use logs for discovery.
The other potential area of research could be PQ-secure implementations of stealth addresses and this proposal working together. As ecdh magic would just stop working at some point of time
Yes, 8304 would be great and UTXOs as a use case strengthens the case for shipping it.
I do think history != history. E.g. we could still prune all of what we call history today, but parse the UTXO event logs and keep them. Like, treat them specially, at least on an opt-in basis for example.
Opt-in retention still has the altruism problem: it works for data someone already wants and fails for the long tail, which is exactly the data most at risk. Thatās what a creation-time bounty solves: each UTXO carries a small fee that goes to whoever kept its data around when itās finally spent. Storage becomes a paid job instead of a favor. Special treatment needs a payer, not a volunteer.
We are storing the roots of a tree (or any accumulator) per block. So after spending that UTXO, canāt we zero-out its commitment and update the tree? So, now if I try to spend a zero leaf/utxo, the protocol rejects?
Also, stealth addresses will be a great use case here. I think the biggest bottleneck will be discovery of the notes/payments. The discovery mechanisms implemented so far across different protocols still degrade the user experience. A viable solution solution could be borrow research from ZCash Tachyon projectās efforts.