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

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

ajruecker commented

2024-10-27 20:32:18 +01:00

Crosspost:

Ideally, we don't stop a transaction in the middle of execution. If the bridge is fast enough and a user makes a mistake, they can simply bridge back. Allowing cancellations introduces security vulnerabilities, so I don’t see a strong case for implementing it.

What should we do if the amount on the destination network is not sufficient?
There should be a check in place before this happens, either directly or through an oracle, to confirm the availability of sufficient funds. If the funds are not enough, the txn should be halted/blocked. OR they should be recomennded to swap and bridge using a different asset (no reason we can't have different funds in the bridge, i.e. ETH, USDT, wBTC, etc.) especially if Ghost is positing as some form of interoperability protocol. Simply funnel users to the LP pools that are the largest, either by charging higher fees on more exotic bridge assets, or by discounting fees on the more liquid bridge assets.

How to deal with double spending? What can be used as nonce?
Create a unique hash using the user’s public key, validator, and specifics about their transaction (amount and timestamp). Lock the funds with this hash and store it on-chain. Once the bridge completes, mark it as finalized/spent to prevent reuse.

Do we need to deal with finality on the side of the ghost chain?
Most likely, a finality indicator using block confirmation along with the unique hash would be beneficial. It would probably be necessary to wait for the hash to be marked as spent before treating the transaction as final.

Crosspost: Ideally, we don't stop a transaction in the middle of execution. If the bridge is fast enough and a user makes a mistake, they can simply bridge back. Allowing cancellations introduces security vulnerabilities, so I don’t see a strong case for implementing it. What should we do if the amount on the destination network is not sufficient? There should be a check in place before this happens, either directly or through an oracle, to confirm the availability of sufficient funds. If the funds are not enough, the txn should be halted/blocked. OR they should be recomennded to swap and bridge using a different asset (no reason we can't have different funds in the bridge, i.e. ETH, USDT, wBTC, etc.) especially if Ghost is positing as some form of interoperability protocol. Simply funnel users to the LP pools that are the largest, either by charging higher fees on more exotic bridge assets, or by discounting fees on the more liquid bridge assets. How to deal with double spending? What can be used as nonce? Create a unique hash using the user’s public key, validator, and specifics about their transaction (amount and timestamp). Lock the funds with this hash and store it on-chain. Once the bridge completes, mark it as finalized/spent to prevent reuse. Do we need to deal with finality on the side of the ghost chain? Most likely, a finality indicator using block confirmation along with the unique hash would be beneficial. It would probably be necessary to wait for the hash to be marked as spent before treating the transaction as final.

st1nky commented

2024-10-28 15:55:10 +01:00

@ajruecker thank you for joining the discussion, it is very important to always have a fresh perspective on things!

What should we do if the amount on the destination network is not sufficient?

It seems to me that when @str3tch talked about "amount on the destination network is not sufficient", he meant a situation where two transactions are in the mempool and sum of their amounts will not give the entire possible volume. For example

Person A wants to withdraw 80 tokens
Person B wants to withdraw 70 tokens
On the bridge side there's only 100 tokens

Due to the fact that state machine process transactions one be one, someone must be first. Let's say person A is the first, so full amount passed without problems. But the next guy is in trouble, only 30 tokens left but tx was done for 70. IMHO there's no ideal solution, so the best course of actions is to make it customizable from the user's side, such as transfers below existential deposit.

I personally don't see how any type of oracle could be applied here, because every validator node is an oracle 😊
No need to re-invent the bycicle. We can store actually clapped transactions and use them as a factual gatekeeper amount.

How to deal with double spending? What can be used as nonce?

Here's the tricky part! If we are going to provide signatures on the side of Ghost, which should be executed on the side of EVM chain, I don't think that it's enough to have pubic key and tx info. Signature generated on the side of Ghost, should have something specific that could be synced to EVM in order to prevent usage of the same signatures down the road.

Do we need to deal with finality on the side of the ghost chain?

I'm on the side of @ajruecker, that is so obvious task. Just give them signatures and wait for finalized events 😎

@ajruecker thank you for joining the discussion, it is very important to always have a fresh perspective on things! ### What should we do if the amount on the destination network is not sufficient? It seems to me that when @str3tch talked about **"amount on the destination network is not sufficient"**, he meant a situation where two transactions are in the mempool and sum of their amounts will not give the entire possible volume. For example - Person A wants to withdraw 80 tokens - Person B wants to withdraw 70 tokens - On the bridge side there's only 100 tokens Due to the fact that state machine process transactions one be one, someone must be first. Let's say person A is the first, so full amount passed without problems. But the next guy is in trouble, only 30 tokens left but tx was done for 70. IMHO there's no ideal solution, so the best course of actions is to make it customizable from the user's side, such as transfers below **existential deposit**. I personally don't see how any type of **oracle** could be applied here, because every validator node is an oracle 😊 No need to re-invent the bycicle. We can store actually clapped transactions and use them as a factual gatekeeper amount. ### How to deal with double spending? What can be used as nonce? Here's the tricky part! If we are going to provide signatures on the side of Ghost, which should be executed on the side of EVM chain, I don't think that it's enough to have pubic key and tx info. Signature generated on the side of Ghost, should have something specific that could be synced to EVM in order to prevent usage of the same signatures down the road. ### Do we need to deal with finality on the side of the ghost chain? I'm on the side of @ajruecker, that is so obvious task. Just give them signatures and wait for finalized events 😎

Sign in to join this conversation.