You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The motivation behind this feature request is to prevent the registration of fake nodes and significantly improve the quality of the nodes ledger by combining multiple layers of verification, staking, and workload testing.
Summary:
The proposal is to implement a comprehensive Node Verification System to ensure that newly registered nodes in the network are legitimate and active. The system will consist of the following components:
Initial Verification Period.
Staking/Depositing Mechanism.
Unique Workload Deployment.
Trusted Executors with the ability to verify nodes and update their status on-chain.
Key Features:
1. Initial Verification Period
Objective:
When a node is newly registered, it must pass an initial verification period during which it must stay online and respond to basic checks (e.g., pings over RMB).
Implementation:
Nodes are registered but marked as "unverified" by default. Unverified nodes should not be listed in deployment solutions.
The node must be continuously online for a configurable period and pass periodic health checks to demonstrate its reliability.
If the node passes the verification period, it can proceed to the next steps (workload deployment).
Nodes that fail to meet requirements during the verification period will be removed from the network, ensuring these fake nodes do not "bloat" the state of the blockchain.
2. Staking/Depositing Mechanism
Objective:
Introduce a staking/depositing mechanism to incentivize honest node registration and penalize bad actors. Node operators must lock up a certain amount of tokens as a stake during registration.
Implementation:
When registering a node, the operator must stake a predefined amount of TFTs.
If the node passes the verification period and workload deployment, the stake is maintained or released.
Penalties: Nodes that fail verification or are found to be fraudulent will have part or all of their stake slashed.
stake tokens can be released after a certain period of consistent operation or immediately after passing the Initial Verification Period.
3. Unique Workload Deployment
Objective:
Ensure that nodes can handle legitimate workloads by deploying unique resource-intensive workloads to test their capabilities. Nodes must run these workloads and provide verifiable proof of execution.
Implementation:
Trusted Executors will generate and deploy a unique workload for each newly registered node.
The workload will utilize the node's resources (e.g., CPU, memory, network) and will include randomized elements or cryptographic challenges.
Nodes must run the workload and generate a cryptographic proof of execution.
The trusted executor should ensure that the workload is running without tampering by accessing the workload through a secure endpoint and verifying the proof.
4. Node Verifiers (Trusted Executors)
Objective:
Node Verifiers are special entities with known public keys on the blockchain responsible for verifying nodes. They will have on-chain privileges to update node verification status.
Implementation:
Registration of Nodes Verifiers: Trusted executors must be registered on the chain and hold the authority to verify nodes.
Nodes Verifiers (external agents) actively monitor and listen for newly registered nodes, deploying workloads and performing verification checks.
Nodes Verifiers will update the node’s verification status by setting a boolean flag (isVerified) in the node's on-chain data.
Nodes Verifiers also could (optionally) have the authority to monitor verified nodes over time, ensuring consistent performance, and penalizing those that become inactive or misbehave.
Workflow:
Node Registration: A new node is registered on the chain but is marked as unverified.
Staking: During registration, the node operator locks up a predefined amount of tokens as a stake. If the node fails verification, the stake is slashed.
Initial Verification Period: The node enters the verification period, where it must maintain consistent uptime and respond to health checks.
Workload Deployment: Trusted executors deploy a unique workload to the node, which must run it and provide proof of successful execution.
Verification: If the node passes the verification period, staking, and workload checks, the Nodes Verifiers update the node’s status on-chain by setting the isVerified flag to true.
(Optional) Ongoing Monitoring: Node Verifiers continue to monitor the node’s status over time, ensuring it remains compliant with uptime and resources requirements.
Benefits:
Enhanced Security: Ensures only legitimate, active nodes participate in the network, reducing the risk of fake or inactive nodes.
Economic Incentive: A staking mechanism provides financial motivation for honest node operation by deterring bad actors.
Resource Verification: Workload deployment guarantees that nodes have the necessary computational resources and are capable of handling real workloads.
Action Items:
Implement node registration with isVerified status on-chain.
Design the initial verification period process and logic.
Introduce the staking mechanism with penalties and rewards for node operators.
Develop and integrate the Unique Workload Deployment process for testing node resources.
Develop the trusted executors' logic and define their responsibilities.
Implement the node verifiers on-chain registration.
The text was updated successfully, but these errors were encountered:
sameh-farouk
changed the title
Node Verification System with Initial Verification Period, stacking, and Workload Deployment.
Node Verification System with Initial Verification Period, stacking, and Workload Deployment Testing.
Sep 4, 2024
The motivation behind this feature request is to prevent the registration of fake nodes and significantly improve the quality of the nodes ledger by combining multiple layers of verification, staking, and workload testing.
Summary:
The proposal is to implement a comprehensive Node Verification System to ensure that newly registered nodes in the network are legitimate and active. The system will consist of the following components:
Key Features:
1. Initial Verification Period
Objective:
When a node is newly registered, it must pass an initial verification period during which it must stay online and respond to basic checks (e.g., pings over RMB).
Implementation:
2. Staking/Depositing Mechanism
Objective:
Introduce a staking/depositing mechanism to incentivize honest node registration and penalize bad actors. Node operators must lock up a certain amount of tokens as a stake during registration.
Implementation:
3. Unique Workload Deployment
Objective:
Ensure that nodes can handle legitimate workloads by deploying unique resource-intensive workloads to test their capabilities. Nodes must run these workloads and provide verifiable proof of execution.
Implementation:
4. Node Verifiers (Trusted Executors)
Objective:
Node Verifiers are special entities with known public keys on the blockchain responsible for verifying nodes. They will have on-chain privileges to update node verification status.
Implementation:
Workflow:
Node Registration: A new node is registered on the chain but is marked as unverified.
Staking: During registration, the node operator locks up a predefined amount of tokens as a stake. If the node fails verification, the stake is slashed.
Initial Verification Period: The node enters the verification period, where it must maintain consistent uptime and respond to health checks.
Workload Deployment: Trusted executors deploy a unique workload to the node, which must run it and provide proof of successful execution.
Verification: If the node passes the verification period, staking, and workload checks, the Nodes Verifiers update the node’s status on-chain by setting the isVerified flag to true.
(Optional) Ongoing Monitoring: Node Verifiers continue to monitor the node’s status over time, ensuring it remains compliant with uptime and resources requirements.
Benefits:
Action Items:
The text was updated successfully, but these errors were encountered: