[Design]: Signer Key Rotation LLD

[AshtonStephens]

Design - Signer Key Rotation LLD

Ownership breakdown: https://github.com/Trust-Machines/sbtc-v1/discussions/47

• Signer side
  • Primary: Marzi (@8marz8)
  • Secondary: Jacinta (@jferrant)
  • reviewer: Mårten (@netrome)
• Clarity side
  • Primary: Jesus (@setzeus)
  • Secondary: Jacinta (@jferrant)
  • reviewer: Gowtham (@SundarGowtham)

This ticket tracks creating the low level design document for the signer key rotation. For a low level design to be "complete" it must have the approval of the majority of the sBTC team and meet the criteria of the checklist below.

Acceptance Criteria Checklist

• [x] There's a written low level design doc with the following
  • [x] Clear descriptions of all component interactions including serialization format
  • [x] Diagram/s on how the component will work
  • [x] Clear descriptions of the programming languages and infrastructure that will be used
  • [x] Justifications for the design decisions
  • [x] A rough task breakdown of the component's implementation plan referencing inter-dependencies
  • [x] A general list of the of tests required for the component
• [x] Low level design has been reviewed and approved with the secondary.
• [x] Low level design has been reviewed and approved with the team.
• [x] The task breakdown is refined with GitHub issues for each task

[setzeus]

https://docs.google.com/document/d/1Bwi1jM_7p9OqNGT41eWCuoKnfoOrNHycqxby3XSonCA/edit?usp=sharing

[jferrant]

Not entirely sure how the rotate keys is happening. Do we store one aggregate key at any given time? Two signer sets at most? Once all keys are rotated. and a new set-aggregate-key called, does the second signer set come into affect? How do we know that the set-aggregate-key value actually corresponds to the previously rotated set? Just not entirely sure the order of operations/what is stored in the contract at each stage of the rotate key process.

[djordon]

After rereading the doc, I have a decent understanding of the key rotation process, but I want to ensure we thoroughly document the different failure modes and their resolutions. Here are some specific concerns that I had in mind:

1. Temporary Lockout Risks: Is it possible to temporarily lock ourselves out? The risk exists if signers do not retain their old private keys. Even if a clarity contract call is accepted, signers should not delete their old keys until the contract call is committed and several stacks blocks deep. Considering that reorganizations can occur up to 150[^1] stacks blocks post-Nakamoto, it might be wise for signers to retain their old keys for at least that duration. Perhaps the contract should accept both the new key and the previous key for 150 stacks blocks to mitigate risks associated with reorgs. If a reorg occurs, it's unclear to me whether lost transactions are automatically replayed or not[^2].

2. Permanent Lockout Risks: Can we permanently lock ourselves out of any contracts? Yes, if enough signers' keys are lost then we will be permanently lockout. This risk seems unavoidable.

I suspect that this is comment should probably be moved to a different ticket. Maybe there isn't much to do on the clarity side? Maybe it's up to the signers to make contract calls with the right keys? But I think we need to have a plan for forking and key rotation somewhere (if we don't already).

[^1]: I think reorgs can happen "easily" up to and including 6 blocks but never after 150 blocks. [^2]: The Stacks Nakamoto paper goes into detail the new forking rules but I don't think it mentions what happens to the "lost" transactions. Replaying transactions is mentioned in the Bitcoin Reorgs section of the stacks online docs here, and my parsing is that we do not replay transactions, which seems odd.

[AshtonStephens]

~@8marz8 this is in review / done right?~

Sorry, I mixed this up with a different one, we haven't started this one yet.

[netrome]

~@8marz8 this is in review / done right?~

Sorry, I mixed this up with a different one, we haven't started this one yet.

I thought this one was covered by the LLD posted by @setzeus in the first comment.

[AshtonStephens]

Same as:

• 56

• 57

@setzeus / @hstove can you two do a quick check of this and the two above to make sure we've mostly checked the boxes and then clear mark this as resolved?