Make BEEFY client able to generate either ECDSA or (ECDSA,BLS) Finality proof. #13311

drskalman · 2023-02-04T09:37:23Z

To enjoy the benefit and efficiency of APK proof for light client we need BEEFY to generate BLS signatures. We also like ECDSA signature because they are easier to verify both for the gossiper and for the Ethereum light client. This PR makes BEEFY Gadget generic over the signing key and signature and implement tests for both proofs signed only by ECDSA and also for proofs signed by ECDSA and BLS keys.

It implements #10469 as a side effect.

- break the 85000 char line in the commitment test multiple lines.

- remove H256, H512 unused hash types from bls

… skalman-bls-beefy

…lock conflict

bls_verify` - implement bls wrapper for application-crypto

aggregatble signature. - Flexiblize Witness to have different Aggregator (either Merkle or BLS).

… keystore

because it is not possible with bitfield aggregation. Compiles but tests do not compile yet.

using bls aggregator

…an/substrate into skalman-bls-beefy-client

CryptStoe into approperate key store.

serban300

I left a couple of comments. Most of them are about some duplicated code that's a result of previous implementations. But I think it would be better to fix them in a separate PR that would be smaller and easier to review.

serban300 · 2023-02-06T07:40:22Z

Cargo.toml

@@ -321,3 +321,15 @@ inherits = "release"
 lto = "fat"
 # https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units
 codegen-units = 1
+
+[patch.crates-io]
+bls-like = {git = "https://github.com/w3f/bls", branch = "skalman-hash-to-curve-wb"}


Nit: This doesn't seem to be needed since everywhere it's used like bls-like = {git = "https://github.com/w3f/bls", branch = "skalman-hash-to-curve-wb"}. However it would make sense to use it like bls-like = {git = "https://github.com/w3f/bls", branch = "master"} in other places in which case, this patch would be needed.

Also is this library reviewed and production-ready ? Or should we also review it ?

I'd probably deprecate that whole crate myself. It's a legacy design that pre-dates our gossip optimizations in https://eprint.iacr.org/2022/1611 and the apk proofs work.

As syed do the hash-to-curve work, it should work fine, and comply with the proposed standard such as it is, but it makes verifying BLS signatures quite slow (like everyone else's BLS.. We know how to do this faster.

serban300 · 2023-02-06T08:21:02Z

primitives/core/src/bls.rs

+
+	/// Verify a signature on a message. Returns true if the signature is good.
+	fn verify<M: AsRef<[u8]>>(sig: &Self::Signature, message: M, pubkey: &Self::Public) -> bool {
+		Self::verify_weak(&sig.0[..], message.as_ref(), pubkey)


Nit: message.as_ref() doesn't seem to be needed. We can just use message.

serban300 · 2023-02-06T08:47:15Z

primitives/core/src/bls.rs

+}
+
+#[cfg(feature = "full_crypto")]
+impl TraitPair for Pair {


Some methods seem to be duplicated for bls, ecdsa and ed25519. So maybe we could have a default definition for them on the TraitPair trait.

For example:

generate_with_phrase

also from_seed could be defined on TraitPair with some small modifications:

fn from_seed(seed: &Self::Seed) -> Self { Self::from_seed_slice(seed.as_ref()).expect("seed has valid length; qed") }

from_phrase as well with some small modifications

derive() could be deduplicated as well if we define for example a BaseDeriveError that is common to all structs implementing TraitPair.

Maybe other methods can be deduplicated as well.

serban300 · 2023-02-06T14:05:30Z

primitives/core/src/bls.rs

+	fn try_from(data: &[u8]) -> Result<Self, Self::Error> {
+		if data.len() != Self::LEN {
+			return Err(())
+		}
+		let mut r = [0u8; Self::LEN];
+		r.copy_from_slice(data);
+		Ok(Self::unchecked_from(r))
+	}


This logic seems the same as the one for ed25519 and sr25519. Maybe we could move it to a shared method or a trait.

serban300 · 2023-02-06T14:10:29Z

primitives/core/src/bls.rs

+	fn try_from(data: &[u8]) -> Result<Self, Self::Error> {
+		if data.len() == BLS377::SIGNATURE_SERIALIZED_SIZE {
+			let mut inner = [0u8; BLS377::SIGNATURE_SERIALIZED_SIZE];
+			inner.copy_from_slice(data);
+			Ok(Signature(inner))
+		} else {
+			Err(())
+		}
+	}


This logic seems the same as the one for ed25519 and sr25519. Maybe we could move it to a shared method or a trait. In general I would deduplicate as much as possible.

serban300 · 2023-02-06T14:49:12Z

primitives/beefy/src/witness.rs

@@ -57,18 +60,18 @@ impl<TBlockNumber, TMerkleRoot> SignedCommitmentWitness<TBlockNumber, TMerkleRoo
 	/// and a merkle root of all signatures.
 	///
 	/// Returns the full list of signatures along with the witness.
-	pub fn from_signed<TMerkelize, TSignature>(
+	pub fn from_signed<TSignatureAggregator, TSignature, TAggregatableSignature>(


Nit: TAggregatableSignature doesn't seem to be used

It was supposed to be populated by apk prover after the received enough signatures (see the test) because multiple aggregations can not be aggregated.

Nonetheless, I think we might the commitment here instead.

hmm maybe you mean in this function? isn't the return value of TAggregatableSignature type?

hmm maybe you mean in this function?

Yes, exactly

isn't the return value of TAggregatableSignature type?

Doesn't seem to be used for the return type. If I understand correctly, TAggregatedSignature is used in the return type. And the code compiles without it.

serban300 · 2023-02-06T15:03:43Z

client/keystore/src/local.rs

+	fn bls_public_keys(&self, key_type: KeyTypeId) -> Vec<bls::Public> {
+		self.0
+			.read()
+			.raw_public_keys(key_type)
+			.map(|v| {
+				v.into_iter()
+					.filter_map(|k| bls::Public::from_slice(k.as_slice()).ok())
+					.collect()
+			})
+			.unwrap_or_default()
+	}


This code seems similar with the one used for ecdsa, ed25519, sr25519. I would try to deduplicate it. For example I would define a method:

fn public_keys<Public: ByteArray>(&self, key_type: KeyTypeId) -> Vec<Public> { self.0 .read() .raw_public_keys(key_type) .map(|v| { v.into_iter() .filter_map(|k| Public::from_slice(k.as_slice()).ok()) .collect() }) .unwrap_or_default() }

on LocalKeystore and then I would reimplement:

fn ecdsa_public_keys(&self, key_type: KeyTypeId) -> Vec<ecdsa::Public> { self.public_keys::<ecdsa::Public>(key_type) } ... fn bls_public_keys(&self, key_type: KeyTypeId) -> Vec<bls::Public> { self.public_keys::<bls::Public>(key_type) }

serban300 · 2023-02-06T15:04:25Z

client/keystore/src/local.rs

+	fn bls_generate_new(
+		&self,
+		id: KeyTypeId,
+		seed: Option<&str>,
+	) -> std::result::Result<bls::Public, TraitError> {
+		let pair = match seed {
+			Some(seed) => self.0.write().insert_ephemeral_from_seed_by_type::<bls::Pair>(seed, id),
+			None => self.0.write().generate_by_type::<bls::Pair>(id),
+		}
+		.map_err(|e| -> TraitError { e.into() })?;
+
+		Ok(pair.public())
+	}


The same comment as the one for bls_public_keys. I would try to deduplicate this code.

serban300 · 2023-02-06T16:55:42Z

client/beefy/src/keystore.rs

+		let own_ecdsa_key = self.both().0.authority_id(&ecdsa_pubkeys);
+		let own_bls_key = self.both().1.authority_id(&bls_pubkeys);


I see that for this keystore the key is made of a BLS key and a ECDSA key. Do this 2 keys need to be matching somehow (generated from the same seed or something) ? If they need to be matching, does this logic here guarantee that we are retrieving 2 matching keys from the ECDSA keystora and BLS keystore ?

Do this 2 keys need to be matching somehow (generated from the same seed or something) ?

afaict, it's immaterial if the seeds/privkeys are distinct since to the outside, what matters is the registered ECDSA & BLS pubkeys. if there's need for more, you could achieve this with a dleq proof.

serban300 · 2023-02-06T17:02:30Z

client/beefy/src/communication/request_response/outgoing_requests_engine.rs

+	_auth_id: PhantomData<AuthId>,
+	_signature: PhantomData<TSignature>,
+	_keystor: PhantomData<BKS>,


I saw a couple of places where we have fields declared like this. Do we plan to use them in the future or is it just a way of declaring phantom data?

If we plan to use them in the future, I think it would be helpful to write in the description of the PR what is the current status, what remains to be done, and maybe also mark the PR as a draft if needed.

drskalman · 2023-02-08T11:07:45Z

primitives/beefy/src/witness.rs

+			//we are going to aggregate the signatures here
+			let mut aggregatedsigs: SignatureAggregatorAssumingPoP<BLS377> =
+				SignatureAggregatorAssumingPoP::new();
+			sigs.iter().filter_map(|sig| {


not only I assumed the commitment is the aggregated signature, I tought is should be computed only by the prover not each validator. I think @AlistairStewart says that this is the commitment and it should be computed and sign by all validators:

I added the commitment to the set of public keys here: https://github.com/paritytech/substrate/pull/13311/files#diff-90d0377841064e4bcca6f0956bf16bd71e11159f9dd6d5975b91f2b4d901b0a4R200

It is not clear for me where it should be actually computed and updated.

Lederstrumpf

main requested change is using consistent naming conventions; I'm otherwise happy with direction of the PR :)

Lederstrumpf · 2023-02-14T08:10:41Z

client/beefy/src/keystore.rs

+	/// Check if the keystore contains a private key for one of the public keys
+	/// contained in `keys`. A public key with a matching private key is known
+	/// as a local authority id.
+	///
+	/// Return the public key for which we also do have a private key. If no
+	/// matching private key is found, `None` will be returned.
+	fn authority_id(&self, keys: &[(ECDSAPublic, BLSPublic)]) -> Option<Self::Public> {


this currently checks though whether both keys are present, else returning None. So either expressed intent or impl should be adjusted.

Lederstrumpf · 2023-02-14T08:21:11Z

client/beefy/src/keystore.rs

+		let own_ecdsa_key = self.both().0.authority_id(&ecdsa_pubkeys);
+		let own_bls_key = self.both().1.authority_id(&bls_pubkeys);


Do this 2 keys need to be matching somehow (generated from the same seed or something) ?

afaict, it's immaterial if the seeds/privkeys are distinct since to the outside, what matters is the registered ECDSA & BLS pubkeys. if there's need for more, you could achieve this with a dleq proof.

Lederstrumpf · 2023-02-14T08:36:20Z

primitives/keystore/src/lib.rs

+		id: KeyTypeId,
+		public: &bls::Public,
+		msg: &[u8],
+	) -> Result<Option<bls::Signature>, Error>;
 }


nit: in the same spirit as @serban300's deduplication recommendation elsewhere, since the function interfaces look the same here, I'd unify all the SIGSCHEME_{public_keys, generate_new, sign...} implementations with generic function interfaces and concrete instantiations for every signature scheme.

Lederstrumpf · 2023-02-14T08:39:07Z

primitives/core/Cargo.toml

@@ -50,6 +50,10 @@ schnorrkel = { version = "0.9.1", features = [
 	"preaudit_deprecated",
 	"u64_backend",
 ], default-features = false, optional = true }
+bls-like = {git = "https://github.com/w3f/bls", branch = "skalman-hash-to-curve-wb", default-features = false}
+#bls-like = {version="*", default-features = false }


nit:

Suggested change

#bls-like = {version="*", default-features = false }

or replace the actual bls-like dependency once your branch is merged.

Lederstrumpf · 2023-02-14T08:59:35Z

primitives/beefy/src/commitment.rs

+	struct BLSAggregatableSignature(BLSSignature);
+
+	#[derive(Clone, Debug, PartialEq, codec::Encode, codec::Decode)]
+	struct ECDSABLSSignaturePair(ecdsa_crypto::Signature, BLSSignature);


nit: concatenation ECDSABLS is hard to decipher. I'd either go with ECDSAnBLS/BLSnECDSA, as you've done here and here, or break style convention with #[allow(non_camel_case_types)] & BLS_ECDSA_SignaturePair, which I find useful for crypto acronyms.

Lederstrumpf · 2023-02-14T09:22:47Z

client/beefy/src/keystore.rs

+impl BeefyBLSnECDSAKeystore {
+	fn both(&self) -> (BeefyECDSAKeystore, BeefyBLSKeystore) {
+		(BeefyECDSAKeystore(self.0.clone()), BeefyBLSKeystore(self.0.clone()))


you're using both ...BLSnECDSA... and ...ECDSAnBLS... for naming. Here for instance as elsewhere, the ordering of the tuple is in fact (...ECDSA..., ...BLS...). This seems prone to developer bugs whenever type system doesn't come to the rescue, so I'd stick with one of the naming conventions. I'd personally prefer alphabetically BLS then ECDSA, but ECDSA then BLS requires less refactoring.

Lederstrumpf · 2023-02-14T09:26:07Z

client/beefy/src/keystore.rs

-			&sig.clone().into(),
-			&msg,
-			&Keyring::Alice.public().into(),
+	/// Auxiliray tairt for ECDSAnBLS


Suggested change

/// Auxiliray tairt for ECDSAnBLS

/// Auxiliary trait for ECDSAnBLS

burdges · 2023-02-19T11:23:59Z

I've not kept up with this sorry.

Are BLS signatures being gossiped as DLEQ proofs? If not, do we have a migration path?

A: Nope & nope. Ideally we'd benchmark this to see if its really worthwhile, but maybe we'll be lazy and not do this ever. I donno..

Are BLS public keys also DLEQ proofs? If not, do we have a migration path?

A: Nope & nope. This seems essential, as hash-to-G2 is extremely slow.

What curves are being used?

A: BLS12-377 but Alistair recently changed his mind, and wants BLS12-381. Otoh hash-to-G2 maybe makes more sense for Ethereum, since they fucked ups themselves and picked hash-to-G2.

acatangiu

I suggest you move non-beefy-specific BLS support to a new PR that we can review and merge to substrate/master without worrying about breaking BEEFY.

I'm referring to the generic BLS (bls12-377 in particular) support. So that would be changes under:

client/keystore/
primitives/application-crypto/
primitives/core/
primitives/io/
primitives/keystore/

Then we can focus on the integration with BEEFY.

@drskalman wdyt?

burdges · 2023-02-24T00:34:29Z

primitives/core/src/testing.rs

@@ -25,6 +25,8 @@ pub const ED25519: KeyTypeId = KeyTypeId(*b"ed25");
 pub const SR25519: KeyTypeId = KeyTypeId(*b"sr25");
 /// Key type for generic ECDSA key.
 pub const ECDSA: KeyTypeId = KeyTypeId(*b"ecds");
+/// Key type for generic BLS12-377 key.
+pub const BLS: KeyTypeId = KeyTypeId(*b"bls7");


We'll likely choose bls12-381 over bls12-377 now.

burdges · 2023-02-24T00:42:17Z

primitives/beefy/src/witness.rs

+	};
+	use bls_like::{
+		pop::SignatureAggregatorAssumingPoP, EngineBLS, SerializableToBytes, Signed, BLS377,
+	};


I see pub type BLS377 = UsualBLS<ark_bls12_377::Bls12_377, ark_bls12_377::Config>; and UsualBLS uses 48 byte keys and hashes-to-G2, but..

We do not want to hash-to-G2. We want to both hash-to-G1 and also run apk proofs on G1.

This requires that public keys be on both G1 and G2 and contain a DLEQ proof between them. This is the point of https://eprint.iacr.org/2022/1611

…PK prover

drskalman · 2023-02-24T17:56:35Z

primitives/beefy/src/mmr.rs

+#[derive(Debug, Default, Clone, PartialEq, Eq)]
+pub struct AuthoritySetCommitment(pub KeysetCommitment);
+
+impl Encode for AuthoritySetCommitment {


I did haphazard job implementing Scale for the APK Commitment so I can compile the code. I'm sure someone else on the team knows better how to implement Scale and Serialization related stuff, so please have a go at it.

Related to this, @swasilyev is reluctant to add Scale to KeysetCommitment as it is substrate specific. Plus we should have Scale for Arkworks' CanonicalSerialize as we are scaling arkworks object other place (like new crypto host function for pairing etc).

drskalman · 2023-02-24T18:11:17Z

I've not kept up with this sorry.

Are BLS signatures being gossiped as DLEQ proofs? If not, do we have a migration path?

A: Nope & nope. Ideally we'd benchmark this to see if its really worthwhile, but maybe we'll be lazy and not do this ever. I donno..

Are BLS public keys also DLEQ proofs? If not, do we have a migration path?

A: Nope & nope. This seems essential, as hash-to-G2 is extremely slow.

What curves are being used?

A: BLS12-377 but Alistair recently changed his mind, and wants BLS12-381. Otoh hash-to-G2 maybe makes more sense for Ethereum, since they fucked ups themselves and picked hash-to-G2.

Nope & Yes: changing what our "BLS Signature" is, is quite trivial not changing anything in BEEFY, and we have no plan to activate the bls host function so this should not make any problem.
Nope and Yes: This PR is mainly about BEEFY being able to generate messages supporting more than one cryptographic scheme in each message. It does little for that cryptographic scheme to be supported in rest of substrate.
I'd stay with BLS12-377 till BW6 is implemented for BLS12-381 and BLS12-381 is supported by APK proof, otherwise we will be blocked to test anything.

drskalman · 2023-02-24T18:17:30Z

I suggest you move non-beefy-specific BLS support to a new PR that we can review and merge to substrate/master without worrying about breaking BEEFY.

I'm referring to the generic BLS (bls12-377 in particular) support. So that would be changes under:
client/keystore/
primitives/application-crypto/
primitives/core/
primitives/io/
primitives/keystore/
Then we can focus on the integration with BEEFY.

@drskalman wdyt?

I agree. Still we need a generic BLS12-377 signer/verifier to be able to run the beefy tests (unless we want to simulate it with BEEFY with let say (ECDSA, ED25519) crypto but that sound like a terrible idea and lots of wasted of time and energy) I'll make another PR to improve BLS crypto and do not bother the beefy team with it. We can put a warning on the bls crypto modules that they are not production ready meannwhile.

drskalman · 2023-02-24T18:28:04Z

primitives/beefy/src/witness.rs

 	/// The full content of the commitment.
 	pub commitment: Commitment<TBlockNumber>,

 	/// The bit vector of validators who signed the commitment.
 	pub signed_by: Vec<bool>, // TODO [ToDr] Consider replacing with bitvec crate

-	/// A merkle root of signatures in the original signed commitment.
-	pub signatures_merkle_root: TMerkleRoot,


According to @andresilva the Merkle root of validator set is not part of the beefy message and so adding multiple commitment to the validator set doesn't affect BEEFY messages size. But I'm confused here as it seems to me that it is included here. Isn't SignedCommitmentWitness being being gossiped?

burdges · 2023-02-24T22:01:33Z

Alright, we do not need a migration path here because we'll only keep the overall framework for doing two BEEFY signatures, and the actual BLS code here can be entirely replaced before going to kusama, yes? Cool

serban300 · 2023-02-28T09:55:14Z

@drskalman if you didn't start working on the deduplication comments that I left and if it's ok for you, I would be interested in implementing them myself in a separate PR sine I have some ideas there. Please just let me know. Thanks !

- rename TAggregatableSignature to TSignatureAccumulator. - Fix and pass all tests in primites/beefy. - remove unused TAggregatableSignature type

paritytech-cicd-pr · 2023-03-13T20:26:05Z

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2517257

…3311 applied to master's head

stale · 2023-04-14T05:17:16Z

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

acatangiu · 2023-04-28T11:12:05Z

We'll reopen when we get there

* Cherry pick all crypto related changes from pull-request #13311 applied to master's head * Import some stuff just if 'full_crypto' is on * Remove copyright year * Cleanup * First generic BLS draft * Finalize generic implementation * Restore tests * Fix rust docs * Fix after master merge * Fix after master merge * Use double bls with G1 as signature group and verify individual signatures using DLEQ proof. * Fix inclusions and types used within substrate * Remove unused cruft * Restore usage of upstream crates * Fix test * Reduce the diff by aligning Cargo.lock to master * Application-crypto provides bls381 * Implement bls381 for local keystore * Use new generic keystore features * import DoublePublickey[Scheme] from the bls-like root to be less confusing. * fix compilation * Apply suggestions from code review Co-authored-by: Robert Hambrock <roberthambrock@gmail.com> * Clean leftovers * - update bls test vector after applying spec change recommendation. - send message as ref. * Different hard junction ids for different bls12 types * update to new bls-like * bls-like → w3f-bls * Make clippy happy * update test vector after replacing hash and crop with hash to field. * cargo fmt * account for #13972 * hide BLS behind "bls_non_production" feature flag * Remove Cargo.lock entries duplicated in merge * add bls377 to primitives/keystore and client/keystore add bls377 to primitives/application-crypto/ add bls_non_production to primitives/keystore and client/keystore bump up w3f-bls version * rename feature `bls_non_production` to `bls-experimental` --------- Co-authored-by: Davide Galassi <davxy@datawok.net> Co-authored-by: André Silva <andrerfosilva@gmail.com> Co-authored-by: Robert Hambrock <roberthambrock@gmail.com>

* Cherry pick all crypto related changes from pull-request paritytech#13311 applied to master's head * Import some stuff just if 'full_crypto' is on * Remove copyright year * Cleanup * First generic BLS draft * Finalize generic implementation * Restore tests * Fix rust docs * Fix after master merge * Fix after master merge * Use double bls with G1 as signature group and verify individual signatures using DLEQ proof. * Fix inclusions and types used within substrate * Remove unused cruft * Restore usage of upstream crates * Fix test * Reduce the diff by aligning Cargo.lock to master * Application-crypto provides bls381 * Implement bls381 for local keystore * Use new generic keystore features * import DoublePublickey[Scheme] from the bls-like root to be less confusing. * fix compilation * Apply suggestions from code review Co-authored-by: Robert Hambrock <roberthambrock@gmail.com> * Clean leftovers * - update bls test vector after applying spec change recommendation. - send message as ref. * Different hard junction ids for different bls12 types * update to new bls-like * bls-like → w3f-bls * Make clippy happy * update test vector after replacing hash and crop with hash to field. * cargo fmt * account for paritytech#13972 * hide BLS behind "bls_non_production" feature flag * Remove Cargo.lock entries duplicated in merge * add bls377 to primitives/keystore and client/keystore add bls377 to primitives/application-crypto/ add bls_non_production to primitives/keystore and client/keystore bump up w3f-bls version * rename feature `bls_non_production` to `bls-experimental` --------- Co-authored-by: Davide Galassi <davxy@datawok.net> Co-authored-by: André Silva <andrerfosilva@gmail.com> Co-authored-by: Robert Hambrock <roberthambrock@gmail.com>

drskalman added 30 commits December 9, 2021 19:47

adding boilerplate for adding bls crypto

18c7d88

First scratches to add bls crypto to primities/core and beefy.

b86768c

suggested solution during BEEFY meeting for making BEEFY BLS compatible

fd75c93

Merge remote-tracking branch 'origin/master' into skalman-bls-beefy

322ad00

- fix dependencies on arkwork and bls library.

f7fca6d

- break the 85000 char line in the commitment test multiple lines.

to discuss HKDK with Al

5e8f2ea

resolve compilation errors for primitives/core/src/bls.rs

2912fa1

resolve bls test compilation error, 6 tests still failing

86b1e3a

- change dependancy patches to repos available on github.

2b59fa0

- remove H256, H512 unused hash types from bls

Merge branch 'master' of https://github.com/paritytech/substrate into…

b602e7a

… skalman-bls-beefy

overwrite Cargo.lock from upstream and cargo-update to reslove Cargo.…

68fd3a2

…lock conflict

add bls_generate_new and bls_public_keys to CryptoStore

59d665e

- implement host api `bls_public_keys, bls_generate, bls_sign,

857f85e

bls_verify` - implement bls wrapper for application-crypto

- Adapt primitives/beefy/src/commitment.rs and witness.rs to have

a1ed112

aggregatble signature. - Flexiblize Witness to have different Aggregator (either Merkle or BLS).

implement TestNOPAggregatableSignature for Merkle based commitment.

b936150

adapt an pass test for merkle root aggregator

1df925c

rust-fmtize

28596f2

add test for commitment containing aggregated bls signature.

577cc68

make different traits for keystore for ecdsa-only and ecdsa-bls beefy…

0f53f28

… keystore

reverse the idea of validator aggregating received bls signature

fed0bbc

because it is not possible with bitfield aggregation. Compiles but tests do not compile yet.

make beefy primitve test compile and pass

7de89ae

implement should_convert_dually_signed_commitment_to_witness test

5379e62

using bls aggregator

Merge branch 'skalman-bls-beefy' into skalman-bls-beefy-client

7bdb082

separate impl for ECDSA and BLS keystore

1661c19

Merge branch 'skalman-bls-beefy-client' of https://github.com/drskalm…

6a1c26f

…an/substrate into skalman-bls-beefy-client

add bls support to LocalKeyStore

ab682ce

implement BeefyBLSKeystore and BeefyBLSnECDSAKeystore

231a38e

Make BeefyKeyStore generic for Beefy Worker

1847516

add BeefyKeystore generic type to GossipValidator so it can turn

cc3a9d6

CryptStoe into approperate key store.

adapt BEEFY GossipValidator to a generic Keystore

e0d8740

serban300 self-requested a review February 6, 2023 07:10

acatangiu requested a review from andresilva February 6, 2023 08:57

serban300 reviewed Feb 6, 2023

View reviewed changes

drskalman commented Feb 8, 2023

View reviewed changes

Lederstrumpf self-requested a review February 14, 2023 07:32

Lederstrumpf suggested changes Feb 14, 2023

View reviewed changes

acatangiu reviewed Feb 21, 2023

View reviewed changes

burdges reviewed Feb 24, 2023

View reviewed changes

Add AuthoritySetCommitment field to BeefyAuthoritySet needed by A…

73657c5

…PK prover

drskalman commented Feb 24, 2023

View reviewed changes

hujw77 mentioned this pull request Mar 8, 2023

Accountable Light Client tracker darwinia-network/darwinia-messages-sol#310

Open

- depend on default branch of bls-like and apk-proofs.

096f94d

- rename TAggregatableSignature to TSignatureAccumulator. - Fix and pass all tests in primites/beefy. - remove unused TAggregatableSignature type

drskalman added a commit to w3f/substrate that referenced this pull request Mar 15, 2023

Cherry pick all crypto related changes from pull-request paritytech#1…

b845210

…3311 applied to master's head

drskalman mentioned this pull request Mar 15, 2023

BLS Core Crypto attempt #2 #13618

Merged

stale bot added the A3-stale label Apr 14, 2023

stale bot closed this Apr 28, 2023

drskalman mentioned this pull request Jun 14, 2023

Support for multiple signature scheme for BEEFY primitves #14373

Merged

drskalman mentioned this pull request Oct 8, 2023

Beefy client generic on aduthority Id paritytech/polkadot-sdk#1816

Merged

		let own_ecdsa_key = self.both().0.authority_id(&ecdsa_pubkeys);
		let own_bls_key = self.both().1.authority_id(&bls_pubkeys);

	/// Auxiliray tairt for ECDSAnBLS
	/// Auxiliary trait for ECDSAnBLS

Make BEEFY client able to generate either ECDSA or (ECDSA,BLS) Finality proof. #13311

Make BEEFY client able to generate either ECDSA or (ECDSA,BLS) Finality proof. #13311

Conversation

drskalman commented Feb 4, 2023

serban300 left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Lederstrumpf left a 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

burdges commented Feb 19, 2023 • edited Loading

acatangiu left a 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

drskalman commented Feb 24, 2023

drskalman commented Feb 24, 2023

Choose a reason for hiding this comment

burdges commented Feb 24, 2023 • edited Loading

serban300 commented Feb 28, 2023 • edited Loading

paritytech-cicd-pr commented Mar 13, 2023

stale bot commented Apr 14, 2023

acatangiu commented Apr 28, 2023

burdges commented Feb 19, 2023 •

edited

Loading

burdges commented Feb 24, 2023 •

edited

Loading

serban300 commented Feb 28, 2023 •

edited

Loading