نام در حال استفاده

یک برچسب در حال حاضر با نام شاخه ارائه شده وجود دارد. بسیاری از دستورات GIT نام برچسب و شاخه را می پذیرند ، بنابراین ایجاد این شاخه ممکن است باعث رفتار غیر منتظره شود. آیا مطمئن هستید که می خواهید این شاخه را ایجاد کنید؟

devp2p / caps / et. md

• به پرونده T بروید
• به خط L بروید
• مسیر کپی کردن
• کپی کردن پیوند ثابت

این تعهد متعلق به هیچ شعبه ای در این مخزن نیست و ممکن است متعلق به یک چنگال در خارج از مخزن باشد.

3 همکار

کاربرانی که در این پرونده مشارکت داشته اند

• با دسک تاپ باز کنید
• مشاهده خام
• کپی کردن محتوای خام کپی محتوای خام

   

محتوای خام را کپی کنید

محتوای خام را کپی کنید

پروتکل سیم اتریوم (ETH)

"ETH" پروتکل حمل و نقل RLPX است که تبادل اطلاعات blockchain Ethereum بین همسالان را تسهیل می کند. نسخه پروتکل فعلی ETH/67 است. برای لیستی از تغییرات در نسخه های پروتکل گذشته ، به پایان سند مراجعه کنید.

پس از برقراری ارتباط ، باید یک پیام وضعیت ارسال شود. پس از دریافت پیام وضعیت همسالان ، جلسه اتریوم فعال است و هر پیام دیگری ممکن است ارسال شود.

در طی یک جلسه ، سه کار سطح بالا می تواند انجام شود: همگام سازی زنجیره ای ، انتشار بلوک و تبادل معاملات. این وظایف از مجموعه های جدا شده از پیام های پروتکل استفاده می کنند و مشتری ها به طور معمول آنها را به عنوان فعالیت های همزمان در تمام اتصالات همسالان انجام می دهند.

اجرای مشتری باید محدودیت هایی را در اندازه پیام پروتکل اعمال کند. حمل و نقل زیرین RLPX اندازه یک پیام واحد را به 16. 7 MIB محدود می کند. محدودیت های عملی برای پروتکل ETH کمتر است ، به طور معمول 10 MIB. اگر یک پیام دریافت شده از حد مجاز بزرگتر باشد ، همسالان باید قطع شوند.

علاوه بر حد سخت در پیام های دریافت شده ، مشتری ها همچنین باید محدودیت های نرم "را به درخواست ها و پاسخ هایی که ارسال می کنند تحمیل کنند. حد نرم توصیه شده در هر نوع پیام متفاوت است. محدود کردن درخواست ها و پاسخ ها تضمین می کند که فعالیت همزمان ، به عنوان مثالهمگام سازی و تبادل معامله را به راحتی در همان اتصال همسالان کار کنید.

انتظار می رود گره های شرکت کننده در پروتکل ETH از زنجیره ای کامل همه بلوک ها از بلوک پیدایش تا آخرین بلوک فعلی آگاهی داشته باشند. این زنجیره با بارگیری آن از سایر همسالان بدست می آید.

پس از اتصال ، هر دو همسالان پیام وضعیت خود را ارسال می کنند ، که شامل کل دشواری (TD) و هش از بلوک شناخته شده "بهترین" آنها است.

مشتری با بدترین TD سپس با استفاده از پیام GetBlockHeaders اقدام به دانلود هدرهای بلوک می کند. مقادیر اثبات کار را در هدرهای دریافتی تأیید می کند و بدنه های بلوک را با استفاده از پیام GetBlockBodies واکشی می کند. بلوک های دریافتی با استفاده از ماشین مجازی اتریوم اجرا می شوند و درخت حالت و رسیدها را دوباره ایجاد می کنند.

توجه داشته باشید که دانلود سرصفحه، مسدود کردن دانلود بدنه و اجرای بلوک ممکن است همزمان اتفاق بیفتد.

همگام سازی حالت (با نام مستعار "همگام سازی سریع")

نسخه های پروتکل eth/63 تا eth/66 نیز امکان همگام سازی درخت حالت را فراهم می کند. از آنجایی که پروتکل نسخه eth/67، درخت حالت اتریوم دیگر با استفاده از پروتکل eth قابل بازیابی نیست و به جای آن، بارگیری های حالت توسط پروتکل کمکی snap ارائه می شود.

همگام سازی حالت معمولاً با بارگیری زنجیره هدرهای بلوک و تأیید اعتبار آنها انجام می شود. بدنه های بلاک مانند بخش همگام سازی زنجیره ای درخواست می شوند، اما تراکنش ها اجرا نمی شوند، فقط «اعتبار داده» آن ها تأیید می شود. مشتری یک بلوک را در نزدیکی سر زنجیره انتخاب می کند ("بلوک محوری") و وضعیت آن بلوک را دانلود می کند.

بلوک های تازه استخراج شده باید به همه گره ها منتقل شوند. این از طریق انتشار بلوک اتفاق می افتد، که یک فرآیند دو مرحله ای است. هنگامی که یک پیام اعلامی NewBlock از یک همتا دریافت می شود، مشتری ابتدا اعتبار هدر اصلی بلوک را تأیید می کند و بررسی می کند که آیا ارزش اثبات کار معتبر است یا خیر. سپس بلوک را با استفاده از پیام NewBlock به بخش کوچکی از همتاهای متصل (معمولاً جذر تعداد کل همتاها) ارسال می کند.

پس از بررسی اعتبار هدر، مشتری با اجرای تمام تراکنش های موجود در بلوک، و محاسبه وضعیت پست بلوک، بلوک را به زنجیره محلی خود وارد می کند. هش ریشه حالت بلوک باید با ریشه پست حالت محاسبه شده مطابقت داشته باشد. هنگامی که بلوک به طور کامل پردازش شد، و معتبر تلقی شد، مشتری یک پیام NewBlockHashes در مورد بلوک به همه همتاهایی که قبلاً به آنها اطلاع نداده ارسال می کند. آن همتایان ممکن است بعداً در صورتی که نتوانند آن را از طریق NewBlock از شخص دیگری دریافت کنند، بلوک کامل را درخواست کنند.

یک گره هرگز نباید یک اعلان بلوک را به همتای که قبلاً همان بلوک را اعلام کرده است، ارسال کند. این معمولاً با به خاطر سپردن مجموعه بزرگی از هش های بلوکی که اخیراً به یا از هر همتا ارسال شده است، به دست می آید.

در صورتی که بلوک جانشین بلافصل آخرین بلوک فعلی مشتری نباشد، دریافت یک اعلامیه بلوک ممکن است باعث همگام سازی زنجیره شود.

همه گره ها برای انتقال آنها به معدنچیان ، باید معاملات معلق را مبادله کنند ، که آنها را برای ورود به blockchain انتخاب می کند. اجرای مشتری مجموعه ای از معاملات در انتظار را در "استخر معامله" پیگیری می کند. استخر مشمول محدودیت های خاص مشتری است و می تواند شامل بسیاری از معاملات (یعنی هزاران نفر) باشد.

هنگامی که یک اتصال همتا جدید برقرار شد ، استخرهای معامله از هر دو طرف باید هماهنگ شوند. در ابتدا ، هر دو انتهای باید پیام های NewPooledTransactionHashes را که شامل کلیه هش های معامله در استخر محلی است ، ارسال کند تا مبادله را شروع کند.

با دریافت اعلامیه NewPooledTransactionHashes ، مشتری مجموعه دریافت شده را فیلتر می کند ، و هش های معامله ای را که هنوز در استخر محلی خود ندارد ، جمع آوری می کند. سپس می تواند معاملات را با استفاده از پیام GetPooledTransactions درخواست کند.

هنگامی که معاملات جدید در استخر مشتری ظاهر می شود ، باید آنها را با استفاده از معاملات و پیام های NewPooledTransactionHashes به شبکه پخش کند. پیام معاملات رله های معاملات را کامل می کند و به طور معمول به یک بخش کوچک و تصادفی از همسالان متصل ارسال می شود. همه همسالان دیگر اطلاعیه ای از هش معامله دریافت می کنند و در صورت عدم مشهود برای آنها می توانند از شیء معامله کامل درخواست کنند. انتشار معاملات کامل به کسری از همسالان معمولاً تضمین می کند که همه گره ها معامله را دریافت می کنند و نیازی به درخواست آن نخواهند داشت.

یک گره هرگز نباید معامله ای را به یک همکار ارسال کند که بتواند از قبل آن را تعیین کند (یا به دلیل این که قبلاً ارسال شده بود یا به این دلیل که در ابتدا از این همسالان مطلع شده بود). این امر معمولاً با به یاد آوردن مجموعه ای از معامله هایی که اخیراً توسط همسالان منتقل شده اند حاصل می شود.

رمزگذاری معامله و اعتبار

اشیاء معامله ای که توسط همسالان رد و بدل شده اند یکی از دو رمزگذاری دارند. در تعاریف در این مشخصات ، ما به معاملات هر دو رمزگذاری با استفاده از شناسه TXₙ اشاره می کنیم.

بدون استفاده ، معاملات میراث به عنوان لیست RLP ارائه می شود.

معاملات تایپ شده EIP-2718 به عنوان آرایه های بایت RLP رمزگذاری می شوند که در آن اولین بایت نوع معامله (TX-Type) و بیت های باقیمانده داده های خاص از نوع مات هستند.

معاملات باید هنگام دریافت تأیید شود. اعتبار به حالت زنجیره اتریوم بستگی دارد. نوع خاصی از اعتبار این مشخصات مربوط به این نیست که آیا معامله با موفقیت توسط EVM قابل انجام است ، بلکه فقط این است که آیا برای ذخیره موقت در استخر محلی و برای مبادله با سایر همسالان قابل قبول است.

معاملات طبق قوانین زیر تأیید می شوند. در حالی که رمزگذاری معاملات تایپ شده مات است ، فرض بر این است که DATA TX آنها مقادیری را برای غیرقانونی ، قیمت گاز ، گاز محدود می کند و حساب فرستنده معامله را می توان از امضای آنها تعیین کرد.

• اگر معامله تایپ شود ، نوع TX باید برای اجرای آن شناخته شود. انواع معاملات تعریف شده ممکن است حتی قبل از اینکه برای ورود به یک بلوک قابل قبول باشند ، معتبر تلقی شوند. پیاده سازی ها باید همسالان را ارسال کنند که معاملات از نوع ناشناخته را ارسال می کنند.
• امضای باید با توجه به طرح های امضای پشتیبانی شده توسط زنجیره معتبر باشد. برای معاملات تایپ شده ، رسیدگی به امضا با EIP معرفی نوع تعریف می شود. برای معاملات میراث ، دو طرح مورد استفاده فعال طرح اصلی "خانه" و طرح EIP-155 است.
• محدودیت گاز باید "گاز ذاتی" معامله را پوشش دهد.
• حساب فرستنده معامله ، که از امضای گرفته شده است ، باید دارای مانده اتر کافی برای تأمین هزینه (گاز-محدود * قیمت گاز + ارزش) معامله باشد.
• عدم انجام معامله باید برابر یا بیشتر از غیرقانونی فعلی حساب فرستنده باشد.
• هنگام در نظر گرفتن معامله برای گنجاندن در استخر محلی ، این وظیفه است که تعیین کنیم تعداد معاملات "آینده" با غیرقانونی بیشتر از حساب جاری معتبر است و چه درجه ای "شکاف های غیرقانونی" قابل قبول است.

پیاده سازی ها ممکن است سایر قوانین اعتبار سنجی را برای معاملات اجرا کنند. به عنوان مثال ، معمول است که معاملات رمزگذاری شده بزرگتر از 128 کیلوبایت را رد کنید.

مگر در مواردی که در غیر این صورت ذکر نشده باشد ، پیاده سازی ها نباید همسالان را برای ارسال معاملات نامعتبر جدا کنند و به جای آن باید آنها را دور بیندازند. این امر به این دلیل است که همکار ممکن است تحت قوانین اعتبار سنجی کمی متفاوت عمل کند.

رمزگذاری و اعتبار را مسدود کنید

بلوک های اتریوم به شرح زیر رمزگذاری می شوند:

در پیام های پروتکل خاص ، لیست های معامله و ommer به عنوان یک مورد واحد به نام "بلوک بدنه" به هم منتقل می شوند.

اعتبار هدرهای بلوک به زمینه ای که در آن استفاده می شود بستگی دارد. برای یک هدر تک بلوک ، فقط اعتبار مهر و موم اثبات کار (مخلوط هضم ، بلوک) قابل تأیید است. هنگامی که از یک هدر برای گسترش زنجیره محلی مشتری استفاده می شود ، یا چندین هدر در هنگام هماهنگ سازی زنجیره ای به ترتیب به صورت توالی پردازش می شوند ، قوانین زیر اعمال می شود:

• هدرها باید زنجیره ای را تشکیل دهند که تعداد بلوک های متوالی باشد و والدین هر یک از هدر با هش از هدر قبلی مطابقت داشته باشند.
• هنگام گسترش زنجیره ذخیره شده محلی، پیاده سازی ها باید تأیید کنند که مقادیر دشواری، محدودیت گاز و زمان در محدوده قوانین پروتکل ارائه شده در کاغذ زرد قرار دارند.
• میدان سرصفحه گاز مصرفی باید کمتر یا مساوی با حد گاز باشد.
• میدان هدر بیسفی به ازای هر گاز باید برای بلوک های بعد از هارد فورک لندن وجود داشته باشد. توجه داشته باشید که بیسفی به ازای هر گاز باید برای بلوک های قبلی وجود نداشته باشد. این قانون توسط EIP-1559 به طور ضمنی اضافه شد، که فیلد را به تعریف هش بلوک اتریوم اضافه کرد.

برای بلوک های کامل، بین اعتبار انتقال حالت EVM بلوک و «اعتبار داده های ضعیف تر» بلوک تمایز قائل می شویم. در این مشخصات به تعریف قوانین انتقال حالت پرداخته نشده است. ما به اعتبار داده های بلوک برای اهداف انتشار فوری بلوک و در طول همگام سازی حالت نیاز داریم.

برای تعیین اعتبار داده های یک بلوک، از قوانین زیر استفاده کنید. پیاده سازی ها باید همتاهایی را که بلوک های نامعتبر را ارسال می کنند، قطع کنند.

• هدر بلوک باید معتبر باشد.
• تراکنش های موجود در بلوک باید برای درج در زنجیره به شماره بلوک معتبر باشند. این بدان معنی است که علاوه بر قوانین اعتبارسنجی تراکنش که قبلاً ارائه شد، تأیید اینکه آیا نوع tx در شماره بلوک مجاز است یا خیر، مورد نیاز است و اعتبار سنجی گاز تراکنش باید شماره بلوک را در نظر بگیرد.
• مجموع حد گاز تمام معاملات نباید از حد گاز بلوک تجاوز کند.
• تراکنش های بلوک باید در برابر txs-root با محاسبه و مقایسه هش merkle trie لیست تراکنش ها تأیید شوند.
• لیست Ommers ممکن است حداکثر دارای دو سرصفحه باشد.
• keccak256 (ommers) باید با ommers-hash سربرگ بلوک مطابقت داشته باشد.
• سرصفحه های موجود در لیست ommers باید سرصفحه های معتبر باشند. تعداد بلوک آنها نباید بیشتر از بلوکی باشد که در آن گنجانده شده است. هش والد یک هدر ommer باید به اجدادی با عمق 7 یا کمتر از بلوک شامل آن اشاره داشته باشد و نباید در بلوک قبلی گنجانده شده باشد. موجود در این مجموعه اجدادی

رمزگذاری و اعتبار رسید

رسیدها خروجی انتقال حالت EVM یک بلوک هستند. مانند تراکنش ها، رسیدها دارای دو رمزگذاری مجزا هستند و ما به کدگذاری با استفاده از شناسه رسیدₙ اشاره خواهیم کرد.

بدون تایپ، رسیدهای قدیمی به صورت زیر کدگذاری می شوند:

رسیدهای تایپ شده EIP-2718 به عنوان آرایه های بایت RLP کدگذاری می شوند که در آن بایت اول نوع رسید را نشان می دهد (مطابق با نوع tx) و بایت های باقی مانده داده های غیرشفاف خاص برای نوع هستند.

در پروتکل سیم اتریوم، رسیدها همیشه به عنوان لیست کامل تمام رسیدهای موجود در یک بلوک منتقل می شوند. همچنین فرض بر این است که بلوک حاوی رسیدها معتبر و شناخته شده است. هنگامی که لیستی از رسیدهای بلوک توسط یک همتا دریافت می شود، باید با محاسبه و مقایسه هش merkle trie لیست با ریشه رسیدهای بلوک تأیید شود. از آنجایی که فهرست معتبر دریافت ها توسط انتقال حالت EVM تعیین می شود، نیازی به تعریف قوانین اعتبار بیشتر برای دریافت ها در این مشخصات نیست.

در اکثر پیام ها، اولین عنصر لیست داده پیام، شناسه درخواست است. برای درخواست ها، این یک مقدار صحیح 64 بیتی است که توسط همتای درخواست کننده انتخاب شده است. همتای پاسخ دهنده باید مقدار را در عنصر request-id پیام پاسخ منعکس کند.

[نسخه: P، شبکه: P، td: P، blockhash: B_32، پیدایش: B_32، forkid]

به یک همتا از وضعیت فعلی آن اطلاع دهید. این پیام باید درست پس از برقراری ارتباط و قبل از هر پیام پروتکل دیگر ارسال شود.

• نسخه: نسخه پروتکل فعلی
• networkid: عدد صحیح شناسایی بلاک چین، جدول زیر را ببینید
• td: سختی کل بهترین زنجیره. عدد صحیح، همانطور که در هدر بلوک یافت می شود.
• blockhash: هش بهترین (یعنی بالاترین TD) بلوک شناخته شده
• پیدایش: هش بلوک پیدایش
• forkid : یک شناسه فورک EIP-2124 که به صورت [fork-hash, fork-next] کدگذاری شده است.

این جدول شناسه های رایج شبکه و شبکه های مربوط به آنها را فهرست می کند. شناسه های دیگری وجود دارند که در فهرست نیستند، یعنی کلاینت ها نباید نیاز به استفاده از شناسه شبکه خاصی داشته باشند. توجه داشته باشید که شناسه شبکه ممکن است با شناسه زنجیره ای EIP-155 که برای جلوگیری از پخش مجدد تراکنش استفاده می شود مطابقت داشته باشد یا نباشد.

برای فهرست انتخاب شده توسط انجمن از شناسه های زنجیره، به https://chainid.network مراجعه کنید.

[[blockhash1: B_32، number1: P]، [blockhash2: B_32، number2: P]، .]

یک یا چند بلوک جدید را که در شبکه ظاهر شده اند مشخص کنید. برای اینکه حداکثر مفید باشند ، گره ها باید از همه بلوک هایی که ممکن است از آنها آگاه نباشند ، به همسالان اطلاع دهند. از جمله هشداری که همسالان ارسال کننده می توانند به طور منطقی بدانند (به دلیل این واقعیت که قبلاً از آنها مطلع شده بودند ، زیرا این گره خود دانش خود را از هش ها از طریق Newblockhashes تبلیغ کرده است) شکل بدی در نظر گرفته می شود و ممکن است باعث کاهش اعتبار گره ارسال شود. از جمله هشداری که بعداً گره ارسال کننده از افتخار با پیام GetBlockeHeaders امتناع می ورزد ، شکل بدی در نظر گرفته می شود و ممکن است اعتبار گره ارسال را کاهش دهد.

معاملات را مشخص کنید که همکار باید مطمئن شود که در صف معاملات آن گنجانده شده است. موارد موجود در این لیست معاملات در قالب شرح داده شده در مشخصات اصلی اتریوم است. پیام های معاملات باید حداقل یک معامله (جدید) داشته باشند ، پیام های معاملات خالی دلسرد می شوند و ممکن است منجر به قطع ارتباط شوند.

گره ها نباید در همان جلسه همان معامله را به یک همکار ارسال کنند و نباید معاملات را به همسایه ای که از آن معامله دریافت کرده اند ، انتقال دهند. در عمل این اغلب با نگه داشتن یک فیلتر شکوفه در هر یک یا مجموعه ای از هشدهای معامله ای که قبلاً ارسال شده یا دریافت شده است ، اجرا می شود.

[درخواست-ID: P ، [StartBlock :، Limit: P ، Skip: P ، Reverse:]]

برای بازگشت پیام Blockheaders به همسالان نیاز دارید. پاسخ باید حاوی تعدادی از هدرهای بلوک باشد ، از تعداد در حال افزایش در هنگام معکوس 0 ، در حالی که 1 در حال سقوط است ، از هم جدا می شود ، از شروع بلوک جدا می شود ، در شروع بلوک شروع می شود (با استفاده از هر یک از شماره یا هش) در زنجیره متعارف و با حداکثر موارد محدود.

[درخواست-ID: P ، [header₁ ، header₂ ،.]]

این پاسخ به GetBlockHeaders است که حاوی هدرهای درخواستی است. اگر هیچ یک از هدرهای بلوک درخواست شده پیدا نشد ، ممکن است لیست هدر خالی باشد. تعداد هدرهایی که می توانند در یک پیام واحد درخواست شوند ممکن است در معرض محدودیت های تعریف شده باشد.

حد نرم توصیه شده برای پاسخ های بلاک ها 2 MIB است.

[درخواست-ID: P ، [Blockhash₁: B_32 ، Blockhash₂: B_32 ،.]]

این پیام درخواست می کند داده های بدن را توسط هش مسدود کند. تعداد بلوک هایی که می توان در یک پیام واحد درخواست کرد ممکن است در معرض محدودیت های تعریف شده باشد.

[درخواست-ID: P ، [Block-Body₁ ، Block-Body₂ ،.]]

این پاسخ به GetBlockBodies است. موارد موجود در لیست شامل داده های بدنه بلوک های درخواستی است. اگر هیچ یک از بلوک های درخواستی در دسترس نبود ، ممکن است این لیست خالی باشد.

حد نرم توصیه شده برای پاسخهای blockbodies 2 MIB است.

یک بلوک کامل را مشخص کنید که همکار باید در مورد آن آگاهی داشته باشد. TD دشواری کل بلوک است ، یعنی مجموع تمام مشکلات بلوک تا و از جمله این بلوک.

[txhash₁: b_32 ، txhash₂: b_32 ،.]

این پیام یک یا چند معاملات را که در شبکه ظاهر شده اند اعلام می کند و هنوز در یک بلوک گنجانده نشده است. برای اینکه حداکثر مفید باشند ، گره ها باید از همه معاملات که ممکن است از آنها آگاه نباشند ، به همسالان اطلاع دهند.

حد نرم توصیه شده برای این پیام 4096 هش (128 KIB) است.

گره ها فقط باید هش از معاملات را اعلام کنند که همسالان از راه دور می توانند به طور منطقی بدانند که نمی داند ، اما بهتر است معاملات بیشتری را برگردانید تا اینکه یک شکاف غیرقانونی در استخر داشته باشد.

[درخواست-ID: P ، [TXHASH₁: B_32 ، TXHASH₂: B_32 ،.]]

این پیام معاملات را از استخر معامله گیرنده توسط هش درخواست می کند.

حد نرم توصیه شده برای درخواست های getPooledTransactions 256 هش (8 کیب) است. گیرنده ممکن است محدودیت دلخواه را در پاسخ (اندازه یا زمان خدمت) اعمال کند ، که نباید نقض پروتکل در نظر گرفته شود.

[درخواست-ID: P ، [TX₁ ، TX₂.]]

این پاسخ به GetPooledTransactions است و معاملات درخواست شده را از استخر محلی باز می گرداند. موارد موجود در این لیست معاملات در قالب شرح داده شده در مشخصات اصلی اتریوم است.

معاملات باید به همان ترتیب در درخواست باشد ، اما از معاملات موجود در دسترس نیست. به این ترتیب ، در صورت دستیابی به حد اندازه پاسخ ، درخواست کنندگان می دانند که کدام یک از آنها را درخواست می کنند (همه چیز از آخرین معامله برگشتی شروع می شود) و کدام یک را در دسترس نیست (همه شکاف ها قبل از آخرین معامله برگشتی).

اعلام می شود ابتدا یک معامله را از طریق NewPooledTransactionHashes اعلام کنید ، اما پس از آن امتناع از خدمت به آن از طریق جمع آوری شده است. این وضعیت می تواند ایجاد شود که معامله در یک بلوک (و از استخر خارج شود) در بین اعلام و درخواست.

یک همکار ممکن است با لیست خالی پاسخ دهد اگر هیچ یک از معاملات مطابقت هش در استخر خود وجود ندارد.

[درخواست-ID: P ، [Blockhash₁: B_32 ، Blockhash₂: B_32 ،.]]

به همسالان نیاز دارید تا پیام رسیدهای حاوی رسید هش های بلوک داده شده را برگرداند. تعداد رسیدهایی که می توان در یک پیام واحد درخواست کرد ممکن است در معرض محدودیت های تعریف شده باشد.

[درخواست-ID: P ، [[رسید ، دریافت] ،.]]

این پاسخ به GetReceipts است ، و دریافت های بلوک درخواست شده را ارائه می دهد. هر عنصر در لیست پاسخ با یک هش بلوک درخواست GetReceipts مطابقت دارد و باید شامل لیست کاملی از رسیدهای بلوک باشد.

حد نرم توصیه شده برای پاسخهای رسیدها 2 MIB است.

نسخه 67 پیام های GetNodedata و Nodedata را حذف کرد.

• getNodedata (0x0d) [درخواست_id: p ، [hash_0: b_32 ، hash_1: b_32 ،.]]
• Nodedata (0x0E) [Request_ID: P ، [Value_0: B ، Value_1: B ،.]]

ETH/65 با معاملات تایپ شده (EIP-2976 ، آوریل 2021)

هنگامی که معاملات تایپ شده توسط EIP-2718 معرفی شد ، مجریان مشتری تصمیم گرفتند بدون افزایش نسخه پروتکل ، قالب های جدید معامله و دریافت را در پروتکل سیم بپذیرند. این به روزرسانی مشخصات همچنین به جای مراجعه به کاغذ زرد ، تعاریف را برای رمزگذاری کلیه اشیاء اجماع اضافه می کند.

نسخه 65 مبادله معاملات بهبود یافته ، معرفی سه پیام اضافی: NewPooledTransactionHashes ، getPooledTransactions و PooledTransactions.

قبل از نسخه 65 ، همسالان همیشه اشیاء معامله ای کامل را رد و بدل می کردند. با افزایش فعالیت و اندازه معاملات در Ethereum Mainnet ، پهنای باند شبکه مورد استفاده برای مبادله معاملات به یک بار قابل توجه برای اپراتورهای گره تبدیل شد. این بروزرسانی با اتخاذ یک سیستم پخش معاملات دو لایه مشابه با انتشار بلوک ، پهنای باند مورد نیاز را کاهش داد.

نسخه 64 پیام وضعیت را تغییر داد تا Forkid EIP-2124 را شامل شود. این به همسالان اجازه می دهد تا سازگاری متقابل قوانین اجرای زنجیره ای را بدون همگام سازی blockchain تعیین کنند.

نسخه 63 پیام های GetNodedata ، Nodedata ، GetReceipts و رسیدها را اضافه کرد که امکان همگام سازی نتایج اجرای معامله را فراهم می کند.

در نسخه 62 ، پیام Newblockhashes گسترش یافت تا شماره های بلوک را در کنار هش های اعلام شده شامل شود. تعداد بلوک در وضعیت حذف شد. پیام های GetBlockHashes (0x03) ، Blockhashes (0x04) ، GetBlocks (0x05) و بلوک (0x06) با پیامهایی جایگزین شدند که هدرها و بدنهای بلوک را واکشی می کنند. پیام blockhashesfromnumber (0x08) حذف شد.

رمزگذاری های قبلی کدهای پیام مجدد/حذف شده عبارت بودند از:

• GetBlockHashes (0x03): [هش: B_32 ، حداکثر بلوک ها: P]
• Blockhashes (0x04): [Hash₁: B_32 ، Hash₂: B_32 ،.]
• GetBlocks (0x05): [Hash₁: B_32 ، Hash₂: B_32 ،.]
• بلوک ها (0x06): [[هدر ، معاملات ، ommers] ،.]
• blockhashesfromnumber (0x08): [شماره: P ، Max-Blocks: P]

نسخه 61 پیام blockhashesfromnumber (0x08) را اضافه کرد که می تواند برای درخواست بلوک به ترتیب صعودی استفاده شود. همچنین آخرین شماره بلوک را به پیام وضعیت اضافه کرد.

ETH/60 و پایین

شماره نسخه زیر 60 در مرحله توسعه Ethereum POC استفاده شد.