بينما شهد العام أو العامان الماضيان عددًا من المقترحات لتمديد بروتوكولات الاقتراض إلى البيتكوين، كانت هناك دائمًا شكوك بين الخبراء بأن بروتوكولات الاقتراض يمكن أن تكون ممكنة بدون أي تمديدات. جاءت الأدلة على ذلك بشكلين: مجموعة متزايدة من العمليات الحسابية التي كان يعتقد في السابق أنها مستحيلة في سكريبت (وتوجت بمشروع BitVM لتنفيذ كل ريكسي في رمز)، وسلسلة من “الأخطاء القريبة” التي وجدها مطورو البيتكوين والتي كان من الممكن أن تجعل بروتوكولات الاقتراض ممكنة لولا بعض الغرائب التاريخية غير المعروفة للنظام.
لقد طور إيثان هيلمان، افيهو ليفي، فيكتور كوبولوف وأنا نظامًا يثبت أن هذه الشكوك كانت مؤسسة بشكل جيد. نظامنا، ColliderScript، يمكّن من تنفيذ بروتوكولات الاقتراض على البيتكوين اليوم، بموجب افتراضات تشفيرية معقولة وبسعر محتمل يبلغ حوالي 50 مليون دولار لكل معاملة (بالإضافة إلى بعض أبحاث التطوير في الأجهزة).
على الرغم من تكاليف استخدام ColliderScript الباهظة، فإن إعدادها رخيص جدًا، والقيام بذلك (بجانب آلية إنفاق عادية، باستخدام Taproot لفصل الاثنين) قد ينقذ عملاتك في حال ظهر حاسوب كمي من مكان ما ودمر النظام.
بدون شك، العديد من القراء بعد قراءة هذه الادعاءات سيرفعون حاجبًا إلى السماء. وبحلول الوقت الذي تنتهي فيه من قراءة هذه المقالة، سيكون الآخر بنفس الارتفاع.
بروتوكولات الاقتراض
لسياق هذه المناقشة، لأولئك غير المألوفين، فإن البيتكوين لديه لغة برمجة مدمجة تُعرف باسم Bitcoin Script، والتي تُستخدم للسماح بإنفاق العملات. في أيامه الأولى، تضمن السكريبت مجموعة غنية من رموز العمليات الحسابية التي يمكن استخدامها لتنفيذ عمليات حسابية عشوائية. ولكن في صيف عام 2010، قام ساتوشي بإلغاء تفعيل الكثير من هذه الرموز بغرض القضاء على سلسلة من الأخطاء الخطيرة. (العودة إلى النسخة قبل 2010 من السكريبت هو هدف مشروع استعادة السكريبت الكبير؛ OP_CAT هو اقتراح أقل طموحًا في نفس الاتجاه.) فكرة بروتوكولات الاقتراض – المعاملات التي تستخدم السكريبت للتحكم في كمية ووجهة عملاتها – لم تظهر لعدة سنوات أخرى، ولم يتحقق من أن هذه الرموز كانت كافية لتنفيذ بروتوكولات الاقتراض إلا بعد ذلك بوقت طويل. وعند هذه النقطة، كانت المجتمع كبيرًا وحذرًا جدًا لإعادة تفعيل هذه الرموز القديمة بنفس الطريقة التي تم تعطيلها بها.
بروتوكولات الاقتراض هي إنشاءات سكريبت افتراضية كانت ستسمح للمستخدمين بالتحكم ليس فقط في الشروط التي يتم بموجبها إنفاق العملات، ولكن أيضًا في وجهتها. هذا هو الأساس للعديد من الإنشاءات المحتملة على البيتكوين، من الخزائن والمحافظ المحدودة بالسعر، إلى آليات سوق الرسوم الجديدة مثل مسابح الدفع، إلى إنشاءات أقل فعالية مثل التمويل الموزع وMEV. تم إنفاق الملايين من الكلمات في مناقشة جاذبية بروتوكولات الاقتراض وما الذي ستفعله بطبيعة البيتكوين.
في هذه المقالة، سأتجنب هذه المناقشة، وأجادل ببساطة بأن بروتوكولات الاقتراض ممكنة بالفعل على البيتكوين؛ وأننا سوف نكتشف في نهاية المطاف كيف أنها ممكنة (بدون تكلفة حسابية كبيرة أو افتراضات تشفيرية مشكوك فيها)؛ وأن مناقشتنا حول التمديدات الجديدة للبيتكوين لا ينبغي أن تتم هكذا وكأن التغييرات الفردية ستكون الخط الفاصل بين مستقبل بدون بروتوكولات الاقتراض أو معه.
التاريخ
على مر السنين، تطور تقليد للعثور على طرق إبداعية لفعل أشياء غير تافهة حتى بسكريبت محدود. كان شبكة البرق مثالاً على ذلك، وكذلك كانت الأفكار الأقل شهرة مثل المدفوعات الاحتمالية أو مكافآت الاصطدام لدوال التجزئة. كانت الحالات الغامضة مثل خطأ SIGHASH_SINGLE أو استخدام استرجاع المفتاح العمومي للحصول على “هاش المعاملة” داخل سكريبت المفسر، ملحوظة ومُستكشفة، ولكن لم يتمكن أحد من العثور على طريقة لجعلها مفيدة. وفي الوقت نفسه، تطور البيتكوين ليكون أكثر تحديدًا، مغلقًا العديد من هذه الأبواب. على سبيل المثال، قامت Segwit بإزالة خطأ SIGHASH_SINGLE وفصلت البيانات البرمجية بوضوح عن بيانات الشهود؛ تخلص Taproot من استرجاع المفتاح العمومي، مما وفر مرونة على حساب تقويض الأمان المحتمل لتوقيعات التكيف أو التوقيعات المتعددة.
على الرغم من هذه التغييرات، استمر التلاعب بالسكريبت، كما استمرت البقية في الاعتقاد بأن هناك بطريقة ما، سيتم العثور على حالة حافة تمكن من دعم بروتوكولات الاقتراض في البيتكوين. في أوائل العشرينيات من القرن الحادي والعشرين، حدث تطوران خاصان أحدثا ضجة. كان أحدهما اكتشافي الشخصي بأن بروتوكولات الاقتراض المستندة إلى التوقيع لم تمت مع استرجاع المفتاح العمومي، وأن على وجه الخصوص، إذا كان لدينا حتى رمز معطل واحد – OP_CAT – سيكون كافيًا لبناء بروتوكول اقتراض فعال بشكل معقول. والآخر كان BitVM، وهو طريقة مبتكرة للقيام بعمليات حسابية كبيرة في السكريبت عبر عدة معاملات، مما ألهب الكثير من البحث في العمليات الحسابية الأساسية داخل المعاملات الفردية.
ألهم هذان التطوران الكثير من النشاط والإثارة حول بروتوكولات الاقتراض، ولكنهما أيضًا بلورا تفكيرنا حول القيود الأساسية للسكريبت. على وجه الخصوص، بدا أن بروتوكولات الاقتراض قد تكون مستحيلة بدون رموز جديدة، حيث أن بيانات المعاملة كانت تُدخل فقط إلى السكريبت عبر توق Signatures ذات 64 بايت ومفاتيح عمومية ذات 32 بايت، بينما كان بإمكان رموز العمليات الداعمة لـBitVM العمل فقط مع أشياء ذات 4 بايت. تم تسمية هذا الانقسام باسم “السكريبت الصغير” و”السكريبت الكبير”، وأصبح العثور على جسر بين الاثنين مرادفًا (على الأقل في ذهني) للعثور على تنفيذ لبروتوكول الاقتراض.
التشفير الوظيفي وPIPEs
تمت ملاحظة أيضًا أنه، مع القليل من الرياضيات العليا، قد يكون من الممكن تنفيذ بروتوكولات الاقتراض بالكامل داخل التوق Signatures أنفسهم، دون مغادرة السكريبت الكبير. تم التعبير عن هذه الفكرة بواسطة جيريمي روبين في ورقته FE’d Up Covenants، التي وصفت كيفية تنفيذ بروتوكولات الاقتراض باستخدام بدائية تشفيرية افتراضية تُسمى التشفير الوظيفي. بعد أشهر، اقترح ميشا كوموروف نظامًا محددًا باسم PIPEs الذي يُظهر أن هذه الفكرة الافتراضية قد أصبحت حقيقة.
هذا تطور مثير، على الرغم من أنه يعاني من قيود رئيسية: الأولى هي أنه يتضمن إعدادًا موثوقًا فيه، مما يعني أن الشخص الذي ينشئ بروتوكول الاقتراض يمكنه تجاوزه. (هذا جيد لشيء مثل الخزائن، حيث يمكن الوثوق بمالك العملات بعدم تقويض أمنه الخاص؛ ولكنه ليس جيدًا لشيء مثل مسابح الدفع حيث لا تُملك العملات في بروتوكول الاقتراض بواسطة المبدع.) القيود الأخرى هو أنه يتضمن تشفير قطع الحدود مع خصائص أمان غير واضحة. سيتلاشى هذا القيد الأخير مع المزيد من البحث، ولكنه السطح الموثوق فيه هو جزء متأصل في نهج التشفير الوظيفي.
ColliderScript
هذا العرض يضعنا في الوضع الحالي: نرغب في إيجاد طريقة لتنفيذ بروتوكولات الاقتراض باستخدام الشكل الحالي من سكريبت البيتكوين، ونعتقد أن الطريقة للقيام بذلك هي إيجاد نوع من الجسر بين “السكريبت الكبير” لتواقيع المعاملات و”السكريبت الصغير” للعمليات الحسابية العشوائية. يبدو أن لا توجد رموز عمليات يمكنها تكوين هذا الجسر مباشرةً (انظر الملحق A في ورقتنا لتصنيف جميع الرموز من حيث حجم المدخلات والمخرجات). سيكون الجسر، إذا كان موجودًا، نوعًا من البناء الذي يأخذ كائنًا واحدًا كبيرًا ويظهر أنه مساوي تمامًا لتسلسل من كائنات صغيرة عدة. يبدو، استنادًا إلى تصنيفنا للرموز، أن هذا مستحيل.
ومع ذلك، في التشفير غالبًا ما نضعف مفاهيم مثل “مساوي تمامًا”، ونستخدم بدلاً من ذلك مفاهيم مثل “غير قابل للتمييز حاسوبيًا” أو “غير قابل للتمييز إحصائيًا”، ومن ثم نتحايل على نتائج الاستحالة. ربما، باستخدام الإنشاءات التشفيرية المدمجة في السكريبت الكبير – الهاشات وتوق Signatures المنحنى الإهليلجي – وبتكرارها باستخدام إنشاءات BitVM في السكريبت الصغير، يمكننا العثور على طريقة لإظهار أن كائنًا كبيرًا كان “غير قابل للتمييز حاسوبيًا” من تسلسل من الصغيرة؟ مع ColliderScript، هذا ما فعلناه بالضبط.
الأسئلة الشائعة
- ما هو الهدف الرئيسي من ColliderScript؟
ColliderScript يهدف إلى تمكين تنفيذ بروتوكولات الاقتراض على البيتكوين بدون تمديدات إضافية، باستخدام أدوات تشفير مدمجة في البيتكوين.
- ما هي التحديات الرئيسية لاستخدام ColliderScript؟
التكاليف المالية المرتفعة والتعقيدات التقنية هي التحديات الرئيسية، ولكن تأمين العملات ضد الحواسيب الكمية يعتبر تحفيزًا قويًا لأبحاث التطوير المستقبلية.
- كيف يساهم ColliderScript في الأمن ضد الحواسيب الكمية؟
باستخدام بنية التوقيعات الوظيفية، يمكن أن يسهم النظام في تجنب التهديدات التي تشكلها الحواسيب الكمية لتميز التوقيعات الحالية للبيتكوين، مما يجعله حلاً أمنيًا محتملاً في المستقبل.
هذا المقال منشور كضيفة من قبل أندرو بولسترا. الآراء المعبر عنها هي ملكه الخاصة ولا تعكس بالضرورة آراء BTC Inc أو مجلة Bitcoin.
