Oasis Q2 2022 Engineering Update
The past three months have been busy for our engineering team despite all the rumblings around the cryptocurrency market.
Work has continued on our array of Paratimes, but there has also been a concerted effort to get a new confidential EVM-compatible ParaTime named Sapphire, up and running.
There have also been major developments for our Oasis Wallet (the web version) mainly because this will be the future common code base for both of our wallets: Web and Browser Extension.
There are also some developer platform updates, as well as core platform updates all aimed at improving the platform for those building on the Oasis Network.
Take a dive into the more technical things we have been up to through Q2 below!
Our Oasis Wallet — Web has seen massive development in Q2. One of the reasons is also that we’ve chosen to use this code base as the future common code base for both of our wallets: Web and Browser Extension.
In Q2, we merged 69 pull requests. Highlights are:
- Use webext-redux for the extension (#787).
- Use Parcel for building the extension and adapting things so it is buildable in the master branch (#805).
- Simplify extension configuration, env, and build scripts (#830).
- Refactor sidebar and make all buttons focusable (#821).
- Addition of Slovenian and Turkish translations (#277, #808).
- Add a notice before staking to top 20 validators to encourage decentralization (#831).
- Restyle search address box’s focus and refactor it into a separate component (#844).
- Fix keyboard accessibility after creating a wallet (#864).
- Only show send transaction component for one’s own accounts (#865).
- Add latin ext font to fix font rendering issues with non-latin characters (#867).
- Document release process (#840).
Even though the future common code base is the Oasis Wallet — Web codebase, we are continuing to improve UX and stability/resilience of our Oasis Wallet — Browser Extension.
- Fallback to gRPC when querying account’s info fails with Oasis Scan API (#257).
- Block confirming dangerous actions (i.e. making a transfer to a validator, depositing into a ParaTime to a foreign account, withdrawing from ParaTime to a foreign account, depositing into a ParaTime to a Ledger-backed account) (#271)
- Update default gas fees for ParaTime transactions to be sufficient for the recent Emerald minimum gas price increase (#261, #262).
- Fix signing transactions after importing from short private keys (#273).
- Only show ParaTimes Emerald and Cipher (#267).
- Fix displaying errors from background page (#272).
- Improved inferred types of promises and TransactionWrapper (#264).
- The Emerald ParaTime usage in Q2 has been healthy. The number of transactions was reduced due to the more successful prevention of erroneous transactions being included in the blocks. Usage in June 2022 grew steadily with a peak of more than 300k transactions per day on Jun 7 and ending the month at between 35k and 100k transactions per day.
- 65 nodes are running Emerald ParaTime on Mainnet as of Jun 30.
- 30 nodes are running Cipher ParaTime on Mainnet as of Jun 30.
Development of our ParaTimes forged ahead, full steam, in Q2.
We’ve been working on a new confidential EVM-compatible ParaTime named Sapphire ParaTime. The code is open source and has just been released in the sapphire-paratime GitHub repo. We will be launching it on the Testnet in July 2022.
Here are the highlights from Runtime SDK development:
- Add support for signed queries (#984, #980).
- Add confidentiality support to our evm module (#855).
- Add call envelope encryption support to our evm module (#926).
- Add support for tagging expensive queries and configuring max gas to be used when estimating gas while simulating txns (#865).
- Add configurable gas estimation via binary search support (#981).
- Improve EVM-compatibility and document more differences in our evm module (#983).
- Bump SputnikVM, the Rust EVM implementation we use, to version 0.35.0 (#997).
- Add config option that allows node operators to specify the max gas limit value for which they are still willing to answer the evm.SimulateCall query (#885).
- In check tx, only update fee/nonce after successful call (#864).
- To comply with Oasis Core change mandating ParaTime schedule control, always enable schedule control in the Runtime SDK (#888).
- Propagate errors in WASM lib calls (#894).
- Add optional error propagation in core. EstimateGas (#972).
- Add option to disable gas used event emission (#944, #1021).
- Decrypt confidential call’s data with previous epoch’s key for smooth operation after an epoch transition (#1023).
- Add support for WASM contract ABI sub versions to enable ABI evolution without breaking compatibility with older already deployed smart contracts (#984).
DEVELOPER PLATFORM UPDATES
Our Solidity & EVM-based smart contract development environment is available on the Emerald ParaTime on the Mainnet.
The Emerald Web3 Gateway allows legacy Ethereum applications to talk to Emerald without requiring modifications. In Q2, we merged 35 pull requests that focused on improving its performance, robustness and usability and released versions 2.1.0 and 2.2.0. Notable changes are:
- Improve cache memory efficiency (#260).
- Implement a response cache (#242).
- Add transaction and transaction receipt cache (#244).
- Add log cache (#244).
- Implement a gas price oracle based on indexed blocks (#256).
- Add support for configuring the gateway to start indexing at a specific height (#233).
- Add support for Prometheus monitoring for API endpoints (#241).
- Add metrics for PostgreSQL queries (#253).
- Properly use and propagate contexts throughout the codebase (#240).
- Add timeout to indexing a block (#238).
- Handle cases where an earlier sighting of a transaction failed and a later sighting succeeded (#207).
- Query max block gas limit (#191).
Our Rust & WebAssembly-based smart contracts development environment is deployed on the Cipher ParaTime on the Testnet. Take a look at our Smart Contracts Guide to learn how to prepare your environment for Cipher smart contract development and how to deploy smart contracts using the new Oasis CLI.
We’ve added a new Confidential Hello World guide which will guide you through writing and deploying your first confidential smart contract on Cipher!
CORE PLATFORM UPDATES
Nevertheless, our Core Platform continued to be developed at full pace in Q2.
We’ve been working on a new official Oasis Indexer which will be indexing Oasis Network’s consensus and ParaTime transactions in a PostgreSQL database and providing easy access to historical data. The code is open source and has just been released in the oasis-indexer GitHub repo. We will soon be transitioning our Oasis Wallets to use it as the preferred backend for fetching data.
Development of Oasis Core has continued at a blistering pace.
In Q2, we merged 132 pull requests. Notable improvements are (some are scheduled to land in Oasis Core 22.2 and some were backported to 22.1.x):
- Rewrite the runtime transaction pool and processing flow to enable transaction sender tracking and per-sender limits of outstanding transactions allowed in the pool (#4665).
- Improve peer prioritization when fetching storage checkpoint chunks (#4671).
- Various fixes to confidential runtime registration flow (#4678, #4683).
- Ability for compute execution nodes to handle dynamic key manager configuration changes (#4729, #4715).
- Improve the EnclaveRPC protocol to allow the runtimes to report peer feedback based on higher-level protocol indicators to make the protocol more robust (#4757).
- Add support for the latest Architectural Enclave Service Manager (AESM) protocol (#4711).
- Define Intel DCAP attestation bundle format and implement v3 quote parsing and verification logic in both Go and Rust. This will be used to gradually implement full support for DCAP attestation which will allow the use of 3rd generation Intel Xeon CPUs (#4720, #4789).
- Implement Intel PCS client to allow retrieval of TCB information and QE identity needed as part of the DCAP quote verification process (#4752).
- Implement archive mode support (#4571).
- Ensure freshness of consensus state served to confidential runtimes via light client verification and RAK registration (#4741).
- Collect runtime logs and emit as part of regular oasis-node logs (#4709).
- Make it easier to see the current node and runtime status (#4669).
Let’s Stay Connected!
If you are working on the Oasis Network and you want your progress to be included in the next monthly update, please email us at email@example.com.