How does a blockchain system like a database?

A blockchain smart contract only read committed, cannot read-uncommitted. ^[1]

A blockchain is a shared append-only distributed database with full replication.

ACID: Atomicity, Consistency, Isolation, and Durability

A smart contract is like an interface to operate the blockchain. (A blockchain can be set up in a way that does not allow direct interaction, i.e., sending money directly to someone)

In this sense, a smart contract is a transaction interface in DBMS.

Dirty read: No. A smart contract only reads data on chain.

Non-Repeatable Reads, and Read Skew: No. In a single execution of a transaction method, the miner will not synchronize its local blockchain copy with the global one. Smart contracts do not execute concurrently either on one miner.

Phantom Reads: No.

Write Skew: No. In Hyperledger Fabric, when a smart contract finishes its execution on a miner, an orderer will check the read-write set of the smart contract.

To sum up, the isolation level of a blockchain platform is snapshot.^[2]

Durability

In blockchain, it is the majority of the network who determines the validity of blocks. It is possible that a block is added to the chain but later is deemed invalid.

Therefore blockchain transaction is not durable in spite of the extremely low probability.

A blockchain transaction is either committed or rolled back. (How about an external transaction call?)

BASE: Basically Available, Soft state, Eventually consistent.

A smart contract can be viewed as a stored procedure on a database system.

However, blockchain networks usually have a defined block time, e.g., 10 minutes for Bitcoin. Thus, a single execution of a smart contract cannot exceed 10 minutes; otherwise the mining node is unable to give a block in the block time.

On the other hand, a stored procedure can run for longer time as long as not infinite.

Why can’t we delete smart contracts?

Because full nodes will not be able to confirm the old blocks. If a smart contract is deleted, a full node runs a smart contract proposal, and the result will be different from the one at the earlier time. Then the full node will re-calculate a SHA and publish it. The same skewness happens when a smart contract involves unstable or non-deterministic external API calls.

In systems supporting BASE, replicas can be in conflicting state because they each process a different set of transactions. The same can happen in systems supporting SALT, when two nodes
mine different blocks and hence temporarily maintain different state.

Then how do BASE converge from diverted states?

参考资料

1. Victor Cook; . Read-Uncommitted Transactions for Smart Contract Performance. IEEE International Conference on Distributed Computing Systems. 2019, (): [].↑
2. Nader Medhat. Understanding Database Isolation Levels. . 2021-03-21 [2022-08-18].↑