August Monthly Digest: Developer Dashboard, Final Stages of FLEX, GOSH testnet and More

9 min readAug 15, 2022

Hello EverX fans! There’s been a lot of action since our last update in July as the teams within EverX work diligently on improving reliability, efficiency and the quality of our products.

A few weeks ago, the key developers of the Everscale network held an important conference to discuss the organizational aspects of Everscale’s development. This conference highlighted the decision to divide the EverX team into several product teams, all of which are already becoming independent teams within the EverX company with their own team leads.

You can read more about the important and positive changes to the structure of the core team of EverX here.

Let’s take a look at the latest developments by some of our teams:

#Evernode Platform/SDK

#Ever.Live

#Node

#FLEX

Ever.Live: Reliable Algorithms and Improving Experience

The Ever.Live team continues to work on replacing React Native components with React components in order to completely switch to React, which increases the speed of UI. One of the recent changes is a new date-time picker component based on a React library and other components under the hood.

The Ever.Live team recently updated the elections time algorithm that shows time of the next 2 elections for a new more robust version. The previous version was not able to show the time when the network stops (or in other unusual situations). The new algorithm can show this reliable information in critical situations, which is not only useful on the mainnet but other networks as well.

The team has also:

Sped up statistics for accounts;
Swapped the the old datepicker out for a more comprehensive version from the React library and adapted it for Ever.Live;

One functionality of this new datepicker is particularly useful for developers: one can now search a specific timeframe, even down to a few seconds, to find specific information.

Node: New Shard States Storage

With the help of the Everscale community, the Node team has been taking necessary actions to prepare for working on the node version update. Synchronizing these efforts is critical because this update itself is critical. It requires long-term operation with the database in order to restore it, therefore it’s crucial to arrange the order in which the validators will do the update on the node.

Currently the situation with the main network is due to the update process. Approximately 50% of the validators are running the new node and the remaining 50% are running the old node.

Also discussed by the team has been new functionalities to be embedded into the node blockchain, such as a decentralized elector and centralized file data storage (DriveChain). In order to understand the best way to implement the concepts and design a more reliable procedure while ensuring they can be stable in such a short amount of time, the team conducted multiple brainstorms.

Improvements in Operation with Blockchain State Data

The Node team has also implemented a new shard state storage, which is directly related to working with the shard state. This change improves memory consumption, stability and performance. Above you can see how a shard state can be seen as a graph of cells: mainnet contains 35 million unique cells, where each block updates x numbers of cells in the shard state. The shard state must save new cells from each new block very quickly and of course clear cells that we don’t need anymore.

Further updates include automated garbage collection, which is complex in itself as it must work as fast or slow to meet the demand of cells that exist. The minted cells in the image above are shown as white cells; the collector will remove all unmarked cells (red cells).

Luckily the algorithms work faster and use less memory, allowing the team to cut down on database usage, in comparision to the previous model.

Low Memory Mode and Fast Mode

Following hot on the tails of improvement and efficiency is the implementation of two variants: Low Memory and Fast Mode realization of a shard state. Thinking back to the previous cell image above, let’s imagine we download the shard state as a “Bag of cells”. It’s compact but we still need to deserialize, which is memory-intensive. Because it is impossible to create the same fast and slow memory algorithms, we created two variants. The first variant is the Fast Mode, which uses a lot of memory but works faster due to its optimization. The second is the Low Memory Mode, which uses approximately 5GB of memory, and is possible to adjust it to use even less memory.

Current topics the team is working on include:

Shard state storage and optimization: currently model has a very heavy garbage collection mechanism
Persistent state deserialisation: saving into shard state while the nodes boot
Stabilizing the REMP solution: thanks to the community’s suggestions, the team has began working on topics related to deploying a solution for slashing, and want to apply it to current main network
Currently in the design stage: a solution for using multiple workchains in one network
Finalizing drive chain solution

Infrastructure: GOSH Testnet

For those who aren’t yet up to speed on one of the latest ventures, GOSH is a decentralized community Git blockchain, purpose-built for securing the software supply chain, while allowing developers to build consensus around their code. GOSH is the first and only formally verified Git implementation. Recently, there has been a wave of security breaches and malware attacks affecting numerous projects that store their code on GitHub, underlining the importance of using decentralized git storage.

Testnet

The GOSH infrastructure team recently rolled out a small testnet for testing GOSH updates. It’s a network consisting of only three validators and a single host. The team has also improved the blockchain data storage system and how it is distributed between big data, which also stores data more efficiently.

GOSH CI

The GOSH CI on temporary network recently underwent a sprint where the GOSH testnet and GOSH pipeline ensures the team is able to make changes, execute the pipeline and confirm that any changes or actions in testnet does not affect the real network.

Flex: Updates Galore, Limit Orders and More

While half the team enjoys summer holidays, the other half is busy with finishing the necessary features for launching Flex DEX in the Mainnet.

We would like to remind everyone that the current version of Flex is architecturally made for the work of institutional teams. It implies that several traders can register their pubkeys with their manager (by sending a QR code to him/her) and receive funds from a central wallet. As a result, the number of contracts to be deployed at the initial authorization is more than it could be in case of a single trader only (and the whole flow obviously looks a bit complex).

While the Flex public beta in Devnet is currently available as a web app, the Mainnet institutional version will be distributed as a desktop app for security reasons. The team is now working on the system to build, distribute and update the desktop app based on the Electron technology. According to the Flex team’s roadmap, they also plan on making a simpler web version of Flex working with a wallet extension–targeting a single trader case.

Limit Orders

The Limit Order feature was recently released on public beta. Limit orders are common methods and are favored by experienced traders.

For demonstration purposes, we’ll take the action of buying .5 ETH for 8500 EVER.

We see the order doesn’t actually execute at 8500: the DeBot fills the order at 8320–buying from the orderbook at the best price available.
The concept is clear how orders are filled with the best available price and that one order can be filled from several prices.

Gas Recovery via DeBot

Another interesting feature completed is the DeBot which allows a user to recover gas by following a very simple process:

Step 1. Log in to your Surf account and run the FLEX DeBot

Step 2. Select Account Management. Here you’ll be able to see all your trades.

Step 3. Select User ID and Wallets to recover the gas.

Helpful Instructions

The FLEX instructions have been updated to include information such as How to Trade, How to Withdraw, Recover Gas Balances and more.

3, 2, 1….🚀

As the latest version of the FLEX public beta has been released to the community, the Flash Exchange crew has been heads-down conducting stress tests, finalizing the UI, and implementing all the remaining features and feedback from the community in order to make sure FLEX is ready to make its official debut. 🥳

Evernode Platform/SDK

Evercloud

Over the past few weeks the Evernode team has completed two milestones: Authorization and the Developer Dashboard.

Authorization

Authorization to Evercloud will be mandatory starting on the first of September (09/01). Be sure to get your credentials and read through the Get Started guide.

Developer Dashboard

If you’ve read through the Get Started guide you have most likely discovered the Developer Dashboard which we will continue developing as a product. Other than access credentials and security settings, the roadmap includes project analytics and, in the near future, handy developer web tools.

Client Libraries

Core (Rust)

Improved the time synchronization mechanism;
Basic Auth key was supported in network config.

Rust Changelog

JavaScript

lib-web option disableSeparateWorker.By default, lib web starts a separate worker that will utilize core (wasm). So the main thread never freezes — it is sufficient for UI. Although in some cases (e.g. when a worker already exists in an application or extension) a separate worker is a bad approach. In this case the application can suppress this with libWebSetup({disableSeparateWorker: true}).
The team also fixed some issues with memory allocation in the web version for zip/unzip operations.

JavaScript Changelog