Dev Release 26

Greeting BlockDAG Community,

As mentioned in previous update, as a part of substream implementation in blockDAG today we're implementating request-response protocol along with notification protocol. In this technical post, we'll delve into the details of how request-response protocols function within substreams and it's importance in BlockDAG project.

Substreams are the virtual connections or data transmission channels logically created between the network nodes in a BlockDAG layout. Consequently, the existence of these side-chains enables peers to trade data and store the blocks and transactions as they are relayed across the network. For more details refer to the previous post here .
Purpose: Substream request-response protocol is tailored to ensure the continuation of sophisticated information querying and retrieval from peers within a distributed network. This protocol is an indispensable part of the whole cycle in tasks like block validation, consensus making and data synchronization which can result in emergence of a BlockDAG.
Each request is performed in a new separate substream.

The essential elements of Request-Response method:
 

• Initiation of Requests: Node start a search by sending a special formatted request to the node it is directly connected to within a sub stream. This type of message usually contains the details of the data being requested, with inclusive participation of population, stakeholders and organizations in making a decision which means the entire history of who sent how much money to whom is recorded for everyone to see (e.g., a specific transaction or a certain block).
• Handling Requests: In case of a request from a peer node, the node processes it and draws up an appropriate answer. And the answer is again to be sent back to the client via the same substream.
• Response Handling: The node delivering a response will be noticed by the requesting node and the information inside it will be processed. It might be a matter of validating the block, entering it into the local register or subsequently transmitting the received data across the network.

Deployment of request-response protocol as a primary means of internode communication in substreams within BlockDAG network entails several steps and concerns which must be taken into account to avoid potential issues.
Below is a technical algorithm outline detailing how this protocol can be implemented:

• Message Structures: Create message structures that are standardized by which nodes can communicate every time with their neighbors through requests and responses. These messages should have available identifiers, data payloads, and metadata. A distinguishing code is known as an identifier; this facilitates quick tracking and identification of danger.

• Substream Establishment: Create link-branches between the elements to provide direct information channels subheadings. This is enabled by the use of TCP/IP or P2P protocols which can be customized.

• Requester Node Behavior:

Send Request: The situation is that the when a node requires certain data, the node determines the shortest path by using the distributed network and it sends the data request to the node with the highest opportunity to generate the block. By creating a request message with a block or transaction format, it sends it via a substream to the peer node with which connection has been previously established.
Wait for Response: Requester node patiently waits for reply message from the peer node, after those request messages are sent. It also a timeout option to deal with the cases where no response has been received within a timely manner.
 

• Responder Node Behavior:

Receive Request: The peer node is the receiving get source from the substream.
Process Request: On receiving a query, the peer node examines it, in case the data is available it will be retrieved and prepared for a reply before the acknowledgement message is sent by the node.
Send Response: The peer node sends an acknowledgment message to the querier node using the identical substream as the one used to forward the queries.
 

• Error Handling:

Develop mechanisms of error handling that take care of communication failures, timeouts, or incorrect requests. To do this, we will gradually increase the complexity of our systems and test their readiness by performing stress tests.
Retry Mechanism: The requester node has to react in such a manner that within the time frame that has been set, if no reply is received, it retries the request, or the process is handled accordingly.
 

• Asynchronous Processing:

Adopt asynchronous programming techniques to solve the issue of various simultaneous requests handling efficiency.
Implement callback operations or event handlers to react to response messages, processing them as they come in and keeping instance as responsive as it is.

It's also a part of above protocol's implementation, below is a quick summary of how Notification protocol would work.
 

• As a handshake message is the first message which is sent when a substream is opened, it has the content of a protocol. The head message must be prefixed with a 2+bytes length number which was encoded with the LEB128. The encrypted handshake message can have a length of 0 which for the sender simply means that a single 0 must be sent.
• The receiver then sends either back a LEB128-prefixed R-ack handshake to the substream closure, or answers with its own specific protocol handshake that begins with a LEB128. Along with it, the message length will also be of 0. So the receiver has to send back a single 0.
• When you finished shaking hands, your communications protocol becomes unidirectional. The stream can only be revealed if the node which initiated the substream pushes out notification. If the remote also wants to send notifications, it has to open its own unidirectional substream, since the main transmission has to be multicast.
• Every alert has to start with an LEB128(a)-translated length. All codecs that art transcoded for each protocol are different from the other.
• Both parties, either of them can demonstrate that it doesn't want to have a notification substream by closing their writing-side. Besides, the counter message should surface immediately following the other party`s writing side.

The sc-network API enables the registration of notification protocols as user-defined entities. sc-network will be trying automatically for each node substream to open where the previous counterpart from Legacy Substream will be opened by it. Then comes the Handshake thing without conscious thought.What is currently in place, for a manner of backward-compatibility, a group of notification protocols are joined with the legacy Substrate branch. Additionally, the handshake message is hardcoded to be a single 8-bits integer representing the role of the node:
To run an accomplished full node, you shall set aside 1 GB of memory, while for much less achieved ones, 32 MB will do the secret.
2 for concealing a light source on node lighting.
4 for an authority.
In addition, in the future, these restrictions will be totally scrapped.

• Sending a Notification:

A node triggers a notification event by invoking notify_peers() with specific event_type and the information in it.
This function forwards the information message contain event type, data, and the event issuers address to all the peer nodes connected.
 

• Receiving and Processing Notifications:

Every peer node receives the alert sent at render_headers() method.
The receiving node examines the relevance and is configured to carry out actions based on the event type.

Example implementation:
 

    # Create BlockDAG

   nodes    node1 = BlockDAGNode(node_id=1)

   node2 = BlockDAGNode(node_id=2)

   # Add peer nodes for communication

   node1.peer_nodes.append(node2)

   node2.peer_nodes.append(node1)

   # Simulate notification - Node 1 notifies peers about a new block

   new_block = Block(block_id=1, transactions=["Tx1", "Tx2"], parent_blocks=[])    node1.notify_peers(event_type="new_block_received", event_data=new_block)

   # Node 2 receives and processes the notification

   # This triggers Node 2 to process the new block received from Node 1

   # The notification protocol can be extended to handle various types of events and data

After the successful implementation of the communication protocols between the nodes and a notification service it's essential to sync all the nodes with the same information to maintain a consistency in the ledger. Therefore, the next step after this would be working on the syncing process and implementing the same.