diff --git a/wip-0003.md b/wip-0003.md new file mode 100644 index 0000000..4df0901 --- /dev/null +++ b/wip-0003.md @@ -0,0 +1,136 @@ +
+ WIP: WIP-0003 + Layer: Consensus (hard fork) + Title: Coexistence of BLS and Secp256k1 keys + Author: Gorka Irazoqui+ +## Abstract + +This proposal discusses different options to handle both BLS and Secp256K1 keys in the Witnet network. This is a key feature for the interoperability with Ethereum, in particular to achieve highly efficient signature verifications by leveraging the curves that the EVM subsidizes. + +The co-existence of different curve keys will be crucial 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 highly depends on the consensus protocol implemented by the chain whose transactions need to be verified. We will call this chain the *source chain* (i.e. the _Witnet chain_), while the chain in which the transactions are verified will be referred as the *target chain*. + +Assuming the availability of the source chain's block headers on 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 inserted into the block header. Thus, to prove the existence of a transaction you just need to provide a valid merkle path that evinces that the hash of the transaction was undeniably inserted into the merkle tree at the time the block hash was appended to the source chain.. + +However, ensuring the availability of the block headers in the target chain is not that straightforward, specially for non-PoW chains. PoW achieves probabilistic 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 a BFT algorithm that is based on an intra-chain metric (stake, reputation) the target chain needs to know the previous state of such metrics in the source chain. In the particular case of Witnet, it is yet not decided which metric to use, but under BFT assumptions we can expect 2/3 of such metric holders to be honest, and therefore a block header validity will likely depend on the ability to demonstrate that those 2/3 agree on a specific value. This can become truly challenging in terms of efficiency. + +BLS signatures allow us to aggregate signatures provided by a set of group members. In the case of Witnet, those members will be the ARS, as the consensus of the Witnet chain is highly dependant on the reputation of each of the peers. The overall aggregated signature can be validated in the target chain in a single verification. However, a BLS verification is approximately 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 sign transactions internally in the _Witnet network_. + +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. + +## Requirements +As already said before, we need to maintain a state about the ARS in the block headers that future blocks can be validated upon. Such information will be stored as a merkle root of all the identities and their position in the ARS. + +Note that reputation score is currently associated to the hash of the Secp256K1 public key. However, ARS members in the ARS merkle root should be identifiable by their BLS public key, as this will be used to verify their aggregated signature. + +Additionally, addresses and transaction outputs are also associated with the hash of the Secp256k1 public key. Given the clear overhead of implementing a BLS verification compared to a ECDSA verification, transaction outputs should keep being spendable by secp256k1 private key holders. + +## Proposal: A mapping between Secp256 and BN256 public keys. + +### Specification +Our first proposal is to make every node store a mapping with the relationship between a *Secp256k1* and the *altBN_128* key. + +#### Information storage + +**`secp256k1AltbnMap` mapping.** A new mapping to be stored in memory that is updated every time a new key is proposed. This mapping does not need to be stored on-chain, but can be constructed by information that is on-chain. This can be implemented as an additional mapping to be stored in the chain manager. + +``` rust +type secp256k1AltbnMap = HashMap+ Discussions-To: `#dev-general` channel on Witnet Comunnity's Discord server + Status: Draft + Type: Standards Track + Created: 2020-04-24 + License: BSD-2-Clause +