Tamperproof SQL Ledger
Data is the backbone of every industry in the world. Banks rely on transaction data to inform credit assessments, supply chain systems use data to optimize inventory management, and retailers leverage consumer data to personalize shopping experiences. Regardless of the business model, data is an extremely valuable asset to the modern enterprise, and companies have a vested interest in ensuring that the data they’re using is accurate and verifiable.
A tamperproof ledger allows a business to keep a verifiable record of its data. These ledgers come in various forms, including the blockchain and enterprise hyperledgers, but they all share the same problem: limited storage and compute. The ledger is designed to record only the most important aggregations of a business’s data. Web3 games only store NFT ownership and game-state data on-chain, because the blockchain can’t handle massive amounts of in-game telemetry. Similarly, a bank can’t store all of its intraday transactions on a hyperledger, just its daily profit and loss.
Instead, businesses manage this granular data in a SQL database, where it’s rolled up into pieces of information that can be published on the ledger. But if the database is tamperable, how can a business trust that the aggregated data is accurate? And if inaccurate data is added to the ledger, what consequences does that have for the business?
Consortium ledgers
Over the last decade, banks and other financial enterprises have adopted consortium ledgers as a trusted way to share data with other institutions. A consortium ledger functions essentially like a blockchain that is privatized and controlled by a consortium of enterprises instead of a decentralized network. Rather than thousands of nodes all over the globe, the network is operated by ten different banks, for example. Each of the ten banks has access to the data shared by the other nine without having to trust the integrity of any one of them. Instead, trust is secured by the immutable ledger.
However, much like a blockchain, this ledger isn’t built to function as a transactional database. Enterprises still manage their transactions in Oracle, PostgreSQL, KX, or something of the sort. A bank deploys a SQL database to manage its order books, then marks its P&L to market once a day to be shared with the other banks in the consortium. Each consortium member can trust that once this bank marks to market, the data on the ledger can’t be manipulated.
Still, there’s no way to guarantee that the granular transactions used to calculate P&L are real and verifiable. How can Bank A be assured that a DBA at Bank B didn’t change a few of the intraday prices in the database before that bank marked to market? Even if Bank B has strict SOC 2 compliance controls and regulatory audits, it’s not a totally fail-proof system. And if the data rolled up to the ledger can’t be trusted by other banks in the consortium, then the ledger itself can’t be trusted either.
Real estate bidding
This problem extends far beyond consortium ledgers and financial services. For example, if a company is running a digital marketplace for bidding on foreclosed houses, they’re dealing with data of significant monetary value. Losing even just a few rows in a table could cost tens of thousands of dollars to resolve. Ensuring that the data is tamperproof is critical to the function of the business.
For a business like this, a loss of data not only results in a loss of the significant value tied directly to that data, but also affects the many downstream business processes that rely on it. Recovering from, for example, a table deletion could conceivably cost the business days of productivity and millions of dollars.
And despite standard access controls, there’s no way to prevent it from happening entirely in a typical database. Even a highly secured database is vulnerable when a business cuts corners for the sake of efficiency, when access controls aren’t set up properly, or when one of the permissioned DBAs makes a human error.
Web3 custodial assets
Unfortunately, Web3 faces a similar issue. Though the blockchain is tamperproof, the off-chain systems connected to it aren’t, and the tampering of these off-chain systems can result in value loss on-chain. This is one of the core problems of centralized exchanges.
When you buy crypto from a centralized exchange, you’re not actually minting it to your own wallet. You’re trusting that the exchange went and purchased it on your behalf, and that they’ll mint it to you when you’re ready to take custody. But more than likely, the exchange isn’t actually minting crypto on-chain and paying gas every time someone makes a purchase, they’re only doing so if and when the user is ready to take custody of it. The user has no way of knowing whether the exchange actually owns the crypto it claims to own on their behalf.
The same is true for any custodian, like a Web3 game, for example. Many Web3 games are working to abstract away the complexity of blockchain for their players by providing a familiar interface and experience. You might log in to a game on Steam and purchase a weapon or an upgrade using Steam credits, and in theory, the game is minting it as an NFT on your behalf. But, like the centralized exchange, the game is most likely just waiting until you decide you want to take custody of your NFT before paying the minting and transfer gas.
The Space and Time solution
The only way to fully secure trust in off-chain data is to connect it to a verifiable database. Each bank needs to be able to verify that no other bank manipulated its P&L (or the data used to calculate P&L) before adding it to a consortium ledger. Executives at a real estate bidding company need to know that data can’t be tampered internally. Users of a centralized exchange or players of a Web3 game need assurance that their assets are real. All of these use cases require Space and Time.
Proof of SQL
Proof of SQL is the novel cryptography we’ve developed to cryptographically guarantee SQL operations. It proves that, when you run a query in Space and Time, the computation was done correctly and both the query and the underlying data are verifiably tamperproof. Proof of SQL allows you to connect any off-chain SQL database to any tamperproof ledger, including the blockchain, with verifiable assurance that data wasn’t manipulated before it’s added to the ledger.
If every member of a bank consortium is using Space and Time to manage its data, then no bank has to trust that each other member is calculating its P&L correctly. It’s cryptographically guaranteed by Proof of SQL.
Archival of immutable ledgers
Space and Time uniquely uses biscuit tokens to support fine-tuned, role-based access control. A table in Space and Time can’t be deleted without explicit authorization from the user that created the table, effectively making it much more difficult for anyone to accidentally or maliciously do so. Tables in Space and Time are also replicated to a secondary cluster and archived to IPFS, ensuring that even in the event that someone does delete a table, the data is easily restored with little downtime.
A company managing terabytes of important real estate data doesn’t have to worry about the catastrophic effects of a table deletion, because Space and Time allows for tamperproof archival of immutable ledgers that are interfaced with low-latency standard SQL.
Tamperproof SQL ledger
A cryptographically guaranteed off-chain database is the perfect complement to a tamperproof ledger like the blockchain. Data that can’t be stored on-chain can be stored in Space and Time. Computations that can’t be done with a smart contract can be run in Space and Time and secured by Proof of SQL. This allows the database to function essentially as a tamperproof ledger, but with the storage, compute, and SQL interface required for business operations.
With Space and Time, a centralized exchange can’t falsify records of which users bought what crypto. They also can’t just delete a table with those records in the event of an audit. Space and Time provides verifiable assurance that custodial assets—such as crypto on a centralized exchange or NFTs in a Web3 game—are real and belong to the user.
Expanding to analytics
Even with a tamperproof SQL database, business processes are still vulnerable to manipulation and inaccuracy when they’re connected to a separate analytic system. Each point-solution in your data management stack is a potential point of failure. Executives need to know that the report on the state of an order book, the state of real estate auctions, or the state of gaming data is accurate and realtime. If the transactional data is stored and processed in one database, but analytics are run in another, and ETL tools are used to migrate data between systems, it doesn’t matter if the database is tamperproof, because data can be tampered at any other point.
Businesses need one fail-proof system for both transactions and analytics. Removing point-solutions ensures that data isn’t lost during transfer, manipulated in one system before it’s sent to another, or otherwise unaccounted for. That’s why we built Space and Time as an HTAP data warehouse—one SQL database for both transactions and analytics… tamperproof and verifiable.
