[Proposal] Cosmos Hub adopt the Skip Block SDK

Interesting. Seems an easy ‘yes’

2 Likes

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

Great team, even better product - YES!

2 Likes

I fully support this <3

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

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

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" }

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

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

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

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.

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.

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

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

@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

Thank you for the additional information @hxrts

Adopting an EIP-1559 mempool is a mistake for the Cosmos Hub and Osmosis chains.

It makes absolutely no sense to constrain what fee the next block proposer must charge for transactions based on how full the previous block is.

In a Cosmos style blockchain, we need to treat each block as a unique auction that occurs within the next proposer.

It doesn’t matter if the previous proposer proposed a lot of transactions or a few transactions.

It is a mistake to treat previous blocks as a view of congestion in the network.

This is the wrong design and will result in worsening UX for Cosmos.

7 Likes

I think this could be accurate.

Since we have full finality, each block is fully independent of the others, especially if we do not have a mempool, aka satoshis mind prison.

3 Likes

The implementation of the “FeeMarket” module we have does not necessarily mandate including previous block capacity as a parameter, and doesn’t mandate copying EIP-1559. If we find previous block capacity is not a good signal (though I think in periods of high load like today on Osmosis, it’s hard for me to argue it wasn’t), then we can hot-swap other parameters. EIP-1559 would be a general improvement on the fee market today, and we’d love to be engaged on finding yet better ones over time that are dependent on other factors.

Finality does not seem to change the calculus of why EIP-1559 is worse for Cosmos than it is for Ethereum. In Ethereum, even though finality takes longer, block-by-block base fees are still independent, as they would be in this implementation. However, this version of EIP-1559 allows for adjustable learning rates so we could scale up/down how much we index on block size or capacity.

If we wanted a pure PGA on the Hub, it can support this too. The module is a general framework to build stateful-aware fee markets, and dynamically adjust learning parameters on a set of inputs - i.e. can create any fee market. With the Block SDK wrapping the module, we can constrain the fee market to a lane that starts at 1% of total blockspace, and increase it gradually to 100%, on any timeframe, as we gain confidence in its effects.

See (working) spec here: https://skip-protocol.notion.site/RFC-011-FeeMarket-Module-c4a7d374854e42acb3ddf752d8cc8e72?pvs=4

2 Likes

Here are my assumption.

  1. The current Cosmos mempool is riddled with extensive security flaws and will not be a part of Cosmos in near term.

  2. The idea of a widely gossiped mempool makes no sense and is not part of any successful blockchains block proposal process.

  3. There are a bunch of flaw in post proof of stake Ethereum related EIP-1559. The reality is 50% of Ethereum block space is DEX swaps and CEX/DEX arbitrage is a big consumer of Ethereum block space .

1 Like