Ei, detsentraliseeritud rakenduse (dapp) käitamine plokiahelas ei taga edukat ettevõtlust. Tegelikult ei mõtle enamik kasutajaid isegi sellele, kas rakendus töötab plokiahelas – nad valivad lihtsalt toote, mis on odavam, kiirem ja lihtsam.

Kahjuks, isegi kui plokiahelal on oma unikaalsed omadused ja eelised, on enamik rakendusi, mis seda kasutavad, oluliselt kallimad, aeglasemad ja vähem arusaadavad kui nende tsentraliseeritud konkurendid.

Sageli leiab plokiahelaga ehitatud rakenduste whitepaper'itest lõike, kus öeldakse: "plokiahel on kallis ja ei suuda toetada vajalikku tehingute arvu sekundis. Õnneks töötab palju nutikaid inimesi plokiahela skaleerimise nimel ja meie rakenduse käivitamise ajaks muutub see piisavalt skaleeritavaks."

Lihtsas lõigus võib dapp arendaja loobuda sügavamast arutelust skaleerimise probleemide ja alternatiivsete lahenduste üle. See toob sageli kaasa ebaefektiivse arhitektuuri, kus rakenduse taust ja tuum on plokiahelas töötavad nutilepingud.

Siiski on veel katsetamata lähenemisviise detsentraliseeritud rakenduste arhitektuuris, mis võimaldavad oluliselt paremat skaleeritavust, vähendades sõltuvust plokiahelast. Näiteks Blockstack töötab arhitektuuri kallal, kus enamik rakenduse andmeid ja loogikat hoitakse plokiahlatest väljaspool.

Alustame traditsioonilisest lähenemisviisist, kus plokiahelat kasutatakse otsemootorina rakenduse kasutajate vahel ning mis ei suuda eriti hästi skaleeruda.

Lähenemine #1: Plokiahel kui taustsüsteem

Selgemaks tegemiseks vaatame hotellitööstust. See on suur tööstusharu, kus vahendajad nagu Booking.com võtavad suuri tasusid külaliste ja hotellide ühendamise eest.

Igas olukorras, kus me soovime sellist vahendajat ületada, kasutades seda lähenemist, püüame korrata tema äri loogikat, kasutades nutilepinguid sellisel plokiahelal nagu Ethereum.

Avaallikaga nutilepingud, mis töötavad "kõikide arvutite" peal, saavad ühendada müüjad ja tarbijad ilma vahefirma vahelesekkumiseta, mis lõpuks vähendab vahendaja nõutavaid tasusid ja teenustasusid.

Nagu allolevas pildis on näidatud, kasutavad hotellid detsentraliseeritud rakendust, et plokiahelas majutada teavet tubade, nende kättesaadavuse ja hindade kohta tööpäevadel või nädalavahetustel, ja võimalik, et isegi tubade kirjeldust koos kogu muu sobiva teabega.

Igaühe jaoks, kes soovib tuba broneerida, kasutab see rakendus plokiahelas hotellide ja tubade otsimiseks. Kui kasutaja valib toa, toimub broneerimine, saates vajalikud tokenid hotellile tagatisena. Vastuseks värskendab nutileping plokiahelas teavet, et tuba pole enam kättesaadav.

Selles lähenemises on kaks skaleerimise probleemi. Esiteks, maksimaalne tehingute arv sekundis. Teiseks, andmete maht, mida plokiahel suudab hoida.

Teeme siis umbkaudsed arvutused. Booking.com teatab, et neil on registreeritud peaaegu 2 miljonit hotelli. Oletame, et keskmiselt on hotellil 10 tuba ja igaüht broneeritakse ainult 20 korda aastas – see annab meile keskmiselt 13 broneeringut sekundis.

Selle numbri hindamiseks on oluline mainida, et Ethereum suudab töödelda ligikaudu 15 tehingut sekundis.

Samuti tuleks arvesse võtta, et meie rakenduses on ka hotellide tehingud – nende tubade teabe laadimiseks ja pidevaks värskendamiseks. Hotellid värskendavad tubade hindu väga tihti, mõnikord isegi igapäevaselt, ja iga muutus hinnas või kirjelduses nõuab plokiahelas tehingut.

Siin on ka mure suuruse üle – Ethereum plokiahela kaal on hiljuti ületanud 2TB. Kui sarnased lähenemised tõeliselt populaarseks saavad, muutuks Ethereum võrgu äärmiselt ebastabiilseks.

Selline plokiahelas põhinev süsteem võib kõrvaldada kolmandad osalised oma erapooletuse ja detsentraliseerimise tõttu - plokiahela tehnoloogia peamised eelised. Kuid plokiahelal on ka muid omadusi – see on jaotatud ja kirjutamiskindel, need on suurepärased omadused, kuid nende eest tuleb maksta kiirus ja tehingute tasud.

Seetõttu peavad dapp arendajad hoolikalt kaaluma, kas iga funktsioon, mis kasutab plokiahela tehnoloogiat, vajab tõesti jaotatud ja kirjutamiskindlat lähenemist.

Näiteks: milline on iga hotelli andmete jaotamise eelis sadade masinate vahel üle kogu maailma ja nende pidev säilitamine seal? Kas ajalugu hindade ja tubade saadavuse kohta peab tõesti olema igavesti plokiahelas? Ehk mitte.

Kui hakkame selliseid küsimusi esitama, näeme, et meil ei ole vajadust kõigi plokiahela kallite omaduste järele kõigi meie funktsioonide jaoks. Nii et mis on alternatiiv?

Lähenemine #2: Blockstack'i inspireeritud arhitektuur

Kuigi peamine fookus Blockstack on rakendustel, kus kasutajad on oma andmete omanikud (nt nagu Airtext, BentenSound, ImageOptimizer või Graphite), on blockstackil ka filosoofia plokiahela vähese kasutamise kohta - ainult siis, kui see on tõeliselt vajalik. Nende peamine argumendi kohaselt on plokiahel aeglane ja kallis, seega tuleb seda kasutada ainult üksikute või harvade toimingute jaoks. Ülejäänud rakendustega suhtlemine peaks toimuma peer-to-peer kaudu, see tähendab, et detsentraliseeritud rakenduste kasutajad peaksid andmeid vahetama otse üksteisega, mitte plokiahela kaudu. Lõppude lõpuks loodi kõige vanemad ja edukamad detsentraliseeritud rakendused, nagu BitTorrent, e-post ja Tor, juba enne plokiahela kontsepti.

Vasakul: esimene lähenemine, kus kasutajad suhtlevad plokiahela kaudu. Paremal: kasutajad suhtlevad otse üksteisega, plokiahelat kasutatakse ainult identifitseerimiseks ja sarnaseks..

Naaseme hotelliteeninduse näite juurde. Me soovime objektiivset, sõltumatut ja avatud protokolli külaliste ja hotellide ühendamiseks. Teisisõnu, me soovime kõrvaldada tsentraliseeritud vahendaja. Meil ei ole vajadust näiteks pidevalt hoida tubade hindasid ühises jaotatud registris.

Miks mitte lubada külalistel ja hotellidel otse suhelda, mitte plokiahela kaudu? Hotellid saavad hoida oma hindade, tubade saadavuse ja muu informatsiooni kuskil, kus see on kõigile saadaval - näiteks IPFS, Amazon S3 või isegi nende enda kohalikul serveril. See on täpselt see, mida pakub Blockstacki detsentraliseeritud andmesalvestussüsteem, mille nimi on Gaia. See võimaldab kasutajatel valida, kus nad soovivad oma andmeid hoida ja kontrollida, kellel võib neile ligipääs olla, lähenemisviisi kaudu, mida nimetatakse mitmikruumiliseks salvestuseks.

Krediidi tagamiseks allkirjastab iga hotelli andmed krüptograafiliselt hotell ise. Ükskõik, kus need andmed on hoitud, saab nende terviklikkust kontrollida kasutades avatud võtmeid, mis on seotud selle hotelli identifitseerimisega, mis on salvestatud plokiahelas.

Blockstacki puhul salvestatakse plokiahelas ainult teie identifitseerimisinformatsioon. Informatsioon selle kohta, kuidas saada iga kasutaja andmeid, hoitakse tsoonifailides (zone files) ja levitatakse peer-to-peer võrgus sõlmede kaudu. Ja veel kord - te ei pea uskuma sõlmede edastatud andmetesse, sest saate neid autentida, võrreldes neid plokiahelas ja teiste kasutajate juures hoitavatega.

Lihtsustatud süsteemi puhul kasutavad külalised Blockstacki peer-to-peer võrku hotellide leidmiseks ja nende tubade kohta teabe saamiseks. Kõikide saadud andmete ehtsust ja terviklikkust saab kontrollida kasutades avalikke võtmeid ja hashe, mis on salvestatud virtuaalses plokiahelas Blockstack.

See arhitektuur on keerukam kui esimene lähenemine ja nõuab keerukamat infrastruktuuri. Tegelikult on see just see, kus Blockstack tuleb appi, pakkudes kõik vajalikke komponente sellise detsentraliseeritud süsteemi loomiseks.

Sellise arhitektuuri puhul salvestame plokiahelas ainult andmed, mis peavad tõeliselt olema jaotatud ja mitte üle kirjutatavad. Blockstacki puhul vajate plokiahelas tehinguid ainult registreerimiseks ja märkimiseks, kus teie andmed peaksid asuma. Te võite vajada rohkem tehinguid, kui soovite midagi muuta, aga see ei ole korduv sündmus.

Rohkemgi veel, rakenduse loogika, erinevalt esimesest lähenemisest, töötab kliendi poolel, mitte nutilepingutes. See võimaldab arendajal seda loogikat muuta ilma kallite või mõnikord isegi võimatute nutilepingu värskendusteta. Ja hoides andmeid ja rakenduse loogikat mitte plokiahelas, saavad detsentraliseeritud rakendused saavutada traditsiooniliste tsentraliseeritud süsteemide taseme jõudlust ja skaleeritavust.

Kokkuvõte

Blockstackil töötavad rakendused saavad skaleeruda oluliselt paremini kui tavalised plokiahela rakendused, kuid see on noorem lähenemine, millel on oma probleemid ja vastamata küsimused.

Kui näiteks detsentraliseeritud rakendus ei tööta nutilepingute peal, siis väheneb vajadus utiliit-tokenite järele. See võib tekitada probleemide äri jaoks, arvestades, et ICO-d olid peamine rahastamisallikas detsentraliseeritud rakenduste jaoks (sealhulgas Blockstacki jaoks).

Siin on ka tehnilised probleemid. Näiteks on suhteliselt lihtne rakendada hotelli broneerimise funktsiooni nutilepingus, kus atomaarse toimingu käigus broneeritakse numbrid tokenite vahetamisega. Kuid ei ole väga selge, kuidas broneerimine toimiks Blockstacki rakenduses ilma nutilepinguteta.

Rakendused, mis sihivad globaalseid turge ja millel on potentsiaal miljoneid kasutajaid, peavad olema väga hästi skaleeritavad, et olla edukad. On vale tugineda ainult plokiahelatele, et saavutada selline skaleeritavus lähitulevikus. Konkurentsivõime suurte tsentraliseeritud turu mängijate, nagu Booking.com, kõrval nõuab detsentraliseeritud rakenduste arendajatelt alternatiivsete lähenemisviiside kaalumist oma rakenduste projekteerimisel, näiteks Blockstacki pakutavat.

Allikas: habr.com