Increasing the observability of Attestor Censorship - Censorship.wtf

Why censorship is important ? (2:08:55)

• Censorship resistance protects against economic attacks like liquidations for DeFi protocols.
• It enables credible neutrality - not depending on any one jurisdiction's constraints.
• "Meta censorship resistance" means developers building new dapps on the platform cannot be censored. No one can block new smart contracts from being usable.
• If rollup operators or nodes blocked new deployments or contract calls, it would violate this meta censorship resistance.

Censorship resistance is important not only for end users but for unblocking open innovation from developers building on the platform. Monitoring the system for potential issues preserves this quality.

Observability tools help detect if censorship is occurring by monitoring transactions and identifying anomalies.

Time to Censorship Resistance (2:10:50)

Censorship resistance is not binary. Instead of talking about consored transactions or not, we'd rather talk about "time to censorship resistance (TCR)".

It matters how long an honest, properly paid transaction takes to get included :

• Short fraud proof periods may expire before a censored transaction confirms.
• The time to confirm impacts economic efficiency - like capital requirements for optimistic rollups during settlement lag.
• It affects risk parameters like overcollateralization factors for stablecoin protocols based on liquidation timelines.

The temporal dimension of censorship resistance has broad implications for usability, innovation, credible neutrality, and economic efficiency.

Difficulty with punishing for censorship (2:12:45)

The goal of Ethereum is to be resilient beyond majority trust - not to just trust that a majority of validators will be honest. In a pseudonymous world, it's not robust to assume a majority of validators will be honest since their identities are unknown.

There are two key aspects in building resilient distributed systems :

• Safety (confirmed transactions should not get reversed)
• Lack of censorship (validators colluding to prevent transactions).

To punish validators that collude to attack protocol Safety, Ethereum uses slashing and this is easily attributable.

However, censorship through collusion is much harder to conclusively identify and attribute. There is no clear way for the protocol to definitively know if collusion and censorship occurred.

Types of censorship

Proposer censorship (2:15:30)

Proposer censorship is easy to solve. Just 5% of honest block proposers can mitigate this by following protocol to include transactions. This provides enough censorship resistant throughput, albeit reduced.

Hence the Ethereum community emphasizes solo stakers - even a few honest validators can solve proposer censorship.

Attestor censorship (2:16:45)

Attester censorship is harder to address. If 33% of validators collude and refuse to build on blocks with certain transactions, they can effectively censor those transactions by not allowing that chain to grow.

This is done intentionally for various reasons. There are "uncle" blocks that get created but don't make it to the main chain.

What can we do about this ? (2:18:00)

Ethereum's LMDGhost protocol provides some observability into potential censorship by having a liveness and safety layer.

You can see a pattern of uncle blocks not getting attested. However, it's unclear whether these are due to intentional censorship or just network latency.

So censorship remains difficult to attribute and address on-chain.

"Revere", a tool to solve attestor censorship

How it works (2:20:00)

A proposed mechanism called "revere" aims to address attester censorship in Ethereum.

It involves a transaction inclusion rule : when proposing a block, validators must include recent valid transactions from uncle/unattested blocks that haven't already been included.

By observing if those transactions do get included eventually, nodes can infer whether censorship occurred or if an uncle block was just due to network latency :

• If transaction eventually included, likely just latency
• If transaction never included subsequently, indicates intentional tester censorship

This inclusion rule enforces a social consensus that enables detecting censorship by observing blockchain structure.

Light clients enhance observability (2:22:30)

To propagate this information, enhance light clients to sample unattested/uncle blocks in addition to main chain blocks.

This allows most nodes to observe block proposing patterns and identify potential censorship, even without transaction data.

Once light nodes testify censorship is happening, strong social consensus enables slashing validators for attester censorship.

So light clients can help monitor the commons and ensure validators follow expected behavior, in addition to just verifying validity for themselves.

Back to TCR (2:25:00)

If a transaction gets censored beyond a certain time threshold, the validators/attesters responsible should face slashing penalties.

Along with an assumption that some fraction of block proposers are honest, this approach allows providing economic guarantees on censorship resistance. If censorship persists beyond a point, observable patterns make it possible to coordinate multilateral slashing of a majority of colluding validators.

This aligns with Ethereum's roadmap wherein block building may get centralized but block proposing can remain decentralized. Even if most proposers centralize, having highly decentralized light clients acting as watchdogs ensures bad actors and censorship attempts can be penalized via slashing.