-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Context
The Accounts State module keeps track of stake addresses, SPO delegations, DRep delegations, rewards, and pot balances. It also maintains three-epoch snapshot history (mark, set, go) for rewards calculations (IIUC) and processes epoch activity to calculate and distribute rewards. It currently expects many message types starting from genesis, building up delegation history and taking snapshots at epoch boundaries.
Problem
When bootstrapping from a snapshot (e.g., epoch 500), the accounts state module needs to initialize from messages containing parsed snapshot data:
- Stake addresses with rewards and delegations (SPO and DRep)
- SPO registrations with parameters and retirement info
- DRep registrations with deposits
- Pot balances (treasury, reserves, deposits)
- Three-epoch snapshot history (mark, set, go) for rewards calculation
The CDDL we have for the NewEpochState might be useful here.
The bootstrapper will parse the snapshot CBOR, and send the appropriate messages to initialize accounts state. This latter part must be implemented as part of this work.
Acceptance Criteria
- Bootstrapper parses snapshot and sends message with information required by accounts module
- Accounts module has message handler able to work with message from bootstrapper and initialize state properly
- Normal epoch processing continues after bootstrap (i.e we can use Mithril or Upstream fetcher post bootstrap)
Testing Requirements
- Bootstrap data validates against Blockfrost API
- Come up with other requirements if you can!
- Rewards calculations must be correct
Definition of Done
- Accounts state initializes from snapshot without replaying the entire chain's history
- All stake addresses, delegations, and rewards accurate after bootstrap
- SPO and DRep state accurate after bootstrap
- Pot balances match snapshot values
- Snapshot history properly initialized for rewards calculation
- Blockfrost API validation confirms correctness