Ne, lanĉi malcentralizitan aplikon (dapp) sur la blokĉeno ne kondukos al sukcesa komerco. Fakte, plej multaj uzantoj eĉ ne pensas, ĉu la aplikaĵo funkcias sur la blokĉeno - ili simple elektas produkton, kiu estas pli malmultekosta, pli rapida kaj pli simpla.
Bedaŭrinde, eĉ se blokĉeno havas siajn proprajn unikajn funkciojn kaj avantaĝojn, plej multaj aplikoj, kiuj funkcias sur ĝi, estas multe pli multekostaj, pli malrapidaj kaj malpli intuiciaj ol siaj centralizitaj konkurantoj.
Sufiĉe ofte en la blankpaperoj de aplikoj, kiuj estas konstruitaj sur la blokĉeno, vi povas trovi alineon, kiu diras: "La blokĉeno estas multekosta kaj ne povas subteni la postulatan nombron da transakcioj por sekundo. Feliĉe, multaj inteligentaj homoj laboras pri skalado de la blokĉeno kaj kiam nia aplikaĵo lanĉos, ĝi fariĝos sufiĉe skalebla."
En unu simpla alineo, dapp-programisto povas rezigni pri pli profunda diskuto pri skaleblo-problemoj kaj alternativaj solvoj al problemoj. Ĉi tio ofte kondukas al malefika arkitekturo, kie inteligentaj kontraktoj kurantaj sur la blokĉeno funkcias kiel la backend kaj kerno de la aplikaĵo.
Tamen, ekzistas ankoraŭ neprovitaj aliroj al malcentralizita aplika arkitekturo, kiuj permesas multe pli bonan skaleblon reduktante dependecon de la blokĉeno. Ekzemple, Blockstack laboras pri arkitekturo kie la plej multaj el la aplikaj datumoj kaj logiko estas stokitaj eksterĉene.
Ni unue rigardu pli tradician aliron, kiu uzas blokĉenon kiel rektan peranton inter aplikaĵuzantoj, kaj kiu ne skalas precipe bone.
Aliro #1: Blokoĉeno kiel Backend
Por pliklarigi aferojn, ni prenu la hotelindustrion kiel ekzemplon. Ĉi tio estas grandega industrio en kiu perantoj kiel Booking.com, por konekti gastojn kaj hotelojn.
En ajna situacio, kie ni volas venki tian peranton uzante ĉi tiun aliron, ni provos reprodukti lian komercan logikon uzante inteligentajn kontraktojn sur blokĉeno kiel Ethereum.
Malfermfontaj inteligentaj kontraktoj kurantaj sur la "monda komputilo" povas ligi komercistojn al konsumantoj sen tria partio intere, finfine reduktante la kotizojn kaj komisionojn ŝargitajn de la peranto.
Kiel montrite en la suba bildo, hoteloj uzas malcentralizitan aplikaĵon por afiŝi en la blokĉeno informojn pri ĉambroj, ilia havebleco kaj prezoj en labortagoj aŭ semajnfinoj, kaj eble eĉ priskribo de la ĉambroj kun ĉiuj aliaj rilataj informoj.
Ĉiu, kiu volas rezervi ĉambron, uzas ĉi tiun aplikaĵon por serĉi hotelojn kaj ĉambrojn gastigitajn sur la blokĉeno. Post kiam la uzanto elektas ĉambron, la rezervado estas farita sendante la postulatan kvanton da ĵetonoj al la hotelo kiel deponejo. Kaj en respondo, la inteligenta kontrakto ĝisdatigas la informojn en la blokĉeno, ke la nombro ne plu disponeblas.
Estas du flankoj al la skalebloproblemo kun ĉi tiu aliro. Unue, la maksimuma nombro da transakcioj por sekundo. Due, la kvanto de datumoj, kiuj povas esti stokitaj sur la blokĉeno.
Ni faru kelkajn malglatajn kalkulojn. Booking.com diras, ke ili havas preskaŭ 2 milionojn da hoteloj registritaj kun ili. Ni diru, ke la averaĝa hotelo havas 10 ĉambrojn kaj ĉiu estas rezervita nur 20 fojojn jare - tio donas al ni mezumon de 13 rezervoj sekundo.
Por meti ĉi tiun nombron en perspektivon, indas noti, ke Ethereum povas procesi proksimume 15-transakciojn por sekundo.
Samtempe, indas konsideri, ke nia aplikaĵo ankaŭ enhavos transakciojn de hoteloj - por elŝuti kaj konstante ĝisdatigi informojn pri iliaj ĉambroj. Hoteloj ĝisdatigas ĉambrajn prezojn tre ofte, foje eĉ ĉiutage, kaj ĉiu prezo aŭ priskriba ŝanĝo postulas transakcion sur la blokĉeno.
Estas ankaŭ grandecoj ĉi tie - la pezo de la blokĉeno de Ethereum ĵus pasis la markon de 2TB. Se aplikoj kun ĉi tiu aliro iĝus vere popularaj, la reto Ethereum fariĝus ekstreme malstabila.
Tia bloko-bazita sistemo povas ekskludi eksterulojn pro sia nepartieco kaj manko de centraligo, la ĉefaj avantaĝoj de blokĉena teknologio. Sed la blokĉeno ankaŭ havas aliajn funkciojn - ĝi estas distribuita kaj ne reverkita, ĉi tiuj estas bonegaj trajtoj, sed vi devas pagi por ili en la rapideco kaj komisiono de transakcioj.
Tial, dapp-programistoj devas zorge taksi ĉu ĉiu funkcio uzanta la blokĉenon vere bezonas distribuon kaj ne-skribindecon.
Ekzemple: kio estas la avantaĝo de distribui la datumojn de ĉiu hotelo tra centoj da maŝinoj tra la mondo kaj konservi ĝin konstante? Ĉu vere gravas, ke historiaj datumoj pri ĉambraj tarifoj kaj havebleco ĉiam estas inkluzivitaj en la blokĉeno? Verŝajne ne.
Se ni komencos demandi tiajn demandojn, ni ekvidos, ke ni ne nepre bezonas ĉiujn multekostajn blokĉenajn funkciojn por ĉiuj niaj funkcioj. Do, kio estas la alternativo?
Aliro #2: Blockstack Inspirita Arkitekturo
Kvankam la ĉefa emfazo pri aplikoj en kiuj uzantoj estas la posedantoj de siaj datumoj (ekzemple, kiel ekzemple , , aŭ ), blockstack ankaŭ havas filozofion uzi la blokĉenon malpeze—nur kiam absolute necese. Ilia ĉefa argumento estas, ke blokĉeno estas malrapida kaj multekosta, kaj tial nur devus esti uzata por ununuraj aŭ maloftaj transakcioj. La resto de la interagado kun aplikoj devus okazi per kunulo-al-kunulo, t.e. uzantoj de malcentralizitaj aplikoj devas kunhavi datumojn rekte unu kun la alia, prefere ol per la blokĉeno. Post ĉio, la plej malnovaj kaj plej sukcesaj malcentralizitaj aplikoj kiel BitTorrent, retpoŝto kaj Tor estis kreitaj antaŭ la koncepto de blokĉeno mem.
Maldekstre: La unua aliro, en kiu uzantoj interagas per la blokĉeno. Ĝuste: Uzantoj interagas rekte unu kun la alia, kaj la blokĉeno estas uzata nur por identigo kaj similaĵoj.
Ni revenu al la hotela rezerva ekzemplo. Ni volas senpartian, sendependan kaj malfermitan protokolon por konekti gastojn kun hoteloj. Alivorte, ni volas forigi la centralizitan periston. Ni ne bezonas, ekzemple, konstante stoki ĉambrajn prezojn en komuna distribuita ĉeflibro.
Kial ni ne nur permesas gastojn kaj hotelojn interagi rekte prefere ol per blokĉeno. Hoteloj povas konservi siajn prezojn, ĉambran haveblecon kaj ajnan alian informon ie kie ĝi estos alirebla por ĉiuj - ekzemple, IPFS, Amazon S3, aŭ eĉ sia propra loka servilo. Ĝuste ĉi tio nomis la malcentralizita stokadosistemo de Blockstack . Ĝi permesas al uzantoj elekti kie ili volas konservi siajn datumojn kaj kontroli kiu povas aliri ĝin per aliro nomita .
Por establi fidon, ĉiuj hotelaj datumoj estas kriptografie subskribitaj de la hotelo mem. Sendepende de kie ĉi tiuj datumoj estas konservitaj, ĝia integreco povas esti kontrolita uzante la publikajn ŝlosilojn asociitajn kun la identeco de tiu hotelo stokita sur la blokĉeno.
En la kazo de Blockstack, nur viaj identecaj informoj estas konservitaj sur la blokĉeno. Informoj pri kiel akiri la datumojn de ĉiu uzanto estas stokitaj en zondosieroj kaj distribuitaj tra kunul-al-kunula reto uzanta nodojn. Kaj denove, vi ne bezonas fidi la datumojn, kiujn donas la nodoj, ĉar vi povas kontroli ĝian aŭtentikecon komparante ĝin kun la hashoj, kiuj estas stokitaj en la blokĉeno kaj aliaj uzantoj.
En simpligita versio de la sistemo, gastoj uzos la kunulan reton Blockstack por serĉi hotelojn kaj akiri informojn pri siaj ĉambroj. Kaj la aŭtentikeco kaj integreco de ĉiuj datumoj, kiujn vi ricevas, povas esti kontrolitaj per publikaj ŝlosiloj kaj hashoj stokitaj en Blockstack.
Ĉi tiu arkitekturo estas pli kompleksa ol la unua aliro kaj postulas pli ampleksan infrastrukturon. Fakte, ĉi tie estas ĝuste kie Blockstack eniras, provizante ĉiujn necesajn komponantojn por krei tian malcentralizitan sistemon.
Kun ĉi tiu arkitekturo, ni nur stokas datumojn pri la blokĉeno, kiu vere devas esti distribuata kaj ne anstataŭita. En la kazo de Blockstack, vi nur bezonas transakciojn sur la blokĉeno por registri kaj indiki kie viaj datumoj estu konservitaj. Vi eble bezonos fari pli da transakcioj se vi volas ŝanĝi iun ajn el ĉi tiuj informoj, sed ĉi tio ne estas ripetiĝanta evento.
Krome, la aplika logiko, kontraste al la unua aliro, funkcias ĉe la klienta flanko kaj ne sur inteligentaj kontraktoj. Ĉi tio permesas al la programisto ŝanĝi ĉi tiun logikon sen multekostaj aŭ foje eĉ neeblaj inteligentaj kontraktaj ĝisdatigoj. Kaj konservante aplikajn datumojn kaj logikon ekster ĉeno, malcentralizitaj aplikoj povas atingi la agadon kaj skaleblo-nivelojn de tradiciaj centralizitaj sistemoj.
konkludo
Aplikoj kurantaj sur Blockstack povas skali multe pli bone ol konvenciaj blokĉenaj aplikoj, sed ĝi estas pli juna aliro kun siaj propraj problemoj kaj neresponditaj demandoj.
Ekzemple, se malcentralizita aplikaĵo ne funkcias per inteligentaj kontraktoj, tiam ĉi tio reduktas la bezonon de utilaj ĵetonoj. Ĉi tio povus kaŭzi problemojn por entreprenoj konsiderante, ke ICO-oj estis la ĉefa fonto de financado por malcentralizitaj aplikoj (inkluzive de Blockstack mem)
Ankaŭ ĉi tie estas teknikaj problemoj. Ekzemple, estas relative facile efektivigi hotelan rezervan funkcion en inteligenta kontrakto, kie en atomoperacio, ĉambraj rezervoj estas faritaj kontraŭ ĵetonoj. Kaj ne estas tre evidente kiel rezervo funkcios en aplikaĵo Blockstack sen inteligentaj kontraktoj.
Aplikoj, kiuj celas tutmondajn merkatojn kun la potencialo por milionoj da uzantoj, devas tre bone skali por esti sukcesaj. Estas eraro fidi nur al blokĉenoj por atingi ĉi tiun nivelon de skaleblo en proksima estonteco. Por povi konkuri kun grandaj centralizitaj merkataj ludantoj kiel Booking.com, malcentralizitaj aplikaĵprogramistoj devus konsideri alternativajn alirojn al desegnado de siaj aplikoj, kiel tiu ofertita de Blockstack.
fonto: www.habr.com