See previous work: Censorship rejection through "suspicion scores"
See also as background: https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html
We can use the 99% fault tolerant consensus algorithm described above by having it constantly run “in the background”, to create a consensus on what data was broadcasted at what times, and therefore what data the main chain is maliciously failing to include.
Using old finalized blockchain state as a source of validators and entropy, we agree on a sequence of validators, V[1], V[2]…, where each validator is assigned to a slot (eg. of 1 minute length). Let [G + D * x, G + D * (x+1)] be the time interval associated with slot x. At time G + D * (k * 100), any validator in V[k * 100] ... V[k * 100 + 99] can publish a message (h, sig(h)) for any hash h of a block that they saw in the previous interval of 100 * D seconds. Over the next 100 periods, the 99% fault tolerant consensus protocol runs: any validator in that set, upon receiving a value v with n signatures with some hash h that they did not yet sign off on, checks if the time is less than G + D * (k * 100 + n), and if it is then it publishes (v, sig(v)) with their own signature.
Clients watching this process accept a block with hash h as having been published within a given slot if they see the block and they see a message with n signatures before time G + D * (k * 100 + n - 0.5). There is a proof (see blog post) that, if the network latency assumption is correct, clients will agree on which blocks were published during what interval. Now, we can socially agree on a definition of “censorship” (eg. if a block was published during interval k, and was not included in a chain that was published after interval k+1, then that chain is censoring that block), and coordinate on rejecting majority chains that are censoring, and coordinate on a minority soft fork to get around the attack.