الاقتراب من BTC: شرح المعرفة الأساسية المطلوبة لـ BitVM

المؤلف: Nickqiao & Faust & شيو وانغ، جيكي ويب 3

المستشار: فريق بحث بيتلاير

ملخص:

أصدرت Delphi Digital مؤخرًا تقريرًا بحثيًا يتعلق بتقنيات الطبقة الثانية لبيتكوين بعنوان “فجر برمجة بيتكوين: الطريق للتراص”، حيث قدمت استعراضًا شاملاً للمفاهيم الأساسية المتعلقة ببيتكوين رول أب، مثل عائلة أدوات BitVM وتحديد الشروط Covenant والبيئة البيئية DA لبيتكوين والجسر والطبقة الثانية لبيتكوين مثل Bitlayer و Citrea و Yona و Bob وغيرها الكثير.

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

سنعمل مع فريق بحث Bitlayer والمجتمع الصيني BitVM لإطلاق سلسلة من الأعمدة تسمى “الاقتراب من BTC” ، مع التركيز على الموضوعات الرئيسية مثل BitVM و OP\ _CAT و بيتكوين الجسور عبر السلسلة لفترة طويل ، ونحن ملتزمون بتمهيد الطريق لمزيد من الأشخاص طويل لخيبة أمل بيتكوين التقنيات ذات الصلة بالطبقة 2 ومساعدة عشاق طويل.

النص:

قبل عدة أشهر، قام روبن لينوس، المسؤول عن ZeroSync، بنشر مقال بعنوان “BitVM: Compute Anything on Bitcoin”، حيث قدم رسميًا مفهوم BitVM، مما دفع تقدم تقنية بتكوين من الطبقة الثانية. يمكن القول إن هذا واحد من أكثر الابتكارات ثورية في بيئة بتكوين، حيث أشعل حماسًا في جميع بيئة بتكوين الطبقة الثانية، مما جذب مشاركة مشاريع نجومية مثل Bitlayer و Citrea و BOB، وجلب حيوية للسوق بأكمله.

بعد ذلك، شارك المزيد من الباحثين في تحسين BitVM، وقدموا بشكل متتالي الإصدارات المتطورة المختلفة مثل BitVM1 وBitVM2 وBitVMX وBitSNARK. وفيما يلي ملخص تقريبي للوضع:

1. تم تقديم ورقة بيضاء لتنفيذ BitVM من قبل Robin Linus في العام الماضي ، وهو حلاً لتنفيذ BitVM بناءً على دائرة بوابات منطقية وهمية ، ويُعرف باسم BitVM0.
2. في المرات القليلة الأخيرة، في خطابات ومقابلات غير رسمية، قدم Robin Linus حل BitVM1 الذي يعتمد على وحدة المعالجة المركزية الوهمية ويشبه نظام الأدلة الزائفة Cannon لـ Optimism. يمكن استخدام بتكوين سكريبت في سلسلة خارجية لمحاكاة تأثير وحدة المعالجة المركزية العامة.
3. روبن لينوس قدم أيضًا BitVM2، وهو بروتوكول إثبات الاحتيال الغير تفاعلي خطوة بخطوة بدون إذن.
4. أطلق أعضاء Rootstock Labs و Fairgate Labs وثيقة بيضاء حول BitVMX، وهم يأملون في محاكاة تأثير وحدة المعالجة المركزية العامة باستخدام سكريبت بيتكوين (خارج السلسلة) مشابه ل BitVM1.

مقارنة بالعام الماضي ، أصبح النظام البيئي BitVM اليوم “مرئيا بشكل ضعيف” من “قصير في المبنى” الأصلي ، والذي جذب أيضا المزيد والمزيد من مطوري طويل VC للاندفاع إلى النظام البيئي بيتكوين.

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

MATT والتعهد: الفكر الأساسي لـ BitVM

أولاً، يجب أن نؤكد أن الفكرة الأساسية لـ BitVM هي MATT، والتي تعني Merkleize All The Things، وهي تشير بشكل رئيسي إلى استخدام هيكل تخزين البيانات بشكل شجري مثل شجرة Merkle لعرض عملية التنفيذ المعقدة للبرنامج ومحاولة التحقق من صحة العمليات الاحتيالية في الـ BTC الأصلية.

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

• كود نصي للعقد الذكي
• البيانات المطلوبة للعقد
• الآثار المتركة من تنفيذ العقد (سجل التغييرات التي تحدث في الذاكرة ووحدة المعالجة المركزية عند تنفيذ العقد الذكي في EVM وغيرها من الآلات الافتراضية)

تحت مخطط MATT، يتم تخزين جذر Merkle الصغير جدًا في السلسلة، ويتم تخزين مجموعة بيانات Merkle الكاملة في سلسلة البيانات الكاملة في السلسلة، ويتم استخدام نوع من الأفكار المعروفة بـ “التعهد”. هنا يتم شرح ما هو “التعهد” (Commitment).

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

في بعض الأحيان، يمكن أن يعمل تجزئة البيانات كـ “التزام” للبيانات نفسها، وهناك حلول التزام أخرى مثل التزام KZG أو شجرة Merkle وما إلى ذلك. في بروتوكولات إثبات الاحتيال الشائعة في Layer2، يقوم مُنشر البيانات بنشر مجموعة البيانات الكاملة خارج السلسلة، ونشر التزامات مجموعة البيانات داخل السلسلة. إذا اكتشف شخص ما وجود بيانات غير صالحة في مجموعة البيانات خارج السلسلة، فسيقوم بتحدي التزام بيانات داخل السلسلة.

من خلال الالتزام ، يمكن طبقة 2 ضغط كمية كبيرة من البيانات ونشر “التزامها” بيتكوين داخل السلسلة فقط. بالطبع ، من الضروري أيضا التأكد من أن مجموعة البيانات الكاملة المنشورة خارج السلسلة يمكن ملاحظتها من قبل العالم الخارجي.

حاليًا ، هناك عدة حلول رئيسية لـ BitVM مثل BitVM0 و BitVM1 و BitVM2 و BitVMX ، وتستخدم جميعها هياكل مجردة مماثلة تقريبًا:

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

يمكن أن تكون خطط الالتزام المحددة بأشكال متعددة، مثل: شجرة Merkle، PIOPs (مختلف خوارزميات ZK)، وظيفة الهاش

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

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

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

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

الآن نحن نفهم تقريبا فكرة BitVM بشكل عام، وجميع الاختلافات في BitVM أساسا لا يمكن أن تتجاوز النموذج المذكور أعلاه. لذلك، دعونا نبدأ في تعلم وفهم بعض التقنيات المهمة المستخدمة في العملية المذكورة أعلاه، ابتداءً من أساسيات سكريبت بيتكوين و Taproot والتوقيع المسبق.

ما هو سكريبت بيتكوين

معرفة البيتكوين أصعب بكثير من الإيثيريوم، حتى العمليات الأساسية مثل التحويل تتضمن سلسلة من المفاهيم، بما في ذلك UTXO (مخرجات المعاملات غير المنفقة)، وسيناريو القفل (المعروف أيضًا بـPubKey) وسيناريو الفتح (المعروف أيضًا بـSig). سنشرح هذه المفاهيم الرئيسية أولاً.

(مثال لشفرة بيتكوين المكونة من رموز عمليات أكثر تطوراً من لغة برمجة أعلى مستوى)

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

حزمة UTXO لبيتكوين تحتوي على حقلين رئيسيين:

المبلغ ، بوحدات “ساتوشي (ساتوشي)” (100 مليون ساتوشي هو BTC واحد) ؛

النص العام

يجب ملاحظة أن ملكية بيتكوين UTXO تُعبر عنها من خلال نص مقفل. إذا كنت ترغب في نقل UTXO الخاص بك إلى Sam، فيمكنك بدء صفقة لتدمير بعض UTXO الخاص بك، وتحديد شرط فك القفل للUTXO الجديد بأنه “يمكن لـ Sam فقط فتحه”.

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

(يجب أن يتطابق نص الفتح مع نص القفل)

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

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

بشكل محدد، في بيانات مدخلات المعاملة، يجب أن تعلن أي UTXO ترغب في فتحه وتحديد ‘موقع التخزين’ لهذه البيانات. يجب ملاحظة هنا أن Bitcoin و Ethereum مختلفتان تمامًا، حيث يوفر Ethereum نوعين من الحسابات لتخزين البيانات وهما حساب العقد وحساب EOA. تُسجّل الأصول كأرقام في حساب العقد أو حساب EOA وتُخزّن مركزيًا في قاعدة بيانات تُسمى ‘الحالة العالمية’. عند التحويل، يتم تعديل الحساب المحدد مباشرةً من ‘الحالة العالمية’ لتحديد موقع تخزين البيانات بسهولة.

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

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

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

（عند إنشاء إعلان معاملة لتحويل UTXO الخاص بك إلى شخص آخر ، يجب عليك وضع علامة على موقع UTXO في سجل بيتكوين بناءً على معرف/هاش معاملة UTXO هذه）

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

وبالإضافة إلى ذلك، يمكن تخصيص سكريبت قفل UTXO (القفل)، حيث يمكنك تعيين UTXO كـ ‘قابل لفتح من قبل مالك عنوان بيتكوين معين’، حيث يجب على مالك العنوان تقديم توقيع رقمي ومفتاح عام (P2PKH). وفي أنواع الصفقات Pay-to-Hash (P2SH)، يمكنك إضافة هاش في سكريبت قفل UTXO، ومن يمكنه تقديم الصورة الأصلية لهذا الهاش وتحقيق الشروط المحددة مسبقًا في هذه الصورة الأصلية، يمكنه فتح UTXO. يستخدم سكريبت Taproot الذي يعتمد عليه BitVM ميزات مشابهة لـ P2SH.

كيفية تنشيط نص بيتكوين

سنقوم هنا بشرح كيفية تنشيط سكريبت بيتكوين باستخدام P2PKH كحالة توضيحية أولية، حيث أنه فقط من خلال فهم طريقة التنشيط يمكننا فهم Taproot وBitVM الأكثر تعقيدا. يعني P2PKH “الدفع إلى القيمة المقابلة لها بمفتاح عام”، حيث يتم ضبط مفتاح عام hash في سكريبت القفل UTXO، وعند فتح القفل يتعين تقديم المفتاح العام المقابل لهذا ال hash، وهذا يتماشى أساسا مع نهج تحويل بيتكوين العادي.

في هذه الحالة، يجب على عقدة بيتكوين تحقق من أن المفتاح العام في البرنامج النصّي لفتح القفل يتطابق مع تجزئة المفتاح العام المحددة في برنامج القفل، بمعنى آخر، يجب التأكد من أن “المفتاح” المقدم من شخص فتح القفل يتطابق مع “القفل” المحدد مسبقًا في UTXO.

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

قد لا يكون القارئ على دراية ببيئة تنفيذ البرامج النصية لـ BTC ، لذا سنقدم هنا نبذة مبسطة. أولاً ، يتكون برنامج نصي لـ BTC من عنصرين:

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

كما في الرسم البياني أعلاه، الجانب الأيسر هو سكريبت الفتح Sig المرفوع من قبل شخص ما، والذي يحتوي على توقيعه الرقمي والمفتاح العام الخاص به، بينما في سكريبت القفل Pubkey الجانب الأيمن، يحتوي على كود عملية وبيانات (لا نحتاج هنا إلى فهم معنى كل كود عملية، بل فهم ماهية الأمر تقريبا) التي قام خلق UTXO بها عند إنشاء تلك UTXO.

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

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

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

（هذا الرسم متحرك: رسم توضيحي لنص بيتكوين لفتح القفل تحت خطة P2PKH

مصدر: ** )

بالطبع، تدعم شبكة بيتكوين أنواعًا متعددة من عمليات التداول، وليس فقط Pay to public key/public key hash، بل أيضًا P2SH (Pay to hash)، وكل ذلك يعتمد على البرمجيات المخصصة لإنشاء UTXO وكيفية تعيين البرمجيات النصية المقفلة.

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

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

هنا يجب أن نوضح أن سلسلة بيتكوين (كتلة) لا تسجل مباشرة أي UTXO مرتبطة بأي عنوان، بل تسجل فقط UTXO التي يمكن فتحها بتجزئة مفتاح عام / تجزئة النص، ولكن يمكننا بسرعة حساب العنوان المقابل (الجزء الذي يظهر على واجهة المحفظة كشيء عشوائي).

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

الشاهد المنفصل وWitness

عندما نفهم فكرة P2SH ، نكون قد اقتربنا أكثر من BitVM الذي يعتمد على Taproot. ولكن قبل ذلك ، يجب أن نفهم مفهومًا مهمًا: الشاهد والشاهد المنفصل.

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

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

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

في الواقع، في حلول كل من جسر DLC و BitVM2، سيتم بناء صفقات ذات صلة بترتيب دفعي بكميات كبيرة، لذلك ليست الحالة المذكورة في البداية نادرة.

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

بعد ذلك، تم إطلاق ترقية الشاهد المنفصل/SegWit، والتي في الواقع تفصل تمامًا معرف المعاملة ونص الإلغاء، ولا تحتاج إلى تضمين بيانات نص الإلغاء عند حساب تجزئة المعاملة. سيتم تعيين الرمز التشغيلي المسمى “OP_0” تلقائيًا في بداية نص القفل UTXO الذي يتبع ترقية SegWit كعلامة؛ بينما سيتم تسمية نص الإلغاء المقابل باسم Witness (الشاهد).

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

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