This article was kindly contributed by Klaytn Developer Ambassador yhc125 (GitHub / LinkedIn).
Security, transparency, and verifiable true randomness are core attributes that blockchain networks constantly work to improve upon, and one technology that aims to address some of these issues has recently been gaining traction—the Boneh-Lynn-Shacham (BLS) signature scheme.
Most famously, Ethereum’s Phase 2.0 Beacon Chain uses this BLS signature scheme to handle validator consensus, and implements randomness through a Verifiable Random Function (VRF). On the Beacon Chain, submitted signatures are accumulated over time to eventually generate a random value at a point in time that is transparently verifiable and tamper-proof.
Inspired by Ethereum’s use of the BLS signature scheme, KIP-113 and KIP-114 were created to propose the use of BLS signature on Klaytn. KIP-113 proposes a mechanism to verify the identity of nodes through public key registration based on BLS signatures, and KIP-114 proposes to introduce two new fields in the block header to generate random values that can be verified on-chain.
In this article, we’ll briefly touch on the BLS signature scheme and then cover KIP-113 and KIP-114 in turn.
Understanding BLS signatures
BLS signatures have two main advantages over ECDSA: smaller signature data and signature aggregation.
Before comparing the two algorithms, we will first need to understand an important concept in elliptic curve cryptography (ECC): the generator.
A generator is a point on a particular elliptic curve. This point is used to generate all other points on the elliptic curve. This is done by a multiplicative operation (doubling), where the generator is ‘added’ a certain number of times (where ‘adding’ refers to a special ‘addition’ operation on the elliptic curve), and the corresponding other points on the elliptic curve are generated.
To generate the public key, the private key—a random number—is multiplied by the generator, with the resulting point being the public key.
Here’s a comparison of each process in [Figure 1].
- EC Group(s): In ECDSA, generators are created through elliptic curves of the p256, secp256k1 type, but in BLS Signature, they are typically constructed from two generators, G1 and G2, using the BLS12-381 elliptic curve. G1 and G2 are then used to generate the signature and public key.
- Key generation: Both ECDSA and BLS Signature generate a public key as the product of a private key and a generator point on the chosen elliptic curve. The private key is a random integer chosen from a finite group of integers over a selected elliptic curve.
- Sign (for msg): In ECDSA, the signature generation process is slightly more complicated. The signer uses the secret key and a random number along with a hash of the message to generate the signature. In BLS, on the other hand, signature generation is relatively straightforward. The signer uses only the hash of the message and the secret key to generate the signature. As a result, BLS signature data is noticeably smaller in size, at 48 bytes versus 64 bytes for ECDSA signature data.
- Verification: Both ECDSA and BLS require the recipient to verify the signature using the original message, the signature, and the signer’s public key. However, the process is slightly different. ECDSA performs an operation and division, and then checks to see if the result matches the value provided by the signer. BLS uses a pairing check to verify that the signature is valid.
Before we carry on, we will need to circle back to the signature sizes. While in point 3 we mentioned that the size of the BLS signature data is 48 bytes and thus smaller than ECDSA, the BLS signature data on Ethereum’s consensus layer and that represented by KIP-113 and KIP-113 is actually 96 bytes. This is because there are two variants of the BLS signature scheme , one with a smaller public key size (min-pubkey-size) and one with a smaller signature data size (min-signature-size).
When you generate a public key with G1, it’s called min-pubkey-size type, and when you generate a signature with G1, it’s called min-signature-size type. Depending on whether you need to minimize the size of the signature or the public key, you can simply place the element to be minimized as G1 and the other as G2.
For Klaytn, because the validators’ public keys are stored in the smart contract and Klaytn chain, and will undergo frequent cryptographic operations while proposing blocks and validating and verifying transaction, reducing the size of public keys to speed up computations is a more efficient choice than reducing the size of signature data.
The other key advantage of BLS signatures is the ability to aggregate signatures. Signature aggregation means that multiple signatures can be combined into a single signature, and this combined signature provides the same level of security as validating all the individual signatures. ECDSA, on the other hand, does not have this aggregation capability.
This feature is used for block validation in Ethereum’s consensus layer, reducing the storage space to 1/N compared to N using ECDSA. [Figure 2] shows how signature aggregation works when N people sign the same message.
For a more detailed explanation, along with the general concept of ECC, please refer to the following article: Upgrading Ethereum, Part 2.9.1: BLS Signatures
KIP-113
KIP-113 proposes a mechanism to verify the identity of nodes through public key registration based on BLS signatures, with the BLS12-381 registry designed to take advantage of BLS signatures’ unique benefits.
This may seem similar to Klaytn’s AddressBook smart contract that records the address and node ID of each node on the Klaytn blockchain, KIP-113 is not meant to replace AddressBook. The purpose of AddressBook is to help nodes find and communicate with each other on the Klaytn network, while KIP-113 is meant to complement it by facilitating the use of BLS in various components, including the prevention of Rogue Key Attacks and KIP-114, which we will be covering further down in this article.
To perform the intended functions, the KIP-113 registry contract will implement the IKIP-113 interface to register and manage BLS public keys, proof-of-ownership information, and more. The BlsPublicKeyInfo structure of the BLS12-381 public key defined in IKIP-113 contains two main elements:
- publicKey: The compressed BLS12-381 public key, which is 48 bytes in size.
- pop: stands for Proof-of-Possession, and is 96 bytes in size. This must result from the PopProve algorithm specified in Section 3.3.3 of draft-irtf-cfrg-bls-signature-05.
Proof-of-Possession (PoP) is a mechanism for proving that a participant submitting a public key actually owns the private key corresponding to that key. This plays an important role in preventing Rogue Key Attacks, in which an attacker attempts to compromise a group’s entire signature by injecting a maliciously manipulated public key into the network. It is important to note that while PoPs validate public keys to prevent such attacks, due to the current absence of EIP-2537, this validation must be performed off-chain.
KIP-114
In a nutshell, KIP-114 proposes to introduce two new fields in the block header to enable the generation of Verifiable Random Numbers.
A Verifiable Random Number is a random number whose authenticity can be verified without human intervention. On the Ethereum Beacon Chain, this is calculated by implementing VRF in a RANDAO fashion, but for KIP-114, it will be done by implementing mixHash to generate a Verifiable Random.
To accomplish this, KIP-114 proposes the addition of two new fields to the block header: randomReveal and mixHash. randomReveal is the proposer’s signature, and is generated using the BLS signature scheme standardized by KIP-113. Validators can then obtain the proposer’s public key and proof-of-possession (pop) using the getInfo(cnNodeId) function of the KIP-113 BLS registry, and use the pop to validate the proposer’s public key and verify that the randomReveal is signed by the correct private key of the proposer.
mixHash is then generated by XORing the keccak256 hash of the randomReveal value of the block being proposed with the mixHash of the previous block. If the previous block was a FORK_BLOCK, it must be followed by a mixHash value consisting of 32 bytes of zeros. The resulting mixHash provides a verifiable and reliable source of randomness. In this way, KIP-114 aims to provide random, verifiable and unbiased random values on the blockchain.
One particular use case for this would be for block proposers who want to remain private until the previous block is completed, or if we want the proposer to be unable to intervene in the selection of the next block proposer—which has been submitted as KIP-146, which proposes a policy for randomly selecting a block proponent, implemented using mixHash.
As a quick recap, here’s the process again:
- The Block Proposer generates a randomReveal using the BLS signature scheme. This value is included in the block header as the proposer’s unique signature.
- Validators obtain the proposer’s public key and pop from the BLS registry.
- Validators use the pop to validate the proposer’s public key and verify that the randomReveal is signed by the proposer’s private key.
- The validators compute a mixHash by mixing multiple randomReveal values and the mixHash of the previous block.
KIP-114 also specifies security considerations that must be taken into account during the above process.
- Replay Attacks: To prevent attacks where a block proponent reuses a randomReveal value from a previous block, the randomReveal value used in each block must be unique. This prevents a block proponent from manipulating the mixHash by reusing their own previous randomReveal value.
- Honesty of Block Proposer: Requires the proposer to honestly generate and submit their own randomReveal. If a proposer manipulates their randomReveal value, the resulting mixHash value can be manipulated as well. Therefore, a proposer must honestly provide all the information needed to compute the mixHash from their randomReveal without manipulating it.
- Secrecy of randomReveal Before Block Proposal: The proposer must keep their randomReveal value secret until the block proposal. This prevents other participants from predicting the proposer’s randomReveal value and using it to manipulate the mixHash.
- Validation of randomReveal: The randomReveal value must be signed by the proposer’s public key and validated by the validator. This prevents the proposer from manipulating or tampering with their randomReveal value.
With this, we hope that you have gained a deeper understanding of the Boneh-Lynn-Shacham (BLS) signature scheme and why its unique benefits made it the best choice for the Ethereum consensus layer, and consequently KIP-113 and KIP-114. We hope this article has given you an insight into the current direction of Klaytn core development, and helped you understand the overall development and future of blockchain technology.
