polytope-labs/hyperbridge

Hyperbridge is a hyper-scalable coprocessor for cryptographically secure, cross-chain interoperability

hyperbridge's Issues

Ismp Parachain should identify parachains with 6s slots

We currently hard code the expected slot duration for parachains which is used to calculate it's current timestamp. For parachains with async backing (like hyperbridge), this slot duration will instead be 6s. We should add some metadata about parachains which tell the ismp parachain consensus client what slot number that the parachain currently uses. This should be configured when the parachain is added to the pallet.

CallDispatcherV2

It might be usefult to make CallDispatcher itself an IIsmpModule that can receive arbitrary calls and execute them, particularly useful once EIP-3074 is merged.

OffchainDB MMR pruning

With #184 merged, we now store mmr nodes fully offchain. With the peaks stored on-chain. This is great but as the mmr grows, so does the storage requirements for node runners (See #185).

It's clear that long-term we will need to introduce pruning for the mmr stored in the offchaindb. Luckily, MMRs are very amenable to pruning. More so, we will be focusing on pruning ancient subtrees whose leaves (requests) have already timed out. Meaning knowledge of their intermediate nodes are infact useless to relayers. Relayers & Users will only care about more recent subtrees in the MMR. This should keep the storage requirements for hyperbridge low enough that it can remain a radically inclusive & decentralized network.

Gateway `ERC20` support

Gateway should be able to support the ERC6160 standard as well as the ERC20 standard through token swaps. If a user bridges an ERC20 token that has no ERC20 counterpart on the destination chain, they should get an ERC6160 token. On the other hand if a counterpart exists, the relayers should double as liquidity providers and facilitate the token swap. Relayers after providing liquidity should get the ERC6160 counterpart that they can use to withdraw the ERC20 token locked on the source chain.

onRequestTimeout we should either refund the custodied ERC20 or mint the ERC6160 asset back to the user. Allowing them retry the cross-chain teleportation.

Because ISMP charges protocol fees in it's configured feeToken, Gateway should allow users swap either the native asset or an ERC20 for the feeToken asset through some local AMM required to cover their fees.

Introduce HostExecutive

The HostExecutive module is responsible for tracking the HostParams for each individual host on a connected chain. This host may be a Substrate or Evm host.

The manager is responsible for dispatching parameter updates to these hosts over ismp. This should allow for securely updating the host either through sudo, a council motion or governance. The manager can also be used to withdraw protocol revenue that has been accrued by each host.

[META] Relayers

Coordinating a decentralized pool of relayers will be necessary for the scalability and robustness of the Hyperbridge protocol. Our chosen design is one where relayers race to deliver ISMP requests to their respective destinations for a fee. This fee is paid ahead of time by the user on the source chain. This also means that if the request/response is never delivered then a user should be refunded the fees they paid ahead of time for delivery since it was never used.

Given these considerations we should introduce a new module that lives on the hyperbridge aptly named, RelayerManager. This module should track the cumulative sum of requests & responses that have been delivered by 3rd party relayers, through the verification of state proofs of their delivery.

Relayers, at the end of a days of work (or at their own discretion) should be able to issue a signed request to the RelayerManager asking to withdraw all the funds they are entitled to on the respective chains.

Ismp Parachain inherent relay chain Get request handling.

The inherent can also be used to provide responses to get requests addressed to the relay chain.

Might be useful for something or someone.

`GovernableToken`

Much like how the IsmpHost and Gateway should be governable by hyperbridge. So also must the ERC6160 tokens that are integrated into Gateway be governable. This governance action should allow modifying it's allowed minter & burners, eg adding new roles or deleting existing ones.

contract GovernableToken is IIsmpModule, ERC6160Ext20 {}

Relayer DPoS

Goal: configure simple, efficient DPoS to enable relayer revenue sharing

Current idea is to add a new pallet-delegate which (in)directly uses/requires polkadot-sdk/collator-selection pallet (and also configure pallet-collator-selection in the runtime). Building on this pallet for the initial implementation is safe because it is already audited as well as tested by widespread ecosystem usage.

Runtime upgrades enable upgrading into custom, optimized DPoS implementations for future iterations, but I suggest starting simple by building on what has proven to work (polkadot-sdk/collator-selection pallet)

pallet-delegate spec (wip)

Config:

• Currency
• MinDelegation

Extrinsics:

• delegate: increase/initiate delegation
• undelegate: decrease/remove delegation

[META] SubstrateHost

To support SubstrateHosts. We would need

• HyperbridgeDispatcher - for dispatching requests to hyperbridge
• SubstrateHostManager - for managing the HostParams from hyperbridge
• ismp-grandpa - for standalone chains and parachains on the sister relay chain
• ismp-beefy - for standalone chains and parachains on the sister relay chain
• ismp-parachain - for parachains

Testnet Token request for Faucet

Hello, I am one of the contributors to the Universal Substrate Faucet funded by the Polkadot Treasury(https://polkadot.polkassembly.io/referenda/541).
Please help us acquire the testnet tokens for Hyperbridge (Gargantua).

Support Account Abstraction(?)

In the account abstraction paradigm, user accounts will no longer be tx.origin. This is as a result of moving their assets from an EOA to a smart contract account. Consequently, the EvmHost should be reworked to support smart contract accounts which hold assets in msg.sender instead of tx.origin.

Some ideas

• Don't charge tx.origin by default when dispatching requests, instead allow the application to choose who should pay for fees.
• Allow relayers use account abstraction.

Implement Parachain Template Runtime

Hyperclient Improvements

• Update hyperclient to child tries #148
• Hyperclient should yield the HandlerV1.HandlePostRequest calldata in HyperbridgeFinalized event to allow for self-relaying. Alternatively subscribe to the indexer events directly, instead of querying the chain.
• Hyperclient should query the indexer for events instead of the chain.

Add optimism support for beacon consensus client updates

Spec is described here https://www.notion.so/polytopelabs/Optimism-Support-for-Beacon-Consensus-Client-03a82c7b85404435b48f1a8e93b02722

This task specs out requirements for adding optimism support to the sync committee updates
We create a new struct that contains the LightClientUpdate alongside an optional optimism update field optimism_payload that holds Option as defined below.

struct BeaconClientUpdate {
	pub consensus_update: LightClientUpdate,
  pub optimism_payload: Option<OptimismPayloadProof>
}

struct OptimismPayloadProof {
	/// Actual state root of the optimism execution layer
	pub state_root: [u8; 32],
  /// Storage root hash of the optimism withdrawal contracts
	pub withdrawal_storage_root: [u8; 32],
  /// Optimism Block hash at which the values aboved were fetched
	pub l2_block_hash: [u8; 32],
	/// L2Oracle contract version
	pub version: [u8; 32],
  /// Membership Proof for the L2Oracle contract account in the ethereum world trie
  pub l2_oracle_proof: Vec<Vec<u8>>,
  /// Membership proof for Output root in l2Outputs array
  pub output_root_proof: Vec<Vec<u8>>,
  /// Index of the output root that needs to be proved in the l2Outputs array
  pub output_root_index: u64
}

Contract Properties
For testnet L2Oracle contract address is 0x47bBB9054823f27B9B6A71F5cb0eBc785692FF2E

Slot index for the l2Outputs array in the contract is 3

To verify an optimism update

1. Extract L2Oracle storage root hash from the l2_oracle_proof , the root hash to be used for this step is the execution_payload_root from the LightClientUpdate.
2. Use the extracted storage root hash to verify membership for the output_root as constructed below in the output_root_proof

Contract Properties
For testnet L2Oracle contract address is `0x47bBB9054823f27B9B6A71F5cb0eBc785692FF2E`

Slot index for the l2Outputs array in the contract is `3`

To verify an optimism update

1. Extract `L2Oracle` storage root hash from the `l2_oracle_proof` , the root hash to be used for this step is the `execution_payload_root` from the `LightClientUpdate`.
2. Use the extracted storage root hash to verify membership for the `output_root`  as constructed below in the  `output_root_proof`

Create a file for exporting beacon consensus client constants.
Feature flag testnet config parameters.

#first