Utöka smarta kontrakt med SQL

Speciellt tack till Jun Jiang från DePHY Network och Ryan Soury från Usher Labs för feedback och insikter.

År 2008 ringde larmen på Wall Street när sofistikerade handlare gick ner i en primär frenesi. Överbelånade finansiella institutioner, som kollapsade under tyngden av subprime-inteckningsskyddade värdepapper, lämnade giriga bankirer utsatta och bad om räddningsaktioner. Centralbankerna, desperata att behålla sitt grepp om makten, betalade för bankirernas synder från gemene mans checkhäfte. Detta svek blottade det centraliserade monetära systemets brister och avslöjade behovet av ett nyare, friare och mer rättvist finansiellt system. Precis som den amerikanska revolutionen och konstitutionen som följde separerade kyrka och stat, uppstod en ny revolution kallad Bitcoin för att separera pengar och stat, vilket möjliggör många av samma friheter och friheter som är grundläggande för självbestämmande.

Blockchain-teknik är frihetsteknik. Det gör det möjligt för oss att bygga finansiella, identitets-, informations- och sociala samordningssystem som inte kräver förtroende för en centraliserad mellanhand. Individuella friheter frodas i en värld där centralbanken inte kontrollerar flödet av pengar, en enda plattform inte kontrollerar den sociala diskursen och ett enda företag inte kontrollerar digitala identiteter.

Många av skillnaderna mellan denna nya värld och där vi är idag ligger i blockkedjeplattformarnas tekniska kapacitet. Den första generationen smarta kontrakt var toppen av isberget som möjliggjorde dessa frihetssystem; dock är de i grunden begränsade i sina möjligheter. I den här artikeln förklarar jag några av de kritiska begränsningarna i nuvarande smarta kontrakt och hur ett nytt system, "SQL Smart Contracts", ger en mer tekniskt kapabel grund för att låsa upp mänskliga friheter och realisera blockchains potential som en ny datorplattform.

Smarta kontrakt: programmering av sanningsmaskinen

"Rotproblemet ... är allt förtroende som krävs för att få det att fungera." - Satoshi Nakamoto

En blockkedjas ursprungliga kärnegenskap är oföränderlighet; när en viss tröskel av intressenter (eller "noder") i ett nätverk är överens om att något är sant, kommer blockkedjan att behålla en permanent registrering av den sanningen. Blockkedjor använder en mängd olika "bevis"-mekanismer där noder spenderar stora mängder värde i form av datorkraft, ekonomisk insats eller rykte för att säkerställa att illvilliga aktörer inte kan manipulera sanningen.

Om Bitcoin är "sanningsmaskinen" för digital valuta, är Ethereum "sanningsmaskinen" för mer komplexa finansiella produkter. Ethereum expanderar på Bitcoins möjligheter genom att skapa ett programmerbart designutrymme där utvecklare kan implementera vilken logik som helst som ska distribueras, verifieras och exekveras över en serie noder. Det betyder att vi nu kan skapa system som tar bort behovet av förtroende för en central myndighet bortom bara valuta! Alla system som kräver centrala myndigheter – såsom utlåning, fastighetshandlingar, identitetsinformation, sociala medier, ekonomiska mått etc. – kan nu fungera utan centrala mellanhänder. Det här är en helt ny värld!

Ett smart kontrakt är ett program som utvecklare skriver och distribuerar på en blockchain, duken för utvecklare att skapa decentraliserade applikationer. Termen "smart kontrakt" betyder inte ett juridiskt kontrakt där två parter är bundna till vissa rättigheter och skyldigheter. Istället innebär ett "smart kontrakt" helt enkelt att applikationen garanterat fungerar precis som koden är skriven på obestämd tid. Lånekontrakt garanterar att låntagare och långivare alltid kan göra transaktioner. Fastighetskontrakt garanterar att människor alltid kan verifiera och överföra fastighetsägande. Ett smart kontrakt är en applikation där kod blir lag.

Steve Jobs kallade datorn "en cykel för sinnet." Smarta kontrakt garanterar att hjulen aldrig ramlar av.

Ethereums smarta kontrakt: toppen av isberget

"Crypto handlar inte bara om att handla med tokens, det är en del av ett bredare etos för att skydda frihet och integritet och behålla makten i händerna på den lilla killen." - Vitalik Buterin

Även om Ethereums smarta kontrakt introducerade en helt ny värld av decentraliserade produkter, hindrar grundläggande begränsningar i deras design- och datamanipuleringsmöjligheter dem från att vara effektiva i många applikationer utöver kryptovaluta.

I Solidity (ett programmeringsspråk för Ethereum) lagras kontraktsdata i nyckel-värdepar. Även om strukturer (variabelgrupperingar) och mappningar (insamling av nyckel-värdepar) erbjuder användbara sätt att organisera data, kan all data endast hämtas med sin nyckel. Överväg ett teoretiskt kontrakt för lagring av användaridentitetsdata:

 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 }

I detta kontrakt kan en användares identitetspost endast hämtas genom att känna till användarens land och plånboksadress. Såvida inte kontraktsutvecklaren designar om det smarta kontraktet för att ha datamanipulation med höga gaskostnader, finns det inga andra sätt för kontraktsanvändaren att hämta en identitetspost. Att lagra data i nyckel-värdepar begränsar i slutändan hur data kan nås och manipuleras.

Datahantering i Ethereums smarta kontrakt presenterar särskilt två grundläggande problem: indexberoende och åtkomstvägsberoende.

Indexberoende

Indexberoende innebär att för att få tillgång till en specifik del av data måste data finnas tillgängligt i ett index. Ett index är en datastruktur som effektivt söker efter en unik identifierare inom en samling. I exemplet på KYC-kontraktet ovan är poster endast tillgängliga via den exakta Ethereum-adressen som används för nyckeln. Denna stela indexeringsstruktur förhindrar kontraktsanvändare från att fråga efter data baserat på andra kriterier, som "Vilka användare har den här bostadsadressen?" eller "Hur många procent av användare med detta nationella ID föddes efter 1 januari 1970?" Utan möjligheten att utföra sådana frågor saknar utvecklare flexibiliteten att aggregera, analysera och bygga applikationslogik kring kontraktsdata. När utvecklare behöver denna extra flexibilitet, som att hämta en identitetspost med fullt namn, måste hela kontraktet omstruktureras. I Ethereum kan omstruktureringsindex också öka ett kontrakts gaskostnader, vilket ytterligare försvårar kontraktets användbarhet.

Access Path Dependence

Åtkomstvägsberoende hänvisar till att data är tillgänglig och begriplig endast genom en specifik hämtningsväg. I exempelkontraktet skulle en utvecklare kunna hämta sin identitetspost genom att känna till Vitaliks land och plånboksadress. Att bara känna till plånboksadressen skulle dock inte tillåta en utvecklare att få Vitaliks ursprungsland. Dessutom, även om utvecklaren har Vitaliks plånboksadress, kan de inte få hans identitetsregister om de inte också känner till ursprungslandet (”Kanada”-nyckeln). Åtkomstvägen till Vitaliks identitetspost är fixerad; om en utvecklare behövde försöka hämta sin post med bara plånboksadressen, skulle hela kontraktet behöva omstruktureras. Åtkomstvägsberoende innebär att data är tillgänglig och meningsfull endast i en riktning, vilket begränsar möjligheten att fråga eller tolka data från olika perspektiv.

Index- och åtkomstvägsberoende utgör betydande utmaningar för applikationer som kräver en komplex eller utvecklande datamodell. Medan kryptovalutor har enkla datastrukturer som kan implementeras på Ethereum (ERC20-tokens är i huvudsak bara en kartläggning av adresser till saldon), blir dessa utmaningar problematiska för mer dataintensiva applikationer. När en applikation behöver lagra, fråga och manipulera en komplex datamodell, gör Ethereums grundläggande nyckel-värdelagring datahantering betydligt mer begränsande, vilket gör det utmanande att bygga och underhålla applikationer som kräver komplex datahantering.

En kort historielektion: Relationsmodellen

"Historien upprepar sig inte, men den rimmar ofta" - Mark Twain

1970 publicerade Edgar F. Codd, en datavetare vid IBM, en artikel som heter "A Relational Model of Data for Large Shared Data Banks." På den tiden var den mest populära typen av applikationsdatabas den "hierarkiska databasen", som använde en stel, trädliknande struktur där varje bit data lagrades under en överordnad katalog, liknande hur filer är organiserade på en dator. Codd argumenterade mot den hierarkiska databasen och föreslog en nyare, enklare, mycket mer kapabel relationsdatabas med en tabellstruktur.

Den hierarkiska databasens trädliknande struktur innebär att data endast kan nås genom det stela systemet för att förstå varje del av datas förälder-barn-relation. I synnerhet identifierade Codd tre nyckelproblem med det hierarkiska systemet:

1. Beställningsberoende: Resultatet av en fråga beror ofta på hur data är organiserad i lagringen. Om en applikation är byggd förutsatt att data kommer att efterfrågas i samma ordning som den lagras, kan ordningen inte ändras i framtiden.

2. Indexberoende: För att få tillgång till en specifik del av data måste programmet känna till föräldern (dvs. ett index). Annars är det omöjligt att hämta de begärda uppgifterna.

3. Åtkomstvägsberoende: För att komma åt eller förstå data krävs att man följer en specifik hämtningsväg. Om applikationen är utformad för att hämta data med ett visst åtkomstmönster, kan den inte hämta eller tolka samma data med hjälp av alternativa sökvägar.

   
   

Låter detta bekant? Även om Ethereums smarta kontrakt inte har beställningsberoende (kartor är oordnade), håller samma index- och åtkomstvägsberoendebegränsningar som höll databaser tillbaka på 1960- och 1970-talen tillbaka smarta kontraktsplattformar idag.

Begränsningar på databasnivå är mer än ett trivialt bakslag; de begränsar i grunden utvecklare och begränsar de typer av applikationer som byggs på en plattform. Istället för att fokusera på att implementera nya funktioner måste utvecklare som bekämpar index- och åtkomstvägsberoende lägga extraordinärt mycket arbete på att underhålla en befintlig applikations funktionalitet. Under 1960- och 1970-talen var databasanvändning i första hand reserverad för stela affärsuppgifter såsom lagerhantering, redovisning och allmän databehandling; utvecklare hade inte dataflexibiliteten att skapa mer sofistikerade applikationer. Men efter introduktionen av relationsdatabaser uppstod betydligt mer uttrycksfulla och dataintensiva applikationer, vilket ledde till framväxten av ERP-system, CRM:er och affärsintelligensverktyg. Dessutom banade dessa framsteg vägen för e-handelsplattformar och sociala medieapplikationer med internets tillkomst. Utvecklare skulle kunna implementera funktioner som tidigare krävde att en hel databas skulle omstruktureras med bara några rader SQL. Relationsdatabasen var mer än ett paradigmskifte; det var en kategoriskapande plattform som gjorde det möjligt för fundamentalt nya applikationer att komma till.

Idag liknar blockchain-plattformar datorer och databaser på 1970-talet. Bristen på kapabel databehandling på blockkedjenivå innebär att utvecklare inte kan implementera mer sofistikerade, dataintensiva decentraliserade applikationer. Om det primära användningsfallet för blockkedjor någonsin kommer att expandera bortom kryptovaluta, behöver vi blockkedjeplattformar med mer kapabel databehandlingsfunktionalitet.

SQL Smart Contracts: Ett mer flexibelt paradigm

"Mättet på intelligens är förmågan att förändra." - Albert Einstein

Precis som kommersialiseringen av relationsdatabasen på 1980-talet ledde till spridningen av nya applikationer, har integrering av relationsdatabaser i blockchain-plattformar samma potential att omforma de typer av decentraliserade applikationer som kan skapas.

På Kwil bygger vi en blockchain-plattform och ett smart kontraktsspråk som gör att utvecklare kan bygga decentraliserade applikationer som utnyttjar SQLs fulla uttrycksförmåga. Med Kwil kan utvecklare utnyttja relationsmodellens flexibilitet för att skapa mer kapabla, dataintensiva decentraliserade applikationer.

Betrakta samma exempel på identitetslagring från tidigare. Istället för att lagra identitetsposter i en karta där varje post endast är tillgänglig med sin nyckel, tillåter Kwil utvecklare att lagra posterna i en tabell och utnyttja en flexibel SQL-syntax för att fråga över tabellen:

 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; }

I det ursprungliga smarta Ethereum-kontraktet fanns det inget sätt att söka igenom identiteterna och returnera alla användare som fått ett villkor (som nationellt ID) eller att associera en plånbok baserat på ett specifikt attribut (som ett födelsedatum). För att möjliggöra sådan funktionalitet skulle det krävas en omstrukturering av kontraktet för att lägga till kostsamma, gasintensiva funktioner. Men med den relationella modellen kan utvecklare utföra dessa frågor utan att någon omstrukturering krävs, och därmed få mer flexibilitet för datamanipulering utan att ådra sig extra kostnader.

Till exempel är idOS-nätverket en suverän blockkedja byggd med Kwil, vilket tillåter användare och dApps att lagra användaruppgifter. Att utnyttja SQL över idOS-nätverket möjliggör:

1. Användare som ska associeras och kan hämtas av flera plånböcker, referenser och attribut.

2. DeFi-protokoll för att utföra aggregerade analyser av var deras användare kommer ifrån.

3. Stablecoin-protokoll för att bedöma vilka användare som kommer från högriskområden.

   
   

Genom att aktivera relationsmodellen och SQL på en decentraliserad blockchain-plattform kan vi skapa fundamentalt nya applikationer som inte kan existera på befintliga Ethereum smarta kontrakt.

Slutsats

Den relationsmodell som revolutionerade datorindustrin för 40 år sedan har samma förmåga att revolutionera blockkedjeindustrin idag. På 1960- och 1970-talen begränsade index- och åtkomstvägsberoende den hierarkiska databasens användbarhet i dataintensiva applikationer. Idag begränsar samma index- och åtkomstvägsberoende Ethereums smarta kontrakt och deras förmåga att driva decentraliserade plattformar med komplexa datamodeller. Men genom att integrera relationsmodellen i blockkedjan och förse utvecklare med samma uttrycksfulla SQL-dialekt kan vi låsa upp nya typer av applikationer. Precis som den relationella databasen accelererade affärsefterfrågan och hjälpte datorer att bli vanligare, kan den hjälpa blockkedjeplattformar att göra detsamma och därigenom låsa upp en friare, mer decentraliserad, mer pålitlig digital värld.