<-home

DOG: A New Gossip Protocol for CometBFT

Contents

For the busy modern soul

DOG optimizes the path for transmitting transactions to each node.

  • When the sent transaction is returned (cycle), it closes the path by sending a HaveTx message to the peer that sent the transaction.
  • HaveTx message only carries the transaction hash, so there is little network overhead.
  • Gradually remove unnecessary paths to minimize duplicate transactions.
    • In the paper, It is called a Closed-loop redundancy controller which is a mechanism for the system to monitor the current network status and dynamically adjust the level of redundant propagation.
  • Finally, a superposition of directed spanning tree structure is created with each node as the root.

Initially all routes are open

@Initially all routes are open

The result of directed spanning trees

@The result: Directed spanning trees, where each node has a single, optimal path to reach every other node.

Redundancy Controller is used to set the transaction duplication tolerance range per node.

  • Redundancy Level

    • The percentage of redundancy allowed in the overall transaction flow

      Redundancy Level = 1 / Allowable redundancy ratio
    • The lower the Redundancy Level, the lower the tolerance for duplicate transactions
    • f.e. Redundancy Level = 0.5 means when 100 different transactions come in, up to 50 duplicate transactions can be received
    • If duplicate transactions are lower than the allowable range, a ResetRoute message is sent to the peer to reactivate the closed route

Test Results

  • In the test, transactions were transmitted at a speed of 500tx/s for 15 minutes from 200 nodes

  • Mempool: As the path is built, the mempool size and cache hit count gradually decrease

  • Consensus
    • More stable block production
    • Less additional consensus rounds for the validator is needed
    • 8 times less missing validators during voting
    • About 2.7 times less missed blocks
    • Additional 10% reduction in network traffic generated by BlockPart messages
  • Resource usage and latency
    • CPU usage reduced by 43%
    • Memory usage reduced by 10%
    • Total transaction verification time (checkTx) reduced by 10%
    • Average latency: Flood (3.63s), DOG (3.14s)

The usefulness of DOG in the persistent peering network

Persistent peering network is a network where nodes are connected to each other in a persistent way, meaning that nodes are always connected to each other. All validators are connected to each other, and since there are no multi-hops in the network, all transactions can be propagated directly to all nodes in one hop.

As you may have guessed, DOG is not an advantage in this environment. In a single-hop architecture, where a transaction from A to B does not need to go through C, no duplicate transactions occur. The biggest advantage of DOG is that it optimizes the overall network path by gradually reducing the paths where duplicate transactions can occur, so its use is unnecessary in this environment.

However, this does not mean that DOG is completely unnecessary.

Since it is not guaranteed that all nodes will always maintain connectivity, DOG can maintain network propagation by dynamically reconfiguring the path when a specific network connection becomes unstable.

In addition, even in a direct peering environment, network bandwidth can be further reduced through duplicate transaction filtering. In particular, when unnecessary redundant data is propagated in communication between nodes, DOG can detect and minimize this.

Finally, when the number of network nodes is greatly expanded, it may be realistically difficult to maintain persistent peering, but DOG can maintain efficient propagation even in large-scale networks by optimizing the transaction propagation path.

Comparison: Flood gossip protocol

Flood gossip protocol broadcasts a transaction to all peers in the network when the transaction is created.

During this process, the same transaction may be transmitted multiple times. In a fully connected network, all nodes are directly connected to each other, which increases redundant propagation.

Flood gossip protocol simply broadcast transactions without checking for duplication, which wastes bandwidth.

For example, There are 4 nodes A, B, C, D.

- If node A sends a transaction to nodes B, C, and D, then B, C, and D also send the same transaction back to each other.
- Flood simply propagate without checking for transaction duplication, resulting in wasted bandwidth.

As a result, these problems occur:

  • Network bandwidth wastes
    • Duplicate transaction messages are continuously transmitted, which wastes bandwidth unnecessarily.
  • Performance degradation
    • Transaction propagation speed may slow down as the network becomes overloaded.
  • Scalability issues
    • As the number of network nodes increases, the number of duplicate propagated transactions also increases rapidly.

References