ইথেরিয়াম কোর গভর্ন্যান্স ব্যাখ্যা

ETHBoulder-এ ইথেরিয়াম ফাউন্ডেশন-এর নিক্সো রোকিশ-এর একটি প্রেজেন্টেশন, যেখানে ইথেরিয়ামের কোর প্রোটোকল গভর্ন্যান্স, কীভাবে হার্ড ফর্ক সমন্বয় করা হয়, ইথেরিয়াম কে নিয়ন্ত্রণ করে সে সম্পর্কে সাধারণ ভুল ধারণা এবং গভর্ন্যান্স প্রক্রিয়ায় কীভাবে অংশগ্রহণ করতে হয় তা ব্যাখ্যা করা হয়েছে।

এই ট্রান্সক্রিপ্টটি EthBoulder দ্বারা প্রকাশিত মূল ভিডিও ট্রান্সক্রিপ্টের (opens in a new tab) একটি অ্যাক্সেসযোগ্য অনুলিপি। পড়ার সুবিধার জন্য এটি সামান্য সম্পাদনা করা হয়েছে।

ভূমিকা (0:12)

উপস্থিত আমার ছয়জন বন্ধুকে ধন্যবাদ। ঠিক আছে। আমি আজ আপনাদের সাথে ইথেরিয়াম কোর গভর্ন্যান্স নিয়ে কথা বলছি। আমার নাম নিক্সো। আমি EF (ইথেরিয়াম ফাউন্ডেশন)-এ প্রোটোকল সাপোর্ট টিমের নেতৃত্ব দিই। আমাদের সমস্ত দায়িত্বের মধ্যে একটি হলো গভর্ন্যান্স প্রক্রিয়াটিকে আরও স্পষ্ট এবং অংশগ্রহণকারী সকলের জন্য সহজে ব্যবহারযোগ্য করে তোলা, কারণ ইথেরিয়ামে শুধুমাত্র এর কোর ডেভেলপারদের চেয়ে আরও অনেক বেশি কিছু অন্তর্ভুক্ত রয়েছে।

তো এখানে আলোচনার একটি রূপরেখা দেওয়া হলো। আমরা কোর গভর্ন্যান্স কী তা নিয়ে কথা বলব। আমরা ভুল ধারণাগুলো নিয়ে কথা বলব, বর্তমানে ইথেরিয়াম গভর্ন্যান্স কীভাবে কাজ করে তা জানব। অন্যান্য বিকেন্দ্রীকৃত গভর্ন্যান্স সিস্টেমের সাথে এর তুলনা, কেন বিল্ডারদের এটি নিয়ে ভাবা উচিত এবং অংশগ্রহণের কার্যকরী উপায়গুলো নিয়ে আমরা আলোচনা করব।

তাহলে, কোর প্রোটোকল গভর্ন্যান্স কী? আমি একটি নোড চালাই। এর মানে হলো আমার কাছে একটি হার্ডওয়্যার আছে, আমার বাড়িতে একটি কম্পিউটার আছে যেখানে আমি ইথেরিয়াম সফটওয়্যার চালাই। যখন আমি এই ইথেরিয়াম সফটওয়্যারটি সেট আপ করি, তখন আমাকে সেই সফটওয়্যারটি চালানোর জন্য ক্লায়েন্ট বেছে নিতে হয়েছিল। ইথেরিয়াম কিছুটা অনন্য কারণ ক্লায়েন্ট বৈচিত্র্য বজায় রাখার জন্য এর একাধিক ক্লায়েন্ট রয়েছে। এর মূল উদ্দেশ্য হলো যদি একটি ক্লায়েন্ট ডাউন হয়ে যায়, বা কোনো ক্লায়েন্টে বাগ থাকে, তবে পুরো নেটওয়ার্ক ডাউন হয় না। অন্যান্য ব্লকচেইন রয়েছে যাদের অন্যান্য ক্লায়েন্ট আছে। তবে, ইথেরিয়ামই একমাত্র যা এমনভাবে সেট আপ করা হয়েছে যা আসলে আমাদের বাগের বিরুদ্ধে সুরক্ষা দেয়। সুতরাং, আপনি যদি Solana-এর মতো নেটওয়ার্কে যান, Solana-এর আরেকটি ক্লায়েন্ট আছে, আমার মনে হয় একে GTO বলা হয়, তবে এর মাত্র 20–21% ব্যবহারকারী রয়েছে। তাই, যদি সংখ্যাগরিষ্ঠ ক্লায়েন্ট ডাউন হয়ে যায়, তবে চেইন ডাউন হয়ে যায়। এবং আমরা অন্যান্য নেটওয়ার্কগুলোকে ডাউন হতে দেখেছি। আর এই কারণেই ইথেরিয়াম হলো সবচেয়ে স্থিতিস্থাপক এবং সুরক্ষিত ব্লকচেইন।

তাই প্রশ্ন আসে যে, যখন আপনাকে এতগুলো ভিন্ন ক্লায়েন্টের সাথে সমন্বয় করতে হয় তখন আপনি কীভাবে ইথেরিয়ামে পরিবর্তন আনবেন। প্রথমে আমরা একটি হার্ড ফর্ক এবং একটি সফট ফর্ক-এর মধ্যে পার্থক্য করব। একটি সফট ফর্ক-এ হার্ড ফর্ক-এর মতো সমন্বয়ের প্রয়োজন হয় না। ইথেরিয়াম মূলত হার্ড ফর্ক নিয়ে কাজ করে। হার্ড ফর্ক হলো মূলত সমস্ত ক্লায়েন্ট ইথেরিয়ামের একটি নতুন সংস্করণ তৈরি করে এবং পূর্বনির্ধারিত কোনো সময়ে ইথেরিয়ামের এই নতুন সংস্করণটি চালু করার সিদ্ধান্ত নেয়। এটি এখনও ইথেরিয়াম, তবে এতে নতুন বৈশিষ্ট্য রয়েছে। এতে ভিন্ন বৈশিষ্ট্য রয়েছে। এবং আমার মতো সমস্ত নোড অপারেটর যারা বাড়িতে নোড চালাচ্ছেন বা পেশাদার অপারেটরদের ইথেরিয়ামের সেই নতুন সংস্করণটি গ্রহণ করতে হয়। তাদের সেই নতুন সফটওয়্যারটি অন্তর্ভুক্ত করার জন্য তাদের নোড আপগ্রেড বা আপডেট করতে হয়।

তাহলে তারা কীভাবে সিদ্ধান্ত নেয় যে সেই হার্ড ফর্কগুলোতে কোন বৈশিষ্ট্যগুলো যুক্ত হবে? তাদের সময় এবং সংস্থান বরাদ্দ করার জন্য অগ্রাধিকারের বিষয়ে একমত হতে হয় কারণ সেখানে বরাদ্দ করার জন্য তাদের কাছে সীমিত সময় এবং সংস্থান রয়েছে। তারা নিরাপত্তা ত্রুটি বা সিকিউরিটি প্যাচ, UX-এর মতো বিষয়গুলোকে অগ্রাধিকার দেয় — যদি অন্য কোনো ব্লকচেইন আমাদের সাথে প্রতিযোগিতা করে, তবে আমাদের সেই অন্যান্য ব্লকচেইনগুলোর সাথে প্রতিযোগিতামূলক হতে হবে। তাই তারা যে বিষয়গুলোর দিকে নজর দেয় তার মধ্যে একটি হলো, যে কোনো নতুন বৈশিষ্ট্য যা যুক্ত করা হবে তা যেন সম্ভাব্য আসন্ন রোডম্যাপ আইটেমগুলোর সাথে সামঞ্জস্যপূর্ণ হয়।

গত বছর একটি খুব বিতর্কিত ঘটনা ঘটেছিল। আপনারা হয়তো এর কথা শুনে থাকবেন। একে বলা হতো EOF। এটি হলো EVM Object Format। এটি ছিল কিছু বৈশিষ্ট্যের একটি সেট যা ফুসাকা হার্ড ফর্ক — পেকট্রা, ফুসাকা, আমার মনে হয় উভয়টিতেই — যুক্ত হওয়ার কথা ছিল, কিন্তু এটি বিভক্ত হয়ে যায়। এবং এটি সেই ফর্ক থেকে বাদ পড়ার অনেকগুলো কারণের মধ্যে একটি ছিল কারণ ভিটালিক (Vitalik) ইথেরিয়ামের RISC-V গ্রহণ করার সম্ভাবনা নিয়ে একটি পোস্ট করেছিলেন। যারা এটি পড়ছিলেন তাদের অনেকেই ভেবেছিলেন, ঠিক আছে, যদি আমরা RISC-V গ্রহণ করি তবে EOF-এ আমরা যে বৈশিষ্ট্যগুলো দেখছি তা RISC-V-এর সাথেই ডিফল্টভাবে চলে আসবে। তাহলে কেন আমরা প্রোটোকল-এ এই জটিলতা যোগ করব? কেন আমরা এই জিনিসটির পিছনে ক্লায়েন্ট ডেভেলপারদের সমস্ত সংস্থান ব্যয় করব? যদি আমরা শেষ পর্যন্ত RISC-V-তে চলে যাই তবে এটি একটি অর্থহীন বিষয় হবে।

তাই এটি ছিল EOF-এর জন্য শেষ পেরেক এবং শেষ পর্যন্ত এটি ফর্ক থেকে বাদ পড়ে যায়। তাদের আরেকটি বিষয় বিবেচনা করতে হয় তা হলো এটি ছয়টি ভিন্ন ভাষায় লিখতে হবে এবং কঠোরভাবে পরীক্ষা করতে হবে কারণ এই ক্লায়েন্টগুলো ছয়টি ভিন্ন ভাষায় লেখা। তাই এটি তাদের কাজ করার জন্য একটি খুব বড় টেস্টিং ম্যাট্রিক্স। আর এই কারণেই প্রতিটি ছোটখাটো ডিজাইনের পছন্দ বিতর্কের বিষয় হয়ে দাঁড়ায় এবং মতবিরোধ সমাধানের জন্য কোনো একক কর্তৃপক্ষ থাকে না। তাই যে প্রশ্নটি উঠে আসে তা হলো কে সিদ্ধান্ত নেয় — যা হলো গভর্ন্যান্স-এর মূল বিষয়।

ভুল ধারণা (5:23)

এটি আমাদের ভুল ধারণার দিকে নিয়ে যায় এবং আমরা এর কয়েকটি নিয়ে আলোচনা করব। একটি হলো ভিটালিক সিদ্ধান্ত নেন যে ইথেরিয়াম প্রোটোকল-এ কী যুক্ত হবে। এর একটি সম্প্রসারিত রূপ হলো EF সবকিছু নিয়ন্ত্রণ করে। এবং তৃতীয়টি হলো এগুলো সবই গোপন চুক্তি — ভেতরের লোকজন, বা OG-রা এই সিদ্ধান্তগুলো নেয়।

প্রথমটি হলো: ভিটালিক সিদ্ধান্ত নেন। আমি ভিটালিকের লেখা কিছু স্থগিত EIP (Ethereum Improvement Proposal)-এর উদাহরণ বেছে নিয়েছি। এর মানে হলো ভিটালিক বসে একটি প্রস্তাব লিখেছিলেন এবং বলেছিলেন যে আমি চাই এই জিনিসগুলো ইথেরিয়ামে যুক্ত হোক, কিন্তু কেউ রাজি হয়নি — এই জিনিসগুলো সেভাবেই পড়ে আছে। তিনি এগুলোকে প্রোটোকল-এ অন্তর্ভুক্ত করতে পারেননি। তাই তিনি যা প্রস্তাব করেন তার সবকিছুই স্বয়ংক্রিয়ভাবে অন্তর্ভুক্ত হয় না।

এর একটি সম্প্রসারিত রূপ হলো ইথেরিয়াম ফাউন্ডেশন সবকিছু নিয়ন্ত্রণ করে। আমি এমন একটি সময়ের নির্দিষ্ট উদাহরণ বেছে নেব যা আমার মতে এর বিরোধিতা করে। 2024 সালে গ্যাস লিমিট নিয়ে অনেক কথা হয়েছিল। আর এর কারণ হলো 2022 সালে দ্য মার্জ-এর সময় আমরা গ্যাস লিমিট বাড়িয়ে 30 মিলিয়ন করেছিলাম। এটি হলো একটি ব্লক-এ অনুমোদিত সর্বোচ্চ কম্পিউটেশন। এরপর আমরা কিছু সময়ের জন্য এটিতে হাত দিইনি কারণ এটি এমন কোনো বাধা ছিল না যার জন্য লোকেরা বলছিল, "এই কারণেই আমি ইথেরিয়ামে যাচ্ছি না" বা "এটি ইথেরিয়ামে আমার বর্তমান ব্যবহারকে সীমাবদ্ধ করছে।"

2023 সালের শেষের দিকে এবং 2024 সালের শুরুর দিকে, এমন একটি গুঞ্জন ছিল যে Solana আসছে। এটি ইথেরিয়ামের জায়গা দখল করতে যাচ্ছে। তাই লোকেরা ভাবছিল যে ইথেরিয়ামকে ত্বরান্বিত করতে কী করা যেতে পারে। এর মধ্যে একটি বিষয় ছিল যে চলুন এই গ্যাস মেট্রিকটি বাড়ানো যাক। আর সেই সময়ে EF এবং ক্লায়েন্ট ডেভেলপাররা অনেকটা এমন ছিল, "আমাদের চিন্তা করার মতো অন্যান্য বিষয় আছে। তবে ধন্যবাদ।" কিন্তু এরিক কনর (Eric Connor) এবং মারিয়ানো কন্টি (Mariano Conti) নামের এই দুজন ব্যক্তি এসে বললেন, "না, আমরা গ্যাস লিমিট বাড়াচ্ছি।" গ্যাস লিমিট হলো একটি ভ্যালিডেটর-নিয়ন্ত্রিত প্যারামিটার। তাই তারা ভ্যালিডেটর এবং পেশাদার অপারেটরদের সাথে কথা বলা শুরু করতে পারতেন এবং বলতে পারতেন, "আরে, আপনাদের গ্যাস লিমিট বাড়ান।"

এবং এক পর্যায়ে এটি এতটাই গ্রহণযোগ্যতা পেয়েছিল যে EF এবং ক্লায়েন্টরা ভাবতে বাধ্য হয়েছিল, "ওহ, আমাদের এদিকে মনোযোগ দিতে হবে। আমাদের নিশ্চিত করতে হবে যে তারা যা করছে তা নিরাপদ এবং তারা শেষ পর্যন্ত যে মানটি বাড়াচ্ছে তা নেটওয়ার্ক-এর জন্য নিরাপদ হবে।" তাই, তাদের সংস্থানগুলো পুনরায় বরাদ্দ করতে হয়েছিল। নেদারমাইন্ড এই টেস্টিং ফ্রেমওয়ার্কটি নিয়ে এসেছিল। EF বার্লিন-এ অনেক কাজ করেছিল। সমস্ত ক্লায়েন্ট ডেভেলপাররা এর বেঞ্চমার্কিং করছিল। তাই আমার এটি ভালো লেগেছে কারণ এটি EF-কে কোন বিষয়টিকে অগ্রাধিকার দেওয়া হবে তা নির্ধারণ করতে বাধ্য করেছিল।

এবং আমার এই বোকা টুইটটি ভালো লেগেছে যা আমি এখানে স্ক্রিনশট নিয়েছি কারণ এটি এমন যে কোনো একটি সাধারণ নিউজ আউটলেট এরিক কনর এবং মারিয়ানো কন্টি-কে কোর ডেভেলপার বলছে। তারা কোর ডেভেলপার নন। এরিক কনর ছিলেন একজন স্টেকার এবং কমিউনিটি সদস্য। মারিয়ানো কন্টি ছিলেন MakerDAO-এর একজন প্রাক্তন অ্যাপ ডেভেলপার। কিন্তু তাদের কোর ডেভেলপার বলা হয়েছিল কারণ ইথেরিয়াম ডেভেলপমেন্ট প্রথাগত সফটওয়্যার কীভাবে কাজ করে তার জগতের সম্পূর্ণ বাইরে, তাই তারা একটি কোর প্যারামিটার পরিবর্তন হতে দেখে ভেবেছিল, "ওহ, এরা নিশ্চয়ই কোর ডেভেলপার।" তারা তা ছিলেন না। তাই এটি হলো কমিউনিটি সদস্যদের এগিয়ে এসে এই পরিবর্তনটি দেখতে চাওয়া এবং তা বাস্তবায়ন করার একটি উদাহরণ মাত্র।

এগুলো সবই গোপন চুক্তি, ভেতরের লোকজন, OG-রা — আমি একটু বেশি বুঝতে পারি কেন এটি একটি ভুল ধারণা, কারণ আপনি যখন এই গভর্ন্যান্স কলগুলোতে আসেন, তখন সেখানে একশ জন লোক থাকে। মনে হয় তারা সবাই যা ঘটছে তা নিয়ে খুব স্বাচ্ছন্দ্যবোধ করছে। আপনি হারিয়ে গেছেন। এই সিদ্ধান্তগুলো কীভাবে নেওয়া হয় সে সম্পর্কে আপনার কোনো ধারণা নেই। আপনি ভাবছেন, "এখন কি আমার কথা বলার পালা?" এবং মনে হয় যে এই সিদ্ধান্তগুলো নেওয়ার জন্য লোকেরা একই 10 জনের কথা শুনছে।

মেধাভিত্তিক ব্যবস্থা এবং অংশগ্রহণের পরিসংখ্যান (10:18)

কিন্তু সত্য হলো ইথেরিয়াম ডেভেলপমেন্ট বেশিরভাগ সফটওয়্যার ডেভেলপমেন্টের তুলনায় অনেক বেশি মেধাভিত্তিক, যা আমি আগে কখনো দেখিনি। এই স্ক্রিনশটের সমস্ত লোক — এটি একটি সাধারণ ACD (All Core Devs) কলের তিনটির মধ্যে একটি যা আমি স্ক্রিনশট নেওয়ার সিদ্ধান্ত নিয়েছিলাম — এদের কাউকেই এখানে নিয়োগ দেওয়া হয়নি। সবাই হলো সেইসব মানুষ যারা এখানে উপস্থিত হয়েছেন। তারা হলেন সেই ডেভেলপার যারা এই প্রোটোকল-এর সাথে অনেক সময় কাটিয়েছেন। তারাই হলেন সেই ব্যক্তি যাদের লোকেরা এই স্পেসে প্রতিভাবান ডেভেলপার হিসেবে স্বীকৃতি দিয়েছে যারা ধারাবাহিকভাবে ভালো সিদ্ধান্ত নিচ্ছেন, এবং এখানকার কাউকেই নিয়োগ দেওয়া হয়নি।

আমি মাত্র এক বছরের কিছু বেশি সময় আগে EF-এ যোগ দিয়েছি। আমি এই পরিসংখ্যানগুলো সংগ্রহ করেছি। এগুলো শুধুমাত্র 2025 সালের মার্চ পর্যন্ত। অর্থাৎ এক বছরেরও কম সময়ের। All Core Dev-এ অংশগ্রহণকারীদের গড় সংখ্যা — যা হলো গভর্ন্যান্স কল — 98 জন। তাই গড়ে এই কলগুলোতে 98 জন লোক থাকে। এরপর থেকে একটি কলে সর্বোচ্চ অংশগ্রহণকারী ছিল 153 জন। আমার মনে হয় সেটি সেই দিন ছিল যেদিন আমরা পেকট্রা মেইননেট-এর তারিখ নির্ধারণ করছিলাম। এবং শুধুমাত্র গত বছরে মোট অনন্য অংশগ্রহণকারীর সংখ্যা হলো 567 জন। আমার এই মেট্রিকটি সত্যিই ভালো লাগে কারণ এটি দেখায় যে প্রতিবার একই 100 জন লোক এই কলগুলোতে যায় না। এই অ্যাপ ডেভেলপার, গবেষক, কেউ কোনো বৈশিষ্ট্য নিয়ে আলোচনা হচ্ছে শুনে তাদের বিরোধিতা বা সমর্থন জানাতে উপস্থিত হন এবং তারপর তারা আর অন্য কোনো কলে আসেন না।

গভর্ন্যান্স প্রক্রিয়া কীভাবে কাজ করে (11:52)

এটি কিছুটা নীরস স্লাইড তবে আমি মনে করি এটি নিয়ে আলোচনা করা গুরুত্বপূর্ণ — বর্তমানে ইথেরিয়ামের গভর্ন্যান্স এভাবেই কাজ করে। যখন এই ফর্কগুলোর কোনো একটি নিয়ে আলোচনা করা হয়, তখন প্রথম যে জিনিসটি ঘটে তা হলো লোকেরা এই নির্ধারিত সময়ের মধ্যে তাদের হেডলাইনার প্রস্তাব জমা দিতে পারে। হেডলাইনার প্রস্তাব হলো সেই প্রধান বৈশিষ্ট্য যা আমরা চাই লোকেরা এই ফর্ক-এর জন্য সমর্থন করুক। এটি একজন কমিউনিটি সদস্য, একজন গবেষক, একজন কোর ডেভেলপার হতে পারে — যে কেউ এই হেডলাইনার প্রস্তাবগুলোর একটি জমা দিতে পারে। তারপর সময়সীমা শেষ হয় এবং গভর্ন্যান্স কলগুলোতে আমরা আলোচনা করি যে এগুলোর মধ্যে কোনটি যুক্তিসঙ্গত। লোকেরা তাদের যুক্তি উপস্থাপন করে, তর্ক করে এবং আসন্ন ফর্ক-এর জন্য আমাদের কোনটি বেছে নেওয়া উচিত সে বিষয়ে ঐক্যমত তৈরি হয়।

এরপর তারা ছোটখাটো বৈশিষ্ট্যগুলো বেছে নেয়। অর্থাৎ ছোট জিনিসগুলো যেগুলোর আসলে প্রধান ফর্ক-পরিচালনাকারী বৈশিষ্ট্য হওয়ার প্রয়োজন নেই। এবং এই পুরো সময় জুড়ে আমাদের বৈশিষ্ট্য-নির্দিষ্ট ডেভনেট থাকে। একটি ডেভনেট হলো টেস্টনেট-এর মতো — ডেভেলপারদের এই বৈশিষ্ট্যগুলো পরীক্ষা করার এবং এগুলো আসলে ইথেরিয়ামে কাজ করছে কিনা তা নিশ্চিত করার জন্য একটি ব্যক্তিগত টেস্ট নেটওয়ার্ক। এবং তারপর এক পর্যায়ে একটি ফিচার ফ্রিজ (feature freeze) হয়। তাই আমরা প্রধান বৈশিষ্ট্যগুলো নিয়ে আলোচনা করেছি, আমরা ছোটখাটো বৈশিষ্ট্যগুলো নিয়ে আলোচনা করেছি, আমরা এই বৈশিষ্ট্য-নির্দিষ্ট ডেভনেটগুলো চালিয়েছি যা সাধারণত ফর্ক হেডলাইনার হয়। এবং এটি একটি তারকাচিহ্নযুক্ত ফিচার ফ্রিজ কারণ সেই সময়ে আমরা সিদ্ধান্ত নিয়েছি যে আমরা এই ফর্ক-এ আর কোনো বৈশিষ্ট্য যুক্ত করব না। আমরা সমস্ত বৈশিষ্ট্য একসাথে চালাব, সবকিছু ঠিক আছে কিনা তা নিশ্চিত করব, কোনো কিছু ভেঙে পড়বে না তা নিশ্চিত করব। কিন্তু যদি কোনো কিছু প্রক্রিয়াটিকে ধীর করে দেয়, যদি ফর্ক বিলম্বিত হয়, যদি এটি খুব জটিল হয়, তবে সেই পর্যায়েও জিনিসগুলো বাদ দেওয়া যেতে পারে।

তাই বেশ কয়েকটি ডেভনেট-এর পরে — এটি 2টি হতে পারে, 10টিও হতে পারে — সমস্ত ক্লায়েন্ট এক পর্যায়ে সিদ্ধান্ত নেয় যে এটি স্থিতিশীল। আমরা এখন যা ঘটছে তা বিশ্বাস করি। আমরা একটি ভালো অবস্থানে আছি। চলুন এটি ইথেরিয়াম মেইননেট-এ নিয়ে আসার কথা ভাবা শুরু করি। তারা ক্লায়েন্ট রিলিজ তৈরি করে এবং তারপর 30 দিনের একটি সময়কাল থাকে যেখানে EF সিকিউরিটি টিম একটি বাগ বাউন্টি (bug bounty) ঘোষণা করে। তারা সিকিউরিটি অডিট-এর চুক্তি করে। এবং তারপর সেই 30 দিনের সময়কাল শেষে আমরা টেস্টনেট-এ ফর্ক চালু করি। এগুলো হলো সেই টেস্টনেট যার কথা আপনি হয়তো শুনে থাকবেন — যেমন Holesky। এখানেই অ্যাপ ডেভেলপাররা ফর্ক লাইভ হওয়ার আগে তাদের জিনিসগুলো পরীক্ষা করতে পারে। এবং সবকিছু ঠিক আছে কিনা তা নিশ্চিত করার জন্য এগুলো সাধারণত প্রতিটিতে ন্যূনতম 14 দিনের জন্য হয়। আমরা কোনো বড় সমস্যার আশা করি না কারণ এটি আগে বৈশিষ্ট্য-নির্দিষ্ট ডেভনেট এবং সাধারণ ডেভনেট-এর মধ্য দিয়ে গেছে, তবে ঐতিহাসিকভাবে এটি এই টেস্টনেটগুলোর কয়েকটিকে ভেঙে দিয়েছে। তাই এই সমস্ত বাগ খুঁজে বের করার এবং সমাধান করার জন্য এটি হলো শেষ সুযোগ।

এবং তারপর একবার পারমিশনলেস টেস্টনেট স্থিতিশীল হলে, মেইননেট-এর তারিখ বেছে নেওয়া হয়। এরপর, 30 দিনের একটি বাফার (buffer) সময় থাকে। এই 30 দিনের বাফারটি রাখা হয় কারণ L2 এবং প্রোটোকলগুলো ফর্ক-এর জন্য প্রস্তুত হওয়ার উদ্দেশ্যে এটি অনুরোধ করেছে। তাই এটি ন্যূনতম 30 দিনের হয় এবং তারপর ফর্ক সম্পন্ন হয়।

কলের কাঠামো এবং সমন্বয় (15:01)

এই পুরো সময় জুড়ে কিছু প্রধান কল সিরিজ চলতে থাকে। এগুলো সবই ইউটিউবে লাইভ-স্ট্রিম করা পাবলিক কল। প্রধানগুলো হলো ACDE এবং ACDC। E হলো এক্সিকিউশন লেয়ার-এর জন্য — যেমন ট্রানজ্যাকশন, স্মার্ট কন্ট্রাক্ট ডিপ্লয়মেন্ট, মেমপুল ম্যানেজমেন্ট। ACDC হলো কনসেনসাস লেয়ার — অর্থাৎ ভ্যালিডেটর ম্যানেজমেন্ট, স্ল্যাশিং-এর মতো ভ্যালিডেটর সংক্রান্ত বিষয়। এবং এগুলো প্রতি বৃহস্পতিবার পর্যায়ক্রমে হয়। তাই প্রতি বৃহস্পতিবার একটি করে ACD হয় এবং এর মধ্যে একটি হলো ACDE এবং তারপরেরটি হলো ACDC, এভাবেই চলতে থাকে।

ACDE এবং ACDC কলগুলো আমরা বর্তমানে যে ফর্কটি তৈরি করছি এবং ভবিষ্যতের জন্য যে ফর্কগুলোর পরিকল্পনা করছি তার উপর ফোকাস করে। ACDT কলগুলো আরও বেশি খুঁটিনাটি বিষয় নিয়ে আলোচনা করে। এগুলো হলো ক্লায়েন্টদের এমন বাগ নিয়ে কথা বলা যা তারা সমাধান করতে পারছে না বা তারা বর্তমানে যে ফর্ক নিয়ে কাজ করছে তার বাস্তবায়নের বিশদ বিবরণ যা সমাধান করা প্রয়োজন। তাই এই মুহূর্তে পরবর্তী যে ফর্কটি হতে যাচ্ছে তা হলো গ্ল্যামস্টারডাম। তাই এই ACDT কলগুলোতে ePBS এবং ব্লক-লেভেল অ্যাক্সেস লিস্ট নিয়ে আলোচনা প্রাধান্য পায় যা গ্ল্যামস্টারডাম-এ যুক্ত হতে যাচ্ছে। এবং এগুলো অত্যন্ত প্রযুক্তিগত কল।

এবং তারপর ব্রেকআউট কল রয়েছে। ব্রেকআউট কল হলো কমিউনিটি সদস্য, গবেষক, ডেভেলপারদের বলা, "আরে, আমার কাছে একটি বৈশিষ্ট্য আছে যা আমি এখন থেকে দুটি ফর্ক পরে ইথেরিয়ামে যুক্ত করতে চাই।" তাই তারা এই সাপ্তাহিক, মাসিক বা দ্বিমাসিক কলগুলোর আয়োজন করে যেখানে তারা বাস্তবায়নের বিশদ বিবরণ নিয়ে আলোচনা করে, স্পেসিফিকেশন পরিবর্তন এবং পুনরাবৃত্তি করে, এবং সাধারণত লোকেদের সমস্ত প্রশ্নের উত্তর দেয়, সমস্ত পরিচিত অজানা বিষয়গুলো সমাধান করে যাতে এটি নিশ্চিত করা যায় যে এটি এখন থেকে দুটি ফর্ক পরে অন্তর্ভুক্ত হওয়ার জন্য সর্বোত্তম সম্ভাব্য স্থানে রয়েছে। এবং ফ্যাসিলিটেটর যখনই সিদ্ধান্ত নেন তখনই এগুলো নির্ধারণ করা যেতে পারে।

একটি বিবর্তনশীল প্রক্রিয়া (15:29)

তাই আমি সবাইকে একটি বিষয় বোঝাতে চাই যে এই প্রক্রিয়াটি কোনোভাবেই স্থির নয়। আমি আপনাদের কাছে এইমাত্র যে প্রক্রিয়াটি বর্ণনা করেছি তা এক বছরেরও কম সময় ধরে লাইভ রয়েছে। ইথেরিয়াম 10 বছর ধরে লাইভ রয়েছে। তবে এটি ক্রমাগত পরিবর্তিত হয় এবং এটি ক্রমাগত পরিবর্তিত হওয়ার কারণ হলো কেউ এর দায়িত্বে নেই। এবং কাজ করার সবচেয়ে কার্যকর উপায় খুঁজে বের করার জন্য এই প্রক্রিয়াটি একরকম বিবর্তিত হয়। এবং আমি যেমন কার্যকর বলছি, কিন্তু ইথেরিয়াম গভর্ন্যান্স-এর যে খ্যাতি রয়েছে তা হলো এটি সত্যিই স্থবির, কোনো কিছু পাস করানো কঠিন, বিভ্রান্তিকর — এবং এর কারণ হলো যখন আপনার কাছে 100 থেকে 500 জন লোক সিদ্ধান্ত নেওয়ার জন্য থাকে, তখন আমি সত্যি বলতে অবাক হই যে এটি আদৌ কাজ করে।

তাই টিম (Tim) 2025 সালের এপ্রিলে "Reconfiguring All Core Devs" নামে একটি পোস্ট করেছিলেন যা শেষ পর্যন্ত বর্তমানে জিনিসগুলো কীভাবে কাজ করে তার প্রস্তাব হয়ে ওঠে। এবং এর কারণ হলো এর আগে ইথেরিয়ামে আমাদের কী ফোকাস করা উচিত সে সম্পর্কে আমাদের এক ধরণের সুসংহত ধারণা ছিল। দ্য মার্জ ছিল যা একটি বিশাল উদ্যোগ ছিল। সবাই খুব উত্তেজিত ছিল। বেশিরভাগ মানুষ খুব উত্তেজিত ছিল। মাইনাররা ছিল না। এবং তারপর দ্য মার্জ-এর পরে, উইথড্রয়াল (withdrawals) ছিল। তাই, আমরা চাইনি যে লোকেদের ETH একটি কন্ট্রাক্ট-এ আটকে থাকুক এবং এই FUD (Fear, Uncertainty, Doubt) তৈরি হোক যে তারা কখনই এখান থেকে ETH বের করতে পারবে না। তাই, আমাদের যত দ্রুত সম্ভব এটি চালু করতে হয়েছিল। এবং তারপর প্রোটো-ড্যাঙ্কশার্ডিং ছিল এবং তারপর পেকট্রা আসে এবং পেকট্রা ছিল বিভিন্ন সম্পর্কহীন EIP-এর একটি সংমিশ্রণ এবং এর সত্যিই কোনো সুসংহত ধারণা ছিললগ্ন। এবং এটি এত বড় হয়ে গিয়েছিল কারণ সমন্বয়ের অভাবে লোকেরা কেবল জিনিসগুলো ঢুকিয়ে দিচ্ছিল যার ফলে এটিকে দুটি ভিন্ন ফর্ক-এ বিভক্ত করতে হয়েছিল কারণ টেস্টিং টিমগুলো অনেকটা এমন ছিল, "এর পরিধি অনেক বড়। আমরা এই সব পরীক্ষা করতে পারব না।"

আর তাই টিমের এটি করার প্রেরণা ছিল, ঠিক আছে, আমাদের এই ফর্কগুলোকে যতটা সম্ভব ফোকাসড এবং সুসংহত রাখার একটি উপায় ভাবতে হবে। এবং হেডলাইনার ছিল এর এক ধরণের উত্তর। এর উদ্দেশ্য ছিল এমনভাবে রিলিজ করা যা অগ্রাধিকার দেয় যাতে মনে হয় সবাই জানে ফর্কটি কী সম্পর্কে, তাই তাদের 25টি ভিন্ন EIP ঢোকাতে হয়নি।

তাই উপরের অন্য স্ক্রিনশটটি হলো টিম এই EIP-গুলোর অন্তর্ভুক্তির পর্যায়গুলোর সংজ্ঞা প্রস্তাব করছেন। এবং আমি এর মাধ্যমে যে বিষয়টি বোঝাতে চাই তা হলো মাঝে মাঝে আপনি লোকেদের বলতে শোনেন যে এই প্রক্রিয়াটি খুব বেশি আমলাতান্ত্রিক। কিন্তু আসলে যা ঘটছে তা হলো লোকেরা এই গভর্ন্যান্স প্রক্রিয়ায় আসে এবং তারা বলে, "আমি কীভাবে একটি EIP যুক্ত করব?" এবং যারা 10 বছর ধরে সেখানে আছেন তারা বলেন, "আপনি কেবল এটি করে ফেলুন।" এবং লোকেরা বলে, "এটি ভয়ানক।" আর তাই এই জিনিসগুলো যা করে তা হলো তারা বর্ণনা করে যে কী ঘটছে যাতে বাইরের লোকেদের এই প্রক্রিয়ায় অংশগ্রহণ করা সহজ হয়, কারণ আপনি যদি কেবল এখানে আসেন এবং বলেন, "আমার কাছে একটি EIP আছে, আমি ইথেরিয়াম গভর্ন্যান্স নিয়ে মাথা ঘামাই না, আমি কেবল এই একটি EIP যুক্ত করতে চাই" — আপনি একটি রুব্রিক চান, আপনি একটি চেকলিস্ট চান, আপনি কীভাবে এই EIP যুক্ত করবেন তার একটি খুব স্পষ্ট ধাপে ধাপে নির্দেশিকা চান। তাই, এই জিনিসগুলোর বেশিরভাগই প্রক্রিয়াটি কীভাবে কাজ করে তা বর্ণনা করার বিষয়ে, এমন আমলাতান্ত্রিক নিয়ম তৈরি করার বিষয়ে নয় যা লোকেদের অনুসরণ করতে হবে যাতে EIP যুক্ত করা কঠিন হয়ে যায়।

তৃতীয় বিষয়টি হলো Forkcast-এ সময়ের সাথে সাথে কমিট (commits)। Forkcast হলো আমার টিমের একটি প্রোডাক্ট, আমার টিমের একজন সদস্য উলফ্রাম মার্ক (Wolfram Mark) এটি গত বছরের মাঝামাঝি সময়ে তৈরি করেছিলেন যখন আমার টিম বর্তমান রূপে গঠিত হয়েছিল। এবং এটি লোকেদের একটি ফর্ক-এর সাথে ইন্টারঅ্যাক্ট করার জন্য, একটি ফর্ক-এ কী যুক্ত হচ্ছে এবং এটি কীভাবে তাদের প্রভাবিত করে তা দেখার জন্য একটি প্রামাণিক সংস্থান হয়ে উঠেছে। এই সমস্ত জিনিস দুই বছরেরও কম পুরানো। তাই আমি কেবল যে বিষয়টি বোঝাতে চাইছি তা হলো এই প্রক্রিয়াটি অনেক পরিবর্তিত হয়। এটি মোটেও স্থির নয়। এটি এমন কোনো হিমায়িত আমলাতন্ত্র নয় যেখানে প্রবেশ করা কঠিন।

তুলনামূলক গভর্ন্যান্স সিস্টেম (20:21)

তাই আমি খুব দ্রুত ইথেরিয়াম গভর্ন্যান্স-এর সাথে সবচেয়ে বেশি মিল রয়েছে এমন বিকেন্দ্রীকৃত গভর্ন্যান্স সিস্টেমগুলো নিয়ে আলোচনা করতে চেয়েছিলাম। এবং আমি এখানে যে বিষয়টি বোঝানোর চেষ্টা করছি তা হলো এটি টেকসই — যদিও এটি আশ্চর্যজনক যে 100 থেকে 500 জন লোক সিদ্ধান্ত নিতে পারে, এটি বাস্তব জগতে টেকসই। আমরা এর কাজ করার উদাহরণ দেখতে পাই।

IETF হলো ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স (Internet Engineering Task Force)। এটি স্বেচ্ছাসেবক-পরিচালিত স্ট্যান্ডার্ড বডি যা TCP/IP, HTTP তৈরি করেছে। আজ আমাদের কাছে যে বিনামূল্যের ইন্টারনেট রয়েছে তার জন্য এই সংস্থাটি সবচেয়ে বেশি দায়ী। লিনাক্স কার্নেল (Linux kernel) — এটি লিনাক্স অপারেটিং সিস্টেমের মূল অংশ। এটি হলো ওপেন-সোর্স সফটওয়্যার যা ইন্টারনেট সার্ভার, অ্যান্ড্রয়েড ফোন, সুপারকম্পিউটার চালায়। সেখানে পার্থক্য হলো লিনাস টরভ্যাল্ডস (Linus Torvalds)-এর সাথে তাদের এক ধরণের হিতৈষী একনায়ক মডেল রয়েছে। কিন্তু তা সত্ত্বেও তাদের 17,000-এরও বেশি অবদানকারী রয়েছে, যা সত্যিই বিস্ময়কর।

যে জিনিসগুলোর সাথে এর মিল নেই: অন্যান্য ব্লকচেইন যাদের অনচেইন টোকেন ভোটিং রয়েছে। ইথেরিয়াম বিশেষভাবে যেকোনো ধরণের ভোটিং মেকানিজম এড়িয়ে চলে কারণ আমার মতে এটি নিয়ন্ত্রণের সুযোগ তৈরি করে এবং এটি জিনিসগুলোকে মেধাভিত্তিক করার প্রণোদনা দূর করে দেয় যেখানে লোকেরা কেবল সেই ব্যক্তিদের বিশ্বাস করে যারা সেরা কোড লেখে। এবং তারপর L2 রয়েছে। তাদের মাল্টি-সিগ (multi-sigs) রয়েছে। তাদের সিকিউরিটি কাউন্সিল রয়েছে। এগুলো অনেকটা নিয়োগপ্রাপ্ত পদের মতো যারা এই সিদ্ধান্তগুলো নেয়। এবং এর নিজস্ব সুবিধা-অসুবিধা রয়েছে। এটি আরও বেশি কেন্দ্রীভূত। তবে এটি দ্রুত কাজ করে।

কেন বিল্ডারদের এটি নিয়ে ভাবা উচিত (22:38)

তাহলে বিল্ডাররা কেন গভর্ন্যান্স নিয়ে মাথা ঘামায়? কারণ আক্ষরিক অর্থেই বিল্ডারদের জন্যই ইথেরিয়াম তৈরি করা হয়েছে। ইথেরিয়াম কোর ডেভেলপারদের জন্য তৈরি করা হয়নি। এটি ভ্যালিডেটরদের জন্য তৈরি করা হয়নি। মাঝে মাঝে এই লোকেরা এটি নিয়ে বিভ্রান্ত হয়। ইথেরিয়াম কোর ডেভেলপার এবং ভ্যালিডেটররা ইথেরিয়ামকে পরিষেবা দেয় যা বিল্ডার এবং ব্যবহারকারীদের পরিষেবা দেয়।

এবং প্রত্যেকেরই AI-এর সাথে এমন মুহূর্ত এসেছে যেখানে আপনি খুব বেশি গভীরে চলে যাচ্ছেন এবং এটি এই ছোট জিনিসটি ঠিক করার চেষ্টা করছে এবং এটি জুম আউট করে প্রজেক্টের পুরো উদ্দেশ্যটি দেখতে ব্যর্থ হয়। এবং কোর ডেভেলপাররাও এমন হতে পারে যেখানে তারা কোর ডেভেলপমেন্ট প্রক্রিয়াটিকে নিখুঁত করার চেষ্টা করছে। এবং সেই ক্ষেত্রে এটি অত্যন্ত গুরুত্বপূর্ণ যে বিল্ডাররা এগিয়ে আসে কারণ কোর ডেভেলপমেন্ট এতটাই সময়সাপেক্ষ যে তারা বেশিরভাগ সময় ইথেরিয়ামের উপরে কিছু তৈরি করে না। তারা কোর ডেভেলপমেন্টে খুব বেশি জড়িত থাকে। এটি তাদের সমস্ত সময় নিয়ে নেয়। আর তাই অ্যাপ বিল্ডারদের সত্যিই এগিয়ে আসার চেষ্টা করতে হবে এবং বলতে হবে, "আরে, আমাদের এটি দরকার। এটি ইথেরিয়ামের জন্য অত্যন্ত গুরুত্বপূর্ণ।" শুধুমাত্র এটি নিশ্চিত করার জন্য যে দৃষ্টিভঙ্গিটি সেখানে রয়েছে এবং তারা কেবল কোর ডেভেলপারদের জন্য কাজ করার মধ্যে সীমাবদ্ধ হয়ে পড়ছে না।

কীভাবে অংশগ্রহণ করবেন (24:40)

তাহলে আপনি কীভাবে অংশগ্রহণ করবেন বা আপনার বৈশিষ্ট্যটি যুক্ত করবেন? এটি এক ধরণের সাধারণ পরামর্শ, তবে আমি মনে করি এটি সেরা। আপনার সমস্যাগুলো নিয়ে সোচ্চার হোন। টুইটারে যান, ব্লগ পোস্ট লিখুন, আপনার সমস্যার সমাধানগুলো চিহ্নিত করুন। আপনাকে সাহায্য করতে পারে এমন জিনিসগুলো নিয়ে অনুমান করুন। আপনি যদি এমন অন্য লোকেদের খুঁজে পান যাদের একই সমস্যা রয়েছে, তবে সাধারণত আপনি এমন একটি EIP খুঁজে পেতে পারেন যা সেই সমস্যা সমাধানের জন্য বিদ্যমান বা এমন কাউকে পেতে পারেন যিনি আপনাকে এমন একটি EIP লিখতে সাহায্য করবেন।

ওপেন-সোর্স সফটওয়্যার সম্পর্কে আমার একটি জিনিস ভালো লাগে তা হলো সাধারণত সুপ্রতিষ্ঠিত কোম্পানিগুলো তাদের ব্যবহার করা ওপেন-সোর্স টুলিং বজায় রাখার জন্য তাদের ডেভেলপমেন্ট সময় এবং সংস্থান বরাদ্দ করবে। এবং শেষ পর্যন্ত এটি বিভিন্ন কোম্পানির একটি গোষ্ঠী হয়ে ওঠে যারা এই জিনিসটি বজায় রাখতে সহযোগিতা করে এবং ইথেরিয়ামেও এটি এভাবেই কাজ করতে পারে। তাই আপনার যদি এমন কোনো সমস্যা থাকে যা আপনি চিহ্নিত করেছেন তবে আপনি একজন Base ডেভেলপার খুঁজে পেতে পারেন যার একই রকম সমস্যা রয়েছে, এবং Base একটি সুপ্রতিষ্ঠিত সংস্থা তাই তারা সম্ভবত একটি বৈশিষ্ট্য রিলিজ করতে বা ইথেরিয়াম হার্ড ফর্ক-এর মাধ্যমে একটি বৈশিষ্ট্য পরিচালনা করতে কিছু সংস্থান বরাদ্দ করতে ইচ্ছুক হবে।

আমি আপনাদের জন্য কিছু সংস্থান রেখে যাচ্ছি। Forkcast.org — সেখানে গিয়ে আপনি দেখতে পারেন যে একটি ফর্ক-এ কী যুক্ত হচ্ছে, এটি কীভাবে নির্দিষ্ট স্টেকহোল্ডারদের প্রভাবিত করে। তাই, আপনি যদি একজন অ্যাপ ডেভেলপার হন, তবে অ্যাপ ডেভেলপারদের জন্য একটি বিভাগ রয়েছে। আপনি যদি একজন ওয়ালেট ডেভেলপার, একজন কনসেনসাস লেয়ার ক্লায়েন্ট ডেভেলপার হন, তবে সেগুলো কীভাবে আপনাকে প্রভাবিত করে সে সম্পর্কে বিভাগ রয়েছে। ইউটিউবে সেই সমস্ত কলের ভিডিও আপলোড করা হয়। সেগুলো forkcast.org/calls পেজেও এম্বেড করা আছে যেখানে সারাংশ, স্পিকার অ্যাট্রিবিউশন রয়েছে, তাই সেই কলগুলো নেভিগেট করা সহজ। EIP ডিরেক্টরি, ইথেরিয়াম ম্যাজিশিয়ানস (Ethereum Magicians) ফোরাম যেখানে আপনি সম্ভাব্য সমাধান বা আপনি যে EIP-গুলো লিখতে চান সে সম্পর্কে অন্যান্য লোকেদের সাথে কথা বলতে পারেন। এবং খুব শীঘ্রই আমার টিমের একটি প্রোটোকল সাপোর্ট সাইট থাকবে। এটি দেখতে দারুণ। এটি এখনও শেয়ার করার জন্য প্রস্তুত নয়। আমার ইমেইলও সেখানে আছে — nixo@ethereum.org (opens email client)। এইটুকুই।