DOCSEARCHbyAlgolia
Submit Docs

Solana Improvement Documents (SIMD)

repository·main·Indexed 19 days ago

https://github.com/solana-foundation/solana-improvement-documents

The Solana Improvement Documents (SIMD) serve as the central location for standardizing and documenting proposed and accepted changes to the Solana protocol. The repository covers Standard SIMDs (Core, Networking, and Interfaces), Meta SIMDs regarding processes, and Advisory Proposals. It details the proposal lifecycle from idea to activation, the governing process for substantial changes to the Validator, RPC, and consensus, and the repository's access policy.

Tokens
88.6K
Snippets
123
Records
389
Agent score
66%

What's inside solana-improvement-documents

  1. Overview of BLS12-381 Elliptic Curve Syscalls (SIMD 0388)

    main

    SIMD 0388 introduces a new family of syscalls to provide native support for cryptographic operations on the BLS12-381 elliptic curve. This allows BPF programs to perform high-security (128-bit security level) pairing-based cryptography efficiently, which was previously limited to the alt_bn128 (BN254) curve.

    The syscalls cover:

    • Group operations: Addition, subtraction/negation, and scalar multiplication in G1 and G2.
    • Point validation: Verifying points in G1 and G2.
    • Pairing operations: Executing the pairing operation.
    • Decompression operations: Decompressing points in G1 and G2.

    Note: Poseidon hash support is explicitly excluded from this SIMD.

  2. Overview of the Alpenglow Consensus Protocol

    main

    Alpenglow is a core protocol change that replaces the existing Proof-of-History and TowerBFT consensus mechanism. It is designed to provide higher resilience, lower consensus finality latency, and reduced bandwidth and computation overhead.

    Key improvements include:

    • Lower Latency: Actual consensus finality latency is lowered below the pre-confirmation latency of TowerBFT.
    • Efficiency: Decreases bandwidth use by eliminating costly gossip traffic and reduces computation by replacing on-chain signature verification with local signature aggregation.
    • Resilience: Increases resistance to sophisticated attackers, adversarial network conditions, DOS attacks, and crash failures.
    • Incentive Alignment: Removes harmful incentives like waiting to cast more profitable votes.

    Note: This SIMD covers the Votor components of Alpenglow. Other components like Rotor (data dissemination) and Lazy Execution are handled in separate SIMDs.

  3. Use the ZK ElGamal Proof program for application-independent ZK proofs

    main

    The ZK ElGamal Proof program is a general-purpose, application-independent built-in program used to verify zero-knowledge proofs related to ElGamal ciphertexts and Pedersen commitments. It replaces the specialized (and now deprecated) ZK Token Proof program.

    Developers should use this program for verifying proofs that are not strictly tied to the SPL Token program, such as verifying that a ciphertext encrypts zero or verifying percentage relations with caps.

    Program Address: ZkE1Gama1Proof1111111111111111111111111111111

  4. Impact of SIMD 0391 on Stake and Validator components

    main

    The transition from floating-point to fixed-point arithmetic affects several critical areas:

    Stake Program

    • Stake Merging: Used to determine if an account is in a transient state (rejecting merges if not fully active/inactive).
    • Stake Splitting: Used to determine if source stake is active to enforce rent-exempt reserve requirements.
    • Stake Redelegation: Used to confirm effective stake is zero before allowing redelegation.
    • Stake Withdrawal: Used to determine remaining effective stake during deactivation.

    Validator Clients (Agave & Firedancer)

    • Stake Activation/Deactivation: Computing how much stake has completed warmup/cooldown by walking through epochs.
    • Epoch Boundary Stake History: Summing per-delegation activation statuses to produce cluster-wide totals.
    • Stake Cache Updates: Computing effective stake contributions before/after changes to vote accounts.
    • Vote Account Stake Totals: Summing effective stake of all delegations to determine leader schedule weights and fork choice power.
    • Inflation Rewards: Computing the effective stake for each epoch in a vote account's credit history (note: the downstream reward-to-lamport conversion remains unchanged).

  5. BN254 G2 Arithmetic Syscalls (SIMD-0302)

    main

    SIMD-0302 extends the existing sol_alt_bn128_group_op syscall to provide native support for G2 curve point arithmetic on the BN254 curve. This allows for efficient addition, subtraction, and scalar multiplication of G2 points directly via syscalls, which is significantly faster than software-based implementations.

    Key Capabilities:

    • G2 Addition/Subtraction: Perform arithmetic on G2 points.
    • G2 Scalar Multiplication: Perform scalar multiplication on G2 points.
    • Performance: Reduces compute unit consumption by approximately 10×–20× compared to pure BPF implementations.
    • Use Cases: Batch Groth16 verification, KZG polynomial commitment schemes (multi-point opening proofs and batch verification), and advanced ZK systems.

  6. Upgrade BPF Stake Program to v5.0.0

    main

    SIMD 0490 upgrades the Core BPF Stake Program to version 5.0.0. This upgrade introduces a higher minimum delegation threshold, changes how rent is calculated, and optimizes instruction inputs.

    Key Changes:

    • Minimum Delegation: The minimum delegation required to create a new stake account is raised from 1 lamport to 1 sol.
    • Rent Calculation: The program now uses the Rent sysvar instead of Meta.rent_exempt_reserve. The rent_exempt_reserve for new stake accounts is fixed at 2_282_880 (the current reserve for a 200-byte account) to prevent breakage.
    • Optional Sysvars: All sysvar account inputs are now optional. The program remains backwards compatible with instructions that still include them.
    • Split Implementation: The Split processor has been rewritten to fix bugs. Notably, attempting to split a stake account into itself is now an error.
    • Merge Behavior: When calling Merge on two activating stakes, all lamports from the source account are now merged into the destination, rather than just the source delegation and rent_exempt_reserve.

  7. SIMD 0307: Add Block Footer

    main

    SIMD 0307 proposes adding a block footer to Solana blocks and exposing the footer fields via the getBlock RPC endpoint. This provides a reliable, static way to identify the block producer and the exact timing of block production, addressing limitations in current gossip-based or vote-timestamp-based monitoring methods.

    Key improvements include:

    • Reliable identification of the Block Producer (the client that produced the block).
    • Precise block production timing (improving upon the 1-second granularity of vote timestamps).
    • Availability of metadata such as the Scheduler used, mods, and configuration settings.
    • Persistence of information that is currently ephemeral in Gossip.

  8. Use secp256r1 (NIST P-256) Curve Syscalls

    main
    The secp256r1 (NIST P-256) curve is supported via Solana's generalized sol_curve_* syscall family. This allows BPF programs to perform low-level elliptic curve operations including group operations, multiscalar multiplication (MSM), point validation, and decompression. This is particularly useful for implementing WebAuthn, Passkeys, or migrating cryptographic precompiles into standard BPF programs.

  9. Impact of SIMD-0189 on dApp development

    main
    The restrictions imposed by SIMD-0189 are designed to be transparent to dApp developers. The toolchain linker is updated with a new linker script to ensure that generated ELF files automatically adhere to the stricter header requirements. Section headers are ignored, allowing arbitrary metadata to remain encoded there without affecting compliance.

  10. What is the Accounts Lattice Hash and how does it work?

    main

    The Accounts Lattice Hash is a new mechanism used to maintain a hash of the total account state on Solana. Unlike previous Merkle-based methods (like the Epoch Accounts Hash), it uses homomorphic hashing (specifically a lattice-based function called LtHash) to allow for incremental updates.

    Key Characteristics:

    • Incremental Updates: The total account state hash for a new block can be computed by taking the previous block's hash and applying only the changes (additions and subtractions) from the current block.
    • Efficiency: It removes the need to sort accounts by public key, which significantly improves scalability for billions of accounts.
    • Replacement: It replaces the Epoch Accounts Hash in the bank hash, providing a total account state hash in every block rather than once per epoch.
    • Limitation: Unlike Merkle trees, the Accounts Lattice Hash does NOT support inclusion or exclusion proofs.

  11. What is a Core BPF Program?

    main

    A Core BPF Program is a BPF program that is essential to the operation of the Solana network. These programs are relied upon by critical components of the stack, including consensus, transaction processing, voting, staking, and account creation.

    Previously, these essential programs existed as "native" programs built directly into the validator runtime. The transition to Core BPF programs allows these essential functions to be updated once as BPF programs rather than requiring every validator client implementation to manually update their internal runtime code.

  12. What is the Feature Gate program and its purpose?

    main

    The Feature Gate program is a Core BPF program deployed at the address Feature111111111111111111111111111111111111.

    Its primary purpose is to provide a mechanism for core contributors to revoke pending feature activations. Previously, feature accounts were assigned to a non-existent program address, making queued activations irreversible. By implementing a live BPF program at this address, engineers can manage the cadence and schedule of activations, providing a safeguard against mistaken queuing or discovered bugs.