I assumed the difficult part of verifiable AI would be proof generation
That was probably the obvious place to look
More requests
More proofs
More overhead
Simple enough
I spent some time recently exploring one of the newer inference stacks built around verification and expected most of my attention to end up there
Strangely, it didn't
The SDK itself felt pretty ordinary
Import the package
Pass a key
Call the model
Nothing about it really stood out
Which, in hindsight, was probably a good sign
At first I thought the interesting part was the cryptography
Then I thought maybe the bottleneck would be proof generation
I don't think that's what keeps coming back into my head anymore
What keeps bothering me is something much lower in the stack
And honestly, I didn't expect that
Because the attestation mechanism makes sense
The mathematics seem fine
But eventually those guarantees inherit assumptions from secure hardware
And secure hardware inherits assumptions from manufacturers
That never sounded particularly important to me
Every system depends on something
Maybe this one is no different
Still, software ecosystems and hardware ecosystems don't really move at the same speed
Code gets replaced all the time
Supply chains don't
Protocols coordinate upgrades
Firmware roadmaps have owners
And if enough applications end up relying on similar enclave architectures, software diversity could quietly end up sitting on top of much less diversity underneath
Maybe that doesn't matter
I'm genuinely not sure
I suppose what surprised me is that I originally thought verifiable AI would mostly change how trust gets established
Lately I've been wondering whether it also changes where dependencies accumulate
Not higher in the stack
Lower
Which wasn't where I expected to find them
That thought only started occurring to me after spending time around some of the ideas people at @OpenGradient have been building around