Introduction

In this article, we discuss the decentralization, security and scalability tradeoffs among multiple technologies in the field of decentralized computing.

The Blockchain Trilemma

Vitalik Buterin introduced the blockchain scalability trilemma. Generally speaking, the trilemma says that simple blockchain architectures can only get two of the following three properties: decentralization, security and scalability.

• Scalability: High transactions per second (TPS)
• Decentralization: Anyone can participate in consensus, no small set of trusted parties
• Security: The chain can resist a large percentage of attackers (say > 33%)

Complex architectures like sharded blockchains (e.g. Eth 2.0) solve the blockchain trilemma and achieve all three properties simultaneously, but are difficult to implement.

The Rollup Trilemma

Rollups are stateful, transaction-based, blockchain scaling solutions that provide the developer with the abstraction of a faster blockchain and are built on top of a given Layer 1. For instance, rollups can provide an EVM-compatible (or equivalent) smart contract execution environment.

There exist three types of rollups: optimistic rollups, zero-knowledge rollups and sidechains. Analogously to the blockchain trilemma, we introduce the rollup trilemma to evaluate tradeoffs between these different scalability architectures.

Sidechains are not usually considered to be rollups, but we do here for the sake of comparison. In this, t-of-N security means that at least t out of N nodes are needed to be honest to maintain the rollup security, and 1-of-N is the special case t = 1. For optimistic rollups, settlement can take ~7 days due to the reliance on the optimistic mechanism (a dispute period + fraud proofs). Compute means the amount of total computation needed to process transactions. For zk-rollups this is high because proof generation for a given computation is on the order of 1000x more expensive than the computation itself.

The Interoperability Trilemma

Arjun Bhuptani introduced the notion of an interoperability trilemma for the field of blockchain bridges, considering security, extensibility and generalizability properties. Here we give a different take to the interoperability trilemma, now from the side of security, extensibility and scalability.

• Security: New trust assumptions introduced beyond that of the underlying blockchains
• Extensibility: Can the architecture be easily modified to integrate new blockchains?
• Speed: Cross-chain communication latency

Here "light-client-bridges" means relay-based bridges where the destination chain can verify through a proof that a sequence of blocks from the source chain is valid. This can be done through ZKPs (e.g. zkRelay) or without them (e.g. Rainbow, ETH-relay).

While most commercial bridges are PoS-bridges, not all PoS bridges are built the same. Some, like Axelar (and [Endpoint + Nexus]), have a decentralized, open-membership, validator set. Most however, run a centralized validator set (meaning N is small, and fixed) and some not even rely on cryptoeconomic incentives, but only on reputation, thus providing much lower security.

The Computational Oracle Trilemma

Computational oracles are stateless, event-driven, blockchain scaling solutions that provide smart contracts with a way to outsource specific parts of a computation. For instance, computational oracles allow smart contracts to outsource heavy operations like running a decentralized AI model or solving large systems of equations. Computational oracles can serve requests from smart contracts on any L1 or L2.

Truebit is an optimistic computational oracle system. In the Truebit architecture, an oracle node produces a cryptographic summary of the off-chain computation, with which disputes and fraud proofs can be generated to ensure security as with any other optimistic system. Nexus is a PoS-based computational oracle network, also called "cloud oracles" (for its resemblance to traditional cloud computing) which achieves low latency (unlike optimistic systems) but has a weaker t-of-N security guarantee.

The Data Oracle Trilemma

Similarly, we introduce the notion of a trilemma for data oracles (e.g. token price oracles, stock price oracles, interest rate oracles, weather data oracles, etc.) for the properties of consensus security, speed and cost. To do so, we also introduce a new idea: security for data oracles can be decomposed into two separate properties, data security and consensus security.

Data providers are the set of parties who provide the data inputs (e.g. reputable websites, API endpoints, weather agencies). Consensus nodes are the set of parties who fetch and reach consensus on that data. For traditional PoS-oracles (or reputation-based, like Chainlink) data providers are also consensus nodes (i.e. k = t and M = N below). New systems like Nexus, however, decouple the notions of data and computation, so that oracles are k-of-M data-secure for M data sources, and t-of-N computationally-secure for an N-sized cloud network. That is, Nexus allows developers to program on top of a computational oracle network of size N that fetches data from M external sources. The oracle application logic on the cloud network can have custom incentivisation mechanisms that strengthen (or establish) data security, such as data provider staking and slashing. Thus, platforms like Nexus provide a compute-enabled generalization of traditional data oracles.

For zk-oracles like Provable and DECO, data providers and consensus nodes are also decoupled (i.e. they are independent entities, k = M = 1), since the data source is a single centralized entity (e.g. a website) and some other independent party (the consensus node) produces and submits a TLS validity proof on-chain. With optimistic oracles like UMA, at least one consensus node needs to be active in order to initiate disputes, which are then resolved by a quorum of data providers.

Decentralized systems are only as secure as their least secure component, and this is true for data oracles too. For example, it doesn't matter that optimistic oracles have high 1-of-N consensus security if the data providers themselves (who resolve disputes) have low k-of-M security, since the whole application is then at most k-of-M-secure. However, in some instances data providers can be regarded as highly authoritative or reputable (and hence highly secure), so that the important security design choice is not on the side of data security but consensus security. For instance, it would make more sense security-wise to build a centralized identity oracle that fetches data from a government website using a zk-oracle than a PoS-oracle, since the former introduces the least amount of new trust assumptions. However, PoS-oracles are generally much more flexible and generalizable than zk-oracles, and need far lower on-chain and off-chain computational resources.

The Cloud Network Trilemma

The Nexus Protocol generalizes the notion of cross-chain, data and computational PoS-based oracles into a single new decentralized computing architecture: a Decentralized Cloud Network. It provides a general-purpose off-chain consensus and computation engine for blockchains. Since users can select custom network sizes (say, of size n), applications running on the Nexus Cloud, called decentralized executables (dEXs), can serve as oracles for blockchain applications n ~= 100 or as independent cloud computing nodes for traditional computing applications n = 1, 2, 3.

Similarly to Vitalik's Blockchain Trilemma, different cloud network architectures can be analyzed from the lens of a Cloud Network Trilemma between the decentralization, security and scalability properties.

• Decentralized Cloud: the cloud is large-scale, open-membership, and every node runs every computation.
• Centralized Cloud: the cloud is small-scale, closed-membership, and every node runs every computation.
• Partitioned Cloud: the cloud is large-scale, open-membership, and is partitioned into smaller subnetworks which run jobs in parallel.
• Sharded Cloud: the cloud is large-scale, open-membership, and sharded so that it can run multiple jobs in parallel without long-term network partition

Unlike Eth 1.0 and Eth 2.0, Nexus will initially give up on the side of decentralization in exchange for high throughput (so it can serve multiple requests across L1s and L2s). Nexus 2.0 will then become decentralized and introduce network partitioning, allowing the network to become large-scale. This will enable the network to serve multiple requests in parallel while maintaining equal or higher cryptoeconomic security as Nexus 1.0, as well as the creation of a cloud computing marketplace where applications can run on subnets with custom size and computing capabilities. Lastly, Nexus 3.0 will allow subnets to achieve much higher security through sharding, similar to Eth 2.0.

Conclusion

The future of decentralized computing looks bright. From the side of blockchain scalability, fractal scaling (through recursive zk-rollups) along with Eth 2.0 sharding will bring about the next frontier of stateful, transaction-based, decentralized computing.

In parallel, the need for cross-chain (and cross-rollup) bridges, high-performance off-chain decentralized computing (and smart contract automation), and data oracles (for achieving real-world interoperability) requires a new technology in the form of a stateless, event-driven, decentralized computing platform like Nexus.

When combined, solutions to the blockchain and cloud network trilemmas (like Eth 2.0 and Nexus 3.0) will bring about a new era of highly-scalable, highly-secure, and highly-interoperable decentralized computing.