Titlul original: „Bedrock Explainer”

Scris de: Optimism Official

Compilat de: Frank, Foresight News

Bedrock este numele primei versiuni oficiale a OP Stack, un set de componente modulare gratuite și open source concepute pentru a stimula creșterea Optimism.

Rezumatul îmbunătățirii

Bedrock se îmbunătățește față de predecesorul său, inclusiv:

• Reduceți taxele de tranzacție folosind compresia optimizată a tranzacțiilor în lot și Ethereum ca nivel de disponibilitate a datelor;

• Reducerea latenței în ambalarea tranzacțiilor L1 în pachete, prin gestionarea mai bună a reorganizărilor L1;

• Activați sistemele de verificare modulare prin reutilizarea codului;

• Îmbunătățiți performanța nodului prin eliminarea datoriei de proiectare.

comisioane mai mici

Bedrock utilizează o strategie optimizată de comprimare a datelor pentru a minimiza costurile datelor. În prezent, analizăm impactul acestei schimbări, dar ne așteptăm ca aceasta să reducă semnificativ taxele.

De asemenea, Bedrock elimină toate costurile de gaz asociate cu execuția EVM atunci când trimiteți date la L1, ceea ce va reduce costurile cu încă 10% față de versiunile anterioare ale protocolului.

Timp de credit de depozit mai scurt

Bedrock a introdus suport pentru reorganizările L1 în software-ul nodului, ceea ce reduce semnificativ timpul pe care utilizatorii trebuie să aștepte ca depozitele să fie creditate.

Versiunile anterioare ale protocolului ar putea dura până la 10 minute pentru ca depozitele să fie confirmate, în timp ce cu Bedrock ne așteptăm ca depozitele să fie confirmate în 3 minute.

Dovada modulară îmbunătățită

Bedrock extrage sistemul de dovezi din stiva OP, astfel încât pachetul să poată utiliza dovezi de eșec sau dovezi de validitate (cum ar fi zk-SNARK) pentru a dovedi execuția corectă după introducerea în rollup. Această abstractizare va permite, de asemenea, utilizarea Cannon pentru a demonstra eroare de sistem.

Performanța nodului îmbunătățită

Performanța software-ului nod este îmbunătățită semnificativ prin executarea mai multor tranzacții într-un singur „bloc” cumulat în loc de modelul „o tranzacție per bloc” din versiunile anterioare.

Acest lucru permite ca costul actualizărilor Merkle Trie să fie împărțit în mai multe tranzacții, ceea ce la volumele actuale de tranzacții reduce creșterea datelor de stat cu aproximativ 15 GB pe an.

Performanța nodului a fost, de asemenea, îmbunătățită în continuare prin eliminarea datoriilor tehnice din versiunile anterioare ale protocolului, inclusiv prin eliminarea necesității unui nod separat de „nivel de transport de date” pentru a indexa L1 și prin actualizarea software-ului nodului pentru a interoga eficient tranzacțiile din datele L1.

Echivalența Ethereum îmbunătățită

Bedrock a fost conceput de la început pentru a fi cât mai „consecvent” cu Ethereum, iar multe abateri de la Ethereum în versiunile anterioare ale protocolului au fost eliminate, inclusiv:

• Model „O tranzacție pe bloc”;

• Personalizați opcode pentru a obține informații despre bloc L1;

• Câmpuri separate de cost L1/L2 în API-ul JSON-RPC;

• Reprezentare personalizată ERC20 a soldurilor ETH.

Bedrock a adăugat, de asemenea, suport pentru EIP-1559, reorganizarea blockchain și alte funcții Ethereum prezente pe L1.

Principii de proiectare

Bedrock este construit pentru a fi modular și scalabil în timp ce reutiliza codul existent de la Ethereum și urmărește să atingă echivalența Ethereum de 100% ori de câte ori este posibil.

Modular

Folosind interfețe și scheme de versiuni bine definite, Bedrock poate înlocui cu ușurință diferite componente din stiva OP și poate adăuga funcționalități noi.

Acest lucru îi permite să se adapteze la dezvoltarea viitoare a ecosistemului Ethereum cu o arhitectură flexibilă, cum ar fi:

• Nodul rollup este separat de clientul de execuție;

• Design modular rezistent la erori.

reutilizarea codului

Bedrock folosește arhitectura și infrastructura Ethereum existente ori de câte ori este posibil. Această abordare permite OP Stack să moștenească avantajele de securitate și efectul Lindy de la baza de coduri testate în luptă folosită de rețeaua principală Ethereum.

Veți găsi exemple în acest sens pe parcursul designului, inclusiv:

• client de execuție minim modificat;

• Contracte EVM în loc de codul client precompilat.

Echivalența Ethereum

Bedrock este conceput pentru a fi compatibil maxim cu experiențele existente ale dezvoltatorilor Ethereum, dar există câteva excepții datorate diferențelor fundamentale dintre L1 și rollup: diferite modele de taxe, timpi de blocare mai rapidi (2 secunde față de 12 secunde) și tipuri speciale de tranzacții, inclusiv tranzacții de depozit L1.

Aceste excepții includ:

• Verificarea erorilor clienților de execuție Ethereum menite să dovedească modificări minime;

• Ethereum realizează reutilizarea codului pe partea clientului pentru utilizarea de către noduri și ordonanți din rețeaua L2.

protocol

Rollup-urile sunt construite pe disponibilitatea datelor (de obicei, un blockchain L1, cum ar fi Ethereum, în cea mai comună configurație, protocolul de rollup derivă un „lanț canonic L2” din două surse principale de informații:

• Datele de tranzacție sunt publicate la L1 de către secvențior;

• Tranzacțiile de depozit sunt transmise de conturi și contracte inteligente la contractul bridge pe L1.

Următoarele sunt componentele de bază ale acordului:

• Prin interacțiunea directă cu contractul inteligent pe L1, depozitul este înscris în „lanțul standard L2”;

• Retragerile sunt scrise în „lanțul canonic L2” și implicit declanșează interacțiuni cu contracte și conturi inteligente pe L1;

• Loturile sunt scrieri de date corespunzătoare loturii în rollup;

• Derivarea blocurilor este modul de interpretare a datelor citite pe L1 pentru a înțelege „lanțul canonic L2”;

• Sistemul de probă definește finalitatea rădăcinilor de ieșire publicate pe L1, astfel încât acestea să poată fi executate (de exemplu, efectuarea retragerilor).

depozit

Depunerea este o tranzacție pe L1 și va fi inclusă în pachet. Prin definiție, depozitele sunt garantate a fi incluse în „lanțul canonic L2” ca mijloc de a preveni cenzura sau controlul L2.

Orice mesaj livrat din L1

Tranzacțiile de depozit sunt tranzacții cumulate efectuate ca parte a unui depozit. Cu Bedrock, depozitele sunt tranzacții Ethereum complet universale, cum ar fi conturile pe Ethereum sau contractele inteligente pot crea contracte de „depozit”.

Bedrock definește un contract de depozit disponibil pe L1: este un contract inteligent cu care conturile L1 și contractele inteligente pot interacționa pentru a scrie la L2. Tranzacțiile de depozit pe L2 sunt derivate din tranzacțiile emise de acest contract de depozit și includ parametri așteptați, cum ar fi de la, către și date.

Vă rugăm să consultați secțiunea Specificații contractului de depozit pentru detalii.

Cumpărați benzină L2 garantată pe L1

De asemenea, Bedrock a clarificat mecanismul de ardere a gazului și piața comisionului de depozit Gazul cheltuit pe L2 prin tranzacții de depozit este achiziționat pe L1 prin arderea gazului.

Acest gaz este achiziționat în mod special pe piața taxelor și există o limită strictă a cantității totale de gaz furnizate pentru toate tranzacțiile de depozit într-un singur bloc L1. Acest mecanism este utilizat pentru a preveni atacurile de tip Denial of Service (DoS) care ar putea apărea. Când scrieți tranzacții de la L1 la L2, deoarece aceste tranzacții consumă mult Gaz pe L2, dar sunt foarte ieftine pe L1.

Gazul furnizat pentru tranzacțiile de depozit este uneori numit „Garant garantat”. Gazul garantat este unic prin faptul că este plătit prin arderea gazului pe L1 și, prin urmare, este nerambursabil.

Iar cantitatea totală de gaz L1 necesară pentru a fi ars per unitate de gaz L2 garantat depinde de prețul gazului L2 raportat de mecanismul de încărcare în stil EIP-1559. În plus, utilizatorii primesc o alocație dinamică de gaz bazată pe cantitatea de gaz L1 cheltuită pentru calcularea actualizărilor mecanismului de taxare.

Pentru o explicație mai aprofundată, vă rugăm să citiți specificațiile protocolului din secțiunea de depozit.

Retrage bani

Retragerile sunt tranzacții încrucișate inițiate pe L2 și finalizate cu tranzacții executate pe L1. Este de remarcat faptul că conturile L2 pot folosi retrageri pentru a apela contracte L1 sau pentru a transfera ETH din conturile L2 în conturile L1.

Retragerea este inițiată prin apelarea contractului preinstalat Message Passer pe L2, care înregistrează proprietățile importante ale mesajului în stocarea acestuia, iar apoi retragerea este finalizată pe L1 apelând contractul OptimismPortal pentru a dovedi includerea acestui mesaj de retragere.

În acest fel, retragerile și depozitele sunt diferite: tranzacțiile de retragere trebuie finalizate folosind contracte inteligente pe L1, mai degrabă decât bazându-se pe informațiile derivate din blocuri.

Proces de retragere în două etape

Erorile de validare a dovezii de retragere sunt cauza principală a multor hack-uri de poduri încrucișate în ultimii ani. Versiunea Bedrock introduce un pas suplimentar în procesul de retragere a versiunilor anterioare menite să ofere o apărare suplimentară împotriva acestor tipuri de erori.

În procesul de retragere în două etape, fiecare retragere trebuie să prezinte dovada Merkle corespunzătoare retragerii cu 7 zile înainte de ieșirea finală. Acest nou mecanism de securitate oferă instrumentelor de monitorizare 7 zile întregi pentru a găsi și detecta dovada retragerii.

Dacă certificatul de retragere se dovedește a fi invalid în această perioadă, reparațiile smart contract pot fi implementate înainte ca fondurile să fie pierdute, ceea ce reduce foarte mult riscul de compromitere a podurilor încrucișate.

Vă rugăm să consultați secțiunea Specificații privind acordul de retragere pentru detalii.

Loturi

În Bedrock, un format cu fir este definit pentru transmiterea mesajelor între L1 și L2 (adică L2 derivă blocuri din L1, L2 scrie tranzacții în L1), acest format cu fir este conceput pentru a reduce costul de scriere în L1 și complexitatea software-ului la minimum.

Optimizați compresia datelor

Pentru a optimiza compresia datelor, listele de tranzacții L2 (numite loturi de secvențe) sunt organizate în grupuri de obiecte (numite canale). Dimensiunea maximă a fiecărui canal poate fi definită în parametrul configurabil, care va fi setat inițial la 9,5 M. Aceste canale. este de așteptat să fie comprimat folosind funcția de compresie și trimis la L1.

transmitere în paralel în lot

Pentru a paraleliza mesajele de la secvențiale care trimit date de canal comprimate la L1, canalele sunt descompuse în continuare în „cadre de canal”, care sunt bucăți de date de canal comprimate care se pot încadra într-o singură tranzacție L1.

Presupunând că „cadrele de canal” sunt independente unele de altele și ordinea este cunoscută, tranzacțiile Ethereum trimise către L1 de către secvenționar pot fi trimise în paralel, reducând astfel la minimum complexitatea software-ului sequencerului și permițând umplutura Tot spațiul de date disponibil pe L1.

Minimizarea gazului Ethereum

Bedrock elimină toate gazele de execuție utilizate de sistemul L1 pentru a trimite date de canal către L1 în tranzacțiile numite „tranzacții de lot”. Toată logica de verificare care a avut loc anterior pe contractele inteligente L1 a fost mutată în logica de derivare a blocului. În schimb, „tranzacțiile cu lot” sunt trimise la o singură adresă EOA pe Ethereum, numită „adresă de inbox de lot”.

Loturile sunt încă supuse verificărilor de valabilitate (adică trebuie să fie codificate corect), la fel ca și tranzacțiile individuale din lot (de exemplu, semnăturile trebuie să fie valide), loturile nevalide și tranzacțiile individuale invalide din loturi valide sunt considerate eliminate și irelevante pentru sistem.

Notă: Ethereum va fi actualizat în curând la o nouă versiune care include EIP-4844, care introduce o piață separată a taxei de scriere a datelor și crește limita superioară a cantității de date pe care protocolul Ethereum este dispus să o reducă și mai mult numărul de Costuri asociate cu publicarea în L1.

Pentru o explicație mai aprofundată, citiți Specificația formatului cablului.

Derivarea blocurilor

În Bedrock, protocolul este conceput pentru a se asigura că sincronizarea depozitelor pe L1 este legată de derivarea în bloc a „lanțului canonic L2”. Ceea ce face aceasta este o funcție pură de scriere a datelor în L1 prin intermediul proprietăților de secvențiere, depozit și bloc L1.

Pentru a realiza acest lucru, protocolul definește strategii pentru garantarea depozitelor, gestionarea marcajelor de timp L1 și L2 și gestionarea ferestrelor de comandă în canal pentru a asigura o comandă corectă.

Depozit garantat în cont

Obiectivele protocolului de derivare a blocurilor sunt definite după cum urmează:

După ce a trecut fiecare „interval de bloc L2”, trebuie să existe un bloc L2, iar marcajul de timp al blocului L2 este sincronizat cu marcajul de timp al L1 (adică, asigurându-se că depozitele sunt incluse în ordinea cronologică logică).

În Bedrock, este introdus conceptul de „epocă de secvențiere”: este gama de blocuri L2 derivate dintr-o serie de blocuri L1. Fiecare epocă este identificată printr-un „număr de epocă”, care este egal cu numărul din fereastra de sortare. Numărul de secvență al primului bloc L1. Mărimea epocilor poate varia, sub rezerva unor restricții.

Canalul derivat din lot consideră marcajul de timp al blocului L1 asociat cu „numărul epocii” ca ancora pentru determinarea ordinii tranzacțiilor pe L2. Protocolul garantează că primul bloc L2 al unei epoci nu va rămâne niciodată în urmă marcajului de timp al blocului L1 al epocii potrivite. Primul bloc al unei epoci trebuie să conțină depozite pe L1 pentru a garanta că depozitul va fi procesat.

Rețineți că în versiunea Bedrock, ținta intervalului de bloc pe L2 este configurată la 2 secunde.

Gestionarea marcajelor de timp L1 și L2

Bedrock încearcă să rezolve problema reconcilierii marcajelor de timp de pe L2 cu marcajele de timp de pe L1 care există în tranzacțiile de depozit.

Face acest lucru permițând o fereastră de timp scurtă pentru sortare pentru a aplica în mod liber marcajele de timp pe tranzacțiile L2 între epoci.

Fereastra de secvențiere este succesiunea de blocuri L1 din care pot fi derivate epocile. Într-o fereastră de sortare, primul număr de bloc L1 N conține „tranzacțiile lotului” ale epocii.​

Fereastra de sortare conține blocuri, care depinde de dimensiunea ferestrei de sortare: un parametru fix de configurare a nivelului de rulare trebuie să fie de cel puțin 2, creșterea acestuia va oferi secvențatorului mai multe oportunități de a sorta tranzacțiile L2 pe depozite, scăzându-l pentru secvențiere Timpul mai strict fereastra introdusă de server pentru a trimite „tranzacții batcher”. Acesta este un compromis între crearea de oportunități MEV și creșterea complexității software-ului.

O constantă de protocol numită „max sequencer drift” controlează marca temporală maximă pe care o poate avea un bloc în epoca sa.

Blocați conducta furcii

„Lanțul L2 canonic” poate fi procesat de la zero, pornind de la starea de geneză L2, setând începutul lanțului L2 la prima epocă și apoi procesând toate ferestrele de sortare pentru a determina loturile de secvențiere în conformitate cu următoarea ordine simplificată și secvența corectă pentru țevi de depozitare:

Dovada de esec

După ce secvențiatorul procesează unul sau mai multe blocuri L2, ieșirile din calculele tranzacțiilor executate în aceste blocuri vor trebui scrise în L1 pentru a permite executarea fără încredere a mesajelor L2 la L1, cum ar fi retragerile etc.

În Bedrock, rezultatul este hashing sub forma unei structuri arborescente, minimizând costul dovedirii oricărei date captate de rezultat. Proponenții trimit periodic rădăcini de ieșire la L1 care servesc drept rădăcini Merkle pentru întregul „lanț canonic L2”.

Actualizările viitoare ale stivei OP ar trebui să includă o specificare a unei variante rezistente la eșec, cu legături pentru a stimula propunerii să propună rădăcini de ieșire corecte.

Pentru detalii complete, citiți specificația protocolului din secțiunea Propunere de rădăcină de ieșire L2.

implementează

În Bedrock, OP Stack trebuie să se bazeze în mare măsură pe separarea specificată de Ethereum a preocupărilor tehnice, reflectând separarea dintre stratul de execuție al lui Ethereum și stratul de consens.

Așadar, Bedrock a introdus separarea clienților de execuție și a nodurilor rollup în același mod.

Executați clientul

Clienții de execuție sunt sisteme pe care secvențierele și alte tipuri de operatori de noduri le rulează pentru a determina starea lanțului canonic L2. De asemenea, îndeplinește și alte funcții, cum ar fi gestionarea tranzacțiilor de intrare și comunicațiile peer-to-peer, precum și procesarea stării sistemului pentru a gestiona interogările îndreptate împotriva acestuia.

Cu Bedrock, OP Stack își propune să refolosească specificația clientului de execuție proprie Ethereum și multe dintre operațiunile sale de execuție. În această versiune, Bedrock a demonstrat o modificare extrem de limitată a clientului Ethereum go-ethereum, cu o diferență de mai puțin de 2000 de linii de cod.

Există două motive fundamentale pentru diferență: procesarea tranzacțiilor de depozit și perceperea taxelor de tranzacție.

Procesează tranzacțiile de depozit

Pentru a reprezenta tranzacțiile depuse într-un pachet cumulat, este introdus un tip de tranzacție suplimentar. Implementarea clienților care implementează acest nou tip de tranzacție se bazează pe standardul de tranzacție de tip EIP-2718.

percepe comisioane de tranzacție

De asemenea, pachetele cumulate au în esență două tipuri de taxe legate de tranzacții:

Una este taxa de secvențiere. Costul de funcționare a secvențatorului este calculat folosind același tabel de gaz și același algoritm EIP-1559 ca Ethereum, care este utilizat de protocol pentru a opera secvențiatorul și fluctuează în timp în funcție de congestionarea rețelei.

O altă taxă de disponibilitate a datelor. Costurile de disponibilitate a datelor sunt asociate cu scrierea tranzacțiilor în lot la L1 și sunt destinate să acopere taxele secvențerului pentru trimiterea tranzacțiilor în lot la L1.

În Bedrock, partea de disponibilitate a datelor a taxei este determinată pe baza informațiilor din contractul inteligent al sistemului de acumulare numit GasPriceOracle, care se bazează pe atributele blocului L1 inserate la începutul fiecărei epoci în timpul procesului de derivare a blocurilor este actualizat.

Bedrock specifică faptul că ambele costuri sunt adăugate într-un singur câmp atunci când se utilizează JSON-RPC.

nod rollup

Spre deosebire de Ethereum, Bedrock nu are consens PoS. În contrast, consensul unui „lanț L2 canonic” este definit prin derivarea blocului. Clientul de execuție al OP Stack comunică cu o nouă componentă care implementează blocarea blocului numită nod rollup, care comunică cu clientul de execuție folosind exact același motor API ca Ethereum.

Nodul rollup este o componentă apatridă responsabilă de derivarea stării sistemului prin citirea datelor și a depozitelor pe L1. În Bedrock, nodurile de acumulare pot fi folosite pentru a ordona tranzacțiile primite de la utilizatori sau alte noduri de acumulare sau pentru a valida tranzacțiile confirmate publicate pe L1 bazându-se exclusiv pe L1.

Diferitele utilizări ale nodurilor rollup sunt rezumate mai jos:

Verificați „lanțul L2 canonic”

Cel mai simplu mod de rulare a nodurilor de rulare este să urmați doar „lanțul canonic L2”. În acest mod, nodul rollup nu are egali și este strict folosit pentru a citi datele din L1 și a interpreta datele conform regulilor protocolului de derivare a blocurilor.

Unul dintre scopurile unui astfel de nod este de a verifica dacă orice rădăcină de ieșire partajată de alte noduri sau publicată pe L1 este corectă conform definiției protocolului. În plus, propunetorii care intenționează să trimită rădăcini de ieșire la L1 pot folosi ei înșiși optimism_outputAtBlock pentru a genera rădăcinile de ieșire de care au nevoie și să returneze hash-ul de 32 de octeți corespunzător rădăcinii de ieșire L2.

Pentru a face acest lucru, nodurile ar trebui să urmeze doar antetul blocului „finalizat”. Termenul „finalizat” se referă la consensul PoS Ethereum (adică canonic și aproape ireversibil), iar antetul blocului L2 „finalizat” este zona „lanțului L2 canonic” derivat doar din blocul L1 „finalizat”. cap.

Participați la rețeaua L2

Cel mai obișnuit mod de a utiliza un nod de acumulare este de a participa la o rețea de alte noduri de acumulare, urmărind procesele și starea L2. În acest mod, nodul de acumulare citește simultan datele și depozitele pe care le observă din L1, le interpretează în blocuri și acceptă tranzacții de intrare de la utilizatori și colegi din rețeaua altor noduri de acumulare.

Nodurile care participă în rețea pot folosi anteturile blocului securizate și nesigure ale L2 cu care se sincronizează.

• Anteturile blocurilor L2 securizate reprezintă pachete care pot fi construite în care fiecare bloc (inclusiv anteturile) poate fi derivat complet din lanțul L1 de referință înainte ca L1 să fie „finalizat” (adică reorganizarea poate avea loc în continuare pe L1);

• Antetele blocurilor L2 nesigure includ blocuri nesigure care nu au fost derivate din L1. Aceste blocuri fie provin din operarea nodului rollup ca secvenționar, fie din sincronizarea nesigură cu secvențiatorul. Acesta este, de asemenea, numit „cel mai recent” antet de bloc. În caz de dezacord, alegeți întotdeauna antetul blocului L2 sigur peste antetul blocului L2 nesigur. Când apare un dezacord, porțiunea nesigură a lanțului se va reorganiza;

În cele mai multe cazuri, pentru aplicațiile utilizatorului final, nodurile de acumulare din rețeaua L2 vor face referire la anteturile blocurilor L2 nesigure.

Sortarea tranzacțiilor

A treia modalitate de a utiliza nodurile de acumulare este de a comanda tranzacții. În acest mod, nodurile de acumulare vor crea blocuri noi pe deasupra antetelor de bloc L2 nesigure. În prezent, există un singur sequencer per rețea OP Stack.

Sequencerul este, de asemenea, responsabil pentru publicarea loturilor de tranzacții la L1, astfel încât alte noduri din rețea să se poată sincroniza de la acesta.

Dozator

Rolul unui secvențietor este de a produce loturi de tranzacții, în acest scop secvențialele pot rula noduri de rulare și au procese separate care execută loturi citind din nodurile de rulare de încredere pe care rulează.

Acest lucru asigură că o componentă suplimentară a stivei OP, numită handler de tranzacții în lot, citește datele tranzacției din nodul rollup și le interpretează într-o tranzacție batch care urmează să fie scrisă în L1, componenta batcher este responsabilă pentru citirea și rularea de către Sequencerul Nodul rulează antetul blocului L2 nesigur, creează tranzacții de tip lot și le scrie în L1.

Contract de pod standard

Bedrock include, de asemenea, o pereche de contracte bridge pentru cele mai comune tipuri de depozite, numite Standard Bridge Contract. Aceste contracte încapsulează contractele de depunere și retragere, oferind o interfață simplă pentru depunerile și retragerile de jetoane ETH și ERC-20.

Aceste contracte de legătură sunt proiectate astfel încât o parte a punții de lanț încrucișat să aibă jetonul nativ, iar cealaltă parte să conțină un jeton împachetat care poate gestiona baterea și arderea jetonului nativ implică blocarea jetonului nativ în contract și apoi blocarea Jeton nativ în podul cu lanțuri încrucișate Cealaltă parte bate o cantitate egală de jetoane încapsulate.

Pentru mai multe informații, consultați secțiunea Standard Cross-Chain Bridge Protocol Specification.

Tun

În timp ce construirea și verificarea cu siguranță sunt implementate în Cannon, specificația jocului cu siguranță și integrarea challenger-ului rădăcină de ieșire în nodul de acumulare fac parte din etapele ulterioare ale specificațiilor.

Lectură în continuare

Specificarea protocolului

Specificația protocolului definește detaliile tehnice ale stivei OP și este cea mai actualizată sursă de adevăr despre funcționarea interioară a protocolului.

Diferența de bază

Pentru o privire în profunzime asupra diferențelor dintre Bedrock și versiunile anterioare, consultați Cum este Bedrock diferit.