Ei, detsentraliseeritud rakenduse (dapp) käivitamine plokiahelas ei too kaasa edukat äri. Tegelikult enamik kasutajaid isegi ei mõtle sellele, kas rakendus töötab plokiahelas – nad lihtsalt valivad toote, mis on odavam, kiirem ja lihtsam.
Kahjuks, isegi kui plokiahelal on oma ainulaadsed funktsioonid ja eelised, on enamik sellel töötavaid rakendusi palju kallimad, aeglasemad ja vähem intuitiivsed kui nende tsentraliseeritud konkurendid.
Üsna sageli võib plokiahelale üles ehitatud rakenduste valgetest paberitest leida lõigu, mis ütleb: "Plokiahel on kallis ega suuda toetada vajalikku arvu tehinguid sekundis. Õnneks tegelevad paljud targad inimesed plokiahela skaleerimisega ja meie rakenduse käivitamise ajaks muutub see üsna skaleeritavaks.
Ühe lihtsa lõiguga saab dappi arendaja loobuda mastaapsuse probleemide põhjalikumast arutelust ja probleemide alternatiivsetest lahendustest. See viib sageli ebatõhusa arhitektuurini, kus plokiahelas töötavad nutikad lepingud toimivad rakenduse taustaprogrammina ja tuumana.
Siiski on detsentraliseeritud rakendusarhitektuurile veel testimata lähenemisviise, mis võimaldavad palju paremat skaleeritavust, vähendades sõltuvust plokiahelast. Näiteks töötab Blockstack arhitektuuri kallal, kus suurem osa rakenduse andmetest ja loogikast on salvestatud väljaspool ahelat.
Vaatame esmalt traditsioonilisemat lähenemist, mis kasutab plokiahelat otsese vahendajana rakenduste kasutajate vahel ja mis ei skaleeru eriti hästi.
Lähenemisviis nr 1: Blockchain kui taustaprogramm
Asjade selgemaks muutmiseks võtame näiteks hotellitööstuse. See on tohutu tööstusharu, kus vahendajad, nagu Booking.com, külaliste ja hotellide ühendamiseks.
Igas olukorras, kus me tahame sellisest vahendajast seda lähenemisviisi kasutades võita, proovime kopeerida tema äriloogikat, kasutades nutikaid lepinguid plokiahelas, näiteks Ethereum.
"Maailmaarvutis" töötavad avatud lähtekoodiga nutikad lepingud võivad ühendada kaupmehed tarbijatega ilma kolmanda osapooleta, vähendades lõpuks vahendaja poolt võetavaid tasusid ja vahendustasusid.
Nagu on näidatud alloleval pildil, kasutavad hotellid detsentraliseeritud rakendust, et postitada plokiahelasse teavet tubade, nende saadavuse ja hindade kohta tööpäeviti või nädalavahetustel ning võib-olla isegi tubade kirjelduse koos kogu muu asjakohase teabega.
Igaüks, kes soovib tuba broneerida, kasutab seda rakendust plokiahelas hostitud hotellide ja tubade otsimiseks. Kui kasutaja on toa valinud, tehakse broneering, saates hotellile sissemaksena vajaliku koguse žetoone. Ja vastuseks värskendab nutikas leping plokiahelas olevat teavet, et number pole enam saadaval.
Selle lähenemisviisi mastaapsuse probleemil on kaks külge. Esiteks maksimaalne tehingute arv sekundis. Teiseks andmete hulk, mida saab plokiahelasse salvestada.
Teeme mõned ligikaudsed arvutused. Booking.com ütleb, et neil on registreeritud peaaegu 2 miljonit hotelli. Oletame, et keskmises hotellis on 10 tuba ja igaüks neist broneeritakse vaid 20 korda aastas – see annab meile keskmiselt 13 broneeringut sekundis.
Selle numbri perspektiivi vaatamiseks tasub märkida, et Ethereum suudab töödelda umbes 15 tehingut sekundis.
Samas tasub arvestada, et meie rakendus hakkab sisaldama ka tehinguid hotellidest – nende tubade info allalaadimiseks ja pidevaks uuendamiseks. Hotellid uuendavad tubade hindu väga sageli, mõnikord isegi iga päev ning iga hinna või kirjelduse muudatus nõuab tehingut plokiahelas.
Siin on ka suuruseprobleemid – Ethereumi plokiahela kaal ületas hiljuti 2TB piiri. Kui selle lähenemisviisiga rakendused muutuksid tõeliselt populaarseks, muutuks Ethereumi võrk äärmiselt ebastabiilseks.
Selline plokiahelal põhinev süsteem võib oma erapooletuse ja tsentraliseerituse puudumise tõttu välistada kõrvalised isikud, mis on plokiahela tehnoloogia peamised eelised. Kuid plokiahelal on ka muid funktsioone - seda levitatakse ja ei kirjutata ümber, need on suurepärased omadused, kuid nende eest peate maksma tehingute kiiruse ja vahendustasu eest.
Seetõttu peavad dappide arendajad hoolikalt hindama, kas iga plokiahelat kasutav funktsioon vajab tõesti levitamist ja mittekirjutamist.
Näiteks: mis kasu on iga hotelli andmete levitamisest sadade masinate vahel üle maailma ja nende püsivalt sinna salvestamisest? Kas on tõesti oluline, et plokiahelas sisalduksid alati ajaloolised andmed tubade hindade ja saadavuse kohta? Ilmselt mitte.
Kui hakkame selliseid küsimusi esitama, hakkame nägema, et me ei vaja kõigi oma funktsioonide jaoks tingimata kõiki kalleid plokiahela funktsioone. Niisiis, mis on alternatiiv?
Lähenemisviis nr 2: Blockstackist inspireeritud arhitektuur
Kuigi põhirõhk rakendustes, milles kasutajad on nende andmete omanikud (nt , , või ), on blockstackil ka filosoofia kasutada plokiahelat kergekäeliselt – ainult siis, kui see on hädavajalik. Nende peamine argument on see, et plokiahel on aeglane ja kallis ning seetõttu tuleks seda kasutada ainult üksikute või harvaesinevate tehingute jaoks. Ülejäänud suhtlus rakendustega peaks toimuma peer-to-peer kaudu, s.t. detsentraliseeritud rakenduste kasutajad peavad andmeid jagama otse üksteisega, mitte plokiahela kaudu. Vanimad ja edukaimad detsentraliseeritud rakendused nagu BitTorrent, email ja Tor loodi ju enne plokiahela enda kontseptsiooni.
Vasakul: esimene lähenemisviis, mille puhul kasutajad suhtlevad plokiahela kaudu. Paremal: kasutajad suhtlevad üksteisega otse ja plokiahelat kasutatakse ainult tuvastamiseks jms.
Läheme tagasi hotelli broneerimise näite juurde. Soovime erapooletut, sõltumatut ja avatud protokolli külaliste ühendamiseks hotellidega. Teisisõnu tahame eemaldada tsentraliseeritud vahendaja. Meil ei ole vaja näiteks tubade hindu pidevalt ühises hajutatud pearaamatus hoida.
Miks mitte lubada külalistel ja hotellidel suhelda otse, mitte plokiahela kaudu. Hotellid saavad salvestada oma hindu, tubade saadavust ja muud teavet kuskil, kus see on kõigile kättesaadav – näiteks IPFS, Amazon S3 või isegi oma kohalik server. Täpselt seda nimetas Blockstacki detsentraliseeritud salvestussüsteem . See võimaldab kasutajatel valida, kuhu nad soovivad oma andmeid salvestada, ja kontrollida, kes pääseb neile juurde nn lähenemise kaudu .
Usalduse loomiseks allkirjastab hotell kõik hotelliandmed krüptograafiliselt. Sõltumata sellest, kus neid andmeid hoitakse, saab nende terviklikkust kontrollida, kasutades plokiahelasse salvestatud selle hotelli identiteediga seotud avalikke võtmeid.
Blockstacki puhul salvestatakse plokiahelasse ainult teie isikuandmed. Teave iga kasutaja andmete hankimise kohta salvestatakse tsoonifailidesse ja levitatakse sõlmede abil peer-to-peer võrgu kaudu. Ja veel kord, te ei pea usaldama andmeid, mida sõlmed annavad, sest saate kontrollida nende autentsust, võrreldes neid räsidega, mis on salvestatud plokiahelasse ja teistele kasutajatele.
Süsteemi lihtsustatud versioonis kasutavad külalised hotellide otsimiseks ja oma tubade kohta teabe hankimiseks Blockstacki peer-to-peer võrku. Ja kõigi saadud andmete autentsust ja terviklikkust saab kontrollida avalike võtmete ja salvestatud räsidega Blockstack.
See arhitektuur on keerulisem kui esimene lähenemisviis ja nõuab terviklikumat infrastruktuuri. Tegelikult on just see koht Blockstack, mis pakub sellise detsentraliseeritud süsteemi loomiseks kõiki vajalikke komponente.
Selle arhitektuuriga salvestame plokiahelasse ainult neid andmeid, mida tuleb tegelikult levitada, mitte üle kirjutada. Blockstacki puhul vajate plokiahelas tehinguid ainult selleks, et registreeruda ja näidata, kuhu teie andmed tuleks salvestada. Kui soovite seda teavet muuta, peate võib-olla tegema rohkem tehinguid, kuid see ei ole korduv sündmus.
Lisaks töötab rakenduse loogika erinevalt esimesest lähenemisviisist kliendi poolel, mitte nutikatel lepingutel. See võimaldab arendajal seda loogikat muuta ilma kulukate või mõnikord isegi võimatute nutikate lepingute uuendusteta. Ja hoides rakenduste andmeid ja loogikat ahelast väljas, võivad detsentraliseeritud rakendused saavutada traditsiooniliste tsentraliseeritud süsteemide jõudluse ja mastaapsuse taseme.
Järeldus
Blockstackis töötavaid rakendusi saab skaleerida palju paremini kui tavapäraseid plokiahelarakendusi, kuid see on noorem lähenemisviis, millel on oma probleemid ja vastuseta küsimused.
Näiteks kui detsentraliseeritud rakendus ei tööta nutikate lepingutega, vähendab see vajadust utiliidi lubade järele. See võib tekitada probleeme ettevõtetele, arvestades, et ICO-d on olnud detsentraliseeritud rakenduste (sealhulgas Blockstacki enda) peamine rahastamisallikas.
Siin on ka tehnilisi probleeme. Näiteks nutikas lepingus on suhteliselt lihtne rakendada hotellibroneerimisfunktsiooni, kus aatomioperatsioonis tehakse tubade broneerimine žetoonide vastu. Ja pole eriti ilmne, kuidas broneerimine töötab Blockstacki rakenduses ilma nutikate lepinguteta.
Rakendused, mis on suunatud globaalsetele turgudele ja millel on potentsiaali miljonitele kasutajatele, peavad edu saavutamiseks väga hästi skaleerima. Selle mastaapsuse taseme saavutamiseks lähitulevikus on viga loota ainult plokiahelatele. Et konkureerida suurte tsentraliseeritud turuosalistega, nagu Booking.com, peaksid detsentraliseeritud rakenduste arendajad oma rakenduste kujundamisel kaaluma alternatiivseid lähenemisviise, näiteks Blockstacki pakutavat.
Allikas: www.habr.com