Turbo

Seamless Blockchain Data Access

Turbo is a powerful smart contract interface that enables smart contract developers to seamlessly integrate Storage Proofs into their applications. By abstracting away the complexities involved in generating storage proofs, Turbo provides a user-friendly way to access and utilize blockchain data.

How Turbo Works

Turbo serves as a smart contract interface for the Herodotus API. When a transaction is sent to a smart contract that integrates Turbo, it triggers Herodotus infrastructure to generate all the necessary storage proofs behind the scenes. These proofs are essential for the successful execution of the transaction.

Usage

To use Turbo, you need to integrate it into your smart contract. Here's an example of how to access on-chain data using Turbo in Solidity:

function proveHeaderProperty(
    uint256 chainId,
    uint256 blockNumber,
    HeaderProperty property
) external {
    bytes32 provenProperty = turboSwap.headers(
        chainId,
        blockNumber,
        property
    );

    // Store the proven property to this contract storage
    headerProperties[chainId][blockNumber][property] = provenProperty;
    isProven[chainId][blockNumber][property] = true;
}

To interact with Turbo-integrated smart contracts, transactions need to be submitted through a special RPC called a Turbo RPC. Please refer to the list of RPCs for each network below.

Turbo Transaction Workflow

1. Initiation: The process begins when a user initiates a transaction (Tx) targeting a turbo-enabled smart contract.

2. Turbo Enabled RPC: The transaction is processed through the "Turbo Enabled RPC," which acts as an interface to facilitate the transaction's journey.

3. Simulated Transaction Execution: Here, the transaction is simulated to check if it requires a storage proof or HDP task execution.

   • If the transaction does not require storage proof, it's deemed successful and directly forwarded to the Validator/Sequencer.

   • If the transaction requires a storage proof but lacks it, the transaction fails. In such cases, the system traces the transaction to identify the necessary storage proofs.

4. Herodotus API Query Builder: Once the need for storage proof is determined, the "Herodotus API Query Builder" constructs an API request, aimed at retrieving the required storage proofs from the off-chain Herodotus API.

5. Turbo Bundle Builder: Upon receiving the storage proof from the Herodotus API, the Turbo Bundle Builder creates a bundle of transactions known as the "Herodotus Turbo Bundle."

   • The first transaction in this bundle verifies the validity of the retrieved storage proof and assigns the proven data to a set of variables.

   • Subsequent transactions within the bundle then utilize these variables.

   • The last transaction in the bundle clears the storage proof variables, ensuring that there are no state differences. (Particularly useful for zk-rollups)

6. Validator/Sequencer Integration: Finally, this crafted bundle is forwarded to either a sequencer or validator which include the bundle into the blockchain.

Synchronous Transactions

One of the key advantages of Turbo is that it offers synchronous transactions from an end-user perspective. When a user sends a transaction involving Turbo, they don't need to take any additional steps. The transaction is processed seamlessly, and the user can sit back and wait for the transaction to be executed.

This synchronous nature of Turbo transactions represents a significant step forward in addressing the increasing fragmentation of the Ethereum ecosystem. With Turbo, users no longer have to navigate complex workflows or interact with multiple systems to complete a transaction.

The Trade-off: Slightly Longer Transaction Times

It's important to note that the convenience of synchronous transactions comes with a trade-off. Transactions involving Turbo may take slightly longer to complete compared to regular transactions. This is because the storage proofs required for the transaction need to be generated and verified before the transaction can be executed.

However, we believe that this increased transaction time is a small price to pay for the enhanced user experience and seamless integration provided by Turbo.

Data Accessible through Turbo

Turbo provides access to a wide range of data that Herodotus can provide, including:

• Headers

• Accounts

• Storage

• Receipts (coming soon)

• Transactions (coming soon)

• Verifiable Compute through HDP (coming soon)

Interfaces

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.17;

interface IFactsRegistry {}

enum HeaderProperty {
    PARENT_HASH,
    UNCLE_HASH,
    COINBASE,
    STATE_ROOT,
    TRANSACTIONS_ROOT,
    RECEIPTS_ROOT,
    LOGS_BLOOM,
    DIFFICULTY,
    BLOCK_NUMBER,
    GAS_LIMIT,
    GAS_USED,
    TIMESTAMP,
    EXTRA_DATA,
    MIX_HASH,
    NONCE,
    BASE_FEE_PER_GAS,
    WITHDRAWALS_ROOT,
    BLOB_GAS_USED,
    EXCESS_BLOB_GAS,
    PARENT_BEACON_BLOCK_ROOT
}

enum AccountFields {
    NONCE,
    BALANCE,
    STORAGE_ROOT,
    CODE_HASH
}

interface ITurboSwap {
    function factsRegistries(
        uint256 chainId
    ) external returns (IFactsRegistry factsRegistry);

    function storageSlots(
        uint256 chainId,
        uint256 blockNumber,
        address account,
        bytes32 slot
    ) external returns (bytes32);

    function accounts(
        uint256 chainId,
        uint256 blockNumber,
        address account,
        AccountFields field
    ) external returns (bytes32);

    function headers(
        uint256 chainId,
        uint256 blockNumber,
        HeaderProperty property
    ) external returns (bytes32);
}

Fees

Note: In Testnet fees are not required.

When interacting with Turbo you are expected to pay the Turbo operator for your transactions through a smart contract by using feeToken.transfer(operator, AMOUNT_TO_TRANSFER).

If the fee is too low the transaction won't be picked up by the RPC.