[Proposal] Cosmos Hub adopt the Skip Block SDK

Hub Proposals Signaling/Text
1

[ mintscan link :link: ]

Written by Sam Hart (Head of Product & Strategy) and Maghnus Mareneck (Co-Founder) of Skip Protocol

Background

The Cosmos Hub continues to grow as a central trust layer for the AEZ and wider Cosmos. With the expansion of ICS and the addition of Neutron and Stride, the Hub has increased responsibility and importance in the security and extensibility that it can offer to the interchain.

That said, some of the Hub’s functionality is still based on dated Cosmos chain design formulated just as IBC was coming online. In particular, the Hub uses a first-come-first-serve, monolithic, and generalized mempool, and does not take advantage of any of the new Cosmos SDK advancements including ABCI++, vote extensions, or enhanced block-production capabilities that Skip has deployed widely across the interchain.

This has nothing to do with MEV

The Hub, like Bitcoin, currently has very-little-to-no MEV (we checked). This is because Hub transactions are mostly transfers, staking events, and light client updates. This is likely how it will stay, and so nothing in this proposal suggests introducing a MEV recapture or distribution mechanism. Rather, it focuses on improving the Hub revenue model by focusing on fee market improvements that have been developed and been battle-tested over the years since the Hub was first deployed.

As an aside, much of Skip’s work has transitioned from MEV capture, and into core infrastructure work to improve the Cosmos ecosystem, as demonstrated by the Skip API and the Block SDK.

Proposal

The next planned upgrade of the Cosmos Hub will have version 0.47, which natively supports ABC++ functionality (but doesn’t do anything with it). We propose putting it to work.

Our proposal: After the Cosmos Hub upgrades to Cosmos SDK 0.47 and has proven the software is stable, the subsequent upgrade should adopt the open-source Block SDK, the primary research and development focus of Skip Protocol built on ABCI++, and include the EIP-1559 fee market lane that Skip is building in collaboration with Osmosis Labs.

Why upgrade?

The current fee market on the Cosmos Hub, controlled by the Global Fee Module, is very rudimentary and overdue for an upgrade. Transactions are charged a minimum fee irregardless of network load or demand, which is set by governance. Individual validators may choose to responsively increase fees by changing their local configuration. This causes several of problems:

  • In order for the Hub to capture additional revenue when the network has any kind of increased load, validators must monitor the mempool and create their own pricing software that resets their configuration file.
  • There is no way for clients to know what fees validators have set locally, meaning wallets and front-ends must guess what fee to set beyond the base fee level. This can cause failed transactions, or transactions may wait in the mempool without ever being accepted. Empirically, most validators use the global fee default, however validators will make such changes to their local fee settings if the Hub ever encounters a spike in transaction load.
  • The Hub is overcharging users for transactions when there is little demand for blockspace and plenty of compute resources available
  • And most importantly, The Hub’s performance and liveness will be significantly degraded if there is demand for blockspace (e.g. more light client updates from more IBC connections, or many more ICS chains deployed). More concerning is that the Hub is extremely vulnerable to DDoS today.

That is to say, the Hub’s fee market needs an update to scale and meet the needs its current security offering. Although the Hub has operated without incident to date, this could change quickly, and it will be too late once it does.

How EIP-1559 fixes the issues above

EIP-1559 is the adaptive fee market developed within the Ethereum community. Sam Hart worked on EIP-1559 at the earliest stages, helping to validate the design. Additionally, while at the ICF, Sam ran the fee market working group, which mapped out various fee market designs for Cosmos. This work led to changes in Tendermint that allowed for fee prioritization, and generated ideas that would eventually lead to Sommelier’s multi-token auction model, as well as Osmosis and Notional’s work on cross-chain fee abstraction.

Since deployment EIP-1559 has processed over billions USD-equivalent in fees, and proven itself as a robust and UX-friendly fee market design.

The TLDR of EIP-1559 is that it implements a “base fee” and a “priority fee.”

  • The “base fee” is a variable, dynamic fee that adjusts with demand (measured by percentage of gas limit used). This is required for inclusion, and is easy to calculate and expose to wallets from any node on the network.
  • The “priority fee” is an optional tip that users can add on top of the base fee to receive priority execution. Paying a higher priority fee than another transaction will ensure that the higher paying tx will be included first. We don’t anticipate priority fees being very relevant for the Hub until volume scales.

You can read a detailed description of EIP-1559 here.

Why the Block SDK is the best way to implement EIP-1559

ABCI++ allows applications built with the Cosmos SDK to have a say in block production. Comet-BFT passes a list of raw tx data to the application, which can sort or otherwise process the transactions before they’re executed.

The Block SDK builds on top of ABCI++ to abstract blocks into a series of “lanes.” Like a highway, a block can have “lanes” dedicated towards specific use cases. In the case of sovereign chains like the Hub, this would be an EIP-1559 lane. In the future, it could include other lanes based on the Cosmos Hub community’s feedback (like a free lane for new users, a lane dedicated for light client updates or ICS packets). Lanes can be configured to take up anywhere from 0-100% of total blockspace, providing a flexible format for meeting the community’s blockspace needs as they arise.

The Block SDK has already been built and audited (by OtterSec), we also have an ongoing engagement with Informal Systems to audit future iterations of the Block SDK. We have fully specced out the EIP-1559 lane and fee market, and will build, test and deploy this lane, available for immediate adoption over the next few months. It is purpose-built for Cosmos chains, and would make an excellent, purely value-additive improvement to the Hub.

How to deploy the Block SDK

Skip would PR the Block SDK and EIP-1559 lane (nothing related to MEV) to the Hub repository. Skip will ensure our software is compatible with the Fee Abstraction module, the subject of Cosmos Hub proposal 810. The PR will be reviewed by all relevant teams and community members maintaining the Hub codebase. After sufficient testing, the Block SDK would be deployed in the following upgrade, pending ATOM governance approval of the software upgrade.

Skip maintains and continues to improve the Block SDK and EIP-1559 implementation, and would share any improvements with the Hub as they develop.

Timeframe

The Block SDK, as mentioned before, is fully built and currently in audit. The EIP-1559 lane will be completed in the next two months, including a testing suite and load-performance analysis similar to the Vote Extension testing that Informal conducted.

Our Ask

Neither Skip or any affiliated parties are asking for anything. No ATOM from the community pool, thanks :slight_smile: We’re happy to implement this pro-bono, as we view it as an essential improvement for one of the most important players in the ecosystem we’re all part of.

That said, we would love feedback on this proposal, and always happy to get involved in the comments section!

28 Likes
2

Will be the easiest yes vote in quite a while. Exciting!

11 Likes
3

This is an awesome idea. Certainly in favor of it! Glad to see more developments to improve ATOM tokenomics and Hub sustainability.

6 Likes
4

easy yes. Congratulations Atom community

4 Likes
5

Seems like a no brainer to me.

2 Likes
6

Interesting. Seems an easy ‘yes’

2 Likes
7

I think that this is a important and well reasoned proposal.

The current way that we do fees adds additional danger to the systems that we are building and does not allow for demand pricing.

Notional supports this proposal and because we feel that it is an important security improvement to the stack, we are happy to help in implementation and testing.

In fact, given recent research into the fee systems used in cosmos, I think I need to say that I think that after some review and testing, it likely makes sense to attempt to upstream this into the SDK itself because it makes the systems that we build safer and more reliable.

5 Likes
8

Great team, even better product - YES!

2 Likes
9

I fully support this <3

10

Frankly this proposal is a very good idea and doesn’t require any refining. Even though we believe that its implementation isn’t necessarily an immediate requirement. This is still a problem that will likely grow over time and we also believe that having a proactive approach is always a good solution. Let’s profit from the current calm environment. We will also be happy to help in testing.

On behalf of the PRO Delegators’ validator, we will greatly support this proposal. Thank you for posting it

11

Hey, this sounds really great. The lack of a sophisticated fee market in Cosmos has bothered me for a long time.

We just put out this suggested “CHIPs” process for Cosmos Hub improvements: Cosmos Hub Improvement Process (CHIPs)

Not to hijack your post, but I was wondering what CHIPs phase you consider this proposal to be at (and whether CHIPs even looks like a good process to you)? To me, it seems like we are at phase 4: signaling proposal, since the design and implementation work has already been done.

Maintenance

Either way, my main concern here is maintenance. I have the following questions:

  • How will ongoing maintenance (SDK version upgrades, etc) be paid for? Who do you expect will do it? Will the code always be owned by Skip, or will responsibility pass over to the SDK or Comet teams at some point?
  • In the scenario that maintenance stops for whatever reason, what will the impact on the Cosmos Hub be?
2 Likes
12

Actually, there’s a way that has been added recently to Gaia

You need to have access to the GRPC endpoint, for example:

$ grpcurl -plaintext cosmos-grpc.polkachu.com:14990 \
   cosmos.base.node.v1beta1.Service/Config

{ "minimumGasPrice": "0.002500000000000000uatom" }
13

that’s querying the grpc node run by polkachu, but is not querying the network itself.

14

It’s a local node parameter, so querying a specific node makes sense no?

15

not really. It’s supposed to be global, the hub uses x/globalfee to enforce a consistent fee level.

rumor has it, everything except for:

…is priced at 0.0025uatom because of x/globalfee – however if we look at blocks produced by certain validators, we can easily find that to not be the case.

I’ll watch the block log and find an example of this for you:

ergo, x/globalfee doesn’t seem to really work

Seems we just need to set the parameters correctly for x/globalfee

16

What is quoted above I am in support of; having a consensus agreed base fee, and an optional tip, is perfect.

My objection is in using ABCI++ as it was described when first announced. Unless I’m missing something, ABCI++ helps with prioritizing transactions that were already reaped from the mempool, but what we need is a way to customize the mempool to literally create new lanes each with their own underlying MConnection channel.

If a lane doesn’t have its own MConnection channel, it doesn’t make any sense to me.

If ABCI++ doesn’t support creating new lanes, I suggest we create a new message that allows for ABCI app → tendermint commands to set up independent mempool lanes (or perhaps entirely independent multiple mempool reactors).

In the end this would be a modification to TM2 & Comet to allow the app to create new mempools. The ABCI++ feature of tx reordering should be arguably entirely optional.

Ultimately this was my criticism of ABCI++. What we should focus on is creating new mempool lanes with underlying MConnection channels. There is no need for a separate SDK besides upgrades to TM2&Comet and a few changes in the SDK to send new ABCI requests from the app to TM2/Comet.

Leaving this comment here as a first thought; maybe somebody can correct me if I’m missing something.

If people are interested I can prototype something in TM2 and it should be easy to port over to comet.

17

This requires every validator to expose this endpoint publicly and clients to query all validators to see their gas prices each time they send a transaction. I think we can agree this is suboptimal.

18

Hi Jae, thanks for your reply. Cosmos SDK 0.47+ has an app-side mempool, so what’s proposed here is really an augmentation of the way the mempool works in mainline SDK, modifying this system to use an in-protocol base-fee. I see the decision about where the mempool lives as largely out of Skip’s hands. My understanding is 0.47 is planned work here: EPIC: Refactor to SDK v0.47 and IBC v7 · Issue #2540 · cosmos/gaia · GitHub

1 Like
19

The migration to SDK 47 is pretty much done. We are currently waiting on the LSM’s upgrade and we should be able to deploy in v15.

1 Like
21

@jtremback just to address your point above we plan to maintain the Block SDK for the Hub and work closely with Hub development teams. We’re also speaking with Binary Builders about a long-term working relationship with the Cosmos SDK team around Block SDK support given the number of chains in the ecosystem that are now planning to adopt it.

Also if the proposal does pass we can slot in the integration in whichever release makes sense for your team. The Block SDK is exceedingly simple to integrate and we can make the PR.

We’ll be putting this up shortly. Just wrapping up our team off-site, so wanted to wait till we could give this proposal our full attention.

3 Likes