# Execution

The **Execution** component is the "CPU" of the blockchain. It defines the state transition function: `State + Transaction = New State`. It is responsible for taking a block of transactions, verifying them, and applying their changes to the Storage.

## Current Architecture (v0.3.0)

In this iteration, the Execution Engine became "identity-aware." It no longer processes arbitrary commands; it enforces cryptographic ownership and authorization.

### 1. The Signed Transaction

pETHit moved away from processing raw `Transaction` structs. The engine now operates on `SignedTransaction`, which bundles the intent with the authorization.

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct SignedTransaction {
    pub transaction: Transaction, // The Intent (To, Value, Nonce)
    pub signature: Signature,     // The Authorization (r, s)
    pub recovery_id: RecoveryId,  // The Identity Recovery (v)
}

### 2. RLP Serialization

To ensure that the data being signed and hashed is consistent across all nodes (and compatible with Ethereum tooling), **Recursive Length Prefix (RLP)** serialization was implemented manually.

* **Encoding:** Converts the struct into a canonical byte stream: `[nonce, value, to, sig_r, sig_s, v]`.
* **Decoding:** Parses raw network bytes back into the Rust struct. This includes manual handling of the signature bytes to ensure compatibility with standard crypto libraries (alloy_rlp).

### 3. Verification Logic (The Guard)

Before executing any transaction, the engine performs strict validation checks:

1. **Recover Signer:** Using the `Signature` + `RecoveryID`, it mathematically recovers the **Public Key** and derives the **Sender Address**.
2. **Verify Nonce:** Checks if `tx.nonce == account.nonce`. This prevents **Replay Attacks** (sending the same transaction twice).
3. **Verify Balance:** Checks if `account.balance >= tx.value`.
4. **Verify Spender:** Ensures the recovered address matches the claimed sender (implicit in the recovery process).

## API / Usage

The Execution crate exposes the logic to process transactions and blocks.

### Structs

// The core unit of work
pub struct SignedTransaction { ... }

// The inner intent
pub struct Transaction {
    pub to: Address,
    pub value: U256,
    pub nonce: u64,
}

### Public Methods

#### `execute(&mut storage, &signed_tx)`

Tries to apply a single transaction.

* **Recover:** Derives the sender address from the signature.
* **Check:** Verifies Nonce and Balance against the Storage.
* **Apply:** Deducts balance from Sender, adds balance to Receiver, increments Sender's Nonce.
* **Update:** Writes the new account states back to Storage.

#### `SignedTransaction::encode/decode`

Methods for converting the transaction to/from RLP bytes. Used by the RPC (for receiving data) and Storage (for saving data).

#### `SignedTransaction::hash()`

Returns the Keccak256 hash of the RLP-encoded transaction. This is the unique ID (TxHash) used in the TxPool and Block.

## Evolution Log

### v0.1.0: The Calculator

* **Logic:** Simple string manipulation. A transaction was just a Key-Value pair.
* **Action:** `db.put(tx.key, tx.value)`. No checks, no balances.

### v0.2.0: Unique IDs

* **Logic:** Added hashing logic to `Transaction` to give them unique identifiers.
* **Action:** No validation changes, just better identification.

### v0.3.0: The Identity Update

* **Struct Change:** Introduced `SignedTransaction` wrapping the raw `Transaction`.
* **Cryptography:** Integrated `k256` for ECDSA signature recovery.
* **Serialization:** Implemented manual RLP encoding/decoding.
* **Logic Change:** Added "The Guard" (Nonce checks, Balance checks, Signature verification). The engine now rejects invalid transactions instead of blindly applying them.