المؤلف: فريق ZAN
هذه المقالة مخصصة لمشاركة التكنولوجيا فقط ولا تشكل أي اقتراح للاستثمار.
هل سيكون لدى BTC أيضًا عقد ذكي خاص بها؟
في نظام Bitcoin البيئي الأخير، أطلقت Fractal BTC أخيرًا الشبكة الرئيسية في سبتمبر بعد اجتياز العديد من شبكات الاختبار. الميزة الرئيسية لـ Fractal هي القدرة على الحصول على "عقود ذكية"، وفي نفس الوقت تقريبًا الذي تم فيه إطلاق الشبكة الرئيسية، تم إطلاق بروتوكول الرمز المميز الجديد CAT20. ما هو الذكاء التقني الذي يمتلكه CAT20؟ ماذا يمكننا أن نتعلم؟
Fractal Bitcoin
قبل فهم CAT20، نحتاج إلى فهم Fractal Bitcoin والعلاقة بينهما بشكل موجز تمامًا مثل ERC20 وETH، يتم نشر بروتوكول CAT20 على Fractal Bitcoin.
Fractal Bitcoin، والمعروفة أيضًا باسم Fractal Bitcoin، هي شبكة "طبقة ثانية" متوافقة تمامًا مع BTC. بالمقارنة مع BTC، فإن وقت تأكيد الكتلة الخاص بها أسرع، ويستغرق دقيقة واحدة فقط. مبدأها الأساسي هو ببساطة كما يوحي اسمها، وهو عمل عدة نسخ من شبكة BTC ستقوم كل سلسلة بمعالجة المعاملات كلما زاد عدد العقد التي يمكنها معالجة المعاملات، كلما كانت أسرع بشكل طبيعي. ومع ذلك، فإن التفاصيل المحددة، مثل كيفية تواصل السلاسل المختلفة، ليست واضحة بعد، ولا توجد وثائق فنية رسمية مقابلة للرجوع إليها.
إذا كانت معاملة سلسلة الطبقة الثانية أسرع، فلا يبدو أن هناك أي إثارة. ومع ذلك، فإن تنشيط OP_CAT في Fractal، والذي تخلت عنه BTC منذ فترة طويلة لأسباب أمنية، قد أدى إلى رفع قدرات Fractal Bitcoin إلى مستوى أعلى الطريقة، هناك مجال للخيال أكثر.
الآن، قام شخص ما بتطبيق بروتوكول يشبه ERC20 على Fractal Bitcoin.
أما بالنسبة لسبب التخلي عن OP_CAT ولماذا يمكن استخدامه على Fractal Bitcoin، فيمكننا التحدث عنه لاحقًا، سنركز هنا على CAT20.
بروتوكول CAT
يشير المحتوى التالي إلى المستند التقني: مقدمة | بروتوكول CAT (https://catprotocol.org/)
ومستودع جيثب:
GitHub - CATProtocol/cat-token-box: monorepo للحزم التي تنفذ بروتوكول CAT (https://github.com/CATProtocol/cat-token-box)
مع دعم OP_CAT الأساسي، سيكون البروتوكول المقابل، بروتوكول CAT، متاحًا قريبًا. حاليًا، البروتوكول الذي يتم تشغيله فعليًا هو بروتوكول CAT20، وتمت إضافة لوحة مقابلة على Unisat: https://explorer.unisat.io/fractal-mainnet/cat20.
يجب أن يكون الجميع قادرين على التفاعل عندما يرون اسم CAT20، ويجب أن يكون أكثر شبهاً بـ ERC20. بالمقارنة مع بروتوكول ERC20 الناضج، من الملائم جدًا للجميع نشر رمز مميز. كيف ينفذ CAT20 دورة حياة مشابهة لـ ERC20.
نشر
قبل النشر، يحتاج المستخدمون إلى تحديد عنوان محفظتهم ورقم الرمز المميز الأساسي المعلومات، المعلومات الأساسية للرمز المميز مشابهة لتلك الخاصة بـ ERC20:

ستكون هناك بعض الاختلافات حيث يمكن لـ CAT20 تعيين حدود التعدين المسبق والكمية لكل عملة سك العملة. وبطبيعة الحال، يمكن لـ ERC20 أيضًا تحقيق هذه القدرات من خلال القدرات التعاقدية.
خلال مرحلة النشر، سيتم بدء معاملتين يمكن اعتبارهما مرحلتين: " commit " و" reveal ". نقلاً عن الرسم البياني الرسمي، فإن مراحل النشر هي كما يلي:

في مرحلة "الالتزام"، سيتم كتابة المعلومات الأساسية للرمز المميز في البرنامج النصي الناتج للمعاملة، مثل اسم ورمز الرمز المميز. سيتم استخدام معرف التجزئة للمعاملة التي بدأت في مرحلة "الالتزام" كمعرف للرمز المميز لتمييز الرموز المميزة الأخرى.

يمكنك أن ترى أن utxo لهذه المعاملة " bc1pucq...ashx " يتوافق مع الالتزام. ثم هناك معاملتان متبقيتان تشيران إلى " bc1pszp...rehc4 ". يتم استخدام الأولى لدفع رسوم الغاز لمرحلة " الكشف " التالية، والأخرى هي التغيير.
في مرحلة "الكشف"، يمكنك أن ترى أن هناك مدخلين لـ utxo، يتوافقان مع أول مخرجين من مرحلة الالتزام السابقة. ستنتج هذه المعاملة أولاً OP_RETURN، حيث سيتم حفظ تجزئة الحالة الأولية لـ CAT20. سيتم بعد ذلك إخراج Minter، والذي سيلعب دورًا مهمًا في عملية Mint اللاحقة ويستخدم للحفاظ على تغييرات الحالة في عملية Mint.

بالنظر إلى عملية النشر بأكملها، يتبع "commit " و" reveal " خطوتين الإرسال والكشف الشائع الاستخدام في blockchain، وهما مشروع نشر شائع نسبيًا. بهذه الطريقة، لن يتم الكشف عن بعض بيانات المشروع إلا خلال مرحلة "الكشف".
Mint
دعونا أولاً نلقي نظرة على Mint Token هذه هي الطريقة التي تبدو بها المعاملة يحب.

كما ترون في الصورة أعلاه، تتميز عملية Mint بالخصائص التالية.
مدخل النعناع هو أداة سك العملة، والتي يتم إنشاؤها في البداية أثناء النشر.
تحتوي كل دار سك النقود على أداة سك واحدة فقط كمدخل، وأي عدد من آلات السك كمخرج (مشكلة قليلاً) p >
كل قطعة نعناع لها رمز واحد فقط (مشكلة صغيرة)
ترتيب المخرجات مطلوب، ويجب أن يتبع المعد رمز مميز
I تعرف على Mint في الواقع، يمكننا أن نجد بعض المواقف الخاصة التي ستجعل عملية Mint بأكملها مثيرة للاهتمام.
على سبيل المثال، minter هو ناتج معاملة النعناع ويمكن أن يكون 1 أو متعددًا أو حتى 0. إذا تم ضبط Mint على 1 في كل مرة، فإن عدد آلات سك العملة التي يمكن استخدامها في الشبكة بأكملها سيبقى دون تغيير (1)، الأمر الذي سيجعل Mint مزدحمة، ويجب على الجميع الاستيلاء على أداة سك النقود هذه لتجنب ذلك في هذه الحالة، من الضروري ضبط عدد آلات سك العملة التي يتم إخراجها في كل مرة على أكبر من 1، بحيث يمكن استخدام المزيد والمزيد من آلات سك العملة بعد عملية سك العملة.
ومع ذلك، فإن كل مخرجات أداة سك النقود الإضافية تعني أنك بحاجة إلى دفع utxo إضافي لأسباب اقتصادية، سيكون عدد أكبر من الأشخاص سعداء بضبط أداة سك النقود على 0 سيؤدي حتمًا إلى أن تصبح أداة سك العملة انكماشية، الأمر الذي يتطلب من بعض الأشخاص المساهمة والدفع طوعًا مقابل أداة سك العملة الإضافية.
في الإصدار V2، الافتراضي هو إنشاء جهازي Minter، وستكون حالة Minter الاثنين متشابهة قدر الإمكان.
إنشاء المعاملة
ربما اكتشف بعض الأصدقاء مشكلة، وهذا هو سبب احتمال حدوثها إنشاء المعاملات باستخدام utxo لminter؟ لفهم هذه المشكلة، تحتاج إلى تحليل الكود المصدري لـ "العقد".
1. الكشف عن utxo
أولاً وقبل كل شيء، نحن ناقش عملية الكشف عند تحليل المعاملة في، وجدنا أنه استخدم التزام الإخراج للمعاملة السابقة كمدخل. لماذا يمكننا أن نأخذ utxo ليس عنواننا ونبني مدخلات المعاملة؟
وفقًا للحس السليم، يتوافق المفتاح الخاص مع المفتاح العام، والمفتاح العام يستمد العنوان. عند التحقق من صحة إدخال utxo، يتم تحديده عادةً من خلال مقارنة ما إذا كان التوقيع متوافقًا مع المعاملة الأصلية بعد فك تشفيره باستخدام المفتاح العام. هذا الجزء من المنطق مكتوب بخط Bitcoin. حتى نتمكن من إعادة كتابة منطق البرنامج النصي بذكاء، تنتمي أزواج المفاتيح العامة والخاصة المكتوبة في البرنامج النصي إلى عنواننا الخاص، حتى نتمكن من التحكم في عنوانين مختلفين.
بالنظر إلى الكود المصدري يمكننا معرفة ما حدث:

هناك مشكلة أخرى هنا، وهي أن المفتاح الخاص يتوافق مع مفتاح عام، فلماذا يختلف عنوان الالتزام الذي تم إنشاؤه عن عنواننا؟ يمكنك رؤيتها من الكود المصدري هنا
p>
بعبارة أخرى، سيقوم مفتاحنا الخاص بضبط المفتاح العام وفقًا لـ ISSUE_PUBKEY، والذي يعد أيضًا أحد ميزات عنوان P2TR.
2. يتم استخدام utxo مختلف كمدخل، ولكن مفتاح التشفير هو نفسه في الواقع، وهو المفتاح الخاص للناشر. ولكن في مرحلة التعدين، يمكن للجميع استخدام هذه utxo كمدخل، كيف يتم ذلك؟
أعتقد أن هذا الجزء هو قدرة OP_CAT المذكورة سابقًا، أي قدرة كل عامل على التنقيب هو عقد ذكي. ومع ذلك، لم يتم الإعلان عن الكود المصدري لهذا الجزء في الوقت الحالي، والتنفيذ المحدد غير معروف بعد.
حالة المعاملة (V2)
في minter، يتم الاحتفاظ بالحالة أيضًا. توجد هذه الحالة في مكانين: أحدهما في OP_RETURN لمخرجات المعاملة، والآخر يتم تخزينه في العقد الذكي، وهو Minter والرمز المميز المذكور أعلاه.
ما يتم تخزينه في OP_RETURN هو تجزئة حالة إخراج المعاملة الحالية، وسيتم تخزين أوقات Mint المتبقية للرمز المميز في العقد. بعد كل عملية سك العملة، سيكون عدد سك النعناع الذي تم إنشاؤه حديثًا مساويًا للعدد المتبقي من سك العملة مقسومًا على اثنين. ممثلة برسم تخطيطي:

< p style="text-align: left;">عند اكتمال الكتابة النهائية، يكون العدد المتبقي لجميع Minter هو 0.
بالعودة إلى الصورة الأصلية، بالإضافة إلى كون Minter عقدًا ذكيًا، فإن الرمز المميز الذي تم إنشاؤه هو أيضًا عقد ذكي، وهو CAT20. يحتوي CAT20 على حالتين أساسيتين: الكمية وعنوان مالك الرمز المميز. يمكنك أن ترى أنه على عكس BRC20 أو النقش السابق، فإن CAT20 الخاص بك ليس موجودًا على UTXO لعنوانك.
التحويل
عند النقل، يتم إنشاء رموز الإدخال والإخراج الخاصة بالمعاملة يجب أن تكون متسقة. بالطبع، يمكن أن يكون هناك العديد من الرموز المميزة في نفس المعاملة، طالما أن أرقام الإدخال والإخراج للرموز المميزة المختلفة متسقة.
حرق
إذا كنت تريد نسخ الرمز المميز، فأنت تحتاج فقط إلى نقل الرمز المميز إلى عادي فقط العنوان.
الملخص
كما ترى، يتم إنشاء جميع العمليات بواسطة المستخدمين أنفسهم المرونة عالية جدًا، لذا يلزم إجراء الكثير من منطق التحقق في جزء العقد. بعض الثغرات الأمنية التي تم الكشف عنها حتى الآن ترجع أيضًا إلى الإهمال في منطق التحقق.
مثل هذا التصميم يمكن أن يكون له بعض الفوائد:
إذا كنت تريد العثور على حالة الاحتفاظ بجميع الرموز المميزة، فأنت تحتاج فقط إلى التحقق من utxo للرمز المميز، وليست هناك حاجة لمواصلة البحث.
إذا كنت تريد التحقق من الوضع الحالي للنعناع، فيمكنك البحث عن المعاملات مع cat في البيانات الموجودة في OP_RETURN.