You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to stabilize the EVM GW - it intermittently stops ingesting blocks and need to be restarted manually, after oncall is alerted.
The demands on EVM GW are growing as more partners are onboarding to FLOW. The EVM GW is relying on Access and Execution nodes to get execution state data, executing trace calls and getting debug traces, which is inefficient (was implemented as short-term work-around) and pushes ANs and ENs to their limits. We need to enable partners to run their own EVM GW with customs config, so we can take the load from the ANs and ENs by enabling dry-run on the EVM GW itself. EVM GW implementing dry-run also enables partners to customize the GW to provide only those debug tracers they require for their workflow.
How will we measure success (Key Results) ?
EVM GW runs without block ingestion stalls for 4 weeks.
Dry-run - ANs and ENs are no longer loaded by dry-run & other queries / calls.
Enables adding custom debug_trace to the EVM GW when re-executing Txs.
Alexar is able to deploy [30] their own GWs with minimal support from FF.
Alchemy endpoints are unblocked after the dry-run is deployed on FF-run GW.
Why (Objective)
How will we measure success (Key Results) ?
Effort Estimate
DACI
EVM GW stabilization
Dry-run feature
Stabilization
Dry-run (reducing the GW dependency on the AN)
Operationalizing the EVM GW for partners
The text was updated successfully, but these errors were encountered: