Design Architecture

In-depth design architecture of Skate

Skate operates at both the Execution Layer and Consensus Layer, and is comprised of 3 main components:

  1. Skate Validator Network: independent, lightweight validator nodes that have staked tokens as collateral.

  2. Rollup (consists of Gateway Contracts)

  3. Relayer (operates in the execution layer)

Skate Validator Network

The Skate Validator Network consists of independent, lightweight validator nodes whose underlying consensus mechanism is based on EigenLayer.

To become a validator, individuals must participate in the EigenLayer protocol, locking up a certain amount of tokens as collateral. In the event of dishonest behavior, these tokens will be slashed to ensure the integrity of the network.

For example, a validator could maliciously collude to steal funds for a Skate transaction. However, as they’ve restaked ETH and committed it as collateral, this would be slashed and used to compensate victims, in turn heavily disincentivizing malicious behavior.

Rollup

Skate will operate as an optimistic rollup based on the OP Stack stack.

Initially, there will be a centralized sequencer, which is responsible for ordering transactions before they are finalized on the Ethereum mainnet. However, we plan to increase decentralization by either transitioning to a network of sequencer nodes, or integrating a scalable decentralized sequencer such as Espresso Systems.

For the initial version, batcher and proposer nodes will be run by the Skate team.

Relayer

The Relayer is a high-performance client maintained by the Skate team that acts as the primary point of contact between different chains and the Skate Validator Network.

It serves three key functions:

  1. Actively monitoring and listening for any outbound events on supported chains. For example, a user wishing to transfer funds across networks.

  2. Publishing tasks for the Skate Validator Network. For example, preparing call data on the Polygon network request to be executed on Arbtrium.

  3. Handling cross-chain task responses as required by applications and contracts integrated with Skate across various chains.

Skate Fast Finality Layer - an Eigenlayer AVS

Skate’s Fast Finality Layer (FNN) operates as an Actively Validated Service (AVS) on EigenLayer, which refers to a system leveraging EigenLayer for security. The AVS revolves around a decentralized network of validators who must register as operators by staking a specified amount of ETH as an insurance fund, termed "restakers". Any malicious actions by an operator will result in their fund being slashed and credited to Skatechain.

The primary purpose of the AVS is to facilitate access to the state of the Skate hub's chain through pull-based requests. This is because transactions are executed by users signing “intents” (meaning orders) between networks, which requires that those facilitating these intents (“Executors”) can see the state of each network. For example, if a request were made to transfer $1,000 from Ethereum to Solana, an Executor would need to confirm that assets existed on Ethereum and were successfully transferred to Solana. Therefore, Skate pulls states from various sources, then uses EigenLayer to ensure fast finality.

To enable this, validators run specialized software and indexers to gather and prepare the required data. When a request is made, the AVS validators craft executable calldata encoding the appropriate function calls and parameters to be executed against the settlement chain's state, allowing it to reflect the current hub chain state.

AVS Tasks

The main job of the AVS is to create a set of instructions called "calldata" based on a given task. This calldata includes the specific function calls and parameters that need to be executed on another blockchain.

Correct Response: The AVS must generate calldata that accurately encodes the required function calls and parameters for execution. This ensures the correct state transition on the settlement chain, reflecting the hub chain's state.

Incorrect Response: An incorrect response from the AVS would generate calldata that fails to match properly encoded functions and parameters required for execution. This could arise from several issues, such as:

  1. Wrong function signatures

  2. Incorrect parameters

  3. Improper encoding using the wrong encoders leads to missing bytes or incorrect data.

Slashing Mechanism

To uphold the integrity and reliability of the Autonomous Validator Service (AVS), a robust slashing mechanism is implemented on Eigenlayer. This mechanism serves as a deterrent against dishonest behavior by validators. In case a validator submits an incorrect response, whether intentionally or negligently, their staked insurance fund on Eigenlayer will be slashed and forfeited to Skatechain.

This financial penalty strongly incentivizes validators to operate honestly and consistently provide accurate calldata to the AVS.

Execution Flow

Below is the flow of executing an intent:

Transaction Request Flow

Pre-requisite: An off-chain component is responsible for receiving off-chain intents, that encapsulate a user's signature, through a frontend interface.

  1. The Skate Global State smart contract processes intents by invoking the fulfilIntent() function.

  • This process triggers the creation of a new Task within the smart contract system. Each Task is assigned a unique taskId, for subsequent retrieval calls.

  1. Following the task instantiation process, the fulfilIntent() function execution yields the assignment of a taskId, exemplified as taskId = 10, which is relayed back to the executor.

    • The executor then proceeds to invoke the executeTask() function, specifying taskId, on the destination chain.

    • This action initiates a skate pull request for taskId and emits an event on the SkateGatewayApp.

  2. Concurrently, the Skate Relayer actively monitors these state events across all chains, facilitating the relay of requests to the Skate Validator Network upon detection.

    • The relayer will create a task and publish it for validation.

  3. Upon receiving the new task, each Skate validator retrieves the requisite task details by invoking the getTask() function, passing taskId 10 as a parameter.

    • Each validator will respond to the task by sending the prepared calldata to the relayer.

    • The relayer, upon receiving calldata from the validators, undertakes the aggregation of all received responses

    • Following this aggregation process, the relayer initiates a consensus mechanism to determine the outcome.

      • If a majority consensus is attained by achieving the requisite consensus threshold among the collected responses, the relayer proceeds to sign and generate a final result

      • The relayer will return this response to the executor through the frontend

  4. The executor will take this response go to the destination chain and call executeIntent() with provided bytes calldata via SkateGatewayApp contract

  5. The generated calldata will undergo an authentication process using the generated signature

    If it is valid, execute the required calldata. Calldata will be in the format of

    struct Call {
      address target;
      bytes callData;
    }

    and will be the calls will be executed with a multi-call

    function aggregate(Call[] memory calls) 
      public returns (uint256 blockNumber, bytes[] memory returnData) {
      blockNumber = block.number;
      returnData = new bytes;
      for(uint256 i = 0; i < calls.length; i++) {
        (bool success, bytes memory ret) = calls[i].target.call(calls[i].callData);
        require(success);
        returnData[i] = ret;
      }
    }

Skate Rollup

Content TBC

Skate Relayer design

Content TBC

Last updated