The three parts are:
- time-based leading bits.
- sequential counter, so that multiple UUID 7s generated very rapidly within the same process will be monotonic even if the time counter does not increment.
- enough random bits to ensure no collisions and UUIDs cannot be guessed.
Note that multiple rounds of cryptographic hashing is not considered sufficient anymore; PBKDF2 and Argon2 are Key Derivation Functions, and those are used instead of hash functions.
"New UUID Formats – IETF Draft" https://news.ycombinator.com/item?id=28088213
draft-peabody-dispatch-new-uuid-format-04 Internet-Draft "New UUID Formats" https://datatracker.ietf.org/doc/html/draft-peabody-dispatch... ; UUID6, UUID7, UUID8
And TBH I'm concerned that UUIDv1 had a timestamp, then it was removed completely in UUIDv4 and now the timestamp concept is being added back to UUIDv7... There are legitimate use cases where you simply don't want to have timestamps in your IDs.
Security consultants can be quite blunt in their approach and companies will often yield to their every demand for the sake of easy compliance and to avoid having to explain stuff.
[0]: https://youtu.be/mAyW-4LeXZo (Clock Synchronization in Distributed Systems by Martin Kleppmann)