Skip to content Skip to footer

Oasis Architecture

Computing Evolution: A Historical Overview

Let’s envision a typical scenario, before the 1990s, particularly in the 1980s when personal computers became widely available.  Meet Alice and Bob, who have just purchased a PC—a bulky setup comprising a monitor, keyboard, and possibly a mouse. The question arises: how do they interact with this computer?

Their primary tasks involve writing commands, inputting data, and awaiting computation within the confines of that box. The output typically manifests on the display, floppy drive, or hard drive.

During this era, communication with the computer was limited to using a floppy drive or perhaps a peripheral like a camera; networking capabilities were nonexistent for personal computers at the time.

In the 1990s, the emergence of the Web transformed how PCs were used. Instead of performing all computations locally, PCs primarily ran web browsers. Alice and Bob, for instance, could fill out a form in an HTML interface and send a request to a server. The server would handle the computation, process and store the data, and send a response back to be displayed in the browser.

This setup allowed multiple clients to interact with the same server, establishing the client-server architecture that remains common today. A key aspect of this system is the presence of a server administrator who has access to all the data and computations carried out on the server.

After 2009, the concept of the distributed ledger gained prominence. Although distributed networks existed long before Bitcoin, we’ll focus on Bitcoin for the purposes of this workshop. In Bitcoin’s network, multiple nodes operate in a distributed manner, and each node functions as both a server and a client simultaneously.

What sets Bitcoin apart is its use of a public ledger to record transactions. This ledger is massive and publicly accessible, with every node maintaining a copy on its own hard drive. To add transactions to this ledger, a consensus must be reached to determine which transactions are included. In Bitcoin’s case, this consensus is achieved through a process involving computational difficulty. The first node to solve the cryptographic challenge—by generating a hash with the required number of leading zeros for the proposed block—is granted the permission to add that block to the ledger.

In Bitcoin, a distributed network comprises numerous nodes, each functioning as both a server and a client simultaneously. What sets Bitcoin apart is its utilization of a single, extensive public ledger where all transactions are recorded. Each node maintains a copy of this ledger, typically stored on its hard drive. Transaction inclusion in the ledger requires consensus, a process governed by a predefined difficulty level. The first node to generate a hash with the requisite number of leading zeros earns the right to append a block to the ledger.

With the emergence of Ethereum, the underlying principles remained largely unchanged. Ethereum also features a public ledger accessible to all nodes. However, Ethereum introduced Proof of Stake, a consensus mechanism that relies on validators maintaining a comprehensive view of the network. Unlike client-server architectures, Ethereum operates on a peer-to-peer model, facilitating direct communication and transactions among nodes. While every node theoretically performs computations, practical considerations arise, particularly for users accessing these networks via mobile devices. Running a full node on a mobile phone for Bitcoin or Ethereum is often impractical.  

In this scenario, a liteclient serves as an alternative for users seeking to interact with blockchain networks like Ethereum or Bitcoin without running a full node. Facilitating this interaction is the web3 Gateway, an intermediary that transforms transactions from the traditional web2 format into web3 transactions, allowing seamless communication with the blockchain network.

From a trust perspective, relying on such intermediaries poses challenges. When running a personal node, users have greater control and assurance, able to trust the hardware and verify the software through its source code. However, utilizing a web3 Gateway introduces a dependency on the Gateway’s administrator, necessitating trust that they will uphold data privacy and security.

Moreover, Ethereum and Bitcoin ledgers are inherently transparent, making all transactions and smart contracts visible to anyone. This transparency underscores the importance of trust and security when engaging with blockchain networks, especially when utilizing intermediaries like web3 Gateways.

A Broader Perspective on the Oasis Network and Its Architecture

The Oasis Network is designed to deliver a highly flexible and secure blockchain ecosystem. Here’s a summary of its key components and features:

  1. Consensus Layer
    At the top of the network hierarchy, the consensus layer acts as the governance hub. It oversees critical network operations, including upgrades such as the recent Eden upgrade, and coordinates runtime announcements for subchains. Importantly, this layer does not support smart contracts, mitigating risks associated with Turing-complete languages and preserving stability.
  2. Subchains and Paratimes
    Beneath the consensus layer are subchains, each running its own runtime, referred to as Paratimes. These Paratimes are tailored for specific purposes, providing flexibility to meet diverse requirements:
    • Emerald Paratime: The first Paratime launched on the network, offering Ethereum Virtual Machine (EVM) compatibility. However, it does not support encryption.
    • Cipher Paratime: Designed with a focus on confidentiality, Cipher Paratime encrypts data storage while not supporting EVM. Developers write smart contracts in Rust, supported by a dedicated Rust SDK.
    • Sapphire Paratime: A privacy-enabled EVM-compatible Paratime. Sapphire combines the flexibility of EVM with on-chain confidentiality, allowing developers to leverage familiar tools while ensuring enhanced privacy features.
  3. Token Separation
    The Oasis Network enforces token segregation between the consensus layer and Paratimes. Movement of tokens between these layers requires bridges or similar mechanisms, ensuring controlled transfers and preventing direct token usage across layers.

This layered architecture ensures flexibility by offering distinct Paratimes for different functionalities, while token segregation enhances security and reduces the risks of misuse across the network.