Optimism Teknik Dokümantasyonu

Автор Optimism Collective · 2021

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

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

🇹🇷 Türkçe (Перевод)

Аннотация

В статье рассматривается проблема масштабируемости децентрализованных 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 определяет...

Özet

Makale, bir düğümü çalıştırmak için işlem verimi ile donanım gereksinimleri arasındaki dengeyi analiz ederek merkezi olmayan blockchain'lerdeki ölçeklenebilirlik sorununu ele alıyor. Toplamalar, yani zincir dışında yürütülen blokların zincir üzerinde doğrulanmasına yönelik teknolojiler, hata veya geçerlilik kanıtları şeklinde sunulur. İyimser Toplamaları ve Geçerlilik Toplamalarını para çekme süresi, işlem maliyetleri, optimizasyon teknikleri ve Ethereum ekosistemiyle uyumluluk açısından karşılaştırıyoruz. Analizimiz, Optimism Bedrock'un şu anda yaklaşık 20:1'lik bir gaz sıkıştırma oranına sahip olduğunu, StarkNet'nın ise yaklaşık 24:1'lik bir depolama yazma maliyeti sıkıştırma oranına ulaştığını ortaya koyuyor. Ayrıca, önbellek sözleşmelerinin ve Bloom filtrelerinin kullanımı gibi bu oranları daha da optimize etmeye yönelik teknikleri de tartışıyoruz. Sonuç olarak, sonuçlarımız İyimser ve Geçerlilik Toplamaları arasındaki seçimde karmaşıklık ve çeviklik arasındaki dengeyi vurgulamaktadır. Anahtar Kelimeler Blockchain, Ölçeklenebilirlik, Toplama 1. Giriş Blockchain teknolojisi, çeşitli endüstrilerde devrim yaratma potansiyeli nedeniyle büyük ilgi görmüştür. Bununla birlikte, çoğu blockchain ölçeklenebilirlik, merkezi olmayan yönetim ve güvenlik arasında, genellikle Ölçeklenebilirlik Üçlemi olarak adlandırılan bir ödünleşimle karşı karşıya olduğundan, ölçeklenebilirlik büyük bir zorluk olmaya devam etmektedir [1, 2]. Bir blockchain'nin verimini artırmak için basit bir çözüm, blok boyutunu artırmaktır. Ethereum bağlamında bu, bir bloğun tutabileceği maksimum gaz miktarının arttırılması anlamına gelir. Her tam düğümün her bloğun her işlemini doğrulaması gerektiğinden, verim arttıkça donanım gereksinimleri de artar ve bu da ağın daha merkezi hale getirilmesine yol açar. Bitcoin ve Ethereum gibi bazı blockchain'ler, mimari merkeziyetsizliğini en üst düzeye çıkarmak için tasarımlarını optimize ederken, Binance Smart Chain ve Solana gibi diğerleri mümkün olduğu kadar hızlı ve ucuz olacak şekilde tasarlanmıştır. Merkezi olmayan ağlar, ağa katılım için donanım gereksinimlerini azaltmak amacıyla blockchain verimini yapay olarak sınırlandırır. Yıllar geçtikçe Trilemma'ya devlet kanalları [3] ve Plazma [4, 5] gibi bir çözüm bulmak için girişimlerde bulunuldu. Bu çözümler, bazı etkinlikleri zincir dışına taşıma, smart contracts kullanarak zincir içi etkinlikleri zincir dışı etkinliklere bağlama ve DLT 2023: 5th Distributed Ledger Technology Workshop, 25-26 Mayıs 2023, Bologna, İtalya $ [email protected] (L. Donno) https://lucadonnoh.github.io/ doğrulama özelliklerine sahiptir. (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bu makalenin telif hakkı yazarlarına aittir. Creative Commons Lisansı Atıf 4.0 Uluslararası (CC BY 4.0) kapsamında izin verilen kullanıma. CEUR Çalıştay Bildirileri http://ceur-ws.org ISSN 1613-0073 CEUR Çalıştay Bildirileri (CEUR-WS.org) zincir üzerinde, zincir dışında olup bitenler. Ancak hem Plazma hem de durum kanallarının genel smart contracts desteği sınırlıdır. Toplamalar, bloklarını başka bir blockchain (Layer 1 veya L1) üzerinde yayınlayan ve dolayısıyla onun fikir birliğini, veri kullanılabilirliğini ve güvenlik özelliklerini devralan blockchain'lardır (Layer 2 veya L2 olarak adlandırılır). Diğer çözümlerden farklı olarak keyfi hesaplamayı desteklerler. Toplamaların üç ana bileşeni vardır: • Sıralayıcılar: kullanıcılardan Toplama işlemlerini alan ve bunları Layer 1 adresine gönderilen bir blokta birleştiren düğümler. Blok en azından durum kökünden (örneğin Merkle kökü) ve durumu yeniden yapılandırmak ve doğrulamak için gereken verilerden oluşur. Layer 1 şunu tanımlar...

Введение

Введение Технология блокчейн привлекла значительное внимание благодаря своему потенциалу совершить революцию. различные отрасли промышленности. Однако масштабируемость остается серьезной проблемой, поскольку большинство 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 мы рисуем некоторые выводы.

giriiş

Giriş Blockchain teknolojisi, devrim yaratma potansiyeli nedeniyle büyük ilgi gördü çeşitli endüstriler. Ancak çoğu blockchain'nin karşılaştığı gibi ölçeklenebilirlik büyük bir zorluk olmaya devam ediyor ölçeklenebilirlik, merkezi olmayan yönetim ve güvenlik arasında bir değiş-tokuş Ölçeklenebilirlik Üçlemi [1, 2]. blockchain verimini artırmak için önemsiz bir çözüm blok boyutunu artırmak için. Ethereum bağlamında bu, maksimum değerin artırılması anlamına gelir Bir bloğun tutabileceği gaz miktarı. Her tam düğümün her işlemin her işlemini doğrulaması gerektiğinden blok, verim arttıkça donanım gereksinimleri de artar ve bu da daha büyük bir ağın merkezileştirilmesi. Bitcoin ve Ethereum gibi bazı blockchain'ler, mimari merkezsizleşmeyi en üst düzeye çıkaracak şekilde tasarlarken, Binance Smart gibi diğerleri Chain ve Solana mümkün olduğu kadar hızlı ve ucuz olacak şekilde tasarlandı. Merkezi olmayan ağlar donanım gereksinimlerini azaltmak için blockchain verimini yapay olarak sınırlandırın ağa katılın. Yıllar boyunca Trilemma'ya devlet gibi bir çözüm bulmak için girişimlerde bulunuldu. [3] ve Plazma [4, 5] kanalları. Bu çözümler bazı aktiviteleri hareket ettirme özelliğine sahiptir. zincir dışı, smart contracts kullanarak zincir içi aktiviteyi zincir dışı aktiviteye bağlama ve doğrulama DLT 2023: 5. Dağıtılmış Defter Teknolojisi Çalıştayı, 25-26 Mayıs 2023, Bologna, İtalya $ [email protected] (L.Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L.Donno) © 2023 Bu makalenin telif hakkı yazarlarına aittir. Creative Commons Lisansı Atıf 4.0 Uluslararası (CC BY 4.0) kapsamında izin verilen kullanıma. CEUR Atölye Bildiriler http://ceur-ws.org ISSN1613-0073 CEUR Çalıştay Bildirileri (CEUR-WS.org)zincir üzerinde, zincir dışında neler olup bittiğini. Ancak hem Plazma hem de durum kanalları sınırlıdır. genel smart contracts'yi destekliyorlar. Toplamalar, bloklarını başka bir blockchain üzerinde yayınlayan blockchain'lerdir (Layer 2 veya L2 olarak adlandırılır) (Layer 1 veya L1) ve dolayısıyla fikir birliğini, veri kullanılabilirliğini ve güvenlik özelliklerini devralır. Onlar, diğer çözümlerden farklı olarak keyfi hesaplamayı destekler. Toplamaların üç ana bileşeni vardır: • Sıralayıcılar: kullanıcılardan Toplama işlemlerini alan ve bunları bir araya getiren düğümler Layer 1 adresine gönderilen blok. Blok en azından durum kökünden oluşur (örneğin bir Merkle kök) ve durumu yeniden oluşturmak ve doğrulamak için gereken veriler. Layer 1 şunu tanımlar: yayınlanan verilerin sırasını belirleyerek L2'nin kanonik blockchain. • Toplama tam düğümleri: Katmandan Toplama bloklarını alan, işleyen ve doğrulayan düğümler 1 kökün doğru olduğunu doğrulayarak. Bir blok geçersiz işlemler içeriyorsa o zaman atılır; bu, Sıralayıcıların geçersiz bloklar içeren geçerli bloklar oluşturmasını engeller işlemler. • Toplama hafif düğümleri: Toplama bloklarını Layer 1 adresinden alan ancak hesaplama yapmayan düğümler yeni devletin kendisi. Teknikleri kullanarak yeni durum kökünün geçerli olduğunu doğrularlar Arıza veya geçerlilik delilleri gibi. Toplamalar, işlem sayısı arttıkça amortize edilmiş maliyetleri azaltarak ölçeklenebilirlik elde eder. kullanıcı sayısı artıyor. Bunun nedeni, blockchain geçerliliğini sağlamanın maliyetinin alt doğrusal olarak artmasıdır İşlemlerin bireysel olarak doğrulanmasının maliyeti ile ilgili olarak. Toplamalar şunlara göre farklılık gösterir: Hafif düğümlerde işlem yürütmenin geçerliliğini sağladıkları mekanizma: İyimser Toplamalar, Ekonomik bir model ve hata kanıtları ile sağlanırken, Geçerlilik Toplamalar, geçerlilik kanıtları kullanılarak kriptografik olarak sağlanır. Hafif düğümler Layer 1 üzerinde smart contracts olarak uygulanabilir. Kökünü kabul ediyorlar yeni durum ve geçerliliği veya hata kanıtlarını doğrulayın: bu Toplama bu nedenle Akıllı Sözleşme olarak adlandırılır Toplamalar. Işık düğümleri bağımsızsa bunlara Egemen Toplamalar [6] denir. Avantajı Akıllı Sözleşme Toplamasını kullanmak, ikisi arasında güveni en aza indirilmiş bir köprü kurabilmektir blockchains: L2 durumunun geçerliliği L1'e kanıtlandığından, bir işlemler sistemi L2'den L1'e kadar para çekme işlemlerine izin vererek uygulanabilir. Dezavantajı ise maliyetinin yüksek olmasıdır. işlemler L1'deki durumu doğrulamanın maliyetine bağlıdır: temel katman şu şekilde doyurulursa: diğer faaliyetlerde, Toplamadaki işlemlerin maliyeti de artar. Veri ve fikir birliği katmanları sistemin güvenliğini belirleyen katmanlardır. işlemlerin sırasını tanımlar, saldırıları önler ve durumu kanıtlamak için verileri kullanılabilir hale getirir geçerlilik. Bildiri katkısı Bu yazıda, iki yenilikçi olan İyimserlik ve Geçerlilik Toplamalarını inceliyoruz. Optimism Bedrock ve StarkNet gibi dikkate değer uygulamalara odaklanarak Ölçeklenebilirlik Üçlemine yönelik çözümler. Katkılarımız bunların kapsamlı bir karşılaştırmasını içermektedir. çözümler, geri çekilme sürelerinin analizi ve Optimism adresine olası bir saldırı hakkında tartışma Ana kaya. Ayrıca gaz sıkıştırma oranlarını hesaplıyor, uygulamaya özel optimizasyonlar sağlıyor ve Ethereum'den uzaklaşmanın avantaj ve dezavantajlarını sunuyoruz. Sanal Makine (EVM).

Kağıt yapısı Makale şu şekilde düzenlenmiştir. Bölüm 2'de İyimser Toplamalar Optimism Ana Kaya analiz edilerek tanıtıldı. Bölüm 3'te Geçerlilik Toplamaları şu şekilde tanıtılmaktadır: StarkNet analiz ediliyor. Bölüm 4'te iki çözümü karşılaştırıyoruz. Son olarak 5. bölümde çizim yapıyoruz bazı sonuçlar.

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

Оптимистичные сводки Идея оптимистичного принятия вывода блоков без проверки их выполнения уже присутствует в официальном документе 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 и заменяет базу данных. Запросы выполняются к другим узлам для получить прообразы.

İyimser Toplamalar

İyimser Toplamalar Yürütülmelerini doğrulamadan blokların çıktılarını iyimser bir şekilde kabul etme fikri ışık düğümlerini tartışan Bitcoin teknik incelemesi [7]'de zaten mevcuttur. Bu düğümler yalnızca takip eder konsensüs kuralını doğrulayarak başlık zincirini blokları kabul etmeye karşı savunmasız hale getirir %51 saldırısı durumunda geçersiz işlemler içeren. Nakamoto bunu çözmeyi öneriyor Light node'ları bir bloğun geçersiz işlemler içerdiği konusunda uyarmak için bir "uyarı" sistemi kullanarak sorunu çözebilirsiniz. Bu mekanizma ilk olarak Al-Bassam, Sonnino ve Buterin [8] tarafından uygulandı. [9] hata düzeltme kodlarına dayalı kanıt sistemi kullanılır. Oluşturulmasını sağlamak için Hata kanıtlarının sağlanması için geçersiz bloklar da dahil olmak üzere tüm bloklardaki verilerin mevcut olması gerekir. ağ: bu, olasılıksal veriler kullanılarak çözülen Veri Kullanılabilirliği Sorunudur örnekleme mekanizması. İlk İyimser Toplama tasarımı John Adler tarafından sunuldu ve Mikerah Quintyne-Collins, 2019 [10]'de, bloklar başka bir blockchain'de yayınlanıyor bu onların sıralama konusundaki fikir birliğini tanımlar. 2.1. Optimism Ana kaya Bedrock [11], bir Akıllı Sözleşme Toplama olan Optimism'nin en son sürümüdür. Önceki versiyon, Optimistic Virtual Machine (OVM), Solidity'yi kendi içinde derlemek için geçici bir derleyiciye ihtiyaç duyuyordu. kendi bayt kodu: aksine, Bedrock yürütme motoru açısından EVM ile tamamen eşdeğerdir Ethereum Sarı Kağıt spesifikasyonuna [12] uygundur. 2.1.1. Mevduat Kullanıcılar, Ethereum Portalı üzerindeki bir sözleşme aracılığıyla, mevduatTransaction işlevini çağırarak para yatırabilirler. Bir işlem yürütüldüğünde, bir Toplamadaki her düğümün işlemek için dinlediği TransactionDeposited olayı yayılır Mevduat. Yatırılan işlem, L1'den türetilen bir L2 işlemidir. Eğer arayan kişi işlev bir sözleşmedir, adres ona sabit bir değer eklenerek dönüştürülür: bu, L1'deki bir sözleşmenin L2'deki sözleşmeyle aynı adrese ancak farklı koda sahip olduğu saldırılar. Yatırılan bir işlemin L2'ye dahil edilmesi, bir sıralama içindeki spesifikasyonla sağlanır. pencere. Yatırılan işlemler, 0x7E ön ekine sahip yeni bir EIP-2718 uyumlu işlem türü [13]'dir, rlp kodlu alanlar burada: • bytes32 sourceHash: hash, işlemin kaynağını benzersiz şekilde tanımlar. • gelen adres: gönderenin adresi. • adres: alıcının adresi veya yatırılan işlem bir alıcı adresi ise sıfır adres sözleşme oluşturma.• uint256 mint: L2'de oluşturulacak değer. • uint256 değeri: alıcıya gönderilecek değer. • bayt verileri: giriş verileri. • bayt gasLimit: işlemin gas limiti. SourceHash, L1 bloğunun hash keccak256 hash ve L1 günlüğü olarak hesaplanır. Bir bloktaki bir olayı benzersiz şekilde tanımlayan indeks. Yatırılan işlemler L1'de başlatılıp L2'de yürütüldüğünden, sistemin bir L2'de harcanan gaz için L1'e ödeme yapma mekanizması. Çözümlerden biri ETH'yi Portal aracılığıyla göndermektir. ancak bu, her arayanın (dolaylı arayanlar bile) ödenecek olarak işaretlenmesi gerektiği anlamına gelir ve bu mevcut birçok proje için mümkün değildir. Alternatif, karşılık gelen gazı L1'de yakmaktır. Yatırılan işleme tahsis edilen gaza garantili gaz denir. L2 gaz fiyatı L1 otomatik olarak senkronize edilmez ancak EIP-1559'a benzer bir mekanizma kullanılarak tahmin edilir [14]. Ethereum blok başına garanti edilen maksimum gaz miktarı 8 milyondur ve hedef 2 milyon. L2'de gaz için ödeme yapmak için gereken ETH miktarı 𝑐= 𝑔𝑏L2'dir; burada 𝑏L2, L2'de taban ücreti. L1'deki kontrat 𝑐/𝑏L2'ye eşit miktarda gaz yakar. Aramak için harcanan gaz mevduatİşlemi L2'de geri ödenir: eğer bu miktar garanti edilen gazdan fazlaysa, gaz yakılmaz. Bir rollup bloğunun ilk işlemi, kaydolmak için kullanılan, L1 özniteliklerinde yatırılan bir işlemdir L2'de Ethereum bloklarının niteliklerini önceden konuşlandırın. Ön dağıtımın sağladığı özellikler erişim blok numarası, zaman damgası, taban ücreti, hash bloğu ve dizidir ilgili L1 bloğuna (aynı zamanda dönem olarak da adlandırılır) göre L2'nin blok numarası olan sayı; yeni bir dönem başladığında bu sayı sıfırlanır. 2.1.2. Sıralama Toplama düğümleri Optimism zincirini tamamen Ethereum'den türetir. Bu zincir uzatılır L1'de her yeni işlem yayınlandığında ve blokları her seferinde yeniden düzenlenir Ethereum bloklar yeniden düzenlendi. Toplama blockchain dönemlere bölünmüştür. Her biri için Ethereum blok numarasına karşılık gelen bir 𝑛epoch var. Her çağ en az bir tane içerir bloktur ve bir çağdaki her blok, L1 özniteliklerinde yatırılan işlemi içerir. İlk blok bir dönemde Portal aracılığıyla yatırılan tüm işlemleri içerir. Layer 2 bloklar da olabilir sıralı işlemleri, yani doğrudan Sıralayıcıya gönderilen işlemleri içeriyordu. Sıralayıcı, kullanıcılardan gelen işlemleri kabul eder ve bloklar oluşturur. Her blok için oluşturur Ethereum tarihinde yayınlanacak bir grup. Birkaç parti sıkıştırılmış bir şekilde yayınlanabilir, kanal adını alıyor. Çok büyük olması durumunda bir kanal birkaç kareye bölünebilir. tek bir işlem. Kanal, rlp kodlu ZLIB [15] ile sıkıştırma olarak tanımlanır gruplar. Bir grubun alanları dönem numarası, dönem hash, üst öğe hash, zaman damgası ve işlem listesi. Bir dönem tarafından tanımlanan bir sıralama penceresi, ardışık L1'in sabit bir 𝑤 sayısını içerir Değişken sayıda L2 bloğu oluşturmak için bir türetme adımının girdi olarak aldığı bloklar. için çağ 𝑛, sıralama penceresi 𝑛 blokları içerir [𝑛, 𝑛+𝑤). Bu, siparişin verildiği anlamına gelir Bir sıralama penceresi içindeki L2 işlemlerinin ve bloklarının sayısı, pencere bitene kadar sabitlenmez. Bir rollup işlemi, onu içeren parti L1'de onaylandıysa güvenli olarak adlandırılır. ÇerçevelerGrupları yeniden oluşturmak için L1 bloklarından okunur. Mevcut uygulama buna izin vermiyor karşılık gelen tüm çerçeveler alınana kadar kanalın sıkıştırmasını açma işlemi başlatılır. Geçersiz gruplar göz ardı edilir. Partilerden bireysel blok işlemleri elde edilir. yürütme motoru tarafından durum geçişlerini uygulamak ve Toplama durumunu elde etmek için kullanılır. 2.1.3. Para Çekme Para çekme işlemlerini gerçekleştirmek için L2'den L1'e bir mesajlaşma sistemi uygulanır. Ethereum Para çekme işlemlerini kabul etmek için L2'nin durumunu bilmesi gerekir ve bu, yayınlanarak yapılır L2 Çıkışında Oracle smart contract L1'de her L2 bloğunun durum kökü. Bu kökler sırasında herhangi bir arıza tespiti yapılmazsa iyimser bir şekilde geçerli (veya kesinleşmiş) olarak kabul edilir. anlaşmazlık dönemi. Yalnızca Teklif Veren olarak belirlenen adresler çıktı köklerini yayınlayabilir. Geçerlilik Çıktı köklerinin oranı, Teklif Sahiplerinin, eğer yatırılırlarsa kesilecek bir hisse yatırmaları sağlanarak teşvik edilir. geçersiz bir kök önerdiği gösterilmiştir. İşlemler, işlev çağrılarak başlatılır L2'de bir ön konuşlandırmada Withdrawal'ı başlatın ve ardından işlevi çağırarak L1'de sonlandırın Daha önce bahsedilen Optimism Portalında finalizeWithdrawalTransaction. L2 bloğuna karşılık gelen çıkış kökü, L2 Çıkış Oracle'ından elde edilir; öyle kesinleştiğinin, yani anlaşmazlık süresinin geçtiğinin doğrulanması; Çıkışın doğrulandığı doğrulandı Kök Kanıtı, Oracle Kanıtı ile eşleşir; Para çekme işleminin hash numarasının dahil edildiği doğrulandı bir Para Çekme Kanıtı kullanarak; geri çekilmenin henüz tamamlanmadığını; ve sonra Belirlenen gas limiti, Ether miktarı ve verilerle hedef adrese çağrı gerçekleştirilir. 2.1.4. Cannon: hatasız sistem Bir Toplama Tam Düğümü, toplu işlemleri ve yatırılan işlemleri yerel olarak yürüterek şunları keşfederse: Layer 2 durumu, Teklif Sahibi tarafından zincir üzerinde yayınlanan durum köküyle eşleşmiyor, yürütülebilir Blok geçişi sonucunun yanlış olduğunu kanıtlamak için L1'de bir arıza kanıtı. Çünkü ek yük, L1'de bir Toplama bloğunun tamamını işlemek çok pahalıdır. Uygulanan çözüm Bedrock tarafından zincir üzerinde minigeth anlaşmazlığının yalnızca ilk talimatını yürütmek, bunu zincir üstü bir yorumlayıcıda yürütülen ve yayınlanan bir MIPS mimarisine derlemek L1'de. minigeth, geth 1'in basitleştirilmiş bir versiyonudur; burada fikir birliği, RPC ve veritabanı bulunur. kaldırıldı. Anlaşmazlığın ilk talimatını bulmak için etkileşimli bir ikili arama gerçekleştirilir. Arıza kanıtını başlatan ve çıkış kökünü yayınlayan kişi. Kanıt ne zaman başladığında, her iki taraf da MIPS bellek durumunun kökünü yürütme işleminin yarısında yayınlar. Challenge sözleşmesindeki blok: hash eşleşirse bu, her iki tarafın da bu konuda anlaştığı anlamına gelir Uygulamanın ilk yarısı böylece ikinci yarının yarısının kökünü yayınlar, aksi takdirde yarısı ilk yarının yayınlanması vb. Bunu yapmak, ilk anlaşmazlık talimatını yerine getirir orijinal yürütmeye kıyasla logaritmik sayıda adımla. Eğer iki duraktan biri etkileşimli olarak, anlaşmazlık süresinin sonunda diğer katılımcı otomatik olarak kazanır. Talimatı işlemek için MIPS yorumlayıcısının belleğine erişmesi gerekir: kök olduğundan mevcut olması durumunda gerekli hafıza hücrelerinin dahil olduğu kanıtlanarak yayınlanabilecektir. Erişmek için EVM durumu, Preimage Oracle'dan yararlanılır: döndürdüğü bloğun hash değeri verildiğinde 1https://geth.ethereum.org/docs

önceki bloğun hash numarasını alıp geri dönebileceğiniz blok başlığı zincirini kullanın veya ön görüntünün alınabileceği durumun ve günlüklerin hash değerini alın. oracle minigeth tarafından uygulanır ve veritabanının yerini alır. Diğer düğümlere sorgular yapılır ön görüntüleri elde edin.

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

Сводные данные о сроках действия Целью валидного накопительного пакета является криптографическое доказательство достоверности перехода состояний. учитывая последовательность транзакций с коротким доказательством, которое можно проверить сублинейным сравнением ко времени первоначальных вычислений. Сертификаты такого типа называются доказательствами вычислительной целостности и практически реализуются с помощью 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).

Geçerlilik Toplamaları

Geçerlilik Toplamaları Geçerlilik Toplamasının amacı, durum geçişinin geçerliliğini kriptografik olarak kanıtlamaktır. alt doğrusal olarak karşılaştırılarak doğrulanabilen kısa bir kanıtla işlem sırası verildiğinde orijinal hesaplamaların yapıldığı zamana kadar. Bu tür sertifikalara hesaplama bütünlüğü kanıtları denir ve pratik olarak aritmetik kullanan SNARK'lar (Succint Non-interactive Argument of Knowledge) ile uygulanır. hesaplamalı modeli olarak devreler. Farklı SNARK uygulamaları kanıtlama süresi açısından farklılık gösterir, doğrulama süresi, güvenilir bir kurulum ihtiyacı ve kuantum direnci [16, 17]. STARK'lar (Ölçeklenebilir Şeffaf Bilgi Argümanı) [18], güvenilir bir ağ gerektirmeyen bir SNARK türüdür. kanıtlama ve doğrulamada verimlilikten biraz ödün verirken kuantum dirençlidir diğer çözümlerle karşılaştırıldığında. 3.1. StarkNet StarkNet, StarkWare tarafından geliştirilen ve STARK kullanan bir Akıllı Sözleşme Geçerlilik Toplamasıdır durumunu Ethereum olarak doğrulamak için kanıt sistemi. Geçerlilik kanıtlarının oluşturulmasını kolaylaştırmak için, Üst düzey dili Kahire olan EVM'den farklı bir sanal makine kullanılıyor. 3.1.1. Mevduat Kullanıcılar, sendMessageToL2'yi arayarak Ethereum adresindeki bir sözleşme aracılığıyla işlem yatırabilirler. işlev. Mesaj, hash değeri hesaplanarak ve bir sayaç artırılarak kaydedilir. Sıralayıcılar LogMessageToL2 olayını dinleyin ve bilgileri bir StarkNet işleminde kodlayın bu, l1_handler dekoratörüne sahip bir sözleşmenin işlevini çağırır. İcranın sonunda, Durum geçişinin kanıtı üretildiğinde, mesajın tüketimi buna eklenir ve sayacı azaltılarak silinir. Yatırılan işlemlerin dahil edilmesi StarkNet spesifikasyonu tarafından gerekli değildir, dolayısıyla bir gaz Sıralayıcıları L2'de yayınlamaya teşvik etmek için pazara ihtiyaç var. Mevcut sürümde, çünkü Sıralayıcı, yatırılan işlemlerin maliyeti olan StarkWare tarafından merkezileştirilir ve yönetilir yalnızca depozito işleminin maliyetine göre belirlenir. Bu maliyet ETH gönderilerek ödenir. sendMessageToL2. Bu Eterler L1'de kilitli kalır ve Sıralayıcıya aktarılır. L1, yatırılan işlem bir durum geçişine dahil edildiğinde. Gönderilen ETH miktarı yatırılan işlem dahildir, tüketilen gaz miktarına bakılmaksızın tamamen harcanır L2'de. StarkNet, L1 blok niteliklerinin otomatik olarak kullanılabilir olmasını sağlayan bir sisteme sahip değildir. Alternatif olarak Fossil, Oiler Network 2 tarafından geliştirilen ve hash verildiğinde izin veren bir protokoldür. blok, ön görüntülerin yayınlanmasıyla Ethereum adresinden elde edilecek her türlü bilgi. 2https://www.oiler.network/3.1.2. Sıralama StarkNet'nin mevcut durumu tamamen Ethereum'den türetilebilir. Herhangi bir durum farkı geçişler arasındaki veriler L1'de çağrı verileri olarak yayınlanır. Farklılıklar her sözleşme için yayınlanır ve aşağıdaki kodlamayla uint256[] olarak kaydedilir: • Sözleşme dağıtımlarıyla ilgili alan sayısı. • Yayınlanan her sözleşme için: – Yayınlanan sözleşmenin adresi. – Yayınlanan sözleşmenin hash numarası. – Sözleşmeyi yapanın argümanlarının sayısı. – Yapıcı argümanlarının listesi • Deposu değiştirilen sözleşme sayısı. • Değiştirilen her sözleşme için: – Değiştirilen sözleşmenin adresi. – Depolama güncellemelerinin sayısı. – Yeni değerlere sahip depolama adreslerinin anahtar/değer çiftleri. Durum farklılıkları sırasıyla yayınlandığı için sırasıyla okunması yeterlidir. devleti yeniden inşa edelim. 3.1.3. Para Çekme L2'den L1'e mesaj göndermek için send_message_to_L1 sistem çağrısı kullanılır. Mesaj şu: hash sayacını kanıtla birlikte artırarak L1'de yayınlandı ve çağrılarak sonlandırıldı. L1'deki StarkGate smart contract üzerindeki consumMessageFromL2 işlevi, bu işlevi azaltır sayaç. Herkes para çekme işlemini tamamlayabilir. 3.1.4. Geçerlilik kanıtları Kahire Sanal Makinesi [19], STARK kanıtlarının oluşturulmasını kolaylaştırmak için tasarlanmıştır. Kahire dili, hesaplamanın üst düzey bir programlamayla tanımlanmasına olanak tanır dil ve doğrudan bir devre olarak değil. Bu, bir polinom denklem sistemi ile gerçekleştirilir. Şekil 3 tek bir hesaplamayı temsil etmektedir: von Neumann mimarisinin FDE döngüsü. Sayı Kısıtlamaların sayısı bu nedenle sabittir ve hesaplama türünden bağımsızdır ve yalnızca bir tanesine izin verir. Hesaplanmasının kanıtlanması gereken her program için doğrulama programı. StarkNet, paylaşılan bir kanıtlayıcı kullanarak birden fazla işlemi tek bir STARK kanıtı halinde toplar SHARP'ın adı. Kanıtlar, geçerliliklerini doğrulayan Ethereum tarihinde smart contract adresine gönderilir. ve yeni duruma karşılık gelen Merkle kökünü günceller. Bir doğrulamanın alt doğrusal maliyeti Geçerlilik kanıtı, maliyetinin birden fazla işlem üzerinden amortismana tabi tutulmasına olanak tanır. 3Cebirsel Ara Gösterim (AIR) olarak adlandırılır

Сравнение

Сравнение 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 сталкивается с той же проблемой с доказательствами достоверности, но клиенты приходится писать с нуля, а система доказательства гораздо сложнее, и, следовательно, также гораздо сложнее обеспечить правильность.

Karşılaştırmak

Karşılaştırma 4.1. Para çekme süresi İyimser Toplamaları Geçerlilik Toplamalarından ayıran en önemli husus, Caymanın başlatılması ile sonuçlanması arasında geçen süre. Her iki durumda da Para çekme işlemleri L2'de başlatılır ve L1'de sonlandırılır. StarkNet tarihinde sonlandırma şu şekilde mümkündür: Yeni durum kökünün geçerlilik kanıtı Ethereum tarihinde kabul edilir edilmez: teorik olarak Başlatmanın ardından L1'in ilk bloğundaki fonları çekmek mümkündür. Uygulamada, Ethereum üzerinde geçerlilik kanıtları gönderme sıklığı, blok hızı arasında bir dengedir sonuçlandırma ve kanıt toplama. Şu anda StarkNet doğrulama için geçerlilik kanıtları sağlıyor her 10 saatte bir 4, ancak işlem aktivitesi arttıkça azaltılması amaçlanıyor. Optimism Bedrock'ta para çekme işlemini yalnızca anlaşmazlığın sonunda sonuçlandırmak mümkündür süre (şu anda 7 gün), bu sürenin sonunda kök otomatik olarak geçerli kabul edilir. uzunluğu bu süre temel olarak hata kanıtlarının Ethereum tarihine kadar sansürlenebileceği gerçeğiyle belirlenir. onun sonu. Bu tür saldırıların başarı olasılığı zaman arttıkça katlanarak azalır: E[çıkarılan değer] = 𝑉𝑝𝑛 burada 𝑛bir aralıktaki blok sayısıdır, 𝑉çıkarılabilecek fon miktarıdır geçersiz bir kök yayınlayarak ve 𝑝 başarılı bir sansür gerçekleştirme olasılığıdır tek blokta saldırın. Bu olasılığın %99 olduğunu, değerin Toplama'da kilitlendiğini varsayalım. bir milyon Ether'dir ve bir aralıktaki bloklar 1800'dür (12 saatlik bloklar ile 6 saatlik bloklar). saniye aralığı): beklenen değer yaklaşık 0,01391 Ether'dir. Sistem şu şekilde güvenli hale getirilmiştir: Teklif Sahiplerinden beklenen değerden çok daha büyük miktarda Ether yatırmalarını istemek. Winzer ve ark. basit bir smart contract kullanarak sansür saldırısının nasıl gerçekleştirileceğini gösterdi bu, durumdaki belirli bellek alanlarının [20] değişmemesini sağlar. Saldırının modellenmesi Bir Markov oyunu olarak makale, sansürün rasyonel bir yaklaşım için baskın strateji olduğunu göstermektedir. değişen işlemin dahil edilmesinden daha fazla tazminat alırlarsa üreticiyi bloke edin hafıza. Yukarıda tartışılan 𝑝değeri rasyonel bloğun yüzdesi olarak görülebilir. ağdaki üreticiler, “rasyonel”in muhtemelen cezalandırmayı hesaba katmadığı durumlarda blockchain'ye olan güvenin azalması gibi dışsallıklar, onun kripto para birimi değerini düşürür. Aşağıdaki kod, sansür saldırısı gerçekleştirmek için kullanılabilecek bir smart contract değerini sunar Bedrock'ta. Saldırı, blok üreticilerine rüşvet teklif ederek teşviklerinden yararlanıyor devletin belirli kısımlarını değiştirecek işlemleri sansürlemek. Sözleşmenin ana ClaimBribe işlevi, blok üreticilerinin başarılı bir şekilde sansürlemeleri halinde rüşveti talep etmelerine olanak tanır Geçersiz çıkış köküne dokunulmadığını kontrol ederek hedeflenen işlemi gerçekleştirin. function requestBribe(bayt bellek depolamaProof) harici { require(!talep edilen[blok.numarası], "rüşvet zaten talep edildi"); OutputProposal bellek akımı = depolamaOracle.getStorage(L2_ORACLE, blok.number, SLOT, depolama Kanıtı); require(invalidOutputRoot == current.outputRoot, "saldırı başarısız oldu"); talep edilen[blok.numarası] = doğru; (bool gönderildi, ) = Block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(gönderildi, "ether gönderilemedi"); } Liste 1: Bedrock'a sansür saldırısını teşvik eden bir sözleşme örneği. Uyuşmazlık süresinin uzunluğu aynı zamanda kusurun kanıtlandığı gerçeğini de dikkate almalıdır. etkileşimli bir kanıttır ve bu nedenle katılımcıların etkileşime girmesi için yeterli zaman sağlanmalıdır ve herhangi bir etkileşimin sansürlenebileceğini. Son hamle çok yakın bir zamanda gerçekleşirse Uyuşmazlık döneminin sonunda sansürün maliyeti önemli ölçüde azalır. Her ne kadar sansür baskın strateji, sansür düğümlerinin saldırıya açık olması nedeniyle başarı olasılığı daha düşüktür Hizmet Reddi saldırıları: Bir saldırgan, aşağıdakilerle biten çok karmaşık işlemler oluşturabilir: Hiçbir ücret ödenmeyeceği için arıza kanıtının ücretsiz olarak yayınlanması. Olağanüstü durumlarda, uzun bir anlaşmazlık süresi, başarılı bir anlaşma durumunda koordinasyona olanak sağlar. Bir çatal düzenlemek ve saldıran blok üreticilerini dışlamak için sansür saldırısı. Başka bir Olası saldırı, ihtilaflı tarafların doğrulayabileceğinden daha fazla durum kök teklifinin yayınlanmasından ibarettir, bir frekans limiti kullanılarak bunun önüne geçilebilir. 4.1.1. Hızlı iyimser para çekme işlemleri İyimser Toplamanın geçerliliği herhangi bir zamanda herhangi bir Tam Düğüm tarafından doğrulanabileceğinden, güvenilir oracle, L1'de para çekme işleminin güvenli bir şekilde tamamlanıp tamamlanmayacağını bilmek için kullanılabilir. Bu mekanizma ilk olarak Maker [21] tarafından önerildi: bir oracle para çekme işlemini doğrular, kullanıcıya otomatik olarak faiz getiren bir kredinin atandığı L1'deki sonuç 7 günün sonunda, yani para çekme işleminin fiilen sonuçlandırılabileceği tarihte kapatılır. Bu çözüm bir güven varsayımı getirir, ancak Maker durumunda bu, oracle operatöründen bu yana en aza indirilmiştir. krediyi sağlayarak riski üstlenen aynı kuruluş tarafından yönetilmektedir. 4.2. İşlem maliyetleri L2 işlemlerinin maliyeti çoğunlukla L1 ile olan etkileşime göre belirlenir. Her iki çözümde İşlemlerin hesaplama maliyeti, tamamen zincir dışında yürütüldüğü için çok ucuz. Optimism L2 işlemleri çağrı verilerini çağrı verileri olarak yayınlar ve nadiren (veya hiçbir zaman) hata yürütmez kanıtlar, bu nedenle çağrı verileri en pahalı kaynaktır. 12 Ocak 2022'de bir Bedrock ağı Ethereum'nin Goerli test ağında başlatıldı. Bir gaz sıkıştırma oranı hesaplanabilir Belli bir periyotta Ana Kaya üzerinde kullanılan gaz miktarını takip ederek ve bunu mevcut gaz miktarı ile karşılaştırarak karşılık gelen bloklar için L1'de harcanan gaz miktarı. Bu yöntemi kullanarak gaz sıkıştırma ∼20 : 1 oranı bulunur, ancak bu rakam ana ağdaki gerçek aktiviteye göre farklılık gösterebilir. StarkNet, L2 durumundaki her değişikliği Ethereum tarihinde çağrı verileri olarak yayınlar, bu nedenle depolama en pahalı kaynak. Ağ EVM kullanmadığından işlem maliyeti sıkıştırma önemsiz bir şekilde tahmin edilemez. Yürütme maliyetini ve çağrı verilerini varsayarak ihmal edilebilir düzeydeyse, depolama yazma işlemlerinin sıkıştırma oranını aşağıdakilerle karşılaştırmalı olarak hesaplamak mümkündür: L1. Hiçbir sözleşmenin dağıtılmadığını ve StarkNet üzerinde daha önce erişilmeyen 10 hücrenin değiştirildiğinde, ∼24 : 1'lik bir depolama yazma maliyeti sıkıştırma oranı bulunur. Bir hücrenin üzerine yazılırsa 𝑛veri yayınları arasında her yazmanın maliyeti, maliyete kıyasla 1/𝑛 olacaktır Yalnızca sonuncusu yayınlandığından tek bir yazma işlemi yapılır. Maliyet daha da azaltılabilirSık kullanılan değerlerin sıkıştırılması. Geçerlilik kanıt doğrulamasının maliyeti aşağıdakiler arasında paylaştırılır: atıfta bulunduğu işlemler: örneğin, StarkNet blok 4779 200 işlem içerir ve geçerlilik kanıtı her işlem için 267830 birim gaz veya 1339,15 gaz tüketir. 4.2.1. Çağrı verilerini optimize etme: önbellek sözleşmesi Aşağıda, sık kullanılanlar için bir adres önbelleği uygulayan bir smart contract gösterilmektedir. depolama ve yürütmenin çok daha ucuz olması gerçeğinden yararlanarak adresler kaynakları ve bunların kullanımını gösteren bir Friends sözleşmesi. İkincisi takip ediyor addFriend işlevi çağrılarak kaydedilebilecek bir adresin "arkadaşları". Eğer bir adres zaten en az bir kez kullanılmışsa, addFriendWithCache çağrılarak eklenebilir işlev: önbellek endeksleri 4 baytlık tamsayılardır, adresler ise 20 baytla temsil edilir, yani fonksiyon argümanında 5:1 oranında tasarruf vardır. Aynı mantık diğer veriler için de kullanılabilir tamsayılar veya daha genel olarak baytlar gibi türler. sözleşme Adres Önbelleği { eşleme(adres => uint32) genel adres2key; adres[] genel anahtar2adres; function önbellekWrite(adres _address) dahili dönüşler (uint32) { require(key2address.length < type(uint32).max, "AddressCache: önbellek dolu"); require(address2key[_address] == 0, "AddressCache: adres zaten önbelleğe alınmış"); // anahtarlar 1'den başlamalıdır çünkü 0 "bulunamadı" anlamına gelir uint32 anahtar = uint32(anahtar2adresi.uzunluk + 1); adres2anahtar[_adres] = anahtar; key2address.push(_address); dönüş anahtarı; } function cacheRead(uint32 _key) genel görünüm şunu döndürür (adres) { require(_key <= key2address.length && _key > 0, "AddressCache: anahtar bulunamadı"); dönüş anahtarı2adresi[_anahtar - 1]; } } Liste 2: Adres önbellek sözleşmesi. sözleşme Arkadaşlar AdresCache'dir { haritalama(adres => adres[]) genel arkadaşlar; function addFriend(adres _friend) public { arkadaşlar[msg.sender].push(_friend); önbellekWrite(_arkadaş); } function addFriendWithCache(uint32 _friendKey) public { arkadaşlar[msg.sender].push(cacheRead(_friendKey)); } function getFriends() genel görünüm şunu döndürür (adres[] belleği) { arkadaşlara geri dönün[msg.sender];} } Liste 3: Adres önbelleğini devralan bir sözleşme örneği. Sözleşme önbellekte yaklaşık 4 milyar (232) adresi destekliyor ve bir bayt eklemek şunu sağlıyor: yaklaşık 1 trilyon (240). 4.2.2. Depolamayı optimize etme: Bloom filtreleri StarkNet üzerinde depolama kullanımını en aza indirmeye yönelik çeşitli teknikler vardır. Eğer gerekli değilse orijinal verilerin kullanılabilirliğini garanti ederse, hash zincirine kaydedilmesi yeterlidir: bu ERC-721 (NFT) [22], yani sorunu çözen bir IPFS bağlantısı için verileri kaydetmek için kullanılan mekanizmadır. Varsa verilerin hash. Birden çok kez saklanan veriler için bir arama kullanmak mümkündür. Optimism için tanıtılan önbelleğe alma sistemine benzer, tüm değerlerin şu adrese kaydedilmesini gerektiren tablo en az bir kez. Bazı uygulamalarda Bloom filtresi kullanılarak tüm değerlerin kaydedilmesi önlenebilir. [23, 24, 25], yani birinin kesin olarak bilmesini sağlayan olasılıksal bir veri yapısı bir öğe bir kümeye ait değildir ancak küçük ama göz ardı edilemeyecek bir yanlış olasılığını kabul eder pozitifler. Bir Bloom filtresi sıfırda 𝑚bit dizisi olarak başlatılır. Bir öğe eklemek için 𝑘hash işlevleri düzgün bir rastgele dağılım kullanılır, her biri belirlenen dizinin bir bitiyle eşleşir 1'e kadar. Bir öğenin kümeye ait olup olmadığını kontrol etmek için 𝑘hash işlevlerini çalıştırırız ve doğrularız. 𝑘bit'lerin 1'e ayarlandığını. Basit bir Bloom filtresinde, bir öğe aslında kümeye aittir veya yanlış pozitiftir; sayı arttıkça artan bir olasılık girişlerin sayısı artıyor. 𝑛 elemanlarını ekledikten sonra: P[yanlış pozitif] = (︃ 1 – [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 her bit kümesinin olasılığından bağımsız olduğu varsayılarak. Eğer 𝑛elemanları (isteğe bağlı boyutta!) dahil edilmesi bekleniyor ve yanlış pozitifin tolere edilme olasılığı 𝑝, dizinin boyutu şu şekilde hesaplanabilir: 𝑚= −𝑛ln 𝑝 (2'de)2 hash işlevlerinin optimum sayısı şu şekildedir: 𝑘= 𝑚 𝑛ln 2 %1 toleransla 1000 eleman eklediğimizi varsayarsak dizinin boyutu 9585 bit olur. 𝑘= 6 ile %0,1 tolerans için 𝑘= 9 ile 14377 bit olur. Bir milyon eleman ise Eklenmesi bekleniyorsa dizinin boyutu %1 için yaklaşık 1170 kB, %1 için ise 1775 kB olur. %0,1, aynı 𝑘 değerleriyle, çünkü yalnızca 𝑝[26]'ye bağlıdır. Oyuncuların daha önce meydan okudukları bir rakibe atanmaması gereken bir oyunda, Her oyuncu için geçmiş rakiplerin listesini depoya kaydetmek yerine Bloom kullanılabilir. filtre. Bazı oyunculara meydan okumama riski genellikle kabul edilebilir ve filtre sıfırlanabilir periyodik olarak.4.3. Ethereum uyumluluk EVM ve Ethereum ile uyumlu olmanın temel avantajı, mevcut tüm uygulamaların yeniden kullanılmasıdır araçlar. Ethereum smart contracts herhangi bir değişiklik yapılmadan Optimism üzerinde yayınlanabilir veya yeni denetimler. Cüzdanlar uyumlu kalır, geliştirme ve statik analiz araçları, genel analiz araçlar, indeksleme araçları ve oracles. Ethereum ve Solidity'nin iyi çalışılmış uzun bir geçmişi var Yeniden giriş saldırıları, taşmalar ve yetersiz akışlar, flaş krediler ve oracle gibi güvenlik açıkları manipülasyonlar. Bu nedenle Optimism kısa sürede büyük miktarda değer yakalayabildi zaman. Farklı bir sanal makineyi benimsemeyi seçmek, tüm ekosistemi yeniden inşa etme zorunluluğu anlamına gelir. daha fazla uygulama özgürlüğü avantajına sahiptir. StarkNet hesabı yerel olarak uyguluyor her hesabın uygulayabildiği bir smart contract olduğu bir mekanizma olan soyutlama bir arayüze uyduğu sürece keyfi mantık (bu nedenle soyutlama terimi): bu, farklı dijital imza şemalarının kullanımı, özel anahtarı kullanarak değiştirme yeteneği aynı adresi kullanın veya çoklu imza kullanın. Ethereum topluluğu bunun tanıtımını önerdi 2020'de EIP-2938 ile mekanizma, ancak teklif bir yıldan fazla bir süredir bayat kaldı diğer güncellemelere daha fazla öncelik verildi [27]. Uyumluluktan elde edilen bir diğer önemli fayda da mevcut istemcilerin yeniden kullanılmasıdır: Optimism Kendi düğümü için geth'in yalnızca ∼800 satırlık farka sahip bir versiyonunu kullanır. 2014'ten bu yana geliştiriliyor, test ediliyor ve bakımı yapılıyor. Güçlü bir müşteriye sahip olmak, tanımlandığı üzere çok önemlidir. ağda neyin geçerli olarak kabul edildiği veya edilmediği. Arıza kanıtlamanın uygulanmasında bir hata Sistem yanlış bir ispatın doğru kabul edilmesine veya doğru bir ispatın geçersiz olmasına neden olabilir. bloğun yanlış kabul edilmesi, sistemi tehlikeye atıyor. Bu tür bir olasılık saldırı daha geniş bir müşteri çeşitliliği ile sınırlandırılabilir: Optimism ayrıca yeniden kullanılabilir diğer Ethereum istemcilerin bakımı zaten yapılıyor ve başka bir Erigon tabanlı istemcinin geliştirilmesi de sürüyor zaten devam ediyor. 2016 yılında geth'in hafıza yönetimindeki bir sorundan yararlanıldı. DoS saldırısı ve ilk savunma hattı, en çok ikinci olan Parity'nin kullanılmasını önermekti. o sırada kullanılan istemci 5. StarkNet geçerlilik kanıtlarıyla aynı sorunla karşı karşıyadır, ancak istemciler sıfırdan yazılması gerekir ve ispat sistemi çok daha karmaşıktır ve dolayısıyla doğruluğu sağlamak da çok daha karmaşıktır.

Заключение

Заключение Накопительные пакеты — наиболее многообещающее решение, доступное сегодня для решения проблемы масштабируемости в децентрализованные 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 эта проблема, надеюсь, будет решена.

Çözüm

Sonuç Toplamalar, ölçeklenebilirlik sorununu çözmek için günümüzde mevcut olan en umut verici çözümdür. merkezi olmayan blockchain'ler, modüler blockchain'lerin aksine modüler blockchain'lerin yolunu açıyor yekpare blockchains. İyimser Toplama veya Geçerlilik Toplama geliştirme seçeneği temel olarak gösterilmektedir karmaşıklık ve çeviklik arasında bir denge olarak. StarkNet hızlı gibi çok sayıda avantaja sahiptir para çekme işlemleri, geçersiz durum geçişlerine sahip olunmaması, yapısal olarak yetersizlik, daha düşük işlem maliyeti daha uzun bir geliştirme süresi ve EVM ile uyumsuzluk nedeniyle, Optimism ise hızla pazardan büyük bir pay elde etmek için ağ ekonomisinden yararlandı. Optimism Ancak Bedrock, Geçerlilik haline gelmesini sağlayan modüler bir tasarıma sahiptir. 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Gelecekteki toplama: Cannon şu anda hata koruması için MIPS'ye derlenmiş minigeth kullanıyor Sistem, ancak aynı mimari bir devre elde etmek ve geçerlilik kanıtları üretmek için kullanılabilir. EVM gibi karmaşık bir makinenin bir mikro mimari için derlenmesi daha basit bir sonuç verir. Yükseltme durumunda değiştirilmesine ve yeniden doğrulanmasına gerek olmayan devre. RISC Sıfır bir RISC-V temel alınarak halihazırda geliştirilmekte olan STARK kanıtlarına sahip doğrulanabilir mikro mimari bu amaçla MIPS [28]'ye alternatif olarak kullanılabilir. Göz ardı edilmemesi gereken bir husus, teknoloji çalışıyor. Geleneksel blockchain'lerin güçlü yanı, durumunu doğrulayabilmesidir. blockchain hiçbir üçüncü taraf varlığına güvenmeden. Ancak StarkNet durumunda, Çeşitli bileşenleri doğrulamak mümkün olmadığında uygulamaya güvenmek gerekir kriptografiye ve ileri matematiğe dayalıdır. Bu başlangıçta sürtünme yaratabilir. teknolojinin benimsenmesi, ancak araçlar ve dürüstlük kanıtlarının kullanımı ilerledikçe blockchain alanının dışında bu sorunun çözüleceğini umuyoruz.