spike(staking): subnet staking on 42 and 59: miners and validators (?)

[teslashibe]

Problem

There is a major coordination problem wherein all parties in the Bittensor ecosystem compete against each other rather than coordinate with each other for a common goal

1. Where do we deploy the SDK for contract interaction?

[teslashibe]

https://github.com/masa-finance/masa-contracts-staking

We can use existing staking logic and contracts that are pre-audited

[grantdfoster]

EVM based contracts are the easiest first approach

[grantdfoster]

Key features:

• no cooldown period
• stake / unstake / slash (user / validator)
• hotkey <> address mapping (validator)
• access control (owner, validator)
• distribution of MASA (sep spike, validator, could be set in proportional to weights)

[grantdfoster]

Foundry > Hardhat

[grantdfoster]

A repository has been created here to test the theories of this spike, using the former staking contract as inspiration. The MasaSubnetStaking contract can be tracked here

Reusable Components from Existing Contracts

1. Access Control and Security:

   • Both MasaStaking and MasaStakingV2 utilize OpenZeppelin's AccessControl to manage roles and permissions. This is crucial for defining roles such as admin, validators, and users, ensuring that only authorized entities can perform specific actions.
   • Reusability: The AccessControl pattern can be directly reused in MasaSubnetStaking to maintain a robust security model.

2. Staking and Unstaking Logic:

   • The core logic for staking and unstaking, including the management of user stakes, calculation of rewards, and handling of staking periods, is well-defined in the existing contracts.
   • Reusability: The staking logic, particularly the stake and unstake functions, can be adapted for MasaSubnetStaking with modifications to accommodate any new requirements or optimizations.

3. Event Emission:

   • Events such as Staked, Unlocked, and Claimed are used to log significant actions within the contract, providing transparency and traceability.
   • Reusability: These events can be reused or extended in MasaSubnetStaking to include additional parameters or new events specific to subnet operations.

4. Interest Calculation:

   • The contracts use a consistent method for calculating interest based on the staked amount and predefined interest rates.
   • Reusability: This calculation method can be reused, with potential adjustments to interest rates or periods to fit the subnet's economic model.

5. Reward Management:

   • The management of rewards, including reserving and distributing them, is a critical component of the existing contracts.
   • Reusability: The reward management logic can be adapted to handle subnet-specific reward distribution, possibly integrating with a broader network reward system.

Focus on MasaSubnetStaking.sol

For the MasaSubnetStaking.sol contract, the following considerations and improvements can be made based on the reusable components:

1. Integration with Subnet Features:

   • Hotkey to Address Mapping: Implement a mapping system to quickly associate hotkeys with validator addresses, facilitating efficient operations within the subnet.
   • Slash Mechanism: Introduce a slashing mechanism that allows validators to penalize users under certain conditions, enhancing security and compliance within the subnet.

2. No Cooldown Period:

   • As per the prompt, ensure that the staking and unstaking actions do not have a cooldown period, which may require adjustments to the existing logic.

3. Enhanced Access Control:

   • Extend the AccessControl to include subnet-specific roles, such as subnet administrators or special validators, to manage subnet operations effectively.

4. Flexible MASA Distribution:

   • Implement a flexible distribution mechanism that allows for separate spikes and validator rewards, potentially using a weighted distribution model.

5. Potential Vulnerabilities and Improvements:

   • Gas Optimization: Review and optimize the contract for gas efficiency, especially in loops and storage operations.
   • Testing and Auditing: Conduct thorough testing and third-party audits to ensure security and reliability.

Code References

• Access Control and Security:

import {ReentrancyGuard} from "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
import {Pausable} from "@openzeppelin/contracts/security/Pausable.sol";

• Staking and Unstaking Logic:

    function stake(
        uint256 _amount,
        uint256 _period
) external nonReentrant whenNotPaused {
        require(stakingEnabled, "Staking is currently disabled");
        require(interestRates[_period] > 0, "Invalid staking period");
        require(_amount > 0, "Invalid amount");

        // Calculate the reward based on the staked amount and the interest rate
        uint256 reward = (_amount * interestRates[_period]) /
            (100 * INTEREST_PRECISSION);

        require(
            rewardsNotReserved >= reward,
            "Not enough rewards to reserve for staking"
        );

        totalStaked += _amount;
        totalStakedForPeriod[_period] += _amount;

        // decrease the rewards not reserved for staking
        rewardsNotReserved -= reward;
        // increase the rewards reserved for staking
        rewardsReserved += reward;

        stakes[msg.sender].push(
            Stake({
                amount: _amount,
                startTime: block.timestamp,
                unlockTime: 0,
                period: _period,
                interestRate: interestRates[_period]
            })
        );

        masaToken.safeTransferFrom(msg.sender, address(this), _amount);

        emit Staked(
            msg.sender,
            _amount,
            block.timestamp,
            _period,
            interestRates[_period],
            stakes[msg.sender].length - 1
        );
    }

• Event Emission:

    /* ========== EVENTS ==================================================== */

    event StakingEnabled(address indexed by);
    event StakingDisabled(address indexed by);
    event InterestRateUpdated(address indexed by, uint256 period, uint256 rate);
    event CooldownPeriodUpdated(address indexed by, uint256 cooldownPeriod);
    event Staked(
        address indexed user,
        uint256 amount,
        uint256 startTime,
        uint256 period,
        uint256 interestRate,
        uint256 index
    );
    event Unlocked(address indexed user, uint256 amount, uint256 index);
    event Claimed(
        address indexed user,
        uint256 amount,
        uint256 reward,
        uint256 index
    );

• Reward Management:

    function addRewards(uint256 _amount) external nonReentrant whenNotPaused {
        require(_amount > 0, "Invalid amount");
        rewardsNotReserved += _amount;
        masaToken.safeTransferFrom(msg.sender, address(this), _amount);
    }

[grantdfoster]

Note - need to investigate how the EVM address will send along the validator / miner hotkey to the contract, ultimately linking the two! It's likely there is little to no lift on the subnet side...