DOCSEARCHbyAlgolia
Submit Docs

ethereum.org Website Documentation

repository·dev·Indexed 27 days ago

https://github.com/ethereum/ethereum-org-website

Source repository for the official Ethereum portal. Includes guides for local development using pnpm, environment configuration, and detailed implementation steps for GDPR-compliant A/B testing using Matomo and Flags SDK. Covers the setup of the Matomo AI Tracker Netlify Edge Function, mock data usage, and component development with Storybook.

Tokens
172.5K
Snippets
298
Records
912
Agent score
88%

What's inside ethereum-org-website

  1. Overview of Ethereum Development Networks

    dev

    Development networks are Ethereum client implementations designed specifically for local development. They allow you to create a local blockchain instance to test dApps before deploying to a public network.

    Key advantages over running a standard node include:

    • Deterministic Seeding: Automatically seeding the blockchain with data, such as accounts with pre-defined ETH balances.
    • Instant Block Production: Producing blocks instantly with every transaction received, with no delay.
    • Enhanced Debugging: Specialized logging and debugging functionality tailored for developers.

  2. Overview of using zero-knowledge for a secret state

    dev

    On-chain games are typically limited because all data posted to a blockchain is public. To implement games requiring hidden information (like Minesweeper), you can combine zero-knowledge proofs with server components.

    In this architecture:

    1. A server component holds the secret state.
    2. The server provides a hash of the state.
    3. Zero-knowledge proofs are used to prove that the state used to calculate the result of a move is the correct one, ensuring the server's honesty without revealing the state itself.

    This approach allows for a verifiable game with a secret state, consisting of a secret-state-holding server, a client for UI, and an on-chain component for communication.

  3. Overview of Decentralized Science (DeSci)

    dev
    Decentralized science (DeSci) is a movement using the Web3 stack to build public infrastructure for funding, creating, reviewing, crediting, storing, and disseminating scientific knowledge. It aims to create a transparent, equitable, and censorship-resistant ecosystem where scientists are incentivized to share research openly and receive credit via decentralized mechanisms like DAOs and quadratic donations.

  4. Overview of Home Staking

    dev

    Home staking involves running an Ethereum node connected to the internet and depositing 32 ETH to activate a validator. This allows you to participate directly in network consensus.

    An Ethereum node requires two components:

    1. Execution Layer (EL) client: Software to verify transactions.
    2. Consensus Layer (CL) client: Software to attest to the chain head, aggregate attestations, and propose blocks.

    Home stakers are responsible for the hardware and software maintenance. Benefits include receiving rewards directly from the protocol without middlemen and maintaining full control over private keys.

  5. Overview of Slither Static Analysis techniques

    dev

    Slither performs static analysis using several code representations and analysis types:

    Code Representations

    • Abstract Syntax Tree (AST): A structured tree used by the compiler for parsing. Slither uses the AST exported by solc.
    • Control Flow Graph (CFG): A graph-based representation that exposes all execution paths. Edges represent control flow (loops, if/else), and nodes contain instructions. Most Slither analyses are built on top of the CFG.
    • SlithIR: An Intermediate Representation (IR) that translates Solidity into a format more amenable to static analysis. This is used for advanced semantic analyses.

    Analysis Types

    • Syntax Analysis: Uses pattern matching to find inconsistencies like state variable shadowing or incorrect ERC20 interfaces.
    • Semantic Analysis: Analyzes the "meaning" of the code. This includes Data Dependency Analysis (tracking how values influence other variables) and Fixed-point Computation (determining when further analysis of a CFG node provides no new information, essential for loop analysis and reentrancy detection).

  6. Overview of Dapp Development Frameworks

    dev

    Software frameworks for Ethereum development provide out-of-the-box functionality to streamline the building of decentralized applications (dapps). Key features typically include:

    • Local Blockchain Instances: Tools to spin up a local network for testing.
    • Smart Contract Utilities: Capabilities to compile and test smart contracts.
    • Client Development: Add-ons to build user-facing applications within the same repository.
    • Network Configuration: Settings to connect to Ethereum networks (local or public) for contract deployment.
    • Decentralized Distribution: Integrations with storage solutions like IPFS.

  7. Overview of the Pectra network upgrade

    dev
    Pectra (Prague-Electra) is a network upgrade that introduced changes to both the execution and consensus layers of Ethereum. It was successfully activated on Ethereum mainnet at epoch 364032 on 07-May-2025 at 10:05 (UTC). The upgrade includes a significant number of EIPs aimed at improving user experience, developer tools, and validator efficiency.

  8. Overview of Ethereum Smart Contract Languages

    dev

    Ethereum smart contracts can be programmed using several languages depending on your experience level and requirements:

    • Solidity: The most common high-level, object-oriented, statically typed language (curly-bracket syntax).
    • Vyper: A Pythonic, strongly typed language designed for security and auditability by intentionally omitting complex features like inheritance and operator overloading.
    • Yul & Yul+: Low-level intermediate languages for the Ethereum Virtual Machine (EVM). Yul is a common denominator for EVM and Ewasm, while Yul+ is a highly efficient extension.
    • Fe: An emerging, statically typed language inspired by Python and Rust, currently in its early stages.

    For beginners, the Remix IDE (https://remix.ethereum.org) provides a comprehensive in-browser environment for creating and testing contracts in both Solidity and Vyper.

  9. Understand Permissionless Deployment on Ethereum

    dev

    Ethereum is a permissionless environment for builders. You can deploy code, call contracts, run nodes, and publish interfaces without requiring partnerships, account approvals, or commercial agreements.

    Key distinction for builders:

    • On-chain: The base execution environment is governed by public rules that apply to all addresses equally. Once deployed, your contract remains accessible as long as the chain runs.
    • Off-chain dependencies: While the protocol is permissionless, users interact via frontends, wallets, and RPC providers. These layers can be subject to censorship or downtime. To mitigate this, developers should consider that users can always interact with contracts directly via a new interface or a different RPC provider if the primary one fails.

  10. Understand the Consensus Layer P2P Network

    dev

    The consensus layer operates on a separate peer-to-peer network from the execution layer. It uses a discovery protocol to find peers and establish secure sessions for exchanging blocks and attestations.

    Key components include:

    • Discovery: Uses discv5 over UDP. Unlike the execution layer, the consensus layer uses an adaptor to connect discv5 into a libP2P stack, deprecating DevP2P.
    • libP2P: Handles all communications after discovery, supporting IPv4 and IPv6 as defined in the node's ENR. It is divided into the Gossip and Request-response domains.
    • Gossip Domain: Uses libP2P gossipsub v1 to rapidly spread information like beacon blocks, proofs, attestations, exits, and slashings. Nodes must store metadata such as maximum gossip payload sizes.
    • Request-response Domain: Used for clients to request specific information (e.g., Beacon blocks by root hash or slot range). Responses are returned as snappy-compressed SSZ encoded bytes.

  11. Use Symbolic Execution to reason about trace-level properties

    dev

    Symbolic execution analyzes smart contracts by executing functions using symbolic values (e.g., x > 5) instead of concrete values (e.g., x == 5).

    Key concepts:

    • Path Predicate: An execution trace is represented as a mathematical formula over symbolic input values.
    • SMT Solver: An SMT (Satisfiability Modulo Theories) solver is used to check if a path predicate is "satisfiable." If a vulnerable path is satisfiable, the solver generates a concrete value that triggers the error.
    • Efficiency: It is more efficient than regular testing for finding specific inputs that trigger property violations and produces fewer false positives than fuzzing.
    • Mathematical Proof: It can provide a degree of mathematical proof of correctness by showing that certain error states (like integer overflows) cannot satisfy the path predicate.
    function safe_add(uint x, uint y) returns(uint z){

  z = x + y;
  require(z>=x);
  require(z>=y);

  return z;
}

  12. Identify bridge types and use cases

    dev

    Bridges are categorized by their architecture and functionality. Choose a type based on your application's requirements for security, connectivity, and data complexity:

    • Native bridges: Built to bootstrap liquidity for a specific blockchain (e.g., Arbitrum Bridge, Polygon PoS Bridge, Optimism Gateway). Best for moving funds into a specific ecosystem.
    • Validator or oracle based bridges: Rely on external validator sets or oracles to verify transfers (e.g., Multichain, Across). Often offer high connectivity and speed but require trusting the external verifiers.
    • Generalized message passing bridges: Support the transfer of assets along with arbitrary data and messages (e.g., Axelar, LayerZero, Nomad). Best for complex cross-chain dapps.
    • Liquidity networks: Focus on asset transfers via atomic swaps (e.g., Connext, Hop). They excel in security and speed but generally do not support cross-chain message passing.