Skip to content

Conversation

@ZakAyesh
Copy link
Collaborator

Description
Created a guide on how to set the DA footprint

Copy link
Collaborator

@sbvegan sbvegan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's looking good, I've added some suggestions.

| ---------- | ---- | -------- | ------------ | ------------ |
| `daFootprintGasScalar` | Number | 400 | 400 | unitless|

The <strong>Data Availibility (DA) Footprint</strong> feature was introduced in the <strong>Jovian</strong> hardfork to limit the total amount of estimated compressed transaction data that can fit into a block.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The <strong>Data Availibility (DA) Footprint</strong> feature was introduced in the <strong>Jovian</strong> hardfork to limit the total amount of estimated compressed transaction data that can fit into a block.
The <strong>Data Availability (DA) Footprint</strong> feature was introduced in the <strong>Jovian</strong> hardfork to limit the total amount of estimated compressed transaction data that can fit into a block.

| `daFootprintGasScalar` | Number | 400 | 400 | unitless|

The <strong>Data Availibility (DA) Footprint</strong> feature was introduced in the <strong>Jovian</strong> hardfork to limit the total amount of estimated compressed transaction data that can fit into a block.
When an OP Stack chain recieves more calldata heavy transactions than can fit into the L1s availble blob space, [the Batcher](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-batcher-setup#understanding-the-batchers-role)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When an OP Stack chain recieves more calldata heavy transactions than can fit into the L1s availble blob space, [the Batcher](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-batcher-setup#understanding-the-batchers-role)
When an OP Stack chain receives more calldata heavy transactions than can fit into the L1s available blob space, [the Batcher's](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-batcher-setup#understanding-the-batchers-role)


The <strong>Data Availibility (DA) Footprint</strong> feature was introduced in the <strong>Jovian</strong> hardfork to limit the total amount of estimated compressed transaction data that can fit into a block.
When an OP Stack chain recieves more calldata heavy transactions than can fit into the L1s availble blob space, [the Batcher](https://docs.optimism.io/chain-operators/tutorials/create-l2-rollup/op-batcher-setup#understanding-the-batchers-role)
[can throttle it's capacity](https://docs.optimism.io/chain-operators/guides/configuration/batcher#batcher-sequencer-throttling).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[can throttle it's capacity](https://docs.optimism.io/chain-operators/guides/configuration/batcher#batcher-sequencer-throttling).
default behavior will [throttle it's capacity](https://docs.optimism.io/chain-operators/guides/configuration/batcher#batcher-sequencer-throttling).

However, continuous batcher throttling may cause the base fee to drop to the [minimum base fee](https://docs.optimism.io/chain-operators/guides/features/setting-min-base-fee),
causing unnecessary losses for the chain operator and negative user experiences such as priority fee auctions. Limiting the amount of calldata taken up by transactions in an block using the DA Footprint can reduce the need for batcher throttling and the issues that come from throttling.

For every transaction, other than [deposit transactions](https://docs.optimism.io/reference/glossary#deposited-transaction),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we streamline this to, "For every L2 transaction processed by the sequencer, a resource..." and omit the deposit tx part

For every transaction, other than [deposit transactions](https://docs.optimism.io/reference/glossary#deposited-transaction),
processed by an OP Stack chain, a resource called DA Footprint is tracked alongside the transaction's gas usage.
The DA Footprint can be configured via the `daFootprintGasScalar` variable in the `SystemConfig` contract on the L1 chain.
The Da Footprint is automatically calculated for every transaction first by calculating a `daUsageEstimate` for that transaction:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Da Footprint is automatically calculated for every transaction first by calculating a `daUsageEstimate` for that transaction:
The DA Footprint is automatically calculated for every transaction first by calculating a `daUsageEstimate` for that transaction:

- Setting the `daFootprintGasScalar` too low may prove ineffective at preventing batcher throttling or protecting against spam.
- When a chain's gas limit is changed, the DA footprint scales proportionally by design. However you want to retain the same absolute DA footprint limit, then you must the also change the `daFootprintGasScalar`.
- If no limit is set, or the value 0 is set for the daFootprintGasScalar in the SystemConfig, the default value of 400 is used
- If the feature is diabled, set the scalar to a very low value such as 1.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- If the feature is diabled, set the scalar to a very low value such as 1.
- If the feature is disabled, set the scalar to a very low value such as 1.


<Warning>
- Setting the `daFootprintGasScalar` too high may exclude too many transactions from your blocks.
- Setting the `daFootprintGasScalar` too low may prove ineffective at preventing batcher throttling or protecting against spam.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Setting the `daFootprintGasScalar` too low may prove ineffective at preventing batcher throttling or protecting against spam.
- Setting the `daFootprintGasScalar` too low may prove ineffective at preventing batcher throttling or protecting against continuous DA heavy transactions.


<Step title="Call the setDAFootprintGasScalar() method">
<Info>
Note that the owner of the `SystemConfig` contract is the [System Config Owner address](https://docs.optimism.io/chain-operators/reference/privileged-roles#system-config-owner), so this transaction must be sent from that address.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note that the owner of the `SystemConfig` contract is the [System Config Owner address](https://docs.optimism.io/chain-operators/reference/privileged-roles#system-config-owner), so this transaction must be sent from that address.
The [SystemConfig owner](https://docs.optimism.io/chain-operators/reference/privileged-roles#system-config-owner) is the only address that can make these changes.

Example (using [cast](https://getfoundry.sh/cast/reference/cast/)):

```
cast send <SYSTEM_CONFIG_PROXY_ADDRESS> "daFootprintGasScalar(uint16)" 405
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk if there's a way we can fix this, but when it renders the button's cover up the test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants