#sxt $SXT @SpaceandTime
I used to think the interesting part of Proof of SQL was the final ZK proof. After reading Section 3 more carefully, I think an earlier detail deserves just as much attention: how the data commitment is updated.

A table can keep growing as new blocks, transactions or records arrive. If every update required rebuilding a cryptographic commitment from the entire historical table, the cost would become a serious bottleneck. The whitepaper describes an updateable commitment: validators can combine the old commitment with newly appended data to produce a commitment for the updated table, without needing access to all the old rows.

That sounds like a small implementation detail, but I see it as a scaling decision. It means the verification layer is designed around datasets that change continuously, not just static snapshots.

I also find the distinction important: the commitment is the compact fingerprint maintained for verification, while the underlying data still has to be stored and kept available elsewhere in the network.

For me, this is one of the less obvious parts of Space and Time. The value is not only proving a query once. It is maintaining a verifiable history as the dataset keeps moving.