Too many key rotations

[corrideat]

Problem

In #2988, an issue that's known but apparently has never been created. There seem to be too many key rotations in, e.g., groups. We are supposed to only rotate keys when a member leaves or is removed, but if we look at the group income group, we can see many key rotations that have occurred even when group membership hasn't changed.

This isn't supposed to create any issues other than unnecessary operations in the chain, but, as #2988 shows, in practice it can amplify other logic issues. The other issue with this is that this isn't something that is designed to happen, and therefore shouldn't happen.

Solution

Identify the cause for this and fix it. It may be a Group Income issue, a @chelonia/lib issue, or both.

[taoeffect]

Preliminary investigation by Devin:

Summary: The issue reports key rotations happening even when group membership hasn't changed. I've identified several potential causes across both group-income and libcheloniajs.

Potential Causes:

1. Multi-client race condition (Group Income)
When a member leaves, ALL remaining members independently try to rotate keys. The flow is:

• removeMember sideEffect calls setPendingKeyRevocation for ['cek', 'csk'] (group.js:863)
• Then leaveGroup calls rotateKeys (group.js:1827)
• Each client checks pendingKeyRevocations and tries to send OP_KEY_UPDATE

There's a preSendCheck (index.js:178-187) that checks if keys have already been rotated, but there's still a race window where multiple clients could all prepare and send OP_KEY_UPDATE before any is processed.

2. Foreign key mirroring cascade (libcheloniajs)
When OP_KEY_UPDATE is processed, keyRotationHelper (internals.ts:170-281) mirrors the rotation to any contracts watching via foreign keys. This is intentional but causes cascading rotations - e.g., when group keys rotate, chatroom keys with foreign keys pointing to the group also rotate.

3. Identity PEK rotation (Group Income)
After rotating group keys, each member calls revokeGroupKeyAndRotateOurPEK (group.js:1828), which rotates their own identity PEK. For N remaining members, this causes N separate PEK rotations.

4. Foreign key sync on contract load (libcheloniajs)
chelonia/private/deleteOrRotateRevokedKeys (internals.ts:2152-2280) is called when a contract starts watching foreign keys. If the foreign keys are out of sync with the foreign contract, it sets pendingKeyRevocations and triggers a rotation. This could cause "unexpected" rotations when contracts are synced.

5. Re-sync after receiving new keys (libcheloniajs)
When OP_KEY_SHARE is processed and new encryption keys are received, contracts are marked as "dirty" (internals.ts:1268) and re-synced. Contracts with foreign keys are also marked dirty (internals.ts:1311-1315). During resync, sideEffects run again, which could trigger setPendingKeyRevocation again.

Most Likely Root Cause:
The issue says rotations happen "even when group membership hasn't changed". This points to causes #4 and #5 - the foreign key synchronization logic in libcheloniajs. When contracts are synced or receive new keys, the foreign key watching mechanism can trigger rotations to keep keys in sync, even without membership changes.

Would you like me to investigate any of these causes more deeply, or do you have additional context about when these rotations are occurring?