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
refactor(block): log error on data verification failed (#2624)
<!--
Please read and fill out this form before submitting your PR.
Please make sure you have reviewed our contributors guide before
submitting your
first PR.
NOTE: PR titles should follow semantic commits:
https://www.conventionalcommits.org/en/v1.0.0/
-->
## Overview
Looks like we we never logging the error when data verification failed.
This changes isValidSignedData to return an error with the cause instead
of true/false
<!--
Please provide an explanation of the PR, including the appropriate
context,
background, goal, and rationale. If there is an issue with this
information,
please provide a tl;dr and link the issue.
Ex: Closes #<issue number>
-->
Copy file name to clipboardExpand all lines: docs/learn/specs/block-manager.md
+25-25Lines changed: 25 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -456,7 +456,7 @@ The `DataStoreRetrieveLoop`:
456
456
- Operates at `BlockTime` intervals via `dataStoreCh` signals
457
457
- Tracks `dataStoreHeight` for the last retrieved data
458
458
- Retrieves all data blocks between last height and current store height
459
-
- Validates data signatures using `isValidSignedData`
459
+
- Validates data signatures using `assertValidSignedData`
460
460
- Marks data as "seen" in the data cache
461
461
- Sends data to sync goroutine via `dataInCh`
462
462
@@ -568,30 +568,30 @@ The communication with DA layer:
568
568
569
569
## Assumptions and Considerations
570
570
571
-
* The block manager loads the initial state from the local store and uses genesis if not found in the local store, when the node (re)starts.
572
-
* The default mode for sequencer nodes is normal (not lazy).
573
-
* The sequencer can produce empty blocks.
574
-
* In lazy aggregation mode, the block manager maintains consistency with the DA layer by producing empty blocks at regular intervals, ensuring a 1:1 mapping between DA layer blocks and execution layer blocks.
575
-
* The lazy aggregation mechanism uses a dual timer approach:
576
-
* A `blockTimer` that triggers block production when transactions are available
577
-
* A `lazyTimer` that ensures blocks are produced even during periods of inactivity
578
-
* Empty batches are handled differently in lazy mode - instead of discarding them, they are returned with the `ErrNoBatch` error, allowing the caller to create empty blocks with proper timestamps.
579
-
* Transaction notifications from the `Reaper` to the `Manager` are handled via a non-blocking notification channel (`txNotifyCh`) to prevent backpressure.
580
-
* The block manager enforces `MaxPendingHeadersAndData` limit to prevent unbounded growth of pending queues during DA submission issues.
581
-
* Headers and data are submitted separately to the DA layer using different namespaces, supporting the header/data separation architecture.
582
-
* The block manager uses persistent caches for headers and data to track seen items and DA inclusion status.
583
-
* Namespace migration is handled transparently, with automatic detection and state persistence to optimize future operations.
584
-
* The system supports backward compatibility with legacy single-namespace deployments while transitioning to separate namespaces.
585
-
* Gas price management includes automatic adjustment with `GasMultiplier` on DA submission retries.
586
-
* The block manager uses persistent storage (disk) when the `root_dir` and `db_path` configuration parameters are specified in `config.yaml` file under the app directory. If these configuration parameters are not specified, the in-memory storage is used, which will not be persistent if the node stops.
587
-
* The block manager does not re-apply blocks when they transition from soft confirmed to DA included status. The block is only marked DA included in the caches.
588
-
* Header and data stores use separate prefixes for isolation in the underlying database.
589
-
* The genesis `ChainID` is used to create separate `PubSubTopID`s for headers and data in go-header.
590
-
* Block sync over the P2P network works only when a full node is connected to the P2P network by specifying the initial seeds to connect to via `P2PConfig.Seeds` configuration parameter when starting the full node.
591
-
* Node's context is passed down to all components to support graceful shutdown and cancellation.
592
-
* The block manager supports custom signature payload providers for headers, enabling flexible signing schemes.
593
-
* The block manager supports the separation of header and data structures in Evolve. This allows for expanding the sequencing scheme beyond single sequencing and enables the use of a decentralized sequencer mode. For detailed information on this architecture, see the [Header and Data Separation ADR](../../adr/adr-014-header-and-data-separation.md).
594
-
* The block manager processes blocks with a minimal header format, which is designed to eliminate dependency on CometBFT's header format and can be used to produce an execution layer tailored header if needed. For details on this header structure, see the [Evolve Minimal Header](../../adr/adr-015-rollkit-minimal-header.md) specification.
571
+
- The block manager loads the initial state from the local store and uses genesis if not found in the local store, when the node (re)starts.
572
+
- The default mode for sequencer nodes is normal (not lazy).
573
+
- The sequencer can produce empty blocks.
574
+
- In lazy aggregation mode, the block manager maintains consistency with the DA layer by producing empty blocks at regular intervals, ensuring a 1:1 mapping between DA layer blocks and execution layer blocks.
575
+
- The lazy aggregation mechanism uses a dual timer approach:
576
+
- A `blockTimer` that triggers block production when transactions are available
577
+
- A `lazyTimer` that ensures blocks are produced even during periods of inactivity
578
+
- Empty batches are handled differently in lazy mode - instead of discarding them, they are returned with the `ErrNoBatch` error, allowing the caller to create empty blocks with proper timestamps.
579
+
- Transaction notifications from the `Reaper` to the `Manager` are handled via a non-blocking notification channel (`txNotifyCh`) to prevent backpressure.
580
+
- The block manager enforces `MaxPendingHeadersAndData` limit to prevent unbounded growth of pending queues during DA submission issues.
581
+
- Headers and data are submitted separately to the DA layer using different namespaces, supporting the header/data separation architecture.
582
+
- The block manager uses persistent caches for headers and data to track seen items and DA inclusion status.
583
+
- Namespace migration is handled transparently, with automatic detection and state persistence to optimize future operations.
584
+
- The system supports backward compatibility with legacy single-namespace deployments while transitioning to separate namespaces.
585
+
- Gas price management includes automatic adjustment with `GasMultiplier` on DA submission retries.
586
+
- The block manager uses persistent storage (disk) when the `root_dir` and `db_path` configuration parameters are specified in `config.yaml` file under the app directory. If these configuration parameters are not specified, the in-memory storage is used, which will not be persistent if the node stops.
587
+
- The block manager does not re-apply blocks when they transition from soft confirmed to DA included status. The block is only marked DA included in the caches.
588
+
- Header and data stores use separate prefixes for isolation in the underlying database.
589
+
- The genesis `ChainID` is used to create separate `PubSubTopID`s for headers and data in go-header.
590
+
- Block sync over the P2P network works only when a full node is connected to the P2P network by specifying the initial seeds to connect to via `P2PConfig.Seeds` configuration parameter when starting the full node.
591
+
- Node's context is passed down to all components to support graceful shutdown and cancellation.
592
+
- The block manager supports custom signature payload providers for headers, enabling flexible signing schemes.
593
+
- The block manager supports the separation of header and data structures in Evolve. This allows for expanding the sequencing scheme beyond single sequencing and enables the use of a decentralized sequencer mode. For detailed information on this architecture, see the [Header and Data Separation ADR](../../adr/adr-014-header-and-data-separation.md).
594
+
- The block manager processes blocks with a minimal header format, which is designed to eliminate dependency on CometBFT's header format and can be used to produce an execution layer tailored header if needed. For details on this header structure, see the [Evolve Minimal Header](../../adr/adr-015-rollkit-minimal-header.md) specification.
0 commit comments