-
Notifications
You must be signed in to change notification settings - Fork 2k
The chia.consensus
module no longer depends upon chia.full_node
#19671
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.
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
base: main
Are you sure you want to change the base?
Conversation
…eck_time_locks`.
Pull Request Test Coverage Report for Build 15426877319Details
💛 - Coveralls |
is there a vision of what |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's reasonable to move and rename mempool_check_time_locks()
.
I don't see the rationale for moving BlockHeightMap
out of Blockchain
, it seems like you just make it more complicated to construct the Blockchain
object, and I don't see an upside. We don't need the BlockHeightMap
outside Blockchain
, do we?
Also, I'm under the impression that we prefer Protocol
s over inheritance (I personally do at least). We have some precedence of using protocols as well.
However, at a higher level, why do you need an interface/protocol for these types? The main reason I can think if is if you want to be able to stub them out in tests, but I don't see that. It seems like added complexity with no upside, but perhaps I'm missing it.
chia/full_node/block_height_map.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems a lot simpler to just move this class into chia.consensus
and use concrete types. We only have one class implementing the interface, and it doesn't look like we have any intention of adding more implementations, so we should just use the concrete type and keep things simple, I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reasoning is I want to keep storage details away from consensus. I actually think chia.consensus
does a pretty good job of isolating the consensus stuff (not including mempool, which IMO isn't actually consensus. I prefer to narrowly define consensus as "blockchain validation"). This opens the door to (for example) creating a completely RAM-based consensus mechanism that just stores all the data in python dictionaries.
We could move the three storage classes into consensus. If you look at the implementations of BlockHeightMap
, CoinStore
and BlockStore
, they are, IMO, ugly and messy and bogged-down in SQLite3 administrivia that distracts from the understanding of how consensus works. I'd actually quite like to move DBWrapper
and friends etc. into a new module called chia.sqlite3
or chia.db
, to isolate the storage implementations into a black box.
Note that I am working on a new implementation of CoinStore
right now (the rocks_db thing) and having an ABC will make it easier to split CoinStore
into ConsensusCoinStore
(or whatever) and ExplorerStore
(indices of parent coin info and puzzle hashes) which I'm sure you've heard me harp on about several times now.
I think it's a bit funny that python supports ABC
and Protocol
. It makes it hard to know which one to use. ChatGPT recommended ABC for this case. I guess Protocol
is useful for built-in types like saying "I need a thing that looks like a bytes
object in the following ways...". For CoinStore
and friends, I kind of prefer ABC
because it allows default implementations (for example, get_coin_record
could easily have a default imp that uses get_coin_records
with very little loss in efficiency), and it makes it easier to determine exactly what you have to write and what is still missing without resorting to mypy
(which for me always produces a lot of noise that signal gets lost in because I'm probably doing something wrong).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An argument for avoiding SQLite3 code in consensus
: it's not side-effect free. It's much easier to reason about pure functional code that has no side effects. The ABC
is side-effect free (well, except I guess it mutates the state of the object, which I guess is generally seen as okay). Any disk-based stuff is loaded with side effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, this change will make it easier to provide a transition path where we temporarily support the SQLite3 DB and the RocksDB for CoinStore
(and if we move more stuff to rocksdb in future, it helps there too).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ABC is ancient. Protocol is more recent. i encourage protocols since they don't use inheritance and whatever related to that.
chia/consensus/coin_store_abc.py
Outdated
This is a substitute for importing from chia.full_node.coin_store directly. | ||
""" | ||
|
||
db_wrapper: DBWrapper2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line should be removed for sure.
chia/consensus/coin_store_abc.py
Outdated
This is a substitute for importing from chia.full_node.coin_store directly. | ||
""" | ||
|
||
db_wrapper: DBWrapper2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
db_wrapper: DBWrapper2 |
37ae7f3
to
57effcc
Compare
46be01a
to
f842243
Compare
"""Provide a transaction context.""" | ||
|
||
async with self.db_wrapper.writer() as transaction: | ||
yield transaction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check this part carefully. I think it's right, but I got a weird transient error on one test set: py3.10 Mac OS Intel simulator, something about trying to operate on a closed DB. I don't recall having seen that before so it's possible it's related to this.
for row in await cursor.fetchall(): | ||
block_rec = BlockRecord.from_bytes(row[1]) | ||
all_blocks[block_rec.header_hash] = block_rec | ||
batch_size = self.db_wrapper.host_parameter_limit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Batching moved down into here.
raise ValueError(f"Header hash {hh} not in the blockchain") | ||
ret.append(all_blocks[hh]) | ||
return ret | ||
# Step 1: Check the cache for each hash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
caching moved down into here
This is getting a bit too complicated. I think that I will withdraw it and submit multiple PRs that are smaller and simpler. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Prior to this change, there were several dependencies of
chia.full_node
in thechia.consensus
module.