Distributed SystemsBlockchainDAGC++WebSocketCryptographyResearch

Tangle-SG

DAG-Based Distributed Ledger for Microgrid Energy Transactions

schedule25 min

calendar_todayPublished 2024

code9 technologies

Abstract

Tangle-SG is a decentralized, DAG-based ledger system designed for microgrid energy transactions. It implements a directed acyclic graph (DAG) where transactions are organized as vertices with parent-child relationships, enabling parallel transaction processing and asynchronous consensus without requiring a global ordering mechanism like blockchain. The system features dual-signature validation, proof-of-work consensus, auto-peering via UDP broadcast with HMAC-based handshake, and real-time telemetry collection.

§1

Problem Statement

Traditional blockchain systems face scalability limitations due to their linear block structure and global consensus requirements. For microgrid energy trading scenarios, these limitations create bottlenecks: slow transaction confirmation, high energy consumption from mining, and inability to handle parallel transactions. A new architecture was needed that could support high-throughput, low-latency energy transactions in a decentralized peer-to-peer network.

Key Challenges

●Blockchain linear structure limits transaction throughput
●Global consensus mechanisms create latency bottlenecks
●High energy consumption from proof-of-work mining
●No support for parallel transaction processing
●Centralized mining pools undermine decentralization
●Complex peer discovery in dynamic network environments

§2

Solution

Tangle-SG addresses these challenges through a DAG-based architecture where transactions reference multiple parent transactions, enabling parallel processing and asynchronous consensus. The system implements dual-signature validation (both sender and receiver must approve), minimal proof-of-work for spam prevention, UDP-based auto-peering with HMAC authentication, and cumulative weight-based finality.

Key Design Principles

●Decentralized: No central authority; all nodes are peers
●Permissionless: Any node can join and participate
●Dual-Signature: Both sender and receiver must cryptographically approve transactions
●Proof-of-Work: Minimal PoW at each phase to prevent spam
●Asynchronous Consensus: Cumulative weight-based finality without explicit consensus rounds

High-Level Architecture

Figure 1: Tangle-SG Node Architecture showing the core modules and their interactions.

Module Organization

Project Structure

bash

1src/
2├── headers/
3│   ├── transaction.h      # Transaction data structures
4│   ├── tangle.h           # DAG storage and operations
5│   ├── network.h          # WebSocket communication
6│   ├── peers2.h           # Peer management
7│   ├── peerDiscovery.h    # Auto-peering via UDP
8│   ├── pow.h              # Proof-of-Work
9│   ├── telemetry.h        # Metrics collection
10│   └── utils.h            # Utilities
11├── modules/
12│   ├── transaction.cpp    # Transaction signing & verification
13│   ├── tangle.cpp         # DAG operations
14│   ├── network.cpp        # WebSocket server/client
15│   ├── peers2.cpp         # Peer state management
16│   ├── peerDiscovery.cpp  # UDP-based discovery
17│   ├── pow.cpp            # SHA256-based PoW
18│   └── telemetry.cpp      # Metrics collection
19└── main.cpp               # Application entry

§3

Architecture

Core Components

1. Transaction Structure

Transactions in Tangle-SG consist of immutable data and mutable metadata. The data structure contains sender, receiver, amount, and parent references. The metadata tracks approval state, signatures, and consensus progress.

Transaction Data Structures (C++)

cpp

1struct tx_data {
2    std::string transaction_id;       // Unique ID
3    std::string sender;               // Sender node UID
4    std::string receiver;             // Receiver node UID
5    double amount;                    // Energy units
6    std::string unit;                 // Unit type (e.g., kWh)
7    double price_per_unit;            // Tariff rate
8    std::string currency;             // Currency code
9    int64_t timestamp;                // Creation timestamp
10    std::vector<std::string> parents; // Parent transaction refs
11};
12
13struct tx_metadata {
14    int64_t lastUpdated;               // Last modification
15    std::unordered_set<std::string> weightMap;
16    int cumulative_weight;             // Total approvals
17    std::string signature1;            // Sender signature
18    std::string signature2;            // Receiver signature
19    std::string checksum;              // Integrity hash
20    int64_t consensusTimestamp;        // When consensus reached
21    std::vector<std::pair<int64_t, std::string>> hops;
22};

2. Tangle (DAG Storage)

The Tangle class manages the entire DAG with thread-safe operations. It provides O(1) insertion and lookup using hash maps, with recursive weight propagation for parent updates.

3. Network Module

Handles all peer communication via WebSocket with dual client/server architecture for bidirectional communication, peer monitoring with health checks, orphan pool for missing parents, and message queuing for disconnected peers.

Transaction Lifecycle

Figure 2: Complete transaction lifecycle from proposal creation through receiver approval and weight propagation.

DAG Structure & Consensus

The DAG has four key properties: Directed (edges point from child to parent), Acyclic (no cycles due to timestamp ordering), Weighted (cumulative weight represents approval count), and Immutable (transaction data never changes).

Figure 3: Example DAG structure showing the relationship between genesis, proposals, and approval transactions with cumulative weights.

Tip Selection Algorithm

The system uses weighted random selection from preferred tips. Tips with cumulative_weight > threshold AND both signatures present are preferred. This encourages building on approved transactions and prevents spam.

Consensus Mechanism

Asynchronous, weight-based finality without explicit consensus rounds. Higher cumulative weight equals higher confidence in transaction confirmation. Probabilistic finality emerges as weight accumulates across the network.

§4

Implementation

Auto-Peering Mechanism

Tangle-SG uses UDP broadcast-based peer discovery with HMAC-based handshake for secure, decentralized peer finding. The three-phase handshake prevents replay attacks and ensures both nodes share the authentication secret.

Figure 4: HMAC-based three-phase handshake protocol for secure peer discovery.

Transaction Broadcasting

The broadcasting strategy uses WebSocket for real-time communication with JSON serialization. The system handles orphan transactions (those with missing parents) through an orphan pool, and provides message queuing for disconnected peers to prevent message loss.

Transaction Message Format (JSON)

json

1{
2  "type": "TRANSACTION",
3  "payload": {
4    "data": {
5      "transaction_id": "1234567890_nodeA_nodeB",
6      "sender": "nodeA",
7      "receiver": "nodeB",
8      "amount": 10.5,
9      "unit": "kWh",
10      "price_per_unit": 5.0,
11      "currency": "USD",
12      "timestamp": 1234567890,
13      "parents": ["parent1_id", "parent2_id"]
14    },
15    "metadata": {
16      "cumulative_weight": 3,
17      "signature1": "base64_encoded_sig1",
18      "signature2": "base64_encoded_sig2",
19      "hops": [
20        {"timestamp": 1234567890, "uid": "nodeA"},
21        {"timestamp": 1234567891, "uid": "nodeB"}
22      ]
23    }
24  }
25}

Performance Characteristics

info

Estimated Throughput

Best case: 1000 tx/sec (no PoW, local network). Realistic case: 10-100 tx/sec (PoW diff=3, network latency). Conservative case: 1-10 tx/sec (PoW diff=4, internet latency).

Time complexity for core operations: Add Transaction O(1), Get Transaction O(1), Update Weight O(d) where d = DAG depth, Broadcast O(p) where p = number of peers, Tip Selection O(t) where t = number of tips.

Latency Breakdown (End-to-End)

text

1Sender PoW:           10-100 ms (depends on difficulty)
2Broadcast:            10-50 ms (network latency)
3Receiver Processing:  1-5 ms
4Receiver PoW:         10-100 ms
5Broadcast Approval:   10-50 ms
6Verification:         1-2 ms
7Weight Propagation:   1-50 ms (depends on DAG depth)
8─────────────────────────────
9Total:                43-357 ms (typical: 100-150 ms)

§6

Results

Tangle-SG successfully demonstrates a viable alternative to blockchain for microgrid energy trading. The DAG-based architecture enables parallel transaction processing, dual-signature validation ensures both parties approve transactions, and the auto-peering mechanism allows dynamic network formation without central coordination.

check_circle

Research Impact

The platform has been used to prototype and benchmark Tangle-style DAG algorithms, demonstrating the viability of DAG-based ledgers for high-throughput, low-latency transaction scenarios.

Caveats & Limitations

Known Limitations

●Finality threshold not fully implemented - transactions remain pending indefinitely
●Centralized tip selection vulnerable to tip-splitting attacks
●No transaction pruning mechanism - Tangle grows indefinitely
●Weak Sybil attack resistance due to low PoW difficulty
●No partition tolerance - network partitions cause divergent DAGs
●Peer discovery limited to local subnet via UDP broadcast

Future Scope

●Implement finality threshold and snapshot mechanism for pruning
●Add weighted random walk (MCMC) for tip selection
●Implement Byzantine Fault Tolerance (BFT) for partition tolerance
●Add reputation system and stake-based identity binding
●Implement DHT-based peer discovery for WAN deployment
●Add sharding and state channels for scalability

Key Metrics

speed

1000+

Max TPS (No PoW)

trending_up

10-100

Realistic TPS

timer

<150ms

Avg Latency

code

C++17

Core Language

§7

Conclusion

Tangle-SG demonstrates that DAG-based architectures can provide viable alternatives to traditional blockchain for specific use cases like microgrid energy trading. While limitations exist around finality and partition tolerance, the system successfully implements core DAG concepts including parallel transaction processing, asynchronous consensus, and decentralized peer discovery. Future work should address the identified limitations to make the system production-ready.

§8

Technologies

C++17libsodiumOpenSSLWebSocketPPBoostJSONcppEd25519SHA256HMAC-SHA256

References

Related Case Studies

DockNet

A Docker-powered network emulator designed for prototyping, benchmarking, and stress-testing distributed system algorithms with real-time telemetry and WebSocket-based monitoring.