July 17, 2021

Available on

YouTube
Spotify
Apple Podcasts
SoundCloud
Google Podcasts
Anchor
CastBox

شیر یا خط فصل پنجم - قسمت اول

فرایند به‌روز‌رسانی پروتکل اتریوم

فصل پنجم پادکست «شیر یا خط» را در جولای ۲۰۲۱ و پس از حدود یک سال وقفه دوباره آغاز کردیم و این فصل را به‌طور کامل روی اتریوم متمرکز می‌کنیم؛ نه صرفاً به‌خاطر کوین اتریوم، بلکه به‌خاطر فرایندها و پروسه‌هایی که پیرامون آن شکل گرفته و این‌که بیشترین تعداد توسعه‌دهنده روی این تکنولوژی کار می‌کنند. در این قسمت اول سراغ یک پرسش پایه‌ای می‌رویم: اصلاً تغییرات روی اتریوم چگونه انجام می‌شود و چطور می‌توان در یک نرم‌افزار غیرمتمرکز، تغییری را به منصفانه‌ترین شکل ممکن از ایده تا اجرا رساند؟

🇬🇧 English Summary

The «شیر یا خط» (Shir Ya Khat) podcast opens its fifth season (July 2021) with a deep dive into how protocol changes are proposed, debated, and shipped on Ethereum through EIPs (Ethereum Improvement Proposals), tracing the lineage of open-source governance from the IETF’s RFC process and Python’s PEP to Bitcoin’s BIP before landing on Ethereum’s EIP-1 (originated by Amir Taaki and adapted by Martin Becze and Hudson Jameson). The hosts break down the EIP taxonomy—Meta EIPs (like EIP-1 itself), Informational EIPs (e.g., the Smart Contract Weakness Classification), and Standards Track EIPs, which split into Core (EVM logic changes requiring consensus), Networking (peer/mining layers, Swarm, Whisper), Interface (client RPC/APIs), and ERCs (application-layer standards such as the token standard ERC-20 with name, symbol, decimals, balanceOf, transfer, and allowance)—and stress the addition of mandatory security considerations, illustrated by battles to amend the process and by outsourced security audits (e.g., for EIP-7074 and EIP-1559, reviewed by firms like PeckShield). It walks the full workflow—champion, EIP editors (and the Ethereum Cat Herders), draft, last call, final, plus states like stagnant, withdrawn, and living—through the All Core Devs (ACD) calls, Ethereum Magicians, EthResearch, and the ethereum/pm GitHub repo, up to EIP-centric hard forks tested on devnets, testnets (Ropsten, Rinkeby), and mainnet, with the client implementations (Geth’s ~85% dominance, OpenEthereum/Parity, Nethermind, Besu, Erigon) effectively casting the votes. The episode contextualizes the upcoming London fork and EIP-1559 fee-burn changes, the difficulty bomb that pressures nodes toward the Proof-of-Work to Proof-of-Stake transition, and Ethereum’s reliance on off-chain governance rather than on-chain voting or Bitcoin-style user-activated soft forks. Throughout, the hosts weigh the trade-offs of decentralized decision-making—slower, harder change versus the early-days speed once wielded by Vitalik Buterin and Gavin Wood—and touch on developer culture terms like “YOLO” testnets and “test in production.”

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

بحث را از این نقطه شروع می‌کنیم که «تغییر» مفهومی است که در دنیای بیرون از بلاکچین هم زیاد با آن سروکار داریم. در یک شرکت عادی صاحبان سهام (شیرهولدرها) و بورد مدیریتی تصمیم‌گیرنده‌اند و چون مالکیت مشخص است، روند تغییر استریکت‌تر و روشن‌تر است؛ اما با جنبش متن‌باز (open source) با کانسپت تازه‌ای روبه‌رو شدیم: تکه‌کدهایی که صاحب مشخصی ندارند ولی قرار است در طول زمان تغییر کنند. برای همین به راهی نیاز بود که این تغییرات به سورس اصلی برگردد. در این اپیزود این تاریخچه را دنبال می‌کنیم: از IETF که در حدود سال ۱۹۸۶ شکل گرفت و مدل RFC یا Request for Comment را به‌عنوان روش استانداردسازی پروتکل‌های اینترنت مطرح کرد، تا PEP یا Python Enhancement Proposal که همین روند را برای زبان پایتون پیاده کرد، و سپس BIP یا Bitcoin Improvement Proposal که در واقع کپی‌ای از مدل پایتون بود.

سپس به خود اتریوم می‌رسیم و توضیح می‌دهیم که EIP یا Ethereum Improvement Proposal (و ERC یا Ethereum Request for Comment) چیست و چرا لازم است؛ چون هر نرم‌افزاری نیاز به تغییر و آپدیت دارد و اتریوم از روز اول یک رودمپ برای فورک‌ها و آپدیت‌های دوره‌ای تعریف کرد. درباره‌ی EIP-1 صحبت می‌کنیم که خودش یک EIP از نوع Meta و در حالت Living است و مانند یک چارچوب یا «انجیل» برای بقیه‌ی EIPها عمل می‌کند؛ این‌که چه کسانی آن را نوشتند، یک EIP برای پذیرش اولیه باید چه مینیمم‌هایی داشته باشد، و چگونه ملاحظات امنیتی (Security Consideration) که در بیت‌کوین و ابتدای اتریوم وجود نداشت، پس از حدود دو سال تلاش و ارائه‌ها به EIP-1 اضافه شد.

در ادامه انواع EIP، روند حرکت یک EIP از ایده تا Final، بازیگران اصلی این فرایند، جلسات توسعه‌دهندگان هسته یا All Core Devs، کلاینت‌های مختلف اتریوم، گروه Cat Herders و در نهایت پروسه‌ی پیچیده و سنگین هاردفورک‌های اتریوم را بررسی می‌کنیم و این پرسش را می‌کاویم که آیا تصمیم‌گیری در اتریوم متمرکز است و چرا این مدل برای پروتکلی که نیاز به تغییرات سریع دارد لازم است.

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

چرا به روند تغییرات نیاز داریم و ریشه‌های آن

  • در شرکت‌های عادی صاحبان سهام و بورد مدیریتی تصمیم می‌گیرند، اما پروژه‌های متن‌باز صاحب مشخصی ندارند و برای بازگرداندن تغییرات به سورس اصلی به یک روند نیاز دارند.
  • IETF حدود سال ۱۹۸۶ شکل گرفت تا مهندسان و قانون‌گذاران درباره‌ی نحوه‌ی پیاده‌سازی پروتکل‌های اینترنت مانند TCP/IP و DNS تصمیم بگیرند؛ روش کار آن‌ها RFC یا Request for Comment بود.
  • PEP (Python Enhancement Proposal) همین روند را برای زبان پایتون پیاده کرد و BIP (Bitcoin Improvement Proposal) کپی‌ای از مدل پایتون بود؛ در همین انتقال بخش Security Consideration که پایتون داشت حذف شد.

EIP-1 و ساختار یک EIP

  • اولین مسیر برای تغییرات اتریوم را مارتین بکس و سپس هادسون جیمسون با فورک از BIP-1 گذاشتند و EIP-1 را نوشتند.
  • EIP-1 توضیح می‌دهد یک ایده چگونه پروپوز می‌شود، انواع EIP چیست، پروسه از کجا شروع و به کجا ختم می‌شود و یک EIP برای پذیرش اولیه چه مینیمم‌هایی (فرمت، تست کیس، Formal Specification، Implementation و Security Consideration) باید داشته باشد.
  • ملاحظات امنیتی یا Security Consideration یعنی بررسی این‌که تغییرِ اضافه‌شده چه سناریوهای ناخواسته‌ای (مثل آندرفلو/آورفلو یا تأثیر روی ماینینگ و شبکه) می‌تواند ایجاد کند؛ این بخش پس از ارائه‌ها و تأییدهای پی‌درپی طی حدود دو سال و در جلسات All Core Devs به EIP-1 اضافه شد.

انواع EIP

  • Standard Track: تغییرات سنگین که به چهار دسته تقسیم می‌شوند: Core (تغییر لاجیک EVM و کدبیس، نیازمند اجماع/کانسنسس و چالشی‌ترین نوع)، Networking (سطح شبکه و ارتباط ماینرها)، Interface (مثل API/RPC کلاینت‌ها) و ERC (سطح اپلیکیشن).
  • Meta EIP: تغییرات روندی که به خود اتریوم مربوط نیست، مثل خود EIP-1.
  • Informational EIP: حالت اطلاع‌رسانی و کم‌اهمیت‌تر، مثل Smart Contract Weakness Classification که قابل ایگنور کردن است.
  • در بیت‌کوین BIP-123 نیز تغییرات را به همین چهار دسته تقسیم کرده بود.

ERC و استاندارد ERC20

  • ERCها در سطح اپلیکیشن هستند و به لاجیک اتریوم کاری ندارند؛ استانداردهایی برای نوشتن قرارداد هوشمند تعیین می‌کنند.
  • ERC20 (یا EIP20) استاندارد توکن است و مشخص می‌کند یک توکن چه آپشن‌هایی مثل نام، سیمبول، تعداد ارقام اعشار، بالانس و ترنسفر باید داشته باشد تا ولت‌ها و قراردادهای دیگر بتوانند با آن کار کنند؛ ویتالیک یکی از نویسندگان آن بود و همین استاندارد راه را برای ICOها و توکن‌سازی باز کرد.

روند و بازیگران یک EIP (به‌جز Core)

  • سه بازیگر اصلی: EIP Champion (صاحب و مسئول جلو بردن ایده)، ویرایشگران یا EIP Editors و متخصصان فنی یا Core Developers.
  • ایده ابتدا در جاهایی مثل Ethereum Magicians، سابردیت اتریوم، ethresear.ch یا issueهای گیت‌هاب مطرح و بحث می‌شود، پیش از آن‌که به EIP تبدیل شود.
  • EIP Editorها حق قضاوت (Judge) ندارند؛ فقط منطقی بودن و مطابقت فرمت را چک می‌کنند و یک EIP Number اختصاص می‌دهند و پول‌ریکوئست را مرج می‌کنند.
  • مراحل: Idea ← Draft ← Last Call (یک تایم‌ویندوی معمولاً چهارده‌روزه) ← Final. حالت‌های دیگر: Stagnant (شش ماه بدون پیشرفت)، Withdrawn (ریجکت) و Living (همیشه قابل تغییر، مثل EIP-1). فقط EIPهای Final در فولدر ریپوی گیت‌هاب قرار می‌گیرند.
  • گروه EIPIP یا EIP Improvement Process هر دو هفته یک‌بار جلسه دارد و فقط درباره‌ی بهبود خودِ روند EIPها بحث می‌کند.

جلسات هسته و کلاینت‌ها

  • جلسات All Core Devs (ACD) هر دو هفته یک‌بار برگزار و به‌صورت پابلیک در یوتیوب پخش می‌شود؛ توسعه‌دهندگان اصلی، اعضای اتریوم فاوندیشن، ریسرچرها و کامیونیتی حضور دارند و هر کلاینت اصلی باید حداقل یک نماینده داشته باشد چون رأی‌گیری اصلی روی کلاینت‌ها انجام می‌شود.
  • پنج کلاینت اصلی اتریوم: Geth (با زبان Go و پرکاربردترین)، OpenEthereum (سابقاً Parity)، Nethermind، Besu و Erigon؛ برنامه‌ریزی جلسات در ریپوی ethereum/pm انجام می‌شود.

پروسه‌ی Core EIP و هاردفورک

  • گروه Cat Herders را هادسون جیمسون اوایل ۲۰۱۹ راه‌اندازی کرد تا هماهنگی و مدیریت هاردفورک‌ها و ارتباط با زیرساخت‌ها (اکسچنج‌ها، ولت‌ها، ماینرها و سرویس‌هایی مثل اینفورا و آلکمی) را برعهده بگیرد؛ اکنون تیم بیکو آن را منیج می‌کند.
  • پروسه‌ی یک Core EIP: بحث و Draft ← اکسپت اولیه در یک ACD Call ← Implementation اولیه برای راضی کردن کلاینت‌ها ← نوشتن Test Case و Security Review (که گاهی مثل EIP-3074 و EIP-1559 آوت‌سورس می‌شود) ← تست روی Dev Net (اولین آن YOLO بود؛ شبکه‌ای با تعداد کمی نود که برای دیپلوی نیست) ← تست روی تست‌نت‌ها مثل Ropsten و Rinkeby با بلاک‌نامبر مشخص ← در نهایت تعیین بلاک‌نامبر روی مین‌نت.
  • شرط اصلی برای قبول شدن یک Core EIP و انجام هاردفورک این است که حداقل سه کلاینت مختلف اتریوم آن تغییر را پیاده‌سازی کنند؛ در غیر این‌صورت ریجکت می‌شود.
  • تاریخچه: در ۲۰۱۵ و اوایل ۲۰۱۶ تعداد کمی توسعه‌دهنده (و در اصل ویتالیک و گوین وود) تصمیم می‌گرفتند؛ سپس با ایده‌ی هاردفورک هر شش ماه یک‌بار در ۲۰۱۹ و بعد مدل EIP-Centric Hard Fork، روند تکامل یافت.

دیفیکالتی بامب و تمرکز در تصمیم‌گیری

  • اتریوم آن‌چین گاورننس ندارد و سیگنالینگ آف‌چین است؛ تصمیم اصلی جایی است که کلاینت‌ها ایمپلیمنت را می‌پذیرند و بعد ماینرها آپدیت می‌کنند، و در هر مرحله امکان فورک وجود دارد که پروسه‌ای سنگین است.
  • Difficulty Bomb با هدف عقب انداختن ماینینگ و سوئیچ از Proof of Work به Proof of Stake در هر آپدیت عقب انداخته می‌شود؛ ایده‌ی «تصمیم‌گیری با عدم عمل» (deciding by no action) نودها را مجبور می‌کند تصمیم بگیرند و آپدیت کنند.
  • استدلال می‌شود چون اتریوم نیاز به تغییرات سریع و زیاد (مثل مسیر اتریوم ۲) دارد و نمی‌تواند مثل بیت‌کوین سال‌ها منتظر بماند، نمی‌تواند کاملاً غیرمتمرکز باشد؛ ویتالیک تصمیم‌گیری را به تیمی از متخصصان واگذار کرد تا یک دوران گذار به سیستم غیرمتمرکزتر طی شود.
  • فشار روی ماینرها فقط از سمت کامیونیتی نیست: چون کاربران و دپ‌ها (مثلاً تتر که فقط یک زنجیره را ساپورت می‌کند) انتخاب می‌کنند تراکنش‌ها را کجا بفرستند، ماینر به‌تنهایی نمی‌تواند تصمیم بگیرد؛ نمونه‌ی ProgPoW فورکی بود که تا مرحله‌ی آخر آمد ولی ماینرها قبولش نکردند.

نتیجه‌گیری

فرایند به‌روزرسانی اتریوم ترکیبی از میراث RFC و PEP و BIP است که در قالب EIP و EIP-1 نهادینه شده و از ایده تا Final و در نمونه‌ی سنگین Core EIP تا هاردفورک، لایه‌های متعددی از بحث، تست، ملاحظات امنیتی و اجماع کلاینت‌ها را طی می‌کند. این مدل نه کاملاً متمرکز است و نه کاملاً غیرمتمرکز؛ انتخابی آگاهانه است بین سرعت تغییر و غیرمتمرکز بودن، تا شبکه‌ای که ارزش و پروژه‌های زیادی به آن وابسته‌اند بتواند با اطمینان و در عین حال با مشارکت گسترده تکامل پیدا کند. در اپیزودهای بعدی به‌طور خاص سراغ EIPهای مهم مانند EIP-1559 خواهیم رفت.

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

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

  • EIP-1559 و فورک لندن — ادامه مستقیم همین قسمت؛ در متن بارها به EIP-1559 و فورک لندن به‌عنوان نمونه‌ی کور EIP اشاره شد.
  • هاردفورک دنکون — نمونه‌ی عملی همان فرایند کور EIP و هاردفورک اتریوم که اینجا توضیح داده شد.
  • هاردفورک پکترا — کاربرد واقعی روند EIP و هاردفورک محور در به‌روزرسانی پروتکل اتریوم.
  • فورک بیت‌کوین و سگویت/BIP148 — بحث BIP و گاورننس آفچین و یوزر-اکتیویتد سافت‌فورک که در این قسمت با روند اتریوم مقایسه شد.
  • چه فورکی، انشعابات بیت‌کوین — ریشه‌ی فورک در دنیای اوپن‌سورس و مدل BIP بیت‌کوین که مبنای EIP اتریوم است.
  • اتریوم — معرفی پایه‌ی اتریوم و EVM که پیش‌نیاز درک تغییرات کور EIP روی این پروتکل است.
Share: