Testing Plan for Stacks 2.1 (due December 14 EOD)

[jcnelson]

Finish All Testing By December 14 EOD

Tracking sheet: https://docs.google.com/spreadsheets/d/1YoQPwgfJohtLYjqb91vUd6QJV99XRZUV5G1NeV1w1MU/edit#gid=0

Testing Timelines & Estimates: https://www.notion.so/hiropbc/2-1-Testing-Timelines-Estimates-1c9b3ad74d7040f281a17e30a6a51191

This document will be edited as more test items are accepted.

Blockchain track

• Verify that the .pox to .pox-2 transition works on testnet - @lgalabru - In Progress

  • .pox-2 instantiates at the expected block height (unit test added for this in Btc wire format for delegate stx + use active PoX contract for btc ops #3339) Regtest integration tests
  • All STX stacked in .pox are available for spending / re-stacking once v1_block_height passes Regtest integration tests
  • Users can re-stack their STX into .pox-2 Regtest integration tests
  • Once the next reward cycle begins, tokens stacked in .pox-2 are used to derive the reward cycle. .pox is ignored Regtest integration tests
  • Verify that btc wire format tx for "delegate-stx" does not work before Epoch 2.1 initializes
    Tests end to end: https://github.com/hirosystems/stacks-2-1-testing/tree/main/tests/integration/pox/stacking

• Verify that new PoX features work on the public 2.1 testnet - @lgalabru | @donpdonp

  • stacks-increase works as expected
  • stacks-unlock works as expected
  • stacking to a segwit and taproot address works in pox-2
  • stacking to a segwit and taproot address receives payout
  • verify that btc wire format tx for "delegate-stx" works
    ⚠️ Blocked by [Stacks 2.1] Lack of synthetic event attached to Delegate Stacks STX Bitcoin op  #3465

• Verify that mining enhancements work on the public 2.1 testnet - @jcnelson

  • Miners no longer penalized so harshly for missing a block-commit
  • on-BTC STX-transfer and stacking land on all forks that arise within 6 Bitcoin blocks after they are mined
  • Miners can mine with a taproot address - @wileyj

• Verify that revealing a hidden anchor block does not reorg the chain - @jcnelson

  • Verify that a node correctly computes affirmation maps
  • Verify that the PoX anchor block is the heaviest-confirmed block-commit by BTC weight, even before 2.1
  • Verify that an anchor block missing for more than one reward cycle is marked absent
  • Verify that the arrival of a missing anchor block during its reward cycle does not reorg the chain
    • Verify that a running node will ignore the anchor block as having been revealed too late
    • Verify that a bootstrapping node will ignore the anchor block if informed by its bootstrap node
  • Verify that the arrival of an anchor block after its reward cycle does not reorg the chain

• Verify that all new Clarity keywords and functions only become available after the transition - @obycode - In Progress

  • get pox addrs

• Verify that subnets instantiate on the public 2.1 testnet - @pavitthrap | @gregorycoppola

• Verify that transactions now pay transaction fees before they are executed, such that any transaction with a runtime-caught CheckError is mined and the paying account is billed the transaction fee. - @igorsyl / @netrome

  • e.g. call a contract which tries to invoke a trait implementation within an at-block closure, but which is declared after the at-block block.
  • test script: https://gist.github.com/igorsyl/7da553fc7cf19b9578abdc97d76eb825

• Trait implementations work correctly - @obycode

  • Old trait system behavior is preserved
  • New trait system works as intended
  • Cross-epoch contract-calls, with traits defined in different epochs, works as expected (it does in unit tests)
  • All consensus-critical fields in the 2.1 and 2.05 databases are the same, when next is sync'ed up to the chain tip prior to launch

• Build PoC apps to validate the design of new 2.1 features - @mefrem

  • Simple oracle built on from-consensus-buff.
  • Simple bridge with principal-of, principal-destruct, principal-construct - In Progress
  • Simple mining pool with pay-to-contract, taproot mining, and BTC tx parsing / validation built in slice and get-burn-block-info?
    • Can mine a pay-to-contract block
    • Can mine with taproot
    • Can parse Bitcoin transactions with slice
    • Can query Bitcoin block header hashes with get-burn-block-info?
  • Simple proof-of-PoX-payout contract built with get-burn-block-info? and BTC tx parsing

• Stacks API works correctly with Epoch 2.1 @donpdonp @zone117x - In Progress

  • PoX 2 events get emitted
  • All events we expect from 2.05 get emitted
  • New PoX events get emitted
  • Epoch transition events get emitted

• Fuzz testing @obycode - In Progress

  • No inconsistencies between 2.05 and 2.1's Clarity implementation
  • Fuzz testing ongoing for 2.1 Clarity

Client/Wallet track

• Clients that stack will automatically direct STX to .pox-2

  • Clients can determine that STX have unlocked after the transition
  • Clients can determine when the .pox-2 contract has been instantiated

• Clients will report the correct locked / unlocked balance after the transition

  • At the transition, all STX locked in .pox show up as unlocked
  • STX stacked after the transition show up as locked

• Clients can permit users to stack to a segwit address in .pox-2

Exchange track - @wileyj | @cuevasm

• Reach out to all exchanges we know of to inform them that they will need to update their code to stack user STX to .pox-2
• Offer them a testnet (or a private testnet) to try out new stacking
• Inform exchanges that they should use an officially-supported client library for .pox-2 if the are able

---

Please suggest more tests below

For reference, here are the new features being added to 2.1:

• It fixes principal-of, which lets you convert a public key in a Bitcoin scriptSig to a Stacks address (it's currently broken on mainnet)
• It adds Clarity built-ins to construct and deconstruct principal types from hash160s and version bytes (which is necessary to convert Bitcoin addresses to Stacks principals and back)
• It adds Clarity built-ins to convert between buffers and integers, and it adds a slice built-in -- both of which are necessary for efficiently parsing Bitcoin transactions (my bitcoin.clar contract certainly works, but it's very costly to use because it must implement all of these functions in Clarity)
• It ensures that any past Bitcoin block hash can be queried, back to system genesis, even if there is no Stacks block chosen in it (right now, you can only get Bitcoin block hashes if there was a Stacks block mined in it. You can't get a flash block's Bitcoin hash). This is necessary for validating SPV proofs.
• It exposes PoX address payouts for past blocks, which enables writing Clarity contracts that react to the on-Bitcoin behavior of PoX (such as using PoX to implement a peg-out)
• It adds support for mining and Stacking with taproot addresses, which enables more-complex interactions between Clarity and Bitcoin than you can have today with just segwit and legacy transactions. This will be important if miners and/or stackers are part of a 2-way peg system.

[diwakergupta]

Thanks for putting this together Jude, was on my list for this week -- much appreciated! 🙏🏽

[saralab]

Added Owners to the Testing Plan based on discussion today during Architecture meeting and the offsite

[whoabuddy]

Could we add a section for Stacking Pool Operators?

After the Gov CAB review of SIP-015 we asked some of the current pool operators to comment on the transition to continuous stacking, and all three were interested in testing on testnet as soon as it's available. Comments can be seen here.

[whoabuddy]

Tagging @yknl @friedger @planbetterHQ here so they can provide more information. If anyone knows handles for other Stacking pool operators feel free to add them as well!

[planbetterHQ]

From Planbetter's point of view we are more confortable simply testing the new Pox-2 contract directly in testnet with sufficient time to smooth out possible bugs, ask questions if problems arise and get ready for launch.

Adding to that, we have a couple of questions:

• Will pooled stackers have to re-stack again (even those that still have multiple cycles left)? The reason I am asking this is because a lot of our users delegate for 12 cycles, and some will still have cycles left when POX2 comes into action. In that case what will happen and what we will have to do as pool operators? I read the SIP and I understand, they will have to call delegate-stx again, but if someone could confirm it, I'd be thankful.
• Is there a way to know which pool members have increased their stacking amounts? So we can acknowledge that and issue delegate-stack-increase?
• Is there a way to know which pool members have asked to extend their delegation? Maybe I am confused here since I don't see such method for pooled stackers. Does this mean that this dependes on the until-burn-ht function argument on the delegate-stx method, which is the same as POX1? If the delegation status of a pool member does not have an untilBurnHeight value set, it means the pool can issue delegate-stack-extend. Am I assuming this right?

Thank you

[jcnelson]

Will pooled stackers have to re-stack again (even those that still have multiple cycles left)?

Yes -- all locked tokens will unlock after PoX 2 is live.

In that case what will happen and what we will have to do as pool operators? I read the SIP and I understand, they will have to call delegate-stx again, but if someone could confirm it, I'd be thankful.

Yes -- the users will each need to call delegate-stx, and the pool operator will need to call delegate-stack-stx and stack-aggregation-commit.

Note that you additionally have the option to call stack-aggregation-commit-indexed, which will return an index integer you can pass into stack-aggregation-increase. This new function stack-aggregation-increase was added in 2.1 to make it possible to add more STX to an already-locked-in PoX address without needing to first clear the stacking minimum (which stack-aggregation-commit forces you to do). So, if you have some straggling users, you could repeatedly call stack-aggregation-increase with their tokens as they delegate them.

Is there a way to know which pool members have increased their stacking amounts? So we can acknowledge that and issue delegate-stack-increase?

I believe this information is going to be emitted by the node to an event observer, so you'll be able to tell (cc @zone117x).

Is there a way to know which pool members have asked to extend their delegation?

You're correct -- as long as the user has still delegated to the pool operator at the current burn height (or if the user didn't specify a burn height), then the pool operator can call delegate-stack-extend to keep their STX locked.

[zone117x]

I believe this information is going to be emitted by the node to an event observer, so you'll be able to tell (cc @zone117x).

Yep that's correct. Although we are still waiting on this issue #3289 (associated PR #3318) to be completed.

[planbetterHQ]

Great, thank you for the help @jcnelson, @zone117x, @whoabuddy

[wileyj]

@jcnelson i can look into the miner taproot item.

[saralab]

Update :

• Verify that the .pox to .pox-2 transition works on testnet - @lgalabru - In Progress
• Verify that all new Clarity keywords and functions only become available after the transition - In Progress
  • Found a Type Checker regression and PR is in review , @obycode is working on property-testing - @obycode
• Verify that subnets instantiate on the public 2.1 testnet : @gregorycoppola - In Progress
  • Validated the NFT Use case with the latest 2.1 version
  • Merging clarity2 changes into subnets code
• Stacks API works correctly with Epoch 2.1 @matt - In Progress
  • Working on API updates to match the changes in this PR which fixes this issue

[donpdonp]

[X] stacks-unlock test line item should happen at 2022-Dec-14 11am EST

Stacking to taproot address (32 hashbytes) locked for 1 cycle. Unlock burn height 2,411,250
https://explorer.stacks.co/txid/0xc44914e4a03b239b67e7a0d8bf335725b679f4e05becddb2641d1fef3a4e5892?chain=testnet&api=https://2-1-api.testnet.hiro.so

update [2022-Dec-14]: locked STX did unlock after 2,411,250

[] payout to taproot address
btc taproot testnet address: tb1p3cgmhx7jduegf8u7028he826lat6nectec8mprv8wsfmwjetfccqz0emm3
to date (2022-Dec-9) no payments have been made to this address.
Start Burn Height for stack-stx call is 2,409,274, current height is 2,410,510. Maybe its reward slot hasnt been hit yet?

update [2022-Dec-24]: No payouts recorded to [1]. I'm not sure what this means. Perhaps the stacking minimum was above the amount stacked, or some other reason for no payout.
[1] https://blockstream.info/testnet/address/tb1p3cgmhx7jduegf8u7028he826lat6nectec8mprv8wsfmwjetfccqz0emm3

[netrome]

I have issues creating a clarity contract that triggers a runtime-caught CheckError. The proposed approach to to invoke a trait implementation within an at-block closure does not work since at-block closures are only allowed to call read-only functions, while traits only specify public functions (that may modify data). i.e. I can't invoke (at-block block-id (contract-call? ...)).

I have tried many other contracts, you can see some of my activity on the test chain here - but so far I have yet to figure out a way to trigger a CheckError that's caught at runtime.

@jcnelson I remember you mentioned potential ways to trigger these during our last Blockchain Engineering Weekly meeting, could you write short descriptions here of ideas I can try out?

Any ideas are much appreciated. I'm new to Clarity so I might be missing something obvious. Please respond with any ideas of contracts that could trigger a CheckError at runtime 🙏.

[netrome]

I've tried different clarinet versions locally, and they all reproduce the runtime CheckError. However, I'm currently not able to build Clarinet against the Clarity in the next branch of the stacks-blockchain. I suspect this is the version running in the 2.1 testnet.

If this is true, I should be able to reproduce the CheckError on https://stacks-node-api.testnet.stacks.co/ which should not run the next Clarity as I understand it. I will try this, and on the side see what I need to compile Clarinet against next.

[netrome]

Tested with Clarity on /chore/update-rusqlite (3bc04a8eaa3273d30b239114c4e3e9173c79b1e7) and I'm still not able to reproduce the passing behavior seen on chain. Just to be sure, I'll try again after merging in the latest next branch into /chore/update-rusqlite.

[obycode]

Make sure to use the right Clarity version when publishing the contracts. Note that this code is valid in Clarity 2 but should trigger the error in Clarity 1.

[netrome]

Ah I see. Now I can reproduce the passing behavior locally. I'll publish a contract with version 1 then. Super helpful, thank you!

[netrome]

Task failed successfully: I've deployed and executed the contract on-chain with Clarity 1 now, and it fails as expected. (function invocation). I don't see where in the UI I can verify the actual type of the error, but from my local experiences I know this should be a CheckError. There's a transaction fee in the transaction on the chain.

I will proceed with automating this test case in this PR hirosystems/stacks-e2e-testing#8