Client-side changes for event streams

[mskd12]

Description

This PR prototypes the client-side of the event streams design. The high-level logic is as follows.

Every X seconds, do:

• fetch the latest stream head object & verify it with the committee keys (if we had object subscriptions, we wouldn't have to poll this way)
• if it got updated since we last checked, fetch the newly emitted events and verify them against the new stream head.

Thoughts

Some design decisions that can help simplify the design (things I noticed as I prototyped this):

• Deterministic derivation of the stream head's object ID from the event type
• Whether the client needs to download the full checkpoint data or not: Would be nice to avoid if possible. A few places this crops up:
  - ADS choice: Using hash chains or similar data structures avoids it (as opposed to counters)
  - Object inclusion (verifying the latest state of the stream head object). The below prototype downloads the full checkpoint to verify the object's latest state (the only part of the prototype I don't like). To avoid this, we'd have to include a new field in the summary that contains a hash of all the object references (or a Merkle tree if we want to future-proof it).
• In the below design, the StreamHead contains a:
  - digest (e.g. hash chain head)
  - a pointer to the last emitted event (to help figure out where to start looking)
  - counter (to help determine how many events to request)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)			Jan 7, 2025 11:58am
sui-kiosk	⬜️ Ignored (Inspect)			Jan 7, 2025 11:58am
sui-typescript-docs	⬜️ Ignored (Inspect)			Jan 7, 2025 11:58am