Launch App

Sommelier This Week - April 1st 2021: Gravity Bridge and Private Testnets

It’s been a really exciting week at Sommelier. Last week was the launch of our state machine application’s front end. Among the many things that the development team had going on was to support the effort to ensure it could go as smoothly as possible.

Test Net, Test Net: One, Two, Three

Jack Zampolin, VP Product, who heads up the engineering team explains: “A lot of effort went into the data engineering to support the graphs that you’re seeing on app.sommelier.com as well as the front end, which went through multiple iterations, design as well as user testing. Kevin and Lucky are doing some amazing work on the front end, but there are always issues on launch to which the team has to respond.”

At the same time, developers worked on key pieces of back-end infrastructure as the team participated in two private test nets and responded to lessons learned.

Following is a look at test nets #1 and #2 and the readiness of these essential pieces, progress on their integration, and the skills needed to be a Sommelier validator.

The Sommelier Protocol

As a state machine, Sommelier relies on external data. The Sommelier protocol currently is made up of three key pieces: the gravity bridge, the oracle, and a module that consumes both of those in order to provide the stop-loss functionality that sits on top of that.

“Getting this sort of cross-chain communication and these bridge technologies correct is the foundation on which everything else we’re building goes,” says Jack, whose previous experience includes bringing up the original Cosmos Network. “For gravity itself there are additional processes that you need to run. To follow data from Ethereum you need to run an Ethereum-like client as well as a couple of other things. The oracle technology that we have requires running graph nodes and an oracle feeder.”

Diving a little deeper into how Sommelier is shaping up, we present...

The Gravity Bridge

Currently, we’re working to develop the gravity bridge technology closely with Althea, Injective Protocol, and others in the Cosmos ecosystem. Sommelier’s engineers recently supported two Althea team test nets as well as participating and contributing improvements upstream into the core gravity repository.

This past week the team worked to ensure that Sommelier’s graph node data is timely, so when users load the page it shows up really quickly and as fine-grained as users need for the type of analysis they require.

Jack shares some perspective on the effort: “If you want to get that data by querying the blockchain systems directly, it would take way too long and you would need to run quite a bit of really redundant infrastructure. And, historical queries on the Ethereum blockchain as well as application specific data, still would be very difficult because you have to do a lot of historical queries in order to populate a few months of a graph.”

The way this normally works in legacy banking or ad tech markets is that you have a separate database that’s essentially caching data and providing it in a much more structured way, and doing user queries ahead of time so when the user requests that data it comes out really quickly.

And, if you’re a blockchain, all the historical trades on Uniswap are on the blockchain and you’re going to have to be able to query this. And, when you’re running a node, not every node has all of this data. A lot of nodes just keep recent data and they don’t index that historical data. So, there’s a lot of work that has to go into indexing and efficiently serving that data. And, as a validator you have to provide a list of what the top 100 or 1,000 markets are on uniswap and you’re updating that feed continuously.

Juggling Multiple Processes

Cosmos validators are normally used to running only one process, which is the validator, and maybe a couple of sentry nodes and a few other things. In contrast, to properly run a validator on the Sommelier network, you need to run an Ethereum node, an indexing service, and also processes to submit transactions from both of those onto the blockchain.

That accounts for five pieces of software the team addressed in the first private test net. What made it challenging is figuring out the order in which you install this software. For example, if the blockchain node requires some contract addresses on Ethereum this order of operations, especially as you add more and more pieces, becomes increasingly difficult.

Jack explains: “One of the things that we did really well when we launched Cosmos and were working on that system, we made sure we had a really tight startup system that’s very easy to do in a centralized fashion. In these initial test nets what I’m looking for are places where there is an impedance mismatch.”

All of the development work we’ve done so far is just building out the raw functionality to make this network happen. And, I think that the positive learnings from this are we have all that functionality built out and it works and that’s great. The learnings that we need to take back and really reflect on are how do we make this easier for users and how to make this sustainable for a public network.”

Bringing up a Cosmos Network for Sommelier starts with Cosmos expertise and as Jack puts it, “we’re adding on these additional layers of complexity and now have to take the time to ensure that that’s able to be run by the average validator and it’s also a little less error prone. Right now there’s a lot of opportunity for human error and we can change some small pieces of ordering during the startup procedure to make that drastically easier and way less error prone.”

Oracles Tell It Like It Is

There’s a lot of discussion about oracles lately. Essentially, any time you have a state machine or an application that relies on external data, you need to certify the data coming in.

“Sommelier is comfortable with the security model of relying on a vote of the validators to provide reliable and consistent data,” says Jack.

What that means is if even one or a small group of those validators is producing fraudulent data, trying to profit off of market movements, that will be ignored, and the real data that is voted on by the vast majority of those validators is what the system is going to use to make those decisions.

“This is a very secure oracle design that requires all of the validators, so in the case of Sommelier, that’s probably going to be on the order of 30-60 different independent parties to bring the same data to the party,” says Jack. “Then, that gets averaged and smoothed out and committed to the state machine. That’s what we’re using to check to see if there’s impermanent losses on your possessions.”

This differs from the way most Ethereum DeFi Products work, built on top of a multi-state. They’re comfortable and familiar with the security model that gives four or five named parties as responsible for the security of the network.

“Over on the Cosmos side, we tried to engineer out of a named subset of responsible parties and tried to make these systems permissionless and as trustless as possible,” says Jack. “Instead of saying we’re comfortable with a small subset of about four responsible parties bringing this data in, we’re saying we’re really not comfortable with that as a long-term security model. This is like writing a back-door that allows a small subset of keys to control the system -- that back door is exploitable. It degrades the security of your system as a whole.”

“It’s a massive engineering effort. We are currently working on a refractor of some of those internal systems and working on smoothing out how gravity is deployed. Part of the test net that we were doing was ensuring that we have the internal competency to a.) deploy gravity and b.) get some user experience feedback as users of gravity deploying that as well as the other different aspects of our platform.

Looking Ahead to Test Net #3

Looking ahead, the team will be reflecting on what they’ve learned, such as the need to fix some of the order of operations issues with network boot by making the exact order of operations to start up a Sommelier network a more asynchronous process.

“Then we’re going to run more frequent and persistent test nets as an internal development team and work to fix some of these issues,” says Jack.

Validators Wanted

Within the next couple of weeks, Sommelier will be formalizing this process by bringing in community members and others interested in becoming validators. We’ll have more information on that soon prior to our public test nets.

What’s needed to be a good validator? “This is going to be like validating on Cosmos SDK ++,” says Jack. “More complexity, more pieces. A much more complex system.”

Sommelier has data requirements between services. As the coprocessor for Ethereum, we’re intertwined with an Ethereum blockchain. And, with that comes a lot of Ethereum expertise that I think is going to be new for a lot of Cosmos validators.

Prerequisite: Already validating on a Cosmos SDK-based network.

Skills Needed: The ability to run a very complex and multilayered system with a number of different components.

Examples include:

Dev Ops skills required to run persistent web services across a wide variety of disciplines.

More traditional Ops experience working in a large corporation that has a data pipeline with a few different layers of caching and servers with a major database.

Ethereum community members comfortable with Ethereum tooling. This is an additional competency that you’re going to need as a Sommelier validator.

Please ping Jack, Taariq, or Mario at to learn more https://me/getsomm