-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
29 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
<pre> | ||
WIP: WIP-0002 | ||
Layer: Consensus (hard fork) | ||
Title: Coexistence of BLS and Secp256k1 keys | ||
Author: Gorka Irazoqui <gorka@stampery.co> | ||
Discussions-To: `#dev-general` channel on Witnet Comunnity's Discord server | ||
Status: Draft | ||
Type: Standards Track | ||
Created: 2020-04-24 | ||
License: BSD-2-Clause | ||
</pre> | ||
|
||
## Abstract | ||
|
||
This proposal discusses different options to handle both BLS and Secp256K1 keys in the Witnet network. This is a key feature for the connection with Ethereum, in particular to achieve high efficient verifications with subsidized curves by the EVM. | ||
|
||
Nothe that the co-existence of different elliptic curve keys will be crutial in Witnet in order to develop bridges with other chains. For the purpose of the document, we will only discuss the co-existence between Secp256k1 and ALTBN-128, being the latter subsidized in the EVM. However, this WIP can serve as a proposal for adding new curves to Witnet. | ||
|
||
## Motivation and Rationale | ||
|
||
Implementing one-way decentralized bridges between two chains becomes a task that higly depends on the consensus protocol implemented by the chain whose transactions need to be verified. We will call this chain the source chain, while the chain in which the transactions are verified will be refered as the target chain. | ||
|
||
Assuming the existence of the source chain block headers in the target chain, one can easily verify that a transaction occurred in the source chain. Typically transactions are grouped in a merkle tree whose root is appended into the block header. Thus, a prover just needs to provide a valid merkle path to the merkle root to prove a transaction ocurred. | ||
|
||
However, ensuring the availability of the block headers in the target chain is not that straight-forward, specially for non-PoW chains. PoW achieves probabilitistic finality thanks to the difficulty of reverting a chain with sufficient work on it, a difficulty that is publicly verifiable. In order to validate new block headers from chains whose consensus relies on an intra-chain metric (stake, reputation) based BFT algorithm the target chain needs to know the previous state of such metrics in the source chain. In the particular case of Witnet, we need to prove that at least 2/3 of the ARS (active reputation) supports a certain block header in order to consider it valid (or more specifically, final). This can become trully challenging in terms of efficiency. | ||
|
||
BLS signatures allow us to aggregate signatures provided by those members of the ARS. The overall aggregated signature can be validated in the target chain in a single verification. However, a BLS verification is 10 times more costly than a regular ECDSA verification. Thus, BLS gives us a big advantage for bridging with other chains, but little advantage when using it to intra-chain sign transactions. | ||
|
||
In consequence, we need to derive a way to make both BLS and ECDSA algorithms co-exist in Witnet. This proposal introduces different solutions to such problem. |