ایتھیریم کی بنیادی گورننس کی وضاحت

ایتھیریم فاؤنڈیشن کے نکسو روکش (Nixo Rokish) کی جانب سے ETHBoulder میں ایک پریزنٹیشن، جس میں ایتھیریم کے بنیادی پروٹوکول کی گورننس، ہارڈ فورکس کو کیسے مربوط کیا جاتا ہے، ایتھیریم کو کون کنٹرول کرتا ہے اس بارے میں عام غلط فہمیوں، اور گورننس کے عمل میں حصہ لینے کے طریقہ کار کی وضاحت کی گئی ہے۔

یہ ٹرانسکرپٹ EthBoulder کی جانب سے شائع کردہ اصل ویڈیو ٹرانسکرپٹ (opens in a new tab) کی ایک قابل رسائی کاپی ہے۔ اسے پڑھنے میں آسانی کے لیے معمولی طور پر ایڈٹ کیا گیا ہے۔

تعارف (0:12)

میرے ان تمام چھ دوستوں کا شکریہ جو یہاں آئے۔ ٹھیک ہے۔ میں آج آپ سے ایتھیریم کی بنیادی گورننس کے بارے میں بات کر رہا ہوں۔ میرا نام نکسو ہے۔ میں EF (ایتھیریم فاؤنڈیشن) میں پروٹوکول سپورٹ ٹیم کی قیادت کرتا ہوں۔ ہماری تمام ذمہ داریوں میں سے ایک ذمہ داری یہ ہے کہ گورننس کے عمل کو ان تمام لوگوں کے لیے واضح اور آسان بنایا جائے جو ان چیزوں میں حصہ لیتے ہیں کیونکہ ایتھیریم میں صرف اس کے بنیادی ڈیولپرز کے علاوہ بھی بہت کچھ شامل ہے۔

تو یہاں اس گفتگو کا خاکہ ہے۔ ہم بات کریں گے کہ بنیادی گورننس کیا ہے۔ ہم غلط فہمیوں پر بات کریں گے، اور یہ کہ ایتھیریم کی گورننس فی الحال کیسے کام کرتی ہے۔ ہم اس بات پر بھی روشنی ڈالیں گے کہ اس کا دیگر لامركزی گورننس سسٹمز سے کیا موازنہ ہے، بلڈرز کو اس کی پرواہ کیوں کرنی چاہیے، اور شرکت کے لیے قابل عمل راستے کیا ہیں۔

تو، بنیادی پروٹوکول کی گورننس کیا ہے؟ میں ایک نوڈ چلاتا ہوں۔ اس کا مطلب یہ ہے کہ میرے پاس ہارڈویئر کا ایک ٹکڑا ہے، میرے گھر پر ایک کمپیوٹر ہے جہاں میں ایتھیریم سافٹ ویئر چلاتا ہوں۔ جب میں نے یہ ایتھیریم سافٹ ویئر سیٹ اپ کیا، تو مجھے ان کلائنٹس کا انتخاب کرنا تھا جو وہ سافٹ ویئر چلانے والے تھے۔ ایتھیریم اس لحاظ سے منفرد ہے کہ اس میں کلائنٹ کا تنوع کے لیے متعدد کلائنٹس ہیں۔ اس کا مقصد یہ ہے کہ اگر ایک کلائنٹ ڈاؤن ہو جائے، یا اگر کسی کلائنٹ میں کوئی بگ آ جائے، تو پورا نیٹ ورک ڈاؤن نہیں ہوتا۔ دیگر بلاک چینز بھی ہیں جن کے دوسرے کلائنٹس ہیں۔ تاہم، ایتھیریم واحد بلاک چین ہے جو اس طرح سیٹ اپ کی گئی ہے جو دراصل ہمیں بگز سے بچاتی ہے۔ لہذا، اگر آپ Solana جیسی مثال لیں، تو Solana کا ایک اور کلائنٹ ہے، میرا خیال ہے اسے GTO کہا جاتا ہے، لیکن اس کا استعمال صرف 20–21% ہے۔ لہذا، اگر اکثریتی کلائنٹ ڈاؤن ہو جاتا ہے، تو چین ڈاؤن ہو جاتی ہے۔ اور ہم نے دوسرے نیٹ ورکس کو ڈاؤن ہوتے دیکھا ہے۔ اور یہی وجہ ہے کہ ایتھیریم سب سے زیادہ لچکدار اور محفوظ بلاک چین ہے۔

تو سوال یہ پیدا ہوتا ہے کہ جب آپ کو اتنے مختلف کلائنٹس کے ساتھ ہم آہنگی کرنی ہو تو آپ ایتھیریم میں تبدیلیاں کیسے لاتے ہیں۔ سب سے پہلے ہم ہارڈ فورک اور سافٹ فورک کے درمیان فرق کریں گے۔ ایک سافٹ فورک کو اس ہم آہنگی کی ضرورت نہیں ہوتی جو ایک ہارڈ فورک کو ہوتی ہے۔ ایتھیریم بنیادی طور پر ہارڈ فورکس کے ساتھ کام کرتا ہے۔ تو ہارڈ فورک بنیادی طور پر یہ ہے کہ تمام کلائنٹس ایتھیریم کا ایک نیا ورژن بناتے ہیں اور کسی پہلے سے طے شدہ وقت پر ایتھیریم کے اس نئے ورژن کو لانچ کرنے کا فیصلہ کرتے ہیں۔ یہ اب بھی ایتھیریم ہی ہوتا ہے لیکن اس میں نئی خصوصیات ہوتی ہیں۔ اس میں مختلف خصوصیات ہوتی ہیں۔ اور میری طرح کے تمام نوڈ آپریٹرز جو گھر پر نوڈز چلا رہے ہیں یا پیشہ ور آپریٹرز کو ایتھیریم کے اس نئے ورژن کو اپنانا پڑتا ہے۔ انہیں اس نئے سافٹ ویئر کو شامل کرنے کے لیے اپنے نوڈ کو اپ گریڈ یا اپ ڈیٹ کرنا پڑتا ہے۔

تو وہ یہ کیسے فیصلہ کرتے ہیں کہ ان ہارڈ فورکس میں کون سی خصوصیات شامل ہوں گی؟ انہیں اپنا وقت اور وسائل مختص کرنے کے لیے ترجیحات پر اتفاق رائے کرنا پڑتا ہے کیونکہ ان کے پاس مختص کرنے کے لیے محدود وقت اور وسائل ہوتے ہیں۔ وہ سیکیورٹی کی خامیوں یا سیکیورٹی پیچز، اور UX (صارف کے تجربے) جیسی چیزوں کو ترجیح دیتے ہیں — اگر کوئی دوسری بلاک چین ہمارا مقابلہ کر رہی ہے، تو ہمیں ان دوسری بلاک چینز کے ساتھ مسابقتی بننے کی ضرورت ہے۔ لہذا وہ جن چیزوں پر غور کرتے ہیں ان میں سے ایک یہ ہے کہ جو بھی خصوصیت شامل کی جائے اسے ممکنہ آنے والے روڈ میپ آئٹمز کے ساتھ آگے کی طرف مطابقت (forward compatible) رکھنی چاہیے۔

تو پچھلے سال ایک بہت ہی متنازعہ چیز ہوئی تھی۔ آپ نے شاید اس کے بارے میں سنا ہو۔ اسے EOF کہا جاتا تھا۔ یہ EVM Object Format ہے۔ یہ خصوصیات کا ایک مجموعہ تھا جسے فوساکا ہارڈ فورک — پیکٹرا، فوساکا، میرا خیال ہے دونوں — میں شامل کیا جانا تھا لیکن اسے تقسیم کر دیا گیا۔ اور اسے اس فورک سے نکالے جانے کی کئی وجوہات میں سے ایک وجہ یہ تھی کہ Vitalik نے ایتھیریم کے RISC-V کو اپنانے کے امکان کے بارے میں ایک پوسٹ کی تھی۔ بہت سے لوگ جو اسے پڑھ رہے تھے انہوں نے اسے دیکھا اور سوچا، ٹھیک ہے، اگر ہم RISC-V کو اپناتے ہیں تو EOF میں ہم جن خصوصیات کو دیکھ رہے ہیں وہ RISC-V کے ساتھ قدرتی طور پر آتی ہیں۔ تو ہم پروٹوکول میں یہ پیچیدگی کیوں شامل کریں؟ ہم کلائنٹ ڈیولپرز کے یہ تمام وسائل اس چیز پر کیوں لگائیں؟ اگر ہم بالآخر RISC-V کی طرف منتقل ہو گئے تو یہ ایک بے معنی بات ہو گی۔

تو یہ EOF کے معاملے میں اونٹ کی کمر توڑنے والا آخری تنکا ثابت ہوا اور بالآخر اسے فورک سے نکال دیا گیا۔ ایک اور چیز جس پر انہیں غور کرنا پڑتا ہے وہ یہ ہے کہ اسے چھ مختلف زبانوں میں لکھا جانا اور سختی سے ٹیسٹ کیا جانا چاہیے کیونکہ یہ کلائنٹس چھ مختلف زبانوں میں لکھے گئے ہیں۔ لہذا یہ ان کے کام کرنے کے لیے ایک بہت بڑا ٹیسٹنگ میٹرکس ہے۔ اور اس کی وجہ سے ڈیزائن کے ہر چھوٹے سے انتخاب پر بحث ہوتی ہے اور اختلافات کو حل کرنے کے لیے کوئی مرکزی اتھارٹی نہیں ہوتی۔ تو اس سے یہ سوال پیدا ہوتا ہے کہ فیصلہ کون کرتا ہے — جو کہ گورننس کا اصل نچوڑ ہے۔

غلط فہمیاں (5:23)

تو یہ ہمیں غلط فہمیوں کی طرف لاتا ہے اور ہم ان میں سے کچھ پر بات کریں گے۔ ایک یہ کہ Vitalik فیصلہ کرتا ہے کہ ایتھیریم پروٹوکول میں کیا شامل ہوگا۔ اسی کی ایک توسیع یہ ہے کہ EF (ایتھیریم فاؤنڈیشن) ہر چیز کو کنٹرول کرتی ہے۔ اور تیسری یہ کہ یہ سب خفیہ سودے بازیاں ہیں — اندرونی لوگ، اور پرانے کھلاڑی (OGs) یہ فیصلے کر رہے ہیں۔

تو پہلی بات: Vitalik فیصلہ کرتا ہے۔ میں نے ابھی Vitalik کی لکھی ہوئی رکی ہوئی EIPs کا ایک حصہ چنا ہے۔ اس کا مطلب یہ ہے کہ Vitalik بیٹھا، اس نے ایک تجویز لکھی اور اس نے کہا کہ میں چاہتا ہوں کہ یہ چیزیں ایتھیریم میں شامل ہوں اور کوئی بھی متفق نہیں ہوا — یہ چیزیں بس وہیں پڑی ہیں۔ وہ انہیں پروٹوکول میں شامل کروانے کے قابل نہیں تھا۔ لہذا وہ جو بھی تجویز کرتا ہے وہ خود بخود شامل نہیں ہو جاتا۔

اس کی ایک توسیع یہ ہے کہ ایتھیریم فاؤنڈیشن ہر چیز کو کنٹرول کرتی ہے۔ میں ایک ایسے وقت کی مخصوص مثال لینے جا رہا ہوں جو میرے خیال میں اس کی تردید کرتی ہے۔ 2024 میں گیس کی حد کے بارے میں بہت بات چیت ہوئی۔ اور اس کی وجہ یہ ہے کہ 2022 میں دی مرج کے دوران ہم نے گیس کی حد کو بڑھا کر 30 million کر دیا تھا۔ یہ وہ زیادہ سے زیادہ کمپیوٹیشن ہے جس کی ایک بلاک میں اجازت ہے۔ اور پھر ہم نے کچھ عرصے تک اسے نہیں چھیڑا کیونکہ یہ واقعی کوئی ایسی رکاوٹ نہیں تھی جس پر لوگ کہہ رہے ہوں، "یہی وجہ ہے کہ میں ایتھیریم کی طرف منتقل نہیں ہو رہا" یا "یہ ایتھیریم کے میرے موجودہ استعمال کو محدود کر رہا ہے۔"

اور 2023 کے آخر، 2024 کے اوائل میں، یہ بیانیہ تھا کہ Solana آ رہا ہے۔ یہ ایتھیریم کو پیچھے چھوڑ دے گا۔ اور اس لیے لوگ سوچ رہے تھے کہ ایتھیریم تیز رفتاری کے لیے کیا کر سکتا ہے۔ اور ان چیزوں میں سے ایک یہ تھی کہ آئیے اس گیس میٹرک کو بڑھائیں۔ اور اس وقت EF اور کلائنٹ ڈیولپرز کا رویہ کچھ یوں تھا، "ہمارے پاس فکر کرنے کے لیے اور بھی چیزیں ہیں۔ ویسے شکریہ۔" لیکن یہ دو لوگ، Eric Connor اور Mariano Conti، آئے اور کہا، "نہیں، ہم گیس کی حد بڑھا رہے ہیں۔" گیس کی حد ایک توثیق کار کے زیر کنٹرول پیرامیٹر ہے۔ اور اس لیے وہ بس توثیق کاروں، پیشہ ور آپریٹرز سے بات کرنا شروع کر سکتے تھے، اور کہہ سکتے تھے، "ارے، اپنی گیس کی حد بڑھائیں۔"

اور ایک موقع پر اسے اتنا اپنا لیا گیا کہ EF اور کلائنٹس کو لگا، "اوہ ہمیں اس پر توجہ دینی چاہیے۔ ہمیں یہ یقینی بنانا ہوگا کہ وہ جو کر رہے ہیں وہ محفوظ ہے اور وہ اسے جس قدر تک بڑھا رہے ہیں وہ نیٹ ورک کے لیے ایک محفوظ چیز ہوگی۔" لہذا، انہیں اپنے وسائل کو دوبارہ مختص کرنا پڑا۔ نیدر مائنڈ اس ٹیسٹنگ فریم ورک کے ساتھ سامنے آیا۔ EF نے برلن میں بہت سا کام کیا۔ تمام کلائنٹ ڈیولپرز اس کی بینچ مارکنگ کر رہے تھے۔ اور اس لیے مجھے یہ پسند ہے کیونکہ اس نے EF کو یہ فیصلہ کرنے پر مجبور کیا کہ کس چیز کو ترجیح دی جائے۔

اور مجھے یہ احمقانہ ٹویٹ پسند ہے جس کا میں نے یہاں اسکرین شاٹ لیا ہے کیونکہ یہ ایسا ہے جیسے کوئی عام نیوز آؤٹ لیٹ Eric Connor اور Mariano Conti کو کور ڈیولپرز کہہ رہا ہو۔ وہ کور ڈیولپرز نہیں ہیں۔ Eric Connor ایک اسٹیکر اور کمیونٹی ممبر تھا۔ Mariano Conti ایک سابق MakerDAO ایپ ڈیولپر تھا۔ لیکن انہیں صرف اس لیے کور ڈیولپرز کہا گیا کیونکہ ایتھیریم کی ڈیولپمنٹ روایتی سافٹ ویئر کے کام کرنے کے طریقے کی دنیا سے بالکل باہر ہے اور اس لیے انہوں نے ایک بنیادی پیرامیٹر کو تبدیل ہوتے دیکھا اور انہوں نے سوچا، "اوہ یہ ضرور کور ڈیولپرز ہوں گے۔" وہ نہیں تھے۔ تو یہ صرف کمیونٹی ممبرز کے آگے آنے اور یہ کہنے کی ایک مثال ہے کہ ہم یہ تبدیلی دیکھنا چاہتے ہیں اور اسے عملی جامہ پہنانا چاہتے ہیں۔

یہ سب خفیہ سودے بازیاں ہیں، اندرونی لوگ، پرانے کھلاڑی (OGs) — میں تھوڑا اور سمجھتا ہوں کہ یہ ایک غلط فہمی کیوں ہے کیونکہ آپ بنیادی طور پر ان گورننس کالز میں آتے ہیں، ان گورننس کالز میں سو لوگ ہوتے ہیں۔ ایسا لگتا ہے کہ وہ سب اس بات سے بہت مطمئن ہیں کہ کیا ہو رہا ہے۔ آپ کھوئے ہوئے ہیں۔ آپ کو اندازہ نہیں ہے کہ یہ فیصلے کیسے کیے جاتے ہیں۔ آپ سوچتے ہیں، "کیا ابھی میری بات کرنے کی باری آئی ہے؟" اور ایسا محسوس ہوتا ہے کہ لوگ یہ فیصلے کرنے کے لیے انہی 10 لوگوں کی بات سن رہے ہیں۔

میرٹ اور شرکت کے اعداد و شمار (10:18)

لیکن سچ یہ ہے کہ ایتھیریم کی ڈیولپمنٹ زیادہ تر سافٹ ویئر ڈیولپمنٹ کے مقابلے میں کہیں زیادہ میرٹ پر مبنی ہے جو میں نے کبھی دیکھی ہے۔ اس اسکرین شاٹ پر موجود یہ تمام لوگ — یہ اس بے ترتیب ACD کال کے تین میں سے ایک ہے جس کا میں نے اسکرین شاٹ لینے کا فیصلہ کیا — ان میں سے کسی بھی شخص کو یہاں ہونے کے لیے مقرر نہیں کیا گیا تھا۔ ہر کوئی بس ان لوگوں میں سے ہے جو وہاں آئے۔ یہ وہ ڈیولپرز ہیں جنہوں نے اس پروٹوکول کے ساتھ بہت وقت گزارا ہے۔ یہ وہ لوگ ہیں جنہیں لوگوں نے اس فیلڈ میں باصلاحیت ڈیولپرز کے طور پر تسلیم کیا ہے جو مسلسل اچھے فیصلے کر رہے ہیں، اور اس میں کسی کو بھی یہاں ہونے کے لیے مقرر نہیں کیا گیا ہے۔

تو میں نے صرف ایک سال سے کچھ عرصہ قبل ہی EF میں شمولیت اختیار کی ہے۔ میں نے یہ اعداد و شمار اکٹھے کیے ہیں۔ یہ صرف مارچ 2025 تک جاتے ہیں۔ تو ایک سال سے بھی کم۔ آل کور ڈیو (All Core Dev) کے شرکاء کی اوسط — جو کہ گورننس کالز ہیں — 98 ہے۔ لہذا اوسطاً ان کالز میں 98 لوگ ہوتے ہیں۔ اس کے بعد سے ایک کال میں زیادہ سے زیادہ شرکاء 153 تھے۔ میرا خیال ہے کہ وہ دن تھا جب ہم پیکٹرا مین نیٹ کی تاریخ کا فیصلہ کر رہے تھے۔ اور صرف پچھلے سال میں کل منفرد شرکاء 567 ہیں۔ مجھے واقعی یہ میٹرک پسند ہے کیونکہ یہ ظاہر کرتا ہے کہ ہر بار ان کالز میں وہی 100 لوگ نہیں جاتے۔ یہ ایپ ڈیولپرز، محققین، کوئی کسی ایسی خصوصیت کے بارے میں سنتا ہے جس پر بحث ہو رہی ہے، وہ اس کی مخالفت یا حمایت میں آواز اٹھانے کے لیے آتے ہیں اور پھر وہ کسی دوسری کال میں نہیں آتے۔

گورننس کا عمل کیسے کام کرتا ہے (11:52)

تو یہ ایک طرح کی خشک سلائیڈ ہے لیکن میرے خیال میں اس سے گزرنا اہم ہے — ایتھیریم کی گورننس فی الحال اس طرح کام کرتی ہے۔ تو جب ان فورکس میں سے کسی ایک پر بحث ہو رہی ہوتی ہے تو سب سے پہلی چیز جو ہوتی ہے وہ یہ ہے کہ لوگ اس مختص کردہ وقت کے دوران اپنی ہیڈلائنر تجویز جمع کرانے کے قابل ہوتے ہیں۔ ہیڈلائنر تجویز وہ اہم خصوصیت ہے جس کے گرد ہم چاہتے ہیں کہ لوگ اس فورک کے لیے جمع ہوں۔ یہ کوئی کمیونٹی ممبر، محقق، کور ڈیولپر ہو سکتا ہے — واقعی کوئی بھی جو ان ہیڈلائنر تجاویز میں سے ایک جمع کراتا ہے۔ پھر وہ وقت ختم ہو جاتا ہے اور گورننس کالز پر ہم اس بات پر بحث کرتے ہیں کہ ان میں سے کون سی معنی خیز ہے۔ لوگ اپنے دلائل پیش کرتے ہیں، لوگ بحث کرتے ہیں اور اس بات پر اتفاق رائے ہوتا ہے کہ ہمیں اس آنے والے فورک کے لیے کون سی تجویز کا انتخاب کرنا چاہیے۔

اس کے بعد وہ معمولی خصوصیات کا انتخاب کرتے ہیں۔ یعنی وہ چھوٹی چیزیں جنہیں واقعی ان بڑی فورک چلانے والی خصوصیات ہونے کی ضرورت نہیں ہے۔ اور اس پورے وقت کے دوران ہمارے پاس فیچر کے لحاظ سے مخصوص ڈیونیٹس ہوتے ہیں۔ ایک ڈیونیٹ ایک ٹیسٹ نیٹ کی طرح ہوتا ہے — ڈیولپرز کے لیے ان خصوصیات کو ٹیسٹ کرنے اور یہ یقینی بنانے کے لیے ایک نجی آزمائشی نیٹ ورک کہ وہ دراصل ایتھیریم پر کام کر رہی ہیں۔ اور پھر کسی موڑ پر فیچر فریز (feature freeze) ہوتا ہے۔ تو ہم نے بڑی خصوصیات پر تبادلہ خیال کیا ہے، ہم نے معمولی خصوصیات پر تبادلہ خیال کیا ہے، ہم نے یہ فیچر کے لحاظ سے مخصوص ڈیونیٹس چلائے ہیں جو عام طور پر فورک ہیڈلائنرز ہوتے ہیں۔ اور یہ ایک ستارے (asterisk) کے ساتھ فیچر فریز ہے کیونکہ اس مقام پر ہم نے فیصلہ کیا ہے کہ ہم اس فورک میں مزید کوئی خصوصیات شامل نہیں کریں گے۔ ہم تمام خصوصیات کو ایک ساتھ چلانے والے ہیں، یہ یقینی بنانے کے لیے کہ سب کچھ ٹھیک ہے، یہ یقینی بنانے کے لیے کہ کچھ بھی ٹوٹنے والا نہیں ہے۔ لیکن اگر کوئی چیز کام کو سست کرنا شروع کر دیتی ہے، اگر فورک میں تاخیر ہوتی ہے، اگر یہ بہت پیچیدہ ہے، تو اس مقام پر بھی چیزوں کو نکالا جا سکتا ہے۔

تو کئی ڈیونیٹس کے بعد — یہ دو ہو سکتے ہیں، یہ 10 ہو سکتے ہیں — تمام کلائنٹس کسی موڑ پر فیصلہ کرتے ہیں کہ یہ مستحکم ہے۔ ہم اس پر بھروسہ کرتے ہیں جو ابھی ہو رہا ہے۔ ہم ایک اچھی جگہ پر ہیں۔ آئیے اسے ایتھیریم مین نیٹ پر لانے کے بارے میں سوچنا شروع کریں۔ وہ کلائنٹ ریلیزز جاری کرتے ہیں اور پھر 30 دن کی مدت ہوتی ہے جہاں EF سیکیورٹی ٹیم بگ باؤنٹی (bug bounty) پیش کرتی ہے۔ وہ سیکیورٹی آڈٹ کا معاہدہ کرتے ہیں۔ اور پھر اس 30 دن کی مدت کے اختتام پر ہم فورک کو آزمائشی نیٹ ورکس پر لانچ کرتے ہیں۔ یہ وہ آزمائشی نیٹ ورکس ہیں جن کے بارے میں آپ نے سنا ہوگا — جیسے Holesky۔ یہ وہ جگہیں ہیں جہاں ایپ ڈیولپرز فورک کے لائیو ہونے سے پہلے اپنی چیزوں کو ٹیسٹ کر سکتے ہیں۔ اور یہ عام طور پر کم از کم 14 دن کے ہوتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ سب کچھ ٹھیک ہے۔ ہم کسی بڑے مسئلے کی توقع نہیں کرتے کیونکہ یہ پہلے فیچر کے لحاظ سے مخصوص ڈیونیٹس اور عمومی ڈیونیٹس سے گزر چکا ہوتا ہے، لیکن تاریخی طور پر اس نے ان میں سے کچھ آزمائشی نیٹ ورکس کو توڑا ہے۔ اور اس لیے یہ ان تمام بگز کو تلاش کرنے اور ختم کرنے کا آخری موقع ہوتا ہے۔

اور پھر ایک بار جب بلا اجازت آزمائشی نیٹ ورک مستحکم ہو جاتا ہے، تو مین نیٹ کی تاریخ کا انتخاب کیا جاتا ہے۔ اس کے بعد، 30 دن کا بفر (buffer) ہوتا ہے۔ یہ 30 دن کا بفر اس لیے موجود ہے کیونکہ L2s اور پروٹوکولز نے فورک کے لیے تیار ہونے کی غرض سے اس کی درخواست کی ہے۔ تو یہ کم از کم 30 دن کا ہوتا ہے اور پھر فورک ہوتا ہے۔

کال کا ڈھانچہ اور ہم آہنگی (15:01)

اس پورے وقت کے دوران کچھ اہم کال سیریز ہو رہی ہوتی ہیں۔ یہ سب عوامی کالز ہیں جو یوٹیوب پر لائیو اسٹریم کی جاتی ہیں۔ ان میں اہم ACDE اور ACDC ہیں۔ E کا مطلب عمل درآمد کی تہہ ہے — اس میں ٹرانزیکشنز، سمارٹ کنٹریکٹ کی تعیناتی، میم پول مینجمنٹ جیسی چیزیں شامل ہیں۔ ACDC اتفاق رائے کی تہہ ہے — تو اس میں توثیق کار کی چیزیں جیسے توثیق کار کا انتظام، کٹوتی شامل ہیں۔ اور یہ جمعرات کے دن باری باری ہوتی ہیں۔ لہذا ہر جمعرات کو ایک ACD ہوتی ہے اور ان میں سے ایک ACDE ہوتی ہے اور پھر اگلی ACDC ہوتی ہے، اور اسی طرح سلسلہ جاری رہتا ہے۔

ACDE اور ACDC کالز اس فورک پر توجہ مرکوز کرتی ہیں جو ہم فی الحال بنا رہے ہیں اور وہ فورکس جن کا ہم مستقبل کے لیے دائرہ کار طے کر رہے ہیں۔ ACDT کالز زیادہ باریک بینی اور گہرائی میں ہوتی ہیں۔ ان میں کلائنٹس ان بگز کے بارے میں بات کرتے ہیں جنہیں وہ حل نہیں کر پا رہے یا اس فورک کے بارے میں عمل درآمد کی تفصیلات جنہیں حل کرنے کی ضرورت ہے جس پر وہ فی الحال کام کر رہے ہیں۔ تو ابھی اگلا فورک جو ہو رہا ہے وہ گلیمسٹرڈیم ہے۔ لہذا ان ACDT کالز میں ePBS اور بلاک لیول ایکسیس لسٹس کے بارے میں گفتگو کا غلبہ ہوتا ہے جو وہ چیزیں ہیں جو گلیمسٹرڈیم میں شامل ہو رہی ہیں۔ اور یہ انتہائی تکنیکی کالز ہوتی ہیں۔

اور پھر بریک آؤٹ کالز (breakout calls) ہوتی ہیں۔ بریک آؤٹ کالز میں کمیونٹی ممبرز، محققین، ڈیولپرز کہتے ہیں، "ارے، میرے پاس ایک خصوصیت ہے جسے میں اب سے دو فورکس کے بعد ایتھیریم میں شامل کرنا چاہتا ہوں۔" اور اس لیے وہ یہ ہفتہ وار، ماہانہ، یا دو ماہی کالز کی میزبانی کرتے ہیں جہاں وہ عمل درآمد کی تفصیلات طے کرتے ہیں، تصریحات (spec) میں تبدیلی اور بہتری لاتے ہیں، اور عام طور پر ان تمام سوالات کو حل کرتے ہیں جو لوگوں کے ذہن میں ہوتے ہیں، تمام معلوم نامعلوم چیزوں کو حل کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ یہ اب سے دو فورکس کے بعد فورک میں شامل ہونے کے لیے بہترین ممکنہ حالت میں ہے۔ اور انہیں اس وقت شیڈول کیا جا سکتا ہے جب بھی سہولت کار فیصلہ کرے۔

ایک ارتقا پذیر عمل (15:29)

تو ایک چیز جو میں سب پر واضح کرنا چاہتا ہوں وہ یہ ہے کہ یہ عمل کسی بھی طرح سے جامد نہیں ہے۔ یہ عمل جو میں نے ابھی آپ کو بیان کیا ہے اسے لائیو ہوئے ایک سال سے بھی کم عرصہ ہوا ہے۔ ایتھیریم 10 سال سے لائیو ہے۔ لیکن یہ مسلسل تبدیل ہوتا رہتا ہے اور اس کے مسلسل تبدیل ہونے کی وجہ یہ ہے کہ کوئی بھی انچارج نہیں ہے۔ اور یہ عمل کام کرنے کا سب سے موثر طریقہ تلاش کرنے کے لیے ایک طرح سے ارتقا پذیر ہوتا ہے۔ اور جیسے میں موثر کہتا ہوں، لیکن ایتھیریم گورننس کی جو شہرت ہے وہ یہ ہے کہ یہ واقعی سست ہے، چیزوں کو منظور کروانا مشکل ہے، مبہم ہے — اور اس کی وجہ یہ ہے کہ جب آپ کے پاس 100 سے 500 لوگ فیصلے کر رہے ہوں، تو میں ایمانداری سے متاثر ہوں کہ یہ بالکل کام کرتا ہے۔

تو ٹم (Tim) نے اپریل 2025 میں "Reconfiguring All Core Devs" کے نام سے ایک پوسٹ کی جو بالآخر اس بات کی تجویز بن گئی کہ چیزیں ابھی کیسے کام کرتی ہیں۔ اور اس کی وجہ یہ ہے کہ اس سے پہلے ہمارے پاس ایک طرح کا یہ مربوط بیانیہ تھا کہ ہمیں ایتھیریم میں کس چیز پر توجہ مرکوز کرنی چاہیے۔ دی مرج تھا جو ایک بہت بڑا کام تھا۔ ہر کوئی بہت پرجوش تھا۔ زیادہ تر لوگ بہت پرجوش تھے۔ مائنرز نہیں تھے۔ اور پھر دی مرج کے بعد، آپ کے پاس رقوم نکلوانے (withdrawals) کا آپشن تھا۔ لہذا، ہم نہیں چاہتے تھے کہ لوگوں کا ETH کسی کنٹریکٹ میں مقفل ہو جائے اور یہ خوف (FUD) پھیلے کہ وہ کبھی بھی اس سے اپنا ETH نہیں نکال پائیں گے۔ لہذا، ہمیں اسے جلد از جلد پیش کرنا تھا۔ اور پھر پروٹو-ڈینک شارڈنگ تھی اور پھر پیکٹرا آیا اور پیکٹرا ایک طرح سے مختلف غیر متعلقہ EIPs کا مرکب تھا اور اس کا واقعی کوئی مربوط بیانیہ نہیں تھا۔ اور یہ اتنا بڑا ہو گیا کیونکہ ہم آہنگی کی کمی کی وجہ سے لوگ بس چیزیں اس میں ڈال رہے تھے کہ اسے دو مختلف فورکس میں تقسیم کرنا پڑا کیونکہ ٹیسٹنگ ٹیموں کا کہنا تھا، "اس کا دائرہ کار بہت بڑا ہے۔ ہم اس سب کو ٹیسٹ نہیں کر سکتے۔"

اور اس لیے ٹم کا یہ کرنے کا محرک یہ تھا کہ، ٹھیک ہے، ہمیں ان فورکس کو ہر ممکن حد تک مرکوز اور مربوط رکھنے کے طریقے کے بارے میں سوچنے کی ضرورت ہے۔ اور ہیڈلائنر ایک طرح سے اس کا جواب تھا۔ اس کا مقصد اس طرح سے چیزوں کو پیش کرنا تھا جس میں اس بات کو ترجیح دی جائے کہ ہر کسی کو معلوم ہو کہ فورک کس بارے میں ہے، تاکہ انہیں 25 مختلف EIPs کو زبردستی شامل نہ کرنا پڑے۔

تو اوپر موجود دوسرا اسکرین شاٹ ٹم کا ہے جو ان EIPs کی شمولیت کے مراحل کی تعریفیں تجویز کر رہا ہے۔ اور میں اس سے جو بات واضح کرنا چاہتا ہوں وہ یہ ہے کہ بعض اوقات آپ لوگوں کو یہ کہتے ہوئے سنتے ہیں کہ یہ عمل بہت بیوروکریٹک ہے۔ لیکن حقیقت میں جو ہو رہا ہے وہ یہ ہے کہ لوگ اس گورننس کے عمل میں آتے ہیں اور وہ کہتے ہیں، "میں ایک EIP کیسے شامل کرواؤں؟" اور جو لوگ 10 سال سے وہاں ہیں وہ کہتے ہیں، "آپ بس کروا لیتے ہیں۔" اور لوگ کہتے ہیں، "یہ خوفناک ہے۔" اور اس لیے یہ چیزیں جو کرتی ہیں وہ یہ ہے کہ وہ بیان کرتی ہیں کہ کیا ہو رہا ہے تاکہ بیرونی لوگوں کے لیے اس عمل میں حصہ لینا آسان ہو جائے، کیونکہ اگر آپ صرف یہاں آ رہے ہیں اور آپ کہتے ہیں، "میرے پاس ایک EIP ہے، مجھے ایتھیریم گورننس کی پرواہ نہیں ہے، میں صرف اس ایک EIP کو شامل کروانا چاہتا ہوں" — تو آپ کو ایک لائحہ عمل چاہیے، آپ کو ایک چیک لسٹ چاہیے، آپ کو اس EIP کو شامل کروانے کے طریقے پر ایک بہت واضح مرحلہ وار رہنمائی چاہیے۔ لہذا، ان میں سے زیادہ تر چیزیں بیوروکریٹک اصول بنانے کے بجائے اس بات کو بیان کرنے کے بارے میں ہیں کہ یہ عمل کیسے کام کرتا ہے، جن پر لوگوں کو عمل کرنا پڑے تاکہ EIPs کو شامل کروانا مشکل ہو جائے۔

تیسری چیز Forkcast پر وقت کے ساتھ ہونے والی کمٹس (commits) ہیں۔ Forkcast میری ٹیم کی ایک پروڈکٹ ہے، جسے میری ٹیم کے ایک فرد Wolfram Mark نے پچھلے سال کے وسط میں بنایا تھا جب میری ٹیم اپنی موجودہ شکل میں تشکیل پائی تھی۔ اور یہ لوگوں کے لیے ایک فورک کے ساتھ تعامل کرنے، یہ دیکھنے کے لیے کہ فورک میں کیا شامل ہو رہا ہے اور یہ ان پر کیسے اثر انداز ہوتا ہے، استعمال کرنے کے لیے ایک ایسا مستند ذریعہ بن گیا ہے۔ یہ تمام چیزیں دو سال سے بھی کم پرانی ہیں۔ تو میں صرف یہ بات واضح کر رہا ہوں کہ یہ عمل بہت بدلتا ہے۔ یہ بالکل بھی جامد نہیں ہے۔ یہ کوئی جمی ہوئی بیوروکریسی نہیں ہے جس میں قدم جمانا مشکل ہو۔

قابل موازنہ گورننس سسٹمز (20:21)

تو میں بس جلدی سے گورننس کے ان سب سے ملتے جلتے لامركزی سسٹمز پر روشنی ڈالنا چاہتا تھا جو مجھے ایتھیریم گورننس کے مشابہ نظر آتے ہیں۔ اور میں یہاں جو بات سمجھانے کی کوشش کر رہا ہوں وہ یہ ہے کہ یہ پائیدار ہے — اگرچہ یہ حیرت انگیز ہے کہ 100 سے 500 لوگ فیصلے کر سکتے ہیں، لیکن یہ حقیقی دنیا میں پائیدار ہے۔ ہم اس کے کام کرنے کی مثالیں دیکھتے ہیں۔

IETF انٹرنیٹ انجینئرنگ ٹاسک فورس (Internet Engineering Task Force) ہے۔ یہ رضاکاروں کے زیر انتظام چلنے والا معیارات کا ادارہ ہے جس نے TCP/IP، HTTP بنایا۔ یہ وہ تنظیم ہے جو اس حقیقت کے لیے سب سے زیادہ ذمہ دار ہے کہ آج ہمارے پاس مفت انٹرنیٹ موجود ہے۔ لینکس کرنل (Linux kernel) — یہ لینکس آپریٹنگ سسٹم کا مرکز ہے۔ تو یہ اوپن سورس سافٹ ویئر ہے جو انٹرنیٹ سرورز، اینڈرائیڈ فونز، سپر کمپیوٹرز کو چلاتا ہے۔ وہاں فرق یہ ہے کہ ان کے پاس Linus Torvalds کے ساتھ ایک طرح کا خیر خواہ ڈکٹیٹر ماڈل ہے۔ لیکن اس کے باوجود ان کے پاس 17,000 سے زیادہ تعاون کنندگان ہیں، جو کہ حیران کن ہے۔

وہ چیزیں جن سے یہ مشابہ نہیں ہے: دیگر بلاک چینز جن میں آن چین ٹوکن ووٹنگ ہوتی ہے۔ ایتھیریم خاص طور پر کسی بھی قسم کے ووٹنگ میکانزم سے گریز کرتا ہے کیونکہ میری رائے میں یہ قبضے کے راستے کھولتا ہے اور یہ ایک طرح سے چیزوں کو میرٹ پر مبنی بنانے کی ترغیب کو ختم کر دیتا ہے جہاں لوگ صرف ان لوگوں پر بھروسہ کرتے ہیں جو بہترین کوڈ لکھتے ہیں۔ اور پھر L2s ہیں۔ ان کے پاس ملٹی سگ (multi-sigs) ہیں۔ ان کے پاس سیکیورٹی کونسلز ہیں۔ یہ زیادہ تر مقرر کردہ عہدوں کی طرح ہیں جو یہ فیصلے کرتے ہیں۔ اور اس کے اپنے نقصانات ہیں۔ یہ زیادہ مرکزی ہے۔ تاہم یہ تیزی سے آگے بڑھتا ہے۔

بلڈرز کو کیوں پرواہ ہے (22:38)

تو بلڈرز کو گورننس کی پرواہ کیوں ہے؟ کیونکہ بلڈرز ہی وہ لوگ ہیں جن کے لیے ایتھیریم بنایا گیا ہے۔ ایتھیریم کور ڈیولپرز کے لیے نہیں بنایا گیا ہے۔ یہ توثیق کاروں کے لیے نہیں بنایا گیا ہے۔ بعض اوقات یہ لوگ اس بارے میں الجھن کا شکار ہو جاتے ہیں۔ ایتھیریم کور ڈیولپرز اور توثیق کار ایتھیریم کی خدمت کرتے ہیں جو بلڈرز اور صارفین کی خدمت کرتا ہے۔

اور ہر کسی کا AI کے ساتھ وہ لمحہ گزرا ہے جہاں آپ بہت زیادہ گہرائی میں جا رہے ہوتے ہیں اور یہ اس چھوٹی سی چیز کو ٹھیک کرنے کی کوشش کر رہا ہوتا ہے اور یہ پیچھے ہٹ کر پروجیکٹ کے پورے مقصد کو دیکھنے میں ناکام رہتا ہے۔ اور کور ڈیولپرز بھی ایسے ہو سکتے ہیں جہاں وہ کور ڈیولپمنٹ کے عمل کو مکمل کرنے کی کوشش کر رہے ہوں۔ اور اس صورت میں یہ بہت اہم ہے کہ بلڈرز آگے آئیں کیونکہ کور ڈیولپمنٹ اتنی زیادہ توجہ طلب ہے کہ وہ زیادہ تر وقت ایتھیریم کے اوپر تعمیر نہیں کر رہے ہوتے۔ وہ کور ڈیولپمنٹ میں بہت زیادہ ملوث ہوتے ہیں۔ یہ ان کا سارا وقت لے لیتا ہے۔ اور اس لیے ایپ بلڈرز کو واقعی آگے آنے اور یہ کہنے کی کوشش کرنی پڑتی ہے، "ارے، ہمیں اس کی ضرورت ہے۔ یہ ایتھیریم کے لیے بہت اہم ہے۔" صرف یہ یقینی بنانے کے لیے کہ وہ نقطہ نظر موجود ہے اور وہ صرف کور ڈیولپرز کے لیے کام کرنے تک محدود نہیں ہو رہے ہیں۔

کیسے حصہ لیں (24:40)

تو آپ کیسے حصہ لیتے ہیں یا اپنی خصوصیت کو کیسے شامل کرواتے ہیں؟ یہ ایک طرح کا عمومی مشورہ ہے، لیکن میرے خیال میں یہ بہترین ہے۔ اپنے مسائل کے بارے میں کھل کر بات کریں۔ ٹوئٹر پر جائیں، بلاگ پوسٹس لکھیں، اپنے مسائل کے حل کی نشاندہی کریں۔ ان چیزوں پر غور کریں جو آپ کی مدد کر سکتی ہیں۔ اگر آپ کو دوسرے لوگ ملتے ہیں جنہیں وہی مسائل درپیش ہیں، تو عام طور پر آپ کو ایک ایسی EIP مل سکتی ہے جو اس مسئلے کو حل کرنے کے لیے موجود ہو یا آپ کسی سے ایسی EIP لکھنے میں مدد لے سکتے ہیں جو ایسا کرے۔

اوپن سورس سافٹ ویئر کے بارے میں مجھے ایک چیز جو پسند ہے وہ یہ ہے کہ عام طور پر اچھے سرمائے والی کمپنیاں اپنا ڈیولپمنٹ کا وقت اور وسائل اس اوپن سورس ٹولنگ کو برقرار رکھنے کے لیے مختص کریں گی جسے وہ استعمال کر رہی ہیں۔ اور اس کا نتیجہ یہ نکلتا ہے کہ مختلف کمپنیوں کا ایک گروپ اس چیز کو برقرار رکھنے میں تعاون کرتا ہے اور ایتھیریم میں بھی یہ اسی طرح کام کر سکتا ہے۔ لہذا اگر آپ کا کوئی مسئلہ ہے جس کی آپ نے نشاندہی کی ہے تو آپ کو ایک Base ڈیولپر مل سکتا ہے جسے بھی ایسا ہی مسئلہ درپیش ہو، اور Base ایک اچھے سرمائے والی تنظیم ہے اور اس لیے وہ شاید کسی خصوصیت کو پیش کرنے یا ایتھیریم ہارڈ فورک کے ذریعے کسی خصوصیت کی رہنمائی کرنے کے لیے کچھ وسائل مختص کرنے کے لیے تیار ہوں گے۔

میں بس آپ کے لیے کچھ وسائل چھوڑے جا رہا ہوں۔ Forkcast.org — یہ وہ جگہ ہے جہاں آپ جا کر دیکھ سکتے ہیں کہ فورک میں کیا شامل ہو رہا ہے، یہ مخصوص اسٹیک ہولڈرز کو کیسے متاثر کرتا ہے۔ لہذا، اگر آپ ایک ایپ ڈیولپر ہیں، تو ایپ ڈیولپرز کے لیے ایک سیکشن موجود ہے۔ اگر آپ ایک والیٹ ڈیولپر ہیں، یا اتفاق رائے کی تہہ کے کلائنٹ ڈیولپر ہیں، تو اس پر سیکشنز موجود ہیں کہ یہ سب آپ کو کیسے متاثر کرتے ہیں۔ یوٹیوب وہ جگہ ہے جہاں ان تمام کالز کی ویڈیوز اپ لوڈ کی جاتی ہیں۔ وہ forkcast.org/calls پیج میں بھی شامل ہیں جہاں خلاصے، مقررین کے حوالے موجود ہیں، تاکہ ان کالز کو نیویگیٹ کرنا آسان ہو۔ EIPs ڈائرکٹری، Ethereum Magicians فورم جہاں آپ جا کر دوسرے لوگوں سے ممکنہ حل یا ان EIPs کے بارے میں بات کر سکتے ہیں جو آپ لکھنا چاہتے ہیں۔ اور بہت جلد میری ٹیم کی ایک پروٹوکول سپورٹ سائٹ ہوگی۔ یہ شاندار لگتی ہے۔ یہ ابھی شیئر کرنے کے لیے تیار نہیں ہے۔ میرا ای میل بھی وہاں موجود ہے — nixo@ethereum.org (opens email client)۔ بس اتنا ہی۔