Skip to content
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

Open
wants to merge 26 commits into
base: development
Choose a base branch
from

Conversation

andreiblt1304
Copy link

@andreiblt1304 andreiblt1304 commented Jan 14, 2025

Description of the pull request (what is new / what has changed)

Did you test the changes locally ?

  • yes
  • no

Which category (categories) does this pull request belong to?

  • document new feature
  • update documentation that is not relevant anymore
  • add examples or more information about a component
  • fix grammar issues
  • other

@andreiblt1304 andreiblt1304 marked this pull request as ready for review January 14, 2025 12:55
@@ -0,0 +1,9 @@
# Cross-Chain Execution Example
Copy link
Contributor

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
Copy link
Contributor

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:
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

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.

@@ -0,0 +1,42 @@
# To Sovereign
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

@andreiblt1304 andreiblt1304 changed the base branch from main to development January 15, 2025 08:04
@andreiblt1304 andreiblt1304 changed the base branch from development to main January 15, 2025 08:08
docs/sovereign/cross-chain-execution.md Outdated Show resolved Hide resolved
docs/sovereign/cross-chain-execution.md Outdated Show resolved Hide resolved
docs/sovereign/cross-chain-execution.md Outdated Show resolved Hide resolved
docs/sovereign/cross-chain-execution.md Outdated Show resolved Hide resolved
docs/sovereign/to-sovereign.md Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Show resolved Hide resolved
@andreiblt1304 andreiblt1304 self-assigned this Jan 15, 2025
@andreiblt1304 andreiblt1304 changed the base branch from main to development January 16, 2025 07:40
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]>
docs/sovereign/to-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/to-sovereign.md Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/to-sovereign.md Outdated Show resolved Hide resolved
static/sovereign/from-sovereign.png Outdated Show resolved Hide resolved
static/sovereign/to-sovereign.png Outdated Show resolved Hide resolved
Signed-off-by: Andrei Baltariu <[email protected]>
Signed-off-by: Andrei Baltariu <[email protected]>
docs/sovereign/to-sovereign.md Outdated Show resolved Hide resolved
docs/sovereign/from-sovereign.md Outdated Show resolved Hide resolved
Signed-off-by: Andrei Baltariu <[email protected]>
axenteoctavian
axenteoctavian previously approved these changes Jan 17, 2025
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.
Copy link
Contributor

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.
Copy link
Contributor

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_)
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants