كيف تعمل معاملات البلوكشين؟ من الإنشاء إلى تغيير الحالة

معاملة البلوكشين طلبٌ مُصرَّح به لتغيير حالة الشبكة

معاملة البلوكشين ليست قيمة تنتقل عبر نفق خفي، بل بيانات منظَّمة تطلب من الشبكة تطبيق تغيير محدد. قد يكون التغيير نقل العملة الأصلية، أو استدعاء عقد ذكي، أو تحويل رمز، أو إنشاء أصل، أو تحديث جزء آخر من السجل الموزع.

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

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

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

يحدد المستخدم النية، لكن المحفظة هي التي تُنشئ كائن المعاملة

يفكر المستخدم عادة بأوامر بسيطة: أرسل 0.01 BTC، أو حوّل 50 USDT، أو بدّل رمزًا، أو تفاعل مع عقد. لا تستطيع البلوكشين معالجة هذه النية البشرية مباشرة؛ بل يجب على المحفظة أو التطبيق ترجمتها إلى صيغة دقيقة تفهمها الشبكة المختارة.

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

لهذا لا تقتصر المعاملة على أمر دفع، بل هي وصف قابل لقراءة الآلة لما ينبغي تغييره، ومن أجازه، والموارد المسموح باستخدامها، والقواعد الواجب استيفاؤها.

تختلف حقول المعاملات بين الشبكات، لكن كل معاملة تحتاج سياقًا يكفي للتحقق منها

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

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

يخوّل التوقيع الرقمي بيانات المعاملة المحددة؛ ولا ينقل الأموال بمفرده

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

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

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

يصف نموذجا UTXO والحسابات الحالة القابلة للإنفاق بأسلوبين مختلفين

تنبع صيغة المعاملة من نموذج السجل. تستخدم بيتكوين نموذج مخرجات المعاملات غير المنفقة UTXO؛ فتستهلك المعاملة مخرجات محددة من معاملات سابقة وتنشئ مخرجات جديدة. لا تحدّث الشبكة رصيد حساب بيتكوين عالمي واحد، بل تجمع المحفظة المخرجات التي تستطيع مفاتيحها إنفاقها لحساب الرصيد المتاح.

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

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

تعمل TON بالرسائل؛ فقد تؤدي رسالة واردة إلى تنفيذ معاملة لحساب واحد تغيّر حالته وترسل رسائل إلى حسابات أخرى. توضّح وثائق الرسائل والمعاملات في TON هذا الترابط.

ينشر البث معاملة مرشحة؛ لكنه لا يعني اتفاق الشبكة عليها

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

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

يفسر دليل شبكة بيتكوين الندّية تبادل المعاملات بين العقد الكاملة. لذا فإن «البث» يعني بدء توزيع الطلب، وليس قبول الجميع نتيجة موحدة ومعتمدة.

تفحص العقد بيانات المعاملة والحالة التي سيجري التنفيذ عليها

التحقق من التوقيع ليس سوى خطوة. تراجع العقدة الترميز وقيم الحقول والموارد المشار إليها ومتطلبات الترتيب، ثم تختبر الطلب مقابل الحالة الحالية للسجل كما تراها.

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

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

تتحقق سولانا من التوقيعات المطلوبة وتجزئة الكتلة الحديثة وأقفال الحسابات وبنية التعليمات والرسوم وقواعد بيئة التنفيذ. أما TON فتتحقق من الرسالة الواردة وتعالج الحساب ضمن مراحل يحددها البروتوكول.

معاملة مرشحة
├─ هل البنية صحيحة؟
├─ هل التوقيعات المطلوبة صالحة؟
├─ هل المدخلات أو حالة الحساب متاحة؟
├─ هل الترتيب / nonce / تجزئة الكتلة مقبولة؟
├─ هل الرسوم والموارد كافية؟
└─ هل يسمح البروتوكول بالعملية؟
   ├─ لا ← رفض أو عدم إعادة البث
   └─ نعم ← الاحتفاظ بها مرشحة للإدراج

التحقق يعتمد على السياق: قد تكون المعاملة صالحة عند توقيعها لكنها تصبح غير قابلة للتنفيذ قبل إدراجها؛ فقد ينفق طلب آخر مخرج بيتكوين نفسه، أو يتأخر nonce سابق في إيثريوم، أو تنتهي صلاحية تجزئة كتلة سولانا.

المعاملة المعلقة المقبولة محليًا ليست مسجلة بعد في الحالة المعتمدة

تحتفظ شبكات كثيرة بتجمعات محلية لمعاملات اجتازت شروط القبول ولم تُدرج بعد. كلمة «mempool» مفيدة لكنها لا تعني عادة وجود تجمع عالمي واحد؛ فكل عقدة تدير قائمة مرشحيها وفق رؤيتها وسياساتها.

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

تشرح مقالة OxaPay عن تجمع المعاملات المعلقة سبب التنافس على السعة وتغير وقت الإدراج. ويكتفي هذا التحليل بدور التجمع في دورة الحياة؛ فسوق الرسوم والمنافسة على مساحة الكتل يستحقان بحثًا مستقلًا.

يحدد الإدراج في الكتلة موضع التنفيذ ضمن تاريخ مقبول

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

الترتيب مؤثر لأن المعاملات تعتمد على الحالة السابقة. قد تتنافس معاملتان على مورد واحد، وقد تنتج استدعاءات العقود نتائج مختلفة بتغيير الترتيب. كذلك تفرض أرقام nonce تسلسلًا، وتؤثر أقفال حسابات سولانا في التنفيذ المتوازي.

إذن لا يقتصر الإدراج على إضافة طابع زمني؛ بل يحدد موقع المعاملة في سلسلة انتقالات الحالة بحيث تُقيَّم بعد العمليات السابقة وقبل اللاحقة.

يحوّل التنفيذ الحالة السابقة إلى حالة لاحقة وفق قواعد حتمية

بعد وصول المعاملة إلى موضعها تطبق الشبكة القواعد المناسبة. يمكن تمثيل ذلك بدالة انتقال الحالة:

post_state = transition(pre_state, ordered_transaction, protocol_rules)

في بيتكوين يزيل التحقق الناجح المخرجات المستهلكة من مجموعة UTXO ويضيف الجديدة. وفي إيثريوم قد يغيّر التنفيذ الأرصدة ويزيد nonce المرسل وينشر عقودًا ويحدّث تخزينها ويصدر سجلات أحداث. وتقارن اختبارات مواصفات تنفيذ إيثريوم الحالة السابقة بالحالة المتوقعة بعدها.

في سولانا تستدعي كل تعليمة برنامجًا مع حسابات معلنة، وتطبّق تغييرات الحسابات بصورة ذرية: إما أن تنجح المعاملة كوحدة واحدة وإما تُسترجع تغييراتها. وفي TON قد تغير معالجة رسالة حسابًا وترسل رسائل تُنشئ معاملات لاحقة على حسابات أخرى.

يوضح تحويل الرمز سبب اختلاف المعاملة عن حركة القيمة. ففي شبكات العقود الذكية تستدعي المعاملة الأصلية عقد الرمز الذي يحدّث أرصدته المخزنة وقد يصدر حدث تحويل؛ وليس هناك جسم منفصل ينتقل ماديًا بين عنوانين.

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

الرفض والإسقاط والاستبدال والانتهاء والتراجع إخفاقات تحدث في طبقات مختلفة

عبارة «معاملة فاشلة» واسعة جدًا. فقد ترفض معاملة مشوهة أو غير مصرّح بها قبل الانتشار؛ أو تبقى معاملة صالحة معلقة لعدم اختيارها؛ أو تستبدلها معاملة منافسة؛ أو تنتهي صلاحيتها؛ أو يُدرج استدعاء عقد لكنه يتراجع خلال التنفيذ.

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

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

يُشتق معرّف المعاملة عادة من بياناتها المرمزة، ليسمح للعقد والمستكشفات والمحافظ والتطبيقات بالإشارة إليها دون تكرار حمولتها. تختلف خوارزميات التجزئة وقواعد المعرّفات باختلاف الشبكة.

يشرح دليل OxaPay عن معرّف معاملة العملات المشفرة استخدام TXID في التحقق والدعم، ويمكن لـمستكشف البلوكشين عرض العناوين والمبالغ والرسوم وموضع الكتلة وحالة التنفيذ والتأكيدات.

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

دورة الحياة مشتركة، لكن دلالات المعاملات وضماناتها تختلف بين السلاسل

تنتقل جميع الشبكات من عملية مقترحة إلى حالة مقبولة، لكن آلياتها مختلفة: تنفق بيتكوين المخرجات، وتنقل إيثريوم ETH أو تستدعي العقود، وتجمع سولانا تعليمات تعمل على حسابات محددة، وتعتمد TON الرسائل ومعالجة المعاملات لكل حساب.

تؤثر الاختلافات في الرسوم وحجم المعاملة والترتيب والتنفيذ المتوازي والانتهاء وكشف الرموز ومعنى النجاح. وتؤثر كذلك في قراءة خدمات الدفع للبيانات: يُعرف دفع ERC-20 من تنفيذ العقد والسجلات، ودفع بيتكوين الأصلي من المخرجات، وقد يلزم تتبع رسائل متعاقبة بين عقود لاكتشاف تحويل Jetton في TON.

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

معاملة البلوكشين سجل واحد داخل منظومة دفع كاملة

يبدأ طلب الدفع بسياق تجاري: طلب شراء ومبلغ وأصل وشبكة ووجهة ومدة صلاحية ومرجع عمل. تسجل معاملة البلوكشين ما أرسله الدافع فعليًا؛ وتقارن منظومة الدفع المتوقع بما رُصد على الشبكة.

يوضح طرف معلومات الدفع في OxaPay الفصل بين المستويين: قد يحوي سجل الدفع معرّف تتبع وسياق الطلب والحالة العامة؛ فيما تضم بيانات المعاملة التجزئة والمبلغ والعملة والشبكة والعنوان والحالة والتأكيدات.

حالة الشبكة وحالة الدفع مترابطتان لكنهما غير متطابقتين. يشمل جدول حالات الدفع في OxaPay الانتظار والدفع الجاري والمدفوع والناقص والاسترداد الجاري والمسترد والمنتهي. لا تنتج البلوكشين هذه المعاني التجارية بذاتها.

طلب تجاري
الطلب + المبلغ المتوقع + الأصل + الشبكة + المهلة
          ↓
معاملة البلوكشين
التجزئة + المدخلات/الحسابات + التعليمات + التوقيع + التنفيذ
          ↓
تفسير الدفع
المطابقة + سياسة التأكيد + قواعد الاستثناء + الحالة التجارية

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

افهم أي معاملة بلوكشين عبر نموذج من سبع خطوات

1. النية: يحدد المستخدم أو التطبيق النتيجة المطلوبة.
2. البناء: تحوّل المحفظة النية إلى كائن خاص بالشبكة.
3. التفويض: توقّع المفاتيح اللازمة البيانات أو شروط الإنفاق.
4. الانتشار: تستقبل العقد المرشح وتتحقق منه وتنشره.
5. القبول والاختيار: تنتظر المعاملات المرشحة وفق السياسات والسعة والترتيب والرسوم.
6. الإدراج والتنفيذ: تحصل المعاملة على موضع مرتب وتُطبّق على الحالة السابقة.
7. الحالة المقبولة: تصبح النتيجة جزءًا من تاريخ الشبكة وتكتسب التزامًا متزايدًا.

يخلط كثيرون بين «أُرسلت» و«تغيّرت الحالة». يوضح هذا النموذج ضرورة المرور بالبناء والتفويض والتحقق والترتيب والتنفيذ قبل أن يسجل السجل النتيجة.

وثائق البروتوكولات المعتمدة في هذا التحليل

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