Test with 0 values, test with empty strings, test with large values, etc.
Service pallet
Where does an operator set their limit for how many active service instances they will execute per blueprint?
Ensure we enforce this and test it. (NEEDS TASK)
Should there be an expiration for instance requests? Is there a limit on the # of requests an operator can have?
Instance requests expire after 1000 blocks?
Service requesters modifying their requests while they're not finalized (operator(s) reject service requests)
Should there be a bond requests that require approvals?
Tests
All error cases tested
Test exhausting parts of the system (create 1000 service requests, exhaust operator limits to hit errors from operator side)
Requesting a service should indicate what assets are being used for the securing the service. This is important for slashing and rewards.
Submissions
Who can submit jobs
Who can submit job results
Tests to ensure its protected enough. Tests to demonstrate failure to call job result for a different job.
Report submission
Dealing with job misbehaviors vs quality of service misbehaviors.
function verifyReport(
uint64 serviceId,
uint8 jobIndex,
uint64 jobCallId,
bytes calldata participant,
bytes calldata inputs,
bytes calldata outputs
) public override view onlyRuntime {
if jobCallId == 1 {
verifyReportForJob1();
} else {
// Potential Quality of Service reporting
// TODO: How to identify what quality of service report it is.
}
}
Slashing
Slashing similar to validator slashing, meaning there's a global list of potential slashes and the governance system can veto slashes. Slashes should have a 1-2 week period to review.
Submit report extrinsic (similar to submit job result) which submits a report if the Blueprint has reporting specified.
Research Symbiotic and Eigenlayer
Incentives and rewards
Do we have incentivized blueprints? activate_blueprint_for_rewards, deactivate_blueprint_from_rewards should be in service pallet or separate one (perhaps separate pallet for rewards and slashes).
Deposit APYs for delegation pallets.
Rewarding operators of a incentivized blueprint (things in Runtime and then there's specific things in the Blueprint)
Build distributions of successful and failed job submissions and reports (counter metric)
Maybe each job contains t signatures and so all t signers get a point.
Maybe each job submission is a race and so whoever submits the most jobs gets the most points
Maybe everyone gets a point for posting a heartbeat every 100 blocks.
Rewards issued each session (or era)
Rewards need to pay out to the operator and all its delegators proportionally to their stake provided (go to stash initially, eventually can specify an LST strategy for your TNT rewards to be auto-liquid staked and restaked).
How to distribute rewards to delegators?
USD oracle for assets
Exploration
Response Time and Latency:
Operators report response times, but clients can also submit signed timestamps.
Discrepancies between operator-reported and client-reported times can trigger audits or slashing.
Uptime and Availability:
Implement a challenge-response system where random challenges are sent to services.
Failure to respond within a set timeframe results in penalties.
Throughput and Request Count:
Clients submit signed receipts for each request.
Operators' reported throughput can be cross-checked against these receipts.
Error Rates:
Clients submit signed error reports.
Large discrepancies between reported and client-submitted errors trigger penalties.
Data Integrity:
Use Merkle trees or other cryptographic proofs to verify data hasn't been tampered with.
Operators provide proofs along with their reports.
Computation Correctness:
Implement zero-knowledge proofs or verifiable computation techniques for complex tasks.
Operators provide proofs of correct computation along with results.
Resource Usage:
Implement trusted execution environments (TEEs) or secure enclaves to report actual resource usage.
Cross-check reported usage against expected usage based on tasks performed.
Network Traffic:
Implement packet signing at network boundaries.
Operators provide proofs of traffic volume, which can be verified against client-side data.
Storage Proofs:
Use techniques like Proof-of-Retrievability or Proof-of-Space to verify data is being stored correctly.
Smart Contract Interactions:
Track on-chain interactions initiated by the service.
Operators report these, which can be directly verified against blockchain data.
Pallet services and assets
Operator states
Staking pallet
Tangle liquid staking pallet
Service pallet
Slashing
Incentives and rewards
activate_blueprint_for_rewards,deactivate_blueprint_from_rewardsshould be in service pallet or separate one (perhaps separate pallet for rewards and slashes).Exploration
Response Time and Latency:
Uptime and Availability:
Throughput and Request Count:
Error Rates:
Data Integrity:
Computation Correctness:
Resource Usage:
Network Traffic:
Storage Proofs:
Smart Contract Interactions:
Consensus Participation (for blockchain-related services):
API Usage Metrics:
Service Level Agreement (SLA) Compliance:
Security Incident Reporting:
Version and Patch Management:
Load Balancing Effectiveness:
Data Processing Metrics:
Scalability Metrics:
Cost Accrual:
Compliance and Audit Logs:
Slashing Conditions:
Implementation Considerations: