Skip to content

Replicas do not have a way to get the execution gas price from sequencers #528

@tynes

Description

@tynes

The sequencer is ultimately in control of choosing what the fees are. Right now (#519), replicas compute client side what the fee is using the same algorithm as the sequencer. This is not scalable long term as the replicas are unaware of the congestion. A possible work around would be to put information about the congestion into the state. Another solution would be to have all replicas query out to the sequencer, but this is not scalable for the sequencer as it could ddos the node. The proposed solution involves having a single source of truth that lives outside of geth and the replicas that is referenced for the fees.


From #557

After some brainstorming about setting the ExecutionPrice longer term, if it is set via IPC then the problem is that it will also need to be set via IPC for all replicas/verifiers at the same time. This is a large coordination problem that adds a lot of overhead, basically if we want to up the fee then we will need to have everybody reconfigure their nodes. Longer term the ExecutionPrice could live in the L2 state. The value could be updated behind an onlySequener modifier and the Sequencer RPC would reject transactions that do not pay a large enough fee. A problem with this approach is that verifiers that listen to L1 will have a lag in updates to the value since they will not see the updates until the transactions are batch submitted. This problem could be mitigated by only allowing fee changes every so many blocks and allowing it to only change by deterministic amounts, but that adds complexity and the problem space should be explored in greater depth. Verifiers will always be at a disadvantage compared to replicas, since replicas sync from the sequencer but there is risk involved since that data isn't technically the source of truth. A malicious sequencer may lie.

Short term we do not need this value to be pulled from the L2 state but we definitely would like it to be pulled from the L2 state before the Uniswap v3 launch. We would be able send transactions to the sequencer that updates the ExecutionPrice from a multisig to make sure the system does not get overwhelmed

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-featureCategory: features

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions