paint-brush
Erweiterung von Smart Contracts mit SQLvon@kwilteam
Neue Geschichte

Erweiterung von Smart Contracts mit SQL

von Kwil9m2024/10/08
Read on Terminal Reader

Zu lang; Lesen

Aktuelle Blockchain-Plattformen wie Ethereum haben aufgrund der starren Schlüssel-Wert-Speicherung Einschränkungen bei der Verarbeitung komplexer Daten, was fortgeschrittene Anwendungen behindert. SQL Smart Contracts bieten Flexibilität, sodass Entwickler dynamische Abfragen durchführen und komplexe Datenmodelle effizient in einem dezentralen Netzwerk verwalten können. SQL Smart Contracts erschließen das Potenzial für leistungsfähigere dezentrale Apps und revolutionieren die Blockchain über Kryptowährungen hinaus.
featured image - Erweiterung von Smart Contracts mit SQL
Kwil HackerNoon profile picture
0-item
1-item
2-item

Besonderer Dank geht an Jun Jiang von DePHY Network und Ryan Soury von Usher Labs für Feedback und Einblicke.


Im Jahr 2008 schrillten an der Wall Street die Alarmglocken, als erfahrene Händler in einen Urrausch verfielen. Überschuldete Finanzinstitute brachen unter der Last von Hypothekenpapieren mit niedriger Bonität zusammen und ließen gierige Banker schutzlos zurück, die um Rettungspakete betteln mussten. Die Zentralbanken, die verzweifelt versuchten, ihre Macht zu behalten, bezahlten die Sünden der Banker aus dem Scheckbuch des einfachen Mannes. Dieser Verrat legte die Mängel des zentralisierten Währungssystems offen und machte deutlich, dass ein neueres, freieres und gerechteres Finanzsystem erforderlich war. So wie die amerikanische Revolution und die darauf folgende Verfassung Kirche und Staat trennten, entstand eine neue Revolution namens Bitcoin, die Geld und Staat trennte und viele der gleichen Freiheiten und Rechte ermöglichte, die für die Selbstbestimmung grundlegend sind.


Blockchain-Technologie ist Freiheitstechnologie. Sie ermöglicht uns den Aufbau von Finanz-, Identitäts-, Informations- und sozialen Koordinationssystemen, die kein Vertrauen in einen zentralen Vermittler erfordern. Individuelle Freiheiten gedeihen in einer Welt, in der die Zentralbank nicht den Geldfluss kontrolliert, eine einzelne Plattform nicht den sozialen Diskurs kontrolliert und ein einzelnes Unternehmen nicht die digitalen Identitäten kontrolliert.


Viele der Unterschiede zwischen dieser neuen Welt und unserer heutigen Welt liegen in den technischen Möglichkeiten der Blockchain-Plattformen. Die erste Generation von Smart Contracts war die Spitze des Eisbergs, der diese Freiheitssysteme ermöglichte; ihre Möglichkeiten sind jedoch grundsätzlich begrenzt. In diesem Artikel erkläre ich einige der kritischen Einschränkungen aktueller Smart Contracts und wie ein neues System, „SQL Smart Contracts“, eine technisch leistungsfähigere Grundlage bietet, um menschliche Freiheiten freizusetzen und das Potenzial der Blockchain als neue Computerplattform auszuschöpfen.

Smart Contracts: Die Wahrheitsmaschine programmieren

„Das Grundproblem … ist das ganze Vertrauen, das erforderlich ist, damit es funktioniert.“ – Satoshi Nakamoto


Die grundlegende Kerneigenschaft einer Blockchain ist ihre Unveränderlichkeit. Sobald eine bestimmte Anzahl von Beteiligten (oder „Knoten“) in einem Netzwerk der Meinung ist, dass etwas wahr ist, speichert die Blockchain eine dauerhafte Aufzeichnung dieser Wahrheit. Blockchains verwenden eine Vielzahl von „Beweismechanismen“, bei denen Knoten große Wertbeträge in Form von Rechenleistung, finanziellem Einsatz oder Reputation aufwenden, um sicherzustellen, dass böswillige Akteure die Wahrheit nicht manipulieren können.


Wenn Bitcoin die „Wahrheitsmaschine“ für digitale Währungen ist, dann ist Ethereum die „Wahrheitsmaschine“ für komplexere Finanzprodukte. Ethereum erweitert die Fähigkeiten von Bitcoin, indem es einen programmierbaren Designraum schafft, in dem Entwickler jede Logik implementieren können, die über eine Reihe von Knoten bereitgestellt, überprüft und ausgeführt werden kann. Das bedeutet, dass wir jetzt Systeme erstellen können, die das Vertrauen in eine zentrale Autorität überflüssig machen, die über die Währung hinausgeht! Jedes System, das zentrale Autoritäten erfordert – wie Kreditvergabe, Immobilienurkunden, Identitätsinformationen, soziale Medien, Wirtschaftskennzahlen usw. – kann jetzt ohne zentrale Vermittler funktionieren. Das ist eine völlig neue Welt!

Ein Smart Contract ist ein Programm, das Entwickler schreiben und auf einer Blockchain bereitstellen, der Leinwand, auf der Entwickler dezentrale Anwendungen erstellen. Der Begriff „Smart Contract“ bezeichnet keinen Rechtsvertrag, bei dem zwei Parteien an bestimmte Rechte und Pflichten gebunden sind. Stattdessen bedeutet ein „Smart Contract“ einfach, dass die Anwendung garantiert auf unbestimmte Zeit genau so funktioniert, wie der Code geschrieben ist. Kreditverträge garantieren, dass Kreditnehmer und Kreditgeber immer Transaktionen durchführen können. Immobilienverträge garantieren, dass Menschen das Eigentum an einer Immobilie immer überprüfen und übertragen können. Ein Smart Contract ist eine Anwendung, bei der Code zum Gesetz wird.


Steve Jobs bezeichnete den Computer als „Fahrrad für den Geist“. Intelligente Verträge garantieren, dass die Räder nie abfallen.


Ethereum Smart Contracts: Die Spitze des Eisbergs

„Bei Krypto geht es nicht nur um den Handel mit Token, es ist Teil eines umfassenderen Ethos, das darauf abzielt, Freiheit und Privatsphäre zu schützen und die Macht in den Händen des kleinen Mannes zu behalten.“ – Vitalik Buterin


Obwohl die Smart Contracts von Ethereum eine völlig neue Welt dezentralisierter Produkte einführten, verhindern grundlegende Einschränkungen in ihrem Design und ihren Möglichkeiten zur Datenmanipulation, dass sie für viele Anwendungen jenseits von Kryptowährungen effektiv sind.


In Solidity (einer Programmiersprache für Ethereum) werden Vertragsdaten in Schlüssel-Wert-Paaren gespeichert. Obwohl Strukturen (Variablengruppierungen) und Zuordnungen (Sammlungen von Schlüssel-Wert-Paaren) hilfreiche Möglichkeiten zur Organisation von Daten darstellen, sind alle Daten nur über ihren Schlüssel abrufbar. Betrachten Sie einen theoretischen Vertrag zum Speichern von Benutzeridentitätsdaten:


 contract IdentityStorage { // Struct to store KYC details struct identity { string fullName; string dateOfBirth; string residentialAddress; } // mapping a country to its citizens to their info // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...} mapping(string => mapping(address => identity)) public idData; //...rest of contract }


In diesem Vertrag kann der Identitätsdatensatz eines Benutzers nur abgerufen werden, wenn das Land und die Wallet-Adresse des Benutzers bekannt sind. Sofern der Vertragsanbieter den Smart Contract nicht so umgestaltet, dass er eine Datenmanipulation mit hohen Gaskosten ermöglicht, gibt es für den Vertragsbenutzer keine anderen Möglichkeiten, einen Identitätsdatensatz abzurufen. Das Speichern von Daten in Schlüssel-Wert-Paaren begrenzt letztendlich, wie auf die Daten zugegriffen und sie manipuliert werden können.


Insbesondere wirft die Datenverwaltung in Ethereum-Smart Contracts zwei grundlegende Probleme auf: Indexabhängigkeit und Zugriffspfadabhängigkeit.


Indexabhängigkeit

Indexabhängigkeit bedeutet, dass die Daten in einem Index verfügbar sein müssen, um auf sie zugreifen zu können. Ein Index ist eine Datenstruktur, die effizient nach einer eindeutigen Kennung innerhalb einer Sammlung sucht. Im obigen Beispiel eines KYC-Vertrags sind Datensätze nur über die genaue Ethereum-Adresse zugänglich, die für den Schlüssel verwendet wurde. Diese starre Indexierungsstruktur verhindert, dass Vertragsbenutzer die Daten anhand anderer Kriterien abfragen, wie etwa „Welche Benutzer haben diese Wohnadresse?“ oder „Wie viel Prozent der Benutzer mit dieser nationalen ID wurden nach dem 1. Januar 1970 geboren?“ Ohne die Möglichkeit, solche Abfragen durchzuführen, fehlt Entwicklern die Flexibilität, um Vertragsdaten zu aggregieren, zu analysieren und Anwendungslogik rund um sie herum zu erstellen. Wenn Entwickler diese zusätzliche Flexibilität benötigen, wie etwa das Abrufen eines Identitätsdatensatzes anhand des vollständigen Namens, muss der gesamte Vertrag neu strukturiert werden. In Ethereum kann die Umstrukturierung von Indizes auch die Gaskosten eines Vertrags erhöhen, was die Nutzbarkeit des Vertrags weiter beeinträchtigt.


Zugriffspfadabhängigkeit

Zugriffspfadabhängigkeit bedeutet, dass Daten nur über einen bestimmten Abrufpfad zugänglich und verständlich sind. Im Beispielvertrag könnte ein Entwickler, wenn er Vitaliks Land und Wallet-Adresse kennt, dessen Identitätsdatensatz abrufen. Kennt ein Entwickler jedoch nur die Wallet-Adresse, kann er Vitaliks Herkunftsland nicht ermitteln. Und selbst wenn der Entwickler Vitaliks Wallet-Adresse kennt, kann er seinen Identitätsdatensatz nicht abrufen, wenn er nicht auch das Herkunftsland (den „Kanada“-Schlüssel) kennt. Der Zugriffspfad zu Vitaliks Identitätsdatensatz ist festgelegt. Wenn ein Entwickler versuchen müsste, seinen Datensatz nur über die Wallet-Adresse abzurufen, müsste der gesamte Vertrag neu strukturiert werden. Zugriffspfadabhängigkeit bedeutet, dass Daten nur in eine Richtung zugänglich und aussagekräftig sind, was die Möglichkeit einschränkt, die Daten aus verschiedenen Perspektiven abzufragen oder zu interpretieren.

Index- und Zugriffspfadabhängigkeit stellen erhebliche Herausforderungen für Anwendungen dar, die ein komplexes oder sich entwickelndes Datenmodell erfordern. Während Kryptowährungen einfache Datenstrukturen haben, die auf Ethereum implementiert werden können (ERC20-Token sind im Wesentlichen nur eine Zuordnung von Adressen zu Guthaben), werden diese Herausforderungen für datenintensivere Anwendungen problematisch. Wenn eine Anwendung ein komplexes Datenmodell speichern, abfragen und bearbeiten muss, ist die Datenverwaltung durch Ethereums grundlegende Schlüssel-Wert-Speicherung deutlich eingeschränkter, was die Erstellung und Wartung von Anwendungen, die eine komplexe Datenverwaltung erfordern, erschwert.

Eine kurze Geschichtsstunde: Das relationale Modell

„Die Geschichte wiederholt sich nicht, aber sie reimt sich oft“ – Mark Twain


1970 veröffentlichte Edgar F. Codd, ein Informatiker bei IBM, ein Papier mit dem Titel „Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken“. Zu dieser Zeit war die „hierarchische Datenbank“ der beliebteste Anwendungsdatenbanktyp, der eine starre, baumartige Struktur verwendete, bei der jedes Datenelement in einem übergeordneten Verzeichnis gespeichert wurde, ähnlich wie Dateien auf einem Computer organisiert sind. Codd argumentierte gegen die hierarchische Datenbank und schlug eine neuere, einfachere und weitaus leistungsfähigere relationale Datenbank mit einer tabellarischen Struktur vor.


Die baumartige Struktur der hierarchischen Datenbank bedeutet, dass auf Daten nur über das starre System zugegriffen werden kann, das die Eltern-Kind-Beziehung jedes Datenelements versteht. Insbesondere identifizierte Codd drei Hauptprobleme des hierarchischen Systems:


  1. Reihenfolgeabhängigkeit: Das Ergebnis einer Abfrage hängt häufig davon ab, wie die Daten im Speicher organisiert sind. Wenn eine Anwendung unter der Annahme erstellt wird, dass Daten in derselben Reihenfolge abgefragt werden, in der sie gespeichert sind, kann die Reihenfolge in Zukunft nicht mehr geändert werden.

  2. Indexabhängigkeit: Um auf ein bestimmtes Datenelement zugreifen zu können, muss die Anwendung das übergeordnete Element (d. h. einen Index) kennen. Andernfalls ist das Abrufen der angeforderten Daten nicht möglich.

  3. Abhängigkeit vom Zugriffspfad: Um auf Daten zuzugreifen oder sie zu verstehen, muss ein bestimmter Abrufpfad befolgt werden. Wenn die Anwendung darauf ausgelegt ist, Daten mit einem bestimmten Zugriffsmuster abzurufen, kann sie dieselben Daten nicht über alternative Pfade abrufen oder interpretieren.


Kommt Ihnen das bekannt vor? Obwohl Ethereum-Smart Contracts keine Reihenfolgeabhängigkeit aufweisen (Maps sind ungeordnet), behindern dieselben Index- und Zugriffspfadabhängigkeitsbeschränkungen, die Datenbanken in den 1960er und 1970er Jahren behinderten, auch heute noch Smart-Contract-Plattformen.


Einschränkungen auf Datenbankebene sind mehr als nur ein trivialer Rückschlag; sie schränken Entwickler grundlegend ein und begrenzen die Arten von Anwendungen, die auf einer Plattform erstellt werden können. Anstatt sich auf die Implementierung neuer Funktionen zu konzentrieren, müssen Entwickler, die gegen Index- und Zugriffspfadabhängigkeit kämpfen, außerordentlich viel Aufwand aufwenden, um die Funktionalität einer vorhandenen Anwendung aufrechtzuerhalten. In den 1960er und 1970er Jahren war die Verwendung von Datenbanken hauptsächlich starren Geschäftsaufgaben wie Bestandsverwaltung, Buchhaltung und allgemeiner Datenverarbeitung vorbehalten; Entwickler hatten nicht die Datenflexibilität, um anspruchsvollere Anwendungen zu erstellen. Nach der Einführung relationaler Datenbanken entstanden jedoch deutlich ausdrucksstärkere und datenintensivere Anwendungen, was zur Entstehung von ERP-Systemen, CRMs und Business-Intelligence-Tools führte. Darüber hinaus ebneten diese Fortschritte mit dem Aufkommen des Internets den Weg für E-Commerce-Plattformen und Social-Media-Anwendungen. Entwickler konnten Funktionen implementieren, für die zuvor eine komplette Datenbank mit nur wenigen Zeilen SQL neu strukturiert werden musste. Die relationale Datenbank war mehr als ein Paradigmenwechsel; sie war eine Kategorie-erstellende Plattform, die die Entstehung grundlegend neuer Anwendungen ermöglichte.


Heute ähneln Blockchain-Plattformen den Computern und Datenbanken der 1970er Jahre. Da es auf Blockchain-Ebene an leistungsfähiger Datenverarbeitung mangelt, können Entwickler keine anspruchsvolleren, datenintensiveren dezentralen Anwendungen implementieren. Wenn der primäre Anwendungsfall für Blockchains jemals über Kryptowährungen hinausgehen soll, benötigen wir Blockchain-Plattformen mit leistungsfähigeren Datenverarbeitungsfunktionen.

SQL Smart Contracts: Ein flexibleres Paradigma

„Das Maß der Intelligenz ist die Fähigkeit zur Veränderung.“ – Albert Einstein


So wie die Kommerzialisierung relationaler Datenbanken in den 1980er Jahren zur Verbreitung neuer Anwendungen führte, birgt die Integration relationaler Datenbanken in Blockchain-Plattformen das gleiche Potenzial, die Arten dezentraler Anwendungen, die erstellt werden können, neu zu gestalten.


Bei Kwil entwickeln wir eine Blockchain-Plattform und eine Smart-Contract-Sprache, mit der Entwickler dezentrale Anwendungen erstellen können, die die volle Ausdruckskraft von SQL nutzen. Mit Kwil können Entwickler die Flexibilität des relationalen Modells nutzen, um leistungsfähigere, datenintensivere dezentrale Anwendungen zu erstellen.


Betrachten wir das gleiche Beispiel zur Identitätsspeicherung wie zuvor. Anstatt Identitätsdatensätze in einer Karte zu speichern, in der jeder Datensatz nur über seinen Schlüssel zugänglich ist, ermöglicht Kwil Entwicklern, die Datensätze in einer Tabelle zu speichern und eine flexible SQL-Syntax zu nutzen, um die Tabelle abzufragen:


 database user_registry; table identities { address uuid primary key, name text notnull, date_of_birth int notnull, residential_address text notnull, national_id int notnull, #country_index index(national_id) } action query_by_national_id ($id) public view { SELECT * FROM identities WHERE national_id = $id; } action query_by_dob ($dob) public view { SELECT * FROM identities WHERE date_of_birth > $dob; }


Im ursprünglichen Ethereum-Smart-Contract gab es keine Möglichkeit, die Identitäten zu durchsuchen und alle Benutzer unter einer bestimmten Bedingung (z. B. Personalausweis) zurückzugeben oder ein Wallet anhand eines bestimmten Attributs (z. B. Geburtsdatum) zuzuordnen. Um eine solche Funktionalität zu ermöglichen, müsste der Vertrag umstrukturiert werden, um kostspielige, gasintensive Funktionen hinzuzufügen. Mit dem relationalen Modell können Entwickler diese Abfragen jedoch ohne erforderliche Umstrukturierung ausführen und so mehr Flexibilität bei der Datenmanipulation gewinnen, ohne zusätzliche Kosten zu verursachen.


Das idOS-Netzwerk ist beispielsweise eine souveräne Blockchain, die mit Kwil erstellt wurde und es Benutzern und dApps ermöglicht, Benutzeranmeldeinformationen zu speichern. Die Nutzung von SQL über das idOS-Netzwerk ermöglicht:


  1. Benutzer müssen über mehrere Geldbörsen, Anmeldeinformationen und Attribute zugeordnet und abrufbar sein.

  2. DeFi-Protokolle führen aggregierte Analysen darüber durch, woher ihre Benutzer kommen.

  3. Stablecoin-Protokolle zur Beurteilung, welche Benutzer aus Hochrisikogebieten stammen.


Durch die Aktivierung des relationalen Modells und von SQL auf einer dezentralen Blockchain-Plattform können wir grundlegend neue Anwendungen erstellen, die auf vorhandenen Ethereum-Smart Contracts nicht möglich sind.

Abschluss

Das relationale Modell, das vor 40 Jahren die Computerbranche revolutionierte, hat heute die gleichen Fähigkeiten, die Blockchain-Branche zu revolutionieren. In den 1960er und 1970er Jahren beschränkten Index- und Zugriffspfadabhängigkeit die Nützlichkeit der hierarchischen Datenbank in datenintensiven Anwendungen. Heute beschränkt dieselbe Index- und Zugriffspfadabhängigkeit die Ethereum-Smart Contracts und ihre Fähigkeit, dezentrale Plattformen mit komplexen Datenmodellen zu betreiben. Indem wir jedoch das relationale Modell in die Blockchain integrieren und Entwicklern denselben ausdrucksstarken SQL-Dialekt zur Verfügung stellen, können wir neue Arten von Anwendungen erschließen. So wie die relationale Datenbank die Geschäftsnachfrage beschleunigte und Computern zu einer allgemeinen Akzeptanz verhalf, kann sie Blockchain-Plattformen dabei helfen, dasselbe zu tun und so eine freiere, dezentralere und vertrauenswürdigere digitale Welt zu erschließen.