Išskirtiniame „Hackernoon“ interviu daktaras Aleksas Ševčenka, fizikas, tapęs „blockchain“ novatoriumi, atskleidžia novatorišką „Aurora “ požiūrį į „blockchain“ prieinamumą per „Aurora Cloud Console“. Remdamasis savo patirtimi kuriant Exonum įmonėje Bitfury, daktaras Ševčenka paaiškina, kaip „Aurora“ daro revoliuciją „blockchain“ diegime, naudodama savo „Virtual Chain“ technologiją, efektyviai sumažindama kelių milijonų dolerių kliūtį patekti į rinką iki nulio.
2025 m. spartėjant „blockchain“ diegimui, šis pokalbis atskleidžia, kaip „Aurora“ be kodo sprendimas gali iš esmės pakeisti mūsų mąstymą apie „blockchain“ tinklų paleidimą ir valdymą.
Ishan Pandey: Dr. Shevchenko, jūs patyrėte įspūdingą kelionę nuo fizikos ir matematikos iki blokų grandinės, įskaitant „Exonum“ kūrimą „Bitfury“ ir dabar perversmą „blockchain“ prieinamumui su „Aurora“. Kokios pagrindinės įžvalgos, gautos kuriant vieną iš pirmųjų įmonės Layer-1 platformų, paveikė jūsų viziją apie „Aurora Cloud Console“ be kodo metodą?
Aleksas Ševčenka: „Blockchains“ yra sudėtingas ir daugeliui inžinierių dažnai nėra intuityvus. Kuo paprastesnis ir prieinamesnis bus įtraukimo procesas, tuo plačiau bus taikoma blokų grandinė. Štai kodėl mūsų „Aurora“ tikslas yra supaprastinti „blockchain“ ir padaryti ją patogesnę.
Ishan Pandey: „Aurora Cloud Console“ yra pritaikytų blokų grandinių nulinio kodavimo platforma. Ar galite paaiškinti, kaip pavyko supaprastinti tradiciškai sudėtingą techninį procesą, išlaikant tvirtumą, reikalingą gamybai paruoštoms grandinėms?
Aleksas Ševčenka: Pagrindinis aspektas, dėl kurio tai įmanoma, yra mūsų sprendimo architektūra. „Aurora Cloud Console“ esmė yra virtualios grandinės koncepcija – sprendimas, kuris paveldi pagrindinės grandinės saugumą ir infrastruktūrą. Mūsų atveju tai yra NEAR blokų grandinė. Virtualios grandinės yra įdiegtos kaip išmaniosios sutartys pagrindinėje grandinėje, todėl jų valdymas ir pritaikymas yra toks pat paprastas, kaip išmaniųjų sutarties parametrų koregavimas prieš įdiegiant. Štai kodėl virtualias grandines lengva įdiegti ir lengvai pritaikyti.
Ishan Pandey: Virtualios grandinės yra unikalios tuo, kad paveldi NEAR patvirtinimo rinkinį ir infrastruktūrą. Kaip šis architektūrinis pasirinkimas paveikia saugumą, mastelį ir sąnaudų struktūrą, palyginti su tradiciniais L2 sprendimais, kuriems reikia sukurti savo tikrinimo tinklus?
Aleksas Ševčenka: L2 tradiciškai paleidžiami viename sekvencijos mazge, žadant ateityje paveldėti L1 blokų grandinės saugumą (paprastai vadinama 2 pakopos apvyniojimu). Tačiau nepatogi tiesa yra ta, kad labai nedaug komandų pasiekė šį etapą, o dauguma šaukimų buvo 0 etape (žr. l2beat.com ), o tai reiškia, kad reikia pasitikėti sekvenatoriumi.
Kita vertus, virtualios grandinės veikia kaip išmaniosios sutartys ir todėl turi tas pačias pasitikėjimo prielaidas kaip ir jų pagrindinė grandinė. „Aurora Cloud“ atveju tai reiškia, kad 235 tikrintojai, kurių bendras akcijų paketas viršija 2,5 mlrd. USD, patvirtina visas virtualias grandines nuo pat pirmojo bloko. Tiesą sakant, NEAR protokolas yra bendras decentralizuotas sekvenavimo įrenginys visoms virtualioms grandinėms.
Ishan Pandey: Žvelgiant konkrečiai į „Aurora Cloud Console“ paleidimą, kokių tipų projektus ar naudojimo atvejus įsivaizduojate, kad ši platforma įgalintų tai, kas anksčiau nebuvo įmanoma arba buvo per daug išteklių reikalaujanti?
Aleksas Ševčenka: Pramonės skaičiavimai (žr. tai ) rodo, kad blokų grandinės paleidimas paprastai kainuoja dešimtis milijonų JAV dolerių. Tai yra rimta kliūtis patekti į rinką. „Aurora Cloud Console“ visiškai pašalina šias išlaidas, sumažindama kainą iki nulio. Tikiuosi, kad šis pakeitimas suteiks galimybę ankstyvosios stadijos steigėjams eksperimentuoti ir daug greičiau pasiekti, kad produktų rinka atitiktų. Pašalinus šią kliūtį, tikimės transformuojančio poveikio blokų grandinės naudojimo atvejų kūrimui ir pritaikymui.
Ishan Pandey: Su tokiomis funkcijomis kaip valdomas parametrų pasirinkimas ir stebėjimas realiuoju laiku, atrodo, kad konsolė sukurta tiek techniniams, tiek netechniniams vartotojams. Kaip subalansuoti, kad blokų grandinės diegimas būtų prieinamas, tuo pačiu užtikrinant, kad vartotojai suprastų savo konfigūracijos pasirinkimų pasekmes?
Aleksas Ševčenka: UX gerinimas yra nesibaigianti istorija :) Mūsų požiūris yra užtikrinti, kad 80% atvejų naujos grandinės įkūrėjas/administratorius galėtų pasiekti visą reikiamą informaciją ir suprasti pasekmes tiesiogiai Aurora Cloud Console. Už likusius 20 % teikiame palaikymo grupes ir galimybę suplanuoti pokalbį su mūsų komanda. Tačiau turiu pripažinti, kad blokų grandinių paleidimas tinka ne visiems – kaip ir AWS serverio įsigijimas.
Ishan Pandey: Minėjote, kad „Aurora“ yra ne tik „Ethereum“ suderinamumas. Kaip, jūsų nuomone, pradėjus veikti „Cloud Console“ keičiasi „Aurora“ vaidmuo mažinant atotrūkį tarp skirtingų „blockchain“ ekosistemų?
Aleksas Ševčenka: „Ethereum“ sukūrė EVM kaip de facto „blockchain“ veikimo standartą. Tačiau blokų grandinės iš esmės yra „savaime dalykas“, neturinčios vietinių ryšių su išoriniu pasauliu. Tačiau padėtis diktuoja, kad blokų grandinių yra daug ir jas paleisti darosi vis paprasčiau. Taigi, kelių grandžių ateitis nebėra ateitis – tai mūsų dabartis. Ir mes turime tai leisti. Turime suteikti kūrėjams patogius vientisos sąveikos tarp blokų grandinių mechanizmus.
Aurora Cloud infrastruktūroje siūlome tokį technologinį sprendimą – grandininius parašus. Jis sukurtas ir paleistas kaip NEAR protokolo dalis ir leidžia paskyrose laikyti raktus (pvz., iš paskyros kitose grandinėse) ir pasirašyti pranešimus bei operacijas naudojant juos. Ši technologija prieinama visoms virtualiosioms grandinėms nuo pirmojo bloko.
Taip pat svarbu paminėti, kad ne tik ši, bet ir visa esama NEAR ir Aurora infrastruktūra yra prieinama Virtual Chains. Be to, būsimi infrastruktūros naujinimai bus prieinami diegimo metu. Nors L2 dažnai sukuria suskaidytas, nesąveikaujančias ekosistemas, virtualios grandinės metodas skatina tinklo efektą tarp visų grandinių, užtikrindamas sklandų ryšį ir bendradarbiavimą.
Ishan Pandey: Blockchain pramonė matė įvairius bandymus padaryti grandinės diegimą prieinamesnį. Kokios pamokos iš to
ankstesni metodai informavo apie „Aurora Cloud Console“ kūrimą ir kaip jis pašalina jų apribojimus?
Aleksas Ševčenka: Pagrindinė pamoka, kurią išmokome, yra ta, kad sprendimo kūrimas turi prasidėti nuo problemos, kurią norite išspręsti, o ne priversti esamas idėjas pritaikyti šioms problemoms. L2 buvo sukurti kaip Ethereum mastelio keitimo sprendimai. Kas sakė, kad toks metodas yra geriausias norint pradėti grandinę?
Idealus sprendimas norint paleisti grandinę turėtų atitikti šiuos kriterijus: jis turėtų užtrukti kelias sekundes, būti toks pat decentralizuotas kaip esami geriausi blokų grandinės protokolai ir pasiūlyti visą reikiamą infrastruktūrą, prieinamą nuo pirmojo bloko (stablecoins, CEXs integracija, tiltai, pranešimų siuntimas protokolai, DeFi ekosistema, kryžminės grandinės primityvai, NFP prekyvietės, paleidimo platformos, saugotojai ir rampos, RPC ir indeksavimo sprendimai, piniginės, tyrinėtojai ir valdymo sprendimai ir galbūt dar kažkas). Idealiu atveju visa tai turėtų būti nemokama.
Nors „Aurora Cloud“ dar nepasiekė šio idealo iki galo, mūsų architektūra gali tai įgyvendinti. Ir mes jau padarėme 90 proc.
Ishan Pandey: Žvelgiant į likusį 2025 m., į kokius virtualios grandinės ekosistemos pokyčius turėtume atkreipti dėmesį ir kaip „Aurora Cloud Console“ atitinka jūsų ilgalaikę „blockchain“ pasiekiamumo viziją?
Aleksas Ševčenka: Virtualios grandinės metodas yra geriausias blokų grandinių paleidimo sprendimas. Tačiau tai nereiškia, kad darbas atliktas. Dar reikia daug nuveikti, įskaitant infrastruktūros dalių prieinamumo didinimą per atvirą infrastruktūros rinką „Aurora Cloud“, taip pat tolesnį diegimo greičio optimizavimą.
Žvelgdamas į ateitį, laukiu, ką statybininkai pateiks ant stalo, turėdami rankose tokį galingą instrumentą. Mūsų tikslas 2025 m. – padėti kitiems paleisti 1000 virtualių grandinių. Ir aš esu tikras, kad tai daugiau nei įmanoma.
Nepamirškite pamėgti ir pasidalinti istorija!
Patvirtintų interesų atskleidimas: šis autorius yra nepriklausomas bendradarbis, publikuojantis per mūsų