[Nakamoto] What if DKG takes longer than the reward cycle?

[jcnelson]

It is possible, but unlikely, that DKG will take longer than the reward cycle. In this case, the next reward cycle begins without an aggregate public key. In the current SIP, this would lead to a chain stall because there'd be no way to advance the Stacks chain state.

How confident are we that this never occurs?

[AshtonStephens]

@xoloki are you familiar with what would happen here?

[xoloki]

This was more of a concern with WSTSv1, which took hours for DKG with 4k reward slots. The probability of someone losing network etc was fairly high, which would have necessitated starting over.

With WSTSv2, DKG takes 90 seconds. I don't think this is as much of a concern anymore.

[jcnelson]

Yeah, I'm not worried about DKG itself taking forever. I'm more worried about a long-standing network partition or some other implementation bug or unfavorable environment setting that prevents DKG from completing.

[AshtonStephens]

@kantai: "I wonder if there's a "middle path" here -- treat it as a catastrophic failure, but have a recovery plan"

[jferrant]

Here is my sort of hard to follow brain dump. :P
I was under the impresson this is a potential failure case and its proposed fix:
State:
Signers N stx are locked.
Signers N are reaching the end of their tenure...Prepare phase has stated.
Signers N+1 are determined. (Their stx are immediately locked)

Failure case: Signers N+1 are failing (stacker db is broken, a ton of signers are off line, etc.) to set DKG in the clarity contract

Signers N+1 failing because of malicious behaviour:
-> They start being penalized somehow? not sure how since they are not producing blocks yet. But they are flagged as malicious and future penalizations enacted?

Signers N+1 failing for none malicious reasons:

-> No one is penalized but both signers N and N+1 are locked and both are motivated to get them unlocked / start receiving rewards

1. New Reward cycle N+1 starts with no DKG:
   -> Signers N, are obligated to continue producing blocks and processing transactions while waiting for DKG to be set/they continue receiving payouts
2. DKG IS Set and handoff isn't happening (even into reward cycle N+1)
   -> Signers N are penalized.
3. DKG IS SET and handoff DOES happen
   -> Signers N are free'd from their obligations
   -> Signers N+1 are penalized for any recorded malicious behaviour
   -> Signers N+1 begin performing their duties
   Caveats: There must be dynamic grace periods afforded to signers who are failing to do their duties because of external factors. i.e. Signers N+1 are not penalized if they HAVE set DKG but the old signers have not passed on the funds.

All these caveat/penalities can be ignored for the initial release. Their logic is the hardest part in my own opinion.

This would mean that we would just need logic to ensure tenure extends when DKG is not set yet. and stx remain locked until the handoff occurs.

I may very well be missing something here though that makes the above incredibly difficult (even without the penalization logic)

[jcnelson]

My thoughts on this so far are in the same vein as @jferrant's write-up -- find a way to keep the signers in the now-finished reward cycle to stick around long enough for the signers in cycle N+1 to come online.

Suppose the chain freezes for the entirety of the prepare phase, and comes back online at the start of the next reward phase. Then, the following happens:

1. Old stackers stop signing blocks and sBTC transactions at the start of cycle N+1, since they're no longer the signing set
2. The PoX anchor block for cycle N+1 gets chosen. It's the last tenure-start block of the reward phase of cycle N, so unless the whole of cycle N is empty, we have a PoX anchor block.
3. Stackers for cycle N+1 try and try again to carry out DKG via the pox-4 smart contract's StackerDB instance. They continue until they succeed, even if it's in the reward phase of cycle N+1.
4. Once Stackers complete DKG, they individually submit a Stacks-on-Bitcoin transaction that votes for the aggregate public key and wallet address. The transaction encodes the aggregate public key and reward cycle number, contains an input which could only have been generated by the owner of the stacker's PoX address's private key, and contains an output equal to the wallet's p2tr output. I'm not sure yet the best way to encode the aggregate public key and reward cycle number, because some consideration will be needed for users of custodial wallets who cannot send transactions with OP_RETURNs.
5. Once enough Stackers have voted for the aggregate public key in this manner, then the new wallet address and block signing key will be apparent from just state written to Bitcoin. The old Stackers send the BTC to the new wallet address
6. Once the BTC is received by the new Stackers, they begin signing off on blocks. Because the miners will have seen these Stacks-on-Bitcoin transactions, the first block the miner produces materializes the aggregate public key and wallet address into .sbtc (as well as any other DKG metadata, by means of a zero-fee transaction).

I think this works because it incentivies the right people to take the right actions:

1. Old stackers want their STX to unlock, so they'll be willing to watch the Bitcoin chain for the voted-upon wallet UTXO and be willing to pass the BTC over to it.
2. New stackers want the PoX payouts and eventually want their locked STX back, so they'll be willing to continue to try DKG indefinitely until they succeed, and they'll be willing to send these Bitcoin transactions.
3. Miners want their STX block rewards, so they'll work with the old and new signers to produce blocks that contain zero-fee transactions which recover the system.

I'm not sure further punishment is needed beyond that which system unavailability metes out. New stackers already miss PoX payouts from the system not being online, and once they come online, they'll be obliged under the current sBTC rules to process deposits and withdrawals as soon as possible (since only once they're all cleared will the PoX rewards resume).

[kantai]

From my understanding, the problem this is attempting to solve is:

1. Stackers must elect a public key through the pox-4 contract.
2. If there’s a bug, delay, or whatever, then the pox-4 election does not occur before the new stacking set is responsible for block production.
3. Block production isn’t possible because there’s no stacker pub key and so election cannot occur at this point.

I think there’s two possible solutions that leave the election still in normal stacks transactions:

1. The prior stacker set doesn’t issue a TenureChange transaction during the last block of their cycle, and instead issue an extension.
2. Allow the first block of a cycle to include pox-4 election transactions as long as it concludes successfully.

(2) seems the most seamless from the perspective of stackers: their election transactions should be “stuck” in the mempool anyways, so they don’t need to do anything special. It does mean that block acceptance and processing needs to special case the first block of a cycle. (1) is the least work from the perspective of the stacks node: basically it doesn’t do anything to handle this case, and it just relies on the prior stacker set behavior.