Billing Mechanism

EIP-7702

Ethereum Improvement Proposals (EIPs) are standards specifying potential new features or processes for Ethereum. EIPs contain technical specifications for the proposed changes and act as the “source of truth” for the community. Network upgrades and application standards for Ethereum are discussed and developed through the EIP process.

source: Ethereum website - Introduction to Ethereum Improvement Proposals (EIPs)

EIP-7702 is a step towards account abstraction, enabling EOAs (Externally Owned Accounts) to have both code and storage.

This enhancement allows EOAs to function as smart contract accounts, unlocking new features such as:

• Transaction batching

• Gas sponsorship

• Delegated actions - Granting other addresses limited access to act on behalf of the EOA

---

Prerequisite: User Authorization

KRNL utilizes EIP-7702 to enable a seamless user experience. The process starts with the user (EOA) signing an authorization request to link a smart contract account (SCA) to their address. This authorization allows them to interact with the KRNL protocol. This setup is a one-time requirement.

---

Execution Flow

DIAGRAM

1. dApp Interaction and Signing

• When a user interacts with a dApp, the frontend detects if the action requires KRNL execution.

• If required, the frontend requests the user to sign an EIP-712 request containing:

  • Function parameters of the interacting smart contract (provided by the user input on the frontend)

  • Kernel parameters for all kernels involved in execution

  • Execution fee for kernel processing

  • Execution nonce (ensuring uniqueness and preventing replay attacks)

• The parameters for signing are sourced from the KRNL registry, except for function parameters, which come from the user input.

2. Authorization Check

• Before execution, the SDK checks if the EOA has authorized the smart contract.

• If not, the user is prompted to sign an authorization request as described in the prerequisite step.

• This check occurs every time the user requests an execution.

3. SDK and RPC Interaction

• The KRNL SDK (krnl-sdk.js) manages all frontend interactions, including authorization and execution requests.

• Upon receiving the signed EIP-712 request, the SDK sends it to the KRNL Geth node via an RPC endpoint.

4. Node Verification and Execution

• The KRNL node verifies the execution signature, ensuring:

  • The nonce has not been used before.

• The node retrieves necessary execution details from smart contract registries deployed on Ethereum. These registries contain execution parameters registered by developers through the KRNL platform.

• The node leverages a GraphQL execution engine to process workflows:

  • Kernels may execute in parallel or sequentially.

  • Execution results can be passed between kernels as needed.

5. Adapter System

KRNL utilizes an adapter system to interact with various environments:

• EVM View Function Adapter: Executes view functions on any EVM-compatible chain.

• Web2 Adapter: Calls RESTful APIs using OpenAPI specifications for standardized interactions. The schemas are stored on IPFS for later querying by the KRNL node.

• Aptos Execution Adapter: Enables function execution on the Aptos blockchain.

6. Attestation

• After execution, the node sends execution details (parameters, results, and nonce) to the attestor.

• The execution signature is included in the attestation request to recover the sender's public address, which is used as one of the parameters in the attestation signature generation.

• The attestor (a decentralized TEE network) verifies the execution and returns a cryptographically signed attestation.

7. Transaction Sponsorship & Execution

• Upon receiving the attestation, the KRNL node creates a transaction containing:

  • Execution parameters

  • Attestation

  • Other necessary metadata

• The transaction is sent to a paymaster, which signs and sponsors the gas fees.

• The transaction calls the smart contract account (SCA) of the user’s EOA, which:

  • Verifies the EIP-712 signature.

  • Passes the function call to the destination contract.

  • Extracts the execution fee, sending it to the KRNL vault.

  • Updates the nonce via the nonce manager contract.

8. Smart Contract Execution

• The destination contract processes the function call via the SCA.

• The KRNL Solidity library verifies:

  • Authorization

  • Attestation

  • Execution results (if required)

• If all checks pass, the function executes successfully.

• All operations, including fee transfer and nonce update, occur atomically within a single transaction.

---

Summary

KRNL provides a seamless and trust-minimized cross-chain execution framework by leveraging EIP-7702 for account abstraction, EIP-712 for signed execution requests, and a decentralized TEE network for attestation. The combination of SDK automation, smart contract registries, and atomic transaction execution ensures secure and efficient cross-chain interactions.