هذه المقالة هي الأولى في سلسلة الشيفرة المصدرية لـ Geth، ومن خلال هذه السلسلة، سنقوم ببناء إطار لدراسة تنفيذ Geth، حيث يمكن للمطورين البحث في الأجزاء التي تهمهم بناءً على هذا الإطار. تتكون هذه السلسلة من ست مقالات، وفي المقالة الأولى، سيتم دراسة هيكل تصميم عميل التنفيذ Geth وعملية بدء تشغيل عقدة Geth. يتم تحديث شيفرة Geth بسرعة كبيرة، لذا قد تختلف الشيفرة التي ستراها لاحقًا، ولكن التصميم العام يبقى متسقًا إلى حد كبير، ويمكن قراءة الشيفرة الجديدة بنفس الطريقة.
01\عميل إيثريوم
قبل ترقية The Merge ، كان لدى إيثريوم عميل واحد فقط، وكان هذا العميل مسؤولاً عن تنفيذ المعاملات، كما أنه كان مسؤولاً عن توافق blockchain، لضمان إنتاج كتل جديدة بترتيب معين. بعد ترقية The Merge ، تم تقسيم عميل إيثريوم إلى طبقة التنفيذ وطبقة التوافق، حيث تكون طبقة التنفيذ مسؤولة عن تنفيذ المعاملات وصيانة الحالة والبيانات، بينما تكون طبقة التوافق مسؤولة عن تنفيذ وظيفة التوافق، وتتواصل طبقة التنفيذ وطبقة التوافق عبر واجهة برمجة التطبيقات (API). لكل من طبقة التنفيذ وطبقة التوافق معاييره الخاصة، ويمكن للعملاء استخدام لغات مختلفة للتنفيذ، ولكن يجب أن تتوافق مع المعايير المقابلة، حيث أن Geth هو أحد تطبيقات عميل طبقة التنفيذ. تشمل تطبيقات عملاء طبقة التنفيذ وطبقة التوافق الرئيسية الحالية ما يلي:
طبقة التنفيذ
Geth: يتم صيانته من قبل فريق تموله مؤسسة إيثيريوم مباشرة، تم تطويره باستخدام لغة Go، وهو يُعترف به كأكثر عميل استقرارًا وموثوقية.
نذرمايند: تم تطويره وصيانته بواسطة فريق نذرمايند، تم تطويره بلغة C#، وحصل في البداية على تمويل من مؤسسة إيثيريوم ومجتمع غيتكوين.
Besu: تم تطويره في الأصل بواسطة فريق PegaSys التابع لـ ConsenSys، وهو الآن مشروع ضمن مجتمع Hyperledger، تم تطويره باستخدام لغة Java
إيريجون: تم تطويره وصيانته بواسطة فريق إيريجون، بدعم من مؤسسة إيثيريوم و BNB Chain. تم تفريعه من Geth في عام 2017، والهدف هو تحسين سرعة المزامنة وكفاءة القرص.
Reth: تم تطويره بقيادة Paradigm بلغة Rust، مع التركيز على النمذجة والأداء العالي، وقد اقترب الآن من النضج ويمكن استخدامه في بيئات الإنتاج.
طبقة التوافق
Prysm: تم تطويره بواسطة Prysmatic Labs، وهو واحد من أوائل عملاء طبقة التوافق لإيثريوم، تم تطويره بلغة Go، مع التركيز على القابلية للاستخدام والأمان، وقد حصل في البداية على تمويل من مؤسسة إيثريوم.
Lighthouse: مدعوم من فريق Sigma Prime، تم تطويره بلغة Rust، يركز على الأداء العالي والأمان على مستوى المؤسسات، مناسب لسيناريوهات الحمل العالي
Teku: تم تطويره في البداية بواسطة فريق PegaSys من ConsenSys، ثم أصبح جزءًا من مجتمع Hyperledger Besu، تم تطويره باستخدام لغة Java.
نيمبوس: تم تطويره وصيانته بواسطة فريق Status Network، تم تطويره بلغة Nim، مصمم خصيصًا للأجهزة ذات الموارد المحدودة (مثل الهواتف المحمولة وأجهزة إنترنت الأشياء) مع هدف تحقيق تشغيل خفيف الوزن في الأنظمة المدمجة.
02\مقدمة عن طبقة التنفيذ
يمكن اعتبار طبقة تنفيذ الإيثريوم كآلة حالة مدفوعة بالتداول، حيث أن الوظيفة الأساسية لطبقة التنفيذ هي تحديث بيانات الحالة من خلال تنفيذ المعاملات عبر EVM. بالإضافة إلى تنفيذ المعاملات، هناك أيضًا حفظ والتحقق من الكتل وبيانات الحالة، تشغيل شبكة P2P وصيانة مجموعة المعاملات وغيرها من الوظائف.
تتم معالجة المعاملات من قبل المستخدم (أو البرنامج) وفقًا للتنسيق المحدد بواسطة معايير طبقة التنفيذ لإيثريوم، ويحتاج المستخدم إلى توقيع المعاملة. إذا كانت المعاملة قانونية (الرقم التسلسلي متسلسل، التوقيع صحيح، رسوم الغاز كافية، المنطق التجاري صحيح)، فإن المعاملة ستُنفذ في النهاية بواسطة EVM، مما يؤدي إلى تحديث حالة شبكة إيثريوم. الحالة هنا تشير إلى مجموعة من الهياكل البيانية والبيانات وقواعد البيانات، بما في ذلك عناوين الحسابات الخارجية، عناوين العقود، أرصدة العناوين، بالإضافة إلى الكود والبيانات.
طبقة التنفيذ مسؤولة عن تنفيذ المعاملات والحفاظ على حالة المعاملات بعد التنفيذ، بينما طبقة الإجماع مسؤولة عن اختيار المعاملات التي سيتم تنفيذها. EVM هو دالة تحويل الحالة في هذه الآلة الحالة، حيث تأتي مدخلات الدالة من عدة مصادر، قد تأتي من معلومات الكتل الأخيرة المقدمة من طبقة الإجماع، أو قد تأتي من الكتل التي تم تنزيلها من شبكة p2p.
تتواصل طبقة الإجماع وطبقة التنفيذ عبر واجهة برمجة التطبيقات Engine API، وهي الوسيلة الوحيدة للتواصل بين طبقة التنفيذ وطبقة الإجماع. إذا حصلت طبقة الإجماع على حق إنشاء الكتل، فسوف تستخدم واجهة برمجة التطبيقات Engine API لجعل طبقة التنفيذ تنتج كتل جديدة، وإذا لم تحصل على حق إنشاء الكتل، فسوف تقوم بمزامنة أحدث الكتل لتسمح لطبقة التنفيذ بالتحقق منها وتنفيذها، وبالتالي الحفاظ على الإجماع مع شبكة الإيثيريوم بأكملها.
يمكن تقسيم الطبقة التنفيذية منطقيًا إلى 6 أجزاء:
EVM: مسؤول عن تنفيذ المعاملات، وتنفيذ المعاملات هو الطريقة الوحيدة لتعديل حالة العقدة.
التخزين: مسؤول عن تخزين الحالة وبيانات الكتل وما إلى ذلك
مجموعة المعاملات: تُستخدم لتخزين المعاملات المقدمة من المستخدمين مؤقتًا، وستنتشر عبر شبكة p2p بين عقود مختلفة
شبكة P2P: تستخدم لاكتشاف العقد ومزامنة المعاملات وتنزيل الكتل والمزيد
خدمة RPC: توفر القدرة على الوصول إلى العقدة، مثل إرسال المستخدمين للمعاملات إلى العقدة، والتفاعل بين طبقة الإجماع وطبقة التنفيذ.
BlockChain: مسؤول عن إدارة بيانات سلسلة الكتل الخاصة بالإيثيريوم
يوضح الشكل أدناه العمليات الرئيسية لطبقة التنفيذ ، بالإضافة إلى وظائف كل جزء:
بالنسبة لطبقة التنفيذ (هنا نناقش فقط العقدة الكاملة)، هناك ثلاثة عمليات رئيسية:
إذا كانت عقدة جديدة تنضم إلى الإيثريوم، تحتاج إلى مزامنة الكتل وبيانات الحالة من عقد أخرى عبر شبكة p2p، إذا كانت المزامنة كاملة، ستبدأ من الكتلة الأصلية لتنزيل الكتل واحدة تلو الأخرى، والتحقق من الكتل وإعادة بناء قاعدة بيانات الحالة من خلال EVM، إذا كانت المزامنة السريعة، ستتجاوز عملية التحقق من جميع الكتل، وتقوم بتحميل بيانات الحالة للنقطة المرجعية الأخيرة وبيانات الكتل التالية مباشرة.
إذا كانت العقدة قد تم مزامنتها بالفعل مع أحدث حالة ، فسوف تستمر في الحصول على الكتل الناتجة الأحدث من طبقة الإجماع عبر واجهة برمجة التطبيقات Engine والتحقق من الكتل ، ثم تنفيذ جميع المعاملات في الكتلة عبر EVM لتحديث قاعدة بيانات الحالة ، وكتابة الكتلة في السلسلة المحلية.
إذا كانت العقدة قد تم مزامنتها بالفعل إلى أحدث حالة، وحصلت层 التوافق على حق إنتاج الكتل، فإنها ستقوم من خلال واجهة برمجة التطبيقات Engine API بدفع层 التنفيذ لإنتاج أحدث كتلة، حيث يحصل层 التنفيذ على المعاملات من مجموعة المعاملات وينفذها، ثم يقوم بتجميعها في كتلة ويمررها عبر واجهة برمجة التطبيقات Engine API إلى层 التوافق، حيث تقوم层 التوافق ببث الكتلة إلى شبكة p2p الخاصة بها.
03\هيكل الشيفرة المصدرية
بنية كود go-ethereum كبيرة جدًا، لكن الكثير من الكود ينتمي إلى كود مساعد واختبارات وحدات، عند دراسة شفرة مصدر Geth، تحتاج فقط إلى التركيز على التنفيذ الأساسي للبروتوكول، وتعمل الوحدات المختلفة على النحو التالي. يجب التركيز بشكل خاص على الوحدات core و eth و ethdb و node و p2p و rlp و trie & triedb.
الحسابات: إدارة حسابات Ethereum ، بما في ذلك إنشاء أزواج المفاتيح العامة والخاصة ، والتحقق من التوقيع ، واشتقاق العنوان ، وما إلى ذلك
beacon: معالجة منطق التفاعل مع سلسلة الإشارة الخاصة بالإيثيريوم (Beacon Chain)، تدعم وظيفة الدمج (The Merge) بعد توافق إثبات الحصة (PoS).
بناء: بناء البرامج النصية وتكوينات التجميع (مثل Dockerfile ، دعم التجميع عبر الأنظمة الأساسية)
cmd: مدخل أداة سطر الأوامر، يحتوي على عدة أوامر فرعية
مشترك: أدوات عامة، مثل معالجة البايت، تحويل تنسيق العنوان، دوال رياضية
الإجماع: تعريف محرك الإجماع، بما في ذلك إثبات العمل السابق (Ethash) وإثبات الحصة الفردية (Clique) ومحرك Beacon وغيرها.
وحدة التحكم: توفر وحدة تحكم JavaScript تفاعلية، تتيح للمستخدمين التفاعل مباشرة مع عقدة Ethereum من خلال سطر الأوامر (مثل استدعاء واجهة برمجة تطبيقات Web3، إدارة الحسابات، الاستعلام عن بيانات blockchain)
core: منطق blockchain الأساسي، يعالج إدارة دورة حياة الكتل/المعاملات، آلة الحالة، حساب Gas، وغيرها.
التشفير: تنفيذ خوارزمية التشفير ، بما في ذلك المنحنى الإهليلجي (secp256k1) ، التجزئة (Keccak-256) ، التحقق من التوقيع
docs: وثائق (مثل معايير التصميم، توضيحات API)
eth: التنفيذ الكامل لبروتوكول شبكة إيثيريوم، بما في ذلك خدمات العقدة، مزامنة الكتل (مثل المزامنة السريعة، وضع الأرشيف)، بث المعاملات وغيرها
ethclient: مكتبة عميل Ethereum التي تقوم بتغليف واجهة JSON-RPC، لتوفير تفاعل مطوري Go مع عقدة Ethereum (مثل استعلام الكتل، إرسال المعاملات، نشر العقود)
ethdb: طبقة تجريد قاعدة البيانات، تدعم LevelDB و Pebble و قاعدة البيانات في الذاكرة، تخزن بيانات البلوكشين (الكتل، الحالة، المعاملات)
ethstats: يجمع ويبلغ عن حالة تشغيل العقدة إلى خدمة الإحصاءات، لمراقبة صحة الشبكة
الحدث: تنفيذ آلية الاشتراك في الأحداث والنشر، ودعم الاتصال غير المتزامن بين الوحدات الداخلية للعقدة (مثل وصول الكتلة الجديدة، تحديث مجموعة المعاملات)
graphql: يوفر واجهة GraphQL، يدعم الاستعلامات المعقدة (يحل محل بعض وظائف JSON-RPC)
داخلي：أدوات داخلية أو تعليمات برمجية تحد من الوصول الخارجي
log：نظام السجلات، يدعم إخراج السجلات على مستويات، وتسجيل السجلات السياقية
mertrics: جمع مؤشرات الأداء (دعم Prometheus)
miner: منطق متعلق بالتعدين، إنشاء كتل جديدة وتعبئة المعاملات (في سيناريو PoW)
node：إدارة خدمات العقدة، دمج بدء وتكوين وحدات p2p وRPC وقاعدة البيانات وغيرها.
p2p：تنفيذ بروتوكول الشبكة من نظير إلى نظير، يدعم اكتشاف العقدة، نقل البيانات، الاتصالات المشفرة
params：تعريف معلمات شبكة الإيثيريوم (الشبكة الرئيسية، شبكة الاختبار، تكوين الكتلة الأصلية)
rlp: تنفيذ بروتوكول تسلسل البيانات الخاص بالإيثيريوم RLP (السابقة المتكررة للطول) ، والذي يستخدم لترميز/فك ترميز الكتل والمعاملات وهياكل البيانات الأخرى.
rpc: تنفيذ واجهة JSON-RPC و IPC لتمكين البرامج الخارجية من التفاعل مع العقدة
الموقّع: إدارة توقيع المعاملات (تكامل المحفظة الصلبة)
اختبارات: اختبارات التكامل واختبارات الحالة، للتحقق من توافق البروتوكول
trie &tryedb: تنفيذ شجرة Merkle Patricia Trie للتخزين الفعال وإدارة حالة الحساب وتخزين العقد
04\تقسيم وحدة التنفيذ
هناك نوعان من الوصول الخارجي إلى عقدة Geth، أحدهما عبر RPC والآخر عبر Console. RPC مناسب للاستخدام من قبل المستخدمين الخارجيين، بينما Console مناسب لمشرفي العقد. ولكن سواء كان الوصول عبر RPC أو Console، يتم استخدام القدرات المعبأة داخليًا، والتي تم بناؤها بطريقة طبقية.
الطبقة الخارجية هي واجهة برمجة التطبيقات (API) التي تستخدم للوصول إلى قدرات العقدة الخارجية، واجهة برمجة التطبيقات (Engine API) تستخدم للتواصل بين طبقة التنفيذ وطبقة الإجماع، واجهة برمجة التطبيقات (Eth API) تستخدم لإرسال المعاملات من قبل المستخدمين الخارجيين أو البرامج، والحصول على معلومات الكتلة، وواجهة برمجة التطبيقات (Net API) تستخدم للحصول على حالة شبكة P2P وغيرها. على سبيل المثال، إذا قام المستخدم بإرسال معاملة عبر واجهة برمجة التطبيقات، فإن هذه المعاملة ستُقدّم في النهاية إلى مجموعة المعاملات، ويتم إدارتها من خلال مجموعة المعاملات، ومثال آخر هو إذا احتاج المستخدم إلى الحصول على بيانات كتلة، فإنه يحتاج إلى استدعاء قدرات قاعدة البيانات للحصول على الكتلة المقابلة.
في الطبقة التالية من واجهة برمجة التطبيقات ، يتضمن تنفيذ الوظائف الأساسية تجميع المعاملات ، وحزم المعاملات ، وإنتاج الكتل ، ومزامنة الكتلة والحالة ، وما إلى ذلك. تحتاج هذه الوظائف إلى الاعتماد على قدرات المستوى الأدنى ، مثل قدرة شبكة P2P على مزامنة تجمعات المعاملات والكتل والحالات ، ويجب التحقق من صحة إنشاء الكتل والكتل المتزامنة من العقد الأخرى قبل كتابتها إلى قاعدة البيانات المحلية ، والتي تحتاج إلى الاعتماد على قدرات EVM وتخزين البيانات.
الهيكل البياني الأساسي لطبقة التنفيذ
الإيثريوم
هيكل Ethereum في eth/backend.go هو تجريد لبروتوكول Ethereum بأكمله، ويتضمن بشكل أساسي المكونات الرئيسية في Ethereum، لكن EVM هو استثناء، حيث يتم تنفيذه في كل مرة يتم فيها معالجة صفقة، ولا يحتاج إلى التهيئة مع العقدة بأكملها. يشير Ethereum في النص أدناه إلى هذه البنية.
اكتب بنية Ethereum { // تكوين Ethereum ، بما في ذلك تكوين السلسلة \ * ethconfig. تكوين // تجمع المعاملات ، بعد إرسال معاملة المستخدم ، انتقل إلى تجمع المعاملات txPool \ * txpool. TxPool // تستخدم لتتبع وإدارة المعاملات المحلية localTxTracker \ * المحلية. TxTracker // هيكل سلسلة الكتل سلسلة الكتل \ * الأساسية. BlockChain // هو المكون الأساسي لطبقة شبكة عقدة Ethereum ، وهو مسؤول عن التعامل مع جميع الاتصالات مع العقد الأخرى ، بما في ذلك مزامنة الكتلة ، وبث المعاملات ، وتلقيها ، بالإضافة إلى إدارة معالج اتصال عقدة النظير // المسؤول عن اكتشاف العقدة وإدارة مصدر العقدة discmix \ * enode. FairMix // مسؤول عن التخزين المستمر لسلسلة بيانات blockchainDb ethdb. قاعدة البيانات // مسؤول عن التعامل مع نشر والاشتراك في الأحداث الداخلية المختلفة ل eventMux \ * event. TypeMux // إجماع المحرك. المحرك // إدارة حسابات المستخدمين ومفاتيح accountManager *الحسابات. مدير // إدارة عوامل تصفية السجل وتصفية قطعة الخرائط \ * تصفية الخرائط. FilterMaps // قناة لإيقاف تشغيل filterMaps بأمان ، مما يضمن تنظيف الموارد بشكل صحيح عند إيقاف تشغيل العقد closeFilterMaps chan chan struct{} // توفير دعم الواجهة الخلفية لواجهة برمجة تطبيقات RPC APIBackend *EthAPIBackend // ضمن PoS ، اعمل مع محرك الإجماع للتحقق من صحة عامل منجم الكتلة \ * عامل منجم. عامل منجم // أقل سعر للغاز تقبله العقدة هو gasPrice \ * كبير. Int // معرف شبكة معرف الشبكة uint64 // توفير خدمات RPC المتعلقة بالشبكة ، مما يسمح بالاستعلام عن حالة الشبكة من خلال RPC netRPCService *ethapi. NetAPI // إدارة اتصالات شبكة P2P ، والتعامل مع اكتشاف العقدة وإنشاء الاتصال ، وتوفير وظائف نقل الشبكة الأساسية p2pServer \ * p2p. الخادم // حماية الوصول المتزامن إلى مزامنة قفل الحقول القابلة للتغيير. RWMutex // يتتبع ما إذا كانت العقدة معطلة بأمان ويساعد على استعادة shutdownTracker بعد إيقاف تشغيل غير طبيعي \ * shutdowncheck. ShutdownTracker }
عقدة
في node/node.go ، تعتبر Node هي بنية بيانات أساسية أخرى، تعمل كحاوية، مسؤولة عن إدارة وتنسيق تشغيل الخدمات المختلفة. في الهيكل أدناه، يجب الانتباه إلى حقل lifecycles، حيث يتم استخدام Lifecycle لإدارة دورة حياة الوظائف الداخلية. على سبيل المثال، يتطلب التجريد الخاص بـ Ethereum أعلاه الاعتماد على Node لبدء التشغيل، والتسجيل في lifecycles. بهذه الطريقة، يمكن فصل الوظائف المحددة عن تجريد العقدة، مما يعزز قابلية التوسع للهيكل بأكمله، ويجب تمييز هذه Node عن Node في devp2p.
اكتب بنية العقدة { eventmux *event. TypeMux التكوين \ * التكوين // مدير الحساب ، المسؤول عن إدارة المحافظ والحسابات accman \ * الحسابات. سجل سجل المدير. Logger keyDir string keyDirTemp bool dirLock *flock. قطيع وقف chan struct{} // p2p خادم مثيل الشبكة *p2p. بدء تشغيل الخادممزامنة StopLock. Mutex // تتبع حالة دورة حياة العقدة (تمت تهيئتها ، قيد التشغيل ، مغلقة) مزامنة قفل int. Mutex // جميع الخلفيات والخدمات ودورات حياة الخدمات الإضافية المسجلة []دورة الحياة // قائمة واجهات برمجة التطبيقات المتاحة حاليا rpcAPIs []rpc. API // طرق وصول مختلفة ل RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Server databases map[*closeTrackingDB]struct{} }
إذا نظرنا إلى طبقة تنفيذ Ethereum من بعد تجريدي ، فإن Ethereum ، ككمبيوتر عالمي ، يحتاج إلى تضمين ثلاثة أجزاء ، الشبكة والحوسبة والتخزين ، ثم المكونات المقابلة لهذه الأجزاء الثلاثة في طبقة تنفيذ Ethereum هي:
الشبكة: devp2p
حساب: EVM
التخزين: ethdb
devp2p
الإيثيريوم في جوهره هو نظام موزع، حيث كل عقدة متصلة بعقد أخرى عبر شبكة p2p. تنفيذ بروتوكول شبكة p2p في الإيثيريوم هو devp2p.
يحتوي devp2p على وظيفتين أساسيتين، الأولى هي اكتشاف العقدة، مما يسمح للعقدة بإنشاء اتصال مع عقد أخرى عند الانضمام إلى الشبكة؛ والثانية هي خدمة نقل البيانات، حيث يمكن تبادل البيانات بعد إنشاء اتصال مع العقد الأخرى.
في ملف p2p/enode/node.go، تمثل بنية Node عقدة في شبكة p2p، حيث يتم تخزين أزواج المفتاح والقيمة لمعلومات العقدة التفصيلية في بنية enr.Record، بما في ذلك معلومات الهوية (خوارزمية التوقيع المستخدمة لهوية العقدة، المفتاح العام)، معلومات الشبكة (عنوان IP، رقم المنفذ)، معلومات البروتوكولات المدعومة (مثل دعم بروتوكول eth/68 وبروتوكول snap) ومعلومات مخصصة أخرى، وتشفّر هذه المعلومات بطريقة RLP، والمعايير المحددة تعرف في eip-778:
type Node struct { // سجل العقدة، يحتوي على خصائص العقدة المختلفة r enr.Record // المعرف الفريد للعقدة، بطول 32 بايت id ID // اسم المضيف لتتبع اسم DNS للعقدة hostname string // عنوان IP للعقدة ip netip.Addr // منفذ UDP udp uint16 // منفذ TCP tcp uint16 }// enr.Recordtype Record struct { // الرقم التسلسلي seq uint64 // التوقيع signature []byte // السجل المشفر باستخدام RLP raw []byte // قائمة مرتبة من جميع أزواج المفاتيح pairs []pair }
هيكل Table في p2p/discover/table.go هو الهيكل البياني الأساسي لبروتوكول اكتشاف العقدة الذي ينفذه devp2p، وهو ينفذ جدول تجزئة موزع مشابه لـ Kademlia، لتخزين وإدارة معلومات العقد في الشبكة.
printf( "اكتب بنية الجدول { مزامنة mutex. Mutex // فهرس دلاء العقدة المعروفة حسب المسافة [nBuckets]*bucket // حضانة عقدة التمهيد []*enode. Node rand reseedingRandom ips netutil. جدول إعادة التحقق من صحة DistinctNetSet إعادة التحقق // قاعدة بيانات العقد المعروفة ديسيبل *enode. DB صافي النقل cfg سجل التكوين. Logger // يعالج بشكل دوري الأحداث المختلفة في الشبكة refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // إضافة وإزالة واجهات العقد nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func( \ * دلو ، \ * tableNode)} العالم!" );
إيثدب
تكتمل ethdb تجريد تخزين بيانات الإيثريوم، مما يوفر واجهة تخزين موحدة، يمكن أن تكون قاعدة البيانات المحددة في الأسفل هي leveldb أو pebble أو أي قاعدة بيانات أخرى. يمكن أن يكون هناك الكثير من التوسعات، طالما يتم الحفاظ على الاتساق على مستوى الواجهة.
بعض البيانات (مثل بيانات الكتل) يمكن قراءتها وكتابتها مباشرة عبر واجهة ethdb إلى قاعدة البيانات الأساسية، بينما يتم إنشاء واجهات تخزين البيانات الأخرى على أساس ethdb، على سبيل المثال، يحتوي جزء كبير من البيانات في قاعدة البيانات على بيانات الحالة، وستُنظم هذه البيانات في هيكل MPT، والذي يتوافق في Geth مع تنفيذ trie، خلال عملية تشغيل العقدة، ستنتج بيانات trie العديد من الحالات الوسيطة، ولا يمكن استدعاء هذه البيانات مباشرة عبر ethdb للقراءة والكتابة، بل تحتاج إلى triedb لإدارة هذه البيانات والحالات الوسيطة، وأخيرًا يتم استخدامها عبر ethdb للتخزين الدائم.
تم تعريف واجهة قدرات القراءة والكتابة لقاعدة البيانات الأساسية في ethdb/database.go، ولكن لم يتم تضمين التنفيذ الفعلي، حيث سيتم تنفيذ التنفيذ الفعلي من قبل قواعد البيانات المختلفة نفسها. مثل leveldb أو pebble. تم تعريف واجهتين لقراءة وكتابة البيانات في Database، حيث تُستخدم واجهة KeyValueStore لتخزين البيانات النشطة، التي قد تتغير بشكل متكرر، مثل الكتل الأخيرة، والحالات، وما إلى ذلك. بينما تُستخدم واجهة AncientStore لمعالجة بيانات الكتل التاريخية، والتي نادراً ما تتغير بمجرد كتابتها.
EVM هو دالة تحويل الحالة لهذه الحالة آلة إيثريوم، جميع تحديثات بيانات الحالة يمكن أن تتم فقط من خلال EVM، يمكن أن تستقبل شبكة P2P معلومات المعاملات والكتل، بعد معالجة هذه المعلومات بواسطة EVM ستصبح جزءًا من قاعدة بيانات الحالة. EVM تخفي اختلافات الأجهزة الأساسية، مما يسمح للبرامج بالتنفيذ على EVM على منصات مختلفة للحصول على نتائج متسقة. هذه طريقة تصميم ناضجة جداً، JVM في لغة Java هو تصميم مشابه.
تتكون تنفيذ EVM من ثلاثة مكونات رئيسية، حيث يقوم هيكل EVM الموجود في core/vm/evm.go بتعريف الهيكل العام لـ EVM والاعتمادات، بما في ذلك سياق التنفيذ، والاعتمادات على قاعدة بيانات الحالة، وما إلى ذلك؛ بينما يقوم هيكل EVMInterpreter الموجود في core/vm/interpreter.go بتعريف تنفيذ المترجم، المسؤول عن تنفيذ بايت كود EVM؛ ويقوم هيكل Contract الموجود في core/vm/contract.go بتغليف المعلمات المحددة لاستدعاء العقد، بما في ذلك المستدعي، رمز العقد، المدخلات، وما إلى ذلك، كما يتم تعريف جميع رموز العمليات الحالية في core/vm/opcodes.go:
هيكل EVMtype EVM { // سياق الكتلة ، يحتوي على معلومات متعلقة بالكتلة سياق BlockContext // سياق المعاملة ، يحتوي على معلومات متعلقة بالمعاملة TxContext // قاعدة بيانات الحالة ، تستخدم للوصول إلى حالة الحساب وتعديلها StateDB StateDB // عمق المكالمة الحالي int // معلمة تكوين السلسلة chainConfig \ * params. سلسلة ChainConfig معلمات القواعد. القواعد // تكوين EVM // مترجم الرمز الثانوي *EVMInterpreter // إحباط علامة التنفيذ إحباط ذري. Bool callGasTemp uint64 // precompiles map[common. العنوان]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // أشر إلى مثيل EVM الذي ينتمي إليه evm *EVM // Opcode Jump Table *JumpTable // مثيل Keccak256 hasher ، شارك تشفير hasher بين رموز التشغيل. KeccakState // Keccak256 تجزئة نتيجة العازلة hasherBuf المشتركة. تجزئة // سواء كان وضع القراءة فقط ، لا يسمح بتعديل الحالة في وضع القراءة فقط readOnly bool // يتم استخدام بيانات الإرجاع لآخر CALL لإعادة الاستخدام اللاحقة بيانات الإرجاع [] بايت } نوع بنية العقد { // عنوان المتصل الشائع. العنوان // عنوان العقد العنوان المشترك. عنوان jumpdests map[common. Hash]bitvec تحليل bitvec // رمز Bytecode للعقد []byte // Code hash CodeHash شائع. تجزئة // إدخال المكالمة [] بايت // ما إذا كان سيتم نشر IsDeployment bool للعقد // ما إذا كان سيتم استدعاء IsSystemCall bool // غاز الغاز المتاح uint64 // مقدار ETH المرتبط بقيمة المكالمة \ * uint256. إنت }
تنفيذ وحدات أخرى
تتم وظيفة طبقة التنفيذ من خلال طريقة الطبقات، حيث يتم بناء الوحدات والوظائف الأخرى على أساس هذه المكونات الثلاثة الأساسية. هنا نعرض بعض الوحدات الأساسية.
توجد في eth/protocols تنفيذات بروتوكولات الشبكة الند للند الحالية للإيثيريوم. هناك بروتوكولات فرعية eth/68 و snap، وهذه البروتوكولات الفرعية مبنية على devp2p.
eth/68 هو البروتوكول الأساسي للإيثريوم، اسم البروتوكول هو eth، و68 هو رقم إصداره، ثم تم تنفيذ وظائف مثل حوض المعاملات (TxPool)، مزامنة الكتل (Downloader) ومزامنة المعاملات (Fetcher) على أساس هذا البروتوكول. بروتوكول snap يُستخدم عند انضمام عقدة جديدة إلى الشبكة لمزامنة الكتل وبيانات الحالة بسرعة، مما يمكن أن يقلل بشكل كبير من وقت بدء العقدة الجديدة.
يقدم ethdb القدرة على القراءة والكتابة لقاعدة البيانات الأساسية، ونظرًا لوجود العديد من هياكل البيانات المعقدة في بروتوكول الإيثريوم، فإنه لا يمكن إدارة هذه البيانات مباشرة من خلال ethdb، لذلك تم تنفيذ rawdb و statedb على ethdb لإدارة بيانات الكتلة والحالة على التوالي.
EVM تمر عبر جميع العمليات الرئيسية، سواء كان ذلك في بناء الكتل أو التحقق من الكتل، يحتاج إلى تنفيذ المعاملات باستخدام EVM.
05\عملية بدء تشغيل عقدة Geth
ستقسم عملية بدء Geth إلى مرحلتين، المرحلة الأولى ستقوم بتهيئة المكونات والموارد اللازمة لتشغيل العقدة، المرحلة الثانية ستقوم بتشغيل العقدة رسميًا، ثم تقديم الخدمة للآخرين.
eth/ethconfig/config.go: تهيئة مثيل محرك التوافق (محرك التوافق هنا لا يشارك فعليًا في التوافق، بل يقوم فقط بالتحقق من نتائج طبقة التوافق، بالإضافة إلى معالجة طلبات سحب المدققين)
core / blockchain.go: تهيئة blockchain
core / filterMaps.go: تهيئة خرائط التصفية
core/txpool/blobpool/blobpool.go: تهيئة مجموعة معاملات البلوكتشين
core/txpool/legacypool/legacypool.go: تهيئة حوض المعاملات العادية
cord/txpool/locals/tx_tracker.go: تتبع المعاملات المحلية (تحتاج إلى تكوين لتمكين تتبع المعاملات المحلية، ستتم معالجة المعاملات المحلية ذات الأولوية الأعلى)
eth/handler.go: تهيئة مثيل Handler للبروتوكول
miner/miner.go: وحدة تجميع المعاملات المُعَينة (وحدة التعدين الأصلية)
eth/api_backend.go: إنشاء مثيل لخدمة RPC
eth/gasprice/gasprice.go: إنشاء خدمة استعلام عن أسعار الغاز
عقدة/node.go(RegisterLifecycle): تسجيل دورة حياة المكونات المختلفة
cmd/utils/flags.go(RegisterFilterAPI): تسجيل واجهة برمجة تطبيقات RPC لتصفية
cmd/utils/flags.go(RegisterGraphQLService): تسجيل واجهة برمجة التطبيقات GraphQL RPC (إذا تم تكوينها)
cmd/utils/flags.go(RegisterEthStatsService): تسجيل واجهة برمجة تطبيقات RPC لـ EthStats (إذا تم تكوينها)
eth/catalyst/api.go: تسجيل واجهة برمجة تطبيقات المحرك
سيتم الانتهاء من تهيئة العقدة في makeFullNode الموجود في cmd/geth/config.go، مع التركيز على تهيئة الوحدات الثلاثة التالية
في الخطوة الأولى، سيتم تهيئة بنية Node في node/node.go، وهو حاوية العقدة بأكملها، حيث تحتاج جميع الوظائف إلى العمل داخل هذه الحاوية. في الخطوة الثانية، سيتم تهيئة بنية Ethereum، التي تشمل تنفيذ مجموعة متنوعة من الوظائف الأساسية لـ Ethereum، كما يجب تسجيل Etherereum في العقدة. الخطوة الثالثة هي تسجيل واجهة برمجة التطبيقات Engine في العقدة.
إن تهيئة العقدة تعني إنشاء مثيل عقدة، ثم تهيئة خادم p2p، وإدارة الحسابات، بالإضافة إلى بروتوكولات منافذ http وغيرها التي تم الكشف عنها للخارج.
ستكون初始化 Ethereum أكثر تعقيدًا بكثير، حيث يتم初始化 معظم الوظائف الأساسية هنا. أولاً، سيتم初始化 ethdb، وتحميل تكوين السلسلة من التخزين، ثم إنشاء محرك الإجماع. لن يقوم محرك الإجماع هنا بتنفيذ عمليات الإجماع، بل سيقوم فقط بالتحقق من النتائج التي تم إرجاعها من طبقة الإجماع، وإذا حدثت طلبات سحب في طبقة الإجماع، فسيتم أيضًا إكمال عمليات السحب الفعلية هنا. ثم يتم تهيئة هيكل سلسلة الكتل ومسبح المعاملات.
بعد الانتهاء من كل هذه الأمور، سيتم تهيئة handler، حيث إن handler هو مدخل معالجة جميع طلبات الشبكة الند للند، بما في ذلك مزامنة المعاملات، وتنزيل الكتل، وغيرها، وهو المكون الرئيسي لتحقيق التشغيل اللامركزي على الإيثريوم. بعد الانتهاء من كل هذه الأمور، سيتم تسجيل بعض البروتوكولات الفرعية التي تم تنفيذها على أساس devp2p، مثل eth/68 و snap، في حاوية Node، وأخيرًا سيتم تسجيل Ethereum كدورة حياة في حاوية Node، مما يعني أن تهيئة Ethereum قد اكتملت.
أخيرًا، كانت عملية تهيئة واجهة برمجة التطبيقات (API) الخاصة بمحرك (Engine) بسيطة نسبيًا، حيث تم تسجيل واجهة برمجة التطبيقات (API) الخاصة بمحرك (Engine) في العقدة (Node). وبذلك، اكتملت عملية تهيئة العقدة (Node) بالكامل.
عقدة启动
بعد الانتهاء من تهيئة العقدة، يجب بدء العقدة. إن عملية بدء العقدة بسيطة نسبيًا، كل ما يتعين عليك فعله هو بدء جميع خدمات RPC المسجلة و Lifecycle، عندها يمكن للعقدة تقديم الخدمات للعالم الخارجي.
06\ملخص
قبل فهم تنفيذ طبقة التنفيذ في الإيثيريوم بعمق، من الضروري الحصول على رؤية شاملة عن الإيثيريوم. يمكن اعتبار الإيثيريوم ككل كآلة حالة مدفوعة بالمعاملات، حيث تتولى طبقة التنفيذ مسؤولية تنفيذ المعاملات وتغيير الحالة، بينما تتحمل طبقة الإجماع مسؤولية دفع طبقة التنفيذ للعمل، بما في ذلك جعل طبقة التنفيذ تنتج كتل، وتحديد ترتيب المعاملات، والتصويت على الكتل، وضمان حصول الكتل على النهائية. نظرًا لأن هذه الآلة الحالة لامركزية، فهي بحاجة إلى التواصل مع عقدة أخرى من خلال شبكة p2p للحفاظ على توافق بيانات الحالة.
لا تتحمل طبقة التنفيذ مسؤولية تحديد ترتيب المعاملات، بل تركز على تنفيذ المعاملات وتسجيل التغييرات في الحالة بعد التنفيذ. هناك شكلان من التسجيل هنا، أحدهما هو تسجيل جميع التغييرات في الحالة على شكل كتل، والآخر هو تسجيل الحالة الحالية في قاعدة البيانات. في الوقت نفسه، تعتبر طبقة التنفيذ مدخل المعاملات، من خلال تجمع المعاملات لتخزين المعاملات التي لم يتم تضمينها بعد في الكتل. إذا كانت هناك عقد أخرى بحاجة إلى الحصول على البيانات حول الكتل والحالة والمعاملات، ستقوم طبقة التنفيذ بإرسال هذه المعلومات عبر شبكة نظير إلى نظير.
بالنسبة لطبقة التنفيذ، هناك ثلاثة وحدات أساسية: الحساب، التخزين، والشبكة. الحساب يتوافق مع تنفيذ EVM، بينما التخزين يتوافق مع تنفيذ ethdb، والشبكة تتوافق مع تنفيذ devp2p. بعد الحصول على هذا الفهم الشامل، يمكنك التعمق في فهم كل وحدة فرعية دون أن تضيع في التفاصيل المحددة.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
إثيريوم عميل رئيسي: الهيكل العام لـ Geth
هذه المقالة هي الأولى في سلسلة الشيفرة المصدرية لـ Geth، ومن خلال هذه السلسلة، سنقوم ببناء إطار لدراسة تنفيذ Geth، حيث يمكن للمطورين البحث في الأجزاء التي تهمهم بناءً على هذا الإطار. تتكون هذه السلسلة من ست مقالات، وفي المقالة الأولى، سيتم دراسة هيكل تصميم عميل التنفيذ Geth وعملية بدء تشغيل عقدة Geth. يتم تحديث شيفرة Geth بسرعة كبيرة، لذا قد تختلف الشيفرة التي ستراها لاحقًا، ولكن التصميم العام يبقى متسقًا إلى حد كبير، ويمكن قراءة الشيفرة الجديدة بنفس الطريقة.
01\عميل إيثريوم
قبل ترقية The Merge ، كان لدى إيثريوم عميل واحد فقط، وكان هذا العميل مسؤولاً عن تنفيذ المعاملات، كما أنه كان مسؤولاً عن توافق blockchain، لضمان إنتاج كتل جديدة بترتيب معين. بعد ترقية The Merge ، تم تقسيم عميل إيثريوم إلى طبقة التنفيذ وطبقة التوافق، حيث تكون طبقة التنفيذ مسؤولة عن تنفيذ المعاملات وصيانة الحالة والبيانات، بينما تكون طبقة التوافق مسؤولة عن تنفيذ وظيفة التوافق، وتتواصل طبقة التنفيذ وطبقة التوافق عبر واجهة برمجة التطبيقات (API). لكل من طبقة التنفيذ وطبقة التوافق معاييره الخاصة، ويمكن للعملاء استخدام لغات مختلفة للتنفيذ، ولكن يجب أن تتوافق مع المعايير المقابلة، حيث أن Geth هو أحد تطبيقات عميل طبقة التنفيذ. تشمل تطبيقات عملاء طبقة التنفيذ وطبقة التوافق الرئيسية الحالية ما يلي:
طبقة التنفيذ
طبقة التوافق
02\مقدمة عن طبقة التنفيذ
يمكن اعتبار طبقة تنفيذ الإيثريوم كآلة حالة مدفوعة بالتداول، حيث أن الوظيفة الأساسية لطبقة التنفيذ هي تحديث بيانات الحالة من خلال تنفيذ المعاملات عبر EVM. بالإضافة إلى تنفيذ المعاملات، هناك أيضًا حفظ والتحقق من الكتل وبيانات الحالة، تشغيل شبكة P2P وصيانة مجموعة المعاملات وغيرها من الوظائف.
تتم معالجة المعاملات من قبل المستخدم (أو البرنامج) وفقًا للتنسيق المحدد بواسطة معايير طبقة التنفيذ لإيثريوم، ويحتاج المستخدم إلى توقيع المعاملة. إذا كانت المعاملة قانونية (الرقم التسلسلي متسلسل، التوقيع صحيح، رسوم الغاز كافية، المنطق التجاري صحيح)، فإن المعاملة ستُنفذ في النهاية بواسطة EVM، مما يؤدي إلى تحديث حالة شبكة إيثريوم. الحالة هنا تشير إلى مجموعة من الهياكل البيانية والبيانات وقواعد البيانات، بما في ذلك عناوين الحسابات الخارجية، عناوين العقود، أرصدة العناوين، بالإضافة إلى الكود والبيانات.
طبقة التنفيذ مسؤولة عن تنفيذ المعاملات والحفاظ على حالة المعاملات بعد التنفيذ، بينما طبقة الإجماع مسؤولة عن اختيار المعاملات التي سيتم تنفيذها. EVM هو دالة تحويل الحالة في هذه الآلة الحالة، حيث تأتي مدخلات الدالة من عدة مصادر، قد تأتي من معلومات الكتل الأخيرة المقدمة من طبقة الإجماع، أو قد تأتي من الكتل التي تم تنزيلها من شبكة p2p.
تتواصل طبقة الإجماع وطبقة التنفيذ عبر واجهة برمجة التطبيقات Engine API، وهي الوسيلة الوحيدة للتواصل بين طبقة التنفيذ وطبقة الإجماع. إذا حصلت طبقة الإجماع على حق إنشاء الكتل، فسوف تستخدم واجهة برمجة التطبيقات Engine API لجعل طبقة التنفيذ تنتج كتل جديدة، وإذا لم تحصل على حق إنشاء الكتل، فسوف تقوم بمزامنة أحدث الكتل لتسمح لطبقة التنفيذ بالتحقق منها وتنفيذها، وبالتالي الحفاظ على الإجماع مع شبكة الإيثيريوم بأكملها.
يمكن تقسيم الطبقة التنفيذية منطقيًا إلى 6 أجزاء:
يوضح الشكل أدناه العمليات الرئيسية لطبقة التنفيذ ، بالإضافة إلى وظائف كل جزء:
بالنسبة لطبقة التنفيذ (هنا نناقش فقط العقدة الكاملة)، هناك ثلاثة عمليات رئيسية:
03\هيكل الشيفرة المصدرية
بنية كود go-ethereum كبيرة جدًا، لكن الكثير من الكود ينتمي إلى كود مساعد واختبارات وحدات، عند دراسة شفرة مصدر Geth، تحتاج فقط إلى التركيز على التنفيذ الأساسي للبروتوكول، وتعمل الوحدات المختلفة على النحو التالي. يجب التركيز بشكل خاص على الوحدات core و eth و ethdb و node و p2p و rlp و trie & triedb.
04\تقسيم وحدة التنفيذ
هناك نوعان من الوصول الخارجي إلى عقدة Geth، أحدهما عبر RPC والآخر عبر Console. RPC مناسب للاستخدام من قبل المستخدمين الخارجيين، بينما Console مناسب لمشرفي العقد. ولكن سواء كان الوصول عبر RPC أو Console، يتم استخدام القدرات المعبأة داخليًا، والتي تم بناؤها بطريقة طبقية.
الطبقة الخارجية هي واجهة برمجة التطبيقات (API) التي تستخدم للوصول إلى قدرات العقدة الخارجية، واجهة برمجة التطبيقات (Engine API) تستخدم للتواصل بين طبقة التنفيذ وطبقة الإجماع، واجهة برمجة التطبيقات (Eth API) تستخدم لإرسال المعاملات من قبل المستخدمين الخارجيين أو البرامج، والحصول على معلومات الكتلة، وواجهة برمجة التطبيقات (Net API) تستخدم للحصول على حالة شبكة P2P وغيرها. على سبيل المثال، إذا قام المستخدم بإرسال معاملة عبر واجهة برمجة التطبيقات، فإن هذه المعاملة ستُقدّم في النهاية إلى مجموعة المعاملات، ويتم إدارتها من خلال مجموعة المعاملات، ومثال آخر هو إذا احتاج المستخدم إلى الحصول على بيانات كتلة، فإنه يحتاج إلى استدعاء قدرات قاعدة البيانات للحصول على الكتلة المقابلة.
في الطبقة التالية من واجهة برمجة التطبيقات ، يتضمن تنفيذ الوظائف الأساسية تجميع المعاملات ، وحزم المعاملات ، وإنتاج الكتل ، ومزامنة الكتلة والحالة ، وما إلى ذلك. تحتاج هذه الوظائف إلى الاعتماد على قدرات المستوى الأدنى ، مثل قدرة شبكة P2P على مزامنة تجمعات المعاملات والكتل والحالات ، ويجب التحقق من صحة إنشاء الكتل والكتل المتزامنة من العقد الأخرى قبل كتابتها إلى قاعدة البيانات المحلية ، والتي تحتاج إلى الاعتماد على قدرات EVM وتخزين البيانات.
الهيكل البياني الأساسي لطبقة التنفيذ
الإيثريوم
هيكل Ethereum في eth/backend.go هو تجريد لبروتوكول Ethereum بأكمله، ويتضمن بشكل أساسي المكونات الرئيسية في Ethereum، لكن EVM هو استثناء، حيث يتم تنفيذه في كل مرة يتم فيها معالجة صفقة، ولا يحتاج إلى التهيئة مع العقدة بأكملها. يشير Ethereum في النص أدناه إلى هذه البنية.
اكتب بنية Ethereum { // تكوين Ethereum ، بما في ذلك تكوين السلسلة \ * ethconfig. تكوين // تجمع المعاملات ، بعد إرسال معاملة المستخدم ، انتقل إلى تجمع المعاملات txPool \ * txpool. TxPool // تستخدم لتتبع وإدارة المعاملات المحلية localTxTracker \ * المحلية. TxTracker // هيكل سلسلة الكتل سلسلة الكتل \ * الأساسية. BlockChain // هو المكون الأساسي لطبقة شبكة عقدة Ethereum ، وهو مسؤول عن التعامل مع جميع الاتصالات مع العقد الأخرى ، بما في ذلك مزامنة الكتلة ، وبث المعاملات ، وتلقيها ، بالإضافة إلى إدارة معالج اتصال عقدة النظير // المسؤول عن اكتشاف العقدة وإدارة مصدر العقدة discmix \ * enode. FairMix // مسؤول عن التخزين المستمر لسلسلة بيانات blockchainDb ethdb. قاعدة البيانات // مسؤول عن التعامل مع نشر والاشتراك في الأحداث الداخلية المختلفة ل eventMux \ * event. TypeMux // إجماع المحرك. المحرك // إدارة حسابات المستخدمين ومفاتيح accountManager *الحسابات. مدير // إدارة عوامل تصفية السجل وتصفية قطعة الخرائط \ * تصفية الخرائط. FilterMaps // قناة لإيقاف تشغيل filterMaps بأمان ، مما يضمن تنظيف الموارد بشكل صحيح عند إيقاف تشغيل العقد closeFilterMaps chan chan struct{} // توفير دعم الواجهة الخلفية لواجهة برمجة تطبيقات RPC APIBackend *EthAPIBackend // ضمن PoS ، اعمل مع محرك الإجماع للتحقق من صحة عامل منجم الكتلة \ * عامل منجم. عامل منجم // أقل سعر للغاز تقبله العقدة هو gasPrice \ * كبير. Int // معرف شبكة معرف الشبكة uint64 // توفير خدمات RPC المتعلقة بالشبكة ، مما يسمح بالاستعلام عن حالة الشبكة من خلال RPC netRPCService *ethapi. NetAPI // إدارة اتصالات شبكة P2P ، والتعامل مع اكتشاف العقدة وإنشاء الاتصال ، وتوفير وظائف نقل الشبكة الأساسية p2pServer \ * p2p. الخادم // حماية الوصول المتزامن إلى مزامنة قفل الحقول القابلة للتغيير. RWMutex // يتتبع ما إذا كانت العقدة معطلة بأمان ويساعد على استعادة shutdownTracker بعد إيقاف تشغيل غير طبيعي \ * shutdowncheck. ShutdownTracker }
عقدة
في node/node.go ، تعتبر Node هي بنية بيانات أساسية أخرى، تعمل كحاوية، مسؤولة عن إدارة وتنسيق تشغيل الخدمات المختلفة. في الهيكل أدناه، يجب الانتباه إلى حقل lifecycles، حيث يتم استخدام Lifecycle لإدارة دورة حياة الوظائف الداخلية. على سبيل المثال، يتطلب التجريد الخاص بـ Ethereum أعلاه الاعتماد على Node لبدء التشغيل، والتسجيل في lifecycles. بهذه الطريقة، يمكن فصل الوظائف المحددة عن تجريد العقدة، مما يعزز قابلية التوسع للهيكل بأكمله، ويجب تمييز هذه Node عن Node في devp2p.
اكتب بنية العقدة { eventmux *event. TypeMux التكوين \ * التكوين // مدير الحساب ، المسؤول عن إدارة المحافظ والحسابات accman \ * الحسابات. سجل سجل المدير. Logger keyDir string keyDirTemp bool dirLock *flock. قطيع وقف chan struct{} // p2p خادم مثيل الشبكة *p2p. بدء تشغيل الخادممزامنة StopLock. Mutex // تتبع حالة دورة حياة العقدة (تمت تهيئتها ، قيد التشغيل ، مغلقة) مزامنة قفل int. Mutex // جميع الخلفيات والخدمات ودورات حياة الخدمات الإضافية المسجلة []دورة الحياة // قائمة واجهات برمجة التطبيقات المتاحة حاليا rpcAPIs []rpc. API // طرق وصول مختلفة ل RPC http *httpServer ws *httpServer httpAuth *httpServer wsAuth *httpServer ipc *ipcServer inprocHandler *rpc. Server databases map[*closeTrackingDB]struct{} }
إذا نظرنا إلى طبقة تنفيذ Ethereum من بعد تجريدي ، فإن Ethereum ، ككمبيوتر عالمي ، يحتاج إلى تضمين ثلاثة أجزاء ، الشبكة والحوسبة والتخزين ، ثم المكونات المقابلة لهذه الأجزاء الثلاثة في طبقة تنفيذ Ethereum هي:
devp2p
الإيثيريوم في جوهره هو نظام موزع، حيث كل عقدة متصلة بعقد أخرى عبر شبكة p2p. تنفيذ بروتوكول شبكة p2p في الإيثيريوم هو devp2p.
يحتوي devp2p على وظيفتين أساسيتين، الأولى هي اكتشاف العقدة، مما يسمح للعقدة بإنشاء اتصال مع عقد أخرى عند الانضمام إلى الشبكة؛ والثانية هي خدمة نقل البيانات، حيث يمكن تبادل البيانات بعد إنشاء اتصال مع العقد الأخرى.
في ملف p2p/enode/node.go، تمثل بنية Node عقدة في شبكة p2p، حيث يتم تخزين أزواج المفتاح والقيمة لمعلومات العقدة التفصيلية في بنية enr.Record، بما في ذلك معلومات الهوية (خوارزمية التوقيع المستخدمة لهوية العقدة، المفتاح العام)، معلومات الشبكة (عنوان IP، رقم المنفذ)، معلومات البروتوكولات المدعومة (مثل دعم بروتوكول eth/68 وبروتوكول snap) ومعلومات مخصصة أخرى، وتشفّر هذه المعلومات بطريقة RLP، والمعايير المحددة تعرف في eip-778:
type Node struct { // سجل العقدة، يحتوي على خصائص العقدة المختلفة r enr.Record // المعرف الفريد للعقدة، بطول 32 بايت id ID // اسم المضيف لتتبع اسم DNS للعقدة hostname string // عنوان IP للعقدة ip netip.Addr // منفذ UDP udp uint16 // منفذ TCP tcp uint16 }// enr.Recordtype Record struct { // الرقم التسلسلي seq uint64 // التوقيع signature []byte // السجل المشفر باستخدام RLP raw []byte // قائمة مرتبة من جميع أزواج المفاتيح pairs []pair }
هيكل Table في p2p/discover/table.go هو الهيكل البياني الأساسي لبروتوكول اكتشاف العقدة الذي ينفذه devp2p، وهو ينفذ جدول تجزئة موزع مشابه لـ Kademlia، لتخزين وإدارة معلومات العقد في الشبكة.
printf( "اكتب بنية الجدول { مزامنة mutex. Mutex // فهرس دلاء العقدة المعروفة حسب المسافة [nBuckets]*bucket // حضانة عقدة التمهيد []*enode. Node rand reseedingRandom ips netutil. جدول إعادة التحقق من صحة DistinctNetSet إعادة التحقق // قاعدة بيانات العقد المعروفة ديسيبل *enode. DB صافي النقل cfg سجل التكوين. Logger // يعالج بشكل دوري الأحداث المختلفة في الشبكة refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chan struct{} closeReq chan struct{} closed chan struct{} // إضافة وإزالة واجهات العقد nodeAddedHook func(*bucket, *tableNode) nodeRemovedHook func( \ * دلو ، \ * tableNode)} العالم!" );
إيثدب
تكتمل ethdb تجريد تخزين بيانات الإيثريوم، مما يوفر واجهة تخزين موحدة، يمكن أن تكون قاعدة البيانات المحددة في الأسفل هي leveldb أو pebble أو أي قاعدة بيانات أخرى. يمكن أن يكون هناك الكثير من التوسعات، طالما يتم الحفاظ على الاتساق على مستوى الواجهة.
بعض البيانات (مثل بيانات الكتل) يمكن قراءتها وكتابتها مباشرة عبر واجهة ethdb إلى قاعدة البيانات الأساسية، بينما يتم إنشاء واجهات تخزين البيانات الأخرى على أساس ethdb، على سبيل المثال، يحتوي جزء كبير من البيانات في قاعدة البيانات على بيانات الحالة، وستُنظم هذه البيانات في هيكل MPT، والذي يتوافق في Geth مع تنفيذ trie، خلال عملية تشغيل العقدة، ستنتج بيانات trie العديد من الحالات الوسيطة، ولا يمكن استدعاء هذه البيانات مباشرة عبر ethdb للقراءة والكتابة، بل تحتاج إلى triedb لإدارة هذه البيانات والحالات الوسيطة، وأخيرًا يتم استخدامها عبر ethdb للتخزين الدائم.
تم تعريف واجهة قدرات القراءة والكتابة لقاعدة البيانات الأساسية في ethdb/database.go، ولكن لم يتم تضمين التنفيذ الفعلي، حيث سيتم تنفيذ التنفيذ الفعلي من قبل قواعد البيانات المختلفة نفسها. مثل leveldb أو pebble. تم تعريف واجهتين لقراءة وكتابة البيانات في Database، حيث تُستخدم واجهة KeyValueStore لتخزين البيانات النشطة، التي قد تتغير بشكل متكرر، مثل الكتل الأخيرة، والحالات، وما إلى ذلك. بينما تُستخدم واجهة AncientStore لمعالجة بيانات الكتل التاريخية، والتي نادراً ما تتغير بمجرد كتابتها.
اكتب واجهة قاعدة البيانات { KeyValueStore AncientStore}// اكتب واجهة KeyValueStore { KeyValueReader, KeyValueWriter, KeyValueStater, KeyValueRangeDeleter Batcher Iteratee Compacter io. أقرب}// اكتب واجهة AncientStore { AncientReader AncientWriter AncientStater io. أقرب}
EVM
EVM هو دالة تحويل الحالة لهذه الحالة آلة إيثريوم، جميع تحديثات بيانات الحالة يمكن أن تتم فقط من خلال EVM، يمكن أن تستقبل شبكة P2P معلومات المعاملات والكتل، بعد معالجة هذه المعلومات بواسطة EVM ستصبح جزءًا من قاعدة بيانات الحالة. EVM تخفي اختلافات الأجهزة الأساسية، مما يسمح للبرامج بالتنفيذ على EVM على منصات مختلفة للحصول على نتائج متسقة. هذه طريقة تصميم ناضجة جداً، JVM في لغة Java هو تصميم مشابه.
تتكون تنفيذ EVM من ثلاثة مكونات رئيسية، حيث يقوم هيكل EVM الموجود في core/vm/evm.go بتعريف الهيكل العام لـ EVM والاعتمادات، بما في ذلك سياق التنفيذ، والاعتمادات على قاعدة بيانات الحالة، وما إلى ذلك؛ بينما يقوم هيكل EVMInterpreter الموجود في core/vm/interpreter.go بتعريف تنفيذ المترجم، المسؤول عن تنفيذ بايت كود EVM؛ ويقوم هيكل Contract الموجود في core/vm/contract.go بتغليف المعلمات المحددة لاستدعاء العقد، بما في ذلك المستدعي، رمز العقد، المدخلات، وما إلى ذلك، كما يتم تعريف جميع رموز العمليات الحالية في core/vm/opcodes.go:
هيكل EVMtype EVM { // سياق الكتلة ، يحتوي على معلومات متعلقة بالكتلة سياق BlockContext // سياق المعاملة ، يحتوي على معلومات متعلقة بالمعاملة TxContext // قاعدة بيانات الحالة ، تستخدم للوصول إلى حالة الحساب وتعديلها StateDB StateDB // عمق المكالمة الحالي int // معلمة تكوين السلسلة chainConfig \ * params. سلسلة ChainConfig معلمات القواعد. القواعد // تكوين EVM // مترجم الرمز الثانوي *EVMInterpreter // إحباط علامة التنفيذ إحباط ذري. Bool callGasTemp uint64 // precompiles map[common. العنوان]PrecompiledContract jumpDests map[common. Hash]bitvec }type EVMInterpreter struct { // أشر إلى مثيل EVM الذي ينتمي إليه evm *EVM // Opcode Jump Table *JumpTable // مثيل Keccak256 hasher ، شارك تشفير hasher بين رموز التشغيل. KeccakState // Keccak256 تجزئة نتيجة العازلة hasherBuf المشتركة. تجزئة // سواء كان وضع القراءة فقط ، لا يسمح بتعديل الحالة في وضع القراءة فقط readOnly bool // يتم استخدام بيانات الإرجاع لآخر CALL لإعادة الاستخدام اللاحقة بيانات الإرجاع [] بايت } نوع بنية العقد { // عنوان المتصل الشائع. العنوان // عنوان العقد العنوان المشترك. عنوان jumpdests map[common. Hash]bitvec تحليل bitvec // رمز Bytecode للعقد []byte // Code hash CodeHash شائع. تجزئة // إدخال المكالمة [] بايت // ما إذا كان سيتم نشر IsDeployment bool للعقد // ما إذا كان سيتم استدعاء IsSystemCall bool // غاز الغاز المتاح uint64 // مقدار ETH المرتبط بقيمة المكالمة \ * uint256. إنت }
تنفيذ وحدات أخرى
تتم وظيفة طبقة التنفيذ من خلال طريقة الطبقات، حيث يتم بناء الوحدات والوظائف الأخرى على أساس هذه المكونات الثلاثة الأساسية. هنا نعرض بعض الوحدات الأساسية.
توجد في eth/protocols تنفيذات بروتوكولات الشبكة الند للند الحالية للإيثيريوم. هناك بروتوكولات فرعية eth/68 و snap، وهذه البروتوكولات الفرعية مبنية على devp2p.
eth/68 هو البروتوكول الأساسي للإيثريوم، اسم البروتوكول هو eth، و68 هو رقم إصداره، ثم تم تنفيذ وظائف مثل حوض المعاملات (TxPool)، مزامنة الكتل (Downloader) ومزامنة المعاملات (Fetcher) على أساس هذا البروتوكول. بروتوكول snap يُستخدم عند انضمام عقدة جديدة إلى الشبكة لمزامنة الكتل وبيانات الحالة بسرعة، مما يمكن أن يقلل بشكل كبير من وقت بدء العقدة الجديدة.
يقدم ethdb القدرة على القراءة والكتابة لقاعدة البيانات الأساسية، ونظرًا لوجود العديد من هياكل البيانات المعقدة في بروتوكول الإيثريوم، فإنه لا يمكن إدارة هذه البيانات مباشرة من خلال ethdb، لذلك تم تنفيذ rawdb و statedb على ethdb لإدارة بيانات الكتلة والحالة على التوالي.
EVM تمر عبر جميع العمليات الرئيسية، سواء كان ذلك في بناء الكتل أو التحقق من الكتل، يحتاج إلى تنفيذ المعاملات باستخدام EVM.
05\عملية بدء تشغيل عقدة Geth
ستقسم عملية بدء Geth إلى مرحلتين، المرحلة الأولى ستقوم بتهيئة المكونات والموارد اللازمة لتشغيل العقدة، المرحلة الثانية ستقوم بتشغيل العقدة رسميًا، ثم تقديم الخدمة للآخرين.
عقدة初始化
عند بدء عقدة geth، ستتعلق الشيفرة التالية:
تهيئة كل وحدة هي كما يلي:
سيتم الانتهاء من تهيئة العقدة في makeFullNode الموجود في cmd/geth/config.go، مع التركيز على تهيئة الوحدات الثلاثة التالية
في الخطوة الأولى، سيتم تهيئة بنية Node في node/node.go، وهو حاوية العقدة بأكملها، حيث تحتاج جميع الوظائف إلى العمل داخل هذه الحاوية. في الخطوة الثانية، سيتم تهيئة بنية Ethereum، التي تشمل تنفيذ مجموعة متنوعة من الوظائف الأساسية لـ Ethereum، كما يجب تسجيل Etherereum في العقدة. الخطوة الثالثة هي تسجيل واجهة برمجة التطبيقات Engine في العقدة.
إن تهيئة العقدة تعني إنشاء مثيل عقدة، ثم تهيئة خادم p2p، وإدارة الحسابات، بالإضافة إلى بروتوكولات منافذ http وغيرها التي تم الكشف عنها للخارج.
ستكون初始化 Ethereum أكثر تعقيدًا بكثير، حيث يتم初始化 معظم الوظائف الأساسية هنا. أولاً، سيتم初始化 ethdb، وتحميل تكوين السلسلة من التخزين، ثم إنشاء محرك الإجماع. لن يقوم محرك الإجماع هنا بتنفيذ عمليات الإجماع، بل سيقوم فقط بالتحقق من النتائج التي تم إرجاعها من طبقة الإجماع، وإذا حدثت طلبات سحب في طبقة الإجماع، فسيتم أيضًا إكمال عمليات السحب الفعلية هنا. ثم يتم تهيئة هيكل سلسلة الكتل ومسبح المعاملات.
بعد الانتهاء من كل هذه الأمور، سيتم تهيئة handler، حيث إن handler هو مدخل معالجة جميع طلبات الشبكة الند للند، بما في ذلك مزامنة المعاملات، وتنزيل الكتل، وغيرها، وهو المكون الرئيسي لتحقيق التشغيل اللامركزي على الإيثريوم. بعد الانتهاء من كل هذه الأمور، سيتم تسجيل بعض البروتوكولات الفرعية التي تم تنفيذها على أساس devp2p، مثل eth/68 و snap، في حاوية Node، وأخيرًا سيتم تسجيل Ethereum كدورة حياة في حاوية Node، مما يعني أن تهيئة Ethereum قد اكتملت.
! عميل Ethereum الرئيسي: Geth العمارة الشاملة
أخيرًا، كانت عملية تهيئة واجهة برمجة التطبيقات (API) الخاصة بمحرك (Engine) بسيطة نسبيًا، حيث تم تسجيل واجهة برمجة التطبيقات (API) الخاصة بمحرك (Engine) في العقدة (Node). وبذلك، اكتملت عملية تهيئة العقدة (Node) بالكامل.
عقدة启动
بعد الانتهاء من تهيئة العقدة، يجب بدء العقدة. إن عملية بدء العقدة بسيطة نسبيًا، كل ما يتعين عليك فعله هو بدء جميع خدمات RPC المسجلة و Lifecycle، عندها يمكن للعقدة تقديم الخدمات للعالم الخارجي.
06\ملخص
قبل فهم تنفيذ طبقة التنفيذ في الإيثيريوم بعمق، من الضروري الحصول على رؤية شاملة عن الإيثيريوم. يمكن اعتبار الإيثيريوم ككل كآلة حالة مدفوعة بالمعاملات، حيث تتولى طبقة التنفيذ مسؤولية تنفيذ المعاملات وتغيير الحالة، بينما تتحمل طبقة الإجماع مسؤولية دفع طبقة التنفيذ للعمل، بما في ذلك جعل طبقة التنفيذ تنتج كتل، وتحديد ترتيب المعاملات، والتصويت على الكتل، وضمان حصول الكتل على النهائية. نظرًا لأن هذه الآلة الحالة لامركزية، فهي بحاجة إلى التواصل مع عقدة أخرى من خلال شبكة p2p للحفاظ على توافق بيانات الحالة.
لا تتحمل طبقة التنفيذ مسؤولية تحديد ترتيب المعاملات، بل تركز على تنفيذ المعاملات وتسجيل التغييرات في الحالة بعد التنفيذ. هناك شكلان من التسجيل هنا، أحدهما هو تسجيل جميع التغييرات في الحالة على شكل كتل، والآخر هو تسجيل الحالة الحالية في قاعدة البيانات. في الوقت نفسه، تعتبر طبقة التنفيذ مدخل المعاملات، من خلال تجمع المعاملات لتخزين المعاملات التي لم يتم تضمينها بعد في الكتل. إذا كانت هناك عقد أخرى بحاجة إلى الحصول على البيانات حول الكتل والحالة والمعاملات، ستقوم طبقة التنفيذ بإرسال هذه المعلومات عبر شبكة نظير إلى نظير.
بالنسبة لطبقة التنفيذ، هناك ثلاثة وحدات أساسية: الحساب، التخزين، والشبكة. الحساب يتوافق مع تنفيذ EVM، بينما التخزين يتوافق مع تنفيذ ethdb، والشبكة تتوافق مع تنفيذ devp2p. بعد الحصول على هذا الفهم الشامل، يمكنك التعمق في فهم كل وحدة فرعية دون أن تضيع في التفاصيل المحددة.
07\المرجع
[1]
[2]
[3]
[4]
[5]
[6]
· انتهى·
المحتوى | راي
تحرير & تنسيق |环环
تصميم | دايزي