This post is to discuss the CIP for integrating Packet Forward Middleware as described in: CIP: Packet Forward Middleware by akc2267 · Pull Request #25 · celestiaorg/CIPs · GitHub
Integrating this IBC middleware module will enable beneficial capabilities like ibc/denom path unwinding and multi-hop IBC.
Can you perhaps clarify the tradeoffs between this in-protocol solution for automatically routing packets to a front end solution that provides the same but abstracts it for users.
As an example, I suppose that a front end solution would still require the user to sign multiple times - one for each hop whereas this middleware only requires a single signature.
On the alternative side, perhaps PFM requires more network resources i.e. more state / bandwidth consumption.
Perhaps you already have a document outlined somewhere. It would just be nice to have the pros and cons side by side
I’d also add that Celestia currently uses a TokenFilter which essentially allows only TIA (and no other non-native token) to reside on the Celestia state machine.
Practically this means that the only use case is to route TIA from one IBC chain back out to another which makes it less valuable than the chains which are trying to be multi-token hubs like Osmosis or the Cosmos Hub where routing is more common.
In the CIP call #2, you mentioned this enables a bunch of new software that you can build on top. Do you have a complete list of what it already enables or what you imagine it could enable ?
Very simply, the use case is: I have TIA on chain A, and I want TIA on chain B. But on chain A and B, the most liquid version of TIA is the version bridged directly from Celestia.
Practically, this might happen because I’m a heavy Neutron user, but Osmosis starts offering token incentives on TIA liquidity pools, so I want to move some of my TIA from Neutron to Osmosis.
In both cases, the most widely used and liquid version of TIA on these chains is the one bridged directly from Celestia.
So if PFM doesn’t exist, my desire to go from Neutron to Celestia requires 2 signing events:
Frontend solutions can’t improve this alone. With PFM though, we can construct a single transaction on Neutron that sends TIA from Neutron, through Celestia, and to Osmosis – requiring only one user signing event. We can do even cooler stuff too – like using the memo to actually atomically execute a swap or a more complex after transfer action (e.g. swapping, then transferring to another chain, then buying an NFT).
The Skip API makes extensive use of pfm to help all of the top Cosmos wallets and many frontends build flows that abstract the process of explicitly bridging, so the IBC ecosystem feels more like one chain. These include cross-chain NFT purchases (e.g. see stargaze.zone/marketplace), cross-chain swaps (see Keplr or ibc.fun), or bridging interfaces that can ingest tokens from many chains (e.g. see astroport’s bridge interface).
For clarity, with PFM, the protocol is not doing any “routing”. There’s no canonical list of routes that the protocol needs to maintain or anything like that. The protocol is just reading some memo data in the ibc transfer, then forwarding the packet along the channel specified in the memo. This requires very little additional state (the vast majority of the state consumed here is just state related to packets which exists regardless of whether PFM is used to execute these transfers or not)
In summary, I view this as a very cheap way to improve the “money-ness” of TIA. Money needs to flow easily between different markets and different communities. Introducing PFM tears down one really annoying and completely unnecessary barrier to this flow.
Let me know if I can provide any more info. Happy to hop on a call if helpful!
Thank you, that made sense.
How much state growth would adding the PMF add?
Not relatively, but concretely, what state are we adding?
There is no additional state introduced, except for the normal IBC commitments for in flight packets.
This state is identical to the state that would be created if the user created one ibc transfer to Celestia and then another to their destination.
With PFM, the state associated with the commitment to the send packet on the outbound transfer is created atomically with the receiv packet of the inbound transfer — rather than later with an additional user action
But, as has been seen on Neutron and Cosmos hub, there are serious security risks introduced, and frankly they’re very poorly communicated.
but what is more interesting, is the one that isn’t there, and the fact that numerous users of PFM were not informed about it on a private basis.
Many teams using PFM have been left in the dark on this matter.
Both Neutron and the hub will no longer sync correctly, forever, without a binary change at a certain block height.
Neutron tweeted that the issue was serious:
Then I chose to go and have a look at what had actually occurred:
And then I had a look at the patch:
and then I had a look at the patch
I don’t think that PFM is in keeping with:
As an excersize, we can apply the framework currently being developed to help make a decision on including CIP-9 Packet Forward Middleware into the lemongrass meta CIP.
[I’m only speaking from my point of view ofc]
The PFM is not only live in production for chains that secure a lot of economic value, such as the cosmos hub, but has also been used heavily during that time. Bugs and vulnerabilities have been found, but they’ve also since been fixed.
While this can be difficult to gage, it’s feasible that a bug that the PFM contributes to could impact user funds. That might not be saying that much, since it’s difficult to change the state machine and have 0 impact.
We recently found out that the PFM will infact be audited by a very reputable team, Zelic. The audits should conclude sometime in June.
While the PFM does exist within a complex system, the code itself is quite small.
++Not only does the PFM allow for dramatically improved UX, but it is quickly becoming an ecosystem standard that members directly in and adjacent to Celestia’s rely on.
I think what you’ve shared demonstrates the incredible track record of the Strangelove team in responding to security related bugs in a professional and timely fashion.
The recent Mandrake bug was deemed medium severity, meaning no risk of chain halt or loss of funds. We built an impacted parties spreadsheet composed of every chain that was listed in the dependency graph in the GitHub repo. Some teams apparently do not check their security@ email domain or other listed emails used for disclosing security related vulnerabilities. Our job was to disseminate information in a symmetrical way and we used every tool as our disposal to do just that, we cannot control other teams or set best practices for them. No clue what the syncing issue you described has to do with PFM, the patch did not involve anything that would affect this.
packet-forward-middleware is widely adopted in the Cosmos ecosystem and is currently in use by over 30 chains/projects. It has become a critical piece of software for addressing key user and developer experience pain points in the ecosystem. Yes there have been 3 bugs identified in the software in the 3 years that it has existed and been live on chain, none of these bugs resulted in a security incident and all were handled according to best security practices. Go check the number of security advisories in the Cosmos SDK and CometBFT repos, it is a non-zero number. Should we also remove these dependencies as well?
packet-forward-middleware is important for rollup interoperability, is widely adopted in the ecosystem, has been live in production environments for 3+ years, is undergoing an audit process that begins this Spring, and yes there have been 3 bugs reported in the software in the 3+ years it has been being used.
Thanks @evan for preparing that analysis! Here is my attempt at applying a more exhaustive security considerations framework to PFM.
Which chains have PFM deployed?
| Chain | PFM | Deployed since |
|---|---|---|
| Cosmos Hub | Yes | 2021-11-24 |
| DYDX | No | N/A |
| Noble | Yes | 2023-01-16 |
| Osmosis | Yes | 2023-02-08 |
A more exhaustive list sourced from @bpiv400:
Have there been any known exploits?
Could cause a chain halt (based on Pigeonfall vulnerability). Could result in user temporarily losing access to funds (based on PR description).
PFM hasn’t been audited yet. Strangelove plans to have Zellic audit PFM in May / June.
The PFM implementation exists here. It spans:
Note: file / line count is an extremely crude proxy for complexity.
The IBC memo field is unbounded. Since one byte in the IBC memo field costs 10 gas (see issue) and blob.GasPerBlobByte=8, we expect blobs to remain more favorable for large data. However, if PFM usage spikes, blocks may be filled with IBC memo data instead of blobs.
We may consider limiting the memo field to mitigate this.
Chains should ensure that there is some length limit on the entire packet data to ensure that the packet does not become a DOS vector.
I’m in favor of including PFM in the Lemongrass upgrade.
Note on audit timelines: the celestia-app v2 audit is tentatively scheduled for late May / early June which coincides with the Zellic audit of PFM. Celestia should be prepared to upgrade the PFM dependency shortly before activation of the Lemongrass upgrade if the Zellic audit identifies any critical issues.