Closed zone117x closed 2 months ago
Solution Idea: We can change "mocknet" to be something that runs a full stacks-node
, but simulates the Bitcoin chain itself.
Solution Idea: We can change "mocknet" to be something that runs a full
stacks-node
, but simulates the Bitcoin chain itself.
My 2 cents as mostly a codebase-lurker rather than a frequent contributor -- when looking over the codebase for the various modes (mainnet/testnet, neon/krypton, and helium/mocknet), there appear to be large swaths of responsibility implemented 3 times for each mode. For example, the mining and thread orchestration code seems to have roughly 3 different implementations, each of which appear to roughly follow the order of implementation from when Stacks 2.0 was being developed. On the surface it seems like there should be mostly code for mainnet/testnet which then gets stubbed/mocked out in a cleaner way for the other modes. I realize that sounds much easier said than done.
I would absolutely love to drop the Helium node from stacks-node
, and just keep the Neon node code. But I think this would break a lot of things.
I agree that from the perspective of a maintainer of this repo, it would be a lot easier to drop mocknet/helium support. However, it is very useful to be able to spin up a stacks-node with basic functionality and not have to also deal with the the bitcoin-regtest and regtest-miner dependencies.
Related to what @zone117x said about code copying, I looked into this in some detail in the context of the subnets project: https://github.com/hirosystems/stacks-subnets/discussions/48
To summarize: the use of "associative types", rather than truly abstract types (in which the type of one component does not depend on another), means that we end up
I haven't had time to re-analyze the L1 for this same situation, but I think they are pretty similar.
Is this fixed by #3372?
Let's try and deprecate mocknet in favor of Clarinet.
Helium, along with Stacks 2.x, will soon be replaced with Nakamoto. Going to close this.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
There's a handful of issues related to trying to use
mocknet
mode to boot and use a Stacks instance running in epoch 2.1.I'll update this issue with more details and logs as I have time to test and write them out. In the mean time, opening this issue for visibility. The API has transitioned its testing to using Stacks-krypton and a Bitcoin-regtest node, but it was non-trivial to setup, and the extra dependency on bitcoind and a regtest-mining script is painful. Perhaps this pain is necessary for components that are challenging to mock (e.g. various pox features), but it should still generally be possible for basic usage & testing. For example, it should be possible to boot a mocknet mode and deploy a Clarity 2.0 contract.
Known bugs / limitations:
config.miner.block_reward_recipient
option results in errors. This appears to be because the stacks-node boots into epoch 2.0 first, and/or the mocknet miner code does not respect the config option when specified as an alt-account / contract principal.