fix(ibc)!: handle ibc withdrawals correctly #4787
Conversation
conorsch
added
the
consensus-breaking
conorsch
force-pushed
the
compat-return-address
branch
from
802c96e to
c14463e
Compare
avahowell
force-pushed
the
compat-return-address
branch
from
c14463e to
063bf59
Compare
conorsch
force-pushed
the
compat-return-address
branch
from
063bf59 to
3470c22
Compare
This commit adds a `logic_version` flag to withdrawals, to allow issuing compat address withdrawals. It also implements correct error handling on withdrawal attemtps when counterparty chains return an error.
conorsch
force-pushed
the
compat-return-address
branch
from
3470c22 to
76a21be
Compare
| // in the case where a counterparty chain acknowledges a packet with an error, | ||
| // for example due to a middleware processing issue or other behavior, | ||
| // the funds should be unescrowed back to the packet sender. | ||
| timeout_packet_inner(&mut state, &msg.packet) |
There was a problem hiding this comment.
So the logic in the ics 20 specification for handling error acknowledgements and for handling timeouts appears identical.
I do wonder if it would be more maintainable to make the code a bit more like spec.
Otherwise looks good
There was a problem hiding this comment.
@avahowell can comment more here but I think the goal was to have a minimal diff that used the existing (audited) code as much as possible
There was a problem hiding this comment.
Yes, I checked and verified that the behavior should be identical, then kept the diff minimal in order to minimize risk and maximize readability
There was a problem hiding this comment.
Renamed timeout_packet_inner to conform to spec:
There was a problem hiding this comment.
I went through all the files and this seems to correctly achieve that:
- that all outgoing ICS20 packets use the
penumbracompat1...Bech32 encoding, - that packet acknowledgements with errors are treated as timeouts.
One point of uncertainty I had which I managed to clarify away was whether or not we would be able to correctly handle FungibleTokenPacketData containing a penumbracompat1 address.
We can, because our handling of it uses the FromStr method for Address, which will handle both penumbracompat1 and penumbra1.
This commit adds a pd migration, intended to permit upgrade coordination, so that breaking changes related to ibc withdrawal handling can be made to pd safely. The migration doesn't alter chain state: it simply flips the halt bit off, and permits the chain to resume, after folks have upgraded to a new version of pd. This approach assumes that an upgrade proposal was submitted and passed, in order to halt the chain in a coordinated upgrade. chore: bump crate versions to 0.80.0-alpha.1
conorsch
force-pushed
the
compat-return-address
branch
from
77531fe to
49626ef
Compare
This adds a state change to the migration, in order to replace all of the packets which had error acknowledgements, so that, post-migration, the acks can be replayed with the correct logic for error acks, the packets having been replaced in the state. This also changes the IBC component visibility of a trait to reuse the logic for inserting packet commitments.
| //! There's no state-altering logic in this migration: the migration simply | ||
| //! flips the halt bit off, permitting the chain to restart post-upgrade. |
There was a problem hiding this comment.
This comment seems no longer accurate
crates/bin/pd/src/migrate.rs
Outdated
| @@ -52,6 +53,9 @@ pub enum Migration { | |||
| /// - Truncate various user-supplied `String` fields to a maximum length. | |||
| /// - Populate the DEX NV price idnexes with position data | |||
| Testnet78, | |||
| /// Mainnet-1 migration: | |||
| /// - Reset the halt bit | |||
There was a problem hiding this comment.
This comment seems no longer accurate
avahowell
force-pushed
the
compat-return-address
branch
from
c47b245 to
0e1f68e
Compare
Describe your changes
This commit adds a
use_compat_addressbool to withdrawals, to allow issuing compat address withdrawals. It also implements correct error handling on withdrawal attemtps when counterparty chains return an error.Issue ticket number and link
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: