Hoe om 'n gedesentraliseerde toepassing te skep wat skaal? Gebruik minder blokketting

Nee, die bekendstelling van 'n gedesentraliseerde toepassing (dapp) op die blokketting sal nie tot 'n suksesvolle besigheid lei nie. Trouens, die meeste gebruikers dink nie eers daaraan of die toepassing op die blokketting loop nie - hulle kies eenvoudig 'n produk wat goedkoper, vinniger en eenvoudiger is.

Ongelukkig, selfs al het blockchain sy eie unieke kenmerke en voordele, is die meeste toepassings wat daarop loop, baie duurder, stadiger en minder intuïtief as hul gesentraliseerde mededingers.

Hoe om 'n gedesentraliseerde toepassing te skep wat skaal? Gebruik minder blokketting

Dikwels kan jy in die witskrifte van toepassings wat op die blokketting gebou is 'n paragraaf vind wat sê: "Die blokketting is duur en kan nie die vereiste aantal transaksies per sekonde ondersteun nie. Gelukkig werk baie slim mense daaraan om die blokketting te skaal en teen die tyd dat ons toepassing begin, sal dit redelik skaalbaar word.”

In een eenvoudige paragraaf kan 'n dapp-ontwikkelaar 'n dieper bespreking van skaalbaarheidskwessies en alternatiewe oplossings vir probleme laat vaar. Dit lei dikwels tot 'n ondoeltreffende argitektuur waar slim kontrakte wat op die blokketting loop, dien as die agterkant en kern van die toepassing.

Daar is egter nog ongetoetste benaderings tot gedesentraliseerde toepassingsargitektuur wat baie beter skaalbaarheid moontlik maak deur afhanklikheid van die blokketting te verminder. Blockstack werk byvoorbeeld aan 'n argitektuur waar die meeste van die toepassingsdata en logika buite die ketting gestoor word.

Kom ons kyk eers na 'n meer tradisionele benadering, wat blokketting as 'n direkte tussenganger tussen toepassinggebruikers gebruik, en wat nie besonder goed skaal nie.

Benadering #1: Blockchain as 'n backend

Om dinge duideliker te maak, kom ons neem die hotelbedryf as voorbeeld. Dit is 'n groot bedryf waarin tussengangers soos Booking.com, hulle vra 'n groot fooi om gaste en hotelle te verbind.

In enige situasie waar ons so 'n tussenganger met hierdie benadering wil verslaan, sal ons probeer om sy besigheidslogika te herhaal deur slim kontrakte op 'n blokketting soos Ethereum te gebruik.

Oopbron-slimkontrakte wat op die "wêreldrekenaar" loop, kan handelaars met verbruikers verbind sonder 'n derde party tussenin, wat uiteindelik die fooie en kommissies wat deur die tussenganger gehef word, verminder.

Soos in die prent hieronder getoon, gebruik hotelle 'n gedesentraliseerde toepassing om inligting oor kamers, hul beskikbaarheid en pryse op weeksdae of naweke op die blokketting te plaas, en miskien selfs 'n beskrywing van die kamers met alle ander relevante inligting.

Hoe om 'n gedesentraliseerde toepassing te skep wat skaal? Gebruik minder blokketting

Enigiemand wat 'n kamer wil bespreek, gebruik hierdie toepassing om te soek na hotelle en kamers wat op die blokketting aangebied word. Sodra die gebruiker 'n kamer kies, word die bespreking gemaak deur die vereiste hoeveelheid tokens na die hotel te stuur as 'n deposito. En in reaksie hierop werk die slim kontrak die inligting in die blokketting op dat die nommer nie meer beskikbaar is nie.

Daar is twee kante aan die skaalbaarheidsprobleem met hierdie benadering. Eerstens, die maksimum aantal transaksies per sekonde. Tweedens, die hoeveelheid data wat op die blokketting gestoor kan word.

Kom ons doen 'n paar rowwe berekeninge. Booking.com sê hulle het byna 2 miljoen hotelle wat by hulle geregistreer is. Kom ons sê die gemiddelde hotel het 10 kamers en elkeen word net 20 keer per jaar bespreek - dit gee ons 'n gemiddeld van 13 besprekings per sekonde.

Om hierdie getal in perspektief te plaas, is dit opmerklik dat Ethereum ongeveer 15 transaksies per sekonde kan verwerk.

Terselfdertyd is dit die moeite werd om te oorweeg dat ons toepassing ook transaksies van hotelle sal bevat - vir die aflaai en voortdurende opdatering van inligting oor hul kamers. Hotelle werk kamerpryse baie gereeld op, soms selfs daagliks, en elke prys- of beskrywingsverandering vereis 'n transaksie op die blokketting.

Daar is ook grootteprobleme hier - die gewig van die Ethereum-blokketting het onlangs die 2TB-merk verbygesteek. As toepassings met hierdie benadering werklik gewild word, sal die Ethereum-netwerk uiters onstabiel word.

So 'n blokketting-gebaseerde stelsel kan buitestaanders uitsluit weens sy onpartydigheid en gebrek aan sentralisasie, die belangrikste voordele van blokkettingtegnologie. Maar die blokketting het ook ander kenmerke - dit word versprei en nie herskryf nie, dit is uitstekende eienskappe, maar jy moet daarvoor betaal in die spoed en kommissie van transaksies.

Daarom moet dapp-ontwikkelaars noukeurig evalueer of elke kenmerk wat die blokketting gebruik, werklik verspreiding en nie-skryfbaarheid benodig.

Byvoorbeeld: wat is die voordeel daarvan om elke hotel se data oor honderde masjiene regoor die wêreld te versprei en dit permanent daar te stoor? Is dit regtig belangrik dat historiese data oor kamertariewe en beskikbaarheid altyd by die blokketting ingesluit word? Waarskynlik nie.

As ons vrae soos hierdie begin vra, sal ons begin sien dat ons nie noodwendig al die duur blokkettingkenmerke vir al ons funksies nodig het nie. So, wat is die alternatief?

Benadering #2: Blockstack-geïnspireerde argitektuur

Alhoewel die hoofklem Blockstack op toepassings waarin gebruikers die eienaars van hul data is (byvoorbeeld, soos Lugteks, BentenKlank, Beeld optimeerder of grafiet), blockstack het ook 'n filosofie om die blokketting liggies te gebruik—slegs wanneer dit absoluut noodsaaklik is. Hul hoofargument is dat blokketting stadig en duur is, en daarom slegs vir enkele of ongereelde transaksies gebruik moet word. Die res van die interaksie met toepassings moet deur eweknie geskied, m.a.w. gebruikers van gedesentraliseerde toepassings moet data direk met mekaar deel, eerder as deur die blokketting. Die oudste en suksesvolste gedesentraliseerde toepassings soos BitTorrent, e-pos en Tor is immers geskep voor die konsep van blockchain self.

Hoe om 'n gedesentraliseerde toepassing te skep wat skaal? Gebruik minder blokketting
Links: Die eerste benadering, waarin gebruikers via die blokketting interaksie het. Regs: Gebruikers kommunikeer direk met mekaar, en die blokketting word slegs vir identifikasie en dies meer gebruik.

Kom ons gaan terug na die hotelbesprekingsvoorbeeld. Ons wil 'n onpartydige, onafhanklike en oop protokol hê om gaste met hotelle te verbind. Met ander woorde, ons wil die gesentraliseerde middelman verwyder. Ons hoef byvoorbeeld nie voortdurend kamerpryse in 'n gemeenskaplike verspreide grootboek te stoor nie.

Hoekom laat ons nie net gaste en hotelle toe om direk te kommunikeer eerder as via blockchain nie. Hotelle kan hul pryse, kamerbeskikbaarheid en enige ander inligting iewers stoor waar dit vir almal toeganklik sal wees – byvoorbeeld IPFS, Amazon S3, of selfs hul eie plaaslike bediener. Dit is presies wat Blockstack se gedesentraliseerde bergingstelsel genoem het Gaia. Dit laat gebruikers toe om te kies waar hulle hul data gestoor wil hê en te beheer wie toegang daartoe kan kry deur middel van 'n benadering wat genoem word multi-gebruiker berging.

Om vertroue te vestig, word alle hoteldata kriptografies deur die hotel self onderteken. Ongeag waar hierdie data gestoor word, kan die integriteit daarvan geverifieer word met behulp van die publieke sleutels wat verband hou met daardie hotel se identiteit wat op die blokketting gestoor is.

In die geval van Blockstack word slegs jou identiteitsinligting op die blokketting gestoor. Inligting oor hoe om elke gebruiker se data te bekom, word in sonelêers gestoor en deur 'n eweknie-netwerk met behulp van nodusse versprei. En weereens, jy hoef nie die data wat die nodusse gee, te vertrou nie, want jy kan die egtheid daarvan verifieer deur dit te vergelyk met die hashes wat in die blockchain en ander gebruikers gestoor word.

In 'n vereenvoudigde weergawe van die stelsel sal gaste die Blockstack-eweknie-netwerk gebruik om hotelle te soek en inligting oor hul kamers te bekom. En die egtheid en integriteit van alle data wat jy ontvang, kan geverifieer word met behulp van publieke sleutels en hashes wat in virtuele stroombaan Blokstapel.

Hierdie argitektuur is meer kompleks as die eerste benadering en vereis 'n meer omvattende infrastruktuur. Trouens, dit is presies waar Blockstack inkom, wat al die nodige komponente verskaf om so 'n gedesentraliseerde stelsel te skep.

Hoe om 'n gedesentraliseerde toepassing te skep wat skaal? Gebruik minder blokketting

Met hierdie argitektuur stoor ons net data op die blokketting wat regtig versprei moet word en nie oorskryf moet word nie. In die geval van Blockstack het jy net transaksies op die blokketting nodig om te registreer en aan te dui waar jou data gestoor moet word. Jy sal dalk meer transaksies moet doen as jy enige van hierdie inligting wil verander, maar dit is nie 'n herhalende gebeurtenis nie.

Boonop loop die toepassingslogika, in teenstelling met die eerste benadering, aan die kliëntkant en nie op slim kontrakte nie. Dit stel die ontwikkelaar in staat om hierdie logika te verander sonder duur of soms selfs onmoontlike slimkontrakopdaterings. En deur toepassingsdata en logika buite die ketting te hou, kan gedesentraliseerde toepassings die werkverrigting en skaalbaarheidsvlakke van tradisionele gesentraliseerde stelsels bereik.

Gevolgtrekking

Toepassings wat op Blockstack loop, kan baie beter skaal as konvensionele blokkettingtoepassings, maar dit is 'n jonger benadering met sy eie probleme en onbeantwoorde vrae.

Byvoorbeeld, as 'n gedesentraliseerde toepassing nie op slim kontrakte loop nie, verminder dit die behoefte aan nutsbewyse. Dit kan probleme vir besighede veroorsaak, aangesien ICO's die hoofbron van befondsing vir gedesentraliseerde toepassings was (insluitend Blockstack self)

Hier is ook tegniese probleme. Dit is byvoorbeeld relatief maklik om 'n hotelbesprekingsfunksie in 'n slim kontrak te implementeer, waar in 'n atoomoperasie kamerbesprekings gemaak word in ruil vir tokens. En dit is nie baie duidelik hoe bespreking sal werk in 'n Blockstack-toepassing sonder slim kontrakte nie.

Programme wat globale markte teiken met die potensiaal vir miljoene gebruikers, moet baie goed skaal om suksesvol te wees. Dit is 'n fout om net op blokkettings staat te maak om hierdie vlak van skaalbaarheid in die nabye toekoms te bereik. Om met groot gesentraliseerde markspelers soos Booking.com te kan meeding, moet gedesentraliseerde toepassingsontwikkelaars alternatiewe benaderings tot die ontwerp van hul toepassings oorweeg, soos die een wat deur Blockstack aangebied word.

Bron: will.com

Voeg 'n opmerking