-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sovereign Chains Cross-Chain Execution #1033
base: development
Are you sure you want to change the base?
Conversation
@@ -0,0 +1,9 @@ | |||
# Cross-Chain Execution Example |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this linked to the docs?
@@ -0,0 +1,18 @@ | |||
# Creating Bridges |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This title is confusing. Creating bridges between what to what should be the answer? At this point in time, a normal user, first time visitor will have no clue to what kind of bridges we are reffering to. Even though we may think that it is obvious (it may be for us) that the topic of this page is the bridge btw MainChain to Sovereign and the other way around, it is not.
|
||
## What is Cross-Chain Execution? | ||
|
||
Being able to connect 2 different ecosystems opens up infinite possibilities for functionality. Cross-Chain Execution implies using the functionality of two different chains and combining both of them. In this context we can refer to: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same thing as above:
A new user will ask himself:
"two chains" - Is it Ethereum and Solana? or what chains are you referring to?
|
||
Being able to connect 2 different ecosystems opens up infinite possibilities for functionality. Cross-Chain Execution implies using the functionality of two different chains and combining both of them. In this context we can refer to: | ||
|
||
1. Sending tokens from one chain to another |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
Better define from what Chain to what Chain. Probably it will be better to have a note above where you define what MainChain is and what Sovereign Chain is.
|
||
## Cross-Chain Execution within Sovereign Chains | ||
|
||
All the heavy lifting is being done by the *ESDT-Safe* Smart Contract. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is this Smart Contract described in detail? if it is not, let's create a page for it. If it is, add a link to that description.
docs/sovereign/to-sovereign.md
Outdated
@@ -0,0 +1,42 @@ | |||
# To Sovereign |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To sovereign but from where? From another Sovereign or From Mainchain?
static/sovereign/ToSovereign.png
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not clear enough.
Please modify.
Split in two main part -> what is part of MainChain, what is part of Sovereign.
Besides the ESDT-Safe and Token-Handler contracts (where is token handler described and what's it's purpose) I do not know what the other symbols represent. The first user is Alice who is sending to her on the same chain or is it a differnet chain? etc etc.
static/sovereign/FromSovereign.png
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not clear enough.
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
13dcbed
to
9ecd4a6
Compare
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
This feature is enabled by using multiple smart contracts, each one with its unique role and set of functionalities. The current Sovereign Chain suite consists of three main contracts, here is the high-level description for some of the cross chain smart contracts: | ||
|
||
#### ESDT-Safe | ||
The *ESDT-Safe* Smart Contract performs all the heavy lifting. This is the cross-chain execution contract, this execution will be done between either any Sovereign Chain and the MultiversX mainchain or between any Sovereign Chains. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- "cross-chain execution contract" - the contract does not execute anything cross-chain. It's responsible for the cross-chain transfers
- "between any Sovereign Chains" - not true
#### ESDT-Safe | ||
The *ESDT-Safe* Smart Contract performs all the heavy lifting. This is the cross-chain execution contract, this execution will be done between either any Sovereign Chain and the MultiversX mainchain or between any Sovereign Chains. | ||
|
||
There are two modules implemented for this contract: [*From Sovereign*](from-sovereign.md), [*To Sovereign*](to-sovereign.md) and two important endpoints: [`execute_operation`](from-sovereign.md#executing-an-operation), [`deposit`](to-sovereign.md#deposit-tokens). Both of them allow the caller to transfer tokens and also execute smart contracts within a single transaction. The only difference is where the sender and receiver of the cross-chain execution are situated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of them allow the caller to transfer tokens and also execute smart contracts within a single transaction. The only difference is where the sender and receiver of the cross-chain execution are situated.
This is not really accurate. Users only use the deposit
endpoint to deposit tokens which will be transferred cross-chain. The other endpoint is used only for transfers sov -> main by the bridge service
|
||
The scenarios for what endpoint to choose look like this: | ||
1. If the receiver is in a Sovereign Chain, the call should be to the `deposit` endpoint. (_To Sovereign_) | ||
2. If the sender is in a Sovereign Chain, the call should be to the `execute_operation` endpoint. (_From Sovereign_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call is also on deposit endpoint, then the bridge service will execute_operation
on main chain
Cross-Chain execution is the ability of smart contracts or decentralized applications on one blockchain to invoke actions on another blockchain. This feature allows for seamless communication and interaction between different blockchain networks, enabling developers to build applications that are chain agnostic. | ||
|
||
|
||
## Cross-Chain Execution within Sovereign Chains |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say we need to add some context about the bridge service because it's needed for my next comments
::: | ||
|
||
#### Fee-Market | ||
Since every Sovereign Chain will have a customizable fee logic, it was paramount that this configuration had to be separated into a different contract. Rules such as: fee token, fee percentages, whitelists are all stored inside this contract. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- rules are: fee per transferred token, fee per gas unit and users whitelist to bypass the fee
- you can also add that this contract is present in both chains
All the *BLS keys* of the validator will be stored inside this contract. The main role for the Header-Verifier contract is to verify signatures for the operations that are created inside the Sovereign Chain. | ||
|
||
:::note | ||
Each Sovereign Chain will include those smart contracts, the source code can be found at the official [MultiversX Sovereign Chain SCs repository](https://github.com/multiversx/mx-sovereign-sc). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each Sovereign Chain will include those smart contracts, the source code can be found at the official [MultiversX Sovereign Chain SCs repository](https://github.com/multiversx/mx-sovereign-sc). | |
The source code for the smart contracts can be found at the official [MultiversX Sovereign Chain SCs repository](https://github.com/multiversx/mx-sovereign-sc). |
Since every Sovereign Chain will have a customizable fee logic, it was paramount that this configuration had to be separated into a different contract. Rules such as: fee token, fee percentages, whitelists are all stored inside this contract. | ||
|
||
#### Header-Verifier | ||
All the *BLS keys* of the validator will be stored inside this contract. The main role for the Header-Verifier contract is to verify signatures for the operations that are created inside the Sovereign Chain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say this with more context, like
main role is to verify operations - operations are signed by validators - if succesfully verified will be registered and can be executed by ESDT-Safe
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
Description of the pull request (what is new / what has changed)
Did you test the changes locally ?
Which category (categories) does this pull request belong to?