| Table of Contents |
|---|
...
Question | Answer |
|---|---|
Would it be useful to provide a getter that will tell the user what the rewards amount will be if they unstake now? whats your opinion on a getter get_staking_rewards(pubkey, amount) returning a breakdown of the rewards and principle.. | I would make it more generic and not pass the amount. Also we may need to add staked tokens in get_balance. Let me spec it. (Still TBD?) |
stakefio, unstakefio is bundled, what is the fee when the bundle count is expired? | TBD: do some analysis of the finished implementation and come up with recommend. |
What are the specific logistics of daily_staking_rewards, and total_staking_rewards? | The daily_staking_rewards should only be used to understand if tokens for staking rewards needs to be minted. Both the total and the daily should be incremented together in synchrony otherwise. |
do we need to have the Rate of Exchange (ROE) stored in state. We can compute it when needed, it looks like everywhere we need it we are reading the state table with the info anyway, so its just a divide computation to arrive at the value. | its fine to use the values that make up this value and compute it on the fly as needed and not store it in state. |
What are the units of SRP. should we come up with a units of SRP for this, i also would like to understand if theres any decimal resolution necessary for SRPs (similar to SUFs).. | lets call them SUS (smallest units SRP) and lets use 9 decimals just as we do SUFs. |
When a user performs multiple stakings, lets say day one they stake 200 FIO, day 2 they stake 100 FIO, then they call unstake on 250 FIO. is it safe to assume that unstaking will perform logic that looks for the longest duration staking and apply that ROE for the amount to unstake, perform that unstake, then go to the next staking event and apply the remained to that event, and so on until all of the desired amount is unstaked, the final stake will need to be “adapted” so as to remain accurate, in this case the day 2 stake will need adapted to become 50 FIO instead of the original 100. | we just store SRPs which are computed when we stake, these are additively recorded upon staking, and decremented upon unsticking. we also store the total number of FIO which are staked per account, these are also additively recorded upon staking a dn decremented upon unstaking. so we need two numbers stored by account total_SRPs and total_staked_fio. The FIP will be reviewed with this in mind and we will attempt to clarify this at the FIP level. |
Some clarity is needed regarded what to do when there are locked tokens (Mainnet locks, and general locks) if an account has genesis locked tokens or General (FIP-6) locks are they prohibited from staking? | Accounts are never prohibited from staking. if the account has main net locked tokens, then the user may stake and unstake the unlocked portion of those tokens in that account (all unlocked tokens are eligible for staking, and should stake and unstake as expected). if the account has general locked tokens, then the user may stake and unstake the unlocked portion of those tokens in the account (all unlocked tokens are eligible for staking, and should stake and unstake as expected). the FIP will be examined to see if clarification can be added. |
RAM increment amounts are not specified for the actions in this FIP please add details for RAM increment amounts | these will be computed during development, and updated into the FIP a place holder will be added for this. |
Add a line in the implementation of actions to check for max FIO transaction size exceeded. | this will be added to the FIP |
...
Epic – FIO staking
Stories
Produce design spec, and revise FIP-21. (1 week Complete)
review internal, and community.
FIO Staking Development (3 weeks In progress 85% complete)
implement the solution as per FIP-21 and detailed development spec.
Started work March 29
constants implemented
staking global state implemented
account staking implementation implemented
port existing work to new contract fio.staking, completed
make shell of the new contract and integrate into the build.
integrate all table implementations for staking into fio.staking contract.
integrate stake and unstake shell into fio.staking contract.
Develop new logic to permit new contracts and system accounts to be added to the FIO protocol without mandatory core upgrades (completed, in QA for Bahamas)
implement and test actions to update global state for staking. In progress (100% completed)
implement stakefio (completed)
implement unstakefio (completed)
implement modified locking mechanism to support unstakefio (completed)
impelement and test incgrewards
implement and test
clrdrewardsimplement and test
recorddaily
adapt usable balance logic
adapt voting power logic
transfer
transfer using pub key
modify fee collection logic
process_rewards
processbucketrewards
processrewardsnotpic
bpclaim
bpclaim
implement the removal of expired periods during lock adaptation on unstaking.
implement the use of an existing period if there is a period in this same day during unstaking
Implement new model for general locks, place SUF amount instead of percent.
retire old lock tokens and replace with locktokensv2 table.
integrate new table throughout contracts and chain_plugin.
Dev test. (30% completed)
Regression testing (runs of fio.test) completed
dev test cases
pre existing main net locks (test all unlocking periods using transfer and vote producer) (manual testing completed)
pre existing main net locks (test staking and transfer before and after first unlock period) (javascript fio.test integrated testing completed)
modify all general locks tests to run with the new v2 general locks table.
modify performance tests to use new general locks structure
modify tests to perform auto proxy testing.
incgrewardsrecorddailyno pre-existing locks
pre existing general locks
use existing main net locked account to create general lock
pre existing main net AND general locks
develop tests matching test plan in design spec.
internal code review
internal testing review.
perform QA and resolve all issues (comprehensive QA analysis)
Acceptance testing review by product owner.
FIO staking – Security/Performance testing (dev net) (1 week)
develop tests to load system and drive volume of requests (we desire a max stakes test, and also a volume of staking unstaking requests once loaded maximally) performance test plan is still TBD.
Rollout testing (dev net) (2 days)
load previous version of contracts, perform contract MSIGs, repeat load testing.
Test net testing – (1 week)
roll out msigs, perform subset of functional tests on test net (tests to be performed are TBD)
Main net rollout (2 days)
roll out MSIGs, perform minimal success testing to verify deployment (tests to be performed are TBD).
security of the new locking actions will require relatively complete QA testing (a test plan will be published).
...
Update all SDKs to include new endpoints for staking.
FIOSdk_typescript
integrate stakefio into SDK (6 hours) (completed)
expand tests to cover stakefio in SDK (4 hours)
Integrate unstakefio into SDK (6 hours)
expand tests to cover unstakefio (4 hours)
integrate changes to get_balance (4 hours)
integrate get_staked_info into SDK (6 hours)
expand tests to cover get_staked_info (4 hours)
FIOSdk_Kotlin
integrate stakefio into SDK (6 hours)
expand tests to cover stakefio in SDK (4 hours)
Integrate unstakefio into SDK (6 hours)
expand tests to cover unstakefio (4 hours)
integrate changes to get_balance (4 hours)
integrate get_staked_info into SDK (6 hours)
expand tests to cover get_staked_info (4 hours)
FIOSdk_IOS
integrate stakefio into SDK (6 hours)
expand tests to cover stakefio in SDK (4 hours)
Integrate unstakefio into SDK (6 hours)
expand tests to cover unstakefio (4 hours)
integrate changes to get_balance (4 hours)
integrate get_staked_info into SDK (6 hours)
expand tests to cover get_staked_info (4 hours)
...
Main net (genesis) locks functional testing
APPROACH --
The approach is to cover the required regression testing as efficiently as possible, transfer fio pub key, voting for producers, staking and unstakingre are the critical calls , these calls need to be tested so as to requiring testing (and the grant amounts need to be very large grants in the 10s of M in fio), these calls need to be tested so as to ensure overflow errors are not present, and that the proper unlocking is performed by the system according to the schedule. For QA testing it will be important to create test accounts that have been granted the largest and smallest scale of FIO genesis grants (is this 100M and 1M), then test these grants in various ways throughout the unlocking periods.
The FIO Protocol will need needs to be set up to have a shorted unlocking period for testing, this will provide efficient time utilization.
set the system unlocking period to be a new pre-determined interval (10-20 minutes)
load the system with genesis grants that match closely the genesis grants provided at FIO launch
at least have a few that use the same scale of locked token values (hundreds of thousands, millions, tens of millions)
perhaps have an account directed at each test case identified.
regression test unlocking of genesis grants. (transfer and vote must both be tested to verify they unlock properly after being called)
tactic one – skip unlock periods, verify proper unlocking when periods are skipped.
tactic two – unlock every period sometime after the unlock
tactic three – wait until all unlocking periods pass then transfer or vote.
tactic four – error testing.
verify that transfers fail with more than the unlocked amount specified.
other error scenarios.
tactic five – no action scenarios
vote multiple times in a row, note that no unlocking occurs on subsequent unlocks.
regression test staking and unstaking during unlocking periods.
perform stake and unstake
shorten the 7 day unlock period on unstake to some pre-determined test duration.
perform transfers both before and after the unstaking lock period is expired.
inadequate unlocked funds.
cannot unstake more than has been staked.
more…
error scenarios
verify staking and unstaking failures
, (in the current staking branch for fio.contracts, the current time set for genesis locking periods is 2 minutes.)
The fio.test repository should cnfigure the index.js so that the only test to be run is the test stake-mainnet-locked-tokens.js
init a dev local test environment by running the 20_debug_staking.sh during chain startup. (the dev branch for staking is already set up to run this script during startup)
When the chain is initialized. IMMEDIATELY run the rpm test to run these tests.
expected results, the tests will run and the later tests MAY experience a duplicate tx error, this is OK as long as duplicate TX error is the only error you see.
these tests run minimal staking tests on the genesis locked token account and they are NOT meant to test token unlocking.
Testing Genesis locked token grant unlocking.
pre-test setup (not completed yet)
set up the 20_debug_staking.sh script to create 2 new locked token accounts
one with 10M (be sure to make lock amounts fully populated in resolution, IE 10123456123456789 to encourage overflows if they happen).
one with 1M
tests to be performed.
Test Suite 1 – basic unlock using transfer.
unlock funds on both accounts by calling transfer every 2 minutes, and verifying the proper amount is unlocked at each unlock period.
Test Suite 2 – basic unlock using vote prducers
unlock funds on both accounts by calling vote producers every 2 minutes, and verifying the proper amount is unlocked at each unlock period.
Test Suite 3 – intermittent unlocking using transfer
unlock at period 3 only then wait for the end of all locks and unlock again using transfer, verify proper amounts are unlocked.
Test Suite 5 – intermittent unlocking using voting
unlock at period 3 only then wait for the end of all locks and unlock again using vote producers, verify proper amounts are unlocked.
Test Suite 6 – errors testing.
Transfer errors testing
try to transfer more than is unlocked during period 1.
unlock period 1 funds using transfer
try to transfer successful amount.
try to transfer more than whats left, see failure
unlock period 2 funds
try to transfer successful amount.
try to transfer more than whats left, see failure
Test Suite 7 – voting tests.
perform vote and verify the voting power of each account
unlock period 1 funds using transfer
reverify voting power.
Test Suite 8 – multiple calls tests
perform vote after period 1 passes
verify lock amount.
vote again changing your vote
verify no change in lock amounts.
vote again changing your vote
verify no change in lock amounts.
wait for period 2
call transfer
verify lock amount
call transfer
verify lock amount remains as before (cuz the next unlock hasn't happened yet)
call transfer
verify lock amount remains as before (cuz the next unlock hasn't happened yet)
General (FIP-6) locks testing
regression test general locks, unlocking and transfer especially.
existing tests may be adequate for this.
Staking rewards Tests
load system with load which does not provide minting. (less than 1M staked).
verify correct BP rewards
verify correct staking rewards.
load system with load which does provide minting. (more than 1M staked)
verify correct BP rewards
verify correct staking rewards.
stakefio
Authorization Tests
call using authority not matching actor, invalid signature error.
Parameter tests
set amount 0 invalid amount error.
set amount -100 invalid amount error.
set max_fee 0 invalid fee error.
set max_fee -100 invalid fee error
set invalid tpid – invalid tpid error.
set invalid actor – invalid actor error.
Success tests
stake fio from an account that has genesis tokens unlocked. verify global state results
perform multiple consecutive stakes of varying amounts that are premised. verify global state results
stake fio from an account that has FIP-6 locked token grant, and unlocked tokens. verify global state results
perform multiple consecutive stakes of varying amounts that are premised. verify global state results
stake from an account with FIP-6 locked token grant and tokens added to account. verify global state results
perform multiple consecutive stakes of varying amounts that are premised. verify global state results
stake from an account without any locked token grants. verify global state results
perform multiple consecutive stakes of varying amounts that are premised. verify global state results
stake fio using a tpid that has this staking call being the very first time this tpid is used. and WITHOUT voting first.
verify the stake is successful.
stake fio using a tpid that been established through its use in previous calls.
verify the stake is successful.
Failure tests
stake more than account has unlocked, fio from an account that has genesis locked tokens.
stake more than account has unlocked, fio from an account that has FIP-6 locked tokens.
stake more than account has, fio from an account that has no locked tokens.
stake fio using a tpid that is NOT set as proxy (and without voting first).
unstakefio
Authorization Tests
call using authority not matching actor, invalid signature error.
Parameter tests
set amount 0 invalid amount error.
set amount -100 invalid amount error.
set max_fee 0 invalid fee error.
set max_fee -100 invalid fee error
set invalid tpid – invalid tpid error.
set invalid actor – invalid actor error.
Success tests
unstake amount less than what was staked. verify accounting. verify lock result
examine if this is necessary to test on locked token accounts. verify lock result
unstake remained that is staked. verify accounting. verify lock amount.
examine if this is necessary to test on locked token accounts.
Failure tests
unstake more than remaining staked. verify error/exceptioin.
adaptlock
Authorization Tests
call as a non system account, verify this fails with auth error.
Parameter tests
call with duration on locking period set to 0
call with duration on locking period set to -100
call with percent set to 0
call with percent set to -1
Success tests
see unstake fio success tests, these drive these success cases.
Failure tests
see unstake failure tests, these test through this logic.
updatestake
Authorization Tests
call as a non system account, verify this fails with auth error.
Parameter tests
call with invalid parameters, for each parameter, verify errors.
Success tests
call bpclaim, verify that daily staking is updated as expected.
see stakefio success tests
see staking rewards tests.
Failure tests.
evaluate, and discover any test cases necessary.
...