DEV Community: 이관호(Gwanho LEE)

Backend Architecture Fundamentals_part1

이관호(Gwanho LEE) — Wed, 11 Mar 2026 09:57:16 +0000

In this article, I summarize the core backend architecture concepts:

Load Balancing
Asynchronous Concurrency
Caching (Redis)
Database Scaling (Sharding & Replicas)
API Design
API Security
Monolithic vs Microservices Architecture

The goal is to understand why these patterns exist and how they help systems scale.

1. Load Balancing

When an application receives many user requests, sending all requests to a single server can quickly overwhelm it. A load balancer distributes incoming traffic across multiple servers so that no single server becomes overloaded.

This improves:

reliability
scalability
fault tolerance

If one server fails, the load balancer routes traffic to other healthy servers.

Example Architecture

          Users
            |
            v
        Load Balancer
             |
    |        |         |
|Server A|  |Server B|  |Server|

Example (NGINX Load Balancer)

http {
    upstream backend_servers {
        server app1.example.com;
        server app2.example.com;
        server app3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend_servers;
        }
    }
}

2. Asynchronous Concurrency

Modern backend systems must handle thousands of requests simultaneously. Blocking threads while waiting for database queries or network calls reduces performance.

Instead, many systems use asynchronous execution, allowing other tasks to run while waiting for I/O operations.

Rust commonly uses the Tokio runtime for asynchronous programming.

Example (Rust Async Server)

use tokio::net::TcpListener;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {

    let listener = TcpListener::bind("127.0.0.1:8080").await?;

    loop {
        let (socket, _) = listener.accept().await?;

        tokio::spawn(async move {
            println!("Handling new request");
        });
    }
}

3. Caching (Redis)

Many backend systems repeatedly fetch the same data (for example: product details or user sessions). Querying the database every time increases latency.

A cache stores frequently accessed data in memory, allowing extremely fast reads.

Redis is a popular in-memory key-value store used as a cache.

Typical Data Flow

        Client Request
              |
              v
         Redis Cache
              |
            (Miss)
              |
           Database

If the data exists in Redis, the system returns it immediately without querying the database.

Example (Redis in Rust)

use redis::Commands;

fn main() -> redis::RedisResult<()> {

    let client = redis::Client::open("redis://127.0.0.1/")?;
    let mut con = client.get_connection()?;

    con.set("user:1", "Tony")?;

    let name: String = con.get("user:1")?;

    println!("User name: {}", name);

    Ok(())
}

Redis dramatically reduces latency because data is stored in memory instead of disk.

4. Database Scaling

As applications grow, a single database may become a bottleneck.

Read Replicas

One primary database handles writes, while multiple replicas handle read requests.

                Write
     App --------------> Primary DB
                  |
               Replication
                  |
         ---------------------
         |        |         |
    Replica1   Replica2   Replica3

This reduces load on the primary database.

Database Sharding

Sharding means splitting a large database into smaller databases called shards.

Example:

Shard 1 → Users 1 - 1,000,000

Shard 2 → Users 1,000,001 - 2,000,000

Shard 3 → Users 2,000,001 - 3,000,000

This distributes the workload across multiple database servers.

5. API Design Principles

A well-designed API is predictable and easy to use.

Resource-Based Endpoints

Use nouns instead of verbs.

GET    /users
GET    /users/1
POST   /users
DELETE /users/1

API Versioning

Versioning allows backward compatibility when APIs evolve.

/api/v1/users
/api/v2/users

6. API Security

Security is critical in backend systems.

Rate Limiting

Limit the number of requests a user can make in a given time period.

Example:

100 requests per minute per IP

Firewalls

Firewalls act as traffic filters and block suspicious traffic before it reaches the server.

Authentication

Authentication ensures only authorized users access the system.

Common methods:

API Keys
OAuth
JWT (JSON Web Tokens)

Example concept:

fn validate_token(token: &str) -> bool {
    token == "valid_token"
}

7. Monolithic vs Microservices Architecture

Monolithic Architecture

All application features exist in a single codebase.

Advantages:

simple architecture
easier initial development

Disadvantages:

harder to scale
difficult deployments
tightly coupled code

Microservices Architecture

Microservices divide the system into independent services.

Example services:

User Service
Payment Service
Order Service
Notification Service

Each service can scale and deploy independently.

Final keywords

high traffic
reliability
scalability
Load balancing
Async concurrency
Redis caching
Database sharding
Secure API design
Microservice architecture

Deep Dive into `mithril-aggregator`: Core Responsibilities, HTTP Boundaries, and Certificate/Artifact Production

이관호(Gwanho LEE) — Sat, 28 Feb 2026 13:59:58 +0000

Why I Studied `mithril-aggregator`

After reading the Mithril client modules and contributing small fixes, I realized that the aggregator is the center of the whole Mithril system. The signer produces individual signatures, and the client verifies certificates and consumes artifacts, but the aggregator is where everything converges: it coordinates signers, collects signatures, produces Mithril certificates, and serves certified artifacts through HTTP endpoints.

From an engineering perspective, the aggregator is a great module to study because it contains many real-world infrastructure concerns: state machines, persistence, API boundaries, resource limits, and the “correctness glue” that ensures protocol outputs are verifiable. This post summarizes what I learned about the aggregator’s role, its internal structure, and the practical points where reliability and security matters the most.

What the Aggregator Does (High-level Responsibility)

The aggregator’s job can be summarized in one sentence:

Collect enough stake-backed signer signatures for an open message and produce a certificate + artifacts that clients can verify.

More concretely, the aggregator does the following:

1) Maintains epoch context (epoch settings, stake distribution, protocol parameters).

2) Accepts signer registration and signature submissions through HTTP APIs.

3) Selects or computes open messages that must be certified (snapshots, stake distributions, transactions, etc.).

4) Verifies incoming signatures and checks quorum/threshold conditions.

5) Aggregates individual signatures into a multi-signature and seals it into a Mithril certificate.

6) Builds and publishes certified artifacts (snapshots, proofs, metadata).

7) Serves data to clients via a stable HTTP API: certificates, artifact listings, artifact downloads, protocol configuration, metrics, and status.

A crucial design property is: the aggregator is often described as “trustless.” That does not mean “it can’t cause trouble,” but it means the correctness of its outputs can be checked by clients using cryptography and certificate chains.

Aggregator Architecture (Key Internal Areas)

The mithril-aggregator crate is large, but it becomes manageable when you group it into a few major responsibilities:

1) Runtime and state machine

The aggregator runs continuously. It typically uses a state machine loop to drive epoch transitions, open message creation, signature collection, and maintenance tasks. This is where liveness and correctness meet: the aggregator must progress through states safely without getting stuck.

2) HTTP server boundary (trust boundary)

The aggregator exposes routes for signers and clients. This is a major trust boundary because request bodies and inputs are untrusted. Good engineering requires early validation, strict parsing, and resource safety (limits, timeouts, and predictable error behavior).

3) Persistence layer (SQLite and repositories)

Certificates, open messages, signer registrations, stake pools, signatures, and artifact metadata are stored in a database. Persistence is critical because the aggregator must survive restarts and maintain a consistent view of protocol history.

4) Artifact pipeline and proof generation

The aggregator can certify multiple kinds of data. It builds artifacts (snapshots, stake distributions, transactions sets), computes their digests deterministically, and publishes them in a way clients can verify.

What Data Moves Through the Aggregator?

The aggregator receives different classes of data from different actors.

From signers (SPOs)

Signer registration payloads (identity, verification key material, version metadata)
Signature submissions for signing rounds
“won indexes” from the lottery system (justification of eligibility)

To clients (end users / infra tools)

Certificates (including certificate chain)
Artifact listings (available snapshots, stake distributions, transaction artifacts)
Artifact downloads (snapshot archive, proof data, metadata)
Protocol configuration and status endpoints (for diagnostics)

A key engineering insight: signer-facing endpoints are often write-heavy and must handle bursts; client-facing endpoints are read-heavy and must scale for downloads. These have very different performance and security concerns.

The Aggregator Happy Path (End-to-End)

A simplified “happy path” flow looks like this:

1) Startup
The aggregator loads configuration, initializes database/repositories, and starts the HTTP server plus runtime loop.

2) Epoch initialization
When a new epoch starts, it refreshes epoch settings and stake distribution and prepares for the next signing period.

3) Signer registration
Signers register their keys and metadata. The aggregator stores and validates registrations.

4) Open message creation
The aggregator determines the next “signed entity” to certify (for example, a snapshot digest). It stores this as an open message.

5) Signature collection
Signers submit signatures for this open message. The aggregator validates and stores them.

6) Quorum reached
Once enough stake-backed signatures are collected, the certifier aggregates them into a multi-signature.

7) Certificate creation
The aggregator creates a new certificate that links to the previous certificate (certificate chain).

8) Artifact publication
The aggregator builds/publishes the artifact and serves it, along with certificate chain data, to clients.

Clients then download the artifact + certificate and verify it independently.

Security and Reliability Boundaries (Where Bugs Matter Most)

Even if the protocol is “cryptographically trustless,” the aggregator is still an internet-facing service. A few practical engineering boundaries matter a lot:

1) Unbounded request body sizes (DoS risk)

If a route uses warp::body::json() without a request size limit, a remote client can attempt to send arbitrarily large bodies. That can force the server to buffer large payloads and consume memory/CPU during parsing. This is why adding warp::body::content_length_limit(...) before JSON parsing is a practical defense-in-depth improvement.

2) Ordering of validation

A best practice is: reject quickly before doing heavy work. For example, validate headers/auth/limits before parsing large bodies and before expensive cryptographic checks.

3) File and archive safety

Artifacts and snapshots can be large and often involve compression and archives. Unpacking/packing must be safe against path traversal and tarbomb-style resource exhaustion in any path that touches untrusted archive content.

4) Consistency invariants across epoch boundaries

The aggregator must not accidentally mix epoch context, stake distribution, or open message state across epochs. This is a classic source of subtle bugs in state-machine-driven distributed systems.

Important Invariants (What Must Always Be True)

When reading the aggregator code, these invariants are useful for auditing:

A certificate must link correctly to the previous certificate (certificate chain integrity).
A certificate must only be issued when quorum conditions are satisfied for the open message.
The artifact digest must match the message that was signed and certified.
Signer registration must be validated and tied to the correct epoch context.
The system must not panic or crash due to malformed inputs on public endpoints; it should return structured errors and remain operational.

Practical Engineering Takeaways

Studying the aggregator teaches valuable “real systems” skills beyond cryptography:

how to build and verify protocol outputs with durable persistence
how to handle public HTTP boundaries safely
how to manage long-running state machines without fragile defaults
how to reason about correctness invariants across epochs and rounds
how to implement defense-in-depth (application + infrastructure + protocol)

Because of this, auditing and contributing to the aggregator is high signal for hiring: it shows that you can work on production-grade distributed infrastructure, not just implement algorithms.

`mithril-signer`: State Machine Flow, KES Period, and Safe Registration

이관호(Gwanho LEE) — Sat, 28 Feb 2026 13:58:13 +0000

Why I Studied `mithril-signer`

After contributing to the Mithril project and reading the client/aggregator modules, I realized that the signer is one of the most critical components in the whole protocol. The signer is operated by stake pool operators (SPOs) and is responsible for producing the individual signatures that the aggregator later combines into a Mithril certificate. If signers crash or register incorrect data, then participation drops and certificate production can become slow or unstable. So understanding the signer is not only “reading code,” but understanding the real operational reliability of Mithril.

In this post, I summarize how mithril-signer works from an engineer’s point of view: the state machine (status) flow, how registration and signing rounds work, what kind of data moves between signer and aggregator, and why KES period handling is a correctness-sensitive part of registration.

What the Signer Does (High-level Responsibility)

You can think of the signer as a long-running daemon that repeats the following loop:

1) Observe chain context from a Cardano node (epoch, chain tip / slot context, and other values needed by the protocol).

2) Register itself for the current epoch (publish its verification key material and metadata so it can participate).

3) When the aggregator opens a message to be certified, run the lottery locally to decide eligibility.

4) If eligible, produce one or more signatures and submit them to the aggregator.

5) Persist local “already signed” markers so it does not re-sign the same entity repeatedly.

6) Retry safely when the node is still syncing or any dependency is temporarily unavailable.

The most important detail here is that the signer must behave safely under real-world conditions: node syncing, transient network failures, partial DB corruption, and other imperfect states. Reliability is part of the protocol’s real security because low signer participation affects liveness.

Signer Status / State Machine (How the Process Moves)

mithril-signer is implemented as a state machine. The exact enum names can vary by version, but the conceptual states are stable:

INIT: signer starts, loads configuration, initializes DB, logger, and internal services.
UNREGISTERED: signer is not registered for the current epoch. It should attempt registration (or wait if registration round is not open).
READY_TO_SIGN: signer is registered and eligible to participate in signing rounds.
REGISTERED_NOT_ABLE_TO_SIGN: signer is registered but cannot sign for some reason (not eligible in this epoch/round, stake conditions, or protocol constraints).

A key engineering point is that the runtime should not crash for ordinary “not ready yet” situations. In many flows, the correct behavior is to keep state and retry later, not panic or register with fake data.

What Data Moves Between Signer and Aggregator?

The signer communicates with the aggregator through HTTP endpoints. The data exchange has two main categories:

1) Registration data

This usually includes:

signer identity (pool id / party id),
signer verification key material,
protocol metadata (version, network),
additional fields required by the protocol for the epoch (e.g., KES-related fields depending on the build path).

This happens on startup and at epoch transitions.

2) Signature submission data

This includes:

a signature (cryptographic bytes encoded in JSON),
“won indexes” (the lottery results that justify why the signer can submit signatures),
identifiers tying this signature to the current open message.

This happens repeatedly during the operations phase whenever the aggregator has an open message.

What Is “Beacon” and Why Do We Store It?

In the signer code, “beacon” is a compact identifier for “what was signed.” You can treat it like:

A unique key that represents a specific signed entity at a specific time/epoch.

The signer stores signed beacons locally so it can answer this question:

“Have I already signed this entity? If yes, do not sign again.”

This is idempotency and it protects both:

protocol correctness (avoid duplicates)
operational health (avoid useless work)

When Does the Signer Check “Already Signed” Beacons?

This check typically happens after the signer has candidate messages to sign but before it generates signatures and submits them. A simplified flow looks like:

1) Determine which signed entities are candidates for this round.

2) Query local DB to filter out entities already signed (filter_out_already_signed_entities).

3) Only sign entities that are not already signed.

4) Store the signed beacon and submit signature(s) to the aggregator.

This is a critical control path. If this DB path crashes, the signer may repeatedly crash or repeatedly re-sign.

KES Period: What It Is and Why It Appears in Registration

KES stands for Key Evolving Signature, a Cardano mechanism where a node’s signing key evolves over time to limit the impact of long-term key compromise. The KES period is an index derived from chain time (slot/epoch context). In Mithril signer registration, KES period may be used to compute a derived value like KES evolutions, which indicates how far the current key period is from the start period encoded in the operational certificate.

The key idea is that KES-related values represent real chain state. If they are unknown, it is safer to treat them as “not ready” and retry rather than sending incorrect values.

Mithril Network Overview

이관호(Gwanho LEE) — Mon, 05 Jan 2026 22:17:00 +0000

Overview: Architecture, Protocol, and Security

The Mithril network is a decentralized system designed to provide secure and efficient validation of data on the Cardano blockchain without requiring users to run a full node.

By leveraging a Stake-based Threshold Multisignature (STM) scheme, Mithril allows a subset of stakeholders to sign messages in a way that is proportionally weighted by their stake. This enables fast verification while preserving Cardano’s economic security model.

Below is a comprehensive overview of the network’s architecture, operation, and security.

1. Core Participants (Nodes)

The Mithril network relies on four types of nodes. Each node operates as a state machine, meaning its behavior depends on well-defined states.

Mithril Signer

Mithril Signers are operated by Cardano Stake Pool Operators (SPOs). Their role is to independently sign blockchain state data.

States:

INIT: Initial setup when the node starts
UNREGISTERED: A new epoch has started, but the signer has not registered keys yet
READY TO SIGN: Successfully registered and eligible to sign
REGISTERED NOT ABLE TO SIGN: Registered, but not selected in the lottery for this round

Mithril Aggregator

The Aggregator is a trustless coordinator. It does not need to be trusted by clients.

Its responsibilities include:

collecting individual signatures from signers
aggregating them into a multisignature
issuing a Mithril certificate

States:

IDLE: Updating parameters at the start of an epoch
READY: Computing a message for a new signing trigger
SIGNING: Gathering signatures until the required quorum is reached

Mithril Client

The Client is used by end-users (such as wallets or infrastructure tools).

It:

downloads certified artifacts (snapshots, transaction sets, etc.)
downloads the associated certificates
verifies everything cryptographically, without trusting servers

Mithril Relay

The Relay is a security proxy (similar to Squid) that protects communication between Signers and the Aggregator.

It improves network security and privacy but does not affect protocol correctness.

2. How the Protocol Works (Phases)

The Mithril protocol operates in three main phases:

1) Establishment

Protocol parameters are defined:

m: number of lottery attempts per signer
k: required number of signatures (threshold)
ϕ: stake-weighted winning probability function

2) Initialization

At the start of each epoch:

Signers generate key pairs
They submit a Proof of Possession (PoP) to prevent rogue-key attacks
Signers register with the Aggregator
The Aggregator computes the Aggregate Verification Key (AVK) as a Merkle tree root

3) Operations

This phase runs repeatedly during an epoch:

Signers participate in a lottery for each message
Winning signers generate and send signatures
The Aggregator collects signatures
Once k valid signatures are collected, it creates a final Mithril certificate

3. Data Certification (Pluggable Modules)

Mithril uses a pluggable framework to certify different types of data.

Cardano Node Database (v1 / v2)

Enables node bootstrap in ~20 minutes instead of 24+ hours
v2 uses Merkle trees for incremental certification
Clients can verify only specific ranges of database files

Stake Distribution

Certifies the amount of stake held by SPOs at a specific epoch
Essential for sidechains, bridges, and cross-chain validation

Cardano Transactions

To certify millions of transactions efficiently, Mithril uses a Merkle Forest:

Blocks are grouped into ranges of 15
Each range forms a Merkle tree
Tree roots are combined into higher-level trees

This reduces memory usage by about 100×.

4. Security and the Certificate Chain

To prevent Eclipse Attacks (where an attacker shows a fake blockchain view), Mithril uses a Certificate Chain.

Genesis Certificate

The chain starts with a certificate signed by a special Genesis Key
This acts as the root of trust

Chain Validation

Each new certificate must reference a previous certificate
A certificate is valid only if its AVK was signed in an earlier verified certificate
Clients verify certificates by walking the chain back to the genesis certificate

Attack Resistance

Mithril defends against:

Long-range attacks using epoch-based checkpoints
Grinding attacks via strong randomness
Sybil attacks through stake-weighted eligibility and Proof of Possession

5. Engineering and Scalability Considerations

From an engineering perspective, Mithril is designed for efficiency and safety:

Scalability: Signing and verification costs grow as O(logN), not O(N)
Trustlessness: Even a malicious Aggregator cannot forge a valid certificate without k honest signatures
Finality: Transactions are certified only at a fixed offset (currently 100 blocks) from the chain tip to avoid rollbacks

Summary

Mithril replaces the need for full blockchain verification with a stake-backed cryptographic certificate.

By combining lottery-based signer selection, multisignatures, Merkle structures, and certificate chaining, it provides a scalable and secure foundation for fast synchronization and trust-minimized data access in the Cardano ecosystem.

ref(https://mithril.network/doc/mithril/intro)

Understanding Pallas and Mithril: Journey into Cardano Infrastructure

이관호(Gwanho LEE) — Sun, 04 Jan 2026 05:00:24 +0000

Introduction

In this post, I want to summarize what I have learned so far about the Pallas and Mithril projects in the Cardano ecosystem.

Before deep diving into the Mithril codebase and starting to contribute, I felt it was important to organize my understanding and thoughts clearly.

My goal is to become a blockchain engineer working on Cardano infrastructure, and this summary helps me confirm that I have the right mental model before moving forward.

Why the Pallas Project Exists

Cardano’s mainnet and core node software are implemented in Haskell. While Haskell is powerful, it creates a high barrier for developers who want to interact directly with Cardano using other languages, especially Rust.

If a developer wants to understand Cardano data formats, network protocols, or transaction structures at a low level, they usually need to read Haskell code and understand how cardano-node works internally.

This is where Pallas comes in.

Pallas is a collection of Rust libraries that re-implement Cardano’s data formats and protocols in a Rust-friendly way. It allows developers to interact with the Cardano mainnet without writing or deeply understanding Haskell. Instead, developers can use Rust to decode blocks, inspect transactions, build transactions, and communicate with Cardano nodes.

What Pallas Provides

Pallas is not a single library, but a set of modules, each with a specific responsibility:

primitives: defines Cardano data types such as transactions, blocks, values, scripts, and metadata
codec: handles serialization and deserialization (mainly CBOR)
network: implements Cardano node-to-node communication protocols
txbuilder: helps construct Cardano transactions
traverse: provides era-agnostic ways to inspect blocks and transactions
hardano: interoperates with Cardano node storage formats
crypto: cryptographic utilities used by Cardano
math / utxorpc: supporting utilities and interoperability layers

All of these modules focus on one core idea:

How to correctly represent, encode, decode, and interact with Cardano data and protocols in Rust.

Because of Pallas, Rust developers can build useful tools such as wallets, indexers, explorers, analytics services, and other infrastructure components without relying on Haskell code. This significantly lowers the entry barrier for system-level development in the Cardano ecosystem.

Why Mithril Exists

While Pallas helps developers interact with Cardano, another major challenge remains: verification and synchronization.

To fully verify Cardano data from scratch, a client normally needs to download and validate a very large amount of blockchain data. In practice, this means many applications depend on full nodes or trusted servers to provide data, because downloading and validating everything locally is slow and resource-intensive.

This is why Mithril was created.

Mithril provides a way to verify Cardano blockchain state efficiently, without downloading the entire chain. It does this by using stake-weighted cryptographic certificates.

Snapshots and Certificates (Important Distinction)

In Mithril, there are two different concepts:

A snapshot is a compressed representation of the Cardano chain state at a specific point in time.
A certificate is a small cryptographic proof showing that this snapshot was approved by stake pool operators representing a large percentage of total ADA stake.

A client downloads both the snapshot and its certificate.

The client then verifies the certificate locally. If the certificate is valid, the client can trust that the snapshot represents a chain state that the Cardano network agreed on at that time.

It is important to note that Mithril does not re-validate individual transactions or UTXOs. That work is already done by Cardano nodes. Mithril verifies agreement on the resulting state, not the full transaction history.

What Problem Mithril Solves

Mithril reduces the need to trust a single server and removes the need to download massive amounts of historical data just to get started. By verifying a small certificate instead of the full chain, clients can:

bootstrap much faster
reduce infrastructure and storage costs
rely on Cardano’s stake-based security model instead of centralized trust

This makes Mithril especially useful for infrastructure tools, indexers, research systems, and future interoperability solutions.

What I Did Not Deep Dive Into (Yet)

Topics such as bridges, sidechains, oracles, and cross-chain interoperability are closely related to Mithril, but they require a much deeper understanding of blockchain systems and security models.

For now, I chose not to dive deeply into these topics. I understand that Mithril helps make these systems safer and more verifiable, but I plan to study them later in more detail.

Deep dive into the Mithril project structure, understand how each module works, why it exists, and how the system operates end to end. My goal is to contribute to the Mithril project and grow as a blockchain engineer.

➡️ Rust Dev's Pallas Journey: Cardano in Rust Intro

이관호(Gwanho LEE) — Thu, 01 Jan 2026 10:43:55 +0000

source code(https://github.com/leepl37/Pallas-Explorer-Demo)

dive into Pallas, TxPipe's Rust toolkit for Cardano.

Modular Rust for blockchain without Haskell.

summary of pallas.

pallas-codec

CBOR serialization/deserialization foundation.

Example:

use pallas_codec::{Encode, Decode};
use pallas_codec::minicbor::Decoder;

#[derive(Encode, Decode)]
enum MyEnum { Value(u64) }

fn main() {
    let val = MyEnum::Value(42);
    let encoded = val.encode_to_vec().unwrap();
    let mut decoder = Decoder::new(&encoded);
    let decoded: MyEnum = decoder.decode().unwrap();
    if let MyEnum::Value(n) = decoded { println!("Decoded: {}", n); }
}

pallas-primitives

Ledger data structs across eras.

Example:


use pallas_primitives::MultiEraTx;

fn main() {
    let tx_bytes = vec![]; // CBOR bytes
    let tx = MultiEraTx::from_cbor_bytes(&tx_bytes).unwrap();
    println!("Fee: {:?}", tx.fees());
}

pallas-crypto

Hashes, sigs, VRF for security.

Example:

use pallas_crypto::{Blake2b256, Ed25519Bip32SecretKey, Ed25519Signature};
use rand::rngs::OsRng;
use rand::RngCore;

fn main() {
    let mut sk_bytes = [0u8; 32];
    OsRng.fill_bytes(&mut sk_bytes);
    let sk = Ed25519Bip32SecretKey::from_bytes(sk_bytes).unwrap();
    let data = b"test";
    let sig = Ed25519Signature::sign(&sk, data);
    println!("Sig valid: {}", sig.verify(&sk.public_key(), data));
}

pallas-addresses

Address encoding/decoding.

Example:


use pallas_addresses::Address;

fn main() {
    let addr = Address::from_bech32("addr1q...").unwrap();
    if let Address::Shelley(s) = addr {
        println!("Payment: {:?}", s.payment);
    }
}

pallas-txbuilder

Tx construction builder.

Example:

use pallas_txbuilder::Builder;
use pallas_primitives::ProtocolParameters;

fn main() {
    let params = ProtocolParameters::default();
    let mut builder = Builder::new(params);
    let min_fee = builder.min_fee().unwrap();
    println!("Min fee: {}", min_fee);
}

pallas-traverse

Data analysis/traversal.

Example:

use pallas_traverse::MultiEraBlock;

fn main() {
    let block_bytes = vec![]; // Bytes
    let block = MultiEraBlock::decode(&block_bytes).unwrap();
    for tx in block.txs() {
        println!("Inputs: {:?}", tx.inputs().len());
    }
}

pallas-network

Node communication stack.

Example:

use pallas_network::n2c::connect;

#[tokio::main]
async fn main() {
    let _mux = connect("relay.example:3001").await.unwrap();
}

pallas-hardano

Haskell node artifact interop.

Example:

use pallas_hardano::ImmutableFile;

use std::path::PathBuf;

fn main() {
    let path = PathBuf::from("chunk.file");
    let mut reader = ImmutableFile::open(&path).unwrap();
    if let Some(block) = reader.next() {
        println!("Block: {:?}", block.unwrap().header);
    }
}

pallas-math

Math utils for ledger/consensus.

Example:

use pallas_math::slot_to_epoch;

fn main() {
    let epoch = slot_to_epoch(1000000, 432000);
    println!("Epoch: {}", epoch); // ~2
}

pallas-utxorpc

UTxO-RPC querying.

Example:

use pallas_utxorpc::Client;

#[tokio::main]
async fn main() {
    let client = Client::connect("grpc://node:50051").await.unwrap();
    let tip = client.get_chain_tip().await.unwrap();
    println!("Tip: {:?}", tip);
}

easy to remember.

Layer 1: The Atoms

These modules handle the low-level rules of the universe: math, serialization, and cryptography.

pallas-codec:
- What: Implements CBOR (Concise Binary Object Representation) serialization.
- Why: Cardano uses binary CBOR, not JSON. This module maps Rust Structs to raw bytes using efficient macros.
pallas-crypto:
- What: Handles hashing (Blake2b) and signatures (Ed25519).
- Why: Bitcoin relies on SHA-256; Cardano relies on Blake2b-256 for performance and security.
pallas-math:
- What: Implements precise fixed-point arithmetic.
- Why: Floating-point errors (e.g., 0.1 + 0.2 != 0.3) are forbidden in consensus. This ensures exact agreement on staking rewards.

Layer 2: The Data

These modules define the data structures that populate the blockchain.

pallas-primitives:
- What: Defines the Rust Structs for TransactionBody, Block, and Header.
- Key Concept: Eras. Because of Hard Forks, a "Block" has different shapes in different years (Byron, Shelley, Alonzo, Babbage).
pallas-addresses:
- What: Parses human-readable strings (addr1...) into data.
- Key Concept: Bech32. It validates checksums and extracts the Payment Key (Ownership) and Stake Key (Voting Rights).

Layer 3: The Tools

These are the libraries you use to read and write data.

pallas-traverse:
- What: The most essential tool for reading chain data.
- Why: It provides a MultiEraBlock wrapper. This allows you to query data (e.g., block.tx_count()) without writing complex if/else logic for every hard fork era.
pallas-txbuilder:
- What: A helper to construct valid transaction binaries.
- Why: It manages the complexity of UTXO inputs, fee calculation, and change addresses.

Layer 4: The Infrastructure

These modules connect your code to the physical network.

pallas-network:
- What: Implements the Ouroboros mini-protocols (Handshake, ChainSync, TxSubmission).
- Why: Allows Rust code to connect directly to Mainnet nodes via TCP.
pallas-hardano:
- What: Reads raw ImmutableDB files directly from the hard drive.
- Why: Critical for high-performance local indexing (used heavily by Mithril).
pallas-utxorpc:
- What: A modern gRPC bridge to access blockchain data without managing Ouroboros state machines.

The Transaction Lifecycle

the life of a transaction on the Cardano Mainnet.

Creation: A Wallet builds a Tx using pallas-txbuilder (logic) and pallas-primitives (structs).
Submission: The Wallet pushes the Tx to a local Relay Node using pallas-network (TxSubmission protocol).
Propagation (Gossip): Relay nodes check validity and "gossip" the Tx to the Slot Leader's Mempool.
Consensus: The Slot Leader checks its VRF (Verifiable Random Function). If it wins the lottery, it mints a block.
Distribution: The Slot Leader broadcasts the new block using pallas-network (ChainSync protocol).
Observation: Your Pallas Client downloads the block and decodes it using pallas-traverse.

How Rust's Future Type Guarantees Scalable, Safe Asynchronous I/O

이관호(Gwanho LEE) — Thu, 04 Dec 2025 00:26:06 +0000

Introduction:

The Problem: Briefly explain why traditional thread-per-connection models struggle with high concurrency (too many threads cause high resource overhead and context-switching costs).

The Rust Promise: Introduce the Rust solution: Asynchronous Programming using Futures, emphasizing that it delivers C-style performance with Rust's signature memory safety.

🧱 Part I: The Foundation - The Future Trait Focus on what a Future is and is not.

Definition: A Future is just a trait representing a value that might be ready at some point. It is the fundamental building block of Rust's async ecosystem.

Lazy Execution: Explain the crucial concept: Futures are inert. They do nothing until they are actively polled by an executor (the runtime). This is the "compute when needed" principle.

Code Example 1: A Simple (Manual) Future

Show a basic custom Future implementation (e.g., a simple counter that increments on each poll or a future that resolves after a fixed number of polls). This is to illustrate the poll method directly, even if it's not a real-world scenario.


// Example 1: A basic custom Future (for illustrative purposes)
use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};
use std::time::{Duration, Instant};

struct MyFuture {
    start: Instant,
    duration: Duration,
}

impl Future for MyFuture {
    type Output = &'static str; // What this Future will produce

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        if self.start.elapsed() >= self.duration {
            println!("MyFuture is ready!");
            Poll::Ready("Done waiting!")
        } else {
            // If not ready, register the current task to be woken up.
            // In a real async runtime, this would involve registering with an event loop.
            cx.waker().wake_by_ref(); // For this simple example, we'll just wake ourselves
                                    // or a real runtime would ensure this gets polled again.
            println!("MyFuture is pending...");
            Poll::Pending
        }
    }
}

// How to create and run it (briefly, to show usage)
// Note: This won't run without an executor, but it shows the API.
async fn demonstrate_my_future() {
    let fut = MyFuture { start: Instant::now(), duration: Duration::from_millis(10) };
    println!("{}", fut.await); // This .await relies on an executor
}

The poll Method: (Crucial detail for experts) Briefly explain the signature of the poll method:

It returns Poll::Ready(T) (done) or Poll::Pending (not yet done).

The Waker is passed to wake the task when it's ready to be polled again.

✨ Part II: The Syntactic Sugar - async and await Explain how Rust makes the complex Future machinery easy to use.

async Block/Function: Explain that async fn is syntactic sugar for a function that returns an opaque type implementing the Future trait.

Analogy: It packages your code into a state machine.

await Operator: Explain that .await is the key mechanism. When you .await a Future:

If the Future is not ready, the task is yielded back to the executor.

This allows the single thread to go work on other tasks (Futures) instead of blocking.

Code Example 2: async/await in Action (Simple Task)

Show a basic async fn that does something simple, like tokio::time::sleep. This clearly demonstrates how await pauses execution without blocking the thread.


// Example 2: Simple async/await using Tokio
// Requires: `tokio = { version = "1", features = ["full"] }` in Cargo.toml

#[tokio::main] // This macro sets up the Tokio runtime
async fn main() {
    println!("Hello from main!");
    // Call an async function
    say_hello_after_delay().await;
    println!("Main function finished.");
}

async fn say_hello_after_delay() {
    println!("Inside async function: About to wait...");
    tokio::time::sleep(tokio::time::Duration::from_secs(1)).await; // .await pauses THIS task
    println!("Inside async function: Waited for 1 second!");
}

⚙️ Part III: The Engine - The Asynchronous Runtime Show the essential role of the Executor (the runtime).

The Executor's Role: A Future needs an executor (like Tokio or async-std) to drive its state machine forward.

The Event Loop: Describe how the runtime works: It takes pending Futures and efficiently schedules them onto a small pool of threads . When a task (Future) signals it's ready (via the Waker), the executor resumes polling that task.

Benefit: This model provides non-blocking I/O without the overhead of creating one operating system thread per connection, leading to high throughput.

Code Example 3: Concurrency with Multiple Async Tasks

Demonstrate tokio::spawn to run multiple Futures concurrently on a single (or small number of) thread(s), showing how the runtime interleaves their execution. This highlights the "non-blocking" nature.


// Example 3: Running multiple async tasks concurrently with Tokio
// Requires: `tokio = { version = "1", features = ["full"] }` in Cargo.toml

#[tokio::main]
async fn main() {
    println!("Main starting...");

    let task1 = tokio::spawn(async { // Spawn creates a Future and adds it to the executor
        for i in 1..=3 {
            println!("Task 1: {i}");
            tokio::time::sleep(tokio::time::Duration::from_millis(100)).await;
        }
        "Task 1 complete!" // Return value of the spawned future
    });

    let task2 = tokio::spawn(async {
        for i in 1..=2 {
            println!("  Task 2: {i}");
            tokio::time::sleep(tokio::time::Duration::from_millis(200)).await;
        }
        "Task 2 complete!"
    });

    // Await the results of the spawned tasks
    let result1 = task1.await.unwrap(); // .await on JoinHandle blocks current task until spawned task finishes
    let result2 = task2.await.unwrap();

    println!("{result1}");
    println!("{result2}");
    println!("Main finished.");
}

💻 Conclusion: Why Rust Async Shines Summary: Reiterate how the Future trait, async/await syntax, and efficient runtimes combine to make Rust a powerhouse for async programming.

Real-World Impact: Emphasize why this is crucial for blockchain and network services:

High Scalability: Handling thousands of concurrent connections efficiently.

Resource Efficiency: Lower memory footprint compared to thread-heavy models.

Rust's Safety Guarantees: All of this performance without data races or memory errors, thanks to the borrow checker and type system.

Final Call to Action: Encourage readers to experiment with async/await and explore Rust's ecosyste

Understanding Bitcoin Fundamentals: From Transactions to Consensus

이관호(Gwanho LEE) — Tue, 21 Oct 2025 04:26:35 +0000

This post is part of my deep dive into Bitcoin’s core architecture — studying directly from the official Bitcoin Developer Guide.

It summarizes everything I’ve learned so far before moving on to advanced topics like wallet architecture, the P2P network, and Taproot.

🧩 1. Bitcoin Overview

Bitcoin is a decentralized ledger that records all transactions without a central authority.

It achieves trustless consensus through cryptography, distributed nodes, and the Proof-of-Work mechanism.

Each node maintains a full copy of the blockchain — a chain of blocks that reference one another using cryptographic hashes.

💸 2. Transactions: The Heart of Bitcoin

Every Bitcoin transaction consists of inputs and outputs:

Input: References a previous unspent transaction output (UTXO).

It includes the public key and signature to unlock those funds.
Output: Defines the new recipient’s address (as a public key hash) and the amount being sent.

When Alice sends Bitcoin to Bob:

Her wallet creates a transaction using her UTXOs as inputs.
It generates an unlocking script (scriptSig) with her public key and signature.
The output specifies Bob’s public key hash — the new UTXO that only Bob can spend later.

🧮 3. Validation and the Memory Pool

When Alice’s transaction is broadcast:

Each node verifies it by checking:
- The referenced UTXOs exist and are unspent.
- The signature is valid.
- Inputs are larger than outputs.
- The fee is above the minimum relay fee.
Once validated, it’s added to the mempool (memory pool), where it waits to be mined.
Miners then pick transactions from the mempool, prioritizing those with higher fees.

⛏️ 4. Mining and Block Creation

Miners collect valid transactions into a block, which contains:

Version – protocol version number
Previous Block Hash – reference to the last block
Merkle Root – summary of all transaction hashes in the block
Timestamp – time when block was created
Difficulty Target – defines how hard the block is to mine
Nonce – value miners adjust to find a valid hash

Proof-of-Work (PoW)

To add a new block, miners must find a nonce that makes the block’s hash lower than the target difficulty.

This ensures that creating blocks requires computational work and prevents tampering.

If anyone changes even one transaction, the Merkle root changes →

the block hash changes → all subsequent blocks become invalid.

💰 5. Coinbase Transaction and Rewards

Each block starts with a coinbase transaction, which:

Rewards the miner with newly created bitcoins (block subsidy).
Collects all transaction fees in that block.

This coinbase transaction is mandatory under the consensus rules.

As block subsidies halve every 210,000 blocks, miners will eventually rely solely on transaction fees.

🔒 6. SegWit: Making Transactions More Efficient

The Segregated Witness (SegWit) upgrade moved signatures and public keys

from the scriptSig to a separate witness field, reducing transaction size and cost.

Benefits:

Lower fees (because signatures no longer count fully toward byte size).
Fixed transaction malleability.
Enabled second-layer solutions like the Lightning Network.

⚙️ 7. Fee Policies and Mempool Rules

Bitcoin nodes implement several fee and safety policies:

Policy	Description
Minimum Relay Fee	Reject transactions with fees below a certain threshold.
Dust Limit	Prevents outputs too small to be spent later.
Ancestor/Descendant Limit	Limits chains of unconfirmed transactions to avoid mempool flooding.
Replace-By-Fee (RBF)	Allows resending the same transaction with a higher fee.
Child-Pays-for-Parent (CPFP)	A child transaction can pay a higher fee to help confirm its parent.

These rules maintain efficiency and fairness within the network.

⚡ 8. Advanced Scripts: Multi-Signature and Timelocks

Bitcoin’s scripting system allows conditional spending — making Bitcoin programmable.

🧾 Multi-Signature

A multisig script requires multiple signatures to unlock funds, such as:
This means 2 of 3 participants must sign to spend the funds.

Used in Lightning Network channels and escrow systems.

⏳ Timelocks

Timelocks restrict when funds can be spent:

Type	Opcode	Description
Absolute Timelock	`CHECKLOCKTIMEVERIFY (CLTV)`	Funds are locked until a specific block height or timestamp.
Relative Timelock	`CHECKSEQUENCEVERIFY (CSV)`	Funds are locked for a certain number of blocks after confirmation.

These opcodes enable secure payment channels like Lightning Network.

⚡ Lightning Network Connection

In Lightning:

CLTV sets an absolute timeout for a channel.
CSV enforces a relative delay when closing a channel. This delay gives the honest party time to react if someone tries to cheat by broadcasting an old channel state.

🔗 9. Consensus and Immutability

Consensus ensures all nodes agree on the same blockchain state.

Each node selects the longest valid chain (most cumulative Proof-of-Work).
Any modification to old blocks changes their hashes, breaking the chain.
This immutability guarantees transparency and trust.

🧠 10. What I’ve Learned

Bitcoin’s security comes from cryptography, distributed consensus, and Proof-of-Work.
Every transaction is traceable through UTXOs, making the system auditable.
Scripts like multisig and timelocks add flexibility to Bitcoin’s functionality.
Understanding the mempool and fee policies explains why transactions confirm at different speeds.
SegWit and Lightning Network show how Bitcoin continues to evolve for scalability.

🌱 Reflection

Studying these fundamentals taught me not just how Bitcoin works,

but why it works this way — how every rule, from UTXOs to CSV, builds a secure, decentralized network.

It’s the foundation for my next step: learning about wallet architecture and P2P networking

to strengthen my Rust-based Bitcoin wallet project.

🚀 Understanding Proof-of-Work, Block Structure, Merkle Trees, and Consensus in Bitcoin

이관호(Gwanho LEE) — Wed, 01 Oct 2025 02:04:14 +0000

This post is part of my study journey following the Bitcoin Developer Guide. In particular, this article focuses on the Block Chain section.

As a developer preparing for a career in blockchain, I’m documenting what I’ve learned about how transactions, blocks, Merkle trees, consensus, and proof-of-work all fit together in Bitcoin.

🧩 Transactions: The Building Blocks

Every Bitcoin transaction is made up of:

Unlocking script (signature + public key): Proves the sender can spend a UTXO.
Locking script (public key hash): Ensures only the recipient can spend later.

👉 Example: Alice wants to send 0.6 BTC to Bob.

Alice provides her public key + signature to unlock her UTXOs.
She includes Bob’s public key hash as the new locking script.

This guarantees only Bob can later spend this Bitcoin.

🔄 The Flow of a Transaction

flowchart TD
    A[Alice Creates Transaction] --> B[Transaction Broadcasted]
    B --> C[Mempool: Waiting Room]
    C --> D[Miners Collect Transactions]
    D --> E[Transaction Packaged into Block]
    E --> F[Block Verified by Network]
    F --> G[Transaction Confirmed in Blockchain]

🌳 Merkle Trees: Efficient Transaction Summaries

From the Bitcoin Developer Guide: Block Chain section:

“Copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, the merkle root of a merkle tree.”

👉 Merkle Trees allow Bitcoin to efficiently prove that a transaction is included in a block.

Each transaction is hashed.
Hashes are paired, combined, and hashed again.
Process repeats until one hash remains → the Merkle Root.
The Merkle Root goes into the block header.

graph TD
    T1[Tx1] --> H1[Hash1]
    T2[Tx2] --> H2[Hash2]
    T3[Tx3] --> H3[Hash3]
    T4[Tx4] --> H4[Hash4]

    H1 --> H12[Hash(H1+H2)]
    H2 --> H12
    H3 --> H34[Hash(H3+H4)]
    H4 --> H34

    H12 --> Root[Merkle Root]
    H34 --> Root

👉 Key property:

If any transaction changes, its hash changes → which changes the Merkle Root → which changes the block header hash.

This makes tampering impossible without re-mining the entire chain.

🧱 Block Structure

According to the Bitcoin Developer Guide, each block header contains:

Version number → Identifies which set of consensus rules apply.
Previous Block Hash → Links to the block before it.
Merkle Root → Summary of all transactions.
Timestamp → When the block was created.
Difficulty Target → Mining difficulty.
Nonce → Random number miners adjust to find a valid solution.

This structure prevents tampering because every block depends on the hash of the block before it.

⚡ Proof-of-Work

Miners must find a nonce so that the block header hash is below the difficulty target.

On average, a block is mined every 10 minutes.
Difficulty adjusts every 2016 blocks (~2 weeks).
Changing even one transaction would force re-mining of that block and all blocks after it.

🤝 Consensus Rules

From the Consensus and Proof-of-Work section:

“When several nodes all have the same blocks in their blockchain, they are considered to be in consensus.”

Key Rules:

Valid blocks must meet all requirements (valid transactions, valid proof-of-work, correct structure).
Longest Chain Rule: All nodes follow the chain with the most cumulative proof-of-work.
Invalid blocks are rejected automatically.

👉 This ensures all nodes converge on the same blockchain history.

🦀 Rust Example: Simple Merkle Root

Here’s a small Rust snippet that shows how a Merkle Root is computed from a list of transactions (using sha2 crate).

use sha2::{Sha256, Digest};

fn hash(data: &[u8]) -> Vec<u8> {
    Sha256::digest(data).to_vec()
}

fn merkle_root(mut txs: Vec<&[u8]>) -> Vec<u8> {
    if txs.is_empty() {
        return vec![0u8; 32];
    }

    while txs.len() > 1 {
        let mut new_level = Vec::new();
        for i in (0..txs.len()).step_by(2) {
            let left = txs[i];
            let right = if i + 1 < txs.len() { txs[i + 1] } else { txs[i] }; // duplicate if odd
            let mut combined = Vec::new();
            combined.extend_from_slice(&hash(left));
            combined.extend_from_slice(&hash(right));
            new_level.push(hash(&combined));
        }
        txs = new_level.iter().map(|v| v.as_slice()).collect();
    }

    txs[0].to_vec()
}

fn main() {
    let txs = vec![b"tx1", b"tx2", b"tx3", b"tx4"];
    let root = merkle_root(txs);
    println!("Merkle Root: {:x?}", root);
}

🔐 Final Reflection

This post covered what the Bitcoin Developer Guide: Block Chain section describes:

Transactions (locking/unlocking scripts).
Mempool and transaction flow.
Block structure.
Merkle Trees.
Proof-of-Work.
Consensus rules (longest chain).

✨ Next Step: In the next post, I’ll explore the transaction lifecycle in detail—from creation to confirmation—so we can see how wallets and nodes actually handle them.

🍎 From UTXOs to SegWit: How Bitcoin Fixed Transaction Malleability and Lowered Fees

이관호(Gwanho LEE) — Fri, 26 Sep 2025 02:50:18 +0000

Introduction

If you’re building Bitcoin or Lightning applications in Rust, understanding the difference between legacy transactions and SegWit is crucial.

In this post, I’ll walk you through:

How UTXOs and scripts work
The problems with legacy transactions
How SegWit solved these problems
Why this matters for the Lightning Network

1. Legacy Transactions (P2PKH)

In Bitcoin’s original system, when Alice wants to send BTC to Bob, she must:

Sign the transaction with her private key
Provide her public key
Specify Bob’s public key hash as the output

Legacy Transaction Structure

Input (scriptSig = Unlocking script):

<signature> <publicKey>

Output (locking script):

OP_DUP OP_HASH160 <Bob’s publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Diagram – Legacy Transaction

[ Input ] -------------------------> [ Output ]
  scriptSig:                          locking script:
  <AliceSig> <AlicePubKey>            OP_DUP OP_HASH160 <BobPKH> OP_EQUALVERIFY OP_CHECKSIG

Here:

Alice proves ownership with her signature + public key.
Miners hash Alice’s public key, compare it to the UTXO’s public key hash, and check the signature.

2. Problems With Legacy Transactions

Malleability:

Transaction IDs included the signature. If anyone slightly modified the signature, the txid changed. This caused big problems for advanced protocols like Lightning.
High Fees:

Signatures and public keys are large. Bigger transactions → higher fees.

3. Enter SegWit (P2WPKH)

SegWit (Segregated Witness) moved the unlocking data (signature + public key) out of the scriptSig into a new structure called the witness.

scriptSig is now empty (or minimal).
Witness data is not included in the transaction ID calculation.

SegWit Transaction Structure

Input (scriptSig):

(empty or minimal)

Witness:

<signature> <publicKey>

Output (locking script – unchanged):

OP_DUP OP_HASH160 <Bob’s publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Diagram – SegWit Transaction

[ Input ] -----> [ Output ] + [ Witness ]
  scriptSig:       locking script:      witness data:
  (empty)          OP_DUP OP_HASH160    <AliceSig> <AlicePubKey>
                   <BobPKH>
                   OP_EQUALVERIFY
                   OP_CHECKSIG

4. Why This Matters

SegWit fixed two key issues:

No more malleability: Txids are stable because signatures aren’t included in the hash.
Lower fees: Witness data is discounted, making transactions smaller and cheaper.

5. Impact on Lightning Network

SegWit wasn’t just a cleanup. It enabled:

Lightning Network: Needs stable txids to work.
Scalability: More transactions fit into each block.
Future upgrades: Like Taproot, which builds on SegWit.

6. Rust Code Example

Here’s a simplified Rust example showing how legacy and SegWit signatures differ when building transactions.

use bitcoin::blockdata::transaction::Transaction;
use bitcoin::consensus::encode::serialize;
use bitcoin::util::sighash::SighashCache;
use bitcoin::{Amount, EcdsaSighashType};

// Legacy P2PKH signing
fn sign_legacy(tx: &Transaction, input_index: usize, script_pubkey: &bitcoin::Script, value: u64, privkey: &secp256k1::SecretKey) {
    let secp = secp256k1::Secp256k1::new();
    let mut cache = SighashCache::new(tx);
    let sighash = cache.legacy_signature_hash(input_index, script_pubkey, value, EcdsaSighashType::All).unwrap();
    let msg = secp256k1::Message::from_slice(&sighash).unwrap();
    let sig = secp.sign_ecdsa(&msg, privkey);
    println!("Legacy signature: {:?}", sig);
}

// SegWit P2WPKH signing
fn sign_segwit(tx: &Transaction, input_index: usize, script_code: &bitcoin::Script, value: u64, privkey: &secp256k1::SecretKey) {
    let secp = secp256k1::Secp256k1::new();
    let mut cache = SighashCache::new(tx);
    let sighash = cache.p2wpkh_signature_hash(input_index, script_code, Amount::from_sat(value), EcdsaSighashType::All).unwrap();
    let msg = secp256k1::Message::from_slice(&sighash[..]).unwrap();
    let sig = secp.sign_ecdsa(&msg, privkey);
    println!("SegWit signature: {:?}", sig);
}

Conclusion

By moving signatures into the witness field, Bitcoin became cheaper, safer, and faster.

As developers, understanding this transition is essential — not just for implementing wallets but also for building scalable Layer 2 solutions like Lightning.

Mastering Multi-Signature Transactions in Bitcoin: Workflow, Optimizations, and Trends

이관호(Gwanho LEE) — Wed, 24 Sep 2025 01:56:49 +0000

Multi-signature (multisig) wallets are fundamental to securing digital assets in the blockchain ecosystem, particularly Bitcoin. Their applications range from institutional custody to secure DAO treasuries. This post provides an expert-level deep dive into the multi-signature transaction process, enriched with advanced features, optimization techniques, and the current trends shaping this domain.

🔐 Phase 1: Wallet Setup

The initial step involves preparing the multi-signature environment across all cosigners:
1. Public Key Collection: All cosigners generate key pairs and exchange public keys securely.
2. Wallet Configuration: A multisig wallet is constructed using M-of-N schema (e.g., 2-of-3), leveraging public keys.
3. Shared Address Generation: The shared P2WSH (Pay-to-Witness-Script-Hash) address is derived.
4. Configuration Export/Import: Each cosigner imports the multisig setup, typically via QR code or configuration files.

📝 Phase 2: Transaction Creation & Signing

Once the wallet is live, the process of sending funds involves:
1. Transaction Drafting: One cosigner specifies recipient, amount, and fee — producing an unsigned PSBT (Partially Signed Bitcoin Transaction).
2. Signature Collection:
• The PSBT is shared across cosigners.
• Each participant signs it using their private key.
• Signatures are validated and deduplicated.
3. Threshold Checking: Once enough valid signatures are collected (e.g., 2 of 3), the transaction can be finalized.
4. Broadcasting: Final transaction is pushed to the Bitcoin network.

🧠 Tip: Always verify the transaction before finalizing — human errors or malware could alter recipients or fees.

🔍 Phase 3: UTXO Management (The Hidden Complexity)

While often abstracted by wallets, UTXO (Unspent Transaction Output) selection plays a critical role:
• Balance Updates: Wallets must scan the blockchain to update available UTXOs.
• Coin Selection: Efficient algorithms like Branch and Bound or Knapsack optimize which UTXOs to use.
• Fee Estimation: Depends on transaction size; SegWit discounts help reduce costs.

💡 Advanced: Implement custom UTXO selection logic in Rust using bdk for full control over coin selection policies.

🛡️ Phase 4: Signature Validation and Security Measures
• Partial Signature Collection: Ensure all cosigners sign independently, and only once.
• Duplicate Detection: Protects against accidental or malicious re-signing.
• Signature Verification: Use libraries like secp256k1 to validate signature authenticity.
• Threshold Confirmation: Confirm that the required M signatures are present before finalizing.

🔐 Security Tip: Use hardware wallets and air-gapped devices to sign transactions safely.

🌐 Phase 5: Transaction Broadcasting & Monitoring
• Network Validation: Ensure the mempool accepts the transaction (e.g., fee is sufficient).
• Transaction ID Tracking: Monitor confirmation status using tools like mempool.space.
• Failure Recovery: Handle cases where broadcast fails (e.g., replace-by-fee for stuck transactions).

📡 Broadcast Methods: Via full node (bitcoind), public APIs, or P2P broadcast protocols.

🧩 Optimization Techniques

To streamline the process, especially in high-frequency environments:
• Pre-signing Logic: Pre-authorize blank transactions with defined policies for fast execution.
• Signature Aggregation (MuSig2): Shortens the process by aggregating keys and signatures, reducing size and improving privacy.
• Session Management: Cosigner daemons maintain active sessions to minimize latency.
• Batching: Aggregate multiple outputs in one transaction to save fees.

📈 Trends and Future Directions
• Taproot & MuSig2: Enhances privacy and efficiency for multisig transactions.
• N-of-N with Scriptless Scripts: Removes script visibility, improving fungibility.
• Threshold Signature Schemes (TSS): Distributed signing without revealing full keys.
• Smart Contract Coordination: On chains like Bitcoin’s L2s (e.g., Lightning), multisig is increasingly coordinated via smart logic.

🛠 Recommended Rust Crates for Multisig Workflows
• bdk: Bitcoin Development Kit
• rust-bitcoin: Core Bitcoin types and serialization
• secp256k1: Signature validation
• miniscript: Policy-based scripting for complex conditions

📚 Conclusion

Understanding and mastering the multi-signature transaction process is crucial for advanced blockchain developers. Beyond the simple wallet setup and signing, a robust grasp of UTXO management, signature security, and network dynamics can set apart elite developers — especially those working in Rust and protocol engineering roles.

🚀 Pro Tip: Build your own multisig coordinator in Rust as a portfolio project. It demonstrates protocol-level understanding, cryptographic knowledge, and secure systems design.

Stay tuned for future posts covering Taproot-enabled multisig and integrating MuSig2 in Rust ecosystems.

From 404|1003 to the Green Lock: How I Fixed My Rust SMS Proxy on GCP with Caddy

이관호(Gwanho LEE) — Fri, 19 Sep 2025 04:19:19 +0000

TL;DR: I was calling my Rust SMS proxy on a Google Cloud VM by IP:8080, which caused Cloudflare 1003 errors and browser warnings. I mapped a hostname (example-proxy.example.com) to the VM, opened ports 80/443, put Caddy in front of my Rust app, and let it auto-issue a Let’s Encrypt certificate. Result: clean HTTPS endpoint that “just works,” and an easy env var for my Cloudflare Worker: SMS_API_URL=https://example-proxy.example.com/sms/send.

Why this post?

I built a Rust program that proxies SMS requests. It ran fine at http://203.0.113.45:8080, but when I integrated it with a Cloudflare Worker and the frontend, I started seeing:

404 Not Found (from my origin on routes I hadn’t defined yet)
Cloudflare 1003 (when requests were made by IP instead of a hostname)

This post documents what the errors actually mean, how the web stack sees your request, and the exact commands/configs I used to fix it—for real production use.

The stack (before & after)

Before

Rust SMS proxy (Axum/Actix/Hyper) → listening on 0.0.0.0:8080
Calls from Cloudflare Worker / browser sometimes used IP:8080 directly
No HTTPS on origin → mixed content and proxy restrictions

After

DNS hostname: example-proxy.example.com → A record → 203.0.113.45
Caddy on the VM listens on 80/443, terminates TLS with Let’s Encrypt
Caddy reverse_proxies to Rust at 127.0.0.1:8080
Worker ENV: SMS_API_URL=https://example-proxy.example.com/sms/send

The symptoms and what they actually mean

404 Not Found: The origin (your Rust app or upstream server) doesn’t have a route for the path you requested (e.g., /health). It’s not Cloudflare’s fault; it’s your app/router.
Cloudflare 1003: Cloudflare does not allow you to access its network by raw IP or with a mismatched Host header. If your code fetch()es http://203.0.113.45:8080/... through a CF zone, expect this. Cloudflare wants a domain that the zone knows about.
Mixed content / TLS issues: If your frontend is HTTPS but your API is HTTP, browsers can block or warn. You want HTTPS → HTTPS.

Key vocabulary (fast, practical definitions)

Hostname / FQDN: A human-readable name (e.g., example-proxy.example.com) that maps to an IP via DNS.
A record: DNS record that maps a hostname to an IPv4 address.
Reverse proxy: A public-facing server that forwards incoming requests to a private backend (our Rust app).
TLS (SSL): Encryption for HTTP. Gives you https:// and the browser’s green lock.
Let’s Encrypt: A free CA that issues certificates automatically. Caddy handles it for you.
SNI: The TLS extension that lets one IP serve many hostnames by telling the server which cert to use.
HTTP-01 challenge: Let’s Encrypt check that proves you control a domain by answering a request on port 80.
Origin: Your actual application server (here: Rust on 127.0.0.1:8080).
Edge: The public-facing entrypoint (here: Caddy on 80/443; sometimes Cloudflare or a load balancer).
CORS: Browser security policy for cross-origin requests. If a Cloudflare Worker calls your origin server-to-server, you usually don’t need CORS on the origin.
Project ID (GCP): The string identifier for your Google Cloud project (not the numeric project number).

The fix — exact steps (copy/paste friendly)

1) Point a hostname to your VM

I used DuckDNS to create example-proxy.example.com pointing to 203.0.113.45.

Quick check:

dig +short example-proxy.example.com
# Expect: 203.0.113.45

2) Open ports 80 and 443 in Google Cloud

We need 80 for Let’s Encrypt (HTTP-01) and 443 for real HTTPS traffic.

gcloud compute firewall-rules create allow-http  --allow tcp:80  --description="Allow HTTP"
gcloud compute firewall-rules create allow-https --allow tcp:443 --description="Allow HTTPS"

If gcloud complains about your project, set it first:
gcloud config set project YOUR_PROJECT_ID

3) Install Caddy

sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

4) Configure Caddy as a reverse proxy to Rust

Create /etc/caddy/Caddyfile:

example-proxy.example.com {
    reverse_proxy 127.0.0.1:8080
}

Reload Caddy and check status:

sudo systemctl reload caddy
sudo systemctl status caddy --no-pager

What happens here: Caddy automatically obtains a Let’s Encrypt certificate for example-proxy.example.com (using the HTTP-01 challenge on port 80), then starts serving HTTPS on port 443 with that cert.

5) Bind your Rust app to localhost

Keep port 8080 private behind Caddy:

./your_proxy_binary --host 127.0.0.1 --port 8080

If you had previously opened 8080 to the internet, you can remove/disable that firewall rule for security.

6) Test like a pro

If you have a health route:

curl -I https://example-proxy.example.com/health

If not, hit your real endpoint:

curl -i -X POST \
  -H "content-type: application/json" \
  -d '{"to":"+821012345678","text":"hello"}' \
  https://example-proxy.example.com/sms/send

You should see a clean HTTPS response from your Rust service through Caddy.

7) Point your Cloudflare Worker / backend env to the hostname

In code:

const endpoint = env.SMS_API_URL || "https://example-proxy.example.com/sms/send";

In wrangler.toml:

[vars]
SMS_API_URL = "https://example-proxy.example.com/sms/send"

Deploy your Worker/Pages and you’re done.

Why this works (the request flow explained)

DNS resolves example-proxy.example.com → 203.0.113.45.
The browser (or Worker) connects to port 443 and says via SNI: “I’m example-proxy.example.com.”
Caddy presents the valid Let’s Encrypt certificate for that hostname.
Caddy reverse_proxies the request to http://127.0.0.1:8080 (your Rust app).
The response streams back over the secure TLS connection to the client.

Result: a trusted green lock, no mixed content, no Cloudflare 1003, and a single stable URL for your app.

Troubleshooting & FAQs

Q: Caddy failed to get a certificate.

Ensure example-proxy.example.com resolves to 203.0.113.45.
Make sure ports 80/443 are open and reachable from the internet.
Check logs: journalctl -u caddy -n 100 --no-pager.
Confirm nothing else is already listening on port 80.

Q: I still get 404 on /health.

That’s your Rust router, not Caddy. Either add a route or test /sms/send.

Q: Do I need CORS?

If the browser calls your Rust origin directly, yes. If your Worker calls the origin server-to-server, you typically don’t need CORS on the origin.

Q: Could I use a Google HTTPS Load Balancer instead?

Yes. It’s managed TLS and scales nicely, but setup is heavier and may add cost. Caddy is a sweet spot for a single VM.

Q: Could I avoid opening ports with Cloudflare Tunnel?

Yes. A tunnel maps a public hostname to your private 127.0.0.1:8080 without exposing ports. It’s also a good option.

Security & production hardening

Bind Rust to 127.0.0.1 so only Caddy can reach it.
Close 8080 from the internet if you previously opened it.
Use env vars for endpoints and secrets.
Rate limit / auth your /sms/send to prevent abuse.
Monitor logs (journalctl, app logs) and set alerts.
Backups & updates: keep Caddy and OS packages updated.

Bonus: Minimal health route in Rust

Axum

use axum::{routing::{get, post}, Router};
use std::net::SocketAddr;

async fn health() -> &'static str { "ok" }
async fn send_sms() { /* your handler */ }

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/health", get(health))
        .route("/sms/send", post(send_sms));

    let addr: SocketAddr = "127.0.0.1:8080".parse().unwrap();
    axum::Server::bind(&addr).serve(app.into_make_service()).await.unwrap();
}

Actix‑web

use actix_web::{get, post, App, HttpServer, Responder, HttpResponse};

#[get("/health")]
async fn health() -> impl Responder { HttpResponse::Ok().body("ok") }

async fn send_sms() -> impl Responder { HttpResponse::Ok().finish() }

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| App::new().service(health).route("/sms/send", actix_web::web::post().to(send_sms)))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}

Final checklist

[ ] DNS: example-proxy.example.com → 203.0.113.45
[ ] GCP Firewall: 80/443 allowed
[ ] Caddy installed and reverse_proxy 127.0.0.1:8080
[ ] Rust bound to 127.0.0.1:8080
[ ] curl -I https://example-proxy.example.com/… works
[ ] Worker env: SMS_API_URL=https://example-proxy.example.com/sms/send

Takeaways

Don’t call your backend by raw IP—use a hostname.
Put a reverse proxy (Caddy/Nginx) at the edge to handle TLS.
Keep your app private on localhost; only expose 80/443.
Prefer env-driven endpoints so deployments are clean.

Now your Rust SMS proxy is production-ready with a proper HTTPS URL that your frontend and Workers can trust.

DEV Community: 이관호(Gwanho LEE)

Backend Architecture Fundamentals_part1

1. Load Balancing

Example Architecture

Example (NGINX Load Balancer)

2. Asynchronous Concurrency

Example (Rust Async Server)

3. Caching (Redis)

Typical Data Flow

Example (Redis in Rust)

4. Database Scaling

Read Replicas

Database Sharding

5. API Design Principles

Resource-Based Endpoints

API Versioning

6. API Security

Rate Limiting

Firewalls

Authentication

7. Monolithic vs Microservices Architecture

Monolithic Architecture

Microservices Architecture

Final keywords

Deep Dive into `mithril-aggregator`: Core Responsibilities, HTTP Boundaries, and Certificate/Artifact Production

Why I Studied mithril-aggregator

What the Aggregator Does (High-level Responsibility)

Aggregator Architecture (Key Internal Areas)

1) Runtime and state machine

2) HTTP server boundary (trust boundary)

3) Persistence layer (SQLite and repositories)

4) Artifact pipeline and proof generation

What Data Moves Through the Aggregator?

From signers (SPOs)

To clients (end users / infra tools)

The Aggregator Happy Path (End-to-End)

Security and Reliability Boundaries (Where Bugs Matter Most)

1) Unbounded request body sizes (DoS risk)

2) Ordering of validation

3) File and archive safety

4) Consistency invariants across epoch boundaries

Important Invariants (What Must Always Be True)

Practical Engineering Takeaways

`mithril-signer`: State Machine Flow, KES Period, and Safe Registration

Why I Studied mithril-signer

What the Signer Does (High-level Responsibility)

Signer Status / State Machine (How the Process Moves)

What Data Moves Between Signer and Aggregator?

1) Registration data

2) Signature submission data

What Is “Beacon” and Why Do We Store It?

When Does the Signer Check “Already Signed” Beacons?

KES Period: What It Is and Why It Appears in Registration

Mithril Network Overview

Overview: Architecture, Protocol, and Security

1. Core Participants (Nodes)

Mithril Signer

Mithril Aggregator

Mithril Client

Mithril Relay

2. How the Protocol Works (Phases)

1) Establishment

2) Initialization

3) Operations

3. Data Certification (Pluggable Modules)

Cardano Node Database (v1 / v2)

Stake Distribution

Cardano Transactions

4. Security and the Certificate Chain

Genesis Certificate

Chain Validation

Attack Resistance

5. Engineering and Scalability Considerations

Summary

Understanding Pallas and Mithril: Journey into Cardano Infrastructure

Introduction

Why the Pallas Project Exists

What Pallas Provides

Why Mithril Exists

Snapshots and Certificates (Important Distinction)

Why I Studied `mithril-aggregator`

Why I Studied `mithril-signer`