كيفية تشغيل Ethereum Mainnet العقدة على AWS

قامت AWS مؤخرًا بنشر قوالب CloudFormation [1] لإطلاق شبكة اختبار Ethereum خاصة.
يأتي حلهم مع تطبيق لعرض الكتل ، وعمال المناجم ، وما إلى ذلك. وبقدر ما هو رائع ، لا يسهل تطبيق هذا الحل لتشغيل العقدة الرئيسية.

أولاً ، دعنا نحاول الإجابة عن سبب احتياج أي شخص إلى عقدة Ethereum mainnet المستضافة من القطاع الخاص بدلاً من الاعتماد على Infura. في Rumble Fish ، لدينا عدد قليل من المشروعات التي يتفاعل فيها بعض المكونات الخلفية
مع كتلة سلسلة Ethereum. في بعض الحالات ، يتفاعل مع إخطار الأحداث ، وفي حالات أخرى يكون مسؤولاً عن إغلاق المعاملات المالية ويجب أن يتصرف بسرعة.

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

TL ؛ ملخص DR

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

0. استنساخ هذا المستودع.

بوابة استنساخ https://github.com/rumblefishdev/cf-parity-mainnet.git
  1. محطة مفتوحة. تثبيت aws و jq إذا لم يتم تثبيت.
  2. قم بإعداد الحساب والمنطقة التي تعمل معها.
تصدير AWS_DEFAULT_REGION = eu-central-1
      # تعيين لمطابقة الإدخال في ~ / .aws / بيانات الاعتماد
      تصدير AWS_DEFAULT_PROFILE = ...

3. إنشاء مستودع ، بناء الصورة ودفعها.

bash build_and_upload.sh

ينشئ هذا الأمر مستودع ECR ضمن حسابك ويدفع إلى هناك صورة مخصصة قليلاً لعميل Parity.

4. حدد معلمات العقدة.

سحابة مؤتمر نزع السلاح
cp stack-sources.default.json stack-sources.json
المحرر $ المكدس-sources.json

هنا تحتاج إلى تحديد:

  • VpcId لتشغيل السلسلة
  • DNSName للتسجيل في العقدة الخاصة بك (على سبيل المثال mainnet.rumblefishdev.com)

5. إنشاء كومة CloudFormation.

باش -X إنشاء كومة

6. انتقل إلى وحدة تحكم CloudFormation وانتظر حتى تكتمل عملية إنشاء المكدس. احصل على إخراج NameServer الذي تم تصديره ووضعه كإدخال NS في تهيئة DNS للمجال الخاص بك.

7. انتظر ~ 3 أيام حتى تنتهي عملية المزامنة والتحقق.

8. انتقل إلى AWS console EC2 | مجلدات المجلد والتقاط لقطة حجم.

9. عندما تكون اللقطة جاهزة ، ضعها كمعلمات ChainSnapshodId stack-sources.json وقم بتحديث المكدس.

باش -X تحديث المكدس

تحديات تشغيل العقدة الرئيسية

بلوكشين استمرار البيانات

التحدي الأكبر في الحصول على عقدة mainnet هو الحصول على مزامنتها. تستغرق مزامنة العقدة المتصلة حديثًا من الصفر 2-3 ساعات للوصول إلى الكتل الحالية. ثم يستغرق الأمر 2-3 أيام إضافية لإكمال عملية التحقق من التشفير لجميع الكتل. تستخدم عملية التحقق جميع IOPS المتاحة مما يجعل العقدة غير مستجيبة للغاية. خلال هذا الوقت ، غالبًا ما لوحظ أن العقدة ستتخلف بنسبة تصل إلى 30 قطعة مما يجعلها غير مفيدة. فقط بعد اكتمال عملية التحقق ، تصبح العقدة مستقرة ويمكن الاعتماد عليها. لا تتعامل الأكوام التي تقدمها AWS مع هذه المشكلة - كل عقدة تبدأ بقائمة نظيفة. هذا جيد ، طالما أنك لا تملك الكثير من البيانات للمزامنة من العقد الأخرى.

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

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

النهج التي رفضناها

وحيد ثابت EBS

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

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

نظام الملفات المرنة (EFS)

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

وصول الشبكة العامة لطبقة التزامن

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

لضمان وصول الجمهور ، استخدمنا الخطوات التالية.

  1. يتم تشغيل التكافؤ في حاوية عامل ميناء. يتم سد المنفذ 30303 باستخدام الجزء التالي من مكدس cloudform.
مصادر:
  TaskDefinition:
    النوع: AWS :: ECS :: TaskDefinition
    الخصائص:
      ...
      ContainerDefinitions:
        ...
        PortMappings:
          - ContainerPort: 30303
            مضيف المنفذ: 30303
            البروتوكول: برنامج التعاون الفني

2. تحتاج العقدة الآن إلى IP العام الخاص بها ، حيث يتم استخدام هذا المعرف enode للبث إلى العقد الأخرى. الحل خاص بـ EC2 ويعتمد على واجهة برمجة التطبيقات الداخلية المتاحة من الجهاز. من عامل الميناء / run_parity.sh:

PUBLIC_IP = `curl -s http: // 169.254.169.254 / latest / meta-data / public-ipv4`
/ parity / parity --config config.toml - nip extip: $ PUBLIC_IP

3. لكي يكون منفذ جهاز EC2 متاحًا ، يجب أيضًا فتحه في تكوين مجموعة الأمان. هذا الجزء من المكدس مسؤول عن القيام بذلك.

مصادر:
  ECSSecurityGroup:
    النوع: AWS :: EC2 :: SecurityGroup
    الخصائص:
      ...
      SecurityGroupIngress:
        - من ميناء: 30303
          ToPort: 30303
          CidrIp: 0.0.0.0/0
          IpProtocol: tcp

وصول خاص إلى json-rpc ونقاط نهاية websocket

لدى Parity واجهات شبكة أخرى للوصول إلى بيانات blockchain.

  • يستخدم المنفذ 8545 في json-rpc api: نشر المعاملات والحصول على كل نوع من المعلومات
  • يمكن استخدام المنفذ 8546 لتلقي إخطار من العقدة حول الكتل و / أو الأحداث الجديدة

أولاً ، دعنا نناقش سبب اعتقادنا أن json-rpc يجب ألا تكون متاحة للعامة. اعتمادًا على حالة الاستخدام المعينة ، قد لا يكون وجود مشكلة في json-rpc مفتوحًا. لكن في مطعم Rumble Fish ، نعتقد أن أي شيء يمكن إخفاؤه يجب أن يظل مخفيًا.

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

يتكون نهجنا للوصول الخاص من التالي.

  1. إنشاء مكدس Cloudform وتصدير SecurityGroup خاص يستخدم للوصول إلى العقدة. يمكنك استيراده مكدس آخر باستخدام:
! Fn :: استيراد MainnetParity-AccessSecurityGroup

2. يتم منح هذه المجموعة حق الوصول إلى المثيل باستخدام الإعداد التالي في SecurityGroup لمثيل EC2.

مصادر:
   ECSSecurityGroup:
     النوع: AWS :: EC2 :: SecurityGroup
     الخصائص:
       ...
       SecurityGroupIngress:
         - من ميناء: 8545
           المنفذ: 8545
           SourceSecurityGroupId:! GetAtt AccessSecurityGroup.GroupId
           IpProtocol: tcp
         - من ميناء: 8546
           ToPort: 8546
           SourceSecurityGroupId:! GetAtt AccessSecurityGroup.GroupId
           IpProtocol: tcp


يتم توجيه هذه المنافذ إلى حاوية عامل الميناء ، على غرار ما قمنا به من قبل
ميناء 30303.

::

  مصادر:
    TaskDefinition:
      النوع: AWS :: ECS :: TaskDefinition
      الخصائص:
        ...
        ContainerDefinitions:
          ...
          PortMappings:
            - ContainerPort: 8545
              مضيف المنفذ: 8545
              البروتوكول: برنامج التعاون الفني
            - ContainerPort: 8546
              مضيف المنفذ: 8546
              البروتوكول: برنامج التعاون الفني

3. يحتاج العميل المتصل بـ json-rpc / websocket api إلى القيام بذلك باستخدام IP الخاص للمثيل. نحقق ذلك من خلال إنشاء Route53 HostedZone وتسجيل مثيلات IP هناك عند بدء التشغيل.

يُصدر مكدس Cloudform خوادم الأسماء في هذه المنطقة ليتم استيرادها كـ

! Fn :: استيراد MainnetParity-NameServer

أو بحثت في صادرات وحدة التحكم AWS.

يجب عليك وضع هذه القيمة كإدخال NS في تكوين مجال DNS الخاص بك.

الرصد والتسجيل

تم تكوين المكدس لجمع ملفات مثيرة للاهتمام من الجهاز ودفعها إلى دفق سجل CloudWatch المسمى MainnetParity-logs.

عملية المزامنة والتحقق

هنا ، البتات المثيرة للاهتمام هي أسماء الملفات / التماثل / التماثل / ... والتي هي ناتج عملية التماثل. في المرة الأولى التي تقوم فيها بتشغيل الحزمة ، ستستخدم مزامنة الاعوجاج لتنزيل محفوظات blockchain باستخدام بروتوكول التنزيل المجمع لـ Parity.

في الإخراج يبدو إلى حد ما مثل هذا:

2018-05-11T09: 27: 56.202Z ++ curl -s http://169.254.169.254/latest/meta-data/public-ipv4
2018-05-11T09: 27: 56.253Z + PUBLIC_IP = 18.196.95.41
2018-05-11T09: 27: 56.253Z + / التكافؤ / التكافؤ - التكوين config.toml - nip extip: 18.196.95.41
2018-05-11T09: 27: 56.297Z تحميل ملف التكوين من config.toml
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC بدء التكافؤ / v1.10.3-stabil-b9ceda3-20180507 / x86_64-linux-gnu / rustc1.25.0
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 مسار مفاتيح UTC /root/.local/share/io.parity.ethereum/keys/Foundation
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 مسار DB DB /root/.local/share/io.parity.ethereum/chains/ethereum/db/906a34e69aec8c0d
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC المسار إلى dapps /root/.local/share/io.parity.ethereum/dapps
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC حالة تكوين DB: سريع
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC وضع التشغيل: نشط
2018-05-11T09: 27: 56.361Z 2018-05-11 09:27:56 UTC تم تكوينها للمؤسسة باستخدام محرك Ethash
2018-05-11T09: 27: 56.730Z 2018-05-11 09:27:56 UTC عنوان URL للعقدة العامة: enode: //ec52f4ae94c624b1f8bf9c9b60fd63261beb42af6fea9d0fa4aeb6f52047fdf4afd92d9e9d9f9e
2018-05-11T09: 27: 57.057Z 2018-05-11 09:27:57 UTC معدل التحويل المحدّث إلى Ξ1 = 694.89 دولارًا أمريكيًا (6852745.5 wei / gas)
2018-05-11T09: 28: 06.806Z 2018-05-11 09:28:06 UTC المزامنة # 0 d4e5… 8fa3 0 blk / s 0 tx / s 0 Mgas / s 0+ 0 Qed # 0 1/25 peers 8 KiB chain 3 MiB db 0 bytes Queue 10 KiB sync RPC: 0 conn، 0 req / s، 0 µs
2018-05-11T09: 28: 16.806Z 2018-05-11 09:28:16 UTC مزامنة لقطة 9/1370 # 0 2/25 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T09: 28: 21.807Z 2018-05-11 09:28:21 UTC مزامنة لقطة 15/1370 # 0 2/25 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T09: 28: 26.808Z 2018-05-11 09:28:26 UTC مزامنة لقطة 21/1370 # 0 2/25 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T09: 28: 31.809Z 2018-05-11 09:28:31 UTC مزامنة لقطة 27/1370 # 0 3/25 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T09: 28: 36.809Z 2018-05-11 09:28:36 UTC مزامنة لقطة 29/1370 # 0 3/25 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs

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

2018-05-11T10: 26: 46.793Z 2018-05-11 10:26:46 UTC مزامنة لقطة 1327/1370 # 0 26/50 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T10: 26: 56.798Z 2018-05-11 10:26:56 UTC مزامنة لقطة 1346/1370 # 0 26/50 أقران 8 سلسلة KiB 3 MiB db 0 بايت قائمة انتظار 10 KiB sync RPC: 0 conn، 0 مسا / ثانية ، 0 µs
2018-05-11T10: 27: 08.097Z 2018-05-11 10:27:08 UTC المزامنة # 5590000 b084… 309c 0 blk / s 0 tx / s 0 Mgas / s 0+ 0 Qed # 5590000 24/25 أقرانهم 63 KiB chain 1 KiB db 0 bytes Queue 6 MiB sync RPC: 0 conn، 0 req / s، 0 µs
2018-05-11T10: 27: 16.794Z 2018-05-11 10:27:16 UTC المزامنة # 5590000 b084… 309c 0 blk / s 0 tx / s 0 Mgas / s 1750+ 1 Qed # 5591752 26/50 أقران 174 سلسلة KiB 39 KiB db 95 MiB قائمة انتظار 11 MiB sync RPC: 0 conn، 0 req / s، 0 µs

سيستغرق هذا حوالي ساعة أخرى لإنهاء هذه المرحلة.

عند اكتمال هذه المرحلة ، سيتغير ملف السجل كما يلي:

2018-05-11T15: 24: 30.011Z 2018-05-11 15:24:30 UTC المزامنة # 5595608 f2fe ... d003 0 blk / s 0 tx / s 0 Mgas / s 0+ 7 Qed # 5595619 11/25 أقرانهم 33 سلسلة MiB 182 MiB db 1 قائمة انتظار MiB 8 MiB sync RPC: 0 conn، 0 req / s، 0 µs
2018-05-11T15: 24: 41.386Z 2018-05-11 15:24:41 UTC معدل التحويل المحدث إلى Ξ1 = 679.41 دولار أمريكي (7008882.5 wei / gas)
2018-05-11T15: 24: 41.795Z 2018-05-11 15:24:41 UTC مستورد # 5595620 ef95 ... d8b2 (181 txs ، 7.98 Mgas ، 4237.27 ms ، 27.63 KiB) + 3 كتل أخرى تحتوي على 330 tx (س)
2018-05-11T15: 24: 48.290Z 2018-05-11 15:24:48 UTC مستورد # 5595622 221b… 509d (162 txs ، 7.99 Mgas ، 1194.76 ms ، 25.13 KiB)
2018-05-11T15: 24: 51.186Z 2018-05-11 15:24:51 UTC مستورد # 5595623 b744 ... cf9c (183 txs ، 7.98 Mgas ، 1698.02 مللي ثانية ، 33.23 كيلوبايت)
2018-05-11T15: 25: 27.225Z 2018-05-11 15:25:27 UTC # 40653 13/25 أقران 37 سلسلة MiB 182 MiB db 0 بايت قائمة انتظار 24 MiB sync RPC: 0 conn، 0 req / s، 0 ميكرو ثانية
2018-05-11T15: 25: 27.241Z 2018-05-11 15:25:27 UTC # 40653 13/25 أقران 37 سلسلة MiB 182 MiB db 0 بايت قائمة انتظار 24 MiB sync RPC: 0 conn، 0 req / s، 0 ميكرو ثانية
2018-05-11T15: 25: 27.252Z 2018-05-11 15:25:27 UTC # 40653 13/25 أقران 37 سلسلة MiB 182 MiB db 0 بايت قائمة انتظار 24 MiB sync RPC: 0 conn، 0 req / s، 0 ميكرو ثانية
2018-05-11T15: 25: 27.310Z 2018-05-11 15:25:27 UTC # 40653 13/25 أقران 37 سلسلة MiB 182 MiB db 0 بايت قائمة انتظار 24 MiB sync RPC: 0 conn، 0 req / s، 0 ميكرو ثانية
2018-05-11T15: 25: 41.464Z 2018-05-11 15:25:41 UTC مستورد # 5595627 a4a9 ... 9dc0 (136 txs ، 7.98 Mgas ، 529.92 ms ، 19.68 KiB)
2018-05-11T15: 26: 02.263Z 2018-05-11 15:26:02 UTC # 78637 23/25 أقران 37 MiB سلسلة 183 MiB db 241 KiB قائمة انتظار 22 MiB sync RPC: 0 conn، 0 req / s، 0 ميكرو ثانية
2018-05-11T15: 26: 03.398Z 2018-05-11 15:26:03 UTC Reorg إلى # 5595628 8fc3 ... 7c58 (a4a9 ... 9dc0 18c7 ... 4d47 # 5595625 f6c1 ... feae 3faf ... 012d af04… 83a8)

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

تستغرق هذه العملية حوالي 3 أيام أيضًا عند تشغيلها على t2.machine مع gp2 EBS 300 IOPS. أثناء تشغيله ، يمكنك ملاحظة أنه عند استهلاك وحدة تخزين EBS ، يتم استهلاك كل IOPS المتاحة. تمثل لقطة الشاشة أدناه اللحظة التي تنتهي فيها عملية التحقق. يمكنك أن ترى الفرق في نمط الاستخدام.

قراءة IOPSاكتب IOPS

نظرًا لأن عملية التحقق مرتبطة بـ IO ، فمن الممكن جعلها أسرع من خلال توفير محرك EBS مع IOPS إضافية. في مكدس CloudFormation الخاص بنا ، نستخدم gp2 VolumeType بحجم 100 جيجابايت. أحكام AWS 300 IOPS الأساس لمثل هذا محرك الأقراص. إذا كنت بحاجة إلى جعل التحقق أسرع ، فيمكنك تعديل VolumeType إلى io1 وإعطائه 1200 IOPS. في هذا المستوى ، نلاحظ أن عملية التحقق لم تعد مقيدة بـ IOPS المتاحة ولكنها تفتقد إلى طاقة وحدة المعالجة المركزية. لذلك يمكنك دفعها إلى مستوى آخر عن طريق تغيير حجم آلة EC2 من t2.medium إلى c5.large.

يعمل على c5.large لقد لاحظنا أن Parity أثناء التحقق يستخدم 2000 IOPS ويمكنه إنهاء العملية بأكملها في حوالي 7 ساعات ، لذلك فهو اختصار جيد إذا كنت بحاجة إلى الحصول على نتائج سريعة. فقط ضع في اعتبارك أن IOPS المقدمة ليست رخيصة ، وأن التكلفة الشهرية لترك محرك بهذا الحجم وأن IOPS سيكون في حدود 100 دولار ، لذا كن حذرًا.

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

البقاء في المزامنة

بمجرد أن تتم مزامنة العقدة بالكامل ومزامنتها ، تظل بشكل عام متزامنة مع رأس السلسلة :-)

فرق التكافؤ مع Infura

تعرض الصورة أعلاه تأثير استدعاء eth_blockNumber على عقدتنا وعلى Infura. معظم الوقت العقد متزامنة. من حين لآخر إما العقدة أو Infura يقع خلفها 1-4 كتل.

يرجى ملاحظة أن هذا المستودع حاليًا لا يشمل Lambda المسؤول عن جمع المقاييس أعلاه. سيتم تضمينه في المقالات المستقبلية.

[1] https://docs.aws.amazon.com/blockchain-templates/latest/developerguide/blockchain-templates-ethereum.html

Chcielibyście dowiedzieć się، jak uruchomić mainnetowy node Ethereum na AWS، ale wolicie przeczytać o tym po polsku؟ Zapraszamy do zapoznania się z tłumaczeniem artykułu opublikowanym przez justgeek.it: https://geek.justjoin.it/uruchomic-mainnetowy-node-ethereum-aws/