This IIP introduces the concept of node types, aiming to enable a diversified network structure in the future. It discusses the registration process and mechanisms associated with node types. Additionally, it introduces the concept of message networks to optimize communication efficiency among diverse node types. By exploring these advancements, this article seeks to enhance the network’s flexibility and scalability.
This IIP is an introductory, umbrella proposal to gauge the community’s interest in a gradual shift towards a multiple node model. Many specifics including a final list of new node types, their contributions to the network, their reward amounts and where these rewards come from, etc. will be fleshed out and put to the community for a vote at a later time.
Currently, the requirements for becoming a delegate node in the IoTeX network are relatively high. To address this, we propose separating the block proposal task from delegate nodes. By delegating this responsibility to a different set of nodes that require a lower staking requirement, more individuals can actively participate in the network and earn rewards.
In line with our broader vision for the future of IoTeX, we envision a diverse network comprising various types of nodes, each performing specific functions. This includes consensus nodes, block proposal nodes, w3bstream (WS) compute nodes, and more. These nodes will earn rewards based on their respective roles and contributions to the network.
To achieve these objectives, it is crucial to establish a solid infrastructure for managing node role assignments.
A node type refers to a distinct category or role assigned to a node within the IoTeX network. Each node type is designed to fulfill specific functions and contribute to the network. The introduction of node types allows for specialization and efficient allocation of resources, ensuring that different tasks are performed by nodes with the necessary expertise and functionalities.
Currently, the IoTeX network relies on delegates to validate blocks and maintain the consensus. However, as the network evolves, we envision the introduction of additional node types to enhance its capabilities and accommodate diverse use cases.
For example, we would like to have oracle nodes that serve as bridges between the blockchain and the real world, transforming real-world data into a usable form in smart contracts. Additionally, there will be bridge nodes that connect nodes from different blockchain networks, allowing users to transfer and exchange assets, information, and value between different blockchain networks. Moreover, there will also be WS nodes capable of receiving data streams from IoT devices and processing, analyzing, and computing on this data.
The registration process plays a vital role in onboarding nodes into the IoTeX network.
Requirements: The registration process defines specific requirements and eligibility criteria that nodes must meet to participate in the network. By establishing these requirements, the network ensures that nodes have the necessary capabilities and resources to contribute effectively. These criteria may include factors such as
1.1 staking requirements
1.2. minimum hardware specifications
Register Action: A new register action is introduced to trigger the node type registration process, which includes the necessary registration information, such as:
2.1. information of node (e.g. operatorAddress, rewardAddress, ownerAddress)
2.2. staking amount & duration
2.3. node type
State Storage: Once the register action is validated and executed, there are two kinds of data stored in states of blockchain:
3.1. native staking bucket: this bucket contains staking-related information, including the staking amount and duration.
3.2. node type: the blockchain state also includes information about the registered entity and its corresponding bucket index.
If a user no longer wishes to continue running as a registered node in the network, they can initiate the exit process at any time.
Non-auto-stake: If the bucket’s status is set to auto-stake, the user needs to perform a restake operation first to switch the status to non-auto-stake.
Waiting staking period: Starting from the moment of non-auto-stake, the user needs to wait for the staking period of the corresponding bucket. During this period, the node’s registration type remains effective.
Unstake: After the staking period ends, the user can perform an unstake operation. Once completed, the node’s registration type becomes invalid.
Waiting for 3 days: Starting from the moment of unstake, the user needs to wait for three days.
Withdraw: After the waiting period, the user can perform a withdraw operation to retrieve the staked amount.
Once the registration of nodes is completed, they can operate and perform their respective functions within the network. To facilitate more effective communication among different types of nodes, we introduce the concept of message networks. Message networks possess the following characteristics, optimizing communication and addressing network congestion:
Node Message Sending and Receiving: When a node joins a message network, it can send and receive messages within that network. This allows nodes to engage in real-time information exchange with other nodes within the same message network.
Isolation of Message Networks: Nodes can send messages to a message network they have not joined, but they are unable to receive messages from that network. This isolation ensures that nodes are only affected by the message network they belong to, preventing interference from other message networks. Different types of nodes can exchange internal messages within their respective message networks without disrupting the operation of other nodes.
Joining Multiple Message Networks: Nodes have the capability to join multiple message networks simultaneously. This flexibility allows nodes to participate in appropriate message networks based on their specific communication requirements. By joining the relevant message networks, nodes can engage in targeted message delivery and subscribe to messages from nodes of other types.
Different types of nodes have different roles, which determine the networks they will join and the networks to which they will send messages. The future IoTeX network will consist of various types of nodes. Each type of node will choose to join specific networks and send messages to certain networks, thus forming the overall network structure. This allows each type of node to receive only the content of interest, reducing network load. Below is an example diagram of the network structure:
The introduction of multiple node types within the IoTeX network fosters active participation and rewards contributions across various node roles. By incentivizing different types of nodes, the network aims to create a vibrant ecosystem where more participants are motivated to engage and contribute to its growth. The incentives for multiple node types are designed to align with their respective responsibilities and contributions to the network.
By introducing node type and messaging networks, the IoTeX ecosystem benefits in the following ways:
Decentralization and Network Security: By supporting multiple node types, the IoTeX network aims to foster decentralization. Delegating specific tasks to different types of nodes distributes responsibility and authority across a diverse set of participants. This decentralization promotes a more robust and resilient network architecture by reducing the reliance on a single type of node, such as delegates. It enhances network security, mitigates the risk of single points of failure, and ensures that no single entity or group has undue control over the network’s operations.
Increased Participation: Traditional delegate staking requirements may pose barriers to entry for some individuals or organizations. By diversifying node types and reducing the staking requirements for certain roles, the network becomes more accessible to a broader range of participants. This inclusivity fosters a more vibrant and diverse network ecosystem, attracting a wider community of contributors and stakeholders. Increased participation enhances network resilience, decentralization, and fosters innovation by harnessing a diverse set of skills and perspectives.
Future- p roofing the Network: As the network expands and new use cases emerge, different types of nodes enable the network to adapt to specific requirements. By having specialized node types, such as proposer nodes for efficient block bundling or w3bstream compute nodes for IoT data processing, the network remains adaptable and capable of handling diverse tasks. This future-proofing ensures that the IoTeX network can scale, evolve, and meet the needs of emerging applications and technologies.
Ensures backward compatibility by implementing a new registration process separate from the original delegate registration and maintaining a unified message network where all nodes currently reside.
Copyright and related rights waived via CC0.
More technical details could be found here: Add IIP-16 by envestcc · Pull Request #25 · iotexproject/iips · GitHub
If you are interested in DePIN you can learn more about the latest developments in the sector and compare projects by visiting DePINscan. DePINscan powered by W3bstream and IoTeX is designed to empower intelligent investors in the DePIN sector.