- Oracle, MySQL
- carry data: rational (excel), document (mongo), object (??)
- Managable data: mutable, editable, deletable, appendable
- distributed via master -> slave (proxy) concept
- "centralized" database "management"
(- blockchain, read-only filesystems(?))
- carry data: any
- Managable data: append ONLY, no edits, not deletes => immutable
- distributed
- master -> slave
- (global, or local) P2P network or
- distributed vs. non-distributed
- database management:
- centralized vs. decentralized
- private vs. public
Similarity to book keeping(!) with new pages every X seconds/minutes (writing on the backside of the previous page (?))
- New booking entries arrive at the book keeper
- book keeper adds them to his current page of entries
- every now and then, the book keeper changes to the "next page" and by this "commits" to the previous entries
- every new page carriers a date time
Blockchain tech:
- the data to be inserted is formatted properly
- data to be submitted/committed is organized as 'operations'
- several operations can be grouped together into a single 'transaction'
- several transactions are grouped into a set of "database commits" (i.e. a "block")
- new blocks get "applied" (read: committed) "occasionally"
- the new block carries the hash of the content of the previous block as reference
- Participants verify operations/transactions/commits and linking of each blocks
Definition: A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values returned by a hash function are called hash values, hash codes, hash sums, or simply hashes.
HASH(arbitrary-data) -> randomly looking shorter hash
- Determinism (always same hash for same data)
- Uniformity (Uniform mapping)
- Data normalization (data format normalization)
- Continuity (Not useful here)
- Non-invertible (cannot reverse the process (processing theorem)
- digit sum
- two-letter country codes
- MD5
- SHA1
- SHA256
- ...
- Develop our own blockchain in python
- blocks are json objects:
{
"previous_id": <>,
"timestamp": <>,
"data_hash": <>,
"commits": {...},
}
- data is a json object, the hash is from the stringified/serialized json
[
{
"key" : <>,
"value" : <>,
}
]
- indexing the blockchains key/value pairs in a local json object
- rescan/re-apply/reindex blocks
Note:
Why Bitcoin uses a merkle tree?
If they were stored sequentially, you'd need all transactions to verify that any single one belongs to a given block. With a merkle tree, you only need to provide the transaction and the merkle branch to prove that this transaction in fact appears in this block.