Transaction Allocation Mechanism

Provides an overview of the mechanics of workload distribution.

Mechanism

In a group of executors R and a set of meta transactions T, transaction allocation is the process of allocating transactions to executors such that each executor's allocation does not conflict with any other executor in a particular block interval.

Let $A(T, r_i) \subset T$ denote the transactions allotted to executor $r_i ∈ R$, then $\forall (r_i, r_j) \in R \times R, r_i \neq r_j \implies A(T, r_i) \cap A(T, r_j) = \emptyset$

This is achieved using a 2-step mechanism:

1. executor Sampling: Given R, the full list of executors, assignment of the meta transaction to executor r_i is drawn using a probability mass function (PMF) built from the individual ratios of operators stake to the global stake of the network. Let S be the total delegated amount in the network and s_i the amount of stake of the executor r_i, such that $S = \sum_{i=0}^{n-1} s_i$

   The probability of selecting $r_i$ is given by $p(r_i) = \frac{s_i}{S}$ and $\sum_{i=0}^{n-1}p(r_i) = 1$. Each executor is allowed to submit transactions in a block window of fixed length. This selection changes every N block. N is a parameter of the network for each target chain.

2. Direct Allocation: From the full set of pending meta transactions T, meta transactions are allocated to the selected executors based on the hash of calldata, chainId and epoch seed, such that meta transactions are divided uniformly among the selected executors R.

For each executor $r_i$, the assignment function evaluates whether the total cumulative stake of all sorted executors up to and including $r_i$ (referred to as the cumulative interval) $I_i = [S_{i-1}, S_i)$ encompasses the result of a hashing function $H ∈ I_i$. This hashing function processes multiple inputs: the block number range, block hash for the current epoch, the executor's address, and the calldata. The result is then modulated by the total stake (mod $S$) as follows: $H = hash(block \ \space range, random \space hash, executor's address, calldata)\space mod \space S$.

This method ensures that every meta transaction is deterministically assigned to an executor, with no collisions, as for each workflow there is a unique hashing seed probabilistically defining one assigned interval.

The allocation dynamically adjusts to blockchain parameters like block number and random hash. Executors consult workload distributor module of Orchestration Network to ascertain the current network state and retrieve the list of transactions they are authorized to submit. If an executor broadcasts a transaction that is not assigned to them, they will not receive any compensation or reward.

What happens if a executor has a set of transactions allocated and decides not to submit them to the blockchain?

Transactions are reassigned every N block (the length of a window/epoch in the system for each network) in a probabilistic manner. This means that the same transactions will be in the following window submitted by another executor if the currently assigned executor fails to submit the transaction. While an executor can be selected in two consecutive windows, the probability of being selected and to have the same transaction allocated is significantly low.

What happens if an executor is offline?

Executors should submit transactions that are assigned to them in the window. If they fail to follow the rules, they will be penalized by applying a slashing in their delegated stake amount. This mechanism is fully decentralized. Executors are incentivized to raise the dispute for quorum to penalize non compliant executor.

The allocation system uses an entrypoint contract to enforce transaction allocation without the need for achieving consensus among the executors. Parameters of the blockchain are used to reallocate transactions in cases where relayers are offline or irresponsive, ensuring that transactions can not be censored.

Settlement compensation

When executing a meta transaction (workflow), a call is made through an entrypoint contract that stores gas policies. These policies hold parameters that determine the payment amount any contract using the ditto execution layer on the given operating network must pay. These policies limit the maximum gas price that the user will pay, and also set the size of the reward and compensation for the gas used.

The total cost paid by the user for automation services, incentivizing the provision of an optimal gas price by executor, is calculated by the following formula: $Total Cost=GasCompensationQuote×Gas Used×Gas Price+FixedReward$

Where the GasCompensationQuote (determines the amount of gasUsed that will not be compensated) and FixedReward are defined by the protocol decision for each execution network. The distribution of compensations and rewards occurs on the Orchestration Network after inclusion in the state by consensus and is propagated to the execution network through interop. This formula incentivizes the network to provide the optimal gas price so that the execution happens with the maximum possible reward for all participants.

Automation Cancellation Process:

To cancel an automation, it is not enough to cancel it on the Orchestration Network, as the signature exists publicly. To guarantee the cancellation, a transaction must be executed on the target network to invalidate the nonce of the existing signature.

Rewards for Automations

The native currency of the target network is used to pay for automations. Each execution, based on the smart contract logic, calculates the required compensation amount, compensates the executor, and sends a portion to the reward vault in the network through an atomic transaction.

Rewards are collected using a Merkle Root, which is posted to the network depending on the dynamics and policies for that network. The validity of the "permission to withdraw rewards" is verified through signature validation from interop. The decision on slashing is also made in the Orchestration Network.