Parallelize Speculative Read-Only Transaction Execution

stephenpdeos commented 2 years ago

Problem

Opportunity: What are the needs of our target user groups?

Currently transactions are executed in a single thread. To take advantage of multi-core architecture, executing speculative transactions in multiple threads would improve performance.

Target audience: Who is the target audience and why?

API nodeos operators and users.

Strategic alignment: How does this problem align with our core strategic pillars?

Performance

Context

Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?

Product differentiation: what would make our solution different?

Audience definition

Solution

Solution name: How should we refer to this product opportunity?

Parallelize Speculative Transaction Execution

Purpose: Define the product’s purpose briefly

Success definition: What are the top metrics for the product (up to 5) to define success?

Assumptions

Only irreversible and head are supported in DB read-mode configuration.

Risks: What risks should be considered? https://www.svpg.com/four-big-risks/

Business Objectives/Functionality

Features/Epics

A possible solution is being investigated.

nodeos runs in one of two modes between which it cycles rapidly (to maintain good latency on fulfilling the requests), read-only mode, and exclusive write mode:

In exclusive write mode, nodeos quickly syncs to the latest available blocks that were being queued up in the fork database. Transactions received during this mode are queued in a transaction queue.
In read-only mode, block syncing would be paused to ensure nothing is written to chainbase. Transactions in the transaction queue are dispatched to a thread pool to access chainbase in parallel.

Several design decisions need to be made in this approach.

A transaction can potentially modify the state it is accessing. It needs to see its own side-effects, but still be isolated from the side-effects of any other concurrently executing transactions. For each transaction, we will create a separate simulated state from the common LIB or head such that the transaction works on this simulated state only. After the transaction execution is finished, the simulated state is discarded. Research is needed on how to support this in Chainbase.
As it gets close to the point where transition from read-only to exclusive write mode is expected, additional requests should not be dispatched to the thread pool. Furthermore, some existing threads will run for too long. At that point they will be forcefully killed and re-queued so that they can be processed again in the next read cycle. Once all read threads have stopped, the exclusive write mode is transitioned.
Duration or ratio of read-only mode and exclusive write mode can be configured. Ideally, those configurations serve as max values. When no more read requests are queued, control can be transitioned to exclusive write mode, and vice versa.

User stories

Additional tasks

Timeline

Cost

Open questions

linh2931 commented 2 years ago

jbuice commented 1 year ago

Huge +1 on this.

bhazzard commented 1 year ago

All tasks complete, moving this to "Transition to Operations"

eosnetworkfoundation / product