"Eine Blockchain ist eine dezentrale Datenbank" - das ist eine gängige Definition, die man häufig hört. Wer sich mit Datenbanken beschäftigt, weiß aber, dass "Verteilung" nicht notwendigerweise von "dezentralem Konsens" abhängt - Replikation, Raft und eventgetriebene Datenmodelle lassen sich auch mit Kafka, Cockroach oder Cassandra realisieren. Die Frage ist also: Was ist an der Blockchain so speziell verglichen mit einem verteilten Datenbank-System? Was haben Kryptografie, Hashing, Merkle Trees, PoW, PoS und inzentivierter Konsens damit zu tun? Oder noch fundamentaler gefragt: Was *ist* eigentlich eine Datenbank?

1. Was ist eine Datenbank &
was hat Blockchain damit zu tun?
Meetup #30

2. Was ist eine Datenbank &
was hat Blockchain damit zu tun?
Stefan Adolf Nhan Vu Krystian Gaus

10. Agenda
1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

11. 1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

12. Was sind “Daten”
Informationen, die den Zustand eines Systems bestimmen
● Strukturiert
● Abfragbar
● Erweiterbar
● Veränderlich
● (Relational)

13. Was ist eine Datenbank?
A database is an organized collection of data, generally stored and
accessed electronically from a computer system. Where databases
are more complex they are often developed using formal design and
modeling techniques.

14. Eine kleine Datenbankgeschichte
1960: Navigations- / Hierarchische Datenbanken (b-trees, linked lists)
CODASYL, IBM IMS (Apollo), IBM System R
Identität = Position auf dem Speicherband
jeder Datensatz kann jeden anderen Datensatz verlinken
worst case: man muss alle Daten einer Entität lesen, um eine Information zu finden
1970: relationale Datenbanken
(IBM / Edgar Codd): in CODASYL kann man nicht suchen!
flexible Links zwischen Daten-Entitäten, Definitionen der Entitätsstruktur
Tabelle -> Zeile -> Spalte bzw. Relation -> Tupel -> Domäne
Identität = Primärschlüssel einer Relation
1978/79: SQL -> IBM DB/2, Larry Ellison’s Oracle, INGRES (Postgres)
Entity-Relationships
1980 Desktop-Datenbanken dBASE, Access
1990 Objektrelationale Datenbanken
SQL-Erweiterungen, ORM, Inheritance und Diskriminierung
2000 NoSQL / NewSQL
XML: Traversierung / Queries auf Entitäts-Dokumenten
NoSQL: Daten-Denormalisierung = horizontale Skalierbarkeit
NewSQL: NoSQL mit SQL und ACID
Graph-Datenbanken

15. DBMS
System, das 3 Konzepte der Datenspeicherung kombiniert
- Externe APIs: wie greifen Endnutzer auf Daten zu?
- “SQL”, “MS Access”, MongoDB API
- Konzeptionell: wie definiert sich der “globale” Zustand aller Daten in dem System?
- “WiredTiger”, “MyISAM”, “Binlog”
- Intern: wie sind die Daten physisch in dem System organisiert?
- Index-Tabellen, Materialisierte Views, Sharding
Separating the external, conceptual and internal levels was a major feature of the
relational database model implementations that dominate 21st century databases.

16. Stefan, was ist eine Datenbank?
Ein System, mit dem man aus alten Informationen neue Information macht und
das dafür sorgt, dass man sich als Anwender keine Gedanken über die
Funktionalität des Managements machen muss.

17. 1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

18. Konsistenz & Integrität
- Aus dem DBMS geht der aktuelle Zustand des Systems hervor
- Konsistenz ist die Konsequenz der Ausführung von Operationen auf Daten
- ACID-Transaktionalität
- Atomicity: Alle Operationen einer Transaktion können nur gemeinsam ausgeführt werden
- Consistency: Transaktionen müssen gegen Modell-Constraints validieren
- Isolation: Gleichzeitige Transaktionen führen zum selben Ergebnis als würden sie
nacheinander ausgeführt (-> gefühlte concurrency / internes ordering)
- Durability: eine atomische Transaktionen gilt erst als ausgeführt, wenn sie auf der Platte steht

19. Skalierbarkeit & Verteilung
“zentrale” ACID-DBMS lassen sich horizontal skalieren
Sie werden dann nur langsamer
Trennung von “schreibenden” und “lesenden” Zugriffen
“Master”-”Slave” Replikation (bzw Leaders -> Followers / Primary -> Replica)
geteilte Transaktionslogs
Für Geschwindigkeit: BASE <-> ACID
- Basically Available
- Soft state
- Eventually consistent

20. Das CAP Theorem: wähle 2.
Consistency: Jeder Lesezugriff erhält den
selben, zuletzt geschriebenen Zustand
Availability: Jede Anfrage wird unverzüglich
beantwortet, ohne zu garantieren, dass sie dem
letzten Write entspricht
Partition tolerance: Das System funktioniert
weiter, auch wenn Informationen noch nicht bei
allen Beteiligten angekommen sind.
Verteilung
Response-Zeit
Garantierte Aktualität

21. 1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

22. Eventlogs
Jeder Write wird als Log-Item auf die Platte
geschrieben
Anschließend wird der Zustand verändert
“Tabellen” und “Indizes” sind nur eine Projektion der
Änderungshistorie.
=> Das Eventlog ist die ursprünglichste
Repräsentation des aktuellen Datenbankzustands.
Eventlogs sind Implementierungsdetails aller
verteilten DBMS
PostgreSQL transaction log

23. State Machines
Wenn zwei identische deterministische Prozesse den
gleichen Zustand haben und “Eingaben” in derselben
Reihenfolge erhalten, erzeugen sie identische
Ausgaben und befinden sich anschließend im selben
Zustand.
- Die Eingaben müssen für jede State Machine in derselben Reihenfolge stehen.
- Der Zustand einer Instanz lässt sich über den “höchsten” Log-Eintrag
beschreiben

24. Dualismus: Event Log <-> Tabellen
Tabellen: “Ruhe”-Daten <-> Logs: Daten-”Veränderungen”
Tabelle == Anwendung des vollständigen Logs in der “korrekten” Reihenfolge
Event-Log == “Backup” jedes vergangenen Tabellenzustands
Analogie zu VCS/Git:
- patches / commits: Atomische Sammlung von Zustandsänderungen
- branches: Snapshots von angewendeten Patches
- concurrency: Man kann Patches in beliebiger Reihenfolge applizieren

25. Es gibt keine gemeinsame Uhrzeit
In verteilten Systemen kann “Zustand” davon abhängen, wen man wann fragt.
there is no shared clock according to which we can decide ordering
- Einstein.
- Ein Ereignis hat erst stattgefunden, wenn wir es wahrnehmen können
- Netzwerklatenz
- Gleichzeitigkeit
- Nachlässigkeit
- Betrug
“Logische” (Counter) vs. “physische” (Timestamp) Uhren

26. Konsens für Log-getriebene State Machines
Log-Writes bewirken replizierte Statusänderungen
Nodes benötigen Konsens über die Reihenfolge
eingehender Logs
-> Paxos / Raft (asymmetrischer Konsens)
- Quorum-basiert: alle Teilnehmer “kennen” sich
- Alle Teilnehmer halten sich an die Regeln
- Leadership Elections (“Master” fällt aus)
- Leader Heartbeat
- Candidate Mode
https://www.youtube.com/watch?v=JEpsBg0AO6o
https://www.youtube.com/watch?v=YbZ3zDzDnrw
https://medium.com/@spsingh559/detail-analysis-of-raft-its-implementation
-in-hyperledger-fabric-d269367a79c0

27. 1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

28. Dezentral > Distributed
- Niemand kennt alle Teilnehmer / jeder kann Teilnehmer werden
- Teilnehmer können absichtlich gegen die Regeln spielen
- Keine Autorität kontrolliert das Netzwerk
- => Unautorisierte Multi-Master-Replikation
- mehrere Zustände existieren gleichzeitig
- globaler Konsens führt zu einem
temporär finalen Systemzustand

29. Dezentral & Konsenslos
OrbitDB
IPFS als Storage Layer
IPFS Pubsub für Sync / Replikation
CRDTs für konfliktfreie Daten-Merges
Ceramic Documents
Unveränderliche Dokument-IDs
Change Records
IPFS Pubsub-Notifications
Blockchain Anchor-Documents (Batch Proofs)

30. Byzantine Fault Tolerance
BFT (symmetrischer Konsens)
- Mehrheit aller Nodes entscheidet über
die Ordnung des Event-Logs
- z.B. Tendermint (BFT) -> Cosmos (PoS)
- Kann ⅓ byzantinische Nodes korrigieren
- Inzentivierung korrekten Verhaltens
- Block Awards, Transaktionsgebühren
- Bzw. starke Disinzentivierung
fehlerhaften Verhaltens
- PoW / PoS-Slashing

31. Bitcoin: UTXOs
- Unspent Transaction Outputs
- Bitcoin speichert keinen Zustand
(“Kontostand”) eines Accounts
- Nutzer speichern die private keys von
offenen UTXOs in ihren Wallets
- Jede Transaktion erzeugt eine neue UTXO
== “Geld”, das ein Nutzer noch ausgeben
kann
=> “Bitcoin ist keine Datenbank”

32. Ethereum
- Transaktionsgetriebene State Machine
- ∑ Transaktionen = “World” State
- Transaction Trie
- Transaktionen eines Blocks
- permanent
- Root -> Block Header
- Globaler State Trie
- Account => {nonce, balance, storageRoot, codeHash}
- ephemeral
- Storage Trie
- Contract data pro Account
- Root -> globaler State trie
There is one, and one only, global state trie in Ethereum.

33. Ist eine Blockchain eine Datenbank?
● Eine Blockchain ist ein verteilter BFT-Konsensmechanismus zur Ordnung von
Transaktionen
● Nacheinander ausgeführt führen die Transaktionen zu einem Systemstatus
● Der aktuelle Status wird in der Regel neben den Transaktionen geführt
= eine Blockchain ist keine Datenbank im eigentlichen Sinne…
… aber sie lässt sich (fast) wie eine Datenbank benutzen ;)

34. 1. Was sind Daten?
2. Zentralisierte Datenbanken
3. Verteilte Datenbanken
4. Dezentralisierung
5. Wie geht es weiter?

35. Sharding
SSI
DeFiEthereum 2.0
Off-Chain workers
Skalierung
Oracles
Ethereum-Bridges
2nd Layer Solutions
Non-Fungible Tokens
Directed Acyclic Graphs
Interoperability Proof of X
Tokenisierung
Crypto Games