فكرة جديدة لتوسيع البيتكوين: هل يمكن لـ LayerTree أن يجعل مليون شخص يتشاركون UTXO واحدًا؟

بقلم: 798.eth

نشر Olaoluwa Osuntokun، المؤسس المشارك لشركة Lightning Labs، مؤخرًا تصميمًا جديدًا لتوسيع البيتكوين يُدعى LayerTree.

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

قد يبدو هذا متناقضًا.

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

يحاول LayerTree إيجاد موقع جديد بين هذين النقيضين.

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

كيف تمثل شجرة واحدة أرصدة الجميع

في LayerTree، يمتلك كل مستخدم عقدة ورقية.

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

لنفترض أن هناك أربعة أشخاص في الشجرة:

تمتلك Alice 5 BTC، ويمتلك Bob 3 BTC، ويمتلك كل من Carol وDavid 1 BTC.

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

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

لا تحتاج سلسلة البيتكوين إلى حفظ الشجرة بأكملها، بل تحتاج فقط إلى حفظ هذا الجذر وUTXO المطابق لإجمالي الرصيد في الشجرة.

هذا يعادل ضغط سجلات ملكية عدد كبير من المستخدمين في التزام تشفيري واحد.

كيف يخرج المستخدمون بشكل فردي

عندما تريد Alice الخروج، لا تحتاج إلى موافقة المشغل، ولا تحتاج إلى أن يكون المستخدمون الآخرون متصلين بالإنترنت.

تحتاج فقط إلى تقديم عقدتها الورقية، وإثبات Merkle من العقدة الورقية إلى جذر الشجرة، وتوقيعها.

سيتحقق سكربت البيتكوين من أن Alice موجودة بالفعل في هذه الشجرة، ويؤكد أنها تمتلك الرصيد المقابل، ثم ينجز أمرين في معاملة واحدة:

أولاً، دفع رصيد Alice إلى عنوان الخروج الذي حددته.

ثانيًا، حذف العقدة الورقية الخاصة بـ Alice، ووضع الأموال المتبقية في UTXO يلتزم بجذر الشجرة الجديد.

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

ما يعنيه LayerTree بخروج O(1) هو أن عدد المعاملات المطلوبة للخروج هو دائمًا معاملة واحدة. لا يزال حجم إثبات Merkle يزداد مع عدد الأعضاء، تقريبًا وفقًا لـ O(log N).

يضغط هذا التصميم عددًا كبيرًا من المستخدمين في UTXO واحد في الحالة الطبيعية، مع الحفاظ على ممر هروب على السلسلة في الحالات غير الطبيعية.

طريقتان للتحويل في LayerTree

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

لذلك، يجعل LayerTree المدفوعات اليومية تتم خارج السلسلة، ويوفر بشكل أساسي طريقتين: channel leaf وvoucher.

Channel leaf: وضع قناة Lightning في عقدة ورقية

يمكن أن تمثل العقدة الورقية قناة Lightning بين المستخدم والمشغل.

لا يظهر مخرج تمويل القناة مؤقتًا كـ UTXO منفصل على السلسلة، بل يتم تضمينه في المخرج المشترك لشجرة LayerTree بأكملها. عند الدفع بين المستخدمين، يتم توجيه HTLC الخاص بـ Lightning عبر المشغل.

أثناء عملية الدفع، لا يتغير جذر شجرة LayerTree، ولا يتم إنشاء أي معاملة على السلسلة.

لذلك، يمكن أن تقترب سرعة الدفع عبر channel leaf من سرعة Lightning العادية، وعادة ما تكتمل في غضون ثوانٍ. يلعب المشغل هنا دور عقدة التوجيه، بينما يتولى LayerTree ضغط UTXO المطلوب على السلسلة للقنوات.

إنه يشبه إلى حد كبير محور Lightning كبير، يشغل مخرجًا واحدًا فقط على السلسلة.

Voucher: شيك رقمي يمكن صرفه على السلسلة

الجزء الأكثر إبداعًا في LayerTree هو الـ voucher.

يمكن فهم الـ voucher على أنه شيك رقمي يصدره المستخدم، ويوفر سكربت البيتكوين القدرة على تنفيذه في النهاية.

لنفترض أن العقدة الورقية لـ Alice تحتوي على 100,000 ساتوشي، وتريد أن تدفع لـ Bob مبلغ 10,000 ساتوشي.

لا تحتاج Alice إلى تعديل الشجرة بأكملها فورًا. تحتاج فقط إلى توقيع رسالة تحدد إلى أي LayerTree ينتمي هذا الـ voucher، ومن أي عقدة ورقية تأتي الأموال، وما هي العقدة الورقية الجديدة التي سيحصل عليها Bob، وما هو مبلغ الدفع، ورقم الحالة الحالي للعقدة الورقية الخاصة بـ Alice.

ترسل Alice الـ voucher الموقّع إلى Bob، وبذلك يكتمل الدفع خارج السلسلة.

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

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

إذا توقفت Alice أو المشغل عن التعاون، يمكن لـ Bob تقديم الـ voucher إلى السلسلة بنفسه. سيقوم عقد LayerTree بخصم المبلغ المقابل من العقدة الورقية لـ Alice، وفي الوقت نفسه إنشاء عقدة ورقية جديدة لـ Bob.

تسمى العملية بأكملها CLAIM.

لا تحتاج Alice إلى التوقيع مرة أخرى، ولا يستطيع المشغل منع Bob من صرف الـ voucher.

لماذا لا يمكن استخدام الـ voucher إلا مرة واحدة

كل عقدة ورقية في LayerTree لها رقم حالة تسلسلي يسمى seq.

لنفترض أن seq الحالي لـ Alice هو 7، فإن الـ voucher الذي توقعه سيرتبط صراحةً بـ seq 7.

عندما يتم صرف voucher، ينخفض رصيد Alice، ويزداد seq من 7 إلى 8. وتصبح جميع الـ vouchers القديمة المرتبطة بـ seq 7 غير صالحة.

هذا يمنع صرف نفس الشيك بشكل متكرر.

إذا كانت Alice تدفع لـ Bob بشكل متكرر، فلن تحتاج إلى إنشاء voucher مستقل في كل مرة.

في الدفعة الأولى البالغة 10,000 ساتوشي، يمكن لـ Alice توقيع voucher بمبلغ تراكمي قدره 10,000 ساتوشي. وفي الدفعة الثانية البالغة 20,000 ساتوشي، يمكنها إعادة التوقيع على voucher بمبلغ تراكمي قدره 30,000 ساتوشي.

يحتاج Bob فقط إلى الاحتفاظ بأحدث voucher.

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

لا يمكن للـ voucher القضاء على مخاطر الائتمان

يمتلك الـ voucher توقيعًا حقيقيًا ومسار صرف على السلسلة، لكنه لا يزال يحمل مخاطر ائتمانية من المُصدر قبل صرفه.

لنفترض أن العقدة الورقية لـ Alice تحتوي على 100,000 ساتوشي فقط.

يمكنها توقيع voucher بقيمة 80,000 ساتوشي لـ Bob، وفي الوقت نفسه توقيع voucher آخر بقيمة 80,000 ساتوشي لـ Carol.

التوقيعات على كلا الـ voucherين حقيقية، لكن رصيد Alice لا يمكنه تغطيتهما في نفس الوقت.

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

يمكن لـ Alice أيضًا تحديث عقدتها الورقية من خلال عمليات قانونية أخرى، مما يزيد من seq. وستصبح الـ vouchers المرتبطة بالحالة القديمة غير صالحة بعد ذلك.

لذلك، يشبه الـ voucher غير المسدد إلى حد كبير الشيك التقليدي:

يمكن للتوقيع أن يثبت من أصدره، ويمكن لحامله محاولة صرفه، لكن رصيد الحساب قد يكون غير كافٍ، وقد تتنافس عدة شيكات على نفس الرصيد.

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

يوضح الموقع الرسمي لـ LayerTree أيضًا أن المستلم يجب أن يعتبر الـ voucher بمثابة ائتمان (credit) حتى يتم صرفه أو تسويته بطريقة أخرى.

هذه المخاطر الائتمانية هي الثمن الذي يدفعه الـ voucher مقابل كفاءته العالية.

لماذا تصميم الـ voucher إذن

بما أن هناك مخاطر ائتمانية، فلماذا لا نستخدم قنوات Lightning بالكامل؟

لأن بنية الـ voucher أبسط وأكثر مرونة.

فهي لا تتطلب من طرفي الدفع إنشاء قناة مستقلة مسبقًا، ويمكن لأي مالك عقدة ورقية إصدارها مباشرة، ويمكن تحديثها تراكميًا عدة مرات، كما يمكن أن تكون بمثابة مستند تسوية بين LayerTree وLightning.

صمم LayerTree نوعًا من العقد الورقية يسمى credit leaf لاستقبال المدفوعات من Lightning.

بعد أن يتلقى المشغل دفعة Lightning، يمكنه استخدام عقدة ورقية يمولها بنفسه لتوقيع voucher تراكمي جديد للمستلم. يمكن للمستلم الاستمرار في الاحتفاظ به، أو صرفه على السلسلة بنفسه عند الضرورة.

توجد نافذة ثقة قصيرة في العملية الأساسية: يكون المشغل قد استلم دفعة Lightning لكنه لم يصدر الـ voucher للمستلم بعد. صممت الورقة أيضًا ما يسمى pending pair، باستخدام أقفال التجزئة والـ vouchers الموقعة مسبقًا ونافذة التسوية، بحيث يحصل المستلم أولاً على مستند قابل للتنفيذ قبل الإفراج عن preimage دفعة Lightning.

في هذا الهيكل، يصبح الـ voucher جسرًا بين مدفوعات Lightning وأرصدة UTXO المشتركة.

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

ما هي ترقيات البيتكوين التي يعتمد عليها LayerTree

لا يمكن تشغيل LayerTree حاليًا على الشبكة الرئيسية للبيتكوين.

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

صمم المشروع أربع مجموعات من أكواد التشغيل.

تعتمد نسخة FULL على BIP 441 وBIP 440 وOP_TX وBIP 348 ومجموعة من أكواد تشغيل المنحنيات الإهليلجية.

يستعيد BIP 441 بعض قدرات السكربت التي تم تعطيلها مبكرًا، ويدعم معالجة أكثر مرونة للبيانات والقيم. يوفر BIP 440 ميزانية حسابية لهذه العمليات ذات التكلفة المتغيرة.

تعتمد نسخة MID على OP_CAT من BIP 347 وOP_TX وOP_CHECKSIGFROMSTACK من BIP 348 وOP_TWEAKADD من BIP 449.

يُستخدم OP_CAT لربط البيانات في السكربت. يسمح OP_TX للسكربت بقراءة المعاملة الحالية وتقييدها. يُستخدم OP_TWEAKADD لحساب المفتاح العام لـ Taproot الذي يلتزم بالحالة الجديدة.

من بينها، يعتبر BIP 348 مهمًا بشكل خاص للـ voucher. فهو يسمح لسكربت البيتكوين بالتحقق من توقيع على بيانات عشوائية. بدون هذه القدرة، سيكون من الصعب على السكربت التحقق من الشيك الرقمي الذي وقعته Alice خارج السلسلة.

تعتمد نسخة MIN فقط على OP_CAT وOP_TWEAKADD، لكنها تستطيع فقط تنفيذ الخروج وSPLIT، ولا يمكنها دعم الـ voucher وchannel leaf. إنها أشبه بتجربة لإثبات الحد الأدنى لقدرات LayerTree.

تعتمد نسخة CCV على OP_CHECKCONTRACTVERIFY من BIP 443 وOP_TX وBIP 348 المُعد للـ voucher.

يمكن لـ BIP 443 أن يجعل UTXO يحمل التزام حالة ديناميكيًا، ويقيد المخرجات الجديدة بأن ترث الحالة المحدثة. وهو يتناسب تمامًا مع LayerTree كآلة حالة على السلسلة، كما أنه من بين الحلول الأربعة الأقل حجمًا في معاملات الخروج.

ومع ذلك، لم يتم تفعيل أي من هذه الـ BIPs على الشبكة الرئيسية للبيتكوين بعد.

هناك شرط إضافي لـ "مليون شخص يتشاركون UTXO واحدًا"

النسخة الأكثر إبهارًا في الأداء التي يروج لها LayerTree تعتمد أيضًا على كود تشغيل مخصص يسمى OP_MERKLESUMUPDATE.

يمكنه التحقق من إثبات Merkle Sum، وحساب جذر الشجرة الجديد مباشرة بعد استبدال عقدة ورقية واحدة.

بفضله، يتطلب خروج شخص واحد من شجرة LayerTree تضم 65,536 عضوًا حوالي 540 vB. وكلما تضاعف عدد الأعضاء، تزيد معاملة الخروج بحوالي 10 vB فقط.

لكن OP_MERKLESUMUPDATE حاليًا مجرد تصميم وتنفيذ محاكاة في مستودع المشروع، ولم يصبح بعد BIP رسميًا، ولم يدخل في عملية ترقية البيتكوين.

إذا تم استخدام مقترحات أكواد التشغيل الموجودة فقط، فإن تكلفة الخروج على نطاق 65,536 شخصًا تتراوح بين 908 و1,473 vB.

لذا فإن فكرة "شجرة واحدة تحمل ملايين الأشخاص" صحيحة من الناحية البنيوية التشفيرية، لكن تنفيذها الفعال لا يزال يعتمد على قدرات سكربت بيتكوين تتجاوز الـ BIPs الحالية.

هل يمكنها حل مشكلة التدافع الجماعي للخروج

يمكن لـ LayerTree ضغط المساحة المستخدمة على السلسلة بشكل كبير في الحالة الطبيعية، لكنه لا يستطيع زيادة سعة كتل البيتكوين نفسها.

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

وفقًا لحسابات المشروع نفسه، إذا خرج 65,536 مستخدمًا من نفس الشجرة بشكل منفصل، فسيتطلب ذلك حوالي 2,622 كتلة، أي ما يقرب من 18 يومًا.

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

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

أهمية LayerTree

لا يزال لدى LayerTree مشغل واضح.

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

من الأنسب وصفه بأنه نظام UTXO مشترك غير احتجازي.

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

الجزء الأكثر استحقاقًا للاهتمام في LayerTree هو أنه يعرض شكلًا آخر من أشكال الأموال خارج UTXO العادي وقنوات Lightning وقواعد البيانات الاحتجازية:

شيك رقمي يمكن تداوله بشكل فوري، ويتراكم باستمرار، ويُسلَّم في النهاية إلى سكربت البيتكوين للصرف الإجباري.

إنه لا يقضي على مخاطر الائتمان، ولا يتجاوز الحد الأقصى لمساحة الكتل.

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

هذه فكرة إبداعية تمامًا لتوسيع البيتكوين.