Technical Background
In B2 Sidechain, all transactions are being signed by the ECDSA signature algorithm which is described in following subsection. The raw transaction is first digested by the hash function (Keccak), and then the hash value is signed by the sender’s private key through ECDSA. The current version of Parlia consensus does not provide fast finality because one validator produces a block, and to make sure of the correctness of these operations, one has to wait for the long confirmation time, usually it is
where
enotes the active validators. Aggregated signature mechanism with Parlia’s fast-finality can solve this problem because one can collect and convert many signatures into one aggregated signature and send only this aggregated signature to the chain. For the aggregated signature, some special elliptic curves such as BLS12381 or BN256 will be used.
A cryptographic hash function
takes an arbitrary-length message and outputs a fixed-length output. A hash function has the following basic properties:
· Deterministic: Given
, we always have
(the same input
always results in the same output
).
· Efficient: it is very fast to compute the hash value for any given message.
· Pre-image resistance (one-wayness): For essentially all pre-specified outputs, it is computationally infeasible to find any input which hashed to that output.
· Second pre-image resistance It is computationally infeasible to find a second message that produces the same hash value.
· Collision resistant: It is also hard to find two arbitrary inputs
and
that hash to the same value, i.e.,
.
Let’s assume that
is order point,
and
are two points on an elliptic curve, and
is a base point. The ECDSA signature algorithm can be described as follows:
Key generation:
1. Select a random number
in the interval
.
2. Compute
3. Public key is
, private key is
.
Signature generation:
1. Select a random integer
,
.
2. Compute
and convert
to an integer
.
3. Compute
. If
then go to step 1.
4. Compute
.
5. Compute
and convert this bit string to an integer
.
6. Compute
. If
then go to step 1.
7. Signature for the message
is
.
Signature verification:
1. Verify that
and
are integers in the interval
.
2. Compute
and convert this bit string to an integer
.
3. Compute
.
4. Compute
and
.
5. Compute
.
6. If
then reject the signature. Otherwise, convert the
-coordinate
of
to an integer
, and compute
.
BLS (Boneh, Lynn, Shacham) is another digital signature introduced in 2001 and has an aggregated structure. Let
be a pairing where
are additive groups and
is a multiplicative group. Also, let
and
are base elements of
and
respectively.
Public and Private Key Pair
:
· The private key
to be used for signing is just a randomly chosen number between
.
· The corresponding public key is
.
Signing:
· To sign a message
we first need to map
onto a point in group
. Let’s assume this mapping results in a
point
.
· We sign the message by calculating the signature
.
Verification:
Given a message
, a signature
, and a public key
, we want to verify that it was signed with the
.
· The signature is valid if, and only if,
.
Aggregation
· To aggregate signatures, we just must add up the
points they correspond to:
.
· We also aggregate the corresponding
public key point
.
· Verify that
to verify all the signatures together with just two pairings.
BN256 is basically the size of the prime number of the underlying field in
and
. In a BN256 curve,
is basically
is a subgroup of
and
is a subgroup of
. Elements of
requires the same number of bits as
for each elliptic curve point. We would like to highlight that not all prime-friendly curves support cofactor 1. This means that we may need a larger prime for a particular group order in some cases. Elements of
require the same as
for each elliptic curve point coordinate, where
is the embedding degree of the curve. When using twisted curves, we can reduce this by 2, 3, 4, or 6 depending on the curve. BN curves have embedding degree 12 and support twists, therefore we can use elements with the same size as
.
Last modified 1yr ago