The blockchain trilemma reared its head once again at Consensus in Hong Kong in February, which, to some extent, put Cardano founder Charles Hoskinson on the backfoot – having to reassure attendees that hyperscalers like Google Cloud and Microsoft Azure No Threat to decentralization
The point was made that major blockchain projects need Hyperscalers, and one should not be concerned about a single point of failure because:
- Advanced cryptography neutralizes risk
- Multiparty computation delivers key content
- Confidential computing shields data in use
The argument was based on the idea that ‘if the cloud cannot see the data, the cloud cannot control the system,’ and was left there due to time constraints.
But there is an alternative to Hawkinson’s argument in favor of hyperscalers that deserves more attention.
MPC and confidential computing reduce exposure
In Charles’s argument this was somewhat of a strategic stronghold – technologies such as multi-party computation (MPC) and confidential computing ensure that hardware providers will not have access to the underlying data.
They are powerful tools. but they don’t do this Eliminate inherent risk.
MPC distributes key material among multiple parties so that no single participant can reconstruct a secret. This significantly reduces the risk of a single compromised node. However, the protection surface extends in other directions. The coordination layer, communication channels, and governance of participating nodes all become important.
Instead of relying on a single key holder, the system now relies on a distributed set of actors behaving correctly and protocols being implemented correctly. Not a single point of failure is eliminated. In reality, it simply becomes a distributed belief surface.
Confidential computing, especially trusted execution environments, introduces a different trade-off. Data is encrypted during execution, which limits exposure to the hosting provider.
But trusted execution environments (TEEs) depend on hardware assumptions. They depend on microarchitectural isolation, firmware integrity, and correct implementation. For example, the academic literature, here and here, has repeatedly demonstrated that side-channel and architectural vulnerabilities continue to emerge in enclave technologies. The security boundary is narrower than that of the traditional cloud, but not perfect.
More importantly, both MPCs and TEEs often operate on top of hyperscalar infrastructures. The physical hardware, virtualization layer, and supply chain remain centralized. If an infrastructure provider controls access to machines, bandwidth, or geographic areas, it retains operational profits. Cryptography can prevent data inspection, but it does not prevent throughput restrictions, shutdowns, or policy interference.
Advanced cryptographic tools make specific attacks harder, but they still do not remove the risk of infrastructure-level failure. They simply replace a visible concentration with a more complex concentration.
‘No L1 can handle global computation’ argument
Hoskinson said hyperscalers are necessary because no layer 1 can handle the computational demands of global systems, referencing the trillions of dollars that have helped build such data centers.
Of course, Layer 1 networks were not built to run AI training loops, high-frequency trading engines, or enterprise analytics pipelines. They exist to maintain consensus, verify state changes, and provide durable data availability.
He is right on what layer 1 is for. But global systems primarily require results that anyone can verify, even if the calculations were done elsewhere.
In modern crypto infrastructure, heavy computations increasingly occur off-chain. What matters is that the results can be proven and verified on chain. This rollup is the foundation of zero-knowledge systems and verifiable compute networks.
Focusing on whether L1 can run global computation misses the main issue of who controls the execution and storage infrastructure behind the verification.
If computations occur offchain but rely on centralized infrastructure, the system achieves centralized failure mode. Settlement remains decentralized in theory, but the path to producing legitimate state change is centralized in practice.
The issue should be about dependencies at the infrastructure level, not about computational capacity inside Layer 1.
Cryptographic neutrality is not the same as participatory neutrality
Cryptographic neutrality is a powerful idea and Hoskinson uses it in his argument. This means that the rules cannot be arbitrarily changed, hidden backdoors cannot be introduced and the protocol remains fair.
But cryptography goes on Hardware.
That physical layer determines who can participate, who can do so, and who can opt out, as throughput and latency are ultimately constrained by the actual machines and the infrastructure they run on. If hardware production, distribution, and hosting remain centralized, participation becomes economically limited even if the protocol is mathematically neutral.
In high-compute systems, the hardware is the game-changer. This determines the cost structure, who can measure, and flexibility under censorship pressure. A neutral protocol running on a centralized infrastructure is neutral in theory but hindered in practice.
Priority should be jointly shifted towards cryptography various Hardware Ownership.
Without infrastructure diversity, neutrality becomes fragile under stress. If a small group of providers can limit workloads, restrict regions, or impose compliance gates, the system gets their advantage. Rule fairness alone does not guarantee participation fairness.
Specialization trumps generalization in compute markets.
Competing with AWS is often seen as a question of scale, but even this is misleading.
Hyperscalers optimize for flexibility. Their infrastructure is designed to handle thousands of workloads simultaneously. Virtualization layers, orchestration systems, enterprise compliance tooling, and elasticity guarantees – these features are strengths for general purpose compute, but they are also cost layers.
Zero-knowledge provable and verifiable computations are deterministic, compute-intensive, memory-bandwidth constrained, and pipeline-sensitive. In other words, they reward expertise.
A purpose-built proven network competes on per dollar proof, per watt proof and per latency proof. When hardware, prover software, circuit design, and aggregation logic are vertically integrated, efficiency is compounded. Removing unnecessary abstraction layers reduces overhead. Continuous throughput on persistent clusters outperforms elastic scaling for narrow, continuous workloads.
In compute markets, specialization consistently outperforms generalization for stable, high-volume tasks. Optimizes for AWS optionality. A dedicated proven network optimizes for a class of tasks.
The economic structure is also different. Hyperscalers price for enterprise margins and wide demand variability. A network aligned around protocol incentives could refine hardware differently and adjust performance around sustained use rather than a short-term rental model.
Competition becomes about structural efficiency for a defined workload.
Use hyperscalers, but don’t depend on them
Hyperscalers are not the enemy. They are efficient, reliable, and globally distributed infrastructure providers. The problem is dependency.
A flexible architecture uses major vendors for burst capacity, geographic redundancy, and edge delivery, but it does not anchor core functions to a single provider or a small group of providers.
Settlement, final validation, and availability of critical artifacts must remain intact even if the cloud region fails, the vendor exits the market, or policy constraints tighten.
This is where decentralized storage and compute infrastructure becomes a viable option. Evidence artifacts, historical records, and validation inputs should not be withdrawn at the discretion of the provider. Instead, they should reside on an infrastructure that is economically compatible with the protocol and that is structurally difficult to shut down.
Hyperscalers should be used as a optional An accelerator rather than something fundamental to the product. The cloud may still be useful for access and explosion, but the ability of the system to continue producing proofs and the verification it depends on is not determined by any one vendor.
In such a system, if the hyperscaler disappeared tomorrow, the network would only slow down, because the parts that matter most are owned and operated by the broader network rather than rented from some big-brand chokepoint.
This is a way to reinforce the decentralization ethos of crypto.