تحقق محافظ السلسلة الحية تعيينًا تقريبيًا 1-1 للمعاملات: لكل معاملة اقتصادية يقوم بها المستخدم، يتطلب تقريبًا معاملة سلسلة كتل واحدة. تغير التجميعات، وتجميع العملات، وقطع المدفوعات وما إلى ذلك هذا البيان قليلاً. ولكنه صحيح تقريباً.

حقق Lightning تخطيطا متعدد إلى واحد للمعاملات إلى المعاملات: سحر Lightning هو أن عددا لا حصر له من المعاملات الاقتصادية يمكن أن يحدث في قناة إضاءة واحدة ، والتي ترتبط نفسها بإخراج معاملة واحدة غير منفقة (UTXO). لقد أخذنا بشكل أساسي البعد "الزمني" - المعاملات - وحققنا توسعا كبيرا من خلال انهيار هذا البعد.

لكن إنشاء حتى UTXO واحد لكل مستخدم ، يمكن القول ، ليس جيدا بما فيه الكفاية. لذلك هناك العديد من المقترحات لتحقيق توسع أكبر من خلال السماح لعدة مستخدمين بمشاركة UTXO واحد بطريقة ذاتية السيادة. مرة أخرى ، انهيار بعد "مساحة" آخر للتوسع - المستخدمين - في UTXO واحد.

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

شكرا يذهب إلىFulgur Venturesلرعاية هذا البحث. لم يكن لديهم أي سيطرة تحريرية على محتويات هذا المنشور ولم يتم مراجعته قبل النشر.

شكراً أيضاً يذهب إلىدانييلا بروزوني, سارة كوكس، وآخرون لمراجعة قبل النشر.

تعريفات

ما هي الطبقة 2؟

في كثير من الأحيان يتم تعريف مصطلح 'الطبقة 2' على نطاق واسع، حتى يمكن تعريف كيان مشابه للبنك (على سبيل المثال Liquid) كطبقة 2. من أجل هذه المقالة سنتبنى تعريفًا صارمًا: الطبقة 2 (L2) هي نظام يتعامل بالبيتكوين، بهدف السماح بتنفيذ عمليات تداول BTC بشكل أكثر تكرارًا من عدد عمليات السلسلة الرئيسية مع أطراف أخرى. ويحدث ذلك إما:

1. لا يستطيع أحد سرقة الأموال بطريقة مربحة في النظام، مع مراعاة العقوبات والتكاليف داخل النظام. لا يتم اعتبار التكاليف والعقوبات خارج النظام مثل فقدان السمعة والعواقب القانونية، إلخ في تعريفنا.
2. (المفضل) يمكن لأصحاب الأموال الحقيقيين سحب أموالهم من دون تعاون أي أطراف ثالثة، باستثناء رسوم المعاملات.

الخيار الأول مطلوب لأننا نريد أن تكون أنظمة L2 الخاصة بنا قادرة على تمثيل المبالغ والمعاملات ذات القيمة الصغيرة بحيث لا يمكن تمثيلها على السلسلة. على سبيل المثال ، في Lightning ، يمكن أن يكون ل HTLCs قيمة صغيرة جدا بحيث لا يمكن تمثيلها على السلسلة. في هذه الحالة ، تتم إضافة قيمة HTLC إلى رسوم المعاملة الخاصة بمعاملة الالتزام. في حين أن عقدة Lightning يمكنها "سرقة" HTLC الغبار عن طريق إغلاق قناة في الوقت المناسب ، فإن القيام بذلك يكون أكثر تكلفة¹من الأفضل أن يكون قيمة HTLC أقل من قيمتها، مما يجعل السرقة غير مربحة.

ومع ذلك، الانسحاب الأحادي هو دائمًا هدف تصميمنا الأساسي.²

مع هذا التعريف، تُعتبر أشياء مثل البرق أنظمة طبقة 2. ومع ذلك، لا تُعتبر نظم مثل السائل، كاشو، وفديمينت طبقة 2، لأن طرفًا آخر أو أطرافًا لديه التحكم في أموالك. بالإضافة إلى ذلك، نظم التحقق من العميل مثل RGB أيضًا ليست طبقة 2 وفقًا لهذا التعريف، لأنها غير قادرة على التداول بالبيتكوين بشكل موثوق به. وأخيرًا، @RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">لا يتمكن Statechains من الوصول إلى المستوى المطلوب، لأن الجهة التي تدير Statechain يمكن أن تسرق الأموال إذا لم تتبع البروتوكول.

ما هي العهود؟

... ولماذا تحتاج أنظمة L2 الأكثر قابلية للتطوير إليها؟

في كتابة بيتكوين، العهود هي آليات يتم من خلالها تقييد الطريقة التي يمكن بها إنفاق txout مسبقًا، بحيث تكون صيغة المعاملات المستخدمة لإنفاق ذلك txout محددة مسبقًا أو مقيدة بطريقة ليست مقتصرة فقط على التواقيع. الأنظمة L2 التي تشارك UTXOs بين عدة أطراف بحاجة إلى عهود لأنها بحاجة إلى طرق لتقييد كيف يمكن إنفاق UTXO لتنفيذ قواعد وحوافز بروتوكول L2.

العهود التكرارية

العهد التكراري هو عهد يتمتع بالخاصية التي يمكن تطبيق القواعد المحددة لكيفية إنفاق UTXO بشكل متكرر ، على UTXOs الفرعية للصفقة القابلة للإنفاق بشكل لا نهائي. العهود التكرارية لهاطالما اعتبرت غير مرغوب فيها من قبل البعضلأنها قد تعرقل العملات بشكل لا نهائي. أو على الأقل، بشكل لا نهائي دون إذن من طرف ثالث مثل حكومة.

أهداف

البرق هو نظام الطبقة 2 الأفضل حاليا. ومع ذلك، لديه قيود. وهي:

1. التوسيع - يتطلب البرق حاليًا على الأقل UTXO واحد لكل مستخدم نهائي.³
2. السيولة - يتطلب البرق ربط الأموال في القنوات.
3. التفاعلية - يتطلب البرق أن يكون المستلمون للمدفوعات متصلين بالإنترنت لاستلامها بشكل آمن.

عند تقييم أنظمة الطبقة 2، سيكون هدفنا تحسين هذه القيود الرئيسية، في الأفضلية دون إضافة قيود جديدة.

حدود توسعة البرق

ماذا يعني "UTXO واحد لكل مستخدم نهائي" عمليًا؟ نظرًا لأن قنوات Lightning يمكن أن تعمل بشكل لا نهائي، فإن طريقة واحدة للنظر في هذا الأمر هي السؤال عن عدد القنوات الجديدة التي يمكن إنشاؤها سنويًا⁴. إنشاء ناتج الجذر الرئيسي له تكلفة هامشية تبلغ 43 فولت ؛ إذا تم إطفاء إنشاء القناة ، مع إنشاء العديد من القنوات في معاملة واحدة ، يمكن جعل النفقات العامة للمعاملة الأخرى ضئيلة ويمكن فتح أعداد كبيرة إلى حد ما من القنوات سنويا للمستخدمين الجدد على متن الطائرة. على سبيل المثال ، افترض أن 90٪ من سعة الكتلة ذهبت لفتح قنوات Lightning جديدة من الجذر:

يُقدر أن حوالي نصف السكان العالمي يمتلكون هاتف ذكي، 4.3 مليار شخص. لذلك يمكننا بالفعل تسجيل نسبة كبيرة من السكان الذين من المرجح أن يكونوا قادرين على استخدام قناة Lightning في السنة.

ومع ذلك، فإن القنوات لا تدوم إلى الأبد. في بعض الأحيان، سيود المستخدمون تغيير المحافظ، أو زيادة أو تخفيض سعة القناة، إلخ. والطريقة الأكثر كفاءة لتغيير سعة القناة هي عبر طبقة 2.تجميع, تنفيذ بشكل ملحوظ في محفظة فينيكس.

مثل فتح القناة ، يمكن أيضًا القيام بعملية التجميع بطريقة مؤجلة لتحسين الكفاءة ، حيث تشترك عمليات التجميع المتعددة في عملية تداول واحدة لتقليل عدد المدخلات والمخرجات اللازمة لإضافة وإزالة الأموال⁵. بالتالي ، مساحة الكتلة دلتا المطلوبة لكل تقسيم للمستخدمين ، بفرض استخدام musig, هو إخراج 43vB تابروت بالإضافة إلى ال

57.5vB الجذرية الرئيسية الطريق تنفق، لمجموع 100.5vB. إذا افترضنا مرة أخرى استخدام 90% من مساحة الكتلة، نحصل على:

أخيرًا ، لاحظ كيف يمكن تبديل قنوات البرق بين المحافظ في صفقة واحدة سواء عن طريق الثقة بالمحفظة التالية لتوقيع صفقة التزام بعد إرسال الأموال إلى عنوان الالتزام ، أو باستخدام الدعم المشترك لإغلاق قناة جديدة في تنفيذ كلا المحافظ.

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

نظرة عامة على الطبقة 2

تحت تعريفنا لأنظمة الطبقة 2، هناك نمطان تصميميان رئيسيان يتم مناقشتهما في مجتمع تطوير البيتكوين:

1. القنوات
2. UTXOs افتراضية

في نمط القناة، والذي يعتبر البرق هو المثال الرئيسي له، يتقدم البروتوكول عن طريق تبادل المعاملات الموقعة مسبقًا بين الأطراف التي يمكن أن تُعد تعدينًا، ولكنها ليست في المسار السعيد. تقسم هذه المعاملات الموقعة مسبقًا UTXO بين الأطراف؛ تحدث المعاملات عن طريق تغيير رصيد هذا الانقسام مرارًا وتكرارًا، مع معاملات موقعة مسبقًا جديدة. نظرًا لوجود العديد من المعاملات الصالحة المختلفة الممكنة التي تنفق نفس UTXO، يتطلب ذلك آلية حوافز للتأكد من أن المعاملة الصحيحة هي المعاملة التي تم التعدين عليها فعليًا.

في نمط تصميم UTXO (V-UTXO) الافتراضي ، والذي يعد Ark أبرز مثال عليه ، يتم إنشاء V-UTXOs عبر العهود أو اتفاقية متعددة الأطراف ، من خلال إنشاء معاملات يمكن تعدينها لسحب أموال V-UTXO من جانب واحد عن طريق وضعها على السلسلة ، ولكنها ليست في "المسار السعيد". في هذا الصدد ، تشبه V-UTXO القنوات. ولكن على عكس القنوات ، تقوم مخططات V-UTXO بإجراء المعاملات عن طريق إنفاق V-UTXOs نفسها ، في (من الناحية المفاهيمية)⁶ معاملة موقعة مسبقا.

نمط التصميم "المسار السعيد" هو استخدام مسار البرنامج "الجميع متفق عليه"، مثل N-of-N multisig؛ تم تصميم taproot خصيصًا لهذا المفهوم، مما يتيح لمسار المفتاح أن يكون N-of-N multisig عبر musig. بفرض اتفاق الأطراف جميعها، يسمح المسار السعيد بإنفاق العملات بكفاءة (وسرية).

من المثير للاهتمام، حيث أن UTXOs الافتراضية "حقيقية" بكثير في العديد من الجوانب، فمن السهل جدًا بناء القنوات على أعلى من UTXOs الافتراضية ببساطة عن طريق إنشاء UTXOs الافتراضية التي، إذا تم تعدينها، ستؤدي إلى إنشاء UTXOs المطلوبة للقنوات. في هذا المعنى، فإن مخططات UTXO الافتراضية هي

طبقة أدنى قليلاً من القنوات.

البرق

الوضع الراهن، المنفذ في الإنتاج كشبكة البرق، يعتمد في المقام الأول علىمعايير BOLTs. Lightning هو مزيج من عدد من الأشياء ، بما في ذلك قنوات Lightning و HTLCs ، وشبكة توجيه P2P ، وتوجيه البصل ، ومعايير الفاتورة ، وما إلى ذلك. والجدير بالذكر أن Lightning ليس نظاما إجماعا ، لذلك لا يلزم اعتماد عناصر مختلفة من "نظام Lightning" بنفس الطريقة بالضبط من قبل جميع المستخدمين. لغرض هذه المقالة ، عندما نقول "Lightning" ، سنستخدمها بالمعنى الواسع ، بما في ذلك الترقيات المتوقعة بسهولة لبروتوكول (بروتوكولات) Lightning الحالي (النموذجي) المستخدم على نطاق واسع.

كما تم مناقشته أعلاه ، السمة الرئيسية للبرق هي حدود قابلية التوسع الخاصة بالمستخدم النهائي ، نظرًا للحاجة إلى وجود UTXO واحد على الأقل لكل مستخدم. ومع ذلك ، بالنسبة لعنصر التوجيه الأساسي للبرق - عقدة البرق العامة التي توجه غالبية المعاملات - لا تعد حدود القابلية للتوسع هذه مشكلة كبيرة ، حيث يعمل البرق بشكل جيد إذا كان هناك مستخدمون أكثر بكثير من عقد التوجيه ، لأن كل قناة عامة تستخدم لتوجيه الدفع يمكن أن تدعم بسهولة عددًا كبيرًا من المعاملات في الثانية. هذا هو أيضًا السبب في أن العديد من أنظمة L2 المستقبلية تتوقع أيضًا المشاركة في شبكة البرق. نرى أيضًا ذلك في كيفية اعتماد أنظمة Cashu غير الموجودة ك L2 الحالية بشكل كبير على شبكة البرق لتكون فعالة فعلا: ربما يكون الاستخدام الأساسي لـ Cashu هو إرسال واستقبال المدفوعات عبر البرق.

قنوات غير تفاعلية

تعمل هذه البنية على تحسين قنوات البرق عن طريق استخدام OP_CTV لتقليل متطلبات التفاعلية. ومع ذلك، لأنها لا تعمل على تحسين حد التوسع الذي يسمح بـ 1 UTXO للمستخدم الواحد ، فلن نناقشها بشكل أوسع.

مصانع القنوات

هنا لدينا أطراف متعددة تتفاوض على عنوان واحد متعدد n-of-n ، جنبا إلى جنب مع إنفاق المعاملات التي يعالجها multisig لإنشاء n مختلفة لتقسيم الأموال. يتم استخدام UTXOs بدورها لقنوات الدفع. يمكن استخدام القنوات بنفس الأمان كما لو تم فتحها مباشرة على السلسلة ، لأنه في حالة الحاجة إلى وضع حالة القناة على السلسلة ، يمكن تعدين المعاملة المقسمة. من المحتمل أن يوفر هذا مساحة على السلسلة عند إغلاق القنوات ، حيث يمكن للأطراف n - من الناحية النظرية - إغلاق جميع قنوات nn بشكل تعاوني مرة واحدة.

نظرًا لأن مصانع القنوات تتفاوض بشأن UTXO يمكن تعدينها ، ولكن لا يُتوقع أن يتم تعدينها فعليًا في المسار السعيد ، فإنها مثال بدائي جدًا لـ V-UTXOs.

مصانع القنوات بحد ذاتها لا تتطلب أي شوكات ناعمة لتكون ممكنة. ومع ذلك، فإن مصانع القنوات البسيطة الموصوفة أعلاه ربما لا تكون عملية وراء أعداد صغيرة من الأطراف بسبب التنسيق اللازم لتحقيق فائدة توسيعية. وبالتالي، مقترحات العهد مثل OP_Evictأو CTV (عبر أشجار txout) تهدف إلى السماح بمزيد من النتائج الدقيقة حيث يمكن إجبار الأطراف الفردية على السلسلة، دون إجبار الجميع على السلسلة في نفس الوقت.

إلتو / LN-التماثل

نظرًا لأن Eltoo هو اسم مربك للغاية ، فسنستخدم فقط الاسم المحدث LN-Symmetry في المستقبل.

بينما تشجع قنوات Poon-Dryja على نشر الحالة الصحيحة على السلسلة من خلال معاقبة الحالات غير الصحيحة ، يسمح LN-Symmetry بدلا من ذلك بتحديث الحالات غير الصحيحة بمعاملة إضافية. هذا له ميزة تبسيط قنوات Lightning عن طريق إزالة تعقيد العقوبات. ومع ذلك ، من المحتمل أن يكون هذا عيبا في السيناريوهات غير الموثوق بها ، حيث يمكن القول إن هناك حاجة إلى عقوبات لتثبيط الاحتيال.

يحتاج LN-Symmetry إلى فork لينعمل على تمكين الطبقة 2SIGHASH_ANYPREVOUT، الذي يتطلب السماح لصفقات الدولة بإعادة الإنفاق لصفقات الدولة الأخرى أثناء التحديثات.

بمفردها، LN-Symmetry لا تقدم تحسينات في توسيع القنوات البرقية التقليدية. ولكنوقد أجاد المؤيدونأنه يجعل الأمور مثل مصانع القنوات أسهل في التنفيذ.

ARK

تتخذ Ark نهجا جديدا لتوسيع نطاق المعاملات: UTXOs الافتراضية القابلة للتحويل بالكامل (V-UTXOs) ، والتي يمكن دمجها وتقسيمها إلى ذري⁷المعاملات خارج السلسلة. في Ark، يوفر العقد المركزي، موفر خدمة Ark (ASP)، V-UTXOs للمستخدمين بفترة زمنية محددة، على سبيل المثال 4 أسابيع. تُعرف هذه الفترات باسم الجولات. يتم إنشاء هذه V-UTXOs عبر pool txouts، واحد لكل جولة، عبر نوع من آلية مثل CTV للسماح للمعاملة on-chain والتعهد بشجرة V-UTXOs. انتهاء الجولة هو كيفية تحقيق Ark لميزة التوسيع: في نهاية الجولة، يقوم pool txout بالفتح، مما يسمح لـ ASP بإنفاقها من جانب واحد بتوقيع واحد في معاملة صغيرة. نظرًا لانتهاء الوقت النهائي للجولة، تنتهي الـ V-UTXOs نفسها عند انتهاء pool txouts الذي ينشئها: يجب على المستخدمين الذين يمتلكون V-UTXO إما إنفاق تلك V-UTXO قبل الوقت النهائي لانتهاء pool txout، أو وضعها on-chain (سحب من جانب واحد).

للتعامل مع V-UTXOs بين الأطراف ، يشارك منسق Ark في توقيع المعاملات التي تنفق واحدا أو أكثر من V-UTXOs ، بحيث تكون المعاملات صالحة فقط إذا تم إنشاء واحد أو أكثر من V-UTXOs الأخرى في جولة مختلفة. بالاقتران مع بعض المهلات الدقيقة - راجع مستندات Ark للحصول على التفاصيل الكاملة - هذه التبعية هي ما يجعل إنفاق V-UTXO غير موثوق به: لا يمكن المطالبة ب V-UTXO على السلسلة ما لم يتم إنشاء V-UTXOs جديدة في معاملة تجمع مختلفة. هناك بعض الطرق المحتملة لتنفيذ هذه التبعية بالفعل. لكن التفاصيل الدقيقة ليست ذات صلة بأغراض هذه المقالة.

لاحظ كيف يعني هذا أن ASP معين سيكون له العديد من الجولات النشطة المختلفة التي تحدث في وقت واحد. يتم إنشاء جولات جديدة بشكل متكرر للسماح بتحويل الأموال في الجولات الحالية. لكن الجولات الحالية تتداخل مع الجولات الجديدة ، حيث ستنتهي صلاحيتها بشكل عام في وقت ما بعد إنشاء جولات جديدة ، وإنشاء مجموعات تجمع جديدة.

اقتصادات آرك

عندما يتم إنفاق V-UTXO ، يجب على ASP توفير BTC متطابقة في txout لحوض جديد يمثل جولة جديدة. ولكنهم لا يمكنهم استرداد قيمة V-UTXO المنفقة حتى ينتهي الجولة. وبالتالي ، للنفقات المتعلقة بإنفاق V-UTXO تكلفة زمنية للمال ، بسبب السيولة التي يجب أن يوفرها ASP.

تحدث التكلفة بشكل خاص عندما يتم إنفاق V-UTXO. بينما يتم حفظ V-UTXO ، يمثل UTXO المحتمل الفعلي الذي يمكن وضعه على السلسلة لسحب الأموال دون الحاجة إلى موافقة أي شخص آخر؛ يمتلك المستخدم تلك الأموال. ومع ذلك ، لإنفاق V-UTXO ، يجب على ASP إنشاء txout لمجموعة جديدة باستخدام الأموال التي يحصل عليها ASP من مكان آخر ، بينما لا تتوفر الأموال في V-UTXO المنفقة لـ ASP حتى يتم الوصول إلى وقت الانتهاء.

بالتالي، يتطلب إنفاق V-UTXO قرضًا قصير الأجل، استعارة الأموال لتغطية الفترة الزمنية بين الآن وانتهاء الجولة. وهذا يعني أن تكلفة السيولة لإنفاق V-UTXO تنخفض فعلا مع تقدم V-UTXO في العمر وتقترب موعد الانتهاء، وفي النهاية — بالنظرية — تصل إلى الصفر عندما تنتهي الجولة.

أخيرا ، تذكر أن تكلفة إنفاق V-UTXO مرتبطة بالحجم الإجمالي ل V-UTXO الذي يتم إنفاقه. ليس المبلغ المدفوع للمستلم. هذا يعني أن المحافظ المخصصة للتعامل مع V-UTXOs مباشرة (على عكس إدارة V-UTXO واحدة لأغراض ، على سبيل المثال ، قناة إضاءة قائمة على V-UTXO) ، يجب أن تقوم بإجراء مقايضات في كيفية تقسيم الأموال إلى V-UTXOs. يقلل V-UTXO واحد من تكلفة السحب من جانب واحد ، مع زيادة رسوم المعاملات القائمة على السيولة ؛ تقسيم الأموال إلى العديد من V-UTXOs يفعل العكس. هذا يختلف تماما عن اقتصاديات معاملات Bitcoin أو Lightning على السلسلة.

ما هو تكلفة السيولة هذه؟ حاليًا، تفرض محفظة البرق فونيكس رسومًا بنسبة 1٪ لحجز سيولة القناة لمدة عام واحد. على أسوأ تقدير، يجب على فونيكس أن تربط أموالها لمدة عام واحد. ومع ذلك، يفترض أن السيولة لم يتم استخدامها. قد يكون من الممكن جدًا أن تكون تكلفة رأس المال لفونيكس في الواقع أعلى، وأنهم يفترضون أن العميل العادي يستخدم سيولته الواردة في أقل من عام واحد. كما أن فونيكس يكسب أموالًا من رسوم المعاملات، وربما يدعم سيولة القناة بشكل مالي. وأخيرًا، قد لا يكون فونيكس رابحًا!

سعر بطاقة خزانة الولايات المتحدة يعطينا تقديرًا آخر. في الوقت الحالي، يبلغ سعر بطاقة خزانة الولايات المتحدة لمدة 3 أشهر حوالي 5٪ في السنة. نظرًا للحجج التي تفيد بأن هذا السعر مبالغ فيه بسبب تضخم الدولار الأمريكي، فسنفترض تكلفة السيولة لصناديق بتكوينات بنسبة 3٪ في السنة لتحليلنا.

إذا كانت فترة الجولة 4 أسابيع، فهذا يعني أن الصفقة ستبدأ بتكلفة سيولة

، وفي النهاية ينخفض إلى الصفر. بافتراض أن المستخدم يحاول نقل أمواله إلى جولة جديدة قبل أسبوعين من انتهاء الجولة، فإن المستخدم يدفع حوالي 1.5٪ سنويًا في تكاليف سيولة لتحقيق الحصانة الذاتية لأمواله. من ناحية أخرى، إذا انتظر المستخدم حتى اللحظة الأخيرة⁸، يمكن أن يكون التكلفة تقريبًا صفر، على حساب خطر فقدان وقت الانتهاء.

قد لا يرون المستخدمون هذا التكلفة تافهة. وتفترض هذه التكلفة أن تكاليف ثابتة لكل جولة تم تجاهلها من خلال توزيع رسوم المعاملات والتكاليف الأخرى على أعداد كبيرة من المشاركين.

ماذا لو كانت التكاليف الثابتة غير هامة؟ فلنفترض أن لدى ASP 1000 مستخدم، وتُنشأ صفقات الحوكمة للمجموعة مرة في الساعة في المتوسط. على مدار فترة 4 أسابيع، يكون هناك 672 صفقة على السلسلة. وهذا يعني أن مستخدمي ASP يجب عليهم أن يدفعوا تقريبًا لنفس عدد الصفقات مقابل الاحتفاظ بأموالهم! ربما سيكون أرخص بالنسبة لهم أن يفتحوا قنوات البرق الخاصة بهم جميعًا، على الرغم من أن ASP يطلب منهم الانتظار لمدة ساعة كاملة للتأكيد.

تهيئة بدء التشغيل لـ Ark

يواجه ASP الجديد مع عدد قليل من المستخدمين معضلة: إما أن جولات ASP تحدث بشكل غير منتظم ، ويتعين على المستخدمين الانتظار لفترة طويلة حتى تجمع الجولة المقترحة ما يكفي من V-UTXOs لتحقيق توسيع مفيد وتخفيض رسوم المعاملات. أو تحدث معاملات تجمع ASP بشكل متكرر ، مع دفع رسوم معاملات عالية لكل مستخدم. كما أوضحنا في القسم السابق ، قد يستغرق الأمر الكثير من المستخدمين لإطفاء الجولات المتكررة ، وتجمعهم الأساسي.

نظرًا لانتهاء الجولات، فإن هذه المشكلة مستمرة، وأسوأ حتى من تلك التي يواجهها قنوات Lightning: على الأقل يمكن لقناة Lightning الاستمرار في أن تكون مفيدة بشكل لا نهاية له، مما يسمح بفتح قناة الآن وتكوينها تدريجيًا على مدى عدة أشهر. ثانيًا، نظرًا لانتهاء الجولات، فإن هناك أقل مرونة فيما يتعلق بموعد إنشاء txouts الجديدة التي تدعم هذه الجولات: إذا كانت الرسوم مرتفعة لمدة أسبوعين أو أكثر، فليس لدى المستخدمين الذين تنتهي صفقاتهم السبيل إلا أن يدفعوا تلك الرسوم المرتفعة (جماعيًا) للحفاظ على حق الولاية على أموالهم. مع قنوات Lightning، هناك مرونة أكبر فيما يتعلق بموعد فتح القناة بالفعل.

بينما تخيل مؤلفو Ark في البداية سيناريو متفائل جدًا حيث يحدث جولات جديدة كل بضع ثوانٍ، فمن المحتمل أن يجب أن يحدث التشغيل الأولي باستخدام حالات الاستخدام التي يمكن أن تنتظر لساعات متعددة لتأكيد عملية Ark، إذا لم يتم تعويض رسوم العملية.

التفاعل

أرك غير الودائع هو بروتوكول تفاعلي للغاية: نظرًا لانتهاء صلاحية V-UTXOs الخاصة بك، لديك مواعيد نهائية للتفاعل مع ASP الخاص بك، وإلا فقد يختار ASP أخذ أموالك. هذا التفاعل لا يمكن أن يتم تفويضه أيضًا: بينما يحتوي Lightning علىwatchtowersالأشياء التي تثير الاستياء للأطراف الأخرى من محاولة خداعك - حتى إذا لم يكن قناتك متصلة بالإنترنت - يجب أن يستخدم مالكو عملة Ark مفاتيحهم الخاصة لتحديث الأموال بدون الحاجة إلى الثقة. أقرب شيء ممكن في Ark للبرج الذي يراقب هو التوقيع على المعاملات التي تسمح لبرج المراقبة بسحب أموالك بشكل منفرد على السلسلة نحو وقت الانتهاء، وهو يشمل تكلفة رسوم المعاملة الكبيرة.

ضع في اعتبارك ما يحدث ل V-UTXO إذا كان المالك غير متصل بالإنترنت: بعد انتهاء الجولة ، يحتاج ASP إلى استرداد الأموال لاستعادة سيولتها لجولات أخرى. إذا كان مالك V-UTXO غير متصل بالإنترنت ، فإن وضع V-UTXO على السلسلة له تكاليف معاملات كبيرة ، حيث يحتاج ASP الآن إلى استرداد الأموال على مستويات متعددة من شجرة V-UTXO. يمكن ل ASP إعادة إنشاء V-UTXOs غير المنفقة في جولة جديدة. لكن هذا ليس غير موثوق به من وجهة نظر مالكي V-UTXO ، حيث لا يمكنهم إنفاق V-UTXO دون الحصول على البيانات⁹من الممكن أيضًا أن يسجل ASP V-UTXOs غير المنفقة كرصيد وصاية. أو ربما لديه سياسة لحجز الأموال!

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

تقدم أرك

قد يكون من الممكن تقليل متطلبات السيولة في Ark من خلال عهود أكثر تقدما ، إذا كان من المعتاد استخدام السيولة جزئيا خلال الجولة. على سبيل المثال ، لنفترض أنه تم إنفاق 50٪ من إجمالي قيمة V-UTXO في تجمع txout. وإذا كان بوسع بنك آسيا والمحيط الهادئ أن يسترد هذا الجزء فقط من مجموع الجولة، فبوسعه أن يسترد السيولة بشكل أسرع، الأمر الذي من شأنه أن يقلل من تكاليف السيولة الإجمالية. على الرغم من عدم نشر أي مقترحات ملموسة حول كيفية القيام بذلك ، يبدو بالتأكيد أنه يجب أن يكون ممكنا مع العهود المتقدمة™ بما فيه الكفاية. على الأرجح من خلال نوع من الشوكة الناعمة لإحياء البرنامج النصي التي تضيف العديد من رموز التشغيل المفيدة في وقت واحد.

بالمثل، من خلال العهود المتقدمة بما فيه الكفاية يمكن استبدال هيكل شجرة txout بنوع من نظام السحب المتداول، مما قد يوفر مساحة بشكل محتمل. سنغطي هذا في قسم آخر، حيث أن هذه التقنية قد تكون مفيدة بشكل محتمل للمخططات الأخرى.

مسألة الحضانة في نهاية الجولة هي حالة أخرى يمكن لـ Sufficiently Advanced™ العهود حلها: يمكن أن تجبر العهدة ، وخاصة عهدة ZK-proof ، ASP على إعادة إنشاء جميع V-UTXO غير المنفقة في الجولة التالية ، مما يزيل مشكلة الحضانة التي تعود إليها في نهاية الجولة. على الرغم من أنه من غير المرجح أن يكون من الممكن جعل هذا غير معتمد على الثقة ، حيث سيحتاج المستخدم على الأرجح إلى بعض البيانات من ASP لإنفاق V-UTXO على الجولة الجديدة ، إلا أنه يمكن أن يمنع ASP من الحصول المالي من الاحتيال على المستخدمين غير المتصلين بالإنترنت.

دفع رسوم السلسلة في السحب الأحادي

مشابه للإضاءة، تحدد اقتصاديات دفع الرسوم على السلسلة والقيمة الفعلية لـ V-UTXO بعد الرسوم ما إذا كان استخدام Ark يلبي تعريفنا لـ L2 من خلال الانسحاب الأحادي أو الاحتيال الفاشل للاستفادة من ASP. سنناقش تفاصيل هذا بشكل أكبر عند مناقشة نمط تصميم شجرة txout.

طبقة التحقق

فئة كبيرة من التركيبات الشبيهة بالسلسلة الجانبية ، يقترح عموما استخدام أشكال مختلفة من تقنية إثبات المعرفة الصفرية (ZK) لفرض قواعد السلسلة. تقنية ZK المقاومة هي الفرق الحاسم بين تقنية تجميع الصلاحية والأشكال الأخرى من السلسلة الجانبية: إذا نجح مخطط ZK المضاد ، فيمكن ضمان صحة المعاملات عن طريق الرياضيات بدلا من الوثوق بطرف ثالث. إن جانب "المعرفة الصفرية" لإثبات ZK ليس في الواقع شرطا في حالة الاستخدام هذه: لا بأس تماما إذا كان الدليل "يتسرب" معلومات حول ما يثبته. يحدث فقط أن معظم المخططات الرياضية لهذه الفئة من الأدلة تصادف أنها براهين صفرية المعرفة.

من وجهة نظر بيتكوين ، يتطلب نظام الكشف عن الصحة الخروج من الصحة وعهدًا ، حيث نرغب في أن نتمكن من إنشاء UTXO للنظام يمكن إنفاقها فقط إذا تم اتباع قواعد النظام. هذه ليست بالضرورة عملية لامركزية. في الواقع ، العديد من أنظمة الكشف عن الصحة الخروج من الصحة هي تمامًا مركزية ؛ إثبات الكشف عن الصحة يثبت أن منفذ المعاملات المركزية اتبع قواعد تسلسل معينة من المعاملات.

فيما يتعلق بالعهد ... تقنية البرهان بدون معرفة لا تزال مجالًا جديدًا جدًا، مع استمرار التطورات بشكل متكرر. لذا، فمن غير المرجح تمامًا أن نرى أي أوبكود مضافة إلى بيتكوين تقوم بالتحقق مباشرة من أية مخططات محددة لبراهين بدون معرفة. بدلاً من ذلك، يُقبل عمومًا استخدام مخططات محددة بدلاً من ذلك باستخدام أوبكودات أكثر عمومية، على وجه الخصوص OP_CAT، للتحقق من براهين بدون معرفة عبر السكريبتات. على سبيل المثال، StarkWare هل الحملاتليتم اعتماد OP_CAT.

التمريرات الصحيحة هي موضوع كبير جدًا بامتياز، مع الكثير من المشاريع ذات القيمة المنخفضة / الضجيج العالي، لن نناقشها أكثر من إشارة إلى العمليات المحتملة التي تجعل هذا التصميم ممكنًا.

BitVM

بشكل تقريبي للغاية ، تعد BitVM طريقة لبناء قناة برق بين طرفين بحيث يتم فرض قواعد قناة Lightning من خلال دليل المعرفة الصفرية. نظرا لأنه لا يحتاج في الواقع إلى تعهدات ليتم تنفيذها على Bitcoin اليوم ، ولأنه لا يمكن استخدامه مباشرة لإنشاء نظام L2 يتجاوز حد 1-UTXO لكل مستخدم ، فلن نناقشه أكثر.

القنوات التسلسلية

القنوات الهرمية¹⁰ يهدف إلى جعل تغيير حجم القناة سريعا ورخيصا: "القنوات الهرمية تفعل لسعة القناة ما تفعله LN لعملة البيتكوين". ومع ذلك ، فإنها لا تزال لا تتجاوز بشكل أساسي حد 1 UTXO لكل مستخدم. كما أنها لا تتطلب أي تغييرات على بروتوكول Bitcoin على أي حال. لذلك لن نناقشها أكثر. يجب على مؤيديها ببساطة تنفيذها! إنهم لا يحتاجون إلى إذننا.

CoinPool

يسمح CoinPool لعدة مستخدمين بمشاركة UXXO واحد ، وتحويل الأموال بين مستخدمين مختلفين ، والسحب من جانب واحد. يتطلب اقتراح ورقة CoinPool ثلاث ميزات سوفت فورك جديدة ، SIGHASH_ANYPREVOUT ، SIGHASH_GROUP تسمح بتطبيق التوقيع فقط على UTXOs محددة ، OP_MerkleSub للتحقق من صحة إزالة فروع محددة من شجرة ميركل. يمكن أيضا تحقيق هذا الأخير مع OP_CAT.

في الوقت الحالي، يبدو أن تطوير CoinPool قد توقف، حيث كان آخر تعهد بالموقع الرسمي منذ عامين.

شبكة إنجما

في حين طُلب مني تغطية شبكة Enigma، يبدو أن هناك نقص في الوثائق بشأن ما هو الاقتراح حقًا. بتفينيكس مقالة في البلوقيقدم الكثير من الادعاءات؛ الصفحة معهد ماساتشوستس للتكنولوجيا فارغة. نظرا لأن منشور المدونة لا يوضح حقا ما يفترض أن يحدث بالضبط ، فلن نناقشه أكثر.

اعتبارات Mempool

سياسة ذاكرة التخزين المؤقت الحالية في Bitcoin Core ليست مثالية لأنظمة L2. هنا سنتناول بعض التحديات الرئيسية التي تواجهها، والتحسينات المحتملة.

تثبيت المعاملات

في نهاية المطاف ، يشير الاستغلال الاقتصادي ، هجمات تثبيت المعاملات ، إلى مجموعة متنوعة من المواقف حيث يمكن لشخص ما عمدا (أو عن غير قصدتجعل من الصعب الحصول على عملية تحويل مرغوب فيها نظرًا لبث عملية تحويل متعارضة لا تتم تعدينها مسبقًا. هذا هو استغلال اقتصادي، لأنه في حالة التثبيت الحقيقي للمعاملات، يوجد معاملة مرغوب فيها يمكن أن يستفيد منها المعدنون إذا قاموا بتعدينها؛ لكن المعاملة المتعارضة لا تتعدين في وقت معقول، إن تم تعدينها على الإطلاق.

أبسط مثال على التثبيت يأتي من حقيقة أنه بدون RBF الكامل ، يمكن إيقاف استبدال المعاملة. وبالتالي ، يمكن أن يكون لدينا معاملة منخفضة الرسوم ، مع إيقاف تشغيل الاستبدال ، والتي لن يتم تعدينها ولكن لا يمكن استبدالها. بشكل أساسي ، قامت 100٪ من طاقة التجزئة بإصلاح هذه المشكلة من خلال تمكين RBF الكامل ، وحتى كتابة هذا التقرير ، يجب تمكين RBF الكامل افتراضيا في الإصدار التالي من Bitcoin Core (بعد 11 عاما من الجهد!).

هذا يترك قاعدة BIP-125 الدبوس #3، المشكلة الوحيدة المتبقية المتعلقة ببروتوكولات L2 متعددة الأطراف والتي لم يتم حلها في نواة بيتكوين. للإشارة، تنص قاعدة BIP-125 الدبوس #3 على ما يلي:

يتطلب إجراء معاملة بديلة لدفع رسوم أعلى بشكل مطلق (ليس

معدل الرسوم فقط) أعلى من مجموع الرسوم المدفوعة بواسطة جميع المعاملات التي يتم استبدالها.

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

القاعدة # 3 يتم إصلاح التثبيت بسهولة إلى حد ما عبر معدل الاستبدال بالرسوم، ويعمل هذا الإصلاح في جميع المواقف. لسوء الحظ ، من غير الواضح ما إذا كان سيتم اعتماد RBFR بواسطة Core في المستقبل القريب ، حيث أنفقوا قدرا كبيرا من الجهد على حل جزئي أدنى ، معاملات TRUC/V3.

دفع الرسوم: RBF ، CPFP ، SIGHASH_ANYONECANPAY ، المراسي ، والرعاية

نظرا لأن معدلات الرسوم لا يمكن التنبؤ بها ، فإن الدفع بشكل موثوق واقتصادي في الحالات التي تكون فيها المعاملات موقعة مسبقا أمر صعب. المعيار الذهبي لدفع الرسوم هو استخدام RBF ، بدءا من تقدير أولي "منخفض الكرة" ، واستبدال المعاملة بإصدارات رسوم أعلى حسب الحاجة حتى يتم تعدينها. على سبيل المثال ، استخدم برنامج تقويم OpenTimestamps RBF بهذه الطريقة لسنوات ، وأضاف LND دعما ل الوعي بالموعد النهائي RBF في v0.18.

RBF هو المعيار الذهبي لدفع الرسوم لأنه الأكثر كفاءة في مساحة الكتلة في معظم الحالات¹¹الحالات: لا تحتاج المعاملة (المعاملات) البديلة إلى أي مدخلات أو مخرجات إضافية، مقارنة بما كان من الضروري إذا تم تخمين الرسوم الصحيحة في المحاولة الأولى.

الكفاءة مهمة، لأن عدم الكفاءة في دفع الرسوم يجعلدفع الرسوم خارج النطاق مصدر مربح للإيرادات لعمال المناجم الكبار ؛ لا يمكن لعمال المناجم الأصغر حجما واللامركزيين الاستفادة من مدفوعات الرسوم خارج النطاق بسبب عدم جدوى الدفع لعامل منجم صغير لتأكيد المعاملة. يبدو أيضا أن دفع الرسوم خارج النطاق يدعو إلى مشكلات AML / KYC: في الوقت الحالي ، تتطلب معظم أنظمة دفع الرسوم خارج النطاق المتاحة بالفعل في الوقت الحالي نوعا من عملية AML / KYC لدفع الرسوم ، مع استثناء ملحوظ من مسرع mempool.space، والتي حتى كتابة هذا التقرير (أغسطس 2024) ، تقبل Lightning بدون حساب.

للاستفادة من RBF مباشرة في حالات المعاملات الموقعة مسبقًا ، تحتاج إلى توقيع مسبق للرسوم المتغيرة التي تغطي مجموعة كاملة من الرسوم المحتملة. في حين أن هذا أمر ممكن تمامًا في كثير من الحالات حيث أن عدد الاختلافات اللازمة عادة ما يكون صغيرًا.¹²، حتى الآن بروتوكول Lightning للإنتاج - وبروتوكولات أخرى مقترحة - اختارت بدلاً من ذلك استخدام Child-Pays-For-Parent(CPFP)، عادة عبر مخرجات الرسن.

الفكرة وراء مخرج المرساة هي إضافة مخرج واحد أو أكثر إلى عملية تحويل بقيمة دنيا أو صفر، مع النية دفع الرسوم عن طريق CPFP بتخصيص هذه المخرجات في عمليات ثانوية. هذا بالطبع غير فعال عند تطبيقه على البروتوكولات مثل LN التي تتمتع بعمليات على سلسلة الكتل الصغيرة، تقريبًا.تضاعف حجم إجمالي التزام LN باستخدام معاملة تزامنية بناءاً على خرج مؤقت. سيكون أقل قلقًا عند تطبيق البروتوكولات التي تستخدم معاملات أكبر حجمًا ، مثل أي شيء يستخدم OP_CAT لتنفيذ العهود.

هناك مشكلة أقل وضوحا في مخرجات المرساة وهي الحاجة إلى الاحتفاظ ب UTXOs إضافية لدفع الرسوم بها. في تطبيق "العميل" النموذجي ، يمكن أن يكون هذا عبئا إجماليا كبيرا ، لأنه بدون مخرجات المرساة ، لا توجد حاجة على الإطلاق للحفاظ على أكثر من UTXO واحد. في الواقع ، من المحتمل أن تكون بعض محافظ Lightning الحالية التي تركز على المستهلك عرضة للسرقة من الجانب البعيد من القناة في بيئات عالية الرسوم بسبب عدم القدرة على دفع الرسوم.

يمكن استخدام SIGHASH_ANYONECANPAY لدفع الرسوم في بعض الحالات عن طريق السماح بإضافة مداخل إضافية إلى المعاملات الموقعة؛ يسمح SIGHASH_SINGLE أيضًا بإضافة المخرجات. يستخدم البرق هذا لمعاملات HTLC. في الوقت الحالي يمكن أن تكون هذه الممارسة عُرضة للتعرض للتثبيت إذا لم يُعالج بعناية.¹³، حيث يمكن للمهاجم إضافة عدد كبير من المدخلات و/أو المخرجات إلى عملية تحويل لإنشاء دبوس برسوم عالية/معدل رسوم منخفض. يحل RBFR هذه المشكلة؛ النهج المستخدم في عمليات TRUC/V3 غير قادر على حل هذه المشكلة. هذا النوع من طرق الدفع بالرسوم ليس بفعالية RBF. ولكن يمكن أن يكون أكثر كفاءة من مخرجات الرصيد الأكثر تثبيتًا.

وأخيراً، هناك مجموعة متنوعة من اقتراحات الفورك الناعمة لإضافة طبقة 2.رعاية الرسوم النظام إلى بروتوكول بيتكوين. سيسمح هذا للمعاملات بالإعلان عن التبعيات على المعاملات الأخرى ، بحيث لا يمكن تعدين معاملة الراعي إلا إذا تم تعدين المعاملة الممولة أيضا (على الأرجح في نفس الكتلة). قد يكون هذا أكثر كفاءة من CPFP التقليدي حيث يمكن للمعاملة الراعية أن تعلن أن التبعية باستخدام vbytes أقل بكثير من حجم إدخال المعاملة.

ركوب الدراجة البديل

الهجوم البديل للدراجات¹⁴يستغل استبدال المعاملات لمحاولة استبدال معاملة L2 المطلوبة بما يكفي لتعدين واحدة غير مرغوبة بدلاً منها. بشكل أساسي ، هجمات استبدال الدورات هي بالنسبة للمهاجم بديل لتقنيات تثبيت المعاملات في أنها تهدف إلى منع المعاملة المطلوبة والصادقة من التعدين بما فيه الكفاية للسماح بتعدين معاملة غير مرغوبة وغير صادقة بدلاً من ذلك. على عكس هجمات تثبيت المعاملات ، لا يمكن حدوث هجوم استبدال دورات بطريقة عرضية.

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

يستفيد تبديل الدورة الدراجية من ذلك باستخدام صورة ما قبل انتهاء المهلة ، لاستبدال المعاملة التي تحاول استرداد إخراج HLTC عبر آلية المهلة دون أن يتعلم الضحية الصورة المسبقة. يقوم هجوم تبديل الدورة الدراجية الناجح بذلك لفترة كافية لانتهاء مهلة HTLC لقناة مختلفة.

تحد رئيسي في استغلال دورة الاستبدال بشكل مربح هو أن كل جولة استبدال تكلف مالاً. ستنفق تنفيذ Lightning المدرك للموعد رسومًا أعلى وأعلى في محاولة إنفاق إخراج HTLC المنتهي قبل انتهاء صلاحية الإخراج HTLC التالي بدوره. ثانيًا، يمكن لأي شخص هزيمة الهجوم عن طريق بث الصفقة المستبدلة ببساطة¹⁵بمجرد الانتهاء من دورة الاستبدال.

كما هو الحال مع تثبيت المعاملات، فإن دورة الاستبدال أيضًا عبارة عن استغلال اقتصادي على العمالقة. في نهاية كل دورة استبدال، توجد معاملة تمت إزالتها من mempools، ومع ذلك فهي صالحة تمامًا ويمكن تعدينها إذا كان العمالقة لا يزالون يمتلكونها في mempools الخاصة بهم.

أنماط الميزات والشوكات الناعمة

الآن بعد أن قدمنا لك نظرة عامة على مجموعة متنوعة من نظم L2 التي تعتمد على العهد ، وتحديات mempool ، سنحاول تلخيص تلك المعلومات إلى مجموعة من الميزات القابلة للانحناء الملحوظة (بشكل رئيسي التعليمات البرمجية الجديدة) وأنماط التصميم التي تشترك فيها تلك النظم L2. بالنسبة لاقتراحات الشوكة اللينة ، سنناقش أيضًا المخاطر التقنية الخاصة بكل اقتراح والتحديات المتعلقة بنشر كل اقتراح.

OP_Expire

سنتخطى هذا الأمر أولاً. تم اقتراح OP_Expire¹⁶ كطريقة بسيطة للقضاء على هجوم ركوب الدراجات البديل عن طريق إصلاح المشكلة في المصدر: حقيقة أنه يمكن إنفاق HTLC بطريقتين مختلفتين في وقت واحد. في سياق أنظمة L2 ، يكون هذا مناسبا لأي شيء يستخدم آلية تشبه HTLC ، وربما حالات استخدام أخرى. OP_Expire من شأنه أن يجعل من الممكن أن يكون ناتج المعاملة غير قابل للإنفاق بعد نقطة زمنية ، مما يسمح لشروط إنفاق HTLC بأن تكون حصرية حقيقية - OR بدلا من "مبرمجين OR".

الحقيقة أن حدث خلل ناعم في OP_Expire من المحتمل أن يتكون من ميزتين، على غرار كيف OP_CheckLockTimeVerifyوOP_CheckSequenceVerifyالأكواد العملية تأتي في جزئين:

1. حقل ارتفاع انتهاء صلاحية للمعاملات، من المرجح تنفيذه في ملحق تابروت.
2. تعليمات OP_انتهت الصلاحية التي تحقق أن ارتفاع انتهاء الصلاحية مضبوط على الأقل إلى الارتفاع المطلوب.

بينما OP_Expire نفسه لا يؤهل تماما كعهد، يبدو أنه مفيد للعديد من الأنظمة L2 التي تعتمد على العهد. ومع ذلك، قد لا يكون مفيدًا بما فيه الكفاية بحيث يمكن أيضًا تخفيف تكرار الاستبدال عن طريق إعادة البث البديلة العطوفة¹⁵

تحدي ملحوظ جدًا في نشر واستخدام OP_Expire هو إعادة التنظيم: المجتمع التقني لبيتكوين، بداية من ساتوشي¹⁷، حاولت التأكد من أن بروتوكول الاتفاق على بيتكوين مصمم بطريقة تتيح بعد إعادة تنظيم عميق، يمكن تعدين المعاملات المستخرجة سابقًا في كتل جديدة. تحاول هذه الرؤية أن تتجنب سيناريو الكوابيس الذي يؤدي إلى أن يصبح عدد كبير من العملات المؤكدة غير صالحة بشكل دائم - وبالتالي يفقد الناس المال الذي يعتمدون عليه - إذا أدى فشل الاتفاق إلى إعادة تنظيم كبيرة.

في حالة إعادة التنظيم الكبيرة ، يمكن أن تصبح المعاملات التي تستخدم انتهاء الصلاحية غير قابلة للتعديل بسبب الوصول إلى ارتفاع انتهاء صلاحيتها. يقترح اقتراح OP_Expire تخفيف هذه المشكلة من خلال معالجة مخرجات المعاملات التي تستخدم انتهاء الصلاحية بشكل مشابه لمعاملات coinbase ، مما يجعلها أيضا غير قابلة للإنفاق على ~ 100 كتلة.

تعتبر عائقاً كبيراً لنشر انتهاء صلاحية المعاملات هو التوصل إلى اتفاق حول ما إذا كان هذا التضحية مقبولًا، أو حتى مطلوبًا. أنواع المعاملات التي ستكون OP_Expire مفيدة بالفعل تشمل فترات انتهاء صلاحية طويلة حيث تتجمد أموال المستخدم. إضافة المزيد من الوقت إلى هذه الفترات غير مرغوب فيه. أيضًا، كانت المعاملات المزدوجة دائمًا وسيلة أخرى لإبطال القطع بعد إعادة التنظيم: مع الاستخدام المتزايد لـ RBF والاستخدام المقترح لمخرجات الأنكور بدون مفتاح، هل سيحدث انتهاء صلاحية المعاملة فرقاً كبيراً؟

SIGHASH_ANYPREVOUT

بيب-118 يقترح وضعين جديدين لتجزئة التوقيع ، وكلاهما لا يلتزم ب UTXO المحدد الذي يتم إنفاقه. SIGHASH_ANYPREVOUT ، الذي يلتزم (بشكل أساسي) بالبرنامج النصي PubKey بدلا من ذلك ، و SIGHASH_ANYPREVOUTANYSCRIPT ، الذي يسمح بأي برنامج نصي. كما نوقش أعلاه ، تم اقتراح هذا في الأصل للاستخدام من قبل LN-Symmetry لتجنب الحاجة إلى التوقيع بشكل منفصل على كل حالة قناة سابقة قد تحتاج إلى التفاعل معها.

SIGHASH_ANYPREVOUT مفيد أيضًا في الحالات التي نريد فيها استخدام الإصدارات المتغيرة لمعدل الرسوم RBF الموقعة مسبقًا بالاقتران مع المعاملات الموقعة مسبقًا، حيث أن حقيقة أن التوقيع لم يعد يعتمد على txid محدد يتجنب انفجار اندماجي لمتغيرات معدل الرسوم. ومع ذلك، فإن اقتراح BIP-118 الحالي لا يتناول هذا الاستخدام، وقد يكون غير متوافق معه بسبب حقيقة اقتراح SIGHASH_ANYPREVOUT للتزام أيضًا بقيمة UTXO.

كانت الاعتراض الأولي على SIGHASH_ANYPREVOUT فكرة أن المحافظ ستواجه مشاكل بسبب استخدامها بطرق غير مناسبة. المشكلة هي أنه بمجرد نشر توقيع واحد لـ SIGHASH_ANYPREVOUT ، يمكن استخدامه لإنفاق أي txout بالنص المحدد. وبالتالي ، إذا تم إنشاء إخراج ثاني بنفس النص بطريقة عرضية ، فإن SIGHASH_ANYPREVOUT يسمح بشكل تراكمي بسرقة تلك العملات. ومع ذلك ، نظرًا لوجود العديد من المخاطر الأخرى المرتبطة بالمحافظ وتنفيذات L2 ، يبدو أن هذا القلق قد انتهى.

في الوقت الحالي، يبدو أن المجتمع التقني العام إيجابي بشكل معقول حول تنفيذ BIP-118. ومع ذلك، كما تم مناقشته أعلاه في مناقشتنا حول LN-Symmetry، هناك جدل حول ما إذا كانت حالته الرئيسية - LN-Symmetry - فكرة جيدة بالفعل.

OP_CheckTemplateVerify

يهدف اقتراحنا الأول لرمز التشغيل الخاص بالعهد ، OP_CheckTemplateVerify - أو "CTV" كما يشار إليه عادة - إلى إنشاء رمز تشغيلي محدد للغاية ومقيد للعهد من خلال القيام بشيء واحد بالضبط: تجزئة معاملة الإنفاق بطريقة محددة لا تلتزم بإدخال UTXOs ، والتحقق من الملخص الناتج مقابل عنصر المكدس العلوي. وهذا يسمح بتقييد معاملة الإنفاق مقدما ، دون جعل قيود العهد العودية الحقيقية ممكنة.

لماذا لا يكون العهود العائدة ممكنة في CTV؟ لأن وظائف التجزئة: يقوم CTV بفحص عملية الإنفاق مقابل تجزئة القالب ولا يوجد طريقة¹⁸إنشاء قالب يحتوي على CTV مع تجزئة لنفسها.

ذلك قال، هذا ليس بالضرورة قيدًا حقيقيًا: يمكنك بسهولة تجزئة سلسلة من تجزئات قوالب CTV لعمق عشرات الملايين من المعاملات في ثوانٍ فقط على جهاز كمبيوتر حديث. مع الأقفال الزمنية النسبية nSequenceويمكن بسهولة جعل الحجم الكتلي المحدود الفعلي الوصول إلى نهاية مثل هذه السلسلة يستغرق آلاف السنين.

مقترح CTV الحالي في BIP-119يحتوي على وضع تجزئة واحد فقط، المعروف باسم DefaultCheckTemplateVerifyHash، والذي يلتزم في الأساس بكل جانب من جوانب عملية الإنفاق في تجزئة الهاش. من وجهة نظر عملية، يعني هذا أن الآلية الوحيدة المتاحة في العديد من الحالات لدفع الرسوم ستكون CPFP. كما ذكر أعلاه، هذه مشكلة محتملة بسبب إنها تجعل دفع الرسوم خارج النطاق توفير تكلفة غير ثابتة في الحالات التي تكون فيها المعاملات المستخدمة لـ CTV صغيرة.

من العادل القول بأن CTV لديها أوسع دعم بين المجتمع التقني من أي مقترح لكود العهد بسبب بساطتها النسبية ومجموعة واسعة من حالات الاستخدام.

LNHANCE

أحد المقترحات لتنفيذ CTV هو دمجها مع اثنين من رموز التشغيل الأخرى ، OP_CheckSigFromStack (تحقق) و OP_InternalKey. المشكلة هي ، حتى كتابة هذا التقرير ، أن الوثائق الموجودة في هذا السحب و BIPs المرتبطة به ببساطة ليست كافية للمجادلة لصالح أو ضد هذا الاقتراح. تفتقر BIPs تماما إلى أي منطق لما يتوقع أن تفعله رموز التشغيل بالفعل في أمثلة العالم الحقيقي ، ناهيك عن البرامج النصية المتعمقة.

على الرغم من أن لدى المؤلفين أسباب جيدة ربما لاقتراحهم، إلا أن المسؤولية تقع عليهم في تفسير هذه الأسباب وتبريرها بشكل مناسب. وبالتالي لن نناقشها بشكل أكبر.

OP_TXHASH

مشابهًا لـ CTV ، تحقق هذه الاقتراحات وظيفة العهد غير المتكررة من خلال تجزئة البيانات من صفقة الإنفاق. على عكس CTV ، يوفر اقتراح TXHASH آلية "محدد حقل" ، مما يسمح بالمرونة في تحديد كيفية تقييد صفقة الإنفاق بالضبط. تحقق هذه المرونة هدفين رئيسيين:

1. تمكين إضافة الرسوم إلى عملية تحويل دون كسر بروتوكول متعدد التحويل.
2. بروتوكولات متعددة المستخدمين حيث يقيد المستخدمون فقط مدخلاتهم ومخرجاتهم الخاصة.

المشكلة الرئيسية مع OP_TXHASH هي أن آلية اختيار الحقل تضيف الكثير من التعقيدات، مما يجعل عمليات المراجعة والاختبار تحديًا مقارنة بالاقتراح CTV الأبسط بكثير. في الوقت الحالي، لم يكن هناك الكثير من تحليل التصميم على كمية الفوائد التي ستقدمها آلية اختيار الحقل بالفعل، أو كيف ستستخدم بالضبط. وبالتالي، لن نناقشها بشكل أوسع.

OP_CAT

عامل الدمج ، الذي يدمج العنصرين الأعلى في الكومة ويدفع النتيجة المدموجة مرة أخرى في الكومة. شحن بيتكوين الأصلي مع OP_CAT ممكّن. ولكن ساتوشيتمت إزالته بصمت في عام 2010، ربما بسبب حقيقة أن التنفيذ الأولي كان عرضة لهجمات DoS بسبب عدم وجود قيود على حجم عنصر البرنامج النصي الناتج. يرجى النظر في البرنامج النصي التالي:

DUP CAT DUP CAT…

بدون قيود حجم العنصر، تضاعف كل تكرار لـ DUP CAT حجم عنصر قمة الكومة، مستخدمًا في النهاية كل الذاكرة المتاحة.

الدمج كافٍ لتنفيذ العديد من أنواع العهود، بما في ذلك العهود العامة، من خلال القيام بما يلي:

1. قم بتجميع تحويلة جزئية، بدون بيانات الشاهد، على الكومة بواحدة أو أكثر من استدعاءات OP_CAT (وأي منطق محدد للعهد اللازم).
2. تحقق من أن المعاملة في الكومة تطابق المعاملة النفقات.

كما تبين، بواسطة إساءة استخدام رياضيات توقيعات Schnorr، من الممكن أداء الخطوة الثانية باستخدام OP_CheckSig من خلال توقيعات مُشكلة بعناية. ومع ذلك، من المرجح أكثر أن يتم دمج الفورك الناعم OP_CAT مع OP_CheckSigFromStack، مما يسمح بأداء الخطوة الثانية عن طريق التحقق من أن التوقيع على الستاك هو توقيع صالح للصفقة¹⁹، ثم إعادة استخدام نفس التوقيع مع OP_CheckSig للتحقق من أن صفقة الإنفاق تتطابق.²⁰

حقيقة أننا نحتاج فقط إلى تجميع المعاملة بدون بيانات الشاهد هي نقطة محورية: العهد يحتاج فقط إلى التحقق مما تفعله المعاملة - إدخالاتها ومخرجاتها - وليس بيانات الشاهد (إن وجدت) التي تجعلها صالحة في الواقع.

بالإضافة إلى حدود حجم البرنامج النصي ، تكفي مزيج OP_CAT و OP_CheckSigFromStack لبناء العديد من أنواع العهود ، بما في ذلك العهود الدوائرية. بالمقارنة مع حلول أكثر كفاءة مثل CTV ، فهو أكثر تكلفة. ولكن الفرق في التكلفة أقل مما تتوقعه!

بشكلٍ تقريبي، يتطلب استخدام OP_CAT للقيام بذلك وضع كل جزء غير الشاهد من عملية الإنفاق على الشكل عبر الشاهد. بالنسبة لحالات استخدام CTV النموذجية مثل أشجار txout، فإن عملية الإنفاق لن تحتوي على بيانات شاهد على الإطلاق. نظرًا لأن مساحة الشاهد مخفضة بنسبة 75%، فإن ذلك يزيد من رسوم المعاملات الفعالة لعملية الإنفاق الفرعية بنسبة 25% فقط. ليس سيئًا!

هل OP_CAT قوي جدًا؟

ربما تكون هذه أكبر عقبة سياسية وتقنية أمام نشر OP_CAT: من الصعب جدا التنبؤ بحالات الاستخدام التي ستصبح ممكنة بحلول عام OP_CAT. وبمجرد خروج "القطة" من الكيس ، من الصعب جدا إعادتها.

مثال رائع هو كيف يُزعم أن OP_CAT كافٍ للسماح بكفاءة معقولة وآمنةالتحقق من STARK سيتم تنفيذه في سكريبت بيتكوين. نظرًا لأن STARKs قادرة على إثبات عبارات عامة للغاية ، فإن جعل STARKs قادرة على التنفيذ بكفاءة له عواقب هامة تتجاوز نطاق أنظمة L2 حيث سيسمح ببناء العديد من الأنظمة المختلفة على بيتكوين. وهو حجة قوية ضد OP_CAT هو أن هذه الحالات الاستخدام قد لا تكون جيدة بشكل عام لمستخدمي بيتكوين.

يعد إنشاء قيمة قابلة للاستخراج لعامل منجم مركزي ضار مشكلة محتملة رئيسية ، المسمى "MEV الشرير" (MEVil)بقلم مات كورالو. MEVil بإختصار هو أي ظرف يمكن للمنقبين / المجموعات الكبيرة إستخراج قيمة إضافية عن طريق توظيف إستراتيجيات تعدين الصفقات المعقدة - بعيداً عن تحقيق أقصى قيمة للرسوم - والتي يصعب على المنقبين / المجموعات الأصغر إعتمادها. تعقيد الأدوات المالية المحتملة التي يمكن إنشاؤها باستخدام OP_CAT يجعل من الصعب جدًا استبعاد MEVil. ظهر MEVil الكبير بالفعل على بيتكوين من بروتوكولات مزاد الرموز الرقمية ؛ لحسن الحظ ، تم هزيمة هذه الحالة المحددة من خلال تبني full-RBF.

بالإضافة إلى إمكانية MEVil، هناك العديد من حالات الاستخدام العملية الأخرى لـ OP_CAT التي قد تكون ضارة بشكل محتمل. على سبيل المثال، تم تقديم اقتراح Drivechains تمت مراجعتها هنا, ويُعتبر عمومًا ضارًا لبيتكوين. إنها معتقد أنه ممكنلتنفيذ Drivechain’s مع OP_CAT. مثال آخر هو اقتراحات الرموز مثل Taproot Assets. على الرغم من أنه من المستحيل بشكل عام منع تنفيذها مع التحقق من الجانب العميل، هناك اقتراحات لتنفيذها بواسطة OP_CAT بطرق قد تكون أكثر جاذبية للمستخدمين النهائيين ، وفي الوقت نفسه باستخدام المزيد من مساحة الكتلة ، مما يمكن أن يتفوق على المعاملات البيتكوين الشرعية. قد تؤدي هذه الحالات الاستخدامية أيضًا إلى مشكلات قانونية بسبب تكرار استخدام بروتوكولات الرمز للغش المالي.

تجزئة تدريجية

بالنسبة للعهود، سيتم استخدام OP_CAT في المقام الأول لربط البيانات، ثم تجزئتها. طريقة أخرى لتحقيق نفس الهدف هي باستخدام نوع ما من عملية التجزئة التدريجية التي تأخذ SHA256 منتصفية من نوع ما، وتجزئة المزيد من البيانات إليه؛ يعمل SHA256 نفسه على كتل بحجم 64 بايت. هناك العديد من التصاميم الممكنة لعمليات التجزئة التدريجية.

أحد قرارات التصميم المهمة هو ما إذا كان سيتم عرض وحدات البايت الفعلية في منتصف الحالة على المكدس في نوع من الشكل الأساسي أم لا ، أو تمثيلها في نوع جديد من نوع عنصر المكدس غير الشفاف الذي لا يمكن التلاعب بقيمة البايت الفعلية الخاصة به مباشرة. تم تحديد SHA256 لمتجه تهيئة معين وثابت ويبدو أنه من غير المعروف ما إذا كانت خصائص تشفير SHA256 صحيحة أم لا إذا تم السماح بمتجهات التهيئة / التهيئة التعسفية.

بالطبع، نظرًا لأن التجزئة التدريجية يمكنها فعل ما يقدر أن يفعل OP_CAT تقريبًا، فقط بكفاءة أكبر، فإنها تشارك جميع القلق بشأن OP_CAT كونها قوية للغاية.

إحياء النص

OP_CAT كانت واحدة من 15 opcode قام ساتوشي بتعطيلها. بالإضافة إلى استعادة OP_CAT ، يقترح راستي راسل.²¹لإعادة بشكل أساسي نص بيتكوين إلى "رؤية ساتوشي الأصلية" من خلال إعادة تمكين معظم تلك الترميزات العملية، وإضافة حدود DoS، وإضافة بعض الترميزات الإضافية المحتملة في نفس الفورك بشكلٍ خاص، من المحتمل وجود OP_CheckSigFromStack.

في حين أن OP_CAT وحدها تجعل العهود (المتكررة) ممكنة ، فإن "إحياء النص" الكامل من شأنه أن يجعل العهود الأكثر تعقيدا ممكنة - وأسهل بكثير في التنفيذ - حيث يمكن التلاعب بأجزاء من معاملة الإنفاق مباشرة. على سبيل المثال ، يمكنك تخيل برنامج نصي للعهد يستخدم أكواد العمليات الحسابية للتأكد من أن القيمة الإجمالية ل txouts في المعاملة تلتزم ببعض الخصائص المطلوبة.

مرة أخرى، يثير إحياء النص جميع المخاوف نفسها، وأكثر، حول كونه قويًا بشكل مفرط يفعل OP_CAT وحده.

بساطة

تشابهًا مع Script Revival ، فإن البساطة ذات صلة بـ L2 والعهود من خلال جعلها ممكنة للقيام بأي شيء. على عكس إحياء Script ، فإن soft-fork لـ Simplicity سيضيف لغة برمجة جديدة تمامًا إلى نظام Scripting لـ Bitcoin استنادًا إلى تسعة عوامل بدائية معروفة باسم combiners.

في الواقع، البساطة هي بسيطة جدًا، وليست بسيطة على الإطلاق. الجمعيات الأساسية هي منخفضة المستوى للغاية بحيث يجب تنفيذ العمليات الأساسية مثل الجمع بصورة مضنية من البداية. لذا، سيكون البرنامج النصي الأساسي لـ Simplicity طويلًا جدًا في الواقع. وبالتالي، فإن أي استخدام حقيقي لـ Simplicity سيستخدم نظامًا من الاستبدالات البرمجية، مثل استدعاءات دوال المكتبة، والمعروف باسمjets. يشكل هذا مشكلة عملية / سياسية: كيف تقرر أي الطائرات المقاتلة تنفيذها؟ من المرجح أن تتم تنفيذ الطائرات المقاتلة بلغة C++ ، مثل أي كود أوبكود آخر ، مما يتطلب شوكة ناعمة لكل طائرة مقاتلة جديدة.

OP_FancyTreeManipulationStuff

هناك تشكيلة واسعة من الأوبكود المتخصص نسبيًا المقترحة للقيام بعمليات تلاعب بالأشجار بطريقة فعالة من حيث المساحة للاقتراحات الطبقية L2 المعتمدة على العهد. على سبيل المثال ، اقترح Coinpools كل منTAPLEAF_UPDATE_VERIFY و OP_MERKLESUB، وكلاهما يتحكم في أشجار التابروت بالطرق اللازمة لاقتراح Coinpools، و ماتقد اقترحت اقتراحًا لعملية OP_CheckContractVerify التي تتحقق في الأساس من البيانات حول أشجار ميركل.

من أجل أغراض هذه المقالة، ليس من الضروري أن ندخل في تفاصيل كل واحدة من هذه الاقتراحات العديدة. بدلاً من ذلك، يمكننا الحديث عنها كمجموعة: جميعها اقتراحات نوع الاستخدام النسبي التي تجعل فئة واحدة من L2 ممكنة، في الأفضلية دون آثار جانبية غير مقصودة. جميعها لديها ميزة الكفاءة: جميعها تستخدم مساحة كتلية أقل من تحقيق نفس الهدف باستخدام عمليات تحريك OP_CAT الأكثر عمومية. ولكن لديها جميعًا عيب إضافة تعقيدات إلى نظام النصوص، لحالة استخدام محتملة بشكل نيش.

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

حمامات الصندوق

يمكن اعتبار جميع أنظمة L2 التي تحاول مشاركة عدة مستخدمين في UTXO واحد نوعا من تجمع الأموال متعدد المستخدمين ، حيث يمتلك المستخدمون نوعا من حق الانسحاب. من المحتمل أن تكون هناك أيضا آلية لإضافة أموال إلى المجمع (بخلاف إنشاء المجمع بأموال مخصصة مسبقا).

لكي يكون تجمع الأموال مفيدا ، يجب أن يحتوي على نوع من "حالة بيانات المشاركة" المرتبطة به: كيف يتم تقسيم قيمة txout؟ إذا كان لمجمع الأموال أن يتطور بمرور الوقت ، فيجب أن تتغير هذه الحالة أيضا مع إضافة الأموال أو إزالتها من المجمع. نظرا لأننا نبني على Bitcoin ، فإن إضافة أو إزالة الأموال من المجمع سيتضمن حتما إنفاق UTXO على عناصر التحكم في المجمع.

تذكر أن نظام الاتفاق في بيتكوين يعتمد بشكل أساسي على التحقق من تغييرات الحالة: تثبت المعاملات من خلال شهودها أن التغييرات في حالة مجموعة UTXO صالحة. يتيح لنا إثبات العمل التوصل إلى اتفاق حول مجموعة من المعاملات الصحيحة. هذا يعني أن حمامات الأموال ستعتمد أنفسها أيضًا على التحقق من تغييرات الحالة: نثبت لكل عقدة بيتكوين أن القواعد المتعلقة بحوض الأموال يتم اتباعها في كل تغيير في الحالة.

ولكن هناك جانب آخر مهم لحمامات الأموال طبقة 2 الغير قابلة للتحقق: عندما يتغير حال حوض الأموال، يجب أن يقوم النظام بنشر البيانات الكافية بشكل طبيعي للمستخدمين الذين يشاركون في حوض الأموال لاستعادة أموالهم. إذا لم نفعل ذلك، فإن نظامنا يفشل في توفير السحب الأحادي، دون تعاون الأطراف الثالثة. تفشل العديد من الخطط المعتمدة على اللفائف هنا: إنها تعاني من فشل في توفر البيانات، حيث يتعذر على المستخدم استعادة أمواله إذا تعطلت المنسقون من الأطراف الثالثة، لأنهم ليس لديهم وسيلة للحصول على البيانات اللازمة لإنشاء صفقة استعادة أموال صالحة.

مع وضع هذه القيود في الاعتبار ، ما هي هياكل البيانات التي ستستند إليها مجمعات الأموال؟ حتما ، كلهم نوع من الأشجار. على وجه التحديد ، نوع من شجرة ميركل. يجب أن تكون شجرة ، لأن هذا هو إلى حد كبير بنية البيانات الوحيدة القابلة للتطوير في علوم الكمبيوتر. يجب أن يتم دمجهم ، لأن هذه هي الطريقة الوحيدة المعقولة للالتزام المشفر بحالة الشجرة. أخيرا ، سيتم نشر تحديثات الشجرة حتما على blockchain Bitcoin ، لأن هذا هو الذي وسيلة نشرجميع مستخدمي L2 يشتركون فيها، وهي الوحيدة التي يمكننا أن نجبر المستخدمين على نشرها لنقل العملات. ولأن أي تنفيذ للعهد سيحتاج إلى أجزاء من الشجرة للتحقق من أن قواعد العهد تُتبع.

إذا، مع نظرية المستوى العالي التي تم التعامل معها، كيف يتم ترجمة هذا فعليًا إلى نصوص بيتكوين ومعاملات؟

المعاملات الفردية الموقعة مسبقًا

الحالة المنحطة لشجرة ، مع ورقة واحدة بالضبط فيها. هنا يمكن أن تتغير حالة مجمع الصناديق لدينا ، بشكل تقريبي ، مرة واحدة. على سبيل المثال ، تقع قناة Lightning القياسية في هذه الفئة ، وبمجرد فتحها ، لا يمكن إغلاقها إلا. البيانات التي يتم نشرها عند إغلاق القناة هي المعاملة نفسها ، وهي معلومات كافية للطرف المقابل في القناة لتعلم txid من بيانات blockchain ، واسترداد أموالهم عن طريق إنفاقها.

العهد الوحيد المطلوب هنا هو العهد الأساسي الأكثر أهمية: المعاملة الموقعة مسبقًا.

أشجار Txout

نمط التصميم التالي، وهو أكثر تعقيدًا، الذي نراه في حمامات الصندوق هو شجرة txout. Ark هو مثال بارز. هنا يمكن تقسيم حمام الصندوق عن طريق إنفاق UTXO الجذر في شجرة من المعاملات المحددة مسبقًا، والتي يتم فرضها باستخدام عهود بسيطة مثل المعاملات الموقعة مسبقًا أو CTV، مقسمة قيمة تلك UTXO إلى مبالغ أصغر وأصغر حتى يتم الوصول إلى العقد الورقية التي يمكن إنفاقها من قبل أصحابها بحق.

من المهم أن ندرك أن الغرض من شجرة txout هو منح المستخدمين خيارات حول كيفية استرداد أموالهم ، وهذه الخيارات تأتي بتكلفة: ستكون شجرة txout دائما طريقة أكثر تكلفة لتقسيم مجموعة من الأموال ، وإعادتها إلى أصحابها ، من مجرد تقسيم UTXO في معاملة واحدة. تضيف كل طبقة في الشجرة تكلفة بسبب البايتات المستخدمة في txouts و txins اللازمة لإنشاء تلك الطبقة.

إذاً، ما هي الخيارات التي يمكن أن يوفرها شجرة txout؟ مرة أخرى ، Ark هو مثال رائع: لا نريد أن يتطلب استرداد V-UTXO واحد في السلسلة أن يتم وضع كل V-UTXO واحد في السلسلة. باستخدام شجرة ، يمكن تقسيم الاسترداد إلى أجزاء أصغر حتى يتم وضع V-UTXO المطلوب في السلسلة.

مشابهة لحالة المعاملة الموقّعة مسبقًا من قِبَل الفرد، المعلومات المُنشَرة هي المعاملات نفسها، التي تُخبر محفظة المستخدمين الآخرين كيفية إنفاق أموالهم إذا لزم الأمر.

قابلية التوسع لأشجار txout لها وفورات حجم مثيرة للاهتمام. تكلفة أول V-UTXO يتم وضعها على السلسلة ، في مجمع صناديق مع n V-UTXOs ، هي تقريبا log2 (n) log2 (n) أكثر تكلفة من معاملة واحدة حيث يجب وضع مستويات log2 (n) للمعاملات المقسمة على سلسلة. ومع ذلك ، بمجرد وضع V-UTXO الأول على السلسلة ، تصبح V-UTXOs اللاحقة أرخص في الاسترداد على السلسلة لأن شخصا آخر قد دفع بالفعل تكلفة استخراج المعاملات الوسيطة.

تذكر أن العدد الإجمالي للعناصر في شجرة بيانية ثنائية الأبعاد مع

عدد الأوراق هو 2n. هذا يعني أنه لوضع جميع V-UTXOs على السلسلة ، سيكون التكلفة الإجمالية للقيام بذلك عبر شجرة txout مضاعفة صغيرة للتكلفة الإجمالية للقيام بذلك في عملية واحدة. فعالة بشكل مدهش!

أو ربما لا... إذا كان حجم إجمالي استرداد حوض الأموال كافياً ، فقد يمثلون طلبًا غير تافه على إجمالي مساحة الكتلة. مساحة الكتلة نظام العرض والطلب ، لذلك في نقطة ما سترتفع الرسوم بسبب الطلب العالي. في الحد الأقصى ، من الممكن تكوين أشجار txout كبيرة وعميقة لدرجة أن استرداد كل شيء فعليًا...

في الشجرة ، من غير الممكن أن يكون هناك V-UTXO.

سؤال مفتوح حول أشجار txout هو من يدفع الرسوم وكيف؟ حل واحد واضح هو استخدام النواتج المرجعية بدون مفتاح في المعاملات الورقية ، والسماح لأي شخص يرغب في تعدين المعاملات الورقية بدفع الرسوم عبر CPFP. في بعض حالات الاستخدام ، يمكن إنفاق V-UTXOs نفسها فور إنشائها ، دون تأخير CSV ، لذا يمكن إنفاق V-UTXOs نفسها لإضافة الرسوم عبر CPFP.

RBF معقد للتنفيذ بسبب الإذن: المكان الواضح لأخذ رسوم RBF هو قيمة V-UTXO. ولكن كيف يمكنك التأكد من أن المالك فقط لديه القدرة على التوقيع على معاملة رسوم أعلى؟ في كثير من الحالات ، ليس من الواضح كيفية القيام بذلك بطريقة أكثر كفاءة من إخراج مرساة بدون مفتاح. ومع ذلك ، فإن الفشل في القيام بذلك يشكل تحديات خطيرة للمخططات التي تستخدمها محافظ المستخدم النهائي ، والتي قد لا يكون لديها UTXO لإنفاقها لأداء CPFP ، إذا كان لا يمكن إنفاق V-UTXOs نفسها على الفور.

أخيرًا ، يجب وضع التفكير الدقيق في المحافظة على الحوافز الموجودة في أنظمة شجرة txout ، مع مراعاة دفع الرسوم. على سبيل المثال ، في نظام مثل Ark ، إذا تكلفت مجموعة من V-UTXOs تكلفة مالية مرتفعة لدرجة أنها لا تستحق أن تؤخذ إلى V-UTXOs في السلسلة ، فيمكن للمنسق غير التعاوني أن يرفض السماح بخصم هذه الـ V-UTXOs خارج السلسلة ، ثم يحقق ربحًا من سرقة قيمة تلك الـ V-UTXOs في عملية واحدة لصرف UTXO عندما تنتهي المهلة.

إذا كانت هذه هي الحالة، فمن المحتمل أن مثل هذا النظام سيفشل معاييرنا ليكون طبقة 2 للمخرجات الافتراضية الصغيرة.

مخططات الرصيد القائمة

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

للقيام بذلك، نحتاج إلى تنفيذ جهاز حالة غير تافه. ولكننا نحتاج أيضًا إلى ما يعد قاعدة بيانات مشتركة. لماذا؟ لأن الهدف هنا هو مشاركة UTXO واحدة عبر العديد من المالكين المختلفين. وأخيرًا، إذا كنا فعلا سنحصل على تحسين في قابلية التوسع، يجب أن نفعل ذلك بطريقة تضع أقل قدر ممكن من بيانات الملكية تلك على السلسلة.

هذه المتطلبات تؤدي بشكل طبيعي إلى نوع ما من الهيكل البياني المعمم مثل شجرة ميركليزد، مثل شجرة ميركلي الجمع. من المؤكد أن تلاعب بهذا الهيكل البياني يتطلب بشكل طبيعي شيئًا مثل OP_CAT، نوع ما من دليل الصفر المعرفة لتحقق التعليمات البرمجية، أو تعليمات برمجية خاصة بتلاعب الشجرة.

ومن المثير للاهتمام ، كما هو الحال في أشجار txout ، لا يمكنك القيام بعمل أفضل من ترتيب log(n) مع الحفاظ على خصائص أمان مماثلة. لماذا؟ لنفترض أن لدينا OP_ZKP افتراضيا احتاج من خلال بعض الرياضيات المتقدمة إلى 32 بايت فقط لإثبات أي بيان. في حين أن هذا الدليل zk يمكن أن يثبت أن بنية البيانات merkelized قد تم التلاعب بها وفقا لقواعد نظام الطبقة 2 ، إلا أنها ستفشل في توفير البيانات اللازمة للمستخدم التالي لإجراء تغيير في الحالة أيضا. هذا يفشل في معاييرنا المفضلة لتمكين السحب غير المشروط: في أحسن الأحوال قد يتمكن مستخدم واحد من تحقيق سحب غير مشروط. ولكن لا يمكن للمستخدمين الآخرين القيام بذلك.

على العكس من ذلك ، إذا تم نشر أجزاء المنشورات المعدلة من هيكل البيانات الميركلزيد عن طريق مخطوطات الكوفينانت - على سبيل المثال ، عناوين العناصر الفرعية في شجرة ميركل - فإن المستخدم التالي لديه بيانات كافية لتحديث فهمه لحالة النظام وجعل انسحابهم غير المشروط.

طريقة محتملة للتغلب على هذه المشكلة هي إذا تطلب العهد إثبات النشر على وسيلة نشر مختلفة عن سلسلة بيتكوين. ومع ذلك، فإن الضمانات الأمنية ستكون أضعف مما هو ممكن عبر بيتكوين.

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

نسبة بيانات الفشل

تحقق L2 من التوسع من خلال إضافة متطلبات تفاعلية في الحالات العدائية. في معظم الحالات، يعني ذلك أن الأطراف الصادقة في البروتوكول لديها مواعيد نهاية يجب أن تقوم بإجراء تعدين المعاملات بحلولها. إذا لم يتم الوفاء بالمواعيد النهائية، يمكن سرقة الأموال.

الطاقة القصوى للكتلة في جميع سلاسل الكتل اللامركزية (والمركزة) محدودة بقيود تقنية. في بيتكوين، الحجم الأقصى للكتلة هو بحيث يعمل بيتكوين في الأساس بسعة ~100% من الوقت. نظرًا لأن تعدين بيتكوين يعمل كنظام مزاد، يتم بيع مساحة الكتلة لأعلى مقدم عرض، في الممارسة يعني هذا أن أدنى معدل رسوم لتعدين المعاملة يزيد وينخفض مع زيادة وانخفاض الطلب.

معدل الرسوم يؤثر دائمًا في اقتصاد L2 وأوضاع الفشل. على سبيل المثال ، في البرق ، تستخدم HTLCs "حجم الغبار" التي صغيرة جدًا لا يمكن استردادها بشكل مربح على السلسلة نموذج أمان مختلف عن HTLCs الأكبر. في حين أن بروتوكول Lightning لا ينفذ هذا بشكل صحيح بعد ، في النظرية يجب أن يكون هذا العتبة ديناميكيًا ، استنادًا إلى معدلات الرسوم وارتفاعها وانخفاضها ، بحيث يمكن للطرف اختيار ما إذا كان HTLC موجودًا حتى في صفقة الالتزام المعطاة بناءً على معدل الرسوم.

تم اقتراح مجموعة متنوعة من الهجمات حيث يتم تعمد تنشيط هذا الوضع على البرق، مثل الفيضان والنهب²²وهجوم الخروج الجماعي²³. نظرًا لأن سعة سلسلة كتل Bitcoin مشتركة عبر جميع الحالات الاستخدامية ، فإن الهجمات بين نظم L2 المختلفة ممكنة أيضًا: على سبيل المثال ، تحفيز الخروج الجماعي على Ark للاستفادة من قنوات Lightning.

L2 التي تشترك في UXXO بين العديد من المستخدمين تجعل هذه المشكلات بطبيعتها أسوأ ، حيث أن أسوأ طلب على مساحة الحظر أثناء الفشل أعلى نسبيا. حتى كتابة هذا التقرير ، لم نشهد في الواقع إخفاقات واسعة النطاق على Lightning حيث كان لا بد من إغلاق أعداد كبيرة من القنوات في وقت واحد. هناك حجة جيدة مفادها أننا يجب أن نحصل على خبرة تشغيلية إضافية مع Lightning وقياسها تقريبا 1-UTXO لكل مستخدم ، قبل دفع الحدود إلى أبعد من ذلك مع مخططات مشاركة UTXO.

ثانيًا ، قبل اعتماد نظم مشاركة UTXO الجديدة على نطاق واسع ، يجب إجراء بحث دقيق حول الربحية المحتملة للهجمات أثناء الطلب العالي على مساحة الكتلة. على سبيل المثال ، في نظام مثل Ark حيث يمكن لـ ASP استرداد الأموال باستخدام مساحة كتلة أقل بكثير من الأطراف الأخرى ، قد يكون الأمر كذلك أن تشغيل أسعار الرسوم المرتفعة عن قصد ثم الاستيلاء على الأموال التي لا يمكن سحبها بربح ثنائي يعد احتيالًا مربحًا ، مخالفًا لكل من شروطنا لنظام L2 الحقيقي.

تنظيف الإجماع

هناك عدد من الأمور التي أخطأ فيها ساتوشي في بروتوكول بيتكوين الأولي، ولا سيما هجمات سكريبتينج دوس، وهجوم تايم وارب، وقضايا مع شجرة ميركل. سبق أن تم إصلاح العديد من الشوائب الأخرى في التوافق بواسطة الشوكات الناعمة، مثل التبديل إلى تقييم nLockTime القائم على الوقت مقابل الوقت الأعتى، (محاولة) إصلاح مشكلة txid المكررة، الخ.

أحدث فورك ناعم، تابروت، كانت له عملية نشر مثيرة للجدل نسبيا، مستغرقة وقتًا طويلاً للنشر بالفعل. أحد الحجج لإجراء تنظيف للموافقة الناعمة في الطبقة 2 أولاً، قبل تمكين أي أوبكودات جديدة أو ميزات أخرى لأنواع جديدة من الطبقة 2، هو أننا سنتعلم المزيد حول مدى استعداد المجتمع الأوسع لتنفيذ ما ينبغي أن يكون تغييرًا ناعمًا نسبياً للموافقة يفيد الجميع على ما يبدو.

اختبار Soft-Fork تعتمد على طبقة L2

لا يحتاج المطورون إلى الانتظار حتى يحدث الفork الناعم لاختبار أفكارهم. إحدى الطرق المتطورة بشكل خاص التي يستخدمها مطورو Ark فيتابوت بلا عهدهو محاكاة العهود التي يحتاجونها مع المعاملات الموقعة مسبقًا. يتيح لهم ذلك اختبار أفكار Ark مع BTC الحقيقي ، على الشبكة الرئيسية ، بنفس السمات الموثوقية ، كما هو متوقع أن يحققه Ark مع العهود. التضحية هي أن Ark بدون عهد يتطلب من جميع الأطراف أن تكون متصلة عبر الإنترنت لتوقيع المعاملات الموقعة مسبقًا. نظرًا لأن clArk يعمل مع BTC الحقيقي ، قد يثبت أنه كافيًا للاستخدام في الإنتاج لبعض حالات الاستخدام التي يمكن أن تتحمل تضحية التفاعلية.

نهج أبسط هو التظاهر بأن بعض الأطراف لا يمكنها القيام بالإجراءات التي قد تمنعها الشروط. على سبيل المثال ، إذا كانت البروتوكول المقترح يرغب في استخدام CTV لفرض نفقة txout في شجرة المعاملات ، يمكن استبدال كل استخدام لـ CTV بـ NOP أو CheckSig. بينما في الواقع لا يتم فرض شجرة txout بالفعل ، يمكن اختبار كل قسم من الشجرة وكل طرف وكأنه يتم فرضه ، وبما أن NOP و CheckSig مسموح بهما في البرامج النصية القياسية ، يمكن اختبار البروتوكول على الشبكة الرئيسية باستخدام أموال حقيقية.

التحديثات الناعمة المحتملة

ما هو المسار الصعودي؟ هنا سنرسم كل خطط L2 الرئيسية التي قمنا بتحليلها، وما هي الشوكات الناعمة المفيدة (U) أو الضرورية (R) لجعل هذه الخطط L2 ناجحة. كما تم مناقشته أعلاه، يمكن لـ OP_CAT (وعند تمديد الموضوع، Script Revival، الذي يتضمن OP_CAT) محاكاة جميع الشوكات الناعمة الأخرى في هذه القائمة - باستثناء OP_Expire و Fee Sponsorship - لذلك حيث يتم تلبية احتياجات المشروع بكفاءة أكبر بشكل مباشر عن طريق شوكة ناعمة أخرى، لن نتضمن OP_CAT.

سنترك أيضًا جميع أوامر تلاعب شجرة ميركل المقترحة. جميعها غير معروفة جدًا وتعتمد على حالة الاستخدام لديها فرصة ضئيلة جدًا في الاعتماد في هذا الوقت. فيما يتعلق بفائدة هذه الأوامر ، فإن تنفيذ تأثيراتها عبر OP_CAT و / أو Script Revival هو مسار أكثر احتمالًا للاعتماد.

CTV هو الفائز الواضح هنا ، يليه SIGHASH_ANYPREVOUT (OP_Expire مفيد للعديد من الأشياء من خلال كونه إصلاحا بديلا لركوب الدراجات ، ولكنه ليس ضروريا). تفوز CTV لأن الكثير من الأشياء تتناسب مع نمط تصميم "التأكد من أن معاملة الإنفاق تتطابق مع هذا القالب" ؛ حتى OP_CAT الإنشاءات يمكنها الاستفادة بكفاءة من CTV.

على عكس OP_CAT ، لا يبدو أن CTV يثير الكثير من مخاطر التبعات غير المقصودة بالإضافة إلى تشجيع دفعات الرسوم خارج النطاق في حالات معينة. هذا ليس مثاليًا. لكن لم يقدم أحد بديلًا مدعومًا على نطاق واسع.

توصيتي الشخصية: قم بتنظيف الشوكة الناعمة بالإجماع ، متبوعا ب CTV.

تنويه:

1. تمت إعادة طباعة هذه المقالة من [ بيترتود], إعادة توجيه العنوان الأصلي 'هل خارطة طريق إثريوم خارجة عن مسارها؟'، جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [بيترتود]. إذا كان هناك اعتراض على هذه الإعادة النشر، يرجى الاتصال بـ تعلّم Gateالفريق، وسوف يتم التعامل معها بسرعة.

2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.

3. تُجري فرقة Gate Learn ترجمة المقال إلى لغات أخرى. ما لم يُذكر غير ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.