التوثيق الفني لـ Optimism

خلاصة

تتناول هذه الورقة مشكلة قابلية التوسع في 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...

مقدمة

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 نرسم بعض الاستنتاجات.

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

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 ويحل محل قاعدة البيانات. يتم إجراء الاستعلامات إلى العقد الأخرى ل الحصول على الصور الأولية.

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

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)

مقارنة

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 يواجه نفس المشكلة مع إثباتات الصلاحية، لكن العملاء يجب كتابتها من الصفر، ونظام الإثبات أكثر تعقيدًا، وبالتالي بل هو أيضًا أكثر تعقيدًا لضمان الصحة.

خاتمة

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 نأمل أن يتم حل هذه المشكلة.