الأوراق البيضاء مقالات الأشكال مسرد المصطلحات رسم بياني بحث

Optimism Teknik Dokümantasyonu

بقلم Optimism Collective · 2021

وضع فردي community.optimism.io

لا تمتلك Optimism ورقةً بيضاءَ تقليديةً. بوصفها rollup تفاؤلياً من الطبقة الثانية لـ Ethereum، يُوثَّق تصميمها ومواصفاتها من خلال الوثائق التقنية ومواصفات OP Stack ومنشورات البحث، بدلاً من ورقة أكاديمية رسمية واحدة.

🇺🇸 English (النص الأصلي)
🇹🇷 Türkçe (الترجمة)

خلاصة

تتناول هذه الورقة مشكلة قابلية التوسع في blockchains اللامركزية من خلال تحليل المفاضلة بين إنتاجية المعاملات ومتطلبات الأجهزة لتشغيل العقدة. يتم تقديم عمليات التجميع، أي تقنيات التحقق من الكتل المنفذة خارج السلسلة على السلسلة، في شكل أدلة خطأ أو صحة. نحن نقارن بين مجموعات متفائلة ومجموعات صلاحية فيما يتعلق بوقت السحب، وتكاليف المعاملات، وتقنيات التحسين، والتوافق مع النظام البيئي Ethereum. يكشف تحليلنا أن Optimism Bedrock لديه حاليًا معدل ضغط غاز يبلغ حوالي 20:1، بينما يحقق StarkNet معدل ضغط تكلفة كتابة تخزين يبلغ حوالي 24:1. نناقش أيضًا تقنيات تحسين هذه الأسعار بشكل أكبر، مثل استخدام عقود التخزين المؤقت ومرشحات Bloom. في نهاية المطاف، تسلط استنتاجاتنا الضوء على المفاضلات بين التعقيد وخفة الحركة في الاختيار بين مجموعة التفاؤل والصلاحية. الكلمات الرئيسية Blockchain، قابلية التوسع، التجميعية 1. مقدمة اكتسبت تقنية Blockchain اهتمامًا كبيرًا نظرًا لقدرتها على إحداث ثورة في مختلف الصناعات. ومع ذلك، لا تزال قابلية التوسع تمثل تحديًا كبيرًا، حيث تواجه معظم blockchain مقايضة بين قابلية التوسع واللامركزية والأمن، والتي يشار إليها عادةً باسم ثلاثية قابلية التوسع [1، 2]. لزيادة إنتاجية blockchain، الحل البسيط هو زيادة حجم الكتلة الخاصة بها. في سياق Ethereum، هذا يعني زيادة الحد الأقصى لكمية الغاز التي يمكن أن تحتويها الكتلة. نظرًا لأن كل عقدة كاملة يجب أن تتحقق من صحة كل معاملة لكل كتلة، ومع زيادة الإنتاجية، تزداد أيضًا متطلبات الأجهزة، مما يؤدي إلى مركزية أكبر للشبكة. تعمل بعض blockchain، مثل Bitcoin وEthereum، على تحسين تصميمها لتحقيق أقصى قدر من اللامركزية المعمارية، في حين تم تصميم البعض الآخر، مثل Binance Smart Chain وSolana، لتكون سريعة ورخيصة قدر الإمكان. تعمل الشبكات اللامركزية على الحد بشكل مصطنع من إنتاجية blockchain لتقليل متطلبات الأجهزة للمشاركة في الشبكة. على مر السنين، جرت محاولات لإيجاد حل للثلاثية، مثل القنوات الحكومية [3] والبلازما [4، 5]. تتميز هذه الحلول بخاصية نقل بعض الأنشطة خارج السلسلة، وربط النشاط الموجود على السلسلة بالنشاط خارج السلسلة باستخدام smart contracts، والتحقق من DLT 2023: ورشة العمل الخامسة لتكنولوجيا دفتر الأستاذ الموزع، 25-26 مايو 2023، بولونيا، إيطاليا $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 حقوق الطبع والنشر لهذه الورقة من قبل مؤلفيها. الاستخدام مسموح به بموجب ترخيص Creative Commons Attribution 4.0 International (CC BY 4.0). إجراءات ورشة عمل CEUR http://ceur-ws.org ISSN 1613-0073 إجراءات ورشة عمل CEUR (CEUR-WS.org) على السلسلة ما يحدث خارج السلسلة. ومع ذلك، فإن قنوات البلازما والقنوات الحكومية محدودة في دعمها للقنوات العامة smart contract. المجموعات المجمعة هي blockchains (تسمى Layer 2 أو L2) تنشر كتلها على blockchain أخرى (Layer 1 أو L1) وبالتالي ترث خصائص الإجماع وتوافر البيانات والأمان. وهي، على عكس الحلول الأخرى، تدعم الحساب التعسفي. تحتوي المجموعات المجمعة على ثلاثة مكونات رئيسية: • أجهزة التسلسل: العقد التي تتلقى معاملات التجميع من المستخدمين ودمجها في كتلة يتم إرسالها إلى Layer 1. تتكون الكتلة على الأقل من جذر الحالة (على سبيل المثال، جذر Merkle) والبيانات اللازمة لإعادة بناء الحالة والتحقق من صحتها. يحدد 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...

مقدمة

  1. مقدمة لقد اكتسبت تقنية Blockchain اهتمامًا كبيرًا نظرًا لقدرتها على إحداث ثورة الصناعات المختلفة. ومع ذلك، تظل قابلية التوسع تحديًا كبيرًا، كما يواجه معظم blockchains وهي مقايضة بين قابلية التوسع واللامركزية والأمن، والتي يشار إليها عادة باسم معضلة قابلية التوسع [1، 2]. لزيادة إنتاجية blockchain، الحل التافه هو لزيادة حجم الكتلة الخاصة به. في سياق Ethereum، هذا يعني زيادة الحد الأقصى كمية الغاز التي يمكن أن تحتويها الكتلة. حيث يجب على كل عقدة كاملة التحقق من صحة كل معاملة لكل عقدة كتلة، مع زيادة الإنتاجية، تزداد أيضًا متطلبات الأجهزة، مما يؤدي إلى زيادة مركزية الشبكة. تعمل بعض blockchains، مثل Bitcoin وEthereum على تحسين التصميم لتحقيق أقصى قدر من اللامركزية المعمارية، في حين أن البعض الآخر، مثل Binance Smart تم تصميم Chain وSolana ليكونا سريعين ورخيصين قدر الإمكان. الشبكات اللامركزية الحد بشكل مصطنع من إنتاجية blockchain لخفض متطلبات الأجهزة المشاركة في الشبكة. على مر السنين، جرت محاولات لإيجاد حل للثلاثية، مثل الدولة القنوات [3] والبلازما [4، 5]. وتتميز هذه الحلول بخاصية تحريك بعض النشاط خارج السلسلة، وربط النشاط الموجود على السلسلة بالنشاط خارج السلسلة باستخدام smart contracts، والتحقق DLT 2023: ورشة العمل الخامسة لتكنولوجيا دفتر الأستاذ الموزع، 25-26 مايو 2023، بولونيا، إيطاليا $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (ل. دونو) 0000-0001-9221-3529 (ل. دونو) © 2023 حقوق الطبع والنشر لهذه الورقة من قبل مؤلفيها. الاستخدام مسموح به بموجب ترخيص Creative Commons Attribution 4.0 International (CC BY 4.0). CEUR ورشة عمل الإجراءات http://ceur-ws.org ISSN 1613-0073 وقائع ورشة عمل CEUR (CEUR-WS.org)على السلسلة ما يحدث خارج السلسلة. ومع ذلك، فإن قنوات البلازما وقنوات الدولة محدودة دعمهم لـ smart contracts العامة. المجموعات المجمعة هي blockchains (تسمى Layer 2 أو L2) تنشر كتلها على blockchain آخر (Layer 1 أو L1) وبالتالي ترث خصائص الإجماع وتوافر البيانات والأمان الخاصة بها. هم، على عكس الحلول الأخرى، دعم الحساب التعسفي. تحتوي المجموعات المجمعة على ثلاثة مكونات رئيسية: • التسلسل: العقد التي تتلقى المعاملات المجمعة من المستخدمين ودمجها في ملف الكتلة التي يتم إرسالها إلى Layer 1. تتكون الكتلة من جذر الحالة على الأقل (على سبيل المثال Merkle root) والبيانات اللازمة لإعادة بناء الحالة والتحقق من صحتها. يحدد Layer 1 الكنسي blockchain للL2 من خلال تحديد ترتيب البيانات المنشورة. • العقد المجمعة الكاملة: العقد التي تحصل على الكتل المجمعة وتعالجها وتتحقق من صحتها من الطبقة 1 عن طريق التحقق من صحة الجذر. إذا كانت الكتلة تحتوي على معاملات غير صالحة، فهذا هو الحال تم تجاهلها، مما يمنع أجهزة التسلسل من إنشاء كتل صالحة تتضمن غير صالحة المعاملات. • العقد الخفيفة التراكمية: العقد التي تحصل على الكتل التراكمية من Layer 1 ولكنها لا تقوم بالحساب الدولة الجديدة نفسها. يتحققون من أن جذر الحالة الجديد صالح باستخدام التقنيات مثل إثبات الخطأ أو الصحة. تحقق المجموعات المجمعة قابلية التوسع من خلال تقليل التكلفة المطفأة للمعاملات كعدد من المستخدمين يزيد. وذلك لأن تكلفة ضمان صلاحية blockchain تنمو بشكل خطي فرعي فيما يتعلق بتكلفة التحقق من المعاملات بشكل فردي. تختلف المجموعات حسب الآلية التي يتم من خلالها التأكد من صحة تنفيذ المعاملة في العقد الخفيفة: في يتم ضمان التراكمات المتفائلة من خلال النموذج الاقتصادي وإثباتات الخطأ، أثناء الصلاحية يتم ضمان المجموعات المجمعة بشكل مشفر باستخدام أدلة الصلاحية. يمكن تنفيذ العقد الخفيفة كـ smart contracts على Layer 1. يقبلون جذر حالة جديدة والتحقق من الصلاحية أو إثبات الأخطاء: لذلك تسمى هذه التحديثات بالعقد الذكي مجموعات. إذا كانت العقد الضوئية مستقلة، فإنها تسمى مجموعة Sovereign Rollups [6]. ميزة إن استخدام مجموعة العقود الذكية هو القدرة على بناء جسر ثقة بين الاثنين blockchains: بما أنه تم إثبات صحة حالة L2 إلى L1، فإن نظام المعاملات من يمكن تنفيذ L2 إلى L1، مما يسمح بالسحب. العيب هو أن تكلفة تعتمد المعاملات على تكلفة التحقق من الحالة على L1: إذا كانت الطبقة الأساسية مشبعة والأنشطة الأخرى، فإن تكلفة المعاملات في مجموعة التحديثات تزيد أيضًا. طبقات البيانات والإجماع هي التي تحدد أمان النظام فهي تحدد ترتيب المعاملات، وتمنع الهجمات، وتتيح البيانات لإثبات الحالة صلاحية. المساهمة الورقية في هذا البحث، قمنا بدراسة مجموعتي التفاؤل والصدق، وهما مبتكران حلول ثلاثية قابلية التوسع، مع التركيز على التطبيقات البارزة، مثل Optimism Bedrock وStarkNet. تتضمن مساهماتنا مقارنة شاملة لهذه الحلول وتحليل أوقات السحب ومناقشة الهجوم المحتمل على Optimism حجر الأساس. بالإضافة إلى ذلك، نقوم بحساب نسب ضغط الغاز الخاصة بها، وتوفير تحسينات خاصة بالتطبيقات، وتقديم مزايا وعيوب الابتعاد عن Ethereum الجهاز الظاهري (EVM).

هيكل الورق يتم تنظيم الورقة على النحو التالي. في القسم 2 التراكمية المتفائلة هي تم تقديمه من خلال تحليل Optimism حجر الأساس. في القسم 3، يتم تقديم مجموعات الصلاحية بواسطة تحليل StarkNet. في القسم 4 نقارن بين الحلين. وأخيرا، في القسم 5 نرسم بعض الاستنتاجات.

giriiş

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

التراكمات المتفائلة

  1. مجموعات متفائلة إن فكرة القبول المتفائل لمخرجات الكتل دون التحقق من تنفيذها هي موجودة بالفعل في Bitcoin المستند التقني [7]، الذي يناقش العقد الضوئية. هذه العقد تتبع فقط سلسلة الرأس عن طريق التحقق من قاعدة الإجماع، مما يجعلها عرضة لقبول الكتل تحتوي على معاملات غير صالحة في حالة حدوث هجوم بنسبة 51%. يقترح ناكاموتو حل هذه المشكلة حل المشكلة باستخدام نظام "تنبيه" لتحذير العقد الخفيفة من أن الكتلة تحتوي على معاملات غير صالحة. هذه الآلية يطبقها لأول مرة البسام وسونينو وبوتيرين [8] فيها خطأ يتم استخدام نظام إثبات يعتمد على رموز تصحيح الأخطاء [9]. من أجل تمكين إنشاء إثباتات الأخطاء، من الضروري أن تكون البيانات من جميع الكتل، بما في ذلك الكتل غير الصالحة، متاحة لـ الشبكة: وهي مشكلة توفر البيانات، والتي يتم حلها باستخدام البيانات الاحتمالية آلية أخذ العينات. أول تصميم متفائل تم تقديمه بواسطة جون أدلر و Mikerah Quintyne-Collins في عام 2019 [10]، حيث يتم نشر الكتل على blockchain آخر الذي يحدد إجماعهم على الطلب. 2.1. Optimism حجر الأساس Bedrock [11] هو أحدث إصدار من Optimism، مجموعة العقود الذكية. الإصدار السابق، تتطلب الآلة الافتراضية المتفائلة (OVM) مترجمًا مخصصًا لتجميع Solidity في نظامها رمز البايت الخاص: في المقابل، فإن Bedrock يعادل تمامًا EVM من حيث محرك التنفيذ يتبع Ethereum مواصفات الورق الأصفر [12]. 2.1.1. الودائع يمكن للمستخدمين إيداع المعاملات من خلال عقد على Ethereum، بوابة Optimism، عن طريق استدعاء وظيفة الإيداع. عند تنفيذ المعاملة، أ يتم إطلاق حدث TransactionDeposited، والذي تستمع إليه كل عقدة في مجموعة التحديثات لمعالجته الودائع. المعاملة المودعة هي معاملة L2 مشتقة من L1. إذا كان المتصل الوظيفة عقد، يتم تحويل العنوان بإضافة قيمة ثابتة إليه: وهذا يمنع الهجمات التي يكون فيها العقد الموجود على L1 له نفس عنوان العقد الموجود على L2 ولكن برمز مختلف. يتم ضمان التضمين في L2 للمعاملة المودعة من خلال المواصفات ضمن التسلسل نافذة. المعاملات المودعة هي نوع معاملة جديد متوافق مع EIP-2718 [13] مع البادئة 0x7E، حيث تكون الحقول المشفرة بـ rlp: • bytes32 sourceHash: hash الذي يحدد مصدر المعاملة بشكل فريد. • العنوان من : عنوان المرسل . • العنوان إلى: عنوان المستلم، أو العنوان الصفري إذا كانت المعاملة المودعة هي a إنشاء العقد.• uint256 mint: القيمة التي سيتم إنشاؤها على L2. • قيمة uint256: القيمة التي سيتم إرسالها إلى المستلم. • بايتات البيانات: بيانات الإدخال. • BytesgasLimit: حد الغاز للمعاملة. يتم حساب 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، هناك 𝑛epoch مناظر. كل عصر يحتوي على واحد على الأقل كتلة، وكل كتلة في حقبة تحتوي على معاملة L1 المودعة. الكتلة الأولى في عصر ما يحتوي على جميع المعاملات المودعة من خلال البوابة. قد يتم أيضًا حظر Layer 2 تحتوي على معاملات متسلسلة، أي المعاملات المرسلة مباشرة إلى جهاز التسلسل. يقبل جهاز التسلسل المعاملات من المستخدمين ويبني الكتل. لكل كتلة، فإنه يبني دفعة سيتم نشرها في Ethereum. يمكن نشر عدة دفعات بشكل مضغوط، أخذ اسم القناة. يمكن تقسيم القناة إلى عدة إطارات، إذا كانت كبيرة جدًا معاملة واحدة. يتم تعريف القناة على أنها الضغط باستخدام ZLIB [15] لـ rlp المشفر دفعات. حقول الدُفعة هي رقم العصر، العصر hash، الأصل hash، الطابع الزمني وقائمة المعاملات. تحتوي نافذة التسلسل، التي يتم تحديدها بواسطة عصر ما، على رقم ثابت 𝑤من L1 المتتالي الكتل التي تأخذها خطوة الاشتقاق كمدخل لإنشاء عدد متغير من كتل L2. ل في العصر 𝑛، تتضمن نافذة التسلسل 𝑛 الكتل [𝑛، 𝑛+𝑤). وهذا يعني أن الترتيب لا يتم إصلاح معاملات L2 والكتل داخل نافذة التسلسل حتى تنتهي النافذة. تُسمى المعاملة rollup بأنها آمنة إذا تم تأكيد الدفعة التي تحتوي عليها على L1. إطاراتتتم قراءتها من كتل L1 لإعادة بناء الدُفعات. التنفيذ الحالي لا يسمح يبدأ ضغط القناة حتى يتم استقبال جميع الإطارات المقابلة. غير صالح يتم تجاهل الدفعات. يتم الحصول على معاملات الكتلة الفردية من الدُفعات يستخدمه محرك التنفيذ لتطبيق انتقالات الحالة والحصول على حالة الإظهار. 2.1.3. عمليات السحب من أجل معالجة عمليات السحب، يتم تطبيق نظام المراسلة من L2 إلى L1. Ethereum يحتاج إلى معرفة حالة L2 لقبول عمليات السحب، ويتم ذلك عن طريق النشر في Oracle Output L2 smart contract على L1 جذر الحالة لكل كتلة L2. هذه الجذور يتم قبولها بشكل متفائل على أنها صالحة (أو نهائية) إذا لم يتم إجراء إثبات خطأ أثناء فترة النزاع. يمكن فقط للعناوين المعينة كمقترحين نشر جذور المخرجات. الصلاحية يتم تحفيز جذور الإنتاج من خلال مطالبة مقدمي العروض بإيداع حصة يتم قطعها إذا قاموا بذلك تبين أنه اقترح جذرًا غير صالح. تبدأ المعاملات عن طريق استدعاء الدالة قم ببدء السحب عند النشر المسبق على L2 ثم تم الانتهاء منه على L1 عن طريق استدعاء الوظيفة FinalizeWithdrawalTransaction على بوابة Optimism المذكورة سابقًا. يتم الحصول على جذر الإخراج المقابل لكتلة L2 من L2 Output Oracle؛ إنه كذلك التحقق من أنه تم الانتهاء منه، أي أن فترة النزاع قد انقضت؛ تم التحقق من أن الإخراج يتطابق إثبات الجذر مع Oracle Proof؛ تم التحقق من تضمين hash الخاص بالسحب فيه باستخدام إثبات السحب؛ وأن الانسحاب لم يتم الانتهاء منه بالفعل؛ ومن ثم يتم تنفيذ الاتصال بالعنوان المستهدف، مع حد الغاز المحدد وكمية الأثير والبيانات. 2.1.4. المدفع: نظام إثبات الخطأ إذا اكتشفت عقدة التجميع الكاملة ذلك، من خلال تنفيذ الدفعات والمعاملات المودعة محليًا الحالة Layer 2 لا تتطابق مع جذر الحالة المنشور على السلسلة بواسطة مقدم العرض، ويمكن تنفيذها دليل خطأ على L1 لإثبات أن نتيجة انتقال الكتلة غير صحيحة. بسبب بشكل عام، تعد معالجة كتلة القيمة المحتسبة بالكامل على L1 مكلفة للغاية. تم تنفيذ الحل بواسطة Bedrock هو تنفيذ التعليمات الأولى للخلاف في minigeth على السلسلة فقط، تجميعها في بنية MIPS التي يتم تنفيذها على مترجم على السلسلة ونشرها على L1. minigeth هو نسخة مبسطة من geth 1 حيث يتم تضمين الإجماع وRPC وقاعدة البيانات تمت إزالتها. للعثور على تعليمات الخلاف الأولى، يتم إجراء بحث ثنائي تفاعلي بين الشخص الذي بدأ إثبات الخطأ والذي نشر جذر الإخراج. عندما يكون الدليل يبدأ كلا الطرفين بنشر جذر حالة الذاكرة MIPS في منتصف عملية التنفيذ الحظر في عقد التحدي: إذا كان hash يتطابق فهذا يعني أن الطرفين يتفقان على النصف الأول من التنفيذ وبذلك ينشر جذر نصف النصف الثاني، وإلا النصف يتم نشر النصف الأول وهكذا. إن القيام بذلك يحقق التعليمات الأولى للخلاف في عدد لوغاريتمي من الخطوات مقارنة بالتنفيذ الأصلي. فإذا توقف أحد الأمرين التفاعل، في نهاية فترة النزاع، يفوز المشارك الآخر تلقائيًا. لمعالجة التعليمات، يحتاج المترجم MIPS إلى الوصول إلى ذاكرته: نظرًا لأن الجذر هو المتاحة، يمكن نشر خلايا الذاكرة اللازمة عن طريق إثبات إدراجها. للوصول حالة EVM، يتم استخدام Preimage Oracle: بالنظر إلى hash للكتلة التي يتم إرجاعها 1https://geth.ethereum.org/docs

رأس الكتلة، والذي يمكن من خلاله الحصول على hash من الكتلة السابقة والعودة إلى chain، أو احصل على hash للحالة والسجلات التي يمكن من خلالها الحصول على الصورة الأولية. oracle يتم تنفيذه بواسطة Minigeth ويحل محل قاعدة البيانات. يتم إجراء الاستعلامات إلى العقد الأخرى ل الحصول على الصور الأولية.

İyimser Toplamalar

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

تراكمات الصلاحية

  1. مجموعات الصلاحية الهدف من مجموعة الصلاحية هو إثبات صحة انتقال الحالة بشكل مشفر نظرا لتسلسل المعاملات مع برهان قصير يمكن التحقق منه خطيا مقارنة إلى وقت الحسابات الأصلية. يُطلق على هذا النوع من الشهادات اسم إثباتات التكامل الحسابي ويتم تنفيذها عمليًا باستخدام SNARKs (وسيطة المعرفة غير التفاعلية المختصرة)، والتي تستخدم العمليات الحسابية الدوائر كنموذج حسابي لها. تختلف تطبيقات SNARK المختلفة في وقت الإثبات، وقت التحقق، والحاجة إلى إعداد موثوق به ومقاومة كمية [16، 17]. ستاركس (قابلة للتطوير حجة المعرفة الشفافة) [18] هي نوع من SNARKs التي لا تتطلب وسيطًا موثوقًا به الإعداد ومقاومة الكم، مع التخلي عن بعض الكفاءة في الإثبات والتحقق مقارنة بالحلول الأخرى. 3.1. StarkNet StarkNet عبارة عن مجموعة من صلاحية العقد الذكي تم تطويرها بواسطة StarkWare والتي تستخدم STARK نظام إثبات للتحقق من صحة حالته إلى Ethereum. لتسهيل بناء أدلة الصحة، أ يتم استخدام جهاز افتراضي مختلف عن EVM، ولغته عالية المستوى هي القاهرة. 3.1.1. الودائع يمكن للمستخدمين إيداع المعاملات عبر عقد على Ethereum عن طريق الاتصال بـ sendMessageToL2 وظيفة. يتم تسجيل الرسالة عن طريق حساب hash وزيادة العداد. التسلسل استمع إلى حدث LogMessageToL2 وقم بتشفير المعلومات في معاملة StarkNet يستدعي وظيفة العقد الذي يحتوي على ديكور l1_handler. وفي نهاية التنفيذ، عندما يتم إنتاج إثبات انتقال الحالة، يتم إرفاق استهلاك الرسالة به ويتم حذفه بتقليل عداده. إن إدراج المعاملات المودعة ليس مطلوبًا بموجب مواصفات StarkNet، لذا فهو غاز هناك حاجة إلى السوق لتحفيز التسلسلات لنشرها على L2. في الإصدار الحالي، لأن يتم التحكم في جهاز التسلسل بشكل مركزي وإدارته بواسطة StarkWare، وهي تكلفة المعاملات المودعة يتم تحديده فقط من خلال تكلفة تنفيذ الإيداع. يتم دفع هذه التكلفة عن طريق إرسال ETH إلى sendMessageToL2. تظل هذه الإثيرات مقفلة على L1 ويتم نقلها إلى جهاز التسلسل L1، عندما يتم تضمين المعاملة المودعة في انتقال الحالة. مبلغ ETH المرسل، إذا يتم تضمين المعاملة المودعة، وإنفاقها بالكامل، بغض النظر عن كمية الغاز المستهلكة على L2. لا يحتوي StarkNet على نظام يجعل سمات كتلة L1 متاحة تلقائيًا. وبدلاً من ذلك، فإن Fossil هو بروتوكول تم تطويره بواسطة Oiler Network 2 والذي يسمح، بالنظر إلى hash من منع أي معلومات يمكن الحصول عليها من Ethereum عن طريق نشر الصور الأولية. 2https://www.oiler.network/3.1.2. التسلسل يمكن اشتقاق الحالة الحالية لـ StarkNet بالكامل من Ethereum. أي اختلاف الدولة يتم نشر بين التحولات على L1 كبيانات الاتصال. يتم نشر الاختلافات لكل عقد ويتم حفظها كـ uint256[] بالتشفير التالي: • عدد الحقول المتعلقة بعمليات نشر العقد. • لكل عقد منشور: – عنوان العقد المنشور. – hash للعقد المنشور. – عدد حجج منشئ العقد.
  2. قائمة وسيطات المنشئ • عدد العقود التي تم تعديل تخزينها. • لكل عقد تم تعديله: – عنوان العقد المعدل. – عدد تحديثات التخزين.
  3. أزواج القيمة الرئيسية لعناوين التخزين مع القيم الجديدة. يتم نشر اختلافات الحالة بالترتيب، لذلك يكفي قراءتها بالتسلسل إعادة بناء الدولة. 3.1.3. عمليات السحب لإرسال رسالة من L2 إلى L1، يتم استخدام syscall send_message_to_L1. الرسالة هي تم نشره إلى L1 عن طريق زيادة عداد hash مع الدليل وتم الانتهاء منه عن طريق استدعاء الدالة ConsumerMessageFromL2 على StarkGate smart contract على L1، مما يتناقص العداد. يمكن لأي شخص وضع اللمسات الأخيرة على أي انسحاب. 3.1.4. إثباتات الصلاحية تم تصميم جهاز القاهرة الافتراضي [19] لتسهيل إنشاء براهين ستارك. تسمح لغة القاهرة بوصف العمليات الحسابية ببرمجة عالية المستوى اللغة، وليس مباشرة كدائرة. يتم تحقيق ذلك من خلال نظام المعادلات متعددة الحدود 3 يمثل حسابًا واحدًا: دورة FDE لهندسة فون نيومان. الرقم وبالتالي فإن القيود ثابتة ومستقلة عن نوع الحساب، مما يسمح بواحد فقط برنامج التحقق لكل برنامج يحتاج إلى إثبات حسابه. يقوم StarkNet بتجميع معاملات متعددة في دليل STARK واحد باستخدام مُثبت مشترك اسمه شارب. يتم إرسال البراهين إلى smart contract على Ethereum، والذي يتحقق من صحتها ويقوم بتحديث جذر Merkle المطابق للحالة الجديدة. التكلفة الخطية الفرعية للتحقق أ يسمح إثبات الصلاحية بإطفاء تكلفته على معاملات متعددة. 3 يسمى التمثيل الجبري المتوسط ​​(AIR)

Geçerlilik Toplamaları

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

مقارنة

  1. المقارنة 4.1. وقت الانسحاب الجانب الأكثر أهمية الذي يميز مجموعات التفاؤل عن مجموعات الصلاحية هو الوقت المنقضي بين بدء عملية الانسحاب ووضع اللمسات النهائية عليها. في كلتا الحالتين، تتم تهيئة عمليات السحب على L2 والانتهاء منها على L1. في StarkNet، يمكن الانتهاء من ذلك بمجرد قبول إثبات صحة جذر الحالة الجديد في Ethereum: من الناحية النظرية، فهو كذلك من الممكن سحب الأموال في المجموعة الأولى من L1 بعد التهيئة. في الممارسة العملية، تردد إرسال إثباتات الصلاحية على Ethereum عبارة عن مفاضلة بين سرعة البلوك وضع اللمسات النهائية وتجميع الأدلة. يوفر StarkNet حاليًا أدلة صحة للتحقق كل 10 ساعات 4، ولكن المقصود أن تنخفض مع زيادة نشاط المعاملات. في Optimism Bedrock من الممكن إنهاء الانسحاب فقط في نهاية النزاع (حاليًا 7 أيام)، وبعدها يعتبر الجذر صالحًا تلقائيًا. طول يتم تحديد هذه الفترة بشكل أساسي من خلال حقيقة أنه يمكن فرض الرقابة على أدلة الأخطاء على Ethereum حتى نهايتها. تتناقص احتمالية نجاح هذا النوع من الهجمات بشكل كبير مع مرور الوقت: ه[القيمة المطروحة] = 𝑉𝑝𝑛 حيث 𝑛 هو عدد الكتل في الفترة، و𝑉 هو مقدار الأموال التي يمكن طرحها عن طريق نشر جذر غير صالح، و𝑝 هو احتمال إجراء الرقابة بنجاح الهجوم في كتلة واحدة. لنفترض أن هذا الاحتمال هو 99%، أن القيمة مؤمنة في التراكمي هو مليون إيثر، وأن الكتل في فترة زمنية هي 1800 (6 ساعات من الكتل مع 12 الفاصل الزمني للثواني): القيمة المتوقعة هي حوالي 0.01391 إيثر. أصبح النظام آمنًا بواسطة مطالبة مقدمي العروض بالحصول على كمية أكبر بكثير من الأثير من القيمة المتوقعة. وينزر وآخرون. أظهر كيفية تنفيذ هجوم الرقابة باستخدام smart contract بسيط يضمن عدم تغيير مناطق معينة من الذاكرة في الحالة [20]. نمذجة الهجوم باعتبارها لعبة ماركوف، توضح الورقة أن الرقابة هي الإستراتيجية السائدة للعقلانية منتج الكتلة إذا حصل على تعويض أكبر من تضمين المعاملة التي تتغير الذاكرة. يمكن اعتبار قيمة 𝑝‏ التي تمت مناقشتها أعلاه كنسبة مئوية من الكتلة النسبية المنتجين في الشبكة، حيث "العقلاني" لا يأخذ بعين الاعتبار احتمال معاقبة العوامل الخارجية، مثل انخفاض الثقة في blockchain مما يقلل من قيمة العملة المشفرة الخاصة بها. يقدم الكود التالي smart contract الذي يمكن استخدامه لتنفيذ هجوم الرقابة على حجر الأساس. يستغل الهجوم حوافز منتجي الكتل من خلال تقديم رشوة لهم فرض رقابة على المعاملات التي من شأنها تعديل أجزاء معينة من الدولة. العقد الرئيسي تسمح وظيفة "المطالبة بالرشوة" لمنتجي الكتل بالمطالبة بالرشوة إذا نجحوا في فرض الرقابة المعاملة المستهدفة عن طريق التحقق من عدم لمس جذر الإخراج غير الصالح. وظيفة المطالبةBribe (بايت تخزين الذاكرة) خارجي { require(!claimed[block.number], "تم المطالبة بالرشوة بالفعل"); تيار الذاكرة OutputProposal = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, إثبات التخزين)؛ يتطلب (invalidOutputRoot == current.outputRoot، "فشل الهجوم")؛ ادعى[block.number] = صحيح؛ (تم إرسال المنطق،) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4يتطلب (أرسل، "فشل في إرسال الأثير")؛ } القائمة 1: مثال على عقد يحفز هجوم الرقابة على Bedrock. يجب أن يأخذ طول فترة النزاع أيضًا في الاعتبار حقيقة وجود دليل على الخطأ دليل تفاعلي وبالتالي يجب توفير الوقت الكافي للمشاركين للتفاعل وأن أي تفاعل يمكن أن يخضع للرقابة. إذا حدثت الخطوة الأخيرة في وقت قريب جدًا من وفي نهاية فترة النزاع، تكون تكلفة الرقابة أقل بكثير. على الرغم من أن الرقابة هي الإستراتيجية المهيمنة، فإن احتمالية النجاح أقل لأن عقد الرقابة معرضة للخطر هجمات رفض الخدمة: يمكن للمهاجم إنشاء معاملات معقدة للغاية تنتهي بـ نشر إثبات الخطأ دون أي تكلفة، حيث لن يتم دفع أي رسوم. وفي الحالات القصوى، تسمح فترة النزاع الطويلة بالتنسيق في حالة نجاحه هجوم الرقابة لتنظيم شوكة واستبعاد منتجي الكتلة المهاجمين. آخر يتمثل الهجوم المحتمل في نشر مقترحات لجذر الدولة أكثر مما يستطيع المتنازعون التحقق منه، والتي يمكن تجنبها باستخدام حد التردد. 4.1.1. انسحابات متفائلة سريعة نظرًا لأنه يمكن التحقق من صحة مجموعة التحديثات المتفائلة في أي وقت بواسطة أي عقدة كاملة، أ يمكن استخدام oracle الموثوق به لمعرفة ما إذا كان من الممكن إنهاء السحب بأمان على L1. هذا تم اقتراح الآلية لأول مرة بواسطة Maker [21]: يتحقق oracle من السحب، وينشر النتيجة على L1 حيث يتم تعيين قرض بفائدة للمستخدم، والذي يتم تلقائيًا يتم إغلاقه في نهاية 7 أيام، أي عندما يمكن الانتهاء من السحب فعليًا. هذا الحل يقدم افتراض الثقة، ولكن في حالة Maker يتم تصغيره نظرًا لأن عامل التشغيل oracle تتم إدارته من قبل نفس المنظمة التي تتحمل المخاطر من خلال تقديم القرض. 4.2. تكاليف المعاملات يتم تحديد تكلفة معاملات المستوى الثاني في الغالب من خلال التفاعل مع المستوى الأول. في كلا الحلين التكلفة الحسابية للمعاملات رخيصة جدًا حيث يتم تنفيذها بالكامل خارج السلسلة. Optimism ينشر بيانات استدعاء معاملات L2 كبيانات استدعاء ونادرًا (أو لا ينفذ أبدًا) الخطأ البراهين، وبالتالي فإن بيانات الاتصال هي المورد الأكثر تكلفة. في 12 يناير 2022 شبكة بيدروك تم إطلاقه على شبكة اختبار Goerli الخاصة بـ Ethereum. يمكن حساب معدل ضغط الغاز من خلال تتبع كمية الغاز المستخدمة في حجر الأساس في فترة معينة ومقارنتها مع كمية الغاز المستهلكة على L1 للكتل المقابلة. باستخدام هذه الطريقة ضغط الغاز تم العثور على معدل ∼20 : 1، ولكن هذا الرقم قد يختلف مع النشاط الحقيقي على الشبكة الرئيسية. StarkNet ينشر في Ethereum كل تغيير في حالة L2 كبيانات اتصال، وبالتالي فإن التخزين أغلى الموارد. نظرًا لأن الشبكة لا تستخدم EVM، فستكون تكلفة المعاملة لا يمكن تقدير الضغط بشكل تافه. من خلال افتراض تكلفة التنفيذ وبيانات الاتصال تكون ضئيلة، فمن الممكن لحساب نسبة ضغط الكتابة التخزين مقارنة L1. بافتراض عدم نشر أي عقد و10 خلايا لم يتم الوصول إليها مسبقًا على StarkNet تم تعديله، وتم العثور على معدل ضغط تكلفة كتابة التخزين يبلغ ∼ 24: 1. إذا تم الكتابة فوق الخلية 𝑛مرات بين عمليات نشر البيانات، ستكون تكلفة كل عملية كتابة 1/𝑛مقارنة بالتكلفة من كتابة واحدة، حيث يتم نشر آخر واحد فقط. يمكن تقليل التكلفة بشكل أكبر من خلالضغط القيم المستخدمة بشكل متكرر. وتنقسم تكلفة التحقق من صحة إثبات بين المعاملات التي يشير إليها: على سبيل المثال، StarkNet الكتلة 4779 تحتوي على 200 معاملة و إثبات الصلاحية يستهلك 267830 وحدة غاز، أو 1339.15 غاز لكل معاملة. 4.2.1. تحسين بيانات الاتصال: عقد ذاكرة التخزين المؤقت الموضح أدناه هو smart contract الذي يقوم بتنفيذ ذاكرة تخزين مؤقت للعناوين للاستخدام المتكرر العناوين من خلال الاستفادة من حقيقة أن التخزين والتنفيذ أقل تكلفة بكثير الموارد، إلى جانب عقد الأصدقاء الذي يوضح استخدامه. هذا الأخير يتتبع "أصدقاء" لعنوان يمكن تسجيله عن طريق استدعاء وظيفة addFriend. إذا كان عنوان تم استخدامه بالفعل مرة واحدة على الأقل، ويمكن إضافته عن طريق استدعاء addFriendWithCache الوظيفة: مؤشرات ذاكرة التخزين المؤقت هي أعداد صحيحة مكونة من 4 بايت بينما يتم تمثيل العناوين بـ 20 بايت، لذلك هناك توفير بنسبة 5:1 في وسيطة الوظيفة. يمكن استخدام نفس المنطق للبيانات الأخرى أنواع مثل الأعداد الصحيحة أو البايتات بشكل عام. العقد AddressCache { تعيين (عنوان => uint32) عنوان عام 2key؛ العنوان[] المفتاح العام2عنوان; وظيفة ذاكرة التخزين المؤقت (العنوان _address) العوائد الداخلية (uint32) { require(key2address.length < type(uint32).max, "AddressCache: ذاكرة التخزين المؤقت ممتلئة"); require(address2key[_address] == 0, "AddressCache: العنوان مخبأ بالفعل"); // يجب أن تبدأ المفاتيح من 1 لأن 0 يعني "لم يتم العثور عليها" مفتاح uint32 = uint32(key2address.length + 1); Address2key[_address] = key; key2address.push(_address); مفتاح العودة؛ } وظيفة ذاكرة التخزين المؤقت قراءة (uint32 _key) إرجاع العرض العام (العنوان) { require(_key <= key2address. length && _key > 0, "AddressCache: لم يتم العثور على المفتاح"); إرجاع عنوان المفتاح2[_key - 1]; } } القائمة 2: عنوان عقد التخزين المؤقت. أصدقاء العقد هو AddressCache { تعيين (العنوان => العنوان []) الأصدقاء العامين؛ وظيفة addFriend(address _friend) عامة { friends[msg.sender].push(_friend); ذاكرة التخزين المؤقت(_friend); } وظيفة addFriendWithCache(uint32 _friendKey) عامة { friends[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]، أي بنية بيانات احتمالية تسمح للمرء أن يعرف على وجه اليقين ما إذا كان لا ينتمي العنصر إلى مجموعة ولكنه يعترف باحتمالية خطأ صغيرة ولكن لا يمكن إهمالها إيجابيات. تتم تهيئة مرشح Bloom كمصفوفة مكونة من 𝑚bits عند الصفر. لإضافة عنصر، استخدم الدالة 𝑘hash مع توزيع عشوائي موحد، يتم تعيين كل منها إلى جزء صغير من المصفوفة التي تم تعيينها إلى 1. للتحقق مما إذا كان العنصر ينتمي إلى المجموعة نقوم بتشغيل الوظائف 𝑘hash والتحقق أن قيمة 𝑘bits مضبوطة على 1. في مرشح بلوم البسيط، لا توجد طريقة للتمييز ما إذا كان ينتمي العنصر فعليًا إلى المجموعة أو يكون نتيجة إيجابية كاذبة، وهو احتمال ينمو كرقم من الإدخالات يزيد. بعد إدخال 𝑛العناصر: ف[إيجابية كاذبة] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 بافتراض استقلالية احتمالية كل مجموعة بت. إذا كان عدد 𝑛 من العناصر (ذات حجم عشوائي!) موجودًا من المتوقع أن يتم تضمينها، واحتمال وجود نتيجة إيجابية كاذبة مسموح بها هو 𝑝، وهو حجم المصفوفة يمكن حسابها على النحو التالي: 𝑚= −𝑛ln 𝑝 (في 2)2 بينما العدد الأمثل لوظائف hash هو: 𝑘= 𝑚 𝑛ln 2 إذا افترضنا إدراج 1000 عنصر بتفاوت 1% فإن حجم المصفوفة هو 9585 بت مع 𝑘= 6، بينما في حالة التسامح بنسبة 0.1% يصبح 14377 بت مع 𝑘= 9. إذا كان مليون عنصر ومن المتوقع إدراجها، يصبح حجم المصفوفة حوالي 1170 كيلو بايت لـ 1% و1775 كيلو بايت لـ 0.1%، بنفس قيم 𝑘، لأنها تعتمد فقط على 𝑝[26]. في لعبة لا يجب فيها تعيين اللاعبين إلى خصم سبق لهم تحديه، بدلاً من حفظ قائمة الخصوم السابقين في مساحة التخزين لكل لاعب، يمكن للمرء استخدام بلوم مرشح. غالبًا ما تكون مخاطرة عدم تحدي بعض اللاعبين مقبولة، ويمكن إعادة ضبط عامل التصفية بشكل دوري.4.3. Ethereum التوافق الميزة الرئيسية للتوافق مع EVM وEthereum هي إعادة استخدام كل ما هو متاح أدوات. Ethereum smart contracts يمكن نشرها على Optimism دون أي تعديل أو عمليات التدقيق الجديدة. تظل المحافظ متوافقة وأدوات التطوير والتحليل الثابت والتحليل العام الأدوات وأدوات الفهرسة وoracles. Ethereum و Solidity لها تاريخ طويل من الدراسة الجيدة الثغرات الأمنية، مثل هجمات إعادة الدخول، والتجاوزات والتجاوزات، والقروض السريعة، وoracle التلاعب. ولهذا السبب، تمكن Optimism من الحصول على قدر كبير من القيمة في وقت قصير الوقت. إن اختيار استخدام جهاز افتراضي مختلف يعني الحاجة إلى إعادة بناء النظام البيئي بأكمله، مع ميزة حرية تنفيذ أكبر. StarkNet ينفذ الحساب أصلاً التجريد، وهو آلية حيث يكون كل حساب smart contract يمكن تنفيذه المنطق التعسفي طالما أنه يتوافق مع واجهة (ومن هنا جاء مصطلح التجريد): وهذا يسمح استخدام أنظمة التوقيع الرقمي المختلفة، والقدرة على تغيير المفتاح الخاص باستخدام نفس العنوان، أو استخدم multisig. اقترح مجتمع Ethereum تقديم هذا آلية مع EIP-2938 في عام 2020، لكن الاقتراح ظل قديمًا لأكثر من عام تم إعطاء التحديثات الأخرى أولوية أكبر [27]. هناك فائدة أخرى مهمة يتم اكتسابها من التوافق وهي إعادة استخدام العملاء الحاليين: Optimism يستخدم نسخة من geth للعقدة الخاصة به مع اختلاف ∼ 800 سطر فقط، وهو ما كان تم تطويره واختباره وصيانته منذ عام 2014. إن وجود عميل قوي أمر بالغ الأهمية كما هو محدد ما هو مقبول على أنه صالح أم لا في الشبكة. خطأ في تنفيذ دليل على الخطأ قد يتسبب النظام في قبول دليل غير صحيح على أنه صحيح أو دليل صحيح على غير صالح ليتم قبول الكتلة على أنها غير صحيحة، مما يعرض النظام للخطر. احتمالية هذا النوع من يمكن أن يقتصر الهجوم على نطاق أوسع من العملاء: Optimism يمكن إعادة استخدامه بالإضافة إلى الحصول على عملاء Ethereum الآخرين الذين تمت صيانتهم بالفعل، ويتم تطوير عميل آخر قائم على Erigon جارية بالفعل. في عام 2016، تم استغلال مشكلة في إدارة الذاكرة في برنامج geth كان هجوم DoS وخط الدفاع الأول هو التوصية باستخدام التكافؤ، والثاني أكثر العميل المستخدم في ذلك الوقت 5. StarkNet يواجه نفس المشكلة مع إثباتات الصلاحية، لكن العملاء يجب كتابتها من الصفر، ونظام الإثبات أكثر تعقيدًا، وبالتالي بل هو أيضًا أكثر تعقيدًا لضمان الصحة.

Karşılaştırmak

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

خاتمة

  1. الاستنتاج تعد المجموعات المجمعة هي الحل الواعد المتاح اليوم لحل مشكلة قابلية التوسع في اللامركزية blockchains، مما يمهد الطريق لعصر blockchains المعيارية بدلاً من متجانسة blockchains. يظهر بشكل أساسي اختيار تطوير مجموعة متفائلة أو مجموعة صلاحية كمفاضلة بين التعقيد وخفة الحركة. يتمتع StarkNet بالعديد من المزايا مثل السرعة عمليات السحب، وعدم القدرة الهيكلية على التحولات غير الصالحة للحالة، وانخفاض تكلفة المعاملات في حساب فترة تطوير أطول وعدم التوافق مع EVM، بينما Optimism لديه استفادت من اقتصاد الشبكة للحصول بسرعة على حصة كبيرة من السوق. Optimism ومع ذلك، يمتلك Bedrock تصميمًا معياريًا يسمح له بأن يصبح صالحًا 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

مجموعة التحديثات في المستقبل: يستخدم Cannon حاليًا برنامج minigeth المترجم إلى MIPS لإثبات الأخطاء النظام، ولكن يمكن استخدام نفس البنية للحصول على دائرة وإنتاج إثباتات الصلاحية. يؤدي تجميع جهاز معقد مثل EVM للهندسة المعمارية الدقيقة إلى عملية أبسط الدائرة التي لا تحتاج إلى تعديل وإعادة التحقق منها في حالة الترقية. RISC صفر هو بنية دقيقة يمكن التحقق منها مع أدلة STARK قيد التطوير بالفعل بناءً على RISC-V ذلك يمكن استخدامه لهذا الغرض كبديل لـ MIPS [28]. أحد الجوانب التي لا ينبغي الاستهانة بها هو التعقيد في فهم كيفية تعمل التكنولوجيا. تتمثل قوة blockchains التقليدية في القدرة على التحقق من حالة blockchain دون الثقة في أي كيان خارجي. ومع ذلك، في حالة StarkNet، فهو كذلك من الضروري الثقة في التنفيذ عندما لا يكون من الممكن التحقق من المكونات المختلفة على أساس التشفير والرياضيات المتقدمة. قد يؤدي هذا في البداية إلى خلق احتكاك لـ اعتماد التكنولوجيا، ولكن مع تقدم الأدوات واستخدام البراهين النزاهة خارج الحقل blockchain نأمل أن يتم حل هذه المشكلة.

Çözüm

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