Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimistic Block #10584

Open
Tracked by #46
Longarithm opened this issue Feb 7, 2024 · 1 comment
Open
Tracked by #46

Optimistic Block #10584

Longarithm opened this issue Feb 7, 2024 · 1 comment
Assignees
@VanBarbascu @Longarithm
Labels
A-stateless-validation Area: stateless validation

Comments

@Longarithm
Copy link
Member

Longarithm commented Feb 7, 2024 •
edited
Loading

Goal

Remove 2x latency of chunk execution by introducing OptimisticBlock.

Plan

  1. Create OptimisticBlock
  2. Change Chain::get_update_shard_job to accept not only Block, but OptimisticBlock and Chunks
  3. Implement OptimisticBlockPool
  4. Validate OptimisticBlock
  5. Distribute OptimisticBlock
  6. End-to-end and forknet tests. Steps 2-4 also include testing
@Longarithm Longarithm added the A-stateless-validation Area: stateless validation label Feb 7, 2024
@Longarithm Longarithm mentioned this issue Feb 7, 2024
Open
52 tasks
@github-actions github-actions bot mentioned this issue Mar 1, 2024
Closed
@Longarithm Longarithm mentioned this issue Jul 2, 2024
Merged
@Longarithm Longarithm changed the title [stateless_validation] Solve 2x Latency Problem Optimistic Block Dec 3, 2024
@Longarithm
Copy link
Member Author

Zulip thread: https://near.zulipchat.com/#narrow/channel/295558-core/topic/Optimistic.20Block.20Design/near/467293949

Original description from 8 Feb 2024

Stateless validation implementation introduces 2x latency of chunk execution. This is because validation of chunk (N+1) is blocked on execution of chunk N, and this validation repeats execution of chunk N itself.

It can be avoided by optimistic execution:

  • Once CP produces chunk N, it can go ahead and distribute it to CP for chunk (N+1). Because they have state, they can execute it before inclusion into block and record resulting state proof.
  • Once BP includes chunk N into block, CP for (N+1) will already have state proof for N ready, can immediately produce chunk (N+1) and send state witness to CVs.

It is a well-defined win after stateless validation release.
For now, I believe we don't need to change config delays because stateless validation improves performance on its own.

Original context: https://docs.google.com/document/d/1k0NRMcLsDZp6C9pCRjNu5l7irDyRHsZ3VtKAKno_tFY/edit#heading=h.7ae0b4dh7648

Another pic of current workflow I came up with trying to understand this:

image

@Longarithm Longarithm mentioned this issue Jan 16, 2025
Merged
VanBarbascu added a commit to VanBarbascu/nearcore that referenced this issue Jan 17, 2025
@VanBarbascu
feat(optimistic_block): Introduce the optimistic block struct
e3eea28 
This PR introduces the shape of the optimistic block described in near#10584.
Along with it I have added the functions to create and sign it. In the next PR,
I will link this in the path of the block production.
@VanBarbascu VanBarbascu mentioned this issue Jan 17, 2025
Merged
VanBarbascu added a commit to VanBarbascu/nearcore that referenced this issue Jan 17, 2025
@Longarithm @VanBarbascu
refactor: replace dependency on Block with BlockContext and `Chun…
43fc799 
…ks` on apply chunk (near#12746)

### Context

We want to improve chunk processing efficiency by applying chunks
optimistically (near#10584), when all partial chunks for the next height and
block metadata (from an `OptimisticBlock`) are already available. This
allows the results of chunk application to be reused when the actual
block is received, enabling the next chunk to be produced immediately.

Currently, this work is a step towards supporting `OptimisticBlock`.
While `OptimisticBlock` is not introduced yet, this refactor prepares
the codebase for its implementation by reducing data dependency on the
current block.

### Change

I replaced the dependency on `Block` with `ApplyChunkBlockContext` and
`chunk_headers: &Chunks`. We'll just need to add conversion from
`OptimisticBlock` to `ApplyChunkBlockContext` later. Chunk headers are
just taken from block, and for optimistic block, they must be supplied
by ShardsManager.

Some APIs are refactored to reflect that change. 

### Next steps

* Convert `OptimisticBlock` to `ApplyChunkBlockContext`.
* Then, we call `get_update_shard_job` for `OptimisticBlock` and reuse
result if it is called for the actual `Block`.

---------

Co-authored-by: Razvan Barbascu <[email protected]>
VanBarbascu added a commit to VanBarbascu/nearcore that referenced this issue Jan 17, 2025
@VanBarbascu
feat(optimistic_block): Introduce the optimistic block struct
90609c0 
This PR introduces the shape of the optimistic block described in near#10584.
Along with it I have added the functions to create and sign it. In the next PR,
I will link this in the path of the block production.
VanBarbascu added a commit to VanBarbascu/nearcore that referenced this issue Jan 20, 2025
@VanBarbascu
feat(optimistic_block): Introduce the optimistic block struct
4d0e4fd 
This PR introduces the shape of the optimistic block described in near#10584.
Along with it I have added the functions to create and sign it. In the next PR,
I will link this in the path of the block production.
VanBarbascu added a commit to VanBarbascu/nearcore that referenced this issue Jan 20, 2025
@VanBarbascu
feat(optimistic_block): Introduce the optimistic block struct
bf3400f 
This PR introduces the shape of the optimistic block described in near#10584.
Along with it I have added the functions to create and sign it. In the next PR,
I will link this in the path of the block production.
@VanBarbascu VanBarbascu mentioned this issue Jan 20, 2025
Merged
github-merge-queue bot pushed a commit that referenced this issue Jan 20, 2025
@VanBarbascu
feat(optimistic_block): Introduce the optimistic block struct (#12730)
9b626a7 
This PR introduces the shape of the optimistic block described in
#10584.
Along with it I have added the functions to create and sign it. In the
next PR,
I will link this in the path of the block production.
@Longarithm Longarithm mentioned this issue Jan 23, 2025
Merged
github-merge-queue bot pushed a commit that referenced this issue Jan 23, 2025
@VanBarbascu @Longarithm
feat(optimistic_block): produce (#12761)
81538fc 
We continue the implementation of Optimistic block #10584, by adding the
logic to produce the block as soon as the previous block is done.

If available, the optimistic block will be used in the production of the
block to use the same timestamp.

---------

Co-authored-by: Aleksandr Logunov <[email protected]>
github-merge-queue bot pushed a commit that referenced this issue Jan 24, 2025
@Longarithm
feat(optimistic_block): shuffle incoming receipts based on prev hash (#…
532d157 
…12777)

#10584

There is another unexpected dependency on block hash during chunk
application - it is used in `shuffle_receipt_proofs` to shuffle new
receipts targeting our shard. As block hash is unknown in optimistic
block, I replace it with prev block hash with a protocol upgrade.

Additionally, use `Chunks` instead of `Block` in
`collect_incoming_receipts_from_chunks` - it will be useful for
optimistic block execution flow later.

## Security

Some block producer can brute force hashes to get salt which gives more
desirable order. But block hash is prone to that as well, prev hash has
equivalent safety.

## Upgrade

I use `BlockHeightForReceiptId` feature because it has similar goal and
it is going to be released soon. Adding separate feature makes code
harder to read I think.

## Testing

IMO it makes sense only to check consistency of the shuffling, I don't
see much value in checking that specific salt is used. So I claim that
running existing tests is enough to test that change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@VanBarbascu VanBarbascu

@Longarithm Longarithm

Labels
A-stateless-validation Area: stateless validation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@VanBarbascu @Longarithm