Paired-key Crypto Scheme #14705
Paired-key Crypto Scheme #14705
Conversation
primitives/core/src/paired_crypto.rs
Outdated
| pub struct PublicWithInner<LeftPublic: PublicKeyBound, RightPublic: PublicKeyBound, const LEFT_PLUS_RIGHT_SIZE: usize> { | ||
| inner: [u8; LEFT_PLUS_RIGHT_SIZE], | ||
| _phantom: PhantomData<fn() -> (LeftPublic, RightPublic)>, | ||
| } | ||
|
|
||
| pub struct Public<LeftPublic: PublicKeyBound, RightPublic: PublicKeyBound> { | ||
| left_public : LeftPublic, | ||
| right_public: RightPublic, | ||
| } |
There was a problem hiding this comment.
@davxy : could you tell me which way of implementing 'paired_cryptodo you prefer? In my opinion the second is more clean and more expressive but it results in copying duringtryForm<[u8]>andAsMut<[u8]>operations. On the other hand, if we go with the inner approach, it could be that when we try to use the subkeys, deserializinginner` results in copying as well as we don't have control on the implementation of subkey types.
There was a problem hiding this comment.
IMO the second representation is better (as you said).
In this way we abstract the internal representation of the components.
It'd be interesting to try to generalize to Tuples (using https://docs.rs/impl-trait-for-tuples/0.2.2/impl_trait_for_tuples/) instead of defining the single types.
In this way we'd have the implementation of Public, Pair, etc for any tuple of types implementing Public, Pair, etc...
- unsucessfuly try to implement ByteArray for paired crypto Public
primitives/core/src/paired_crypto.rs
Outdated
| // impl<LeftPublic: PublicKeyBound, RightPublic: PublicKeyBound, const LEFT_LEN: usize, const RIGHT_LEN: usize> AsMut<[u8]> for Public<LeftPublic, RightPublic, LEFT_LEN, RIGHT_LEN> { | ||
| // fn as_mut(&mut self) -> &mut [u8] { | ||
| // &mut [self.0.as_mut(), self.1.as_mut()].concat() | ||
| // } | ||
| // } |
There was a problem hiding this comment.
@davxy it seems that the second representation (LeftPublic: PublicBound, RightPublic: PublicBound) does not work because we can not implement AsRef<u8> and AsMut<u8> as we don't have a consecutive representation of the sub-elements as these people suggests. Should I go back to the first solution:
pub struct PublicWithInner<LeftPublic: PublicKeyBound, RightPublic: PublicKeyBound, const LEFT_PLUS_RIGHT_SIZE: usize> {
inner: [u8; LEFT_PLUS_RIGHT_SIZE],
_phantom: PhantomData<fn() -> (LeftPublic, RightPublic)>,
}
or should I keep both representations at the same time:
pub struct Public<LeftPublic: PublicKeyBound, RightPublic: PublicKeyBound, const LEFT_PLUS_RIGHT_SIZE: usize> {
left_public : LeftPublic,
right_public: RightPublic,
inner: [u8; LEFT_PLUS_RIGHT_SIZE],
}
or you have a solution to building non-ephemeral slice in a function that works here?
🙏
…ed crypto object in favor of avoiding copy
implement some of aux traits for `paired_crypto::Signature`
|
The CI pipeline was cancelled due to failure one of the required jobs. |
- Implement a pair of seeds for paired crypto scheme.
…paired (ECDSA, BLS377) crypto
…_crypto.rs` - put serialize and descerialze under `serde` feature instead of std in `primitives/core/src/bls.rs` - fix documentation in `primitives/core/src/bls.rs`
BEEFY needs two cryptographic keys at the same time. Validators should sign BEEFY payload using both ECDSA and BLS key. The network will gossip a payload which contains a valid ECDSA key. The prover nodes aggregate the BLS keys if aggregation fails to verifies the validator which provided a valid ECDSA signature but an invalid BLS signature is subject to slashing.
As such BEEFY session should be initiated with both key. Currently there is no straight forward way of doing so, beside having a session with RuntimeApp corresponding to a crypto scheme contains both keys.
This pull request implement a generic
paired_cryptoscheme as well as implementing it for (ECDSA, BLS) pair.Polkadot companion: (if applicable)
Cumulus companion: (if applicable)
Checklist
A,B,CandDrequired)✄ -----------------------------------------------------------------------------