Dokumentasi Teknis Optimism

Автор Optimism Collective · 2021

У Optimism нет традиционного вайтпейпера. Будучи оптимистичным роллапом Layer 2 для Ethereum, его устройство и спецификации задокументированы в технической документации, спецификации OP Stack и исследовательских публикациях, а не в едином формальном академическом документе.

🇺🇸 English (Оригинал)

🇮🇩 Bahasa Indonesia (Перевод)

Аннотация

В статье рассматривается проблема масштабируемости децентрализованных blockchain путем анализа компромисса между пропускной способностью транзакций и требованиями к оборудованию для запуска узла. Свертывания, то есть технологии проверки блоков, выполняемых вне сети, представлены в форме доказательств неисправности или достоверности. Мы сравниваем оптимистичные накопительные пакеты и накопительные пакеты по сроку действия с точки зрения времени вывода средств, транзакционных издержек, методов оптимизации и совместимости с экосистемой Ethereum. Наш анализ показывает, что Optimism Bedrock в настоящее время имеет степень сжатия газа примерно 20:1, а StarkNet обеспечивает степень сжатия стоимости записи в хранилище примерно 24:1. Мы также обсуждаем методы дальнейшей оптимизации этих скоростей, такие как использование контрактов кэша и фильтров Блума. В конечном счете, наши выводы подчеркивают компромисс между сложностью и гибкостью при выборе между оптимистичными и валидными накопительными пакетами. Ключевые слова Блокчейн, Масштабируемость, Объединение 1. Введение Технология Блокчейн привлекла значительное внимание благодаря своему потенциалу совершить революцию в различных отраслях. Однако масштабируемость остается серьезной проблемой, поскольку большинство blockchain сталкиваются с компромиссом между масштабируемостью, децентрализацией и безопасностью, обычно называемым «трилеммой масштабируемости» [1, 2]. Чтобы увеличить пропускную способность blockchain, тривиальным решением является увеличение размера его блока. В контексте Ethereum это означает увеличение максимального количества газа, которое может содержать блок. Поскольку каждый полный узел должен проверять каждую транзакцию каждого блока, по мере увеличения пропускной способности требования к оборудованию также возрастают, что приводит к большей централизации сети. Некоторые blockchain, такие как Bitcoin и Ethereum, оптимизируют свой дизайн, чтобы максимизировать архитектурную децентрализацию, в то время как другие, такие как Binance Smart Chain и Solana, спроектированы так, чтобы быть максимально быстрыми и дешевыми. Децентрализованные сети искусственно ограничивают пропускную способность blockchain, чтобы снизить требования к оборудованию для участия в сети. На протяжении многих лет предпринимались попытки найти решение Трилеммы, например, государственные каналы [3] и Plasma [4, 5]. Эти решения характеризуются перемещением некоторой активности за пределы цепочки, связыванием активности внутри цепочки с активностью вне цепочки с помощью smart contracts и проверкой DLT 2023: 5-й семинар по технологиям распределенного реестра, 25–26 мая 2023 г., Болонья, Италия $ [email protected] (Л. Донно) https://lucadonnoh.github.io/ (Л. Донно) 0000-0001-9221-3529 (Л. Донно) © 2023 Авторские права на эту статью принадлежат ее авторам. Использование разрешено в соответствии с лицензией Creative Commons License Attribution 4.0 International (CC BY 4.0). Материалы семинара CEUR http://ceur-ws.org ISSN 1613-0073 Материалы семинара CEUR (CEUR-WS.org) в сети, что происходит вне сети. Однако как Plasma, так и государственные каналы ограничены в поддержке общих smart contract. Накопительные пакеты — это blockchain (называемые Layer 2 или L2), которые публикуют свои блоки на другом blockchain (Layer 1 или L1) и, следовательно, наследуют его свойства консенсуса, доступности данных и безопасности. Они, в отличие от других решений, поддерживают произвольные вычисления. Rollups состоит из трех основных компонентов: • Секвенсоры: узлы, которые получают транзакции Rollup от пользователей и объединяют их в блок, который отправляется на Layer 1. Блок состоит как минимум из корня состояния (например, корня Меркла) и данных, необходимых для восстановления и проверки состояния. Layer 1 определяет...

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...

Введение

Введение Технология блокчейн привлекла значительное внимание благодаря своему потенциалу совершить революцию. различные отрасли промышленности. Однако масштабируемость остается серьезной проблемой, поскольку большинство blockchain сталкиваются с компромисс между масштабируемостью, децентрализацией и безопасностью, обычно называемый Трилемма масштабируемости [1, 2]. Чтобы увеличить пропускную способность blockchain, есть тривиальное решение: чтобы увеличить размер блока. В контексте Ethereum это означает увеличение максимального количество газа, которое может содержать блок. Поскольку каждый полный узел должен проверять каждую транзакцию каждого блок, поскольку пропускная способность увеличивается, требования к оборудованию также увеличиваются, что приводит к большему централизация сети. Некоторые blockchain, такие как Bitcoin и Ethereum, оптимизируют свои дизайн, чтобы максимизировать свою архитектурную децентрализацию, в то время как другие, такие как Binance Smart Chain и Solana созданы для того, чтобы быть максимально быстрыми и дешевыми. Децентрализованные сети искусственно ограничить пропускную способность blockchain, чтобы снизить требования к оборудованию до участвовать в сети. На протяжении многих лет предпринимались попытки найти решение трилеммы, например, каналы [3] и Плазма [4, 5]. Эти решения имеют свойство перемещать некоторую деятельность оффчейн, связывание активности внутри цепочки с активностью вне цепочки с использованием smart contracts и проверка DLT 2023: 5-й семинар по технологиям распределенного реестра, 25–26 мая 2023 г., Болонья, Италия $ [email protected] (Л. Донно) https://lucadonnoh.github.io/ (Л. Донно) 0000-0001-9221-3529 (Л. Донно) © 2023 Авторские права на данную статью принадлежат авторам. Использование разрешено в соответствии с лицензией Creative Commons License Attribution 4.0 International (CC BY 4.0). ЦЕВР Мастерская Слушания http://ceur-ws.org ISSN 1613-0073 Материалы семинара CEUR (CEUR-WS.org)в сети, что происходит вне сети. Однако как Plasma, так и государственные каналы ограничены в их поддержка генералов smart contracts. Накопительные пакеты — это blockchain (называемые Layer 2 или L2), которые публикуют свои блоки на другом blockchain. (Layer 1 или L1) и, следовательно, наследуют его свойства консенсуса, доступности данных и безопасности. Они, в отличие от других решений, поддерживают произвольные вычисления. Накопительные пакеты состоят из трех основных компонентов: • Секвенсоры: узлы, которые получают транзакции Rollup от пользователей и объединяют их в блок, который отправляется на Layer 1. Блок состоит как минимум из корня состояния (например, Меркла root) и данные, необходимые для восстановления и проверки состояния. Layer 1 определяет канонический blockchain L2 путем установления порядка опубликованных данных. • Полные узлы объединения: узлы, которые получают, обрабатывают и проверяют блоки объединения из слоя. 1, проверив правильность корня. Если блок содержит недействительные транзакции, то это так. отброшено, что не позволяет секвенаторам создавать действительные блоки, содержащие недопустимые транзакции. • Легкие узлы объединения: узлы, которые получают блоки объединения из Layer 1, но не выполняют вычисления. само новое государство. Они проверяют, что новый корень состояния действителен, используя методы такие как доказательства вины или действительности. Накопительные пакеты обеспечивают масштабируемость за счет уменьшения амортизированной стоимости транзакций по мере увеличения количества пользователей увеличивается. Это связано с тем, что стоимость обеспечения достоверности blockchain растет сублинейно. в отношении стоимости проверки транзакций в индивидуальном порядке. Свернутые пакеты различаются в зависимости от механизм, с помощью которого они обеспечивают достоверность выполнения транзакций на легких узлах: в Оптимистические накопительные пакеты обеспечиваются экономической моделью и доказательствами ошибок, пока они действительны. Rollups криптографически обеспечивается с использованием доказательств достоверности. Легкие узлы могут быть реализованы как smart contract на Layer 1. Они принимают корень новое состояние и проверка действительности или доказательств ошибок: поэтому эти накопительные пакеты называются смарт-контрактом. Ролл-апы. Если легкие узлы независимы, они называются суверенными накопительными пакетами [6]. Преимущество использование накопительного пакета смарт-контрактов позволяет построить между ними мост с минимальным доверием. blockchains: поскольку достоверность состояния L2 доказана для L1, система транзакций из Можно реализовать L2–L1, что позволит осуществлять снятие средств. Недостатком является то, что стоимость транзакций зависит от стоимости проверки состояния на L1: если базовый уровень насыщен других видов деятельности, стоимость транзакций в Rollup также увеличивается. Уровни данных и консенсуса — это те, которые определяют безопасность системы как они определяют порядок транзакций, предотвращают атаки и предоставляют данные для подтверждения состояния действительность. Бумажный вклад В этой статье мы изучаем оптимистические и валидные сводные данные, два инновационных метода. решения трилеммы масштабируемости с упором на известные реализации, такие как Optimism Bedrock и StarkNet. Наш вклад включает всестороннее сравнение этих решения, анализ времени вывода средств и обсуждение возможной атаки на Optimism. Коренная порода. Кроме того, мы рассчитываем степень сжатия газа, обеспечиваем оптимизацию для конкретных приложений и представляем преимущества и недостатки отказа от Ethereum. Виртуальная машина (EVM).

Структура бумаги Статья организована следующим образом. В разделе 2 приведены оптимистичные сводные данные. введено путем анализа Optimism коренных пород. В разделе 3 сводные данные о сроках действия представлены анализируем StarkNet. В разделе 4 мы сравниваем два решения. Наконец, в разделе 5 мы рисуем некоторые выводы.

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.

Оптимистичные сводки

Оптимистичные сводки Идея оптимистичного принятия вывода блоков без проверки их выполнения уже присутствует в официальном документе Bitcoin [7], где обсуждаются легкие узлы. Эти узлы следуют только цепочку заголовков, проверяя правило консенсуса, что делает их уязвимыми для приема блоков содержащие недействительные транзакции в случае атаки 51%. Накамото предлагает решить эту проблему проблема с использованием системы «оповещения», предупреждающей легкие узлы о том, что блок содержит недопустимые транзакции. Этот механизм впервые был реализован Аль-Бассамом, Соннино и Бутерином [8], в котором возникла ошибка используется система подтверждения, основанная на кодах исправления ошибок [9]. Для того, чтобы обеспечить возможность создания Для проверки ошибок необходимо, чтобы данные всех блоков, включая недействительные, были доступны сеть: это проблема доступности данных, которая решается с использованием вероятностных данных механизм выборки. Первый дизайн Optimistic Rollup был представлен Джоном Адлером и Микера Квинтайн-Коллинз в 2019 году [10], в котором блоки опубликованы на другом blockchain. это определяет их консенсус относительно порядка. 2.1. Optimism Коренная порода Bedrock [11] — это последняя версия Optimism, накопительного пакета смарт-контрактов. Предыдущая версия, Оптимистической виртуальной машине (OVM) требовался специальный компилятор для компиляции Solidity в свою программу. собственный байт-код: напротив, Bedrock полностью эквивалентен EVM в том смысле, что механизм выполнения соответствует спецификации Ethereum Yellow Paper [12]. 2.1.1. Депозиты Пользователи могут вносить транзакции через контракт на Ethereum, портале Optimism, вызывая функцию депозитаTransaction. Когда транзакция выполняется, Выдается событие TransactionDeposited, которое прослушивает каждый узел в накопительном пакете для обработки. депозиты. Депонированная транзакция — это транзакция L2, производная от L1. Если вызывающий абонент функция является контрактом, адрес преобразуется путем добавления к нему постоянного значения: это предотвращает атаки, при которых контракт на L1 имеет тот же адрес, что и контракт на L2, но другой код. Включение в L2 депонированной транзакции обеспечивается спецификацией в рамках секвенирования. окно. Депонированные транзакции — это новый тип транзакции [13], совместимый с EIP-2718, с префиксом 0x7E, где поля в кодировке rlp: • bytes32 sourceHash: hash, который однозначно идентифицирует источник транзакции. • Адрес от: адрес отправителя. • адрес: адрес получателя или нулевой адрес, если депонированная транзакция является создание договора.• uint256 mint: значение, которое будет создано на уровне L2. • Значение uint256: значение, которое будет отправлено получателю. • байтовые данные: входные данные. • байты gasLimit: лимит газа транзакции. SourceHash вычисляется как keccak256 hash блока L1 hash и журнала L1. индекс, однозначно идентифицирующий событие в блоке. Поскольку депонированные транзакции инициируются на L1, но выполняются на L2, системе требуется механизм оплаты на L1 газа, потраченного на L2. Одним из решений является отправка ETH через Портал. но это подразумевает, что каждый вызывающий абонент (даже косвенный вызывающий абонент) должен быть помечен как подлежащий оплате, и это невозможно для многих существующих проектов. Альтернативой является сжигание соответствующего газа на L1. Газ 𝑔, выделяемый для депозитной транзакции, называется гарантированным газом. Цена на газ L2 на L1 не синхронизируется автоматически, но оценивается с использованием механизма, аналогичного EIP-1559. [14]. Максимальное гарантированное количество газа на блок Ethereum составляет 8 миллионов, с целью из 2 миллионов. Количество 𝑐ETH, необходимое для оплаты газа на L2, равно 𝑐= 𝑔𝑏L2, где 𝑏L2 — это базовая плата за L2. Контракт на L1 сжигает количество газа, равное 𝑐/𝑏L2. Газ, потраченный на звонок депозитная транзакция возмещается на L2: если эта сумма превышает гарантированный газ, газ не горит. Первая транзакция блока rollup — это транзакция с депонированием атрибутов L1, используемая для регистрации на L2 предварительно разверните атрибуты блоков Ethereum. Атрибуты, которые дает предварительное развертывание доступом являются номер блока, временная метка, базовая плата, блок hash и последовательность номер, который является номером блока L2 относительно связанного блока L1 (также называемого эпохой); это число сбрасывается при начале новой эпохи. 2.1.2. Секвенирование Узлы объединения полностью наследуют цепочку Optimism от Ethereum. Эта цепочка расширена каждый раз новые транзакции публикуются на L1, и его блоки каждый раз реорганизуются Блоки Ethereum реорганизованы. Накопительный пакет blockchain разделен на эпохи. Для каждого 𝑛 номер блока Ethereum, существует соответствующая 𝑛эпоха. Каждая эпоха содержит по крайней мере один блок, и каждый блок в эпоху содержит транзакцию депонирования атрибутов L1. Первый блок в эпоху содержит все транзакции, проведенные через Портал. Блоки Layer 2 также могут содержали секвенированные транзакции, т.е. транзакции, отправленные непосредственно в секвенсор. Sequencer принимает транзакции от пользователей и строит блоки. Для каждого блока строится пакет будет опубликован Ethereum. Несколько пакетов могут быть опубликованы в сжатом виде, взяв название канала. Канал можно разделить на несколько кадров, если он слишком велик для одна транзакция. Канал определяется как сжатие с помощью ZLIB [15] файлов, закодированных в rlp. партии. Полями пакета являются номер эпохи, эпоха hash, родительская hash, временная метка и список транзакций. Окно секвенирования, идентифицируемое эпохой, содержит фиксированное количество 𝑤 последовательных L1. блоки, которые на этапе деривации используются в качестве входных данных для создания переменного числа блоков L2. Для эпоха 𝑛, окно последовательности 𝑛 включает блоки [𝑛, 𝑛+𝑤). Это означает, что упорядочение Количество транзакций и блоков L2 в окне последовательности не фиксируется до тех пор, пока окно не завершится. Транзакция rollup называется безопасной, если содержащий ее пакет был подтвержден на L1. Рамкисчитываются из блоков L1 для восстановления пакетов. Текущая реализация не позволяет распаковка канала начнется до тех пор, пока не будут получены все соответствующие кадры. Недействительный пакеты игнорируются. Отдельные блочные транзакции получаются из пакетов, которые используется механизмом выполнения для применения переходов между состояниями и получения состояния Rollup. 2.1.3. Вывод средств Для обработки вывода средств реализована система обмена сообщениями L2-L1. Ethereum необходимо знать состояние L2, чтобы принять вывод средств, и это делается путем публикации на выходе L2 Oracle smart contract на L1 - корень состояния каждого блока L2. Эти корни оптимистично принимаются как действительные (или завершенные), если в течение период спора. Только адреса, обозначенные как Предлагающие, могут публиковать выходные корни. Срок действия выходных корней стимулируется тем, что предлагающие вносят ставку, которая сокращается, если они показано, что он предложил неверный корень. Транзакции инициируются вызовом функции инициироватьВывод средств при предварительном развертывании на уровне L2, а затем завершать на уровне L1, вызывая функцию FinalizeWithdrawalTransaction на ранее упомянутом портале Optimism. Выходной корень, соответствующий блоку L2, получается из выходного оракула L2; это проверил, что он завершен, т. е. период диспута прошел; проверено, что Выход Root Proof соответствует Oracle Proof; подтверждено, что hash вывода включен в нем с использованием Доказательства вывода средств; что вывод еще не завершен; а затем выполняется вызов на целевой адрес с указанным лимитом газа, количеством эфира и данными. 2.1.4. Cannon: надежная система Если объединенный полный узел, локально выполняя пакеты и депонированные транзакции, обнаруживает, что состояние Layer 2 не соответствует корню состояния, опубликованному в цепочке Предлагающим, оно может быть выполнено доказательство неисправности на L1, чтобы доказать, что результат перехода к кадру неверен. Из-за накладные расходы, обработка всего блока Rollup на L1 слишком дорога. Решение реализовано от Bedrock — выполнить по цепочке только первую инструкцию несогласия минигетов, компиляция его в архитектуру MIPS, которая выполняется на интерпретаторе цепочки и публикуется на Л1. minigeth — это упрощенная версия geth 1, в которой консенсус, RPC и база данных были удалены. Для нахождения первой инструкции несогласия проводится интерактивный бинарный поиск между тот, кто инициировал проверку неисправности, и тот, кто опубликовал корень вывода. Когда доказательство начинается, обе стороны публикуют корень состояния памяти MIPS в середине выполнения блок в контракте Challenge: если hash совпадает, это означает, что обе стороны согласны на первая половина выполнения, таким образом публикуя корень половины второй половины, в противном случае половина первой половины публикуется и так далее. Таким образом достигается первая инструкция несогласия. за логарифмическое количество шагов по сравнению с исходным выполнением. Если один из двух останавливается взаимодействуя, по окончании периода спора автоматически побеждает другой участник. Для обработки инструкции интерпретатору MIPS необходим доступ к ее памяти: поскольку корень доступны, необходимые ячейки памяти можно опубликовать, доказав их включение. Чтобы получить доступ состояние EVM, используется Oracle Preimage: учитывая hash блока, который он возвращает 1https://geth.ethereum.org/docs

заголовок блока, из которого можно получить hash предыдущего блока и вернуться в цепочку или получить hash состояния и журналы, из которых можно получить прообраз. oracle реализуется minigeth и заменяет базу данных. Запросы выполняются к другим узлам для получить прообразы.

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.

Сводные данные о сроке действия

Сводные данные о сроках действия Целью валидного накопительного пакета является криптографическое доказательство достоверности перехода состояний. учитывая последовательность транзакций с коротким доказательством, которое можно проверить сублинейным сравнением ко времени первоначальных вычислений. Сертификаты такого типа называются доказательствами вычислительной целостности и практически реализуются с помощью SNARK (краткий неинтерактивный аргумент знаний), в которых используются арифметические действия. схемы в качестве их вычислительной модели. Различные реализации SNARK отличаются временем проверки, время проверки, необходимость доверенной установки и квантовое сопротивление [16, 17]. STARK (Масштабируемые Прозрачный аргумент знаний) [18] — это тип SNARK, не требующий доверенного настройки и являются квантово-устойчивыми, но при этом теряют некоторую эффективность при доказательстве и проверке. по сравнению с другими решениями. 3.1. StarkNet StarkNet — это накопительный пакет действительности смарт-контракта, разработанный StarkWare, который использует STARK система доказательства для подтверждения своего состояния до Ethereum. Чтобы облегчить построение доказательств достоверности, используется виртуальная машина, отличная от EVM, языком высокого уровня которой является Cairo. 3.1.1. Депозиты Пользователи могут вносить транзакции через контракт на Ethereum, вызвав sendMessageToL2. функция. Сообщение записывается путем вычисления его hash и увеличения счетчика. Секвенсоры прослушивайте событие LogMessageToL2 и кодируйте информацию в транзакции StarkNet который вызывает функцию контракта, имеющую декоратор l1_handler. В конце исполнения, когда создается доказательство перехода состояния, к нему прилагается потребление сообщения и он удаляется путем уменьшения его счетчика. Спецификация StarkNet не требует включения депонированных транзакций, поэтому газ рынок необходим, чтобы стимулировать секвенаторов публиковать их на L2. В текущей версии, поскольку Секвенсер централизован и управляется StarkWare, стоимость депонируемых транзакций определяется только стоимостью исполнения депозита. Эта стоимость оплачивается путем отправки ETH на sendMessageToL2. Эти эфиры остаются заблокированными на L1 и передаются в секвенсор L1, когда депонированная транзакция включена в переход состояния. Сумма отправленных ETH, если внесенная транзакция включена, расходуется полностью, независимо от количества потребленного газа на Л2. StarkNet не имеет системы, которая автоматически делает атрибуты блока L1 доступными. Альтернативно, Fossil — это протокол, разработанный Oiler Network 2, который позволяет при наличии hash блок, любая информация, которую можно получить от Ethereum путем публикации прообразов. 2https://www.oiler.network/3.1.2. Секвенирование Текущее состояние StarkNet может быть полностью получено из Ethereum. Любая государственная разница между переходами публикуется на L1 как данные вызова. Различия публикуются для каждого контракта и сохраняются как uint256[] со следующей кодировкой: • Количество полей, касающихся развертывания контрактов. • Для каждого опубликованного контракта: – Адрес опубликованного контракта. – hash опубликованного контракта. – Количество аргументов конструктора контракта. – Список аргументов конструктора • Номер контракта, хранилище которого было изменено. • Для каждого измененного контракта: – Адрес измененного контракта. – Количество обновлений хранилища. – Пары ключ-значение адресов хранения с новыми значениями. Государственные различия публикуются по порядку, поэтому достаточно прочитать их последовательно, чтобы реконструировать государство. 3.1.3. Вывод средств Чтобы отправить сообщение с L2 на L1, используется системный вызов send_message_to_L1. Сообщение опубликовано в L1 путем увеличения счетчика hash вместе с доказательством и завершено путем вызова метода функция ConsumerMessageFromL2 на StarkGate smart contract на L1, которая уменьшает счетчик. Любой может завершить вывод средств. 3.1.4. Доказательства действительности Виртуальная машина Cairo [19] предназначена для облегчения построения доказательств STARK. Язык Cairo позволяет описывать вычисления с помощью высокоуровневого программирования. языке, а не непосредственно как цепь. Это осуществляется с помощью системы полиномиальных уравнений 3 представляет одно вычисление: цикл FDE архитектуры фон Неймана. Число Таким образом, количество ограничений фиксировано и независимо от типа вычислений, что позволяет использовать только одно Программа-верификатор для каждой программы, вычисления которой необходимо доказать. StarkNet объединяет несколько транзакций в одно доказательство STARK с использованием общего доказательства. по имени ШАРП. Доказательства отправляются на smart contract Ethereum, который подтверждает их достоверность. и обновляет корень Меркла, соответствующий новому состоянию. Сублинейная стоимость проверки Доказательство действительности позволяет амортизировать его стоимость в рамках нескольких транзакций.
называется алгебраическим промежуточным представлением (AIR).

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)

Сравнение

Сравнение 4.1. Время вывода Наиболее важным аспектом, который отличает оптимистические сводные данные от сводных данных по достоверности, является время, которое проходит между инициализацией вывода средств и его завершением. В обоих случаях Вывод средств инициализируется на L2 и завершается на L1. На StarkNet финализация возможна как как только подтверждение достоверности нового корня состояния будет принято Ethereum: теоретически это возможен вывод средств в первом блоке L1 после инициализации. На практике частота отправки доказательств достоверности на Ethereum — это компромисс между скоростью блока доработка и агрегирование доказательств. В настоящее время StarkNet предоставляет доказательства действительности для проверки. каждые 10 часов 4, но предполагается, что оно будет уменьшаться по мере увеличения активности транзакций. На Optimism Bedrock завершить вывод можно только по окончании диспута. период (на данный момент 7 дней), по истечении которого рут автоматически считается действительным. Длина этот период главным образом определяется тем фактом, что доказательства ошибок могут подвергаться цензуре Ethereum до тех пор, пока его конец. Вероятность успеха этого типа атаки уменьшается экспоненциально с увеличением времени: E[вычтенное значение] = 𝑉𝑝𝑛 где 𝑛 — количество блоков в интервале, 𝑉 — сумма средств, которую можно вычесть опубликовав недействительный корень, и 𝑝это вероятность успешного выполнения цензуры атаковать одним блоком. Предположим, что эта вероятность составляет 99%, что значение, зафиксированное в сводном списке, составляет один миллион эфиров, а блоков в интервале — 1800 (6 часов блоков по 12 интервал секунд): ожидаемое значение составляет около 0,01391 эфира. Система защищена благодаря просить предлагающих поставить на ставку гораздо большее количество эфира, чем ожидаемое значение. Винзер и др. показал, как осуществить цензурную атаку с помощью простого smart contract это гарантирует, что определенные области памяти в состоянии не изменятся [20]. Моделирование атаки как марковская игра, в статье показано, что цензура является доминирующей стратегией рационального производитель блока, если он получит больше компенсации, чем включая транзакцию, которая меняет память. Обсуждаемое выше значение 𝑝 можно рассматривать как процент рационального блока. производителей в сети, где «рационально» не учитывается возможное наказание внешние эффекты, такие как меньшее доверие к blockchain, что снижает его ценность в криптовалюте. Следующий код представляет smart contract, который можно использовать для проведения цензурной атаки. на Бедроке. Атака использует стимулы производителей блоков, предлагая им взятку. подвергать цензуре транзакции, которые изменят определенные части государства. Основной контракт Функция ClaimBribe позволяет производителям блоков требовать взятку, если они успешно подвергают цензуре целевую транзакцию, проверив, что недействительный выходной корень не затронут. функция претензииBribe (байты памяти StorageProof) внешний { require(!claimed[block.number], "взятка уже заявлена"); Текущий объем памяти OutputProposal = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, хранилищеДоказательство); require(invalidOutputRoot == current.outputRoot, «атака не удалась»); заявлено [блок.номер] = правда; (bool отправлено, ) =block.coinbase.call{значение: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, «не удалось отправить эфир»); } Листинг 1: Пример контракта, стимулирующего цензурную атаку на Bedrock. Продолжительность периода спора также должна учитывать тот факт, что доказательство вины интерактивное доказательство, поэтому участникам необходимо предоставить достаточно времени для взаимодействия и что любое взаимодействие может подвергаться цензуре. Если последний ход происходит в момент, очень близкий к В конце периода спора стоимость цензуры значительно меньше. Хотя цензура – это доминирующей стратегии, вероятность успеха ниже, поскольку узлы цензуры уязвимы для Атаки типа «отказ в обслуживании»: злоумышленник может генерировать очень сложные транзакции, которые заканчиваются публикация доказательства неисправности осуществляется бесплатно, поскольку никакие сборы не взимаются. В крайних случаях длительный период спора позволяет скоординировать действия в случае успешного решения спора. цензурная атака для организации форка и исключения атакующих производителей блоков. Другой Возможная атака состоит в публикации большего количества предложений по созданию корней штата, чем могут проверить участники спора, чего можно избежать, используя ограничение частоты. 4.1.1. Быстрый оптимистичный вывод средств Поскольку достоверность оптимистического накопительного пакета может быть проверена в любое время любым полным узлом, доверенный oracle можно использовать, чтобы узнать на L1, можно ли безопасно завершить вывод средств. Это Механизм был впервые предложен Создателем [21]: oracle проверяет вывод средств, публикует результат на L1, по которому пользователю назначается процентный кредит, который автоматически закрывается по истечении 7 дней, т. е. когда вывод действительно может быть завершен. Это решение вводит предположение о доверии, но в случае Maker оно сведено к минимуму, поскольку оператор oracle управляется той же организацией, которая принимает на себя риск, предоставляя кредит. 4.2. Транзакционные издержки Стоимость транзакций L2 в основном определяется взаимодействием с L1. В обоих решениях Вычислительная стоимость транзакций очень низкая, поскольку они выполняются полностью вне сети. Optimism публикует данные вызовов транзакций L2 как данные вызовов и редко (или никогда) выполняет ошибку доказательства, поэтому данные вызова — самый дорогой ресурс. 12 января 2022 года сеть Bedrock был запущен в тестовой сети Goerli Ethereum. Можно рассчитать степень сжатия газа отслеживая количество газа, использованного на Bedrock за определенный период, и сравнивая его с количество газа, потраченного на L1 для соответствующих блоков. С помощью этого метода происходит сжатие газа. Обнаружена скорость ~20:1, но эта цифра может отличаться в зависимости от реальной активности в основной сети. StarkNet публикует на Ethereum каждое изменение состояния L2 в виде данных вызова, поэтому хранилище самый дорогой ресурс. Поскольку сеть не использует EVM, стоимость транзакции сжатие не может быть тривиально оценено. Предполагая, что стоимость выполнения и данные вызова равны быть незначительным, можно вычислить степень сжатия записи в хранилище по сравнению с Л1. Предполагая, что контракт не развернут и 10 ячеек, к которым ранее не осуществлялся доступ на StarkNet, после модификации получена степень сжатия стоимости записи в хранилище ~24:1. Если ячейка перезаписана 𝑛раз между публикациями данных стоимость каждой записи будет равна 1/𝑛по сравнению со стоимостью одной записи, поскольку публикуется только последняя запись. Затраты можно дополнительно минимизировать за счетсжатие часто используемых значений. Стоимость проверки подтверждения действительности делится между транзакции, к которым он относится: например, блок StarkNet 4779 содержит 200 транзакций и его Доказательство действительности потребляет 267830 единиц газа или 1339,15 газа на каждую транзакцию. 4.2.1. Оптимизация данных вызова: контракт кэша Ниже представлен smart contract, который реализует кэш адресов для часто используемых адреса, воспользовавшись тем фактом, что хранение и выполнение обходятся гораздо дешевле. ресурсы вместе с контрактом друзей, который демонстрирует их использование. Последний отслеживает «друзья» адреса, которые можно зарегистрировать, вызвав функцию addFriend. Если адрес уже использовался хотя бы один раз, его можно добавить, вызвав метод addFriendWithCache. функция: индексы кэша представляют собой 4-байтовые целые числа, а адреса представлены 20 байтами, поэтому экономия аргумента функции составляет 5:1. Ту же логику можно использовать и для других данных. такие типы, как целые числа или, в более общем случае, байты. контракт AddressCache { отображение (адрес => uint32) общедоступный адрес2ключ; адрес[] открытый ключ2адрес; функция cacheWrite(address _address) внутренний возврат (uint32) { require(key2address.length < type(uint32).max, "AddressCache: кеш заполнен"); require(address2key[_address] == 0, «AddressCache: адрес уже кэширован»); // ключи должны начинаться с 1, потому что 0 означает «не найдено» ключ uint32 = uint32(key2address.length + 1); адрес2ключ[_адрес] = ключ; key2address.push(_адрес); возвратный ключ; } function cacheRead(uint32 _key) возвращает публичное представление (адрес) { require(_key <= key2address.length && _key > 0, «AddressCache: ключ не найден»); вернуть адрес key2[_key - 1]; } } Листинг 2. Контракт кэша адресов. контракт Друзья — это AddressCache { сопоставление (адрес => адрес []) общедоступных друзей; функция addFriend(адрес _friend) public { друзья[msg.sender].push(_friend); кэшWrite (_друг); } функция addFriendWithCache(uint32 _friendKey) public { друзья[msg.sender].push(cacheRead(_friendKey)); } функция getFriends() возвращает публичное представление (адрес [] памяти) { вернуть друзей[msg.sender];} } Листинг 3. Пример контракта, который наследует кэш адресов. Контракт поддерживает в кеше около 4 миллиардов (232) адресов, а добавление одного байта дает около 1 триллиона (240). 4.2.2. Оптимизация хранения: фильтры Блума На StarkNet есть несколько способов минимизировать использование памяти. Если нет необходимости гарантировать доступность исходных данных, тогда достаточно сохранить в цепочке их hash: это это механизм, используемый для сохранения данных для ERC-721 (NFT) [22], т. е. канала IPFS, который разрешает hash данных, если они доступны. Для данных, которые сохраняются несколько раз, можно использовать поиск. таблица, аналогичная системе кэширования, представленной для Optimism, требующая сохранения всех значений по адресу хотя бы один раз. В некоторых приложениях сохранения всех значений можно избежать, используя фильтр Блума. [23, 24, 25], т.е. вероятностная структура данных, позволяющая с уверенностью знать, элемент не принадлежит множеству, но допускает небольшую, но не пренебрегаемую вероятность ложного результата. позитивы. Фильтр Блума инициализируется как массив 𝑚битов с нулевым значением. Чтобы добавить элемент, используйте функцию 𝑘hash. с равномерным случайным распределением, каждый из которых соответствует биту установленного массива до 1. Чтобы проверить, принадлежит ли элемент множеству, мы запускаем функции 𝑘hash и проверяем что биты 𝑘 установлены в 1. В простом фильтре Блума нет способа отличить элемент на самом деле принадлежит множеству или является ложноположительным, вероятность, которая растет с увеличением числа записей увеличивается. После вставки 𝑛elements: P[ложное срабатывание] = (︃ 1 — [︂ 1-1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 предполагая независимость вероятности каждого набора битов. Если 𝑛элементы (произвольного размера!) ожидается, что он будет включен, и вероятность ложного положительного результата равна 𝑝, размер массива можно рассчитать как: 𝑚= −𝑛ln 𝑝 (пер. 2)2 А оптимальное количество функций hash составляет: 𝑘= 𝑚 𝑛ln 2 Если предположить вставку 1000 элементов с допуском 1%, размер массива составит 9585 бит. с 𝑘= 6, а при допуске 0,1% оно становится 14377 бит с 𝑘= 9. Если миллион элементов будут вставлены, размер массива составит около 1170 КБ для 1% и 1775 КБ для 0,1%, с теми же значениями 𝑘, поскольку это зависит только от 𝑝[26]. В игре, где игроки не должны быть назначены противнику, которому они уже бросили вызов, вместо сохранения в хранилище для каждого игрока списка прошлых противников можно использовать Bloom фильтр. Риск не бросить вызов некоторым игрокам часто приемлем, и фильтр можно сбросить. периодически.4.3. Ethereum совместимость Основным преимуществом совместимости с EVM и Ethereum является повторное использование всех доступных инструменты. Ethereum smart contract могут быть опубликованы на Optimism без каких-либо изменений или новые проверки. Кошельки остаются совместимыми, инструменты разработки и статического анализа, общий анализ инструменты, инструменты индексирования и oracles. Ethereum и Solidity имеют долгую историю хорошо изученных уязвимости, такие как повторные атаки, переполнение и недостаточное переполнение, быстрые кредиты и oracle манипуляции. Благодаря этому Optimism смог за короткое время получить большую сумму денег. время. Выбор использования другой виртуальной машины подразумевает необходимость перестройки всей экосистемы. с преимуществом большей свободы реализации. StarkNet изначально реализует учетную запись абстракция, представляющая собой механизм, посредством которого каждая учетная запись представляет собой smart contract, который может реализовать произвольная логика, если она соответствует интерфейсу (отсюда и термин абстракция): это позволяет использование различных схем ЭЦП, возможность изменения закрытого ключа с помощью тот же адрес или используйте мультиподпись. Сообщество Ethereum предложило ввести это механизм с EIP-2938 в 2020 году, но предложение оставалось неактуальным уже более года, поскольку другим обновлениям присвоен больший приоритет [27]. Еще одним важным преимуществом совместимости является повторное использование существующих клиентов: Optimism. использует версию geth для своего собственного узла с разницей всего в ~800 строк, что было разрабатывается, тестируется и поддерживается с 2014 года. Наличие надежного клиента имеет решающее значение, поскольку оно определяет что считается действительным или нет в сети. Ошибка в реализации доказательства неисправности система может привести к тому, что неправильное доказательство будет принято за правильное, а правильное доказательство будет принято за недействительное. блок будет принят как неправильный, ставящий под угрозу систему. Вероятность такого типа Атака может быть ограничена за счет более широкого разнообразия клиентов: Optimism можно повторно использовать в дополнение к получению другие клиенты Ethereum уже поддерживаются, а разработка еще одного клиента на базе Erigon уже идет. В 2016 году проблема с управлением памятью geth была использована для DoS-атака и первая линия защиты заключались в том, чтобы рекомендовать использование четности, второй по значимости используемый клиент на тот момент 5. StarkNet сталкивается с той же проблемой с доказательствами достоверности, но клиенты приходится писать с нуля, а система доказательства гораздо сложнее, и, следовательно, также гораздо сложнее обеспечить правильность.

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.

Заключение

Заключение Накопительные пакеты — наиболее многообещающее решение, доступное сегодня для решения проблемы масштабируемости в децентрализованные blockchain, прокладывающие путь к эпохе модульных blockchain в отличие от монолитный blockchainс. В основном показан выбор между разработкой оптимистического сводного отчета или сводного отчета по достоверности. как компромисс между сложностью и гибкостью. StarkNet имеет множество преимуществ, таких как быстрая вывод средств, структурная неспособность иметь недействительные переходы между состояниями, более низкие транзакционные издержки на за счет более длительного периода разработки и несовместимости с EVM, тогда как Optimism имеет использовали сетевую экономику, чтобы быстро завоевать значительную долю рынка. Однако Optimism Bedrock имеет модульную конструкцию, которая позволяет ему стать действительным. 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Обновление в будущем: Cannon в настоящее время использует minigeth, скомпилированный в MIPS, для защиты от ошибок. система, но ту же самую архитектуру можно использовать для получения схемы и доказательства достоверности. Компиляция сложной машины, такой как EVM, для микроархитектуры приводит к более простому результату. схема, которую не нужно дорабатывать и перепроверять в случае модернизации. RISC Zero — это проверяемая микроархитектура с уже разрабатываемыми доказательствами STARK на основе RISC-V, которая может использоваться для этой цели как альтернатива MIPS [28]. Одним из аспектов, который не следует недооценивать, является сложность понимания того, как технология работает. Сильная сторона традиционных blockchain заключается в возможности проверять состояние blockchain, не доверяя какой-либо третьей стороне. Однако в случае StarkNet это необходимо доверять реализации, когда нет возможности проверить различные компоненты основанный на криптографии и высшей математике. Первоначально это может создать трения для внедрение технологии, но по мере развития инструментов и использования доказательств целостности даже за пределами поля blockchain эта проблема, надеюсь, будет решена.

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.