stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 671 forks source link

[Stacks 2.1] Epoch 2.1 is broken in mocknet #3366

Closed zone117x closed 2 months ago

zone117x commented 2 years ago

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:

gregorycoppola commented 2 years ago

Solution Idea: We can change "mocknet" to be something that runs a full stacks-node, but simulates the Bitcoin chain itself.

zone117x commented 2 years ago

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.

jcnelson commented 2 years ago

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.

zone117x commented 2 years ago

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.

gregorycoppola commented 2 years ago

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.

jcnelson commented 2 years ago

Is this fixed by #3372?

jcnelson commented 1 year ago

Let's try and deprecate mocknet in favor of Clarinet.

jcnelson commented 2 months ago

Helium, along with Stacks 2.x, will soon be replaced with Nakamoto. Going to close this.

blockstack-devops commented 3 weeks ago

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.