Skip to content

feat: BlockchainTree#1212

Merged
gakonst merged 36 commits intomainfrom
rakita/blockchain_tree
Mar 14, 2023
Merged

feat: BlockchainTree#1212
gakonst merged 36 commits intomainfrom
rakita/blockchain_tree

Conversation

@rakita
Copy link
Copy Markdown
Collaborator

@rakita rakita commented Feb 7, 2023

closes: #1104

Copy link
Copy Markdown
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rakita good start, I think before merging this, would like to understand exactly where the point of integration with the rest of the code will be? is it going to be engine api? how are we going to expose a single block to get executed?

Comment on lines +84 to +85
_provider: &PROVIDER,
_consensus: &CONSENSUS,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provider & consensus should prob be part of the struct?

@rakita
Copy link
Copy Markdown
Collaborator Author

rakita commented Feb 8, 2023

@rakita good start, I think before merging this, would like to understand exactly where the point of integration with the rest of the code will be? is it going to be engine api? how are we going to expose a single block to get executed?

Let's move this discussion to the main task, it will get dissolved if we start discussion it on two places.

@onbjerg onbjerg added C-enhancement New feature or request A-consensus Related to the consensus engine labels Feb 8, 2023
Copy link
Copy Markdown
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took another pass and looking nice. I think you already know this but let's add a few tests around insert/make-canonical for a few of the scenarios you mention, to make sure we handle things correctly.

I think we'll probably end up doing insert_chain on each new_payload and then on fork_choice_updated we'll be "flushing", which realistically means having the headers+bodies+execution stage run for that part.

@rakita
Copy link
Copy Markdown
Collaborator Author

rakita commented Feb 10, 2023

Took another pass and looking nice. I think you already know this but let's add a few tests around insert/make-canonical for a few of the scenarios you mention, to make sure we handle things correctly.

I think we'll probably end up doing insert_chain on each new_payload and then on fork_choice_updated we'll be "flushing", which realistically means having the headers+bodies+execution stage run for that part.

Yeah, testing is completely missing and some TODO are pending. I wanted to make a draft so that @rkrasiuk can see what is found inside and how it can be used.

@rkrasiuk
Copy link
Copy Markdown
Contributor

rkrasiuk commented Feb 10, 2023

@rakita i will take some time today to review this, thanks!

Copy link
Copy Markdown
Contributor

@rkrasiuk rkrasiuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in general, the interface looks good. didn't do an in-depth review of the implementation. leaving couple of questions

@rakita rakita force-pushed the rakita/blockchain_tree branch 2 times, most recently from 50924bc to 43556de Compare February 21, 2023 17:45
@rakita rakita changed the base branch from main to rakita/refactor_stages_to_providers February 23, 2023 12:40
Copy link
Copy Markdown
Contributor

@rkrasiuk rkrasiuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rakita this implementation is safe if it will be invoked exclusively by the engine API, because the latter is implemented as a Future and consumes the requests successively. otherwise, i believe, we would need some lock mechanism to prevent concurrent operations on the blockchain tree

@rakita rakita force-pushed the rakita/blockchain_tree branch from 2e67384 to ef3be7e Compare February 24, 2023 10:23
Base automatically changed from rakita/refactor_stages_to_providers to main March 1, 2023 20:42
@rakita rakita force-pushed the rakita/blockchain_tree branch 2 times, most recently from 87f66af to e794bfb Compare March 2, 2023 00:50
@rakita rakita force-pushed the rakita/blockchain_tree branch from e794bfb to 65e56b4 Compare March 2, 2023 00:58
@rakita rakita force-pushed the rakita/blockchain_tree branch from 287e067 to 79c3e03 Compare March 4, 2023 17:13
@rakita rakita requested a review from rkrasiuk March 10, 2023 09:20
@rakita rakita force-pushed the rakita/blockchain_tree branch from 1806404 to 3eb05ff Compare March 10, 2023 09:59
Copy link
Copy Markdown
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand the internals.
I didn't review very closely but I could kinda follow along.
test coverage looks great.

perhaps I'm being a bit pedantic, but I want to emphasize that we likely don't want pub field access for most of the things.

use std::ops::DerefMut;

#[test]
fn insert_get_take() {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are way too few tests here considering everything in the stages crate has been moved here at this point.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is moved from stage still gets tested from it. With test data i tried to cover cases that can happen in both getting and taking data from database, and additionally, BlockchainTree is testing this functionality in its own way.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As part of the refactor of the Transaction struct during our tech debt cleanup, we should introduce more tests

@rakita rakita requested a review from Rjected as a code owner March 10, 2023 20:41
@gakonst
Copy link
Copy Markdown
Member

gakonst commented Mar 14, 2023

@onbjerg @rkrasiuk please take another pass

@mattsse if you got bandwidth would love your eyes on this as you're wrapping RPC

Copy link
Copy Markdown
Contributor

@rkrasiuk rkrasiuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leaving some minor comments and cautiously approving. well done overall! just a lot of moving parts here and we've done multiple passes at this over the last couple of days

@rkrasiuk
Copy link
Copy Markdown
Contributor

@rakita pending conflict resolution

@rkrasiuk
Copy link
Copy Markdown
Contributor

@rakita some tests seem to be failing

Copy link
Copy Markdown
Contributor

@rkrasiuk rkrasiuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lessssssgoooooooooooooooooooooooooooooooooooo

Copy link
Copy Markdown
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet. nice work on the tree tester, was really missing. let's ship it and iterate as we get closer to SyncController + Engine API tests on Hive

@gakonst gakonst merged commit 237fd5c into main Mar 14, 2023
@gakonst gakonst deleted the rakita/blockchain_tree branch March 14, 2023 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-consensus Related to the consensus engine C-enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BlockchainTree sidechain/pending block inmemory structure

6 participants