في 1 فبراير، أطلق محفظة Binance Web3 رسميًا سوق النقش الخاص به، داعمًا بروتوكولات نقوش متنوعة مثل BRC20 و Ethscription. منذ عدة أيام، أعلنت OKX أيضًا عن دعمها لبروتوكولات النقوش مثل ARC20 و Runes و Doginals، مما أثار انتباه السوق بأسره نحو النقوش. خلال موجة النقش، تظهر العديد من القضايا الأمنية بشكل متكرر بسبب تعقيد وجدة بروتوكولات النقوش. هذا لا يهدد فقط أمان أصول المستخدمين، ولكن له أيضًا تأثير سلبي على التطوير الصحي للنظام البيئي للنقوش بأسره.

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

مقدمة عن inscriptions

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

الحالة الحالية لـ inscriptions

من الظهور الأولي لِـ Bitcoin Inscriptions مثل BRC-20، وصولاً إلى بيئة الـ Inscription الحالية، توجد بروتوكولات جديدة لا تنتهي ومشاريع جديدة تظهر تقريباً كل يوم. يمكن القول إن تطور الـ Inscription يتقدم بخطوات سريعة وبقفزات. كما انضمت سلاسل عامة مختلفة إلى منظومة الـ inscription، مثل بروتوكول Ethscription على السلسلة العامة لـ ETH، وبروتوكول ARC-20 على السلسلة العامة لـ BTC، وBSC-20 وغيرها من البروتوكولات على السلسلة العامة لـ BSC، وPRC- على سلسلة Polygon… إلخ. تم إنشاء هذه البروتوكولات جميعها بهدف نشر inscriptions على سلاسلها العامة. في المحتوى التالي، سنقدّم طرق تنفيذ واستخدامات بروتوكولات مختلفة.

شرح تفصيلي للـ inscription

دعنا نعرّف البروتوكولات التي تجذب حالياً اهتماماً كبيراً في السوق، ونقارن أوجه التشابه والاختلاف بين بروتوكولات inscriptions لسلاسل عامة مختلفة.

1. BRC-20

لشرح BRC-20 بوضوح، يجب أولاً تقديم UTXO وOrdinals.

تستخدم BTC نموذج UTXO، وتتم معاملة التحويلات بوحدات UTXO. إن UTXO اختصار لـ Unspent Transaction Output، أي مخرج معاملة غير مستهلك. نموذج UTXO يختلف عن نموذج الحساب (account model) للسلاسل العامة مثل Ethereum، إذ إنه يسجل أحداث المعاملات لكنه لا يسجل الحالة النهائية. لحساب كم عدد Bitcoins التي يمتلكها المستخدم، يجب عليك جمع كل UTXOs الخاصة بعنوانه، ونتيجة ذلك هي عدد العملات التي يحتفظ بها المستخدم.

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

ابتكر مؤسس BRC20 مفهوماً آخر استناداً إلى بروتوكول Ordinals. وبما أن بروتوكول Ordinals يمكنه إنشاء Bitcoin NFTs عبر إعطاء كل ساتوشي (Satoshi) "سمات" مختلفة، فإنه يمكنه أيضاً إنشاء Bitcoin FTs عبر إعطاء "صيغة" و"سمات" موحّدة؛ أي رموز متجانسة (homogeneous tokens).

يقوم BRC20 بكتابة بيانات نصية بصيغة JSON موحّدة في Satoshi عبر بروتوكول Ordinals. تُعد هذه البيانات النصية دفتر حسابات رموز BRC-20. وبناءً على هذه البيانات النصية، يمكن تحليل الاحتفاظ بالرموز والتحويلات، والتي تشمل بشكل أساسي المحتويات التالية:

{
“p”:”brc-20”,
“op”:”deploy”,
“tick”:”ordi”,
“max”:”21000000”,
“lim”:”1000”
}

{
“p”:”brc-20”,
“op”:”mint”,
“tick”:”ordi”,
“amt”:”1000”
}

{
“p”:”brc-20”,
“op”:”transfer”,
“tick”:”ordi”,
“amt”:”1000”,
}

إن ما سبق هي المعايير الثلاثة لـ BRC20. ومن بينها، الحقل op يَمثّل العملية التي يجب تنفيذها، وتشمل deploy (النشر/الإعداد)، وmint (الإصدار/السك)، وtransfer (التحويل). الحقل tick يَمثّل اسم الرمز الذي يحتاج إلى أن يتم تنفيذه. الحقل max يَمثّل إجمالي كمية الرموز المصدَرة، والحقل lim يَمثّل الحد الأقصى لعدد العملات (coins) التي يتم سكها لكل رمز، والحقل amt يَمثّل عدد الرموز التي تحتاج إلى تشغيل. في معيار التحويل (transfer)، توجد أيضاً حقول مثل "to"، لكن هذا غير ضروري. يتم إجراء التحويل عن طريق إرسال الـ inscription إلى عنوان الوجهة لتنفيذ تغيير الرصيد.

2. ARC-20

لا يزال ARC-20 هو بروتوكول inscription على السلسلة العامة لـ Bitcoin. وبمثل بروتوكول BRC-20، يتم تنفيذه عن طريق كتابة بيانات معيارية في UTXO، لكن الاختلاف هو أن بروتوكول ARC-20 لا يحتاج إلى تحديد ARC-20 داخل البيانات. بدلاً من ذلك، يتم تمثيل عدد رموز ARC-20 بواسطة sats (ساتوشي، وهي أصغر وحدة في Bitcoin) داخل UTXO. القاعدة هي 1 sat = 1 رمز ARC-20.

بروتوكول ARC20، مثل بروتوكول BRC20، مُقسّم أيضاً إلى ثلاث خطوات: النشر (deployment)، والسك (minting)، والتحويل (transfer). في مرحلة النشر، يجب تعبئة اسم الرمز القياسي، وإجمالي كمية الرموز، وقيود الصب (casting restrictions)، ومعلومات البلوك داخل UTXO.، ومعلومات الصورة... إلخ. في مرحلة السك، يحتاج المستخدم إلى إدخال اسم الرمز داخل UTXO، وكمية sats الخاصة بـ UTXO هي مقدار سك/إصدار رمز ARC20، ولا يتم تعبئتها داخل UTXO مع اسم الرمز. عندما يتم سك رموز ARC20، يمكن إرسالها إلى عناوين أخرى. عند إرسال الرموز، لا يحتاج المستخدمون إلى تعبئة أي بيانات داخل UTXO، بل يقومون مباشرةً بتحويل UTXO الذي يحمل الرمز إلى عناوين أخرى.

عند الاستعلام عن رموز ARC20، يلزم فهرس واحد فقط. يمكن لخادم فهرس البالغات (offline index server) قراءة معلومات تسجيل الرمز وإصدار وإرسال معاملات التحويل. لا حاجة لأن يقوم الخادم بحساب علاقة تحويل الأموال والاستعلام عن رموز ARC20 المملوكة للعِنوان. يمكن الحصول على الكمية عبر قراءة مباشرةً لكمية sats الخاصّة بـ UTXO الذي يحمل الرمز.

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

بما أن بروتوكولات inscription على BTC مثل BRC20 وARC20 مبنية على معاملات UTXO، فإن معاملات الـ inscription تُضاف فعلياً إلى معاملات BTC، ويمكن للمستخدمين تنفيذ عمليات تحويل BTC العادية دون فهم كامل للـ inscription. يتم دمج UTXO الحالي مع UTXOs أخرى وتقسيمه ثم إرساله إلى عناوين غير مقصودة، ما يؤدي إلى تحويل خاطئ للأصول المسجلة أو "حرقها"، مما يسبب خسائر لا يمكن عكسها.

3. Ethscription

Ethscription هو بروتوكول لإنشاء ومشاركة البيانات على Ethereum. تستخدم بعض inscriptions هذا البروتوكول لاستبدال العقود الذكية لتنفيذ إصدار الرموز. إن استخدام inscriptions يمكن أن يُخفض تكاليف المستخدم إلى مستويات منخفضة جداً.

عندما يرسل Ethereum معاملة، فإنه يوفّر كتلة بيانات calldata. بشكل عام، ستُترك كتلة البيانات هذه فارغةً لعمليات نقل ETH العادية. إذا تم استدعاء عقد ذكي، فستُعيَّن كتلة البيانات كـ توقيع دالة الاستدعاء وبيانات كل وسيط (parameter) على حدة. يستخدم بروتوكول Ethscription كتلة بيانات calldata لإضافة بعض البيانات القياسية، بحيث تُعطي معنىً ذا صلة عند إرسال عمليات نقل ETH العادية.

كيف تحدد Ethscription هذه البيانات القياسية؟

أولاً، إذا كنت تريد إنشاء Ethscription يكون محتواه عبارة عن بيانات صورة، فستحتاج إلى تحويل الصورة (حجم الصورة محدود بـ 96KB) إلى URI لبيانات مُشفّرة Base64 بصيغة (data:image/png;base64,...)؛ ثم حوّل الـ URI إلى سلسلة سداسية عشرية (hexadecimal string)؛ بعد ذلك أرسل معاملة تحويل عادية إلى عنوان الوجهة عبر Ethereum، واملأ سلسلة hex أعلاه داخل calldata كما هو موضح أدناه:

بهذه الطريقة، يمتلك العنوان 0xf1bf Ethscription، وستُعتبر أي Ethscription يتم إنشاؤها لاحقاً بنفس calldata غير صالحة.

إذا كنت تريد نقل Ethscription، فأنت بحاجة إلى أن يقوم مالك Ethscription بإرسال تحويل عادي إلى عنوان الاستلام، ثم تعبئة تجزئة (hash) المعاملة التي أنشأت Ethscription في calldata؛ عندها سيصبح عنوان الاستلام هو مالك Ethscription، كما هو موضح أدناه:

4. inscription لسلسلة EVM Blockchain

بالنسبة لسلاسل بلوكشين EVM مثل BSC Chain وEthereum وPolygon، توجد طريقة شائعة لحرق inscriptions، وهي استخدام كتلة بيانات calldata لتخزين بيانات بصيغة ثابتة. وبخلاف طريقة حفظ بيانات الصورة المذكورة أعلاه، فإن هذه الطريقة هي كتابة صيغة معيارية في calldata. بيانات نصية.

عند حرق inscriptions على سلسلة BSC، تكون صيغة inscription مشابهة لصيغة BRC20. على سبيل المثال، تكون صيغة inscription: data:,{"p":"_","op":"_","tick":"_"," amt":"_"} ثم يَمثّل الحقل p اسم البروتوكول، مثل bsc-20 وbnbs-20 وltc-20 وbep-20 وdrc-20 وnrc-20 وsrc-20 إلخ؛ الحقل op يَمثّل العملية، وغالباً "mint"؛ الحقل tick يَمثّل اسم الرمز؛ والحقل amt يَمثّل عدد الرموز.

خذ رمز bnbs كمثال: يمكننا أن نرى أنه طالما تم إرسال تحويل عادي إلى عنوان الوجهة، وملء البيانات:,{"p":"bsc-20","op":"mint" في calldata،"tick":"bnbs","amt":"1000"} ثم إكمال عملية سك رمز bnbs، كما هو موضح أدناه. في هذه اللحظة، يمتلك عنوان 0x22ef 1,000 رمز bnbs.

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

الأمر مشابه إلى حد كبير على Ethereum وPolygon وسلاسل أخرى، لكن ينبغي ملاحظة أن محتوى BSC Chain أعلاه ليس الحالة الوحيدة التي يتم فيها إنشاء inscriptions على سلسلة EVM. قد توجد اختلافات في حقول بيانات النص المعبأة بين سلاسل EVM المختلفة أو بين البروتوكولات المختلفة. قد توجد أيضاً اختلافات في طريقة نقل الرموز. لكن بالنسبة لهذا النوع من الأسلوب، فإنها كلها تُنفَّذ باستخدام خاصية calldata في سلسلة EVM، لذلك تبدو متشابهة.

ملخص

في هذا المقال نناقش مبادئ تنفيذ inscriptions على سلاسل متعددة. باختصار، فإن inscriptions التي تم تقديمها كلها عبارة عن عمليات تستخدم بعض ميزات النظام في سلسلة عامة لحفظ معلومات غير متصلة (offline) على blockchain وفق معايير محددة، ثم يتم التعرف عليها وعرضها عبر خوادم غير متصلة. لا تستخدم أي inscriptions من التي تم تقديمها عقوداً ذكية. يمكن للمستخدمين تقليل كمية كبيرة من تكاليف المعاملات الإضافية عند المشاركة. ومع ذلك، يحتاج المستخدمون إلى فهم كامل لكيفية تنفيذ بروتوكول inscription لتجنب التحويلات الخاطئة أو الحرق العرضي للـ inscriptions، مما يؤدي إلى خسارة الأصول.

اتصل بنا

إذا كنت تحتاج إلى أي خدمات أمن للبلوكشين، فمرحباً بك للتواصل معنا:

الموقع الرسمي Beosin EagleEye Twitter Telegram Linkedin