# KRNL Node

### Introduction

The KRNL Node is the heart of the KRNL Protocol—a decentralized orchestration engine that enables cryptographically verifiable workflows bridging Web2 services, blockchain interactions, and AI agents. Built as a non-invasive extension to go-ethereum (Geth), it allows developers to execute secure off-chain computations without compromising Ethereum’s consensus or relying on trusted third parties.

Whether you're building a DeFi yield optimizer, a compliance tool for real-world assets, or an AI-driven dApp, the KRNL Node handles complex workflows with end-to-end cryptographic proof, ensuring smart contracts can trust off-chain data as if it were on-chain.

{% hint style="success" %}

> **New to development? No worries, here are some of the terms to keep in mind while reading this page:**
>
> * ***Workflow/DSL***: A plan with tasks, like a recipe.
> * ***Sandbox/gVisor***: A safe isolated space where tasks run within a controlled environment.
> * ***Proof***: A digital stamp showing the task was done right. This stamp is created using a key only known to the one requesting the execution and one executing it
> * ***Geth***: It's a software which let's you run the Ethreum blockchain on your system
> * ***Executor:*** Open-source, community-audited code that runs a workflow step like calling an API or calling the balanceOf() on a contract.
> * ***Attestor*****:** Developer-controlled component that signs and verifies execution like a check if things are good to go
> * ***Bundler/Relayer:*** Think of it as parcel delivery system which deliver your parcel (KRNL response) to the recipient (Target Smart Contract) where a may or may not paymaster pays for the cost of the delivery (Gas fees)
>   {% endhint %}

### How it works

The KRNL-Node works as follow on a high level:

1. **Receives** a workflow request (via KRNL SDK or Smart Contract Account).
2. **Parses** the workflow DSL into a Directed Acyclic Graph (DAG).
3. **Executes** each step in an isolated gVisor sandbox.
4. **Signs** all network traffic (HTTP/HTTPS, DNS) for full attestation.
5. **Generates** a cryptographic proof using ephemeral keys.
6. **Bundles** results into a UserOp for on-chain execution via a relayer.

### Architecture Overview

The KRNL Node extends Geth without modifying its core codebase, running workflow orchestration as parallel services. This "additive-only" design preserves 100% Ethereum Foundation compliance.

At its foundation:

* **Core Geth Integration**: The node leverages Geth's battle-tested Ethereum client for blockchain interactions. 
* **Workflow Engine**: Processes KRNL DSL-defined workflows as DAGs, where each step (or "kernel") is an isolated task like an HTTP request, EVM query, or AI inference.
* **Security Layer**: Uses gVisor for sandboxing, ephemeral keys for signing, and a novel executor-attestor separation model to ensure trustless execution.
* **Network Attestation**: Monitors and cryptographically signs all outbound/inbound traffic (HTTP/HTTPS, DNS), providing forensic-level transparency.

Here's a high-level diagram of the architecture:

```
KRNL Node
├── Workflow Orchestrator
│   ├── DAG Parser (from KRNL DSL)
│   ├── Step Scheduler
│   └── Input/Output Binding
├── gVisor Sandbox Manager
│   ├── Executor Loader (Open-Source, Community-Verified)
│   └── Attestor Loader (Closed-Source, Developer-Controlled)
└── Proof Generator
    ├── Ephemeral Key Derivation
    └── Network Interceptor (HTTP/HTTPS + DNS)
```

The node receives workflow requests executes them in isolated environments, attests to the results, and bundles outputs for on-chain delivery.

### Key Capabilities

The KRNL Node isn't just a runner—it's a verifiable execution platform. Here's what it enables:

1. **Workflow Orchestration as DAGs** execute multi-step logic defined in KRNL DSL. For example, a workflow might fetch telemetry from a Web2 API, read an EVM balance, encode results into calldata, and bundle it into an ERC-4337 UserOp.
   * **When to Use**: For complex automation like cross-chain yield farming or pre-transaction compliance checks.
   * **Example DSL Snippet** 

     ```json
     {
       "name": "fetch-telemetry",
       "type": "HTTP",
       "image": "ghcr.io/krnl-labs/executor-http@sha256:...",
       "attestor": "https://public.mypinata.cloud/ipfs/...",
       "inputs": {
         "url": "https://api.example.com/telemetry",
         "method": "GET"
       },
       "outputs": [{ "name": "data", "value": "response.body" }]
     }
     ```
2. **gVisor Sandbox Isolation** Each workflow step runs in a user-space kernel sandbox with syscall interception. This provides multi-dimensional isolation to prevent escapes or tampering.
3. **Executor & Attestor Management**
   * **Executors**: Community-reviewed, open-source containers for task logic. These are the doers which will go the do the task specified in the DSL workflow
   * **Attestors**: Developer-controlled for signing results and monitoring traffic. 
4. **Cryptographic Proof Generation** Every execution produces composable proofs using ephemeral keys (derived from master secrets + context). This prevents replays and binds proofs to specific workflows.
   * **Network Attestation**: Signs full HTTP/HTTPS requests/responses and DNS resolutions for transparency.
5. **Bundling & Relaying** Outputs are ABI-encoded, wrapped in AuthData structs, and bundled into UserOps for relayers (e.g., Pimlico). The node signs and sends these to external bundlers for on-chain execution.

In summary KRNL node is the heart of the KRNL protocol, which orchestrates the end-to-end flow in a decentralized architecture

### What's next?

{% content-ref url="executors" %}
[executors](https://docs.krnl.xyz/core-concepts/executors)
{% endcontent-ref %}