يتطلب فهم قابلية برمجة النظام تحديد السمات الهيكلية للنظام. يساعدنا استكشاف برمجة التطبيقات المستندة إلى Bitcoin Script على فهم البنية الأساسية ل CKB Cell ونموذج البرمجة الخاص بها. ليس ذلك فحسب ، بل إنه يقسم مكونات البرمجة في CKB إلى الأجزاء الصحيحة ويساعدنا على فهم مكاسب قابلية البرمجة التي يجلبها كل جزء.
I. مقدمة
"قابلية البرمجة" هي بعد يأخذه الناس غالبا عند مقارنة أنظمة blockchain. ومع ذلك ، غالبا ما يكون هناك خلاف حول كيفية وصف قابلية البرمجة. التعبير الشائع هو "XX blockchain يدعم لغات برمجة Turing-complete" ، أو "XX blockchain يدعم البرمجة للأغراض العامة" ، والذي يهدف إلى الإشارة إلى أن "XX blockchain" هنا لديه قابلية برمجة قوية. هناك بعض الحقيقة في الآثار المترتبة على هذه العبارات: الأنظمة التي تدعم برمجة تورينج الكاملة أسهل عموما في البرمجة من تلك التي لا تفعل ذلك. ومع ذلك ، هناك العديد من الجوانب للخصائص الهيكلية لنظام العقود الذكية ، وهذا البيان يمس واحدا منها فقط ، لذلك لا يكفي أن يتم فهمه بعمق كاف بحكم حقيقة أن المطورين لا يسترشدون به ، ولا يمكن الاعتماد على المستخدمين العاديين لتمييز الاحتيال.
تشمل الميزات الهيكلية لنظام العقود الذكية ما يلي:
الشكل الأساسي للتعبير عن الدولة (العقد) (الحساب مقابل الناتج التجاري)
ما إذا كان يسمح ببرمجة الحساب التعسفي أم لا (هذا ما يدور حوله مصطلح "Turing-complete")
هل تخلق عملية التنفيذ بيانات جديدة ، أم أنها تمر فقط على القيم المنطقية؟ (الحوسبة مقابل التحقق من الصحة)
ما إذا كان سيتم السماح بتسجيل دول إضافية في العقد أم لا
ما إذا كان العقد لديه حق الوصول إلى حالة عقد آخر عند تنفيذه
لذلك ، بالإضافة إلى "الحساب التعسفي القابل للبرمجة" ، هناك أربع خصائص على الأقل تؤثر على قابلية برمجة نظام العقد الذكي. يمكن القول أن هذه الميزات الأخرى أكثر أهمية ، لأنها تحدد على مستوى أعمق ما يسهل تحقيقه وما يصعب تحقيقه ؛ ما هو التنفيذ الأكثر اقتصادا وما هو التنفيذ الأقل كفاءة.
على سبيل المثال ، غالبا ما يتم الاستشهاد ب Ethereum كمثال على قابلية البرمجة الجيدة ، ولكن الشكل الأساسي لتعبير الحالة على Ethereum هو حساب ، مما يجعل من الصعب برمجة عقود نظير إلى نظير (على سبيل المثال ، بوابات الدفع ، عقود الرهان الفردية) - ليس مستحيلا تماما ، فقط ناكر للجميل. ليس من غير المألوف أن يحاول نظام Ethereum البيئي تنفيذ قناة دفع / قناة حالة ، وكان هناك الكثير من المناقشات النظرية ، ولكن لا يبدو أن هذه المشاريع نشطة بعد الآن - ومن الواضح أنه لا يمكن إلقاء اللوم على قلة الجهد من جانب المطورين. ليس من قبيل المصادفة أن المشاريع النشطة على Ethereum اليوم تأخذ شكل "تجمعات" بدلا من "عقود نظير إلى نظير". وبالمثل ، قد يكون الناس سعداء بقابلية برمجة Ethereum ، لكن نموذج الحساب ناقص بطبيعته في تحقيق "تجريد الحساب" (والذي يمكن فهمه أيضا على أنه تعميم لمفهوم المحفظة).
بنفس الطريقة ، يتطلب استكشاف قابلية برمجة CKB أيضا فهم الخصائص الهيكلية لنظام العقود الذكية CKB في هذه الجوانب. ما نعرفه بالفعل هو أن CKB يسمح ببرمجة الحسابات التعسفية ، ويسمح بتسجيل حالة إضافية داخل العقد ، ويسمح لعقد واحد بالوصول إلى حالة عقد آخر عند تنفيذه. ومع ذلك ، فإن شكل العقد هو ناتج المعاملة (تسمى "الخلية") ، مما يجعلها مختلفة اختلافا جوهريا عن Ethereum. لذلك ، فإن فهم نظام العقد الذكي Ethereum ومثيلات العقد داخله لا يساعدنا على فهم كيفية تنفيذ CKB لهذه الميزات الهيكلية ، ولا يساعدنا على فهم قابلية برمجة CKB.
لحسن الحظ ، يبدو أن العقود الذكية على Bitcoin توفر أفضل أساس لفهم قابلية برمجة CKB. هذا ليس فقط لأن الشكل الأساسي لتمثيل حالة Bitcoin هو أيضا ناتج المعاملات (تسمى "UTXOs") ، ولكن أيضا لأنه بمساعدة مفهوم اقترحه مجتمع Bitcoin يسمى "العهود" ، يمكننا أن نفهم سبب امتلاك CKB لهذه الخصائص الهيكلية ، وتقسيم التأثير النهائي بشكل مناسب إلى عدة أجزاء ، وتحديد مكاسب قابلية البرمجة التي يجلبها كل منها.
II. CKB مقابل BTC: ماذا بعد؟
(1) الهيكل الأساسي
كشكل أساسي لتمثيل حالة Bitcoin ، يحتوي UTXO الخاص ب Bitcoin ("ناتج المعاملات غير المنفقة") على حقلين:
يشير المبلغ ، في ساتوشي ، إلى قيمة البيتكوين التي تمتلكها UTXO ؛
يمثل المفتاح العام للبرنامج النصي ، المعروف أيضا باسم برنامج القفل النصي ، الشروط التي يجب الوفاء بها لإنفاق الأموال ، أي برنامج العقد الذكي الذي يحدد شروط فتح الأموال.
مقارنة بأنظمة العقود الذكية التي جاءت لاحقا ، فإن Bitcoin Script محدود للغاية:
لا يسمح ببرمجة الحسابات التعسفية ؛ لا يوجد سوى عدد قليل من الحسابات العملية التي يمكن استخدامها للتحقق (التحقق من التوقيع ، التحقق المسبق من التجزئة ، التحقق من الوقت)
لا يسمح بتسجيل حالات إضافية في العقد ؛ (على سبيل المثال، لا يمكنك استخدام برنامج نصي للحد من المبلغ النسبي/الأقصى للأموال التي يتم إنفاقها في المرة الواحدة؛ لا توجد أيضا طريقة لإخفاء رمز مميز فيه)
كما أنه لا يسمح بالوصول إلى حالة عقد آخر في وقت التنفيذ (كل برنامج نصي هو عالم منفصل ولا يعتمد على بعضها البعض).
هذا النوع من البرمجة النصية ، على الرغم من محدوديته ، لا يفتقر إلى القدرة على برمجة تطبيقات مذهلة ، وهو أساس استكشافنا لقابلية برمجة CKB. سيكون هناك قسم لاحقا سيقدم مثالين على برمجة Bitcoin Script.
في المقابل ، تسمى وحدة حالة CKB "خلية" ولها أربعة حقول:
السعة ، على غرار مقدار UTXO ، تعبر عن مقدار المساحة التي يمكن أن تشغلها الخلية ، وتقاس بالبايت.
يحدد القفل ، على غرار المفتاح العام للبرنامج النصي UTXO ، ملكية الخلية ؛ فقط عندما يمكن للبيانات المقدمة أن تمر عبر القفل ، يمكن "تحديث" الخلية (أو يمكن تحرير الخلية ويمكن استخدام السعة لسك خلايا جديدة) ؛
البيانات والبيانات والبيانات التعسفية التي يكون حجمها محدودا بالسعة ؛
اكتب ، برنامج نصي اختياري يحدد شروط تحديث البيانات.
بالإضافة إلى ذلك ، يمكن برمجة Lock and Type لإجراء حسابات تعسفية. يمكنك برمجة أي خوارزمية للتحقق من التوقيع ، ويمكنك برمجة أي خوارزمية تجزئة للتحقق من الصورة المسبقة ، وما إلى ذلك.
من السهل على القراء معرفة كيفية تحسين قابلية برمجة الخلية على UTXOs:
يمكن برمجة الخلايا بحسابات تعسفية ، بدلا من مجرد حسابات محددة قليلة ؛ سيكون التحقق من ملكيتها أكثر مرونة ؛
بسبب حقول البيانات والنوع ، يمكن للخلية تسجيل حالات إضافية ؛ يسمح هذا للخلية بحمل ما يعرف باسم "UDT" (رمز مميز معرف من قبل المستخدم).
إلى جانب هيكل "إخراج المعاملة" للخلية نفسها ، فإن فوائد هاتين النقطتين في حد ذاتها مهمة للغاية ، ولكن من الوصف أعلاه وحده ، لا نعرف كيف تحقق الخلية "عقد واحد يصل إلى حالة عقد آخر في وقت التشغيل". للقيام بذلك ، نحتاج إلى الاعتماد على مفهوم تمت مناقشته لفترة طويلة في مجتمع Bitcoin: "العهود".
(2) القيود والاستبطان
الغرض الأصلي من شرط التقييد هو تحديد المكان الذي يمكن فيه إنفاق مبلغ من المال. على Bitcoin الحالي (حيث لم يتم اقتراح أي قيود) ، يمكن إنفاق مبلغ واحد من المال ، بمجرد إلغاء قفله ، في أي مكان (يمكن دفعه إلى مفتاح عام نصي تعسفي). لكن فكرة شرط التقييد هي أنه يمكن إنفاقه بطريقة تقيده في أماكن معينة ، على سبيل المثال ، لن يتم إنفاق UTXO معين إلا من خلال معاملة معينة ، بحيث حتى إذا كان بإمكان شخص ما تقديم توقيع ل UTXO ، حيث يمكن إنفاقه تم تحديده بالفعل من خلال تلك المعاملة. قد يبدو هذا غريبا بعض الشيء ، لكنه قد يؤدي إلى بعض التطبيقات المثيرة للاهتمام ، والتي سيتم تناولها في قسم لاحقا. الأهم من ذلك ، هو المفتاح لفهمنا الإضافي لقابلية برمجة CKB.
يشير راستي راسل بحق إلى أنه يمكن فهم التقييد على أنه قدرة "استبطان" على التداول ، أي عندما يتم إنفاق UTXO A بواسطة معاملة B ، يمكن لمشغل البرنامج النصي قراءة بعض (أو كل) المعاملة B ثم التحقق من أنها تتطابق مع المعلمات المطلوبة مسبقا بواسطة البرنامج النصي. على سبيل المثال ، ما إذا كان المفتاح العام للبرنامج النصي للإخراج الأول للمعاملة A يتطابق مع ما هو مطلوب بواسطة المفتاح العام للبرنامج النصي ل UTXO A (هذا ما يعنيه التقييد في الأصل).
سيدرك القارئ الذكي أنه من خلال الاستبطان الكامل ، يمكن لإدخال معاملة واحدة قراءة حالة إدخال آخر لنفس المعاملة ، مما يتيح قدرة عقد واحد على الوصول إلى حالة عقد آخر في وقت التشغيل. في الواقع ، هذا هو بالضبط كيف تم تصميم خلية CKB.
بناء على ذلك ، يمكننا تقسيم هذه القدرة الاستبطانية الكاملة إلى أربعة سيناريوهات:
قفل يقرأ أقفال أخرى (الإدخال والإخراج)
قفل يقرأ نوع (وكذلك البيانات) من الآخر (المدخلات والإخراج)
نوع يقرأ أقفال أخرى (الإدخال والإخراج)
النوع يقرأ نوع (وبيانات) الآخر (الإدخال والإخراج)
يتيح لنا ذلك تحليل دور القدرات الاستبطانية لكل جزء في حالات الاستخدام المختلفة في ظل افتراضات معينة (تقسيم الوظائف بين القفل والنوع) ، أي اكتساب قابلية البرمجة الذي يجلبه لنا كل جزء.
في القسمين التاليين ، سنلقي نظرة على البرمجة الحالية (وغير المقترحة بعد) ل Bitcoin Script ، والوظيفة المحتملة التي من المتوقع أن يحققها التقييد المقترح ، وذلك لإعطاء فهم ملموس لكيفية برمجة CKB Cell والقيام بها بشكل أفضل.
III. برمجة نصوص البيتكوين
في هذا القسم ، سنستخدم "Lightning Channel / Lightning Network" و "Caution Journal Contract (DLC)" كأمثلة على برمجة التطبيقات القائمة على Bitcoin Script. قبل أن ندخل في ذلك ، دعونا نأخذ شيئين فيه.
(1) OP \ _IF و "صفقات الالتزام"
المفهوم الأول هو رمز التشغيل للتحكم في التدفق في Bitcoin Script ، مثل: OP \ _IF ، OP \ _ELSE. لا تختلف رموز التشغيل هذه عن IF في برمجة الكمبيوتر ، والغرض منها هو تنفيذ عبارات مختلفة بناء على مدخلات مختلفة. في سياق Bitcoin Script ، هذا يعني أنه يمكننا تعيين مسارات فتح متعددة للأموال ؛ إلى جانب ميزة قفل الوقت ، هذا يعني أنه يمكننا إعطاء الأولوية للإجراءات.
خذ "عقد Hash Timelock Contract (HTLC)" الشهير كمثال ، والذي يترجم إلى العامية:
بدلا من ذلك ، يمكن لبوب الكشف عن الصورة المسبقة وراء التجزئة H وإعطاء توقيعه الخاص ، الأمر الذي سيكلف المال
أو ، يمكن لأليس إنفاق الأموال بتوقيعها الخاص بعد فترة معينة من T
هذا "أو ... أو ..." يتم تحقيق التأثير من خلال رمز التشغيل للتحكم في العملية.
الميزة الأبرز ل > HTLC هي أنه يمكنه تجميع عمليات متعددة معا وتفتيتها. على سبيل المثال ، إذا أرادت أليس تبادل BTC مقابل CKB مع Bob ، فيمكن ل Bob أولا إعطاء قيمة تجزئة وإنشاء HTLC على شبكة Nervos. تقوم أليس بعد ذلك بإنشاء HTLC على Bitcoin يستخدم نفس التجزئة. بدلا من ذلك ، يأخذ بوب BTC التي تدفعها Alice على Bitcoin ، بينما يكشف أيضا عن الصورة المسبقة ، مما يسمح لأليس بسحب CKB على شبكة Nervos. في كلتا الحالتين ، لا يكشف بوب عن الصورة الأصلية ، وينتهي كلا العقدين ، ويمكن لكل من أليس وبوب استعادة الأموال التي استثمروها.
بعد تنشيط شوكة Taproot الناعمة ، يتم تحسين ميزة مسار الفتح المتعدد هذه من خلال إدخال MAST (شجرة بناء جملة Merkle المجردة): يمكننا تحويل مسار إلغاء القفل إلى ورقة على شجرة Merkle ، كل ورقة مستقلة ، لذلك لم تعد هناك حاجة لاستخدام رمز التشغيل للتحكم في التدفق ؛ أيضا ، نظرا لأنه يتم الكشف عن مسار واحد دون الكشف عن المسارات الأخرى ، يمكننا إضافة عدد أكبر من مسارات الفتح إلى الناتج دون الحاجة إلى القلق بشأن الاقتصاد.
المفهوم الثاني هو "تداول الالتزام". فكرة المعاملة الملتزم بها هي أنه في بعض الحالات ، تكون معاملة Bitcoin الصالحة ، حتى لو لم يتم تأكيدها بواسطة blockchain ، حقيقية وملزمة بنفس القدر.
على سبيل المثال ، تشترك Alice و Bob في UTXO يتطلب توقيع كلاهما للإنفاق. في هذه المرحلة ، تبني أليس معاملة لإنفاقها ، وتحويل 60٪ من قيمتها إلى بوب والباقي لنفسها. تقدم أليس توقيعها الخاص للمعاملة ، والتي يتم إرسالها بعد ذلك إلى بوب. حسنا ، بالنسبة لبوب ، لا يجب بثها على شبكة Bitcoin ، ولا يجب تأكيدها بواسطة blockchain ، كما أن تأثير الدفع لهذه المعاملة حقيقي وموثوق. نظرا لأن أليس لا يمكنها إنفاق UTXO بمفردها (وبالتالي لا يمكنها إنفاقها بشكل متكرر) ، ولأن التوقيع المقدم من Alice صالح ، يمكن لبوب دائما إضافة توقيعه وبث المعاملة لتكريم الدفع. بعبارة أخرى ، قدمت أليس لبوب "التزاما موثوقا به" من خلال هذه المعاملة الصالحة (خارج السلسلة).
المعاملات الملتزم بها هي مفهوم أساسي لبرمجة تطبيقات Bitcoin. كما ذكرنا سابقا ، فإن عقد Bitcoin قائم على التحقق ، وعديم الجنسية ، ولا يسمح بالوصول المتبادل. ومع ذلك ، إذا كان العقد لا يحمل حالات ، فأين يتم تخزين تلك الحالات ، وكيف يمكن للعقد المضي قدما بأمان (تغيير الحالة)؟ تعطي معاملات الالتزام إجابة مباشرة: يمكن التعبير عن حالة العقد في شكل معاملات ، بحيث يمكن للمشاركين في العقد إنقاذ الحالة بأنفسهم دون الحاجة إلى عرضها على blockchain ؛ يمكن أيضا تحويل مشكلة تغيير حالة العقد إلى مشكلة كيفية تحديث المعاملة الملتزم بها بأمان ؛ بالإضافة إلى ذلك ، إذا كنا قلقين بشأن مخاطر إبرام عقد (على سبيل المثال ، إبرام عقد يتطلب من كلا الطرفين التوقيع من أجل الإنفاق ، وهناك خطر من أن الطرف الآخر لن يستجيب ويتعثر) ، فإن مجرد إنشاء معاملة التزام تكلف العقد مقدما والحصول على توقيع يمكن أن يخفف من المخاطر ويزيل الثقة في المشاركين الآخرين.
(2) قناة البرق وشبكة البرق
قناة البرق هي عقد واحد إلى واحد حيث يمكن لطرفين أن يدفعا لبعضهما البعض عددا غير محدود من المرات دون تأكيد أي دفعة واحدة بواسطة blockchain. كما قد تتوقع ، فإنه يستخدم تداول الالتزام.
في القسم الذي يشرح "المعاملات الملتزم بها" ، قدمنا بالفعل قناة دفع. ومع ذلك ، فإن هذا النوع من العقود ، الذي يستفيد فقط من 2 من 2 multisig ، يمكن أن يتيح فقط المدفوعات في اتجاه واحد. أي أن أليس تدفع دائما لبوب ، أو يدفع بوب دائما لأليس حتى يستهلك رصيده في العقد. إذا كانت دفعة ثنائية الاتجاه ، فهذا يعني أنه بعد تحديث الحالة ، قد يكون لدى أحد الطرفين رصيد أقل من ذي قبل ، لكن TA لديه آخر معاملة ملتزم بها موقعة من الطرف الآخر - ما الذي يمكن فعله لمنع TA من بث الوعد القديم و TA من أحدث معاملة التزام فقط؟
يسمى حل هذه المشكلة مع قناة البرق "LN-Penalty". الآن ، لنفترض أن كل من أليس وبوب لديهما 5 BTC في قناة ؛ الآن تريد أليس أن تدفع لبوب 1 BTC ، لذلك توقع على المعاملة الموعودة وترسلها إلى بوب:
أدخل #0 و 10 BTC:
إخراج Alie-Bob 2 من 2 متعدد التواقيع (أي عقد القناة)
الإخراج # 0 ، 4 BTC:
توقيع أليس الفردي
الإخراج # 1 ، 6 BTC:
أو
أليس بوب مفتاح عام سريع الزوال # 1 توقيع واحد
أو
قفل وقت > T 1 ، بوب موقع واحد
يوقع بوب أيضا التزاما (يتوافق مع المعاملة المذكورة أعلاه) ويرسله إلى أليس:
أدخل #0 و 10 BTC:
إخراج Alie-Bob 2 من 2 متعدد التواقيع (أي عقد القناة)
الإخراج # 0 ، 6 BTC:
بوب توقيع واحد
الإخراج # 1 ، 4 BTC:
أو
مفتاح بوب أليس العام سريع الزوال # 1 توقيع واحد
أو
قفل زمني > T 1 ، توقيع واحد من Alice
تكمن الحيلة هنا في هذا "المفتاح العام المؤقت المشترك" ، والذي يتم إنشاؤه باستخدام أحد مفاتيحها العامة ومفتاح عام يوفره الطرف الآخر ، على سبيل المثال ، المفتاح العام المؤقت المشترك Alice-Bob ، والذي تحصل عليه Alice باستخدام أحد مفاتيحها العامة ومفتاح عام يقدمه Bob ، بضرب كل منهما في قيمة التجزئة. عندما يتم إنشاء مثل هذا المفتاح العام ، لا أحد يعرف مفتاحه الخاص. ومع ذلك ، إذا أخبر بوب أليس بالمفتاح الخاص للمفتاح العام الذي قدمه ، فيمكن لأليس حساب المفتاح الخاص للمفتاح العام المؤقت الموحد. - هذا هو مفتاح حقيقة أن قناة البرق يمكنها "التراجع" عن الحالة القديمة.
في المرة التالية التي يريد فيها الطرفان تحديث حالة القناة (بدء الدفع) ، يتبادل الطرفان المفتاح الخاص للمفتاح العام المؤقت الممنوح لبعضهما البعض في الجولة السابقة. وبهذه الطريقة ، لم يعد المشاركون يجرؤون على بث آخر معاملة موعودة تلقوها: ناتج هذه المعاملة الموعودة التي تحدد قيمة لطرفهم له مساران ، والمفتاح الخاص لمسار المفتاح العام المؤقت معروف بالفعل للطرف الآخر ؛ لذلك بمجرد بث معاملة الالتزام القديمة ، يمكن للطرف الآخر على الفور استخدام هذا المفتاح الخاص المؤقت المشترك لأخذ جميع الأموال في هذا الناتج. - هذا ما تعنيه "عقوبة LN".
وعلى وجه التحديد، يكون ترتيب التفاعل كما يلي: يطلب الطرف الذي يبدأ الدفع أولا مفتاحا عموميا مؤقتا جديدا من الطرف الآخر، ثم ينشئ معاملة التزام جديدة ويسلمها إلى الطرف الآخر؛ كشف الطرف الذي حصل على المعاملة الموعودة للطرف الآخر عن المفتاح الخاص للمفتاح العام المؤقت الذي قدمه في الجولة السابقة. يضمن تسلسل التفاعلات هذا حصول المشاركين دائما على معاملة التزام جديدة قبل إبطال معاملة الالتزام التي تلقوها في الجولة السابقة ، وبالتالي فهي غير موثوقة.
باختصار ، التصاميم الرئيسية لقناة البرق هي:
يستخدم الطرفان دائما معاملات الالتزام للتعبير عن الحالة داخل العقد ، والتغيير في المبلغ للتعبير عن الدفع ؛
تكلف معاملات الالتزام دائما نفس المدخلات (المدخلات التي تتطلب من كلا الطرفين تقديم التوقيعات في نفس الوقت) ، لذلك تتنافس جميع معاملات الالتزام مع بعضها البعض ، ويمكن تأكيد واحدة فقط بواسطة blockchain.
لا يوقع المشتركان على نفس صفقة الالتزام (على الرغم من أنهما مقترنان) ؛ وما يوقعون عليه هو دائما معاملة أكثر ملاءمة لأنفسهم ، بمعنى آخر ، المعاملة الموعودة التي يتلقاها المشاركون دائما ما تكون غير مواتية لأنفسهم ؛
عيب هذا هو أن الإخراج الذي يعين قيمة لنفسه له مساران لإلغاء القفل: يمكن فتح مسار واحد بتوقيعه الخاص ، لكنه يحتاج إلى الانتظار لفترة من الوقت ؛ يستخدم المسار الآخر المفتاح العام للطرف الآخر ، والذي لا يتم حمايته إلا إذا لم يتم الكشف عن أحد مفاتيحه الخاصة المؤقتة.
في كل دفعة ، يقوم الطرفان بتبادل المفتاح الخاص المؤقت الذي استخدمه الطرف الآخر في الجولة السابقة بمعاملة التزام جديدة ، بحيث لا يجرؤ الطرف الذي سلم المفتاح الخاص المؤقت على بث معاملة الالتزام القديمة ، لذلك "يلغي" معاملة الالتزام السابقة ويقوم بتحديث حالة العقد ؛ (في الواقع ، هذه المعاملات الموعودة كلها معاملات صالحة ويمكن بثها إلى blockchain ، لكن المشاركين يضطرون إلى العقاب ولا يجرؤون على البث بعد الآن)
يمكن لأي من الطرفين الانسحاب من العقد في أي وقت بالتزام موقع من الطرف الآخر ؛ ومع ذلك ، إذا كان الطرفان على استعداد للتعاون ، فيمكنهما توقيع صفقة جديدة حتى يتمكن الطرفان من استرداد أموالهما على الفور.
أخيرا ، نظرا لأنه يمكن أيضا وضع HTLC في معاملة ملتزمة ، يمكن لقناة Lightning أيضا إعادة توجيه المدفوعات. بافتراض أن أليس يمكنها العثور على مسار يتكون من قنوات البرق التي تتصل قبل وبعد الوصول إلى دانيال ، فيمكن تحقيق مدفوعات متعددة القفزات غير موثوق بها دون فتح قناة مع دانيال. هذه هي شبكة البرق:
عندما تجد أليس مثل هذا المسار وتريد أن تدفع لدانيال ، تطلب من دانيال تجزئة لإنشاء HTLC لبوب ، وتطالب بوب بإعادة توجيه رسالة إلى كارول وتقديم نفس HTLC ؛ تطالب الرسالة كارول بإعادة توجيه الرسالة إلى دانيال وتقديم نفس HTLC. عندما تصل الأخبار إلى دانيال ، يكشف عن الصورة المسبقة لكارول ، مما يمنحه قيمة HTLC ويقوم بتحديث حالة العقد. فعلت كارول الشيء نفسه ، حيث حصلت على أموال من بوب وتحديث حالة القناة. أخيرا ، يكشف بوب عن الصورة المسبقة لأليس ويقوم بتحديث الحالة. نظرا لطبيعة HTLC ، فإن سلسلة المدفوعات هذه إما تنجح أو تفشل معا ، وعلى هذا النحو ، فهي غير موثوقة.
تتكون شبكة Lightning Network من قناة واحدة تلو الأخرى ، كل منها مستقل عن الآخر. هذا يعني أن أليس تحتاج فقط إلى معرفة ما يحدث في قناتها مع بوب ، بغض النظر عن عدد التفاعلات التي حدثت في قنوات الآخرين ، أو العملة التي تستخدمها هذه التفاعلات ، أو حتى ما إذا كانوا يستخدمون القناة بالفعل.
لا تنعكس قابلية التوسع في شبكة Lightning Network فقط في حقيقة أن سرعة الدفع داخل قناة Lightning محدودة فقط من خلال استثمار موارد الأجهزة من قبل كلا الطرفين ، ولكن أيضا نظرا للتخزين اللامركزي للدولة ، يمكن لعقدة واحدة الاستفادة من الرافعة المالية القصوى بأقل تكلفة.
(3) كن حذرا من عقود دفتر اليومية
يستخدم عقد دفتر اليومية التحذيري (DLC) تقنية تشفير تسمى "توقيع المحول" والتي تسمح ل Bitcoin Script ببرمجة العقود المالية التي تعتمد على الأحداث الخارجية.
تسمح توقيعات المحول للتوقيع بأن يصبح توقيعا صالحا فقط بعد إضافة مفتاح خاص. خذ على سبيل المثال توقيع Schnorr ، حيث يكون الشكل القياسي لتوقيع Schnorr هو (R ، s) ، حيث:
ص = ر.غ
يتم ضرب القيمة nonce r المستخدمة للتوقيع في نقطة توليد المنحنى الإهليلجي ، والتي يمكن القول أيضا أنها المفتاح العام ل r
s = r + تجزئة (R || m || P) * p
p هو المفتاح الخاص للتوقيع ، و P هو المفتاح العام
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + تجزئة (R || m || P) * PK
لنفترض أنني أعطي زوجا من البيانات (R ، s') حيث:
R = R 1 + R 2 = R 1.G + R 2.G
s' = r 1 + تجزئة (R || m || P) * p
من الواضح أن هذا ليس توقيع Schnorr صالحا ، ولا يجتاز صيغة التحقق من الصحة ، لكن يمكنني أن أثبت للمدقق أنه يمكن أن يكون توقيعا صالحا بمجرد معرفة المفتاح الخاص ل R 2 ، r 2:
ق'. G + R 2 = R 1 + التجزئة (R || m || P) * P + R 2 = R + تجزئة (R || m || P) * P
تجعل توقيعات المحول صلاحية التوقيع تعتمد على بيانات سرية ويمكن التحقق منها. ولكن ما علاقة هذا بالعقود المالية؟
لنفترض أن أليس وبوب يريدان المراهنة على نتيجة لعبة الكرة. راهنت أليس وبوب على العفريت الأخضر وألينا للفوز ، على التوالي ، برهان 1 BTC. بالإضافة إلى ذلك ، وعد موقع كارول ، وهو موقع ويب لمراجعة كرة القدم ، باستخدام nonce R \ _c لنشر موقع s \ _c \ _i من النتائج عند الإعلان عن نتائج اللعبة.
كما يتضح ، هناك ثلاث نتائج محتملة (لذلك هناك 3 احتمالات لتوقيع كارول):
العفريت الأخضر يفوز ، أليس يفوز ب 1 BTC
ألينا تفوز ، وبوب يفوز ب 1 BTC
التعادل ، تعود أموال الاثنين بنفس الطريقة
للقيام بذلك ، يقوم الاثنان بإنشاء صفقة التزام لكل نتيجة. على سبيل المثال ، ستبدو معاملة الالتزام التي أنشأوها للنتيجة الأولى كما يلي:
أدخل # 0 ، 2 BTC:
إخراج Alie-Bob 2 من 2 متعدد التواقيع (أي عقد الرهان)
الإخراج # 0 ، 2 BTC:
توقيع أليس الفردي
ومع ذلك ، بدلا من (R ، s) ، فإن توقيع Alice and Bob الذي تم إنشاؤه لهذه المعاملة هو توقيع محول (R ، s ') ؛ بمعنى آخر ، لا يمكن استخدام التوقيعات المقدمة لبعضهما البعض من قبل الطرفين مباشرة لفتح العقد ، ولكن يجب أن تكشف عن قيمة سرية. هذه القيمة السرية هي صورة s \ _c \ _ 1.G ، وهي توقيع كارول! نظرا لأنه تم تحديد قيمة nonce لتوقيع كارول (R \ _c) ، يمكن إنشاء s \ _c \ _ 1.G (s \ _c \ _ 1.G = R \ _c + التجزئة (R \ _c ||). "العفريت الأخضر يفوز" || PK_c) * PK_c)。
عندما يتم الكشف عن النتائج ، بافتراض فوز Green Goblin ، ستصدر كارول توقيعا (R \ _c ، s \ _c \ _ 1) ، بحيث يمكن لأي من Alice أو Bob إكمال توقيع محول الخصم وإضافة توقيعهم الخاص لجعل المعاملة المذكورة أعلاه معاملة صالحة ، وبثها إلى الشبكة لبدء تأثير التسوية. ولكن إذا لم يفز العفريت الأخضر ، فلن تنشر كارول s \ _c _ 1 ، ولن تكون صفقة الالتزام صفقة صالحة.
وهكذا ، كما هو الحال مع الصفقتين الأخريين. وبهذه الطريقة ، تجعل أليس وبوب تنفيذ العقد يعتمد على الأحداث الخارجية (على وجه الدقة ، على بث آلة التأكيد للأحداث الخارجية ، في شكل توقيع) دون الحاجة إلى الوثوق بالطرف المقابل. يمكن تنفيذ العقود المالية الكبيرة والصغيرة ، مثل العقود الآجلة والخيارات ، بهذه الطريقة.
بالمقارنة مع أشكال التنفيذ الأخرى ، فإن أهم ميزة لعقد السجل الحذر هي خصوصيته: (1) لا تحتاج أليس وبوب إلى إخبار كارول بأنهما يستخدمان بيانات كارول ، والتي لا تؤثر على تنفيذ العقد على الإطلاق ؛ (2) لن يتمكن المراقبون على السلسلة (بما في ذلك كارول) من تحديد موقع الويب الذي يستخدمونه من خلال تنفيذ عقد أليس وبوب ، أو حتى أن عقدهم هو عقد مراهنة (وليس قناة برق).
IV. مقدمة في تطبيق القيود
(أ) OP \ _CTV والتحكم في الازدحام
قدم مطورو مجتمع Bitcoin عددا من المقترحات التي يمكن تصنيفها على أنها بنود تقييدية. في الوقت الحالي ، أحد أكثر المقترحات شهرة هو OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV) ، والذي يحظى بشعبية لدى مجتمع Bitcoin لبساطته ومرونته بمفهومه البسيط. وتتمثل فكرة OP_CTV في وضع تجزئة في البرنامج النصي لتقييد أن الأموال لا يمكن إنفاقها إلا من خلال المعاملات التي تمثلها هذه التجزئة؛ تعد هذه التجزئة بإخراج المعاملة ومعظم الحقول ، ولكن ليس مدخلات المعاملة ، فقط عدد المدخلات.
"التحكم في الازدحام" هو مثال جيد على كيفية إظهار OP \ _CTV. حالة الاستخدام الأساسية هي مساعدة عدد كبير من المستخدمين على الخروج من التبادل (بيئة تتطلب الثقة) إلى تجمع ؛ نظرا لأن هذا التجمع يستخدم OP \ _CTV للتخطيط لكيفية إنفاقه في المستقبل ، فإنه يضمن أن المستخدمين يمكنهم الخروج من التجمع دون ثقة ، دون مساعدة من أي شخص ؛ ولأن هذا التجمع يتصرف فقط ك UTXO ، فإنه يتجنب دفع الكثير من الرسوم عندما يكون الطلب على المعاملات على السلسلة مرتفعا (من مخرجات n إلى مخرجات 1 ؛ خفضت أيضا من المعاملات n إلى 1 معاملة). يمكن للمستخدمين في المسبح انتظار فرصة للخروج من المسبح.
لنفترض أن أليس وبوب وكارول يريدون سحب 5 BTC و 3 BTC و 2 BTC من البورصة على التوالي. ثم يمكن للتبادل إخراج 10 BTC مع 3 OP \ _CTV فروع. لنفترض أن أليس تريد سحب الأموال ، يمكنها استخدام الفرع 1 ؛ ستشكل المعاملة التي تمثلها قيمة التجزئة المستخدمة من قبل OP \ _CTV للفرع ناتجين ، أحدهما هو تخصيص 5 BTC إلى Alice ؛ الناتج الآخر ، بدوره ، هو تجمع ، والذي يستخدم أيضا OP \ _CTV للالتزام بمعاملة ، مما يسمح لبوب بسحب 3 BTC فقط وإرسال 2 BTC المتبقية إلى Carol.
إنه نفس الشيء إذا أراد بوب أو كارول سحب الأموال. عند سحب الأموال ، سيكونون قادرين فقط على استخدام المعاملات التي يمكنها اجتياز فحص OP \ _CTV المقابل ، أي أنهم سيكونون قادرين فقط على دفع المبلغ المقابل لأنفسهم ، ولن يكونوا قادرين على سحب الأموال بشكل تعسفي ؛ ستذهب الأموال المتبقية إلى مجمع بقفل OP \ _CTV ، مما يضمن إمكانية وضع المستخدمين المتبقين خارج المجمع دون ثقة ، بغض النظر عن الترتيب الذي يتم سحبهم به.
في الملخص ، يتمثل دور OP \ _CTV هنا في تخطيط المسار حتى نهاية عمر العقد للعقد ، بحيث يمكن للعقد المجمع هنا الحفاظ على سمة الخروج غير الموثوق به بغض النظر عن المسار الذي يسلكه أو الحالة التي يسير فيها.
هناك أيضا استخدام مثير للاهتمام للغاية لهذا OP \ _CTV: "قناة دفع أحادية الاتجاه مخفية ولكن لم يتم الكشف عنها". لنفترض أن أليس تشكل مثل هذا التجمع من الأموال وتضمن أنه يمكن سحب الأموال دون ثقة إلى مخرجات باستخدام البرنامج النصي التالي:
أو ، أليس وبوب يقضيانها معا
أو ، بعد فترة ، يمكن أن تنفقها أليس بمفردها
إذا لم تكشف أليس عن ذلك لبوب ، لما عرف بوب بوجود مثل هذا الإنتاج. بمجرد أن تكشف أليس عن ذلك لبوب ، يمكن لبوب استخدام الإخراج كقناة دفع حساسة للوقت وأحادية الاتجاه يمكن لأليس استخدامها لدفع بوب على الفور دون الحاجة إلى انتظار التأكيد من blockchain. يطلب بوب ببساطة من أليس وضع معاملة التزامه على السلسلة قبل أن تتمكن أليس من إنفاقها بمفرده.
(ب) OP \ _Vault وآمنة
OP \ _VAULT هو اقتراح لشرط تقييدي مصمم خصيصا لبناء "خزائن".
تم تصميم عقد Vault ليكون شكلا أكثر أمانا وتقدما من الحضانة الذاتية. على الرغم من أن العقد الحالي متعدد التواقيع يمكن أن يتجنب نقطة فشل واحدة لمفتاح خاص واحد ، إذا حصل المهاجم على عدد عتبة من المفاتيح الخاصة ، فإن مالك المحفظة عاجز. تريد Vault فرض حد إنفاق واحد على أموالك. في الوقت نفسه ، عند سحب الأموال منه باستخدام المسار العادي ، ستفرض عملية السحب فترة انتظار ؛ وخلال فترة الانتظار ، يمكن مقاطعة عملية السحب عن طريق عملية الاسترداد الطارئ للمحفظة. حتى إذا تم خرق مثل هذا العقد ، يمكن لمالك المحفظة بدء عملية مضادة (باستخدام فرع الاسترداد في حالات الطوارئ).
من الناحية النظرية ، يمكن ل OP \ _CTV أيضا برمجة مثل هذا العقد ، ولكن هناك العديد من المضايقات ، أحدها العمولة: أثناء الالتزام بالمعاملة ، فإنه يعد أيضا بالرسوم التي ستدفعها المعاملة. بالنظر إلى الغرض من هذا العقد ، يجب أن تكون الفترة الزمنية بين إعداد العقد وسحب الأموال طويلة جدا ، لذلك يكاد يكون من المستحيل التنبؤ بالعمولة المناسبة. على الرغم من أن OP \ _CTV لا يحد من المدخلات ، وبالتالي يمكن زيادة الرسوم عن طريق زيادة المدخلات ، فإن المدخلات المقدمة ستصبح جميعها عمولة ، لذلك فهي غير واقعية ؛ طريقة أخرى هي CPFP ، وهي توفير عمولة على المعاملات الجديدة عن طريق إنفاق الأموال المسحوبة. بالإضافة إلى ذلك ، يعني استخدام OP \ _CTV أنه لا يمكن سحب عقد Vault هذا بكميات كبيرة (وبالتأكيد لا يمكن استعادته بكميات كبيرة).
ويحاول مقترح البروتوكول الاختياري _VAULT معالجة هذه المسائل باقتراح رمزي تشغيليين جديدين (OP_VAULT وOP_UNVAULT). تم تصميم OP \ _UNVAULT لمرونة الدفعات ، لذلك لن نذكرها في الوقت الحالي. يتصرف OP \ _VAULT على النحو التالي: عندما نضعه على فرع من شجرة البرنامج النصي ، يمكن استخدامه للالتزام برمز تشغيلي قابل للاستخدام (مثل OP \ _CTV) بدون معلمات محددة ؛ عند إنفاق هذا الفرع ، يمكن تمرير المعاملات في معايير محددة ، ولكن ليس الفروع الأخرى. نتيجة لذلك ، لا يتعين عليه تعيين رسوم محددة مسبقا ، ويمكن تعيينها عند إنفاق الفرع ؛ بافتراض أن الفرع لديه أيضا قفل زمني ، فإنه سيفرض قفلا زمنيا ؛ أخيرا ، نظرا لأنه يمكنك فقط تغيير الفرع الذي تعمل فيه ، ولن يتم تغيير أي فرع آخر من شجرة البرنامج النصي الجديد (بما في ذلك فرع الاسترداد في حالات الطوارئ) ، يسمح لنا بمقاطعة عمليات السحب هذه.
وبالإضافة إلى ذلك، تجدر الإشارة إلى نقطتين: (1) يتصرف رمز التشغيل OP_VAULT بشكل مشابه لمقترح تقييد آخر: OP_TLUV؛ و (2) يتصرف رمز التشغيل OP\ بشكل مشابه لمقترح تقييد آخر: OP; يشير جيريمي روبن بحق إلى أن هذا قد أدى إلى ظهور مفهوم "الحساب" إلى حد ما: يعد OP \ _TLUV / OP \ _VAULT أولا برمز تشغيلي للسماح للمستهلك بتحديث ورقة شجرة البرنامج النصي بالكامل عن طريق تمرير المعلمات إلى رمز التشغيل بمعاملة جديدة ؛ لم يعد الأمر يتعلق ب "التحقق من صحة البيانات الواردة بناء على معايير معينة" ، بل يتعلق ب "إنشاء بيانات جديدة ذات مغزى بناء على البيانات الواردة" ، على الرغم من أن الحساب الذي يمكن تمكينه محدود.
(2) يستفيد اقتراح OP \ _VAULT الكامل أيضا من بعض المقترحات المتعلقة بسياسة mempool (على سبيل المثال ، معاملات v3) لتحقيق نتائج أفضل. هذا يذكرنا بأن معنى "البرمجة" يمكن أن يكون أوسع مما نعتقد. (مثال مماثل هو فتح معاملة في شبكة Nervos.) ）
V. فهم CKB
في القسمين أعلاه ، نصف كيف يمكننا كتابة تطبيقات مثيرة للاهتمام على بنية أكثر تقييدا (Bitcoin UTXO) ؛ وقدمت أيضا مقترحات لمحاولة إضفاء طابع استبطاني على هذا الهيكل.
بينما تتمتع UTXOs بالقدرة على برمجة هذه التطبيقات ، فمن السهل على القراء اكتشاف أوجه القصور أو المجالات التي يمكن تحسينها ، مثل:
في LN-Punishment ، يجب على المشاركين في القناة حفظ كل معاملة تم ارتكابها في الماضي والقيمة السرية للعقوبة المقابلة من أجل التعامل مع احتيال الخصم ، والذي يشكل عبء تخزين. إذا كانت هناك آلية تضمن أن أحدث معاملة التزام فقط هي التي ستدخل حيز التنفيذ ، ولن تدخل معاملة الالتزام القديمة حيز التنفيذ ، فيمكنها التخلص من هذا العبء ، ويمكنها أيضا القضاء على مشكلة معاقبة العقد عن طريق الخطأ لوضع معاملة التزام قديمة على السلسلة.
في DLC ، من المفترض أن هناك العديد من النتائج المحتملة للحدث ، وهناك العديد من التوقيعات التي يتعين على الطرفين توليدها وتسليمها لبعضهما البعض مسبقا ، وهو أيضا عبء كبير ؛ بالإضافة إلى ذلك ، يرتبط دخل عقد DLC ارتباطا مباشرا بالمفتاح العام ، لذلك ليس من السهل نقل موقعه ، هل هناك طريقة لنقل موضع العقد؟
في الواقع ، توصل مجتمع Bitcoin إلى إجابات على هذه الأسئلة ، تتعلق أساسا باقتراح Sighash (BIP-118 AnyPrevOut).
ومع ذلك ، إذا كنا نبرمج على CKB ، فسيكون BIP-118 متاحا الآن (يمكن محاكاة علامات Sighash هذه مع القدرة على التحقق من التوقيعات بشكل استبطاني وهادف).
من خلال تعلم برمجة Bitcoin ، لا نعرف فقط كيف يمكن برمجتها بتنسيق "إخراج المعاملات" (ما يمكن برمجته في CKB) ، ولكن أيضا كيفية تحسين هذه التطبيقات (وكيف يمكننا استخدام قدرات CKB لتحسينها إذا قمنا ببرمجتها على CKB). بالنسبة لمطوري CKB ، يمكن استخدام البرمجة القائمة على Bitcoin Script كمواد تعليمية أو حتى اختصار.
أدناه ، دعنا نحلل قابلية برمجة كل وحدة من برمجة CKB واحدة تلو الأخرى. دعونا لا نفكر في الاستبطان في الوقت الحالي.
(1) قفل محسوب بشكل تعسفي قابل للبرمجة
كما ذكر أعلاه ، لا يمكن برمجة UTXOs للحساب التعسفي. من ناحية أخرى ، يعني القفل أن Lock يمكنه برمجة كل شيء (قبل نشر التقييد) بناء على UTXO ، بما في ذلك على سبيل المثال لا الحصر قناة Lightning و DLC المذكورة أعلاه.
بالإضافة إلى ذلك ، فإن هذه القدرة على التحقق من الحساب التعسفي تجعل Lock أكثر مرونة من UTXO من حيث طرق المصادقة. على سبيل المثال ، يمكننا تنفيذ قناة البرق على CKB حيث يوقع أحد الطرفين ECDSA ويستخدم الطرف الآخر RSA.
في الواقع ، هذا هو أحد المجالات الأولى التي بدأ الناس في استكشافها في CKB: استخدام إمكانية المصادقة المرنة هذه في الوصاية الذاتية للمستخدم لتمكين ما يعرف باسم "تجريد الحساب" - تفويض صلاحية المعاملة واستعادة التحكم مرنان للغاية وغير محدودين تقريبا. من حيث المبدأ ، هذا مزيج من "فروع الإنفاق المتعددة" و "طرق المصادقة التعسفية". أمثلة على التطبيقات هي: محفظة جويد ، يونيباس.
بالإضافة إلى ذلك ، يمكن ل Lock تنفيذ مقترحات eltoo ، مما يتيح قناة البرق التي تحتاج فقط إلى الاحتفاظ بأحدث معاملة ملتزم بها (في الواقع ، يمكن ل eltoo تبسيط جميع عقود نظير إلى نظير).
(2) نوع قابل للبرمجة محسوب بشكل تعسفي
كما ذكر أعلاه ، فإن أحد الاستخدامات الكبيرة للنوع هو برمجة UDTs. بالاقتران مع Lock ، هذا يعني أنه يمكننا تنفيذ قنوات البرق القائمة على UDT (وأنواع أخرى من العقود).
في الواقع ، يمكن اعتبار الانقسام بين Lock و Type بمثابة ترقية أمنية: يركز Lock على تنفيذ طرق الحضانة أو الاتفاقيات التعاقدية ، بينما يركز Type على تحديد UDTs.
بالإضافة إلى ذلك ، فإن القدرة على بدء عمليات التحقق بناء على تعريفات UDT تمكن UDT أيضا من المشاركة في العقود بطريقة مماثلة ل CKB (UDT مواطن من الدرجة الأولى).
على سبيل المثال ، اقترح المؤلف ذات مرة بروتوكولا لتنفيذ الإقراض المدعوم من NFT غير الموثوق به على Bitcoin. مفتاح مثل هذا البروتوكول هو معاملة ملتزمة حيث تكون قيمة المدخلات أقل من قيمة المخرجات (لذلك فهي ليست معاملة صالحة بعد) ، ولكن بمجرد توفير مدخلات كافية للمعاملة ، فهي معاملة صالحة: بمجرد أن يتمكن المقرض من السداد ، لا يمكن للمقرض أن يأخذ NFT المرهون لنفسه. ومع ذلك ، فإن عدم الثقة في معاملة الالتزام هذه يعتمد على المعاملة التي تتحقق من كمية المدخلات والمخرجات ، لذلك يمكن للمقرض استخدام Bitcoin فقط لسداد القرض - حتى لو كان كل من المقرض والمقرض على استعداد لقبول عملة أخرى (مثل USDT الصادرة بموجب بروتوكول RGB) ، فإن معاملة التزام Bitcoin لا تضمن أن المقرض سيستعيد NFT الخاص به طالما أن المقرض يعيد المبلغ الكامل ل USDT ، لأن معاملة Bitcoin ليس لديها فكرة عن حالة USDT! (المراجعة: بمعنى آخر ، لا يمكن إنشاء معاملة ملتزم بها مشروطة بسداد USDT.) ）
إذا تمكنا من بدء شيك بناء على تعريف UDT ، فسنكون قادرين على جعل المقرض يوقع على معاملة أخرى ملتزمة تسمح للمقرض باستخدام USDT لسداد القرض. ستتحقق المعاملة من مبلغ USDT الذي تم إدخاله ومبلغ USDT الخارج ، مما يمنح المستخدمين سدادا غير موثوق به باستخدام USDT.
تعديل >: بافتراض أن NFT المستخدم كضمان وأن الرمز المميز المستخدم للسداد يتم إصدارهما باستخدام نفس البروتوكول (مثل RGB) ، فيمكن حل المشكلة هنا ، ويمكننا إنشاء معاملة التزام وفقا لبروتوكول RGB ، بحيث يمكن أن يحدث انتقال الحالة وسداد NFT في وقت واحد (يرتبط انتقالان للحالة بالمعاملات داخل بروتوكول RGB). ومع ذلك ، نظرا لأن معاملات RGB تعتمد أيضا على معاملات Bitcoin ، فإن إنشاء معاملات الالتزام هنا سيكون صعبا إلى حد ما. الكل في الكل ، على الرغم من أن المشكلة يمكن حلها ، إلا أنه لا يمكن القيام بذلك الرمز المميز هو مواطن من الدرجة الأولى.
بعد ذلك ، دعونا نفكر في الاستبطان.
(3) قفل يقرأ أقفال أخرى
هذا يعني مجموعة كاملة من إمكانيات البرمجة على Bitcoin UTXOs بعد تنفيذ التقييد المقترح. يتضمن ذلك عقود Vault المذكورة أعلاه ، بالإضافة إلى التطبيقات المستندة إلى OP \ _CTV (على سبيل المثال ، التحكم في الازدحام).
ذكر XueJie ذات مرة مثالا مثيرا للاهتمام: يمكنك تنفيذ خلية حساب تجميع على CKB ، عند استخدام هذا النوع من الخلايا كمدخل للمعاملة ، إذا كانت خلية الإخراج (الخلية التي تستخدم نفس القفل) ذات سعة أكبر ، فلن يحتاج الإدخال إلى توفير توقيع ولا يؤثر على صلاحية المعاملة. في الواقع ، لن يكون هذا النوع من الخلايا ممكنا بدون القدرة على الاستبطان. تعتبر خلية حساب التحصيل هذه مثالية كطريقة مؤسسية لتلقي الأموال لأنها تجمع الأموال ولها عيب عدم وجود شعور جيد بالخصوصية.
(4) قفل يقرأ أنواع أخرى (والبيانات)
تطبيق مثير للاهتمام لهذه القدرة هو الرموز المميزة. سيقرر Lock ما إذا كان بإمكانه استخدام سعته الخاصة بناء على عدد الرموز المميزة في المدخلات الأخرى ، وأين يمكن إنفاقها (يتطلب القدرة على استبطان القفل).
(5) اكتب يقرأ الأقفال الأخرى
لست متأكدا ، ولكن يمكن افتراض أنه مفيد. على سبيل المثال، يمكنك التحقق من النوع الذي تظل فيه أقفال مدخلات ومخرجات المعاملة دون تغيير.
(6) النوع Scirpt يقرأ أنواعا (وبيانات) أخرى
بطاقات التداول؟ اجمع n الرموز مقابل رمز مميز أكبر :)
سادسا. خاتمة
مقارنة بأنظمة العقود الذكية السابقة التي يمكن برمجتها بحساب تعسفي ، مثل Ethereum ، تأخذ Nervos Network بنية مختلفة. نتيجة لذلك ، غالبا ما يكون من الصعب فهم شبكة Nervos بناء على معرفة أنظمة العقود الذكية في الماضي. تقترح هذه الورقة طريقة لفهم قابلية برمجة خلية CKB ، بدءا من برمجة التطبيقات لهيكل أكثر تقييدا من خلية CKB ، BTC UTXO. وباستخدام مفهوم "الاستبطان" لفهم قدرات "الوصول عبر العقود" للخلايا ، يمكننا تقسيم المواقف التي تستخدم فيها القدرات الاستبطانية وتحديد استخداماتها المحددة.
التكرار:
بغض النظر عن قدرات الوصول المتقاطع للخلية (أي قدرات الاستبطان) ، يمكن اعتبار الأقفال بمثابة Bitcoin مع قدرات الحالة والبرمجة التي وصلت إلى أقصى الحدود ، بحيث يمكن برمجة جميع التطبيقات المستندة إلى Bitcoin على هذا الأساس وحده ؛
بغض النظر عن قدرة الوصول المتبادل (أي القدرة على الاستبطان) للخلية ، يمكن اعتبار التمييز بين الأقفال والأنواع بمثابة ترقية أمنية: فهو يفصل بين تعريف الأصول وطريقة الحفظ في UDT ؛ بالإضافة إلى ذلك ، فإن نوع (وبيانات) الدولة القابلة للتعرض يحقق تأثير UDT هو مواطن من الدرجة الأولى.
النقطتان المذكورتان أعلاه تعنيان شيئا بنفس نموذج "BTC + RGB" ولكن مع المزيد من قدرات البرمجة ؛
بالنظر إلى قدرة Cell الاستبطانية ، يمكن ل Cell الحصول على قدرات برمجة أقوى من BTC UTXO بعد العهد وتنفيذ شيء يصعب تحقيقه باستخدام BTC + RGB (لأن BTC لا يمكنها قراءة حالة RGB)
لا توجد العديد من الأمثلة المحددة لهذه الاستخدامات ، ولكن هذا يرجع إلى عدم فهم المؤلف لبيئة CKB. بمرور الوقت ، يعتقد أنه سيتم استثمار المزيد والمزيد من الخيال فيه ، وسيتم تجميع التطبيقات التي لا يمكن تصورها اليوم.
شكر وتقدير
شكرا ل Retric و Jan Xie و Xue Jie على ملاحظاتهم أثناء كتابة المقال. بالطبع ، أنا مسؤول عن جميع الأخطاء في النص.
المراجع
الحسابات وقوائم الوصول الصارمة و UTXOs
القيود في بيتكوين: تصنيف للمراجعة
نموذج الخلية
عصبي CKB باختصار
قابلية برمجة البيتكوين
على تجريد الحساب (2022)
ما هي شجرة بناء الجملة المجردة بيتكوين ميركل؟
BIP 345: مقترح البروتوكول التشغيلي \ _VAULT
مقدمة إلى رموز عمليات تقييد TLUV
تتم ترقية المكونات التي تبني العقد باستخدام Bitcoin
وأوضح إلتو
عقد إقراض مضمون NFT بناء على المعاملات الملتزم بها · بيتكوين-دراسة/OP_QUESTION · مناقشة #7
رابط المقال الأصلي
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
فهم قابلية برمجة CKB من برمجة تطبيقات Bitcoin
المؤلف الأصلي: أجيان
ملخص
يتطلب فهم قابلية برمجة النظام تحديد السمات الهيكلية للنظام. يساعدنا استكشاف برمجة التطبيقات المستندة إلى Bitcoin Script على فهم البنية الأساسية ل CKB Cell ونموذج البرمجة الخاص بها. ليس ذلك فحسب ، بل إنه يقسم مكونات البرمجة في CKB إلى الأجزاء الصحيحة ويساعدنا على فهم مكاسب قابلية البرمجة التي يجلبها كل جزء.
I. مقدمة
"قابلية البرمجة" هي بعد يأخذه الناس غالبا عند مقارنة أنظمة blockchain. ومع ذلك ، غالبا ما يكون هناك خلاف حول كيفية وصف قابلية البرمجة. التعبير الشائع هو "XX blockchain يدعم لغات برمجة Turing-complete" ، أو "XX blockchain يدعم البرمجة للأغراض العامة" ، والذي يهدف إلى الإشارة إلى أن "XX blockchain" هنا لديه قابلية برمجة قوية. هناك بعض الحقيقة في الآثار المترتبة على هذه العبارات: الأنظمة التي تدعم برمجة تورينج الكاملة أسهل عموما في البرمجة من تلك التي لا تفعل ذلك. ومع ذلك ، هناك العديد من الجوانب للخصائص الهيكلية لنظام العقود الذكية ، وهذا البيان يمس واحدا منها فقط ، لذلك لا يكفي أن يتم فهمه بعمق كاف بحكم حقيقة أن المطورين لا يسترشدون به ، ولا يمكن الاعتماد على المستخدمين العاديين لتمييز الاحتيال.
تشمل الميزات الهيكلية لنظام العقود الذكية ما يلي:
لذلك ، بالإضافة إلى "الحساب التعسفي القابل للبرمجة" ، هناك أربع خصائص على الأقل تؤثر على قابلية برمجة نظام العقد الذكي. يمكن القول أن هذه الميزات الأخرى أكثر أهمية ، لأنها تحدد على مستوى أعمق ما يسهل تحقيقه وما يصعب تحقيقه ؛ ما هو التنفيذ الأكثر اقتصادا وما هو التنفيذ الأقل كفاءة.
على سبيل المثال ، غالبا ما يتم الاستشهاد ب Ethereum كمثال على قابلية البرمجة الجيدة ، ولكن الشكل الأساسي لتعبير الحالة على Ethereum هو حساب ، مما يجعل من الصعب برمجة عقود نظير إلى نظير (على سبيل المثال ، بوابات الدفع ، عقود الرهان الفردية) - ليس مستحيلا تماما ، فقط ناكر للجميل. ليس من غير المألوف أن يحاول نظام Ethereum البيئي تنفيذ قناة دفع / قناة حالة ، وكان هناك الكثير من المناقشات النظرية ، ولكن لا يبدو أن هذه المشاريع نشطة بعد الآن - ومن الواضح أنه لا يمكن إلقاء اللوم على قلة الجهد من جانب المطورين. ليس من قبيل المصادفة أن المشاريع النشطة على Ethereum اليوم تأخذ شكل "تجمعات" بدلا من "عقود نظير إلى نظير". وبالمثل ، قد يكون الناس سعداء بقابلية برمجة Ethereum ، لكن نموذج الحساب ناقص بطبيعته في تحقيق "تجريد الحساب" (والذي يمكن فهمه أيضا على أنه تعميم لمفهوم المحفظة).
بنفس الطريقة ، يتطلب استكشاف قابلية برمجة CKB أيضا فهم الخصائص الهيكلية لنظام العقود الذكية CKB في هذه الجوانب. ما نعرفه بالفعل هو أن CKB يسمح ببرمجة الحسابات التعسفية ، ويسمح بتسجيل حالة إضافية داخل العقد ، ويسمح لعقد واحد بالوصول إلى حالة عقد آخر عند تنفيذه. ومع ذلك ، فإن شكل العقد هو ناتج المعاملة (تسمى "الخلية") ، مما يجعلها مختلفة اختلافا جوهريا عن Ethereum. لذلك ، فإن فهم نظام العقد الذكي Ethereum ومثيلات العقد داخله لا يساعدنا على فهم كيفية تنفيذ CKB لهذه الميزات الهيكلية ، ولا يساعدنا على فهم قابلية برمجة CKB.
لحسن الحظ ، يبدو أن العقود الذكية على Bitcoin توفر أفضل أساس لفهم قابلية برمجة CKB. هذا ليس فقط لأن الشكل الأساسي لتمثيل حالة Bitcoin هو أيضا ناتج المعاملات (تسمى "UTXOs") ، ولكن أيضا لأنه بمساعدة مفهوم اقترحه مجتمع Bitcoin يسمى "العهود" ، يمكننا أن نفهم سبب امتلاك CKB لهذه الخصائص الهيكلية ، وتقسيم التأثير النهائي بشكل مناسب إلى عدة أجزاء ، وتحديد مكاسب قابلية البرمجة التي يجلبها كل منها.
II. CKB مقابل BTC: ماذا بعد؟
(1) الهيكل الأساسي
كشكل أساسي لتمثيل حالة Bitcoin ، يحتوي UTXO الخاص ب Bitcoin ("ناتج المعاملات غير المنفقة") على حقلين:
مقارنة بأنظمة العقود الذكية التي جاءت لاحقا ، فإن Bitcoin Script محدود للغاية:
هذا النوع من البرمجة النصية ، على الرغم من محدوديته ، لا يفتقر إلى القدرة على برمجة تطبيقات مذهلة ، وهو أساس استكشافنا لقابلية برمجة CKB. سيكون هناك قسم لاحقا سيقدم مثالين على برمجة Bitcoin Script.
في المقابل ، تسمى وحدة حالة CKB "خلية" ولها أربعة حقول:
بالإضافة إلى ذلك ، يمكن برمجة Lock and Type لإجراء حسابات تعسفية. يمكنك برمجة أي خوارزمية للتحقق من التوقيع ، ويمكنك برمجة أي خوارزمية تجزئة للتحقق من الصورة المسبقة ، وما إلى ذلك.
من السهل على القراء معرفة كيفية تحسين قابلية برمجة الخلية على UTXOs:
إلى جانب هيكل "إخراج المعاملة" للخلية نفسها ، فإن فوائد هاتين النقطتين في حد ذاتها مهمة للغاية ، ولكن من الوصف أعلاه وحده ، لا نعرف كيف تحقق الخلية "عقد واحد يصل إلى حالة عقد آخر في وقت التشغيل". للقيام بذلك ، نحتاج إلى الاعتماد على مفهوم تمت مناقشته لفترة طويلة في مجتمع Bitcoin: "العهود".
(2) القيود والاستبطان
الغرض الأصلي من شرط التقييد هو تحديد المكان الذي يمكن فيه إنفاق مبلغ من المال. على Bitcoin الحالي (حيث لم يتم اقتراح أي قيود) ، يمكن إنفاق مبلغ واحد من المال ، بمجرد إلغاء قفله ، في أي مكان (يمكن دفعه إلى مفتاح عام نصي تعسفي). لكن فكرة شرط التقييد هي أنه يمكن إنفاقه بطريقة تقيده في أماكن معينة ، على سبيل المثال ، لن يتم إنفاق UTXO معين إلا من خلال معاملة معينة ، بحيث حتى إذا كان بإمكان شخص ما تقديم توقيع ل UTXO ، حيث يمكن إنفاقه تم تحديده بالفعل من خلال تلك المعاملة. قد يبدو هذا غريبا بعض الشيء ، لكنه قد يؤدي إلى بعض التطبيقات المثيرة للاهتمام ، والتي سيتم تناولها في قسم لاحقا. الأهم من ذلك ، هو المفتاح لفهمنا الإضافي لقابلية برمجة CKB.
يشير راستي راسل بحق إلى أنه يمكن فهم التقييد على أنه قدرة "استبطان" على التداول ، أي عندما يتم إنفاق UTXO A بواسطة معاملة B ، يمكن لمشغل البرنامج النصي قراءة بعض (أو كل) المعاملة B ثم التحقق من أنها تتطابق مع المعلمات المطلوبة مسبقا بواسطة البرنامج النصي. على سبيل المثال ، ما إذا كان المفتاح العام للبرنامج النصي للإخراج الأول للمعاملة A يتطابق مع ما هو مطلوب بواسطة المفتاح العام للبرنامج النصي ل UTXO A (هذا ما يعنيه التقييد في الأصل).
سيدرك القارئ الذكي أنه من خلال الاستبطان الكامل ، يمكن لإدخال معاملة واحدة قراءة حالة إدخال آخر لنفس المعاملة ، مما يتيح قدرة عقد واحد على الوصول إلى حالة عقد آخر في وقت التشغيل. في الواقع ، هذا هو بالضبط كيف تم تصميم خلية CKB.
بناء على ذلك ، يمكننا تقسيم هذه القدرة الاستبطانية الكاملة إلى أربعة سيناريوهات:
يتيح لنا ذلك تحليل دور القدرات الاستبطانية لكل جزء في حالات الاستخدام المختلفة في ظل افتراضات معينة (تقسيم الوظائف بين القفل والنوع) ، أي اكتساب قابلية البرمجة الذي يجلبه لنا كل جزء.
في القسمين التاليين ، سنلقي نظرة على البرمجة الحالية (وغير المقترحة بعد) ل Bitcoin Script ، والوظيفة المحتملة التي من المتوقع أن يحققها التقييد المقترح ، وذلك لإعطاء فهم ملموس لكيفية برمجة CKB Cell والقيام بها بشكل أفضل.
III. برمجة نصوص البيتكوين
في هذا القسم ، سنستخدم "Lightning Channel / Lightning Network" و "Caution Journal Contract (DLC)" كأمثلة على برمجة التطبيقات القائمة على Bitcoin Script. قبل أن ندخل في ذلك ، دعونا نأخذ شيئين فيه.
(1) OP \ _IF و "صفقات الالتزام"
المفهوم الأول هو رمز التشغيل للتحكم في التدفق في Bitcoin Script ، مثل: OP \ _IF ، OP \ _ELSE. لا تختلف رموز التشغيل هذه عن IF في برمجة الكمبيوتر ، والغرض منها هو تنفيذ عبارات مختلفة بناء على مدخلات مختلفة. في سياق Bitcoin Script ، هذا يعني أنه يمكننا تعيين مسارات فتح متعددة للأموال ؛ إلى جانب ميزة قفل الوقت ، هذا يعني أنه يمكننا إعطاء الأولوية للإجراءات.
خذ "عقد Hash Timelock Contract (HTLC)" الشهير كمثال ، والذي يترجم إلى العامية:
هذا "أو ... أو ..." يتم تحقيق التأثير من خلال رمز التشغيل للتحكم في العملية.
الميزة الأبرز ل > HTLC هي أنه يمكنه تجميع عمليات متعددة معا وتفتيتها. على سبيل المثال ، إذا أرادت أليس تبادل BTC مقابل CKB مع Bob ، فيمكن ل Bob أولا إعطاء قيمة تجزئة وإنشاء HTLC على شبكة Nervos. تقوم أليس بعد ذلك بإنشاء HTLC على Bitcoin يستخدم نفس التجزئة. بدلا من ذلك ، يأخذ بوب BTC التي تدفعها Alice على Bitcoin ، بينما يكشف أيضا عن الصورة المسبقة ، مما يسمح لأليس بسحب CKB على شبكة Nervos. في كلتا الحالتين ، لا يكشف بوب عن الصورة الأصلية ، وينتهي كلا العقدين ، ويمكن لكل من أليس وبوب استعادة الأموال التي استثمروها.
بعد تنشيط شوكة Taproot الناعمة ، يتم تحسين ميزة مسار الفتح المتعدد هذه من خلال إدخال MAST (شجرة بناء جملة Merkle المجردة): يمكننا تحويل مسار إلغاء القفل إلى ورقة على شجرة Merkle ، كل ورقة مستقلة ، لذلك لم تعد هناك حاجة لاستخدام رمز التشغيل للتحكم في التدفق ؛ أيضا ، نظرا لأنه يتم الكشف عن مسار واحد دون الكشف عن المسارات الأخرى ، يمكننا إضافة عدد أكبر من مسارات الفتح إلى الناتج دون الحاجة إلى القلق بشأن الاقتصاد.
المفهوم الثاني هو "تداول الالتزام". فكرة المعاملة الملتزم بها هي أنه في بعض الحالات ، تكون معاملة Bitcoin الصالحة ، حتى لو لم يتم تأكيدها بواسطة blockchain ، حقيقية وملزمة بنفس القدر.
على سبيل المثال ، تشترك Alice و Bob في UTXO يتطلب توقيع كلاهما للإنفاق. في هذه المرحلة ، تبني أليس معاملة لإنفاقها ، وتحويل 60٪ من قيمتها إلى بوب والباقي لنفسها. تقدم أليس توقيعها الخاص للمعاملة ، والتي يتم إرسالها بعد ذلك إلى بوب. حسنا ، بالنسبة لبوب ، لا يجب بثها على شبكة Bitcoin ، ولا يجب تأكيدها بواسطة blockchain ، كما أن تأثير الدفع لهذه المعاملة حقيقي وموثوق. نظرا لأن أليس لا يمكنها إنفاق UTXO بمفردها (وبالتالي لا يمكنها إنفاقها بشكل متكرر) ، ولأن التوقيع المقدم من Alice صالح ، يمكن لبوب دائما إضافة توقيعه وبث المعاملة لتكريم الدفع. بعبارة أخرى ، قدمت أليس لبوب "التزاما موثوقا به" من خلال هذه المعاملة الصالحة (خارج السلسلة).
المعاملات الملتزم بها هي مفهوم أساسي لبرمجة تطبيقات Bitcoin. كما ذكرنا سابقا ، فإن عقد Bitcoin قائم على التحقق ، وعديم الجنسية ، ولا يسمح بالوصول المتبادل. ومع ذلك ، إذا كان العقد لا يحمل حالات ، فأين يتم تخزين تلك الحالات ، وكيف يمكن للعقد المضي قدما بأمان (تغيير الحالة)؟ تعطي معاملات الالتزام إجابة مباشرة: يمكن التعبير عن حالة العقد في شكل معاملات ، بحيث يمكن للمشاركين في العقد إنقاذ الحالة بأنفسهم دون الحاجة إلى عرضها على blockchain ؛ يمكن أيضا تحويل مشكلة تغيير حالة العقد إلى مشكلة كيفية تحديث المعاملة الملتزم بها بأمان ؛ بالإضافة إلى ذلك ، إذا كنا قلقين بشأن مخاطر إبرام عقد (على سبيل المثال ، إبرام عقد يتطلب من كلا الطرفين التوقيع من أجل الإنفاق ، وهناك خطر من أن الطرف الآخر لن يستجيب ويتعثر) ، فإن مجرد إنشاء معاملة التزام تكلف العقد مقدما والحصول على توقيع يمكن أن يخفف من المخاطر ويزيل الثقة في المشاركين الآخرين.
(2) قناة البرق وشبكة البرق
قناة البرق هي عقد واحد إلى واحد حيث يمكن لطرفين أن يدفعا لبعضهما البعض عددا غير محدود من المرات دون تأكيد أي دفعة واحدة بواسطة blockchain. كما قد تتوقع ، فإنه يستخدم تداول الالتزام.
في القسم الذي يشرح "المعاملات الملتزم بها" ، قدمنا بالفعل قناة دفع. ومع ذلك ، فإن هذا النوع من العقود ، الذي يستفيد فقط من 2 من 2 multisig ، يمكن أن يتيح فقط المدفوعات في اتجاه واحد. أي أن أليس تدفع دائما لبوب ، أو يدفع بوب دائما لأليس حتى يستهلك رصيده في العقد. إذا كانت دفعة ثنائية الاتجاه ، فهذا يعني أنه بعد تحديث الحالة ، قد يكون لدى أحد الطرفين رصيد أقل من ذي قبل ، لكن TA لديه آخر معاملة ملتزم بها موقعة من الطرف الآخر - ما الذي يمكن فعله لمنع TA من بث الوعد القديم و TA من أحدث معاملة التزام فقط؟
يسمى حل هذه المشكلة مع قناة البرق "LN-Penalty". الآن ، لنفترض أن كل من أليس وبوب لديهما 5 BTC في قناة ؛ الآن تريد أليس أن تدفع لبوب 1 BTC ، لذلك توقع على المعاملة الموعودة وترسلها إلى بوب:
يوقع بوب أيضا التزاما (يتوافق مع المعاملة المذكورة أعلاه) ويرسله إلى أليس:
تكمن الحيلة هنا في هذا "المفتاح العام المؤقت المشترك" ، والذي يتم إنشاؤه باستخدام أحد مفاتيحها العامة ومفتاح عام يوفره الطرف الآخر ، على سبيل المثال ، المفتاح العام المؤقت المشترك Alice-Bob ، والذي تحصل عليه Alice باستخدام أحد مفاتيحها العامة ومفتاح عام يقدمه Bob ، بضرب كل منهما في قيمة التجزئة. عندما يتم إنشاء مثل هذا المفتاح العام ، لا أحد يعرف مفتاحه الخاص. ومع ذلك ، إذا أخبر بوب أليس بالمفتاح الخاص للمفتاح العام الذي قدمه ، فيمكن لأليس حساب المفتاح الخاص للمفتاح العام المؤقت الموحد. - هذا هو مفتاح حقيقة أن قناة البرق يمكنها "التراجع" عن الحالة القديمة.
في المرة التالية التي يريد فيها الطرفان تحديث حالة القناة (بدء الدفع) ، يتبادل الطرفان المفتاح الخاص للمفتاح العام المؤقت الممنوح لبعضهما البعض في الجولة السابقة. وبهذه الطريقة ، لم يعد المشاركون يجرؤون على بث آخر معاملة موعودة تلقوها: ناتج هذه المعاملة الموعودة التي تحدد قيمة لطرفهم له مساران ، والمفتاح الخاص لمسار المفتاح العام المؤقت معروف بالفعل للطرف الآخر ؛ لذلك بمجرد بث معاملة الالتزام القديمة ، يمكن للطرف الآخر على الفور استخدام هذا المفتاح الخاص المؤقت المشترك لأخذ جميع الأموال في هذا الناتج. - هذا ما تعنيه "عقوبة LN".
وعلى وجه التحديد، يكون ترتيب التفاعل كما يلي: يطلب الطرف الذي يبدأ الدفع أولا مفتاحا عموميا مؤقتا جديدا من الطرف الآخر، ثم ينشئ معاملة التزام جديدة ويسلمها إلى الطرف الآخر؛ كشف الطرف الذي حصل على المعاملة الموعودة للطرف الآخر عن المفتاح الخاص للمفتاح العام المؤقت الذي قدمه في الجولة السابقة. يضمن تسلسل التفاعلات هذا حصول المشاركين دائما على معاملة التزام جديدة قبل إبطال معاملة الالتزام التي تلقوها في الجولة السابقة ، وبالتالي فهي غير موثوقة.
باختصار ، التصاميم الرئيسية لقناة البرق هي:
أخيرا ، نظرا لأنه يمكن أيضا وضع HTLC في معاملة ملتزمة ، يمكن لقناة Lightning أيضا إعادة توجيه المدفوعات. بافتراض أن أليس يمكنها العثور على مسار يتكون من قنوات البرق التي تتصل قبل وبعد الوصول إلى دانيال ، فيمكن تحقيق مدفوعات متعددة القفزات غير موثوق بها دون فتح قناة مع دانيال. هذه هي شبكة البرق:
عندما تجد أليس مثل هذا المسار وتريد أن تدفع لدانيال ، تطلب من دانيال تجزئة لإنشاء HTLC لبوب ، وتطالب بوب بإعادة توجيه رسالة إلى كارول وتقديم نفس HTLC ؛ تطالب الرسالة كارول بإعادة توجيه الرسالة إلى دانيال وتقديم نفس HTLC. عندما تصل الأخبار إلى دانيال ، يكشف عن الصورة المسبقة لكارول ، مما يمنحه قيمة HTLC ويقوم بتحديث حالة العقد. فعلت كارول الشيء نفسه ، حيث حصلت على أموال من بوب وتحديث حالة القناة. أخيرا ، يكشف بوب عن الصورة المسبقة لأليس ويقوم بتحديث الحالة. نظرا لطبيعة HTLC ، فإن سلسلة المدفوعات هذه إما تنجح أو تفشل معا ، وعلى هذا النحو ، فهي غير موثوقة.
تتكون شبكة Lightning Network من قناة واحدة تلو الأخرى ، كل منها مستقل عن الآخر. هذا يعني أن أليس تحتاج فقط إلى معرفة ما يحدث في قناتها مع بوب ، بغض النظر عن عدد التفاعلات التي حدثت في قنوات الآخرين ، أو العملة التي تستخدمها هذه التفاعلات ، أو حتى ما إذا كانوا يستخدمون القناة بالفعل.
لا تنعكس قابلية التوسع في شبكة Lightning Network فقط في حقيقة أن سرعة الدفع داخل قناة Lightning محدودة فقط من خلال استثمار موارد الأجهزة من قبل كلا الطرفين ، ولكن أيضا نظرا للتخزين اللامركزي للدولة ، يمكن لعقدة واحدة الاستفادة من الرافعة المالية القصوى بأقل تكلفة.
(3) كن حذرا من عقود دفتر اليومية
يستخدم عقد دفتر اليومية التحذيري (DLC) تقنية تشفير تسمى "توقيع المحول" والتي تسمح ل Bitcoin Script ببرمجة العقود المالية التي تعتمد على الأحداث الخارجية.
تسمح توقيعات المحول للتوقيع بأن يصبح توقيعا صالحا فقط بعد إضافة مفتاح خاص. خذ على سبيل المثال توقيع Schnorr ، حيث يكون الشكل القياسي لتوقيع Schnorr هو (R ، s) ، حيث:
لنفترض أنني أعطي زوجا من البيانات (R ، s') حيث:
من الواضح أن هذا ليس توقيع Schnorr صالحا ، ولا يجتاز صيغة التحقق من الصحة ، لكن يمكنني أن أثبت للمدقق أنه يمكن أن يكون توقيعا صالحا بمجرد معرفة المفتاح الخاص ل R 2 ، r 2:
تجعل توقيعات المحول صلاحية التوقيع تعتمد على بيانات سرية ويمكن التحقق منها. ولكن ما علاقة هذا بالعقود المالية؟
لنفترض أن أليس وبوب يريدان المراهنة على نتيجة لعبة الكرة. راهنت أليس وبوب على العفريت الأخضر وألينا للفوز ، على التوالي ، برهان 1 BTC. بالإضافة إلى ذلك ، وعد موقع كارول ، وهو موقع ويب لمراجعة كرة القدم ، باستخدام nonce R \ _c لنشر موقع s \ _c \ _i من النتائج عند الإعلان عن نتائج اللعبة.
كما يتضح ، هناك ثلاث نتائج محتملة (لذلك هناك 3 احتمالات لتوقيع كارول):
العفريت الأخضر يفوز ، أليس يفوز ب 1 BTC
ألينا تفوز ، وبوب يفوز ب 1 BTC
التعادل ، تعود أموال الاثنين بنفس الطريقة
للقيام بذلك ، يقوم الاثنان بإنشاء صفقة التزام لكل نتيجة. على سبيل المثال ، ستبدو معاملة الالتزام التي أنشأوها للنتيجة الأولى كما يلي:
ومع ذلك ، بدلا من (R ، s) ، فإن توقيع Alice and Bob الذي تم إنشاؤه لهذه المعاملة هو توقيع محول (R ، s ') ؛ بمعنى آخر ، لا يمكن استخدام التوقيعات المقدمة لبعضهما البعض من قبل الطرفين مباشرة لفتح العقد ، ولكن يجب أن تكشف عن قيمة سرية. هذه القيمة السرية هي صورة s \ _c \ _ 1.G ، وهي توقيع كارول! نظرا لأنه تم تحديد قيمة nonce لتوقيع كارول (R \ _c) ، يمكن إنشاء s \ _c \ _ 1.G (s \ _c \ _ 1.G = R \ _c + التجزئة (R \ _c ||). "العفريت الأخضر يفوز" || PK_c) * PK_c)。
عندما يتم الكشف عن النتائج ، بافتراض فوز Green Goblin ، ستصدر كارول توقيعا (R \ _c ، s \ _c \ _ 1) ، بحيث يمكن لأي من Alice أو Bob إكمال توقيع محول الخصم وإضافة توقيعهم الخاص لجعل المعاملة المذكورة أعلاه معاملة صالحة ، وبثها إلى الشبكة لبدء تأثير التسوية. ولكن إذا لم يفز العفريت الأخضر ، فلن تنشر كارول s \ _c _ 1 ، ولن تكون صفقة الالتزام صفقة صالحة.
وهكذا ، كما هو الحال مع الصفقتين الأخريين. وبهذه الطريقة ، تجعل أليس وبوب تنفيذ العقد يعتمد على الأحداث الخارجية (على وجه الدقة ، على بث آلة التأكيد للأحداث الخارجية ، في شكل توقيع) دون الحاجة إلى الوثوق بالطرف المقابل. يمكن تنفيذ العقود المالية الكبيرة والصغيرة ، مثل العقود الآجلة والخيارات ، بهذه الطريقة.
بالمقارنة مع أشكال التنفيذ الأخرى ، فإن أهم ميزة لعقد السجل الحذر هي خصوصيته: (1) لا تحتاج أليس وبوب إلى إخبار كارول بأنهما يستخدمان بيانات كارول ، والتي لا تؤثر على تنفيذ العقد على الإطلاق ؛ (2) لن يتمكن المراقبون على السلسلة (بما في ذلك كارول) من تحديد موقع الويب الذي يستخدمونه من خلال تنفيذ عقد أليس وبوب ، أو حتى أن عقدهم هو عقد مراهنة (وليس قناة برق).
IV. مقدمة في تطبيق القيود
(أ) OP \ _CTV والتحكم في الازدحام
قدم مطورو مجتمع Bitcoin عددا من المقترحات التي يمكن تصنيفها على أنها بنود تقييدية. في الوقت الحالي ، أحد أكثر المقترحات شهرة هو OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV) ، والذي يحظى بشعبية لدى مجتمع Bitcoin لبساطته ومرونته بمفهومه البسيط. وتتمثل فكرة OP_CTV في وضع تجزئة في البرنامج النصي لتقييد أن الأموال لا يمكن إنفاقها إلا من خلال المعاملات التي تمثلها هذه التجزئة؛ تعد هذه التجزئة بإخراج المعاملة ومعظم الحقول ، ولكن ليس مدخلات المعاملة ، فقط عدد المدخلات.
"التحكم في الازدحام" هو مثال جيد على كيفية إظهار OP \ _CTV. حالة الاستخدام الأساسية هي مساعدة عدد كبير من المستخدمين على الخروج من التبادل (بيئة تتطلب الثقة) إلى تجمع ؛ نظرا لأن هذا التجمع يستخدم OP \ _CTV للتخطيط لكيفية إنفاقه في المستقبل ، فإنه يضمن أن المستخدمين يمكنهم الخروج من التجمع دون ثقة ، دون مساعدة من أي شخص ؛ ولأن هذا التجمع يتصرف فقط ك UTXO ، فإنه يتجنب دفع الكثير من الرسوم عندما يكون الطلب على المعاملات على السلسلة مرتفعا (من مخرجات n إلى مخرجات 1 ؛ خفضت أيضا من المعاملات n إلى 1 معاملة). يمكن للمستخدمين في المسبح انتظار فرصة للخروج من المسبح.
لنفترض أن أليس وبوب وكارول يريدون سحب 5 BTC و 3 BTC و 2 BTC من البورصة على التوالي. ثم يمكن للتبادل إخراج 10 BTC مع 3 OP \ _CTV فروع. لنفترض أن أليس تريد سحب الأموال ، يمكنها استخدام الفرع 1 ؛ ستشكل المعاملة التي تمثلها قيمة التجزئة المستخدمة من قبل OP \ _CTV للفرع ناتجين ، أحدهما هو تخصيص 5 BTC إلى Alice ؛ الناتج الآخر ، بدوره ، هو تجمع ، والذي يستخدم أيضا OP \ _CTV للالتزام بمعاملة ، مما يسمح لبوب بسحب 3 BTC فقط وإرسال 2 BTC المتبقية إلى Carol.
إنه نفس الشيء إذا أراد بوب أو كارول سحب الأموال. عند سحب الأموال ، سيكونون قادرين فقط على استخدام المعاملات التي يمكنها اجتياز فحص OP \ _CTV المقابل ، أي أنهم سيكونون قادرين فقط على دفع المبلغ المقابل لأنفسهم ، ولن يكونوا قادرين على سحب الأموال بشكل تعسفي ؛ ستذهب الأموال المتبقية إلى مجمع بقفل OP \ _CTV ، مما يضمن إمكانية وضع المستخدمين المتبقين خارج المجمع دون ثقة ، بغض النظر عن الترتيب الذي يتم سحبهم به.
في الملخص ، يتمثل دور OP \ _CTV هنا في تخطيط المسار حتى نهاية عمر العقد للعقد ، بحيث يمكن للعقد المجمع هنا الحفاظ على سمة الخروج غير الموثوق به بغض النظر عن المسار الذي يسلكه أو الحالة التي يسير فيها.
هناك أيضا استخدام مثير للاهتمام للغاية لهذا OP \ _CTV: "قناة دفع أحادية الاتجاه مخفية ولكن لم يتم الكشف عنها". لنفترض أن أليس تشكل مثل هذا التجمع من الأموال وتضمن أنه يمكن سحب الأموال دون ثقة إلى مخرجات باستخدام البرنامج النصي التالي:
إذا لم تكشف أليس عن ذلك لبوب ، لما عرف بوب بوجود مثل هذا الإنتاج. بمجرد أن تكشف أليس عن ذلك لبوب ، يمكن لبوب استخدام الإخراج كقناة دفع حساسة للوقت وأحادية الاتجاه يمكن لأليس استخدامها لدفع بوب على الفور دون الحاجة إلى انتظار التأكيد من blockchain. يطلب بوب ببساطة من أليس وضع معاملة التزامه على السلسلة قبل أن تتمكن أليس من إنفاقها بمفرده.
(ب) OP \ _Vault وآمنة
OP \ _VAULT هو اقتراح لشرط تقييدي مصمم خصيصا لبناء "خزائن".
تم تصميم عقد Vault ليكون شكلا أكثر أمانا وتقدما من الحضانة الذاتية. على الرغم من أن العقد الحالي متعدد التواقيع يمكن أن يتجنب نقطة فشل واحدة لمفتاح خاص واحد ، إذا حصل المهاجم على عدد عتبة من المفاتيح الخاصة ، فإن مالك المحفظة عاجز. تريد Vault فرض حد إنفاق واحد على أموالك. في الوقت نفسه ، عند سحب الأموال منه باستخدام المسار العادي ، ستفرض عملية السحب فترة انتظار ؛ وخلال فترة الانتظار ، يمكن مقاطعة عملية السحب عن طريق عملية الاسترداد الطارئ للمحفظة. حتى إذا تم خرق مثل هذا العقد ، يمكن لمالك المحفظة بدء عملية مضادة (باستخدام فرع الاسترداد في حالات الطوارئ).
من الناحية النظرية ، يمكن ل OP \ _CTV أيضا برمجة مثل هذا العقد ، ولكن هناك العديد من المضايقات ، أحدها العمولة: أثناء الالتزام بالمعاملة ، فإنه يعد أيضا بالرسوم التي ستدفعها المعاملة. بالنظر إلى الغرض من هذا العقد ، يجب أن تكون الفترة الزمنية بين إعداد العقد وسحب الأموال طويلة جدا ، لذلك يكاد يكون من المستحيل التنبؤ بالعمولة المناسبة. على الرغم من أن OP \ _CTV لا يحد من المدخلات ، وبالتالي يمكن زيادة الرسوم عن طريق زيادة المدخلات ، فإن المدخلات المقدمة ستصبح جميعها عمولة ، لذلك فهي غير واقعية ؛ طريقة أخرى هي CPFP ، وهي توفير عمولة على المعاملات الجديدة عن طريق إنفاق الأموال المسحوبة. بالإضافة إلى ذلك ، يعني استخدام OP \ _CTV أنه لا يمكن سحب عقد Vault هذا بكميات كبيرة (وبالتأكيد لا يمكن استعادته بكميات كبيرة).
ويحاول مقترح البروتوكول الاختياري _VAULT معالجة هذه المسائل باقتراح رمزي تشغيليين جديدين (OP_VAULT وOP_UNVAULT). تم تصميم OP \ _UNVAULT لمرونة الدفعات ، لذلك لن نذكرها في الوقت الحالي. يتصرف OP \ _VAULT على النحو التالي: عندما نضعه على فرع من شجرة البرنامج النصي ، يمكن استخدامه للالتزام برمز تشغيلي قابل للاستخدام (مثل OP \ _CTV) بدون معلمات محددة ؛ عند إنفاق هذا الفرع ، يمكن تمرير المعاملات في معايير محددة ، ولكن ليس الفروع الأخرى. نتيجة لذلك ، لا يتعين عليه تعيين رسوم محددة مسبقا ، ويمكن تعيينها عند إنفاق الفرع ؛ بافتراض أن الفرع لديه أيضا قفل زمني ، فإنه سيفرض قفلا زمنيا ؛ أخيرا ، نظرا لأنه يمكنك فقط تغيير الفرع الذي تعمل فيه ، ولن يتم تغيير أي فرع آخر من شجرة البرنامج النصي الجديد (بما في ذلك فرع الاسترداد في حالات الطوارئ) ، يسمح لنا بمقاطعة عمليات السحب هذه.
وبالإضافة إلى ذلك، تجدر الإشارة إلى نقطتين: (1) يتصرف رمز التشغيل OP_VAULT بشكل مشابه لمقترح تقييد آخر: OP_TLUV؛ و (2) يتصرف رمز التشغيل OP\ بشكل مشابه لمقترح تقييد آخر: OP; يشير جيريمي روبن بحق إلى أن هذا قد أدى إلى ظهور مفهوم "الحساب" إلى حد ما: يعد OP \ _TLUV / OP \ _VAULT أولا برمز تشغيلي للسماح للمستهلك بتحديث ورقة شجرة البرنامج النصي بالكامل عن طريق تمرير المعلمات إلى رمز التشغيل بمعاملة جديدة ؛ لم يعد الأمر يتعلق ب "التحقق من صحة البيانات الواردة بناء على معايير معينة" ، بل يتعلق ب "إنشاء بيانات جديدة ذات مغزى بناء على البيانات الواردة" ، على الرغم من أن الحساب الذي يمكن تمكينه محدود.
(2) يستفيد اقتراح OP \ _VAULT الكامل أيضا من بعض المقترحات المتعلقة بسياسة mempool (على سبيل المثال ، معاملات v3) لتحقيق نتائج أفضل. هذا يذكرنا بأن معنى "البرمجة" يمكن أن يكون أوسع مما نعتقد. (مثال مماثل هو فتح معاملة في شبكة Nervos.) ）
V. فهم CKB
في القسمين أعلاه ، نصف كيف يمكننا كتابة تطبيقات مثيرة للاهتمام على بنية أكثر تقييدا (Bitcoin UTXO) ؛ وقدمت أيضا مقترحات لمحاولة إضفاء طابع استبطاني على هذا الهيكل.
بينما تتمتع UTXOs بالقدرة على برمجة هذه التطبيقات ، فمن السهل على القراء اكتشاف أوجه القصور أو المجالات التي يمكن تحسينها ، مثل:
في الواقع ، توصل مجتمع Bitcoin إلى إجابات على هذه الأسئلة ، تتعلق أساسا باقتراح Sighash (BIP-118 AnyPrevOut).
ومع ذلك ، إذا كنا نبرمج على CKB ، فسيكون BIP-118 متاحا الآن (يمكن محاكاة علامات Sighash هذه مع القدرة على التحقق من التوقيعات بشكل استبطاني وهادف).
من خلال تعلم برمجة Bitcoin ، لا نعرف فقط كيف يمكن برمجتها بتنسيق "إخراج المعاملات" (ما يمكن برمجته في CKB) ، ولكن أيضا كيفية تحسين هذه التطبيقات (وكيف يمكننا استخدام قدرات CKB لتحسينها إذا قمنا ببرمجتها على CKB). بالنسبة لمطوري CKB ، يمكن استخدام البرمجة القائمة على Bitcoin Script كمواد تعليمية أو حتى اختصار.
أدناه ، دعنا نحلل قابلية برمجة كل وحدة من برمجة CKB واحدة تلو الأخرى. دعونا لا نفكر في الاستبطان في الوقت الحالي.
(1) قفل محسوب بشكل تعسفي قابل للبرمجة
كما ذكر أعلاه ، لا يمكن برمجة UTXOs للحساب التعسفي. من ناحية أخرى ، يعني القفل أن Lock يمكنه برمجة كل شيء (قبل نشر التقييد) بناء على UTXO ، بما في ذلك على سبيل المثال لا الحصر قناة Lightning و DLC المذكورة أعلاه.
بالإضافة إلى ذلك ، فإن هذه القدرة على التحقق من الحساب التعسفي تجعل Lock أكثر مرونة من UTXO من حيث طرق المصادقة. على سبيل المثال ، يمكننا تنفيذ قناة البرق على CKB حيث يوقع أحد الطرفين ECDSA ويستخدم الطرف الآخر RSA.
في الواقع ، هذا هو أحد المجالات الأولى التي بدأ الناس في استكشافها في CKB: استخدام إمكانية المصادقة المرنة هذه في الوصاية الذاتية للمستخدم لتمكين ما يعرف باسم "تجريد الحساب" - تفويض صلاحية المعاملة واستعادة التحكم مرنان للغاية وغير محدودين تقريبا. من حيث المبدأ ، هذا مزيج من "فروع الإنفاق المتعددة" و "طرق المصادقة التعسفية". أمثلة على التطبيقات هي: محفظة جويد ، يونيباس.
بالإضافة إلى ذلك ، يمكن ل Lock تنفيذ مقترحات eltoo ، مما يتيح قناة البرق التي تحتاج فقط إلى الاحتفاظ بأحدث معاملة ملتزم بها (في الواقع ، يمكن ل eltoo تبسيط جميع عقود نظير إلى نظير).
(2) نوع قابل للبرمجة محسوب بشكل تعسفي
كما ذكر أعلاه ، فإن أحد الاستخدامات الكبيرة للنوع هو برمجة UDTs. بالاقتران مع Lock ، هذا يعني أنه يمكننا تنفيذ قنوات البرق القائمة على UDT (وأنواع أخرى من العقود).
في الواقع ، يمكن اعتبار الانقسام بين Lock و Type بمثابة ترقية أمنية: يركز Lock على تنفيذ طرق الحضانة أو الاتفاقيات التعاقدية ، بينما يركز Type على تحديد UDTs.
بالإضافة إلى ذلك ، فإن القدرة على بدء عمليات التحقق بناء على تعريفات UDT تمكن UDT أيضا من المشاركة في العقود بطريقة مماثلة ل CKB (UDT مواطن من الدرجة الأولى).
على سبيل المثال ، اقترح المؤلف ذات مرة بروتوكولا لتنفيذ الإقراض المدعوم من NFT غير الموثوق به على Bitcoin. مفتاح مثل هذا البروتوكول هو معاملة ملتزمة حيث تكون قيمة المدخلات أقل من قيمة المخرجات (لذلك فهي ليست معاملة صالحة بعد) ، ولكن بمجرد توفير مدخلات كافية للمعاملة ، فهي معاملة صالحة: بمجرد أن يتمكن المقرض من السداد ، لا يمكن للمقرض أن يأخذ NFT المرهون لنفسه. ومع ذلك ، فإن عدم الثقة في معاملة الالتزام هذه يعتمد على المعاملة التي تتحقق من كمية المدخلات والمخرجات ، لذلك يمكن للمقرض استخدام Bitcoin فقط لسداد القرض - حتى لو كان كل من المقرض والمقرض على استعداد لقبول عملة أخرى (مثل USDT الصادرة بموجب بروتوكول RGB) ، فإن معاملة التزام Bitcoin لا تضمن أن المقرض سيستعيد NFT الخاص به طالما أن المقرض يعيد المبلغ الكامل ل USDT ، لأن معاملة Bitcoin ليس لديها فكرة عن حالة USDT! (المراجعة: بمعنى آخر ، لا يمكن إنشاء معاملة ملتزم بها مشروطة بسداد USDT.) ）
إذا تمكنا من بدء شيك بناء على تعريف UDT ، فسنكون قادرين على جعل المقرض يوقع على معاملة أخرى ملتزمة تسمح للمقرض باستخدام USDT لسداد القرض. ستتحقق المعاملة من مبلغ USDT الذي تم إدخاله ومبلغ USDT الخارج ، مما يمنح المستخدمين سدادا غير موثوق به باستخدام USDT.
تعديل >: بافتراض أن NFT المستخدم كضمان وأن الرمز المميز المستخدم للسداد يتم إصدارهما باستخدام نفس البروتوكول (مثل RGB) ، فيمكن حل المشكلة هنا ، ويمكننا إنشاء معاملة التزام وفقا لبروتوكول RGB ، بحيث يمكن أن يحدث انتقال الحالة وسداد NFT في وقت واحد (يرتبط انتقالان للحالة بالمعاملات داخل بروتوكول RGB). ومع ذلك ، نظرا لأن معاملات RGB تعتمد أيضا على معاملات Bitcoin ، فإن إنشاء معاملات الالتزام هنا سيكون صعبا إلى حد ما. الكل في الكل ، على الرغم من أن المشكلة يمكن حلها ، إلا أنه لا يمكن القيام بذلك الرمز المميز هو مواطن من الدرجة الأولى.
بعد ذلك ، دعونا نفكر في الاستبطان.
(3) قفل يقرأ أقفال أخرى
هذا يعني مجموعة كاملة من إمكانيات البرمجة على Bitcoin UTXOs بعد تنفيذ التقييد المقترح. يتضمن ذلك عقود Vault المذكورة أعلاه ، بالإضافة إلى التطبيقات المستندة إلى OP \ _CTV (على سبيل المثال ، التحكم في الازدحام).
ذكر XueJie ذات مرة مثالا مثيرا للاهتمام: يمكنك تنفيذ خلية حساب تجميع على CKB ، عند استخدام هذا النوع من الخلايا كمدخل للمعاملة ، إذا كانت خلية الإخراج (الخلية التي تستخدم نفس القفل) ذات سعة أكبر ، فلن يحتاج الإدخال إلى توفير توقيع ولا يؤثر على صلاحية المعاملة. في الواقع ، لن يكون هذا النوع من الخلايا ممكنا بدون القدرة على الاستبطان. تعتبر خلية حساب التحصيل هذه مثالية كطريقة مؤسسية لتلقي الأموال لأنها تجمع الأموال ولها عيب عدم وجود شعور جيد بالخصوصية.
(4) قفل يقرأ أنواع أخرى (والبيانات)
تطبيق مثير للاهتمام لهذه القدرة هو الرموز المميزة. سيقرر Lock ما إذا كان بإمكانه استخدام سعته الخاصة بناء على عدد الرموز المميزة في المدخلات الأخرى ، وأين يمكن إنفاقها (يتطلب القدرة على استبطان القفل).
(5) اكتب يقرأ الأقفال الأخرى
لست متأكدا ، ولكن يمكن افتراض أنه مفيد. على سبيل المثال، يمكنك التحقق من النوع الذي تظل فيه أقفال مدخلات ومخرجات المعاملة دون تغيير.
(6) النوع Scirpt يقرأ أنواعا (وبيانات) أخرى
بطاقات التداول؟ اجمع n الرموز مقابل رمز مميز أكبر :)
سادسا. خاتمة
مقارنة بأنظمة العقود الذكية السابقة التي يمكن برمجتها بحساب تعسفي ، مثل Ethereum ، تأخذ Nervos Network بنية مختلفة. نتيجة لذلك ، غالبا ما يكون من الصعب فهم شبكة Nervos بناء على معرفة أنظمة العقود الذكية في الماضي. تقترح هذه الورقة طريقة لفهم قابلية برمجة خلية CKB ، بدءا من برمجة التطبيقات لهيكل أكثر تقييدا من خلية CKB ، BTC UTXO. وباستخدام مفهوم "الاستبطان" لفهم قدرات "الوصول عبر العقود" للخلايا ، يمكننا تقسيم المواقف التي تستخدم فيها القدرات الاستبطانية وتحديد استخداماتها المحددة.
التكرار:
النقطتان المذكورتان أعلاه تعنيان شيئا بنفس نموذج "BTC + RGB" ولكن مع المزيد من قدرات البرمجة ؛
لا توجد العديد من الأمثلة المحددة لهذه الاستخدامات ، ولكن هذا يرجع إلى عدم فهم المؤلف لبيئة CKB. بمرور الوقت ، يعتقد أنه سيتم استثمار المزيد والمزيد من الخيال فيه ، وسيتم تجميع التطبيقات التي لا يمكن تصورها اليوم.
شكر وتقدير
شكرا ل Retric و Jan Xie و Xue Jie على ملاحظاتهم أثناء كتابة المقال. بالطبع ، أنا مسؤول عن جميع الأخطاء في النص.
المراجع
الحسابات وقوائم الوصول الصارمة و UTXOs
القيود في بيتكوين: تصنيف للمراجعة
نموذج الخلية
عصبي CKB باختصار
قابلية برمجة البيتكوين
على تجريد الحساب (2022)
ما هي شجرة بناء الجملة المجردة بيتكوين ميركل؟
BIP 345: مقترح البروتوكول التشغيلي \ _VAULT
مقدمة إلى رموز عمليات تقييد TLUV
تتم ترقية المكونات التي تبني العقد باستخدام Bitcoin
وأوضح إلتو
عقد إقراض مضمون NFT بناء على المعاملات الملتزم بها · بيتكوين-دراسة/OP_QUESTION · مناقشة #7
رابط المقال الأصلي