Exploring BLS Keys on the Harmony Protocol: Understanding Generation, Management, and Use Cases
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:
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:
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:
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 RandSecretKey
function 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:
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:
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 bls
library. 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 ThresholdAggregatePublicKeys
and 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.
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