Exploring BLS Keys on the Harmony Protocol: Understanding Generation, Management, and Use Cases

By: Casey Gardiner

The Harmony Protocol is a cutting-edge blockchain platform that utilizes the latest advancements in distributed systems and cryptography to provide a decentralized, secure, and scalable infrastructure for decentralized applications (dApps). Among the various features that make up the Harmony Protocol, one of the most important is the use of BLS (Boneh-Lynn-Shacham) keys, a type of digital signature scheme based on elliptic curve cryptography.

BLS keys offer several advantages over traditional digital signature schemes. They provide a higher level of security and are particularly well-suited for use in consensus algorithms and staking mechanisms. The BLS signature scheme is a relatively new technique and is considered a state-of-the-art standard for providing secure multi-party computations. BLS signatures have several advantages over traditional digital signature schemes, such as the ability to aggregate multiple signatures into a single one and verify multiple signatures in parallel. Utilizing these properties allows the Harmony Protocol to achieve a high degree of scalability and increased throughput while maintaining a high level of security.

BLS keys also play a critical role in providing privacy and security for smart contract execution on the Harmony Protocol. With the use of BLS keys, smart contract transactions can be processed more privately and securely, as the BLS signature scheme allows for the use of a small and fixed-size signature which is much smaller than the traditional ECDSA or RSA signature, which makes it more efficient in terms of space and time.

This post aims to provide readers with a thorough understanding of BLS keys on the Harmony Protocol and how they help to secure, scale and achieve the decentralization goals of Harmony. The purpose of this document is to provide a comprehensive overview of BLS keys on the Harmony Protocol. We will explore the background and fundamentals of BLS key generation and management and the various use cases of BLS keys on the Harmony Protocol. We will also cover advanced topics such as multi-signature, key delegation, and threshold signature. In this document, we will also dive into the technicalities of the BLS signature scheme and its underlying mathematics that are used to achieve the security and scalability goals of the Harmony Protocol.

BACKGROUND

Cryptography Concepts: Public-key cryptography and elliptic curve cryptography are the two main concepts that form the foundation for BLS keys. Public-key cryptography allows for using two different keys for encrypting and decrypting messages.

A common example of a public-key encryption algorithm is RSA, in which a message, M, is encrypted with a public key, e, to produce a ciphertext, C, and decrypted with a private key, d, to recover the original message. Mathematically, encryption can be represented as:

Where M is the original message, C is the encrypted message, e and d are the public and private keys, respectively and n is the modulus.

Elliptic curve cryptography (ECC) is another important concept that forms the foundation of BLS signatures. ECC is a method for generating a shared secret key from two separate keys. This is achieved by selecting a suitable elliptic curve, and a point on that curve called a generator point and then using it to generate a public and private key.

Mathematically, a point, P, on an elliptic curve can be represented as:

Where x and y are the coordinates of the point P, G is the generator point and k is the private key.

BLS Signature Scheme: BLS signatures are a digital signature scheme based on elliptic curve cryptography. The BLS signature scheme is based on the concept of pairing, a mathematical operation that takes two points on an elliptic curve and produces a scalar value.

The mathematical representation of pairing can be shown as follows:

Where e(P,Q) is the pairing function, P and Q are two points on the elliptic curve, k is the private key, r is the message to be signed, G is the generator point.

The BLS signature scheme can aggregate multiple signatures into a single one and the ability to verify multiple signatures in parallel. This makes BLS signatures particularly well-suited for consensus algorithms and staking mechanisms.

For example, below is a code snippet in Go Lang to generate a BLS keypair and sign a message using the bls library.

package main

import (
    "fmt"
    "github.com/harmony-one/bls/ffi/go/bls"
)

func main() {
    // Generate a BLS keypair
    sk := bls.RandSecretKey()
    pk := sk.GetPublicKey()

    // Sign a message
    message := []byte("Hello World")
    sig := sk.Sign(message)

    // Verify the signature
    if !pk.VerifyBytes(message, sig) {
        fmt.Println("Invalid signature")
    } else {
        fmt.Println("Valid signature")
    }
}

In this example, we use the bls package from github.com/harmony-one/bls/ffi/go/bls; it is a Go wrapper around the C library, which provides the functionality to generate and sign BLS keys, and also to validate signatures.

The RandSecretKeyfunction generates a new private key, which is then used to generate the corresponding public key using the GetPublicKey function.

The Sign function is used to sign a message using the private key, and the VerifyBytes function is used to verify the signature using the public key and the original message.

BLS Key Generation and Management

BLS Key Generation and Management on the Harmony Protocol: BLS keys on the Harmony Protocol are typically generated using an elliptic curve cryptography library, such as the one provided by the bls package. The process starts with selecting a suitable elliptic curve, and then two keys are generated for each party: a public key and a private key. The public key can be shared with others and is used to encrypt messages or verify signatures. In contrast, the private key must be kept secret and used to decrypt messages or create signatures.

The Harmony Protocol uses the BLS key pairs for many different purposes, such as consensus, staking, and smart contract execution. Each party will have its own BLS key pairs for these purposes.

Security considerations for BLS key generation and management:

• BLS keys’ security depends on the private key’s randomness during the key generation process. A cryptographically secure random number generator is essential to generate the private key.

• As BLS private key is critical and should be kept secret, it is necessary to use secure storage mechanisms to store the private key, such as hardware wallets, secure enclaves, or secure elements.

• It is crucial to have a robust key management infrastructure in place to protect private keys from unauthorized access and to ensure that they are only used for the intended purposes.

• Regularly rotating the private key is a best practice for security reasons; it helps to minimize the impact of any potential compromise of the private key.

Tools and libraries for BLS key management:

• The Harmony team provides a set of libraries and command-line tools for BLS key management, such as Go Lang wrapper of the C library, python wrapper of the C library, and CLI tool to interact with keys and keystores.

• Other open-source libraries and tools, such as the bls-signatures library, provide BLS key generation, signing, and verification functionality.

• Additionally, there are various hardware wallets and secure elements that provide support for BLS key management.

Use Cases

BLS Key Use Cases for Consensus and Staking on Harmony: BLS keys play a critical role in the consensus and staking mechanisms of the Harmony Protocol. In the consensus mechanism, BLS keys aggregate multiple signatures from validators into a single signature. This allows for a more efficient verification process and enables the Harmony Protocol to achieve a high degree of scalability and increased throughput.

In the staking mechanism, BLS keys are used to secure the process of creating and validating new blocks on the blockchain. Each validator on the Harmony Protocol has its own BLS key pair, which they use to sign blocks that they propose. Other validators can then use the public key to verify the signature and determine the authenticity of the proposed block.

BLS keys also play a critical role in the execution of smart contracts on the Harmony Protocol. With BLS keys, smart contract transactions can be processed more privately and securely. The BLS signature scheme allows for the use of a small and fixed-size signature much smaller than a traditional ECDSA or RSA signature, making it more efficient in terms of space and time. Additionally, BLS keys can be used to encrypt the data in smart contracts, so that only authorized parties can access it.

BLS keys also allow for using zero-knowledge proofs on the Harmony Protocol, which enables the execution of private smart contracts. With zero-knowledge proofs, the inputs and outputs of a smart contract can be verified without revealing the underlying data. This provides an additional layer of privacy and security for smart contract execution on the Harmony Protocol.

Advanced Topics

Multisignature: In a multisignature scheme, multiple parties must provide their signatures in order for a transaction to be considered valid. This provides an additional layer of security, as an attacker must compromise multiple private keys to execute a fraudulent transaction.

A common example of a multisignature scheme is the threshold signature scheme, where a threshold number of signatures is required for a transaction to be considered valid. Mathematically, a threshold signature scheme can be represented as:

Where S is the resulting signature, s_1, s_2, …, s_n are the private keys of the parties involved, G is the generator point, and n is the threshold number of signatures required.

In Code, an example of a threshold signature scheme in Go Lang could be:

package main

import (
    "fmt"
    "github.com/harmony-one/bls/ffi/go/bls"
)

func main() {
    // Generate threshold number of keypairs
    var keys []bls.SecretKey
    threshold := 3
    for i := 0; i < threshold; i++ {
        keys = append(keys, bls.RandSecretKey())
    }
   // Create a threshold signature
   message := []byte("Hello World")
   var sigs []bls.Sign
   for _, key := range keys {
        sigs = append(sigs, key.Sign(message))
   }
   combinedSig := bls.AggregateSignatures(sigs)
   
   // Verify the threshold signature
   var pubkeys []bls.PublicKey
   for _, key := range keys {
        pubkeys = append(pubkeys, key.GetPublicKey())
   }
   combinedPk := bls.AggregatePublicKeys(pubkeys)

  if !combinedPk.VerifyBytes(message, combinedSig) {
        fmt.Println("Invalid threshold signature")
  } else {
        fmt.Println("Valid threshold signature")
  }

Key-Delegation: Key-delegation is a mechanism that allows for the delegation of signing authority to another party. This is useful in situations where a party does not want to expose its private key but still wants to participate in a consensus or staking mechanism. A common example of key-delegation is a proxy signature scheme, where a party can delegate signing authority to another party by providing them with a proxy signing key. Mathematically, a proxy signature scheme can be represented as:

Where P is the public key of the delegating party, k is the private key of the delegating party, PS is the proxy signing key, G is the generator point, and r is the private key of the delegated party.

In code, an example of key-delegation in Go Lang could be:

package main

import (
    "fmt"
    "github.com/harmony-one/bls/ffi/go/bls"
)

func main() {
    // Generate a keypair for the delegating party
    skDelegator := bls.RandSecretKey()
    pkDelegator := skDelegator.GetPublicKey()

    // Generate a keypair for the delegated party
    skDelegate := bls.RandSecretKey()

    // Generate a proxy signing key
    proxySig := skDelegator.MakeProxySignature(skDelegate.GetPublicKey())

    // Sign a message using the proxy signing key
    message := []byte("Hello World")
    sig := skDelegate.SignWithProxy(proxySig, message)

    // Verify the signature using the delegator's public key
    if !pkDelegator.Verify(message, sig) {
        fmt.Println("Invalid signature")
    } else {
        fmt.Println("Valid signature")
    }
}

Threshold Signature: A threshold signature scheme allows a group of parties to generate a signature on a message where a certain number of parties or a threshold must provide their signatures. This is useful in situations where a high degree of security is required, as an attacker must compromise multiple private keys to execute a fraudulent transaction.

In code, an example of threshold signature in Go Lang could be:

package main

import (
    "fmt"
    "github.com/harmony-one/bls/ffi/go/bls"
)

func main() {
    // Generate threshold number of keypairs
    var keys []bls.SecretKey
    threshold := 3
    for i := 0; i < threshold; i++ {
        keys = append(keys, bls.RandSecretKey())
    }

    // Create a threshold signature
    message := []byte("Hello World")
    var sigs []bls.Sign
    for _, key := range keys {
        sigs = append(sigs, key.Sign(message))
    }
    thresholdSig := bls.ThresholdAggregateSignatures(sigs, threshold)

    // Verify the threshold signature
    var pubkeys []bls.PublicKey
    for _, key := range keys {
        pubkeys = append(pubkeys, key.GetPublicKey())
    }
    thresholdPk := bls.ThresholdAggregatePublicKeys(pubkeys, threshold)

    if !thresholdPk.VerifyBytes(message, thresholdSig) {
        fmt.Println("Invalid threshold signature")
    } else {
        fmt.Println("Valid threshold signature")
    }
}

In this example, a threshold number of keypairs are generated using the blslibrary. The private keys of these keypairs are then used to create a threshold signature using the ThresholdAggregateSignatures function. The resulting threshold signature and the corresponding public keys are then used to verify the signature’s authenticity using the ThresholdAggregatePublicKeysand VerifyBytes functions. It is worth noting that all examples provided are meant to illustrate how these schemes work. However, in real-world use, the implementation of the key generation and signing procedures would depend on the system’s specific requirements and constraints and the libraries being used.

I like making things in MidJourney and thought this was fitting for the BLS topic

CONCLUSION

In this technical post, we discussed BLS keys and their use in the Harmony Protocol. We covered the concepts of public-key cryptography, elliptic curve cryptography, and the BLS signature scheme. We discussed how these concepts are used in generating and managing BLS keys. We also covered advanced topics, such as multisignature, key-delegation, and threshold signature schemes, and provided mathematical equations and coding examples to illustrate their usage.

In summary, BLS keys play a critical role in the consensus, staking, and smart contract execution mechanisms of the Harmony Protocol, providing efficient and secure methods of transaction verification and privacy. Using multisignature, key-delegation, and threshold signature schemes offers additional layers of security and functionality.

Future directions for BLS key research and development on the Harmony Protocol include exploring new and advanced use cases for BLS keys, such as privacy-preserving smart contract execution and secure, off-chain data storage. Additionally, ongoing research and development efforts will focus on the optimization and scalability of the BLS signature scheme, as well as the integration of new cryptographic techniques and advancements in the field. Furthermore, the community will continue to research new methods to balance security and usability in key management, increasing security and making it easier for users to manage their keys.

REFERENCES

• “BLS: Signature of Practical Aggregate Signatures from Bilinear Maps” by Dan Boneh, Ben Lynn, and Hovav Shacham. Advances in Cryptology — CRYPTO 2001, LNCS 2139, pp. 319–334. Springer, 2001.

• “Threshold Signatures, Multisignatures and Blind Signatures based on the RSA Public-Key Cryptosystem” by E. Fujisaki and T. Okamoto. Advances in Cryptology — CRYPTO’97, LNCS 1294, pp. 57–73. Springer, 1997.

• “Short Group Signatures” by Dan Boneh, Xavier Boyen and Hovav Shacham. Advances in Cryptology — EUROCRYPT 2004, LNCS 3027, pp. 56–72. Springer, 2004.

• “Harmony Protocol” by Harmony team.

https://harmony.one/

• “bls” Go Lang library by Harmony team, https://github.com/harmony-one/bls