أخبارالمطورينإدخالالمشروع Blockchain شرح الأحداث والمؤتمرات الصحافةالنشرات الإخبارية

اشترك في نشرتنا الإخبارية.

عنوان بريد الكتروني

نحن نحترم خصوصيتك

الرئيسيةالمدونةتطوير Blockchain

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

مقدمة فنية لاستخدام الحالات للأحداث والسجلات على سلسلة Ethereum blockchain مع نموذج الكود جوزيف تشاو يونيو 6 ، 2016 نُشر في 6 يونيو 2016

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

قد تكون الأحداث محيرة لأنه يمكن استخدامها بطرق مختلفة. قد لا يبدو حدث ما كحدث لآخر. هناك 3 حالات استخدام رئيسية للأحداث والسجلات:

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

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

1) قيم إرجاع العقد الذكية لواجهة المستخدم

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

عقد ExampleContract {// بعض متغيرات الحالة … دالة foo (int256 _value) ترجع (int256) {// manipulate state … return _value؛ }} لغة الشفرة: JavaScript (javascript)

بافتراض أن exampleContract هو مثيل لـ ExampleContract ، يمكن للواجهة الأمامية باستخدام web3.js الحصول على قيمة مرتجعة عن طريق محاكاة تنفيذ العقد:

var returnValue = exampleContract.foo.call (2) ، console.log (returnValue) // 2Code language: JavaScript (javascript)

ومع ذلك ، عندما ترسل web3.js استدعاء العقد كمعاملة ، لا يمكنها الحصول على قيمة الإرجاع [1]:

var returnValue = exampleContract.foo.sendTransaction (2، {from: web3.eth.coinbase}) ؛ console.log (returnValue) // لغة hashCode للمعاملة: JavaScript (javascript)

دائمًا ما تكون قيمة الإرجاع لطريقة sendTransaction هي تجزئة المعاملة التي تم إنشاؤها. لا تُرجع المعاملات قيمة العقد إلى الواجهة الأمامية لأن المعاملات لا يتم تعدينها على الفور وإدراجها في blockchain.

الحل الموصى به هو استخدام حدث ، وهذا أحد الأغراض المقصودة للأحداث.

عقد مثال على العقد {حدث ReturnValue (عنوان مفهرس _from، int256 _value) ؛ تُرجع الدالة foo (int256 _value) (int256) {ReturnValue (msg.sender، _value) ؛ قيمة الإرجاع؛ }} يمكن للواجهة الأمامية الحصول على القيمة المعادة: var exampleEvent = exampleContract.ReturnValue ({_ from: web3.eth.coinbase})؛ exampleEvent.watch (function (err، result) {if (err) {console.log (err) return؛} console.log (result.args._value) // تحقق من تلك النتيجة.args._from is web3.eth.coinbase ثم // display result.args._value في واجهة المستخدم واستدعاء // exampleEvent.stopWatching ()}) exampleContract.foo.sendTransaction (2، {from: web3.eth.coinbase}) لغة الشفرة: جافا سكريبت (جافا سكريبت)

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

2) مشغلات غير متزامنة مع البيانات

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

3) نموذج تخزين أرخص

تختلف حالة الاستخدام الثالثة تمامًا عما تمت تغطيته ، وهي استخدام الأحداث كشكل أرخص بكثير من التخزين. في جهاز Ethereum Virtual Machine (EVM) و ورقة صفراء Ethereum, يشار إلى الأحداث على أنها سجلات (توجد أكواد تشغيل LOG). عند الحديث عن التخزين ، سيكون من الأكثر دقة من الناحية الفنية القول بأنه يمكن تخزين البيانات في سجلات ، بدلاً من البيانات المخزنة في الأحداث. ومع ذلك ، عندما ننتقل إلى مستوى أعلى من البروتوكول ، فمن الأكثر دقة أن نقول إن العقود تنبعث أو تطلق أحداثًا يمكن للواجهة الأمامية الرد عليها. عندما يتم إصدار حدث ، تتم كتابة السجلات المقابلة في blockchain. المصطلحات بين الأحداث والسجلات هي مصدر آخر للارتباك ، لأن السياق يملي المصطلح الأكثر دقة.

تم تصميم جذوع الأشجار لتكون شكلاً من أشكال التخزين التي تكلف غازًا أقل بكثير من تكلفة تخزين العقد. تكلف السجلات [2] أساسًا 8 غاز لكل بايت ، في حين أن تكلفة تخزين العقد 20000 غاز لكل 32 بايت. على الرغم من أن السجلات توفر وفورات هائلة في الغاز ، إلا أنه لا يمكن الوصول إلى السجلات من أي عقود [3].

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

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

عقد CryptoExchange {event Deposit (uint256 indexed _market، address indexed_sender، uint256 _amount، uint256 _time) ؛ إرجاع الإيداع الوظيفي (uint256 _amount، uint256 _market) (int256) {// إجراء الإيداع وتحديث رصيد المستخدم وما إلى ذلك الإيداع (_market ، msg.sender ، _amount ، الآن) ؛ } لغة الكود: JavaScript (javascript)

لنفترض أننا نريد تحديث واجهة المستخدم أثناء قيام المستخدم بالإيداعات. فيما يلي مثال على استخدام حدث (إيداع) كمشغل غير متزامن مع البيانات (_market ، msg.sender ، _amount ، الآن). افترض أن cryptoExContract هو مثيل لـ CryptoExchange:

var DepositEvent = cryptoExContract.Deposit ({_ sender: userAddress}) ؛ DepositEvent.watch (function (err، نتيجة) {if (err) {console.log (err) return؛} // إلحاق تفاصيل result.args إلى UI}) لغة الشفرة: JavaScript (javascript)

إن تحسين كفاءة الحصول على جميع الأحداث للمستخدم هو سبب فهرسة معلمة المرسل للحدث: إيداع الحدث (uint256 مفهرس _ سوق ، عنوان مفهرس _ مرسل ، uint256 _amount ، uint256 _time).

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

var DepositEventAll = cryptoExContract.Deposit ({_ sender: userAddress}، {fromBlock: 0، toBlock: ‘latest’}) ؛ DepositEventAll.watch (function (err، نتيجة) {if (err) {console.log (err) return؛} // إلحاق تفاصيل result.args بواجهة المستخدم}) لغة الشفرة: JavaScript (javascript)

عندما يتم تقديم واجهة المستخدم ، يجب استدعاء DependEventAll.stopWatching ().

جانبا – المعلمات المفهرسة

يمكن فهرسة ما يصل إلى 3 معلمات. على سبيل المثال ، يحتوي معيار الرمز المميز المقترح على: حدث نقل (عنوان مفهرس _ من ، عنوان مفهرس _ إلى ، uint256 _value). هذا يعني أنه يمكن للواجهة الأمامية أن تراقب بكفاءة عمليات تحويل الرموز التي هي:

مُرسَل عن طريق عنوان tokenContract.Transfer ({_ from: senderAddress})
أو تلقيها عن طريق عنوان tokenContract.Transfer ({_ to: receiverAddress})
أو إرسالها عن طريق عنوان إلى عنوان محدد tokenContract.Transfer ({_ from: senderAddress، _to: receiverAddress})

استنتاج

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

بفضل آرون ديفيس وفينسنت جاريبي وجوزيف لوبين لتعليقاتهم على هذه المقالة.

مراجع

[1] يمكن لـ web3.js مراقبة المعاملة ليتم تضمينها في blockchain ، ثم إعادة تشغيل المعاملة في مثيل EVM ، للحصول على قيمة الإرجاع ، ولكن هذا قدر كبير من المنطق لإضافته إلى web3.js

[2] هناك تكاليف غاز تبلغ 375 لعملية LOG ، و 375 غازًا لكل موضوع ، ولكن عندما يتم تخزين العديد من البايتات ، فإن هذه التكاليف تمثل جزءًا ضئيلًا من التكلفة الإجمالية للتخزين.

[3] من الممكن تقديم براهين Merkle للسجلات ، لذلك إذا قدم كيان خارجي عقدًا بمثل هذا الإثبات ، يمكن للعقد التحقق من وجود السجل بالفعل داخل blockchain.