SALT: A Descriptive Model For Blockchain

Family-friendly main picture that I think everyone would feel rather… *sunglasses* … neutral… about.

I, personally, like to think of a blockchain as a database more than anything. Sure they’re a communication protocol, sure they have features of file share, but the file share and the information they communicate builds a database. Databases are described in two ways typically: ACID or BASE.

Today I was thinking to myself, “Self… are blockchains ACID or are they BASE?” Let’s take a look to see…

A Splash of ACID

How you feel when your database doesn’t have ACID-compliant transactions. Yup. That’s what that is a picture of. That’s my story and I’m sticking to it.

ACID databases transaction tend to follow your more SQL-like systems and has the following properties:

  • Atomicity — Ether the entire transaction succeeds or the entire transaction fails… no partial credit.
  • Consistency — The same transaction will always produce the same results in the system… no uncertainty.
  • Isolation — Transactions which occur concurrently will produces the same results if they were run sequentially… no interference or interruptions.
  • Durability — Once a transaction executes, it stays executed… even if the power goes down on the system.

A lot of these properties seem to be enforced in blockchain systems, but are they? Blockchains are known for their immutability of record, so long as there are sufficient honest peers to share that record, so they seem fairly durable… except consensus can overrule the record like it did after the DAO hack. Atomicity tends to be true, but does it do so consistently? None of these transactions on a blockchain really occur in isolation of each other and if multiple happen at the same time, which may produce a contradiction, do they fail? Can they succeed but interfere with each other?

That last part, in particular, is really interesting to me. Dive further and think about Ethereum smart contracts. They have their own state, which they maintain, and they can execute many times in the same block. Say you get 40 transactions sent to a smart contract in the same block… what is the order these transaction occur? The answer is… the winning miner chooses the order! From an ACID standpoint this is a major no-no. Depending on your contract, you may not be ACID compliant. In fact, the entire blockchain itself isn’t ACID compliant until the winning miner tells everyone what to do. There’s no deterministic method to commit data, there’s only consensus on what the data should look like.

This is what’s known as “Eventual Consistency” which made me go, “Hmmm, maybe blockchains are BASE.”

Is Blockchain BASEic, Bro?

I wish Jonah Hill would give me five in a similar manner for the title I just wrote.

BASE is an acronym used largely in reference to Big Data systems which store information in a distributed manner. It stands for:

  • Basically Available —Responsibility for the data is shared, so if a single node becomes unavailable, the entire system doesn’t fail, just the data only contained on that one node.
  • Soft state — Data has the ability to expire or be archived if it’s old and unused.
  • Eventual consistency — Over time, all data will update across all nodes in the system.

This seems closer defining a blockchain at a glance, doesn’t it? Only at a glance, though.

Looking further, there’s flaws. There’s no “Basically” about the availability of the blockchain. It’s available. You have it. I have it. Everyone has it. It isn’t soft state, it’s quite the opposite… it’s immutable. It’s not even eventually consistent! Even though once a longest chain is determined, a blockchain is still immediately adding totally and completely verifiable blocks to the network. Sure, you need to wait for confirmations in certain designs, but that’s not a required restriction. Yet, even with all that, it’s a probabilistic finality, not true consistency in the most… ahem… BASEic sense of the term.

So I dug in further… what is a good model for defining the blockchain? It’s not an ACID database. It’s not a BASE database. It has some loose features of both, but not in any perfect sense. What do you get when you mix ACID with BASE?

That’s when my search results turned up a really clever-sounding proposed model for defining decentralized database solutions like blockchains.

SALT: The Best Marketing-Acronym Ever

I swear this has to be a case of coming up with the acronym first and the paper second.

My research (read: Google searches) on the subject yielded a paper entitled, “Not ACID, not BASE, but SALT: A Transaction Processing Perspective on Blockchains“ by Stefan Tai, Jacob Eberhardt and Markus Klems of Technische Universität Berlin. A video on the paper can be found here.

In this paper, there is a proposed alternative to ACID and BASE that describes a decentralized storage system such as blockchain. It’s called SALT. For those of you who remember your chemistry classes, when you mix an “acid” with a “base” you get a “salt”. So, is this is a clever marketing term?

Well, no… it actually does a pretty decent job describing decentralized databases. SALT has two contexts: Transactional and Systemic. In a transactional sense, SALT means:

  • Sequential — Transactions occur in some sequential ordering… though that may be determined by the winning miner in some blockchains.
  • Agreed — There is a consensus on what is to transpire to produce a common state… which may require a leader election or a winner such as in Proof of Work systems.
  • Ledgered — All evidence of transactions are maintained in a historical ledger of events… which allows the current state to be verified as correct.
  • Tamper-resistant — A significant plurality is required to alter committed transactions… often called immutability but that’s a misnomer.

That makes perfect sense to me, and I can see how every shared decentralized database would require these features in some fashion.

In the systems context, SALT stands for:

  • Symmetric —Every node is empowered to validate their data (I modified this a bit from their paper because they assume public consensus networks but this can be abstracted to private chains that do not have symmetric responsibility of nodes).
  • Admin-free — I prefer the term ‘autonomous’, but it means there’s a self-governance to the system and no one node can change the system on its own.
  • Ledgered — All peers maintain a ledgered system of the data and have rules for negotiating the addition of blocks onto the ledger.
  • Time-consensual — There is a defined expectation of approximate block creation times.

Bit more of a stretch, but not as bad as what you see with BASE.

So How Does This Play Out In Reality?

It doesn’t. I just saw the paper and thought this would be a cool article to write.


Kind of.

If you know what a blockchain is and firmly grasp the fundamental concepts behind it already, SALT doesn’t really help you much. Right now the only databases which are SALTy use blockchain as the model. Maybe in the future there will be some SALTy systems that do not adhere to the same probabilistic finality of block generation. That would require another paradigm of consensus algorithms, but right now I think this is what we’re working with, and SALT explains is fairly well.

Really, these acronyms… ACID….BASE…SALT… they’re teaching tools. In what context do people use ACID on a daily basis? Almost never, right? BASE? Come on, that barely is a real acronym. SALT is the same way, really. It’s perfect for pedagogy as it helps people being introduced to the concepts to understand and memorize them for future recognition. As a method of evaluating and measuring a system… ehhh… not terrible useful.

Either way it makes a pretty decent article.

I hope this helps someone!

Avalanche is pretty cool.