Transaction flow

Learn how Asterizm Protocol operates

Asterizm architecture

packet - data packet containing cross-chain transaction content and related parameters;

payload - message/data transmitted as part of a cross-chain transaction;

dst - destination network ID;

xID - a unique cross-chain transaction ID generated when the cross-chain transaction is initialized
 in the _initAsterizmTransferEvent() method;

p - additional parameters of the transaction: address of the source contract, destination contract, timestamp, and other data.

Complete information can be found in Section 2 of the White paper

Step 1

The client implements a smart contract using an abstract class from Asterizm and deploys it to the required networks. The _initAsterizmTransferEvent() method is used to initiate a cross-chain transaction on the contract. The data and parameters of the cross-chain transaction are transmitted to it.

The transaction can contain arbitrary information and one or more actions (instructions) to be performed on the destination networks.

Step 2

The client smart contract sends the received data and hash based on the payload generated at that moment xID, source chain id, destination chain id, client smart contract address in the source and destination chains.

At this step, the key parameters are formed, which will further ensure the security of the cross-chain transaction, namely to confirm its validity and integrity in the destination chain.

Step 3

The Client off-chain module receives the cross-chain transaction payload and initiates the cross-chain transaction by calling initAsterizmTransfer() on the client's smart contract in the source network.

Step 4

Before sending transaction proofs (hash and xID) to the Initializer contract, the Сlient s smart contract performs a validity and integrity check of the transaction by comparing the hash, calculated based on the payload. This effectively mitigates the risk of spam and counterfeit transactions in case of compromise of the Client server.

This step verifies that this exact transaction was initiated on the client's smart contract, which eliminates the possibility of spam from the client's off-chain module.

Step 5

The Initializer smart contract checks the transaction nonce to preserve the cross-chain transaction execution sequence and transmits the transaction proofs (hash and xID) with the unique parameters to the Translator smart contract.

When a data packet is received on the Initializer smart contract, the client is identified based on the destination
 chain id, the Client smart contract address in the destination chain, and the client smart contract address in the source chain.

After the client (sender) of the cross-chain transaction is determined, the nonce value is incremented for it.

Step 6

Asterizm Relayer servers pull the proofs with the parameters from the Translator contract and send them to the Translator smart contract in the destination network for further processing.

Step 7

The Translator smart contract on the destination network accepts the encrypted data with the parameters from the Relayers and passes it to the Initializer smart contract for validation.

Step 8

After receiving the proofs and the parameters, the Initializer smart contract checks the nonce to comply with the transaction sequence, stores the transaction xID to validate the transaction at step 10, and transmits the proofs to the Client’s smart contract.

Step 9

The Client's smart contract in the destination network receives the proofs with the parameters and emits an event to notify the delivery of proofs, which is awaited by the Client's off-chain module.

At this stage, the first but not the main step of transaction validity check occurs - the hash from the payload and the transaction's xID are compared, mitigating the risk of relay server compromise.

Step 10

After the first step of cross-chain transaction validation, the client’s server initiates the transaction on the Client’s smart contract by calling the asterizmClReceive() method in the destination network, sending the payload (data) and xID to the contract, and validating the transaction on the Initializer smart contract by calculating the hash from received payload and checking the xID.

At this step, the integrity of the data and the trusted addresses is checked before the transaction is executed. This check eliminates the risk of hacking the client’s server.

The verification is performed by calculating and matching the hash from the payload with the hash received from Relayers and the xID that was previously stored on the Initializer contract. If the verification succeeds, it means that the client’s contract executes exactly the transaction it sent, and does so for the first time. This algorithm eliminates the possibility of spamming transactions and spoofing data on the client’s server (if, for example, the server is compromised).

Step 11

After receiving the confirmation of the validity and integrity of the cross-chain transaction, the client’s smart contract executes the payload or data sent in the cross-chain transaction, calling methods of other contracts or performing calculations on the client’s contract. The logic of this step depends solely on the client’s business logic implemented in the cross-chain transaction.