OpenCerts & Ethereum Whitepaper (2014)

Open Cert + Ethereum Whitepaper 2014

Section 1: Introduction to the Ethereum blockchain

Some context on key figures in Ethereum 2014 & their involvement:

A brief history:

The Ethereum whitepaper spends about a quarter of its content explaining Bitcoin, which is important to appreciate as Ethereum was intended to address some problems that came about with Bitcoin’s protocol: It had very limited programmable features. Smart contracts are self-executing programs that automatically enforce and execute agreements when predetermined conditions are met. Think of them as digital vending machines - you put in the right input (money/data), and the contract automatically delivers the output without needing a middleman.  

Smart contracts introduce:

• Turing-complete programming language (ability to recreate any program with Solidity)

• State management (ability to store, track & modify data)

• Composability (function calls to each other - can build on top of each other)

Section 2: What does the Ethereum Blockchain keep track of?

Now that you know smart contracts can store data, what then, stores the smart contract and its data? Let’s examine this from an actor’s point of view:

Block-chaining: What is a block?

The Complete Blockchain stores:

• Every block header
• Every transaction
• Every receipt
• The entire current state

Three Active Merkle Trees PER BLOCK:

• Transaction Trie: All transactions in that block
• Receipt Trie: All transaction receipts in that block
• State Trie: The entire world state after that block

Storage Reality

• Historical Data:

• Block 1: TxRoot₁, ReceiptRoot₁, StateRoot₁

• Block 2: TxRoot₂, ReceiptRoot₂, StateRoot₂

• ...

• Block N: TxRootₙ, ReceiptRootₙ, StateRootₙ

• Current Active State:

• Only the latest state trie is "live" and queryable

• Historical state tries can be reconstructed but aren't kept in memory

Storage Optimization

Patricia Merkle Tries:

• Nodes share common prefixes
• Unchanged branches reference previous versions
• Only changed paths create new nodes

Example:

• Old State Trie: Root₁ → ... → OpenCerts storage (old)
• New State Trie: Root₂ → ... → OpenCerts storage (new)

                   └─ Shared unchanged branches

^ Note that most of the trie structure is reused between blocks!

In summary: Validators are managing these 3 data structures, but they're optimized with sharing, pruning, and different storage tiers. The beauty is that even with pruning, any node can still verify OpenCerts certificates because they only need to check the current state trie!

^ Note: Ethereum is not simply just Patricia Merklet Tries! Other data structures exist: Directed Acyclic Graph (used for GHOST consensus protocol), Binary Merkle Trees (for efficient proof generation), AVL/Red-Black Trees (for indexing and caching), B-Trees (for disk storage optimization), DHT Trees (for peer discovery; Kademlia), Routing Trees (for network topology).

Section 3: Consensus – how everyone agrees on a single thing

Ethereum has evolved since the genesis block back in 2015, transitioning from Proof of Work (PoW) to Proof of Stake (PoS), and we will be only discussing PoS for this section to avoid any confusion. However, you may refer to the classic 2014 Ethereum Whitepaper to read up on PoW mechanisms for Ethereum!

Consensus mechanism is implemented on the Beacon Chain [Ethereum = Consensus (aka Beacon Chain) + Execution Layer (aka Ethereum Virtual Machine)], this is where everyone agrees on who would be the next block proposer. Every block takes exactly 12 seconds, and 32 blocks form an Epoch (~6.4 minutes). Once a block is more than 2 epochs old (~12.8 mins past), it is considered finalised!

^Note: reversing finality is still possible but a massive economic undertaking! An attacker will need to control 2/3rds of all staked ETH + get 1/3rd of their stake immediately slashed (at the minimum losing ~$30B, and needing to have control of close to more than $60B worth of Ether!)

Block Proposal to Finalized Process:

Section 4 (truncated): Execution & Consensus Layer

In summary, here are the various actors and their responsibilities:

*Notice how execution for validators is mandatory? How is execution for validators different from full/archive nodes?

Section 5 (truncated) : Gas/Fees

A practical overview of gas mechanism:

Every blockchain transaction requires network-wide processing. To prevent spam, blockchains charge gas fees. Bitcoin lets users bid any fee - miners pick the highest-paying transactions in what seems like a fair market.

The problem: When miners include transactions, every node (not just the miner) must process them. So miners collect rewards while others bear most costs - a classic "tragedy of the commons."

^In theory, this works if miners have equal power and no non-mining nodes exist. Reality is messier: mining is concentrated, many non-mining nodes bear costs, and bad actors can exploit the system.

Ethereum's modern solution (since 2021):

• Base Fee + Priority Fee: Users pay a mandatory "base fee" (algorithmically set and burned) plus optional "priority fee" (tip for validators). This makes pricing predictable while maintaining incentives.
• Dynamic Blocks: Blocks target 15 million gas but expand to 30 million based on demand. When blocks exceed 50% capacity, base fees auto-increase up to 12.5%; when under 50%, they decrease.
• Gas Limits: Transactions set computational step limits. Block limits adjust gradually through validator consensus.

This provides predictable pricing, reduces volatility, and aligns economics by burning base fees while rewarding validators.

A philosophical overview of gas mechanism

Gas requires Ethereum's native token (Ether), creating a "Token Economy" where network influence requires platform stake. Like governments with national currencies or gaming companies with proprietary tokens, Ethereum uses its native currency to align incentives and coordinate decisions.

^ Note: Unlike centralized entities though, Ethereum's governance is distributed across many decentralized actors.

Section 6: Application on Ethereum - OpenCerts Introduction

The above picture is the summary of today’s content. Now that we have a big picture overview of Ethereum, let’s explore OpenCerts as a real-world application of Ethereum.

^Note: Ethereum is not a collection of 3 independent parts but the orchestration of a network of actors who have overlapping activities across its core mechanisms (in fact, there are more than 3 key components, one big mechanism we are leaving out here is tokenomics of Ether, the native coin of Ethereum). When we talk about “Ethereum Blockchain”, we are referring to it in its entirety!

Section 7: OpenCerts 

OpenCerts is an open-source platform developed by GovTech Singapore, primarily for securely issuing academic certificates. Key features include: (i) Schema for credential issuance (ii) Cryptographic protection tools for generating credentials (iii) Web-based verification system

Safety, Authenticity and Why:

• Personal data isn't stored directly on-chain; only a certificate hash (Keccak-256) is recorded, preserving privacy and security.
• Certificates can be copied but not altered without verification failure. Note: Even if the verification server goes down, the person can always present the original content and regenerate the hash.
• Future plans involve Distributed IDs for enhanced authentication.
• Blockchain reduces publishing costs and removes the need for centralized verification infrastructure.

Hash: A hash function turns any input into a fixed-size, unique-looking output. It’s one-way, fast, and collision-resistant.

Keccak-256: Ethereum chose Keccak-256 (a SHA-3 finalist) for its strong security, resistance to length-extension attacks, and flexible sponge construction. Unlike SHA-256 (used in Bitcoin), Keccak allows variable-length input and better suits Ethereum’s needs. It was also widely available when Ethereum launched. Note: Other hash functions were either less secure, less flexible, slower, or already broken (e.g., MD5, SHA-1).

Section 8: Technical Breakdown of OpenCerts

Only a 256-bit Merkle root hash is stored on Ethereum, generated using Keccak-256. Workflow: (A) Raw Document → (B) Wrapped Document + Merkle Root → (C) Document Store Smart Contract.

Source: https://www.opencerts.io/ 

Section 9: Merkle Root & Merkle Trees

Merkle Trees allow for efficient verification of large datasets by hashing individual data elements, pairing these hashes, and repeatedly hashing pairs until a single, fixed-size hash value (Merkle Root) remains. This root summarizes the entire dataset and allows secure verification of individual elements without revealing the whole dataset. Verification can also be done with a small amount of data.

Example: OpenCerts

• Each student’s academic certificate generates an individual hash (T1-T5).
• These certificate hashes are recursively paired and hashed, eventually generating a Merkle Root representing the entire graduating cohort.
• Only this Merkle Root is stored on Ethereum within a Document Store Smart Contract, significantly minimizing blockchain storage requirements.

To verify any specific certificate (e.g., T3/H3), only its hash and necessary intermediate hashes (like H4 and H(1,2)) are required, this is efficient and private for others. Merkle Trees are crucial because they provide secure, scalable, and efficient methods for verifying large datasets, making them essential for blockchain-based solutions like OpenCerts.Note: All states in the blockchain are stored in Merkle Trees.

Why Merkle Tree and Not Other types?

In DBs like SQL and MongoDB, data is organized using B-trees. These trees are optimized for efficient storage, searches, and range queries, but they are not designed for cryptographic integrity or tamper-proof verification.

Ethereum, operates in a decentralized and trustless environment - needs efficient verifiability. It uses a Merkle Patricia Trie (MPT)—a hybrid of Merkle trees and Patricia tries—to store and manage data. Each node in an MPT is hashed, and changes propagate up to the root hash, allowing for efficient proofs of data inclusion and integrity.

Unlike B-trees, MPTs allow any participant to independently verify that a piece of data belongs to the blockchain state without needing the entire dataset. While MPTs are more complex and computationally intensive due to hash recalculations, they are essential for ensuring data security, verifiability, and decentralization on Ethereum.

Section 10: More Applications

While the Ethereum whitepaper focuses on decentralized applications (dApps), smart contracts, and financial use cases, Ethereum has grown into a broader platform supporting many new applications:

1. DeFi (Decentralized Finance): A full ecosystem of lending, trading, and yield strategies without banks—built entirely on smart contracts.
2. Stablecoins (Cryptocurrencies like USDT & USDC which are pegged to the US Dollar): The potential for flat infrastructure and highly efficient payment rails. An International wire transfer can cost anywhere from $30 or more, which much of onchain transfers cost less than a dollar, with some exception of high network usage (this is where Layer 2 Scaling come into the picture).
3. NFTs (Non-Fungible Tokens): Used for digital art, gaming items, music, collectibles, and even real-world assets like property and event tickets.
4. DAOs (Decentralized Autonomous Organizations): Online communities and projects that use Ethereum smart contracts for governance and funding decisions.
5. Layer 2 Scaling: Networks like Optimism and Arbitrum run on top of Ethereum, offering faster and cheaper transactions while settling back to the main chain.
6. Social and Identity: Decentralized social media (e.g., Lens Protocol) and identity tools (like ENS and soulbound tokens) that give users more control over their online presence.
7. Real-World Integration: Supply chain tracking, carbon credits, and tokenized assets (like real estate or stocks) are starting to use Ethereum for transparency and trust.

Section 11: Further Readings

• EIP & ERC (https://shardeum.org/blog/eip-and-erc/)

• Ethereum Improvement Proposals (EIPs) are formal suggestions for changes or additions to the Ethereum protocol. ERCs (Ethereum Request for Comments) are a subset of EIPs that define standards for application-level features, like tokens or smart contract interfaces. For example, ERC-20 defines how fungible tokens behave, while ERC-721 defines NFTs. These standards help ensure interoperability across the Ethereum ecosystem.

• Block building – Execution Clients (https://www.blocknative.com/blog/ethereum-block-building)

• Execution clients are software that validate and execute Ethereum transactions and smart contracts. They're responsible for building blocks by selecting transactions from the mempool, executing them, and packaging the results into a block. Clients like Geth, Nethermind, and Besu are examples. Proper block building ensures the network stays secure, accurate, and up-to-date.

• MEV & Mempool (https://info.arkm.com/research/beginners-guide-to-mev)

• The mempool is a temporary holding area for unconfirmed transactions. Miners or validators pick from it when building new blocks. MEV (Maximal Extractable Value) refers to the extra profit they can make by reordering, including, or excluding certain transactions—especially in DeFi. While MEV can be lucrative, it also raises fairness and security concerns.

• Layer 2s (https://www.coinbase.com/en-sg/learn/crypto-basics/what-are-ethereum-layer-2-blockchains-and-how-do-they-work)

• Layer 2 solutions are built on top of Ethereum to handle transactions off-chain, reducing fees and improving speed while still leveraging Ethereum’s security. These systems batch many transactions together and post summaries or proofs to the main chain. Popular Layer 2s include Optimism, Arbitrum, and Base.

• Zero Knowledge Proofs & Optimistic Rollups (https://www.chainalysis.com/blog/zero-knowledge-rollups-optimistic-rollups-overview/) 

• These are two major Layer 2 scaling techniques. Optimistic Rollups assume transactions are valid by default and allow fraud proofs if something goes wrong. Zero-Knowledge (ZK) Rollups use cryptographic proofs to show transactions are valid without revealing details. Both methods help Ethereum scale while keeping it secure and decentralized.

 

References

https://ethereum.org/en/whitepaper/ 

https://www.opencerts.io/faq/ 

https://docs.opencerts.io/docs/ 

https://github.com/OpenCerts/open-certificate 

https://www.openattestation.com/docs/ethereum-section/overview-eth 

 

SEVEN Blockchain <> Whitepaper Reading Clubtouch on brieflytouch on briefly