If the session store is set, we use it to store our session keys and reuse them across transactions. Otherwise, if the 'global' session store is disabled, we create a local cache that is valid only for a single transaction.

This cache keeps track of the matching encrypted randomness for the session keys and their correspondent unencrypted value. This way we can save on the amount of asymmetric decryption operations.

This cache keeps track of the session key information for each recipient tree, which is then used to encrypt the view messages.

This cache may create interesting eviction strategies during a key roll of a recipient. Whether a key is considered revoked or not depends on the snapshot we're picking.

So, consider two concurrent transaction submissions:

• tx1 and tx2 pick a snapshot where the key is still valid
• tx3 and tx4 pick a snapshot where the key is invalid

However, due to concurrency, they interleave for the encrypted view message factory as tx1, tx3, tx2, tx4

• tx1 populates the cache for the recipients' tree with a new session key;
• tx3 notices that the key is no longer valid, produces a new session key and replaces the old one;
• tx2 finds the session key from tx3, but considers it invalid because the key is not active. So create a new session key and evict the old on;
• tx4 installs again a new session key

Since key rolls are rare and everything still remains consistent we accept this as an expected behavior.