# A Survey of Ledger Technology-Based Databases
## 4 Permissioned Blockchain Based Databases
### BlockchainDB  
In a unique way, BlockchainDB [46] uses classical data management techniques, which consist of data sharing. The primary notion behind BlockchainDB is the use of blockchains as a storage layer as well as implementing a database layer on top. Thus, the native storage layer can be an existing blockchain technology, which can be then used as decentralised storage. With the assistance of the database layer, shared tables can be accessed. As a result of this architectural choice, a possibility is ensured that nodes do not store all data in the blockchain network locally. Due to the sharding, an arbitrary number of peers store the shards. This intention is observable in the architectural features of and changes to Ethereum 2.0 [47] and Rapidchain [48]. The use of data sharing does not negatively impact security or the aforementioned basic principles of blockchain.  
The participating nodes in a BlockchainDB network can be full peer or thin peer. Thin peer does not store any shards; thus, it can take part in a blockchain network with limited resources and use the shared table, while the full peers manage databases and store at least one shard replica. Clients must trust in their own BlockchainDB peers. They can request transactions through a limited put-get interface. This key-value interface can be used to read and write data without knowledge of the blockchain technology. Moreover, clients can verify the methods of database layers through the use of off-chain verification. As has been mentioned, the architecture of BlockchainDB can be split into two layers. The aforementioned key-value interface is used by the database layer, while the storage layer stores all data built on blockchains.  
**Database Layer:** The database layer within BlockchainDB is found on top of the storage layer. It serves the clients through the aforementioned put-get interface. With the assistance of the Shard Manager, the necessary shard of a given table is found. Depending on the definition of the partitioning scheme and the replication scheme, the sought after shard can be in either local storage or remotely in another peer's storage. Alongside the Shard Manager, a Transaction Manager assists in the maintenance of consistency levels and defines the behaviour for concurrent transactions.  
Figure 5: Whatever-Ledger Consensus transaction processing model.  
**Storage Layer:** The storage layer is built on an existing blockchain technology, the backend of BlockchainDB. Its task is the storage of all data, which interacts with the BlockchainDB. Furthermore, it is responsible for the creation of shards and providing access for shards through the mentioned well-defined interface. The creation of shards is based on the key value data model. The interfaces are independent from the blockchain technology, as BlockchainDB uses them through backend connectors. The backend connectors ensure a stable, predefined interface for the management of data via the smart contracts. These smart contracts need to be installed in BlockchainDB to use their basic read/write functions. There is a possibility to process data simultaneously, across different blockchains, wherein various blockchains are various shards. These blockchain technologies can be Ethereum or Hyperledger Fabric, for example.