| Table of Contents |
|---|
Links
...
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)
...
3/30 Made strategic decision to place staking into its own distinct contract and account fio.staking.
during implementation it became obvious that the implementation of staking by adding actions and tables into the fio.system contract would considerably contribute to the contract bloat of that contract.
it was also deemed somewhat more organized to place all of the structures and actions pertaining to the staking within a central contract named for this purpose, this helps to clarify the location of the key structures and actions involved in staking going forward, and also provides a clean compartmentalization of the staking data and functionality.
it will add a day or two to the project, but the gains we get by way of comprehensibility, and maintainability will be significant, and so this is seen as an easy decision.
4/1 The team met to discuss the necessity for core upgrades that are presently required to deliver new contracts and system accounts within the Fio Protocol. It was proposed that we can use the actions table to make a list of distinct system accounts and use this, and so in the future we can avoid any mandatary upgrades being required whenever new contracts and system accounts are added to the Fio Protocol.
This underwent a quick feasibility prototype which proved the concept should work acceptably.
NOTE – testing must be performed before we go forward in delivering this approach.
full playback testing
test with 400 actions in the actions table
test with 400 actions in the actions table and also perform set code on system contract.
test with 400 actions in the actions table and also perform set code on system contract after bloating the system contract to increase its size.
test that a new contract can be added using operational msig and set contracts.
After submitting the PR for these changes, work will resume on the staking project. These changes may deliver with Bahamas and so should position the protocol well for staking, marketplace, and wrapping.
4/8/2021 implementation completed and functional testing completed on changes to permit adding contracts without core changes.
4/15/2021 release testing discovered an issue with playback, a fix was strategized and implemented. This Took a few days.
4/22/2021 dev net testing uncovered some issues with support for the dev net environment a fix was implemented, this took a few days.
4/25/2021 rollout to test net with Bahamas, and work re-focuses on the staking contract development.
4/28/2021 4 system calls implemented and dev tested.
4/292021 system calls refactored into in line logic in stakefio and unstakefio (stakefio is completed and dev tested, unstakefio is 75%, need to focus next on the lock modifications to support the rest of the unstakefio implementation).
5/8/2021 completed initial testing of spendable balance for transfer, and voting weight with genesis locks and after unstaking (and so having general locks as well).
5/9/2021 completed implementation and dev test of collection of fees and staking rewards, and minting of bp rewards when BP claim is called.
5/13/2021 regression tests completed, modifications to fio.test to integrate staking specific tests begins.
5/17/2021 genesis locks dev testing is completed (test first 3 locking periods and also unlocking after all locking periods have passed).
5/17/2021 beginning to integrate the dev test plan into a set of javascript tests in the fio.test repo.
5/17/2021 Added fio.staking abi to the fiosdk_typescript repo.
5/26/2021 during the beginning of the regression tests development, it was discovered 2 important requirements are yet to be addressed.
first, when locks are adapted, old (or expired) locking periods should be removed.
second, when adapting locking periods, if there is a pre-existing period that exists on the same day as the period to be added, this period should be adapted instead of adding a new period.
both of these requirements will be addressed immediately..
5/27/2021 discover issue with the locking period precision, initial discussions with pawel, document the possible paths forward.
the limitations of 3 decimal places prohibits unstaking of small amounts (internal calculations go t zero)
recommend the use of a SUF amount for locking periods and retirement of the existing lock tokens table for general locks.
meeting is scheduled to discuss the options and decide the path forward.
6/2/2021 Decision was made to go with the use of SUF amount within locking periods.
implemented all necessary changes throughout the protocols contracts and chain plugin to integrate the vs table (locktokensv2).
modify existing staking dev tests and get clean run of these.
continue modifying all pre-existing tests for general locks.
6/7/2021 complete performance testing on modified general locks.
modify all performance tests to function with new design.
complete testing on local dev box and dev net.
6/10 Testing auto proxy uses to satisfy the staking voting requirements (as a result of a request from Paul from edge)
testing verifies that fio has a bug in all bundle fees, auto proxy is not processed in any fio bundled fee calls, only when a fee is collected.
modified the protocol to add a new set_auto_proxy in fio.common and integrate into staking.
dev test these changes by modifying startup so casey@dapixdev is a proxy and mod the tests to use him as tpid, verify that the staking code handles this as desired (the stake is called without having to vote because the tpid is specified and so auto proxy).