Shobikhul Irfan

Posted on Mar 5

Darkchain: A Privacy-First Layer-1 Blockchain with Wallet-as-IP Architecture and Anonymous Networking

#architecture #blockchain #web3

For academic discussion

Abstract

Blockchain technology promises decentralization but often sacrifices user privacy by exposing transaction details and network metadata on public ledgers. Existing privacy coins focus on obscuring transaction amounts and addresses, yet they still leak network-level information such as IP addresses. This paper introduces Darkchain, a novel Layer‑1 blockchain designed from the ground up with privacy as its primary objective. Darkchain introduces the Wallet‑as‑IP paradigm, where each wallet functions as a first‑class citizen in an anonymous overlay network. Leveraging garlic routing and layered encryption, Darkchain decouples network identity (IP) from cryptographic identity (wallet address). Transactions are routed through multiple relay wallets, making it impossible for external observers to link a transaction to its origin or destination IP. The consensus mechanism, Hybrid Memory‑Hard Consensus (HMHC) , is tailored for constrained devices like the ESP32, enabling widespread participation while resisting ASIC dominance. Furthermore, Darkchain adopts a limited data retention policy where nodes store only the last 30 days of transaction data, with older data retrievable from archival nodes via a distributed hash table. This paper details the architecture, protocols, security analysis, and a blueprint for implementation, demonstrating a feasible path toward a truly private, inclusive, and decentralized blockchain.

Keywords: Blockchain, Privacy, Wallet‑as‑IP, Garlic Routing, Anonymous Networking, ESP32, ASIC‑Resistant Consensus, Data Retention

Introduction

1.1 The Privacy Paradox of Public Blockchains

Public blockchains like Bitcoin and Ethereum achieve transparency and decentralization by recording all transactions in a public ledger. While this enables trustless verification, it also creates a permanent, analyzable record of financial activity. Techniques such as address clustering and network analysis can often de‑anonymize users, linking wallet addresses to real‑world identities [1]. Moreover, the underlying peer‑to‑peer network exposes IP addresses, allowing adversaries to correlate transactions with specific locations [2].

Privacy‑focused cryptocurrencies like Monero and Zcash address transaction‑level privacy using ring signatures and zero‑knowledge proofs, but they still operate over conventional IP‑based networks. Consequently, network metadata remains vulnerable to surveillance and traffic analysis [3].

1.2 The Need for a Holistic Privacy Architecture

A truly private blockchain must protect privacy at all layers: transaction content, sender/receiver identities, and network metadata. This requires a fundamental redesign where the network itself is an integral part of the privacy mechanism, not an afterthought. Additionally, to achieve genuine decentralization, the network must allow participation from resource‑constrained devices (e.g., IoT microcontrollers) without being dominated by specialized mining hardware (ASICs).

1.3 Contributions

This paper presents Darkchain, a blockchain architecture that achieves holistic privacy through three key innovations:

Wallet‑as‑IP Paradigm: Each wallet is also a node in an anonymous overlay network. Wallets route traffic for others using garlic routing, making network addresses opaque.
Hybrid Memory‑Hard Consensus (HMHC): A consensus algorithm specifically designed to run on low‑power devices like the ESP32, while remaining ASIC‑resistant.
Limited Data Retention: Nodes store only recent transaction data (30 days), with older data available from archival nodes via a DHT, reducing storage requirements and enhancing privacy.

We provide a complete architectural description, protocol details, security analysis, and a practical implementation blueprint.

Related Work

2.1 Privacy‑Preserving Blockchains

Monero employs ring signatures and stealth addresses to hide transaction origins and destinations [4]. Zcash uses zk‑SNARKs to shield transaction amounts [5]. Both, however, rely on standard P2P networks that leak IP addresses.

2.2 Anonymous Networking

Tor [6] and I2P [7] provide anonymous communication overlays. I2P’s garlic routing, where messages are split into multiple encrypted “cloves” sent over different paths, offers strong resistance to traffic analysis. Some proposals have integrated such techniques with blockchains, e.g., by routing transactions through Tor [8], but these are add‑ons rather than native features.

2.3 ASIC‑Resistant Consensus

RandomX [9] is a memory‑hard PoW used by Monero to favor CPUs over ASICs. However, its memory requirements (~2 GB) exceed the capabilities of embedded devices. Lightweight memory‑hard functions have been explored for IoT authentication [10], but not yet for full blockchain consensus.

2.4 Data Availability and Pruning

Several blockchains (e.g., Ethereum with “state pruning”) allow nodes to discard old historical data while keeping recent state [11]. However, they rely on a small set of archival nodes for long‑term storage. Our proposal extends this concept with a DHT‑based retrieval mechanism.

Darkchain Architecture

Darkchain is a Layer‑1 blockchain composed of three integrated layers: Network Layer, Consensus Layer, and Data Layer.

3.1 Network Layer: Wallet‑as‑IP and Garlic Routing

In Darkchain, every wallet is a full participant in the network overlay. There are no “light clients” in the traditional sense; every instance (running on a smartphone, laptop, or ESP32) acts as a relay for other wallets.

3.1.1 Peer Discovery and Routing Tables

Each wallet maintains a routing table of a few dozen randomly selected peers. Peers are identified solely by their wallet addresses (public keys) within the overlay; no IP addresses are exchanged. Connections between peers are established through encrypted channels (e.g., using Noise Protocol) that hide IP addresses from the application layer.

3.1.2 Garlic Routing Protocol

When a wallet sends a transaction, it performs the following steps (see Figure 1):

The transaction payload is encrypted with the receiver’s public key.
The encrypted payload is split into multiple garlic cloves (packets).
For each clove, the sender selects a random path of relay wallets (typically 3–5 hops) from its routing table.
The clove is encrypted in layers: each layer corresponds to one relay and contains the next hop’s wallet address.
The clove is sent to the first relay.

Each relay, upon receiving a clove, decrypts its outermost layer, learns the next hop, and forwards the clove. Only the final receiver can decrypt the innermost layer and reassemble the original transaction.

Figure 1: Garlic routing in Darkchain

Sender Wallet
    │
    ├─► Clove A ──► Relay 1 ──► Relay 2 ──► Receiver Wallet
    │              (decrypts)    (decrypts)    (decrypts & reassembles)
    └─► Clove B ──► Relay 3 ──► Relay 4 ──► Receiver Wallet
                   (decrypts)    (decrypts)

This mechanism ensures that no single relay (or eavesdropper) can link the sender to the receiver, nor can they determine that different cloves belong to the same transaction.

3.1.3 Resistance to Traffic Analysis

Garlic routing inherently obscures traffic patterns because:

· Packet sizes are randomized by adding dummy data.
· Cloves from the same transaction travel different paths.
· Constant‑rate dummy traffic can be injected to mask silence periods.

3.2 Consensus Layer: Hybrid Memory‑Hard Consensus (HMHC)

Darkchain uses a Proof‑of‑Work‑style consensus adapted for low‑power devices and ASIC resistance. HMHC combines two components: a dynamic puzzle and a memory‑hard function.

3.2.1 Dynamic Puzzle (Inspired by ECCVCC)

Every epoch (e.g., 24 hours), the network generates a random parity‑check matrix H of size m x n (e.g., 32x32). To propose a block, a node must find a binary vector x of low Hamming weight such that Hx = s, where s is a target syndrome derived from the previous block hash. This is a syndrome decoding problem, believed to be hard for general instances and resistant to optimization by specialized hardware [12].

3.2.2 Memory‑Hard Function

After solving the dynamic puzzle, the node must compute a memory‑hard function over a 256 KB scratchpad:

function memory_hard(header, scratchpad_size, iterations):
    scratchpad = initialize_scratchpad(header, scratchpad_size)
    state = hash(header)
    for i in 1..iterations:
        index = state mod scratchpad_size
        value = scratchpad[index]
        state = hash(state + value)
        scratchpad[index] = state  # in‑place update
    return state

The final state must be below a network‑adjusted difficulty target. The parameters (scratchpad size = 256 KB, iterations = 5000) are chosen to take approximately 3–5 seconds on an ESP32 at 240 MHz [13], making the algorithm feasible on constrained devices while still memory‑hard enough to deter ASICs (see Section 5).

3.2.3 Block Propagation

Once a node finds a valid block (header + solution), it broadcasts the block through the garlic routing network. Other nodes verify the solution by re‑running both the dynamic puzzle and the memory‑hard function. If valid, they add the block to their local chain.

3.3 Data Layer: Limited Retention and DHT Archival

Darkchain nodes do not store the entire transaction history forever. Instead, they maintain:

· The current state (UTXO set or account balances) as a Merkle tree.
· Transaction data for the last 30 days, indexed by block height.

Data older than 30 days is pruned from regular nodes. To ensure long‑term availability, a subset of nodes (archival nodes) voluntarily store the full history. These nodes form a Distributed Hash Table (DHT) where each piece of old data (e.g., a block or transaction) is identified by its hash.

When a user needs to access an old transaction (e.g., for auditing), their wallet queries the DHT using the transaction hash. The request is routed through the garlic network, preserving anonymity. Archival nodes may charge a small fee (in Darkchain tokens) for serving data, incentivizing participation.

This design drastically reduces storage requirements for most nodes, enabling ESP32‑class devices to participate fully.

Wallet‑as‑IP: A New Paradigm

The Wallet‑as‑IP paradigm redefines how identity and network addressing work in a blockchain. In Darkchain:

· Wallet address = Network identifier. There is no separate IP address; all communication is directed to wallet addresses within the overlay.
· Wallets are routers. Every wallet contributes to the network’s routing infrastructure, enhancing anonymity for all.
· No central directory. Peers discover each other through gossip and random walks, avoiding central points of failure or surveillance.

This paradigm has profound implications:

· Censorship resistance: Since there is no fixed IP to block, access to the network cannot be easily restricted.
· Geographic obfuscation: Traffic patterns reveal no geographic information, as relays are scattered globally.
· Inherent scalability: More users mean more relays, potentially improving network performance (up to a point).

Security Analysis

5.1 Anonymity Guarantees

Under the garlic routing model, an adversary controlling c out of N relays has a probability of compromising a given path of length l equal to (c/N)^l. With l = 4 and N in the thousands, this probability is negligible. Even if an adversary controls the first and last relays, they cannot link the sender and receiver unless they also control all intermediate hops.

5.2 ASIC Resistance

HMHC’s memory‑hard component forces any specialized hardware to include fast, on‑chip memory of at least 256 KB. While ASICs can be built with such memory, the dynamic puzzle component changes regularly, requiring reconfigurable logic. The combination makes a dedicated ASIC economically unattractive compared to general‑purpose CPUs and microcontrollers [14].

5.3 Data Availability

The DHT‑based archival system ensures that old data remains available as long as at least one archival node holds it. Redundancy can be increased through replication (e.g., storing each piece on multiple nodes). Incentives (fees and reputation) encourage archival nodes to stay online.

5.4 Potential Attacks and Mitigations

Attack Description Mitigation
Sybil attack Adversary creates many fake nodes to increase chance of being on the path. Require a small stake (e.g., 1 Darkcoin) for relay eligibility; use reputation systems.
Timing analysis Correlating packet timings at different points. Inject dummy traffic; randomize delays.
Eclipse attack Isolating a node by controlling all its peers. Random peer selection; periodic re‑peering.
Long‑range attack Rewriting history using old private keys. Use checkpoints; finality gadgets.

Implementation Blueprint for ESP32

6.1 Hardware Requirements

· ESP32‑S3 with 240 MHz CPU, 512 KB SRAM, and 4 MB Flash (PSRAM optional but beneficial for routing tables).
· Wi‑Fi connectivity.

6.2 Software Stack

Component Library / Technology License
Real‑time OS ESP‑IDF (FreeRTOS) Apache 2.0
Cryptography mbedTLS (included) Apache 2.0
Lightweight crypto PSACrypto [15] Apache 2.0
Garlic routing Custom implementation MIT (proposed)
HMHC Custom implementation (based on RandomX [9] ideas) MIT (proposed)
DHT client Custom or adapted from libp2p MIT/Apache 2.0

6.3 Code Sketch

// Main initialization
void app_main() {
    Wallet wallet;
    wallet.init();

    GarlicRouter router;
    router.start();

    Consensus consensus(&wallet, &router);
    consensus.start();

    DHTClient dht;
    dht.init(&router);
}

6.4 Memory and Performance Estimates

· Garlic routing tables: ~10 KB for 50 peers.
· HMHC scratchpad: 256 KB (in SRAM).
· Transaction pool (30 days): Assuming 1 transaction per second, 30 days ≈ 2.6M transactions. With each transaction metadata ~500 bytes, this would be ~1.3 GB, too large for ESP32. Therefore, ESP32 nodes will store only block headers and state, not full transactions older than a few hours. They rely on archival nodes for historical data. A more realistic approach: store recent transactions in microSD card (e.g., 32 GB) via SPI.

Given these constraints, an ESP32 can function as a light‑weight relaying node and participate in consensus, but for full transaction storage, external storage is recommended. The design remains inclusive because consensus participation does not require storing full history.

Evaluation (Theoretical)

7.1 Latency

· Garlic routing: Each hop adds encryption/decryption time and network latency. With 4 hops and typical internet RTT, total delay ~200–500 ms.
· HMHC solving: 3–5 seconds on ESP32.
· Block propagation: Similar to routing latency.
· Total time to confirm a transaction: ~5–10 seconds (dominated by PoW time).

7.2 Throughput

With a block time of 60 seconds and block size of 1 MB (assuming 250 byte transactions), throughput ≈ 4000 transactions per block ≈ 67 TPS. This is modest but sufficient for many use cases.

7.3 Energy Consumption

ESP32 at full load draws ~250 mA at 3.3V (~0.8 W). Solving one HMHC puzzle every 60 seconds consumes ~48 J per hour, or ~0.013 kWh per day—negligible for a device plugged into mains.

Discussion

8.1 Trade‑offs

Darkchain makes deliberate trade‑offs:

· Latency for privacy: The garlic routing and memory‑hard PoW introduce delays that make Darkchain unsuitable for high‑frequency trading but acceptable for everyday transactions and IoT micropayments.
· Storage for inclusivity: By limiting local storage and relying on archival nodes, we enable low‑resource devices to participate fully in consensus and routing.

8.2 Future Work

· Formal verification of the garlic routing protocol.
· Optimizing HMHC for ESP32’s SIMD instructions (ESP32‑S3).
· Implementing and benchmarking a full prototype.
· Layer‑2 solutions (e.g., state channels) for faster payments.
· Integration with PUF for stronger device identity [10].

Conclusion

Darkchain presents a holistic approach to blockchain privacy, integrating network‑layer anonymity (Wallet‑as‑IP, garlic routing) with a lightweight, ASIC‑resistant consensus (HMHC) and a pragmatic data retention policy. By enabling participation from constrained devices like the ESP32, Darkchain advances the vision of a truly decentralized and private financial network. The architecture is grounded in established privacy technologies and offers a clear path toward implementation. We hope this work inspires further research and development in privacy‑preserving blockchain systems.

References

[1] S. Meiklejohn et al., “A fistful of bitcoins: characterizing payments among men with no names,” IMC 2013.

[2] A. Biryukov, I. Pustogarov, “Bitcoin over Tor isn’t a good idea,” IEEE S&P 2015.

[3] Skrypnikov et al., “Anonymization of network traffic in blockchain systems by using garlic routing,” Information Security Problems, 2025.

[4] N. van Saberhagen, “CryptoNote v2.0,” 2013.

[5] E. Ben‑Sasson et al., “Zerocash: Decentralized anonymous payments from Bitcoin,” IEEE S&P 2014.

[6] R. Dingledine, N. Mathewson, P. Syverson, “Tor: The second‑generation onion router,” USENIX Security 2004.

[7] “I2P Anonymous Network,” https://geti2p.net

[8] “TorCoin: Toward a proof‑of‑bandwidth cryptocurrency,” 2014.

[9] “RandomX,” https://github.com/tevador/RandomX

[10] K. Wimal et al., “Secure hardware‑assisted blockchain framework for IoT device authentication using zero‑knowledge proofs,” ACM 2025.

[11] V. Buterin, “A note on state pruning,” Ethereum Blog, 2015.

[12] H.-N. Lee et al., “Error‑correction code verifiable computation consensus (ECCVCC),” IEEE TIFS 2025.

[13] G. Ramezan, E. Meamari, “zk‑IoT: Securing the Internet of Things with zero‑knowledge proofs on blockchain platforms,” arXiv:2402.08322.

[14] M. Bedford Taylor, “The evolution of bitcoin hardware,” IEEE Micro 2017.

[15] “PSACrypto,” Espressif Component Registry, https://components.espressif.com

Appendix A: Garlic Routing Packet Format (Simplified)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version  |   Flags   |           Clove Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                    Encrypted Payload (Clove)                  /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Next Hop Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each layer is encrypted with the public key of the corresponding relay. The innermost layer contains the actual transaction data and the receiver’s wallet address.

Appendix B: HMHC Pseudocode for ESP32

#include "esp_system.h"
#include "esp_timer.h"
#include "mbedtls/sha256.h"

#define SCRATCHPAD_SIZE (256 * 1024)  // 256 KB
#define ITERATIONS 5000

typedef struct {
    uint8_t scratchpad[SCRATCHPAD_SIZE];
} hmhc_ctx_t;

void init_scratchpad(hmhc_ctx_t *ctx, const uint8_t *header, size_t header_len) {
    mbedtls_sha256_context sha;
    mbedtls_sha256_init(&sha);
    mbedtls_sha256_starts(&sha, 0);
    mbedtls_sha256_update(&sha, header, header_len);
    uint8_t hash[32];
    mbedtls_sha256_finish(&sha, hash);
    // Fill scratchpad with repeated hash
    for (int i = 0; i < SCRATCHPAD_SIZE; i += 32) {
        memcpy(ctx->scratchpad + i, hash, 32);
    }
    mbedtls_sha256_free(&sha);
}

uint8_t* hmhc_solve(hmhc_ctx_t *ctx, const uint8_t *header, size_t header_len) {
    init_scratchpad(ctx, header, header_len);
    uint8_t state[32];
    memcpy(state, header, 32);  // simplified

    for (int i = 0; i < ITERATIONS; i++) {
        uint32_t index = (*(uint32_t*)state) % SCRATCHPAD_SIZE;
        uint8_t value[32];
        memcpy(value, &ctx->scratchpad[index], 32);

        // hash(state + value)
        mbedtls_sha256_context sha;
        mbedtls_sha256_init(&sha);
        mbedtls_sha256_starts(&sha, 0);
        mbedtls_sha256_update(&sha, state, 32);
        mbedtls_sha256_update(&sha, value, 32);
        mbedtls_sha256_finish(&sha, state);
        mbedtls_sha256_free(&sha);

        // update scratchpad
        memcpy(&ctx->scratchpad[index], state, 32);
    }
    return state;  // final hash
}

This paper is released under the Creative Commons Attribution 4.0 International License (CC BY 4.0).

DEV Community

Darkchain: A Privacy-First Layer-1 Blockchain with Wallet-as-IP Architecture and Anonymous Networking

Top comments (0)