Wie ich in einem früheren Post berichtet habe, hat Blockstack mit einer dezentralen ID und dem passenden Umfeld an Daps und Services ein eigenes und umfangreiches Universum aufgebaut.
In diesem Video gebe ich einen Überblick über die Funktion und die daraus entstehenden Möglichkeiten von Blockstack.
Wie viele andere Blockchainanwendungen kämpft auch Blockstack mit einem Problem, welches gar nicht so einfach zu lösen ist. Die Qualität der Daten.
Eine D.ID ( dezentrale Identität) auf Blockstack ist eine sehr schöne Sache, da ich zum Einen Herr über meine Daten bin und zum Anderen nicht auf jeder Dapp einen neuen Account eröffnen muss, sondern einfach mit meiner Blockstack ID arbeite.
Das ist super, für z.B. Filetransfer über Blackhole oder zum hochladen der eigenen Webseite auf Runkod und vielen anderen tollen Anwendungen.
Doch wie sieht es aus, wenn ich zum Beispiel einen Vertrag auf Blockusign unterschreiben möchte?
Solange sich die Vertragspartner kennen und der Vertrag nur als Backup auf der Blockchain gespeichert wird ist alles kein Problem. Doch was ist, wenn ich meinen Vertragspartner nicht kenne? Wie kann ich oder auch der Vertragspartner sicher sein, dass ich eben ich bin und der Vertragspartner eben der richtige Vertragspartner.
Ähnliche Probleme haben auch Anwendungen wie zum Beispiel Supply Chain ( Lieferketten) Anwendungen. Wer verifiziert, dass der Kaffee aus Afrika auch wirklich Bio ist oder ob es echter Arabica oder eine andere Sorte ist. Bei Versicherungen tritt das selbe Problem auf. Wer verifiziert den zu versichernden Wagen als „ Neuwagenzustand“, vielleicht sieht der Wagen von aussen ja perfekt aus aber unter dem Blech ist es eine Ruine.
Wir sehen, dass das ein ziemliches Problem ist und die Lösung nicht gerade einfach erscheint. Das Problem muss aber gelöst werden, da davon die Massenadaption abhängt.
Man könnte nun einwenden, dass das Problem ganz einfach über einen zentrale Anbieter gelöst werden kann. Im Falle der D.ID auf Blockstack könnte eine Firma die Personendaten anfordern und sie verifizieren, ähnlich einem KYC ( know your Customer) Verfahren bei Bitcoinbörsen und Banken. Im Falle des Kaffees geht einfach ein Kontrolleur der Firma XY zum Bauern und kontrolliert die Ware und die Eingabe der Daten. Klingt einfach, bringt aber nichts, denn genau das wollen wir ja vermeiden. Wir wollen keinen single Point of failure wo alle Daten zusammen laufen und Manipulationen Tür und Tor geöffnet werden. Genau so läuft es Heute und genau das muss sich ändern um eine wirklich dezentrale Struktur zu etablieren.
Bei einer Blockstack ID besteht die Möglichkeit einen Twitter Account zu verlinken um eine Social Proof zu erreichen. Nur haben wir da dass Problem, dass ein Twitter Account relativ leicht gefaked werden kann ( wie viele Brad Pitts tummeln sich auf Twitter ?).
Den Ansatz finde ich an sich gut, er müsste nur auf mehrere Plattformen ausgedehnt werden. Im Idealfall sollte auch YouTube, LBRY oder Bitchute mit eingebunden werden, so könnte man zumindest eine lebende Person, nämlich den Contentcreator, verifizieren. Wenn zu einem solchen Kanal noch die Webseite des Contentcreators hinzu gefügt wird hätte man über das Impressum noch eine weitere Möglichkeit die Person zu verifizieren.
Bevor jetzt jemand in Panik betreffend des Datenschutzes ausbricht. Ich kann mehrere D.ID auf Blockstack einrichten. Also wenn ich nur ein grösseres File versenden möchte reicht die ID mit Namen ( der auch gefaked sein kann) und eine E- Mail Adresse völlig aus.
Wenn ich aber einen rechtsgültigen Vertrag unterzeichnen möchte verwende ich eben die ID die möglichst alle nötigen Daten enthält und mit möglichst vielen Plattformen verlinkt ist, damit sich mein Vertragspartner, zumindest halbwegs sicher sein kann, dass ich auch wirklich ich bin.
Natürlich würde eine solche D.ID nicht von staatlichen Institutionen anerkannt werden aber für Bestellungen beim Onlinehändler oder beim Buchen eines Hotels sollte eine solche D.ID eigentlich ausreichen.
Weit schwieriger wird die Aufgabe, wenn in der realen Welt Daten verifiziert werden sollen. Einen Ansatz bieten dabei die sogenannten Orakel. Orakel sind Personen oder Institutionen welche die Echtheit der Angaben überprüfen. Die Überprüfung findet aber nicht nur durch ein Orakel statt sondern durch mehrere und keines der Orakel weiss ob nun seine Überprüfung Anwendung findet oder die eines oder mehrerer anderer Orakel. Die Verifizierung über Orakel kommt aus der Spieltheorie und setzt die Rahmenbedingungen so, dass es für die einzelnen Orakel keinen Sinn ergibt zu betrügen. So kann zu einem sehr hohen Mass garantiert werden, dass die Daten stimmen. Weiters wird durch dieses System der single Point of failure eliminiert.
Auf der digitalen Seite arbeitet Chainlink mit solchen Orakeln. Chainlink bietet die Möglichkeit Daten für Smartcontracts mithilfe von Orakeln, im digitalen Bereich, von Servern und/ oder Notes zu verifizieren. Chainlink greift nicht nur auf eine Datenbank zu, dass wäre wieder ein SPOF ( single Point of failure) sondern auf mehrere und kann daher auch eine sehr hohe Qualität der verwendeten Daten garantieren.
Nachfolgend findet Ihr noch ein paar Links zu den diversen Themen. Was die Spieltheorie betrifft, so habe ich mich in den letzten Wochen etwas intensiver damit beschäftigt ( macht am Anfang ziemliche Knoten ins Hirn :-)) und sehr spannende Ansätze gefunden wie man Situationen bei der Interaktionen mit anderen Personen bewerten kann. Die Spieltheorie findet überall dort Anwendung wo zwei oder mehr Parteien miteinander interagieren. ( Verhandlungen, Poker, Politik......... )
In diesem Sinne
Tschüss Euch
