March 02, 2025

Available on

YouTube
Spotify
Apple Podcasts
CastBox

شیر یا خط

فصل هفتم - قسمت پنجم

Ethereum Pectra Upgrade (S07E05) ارتقای هاردفورک پکترا و تغییرات جدید در اتریوم

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

🇬🇧 English Summary

This episode of the شیر یا خط (Shir Ya Khat) podcast, featuring guests Sina and Hamid, offers a technical deep-dive into Ethereum’s upcoming Pectra hard fork (a name blending the consensus-layer “Electra” and execution-layer “Prague” upgrades), expected to launch on mainnet within a month or two after debuting on the Holešky testnet. The hosts trace Ethereum’s governance and update process through EIPs (Ethereum Improvement Proposals), the roadmap coordinated by Vitalik Buterin, and the history of prior hard forks like the Merge and Dencun, before unpacking Pectra’s roughly ten to eleven EIPs. A central focus is account abstraction via EIP-7702, which lets a standard EOA be temporarily upgraded into a smart-contract wallet (enabling batching, session keys, alternate signers, and gas sponsorship) — contextualized against earlier approaches including sponsored transactions, permit tokens, EIP-3074, and the application-layer ERC-4337 with its bundlers, paymasters, and user operations, plus native account abstraction on L2s like zkSync. The discussion then covers blob scaling for Layer 2 rollups, explaining EIP-7691’s increase of the blob target and max from 3/6 to 6/9, KZG commitments, data availability sampling and the future PeerDAS, the Get Blobs Engine API optimization, and calldata repricing via EIP-7623 to protect solo stakers and decentralization. Finally, the episode examines staking-related changes, including EIP-7251 raising the validator max effective balance from 32 to 2048 ETH to reduce network load, and EIP-7002/EIP-7685 enabling execution-layer-triggered validator exits and improved consensus–execution layer communication through withdrawal-address requests. Throughout, the hosts emphasize Ethereum’s pattern of planting long-term infrastructure (Verkle tree prep via EIP-2335, KZG foresight) for future harvest while balancing immediate Layer 2 demand for cheaper, higher-throughput transactions.

توضیحات اپیزود

گفتگو با یک مرور بر فرایند گاورننس اتریوم آغاز می‌شود؛ اینکه چطور شبکه از طریق EIPها (Ethereum Improvement Proposals) به‌روزرسانی می‌شود و چرا هر هاردفورک به‌طور میانگین حدود نه ماه تا یک سال طول می‌کشد تا از مرحله‌ی دِوِلوپمنت به مین‌نت برسد. مجری‌ها توضیح می‌دهند که نام پکترا از ترکیب پراگ (Prague) در لایه اجرایی و الکترا (Electra) در لایه اجماع ساخته شده و درست یک سال پس از هاردفورک دنکون در حال آماده شدن است. نکته‌ی مهمی که تأکید می‌شود این است که رودمپ اتریوم را ویتالیک به‌تنهایی دیکته نمی‌کند؛ او بیشتر نقش یک هماهنگ‌کننده (coordinator) را دارد که ایده‌های تیم‌های تحقیقاتی پراکنده در اکوسیستم را جمع‌آوری و فرمولایز می‌کند، و بسیاری از آیتم‌های رودمپ ممکن است هیچ‌وقت به همان شکل اجرا نشوند یا با آلترنتیوهای بهتر جایگزین شوند.

بخش بزرگی از اپیزود به اکانت ابسترکشن اختصاص دارد. سینا مسیر تاریخی این ایده را از اسپانسر ترنزکشن‌ها و استاندارد پرمیت توکن‌ها تا EIP-4337 روایت می‌کند؛ استانداردی که در لایه اپلیکیشن و با مجموعه‌ای از قراردادهای هوشمند، باندلر و پیمستر کار می‌کرد اما به دلایلی مثل پیچیدگی آنبوردینگ و متفاوت بودن آدرس روی هر چین، آنطور که باید ادابت نشد (مگر در نمونه‌هایی مثل پولی‌مارکت). سپس نوبت به ستاره‌ی این آپگرید می‌رسد: EIP-7702 که به کاربران اجازه می‌دهد همان اکانت معمولی (EOA) خود را با یک امضا به یک کیف‌پول هوشمند ارتقا دهند، بدون اینکه آدرس یا دارایی‌شان تغییر کند. مزایایی مثل batching، افزودن signerهای اضافه، session key و امکان اعمال محدودیت روی تراکنش‌های ورودی از جمله کاربردهایی است که بحث می‌شود؛ همچنین تفاوت آن با EIP-3074 که نیازمند آپ‌کد جدید و بررسی‌های امنیتی سنگین بود، و ماجرای جالب نگارش EIP-7702 توسط ویتالیک تنها در بیست دقیقه.

در ادامه، تیم‌های بزرگ بحث یعنی بلاب‌ها و استیکینگ واکاوی می‌شوند. سینا توضیح می‌دهد که بلاب‌ها بخشی از استراتژی بلندمدت اسکیلینگ اتریوم از طریق لایه دوها هستند و چطور جایگزین کال‌دیتای گران و دائمی شدند. سپس به سراغ EIPهای استیکینگ، پیش‌کامپایل‌های کریپتوگرافیک، امضای جمعی BLS و در نهایت چالش واقعی و داغ همان روزها — یعنی فورک شدن تست‌نت هولسکی به دلیل یک باگ کانفیگریشن در آدرس دیپازیت کانترکت — می‌رویم که در لحظه‌ی ضبط هنوز فاینالایز نشده بود.

نکات اصلی بحث‌شده

پکترا و فرایند رسیدن به آن

  • نام پکترا از ترکیب پراگ (لایه اجرایی) و الکترا (لایه اجماع) ساخته شده و هاردفورک بعدی احتمالاً فوساکا (فولو + اوساکا) خواهد بود.
  • هر هاردفورک به‌طور میانگین نه ماه تا یک سال طول می‌کشد؛ بحث پکترا از نومبر ۲۰۲۳ و پیش از لانچ دنکون در فوروم Ethereum Magicians شروع شده بود.
  • یک ظرفیت محدود در هر آپگرید وجود دارد و از میان لیست بلندبالای EIPها بر اساس اولویت و نیازها انتخاب می‌شوند؛ برخی EIPها (مثل EOF و ورکل) در نهایت به این فورک نرسیدند.
  • ویتالیک سازنده‌ی یک‌تنه‌ی رودمپ نیست؛ او هماهنگ‌کننده‌ای است که کار تیم‌های تحقیقاتی مختلف را جمع و فرمولایز می‌کند.

اکانت ابسترکشن، EIP-7702 و EIP-4337

  • مسیر از اسپانسر ترنزکشن‌ها و پرمیت توکن‌ها (که توکن‌هایی مثل آربیتروم، آپتیمیزم، USDC و DAI دارند) شروع شد.
  • EIP-4337 اکانت ابسترکشن را در لایه اپلیکیشن و بدون نیاز به فورک پیاده کرد (با مادر کانترکت، باندلر/سکند مم‌پول و پیمستر)، اما آنبوردینگ پیچیده و آدرس متفاوت روی هر چین باعث شد کمتر ادابت شود؛ شبکه‌هایی مثل zkSync با نیتیو اکانت ابسترکشن تجربه‌ی بهتری داشتند.
  • EIP-7702 اجازه می‌دهد همان EOA با یک sign به قرارداد هوشمند ارتقا یابد؛ ایتر و آدرس کاربر حفظ می‌شود.
  • کاربردها: batching (حذف نیاز به approve و transfer جداگانه)، افزودن signer، session key، و امکان جلوگیری از تراکنش‌های ناخواسته (مثال تورنادو کش و توکن‌های اسپم).
  • در EIP-7702 یک نوع تراکنش جدید اضافه می‌شود، نه آپ‌کد جدید؛ این وکالت به قرارداد هوشمند داده می‌شود اما پرایویت‌کی همچنان قدرت نهایی را دارد و می‌تواند وکالت را ریووک کند — به همین دلیل «اکانت ابسترکشن کامل» نیست.
  • برخلاف EIP-3074 که آپ‌کد جدید و لایه‌ی سنسورشیپ‌پذیر متر ترنزکشن داشت، EIP-7702 صرفاً از آپ‌کدهای موجود استفاده می‌کند و تغییرات کوچکی در درخت داده اتریوم ایجاد می‌کند.
  • ماجرای جالب: ویتالیک ایده‌ی اولیه‌ی EIP-7702 را در یک چت تلگرامی مطرح و ۲۰ دقیقه بعد لینک EIP نوشته‌شده را ارسال کرد.
  • نگرانی امنیتی: حالا message.sender یک EOA می‌تواند قرارداد هوشمند باشد و مدل‌های جدید حملات ری‌اِنترنسی محتمل است.

بلاب‌ها و بهینه‌سازی داده‌ها

  • بلاب‌ها بخشی از استراتژی بلندمدت اسکیلینگ‌اند و جایگزین کال‌دیتای گران و دائمی برای لایه دوها شدند؛ داده‌ی بلاب فقط چند هفته (حدود سی روز) نگهداری می‌شود.
  • در دنکون هر بلاک تارگت ۳ و مکس ۶ بلاب داشت (هر بلاب ۱۲۸ کیلوبایت)؛ EIP-7691 و EIP-7840 این پارامترها را به تارگت ۶ و مکس ۹ افزایش می‌دهند.
  • به گفته‌ی ویتالیک، بسیاری از لایه دوها به دلیل کمبود ظرفیت بلاب هنوز لانچ نکرده‌اند یا از دیتا اویلیبیلیتی شبکه‌های دیگر استفاده می‌کنند.
  • بهینه‌سازی‌هایی مثل متود جدید Get Blobs در Engine API اجازه می‌دهد کلاینت اجماع بلاب موجود در کلاینت اجرایی را دوباره از شبکه دانلود نکند.
  • EIP-7623 هزینه‌ی کال‌دیتا را محدود می‌کند تا از تولید بلاک‌های عظیم (مثلاً ۷ مگابایت) جلوگیری شود؛ این EIP باید همراه با EIP-7691 بیاید تا بلاک بیش از حد بزرگ نشود. حدود ۹۹.۵٪ تراکنش‌های معمولی هیچ افزایش هزینه‌ای احساس نمی‌کنند.
  • مثال تاریخی از خطر کال‌دیتا: داون شدن سیکوئنسر آربیتروم هنگام پیاده‌سازی اینسکریپشن‌ها.
  • کیزی‌جی کامیتمنت روی بلاب‌ها آماده‌سازی برای وریفیکیشن تاریخی و در نهایت PeerDAS و دیتا اویلیبیلیتی سمپلینگ در فورک‌های بعدی است.
  • تفکیک historical data: تاریخچه‌ی خود اتریوم drop نمی‌شود، بلکه داده‌ی تاریخی لایه دوهاست که drop می‌شود، چون latest state رول‌آپ‌ها همیشه در بلاب‌های available وجود دارد.

استیکینگ و ولیدیتورها

  • EIP-7251 سقف استیک هر ولیدیتور را از ۳۲ به ۲۰۴۸ اتر افزایش می‌دهد؛ این به گروه‌های بزرگ مثل لایدو و کوین‌بیس اجازه می‌دهد ولیدیتورها را ادغام کنند و ترافیک شبکه و بار ری‌سورس را کاهش دهند بدون آنکه سنترالایزیشن بیشتر شود.
  • بالانس مازاد بالای سقف به آدرس ویدرال (که با 0x02 شروع می‌شود) سوییپ می‌شود.
  • EIP-7002 امکان درخواست خروج (exit) ولیدیتور را از طریق آدرس ویدرال و لایه اجرایی فراهم می‌کند؛ این مشکل قدیمی سرویس‌های استیکینگ و ری‌استیکینگ (فورس ویدرال و اسلش) را حل می‌کند.
  • EIP-7685 مسیر ارتباطی رکوئست از لایه اجرایی و قراردادهای هوشمند به لایه اجماع را استاندارد می‌کند؛ حالا دیپازیت‌ها هم از همین مسیر انجام می‌شوند و زمان دیپازیت از حدود ۱۳ ساعت به حدود ۱۳ دقیقه کاهش یافته است.
  • دلیل تاریخی پیاده نشدن این ارتباط از ابتدا: رودمپ قبلی شاردینگ‌سنتریک بود، اما با رول‌آپ‌سنتریک شدن رودمپ حالا می‌توان ارتباط اجرایی-اجماع را برای تنها شارد موجود بهینه کرد.

پیش‌کامپایل‌ها، BLS و امضای جمعی

  • EIP-2537 پیش‌کامپایل منحنی BLS12-381 را اضافه می‌کند که امنیت حدود ۱۲۸ بیتی (بسیار قوی‌تر از bn254 با امنیت ~۸۰ بیتی) و امکان وریفای امضاهای BLS و سیرکت‌های بزرگ‌تر ZKP را در لایه اجرایی فراهم می‌کند.
  • کاربردها: دیسنترالایزد سیکوئنسر، اوراکل‌ها و لایت‌نودهای شبکه‌هایی مثل آلت‌کوین‌هایی که از BLS استفاده می‌کنند.
  • پیش‌کامپایل‌ها قطعه کدهایی هستند که به زبان نیتیو هر کلاینت (مثل Go در گو-اتریوم) نوشته می‌شوند، آدرس EVM و هزینه‌ی fixed دارند و عملیات ریاضی سنگین را ارزان‌تر از پیاده‌سازی در EVM انجام می‌دهند؛ آلترنتیو در حال بررسی EVM-MAX است.
  • EIP-7549 با حذف کامیتی ایندکس از اتستیشن، امکان BLS Signature Aggregation را فعال می‌کند؛ به‌جای ذخیره و وریفای مثلاً ۵۰۰ امضا در هر اسلات، تنها یک امضا با یک آپریشن وریفای می‌شود که ترافیک و حجم ذخیره‌سازی شبکه را به‌شدت کاهش می‌دهد.

تاریخچه بلاک و چالش‌های آپگرید

  • EIP-2935 تاریخچه‌ی بلاک‌های روی زنجیره را از ۲۵۶ به ۸۱۹۲ بلاک افزایش می‌دهد و آماده‌سازی برای انتقال آینده به ورکل تری است.
  • تست‌نت هولسکی به دلیل یک باگ کانفیگریشن در آدرس دیپازیت کانترکت (که روی هولسکی متفاوت بود) فورک شد؛ سه کلاینت اجرایی (گو-اتریوم، ندرمایند و بسو) روی یک فورک و ریث و اریگون روی فورک دیگر رفتند و شبکه چند روز فاینالایز نشد.
  • این باگ روی لاجیک و شبکه‌های دیگر تأثیری نداشت و ارزش کلاینت دایورسیتی را نشان داد؛ بهتر است چنین مشکلاتی در تست‌نت رخ دهد تا مین‌نت.
  • در زمان ضبط، آپگرید سپولیا حدود شش روز بعد برنامه‌ریزی شده بود و تاریخ مین‌نت هنوز اعلام نشده بود و منوط به موفقیت فورک سپولیا است.

نگاه به آینده

  • هاردفورک بعدی فوساکا احتمالاً شامل PeerDAS و EOF خواهد بود؛ پیاده‌سازی‌ها در گو-اتریوم آغاز شده.
  • History Expiry یکی از تاپیک‌های بزرگ آینده است که از حدود ماه مِی به کلاینت‌ها اجازه می‌دهد تاریخچه‌ی پیش از مرج را پاک کنند و حجم دیسک مورد نیاز نودها را کاهش می‌دهد.

نتیجه‌گیری

پکترا نشان می‌دهد که توسعه‌ی اتریوم فرایندی چند ساله، تدریجی و مبتنی بر یادگیری از تجربه است؛ بسیاری از EIPهای این فورک، از EIP-7702 و بلاب‌ها تا استیکینگ و امضای جمعی، هم پاسخ به نیازهای فوری هستند و هم آماده‌سازی برای اهداف بلندمدت رودمپ. این آپگرید تعهد اتریوم به مقیاس‌پذیری، حفظ دیسنترالایزیشن (به‌ویژه برای سولو استیکرها) و توسعه‌ی پایدار را بازتاب می‌دهد. اکنون که کار روی پکترا رو به پایان است، بحث‌ها روی فوساکا آغاز شده و حکایت اتریوم همچنان باقی است.

لینک های این اپیزود:

منابع فارسی
مرجع EIPهای مربوط به آپگرید Pectra:
منابع مرتبط با بلاب‌ها و استیکینگ:

حاضران در این قسمت:

قسمت‌های مرتبط

  • هاردفورک دنکون — هاردفورک قبلی اتریوم که در همین اپیزود بارها به آن ارجاع می‌شود؛ بلاب‌ها و EIP-4844 که در پکترا گسترش می‌یابند از اینجا آمده‌اند و همین فرمت بررسی EIPها را دنبال می‌کند.
  • فرایند به‌روزرسانی و EIP اتریوم — در اپیزود صراحتاً به این قسمت (جولای ۲۰۲۱) برای درک گاورننس اتریوم و روند تعریف و تصویب EIPها ارجاع داده و شنیدنش پیشنهاد شده است.
  • EIP-1559 و ساختار فی — به‌عنوان نمونه یک EIP بنیادی که ساختار فی شبکه را تغییر داد مستقیماً نام برده می‌شود؛ مکانیزم تارگت/مکس فی که در پکترا برای بلاب‌ها به‌کار می‌رود ریشه در همین دارد.
  • مقیاس‌پذیری بلاکچین — بخش بزرگی از پکترا درباره بلاب‌ها، لایه دو، افزایش ظرفیت و رودمپ اسکیلینگ رول‌آپ‌محور اتریوم است که پیش‌زمینه‌اش در این قسمت بحث شده.
  • استیکینگ و اثبات سهام — چند EIP مهم پکترا (مثل ۷۲۵۱ و ۷۰۰۲) درباره کارایی استیکینگ، اکزیت ولیدیتور و افزایش سقف استیک است؛ این قسمت زمینه استیکینگ اتریوم را پوشش می‌دهد.
  • معرفی اتریوم — قسمت پایه‌ای درباره ساختار فنی اتریوم و مفهوم لایه اجرا و اجماع که برای درک تغییرات پروتکلی پکترا لازم است.

زمان‌بندی فصل‌ها

  • 00:00 معرفی و مقدمه
  • 03:02 تاریخچه و روند توسعه اتریوم
  • 06:00 بررسی هارد فورک‌ها و تأثیرات آن‌ها
  • 08:55 تحلیل EIPها و اولویت‌های توسعه
  • 13:09 تحلیل رودمپر و نیازهای آینده
  • 14:25 نقش ویتالیک و تیم‌های تحقیقاتی در اتریوم
  • 18:22 EIP-7702 و مفهوم Account Abstraction
  • 21:29 استانداردهای توکن و EIP-4337
  • 25:03 چالش‌ها و فرصت‌های Account Abstraction
  • 28:28 تحلیل EIP-7702 و کاربردهای آن
  • 31:53 تجربه کاربری و امنیت در EIP-7702
  • 37:36 تفاوت‌های EIP-7702 با EIP-4337
  • 40:34 جمع‌بندی و آینده EIP-7702
  • 43:28 بررسی ابسترکشن
  • 44:33 بلاب‌ها و استراتژی‌های اتریوم
  • 49:23 بهینه‌سازی و افزایش ظرفیت بلاب ها
  • 55:05 چالش‌ها و نیازهای آینده اتریوم
  • 01:00:29 تکنیک‌های بهینه‌سازی در اتریوم
  • 01:06:11 نقش بلاب‌ها در مدیریت داده‌ها و هزینه‌ها
  • 01:15:26 EIPها و تأثیرات آن‌ها بر استیکینگ
  • 01:22:42 چالش‌های استیکینگ و آینده آن
  • 01:25:55 تحلیل و بررسی EIPها و پروپوزال‌ها
  • 01:33:50 چالش‌ها و مشکلات در آپگریدها و شبکه‌ها
  • 01:41:20 تحولات جدید در ولیدیتورهای اتریوم
  • 01:43:39 پیش‌کامپایل‌ها و کاربردهای آن‌ها
  • 01:46:01 EIPها و بهبودهای شبکه اتریوم
  • 01:49:16 امضای جمعی و بهینه‌سازی‌های شبکه
  • 01:52:01 جمع‌بندی
Share: