Forem: Samantha Holstine

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!

From Insights to Action: Harnessing Camunda Optimize for Effective Development

Samantha Holstine — Mon, 26 Feb 2024 13:00:00 +0000

As a new Camunda user, I am actively learning the wide toolset the product has to offer and understanding its impact on my new role at Camunda. While navigating through the Camunda Academy tutorials, my curiosity prompted me to explore all of Camunda’s components, leading me to discover Optimize. As a developer, I was hesitant at first to learn more about a feature that is primarily designed for business logic, but immediately saw how developers can leverage its features to enhance their development process and gain valuable information. This blog post will guide you through my findings as I learn more about Camunda and Optimize, using a simple trivia game as a practical illustration.

Error and Incident Optimization

One of the key features of Optimize is its ability to help developers optimize their processes to produce fewer errors in the long term. By leveraging premade reports, developers can identify incident hotspots and bottlenecks using heatmaps.

When adding a “Locate incident hotspots on a heatmap” template to an Optimize dashboard, developers can produce a visual representation of incidents based on both the resolution duration—how long it takes to resolve a specific issue—and by count—how many incidents occurred. By hovering over any task on the heatmap, developers can quickly analyze the duration and frequency of incidents. Additionally, filters can be applied to narrow down the data, such as by date and time.

Looking at our trivia game example, the heatmap can display the average time each trivia game spends at a specific task, in this case getting a hint from OpenAI. However, if this task was attached to a specific piece of code, developers can easily identify where there may be issues, like a bug in the code or a service that is down.

Another useful template in Optimize is the “locating bottlenecks” report. This heatmap showcases the average time spent on each part of a process.

For example, in the trivia game, answering questions and displaying messages took the longest amount of time. By analyzing this data in their product, developers can identify potential areas of improvement or automation. This information can help optimize the code and improve the overall user experience.

Creating Custom Reports

In addition to pre-built templates, Optimize allows developers to create their own custom reports. With a blank report, developers have the freedom to display any data they desire. For instance, the number of categories played in the trivia game can be showcased.

It’s not surprising to see that science/nature was our top category at a developer conference! This provides a comprehensive overview of the process’s performance and user preferences, as well as information about specific variables to make sure they’re producing the correct values.

In-depth Process Analysis

Optimize offers an analysis tab that provides additional insights into data and performance.

In the “Task Analysis” tab, developers can explore heatmaps that highlight outliers, indicating process instances that deviate from the average, which helps identify potential issues or inefficiencies in the process. From there, the instance IDs and more details can help developers dive into issues about specific tasks or parts of the process. Using the task analysis can be helpful to ensure new versions of a process runs similarly, as well as tracking improvements between versions.Similarly, the “Branch Analysis” tab provides the probability of instances following a desired path.

For example, in the trivia game, developers can analyze how many players who received hints were able to reach the winning path. These insights can guide further improvements and optimizations.

Optimize also offers a machine learning-ready data set, enabling developers to export and analyze their data using machine learning techniques. This means the data is already formatted and structured to align with machine learning algorithms to make predictions for future instances based on existing instances. The machine learning-ready data set simplifies the process of integrating Optimize with machine learning models and allows for more advanced analysis and predictions.

Let’s Review

No matter what type of developer you are—whether you’re an enterprise professional, a startup enthusiast, an engineering manager, or just starting your coding journey—Optimize offers a diverse range of insights that cater to your specific needs.

Efficient Issue Resolution : By utilizing Optimize’s error and incident optimization features, developers can identify and address bottlenecks and issues efficiently.
Comprehensive Performance Views: Custom reports and dashboards provide a comprehensive view of the application’s performance and user interactions.
In-Depth Analysis for Improvement : The in-depth analysis features enable developers to gain deeper insights into the data and identify areas for further improvement.

Overall, Optimize empowers developers to improve their code, improve user experiences, and drive better business outcomes. For a visual exploration of these capabilities, don’t forget to check out our video overview. Feel free to engage in discussions and share your experiences in the Optimize forum category—it’s a great platform for further insights and community collaboration. For additional resources and detailed guides, explore the following links:

The post From Insights to Action: Harnessing Camunda Optimize for Effective Development appeared first on Camunda.