Ethereum încă lucrează la un plan complementar pentru EVM paralel, dar Bitcoin se poate aștepta în curând la propriul strat 2 de VM paralel.

În primul rând, să înțelegem de ce Ethereum nu poate realiza EVM paralel.

Pentru a menține consistența și securitatea rețelei, EVM are o caracteristică crucială în proiectarea sa: tranzacțiile sunt executate secvenţial. Execuția secvențială asigură că tranzacțiile și contractele inteligente pot fi executate într-o ordine deterministă, facilitând gestionarea și prezicerea stării blockchain-ului. Această alegere de design acordă prioritate securității, reducând potențialele complexități și vulnerabilități asociate cu execuția paralelă. Cu toate acestea, în condițiile unui volum mare de cereri de tranzacție, această execuție secvențială poate duce la aglomerarea rețelei și întârzieri, similare cu o autostradă cu o singură bandă.

Este posibil să adăugați pur și simplu benzi? Faceți referire la soluțiile existente ale așa-numitelor VM paralele, inclusiv lanțuri de fragmentare precum Near. Aceste lanțuri au propus să extindă blockchain-ul prin introducerea mai multor VM pentru a scala contractele inteligente. În esență, volumul de muncă al unui contract inteligent se află încă într-o anumită VM. Dacă toate contractele inteligente din acest lanț consumă o cantitate egală de TPS, atunci problema este rezolvată. Totuși, dacă doar câteva contracte, precum protocoalele Aave și Uniswap, consumă peste 90% din spațiul bloc, a avea contracte care rulează pe un singur shard înseamnă doar scalarea la nivel de lanț fără a beneficia de îmbunătățirile aduse de sharding. Adăugarea de benzi fără posibilitatea de a schimba benzi reprezintă dilema actuală a paralelizării VM-urilor.

EVM paralel implică tăierea sau stocarea în cache a datelor la nivelul de date. Cu toate acestea, limitat de modelul de programare al EVM, Solidity, ca cel mai popular limbaj de programare smart contract, nu poate maximiza potențialul arhitecturii blockchain paralele. Este asemănător cu a nu programa cu SQL pe GPU-ul NVIDIA. Solidity nu are expresii pentru arhitecturile paralele precum Relay Execution și nu are o atomicitate finală definită pentru tranzacțiile paralele.

Paralelismul adevărat în arhitectura blockchain necesită obținerea rezultatului ca tranzacțiile unui contract inteligent să poată rula pe mai multe VM simultan. Este necesar un model de programare precum CUDA pentru a utiliza pe deplin un model paralel în arhitectura blockchain.

BitReXe menționează că Bitcoin introduce Turing-complete paralel VM Layer 2 pentru a oferi suport de infrastructură de bază pentru aplicații reale din ecosistemul Bitcoin și un model de programare exclusiv pentru VM paralele, PREDA.

Cum realizează BitReXe Vms paralele pe Bitcoin

VM-uri paralele

Următoarea ilustrație evidențiază diferențele dintre BitReXe și alte inițiative care promovează VM-uri paralele. După cum se arată în segmentul din stânga al figurii, Ethereum aderă la un model de stare cu o singură mașină, în care toate codurile (contractele inteligente) și stările (date) sunt replicate și gestionate de fiecare nod blockchain prin intermediul Ethereum Virtual Machine (EVM). Proiectele existente utilizează EVM-uri paralele, așa cum se arată în secțiunea din mijloc a figurii, unde un singur contract inteligent este implementat pe o VM dedicată (sau VM-uri într-un fragment desemnat pentru a susține consensul). Toate tranzacțiile aferente contractului inteligent sunt procesate de VM (sau VM-urile fragmentului într-o manieră complet duplicată).

În modelul de paralelizare unificată al BitReXe, așa cum se arată în segmentul din dreapta al figurii, toate contractele inteligente sunt implementate pe toate VM-urile rețelei. Stările unui contract inteligent sunt supuse partiționării și distribuției în instanțe VM distincte, asigurând o alocare nesuprapusa. În mod corespunzător, tranzacțiile contractului inteligent sunt segmentate și distribuite pentru procesare independentă și paralelă între VM. În cazul ideal, această abordare facilitează o scalare liniară a debitului total al tranzacțiilor și a capacității de stare cu un număr tot mai mare de VM.

Provocarea principală constă în gestionarea eficientă a dependențelor dintre logica de execuție (cod) și starea contractului (date), permițând în același timp execuția independentă a VM și evitând sincronizarea, deoarece logica de execuție completă a unei tranzacții poate implica acces la mai multe segmente de stări contractuale, fiecare rezident. în VM-uri separate după partiționarea stării.

PREDA

Vă prezentăm Parallel Relay-Execution Distributed Architecture (PREDA), un model de programare revoluționar conceput pentru a extinde contractele inteligente pe sharding blockchains, sisteme parachain și blockchain layer-2. PREDA acceptă o arhitectură paralelă: dacă Solidity pentru Ethereum este asemănător cu programul pe un CPU cu un singur nucleu, arhitectura paralelă PREDA pentru BitReXe este asemănătoare cu CUDA pentru GPU-ul NVIDIA.

Modelul PREDA introduce două componente cheie: (1) „Scoperii contractuale programabile”, permițând programatorilor să definească partiționarea stării contractului pe baza modelului de acces la date al aplicației, restrângând intervalul de acces la date și minimizând dependența de date; și (2) „Releu funcțional asincron”, permițând programatorilor să articuleze logica tranzacțiilor cu dependențe implicite de date pentru o execuție flexibilă în mai multe motoare de execuție (VM). Implementat ca un limbaj Solidity extins, PREDA include sintaxă suplimentară pentru domeniile contractuale programabile și instrucțiuni pentru releul funcțional asincron.

Figura ilustrează versiunea PREDA a unui contract ERC20 simplificat. Cuvântul cheie „@address” definește domeniul de aplicare al soldurilor utilizatorilor, echivalent cu definiția hărții Solidity, dar specifică stări detaliate și separabile pentru partiționarea după adresă. În timpul execuției, stările partiționate după adresă sunt gestionate de un set de mașini virtuale din lanțul BitReXe. Stări diferite nu sunt menținute de seturi diferite de VM. Funcția de transfer din domeniul „@address”, invocată de plătitori (adică adresele de utilizator care inițiază tranzacții de transfer), inițiază un „releu” pentru depunerea către beneficiar. Acest releu, executat de un VM care găzduiește statele adresei beneficiarului, adaugă fonduri la soldul beneficiarului.

În PREDA, un contract inteligent poate avea mai multe domenii cu variabile și funcții definite. Mai multe funcții și variabile de tipuri arbitrare, inclusiv containere, pot fi definite într-un domeniu. Mai multe relee, condiționat sau necondiționat, pot fi inițiate într-un singur apel de funcție, permițând inițierea recursivă și permițând ca fluxul de execuție a tranzacțiilor să fie mutat cu mai multe hop-uri în diferite instanțe VM. Această abordare de execuție releu descompune o tranzacție în mai multe micro-tranzacții, asigurând acces limitat la stat într-o singură mașină virtuală și evitând condițiile de cursă. În contractul inteligent de transfer PREDA, descompunerea tranzacției într-o micro-tranzacție de „retragere” și o micro-tranzacție de „depunere” permite executarea paralelă a acestor două tipuri de micro-tranzacții, atâta timp cât obiectivele lor (adresele în acest caz) sunt mapate pe diferite mașini virtuale.

BitReXe organizează mașinile virtuale în mai multe grupuri de consens, fiecare rulând independent un protocol de consens (bazat pe PoW în implementare) pentru a ajunge la un consens asupra tranzacțiilor executate. Consensul între grupuri este implementat pentru a menține corectitudinea și coerența pentru releele funcționale asincrone, implementate ca tranzacții de releu în BitReXe.

Bitcoin Stratul 2

Paradigma de emitere a activelor pe stratul Bitcoin, cum ar fi inscripția, exploatează în mod constant o vulnerabilitate în Bitcoin, spune Luke. În timp ce banii nu doarme niciodată, la fel cum inscripțiile nu vor muri niciodată. Bitcoin are nevoie disperată de un strat 2 cu adevărat scalabil, care să poată elibera o astfel de presiune și să salveze dimensiunea registrului de la creșterea prea rapidă, ceea ce va slăbi descentralizarea. Este foarte puțin probabil ca un astfel de obiectiv să fie atins printr-o soluție EVM+Bridge.

BitReXe propune VM-uri paralele și PREDA pentru a scala bitcoin. Între timp, se adaptează la securitatea bitcoin. Folosește BTC ca taxă de gaz, împărtășește securitatea Bitcoin și oferă o decontare fără încredere a activelor între cele două lanțuri.

BitReXe reutiliza puterea de calcul hashing de către rețeaua Bitcoin, care este transportată de blocuri în lanț, blocuri orfane și blocuri premature ca dovadă de lucru pentru a crea blocuri valide în rețeaua de nivel 2 fără a modifica protocolul Bitcoin. Minerii Merge primesc rxBTC ca recompense, un bitcoin fixat 1:1 în rețeaua BitReXe. Utilizatorii plătesc taxe de gaz cu rxBTC pentru tranzacții, interacțiunea cu contractele inteligente și alte activități în lanț. Laboratorul Fullnodes, echipa de dezvoltare a PREDA și BitReXe este pe cale să introducă o soluție fără încredere de decontare a activelor între Bitcoin și BitReXe, unde rxbtc peg-out este, în același timp, peg-in-ul BTC al cuiva. Adresele oficiale de peg-out nu mai sunt necesare, prin urmare ipoteza de încredere este eliminată.

Așteptările noastre mari pentru ecosistemul Bitcoin provin din capacitatea sa de a rezolva probleme pe care Ethereum – ca testnet al Bitcoin – nu le-a abordat.

@Bit_ReXe consideră că această problemă provine din lipsa EVM de mecanisme paralele care conduc la trilema blockchain și își propune să o rezolve direct pe Bitcoin Layer 2.

Dacă această problemă poate fi rezolvată pe Bitcoin, atunci benchmarkingul TVL sau chiar depășirea Ethereum de mai mult de trei ori pe Bitcoin Layer 2 ar reprezenta o descoperire fundamentală.”

Aceasta este o postare invitată de BitPNova. Opiniile exprimate sunt în întregime proprii și nu le reflectă neapărat pe cele ale BTC Inc sau Bitcoin Magazine.

Sursa: Bitcoin Magazine

Postarea BitReXe: Activarea VM-urilor paralele pe rețeaua Bitcoin a apărut mai întâi pe Crypto Breaking News.