oasisprotocol

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 2): Stake Requirements and Node Installation Before you can run a node for a blockchain protocol, there are several things to prepare. In this 4-part series, I discuss the prerequisites for running nodes on Oasis in detail. In part 1, we learned about hardware and cloud providers. Here, I will cover stake requirements and how to install the Oasis Node. Stake Requirements Based on your node role and whether you are on the mainnet or the testnet, you need to keep in mind the following requirements. 1. Registration of entity Mainnet: 100 ROSE Testnet: 100 TEST Note: To get the latest entity registration requirement, you will need to run the command oasis network show native-token. 2. Registration of node Mainnet: 100 ROSE Testnet: 100 TEST 3. Size of the validator set Mainnet: 120 Testnet: 110 Notes: The validator set is the consensus committee, and its size is capped by the max_validators committee-scheduler parameter. To view the current value, you will need to run the command oasis network show parameters. For mainnet, to find out whether you are eligible to receive a delegation from the Oasis Protocol Foundation, check out the Delegation Policy. For testnet, the faucet generates only a limited number of TEST tokens. If you need more, you will need to contact the team on the official Discord in the testnet channel. 4. Run a Sapphire or Emerald compute node Mainnet: 5,000,000 ROSE + member of the validator set 5. Run a Cipher compute node Mainnet: member of the validator set Notes: The docs list no separate testnet figures. To get the latest paratime-specific stake requirements, you will need to run the command oasis network show and specify the paratime ID for mainnet. To know who the current top validators are, you can do that either with Oasis Explorer or with the CLI command oasis network show validators. As mentioned, requirements vary according to your choice of node role. Here is a snapshot of the role-specific steps to set up a working node from scratch. !Image description Note: There are no specific requirements for non-validator nodes. To check whether you meet the requirements for your node role, you will first need to view the balance of your account. You can do that either with Oasis Explorer or with the CLI command oasis account show. Installing the Oasis Node The Oasis Node is a binary created from the Oasis Core repository's go/ directory. It is a single executable and contains the logic for running your node in various roles. Currently, the Oasis Node is only supported on x86_64 Linux systems. Setting up the working directory You need a place to store necessary files before installing the Oasis Node, so that is the first step. In this guide, /node refers to the working directory. In the /node directory, start by creating the following subdirectories to allocate specific storage roles. - etc/: configuration and entity.json - data/: node's data - bin/: oasis-node binary - runtimes/: paratime .orc bundles To establish the directory structure along with the corresponding permissions, you will need to execute this command. mkdir -m700 -p /node/{etc,bin,runtimes,data} Note: Creating directories under / usually requires root privileges. Make sure the account that will run the node owns /node afterwards, since the 700 permissions give access to the owner only. Copying the Genesis file You can find the latest Genesis file for mainnet and testnet as part of the network parameters. The next step involves downloading the latest genesis.json file and copying it to /node/etc/genesis.json on the server. Once done, you can now get the oasis-node Binary. Downloading a binary release The Oasis Protocol Foundation builds and provides the binaries. Since the Oasis Node is part of the Oasis Core release, start by finding the network parameters linked earlier for the respective mainnet and testnet. Next, follow the Oasis Core version link to its GitHub release, where the downloads are listed under Assets. Building from source Building from source is highly suggested, but the Oasis documentation currently treats it as beyond its scope. You will need to check out Oasis Core's Build Environment Setup and Building documentation for more details. Note: The code in the current master branch may be incompatible with the code used by other nodes on the network. It is thus essential that you use the version specified in the network parameters linked earlier for the respective mainnet and testnet. Adding oasis-node binary to PATH If you are installing the oasis-node binary next to your Oasis Node data directory, you will need to copy/symlink it to /node/bin. Now, if you are installing the binary for the current user, the copy/symlink needs to be to ~/.local/bin. To install it for all users of the system, you have to copy it to /usr/local/bin. Running paratimes This is applicable only if you are running a paratime node. You will then need to install some additional software packages. You will need Bubblewrap 0.4.1+ to create process sandboxes. On Ubuntu 20.04+, you can install it with this command. sudo apt install bubblewrap For Fedora, use this command instead. sudo dnf install bubblewrap This concludes part 2 of the prerequisites series. In the next part, I will discuss system configuration. - For technical specs, APIs, architecture, and integration guides, the Oasis documentation is your starting point. - For direct support on specific issues, the Oasis engineering team and other node operators are available in the node-operators channel on the official Discord.

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 1): Hardware and Cloud Providers There are various ways to support a blockchain protocol. For example, tech-savvy users sometimes prefer to run nodes. Now, if you are planning to do so, specific hardware and software prerequisites must be in place. In this 4-part series, I will discuss them in detail for running nodes on Oasis. The first part covers hardware and cloud providers. Hardware Requirements As outlined in the [introduction to Oasis nodes] (dev.to), the protocol consists of several distinct node types. - Consensus validator or non-validator node - Sapphire compute or client node - Emerald compute or client node - Cipher compute or client node In this section, I will focus on the minimum and recommended system hardware requirements. Anyone planning to run more than one paratime (Sapphire/Emerald/Cipher) on a single node will need more resources. If you configure a system with fewer resources than recommended, you run the risk of being under-provisioned. This can cause proposer node timeouts and synchronization delays. If your node exhausts its memory or storage, the node process is forcefully killed, which can result in state corruption. As a result, you risk losing stake and getting barred from participating in committees. CPUs Consensus validator or non-validator node - Minimum: 2.0 GHz x86-64 CPU with AES instruction set support - Recommended: 2.0 GHz x86-64 CPU with 2 cores/vCPUs with AES instruction set and Advanced Vector Extensions 2 (AVX2) support Emerald compute node and all client nodes - Minimum: same as above - Recommended: 2.0 GHz x86-64 CPU with 4 cores/vCPUs with AES instruction set and AVX2 support Sapphire/Cipher ParaTime compute node - Minimum: 2.0 GHz x86-64 CPU with AES instruction set and Intel SGX support - Recommended: 2.0 GHz x86-64 CPU with 2 cores/vCPUs with AES instruction set, Intel SGX, and AVX2 support Notes: 1. If you are running regular workloads on your node, the minimum resources will suffice. However, if you plan heavier workloads, like a paratime client node behind a public Web3 gateway, you will need more cores/vCPUs. 2. The reason you need AES instruction set support is that it is required by Deoxys-II-256-128, a Misuse-Resistant Authenticated Encryption (MRAE) algorithm, for encrypting paratime state. 3. The reason you need AVX2 support is to enable faster Ed25519 signature verification. This will speed up node sync. 4. You need Intel SGX support only when you are running paratime compute nodes (Sapphire/Cipher). Check out Intel's comprehensive list of processors that support Intel SGX, and match it with Sapphire and Cipher requirements before proceeding. Memory Consensus validator or non-validator node - Minimum: 6 GB of ECC RAM - Recommended: 8 GB of ECC RAM Each Emerald/Sapphire/Cipher compute or client node - Minimum: 12 GB of ECC RAM - Recommended: 20 GB of ECC RAM In most scenarios, the nodes, even with less than the minimum amount of memory, will run regular workloads smoothly. To cover the more resource-intensive time points, such as the initial state sync, BadgerDB migration when upgrading a node to a new major version of the Oasis Core, generating storage checkpoints with BadgerDB, and periodic BadgerDB compactions, your nodes will need more memory than usual. Storage Consensus validator or non-validator node - Minimum: 400 GB of SSD or NVMe fast storage - Recommended: 700 GB of SSD or NVMe fast storage Emerald compute or client node (in addition to the consensus storage requirements) - Minimum: 400 GB of SSD or NVMe fast storage - Recommended: 700 GB of SSD or NVMe fast storage Sapphire/Cipher compute or client node (in addition to the consensus storage requirements) - Minimum: 200 GB of SSD or NVMe fast storage - Recommended: 300 GB of SSD or NVMe fast storage Notes: 1. Both consensus and paratime states are stored in an embedded BadgerDB database. As BadgerDB is designed to run on SSDs, it is highly recommended not to run a node that stores data on HDDs. 2. Both consensus and paratime states accumulate over time. The rate of storage growth varies by transaction count on the network and the paratimes. For example, a consensus non-validator node on the mainnet accumulated 280 GB of consensus state in approximately one year since the Cobalt upgrade, and 32 GB of consensus state in approximately one month since the Damask upgrade. Another example would be an Emerald client node on the mainnet, which additionally accumulated 260 GB of paratime state in approximately five months since Emerald's launch, and 25 GB of paratime state in approximately one month since the Damask upgrade. 3. Dump and restore upgrades, such as the Damask and Cobalt upgrades, include state wipes that free up node storage. If you need to access historical state, you can run a separate archive node. Also note, the latest is Eden 4. It is recommended not to keep a complete state from the genesis onward unless you are running a node to preserve historical state. This will also reduce storage requirements for both consensus and paratime states, as well as improve the overall latency of the storage-related operations. To enable storage reduction, you should check out consensus pruning and paratime pruning. Network Consensus validator node and all paratime compute nodes - Minimum: 200 Mbps internet connection with low latency - Recommended: 1 Gbps internet connection with low latency Regular workloads use relatively little traffic. The higher bandwidth is recommended for bursts of transactions, when a node with too little bandwidth can time out. Cloud Providers If you plan to run a Sapphire or Cipher compute node, a crucial step is verifying processor compatibility and checking the status of Intel SGX support (refer to Note #4 in the CPUs section). Limitations You will come across several bare-metal or dedicated server providers using Intel processors that support SGX. However, you should also be aware of potential limitations. - BIOS configuration: Some providers restrict users from accessing or modifying BIOS settings, which might be essential to correctly configure Intel SGX. - Outdated firmware: SGX requires the latest firmware to function correctly. If the system provider is behind on updates, this is a problem. - Lack of SGX-specific offerings: Some providers do not advertise or specifically offer SGX-enabled servers. Users need to know specifically that their server is SGX-enabled, as this feature is non-negotiable for running some Oasis nodes. - Limited support: Sometimes even when an SGX-enabled server is available, the provider's support team might lack the expertise to handle SGX-specific issues or configurations. - Hardware provisioning: Use of keys, such as SGX sealing keys, involves them being bound to hardware to encrypt the data of an instance within an Intel SGX enclave. If the host of the instance is changed, the encrypted data cannot be decrypted. Known providers 1. Alibaba Cloud Product: (ECS) Bare Metal Instances Documentation: Build an SGX confidential computing environment 2. Azure Product: Some Dedicated Host SKUs Documentation: Solutions on Azure for Intel SGX 3. Gcore Product: Bare Metal Documentation: Computing with Intel SGX 4. IBM Cloud Product: Virtual Private Cloud (VPC) Documentation: Confidential computing with SGX for VPC 5. OVH Product: Bare Metal servers Documentation: SGX for Confidential Computing 6. PhoenixNAP Product: Bare Metal Cloud Documentation: What is Intel SGX and What are the Benefits? 7. Vultr Product: Bare Metal Documentation: Intel SGX development on Vultr Note: Provider offerings change, so the list above may not reflect each provider's current SGX support. So, it is recommended to check out the provider's own documentation and confirm Intel SGX availability with them directly. If any cloud or dedicated server providers that actively support Intel SGX or Intel TDX are not in this list, or if you come across updated information about the providers listed above, you can let the Oasis team know by creating an issue on GitHub with the additional details. This concludes part 1 of the prerequisites series. In the next part, I will discuss stake requirements and how to install the Oasis node. - For technical specs, APIs, architecture, and integration guides, the Oasis documentation is your starting point. - For direct support on specific issues, the Oasis engineering team and other node operators are available in the node-operators channel on the official Discord.

Introducing Privana: A Deep Dive into Underlying Technology In the world of privacy-first decentralized finance (DeFi), the upcoming Privana, built by and on Oasis, proposes a unique solution that deserves a deep dive. In the first part of this exploratory series, I detailed the core concepts of this private DeFi application. In this part, we will go deeper and look into the underlying technology that makes Privana tick. Oasis Sapphire and ROFL In the core concepts, Sapphire was mentioned several times, but why is this such an integral part of the technology that drives Privana? How does the Runtime Off-chain Logic (ROFL) framework fit in? The scope of Privana's functionality depends on both on-chain and off-chain components running in attested Trusted Execution Environments (TEEs). As the confidential EVM runtime, Sapphire utilizes Intel SGX enclaves to ensure smart contract logic and its state are confidential by default. As a result, transactions and contract storage are encrypted, while validators and node operators, even though they are crucial to running the network, cannot access or alter them. Running Privana's on-chain functionalities with Sapphire has advantages that underpin the application's privacy and security. EVM Compatibility Sapphire is EVM-compatible, so the smart contracts are written in Solidity. There is no need for prior or specialized TEE knowledge, and the confidential smart contracts can be independently audited, as the code is public. Anyone can thus verify whether the on-chain logic functions as claimed. Confidential State This is a critical property of Sapphire, as the encrypted contract storage stays on-chain and in memory. It guarantees that the state is accessible only to the executing TEE. This means that user balances, policies, and trade history are and remain private. !Image description The diagram shows how each contract is encrypted with its own key, held by an isolated Key Manager. However, as it states, node operators are still able to view the access patterns. Cross-chain signing The core concepts highlight Privana as a multi-chain application. The architecture of Sapphire can help us understand how an EVM blockchain manages this. A Sapphire contract holds the private key inside the enclave and signs cross-chain transactions on Oasis itself. The key thus never leaves the enclave, and the contract logic that decides what to sign remains confidential. So, the destination chain can only see the finished transaction, a regularly signed transaction made from the application's pooled vault address. As a result, there is no way to link the transaction back to the users. ROFL The chain-agnostic nature of Privana's vaults and the off-chain execution of application logic come from ROFL TEEs, attested on-chain by Oasis Sapphire. The application's functionalities that run inside a ROFL container are executed in an off-chain, attested, TEE-secured setting. In the subsequent stage, Sapphire verifies whether the EVM transactions originate from that specific ROFL instance. In short, Sapphire holds the keys and handles accounting and signing, while the Privana service, running in ROFL, handles deposit verification, swaps, yield, and broadcasting. Privana's Architecture While discussing the core concepts of Privana, we briefly touched on the architecture. Let's look at it now in more detail. !Image description There are five components. Integrators build with the Privana SDK, which then calls the service via the REST API. This service sits at the center of everything: it reads and writes the Oasis Sapphire contracts, which hold the keys and sign transactions confidentially, and it verifies and settles transactions on external chains, where deposits and pooled vaults sit. Accounting block Accounting here is the confidential ledger. The contract stays on Sapphire and holds a mapping of deposit addresses to asset balances. This is entirely encrypted. The Privana service maintains this system with various functions: - processing deposits on each source chain - ensuring balance change management works smoothly - implementing the Know Your Transaction (KYT) routine by screening transactions - validating balances before any trades can take place - ensuring finality reconciliation once execution has gone through - handling withdrawals taking place in all the supported chains Microservices block Microservices implement the execution logic for DeFi operations. Privana has two microservices: swaps and yield. These will be covered in detail later. Moreover, there is room to add new ones going forward if Privana decides to diversify its services in perpetuals or lending. This is possible because the core accounting logic stays the same for all microservices as they settle against the same wallet balance, using the same signature path. Remote attestation TEEs being the privacy-preserving core of both Sapphire (SGX) and ROFL (TDX), understanding how remote attestations work in Privana is important. The attestation reports are signed by Intel's hardware root of trust. As a result, anyone can remotely verify that the enclave is running exactly the code it claims to run. The beauty of this verification engine is that it is all-encompassing, providing robust, in-depth auditability that regular audits could have missed. It covers the on-chain contracts, the off-chain Privana service, as well as the microservices running in attested ROFL containers. This means it is also possible to verify the swap and yield logic being executed by the application. Not limited to DeFi One of the core architectural strengths of Privana is that its SDK is composable. So, while Privana acts as the face of private DeFi, the applicability goes beyond it. As a result, any dApp that involves private balances or scoped, time-bounded access can use the underlying architecture of the vaults. Fallback & Recovery For the end users, there is a nagging question about any services, especially web3-related ones such as DeFi, given the crypto space has yet to achieve significant mass adoption. So, what happens if the enclave goes offline permanently, or if Privana stops its application and service? A USP of Privana's architecture is that it has built-in fallback and recovery safeguards. This is not a run-of-the-mill service-level promise; it is embedded in the system and guaranteed by Oasis Sapphire. As mentioned, Sapphire runs and executes the Accounting contract, which means it is not dependent on Privana's off-chain service. Since the contract state is on-chain, even if Privana's application and service go offline, the exit option remains open. Let's see how this works. On-chain withdrawal The Accounting contract allows two withdrawal paths independent of the downtime of the off-chain service in the ROFL container. - User balance: The user can submit a withdrawal request signed by their wallet. The contract will return a signed transaction after a short time lapse on-chain. This results in the transaction paying out the user to their own address on the source chain. Anyone can broadcast it for the user, which also minimizes the risk of the funds being lost or stolen. - Funds in user deposit address: This method is initiated if a deposit was never swept into the vault. The user can then call the contract directly to recover it. Following a short time lapse on-chain, the contract will return a signed transaction, the same as the first method. The difference here is that, in this case, the user can specify the destination in that call and will accordingly receive the payout. The important aspect of both these methods is that the payout address is specified before the transaction is signed. So, it is fixed permanently, and even if there is an untrusted broadcaster, the funds will only route to the designated address. Beyond service outage A service outage is the easier case, since Sapphire stays live and the withdrawal paths above still work. A more serious scenario, like a permanently lost enclave, is where Privana's recovery model, informed by the sentinel-wallet design, comes into play. Liquefaction, whose role in Privana is described later, outlines operator-independent recovery so that asset owners can reclaim control of their funds without needing to trust any single party. This is reassuring: user assets are not designed to be permanently lockable. Trust Model We glanced over this while discussing Privana's core concepts. Let's explore more here. No system is or can ever be absolutely trustless. Privana is built using technology that minimizes trust requirements as much as possible, but some assumptions still remain. !Image description Note from the table screenshot: - Research Basis: next section - Sapphire docs Two risks cannot be eliminated for Privana, even with the best of preparedness. 1. Vulnerabilities in the TEE hardware itself, whether Intel SGX or TDX. This is inherent for all TEE platforms, although Sapphire, using SGX technology, has various mitigation steps added in the form of defense-in-depth design. Sapphire's SGX TEE resilience was demonstrated by its withstanding TEE attacks by Battering RAM and Wiretap. 2. Smart contract bugs in the external yield protocols that the user might choose to interact with. Privana approaches this by mitigating potential fallout through conservative platform selection, audits, and protocol vetting. Complete Knowledge proofs Liquefaction is one of the crucial technologies on which Privana stands, as it introduces key encumbrance. The Liquefaction framework also discusses Complete Knowledge (CK) proofs, which are cryptographic proofs that a user has unencumbered access to a private key. They could become a valuable complement to Privana, for example, by letting centralized exchanges verify that a depositor's keys are not encumbered. Research Basis The groundwork behind Privana's architecture and technology is laid down by cryptographic research from Cornell Tech. Recommended reading starts with the Liquefaction paper as the primary research basis. This paper introduces key encumbrance as the core primitive, demonstrating that TEE-based key encumbrance can break the Single-Entity Address-Ownership (SEAO) assumption. Let's now look at the four cornerstones of the research that help to understand how the Liquefaction framework is implemented by Oasis in Privana. - Key Encumbrance: Generating a private key and securely holding it inside a TEE, governed by programmable access-control policies, enabling automation without custody transfer. - SEAO Assumption: Challenging the assumption that one blockchain address can only be controlled by a single entity. - Asset-Time Segmentation: Implementing exclusive asset control by one sub-policy at any given time, thereby ensuring multiple policies don't end up competing amongst themselves, which could result in deadlock and double-spend. - Overlay Smart Contracts: Applying smart-contract-like logic to chains, such as Bitcoin, Litecoin, Dogecoin, etc., that don't support native smart contracts as an extension of the encumbered keys being managed off-chain in TEEs. For interested readers, there are several references available in addition to the Liquefaction paper, if they want to do their own research on the security model. - Kelkar et al. on Complete Knowledge proofs (ACM CCS, 2024) - Jean-Louis et al. on privacy flaws in TEE-based platforms (ePrint 2023/378) - Van Schaik et al. on SGX security (IEEE S&P, 2024) Integrations The components of Privana are assembled from public, auditable infrastructure, chosen because of their popular adoption and independent operation. !Image description These are the live integrations as of now. If any services become unavailable, they can be replaced by similar services with the same interface. This concludes the deep dive into Privana’s underlying technology. Next time, I will discuss Privana’s features in detail. In the meantime, let’s continue the discussion in the comments section about what you think of these technological components that are the basis of Privana’s build. Resources & references: - Privana - Oasis - For specific questions or feedback, connect on the Privana channel** on the official Discord.