Nej, att lansera en decentraliserad applikation (dapp) på blockkedjan kommer inte att leda till en framgångsrik verksamhet. Faktum är att de flesta användare inte ens tänker på om applikationen körs på blockchain - de väljer helt enkelt en produkt som är billigare, snabbare och enklare.
Tyvärr, även om blockchain har sina egna unika funktioner och fördelar, är de flesta applikationer som körs på den mycket dyrare, långsammare och mindre intuitiva än sina centraliserade konkurrenter.
Ganska ofta i whitepapers av applikationer som är byggda på blockkedjan kan du hitta ett stycke som säger: "Blockkedjan är dyr och kan inte stödja det antal transaktioner som krävs per sekund. Lyckligtvis arbetar många smarta människor med att skala blockkedjan och när vår applikation lanseras kommer den att bli ganska skalbar."
I ett enkelt stycke kan en dapp-utvecklare avstå från en djupare diskussion om skalbarhetsproblem och alternativa lösningar på problem. Detta leder ofta till en ineffektiv arkitektur där smarta kontrakt som körs på blockkedjan fungerar som backend och kärna i applikationen.
Det finns dock fortfarande oprövade tillvägagångssätt för decentraliserad applikationsarkitektur som möjliggör mycket bättre skalbarhet genom att minska beroendet av blockkedjan. Blockstack arbetar till exempel med en arkitektur där det mesta av applikationsdata och logik lagras utanför kedjan.
Låt oss först titta på ett mer traditionellt tillvägagångssätt, som använder blockchain som en direkt mellanhand mellan applikationsanvändare, och som inte skalar särskilt väl.
Tillvägagångssätt #1: Blockchain som backend
För att göra saker tydligare, låt oss ta hotellbranschen som exempel. Detta är en enorm bransch där mellanhänder som Booking.com, för att koppla samman gäster och hotell.
I alla situationer där vi vill besegra en sådan mellanhand med detta tillvägagångssätt, kommer vi att försöka replikera dess affärslogik med smarta kontrakt på en blockchain som Ethereum.
Smarta kontrakt med öppen källkod som körs på "världsdatorn" kan koppla handlare till konsumenter utan en tredje part emellan, vilket i slutändan minskar de avgifter och provisioner som tas ut av mellanhanden.
Som visas på bilden nedan använder hotell en decentraliserad applikation för att lägga upp information på blockchain om rum, deras tillgänglighet och priser på vardagar eller helger, och kanske till och med en beskrivning av rummen med all annan relevant information.
Alla som vill boka ett rum använder den här applikationen för att söka efter hotell och rum på blockchain. När användaren har valt ett rum görs bokningen genom att skicka det nödvändiga antalet tokens till hotellet som en deposition. Och som svar uppdaterar det smarta kontraktet informationen i blockkedjan om att numret inte längre är tillgängligt.
Det finns två sidor av skalbarhetsproblemet med detta tillvägagångssätt. Först det maximala antalet transaktioner per sekund. För det andra mängden data som kan lagras på blockkedjan.
Låt oss göra några grova beräkningar. Booking.com säger att de har nästan 2 miljoner hotell registrerade hos dem. Låt oss säga att ett genomsnittligt hotell har 10 rum och att vart och ett är bokat bara 20 gånger per år - det ger oss i genomsnitt 13 bokningar per sekund.
För att sätta denna siffra i perspektiv är det värt att notera att Ethereum kan behandla cirka 15 transaktioner per sekund.
Samtidigt är det värt att tänka på att vår applikation även kommer att innehålla transaktioner från hotell - för att ladda ner och ständigt uppdatera information om deras rum. Hotell uppdaterar rumspriser mycket ofta, ibland till och med dagligen, och varje pris- eller beskrivningsändring kräver en transaktion på blockkedjan.
Det finns också storleksproblem här - vikten av Ethereum blockchain passerade nyligen 2TB-märket. Om applikationer med detta tillvägagångssätt blev riktigt populära, skulle Ethereum-nätverket bli extremt instabilt.
Ett sådant blockkedjebaserat system kan utesluta utomstående på grund av dess opartiskhet och brist på centralisering, de främsta fördelarna med blockkedjeteknik. Men blockkedjan har också andra funktioner - den är distribuerad och inte omskriven, dessa är utmärkta egenskaper, men du måste betala för dem i hastigheten och provisionen av transaktioner.
Därför måste dapp-utvecklare noggrant utvärdera om varje funktion som använder blockkedjan verkligen behöver distribution och icke-skrivbarhet.
Till exempel: vad är fördelen med att distribuera varje hotells data över hundratals maskiner runt om i världen och lagra den där permanent? Är det verkligen viktigt att historisk data om rumspriser och tillgänglighet alltid finns med i blockkedjan? Antagligen inte.
Om vi börjar ställa frågor som dessa kommer vi att börja se att vi inte nödvändigtvis behöver alla dyra blockchain-funktioner för alla våra funktioner. Så, vad är alternativet?
Tillvägagångssätt #2: Blockstack-inspirerad arkitektur
Även om huvudtyngdpunkten på applikationer där användare är ägare till deras data (till exempel , , eller ), har blockstack också en filosofi att använda blockkedjan lätt – bara när det är absolut nödvändigt. Deras huvudargument är att blockchain är långsam och dyr, och därför endast bör användas för enstaka eller sällsynta transaktioner. Resten av interaktionen med applikationer bör ske genom peer-to-peer, d.v.s. användare av decentraliserade applikationer måste dela data direkt med varandra, snarare än genom blockkedjan. De äldsta och mest framgångsrika decentraliserade applikationerna som BitTorrent, e-post och Tor skapades trots allt före själva konceptet med blockchain.
Vänster: Det första tillvägagångssättet, där användare interagerar via blockkedjan. Höger: Användare interagerar direkt med varandra, och blockkedjan används endast för identifiering och liknande.
Låt oss gå tillbaka till exemplet med hotellbokning. Vi vill ha ett opartiskt, oberoende och öppet protokoll för att koppla gäster till hotell. Vi vill med andra ord ta bort den centraliserade mellanhanden. Vi behöver till exempel inte ständigt lagra rumspriser i en gemensam distribuerad reskontra.
Varför tillåter vi inte bara gäster och hotell att interagera direkt snarare än via blockchain. Hotell kan lagra sina priser, rumstillgänglighet och all annan information någonstans där den kommer att vara tillgänglig för alla - till exempel IPFS, Amazon S3 eller till och med deras egen lokala server. Det är precis vad Blockstacks decentraliserade lagringssystem kallade . Det låter användare välja var de vill att deras data ska lagras och kontrollera vem som kan komma åt den genom ett tillvägagångssätt som kallas .
För att skapa förtroende är all hotelldata kryptografiskt signerad av hotellet självt. Oavsett var denna data lagras kan dess integritet verifieras med hjälp av de offentliga nycklar som är associerade med hotellets identitet lagrad i blockchain.
När det gäller Blockstack lagras endast din identitetsinformation på blockkedjan. Information om hur man skaffar varje användares data lagras i zonfiler och distribueras genom ett peer-to-peer-nätverk med hjälp av noder. Och återigen behöver du inte lita på data som noderna ger, eftersom du kan verifiera dess äkthet genom att jämföra den med hasharna som lagras i blockchain och andra användare.
I en förenklad version av systemet kommer gästerna att använda Blockstack peer-to-peer-nätverket för att söka efter hotell och få information om sina rum. Och äktheten och integriteten för all data du tar emot kan verifieras med hjälp av offentliga nycklar och hash som lagras i Blockstack.
Denna arkitektur är mer komplex än den första metoden och kräver en mer omfattande infrastruktur. Faktum är att det är precis här Blockstack kommer in, och tillhandahåller alla nödvändiga komponenter för att skapa ett sådant decentraliserat system.
Med denna arkitektur lagrar vi bara data på blockkedjan som verkligen behöver distribueras och inte skrivas över. När det gäller Blockstack behöver du bara transaktioner på blockkedjan för att registrera och ange var din data ska lagras. Du kan behöva göra fler transaktioner om du vill ändra någon av denna information, men detta är inte en återkommande händelse.
Dessutom körs applikationslogiken, i motsats till den första metoden, på klientsidan och inte på smarta kontrakt. Detta gör att utvecklaren kan ändra denna logik utan kostsamma eller ibland omöjliga smarta kontraktsuppdateringar. Och genom att behålla applikationsdata och logik utanför kedjan, kan decentraliserade applikationer uppnå prestanda och skalbarhetsnivåer för traditionella centraliserade system.
Slutsats
Applikationer som körs på Blockstack kan skalas mycket bättre än konventionella blockkedjeapplikationer, men det är ett yngre tillvägagångssätt med sina egna problem och obesvarade frågor.
Till exempel, om en decentraliserad applikation inte körs på smarta kontrakt, minskar detta behovet av verktygstokens. Detta kan orsaka problem för företag med tanke på att ICO har varit den huvudsakliga finansieringskällan för decentraliserade applikationer (inklusive Blockstack själv)
Här finns även tekniska problem. Det är till exempel relativt enkelt att implementera en hotellbokningsfunktion i ett smart kontrakt, där man i en atomverksamhet gör rumsreservationer i utbyte mot polletter. Och det är inte särskilt uppenbart hur bokning kommer att fungera i en Blockstack-applikation utan smarta kontrakt.
Appar som riktar sig till globala marknader med potential för miljontals användare måste skalas mycket väl för att bli framgångsrika. Det är ett misstag att förlita sig enbart på blockkedjor för att uppnå denna nivå av skalbarhet inom en snar framtid. För att kunna konkurrera med stora centraliserade marknadsaktörer som Booking.com bör decentraliserade applikationsutvecklare överväga alternativa tillvägagångssätt för att designa sina applikationer, som den som erbjuds av Blockstack.
Källa: will.com