Project Link: aster.bryanchan.org

I recently noticed that the CLARITY Act _[1] is going to be voted on by the Senate soon. I'm not going to try and summarize every part of it, but it will help shape the future of cryptocurrency regulation in the United States.

It is possible that cryptocurrency markets will go up when the act passes, and there will be a lot of money to be made. That is interesting on its own, but it also reminded me that I had never actually learned about how any of the technology worked behind cryptocurrency. Sure, I knew the basics (there's a blockchain, supply/demand, cryptographic security), but...what does that REALLY mean?

In this blog, I intend to give a brief overview of what I've learned and showcase a small project I made that analyzes on-chain data.

(As a note, I'll mostly be talking about Ethereum, since that's what my project focuses on.)

What's a Blockchain?

A blockchain is a chain of blocks. Literally.

The blocks serve as an append-only, cryptographically linked ledger (AKA a book where you can only add to the end). I honestly haven't used the word "ledger" outside of crypto...

Each block contains a cryptographic hash of the previous block, so it's hard to tamper with past data (as it would change the hash of every subsequent block).

A blockchain can be centralized or decentralized. Bitcoin, Ethereum, and most other cryptocurrencies use a decentralized blockchain, where the ledger is maintained by a network of computers (nodes) that all agree on the state of the blockchain.

Going forward, I'll mainly be talking about decentralized blockchains.

Anatomy of a Block

In a decentralized ledger, each block contains:

• A list of transactions: The state updates (transfers, contract interactions) executed in that block. In the diagram below, transactions are represented using the acronym "Tx".
• A timestamp: When the block was produced.
• The previous block's hash: A cryptographic fingerprint of the parent block.
• State roots: Cryptographic trees (Merkle / Patricia trees _[2]) that summarize the entire global state of balances and contracts.

┌─────────────────────┐       ┌─────────────────────┐       ┌─────────────────────┐
│      Block #100     │       │      Block #101     │       │      Block #102     │
│ ─────────────────── │       │ ─────────────────── │       │ ─────────────────── │
│ Prev: 0x0000...     │◄──────┤ Prev: 0x9f3a...     │◄──────┤ Prev: 0x4c8e...     │
│ Tx: [Tx1, Tx2, ...] │       │ Tx: [Tx1, Tx2, ...] │       │ Tx: [Tx1, Tx2, ...] │
│ Hash: 0x9f3a...     │       │ Hash: 0x4c8e...     │       │ Hash: 0x7b1d...     │
└─────────────────────┘       └─────────────────────┘       └─────────────────────┘

Of course, you can store other data on the blockchain besides transactions. The important part is the hashing and linking of blocks.

I Had Some Questions.

Before diving into Ethereum specifically, there were a few fundamental questions that confused me as a newcomer:

1. How do we ensure that transactions are secure?

If there is no central bank or credit card company reviewing payments, what prevents someone from spending your coins or forging a transaction? For example, I could say that I have 100 ETH (Ethereum's currency), and then send 200 ETH to you. Why can't that happen on a blockchain?

Two main mechanisms protect the network:

1. State & Balance Verification (Ethereum uses an account-based model): Before executing a transaction, every node checks your account balance against the global blockchain state. If you try to transfer 200 ETH when you only have 100 ETH, every node on the network will independently reject the transaction as invalid.

2. Asymmetric (Public-Key) Cryptography:

   • Every wallet has a private key (secret key known only to you) and a corresponding public key (from which your public wallet address is derived).
   • When you initiate a transaction (e.g. "Send 5 ETH to Alice"), your wallet signs the transaction data with your private key using a mathematical digital signature algorithm like ECDSA _[3].
   • Any node on the network can use your public key to verify that the signature was generated by the holder of the private key—without ever learning the private key itself.
   • Every transaction also includes an account nonce (short for "number used once"). This is a sequential counter tracking the total number of transactions sent from your account (Tx #0, Tx #1, Tx #2...). The nonce guarantees transactions execute in strict order and prevents replay attacks (an eavesdropper intercepts a valid signed transaction and rebroadcasts it multiple times to drain your funds).
   • Because the signature is cryptographically bound to all transaction details (recipient, amount, gas fee, and nonce), altering any field in transit immediately invalidates the signature.

2. How can decentralization even be possible?

If thousands of anonymous, untrusted computers around the world can join the network, what prevents a bad actor from broadcasting fake blocks, rewriting past history, or spending coins twice (double-spending)?

This is known in distributed computing as the Byzantine Generals Problem _[4]—how independent parties reach consensus over an unreliable network when some participants may be corrupt or offline.

Blockchains solve this through consensus mechanisms backed by game theory:

• The network establishes strict mathematical and cryptographic rules for which blocks are valid.
• Following the rules is made economically profitable (nodes earn newly minted rewards and transaction fees).
• Attempting to cheat or attack the network is designed to be either computationally impossible or financially devastating.

To see how this works in practice, the two primary consensus models are Proof of Work and Proof of Stake:

┌────────────────────────────────────────┬────────────────────────────────────────┐
│         Proof of Work (PoW)            │         Proof of Stake (PoS)           │
├────────────────────────────────────────┼────────────────────────────────────────┤
│ • Security from computational energy   │ • Security from capital collateral     │
│ • "Miners" solve mathematical puzzles  │ • "Validators" stake 32 ETH            │
│ • Hardware-heavy (ASICs, GPUs)         │ • Lightweight compute (Raspberry Pi/PC)│
│ • High electricity consumption         │ • 99.95%+ energy reduction             │
│ • Probabilistic finality               │ • Deterministic slot/epoch finality    │
│ • Computationally expensive to attack  │ • Financial pain for attackers         │
└────────────────────────────────────────┴────────────────────────────────────────┘

A. Proof of Work

In Proof of Work _[5] (how Bitcoin runs, and how Ethereum ran prior to September 2022): - Nodes called miners compete to find a cryptographic mining nonce (an arbitrary integer in the block header) such that:

• Because cryptographic hash functions are one-way and pseudo-random, finding a nonce that outputs a hash with a required number of leading zeros is purely brute-force trial and error. The only way to win is by burning massive amounts of computational power and electricity.
• The miner who finds a valid nonce first broadcasts the block and receives the block reward.
• Security model: An attacker needs at least 51% of the entire global hash rate to rewrite history, which costs billions of dollars in hardware and electrical infrastructure.

B. Proof of Stake (Modern Ethereum / "The Merge")

In Proof of Stake (which Ethereum transitioned to during The Merge _[6]):

• Mining is replaced by validators who lock up capital collateral: 32 ETH per validator.

• Time is partitioned into Slots (12 seconds) and Epochs (32 slots $\approx$ 6.4 minutes).

• In each slot, a pseudo-random algorithm (RANDAO) elects one validator to be the Block Proposer, while a committee of other validators attest (vote on) the block's validity.

• If a validator misbehaves (e.g., proposing two conflicting blocks at the same slot, or double-signing), a portion or all of their 32 ETH stake is automatically destroyed (slashed) by the protocol.

3. What happens if multiple blocks are added at the exact same time?

Because nodes are spread across the world and data takes time to propagate across the internet, two miners (or validators) might produce a valid block at almost the exact same second.

When this happens, it creates a temporary split in the chain called a fork:

                       ┌──────────────┐
                 ┌────►│  Block 101a  │ ◄── (Nodes in Asia saw this first)
                 │     └──────────────┘
┌────────────┐   │
│ Block 100  ├───┤
└────────────┘   │
                 │     ┌──────────────┐       ┌──────────────┐
                 └────►│  Block 101b  │◄────  │  Block 102   │ ◄── Winner!
                       └──────────────┘       └──────────────┘
                        (Nodes in Europe saw this first, and mined Block 102 here)

How does the network resolve this tie?

• In Proof of Work (The Longest Chain Rule):
  Nodes temporarily keep both blocks in memory and build on whichever block they saw first. As soon as someone mines the next block (e.g. Block 102 built on top of 101b), that branch becomes the longest chain with more accumulated proof of work.
  All nodes automatically switch over to 101b -> 102. The abandoned Block 101a is discarded as an orphaned block (or stale block).

• What happens to transactions in the discarded block?
  Any transactions that were in Block 101a but not in 101b are automatically returned to the mempool (the pending transaction pool) so other miners can pick them up in subsequent blocks. No funds are lost or created out of thin air.

• In Proof of Stake (Slots & Attestation Votes):
  Because block production is partitioned into strict 12-second slots with only one designated proposer per slot, simultaneous blocks are very rare. If a validator maliciously proposes two blocks at once, they get slashed, and thousands of committee validators vote on the winning block using a fork-choice rule (LMD-GHOST). After ~12.8 minutes (2 epochs), the block is finalized and can never be reorganized.

This fork issue is actually why crypto exchanges will make you wait for several "confirmations" before letting you withdraw your coins - it's to make sure that the block containing your deposit doesn't get orphaned.

How Ethereum Works: The World Computer

While Bitcoin was designed primarily as digital cash (a distributed ledger of balances), Ethereum is a little different.

It was designed as a Turing-complete decentralized computer known as the Ethereum Virtual Machine (EVM) _[7].

Instead of just keeping a static record of who sent coins to whom, every node on the Ethereum network runs an execution environment that maintains a shared global computer state.

Anyone can write code, deploy it to the network, and guarantee that it will execute deterministically without relying on any central server, cloud provider, or company.

Accounts: EOAs vs. Smart Contracts

In Ethereum, there are two types of accounts:

1. Externally Owned Accounts (EOAs): Controlled by private keys (like a MetaMask wallet). They can hold ETH and initiate transactions.

2. Contract Accounts (Smart Contracts): Autonomous code deployed to the blockchain. When a transaction calls a contract, the EVM executes its instructions, modifying internal storage and interacting with other contracts.

Hold on, smart contracts? What are those?

Put simply, they are programs that run on the blockchain. Just like transactions, they are immutable and deterministic.

A simple example of a smart contract would be a vending machine. If you put in the right amount of money and select a snack, the machine will dispense the snack.

Gas: The Solution to Infinite Loops

Since the EVM can run arbitrary code, what prevents someone from deploying a contract with an infinite loop and freezing the entire network?

The answer is Gas _[8]:

• Every computational opcode (adding numbers, reading storage, writing data) has an associated gas cost.
• Users specify a gasLimit and pay a fee (baseFee + priorityTip in Gwei) per unit of gas consumed.
• If a transaction runs out of gas mid-execution, the EVM halts, reverts all state changes, and keeps the spent gas as a fee for the validators' compute time.

Beyond Simple Money: What Can Ethereum Actually Do?

Because Ethereum is a programmable state machine, developers have built an entire decentralized ecosystem on top of it. Some of the most notable capabilities include:

1. Custom Tokens & Assets (ERC-20 & ERC-721):

   • ERC-20 _[14]: The standard for fungible tokens, powering stablecoins (USDC, USDT, DAI) and wrapped assets (WBTC, WETH).
   • ERC-721 _[15]: The standard for Non-Fungible Tokens (NFTs), representing unique ownership of digital art, collectibles, or real-world assets.
   • Takeaway: Standardized contract templates make creating custom tokens fast and easy without reinventing the wheel.

2. Decentralized Finance (DeFi):

   • Automated Market Makers (DEXs): Protocols like Uniswap allow permissionless token trading against algorithmic liquidity pools ($x \cdot y = k$) without a centralized order book.
   • Lending & Borrowing: Protocols like Aave allow users to deposit collateral and borrow funds autonomously based on supply and demand.
   • Takeaway: Financial services become transparent and accessible to anyone with an internet connection.

3. Decentralized Identity (ENS - Ethereum Name Service):

   • Replaces 42-character hexadecimal addresses (0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045) with human-readable domain names (vitalik.eth).
   • Takeaway: It's essentially the DNS system for Web3!

4. Composability ("Money Legos"):

   • The superpower of Ethereum: smart contracts can call and interact with other smart contracts within a single atomic transaction.
   • Example: You can borrow USDC on Aave $\rightarrow$ swap it for ETH on Uniswap $\rightarrow$ deposit it into a yield vault all in one block. If any step fails, the entire sequence reverts cleanly as if it never happened.

5. Decentralized Autonomous Organizations (DAOs):

   • Organizations, venture treasuries, and protocol governance managed transparently via on-chain token voting rather than traditional corporate boards.
   • Example: Trust funds could be replaced by DAOs where funds are released only when a specific percentage of token holders vote to approve it.

The main language that contracts are written in is Solidity. Developers compile this code into bytecode, which the EVM then executes on each network node.

There's a lot more to Ethereum (i.e. sharding, Layer 2s, etc.), but this is enough to understand what's going on with this project. If I continue going down the path of Web3 development, I'll surely make more blogs with more technical info.

Aster

Aster Dashboard

I wanted to build something that analyzes this firehose of on-chain data in real time.

That project is Aster (Live at aster.bryanchan.org), and it's my introductory project to Web3 development.

Why Track "Whales"?

In traditional finance, hedge funds and institutional market makers hide their orders in private dark pools. You rarely know when a multi-billion dollar fund is entering or exiting a position until regulatory filings come out months later.

However, everything is public on a blockchain. If an entity holding a significant amount of ETH decides to move funds, that transaction is broadcast to the network for everyone to see immediately.

In particular, observing Exchange Flows provides valuable market intelligence:

• Exchange Inflow (Sell Pressure): A whale moves 10,000 ETH into a Binance or Coinbase hot wallet. This often signals intent to liquidate or sell.
• Exchange Outflow (Accumulation): A whale withdraws 10,000 ETH from an exchange into a multi-sig cold wallet. This signals long-term holding and supply withdrawal from circulation.

It should be noted that we wouldn't know WHO owns these wallets (unless they're publicly known). Regardless, we can track money movement.

System Architecture: The Rust Actor Model

Aster is built in Rust using Alloy _[10], Tokio, and Axum. Instead of relying on expensive third-party RPC services with strict rate limits (like Infura or Alchemy), Aster connects directly to a private Reth _[9] execution node running locally on my NAS over WebSocket.

┌─────────────────────────┐          ┌──────────────────────────────────────────────┐
│  Reth Execution Node    │          │            Aster Core Engine (Rust)          │
│       (Local NAS)       │          │                                              │
│                         │          │  1. Ingestion (Alloy WsConnect Provider)     │
│  - Full Ethereum State  ├─────────►│     - Live block stream & history seeder     │
│  - JSON-RPC over WS     │  WS RPC  │         │                                    │
│    (port 8546)          │          │         ▼                                    │
└─────────────────────────┘          │  2. Processing (Alloy Primitives & sol!)     │
                                     │     - Decodes ERC-20 & Uniswap swaps         │
┌─────────────────────────┐          │     - Filters whale thresholds via USD feed  │
│   Svelte 5 Dashboard    │          │         │                                    │
│                         │          │         ▼                                    │
│  - Real-time Runes UI   │  HTTP/SSE│  3. Storage & Action Actors                  │
│  - Live Whale Alerts    │◄─────────┤     - SQLite (WAL mode) & alert dispatch     │
│                         │          │         │                                    │
└─────────────────────────┘          │         ▼                                    │
                                     │  4. Axum Web Server (:3000)                  │
                                     └──────────────────────────────────────────────┘

The Reth Node is a client that connects to other nodes to "gossip" about blocks and transactions. Aster reads the gossip (it gets all the tea ;D). This is our information source.

The service is split into concurrent, asynchronous actors:

1. Ingestion Actor:

   • Alloy WebSocket Provider: Uses Alloy's WsConnect to maintain a persistent connection to the local Reth node.
   • Historical Backfill: Seeds some of the blockchain's history on startup using concurrent worker tasks.
   • Live Ingestion: Subscribes to new, incoming blocks over WebSocket for low-latency delivery.

2. Processing Actor:

   • Transaction Decoding: Uses Alloy's compile-time sol! (Solidity contract abstraction) macro to parse native transfers, ERC-20 tokens (USDC, USDT, WBTC), and Uniswap V2 & V3 _[11] multi-hop swaps.
   • Pre-Tx Balance Verification: Queries the sender's balance at block $N-1$ to confirm whale tier.
   • Entity Tagging: Resolves ENS names (vitalik.eth) and tags wallets (e.g., Wintermute, Binance) via the Blockscout API _[12].

3. Action & Storage Actors:

   • Database Worker: Uses SQLite in Write-Ahead Logging (WAL) mode to calculate running whale acquisition cost bases, realized profit/loss, and hourly time-series rollups. This makes it so the stats don't have to be recalculated every time.
   • Alert Dispatchers: Broadcasts real-time alerts to Discord Webhooks, Telegram Bots, and Server-Sent Events (SSE). (I don't have these actively firing right now, but they are fully implemented in the code.)

The Frontend: Reactive Svelte 5 Dashboard

The frontend is an embedded Svelte 5 _[13] single-page app bundled straight into the Rust binary via rust-embed.

The reason for choosing Svelte (over something like React) is related to its performance. Svelte has no Virtual DOM overhead because it is a compiler rather than a runtime library. Instead of diffing an entire component tree on state changes like React, Svelte compiles reactive assignments directly into surgical DOM updates.

Other than that, there isn't too much to add. Server-Sent Events (SSE) are used...as mentioned earlier...

That's all though!

Yay! We Good.

Aster is currently still being built, so there are many features that are not yet implemented (not to mention current bugs...).

This blog will be updated as I make more progress.

Thanks for reading!

References