Sommelier v7
It’s our pleasure to announce that Sommelier v7 has been released. This post is a companion to the upgrade proposal that will be going out today, Feb 4th. We are targeting an upgrade on Wednesday, Feb 7th, a small number of minutes after 17:00 UTC, at block 13010200.
What’s changing
This is our largest release yet, encompassing big dependency updates, new modules, and updated modules. It will see the Sommelier protocol exit its proof-of-concept phase and be the first fully-realized and decentralized version of the protocol.
Dependencies
- cosmos-sdk v0.46.14
- ibc-go v6.2.0
- tendermint replaced with cometbft
New modules
x/auction
The auction module will conduct dutch auctions of fee tokens collected from cellars. The chain will evaluate every 15000 blocks whether to start an auction based on how many times a given denom has been received by x/cellarfees. Prices for each token are determined by governance, and expire every 8 weeks if a proposal does not update them. Fee tokens will be purchased using SOMM (with a minimum bid of 1 SOMM). Prices for fee tokens are set artificially high (52 week highs), and the price for SOMM is set artificially low (52 week low). This will ensure that auctions start at a high price, and one will want to wait for the price to decrease into a desirable range as it decreases every 10 blocks. The longer an auction goes without a bid, the faster the price will decrease. Purchased denoms for the moment will be gravity-bridged tokens from Ethereum mainnet. If you want to transact them on Ethereum, you must bridge them back.
We will be providing more detailed documentation on participating in auctions over the course of the coming week. The first auctions will not occur until block height 13110000, which is approximately Feb 14th 2024 at 07:45 UTC.
x/axelarcork
The axelarcork module will enable the chain to add and manage cellars on EVMs that are supported by Axelar, with the exclusion of Ethereum mainnet, which will remain managed by our own gravity bridge deployment. Cellars are added in a similar way to the existing x/cork module via governance proposal. Relaying corks to Axelar is handled via IBC and Axelar’s GMP implementation, and is permissioned to the axelarcork module account as a sender. Relays can be permissionlessly triggered by sending a MsgRelayCork with gas payment included. Additionally, our Axelar proxy contracts can be upgraded using a special governance proposal, which will, after a fixed delay of a couple days for safety, transfer cellars to be owned by the new proxy contract.
Axelar corks will be sent with a target block height at which they will become relayable. They include a nonce, which will be invalidated if any higher nonce is seen for that target contract, and a deadline (in UTC epoch time), after which the proxy contract on Axelar will no longer execute them.
A test cellar on Arbitrum is included in the v7 upgrade. Some mainnet testing will be conducted to ensure everything works as expected before Axelar cellars are deployed.
x/pubsub
The pubsub module fully decentralizes the role of strategists. During our proof-of-concept period, we worked exclusively with Seven Seas to test the protocol and develop Steward to suit the needs of strategists, and hardcoded them as an authorized publisher in Steward. Now, permissions to act as a strategist, publish updates to cellars, and for validators to subscribe to those updates are all managed on-chain.
These are the elements of the system:
- Publisher: a strategist, identified by a domain name, who sends updates to cellars. Publishers will provide a TLS CA certificate that steward will use to identify authorized calls from the Publisher.
- Subscription ID: a string representing a cellar, in the format “<chain_id>:<cellar_address>”
- PublisherIntent: a publisher can use their SOMM account to indicate their intent to send updates to a given subscription ID
- Subscriber: a validator who wishes to receive updates from publishers and vote on cellar rebalances
- SubscriberIntent: a subscriber who wants to receive updates from a specific publisher for a given subscription ID
- DefaultSubscription: when a cellar is added, a publisher domain is included as a required field, and by default subscribers will receive updates from the Publisher indicated. A subscriber can override this default at any time by setting their own SubscriberIntent to another Publisher.
Publishers can only be added to the system via a governance proposal. An AddPublisher proposal will contain the following fields:
- Publisher domain
- Publisher Sommelier account address, which will be used to control the publisher
- Proof URL
- self-signed CA certificate in PEM format
When evaluating an AddPublisher proposal, consider the following:
- Who owns the provided domain? Are they the entity they claim to be? Should they be trusted as a publisher? Have they provided confirmation on other communication channels of their intent to become a publisher on Sommelier?
- The Proof URL is meant to prove ownership over the provided domain, and should be of the format:
https://<publisher_domain>/<publisher_account_address/cacert.pem
Where, when retrieved, the contents of cacert.pem matches the provided CA certificate in the proposal. This cannot be automatically verified by the chain, so it is recommended that a voter checks this themselves before voting. The downloaded file should be a text file in PEM format, and should never be treated as an executable – anyone can submit a proposal, be careful about where you download files and what you do with them.
If you are a Publisher interested in submitting a proposal to be added, it is recommended that you reach out to the team to better understand the technical requirements of integration. Further detailed documentation will be provided in the coming days on this process.
Steward will compile a list of authorized client certificates by creating a trust store from the set of CAs in the list of authorized Publishers. Authorization to receive updates for a given cellar will be determined by the list of default subscriptions, which can then be overridden for individual validators who set their own subscriber intents.
Rather than use the now-deprecated Steward Registry (at GitHub - PeggyJV/steward-registry: Temporary measure until pubsub module is complete), validators should use their orchestrator keys to register their Subscriber, which will include their CA certificate and Steward URL. For validators who were already part of the Steward Registry, your Subscriber objects have been included as constants in the v7 upgrade and will be present already. For all others, the Steward binary includes a command to add your subscriber and will automatically use the orchestrator key in your Steward configuration.
Updated modules
x/cellarfees
The cellarfees module was originally added as effectively a skeleton module to create a module account where cellar fees would be directed. Fees from managed cellars have since been directed into this module account as gravity-bridged Ethereum tokens.
A parameter in cellarfees will trigger auctions every 15000 blocks if the denom in question has been sent to twice since the last auction. This is tracked by hooking into gravity sends to this module account and incrementing fee accrual counters.
Once auctions are completed, the SOMM used to pay for the fee tokens is sent back to cellarfees, which will then distribute it pro-rata to stakers over 403200 blocks, which is approximately the same as our 28 day unbonding time.
x/cork
Consensus version 2 of the cork module simplifies the scheduling of corks from a strategist perspective by letting them specify a target execution height and query results of the votes for a given cork using a newly-created identifier. Additionally, proposals to add new cellars in cork now include a required publisher domain in order to create a default subscription.
x/gravity
Various small state-breaking improvements, none of which materially change the interface to gravity but should prune a lot more old state to reduce the size of the chain.
Validators beware that slashing will soon be enabled for Gravity. Failing to keep a properly signing Orchestrator will result in jailing and loss of some stake.
Upgrade process
This upgrade will be a bit more involved than previous ones, since the node, the orchestrator, and the Steward server must all be updated. The recommend process is as follows:
- Prepare your sommelier v7.0.0 binary. With this version of the SDK, it is required to build using Go 1.19 if you are compiling it yourself.
Release:
2. Prepare your steward v4.0.0 binary for your orchestrator and steward server (if you are still using gorc for your orchestrator, you will also want to use gorc v4.0.0).
Steward release:
gorc release (almost everyone will not need this, do not use unless you are certain):
3. Just before the upgrade height, turn off your steward server, then your orchestrator.
4. Proceed with the sommelier node upgrade process at the upgrade height. Note: this SDK version may take a bit to come back online as it rebuilds the IAVL store for faster access.
5. Update your steward (and/or gorc) binaries.
6. Turn your orchestrator back on, then your steward server.
Thank you
Many months of engineering work have gone into this, our largest upgrade yet. Special thanks to Eric Bolten, Mantas Vidutis, and Ukpai Ugochi, engineers who all contributed to the protocol and have already, or are moving on from the Sommelier team.
Thank you again for your continued support of Sommelier!