Not any bigger than package repositories on linux distributions, which include the list of all known software and sometimes even rules how to build them.

It's just plain text. If I can have a local dump of wikipedia, I'm pretty sure I can store a list of developer IDs. Especially when I'm a company controlling the hardware and knowing what is the minimum amount of space the hard drives have in my computers.

Extremely small - probably in the megabytes range I would guess.

Think about antivirus definitions - those are many, many times larger, and still they have been kept up to date over the internet for decades.

There is a very large list of binaries that can potentially be downloaded, each of which can have hundreds or thousands of versions, while the number of known virus fingerprints is relatively small.

Apple doesn't check binary hashes but developer certificates these binaries are signed with. Which there are a lot less of (ie. firefox and thunderbird share the same certificate).

From what I understood, Gatekeeper still sends an application specific hash/ticket when an application is opened, not just a dev certificate (e.g. https://lapcatsoftware.com/articles/catalina-executables.htm...). Did that change in Big Sur?

The notarization check is on first launch of an app, but it doesn't occur on subsequent launches, unlike the certificate revocation check.

But the first lookup would have to stay, with all the implications that the proposed alternative (download a list of all certs/tickets) was meant to overcome.

This is what Bloom filters would solve. I believe another poster said that Firefox uses them to quickly check valid certs.

Implementation wise, there are probablilistic DSs like bloom filters which solve this very easily with further checks necesssary for false positives.

Kilobytes to megabytes, see CRLite.