Tech Update #18 — September 2022

Welcome to the eighteenth edition of Vega’s mini-blog series consisting of regular tech updates from the Core Engineering Team (& close friends). These updates are designed to concisely outline where Vega is at with regard to upcoming releases and will be written by the people responsible for each project.

As we journey towards Alpha Mainnet in late 2022, we share the key insights from engineering & co, month by month.

Catch last month’s update here if you haven’t already — LINK

Research 🔬

Vega Market Simulator

A set of agent primitives which allow one to construct complex interactions and trading scenarios is provided in Vega Market Simulator. One of the agents updated recently is the momentum trader that can follow multiple momentum strategies, including RSI, MACD, etc. The calculation of momentum indicators is provided by the library TA-Lib. One can test multiple agents with different strategies in a comprehensive market scenario by following the instructions.

An example is illustrated below. We create a comprehensive market with multiple liquidity providers and limit order traders that follow the historical price of ETH: USD (from 2022–08–08 12:00:00 to 2022–09–05 09:00:00 in hour units). The plot shows the performance of a momentum trader with an RSI strategy.

We also run an uninformed trading bot with the same order intensity and order size running on the same comprehensive market. According to the comparison of the general Pnl (bottom right panel), the momentum trader can effectively react to the price trends and perform a lot better than the uninformed trading bot under historical prices.

Below is the comparison of momentum traders with different strategies running on the same market scenario.

We can see that not all momentum strategies are guaranteed to make a profit. In such a market scenario, RSI and StochRSI perform better than other strategies. Instead, the CMO strategy makes a loss.

Now Vega Market Simulator is open source and so you can try it out yourself and test your own strategies in a complex market scenario.

Written by Galen C

Core Protocol Engineering 🍎

Over the last month, the core protocol team has been working on completing the final core features for the current milestone. In addition to this, the team has accelerated development of the datanode synchronisation feature, allowing the datanode to be up-to-date and consistent during node restarts and when new validators join the network. The remaining members of the team are solely focused on testing and bug fixing to solidify the protocol for the next mainnet deployment.

VegaVisor

As of today, upgrading the protocol is near impossible, when major changes are to be implemented, without using a [Limited Network Life checkpoint restore](./non-protocol-specs/0005-NP-LIMN-limited_network_life.md). This has the undesired effect of requiring synchronous restarts and for this to happen within a short window of time so all state can be restored from Ethereum, and the network can start properly with a checkpoint. The VegaVisor protocol upgrade process enables upgrading the network both asynchronously and without a restart/downtime. The validators signal their readiness to upgrade at a block height in the future and the VegaVisor orchestrates the upgrade managing the state of the two versions. The development work on this feature has been completed and the QA team are now focused on proving its readiness for mainnet deployments.

Batch Instructions

The implementation of batch instructions adds a transaction type that allows a user of the protocol to submit multiple market instructions (e.g. SubmitOrder, CancelOrder, AmendOrder) in a single transaction. This feature provides the ability to handle batches of market instructions in a single transaction, decreasing the complexity of client integrations, and furthermore, reducing the computational and network load on both validators and clients. It will also make Vega’s functionality and APIs closer to parity with those of traditional centralised exchanges.

Datanode data synchronisation

To ensure that validators can join the network and have correct historical and current data in the new datanode a new feature is being built in order to facilitate data synchronisation and sharing on the network. This feature needs to work in conjunction with core snapshots ensuring that when a node is stopped and restarted (e.g for maintenance), or as a new validator node joins the network both the core state and the data-node data are up-to-date as per the other nodes in the network would be. This involves taking regular deterministic data-node ‘snapshots’ to both use locally on a node but also to share around the network for newly joining validators

Datanode V2 APIs

The primary focus of the other datanode team members is to ensure that all the datanode V2 APIs are present, well documented and the pagination and filtering is working as it should.

The last MVP trading-related APIs for version 2 are being added, the remaining work around V2 APIs is to resolve any bugs and issues found with pagination/filtering and to ensure that the API documentation is up-to-date.

NOTE: It is expected that the V2 API for the data will be the only API that’s used in mainnet. V1 will be removed, therefore anyone building apps on top of Vega should start to use the V2 APIs from this release onwards.

Wallet V2 API (notify V1 is on its way out)

The wallet V2 APIs are almost complete in terms of parity with V1. This API version offers increased security for users as important data is no longer input into a dApp/website thus reducing the risk of data being unintentionally leaked. The wallet will also use the APIs to ensure the wallet third-party dApp is connected to the same network. Also along this theme, it will allow verification on the network version to see if it is compatible with the wallet version or not.

NOTE: It is expected that the V2 API for the wallet will be the only API that’s used in mainnet. V1 will exist in testnet to enable the use of the hosted wallet for testing and incentives.

Written by Gordon H

Front End — Console V2 🕹

Market liquidity provision

Supplying liquidity to a market keeps open orders resting on the orderbook, to keep a relatively balanced set of orders available.

Participants who provide liquidity earn from liquidity fees, which are paid by the price takers on each trade. Liquidity fees are defined based on the commitments and proposed fee levels chosen by the providers, not by the protocol.

In order to view all this information, we have added to the console a market-specific liquidity provision view. Here you are able to see all the active and inactive participations, their commitment and equity-like share.

If you want to find out more information on how liquidity works on Vega you can check this article. For more details on how to provide liquidity on Vega, take a look at the documentation.

Written by Madalina R