Oasis Architecture

The Oasis Architecture: Sapphire

While the computation and storage of data within the trusted execution environment remain confidential and encrypted, the decision to encrypt or make transactions publicly visible on the ledger is a matter of choice and context.

In certain scenarios, such as verifying the deployment of a smart contract or auditing contract transactions, it’s essential for specific transactions to be publicly accessible. For instance, showcasing the bytecode of a deployed contract allows others to review and verify its functionality. Similarly, public visibility of contract trade transactions promotes transparency and facilitates trust within the network.

Therefore, while the default behavior may involve encrypting transactions for privacy and security reasons, there are instances where deliberate disclosure of transactions is necessary for verification, auditing, or transparency purposes. This flexibility ensures that users can balance privacy concerns with the need for transparency and accountability within the blockchain ecosystem..

Now we have the detailed architecture of how contracts execute code on the Sapphire platform. Let’s break down the key components and processes involved:

1. *Sapphire Node in TEE:* This is the core component where smart contracts are executed within the Trusted Execution Environment (TEE), ensuring confidentiality and security.

2. *Key Manager:* The Key Manager operates in parallel on a subset of compute nodes. When a transaction requires access to confidential storage, the Sapphire Node requests the necessary key from the Key Manager. The Key Manager retrieves the key from the key-value database specific to the contract and returns it to the Sapphire environment.

3. *Transaction Processing:* Within the Sapphire environment, the transaction is processed, including reading/writing to storage, computing new IO roots for block proposers, and returning results to the user, including computation outcomes and emitted events.

4. *Security Measures:* It’s important to note that Sapphire does not store any keys. Instead, it obtains keys from the Key Manager as needed, ensuring that even if the Sapphire environment were compromised, sensitive keys would not be exposed. The real security concern lies with the Key Manager nodes, as they hold the actual keys. However, the design ensures that keys are only temporarily provided to Sapphire for the duration of computation and are then discarded. Verification mechanisms such as attestation steps help ensure the integrity of the code running within the TEE, providing assurance that the expected code is indeed executing securely.

By segregating key management from the computational environment and implementing stringent security measures, the Sapphire platform offers a robust and secure framework for executing smart contracts with confidentiality and integrity.

.

The Oasis Architecture: Bigger Picture

A broader perspective on the Oasis Network and its architecture. Let’s summarize the key components and features:

1. *Consensus Layer:* Positioned at the top of the network hierarchy, the consensus layer serves as the governance layer. It oversees network upgrades, such as the recent Eden upgrade, and manages the announcement of runtime upgrades for subchains. Notably, the consensus layer does not support smart contracts, as a precautionary measure against potential risks associated with Turing complete languages.

2. *Subchains and Paratimes:* Below the consensus layer are subchains, each hosting its own runtime, known as a Paratime. Paratimes offer various features and capabilities tailored to specific needs. For example:

– *Emerald Paratime:* The first Paratime introduced, it is Ethereum Virtual Machine (EVM) compatible but lacks encryption support.

– *Cipher Paratime:* Prioritizing confidentiality, Cipher Paratime encrypts storage but does not support EVM. Smart contracts on Cipher Paratime are written in Rust, and a Rust SDK is provided for developers.

3. *Token Separation:* Tokens on the Oasis Network are separated between the consensus layer and Paratimes. Transfers between layers require bridges or similar mechanisms, ensuring controlled movement of tokens and preventing direct usage between layers.

This architecture offers flexibility and security by providing different Paratimes with varying functionalities to meet diverse requirements. Additionally, the segregation of tokens between layers enhances control and reduces potential risks associated with cross-layer interactions. Overall, the Oasis Network’s architecture aims to balance functionality with security and governance.

The Oasis Architecture: Sapphire Public Endpoints

For anyone eager out there and if anyone already knows how to you know  write smart contracts on ethereum they just  bootstrap and jumpstart ahead and connect to the test net sapphire for example and try to deploy some contracts there using the original ethereum tooling and  you’re good to go.  You can see the testnet url https://testnet.sapphire.oasis.dev and our block explorer is https://explorer.oasis.io/testnet.sapphire

 let’s pause for a minute here for questions and then we’ll move on

okay so there were some questions  so regarding the slides  I would kindly ask Neli if  she could maybe share view only access from the Google Drive we have  with everyone or maybe export it to PDF and upload the PDF to our drive and share it, sorry I forgot and there are yeah there there are some questions regarding the  sapphire downtime  so as I mentioned earlier

The architecture is something like this

The main issue stemmed from the web Gateway, which experienced challenges with load balancing and node compaction within the Comet BFT consensus library.

To mitigate these issues, additional nodes were added to the network, and efforts were made to optimize the load balancer functionality. It’s important to note that reliance on public centralized services within a distributed network can introduce vulnerabilities and dependencies. As such, developers and companies are encouraged to run their own client nodes to ensure reliability and minimize the risk of censorship.

In cases of congestion or issues with public gateways, utilizing private gateways or running personal nodes can provide an alternative means of transmitting transactions and accessing the network. Despite challenges with endpoints, the underlying network infrastructure remained functional, and efforts to improve gateway performance aim to enhance overall network stability and accessibility.