داخل AnyTrust

AnyTrust هو أحد أشكال تقنية Arbitrum Nitro التي تعمل على خفض التكاليف من خلال قبول افتراض ثقة بسيط.

يتطلب بروتوكول Arbitrum أن تتمتع جميع عقد Arbitrum، بما في ذلك المدققون (العقد التي تتحقق من صحة السلسلة وتكون مستعدة للمشاركة في النتائج الصحيحة)، بإمكانية الوصول إلى بيانات كل معاملة L2 في صندوق الوارد الخاص بسلسلة Arbitrum. توفر مجموعة Arbitrum إمكانية الوصول إلى البيانات عن طريق نشر البيانات (في شكل مجمع ومضغوط) على L1 Ethereum كبيانات اتصال. يعد غاز Ethereum الذي سيتم دفعه مقابل ذلك أكبر عنصر في التكلفة في Arbitrum.

تعتمد AnyTrust بدلاً من ذلك على لجنة خارجية لتوفر البيانات (يشار إليها فيما بعد باسم “اللجنة”) لتخزين البيانات وتوفيرها عند الطلب. تضم اللجنة عدد N من الأعضاء، حيث تفترض AnyTrust أن اثنين منهم على الأقل صادقين. وهذا يعني أنه إذا وعد أعضاء لجنة N-1 بتوفير الوصول إلى بعض البيانات، فيجب أن يكون أحد الأطراف الواعدة على الأقل صادقًا. نظرًا لوجود عضوين صادقين، وفشل واحد فقط في تقديم الوعد، فإن ذلك يعني أن واحدًا على الأقل من الواعدين يجب أن يكون صادقًا – وسيقدم هذا العضو الصادق البيانات عند الحاجة إليها لضمان عمل السلسلة بشكل صحيح.

 

مجموعات المفاتيح

تحدد مجموعة المفاتيح المفاتيح العامة لأعضاء اللجنة وعدد التوقيعات المطلوبة لتكون شهادة توفر البيانات صالحة. تتيح مجموعات المفاتيح إجراء تغييرات على عضوية اللجنة وتزود أعضاء اللجنة بالقدرة على تغيير مفاتيحهم.

تحتوي مجموعة المفاتيح على

• عدد أعضاء اللجنة، و

• لكل عضو في اللجنة، مفتاح عام لـ BLS، و

• عدد توقيعات اللجنة المطلوبة.

يتم تحديد مجموعات المفاتيح من خلال تجزئاتها.

يحتفظ عقد L1 KeysetManager بقائمة من مجموعات المفاتيح الصالحة حاليًا. يمكن لمالك سلسلة L2 إضافة أو إزالة مجموعات المفاتيح من هذه القائمة. عندما تصبح مجموعة المفاتيح صالحة، يصدر عقد KeysetManager حدث L1 Ethereum يحتوي على تجزئة مجموعة المفاتيح والمحتويات الكاملة. وهذا يسمح لأي شخص باسترداد المحتويات لاحقًا، مع مراعاة تجزئة مجموعة المفاتيح فقط.

على الرغم من أن واجهة برمجة التطبيقات (API) لا تحدد عدد مجموعات المفاتيح التي يمكن أن تكون صالحة في نفس الوقت، إلا أنه عادةً ما تكون مجموعة مفاتيح واحدة فقط صالحة.

 

شهادات توفر البيانات

المفهوم المركزي في AnyTrust هو شهادة توفر البيانات (يشار إليها فيما بعد بـ “DACert”). يحتوي DACert على:

• تجزئة كتلة البيانات، و

• وقت انتهاء الصلاحية ، و

• دليل على أن أعضاء لجنة N-1 قد وقعوا على زوج (التجزئة، وقت انتهاء الصلاحية)، المكون من
تجزئة مجموعة المفاتيح المستخدمة في التوقيع، و
صورة نقطية توضح أعضاء اللجنة الذين وقعوا، و
توقيع BLS المجمع (فوق منحنى BLS12-381) يثبت توقيع تلك الأطراف.

 

بسبب افتراض الثقة 2 من N، يشكل DACert دليلاً على أن بيانات الكتلة (أي الصورة الأولية للتجزئة في DACert) ستكون متاحة من عضو واحد صادق على الأقل في اللجنة، على الأقل حتى وقت انتهاء الصلاحية.

في Nitro العادي (غير AnyTrust)، يقوم جهاز التسلسل Arbitrum بنشر كتل البيانات على سلسلة L1 كبيانات اتصال. يتم الالتزام بتجزئة كتل البيانات من خلال عقد L1 Inbox، مما يسمح بقراءة البيانات بشكل موثوق بواسطة كود L2.

يوفر AnyTrust لجهاز التسلسل طريقتين لنشر كتلة بيانات على L1: يمكنه نشر البيانات الكاملة على النحو الوارد أعلاه، أو يمكنه نشر DACert لإثبات توفر البيانات. سيرفض عقد البريد الوارد L1 أي DACert يستخدم مجموعة مفاتيح غير صالحة؛ يتم التحقق من الجوانب الأخرى من صلاحية DACert بواسطة رمز L2.

يقرأ رمز L2 الذي يقرأ البيانات من البريد الوارد كتلة بيانات كاملة كما هو الحال في Nitro العادي. إذا رأى DACert بدلاً من ذلك، فإنه يتحقق من صحة DACert، مع الإشارة إلى مجموعة المفاتيح المحددة بواسطة DACert (والتي يُعرف أنها صالحة لأن صندوق الوارد L1 تحقق من ذلك). يتحقق رمز L2 من ذلك

• عدد الموقعين هو على الأقل العدد المطلوب بواسطة مجموعة المفاتيح، و

• التوقيع المجمع صالح للموقعين المطالبين بهم، و

• يكون وقت انتهاء الصلاحية بعد أسبوعين على الأقل من الطابع الزمني الحالي للمستوى الثاني.

إذا كان DACert غير صالح، فإن رمز L2 يتجاهل DACert وينتقل إلى كتلة البيانات التالية. إذا كان DACert صالحًا، فإن رمز L2 يقرأ كتلة البيانات، والتي من المؤكد أنها متاحة لأن DACert صالح.

 

خوادم توفر البيانات

يقوم أعضاء اللجنة بتشغيل برنامج خادم توفر البيانات (DAS). يعرض DAS واجهتين من واجهات برمجة التطبيقات:

• واجهة Sequencer API، والتي من المفترض أن يتم استدعاؤها فقط بواسطة Sequencer في سلسلة Arbitrum، هي واجهة JSON-RPC تسمح لـ Sequencer بإرسال كتل البيانات إلى DAS للتخزين. عادةً ما تؤدي عمليات النشر إلى حظر الوصول إلى واجهة برمجة التطبيقات (API) هذه من المتصلين بخلاف جهاز التسلسل.

 

• واجهة REST API، والتي من المفترض أن تكون متاحة للعالم، هي بروتوكول يستند إلى RESTful HTTP(S) والذي يسمح بجلب كتل البيانات عن طريق التجزئة. واجهة برمجة التطبيقات (API) هذه قابلة للتخزين المؤقت بالكامل، وقد تستخدم عمليات النشر وكيل التخزين المؤقت أو CDN لزيادة النطاق والحماية من هجمات DoS.

 

فقط أعضاء اللجنة لديهم سبب لدعم Sequencer API. نتوقع من الآخرين تشغيل REST API، وهذا مفيد. (المزيد عن ذلك أدناه.)

يمكن لبرنامج DAS، بناءً على خيارات التكوين، تخزين بياناته في ملفات محلية، أو في قاعدة بيانات Badger، أو على Amazon S3، أو بشكل متكرر عبر مخازن دعم متعددة. يدعم البرنامج أيضًا التخزين المؤقت الاختياري في الذاكرة (باستخدام Bigcache) أو في مثيل Redis.

 

التفاعل بين لجنة التسلسل

عندما يقوم جهاز التسلسل Arbitrum بإنتاج دفعة بيانات يريد نشرها باستخدام اللجنة، فإنه يرسل بيانات الدفعة، بالإضافة إلى وقت انتهاء الصلاحية (عادةً ثلاثة أسابيع في المستقبل) عبر RPC إلى جميع أعضاء اللجنة بالتوازي. يقوم كل عضو في اللجنة بتخزين البيانات في مخزن الدعم الخاص به، ويتم فهرستها بواسطة تجزئة البيانات. ثم يقوم العضو بتوقيع زوج (التجزئة، وقت انتهاء الصلاحية) باستخدام مفتاح BLS الخاص به، ويعيد التوقيع مع مؤشر النجاح إلى جهاز التسلسل.

بمجرد أن يجمع جهاز التسلسل عددًا كافيًا من التوقيعات، يمكنه تجميع التوقيعات وإنشاء DACert صالح لزوج (التجزئة ووقت انتهاء الصلاحية). يقوم Sequencer بعد ذلك بنشر DACert على عقد البريد الوارد L1، مما يجعله متاحًا لبرنامج سلسلة AnyTrust في L2.

إذا فشل جهاز التسلسل في جمع ما يكفي من التوقيعات في غضون دقائق قليلة، فسوف يتخلى عن محاولة استخدام اللجنة، وسوف “يعود إلى التجميع” عن طريق نشر البيانات الكاملة مباشرة إلى سلسلة L1، كما سيفعل في حالة غير- سلسلة أني تراست. يمكن لبرنامج L2 فهم تنسيقي نشر البيانات (عبر DACert أو عبر البيانات الكاملة) وسيتعامل مع كل منهما بشكل صحيح.