E2E Testing Nakamoto Checklist

[ASuciuX]

Questions

• Does follower validate state/blocks? YES

• When do tenure extends happen? Do they have coinbase (or only fee promise)?

  • Current: Only when sorition is missed (burn block with no stacks block commit op)
  • Future: Long period / or miner failed to propose

• What are chunks? (What do they contain? Does miner remember what they proposed (for a chunk to be created)?)

• If the majority of miners are acting maliciously while a minority follow the correct procedures, once the mining winner is selected, will the correct block still be validated on-chain even if the winner belongs to the minority? Or could the malicious majority manipulate the data and falsely claim they’ve won the block?

• If Nakamoto forks (malicious majority)? Which forks is followed by others?

• Are miners ever penalized?

  • What happens if miner only submits nakamoto coinbase (and no next fast blocks)?

• Are signers ever penalized?

  • Field in block header, which signers are behaved. If signers’ bit is zero, stacking slots will be burned instead. (punish slow signers?)

• Can you stack using bitcoin transactions? This should be possible, otherwise total failure if no Stacks blocks in prepare phase or the current 30%+1 signer is malicious and doesn’t sign any transactions

• Is this the typical process? Yes. The miner writes data to the stackerdb, signers read from it, then communicate with their nodes (mostly followers) to validate the data, and finally send back chunks through the stackerdb to the miner.

• Does a miner node always need a signer? No

• When the bitcoin transaction for miners have to be sent in the flow
  btc. | 1000
  stx. 300. | 301 302
  miner (that is not the winner of this tenure) submits after seeing 301 for 1001
  miner that is the winner of this tenure can submit it before 301 is anchored as it knows it (will not influence the overall flow with anything)
  301 tenure change tx so i commit to that in my bitcoin transaction

Chaos Testing

Anything that can go down will go down

• Investigate the use of "toxiproxy" to simulate instability locally
  • Swallowing communication (%)
    • Miner<>Signer (RPC)
    • P2P<>Followers<>Miners
    • Solution: Docker composed into regtest-env
      • Metric: Block height; Cycles with rewards; Number/% of stuck followers;
  • Censoring Stacks burn ops
    • “Flash blocks” or censorship
    • Metric:
      • Do signers recover? ()
      • How many censored blocks until
    • Unlikely: Entire prepare phase censored?
  • Speed
    • How fast to bitcoin/nakamoto blocks have to be to break the system?
    • Unusually long bitcoin block; what happens? How many extends?

Forks

Stories

• When a new burn block is mined; fast blocks should stop progressing (Integration) #5232
  • Todo: Write test for this (not present in codebase)
• Miner ignores latest nakamoto blocks; instead proposes “fork” nakamoto block using the previous to last block in the tenure. This integration test evaluates the behavior at the end of a tenure. Specifically, the miner will broadcast the last block of the tenure, even if the signing is completed after the next burn block arrives. Additionally, the signers will not sign any block that arrives after the next burn block; however, they will complete any signing process that was already in progress when the next burn block arrived.
  • This means that the block proposed by the miner will be invalid and he should built on top of the latest block available.
  • similar tests but don't include signers' validation forked_tenure_invalid and forked_tenure_okay
• What happens if 40% refuse to sign? Invalid till threshold is met
  • this unit test verifies that for 66% voted when threshold is 70% the isn't signed enough to be anchored making it invalid
  • Integration test for: miners fork and the signers split between them (if more than 30% of signers go with 1 fork, both forks would not produce blocks anymore)

Miners

Less important? They’ll figure out how to restart. Someone else will take over.

Stories

• Other miner can’t propose on behalf of current tenure miner. Is the sig/key checked?
  • Unit test
• Signer doesn’t respond to proposal (delayed by 2 minutes); Miner in the meantime tries new proposal(s); Instead signer later responds with “old” valid proposal acceptance; Does miner recover and continue off of “valid” chain? (Integration/Unit)
  • Signer broadcasts (which makes it easier, and miner should recover by receiving new block over P2P)
  • Miner proposes update block (same height), but signers then validate previous proposal (same height)
    • Integration test
• If signers rollover (new cycle, different signers); Miner shouldn’t accept sigs from “old”/previous set of signers - Integration Test #5215
  • The tenure-change locks in the chain tip
• Signer (or anybody (not on same network)) sends invalid chunk(/block) to miner? What happens? (Integration)
  • Doesn't help; Node defines this behavior
• Is it tested the way miners are intended to run when the epoch upgrade happens on the X selected block height. - Integration Test - Activation Block is Flashblock #5127
• Would temporary network/communication issues on the miner/signer disrupt their behaviour and need to be restarted? E2E Test - Would temporary network/communication issues on the miner/signer disrupt their behaviour and need to be restarted? hirosystems/stacks-e2e-testing#64
  • Could maybe be implemented with the toxiproxy setup.
  • Wait for nakamoto-testnet fork and then do it.
• Transaction that can't be added to the mempool is anchored by the miner in valid block - Integration Test - Non standard transaction, but not invalid being anchored #5129
• Could a lot of small miners, each spending 0.1$ worth of btc per block, do anything malicious to congest the communication/network? Integration Test - DDOS Try Many Small Miners  #5131

Signers

Stories

• Signer rejects invalid proposal from miner
  • unit test
  • integration test
• Miner proposes bad/invalid block; Signer should NOT accept it; (Unit/Integration) (/validate is RPC called by signer before signing)
  - the integration hits from here with UnknownParent
  - If majority (maliciously) signs/approves invalid block; the fair minority should still work off of “valid” chain? They would have to stall as there are not enough signatures (Integration)
• Add extensive test cases for possible "invalid" blocks #5136
•  Signer can only write to their own allotted StackerDB slot (Unit)
  • this test only checks they have their own slot, not that they run on it
  • this test checks the write through public key check
  • If chunk is taken; node will refuse the chunk
• Signer tries to write too frequently to the StackerDB. (Unit) Test - Config Stacker DB Signer #5122
• Prepare phase missed stalls system — unrecoverable
  • Question: Can you stack using bitcoin transactions? This should be possible, otherwise total failure if no Stacks blocks in prepare phase or the current 30%+1 signer is malicious and doesn’t sign any transactions.
  • Answer: Yes, it is possible and integrated at the consensus level. (SIP section here)
  • Question 2: Would it still stall? Is the signer set calculated on a Stacks Block?
  • Answer 2: There must be at least two tenure-start Stacks blocks mined in the prepare phase in order for the system to detect and compute the new reward set. Otherwise, it would stall.
• How can the stackerdb be corrupted/stalled?
  • Post invalid chunk somehow? (Signers) - try sql injection
  • Invalid chain state? (Node; Unit test)
  • P2P stalls (Node; Unit test)

Tenures

Stories

• Miner proposes many tenure-extends; (unit test) #5234
  • Signers will reject
  • Signers listen to: StackerDB events; proposal events; burn block events