Nei, lansering av en desentralisert applikasjon (dapp) på blokkjeden vil ikke føre til en vellykket virksomhet. Faktisk tenker de fleste brukere ikke engang på om applikasjonen kjører på blokkjeden - de velger ganske enkelt et produkt som er billigere, raskere og enklere.
Dessverre, selv om blockchain har sine egne unike funksjoner og fordeler, er de fleste applikasjoner som kjører på den mye dyrere, tregere og mindre intuitive enn deres sentraliserte konkurrenter.
Ganske ofte i whitepapers av applikasjoner som er bygget på blokkjeden, kan du finne et avsnitt som sier: "Blokkjeden er dyr og kan ikke støtte det nødvendige antallet transaksjoner per sekund. Heldigvis jobber mange smarte mennesker med å skalere blokkjeden og når applikasjonen vår starter, vil den bli ganske skalerbar."
I ett enkelt avsnitt kan en dapp-utvikler gi avkall på en dypere diskusjon om skalerbarhetsproblemer og alternative løsninger på problemer. Dette fører ofte til en ineffektiv arkitektur der smarte kontrakter som kjører på blokkjeden fungerer som backend og kjerne i applikasjonen.
Imidlertid er det fortsatt uprøvde tilnærminger til desentralisert applikasjonsarkitektur som gir mye bedre skalerbarhet ved å redusere avhengigheten av blokkjeden. For eksempel jobber Blockstack med en arkitektur der det meste av applikasjonsdata og logikk er lagret utenfor kjeden.
La oss først se på en mer tradisjonell tilnærming, som bruker blockchain som et direkte mellomledd mellom applikasjonsbrukere, og som ikke skalerer spesielt godt.
Tilnærming #1: Blockchain som backend
For å gjøre ting klarere, la oss ta hotellbransjen som eksempel. Dette er en enorm bransje der mellommenn som Booking.com, for å koble sammen gjester og hoteller.
I enhver situasjon der vi ønsker å beseire en slik mellommann ved å bruke denne tilnærmingen, vil vi prøve å gjenskape forretningslogikken ved hjelp av smarte kontrakter på en blokkjede som Ethereum.
Åpen kildekode smarte kontrakter som kjører på "verdensdatamaskinen" kan koble selgere til forbrukere uten en tredjepart i mellom, og til slutt redusere gebyrene og provisjonene som belastes av mellommannen.
Som vist på bildet nedenfor bruker hoteller en desentralisert applikasjon for å legge ut informasjon på blokkjeden om rom, tilgjengelighet og priser på ukedager eller helger, og kanskje til og med en beskrivelse av rommene med all annen relevant informasjon.
Alle som ønsker å bestille et rom bruker denne applikasjonen til å søke etter hoteller og rom hostet på blockchain. Når brukeren velger et rom, gjøres reservasjonen ved å sende den nødvendige mengden tokens til hotellet som et depositum. Og som svar oppdaterer den smarte kontrakten informasjonen i blokkjeden om at nummeret ikke lenger er tilgjengelig.
Det er to sider av skalerbarhetsproblemet med denne tilnærmingen. Først det maksimale antallet transaksjoner per sekund. For det andre mengden data som kan lagres på blokkjeden.
La oss gjøre noen grove beregninger. Booking.com sier de har nesten 2 millioner hoteller registrert hos dem. La oss si at et gjennomsnittshotell har 10 rom og at hvert rom bestilles bare 20 ganger i året – det gir oss et gjennomsnitt på 13 bestillinger per sekund.
For å sette dette tallet i perspektiv, er det verdt å merke seg at Ethereum kan behandle omtrent 15 transaksjoner per sekund.
Samtidig er det verdt å tenke på at vår applikasjon også vil inneholde transaksjoner fra hoteller - for nedlasting og kontinuerlig oppdatering av informasjon om rommene deres. Hoteller oppdaterer romprisene svært ofte, noen ganger til og med daglig, og hver pris- eller beskrivelsesendring krever en transaksjon på blokkjeden.
Det er også størrelsesproblemer her - vekten av Ethereum-blokkjeden passerte nylig 2TB-merket. Hvis applikasjoner med denne tilnærmingen ble virkelig populære, ville Ethereum-nettverket bli ekstremt ustabilt.
Et slikt blokkjedebasert system kan ekskludere utenforstående på grunn av dets upartiskhet og mangel på sentralisering, de viktigste fordelene med blokkjedeteknologi. Men blokkjeden har også andre funksjoner - den er distribuert og ikke omskrevet, disse er utmerkede egenskaper, men du må betale for dem i hastighet og provisjon av transaksjoner.
Derfor må dapp-utviklere nøye vurdere om hver funksjon som bruker blokkjeden virkelig trenger distribusjon og ikke-skrivbarhet.
For eksempel: hva er fordelen med å distribuere hvert hotells data over hundrevis av maskiner rundt om i verden og lagre dem permanent der? Er det virkelig viktig at historiske data om rompriser og tilgjengelighet alltid er inkludert i blokkjeden? Sannsynligvis ikke.
Hvis vi begynner å stille spørsmål som disse, vil vi begynne å se at vi ikke nødvendigvis trenger alle de dyre blokkjedefunksjonene for alle funksjonene våre. Så, hva er alternativet?
Tilnærming #2: Blockstack-inspirert arkitektur
Selv om hovedvekten på applikasjoner der brukere er eiere av dataene deres (f.eks , , eller ), har blockstack også en filosofi om å bruke blokkjeden lett – bare når det er absolutt nødvendig. Hovedargumentet deres er at blockchain er treg og dyr, og derfor bør den kun brukes til enkelt- eller sjeldne transaksjoner. Resten av interaksjonen med applikasjoner bør skje gjennom peer-to-peer, dvs. brukere av desentraliserte applikasjoner må dele data direkte med hverandre, i stedet for gjennom blokkjeden. Tross alt ble de eldste og mest vellykkede desentraliserte applikasjonene som BitTorrent, e-post og Tor skapt før selve konseptet med blokkjede.
Venstre: Den første tilnærmingen, der brukere samhandler via blokkjeden. Høyre: Brukere samhandler direkte med hverandre, og blokkjeden brukes kun til identifikasjon og lignende.
La oss gå tilbake til eksempelet på hotellbestilling. Vi ønsker en upartisk, uavhengig og åpen protokoll for å koble gjester med hoteller. Vi ønsker med andre ord å fjerne den sentraliserte mellommannen. Vi trenger for eksempel ikke å stadig lagre rompriser i en felles distribuert reskontro.
Hvorfor lar vi ikke bare gjester og hoteller samhandle direkte i stedet for via blockchain. Hoteller kan lagre sine priser, romtilgjengelighet og all annen informasjon et sted hvor den vil være tilgjengelig for alle - for eksempel IPFS, Amazon S3, eller til og med deres egen lokale server. Dette er akkurat hva Blockstacks desentraliserte lagringssystem kalte . Den lar brukerne velge hvor de vil lagre dataene deres og kontrollere hvem som kan få tilgang til dem gjennom en tilnærming kalt .
For å etablere tillit er alle hotelldata signert kryptografisk av hotellet selv. Uavhengig av hvor disse dataene er lagret, kan dens integritet verifiseres ved å bruke de offentlige nøklene knyttet til hotellets identitet lagret på blokkjeden.
Når det gjelder Blockstack, lagres kun identitetsinformasjonen din på blokkjeden. Informasjon om hvordan du får tak i hver brukers data lagres i sonefiler og distribueres gjennom et peer-to-peer-nettverk ved bruk av noder. Og nok en gang trenger du ikke å stole på dataene som nodene gir, fordi du kan bekrefte ektheten ved å sammenligne den med hashen som er lagret i blokkjeden og andre brukere.
I en forenklet versjon av systemet vil gjestene bruke Blockstack peer-to-peer-nettverket til å søke etter hoteller og få informasjon om rommene deres. Og ektheten og integriteten til alle data du mottar kan verifiseres ved hjelp av offentlige nøkler og hashes lagret i Blockstack.
Denne arkitekturen er mer kompleks enn den første tilnærmingen og krever en mer omfattende infrastruktur. Faktisk er det akkurat her Blockstack kommer inn, og gir alle nødvendige komponenter for å lage et slikt desentralisert system.
Med denne arkitekturen lagrer vi kun data på blokkjeden som virkelig må distribueres og ikke overskrives. Når det gjelder Blockstack, trenger du kun transaksjoner på blokkjeden for å registrere og indikere hvor dataene dine skal lagres. Det kan hende du må foreta flere transaksjoner hvis du vil endre noe av denne informasjonen, men dette er ikke en gjentakende hendelse.
Dessuten kjører applikasjonslogikken, i motsetning til den første tilnærmingen, på klientsiden og ikke på smarte kontrakter. Dette lar utvikleren endre denne logikken uten kostbare eller noen ganger umulige smarte kontraktoppdateringer. Og ved å holde applikasjonsdata og logikk utenfor kjeden, kan desentraliserte applikasjoner oppnå ytelses- og skalerbarhetsnivåene til tradisjonelle sentraliserte systemer.
Konklusjon
Applikasjoner som kjører på Blockstack kan skaleres mye bedre enn konvensjonelle blokkjedeapplikasjoner, men det er en yngre tilnærming med egne problemer og ubesvarte spørsmål.
For eksempel, hvis en desentralisert applikasjon ikke kjører på smarte kontrakter, reduserer dette behovet for verktøytokens. Dette kan skape problemer for bedrifter med tanke på at ICO-er har vært hovedkilden til finansiering for desentraliserte applikasjoner (inkludert Blockstack selv)
Her er det også tekniske problemer. For eksempel er det relativt enkelt å implementere en hotellbestillingsfunksjon i en smart kontrakt, hvor det i en atomoperasjon gjøres romreservasjoner i bytte mot tokens. Og det er ikke veldig åpenbart hvordan booking vil fungere i en Blockstack-applikasjon uten smarte kontrakter.
Apper som retter seg mot globale markeder med potensial for millioner av brukere, må skaleres veldig godt for å lykkes. Det er en feil å stole utelukkende på blokkjeder for å oppnå dette nivået av skalerbarhet i nær fremtid. For å kunne konkurrere med store sentraliserte markedsaktører som Booking.com, bør desentraliserte applikasjonsutviklere vurdere alternative tilnærminger til å designe applikasjonene sine, slik som den som tilbys av Blockstack.
Kilde: www.habr.com