From 29b3afeff3d2dba3b61f1fe9a53732a7d7734e39 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Thu, 28 Jul 2022 16:21:33 +0600 Subject: [PATCH 1/6] Elaborate on why sync optimistically --- sync/optimistic.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/sync/optimistic.md b/sync/optimistic.md index c2f06a9be0..6af886814b 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -270,6 +270,23 @@ optimistic blocks (and vice-versa). ## Design Decision Rationale +### Why sync optimistically? + +Most of execution engines use state sync as a default sync mechanism on Ethereum Mainnet +because executing blocks from genesis takes several weeks on commodity hardware. + +State sync requires the knowledge of the current head of the chain to eventually converge. +If not constantly fed with the most recent head, state sync won't be able to complete +because the recent state soon becomes unavailable due to state trie pruning. + +Optimistic block import (i.e. import without waiting for a payload to be executed by the engine) +breaks a deadlock between the state sync and processing a beacon block by skipping payload +execution as long as execution engine is syncing. + +Optimistic sync works nicely with execution engines using block execution as a default +sync mechanism (e.g. Erigon). It makes optimistic sync a *generalized* solution for +interaction between consensus and execution engine during the sync process. + ### Why `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY`? Nodes can only import an optimistic block if their justified checkpoint is From 47ee4308fc9e5e7f44bae7b92787b337c29642d5 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Fri, 29 Jul 2022 17:31:32 +0600 Subject: [PATCH 2/6] Apply suggestions from code review Co-authored-by: Hsiao-Wei Wang --- sync/optimistic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index 6af886814b..6d8f67e424 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -272,10 +272,10 @@ optimistic blocks (and vice-versa). ### Why sync optimistically? -Most of execution engines use state sync as a default sync mechanism on Ethereum Mainnet +Most execution engines use state sync as a default sync mechanism on Ethereum Mainnet because executing blocks from genesis takes several weeks on commodity hardware. -State sync requires the knowledge of the current head of the chain to eventually converge. +State sync requires the knowledge of the current head of the chain to converge eventually. If not constantly fed with the most recent head, state sync won't be able to complete because the recent state soon becomes unavailable due to state trie pruning. From a3b7c6c5055fccdf529145f63946a75108910001 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Tue, 2 Aug 2022 12:25:15 +0600 Subject: [PATCH 3/6] Apply suggestions from code review Co-authored-by: Danny Ryan --- sync/optimistic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index 6d8f67e424..1511ce8594 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -279,9 +279,9 @@ State sync requires the knowledge of the current head of the chain to converge e If not constantly fed with the most recent head, state sync won't be able to complete because the recent state soon becomes unavailable due to state trie pruning. -Optimistic block import (i.e. import without waiting for a payload to be executed by the engine) -breaks a deadlock between the state sync and processing a beacon block by skipping payload -execution as long as execution engine is syncing. +Optimistic block import (i.e. import when the execution engine *cannot* currently validate the payload) +breaks a deadlock between the execution layer sync process and importing beacon blocks +while the execution engine is syncing. Optimistic sync works nicely with execution engines using block execution as a default sync mechanism (e.g. Erigon). It makes optimistic sync a *generalized* solution for From b9476bf0ee529bbbaee5e492888468f249d8c058 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Tue, 2 Aug 2022 20:04:10 +0600 Subject: [PATCH 4/6] Expand on opti-sync in context of block sync --- sync/optimistic.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index 1511ce8594..b2a30aef68 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -283,9 +283,14 @@ Optimistic block import (i.e. import when the execution engine *cannot* currentl breaks a deadlock between the execution layer sync process and importing beacon blocks while the execution engine is syncing. -Optimistic sync works nicely with execution engines using block execution as a default -sync mechanism (e.g. Erigon). It makes optimistic sync a *generalized* solution for -interaction between consensus and execution engine during the sync process. +Optimistic sync is also an optimal strategy for execution engines using block execution as a default +sync mechanism (e.g. Erigon). Alternatively, a consensus engine may inform the execution engine with a payload +obtained from a checkpoint block, then wait till the execution layer catches up with it and proceed +in lock step after that. This alternative approach would keep user in limbo for several hours and +would increase time of the sync process as batch sync has more opportunities for optimisation than the lock step. + +Aforementioned premises make optimistic sync a *generalized* solution for interaction between consensus and +execution engines during the sync process. ### Why `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY`? From 9352f127ef1c3cc324749ae8f82d00daea578953 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Tue, 9 Aug 2022 07:49:41 -0600 Subject: [PATCH 5/6] minor typo --- sync/optimistic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sync/optimistic.md b/sync/optimistic.md index b2a30aef68..ea0ed75007 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -285,7 +285,7 @@ while the execution engine is syncing. Optimistic sync is also an optimal strategy for execution engines using block execution as a default sync mechanism (e.g. Erigon). Alternatively, a consensus engine may inform the execution engine with a payload -obtained from a checkpoint block, then wait till the execution layer catches up with it and proceed +obtained from a checkpoint block, then wait until the execution layer catches up with it and proceed in lock step after that. This alternative approach would keep user in limbo for several hours and would increase time of the sync process as batch sync has more opportunities for optimisation than the lock step. From f92312c59df908ece4e429c345ed9e12135098b9 Mon Sep 17 00:00:00 2001 From: Hsiao-Wei Wang Date: Tue, 9 Aug 2022 22:00:00 +0800 Subject: [PATCH 6/6] Update ToC --- sync/optimistic.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sync/optimistic.md b/sync/optimistic.md index c205773cbd..dc69135de6 100644 --- a/sync/optimistic.md +++ b/sync/optimistic.md @@ -24,6 +24,7 @@ - [Participating in Sync Committees](#participating-in-sync-committees) - [Ethereum Beacon APIs](#ethereum-beacon-apis) - [Design Decision Rationale](#design-decision-rationale) + - [Why sync optimistically?](#why-sync-optimistically) - [Why `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY`?](#why-safe_slots_to_import_optimistically) - [Transitioning from VALID -> INVALIDATED or INVALIDATED -> VALID](#transitioning-from-valid---invalidated-or-invalidated---valid) - [What about Light Clients?](#what-about-light-clients)