以下内容转载自 Nervos Talk 论坛，作者 Ajian（比特币内容平台 BTC Study 主编）。

ملخص

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

一. المقدمة

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

نظام العقود الذكية يتميز بالتالي من الناحية الهيكلية:

• الشكل الأساسي لتعبير الحالة (العقد) (الحساب مقابل إخراج المعاملات)
• هل يُسمح بحسابات البرمجة العشوائية ("اكتملت الجولة" في هذا السياق)
• هل يمكن أن ينشأ بيانات جديدة أثناء التنفيذ أم أنه يتم إرجاع قيمة بوليانية فقط؟ (الحساب مقابل التحقق)
• هل يسمح بتسجيل حالة إضافية في العقد؟
• هل يمكن للعقد الواحد الوصول إلى حالة عقد آخر أثناء التنفيذ

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

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

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

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

٢. CKB مقابل BTC: ما الجديد؟

الهيكل الأساسي

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

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

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

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

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

وعلى العكس من ذلك ، يُشار إلى وحدة حالة CKB باسم "Cell" ، وهي تحتوي على أربعة حقول:

• السعة، مماثلة لمبلغ UTXO، تعبر عن حجم الفضاء الذي يمكن أن يحتله هذا الخلية، بوحدة البايت (Bytes)؛
• قفل ، مشابه لمفتاح عام لسكريبت UTXO ، يحدد ملكية هذا الخلية ؛ فقط البيانات المقدمة يمكن أن تمر من خلال هذا القفل ، عندئذٍ يمكن "تحديث" هذه الخلية (أو يمكننا القول بأنه يتم إطلاق هذه الخلية واستخدام هذه السعة لصك مستقبلي جديد) ؛
• البيانات ، البيانات ، أي بيانات ، حجمها مقيد بالسعة ؛
• النوع ، البرنامج النصي الاختياري لتعيين شروط تحديث البيانات.

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

القارئ يمكنه بسهولة أن يلاحظ أن Cell تحسنت مقارنةً بـ UTXO من حيث القابلية للبرمجة:

• يمكن لـ Cell برمجة أي حساب بدلاً من قدرته على برمجة عدد محدود من الحسابات. ستكون تحقق الملكية لها أكثر مرونة.
• بفضل حقول Data و Type ، يمكن لـ Cell تسجيل حالة إضافية ؛ وهذا يتيح لـ Cell حمل ما يُسمى "UDT (رمز مخصص من قبل المستخدم)".

结合 Cell 本身的 “交易输出” 结构، هذه النقطتين بحد ذاتهما قد يجلبان فوائد هائلة جدًا، ولكن، فقط من الوصف أعلاه، لا نزال لا نعرف كيف قام Cell بتحقيق "إمكانية لعقد يصل إلى حالة عقد آخر أثناء تشغيله". لذلك، نحتاج إلى الاعتماد على مفهوم قد ناقشته مجتمع بيتكوين لفترة طويلة: "الشروط المحددة (covenants)".

شروط القيود والتفكير الذاتي

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

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

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

بناءً على ذلك ، يمكننا تقسيم هذه القدرة الكاملة على التفكير الذاتي إلى أربع حالات:

• قفل قراءة الأقفال الأخرى (المدخلات والمخرجات)
• قفل قراءة نوع (المدخلات والمخرجات) الآخر (بالإضافة إلى البيانات)
• اكتب 01928374656574839201 قفل إدخالها وإخراجها
• اكتب قراءة نوع آخر (المدخلات والمخرجات) من النوع (بالإضافة إلى البيانات)

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

في الفصلين التاليين، سنتعرف على برمجة سكريبت بيتكوين الحالية (التي لم يتم تقديم بنود القيود بعد) وميزات المقترحات المقتصرة المتوقع تنفيذها، لفهم جيد لكيفية برمجة خلايا CKB وتحسينها بشكل محدد.

ثالثا. برمجة سكريبت بيتكوين

本节将使用 “闪电通道/闪电网络” 和 “谨慎日志合约（DLC）” 作为基于比特币脚本的应用编程的案例。在展开之前，我们要先了解两个概念。

OP_IF وعمليات التداول "بالتعهد"

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

باستخدام عقد التجزئة الشهير "عقد TimeLock المجزأ (HTLC)" كمثال، يتم ترجمة هذا البرنامج النصي إلى العربية على النحو التالي:

要么，Bob可以揭晓某个哈希值H背后的原像，再给出自己的签名，即可花费这笔资金；

إما يمكن لـ Alice أن تنفق هذه الأموال بتوقيعها بعد فترة زمنية T.

هذا التأثير "إما... أما..." يتم تحقيقه من خلال رمز تحكم في العملية.

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

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

第二个概念是 “承诺交易”。承诺交易的想法是，在一些情况下，一笔有效的比特币交易，即使它不得到区块链的确认，也同样是真实的，有约束力的。

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

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

شبكة الإضاءة

闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。

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

الحل لهذه المشكلة يسمى "LN-Penalty". الآن، لنفترض أن أليس وبوب لديهما 5 BTC في القناة. الآن أليس تريد أن تدفع 1 BTC لبوب، لذلك قامت بتوقيع الصفقة التزام وإرسالها إلى بوب.

أدخل #0 ، 10 BTC: مخرجات التوقيع المتعددة Alie-Bob 2-of-2 (أي العقد القناة)

الناتج #0، 4 BTC: Alice توقيع فردي

إخراج #1 ، 6 BTC: إما مفتاح عام مؤقت مشترك بين Alice و Bob #1 بتوقيع واحد أو قفل زمني T1 ، بوب بتوقيع واحد

بوب يوقع أيضًا صفقة التزام (تتوافق مع الصفقة المذكورة أعلاه) وترسل إلى أليس:

إدخال #0، 10 بتكوين: إخراج العقد المتعدد التوقيع Alie-Bob 2-of-2 (أي العقد القناة)

إخراج #0، 6 BTC: بوب توقيع واحد

إخراج #1، 4 بيتكوين: إما مفتاح عام مؤقت مشترك بوب-أليس #1 توقيع واحد أو قفل زمن T1، أليس توقيع واحد

هنا السر هو في "المفتاح العام المؤقت المشترك" ، وهو مولد باستخدام مفتاح عام من الجانب الخاص ومفتاح مقدم من الجانب الآخر ، على سبيل المثال ، مفتاح الجانب العام المؤقت لـ Alice-Bob هو إجمالي ضرب مفتاح عام لـ Alice بقيمة هاش ومفتاح مقدم من Bob. في وقت إنشاء المفتاح العام هذا ، لا يعرف أحد مفتاحه الخاص. ومع ذلك ، إذا أخبرنا Bob بمفتاح خاص لمفتاحه العام المقدم ، يمكن لـ Alice حساب مفتاحه الخاص للمفتاح العام المؤقت المشترك. - هذا هو المفتاح ل "التراجع" في قناة البرق القديمة.

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

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

"في الختام، التصميم الرئيسي للقناة البرقية يتضمن:"

تستخدم الأطراف المعاملات الوعدية دائمًا للتعبير عن الحالة الداخلية للعقد وتعبر عن الدفع من خلال تغيير المبلغ.

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

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

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

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

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

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

أليس -- HTLC --\u003e بوب -- HTLC --\u003e كارول -- HTLC --\u003e دانيال

Alice <-- الصورة الأصلية -- Bob <-- الصورة الأصلية -- Carol <-- الصورة الأصلية -- Daniel

عندما تجد Alice هذا المسار وترغب في دفع Daniel ، تطلب من Daniel قيمة التجزئة لإنشاء HTLC لـ Bob ، وتطلب من Bob إعادة توجيه رسالة إلى Carol وتوفير نفس HTLC ؛ تلمح الرسالة إلى Carol لإعادة توجيه الرسالة إلى Daniel وتوفير نفس HTLC. عندما تصل الرسالة إلى Daniel ، يكشف لـ Carol الصورة الأصلية ، مما يمكنه من الحصول على قيمة HTLC وتحديث حالة العقد ؛ تفعل Carol نفس الشيء ، وتحصل على الدفع من Bob وتحديث حالة القناة ؛ في النهاية ، يكشف Bob لـ Alice الصورة الأصلية ويحدث الحالة. نظرًا لخصائص HTLC ، يجب أن تكون هذه السلسلة من المدفوعات ناجحة معًا أو فاشلة معًا ، وبالتالي فهي خالية من الثقة.

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

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

عقد سجل الحذر

تستخدم عقود سجل الحذر (DLC) تقنية تشفير تسمى "توقيع المحول" لإتاحة إنشاء عقود مالية تعتمد على أحداث خارجية في نص بيتكوين.

التوقيع الموحد يمكنه جعل التوقيع يصبح صالحًا فقط بعد إضافة مفتاح خاص واحد. على سبيل المثال، في توقيع Schnorr، الشكل القياسي لتوقيع Schnorr هو (R، s)، حيث:

R = r.G # nonce قيمة العدم التوقيعية r مضروبة في نقطة توليد المنحنى البيضاوي، يمكن أيضا أن يكون مفتاح عام ل r

s = r + Hash(R || m || P) \* p # p هو المفتاح الخاص للتوقيع ، P هو المفتاح العام

تحقق التوقيع يعني التحقق من s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) * p

显然，这并不是一个有效的 Schnorr 签名，它无法通过验签公式，但是，我却可以向المدققون证明，只需 TA 知道 R2 的私钥 r2 ，就可以让它变成一个有效的签名：

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

التوقيع الموجه يجعل صحة التوقيع تعتمد على بيانات سرية وقابلة للتحقق. ولكن ما العلاقة بين ذلك والعقود المالية؟

تفترض أن آليس وبوب يرغبان في المراهنة على نتيجة مباراة كرة قدم. يراهن آليس على فوز فريق "المروج الخضر" ويُراهن بوب على فوز فريق "آرلينا"، ويكون المراهنة بقيمة 1 بيتكوين. وبالإضافة إلى ذلك، يعد موقع تقييم المباريات "كارول" بأنه سيقوم بنشر توقيع موجز للنتيجة باستخدام قيمة عشوائية غير قابلة للتكرار "R_c" عند الكشف عن نتيجة المباراة.

可以看出，一共有三种可能的结果（因此 Carol 的签名有 01928374656574839201 种可能）：

• الشيطان الأخضر يفوز، أليس تفوز بـ 1 بتكوين
• الربح لصالح أرينا، بوب يفوز ب 1 BTC
• التعادل ، يتم إعادة الأموال إلى الجذور لشخصين

لهذا السبب ، قام الاثنان بإنشاء صفقة التزام لكل نتيجة. على سبيل المثال ، صفقة التزام التي أنشأوها للنتيجة الأولى هي كما يلي:

输入 #0،2 BTC: Alie-Bob 2-of-2 توقيع متعدد الأطراف (أي عقد المراهنة)

إخراج #0, 2 BTC: Alice توقيع واحد

ولكن، التوقيع الذي أنشأته أليس وبوب لهذه المعاملة ليس (R، s) ، ولكنه توقيع محول (R، s') ؛ وهذا يعني أن التوقيع الذي يقدمه كل طرف للطرف الآخر لا يمكن استخدامه مباشرة لفتح هذا العقد ، بل يجب الكشف عن قيمة سرية يمكن أن تفعل ذلك. هذه القيمة السرية هي بالضبط صورة رئيسية لـ s_c_1.G ، أي توقيع كارول! نظرًا لأن قيمة nonce لتوقيع كارول قد تم تحديدها بالفعل (هي R_c) ، فإن s_c_1.G يمكن بناءها (s_c_1.G = R_c + Hash(R_c || 'الشيطان الأخضر يفوز' || PK_c) * PK_c).

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

以此类推，另外两笔交易也是如此。就这样，Alice 和 Bob 让这个合约的执行依赖于外部事件（准确来说是依赖于断言机对外部事件的播报，其形式是个签名），而且不需要信任对手方。大大小小的金融合约，比如خيارات、期权，都可以用这种方式来实现。

مقارنة بتنفيذات أخرى، فإن أهم ميزة لعقد السجل الدقيق هي خصوصيته: (1) لا يحتاج أليس وبوب أن يخبرا كارول بأنهما يستخدمان بياناتها، وهذا لا يؤثر على تنفيذ العقد؛ (2) المراقبين على السلسلة (بما في ذلك كارول) لا يمكنهم تحديد الخدمة التي يستخدمونها أليس وبوب من خلال تنفيذ صفقاتهما في العقد، ولا حتى التأكد ما إذا كان عقدهما هو عقد مراهنة (وليس قناة صاعقة).

الرابع. مقدمة عن تطبيق شروط القيود

OP_CTV ومراقبة الازدحام

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

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

لنفترض أن أليس وبوب وكارول يريدون سحب 5 BTC و 3 BTC و 2 BTC من البورصات على التوالي. ثم يمكن تبادل إخراج 10 BTC مع 3 فروع OP_CTV. لنفترض أن أليس تريد سحب الأموال ، فيمكنها استخدام الفرع 1 ، وستشكل المعاملة التي تمثلها القيمة التجزئة التي يستخدمها OP_CTV لهذا الفرع ناتجين ، أحدهما هو تخصيص 5 BTC لأليس ؛ الناتج الآخر ، بدوره ، هو تجمع ، والذي يستخدم أيضا OP_CTV للالتزام بمعاملة ، مما يسمح لبوب بإخراج 3 BTC فقط وإرسال BTC 2 المتبقية إلى كارول.

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

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

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

إما أن تنفق أليس وبوب معًا، أو بعد فترة من الزمن يمكن لأليس أن تنفقها بمفردها.

如果 Alice 不向 Bob 揭晓，Bob 就不会知道有这样的输出存在；一旦 Alice 向 Bob 揭晓，Bob 就可以把这个输出当成一个有时效性的单向支付通道，Alice 可以立即用其中的资金给 Bob 支付，而不必等待区块链的确认。Bob 只需在 Alice 可以独自花费它之前，让 Alice 给他的承诺交易上链即可。

OP_Vault والخزانة

OP_VAULT هو نوع من اقتراحات الشروط المقترحة المصممة خصيصًا لبناء "عقود الخزائن".

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

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

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

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

الاقتراح الكامل لـ OP_VAULT يستفيد أيضًا من بعض سياسات حوض المعاملات (سياسة mempool) المقترحة (مثل معاملات التنسيق v3) لتحقيق أفضل أداء. يذكرنا هذا بأن معنى "البرمجة" يمكن أن يكون أوسع مما نتصور. (مثال مماثل هو Open Transaction في شبكة Nervos Network).

五. 理解 CKB

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

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

• في LN-Penalty، يجب على المشاركين في القناة الاحتفاظ بكل صفقة التزام سابقة والقيمة السرية المقابلة للعقاب للتصدي للخداع من قبل الخصم، وهذا يشكل عبئًا على التخزين. إذا كان هناك آلية يمكن أن تضمن أن تكون الصفقة الوحيدة الأحدث للالتزام قابلة للتنفيذ وأن الصفقات القديمة لا يمكن تنفيذها، فإن ذلك يمكن أن يخفف من هذا العبء ويحل مشكلة عقاب غير متوقع عندما يقوم المشاركون بنشر صفقات الالتزام القديمة عن طريق الخطأ بسبب عطل. في نظام التعاقد الذكي المفتوح (DLC) ، نفترض أن هناك العديد من النتائج المحتملة للحدث ، وهناك العديد من التوقيعات التي يجب إنشاؤها مسبقًا وتقديمها للطرف الآخر ، وهذا يشكل أعباء كبيرة؛ بالإضافة إلى ذلك ، يرتبط العائد من عقد DLC مباشرة بالمفتاح العام ، وبالتالي فإن المركز غير قابل للتحويل ، هل هناك طريقة لنقل موضع العقد؟

في الواقع ، قدمت مجتمع بيتكوين إجابات على هذه المشكلات ، وتتعلق بشكل أساسي بمقترح Sighash (BIP-118 AnyPrevOut).

لكن إذا كنا نبرمج على CKB، فإن BIP-118 سيكون متاحًا الآن (يمكن استخدام القدرة على التفكير الذاتي والتحقق من التوقيع المستهدف لمحاكاة هذه العلامة Sighash).

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

الآن، سنقوم بتحليل قابلية برمجة كل وحدة في برمجة CKB بشكل منفصل. سنتجاهل القدرة على الانعكاس في البداية.

قفل الحساب القابل للبرمجة

مثلما ذكرنا ، لا يمكن برمجة UTXO بأي حساب عشوائي. ومع ذلك ، يمكن برمجة Lock ، وهذا يعني أنه يمكن برمجة كل شيء يستند إلى برمجة UTXO قبل نشر بنود القيد ، بما في ذلك ولكن لا يقتصر على قناة البرق وٌDLC المذكورة في النص.

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

في الواقع، هذا هو أحد المجالات التي بدأ الناس استكشافها في CKB: استخدام هذه القدرة المرنة للتحقق من الهوية في حفظ المستخدم الذاتي، مما يتيح تحقيق ما يسمى "تجريد الحساب" - تفويض صلاحية التداول واستعادة سيطرة الحساب بشكل مرن للغاية دون قيود تقريبًا. في النظرية، هذا هو الجمع بين "فروع الإنفاق المتعددة" و "أي وسيلة للتحقق من الهوية". أمثلة على التنفيذ هي: JoyID Wallet، UniPass.

此外，Lock 也可以实现 eltoo 提议，从而实现只需保留最新一笔承诺交易的闪电通道（实际上，eltoo 可以简化一切点对点合约）。

قابلية البرمجة للتحويل العشوائي من النوع

如上所述，Type的一大用途是编程UDT。结合Lock，这意味着我们可以实现以UDT为标的的闪电通道（以及其它类型的合约）.

في الواقع ، يمكن اعتبار تقسيم Lock و Type كترقية للأمان: يركز Lock على تنفيذ طرق الحفظ أو البروتوكولات التعاقدية ، بينما يركز Type على تعريف UDT.

此外，基于 UDT 的定义启动检查的能力，还使得 UDT 能够以跟 CKB 类似的方式参与合约（UDT is first-class citizen）。

مثال: سبق للكاتب أن طرح نظامًا لضمان الإقراض الغير مضمون لـ NFT على بيتكوين. المفتاح في هذا البروتوكول هو عملية تداول وعدية، حيث يكون قيمة المدخل أقل من قيمة الإخراج (وبالتالي لا يعد تداولًا صحيحًا)، ولكن بمجرد توفير مدخل كافٍ لهذا التداول، يصبح صحيحًا: بمجرد أن يتمكن المقترض من سداد القرض، لا يمكن للمقرض أن يستولي على NFT المرهونة. ومع ذلك، فإن ضمان الثقة في هذا التداول الوعدية يستند إلى التحقق من قيمة المدخل والإخراج، لذا فإن المقترض يمكنه استخدام بيتكوين فقط لسداد القرض - حتى إذا كان المقترض والمقرض مستعدين لقبول عملة أخرى (مثل USDT التي تم إصدارها باستخدام بروتوكول RGB) ، فإن التداول الوعدية في بيتكوين لا يمكن أن يضمن استعادة NFT الخاص به مجرد سداد المقترض لكمية كافية من USDT، لأن تداول بيتكوين لا يعرف إطلاقًا حالة USDT! (تعديل: وبعبارة أخرى، لا يمكن بناء التداول الوعدية بشرط سداد USDT).

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

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

接下来我们再考虑内省能力。 -> ثم ننظر مرة أخرى إلى قدرتنا على الانعكاس.

锁 读取其它锁 01928374656574839201

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

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

قفل قراءة أنواع أخرى (بالإضافة إلى البيانات)

这种能力的一个有趣的应用是股权 Token。Lock 将根据其它输入中的 Token 的数量来决定能否动用自身的 Capacity，以及这些 Capacity 能够花到哪里去（需要内省 Lock 的能力）。

اقرأ أقفالًا أخرى

不 مؤكد، ولكن يمكن أن نفترض الفائدة. على سبيل المثال، يمكن التحقق من قفل المدخلات والمخرجات للصفقة في نوع 01928374656574839201 للحفاظ على استقرارها.

اقرأ أنواع TypeScript الأخرى (بما في ذلك البيانات)

جمع البطاقات؟ جمع n رمز يمكن استبداله برمز أكبر: )

السادس. الاستنتاج

مقارنةً بأنظمة العقود الذكية القابلة للبرمجة التي ظهرت في السابق (مثل إيثريوم) ، اتخذت شبكة Nervos أسلوبًا مختلفًا ؛ وبالتالي ، فإن فهم تلك الأنظمة القائمة على العقود الذكية السابقة ، عادة ما يكون من الصعب أن يكون أساسًا لفهم شبكة Nervos. يقترح هذا المقال طريقة لفهم قابلية البرمجة لـ CKB Cell من خلال تطبيق بنية أكثر قيدًا - BTC UTXO. كما يمكننا استخدام مفهوم "الانعكاس" لفهم قدرة "الوصول بين العقود" للخلية ، ويمكننا تقسيم حالات استخدام قدرة الانعكاس وتحديد استخداماتها المحددة.

تعديل:

1. بدون النظر إلى قدرة الوصول المتقاطع لـ Cell (أي القدرة الداخلية) ، يمكن اعتبار قفل s على أنه بيتكوين ذو حالة وقدرة برمجية متقدمة للغاية ، وبالتالي يمكن برمجته بمفرده لجميع التطبيقات المعتمدة على 01928374656574839201.

2. بدون النظر في قدرة الوصول المتقاطع للخلية (أي القدرة على الاستدراك) ، يمكن اعتبار تمييز lock s و type s ترقية أمان: فهو يفصل تعريف الأصول لـ UDT وطرق الحفظ؛ بالإضافة إلى ذلك ، فإن تنفيذ type s (بالإضافة إلى البيانات) التي يمكن أن تكشف حالتها يحقق تأثير "UDT هو مواطن من الدرجة الأولى".

以上两点意味着一种跟 “BTC + RGB” 相同范式但编程能力更强的东西；

3. بناءً على قدرة الانعكاس الداخلية للخلية ، يمكن للخلية الحصول على قدرة برمجية أقوى من post-covenants BTC UTXO وتحقيق بعض الأشياء التي يصعب تحقيقها بـ BTC + RGB (لأن BTC غير قادر على قراءة حالة RGB).

حول هذه الاستخدامات ، لا يمكننا تقديم العديد من الأمثلة المحددة في هذه المقالة ، ولكن ذلك بسبب عدم فهم الكاتب للبيئة البيئية لـ CKB. مع مرور الوقت ، أعتقد أن الناس سيضعون المزيد والمزيد من الخيال في ذلك ويطورون تطبيقات لا يمكن تصورها الآن.

شكرا

شكرًا لـ Retric و Jan Xie و Xue Jie على التعليقات التي قدموها خلال عملية كتابة المقال. بالطبع، أنا وحدي مسؤول عن جميع الأخطاء الموجودة في النص.

مراجع:

5._07_05_مقدمة_إلى_نموذج_التحقق_من_برمجة_ckb_/

6.（二）DLC تعاقدات السجل الحذر

13._QUESTION/discussions/7