My system has an on-board Wi-Fi and several USB network devices (a Realtek Wi-Fi dongle and an RNDIS LTE modem). USB interfaces get unpredictable names like wlxa0a3f0904f79. I solved this by writing udev rules that detect devices by USB vendor:product (VID:PID) and (optionally) DRIVER or MAC, then rename them to stable names (wlan-usb and lte-usb). This makes NetworkManager and scripts much simpler and deterministic.

Below is a publishable blog post / personal documentation you can keep, copy, or paste later.

Problem statement

USB Wi-Fi dongles and USB LTE modems appear with interface names derived from MACs, e.g. wlxa0a3f0904f79.

Names change between different dongles or devices; this breaks static configuration (bridge/NetworkManager profiles, scripts).

I need stable, readable names: wlan-usb for the USB Wi-Fi dongle and lte-usb for the RNDIS/LTE device.

Solution overview

Use udev rules in /etc/udev/rules.d/ to detect the USB device by vendor/product ID (VID:PID), optionally match the driver (e.g., rndis_host) or the MAC, and rename the kernel net interface at creation time using NAME="...".

This is:

• robust (matches device hardware, not ephemeral kernel names),

• deterministic (same device always gets the same name), and

• integrates cleanly with NetworkManager once the rename is applied.

Exact udev rules I used

> Replace 0bda:b812 and 1782:000c with your device VID:PID if different. If you prefer MAC-based match, see the MAC example below.

Create /etc/udev/rules.d/10-network-usb.rules with the following contents:

# /etc/udev/rules.d/10-network-usb.rules
# Rename Realtek USB Wi-Fi 0bda:b812 -> wlan-usb
SUBSYSTEM=="net", ACTION=="add", SUBSYSTEMS=="usb", \
ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="b812", \
NAME="wlan-usb"

# Rename Spreadtrum/Unisoc RNDIS device 1782:000c -> lte-usb
# Prefer this rule only for RNDIS driver instances to avoid renaming non-rndis interfaces
SUBSYSTEM=="net", ACTION=="add", SUBSYSTEMS=="usb", \
ATTRS{idVendor}=="1782", ATTRS{idProduct}=="000c", DRIVER=="rndis_host", \
NAME="lte-usb"

How to install & test the rules (copy/paste)

# create the rule file (example)
sudo tee /etc/udev/rules.d/10-network-usb.rules > /dev/null <<'EOF’

# Rename Realtek USB Wi-Fi 0bda:b812 -> wlan-usb

SUBSYSTEM=="net", ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="b812", NAME="wlan-usb"

# Rename Spreadtrum/Unisoc RNDIS device 1782:000c -> lte-usb
SUBSYSTEM=="net", ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1782", ATTRS{idProduct}=="000c", DRIVER=="rndis_host", NAME="lte-usb"

EOF

Reload rules

sudo udevadm control --reload
# trigger (or unplug & replug the dongles)
sudo udevadm trigger --action=add /sys/class/net/* || true
# show renamed interfaces
ifconfig -a

If you unplug and replug the device, you should see wlan-usb and lte-usb appear.

1. Download SDK and Firmware

First, get the necessary files.

• Go to the OpenWrt Downloads page.

• Navigate to your device's target (e.g., targets/ramips/mt76x8).

• Download the SDK for your specific release (e.g., openwrt-sdk-*-ramips-mt76x8_gcc-*-musl.Linux-x86_64.tar.zst).

• Download the firmware image (squashfs-sysupgrade.bin) for your board, if you need to flash it.

2. Extract the SDK

Extract the downloaded SDK archive to your desired working directory.

tar --zstd -xfv openwrt-sdk-*-mt7628_gcc-*-musl.Linux-x86_64.tar.xz
cd openwrt-sdk-* # Navigate into the extracted SDK directory

3. Create Package Folder and Add to Feeds

Create your package directory and integrate it with the SDK's build system.

# Create your package directory
mkdir -p /path/to/sdk/my_custom_feed
src-link my_custom_feed /path/to/sdk/my_custom_feed
# Update and install feeds (ensure you're in the SDK root)
./scripts/feeds update -a
./scripts/feeds install -a

4. Write the Package Makefile and Source Code

Place your C++ source code and the OpenWrt Makefile in the my_custom_feed/my-first-app directory.

my_custom_feed/my-first-app/main.cpp

#include <iostream>

int main(int argc, char* argv[]) {
    std::cout << "Hello from the HLK-7628!" << std::endl;
    return 0;
}

my_custom_feed/my-first-app/CMakeLists.txt

cmake_minimum_required(VERSION 3.5)
project(my-first-app CXX)

add_executable(my-first-app main.cpp)
install(TARGETS my-first-app  DESTINATION /usr/bin)

my_custom_feed/my-first-app/Makefile

include $(TOPDIR)/rules.mk

PKG_NAME:=my-first-app
PKG_VERSION:=1.0
PKG_RELEASE:=1


SOURCE_DIR:=$(TOPDIR)/my_custom_feed/my-first-app
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)

include $(INCLUDE_DIR)/package.mk
# You can include different mk file for different build systems...
include $(INCLUDE_DIR)/cmake.mk

define Package/my-first-app
       SECTION:=utils        
       CATEGORY:=Utilities
       TITLE:=My First Custom Application
       DEPENDS:=+libstdcpp # or other libs
endef

define Build/Prepare
         mkdir -p $(PKG_BUILD_DIR)
        cp -r $(SOURCE_DIR)/* $(PKG_BUILD_DIR)/
endef


define Package/my-first-app/install
  $(INSTALL_DIR) $(1)/usr/bin
  $(INSTALL_BIN) $(PKG_BUILD_DIR)/my-first-app $(1)/usr/bin/
endef

$(eval $(call BuildPackage,my-first-app))

5. Select the Package and Build

Configure the SDK to build your package and then compile it.

# From the SDK root directory:
make menuconfig

• Navigate to Utilities.

• Find my-first-app and select it by pressing M (to build as a module/package).

• Save and exit.

# Build the package (from the SDK root directory)
./scripts/feeds update my_custom_feed
./scripts/feeds install my-first-app
make package/my-first-app/compile V=s

Your .ipk package will be in bin/packages/mipsel_24kc/my_custom_feed/.

6. Push to Device, Install, and Test

Transfer the package to your HLK-7628, install it, and verify functionality.

# Copy the .ipk to your device (replace with actual IP and filename)
scp bin/packages/mipsel_24kc/my_custom_feed/my-first-app_1.0-1_mipsel_24kc.ipk root@<router_ip>:/tmp/

# SSH into your device
ssh root@<router_ip>

# Install the package
opkg install /tmp/my-first-app_1.0-1_mipsel_24kc.ipk

# Run your application
my-first-app

You should see: Hello from the HLK-7628!

Now that you've seen how to build and deploy your own package, the possibilities are endless. What custom functionality will you add to your HLK-7628?

Try this tutorial for yourself and share your experience in the comments below. I'd love to hear about the custom tools or features you're creating for your own router!

Why Rust?

Rust is known for its performance, safety, and concurrency capabilities. These features make it an ideal choice for blockchain development, where performance and security are paramount. By rewriting Naivechain in Rust, we not only aim to leverage these benefits but also provide an opportunity for developers to learn Rust through a practical and engaging project.

Project Overview

The Rust implementation of Naivechain maintains the core simplicity of the original project while introducing several enhancements. Here’s a quick overview of the project structure:

• Main Component: Initializes the blockchain and starts the HTTP server.

• API Module: Handles RESTful API requests for interacting with the blockchain.

• Engine Module: Manages the blockchain’s core logic, such as adding new blocks and validating chains.

• Chain Module: Defines the blockchain structure, including blocks and chain management.

• Network Module: Implements peer-to-peer networking for blockchain propagation using Libp2p.

Key Features

1. Improved Performance: Rust’s zero-cost abstractions and memory safety features help achieve better performance without sacrificing safety.

2. Concurrency Support: By using Rust’s concurrency model, the project can handle multiple requests efficiently, making it more robust and scalable.

3. Enhanced Networking: With the integration of Libp2p, the project supports peer-to-peer networking, allowing for decentralized and distributed operation.

Get Involved

This project is an open invitation for collaboration and innovation. Whether you’re a seasoned developer or new to Rust, your ideas and contributions are welcome. Here are some ways you can get involved:

• Review the Code: Check out the project on GitHub, explore the code, and suggest improvements or optimizations.

• Share Your Ideas: Have a feature in mind that could enhance the project? Share your thoughts, and let’s discuss how we can integrate it.

• Contribute: Found a bug or want to add a new feature? Submit a pull request and become a part of the project’s evolution.

File Structure Overview

1. main.rs: The entry point of the application, setting up the Actix Web server and initializing the blockchain state.

2. api.rs: Handles the HTTP API for interacting with the blockchain, including endpoints for retrieving blocks and mining new ones.

3. chain.rs: Defines the core blockchain structures and methods for block validation and manipulation.

4. engine.rs: Manages the P2P message handling and processing of blockchain updates from peers.

5. net.rs: Manages the network layer using Libp2p, implementing P2P communication and network behavior.

Chain.rs

The chain.rs file is a crucial part of your blockchain project, as it defines the structure and behavior of the blockchain itself. Below, we'll summarize the code, highlighting the important points to help you understand how it works.

Overview

The chain.rs file consists of two main components: Block and Chain. These structures define the individual blocks in the blockchain and the blockchain itself.

Key Structures and Functions

1. Block Structure

The Block structure represents a single block in the blockchain. Each block contains:

• index: The position of the block in the chain.

• previous_hash: The hash of the previous block, ensuring the integrity of the chain.

• timestamp: The time the block was created.

• data: The data stored in the block (could be transactions, messages, etc.).

• hash: The block's own hash, calculated using its contents.

#[derive(Serialize, Deserialize, Debug, Clone, PartialEq, Eq)]
pub struct Block {
    pub index: usize,
    pub previous_hash: String,
    pub timestamp: u64,
    pub data: String,
    pub hash: String,
}

Constructor Functions:

• new_with_hash: Allows creating a block with a predefined hash (for testing or genesis block).

• new: Creates a new block and calculates its hash using the calculate_hash function.

2. Chain Structure

The Chain structure represents the blockchain as a whole. It maintains a list of blocks and handles operations on the blockchain.

#[derive(Debug, Serialize, Deserialize)]
pub struct Chain {
    pub next_index: usize,
    pub chains: Vec<Block>,
}

• Important Methods:

  • new: Initializes a new blockchain with a genesis block.

  • replace_block_chain: Replaces the current blockchain with a new one if it's valid and longer.

  • is_valid_chain: Validates the entire blockchain to ensure it hasn't been tampered with.

  • is_valid_new_block: Checks if a new block is valid by comparing it with the previous block.

  • get_latest_block: Retrieves the most recent block in the chain.

  • add_block: Adds a new block to the chain if it's valid.

3. Hash Functions

The file includes two functions to calculate the hash of a block, which is essential for maintaining the chain's integrity:

• calculate_hash: Generates a hash for a new block using its index, previous hash, timestamp, and data.

    pub fn calculate_hash(index: usize, previous_hash: &str, timestamp: u64, data: &str) -> String {
        let block_data = format!("{}{}{}{}", index, previous_hash, timestamp, data);
        let mut hasher = Sha256::new();
        hasher.update(block_data);
        let result = hasher.finalize();
        format!("{:x}", result)
    }
  

calculate_hash_from_block: Calculates the hash from an existing block structure.

pub fn calculate_hash_from_block(block: &Block) -> String {
    let block_data = format!(
        "{}{}{}{}",
        block.index, block.previous_hash, block.timestamp, block.data
    );
    let mut hasher = Sha256::new();
    hasher.update(block_data);
    let result = hasher.finalize();
    format!("{:x}", result)
}

Important Points

• Block Creation and Validation: Blocks are created with a calculated hash to ensure data integrity. Each block points to the previous one using a hash, forming a chain.

• Chain Integrity: The blockchain is validated by checking the genesis block and ensuring all blocks are correctly linked with valid hashes and indices.

• Chain Updates: New blocks are added only if they are valid, and the chain can be replaced if a valid longer chain is received, ensuring consensus among nodes.

• Data Structures: The use of Vec<Block> for storing the chain and usize for indices helps manage the chain efficiently. Serialization with Serde allows easy transmission of blocks over the network.

This chain.rs file implements a simple yet effective blockchain mechanism in Rust, encapsulating both the concept of a block and the overall blockchain while ensuring integrity and consensus.

Net.rs

The net.rs file provides the networking functionality for the blockchain project, using the Rust library libp2p for peer-to-peer communication. This file is responsible for managing peer discovery and message exchange in the network, enabling the blockchain to function as a decentralized system.

Key Components and Concepts

1. P2PMessage Enum

The P2PMessage enum defines the different types of messages that can be exchanged between peers in the network. These messages include:

• QueryLatest: Request the latest block from peers.

• QueryAll: Request the entire blockchain from peers.

• ResponseBlockchain: Send the current blockchain to peers.

• QueryPeers: Request the list of peers.

• ResponsePeers: Respond with a list of peers.

• AddPeer: Add a new peer to the network.

#[derive(Serialize, Deserialize, Debug)]
pub enum P2PMessage {
    QueryLatest,
    QueryAll,
    ResponseBlockchain(Vec<Block>),
    QueryPeers,
    ResponsePeers(Vec<PeerId>),
    AddPeer(String),
}

2. Network Behavior

The P2PNetWorkBehaviour struct combines two important network protocols: Gossipsub and mDNS. These protocols facilitate message propagation and peer discovery, respectively.

#[derive(NetworkBehaviour)]
pub struct P2PNetWorkBehaviour {
    pub gossipsub: gossipsub::Behaviour,
    pub mdns: mdns::tokio::Behaviour,
}

• Gossipsub: A publish-subscribe protocol that allows nodes to communicate by broadcasting messages to subscribers. It is used for disseminating blockchain updates and other messages.

• mDNS (Multicast DNS): A protocol for automatic service discovery on a local network, allowing peers to find each other without needing a central registry.

3. Transmit and Receive Handlers

These structs manage message transmission and reception between different components of the system, allowing for asynchronous communication.

#[derive(Clone)]
pub struct TransmitHandlers {
    pub swarm_tx: UnboundedSender<P2PMessage>,
    pub router_tx: UnboundedSender<P2PMessage>,
    pub api_peers_tx: UnboundedSender<P2PMessage>,
}

pub struct ReceiveHandlers {
    pub api_peers_rx: Mutex<UnboundedReceiver<P2PMessage>>,
}

4. Handling Swarm Events

The handle_swarm function manages the swarm's events and message handling. It uses tokio::select! to asynchronously handle incoming messages and network events, such as discovering new peers or receiving messages.

pub async fn handle_swarm(
    mut swarm: Swarm<P2PNetWorkBehaviour>,
    topic: gossipsub::IdentTopic,
    transmit_handler: TransmitHandlers,
    mut rx: UnboundedReceiver<P2PMessage>,
) {
    log::info!("swarm task is started");

    let handle_msg = |msg: P2PMessage, swarm: &mut Swarm<P2PNetWorkBehaviour>| match msg {
        // Handle different message types
    };

    loop {
        tokio::select! {
            Some(msg) = rx.recv() => handle_msg(msg, swarm.borrow_mut()),
            event = swarm.select_next_some() => match event {
                SwarmEvent::Behaviour(P2PNetWorkBehaviourEvent::Mdns(mdns::Event::Discovered(list))) => {
                    for (peer_id, _multiaddr) in list {
                        log::info!("mDNS discovered a new peer: {peer_id}");
                        swarm.behaviour_mut().gossipsub.add_explicit_peer(&peer_id);
                    }
                },
                // Handle other swarm events
            }
        }
    }
}

• Peer Discovery: When a new peer is discovered via mDNS, it is added as an explicit peer in the Gossipsub network.

• Message Propagation: When a message is received or generated, it is published to the network using Gossipsub.

5. Configuring the Network

The config_network function sets up the network configuration, including the transport protocols (TCP and QUIC) and initializes the network behavior (Gossipsub and mDNS).

pub fn config_network(transmit_handler: TransmitHandlers, rx: UnboundedReceiver<P2PMessage>) {
    let mut swarm = libp2p::SwarmBuilder::with_new_identity()
        .with_tokio()
        .with_tcp(
            tcp::Config::default(),
            noise::Config::new,
            yamux::Config::default,
        )
        .unwrap()
        .with_quic()
        .with_behaviour(|key| {
            // Configure Gossipsub and mDNS
        })
        .unwrap()
        .with_swarm_config(|c| c.with_idle_connection_timeout(tokio::time::Duration::from_secs(60)))
        .build();

    let topic = gossipsub::IdentTopic::new("test-net");
    swarm.behaviour_mut().gossipsub.subscribe(&topic).unwrap();

    // Start listening on network interfaces
    swarm
        .listen_on("/ip4/0.0.0.0/udp/0/quic-v1".parse().unwrap())
        .unwrap();
    swarm
        .listen_on("/ip4/0.0.0.0/tcp/0".parse().unwrap())
        .unwrap();

    actix_web::rt::spawn(handle_swarm(swarm, topic, transmit_handler, rx));
}

• Transport Protocols: The network uses TCP and QUIC for transport, providing reliability and performance.

• Message Handling: The network is configured to handle incoming messages, peer discovery, and message propagation.

Important Points

• Peer-to-Peer Communication: This file establishes a decentralized network using libp2p, allowing nodes to communicate and synchronize without a central server.

• Message Types: The P2PMessage enum defines the protocol for exchanging information between nodes, including querying the blockchain and discovering peers.

• Network Behavior: The combination of Gossipsub and mDNS facilitates efficient message propagation and peer discovery, enabling the blockchain to maintain consistency across nodes.

• Asynchronous Handling: The use of tokio and channels for message transmission and reception ensures that the network can handle events and messages efficiently.

The net.rs file is essential for the decentralized nature of the blockchain, enabling communication and synchronization across a distributed network of peers.

Conclusion

Rewriting NaiveChain in Rust is more than just a technical exercise; it’s a community-driven effort to explore the possibilities of blockchain technology using Rust. By simplifying blockchain concepts, we aim to make learning and contributing accessible to everyone.

I invite you to explore the project on GitHub and join the discussion. Let’s work together to make this project better, more efficient, and a valuable resource for learners and developers alike.

Thank you for reading, and I look forward to your contributions and insights!

Introduction to P2P Networks

Peer-to-peer networks enable decentralized communication between nodes, allowing data exchange without relying on a central server. Each participant in the network, or "peer," can act as both a client and a server, fostering direct connections and communication. In our example, we use WebSocket, which provide a full-duplex communication channel over a single TCP connection, to facilitate this real-time interaction.

Overview of the Project

Our project is structured to demonstrate how to establish a P2P network using WebSocket in Rust, leveraging the power of asynchronous programming with the Tokio runtime. We'll explore the following key components:

• Command-Line Argument Parsing: We'll use clap to parse the peer URLs and bind address.

• WebSocket Actor: This component manages WebSocket connections to peers.

• Network State Management: We'll maintain the state of the network, including connected peers.

• Connection Handling: We'll manage the lifecycle of WebSocket connections with peers.

• Broadcasting Messages: We'll send messages to all connected peers periodically.

• Graceful Shutdown: We'll handle interruptions gracefully to shut down the network.

Understanding the Code

Command-Line Argument Parsing

We'll start by defining our command-line arguments using clap. This allows us to specify peer URLs and the bind address when starting our P2P node.

#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
struct Args {
    /// List of client addresses to connect to
    #[arg(short, long, value_delimiter = ',', value_parser = parse_peer)]
    peers: Vec<String>,

    /// Address to bind the server
    #[arg(short, long, value_parser = parse_bind)]
    bind: String,
}

• --peers: A comma-separated list of WebSocket URLs to connect to as peers.

• --bind: The address to bind the server for incoming connections.

WebSocket Actor

The WebSocketActor struct manages WebSocket connections. It establishes a connection to a given URL and handles the sending and receiving of messages.

struct WebSocketActor {
    ws_stream: WebSocketStream<MaybeTlsStream<TcpStream>>,
}

impl WebSocketActor {
    async fn connect(url: &str) -> Option<Self> {
        match connect_async(url).await {
            Ok((conn, _)) => {
                log::info!("Connected successfully to {}", url);
                Some(WebSocketActor { ws_stream: conn })
            }
            Err(e) => {
                log::error!("Connection to {} failed: {:?}", url, e);
                None
            }
        }
    }
}

Network State Management

The P2PWebsocketNetwork struct maintains the state of the network, including connected peers and a master sender for message broadcasting.

struct P2PWebsocketNetwork {
    addresses: Arc<Mutex<HashMap<SocketAddr, UnboundedSender<P2PInnerMessage>>>>,
    master: Arc<Mutex<UnboundedSender<P2PInnerMessage>>>,
}

Connection Handling

We'll handle incoming and outgoing connections using the handle_connection and handle_server_connection functions. These functions manage the lifecycle of WebSocket connections, sending and receiving messages.

async fn handle_connection(
    state: Arc<P2PWebsocketNetwork>,
    conn: WebSocketActor,
    token: CancellationToken,
) {
    // Logic for handling connections and message exchange
}

Function Signature

• state: A shared state (Arc<P2PWebsocketNetwork>) that contains the network's information, including connected peers and message handlers.

• conn: A WebSocketActor instance representing the connection with a peer.

• token: A CancellationToken used to handle task cancellation for graceful shutdown.

Extracting the Socket Address

let addr = match conn.ws_stream.get_ref() {
    MaybeTlsStream::Plain(f) => f.peer_addr().unwrap(),
    _ => {
        panic!("tls is not supported yet");
    }
};

• addr: The socket address of the peer. The code extracts the peer's address from the WebSocket stream. Currently, only non-TLS (plain) streams are supported.

Setting Up the Message Channel

let (tx, mut rx) = unbounded_channel::<P2PInnerMessage>();
{
    let mut list = state.addresses.lock().unwrap();
    list.insert(addr, tx.clone());
}

• tx and rx: An unbounded channel for sending and receiving messages (P2PInnerMessage) between this function and other parts of the application.

• state.addresses: The connected peers' addresses are stored in a shared HashMap, and the new peer's address and its sender (tx) are added to the list.

Splitting the WebSocket Stream

let (mut ws_tx, mut ws_rx) = conn.ws_stream.split();

• ws_tx and ws_rx: The WebSocket stream is split into a sender (ws_tx) and a receiver (ws_rx) to handle incoming and outgoing messages asynchronously.

Message Handling Loop

loop {
    tokio::select! {
        Some(msg) = ws_rx.next() => {
            log::debug!("Received: {:?}", msg);
            match msg {
                Ok(msg) => {
                    if let Err(e) = state.master.lock().unwrap().send(P2PInnerMessage {
                        message: msg,
                        tx_handler: tx.clone(),
                    }) {
                        log::error!("Failed to send message to master: {:?}", e);
                    }
                },
                Err(e) => {
                    log::error!("Error receiving message or connection closed: {:?}", e);
                    break
                }
            }
        }
        Some(msg) = rx.recv() => {
            log::debug!("Sending: {:?}", msg);
            if let Err(e) = ws_tx.send(msg.message).await {
                log::error!("Failed to send message on socket: {:?}", e);
            }
        }
        _ = token.cancelled() => {
            log::warn!("task is cancelled");
            break
        }
    }
}

• Incoming Messages (ws_rx): The loop uses tokio::select! to wait for multiple asynchronous events. It first checks for incoming messages from the peer (ws_rx.next()).

  • If a message is received successfully, it is forwarded to the master handler by sending it through state.master. This allows centralized processing or routing of messages.

  • If an error occurs (e.g., connection closed), the loop breaks, effectively terminating the connection.

• Outgoing Messages (rx): The loop also checks for messages received from the application's internal channels (rx.recv()), intended to be sent to the peer.

  • The message is sent to the peer using ws_tx.send(msg.message).await. Errors in sending are logged.

• Cancellation Token: If the cancellation token is triggered (token.cancelled()), the loop breaks, allowing the task to exit cleanly.

Removing the Peer from the List

{
    let mut list = state.addresses.lock().unwrap();
    list.remove(&addr);
}

Once the loop exits (either due to an error or cancellation), the peer's address is removed from the list of connected addresses, ensuring that the state reflects the current network connections accurately.

The handle_server_connection function operates as described above.

Broadcasting Messages

Our broadcast function sends a message to all connected peers periodically, demonstrating the P2P network's ability to propagate information.

async fn broadcast(
    state: Arc<P2PWebsocketNetwork>,
    tx: UnboundedSender<P2PInnerMessage>,
    bind: String,
) {
    // Broadcast messages to all connected peers
    let list = state.addresses.lock().unwrap();
    for (i, cl) in list.iter().enumerate() {
        log::debug!("Broadcasting to {} ", cl.0);
        if let Err(e) = cl.1.send(P2PInnerMessage {
            message: tungstenite::protocol::Message::text(format!(
                "Message to client {} from {}",
                i, bind
            )),
            tx_handler: tx.clone(),
        }) {
            log::error!("Failed to send broadcast message: {:?}", e);
        }
    }
}
#[tokio::main]
async fn main() {
// other parts of the code
 loop {
        tokio::select! {
            //other match rules
             _ = tokio::time::sleep(tokio::time::Duration::from_secs(10)) => {
                tracker.spawn(broadcast(network_state.clone(), tx.clone(), args.bind.clone()));
            }
        }
    }
}

Graceful Shutdown

Finally, we'll ensure our network can be shut down gracefully by handling Ctrl+C signals and canceling tasks accordingly.

loop {
    tokio::select! {
        Some(msg) = rx.recv() => {
            // Process received messages
        }
        _ = tokio::signal::ctrl_c() => {
            log::warn!("Received Ctrl+C, shutting down...");
            tracker.close();
            cancelation_token.cancel();
            break
        }
    }
}
// wait unitl all tasks are closed
tracker.wait().await;

Running the Project

In separate sessions, run the program in the following order with these arguments:

$ RUST_LOG=debug cargo run -- --bind localhost:8080 # start the first node 
$ RUST_LOG=debug cargo run -- --peers ws://localhost:8080 --bind localhost:8085 # start the second node 
$ RUST_LOG=debug cargo run -- --peers ws://localhost:8080,ws://localhost:8085 --bind localhost:8086 # start the third node

Then you will see messages being broadcast from each peer to all others. It's an all-to-all broadcast!

Conclusion

Building a P2P network over WebSocket infrastructure in Rust offers a powerful and efficient way to enable real-time communication between nodes. By understanding each part of our code, you can extend and customize this example to fit your specific needs, whether for decentralized applications, real-time data sharing, or distributed computing tasks. To view the full source code, check out the project's GitHub repository.

We hope this walkthrough helps you understand the core concepts and inspires you to explore more possibilities with Rust and P2P networks. Happy coding!

Blockchain technology has revolutionized the way we think about digital transactions and data integrity. At its core, a blockchain is a decentralized and distributed ledger that ensures security, transparency, and immutability. Understanding the fundamental components of a blockchain is essential for anyone looking to delve into this transformative technology. This is the second part of the Blockchain Introduction series, you can find the first part here. In this blog post, we'll explore the generic elements that make up a blockchain, providing a handy reference for those new to the field or needing a refresher.

Generic Elements of a Blockchain

One of the main elements of a blockchain (as the name suggests) is the Block. We can visualize the block for a better understanding as follow:

So a Generic Block includes:

• Previous Block Hash: A reference to the previous block, providing a chain structure, except for the genesis block, which is the first block hard coded when the blockchain is started.

• Nonce: A unique number used once, essential in cryptographic operations for replay protection and authentication, particularly in Proof of Work (PoW) consensus algorithms.

• Timestamp: The creation time of the block.

• Merkle Root: A hash representing all the transactions in the block, enabling efficient and secure verification of the entire block's transactions.

• Block Body: Contains the transactions that make up the block. The size of the block can vary based on the blockchain type; for instance, Bitcoin's block size is limited to one megabyte.

The second element is the Transaction. This is the basic unit of a blockchain, representing the transfer of value from one address to another. The next element is the Address. These are unique identifiers used in blockchain transactions to denote senders and recipients. Typically, an address is a public key or derived from one. We can also visualize a simple chain to gain a better understanding:

Beyond the core components, a blockchain includes several other critical attributes that enhance its functionality:

• Peer-to-Peer Network: This network topology allows all peers to communicate directly, sending and receiving messages without intermediaries.

• Scripting or Programming Language: Scripts or programs perform operations on transactions to facilitate various functions. For instance, Bitcoin uses a language called Script, which allows essential operations but does not support arbitrary program development.

• Virtual Machine (VM): Extending transaction scripts, VMs enable Turing-complete code to run on a blockchain, facilitating smart contracts. Not all blockchains support VMs. Examples include the Ethereum Virtual Machine (EVM) and the Chain Virtual Machine (CVM).

• State Machine: A blockchain operates as a state transition mechanism, where the state is modified through transaction execution by nodes on the network.

• Smart Contracts: These programs encapsulate business logic, automatically executing when certain conditions are met. They are enforceable and highly desirable for their flexibility and power in applications such as identity management, capital markets, trade finance, and e-governance.

• Node: Nodes in a blockchain network have various roles, including proposing and validating transactions, performing mining, and ensuring consensus. They can also perform simple payment verification and transaction signing, proving ownership of assets through private keys.

Blockchain Functionality

Let’s walk through the general scheme of how a blockchain validates transactions and creates and adds blocks to the blockchain:

1. Transaction Initiation:

   • A node initiates a transaction by creating it and digitally signing it with its private key.

   • A transaction can represent various actions, most commonly the transfer of value between users on the blockchain network.

   • The transaction data structure typically includes the logic of the transfer, relevant rules, source and destination addresses, and other validation information.

   • Transactions are usually either a cryptocurrency transfer or a smart contract invocation.

2. Transaction Validation and Broadcast:

   • The transaction is propagated to other peers using data-dissemination protocols, such as the Gossip protocol.

   • Peers validate the transaction based on preset validity criteria before broadcasting it further.

3. Finding a New Block:

   • Validated transactions are included in a block by special participants called miners.

   • Miners start the process of mining, racing to finalize the block by solving a mathematical puzzle or fulfilling the requirements of the consensus mechanism.

4. New Block Found:

   • Once a miner solves the puzzle, the block is considered "found" and finalized.

   • The transaction is now considered confirmed.

   • In cryptocurrency blockchains like Bitcoin, the miner is rewarded with a certain number of coins as an incentive for their effort.

5. Adding the New Block to the Blockchain:

   • The newly created block is validated, and the transactions or smart contracts within it are executed.

   • The block is propagated to other peers, who also validate and execute it.

   • The block becomes part of the blockchain (ledger), with the next block cryptographically linking back to it via a hash pointer.

Conclusion

Understanding how a blockchain works is crucial for appreciating the details of this technology. From transaction initiation to block validation and propagation, each step ensures the security, transparency, and immutability of the blockchain. As we explore specific blockchain implementations like Bitcoin and Ethereum, these basic concepts will provide a solid foundation for deeper insights into blockchain functionality.

The main reference for this blog post is Mastering Blockchain: Inner workings of blockchain, from cryptography and decentralized identities, to DeFi, NFTs and Web3, Fourth Edition

Blockchain technology has revolutionized the way we think about data security, transparency, and decentralization. Originally devised as the backbone for Bitcoin, the first cryptocurrency, blockchain's potential reaches far beyond digital currencies. This blog post aims to demystify the basics of blockchain, exploring its fundamental architecture and providing a clear definition. Whether you're a tech enthusiast or a curious beginner, join us as we delve into the intricate yet fascinating world of blockchain technology, uncovering how it works and why it's poised to transform various industries.

Definitions

There are various definitions, but two are widely accepted:

1. Layman's definition: Blockchain is an ever-growing, secure, shared record keeping system in which each user of the data holds a copy of the records, which can only be updated if a majority of parties involved in a transaction agree to update.

2. Technical definition: Blockchain is a peer-to-peer, distributed ledger that is cryptographically secure, append-only, immutable (extremely hard to change), and updateable only via consensus among peers.

In the technical definition, some keywords have deep meanings, including peer-to-peer, distributed ledger, cryptographically secure, append-only, and updateable via consensus. These are the main features of blockchain.

• Peer-to-peer: peer-to-peer (P2P) refers to a decentralized network architecture where each participant (or node) interacts directly with others without the need for a central authority.

• Distributed Ledger: A distributed ledger is a digital database that is shared and synchronized across a network of multiple nodes, or participants. Unlike traditional centralized databases, where data is stored and controlled by a single entity, a distributed ledger distributes data across all nodes in a decentralized manner. Each node independently maintains an identical copy of the ledger.

• Cryptographically Secure: It means that cryptography has been used to provide security services that make this ledger secure against tampering and misuse. It refers to the robustness of cryptographic techniques employed to ensure the integrity, authenticity, and privacy of data and transactions within the blockchain network.

• Append-Only: The "append-only" feature in the context of blockchain refers to the fundamental principle that once data (such as transactions or blocks) is added to the blockchain, it cannot be altered, removed, or tampered with retroactively.

A blockchain can be altered in rare cases where bad actors collude and gain more than 51% control of the network.

• Updateable via Consensus: This means changes to the blockchain are made through agreement among network participants. Unlike centralized systems, blockchain updates are governed by decentralized mechanisms. All nodes must agree on changes, ensuring integrity and security. It allows the blockchain to evolve and adapt while staying decentralized and trustworthy.

Architecture

Understanding blockchain technology starts with exploring its layered architecture, similar to uncovering the details of a complex digital system. At its core, blockchain works within a well-organized framework that uses decentralized networks and cryptographic security. Let's look into each layer of this fascinating design:

|---------------|
|  Application  |
|---------------|
|   Execution   |
|---------------|
|   Consensus   |
|---------------|
| Cryptography  |
|---------------|
|      P2p      |
|---------------|
|    Network    |
|---------------|

1. Network Layer: At the foundation lies the network layer, the backbone that connects nodes across the globe. This layer leverages the Internet's infrastructure to facilitate peer-to-peer (P2P) communication among blockchain participants.

2. P2P Layer: A P2P (peer-to-peer) network runs on top of the Network layer, which consists of information propagation protocols such as gossip or flooding protocols.

3. Cryptography Layer: Securing the blockchain's integrity is the cryptography layer, where advanced mathematical algorithms play a pivotal role. Cryptographic techniques like hashing, digital signatures, and encryption safeguard transactions and data against tampering and unauthorized access. These mechanisms ensure transparency and trust in an inherently trustless environment.

4. Consensus Layer: Above the cryptography layer is the consensus layer, where network nodes agree on the validity and order of transactions. This crucial part of the blockchain architecture includes techniques like State Machine Replication (SMR), proof-based consensus mechanisms, and Byzantine fault-tolerant consensus protocols from traditional distributed systems research.

5. Execution Layer: The Execution layer includes virtual machines, blocks, transactions, and smart contracts. This layer handles key functions on the blockchain, such as processing transactions, running smart contracts, and creating new blocks. Virtual machines like the Ethereum Virtual Machine (EVM), Ethereum WebAssembly (ewasm), and Zinc VM offer the environments needed to execute smart contracts securely and efficiently.

6. Application Layer: At the Application layer, we find smart contracts, decentralized applications (dApps), DAOs (Decentralized Autonomous Organizations), and autonomous agents. This layer contains various user-facing entities and software that operate within the blockchain ecosystem. It's where users interact directly with decentralized applications, taking advantage of the innovative features provided by blockchain technology.

Conclusion

In conclusion, blockchain's layered design promotes innovation in various fields, from supply chains to digital identity. Understanding its architecture and principles shows its potential to change our digital future with decentralized, transparent, and secure solutions. Embrace the evolution of blockchain technology, where each layer plays a part in this transformative revolution.

Blockchain technology has changed how we think about data storage, transactions, and decentralized systems. To fully understand blockchain, it's important to know some basic principles from distributed systems, like the CAP theorem and PACELC theorem. These concepts help explain the trade-offs in blockchain design and implementation.

The CAP Theorem

The CAP theorem, introduced by Eric Brewer in 1998, states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees:

1. Consistency (C): Every read receives the most recent write or an error.

2. Availability (A): Every request receives a (non-error) response, without the guarantee that it contains the most recent write.

3. Partition Tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

In the context of blockchain:

• Consistency: Ensuring that all nodes in the network reflect the same state of the ledger.

• Availability: Guaranteeing that the blockchain is accessible and operational, allowing transactions to be processed.

• Partition Tolerance: The blockchain's ability to continue functioning even if there are network splits or delays.

Blockchains, being decentralized, must handle network partitions, which means they have to balance between consistency and availability. Bitcoin, for example, prioritizes availability and partition tolerance over immediate consistency. This means Bitcoin is always available for transactions, but consistency is achieved over time as the blockchain eventually reaches a consistent state across all nodes. This is known as eventual consistency, where consistency is achieved through validation from multiple nodes over time.

The PACELC Theorem

The PACELC theorem, proposed by Daniel J. Abadi, extends the CAP theorem by introducing another dimension to consider during normal operation. It states:

• If there is a Partition (P), then the system must trade off between Availability (A) and Consistency (C).

• Else (E), when the system is running normally, it must trade off between Latency (L) and Consistency (C).

In the context of blockchain:

• Partition (P): As previously discussed, blockchains must handle network partitions.

• Availability (A): The blockchain's ability to continue processing transactions.

• Consistency (C): Maintaining a uniform state across all nodes.

• Else (E): Under normal conditions without partitions.

• Latency (L): The time it takes to process and confirm transactions.

Conclusion

The CAP and PACELC theorems offer a theoretical framework to understand the trade-offs in distributed systems like blockchain. By examining how platforms like Bitcoin and Ethereum handle these trade-offs, we gain a better understanding of their design choices and operational behaviors. These principles are crucial for developing robust, efficient, and secure blockchain applications. As blockchain technology advances, new strategies and innovations will continue to emerge, addressing these trade-offs in new ways and expanding the capabilities of distributed systems.

Welcome to my blog! Today, I'll be sharing my experience in creating and cross-compiling a simple project in Rust for the Raspberry Pi 4. This guide will help you understand the steps involved and get you started on your own Rust projects for Raspberry Pi.

Rust also has the cross tool. "Cross" is a popular tool designed to simplify cross-compiling Rust code for various target architectures. In this tutorial, we will do the cross-compilation without this tool and will cover it in later tutorials.

Setting Up the Environment

1. Install Rust: Ensure you have Rust installed on your development machine. If not, you can install it using the following command:

    $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
   

2. Set Up the Rust Target: To find the architecture running on your Raspberry Pi, you can run the following command on your board:

    $ uname -a
    Linux raspberrypi 6.6.28+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22) aarch64 GNU/Linux
   

   As you can see, we are on an aarch64-linux-gnu machine. So, we select the target for the aarch64 architecture, which is needed for the Raspberry Pi 4.:

    $ rustup target add aarch64-unknown-linux-gnu
   

To see all supporting targets, look at the rustc documentation

3. Install the GCC Toolchain: You need the GCC toolchain for cross-compilation. On Ubuntu, you can install it with:

    $ sudo apt-get install gcc-aarch64-linux-gnu
   

Creating a Simple Rust Project

1. Create a New Rust Project: Use Cargo to create a new Rust project:

    $ cargo new hello_rust_pi
    $ cd hello_rust_pi
   

2. Write Your Rust Code: Open src/main.rs and write a simple "Hello, world!" program:

    fn main() {
        println!("Hello, Raspberry Pi!");
    }
   

Cross-Compiling the Project

1. Configure Cargo for Cross-Compilation: Create a .cargo/config.toml file in your project directory with the following content:

    [target.aarch64-unknown-linux-gnu]
    linker = "aarch64-linux-gnu-gcc"
   

2. Build the Project: Cross-compile your project using Cargo:

    $ cargo build --target=aarch64-unknown-linux-gnu
   

3. Transfer the Binary: After a successful build, transfer the binary to your Raspberry Pi using SCP:

    scp target/aarch64-unknown-linux-gnu/debug/hello_rust_pi pi@<your_pi_ip>:/home/pi/
   

Running the Project on Raspberry Pi

1. Connect to Your Raspberry Pi: SSH into your Raspberry Pi:

    ssh pi@<your_pi_ip>
   

2. Run the Binary: Make the binary executable and run it:

    $ chmod +x hello_rust_pi
    $ ./hello_rust_pi
   

   You should see the output:

    Hello, Raspberry Pi!
   

Conclusion

Congratulations! You've successfully created and cross-compiled a Rust project for the Raspberry Pi 4. This guide covered the basics, and there's so much more to explore in the world of Rust. Stay tuned for more tutorials and projects as I continue my Rust programming journey.

For accessing to last parts, click here.

In this part, we will install and setup ESP-IDF and look at creating projects and components, sdkconfig, and CMake files.

I am currently doing these steps on Linux, but these steps are repeatable on Windows and Mac. Our primary reference is ESP-IDF documentation. The items mentioned in this section are also fully described in this reference. To use IDF there are several prerequisites (such as Python, Git, Cross compilers, etc) that you must have installed. If you are using Windows, there is an installation wizard that automates the installation process. For Ubuntu or Debian you can use this command as follow: ( read this for the rest of architectures )

$ sudo apt-get install git wget flex bison gperf python3 python3-pip python3-setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

To install IDF, we first download its source from GitHub. You can download branches related to the specific releases, but I prefer to use the master branch.

$ mkdir -p ~/esp
$ cd ~/esp
$ git clone --recursive https://github.com/espressif/esp-idf.git

After downloading the files, go to the esp-idf folder and execute ./install.sh. We can pass one or more specific version names ( or all ) to download the cross-compilation tools for them.

$ cd ~/esp/esp-idf
$ ./install.sh esp32,esp32s2

Now it’s time to export the idf.py’s path to use it in our project. You can make an alias to make exporting easy. Put this alias in your .bashrc or .zshrc file.

alias get_idf='. $HOME/esp/esp-idf/export.sh'

Now source that file source ~/.bashrc or source ~/.zshrc. Finally, you can use idf.py without any issues. You can now go to the folder where you want to create the project and useidf.pyas follow:

$ get_idf # to load idf.py’s path
$ idf.py create-project tutorial

The project structure is as follow:

$ tree tutorial
├── CMakeLists.txt
└── main
    ├── CMakeLists.txt
    └── tutorial.c

The IDF structure is based on components. The project has the main component by default. You can add a new component by idf.py create-component -C components component-namecommand.

$ idf.py create-component -C components test-component
$ tree tutorial
├── CMakeLists.txt
├── components
│   └── test-component
│       ├── CMakeLists.txt
│       ├── include
│       │   └── test-component.h
│       └── test-component.c
└── main
    ├── CMakeLists.txt
    └── tutorial.c

The main component has a tutorial.c file that contains the program’s start point, the app_main function. You can use cpp instead of c, just add extern “C” before the app_main. I will cover this in the future.

The Cmake files contain scripts for building a project. In addition, such scripts exist in the IDF source, and we import them in the project's main CMake file to use the IDF components, ie include($ENV{IDF_PATH}/tools/cmake/project.cmake). In order to add the components folder just created to the project, we add the following command in the main CMakeLists.txt file:

set(EXTRA_COMPONENTS_DIRS components/)

As a result, IDF will locate the components we created.

The idf.py build command builds the project. If you want to compile the code for a specific family, you must first use idf.py set-target, otherwise, esp32 is selected by default.

$ idf.py set-target esp32
$ idf.py build

In this step, after building the code, errors are shown. If the build steps are successful, the idf.py flash -p portcommand will flash the binary file onto the module.

$ idf.py flash -p /dev/ttyUSB0

The question might be, where did IDF store this code in this 4MB of flash memory? The answer is in the Partition Table. We have the ability to divide the flash memory into different sections and the IDF writes binary files including bootloader, partition table, app, etc to the appropriate address based on the partition table we gave it. It uses esptool for flashing purposes. This tool has interesting features that we'll mention if necessary. By default, there are several partition tables that we can use or write a custom one. But where and how to make these settings?

With the idf.py menuconfig command, we can set a number of settings.

You can see different settings for different sections. We will survey this command in the next part. The output of this menu command is in the sdkconfig file, which is used during the compilation process. Our future components will have a section in the menuconfig so that we can systematically change their settings. If you run the above commands without any problems, your idf is ready and you can enter the next step. If there is a particular problem, share it so we can investigate.

Good luck.

Table of Contents

This will be updated

• Table of Contents
• Introduction
• ESP32 introduction

Introduction

Hello and welcome.

In this series, I am going to talk about using the ESP32 module. You will find good and enough information about setting up this module using the Arduino IDE on the Web. In addition, using the Arduino IDE makes a lot of things easier, but the core used for ESP32 is the ESP-IDF compiled.

The ESP-IDF is the espressif framework for ESP32 modules and their families (ESP32s2, ESP32s3, ESP32c3 and etc). If you check their GitHub, you will notice newly updated. However, the Arduino IDE Core is based on the specific ESP-IDF releases, so it doesn't update simultaneously with IDF. On the other hand, some configuration parameters (such as buffer sizes, etc.) were fixed when compiling the ESP-IDF source code. These limit your ability to configure and maneuver embedded systems.

In my case, I had to use the ESP-IDF instead of Arduino IDE, so I'm going to share with you what I learned about setting up the ESP-IDF in this series.

I would appreciate it if you would share your knowledge about this with me and if you found this content helpful, please share it with your friends as well.

ESP32 introduction

The ESP32 module is an SoC microcontroller that incorporates WiFi and Bluetooth. It is available in single-core and dual-core versions. These processors belong to the Xtensa family or RISC-V. The RAM and flash storage also differ according to the different versions.

Hardware Comparision

I use ESP32-CAM, which is based on ESP32-s from AiThinker. This module has a 2MP camera and a 4MB PSRAM and FLASH memory. There is no specific difference between their core ( ESP32 and ESP32-CAM ), so we choose the target to esp32 when compiling codes. Some variants have external PSRAM inside, while some do not. While some use the onboard PCB antenna, we can swap it out for an external antenna. We will discuss this in the future. I plan to talk about the following subjects for now based on what I have in mind:

• Setting up the ESP-IDF
• WiFi and provisioning
• Bluetooth
• HTTP client and server
• Socket client and server
• MQTT client
• ESP-NOW
• File systems and other storage
• Camera
• Mesh Network
• Face Detection via CNN
• WiFi CSI

Whenever you find something interesting or useful, tell me about it so we can check it out.

Thanks.