Open zone117x opened 7 months ago
Running against an epoch3 node is pretty complicated. Duplicate efforts are on-going between the stacks-regtest and Clarinet projects. Ideally the API could use an epoch3 image from Clarinet. That is still in discussion. cc @hugocaillard
Increased priority for this now that we need epoch3.0 for integration tests for new Nakamoto signer event data implemented in https://github.com/stacks-network/stacks-core/pull/4269
Aiming for mid-Feb for epoch to be ready.
Update: the latest signer
branch in the regtest-env repo (https://github.com/hirosystems/stacks-regtest-env/pull/33) is able to boot epoch3 when using the full docker-compose workflow.
The orchestration required is significantly more complicated than epoch2.x..
In order to implement integration tests in this repo so they work similar to epoch2.x, we need to:
Of the above action items, only the first one is actionable right now. But it's unclear how useful that will be by itself, and also unclear if right now is a good time to divert attention away from feature development and manual testing.
In the meantime, we are working around this with a different development and testing workflow, which @janniks and @rafaelcr are helping with:
PR https://github.com/hirosystems/stacks-blockchain-api/pull/1762 boots the stacks-node into epoch2.5 (where pox-4 activates) and refactors all pox integration tests to pox-4.
Epoch3.0 is when NakamotoBlocks come online. The script that boots up the stacks-node needs some new logic to trigger this transition, those changes will be done in the regtest-env repo https://github.com/hirosystems/stacks-regtest-env
Then the integration tests here need to start specifying and confirm epoch3.0 is activated, and test the NakamotoBlock+TenureChange ingestion.