Optimism Teknik Dokümantasyonu

Tác giả Optimism Collective · 2021

Optimism không có whitepaper truyền thống. Là một optimistic rollup Ethereum Layer 2, thiết kế và thông số kỹ thuật của nó được ghi lại qua tài liệu kỹ thuật, đặc tả OP Stack và các bài đăng nghiên cứu thay vì một bài báo học thuật chính thức duy nhất.

🇺🇸 English (Bản gốc)

🇹🇷 Türkçe (Bản dịch)

Tóm tắt

Bài viết giải quyết vấn đề về khả năng mở rộng trong blockchain phi tập trung bằng cách phân tích sự cân bằng giữa thông lượng giao dịch và yêu cầu phần cứng để chạy một nút. Bản tổng hợp, tức là các công nghệ để xác minh trên chuỗi các khối được thực hiện ngoài chuỗi, được trình bày dưới dạng bằng chứng lỗi hoặc tính hợp lệ. Chúng tôi so sánh Tổng hợp lạc quan và Tổng hợp hợp lệ về thời gian rút tiền, chi phí giao dịch, kỹ thuật tối ưu hóa và khả năng tương thích với hệ sinh thái Ethereum. Phân tích của chúng tôi cho thấy rằng Optimism Bedrock hiện có tốc độ nén khí xấp xỉ 20:1, trong khi StarkNet đạt được tốc độ nén chi phí ghi lưu trữ vào khoảng 24:1. Chúng tôi cũng thảo luận về các kỹ thuật để tối ưu hóa hơn nữa các tỷ lệ này, chẳng hạn như việc sử dụng hợp đồng bộ đệm và bộ lọc Bloom. Cuối cùng, kết luận của chúng tôi nêu bật sự cân bằng giữa độ phức tạp và tính linh hoạt trong việc lựa chọn giữa Tổng hợp lạc quan và hợp lệ. Từ khóa Blockchain, Khả năng mở rộng, Rollup 1. Giới thiệu Công nghệ Blockchain đã thu hút được sự chú ý đáng kể nhờ tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn, vì hầu hết blockchain phải đối mặt với sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Bộ ba bất khả thi về khả năng mở rộng [1, 2]. Để tăng thông lượng của blockchain, một giải pháp đơn giản là tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng lượng gas tối đa mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối nên khi thông lượng tăng lên, các yêu cầu về phần cứng cũng tăng lên, dẫn đến tính tập trung cao hơn của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa thiết kế của họ để tối đa hóa khả năng phân cấp kiến trúc của họ, trong khi những blockchain khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn một cách giả tạo thông lượng của blockchain để giảm yêu cầu phần cứng để tham gia vào mạng. Trong những năm qua, nhiều nỗ lực đã được thực hiện để tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như các kênh trạng thái [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là chuyển một số hoạt động ra khỏi chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng cách sử dụng smart contracts và xác minh DLT 2023: Hội thảo công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền bài viết này thuộc về các tác giả. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). Kỷ yếu hội thảo CEUR http://ceur-ws.org ISSN 1613-0073 Kỷ yếu hội thảo CEUR (CEUR-WS.org) trên chuỗi những gì đang diễn ra ngoài chuỗi. Tuy nhiên, cả kênh Plasma và kênh trạng thái đều bị hạn chế trong việc hỗ trợ smart contract chung. Các bản tổng hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain (Layer 1 hoặc L1) khác và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Chúng, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Tập hợp có ba thành phần chính: • Trình sắp xếp thứ tự: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: gốc Merkle) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 định nghĩa...

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

Giới thiệu

Giới thiệu Công nghệ chuỗi khối đã thu hút được sự chú ý đáng kể do tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn vì hầu hết blockchain đều gặp phải sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Khả năng mở rộng Trilemma [1, 2]. Để tăng thông lượng của blockchain, một giải pháp tầm thường là để tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng mức tối đa lượng khí mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối, khi thông lượng tăng lên thì các yêu cầu về phần cứng cũng tăng lên, dẫn đến yêu cầu lớn hơn tập trung của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa được thiết kế để tối đa hóa khả năng phân cấp kiến trúc của họ, trong khi những nền tảng khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn thông lượng của blockchain một cách giả tạo để hạ thấp yêu cầu phần cứng xuống tham gia vào mạng lưới. Trong những năm qua, người ta đã nỗ lực tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như nhà nước kênh [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là di chuyển một số hoạt động ngoài chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng smart contracts và xác minh DLT 2023: Hội thảo Công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền của bài viết này thuộc về tác giả của nó. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). CEUR Xưởng Thủ tục tố tụng http://ceur-ws.org ISSN 1613-0073 Kỷ yếu Hội thảo CEUR (CEUR-WS.org)trên chuỗi những gì đang xảy ra ngoài chuỗi. Tuy nhiên, cả hai kênh Plasma và trạng thái đều bị hạn chế về sự ủng hộ của họ đối với smart contracts chung. Các tập hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain khác (Layer 1 hoặc L1) và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Họ, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Bản tổng hợp có ba thành phần chính: • Trình sắp xếp: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: Merkle root) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 xác định chính tắc blockchain của L2 bằng cách thiết lập thứ tự của dữ liệu được xuất bản. • Nút cuộn đầy đủ: các nút lấy, xử lý và xác thực các khối Rollup từ Lớp 1 bằng cách xác minh rằng gốc là chính xác. Nếu một khối chứa các giao dịch không hợp lệ thì đó là bị loại bỏ, điều này ngăn cản Trình sắp xếp chuỗi tạo các khối hợp lệ bao gồm các khối không hợp lệ giao dịch. • Nút ánh sáng cuộn lên: các nút nhận khối cuộn lên từ Layer 1 nhưng không tính toán bản thân nhà nước mới. Họ xác minh rằng gốc trạng thái mới là hợp lệ bằng cách sử dụng các kỹ thuật chẳng hạn như bằng chứng lỗi hoặc tính hợp lệ. Bản tổng hợp đạt được khả năng mở rộng bằng cách giảm chi phí phân bổ của các giao dịch theo số lượng của người dùng tăng lên. Điều này là do chi phí đảm bảo tính hợp lệ của blockchain tăng tuyến tính liên quan đến chi phí xác minh các giao dịch riêng lẻ. Các bản cuộn khác nhau tùy theo cơ chế đảm bảo tính hợp lệ của việc thực hiện giao dịch tại các nút nhẹ: trong Optimistic Rollups nó được đảm bảo bởi một mô hình kinh tế và bằng chứng lỗi, trong khi Hiệu lực Rollups nó được đảm bảo bằng mật mã bằng cách sử dụng bằng chứng hợp lệ. Các nút ánh sáng có thể được triển khai dưới dạng smart contract trên Layer 1. Họ chấp nhận gốc rễ của trạng thái mới và xác minh tính hợp lệ hoặc bằng chứng lỗi: do đó, các bản tổng hợp này được gọi là Hợp đồng thông minh Bản cuộn. Nếu các nút nhẹ độc lập thì chúng được gọi là Bản tổng hợp có chủ quyền [6]. Ưu điểm của sử dụng Hợp đồng thông minh Rollup là để có thể xây dựng một cầu nối giảm thiểu sự tin cậy giữa hai bên blockchains: vì tính hợp lệ của trạng thái L2 được chứng minh cho L1, nên một hệ thống giao dịch từ L2 đến L1 có thể được thực hiện, cho phép rút tiền. Nhược điểm là chi phí của giao dịch phụ thuộc vào chi phí xác minh trạng thái trên L1: nếu lớp cơ sở bị bão hòa bởi các hoạt động khác, chi phí giao dịch trên Rollup cũng tăng lên. Các lớp dữ liệu và đồng thuận là những lớp quyết định tính bảo mật của hệ thống như họ xác định thứ tự của các giao dịch, ngăn chặn các cuộc tấn công và cung cấp dữ liệu để chứng minh trạng thái hiệu lực. Đóng góp giấy tờ Trong bài viết này, chúng tôi nghiên cứu Tổng hợp lạc quan và hợp lệ, hai cải tiến giải pháp cho Bộ ba bất khả thi về khả năng mở rộng, tập trung vào các triển khai đáng chú ý, chẳng hạn như Optimism Bedrock và StarkNet. Những đóng góp của chúng tôi bao gồm sự so sánh toàn diện về những giải pháp, phân tích thời gian rút tiền và thảo luận về cuộc tấn công có thể xảy ra vào Optimism Đá nền. Ngoài ra, chúng tôi tính toán tỷ lệ nén khí của chúng, cung cấp các tối ưu hóa dành riêng cho ứng dụng và trình bày những ưu điểm cũng như nhược điểm của việc loại bỏ Ethereum Máy ảo (EVM).

Cấu trúc giấy Bài viết được tổ chức như sau. Trong phần 2 Bản tổng hợp lạc quan là được giới thiệu bằng cách phân tích Optimism Bedrock. Trong phần 3 Bản tổng hợp hợp lệ được giới thiệu bởi phân tích StarkNet. Trong phần 4 chúng ta so sánh hai giải pháp. Cuối cùng, trong phần 5 chúng ta vẽ một số kết luận.

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.

Tổng hợp lạc quan

Bản tổng hợp lạc quan Ý tưởng chấp nhận một cách lạc quan đầu ra của các khối mà không cần xác minh việc thực hiện chúng là đã có mặt trong báo cáo chính thức Bitcoin [7], thảo luận về các nút ánh sáng. Các nút này chỉ theo sau chuỗi tiêu đề bằng cách xác minh quy tắc đồng thuận, khiến chúng dễ bị chấp nhận khối chứa các giao dịch không hợp lệ trong trường hợp bị tấn công 51%. Nakamoto đề xuất giải quyết việc này vấn đề bằng cách sử dụng hệ thống “cảnh báo” để cảnh báo các nút ánh sáng rằng một khối chứa các giao dịch không hợp lệ. Cơ chế này lần đầu tiên được thực hiện bởi Al-Bassam, Sonnino và Buterin [8] trong đó có lỗi hệ thống bằng chứng dựa trên mã sửa lỗi [9] được sử dụng. Để có thể tạo điều kiện cho bằng chứng lỗi, điều cần thiết là dữ liệu từ tất cả các khối, bao gồm cả các khối không hợp lệ, có sẵn để mạng: đây là Vấn đề về tính khả dụng của dữ liệu, được giải quyết bằng cách sử dụng dữ liệu xác suất cơ chế lấy mẫu Thiết kế Optimistic Rollup đầu tiên được trình bày bởi John Adler và Mikerah Quintyne-Collins vào năm 2019 [10], trong đó các khối được xuất bản trên blockchain khác điều đó xác định sự đồng thuận của họ về việc đặt hàng. 2.1. Optimism Đá gốc Bedrock [11] là phiên bản mới nhất của Optimism, một Bản tổng hợp hợp đồng thông minh. Phiên bản trước, Máy ảo Optimistic (OVM) yêu cầu một trình biên dịch đặc biệt để biên dịch Solidity thành mã byte riêng: ngược lại, Bedrock hoàn toàn tương đương với EVM ở chỗ công cụ thực thi tuân theo thông số kỹ thuật của Giấy vàng Ethereum [12]. 2.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch thông qua hợp đồng trên Ethereum, Cổng thông tin Optimism bằng cách gọi hàm DepositTransaction. Khi một giao dịch được thực hiện, một Sự kiện TransactionDeposited được phát ra, mỗi nút trong Rollup sẽ lắng nghe để xử lý tiền gửi. Giao dịch ký gửi là giao dịch L2 có nguồn gốc từ L1. Nếu người gọi của là một hợp đồng, địa chỉ được chuyển đổi bằng cách thêm một giá trị không đổi vào nó: điều này ngăn cản các cuộc tấn công trong đó hợp đồng trên L1 có cùng địa chỉ với hợp đồng trên L2 nhưng có mã khác. Việc đưa vào L2 của giao dịch gửi tiền được đảm bảo bằng thông số kỹ thuật trong trình tự cửa sổ. Giao dịch đã gửi là loại giao dịch tương thích EIP-2718 mới [13] với tiền tố 0x7E, trong đó các trường được mã hóa rlp là: • byte32 sourceHash: hash xác định duy nhất nguồn của giao dịch. • địa chỉ từ: địa chỉ của người gửi. • địa chỉ tới: địa chỉ người nhận hoặc địa chỉ 0 nếu giao dịch gửi tiền là việc tạo hợp đồng.• uint256 mint: giá trị được tạo trên L2. • Giá trị uint256: giá trị được gửi tới người nhận. • dữ liệu byte: dữ liệu đầu vào. • byte gasLimit: giới hạn gas của giao dịch. sourceHash được tính là keccak256 hash của khối L1 hash và nhật ký L1 chỉ mục, xác định duy nhất một sự kiện trong một khối. Vì các giao dịch ký gửi được bắt đầu trên L1 nhưng được thực hiện trên L2 nên hệ thống cần có cơ chế thanh toán L1 cho lượng gas sử dụng cho L2. Một giải pháp là gửi ETH qua Cổng thông tin, nhưng điều này ngụ ý rằng mọi người gọi (ngay cả những người gọi gián tiếp) đều phải được đánh dấu là phải trả tiền và đây là không thể thực hiện được đối với nhiều dự án hiện có. Cách khác là đốt khí tương ứng trên L1. Gas 𝑔được phân bổ cho giao dịch ký gửi được gọi là gas được đảm bảo. Giá khí L2 trên L1 không được đồng bộ hóa tự động mà được ước tính bằng cơ chế tương tự như EIP-1559 [14]. Lượng gas tối đa được đảm bảo cho mỗi khối Ethereum là 8 triệu, với mục tiêu là 2 triệu. Số lượng 𝑐 ETH cần thiết để thanh toán gas trên L2 là 𝑐= 𝑔𝑏L2 trong đó 𝑏L2 là phí cơ bản trên L2. Hợp đồng trên L1 đốt cháy một lượng khí bằng 𝑐/𝑏L2. Gas dành để gọi Giao dịch gửi tiền được hoàn trả trên L2: nếu số tiền này lớn hơn lượng gas được đảm bảo, không có khí đốt. Giao dịch đầu tiên của khối rollup là giao dịch ký gửi thuộc tính L1, được sử dụng để đăng ký trên L2 triển khai trước các thuộc tính của khối Ethereum. Các thuộc tính mà predeploy cung cấp quyền truy cập là số khối, dấu thời gian, phí cơ sở, khối hash và trình tự số, là số khối của L2 so với khối L1 được liên kết (còn gọi là epoch); con số này được đặt lại khi một kỷ nguyên mới bắt đầu. 2.1.2. Trình tự Các nút Tổng hợp lấy chuỗi Optimism hoàn toàn từ Ethereum. Chuỗi này được mở rộng mỗi khi giao dịch mới được xuất bản trên L1 và các khối của nó được tổ chức lại mỗi lần Ethereum khối được tổ chức lại. Bản tổng hợp blockchain được chia thành các kỷ nguyên. Đối với mỗi 𝑛 số khối của Ethereum thì có 𝑛epoch tương ứng. Mỗi kỷ nguyên chứa ít nhất một khối và mỗi khối trong một kỷ nguyên chứa một giao dịch được ký gửi thuộc tính L1. Khối đầu tiên trong một kỷ nguyên chứa tất cả các giao dịch được gửi qua Cổng thông tin. Layer 2 khối cũng có thể chứa các giao dịch được sắp xếp theo trình tự, tức là các giao dịch được gửi trực tiếp đến Bộ sắp xếp thứ tự. Trình sắp xếp chuỗi chấp nhận các giao dịch từ người dùng và xây dựng các khối. Với mỗi khối, nó xây dựng một đợt sẽ được xuất bản vào Ethereum. Một số lô có thể được xuất bản theo cách nén, lấy tên kênh. Một kênh có thể được chia thành nhiều khung, trong trường hợp nó quá lớn để một giao dịch duy nhất. Một kênh được định nghĩa là nén với ZLIB [15] của mã hóa rlp lô. Các trường của một lô là số kỷ nguyên, kỷ nguyên hash, kỷ nguyên gốc hash, kỷ nguyên dấu thời gian và danh sách giao dịch. Cửa sổ tuần tự, được xác định bằng một kỷ nguyên, chứa số cố định 𝑤 của L1 liên tiếp các khối mà bước phái sinh lấy làm đầu vào để xây dựng số lượng khối L2 thay đổi. cho kỷ nguyên 𝑛, cửa sổ tuần tự 𝑛bao gồm các khối [𝑛, 𝑛+𝑤). Điều này ngụ ý rằng việc đặt hàng các giao dịch và khối L2 trong cửa sổ tuần tự không được cố định cho đến khi cửa sổ kết thúc. Giao dịch rollup được gọi là an toàn nếu lô chứa nó đã được xác nhận trên L1. Khungđược đọc từ các khối L1 để xây dựng lại các lô. Việc triển khai hiện tại không cho phép quá trình giải nén kênh bắt đầu cho đến khi nhận được tất cả các khung tương ứng. không hợp lệ lô được bỏ qua. Các giao dịch khối riêng lẻ được lấy từ các đợt, được được công cụ thực thi sử dụng để áp dụng các chuyển đổi trạng thái và thu được trạng thái Tổng hợp. 2.1.3. Rút tiền Để xử lý việc rút tiền, hệ thống nhắn tin L2-to-L1 được triển khai. Ethereum cần biết trạng thái L2 để chấp nhận rút tiền và điều này được thực hiện bằng cách xuất bản trên L2 Đầu ra Oracle smart contract trên L1 gốc trạng thái của mỗi khối L2. Những rễ này được chấp nhận một cách lạc quan là hợp lệ (hoặc đã hoàn thiện) nếu không có bằng chứng lỗi nào được thực hiện trong quá trình thời gian tranh chấp. Chỉ những địa chỉ được chỉ định là Người đề xuất mới có thể xuất bản các gốc đầu ra. Hiệu lực nguồn gốc đầu ra được khuyến khích bằng cách yêu cầu Người đề xuất đặt cọc một khoản tiền sẽ bị cắt giảm nếu họ cho thấy đã đề xuất một gốc không hợp lệ. Giao dịch được bắt đầu bằng cách gọi hàm bắt đầu Rút tiền khi triển khai trước trên L2 và sau đó hoàn tất trên L1 bằng cách gọi hàm FinalizeWithdrawalTransaction trên Cổng thông tin Optimism đã đề cập trước đó. Gốc đầu ra tương ứng với khối L2 được lấy từ L2 Output Oracle; nó là xác minh rằng nó đã được hoàn tất, tức là thời gian tranh chấp đã trôi qua; nó được xác minh rằng đầu ra Bằng chứng gốc khớp với Bằng chứng của Oracle; đã xác minh rằng đã bao gồm hash số tiền rút trong đó sử dụng Bằng chứng rút tiền; việc rút tiền vẫn chưa được hoàn tất; và sau đó là cuộc gọi đến địa chỉ đích được thực hiện, với giới hạn gas, lượng Ether và dữ liệu được chỉ định. 2.1.4. Cannon: hệ thống chống lỗi Nếu một Rollup Full Node, bằng cách thực hiện cục bộ các lô và giao dịch được gửi, phát hiện ra rằng trạng thái Layer 2 không khớp với gốc trạng thái được Người đề xuất xuất bản trên chuỗi, nó có thể thực thi bằng chứng lỗi trên L1 để chứng minh rằng kết quả của quá trình chuyển khối là không chính xác. Bởi vì chi phí chung, việc xử lý toàn bộ khối Rollup trên L1 là quá tốn kém. Giải pháp đã thực hiện của Bedrock chỉ thực hiện trên chuỗi chỉ dẫn đầu tiên về sự bất đồng của minigeth, biên dịch nó thành kiến trúc MIPS được thực thi trên trình thông dịch trực tuyến và được xuất bản trên L1. minigeth là phiên bản đơn giản của geth 1 trong đó sự đồng thuận, RPC và cơ sở dữ liệu đã được gỡ bỏ. Để tìm hướng dẫn đầu tiên về sự bất đồng, tìm kiếm nhị phân tương tác được tiến hành giữa người khởi xướng bằng chứng lỗi và người xuất bản gốc đầu ra. Khi bằng chứng bắt đầu, cả hai bên xuất bản gốc của trạng thái bộ nhớ MIPS trong quá trình thực thi khối trong hợp đồng Thử thách: nếu hash khớp thì có nghĩa là cả hai bên đều đồng ý về nửa đầu của quá trình thực hiện do đó xuất bản phần gốc của nửa sau, nếu không thì nửa của nửa đầu được xuất bản, v.v. Làm như vậy đạt được chỉ dẫn đầu tiên về sự bất đồng theo số bước logarit so với lần thực hiện ban đầu. Nếu một trong hai điểm dừng tương tác, khi kết thúc thời gian tranh chấp, người tham gia kia sẽ tự động thắng. Để xử lý hướng dẫn, trình thông dịch MIPS cần truy cập vào bộ nhớ của nó: vì gốc là sẵn có, các ô nhớ cần thiết có thể được xuất bản bằng cách chứng minh sự bao gồm của chúng. Để truy cập trạng thái của EVM, việc sử dụng được tạo ra từ Preimage Oracle: đưa ra hash của một khối mà nó trả về 1https://geth.ethereum.org/docs

tiêu đề khối, từ đó người ta có thể lấy hash của khối trước đó và quay lại chuỗi hoặc lấy hash trạng thái và nhật ký mà từ đó người ta có thể lấy tiền ảnh. oracle được minigeth triển khai và thay thế cơ sở dữ liệu. Các truy vấn được thực hiện tới các nút khác để có được những hình ảnh tiền đề.

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

Bản tổng hợp hiệu lực

Bản tổng hợp hiệu lực Mục tiêu của Tổng hợp tính hợp lệ là để chứng minh tính hợp lệ của quá trình chuyển đổi trạng thái bằng mật mã đưa ra chuỗi các giao dịch với bằng chứng ngắn có thể được xác minh dưới dạng so sánh tuyến tính đến thời điểm tính toán ban đầu. Các loại chứng chỉ này được gọi là bằng chứng toàn vẹn tính toán và được triển khai trên thực tế với SNARK (ARgument of Knowledge không tương tác ngắn gọn), sử dụng số học mạch làm mô hình tính toán của chúng. Việc triển khai SNARK khác nhau sẽ khác nhau về thời gian chứng minh, thời gian xác minh, nhu cầu thiết lập đáng tin cậy và khả năng kháng lượng tử [16, 17]. STARK (Có thể mở rộng Đối số kiến thức minh bạch) [18] là một loại SNARK không yêu cầu độ tin cậy thiết lập và có khả năng chống lượng tử, đồng thời mang lại một số hiệu quả trong việc chứng minh và xác minh so với các giải pháp khác. 3.1. StarkNet StarkNet là Bản tổng hợp hiệu lực hợp đồng thông minh được phát triển bởi StarkWare sử dụng STARK hệ thống bằng chứng để xác thực trạng thái của nó thành Ethereum. Để tạo thuận lợi cho việc xây dựng các bằng chứng có giá trị, một máy ảo khác với EVM được sử dụng, có ngôn ngữ cấp cao là Cairo. 3.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch qua hợp đồng vào Ethereum bằng cách gọi sendMessageToL2 chức năng. Thông báo được ghi lại bằng cách tính hash của nó và tăng bộ đếm. Trình sắp xếp chuỗi lắng nghe sự kiện LogMessageToL2 và mã hóa thông tin trong giao dịch StarkNet gọi một hàm của hợp đồng có trang trí l1_handler. Khi kết thúc quá trình thực hiện, khi bằng chứng về sự chuyển đổi trạng thái được tạo ra, việc tiêu thụ tin nhắn sẽ được đính kèm với nó và nó bị xóa bằng cách giảm bộ đếm của nó. Thông số kỹ thuật StarkNet không yêu cầu bao gồm các giao dịch ký gửi, do đó, gas cần có thị trường để khuyến khích Người sắp xếp chuỗi xuất bản chúng trên L2. Ở phiên bản hiện tại, vì Sequencer được tập trung và quản lý bởi StarkWare, chi phí của các giao dịch ký gửi chỉ được xác định bởi chi phí thực hiện khoản tiền gửi. Chi phí này được thanh toán bằng cách gửi ETH tới gửiMessageToL2. Các Ether này vẫn bị khóa trên L1 và được chuyển đến Bộ sắp xếp chuỗi vào ngày L1, khi giao dịch gửi tiền được đưa vào quá trình chuyển đổi trạng thái. Số lượng ETH được gửi, nếu giao dịch gửi tiền được bao gồm, được chi tiêu đầy đủ, bất kể lượng gas tiêu thụ trên L2. StarkNet không có hệ thống tự động cung cấp các thuộc tính khối L1. Ngoài ra, Fossil là một giao thức được phát triển bởi Oiler Network 2 cho phép, với hash của một chặn, mọi thông tin có được từ Ethereum bằng cách xuất bản các hình ảnh đầu tiên. 2https://www.oiler.network/3.1.2. Trình tự Trạng thái hiện tại của StarkNet có thể được bắt nguồn hoàn toàn từ Ethereum. Bất kỳ sự khác biệt trạng thái giữa các lần chuyển đổi được xuất bản trên L1 dưới dạng calldata. Sự khác biệt được công bố cho từng hợp đồng và được lưu dưới dạng uint256[] với mã hóa sau: • Số lĩnh vực liên quan đến triển khai hợp đồng. • Đối với từng hợp đồng được công bố: – Địa chỉ hợp đồng được công bố. – hash của hợp đồng đã công bố. – Số lượng đối số của người xây dựng hợp đồng. – Danh sách các đối số của hàm tạo • Số hợp đồng đã được sửa đổi lưu trữ. • Đối với mỗi hợp đồng được sửa đổi: – Địa chỉ của hợp đồng sửa đổi. – Số lượng cập nhật lưu trữ. – Cặp khóa-giá trị của địa chỉ lưu trữ với các giá trị mới. Sự khác biệt về trạng thái được công bố theo thứ tự, do đó chỉ cần đọc chúng một cách tuần tự là đủ xây dựng lại nhà nước. 3.1.3. Rút tiền Để gửi tin nhắn từ L2 đến L1, syscall send_message_to_L1 được sử dụng. Tin nhắn là được xuất bản lên L1 bằng cách tăng bộ đếm hash của nó cùng với bằng chứng và được hoàn thiện bằng cách gọi hàm tiêu thụMessageFromL2 trên StarkGate smart contract trên L1, hàm này giảm dần quầy. Bất kỳ ai cũng có thể hoàn tất việc rút tiền. 3.1.4. Bằng chứng hiệu lực Máy ảo Cairo [19] được thiết kế để hỗ trợ việc xây dựng các bằng chứng STARK. Ngôn ngữ Cairo cho phép mô tả tính toán bằng chương trình cấp cao ngôn ngữ, và không trực tiếp như một mạch. Điều này được thực hiện bằng hệ phương trình đa thức 3 thể hiện một phép tính đơn lẻ: chu trình FDE của kiến trúc von Neumann. số do đó, các ràng buộc là cố định và độc lập với loại tính toán, chỉ cho phép một Chương trình xác minh cho mọi chương trình có tính toán cần được chứng minh. StarkNet tổng hợp nhiều giao dịch thành một bằng chứng STARK duy nhất bằng cách sử dụng một bằng chứng được chia sẻ có tên là SHARP. Bằng chứng được gửi tới smart contract vào ngày Ethereum để xác minh tính hợp lệ của chúng và cập nhật gốc Merkle tương ứng với trạng thái mới. Chi phí tuyến tính để xác minh một bằng chứng hợp lệ cho phép chi phí của nó được khấu hao qua nhiều giao dịch. 3gọi là Biểu diễn trung gian đại số (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

So sánh

So sánh 4.1. Thời gian rút tiền Khía cạnh quan trọng nhất giúp phân biệt Bản tổng hợp lạc quan với Bản tổng hợp hợp lệ là thời gian trôi qua kể từ khi bắt đầu rút tiền cho đến khi hoàn tất việc rút tiền. Trong cả hai trường hợp, việc rút tiền được khởi tạo trên L2 và hoàn tất trên L1. Vào StarkNet, việc quyết toán có thể thực hiện được vì ngay khi bằng chứng hợp lệ của gốc trạng thái mới được chấp nhận vào Ethereum: về mặt lý thuyết, đó là có thể rút tiền trong khối đầu tiên của L1 sau khi khởi tạo. Trong thực tế, tần suất gửi bằng chứng hợp lệ trên Ethereum là sự cân bằng giữa tốc độ chặn hoàn thiện và tổng hợp bằng chứng. Hiện StarkNet cung cấp bằng chứng hợp lệ để xác minh cứ sau 10 giờ 4, nhưng nó dự định sẽ giảm khi hoạt động giao dịch tăng lên. Trên Optimism Bedrock, chỉ có thể hoàn tất việc rút tiền khi tranh chấp kết thúc khoảng thời gian (hiện tại là 7 ngày), sau đó root sẽ tự động được coi là hợp lệ. Chiều dài của khoảng thời gian này chủ yếu được xác định bởi thực tế là các bằng chứng lỗi có thể được kiểm duyệt trên Ethereum cho đến khi sự kết thúc của nó. Xác suất thành công của kiểu tấn công này giảm theo cấp số nhân khi thời gian tăng lên: E[giá trị bị trừ] = 𝑉𝑝𝑛 trong đó 𝑛 là số khối trong một khoảng, 𝑉 là số tiền có thể bị trừ bằng cách xuất bản một gốc không hợp lệ và 𝑝là xác suất thực hiện kiểm duyệt thành công tấn công trong một khối duy nhất. Giả sử xác suất này là 99%, giá trị bị khóa trong Rollup là một triệu Ether và số khối trong một khoảng là 1800 (6 giờ khối với 12 giờ khoảng thời gian giây): giá trị dự kiến là khoảng 0,01391 Ether. Hệ thống được đảm bảo an toàn bởi yêu cầu Người đề xuất đặt cược số lượng Ether lớn hơn nhiều so với giá trị dự kiến. Winzer và cộng sự. đã chỉ ra cách thực hiện một cuộc tấn công kiểm duyệt bằng cách sử dụng smart contract đơn giản điều đó đảm bảo rằng các vùng bộ nhớ nhất định ở trạng thái không thay đổi [20]. Mô hình hóa cuộc tấn công như một trò chơi Markov, bài báo cho thấy rằng kiểm duyệt là chiến lược chủ đạo cho một nhà sản xuất khối nếu họ nhận được nhiều tiền bồi thường hơn mức bao gồm giao dịch thay đổi bộ nhớ. Giá trị 𝑝được thảo luận ở trên có thể được xem là phần trăm của khối hợp lý các nhà sản xuất trong mạng lưới, nơi “hợp lý” không tính đến việc có thể bị phạt các yếu tố bên ngoài, chẳng hạn như ít tin tưởng hơn vào blockchain làm giảm giá trị tiền điện tử của nó. Đoạn mã sau trình bày một smart contract có thể được sử dụng để thực hiện một cuộc tấn công kiểm duyệt trên Bedrock. Cuộc tấn công khai thác động cơ của các nhà sản xuất khối bằng cách đưa hối lộ cho họ để kiểm duyệt các giao dịch có thể sửa đổi các phần cụ thể của bang. Hợp đồng chính chức năng, requireBribe, cho phép các nhà sản xuất khối nhận hối lộ nếu họ kiểm duyệt thành công giao dịch được nhắm mục tiêu bằng cách kiểm tra xem gốc đầu ra không hợp lệ không được chạm vào. hàm requireBribe(byte bộ nhớ storageProof) bên ngoài { require(!claimed[block.number], "đã nhận hối lộ"); Dòng điện bộ nhớ đề xuất đầu ra = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, lưu trữProof); require(invalidOutputRoot == current.outputRoot, "tấn công thất bại"); đã xác nhận quyền sở hữu[block.number] = true; (bool đã gửi, ) = block.coinbase.call{value: hối lộAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(đã gửi, "không gửi được ether"); } Liệt kê 1: Ví dụ về một hợp đồng khuyến khích cuộc tấn công kiểm duyệt vào Bedrock. Độ dài của thời gian tranh chấp cũng phải tính đến thực tế là bằng chứng lỗi được bằng chứng tương tác và do đó phải cung cấp đủ thời gian để người tham gia tương tác và mọi tương tác đều có thể bị kiểm duyệt. Nếu nước đi cuối cùng xảy ra vào thời điểm rất gần với khi kết thúc thời gian tranh chấp, chi phí kiểm duyệt sẽ ít hơn đáng kể. Mặc dù kiểm duyệt là chiến lược thống trị, khả năng thành công sẽ thấp hơn vì các nút kiểm duyệt dễ bị tấn công Tấn công từ chối dịch vụ: kẻ tấn công có thể tạo ra các giao dịch rất phức tạp kết thúc bằng công bố bằng chứng lỗi miễn phí vì sẽ không phải trả phí. Trong những trường hợp đặc biệt, thời gian tranh chấp kéo dài cho phép phối hợp trong trường hợp giải quyết thành công. tấn công kiểm duyệt để tổ chức một fork và loại trừ các nhà sản xuất khối tấn công. Khác cuộc tấn công có thể xảy ra bao gồm việc xuất bản nhiều đề xuất gốc cấp bang hơn mức mà các bên tranh chấp có thể xác minh, có thể tránh được bằng cách sử dụng giới hạn tần số. 4.1.1. Rút tiền lạc quan nhanh chóng Vì tính hợp lệ của Tổng hợp lạc quan có thể được xác minh bất kỳ lúc nào bởi bất kỳ Nút đầy đủ nào, nên đáng tin cậy oracle có thể được sử dụng để biết trên L1 liệu việc rút tiền có thể được hoàn tất một cách an toàn hay không. Cái này cơ chế được đề xuất lần đầu tiên bởi Maker [21]: oracle xác minh việc rút tiền, xuất bản kết quả trên L1 trong đó khoản vay chịu lãi được gán cho người dùng, kết quả này được tự động đóng cửa sau 7 ngày, tức là khi việc rút tiền thực sự có thể được hoàn tất. Giải pháp này đưa ra một giả định về độ tin cậy, nhưng trong trường hợp của Maker, nó được giảm thiểu do toán tử oracle được quản lý bởi cùng một tổ chức chịu rủi ro bằng cách cung cấp khoản vay. 4.2. Chi phí giao dịch Chi phí của giao dịch L2 chủ yếu được xác định bởi sự tương tác với L1. Trong cả hai giải pháp chi phí tính toán của các giao dịch rất rẻ vì nó được thực hiện hoàn toàn ngoài chuỗi. Optimism xuất bản dữ liệu cuộc gọi giao dịch L2 dưới dạng dữ liệu cuộc gọi và hiếm khi (hoặc không bao giờ) thực hiện lỗi bằng chứng, do đó calldata là tài nguyên đắt nhất. Vào ngày 12 tháng 1 năm 2022, mạng Bedrock đã được khởi chạy trên mạng thử nghiệm Goerli của Ethereum. Có thể tính được tốc độ nén khí bằng cách theo dõi lượng gas được sử dụng trên Bedrock trong một khoảng thời gian nhất định và bằng cách so sánh nó với lượng gas tiêu tốn cho L1 cho các khối tương ứng. Sử dụng phương pháp này để nén khí tỷ lệ ∼20: 1 được tìm thấy, nhưng con số này có thể khác với hoạt động thực tế trên mạng chính. StarkNet xuất bản trên Ethereum mọi thay đổi ở trạng thái L2 dưới dạng dữ liệu cuộc gọi, do đó dung lượng lưu trữ sẽ bị hạn chế nguồn tài nguyên đắt giá nhất. Vì mạng không sử dụng EVM nên chi phí giao dịch nén không thể được ước tính tầm thường. Bằng cách giả định chi phí thực hiện và lệnh gọi tới không đáng kể, có thể tính được tỷ lệ nén của việc ghi lưu trữ so với L1. Giả sử không có hợp đồng nào được triển khai và 10 ô chưa được truy cập trước đó trên StarkNet được đã sửa đổi, tỷ lệ nén chi phí ghi lưu trữ là ∼24: 1. Nếu một ô bị ghi đè 𝑛lần giữa các lần xuất bản dữ liệu, chi phí cho mỗi lần ghi sẽ là 1/𝑛so với chi phí của một lần viết, vì chỉ có lần cuối cùng được xuất bản. Chi phí có thể được giảm thiểu hơn nữa bằng cáchnén các giá trị được sử dụng thường xuyên. Chi phí xác minh bằng chứng hợp lệ được chia cho các giao dịch mà nó đề cập đến: ví dụ: StarkNet khối 4779 chứa 200 giao dịch và bằng chứng hợp lệ tiêu tốn 267830 đơn vị gas hoặc 1339,15 gas cho mỗi giao dịch. 4.2.1. Tối ưu hóa dữ liệu cuộc gọi: hợp đồng bộ đệm Trình bày bên dưới là smart contract triển khai bộ nhớ đệm địa chỉ cho các địa chỉ được sử dụng thường xuyên địa chỉ bằng cách tận dụng thực tế là việc lưu trữ và thực thi ít tốn kém hơn nhiều tài nguyên, cùng với hợp đồng Bạn bè thể hiện việc sử dụng nó. Cái sau theo dõi “bạn bè” của một địa chỉ có thể được đăng ký bằng cách gọi hàm addFriend. Nếu một địa chỉ đã được sử dụng ít nhất một lần, nó có thể được thêm bằng cách gọi addFriendWithCache chức năng: các chỉ mục bộ đệm là số nguyên 4 byte trong khi địa chỉ được biểu thị bằng 20 byte, vì vậy có mức tiết kiệm 5:1 cho đối số hàm. Logic tương tự có thể được sử dụng cho dữ liệu khác các loại như số nguyên hoặc nói chung hơn là byte. hợp đồng Địa chỉCache { ánh xạ (địa chỉ => uint32) địa chỉ công cộng2key; địa chỉ[] public key2address; hàm cacheWrite(address _address) trả về nội bộ (uint32) { require(key2address.length < type(uint32).max, "AddressCache: bộ đệm đã đầy"); require(address2key[_address] == 0, "AddressCache: địa chỉ đã được lưu vào bộ nhớ đệm"); // khóa phải bắt đầu từ 1 vì 0 có nghĩa là "không tìm thấy" khóa uint32 = uint32(key2address.length + 1); address2key[_address] = khóa; key2address.push(_address); chìa khóa trả lại; } hàm cacheRead(uint32 _key) chế độ xem công khai trả về (địa chỉ) { require(_key <= key2address.length && _key > 0, "AddressCache: không tìm thấy khóa"); trả về key2address[_key - 1]; } } Liệt kê 2: Hợp đồng bộ nhớ đệm địa chỉ. hợp đồng Bạn bè là Địa chỉCache { ánh xạ (địa chỉ => địa chỉ []) bạn bè công khai; hàm addFriend(địa chỉ _friend) công khai { bạn bè[msg.sender].push(_friend); cacheWrite(_friend); } hàm addFriendWithCache(uint32 _friendKey) public { bạn bè[msg.sender].push(cacheRead(_friendKey)); } hàm getFriends() chế độ xem công khai trả về (địa chỉ [] bộ nhớ) { trả lại bạn bè[msg.sender];} } Liệt kê 3: Ví dụ về một hợp đồng kế thừa bộ đệm địa chỉ. Hợp đồng hỗ trợ trong bộ đệm khoảng 4 tỷ (232) địa chỉ và việc thêm một byte sẽ mang lại khoảng 1 nghìn tỷ (240). 4.2.2. Tối ưu hóa lưu trữ: Bộ lọc của Bloom Trên StarkNet có một số kỹ thuật để giảm thiểu mức sử dụng bộ nhớ. Nếu không cần thiết phải đảm bảo tính sẵn có của dữ liệu gốc thì chỉ cần lưu hash trên chuỗi của nó là đủ: cái này là cơ chế được sử dụng để lưu dữ liệu cho ERC-721 (NFT) [22], tức là liên kết IPFS giải quyết vấn đề hash dữ liệu nếu có. Đối với dữ liệu được lưu trữ nhiều lần, có thể sử dụng tra cứu bảng tương tự như hệ thống bộ nhớ đệm được giới thiệu cho Optimism, yêu cầu tất cả giá trị phải được lưu tại ít nhất một lần. Đối với một số ứng dụng, có thể tránh việc lưu tất cả các giá trị bằng cách sử dụng bộ lọc Bloom [23, 24, 25], tức là cấu trúc dữ liệu xác suất cho phép người ta biết chắc chắn liệu một phần tử không thuộc về một tập hợp nhưng thừa nhận một xác suất sai nhỏ nhưng không đáng kể tích cực. Bộ lọc Bloom được khởi tạo dưới dạng mảng 𝑚bit ở mức 0. Để thêm một phần tử, các hàm 𝑘hash với sự phân bố ngẫu nhiên đồng đều được sử dụng, mỗi ánh xạ tới một bit của mảng được đặt đến 1. Để kiểm tra xem một phần tử có thuộc tập hợp hay không, chúng tôi chạy các hàm 𝑘hash và xác minh rằng các 𝑘bit được đặt thành 1. Trong bộ lọc Bloom đơn giản, không có cách nào để phân biệt liệu một phần tử thực sự thuộc về tập hợp hoặc là dương tính giả, xác suất tăng theo số số mục tăng lên. Sau khi chèn phần tử 𝑛: P[dương tính giả] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 giả định tính độc lập của xác suất của mỗi tập hợp bit. Nếu 𝑛 phần tử (có kích thước tùy ý!) dự kiến sẽ được đưa vào và xác suất cho phép dương tính giả là 𝑝, kích thước của mảng có thể được tính như sau: 𝑚= −𝑛ln 𝑝 (ln 2)2 Trong khi số hàm hash tối ưu là: 𝑘= 𝑚 𝑛ln 2 Nếu chúng ta giả sử chèn 1000 phần tử với dung sai 1% thì kích thước của mảng là 9585 bit với 𝑘= 6, trong khi với dung sai 0,1%, nó trở thành 14377 bit với 𝑘= 9. Nếu một triệu phần tử dự kiến sẽ được chèn vào, kích thước của mảng sẽ trở thành khoảng 1170 kB cho 1% và 1775 kB cho 0,1%, có cùng giá trị 𝑘, vì nó chỉ phụ thuộc vào 𝑝[26]. Trong một trò chơi mà người chơi không được phân công vào đối thủ mà họ đã thách đấu, thay vì lưu vào bộ nhớ cho mỗi người chơi danh sách các đối thủ trong quá khứ, người ta có thể sử dụng Bloom bộ lọc. Rủi ro không thách thức một số người chơi thường có thể chấp nhận được và bộ lọc có thể được đặt lại định kỳ.4.3. Ethereum khả năng tương thích Ưu điểm chính của việc tương thích với EVM và Ethereum là sử dụng lại tất cả các tính năng có sẵn công cụ. Ethereum smart contracts có thể được xuất bản trên Optimism mà không cần sửa đổi hay các cuộc kiểm toán mới. Ví vẫn tương thích, các công cụ phát triển và phân tích tĩnh, phân tích chung công cụ, công cụ lập chỉ mục và oracle. Ethereum và Solidity có lịch sử lâu đời được nghiên cứu kỹ lưỡng các lỗ hổng bảo mật, chẳng hạn như các cuộc tấn công vào lại, tràn và tràn, flash loan và oracle thao tác. Vì điều này, Optimism đã có thể nắm bắt được một lượng lớn giá trị trong thời gian ngắn thời gian. Việc chọn sử dụng một máy ảo khác đồng nghĩa với việc phải xây dựng lại toàn bộ hệ sinh thái, với lợi thế là có quyền tự do thực hiện lớn hơn. StarkNet thực hiện tài khoản sự trừu tượng hóa, là một cơ chế trong đó mỗi tài khoản là một smart contract có thể triển khai logic tùy ý miễn là nó tuân thủ một giao diện (do đó có thuật ngữ trừu tượng): điều này cho phép việc sử dụng các sơ đồ chữ ký số khác nhau, khả năng thay đổi khóa riêng bằng cách sử dụng cùng một địa chỉ hoặc sử dụng multisig. Cộng đồng Ethereum đề xuất giới thiệu tính năng này cơ chế với EIP-2938 vào năm 2020, nhưng đề xuất này vẫn tồn tại hơn một năm vì các bản cập nhật khác được ưu tiên hơn [27]. Một lợi ích quan trọng khác thu được từ tính tương thích là khả năng sử dụng lại các ứng dụng khách hiện có: Optimism sử dụng một phiên bản geth cho nút riêng của nó chỉ với ∼800 dòng khác nhau, đã được được phát triển, thử nghiệm và duy trì từ năm 2014. Có một khách hàng mạnh mẽ là rất quan trọng vì nó xác định những gì được chấp nhận là hợp lệ hay không có trong mạng. Một lỗi trong việc thực hiện bằng chứng lỗi hệ thống có thể khiến bằng chứng không chính xác được chấp nhận là đúng hoặc bằng chứng chính xác cho một bằng chứng không hợp lệ khối được chấp nhận là không chính xác, làm tổn hại đến hệ thống. Khả năng xảy ra loại này cuộc tấn công có thể được hạn chế với sự đa dạng của khách hàng rộng hơn: Optimism có thể sử dụng lại ngoài việc lấy các ứng dụng khách Ethereum khác đã được duy trì và việc phát triển một ứng dụng khách khác dựa trên Erigon đang được tiến hành đã được tiến hành. Vào năm 2016, một vấn đề trong việc quản lý bộ nhớ của geth đã bị khai thác để Tấn công DoS và tuyến phòng thủ đầu tiên là khuyến nghị sử dụng Parity, tuyến phòng thủ thứ hai ứng dụng khách đã sử dụng tại thời điểm đó 5. StarkNet gặp phải vấn đề tương tự với bằng chứng hợp lệ, nhưng ứng dụng khách phải được viết từ đầu và hệ thống chứng minh phức tạp hơn nhiều, và do đó nó cũng phức tạp hơn nhiều để đảm bảo tính chính xác.

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.

Phần kết luận

Kết luận Rollups là giải pháp hứa hẹn nhất hiện nay để giải quyết vấn đề về khả năng mở rộng trong blockchains phi tập trung, mở đường cho kỷ nguyên blockchain mô-đun trái ngược với nguyên khối blockchains. Lựa chọn phát triển Tổng hợp lạc quan hoặc Tổng hợp hợp lệ chủ yếu được hiển thị như một sự đánh đổi giữa sự phức tạp và sự nhanh nhẹn. StarkNet có nhiều ưu điểm như nhanh rút tiền, cấu trúc không có khả năng chuyển đổi trạng thái không hợp lệ, chi phí giao dịch thấp hơn tại chi phí cho thời gian phát triển dài hơn và tính không tương thích với EVM, trong khi Optimism có tận dụng nền kinh tế mạng để nhanh chóng chiếm được thị phần lớn trên thị trường. Optimism Tuy nhiên, Bedrock sở hữu thiết kế mô-đun cho phép nó trở thành Hiệu lực 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Cập nhật trong tương lai: Cannon hiện đang sử dụng minigeth được biên dịch thành MIPS để kiểm tra lỗi của nó hệ thống, nhưng kiến trúc tương tự có thể được sử dụng để thu được một mạch điện và tạo ra các bằng chứng hợp lệ. Việc biên dịch một máy phức tạp như EVM cho một vi kiến trúc sẽ mang lại kết quả đơn giản hơn mạch không cần phải sửa đổi và xác minh lại trong trường hợp nâng cấp. RISC Zero là một vi kiến trúc có thể xác minh được với bằng chứng STARK đã được phát triển dựa trên RISC-V rằng có thể được sử dụng cho mục đích này thay thế cho MIPS [28]. Một khía cạnh không nên đánh giá thấp là sự phức tạp trong việc hiểu cách thức công nghệ hoạt động. Điểm mạnh của blockchain truyền thống là có thể xác minh trạng thái của blockchain mà không tin cậy bất kỳ thực thể bên thứ ba nào. Tuy nhiên, trong trường hợp StarkNet, đó là cần thiết phải tin tưởng vào việc triển khai khi không thể xác minh các thành phần khác nhau dựa trên mật mã và toán học nâng cao. Điều này ban đầu có thể tạo ra xích mích đối với việc áp dụng công nghệ, nhưng khi các công cụ và việc sử dụng bằng chứng về tính toàn vẹn ngày càng phát triển bên ngoài trường blockchain hy vọng vấn đề này sẽ được giải quyết.

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