سجلات الأحداث

ما هي سجلات الأحداث في الكريبتو؟

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

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

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

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

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

توضح وثائق Solidity الرسمية حول الأحداث أن الأحداث تجريد مبني على وظائف التسجيل في EVM.

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

بل توفر سجلًا فعالًا يمكن للبرامج الخارجية استخدامه لفهم ما حدث أثناء المعاملة.

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

كيف تعمل سجلات الأحداث؟

يُنشأ سجل الحدث أثناء معالجة آلة Ethereum الافتراضية لمسار تنفيذ ناجح ضمن معاملة.

يعرّف العقد أولًا حدثًا باسم وقائمة من المعلمات.

ثم يصدر العقد الحدث عندما تصل شيفرته إلى التعليمة ذات الصلة.

يحوّل مترجم Solidity إصدار الحدث إلى إحدى عمليات التسجيل في EVM.

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

يصبح السجل جزءًا من إيصال المعاملة بعد إدراج المعاملة في كتلة.

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

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

إذا تراجعت المعاملة، تُحذف أيضًا السجلات التي أُنشئت أثناء التنفيذ المتراجع من النتيجة النهائية للمعاملة.

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

الأحداث مقابل سجلات الأحداث

الحدث هو تعريف يحدده المطور ويصف المعلومات التي يمكن للعقد نشرها.

أما سجل الحدث فهو السجل الفعلي الذي يُنشأ عندما يصدر العقد ذلك الحدث أثناء المعاملة.

على سبيل المثال، قد يعرّف عقدٌ حدث Transfer في شيفرته المصدرية.

ويمكن لكل عملية تحويل مكتملة إنشاء سجل منفصل استنادًا إلى تعريف الحدث هذا.

يعمل الحدث كقالب، بينما يمثل كل سجل واقعة واحدة مسجلة وفقًا لذلك القالب.

قد لا تنشئ معاملة واحدة أي سجلات، أو سجلًا واحدًا، أو سجلات عديدة.

وقد تنتج المعاملة التي تتفاعل مع عدة عقود ذكية سجلات من كل عقد مشارك في التنفيذ.

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

ما المعلومات المخزنة في سجل الحدث؟

يتضمن سجل أحداث EVM عنوان العقد المُصدر، وما يصل إلى أربعة موضوعات، وحقل بيانات متغير الطول.

يحدد العنوان المُصدر العقد الذي أنشأ تنفيذه السجل.

تحتوي الموضوعات على قيم مصممة للترشيح والبحث بكفاءة.

يخزن حقل البيانات معلمات الحدث التي لم تُحدد على أنها مفهرسة.

تعرض واجهات RPC الشائعة أيضًا بيانات المعاملة والكتلة الوصفية مع السجلات.

قد تتضمن هذه البيانات هاش المعاملة، وفهرس المعاملة، وهاش الكتلة، ورقم الكتلة، وفهرس السجل.

يحدد فهرس السجل موضع السجل بين السجلات الأخرى في الكتلة نفسها.

ينبغي للتطبيقات عمومًا استخدام مزيج من معرّف السلسلة وهاش الكتلة وهاش المعاملة وفهرس السجل عند إنشاء معرّف فريد للسجل.

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

ما هي موضوعات الأحداث؟

الموضوعات قيم بحجم 32 بايت توضع في جزء خاص قابل للبحث من سجل EVM.

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

يمكن لحدث Solidity عادي غير مجهول استخدام ما يصل إلى أربعة موضوعات.

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

ترتب الموضوعات تسلسليًا، لذا يختلف الترشيح عن قيمة في الموضع الثاني عن الترشيح للقيمة نفسها في الموضع الثالث.

توضح وثائق Ethereum JSON-RPC الخاصة بـ eth_getLogs أن مرشحات الموضوعات تعتمد على ترتيبها، ويمكن أن تتضمن قيمًا بديلة للموضع نفسه.

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

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

ما هو Topic 0؟

يحتوي Topic 0 عادةً على هاش Keccak-256 للتوقيع القياسي للحدث.

يجمع التوقيع القياسي اسم الحدث مع أنواع معلماته المرتبة.

لا تُضمّن أسماء المعلمات والكلمة المفتاحية indexed في هاش توقيع الحدث.

على سبيل المثال، يكون توقيع حدث باسم Transfer ومعلمات أنواعها address وaddress وuint256 متوقعًا.

يمكن للتطبيقات مقارنة Topic 0 بهاشات التوقيعات المعروفة لتحديد الحدث الذي يمثله سجل خام.

يؤدي تغيير اسم الحدث أو ترتيب معلماته أو أنواعها إلى إنشاء توقيع حدث مختلف.

لذلك يكون لـ Topic 0 قيم مختلفة لحدثين لهما الاسم نفسه لكن أنواع المعلمات مختلفة.

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

معلمات الأحداث المفهرسة

المعلمة المفهرسة وسيط حدث يُخزن في موضوع كي تتمكن الأنظمة الخارجية من ترشيحه بكفاءة.

تسمح Solidity بما يصل إلى ثلاث معلمات مفهرسة في الحدث العادي غير المجهول.

ويُخصص موضع الموضوع المتبقي لتوقيع الحدث.

يمكن تخزين العناوين والأعداد الصحيحة والقيم المنطقية والقيم الأخرى التي تتسع لكلمة واحدة بحجم 32 بايت مباشرةً في موضوع باستخدام ترميز متوافق مع ABI.

أما القيم الديناميكية مثل السلاسل النصية ومصفوفات البايتات والمصفوفات الديناميكية والهياكل المعقدة، فتُعالج بطريقة مختلفة.

عند فهرسة قيمة ديناميكية، يخزن الموضوع هاش Keccak-256 لقيمتها المشفّرة بدلًا من القيمة الأصلية المقروءة.

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

لكن لا يمكنه استعادة سلسلة نصية أو مصفوفة بايتات أصلية مجهولة من الهاش وحده.

يضمّن المطورون أحيانًا المعلومات نفسها مرتين بوضع نسخة مجزأة في معلمة مفهرسة ونسخة مقروءة في معلمة غير مفهرسة.

يحسن هذا التصميم قابلية البحث مع الحفاظ على القيمة الأصلية لإمكان فك ترميزها.

معلمات الأحداث غير المفهرسة

تُخزن المعلمات التي لا تتضمن الكلمة المفتاحية indexed في حقل البيانات الخاص بالسجل.

وتُرمّز هذه القيم وفق قواعد Ethereum ABI.

يلزم استخدام ABI لأن بيانات السجل الخام لا تضع اسمًا ونوعًا مقروءين للبشر لكل قيمة.

يحتاج التطبيق إلى تعريف الحدث الصحيح لفك ترميز البيانات على نحو موثوق.

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

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

لا تستطيع التطبيقات عادةً مطالبة eth_getLogs بالترشيح وفق قيمة عشوائية داخل حقل البيانات.

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

الأحداث المجهولة

يمكن تعريف حدث Solidity على أنه مجهول.

لا يضع الحدث المجهول هاش توقيعه تلقائيًا في Topic 0.

يتيح ذلك استخدام مواضع الموضوعات الأربعة كلها للمعلمات المفهرسة.

لكن إزالة موضوع التوقيع تصعّب على البرامج الخارجية تحديد نوع الحدث تلقائيًا.

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

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

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

رموز التسجيل التشغيلية في EVM

توفر EVM خمسة رموز تشغيلية للتسجيل، وهي LOG0 إلى LOG4.

يمثل الرقم في اسم كل رمز عدد الموضوعات المدرجة في السجل.

ينشئ LOG0 سجلًا بلا موضوعات، بينما ينشئ LOG4 سجلًا بأربعة موضوعات.

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

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

تضيف بيئة التنفيذ عنوان العقد إلى السجل، ولا يُمرر كمعلمة حدث عادية.

تستهلك عمليات التسجيل الغاز وفق عوامل منها عدد الموضوعات وكمية البيانات المسجلة.

يسرد المرجع الرسمي لرموز Ethereum التشغيلية تعليمات التسجيل في EVM وتكاليف تنفيذها.

سجلات الأحداث وإيصالات المعاملات

إيصال المعاملة هو سجل التنفيذ الذي يُنتج بعد إدراج المعاملة في كتلة.

يتضمن الإيصال معلومات مثل حالة التنفيذ، وإجمالي استهلاك الغاز التراكمي، ومرشح Bloom للسجلات، والسجلات التي أصدرتها المعاملة.

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

تحافظ مصفوفة السجلات على ترتيب إصدار الأحداث أثناء التنفيذ.

قد تحتوي المعاملة الناجحة على مصفوفة سجلات فارغة إذا لم يصدر أي عقد حدثًا.

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

ينبغي للتطبيقات التحقق من حالة الإيصال بدلًا من اعتبار وجود هاش للمعاملة دليلًا على نجاح التنفيذ.

تصف طريقة Ethereum JSON-RPC الخاصة بإيصالات المعاملات حقول الإيصال التي يعيدها عميل التنفيذ.

سجلات الأحداث وإيصالات الكتل

تُثبّت إيصالات المعاملات تشفيريًا عبر جذر الإيصالات في الكتلة.

يتيح هذا الالتزام لمشاركي البلوكشين التحقق من أن الإيصالات تنتمي إلى تاريخ كتلة محدد.

يتضمن كل إيصال السجلات التي أنتجتها معاملته.

يتضمن رأس الكتلة أيضًا مرشح Bloom يلخص عناوين السجلات وموضوعاتها من معاملات تلك الكتلة، وفق تنسيق كتلة التنفيذ الحالي.

يساعد مرشح Bloom العميل على تحديد ما إذا كانت الكتلة قد تحتوي على سجلات مطابقة لاستعلام.

لا تثبت المطابقة الإيجابية لمرشح Bloom وجود سجل مطابق، إذ يمكن لهذه المرشحات إنتاج إيجابيات كاذبة.

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

تظل التطبيقات بحاجة إلى سجلات الإيصالات الفعلية للتحقق من قيم الأحداث بدقة.

سجلات الأحداث مقابل بيانات العقد

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

تحتوي بيانات العقد على معلومات دائمة يمكن لتنفيذ العقود الذكية مستقبلًا قراءتها مباشرةً.

أما سجلات الأحداث، فمصممة أساسًا للمراقبة الخارجية والفهرسة التاريخية.

لا تستطيع عقود Solidity قراءة سجلات الأحداث التاريخية مباشرةً، بما فيها السجلات التي أصدرها العقد نفسه.

ينص مرجع أحداث Solidity على أن بيانات السجل والحدث غير متاحة من داخل العقود.

ينبغي ألا يعتمد العقد أبدًا على حدث سابق باعتباره المصدر الوحيد للبيانات اللازمة لقراراته اللاحقة على السلسلة.

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

تكون السجلات عمومًا أقل تكلفة من التخزين الدائم للمعلومات المخصصة للمستخدمين خارج السلسلة فقط.

لكن استخدام السجل بدلًا من التخزين يغير ما تستطيع العقود الذكية التحقق منه أو استرجاعه لاحقًا.

سجلات الأحداث مقابل البيانات المُعادة من الدوال

تُرسل البيانات المعادة من الدالة إلى المستدعي المباشر أثناء تنفيذ العقد.

أما سجلات الأحداث، فتُخزن في إيصالات المعاملات لاسترجاعها لاحقًا خارج السلسلة.

لا توفر المعاملة التي تغيّر الحالة بيانات معادة لواجهة المستخدم بالصيغة التاريخية السهلة نفسها التي يوفرها سجل الحدث.

غالبًا ما تعتمد التطبيقات على الإيصالات والأحداث لمعرفة نتيجة المعاملة المرسلة.

يمكن للاستدعاءات للقراءة فقط إرجاع قيم من دون إنشاء سجلات أحداث أو تغيير حالة البلوكشين.

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

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

كيف تستعلم التطبيقات عن سجلات الأحداث؟

تستعلم التطبيقات عادةً عن سجلات الأحداث التاريخية عبر طريقة eth_getLogs في JSON-RPC.

يمكن للاستعلام تحديد كتلة بداية وكتلة نهاية وعنوان عقد وهاش كتلة ومرشحات موضوعات.

تعيد الطريقة مصفوفة من السجلات المطابقة للمرشح.

يكون الاستعلام المحدود عادةً أكثر موثوقية وكفاءة من طلب كل السجلات ضمن نطاق كتل ضخم.

قد تفرض مزودات RPC حدودًا على نطاقات الكتل أو أحجام الاستجابات أو وقت الطلب أو وتيرة الاستعلامات.

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

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

قد يساعد استخدام مرشح blockHash المحدد في EIP-234 التطبيق على طلب السجلات التابعة لكتلة واحدة محددة.

الاستقصاء والاشتراكات بالأحداث

يمكن للتطبيق اكتشاف سجلات الأحداث الجديدة عبر الاستقصاء المتكرر أو الاشتراكات.

يطلب الاستقصاء من العقدة مرارًا السجلات أو تغييرات المرشح بمرور الوقت.

أما الاشتراك، فيُبقي اتصالًا مباشرًا مفتوحًا كي ترسل العقدة إشعارات بالسجلات الجديدة عند وصول الكتل.

قد توفر الاشتراكات تحديثات أسرع، لكن الاتصال قد ينقطع أو يفوّت معلومات أثناء التعطل.

قد يسهل التعافي من الاستقصاء لأن التطبيق يستطيع طلب نطاق كتل معروف مجددًا.

غالبًا ما يجمع نظام الإنتاج المتين بين الاشتراكات المباشرة والمطابقة الدورية استنادًا إلى الكتل.

يتيح هذا النهج للتطبيق اكتشاف السجلات التي فاتته أثناء انقطاع الشبكة أو إعادة تشغيل العقدة.

تصف وثائق Ethereum الرسمية لواجهة JSON-RPC طرق المرشحات لاسترجاع السجلات التي ظهرت منذ الاستقصاء السابق.

سجلات الأحداث وإعادة تنظيم السلسلة

تحدث إعادة تنظيم السلسلة عندما تُستبدل كتلة كانت تُعد سابقًا جزءًا من السلسلة النشطة بتاريخ كتل مختلف.

لا تعود سجلات الكتلة المستبدلة جزءًا من البلوكشين المعتمد.

قد يحتاج التطبيق الذي استجاب فورًا لهذه السجلات إلى التراجع عن التغييرات التي أجراها في قاعدة بياناته المحلية.

قد تشير بعض استجابات اشتراكات RPC إلى إزالة سجل سبق الإبلاغ عنه بسبب إعادة التنظيم.

لكن انقطاع الشبكة قد يمنع التطبيق من تلقي إشعار الإزالة.

تتعقب أدوات الفهرسة الموثوقة هاشات الكتل والعلاقات بين الكتل الأصلية لاكتشاف الكتل المستبدلة بشكل مستقل.

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

ينبغي للأنظمة المالية عادةً انتظار مستوى مناسب من التأكيد أو النهائية قبل اعتبار الحدث غير قابل للعكس.

يعتمد مستوى التأكيد المطلوب على السلسلة وقيمة التطبيق وعواقب التصرف مبكرًا.

سجلات الأحداث والنهائية

قد يظهر حدث صادر حديثًا في كتلة مقترحة قبل أن تبلغ تلك الكتلة درجة أقوى من نهائية الإجماع.

يمكن للتطبيقات الاستعلام عن السجلات باستخدام وسوم الكتل مثل latest أو safe أو finalized، متى دعمها العميل المتصل.

يوفر الوسم latest معلومات أسرع، لكنه قد يشمل كتلًا أكثر عرضة لإعادة التنظيم.

يوفر الوسم finalized ثقة أقوى، لكنه يضيف تأخيرًا.

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

ينبغي للتطبيقات اختيار سياسة التأكيد بناءً على المخاطر الاقتصادية، لا تطبيق قاعدة واحدة على كل الأحداث.

سجلات الأحداث في عقود التوكنات

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

عادةً ما يصدر التوكن القابل للاستبدال حدث Transfer عندما تنتقل القيمة بين العناوين.

وقد يصدر أيضًا حدث Approval عندما يغير المالك سماحًا بالإنفاق ممنوحًا لعنوان آخر.

تصدر عقود NFT عادةً أحداث تحويل وموافقة تتضمن معرّفات التوكنات.

ويمكن للعقود متعددة التوكنات إصدار أحداث للتحويلات الفردية والجماعية.

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

لكن قد يصدر التوكن أحداثًا مضللة أو لا يلتزم بالمعيار على نحو صحيح.

لا يثبت الحدث وحده أن العقد شرعي أو ذو قيمة أو آمن.

سجلات الأحداث في التمويل اللامركزي

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

تشمل الأمثلة الشائعة الإيداعات والسحوبات والمبادلات والقروض والسداد والتصفية وتحديثات الفائدة والمطالبة بالمكافآت وتغييرات الحوكمة.

قد تراقب واجهة المستخدم هذه الأحداث لتحديث الأرصدة وسجل المعاملات.

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

وقد تراقب خدمة لمتابعة المخاطر أحداث التصفية أو الضمانات لاكتشاف المراكز المتأثرة بالضغوط.

نظرًا إلى أن معاملة DeFi واحدة قد تستدعي عدة عقود، يمكن أن يحتوي الإيصال على سجلات كثيرة مترابطة.

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

سجلات الأحداث في المحافظ ومستكشفات البلوكشين

تستخدم المحافظ سجلات الأحداث لإنشاء سجلات مقروءة من معاملات العقود الذكية الخام.

قد لا يظهر تحويل التوكنات كحركة مباشرة لأصل الشبكة في الحقول الأساسية للمعاملة.

يمكن للمحفظة فك ترميز حدث Transfer الصادر عن عقد التوكن لعرض الأصل والمرسل والمستلم والمبلغ.

كما تفك مستكشفات البلوكشين ترميز السجلات باستخدام واجهات ABI للعقود التي تم التحقق منها وتوقيعات الأحداث المعروفة.

عندما لا تتوفر معلومات الشيفرة المصدرية أو ABI، قد يعرض المستكشف قيم الموضوعات والبيانات الخام.

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

ينبغي للمستخدمين التحقق من عنوان العقد المُصدر قبل الوثوق بوصف الحدث.

سجلات الأحداث وأدوات فهرسة البلوكشين

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

تسهّل أدوات الفهرسة الإجابة عن أسئلة يصعب التعامل معها عبر طلبات RPC المباشرة.

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

تبدأ أداة الفهرسة عادةً من كتلة مختارة وتعالج الكتل الجديدة بالترتيب.

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

ينبغي أن تتمكن أدوات الفهرسة من استئناف العمل بعد تعطل من دون تخطي الأحداث أو تكرارها.

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

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

سجلات الأحداث والأتمتة خارج السلسلة

يمكن للخدمات خارج السلسلة الاستماع إلى سجلات الأحداث وتشغيل إجراءات خارج البلوكشين.

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

لا يجبر السجل نفسه الخدمة خارج السلسلة على التصرف.

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

ينبغي للأتمتة خارج السلسلة التحقق من معرّف السلسلة وعنوان العقد وحالة الكتلة والقيم المفكوكة الترميز قبل اتخاذ إجراء حساس.

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

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

هل تستطيع العقود الذكية قراءة سجلات الأحداث؟

لا تستطيع العقود الذكية البحث مباشرةً في سجلات الأحداث التاريخية أثناء تنفيذ EVM العادي.

صُممت السجلات للتطبيقات الخارجية، لا لتكون حالة قابلة للقراءة من العقود.

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

تشمل الآليات الممكنة تخزين العقد أو إثباتًا تشفيريًا أو Oracle أو بروتوكول مراسلة بين السلاسل.

يجب على العقد التحقق من موثوقية المعلومات المقدمة قبل استخدامها.

يمنع هذا القيد العقود الذكية من التعامل مع استجابة RPC خارج السلسلة على أنها بيانات صالحة تلقائيًا على السلسلة.

هل يمكن تغيير سجلات الأحداث؟

لا يمكن تعديل سجل مؤكد بمعزل عن المعاملة والكتلة اللتين أنشأتاه.

ويتطلب تغيير السجل استبدال تاريخ البلوكشين الذي يتضمن ذلك الإيصال أو إبطاله.

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

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

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

هل يمكن تزوير سجلات الأحداث؟

يمكن لأي عقد ذكي تعريف حدث باسم وتوقيع مألوفين وإصدارهما.

لذلك يمكن لعقد خبيث إصدار حدث Transfer يشبه الحدث الصادر عن عقد توكن شرعي.

لا يحدد توقيع الحدث وحده هوية الأصل ولا يثبت حدوث تغيير حقيقي في الرصيد ضمن عقد موثوق.

يجب على التطبيقات التحقق من عنوان العقد المُصدر وفهم شيفرة ذلك العقد وحالته.

وقد يصدر توكن احتيالي قيمًا مضللة أو ينشئ أحداثًا توحي بأن محفظة غير نشطة تلقت أصلًا.

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

وينبغي للمستخدمين عدم التفاعل مع توكن لمجرد ظهور حدث تحويل غير متوقع في سجل معاملاتهم.

سجلات الأحداث وأمان العقود الذكية

يُعد تصميم الأحداث جزءًا من أمان العقود الذكية، لأن أنظمة المراقبة تعتمد على دقة السجلات.

ينبغي أن تصدر الأحداث الواضحة عند تغيير الإجراءات الإدارية المهمة، مثل الصلاحيات والرسوم وعناوين Oracle وتطبيقات الترقية والإعدادات الطارئة.

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

وقد تؤدي قيم الأحداث غير الصحيحة إلى عرض أنظمة خارج السلسلة نتيجة لا تطابق حالة العقد.

ينبغي ألا يصدر العقد حدثًا إلا بعد نجاح الفحوصات وتغييرات الحالة المرتبطة به.

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

كما ينبغي اختبار عدم بقاء سجلات نهائية مضللة بعد تراجع المعاملات.

لا ينبغي اعتبار الحدث بديلًا عن تطبيق الصلاحيات وقواعد الأرصدة داخل شيفرة العقد.

تكلفة الغاز لسجلات الأحداث

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

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

لذلك قد تكون تكلفة الحدث الذي يتضمن عدة قيم كبيرة أعلى من تكلفة حدث بسيط.

غالبًا ما تكون السجلات أقل تكلفة من حفظ المعلومات نفسها في تخزين العقد الدائم.

لكن السجلات غير الضرورية ترفع تكاليف معاملات المستخدمين وحجم سجل البلوكشين.

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

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

يجب ألا يؤدي تحسين الغاز إلى إزالة الشفافية المهمة اللازمة لمراقبة نشاط البروتوكول بأمان.

أفضل الممارسات لتصميم الأحداث

ينبغي أن تصف أسماء الأحداث الإجراء الذي وقع بوضوح.

ينبغي أن تكون أسماء المعلمات محددة بما يكفي ليفهم المطورون والمحللون معناها.

ينبغي النظر في جعل القيم التي يبحث عنها المستخدمون كثيرًا معلمات مفهرسة.

تشمل القيم المفهرسة الشائعة عناوين الحسابات ومعرّفات التوكنات ومعرّفات الأسواق ومعرّفات المقترحات.

يمكن عادةً إبقاء المبالغ وقيم الإعدادات التفصيلية في حقل البيانات عندما لا تكون هناك حاجة إلى ترشيح مباشر.

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

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

ينبغي أن تتضمن العقود التي تدعم أصولًا أو أسواقًا متعددة معرّف الأصل أو السوق ذي الصلة.

ينبغي أن تحدد أحداث الترقية القيمتين القديمة والجديدة عندما تكون هذه المعلومات مفيدة للمراقبة.

ينبغي أن تظل تعريفات الأحداث مستقرة عندما تعتمد التطبيقات الخارجية على توقيعاتها وتخطيط معلماتها.

أفضل الممارسات لقراءة سجلات الأحداث

ينبغي للتطبيقات الترشيح بحسب عنوان العقد المتوقع وتوقيع الحدث المتوقع معًا.

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

قد تغير العقود القابلة للترقية الأحداث المتاحة بعد ترقية التطبيق.

ينبغي لأدوات الفهرسة تخزين هاش الكتلة ورقمها وهاش المعاملة وفهرس المعاملة وفهرس السجل.

وينبغي أن تعالج السجلات بترتيب الكتل المعتمد وتدعم التراجع بعد إعادة التنظيم.

ينبغي تقسيم الاستعلامات التاريخية الكبيرة إلى نطاقات كتل يمكن إدارتها.

ينبغي للتطبيقات التمييز بين الاستجابة الفارغة الحقيقية والطلب الفاشل أو المبتور أو المحدود بمعدل الطلبات.

ينبغي أن تنتظر الإجراءات المالية مستوى تأكيد يناسب قيمتها ومخاطرها.

وينبغي للتطبيقات مقارنة القيم المستخلصة من الأحداث بحالة العقد عندما تكون الدقة بالغة الأهمية.

سجلات الأحداث على شبكات Layer 2

تستخدم شبكات Layer 2 القائمة على EVM عادةً سجلات أحداث ذات بنية مشابهة لسجلات Ethereum.

غالبًا ما يستطيع المطورون استخدام أحداث Solidity والموضوعات وواجهات ABI واستعلامات JSON-RPC المألوفة.

لكن قد تختلف شبكات Layer 2 في أوقات الكتل وقواعد التأكيد والمُسلسِلات وهياكل الرسوم وعمليات التسوية النهائية.

قد يكون سجل أكدّه مُسلسِل Layer 2 لم يبلغ بعد أقوى مستوى تسوية له على Ethereum.

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

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

قد يمثل عنوان العقد نفسه أو توقيع الحدث نفسه عقودًا وأصولًا مختلفة على شبكات مختلفة.

سجلات الأحداث في التحويلات عبر السلاسل

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

قد يلاحظ مرحّل خارج السلسلة أو بروتوكول على سلسلة الوجهة حدث السلسلة المصدر قبل متابعة عملية التحويل.

يجب أن يتحقق إجراء الوجهة من الحدث المصدر باستخدام آلية الإثبات أو المدققين الخاصة بالجسر.

لا يكفي مجرد رؤية سجل عبر مزود RPC عادي كي يثبت عقد ذكي غير معتمد على الثقة صحة الحدث.

ويجب على الجسور أيضًا مراعاة إعادة تنظيم السلسلة المصدر والنهائية.

قد يعالج الجسر الذي يتصرف بسرعة مفرطة حدثًا يُزال لاحقًا من السجل المعتمد للمصدر.

ينبغي للمستخدمين فهم أن حدث الجسر الصادر قد يشير إلى بدء التحويل لا اكتماله النهائي.

مثال على سجل حدث

لنفترض أن مستخدمًا يحوّل 500 وحدة من توكن قابل للاستبدال إلى محفظة أخرى.

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

يتحقق العقد من رصيد المرسل ويحدّث رصيد المرسل والمستلم.

ثم يصدر العقد حدث Transfer يتضمن عنوان المرسل وعنوان المستلم والمبلغ المحوّل.

قد يُخزن عنوانا المرسل والمستلم كموضوعات مفهرسة، بينما يُرمّز المبلغ عبر ABI في حقل البيانات.

يظهر هاش توقيع الحدث في Topic 0.

بعد إدراج المعاملة في كتلة، يظهر السجل في إيصال المعاملة.

تسترجع المحفظة السجل وتفك ترميزه لعرض حركة التوكنات في سجل معاملات مقروء.

كما تسجل أداة فهرسة الحدث كي يتمكن المستخدمون من البحث عن كل التحويلات المرتبطة بأي من العنوانين.

يوضح هذا المثال كيف يربط سجل حدث واحد تنفيذ العقد بالمحافظ والمستكشفات وتحليلات البلوكشين.

أخطاء شائعة في التعامل مع سجلات الأحداث

من الأخطاء الشائعة افتراض أن عقدًا ذكيًا آخر يستطيع قراءة الحدث.

ومنها أيضًا اعتبار توقيع حدث مألوف دليلًا على شرعية العقد المُصدر.

والخطأ الثالث فك ترميز سجل من دون التحقق من عنوان العقد.

والرابع افتراض إمكانية استعادة سلسلة نصية مفهرسة مباشرةً من هاش موضوعها.

والخامس استخدام هاش المعاملة وحده معرّفًا للسجل.

والسادس عدم التعامل مع إعادة تنظيم السلسلة.

والسابع معالجة السجل نفسه مرتين بعد إعادة طلب RPC أو إعادة تشغيل التطبيق.

والثامن الاستعلام عن نطاق كتل ضخم للغاية واعتبار الطلب الذي انتهت مهلته نتيجة فارغة.

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

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

الأسئلة الشائعة

ما هي سجلات الأحداث في الكريبتو؟

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

أين تُخزن سجلات أحداث Ethereum؟

تُدرج سجلات أحداث Ethereum في إيصالات المعاملات، التي تُثبت ضمن سجل التنفيذ للكتلة.

ما الفرق بين الحدث والسجل؟

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

هل تستطيع العقود الذكية قراءة سجلات الأحداث القديمة؟

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

ما هو Topic 0 في سجل أحداث Ethereum؟

يحتوي Topic 0 عادةً على هاش Keccak-256 لاسم الحدث وأنواع معلماته القياسية.

كم عدد الموضوعات التي يمكن أن يتضمنها سجل الحدث؟

يمكن أن يتضمن سجل EVM ما يصل إلى أربعة موضوعات، ويحجز حدث Solidity العادي عادةً موضوعًا لتوقيع الحدث.

ماذا تعني كلمة indexed في حدث Solidity؟

تُخزن المعلمة المفهرسة في موضوع كي تتمكن التطبيقات الخارجية من ترشيح السجلات وفقًا لقيمتها.

هل يمكن فهرسة السلاسل النصية في سجلات الأحداث؟

نعم، لكن السلسلة المفهرسة تُمثل بهاش Keccak-256 بدلًا من نصها الأصلي المقروء.

ماذا يحدث لسجلات الأحداث عندما تتراجع المعاملة؟

تُحذف السجلات التي أُنتجت أثناء التنفيذ المتراجع من النتيجة النهائية للمعاملة.

هل تستهلك سجلات الأحداث غازًا؟

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

هل يثبت سجل الحدث شرعية التوكن؟

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

كيف يمكن للمطورين استرجاع سجلات الأحداث؟

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

هل يمكن لإعادة تنظيم البلوكشين إزالة سجل حدث؟

نعم، يُزال السجل الصادر عن كتلة مستبدلة من تاريخ السلسلة المعتمد.

هل تتطابق سجلات الأحداث على كل سلاسل EVM؟

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

هل سجلات الأحداث أقل تكلفة من تخزين العقد؟

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

لماذا تستخدم المحافظ سجلات الأحداث؟

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

الخاتمة

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

تُنشأ عبر تعليمات التسجيل في EVM وتُخزن في إيصالات المعاملات بعد نجاح التنفيذ.

يتضمن السجل عنوان العقد المُصدر وموضوعات قابلة للبحث وبيانات أحداث مشفّرة وفق ABI.

يحدد Topic 0 عادةً توقيع الحدث، بينما توفر المعلمات المفهرسة خيارات ترشيح إضافية.

تُخزن المعلمات غير المفهرسة في حقل البيانات وتتطلب واجهة ABI الصحيحة لفك ترميزها.

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

كما تختلف عن البيانات المعادة من الدوال، لأن السجلات مصممة لتظل متاحة للمعالجة التاريخية خارج السلسلة.

يمكن للتطبيقات استرجاع السجلات عبر مرشحات JSON-RPC والاشتراكات وإيصالات المعاملات ومستكشفات البلوكشين وأدوات الفهرسة المتخصصة.

يجب على الأنظمة الموثوقة التعامل مع المعالجة المكررة وقيود RPC وإعادة تنظيم السلسلة وترقيات العقود ومستويات التأكيد المختلفة.

ينبغي للمستخدمين تذكر أن اسم الحدث المألوف لا يثبت موثوقية العقد المُصدر ولا شرعية التوكن.

ينبغي للمطورين تصميم أحداث بأسماء واضحة ومعلمات مفهرسة مفيدة وسياق كافٍ ومخططات مستقرة.

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