-
Notifications
You must be signed in to change notification settings - Fork 538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for the applications specific tx ordering behavior from the comet BFT mempool working group #6159
Comments
These problems feel like they could be solved (along with other related problems) by an IBC lane in the BlockSDK Basic behavior could be something like:
(This is off the top of my head very quickly. We could come up with more intelligent versions of this) There are a lot of variations of this we've discussed internally |
It seems like there are two possible approaches here:
An IBC lane in the BlockSDK is an example of (1). I think it would be worthwhile to pursue (2) rather than (1) if possible, because it preserves the ability to use the IBC host implementation with a different consensus stack. For instance, what if someone wants to use IBC in a context where For example, why can't IBC-go correctly handle duplicate client updates without any consensus integration at all? Penumbra just does the right thing, no |
Thanks for opening the issue and the comments.
Agree. We are planning to explore how to decouple ibc-go from SDK/CometBFT and make it a generic library that can be plugged in with various frameworks/ecosystems via adapter layers. Thus solutions that don't tidy ibc-go even more with CometBFT would be preferred.
We actually do! In 07-tendermint we check for a duplicate update and no-op if that's the case. |
Yes, like @crodriguezvega mentioned and @hdevalence suggested, we currently do a no-op for duplicate updates. The reason why we don't return so early (like penumbra) is because we do a misbehavior check first. I think there might be some issues with using PrepareProposal to ignore duplicate client updates:
I'd also like to understand why |
In all current released versions of Comet BFT, the default proposer is semi-fifo. The proposer will propose txs in approximately the order broadcast but "actually the order received" until one of the system bottle necks like the ABCI mutex load, P2P bandwidth capacity or mempool size is hit and then basically nothing is guaranteed.
The semi FIFO property is going to be difficult to maintain as we try to get to a more robust design.
Right now IBC relayers depend on the semi FIFO property to reliably operate.
Newer features of the Cosmos SDK in 0.50+ would change things from relying on non specified to relaying on specific features of IBC-go. Specifically, IBC-go can hook into prepare block and improve relayer reliability under load.
The issues we are aware of are
A lot of this could be handled with prepare proposal.
The proposer could mark duplicates unexecutable and refund gas.
A collection of @ValarDragon ideas below.
"The sequence numbers are today solved via complex Authz hacks.
We can also solve them via unordered txs."
"Duplicate client updates and packet relays themselves have problems in gas charged to the relayer.
We multi-message these right now. I see two options:
Prepare proposal can also check that all ordered channel packets are being deliver in order.
The text was updated successfully, but these errors were encountered: