مقدمة

لطالما كان إصدار الأصول على أساس BTC موضوعًا ساخنًا. من أقدم العملات الملونة في عام 2011 إلى بروتوكول Ordinal الشهير مؤخرًا، تمكن مجتمع BTC باستمرار من التوصل إلى لاعبين جدد وإجماع، لكن القليل منهم ظل عالقًا. ومع ذلك، كشفت شركة Lightning Labs عن خطط طموحة لتطوير عملات مستقرة استنادًا إلى أصول Taproot أعلنت Tether أيضًا أنها ستستخدم بروتوكول RGB لسك USDT على الطبقة الأولى من بيتكوين.

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

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

عملات ملونة

تم توضيح مفهوم العملات الملونة لأول مرة من قبل يوني آسيا، الذي يشغل الآن منصب الرئيس التنفيذي لشركة eToro، في مقالته الأساسية «bitcoin 2.X (المعروف أيضًا باسم البيتكوين الملون)» في 27 مارس 2012. افترض المقال أن التكنولوجيا الأساسية لبيتكوين كانت أساسية وخالية من العيوب مثل HTTP للإنترنت. لذلك، تم تصميم بروتوكول الرمز المميز للعملات الملونة فوق BTC.

تصورت Yoni Assia إنشاء اقتصادات BTC 2.0 من خلال هذا الابتكار، مما يمكّن أي مجتمع من توليد عملات متعددة بهذه الطريقة. كان استخدام تقنية بيتكوين الأساسية لتسوية المعاملات ومنع الإنفاق المزدوج، في ذلك الوقت، فكرة رائدة.

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

في 3 يوليو 2014، خطت ChromaWay خطوة كبيرة من خلال تطوير البروتوكول المحسن القائم على طلب العملات الملونة (EPOBC)، والذي سهّل إلى حد كبير عملية إنشاء العملات الملونة للمطورين. كان هذا هو البروتوكول الافتتاحي لاستخدام وظيفة OP_RETURN الخاصة بـ Bitcoin Script.

بدت النتيجة كما يلي:

مثل هذا التنفيذ موجز للغاية، ولكنه يجلب أيضًا العديد من المشكلات:

1. مسألة قابلية الاستبدال والحد الأدنى لقيمة الربط من خلال ربط 1000 سات في معاملة التكوين لعملة ملونة، يصبح الحد الأدنى لوحدة تلك العملة الملونة مقعدًا واحدًا. هذا يعني أنه يمكن نظريًا تقسيم الأصل أو الرمز المميز إلى 1000 وحدة كحد أقصى (ولكن من الناحية العملية يكون أقل لمنع هجمات الغبار). على سبيل المثال، تم تعيين الحد الأدنى لقيمة ساتوشي مرة واحدة عند 546 SAT، وبالنسبة إلى Ordinals، فهي أعلى من ذلك).
2. تحديات التحقق من الصحة من أجل تحديد أصالة وملكية العملة الملونة، يجب تتبع سجل معاملاتها والتحقق من صحتها من معاملة التكوين إلى UTXO الحالية. لذلك، يجب تطوير محافظ مخصصة وعقد كاملة وحتى ماسح ضوئي.
3. مخاطر الرقابة المحتملة على عمال المناجم تتميز ColoredTransaction بخصائص مميزة، مثل كتابة البيانات الوصفية في المخرجات، وهذا يجلب إمكانية الرقابة على عمال المناجم.

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

أول عرض أولي للعملة المشفرة: Mastercoin

تم اقتراح مفهوم Mastercoin في البداية من قبل J.R. Willett. وفي عام 2012، نشر ورقة بيضاء بعنوان «الورقة البيضاء الثانية للبيتكوين»، والتي حددت فكرة إنشاء أصول أو رموز جديدة بالإضافة إلى بلوكتشين بيتكوين الحالية. أصبح هذا المفهوم معروفًا في النهاية باسم «MasterCoin»، والذي تمت إعادة تسميته لاحقًا إلى Omni Layer.

في عام 2013، أجرى مشروع Mastercoin إصدارًا مبكرًا لما نشير إليه اليوم باسم ICO (عرض العملة الأولي)، حيث نجح في جمع ملايين الدولارات. يعتبر هذا أول ICO في التاريخ. أحد أبرز تطبيقات Mastercoin هو Tether (USDT)، وهي عملة مستقرة معروفة بضمانات ورقية، والتي تم إصدارها في البداية على طبقة Omni Layer.

في الواقع، سبقت فكرة Mastercoin العملات الملونة. السبب الذي يجعلنا نناقشه ثانيًا هو أنه مقارنة بالعملات الملونة، تعد MasterCoin حلاً أكثر شمولاً نسبيًا. أنشأت MasterCoin طبقة عقدة كاملة، تقدم وظائف أكثر تعقيدًا مثل العقود الذكية. في المقابل، تعتبر العملات الملونة أبسط وأكثر مباشرة، حيث تركز بشكل أساسي على «تلوين» أو وضع علامة على Bitcoin UTXOS لتمثيل الأصول الأخرى.

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

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

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

باختصار:

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

وفقًا للمعلومات التي قدمتها Omni Bolt: تقترح Omni Layer بروتوكول أصول UBA (الأصول المستندة إلى UTXO) جديدًا إلى Tether، والذي سيستخدم ترقية Taproot. سيقوم هذا البروتوكول بتضمين معلومات الأصول في tapleaf، مما يتيح وظائف مثل المدفوعات المشروطة. في الوقت نفسه، تعمل OmniBolt على دمج Stark في البنية التحتية لشبكة Lightning Network الخاصة بـ Omni Layer.

مفهوم التحقق من جانب العميل

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

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

لمتابعة تفكير بيتر تود، نحتاج أولاً إلى فهم المشكلة التي تحلها بيتكوين فعليًا. وفقًا لبيتر تود، تعالج بيتكوين ثلاث مشكلات:

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

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

إذن كيف يتحقق التحقق من جانب العميل بشكل فعال من المعاملات؟

أولاً، دعونا نلقي نظرة على ما يجب التحقق منه:

1. الحالة (التحقق من منطق المعاملة)
2. تحقق من أن المدخلات (TxIN) صالحة لمنع الإنفاق المزدوج.

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

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

هيكل شجرة الالتزام الذي اقترحه بيتر تود هو كما يلي:

CTXin - > CTxOut - > <merkle path> < مسار ميركل > - > المعاملة - > < مسار ميركل > <merkle path> - > CTXin

ولكن كيف يمكننا تخزين شجرة الالتزام هذه على بلوكتشين؟ هذا هو المكان الذي يمكننا فيه تقديم مفهوم «الختم أحادي الاستخدام».

ختم للاستخدام الفردي

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

بالنسبة لبروتوكول SEAL، هناك ثلاثة عناصر وإجراءان.

العناصر الأساسية:

1. l: ختم
2. m: الرسالة، وهي المعلومات أو المعاملة
3. w: شاهد أو شخص ما أو شيء يمكنه التحقق من الختم

العمليات الأساسية: هناك إجراءان أساسيان:

1. إغلاق (l، m) → w: أغلق الختم l على الرسالة m، مع تقديم شاهد w.
2. تحقق من (l، w، m) → bool: تحقق مما إذا كان الختم l قد تم إغلاقه على الرسالة m.

يعني أمان تنفيذ الختم أحادي الاستخدام أن المهاجم لا يمكنه العثور على رسالتين مختلفتين m1 و m2 بحيث تعود وظيفة Verify صحيحة لنفس الختم.

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

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

لتوضيح الأمر بشكل أكثر بساطة:

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

تلخيصًا لما سبق، تتميز الأصول التي تستخدم التحقق من جانب العميل بالخصائص التالية:

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

بالنسبة لأولئك الذين يستخدمون الأصول مع التحقق من جانب العميل، هناك نقطة إضافية يجب ملاحظتها:

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

RGB، رائد CSV

تم اقتراح مفهوم RGB من قبل جياكومو زوكو، وهو شخصية معروفة في المجتمع، بعد عام 2015. كانت هذه هي الفترة التي كانت فيها إيثريوم في ارتفاع، وانتشرت عمليات الطرح الأولي للعملات الرقمية (ICOs)، وبُذلت العديد من المحاولات لإنشاء مشاريع تتجاوز بيتكوين، مثل Mastercoin والعملات الملونة.

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

بصرف النظر عن الخصائص المذكورة سابقًا للأصول التي تستخدم التحقق من جانب العميل، فإن الاختلاف الرئيسي مع RGB وبروتوكولات الأصول السابقة هو إضافة VM للتنفيذ (Virtual Machine) لتنفيذ عقد Turing بالكامل. لضمان أمان بيانات العقد، تم تصميم المخطط والواجهة. يعلن المخطط، على غرار مخطط إيثريوم، عن محتوى ووظائف العقد، في حين أن الواجهة مسؤولة عن تنفيذ وظائف محددة، على غرار الواجهات في لغات البرمجة.

مخططات هذه العقود مسؤولة عن تقييد السلوكيات التي تتجاوز التوقعات أثناء تنفيذ VM. على سبيل المثال، RGB20 و RGB21 مسؤولان على التوالي عن فرض قيود معينة على الرموز المميزة القابلة للاستبدال وغير القابلة للاستبدال أثناء المعاملات.

آلية الالتزام المستخدمة في RGB، بيدرسن هاش

تكمن ميزتها في قدرتها على الالتزام بقيمة دون الكشف عنها. استخدام Pedersen Hash لبناء شجرة Merkle يعني أنه يمكنك إنشاء شجرة Merkle لحماية الخصوصية يمكنها إخفاء قيمها. هذه البنية مفيدة في بعض بروتوكولات الحفاظ على الخصوصية، مثل بعض مشاريع العملات المشفرة المجهولة. ومع ذلك، قد لا تكون مناسبة لأصول CSV، والتي سيتم ذكرها لاحقًا بالمقارنة مع Taproot Assets.

تصميم الجهاز الافتراضي لبساطة RGB → AluVM

لم تهدف RGB فقط إلى تنفيذ بروتوكول الأصول الذي تم التحقق من صحته من جانب العميل ولكن أيضًا إلى التوسع في تنفيذ الجهاز الافتراضي الكامل لـ Turing وبرمجة العقود. في البداية، ادعت RGB أنها تستخدم لغة برمجة تسمى Simplicity، والتي تولد دليلًا على التنفيذ وتسمح بالتحقق الرسمي (لتجنب الأخطاء) من العقود المكتوبة فيها. ومع ذلك، لم يتم تطوير هذه اللغة كما هو مخطط له، مما أدى إلى مضاعفات أعاقت في النهاية بروتوكول RGB بأكمله. في النهاية، بدأت RGB في استخدام VM يسمى AluVM، تم تطويره بواسطة Maxim، بهدف تجنب أي سلوك غير محدد، على غرار Simplicity الأصلي. يُقال إن AluVM الجديد سيتم استبداله في المستقبل بلغة برمجة تسمى Contractum، مبتعدًا عن استخدامه الحالي لـ Rust.

اتجاه تحجيم طبقة RGB 2: شبكة البرق أو السلسلة الجانبية؟

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

RGB وشبكة البرق

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

يمكن لـ RGB إنشاء البنية التحتية لشبكة Lightning Network الخاصة بها من خلال تصميم تفاصيل عقد قناة الدفع المناسبة لـ RGB نفسها. ومع ذلك، فإن بناء مثل هذه البنية التحتية ليس بالأمر السهل بسبب التعقيد العالي لشبكة Lightning Network، لا سيما بالنظر إلى سنوات عمل Lightning Labs في هذا المجال وحصة LND السوقية التي تزيد عن 90٪.

السلسلة الجانبية الرئيسية من RGB

أصدرت LNP-BP، المشرف الحالي على بروتوكول RGB، اقتراحًا في يونيو 2023 من قبل Maxim لحل توسيع الأصول تم التحقق من صحته من جانب العميل يسمى Prime. في ذلك، انتقد ماكسيم حلول توسيع السلسلة الجانبية وشبكة Lightning Network الحالية لكونها معقدة للغاية في التطوير. وأعرب عن اعتقاده بأنه، بصرف النظر عن Prime، ستتطلب طرق التوسع الأخرى، بما في ذلك قنوات NUCLEUS متعددة العقد Lightning ومصانع قنوات Ark/Enigma، أكثر من عامين من التطوير. ومع ذلك، يمكن إكمال Prime في عام واحد فقط.

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

1. خدمة الختم الزمني: يمكن لهذه الخدمة إنهاء سلسلة من المعاملات في أقل من 10 ثوانٍ.
2. البراهين: يتم تخزينها في شكل أشجار ميركل الجزئية (PMTs) ويتم إنتاجها ونشرها جنبًا إلى جنب مع رؤوس الكتل.
3. الأختام ذات الاستخدام الفردي: هذا بروتوكول ختم تجريدي للاستخدام الفردي مصمم لمنع الإنفاق المزدوج. عند تنفيذه على Bitcoin، يمكن ربطه بـ UTXOS، على غرار تصميم RGB الحالي.
4. بروتوكول العقد الذكي: العقود المجزأة لـ RGB (والتي يمكن استبدالها)

من هذا المنطلق، يمكننا أن نرى أنه لمعالجة مشكلة أوقات تأكيد المعاملات في RGB، تستخدم Prime خدمة الختم الزمني لتأكيد المعاملات خارج السلسلة بسرعة وتعبئتها بمعرفات في كتل. في الوقت نفسه، يمكن دمج أدلة المعاملات على Prime بشكل أكبر من خلال PMTs ثم تثبيتها على BTC بطريقة تشبه نقطة التفتيش.

بروتوكول أصول CSV المستند إلى Taproot: أصول Taproot

Taproot Assets هو بروتوكول أصول CSV يعتمد على Taproot، وهو مصمم لإصدار الأصول على بلوكشين بيتكوين. يمكن تداول هذه الأصول على الفور وبأحجام كبيرة وبتكلفة منخفضة عبر شبكة Lightning Network. يتمثل جوهر Taproot Assets في استخدام أمان واستقرار Bitcoin جنبًا إلى جنب مع السرعة وقابلية التوسع والتكلفة المنخفضة لشبكة Lightning Network. تم تصميم البروتوكول وتطويره من قبل roasbeef، المدير التنفيذي للتكنولوجيا في Lightning Labs. من المحتمل أن يكون Roasbeef هو الشخص الوحيد على هذا الكوكب الذي قاد شخصيًا تطوير كل من عميل Bitcoin (BTCD) وعميل Lightning Network (LND)، مما يدل على فهم عميق لـ BTC.

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

هيكل ترميز أصول Taproot كما يلي:

بواسطة roasbeef، الرئيس التنفيذي للتكنولوجيا في مختبرات الإضاءة

أيضًا كبروتوكول أصول CSV، تتمتع Taproot Assets بتصميم أكثر إيجازًا مقارنة بـ RGB. يكمن الاختلاف الأكبر بين أصول Taproot و RGB من حيث قابلية تطوير التطبيق في VM للتنفيذ، وتستخدم Taproot Assets نفس TaprootScript VM باعتباره الإعداد الافتراضي الأصلي لـ BTC. في السنوات الأخيرة، استندت العديد من الأبحاث الخاصة بـ BTC في السنوات الأخيرة، الكثير من أبحاث البنية التحتية لـ BTC على TapScript، ولكن نظرًا للترقية البطيئة لـ BTC، لا يمكن تطبيقها في فترة زمنية قصيرة، لذلك يمكن التنبؤ بأن Taproot Assets ستكون ساحة اختبار لهذه الأفكار الجديدة في المستقبل.

الاختلافات بين أصول Taproot و RGB

1. التحقق من المعاملات وسهولة التعامل مع العقدة الخفيفة

تتمتع Taproot Assets، نظرًا لتنفيذ شجرة المجموع، بكفاءة تحقق وأمان عاليين. وهو يسمح بالتحقق من الدولة وإجراء المعاملات ببساطة عن طريق امتلاك دليل، دون الحاجة إلى اجتياز سجل المعاملات بأكمله. في المقابل، فإن استخدام RGB لالتزامات Pedersen يجعل من الصعب التحقق بشكل فعال من صحة المدخلات. ونتيجة لذلك، يتطلب RGB تتبع سجل معاملات المدخلات، والذي يمكن أن يصبح عبئًا كبيرًا مع تراكم المعاملات بمرور الوقت. كما أن تصميم شجرة مجموع Merkel يمكّن Taproot Assets من تسهيل التحقق من العقدة الخفيفة بسهولة، وهي ميزة لم تكن متوفرة سابقًا في بروتوكولات الأصول المبنية على بيتكوين.

2. VM للتنفيذ

تم تطوير Taproot Assets استجابةً لترقية Taproot لشبكة بيتكوين. وهو يستخدم TaprootScriptVM، وهو محرك تنفيذ البرنامج النصي الذي يأتي مع بيتكوين بعد ترقية Taproot. علاوة على ذلك، فإنه يستخدم vPSBT، وهو نوع من PSBT الخاص ببيتكوين، مما يشير إلى أنه بمجرد تطوير آلية قناة Taproot Assets Lightning، يمكنها على الفور إعادة استخدام جميع البنية التحتية الحالية لـ LND (Lightning Network Daemon)، بالإضافة إلى المنتجات السابقة من Lightning Labs (تمتلك LND حاليًا أكثر من 90٪ من حصة السوق في شبكة البرق). بالإضافة إلى ذلك، يعتمد اقتراح BitVM الشهير الأخير على TaprootScript، مما يعني نظريًا أن جميع هذه التحسينات يمكن أن تفيد في النهاية أصول Taproot.

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

3. العقود الذكية

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

من ناحية أخرى، تتميز Taproot Assets بتصميم أبسط، ولكنها تقوم حاليًا بتخزين أرصدة الأصول فقط ولا تتعامل مع الحالات الأكثر تعقيدًا، مما يجعل مناقشات العقود الذكية سابقة لأوانها. ومع ذلك، وفقًا لـ Lightning Labs، هناك خطط للتركيز على تصميم العقود الذكية لـ Taproot Assets العام المقبل.

4. مركز المزامنة

يشير المبدأ الأساسي المذكور سابقًا فيما يتعلق بالأصول التي تم التحقق منها من جانب العميل إلى أن الاحتفاظ بالإثبات لا يقل أهمية عن الاحتفاظ بالمفتاح الخاص. ومع ذلك، هناك خطر فقدان الإثبات نظرًا لأنه يتم الاحتفاظ به من جانب العميل. كيف يمكن معالجة ذلك؟ في Taproot Assets، يمكن تجنب هذه المشكلة من خلال استخدام «الكون». الكون عبارة عن شجرة Merkle متفرقة قابلة للتدقيق العام وتغطي أصلًا واحدًا أو أكثر. على عكس شجرة أصول Taproot القياسية، لا يتم استخدام الكون لحفظ أصول Taproot. وبدلاً من ذلك، فإنه يلتزم بمجموعة فرعية من سجل أصول واحد أو أكثر.

في نظام RGB، يتم تنفيذ هذا الدور بواسطة Storm، التي تقوم بمزامنة البيانات المقاومة خارج السلسلة من خلال شبكة نظير إلى نظير (p2p). ومع ذلك، نظرًا لأسباب تاريخية مرتبطة بفريق تطوير RGB، تستخدم هذه الفرق حاليًا تنسيقات إثبات غير متوافقة. أشار فريق النظام البيئي RGB، DIBA، إلى أنه سيطور «carbonado» لمعالجة هذه المشكلة، لكن تقدمه غير واضح.

5. التنفيذ الهندسي

تم اختبار جميع المكتبات التي تستخدمها Taproot Assets جيدًا، حيث تمتلك Lightning Labs عميل Bitcoin الخاص بها (BTCD) وعميل Lightning Network (LND) ومجموعة واسعة من تطبيقات مكتبة المحفظة. في المقابل، فإن معظم المكتبات المستخدمة لتطبيق RGB محددة ذاتيًا. من منظور معايير الصناعة، لا يزال تنفيذ RGB في المرحلة التجريبية.

نظرة سريعة على مستقبل توسيع BTC

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

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

عمليات حسابية أقل على السلسلة، والمزيد من التحقق على السلسلة

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

أين يتم التحقق؟ هذا أمر بالغ الأهمية.

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

من منظور عمليات التنفيذ القائمة على التحقق، لدينا ثلاثة اتجاهات للتوسع:

1- التحقق على السلسلة (OP-ZKP)

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

2. التحقق على الشبكة شبه المتصلة بالسلسلة (BitVM)

يضمن تصميم BitVM أنه غير مخصص لمنطق المعاملات العادي. أشار روبن لينوس أيضًا إلى أن مستقبل BitVM يكمن في إنشاء سوق مجاني عبر السلاسل لمختلف SideChains. يعتبر نهج BitVM شبه متصل بالسلسلة لأن معظم حسابات التحقق لن تحدث على السلسلة ولكن خارج السلسلة. السبب المهم للتصميم حول Taproot الخاص بـ Bitcoin هو استخدام TapScriptVM للتحقق الحسابي عند الضرورة، مع وراثة أمان Bitcoin نظريًا. تؤدي هذه العملية أيضًا إلى إنشاء سلسلة ثقة للتحقق، مثل الحاجة فقط إلى مدقق صادق واحد بين المدققين «n»، والمعروف باسم Optimitic Rollups.

تتكبد BitVM نفقات كبيرة على السلسلة، ولكن هل يمكنها استخدام براهين الاحتيال ZK لتحقيق مكاسب في الكفاءة؟ الإجابة هي لا، حيث يعتمد تنفيذ براهين الاحتيال في ZK على القدرة على إجراء التحقق من ZKP على السلسلة، مما يعيدنا إلى صعوبات نهج OP-ZKP.

3. التحقق خارج السلسلة (التحقق من جانب العميل، شبكة Lightning)

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

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

اتجاه تطور التوسع

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

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [mirror]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [Ben77]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.