EXODUS as the only way to bridge out from Ghost Chain to any EVM network #3

New Issue

str3tch · 2024-10-07T20:42:42+02:00

str3tch commented

2024-10-07 20:42:42 +02:00

Problem

This has been discussed many times, but still. The current slow claps protocol is great for bridging inside the ghost network, but it doesn't fit perfectly when exiting the network. This was partly solved by adding companions, which added an additional level of complexity overall.

Context

Due to the fact that any node that is running with --validator flag and staking is forced to listen on events with predefined structure over EVM RPC endpoint provides an opportunity to do so-called claps for each logged event. One clap represents a vote to pass through the transaction, but when the threshold is met the applause will happen and transaction will be actually executed on the network aka ghost balance will be minted.

But in order to make bridge out, user need to create a record on the EVM destination network that represents the locked balance on the side of ghost chain. This is called companion. The user should wait for the bridge incoimng transaction in order to become get tokens from the gatekeeper smart contract, basically this person pays fee to the person who is bridging-in (pay-2-bridge).

There are some pitfalls which are partially resolved, so for now it seems like it's pretty stable.

Downsides

Not the best UX for the end user, due to extra actions needed to be done in order to bridge out. Comment by @harpocrates
To process all companions across all networks and events, O(n^2) is possible. Comment by @st1nky
Extra commissions fees to be payed on the side of EVM network. Comment by @f4ts0
Non-determenistic time for the bridging out
Bridge is highly dependant on the average amount of users

Solution

EXODUS (EXchange Of Distributed Unified Signatures) should partially solve the problems mentioned above. This protocol is about signing EVM transaction on the side of ghost chain by every node which is running with --validator flag and actively participating in staking. Public keys for that signatures should be registered in a gatekeeper smart contract and should be treated as multisig.

Something similar was used by @f4ts0 for the multisig.

How it should work

Validator add private key to the offchain storage
Validator should prove that key is reachable. For that reason on chain could be stored heartbeats, which are signed block_number or something else
User locks funds on the side of ghost chain, attaching ERC20 transfer(address who, uint256 amount) information
Validators generate signatures for this transaction with help of the stored key
Anyone can use this signatures in order to execute this transaction on the EVM side
Key rotation could happen on the same manner but with addValidator(address who) and/or removeValidator(address who)
Potentially keep track of locked funds on the gatekeeper
Potentially don't bridge transactions to EVM network which is not synced for validators list on EVM and ghost chain (just store validators on the gatekeeper as slow claps)

Questions to be solved

Is there anyway to cancel bridge out?
What should we do if the amount on destination network is not sufficient?
How to deal with double spending? What can be used as nonces?
Do we need to deal with finality on the side of ghost chain?
TBD

### Problem This has been discussed many times, but still. The current **slow claps** protocol is great for bridging inside the ghost network, but it doesn't fit perfectly when exiting the network. This was partly solved by adding **companions**, which added an additional level of complexity overall. ### Context Due to the fact that any node that is running with `--validator` flag and staking is forced to listen on **events** with predefined structure over [EVM RPC endpoint](https://ethereum.org/en/developers/docs/apis/json-rpc/) provides an opportunity to do so-called **claps** for each logged event. One **clap** represents a vote to pass through the transaction, but when the threshold is met the **applause** will happen and transaction will be actually executed on the network aka ghost balance will be minted. But in order to make bridge out, user need to create a record on the EVM destination network that represents the locked balance on the side of ghost chain. This is called **companion**. The user should wait for the bridge incoimng transaction in order to become get tokens from the **gatekeeper** smart contract, basically this person pays fee to the person who is bridging-in (pay-2-bridge). There are some pitfalls which are partially resolved, so for now it seems like it's pretty stable. ### Downsides - Not the best UX for the end user, due to extra actions needed to be done in order to bridge out. Comment by @harpocrates - To process all companions across all networks and events, O(n^2) is possible. Comment by @st1nky - Extra commissions fees to be payed on the side of EVM network. Comment by @f4ts0 - Non-determenistic time for the bridging out - Bridge is highly dependant on the average amount of users ### Solution **_EXODUS_** (EXchange Of Distributed Unified Signatures) should partially solve the problems mentioned above. This protocol is about signing EVM transaction on the side of ghost chain by every node which is running with `--validator` flag and actively participating in staking. Public keys for that signatures should be registered in a **gatekeeper** smart contract and should be treated as multisig. Something similar was used by @f4ts0 for the multisig. ### How it should work - Validator add private key to the **offchain storage** - Validator should prove that key is reachable. For that reason on chain could be stored **heartbeats**, which are signed **block_number** or something else - User locks funds on the side of ghost chain, attaching ERC20 `transfer(address who, uint256 amount)` information - Validators generate signatures for this transaction with help of the stored key - Anyone can use this signatures in order to execute this transaction on the EVM side - Key rotation could happen on the same manner but with `addValidator(address who)` and/or `removeValidator(address who)` - Potentially keep track of locked funds on the gatekeeper - Potentially don't bridge transactions to EVM network which is not synced for validators list on EVM and ghost chain (just store validators on the **gatekeeper** as **slow claps**) ### Questions to be solved - Is there anyway to cancel bridge out? - What should we do if the amount on destination network is not sufficient? - How to deal with double spending? What can be used as nonces? - Do we need to deal with finality on the side of ghost chain? - TBD

str3tch added the

enhancement

help wanted

labels 2024-10-07 20:42:42 +02:00

str3tch self-assigned this 2024-10-07 20:42:42 +02:00

neptune was assigned by str3tch

2024-10-07 20:42:42 +02:00

f4ts0 was assigned by str3tch

2024-10-07 20:42:42 +02:00

ghost_7 was assigned by str3tch

2024-10-07 20:42:42 +02:00

st1nky was assigned by str3tch