الفائدة الرئيسية هي تقليل كمية البيانات المخزنة على Ethereum ، وبالتالي تقليل التكلفة على المستخدمين لإجراء المعاملات على L2.
** بقلم: **** OneTrueKirk **
** بقلم: Yvonne، MarsBit **
** المنشور الأصلي من OneTrueKirk على ethresear.ch **
هذه هي المرة الأولى التي أنشر فيها موضوعًا هنا ، لذا أعتذر إذا أساءت إليك بأي شكل من الأشكال. لقد كنت أفكر في هذه الفكرة (مجموعات عديمة الحالة) في الغالب من أجل مجموعات مخصصة لبروتوكول الإقراض الخاص بنا ، ولكن آمل أن تكون قابلة للتطبيق بشكل عام ، ونقدر أي تعليقات.
** TLDR ： **
يتم نشر جذر الحالة فقط ، وليس بيانات الاتصال.
(ملاحظة MarsBit: Calldata هي قيمة جزء البيانات في معاملة العقد ولا يمكن تعديلها.)
التفاصيل
ماذا لو بدلاً من استخدام Ethereum كطبقة توفر بيانات ، عن طريق نشر الحالة الكاملة كبيانات اتصال ، ونشر فقط جذر الحالة إلى mainnet؟ تتمثل الفائدة الرئيسية في تقليل كمية البيانات المخزنة على Ethereum ، وبالتالي تقليل تكلفة المستخدمين للتعامل على L2. حتى مع EIP-4844 ، فإن blobace ليس مجانيًا.
يتمثل الخطر الرئيسي في هجوم حجب البيانات ، حيث ينشر مقدم العرض جذر حالة صالحًا ولكنه يحجب البيانات الكاملة من عقد التجميع الأخرى لاحتكار إنتاج الكتلة في المستقبل أو الاحتفاظ بالأموال كرهينة. لمنع ذلك ، يجب على العقد الصادقة أن تشكك في أي تحديث للحالة لا يمكن لأي نظير توفير بيانات عنه. يمكن استخدام إثباتات الاحتيال التفاعلية على غرار Arbitrum لإجبار مقدمي العروض على الكشف عن الحالة الكاملة على الشبكة الرئيسية ، ولكن لا يزالون يتسببون في فشل التحدي إذا كان الجذر صالحًا ، لذلك حتى في حالة الفشل ، تكون تكلفة التحدي منخفضة.
(ملاحظة MarsBit: يشير هجوم حجب البيانات إلى المهاجم الذي لا يقوم عن عمد بإعادة جميع البيانات أو إعادة البيانات الخاطئة عند الوصول إلى البيانات المحمية ، من أجل تحقيق غرض الخداع أو التدمير.
إذا كانت تكلفة فشل التحدي منخفضة ، فيمكن جعل مقدمي العروض الصادقين بائسين من خلال إجبارهم على الدفع مقابل نشر جميع بيانات الحالة على الشبكة الرئيسية للدفاع عن التحدي ، حتى لو قاموا بنشر بيانات الحالة من نقطة إلى نقطة بشكل صحيح. يجب أن تكون تكلفة بدء التحدي متناسبة مع تكلفة الدفاع لضمان عدم مهاجمة مقدمي العروض الصادقين بهذه الطريقة.
في أسوأ الحالات ، إذا تمكن المهاجم من إنفاق دولار واحد لتكلف مقدم العرض الصادق دولارًا واحدًا ، فيمكنه إجبار مقدم العرض على الاستسلام واستعادة الحظر. يمكن لمقدم العرض الجديد الصادق بعد ذلك تقديم عرض ، وما لم يتمكن المهاجم من تكرار الهجوم على جميع مقدمي العروض الصادقين المحتملين ، بما في ذلك كل شخص لديه أموال ، فلن يتمكن من التسبب في توقف دائم. من الممكن إضافة بند آخر ، حيث ترتفع تكلفة التحدي عندما يمر وقت طويل منذ الانتهاء من كتلة صالحة. بهذه الطريقة ، من السهل تحدي مقدم عرض غير أمين ، لكن من المستحيل إيقاف انتقالات الحالة لفترة طويلة.
وبشكل أكثر تفاؤلاً ، إذا قامت العقد بنشر البيانات بين الأقران ، فيمكنهم تحديد حلول النسخ الاحتياطي للبيانات وإمكانية الوصول الخاصة بهم ، ويكون المستخدمون أفضل حالًا في تخزين البيانات التي يحتاجون إليها محليًا لتحولات الحالة الخاصة بهم. في سياق تطبيق معين ، فكرت في ترميز حالة التجميع بطريقة مختلفة تمامًا عن EVM لتحسين ذلك. يمكن تشفير جميع الحالات المرتبطة بحساب مستخدم معين في نفس التجزئة ، بحيث يمكن للمستخدمين التحقق بسهولة أكبر من التغييرات التي تطرأ على حساباتهم دون معرفة الحالة العالمية (أي تأكيد تلقيك العدد المطلوب من الرموز المميزة دون القلق بشأن مصدرها) .
لخص
أرغب في سماع أفكارك ، وسأكون ممتنًا للحصول على روابط للعمل ذي الصلة. على عكس التراكمي المتفائل العادي ، من السهل في التراكمي المتفائل تحديد ما إذا كانت بيانات الاتصال المقدمة تتطابق مع جذر الحالة للشبكة الرئيسية ، وما إذا كان كلاهما صالحًا ، ولكن من المستحيل معرفة ما إذا كان التحديث صالحًا من جذر الحالة وحده ، لذلك من الضروري النظر بعناية في اقتصاديات فترات التحدي والحزن (أي السلوك الخبيث).
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
نظرة سريعة على المزايا والمشكلات المحتملة للتراكم عديم الحالة
** بقلم: **** OneTrueKirk **
** بقلم: Yvonne، MarsBit **
** المنشور الأصلي من OneTrueKirk على ethresear.ch **
هذه هي المرة الأولى التي أنشر فيها موضوعًا هنا ، لذا أعتذر إذا أساءت إليك بأي شكل من الأشكال. لقد كنت أفكر في هذه الفكرة (مجموعات عديمة الحالة) في الغالب من أجل مجموعات مخصصة لبروتوكول الإقراض الخاص بنا ، ولكن آمل أن تكون قابلة للتطبيق بشكل عام ، ونقدر أي تعليقات.
** TLDR ： **
يتم نشر جذر الحالة فقط ، وليس بيانات الاتصال.
(ملاحظة MarsBit: Calldata هي قيمة جزء البيانات في معاملة العقد ولا يمكن تعديلها.)
التفاصيل
ماذا لو بدلاً من استخدام Ethereum كطبقة توفر بيانات ، عن طريق نشر الحالة الكاملة كبيانات اتصال ، ونشر فقط جذر الحالة إلى mainnet؟ تتمثل الفائدة الرئيسية في تقليل كمية البيانات المخزنة على Ethereum ، وبالتالي تقليل تكلفة المستخدمين للتعامل على L2. حتى مع EIP-4844 ، فإن blobace ليس مجانيًا.
يتمثل الخطر الرئيسي في هجوم حجب البيانات ، حيث ينشر مقدم العرض جذر حالة صالحًا ولكنه يحجب البيانات الكاملة من عقد التجميع الأخرى لاحتكار إنتاج الكتلة في المستقبل أو الاحتفاظ بالأموال كرهينة. لمنع ذلك ، يجب على العقد الصادقة أن تشكك في أي تحديث للحالة لا يمكن لأي نظير توفير بيانات عنه. يمكن استخدام إثباتات الاحتيال التفاعلية على غرار Arbitrum لإجبار مقدمي العروض على الكشف عن الحالة الكاملة على الشبكة الرئيسية ، ولكن لا يزالون يتسببون في فشل التحدي إذا كان الجذر صالحًا ، لذلك حتى في حالة الفشل ، تكون تكلفة التحدي منخفضة.
(ملاحظة MarsBit: يشير هجوم حجب البيانات إلى المهاجم الذي لا يقوم عن عمد بإعادة جميع البيانات أو إعادة البيانات الخاطئة عند الوصول إلى البيانات المحمية ، من أجل تحقيق غرض الخداع أو التدمير.
إذا كانت تكلفة فشل التحدي منخفضة ، فيمكن جعل مقدمي العروض الصادقين بائسين من خلال إجبارهم على الدفع مقابل نشر جميع بيانات الحالة على الشبكة الرئيسية للدفاع عن التحدي ، حتى لو قاموا بنشر بيانات الحالة من نقطة إلى نقطة بشكل صحيح. يجب أن تكون تكلفة بدء التحدي متناسبة مع تكلفة الدفاع لضمان عدم مهاجمة مقدمي العروض الصادقين بهذه الطريقة.
في أسوأ الحالات ، إذا تمكن المهاجم من إنفاق دولار واحد لتكلف مقدم العرض الصادق دولارًا واحدًا ، فيمكنه إجبار مقدم العرض على الاستسلام واستعادة الحظر. يمكن لمقدم العرض الجديد الصادق بعد ذلك تقديم عرض ، وما لم يتمكن المهاجم من تكرار الهجوم على جميع مقدمي العروض الصادقين المحتملين ، بما في ذلك كل شخص لديه أموال ، فلن يتمكن من التسبب في توقف دائم. من الممكن إضافة بند آخر ، حيث ترتفع تكلفة التحدي عندما يمر وقت طويل منذ الانتهاء من كتلة صالحة. بهذه الطريقة ، من السهل تحدي مقدم عرض غير أمين ، لكن من المستحيل إيقاف انتقالات الحالة لفترة طويلة.
وبشكل أكثر تفاؤلاً ، إذا قامت العقد بنشر البيانات بين الأقران ، فيمكنهم تحديد حلول النسخ الاحتياطي للبيانات وإمكانية الوصول الخاصة بهم ، ويكون المستخدمون أفضل حالًا في تخزين البيانات التي يحتاجون إليها محليًا لتحولات الحالة الخاصة بهم. في سياق تطبيق معين ، فكرت في ترميز حالة التجميع بطريقة مختلفة تمامًا عن EVM لتحسين ذلك. يمكن تشفير جميع الحالات المرتبطة بحساب مستخدم معين في نفس التجزئة ، بحيث يمكن للمستخدمين التحقق بسهولة أكبر من التغييرات التي تطرأ على حساباتهم دون معرفة الحالة العالمية (أي تأكيد تلقيك العدد المطلوب من الرموز المميزة دون القلق بشأن مصدرها) .
لخص
أرغب في سماع أفكارك ، وسأكون ممتنًا للحصول على روابط للعمل ذي الصلة. على عكس التراكمي المتفائل العادي ، من السهل في التراكمي المتفائل تحديد ما إذا كانت بيانات الاتصال المقدمة تتطابق مع جذر الحالة للشبكة الرئيسية ، وما إذا كان كلاهما صالحًا ، ولكن من المستحيل معرفة ما إذا كان التحديث صالحًا من جذر الحالة وحده ، لذلك من الضروري النظر بعناية في اقتصاديات فترات التحدي والحزن (أي السلوك الخبيث).