Skip to content Skip to footer

Overview and Prerequisites

Overview

First we will look at the Oasis architecture then I have prepared four

tasks for you 

We will start with the confidential transaction and then sign view calls, we’ll move to the front end so we can connect to sapphire with the browser then we will look at the precompiles.

 First, let’s explore the Oasis architecture, and then we’ll dive into four prepared tasks.

We’ll begin with confidential transactions, followed by signing view calls. Afterward, we’ll shift our focus to the frontend, connecting to Sapphire through the browser. Next, we’ll delve into the precompiles section, where Sapphire provides valuable tools for on-chain encryption, such as the random number generator.

Finally, I’ll share insights on potential pathways for further exploration after the workshop. Sapphire addresses a variety of challenges, and I hope to inspire you with ideas that spark your interest. If you have any questions along the way, feel free to ask, and let’s make this workshop an engaging and productive experience!

Prerequisites

The programming knowledge that is required is basic (JavaScript); you are not required to be a blockchain solidity or ethereum expert. We’ll also use the command line and finally you will need the nodejs environment on your computer and the pnpm package manager. 

The Oasis Architecture

Okay now let’s look at the Oasis architecture! 

Before the 1990s, particularly in the 1980s when personal computers became widely available, let’s envision a typical scenario. 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.”

Feel free to let me know if you’d like further adjustments or have any specific preferences!

Before the 1990s, particularly in the 1980s when personal computers became widely available, let’s envision a typical scenario. 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.”

Feel free to let me know if you’d like further adjustments or have any specific preferences!

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.