VItalik's blog post "Don't overload Ethereum's consensus" from May 21, 2023 talks about a problem that actually isn't very new in blockchain science.

The easiest way for me to describe the problem is by referring to the drivechains debate. Drivechains are a type of sidechain that allows Bitcoin miners to use their hashrate to lock and unlock coins on the mainchain when they're sent to and from the drivechain. Almost all types of sidechains in existence require trust in a permissioned set of key holders, but drivechains are a directionally "decentralized".

It's sort of a holy grail in Bitcoin-world because it would allow the BTC asset to function on any sidechain blockchain, which means you could use BTC in a Zcash-style blockchain for near-ideal privacy, or anything that you'd like.

The big issue—and one of the major reasons drivechains have not been adopted yet—is that miners can in fact steal all the coins in a drivechain. Paul Sztorc, the inventor, has therefore designed the protocol in such a way that it would take miners months to move the coins out of a drivechains, miners all need to vote incrementally on where they want the coins to be sent in a transparent manner, so that the drivechain users and Bitcoin users have time to react.

The idea is that Bitcoin users will prevent the attack by softforking the Bitcoin mainchain.

This is where the idea starts to break down to some. The whole purpose of sidechains is to isolate the sidechain's problems to the sidechain. The moment your design requires intervention by the mainchain users, you posit that mainchain users should be paying attention to and arbitrate issues in a sidechain.

Thus, if you have an Ethereum-style drivechain with a lot of complexity inside it and there is a bug or a consensus dispute, it now becomes the Bitcoin mainchain users' problem to look into whether funds are being moved suspiciously and whether this is the result of a drivechain-level conflict or theft by malicious Bitcoin miners (and whether they should be stopped via softfork!).

Ethereum-complexity now becomes Bitcoin-complexity! Bad design pattern.

You can imagine how resisting changes that enable this design pattern is the more prudent choice. Imagine hundreds of different drivechains, each with their own set of unique peculiarities, all having their chain-specific problems leak into the dialogue of Bitcoin consensus. This is a textbook guide to "overloading Bitcoin's consensus". As a result (of this issue and a plethora of other political issues), it is not possible to build drivechains on Bitcoin today—the necessary opcodes have not been enabled.

Vitalik's blog post is simply an attempt to classify a bunch of different ongoing experiments and ideas in Ethereum (such as EigenLayer restaking) by the degree to which they introduce this very specific, social consensus problem.

"If [...] you have the intent to rope in the broader Ethereum ecosystem social consensus to fork or reorg to solve your problems, this is high-risk, and I argue that we should strongly resist all attempts to create such expectations."

How might Chainlink be a part of the solution?

Chainlink by itself cannot solve the problem. If we allow Chainlink oracles to decide what is true and what is not true inside a separate system, like a Bitcoin drivechain or an Ethereum Layer 2 protocol, then these systems ceases to be Layer 2 protocols entirely and become Chainlink-permissioned sidechains instead.

However, as your question rightly posits, Chainlink could be a part of a solution.

Backstop: If we take the example of a drivechain, we could design the system in such a way that miners can be backstopped by Chainlink oracles when moving drivechain funds, instead of involving mainchain consensus in the conflict as the next go-to option. Miners would effectively need Chainlink oracles' permission to move funds out of the drivechain, ontop of hashrate.

1-of-N security: A better example where Chainlink oracles can be helpful is in acting as watchtowers for optimistic rollups. In an optimistic rollup, the same type of theft as described in the drivechain case can be proven and stopped automatically by mainchain nodes when they're presented with the right information (a fraud proof). Adding Chainlink oracles to the list of entities with the responsibility of monitoring the rollup for fraud and submitting it to the mainchain is completely an additive security measure. The Chainlink oracles don't even need to agree on a median value for it to work—as long as a single Chainlink oracle (1-of-N) reports on fraud correctly, an attack is stopped.

---

I would not recommend to use Chainlink oracles to backstop a drivechain, because it gives Chainlink oracles the power to freeze funds inside the drivechain, and Chainlink oracles and miners can still collude to steal funds. In general, layering security via a bunch of different backstops can often introduce more problems than it solves.

However, I see no downsides in adding Chainlink oracles as watchtowers to a fraud provable system like an optimistic rollup.

---

Chainlink cannot save all blockchains from having their consensus overloaded. Even if Chainlink can alleviate a problem, what happens when Chainlink fails? As soon as you layer one system ontop of another or make one system depend on another, there is always the risk that problems in the first system will leak into the second.

Chainlink can help to automate arbitration so that social intervention is required less frequently, but if applied incorrectly, it can cause more frequent need for social intervention.

Note: When I talk about "Chainlink" here, that refers to Chainlink as it currently works (including Chainlink v0.1 staking). Furthermore, for those who have read my "What’s Wrong With the Chainlink 2.0 Whitepaper? (For Simpletons)" blog post on Medium, you'll know that I don't expect to treat future versions of Chainlink as fundamentally different from the system that exists today either.

P.S. I actually like drivechains.