DEV Community: Devs of Midnight

Compact을 시작하기 전 알아야 할 Midnight의 작동 방식

Midnight Korea — Thu, 07 May 2026 05:16:24 +0000

EVM 네트워크에서 개발해본 분이라면 익숙한 흐름이 있을 겁니다. 문법을 익히고, 스마트 컨트랙트를 작성하고, 온체인에 배포하고, 실행 비용은 가스로 지불하는 방식입니다.

하지만 Midnight은 단순히 문법만 다른 플랫폼이 아닙니다. Compact은 처음 보면 어느 정도 익숙해 보이지만, 실제로는 로컬 실행, ZK 증명, 그리고 명시적 공개(explicit disclosure)를 중심에 둔 다른 실행 모델 위에서 동작합니다.

이 글에서는 Midnight이 EVM과 어떻게 다른지, 왜 Compact을 단순히 “새로운 스마트 컨트랙트 언어”로만 보면 안 되는지, 그리고 환경 설정에 들어가기 전에 왜 이 차이를 먼저 이해해야 하는지 살펴봅니다.

익숙해 보이는 문법, 전혀 다른 실행 방식

Compact 예제를 처음 보면 크게 낯설지 않을 수 있습니다.

타입 선언이 있고, export가 보이며, 전체적인 문법도 저수준 암호학 언어라기보다는 TypeScript에 가까워 보입니다.

이 첫인상은 분명 진입 장벽을 낮춰줍니다. 다만 동시에 오해를 만들기도 합니다.

Compact은 일부 문법이 익숙할 뿐, 실행 방식까지 익숙한 것은 아닙니다. 겉으로는 코드를 읽을 수 있어 보여도, 실제로 그 코드가 어디에서 실행되는지, 어떤 값이 공개되는지, 네트워크가 정확히 무엇을 검증하는지는 놓치기 쉽습니다.

그래서 Compact을 “스마트 컨트랙트 언어가 하나 더 나왔구나” 정도로 받아들이면 곧 헷갈리게 됩니다. 문법은 읽히는데, 설계 방식은 기존 EVM 기반 개발과 다르기 때문입니다.

이 글은 바로 그 지점, 즉 문법은 익숙하지만 사고방식은 달라지는 간극을 먼저 짚기 위한 가이드입니다.

EVM과 Midnight의 가장 큰 차이: 실행 모델

EVM 네트워크의 실행 모델은 비교적 직관적입니다.

사용자가 트랜잭션을 제출합니다.
네트워크의 노드들이 같은 코드를 다시 실행합니다.
실행 결과에 따라 상태가 바뀝니다.
사용자는 실행 비용으로 가스를 지불합니다.

즉, 실행도 온체인에서 일어나고 상태 전이도 온체인에서 처리됩니다. 네트워크는 같은 계산을 반복하고, 그 결과를 기준으로 상태를 검증합니다. 이해하기 쉬운 구조지만, 실행 과정과 상태가 기본적으로 공개되는 모델에 가깝습니다.

Midnight은 다르게 동작합니다.

사용자가 로컬에서 로직을 실행합니다.
그 실행이 규칙에 맞았음을 보여주는 ZK proof를 생성합니다.
공개해야 하는 결과와 transcript를 네트워크에 제출합니다.
네트워크는 증명을 검증한 뒤, transcript에 포함된 공개 상태 전이만 온체인에서 실행합니다.

핵심은 여기에 있습니다.

EVM에서는 모든 노드가 전체 로직을 다시 실행합니다.

Midnight에서는 사용자가 로컬에서 프라이빗 연산을 수행하고, 네트워크는 그 결과가 규칙에 맞는지를 증명으로 검증한 뒤 공개 상태 전이만 반영합니다.

따라서 Midnight에서는 단순히 “함수를 호출한다”는 관점만으로는 부족합니다. 그 연산이 무엇을 증명하는지, 그리고 그 결과가 어떤 공개 상태 전이로 이어지는지까지 함께 봐야 합니다.

상태와 자산을 바라보는 방식

EVM 개발자에게 익숙한 모델은 보통 account 모델입니다. 글로벌 상태 안에 주소별 잔액과 값이 있고, 트랜잭션이 그 값을 직접 바꾸는 방식입니다.

Midnight은 출발점이 다릅니다. 핵심 자산 메커니즘은 UTXO 기반 구조를 사용하며, 이 구조는 프라이버시를 보존하는 설계와 잘 맞습니다. 잔액을 직접 수정하기보다, 기존 입력을 소비하고 새로운 출력을 만드는 방식으로 자산이 이동합니다.

EVM식으로 표현하면 “Alice의 잔액에서 40을 빼고 Bob의 잔액에 40을 더한다”에 가깝습니다.

반면 Midnight식으로 보면 “기존 입력 UTXO를 소비하고, Bob에게 보낼 출력 하나와 Alice의 잔돈에 해당하는 출력 하나를 새로 만든다”는 설명이 더 자연스럽습니다.

다만 Midnight을 단순한 UTXO 체인으로만 이해해도 오해가 생깁니다. Midnight은 순수 UTXO 체인이 아니라 하이브리드 구조를 사용합니다. ledger token 메커니즘은 UTXO 기반이지만, Compact으로 작성한 스마트 컨트랙트의 자산과 로직은 경우에 따라 account 스타일에 가까운 패턴으로 동작할 수도 있습니다.

그래서 Midnight을 이해할 때 더 적절한 표현은 “EVM의 반대”가 아닙니다.

Midnight은 UTXO 기반 자산 메커니즘과, 필요할 경우 account 스타일의 스마트 컨트랙트 동작을 함께 사용하는, 프라이버시와 증명 중심의 체인에 가깝습니다.

Compact을 기존 스마트 컨트랙트 언어처럼 보면 안 되는 이유

Compact을 처음 접할 때 흔히 하는 실수는, 이를 단순히 새로운 스마트 컨트랙트 문법으로만 보는 것입니다. 하지만 Compact은 문법만 새로 익힌다고 충분히 이해되는 언어가 아닙니다. 서로 다른 세 가지 맥락을 동시에 구분해야 합니다.

ledger: 온체인에 남는 공개 상태
circuit: 증명 시스템의 일부가 되는 로직
witness: 로컬에서 제공되는 프라이빗 데이터. 일회성 입력일 수도 있고, 로컬에서 유지되는 프라이빗 상태나 기록의 일부일 수도 있음

이 구분이 중요합니다.

EVM에서는 상태 변수와 함수 호출을 중심으로 생각해도 대부분의 설계가 가능합니다. 하지만 Compact에서는 질문 자체가 달라집니다.

이 값은 어디에서 왔는가?
이 로직은 정확히 무엇을 증명하는가?
이 값은 끝까지 프라이빗하게 남는가, 아니면 공개되는가?

즉, 핵심은 새로운 문법이 아니라 공개 상태, 증명 로직, 프라이빗 데이터 사이의 경계가 새롭게 정의되어 있다는 점입니다.

이 경계를 이해하지 못하면 코드는 읽을 수 있어도, 그 언어로 실제 설계를 하기는 어렵습니다.

`disclose()`는 왜 필요할까

EVM 네트워크에서는 상태와 실행 결과가 기본적으로 공개됩니다. 별도로 “이 값은 공개하겠습니다”라고 선언하지 않아도, 온체인에 올라간 정보는 자연스럽게 공개됩니다.

Midnight은 반대 방향에서 출발합니다.

Midnight에서는 프라이버시가 기본값이고, 공개는 명시적인 선택입니다.

그래서 Compact에서는 witness나 프라이빗 연산에서 나온 값을 ledger로 넘길 때 disclose()를 사용합니다. 이는 단순한 헬퍼 함수가 아닙니다. 개발자가 “이 값은 공개하겠다”는 의도를 코드 안에서 명확히 드러내게 하는 장치입니다.

이 설계는 다음과 같은 의미를 갖습니다.

민감한 데이터가 실수로 노출될 가능성을 줄입니다.
어떤 값이 공개되는지 개발자가 더 신중하게 판단하게 합니다.
Midnight의 프라이버시 중심 모델을 언어 차원에서 드러냅니다.

따라서 disclose()를 어색한 문법 요소 정도로 보면 안 됩니다. 오히려 이 함수는 Midnight이 EVM의 “기본 공개” 모델과 얼마나 다르게 설계되어 있는지를 가장 직접적으로 보여주는 요소 중 하나입니다.

Midnight은 문법보다 사고방식이 먼저입니다

여기까지 보면 핵심이 분명해집니다. Midnight을 또 하나의 EVM 계열 스택처럼 접근하면, 처음에는 익숙해 보여도 실제 개발에 들어갔을 때 금방 한계를 느낄 수 있습니다.

EVM에서는 보통 다음과 같은 전제를 깔고 개발합니다.

함수는 온체인에서 실행된다.
상태는 기본적으로 공개된다.
노드들은 같은 로직을 반복 실행한다.
가스는 거래 가능한 토큰에서 나온다.

Midnight에서는 이 전제가 바뀝니다.

사용자는 로컬에서 프라이빗 연산을 수행하고 증명을 생성합니다.
공개는 자동이 아니라 명시적입니다.
네트워크는 전체 로직을 다시 실행하지 않고, 증명을 검증한 뒤 transcript에 담긴 공개 상태 전이만 반영합니다.
경제·운영 모델 역시 NIGHT와 DUST를 중심으로 다르게 설계되어 있습니다.

결국 Midnight을 배운다는 것은 Compact 문법을 외우는 일이 아닙니다.

더 정확히는, 프라이버시와 증명 생성이 기본 전제로 들어간 환경에서 스마트 컨트랙트를 어떻게 설계해야 하는지 다시 배우는 과정에 가깝습니다.

이 시리즈가 DUST부터 다루는 이유도 여기에 있습니다. Midnight은 단순히 “어떻게 작성하는가”만 바꾸는 플랫폼이 아니라, “어떻게 실행되고 운영되는가”까지 함께 바꾸는 플랫폼이기 때문입니다.

Next Step: 환경 설정

이 글이 의도한 대로 전달되었다면, Compact이 왜 처음에는 익숙해 보여도 실제로는 전혀 다른 방식으로 동작하는지 어느 정도 감이 잡혔을 것입니다.

이제 다음 단계는 문법 비교가 아니라 실제 실행입니다.

다음 가이드에서는 환경 설정과 첫 실행을 통해, 지금까지 설명한 모델 차이가 실제 개발 워크플로에서 어떻게 드러나는지 확인해보겠습니다.

핵심 정리

이 글의 핵심은 다음과 같습니다.

Compact은 문법만 보면 익숙할 수 있지만, 실행 모델은 전혀 다릅니다.
Midnight에서는 사용자가 로컬에서 프라이빗 연산을 수행하고 ZK proof를 생성합니다.
네트워크는 전체 로직을 재실행하지 않고, 증명을 검증한 뒤 transcript에 담긴 공개 상태 전이만 실행합니다.
Midnight은 UTXO 기반 자산 메커니즘과 account 스타일의 스마트 컨트랙트 동작을 함께 쓰는 하이브리드 구조입니다.
ledger, circuit, witness의 구분은 Compact을 이해하는 핵심입니다.
disclose()는 사소한 문법 요소가 아니라, 공개가 자동이 아니라는 Midnight의 원칙을 코드로 드러내는 장치입니다.

Midnight MCP - AI-assisted development for Compact smart contracts

Idris Olubisi💡 — Tue, 24 Feb 2026 13:03:27 +0000

AI coding assistants like Claude, GitHub Copilot, and Cursor have transformed how developers write code. But they have a fundamental limitation: they only know what was in their training data.

Compact, Midnight's smart contract language, isn't in that training data. When you ask an AI assistant to write a Compact contract, it hallucinates. It invents syntax that doesn't exist, references functions that were never defined, and produces code that fails at compile time.

Midnight MCP solves this problem.

What is MCP?

The Model Context Protocol (MCP) is an open standard that allows AI assistants to access external tools and data sources. Instead of relying solely on training data, an AI assistant with MCP can query live documentation, search codebases, and call APIs.

Midnight MCP is an MCP server purpose-built for Midnight development. It gives AI assistants:

Indexed knowledge of 102 Midnight repositories
Real compiler validation before showing you code
Semantic search across documentation and examples
Version-aware syntax references for Compact

When you ask Claude to write a Compact contract, it queries Midnight MCP for the correct syntax, generates the code, validates it against the real compiler, and only shows you working code.

The problem with AI-generated Compact code

Consider this prompt:

"Write a simple counter contract in Compact"

Without Midnight MCP, an AI assistant might generate:

contract Counter {
    state count: Int = 0;

    function increment(): Void {
        count = count + 1;
    }
}

This looks plausible. It's also completely wrong:

Compact uses ledger for state, not state.
There is no Int type in Compact. It uses Uint<32>, Field, and other specific types.
Void doesn't exist. Compact uses [] for the unit type.
State mutations require witness functions, not direct assignment.

The AI hallucinated a language that resembles Solidity but isn't Compact. A developer unfamiliar with Compact might spend hours debugging code that was never valid.

Install Midnight MCP

Midnight MCP requires no API keys and installs in under 60 seconds. Add the appropriate configuration to your AI assistant based on the tool you use.

Claude Desktop

On macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json. Add the following configuration to enable Midnight MCP:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

Cursor

Create or edit .cursor/mcp.json in your project root. You can also configure it globally at ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows. Add the following configuration:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

VS Code with GitHub Copilot

Create or edit .vscode/mcp.json in your project. Add the following configuration to connect Copilot to Midnight MCP:

{
  "servers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

After adding the configuration, restart your AI assistant. You now have access to 29 Midnight-specific tools.

How Midnight MCP works

Midnight MCP operates as a local server that connects your AI assistant to Midnight's ecosystem.

When you ask for a Compact contract:

The AI assistant calls midnight-get-latest-syntax to retrieve current Compact syntax.
It generates code using the correct patterns.
It calls midnight-compile-contract to validate against the real compiler.
If compilation fails, it reads the error, fixes the code, and retries.
You receive verified, working code.

This compile-validate-fix loop happens automatically. You never see the broken intermediate versions.

Real compiler integration

Most code-generation tools rely on pattern matching and hope. Midnight MCP validates code against the actual Compact compiler hosted.

The compiler catches errors that static analysis cannot, including:

Type mismatches: Using Field where Uint<64> is expected
Sealed field violations: Attempting to access sealed state incorrectly
Disclose rule errors: Missing or malformed privacy annotations
Unbound identifiers: References to undefined variables or types

When the compiler returns an error, the response includes the exact line number and column:

success: false
message: "Line 12:8 - unbound identifier 'totalSupply'"
errorDetails:
  line: 12
  column: 8
  errorType: error

The AI assistant uses this information to fix the code and try again.

Graceful fallback

If the hosted compiler is unavailable, Midnight MCP falls back to static analysis. The response indicates which validation method was used:

validationType: "compiler"           # Real compiler validation
validationType: "static-analysis-fallback"  # Compiler unavailable

You always receive validation. The tool never fails silently.

Semantic search across 102 repositories

Today, Midnight MCP indexes every non-archived repository in the Midnight ecosystem:

All 88 repositories from midnightntwrk.
14 community and partner repositories, including OpenZeppelin contracts and hackathon winners.

The search is semantic, not keyword-based. For example, a prompt like "find code that handles shielded transactions" returns relevant results even if those exact words don't appear in the code.

Prompt: "How do I implement a token with transfer limits?"

midnight-search-compact returns:
- Token contract examples from midnight-examples
- Rate limiting patterns from community repos
- Relevant documentation sections

29+ tools for Midnight development

Midnight MCP provides 29 tools organized by function.

Search tools

Use these tools to find code, documentation, and examples across the Midnight ecosystem.

Tool	Purpose
`midnight-search-compact`	Search Compact language code across indexed repos
`midnight-search-docs`	Search official Midnight documentation
`midnight-search-typescript`	Search TypeScript SDK implementations
`midnight-fetch-docs`	Fetch live documentation from docs.midnight.network

Analysis tools

Use these tools to validate, analyze, and review Compact contracts.

Tool	Purpose
`midnight-compile-contract`	Validate code against the real Compact compiler
`midnight-analyze-contract`	Run 15 static security checks
`midnight-review-contract`	AI-powered security review
`midnight-extract-contract-structure`	Parse contract structure and exports

Generation tools

Use these tools to create new contracts and documentation.

Tool	Purpose
`midnight-generate-contract`	Generate contracts from natural language descriptions
`midnight-document-contract`	Generate documentation in Markdown or JSDoc format

Repository tools

Use these tools to access files and syntax references from Midnight repositories.

Tool	Purpose
`midnight-get-file`	Retrieve files from any indexed Midnight repository
`midnight-get-file-at-version`	Get file content at a specific version
`midnight-compare-syntax`	Compare syntax between Compact versions
`midnight-get-latest-syntax`	Current Compact syntax reference
`midnight-get-repo-context`	Everything needed to start coding (compound tool)
`midnight-list-examples`	List available example contracts

Version management tools

Use these tools to manage upgrades and track changes between Compact versions.

Tool	Purpose
`midnight-upgrade-check`	Full upgrade analysis (compound tool)
`midnight-check-breaking-changes`	Identify breaking changes between versions
`midnight-get-migration-guide`	Step-by-step migration instructions

Resources and prompts

Beyond tools, Midnight MCP provides nine built-in resources and five interactive prompts.

Resources are always-available references that provide quick access to syntax and examples:

midnight://syntax/latest      Current Compact syntax
midnight://examples/counter   Counter contract example
midnight://examples/token     Token contract example
midnight://docs/compact       Compact language reference

Prompts are templates for common tasks that guide you through specific workflows:

create-compact-contract      Start a new contract
debug-compact-error          Fix compilation errors
security-review              Full security audit
compare-compact-versions     Migration assistance

Architecture

Midnight MCP is built for reliability:

Token efficiency: Outputs YAML by default (20-30% fewer tokens than JSON)
Compound tools: Single calls that combine multiple operations
Graceful degradation: Falls back to cached data when services are unavailable
Progress notifications: Real-time updates during long operations

The codebase is fully tested with 206 tests across 10 test suites.

What's next

Midnight MCP is open source and actively developed. The roadmap includes:

Full ZK circuit output parsing from compiler results.
Contract deployment directly from AI chat.
TypeScript SDK integration for automatic prover code generation.
Local devnet interaction for querying balances and submitting transactions.

Learn more

Explore the source code and contribute:

→ GitHub repository

→ npm package

→ API documentation

Midnight MCP is a community project. Contributions, issues, and feature requests are welcome.

Introduction to the FungibleToken contract on Midnight

Claude Barde — Thu, 11 Sep 2025 14:35:44 +0000

Introduction to the FungibleToken contract on Midnight

Midnight is a privacy-first blockchain designed to bring privacy to decentralized applications. It achieves this through zero-knowledge proofs, programmable data protection, and developer-friendly tools like Compact, a TypeScript-based DSL (Domain-Specific Language) for writing privacy-aware smart contracts.

OpenZeppelin is renowned in the Ethereum ecosystem for its battle-tested smart contract libraries, which have secured trillions in on-chain value. Recently, OpenZeppelin partnered with Midnight to bring comparable tooling to the Compact ecosystem, adapting familiar standards like ERC-20 into privacy-preserving variants.

In the Ethereum world, the ERC-20 standard defines a fungible token with public ledger functions like balanceOf, transfer, approve, etc. It exposes transaction data transparently and lacks built-in privacy. The FungibleToken contract on Midnight draws inspiration from this, but operates within Midnight’s zero-knowledge, selective-disclosure framework.

Fungible tokens are a cornerstone of the blockchain ecosystem, representing digital assets that are interchangeable – much like traditional currency. On various blockchains, these tokens power a wide array of applications, from facilitating seamless transactions and enabling decentralized finance (DeFi) protocols to representing ownership in digital communities and driving the mechanics of in-game economies.

Unlike unique non-fungible tokens (NFTs), the value of one fungible token is identical to another of the same type, making them ideal for use cases requiring divisibility and ease of exchange. Their widespread adoption underscores their importance in building liquid and interconnected digital economies.

In this article, you'll learn about the core features of the contract, including how it manages ledger state variables, its key entry points and circuits for operations like minting, burning, and transferring tokens, and the essential safety and utility functions provided by the Utils and Initializable modules.

By understanding how these components fit together, you’ll gain insight into how the FungibleToken contract balances fungibility, usability, and privacy, providing an essential building block for privacy-preserving DeFi, identity, and tokenized assets on Midnight.

Features of the FungibleToken Contract

The FungibleToken contract on Midnight utilizes ledger state variables to keep track of balances, allowances, total supply, name, symbol, and decimals. Its functionality is exposed through "circuits" (entry points) like Mint, Burn, Transfer, Approve, TransferFrom, and Initialize, all of which enforce specific zero-knowledge validated transitions and maintain the integrity of the token's state.

1. Ledger State Variables

In Compact, the contract defines a structured state storing token balances and allowances—similar to ERC-20. The _balances map keeps track of the users’ token balances and is updated when a transfer occurs. The _allowances map keeps track of the permission given to specific users to spend tokens on behalf of another user:

export ledger _balances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>;
export ledger _allowances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>>;

These values live in the contract's ledger and are updated through transactions sent to the contract.

There are other values in the ledger that are set when the contract is deployed:

export ledger _totalSupply: Uint<128>;
export sealed ledger _name: Opaque<"string">;
export sealed ledger _symbol: Opaque<"string">;
export sealed ledger _decimals: Uint<8>;

These values provide different information about the token managed by the contract, its total supply, its name, its symbol, and its decimal (for display).

2. Entry Points and Circuits

In Compact, entry points are defined as circuits (akin to Solidity functions), each modelling a zero-knowledge validated transition. The difference between a circuit entry point and a circuit is that the entry point is callable via a transaction, while the non-entry point circuit is internal. Core circuits include:

Mint / Burn (to mint new tokens or burn existing tokens).
Transfer: to move tokens between addresses.
Approve, TransferFrom: standard ERC-20-style delegation mechanisms.
Initialize: via the Initializable module for contract setup.

Each circuit enforces necessary constraints — for example, ensuring sufficient balance, managing allowance decrements, and preserving total supply.

In the next step of the contract lifecycle, the different metadata stored in the ledger of the contract are safely initialized.

Initialization & metadata

The following circuits define the essential setup and retrieval logic for the fungible token metadata and users’ balances, enforcing correct initialization.

initialize(name_, symbol_, decimals_)

One-time setup. Calls Initializable_initialize(), then stores the (disclosed) name, symbol, and decimals. Every other public circuit asserts that the contract is initialized first.
name() / symbol() / decimals() / totalSupply()

Simple getters that first assert initialized, then return the sealed (read only) ledger values.
balanceOf(account)

Safe map lookup that returns 0 if the account isn’t present (to prevent contract failure if the key is absent).

The transfer family

The FungibleToken contract's transfer circuits manage token movement. Key circuits include: transfer for safe user-initiated transfers, _unsafeTransfer for internal token movement, _transfer for administrative transfers, _unsafeUncheckedTransfer for low-level token movement, and _update as the central accounting function for all token operations.

These are split into safe and unsafe variants because sending to contract addresses is currently disallowed (until contract-to-contract interactions are supported).

“Safe” circuits enforce that policy; “unsafe” ones let you bypass it—explicitly marked as dangerous in comments.

transfer(to, value) → Boolean

Safe user-initiated transfer: rejects if to is a ContractAddress. Internally, it just forwards to the unsafe variant after the check.
_unsafeTransfer(to, value) → Boolean

Owner is the caller (left(ownPublicKey())). Moves value using the unchecked internal mover, then returns true.
_transfer(from, to, value) → []

Admin/extension hook that moves tokens from an arbitrary from (not necessarily the caller). Still enforces the “no contracts as to” rule and then uses the same mover underneath.
_unsafeUncheckedTransfer(from, to, value) → []

The low-level mover checks that neither side is the zero/burn address and then delegates the actual accounting to _update.
_update(from, to, value) → []

Central accounting function used by all mint/burn/transfer paths. It’s an internal circuit; it cannot be called via a transaction.
- If from is zero, the mint circuit is called, it asserts no uint128 overflow, and increases _totalSupply.
- Else, it deducts from from balance (or reverts on insufficient funds).
- If to is zero, the burn circuit is called, and it decreases _totalSupply.
- Else, it adds to to balance. This single function guarantees the invariants for every movement of value.

The "transfer family" circuits ensure secure token movement, with "safe" variants disallowing transfers to contract addresses and "unsafe" variants providing lower-level control.

This leads us to explore how allowances function, enabling delegated token spending.

Allowances (approve / spend / transferFrom)

This section details the allowance mechanisms within the FungibleToken contract, which enable users to delegate spending permissions to other addresses. These circuits facilitate secure, approved transfers on behalf of an owner without directly exposing their private keys.

allowance(owner, spender)

Read the nested _allowances map, returning 0 when keys are missing (no revert).
approve(spender, value) → Boolean

The owner is the caller. Forwards to _approve(owner, spender, value) and returns true.
transferFrom(from, to, value) → Boolean

Safe delegated transfer: enforces the “no contract receiver” rule, then defers to _unsafeTransferFrom.
_unsafeTransferFrom(from, to, value) → Boolean

The spender is the caller. First spends allowance via _spendAllowance(from, spender, value), then moves value using _unsafeUncheckedTransfer. Returns true.
_approve(owner, spender, value) → []

It ensures that both the owner and the spender are valid, creates the owner’s entry in the map if needed, and then writes the allowance. (This mirrors OZ’s ERC-20 pattern of public approve() → internal _approve().)
_spendAllowance(owner, spender, value) → []

It deducts from the allowance unless it’s “infinite.” The implementation treats MAX_UINT128 as infinite: if currentAllowance == MAX, it doesn’t decrement; otherwise, it asserts currentAllowance ≥ value and writes back currentAllowance - value.

This is important because it supports “no-friction approvals” by letting apps set MAX once.

So, we just covered how allowances let people delegate token spending—basically, giving others permission to move their tokens. Up next, we'll dive into how we create and delete tokens in the contract.

Minting and burning

Here's how the FungibleToken contract handles making and destroying tokens. We'll dive into the _mint and _burn functions, showing what they do and how they link up with the main accounting system.

_mint(account, value) (safe) → []

It forbids minting to a contract address (same contract-to-contract restriction), then forwards to _unsafeMint.
_unsafeMint(account, value) → []

It validates the receiver’s address, then calls _update(burnAddress(), account, value)—i.e., mint is modelled as a transfer from the burn/zero address.
_burn(account, value) → []

It validates the sender’s address, then calls _update(account, burnAddress(), value)—i.e., burn is a transfer to the burn/zero address.

Note: The actual notion of “zero/burn” address is standardized in the Utils module; you can also see helpers like Utils_isKeyOrAddressZero and Utils_isContractAddress.

Because mint and burn also route through _update, total supply is adjusted in exactly one place, and the same safety checks apply across all flows (including the uint128 overflow check on mint).

The mint and burn circuits, by using the _update function, make sure the total supply adjustments are always consistent and that all token flows get the same safety checks.

Now, let's dive into the extra safety and utility stuff that the Utils and Initializable modules bring to the table.

Safety & utility glue (from `Utils` and `Initializable`)

This section explores how the Utils and Initializable modules provide essential safeguards and helpful functionalities. These components are vital for ensuring the contract's integrity and enabling secure, well-managed operations.

Initialization guards: The Initializable_initialize and Initializable_assertInitialized functions serve as crucial initialization guards within the Initializable contract. These safeguards ensure that a contract's state is properly set up only once and that subsequent operations only proceed if the contract has been correctly initialized. Every circuit that interacts with or modifies the contract's state is designed to invoke the assert function, reinforcing the integrity of the initialization process.
Address helpers:
- Utils_isContractAddress(either) distinguishes user keys from contract addresses.
- Utils_isKeyOrAddressZero(either) detects the zero/burn address used in _update, _unsafeUncheckedTransfer, etc. These support the temporary “no contract receiver” policy and zero-address checks.

The Utils and Initializable modules provide crucial safety and utility functions, ensuring the contract's proper setup and secure operation. Now, let's look at how all these different parts of the FungibleToken contract work together.

How the pieces fit together

This part shows how everything in the FungibleToken contract is hooked up. Whether it's you sending tokens, someone else doing it for you, or tokens being created or destroyed, it all funnels through a few key functions and ultimately lands in the main _update function to keep track of everything.

User transfer:

transfer → (safe check) → _unsafeTransfer → _unsafeUncheckedTransfer → _update (balances/supply)
Delegated transfer:

transferFrom → (safe check) → _unsafeTransferFrom → _spendAllowance → _unsafeUncheckedTransfer → _update
Mint/Burn:

_mint/_unsafeMint or _burn → _update (with zero/burn address on one side)

This section illustrates how various token operations, from user transfers to minting and burning, ultimately funnel through the central _update function for consistent accounting. Now, let's summarize the key takeaways of the FungibleToken contract on Midnight.

Conclusion

The FungibleToken Compact contract on Midnight is a privacy-aware reimagining of the ERC-20 standard. It maintains the familiar token interfaces—balances, transfers, approvals—but encodes them as ZK-validated circuits within Compact, enabling private, verifiable execution. The contract’s state and logic are shielded by design, exposing only proofs rather than raw data to the blockchain.

The ERC-20 standard revolutionized the crypto landscape by providing a common framework for creating and managing digital assets, fostering interoperability, and accelerating the growth of decentralized applications. For Midnight, an ERC-20-based token is crucial as it leverages this established standard while integrating ZK-privacy, offering a familiar yet enhanced experience for developers and users seeking both functionality and confidentiality.

This model contrasts sharply with ERC-20 on Ethereum, where all token movements and balances are fully transparent. Here, Midnight allows selective disclosure: users and applications choose what to reveal. The FungibleToken contract thus balances fungibility, usability, and privacy—providing an essential building block for privacy-preserving DeFi, identity, and tokenized assets on Midnight.

Links

Delve deeper into the code, contracts, and comprehensive documentation to enhance your understanding and development skills. These resources are invaluable for building robust and innovative solutions.

FungibleToken contract: FungibleToken.compact on Github
OpenZeppelin documentation: docs.openzeppelin.com
ERC20 standard: ethereum.org
Midnight docs: Midnight Developer Documentation
Do you have any questions?: Midnight Forum

Learning Web3 from the Ground Up: Understanding Ethereum

Samantha Holstine — Fri, 25 Jul 2025 15:09:00 +0000

This past week, I started the SheFi course— a program designed to help women dive deeper into Web3 and decentralized finance. One of the first topics it covered was Ethereum: what it is, why it matters, and how it fits into the broader decentralized ecosystem.

To build on what I learned there, I read two excellent overviews: “A Beginner’s Guide to Ethereum” from Coinbase and “Getting Up to Speed on Ethereum” by Matt. Both helped frame Ethereum not just as a cryptocurrency, but as a foundational platform for Web3 applications. Here’s what stood out and why Ethereum remains vital in a rapidly evolving cryptocurrency ecosystem.

Ethereum in a Nutshell

Ethereum is a decentralized computing platform. Think of it like a global computer that anyone can access, but no single person or organization controls it. This is possible because Ethereum is powered by a blockchain—a network of nodes around the world that maintain and validate a shared record of activity. What makes Ethereum special is that it doesn’t just store transactions; it can also run applications. These apps are powered by smart contracts, which are programs deployed to the blockchain that execute exactly as written.

The Ethereum network is designed to be open, programmable, and permissionless. That means anyone can build on it, and no one needs approval to use it. This structure has enabled Ethereum to become the foundation for a wide range of decentralized applications (dApps), including financial tools such as lending protocols and stablecoins, as well as NFT marketplaces and decentralized identity systems.

Why Ethereum Matters

Ethereum matters because it transforms the internet from a read-write platform into a read-write-execute environment. That is, it enables not just the sharing of information, but also the execution of logic—without relying on centralized intermediaries. This shift opens the door to creating systems that are more transparent, resilient, and accessible.

One of Ethereum’s most significant breakthroughs is that it allows developers to write and deploy their own logic onto the network through smart contracts. These contracts can define rules, manage value, and interact with other contracts—all while being trustless and tamper-proof. Once deployed, smart contracts can’t be changed or censored, which means users can interact with them without worrying about backend changes or manipulation.

Ether: The Fuel of the Ethereum Network

Ether (ETH) is the native currency of Ethereum. While many people think of ETH primarily as a cryptocurrency—something you can buy, sell, or hold—its most important role as the fuel for computation. Every operation on the Ethereum network costs gas, and ETH is what you use to pay for it. This is a crucial aspect of Ethereum’s security and incentive structure, ensuring that resources are utilized responsibly and the network remains resilient to spam.

When you send a transaction, deploy a smart contract, or interact with a dApp, you’re paying for the network to process that request. The more complex the operation, the more gas it consumes. Gas prices fluctuate based on network demand, and users can choose how much to pay to incentivize faster confirmation. This dynamic creates a market for block space, encouraging developers to write more efficient code.

The Power of Smart Contracts

Smart contracts are at the heart of what makes Ethereum powerful. These are self-executing programs that live on the blockchain and enforce rules automatically. You don’t need to trust a company or a person; you can trust the code. Smart contracts enable a wide range of use cases, including lending platforms like Aave, decentralized exchanges like Uniswap, and even games like Axie Infinity.

Once a smart contract is deployed, it’s public and verifiable. Anyone can inspect the code, interact with it, and build on top of it. This openness fosters a culture of composability—developers can plug into existing contracts, remix them, or build entirely new systems that work together. This is why Ethereum is often referred to as a “LEGO set for financial and digital tools.”

Ethereum Today and Tomorrow

Ethereum has come a long way since its launch in 2015. It’s no longer just a niche experiment; it’s the most widely used smart contract platform in the world. However, with that growth has come challenges. Network congestion and high gas fees have made it difficult for some users to interact with dApps affordably. To address these issues, Ethereum has undergone significant upgrades, most notably the transition from proof-of-work to proof-of-stake, known as “The Merge.”

Proof-of-stake is a consensus mechanism that allows Ethereum to secure the network using validators who lock up ETH rather than relying on energy-intensive mining. This shift has dramatically reduced Ethereum’s energy usage and paved the way for future scaling efforts, such as sharding and rollups. Rollups are a technique for batching many transactions into a single proof, which can then be submitted to the Ethereum mainnet. This helps scale the network without sacrificing security or decentralization.

The Ethereum ecosystem is also growing through layer 2 networks, which are built on top of Ethereum and handle transactions off-chain while still relying on Ethereum for settlement and security. Projects like Arbitrum, Optimism, and zkSync are working to make Ethereum faster and cheaper for everyday users.

How Ethereum Connects with Midnight

While Ethereum serves as the foundational smart contract platform for much of Web3, Midnight is designed to complement and extend its capabilities—especially in terms of privacy.

In practical terms, this means that developers who are comfortable with the Ethereum ecosystem —its wallets, development environments, and smart contract models—can interact with Midnight using similar patterns. For example, Midnight supports a Solidity-like programming approach through its Compact smart contract language, which compiles to verifiable circuits that enforce privacy constraints. This allows developers to build private versions of applications, such as voting systems, token transfers, and identity verification, that would typically be public on the Ethereum blockchain.

Ethereum offers programmability and decentralization, but by default, all on-chain transactions are transparent. Midnight fills in the missing privacy layer. You could imagine a workflow where public assets and smart contracts live on Ethereum, but sensitive data or confidential logic is handled by Midnight—bridging the two networks for richer, privacy-preserving applications.

Together, Ethereum and Midnight can be seen as complementary parts of a broader decentralized stack: Ethereum provides openness and composability, while Midnight adds selective disclosure and private computation, enabling developers to build secure and compliant applications in ways that Ethereum alone can’t.

Conclusion

Ethereum isn’t just a cryptocurrency—it’s a platform for building a new kind of internet. By combining programmable logic with decentralized infrastructure, Ethereum enables applications that are open, transparent, and user-owned. It’s the foundation of decentralized finance (DeFi), non-fungible tokens (NFTs), and numerous experiments in online interaction.

For me, starting with SheFi and reading through these resources helped ground my understanding of what Ethereum is and why it matters. It’s not just about buying coins—it’s about reshaping how we think about trust, ownership, and value in a digital world.

I’ll be back next week as I continue diving into the core building blocks of Web3. If you’re just starting out too, I highly recommend giving Coinbase’s primer and Matt’s breakdown a read.

Learning Web3 From the Ground Up: What Are Zero-Knowledge Proofs (ZKPs)?

Samantha Holstine — Mon, 21 Jul 2025 17:20:09 +0000

As I continue exploring the foundations of Web3, last week I focused on Smart Contracts and Compact—Midnight’s purpose-built smart contract language. Together, these two elements form the foundation for defining and enforcing logic in privacy-preserving applications.

But logic alone isn’t enough in a decentralized system, especially when privacy is a priority. That’s where zero-knowledge proofs (ZKPs) come in.

ZKPs enable the verification of a statement's truth without revealing the underlying justification. They let applications enforce smart contract rules while keeping sensitive data private—an essential capability for building systems that balance trust, utility, and confidentiality.

In this post, I’ll break down what zero-knowledge proofs are, how they work, and how Midnight uses them to support privacy, compliance, and secure dApp development.

What Are Zero-Knowledge Proofs?

A zero-knowledge proof allows someone (the prover) to prove to another party (the verifier) that a specific statement is true, without revealing any additional information beyond the fact itself.

Think of it like this: instead of handing over your complete ID to prove you're over 18, you could use a ZKP to prove you're above the age threshold, without disclosing your exact birthday, name, or ID number.

This cryptographic technique is built on three foundational properties:

Completeness: If the statement is true, the prover can convince the verifier that it is true.
Soundness: If the statement is false, no dishonest prover can convince the verifier that it is true.
Zero-knowledge: The verifier learns nothing beyond the truth of the statement.

Interactive vs. Non-Interactive Proofs

Early ZKPs required a back-and-forth exchange between prover and verifier—these are called interactive proofs. But in decentralized systems, interaction isn’t always feasible. That’s where non-interactive proofs come in.

Non-interactive ZKPs let a prover generate a single proof that anyone can verify at any time, with no additional input. Protocols like zk-SNARKs and zk-STARKs make this possible, often using techniques like the Fiat–Shamir heuristic to simulate interaction using cryptographic hashes.

This makes non-interactive ZKPs ideal for blockchains, where proofs need to be public, reusable, and verifiable by anyone.

Types of Zero-Knowledge Proof Systems

Different ZKP systems come with different tradeoffs in terms of size, speed, and trust requirements:

Groth16 (zk-SNARK): Very small proofs, fast verification, but requires a trusted setup per circuit.
Plonk (zk-SNARK): Slightly larger proofs, slower verification, but only needs a one-time universal setup.
Bulletproofs: No trusted setup, but proof size grows with complexity.
zk-STARKs: Transparent (no trusted setup), post-quantum secure, but with large proof sizes.

Midnight utilizes a Plonk-derived system called Halo 2, which supports recursive proofs and eliminates trusted setup in specific configurations, making it an ideal choice for privacy-preserving dApps that require both flexibility and scalability.

How Do ZKPs Work?

The idea behind zero-knowledge proofs might seem almost magical: one party (the prover) can prove to another (the verifier) that a statement is true, without revealing the why. But this is no sleight of hand—it’s grounded in rigorous cryptography and clever use of mathematical structures.

At the heart of a ZKP is a “statement” that the prover wants to validate without revealing the underlying secret. That statement gets encoded into a circuit, which represents the logical rules or constraints that need to be satisfied. The prover then uses a special cryptographic key, known as the proving key, along with the secret input (called the witness), to generate a succinct proof. The verifier can then check this proof using a verifying key, confirming the rules were followed, without ever seeing the private input.

This process makes ZKPs ideal for privacy-preserving smart contracts. In traditional systems, all data must be made public to verify that an action is legitimate. But with ZKPs, we can shift the trust model: rather than inspecting the data itself, the verifier checks a cryptographic proof that the data complies with the rules.

Midnight takes this further by embedding ZKPs directly into the structure and execution of smart contracts. In Midnight, the verification key of a compiled Compact smart contract becomes the identity of that contract on-chain. When users interact with it, they’re not just calling a function—they’re submitting proof that they've complied with the logic defined by that contract, without revealing their inputs.

Here's a high-level flow of how this works:

Setup: A circuit is created. A proving key and a verifying key are generated.
Proof Generation: The prover uses their secret (a witness) and the proving key to generate a cryptographic proof.
Verification: The verifier uses the verifying key and the proof to confirm the statement is true, without learning anything else.

This process ensures that the smart contract logic is executed exactly as intended, without exposing the underlying data.

Midnight’s Approach to ZKPs

Midnight utilizes zero-knowledge proofs not only for theoretical privacy but also to enable real-world compliance and usability. Let’s walk through a few key elements of how ZKPs show up on the Midnight network:

Confidential Transactions

Users can transfer assets on Midnight without revealing the sender, receiver, or amount. ZKPs are used to prove that a transaction is valid (i.e., no double spending, balances add up) without revealing specific details. This ensures both privacy and integrity.

Selective Disclosure and Compliance

Midnight supports “shielded” and “unshielded” data modes. You can keep your transaction data private by default, but also selectively disclose specific information (via a ZKP or viewing key) to a regulator, auditor, or another authorized party.

This enables use cases like “prove I’m a citizen of Country X” or “prove I’m not sanctioned” without revealing your complete identity or wallet history.

For more information about selective disclosure, read my overview here!

Decentralized Identity

ZKPs are key to proving facts about identity without revealing full credentials. Midnight supports workflows like proving KYC status (“A trusted provider has verified me”) using a proof, not a document.

This allows users to interact with services that require identity checks—such as exchanges or marketplaces—without exposing sensitive personal data.

Scalability via Recursive Proofs

ZKPs also compress large computations into tiny proofs. That makes them ideal for batching transactions or reducing blockchain bloat. Midnight’s use of recursive proofs allows smart contracts and transactions to scale more efficiently than traditional blockchains.

Real-World Use Cases on Midnight

Some examples of ZKP-powered applications on Midnight are:

Voting: Prove you’re eligible to vote and that your vote was counted, without revealing your identity or your vote.
Whistleblowing: Submit a report anonymously, proving only that you’re authorized (e.g., an employee).
Private Asset Swaps: Use Midnight’s Zswap to exchange tokens confidentially without revealing terms or participants.
KYC Onboarding: Prove compliance status to a platform or dApp without exposing documents.
Tokenized Real-World Assets: Keep ownership private while maintaining auditable transfer records. These use cases show how ZKPs on Midnight turn privacy into a practical feature, not just a theoretical promise. They lay the groundwork for a future where developers can build secure, compliant, and data-protecting applications by default.

Conclusion

Zero-knowledge proofs bring trust to trustless systems. They make it possible to prove something is true—like compliance with laws, asset ownership, or user eligibility—without revealing any sensitive details.

Midnight makes ZKPs more than theoretical. They’re deeply integrated into its smart contract architecture, transaction model, and developer tooling. Paired with the Compact language (covered in last week’s post), they create a robust foundation for building privacy-first decentralized applications.

If you’re interested in learning more, check out:

And if you’ve come across excellent ZKP explanations or tutorials, I’d love to hear about them—please share your favorites!

See you next week as I continue to unpack the core ideas that power privacy in Web3!

Learning Web3 from the Ground Up: Smart Contracts and the Compact Language

Samantha Holstine — Fri, 20 Jun 2025 16:39:59 +0000

As I continue my journey through the world of Web3, I’ve been digging into the building blocks that make privacy-first platforms like Midnight possible (you can catch up on previous posts in the Midnight Dev Diaries!). This week, I focused on two foundational pieces that go hand in hand: smart contracts on Midnight and the Compact language that powers them.

Smart contracts aren’t new to blockchain, but Midnight’s approach is unique. Instead of executing code directly on-chain, Midnight uses smart contracts to define rules that are enforced off-chain through zero-knowledge proofs. At the center of this system is Compact—a purpose-built language designed to make writing these privacy-preserving contracts both secure and practical.

To better understand how this works in practice, I also worked through Module 2 of the Midnight Developer Academy, which covers key concepts such as contract structure, circuit types, and the relationship between the contract and the external logic that executes it.

In this post, I’ll break down what makes smart contracts on Midnight different, how Compact is structured, and how the two work together to enable provable logic without exposing sensitive data.

What Is a Smart Contract on Midnight?

At a high level, a smart contract is an autonomous program stored on the blockchain. It defines rules for interaction, checks that those rules are met, and records results—all without needing a trusted third party to enforce them.

But Midnight isn’t just any blockchain. It’s a privacy-first platform built with compliance in mind, and that means its smart contracts need to do more than just run logic. They need to protect private data, enable selective disclosure, and uphold security and trust even in adversarial environments.

That’s where Compact comes in—a custom domain-specific language explicitly designed to write smart contracts on Midnight.

Instead of executing logic directly on-chain like many traditional smart contracts, Compact contracts define the logic to be proven, not the execution environment itself. The contract encodes the rules that must be followed, which are then used as the foundation for a zero-knowledge proof. The actual execution—like processing a transaction, generating a credential, or submitting a vote—happens externally, often in a DApp, backend service, or API.

That external system runs the necessary logic and proves it followed the contract’s rules by generating a cryptographic proof. The blockchain doesn’t need to know the details—it just verifies that the proof is valid. This separation is what makes Midnight’s model both scalable and privacy-preserving.

In other words: the contract sets the rules, your app runs the logic, and the blockchain verifies the outcome, without ever seeing the sensitive inputs.

What Is Compact?

Compact is a statically typed, privacy-focused smart contract language tailored to the unique goals of the Midnight network. If you've worked with JavaScript or TypeScript before, you'll find Compact refreshingly approachable. It’s a domain-specific language (DSL) designed to define zero-knowledge proof logic using statically typed circuits that map to off-chain computations. But don’t let the simple syntax fool you—Compact is engineered for privacy-preserving computation using zero-knowledge proofs (ZKPs) under the hood. (For a more technical deep dive into compact, check out part 1 of Kevin Millikin's Compact Deep Dive here!)

A Compact contract is made up of three core components:

Ledger: The public, on-chain state of the contract.
Circuits: Off-chain logic that can manipulate data, produce proofs, and interact with the ledger.
Witnesses: Privately held data, only known to the entity executing the contract.

Compact also supports explicit disclosure, meaning developers can define exactly what data gets revealed (and to whom). This provides fine-grained control over what is visible on-chain and what remains private, essential for use cases such as private asset transfers, age-gated access, or confidential voting.

Circuits and Privacy

One of the most essential takeaways from Module 2 of the Midnight Developer Academy is how circuits work. In Compact, circuits are the functions that users or systems can call to trigger actions. But unlike Web2 APIs or EVM contract functions, these circuits don’t execute logic directly on the blockchain. Instead, they run off-chain and generate zero-knowledge proofs that the logic was followed.

In practice, that means:

The contract logic is public.
The data used during execution is private.
The outcome of the logic (e.g., “the rules were followed”) is publicly verifiable using a proof.

This is where Midnight’s model shows its strength—users can prove they followed the rules without revealing the exact data that triggered the result. Think “I proved I’m eligible to vote” without revealing who I am or what I voted for.

From Theory to Practice

In traditional smart contract platforms, everything you do is public by default: data, logic, inputs, outputs. That’s useful for transparency, but it's not always practical, especially for sensitive use cases like health data, financial records, or identity verification.

Midnight flips that default. Privacy is built in, and developers opt into disclosure only when it’s needed.

Some examples of what you might build with Compact on Midnight:

A voting system where only the outcome is public.
An access control system that verifies user attributes without revealing identities.
A token transfer app that hides amounts or senders while still allowing public verification.

Conclusion

Smart contracts are the foundation of decentralized applications—but at Midnight, they’re built for a privacy-first future. Instead of executing every piece of logic on-chain, Midnight separates the contract's logic from its execution. With Compact, developers define the rules of a zero-knowledge proof system, enabling applications to prove facts without exposing sensitive data. It’s a practical shift toward secure, scalable, and user-protective Web3 design.

At Midnight, this isn’t just a theoretical improvement—it’s core to how the platform operates. Compact smart contracts let developers write verifiable, auditable logic while keeping inputs and execution off-chain. Combined with ZKPs and shielded transactions, they create an infrastructure that supports real-world use cases without compromising on privacy or decentralization.

If you're learning how to build smart contracts in Web3—or just curious how these pieces fit together—I highly recommend diving into Module 2 of the Midnight Developer Academy and reviewing the Compact Language Reference. These resources break down the concepts step by step and show how Midnight’s architecture turns advanced cryptography into practical developer tools.

I’ll be back next week with more insights as I continue to unpack the pieces that make privacy-first systems work in the decentralized world.

Learning Web3 From the Ground Up: Understanding Selective Disclosure

Samantha Holstine — Fri, 13 Jun 2025 20:44:47 +0000

As I delve deeper into the world of Web3, I've been working my way through foundational concepts to have a better understanding of the industry (check out my last five posts on the Midnight Dev Diaries!). This week, I dove into one of the most practical and privacy-focused ideas I’ve encountered so far: selective disclosure.

Selective disclosure is more than just a technical feature—it’s the working expression of a broader idea known as rational privacy. It allows individuals to prove or reveal only what’s necessary in a given interaction, keeping everything else private. In an ecosystem where trust must be earned without a central authority, this ability to protect personal data while still meeting legal or operational requirements is critical.

This post examines how selective disclosure operates, its benefits, and how platforms like Midnight are implementing it through privacy-first smart contracts.

What Is Selective Disclosure?

In the Web3 world, privacy doesn’t mean keeping everything secret—it means sharing only what’s necessary. Selective disclosure is a privacy-preserving technique that enables individuals to disclose specific information for a given interaction while keeping all other personal data confidential.

This approach is a practical expression of a broader concept known as rational privacy. Rational privacy is the idea that privacy shouldn’t be absolute or all-or-nothing—it should be contextual. It recognizes that in many real-world scenarios, users want to share some data to gain access to services or meet legal obligations, but they shouldn't be forced to give up all privacy and security in the process. It’s about striking a balance between personal control, usability, and regulatory compliance.

Selective disclosure is the technical implementation of rational privacy. It gives users and developers the cryptographic tools to protect sensitive information by default, while still enabling the right level of transparency when it’s required. This makes it especially relevant for public blockchain networks, where data is immutable and visible by design.

A typical example of selective disclosure in action is the use of Verifiable Credentials (VCs). VCs allow users to prove attributes—like age, residency, or educational background—without revealing the entire credential. This aligns with the principles of data minimization and privacy by design, ensuring individuals remain in control of their information.

This balance between usability and privacy is what makes selective disclosure so powerful—and so relevant for real-world blockchain applications. But beyond the technical implementation, it's worth asking: what are the practical benefits of using selective disclosure in the first place?

Benefits of Selective Disclosure

When integrated thoughtfully, selective disclosure brings both technical and human-centric advantages to decentralized systems. It enables individuals and organizations to meet privacy expectations and compliance standards without sacrificing functionality. Implementing selective disclosure offers several advantages:

Enhanced Privacy: Selective disclosure enables users to share only the data necessary for a specific interaction, rather than disclosing full credentials or identity documents. This dramatically reduces the surface area for privacy breaches and surveillance. Whether you’re accessing a service, submitting a form, or interacting with a smart contract, your unnecessary personal data stays out of view.
Data Minimization and Compliance: This principle, core to privacy laws such as GDPR and HIPAA, requires that only the minimum amount of personal data necessary for a task is collected or processed. Selective disclosure naturally enforces this, making it easier for developers and organizations to design privacy-respecting systems by default.
User Empowerment and Control: In traditional systems, users often hand over their entire dataset for one small verification (e.g., uploading an entire ID just to prove their age). Selective disclosure flips that dynamic, giving users the power to control what they share, when, and with whom. This supports a more user-centric data model, where individuals become the custodians of their credentials.
Reduced Risk of Data Misuse: The less information that’s exposed, the lower the risk of that data being lost, stolen, or misused. Selective disclosure reduces the need for centralized data storage (e.g., big ID databases), limiting attack vectors for fraud and identity theft. Even if a transaction or credential presentation is intercepted, only the minimum disclosed attribute is visible, keeping the rest safe.
Lower Liability and Operational Overhead for Businesses: Many organizations would prefer not to collect or store sensitive user data due to the associated risks, regulatory requirements, and administrative burdens. Selective disclosure offers a path forward, enabling users to demonstrate eligibility or compliance without requiring businesses to retain or manage that data. This can reduce costs, simplify operations, and improve overall data security posture.

While selective disclosure introduces a powerful model for user-centric privacy, it also comes with its own set of technical and usability challenges. Understanding these limitations is essential for builders and organizations aiming to adopt it responsibly.

Potential Drawbacks

While selective disclosure strengthens privacy and control, implementing it in real-world systems isn’t always straightforward. Here are some of the common challenges:

Complexity in Implementation: Selective disclosure relies on advanced cryptographic techniques, often zero-knowledge proofs or similar privacy-preserving protocols. These require careful design, precise execution, and deep security expertise. For developers new to Web3 or cryptography, like myself, the learning curve can be steep, and mistakes in implementation could compromise the intended privacy protections.
Verification Difficulties: When only a fragment of a credential or statement is revealed, verifying its authenticity can become more complicated. Systems must be designed to ensure that partial disclosures can be trusted without needing access to the complete original data. This often requires additional metadata or proofs to be included, which can increase the overall complexity of the system and potentially slow down the verification process.
Interoperability Challenges: Not all decentralized identity systems follow the same formats or standards. As a result, credentials issued by one platform may not be easily verifiable on another, especially when using advanced features like selective disclosure. Without widely adopted protocols and infrastructure, cross-platform compatibility can be limited, reducing the broader utility of selectively disclosed data.

While these challenges are real, they’re not insurmountable. Much of the current work in privacy-preserving blockchain development, including projects like Midnight, focuses on making selective disclosure more practical, developer-friendly, and interoperable across various ecosystems.

Use Cases of Selective Disclosure

Selective disclosure has powerful, real-world applications wherever individuals or organizations need to prove something without oversharing. It’s beneficial in systems that handle sensitive data but also require compliance, trust, and transparency. Here are a few domains where it shines:

Digital Identity Verification: Imagine proving you're over 18 to access a service—without uploading your driver's license or disclosing your full birthdate and address. Selective disclosure lets you present only the relevant fact (e.g., “over 18”) as a verifiable statement, not the whole credential.
Financial Transactions: Financial platforms often need to confirm identity or transaction legitimacy (for KYC/AML compliance), but users shouldn’t have to share their entire financial history or wallet activity. Selective disclosure enables sharing only what’s legally necessary—no more, no less.
Healthcare: Patients may need to prove their vaccination status or medical eligibility without disclosing their entire health record. Selective disclosure lets them share only the required attribute (e.g., “vaccinated for X”) while keeping the rest private.
Access Control: Whether entering a venue or accessing online services, users may be granted or denied access based on attributes like membership, role, or credentials. Selective disclosure can enforce this access logic without revealing unnecessary identifying information.

Selective Disclosure in the Midnight Network

At Midnight, selective disclosure isn’t just a privacy feature—it’s a core design principle grounded in rational privacy. Rational privacy recognizes that while sensitive data must be protected, real-world applications also require controlled visibility for regulatory, legal, or operational reasons.

Take financial transactions, for example. A decentralized financial platform built on Midnight may want to keep user balances, transfers, and transaction histories private. However, under anti-money laundering (AML) or know-your-customer (KYC) regulations, certain information may need to be revealed—but only to authorized parties, and only under specific legal conditions.

This is where selective disclosure and zero-knowledge proofs come together. Using Midnight's Compact smart contract language, developers can build logic that proves a transaction is valid (e.g., below a certain threshold, or compliant with regulatory filters) without revealing the full transaction details. Meanwhile, if a regulatory audit is triggered, users or auditors could selectively disclose the required pieces of information—nothing more.

In this way, Midnight enables builders to create applications that respect individual privacy and comply with regulatory requirements. It’s a practical application of selective disclosure that mirrors how real-world trust operates: share only what’s needed, only when it’s needed, and only with the right people.

Conclusion

Selective disclosure offers a flexible and powerful approach to privacy—one that meets people where they are, allowing them to control their information. It enables individuals to share just enough information to satisfy requirements, without exposing more than necessary. Whether you're verifying an identity, proving a credential, or complying with financial regulations, selective disclosure makes privacy practical and effective.

At Midnight, this concept becomes more than theoretical. It’s embedded into the platform’s architecture through Compact smart contracts and zero-knowledge proofs, allowing builders to create systems that balance user protection with real-world needs. It’s rational privacy in action.

If you're exploring how to build for privacy in Web3—or just learning how these systems work—I encourage you to check out the Midnight docs and Academy for more examples and technical insight, as well as a detailed list of further reading about selective disclosure below:

And, as always, if you’ve come across any great learning resources on privacy or identity in Web3, I’d love to see them—drop a comment or reply with your favorites!

I'll be back next week with more insights as I continue unpacking the key building blocks that make decentralized systems work.

Learning Web3 from the Ground Up - Unpacking Merkle Trees and DAOs

Samantha Holstine — Fri, 06 Jun 2025 19:04:08 +0000

As I continue my Web3 learning journey, I've mostly been working through Cardano Academy and Midnight Academy and documenting my findings in the Midnight Dev Diaries. But this week, I decided to branch out and explore a broader range of beginner-friendly resources across the ecosystem. That led me to two foundational concepts that kept coming up: Merkle Trees and Decentralized Autonomous Organizations (DAOs).

These two topics sit at the heart of blockchain's promise—ensuring transparency, verifying data integrity, and enabling decentralized governance. I've broken down the key takeaways below, and if you're curious to go deeper, check out the list of helpful resources I've included at the end.

Merkle Trees: Ensuring Data Integrity

A Merkle Tree, also known as a hash tree, is a data structure that enables efficient and secure verification of large data sets. At its core, it is a special kind of binary tree—a structure many Web2 developers will recognize. In a binary tree, each node has at most two children. What makes Merkle Trees different is that instead of storing values directly, they store hashes. These hashes represent data blocks and provide a compact, tamper-evident summary of all the data in the tree.

Merkle Trees are crucial in blockchain because they allow a large set of data (like thousands of transactions) to be verified efficiently and securely. Instead of needing to check every transaction, you only need a small subset of hashes (called a Merkle proof) to confirm that a transaction is part of a block.

Here's a simplified breakdown of how a Merkle Tree is built:

Start with data blocks (like transactions in a block).
Each data block is hashed individually. These hashes become the leaf nodes.
Pairs of leaf hashes are then hashed together to form the next level of the tree.
This process continues, combining hashes pairwise and moving up the tree until you're left with a single root hash, often called the Merkle Root.

In short, each leaf node contains the hash of a data block, each non-leaf node contains the hash of its child nodes, and the root hash represents the entire data set. Any change to any single data block will change its hash, which then cascades up the tree, altering the Merkle Root. This property is crucial for blockchain systems, where data immutability and integrity are paramount.

In practice, Merkle Trees are used in:

Blockchain Transactions: Ensuring that transactions within a block are untampered.
Proof of Reserves: Cryptocurrency exchanges use Merkle Trees to prove they hold sufficient assets to cover user deposits without revealing individual account balances.

DAOs: Redefining Organizational Governance

Decentralized Autonomous Organizations (DAOs) are organizations governed by smart contracts on a blockchain, eliminating the need for centralized leadership. They replace traditional top-down leadership with transparent, community-driven governance, all enforced through code—specifically, smart contracts.

In a DAO, rules and operations are programmed upfront and stored on-chain. That means anyone can inspect how decisions are made, how funds are allocated, and how proposals are handled. Everything is transparent and auditable by default. Instead of a single CEO or board, decisions are made collectively by the community. Token holders can vote on proposals, and the outcome reflects the weight of their stake in the project. This collective decision-making process is what makes DAOs decentralized by design. And because those rules are enforced automatically by smart contracts, DAOs can operate autonomously without relying on manual intervention or centralized gatekeepers. Once a proposal passes, the smart contract executes the decision just as it was coded—no waiting for someone to push a button.

However, DAOs also face challenges, including:

Security Risks: Vulnerabilities in smart contracts can be exploited.
Governance Issues: Low voter participation and token concentration can lead to centralization.

DAOs have been utilized in various domains, such as:

Investment Funds: Pooling resources to invest in projects collectively.
Charitable Organizations: Deciding on fund allocation through member voting.
Protocol Governance: Managing and updating blockchain protocols.

How DAO Voting Works (The Simple Version)

Most DAOs use token-based voting to reach decisions:

Members hold a governance token, which gives them the right to vote.
A proposal is submitted (for example, "Fund a new development project").
Token holders vote for or against the proposal.
If a certain threshold is reached (like a quorum or majority), the proposal is accepted and automatically executed by smart contracts.

Beyond on-chain voting, many DAOs utilize off-chain governance platforms, such as Snapshot (widely used for token-weighted voting), Aragon Voice, Tally (commonly paired with Governor contracts), or Coordinape (used for decentralized grants and peer voting). These tools offer flexibility, reduce gas costs, and enable more experimental governance setups.

The more tokens you hold, the more voting power you wield. This is similar to how shareholders vote in corporations, but the process is entirely on-chain, without intermediaries.

Some DAOs use quadratic voting or other mechanisms to prevent whales (large holders) from dominating the process, but the core idea remains the same: the community drives the roadmap.

Interplay Between Merkle Trees and DAOs

While Merkle Trees and DAOs serve different purposes in the blockchain world—one focused on data integrity, the other on governance—they complement each other in powerful ways. Together, DAOs can remain secure, transparent, and efficient even as they scale.

For example, instead of storing a complete list of eligible voters, a DAO can publish a Merkle Root representing that list. Individual voters then submit a short cryptographic proof (a Merkle proof) to confirm they're included. This keeps voting lightweight, private, and verifiable. The same method can be used to verify grant recipients or airdrop eligibility—ensuring integrity while saving space and gas costs.

Merkle Trees also act as a bridge between off-chain and on-chain activity. Whether it's tracking voting done through Snapshot or verifying community identities, these proofs give DAOs a scalable way to maintain trust and transparency—even as they grow.

Merkle Trees provide DAOs with the cryptographic foundation to scale governance without sacrificing transparency or efficiency. Whether it's verifying voter eligibility, proving fund distribution, or bridging off-chain data to on-chain actions, Merkle Trees help DAOs maintain trust and accountability as they grow. It's a powerful example of how foundational blockchain structures support and enhance decentralized decision-making.

Conclusion

Together, Merkle Trees and DAOs demonstrate how blockchain technology strikes a balance between technical efficiency and community empowerment. Merkle Trees ensure that large sets of data—like transactions, votes, or recipient lists, can be verified quickly and securely. At the same time, DAOs introduce a way for communities to govern decentralized projects in a transparent and fair manner. When combined, they offer a practical solution for scaling trust without sacrificing decentralization. Whether you're verifying a vote, distributing funds, or proving membership, these tools help build the infrastructure that makes Web3 more than just a technological shift—it becomes a new model for how people coordinate, decide, and build together.

Exploring beyond the Cardano and Midnight Academies for the first time in this journey provided me with a broader understanding of how these technologies are explained and applied across the space. If you're learning along with me or want to dig deeper into any of the topics covered, here are some of the materials I found especially helpful:

And if you’ve come across other great resources while learning Web3 basics, I’d love to hear them—drop a comment or reply with your favorites! You can also check out the Midnight docs for more technical deep dives and real-world use cases.

Stay tuned for next week's exploration into other core components of the decentralized world.

Learning Web3 from the Ground Up - A Quick History of Blockchain and Why Tokens Matter

Samantha Holstine — Mon, 02 Jun 2025 15:38:55 +0000

I’m still in the early stages of my Web3 learning journey (see my previous posts on the Midnight Dev Diaries!), and each week unveils new insights and "aha" moments for me. This week, I delved deeper into the Intro to Blockchain section of Cardano Academy, along with Module 1 of the Midnight Developer Academy. Rather than just focusing on the technical aspects and step-by-step guides, I shifted my attention to understanding the evolution of blockchain platforms over time, particularly the journey from Bitcoin to more advanced systems like Midnight. This exploration also led me to reflect on the crucial role that tokens play in the functionality and sustainability of decentralized systems. Tokens aren't just mere digital assets; they serve as the economic backbone that incentivizes participation and secures the network. In this post, I want to share two significant topics that helped clarify my understanding this week:

How blockchain platforms have progressed from Bitcoin to Midnight
How tokens keep decentralized systems running through economic incentives

Let's jump in!

The Evolution of Blockchain Platforms

When I first heard about blockchain, I mostly associated it with Bitcoin. However, after diving into more educational content, it became clear that this space has undergone multiple waves of innovation, each building on the last. Here's how we got from the first Bitcoin transaction to the emergence of privacy-focused blockchains like Midnight.

Bitcoin (2009): A New Way to Move Money

Blockchain began with Bitcoin, launched in 2009 by the pseudonymous Satoshi Nakamoto. It introduced the idea of a decentralized, peer-to-peer payment network where anyone could send money without relying on banks or intermediaries. Transactions were validated through proof-of-work and recorded on a public ledger that anyone could inspect—but no one could alter.

This was revolutionary. Bitcoin proved that decentralized digital money was possible—and, in 2010, someone even traded 10,000 BTC for two pizzas. That transaction is now famous for being the first real-world use of Bitcoin and the most expensive pizza ever bought.

Still, Bitcoin was narrowly focused: it could securely transfer value but not much else.

Ethereum (2015): The Rise of Programmable Blockchains

Ethereum took the core idea of blockchain and expanded it into something far more flexible. It introduced smart contracts—self-executing programs that live on the blockchain and run when certain conditions are met. This turned Ethereum into what its creators called a "world computer": a decentralized platform for building applications that couldn't be shut down or censored.

Ethereum is guided by six key principles:

Atomicity: All or nothing execution
Synchrony: Consistent state across nodes
Provenance: Trackable origins
Permanence: Durable data storage
Immortality: Apps that can't be turned off
Immutability: Data that can't be changed once written

These principles laid the groundwork for DeFi, NFTs, and DAOs, giving rise to an entire ecosystem of decentralized applications. However, this flexibility came with trade-offs, especially around scalability and high transaction fees.

Third-Generation Platforms: Cardano and Beyond

Enter the third generation of blockchains. These platforms aim to solve the Blockchain Trilemma: how to balance scalability, security, and decentralization—without sacrificing any of them.

Cardano, launched in 2017, is one of the most notable examples. It uses proof-of-stake to reduce energy consumption and improve efficiency. But what stood out most to me is that it was built from the ground up with formal research and peer-reviewed design—a very different approach from its predecessors.

Cardano also addresses security at the protocol level. Unlike Ethereum, where new tokens are created via smart contracts (which can introduce vulnerabilities), tokens on Cardano are treated as native assets. This means they inherit the same security guarantees as the platform's native currency, ADA, and don't require a custom contract to be created or maintained.

Other improvements include:

Layer 2 scaling solutions like Hydra
Support for sidechains to improve interoperability
A focus on sustainability by reducing resource consumption through staking is also needed

Midnight: The Privacy Layer of the Future

Midnight represents a new phase in blockchain evolution focused on privacy and regulatory compliance.

It uses tools like zero-knowledge proofs to allow data to remain private on a public blockchain. At the same time, it supports selective disclosure, meaning users can prove compliance (for example, with regulations or audits) without revealing everything. In other words, Midnight blends the decentralization and transparency of blockchain with the privacy needed for real-world use cases—whether it's secure communication, confidential data sharing, or regulated financial applications.

Tokenomics 101: Why Tokens Are More Than Just Coins

Once I understood how blockchains evolved, the next big question was: How do they keep running without a central company in charge? The answer lies in tokenomics, the economic design behind each network.

Tokens as Utility

Every blockchain has a native token—Bitcoin has BTC, Ethereum has ETH, Cardano has ADA. But tokens aren't just money. Tokens are used to pay transaction fees, deploy contracts, access network features, and more.

This creates a built-in incentive system. If using the network requires tokens, and the network is valuable, then tokens have value too.

Tokens as Incentives

Blockchain networks need participants to validate transactions, secure the network, and maintain consensus. In return, they reward those participants with tokens.

For example:

Miners earn BTC for adding blocks to the Bitcoin chain.
Validators earn ADA in Cardano's proof-of-stake system to secure the network.

These rewards are often inflationary, meaning new tokens are regularly minted and distributed. However, that inflation funds the network's infrastructure.

Tokens as Governance Tools

Some tokens also allow holders to vote on decisions. In DAO-style systems, governance tokens let users decide protocol upgrades, fee structures, or treasury spending. This turns token holders into active stakeholders, not just passive investors.

Inflationary vs. Deflationary Models

The way a token's supply is designed can shape behavior:

Inflationary models (e.g., Polkadot) continually mint new tokens to incentivize active participation.
Deflationary models (e.g., Bitcoin) cap the total supply or burn tokens to reduce circulation.

Each model has trade-offs: Inflation can reward contributors but reduce long-term value, while deflation can increase scarcity but discourage spending.

Many modern projects use hybrid models. For example, Ethereum burns a portion of transaction fees to offset inflation while still issuing new tokens to validators.

Conclusion

Understanding where blockchain originated and how tokens drive these systems provided me with a much clearer view of the ecosystem I'm entering. It's not just about code or decentralization for its sake. It's about designing systems where people are economically motivated to do the right thing. And just like the technology itself, the economics behind blockchains are still evolving.

If you're learning Web3 too or just curious how all the pieces fit together, be sure to take a look at the Midnight docs, Dev Diaries, and the newly published modules in the Midnight Developer Academy.

More foundational concepts are coming next week—stay tuned!

Learning Web3 from the Ground Up: Encryption & Practical Byzantine Fault Tolerance

Samantha Holstine — Wed, 21 May 2025 14:17:57 +0000

I'm still in the early stages of learning about Web3 (see my last two blog posts here and here!), and the deeper I go, the more I realize that the real magic of blockchain isn't just in the code—it's in the cryptography that secures data and the consensus algorithms that coordinate it. As I continue learning, two concepts stood out this week: public key encryption and Practical Byzantine Fault Tolerance (PBFT).

These may sound intimidating, but they’re the backbone of how blockchains protect data and reach agreement without a central authority. I explored them through Cardano Academy's Intro to Blockchain series, which continues to be a great entry point for breaking down these core concepts.

Here's what I learned—and how these two building blocks shape the infrastructure behind modern blockchain networks.

Public Key Encryption – Sending Secrets Without Sharing Keys

Encryption is the backbone of blockchain security. It allows us to send private messages, verify identities, and keep data safe—even across open, decentralized networks like the internet or blockchain itself. This is especially important in Web3, where blockchains are public by default—anyone can view the data, participate in the network, or run a node. At Midnight, encryption plays a key role in protecting sensitive data while still allowing it to live on a public chain. From shielded transactions to selective disclosure, Midnight builds on the principles of public key cryptography to enable privacy without sacrificing decentralization.

At a high level, encryption is just the process of turning readable data (called cleartext) into gibberish (ciphertext) so that only the right person can turn it back. But how do we do that without first sharing a secret key?

The Two Types of Encryption

There are two main types of encryption:

Symmetric encryption: The same key is used to encrypt and decrypt the message. It's fast, but you need to share that key first, which can be tricky to do securely.
Asymmetric encryption (also known as public key encryption): Uses a key pair—one public and one private. What one key encrypts, the other can decrypt. If you encrypt something with a public key, only the matching private key can unlock it and vice versa. They’re mathematically linked, but guessing one from the other is nearly impossible.

The key difference? In symmetric encryption, both people share one secret key. In asymmetric encryption, no shared secret is needed, just a matching key pair.

A Simple Analogy

Think of symmetric encryption like a shared locker: you and your friend have the same key. Anyone with that key can open the locker. The hard part? Making sure only the two of you have a copy. On the other hand, asymmetric encryption is more like giving everyone a padlock with your name on it (your public key). Anyone can lock a box and send it to you, but only you, holding the matching private key, can open it.

How It's Used in Blockchain

When Alice wants to send Bob a secure message:

Bob shares his public key.
Alice encrypts her message using Bob's public key.
Bob receives and decrypts the encrypted message using his private key.

Even if someone intercepts the message, it’s unreadable without Bob’s private key. Thanks to the math behind elliptic curves and RSA, it would take more time than the universe has existed to reverse-engineer a private key from a public one with today’s computers.

Why Not Just Use Public Key Encryption for Everything?

Public key encryption is powerful but computationally heavy. That's why, in practice, most secure systems (like HTTPS) use a hybrid model:

The client and server use public key encryption to securely exchange a temporary session key.
From then on, they use symmetric encryption with that shared key to communicate quickly and securely.

This is the same approach blockchains often use for performance and scalability—combining the strengths of both methods.

Practical Byzantine Fault Tolerance – How Blockchains Reach Consensus

Now that we've covered encryption, let's move to something that puzzled me at first: How do blockchains reach consensus without a central decision-maker? That's where consensus algorithms come in. This week, I learned about one of the earliest and most influential: Practical Byzantine Fault Tolerance, or PBFT.

First, a Quick Refresher on Consensus

Consensus is how distributed systems agree on a single truth, even if some participants are slow, offline, or actively trying to cause problems. It's what lets a decentralized ledger agree on who owns what, and it's essential for any blockchain to function.

The "Byzantine" part comes from a famous thought experiment called the Byzantine Generals Problem, in which generals need to coordinate an attack but can't trust their messengers. In blockchain terms, nodes must agree on a block, even if some are lying or malfunctioning.

What Makes PBFT "Practical"?

PBFT is designed to work in weakly synchronous systems—systems where messages might be delayed, but not indefinitely. It assumes that at most one-third of nodes can be faulty and uses cryptographic signatures to authenticate all messages. That means messages might be delayed, but will eventually arrive, unlike in totally unreliable (asynchronous) systems.

PBFT has a built-in process called view change, which automatically replaces a faulty primary when enough nodes detect issues. Here's how it works in broad strokes:

A client (like a user submitting a transaction) sends a request to a primary node.
That primary broadcasts the request to other replica nodes.
Each replica processes the request and responds.
The client waits for enough matching replies (2/3 + 1) to confirm the result.

Suppose the primary node is unresponsive or sends conflicting messages. In that case, replicas can vote to replace it and elect a new primary. This makes PBFT fault-tolerant and adaptive, critical for blockchains operating in the real world.

Real-World Analogy

Imagine you're on a group project. One person (the "primary") shares the final version of the project. Everyone else ("replicas") reviews it. If enough people agree it's correct, you submit it. But if someone thinks the leader messed up, they can flag it—and if enough people agree, the group picks a new leader.

PBFT formalizes this process with message signatures, vote thresholds, and fault limits.

Where PBFT Shines—and Where It Doesn't

PBFT excels in small, permissioned networks where all participants are known and vetted, such as enterprise or consortium blockchains. It offers fast and deterministic finality with fewer probabilistic assumptions than models like proof-of-work or proof-of-stake.

But there are trade-offs:

It doesn't scale well to hundreds or thousands of nodes—it's communication-heavy.
Nodes must know about each other ahead of time.
It's less decentralized and potentially vulnerable to Sybil attacks if new nodes aren't vetted carefully.

That's why PBFT-inspired models are often combined with other mechanisms, like rotating leadership or staking systems, to improve scalability and resilience.

Conclusion

Encryption and consensus might sound like deep technical topics (and they are), but at their core, they solve very human problems: How can we keep secrets? And how can we agree on what's true when no one is in charge? Here's a quick overview of both concepts, what they solve, and what they're used for:

Public Key Encryption: Secure communication over open networks. Used in Wallets, HTTPS, block signing
PBFT: Reaching agreement in the face of faulty/lying nodes. Used in permissioned blockchains, early crypto projects

Learning about these two areas gave me a clearer view of the building blocks behind secure, decentralized systems like Cardano—and why consensus and cryptography are so tightly intertwined in Web3.

All of the material in this post comes from Cardano Academy, which continues to be a fantastic first stop in my Web3 learning journey. I'll be adding more resources over time and sharing what I learn along the way. If you're also getting started, check out the Academy, do some digging on your own, and browse through the Midnight docs and Dev Diaries if you want a glimpse of how these ideas show up in practice.

If you're learning along with me, which concepts have been most challenging to wrap your head around? Drop a comment. I’d love to swap resources! More foundational concepts are coming soon!

Learning Web3 from the Ground Up: Hash Functions & Digital Signatures

Samantha Holstine — Wed, 07 May 2025 14:27:30 +0000

I'm still at the beginning of my Web3 journey, and already it’s clear: before you can build the future, you have to understand the foundations. This week, I focused on two key cryptographic building blocks: hash functions and digital signatures.

These concepts might initially sound intimidating, but they're at the core of blockchain, ensuring data integrity, authenticity, and security. I learned about them through the "Intro to Blockchain" section of the Cardano Academy—a fantastic first stop on my learning journey. Here's a breakdown of what I took away.

Hash Functions – The Digital Fingerprints of Blockchain

Hash functions are everywhere in a blockchain—they link blocks, verify data, and secure transactions. Think of a hash function as a digital fingerprint: it takes an input of any size and produces a fixed-length string (called a hash digest) that uniquely represents that input.

Key Properties of Cryptographic Hash Functions

To be helpful in a blockchain or cryptographic setting, hash functions must possess several specific properties that ensure their security and reliability. Some of the most important properties include:

One-way: You can go from input to hash, but not vice versa.
Deterministic: The same input will always produce the same output.
Avalanche Effect: A tiny input change causes a massive output change.
Preimage Resistance: You can't guess the input just by looking at the hash.
Collision Resistance: It's nearly impossible to find two different inputs that give the same hash.

These properties are critical for ensuring that once data is recorded—like a transaction—it can't be altered without detection.

Real-World Use Cases

Hash functions aren’t just theoretical—they’re used all the time in real-world systems to keep data secure. Here are a few practical ways they show up:

Password storage: Systems store hashes, not the actual passwords.
Data integrity: Hashes are used to check if data has been altered.

Blockchain linking: Every block contains the previous block's hash—alter one, and the whole chain breaks.

Popular hash functions include SHA-256 (used by Bitcoin), SHA-3, and RIPEMD-160. Some older algorithms, such as MD5 and SHA-1, are now considered insecure due to collision vulnerabilities.

Digital Signatures – Proving Who Sent What (and That It Wasn't Changed)

If hash functions are about verifying data hasn't changed, digital signatures go a step further by proving who sent the data. This gives us authenticity and non-repudiation.

How They Work (In a Nutshell)

The digital signature process cleverly combines hashing and encryption to guarantee both authenticity and integrity. Here's a high-level overview of how it works:

Signing: The sender hashes the original message and encrypts that hash using their private key, creating the digital signature.
Verifying: The recipient uses the sender's public key to decrypt the signature and then checks if the result matches the hash of the received message.
If the hashes match, the message is verified. If not, it's been tampered with.

Now, let’s make this less abstract. Think of it like sending a secure email using PGP (Pretty Good Privacy):

When you send an encrypted email using PGP, your email client uses your private key to sign the message. Anyone who receives it can use your public key to confirm it was really you who sent it, and that the content hasn’t been changed in transit. The same principles apply to digital signatures on the blockchain: the sender signs a message or transaction, and anyone with the public key can verify it. While the tools and context differ, the underlying idea remains familiar: use cryptographic keys to establish trust without relying on a centralized authority.

Why This Matters

Only the private key can create a valid signature.
Anyone can use the public key to verify it.
If someone tampers with the message, the signature will fail verification.

Types of Digital Signature Algorithms

Different blockchains and cryptographic systems utilize various signature algorithms, depending on their specific security and performance requirements. A few notable examples are:

RSA: Based on the difficulty of factoring large numbers.
DSA: Based on the discrete log problem.
ECDSA: A more efficient elliptic curve version used by Bitcoin.
Ed25519: The one used by Cardano, known for its speed, security, and small key sizes.

Wallets: Where the Magic Happens

Most of us don’t interact directly with private keys or raw cryptographic operations. Wallets make it manageable by handling keys and signing transactions securely in the background.

There are two main types of wallets:

Custodial wallets: A third party, such as an exchange, manages your keys.
Non-custodial wallets: You control your own keys—more responsibility, but more control.

Wallets also fall into two categories: hot (online) and cold (offline) storage. Hardware wallets, such as Ledger or Trezor, are considered cold storage because they keep your keys offline. Cold wallets are generally preferred for long-term or high-value holdings due to their increased security.

Conclusion

Hash functions and digital signatures are like the grammar and punctuation of blockchain. They quietly enable much of what makes the ecosystem secure and trustless. Learning about them provided a clearer understanding of how blockchains, such as Cardano, and tools like Midnight operate under the hood.

I highly recommend checking out Cardano Academy. It's approachable and well-structured. I also suggest doing your own research and diving into the Midnight documentation and Dev Diaries for more technical depth. Be sure to check out last week’s blog post on blockchain fundamentals.

If you're learning Web3 with me, I'd love to hear what's helped you, what's tripped you up, and what topics you'd like to see explored next. More foundational concepts to come next week!

Learning Web3 from the Ground Up: A Beginner's Journey into Blockchain

Samantha Holstine — Thu, 24 Apr 2025 19:58:23 +0000

Joining the Midnight team as a Developer Relations Engineer has been an exciting transition, but also an eye-opening one. While I anticipated a learning curve stepping into the Web3 space, I didn't expect just how fundamentally different it would be from my experiences in Web2. Web3 isn't simply a new tech stack—it's a shift in how we think about data, trust, and ownership.

As I began onboarding with Midnight, I quickly realized that to fully understand the value and capabilities of the platform, I first needed to ground myself in the core principles of blockchain and decentralized technologies. I started learning the basics with Cardano Academy as a first pass, and it has been a great resource for getting up to speed on the foundations of Web3.

So, if you're also new to Web3 or blockchain and feeling a bit overwhelmed, you're not alone. And if you're a seasoned pro, consider this a little refresher on some foundational topics I’ve started diving into. Here are the core concepts I've been exploring this week as I embark on my journey into the world of decentralized technology.

Core Concepts of Blockchain

Decentralization

At its heart, blockchain is about decentralization. Instead of relying on a single authority, such as a bank or server, blockchain distributes control across a network of independent nodes. This makes the system more resilient—there is no single point of failure—and ensures that no single entity can unilaterally change the rules.

Decentralization also lays the groundwork for trustless systems, where participants can interact and transact without needing to trust a central authority.

Consensus Algorithms

But how do all these independent nodes agree on what's true? That's where consensus algorithms come in. They enable a decentralized network to reach a consensus, even when some nodes are offline or acting maliciously.

This idea actually solves a famous problem in distributed systems known as the Byzantine Generals Problem—how to coordinate among parties that can't fully trust each other. Different blockchains address this issue in various ways, which we'll explore shortly.

Blockchain Structure

The term "blockchain" is literal: it's a chain of blocks, each containing data. Every block links to the previous one using a cryptographic hash. This structure makes the data immutable—once it's recorded, you can't change it without altering every block that came after it, which is extremely difficult.

This immutability, combined with transparency, is what gives blockchain its auditability and security.

Consensus Mechanisms

Now that we've discussed consensus in theory, here's a breakdown of how it works in practice. Different blockchains employ various mechanisms to achieve consensus, each with its strengths, trade-offs, and specific use cases.

Proof of Work (PoW)

What it uses: Computational power.
How it works: Miners compete to solve complex math problems. The first one to solve one gets to add the next block to the chain.
Pros: Secure and well-tested (used by Bitcoin).
Cons: Extremely energy-intensive and not very scalable.

Proof of Stake (PoS)

What it uses: Stake in the network (native tokens). How it works**: Validators are chosen to create new blocks based on how much they've staked.
Pros: Much more energy-efficient than PoW, faster transactions.
Cons: Can raise concerns around wealth concentration and governance.

Practical Byzantine Fault Tolerance (PBFT)

What it uses: Agreement among a known group of nodes.
How it works: Nodes exchange messages to confirm transactions, even if some are faulty.
Pros: Fast finality, great for permissioned blockchains.
Cons: It doesn't scale well for large public networks. It is often used in smaller, permissioned networks because it requires many messages between nodes to agree, which makes it impractical for large public blockchains.

Other Consensus Models

Numerous niche, experimental, and hybrid models are available. Here are a few that caught my attention:

Proof of Authority (PoA): Uses validator identity/reputation and is typically used in permissioned chains.
Proof of Activity (PoAc): A hybrid of PoW and PoS where miners start the process, and validators stake to complete it.
Proof of Burn/Capacity/Contribution: Novel methods using resources, effort, or behavior.
Proof of Elapsed Time (PoET): Uses secure hardware to ensure fairness.

Conclusion

This is just the beginning of my journey, but already, I can see how powerful and complex this space is. Understanding blockchain and consensus mechanisms is like learning the grammar of a new language. It's the foundation for understanding platforms like Midnight and the kinds of problems it's designed to solve.

So far, everything I’ve shared has come from one resource: Cardano Academy. It’s been a helpful starting point, but it’s just that – a starting point. I plan to explore many more resources to continue building my knowledge, and I recommend that you do the same. Cardano Academy is a great place to start, but supplementing it with your own research and delving into the Midnight documentation and Dev Diaries can provide a much more well-rounded understanding of Web3.

If you're also diving into Web3 for the first time, I hope this helped give you some structure to start your learning. And if you're already immersed in the space, I'd love to hear what helped you connect the dots when you were starting out—please drop a comment or share your favorite learning resources with me!

More concepts to come as I dig deeper into Midnight and the wider Web3 world – and I’ll be sharing additional resources along the way as I continue learning. Stay tuned!

DEV Community: Devs of Midnight

Compact을 시작하기 전 알아야 할 Midnight의 작동 방식

익숙해 보이는 문법, 전혀 다른 실행 방식

EVM과 Midnight의 가장 큰 차이: 실행 모델

상태와 자산을 바라보는 방식

Compact을 기존 스마트 컨트랙트 언어처럼 보면 안 되는 이유

disclose()는 왜 필요할까

Midnight은 문법보다 사고방식이 먼저입니다

Next Step: 환경 설정

핵심 정리

Midnight MCP - AI-assisted development for Compact smart contracts

What is MCP?

The problem with AI-generated Compact code

Install Midnight MCP

Claude Desktop

Cursor

VS Code with GitHub Copilot

How Midnight MCP works

Real compiler integration

Graceful fallback

Semantic search across 102 repositories

29+ tools for Midnight development

Search tools

Analysis tools

Generation tools

Repository tools

Version management tools

Resources and prompts

Architecture

What's next

Learn more

Introduction to the FungibleToken contract on Midnight

Introduction to the FungibleToken contract on Midnight

Features of the FungibleToken Contract

1. Ledger State Variables

2. Entry Points and Circuits

Initialization & metadata

The transfer family

Allowances (approve / spend / transferFrom)

Minting and burning

Safety & utility glue (from Utils and Initializable)

How the pieces fit together

Conclusion

Links

Learning Web3 from the Ground Up: Understanding Ethereum

Ethereum in a Nutshell

Why Ethereum Matters

Ether: The Fuel of the Ethereum Network

The Power of Smart Contracts

Ethereum Today and Tomorrow

How Ethereum Connects with Midnight

Conclusion

Learning Web3 From the Ground Up: What Are Zero-Knowledge Proofs (ZKPs)?

What Are Zero-Knowledge Proofs?

Interactive vs. Non-Interactive Proofs

Types of Zero-Knowledge Proof Systems

How Do ZKPs Work?

Midnight’s Approach to ZKPs

Confidential Transactions

Selective Disclosure and Compliance

Decentralized Identity

Scalability via Recursive Proofs

Real-World Use Cases on Midnight

Conclusion

Learning Web3 from the Ground Up: Smart Contracts and the Compact Language

What Is a Smart Contract on Midnight?

What Is Compact?

Circuits and Privacy

From Theory to Practice

Conclusion

Learning Web3 From the Ground Up: Understanding Selective Disclosure

What Is Selective Disclosure?

Benefits of Selective Disclosure

Potential Drawbacks

Use Cases of Selective Disclosure

Selective Disclosure in the Midnight Network

Conclusion

Learning Web3 from the Ground Up - Unpacking Merkle Trees and DAOs

Merkle Trees: Ensuring Data Integrity

DAOs: Redefining Organizational Governance

`disclose()`는 왜 필요할까

Safety & utility glue (from `Utils` and `Initializable`)