WIP-girazoki-multikey: draft submission #22

girazoki · 2020-04-24T14:39:43Z

Close #24

mariocao · 2020-04-24T14:48:15Z

wip-0003.md

+
+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.


Suggested change

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.

Note that 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.

mariocao · 2020-04-24T14:51:54Z

wip-0003.md

+
+## 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.


Suggested change

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.

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*.

mariocao · 2020-04-24T14:53:47Z

wip-0003.md

+
+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.


Suggested change

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.

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, to prove a transaction you just need to provide a valid merkle path to the merkle root.

mariocao · 2020-04-24T14:58:35Z

wip-0003.md

+
+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. 


Suggested change

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.

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 set) supports a certain block header in order to consider it valid (or more specifically, final). This can become truly challenging in terms of efficiency.

I would be a little bit more generic with the specific conditions for a block valid (e.g. 2/3 of the ARS). They are not yet fully agreed. :P

mariocao · 2020-04-24T15:02:16Z

wip-0003.md

+
+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.


Suggested change

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.

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 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_.

I would rephrase the first sentence, e.g. "BLS curves allows us to aggregate signatures such as those provided by ARS members", or something like that 😄

aesedepece · 2020-04-25T12:16:41Z

I have renamed the PR to "WIP-girazoki-multikey" as provided for by WIP-0001:

[drafts] must be written in WIP style as described below, and named with an alias such as "WIP-champion-feature" until the editor has assigned it a WIP number (authors MUST NOT self-assign WIP numbers).

A WIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.

When the WIP draft is complete, the WIP editor will assign the WIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the WIPs git repository.

aesedepece · 2020-04-27T12:19:48Z

wip-0003.md

+
+## 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.


Suggested change

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.

This proposal discusses different options to handle both BLS and Secp256K1 keys in the Witnet network. This is a key feature for interoperability with Ethereum, in particular to achieve highly efficient signature verifications by leveraging the curves that the EVM subsidizes.

aesedepece · 2020-04-27T12:21:39Z

wip-0003.md

+
+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.
+
+Note that 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.


Suggested change

Note that 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.

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.

aesedepece · 2020-04-27T12:28:47Z

wip-0003.md

+
+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 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, to prove a transaction you just need to provide a valid merkle path to the merkle root to prove a transaction ocurred.


Suggested change

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, to prove a transaction you just need to provide a valid merkle path to the merkle root to prove a transaction ocurred.

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.

aesedepece · 2020-04-27T12:33:17Z

wip-0003.md

+
+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, to prove a transaction you just need 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, it is yet not decided which metric to use, but under BFT assumptions we can expect 2/3s of such metric holders to be honest, and therefore a block header validity will likely depend on the ability to demonstrate that those 2/3s agree on a specific value. This can become trully challenging in terms of efficiency. 


Suggested change

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, it is yet not decided which metric to use, but under BFT assumptions we can expect 2/3s of such metric holders to be honest, and therefore a block header validity will likely depend on the ability to demonstrate that those 2/3s agree on a specific value. This can become trully challenging in terms of efficiency.

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.

aesedepece · 2020-04-27T12:38:19Z

wip-0003.md

+
+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, it is yet not decided which metric to use, but under BFT assumptions we can expect 2/3s of such metric holders to be honest, and therefore a block header validity will likely depend on the ability to demonstrate that those 2/3s agree on a specific value. This can become trully 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 fo 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_.


Suggested change

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 fo 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_.

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_.

aesedepece · 2020-04-27T12:41:01Z

wip-0003.md

+
+However, note that the reputation is today associated to the PKH 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, UTXOs are also associated with the PKH of the Secp256k1 public key. Given the clear overhead of implementing a BLS verification compared to a ECDSA verification, UTXOs should keep being spendable by secp256k1 private key holders.


Suggested change

Additionally, UTXOs are also associated with the PKH of the Secp256k1 public key. Given the clear overhead of implementing a BLS verification compared to a ECDSA verification, UTXOs should keep being spendable by secp256k1 private key holders.

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.

aesedepece · 2020-04-27T12:42:39Z

wip-0003.md

+## 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.
+
+However, note that the reputation is today associated to the PKH 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.


Suggested change

However, note that the reputation is today associated to the PKH 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.

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.

aesedepece · 2020-04-27T12:43:47Z

wip-0003.md

+
+#### 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 can be extended to the struct TotalReputationSet:


Suggested change

**`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 can be extended to the struct TotalReputationSet:

**`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 extension of the `TotalReputationSet` structure:

tmpolaczyk · 2020-04-27T14:10:48Z

wip-0003.md

+
+```rust
+// Everything here is pseudo-Rust, it's obviously not guaranteed to compile
+struct TotalReputationSet {


Suggested change

struct TotalReputationSet {

struct ActiveReputationSet {

The ARS is mentioned earlier, so why do we use the TRS here?

AFAIK the ARS contains the active identities, but the isnt the information of the reputation hold by each identity stored in totalreputationset? I might be wrong here, it would be good if we can clarify a bit more. Since the key is information associated with each pkh, I thought it should be in the same place where the reputation of each identity is stored

There is a small problem with storing the public key in the TRS: identities with null reputation aren't stored there. So for example an identity that mines a block is counted as "active", but has no extra reputation.

We can change the behavior of the TRS to include active identities, or we can store this map in a separate structure.

Interesting, lets use a different structure then. However that means that one should include the BLS key also when proposing a block correct?

Yes, let's just include the BLS key with the VRF proof, since that's the only way to enter the ARS.

Great, agree

mariocao · 2020-05-06T09:11:48Z

wip-0003.md

+    DataRequestEligibilityClaim proof = 3;
+    repeated Input inputs = 4;
+    repeated ValueTransferOutput outputs = 5;
+    Bn256PublicKey bn256_pub_key = 6;


I suggest using extended naming as I think we are doing in the rest of witnet-rust code:

Suggested change

Bn256PublicKey bn256_pub_key = 6;

Bn256PublicKey bn256_public_key = 6;

mariocao · 2020-05-06T09:12:48Z

wip-0003.md

+Extending such functionality to be able to associate a secp256k1 public key to an additional curve key should be as simple as creating declaring an struct with all curves we want to store the public key for.
+
+``` rust
+struct BlsKeys {


Why only BLS curves?
Maybe in the future we might want have other curve types.

Maybe something like:

Suggested change

struct BlsKeys {

struct AdditionalKeys {

mariocao · 2020-05-06T09:13:29Z

wip-0003.md

+
+

Suggested change

mariocao

Just a few comments about variable names as they will be implemented in the witnet-rust code.

mariocao · 2020-05-06T14:00:55Z

wip-0003.md

+Extending such functionality to be able to associate a secp256k1 public key to an additional curve key should be as simple as creating declaring an struct with all curves we want to store the public key for.
+
+``` rust
+struct AltKeys {


Suggested change

struct AltKeys {

struct AltPublicKeys {

girazoki · 2020-05-14T08:47:51Z

Completed. Can I get a WIP number?

aesedepece · 2021-01-12T07:24:23Z

Merged in 0265e64. @girazoki you can request moving this to proposed at any time now.

girazoki force-pushed the multi_key branch 2 times, most recently from 0e69ab1 to e79aea1 Compare April 24, 2020 14:41

mariocao suggested changes Apr 24, 2020

View reviewed changes

aesedepece changed the title ~~WIP: feat: wip3 abstract and rationale~~ wip-girazoki-multikey: draft submission Apr 25, 2020

aesedepece marked this pull request as draft April 25, 2020 12:10

aesedepece changed the title ~~wip-girazoki-multikey: draft submission~~ WIP-girazoki-multikey: draft submission Apr 25, 2020

girazoki force-pushed the multi_key branch 5 times, most recently from 1bbc595 to 170f735 Compare April 27, 2020 09:44

tmpolaczyk mentioned this pull request Apr 27, 2020

Assess multi-key identities witnet/witnet-rust#1179

Closed

aesedepece requested changes Apr 27, 2020

View reviewed changes

tmpolaczyk reviewed Apr 27, 2020

View reviewed changes

girazoki force-pushed the multi_key branch 4 times, most recently from 4b36f40 to 7e7e788 Compare May 4, 2020 15:12

mariocao reviewed May 6, 2020

View reviewed changes

wip-0003.md Outdated

Comment on lines 132 to 133

Copy link

Contributor

mariocao May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

mariocao suggested changes May 6, 2020

View reviewed changes

girazoki force-pushed the multi_key branch 2 times, most recently from e447c76 to 74dfc9e Compare May 6, 2020 13:40

mariocao reviewed May 6, 2020

View reviewed changes

girazoki force-pushed the multi_key branch from 259343a to 666d0c3 Compare May 7, 2020 09:13

feat: wip3 multi-key

74582bc

girazoki force-pushed the multi_key branch from 666d0c3 to 74582bc Compare May 7, 2020 14:00

aesedepece closed this Jan 12, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP-girazoki-multikey: draft submission #22

WIP-girazoki-multikey: draft submission #22

girazoki commented Apr 24, 2020 •

edited by aesedepece

Loading

mariocao Apr 24, 2020

mariocao Apr 24, 2020

mariocao Apr 24, 2020

mariocao Apr 24, 2020

mariocao Apr 24, 2020

aesedepece commented Apr 25, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

aesedepece Apr 27, 2020

tmpolaczyk Apr 27, 2020

girazoki Apr 27, 2020

tmpolaczyk Apr 27, 2020

girazoki Apr 28, 2020

tmpolaczyk Apr 28, 2020

girazoki Apr 28, 2020

mariocao May 6, 2020

mariocao May 6, 2020

mariocao May 6, 2020

mariocao left a comment

mariocao May 6, 2020

girazoki commented May 14, 2020

aesedepece commented Jan 12, 2021


		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.

	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.
	Note that 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 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.


		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.


		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.


		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.


		## 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.

	Note that 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.
	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.


		However, note that the reputation is today associated to the PKH 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, UTXOs are also associated with the PKH of the Secp256k1 public key. Given the clear overhead of implementing a BLS verification compared to a ECDSA verification, UTXOs should keep being spendable by secp256k1 private key holders.

	Additionally, UTXOs are also associated with the PKH of the Secp256k1 public key. Given the clear overhead of implementing a BLS verification compared to a ECDSA verification, UTXOs should keep being spendable by secp256k1 private key holders.
	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.

	However, note that the reputation is today associated to the PKH 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.
	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.


		#### 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 can be extended to the struct TotalReputationSet:

	Bn256PublicKey bn256_pub_key = 6;
	Bn256PublicKey bn256_public_key = 6;

WIP-girazoki-multikey: draft submission #22

WIP-girazoki-multikey: draft submission #22

Conversation

girazoki commented Apr 24, 2020 • edited by aesedepece Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aesedepece commented Apr 25, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mariocao left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

girazoki commented May 14, 2020

aesedepece commented Jan 12, 2021

girazoki commented Apr 24, 2020 •

edited by aesedepece

Loading