Weekly snapshot of substrate technology 20220411

ECDSA Public key translation Ethereum address

This week, substrate  Update extended ESDSA Signature related functions ,  Added ECDSAExt trait In order to expand ECDSA Signature  ,  Currently it contains a to_eth_address Method ,  Can be realized from ESDSA Public key to Ethereum compatible address conversion .  At the same time, it is a cross link bridge protocol module beefy-mmr And the contract module contract Add related calling methods and test modules . # Cross link # #ink contract #

It mainly adds frame/support/src/crypto/ecdsa.rs  file ,  The code is as follows :

```rust

pub trait ECDSAExt {
/// Returns Ethereum address calculated from this ECDSA public key.
fn to_eth_address(&self) -> Result<[u8; 20], ()>;
}impl ECDSAExt for Public {
fn to_eth_address(&self) -> Result<[u8; 20], ()> {
use k256::{elliptic_curve::sec1::ToEncodedPoint, PublicKey}; PublicKey::from_sec1_bytes(self.as_slice()).map_err(drop).and_then(|pub_key| {
// uncompress the key
let uncompressed = pub_key.to_encoded_point(false);
// convert to ETH address
<[u8; 20]>::try_from(
sp_io::hashing::keccak_256(&uncompressed.as_bytes()[1..])[12..].as_ref(),
)
.map_err(drop)
})
}
}

```

Simple code ,  Mainly to make use of k256 This crate and sp_io::hashing::keccak_256 take ECDSA The address is decompressed and then converted to Ethereum address format .  With this  to_eth_address,  The most immediate benefit is BEEFY Protocol related modules ,  as well as contract modular ;  The former is mainly used to bridge with Ethereum (bridge),  The latter needs to be extended to be compatible with Ethereum contracts . Extended reading : BEEFY and BEEFY-MMR

The most important feature of Poka ecology is its excellent cross chain capability ,  Parallel link network connected to Boca, such as Moonbean, Acala And so on susbtrate Development ,  Therefore, cross chain communication can be carried out by accessing the relay chain ;  But for those who are not substrate The chain of development ,  Like bitcoin / The etheric fang   These traditional blockchains ,  How to access Boca ,  And cross chain communication with Boca ecology ?

BEEFY The agreement is born for this .

BEEFY Consensus is also called BEEFY agreement , The full name is Bridge Efficiency Enabling Finality Yielder, Is an auxiliary consensus agreement ,  Need to agree with others such as GRANDPA Run together ;  It is mainly used to support and not Substrate More efficient bridging of blockchain ;  Such as Ethereum or bitcoin network Substrate Cross chain bridging between networks .

BEEFY It is usually necessary to follow a certain data aggregation structure in the application of ( Such as Merkle Trees ) Use a combination of ,  The main reason is substrate The final block validation for is based on GRANDPA agreement ,  The feature of this protocol is to confirm one sub chain at a time ,  Instead of a single block ;  But bitcoin ,  Traditional blockchains such as Ethereum are used to confirm blocks ;  So it's in substrate Bridge between the chain and Ethereum ,  A new aggregate data structure is needed ,  To accommodate the differences between the two consensus systems .

MMR (Merkle Mountain Range) It happens to be such a structure ,  and MMR It is more efficient and suitable for blockchain networks Merkle Tree structure ;  therefore substrate  Kindly provide BEEFY  and  BEEFY-MMR Related modules .

More about BEEFY The protocol and MMR,  Please pay attention to the following articles in this column . Optimize final block confirmation and notification

Another key optimization this week ,  It is aimed at the recent collectors (collator)  Caton's situation ,  Optimized the process of final block validation .

substrate The final block of the chain confirms that the consensus engine is GRANDPA,  because GRANDPA The confirmation method of is quite unique ,  It is completed by confirming the sub chain formed by multiple blocks at one time ,  Pictured :

In the figure ,  Every verifier (validtor) Will vote for the most suitable sub chain ,  Then the system selects 2/3 The verifier above votes for the longest child chain as passed ,  The picture shows A->B-C The longest subchain of the .

As can be seen from the picture ,  The best block is the block with the highest height ( The picture shows F1),  With the last confirmed block ( The picture shows C) There is a certain gap directly ,  Some blocks in this gap will be confirmed in the future ,  And some belong to expired headers (state head),  Something that needs to be discarded .

And the collector's Caton ,  Found by inspection ,  Mainly due to the confirmation of blocks (finalized block) And the best block (best block)  The spacing height is too high ,  Cause the collector (collator) It takes a lot of time to check and exclude the expired block header information (stale heads);

In view of the original leaves The module has provided a method to get the list of expired headers ,  But because all unreachable expiration headers are returned ;  So this PR Minor modifications have been made on this basis ,  add to displaced_by_finalize_height Method ,  So that only those whose height is lower than the confirmation block stale heads Removed instead of all unreachable blocks .

pub fn displaced_by_finalize_height(&self, number: N) -> FinalizationDisplaced<H, N> {
let boundary = if number == N::zero() {
return FinalizationDisplaced { leaves: BTreeMap::new() }
} else {
number - N::one()
}; let below_boundary = self.storage.range(&Reverse(boundary)..);
FinalizationDisplaced {
leaves: below_boundary.map(|(k, v)| (k.clone(), v.clone())).collect(),
}
}

Its calling method is shown in the following code :

fn displaced_leaves_after_finalizing(
&self,
block_number: NumberFor<Block>,
) -> sp_blockchain::Result<Vec<Block::Hash>> {
Ok(self
.storage
.read()
.leaves
.displaced_by_finalize_height(block_number)
.leaves()
.cloned()
.collect::<Vec<_>>())
}

It can be seen that ,  adopt leaves Module gets the list of expired headers ,  And then use displaced_by_finalize_height Method to remove some low height blocks ,  This greatly optimizes the time for final block validation .

that ,  What about those higher than the final block ?  These will be discarded in subsequent rounds .  Therefore, there is no need to worry about the problem that too much old data is retained in the chain .

About GRANDPA A detailed analysis of ,  Please also pay attention to the following articles .

This article has started

Permanent link

,  Belong to SEP Creation  Original group articles ,  Unauthorized ,  Do not reprint .