feat: support phase1 unbonding #23
Conversation
gusin13
requested review from
gitferry,
jrwbabylonlab and
jeremy-babylonlabs
| } | ||
| } | ||
|
|
||
| func (s *Service) handleSpendingStakingTransaction( |
There was a problem hiding this comment.
@gitferry would appreciate if can you review this logic, its taken from phase1 indexer.
| defer s.wg.Done() | ||
| for { | ||
| select { | ||
| case event := <-s.withdrawnDelegationChan: |
There was a problem hiding this comment.
hmm.... could you point out where we pushing event into this chan? or if it will be handled in a seperate PR?
There was a problem hiding this comment.
the diff was too big so file was hidden
| // Iterate the list in reverse (i.e. decreasing ActivationHeight) | ||
| // and identify the first element that has an activation height below | ||
| // the specified BTC height. | ||
| for i := len(s.params.Versions) - 1; i >= 0; i-- { |
There was a problem hiding this comment.
nit: let's sort the array first. just to be 100% sure it's in the right order for us to loop through
| utils.PushOrQuit(s.unbondingDelegationChan, unbondingEvent, s.quit) | ||
|
|
||
| // Register unbonding spend notification | ||
| return s.registerUnbondingSpendNotification(delegation) |
There was a problem hiding this comment.
I don't think we should pass delegation but we should use unbondingTxHex instead. If I remember correctly the unbonding tx of the delegation is filled when the phase-1 indexer observes it. So it will be empty here
There was a problem hiding this comment.
good point, you are right this seems to be a bug.
I have logged a ticket, will fix in a separate pr soon
#24
tysm 🙏
This pr adds phase1 unbonding support in expiry service
https://babylonlabs.atlassian.net/wiki/spaces/BABYLON/pages/86900834/RFC-004+Support+unbonding+of+phase-1+delegation
Fixes -
#19
#18
babylonlabs-io/staking-api-service#177
The following diagram explains the code flow
Simple explanation -
service, on start up spins up expiry poller and btcsubscriber poller
also starts go routine to handle unbonding delegation and withdrawn delegation
the expirty poller will keep looking for expired delegations and mark them as "unbonded" in the db
the btc subscriber poller will keep looking for "unbonded" and "unbonding requested" delegations and register for spend notifications. it also has a internal in memory store where it will keep track of the subscriptions it already made so it doesn't create duplicated subscriptions (the lightenening node library doesn't handle duplications, already discussed offline)
once the spend notifications are received the logic would push the delegations to "unbonding" channel or "withdrawn" channel
the channel handlers will pick up the event from channel,
unbonding channel handler when unbonding is received it marks the delegation as "unbonding" and also creates a new entry in the timelock expiry table so the expiry checker can monitor this and mark as "unbonded" when timelock expires
the withdrawn channel handler will pick up the event from channel and simply mark the delegation as withdrawn