مناقشة المبادئ والتفاصيل الفنية لبروتوكول النقش الترتيبي

المؤلف: CaptainZ، باحث سابق في GametaverseDAO المصدر: X، @hiCaptainZ

عندما كنت أدرس بيئة BTC ومشاريع التسجيل المختلفة في الأسبوعين الماضيين، وجدت أن هناك عددًا قليلاً جدًا من المقالات التي يمكنها تقديم المبادئ والتفاصيل الفنية بوضوح: على سبيل المثال، عندما يتم صب النقش، كيف يتم بدء المعاملة، وكيف يتم تتبع الساتس في UTXO، وأين يتم وضع المحتوى المحفور في البرنامج النصي، ولماذا يتطلب BRC20 عمليتين عند تحويل الأموال؟ أجد أنه بدون فهم هذه التفاصيل التقنية، من الصعب فهم الاختلافات بين البروتوكولات المختلفة مثل BRC20، BRC420، atomicals، Stamps، وRunes. ستتناول هذه المقالة المعرفة الأساسية لـ BTC blockchain وتحاول الإجابة على ما ورد أعلاه أسئلة.

بنية كتلة BTC

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

p>

استخدمنا برنامج Excel لإنشاء جدول لشرح كيفية عمل blockchain. يمثل ملف Excel blockchain، حيث يمثل كل جدول منفصل كتلة. الكتل مرتبة ترتيبًا زمنيًا من 560331، 560332. إلى الأحدث 560336. 560336 سوف يقوم بحزم أحدث المعاملات في الكتلة. الجزء الرئيسي من الكتلة هو طريقة المحاسبة ذات القيد المزدوج الأكثر شيوعًا في مجال المحاسبة، حيث يتم تسجيل العنوان على جانب واحد كمدينة (مدين)، وهو مدخلات من، ويتم تسجيل العنوان على الجانب الآخر كدائن ( الائتمان)، وهو مخرجات ل. تتوافق القيمة مع مبلغ BTC للعنوان المقابل. سيكون عدد عملات المدخلات أكبر من عدد عملات المخرجات، والفرق هو رسوم النقل على مستوى المستخدم ورسوم المناولة التي يحصل عليها عمال المناجم (المحاسبون). سيحصل رأس الكتلة على ارتفاع الكتلة السابقة، وقيمة التجزئة للكتلة السابقة، ووقت الإنشاء (الطابع الزمني) لهذه الكتلة، ورقم عشوائي. إذن، كتقنية محاسبة لامركزية، من الذي سيحصل على الحقوق المحاسبية للكتلة التالية؟ ويعتمد على هذا الرقم العشوائي وقيمة التجزئة المقابلة له. يقوم القائمون بالتعدين الذين يتمتعون بقدرة حاسوبية بإجراء حساب تجزئة على الرقم العشوائي للكتلة الحالية، ويتمتع المُعدن الذي يحصل أولاً على قيمة التجزئة التي تستوفي الشروط بالحقوق المحاسبية للكتلة التالية ويفوز بمكافأة الكتلة ورسوم التحويل. وأخيرًا، هناك منطقة البرنامج النصي، والتي يمكن استخدامها لإنشاء بعض التطبيقات الموسعة، على سبيل المثال، يمكن استخدام البرنامج النصي op_return كعمود ملحق. تجدر الإشارة إلى أنه في الكتلة الفعلية، يتم إرفاق منطقة البرنامج النصي بمعلومات الإدخال والإخراج، وليست منطقة منفصلة أخرى. على سبيل المثال، البرنامج النصي المرفق بالمدخل هو برنامج نصي لإلغاء القفل (ScriptSig)، والذي يتطلب عنوان المحفظة لترخيص توقيع المفتاح الخاص للسماح بالنقل، في حين أن البرنامج النصي المرفق بالمخرج هو برنامج نصي للقفل (ScriptPubKey)، والذي يستخدم لـ قم بتعيين شروط إلغاء القفل لاستلام BTC (الشرط عمومًا هو "لا يمكن استهلاكه إلا لأولئك الذين لديهم المفتاح الخاص المقابل").

p>

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

SegWit وTaproot#

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

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

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

p>

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

تم تنفيذ Taproot في نوفمبر 2021 ويتكون من 3 مقترحات مختلفة لتحسين Bitcoin (BIPs)، بما في ذلك: Taproot وTapscript ونظام التوقيع الرقمي الجديد المسمى "Schnorr". إمضاء". تم تصميم Taproot لجلب العديد من الفوائد لمستخدمي Bitcoin، مثل زيادة خصوصية المعاملات وخفض رسوم المعاملات. كما سيسمح للبيتكوين بإجراء معاملات أكثر تعقيدًا، وبالتالي توسيع سيناريوهات التطبيق (تمت إضافة بعض أكواد التشغيل الجديدة).

تعد هذه التحديثات عامل تمكين رئيسي لـ Ordinals NFT، الذي يخزن بيانات NFT في برنامج نصي للإنفاق في مسار البرنامج النصي Taproot (مساحة بيانات الشاهد). تعمل هذه الترقية على تسهيل هيكلة بيانات الشهود العشوائية وتخزينها، مما يضع الأساس لمعيار "ord". نظرًا لتخفيف متطلبات البيانات، فمن المفترض أن المعاملة يمكن أن تملأ كتلة كاملة ببيانات المعاملة والشاهد - حيث تصل إلى حد حجم الكتلة البالغ 4 ميجابايت (مساحة بيانات الشاهد) - مما يؤدي إلى توسيع أنواع الوسائط التي يمكن وضعها على السلسلة بشكل كبير. .

قد يتساءل البعض، نظرًا لأنه يتم وضع بعض السلاسل في البرنامج النصي، فهل لا توجد قيود على هذه السلاسل؟ ماذا لو تم تنفيذ هذه البرامج النصية بالفعل؟ إذا قمت بوضع المحتوى بشكل عرضي، فهل سيكون هناك رمز خطأ يرفض إنتاج كتلة؟ يؤدي هذا إلى إظهار تعليمات OP_FALSE. يضمن OP_FALSE (يُمثل أيضًا بـ "0" في Bitcoin Script) عدم دخول مسار التنفيذ في لغة البرمجة النصية إلى فرع OP_IF مطلقًا ويظل غير مُنفذ. يعمل كعنصر نائب أو لا توجد عملية (No Operation) في البرنامج النصي، على غرار "التعليق" في لغة عالية المستوى، لضمان عدم تنفيذ التعليمات البرمجية اللاحقة.

p>

نموذج نقل UTXO

ما ورد أعلاه هو المبادئ الأساسية لدراسة BTC من منظور بنية البيانات الحاسوبية، دعونا نناقش نموذج UTXO من منظور النموذج المالي.

UTXO هو اختصار لمخرجات المعاملات غير المنفقة. الترجمة الصينية هي "مخرجات المعاملات غير المنفقة". يمكن فهمها في الواقع على أنها مخرجات المعاملات غير المنفقة المتبقية أثناء عملية النقل . أموال. فلماذا تستخدم Bitcoin مثل هذا المفهوم؟ يبدأ ذلك بنموذج معاملة الحساب ونموذج رصيد الحساب لطريقة المحاسبة.

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

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

المعاملة 1 المستخدم أ إلى المستخدم "ب" ينقل 100 يوان

المعاملة 2 ينقل المستخدم "أ" 900 يوان (UTXO) إلى المستخدم "أ" بنفسه

على الرغم من أن المعاملة 2 هنا هي معاملة، إلا أنها تعمل بمثابة رصيد الحساب، مما يشير إلى أنه بعد إكمال تحويل 100 يوان، لا يزال هناك 900 يوان متبقية في حساب A.

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

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

يقوم Xiao Ming بتحويل عملة بيتكوين واحدة إلى Xiao Gang. العملية برمتها هي مثل هذا. يحتاج Xiao Ming إلى جمع ما يكفي من المدخلات. على سبيل المثال، في المعاملة السابقة المقابلة لعنوان Xiao Ming، وجد UTXO بقيمة اسمية تبلغ 0.9، وهو ما لا يكفي لـ 1 Bitcoin. ولحسن الحظ، هناك عدة يُسمح بالمدخلات في المعاملة، لذلك وجد Xiao Ming UTXO آخر بقيمة اسمية تبلغ 0.2، لذلك سيكون هناك مدخلان في معاملة النقل هذه. سيكون هناك أيضًا مخرجان في نفس الوقت، أحدهما يشير إلى عنوان Xiaogang، بقيمة اسمية تبلغ 1 بيتكوين. ويشير الآخر إلى عنوان شياو مينغ الخاص، بقيمة اسمية تبلغ 0.1 بيتكوين، وهذا الناتج هو التغيير (يتم تجاهل الغاز في هذا المثال).

وبعبارة أخرى، هناك عملتان معدنيتان في جيب Xiao Ming، إحداهما بقيمة اسمية 0.9 والأخرى بقيمة اسمية 0.2. في هذا الوقت يحتاج Xiao Ming إلى دفع العملة بقيمة اسمية 1، لذلك يحتاج في الوقت نفسه إلى تسليم العملاتتين إلى Xiaogang، وبعد أن استلمهما Xiaogang، أعطى Xiaoming 0.1 مقابل التغيير. ولذلك، فإن جوهر هذا النموذج المحاسبي هو تجنب "حساب الأرصدة" من خلال إجراء "إحداث التغيير".

نظام فرز البروتوكول الترتيبي

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

نحن نعلم أن المبلغ الإجمالي لـ BTC هو 21 مليونًا، ويمكن تقسيم BTC الواحد إلى 100 مليون جزء على الأقل (السبت)، لذا فإن أصغر وحدة من BTC BTC هي Sat، سواء كانت BTC أو أصغر وحدة سات، كلها رموز متجانسة نموذجية FT. نحاول الآن تعيين ترتيبي لهذه الأقمار الصناعية.

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

ينص البروتوكول الترتيبي على ما يلي:

1. الترقيم: يتم ترقيم كل جلسة حسب الترتيب الذي تم تعدينها به

2. النقل: حسب الأول- قاعدة الدخول أولاً، الانتقال من الإدخال إلى إخراج المعاملة
   القاعدة الأولى بسيطة نسبيًا، فهي تحدد أنه لا يمكن إنشاء الرقم إلا من خلال معاملة قاعدة العملات في مكافأة التعدين. على سبيل المثال، إذا كانت مكافأة التعدين للكتلة الأولى هي 50 بيتكوين، فسيتم تخصيص الكتلة الأولى بعدد من النقاط في نطاق [0;1;2;...;4,999,999,999]؛ وستكون مكافأة الكتلة الثانية أيضًا عندما تكون 50 بيتكوين، ستخصص الكتلة الثانية مقاعد في نطاق [5,000,000,000;5,000,000,001;...;9,999,999,999].

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

أفترض أولاً أن الحد الأدنى لوحدة تقسيم BTC هو 1، وإجمالي 10 الكتل، مكافأة الكتلة لكل كتلة هي 10 بيتكوين، أي أن المبلغ الإجمالي هو 100. يمكننا تعيين رقم تسلسلي (0-99) مباشرة لهذه الـ 100 BTC. إذا لم يكن هناك تحويل، فإننا نعرف فقط أن أرقام 10 BTC في الكتلة الأولى هي (0-9)، وأرقام 10 BTC في الكتلة الثانية هي (10-19)، حتى المنطقة العاشرة رقم الكتلة 10 البيتكوين (90-99). نظرًا لعدم وجود تكلفة ولا مخرجات، يمكننا فقط تعيين نطاق رقمي لكل 10 بيتكوين.

لنفترض أنه تمت إضافة اثنين من النفقات (المخرجات) إلى الكتلة الثانية، أحدهما هو 3 BTC، والآخر هو "التغيير" 7 BTC، الموافق لشخص آخر حولت 3 بيتكوين وأعطتني 7 بيتكوين مقابل التغيير. في هذا الوقت، في قائمة المعاملات الخاصة بالكتلة، افترض أن 7 BTC الممنوحة لنفسه في التغيير تحتل المرتبة الأولى (الرقم المقابل هو 10-16)، و3 BTC الممنوحة للآخرين تحتل المرتبة الثانية (الرقم المقابل هو 17-). 19). وهذا يؤكد المجموعة المتسلسلة من الأقمار الصناعية الموجودة في UTXO معين من خلال نقل الإخراج.

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

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

p>

بعد أن يكون لدى sats رقم تسلسلي موحد، يمكن اعتباره للتسجيل. كما ذكرنا أعلاه، يمكنك تحميل الملفات من أي نوع بيانات في مساحة 4M من منطقة بيانات الشاهد، سواء كانت نصًا أو صورًا أو مقاطع فيديو. بعد التحميل، سيتم تحويل الملفات تلقائيًا إلى نظام سداسي عشري وتخزينها في منطقة البرنامج النصي الجذري . لذا، فإن 1 UTXO يتوافق مع منطقة نص Taproot واحدة، وسيحتوي UTXO 1 هذا على العديد من sats في نفس الوقت (الكل عبارة عن مجموعة من تسلسلات sats. ومن أجل منع هجمات الغبار، فإن عدد Bitcoins في UTXO واحد محدود إلى ما لا يقل عن 546 ساتوشي..). من أجل تسهيل التسجيل، ينص البروتوكول الترتيبي بشكل مصطنع على "استخدام رقم السبت الأول من مجموعة التسلسل هذه لتمثيل علاقة الربط" (الكلمات الأصلية للورقة البيضاء هي رقم السبت الأول للمخرج الأول)، على سبيل المثال، تحتوي على (17-19) يتم استخدام UTXO للساتس ذو الرقم 17 مباشرة لاستبدال هذه المجموعة وربط المحتوى المنقوش.

تحويل ونقل الأصول الترتيبية#

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

آلية Commit-Reveal في blockchain هي بروتوكول يستخدم لضمان المعالجة العادلة والشفافة للمعلومات. تُستخدم هذه الآلية غالبًا في السيناريوهات التي تتطلب تقديم معلومات مخفية (مثل التصويت أو العرض) ثم الكشف عنها في وقت لاحق. تنقسم آلية الالتزام والكشف إلى مرحلتين: مرحلة الالتزام ومرحلة الكشف.

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

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

كما قلنا من قبل، يجب أن يكون المحتوى المحفور مرتبطًا بمجموعة تسلسل sats الموجودة في UTXO. UTXO موجود في الكتلة عبارة عن مخرجات، لذا يجب إرفاقها بالبرنامج النصي لقفل المخرجات. ومع ذلك، تحتاج عقد BTC الكاملة إلى صيانة ونقل جميع مجموعات UTXO للشبكة بأكملها محليًا. تخيل أنه إذا تم تحميل 10000 ملف فيديو بحجم 4M مباشرة إلى 10000 نص قفل UTXO، فستحتاج جميع العقد الكاملة إلى مساحة تخزين عالية جدًا وسرعات شبكة فائقة السرعة، ويمكن القول أن السلسلة بأكملها ستنهار مباشرة. لذلك، الحل الوحيد هو وضع المحتوى في البرنامج النصي لإلغاء القفل الخاص بالإدخال، ثم جعل هذا المحتوى "يشير" إلى مخرج آخر.

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

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

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

p>

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

P2TR ومثال#

المناقشة الفنية أعلاه حول اختيار الممثلين لم تنته بعد، لأنه قد يكون لدى بعض الأشخاص فضول، كيف يمكن لمعاملة الكشف التحقق من معلومات التسجيل في معاملة الالتزام؟ لماذا نحتاج إلى عناوين AB الخاصة بنا لتحويل الأموال إلى بعضنا البعض عند تنظيم المعاملة؟ لم أر ضرورة لإعداد محفظتين عندما كنت أقوم بالنقش. نحن هنا بحاجة للحديث عن إحدى الترقيات الرئيسية لـ Taproot، P2TR.

P2TR (الدفع إلى Taproot) هو نوع جديد من معاملات Bitcoin تم تقديمه بواسطة ترقية Taproot. تتيح معاملات P2TR قدرًا أكبر من الخصوصية والمرونة من خلال السماح للمستخدمين بإنفاق Bitcoin باستخدام مفتاح عام واحد أو نصوص أكثر تعقيدًا مثل المحافظ متعددة التوقيع أو العقود الذكية. يتم تحقيق ذلك من خلال استخدام Merkleized Abstract Syntax Trees (MAST) وتوقيعات Schnorr، وهي تقنيات تتيح تشفير شروط الإنفاق المتعددة بكفاءة في معاملة واحدة.

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

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

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

• التحقق من المعاملة
  ثم يقوم القائمون بالتعدين والعقد بالتحقق من المعاملة عن طريق التحقق من توقيع شنور والبيانات المقدمة مع شروط الإنفاق. إذا تم استيفاء الشروط، تعتبر المعاملة صالحة ويمكن إنفاق عملات البيتكوين.

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

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

استخدم متصفح blockchain https://www.blockchain.com/  دعونا ندرس عملية صب الصورة الترتيبية NFT، بما في ذلك الكشف عن الالتزام السابق مرحلتان.

أولاً، نرى أن معرف التجزئة لمعاملة الالتزام هو (2ddf90ddf7c929c8038888fc2b7591fb999c3ba3c3c7b49d54d01f8db4af585c). تجدر الإشارة إلى أن مخرجات هذه المعاملة لا تحتوي على بيانات نقش (في الواقع هي قيمة التجزئة لملف الصورة المكون من 16 آلية)، ولا توجد معلومات نقش ذات صلة في صفحة الويب. عنوان الإخراج (bc1p4mtc....) هو في الواقع عنوان مؤقت تم إنشاؤه من خلال عملية "التبديل" (يمثل المفتاح العام لشرط فتح البرنامج النصي)، ويشارك مفتاحًا خاصًا مع العنوان الرئيسي للجذر (bc1pg2mp...) . ينتمي UTXO الثاني في هذه المعاملة إلى عملية "التغيير" التي تم إرجاعها. بهذه الطريقة، يتم تحقيق ربط محتوى النقش بالساتس الموجود في UTXO الأول.

p>

بعد ذلك، نتحقق من سجل معاملة الكشف، ومعرف التجزئة الخاص بها هو (e7454db518ca3910d2f17f41c7b215d6cba00f29bd186ae77d4fcd7f0ba7c0e1). هنا يمكننا رؤية معلومات نقش الترتيبيات. عنوان الإدخال لهذه المعاملة هو عنوان الإخراج المؤقت الذي تم إنشاؤه بواسطة المعاملة السابقة (bc1p4mtc....) يحتوي البرنامج النصي لإلغاء قفل الإدخال على الملف السداسي العشري للصورة الأصلية، والإخراج 0.00000546BTC (546 ساتوشي) هو إرسال NFT هذا إلى عنوان الجذر الرئيسي الخاص بك (bc1pg2mp...). استنادًا إلى مبدأ أول ما يدخل أولاً يخرج أولاً و"عدد الساتوشي الأول للمخرج الأول مرتبط"، على الرغم من أن عدد الساتس الموجود في اثنين من UTXOs قبل وبعد التغييرات، يظل رقم تسلسل السبت المنضم دون تغيير. لذا، يمكننا العثور على ساتوشي حيث يوجد هذا النقش (sat 1893640468329373).

(https://ordinals.com/sat/1893640468329373)

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

بروتوكول BRC20 والمفهرس

بالنسبة للبروتوكول الترتيبي، نقوم بنقش جزء من النص، وهو عبارة عن نص NFT (يتوافق مع Loot on Ethereum)، إذا تم نقش صورة، فهي صورة NFT (تتوافق مع PFP على Ethereum)، وإذا تم نقش مقطوعة موسيقية، فهي NFT صوتية. فماذا لو قمنا بنقش جزء من التعليمات البرمجية، وكان هذا الرمز عبارة عن جزء من التعليمات البرمجية "لإصدار رموز FT القابلة للاستبدال"؟

يقوم BRC20 بنشر الرمز المميز وسكه ونقله باستخدام البروتوكول الترتيبي لتعيين النقوش في تنسيق بيانات JSON. يحتوي JSON على بعض مقتطفات التعليمات البرمجية لوصف الرمز المميز. خصائص مختلفة مثل مثل العرض الخاص بها والحد الأقصى لوحدة سك العملة والرمز الفريد. لقد ذكرنا بالفعل في المقالة السابقة أن جوهر رمز BRC20 هو رمز SFT شبه قابل للاستبدال، أي أنه في بعض الحالات يمكن استخدامه كمعاملة NFT، وفي بعض الحالات يمكن استخدامه كمعاملة NFT. معاملة FT. هذا النوع من الاقتران كيف يتم التحكم في "المواقف المختلفة"؟ الجواب هو الفهارس.

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

لذلك يمكننا رؤية أشكال مختلفة من وجود الرمز المميز من منظور محاسب الحسابات: رموز بروتوكول BRC20 موجودة بالفعل في قاعدة بيانات ثلاثية. في الطبقة الأولى، يكون كاتب الحسابات هو عامل تعدين BTC، ونوع قاعدة البيانات هو "قاعدة بيانات متسلسلة"، وتكون BTC التي تم إنشاؤها هي أحد أصول FT. في الطبقة الثانية 2، يكون كاتب الحسابات هو المفهرس الترتيبي، ونوع قاعدة البيانات هو "قاعدة بيانات علائقية"، والأرقام التسلسلية التي تم إنشاؤها هي أصول NFT. في الطبقة الثالثة، يكون كاتب الحسابات هو مفهرس BRC20، ونوع قاعدة البيانات هو "قاعدة بيانات علائقية"، وأصول BRC20 التي تم إنشاؤها هي أصول FT. عندما نحسب BRC20 من حيث "القطع"، فإن وجهة النظر هي المفهرس الترتيبي (المسجل بواسطة هذا المفهرس)، وهو بطبيعة الحال NFT؛ عندما نفكر في BRC20 من حيث "القطع" المقسمة (خاصة بعد إعادة الشحن إلى التبادل المركزي)، منظور المحطة هو مفهرس BRC20 (المسجل بواسطة المفهرس أو خادم التبادل المركزي)، وهو بطبيعة الحال FT. من هذا يمكننا أن نستنتج أن وجود الرمز المميز شبه القابل للاستبدال SFT يرجع إلى اختلاف مستويات المحاسبين.

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

ومع ذلك، بعد أكثر من عشر سنوات من التطوير، لا تزال الصناعة تراكم الكثير من خبرة "اللامركزية". هل يمكن للمفهرس استخدام "قاعدة البيانات المتسلسلة" لاستبدال قاعدة بيانات علائقية؟ هل يمكن استخدام أدلة الاحتيال أو ZKP لضمان الأمن واللامركزية؟ هل سيمتد الطلب على DA في النظام البيئي للبيتكوين إلى DAs الأخرى، وبالتالي تعزيز ازدهار وتكامل النظم البيئية متعددة السلاسل؟ يبدو أنني أرى المزيد من الاحتمالات.

المواد المرجعية

https://www.aixinzhijie.com/books/261/ master_bitcoin/_book/

https://learnblockchain.cn/article/5717

https //zhuanlan.zhihu.com/p/361854961

https://www.odaily.news/post/5187233

https://learnblockchain.cn/article/5376

https://www.panewslab.com/zh/articledetails /1301r1ibp79c.html

https://docs.ordinals.com/inscriptions.html

https://thebitcoinmanual.com/articles/pay-to-taproot-p2tr/