Versions Compared

Old Version 102

changes.mady.by.user Eric Butz

Saved on

compared with

New Version Current

changes.mady.by.user Ed Rotthoff

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Links

...

https://github.com/fioprotocol/fips/blob/master/fip-0021.md

...

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

...

  • since we will permit main net and FIP-6 locks to co-exist , we must (for unstaking only, you still cannot create a lock on an account with existing tokens), we must combine the votable balance computations to provide an accurate votable balance when both types of lock are co-existing in the same account.

...

  • When user unstakes FIO Tokens, the TPID attached to the unstake action receives 10% of the difference between tokens being unstaked and FIO Tokens received as a result of SRP to FIO Token conversion. If no TPID is provided, the 10% remains undistributed.

Requirement:

...

  • we must enforce this business rule.

Summary of changes to fio and fio.contracts

...

TPIDs will receive a percentage of the Fees AND part of staking rewards.

  • When user unstakes FIO Tokens, the TPID attached to the unstake action receives 10% of the difference between tokens being unstaked and FIO Tokens received as a result of SRP to FIO Token conversion. If no TPID is provided, the 10% remains undistributed.

Requirement: If auto proxy is used in the staking call, the code should not fail voting checks if this is the first call using tpid (when the auto proxy is being established IN the staking call).

  • we must enforce this business rule.

Summary of changes to fio and fio.contracts

  • a list of affected contracts, files and changes to files. including logic will be posted.

    • fio.common.hpp – add new constants for

      • STAKED_TOKEN_POOL_MINIMUM,

      • STAKING_REWARDS_RESERVE_MAXIMUM

      • process_rewards – modify percentages, integrate update to staking globals.

      • processbucketrewards – modify percentages, integrate update staking globals.

      • processrewardsnotpid – modify percentages, integrate update staking globals.

      • add constants for percentage amounts in rewards processing, instead of int literals.

      fio.staking.hpp

      • staking_info – struct set_auto_proxy – add a new common method to set auto proxy (usable from bundled fees in staking)

    • fio.staking.hpp

      • staking_info – struct for the global staking info records in the global staking table.

      • account_staking_info – struct for account staking info records in account_staking table.

      • add new tables

        • global_staking – the table to hold global staking info.

        • account_staking – the table holding account-wise staking info.

    • fio.staking.cpp

      • stakefio – perform the staking of fio.

      • unstakefio – perform the unstaking of fio.

      • add the following actions to the fio.staking contract

        • Code Block
          //FIP-21 actions to update staking state.

//clrgdailyrew performs the clearing of the daily rewards.
// params none!
// logic
//   set daily_staking_rewards = 0;

//incgstkmint increments the staking_rewards_reserves_minted
// params
//     amountfiosufs, this is the amount of FIO that has been minted, units SUFs
//FIP-21 actions to update staking state.

    • fio.system.cpp --add new actions for (these actions will be added to the fio.staking contract, once this is prototyped successfully this document will be updated).

      • adaptlock – update FIP-6 locks.

      • updbpclaim – update to perform necessary accounting for staking.

      • resetclaim – update to perform necessary accounting for staking.

    • voting.cpp

      • the computation of the votable balance will be modified to properly consider accounts having main net locks, general locks and staked tokens (along with the rules for voting for these)..

    • fio.treasury.cpp –

      • bpclaim – modify to perform modified logic for staking, including minting of staking rewards according to spec.

    • fio.token.hpp --

      • can_transfer, can_transfer_general – we will combine the logic of these 2 calls into one call that checks main net locks, general (FIP-6) locks, and staking amount to determine the allowability of transfers.

...

  • ABI changes will be published here as development commences.

Tables

  • fio.system – establish a new table for general locks locktokensv2 the old table will be retired.

    • establish the use of an unlock amount instead of a percentage.

  • fio.staking contract

    • staking table – this is the new table which will hold global state items relating to staking.

      • uint64_t staked_token_pool – this will be the total FIO tokens staked for all FIO users. (units FIO SUF)

      • uint64_t combined_token_pool – this will be the total FIO tokens staked for all FIO users plus the staking rewards. (units FIO SUF)

      • uint64_t rewards_token_pool – this is the value of the total staking rewards (units SUFs)

      • uint64_t global_SRP_count –this is the global SRP count used to compute the rate of exchange for staking rewards. (Units SUS)

      • uint64_t daily_staking_rewards – this is the value of the staking rewards per day. (units SUFs)

      • uint64_t staking_rewards_reserve_minted –this is the amount that has been minted so far for rewards. (units SUFs)

      • uint64_t treasury_staking_rewards –this is the amount of FIO in the treasury ear marked for staking rewards. (units SUFs)

    • stakeaccount – this is a new table that will hold staking information by FIO account.

      • uint64_t id – unique id for the staking event

      • name account – the account that staked.

      • uint64_t total_SRPs – the total SRPs to be awarded (units SUSs).

      • uint64_t total_staked_fio – the total fio staked by this account (units SUFs)

...

  • 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 clrdrewards

            • implement 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)

          perform

          • 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

            • incgrewards

            • recorddaily

            • no 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.

            • modify tests to perform auto proxy testing.

        • 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 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.

      • error scenarios

      verify staking and unstaking failures

    • inadequate unlocked funds.

    • cannot unstake more than has been staked.

      • more…

      (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 tokenstokens.

      • 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.

...

  • 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 lockstokens 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).