by Jendrik Poloczek, May 19

TLDR

Last summer, we decided to run infrastructure for our portfolio networks in-house. The Vega network, in which we’ve invested in late 2019, was ready for the launch of both test- and mainnet and held an open community call for participation for the initial validator set. We’ve been fortunate to be among them and in this article we outline: why we go into the role of an active contributor, how we got involved, how we (the validator group) are running the network, how we (the fund) run it, and where we’re going from here.

What is Vega?

Vega is a decentralized derivatives market with a fully decentralized order book, dynamic margins, permissionless market creation, and last but not least front-running protection. Our first investment into Vega was in late 2019, and we’ve been closely monitoring developments with high curiosity ever since.

Technically speaking, Vega is based on Cosmos SDK. Cosmos SDK is a framework that enables the fast creation of blockchains with the support of the proof-of-stake-based Tendermint BFT consensus algorithm that is widely used among app chains in the Cosmos ecosystem. Vega’s code is written, like Cosmos SDK, primarily in the Go language.

We support our portfolio networks

Last summer we made the deliberate decision to run infrastructure for portfolio networks in-house. First and foremost, we understand the importance of being a reputable pillar contributing to decentralization right from the start and in the maturation of new networks. For this, it’s key to take full ownership of the network infrastructure such as validators, oracles, and other required off-chain components and not to externalize it, e.g. via white-labeling/service companies.

How did we get involved?

After internal testing of the components, the core team behind Vega decided to source teams for the initial launch of the Vega network from the community. An open call to contribute followed, which stated technical/team requirements and underlined that investors in Vega would not get shortlisted. At the time, we were just starting, catching up on Tendermint BFT and the technicalities of handling key material. Earlier touchpoints with our custody providers and publicly available architecture documentation such as Certus One’s helped in preparation for the task at hand.

How we (the validator group) are running it

With the fortunate news of being accepted by the community as a validator team, we established relationships with our validator colleagues and the technical department of the Vega team. A strong emphasis on decentralization led to a self-organized group that cooperates with the team but ultimately acts independently. Experienced groups jumped in and shared their common practices, from voting for decision making to communication channels, such as a private Discord and emergency phone lists. One group set up a shared global metrics and monitoring system which continues to add additional transparency/accountability among the group.

Over time the roles and responsibilities between validators and the Vega team became clearer and led to a social consensus of expectations involving general availability for upgrades (from the validator side) and appropriate documentation for upgrades such as breaking changes and migration paths between versions (from the Vega team side).

How we (Greenfield) run it

The Vega product has been tested with users long before the official Vega validator testnet was launched. To avoid confusion: The Fairground testnet has been an internal testnet with a focus on the end-to-end product suite, whereas the validator testnet has been a testnet for running the validator code externally.

After the successful launch of the validator testnet, the team and the validator group felt confident to launch the mainnet just a couple of months later. As such, both the testnet and (restricted) mainnet have since been live, and network upgrades have happened on an irregular monthly basis. The main focus of development for validators in recent months has been the snapshot feature, which allowed validators to restart their processes without syncing the blockchain from the beginning, which would result in a long startup time. Furthermore, the automation of manual checkpoint restarts could improve the process that originally involves multiple error-prone steps.

The current required setup for either testnet or mainnet involves four different processes (with four configurations) running on three different instances (not counting sentry nodes) and four public/private key pairs including TMKMS (Tendermint Key Management System) communication keys. For running both testnet and mainnet, we end up with six instances (not counting sentry nodes), eight configuration files, and eight public/private key pairs. To ensure reliability we set up metrics and monitoring systems with a 24/7 pager and have runbooks for resolving common failure modes. We’re following the zero-trust principle for security and strive to use the latest cryptographic building blocks to ensure this.

At current market prices, $2.3M in VEGA tokens have been already delegated to our mainnet validator. A big thank you to all the VEGA holders putting their trust in the Greenfield brand.

Where are we going from here?

As we understand that security and reliability are extremely important in partaking in our portfolios’ networks, we managed to convince Simone Roselli to join as our new Infrastructure Lead to build an infrastructure team and mature processes. I’m thanking the other validator groups for the kind support, and the Vega and Greenfield team for their editorial feedback.