• For the last testnet proof-of-stake transition, Goerli will merge with Prater. The combined Goerli/Prater network will retain the Goerli name post-merge.
  • Bellatrix, the Prater upgrade readying it for The Merge will happen at epoch 112260, expected at 12:24PM UTC on August 4, 2022.
  • After Bellatrix is activated, the Goerli/Prater merge will happen when Goerli hits a total difficulty of 10790000, expected between August 6-12, 2022.
  • Post-merge, Goerli’s validator set will remain open for individual stakers to run testnets validators. Stakers who wish to start a Goerli/Prater validator can do so at the Prater Launchpad.

Language options

Don’t want to read in English? We’ve translated this post into the following languages:

Background

After years of work to bring proof-of-stake to Ethereum, we are now well into the final testing stage: testnet deployments!

After several devnets, shadow forks and merges on deprecated testnets, Sepolia was recently transitioned to proof-of-stake. Now, only one more testnet remains: Goerli, and its associated Beacon Chain, Prater.

The Merge is different from previous Ethereum upgrades in two ways. First, node operators need to update both their consensus layer (CL) and execution layer (EL) clients in tandem, rather than just one of the two. Second, the upgrade activates in two phases: the first, named Bellatrix, at an epoch height on the Beacon Chain and the second, named Paris, upon hitting a Total Difficulty value on the execution layer.

Upgrade Information

Timing

The Merge is a two-step process. It starts with a network upgrade, Bellatrix, on the consensus layer, triggered by an epoch height. This is followed by the execution layer’s transition from proof-of-work to proof-of-stake, Paris, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).

The Bellatrix upgrade is scheduled for epoch 112260 on the Prater Beacon Chain, expected at 12:24PM UTC on August 4, 2022. Paris, the execution layer’s portion of the transition, will trigerred by reaching a Terminal Total Difficulty (TTD) of 10790000 on Goerli, expected between August 6-12, 2022.

Once the execution layer has exceeded the TTD, the next block will be solely produced by a Beacon Chain validator. We consider The Merge to have been completed once the Beacon Chain has finalized this block. Assuming normal network conditions, this should happen 2 epochs, or approximately 13 minutes, after the first post-TTD block is hit!

A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no such post-merge block exists. This tag can be used for applications to check if The Merge has been completed. Similarly, smart contracts can query the DIFFICULTY opcode (0x44), renamed to PREVRANDAO post-merge, to determine if The Merge has happened. We recommend infrastructure providers monitor overall network stability in addition to finalization status.

Client Releases

The following client releases support The Merge across the Goerli & Prater testnets. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

When choosing which client to run, validators should be especially mindful of the risks of running a majority client on both the EL and CL. An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.

Consensus Layer

Execution Layer

Upgrade Specifications

Consensus-critical changes for The Merge are specified in two places:

  • The consensus layer changes, under the bellatrix directory of the consensus-specs repository
  • The execution layer changes, under the Paris spec in the execution-specs repository

In addition to these, two other specifications cover how the consensus and execution layer clients interact:

  • The Engine API, specified in the execution-apis repository, is used for communication between the consensus and execution layers
  • Optimistic Sync, specified in the sync folder of the consensus-specs repository, is used by the consensus layer to import blocks as the execution layer client is syncing and to provide a partial view of the head of the chain from the former to the latter

FAQ

As a node operator, what should I do?

Post-merge, an Ethereum full node will combine a consensus layer (CL) client, which runs the proof-of-stake Beacon Chain, and an execution layer (EL) client, which manages the user-state and runs the computations associated with transactions. These communicate over an authenticated port using a new set of JSON RPC methods called the Engine API. The EL and CL client authenticate each other using a JWT secret. Node operators should refer to their clients’ documentation for instructions about how to generate and configure these.

In other words, if you were already running a node on the Beacon Chain, you now also need to run an execution layer client. Similarly, if you were running a node on the current proof-of-work network, you will need to run a consensus layer client. For them to communicate securely, a JWT token must be passed to each client. Summary instructions for running a node on the Goerli/Prater network can be found here.

It is worth emphasizing that while they are both part of consensus layer client releases, running a Beacon Node is distinct from running a Validator Client. Stakers must run both, but node operators only need the former. This post explains the difference between both components in more detail.

Also, note that each layer will maintain an independent set of peers and expose its own APIs. The Beacon and JSON RPC APIs will both continue working as expected.

As a staker, what do I need to do?

The Goerli/Prater Merge is your last opportunity to ensure that your validators are correctly configured before the mainnet transition. Running through the transition now is strongly recommended to avoid any unexpected issues on mainnet.

As explained above, validators on the Beacon Chain will need to run an execution layer client after The Merge, in addition to their consensus layer clients. Pre-merge, this was strongly recommended, but validators could have outsourced these functions to third-party providers. This was possible because the only data required on the execution layer were updates to the deposit contract.

Post-merge, validators need to ensure that transactions in blocks that they create and attest to are valid. To do this, each beacon node must be paired with an execution layer client. Note that multiple validators can still be paired to a single beacon node & execution layer client combo. While this expands validators’ responsibilities, it also gives a validator who proposes a block the right to its associated transaction priority fees (which currently go to miners).

While validator rewards accrue on the Beacon Chain and will require a subsequent network upgrade to be withdrawn, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can specify any Ethereum address as a recipient for transaction fees.

After updating your consensus client, be sure to set the fee recipient as part of your validator client configurations to ensure transaction fees are sent to an address you control. If you have staked using a third-party provider, it is up to your selected provider to specify how these fees are allocated.

The Prater Staking Launchpad has a Merge Readiness Checklist that stakers can use to ensure they have gone through each step of the process. The EthStaker team is also hosting a Merge Validator Preparation Workshop on July 29.

Why is the estimate for the Terminal Total Difficulty date so broad?

The volatility in incremental difficulty per block makes estimating a window for the TTD harder than with a block or epoch height, hence the wider expected range. Users should note that this will also be the case for mainnet’s transition due to changes in proof-of-work hash rate.

As an application or tooling developer, what should I do?

With The Merge going live on Goerli, now is your last chance to ensure that your product works as expected through the proof-of-stake transition and in a post-merge context. As explained in a previous post, The Merge will have only minimal impact on a subset of contracts deployed on Ethereum, none of which should be breaking. Additionally, the lion’s share of user API endpoints remain stable (unless you use proof-of-work specific methods such as eth_getWork).

That said, most applications on Ethereum involve much more than on-chain contracts. Now is the time to ensure that your front-end code, tooling, deployment pipeline and other off-chain components work as intended. We strongly recommend that developers run through a complete testing & deployment cycle on Sepolia, Ropsten or Kiln and report any issues with tools or dependencies to those projects’ maintainers. If you are unsure where to open an issue, please use this repository.

Additionally, you should note that all testnets aside from Sepolia and Goerli will be deprecated post-merge. If you are a user of Ropsten, Rinkeby or Kiln, you should plan to migrate to Goerli or Sepolia. More information about this can be found here.

As an Ethereum user or Ether holder, is there anything I need to do?

No. The Ethereum mainnet is not affected by this testnet. Subsequent announcements will be made on this blog before mainnet’s transition.

As a miner, is there anything I need to do?

No. If you are mining on the Ethereum mainnet, you should be aware that the network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.

As a validator, can I withdraw my stake?

No. The Merge is the most complicated upgrade to Ethereum to date. To minimize risks of network disruptions, a minimal approach was taken which excluded any non-transition changes from this upgrade.

Withdrawals from the Beacon Chain will likely be introduced in the first upgrade after The Merge. Specifications for both the consensus and execution layers are in progress.

I have more questions, where can I ask them?

The EthStaker community has set up a discord channel to answer staker and node operator questions. You can join their discord here and then use the #goerli-prater channel for assistance. As mentioned above, EthStaker will also host a Merge Validator Preparation Workshop on July 29.

Additionally, a Merge Community Call is scheduled for August 12, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members. Note that this community call is expected to happen after the Goerli/Prater merge.

wen merge?

As of the publication of this post, the time for the Ethereum mainnet proof-of-stake transition has not been set. Any source claiming otherwise is likely to be a scam. Updates will be posted on this blog. Please stay safe!

Assuming no issues are found during the Goerli/Prater merge, once clients have feature-complete releases, a slot height will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a total difficulty value will be set for the mainnet transition. Clients will then make releases that enable The Merge on mainnet. These will be announced on this blog and in other community publications.

However, if issues are found at any point in the process or test coverage is judged to be insufficient, these things will be addressed before continuing with the deployment process.

Only then will it be possible to estimate the exact date for The Merge.

In other words, 🔜.


إعلان دمج غويرلي/ براتر

  • في آخر انتقال لإثبات حصة شبكة التجريب، ستندمج غويرلي مع براتر. وستحتفظ شبكة غويرلي/ براتر مجتمعة باسم غويرلي بعد الدمج.
  • بيلاتريكس، ترقية براتر الجاهزة للدمج ستحدث في الحقبة 112260، المتوقعة في 12:24 مساءً بالتوقيت العالمي المنسق في 4 أغسطس 2022.
  • بعد تنشيط بيلاتريكس، سيحدث دمج غويرلي/ براتر عندما يواجه غويرلي صعوبة إجمالية قدرها 10790000، متوقعة بين 6-12 أغسطس 2022.
  • بعد الدمج، ستبقى مجموعة مصادقة غويرلي مفتوحة لفرادى المراهنين لتشغيل محققي شبكات التجريب. يمكن للمراهنين الذين يرغبون في بدء التحقق من صحة غويرلي/ براتر أن يفعلوا ذلك في منصة تشغيل براتر.

الخلفية

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

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

يختلف الدمج عن ترقيات إثيريوم السابقة بطريقتين. أولًا، يحتاج مشغلو العقدة إلى تحديث كل من طبقة إجماع الآراء (CL) والعملاء (EL) من طبقة التنفيذ جنبًا إلى جنب، بدلًا من مجرد واحد من الاثنين. ثانيًا، يتم تفعيل الترقية على مرحلتين: الأولى في ارتفاع الحقبة على سلسلة المنارة والثانية عند ضرب قيمة إجمالي الإعداد الشبكي للحوسبةعلى طبقة التنفيذ.

ترقية المعلومات

التوقيت

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

تم جدولة الترقية بيلاتريكس للحقبة** 112260** على سلسلة منارة براتر، متوقعة في 12:24 مساءً بالتوقيت العالمي المنسق في 4 أغسطس 2022. باريس، جزء طبقة التنفيذ من الانتقال، سيتم تشغيله بالوصول إلى إجمالي الإعداد الشبكي للحوسبة (TTD) من 10790000 على غويرلي، متوقعة بين 6-12 أغسطس 2022.

بمجرد أن تتجاوز طبقة التنفيذ TTD، سيتم إنتاج الكتلة التالية فقط بواسطة مدقق سلسلة المنارة. نعتبر أن الدمج قد اكتمل بمجرد أن تنتهي سلسلة المنارة من هذه الكتلة. بافتراض ظروف الشبكة الطبيعية، يجب أن يحدث هذا في حقبتين، أو حوالي 13 دقيقة، بعد أن تنطلق كتلة إجمالي الإعداد الشبكي للحوسبة بالمحطة-TTD اللاحقة!

علامة كتلة JSON-RPC جديدة، تم الانتهاء منها، تعرض أحدث كتلة نهائية أو خطأ في حالة عدم وجود كتلة ما بعد الدمج. يمكن استخدام هذه العلامة للتطبيقات للتحقق مما إذا كان الدمج قد اكتمل. وبالمثل، يمكن للعقود الذكية الاستعلام عن كود التشغيل "الإعداد الشبكي" (0x44)، الذي يحمل اسم PREVRANDAO بعد الدمج، لتحديد ما إذا كان الدمج قد حدث أم لا. ونوصي مقدمي خدمات الهياكل الأساسية برصد استقرار الشبكة عامةً بالإضافة إلى وضع الإنهاء.

إصدارات العميل

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

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

طبقة إجماع الآراء

الاسم الإصدار الرابط
لايتهاوس جيردود كلوكبرج (إصدار 2.4.0) تنزيل
لودجستار الإصدار 0.41.0 تنزيل
نمبس الإصدار 22.7.0 تنزيل
بريسم الإصدار 2.1.4-rc.0 تنزيل
تيكو 22.7.0 تنزيل

طبقة التنفيذ

الاسم الإصدار الرابط
بيسو 22.7.0-RC3 تنزيل
إيريغون 2022.07.03-ألفا تنزيل
جو-إثيريوم (جيث) الإصدار 1.10.21 تنزيل
نيثرمايند 1.13.5 تنزيل

ترقية المواصفات

التغييرات الحاسمة في إجماع الآراء للدمج محددة في موضعين:

وبالإضافة إلى ذلك، هناك نوعان من المواصفات الأخرى تغطي كيفية تفاعل عملاء طبقة إجماع الآراء والتنفيذ:

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

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

بصفتي مشغل العقدة، ماذا علي أن أفعل؟

بعد الدمج، ستجمع عقدة إثيريوم كاملة بين عميل طبقة إجماع الآراء (CL)، الذي يشغل إثبات الحصة على سلسلة المنارة، وبين عميل طبقة التنفيذ (EL)، الذي يدير حالة المستخدم ويشغل الحسابات المرتبطة بالمعاملات. ويتم التواصل بينهما عبر منفذ مُصادق باستخدام مجموعة طرق JSON RPC جديدة، يُطلق عليها اسم واجهة برمجة تطبيقات المحرك. يقوم عميل EL وCL بمصادقة بعضهما البعض باستخدام المفتاح السري JWT. يجب على مشغلي العقد الاطِّلاع على مستندات عملائهم للحصول على إرشادات حول كيفية إنشائها وتكوينها.

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

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

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

كمراهن، ماذا عليّ أن أفعل؟

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

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

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

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

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

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

لماذا التقدير لـ الإعداد الشبكي للحوسبة بالمحطة واسع للغاية؟

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

كتطبيق أو مبرمج أدوات، ماذا علي أن أفعل؟

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

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

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

بصفتي مستخدم إثيريوم أو حامل لعملة إثيريوم، هل عليّ فعل شيء؟

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

بصفتي عامل منجم، هل عليّ فعل شيء؟

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

بصفتي برنامج مدقق، هل يمكنني سحب حصتي؟

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

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

لدي المزيد من الأسئلة، أين يمكنني أن أطرحها؟

قام مجتمع إيثستاكر بإنشاء قناة discord للإجابة على أسئلة المراهن وعميل العقدة. يمكنك الانضمام إلى discord هنا ثم استخدام قناة #goerli-prater للمساعدة. يستضيف فريق إيثستاكر أيضًا ورشة تحضير لبرنامج مدقق الدمج في 29 يوليو.

تم تحديد موعد مجتمع الدمج في 12 يونيو في تمام الساعة 14:00 بالتوقيت العالمي المنسق. سيكون مطورو وباحثو العملاء متاحين للإجابة على أسئلة عملاء العقدة والمراهنين والبنية الأساسية وموفري الأدوات وأعضاء المجتمع. لاحظ أنه من المتوقع أن يحدث هذا الاتصال المجتمعي بعد دمج جويرلي/ براتر.

متى يحدث الدمج؟

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

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

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

وعندئذٍ فقط، سيكون ممكنًا تقدير تاريخ محدد للدمج.

بعبارة أخرى، 🔜.


Ankündigung der Goerli/Prater-Zusammenführung

  • Im Zuge der letzten Proof-of-Stake-Umstellung des Testnetzes wird Goerli mit Prater zusammengeführt. Die beiden Netzwerke fusionieren unter dem Namen Goerli.
  • Prater wird durch das Upgrade Bellatrix auf die Zusammenführung vorbereitet. Dieses Uprade erfolgt in der Epoche 112260 nach derzeitiger Erwartung am 4. August 2022 um 12:24 Uhr UTC.
  • Nach der Aktivierung von Bellatrix erfolgt die Zusammenführung von Goerli und Prater, sobald Goerli vermutlich zwischen dem 6. und 12. August 2022 einen Total Difficulty-Wert von 10790000 erreicht.
  • Nach der Zusammenführung bleibt Goerlis Validator-Set für die Ausführung von Testnetz-Validatoren für einzelne Staker offen. Staker können Goerli/Prater-Validatoren über das Prater-Launchpad starten.

Hintergrund

Nach jahrelanger Arbeit am Proof-of-Stake für Ethereum haben wir die letzte Testphase erreicht: die Bereitstellung von Testnetzen.

Nach mehreren Devnets, Shadow Forks und Zusammenführungen in veralteten Testnetzen wurde Sepolia kürzlich auf Proof-of-Stake umgestellt. Jetzt verbleibt nur noch ein Testnetz: Goerli und die zugehörige Beacon Chain Prater.

Die Zusammenführung unterscheidet sich in zwei Merkmalen von früheren Ethereum-Upgrades. Zum einen müssen Node-Betreiber ihre Clients sowohl auf Konsensebene (CL) als auch auf Ausführungsebene (EL) gleichzeitig aktualisieren, also nicht nur jeweils die Clients einer der beiden Ebenen. Zum anderen wird das Upgrade in zwei Phasen aktiviert: Die erste Phase, genannt Bellatrix, erfolgt auf einer Epochenhöhe der Beacon Chain und die zweite, genannt Paris, sobald auf Ausführungsebene ein bestimmter Total Difficulty-Wert erreicht ist.

Informationen zum Upgrade

Zeitplan

Die Zusammenführung ist ein zweistufiger Prozess. Als Erstes erfolgt ein Netzwerkupgrade (Bellatrix) auf Konsensebene, ausgelöst durch eine Epochenhöhe. Anschließend erfolgt die Umstellung der Ausführungsebene von Proof-of-Work zu Proof-of-Stake (Paris), ausgelöst durch einen bestimmten Total Difficulty-Wert, die sogenannte Terminal Total Difficulty (TTD).

Das Bellatrix-Upgrade auf der Beacon Chain Prater ist für Epoche 112260 geplant, nach derzeitiger Erwartung am 4. August 2022 um 12:24 Uhr UTC. Paris, die Umstellung auf Ausführungsebene, wird durch Erreichen einer Terminal Total Difficulty (TTD) von 10790000 auf Goerli ausgelöst, erwartet zwischen dem 6. und 12. August 2022.

Nach Überschreiten der TTD auf Ausführungsebene wird der nächste Block vollständig durch einem Beacon Chain-Validator erzeugt. Die Zusammenführung wird als abgeschlossen betrachtet, sobald die Beacon Chain diesen Block fertiggestellt hat. Unter normalen Netzwerkbedingungen sollte die Erstellung des ersten Blocks nach Erreichen der TTD zwei Epochen bzw. etwa 13 Minuten dauern.

Das neu eingeführte JSON-RPC-Block-Tag finalized gibt den zuletzt fertiggestellten Block bzw. einen Fehler zurück, wenn nach der Zusammenführung kein solcher Block vorhanden ist. Anhand dieses Tags lässt sich für Anwendungen prüfen, ob die Zusammenführung abgeschlosen ist. Ebenso können Smart Contracts den Opcode DIFFICULTY (0x44) abfragen, der nach der Zusammenführung in PREVRANDAO umbenannt wurde, um festzustellen, ob die Zusammenführung abgeschlossen ist. Wir empfehlen Infrastrukturanbietern, zusätzlich zum Finalisierungsstatus auch die gesamte Netzwerkstabilität zu überwachen.

Client-Versionen

Die folgenden Client-Versionen unterstützen die Zusammenführung der Goerli- und Prater-Testnetze. Node-Betreiber müssen sowohl einen Client auf Ausführungsebene als auch auf Konsensebene ausführen, um während und nach der Zusammenführung im Netzwerk zu bleiben.

Bei der Auswahl des auszuführenden Clients sollten Validatoren insbesondere die Risiken berücksichtigen, die die Ausführung eines Majority-Clients sowohl auf der Ausführungsebene (EL) als auch auf der Konsensebene (CL) mit sich bringt. Eine Erläuterung der Risiken und Folgen finden Sie hier. Eine Schätzung der aktuellen EL- und CL-Client-Verteilung sowie Leitfäden für den Wechsel von einem Client zu einem anderen finden Sie hier.

Konsensebene

Ausführungsebene

Upgrade-Spezifikationen

Konsenskritische Änderungen für die Zusammenführung werden an zwei Stellen angegeben:

  • Änderungen auf Konsensebene im Ordner bellatrix des Repositorys der Konsensspezifikationen
  • Änderungen auf Ausführungsebene in der Spezifikation Paris im Repository der Ausführungsspezifikationen

Zwei weitere Spezifikationen legen darüber hinaus die Interaktion der Clients auf Konsens- und Ausführungsebene fest:

  • Die im Repository für Ausführungs-APIs angegebene Engine-API wird für die Kommunikation zwischen der Konsens- und Ausführungsebene genutzt.
  • Optimistic Sync, angegeben im Ordner sync des Repositorys der Konsensspezifikationen, wird von der Konsensebene zum Importieren von Blöcken bei der Synchronisierung der Clients auf Ausführungsebene verwendet. Zudem bietet es eine teilweise Ansicht des Chain-Heads, vom ersten zum letzten.

Häufig gestellte Fragen

Was muss ich als Node-Betreiber machen?

Nach der Zusammenführung führt ein vollständiger Ethereum-Node einen Client auf Konsensebene (CL), der den Proof-of-Stake auf der Beacon Chain durchführt, mit einem Client auf Ausführungsebene (EL) zusammen, der die Benutzerstatus verwaltet und die Verarbeitung von Transaktionen durchführt. Die Kommunikation erfolgt über einen authentifizierten Port mittels eines neuen Satzes an JSON RPC-Methoden, die sogenannte Engine-API. Der EL- und der CL-Client authentifizieren sich gegenseitig mit einem JWT-Geheimnis. Informationen zur Client-Erstellung und -Konfiguration finden Node-Betreiber in der Dokumentation ihrer Clients.

Wenn Sie also bereits einen Node auf der Beacon Chain ausführen, müssen Sie nun zusätzlich einen Client auf der Ausführungsebene betreiben. Ähnlich verhält es sich, wenn Sie einen Node im aktuellen Proof-of-Work-Netzwerk ausführen. Dann müssen Sie nun auch einen Client auf Konsensebene betreiben. Damit diese Clients sicher miteinander kommunizieren können, muss an beide Clients ein JWT-Token übergeben werden. Eine Zusammenfassung der Anweisungen zur Ausführung eines Node im Goerli/Prater-Netzwerk finden Sie hier.

Wir möchten betonen, dass sich die Ausführung eines Beacon-Node von der Ausführung eines Validator-Clients unterscheidet, obwohl beide Teile der Client-Versionen auf Konsensebene sind. Staker müssen beide Komponenten ausführen, Node-Operatoren hingegen nur den Beacon-Node. In diesem Beitrag werden die Unterschiede zwischen den beiden Komponenten ausführlicher erläutert.

Beachten Sie außerdem, dass für beide Ebenen ein eigener Peer-Satz verwaltet werden muss und eigene APIs erforderlich sind. Die Beacon– und JSON RPC-APIs funktionieren weiterhin erwartungsgemäß.

Was muss ich als Staker machen?

Die Goerli/Prater-Zusammenführung ist Ihre letzte Gelegenheit vor der Umstellung des Mainnet sicherzustellen, dass Ihre Validatoren korrekt konfiguriert sind. Das Durchlaufen der Umstellung wird dringend empfohlen, um unerwartete Probleme im Mainnet zu vermeiden.

Wie bereits erläutert, müssen Validatoren auf der Beacon Chain nach der Zusammenführung einen Client auf Ausführungsebene ausführen, und zwar zusätzlich zu den Clients auf Konsensebene. Diese Praxis wurde bereits vor der Zusammenführung dringend empfohlen, jedoch konnten Validatoren diese Funktionen auch an Drittanbieter auslagern. Das war möglich, da die einzigen auf der Ausführungsebene erforderlichen Daten Aktualisierungen am Einlagenvertrag waren.

Nach der Zusammenführung müssen Validatoren sicherstellen, dass die Transaktionen in den von ihnen erstellten und bescheinigten Blöcken gültig sind. Hierzu muss jeder Beacon-Node mit einem Client auf Ausführungsebene gekoppelt werden. Nach wie vor ist es jedoch möglich, mehrere Validatoren mit einer einzigen Kombination aus Beacon-Node und Client auf Ausführungsebene zu koppeln. Validatoren erhalten dadurch zwar mehr Verantwortung, für die von ihnen vorgeschlagenen Blöcke jedoch auch Anspruch auf Transaktionsprioritätsgebühren, die bislang Minern zustehen.

Validatorprämien sammeln sich auf der Beacon Chain an und können erst nach einem Upgrade entnommen werden, während Transaktionsgebühren weiterhin auf der Ausführungsebene bezahlt, verbraucht und verteilt werden. Validatoren können jede beliebige Ethereum-Adresse als Empfänger für Transaktionsgebühren angeben.

Geben Sie nach der Aktualisierung Ihres Clients auf Konsensebene im Zuge der Konfiguration Ihres Validator-Clients in fee recipient eine von Ihnen kontrollierte Adresse an, an die Ihre Transaktionsgebühren gesendet werden sollen. Wenn Ihr Staking über einen Drittanbieter erfolgt, entscheidet Ihr Provider, wie diese Gebühren verrechnet werden.

Im Staking-Launchpad von Prater finden Sie eine Checkliste für die Bereitschaft für die Zusammenführung, anhand der Sie als Staker überprüfen können, ob Sie alle erforderlichen Prozessschritte abgeschlossen haben. Darüber hinaus bietet das EthStaker-Team am 29. Juli 2022 einen Workshop für Validatoren zur Vorbereitung auf die Zusammenführung an.

Warum lässt sich das Datum, an dem die Terminal Total Difficulty erreicht wird, nicht genauer festlegen?

Gegenüber Block- oder Epochenhöhen erschwert die Volatilität der inkrementellen Schwierigkeit pro Block die Einschätzung des voraussichtlichen TTD-Fensters erheblich. Daher lässt sich der erwartete Zeitraum nicht enger eingrenzen. Für Benutzer gilt zu beachten, dass dies aufgrund der Hash-Ratenschwankungen in Proof-of-Work auch auf die Umstellung des Mainnet zutrifft.

Was muss ich als Anwendungs- oder Toolentwickler machen?

Nach der Live-Schaltung der Zusammenführung auf Goerli haben Sie ein letztes Mal die Gelegenheit, im Zuge der Proof-of-Stake-Umstellung sowie im Kontext nach der Zusammenführung sicherzustellen, dass Ihr Produkt erwartungsgemäß funktioniert. Wie bereits in einem früheren Beitrag erwähnt, hat die Zusammenführung nur minimale Auswirkung auf wenige der unter Ethereum bereitgestellten Verträge, wobei keiner davon in seiner Funktionsweise beeinträchtigt sein sollte. Der größte Teil der API-Endpunkte der Benutzer sollte zudem stabil bleiben, zumindest, wenn Sie keine Proof-of-Work-spezifischen Methoden wie zum Beispiel eth_getWork nutzen.

Jedoch umfassen die meisten Anwendungen auf Ethereum mehr als nur On-Chain-Verträge. Daher ist dies ein guter Zeitpunkt, zu überprüfen, ob Ihr Front-End-Code, Ihre Tools, die Bereitstellungspipeline und weitere Off-Chain-Komponenten erwartungsgemäß funktionieren. Wir empfehlen Entwicklern daher die Durchführung eines vollständigen Test- und Bereitstellungszyklus auf Sepolia, Ropsten oder Kiln sowie die Zurückmeldung aller Probleme mit Tools oder Abhängigkeiten an die Projektverantwortlichen. Wenn Sie sich nicht sicher sind, an wen Sie Ihre Anfrage richten sollen, finden Sie in diesem Repository nähere Informationen.

Beachten Sie zudem, dass alle Testnetze, ausgenommen Sepolia und Goerli, nach der Zusammenführung stillgelegt werden. Als Benutzer von Ropsten, Rinkeby oder Kiln sollten Sie die Migration auf Goerli oder Sepolia planen. Weitere Informationen finden Sie hier.

Muss ich als Ethereum-Benutzer oder Ether-Inhaber Umstellungen vornehmen?

Nein. Das Ethereum-Mainnet ist von diesem Testnetz nicht betroffen. Vor der Umstellung des Mainnets erfolgen in diesem Blog entsprechende Ankündigungen.

Muss ich als Miner Umstellungen vornehmen?

Nein. Wenn Sie Miner im Ethereum-Mainnet sind, sollte Ihnen bewusst sein, dass das Netzwerk nach der Zusammenführung vollständig im Proof-of-Stake-Modus arbeitet. Ab dem Zeitpunkt der Umstellung wird Mining im Netzwerk nicht mehr möglich sein.

Kann ich als Validator meinen Einsatz zurückziehen?

Nein. Die Zusammenführung ist das bislang komplizierteste Upgrade von Ethereum. Um das Risiko von Netzwerkunterbrechungen zu minimieren, wurde ein minimaler Ansatz gewählt. Dabei sind Änderungen, die nicht mit der Umstellung zusammenhängen, von diesem Upgrade ausgeschlossen.

Die Möglichkeit der Entnahme von Einsätzen aus der Beacon Chain wird voraussichtlich mit dem ersten Upgrade nach der Zusammenführung eingeführt. Spezifikationen sowohl für die Konsens- als auch die Ausführungsebene werden derzeit ausgearbeitet.

Ich habe weitere Fragen. An wen kann ich diese richten?

Die EthStaker-Community hat einen Discord-Kanal eingerichtet, auf dem die Community Fragen von Stakern und Node-Betreibern beantwortet. Dem Discord der Community können Sie hier beitreten und bei Fragen zum Kanal #goerli-prater wechseln. Wie bereits erwähnt, bietet EthStaker am 29. Juli 2022 auch einen Workshop für Validatoren zur Vorbereitung auf die Zusammenführung an.

Für den 12. August, 14:00 UTC, ist darüber hinaus ein Community Call zur Zusammenführung geplant. Hier werden Client-Entwickler und -Wissenschaftler Fragen von Node-Betreibern, Stakern, Infrastruktur- und Toolanbietern sowie Community-Mitgliedern beantworten. Dieser Community Call wird voraussichtlich jedoch nach der Goerli/Prater-Zusammenführung stattfinden.

Wann erfolgt die Zusammenführung?

Zum Zeitpunkt der Veröffentlichung dieses Beitrags war das Umstellungsdatum auf Proof-of-Stake für das Ethereum-Mainnet noch nicht festgelegt. Jede andere Behauptung ist falsch. Verlässliche Neuigkeiten erhalten Sie in diesem Blog. Halten Sie sich hier informiert!

Sofern bei der Goerli/Sepolia-Zusammenführung keine Probleme auftreten und sobald Client-Versionen mit stabilen Funktionen vorliegen, werden auf der Beacon Chain eine Slot-Höhe für das Bellatrix-Upgrade sowie für die Umstellung des Mainnets die Terminal Total Difficulty festgelegt. Für die Clients werden dann Versionen veröffentlicht, die die Zusammenführung auch im Mainnet unterstützen. Eine entsprechende Ankündigung erfolgt in diesem Blog und in weiteren Community-Publikationen.

Falls jedoch an irgendeiner Stelle während dieses Prozesses Probleme auftreten oder die Testabdeckung als unzureichend eingeschätzt wird, wird der Bereitstellungsprozess erst fortgesetzt, wenn die erkannten Probleme behoben sind.

Erst dann kann das genaue Datum der Zusammenführung bestimmt werden.

Mit anderen Worten: 🔜.


Anuncio de fusión Goerli/Prater

  • Para la última transición de la red de prueba de participación, Goerli se fusionará con Prater. La red combinada Goerli/Prater conservará el nombre de Goerli después de la fusión.
  • Bellatrix, la actualización del Prater que lo prepara para la fusión se producirá en la época 112260, esperada a las 12:24PM UTC el 4 de agosto de 2022.
  • Después de activar la Bellatrix, la fusión Goerli/Prater se producirá cuando Goerli alcance una dificultad total de 10790000, se espera que ocurra entre el 6 y 12 de agosto de 2022.
  • Después de la fusión, el conjunto de validadores de Goerli permanecerá abierto para que los participantes individuales ejecuten validadores de redes de pruebas. Los participantes que deseen iniciar un validador de Goerli/Prater pueden hacerlo en la plataforma de lanzamiento de Prater.

Contexto

Tras años de trabajo para llevar la prueba de participación a Ethereum, ahora entramos en la fase final de pruebas, es decir, en las implementaciones de la red de prueba.

Después de varias devnet, bifurcaciones paralelas y fusiones en redes de pruebas obsoletas, Sepolia ha pasado recientemente a la prueba de participación. Ahora, solo queda una red de prueba más, Goerli, y su cadena de baliza asociada, Prater.

La fusión se distingue de anteriores actualizaciones de Ethereum en dos aspectos fundamentalmente: en primer lugar, los operadores de nodo tienen que actualizar tanto sus clientes de capa de ejecución, como de consenso a la par, en vez de uno de los dos. Y, en segundo, la actualización se activa en dos fases: la primera, llamada Bellatrix, a la altura de una época la cadena de baliza y, la segunda, llamada París, al llegar a un valor de Dificultad Total en la capa de ejecución.

Información acerca de la actualización

Sincronización

La fusión es un proceso de dos pasos. Empieza con la actualización de la red, Bellatrix, en la capa de consenso, desencadenada por una altura de época. Seguida de la transición de la capa de ejecución de una prueba de trabajo a una prueba de participación, París, provocada por un umbral de Dificultad Total específico, conocido como Dificultad Total del Terminal (TTD).

La actualización Bellatrix está programada para la época 112260 en la cadena de baliza del Prater, esperada a las 12:24PM UTC del 4 de agosto de 2022. París, la porción de la capa de ejecución de la transición, se activará al alcanzar una Dificuldad Total del Terminal (TTD) de 10790000 en Goerli, se espera que ocurra entre el 6 y el 12 de agosto de 2022.

Una vez que la capa de ejecución haya superado la TTD, un validador de cadena de baliza producirá por completo el siguiente bloque. Consideramos que la fusión se ha completado una vez que la cadena de baliza haya concluido con este bloque. Asumiendo que se den las condiciones normales de la red, esto debería suceder 2 épocas, o aproximadamente 13 minutos, después de alcanzar el primer bloque después de la TTD.

Una nueva etiqueta de bloque JSON-RPC finalizado devuelve el último bloque finalizado, o un error si no existe ningún bloque tras la fusión. Esta etiqueta sirve para que las aplicaciones comprueben si se ha completado la fusión. Del mismo modo, los contratos inteligentes pueden consultar el opcode DIFFICULTY (0x44), rebautizado como PREVRANDAO tras la fusión, para determinar si se ha producido la fusión. Recomendamos que los proveedores de infraestructuras controlen la estabilidad total de la red, además del estado de finalización.

Versiones del cliente

Los siguientes lanzamientos de cliente soportan la fusión a través de las redes de prueba Goerli y Prater. Los operadores de nodo deben ejecutar tanto un cliente de capa de ejecución y de capa de consenso para permanecer en la red durante y después de la fusión.

A la hora de elegir el cliente de ejecución, los validadores deben prestar especial atención a los riesgos derivados de gestionar un cliente principal, tanto en la EL como en la CL. Aquí encontrará una explicación detallada de tales riesgos y de las consecuencias que acarrean. Se puede encontrar una estimación de la distribución actual de los clientes EL y CL y guías para cambiar de un cliente a otro aquí.

Capa de consenso

Capa de ejecución

Especificaciones de la actualización

Los cambios fundamentales de consenso para la fusión se especifican en dos fases:

  • Los cambios para la capa de consenso en el directorio Bellatrix de especificaciones de consenso.
  • Los cambios de la capa de ejecución en la especificación París en el directorio de especificaciones de ejecución.

Además de estas, otras dos especificaciones cubren la forma en la que interactúan los clientes de capa de ejecución y capa de consenso:

  • La Engine API, especificada en el directorio execution-apis, se utiliza para la comunicación entre las capas de consenso y ejecución.
  • La capa de consenso utiliza la Optimistic Sync, especificada en la carpeta sync del directorio consenso-especificaciones para importar bloques mientras el cliente de capa de ejecución se está sincronizando, y ofrece una visión parcial del principio de la cadena desde la primera hasta la segunda.

Preguntas frecuentes

¿Qué debo hacer como operador de nodos?

Después de la fusión, un nodo completo de Ethereum estará formado por una combinación de un cliente de capa de consenso (CL), que ejecuta pruebas de participación en la cadena de baliza, y un cliente de capa de ejecución (EL), que gestiona el estado de los usuarios y se encarga de los cálculos asociados a las transacciones. Estos se comunican a través de un puerto autenticado usando un nuevo conjunto de métodos JSON RPC denominado Engine API. El cliente EL y CL se autentican utilizando un secreto JWT. Los operadores de nodos deben referirse a la documentación de sus clientes para obtener instrucciones sobre cómo generarlos y configurarlos.

Dicho de otra forma, si antes ya ejecutaba un nodo en la cadena de baliza, ahora debe hacerlo también con un cliente de capa de ejecución. De la misma manera, si antes ejecutaba un nodo en la red actual de prueba de trabajo, ahora deberá ejecutar un cliente de capa de consenso. Para que se comuniquen de forma segura, se debe pasar un token JWT a cada cliente. Las instrucciones de resumen para ejecutar un nodo en la red Goerli/Prater se pueden encontrar aquí..

Cabe recalcar que si bien ambos son parte de las versiones de cliente de capa de consenso, ejecutar un nodo de baliza es distinto de ejecutar un cliente validador. Los participantes deben ejecutar ambos, sin embargo los operadores de nodos solo tienen que ejecutar el primero. Este artículo explica la diferencia entre ambos componentes con más detalle.

Además, tenga en cuenta que cada capa mantendrá un conjunto independiente de pares y expondrá sus propias API. La baliza y las API JSON RPC continuarán funcionando según lo previsto.

¿Qué necesito hacer como participante?

La fusión Goerli/Prater es su última oportunidad para asegurarse de que sus validadores estén correctamente configurados antes de la transición a la red principal. Se recomienda encarecidamente que se ejecute la transición para evitar cualquier problema inesperado en la red principal.

Tal y como se ha explicado anteriormente, los validadores en la cadena de baliza necesitarán ejecutar un cliente de capa de ejecución después de la fusión, además de sus clientes de capa de consenso. Algo que se recomendaba encarecidamente hacer antes de la fusión, aunque puede que los validadores hayan externalizado estas funciones a proveedores de terceros. Esta opción era posible, porque los únicos datos que se necesitaban en la capa de ejecución eran las actualizaciones del contrato de depósito.

Después de la fusión, los validadores tendrán que asegurarse de que las transacciones en bloques que crean y certifican son válidas. Para ello, cada nodo de baliza debe estar emparejado con un cliente de capa de ejecución. Tenga en cuenta que varios validadores todavía pueden emparejarse con una única combinación de nodo de baliza y cliente de capa de ejecución. Aunque de este modo aumentan las responsabilidades de los validadores, el validador que propone un bloque también obtiene derecho a las comisiones de prioridad de transacciones asociadas (que actualmente se destinan a los mineros).

Mientras que las recompensas del validador se acumulan en la cadena de baliza y requieren una posterior actualización para poder retirarlas, las comisiones de transacción seguirán pagándose, registrándose y distribuyéndose en la capa de ejecución. Los validadores pueden especificar cualquier dirección de Ethereum como destinatarios de las comisiones de transacciones.

Después de actualizar su cliente de consenso, asegúrese de establecer el destinatario de comisión como parte de las configuraciones de su cliente validador para asegurar que las comisiones de transacción se envían a una dirección que usted controla. Si usted ha apostado usando un proveedor de terceros, corresponde a su proveedor seleccionado especificar cómo se asignan estas cuotas.

La plataforma de lanzamiento de participación Prater tiene una Lista de comprobación de preparación para la fusión que los participantes pueden usar para asegurarse de que han pasado por cada paso del proceso. El equipo de EthStaker también ha organizado un taller de preparación del validador para la fusión el 29 de julio.

¿Por qué es tan amplia la fecha de Diferencia Total del Terminal?

La volatilidad de la dificultad incremental por bloque hace que la estimación de una ventana para la TTD sea más difícil que con un bloque o una altura de épocas, de ahí que el rango esperado sea más amplio. Los usuarios deben tener en cuenta que este también será el caso de la transición de la red principal debido a cambios en la tasa de hash de prueba de trabajo.

¿Qué debo hacer como desarrollador de aplicaciones o herramientas?

Con la fusión ejecutándose en Goerli, es su última oportunidad de asegurarse de que su producto funciona como es debido a través de la transición a la prueba de participación y en un contexto después de la fusión. Como explicamos en una publicación anterior, la fusión tendrá un mínimo impacto en un subconjunto de contratos implementados en Ethereum, ninguno de los cuales se rescindirá. Además, la mayor parte de los puntos finales de la API del usuario permanecen estables (a menos que esté usando métodos específicos de prueba de trabajo como eth_getWork).

Dicho esto, la mayoría de aplicaciones de Ethereum implican mucho más que contratos en cadena. Ahora es el momento de asegurarse de que su código front-end, herramientas, canal de implementación y otros componentes fuera de cadena funcionan como es debido. Recomendamos encarecidamente que los desarrolladores ejecuten un ciclo completo de prueba e implementación en Sepolia, Ropsten o Kiln y que informen de cualquier problema relacionado con herramientas o dependencias a los mantenedores de esos proyectos. Si duda sobre en qué casos debe informar de una incidencia, consulte este directorio.

Además, hay que tener en cuenta que todas las redes de pruebas aparte de Sepolia y Goerli estarán obsoletas después de la fusión. Si usted es un usuario de Ropsten, Rinkeby o Kiln, debe planificar la migración a Goerli o Sepolia. Puede encontrar más información sobre esto aquí.

¿Hay algo que necesite hacer como usuario de Ethereum, o titular de Ether?

No. La red principal de Ethereum no se ve afectada por esta red de prueba. En este blog, iremos colgando próximamente anuncios antes de la transición de la red principal.

¿Hay algo que yo necesite hacer como minero?

No. Si está minando la red principal en Ethereum, deberá tener en cuenta que después de la fusión cada red funcionará completamente como prueba de participación. Y cuando eso ocurra, no se podrá minar en la red.

¿Puedo retirar mi participación como validador?

No. La fusión es la actualización más compleja de Ethereum realizada hasta la fecha. Para minimizar los riesgos de que se produzca una interrupción de la red, se ha adoptado un enfoque mínimo que excluye cualquier cambio no relacionado con la transición de esta actualización.

Es posible que se permitan las retiradas de la cadena de bloques en la primera actualización que se haga después de la fusión. Se están elaborando las especificaciones para ambas capas, de consenso y de ejecución.

Tengo más preguntas, ¿dónde puedo hacerlas?

La comunidad EthStaker ha establecido un canal Discord para responder a las preguntas de participantes y de operadores de nodos. Puede unirse a su Discord aquí y luego usar el canal #goerli-prater como ayuda. Como ya se ha mencionado, el equipo de EthStaker también ha organizado un taller de preparación del validador para la fusión el 29 de julio.

Además, está programada una llamada comunitaria sobre la fusión el 12 de agosto a las 14:00 UTC. Los desarrolladores de clientes e investigadores estarán disponibles para responder preguntas de operadores de nodos, participantes, infraestructura y proveedores de herramientas y miembros de la comunidad. Tenga en cuenta que se espera que esta llamada comunitaria suceda después de la fusión de Goerli/Prater.

¿Cuándo se producirá la fusión?

A fecha de publicación de esta notificación, la transición de la prueba de participación de la red principal de Ethereum aún no se ha fijado. Cualquier información que apunte a una fecha concreta debe considerarse falsa. En este blog se irá informando de cualquier avance. ¡Vele por su seguridad!

Asumiendo que no se encuentren problemas durante la fusión Goerli/Prater, una vez que los clientes tengan versiones con todas las funciones incorporadas se elegirá una altura de ranura para la actualización de Bellatrix en la cadena de baliza de la red principal y se establecerá un valor de dificultad total para la transición de la red principal. Los clientes podrán entonces hacer versiones que permitan la fusión en la red principal. Estas se anunciarán en este blog y en otras publicaciones comunitarias.

Sin embargo, si se encuentran problemas en cualquier momento del proceso o la cobertura de la prueba se considera insuficiente, se abordará antes de continuar con el proceso de implementación.

Solo entonces será posible calcular la fecha exacta de la fusión.

Es decir, 🔜 (pronto).


Annonce de fusion de Goerli/Prater

  • Goerli fusionnera avec Prater pour la dernière transition du réseau de test vers la preuve d’enjeu. Le réseau fusionné Goerli/Prater continuera de s’appeler Goerli après la fusion.
  • Bellatrix, la mise à niveau de Prater le préparant à La Fusion aura lieu à la période 112260, attendue à 12h24 UTC le 4 août 2022.
  • Après l’activation de Bellatrix, la fusion Goerli/Prater interviendra lorsque Goerli atteindra une valeur de difficulté totale de 10790000, prévue entre le 6 et le 12 août 2022.
  • Après la fusion, la chaîne de validateurs de Goerli restera ouverte afin que des stalkers individuels puissent faire appel à des validateurs de réseaux de test. Les stakers qui souhaitent lancer un validateur Goerli/Prater peuvent le faire sur la plateforme de lancement Prater.

Contexte

Après des années de travail pour conférer des preuves d’enjeu à Ethereum, nous allons maintenant entrer dans la phase finale de test avec les déploiements des réseaux de test !

Après plusieurs devnets, des fourches fantômes et des fusions sur des réseaux de test obsolètes, Sepolia a récemment opéré une transition vers la preuve d’enjeu. Il ne reste plus désormais qu’un réseau de test : Goerli, et sa Chaîne phare, Prater.

La Fusion se distingue des précédentes mises à niveau Ethereum sur deux points. Pour commencer, les opérateurs de nœuds doivent mettre à niveau leurs clients de couche de consensus et leurs clients de couche d’exécution en parallèle, et non un seul des deux. Ensuite, la mise à niveau s’opère en deux phases : la première, appelée Bellatrix, à une hauteur d’époque sur la chaîne phare et la seconde, appelée Paris, en sélectionnant une valeur Total Difficulty sur la couche d’exécution.

Informations sur la mise à niveau

Étapes

La Fusion se déroule en deux étapes. Elle commence par une mise à niveau du réseau sur la couche de consensus, déclenchée par une hauteur d’époque. Elle est suivie par la transition de la couche d’exécution de la preuve de travail vers la preuve d’enjeu, déclenchée par un seuil Total Difficulty spécifique, appelé Terminal Total Difficulty (TTD).

La mise à niveau de Bellatrix est programmée pour l’époque 112260 sur la chaîne phare Prater, prévue à 12h24 UTC le 4 août 2022. Paris, la portion de la transition de la couche d’exécution, sera déclenchée lorsque sera atteinte une valeur de Terminal Total Difficulty (TTD) de 10790000 sur Goerli, attendue entre le 6 et le 12 août 2022.

Une fois que la couche d’exécution a dépassé la valeur TTD, le bloc suivant sera entièrement produit par un validateur de chaîne phare. Nous considérons que La Fusion est terminée une fois que la chaîne phare a finalisé ce bloc. En se basant sur des conditions de réseau normales, cela devrait se produire 2 époques, ou environ 13 minutes, après que le premier bloc post-TTD a été atteint !

Une nouvelle balise de bloc JSON-RPC, finalized, renvoie le dernier bloc finalisé ou une erreur s’il n’y a aucun bloc après la fusion. Les applications peuvent se servir de cette balise pour s’assurer que La Fusion est bien terminée. De même, les contrats intelligents peuvent interroger l’opcode DIFFICULTY (0x44), renommé PREVRANDAO post-fusion, pour déterminer si la fusion a eu lieu. Nous recommandons aux fournisseurs d’infrastructures de surveiller la stabilité globale du réseau en plus du statut de finalisation.

Versions client

Les versions clients suivantes sont compatibles avec La fusion sur les réseaux de test Goerli & Prater. Les opérateurs de nœuds doivent exécuter à la fois un client de couche de consensus et un client de couche d’exécution pour rester sur le réseau pendant et après La Fusion.

Lorsqu’ils choisissent le client à exécuter, les validateurs doivent être particulièrement attentifs aux risques liés à l’exécution d’un client majoritaire sur l’EL et le CL. Ces risques et leurs conséquences sont expliqués ici. Une estimation de la répartition actuelle des clients EL et CL ainsi que des guides pour le passage d’un client à un autre sont disponibles ici.

Couche de consensus

Couche d’exécution

Mise à niveau des spécifications

Les changements en vue d’un consensus crucial autour de La Fusion sont spécifiés en deux endroits :

  • Les changements au niveau de la couche de consensus, dans le dossier bellatrix du référentiel consensus-specs
  • Les changements au niveau de la couche d’exécution, dans la spécification Paris spec du référentiel execution-specs

De plus, deux autres spécifications couvrent la manière dont les clients de couche de consensus et les clients de couche d’exécution interagissent :

  • L’API Moteur, spécifiée dans le référentiel execution-apis, est utilisée pour la communication entre les couches de consensus et les couches d’exécution
  • La synchronisation optimiste, spécifiée dans le dossier sync du référentiel consensus-specs, est utilisée par la couche de consensus pour importer des blocs lorsque le client de la couche d’exécution est en phase de synchronisation et pour fournir une vue partielle de la tête de la chaîne de la première à la dernière

FAQ (Questions fréquemment posées)

En tant qu’opérateur de nœud, que dois-je faire?

Après La Fusion, le nœud Ethereum complet combinera un client de couche de consensus (CL), qui exécutera une preuve d’enjeu sur la chaîne phare, et un client de couche d’exécution (EL), qui gérera l’état utilisateur et effectuera les calculs associés aux transactions. Ces deux clients communiqueront via un port authentifié en utilisant un nouvel ensemble de méthodes RPC JSON appelé Engine API. Les clients EL et CL s’authentifient mutuellement en utilisant un secret JWT. Les opérateurs de noeuds doivent se référer à la documentation de leurs clients pour obtenir des instructions sur la manière de générer et configurer ceux-ci.

En d’autres termes, si vous exécutiez déjà un nœud sur la chaîne phare, il vous faudra désormais également exécuter un client de couche d’exécution. De même, si vous exécutiez un nœud sur le réseau preuve de travail actuel, vous devrez exécuter un client de couche de consensus. Pour qu’ils puissent communiquer en toute sécurité, un jeton JWT doit être transmis à chaque client. Des instructions sommaires pour exécuter un noeud sur le réseau Goerli/Prater sont disponibles ici.

Il est utile de souligner que, bien qu’ils fassent tous deux partie des versions client de couche de consensus et client de couche d’exécution, exécuter un Nœud phare et exécuter un Client Validateur sont deux choses distinctes. Les validateurs doivent exécuter les deux, mais les opérateurs de nœuds n’ont besoin que du premier. Cet article explique la différence entre les deux composantes de manière plus détaillée.

À noter également que chaque couche conservera un ensemble indépendant de pairs et présentera ses propres API. Les API phares et RPC JSON continueront donc à fonctionner comme prévu.

En tant que staker, que dois-je faire ?

La fusion Goerli/Prater est votre dernière occasion de vous assurer que vos validateurs sont correctement configurés avant la transition du réseau principal. Il est fortement recommandé de passer par la transition pour éviter tout problème inattendu sur le réseau principal.

Comme expliqué ci-dessus, les validateurs de la chaîne phare devront exécuter un client de couche d’exécution après La Fusion, en plus de leurs clients de couche de consensus avant la fusion. C’est ce qui a été vivement recommandé, mais les validateurs auraient pu sous-traiter ces fonctions à des prestataires tiers. Ceci parce que les mises à jour du contrat de dépôt étaient les seules données requises sur la couche d’exécution.

Après La Fusion, les validateurs devront s’assurer que les transactions dans les blocs qu’ils créent et approuvent sont valides. Pour ce faire, chaque noeud de balise doit être associé à un client de couche d’exécution. Notez que même s’il y a plusieurs validateurs, ils ne peuvent être associés qu’à une seule combinaison de nœud de balise & client de couche d’exécution. Bien que cette configuration implique davantage de responsabilités pour les validateurs, elle permet également au validateur qui propose un bloc d’avoir droit aux frais de transaction prioritaire associés (actuellement attribuées aux mineurs).

Si les récompenses du validateur s’accumulent sur la chaîne phare et qu’il faudra procéder à une mise à niveau ultérieure pour les récupérer, les frais de transaction continueront pour leur part à être payés, brûlés et distribués sur la couche d’exécution. Las validateurs pourront ainsi renseigner n’importe quelle adresse Ethereum comme destinataire des frais de transaction.

Après mise à jour de votre client de consensus, veillez à définir le fee recipient dans le cadre des configurations de votre client validateur afin de vous assurer que les frais de transaction sont bien envoyés à une adresse sur laquelle vous avez la main. Si vous avez misé sur un fournisseur tiers, il appartient au fournisseur que vous avez sélectionné de préciser de quelle manière ces frais sont alloués.

La plateforme de lancement de mise Prater est dotée d’une Liste de vérification de la préparation à la fusion que les stakers peuvent utiliser pour s’assurer qu’ils ont parcouru chaque étape du processus. L’équipe EthStaker anime également un atelier de préparation des validateurs à la fusion le 29 juillet.

Pourquoi la date estimée pour la valeur Terminal Total Difficulty est-elle si large ?

La volatilité de la valeur relative à la difficulté incrémentale par bloc rend l’estimation d’une fenêtre pour la TTD plus difficile à définir qu’avec un bloc ou une hauteur d’époque. La plage prévue est donc plus large. Les utilisateurs sont prévenus que cela sera également le cas pour la transition du réseau principal en raison de changements dans le taux de hachage de la preuve de travail.

En tant que développeur d’applications ou d’outils, que dois-je faire ?

À l’approche de la fusion avec Goerli, l’heure est venue de vérifier que votre produit fonctionnera comme il se doit lors de la transition vers la preuve d’enjeu et dans une configuration post-fusion. Comme expliqué dans un article précédent, La Fusion n’aura que des répercussions minimes sur un sous-ensemble de contrats déployés sur Ethereum, dont aucun ne devrait être rompu. De plus, la majeure partie des points de terminaison d’API utilisateur resteront stables (à condition que vous n’utilisiez pas de méthodes propres à la preuve de travail, telles que eth_getWork).

Cela étant, la plupart des applications sur Ethereum concernent bien plus que des contrats en chaîne. Le moment est venu de vous assurer que votre code front-end, vos outils, votre pipeline de déploiement et vos autres composants hors chaîne fonctionnent correctement. Nous recommandons vivement aux développeurs d’effectuer un cycle de test testing & de déploiement complet sur Sepolia, Ropsten ou Kiln, et de signaler tout problème d’outils ou de dépendances aux responsables de ces projets. Si vous n’êtes pas sûr de savoir où signaler un problème, veuillez utiliser ce référentiel.

De plus, veuillez noter que tous les réseaux de tests en dehors de Sepolia et de Goerli seront obsolètes après la fusion. Si vous utilisez Ropsten, Rinkeby ou Kiln, vous devez prévoir de migrer vers Goerli ou Sepolia. Un complément d’informations à ce sujet est disponible ici.

En tant qu’utilisateur d’Ethereum ou détenteur d’Ether, dois-je faire quoi que ce soit ?

Non. Le réseau principal Ethereum n’est pas affecté par ce réseau de test. D’autres annonces seront publiées sur ce blog avant la transition du réseau principal.

En tant que mineur, dois-je faire quoi que ce soit ?

Non. Si vous minez sur le réseau principal Ethereum, vous devez savoir que chaque réseau fonctionnera entièrement sous sa preuve d’enjeu après La Fusion. À ce stade, il ne sera alors plus possible de miner sur le réseau.

En tant que validateur, puis-je retirer ma mise ?

Non. La Fusion est la mise à niveau d’Ethereum la plus complexe à ce jour. Afin de réduire au maximum les risques de perturbation du réseau, une approche minimale a été adoptée. Cette approche a exclu de cette mise à niveau tout changement ne concernant pas la transition.

Les retraits de la chaîne phare seront très probablement intégrés à la première mise à niveau qui suivra La Fusion. Les spécifications des couches de consensus et d’exécution sont en cours de finalisation.

J’ai d’autre question, à qui puis-je les poser ?

La communauté EthStaker a mis en place un canal communautaire pour répondre aux questions des stakers et des opérateurs de nœuds. Vous pouvez rejoindre cette communauté ici puis utiliser le canal #goerli-prater pour obtenir de l’aide. Comme indiqué plus haut, l’équipe EthStaker anime également un atelier de préparation des validateurs à la fusion le 29 juillet.

Une réunion en ligne dédiée à la Fusion est prévue le 12 août à 14h00 UTC. Des développeurs de clients et des chercheurs répondront aux questions des opérateurs de nœuds, des validateurs, des fournisseurs d’infrastructure & d’outillage et des membres de la communauté. Veuillez noter que cette visio communautaire devrait avoir lieu après la fusion de Goerli/Prater.

Quand La Fusion aura-t-elle lieu ?

À la date de publication de cet article, la date de la transition sous preuve d’enjeu du réseau principal Ethereum n'a pas été définie. Toute source qui prétendrait le contraire relèverait vraisemblablement de l’escroquerie. Des mises à jour de l’évolution de la situation seront publiées sur ce blog. Soyez attentifs !

Une fois que les clients auront des versions complètes et en supposant qu’aucun problème ne soit décelé lors de la fusion Goerli/Prater, une hauteur de créneau sera choisie pour la mise à niveau Bellatrix sur la chaîne phare du réseau principal et une valeur de difficulté totale sera définie en vue de la transition du réseau principal. Les clients proposeront alors des versions qui activent La Fusion sur le réseau principal. Celles-ci seront annoncées sur ce blog et dans d’autres publications communautaires.

Si toutefois des problèmes venaient à être décelés à quelque moment du processus que ce soit ou si la couverture de test était jugée insuffisante, ces problèmes seront traités avant de poursuivre le processus de déploiement.

Ce n’est qu’alors qu’il sera possible d’estimer une date précise pour La Fusion.

En d’autres termes, 🔜.


गोएर्ली/प्रेटर के मर्ज की घोषणा

  • अंतिम टेस्टनेट प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन के लिए, गोएर्ली का प्रेटर के साथ मर्ज हो जाएगा। मर्ज के बाद गोएर्ली/प्रेटर के संयुक्त नेटवर्क का नाम गोएर्ली होगा।
  • बेलाट्रिक्स, जो मर्ज के लिए प्रेटर को तैयार करने वाला अपग्रेड है, ईपोक 112260 में होगा, ऐसा 4 अगस्त, 2022 को 12:24PM UTC पर हो सकता है।
  • बेलाट्रिक्स के एक्टिवेट हो जाने के बाद, गोएर्ली/प्रेटर का मर्ज तभी होगा, जब गोएर्ली 10790000 की टोटल डिफ़िकल्टी तक पहुँच जाएगा, ऐसा 6-12 अगस्त, 2022 के बीच हो सकता है।
  • मर्ज के बाद, गोएर्ली का सत्यापनकर्ता सेट, अलग-अलग स्टेकर्स के लिए टेस्टनेट सत्यापनकर्ता चलाने हेतु खुला रहेगा। जो स्टेकर, गोएर्ली/प्रेटर सत्यापनकर्ता शुरू करना चाहते हैं, वे प्रेटर लांच पैड पर जाकर ऐसा कर सकते हैं।

बैकग्राउंड

एथेरियम में प्रूफ़-ऑफ़-स्टेक को लाने के वर्षों के प्रयास के बाद, अब हम आखिरी टेस्टिंग स्टेज में प्रवेश कर रहे हैं: जो टेस्टनेट डिप्लॉयमेंट है!

बंद कर दिए गए टेस्टनेट पर कई डेवनेट, शैडो फ़ोर्क और मर्ज के बाद, सेपोलिया का ट्रांज़िशन हाल ही में प्रूफ़-ऑफ़-स्टेक में हुआ था। अब, केवल एक और टेस्टनेट बचा है: गोएर्ली और इससे जुड़ी बीकन चेन, प्रेटर।

यह मर्ज पिछले एथेरियम अपग्रेड से दो तरह से अलग है। पहला, नोड ऑपरेटर्स को अपने सहमति परत (CL) और निष्पादन परत (EL) क्लाइंट दोनों में से किसी एक के बजाय दोनों को एक साथ अपडेट करना होगा। दूसरा, अपग्रेड दो चरणों में एक्टिवेट होगा: पहला चरण बेलाट्रिक्स, बीकन चेन पर ईपोक हाइट पर एक्टिवेट होगा और दूसरा चरण पेरिस, निष्पादन परत पर टोटल डिफ़िकल्टी मान तक पहुँचने पर एक्टिवेट होगा।

जानकारी अपग्रेड करें

समय

मर्ज दो चरणों की प्रक्रिया है। यह प्रक्रिया सहमति परत पर बेलाट्रिक्स नाम के नेटवर्क अपग्रेड के साथ शुरू होती है, जो ईपोक हाइट पर एक्टिवेट होता है। इसके बाद निष्पादन परत का ट्रांज़िशन प्रूफ़-ऑफ़-वर्क से प्रूफ़-ऑफ़-स्टेक में होता है, जो एक निश्चित टोटल डिफ़िकल्टी सीमा पर पहुँचने पर एक्टिवेट होता है, जिसे टर्मिनल टोटल डिफ़िकल्टी (TTD) कहा जाता है।

बेलाट्रिक्स अपग्रेड, प्रेटर बीकन चेन पर ईपोक 112260 पर होगा, ऐसा 4 अगस्त, 2022 को 12:24 PM UTC पर हो सकता है। निष्पादन परत के हिस्से का ट्रांज़िशन, पेरिस, तब एक्टिवेट होगा जब निष्पादन परत गोएर्ली पर 10790000 की टर्मिनल टोटल डिफ़िकल्टी (TTD) तक पहुँच जाएगी, ऐसा 6-12 अगस्त, 2022 के बीच हो सकता है।

जब निष्पादन परत TTD को पार कर लेगी, तब अगला ब्लॉक सिर्फ़ बीकन चेन वैलिडेटर द्वारा ही बनाया जाएगा। हम मर्ज को तभी पूरा हुआ मानते हैं, जब बीकन चेन ने इस ब्लॉक को फ़ाइनलाइज़ कर दिया हो। नेटवर्क की सामान्य स्थितियों में, ऐसा फ़र्स्ट पोस्ट TTD ब्लॉक तक पहुँचने के बाद 2 ईपोक या लगभग 13 मिनट में हो जाना चाहिए!

फ़ाइनलाइज़ किया गया, नया JSON-RPC ब्लॉक टैग, फ़ाइनलाइज़ किया गया सबसे नया ब्लॉक रिटर्न करता है या मर्ज के बाद ऐसा कोई ब्लॉक मौजूद नहीं होने पर त्रुटि दिखाता है। इस टैग का उपयोग एप्लीकेशन में यह चेक करने के लिए किया जा सकता है कि मर्ज पूरा हो गया है या नहीं। इसी तरह, स्मार्ट कॉन्ट्रैक्ट, डिफ़िकल्टी ऑप्टकोड (0x44) की क्वेरी कर सकते हैं, जिसका नाम मर्ज के बाद प्रीवरांडाओ कर दिया गया है, ताकि यह पता लगाया जा सके कि मर्ज हो गया है या नहीं। हमारा सुझाव है कि इंफ़्रास्ट्रक्चर प्रोवाइडर फ़ाइनलाइज़ेशन स्टेटस के अलावा नेटवर्क की पूरी स्टेबिलिटी पर भी नज़र रखें।

क्लाइंट रिलीज़

निम्नलिखित क्लाइंट गोएर्ली और प्रेटर टेस्टनेट में मर्ज का समर्थन जारी करती हैं। मर्ज के दौरान और बाद में नेटवर्क पर बने रहने के लिए नोड ऑपरेटर्स को निष्पादन और सहमति परत क्लाइंट दोनों को चलाना होगा।

कौन सा क्लाइंट चलाना है, यह चुनते समय सत्यापनकर्ताओं को EL और CL दोनों पर ज़्यादातर क्लाइंट चलाने के जोखिमों के प्रति विशेष रूप से सावधान रहना चाहिए। इन जोखिमों और उनके परिणामों के बारे में अधिक जानकारी यहाँ दी गई है। मौजूदा EL और CL क्लाइंट डिस्ट्रीब्यूशन का अनुमान और एक क्लाइंट से दूसरे क्लाइंट पर स्विच करने की जानकारी यहाँ दी गई है।

सहमति परत

निष्पादन परत

अपग्रेड की विशेषताएँ

मर्ज के कॉन्सेंसस के लिए ज़रूरी बदलाव दो जगहों पर बताए गए हैं:

इनके अलावा, दो अन्य स्पेसिफ़िकेशन यह बताते हैं कि सहमति और निष्पादन परत क्लाइंट आपस में किस तरह इंटरैक्ट करेंगे:

  • एक्ज़ीक्यूशन-एपिस रिपॉज़िटरी में बताए गए इंजन API का इस्तेमाल, सहमति और निष्पादन परत के बीच बातचीत के लिए किया जाता है
  • कॉन्सेंसस-स्पेसिफ़िकेशन रिपॉज़िटरी के सिंक फ़ोल्डर में बताए गए ऑप्टिमिस्टिक सिंक का उपयोग निष्पादन परत क्लाइंट के सिंक होते समय सहमति परत द्वारा ब्लॉक को इम्पोर्ट करने और पहले से लेकर बाद तक की हेड ऑफ़ द चेन का आंशिक दृश्य दिखाने के लिए किया जाता है

अक्सर पूछे जाने वाले प्रश्न

नोड ऑपरेटर के तौर पर, मुझे क्या करना चाहिए?

मर्ज के बाद, एथेरियम का एक फ़ुल नोड, प्रूफ़-ऑफ़-स्टेक बीकन चेन चलाने वाले सहमति परत (CL) क्लाइंट को यूज़र स्टेट मैनेज करने वाले और ट्रांज़ेक्शन से संबंधित कैलकुलेशन चलाने वाले निष्पादन परत क्लाइंट (EL) से जोड़ देगा। ये JSON RPC विधियों के एक नए सेट, इंजन API का उपयोग करके एक प्रमाणित पोर्ट पर बातचीत करते हैं। EL और CL क्लाइंट एक दूसरे को JWT सीक्रेट का उपयोग करके प्रमाणीकृत करते हैं। नोड ऑपरेटर को इन्हें जनरेट करने और कॉन्फ़िगर करने के निर्देश देखने के लिए अपने क्लाइंट के प्रलेखन देखने चाहिए।

दूसरे शब्दों में, अगर आप पहले से ही बीकन चेन पर कोई नोड चला रहे थे, तो अब आपको एक निष्पादन परत क्लाइंट भी चलाना होगा। इसी तरह, अगर आप मौजूदा प्रूफ़-ऑफ़-वर्क नेटवर्क पर कोई नोड चला रहे थे, तो आपको एक सहमति परत क्लाइंट भी चलाना होगा। ये सुरक्षित रूप से बातचीत कर सकें, इसके लिए JWT टोकन प्रत्येक क्लाइंट को पास किया जाना चाहिए। गोएर्ली/प्रेटर नेटवर्क पर नोड चलाने के निर्देशों का सारांश यहाँ देखा जा सकता है।

यहाँ यह ध्यान दिया जाना चाहिए कि हालाँकि ये दोनों ही सहमति परत क्लाइंट रिलीज़ का हिस्सा हैं, लेकिन फिर भी बीकन नोड चलाना, सत्यापनकर्ता क्लाइंट चलाने से अलग होता है। स्टेकर को ये दोनों चलाने चाहिए, लेकिन नोड ऑपरेटर्स को केवल पहले वाले की ही ज़रूरत होती है। इस पोस्ट में दोनों तत्वों के बीच के अंतर को और अधिक विस्तार से समझाया गया है।

यह भी ध्यान रखें कि हर लेयर, पियर्स का एक अलग सेट बनाए रखेगी और अपने API दिखाएगी। इस प्रकार बीकन और JSON RPC API दोनों सही ढंग से काम करना जारी रखेंगे।

स्टेकर के तौर पर, मुझे क्या करना होगा?

गोएर्ली/प्रेटर मर्ज आपके लिए यह सुनिश्चित करने का आखिरी मौका है कि मेननेट ट्रांजिशन से पहले आपके सत्यापनकर्ता सही तरीके से कॉन्फ़िगर हो गए हैं। मेननेट पर किसी भी अप्रत्याशित समस्या से बचने के लिए अब ट्रांज़िशन चलाने की पूरी अनुशंसा की जाती है।

जैसा कि ऊपर बताया गया है, बीकन चेन पर मौजूद सत्यापनकर्ता को मर्ज के बाद अपने सहमति परत क्लाइंट के अलावा निष्पादन परत क्लाइंट को भी चलाना होगा। मर्ज से पहले, इसकी पूरी अनुशंसा की गई थी, लेकिन सत्यापनकर्ता ये काम थर्ड-पार्टी प्रोवाइडर्स को आउटसोर्स कर सकते थे। यह इसलिए संभव हो पाया, क्योंकि निष्पादन परत पर जिस डेटा की ज़रूरत थी, वह केवल डिपॉज़िट अनुबंध के अपडेट का डेटा था।

मर्ज के बाद, सत्यापनकर्ताओं को यह सुनिश्चित करना होगा कि उनके द्वारा बनाए गए और प्रमाणित किए गए ब्लॉक में किए जाने वाले ट्रांज़ेक्शन वैध हों। ऐसा करने के लिए, प्रत्येक बीकन नोड को निष्पादन परत क्लाइंट के साथ पेयर किया जाना चाहिए। ध्यान रखें कि एक से ज़्यादा सत्यापनकर्ता को एक ही बीकन नोड और निष्पादन परत क्लाइंट कॉम्बो से अब भी पेयर किया जा सकता है। हालाँकि इससे सत्यापनकर्ता की ज़िम्मेदारियाँ बढ़ जाती हैं, लेकिन इससे ब्लॉक का प्रस्ताव देने वाले सत्यापनकर्ता को इससे संबंधित ट्रांज़ेक्शन की प्रायोरिटी फ़ीस (जो अभी माइनर्स को मिलता है) लेने का अधिकार भी मिल जाता है।

वैसे तो वैलिडेटर्स के रिवॉर्ड, बीकन चेन पर एकत्रित होते हैं और उनकी निकासी के लिए एक और नेटवर्क अपग्रेड ज़रूरी होगा, लेकिन ट्रांज़ेक्शन फ़ीस का भुगतान, बर्निंग और डिस्ट्रीब्यूशन, निष्पादन परत पर ही जारी रहेगा। सत्यापनकर्ता, ट्रांज़ेक्शन फ़ीस पाने के लिए कोई भी एथेरियम पता सेट कर सकते हैं।

अपने कॉन्सेंसस क्लाइंट को अपडेट करने के बाद, फ़ीस पाने वाले को अपने वैलिडेटर क्लाइंट कॉन्फ़िगरेशन के हिस्से के रूप में सेट करना सुनिश्चित करें, ताकि यह सुनिश्चित हो सके कि ट्रांज़ेक्शन फ़ीस आपके द्वारा नियंत्रित पते पर ही भेजी जाए। अगर आपने किसी थर्ड-पार्टी प्रोवाइडर का उपयोग करके स्टेक लगाई है, तो यह तय करना आपके द्वारा चुने गए प्रोवाइडर पर निर्भर करता है कि ये फ़ीस कैसे बाँटी जाएगी।

प्रेटर स्टेकिंग लांच पैड में एक मर्ज रेडीनेस चेकलिस्ट है, जिसका उपयोग स्टेकर यह सुनिश्चित करने के लिए कर सकते हैं कि वे प्रक्रिया के प्रत्येक चरण से गुजर चुके हैं। EthStaker टीम 29 जुलाई को एक मर्ज वैलिडेटर प्रिपरेशन वर्कशॉप भी आयोजित कर रही है।

टर्मिनल टोटल डिफ़िकल्टी की तारीख का अनुमान सटीक क्यों नहीं है?

हर ब्लॉक पर बढ़ती हुई डिफ़िकल्टी में अस्थिरता के कारण TTD की तारीख का अनुमान लगा पाना, ब्लॉक या ईपोक की ऊँचाई के साथ इसका अनुमान लगाने की तुलना में ज़्यादा मुश्किल होता है, यही कारण है कि इसकी तारीख की रेंज इतनी ज़्यादा होती है। यूज़र्स को ध्यान देना चाहिए कि प्रूफ-ऑफ-वर्क हैश रेट में बदलाव के कारण मेननेट के ट्रांज़िशन में भी ऐसा ही होगा।

एप्लिकेशन या टूलिंग डेवलपर के तौर पर, मुझे क्या करना चाहिए?

मर्ज के गोएर्ली पर लाइव होने के साथ, अब आपके पास यह सुनिश्चित करने का आखिरी मौका है कि आपका उत्पाद प्रूफ-ऑफ-स्टेक ट्रांज़िशन के माध्यम से और मर्ज के बाद के संदर्भ में अपेक्षित रूप से काम करता है। जैसा कि पिछली पोस्ट में बताया गया है, मर्ज का एथेरियम पर डिप्लॉय किए गए अनुबंधों के सबसेट पर बहुत ही कम प्रभाव पड़ेगा, मतलब इनमें से शायद कोई भी अनुबंध नहीं टूटेगा। इसके अलावा, यूज़र API एंडपॉइंट में लॉयन का हिस्सा एक जैसा बना रहेगा (बशर्ते कि आप प्रूफ़-ऑफ़-वर्क विशिष्ट तरीकों जैसे eth_getWork का उपयोग नहीं कर रहे हों)।

इस तरह एथेरियम पर मौजूद अधिकांश एप्लिकेशन में चेन पर मौजूद अनुबंधों से कहीं ज़्यादा चीज़ें शामिल होती है। अब आपको यह सुनिश्चित करना चाहिए कि आपका फ्रंट एंड कोड, टूलिंग, डिप्लॉयमेंट पाइपलाइन और चेन से बाहर के अन्य कंपोनेंट, मनचाहे तरीके से काम करें। हम दृढ़ता से अनुशंसा करते हैं कि डेवलपर्स सेपोलिया, रोपस्टेन या किल पर एक पूर्ण परीक्षण और परिनियोजन चक्र के माध्यम से चलाएं और उन परियोजनाओं के अनुरक्षकों को उपकरण या निर्भरता के साथ किसी भी समस्या की रिपोर्ट करें। अगर आप इस बारे में निश्चित नहीं हैं कि आपको किसी समस्या की रिपोर्ट कहाँ करनी चाहिए, तो कृपया इस रिपोज़िटरी का उपयोग करें।

इसके अलावा, यह भी ध्यान रखें कि मर्ज के बाद सेपोलिया और गोएर्ली को छोड़कर अन्य सभी टेस्टनेट बंद कर दिए जाएँगे। अगर आप रोपस्टेन, रिंकबी या किल्न के यूज़र हैं, तो आपको गोएर्ली या सेपोलिया पर शिफ़्ट होने का प्लान बना लेना चाहिए। इसके बारे में अधिक जानकारी यहाँ मिल सकती है।

एथेरियम यूज़र या ईथर धारक के तौर पर, क्या मुझे कुछ करना होगा?

नहीं। एथेरियम मेननेट इस टेस्टनेट से प्रभावित नहीं हुआ है। मेननेट के ट्रांज़िशन से पहले इस ब्लॉग पर आगे की कुछ घोषणाएँ की जाएँगी।

माईनर के तौर पर, क्या मुझे कुछ करना होगा?

नहीं। अगर आप एथेरियम मेननेट या रोपस्टेन पर माईनिंग कर रहे हैं, तो आपको पता होना चाहिए कि मर्ज के बाद प्रत्येक नेटवर्क पूरी तरह से प्रूफ़-ऑफ़-स्टेक के अंतर्गत काम करेगा। तब नेटवर्क पर माईनिंग करना संभव नहीं रह जाएगा।

सत्यापनकर्ता के तौर पर, क्या मैं अपनी स्टेक वापस ले सकता हूँ?

नहीं। यह मर्ज, एथेरियम का अब तक का सबसे जटिल अपग्रेड है। नेटवर्क की रुकावटों के जोखिम को कम करने के लिए, एक न्यूनतम दृष्टिकोण अपनाया गया, जिसमें इस अपग्रेड से सभी नॉन-ट्रांज़िशन बदलावों को हटा दिया गया है।

मर्ज के बाद के पहले अपग्रेड में शायद बीकन चेन से निकासी करने की सुविधा उपलब्ध होने की संभावना है। सहमति और निष्पादन दोनों परत के लिए स्पेसिफ़िकेशन तैयार किए जा रहे हैं।

मेरे और भी प्रश्न हैं, मैं उन्हें कहाँ पूछ सकता/सकती हूं?

EthStaker कम्युनिटी ने स्टेकर्स और नोड ऑपरेटर्स के सवालों के जवाब देने के लिए एक डिस्कॉर्ड चैनल बनाया है। आप यहाँ से उनके डिस्कॉर्ड में शामिल हो सकते हैं और फिर सहायता पाने के लिए #goerli-prater चैनल का उपयोग कर सकते हैं। जैसा कि ऊपर बताया गया है, EthStaker 29 जुलाई को एक मर्ज वैलिडेटर प्रिपेरेशन वर्कशॉप भी आयोजित करेंगे।

इसके अलावा 12 जून, 14:00 UTC पर एक मर्ज कम्युनिटी कॉल शेड्यूल किया गया है। इसमें नोड ऑपरेटर्स, स्टैकर्स, इन्फ़्रास्ट्रक्चर और टूलिंग प्रोवाइडर्स और कम्युनिटी के सदस्यों के सवालों के जवाब देने के लिए क्लाइंट के डेवलपर और रिसर्चर उपलब्ध रहेंगे। ध्यान दें कि यह कम्युनिटी कॉल गोएर्ली/प्रेटर मर्ज के बाद होने की उम्मीद है।

मर्ज कब होगा?

इस पोस्ट के प्रकाशन के समय, एथेरियम मेननेट के प्रूफ़-ऑफ़-स्टेक ट्रांज़िशन की तारीख तय नहीं की गई है। इससे अलग कोई भी दावा करने वाला कोई भी स्रोत, स्कैम हो सकता है। अपडेट इस ब्लॉग पर पोस्ट किए जाएँगे। कृपया सुरक्षित रहें!

अगर मान लिया जाए कि गोएर्ली/प्रेटर मर्ज के दौरान कोई समस्या नहीं आई है, तो क्लाइंट की ओर से पूरे फ़ीचर वाली रिलीज़ के बाद, मेननेट बीकन चेन पर बेलाट्रिक्स अपग्रेड के लिए एक स्लॉट हाइट चुनी जाएगी और मेननेट ट्रांज़िशन के लिए एक टोटल डिफ़िकल्टी मान सेट किया जाएगा। क्लाइंट इसके बाद रिलीज़ जारी करेंगे, जिससे मेननेट पर मर्ज हो सकेगा। इनकी घोषणा इस ब्लॉग और कम्युनिटी के अन्य प्रकाशनों में की जाएगी।

हालाँकि, अगर इस प्रक्रिया में कहीं पर भी कोई समस्या आती है या टेस्ट का कवरेज अपर्याप्त माना जाता है, तो डिप्लॉयमेंट प्रोसेस को जारी रखने से पहले इन समस्याओं का समाधान किया जाएगा।

इसके बाद ही मर्ज की सही तारीख का अनुमान लगाना संभव हो पाएगा।

दूसरे शब्दों में, 🔜।


Pengumuman Penggabungan Goerli/Prater

  • Untuk transisi bukti taruhan jaringan percobaan terakhir, Goerli akan bergabung dengan Prater. Jaringan gabungan Goerli/Prater akan mempertahankan nama Goerli setelah penggabungan.
  • Bellatrix, peningkatan Prater menyiapkannya untuk Penggabungan yang akan berlangsung pada jangka waktu 112260, diperkirakan pada pukul 12:24 UTC tanggal 4 Agustus 2022.
  • Setelah Bellatrix diaktifkan, penggabungan Goerli/Prater akan berlangsung saat Goerli mencapai total tingkat kesulitan 10790000, diperkirakan antara tanggal 6-12 Agustus 2022.
  • Setelah penggabungan, set validator Goerli akan tetap terbuka bagi penaruh individual untuk menjalankan validator jaringan percobaan. Penaruh yang ingin memulai validator Goerli/Prater dapat melakukannya di Landasan Peluncuran Prater.

Latar Belakang

Setelah bertahun-tahun berusaha menghadirkan bukti taruhan ke Ethereum, sekarang kami memasuki tahap percobaan akhir: penyebaran jaringan percobaan!

Setelah beberapa jaringan pengembang, shadow fork, dan penggabungan pada jaringan percobaan tidak digunakan lagi, Sepolia baru-baru ini beralih ke bukti taruhan. Sekarang, hanya tersisa satu jaringan percobaan lagi: Goerli, dan Rantai Suar terkait, Prater.

Penggabungan berbeda dari peningkatan Ethereum sebelumnya dalam dua cara. Pertama, operator simpul perlu memperbarui baik klien lapisan konsensus (CL) dan lapisan eksekusi (EL) mereka secara bersamaan, bukan hanya salah satu dari keduanya. Kedua, peningkatan diaktifkan dalam dua fase: yang pertama, bernama Bellatrix, pada ketinggian jangka waktu di Rantai Suar dan yang kedua, bernama Paris, setelah mencapai nilai Total Tingkat Kesulitan di lapisan eksekusi.

Informasi Peningkatan

Pengaturan waktu

Penggabungan merupakan proses dua langkah. Dimulai dengan peningkatan jaringan, Bellatrix, pada lapisan konsensus, dipicu oleh ketinggian jangka waktu. Ini diikuti oleh transisi lapisan eksekusi dari bukti kerja ke bukti taruhan, Paris, dipicu oleh ambang batas Total Tingkat Kesulitan tertentu, yang disebut Total Tingkat Kesulitan Terminal (TTD).

Peningkatan Bellatrix dijadwalkan untuk jangka waktu 112260 pada Rantai Suar Prater, yang diperkirakan pada pukul 12:24 UTC tanggal 4 Agustus 2022. Paris, bagian transisi lapisan eksekusi, akan dipicu dengan mencapai Total Tingkat Kesulitan Terminal (TTD) dari 10790000 di Goerli, diperkirakan antara tanggal 6-12 Agustus 2022.

Setelah lapisan eksekusi melampaui TTD, blok berikutnya akan diproduksi sepenuhnya oleh validator Rantai Suar. Kami menganggap Penggabungan telah selesai setelah Rantai Suar menyelesaikan blok ini. Dengan asumsi kondisi jaringan normal, ini akan terjadi dalam 2 jangka waktu, atau sekitar 13 menit, setelah blok pasca TTD pertama dicapai!

Label blok JSON-RPC yang baru, selesai, mengembalikan blok yang terakhir selesai atau kesalahan jika tidak ada blok pasca penggabungan seperti itu. Label ini dapat digunakan untuk aplikasi guna memeriksa apakah Penggabungan telah selesai. Demikian juga, kontrak pintar dapat meminta kode operasi TINGKAT KESULITAN (0x44), diganti namanya menjadi PREVRANDAO setelah penggabungan, untuk menentukan apakah Penggabungan telah terjadi. Kami menyarankan agar penyedia infrastruktur memantau stabilitas jaringan keseluruhan selain status finalisasi.

Rilis Klien

Rilis klien berikut mendukung Penggabungan di jaringan percobaan Goerli & Prater. Operator simpul harus menjalankan keduanya baik klien lapisan eksekusi maupun lapisan konsensus agar tetap berada di jaringan selama dan setelah Penggabungan.

Saat memilih klien mana yang akan dijalankan, validator harus memperhatikan secara khusus risiko menjalankan klien mayoritas di keduanya baik EL dan CL. Penjelasan tentang risiko ini dan konsekuensinya dapat ditemukan di sini. Perkiraan distribusi klien EL dan CL saat ini dan panduan untuk beralih dari satu klien ke klien lainnya dapat ditemukan di sini.

Lapisan Konsensus

Nama Versi Tautan
Lighthouse Geardude Clockberg (v2.4.0) Unduh
Lodestar v0.41.0 Unduh
Nimbus v22.7.0 Unduh
Prysm v2.1.4-rc.0 Unduh
Teku 22.7.0 Unduh

Lapisan Eksekusi

Nama Versi Tautan
Besu 22.7.0-RC3 Unduh
Erigon 2022.07.03-alpha Unduh
go-ethereum (geth) v1.10.21 Unduh
Nethermind 1.13.5 Unduh

Spesifikasi Peningkatan

Perubahan penting konsensus untuk Penggabungan ditentukan dalam dua tempat:

  • Perubahan lapisan konsensus, di bawah direktori bellatrix dari repositori spesifikasi konsensus
  • Perubahan lapisan eksekusi, di bawah spesifikasi Paris di repositori spesifikasi-eksekusi

Selain itu, dua spesifikasi lainnya mencakup bagaimana klien lapisan konsensus dan lapisan eksekusi berinteraksi:

  • API Mesin, yang ditetapkan dalam repositori api-eksekusi, digunakan untuk komunikasi antara lapisan konsensus dan lapisan eksekusi
  • Sinkronisasi Optimis, yang ditetapkan dalam folder sinkronisasi di repositori spesifikasi konsensus, yang digunakan oleh lapisan konsensus untuk mengimpor blok sebagai klien lapisan eksekusi disinkronkan, dan untuk memberikan tampilan parsial kepala rantai dari yang pertama hingga yang terakhir

PERTANYAAN YANG SERING DITANYAKAN

Sebagai operator simpul, apa yang harus saya lakukan?

Setelah penggabungan, simpul penuh Ethereum akan menggabungkan klien lapisan konsensus (CL), yang menjalankan Rantai Suar bukti taruhan, dan klien lapisan eksekusi (EL), yang mengelola state pengguna dan menjalankan komputasi yang terkait dengan transaksi. Simpul ini berkomunikasi melalui port yang diautentikasi menggunakan set baru metode JSON RPC, yang disebut API Mesin. Klien EL dan CL saling mengautentikasi menggunakan rahasia JWT. Operator simpul harus merujuk pada dokumentasi klien mereka untuk mendapatkan instruksi tentang cara membuat dan mengonfigurasinya.

Dengan kata lain, jika Anda sudah menjalankan simpul di Rantai Suar, sekarang Anda juga perlu menjalankan klien lapisan eksekusi. Demikian juga, jika Anda menjalankan simpul di jaringan bukti kerja saat ini, Anda perlu menjalankan klien lapisan konsensus. Agar mereka berkomunikasi dengan aman, token JWT harus diteruskan ke setiap klien. Ringkasan petunjuk untuk menjalankan simpul di jaringan Goerli/Prater dapat ditemukan di sini.

Perlu ditekankan bahwa meskipun keduanya merupakan bagian dari rilis klien lapisan konsensus, menjalankan Simpul Suar berbeda dari menjalankan Klien Validator. Penaruh harus menjalankan keduanya, tetapi operator simpul hanya memerlukan yang pertama. Postingan ini menjelaskan perbedaan di antara kedua komponen secara rinci.

Selain itu, perhatikan bahwa setiap lapisan akan mempertahankan set peer independen dan mengekspos API-nya sendiri. API Suar dan JSON RPC keduanya akan tetap berjalan seperti yang diharapkan.

Sebagai penaruh, apa yang perlu saya lakukan?

Penggabungan Goerli/Prater adalah kesempatan terakhir Anda untuk memastikan bahwa validator Anda telah dikonfigurasi dengan benar sebelum transisi jaringan utama. Menjalankan transisi sekarang sangat disarankan untuk menghindari masalah yang tidak diharapkan pada jaringan utama.

Seperti yang dijelaskan di atas, validator di Rantai Suar perlu menjalankan klien lapisan eksekusi setelah Penggabungan, selain klien lapisan konsensus mereka. Sebelum penggabungan, hal ini sangat direkomendasikan, tetapi validator dapat mengalihdayakan fungsi ini ke penyedia pihak ketiga. Hal ini dimungkinkan karena satu-satunya data yang diperlukan di lapisan eksekusi adalah pembaruan kontrak deposit.

Pasca-penggabungan, validator perlu memastikan bahwa transaksi di blok yang mereka buat dan membuktikan bahwa itu valid. Untuk melakukannya, setiap simpul suar harus dipasangkan dengan klien lapisan eksekusi. Perhatikan bahwa beberapa validator masih tetap bisa dipasangkan ke satu simpul suar & kombo klien lapisan eksekusi. Meskipun hal ini memperluas tanggung jawab validator, juga memberi hak kepada validator yang mengusulkan blok atas biaya prioritas transaksi terkait (yang saat ini diberikan kepada penambang).

Meskipun imbalan validator bertambah di Rantai Suar dan akan memerlukan peningkatan jaringan berikutnya untuk ditarik, biaya transaksi akan terus dibayarkan, dibakar, dan didistribusikan di lapisan eksekusi. Validator dapat menentukan alamat Ethereum mana saja sebagai penerima untuk biaya transaksi.

Setelah memperbarui klien konsensus, pastikan untuk mengatur penerima biaya sebagai bagian dari konfigurasi klien validator guna memastikan biaya transaksi dikirimkan ke alamat yang Anda kendalikan. Jika Anda telah bertaruh menggunakan penyedia pihak ketiga, terserah penyedia yang Anda pilih untuk menentukan cara mengalokasikan biaya ini.

Landasan Peluncuran Penaruhan Prater memiliki Daftar Periksa Kesiapan Penggabungan yang dapat digunakan penaruh untuk memastikan mereka telah melalui setiap langkah dalam prosesnya. Tim EthStaker juga mengadakan Workshop Persiapan Validator Penggabungan pada tanggal 29 Juli.

Mengapa perkiraan tanggal Total Tingkat Kesulitan Terminal begitu luas?

Volatilitas dalam tingkat kesulitan tambahan per blok membuat perkiraaan jendela untuk TTD lebih sulit daripada dengan ketinggian blok atau jangka waktu, oleh karena itu rentang perkiraan lebih luas. Pengguna harus memperhatikan bahwa ini juga akan terjadi pada transisi jaringan utama karena perubahan dalam hash rate bukti kerja.

Sebagai pengembang aplikasi atau perangkat, apa yang harus saya lakukan?

Dengan ditayangkannya Penggabungan di Goerli, sekarang adalah kesempatan terakhir untuk memastikan bahwa produk Anda berjalan seperti yang diharapkan melalui transisi bukti taruhan dan dalam konteks pasca penggabungan. Seperti yang dijelaskan dalam postingan sebelumnya, Penggabungan hanya akan berdampak minimal pada sebagian kontrak yang disebarkan di Ethereum, tidak ada yang akan dilanggar. Selain itu, bagian terbesar dari titik akhir API pengguna akan tetap stabil (kecuali Anda menggunakan metode khusus bukti kerja seperti eth_getWork).

Meskipun demikian, sebagian besar aplikasi di Ethereum melibatkan lebih dari sekadar kontrak di dalam rantai. Sekarang adalah saatnya untuk memastikan bahwa kode front-end, perangkat, saluran penyebaran, dan komponen di luar rantai Anda berjalan sebagaimana yang dimaksudkan. Kami sangat menyarankan agar pengembang menjalankan siklus percobaan & penyebaran penuh di Sepolia, Ropsten, atau Kiln serta melaporkan masalah apa pun pada perangkat atau dependensi terhadap pengelola proyek tersebut. Jika Anda tidak yakin di mana harus melayangkan permasalahan yang ada, gunakan repositori ini.

Selain itu, Anda harus memperhatikan bahwa semua jaringan percobaan selain Sepolia dan Goerli tidak akan digunakan lagi setelah penggabungan. Jika Anda adalah pengguna Ropsten, Rinkeby, atau Kiln, Anda harus siap untuk bermigrasi ke Goerli atau Sepolia. Informasi selengkapnya tentang hal ini dapat ditemukan di sini.

Sebagai pengguna Ethereum atau pemegang Ether, apakah ada yang perlu saya lakukan?

Tidak. Jaringan utama Ethereum tidak terpengaruh oleh jaringan percobaan ini. Pengumuman berikutnya akan dibuat di blog ini sebelum transisi jaringan utama.

Sebagai penambang, apakah ada yang perlu saya lakukan?

Tidak. Jika Anda menambang di jaringan utama Ethereum, Anda harus menyadari bahwa setiap jaringan akan beroperasi sepenuhnya di bawah bukti taruhan setelah Penggabungan. Pada saat itu, penambangan tidak lagi dapat dilakukan di jaringan.

Sebagai validator, bisakah saya menarik taruhan saya?

Tidak. Penggabungan adalah peningkatan ke Ethereum yang paling rumit untuk saat ini. Untuk meminimalkan risiko gangguan jaringan, pendekatan minimal diambil yang mengecualikan perubahan non-transisi dari peningkatan ini.

Penarikan dari Rantai Suar kemungkinan akan diperkenalkan di peningkatan pertama setelah Penggabungan. Spesifikasi baik untuk lapisan konsensus dan eksekusi sedang dalam proses.

Saya masih punya pertanyaan, ke mana saya harus menyampaikannya?

Komunitas EthStaker telah menyiapkan saluran perselisihan untuk menjawab pertanyaan penaruh dan operator simpul. Anda dapat bergabung dengan saluran perselisihan mereka di sini lalu menggunakan saluran #goerli-prater untuk mendapatkan bantuan. Seperti yang disebutkan di atas, EthStaker juga akan mengadakan Workshop Persiapan Validator Penggabungan pada tanggal 29 Juli.

Selain itu, Panggilan Komunitas Penggabungan dijadwalkan tanggal 12 Agustus, pukul 14:00 UTC. Pengembang dan peneliti klien akan tersedia untuk menjawab pertanyaan dari operator simpul, penaruh, penyedia infrastruktur & perangkat, serta anggota komunitas. Perhatikan bahwa panggilan komunitas ini diperkirakan akan berlangsung setelah penggabungan Goerli/Prater.

kapan penggabungan?

Sejak dipublikasikannya postingan ini, jadwal untuk transisi bukti taruhan jaringan utama Ethereum belum ditetapkan. Sumber mana pun yang mengklaim sebaliknya kemungkinan adalah penipuan. Pembaruan akan diposting di blog ini. Tetap aman!

Dengan asumsi tidak ditemukan masalah selama penggabungan Goerli/Prater, setelah klien memiliki rilis fitur lengkap, ketinggian ruang akan dipilih untuk peningkatan Bellatrix di jaringan utama Rantai Suar dan nilai total tingkat kesulitan akan ditetapkan untuk transisi jaringan utama. Kemudian klien akan membuat rilis yang memungkinkan Penggabungan di jaringan utama. Hal ini akan diumumkan di blog ini dan di publikasi komunitas lainnya.

Namun, jika ditemukan masalah pada titik mana pun di dalam prosesnya atau cakupan percobaan dinilai tidak mencukupi, hal ini akan diselesaikan sebelum melanjutkan proses penyebaran.

Hanya dengan demikianlah dimungkinkan untuk memperkirakan tanggal pasti Penggabungan.

Dengan kata lain, 🔜.


Anúncio sobre a fusão das redes de testes Goerli/Prater

  • A última transição da rede de testes para a prova de participação trará a fusão entre as redes de testes Goerli e Prater. A rede combinada Goerli/Prater vai conservar o nome de Goerli depois da fusão.
  • Bellatrix, a atualização da rede de testes Prater que se prepara para a fusão, será realizada na época 112260, prevista para as 12h24 da tarde (UTC) de 4 de agosto de 2022.
  • Depois de ativar a Bellatrix, a fusão Goerli/Prater acontecerá quando Goerli alcance uma dificuldade total de 10790000, esperada entre os dias 6 e 12 de agosto de 2022.
  • Depois da fusão, o conjunto de validadores da rede de testes Goerli permanecerá aberto para que os participantes individuais executem validadores de redes de testes. Os participantes que desejam iniciar um validador da rede de testes Goerli/Prater podem fazê-lo na plataforma de lançamento da rede de testes Prater.

Contexto

Depois de anos de trabalho na prova de participação do Ethereum, agora estamos na etapa final de testes: as implantações da rede de testes.

Depois de várias devnets, shadow forks e fusões em redes de testes obsoletas, Sepolia foi migrada recentemente para a prova de participação. Agora só falta uma rede de testes: Goerli, e sua Beacon Chain associada, Prater.

A Fusão é diferente das melhorias anteriores feitas no Ethereum porque: primeiro, os operadores de nós precisam atualizar tanto os clientes de camada de consenso quanto os clientes de camada de execução, não somente um deles; segundo, a melhoria é feita em duas fases: a primeira, chamada Bellatrix, em uma altura de slot na Beacon Chain, e a segunda, denominada Paris, ao atingir um valor de Total Difficulty na camada de execução.

Informações sobre a melhoria

Sincronia

A Fusão é um processo de duas etapas. Começa com a melhoria da rede (Bellatrix) na camada de consenso, acionada por uma altura de época, seguida pela transição da camada de execução de prova de trabalho para prova de participação (Paris), acionada por um limite de Dificuldade Total específico, conhecido como Dificuldade Total de Terminal (TTD).

A melhoria Bellatrix está programada para a época 112260 na Beacon Chain da Prater, prevista para as 12h24 da tarde (UTC) de 4 de agosto de 2022. Paris, a parte da camada de execução da transição, será ativada quando alcançar uma Dificuldade Total de Terminal (TTD) de 10790000 na Goerli, esperada entre os dias 6 e 12 de agosto de 2022.

Quando a camada de execução tiver superado o valor de TTD, o próximo bloco será integralmente produzido pelo validador da Beacon Chain. Uma vez que a Beacon Chain tiver finalizado esse bloco, consideraremos a Fusão concluída. Em condições normais de rede, isso deveria acontecer em 2 épocas, ou aproximadamente 13 minutos, depois que o bloco pós-TTD é atingido.

Uma nova tag do bloco JSON-RPC, finalized, retorna o último bloco finalizado ou um erro se não existirem blocos depois da fusão. Esta tag pode ser usada por aplicativos para verificar se a Fusão foi concluída. Da mesma forma, os contratos inteligentes podem consultar o opcode DIFFICULTY (0x44), renomeado PREVRANDAO depois da fusão, para determinar se a Fusão foi realizada. Recomendamos que os provedores de infraestrutura monitorem a estabilidade global da rede, além do estado de finalização.

Versões de clientes

As seguintes versões de clientes são compatíveis com a Fusão nas redes de testes Goerli e Prater. Os operadores de nós devem executar tanto um cliente de camada de execução quanto um cliente de camada de consenso para permanecer na rede durante e depois da Fusão.

Ao escolher qual cliente executar, os validadores devem estar particularmente atentos aos riscos de executar um cliente principal tanto na camada de execução quanto na de consenso. Veja aqui uma explicação sobre esses riscos e suas consequências. Veja aqui uma estimativa da distribuição de clientes de camada de execução e de camada de consenso, e orientações para mudar de um cliente a outro.

Camada de consenso

Nome Versão Link
Lighthouse Geardude Clockberg (v2.4.0) Baixar
Lodestar v0.41.0 Baixar
Nimbus v22.7.0 Baixar
Prysm v2.1.4-rc.0 Baixar
Teku 22.7.0 Baixar

Camada de execução

Nome Versão Link
Besu 22.7.0-RC3 Baixar
Erigon 2022.07.03-alpha Baixar
go-ethereum (geth) v1.10.21 Baixar
Nethermind 1.13.5 Baixar

Especificações da melhoria

As mudanças fundamentais de consenso para a Fusão são especificadas em dois lugares:

  • Mudanças na camada de consenso: no diretório bellatrix do repositório de especificações de consenso
  • Mudanças na camada de execução: na especificação Paris, no repositório de especificações de execução

Além disso, duas outras especificações tratam como os clientes das camadas de consenso e execução interagem:

  • A Engine API, especificada no repositório execution-apis, é usada para comunicação entre as camadas de consenso e execução
  • O Optimistic Sync, especificado na pasta sincronização do repositório de especificações de consenso, é usado pela camada de consenso para importar blocos durante a sincronização do cliente da camada de execução e para fornecer uma visão parcial do cabeçalho da cadeia, do primeiro ao último

Perguntas frequentes

Como operador de nó, o que devo fazer?

Depois da Fusão, um nó completo do Ethereum será uma combinação de um cliente de camada de consenso, que executa a prova de participação na Beacon Chain, e um cliente de camada de execução, que gerencia o estado dos usuários e se encarrega dos cálculos associados às transações. Esses dois clientes se comunicam via uma porta autenticada usando um novo conjunto de métodos JSON RPC chamado Engine API. Os clientes de camada de execução e de camada de consenso se autenticam utilizando um segredo JWT. Os operadores de nós devem consultar a documentação de seus clientes para ver instruções de como gerar e configurar esses clientes.

Em outras palavras, se você já executa um nó na Beacon Chain, agora também precisará executar um cliente de camada de execução. Da mesma forma, se antes você executava um nó na rede de prova de trabalho atual, agora deverá executar um cliente de camada de consenso. Para que se comuniquem de forma segura, cada cliente deve receber um token JWT. Instruções resumidas para executar um nó na rede Goerli/Prater podem ser encontradas aqui.

Vale a pena salientar que, embora ambos façam parte das versões do cliente de camada de consenso, executar um nó de sinalizador é diferente de executar um cliente validador. Os participantes devem executar os dois, mas os operadores de nós só precisam executar o primeiro. Este artigo explica a diferença entre esses componentes em mais detalhes.

E vale observar que cada camada vai manter um conjunto independente de pares e expor suas próprias APIs. As APIs Beacon e JSON RPC continuarão funcionando como esperado.

Como participante, o que preciso fazer?

A fusão Goerli/Prater é sua última chance de garantir que seus validadores estão corretamente configurados antes da transição para a rede principal. Recomendamos enfaticamente executar a transição para evitar qualquer problema inesperado na rede principal.

Como explicado acima, os validadores na Beacon Chain precisarão executar um cliente de camada de execução depois da Fusão, além de seus clientes de camada de consenso. Antes da Fusão, isso era altamente recomendado, mas os validadores podem ter terceirizado essas funções a outros provedores. Essa opção era possível porque os únicos dados necessários na camada de execução eram atualizações no contrato de depósito.

Depois da Fusão, os validadores devem garantir que as transações em blocos que criam e certificam são válidas. Para fazer isso, cada nó de sinalizador deve ser vinculado a um cliente de camada de execução. Observe que ainda é possível associar vários validadores a uma combinação única de nó de sinalizador e cliente de camada de execução. Embora esse cenário aumente as responsabilidades dos validadores, ele também permite que um validador que propõe um bloco tenha direito às taxas de transação prioritária associadas (atualmente atribuídas aos mineradores).

Embora as recompensas do validador se acumulem na Beacon Chain e exijam uma melhoria posterior na rede para serem retiradas, as taxas de transação seguirão sendo pagas, registradas e distribuídas na camada de execução. Os validadores podem especificar qualquer endereço Ethereum como destinatário das taxas da transação.

**Depois de atualizar seu cliente de consenso, certifique-se de definir o destinatário de taxa como parte das configurações do seu cliente validador para garantir que as taxas de transação sejam enviadas para um endereço que você controla. **Se você fez staking usando um provedor de terceiros, cabe ao seu provedor selecionado especificar como essas tarifas são alocadas.

A plataforma de lançamento de participação Prater tem uma Lista de verificação de preparação para a fusão que os participantes podem usar para garantir que passaram por cada etapa do processo. A equipe EthStaker também organizou no dia 29 de julho um workshop de preparação do validador para a fusão.

Por que a data estimada para a Dificuldade Total do Terminal é tão ampla?

A volatilidade da dificuldade incremental por bloco faz com que a estimativa de uma janela para a TTD sea más difícil do que com um bloco ou uma altura de épocas, por isso que o intervalo esperado seja mais amplo. Os usuários devem considerar que esse também será o caso da transição para a rede principal devido a mudanças na taxa de rash da prova de trabalho.

Como desenvolvedor de aplicativos ou de ferramentas, o que devo fazer?

Com a iminência da Fusão na rede de testes Goerli, esta é sua última chance de garantir que seu produto funcione como esperado na transição para a prova de participação e em um contexto de pós-fusão. Como explicamos em um artigo anterior, a Fusão causará um impacto mínimo em um subconjunto de contratos implementados no Ethereum, nenhum dos quais será rescindido. Além disso, a maior parte dos endpoints da API do usuário permanece estável (a menos que você esteja usando métodos específicos de prova de trabalho como eth_getWork).

Dito isso, a maioria dos aplicativos no Ethereum envolve muito mais do que contratos on-chain. Agora é o momento de garantir que seu código front-end, ferramentas, pipeline de implantação e outros componentes off-chain funcionem como esperado. Recomendamos de maneira enfática que os desenvolvedores realizem um ciclo completo de teste e implantação na Sepolia, Ropsten ou Kiln e que informem qualquer problema relacionado a ferramentas ou dependências aos responsáveis desses projetos. Se você não sabe onde informar um problema, utilize este repositório.

Considere também que todas as redes de testes, com exceção de Sepolia e Goerli, se tornarão obsoletas depois da fusão. Se você é um usuário da Ropsten, Rinkeby ou Kiln, deveria planejar migrar para Goerli ou Sepolia. Encontre mais informações sobre isso aqui.

Como usuário do Ethereum ou proprietário de Ether, há algo que eu precise fazer?

Não. A rede principal do Ethereum não é afetada por essa rede de testes. Outros anúncios serão publicados neste blog antes da transição à rede principal.

Como minerador, há algo que eu precise fazer?

Não. Se você está minerando na rede principal do Ethereum ou, saiba que depois da Fusão a operação da rede será inteiramente feita sob a prova de participação. Quando isso ocorrer, a mineração deixará de ser possível na rede.

Como validador, posso retirar minha participação?

Não. A Fusão é a melhoria do Ethereum mais complexa até hoje. Para minimizar os riscos de interrupções na rede, foi adotada uma abordagem mínima, que excluiu desta melhoria qualquer mudança não transitória.

É provável que a partir da primeira melhoria depois da Fusão você já possa retirar sua participação da Beacon Chain. As especificações para as camadas de consenso e de execução estão sendo definidas.

Tenho mais perguntas. Onde posso fazê-las?

A comunidade EthStaker criou um canal comunitário para responder às perguntas de participantes e operadores de nós. Você pode se unir a essa comunidade aqui e usar o canal #goerli-prater para conseguir ajuda. Como dito antes, a equipe EthStaker também organizou no dia 29 de julho um workshop de preparação do validador para a fusão.

Além disso, está prevista uma reunião online sobre a fusão no dia 12 de agosto às 14 horas (UTC). Desenvolvedores de clientes e pesquisadores estarão disponíveis para responder a perguntas de operadores de nós, participantes, provedores de infraestrutura e ferramentas, e membros da comunidade. Espera-se que essa reunião online aconteça depois da fusão da rede de testes Goerli/Prater.

Quando será a fusão?

Até a publicação deste artigo, a data para a transição de prova de participação da rede principal Ethereum não havia sido definida. Qualquer fonte que afirme o contrário provavelmente é fake news. As atualizações serão publicadas neste blog. Esteja atento!

Considerando que não haja problemas durante a fusão das redes de testes Goerli e Prater, e uma vez que os clientes tenham versões com todas as funções incorporadas, se selecionará uma altura de slot para a melhoria da Bellatrix na Beacon Chain da rede principal e um valor de dificuldade total será definido para a transição da rede principal. Os clientes poderão, então, propor versões que permitam a Fusão na rede principal. Estas serão anunciadas neste blog e em outras publicações da comunidade.

No entanto, se em qualquer momento do processo forem detectados problemas ou caso a cobertura dos testes seja considerada insuficiente, estas questões serão tratadas antes de prosseguir com o processo de implantação.

Somente então será possível determinar a data exata da Fusão.

Em outras palavras, em breve (🔜).


Объявление о слиянии Goerli и Prater

  • Во время последнего перехода тестовой сети на модель доказательства владения будет выполнено слияние Goerli с Prater. Объединенная сеть Goerli и Prater после слияния сохранит название Goerli.
  • Bellatrix, обновление сети Prater, предназначенное для ее подготовки к слиянию, произойдет в эпоху 112260, наступление которой ожидается в 12:24 (UTC) 4 августа 2022 года.
  • После активации Bellatrix слияние Goerli и Prater произойдет, когда Goerli достигнет значения общей сложности 10790000. Это событие ожидается 6–12 августа 2022 года.
  • После слияния набор валидаторов Goerli останется открытым для отдельных дольщиков, желающих запустить валидаторы тестовых сетей. Дольщики, желающие запустить валидатор Goerli/Prater, могут сделать это с помощью панели запуска Prater.

Контекст

После долгих лет работы по внедрению доказательства владения в Ethereum мы приступаем к финальной стадии тестирования — запуску тестовой сети.

После применения нескольких сетей разработки, теневых ветвлений и выполнения слияний на устаревших тестовых сетях сеть Sepolia недавно была переведена на модель доказательства владения. Теперь осталась только одна тестовая сеть — Goerli вместе со связанной с ней сетью Beacon Chain Prater.

Две особенности принципиально отличают это слияние от предыдущих обновлений Ethereum. Во-первых, операторам узлов необходимо обновлять свои клиенты как слоя консенсуса (CL), так и исполнения (EL) одновременно, а не по одному. Во-вторых, обновление активируется в два этапа: первый, Bellatrix, на высоте эпохи в сети Beacon Chain, а второй, Paris, — при достижении значения общей сложности на слое исполнения.

Информация об обновлении

Сроки

Процесс слияния будет состоять из двух этапов. Он начнется с обновления сети, Bellatrix, на слое консенсуса, которое запускается высотой эпохи. За этим следует переход слоя исполнения от доказательства работы к доказательству владения, Paris, который запускается определенным пороговым значением общей сложности под названием конечная общая сложность (Terminal Total Difficulty, TTD).

Обновление Bellatrix назначено на эпоху 112260 сети Beacon Chain Prater и ожидается в 12:24 (UTC) 4 августа 2022 года. Paris, часть перехода на слое исполнения, будет запущена при достижении значения конечной общей сложности (TTD) 10790000 сети Goerli, что ожидается 6–12 августа 2022 года.

Как только слой исполнения превысит значение TTD, следующий блок будет создан полностью валидатором сети Beacon Chain. Слияние будет считаться оконченным сразу после того, как сеть Beacon Chain завершит создание этого блока. При нормальных условиях работы сети это должно произойти в течение 2 эпох (или приблизительно через 13 минут) после попадания в первый блок, созданный после достижения TTD.

Новый завершенный тег блока JSON-RPC выводит последний оконченный блок или ошибку, если такого блока после слияния не существует. Этот тег может использоваться для приложений, чтобы проверять завершенность слияния. Аналогично умные контракты могут запрашивать опкод DIFFICULTY (0x44), который после слияния получит имя PREVRANDAO, чтобы определить, произошло ли слияние. Мы рекомендуем поставщикам инфраструктуры следить не только за завершением процесса, но и за общей стабильностью сети.

Выпуски клиентов

Следующие выпуски клиентов поддерживают слияние в тестовых сетях Goerli и Prater. Операторы узлов должны запускать клиент и слоя исполнения, и консенсуса, чтобы оставаться в сети во время процесса слияния и после него.

При выборе клиента для запуска валидаторы должны уделять особое внимание рискам запуска большинства клиентов, как на EL, так и на CL. С пояснением этих рисков и их последствий можно ознакомиться здесь. С оценкой текущего распространения клиентов EL и CL, а также руководством для перехода от одного клиента к другому можно ознакомиться здесь.

Слой консенсуса

Слой исполнения

Спецификации обновлений

Критические изменения консенсуса для слияния указаны в двух местах:

Кроме того, две другие спецификации охватывают способы взаимодействия клиентов слоя консенсуса и слоя исполнения:

  • интерфейс API движка, указанный в репозитории execution-apis, используется для коммуникации между слоями консенсуса и исполнения;
  • спецификация Optimistic Sync, указанная в папке sync репозитория consensus-specs, используется слоем консенсуса для импорта блоков по мере синхронизации клиента слоя исполнения и обеспечивает частичный обзор головы цепочки от первого до последнего значения.

Часто задаваемые вопросы

Что нужно делать оператору узла?

После слияния полный узел Ethereum будет объединять в себе клиент слоя консенсуса (CL), запущенный по модели доказательства владения в сети Beacon Chain, и клиент слоя исполнения (EL), который управляет пользовательским состоянием и запускает вычисления, связанные с транзакциями. Слаженность их работы достигается с помощью аутентифицированного порта и нового набора методов удаленного вызова процедур (RPC) JSON под названием API движка. Клиенты EL и CL аутентифицируют друг друга с помощью секрета JWT. Операторы узлов могут найти инструкции по их созданию и настройке в документации своих клиентов.

Другими словами, если вы уже управляете узлом в Beacon Chain, теперь вам также нужно будет управлять клиентом слоя исполнения. Аналогично, если вы управляете узлом в текущей сети с доказательством работы, вам будет необходимо управлять клиентом слоя консенсуса. Для их безопасной связи необходимо передать на каждый клиент токен JWT. Краткие инструкции по запуску узла в сети Goerli/Prater см. здесь.

Стоит подчеркнуть: хотя они оба являются частью выпусков клиентов слоя консенсуса, запуск узла Beacon отличается от запуска клиента валидатора. Дольщики должны запускать оба, но операторам узла нужен только первый. В этой публикации более подробно объясняется разница между обоими компонентами.

Обратите также внимание, что каждый слой будет содержать независимый набор пиров и собственный программный интерфейс API. Поэтому программные интерфейсы API Beacon и удаленного вызова процедур JSON продолжат работать так, как ожидается.

Что нужно делать дольщику?

Слияние Goerli и Prater — последняя возможность убедиться в правильной настройке ваших валидаторов до перехода основной сети. Настоятельно рекомендуется выполнить переход сейчас, чтобы избежать непредвиденных проблем в основной сети.

Как уже говорилось выше, после слияния валидаторам сети Beacon Chain необходимо будет запустить клиент слоя исполнения, помимо клиентов слоя консенсуса. Это настоятельно рекомендовалось до слияния, но валидаторы могли передавать эти обязанности третьим сторонам. Это было возможно, потому что единственными данными, необходимыми для слоя исполнения, были обновления депозитного контракта.

После слияния валидаторы должны удостовериться, что транзакции в блоках, которые они создают и подтверждают, действительны. Для этого каждый узел Beacon должен быть связан с клиентом слоя исполнения. Обратите внимание, что несколько валидаторов все еще могут быть связаны с одной комбинацией узла Beacon и клиента слоя исполнения. Это расширяет круг обязанностей валидаторов, но также дает валидатору, предлагающему блок, право приоритетного получения комиссий за соответствующие транзакции (которые в настоящее время поступают майнерам).

Вознаграждение для валидатора начисляется в сети Beacon Chain и для снятия требует последующего обновления сети, но комиссии за транзакции будут и далее выплачиваться, сгорать и распределяться на слое исполнения. Валидаторы могут указывать любой адрес Ethereum в качестве получателя комиссий за транзакции.

После обновления клиента консенсуса в настройках обязательно установите получателя комиссий частью клиента валидатора, чтобы убедиться, что комиссия за транзакцию отправляется на адрес, которым вы управляете. Если вы внесли свою долю с помощью третьей стороны, именно она должна указать способ распределения комиссий.

Панель запуска стейкинга Prater содержит контрольный список для проверки готовности к слиянию, с помощью которого дольщики могут убедиться в прохождении каждого этапа процесса. 29 июля команда EthStaker также проведет семинар по подготовке валидаторов к слиянию.

Почему прогнозированная дата достижения конечной общей сложности неточная?

В отличие от использования высоты блока или эпохи, переменчивость инкрементной сложности в каждом блоке усложняет определение окна достижения значения TTD, поэтому диапазон возможной даты такой широкий. Пользователям следует обратить внимание, что это касается и перехода основной сети — из-за изменений в скорости хэширования модели с доказательством работы.

Что требуется от разработчика приложений или инструментов?

Запуск слияния на Goerli — последняя возможность удостовериться, что ваш продукт будет работать надлежащим образом при переходе к доказательству владения и в среде после слияния. Как говорилось в предыдущей публикации, слияние окажет лишь минимальное воздействие на подмножество контрактов, развернутых в Ethereum, и ни один из них не должен быть нарушен. Кроме того, львиная доля пользовательских конечных точек программного интерфейса API остается стабильной (если вы не используете специальные методы доказательства работы, такие как eth_getWork).

Однако большинство приложений в Ethereum охватывает гораздо больше, чем контракты в цепи. Теперь вам пора убедиться, что ваш код интерфейса, инструменты, конвейер развертывания и другие не входящие в цепь компоненты работают так, как задумано. Мы настоятельно рекомендуем разработчикам выполнить полный цикл тестирования и развертывания в сети Sepolia, Ropsten или Kiln и сообщить соответствующим сопроводителям проектов о любых проблемах с инструментами или зависимостями. Если вы не уверены, где следует открыть запрос на решение проблемы, используйте этот репозиторий.

Кроме того, следует отметить, что все тестовые сети, помимо Sepolia и Goerli, устареют после слияния. Пользователям Ropsten, Rinkeby или Kiln следует рассмотреть переход на Goerli или Sepolia. Больше об этом можно узнать здесь.

Требуется ли что-нибудь от пользователей Ethereum или владельцев эфиров?

Нет. Эта тестовая сеть не повлияет на основную сеть Ethereum. Перед переходом основной сети в этом блоге появятся последующие объявления.

Требуется ли что-нибудь от майнеров?

Нет. Если вы занимаетесь майнингом в основной сети Ethereum, вам нужно знать, что после слияния эта сеть будет полностью функционировать по принципу доказательства владения. После слияния майнинг в ней будет невозможен.

Может ли валидатор снять свою долю?

Нет. Слияние — самое сложное обновление среды Ethereum за все время ее существования. Чтобы свести к минимуму риски нарушения работы сети, был принят минимальный подход, исключающий из данного обновления любые изменения, не связанные с переходом.

Снятие средств с Beacon Chain, вероятно, будет введено с первым обновлением после слияния. Спецификации для слоев консенсуса и исполнения находятся в процессе разработки.

У меня есть еще вопросы. К кому с ними обратиться?

Сообщество EthStaker создало канал на платформе Discord, чтобы отвечать на вопросы дольщиков и операторов узлов. Вы можете присоединиться к этому каналу и обратиться за помощью, используя хэштег #goerli-prater. Как уже упоминалось выше, 29 июля команда EthStaker также проведет семинар по подготовке валидаторов к слиянию.

Кроме того, 12 августа в 14:00 (UTC) запланирован созвон сообщества по вопросам слияния. Исследователи и разработчики клиентов смогут ответить на вопросы операторов узлов, дольщиков, поставщиков инструментов и инфраструктуры, а также членов сообщества. Обратите внимание, что проведение этого созвона планируется после слияния Goerli и Prater.

Когда произойдет слияние?

На момент этой публикации время перехода основной сети Ethereum на доказательство владения еще не определено. Если кто-то утверждает обратное, то это, скорее всего, мошенник. Новости будут публиковаться в этом блоге. Будьте бдительны!

При отсутствии проблем во время слияния Goerli и Prater, как только появятся полноценные выпуски для клиентов, будет выбрана высота ячейки для обновления Bellatrix в основной сети Beacon Chain, а также будет установлено значение общей сложности для перехода основной сети. Клиенты затем реализуют выпуски, позволяющие выполнить слияние в основной сети. Об этом будет объявлено в этом блоге и других публикациях сообщества.

Но если на каком-либо этапе процесса появятся проблемы или тестовый охват будет оценен как недостаточный, эти вопросы будут решены до продолжения развертывания.

Только после этого можно будет определить точную дату слияния.

Иными словами, 🔜.


Goerli/Prater 合并公告

  • Goerli 将与 Prater 合并,完成最后一次测试网权益证明过渡。 在合并后,Goerli/Prater 融合后的网络将保留 Goerli 的名称。
  • 已为合并做好准备的 Prater 升级 Bellatrix 将在时段 112260 启动,预计时间为 12:24PM UTC on August 4, 2022
  • Bellatrix 启动后,Goerli/Prater 合并将在 Goerli 达到 10790000 的总难度时开始,预计时间为 August 6-12, 2022
  • 合并后,Goerli 的验证者集将针对个人质押人开放,以便他们运行测试网验证者。 想要启动 Goerli/Prater 验证者的质押人可在 Prater 启动板上执行。

背景

经过多年努力将权益证明引入以太坊后,我们现在终于进入最后的测试阶段:测试网部署!

在已弃用测试网上经过几次开发者网络测试、影子分叉和合并后,Sepolia 最近已经过渡到权益证明。 现在,仅剩下最后一个测试网:Goerli 以及与之相关的信标链 Prater。

此次合并与以往以太坊升级的区别体现在两个方面。 首先,节点运营商需要依次升级他们的共识层 (CL) 和执行层 (EL) 客户端,而非仅升级两者之一。 其次,此升级分两个阶段启动:第一个阶段名为 Bellatrix,在信标链上达到某个时段高度时开始;第二个阶段名为 Paris,在执行层达到某个 Total Difficulty 值时开始。

升级信息

时间

_合并_分两个步骤进行。 首先是共识层网络升级 Bellatrix,由时段高度触发。 然后是执行层从工作量证明过渡到权益证明的升级 Paris,由特定的 Total Difficulty 阈值触发,即 Terminal Total Difficulty (TTD)。

Bellatrix 升级计划在 Prater 信标链上的时段 112260 实施,预计时间为 12:24PM UTC on August 4, 2022Paris 为执行层部分的过渡,将在 Goerli 上的 Terminal Total Difficulty (TTD) 达到 10790000 时执行,预计时间为 August 6-12, 2022

仅当执行层超过 TTD 时,信标链验证者才会单独生成下一个区块。 而仅当信标链最终确认此区块后,我们才会认为合并已经完成。 假设网络状态正常,在达到第一个 TTD 后区块之后,此过程应持续 2 个时段,或大约 13 分钟。

新的 JSON-RPC 区块标签 finalized 将返回最新确认的区块,或者,如果不存在合并后区块,则会返回错误。 应用程序可使用此标签检查合并是否完成。 同样,智能合约可以查询 DIFFICULTY 操作码 (0x44) 以确定合并是否发生,该操作码合并后重命名为 PREVRANDAO。 因此,我们建议除了监控最终状态之外,基础设施提供商还应监控网络的总体稳定性。

客户端版本

以下客户端版本均支持 Goerli 和 Prater 测试网的合并。 节点运营商必须同时运行执行层和共识层客户端,才能在合并期间和之后一直在线。

选择要运行的客户端时,验证者应特别注意在执行层和共识层运行主流客户端的风险。 如需了解这些风险及其后果,请点击此处。 如需了解当前执行层和共识层客户端的分布估计,以及从一种客户端切换至另一种客户端的操作指南,请点击此处

共识层

名称 版本 链接
Lighthouse Geardude Clockberg (v2.4.0) 下载
Lodestar v0.41.0 下载
Nimbus v22.7.0 下载
Prysm v2.1.4-rc.0 下载
Teku 22.7.0 下载

执行层

名称 版本 链接
Besu 22.7.0-RC3 下载
Erigon 2022.07.03-alpha 下载
go-ethereum (geth) v1.10.21 下载
Nethermind 1.13.5 下载

升级规范

合并的共识关键变更在下面两个位置详细说明:

除此之外,还有两套规范涉及到共识层和执行层客户端的交互方式:

  • 引擎应用程序接口,在执行应用程序接口存储库中详细说明,用于实现共识层和执行层之间的通信
  • 乐观同步,在共识规范存储库的 sync 文件夹下详细说明,由共识层用于在执行层客户端同步时导入区块,并按前后顺序提供区块链头部的部分视图

常见问题

作为节点运营商,我应该做什么?

合并之后,以太坊全节点将共识层 (CL) 客户端与执行层 (EL) 客户端合二为一。前者运行权益证明信标链,后者管理用户状态并运行与交易相关的计算。 这两个客户端使用一套新的 JSON RPC 方法,即引擎应用程序接口,通过经过身份验证的端口进行通信。 此外,执行层和共识层客户端使用 JSON Web 令牌 (JWT) 密钥相互验证。 因此,节点运营商应参考客户端文档,了解如何生成和配置这种密钥。

换句话说,如果你已经在信标链上运行了一个节点,现在还需要运行一个执行层客户端。 同样,如果你在当前的工作量证明网络上运行一个节点,还需要运行一个共识层客户端。 为使两个客户端之间安全通信,必须将 JSON Web 令牌 (JWT) 密钥传送至每个客户端。 有关在 Goerli/Prater 网络上运行节点的总结说明,请点击此处

值得强调的是,虽然信标节点和验证者客户端都是共识层客户端版本的一部分,但它们的运行却存在差异。 质押人必须运行两种客户端,但节点运营商仅需运行信标节点。 本文更加深入地解释了两者之间的差异。

另请注意,每一层都会维护一组独立的对等节点,并公开自己的应用程序接口。 信标应用程序接口和 JSON RPC 应用程序接口将继续按预期运行。

作为质押人,我需要做什么?

Goerli/Prater 合并为你提供了最后一次机会,确保你的验证者在主网过渡之前已正确配置。 强烈建议现在运行至过渡结束,以避免主网出现任何意外问题。

如前所述,在合并后,除了其共识层客户端以外,信标链上的验证者还需要运行执行层客户端。虽然强烈建议在合并前也这么做,但验证者本可以将这些功能外包给第三方提供商执行。 由于执行层所需的唯一数据是对存款合约的更新,因此可以实现外包。

合并后,验证者需要确保他们创建并证明的区块中的交易有效。 为此,每个信标节点必须与一个执行层客户端配对。 请注意,多个验证者仍可与一个信标节点和执行层客户端组合配对。 虽然这增加了验证者的责任,但也使提出区块的验证者有权获得相关交易优先费(该费用目前由矿工获得)。

虽然验证者奖励会在信标链上累积,且需要后续网络升级才能提取,但交易费的支付、消耗和分发将继续在执行层执行。 验证者可将任何以太坊地址指定为交易费的接收者。

更新完共识层客户端之后,务必将 fee recipient 设为验证者客户端配置的一部分,以确保将交易费发送至由你控制的地址。如果你使用了第三方提供商进行质押,则由你选定的提供商指定如何分配这些费用。

Prater 质押启动板有一张合并准备情况检查清单,质押人可用它确保完成了合并的每个步骤。 EthStaker 团队还在 7 月 29 日举办了一场合并验证者准备工作研讨会

为什么 Terminal Total Difficulty 的预估日期范围如此宽泛?

每个区块的难度增量不同,导致 TTD 时间窗口的预估较之区块或时段高度更难,因此得到的预期范围更广。 用户应注意,由于工作量证明的哈希率会发生变化,因此主网过渡的时间也很难预测。

作为应用程序或工具的开发者,我应该做什么?

随着合并在 Goerli 启动,现在是确保你的产品在权益证明过渡期间,以及合并后环境下按预期工作的最后一次机会。 如前一篇文章所述,合并仅会对以太坊上部署的一小部分合约产生极小的影响。这些合约均不会遭到中断。 此外,大部分用户的应用程序接口端点保持稳定(除非使用特定的工作量证明方法,如 eth_getWork)。

尽管如此,以太坊上的大多数应用程序涉及的远不止链上合约。 就是现在,需要确保你的前端代码、工具、部署管道和其他链下组件能够按预期工作。 我们强烈建议开发者在 Sepolia、Ropsten 或 Kiln 上运行完整的测试和部署过程,并向项目维护者报告任何与工具或依赖项相关的问题。 如果你不确定在哪里提出问题,请使用此存储库

还应注意,除 Sepolia 和 Goerli 以外,所有测试网均将在合并后弃用。 因此,如果你是 Ropsten、Rinkeby 或 Kiln 的用户,你应该计划迁移至 Goerli 或 Sepolia。 如需深入了解相关信息,请点击此处

作为以太坊用户或以太币持有者,我是否需要做点什么?

不需要。 以太坊主网并不受此测试网的影响。 在主网过渡之前,将会在此博客中发布后续公告。

作为矿工,我是否需要做点什么?

不需要。 如果你在以太坊主网上挖矿,就应该了解在合并后,网络将完全采用权益证明运营。 届时,网络上将不再支持挖矿。

作为验证者,我能否撤销质押?

不能。 合并是以太坊迄今为止最为复杂的升级。 为将网络中断的风险降至最低,我们采取了最精简的方法,即在本次升级中摒弃了一切与过渡无关的变更。

从信标链撤销质押这一功能很可能会在合并后的第一次升级中实现。 共识层和执行层的相关规范均在制定中。

我还有其他问题,可以在哪里提问?

EthStaker 社区已经设立了一个争议解决频道,用于回答质押人和节点运营商的问题。 你可以从此处加入争议解决频道,然后使用 #goerli-prater 频道获得帮助。 如前所述,EthStaker 还在 7 月 29 日举办了一场合并验证者准备工作研讨会

此外,计划在协调世界时 8 月 12 日 14:00 举行合并社区会议。 客户端开发者和研究员将在会议上回答节点运营商、质押人、基础设施和工具提供商以及社区成员提出的问题。 请注意,此次社区会议预计在 Goerli/Prater 合并之后举行。

何时合并?

截至本文发布时,以太坊主网的权益证明过渡时期还 not 确定。 任何来源发布的其他相关言论都可能不实。 最新信息将通过本博客发布。 请注意网络信息安全!

假定在 Goerli/Prater 合并期间未出现任何问题,只要客户端有功能完备的版本,将为主网信标链上的 Bellatrix 升级选择一个时隙高度,并为主网过渡设定一个总难度值。 之后,客户端将会发布支持主网合并的版本。 届时将在本博客和其他社区出版物中发布相关公告。

然而,如果在此过程中发现任何问题,或测试范围被判定不够全面,我们将解决这些问题,然后再继续推进部署进程。

只有到那时,才能预估合并的确切日期。

也就是说,我们会快马加鞭 🔜。

Source link

crypto & nft lover

Johnathan DoeCoin

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar.

Newsletter

Subscribe my Newsletter for new blog posts, tips & new photos. Let's stay updated!

Leave a Comment

crypto & nft lover

Johnathan DoeCoin

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar.