Documentação Técnica Optimism

Oleh Optimism Collective · 2021

Optimism tidak memiliki whitepaper tradisional. Sebagai optimistic rollup Ethereum Layer 2, desain dan spesifikasinya didokumentasikan melalui dokumentasi teknis, spesifikasi OP Stack, dan postingan riset, bukan satu makalah akademik formal tunggal.

🇺🇸 English (Asli)

🇧🇷 Português (Terjemahan)

Abstrak

Makalah ini membahas masalah skalabilitas dalam blockchains yang terdesentralisasi dengan menganalisis trade-off antara throughput transaksi dan persyaratan perangkat keras untuk menjalankan sebuah node. Rollup, yaitu teknologi untuk verifikasi on-chain dari blok yang dieksekusi secara off-chain, disajikan dalam bentuk bukti kesalahan atau validitas. Kami membandingkan Rollup Optimis dan Rollup Validitas sehubungan dengan waktu penarikan, biaya transaksi, teknik pengoptimalan, dan kompatibilitas dengan ekosistem Ethereum. Analisis kami menunjukkan bahwa Optimism Batuan Dasar saat ini memiliki laju kompresi gas sekitar 20:1, sementara StarkNet mencapai laju kompresi biaya tulis penyimpanan sekitar 24:1. Kami juga membahas teknik untuk lebih mengoptimalkan tarif ini, seperti penggunaan kontrak cache dan filter Bloom. Pada akhirnya, kesimpulan kami menyoroti trade-off antara kompleksitas dan kelincahan dalam pilihan antara Optimistic dan Validity Rollup. Kata Kunci Blockchain, Skalabilitas, Rollup 1. Pendahuluan Teknologi Blockchain telah mendapatkan perhatian yang signifikan karena potensinya untuk merevolusi berbagai industri. Namun, skalabilitas tetap menjadi tantangan besar, karena sebagian besar blockchain menghadapi trade-off antara skalabilitas, desentralisasi, dan keamanan, yang biasa disebut sebagai Trilema Skalabilitas [1, 2]. Untuk meningkatkan throughput blockchain, solusi sederhana adalah dengan meningkatkan ukuran bloknya. Dalam konteks Ethereum, hal ini berarti meningkatkan jumlah maksimum gas yang dapat ditampung suatu blok. Karena setiap node penuh harus memvalidasi setiap transaksi di setiap blok, seiring dengan peningkatan throughput, kebutuhan perangkat keras juga meningkat, sehingga menyebabkan sentralisasi jaringan yang lebih besar. Beberapa blockchain, seperti Bitcoin dan Ethereum, mengoptimalkan desainnya untuk memaksimalkan desentralisasi arsitekturnya, sementara yang lain, seperti Binance Smart Chain dan Solana, dirancang agar secepat dan semurah mungkin. Jaringan terdesentralisasi secara artifisial membatasi throughput blockchain untuk menurunkan persyaratan perangkat keras untuk berpartisipasi dalam jaringan. Selama bertahun-tahun, upaya telah dilakukan untuk menemukan solusi terhadap Trilema, seperti saluran negara [3] dan Plasma [4, 5]. Solusi ini memiliki karakteristik memindahkan beberapa aktivitas di luar rantai, menghubungkan aktivitas di dalam rantai dengan aktivitas di luar rantai menggunakan smart contracts, dan memverifikasi DLT 2023: Lokakarya Teknologi Buku Besar Terdistribusi ke-5, 25-26 Mei 2023, Bologna, Italia $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Hak cipta untuk makalah ini oleh penulisnya. Penggunaan diizinkan berdasarkan Creative Commons License Attribution 4.0 International (CC BY 4.0). Prosiding Lokakarya CEUR http://ceur-ws.org ISSN 1613-0073 Prosiding Lokakarya CEUR (CEUR-WS.org) on-chain apa yang terjadi di luar rantai. Namun, saluran Plasma dan negara terbatas dalam mendukung smart contracts umum. Rollup adalah blockchain (disebut Layer 2 atau L2) yang memublikasikan bloknya di blockchain lain (Layer 1 atau L1) dan oleh karena itu mewarisi properti konsensus, ketersediaan data, dan keamanannya. Berbeda dengan solusi lainnya, solusi ini mendukung komputasi arbitrer. Rollup memiliki tiga komponen utama: • Sequencer: node yang menerima transaksi Rollup dari pengguna dan menggabungkannya ke dalam blok yang dikirim ke Layer 1. Blok tersebut setidaknya terdiri dari root negara (misalnya root Merkle) dan data yang diperlukan untuk merekonstruksi dan memvalidasi negara. Layer 1 mendefinisikan...

Resumo

O artigo aborda o problema de escalabilidade em blockchains descentralizados analisando a compensação entre o rendimento da transação e os requisitos de hardware para executar um nó. Rollups, ou seja, tecnologias para verificação on-chain de blocos executados fora da cadeia, são apresentados na forma de provas de falha ou de validade. Comparamos Rollups Otimistas e Rollups de Validade em relação ao tempo de retirada, custos de transação, técnicas de otimização e compatibilidade com o ecossistema Ethereum. Nossa análise revela que Optimism Bedrock atualmente tem uma taxa de compressão de gás de aproximadamente 20:1, enquanto StarkNet atinge uma taxa de compressão de custo de gravação de armazenamento de cerca de 24:1. Também discutimos técnicas para otimizar ainda mais essas taxas, como o uso de contratos de cache e filtros Bloom. Em última análise, as nossas conclusões destacam os compromissos entre complexidade e agilidade na escolha entre rollups otimistas e de validade. Palavras-chave Blockchain, Escalabilidade, Rollup 1. Introdução A tecnologia Blockchain ganhou atenção significativa devido ao seu potencial para revolucionar vários setores. No entanto, a escalabilidade continua a ser um grande desafio, já que a maioria dos blockchains enfrentam um compromisso entre escalabilidade, descentralização e segurança, comumente referido como o Trilema da Escalabilidade [1, 2]. Para aumentar o rendimento de um blockchain, uma solução trivial é aumentar o tamanho do bloco. No contexto de Ethereum, isso significa aumentar a quantidade máxima de gás que um bloco pode conter. Como cada nó completo deve validar todas as transações de cada bloco, à medida que o rendimento aumenta, os requisitos de hardware também aumentam, levando a uma maior centralização da rede. Alguns blockchains, como Bitcoin e Ethereum, otimizam seu design para maximizar sua descentralização arquitetônica, enquanto outros, como Binance Smart Chain e Solana, são projetados para serem o mais rápidos e baratos possível. As redes descentralizadas limitam artificialmente o rendimento do blockchain para reduzir os requisitos de hardware para participar da rede. Ao longo dos anos, foram feitas tentativas para encontrar uma solução para o Trilema, como os canais estaduais [3] e Plasma [4, 5]. Essas soluções têm a característica de mover algumas atividades para fora da cadeia, vincular atividades on-chain a atividades fora da cadeia usando smart contracts e verificar DLT 2023: 5th Distributed Ledger Technology Workshop, 25 a 26 de maio de 2023, Bolonha, Itália $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Direitos autorais deste artigo de seus autores. Uso permitido sob Creative Commons License Attribution 4.0 International (CC BY 4.0). Procedimentos do Workshop CEUR http://ceur-ws.org ISSN 1613-0073 Procedimentos do Workshop CEUR (CEUR-WS.org) na rede o que está acontecendo fora da rede. No entanto, os canais de plasma e de estado são limitados no suporte a smart contracts gerais. Rollups são blockchains (chamados Layer 2 ou L2) que publicam seus blocos em outro blockchain (Layer 1 ou L1) e, portanto, herdam seu consenso, disponibilidade de dados e propriedades de segurança. Elas, ao contrário de outras soluções, suportam computação arbitrária. Rollups possuem três componentes principais: • Sequenciadores: nós que recebem transações Rollup de usuários e as combinam em um bloco que é enviado para Layer 1. O bloco consiste em pelo menos a raiz do estado (por exemplo, uma raiz Merkle) e os dados necessários para reconstruir e validar o estado. O Layer 1 define o...

Perkenalan

Pendahuluan Teknologi Blockchain telah mendapatkan perhatian yang signifikan karena potensinya untuk melakukan revolusi berbagai industri. Namun, skalabilitas tetap menjadi tantangan besar, seperti yang dihadapi sebagian besar blockchain trade-off antara skalabilitas, desentralisasi, dan keamanan, yang biasa disebut sebagai Trilema Skalabilitas [1, 2]. Untuk meningkatkan throughput blockchain, solusi yang sepele adalah untuk meningkatkan ukuran bloknya. Dalam konteks Ethereum, ini berarti meningkatkan secara maksimal jumlah gas yang dapat ditampung suatu blok. Karena setiap node penuh harus memvalidasi setiap transaksi blok, seiring dengan peningkatan throughput, kebutuhan perangkat keras juga meningkat, sehingga menyebabkan lebih besar sentralisasi jaringan. Beberapa blockchain, seperti Bitcoin dan Ethereum, mengoptimalkannya desain untuk memaksimalkan desentralisasi arsitekturnya, sementara yang lain, seperti Binance Smart Chain dan Solana, dirancang secepat dan semurah mungkin. Jaringan terdesentralisasi membatasi throughput blockchain secara artifisial untuk menurunkan persyaratan perangkat keras berpartisipasi dalam jaringan. Selama bertahun-tahun, upaya telah dilakukan untuk menemukan solusi terhadap Trilema, seperti negara saluran [3] dan Plasma [4, 5]. Solusi-solusi ini mempunyai ciri-ciri menggerakkan suatu aktivitas off-chain, menghubungkan aktivitas on-chain ke aktivitas off-chain menggunakan smart contracts, dan memverifikasi DLT 2023: Lokakarya Teknologi Buku Besar Terdistribusi ke-5, 25-26 Mei 2023, Bologna, Italia $ [email protected] (L.Donno) https://lucadonnoh.github.io/ (L.Donno) 0000-0001-9221-3529 (L.Donno) © 2023 Hak cipta untuk makalah ini oleh penulisnya. Penggunaan diizinkan berdasarkan Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Bengkel Proses http://ceur-ws.org ISSN 1613-0073 Prosiding Lokakarya CEUR (CEUR-WS.org)on-chain apa yang terjadi di off-chain. Namun, saluran Plasma dan negara terbatas dukungan mereka terhadap smart contracts umum. Rollup adalah blockchain (disebut Layer 2 atau L2) yang memublikasikan bloknya di blockchain lain (Layer 1 atau L1) dan karenanya mewarisi properti konsensus, ketersediaan data, dan keamanannya. Mereka, tidak seperti solusi lain, mendukung komputasi sewenang-wenang. Rollup memiliki tiga komponen utama: • Sequencer: node yang menerima transaksi Rollup dari pengguna dan menggabungkannya menjadi a blok yang dikirim ke Layer 1. Blok tersebut setidaknya terdiri dari root negara (misalnya Merkle root) dan data yang diperlukan untuk merekonstruksi dan memvalidasi keadaan. Layer 1 mendefinisikan kanonik blockchain dari L2 dengan menetapkan urutan data yang dipublikasikan. • Rollup full node: node yang memperoleh, memproses dan memvalidasi blok Rollup dari Layer 1 dengan memverifikasi bahwa root sudah benar. Jika sebuah blok berisi transaksi yang tidak valid, maka itu adalah blok tersebut dibuang, yang mencegah Sequencer membuat blok valid yang menyertakan blok tidak valid transaksi. • Rollup light node: node yang memperoleh blok Rollup dari Layer 1 tetapi tidak melakukan komputasi negara baru itu sendiri. Mereka memverifikasi bahwa root negara baru valid menggunakan teknik seperti bukti kesalahan atau keabsahan. Rollup mencapai skalabilitas dengan mengurangi biaya transaksi yang diamortisasi sebagai jumlahnya jumlah pengguna meningkat. Hal ini karena biaya untuk memastikan validitas blockchain meningkat secara sub-linear sehubungan dengan biaya verifikasi transaksi secara individual. Rollup berbeda menurut mekanisme yang digunakan untuk memastikan validitas eksekusi transaksi pada node ringan: in Rollup Optimis itu dijamin oleh model ekonomi dan bukti kesalahan, sementara dalam Validitas Rollup itu dipastikan secara kriptografis menggunakan bukti validitas. Node cahaya dapat diimplementasikan sebagai smart contracts pada Layer 1. Mereka menerima akar dari keadaan baru dan verifikasi validitas atau bukti kesalahan: Oleh karena itu, Rollup ini disebut Kontrak Cerdas Rollup. Jika light node bersifat independen, maka disebut Sovereign Rollup [6]. Keuntungan dari menggunakan Smart Contract Rollup adalah untuk dapat membangun jembatan kepercayaan yang diminimalkan antara keduanya blockchains : karena keabsahan status L2 terbukti hingga L1, maka sistem transaksi dari L2 hingga L1 dapat diterapkan, memungkinkan penarikan. Kerugiannya adalah biaya transaksi tergantung pada biaya verifikasi keadaan pada L1: jika lapisan dasar jenuh aktivitas lainnya, biaya transaksi pada Rollup juga meningkat. Lapisan data dan konsensus inilah yang menentukan keamanan sistem mereka menentukan urutan transaksi, mencegah serangan, dan menyediakan data untuk membuktikan keadaan validitas. Kontribusi kertas Dalam makalah ini, kami mempelajari Optimistic dan Validity Rollup, dua yang inovatif solusi Trilema Skalabilitas, dengan fokus pada implementasi penting, seperti Optimism Batuan Dasar dan StarkNet. Kontribusi kami mencakup perbandingan komprehensif mengenai hal-hal tersebut solusi, analisis waktu penarikan, dan diskusi tentang kemungkinan serangan terhadap Optimism Batuan dasar. Selain itu, kami menghitung rasio kompresi gasnya, memberikan pengoptimalan khusus aplikasi, dan menyajikan keuntungan dan kerugian jika beralih dari Ethereum Mesin Virtual (EVM).

Struktur kertas Makalah ini disusun sebagai berikut. Di bagian 2 Rollup Optimis adalah diperkenalkan dengan menganalisis Optimism Batuan Dasar. Di bagian 3 Validitas Rollup diperkenalkan oleh menganalisis StarkNet. Di bagian 4 kami membandingkan kedua solusi. Terakhir, di bagian 5 kita menggambar beberapa kesimpulan.

Introdução

Introdução A tecnologia Blockchain ganhou atenção significativa devido ao seu potencial para revolucionar diversas indústrias. No entanto, a escalabilidade continua a ser um grande desafio, uma vez que a maioria dos blockchains enfrentam um compromisso entre escalabilidade, descentralização e segurança, comumente referido como o Trilema de escalabilidade [1, 2]. Para aumentar o rendimento de um blockchain, uma solução trivial é para aumentar o tamanho do bloco. No contexto de Ethereum, isso significa aumentar o máximo quantidade de gás que um bloco pode conter. Como cada nó completo deve validar todas as transações de cada bloco, à medida que a taxa de transferência aumenta, os requisitos de hardware também aumentam, levando a um maior centralização da rede. Alguns blockchains, como Bitcoin e Ethereum, otimizam seus design para maximizar sua descentralização arquitetônica, enquanto outros, como o Binance Smart Chain e Solana são projetados para serem o mais rápidos e baratos possíveis. Redes descentralizadas limitar artificialmente o rendimento do blockchain para reduzir os requisitos de hardware para participar da rede. Ao longo dos anos, foram feitas tentativas para encontrar uma solução para o Trilema, tais como medidas estatais canais [3] e Plasma [4, 5]. Estas soluções têm a característica de movimentar alguma atividade fora da cadeia, vinculando a atividade na cadeia à atividade fora da cadeia usando smart contracts e verificando DLT 2023: 5º Workshop de Tecnologia de Ledger Distribuído, 25 a 26 de maio de 2023, Bolonha, Itália $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Direitos autorais deste artigo de seus autores. Uso permitido sob Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Oficina Processos http://ceur-ws.org ISSN 1613-0073 Anais do Workshop CEUR (CEUR-WS.org)na cadeia o que está acontecendo fora da cadeia. No entanto, tanto os canais de plasma quanto os de estado são limitados em seu apoio aos smart contracts gerais. Rollups são blockchains (chamados Layer 2 ou L2) que publicam seus blocos em outro blockchain (Layer 1 ou L1) e, portanto, herda seu consenso, disponibilidade de dados e propriedades de segurança. Eles, ao contrário de outras soluções, suporta computação arbitrária. Os rollups têm três componentes principais: • Sequenciadores: nós que recebem transações Rollup dos usuários e as combinam em um bloco que é enviado para Layer 1. O bloco consiste em pelo menos a raiz do estado (por exemplo, um Merkle root) e os dados necessários para reconstruir e validar o estado. O Layer 1 define o canônico blockchain do L2 estabelecendo a ordenação dos dados publicados. • Nós completos de rollup: nós que obtêm, processam e validam blocos de rollup da camada 1 verificando se a raiz está correta. Se um bloco contém transações inválidas, então descartado, o que impede que os sequenciadores criem blocos válidos que incluam blocos inválidos transações. • Nós light de rollup: nós que obtêm blocos de rollup de Layer 1, mas não calculam o novo estado eles mesmos. Eles verificam se a nova raiz de estado é válida usando técnicas como provas de culpa ou validade. Os rollups alcançam escalabilidade diminuindo o custo amortizado das transações conforme o número de usuários aumenta. Isso ocorre porque o custo para garantir a validade de blockchain cresce sublinearmente no que diz respeito ao custo de verificação individual das transações. Os rollups diferem de acordo com o mecanismo pelo qual eles garantem a validade da execução da transação em nós leves: em Rollups Otimistas são garantidos por um modelo econômico e por provas de falhas, enquanto em Validade Rollups são garantidos criptograficamente usando provas de validade. Os nós leves podem ser implementados como smart contracts em Layer 1. Eles aceitam a raiz do novo estado e verificar a validade ou provas de falha: esses Rollup são, portanto, chamados de Contrato Inteligente Acumulações. Se os nós leves forem independentes, eles serão chamados de Rollups Soberanos [6]. A vantagem de usar um Smart Contract Rollup é ser capaz de construir uma ponte com confiança minimizada entre os dois blockchains: como a validade do estado L2 é comprovada para L1, um sistema de transações de L2 a L1 podem ser implementados, permitindo saques. A desvantagem é que o custo do transações depende do custo de verificação do estado em L1: se a camada base estiver saturada por outras atividades, o custo das transações no Rollup também aumenta. As camadas de dados e de consenso são as que determinam a segurança do sistema como eles definem a ordem das transações, evitam ataques e disponibilizam dados para comprovar o estado validade. Contribuição em papel Neste artigo, estudamos Optimistic e Validity Rollups, dois inovadores soluções para o Trilema de Escalabilidade, com foco em implementações notáveis, como Optimism Bedrock e StarkNet. Nossas contribuições incluem uma comparação abrangente desses soluções, uma análise dos tempos de retirada e uma discussão sobre um possível ataque a Optimism Base rochosa. Além disso, calculamos suas taxas de compressão de gás, fornecemos otimizações específicas da aplicação e apresentamos as vantagens e desvantagens de se afastar do Ethereum Máquina Virtual (EVM).

Estrutura do papel O artigo está organizado da seguinte forma. Na seção 2, Rollups otimistas são introduzido pela análise de Optimism Bedrock. Na seção 3, os Rollups de Validade são introduzidos por analisando StarkNet. Na seção 4 comparamos as duas soluções. Finalmente, na seção 5 desenhamos algumas conclusões.

Rollup Optimis

Rollup Optimis Gagasan untuk menerima keluaran blok secara optimis tanpa memverifikasi eksekusinya adalah sudah ada di whitepaper Bitcoin [7], membahas tentang light node. Node-node ini hanya mengikuti rantai header dengan memverifikasi aturan konsensus, membuat mereka rentan untuk menerima pemblokiran berisi transaksi yang tidak valid jika terjadi serangan 51%. Nakamoto mengusulkan untuk memecahkan masalah ini masalah dengan menggunakan sistem "peringatan" untuk memperingatkan node ringan bahwa suatu blok berisi transaksi yang tidak valid. Mekanisme ini pertama kali diterapkan oleh Al-Bassam, Sonnino dan Buterin [8] dimana terjadi kesalahan sistem pembuktian berdasarkan kode koreksi kesalahan [9] digunakan. Untuk memungkinkan pembuatan bukti kesalahan, data dari semua blok, termasuk blok yang tidak valid, harus tersedia jaringan: ini adalah Masalah Ketersediaan Data, yang diselesaikan dengan menggunakan data probabilistik mekanisme pengambilan sampel. Desain Optimistic Rollup pertama dipresentasikan oleh John Adler dan Mikerah Quintyne-Collins pada tahun 2019 [10], di mana blok diterbitkan pada blockchain lain yang mendefinisikan konsensus mereka tentang pemesanan. 2.1. Optimism Batuan Dasar Batuan Dasar [11] adalah versi terbaru dari Optimism, Smart Contract Rollup. Versi sebelumnya, Mesin Virtual Optimis (OVM) memerlukan kompiler ad hoc untuk mengkompilasi Soliditas ke dalamnya bytecode sendiri: sebaliknya, Bedrock sepenuhnya setara dengan EVM di mesin eksekusi mengikuti spesifikasi Ethereum Kertas Kuning [12]. 2.1.1. Deposito Pengguna dapat menyetorkan transaksi melalui kontrak di Ethereum, Portal Optimism, dengan memanggil fungsi depositTransaction. Pada saat transaksi dijalankan, a Peristiwa TransactionDeposited dipancarkan, yang didengarkan oleh setiap node di Rollup untuk diproses deposito. Transaksi yang disimpan adalah transaksi L2 yang berasal dari L1. Jika penelepon dari fungsinya adalah kontrak, alamat diubah dengan menambahkan nilai konstan ke dalamnya: ini mencegah serangan di mana kontrak di L1 memiliki alamat yang sama dengan kontrak di L2 tetapi kodenya berbeda. Dimasukkannya L2 dari transaksi yang disimpan dijamin oleh spesifikasi dalam suatu urutan jendela. Transaksi yang disimpan adalah jenis transaksi baru yang kompatibel dengan EIP-2718 [13] dengan awalan 0x7E, di mana bidang yang dikodekan rlp adalah: • bytes32 sourceHash: hash yang secara unik mengidentifikasi sumber transaksi. • alamat dari : alamat pengirim. • alamat ke : alamat penerima, atau alamat nol jika transaksi yang disetor adalah a pembuatan kontrak.• uint256 mint: nilai yang akan dibuat pada L2. • nilai uint256: nilai yang akan dikirim ke penerima. • byte data: data masukan. • bytes gasLimit: batas gas transaksi. sourceHash dihitung sebagai keccak256 hash dari blok L1 hash dan log L1 indeks, secara unik mengidentifikasi suatu peristiwa dalam sebuah blok. Karena transaksi yang disimpan dimulai pada L1 tetapi dieksekusi pada L2, sistem memerlukan a mekanisme untuk membayar L1 untuk gas yang dihabiskan untuk L2. Salah satu solusinya adalah dengan mengirimkan ETH melalui Portal, tapi ini menyiratkan bahwa setiap penelepon (bahkan penelepon tidak langsung) harus ditandai sebagai orang yang harus dibayar, dan memang demikian tidak mungkin untuk banyak proyek yang ada. Alternatifnya adalah dengan membakar gas yang sesuai pada L1. Gas yang 𝑔dialokasikan untuk transaksi yang disetor disebut gas terjamin. Harga gas L2 aktif L1 tidak disinkronkan secara otomatis tetapi diperkirakan menggunakan mekanisme yang mirip dengan EIP-1559 [14]. Jumlah maksimum gas yang dijamin per blok Ethereum adalah 8 juta, dengan target dari 2 juta. Kuantitas 𝑐ETH yang dibutuhkan untuk membayar gas pada L2 adalah 𝑐= 𝑔𝑏L2 dimana 𝑏L2 adalah biaya dasar pada L2. Kontrak pada L1 membakar sejumlah gas yang sama dengan 𝑐/𝑏L2. Gas dihabiskan untuk menelepon depositTransaksi diganti pada L2: jika jumlah ini lebih besar dari gas yang dijamin, tidak ada gas yang terbakar. Transaksi pertama dari blok rollup adalah transaksi yang disimpan dengan atribut L1, digunakan untuk mendaftar pada L2 pra-deploy atribut blok Ethereum. Atribut yang diberikan oleh pra-penerapan aksesnya adalah nomor blok, stempel waktu, biaya dasar, blok hash dan urutannya number, yang merupakan nomor blok L2 relatif terhadap blok L1 terkait (juga disebut epoch); nomor ini disetel ulang ketika zaman baru dimulai. 2.1.2. Urutan Node Rollup memperoleh rantai Optimism seluruhnya dari Ethereum. Rantai ini diperpanjang setiap kali transaksi baru dipublikasikan di L1, dan bloknya direorganisasi setiap kali Ethereum blok ditata ulang. Rollup blockchain dibagi menjadi beberapa zaman. Untuk setiap 𝑛 nomor blok Ethereum, ada 𝑛epoch yang sesuai. Setiap zaman berisi setidaknya satu blok, dan setiap blok dalam suatu zaman berisi transaksi penyimpanan atribut L1. Blok pertama dalam suatu zaman berisi semua transaksi yang disimpan melalui Portal. Layer 2 blok juga bisa berisi transaksi berurutan, yaitu transaksi yang dikirim langsung ke Sequencer. Sequencer menerima transaksi dari pengguna dan membangun blok. Untuk setiap blok, itu dibangun kumpulan yang akan diterbitkan pada Ethereum. Beberapa batch dapat diterbitkan secara terkompresi, mengambil nama saluran. Sebuah saluran dapat dibagi menjadi beberapa bingkai, jika terlalu besar satu transaksi. Saluran didefinisikan sebagai kompresi dengan ZLIB [15] yang dikodekan rlp batch. Bidang batch adalah nomor zaman, zaman hash, induk hash, stempel waktu dan daftar transaksi. Jendela pengurutan, yang diidentifikasi berdasarkan suatu zaman, berisi bilangan tetap 𝑤dari L1 yang berurutan blok yang diambil langkah derivasi sebagai masukan untuk membangun sejumlah variabel blok L2. Untuk Epoch 𝑛, jendela pengurutan 𝑛 mencakup blok [𝑛, 𝑛+𝑤). Ini menyiratkan bahwa pemesanan transaksi dan blok L2 dalam jendela sequencing tidak diperbaiki sampai jendela berakhir. Transaksi rollup disebut aman jika batch yang memuatnya telah dikonfirmasi di L1. Bingkaidibaca dari blok L1 untuk merekonstruksi batch. Implementasi saat ini tidak memungkinkan dekompresi saluran dimulai sampai semua frame yang sesuai telah diterima. Tidak valid batch diabaikan. Transaksi blok individu diperoleh dari batch, yaitu digunakan oleh mesin eksekusi untuk menerapkan transisi status dan mendapatkan status Rollup. 2.1.3. Penarikan Untuk memproses penarikan, sistem pesan L2-ke-L1 diterapkan. Ethereum perlu mengetahui status L2 untuk menerima penarikan, dan ini dilakukan dengan menerbitkan pada Output L2 Oracle smart contract pada L1 state root setiap blok L2. Akar ini secara optimis diterima sebagai valid (atau diselesaikan) jika tidak ada bukti kesalahan yang dilakukan selama proses periode perselisihan. Hanya alamat yang ditunjuk sebagai Pengusul yang dapat mempublikasikan akar keluaran. Validitas akar keluaran diberi insentif dengan meminta Pengusul menyetorkan taruhan yang akan dipotong jika memang demikian terbukti telah mengusulkan root yang tidak valid. Transaksi dimulai dengan memanggil fungsi tersebut inisiasi Penarikan pada pra-penerapan di L2 dan kemudian diselesaikan di L1 dengan memanggil fungsi tersebut finalizeWithdrawalTransaction pada Portal Optimism yang disebutkan sebelumnya. Root keluaran yang sesuai dengan blok L2 diperoleh dari L2 Output Oracle; itu diverifikasi bahwa perselisihan tersebut telah selesai, yaitu bahwa jangka waktu perselisihan telah berlalu; telah diverifikasi bahwa Output Bukti Root cocok dengan Bukti Oracle; telah diverifikasi bahwa hash penarikan disertakan di dalamnya menggunakan Bukti Penarikan; bahwa penarikan tersebut belum diselesaikan; dan kemudian panggilan ke alamat target dieksekusi, dengan batas gas, jumlah Ether, dan data yang ditentukan. 2.1.4. Cannon: sistem bukti kesalahan Jika Rollup Full Node, dengan mengeksekusi batch dan transaksi yang disimpan secara lokal, menemukannya status Layer 2 tidak cocok dengan root status yang diterbitkan secara on-chain oleh Pengusul, ia dapat mengeksekusi bukti kesalahan pada L1 untuk membuktikan bahwa hasil transisi blok salah. Karena overhead, memproses seluruh blok Rollup di L1 terlalu mahal. Solusinya diterapkan oleh Bedrock adalah mengeksekusi on-chain hanya instruksi pertama dari ketidaksepakatan minigeth, mengkompilasinya menjadi arsitektur MIPS yang dieksekusi pada penerjemah on-chain dan diterbitkan di L1. minigeth adalah versi sederhana dari geth 1 yang berisi konsensus, RPC, dan database telah dihapus. Untuk menemukan instruksi ketidaksepakatan pertama, dilakukan pencarian biner interaktif antar orang yang memulai bukti kesalahan dan orang yang menerbitkan akar keluaran. Ketika buktinya dimulai, kedua belah pihak mempublikasikan root dari status memori MIPS di tengah-tengah eksekusi blok pada kontrak Tantangan: jika hash cocok berarti kedua belah pihak menyetujui paruh pertama eksekusi sehingga menerbitkan akar setengah dari paruh kedua, jika tidak, setengahnya babak pertama diterbitkan dan seterusnya. Melakukan hal itu akan menghasilkan instruksi ketidaksepakatan yang pertama dalam jumlah langkah logaritmik dibandingkan dengan eksekusi aslinya. Jika salah satu dari keduanya berhenti berinteraksi, di akhir masa perselisihan peserta lain otomatis menang. Untuk memproses instruksi, penerjemah MIPS memerlukan akses ke memorinya: karena root adalah tersedia, sel memori yang diperlukan dapat dipublikasikan dengan membuktikan penyertaannya. Untuk mengakses keadaan EVM, penggunaan dibuat dari Preimage Oracle: mengingat hash dari blok yang dikembalikannya 1https://geth.ethereum.org/docs

header blok, dari mana seseorang bisa mendapatkan hash dari blok sebelumnya dan kembali ke rantai, atau dapatkan hash status dan log dari mana seseorang bisa mendapatkan gambar awal. oracle diimplementasikan oleh minigeth dan menggantikan database. Kueri dibuat ke node lain untuk mendapatkan gambar awal.

Rollups otimistas

Rollups otimistas A ideia de aceitar de forma otimista a saída dos blocos sem verificar sua execução é já presente no white paper Bitcoin [7], discutindo nós de luz. Esses nós seguem apenas a cadeia de cabeçalho, verificando a regra de consenso, tornando-os vulneráveis à aceitação de blocos contendo transações inválidas no caso de um ataque de 51%. Nakamoto propõe resolver isso problema usando um sistema de “alerta” para avisar os nós leves de que um bloco contém transações inválidas. Este mecanismo foi implementado pela primeira vez por Al-Bassam, Sonnino e Buterin [8] em que uma falha sistema de prova baseado em códigos de correção de erros [9] é usado. Para permitir a criação de provas de falhas, é necessário que os dados de todos os blocos, inclusive os blocos inválidos, estejam disponíveis para a rede: este é o Problema de Disponibilidade de Dados, que é resolvido usando uma análise probabilística de dados mecanismo de amostragem. O primeiro design Optimistic Rollup foi apresentado por John Adler e Mikerah Quintyne-Collins em 2019 [10], em que os blocos são publicados em outro blockchain que define seu consenso sobre o pedido. 2.1. Optimism Base rochosa Bedrock [11] é a versão mais recente de Optimism, um Smart Contract Rollup. A versão anterior, a Optimistic Virtual Machine (OVM) exigia um compilador ad hoc para compilar o Solidity em seu próprio bytecode: em contraste, Bedrock é totalmente equivalente ao EVM em que o mecanismo de execução segue a especificação do papel amarelo Ethereum [12]. 2.1.1. Depósitos Os usuários podem depositar transações por meio de um contrato no Ethereum, o Portal Optimism, chamando a função depositTransaction. Quando uma transação é executada, um O evento TransactionDeposited é emitido, e cada nó no Rollup escuta para processar depósitos. Uma transação depositada é uma transação L2 derivada de L1. Se o chamador do função é um contrato, o endereço é transformado adicionando-lhe um valor constante: isso evita ataques em que um contrato em L1 tem o mesmo endereço que um contrato em L2, mas um código diferente. A inclusão em L2 de uma transação depositada é garantida pela especificação dentro de um sequenciamento janela. As transações depositadas são um novo tipo de transação compatível com EIP-2718 [13] com prefixo 0x7E, onde os campos codificados em rlp são: • bytes32 sourceHash: hash que identifica exclusivamente a origem da transação. • endereço de: o endereço do remetente. • endereço para: o endereço do destinatário, ou o endereço zero se a transação depositada for uma criação de contrato.• uint256 mint: o valor a ser criado em L2. • valor uint256: valor a ser enviado ao destinatário. • dados de bytes: os dados de entrada. • bytes gasLimit: o limite gas da transação. O sourceHash é calculado como o keccak256 hash do bloco L1 hash e o log L1 índice, identificando exclusivamente um evento em um bloco. Como as transações depositadas são iniciadas em L1, mas executadas em L2, o sistema precisa de um mecanismo para pagar em L1 pelo gás gasto em L2. Uma solução é enviar ETH pelo Portal, mas isso implica que cada chamador (mesmo os chamadores indiretos) deve ser marcado como pagável, e isso é não é possível para muitos projetos existentes. A alternativa é queimar o gás correspondente em L1. O gás 𝑔alocado para a transação depositada é chamado de gás garantido. O preço do gás L2 em L1 não é sincronizado automaticamente, mas é estimado usando um mecanismo semelhante ao EIP-1559 [14]. A quantidade máxima de gás garantida por bloco Ethereum é de 8 milhões, com meta de 2 milhões. A quantidade 𝑐de ETH necessária para pagar o gás em L2 é 𝑐= 𝑔𝑏L2 onde 𝑏L2 é o taxa base em L2. O contrato em L1 queima uma quantidade de gás igual a 𝑐/𝑏L2. O gás gasto para ligar depositTransaction é reembolsado em L2: se este valor for maior que o gás garantido, nenhum gás é queimado. A primeira transação de um bloco rollup é uma transação depositada com atributos L1, usada para registrar em um L2 pré-implante os atributos dos blocos Ethereum. Os atributos que a pré-implantação fornece acesso são o número do bloco, o carimbo de data / hora, a taxa base, o bloco hash e a sequência número, que é o número do bloco L2 relativo ao bloco L1 associado (também chamado de época); este número é redefinido quando uma nova época começa. 2.1.2. Sequenciamento Os nós Rollup derivam a cadeia Optimism inteiramente de Ethereum. Esta cadeia é estendida cada vez que novas transações são publicadas em L1, e seus blocos são reorganizados cada vez Ethereum blocos são reorganizados. O Rollup blockchain é dividido em épocas. Para cada 𝑛 número do bloco de Ethereum, há uma época 𝑛 correspondente. Cada época contém pelo menos um bloco, e cada bloco em uma época contém uma transação depositada com atributos L1. O primeiro bloco em uma época contém todas as transações depositadas através do Portal. Layer 2 blocos também podem continha transações sequenciadas, ou seja, transações enviadas diretamente ao sequenciador. O sequenciador aceita transações de usuários e constrói blocos. Para cada bloco, ele constrói um lote a ser publicado em Ethereum. Vários lotes podem ser publicados de forma compactada, tomando o nome do canal. Um canal pode ser dividido em vários frames, caso seja muito grande para uma única transação. Um canal é definido como a compactação com ZLIB [15] de canais codificados em rlp lotes. Os campos de um lote são o número da época, a época hash, o pai hash, o carimbo de data/hora e a lista de transações. Uma janela de sequenciação, identificada por uma época, contém um número fixo 𝑤de L1 consecutivos blocos que uma etapa de derivação toma como entrada para construir um número variável de blocos L2. Para época 𝑛, a janela de sequenciamento 𝑛 inclui os blocos [𝑛, 𝑛+𝑤). Isto implica que a ordenação O número de transações e blocos L2 dentro de uma janela de sequenciamento não é corrigido até que a janela termine. Uma transação rollup é chamada de segura se o lote que a contém foi confirmado em L1. Moldurassão lidos de blocos L1 para reconstruir lotes. A implementação atual não permite a descompressão de um canal comece até que todos os quadros correspondentes tenham sido recebidos. Inválido lotes são ignorados. As transações em bloco individuais são obtidas dos lotes, que são usado pelo mecanismo de execução para aplicar transições de estado e obter o estado Rollup. 2.1.3. Retiradas Para processar saques, é implementado um sistema de mensagens L2 para L1. Ethereum precisa saber o estado do L2 para aceitar saques, e isso é feito publicando no Oracle de saída L2 smart contract em L1 a raiz de estado de cada bloco L2. Essas raízes são otimistamente aceitos como válidos (ou finalizados) se nenhuma prova de falha for realizada durante o período de disputa. Somente endereços designados como Proponentes podem publicar raízes de saída. A validade das raízes da produção é incentivada fazendo com que os proponentes depositem uma participação que será reduzida se eles forem mostrado ter proposto uma raiz inválida. As transações são iniciadas chamando a função inicieWithdrawal em uma pré-implantação em L2 e, em seguida, finalize em L1 chamando a função finalizeWithdrawalTransaction no Portal Optimism mencionado anteriormente. A raiz de saída correspondente ao bloco L2 é obtida do L2 Output Oracle; é verificou que está finalizado, ou seja, que o período de disputa já passou; verifica-se que a Saída A Prova Raiz corresponde à Prova Oracle; verifica-se que o hash do saque está incluído nele utilizando um Comprovante de Saque; que a retirada ainda não foi finalizada; e então o a chamada para o endereço de destino é executada, com o limite de gás especificado, quantidade de Ether e dados. 2.1.4. Cannon: o sistema à prova de falhas Se um Rollup Full Node, ao executar localmente lotes e transações depositadas, descobrir que o estado Layer 2 não corresponde à raiz do estado publicada na cadeia por um proponente, ele pode ser executado uma prova de falha em L1 para provar que o resultado da transição do bloco está incorreto. Por causa do sobrecarga, processar um bloco Rollup inteiro em L1 é muito caro. A solução implementada por Bedrock é executar on-chain apenas a primeira instrução de desacordo de minigeth, compilando-o em uma arquitetura MIPS que é executada em um intérprete on-chain e publicada em L1. minigeth é uma versão simplificada do geth 1 em que o consenso, RPC e banco de dados foram removidos. Para encontrar a primeira instrução de desacordo, uma busca binária interativa é conduzida entre aquele que iniciou a prova de falhas e aquele que publicou a raiz de saída. Quando a prova começa, ambas as partes publicam a raiz do estado de memória MIPS no meio da execução de o bloqueio no contrato do Desafio: se hash corresponder, significa que ambas as partes concordam com o primeira metade da execução publicando assim a raiz da metade da segunda metade, caso contrário a metade do primeiro semestre é publicado e assim por diante. Fazer isso alcança a primeira instrução de desacordo em um número logarítmico de etapas em comparação com a execução original. Se um dos dois parar interagindo, ao final do período de disputa o outro participante ganha automaticamente. Para processar a instrução, o interpretador MIPS precisa de acesso à sua memória: já que a raiz é disponíveis, as células de memória necessárias podem ser publicadas comprovando sua inclusão. Para acessar o estado do EVM, é feito uso do Preimage Oracle: dado o hash de um bloco ele retorna 1https://geth.ethereum.org/docs

o cabeçalho do bloco, a partir do qual se pode obter o hash do bloco anterior e voltar no cadeia ou obtenha o hash do estado e dos logs dos quais é possível obter a pré-imagem. O oracle é implementado pelo minigeth e substitui o banco de dados. Consultas são feitas a outros nós para obter as pré-imagens.

Rollup Validitas

Pembatalan Validitas Tujuan dari Validity Rollup adalah untuk membuktikan secara kriptografis validitas transisi keadaan diberikan urutan transaksi dengan bukti singkat yang dapat diverifikasi dibandingkan secara sub-linear ke waktu perhitungan aslinya. Sertifikat semacam ini disebut bukti integritas komputasi dan secara praktis diimplementasikan dengan SNARK (Succint Non-interactive ARgument of Knowledge), yang menggunakan aritmatika sirkuit sebagai model komputasinya. Implementasi SNARK yang berbeda berbeda dalam waktu pembuktian, waktu verifikasi, kebutuhan pengaturan yang tepercaya dan ketahanan kuantum [16, 17]. STARK (Dapat diskalakan ARgumen Pengetahuan Transparan) [18] adalah jenis SNARK yang tidak memerlukan kepercayaan pengaturannya dan tahan terhadap kuantum, namun mengurangi efisiensi dalam pembuktian dan verifikasi dibandingkan dengan solusi lain. 3.1. StarkNet StarkNet adalah Rollup Validitas Kontrak Cerdas yang dikembangkan oleh StarkWare yang menggunakan STARK sistem bukti untuk memvalidasi statusnya ke Ethereum. Untuk memudahkan konstruksi bukti keabsahan, a mesin virtual berbeda dari EVM yang digunakan, yang bahasa tingkat tingginya adalah Kairo. 3.1.1. Deposito Pengguna dapat menyetor transaksi melalui kontrak di Ethereum dengan menghubungi sendMessageToL2 fungsi. Pesan dicatat dengan menghitung hash dan menambah penghitung. Pengurut mendengarkan acara LogMessageToL2 dan menyandikan informasi dalam transaksi StarkNet yang memanggil fungsi kontrak yang memiliki dekorator l1_handler. Di akhir eksekusi, ketika bukti transisi keadaan dihasilkan, konsumsi pesan dilampirkan padanya dan itu dihapus dengan mengurangi penghitungnya. Pencantuman transaksi yang disimpan tidak diwajibkan oleh spesifikasi StarkNet, jadi gas pasar diperlukan untuk memberi insentif kepada Sequencer untuk mempublikasikannya di L2. Dalam versi saat ini, karena Sequencer dipusatkan dan dikelola oleh StarkWare, biaya transaksi yang disimpan hanya ditentukan oleh biaya pelaksanaan titipan. Biaya ini dibayar dengan mengirimkan ETH ke kirimMessageToL2. Eter ini tetap terkunci di L1 dan ditransfer ke Sequencer aktif L1, apabila transaksi yang disetorkan termasuk dalam keadaan transisi. Jumlah ETH yang dikirim, jika transaksi yang disimpan sudah termasuk, dihabiskan sepenuhnya, berapa pun jumlah gas yang dikonsumsi di L2. StarkNet tidak memiliki sistem yang membuat atribut blok L1 tersedia secara otomatis. Alternatifnya, Fossil adalah protokol yang dikembangkan oleh Oiler Network 2 yang memungkinkan, dengan hash dari a blok, informasi apa pun yang dapat diperoleh dari Ethereum dengan menerbitkan gambar awal. 2https://www.oiler.network/3.1.2. Urutan Keadaan StarkNet saat ini dapat diturunkan seluruhnya dari Ethereum. Perbedaan negara bagian apa pun antar transisi dipublikasikan di L1 sebagai data panggilan. Perbedaan dipublikasikan untuk setiap kontrak dan disimpan sebagai uint256[] dengan pengkodean berikut: • Jumlah bidang mengenai penerapan kontrak. • Untuk setiap kontrak yang diterbitkan: – Alamat kontrak yang diterbitkan. – hash dari kontrak yang dipublikasikan. – Jumlah argumen pembuat kontrak. – Daftar argumen konstruktor • Jumlah kontrak yang penyimpanannya telah diubah. • Untuk setiap kontrak yang telah diubah: – Alamat kontrak yang diubah. – Jumlah pembaruan penyimpanan. – Pasangan nilai kunci dari alamat penyimpanan dengan nilai baru. Perbedaan negara diterbitkan secara berurutan, sehingga cukup membacanya secara berurutan merekonstruksi negara. 3.1.3. Penarikan Untuk mengirim pesan dari L2 ke L1 digunakan syscall send_message_to_L1. Pesannya adalah diterbitkan ke L1 dengan menambah counter hash-nya beserta buktinya dan diselesaikan dengan memanggil fungsi mengkonsumsiMessageFromL2 di StarkGate smart contract di L1, yang mengurangi konter. Siapa pun dapat menyelesaikan penarikan apa pun. 3.1.4. Bukti validitas Mesin Virtual Kairo [19] dirancang untuk memfasilitasi pembuatan bukti STARK. Bahasa Kairo memungkinkan komputasi dijelaskan dengan pemrograman tingkat tinggi bahasa, dan tidak secara langsung sebagai sirkuit. Hal ini dicapai dengan sistem persamaan polinomial 3 mewakili komputasi tunggal: siklus FDE dari arsitektur von Neumann. Nomornya batasannya tetap dan tidak bergantung pada jenis komputasi, sehingga hanya memungkinkan satu komputasi Program verifikator untuk setiap program yang perhitungannya perlu dibuktikan. StarkNet menggabungkan beberapa transaksi menjadi satu bukti STARK menggunakan pembuktian bersama bernama SHARP. Buktinya dikirim ke smart contract pada Ethereum, yang memverifikasi keabsahannya dan memperbarui akar Merkle yang sesuai dengan status baru. Biaya sub-linier untuk verifikasi a bukti validitas memungkinkan biayanya diamortisasi dalam beberapa transaksi. 3disebut Representasi Menengah Aljabar (AIR)

Rollups de validade

Rollups de validade O objetivo de um Validity Rollup é provar criptograficamente a validade da transição de estado dada a sequência de transações com uma prova curta que pode ser verificada sub-linearmente comparada ao tempo dos cálculos originais. Esses tipos de certificados são chamados de provas de integridade computacional e são praticamente implementados com SNARKs (Succint Non-interactive ARgument of Knowledge), que utilizam aritmética circuitos como seu modelo computacional. Diferentes implementações do SNARK diferem no tempo de prova, tempo de verificação, a necessidade de uma configuração confiável e resistência quântica [16, 17]. STARKs (escalável ARgumento Transparente de Conhecimento) [18] são um tipo de SNARKs que não requer um confiável configurados e são resistentes a quantum, ao mesmo tempo que abrem mão de alguma eficiência na prova e verificação em comparação com outras soluções. 3.1. StarkNet StarkNet é um Smart Contract Validity Rollup desenvolvido pela StarkWare que usa o STARK sistema de prova para validar seu estado para Ethereum. Para facilitar a construção de provas de validade, um É utilizada uma máquina virtual diferente da EVM, cuja linguagem de alto nível é Cairo. 3.1.1. Depósitos Os usuários podem depositar transações por meio de um contrato em Ethereum chamando sendMessageToL2 função. A mensagem é registrada calculando seu hash e aumentando um contador. Sequenciadores ouça o evento LogMessageToL2 e codifique as informações em uma transação StarkNet que chama uma função de um contrato que possui o decorador l1_handler. No final da execução, quando a prova de transição de estado é produzida, o consumo da mensagem é anexado a ela e é excluído diminuindo seu contador. A inclusão de transações depositadas não é exigida pela especificação StarkNet, portanto, um gás mercado é necessário para incentivar os sequenciadores a publicá-los em L2. Na versão atual, porque o Sequenciador é centralizado e gerenciado pela StarkWare, o custo das transações depositadas é determinado apenas pelo custo de execução do depósito. Este custo é pago enviando ETH para enviarMessageToL2. Esses Éteres permanecem bloqueados em L1 e são transferidos para o Sequenciador em L1, quando a transação depositada está incluída em uma transição de estado. A quantidade de ETH enviada, se a transação depositada está incluída, é totalmente gasta, independentemente da quantidade de gás consumida em L2. StarkNet não possui um sistema que disponibilize atributos do bloco L1 automaticamente. Alternativamente, Fossil é um protocolo desenvolvido pela Oiler Network 2 que permite, dado um hash de um bloco, qualquer informação a ser obtida de Ethereum através da publicação de pré-imagens. 2https://www.oiler.network/3.1.2. Sequenciamento O estado atual de StarkNet pode ser derivado inteiramente de Ethereum. Qualquer diferença de estado entre transições é publicado em L1 como calldata. As diferenças são publicadas para cada contrato e são salvos como uint256[] com a seguinte codificação: • Número de campos relativos a implantações contratuais. • Para cada contrato publicado: – O endereço do contrato publicado. – O hash do contrato publicado. – O número de argumentos do construtor do contrato. – A lista de argumentos do construtor • Número de contrato cuja armazenagem foi modificada. • Para cada contrato que foi modificado: – O endereço do contrato modificado. – O número de atualizações de armazenamento. – Os pares de valores-chave dos endereços de armazenamento com os novos valores. As diferenças de estado são publicadas em ordem, portanto é suficiente lê-las sequencialmente para reconstruir o estado. 3.1.3. Retiradas Para enviar uma mensagem de L2 para L1, é usado o syscall send_message_to_L1. A mensagem é publicado em L1 aumentando seu contador hash junto com a prova e finalizado chamando o função consomeMessageFromL2 no StarkGate smart contract em L1, que diminui o contador. Qualquer pessoa pode finalizar qualquer saque. 3.1.4. Provas de validade A Máquina Virtual Cairo [19] foi projetada para facilitar a construção de provas STARK. A linguagem Cairo permite que o cálculo seja descrito com uma programação de alto nível linguagem, e não diretamente como um circuito. Isso é conseguido por um sistema de equações polinomiais 3 representando um único cálculo: o ciclo FDE de uma arquitetura von Neumann. O número de restrições é, portanto, fixo e independente do tipo de computação, permitindo apenas um Programa verificador para cada programa cujo cálculo precisa ser provado. StarkNet agrega múltiplas transações em uma única prova STARK usando um provador compartilhado chamado SHARP. As provas são enviadas para smart contract em Ethereum, que verifica sua validade e atualiza a raiz Merkle correspondente ao novo estado. O custo sublinear de verificar um a prova de validade permite que seu custo seja amortizado em múltiplas transações. 3chamada Representação Algébrica Intermediária (AIR)

Perbandingan

Perbandingan 4.1. Waktu penarikan Aspek terpenting yang membedakan Optimistic Rollup dengan Validity Rollup adalah waktu yang berlalu antara inisialisasi penarikan dan penyelesaiannya. Dalam kedua kasus tersebut, penarikan diinisialisasi pada L2 dan diselesaikan pada L1. Pada StarkNet, finalisasi dapat dilakukan sebagai segera setelah bukti validitas root negara baru diterima pada Ethereum: secara teoritis, itu adalah mungkin untuk menarik dana di blok pertama L1 setelah inisialisasi. Dalam praktiknya, frekuensi pengiriman bukti validitas pada Ethereum merupakan trade-off antara kecepatan blok finalisasi dan agregasi bukti. Saat ini StarkNet memberikan bukti validitas untuk verifikasi setiap 10 jam 4, namun dimaksudkan untuk dikurangi seiring dengan meningkatnya aktivitas transaksi. Di Optimism Batuan Dasar, penarikan hanya dapat diselesaikan di akhir perselisihan periode (saat ini 7 hari), setelah itu root secara otomatis dianggap valid. Panjangnya periode ini terutama ditentukan oleh fakta bahwa bukti kesalahan dapat disensor pada Ethereum hingga akhirnya. Kemungkinan keberhasilan serangan jenis ini menurun secara eksponensial seiring bertambahnya waktu: E[nilai yang dikurangi] = 𝑉𝑝𝑛 dimana 𝑛adalah jumlah blok dalam suatu interval, 𝑉adalah jumlah dana yang dapat dikurangi dengan menerbitkan root yang tidak valid, dan 𝑝adalah kemungkinan berhasil melakukan penyensoran menyerang dalam satu blok. Misalkan probabilitas ini adalah 99%, nilai terkunci di Rollup adalah satu juta Eter, dan blok dalam suatu interval adalah 1800 (6 jam blok dengan 12 interval detik): nilai yang diharapkan adalah sekitar 0,01391 Eter. Sistem dibuat aman oleh meminta Pengusul untuk mempertaruhkan jumlah Ether yang jauh lebih besar dari nilai yang diharapkan. Winzer dkk. menunjukkan cara melakukan serangan sensor menggunakan smart contract sederhana yang memastikan bahwa area memori tertentu di negara bagian tidak berubah [20]. Memodelkan serangan sebagai permainan Markov, makalah ini menunjukkan bahwa penyensoran adalah strategi dominan yang rasional produsen blok jika mereka menerima kompensasi lebih dari memasukkan transaksi yang berubah memori. Nilai 𝑝 yang dibahas di atas dapat dipandang sebagai persentase blok rasional produsen dalam jaringan, di mana “rasional” tidak memperhitungkan kemungkinan pemberian sanksi eksternalitas, seperti berkurangnya kepercayaan pada blockchain yang menurunkan nilai mata uang kripto. Kode berikut menyajikan smart contract yang dapat digunakan untuk melakukan serangan sensor di Batuan Dasar. Serangan tersebut mengeksploitasi insentif produsen blok dengan menawarkan suap untuk menyensor transaksi yang akan mengubah bagian tertentu negara. Kontrak utama fungsi,claimBribe, memungkinkan produsen blok untuk mengklaim suap jika mereka berhasil menyensor transaksi yang ditargetkan dengan memeriksa bahwa akar keluaran yang tidak valid tidak disentuh. fungsi klaim Suap (byte memori penyimpanan Bukti) eksternal { require(!claimed[block.number], "suap sudah diklaim"); Memori OutputProposal saat ini = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, penyimpananBukti); require(invalidOutputRoot == current.outputRoot, "serangan gagal"); diklaim[block.number] = true; (bool terkirim, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(terkirim, "gagal mengirim ether"); } Listing 1: Contoh kontrak yang memberikan insentif untuk serangan sensor terhadap Bedrock. Lamanya jangka waktu perselisihan juga harus mempertimbangkan fakta bahwa bukti kesalahannya bukti interaktif dan oleh karena itu waktu yang cukup harus disediakan bagi peserta untuk berinteraksi dan bahwa interaksi apa pun dapat disensor. Jika pergerakan terakhir terjadi pada waktu yang sangat dekat dengan Pada akhir periode perselisihan, biaya penyensoran jauh lebih sedikit. Meskipun penyensoran adalah hal yang paling penting strategi dominan, kemungkinan keberhasilannya lebih rendah karena node penyensoran rentan terhadapnya Serangan Denial of Service: penyerang dapat menghasilkan transaksi yang sangat kompleks yang diakhiri dengan publikasi bukti kesalahan tanpa biaya, karena tidak ada biaya yang akan dibayarkan. Dalam kasus ekstrim, periode perselisihan yang panjang memungkinkan terjadinya koordinasi jika terjadi keberhasilan serangan sensor untuk mengatur percabangan dan mengecualikan produsen blok yang menyerang. Lainnya kemungkinan serangan terdiri dari menerbitkan lebih banyak proposal dasar negara bagian daripada yang dapat diverifikasi oleh pihak yang berselisih, yang dapat dihindari dengan menggunakan batas frekuensi. 4.1.1. Penarikan optimis yang cepat Karena validitas Optimistic Rollup dapat diverifikasi kapan saja oleh Full Node mana pun, a oracle tepercaya dapat digunakan untuk mengetahui di L1 apakah penarikan dapat diselesaikan dengan aman. Ini mekanisme pertama kali diusulkan oleh Pembuat [21]: oracle memverifikasi penarikan, menerbitkan hasil pada L1 di mana pinjaman berbunga diberikan kepada pengguna, yang secara otomatis ditutup pada akhir 7 hari, yaitu saat penarikan benar-benar dapat diselesaikan. Solusi ini memperkenalkan asumsi kepercayaan, tetapi dalam kasus Maker, asumsi ini diminimalkan karena operator oracle dikelola oleh organisasi yang sama yang menanggung risiko dengan memberikan pinjaman. 4.2. Biaya transaksi Biaya transaksi L2 sebagian besar ditentukan oleh interaksi dengan L1. Dalam kedua solusi biaya komputasi transaksi sangat murah karena dijalankan sepenuhnya secara off-chain. Optimism menerbitkan data panggilan transaksi L2 sebagai data panggilan dan jarang (atau tidak pernah) mengeksekusi kesalahan buktinya, oleh karena itu calldata adalah sumber daya yang paling mahal. Pada 12 Januari 2022 jaringan Bedrock telah diluncurkan di testnet Goerli Ethereum. Tingkat kompresi gas dapat dihitung dengan melacak jumlah gas yang digunakan pada Batuan Dasar dalam periode tertentu dan membandingkannya dengan jumlah gas yang dihabiskan pada L1 untuk blok terkait. Menggunakan metode ini kompresi gas tingkat ∼20 : 1 ditemukan, namun angka ini mungkin berbeda dengan aktivitas nyata di mainnet. StarkNet diterbitkan pada Ethereum setiap perubahan status L2 sebagai data panggilan, oleh karena itu penyimpanan adalah sumber daya yang paling mahal. Karena jaringan tidak menggunakan EVM, biaya transaksinya kompresi tidak dapat diperkirakan dengan mudah. Dengan mengasumsikan biaya eksekusi dan data panggilan dapat diabaikan, dimungkinkan untuk menghitung rasio kompresi penulisan penyimpanan dibandingkan dengan L1. Dengan asumsi tidak ada kontrak yang diterapkan dan 10 sel yang sebelumnya tidak diakses di StarkNet adalah dimodifikasi, ditemukan tingkat kompresi biaya tulis penyimpanan ∼24 : 1. Jika sel ditimpa 𝑛waktu antar publikasi data, biaya setiap penulisan akan menjadi 1/𝑛dibandingkan dengan biayanya dari satu tulisan, karena hanya yang terakhir yang diterbitkan. Biaya dapat diminimalkan lebih lanjut denganmengompresi nilai yang sering digunakan. Biaya verifikasi bukti keabsahan dibagi diantara transaksi yang dimaksud: misalnya, StarkNet blok 4779 berisi 200 transaksi dan bukti validitas mengkonsumsi 267830 unit gas atau 1339,15 gas untuk setiap transaksi. 4.2.1. Mengoptimalkan data panggilan: kontrak cache Disajikan di bawah ini adalah smart contract yang mengimplementasikan cache alamat yang sering digunakan alamat dengan memanfaatkan fakta bahwa penyimpanan dan eksekusi jauh lebih murah sumber daya, bersama dengan kontrak Teman yang menunjukkan penggunaannya. Yang terakhir melacak “teman” dari suatu alamat yang dapat didaftarkan dengan memanggil fungsi addFriend. Jika sebuah alamat telah digunakan minimal satu kali, dapat ditambahkan dengan memanggil addFriendWithCache fungsi: indeks cache adalah bilangan bulat 4-byte sedangkan alamat diwakili oleh 20 byte, jadi ada penghematan 5:1 pada argumen fungsi. Logika yang sama dapat digunakan untuk data lain jenis seperti bilangan bulat atau lebih umum byte. kontrak AlamatCache { pemetaan(alamat => uint32) alamat2 kunci publik; alamat[] kunci2 publik; fungsi cacheWrite(alamat _alamat) pengembalian internal (uint32) { require(key2address.length < type(uint32).max, "AddressCache: cache penuh"); require(address2key[_address] == 0, "AddressCache: alamat sudah di-cache"); // kunci harus dimulai dari 1 karena 0 berarti "tidak ditemukan" kunci uint32 = uint32(alamat kunci2.panjang + 1); alamat2kunci[_alamat] = kunci; key2address.push(_address); kunci kembali; } fungsi cacheRead(uint32 _key) tampilan publik kembali (alamat) { require(_key <= key2address.length && _key > 0, "AddressCache: kunci tidak ditemukan"); kembalikan alamat kunci2[_kunci - 1]; } } Daftar 2: Kontrak cache alamat. kontrak Teman adalah AddressCache { pemetaan(alamat => alamat[]) teman umum; fungsi addFriend(alamat _teman) publik { teman[pesan.pengirim].push(_teman); cacheWrite(_teman); } fungsi addFriendWithCache(uint32 _friendKey) publik { teman[pesan.pengirim].push(cacheRead(_friendKey)); } function getFriends() tampilan publik kembali (alamat[] memori) { kembalikan teman[pesan.pengirim];} } Listing 3: Contoh kontrak yang mewarisi cache alamat. Kontrak tersebut mendukung cache sekitar 4 miliar (232) alamat, dan menambahkan satu byte akan menghasilkan sekitar 1 triliun (240). 4.2.2. Mengoptimalkan penyimpanan: filter Bloom Pada StarkNet ada beberapa teknik untuk meminimalkan penggunaan penyimpanan. Jika tidak perlu menjamin ketersediaan data asli maka cukup untuk menyimpan hash on-chain-nya: ini adalah mekanisme yang digunakan untuk menyimpan data untuk ERC-721 (NFT) [22], yaitu tautan IPFS yang menyelesaikan hash data jika tersedia. Untuk data yang disimpan berkali-kali, dimungkinkan untuk menggunakan pencarian tabel serupa dengan sistem cache yang diperkenalkan untuk Optimism, yang mengharuskan semua nilai disimpan setidaknya sekali. Untuk beberapa aplikasi, menyimpan semua nilai dapat dihindari dengan menggunakan filter Bloom [23, 24, 25], yaitu struktur data probabilistik yang memungkinkan seseorang mengetahui dengan pasti apakah suatu elemen tidak termasuk dalam suatu himpunan tetapi memiliki kemungkinan salah yang kecil namun tidak dapat diabaikan positif. Filter Bloom diinisialisasi sebagai array 𝑚bit di nol. Untuk menambahkan elemen, 𝑘hash berfungsi dengan distribusi acak seragam digunakan, masing-masing memetakan ke sedikit array yang diatur ke 1. Untuk memeriksa apakah suatu elemen termasuk dalam himpunan, kita jalankan fungsi 𝑘hash dan verifikasi bahwa 𝑘bit disetel ke 1. Dalam filter Bloom yang sederhana, tidak ada cara untuk membedakan apakah suatu elemen sebenarnya termasuk dalam himpunan atau merupakan positif palsu, probabilitas yang bertambah seiring dengan bertambahnya angka entri meningkat. Setelah memasukkan 𝑛elemen: P[positif palsu] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 dengan asumsi independensi probabilitas setiap set bit. Jika 𝑛elemen (dengan ukuran sembarang!) adalah diharapkan untuk disertakan dan probabilitas toleransi positif palsu adalah 𝑝, ukuran array dapat dihitung sebagai: 𝑚= −𝑛ln 𝑝 (dalam 2)2 Sedangkan jumlah fungsi hash yang optimal adalah: 𝑘= 𝑚 𝑛ln 2 Jika kita berasumsi untuk memasukkan 1000 elemen dengan toleransi 1%, ukuran array adalah 9585 bit dengan 𝑘= 6, sedangkan untuk toleransi 0.1% menjadi 14377 bit dengan 𝑘= 9. Jika sejuta elemen diharapkan untuk dimasukkan, ukuran array menjadi sekitar 1170 kB untuk 1% dan 1775 kB untuk 0,1%, dengan nilai 𝑘 yang sama, karena hanya bergantung pada 𝑝[26]. Dalam permainan di mana pemain tidak boleh ditugaskan ke lawan yang telah mereka tantang, alih-alih menyimpan daftar lawan masa lalu di penyimpanan untuk setiap pemain, kita dapat menggunakan Bloom menyaring. Risiko tidak menantang beberapa pemain seringkali dapat diterima, dan filter dapat diatur ulang secara berkala.4.3. Ethereum kompatibilitas Keuntungan utama karena kompatibel dengan EVM dan Ethereum adalah penggunaan kembali semua yang tersedia alat. Ethereum smart contracts dapat dipublikasikan di Optimism tanpa modifikasi apa pun atau audit baru. Dompet tetap kompatibel, alat pengembangan dan analisis statis, analisis umum alat, alat pengindeksan, dan oracles. Ethereum dan Soliditas memiliki sejarah panjang yang dipelajari dengan baik kerentanan, seperti serangan masuk kembali, luapan dan arus bawah, pinjaman kilat, dan oracle manipulasi. Oleh karena itu, Optimism mampu memperoleh sejumlah besar nilai dalam waktu singkat waktu. Memilih untuk mengadopsi mesin virtual yang berbeda berarti harus membangun kembali seluruh ekosistem, dengan keuntungan dari kebebasan implementasi yang lebih besar. StarkNet mengimplementasikan akun secara asli abstraksi, yang merupakan mekanisme dimana setiap akun adalah smart contract yang dapat diimplementasikan logika sewenang-wenang asalkan sesuai dengan antarmuka (maka istilah abstraksi): ini memungkinkan penggunaan skema tanda tangan digital yang berbeda, kemampuan untuk mengubah kunci pribadi menggunakan alamat yang sama, atau gunakan multisig. Komunitas Ethereum mengusulkan pengenalan ini mekanisme dengan EIP-2938 pada tahun 2020, tetapi proposal tersebut tetap basi selama lebih dari satu tahun karena pembaruan lainnya telah diberi prioritas lebih [27]. Manfaat penting lainnya yang diperoleh dari kompatibilitas adalah penggunaan kembali klien yang sudah ada: Optimism menggunakan versi geth untuk simpulnya sendiri dengan hanya ∼800 baris perbedaan, yang telah terjadi dikembangkan, diuji, dan dipelihara sejak tahun 2014. Memiliki klien yang kuat sangatlah penting dalam definisinya apa yang diterima valid atau tidak dalam jaringan. Bug dalam penerapan bukti kesalahan sistem dapat menyebabkan bukti yang salah diterima sebagai benar atau bukti yang benar untuk tidak valid blok untuk diterima sebagai salah, membahayakan sistem. Kemungkinan seperti ini serangan dapat dibatasi dengan keragaman klien yang lebih luas: Optimism dapat digunakan kembali selain mendapatkan klien Ethereum lainnya telah dikelola, dan pengembangan klien berbasis Erigon lainnya sedang dilakukan sudah berlangsung. Pada tahun 2016 masalah dalam manajemen memori geth dieksploitasi untuk a Serangan DoS dan garis pertahanan pertama adalah merekomendasikan penggunaan Parity, yang kedua terbanyak klien yang digunakan pada saat itu 5. StarkNet menghadapi masalah yang sama dengan bukti validitas, tetapi klien harus ditulis dari awal dan sistem pembuktiannya jauh lebih kompleks, dan akibatnya itu juga jauh lebih kompleks untuk memastikan kebenarannya.

Comparação

Comparação 4.1. Tempo de retirada O aspecto mais importante que distingue os Rollups Otimistas dos Rollups de Validade é o tempo que decorre entre a inicialização de um levantamento e a sua finalização. Em ambos os casos, as retiradas são inicializadas em L2 e finalizadas em L1. Em StarkNet, a finalização é possível como assim que a prova de validade da nova raiz de estado for aceita em Ethereum: teoricamente, é possível retirar fundos no primeiro bloco de L1 após a inicialização. Na prática, o frequência de envio de provas de validade em Ethereum é uma compensação entre a velocidade do bloco finalização e agregação de provas. Atualmente StarkNet fornece provas de validade para verificação a cada 10 horas 4, mas pretende-se que diminua à medida que a atividade de transação aumenta. Em Optimism Bedrock é possível finalizar um saque somente no final da disputa período (atualmente 7 dias), após o qual uma raiz é automaticamente considerada válida. O comprimento de este período é determinado principalmente pelo fato de que as provas de falha podem ser censuradas em Ethereum até seu fim. A probabilidade de sucesso deste tipo de ataque diminui exponencialmente à medida que o tempo aumenta: E[valor subtraído] = 𝑉𝑝𝑛 onde 𝑛 é o número de blocos em um intervalo, 𝑉 é a quantidade de fundos que pode ser subtraída publicando uma raiz inválida, e 𝑝é a probabilidade de realizar uma censura com sucesso ataque em um único bloco. Suponha que esta probabilidade seja de 99%, que o valor bloqueado no Rollup é um milhão de Ether, e que os blocos em um intervalo são 1800 (6 horas de blocos com 12 intervalo de segundos): o valor esperado é cerca de 0,01391 Ether. O sistema é tornado seguro por pedindo aos proponentes que apostem uma quantidade muito maior de Ether do que o valor esperado. Winzer et al. mostrou como realizar um ataque de censura usando um simples smart contract isso garante que certas áreas da memória no estado não mudem [20]. Modelando o ataque como um jogo de Markov, o artigo mostra que a censura é a estratégia dominante para uma bloquear o produtor se receberem mais compensação do que incluindo a transação que muda a memória. O valor de 𝑝 discutido acima pode ser visto como a percentagem do bloco racional produtores da rede, onde “racional” não leva em conta possivelmente penalizar externalidades, como menos confiança no blockchain que diminui seu valor de criptomoeda. O código a seguir apresenta um smart contract que pode ser usado para realizar um ataque de censura em Bedrock. O ataque explora os incentivos dos produtores de blocos, oferecendo-lhes suborno censurar as transações que modificariam partes específicas do estado. O principal do contrato função, ClaimBribe, permite que os produtores de blocos reivindiquem o suborno se conseguirem censurar a transação alvo, verificando se a raiz de saída inválida não foi tocada. função reivindicaçãoSuborno(bytes memória storageProof) externo { require(!claimed[block.number], "suborno já reivindicado"); Memória OutputProposal atual = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, prova de armazenamento); require(invalidOutputRoot == current.outputRoot, "ataque falhou"); reivindicado[bloco.número] = verdadeiro; (bool enviado,) = block.coinbase.call{valor: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(enviado, "falha ao enviar ether"); } Listagem 1: Exemplo de contrato que incentiva um ataque de censura a Bedrock. A duração do período de litígio também deve ter em conta o facto de a prova da culpa ser uma prova interativa e, portanto, deve ser fornecido tempo suficiente para os participantes interagirem e que qualquer interação poderia ser censurada. Se o último movimento ocorrer num momento muito próximo do final do período de disputa, o custo da censura é significativamente menor. Embora a censura seja o estratégia dominante, a probabilidade de sucesso é menor porque os nós de censura são vulneráveis a Ataques de negação de serviço: um invasor pode gerar transações muito complexas que terminam com o publicação de uma prova de culpa sem nenhum custo, uma vez que nenhuma taxa seria paga. Em casos extremos, um longo período de litígio permite a coordenação no caso de uma decisão bem-sucedida. ataque de censura para organizar um fork e excluir os produtores de blocos atacantes. Outro possível ataque consiste em publicar mais propostas de raiz estatal do que os disputantes podem verificar, que pode ser evitado usando um limite de frequência. 4.1.1. Retiradas rápidas e otimistas Como a validade de um Optimistic Rollup pode ser verificada a qualquer momento por qualquer Full Node, um confiável oracle pode ser usado para saber em L1 se a retirada pode ser finalizada com segurança. Isto mecanismo foi proposto pela primeira vez pelo Maker [21]: um oracle verifica a retirada, publica o resultado em L1 em que um empréstimo remunerado é atribuído ao usuário, que é automaticamente fechado ao final de 7 dias, ou seja, quando o saque pode realmente ser finalizado. Esta solução introduz uma suposição de confiança, mas no caso do Maker ela é minimizada, pois o operador oracle é gerido pela mesma organização que assume o risco ao conceder o empréstimo. 4.2. Custos de transação O custo das transações L2 é determinado principalmente pela interação com a L1. Em ambas as soluções o custo computacional das transações é muito barato, pois é executado inteiramente fora da cadeia. Optimism publica calldata de transações L2 como calldata e raramente (ou nunca) executa falha provas, portanto calldata é o recurso mais caro. Em 12 de janeiro de 2022, uma rede Bedrock foi lançado na testnet Goerli de Ethereum. Uma taxa de compressão de gás pode ser calculada rastreando a quantidade de gás usada em Bedrock em um determinado período e comparando-a com o quantidade de gás gasta em L1 para os blocos correspondentes. Usando este método, uma compressão de gás taxa de ∼20: 1 é encontrada, mas este número pode diferir com a atividade real na rede principal. StarkNet publica em Ethereum todas as alterações no estado L2 como dados de chamada, portanto, o armazenamento é o recurso mais caro. Como a rede não utiliza EVM, o custo da transação a compressão não pode ser estimada trivialmente. Ao assumir o custo de execução e calldata para ser insignificante, é possível calcular a taxa de compactação de gravações de armazenamento em comparação com L1. Supondo que nenhum contrato seja implantado e 10 células não acessadas anteriormente em StarkNet sejam modificado, uma taxa de compactação de custo de gravação de armazenamento de ∼24: 1 é encontrada. Se uma célula for sobrescrita 𝑛vezes entre publicações de dados, o custo de cada gravação será 1/𝑛comparado ao custo de uma única escrita, já que apenas a última é publicada. O custo pode ser ainda mais minimizado porcompactando valores usados com frequência. O custo da verificação da prova de validade é dividido entre as transações às quais se refere: por exemplo, o bloco StarkNet 4779 contém 200 transações e seu o comprovante de validade consome 267.830 unidades de gás, ou 1.339,15 gás para cada transação. 4.2.1. Otimizando calldata: contrato de cache Apresentado abaixo está um smart contract que implementa um cache de endereço para uso frequente endereços aproveitando o fato de que o armazenamento e a execução são muito mais baratos recursos, juntamente com um contrato de Amigos que demonstra seu uso. Este último acompanha o “amigos” de um endereço que pode ser registrado chamando a função addFriend. Se um endereço já foi usado pelo menos uma vez, ele pode ser adicionado chamando addFriendWithCache função: os índices de cache são inteiros de 4 bytes enquanto os endereços são representados por 20 bytes, portanto, há uma economia de 5:1 no argumento da função. A mesma lógica pode ser usada para outros dados tipos como inteiros ou, mais geralmente, bytes. contrato AddressCache { mapeamento (endereço => uint32) public address2key; endereço[] endereço-chave2 público; função cacheWrite(address _address) retornos internos (uint32) { require(key2address.length <type(uint32).max, "AddressCache: cache está cheio"); require(address2key[_address] == 0, "AddressCache: endereço já armazenado em cache"); // as chaves devem começar em 1 porque 0 significa "não encontrado" chave uint32 = uint32(key2address.length + 1); endereço2key[_endereço] = chave; key2address.push(_address); chave de retorno; } função cacheRead (uint32 _key) visualização pública retorna (endereço) { require(_key <= key2address.length && _key > 0, "AddressCache: chave não encontrada"); retornar key2address[_key - 1]; } } Listagem 2: Contrato de cache de endereço. contrato Amigos é AddressCache { mapeamento(endereço => endereço[]) amigos públicos; function addAmigo(endereço_amigo) public { amigos[msg.remetente].push(_amigo); cacheWrite(_amigo); } função addFriendWithCache(uint32 _friendKey) public { amigos[msg.sender].push(cacheRead(_friendKey)); } função getFriends() visualização pública retorna (endereço[] memória) { retornar amigos[msg.sender];} } Listagem 3: Exemplo de contrato que herda o cache de endereços. O contrato suporta em cache cerca de 4 bilhões (232) endereços, e adicionar um byte dá cerca de 1 trilhão (240). 4.2.2. Otimizando o armazenamento: filtros Bloom Em StarkNet existem diversas técnicas para minimizar o uso de armazenamento. Se não for necessário garantir a disponibilidade dos dados originais, então é suficiente salvar on-chain seu hash: este é o mecanismo usado para salvar dados para um ERC-721 (NFT) [22], ou seja, um link IPFS que resolve o hash dos dados, se disponíveis. Para dados armazenados diversas vezes, é possível usar uma pesquisa tabela semelhante ao sistema de cache introduzido para Optimism, exigindo que todos os valores sejam salvos em pelo menos uma vez. Para algumas aplicações, salvar todos os valores pode ser evitado usando um filtro Bloom [23, 24, 25], ou seja, uma estrutura de dados probabilística que permite saber com certeza se um elemento não pertence a um conjunto, mas admite uma probabilidade pequena, mas não desprezível, de falso positivos. Um filtro Bloom é inicializado como uma matriz de 𝑚bits em zero. Para adicionar um elemento, 𝑘hash funções com uma distribuição aleatória uniforme são usados, cada um mapeando para um bit da matriz que está definida para 1. Para verificar se um elemento pertence ao conjunto, executamos as funções 𝑘hash e verificamos que os 𝑘bits estão definidos como 1. Num filtro de Bloom simples, não há como distinguir se um elemento realmente pertence ao conjunto ou é um falso positivo, uma probabilidade que aumenta à medida que o número de entradas aumenta. Depois de inserir 𝑛elementos: P[falso positivo] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 assumindo a independência da probabilidade de cada conjunto de bits. Se 𝑛elementos (de tamanho arbitrário!) são espera-se que seja incluído e a probabilidade de um falso positivo tolerado é 𝑝, o tamanho da matriz pode ser calculado como: 𝑚= −𝑛ln 𝑝 (Em 2)2 Embora o número ideal de funções hash seja: 𝑘= 𝑚 𝑛ln 2 Se assumirmos a inserção de 1.000 elementos com tolerância de 1%, o tamanho do array será de 9.585 bits com 𝑘= 6, enquanto para uma tolerância de 0,1% torna-se 14377 bits com 𝑘= 9. Se um milhão de elementos espera-se que sejam inseridos, o tamanho da matriz torna-se cerca de 1170 kB para 1% e 1775 kB para 0,1%, com os mesmos valores de 𝑘, pois depende apenas de 𝑝[26]. Num jogo em que os jogadores não devem ser atribuídos a um adversário que já tenham desafiado, em vez de salvar no armazenamento para cada jogador a lista de oponentes anteriores, pode-se usar um Bloom filtro. O risco de não desafiar alguns jogadores é muitas vezes aceitável, e o filtro pode ser reiniciado periodicamente.4.3. Ethereum compatibilidade A principal vantagem de ser compatível com EVM e Ethereum é o reaproveitamento de todos os disponíveis ferramentas. Ethereum smart contracts podem ser publicados em Optimism sem qualquer modificação nem novas auditorias. As carteiras permanecem compatíveis, ferramentas de desenvolvimento e análise estática, análise geral ferramentas, ferramentas de indexação e oracles. Ethereum e Solidity têm uma longa história de estudos bem estudados vulnerabilidades, como ataques de reentrada, overflows e underflows, empréstimos instantâneos e oracle manipulações. Por causa disso, Optimism foi capaz de capturar uma grande quantidade de valor em um curto espaço de tempo tempo. Optar por adotar uma máquina virtual diferente implica reconstruir todo um ecossistema, com a vantagem de uma maior liberdade de implementação. StarkNet implementa conta nativamente abstração, que é um mecanismo pelo qual cada conta é um smart contract que pode implementar lógica arbitrária, desde que esteja em conformidade com uma interface (daí o termo abstração): isso permite o uso de diferentes esquemas de assinatura digital, a capacidade de alterar a chave privada usando o mesmo endereço ou use um multisig. A comunidade Ethereum propôs a introdução deste mecanismo com EIP-2938 em 2020, mas a proposta permaneceu obsoleta por mais de um ano como outras atualizações receberam mais prioridade [27]. Outro benefício importante obtido com a compatibilidade é a reutilização de clientes existentes: Optimism usa uma versão de geth para seu próprio nó com apenas 800 linhas de diferença, que foi desenvolvido, testado e mantido desde 2014. Ter um cliente robusto é crucial, pois define o que é aceito como válido ou não na rede. Um bug na implementação da prova de falhas sistema pode fazer com que uma prova incorreta seja aceita como correta ou uma prova correta para uma prova inválida. bloco seja aceito como incorreto, comprometendo o sistema. A probabilidade deste tipo de o ataque pode ser limitado com uma diversidade maior de clientes: Optimism pode reutilizar além de obter o outros clientes Ethereum já mantidos, e o desenvolvimento de outro cliente baseado em Erigon está já em andamento. Em 2016 um problema no gerenciamento de memória do geth foi explorado por um ataque DoS e a primeira linha de defesa foi recomendar o uso de Paridade, o segundo mais cliente usado na época 5. StarkNet enfrenta o mesmo problema com provas de validade, mas os clientes tem que ser escrito do zero e o sistema de provas é muito mais complexo e, conseqüentemente, também é muito mais complexo garantir a correção.

Kesimpulan

Kesimpulan Rollup adalah solusi paling menjanjikan yang tersedia saat ini untuk memecahkan masalah skalabilitas blockchains yang terdesentralisasi, membuka jalan bagi era blockchains yang modular dibandingkan dengan monolitik blockchains. Pilihan untuk mengembangkan Optimistic Rollup atau Validity Rollup terutama ditampilkan sebagai trade-off antara kompleksitas dan ketangkasan. StarkNet memiliki banyak keunggulan seperti cepat penarikan, ketidakmampuan struktural untuk memiliki transisi negara yang tidak valid, biaya transaksi yang lebih rendah biaya periode pengembangan yang lebih lama dan ketidakcocokan dengan EVM, sedangkan Optimism memiliki memanfaatkan ekonomi jaringan untuk dengan cepat memperoleh pangsa pasar yang besar. Optimism Batuan dasar, bagaimanapun, memiliki desain modular yang memungkinkannya menjadi Validitas 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup di masa mendatang: Cannon saat ini menggunakan minigeth yang dikompilasi ke MIPS sebagai bukti kesalahannya sistem, tetapi arsitektur yang sama dapat digunakan untuk memperoleh rangkaian dan menghasilkan bukti validitas. Mengkompilasi mesin yang kompleks seperti EVM untuk mikroarsitektur menghasilkan cara yang lebih sederhana sirkuit yang tidak perlu dimodifikasi dan diverifikasi ulang jika terjadi peningkatan. RISC Nol adalah a mikroarsitektur yang dapat diverifikasi dengan bukti STARK sudah dalam pengembangan berdasarkan RISC-V yang dapat digunakan untuk tujuan ini sebagai alternatif untuk MIPS [28]. Salah satu aspek yang tidak boleh dianggap remeh adalah kompleksitas dalam memahami cara kerja teknologi bekerja. Kekuatan blockchain tradisional adalah mampu memverifikasi keadaan blockchain tanpa mempercayai entitas pihak ketiga mana pun. Namun, dalam kasus StarkNet, itu benar perlu untuk mempercayai implementasi ketika tidak mungkin untuk memverifikasi berbagai komponen berdasarkan kriptografi dan matematika tingkat lanjut. Hal ini pada awalnya dapat menimbulkan gesekan bagi adopsi teknologi, namun seiring kemajuan alat dan penggunaan bukti integritas di luar bidang blockchain semoga masalah ini dapat teratasi.

Conclusão

Conclusão Rollups são a solução mais promissora disponível atualmente para resolver o problema de escalabilidade em blockchains descentralizados, abrindo caminho para a era dos blockchains modulares em oposição a blockchains monolíticos. A escolha de desenvolver um Rollup Otimista ou um Rollup de Validade é mostrada principalmente como uma compensação entre complexidade e agilidade. StarkNet tem inúmeras vantagens, como rapidez retiradas, incapacidade estrutural de ter transições de estado inválidas, menor custo de transação no despesa de um período de desenvolvimento mais longo e incompatibilidade com EVM, enquanto Optimism tem alavancou a economia de rede para ganhar rapidamente uma grande fatia do mercado. Optimism Bedrock, entretanto, possui um design modular que permite que ele se torne um Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup no futuro: Cannon atualmente usa minigeth compilado em MIPS para sua prova de falhas sistema, mas a mesma arquitetura pode ser usada para obter um circuito e produzir provas de validade. Compilar uma máquina complexa como EVM para uma microarquitetura resulta em uma solução mais simples circuito que não precisa ser modificado e verificado novamente em caso de atualizações. RISC Zero é um microarquitetura verificável com provas STARK já em desenvolvimento com base em RISC-V que pode ser usado para esta finalidade como uma alternativa a MIPS [28]. Um aspecto que não deve ser subestimado é a complexidade em compreender como o a tecnologia funciona. Um ponto forte dos blockchains tradicionais é ser capaz de verificar o estado de o blockchain sem confiar em nenhuma entidade terceirizada. No entanto, no caso de StarkNet, é necessário confiar na implementação quando não é possível verificar os vários componentes baseado em criptografia e matemática avançada. Isto pode inicialmente criar atrito para o adoção da tecnologia, mas à medida que as ferramentas e o uso de provas de integridade avançam ainda mais fora do campo blockchain este problema será resolvido.