فراكتل بيتكوين OP_CAT: شرح فني للقيود

المؤلف: زعيم العصابة موجود هنا ومعه: >

تم اقتراح op_cat كقيد، وقد تلقى مؤخرًا رقم BIP من 347. دعونا أولاً نفهم ما هو "العهد".

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

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

وضع التنفيذ الخطي

1. أحد قيود Bitcoin Script هو وضع التشغيل الخاص به : يتم تنفيذ أكواد التشغيل بشكل تسلسلي ولا توجد حلقات.

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

2. الافتقار إلى الحساب الأساسي لـ Bitcoin Script يحتوي على أقل من 100 رمز تشغيل مهم، وهو ما يثير الدهشة في بعض الأحيان: لا يمكنه مضاعفة الكائنات في المكدس أو تقسيمها أو دمجها. قد يعرف العديد من المستخدمين المهتمين بـ OP_CAT أن ساتوشي ناكاموتو قام بتعطيل العديد من أكواد تشغيل البيتكوين في عام 2010، بما في ذلك OP_OR، وOP_MUL (الضرب)، وOP_DIV (التقسيم)، وOP_CAT (تسلسل السلسلة). تمت إزالة أكواد التشغيل المعطلة هذه لأن تطبيقاتها الأصلية كانت تحتوي على ثغرات أمنية قابلة للاستغلال يمكن أن تعرض أمان الشبكة للخطر. لكن الافتقار إلى رموز التشغيل هذه يجعل من الصعب على البرنامج النصي تنفيذ العمليات الحسابية الأساسية، وهو أمر مفيد في بعض السيناريوهات البسيطة، مثل حساب رسوم المعاملات في العقد.

3. بيانات المعاملات غير مرئية بصراحة، أعتقد أن معظم الناس يفترضون أن عقود البيتكوين الذكية يمكنها رؤية مبلغ المعاملة وأجزاء أخرى من المعاملة. البيانات، حيث أن هذه المعلومات مرئية للعامة على blockchain. لكن العكس هو الصحيح. فالعقود في البيتكوين لا يمكنها تحديد شروط الإنفاق بناءً على بيانات المعاملات، لأن قدرة Bitcoin Script على فهم بيانات المعاملات محدودة للغاية. إذا كان البرنامج النصي لديه القدرة على استبطان المزيد من التفاصيل في بيانات المعاملة، فيمكننا تطوير عقود ذكية أكثر قوة يمكنها القيام بكل الأشياء المثيرة للاهتمام مثل فرض شرط إنفاق معين، وإنشاء المعاملات التي يتم تنفيذها على مراحل، وتمكين عمليات حفظ أكثر تقدمًا الميزات (مثل "القبو").

4. فماذا علينا أن نفعل؟ المزيد من التجارب الرائدة في Bitcoin Script، مثل لغة Simplicity وغيرها، تهدف إلى توفير بدائل لقيود شكل المكدس. تم تصميم أكواد التشغيل مثل OP_MULTISHA256 وOP_LESS وOP_LE32TOLE64 لترقية قوة الحوسبة الخاصة بالبيتكوين. يتم تصنيف المقترحات الخاصة بالتعامل مع رموز تشغيل الاستبطان مثل OP_CTV وOP_CAT على أنها "قيود". إذن، ما الفرق بين "العقود الذكية" و"القيود"؟

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

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

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

يوجد أيضًا OP_CAT، وهو ليس كود تشغيل يمكّنك من الاستبطان بشكل مباشر... OP_CAT: يسمح للبرنامج النصي بربط عنصرين في المكدس ذهابًا وإيابًا يمكن استخدامها لتجميع أجزاء من المعلومات في البرنامج النصي.

OP_CAT: تحرير جميع الاحتمالات في Bitcoin Script، هناك ثلاثة أكواد تشغيل رئيسية فقط يمكنها تحليل بيانات المعاملات: CHECKLOCKTIMEVERIFY (قفل الوقت المطلق)،

بالإضافة إلى ذلك، لديهم بعض المتغيرات، مثل: CHECKSIGVERIFY، وCHECKSIGADD، وCHECKMULTISIG، وCHECKMULTISIGVERIFY، وهي في الأساس متغيرات صغيرة لـ CHECKSIG؛ يمكنه معرفة ما إذا كان الفحص قد نجح أم لا ويوفر فقط وظائف محدودة جدًا. يشبه CHECKSIG، باستثناء أنه يمكنك الحصول على التوقيع والمفتاح العام من المكدس.

في السابق، فهمنا التسلسل كدالة تربط عنصرين، ولكن يمكننا أيضًا استخدامها لتقسيم عنصر - تقسيم التوقيع إلى (r, s) نعم.

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

ما الذي يحدث بحق الجحيم؟ يقوم المستخدم أولاً بتوفير التوقيع والمفتاح العام والمعاملة الموقعة. يمكنك تقسيم التوقيع إلى نصفين والتحقق من كل جزء على حدة باستخدام بيانات المعاملة. يمكن اعتبار هذه التقنية بمثابة نوع من التجزئة أو الربط، لأنها تتحقق من أن التوقيع والمفتاح العام جزء من معاملة صالحة. (ملاحظة المترجم: "يمكن تقسيم البيانات إلى نصفين" هنا لا يعني أنه يمكن تقسيم جزء واحد من البيانات إلى قطعتين أثناء تشغيل البرنامج النصي، ولكن يتم تمرير قطعتي البيانات بشكل منفصل كبيانات شاهدة ، ثم استخدمنا CAT، فربطهما معًا وإجراء الفحص الذي كان سيتم إجراؤه على البيانات الكاملة يسمح لنا بإجراء فحوصات إضافية على كلا قطعتي البيانات عند تمريرهما. ما علاقة هذا بالاستبطان؟ "في Taproot، لدينا بالفعل توقيعات Schnorr. باستخدام أكواد التشغيل للتحقق من توقيع OP_CAT وSchnorr، اتضح أنه يمكننا الحصول على قيد غير متكرر: يمكنك بالفعل الحصول على تجزئة المعاملة. بدلاً من أن تكون قيمة تجزئة المعاملة المخربشة هي قيمة تجزئة SHA2 لجميع بيانات المعاملات في المكدس ”

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

آمن

باستخدام نفس التقنية، لدينا القدرة على تداول الاستبطان، وإعطاء لنا عقد آمن أساسي على الفور. بعد منطق Poelstra في المقالة، أثبت مطور يدعى Rijndael أنه يمكننا تنفيذ Purrfect Vaults ("Perfect Vaults") باستخدام OP_CAT فقط. يمكن للمستخدمين تحديد العنوان الذي يجب أن تذهب إليه الأموال بعد ذلك، مما يوفر آلية لاسترداد الأموال في حالة اختراق المفاتيح ويقلل من الحافز لسرقة المفاتيح الخاصة.

شجرة ميركل داخل البرنامج النصي

في عملة البيتكوين اليوم، "شجرة Kerr الافتراضية" هي عبارة عن بيانات البنية المستخدمة للتحقق من البيانات، ومزامنتها، وبمعنى ما، المعاملات والكتل "الملزمة". يمكن لـ OP_CAT ربط متغيرين في المكدس، وعند استخدامه مع تجزئة SHA256 للمفتاح العام، يمكن تنفيذ أداة التحقق المباشرة من شجرة Merkle في البرنامج النصي. تم تنفيذ هذا النهج، الذي اقترحه بيتر وويل في عام 2015، في Liquid.

توقيع الشجرة

يوفر برنامج نصي متعدد التوقيع بنفس حجم المفتاح العام يحتوي الرقم على علاقة لوغاريتمية، ويمكنه تشفير شروط الإنفاق بخلاف n-of-m. على سبيل المثال، يمكن للمعاملات التي يقل حجمها عن 1 كيلو بايت أن تدعم التوقيعات الشجرية باستخدام 1000 مفتاح عام. كما أنه يفتح شروط الإنفاق للتعميم المنطقي.

حد النوع العودي شروط القيد

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

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

هل هذا آمن؟

قبل إزالة OP_CAT مبدئيًا، يتم دمجه مع OP_DUP (مكدس مكرر)، حتى لو كان الكائن الذي تم معالجته في البداية في المكدس هو بايت واحد فقط، من خلال تطبيق هذا بشكل متكرر لـ رموز التشغيل، فإن حجم كائن المكدس سوف يتوسع أيضًا بسرعة حتى تمتلئ الذاكرة. يمكن استخدام هذا كهجوم DoS. يمنع الاقتراح الجديد هذا الهجوم بسهولة من خلال فرض حد يبلغ 520 بايت على عناصر المكدس.

هل هناك خطر في إنشاء عقد يستمر إلى أجل غير مسمى؟

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

هل ستخلق القيود سوقًا لإصدار العملات المعدنية الأخرى على البيتكوين؟

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

هل يمكنك استخدام CAT "لتشويه" مبلغ من المال بشكل دائم؟

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

هل سيسبب مشاكل MEV للبيتكوين؟

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

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

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

هل OP_CAT مثالي نسبيًا؟

يدعم بعض مستخدمي Bitcoin، الذين يمكن تسميتهم "بأخصائيي التوحيد"، إبقاء Bitcoin في حالته الحالية وهم متشككون في أي ترقيات للبروتوكول. وهم يشعرون بالقلق بشكل خاص من أن التغييرات الرئيسية، مثل إدخال القيود، قد تقلل من لامركزية الشبكة. وتستند دعوتهم إلى الاعتقاد بأنه من الأفضل الالتزام برؤية البيتكوين الأصلية.

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

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

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

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