> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base.org/llms.txt
> Use this file to discover all available pages before exploring further.

# L2 Execution Engine

> Execution engine changes in the Fjord upgrade, replacing the L1 cost fee estimator with a FastLZ-based compression model.

## Fees

### L1-Cost fees (L1 Fee Vault)

#### Fjord L1-Cost fee changes (FastLZ estimator)

Fjord updates the L1 cost calculation function to use a FastLZ-based compression estimator.
The L1 cost is computed as:

```pseudocode theme={null}
l1FeeScaled = l1BaseFeeScalar*l1BaseFee*16 + l1BlobFeeScalar*l1BlobBaseFee
estimatedSizeScaled = max(minTransactionSize * 1e6, intercept + fastlzCoef*fastlzSize)
l1Fee = estimatedSizeScaled * l1FeeScaled / 1e12
```

The final `l1Fee` computation is an unlimited precision unsigned integer computation, with the result in Wei and
having `uint256` range. The values in this computation, are as follows:

| Input arg            | Type      | Description                                                       | Value                    |
| -------------------- | --------- | ----------------------------------------------------------------- | ------------------------ |
| `l1BaseFee`          | `uint256` | L1 base fee of the latest L1 origin registered in the L2 chain    | varies, L1 fee           |
| `l1BlobBaseFee`      | `uint256` | Blob gas price of the latest L1 origin registered in the L2 chain | varies, L1 fee           |
| `fastlzSize`         | `uint256` | Size of the FastLZ-compressed RLP-encoded signed tx               | varies, per transaction  |
| `l1BaseFeeScalar`    | `uint32`  | L1 base fee scalar, scaled by `1e6`                               | varies, L2 configuration |
| `l1BlobFeeScalar`    | `uint32`  | L1 blob fee scalar, scaled by `1e6`                               | varies, L2 configuration |
| `intercept`          | `int32`   | Intercept constant, scaled by `1e6` (can be negative)             | -42\_585\_600            |
| `fastlzCoef`         | `uint32`  | FastLZ coefficient, scaled by `1e6`                               | 836\_500                 |
| `minTransactionSize` | `uint32`  | A lower bound on transaction size, in bytes                       | 100                      |

Previously, `l1BaseFeeScalar` and `l1BlobFeeScalar` were used to encode the compression ratio, due to the inaccuracy of
the L1 cost function. However, the new cost function takes into account the compression ratio, so these scalars should
be adjusted to account for any previous compression ratio they encoded.

##### FastLZ Implementation

All compression algorithms must be implemented equivalently to the `fastlz_compress` function in `fastlz.c` at the
following [commit](https://github.com/ariya/FastLZ/blob/344eb4025f9ae866ebf7a2ec48850f7113a97a42/fastlz.c#L482-L506).

##### L1-Cost linear regression details

The `intercept` and `fastlzCoef` constants are calculated by linear regression using a dataset
of previous L2 transactions. The dataset is generated by iterating over all transactions in a given time range, and
performing the following actions. For each transaction:

1. Compress the payload using FastLZ. Record the size of the compressed payload as `fastlzSize`.
2. Emulate the change in batch size adding the transaction to a batch, compressed with Brotli 10. Record the change in
   batch size as `bestEstimateSize`.

Once this dataset is generated, a linear regression can be calculated using the `bestEstimateSize` as
the dependent variable and `fastlzSize` as the independent variable.

We generated a dataset from two weeks of post-Ecotone transactions on Optimism Mainnet, as we found that was
the most representative of performance across multiple chains and time periods. More details on the linear regression
and datasets used can be found in this [repository](https://github.com/roberto-bayardo/compression-analysis/tree/main).

### L1 Gas Usage Estimation

The `L1GasUsed` property is deprecated due to it not capturing the L1 blob gas used by a transaction, and will be
removed in a future network upgrade. Users can continue to use the `L1Fee` field to retrieve the L1 fee for a given
transaction.