Consensus, Execution and Application Layers without IP-Level Privacy - Censorship.wtf

Datamining the audience (0:00)

Everyone in the room has been using an EVM chain in the last 30 days, but there was no RPC users in the room.

When people rely on others' computers to interface with EVM chains, they inherently "trust" them, suggesting there is a common narrative around trusting certain infrastructure/companies to do this.

This is more a question about what "trust" even means in this context - suggesting reliance on others' infrastructure implies trust whether that is merited or not.

What does "trust" even mean ? (1:10)

Trust in this context refers to trusting infrastructure providers like Infura to not censor users. This relies on :

• Free and open source software (FOSS) that can be inspected, modified and self-hosted.
• Standardization through the EIP process enables low switching costs between providers.
• Widespread retail hardware makes self-hosting nodes more feasible.

Light client verification provides another path to trustless operation without self-hosting, and there are multiple providers offering light client verification, such as Helios and kevlar.sh.

Finally, there is the issue of trust to not track all user activity. Strong full stack privacy is necessary because censorship resistance and trustless data delivery lose value if providers can still monitor all actions.

Lack of full privacy (3:30)

We need to agree that user tracking is problematic, otherwise privacy efforts fall apart.

On-chain privacy is needed even with good execution layer privacy. There are leaks of information at the p2p layer with things like solvers, builders, indexers etc.

Validators are not private currently, though there are efforts around single secret leader election (SSLE).

Web2 enforcing policy (4:55)

The old world has some privacy protections like GDPR and CCPA, along with corporate privacy policies. These are enforced because there are identifiable entities behind services.

These old world privacy regulations and corporate policies, implying the blockchain space currently lacks identifiable entities to enforce privacy.

Do you trust random nodes operators ? (5:50)

Decentralization without privacy protections replaces trust in laws/regulations with trusting random node operators not to misuse user data. This makes privacy worse than the centralized world.

Connecting to a non-private EL (6:40)

Non-private execution layers allow node operators to link all your accounts together - PoAP, ENS, savings etc. They can also link accounts to off-chain identities through things like IP addresses.

MEV providers see user activity before the user does - this allows tracking.

How to screw users (8:15)

Let's imagine a fully decentralized Uniswap app using ENS, IPFS, The Graph, and decentralized RPC providers :

1. Attacker runs IPFS nodes to identify active users from their queries.
2. Attacker then runs Graph nodes not to feed malicious data, but to deanonymize the user and harvest their data.
3. By running the Graph nodes, the attacker sees every click and dropdown selection the user makes in the app interface. This allows tracking without traditional web tracking.

The attacker can front run the user's transactions in the mempool of the RPC provider. He can even front run based on the user's gas estimation calls, before the transaction hits the mempool.

This is meant as an example of privacy issues that need solutions as we decentralize web3 stacks, not as disrespect to the projects involved.

What about Consensus Layer Privacy ? (11:00)

Experiment showing validators can be deanonymized by collecting attestation data and linking pubkeys to IP addresses from beacon nodes. This allows targeting validators.

Today's sad state of Ethereum [d]App privacy (11:50)

To illustrate this, Sebastian called out Uniswap's IPFS deployment, which logs wallet addresses linked to device IDs to track users across requests.

Uniswap IPFS deployment logs every button click so developers know exactly what the user is doing and what version of MetaMask they use, exposing potential vulnerabilities.

Uniswap is an exemple not to follow. The main point is that consensus and execution layer privacy issues exist and are actively happening, making user exploitation possible.

Data harvesting (13:00)

The current MEV landscape is essentially a data harvesting MVP, showing the value of mempool data (left slide). This is just a small subset of what's possible in a decentralized system.

As Ethereum tries to attract institutional users, we should consider that institutions like hedge funds already harvest data extremely aggressively.

Sebastian believes exploitative data harvesting by malicious actors is inevitable as things decentralize further. Transport layer data is not tinfoil hat thinking.

Market size (14:25)

Strong privacy is the primary insurance against exploiting every web3 user, whether individuals or institutions. Privacy makes Ethereum safe for all.

The issues initially highlighted around web tracking relate to the application layer. The decentralization arguments relate more to the transport and execution layers. But privacy is needed across all layers.

How to fix (15:00)

• We need to defend core values and call out actors not aligned. Legal support is needed as some teams are afraid to work on privacy features.
• Execution layer privacy tools exist but need more integration and usage.
• Address P2P leaks from things like solvers, builders, indexers via mixnets. Hopper is a mixnet focused on RPC middleware.
• Forced transaction inclusion should happen at the RPC wrapper level, not the user frontend. This enables censorship resistance.
• Consensus layer privacy for validators is still an issue not solved by SSLE. Overall need strong privacy across tags. Latency issues make consensus privacy difficult, so Hopper focused first on RPC middleware over mixnet transport.