Expanding Smart Contracts with SQL

Expanding Smart Contracts with SQL
Special thanks to Jun Jiang from DePHY Network and Ryan Soury from Usher Labs for feedback and insights.

In 2008, the alarms on Wall Street rang as sophisticated traders descended into a primal frenzy. Overleveraged financial institutions, collapsing under the weight of subprime mortgage-backed securities, left greedy bankers exposed and begging for bailouts. The central banks, desperate to retain their grip on power, paid for the bankers’ sins from the common man’s checkbook. This betrayal laid bare the centralized monetary system’s flaws, revealing the need for a newer, freer, and fairer financial system.

Just as the American Revolution and the constitution that followed separated church and state, a new revolution called Bitcoin emerged to separate money and state, enabling many of the same liberties and freedoms fundamental to self-determination.

Blockchain technology is freedom technology. It enables us to build financial, identity, information, and social coordination systems that do not require trust in a centralized intermediary.

Individual liberties thrive in a world where:

• The central bank does not control the flow of money
• A single platform does not control social discourse
• A single company does not control digital identities

Many of the differences between this new world and where we are today lie in the technical capabilities of blockchain platforms.

The first generation of smart contracts was the tip of the iceberg that enabled these freedom systems; however, they are fundamentally limited in their capabilities.

In this article, we explain some of the critical limitations in current smart contracts and how a new system, “SQL Smart Contracts,” used in TRUF.NETWORK, provides a more technically capable foundation to unlock human freedoms and realize blockchain’s potential as a new computing platform.

---

Smart Contracts: Programming The Truth Machine

“The root problem… is all the trust that is required to make it work.” - Satoshi Nakamoto

A blockchain’s initial core property is immutability; once a certain threshold of stakeholders (or “nodes”) in a network agree that something is true, the blockchain will retain a permanent record of that truth.

Blockchains use a variety of “proof” mechanisms in which nodes expend large amounts of value in the form of computing power, financial stake, or reputation to ensure that malicious actors cannot manipulate the truth.

If Bitcoin is the “truth machine” for digital currency, Ethereum is the “truth machine” for more complex financial products.

Ethereum expands on Bitcoin’s capabilities by creating a programmable design space where developers can implement any logic to be deployed, verified, and executed across a series of nodes.

This means we can now create systems that remove the need for trust in a central authority beyond just currency!

Any system requiring central authorities—such as:

• Lending
• Real estate deeds
• Identity information
• Social media
• Economic metrics

can now operate without central intermediaries. This is an entirely new world!

A smart contract is a program developers write and deploy on a blockchain, the canvas for developers to create decentralized applications.

The term “smart contract” does not mean a legal contract where two parties are bound to certain rights and obligations. Instead, it means the application is guaranteed to function exactly how the code is written indefinitely.

• Lending contracts guarantee that borrowers and lenders can always transact.
• Real estate contracts guarantee that people can always verify and transfer property ownership.

A smart contract is an application where code becomes law.

Steve Jobs called the computer “a bicycle for the mind.” Smart contracts guarantee that the wheels never fall off.

---

Ethereum Smart Contracts: Tip of the Iceberg

“Crypto is not just about trading tokens, it’s part of a broader ethos of protecting freedom and privacy and keeping power in the hands of the little guy.” - Vitalik Buterin

Although Ethereum smart contracts introduced a whole new world of decentralized products, fundamental limitations in their design and data manipulation capabilities prevent them from being effective in many applications beyond cryptocurrency.

In Solidity (a programming language for Ethereum), contract data is stored in key-value pairs. Although structs and mappings help organize data, all data is only retrievable by its key. Consider a theoretical contract for storing user identity data:

contract IdentityStorage {
   // Struct to store KYC details
   struct identity {
       string fullName;
       string dateOfBirth;
       string residentialAddress;
   }

   // mapping a country to its citizens to their info
   // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...}
   mapping(string => mapping(address => identity)) public idData;

   //...rest of contract
}

In this contract, a user’s identity record can only be retrieved by knowing the User’s country and wallet address. Unless the contract deployer redesigns the smart contract to have high-gas cost data manipulation, there are no other ways for the contract user to retrieve an identity record. Storing data in key-value pairs ultimately limits how the data can be accessed and manipulated.

---

In particular, Ethereum smart contracts face two fundamental problems:

• Index Dependence
• Access Path Dependence

---

Index Dependence

Index dependence means that to access a specific piece of data, it must be available in an index.

In the example KYC contract, records are only accessible through the exact Ethereum address used for the key.

This rigid indexing structure prevents users from querying data based on other criteria, such as:

• “Which users have this residential address?”
• “What percentage of users with this national ID were born after January 1, 1970?”

Without this flexibility, developers lack the tools to aggregate, analyze, and build logic around contract data.

---

Access Path Dependence

Access path dependence refers to data being accessible and understandable only through a specific retrieval path.

In the example contract:

• Knowing Vitalik’s country and wallet address allows retrieval of his identity record.
• Knowing only the wallet address does not allow the developer to get his country of origin.

This means data is only meaningful in one direction, limiting the ability to interpret data from different perspectives.

---

Index and access path dependence are significant challenges for apps requiring complex or evolving data models.

While ERC20 tokens work due to simple structures, these limitations become problematic for data-intensive applications.

---

A Brief History Lesson: The Relational Model

“History doesn’t repeat itself, but it often rhymes” – Mark Twain

In 1970, Edgar F. Codd published a paper proposing a relational database over the then-dominant hierarchical database model.

Codd identified three key problems with the hierarchical system:

• Ordering Dependence
• Index Dependence
• Access Path Dependence

Does this sound familiar?

Ethereum smart contracts do not have ordering dependence, but they do suffer from the same index and access path limitations as the hierarchical databases of the 60s and 70s.

These constraints:

• Limit developer flexibility
• Constrain application types
• Increase maintenance burden

After relational databases emerged, the industry saw an explosion of:

• ERP systems
• CRMs
• Business intelligence tools
• E-commerce platforms
• Social media applications

The relational database was more than a paradigm shift; it was a category-creating platform.

Today, blockchain platforms resemble the limitations of early computing. Without capable data processing, we can’t build more sophisticated decentralized applications.

---

SQL Smart Contracts: A More Flexible Paradigm

“The measure of intelligence is the ability to change.” - Albert Einstein

Just as relational databases revolutionized software, integrating them into blockchains has the same potential to reshape decentralized applications.

At TRUF.NETWORK, we are building a blockchain platform and smart contract language that:

• Allows developers to leverage SQL’s full expressivity
• Enables more data-intensive decentralized applications

Instead of key-value maps, TRUF.NETWORK lets you:

• Store identity records in tables
• Query them with flexible SQL syntax

Consider the same identity storage example from earlier. Rather than storing identity records in a map where each record is only accessible by its key, TRUF.NETWORK allows developers to store the records in a table and leverage a flexible SQL syntax to query over the table:

database user_registry;

table identities {
  address uuid primary key,
  name text notnull,
  date_of_birth int notnull,
  residential_address text notnull,
  national_id int notnull,
  #country_index index(national_id)
}

action query_by_national_id ($id) public view {
  SELECT * FROM identities WHERE national_id = $id;
}

action query_by_dob ($dob) public view {
  SELECT * FROM identities WHERE date_of_birth > $dob;
}

In the original Ethereum smart contract, there was no way to search through the identities and return all users given a condition (such as national ID) or to associate a wallet based on a specific attribute (such as a date of birth). To enable such functionality would require restructuring the contract to add costly, gas-intensive functions. However, with the relational model, developers can execute these queries without any restructuring required, thereby gaining more data manipulation flexibility without incurring additional costs.

For example, the idOS network is a sovereign blockchain built with TRUF.NETWORK, allowing users and dApps to store user credential information. Leveraging SQL over the idOS network enables:

• Users and dApps can store user credential info
• Users to be associated and retrievable by multiple wallets, credentials, and attributes.
• DeFi protocols to perform aggregate analyses of where their users are from.
• Stablecoin protocols to assess which users are from high-risk areas.

Enabling the relational model and SQL on a decentralized blockchain platform allows us to create fundamentally new applications that cannot exist on existing Ethereum smart contracts.

---

Conclusion

The relational model that revolutionized the computing industry 40 years ago has the same capabilities to revolutionize the blockchain industry today. In the 1960s and 1970s, index and access path dependence limited the hierarchical database’s usefulness in data-intensive applications. Today, the same index and access path dependence limit Ethereum smart contracts and their ability to power decentralized platforms with complex data models. However, by integrating the relational model into the blockchain and providing developers with the same expressive SQL dialect, we can unlock new types of applications.

Just as the relational database accelerated business demand and helped computers attain mainstream adoption, it may help blockchain platforms do the same, thereby unlocking a freer, more decentralized, more trustworthy digital world.