مقدمة العملة

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

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

عملات ملونة

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

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

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

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

يظهر التنفيذ النهائي في الصورة التالية:

)

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

الرموز المتجانسة والحد الأدنى لقيمة الربط

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

مشكلات التحقق

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

المخاطر المحتملة لرقابة عمال المناجم

نظرًا للخصائص المميزة لـ ColoredTransaction، والتي تتضمن كتابة معلومات البيانات الوصفية في المخرجات، هناك إمكانية للرقابة على عمال المناجم.

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

أول عرض أولي للعملة الرقمية في صناعة العملات المشفرة: Mastercoin

تم اقتراح المفهوم الأولي لماستركوين من قبل جي آر ويليت. وفي عام ٢٠١٢، نشر ورقة بيضاء بعنوان «الورقة البيضاء الثانية لبيتكوين»، والتي وصفت مفهوم إنشاء أصول أو رموز جديدة على بلوكتشين الحالية لبيتكوين، والتي عُرفت لاحقًا باسم «MasterCoin». تم تغيير اسمها لاحقًا إلى Omni Layer.

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

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

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

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

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

باختصار:

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

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

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

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

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

باتباع أفكار بيتر تود، دعونا أولاً نفهم المشكلات التي قامت BTC (Bitcoin) بحلها بالفعل. من وجهة نظر بيتر تود، حلت BTC ثلاث مشاكل:

إثبات النشر

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

إجماع الطلبيات

في أنظمة الكمبيوتر، لا يوجد الوقت الفعلي الذي ندركه عادةً. في الأنظمة الموزعة، غالبًا ما يتم تمثيل الوقت بواسطة طوابع Lamport الزمنية، والتي لا تقيس وقتنا الفعلي ولكنها تطلب معاملاتنا.

التحقق من الصحة (اختياري)

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

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

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

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

• الحالة (التحقق من منطق المعاملة)

• صلاحية إدخال TxIN (لمنع الإنفاق المزدوج)

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

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

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

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

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

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

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

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

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

1. l：الختم، أي الختم
2. m：رسالة، رسالة
3. في：شاهد، شاهد

العمليات الأساسية: هناك عمليتان أساسيتان:

1. إغلاق (l، m) → w: في ختم إغلاق الجزء العلوي من الرسالة، قم بإنشاء شاهد في。
2. تحقق من (l، w، m) → كتاب: تحقق من صحة الخبر هل أنت في الأخبار؟ لم يتم إغلاقه.

يتم تنفيذ الختم أحادي الاستخدام من حيث الأمان. لا يمكن للمهاجم/m1andm2 العثور على رسالتين مختلفتين، ويتسبب في قيام وظيفة Verify بإرجاع نفس sealtrueof.

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

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

هل يمكن أن يكون الأمر أكثر بساطة؟

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

نعم، الأمر بهذه البساطة.

وخلاصة القول، تتميز الأصول التي تم التحقق منها من قبل العميل بالخصائص التالية:

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

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

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

الرائد في التحقق من جانب العميل (CSV): RGB

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

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

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

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

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

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

تصميم الجهاز الافتراضي لـ RGB: من البساطة إلى AluVM

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

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

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

RGB وشبكة البرق

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

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

السلسلة الجانبية لـ RGB: برايم

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

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

1. خدمة الطابع الزمني: تحديد تسلسل المعاملات في غضون 10 ثوانٍ.

2. الإثبات: يتم تخزينه بتنسيق PMT وإنتاجه ونشره مع رأس الكتلة.

3. الختم لمرة واحدة: بروتوكول ختم تجريدي لمرة واحدة، يضمن حماية الإنفاق المزدوج. إذا تم تنفيذه على Bitcoin، فيمكن ربطه بـ UTXO، على غرار تصميم RGB الحالي.

4. بروتوكول العقد الذكي: العقود القابلة للمشاركة - RGB (قابلة للاستبدال).

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

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

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

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

هيكل الترميز لـ Taproot Assets هو كما يلي: [ينتهي الوصف هنا، مما يشير إلى أن الجزء التالي من المقالة من المحتمل أن يتعمق في التفاصيل الفنية لهيكل ترميز Taproot Assets.]

الصورة عبر رئيس قسم التكنولوجيا في شركة Lightning Labs

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

أين تختلف أصول Taproot و RGB؟

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

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

1. VM للتنفيذ

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

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

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

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

وكما هو مفهوم من المبادئ الأساسية للتحقق من الأصول من جانب العميل، فإن الاحتفاظ بالإثبات لا يقل أهمية عن الاحتفاظ بالمفتاح الخاص. ولكن ماذا لو فُقد الدليل من جانب عميل المستخدم؟ في أصول Taproot، يمكن معالجة هذه المشكلة من خلال «الكون». The Universe عبارة عن شجرة Merkle متفرقة قابلة للتدقيق العام، وتغطي أصلًا واحدًا أو أكثر. على عكس أشجار أصول Taproot التقليدية، لا يستضيف الكون أصول Taproot. وبدلاً من ذلك، فإنه يلتزم بمجموعة فرعية من سجل أصول واحد أو أكثر. في RGB، تلعب Storm هذا الدور، حيث تقوم بمزامنة البيانات المقاومة خارج السلسلة عبر P2P. ومع ذلك، نظرًا لأسباب تاريخية لفرق تطوير RGB، فإن تنسيقات الإثبات هذه غير متوافقة حاليًا. يُقال إن فريق النظام البيئي في RGB، DIBA، يقوم بتطوير «carbonado» لحل هذه المشكلة، على الرغم من أن التقدم غير واضح.

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

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

مناقشة موجزة حول مستقبل توسيع BTC

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

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

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

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

أين يحدث التحقق؟ هذا مهم

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

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

1. 1. التحقق من صحة السلسلة (OP-ZKP)
2. إذا تم تنفيذ OP-ZKP مباشرةً في TaprootScriptVM، فهذا يعني دمج قدرات التحقق من ZKP في BTC نفسها، إلى جانب بعض تصميمات العهد لبروتوكولات التسوية، وإنشاء خطة توسيع Zk-Rolup التي ترث أمان BTC. ومع ذلك، على عكس نشر عقد التحقق على إيثريوم، فإن عملية الترقية البطيئة لبيتكوين، إلى جانب مثل هذا الرمز الاختياري المتخصص والذي قد يحتاج إلى ترقية، تجعل الأمر صعبًا.
4. 2. التحقق شبه على السلسلة (BitVM)
5. لا يهدف تصميم BitVM إلى خدمة منطق المعاملات العادي. أشار روبن لينوس أيضًا إلى أن مستقبل BitVM يكمن في إنشاء سوق مجاني عبر السلاسل لمختلف SideChains. يعتبر نهج BitVM شبه متصل بالسلسلة لأن معظم حسابات التحقق هذه لا تحدث على السلسلة، بل خارج السلسلة. ومع ذلك، فإن أحد الأسباب المهمة للتصميم حول Taproot الخاص بـ BTC هو استخدام TapscriptVM للتحقق الحسابي عند الضرورة، مع وراثة أمان BTC نظريًا. تؤدي هذه العملية أيضًا إلى إنشاء سلسلة ثقة للتحقق. على سبيل المثال، يكفي أن يكون أحد المدققين «n» صادقًا، على غرار التجميعات المتفائلة.
6. تكاليف BitVM على السلسلة مرتفعة، ولكن هل يمكنها استخدام براهين الاحتيال ZK لتحسين الكفاءة؟ الإجابة هي لا، لأن تنفيذ براهين الاحتيال في ZK يعتمد على القدرة على إجراء التحقق من صحة ZKP على السلسلة، مما يعيدنا إلى معضلة مخطط OP-ZKP.
8. 3. التحقق من الصحة خارج السلسلة (التحقق من جانب العميل، شبكة Lightning)
9. مع إجراء التحقق خارج السلسلة تمامًا، نعود إلى بروتوكولات أصول CSV التي تمت مناقشتها سابقًا وشبكة Lightning Network. في المناقشات السابقة، لوحظ أنه في تصميم CSV، لا يمكننا منع التلاعب التواطئي تمامًا. ما يمكننا القيام به هو استخدام التشفير وتصميم البروتوكول للحفاظ على ضرر التواطؤ الضار ضمن نطاق يمكن التحكم فيه، مما يجعل مثل هذا السلوك غير مربح.
10. إن إيجابيات وسلبيات التحقق خارج السلسلة واضحة. الميزة هي الحد الأدنى من استخدام الموارد على السلسلة، مع إمكانات هائلة للتوسع. الجانب السلبي هو أنه يكاد يكون من المستحيل الاستفادة الكاملة من أمان BTC، مما يحد بشكل كبير من أنواع وأساليب المعاملات خارج السلسلة. علاوة على ذلك، فإن التحقق خارج السلسلة يعني أيضًا أن البيانات يتم الاحتفاظ بها خارج السلسلة، ويديرها المستخدمون، الأمر الذي يتطلب متطلبات أعلى لأمان بيئة تنفيذ البرامج واستقرار البرنامج.

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

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

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

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