IIP-16: Support Multiple Node Types within IoTeX Network

Governance Proposals IIP Discussion
1

Abstract

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.

Motivation

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.

Specification

What are Node Types?

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.

Why do we need new Node Types?

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.

How do we support New Node Types?

Registration

The registration process plays a vital role in onboarding nodes into the IoTeX network.

  1. 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
  2. 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
  3. 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.

Revoke

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.

  1. 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.

  2. 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.

  3. Unstake: After the staking period ends, the user can perform an unstake operation. Once completed, the node’s registration type becomes invalid.

  4. Waiting for 3 days: Starting from the moment of unstake, the user needs to wait for three days.

  5. Withdraw: After the waiting period, the user can perform a withdraw operation to retrieve the staked amount.

Messaging

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:

  1. 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.

  2. 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.

  3. 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:

iip-16-network-arch
iip-16-network-arch1334×794 74.1 KB

Incentive

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.

Rationale

By introducing node type and messaging networks, the IoTeX ecosystem benefits in the following ways:

  1. 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.

  2. 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.

  3. 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.

Backward Compatibility

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.

Security Considerations

Copyright

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.

8 Likes
2

This is a very welcome idea, I agree that the staking requirement for delegate nodes can be a significant barrier for additional participation from the community. Having more types on nodes would improve the robustness of IoTeX as a machine-to-machine infrastructure. I also really like the idea of having bridge nodes as special nodes for cross-chain transactions. :+1:

6 Likes
3

So far I’ve got nothing against this. Sounds like a really good proposal plus I think this improves the decentralization objective by a lot.

1 question though, where will the rewards for the new nodes come from? Currently for delegates, we know that 12% of the total supply has already been allocated for the Roll-Dpos. Is it going to be from this percentage as well?

EDIT: After re-reading the nodes basic requirement, I’m assuming the rewards for the new categories of nodes will also be from the 12%. So basically - Register as a new type of node → stake with my own node → receive rewards? Is that right?

source for Roll-Dpos reward: Welcome to the IoTeX Docs | IoTeX Documentation

4 Likes
4

I love this proposal .

Some questions.
*how the incentive model will take place.
*how secure is the messaging platform.

1 Like
5

a very interesting offer :rocket: :rocket: :rocket: :rocket:

6

This is an excellent proposal on a few fronts. Not only is it good to create a lower cost vehicle for running a node but this is a clear path towards scaling exponentially.

7

It’s an interesting proposal

8

I recommend we extend the discussion period for this proposal as needed until the earning models can be clearly defined.

1 Like
9

Interesting proposal because in actual system huge organisations or companies are getting all huge nodes so decentralisation is not going as expected…
Maybe We can avoid this centralisation in this way, let’s see and discuss a bit more to take another point of view

10

It’s a great proposal

11

I think you are onto something with having task specific nodes (if I understand that right), of course how scalable is it if there is a large influx of data requiring hundreds of different types and forms of data. Possibly thousands of data requests, will it be able to provide data upon request, ie- structured and unstructured data.

Put AI in the mix (if that is the intent) iotex would be well placed to provide structured data, reducing the time taken for data analysts to produce it themselves.

I may have gone off the field with this, but it is interesting and I think you can take this as far as your imagination.

If it doesn’t compromise iotex security, I think this is great. Lowering the barrier too low, can also attract bad actors.

2 Likes
12

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.

1 Like
13

Thanks Chenchen! I’m looking forward to see this approved by the community >> which will lead to more detailed proposals ^^

14

We will implement the message network based on the libp2p pubsub system. The pubsub system will provide security guarantees. Here are some mechanisms:

  • Message Encryption: The libp2p pub/sub system supports end-to-end encryption of messages.
  • Message Signing: Messages exchanged through the pub/sub system can be signed with cryptographic signatures.
  • Topic-Based Filtering: Nodes subscribe to specific topics, and messages are only sent to nodes subscribed to those topics.
  • Decentralization: The peer-to-peer nature of libp2p enhances security by reducing central points of failure and control.

For more technical details, please refer to the proposal mentioned at the end of the article.

3 Likes
15

So what will IIP-16 trigger by way of any developments from the core team? Or is the intent limited to assessing support community support for the multiple node model?

1 Like
16

The development work of IIP-16 lays the foundation for introducing new node types in the future, and mainly includes two points:

  1. Implementing a universal node type registration logic, to simplify the implementation of specific new node types registration in the future.
  2. Constructing messaging networks on top of the P2P network.
1 Like
17

Very cool! Thanks for the greater details.

18

this is probably very early, but I suggest for nodes with very narrowed down role(s) to have a max stake limit. Individuals can have as many nodes as they are capable of, but these nodes will only allow let’s say 10k stake per node.

Just wanna voice this out.

19

With this suggestion, is your goal to have more nodes to promote decentralization and lower the barrier to entry? I’ll be curious to see what reward models might be put in place for these different node types. Unless one is targeting ‘true believers’ people will want the reward to be equal or greater than rewards they could get elsewhere for a comparable level of risk.