Opside network въвежда 3-слойна архитектура за блокчейн приложение...

Мащабируемостта на блокчейн и предложените решения са в челните редици на бърборенето в социалните медии от половин десетилетие. Например израелската софтуерна компания Starkware и съоснователят на Ethereum Виталик Бутерин наскоро говориха за идеята за „Layer 3“ като едно от тези решения. Starkware казва, че няколко слоя 3 ще се движат върху слой 2, а решенията за „фрактално наслояване“ могат да бъдат изградени върху слоя 3. 

Проектът Opside наскоро пуснаха своите планове за трислойна архитектура. Това ще позволи на разработчиците да създават блокчейн приложения, които имат достъп до по-високи скорости и по-евтини транзакции. Това става възможно благодарение на веригата Opside, която е наречена решение от слой 2, защото се намира върху множество платформи от слой 1 (като Ethereum, Binance Chain, Bitcoin и т.н.) и ги използва като слой за сетълмент. Функционалността „Layer 3“ прави това още по-далеч, позволявайки на разработчиците да завъртят набор от „сборни пакети като услуга“. Тази архитектура дава на Layer 2 по-всеобхватна гама от активи от мостове и възможност за неограничен растеж от събирания. 

За да обработите договорните повиквания между множество вериги, Opside разработи протокол за обработка на всички обаждания по договор. Също така се разработва DAO гласуване, което позволява на общността Opside да гласува кои публични вериги да използва за сетълмент на ниво 1. 

Решенията от слой 2 зависят от децентрализацията на техния аналог от слой 1, за да осигурят по-бързи транзакционни времена и по-ниски такси за газ. Изглежда приемливо за повечето блокчейн общности да имат централизиран слой върху тяхната платформа, стига всяка транзакция да се урежда на ниво Слой 1. Ефективността се постига чрез „групиране“ на набор от транзакции и сетълмент по-късно. Слой 3 усилва този модел, позволявайки още по-голяма ефективност на разходите, като същевременно поддържа скоростта на мрежата на слой 2. 

Слой 3 притежава потенциала да предложи толкова ниски разходи, че проектите, изградени дори на мрежи от слой 2, няма да трябва да разгръщат свои собствени слоеве 1, за да намалят таксите за сетълмент. Тези приложения, като Axie и dYdX Decentralized Exchange, трябваше да направят това, просто защото техният модел зависеше от най-бързите времена за транзакции и най-ниските такси. Ако се разположи на Layer 3 rollup, това може да предотврати необходимостта от още една блокова верига.

Слой 1: Многоверижни мостове

Opside поддържа по-бърз и по-евтин децентрализиран Liquidity-Bridge за постигане на оперативна съвместимост на активи в повече вериги. Liquidity-Bridge се състои от възли без разрешение, които постигат консенсус относно междуверижни съобщения чрез MPC. Пулът от ликвидност осигурява по-висока скорост и поддържа повече публични вериги и техните активи във веригата.

Освен това Opside ще установи връзки с различни публични вериги на слоя активи чрез безнадеждния ZK-Bridge. В сравнение с други мостови схеми, ZK-Rollup схемата включва повече ZK-устойчиви системи. При операцията между веригата е необходимо да се генерират ZK доказателства, за да се гарантира коректността на процеса на изпълнение в допълнение към общото „изпълнение“. Операциите по депозит и теглене на ZK-Bridge са „втвърдени“ като верига и логиката на веригата е напълно разкрита.

Layer2: Верига, удобна за събиране

Веригата Opside, или Layer 2, е съвместима с EVM и лесна за събиране верига. Веригата Opside ще направи някои задълбочени оптимизации за събиране.

Родният сбор е донякъде подобен на архитектурата на Polkadot. След като сборен пакет регистрира слот, сборният пакет става естествен сборен пакет. За разлика от това, архитектурата Polkadot има недостатъка, че консенсусът на парачейна зависи от зададения набор от валидатори. Има корелация между сигурността и броя на валидаторите. Ако няколко валидатора излязат офлайн, парачейните, чиито групи валидатори са твърде малки, за да валидират блок, ще пропуснат тези блокове или дори ще спрат, докато ситуацията не бъде разрешена. Opside няма този проблем, защото слой 2 събира данни от всички собствени сборни данни в слой 3 и проверява всички zk доказателства. Opside Chain е по-сигурна и децентрализирана с всички събирания в нея като по-плътно цяло, споделящо един и същ консенсусен слой.

Има 64 предварително разгърнати договора като „събирателни слотове“, които ще бъдат извиквани директно чрез пакетни и доказателствени транзакции от сборни пакети. Тези слотове ще извикат предварително компилиран договор за проверка на доказателство и ще актуализират корените на местното състояние, ако успеят. Предварително компилираният договор може да ускори проверката на доказателства с нулево знание с оптимизации в двоични кодове.

Слой 2 и слой 3 на архитектурата Opside споделят a консенсус механизъм с хибрид на PoS и PoW.

• PoS: На слой 2 всеки може да стане валидатор чрез залагане, след което има възможност да произвежда блокове от противоположната верига. PoS е доказуем и валидаторите периодично изпращат PoS доказателство на слой 1. Валидаторите могат да получат наградата за блок и наградата за залагане за тази част от PoS.
• PoW: Валидаторите на слой 2 не само ще произвеждат блокове Opside Chain, но също така ще генерират zk доказателство за всеки естествен сбор на слой 3 според правилата на PoVP. Валидаторите ще получат наградата на IDE за успешно генериране на zk доказателство, което е донякъде подобно на PoW. Валидаторите могат да получат допълнителен бонус за тази част от наградата, като заложат повече токени в системния договор.

По-важното е, че в Opside, след завършване на регистрацията на слотовете, нативните събирания споделят едно с друго световно дърво на състоянието и една и съща глобална опашка от съобщения. Следователно в Opside е възможна вградена оперативна съвместимост с кръстосано събиране. Представете си, че искате да заемете USDC за договор за заем в Rollup A и след това отидете на DEX в Rollup B, за да търгувате, за да купите BTC. В Opside вече не е необходимо да теглите активи от Rollup A към L1 и след това да ги презареждате от L1 към Rollup B. Вместо това можете да извикате договорния метод на Rollup B директно в Rollup A. Това ще направи целия процес много по-бърз, по-евтино и по-безопасно.

Слой 3: Децентрализирани ZK-събирания

В третия слой Opside подкрепя разработчиците да разположат свои собствени събирателни пакети, докато Opside също така предоставя децентрализирано сборно решение въз основа на RaaS, споменат по-горе. Разработчиците могат свободно да избират кой да приемат. Това решение е надеждно и без разрешение. Всеки може да изпраща L2 партиди и доказателства на L1.

За да обобщим, архитектурата „базов слой <- opside <- rollup“ на Opside има предимството на разнообразието на активите и безкрайната мащабируемост. Може да бъде друг избор за решаване на проблемите с мащабируемостта на web3 приложенията. В сравнение със скъпите слоеве 2, базирани на събиране, той е по-подходящ за приложения с висока производителност като игри.

Отказ от отговорност: Тази статия е предоставена само с информационна цел. Той не се предлага или е предназначен да се използва като правен, данъчен, инвестиционен, финансов или друг съвет.