Closed teslashibe closed 2 months ago
To reflect the complexity and non-linear relationships described in the whitepaper for utlity functions, we need can adjust the Solidity code examples for Validators, Worker Nodes, and Oracle Nodes. This involves incorporating specific non-linear functions and conditional logic that governs staking requirements and utility calculations, aligned with the performance metrics.
The utility calculation for Validators will include an exponential function to represent the non-linear relationship between their performance metrics and the staking requirements.
Revised Solidity Code for Validators:
pragma solidity ^0.8.0;
contract ValidatorUtility {
struct Validator {
uint256 stake;
uint256 numTransactionsValidated;
uint256 dataVerified;
uint256 llmOutputsEvaluated;
}
mapping(address => Validator) public validators;
// Performance coefficients, should be settable via governance
uint256 alpha = 1;
uint256 beta = 1;
uint256 gamma = 1;
uint256 lambda = 10; // Sensitivity parameter for performance
// Function to update validator metrics
function updateValidatorActivities(address validatorAddress, uint256 transactions, uint256 verifiedData, uint256 outputsEvaluated) public {
Validator storage v = validators[validatorAddress];
v.numTransactionsValidated += transactions;
v.dataVerified += verifiedData;
v.llmOutputsEvaluated += outputsEvaluated;
}
// Non-linear utility calculation using exponential function
function calculateUtility(address validatorAddress) public view returns (uint256) {
Validator storage v = validators[validatorAddress];
uint256 performanceScore = alpha * v.numTransactionsValidated + beta * v.dataVerified + gamma * v.llmOutputsEvaluated;
return v.stake * (10 ** (performanceScore / lambda));
}
}
Incorporate a dynamic adjustment based on computational power and data quality, using an exponential function to simulate the increased utility for higher performance.
Revised Solidity Code for Worker Nodes:
pragma solidity ^0.8.0;
contract WorkerNodeUtility {
struct WorkerNode {
uint256 stake;
uint256 computationalPower;
uint256 dataQuality;
}
mapping(address => WorkerNode) public workerNodes;
uint256 alpha = 1; // Weight for computational power
uint256 beta = 1; // Weight for data quality
uint256 lambdaW = 5; // Sensitivity parameter
// Update metrics for worker nodes
function updateWorkerNodePerformance(address workerAddress, uint256 compPower, uint256 dataQual) public {
WorkerNode storage w = workerNodes[workerAddress];
w.computationalPower += compPower;
w.dataQuality += dataQual;
}
// Non-linear utility calculation
function calculateUtility(address workerAddress) public view returns (uint256) {
WorkerNode storage w = workerNodes[workerAddress];
uint256 performanceScore = alpha * w.computationalPower + beta * w.dataQuality;
return w.stake * exp(performanceScore / lambdaW);
}
// Helper function to calculate exponential
function exp(uint x) private pure returns (uint) {
return uint(keccak256(abi.encodePacked(x))); // Simplified; use actual exp calculation in production
}
}
Oracle Nodes' utility will be adjusted for their resource usage with an exponential function to accurately represent the impact of high resource consumption.
Revised Solidity Code for Oracle Nodes:
pragma solidity ^0.8.0;
contract OracleNodeUtility {
struct OracleNode {
uint256 stake;
uint256 resourcesUsed;
}
mapping(address => OracleNode) public oracleNodes;
uint256 lambdaO = 20; // Sensitivity parameter for Oracle Nodes
// Update resource usage
function updateResourceUsage(address oracleAddress, uint256 resourceAmount) public {
OracleNode storage o = oracleNodes[oracleAddress];
o.resourcesUsed += resourceAmount;
}
// Non-linear utility calculation with resource usage
function calculateUtility(address oracleAddress) public view returns (uint256) {
OracleNode storage o = oracleNodes[oracleAddress];
return o.stake * exp(o.resourcesUsed / lambdaO);
}
// Helper function for exponential calculation
function exp(uint x) private pure returns (uint) {
return uint(keccak256(abi.encodePacked(x))); // Simplified; use actual exp calculation in production
}
}
lambda
) should be adjustable through governance mechanisms to adapt to network evolution and empirical data.@mudler @teslashibe @H34D @Luka-Loncar Some questions:
Here are the answers:
Question: Should there be a minimum amount required for staking? Should this minimum apply to the total staked amount or to each individual staking action? Answer: According to the technical whitepaper, the staking requirements for each role (validator, worker, and oracle nodes) are determined by performance-sensitive staking mechanisms. The staking requirement for each role is defined as a proportion of the total token supply, adjusted by a monotonic function that maps the node's performance to a staking coefficient. The whitepaper does not specify a fixed minimum staking amount. This quote is from @teslashibe: "Think about adding starting/minimum/dynamic staking for each actor. This is currently missing from requirements. Forgot to add this to ticket. Staking requirement for each actor should be modifiable by the validator role." You can find it in this link
Question: The technical paper states that "validators must stake MASA tokens as collateral." Does this requirement also apply to worker and oracle nodes, meaning all roles can only stake MASA tokens? Answer: The technical whitepaper clearly states that validators, worker nodes, and oracle nodes must stake MASA tokens as collateral.
Question: The technical paper mentions the TAO token but does not specify its use. Can TAO tokens be used for staking, rewards, or both? Answer: I'd like us to get more clarity here from @teslashibe since the technical whitepaper mentions the TAO token as part of the dual-token economic model, alongside the MASA token. However, the specific use case of TAO tokens within the staking smart contract is not clearly defined in the whitepaper.
Question: Can a single account hold multiple roles (e.g., validator, worker, oracle)? This would simplify the creation of a single staking smart contract for all roles. Answer: Whitepaper does not explicitly state whether a single account can hold multiple roles (e.g., validator, worker, and oracle). However, we should consider the potential implications of allowing multiple roles per account, such as centralization risks and the impact on the overall network dynamics. On top of that, I'm not sure if this is related, but during hackathon Vasilis got his nodes banned when he was trying to run validator and worker nodes from same computer.
I don't have answer to your last question @miquelcabot.
@mudler @Luka-Loncar I updated the description to include the tickets that are on the board for this EPIC
Closing this epic as the only outstanding card to finish the story is already available (but blocked): https://github.com/masa-finance/masa-oracle/issues/326
Epic: Refactor and Enhance ProtocolStaking Contract
Description
This epic focuses on refactoring the
OracleNodeStaking.sol
contract toProtocolStaking
to improve its modularity, incorporate epoch-based reward distribution, and add protocol node fee functionality. The updates will align the contract with the utility functions defined for validators, workers, and oracle nodes based on the heuristics outlined in the[DRAFT]_Technical_Whitepaper_Rev_1.3.pdf
.Goals
OracleNodeStaking
contract to achieve better code organization, reusability, and maintainability, rename it toProtocolStaking
to reflect our updated code and vision.Problem Statement
The current implementation of the
OracleNodeStaking
contract has the following issues:To address these issues, we need to refactor the
ProtocolStaking
contract into separate contracts, each responsible for a specific functionality. The contract should be updated to consider the following heuristics for each actor:Validator:
Worker:
Oracle Node:
Suggested Implementation
Create separate contracts:
Staking
: Handles staking functionality for validators, workers, and protocol nodes.UtilityTracker
: Tracks the utility of each actor based on the defined heuristics.EpochRewards
: Handles reward distribution logic for each epoch.ProtocolFees
: Handles fee logic for oracle nodes, oracle nodes must pre-pay fees that are deducted as they use the protocol.Update the
ProtocolStaking
contract:Implement utility tracking:
Update staking and withdrawal:
stake
function to consider the utility of each actor based on their role and the defined heuristics.withdraw
function to update the utility of each actor when they withdraw their stake.Implement epoch-based reward distribution:
Implement protocol node fees:
Update documentation and perform testing:
Contract Structure Diagram
Acceptance Criteria
ProtocolStaking
contract is refactored into separate contracts for better modularity.stake
function considers the utility of each actor based on their role and the defined heuristics.withdraw
function adjusts the utility of each actor when they withdraw their stake.Deployment
Reference
[DRAFT]_Technical_Whitepaper_Rev_1.3.pdf
Tasks