February was filled with new updates and improvements from the Oasis engineering team. Let's see how Oasis and partner-specific improvements helped Oasis have a strong February — and beyond! (See more of what Oasis has in store for 2024!)

Wallet and CLI Updates

After more than two years, a new official release of the Oasis Ledger Nano app is finally available on Ledger Live! The existing 2.3.x codebase only supported consensus transactions — token transfers, delegations, governance operations, ParaTime registrations, token allowances and similar. The new 2.5.x brings support for signing ParaTime transactions such as withdrawals, deposits, transfers, smart contract instantiation, calls and upgrades, and supports all three — ed25519, secp256k1 and sr25519 encryption schemes. Let’s briefly look at why the development took so long and touch upon important milestones:

• In July 2022, the first draft of the ADR-14 spec that defines a generic hardware wallet interface for signing ParaTime transactions was proposed and reviewed. The draft was approved in September after receiving a handful of improvements.
• In September 2022, the development of the Nano app commenced and was feature-complete in March 2023. In parallel, the Oasis CLI team added support for signing ParaTime transactions with Ledger.
• From March until September 2023, an extensive testing and bug fixing was performed, adaptation to other Ledger devices and app size optimizations.
• In October 2023 the app entered the auditing process by the Kudelski IoT Security Labs.
• The final 2.5.9 version that addressed potential vulnerabilities discovered during the audit was released December 13.
• In the beginning of 2024, the upgraded app was reviewed by the Ledger team and uploaded to Ledger Live! on February 13.

To try out signing ParaTime transactions with Ledger, you will need to use the Oasis CLI for now. Support for the Oasis Wallet Web is still in the works.

The Oasis Wallet Web team prepared a set of maintenance fixes in February. The dialog confirmation buttons on mobile have been revisited and made smaller (#1850). A number of deployment improvements and optimizations were merged (#1845, #1847, #1848, #1849). Finally, the Chinese translation is now enabled in default configuration (#1844). Two releases were made for those who want to host the wallet on their own infrastructure: 1.9.0 and 1.9.1. Others can access the official wallet.oasis.io website which hosts the latest stable version. 11 pull requests were merged in February.

Network Updates

In February, Mainnet and Testnet were running stable. Likewise, Emerald, Sapphire and Cipher ParaTimes were up 100%.

The current staking reward schedule defines approximately 2.5% staking reward until April 8 of this year, then dropping to 2% starting at the end of May until the end of September, then gradually dropping to 0% until the end of November. The common pool is far from exhausted, however, because it was designed in a conservative way to pay out the reward fee for all tokens being staked all of the time. This was not the case in the past, so a new governance staking rewards schedule was discussed by the community, keeping the existing 2.5% until the common pool runs out. We estimate that the pool will be exhausted in around 6 years based on the current staking rate. On February 12, such a governance proposal was tested on Testnet and is behaving as expected. This opens the way for the community to propose a different reward schedule.

Mainnet Highlights

February on Sapphire Mainnet was a month of IllumineX trading platform launch. The daily average of transactions was in the 45,000 range until February 4. Then, a huge spike followed on the day of the launch, reaching the monthly peak — 112,504 transactions on February 4 (up 47% from 76,325 on January 18). The number of transactions then steadily declined, ending in the 40,000 range at the end of the month. The daily average was 55,986 transactions in February (down 11% from 62,373 in January).

On Emerald Mainnet, the number of daily transactions was in the 3,000-5,000 range with the exception of two spikes: 10,021 transactions on March 2 and a monthly peak of 11,383 transactions on February 29 (the last month’s peak was 16,505 on January 2). The average was 5,150 daily transactions (7,172 in January).

As of February 29, 2024, the figures are slightly higher compared to the last month (the January figures in parenthesis):

• 120 (120) validator nodes
• 6 (6) key manager nodes
• 44 (42) Cipher ParaTime compute nodes
• 63 (61) Emerald ParaTime compute nodes
• 42 (40) Sapphire ParaTime compute nodes

During the increased Illuminex-related traffic, the Oasis Explorer needed a few days (until Feb 4) to be consistently up-to-date. On February 16, the Rosetta gateway saw a 43-minute downtime due to the planned upgrade by one of our partners. The remaining Mainnet services were up all the time.

Testnet Highlights

The number of Sapphire Testnet daily transactions was steady around 12,000. The average for the month was 12,469 daily transactions (7,606 in January). The peak of 13,269 transactions was on February 19 (12,964 transactions on January 23).

The Emerald Testnet chain was mostly dormant, with around 2,300 daily transactions in the last 3 months (most of them generated by the Oasis heartbeat service). The average number of transactions was 2,370 this month (2,585 in January). The monthly peak of 2,460 transactions on February 2 was lower from the exceptionally high January peak of 6,743 transactions on January 18.

Beside the Emerald and Sapphire ParaTimes, a new Pontus-X ParaTime was registered on Oasis Testnet, with the first block being mined on January 25. Currently in the test phase and only running a single compute node, this chain will become a fundamental component of the trustless data marketplace built by the DeltaDAO team. This ParaTime is also the first one to make use of the native multiple-token support, which can also be used for paying the gas fees. Pontus-X will use the EUROe token by default and the consensus TEST token.

As of February 29, 2024, the Testnet figures are slightly lower compared to the last month (the January figure in parenthesis):

• 44 (44) validator nodes
• 5 (5) key manager nodes
• 19 (18) Cipher ParaTime compute nodes
• 29 (29) Emerald ParaTime compute nodes
• 18 (21) Sapphire ParaTime compute nodes
• 1 (1) Pontus-X ParaTime compute node

On February 16, the Rosetta gateway saw a 29-minute downtime due to the planned upgrade. There were also a few-minute outages on Emerald and Sapphire Testnet endpoints, most likely due to unexpected networking issues. No other downtimes were observed for Oasis Testnet services.

Oasis Nexus and Explorer

The Nexus team mostly focused on speed improvements this month and bug fixes. Let’s see what the two new releases brought this month:

• 0.2.8 released February 4: Fixed the active daily accounts query, fixed redundant backup files with pogreb and unified logging mechanism
• 0.2.9 released February 15: Analyzer optimization for events by considering the event body, faster account total_sent and total_received queries and improved database access by using transaction batches

With the improvements in v0.2.9, DB writes are much faster and Nexus will no longer fall behind with another illuminex-sized launch. Internally, the Nexus team reindexed the entire blockchain on the staging stack, which backfilled the data from newer features into blocks that were originally indexed before those features existed. The reindex was facilitated by the DevOps team which worked on the network configuration to allow StateToGenesis calls to the node from Nexus. This is an expensive endpoint that produces a snapshot of the consensus state and takes around 10 minutes to complete locally, but possibly over one hour on slow network-connected disks. Nexus needs StateToGenesis to finalize a “fast pass” analysis over the chain, which is essential to fully reindex in a reasonable time. In total, 24 pull requests were merged in February.

The Explorer frontend team brought some exciting new features this month. For a long time, the Explorer allowed you to search by the block or round number, block or transaction hash, address and also by contract name. Now, when searching by the contract name, the search results of your query are highlighted yellow (#646, #1223). A new accounts, blocks and ParaTimes list cards was added to the Consensus dashboard (#1160, #1191, #1213, #1237, #1284). Also, the validator and account details pages on consensus were added (#1232, #1257). A UI for the new Pontus-X ParaTime was added on Testnet (#1245, #1254, #1259, #1266). Support for different native tokens was added (#1265, #1279, #1283). A new flag was added which hides all fiat values of the tokens (#1281). The type of the network upgrade proposals on consensus is now determined and correctly rendered (#1208). The exact date and time is now shown when hovering over the age component (#1230). Particular dApps can now use white-labeling in the Explorer with links to community and other dApp-related material (#1244, #1255). Other event errors than the ones originating from the smart contracts are now also shown, for example, failed deposit event (#1278), and the error messages on reverted transactions were revisited (#1296). Also, keyboard accessibility of different components were fixed (#1289, #1291). In February, 74 pull requests were merged with the two stable releases made: 1.7.0 on February 1 and 1.8.0 on February 5. You can access the Oasis Explorer on explorer.oasis.io. If you want to try out all the exciting features mentioned here, visit the development version on explorer.dev.oasis.io and report back to us!

Developer Platform and ParaTime Updates

The Sapphire dApps team developed a new proof-of-concept voting dApp that combines four exciting features:

• Trustless (no oracles involved),
• Gasless (no native tokens required),
• Confidential (individual votes are not revealed),
• Cross-chain (voter’s eligibility can be verified from an external chain).

This is a step forward from the existing Oasis Privacy Layer (OPL) solution for cross-chain communication because it removes any third-party oracles; let’s see how the new mechanism works. Suppose there is a DAO token on an external chain whose user’s account balance corresponds to the voting power of that user. When deploying the voting dApp on Sapphire, it is necessary to pass the root hash of the external network world state trie at some point in history. This is commonly referred to as a balance snapshot. When a user decides to vote, they first call the eth_getProof() on the external chain to obtain the balance of their account together with the merkel proof. Then, they submit their vote together with this proof to our dApp running on Sapphire. The smart contract verifies on-chain, if the merkle proof corresponds with the root hash stored in the contract and finally adds the vote to the ballot box. To learn more, check out the DAO demo-voting branch and the online demo here. The short term goal is to merge this cross-chain voting support into the upstream Oasis voting dApp and offer users a complete suite both for voting and creating their own confidential ballots completely on-chain.

The Sapphire ParaTime team released a new 1.3.2 version of the @oasisprotocol/sapphire-paratime npm package on February 6. The release revisits the behavior of the ephemeral ParaTime’s public key used for end-to-end encryption of the transactions (#270). Previously, the same key was used regardless of hourly epoch changes. If an application didn’t reinitialize the library over time or, for example, if a phone or a laptop was asleep for too long, the “tag verification failed” error was returned. Now, the ephemeral key is re-fetched automatically if it is older than 5 minutes.

The Oasis Web3 gateway saw a handful of notable improvements. The gas price oracle heuristics were updated to return better gas price estimates for the eth_gasPrice queries (#519). Instead of returning the minimum gas price from the recent blocks, the maximum of the median gas price from recent full blocks is returned. A new 5.0.1 version was released on February 5 containing the new gas price heuristics.

The Sapphire Localnet Docker image also saw an important improvement. Postgres initialization sometimes took longer, which caused the dependent Web3 gateway to fail at startup (#530). Now, Postgres needs to finish starting up before the Web3 gateway is launched. Also, the key manager sometimes needed another block or so to generate the public ephemeral key, which is needed for smart contracts to work. The key manager must now generate the public ephemeral key. Developers using the Sapphire Localnet Docker service in their CI may have noticed flakiness from time to time, which are now resolved by these fixes.

The Oasis documentation is richer for the following new content:

• A new gRPC chapter is available, which explains how to configure and safely expose the gRPC interface of your Oasis node externally. This enables applications such as the Oasis CLI, dApps running in your browser that need to perform actions on the consensus layer or a ParaTime, services for monitoring and controlling your node, and similar, to communicate with your private node. In a way, this chapter is complementary to the Web3 gateway chapter, which is an EVM-compatible endpoint.
• A new section describing How to migrate from EPID to DCAP attestation was added. DCAP is the next generation of Intel’s attestation mechanism in newer CPUs.
• The Oasis node System Configuration chapter received an overhaul for creating a special user for running the Oasis node, setting the process ulimit and running it. Examples are provided in systemd, Docker and runit environments.

Core Platform Updates

The Oasis Core team merged a number of interesting new improvements:

• The generation of the proof that the node exists in the merkleized key-value store was optimized by not including the full leaf node in the proof (#5531).
• Peer selection is now performed solely by the ParaTime process, which reduces the latency of the consensus code (#5546).

New CHURP secret sharing scheme functionalities have been added to the key manager. The owners of key manager runtimes can now create new schemes and update parameters, if needed (#5551). Once a scheme is created, key manager nodes can apply for a new committee (#5568) by requesting the runtime to generate a secret bivariate polynomial and return a signed checksum of the corresponding verification matrix (#5562, #5569).