Written by Sam Hart (Head of Product & Strategy) and Maghnus Mareneck (Co-Founder) of Skip Protocol
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.
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.
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.
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.
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.
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.
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.
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.
Neither Skip or any affiliated parties are asking for anything. No ATOM from the community pool, thanks 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!