Split guard from truth layer to application layer

[hackfisher]

Guard is an independent mechanism providing extra protection and audit for the delivered cross-chain messages, there are two kinds of guards, BridgeHubGuard for bridge hubs like Darwinia and Crab, and BranchGuard for the branch bridged chains like Ethereum etc.

• BridgeHubGuard
  For each bridged chains in the bridge hub, there will one BridgeHubGuard instance, BridgeHubGuard is using technical committee as its guard members to confirm the header after light client layer finalize/verify the header.

Current prototype: vote_pending_relay_header_parcel in darwinia-ethereum-relay pallet

• EcdsaBranchGuard

For bridged branch chain like Ethereum, using several ethereum keys as guard member

• This guard members can be used to provide signatures to confirm delivered headers/messages.
• This guard members can be used to upgrade themselves by provide signatures for updating members.
• Its guard members can be selected independently(not governanced by hub chain)

These features are in the bridged branch chain sides, sometime the bridge hub chain might also be used for communicating, validating and aggregating these signatures, but in this part it only used as a shared network and database, not protocol.

Current prototype: EcdsaAuthorities pallet.

Each of the two pallet should be able to be standardized and support multi instance.

[hackfisher]

Only support header guard for now, might support message if future(will consume more gas).

[hackfisher]

For EcdsaBranchGuard, need to provide the commitment content spec for signing.

Current implementation for reference:

			// The message is composed of:
			//
			// hash(
			// 	codec(
			// 		spec_name: String,
			// 		op_code: OpCode,
			// 		block number: Compact<BlockNumber>,
			// 		mmr_root: Hash
			// 	)
			// )

We need to add the chain id of target chain in the following commitment content.

		// The message is composed of:
		//
		// hash(
		// 	codec(
		// 		spec_name: String,
		// 		op_code: OpCode,
		// 		term: Compact<u32>,
		// 		next authorities: Vec<Signer>
		// 	)
		// )

[hackfisher]

Chains like Tron seems to do not support light client, for these chain, the new guard mechanism is critical and thus giving it higher priority.

[hackfisher]

In architect, We'll move the guard design to be part of application. It is up to the application whether to use guard or not, if using guard, it will probably be managed by that application's DAO.

For example, for Wormhole DAO, it will decide what is the guard strategy, and who plays the guard role. In this way, the architect will be simplylied, and design will be more flexible and adaptable.

There might be some useful practices app can consider to adopt:

1. combine of timelock to eliminate the possibility of audit attack.

2. Since the bridger will always deliver the bridge message regardles app design, so for token protocols like wormhole, app might do not want to directly withdraw/mint funds from backing/issing. strategy could be:

A. Guard crosschain tokens according to token amount, exceed day limit, exceed recent velocity. The dispatch call on target chain will emit guard events to invite guards to join in.

B. Only guard very native tokens, since mapping tokens might be still managable/savable by wormhole dao.

Bridge V2 will adopt this new architecture, for current v1, we might only need to keep as it is, or do some simplification to ecdsa authorities and handon to wormhole dao. (replace signature communication with AR or system.remark)

B

[hackfisher]

Moved to helix helix-bridge/contracts#5.

Current guards will be automatically deprecated and removed after switching to v2 (eth2 and bsc)