Every "day" epoch (every 3 days, typically), module stakeibc's hooks.go initiates unbonding ATOM (and other tokens that Stride supports) if any users invoked msgRedeemStake in the preceding 3 days. Specifically, InitiateAllHostZoneUnbondings submits ICA (interchain account, or cross-chain) transactions to each host zone to unbond from its validators, according to a set of weights. Redemptions, unbondings in process and completed unbondings are tracked using data structures called records (defined in the x/records module).
InitiateAllHostZoneUnbondings uses a helper function GetHostZoneUnbondingMsgs to generate the unbonding transactions that need to be issued. This function
Gets the total amount to unbond from EpochUnbondingRecords
Calculates amounts to unbond from each validator, according to the defined set of weights (including doing some rounding and overflow math)
Creates, marshal and return the interchain-account msgUndelegate messages
Stores callback data, so that when the ack from the ICA call returns, Stride can execute cleanup logic
As an aside, the way that IBC transactions work is by processing the following 3 transactions
SendPacket (on Stride)
OnRecvPacket (on another chain)
OnAcknowledgementPacket (on Stride)
An “ack” returning just means that a relayer has executed an OnAcknowledgementPacket transaction on Stride (which can only happen after SendPacket and OnRecvPacket execute). This is an implementation detail of IBC, the ICA transaction is triggered simply by calling SubmitTxsDayEpoch.
InitiateAllHostZoneUnbondings has the outputs from GetHostZoneUnbondingMsgs, it submits the messages and marks the unbonding records "in progress".
**That's a LOT of logic in one single function. It's one of Stride's busiest methods. InitiateAllHostZoneUnbondings and GetHostZoneUnbondingMsgs are unclear and bloated.
To make this code more readable and easier to test, we should modularize it (and generally clean it up, using idiomatic golang).**
Getting started
Please create a new branch in the Stride repo, open a draft pull request and push code incrementally (here’s an example of a thorough pull request description to the Stride repo: https://github.com/Stride-Labs/stride/pull/146)
You might want to take a look at the unit tests in unbonding_records_initiate_all_unbondings_test.go. They’ll help you understand the record logic and explore edge cases as you go.
Goals
All unit tests should pass. All integration tests should pass across multiple zones.
InitiateAllHostZoneUnbondings and GetHostZoneUnbondingMsgs should be refactored and modularized (feel free to define new functions or change these functions’ names as needed). We’re hoping to use this refactor as an example for refactoring other portions of the codebase.
Best golang practices should be followed. We’re hoping to come away from this exercise with some golang learnings (how to write clean, idiomatic golang) that can be applied throughout the Stride codebase.
Background
Every "day" epoch (every 3 days, typically), module stakeibc's
hooks.go
initiates unbonding ATOM (and other tokens that Stride supports) if any users invokedmsgRedeemStake
in the preceding 3 days. Specifically,InitiateAllHostZoneUnbondings
submits ICA (interchain account, or cross-chain) transactions to each host zone to unbond from its validators, according to a set of weights. Redemptions, unbondings in process and completed unbondings are tracked using data structures called records (defined in the x/records module).InitiateAllHostZoneUnbondings
uses a helper functionGetHostZoneUnbondingMsgs
to generate the unbonding transactions that need to be issued. This functionAs an aside, the way that IBC transactions work is by processing the following 3 transactions
InitiateAllHostZoneUnbondings
has the outputs fromGetHostZoneUnbondingMsgs
, it submits the messages and marks the unbonding records "in progress".**That's a LOT of logic in one single function. It's one of Stride's busiest methods.
InitiateAllHostZoneUnbondings
andGetHostZoneUnbondingMsgs
are unclear and bloated.To make this code more readable and easier to test, we should modularize it (and generally clean it up, using idiomatic golang).**
Getting started
Please create a new branch in the Stride repo, open a draft pull request and push code incrementally (here’s an example of a thorough pull request description to the Stride repo: https://github.com/Stride-Labs/stride/pull/146)
You might want to take a look at the unit tests in
unbonding_records_initiate_all_unbondings_test.go
. They’ll help you understand the record logic and explore edge cases as you go.Goals
All unit tests should pass. All integration tests should pass across multiple zones.
InitiateAllHostZoneUnbondings
andGetHostZoneUnbondingMsgs
should be refactored and modularized (feel free to define new functions or change these functions’ names as needed). We’re hoping to use this refactor as an example for refactoring other portions of the codebase.Best golang practices should be followed. We’re hoping to come away from this exercise with some golang learnings (how to write clean, idiomatic golang) that can be applied throughout the Stride codebase.