---
# System prepended metadata

title: One graph to introduce the mutation of the db3 network

---

# One graph to introduce the mutation of the db3 network

![](https://i.imgur.com/4gr0you.jpg)



### The core flow 

1. Pack all operations as a mutation
2. Send the mutation to mempool
3. The validators proposal a new block to pack all mutations
4. The node send all mutations to state machine and return the root hash
5. The validators validate the root hash


### Concepts

What is the **mutation**? all modifications to db3 network are called **mutation**


1. `Create Database` , this operation will produce a unique address like `0x84b0bd55e7ad979b7cb92a56f561190de8f68403`
2. `Create Collection`, this operation will create a collection with name
3. `Document CURD`
4. `Mint Credits`



### **[db3 network](https://github.com/dbpunk-labs/db3/)**

DB3 Network is an open-source and decentralized firebase firestore alternative for building fully decentralized dApps quickly with minimal engineering effort.

At present, there are still some problems in the whole design that need to be solved

1. Mempool cannot store a large amount of data. Broadcasting between a large number of nodes will consume a large amount of bandwidth. At present, some ideas are to separate the metadata from the data itself. The broadcast is the metadata itself, and the validator that produces the block goes to the data node to fetch the data.
1. Merkdb is currently an AVL tree based on rocksdb. Although it can easily produce merkle proof and has good query efficiency, when the amount of data is large, the avl data structure is not friendly to the file system compared to b+ tree

We also plan to optimize these issues in subsequent optimization iterations, and will pay more attention to the integrity and usability of the entire product at present.