A blokklánc méretezhetősége és a javasolt megoldások már fél évtizede a közösségi média csevegés élvonalában állnak. Például az izraeli Starkware szoftvercég és az Ethereum társalapítója, Vitalik Buterin nemrégiben a „Layer 3” ötletéről beszélt, mint az egyik ilyen megoldásról. A Starkware szerint több 3-as réteg is felkerül a 2-es rétegre, a „fraktálrétegű” megoldások pedig a 3-as rétegre építhetők.
Az Opside projekt a közelmúltban kiadták a háromrétegű architektúra terveit. Ez lehetővé teszi a fejlesztők számára, hogy blokklánc-alkalmazásokat hozzanak létre, amelyek nagyobb sebességhez és olcsóbb tranzakciókhoz férnek hozzá. Ezt az Opside lánc teszi lehetővé, amelyet Layer 2 megoldásnak neveznek, mivel több Layer 1 platform tetején ül (mint az Ethereum, Binance Chain, Bitcoin stb.), és ezeket elszámolási rétegként használja. A „Layer 3” funkció még tovább viszi ezt, lehetővé téve a fejlesztők számára, hogy „szolgáltatásként összesítéseket” állítsanak össze. Ez az architektúra a 2. réteg számára a hidakból származó eszközök átfogóbb skáláját kínálja, és lehetővé teszi a végtelenségig történő növekedést az összesítésből.
A több lánc közötti szerződéshívások kezelése érdekében Opside kifejlesztett egy protokollt az összes szerződési hívás kezelésére. Szintén fejlesztés alatt áll a DAO szavazás, amely lehetővé teszi az Opside közösség számára, hogy szavazzon arról, hogy mely nyilvános láncokat használja az 1. rétegű településhez.
A 2. rétegű megoldások az 1. rétegű megfelelőjük decentralizálásától függenek, hogy gyorsabb tranzakciós időt és alacsonyabb gázdíjat biztosítsanak. A legtöbb blokklánc-közösség számára elfogadhatónak tűnik, hogy egy központi réteget helyezzen el a platform tetején, mindaddig, amíg minden tranzakciót az 1. réteg szintjén rendeznek. A hatékonyságot úgy érik el, hogy egy sor tranzakciót „kötegbe” kötnek és később elszámolnak. A Layer 3 felerősíti ezt a modellt, ami még nagyobb költséghatékonyságot tesz lehetővé, miközben megőrzi a 2. rétegű hálózat sebességét.
A 3. réteg olyan alacsony költségeket kínál, hogy még a 2. rétegbeli hálózatokra épülő projekteknek sem kell saját 1. réteget telepíteniük az elszámolási díjak csökkentése érdekében. Ezeknek az alkalmazásoknak, mint például az Axie és a dYdX Decentralized Exchange kellett ezt megtenniük, egyszerűen azért, mert modelljük a leggyorsabb tranzakciós időktől és a legalacsonyabb díjaktól függött. Ha a 3. rétegű összesítésen kerül telepítésre, akkor elkerülhető lenne egy újabb blokklánc szükségessége.
1. réteg: Többláncos hidak
Az Opside támogatja a gyorsabb és olcsóbb decentralizált likviditási hidat, hogy több láncban érje el az eszközök interoperabilitását. A Liquidity-Bridge engedély nélküli csomópontokból áll, amelyek az MPC-n keresztül konszenzusra jutnak a láncok közötti üzenetekről. A likviditási pool gyorsabb sebességet biztosít, és több nyilvános láncot és azok láncon belüli eszközeit támogat.
Továbbá az Opside kapcsolatot létesít az eszközréteg különböző nyilvános láncaival a megbízható ZK-Bridge-en keresztül. Más hídrendszerekhez képest a ZK-Rollup séma több ZK-biztos rendszert tartalmaz. A keresztlánc-műveletben az általános „végrehajtáson” túlmenően szükség van ZK-bizonyítékok generálására, hogy biztosítsuk a végrehajtási folyamat helyességét. A ZK-Bridge be- és kifizetési műveletei áramkörként „megszilárdulnak”, és az áramköri logika teljesen feltárul.
Layer2: Rollup-barát lánc
Az Opside lánc vagy a Layer 2 egy EVM-kompatibilis és rollup-barát lánc. Az Opside lánc mélyreható optimalizálást fog végezni az összesítéshez.
A natív rollup némileg hasonlít a Polkadot architektúrájához. Miután az összesítés egy helyet regisztrál, az összesítés natív összesítővé válik. Ezzel szemben a Polkadot architektúrának az a hátránya, hogy a parachain konszenzusa a hozzárendelt érvényesítőkészlettől függ. Van a biztonság és az érvényesítők száma közötti összefüggés. Ha néhány érvényesítő offline állapotba került, azok a parachain-ok, amelyek érvényesítőcsoportjai túl kicsik egy blokk érvényesítéséhez, kihagyják ezeket a blokkokat, vagy akár le is állnak, amíg a helyzet meg nem oldódik. Az Opside nem rendelkezik ezzel a problémával, mert a 2. réteg a 3. réteg összes natív összesítéséből gyűjti az adatokat, és ellenőrzi az összes zk-bizonyítást. Az Opside Chain biztonságosabb és decentralizáltabb, mivel az összes összesítés szorosabb egészként működik, ugyanazon a konszenzusos rétegen osztozva.
64 előre telepített szerződés létezik „összegzési résként”, amelyeket közvetlenül az összesítésből származó kötegelt és ellenőrző tranzakciók hívnak meg. Ezek a helyek egy előre összeállított szerződést hívnak le az igazolás ellenőrzésére, és sikeres esetben frissítik a helyi állami gyökereket. Az előre lefordított szerződés felgyorsíthatja a nulla tudásalapú igazolások ellenőrzését a bináris kódok optimalizálásával.
Az Opside architektúra 2. és 3. rétege osztozik a konszenzus mechanizmus PoS és PoW hibridjével.
- PoS: A 2. rétegben bárki válhat érvényesítővé kockázással, majd lehetősége van az Opside Chain blokkjainak előállítására. A PoS bizonyítható, és az érvényesítők időszakonként benyújtják a PoS igazolást az 1. rétegnek. Az érvényesítők blokkjutalmat és tétjutalmat kaphatnak a PoS ezen részéért.
- PoW: A 2. réteg érvényesítői nemcsak Opside Chain blokkokat állítanak elő, hanem zk bizonyítást is generálnak a 3. réteg minden egyes natív felgöngyölítéséhez a következő szabályok szerint. PoVP. Az érvényesítők megkapják az IDE-jutalmat a sikeres zk-bizonyítvány generálásáért, amely némileg hasonlít a PoW-hoz. Az érvényesítők extra bónuszt kaphatnak a jutalom ezen részére, ha több tokent tesznek a rendszerszerződésbe.
Ennél is fontosabb, hogy az Opside-ban a helyek regisztrációjának befejezése után a natív összesítők egy világállapot-fát osztanak meg egymással és ugyanazt a globális üzenetsort. Ezért az Opside-ban lehetséges a natív cross-rollup interoperabilitás. Képzelje el, hogy USDC-t szeretne kölcsönadni egy kölcsönszerződéshez az A körben, majd a B körben a DEX-hez szeretne kereskedni, és vásárolni szeretne BTC-t. Az Opside-on már nem kell kivonnia az eszközöket az A összesítésből az L1-be, majd újra kell töltenie azokat az L1-ből a B összesítőbe. Ehelyett közvetlenül az A összesítőben hívhatja meg a B összesítő szerződéses módszerét. Ez sokkal gyorsabbá teszi az egész folyamatot, olcsóbb és biztonságosabb.
3. réteg: Decentralizált ZK-összegzések
A harmadik rétegben az Opside támogatja a fejlesztőket saját összesítésük üzembe helyezésében, míg az Opside a decentralizált rollup megoldás a fent említett RaaS alapján. A fejlesztők szabadon választhatják meg, melyiket alkalmazzák. Ez a megoldás megbízhatatlan és engedély nélküli. Bárki benyújthat L2 kötegeket és igazolásokat az L1-nek.
Összefoglalva, az Opside „alapréteg <- opside <- rollup” architektúrája előnye az eszközök változatossága és a végtelen méretezhetőség. Ez egy másik választás lehet a web3 alkalmazások skálázhatósági problémáinak megoldására. A drága rollup-alapú réteg 2-ekhez képest jobban megfelel nagy áteresztőképességű alkalmazásokhoz, például játékokhoz.
Jogi nyilatkozat: Ez a cikk csak tájékoztató jellegű. Nem ajánlják fel, és nem kívánják felhasználni jogi, adóügyi, befektetési, pénzügyi vagy egyéb tanácsadásként.
Forrás: https://cryptodaily.co.uk/2023/01/opside-network-introduces-3-layer-architecture-for-blockchain-applications