BitVMX off-chain communication system: Multi-Exchange Handler

In our previous articles, we introduced the BitVMX off-chain communication system, a decentralized peer-to-peer (P2P) framework that plays a key role in the BitVMX protocol. We covered its main features, such as secure identity checks, reliable handshake protocols using the Noise Protocol, and a flexible structure for managing async peer-to-peer communication. We also highlighted additional protections, like rate limiting to prevent abuse and allow list verification to control network access.

While the off-chain communication system we described is fully functional for its basic tasks, real-world applications often demand more advanced capabilities. For example, in BitVMX two nodes need to exchange information smoothly while also managing multiple interactions with other peers at the same time. These interactions must remain secure, fast, and reliable, even when handling many simultaneous exchanges in complex scenarios.

In this article, we introduce the Multi-Exchange Handler, a new tool built on top of the BitVMX communication library. The handler expands the protocol by managing more complex interactions between nodes, making it possible to handle many exchanges at once while keeping the same high standards of security and performance as the original framework.

Channels

As described in previous articles, the P2P protocol operates async, and channels are the primary mechanism that enable communication between the async components and the sync parts of the system. In the earlier framework, three main channels were introduced:

1. Sender Channel: This channel is responsible for sending messages or commands to other peers, such as dial attempts, status updates or error notifications.
2. Receiver Channel: This channel handles incoming messages and events from peers.
3. Priority Channel: The priority channel monitors and manages critical information, such as dropped messages or other high-priority alerts.

The Multi-Exchange Handler builds on top of this structure by introducing additional logic to manage and filter the flow of information. While the three original channels serve to connect the P2P protocol with the handler, the handler itself introduces three new channels to deliver only the most relevant messages and events to other parts of the system.

So, in total, the Multi-Exchange Handler utilizes six channels:

• Three channels for communication with the P2P protocol:
  These are the existing sender, receiver, and priority channels, which provide the handler with raw data and events directly from the P2P layer.
• Three channels for communication with the rest of the system:
  The handler processes incoming messages, filters out irrelevant data, and relays only essential information to the main system.

The handler acts as a mediator, analyzing all incoming messages and events from the P2P protocol. It makes decisions based on the content and context of these messages, ensuring that only relevant information is forwarded to the main system.

The information exchange between the handler and the P2P protocol has already been discussed in earlier articles. Though the type of information between the main application and the handler is very similar, it does include additional data fields to support advanced functionalities:

• Peer ID: Derived from the public identity key, it uniquely identifies the node to which a message is sent.
• Address: Specifies the destination for the message.

FSM

The Multi-Exchange Handler employs a Finite State Machine (FSM) to coordinate the flow of communication between peers. This mechanism ensures that interactions are handled in an orderly way, based on input from the P2P protocol and the main application. By assigning distinct roles to the nodes involved, the FSM determines the communication pathway, whether a node acts as a dialer or a responder.

The dialer is responsible for initiating the connection, while the responder handles the incoming request. Although the specific flows differ slightly depending on the role, the overall sequence remains consistent. The dialer establishes the connection, sends a message, waits for an acknowledgment from the responder, and then expects a reply. Once the responder’s reply is received, the dialer acknowledges it and closes the communication.

This entire sequence represents the ideal flow of the FSM, where interactions proceed smoothly without interruptions or errors. However, real-world scenarios often involve complexities, and the FSM is designed to handle such situations. If an error occurs, such as a disconnection, an unexpected event, or a failed acknowledgment, the FSM can transition to an error state or apply features like message resending, which will be explained in the next section.

The FSM ensures reliable and efficient communication between nodes, even in challenging conditions. The following diagram illustrates the typical steps in a successful interaction. While it highlights an uninterrupted flow, the FSM also handles potential errors, adapting as needed.

Features

In addition to the core FSM functionality mentioned above, several complementary features enhance the system's reliability and efficiency:

• Automatic Acknowledgment: The FSM handles message acknowledgment internally, freeing the main application to focus only on sending and receiving messages without managing acknowledgment statuses.
• Message Resending: If a message receives a negative acknowledgment status, the message is temporarily saved and attempts are made to resend it. This ensures delivery continuity until a successful acknowledgment is received or the process is terminated.
• Automatic Redialing: Since the FSM supports a single exchange per connection, consisting of one message from the dialer and one from the responder, the system uses a dial_and_send(message, peer_info) function to manage connection states. If the peer is already engaged in another exchange, the message and peer information are queued. Once the current exchange is completed, the next message is processed.
• Peer Identification on Error: Certain errors linked to specific peers trigger an immediate disconnection from the problematic peer, improving system stability.
• Disconnection Timeout: If no exchanges occur within a customizable timeframe, the peers automatically disconnect to conserve resources and maintain protocol efficiency.
• Automatic Disconnection: After completing a message exchange and reaching the disconnect state, the system automatically disconnects the peers, requiring no additional input from the main application.

Usage

The Multi-Exchange Handler integrates with the main application without requiring async code.

Initialization is performed with the following call:

let handler= P2pHandler::new(address, private_key);

In this context AllowList defines the permitted peers, address specifies the local peer's address and private_key is used to derive the peer ID.

Once initialized, operations can be executed using commands such as:

handler.request(peer_id, address, msg)?;
handler.response(peer_id, msg)?;
handler.check_receive();

The request function is used to dial a peer and send a message, while response is used to reply once a connection (dial) has already been established. These and other functions provide efficient interaction with the handler, facilitating message exchanges while managing the underlying complexity.

Future work

Several potential enhancements could further improve the efficiency and security of the system.

One significant area for development is the AllowList mechanism. Leveraging blockchain technology, the AllowList could be dynamically updated using a multisignature system, ensuring that changes are made collectively and with consensus.

Another proposed improvement involves enabling nodes to publish their information securely on the blockchain in an encrypted format. This would allow updates to be made as needed while preserving data security. Only nodes within the network possessing the appropriate credentials would be able to decrypt and utilize this information.

Each node could periodically update its record on the blockchain or make changes when required, such as updating its address. Additionally, nodes could define an expiration time for their data, ensuring that outdated information does not persist. Nodes that do not refresh their information within defined intervals may be deemed inactive, allowing the network to focus solely on active participants.

Summary

The Multi-Exchange Handler builds upon the foundation of the BitVMX off-chain communication system, enhancing its ability to manage complex and simultaneous interactions between peers. This addition addresses real-world demands for scalability, efficiency, and security while maintaining the core protocol’s robust features.

The handler introduces new functionality by leveraging six communication channels: three for interacting with the P2P protocol and three for interfacing with the main application. It acts as a mediator, filtering and processing data ensuring that only pertinent information reaches the main system.

A FSM governs the communication flow between nodes, supporting both dialer and responder roles, and facilitating orderly message exchanges.

Complementary features like automatic acknowledgment management, message resending, redialing, and timeout-based disconnections enhance the system's reliability while minimizing the workload on the main application.

The handler is also designed for straightforward integration, allowing the main application to interact with it effortlessly through intuitive commands.

Looking ahead, opportunities for enhancing the handler’s efficiency and security include dynamic updates to the AllowList and secure publication of node information using blockchain technology.