[Stacks 2.1] Epoch 2.1 is broken in mocknet

[zone117x]

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:

• There is no toml config (that I'm aware of) which can bootstrap the stacks node into epoch 2.1 (either immediately or after n-configurable blocks) without running into various problems:
• The new coinbase-pay-to-alt config cannot be tested -- the 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.
• Related to the above issues -- because it doesn't appear possible to bootstrap into Epoch 2.1, all the Clarity 2.0 features are unavailable to test / use.
• Because Clarity 2.0 features cannot be tested, the new "send stx with memo" function (and more importantly the new event-emitter payload) cannot be tested.

[gregorycoppola]

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

[zone117x]

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]

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]

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]

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

• copy-and-pasting of functionality
• no ability to mix and match between "prod" components and "mock" components.. the "mock" system is very unrelated to the "prod" system, as we are finding here on the L1

I haven't had time to re-analyze the L1 for this same situation, but I think they are pretty similar.

[jcnelson]

Is this fixed by #3372?

[jcnelson]

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