Nej, at lancere en decentral applikation (dapp) på blockchain vil ikke føre til en succesfuld forretning. Faktisk tænker de fleste brugere ikke engang på, om applikationen kører på blockchain - de vælger simpelthen et produkt, der er billigere, hurtigere og enklere.

Desværre, selvom blockchain har sine egne unikke funktioner og fordele, er de fleste applikationer, der kører på den, meget dyrere, langsommere og mindre intuitive end deres centraliserede konkurrenter.

Ganske ofte kan man i whitepapers af applikationer, der er bygget på blockchain, finde et afsnit, der siger: "Blockchainen er dyr og kan ikke understøtte det nødvendige antal transaktioner i sekundet. Heldigvis arbejder mange smarte mennesker på at skalere blockchainen og når vores applikation lanceres, vil den blive ret skalerbar."

I et enkelt afsnit kan en dapp-udvikler give afkald på en dybere diskussion af skalerbarhedsproblemer og alternative løsninger på problemer. Dette fører ofte til en ineffektiv arkitektur, hvor smarte kontrakter, der kører på blockchain, fungerer som backend og kerne af applikationen.

Der er dog stadig uafprøvede tilgange til decentraliseret applikationsarkitektur, der giver mulighed for meget bedre skalerbarhed ved at reducere afhængigheden af ​​blockchain. For eksempel arbejder Blockstack på en arkitektur, hvor det meste af applikationsdata og logik er lagret off-chain.

Lad os først se på en mere traditionel tilgang, som bruger blockchain som et direkte mellemled mellem applikationsbrugere, og som ikke skalerer særlig godt.

Fremgangsmåde #1: Blockchain som backend

For at gøre tingene klarere, lad os tage hotelbranchen som eksempel. Dette er en enorm industri, hvor formidlere som Booking.com, de opkræver et stort gebyr til at forbinde gæster og hoteller.

I enhver situation, hvor vi ønsker at besejre en sådan mellemmand ved hjælp af denne tilgang, vil vi forsøge at replikere dens forretningslogik ved hjælp af smarte kontrakter på en blockchain som Ethereum.

Open source smarte kontrakter, der kører på "verdenscomputeren", kan forbinde handlende med forbrugere uden en tredjepart imellem, hvilket i sidste ende reducerer de gebyrer og provisioner, som mellemmanden opkræver.

Som vist på billedet nedenfor, bruger hoteller en decentral applikation til at poste på blockchain oplysninger om værelser, deres tilgængelighed og priser på hverdage eller weekender, og måske endda en beskrivelse af værelserne med al anden relevant information.

Enhver, der ønsker at reservere et værelse, bruger denne applikation til at søge efter hoteller og værelser, der er hostet på blockchain. Når brugeren har valgt et værelse, foretages reservationen ved at sende det nødvendige antal tokens til hotellet som depositum. Og som svar opdaterer den smarte kontrakt informationen i blockchainen om, at nummeret ikke længere er tilgængeligt.

Der er to sider af skalerbarhedsproblemet med denne tilgang. Først det maksimale antal transaktioner pr. sekund. For det andet mængden af ​​data, der kan lagres på blockchain.

Lad os lave nogle grove beregninger. Booking.com siger, at de har næsten 2 millioner hoteller registreret hos dem. Lad os sige, at det gennemsnitlige hotel har 10 værelser, og hvert enkelt er reserveret kun 20 gange om året - det giver os et gennemsnit på 13 bookinger i sekundet.

For at sætte dette tal i perspektiv er det værd at bemærke, at Ethereum kan behandle cirka 15 transaktioner i sekundet.

Samtidig er det værd at overveje, at vores applikation også vil indeholde transaktioner fra hoteller - til download og konstant opdatering af oplysninger om deres værelser. Hoteller opdaterer værelsespriser meget ofte, nogle gange endda dagligt, og hver pris- eller beskrivelsesændring kræver en transaktion på blockchain.

Der er også størrelsesproblemer her - vægten af ​​Ethereum blockchain passerede for nylig 2TB-mærket. Hvis applikationer med denne tilgang blev virkelig populære, ville Ethereum-netværket blive ekstremt ustabilt.

Et sådant blockchain-baseret system kan udelukke outsidere på grund af dets upartiskhed og mangel på centralisering, de vigtigste fordele ved blockchain-teknologi. Men blockchain har også andre funktioner - den er distribueret og ikke omskrevet, det er fremragende egenskaber, men du skal betale for dem i hastigheden og kommissionen af ​​transaktioner.

Derfor skal dapp-udviklere nøje vurdere, om hver funktion, der bruger blockchain, virkelig har brug for distribution og ikke-skrivbarhed.

For eksempel: hvad er fordelen ved at distribuere hvert hotels data på tværs af hundredvis af maskiner rundt om i verden og gemme dem permanent der? Er det virkelig vigtigt, at historiske data om værelsespriser og tilgængelighed altid er inkluderet i blockchainen? Sikkert ikke.

Hvis vi begynder at stille spørgsmål som disse, vil vi begynde at se, at vi ikke nødvendigvis har brug for alle de dyre blockchain-funktioner til alle vores funktioner. Så hvad er alternativet?

Fremgangsmåde #2: Blockstack-inspireret arkitektur

Selvom hovedvægten Blockstack på applikationer, hvor brugerne er ejere af deres data (f.eks Lufttekst, BentenSound, Billedoptimering eller Graphite), har blockstack også en filosofi om at bruge blockchain let - kun når det er absolut nødvendigt. Deres hovedargument er, at blockchain er langsom og dyr, og derfor kun bør bruges til enkelte eller sjældne transaktioner. Resten af ​​interaktionen med applikationer bør ske gennem peer-to-peer, dvs. brugere af decentrale applikationer skal dele data direkte med hinanden i stedet for gennem blockchain. De ældste og mest succesrige decentrale applikationer som BitTorrent, e-mail og Tor blev trods alt skabt før selve begrebet blockchain.

Venstre: Den første tilgang, hvor brugere interagerer via blockchain. Til højre: Brugerne interagerer direkte med hinanden, og blockchainen bruges kun til identifikation og lignende.

Lad os gå tilbage til hotelreservationseksemplet. Vi ønsker en upartisk, uafhængig og åben protokol til at forbinde gæster med hoteller. Vi vil med andre ord fjerne den centraliserede mellemmand. Vi behøver for eksempel ikke konstant at opbevare værelsespriser i en fælles fordelt hovedbog.

Hvorfor tillader vi ikke bare gæster og hoteller at interagere direkte i stedet for via blockchain. Hoteller kan gemme deres priser, ledige værelser og enhver anden information et sted, hvor den vil være tilgængelig for alle - for eksempel IPFS, Amazon S3 eller endda deres egen lokale server. Det er præcis, hvad Blockstacks decentraliserede lagersystem kaldte Gaia. Det giver brugerne mulighed for at vælge, hvor de vil have deres data gemt og kontrollere, hvem der kan få adgang til dem gennem en fremgangsmåde kaldet flerbrugerlagring.

For at etablere tillid er alle hoteldata kryptografisk underskrevet af hotellet selv. Uanset hvor disse data er gemt, kan dets integritet verificeres ved hjælp af de offentlige nøgler, der er knyttet til dette hotels identitet, der er gemt på blockchain.

I tilfælde af Blockstack er det kun dine identitetsoplysninger, der gemmes på blockchain. Information om, hvordan man får hver brugers data, gemmes i zonefiler og distribueres gennem et peer-to-peer-netværk ved hjælp af noder. Og endnu en gang behøver du ikke stole på de data, som noderne giver, fordi du kan verificere dets ægthed ved at sammenligne det med de hashes, der er gemt i blockchainen og andre brugere.

I en forenklet version af systemet vil gæster bruge Blockstack peer-to-peer-netværket til at søge efter hoteller og få information om deres værelser. Og ægtheden og integriteten af ​​alle data, du modtager, kan verificeres ved hjælp af offentlige nøgler og hashes gemt i virtuelt kredsløb Blockstack.

Denne arkitektur er mere kompleks end den første tilgang og kræver en mere omfattende infrastruktur. Faktisk er det præcis her, Blockstack kommer ind, og leverer alle de nødvendige komponenter til at skabe sådan et decentraliseret system.

Med denne arkitektur gemmer vi kun data på blockchainen, som virkelig skal distribueres og ikke overskrives. I tilfælde af Blockstack behøver du kun transaktioner på blockchain for at registrere og angive, hvor dine data skal opbevares. Du skal muligvis foretage flere transaktioner, hvis du vil ændre nogen af ​​disse oplysninger, men dette er ikke en tilbagevendende begivenhed.

Desuden kører applikationslogikken, i modsætning til den første tilgang, på klientsiden og ikke på smarte kontrakter. Dette giver udvikleren mulighed for at ændre denne logik uden dyre eller nogle gange endda umulige smarte kontraktopdateringer. Og ved at holde applikationsdata og logik off-chain, kan decentraliserede applikationer opnå præstations- og skalerbarhedsniveauerne for traditionelle centraliserede systemer.

Konklusion

Applikationer, der kører på Blockstack, kan skalere meget bedre end konventionelle blockchain-applikationer, men det er en yngre tilgang med sine egne problemer og ubesvarede spørgsmål.

For eksempel, hvis en decentral applikation ikke kører på smarte kontrakter, reducerer dette behovet for hjælpetokens. Dette kan forårsage problemer for virksomheder i betragtning af, at ICO'er har været hovedkilden til finansiering af decentraliserede applikationer (inklusive selve Blockstack)

Her er der også tekniske problemer. Eksempelvis er det relativt nemt at implementere en hotelbookingsfunktion i en smart kontrakt, hvor der i en atomoperation foretages værelsesreservationer i bytte for poletter. Og det er ikke særlig indlysende, hvordan booking vil fungere i en Blockstack-applikation uden smarte kontrakter.

Apps, der retter sig mod globale markeder med potentiale for millioner af brugere, skal skaleres meget godt for at få succes. Det er en fejl udelukkende at stole på blockchains for at opnå dette niveau af skalerbarhed i den nærmeste fremtid. For at kunne konkurrere med store centraliserede markedsaktører såsom Booking.com, bør decentraliserede applikationsudviklere overveje alternative tilgange til at designe deres applikationer, såsom den, der tilbydes af Blockstack.

Kilde: www.habr.com