Skip to content

Migrate Hedera-Cryptography Repo to Hiero #220

@Mark-Swirlds

Description

@Mark-Swirlds

This proposal is to transfer the project https://github.com/hashgraph/hedera-cryptography to Hiero.

Current project location & resources
https://github.com/hashgraph/hedera-cryptography
TSS Design Proposal
TSS Whitepaper
Suggested name under Hiero
hiero-Cryptography
Supporters of the project
Hashgraph
jasperpotts
nathanklick
mxtartaglia-sl
anthony-swirldslabs

Project Description
TSS Summary
In the Hiero networks, the current approach for signing blocks in the V6 record stream involves each node using RSA signatures on record file hashes, as per HIP-415. A record is only valid if the total number of RSA partial signatures from nodes meets or exceeds a majority of network consensus weight.

However, this method is inefficient: it requires verifiers to track node RSA keys and consensus weight from the network address book, scales poorly with network size (as signature size and verification effort grow linearly with nodes), and isn't feasible for verification on EVM chains due to lacking native support.

To address these issues, a new threshold signature scheme (TSS) called hinTS is proposed in HIP-1200, which serves as an advanced encryption method for nodes to collectively sign blocks within the upcoming blockstream (as outlined in HIP-1056). This TSS also enables verifiers to efficiently confirm the validity of these signed blocks through compact, aggregated signatures & proofs.

In practice nodes will use BLS combined with "hinTS" (lightweight, granular weighting system to indicate the consensus weight of an individual node’s signature. Nodes use TSS to sign blocks, allowing the network to demonstrate that a majority of nodes (based on consensus weight) have signed off (attested) to an individual block. Verifiers can then use these BLS + hints elements to prove that the block has been signed by the required threshold of nodes.

Additionally, a SNARK (Succinct Non-interactive Argument of Knowledge) proof of the Hedera address book contents. This is often referred to as the “WRAPS” proof. It is used by the verifier to ensure that the nodes contributing to the BLS + hints signature are indeed valid (listed in the network's address book) and collectively hold the necessary consensus weight to meet the majority consensus weight threshold.

TSS will be rolled out alongside the introduction of blockstreams, enhancing overall network efficiency.

Repo Summary
The Hedera Cryptography repository provides implementations of TSS. The repo includes the following projects:

  • cryptography/hedera-cryptography-hinTS: HinTS API that enables participants to calculate hints, generate keys, and produce and verify aggregate signatures using BLS-based techniques.
  • cryptography/hedera-cryptography-rpm: History API (WRAPS) that allows participants to generate and verify recursive proofs for AddressBooks, ensuring tamper-proof historical data.
  • common/hedera-common-nativesupport: A helper library providing support for JNI (Java Native Interface) and external libraries to facilitate native integrations.

The repository is structured in a modular fashion, separating cryptographic implementations from common support utilities. It is primarily written in languages suitable for cryptographic primitives (e.g., likely Java or C++ based on JNI support), with a focus on API clarity and extensibility. The architecture includes:

  • Core Cryptography Layer: Handles BLS-based operations like key generation, signature aggregation, and proof verification.
  • API Layer: Provides user-facing interfaces for HinTS and RPM functionalities.
  • Native Support Layer: Manages JNI interactions and external library dependencies.
  • Utility Components: Shared helpers for common tasks across projects.

This modularity ensures easy extension and maintenance, allowing contributors to focus on specific cryptographic components without affecting the overall structure.

State of the project
The core libraries within the Hedera Cryptography repository, including the HinTS API for BLS-based threshold and aggregate signatures, the RPM API for recursive proofs, and the native support helper library, have reached development completion. These components are now ready for integration and testing phases. The repository is poised for inclusion in Hiero consensus node builds in the near future, pending successful validation and integration efforts.
Personas
The repository serves several key personas in the Hedera ecosystem:
Release Engineers: Engineers responsible for build pipelines for Hiero Consensus Nodes. The cryptographic libraries will be essential for Hiero Consensus Node operations once block streams are introduced.
Block Verifiers: Developers, service providers, and mirror node developers creating robust software for verifying aggregate signatures and historical proofs.
Open Source Contributors: Researchers and external developers interested in advancing BLS and threshold signature technologies, experimenting with Hiero-specific implementations or want to contribute directly to development of Hiero TSS.
Releases
As a work-in-progress repository originating from an internal proposal, there have been no formal releases to date. Development has focused on iterative improvements to the core APIs and helper libraries, with future releases planned to include versioned packages for easier integration.

Contributors
anthony-swirldslabs
Mxtartaglia-sl
Andrewb1269hg
Jjohannes
Rsinha
Rbarker-dev
Rbarker-dev
Nathanklick
Timo0
PavelSBorisov
Litt3
Mishomihov00

Vision of the project
The long-term vision for Hedera Cryptography is to become a foundational open-source library for all cryptographic software required for Hiero ecosystems. By providing reliable, efficient tools for aggregate signatures and recursive proofs, the project aims to bolster network security, facilitate developer adoption, and support advanced features like block streams and block nodes.

Moving the project to the Hiero namespace now will foster community contributions, standardize cryptographic practices across Hedera applications, and prevent fragmentation of necessary Github organizations required to build Hiero components.

Metadata

Metadata

Assignees

No one assigned

    Labels

    project proposalProposal for adding a project to Hiero

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions