Charles Hoskinson’s defense of leaning on hyperscalers at Consensus Hong Kong crystallized a growing rift in how the blockchain community defines “decentralization”: is it a purely
cryptographic property, or must it also be realized in the physical infrastructure that runs proofs, validators, and prover fleets? At the conference Hoskinson argued that advanced cryptography—multi‑party computation (MPC), confidential computing (trusted execution environments, or TEEs), and zero‑knowledge proofs—can neutralize the centralization risk of using cloud providers such as Google Cloud and Microsoft Azure. That position is defensible in theory, but when you unpack the engineering, operational, and geopolitical realities beneath those assurances, serious and practical vulnerabilities remain. The debate isn’t about whether cryptography is powerful enough; it’s about where the lines of control actually live and how brittle an otherwise cryptographically neutral protocol becomes when its off‑chain plumbing is concentrated in a few hyperscale hands.
Background / Overview
The recent announcements around Cardano’s
Midnight privacy partner chain—its planned mainnet timeline, federated starting operators, and named infrastructure partners—turned an abstract debate into a concrete one. Midnight is explicitly a model that moves heavy, privacy‑preserving computation off‑chain, produces succinct cryptographic proofs, and records only the proofs on a neutral coordination layer. That architecture is increasingly popular: verifiable compute (ZK proofs, validity proofs, Succinct-style provers) shifts the expensive work off L1 and posts compact attestations on chain. Provers and proving services therefore become a new trust surface: who runs them, where they run, and under what governance? Hoskinson answered this by saying the world needs hyperscaler horsepower to make privacy and ZK‑based workloads practical at global scale—and that cryptography and confidential computing can preserve trust even when that horsepower lives in hyperscaler data centers.
That position has a logic: modern L1 designs increasingly separate execution, data availability, and consensus; verifiable computation lets execution be outsourced and verified cheaply. But outsourcing creates new dependencies. If off‑chain proving infrastructure sits predominantly inside hyperscaler clouds, then cloud control planes, networking policies, and regional availability become part of the system’s attack surface—not only for classic outages but for throttling, censorship, or jurisdictional interference. Real resilience therefore requires more than cryptographic neutrality; it requires distributed, pluggable infrastructure that resists vendor lock‑in.
What MPC and Confidential Computing Actually Buy You
Multi‑party computation: stronger cryptography, harder operations
Multi‑party computation protocols split secret material and processing among multiple parties so that no single host ever sees the full secret. This is a powerful primitive for reducing single‑point compromise in wallet key management, threshold signing, and collaborative private computation.
- Strengths
- Eliminates single custody of keys or secrets.
- Enables threshold signing and policy‑driven key usage without exposing raw keys.
- Mature tooling exists for many use cases (threshold ECDSA/Ed25519, private set intersection, private ML inference).
- What it does not hide
- MPC shifts trust from a single vault to the coordination plane: the communication fabric, session bootstrap, liveness of leader committees, and the software/hardware stack of all participating parties. That increases operational complexity and surface area. Practical MPC implementations face real tradeoffs in latency, bandwidth, and failure modes—especially as the number of participants grows. The academic and industry literature is explicit about MPC’s scaling and round‑complexity costs.
In other words, MPC replaces a single concentrated vulnerability (one private key on one host) with a distributed set of interdependent components that must all be correct and available. Secure in theory, brittle in practice unless the coordination and governance layers are engineered for real‑world fault and attack models.
Confidential computing and TEEs: a narrower but still real boundary
Trusted execution environments—Intel SGX, AMD SEV, ARM TrustZone, and hyperscalers’ managed confidential compute offerings—encrypt data while it’s being processed and aim to reduce the trusted code base. They are attractive: if a hyperscaler can attest it is running your code inside a hardware‑protected enclave, you can run private workloads on cloud hardware with stronger guarantees than ordinary VMs.
- Strengths
- Protects secrets in use, not just at rest or in transit.
- Enables regulated workloads to run in familiar cloud environments while retaining some privacy guarantees.
- When combined with remote attestation, allows third parties to verify the expected runtime and binary.
- Important limits
- TEEs are built on microarchitectural behavior and firmware; history shows these assumptions can be broken. Attacks such as Foreshadow/L1TF, Spectre/SMT side channels, LVI (Load Value Injection), and SEVered demonstrate that TEEs can leak keys or be subverted. Patches and mitigations have helped, but they often carry performance or deployment tradeoffs—and some classes of side‑channel risk are fundamental to contemporary CPU designs. The research corpus is large and consistent: enclaves narrow the attack surface, but they do not produce an impenetrable island.
A second, practical limit: attestation and sealing depend on hardware vendors and hypervisor stacks. If an enclave’s attestation key is compromised, or if a platform’s microcode is patched away, the attestation guarantees can change. That makes long‑term trust in hardware attestation something that should be
continuously audited and rotated—not a one‑time checkbox.
The Hyperscaler Control Plane: The Operational Reality
Even when cryptography and TEEs are working as designed, hyperscalers retain powerful levers that cryptography can’t cryptographically neutralize.
- Hyperscalers own the physical hardware, the hypervisor, the networking fabrics, and the inter‑region backbone that delivers traffic. They manage firmware and supply chain updates.
- They operate the management and control plane APIs that permit creating, starting, stopping, or migrating VMs and containers.
- They are capable of throttling throughput, imposing egress limits, applying access policy changes, or selectively suspending services for reasons ranging from security incidents to legal orders.
These levers are consequential in practice. Mass outages at major clouds are not theoretical: the June 12, 2025 Google Cloud / Cloudflare incidents produced widespread impact across consumer and enterprise services and illustrated how a single underlying failure or policy misstep can cascade across global services. Outages interrupt proof generation, validation pipelines, indexers, and wallets—often with real‑money consequences and degraded resilience.
Hyperscaler control matters not only for accidental outages. It matters for policy and jurisdictional interventions. A cloud provider compelled by local law enforcement, export controls, or sanctions can remove or limit compute capacity in a jurisdiction—an action that cryptography alone cannot prevent. In short: cryptography may stop inspection, but it cannot eliminate capacity control, network policy, or the geopolitical reach of a cloud vendor.
Off‑chain Compute Is the New Trust Cornerstone
Hoskinson’s point that “no Layer‑1 network can economically provide global compute at hyperscaler scale” is technically accurate but misframes the key question. The modern architecture of many privacy and scaling approaches explicitly offloads heavy work to off‑chain provers and verifiers. The essential question is not whether L1s are fast enough; the question is
who controls the off‑chain execution environment.
Zero‑knowledge proving networks, prover marketplaces, and verifiable compute fleets are the workhorses of this design. These services accept computational work, produce compact ZK proofs or validity attestations, and submit those proofs to the chain. That model allows L1s to remain compact and auditable while enabling heavy workloads. But it also concentrates the new trust: if a single company or a small set of providers produce most proofs, they can become the practical gatekeepers of throughput and censorship resistance. The chain’s protocol rules remain neutral; the ecosystem’s practical behavior will be determined by the off‑chain population of provers.
Strengths of the Hyperscaler+Crypto Approach
It’s important to be fair: there are strong, practical reasons why builders reach for hyperscalers today.
- Economics and scale: Hyperscalers provide vast, elastic compute pools and global POPs that are hard to replicate at startup scale. For enterprise adoption—banks, healthcare, or telecommunication use cases—enterprise‑grade SLAs and regional presence matter.
- Operational maturity: Managed identities, hardware attestation services, continuous patching, and secure supply chain practices are mature offerings that reduce go‑to‑market friction.
- Bridging for adoption: Hyperscalers act as accelerators—reducing friction for institutional on‑ramps and enabling early production workloads that prove the model before decentralized capacity is fully realized.
Those are real and nontrivial advantages. They explain why many ecosystems opt for a pragmatic, “use the cloud as a launchpad” model. Yet they also frame the central tradeoff: accelerate adoption now at the risk of institutionalizing a dependency that undermines long‑term resilience.
Risks, Attack Scenarios and Failure Modes
Here are the concrete risks that follow from concentrating off‑chain compute in hyperscalers:
- Cascading availability failures. Cloud control plane or regional networking incidents can halt proof generation or node participation, creating localized or global liveness issues for client applications. The Google Cloud/Cloudflare outages of 2025 are an illustrative example.
- Policy and censorship vectors. Cloud providers may be compelled to suspend services in a jurisdiction or to comply with lawful data‑access requests, potentially blocking certain classes of transactions or prover operations.
- Attestation and hardware trust decay. TEEs can and have been demonstrated to leak secrets through side channels; firmware and microcode changes can alter attestation guarantees. Long‑lived reliance on any single vendor’s attestation model is a brittle trust assumption.
- Coordination fragility in MPC. MPC deployments produce complex dependency graphs—session managers, commit phases, gossip networks—that become attack surfaces for denial, replay, and man‑in‑the‑middle interference. Scaling MPC from tens to thousands of participants magnifies these risks and costs.
- Concentration of prover economics. If a handful of large providers internalize the majority of proof generation because of cost or latency advantages, they control effective throughput and can impose commercial or technical constraints that affect neutrality.
In short, we trade one form of centralization (L1 control) for another (infra and prover control). Cryptography that promises
neutrality will not by itself eliminate this second type of concentration.
What True Resilience Looks Like: Practical Requirements
If decentralization is a property of the full stack—not just the consensus or ledger layer—then resilient designs must address both cryptographic fairness and infrastructure diversity. Key, actionable principles:
- Make hyperscalers optional accelerators, not sole providers. Design protocols so that cloud‑based provers are interchangeable with independent provers. Avoid early mechanisms that lock protocol functionality behind a single provider API or attestation format.
- On‑chain anchoring of proofs and receipts. Store, distribute, and verify not only proofs but provenance records on neutral ledgers. Keep attestations short, verifiable, and auditable by any node without dependence on opaque vendor services. This ensures that even if a provider disappears, the chain retains verifiable history.
- Open, multi‑vendor attestation registries. Create a decentralized registry of attestation roots and firmware/TPM measurements so that verifier logic can accept proofs from many hardware attestation ecosystems, not just one vendor’s signed quote.
- Economic incentives for prover diversity. Embed mechanisms that reward geographical and operator diversity. Subsidize smaller provers with initial reward curves, or use reputation systems that weight results by operator distribution.
- Multi‑cloud & sovereign cloud strategies for critical services. For systems that require high availability, run redundant proving pipelines across multiple hyperscalers and independent co‑located hosts. Encourage sovereign cloud or colocation alternatives in sensitive markets to reduce single‑vendor geopolitical exposure.
- Continuous independent validation. Third‑party monitors should continually audit prover outputs, attestation logs, and enclave telemetry to detect drift, misconfiguration, or unusual failure patterns.
- Short attestation lifetimes and key rotation. Avoid designing systems that rely on immutable long‑term hardware attestations; rotate keys, rotate attestation roots, and require re‑attestation for long‑lived services.
Implementing these measures is neither free nor trivial. They require careful protocol design, extra engineering, and short‑term economic compromises. But they shift systems away from brittle dependencies toward verifiable resilience.
Design Patterns and Technical Options
Below are concrete patterns builders should consider when they accept hyperscalers as part of a broader decentralization strategy.
- Hybrid prover mesh
- Deploy a prover mesh that mixes hyperscaler nodes, independent data center nodes, and edge devices.
- Use work‑allocation strategies that avoid single‑provider bottlenecks, and design auction or reputation mechanisms to encourage diversity.
- Decentralized attestation translation
- Support multiple attestation formats and provide translation layers so enclaves from different vendors can be verified by the same smart contract logic.
- Use open provenance logs for firmware/BIOS/TPM revisions.
- Proof escrow + on‑chain fallback
- Maintain an on‑chain escrow or compact checkpoint that proves a recent state can be reconstructed without contacting a specific provider. If a provider goes offline, other provers can reconstruct and reprove state against the escrow snapshot.
- Interoperable ZK proof standards
- Encourage interoperable proving interfaces (serialization, verification opcodes, precompiles) to reduce vendor lock‑in for proof generation and verification.
- Multi‑party attestation quorum
- Instead of trusting a single remote attestation quote, require a quorum of independent attestation statements (hardware + software stack snapshots) before accepting critical operations.
Case Studies & Precedents
- The June 2025 Google Cloud/Cloudflare incident demonstrated how cloud/control plane failures can cascade into broad outages across services that many users treat as independent. That outage is a practical illustration of the liveness risk that hyperscaler dependence introduces.
- The corpus of TEE research—Foreshadow, LVI, SEVered and many others—shows that hardware assumptions can and have been broken, occasionally with devastating impact on enclave confidentiality. These cases reinforce that TEEs are a narrower trust boundary, not an impenetrable wall.
- Academic and industry treatments of MPC and confidential computing repeatedly call out scaling and operational costs: MPC works well for small committees and guarded use cases, but running MPC at hyperscale for global proof generation or low‑latency signing requires careful design and often yields tradeoffs in latency and resilience.
Practical Roadmap for Builders and Protocols
If you’re building a privacy‑preserving chain or an off‑chain proving layer today, here’s a pragmatic roadmap to balance performance and resilience.
- Short term (0–6 months)
- Identify critical off‑chain services and document their failure modes.
- Enable multi‑region and multi‑cloud deployment testing for proof pipelines.
- Define attestation and proof metadata standards so that operators can be swapped with minimal friction.
- Medium term (6–18 months)
- Launch incentive programs for independent prover operators (grants, bootstrapped rewards).
- Implement attestation registries, rotation policies, and independent audit hooks.
- Add fallback on‑chain checkpoints and light reconstruction proofs.
- Long term (18+ months)
- Build decentralized prover markets with true economic diversity.
- Evolve governance to require geographic and vendor distribution metrics for critical infrastructure.
- Fund research into enclave‑agnostic verifiable compute (reducing reliance on a single TEE family).
Conclusion: Dependence Is the Vulnerability
Charles Hoskinson’s defense of hyperscalers is defensible as a pragmatic, staged approach to delivering privacy and scale to real customers. Hyperscalers provide the horsepower and operational primitives that make zero‑knowledge and confidential computing practical today. But the gloss that cryptography alone removes all centralization risk is misleading.
- MPC and TEEs reduce some attack classes, but they introduce new operational, coordination, and hardware trust assumptions that must be explicitly managed.
- Hyperscalers control non‑cryptographic levers—capacity, networking, policy, and firmware—that cryptography cannot neutralize. The 2025 hyperscaler outages are a practical reminder that availability and policy risk are real and consequential.
- The solution is not to avoid hyperscalers entirely, nor to accept them as permanent gatekeepers. The sustainable model treats hyperscalers as optional accelerators—valuable for burst and global reach—while anchoring settlement, proof storage, and core verification in decentralized, vendor‑agnostic infrastructure. Verifiable compute markets, interoperable attestation, and economic incentives for operator diversity are the practical levers that will preserve the protocol promise of neutrality in practice, not just in theory.
Decentralization must be reclaimed as a
full‑stack property. That means designing systems that are cryptographically fair and operationally redundant; that make it easy to swap providers; and that reward geographic, hardware, and governance diversity. Only then will blockchain systems remain resilient not only to cryptographic attacks but to the real‑world risks of outages, policy pressure, and hardware trust decay.
Source: tokenpost.com
Blockchain Decentralization and the Hyperscaler Dependency Problem - TokenPost