LOGOS-DIGITAL-SIGNATURE

Timeline

• 2026-05-28 — d45eed2 — Chore: mirror blochain specs into github/mdbook (#347)
• 2026-05-18 — 58b5698 — chore(blockchain): migrate contributor emails to @logos.co (#338)
• 2026-02-09 — afd94c8 — chore: add math support (#287)
• 2026-01-30 — 99ca13a — New RFC: Nomos Digital Signature (#167)

Abstract

This specification describes the digital signature schemes used across different components in the Logos Blockchain system design. Throughout the system, each Logos Blockchain layer shares the same signature scheme, ensuring consistent security and interoperability. The specification covers EdDSA for general-purpose signing and ZKSignature for zero-knowledge proof of key ownership.

Keywords: digital signature, EdDSA, Ed25519, zero-knowledge proof, ZKSignature, cryptography, elliptic curve, Curve25519

Semantics

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Definitions

Background

The Logos Blockchain Bedrock consists of a few key components that Logos Blockchain network is built on. See the Logos Blockchain whitepaper for more information. The Bedrock Mantle component serves as the operating system of Logos Blockchain. This includes facilitating operations like writing data to the blockchain or a restricted ledger of notes to support payments and staking. This component also defines how Logos Blockchain Zones update their state and the coordination between the Logos Blockchain zone executor nodes. It is like a system call interface designed to provide a minimal set of operations to interact with lower-level Bedrock services. It is an execution layer that connects Logos Blockchain services to provide the necessary functionality for sovereign rollups and zones. See Common Ledger specification for more on Logos Blockchain Zones.

In order for the Bedrock layer to remain lightweight, it focuses on data availability and verification rather than execution. Native zones on the other hand will be able to define their state transition function and prove to the Bedrock layer their correct execution. The Bedrock layer components share the same digital signature mechanism to ensure security and privacy. This document describes the validation tools that are used with Bedrock services in the Logos Blockchain network.

Protocol Specification

The signature schemes used by the provers and verifiers include:

• EdDSA Digital Signature Algorithm
• ZKSignature (Zero-Knowledge Signature)

EdDSA

EdDSA is a signature scheme based on elliptic-curve cryptography, defined over twisted Edwards curves. Logos Blockchain uses the Ed25519 instance with Curve25519, providing 128-bit security for general-purpose signing. EdDSA SHOULD NOT be used for ZK circuit construction.

The prover computes the following EdDSA signature using twisted Edwards curve Curve25519:

• The public key size MUST be 32 bytes.
• The signature size MUST be 64 bytes.
• The public key MUST NOT already exist in the system.

ZKSignature

The ZKSignature scheme enables a prover to demonstrate cryptographic knowledge of a secret key, corresponding to a publicly available key, without revealing the secret key itself. The following is the structure for a proof attesting public key ownership:

class ZkSignaturePublic:
    public_keys: list[ZkPublicKey]  # The public keys signing the message
    msg: hash                        # The hash of the message

The prover knows a witness:

class ZkSignatureWitness:
    # The list of secret keys used to sign the message
    secret_keys: list[ZkSecretKey]

Such that the following constraints hold:

1. The number of secret keys is equal to the number of public keys:

assert len(secret_keys) == len(public_keys)

1. Each public key is derived from the corresponding secret key:

assert all(
    notes[i].public_key == hash("LOGOS_KDF", secret_keys[i])
    for i in range(len(public_keys))
)

• The proof MUST be embedded in the hashed msg.

The ZKSignature circuit MUST take a maximum of 32 public keys as inputs. To prove ownership when using fewer than 32 keys, the remaining inputs MUST be padded with the public key corresponding to the secret key 0. These padding entries are ignored during execution. The outputs of the circuit have no size limit, as they MUST be included in the hashed msg.

Security Considerations

Key Management

Secret keys MUST be stored securely and never transmitted in plaintext. Implementations MUST use secure random number generators for key generation.

EdDSA Security

EdDSA provides 128-bit security when used with Ed25519. Implementations MUST validate public keys before use to prevent small subgroup attacks. Signature verification MUST reject malformed signatures.

ZKSignature Security

The ZKSignature scheme relies on the security of the underlying hash function and the zero-knowledge proof system. The hash function used for key derivation (LOGOS_KDF) MUST be collision-resistant. Implementations MUST verify that proofs are well-formed before accepting them.

Replay Protection

Signatures SHOULD include context-specific data (such as timestamps or nonces) to prevent replay attacks across different contexts or time periods.

References

Normative

• RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels

Informative

• Logos Blockchain whitepaper - The Logos Blockchain Whitepaper
• Common Ledger specification - Common Ledger Specification
• Edwards curves - Twisted Edwards Curves

Copyright

Copyright and related rights waived via CC0.