Tamper Proofing in the Digital Age: A Look at Proof of SQL

Welcome to this interview! Today, we are speaking with Jay White, Co-Founder and Head of Research at Space and Time.

Jay is involved in the development of Proof of SQL, a database tamper-proofing mechanism designed to ensure the integrity of SQL operations within the Space and Time data warehouse.

During this interview, we will look at Proof of SQL and how it works. We will also discuss the inspirations and challenges encountered during its development, as well as its integration with existing security frameworks and authentication mechanisms to enhance overall data security.

Additionally, we will delve into data provenance, continuous monitoring, and future development plans for Proof of SQL. So, let's dive in and explore more about this technology that aims to strengthen data integrity and security.

Hi there! Please introduce yourself and tell us what you do

I'm Jay White, Co-Founder and Head of Research at Space and Time. I lead the development of Proof of SQL, Space and Time's zk-proof for SQL operations, which cryptographically guarantees that queries run in Space and Time are verifiably tamperproof.

Can you provide an overview of the Proof of SQL database tamperproofing mechanism and how it works?

Proof of SQL comprises two interoperating parties: the prover, which lives in the data warehouse, and the verifier, which lives in the validator layer.

When data is ingested into the Space and Time data warehouse, the verifier creates a digest of the data—essentially a fingerprint. Then, when you submit a query request, the data warehouse returns both the result and proof of the result to the verifier.

The verifier checks that the returned result matches against the fingerprint, which allows us to verify that the query's result is correct.

During the research phase, what were the primary sources of inspiration or related works that influenced the design of Proof of SQL?

A host of interesting zk literature influenced our design of Proof of SQL. We took the best components of each protocol as inspiration and tailored the architecture to the use case we built it for, tamperproof SQL operations.

Some components, like our commitment schemes and vanishing checks, borrow from projects like Bulletproofs, Halo2, and PLONK, but as a whole, what we've built is entirely novel.

When implementing Proof of SQL, what were the key considerations in terms of scalability and performance, especially in large-scale database environments?

Proof of SQL is unique among other protocols in that it's designed to work with SQL analytics, which deals with vast volumes of data and is expected to run with low latency. We have to optimize which data we're running the proof against and how quickly we can produce it.

Those are the two key components to making Proof of SQL run efficiently at scale. We solved the former by doing smart indexing to reduce how much data we need to process.

And we solved the latter by executing the most compute-expensive portion of the proof on a GPU—we even built our own GPU acceleration framework for it.

Could you provide insights into how Proof of SQL addresses data provenance? How can users trace the origin and history of specific data entries within the tamperproof database?

Proof of SQL guarantees that your database is tamperproof—that no one has manipulated the data. If, when you create the data, you create some sort of origin, you know that origin will always be there. You won't lose it.

So you could easily set up your table to have that, and use Proof of SQL for data provenance.

How is Proof of SQL designed to integrate with existing security frameworks and authentication mechanisms to provide a comprehensive security infrastructure?

Space and Time has built some really unique security features into the platform that work in conjunction with Proof of SQL. We've partnered with Sotero, a leading data security platform, to provide in-database encryption, meaning that private data can be encrypted end-to-end.

We've also adopted a novel solution for authorizing resources in a decentralized network that leverages public key cryptography. Proof of SQL works with these features to maintain the security of a user's data and ensure that it's tamperproof.

How do you approach testing and auditing the Proof of SQL mechanism to ensure its reliability and effectiveness over time?

We test everything that we code. Everything that we build goes through a battery of unit tests, smoke tests, integration tests—everything. Proof of SQL is only in alpha today, but we plan to leverage an external firm for auditing soon.

Today, we're ensuring we thoroughly test the protocol because we understand its importance.

As the developer of Proof of SQL, what advice would you give to organizations considering adopting this tamperproofing mechanism to ensure a successful implementation and deployment?

As organizations plan to utilize Proof of SQL, one of the biggest security considerations is around the data source. Proof of SQL can prove that data in your database hasn't been manipulated or changed, but you still need to ensure that the source of data is tamperproof to ensure that the entire pipeline is trustworthy.

How does Proof of SQL handle continuous monitoring and validation to detect and respond to potential tampering incidents in real-time?

Proof of SQL was designed to detect tampering at query time, but you could easily set it up to facilitate continuous monitoring. All you would have to do is periodically send an automatic health check query, and Proof of SQL would then be able to detect manipulation.

Finally, can you share any future research or development plans for Proof of SQL? Are there any upcoming features or improvements that users can look forward to?

The future of Proof of SQL is very bright. One of the things users can look forward to is expanded SQL support. We currently support a limited subset of SQL, but we're working towards continually adding support for more general SQL queries.

Additionally, one of the most exciting upcoming features is lighter-weight verification that can be done by a smartphone, a laptop, a smart contract, client-side… verification that can be done anywhere.