Nem, egy decentralizált alkalmazás (dapp) elindítása a blokkláncon nem vezet sikeres üzlethez. Valójában a legtöbb felhasználó nem is gondol arra, hogy az alkalmazás a blokkláncon fut-e – egyszerűen olyan terméket választ, amely olcsóbb, gyorsabb és egyszerűbb.
Sajnos, még ha a blokkláncnak is megvannak a maga egyedi jellemzői és előnyei, a legtöbb rajta futó alkalmazás sokkal drágább, lassabb és kevésbé intuitív, mint a központosított versenytársaik.
A blokkláncra épülő alkalmazások ismertetőiben gyakran található egy bekezdés, amely így szól: „A blokklánc drága, és nem tudja támogatni a szükséges számú tranzakciót másodpercenként. Szerencsére sok okos ember dolgozik a blokklánc méretezésén, mire az alkalmazásunk elindul, egészen skálázhatóvá válik.”
Egy egyszerű bekezdésben a dapp-fejlesztők lemondhatnak a skálázhatósági problémák és a problémák alternatív megoldásairól szóló mélyebb tárgyalásról. Ez gyakran egy nem hatékony architektúrához vezet, ahol a blokkláncon futó intelligens szerződések szolgálnak az alkalmazás háttereként és magjaként.
A decentralizált alkalmazásarchitektúrának azonban még mindig vannak teszteletlen megközelítései, amelyek sokkal jobb skálázhatóságot tesznek lehetővé a blokklánctól való függés csökkentésével. Például a Blockstack olyan architektúrán dolgozik, ahol az alkalmazásadatok és logika nagy része a láncon kívül van tárolva.
Először nézzünk meg egy hagyományosabb megközelítést, amely a blokkláncot közvetlen közvetítőként használja az alkalmazás felhasználói között, és amely nem skálázódik túl jól.
1. megközelítés: A blokklánc mint háttérprogram
A dolgok világosabbá tétele érdekében vegyük példának a szállodaipart. Ez egy hatalmas iparág, amelyben az olyan közvetítők, mint a Booking.com, a vendégek és a szállodák összekapcsolására.
Minden olyan helyzetben, amikor ezzel a megközelítéssel le akarunk győzni egy ilyen közvetítőt, megpróbáljuk lemásolni az üzleti logikáját egy blokkláncon, például az Ethereumon kötött intelligens szerződések segítségével.
A „világszámítógépen” futó nyílt forráskódú intelligens szerződések harmadik fél nélkül is összeköthetik a kereskedőket a fogyasztókkal, végső soron csökkentve a közvetítő által felszámított díjakat és jutalékokat.
Ahogy az alábbi képen is látható, a szállodák egy decentralizált alkalmazás segítségével közzéteszik a blokkláncon a szobákkal, azok elérhetőségével és áraival kapcsolatos információkat a hétköznapokon vagy hétvégén, és talán még a szobák leírását is, minden egyéb lényeges információval együtt.
Bárki, aki szobát szeretne foglalni, használja ezt az alkalmazást a blokkláncon tárolt szállodák és szobák keresésére. Miután a felhasználó kiválasztott egy szobát, a foglalás megtörténik a szükséges mennyiségű token elküldésével a szállodának előlegként. És válaszul az intelligens szerződés frissíti a blokkláncban található információkat, hogy a szám már nem elérhető.
Ennek a megközelítésnek a méretezhetőségi problémájának két oldala van. Először is, a tranzakciók maximális száma másodpercenként. Másodszor, a blokkláncon tárolható adatmennyiség.
Végezzünk néhány durva számítást. A Booking.com azt állítja, hogy közel 2 millió szállodát regisztráltak náluk. Tegyük fel, hogy egy átlagos szállodában 10 szoba van, és mindegyiket évente csak 20-szor foglalják le – ez másodpercenként átlagosan 13 foglalást jelent.
Ennek a számnak a perspektívájához érdemes megjegyezni, hogy az Ethereum körülbelül 15 tranzakciót tud feldolgozni másodpercenként.
Ugyanakkor érdemes megfontolni, hogy alkalmazásunk a szállodák tranzakcióit is tartalmazza majd - a szobákkal kapcsolatos információk letöltéséhez és folyamatos frissítéséhez. A szállodák nagyon gyakran frissítik a szobaárakat, néha akár naponta is, és minden ár- vagy leírásmódosításhoz tranzakcióra van szükség a blokkláncon.
Itt méretproblémák is vannak – az Ethereum blokklánc súlya nemrég átlépte a 2 TB-os határt. Ha az ilyen megközelítésű alkalmazások valóban népszerűvé válnának, az Ethereum hálózat rendkívül instabillá válna.
Egy ilyen blokklánc alapú rendszer pártatlansága és a centralizáció hiánya miatt kizárhatja a kívülállókat, ami a blokklánc technológia fő előnyei. De a blokkláncnak más funkciói is vannak - terjesztett és nem íródik át, ezek kiváló tulajdonságok, de fizetni kell értük a tranzakciók sebességében és jutalékában.
Ezért a dapp fejlesztőknek gondosan fel kell mérniük, hogy a blokkláncot használó egyes funkciók valóban terjesztésre és nem írhatóságra szorulnak-e.
Például: milyen előnyökkel jár, ha az egyes szállodák adatait több száz gép között szétosztjuk a világon, és ott tartósan tároljuk? Valóban fontos, hogy a szobaárakra és a rendelkezésre állásra vonatkozó történelmi adatok mindig szerepeljenek a blokkláncban? Valószínűleg nem.
Ha elkezdünk ilyen kérdéseket feltenni, látni fogjuk, hogy nem feltétlenül van szükségünk az összes drága blokklánc funkcióra minden funkciónkhoz. Szóval, mi az alternatíva?
2. megközelítés: Blockstack ihletésű építészet
Bár a fő hangsúly olyan alkalmazásokban, amelyekben a felhasználók az adataik tulajdonosai (pl , , vagy ), a blockstacknek is az a filozófiája, hogy a blokkláncot könnyeden használja – csak akkor, ha feltétlenül szükséges. Fő érvük az, hogy a blokklánc lassú és drága, ezért csak egyszeri vagy ritka tranzakciókhoz szabad használni. Az alkalmazásokkal való interakció többi részének peer-to-peer-en keresztül kell történnie, pl. A decentralizált alkalmazások felhasználóinak közvetlenül kell megosztaniuk egymással az adatokat, nem pedig a blokkláncon keresztül. Végül is a legrégebbi és legsikeresebb decentralizált alkalmazások, mint például a BitTorrent, az e-mail és a Tor, a blokklánc koncepciója előtt születtek.
Balra: Az első megközelítés, amelyben a felhasználók a blokkláncon keresztül lépnek kapcsolatba. Jobbra: A felhasználók közvetlenül érintkeznek egymással, és a blokkláncot csak azonosításra és hasonlókra használják.
Térjünk vissza a szállodafoglalási példához. Pártatlan, független és nyílt protokollt szeretnénk a vendégek és a szállodák összekapcsolására. Más szóval, el akarjuk távolítani a központosított közvetítőt. Nem kell például állandóan közös elosztott főkönyvben tárolnunk a szobaárakat.
Miért nem engedjük meg, hogy a vendégek és a szállodák közvetlenül kommunikáljanak egymással, ne pedig a blokkláncon keresztül. A szállodák az áraikat, a szobák elérhetőségét és minden egyéb információt tárolhatnak valahol, ahol mindenki számára elérhetők lesznek - például IPFS, Amazon S3 vagy akár saját helyi szerverük. A Blockstack decentralizált tárolórendszere pontosan ezt hívja . Lehetővé teszi a felhasználók számára, hogy megválasszák, hol kívánják tárolni adataikat, és szabályozhatják, hogy ki férhet hozzá az úgynevezett megközelítésen keresztül .
A bizalom megteremtése érdekében az összes szállodai adatot maga a szálloda kriptográfiailag aláírja. Függetlenül attól, hogy hol tárolják ezeket az adatokat, azok integritása ellenőrizhető a szálloda blokkláncon tárolt identitásához társított nyilvános kulcsokkal.
A Blockstack esetében csak az Ön személyazonossági adatait tárolja a blokklánc. Az egyes felhasználók adatainak megszerzésére vonatkozó információkat zónafájlokban tárolják, és csomópontok segítségével egyenrangú hálózaton keresztül osztják el. És még egyszer: nem kell megbíznia a csomópontok által megadott adatokban, mert ellenőrizheti azok hitelességét, ha összehasonlítja azokat a blokkláncban és más felhasználókban tárolt hash-ekkel.
A rendszer leegyszerűsített változatában a vendégek a Blockstack peer-to-peer hálózatot használják szállodák keresésére és szobáik információira. Az összes kapott adat hitelessége és integritása pedig a tárolt nyilvános kulcsok és hashek segítségével ellenőrizhető Blockstack.
Ez az architektúra összetettebb, mint az első megközelítés, és átfogóbb infrastruktúrát igényel. Valójában pontosan itt jön be a Blockstack, amely minden szükséges összetevőt biztosít egy ilyen decentralizált rendszer létrehozásához.
Ezzel az architektúrával csak azokat az adatokat tároljuk a blokkláncon, amelyeket valóban el kell osztani, és nem kell felülírni. A Blockstack esetében csak a blokkláncon végrehajtott tranzakciókra van szüksége, hogy regisztráljon, és jelezze, hol tárolja adatait. Előfordulhat, hogy további tranzakciókat kell végrehajtania, ha módosítani szeretné ezeket az információkat, de ez nem ismétlődő esemény.
Ráadásul az alkalmazáslogika az első megközelítéssel ellentétben a kliens oldalon fut, nem pedig az intelligens szerződéseken. Ez lehetővé teszi a fejlesztő számára, hogy költséges vagy néha lehetetlen intelligens szerződésfrissítések nélkül módosítsa ezt a logikát. Az alkalmazásadatok és a logika láncon kívül tartásával pedig a decentralizált alkalmazások elérhetik a hagyományos központosított rendszerek teljesítmény- és méretezhetőségi szintjét.
Következtetés
A Blockstacken futó alkalmazások sokkal jobban skálázhatók, mint a hagyományos blokklánc alkalmazások, de ez egy fiatalabb megközelítés, saját problémáival és megválaszolatlan kérdéseivel.
Például, ha egy decentralizált alkalmazás nem fut intelligens szerződéseken, akkor ez csökkenti a segédprogram-tokenek szükségességét. Ez problémákat okozhat a vállalkozásoknak, tekintve, hogy az ICO-k a decentralizált alkalmazások (beleértve magát a Blockstacket is) fő finanszírozási forrását.
Itt technikai problémák is vannak. Például viszonylag egyszerűen megvalósítható egy szállodafoglalási funkció egy intelligens szerződésben, ahol egy atomüzemben tokenekért cserébe szobafoglalás történik. És nem túl nyilvánvaló, hogyan működik a foglalás egy Blockstack alkalmazásban intelligens szerződések nélkül.
Azoknak az alkalmazásoknak, amelyek több millió felhasználó számára potenciálisan globális piacokat céloznak meg, nagyon jól kell skálázni ahhoz, hogy sikeresek legyenek. Hiba kizárólag blokkláncokra hagyatkozni, hogy a közeljövőben elérjük ezt a skálázhatósági szintet. Ahhoz, hogy versenyezni tudjanak olyan nagy központosított piaci szereplőkkel, mint a Booking.com, a decentralizált alkalmazásfejlesztőknek alternatív megoldásokat kell fontolóra venniük alkalmazásaik tervezése során, például a Blockstack által kínált megoldást.
Forrás: will.com