شرح حوكمة إيثيريوم الأساسية

عرض تقديمي بواسطة نيكسو روكيش (Nixo Rokish) من مؤسسة إيثيريوم في إيث بولدر (ETHBoulder)، يشرح حوكمة بروتوكول إيثيريوم الأساسي، وكيفية تنسيق التفرعات الصلبة، والمفاهيم الخاطئة الشائعة حول من يتحكم في إيثيريوم، وكيفية المشاركة في عملية الحوكمة.

هذا النص هو نسخة يسهل الوصول إليها من النص الأصلي للفيديو (opens in a new tab) الذي نشرته إيث بولدر (EthBoulder). تم تعديله بشكل طفيف لتسهيل القراءة.

مقدمة (0:12)

شكرًا لأصدقائي الستة الذين حضروا. حسنًا. سأتحدث إليكم اليوم عن حوكمة إيثيريوم الأساسية. اسمي نيكسو. أقود فريق دعم البروتوكول في مؤسسة إيثيريوم (EF). من بين جميع مهامنا، تتمثل إحدى مهامنا في جعل عملية الحوكمة أكثر وضوحًا وأسهل في التنقل لأي شخص آخر يشارك في هذه الأمور لأن إيثيريوم تتضمن أكثر بكثير من مجرد مطوريها الأساسيين.

إليكم نظرة عامة على المحادثة. سنتحدث عن ماهية الحوكمة الأساسية. وسنتحدث عن المفاهيم الخاطئة، وكيف تعمل حوكمة إيثيريوم حاليًا. وسنتطرق إلى كيفية مقارنتها بأنظمة الحوكمة اللامركزية الأخرى، ولماذا قد يهتم البناة بذلك، والمسارات القابلة للتنفيذ للمشاركة.

إذن، ما هي حوكمة البروتوكول الأساسي؟ أنا أقوم بتشغيل عقدة. ما يعنيه ذلك هو أن لدي قطعة من الأجهزة، جهاز كمبيوتر في منزلي حيث أقوم بتشغيل برنامج إيثيريوم. عندما قمت بإعداد برنامج إيثيريوم هذا، كان علي اختيار العملاء الذين سيقومون بتشغيل هذا البرنامج. تعتبر إيثيريوم فريدة من نوعها من حيث أن لديها عملاء متعددين من أجل تنوع العملاء. الهدف من ذلك هو أنه إذا تعطل أحد العملاء، أو إذا كان هناك خطأ في أحد العملاء، فلن تتعطل الشبكة بأكملها. هناك سلاسل كتل أخرى لديها عملاء آخرون. ومع ذلك، فإن إيثيريوم هي الوحيدة التي تم إعدادها بطريقة تحمينا فعليًا من الأخطاء. لذلك، إذا نظرت إلى شبكة مثل سولانا (Solana)، فإن سولانا لديها عميل آخر، أعتقد أنه يسمى GTO، ولكن نسبة اعتماده تبلغ 20–21% فقط. لذلك، إذا تعطل عميل الأغلبية، تتعطل السلسلة. وقد رأينا شبكات أخرى تتعطل. وهذا هو السبب في أن إيثيريوم هي سلسلة الكتل الأكثر مرونة وأمانًا.

لذا يصبح السؤال هو كيف يمكنك إدخال تغييرات في إيثيريوم عندما يتعين عليك التنسيق مع العديد من العملاء المختلفين. أولاً سنميز بين التفرع الصلب والتفرع المرن. لا يتطلب التفرع المرن التنسيق الذي يتطلبه التفرع الصلب. تعمل إيثيريوم بشكل أساسي مع التفرعات الصلبة. إذن ما هو التفرع الصلب، هو في الأساس قيام جميع العملاء ببناء إصدار جديد من إيثيريوم ويقررون في وقت محدد مسبقًا إطلاق هذا الإصدار الجديد من إيثيريوم. لا تزال إيثيريوم ولكنها تحتوي على ميزات جديدة. لديها ميزات مختلفة. ويجب على جميع مشغلي العقد مثلي الذين يقومون بتشغيل العقد في المنزل أو المشغلين المحترفين قبول هذا الإصدار الجديد من إيثيريوم. يجب عليهم ترقية عقدهم أو تحديثها لتشمل هذا البرنامج الجديد.

إذن كيف يقررون الميزات التي تدخل في تلك التفرعات الصلبة؟ يجب عليهم الاتفاق على الأولويات لتخصيص وقتهم ومواردهم لأن لديهم وقتًا وموارد محدودة لتخصيصها هناك. إنهم يعطون الأولوية لأشياء مثل الثغرات الأمنية أو التصحيحات الأمنية، وأشياء مثل تجربة المستخدم (UX) — إذا كانت هناك سلسلة كتل أخرى تتنافس معنا، فنحن بحاجة إلى أن نصبح قادرين على المنافسة مع سلاسل الكتل الأخرى تلك. لذا فإن أحد الأشياء التي ينظرون إليها هو أن أي ميزة يتم إدخالها يجب أن تكون متوافقة مع عناصر خارطة الطريق المحتملة القادمة.

في العام الماضي حدث شيء مثير للجدل حقًا. ربما سمعت عنه. كان يسمى EOF. وهو اختصار لتنسيق كائنات آلة إيثيريوم الافتراضية (EVM Object Format). كانت تلك مجموعة من الميزات التي كان من المقرر أن تدخل في التفرع الصلب فوساكا — بيكترا، فوساكا، أعتقد كلاهما — ولكن تم تقسيمها. وكان أحد الأسباب من بين العديد من الأسباب التي أدت إلى استبعادها من ذلك التفرع هو أن فيتاليك (Vitalik) نشر منشورًا حول إمكانية اعتماد إيثيريوم لبنية RISC-V. نظر الكثير من الأشخاص الذين كانوا يقرؤون ذلك إليه وقالوا، حسنًا، إذا اعتمدنا RISC-V، فإن الميزات التي نبحث عنها في EOF تأتي بشكل أصلي مع RISC-V. فلماذا نضيف هذا التعقيد إلى البروتوكول؟ لماذا نضع كل موارد مطوري العملاء هذه تجاه هذا الشيء؟ ستكون نقطة غير ذات صلة إذا انتهى بنا الأمر بالانتقال إلى RISC-V.

لذا كان ذلك بمثابة القشة التي قصمت ظهر البعير بالنسبة لـ EOF وانتهى الأمر باستبعادها من التفرع. شيء آخر يجب عليهم مراعاته هو أنه يجب كتابتها واختبارها بدقة بست لغات مختلفة لأن هؤلاء العملاء مكتوبون بست لغات مختلفة. لذا فهذه مصفوفة اختبار كبيرة جدًا بالنسبة لهم للعمل معها. وبسبب ذلك، يخضع كل خيار تصميم صغير للنقاش دون وجود سلطة لحل الخلافات. لذا فإن السؤال الذي يطرح نفسه هو من يقرر — وهو جوهر الحوكمة.

المفاهيم الخاطئة (5:23)

وهذا يقودنا إلى المفاهيم الخاطئة وسنتناول بعضًا منها. أحدها هو أن فيتاليك يقرر ما يدخل في بروتوكول إيثيريوم. وامتداد لذلك هو أن مؤسسة إيثيريوم (EF) تتحكم في كل شيء. والثالث هو أن الأمر كله عبارة عن صفقات في الغرف الخلفية — المطلعون والمخضرمون (OGs) هم من يتخذون هذه القرارات.

إذن الأول: فيتاليك يقرر. لقد اخترت للتو مجموعة فرعية من مقترحات تحسين إيثيريوم (EIPs) الراكدة التي ألفها فيتاليك. ما يعنيه هذا هو أن فيتاليك جلس، وكتب مقترحًا وقال أريد أن تدخل هذه الأشياء في إيثيريوم ولم يوافق أحد — هذه الأشياء مجرد باقية هناك. لم يتمكن من إدخالها في البروتوكول. لذا ليس كل ما يقترحه يتم تضمينه تلقائيًا.

أحد امتدادات ذلك هو أن مؤسسة إيثيريوم تتحكم في كل شيء. سأختار مثالاً محددًا لوقت أعتقد أنه يتناقض مع ذلك. في عام 2024 كان هناك الكثير من الحديث حول حد الغاز. والسبب في ذلك هو أنه في عام 2022 أثناء الدمج قمنا برفع حد الغاز إلى 30 مليون. هذا هو الحد الأقصى للحساب المسموح به في كتلة. ثم لم نلمسه لفترة من الوقت لأنه لم يكن حقًا عنق زجاجة يجعل الناس يقولون، "هذا هو سبب عدم انتقالي إلى إيثيريوم" أو "هذا يقيد حالة الاستخدام الحالية الخاصة بي لإيثيريوم."

وفي أواخر عام 2023، وأوائل عام 2024، كانت هناك هذه السردية بأن سولانا قادمة. وأنها ستتفوق على إيثيريوم. ولذا كان الناس يفكرون فيما يمكن أن تفعله إيثيريوم للتسريع. وكان أحد الأشياء هو دعونا نرفع مقياس الغاز هذا. وفي ذلك الوقت كانت مؤسسة إيثيريوم ومطورو العملاء يقولون نوعًا ما، "لدينا أشياء أخرى لنقلق بشأنها. شكرًا على أي حال." ولكن هذين الشخصين، إريك كونور (Eric Connor) وماريانو كونتي (Mariano Conti)، تدخلا وقالا، "لا، سنقوم برفع حد الغاز." حد الغاز هو معلمة يتحكم فيها المُدَقِّق. ولذا يمكنهم فقط البدء في التحدث إلى المُدَقِّقين، والمشغلين المحترفين، والقول، "مرحبًا، ارفعوا حد الغاز الخاص بكم."

وفي مرحلة ما كان هناك اعتماد كافٍ لدرجة أن مؤسسة إيثيريوم والعملاء قالوا، "أوه، يجب أن ننتبه لهذا. يجب أن نتأكد من أن ما يفعلونه آمن وأن القيمة التي سينتهي بهم الأمر برفع هذا إليها ستكون شيئًا آمنًا للشبكة." لذلك، كان عليهم إعادة تخصيص مواردهم. ابتكر نيذرميند (Nethermind) إطار الاختبار هذا. قامت مؤسسة إيثيريوم بالكثير من العمل في برلين. كان جميع مطوري العملاء يقومون بقياس أداء هذا. ولذا يعجبني هذا لأنه أجبر مؤسسة إيثيريوم على اتخاذ قرار بشأن ما تم إعطاؤه الأولوية.

وتعجبني هذه التغريدة الغبية التي التقطت لها صورة شاشة هنا لأنها تبدو وكأن بعض المنافذ الإخبارية العشوائية تطلق على إريك كونور وماريانو كونتي لقب مطورين أساسيين. إنهم ليسوا مطورين أساسيين. كان إريك كونور متعهد حصص (staker) وعضوًا في المجتمع. وكان ماريانو كونتي مطور تطبيقات سابقًا في MakerDAO. ولكن تم إطلاق لقب مطورين أساسيين عليهم فقط لأن تطوير إيثيريوم يقع حقًا خارج عالم كيفية عمل البرامج التقليدية ولذا رأوا معلمة أساسية يتم تعديلها وقالوا، "أوه، لابد أن هؤلاء مطورون أساسيون." لم يكونوا كذلك. لذا فهذا مجرد مثال لأعضاء المجتمع الذين يتدخلون ويقولون إننا نريد أن نرى هذا التغيير ويجعلونه يحدث.

الأمر كله عبارة عن صفقات في الغرف الخلفية، ومطلعين، ومخضرمين — أفهم قليلاً لماذا يعد هذا مفهومًا خاطئًا لأنك تأتي أساسًا إلى مكالمات الحوكمة هذه، وهناك مائة شخص في مكالمات الحوكمة هذه. يبدو أنهم جميعًا مرتاحون جدًا لما يجري. وأنت ضائع. ليس لديك أي فكرة عن كيفية اتخاذ هذه القرارات. وتقول في نفسك، "هل حان دوري للتحدث بعد؟" ويبدو الأمر وكأن الناس يستمعون إلى نفس الأشخاص العشرة لاتخاذ هذه القرارات.

الجدارة وإحصاءات المشاركة (10:18)

لكن الحقيقة هي أن تطوير إيثيريوم يعتمد على الجدارة أكثر مما رأيته في معظم عمليات تطوير البرمجيات. كل هؤلاء الأشخاص في لقطة الشاشة هذه — هذه واحدة من ثلاث لقطات في مكالمة مطوري النواة (ACD) العشوائية هذه التي قررت التقاطها — لم يتم تعيين أي من هؤلاء الأشخاص ليكونوا هنا. الجميع هم نوعًا ما الأشخاص الذين حضروا. إنهم المطورون الذين أمضوا الكثير من الوقت مع هذا البروتوكول. إنهم الأشخاص الذين اعترف الناس بأنهم مطورون موهوبون في هذا المجال يتخذون قرارات جيدة باستمرار، ولا يوجد أحد في هذا تم تعيينه ليكون هنا.

لذا فقد انضممت إلى مؤسسة إيثيريوم منذ أكثر من عام بقليل. لقد حصلت على هذه الإحصائيات. إنها تعود فقط إلى مارس 2025. أي أقل من عام. متوسط الحضور في مكالمات جميع المطورين الأساسيين (All Core Dev) — وهي مكالمات الحوكمة — هو 98. لذا في المتوسط هناك 98 شخصًا في هذه المكالمات. كان الحد الأقصى للحضور في مكالمة واحدة منذ ذلك الحين هو 153. أعتقد أن ذلك كان اليوم الذي كنا نقرر فيه تاريخ إطلاق بيكترا على الشبكة الرئيسية. وإجمالي الحضور الفريدين هو 567 في العام الماضي فقط. يعجبني هذا المقياس حقًا لأنه يوضح أنه ليس نفس الـ 100 شخص الذين يذهبون إلى هذه المكالمات في كل مرة. هؤلاء مطورو التطبيقات، والباحثون، وشخص يسمع عن ميزة ما تتم مناقشتها، فيحضرون للتعبير عن معارضتهم لها أو دعمهم لها ثم لا يأتون إلى مكالمة أخرى.

كيف تعمل عملية الحوكمة (11:52)

لذا فهذه شريحة جافة نوعًا ما ولكن أعتقد أنه من المهم المرور عليها — هكذا تعمل حوكمة إيثيريوم حاليًا. لذلك عندما تتم مناقشة أحد هذه التفرعات، فإن أول شيء يحدث هو أن الأشخاص خلال هذه النافذة الزمنية المخصصة قادرون على تقديم مقترحهم الرئيسي. المقترح الرئيسي هو الميزة الرئيسية التي نريد أن يلتف الناس حولها لهذا التفرع. يمكن أن يكون هذا عضوًا في المجتمع، أو باحثًا، أو مطورًا أساسيًا — في الواقع أي شخص يقدم أحد هذه المقترحات الرئيسية. ثم تنتهي النافذة وفي مكالمات الحوكمة نناقش نوعًا ما أيًا من هذه المقترحات منطقي. يقدم الناس حججهم، ويتجادلون وهناك إجماع حول أي منها يجب أن نختاره لذلك التفرع القادم.

بعد ذلك يختارون الميزات الثانوية. أي الأشياء الأصغر التي لا تحتاج حقًا إلى أن تكون هذه الميزات الرئيسية الدافعة للتفرع. وطوال هذا الوقت لدينا شبكات تطوير خاصة بالميزات. شبكة التطوير تشبه شبكة اختبار — شبكة اختبار خاصة للمطورين لاختبار هذه الميزات والتأكد من أنها تعمل بالفعل على إيثيريوم. ثم في مرحلة ما يكون هناك تجميد للميزات. لذلك ناقشنا الميزات الرئيسية، وناقشنا الميزات الثانوية، وقمنا بتشغيل شبكات التطوير الخاصة بالميزات والتي عادة ما تكون العناوين الرئيسية للتفرع. وهذا تجميد للميزات مع علامة نجمية لأنه في تلك المرحلة قررنا أننا لن نضيف أي ميزات أخرى إلى هذا التفرع. سنقوم بتشغيل جميع الميزات معًا، ونتأكد من أن كل شيء جيد، ونتأكد من عدم تعطل أي شيء. ولكن إذا بدأ شيء ما في إبطاء الأمور، أو إذا تأخر التفرع، أو إذا كان معقدًا للغاية، فلا يزال من الممكن استبعاد الأشياء في تلك المرحلة.

لذا بعد عدد من شبكات التطوير — قد يكون هناك اثنتان، وقد يكون هناك 10 — يقرر جميع العملاء في مرحلة ما أن هذا مستقر. نحن نثق بما يجري الآن. نحن في وضع جيد. لنبدأ في التفكير في إخراج هذا إلى شبكة إيثيريوم الرئيسية. يقومون بإصدار نسخ العملاء ثم تكون هناك فترة مدتها 30 يومًا حيث يطرح فريق الأمان في مؤسسة إيثيريوم مكافأة لاكتشاف الأخطاء. ويتعاقدون على عمليات تدقيق أمني. ثم في نهاية فترة الـ 30 يومًا تلك، نطلق التفرع على شبكات الاختبار. هذه هي شبكات الاختبار التي ربما سمعت عنها — مثل Holesky. هذا هو المكان الذي يمكن لمطوري التطبيقات فيه اختبار أشيائهم قبل بدء تشغيل التفرع. وهذه بشكل عام لا تقل عن 14 يومًا لكل منها فقط للتأكد من أن كل شيء على ما يرام. لا نتوقع أي مشاكل كبيرة لأنه مر عبر شبكات تطوير خاصة بالميزات وشبكات تطوير معممة من قبل، ولكن تاريخيًا أدى ذلك إلى تعطل بعض شبكات الاختبار هذه. ولذا فهذه نوعًا ما هي الفرصة الأخيرة للعثور على جميع هذه الأخطاء والقضاء عليها.

ثم بمجرد استقرار شبكة الاختبار غير المقيدة بإذن، يتم اختيار تاريخ الشبكة الرئيسية. بعد ذلك، هناك فترة عازلة مدتها 30 يومًا. توجد هذه الفترة العازلة البالغة 30 يومًا لأن شبكات الطبقة الثانية (L2s) والبروتوكولات طلبت ذلك من أجل الاستعداد للتفرع. لذا فهذا كحد أدنى 30 يومًا ثم يحدث التفرع.

هيكل المكالمات والتنسيق (15:01)

خلال هذا الوقت كله، تحدث بعض سلاسل المكالمات الرئيسية. هذه كلها مكالمات عامة يتم بثها مباشرة على يوتيوب (YouTube). المكالمات الرئيسية هي ACDE و ACDC. يرمز حرف E إلى طبقة التنفيذ — وهي أشياء مثل المعاملات، ونشر العقود الذكية، وإدارة مجمع الذاكرة. و ACDC هي طبقة الإجماع — لذا فهذه أشياء تخص المُدَقِّق مثل إدارة المُدَقِّقين، والاقتطاع. ويتم التناوب بينها أيام الخميس. لذا هناك مكالمة ACD كل يوم خميس وإحداها هي ACDE ثم التالية هي ACDC، وتستمر على هذا النحو.

تركز مكالمات ACDE و ACDC على التفرع الذي نقوم به حاليًا والتفرعات التي نخطط لها في المستقبل. مكالمات ACDT أكثر تعمقًا في التفاصيل الدقيقة. إنها عبارة عن حديث العملاء عن الأخطاء التي لا يمكنهم تجاوزها أو تفاصيل التنفيذ التي يجب حلها حول التفرع الذي يعملون عليه حاليًا. لذا في الوقت الحالي، التفرع التالي الذي سيحدث هو غلامستردام. لذا تهيمن على مكالمات ACDT هذه المحادثات حول ePBS وقوائم الوصول على مستوى الكتلة وهي الأشياء التي ستدخل في غلامستردام. وهذه هي المكالمات التقنية للغاية.

ثم هناك مكالمات فرعية. المكالمات الفرعية هي أعضاء المجتمع، والباحثون، والمطورون الذين يقولون، "مرحبًا، لدي ميزة أريد إدخالها في إيثيريوم بعد تفرعين من الآن." ولذا فهم يستضيفون هذه المكالمات الأسبوعية أو الشهرية أو نصف الشهرية حيث يناقشون تفاصيل التنفيذ، ويغيرون ويكررون المواصفات، ويتناولون بشكل عام جميع الأسئلة التي لدى الناس، وجميع المجاهيل المعروفة للتأكد من أنها في أفضل مكان ممكن ليتم تضمينها في التفرع بعد تفرعين من الآن. ويمكن جدولة هذه المكالمات متى قرر الميسر ذلك.

عملية متطورة (15:29)

لذا فإن أحد الأشياء التي أريد أن أؤكد عليها للجميع هو أن هذه العملية ليست ثابتة على الإطلاق. هذه العملية التي وصفتها لكم للتو كانت نشطة لأقل من عام. إيثيريوم نشطة منذ 10 سنوات. لكنها تتغير باستمرار والسبب في تغيرها المستمر هو أنه لا يوجد أحد مسؤول. وهذه العملية تتطور نوعًا ما لمعرفة الطريقة الأكثر كفاءة للعمل. وكما أقول كفؤة، لكن السمعة التي تتمتع بها حوكمة إيثيريوم هي أنها راكدة حقًا، ومن الصعب تمرير الأشياء، ومربكة — وذلك لأنه عندما يكون لديك 100 إلى 500 شخص يتخذون القرارات، فأنا معجب بصراحة بأن هذا يعمل على الإطلاق.

لذا نشر تيم (Tim) منشورًا في أبريل من عام 2025 بعنوان "إعادة تكوين جميع المطورين الأساسيين" والذي انتهى به الأمر ليكون المقترح لكيفية عمل الأشياء في الوقت الحالي. والسبب في ذلك هو أنه قبل ذلك كان لدينا نوعًا ما هذه السردية المتماسكة حول ما يجب أن نركز عليه في إيثيريوم. كان هناك الدمج الذي كان مهمة ضخمة. كان الجميع متحمسين للغاية. كان معظم الناس متحمسين للغاية. لم يكن المعدنون كذلك. ثم بعد الدمج، كان لديك عمليات السحب. لذلك، لم نكن نريد أن يتم قفل ETH الخاص بالأشخاص في عقد وأن يكون هذا الخوف وعدم اليقين والشك (FUD) وكأنهم لن يخرجوا ETH من هذا أبدًا. لذلك، كان علينا شحن ذلك في أسرع وقت ممكن. ثم كان هناك بروتو-دانكشاردينغ ثم جاءت بيكترا وكانت بيكترا نوعًا ما هذا المزيج من مقترحات تحسين إيثيريوم (EIPs) المختلفة غير ذات الصلة ولم يكن لديها حقًا سردية متماسكة. وأصبحت كبيرة جدًا لأن الناس كانوا نوعًا ما يحشرون الأشياء بسبب الافتقار إلى التماسك لدرجة أنه كان لا بد من تقسيمها إلى تفرعين مختلفين لأن فرق الاختبار كانت تقول نوعًا ما، "النطاق كبير جدًا. لا يمكننا اختبار كل هذا."

ولذا كان دافع تيم للقيام بذلك هو، حسنًا، نحن بحاجة إلى التفكير في طريقة للحفاظ على هذه التفرعات مركزة ومتماسكة قدر الإمكان. وكان المقترح الرئيسي نوعًا ما هو الإجابة على ذلك. كان الهدف من ذلك هو الشحن بطريقة تعطي الأولوية لجعل الأمر يبدو وكأن الجميع يعرفون ما يدور حوله التفرع، لذلك لم يضطروا إلى حشر 25 مقترح تحسين إيثيريوم (EIP) مختلفًا.

لذا فإن لقطة الشاشة الأخرى في الأعلى هي اقتراح تيم لتعريفات لمراحل التضمين لمقترحات تحسين إيثيريوم (EIPs) هذه. والنقطة التي أريد توضيحها بهذا هي أنك تسمع أحيانًا أشخاصًا يقولون إن هذه العملية بيروقراطية للغاية. ولكن ما يحدث حقًا هو أن الناس يدخلون في عملية الحوكمة هذه ويقولون، "كيف يمكنني إدخال مقترح تحسين إيثيريوم (EIP)؟" والأشخاص الذين كانوا هناك لمدة 10 سنوات يقولون، "أنت تفعل ذلك وحسب." ويقول الناس، "هذا فظيع." ولذا فإن ما تفعله هذه الأشياء هو أنها تصف ما يحدث لتسهيل مشاركة الغرباء في هذه العملية، لأنه إذا كنت قادمًا إلى هنا للتو وتقول، "لدي مقترح تحسين إيثيريوم (EIP) واحد، لا أهتم بحوكمة إيثيريوم، أريد فقط إدخال هذا المقترح" — فأنت تريد معيارًا، وتريد قائمة تحقق، وتريد خطوة بخطوة واضحة جدًا حول كيفية إدخال هذا المقترح. لذا، فإن معظم هذه الأشياء تتعلق بوصف كيفية عمل العملية أكثر من إنشاء قواعد بيروقراطية يجب على الناس اتباعها لجعل من الصعب إدخال مقترحات تحسين إيثيريوم (EIPs).

الشيء الثالث هو الالتزامات (commits) بمرور الوقت على Forkcast. Forkcast هو منتج من فريقي، بواسطة وولفرام مارك (Wolfram Mark)، وهو شخص في فريقي أنشأ هذا في منتصف العام الماضي عندما تم تشكيل فريقي في نسخته الحالية. وقد أصبح موردًا أساسيًا للناس لاستخدامه للتفاعل مع التفرع، لمعرفة ما يدخل في التفرع وكيف يؤثر عليهم. كل هذه الأشياء عمرها أقل من عامين. لذا فإن النقطة التي أوضحها هي أن هذه العملية تتغير كثيرًا. إنها ليست ثابتة على الإطلاق. إنها ليست بيروقراطية مجمدة يصعب الدخول إليها.

أنظمة الحوكمة القابلة للمقارنة (20:21)

لذا وبسرعة أردت التطرق إلى أنظمة الحوكمة اللامركزية الأكثر تشابهًا التي يمكنني رؤيتها مع حوكمة إيثيريوم. والنقطة التي أحاول توضيحها هنا هي أن هذا مستدام — على الرغم من أنه من المدهش أن 100 إلى 500 شخص يمكنهم اتخاذ القرارات، إلا أنه مستدام في العالم الحقيقي. نحن نرى أمثلة على نجاح هذا.

فريق هندسة الإنترنت (IETF) هو هيئة المعايير التي يديرها متطوعون والتي أنشأت TCP/IP و HTTP. إنها المنظمة الأكثر مسؤولية عن حقيقة أن لدينا إنترنت مجاني اليوم. نواة لينكس (Linux kernel) — إنها جوهر نظام تشغيل لينكس. لذا فهذا برنامج مفتوح المصدر يعمل على تشغيل خوادم الإنترنت، وهواتف أندرويد، وأجهزة الكمبيوتر العملاقة. الاختلاف هناك هو أن لديهم نوعًا من نموذج الديكتاتور الخيّر مع لينوس تورفالدس (Linus Torvalds). ولكن حتى مع ذلك، لديهم أكثر من 17,000 مساهم، وهو أمر مذهل.

الأشياء التي لا يشبهها هذا: سلاسل الكتل الأخرى التي لديها تصويت بالرموز المميزة على السلسلة. تتجنب إيثيريوم تحديدًا أي نوع من آليات التصويت لأنه في رأيي يؤدي ذلك إلى سبل للاستحواذ ويتخلص نوعًا ما من الحافز لجعل الأشياء تعتمد على الجدارة حيث يثق الناس فقط في الأشخاص الذين يكتبون أفضل كود. ثم هناك شبكات الطبقة الثانية (L2s). لديهم محافظ متعددة التوقيعات (multi-sigs). لديهم مجالس أمنية. هذه أشبه بمناصب معينة تتخذ هذه القرارات. وهذا له مقايضاته. إنه أكثر مركزية. لكنه يتحرك بشكل أسرع.

لماذا يهتم البناة (22:38)

إذن لماذا يهتم البناة بالحوكمة؟ لأن البناة هم حرفيًا من تم إنشاء إيثيريوم من أجلهم. لم يتم إنشاء إيثيريوم للمطورين الأساسيين. ولم يتم إنشاؤها للمُدَقِّقين. أحيانًا يرتبك هؤلاء الأشخاص بشأن ذلك. يخدم مطورو إيثيريوم الأساسيون والمُدَقِّقون إيثيريوم التي تخدم البناة والمستخدمين.

وقد مر الجميع بتلك اللحظة مع الذكاء الاصطناعي حيث تتعمق كثيرًا في التفاصيل ويحاول إصلاح هذا الشيء الصغير ويفشل في التراجع والنظر إلى الغرض الكامل من المشروع. ويمكن أن يكون المطورون الأساسيون هكذا حيث يحاولون إتقان عملية التطوير الأساسية. ومن الأهمية بمكان في هذه الحالة أن يتدخل البناة لأن التطوير الأساسي يستهلك الكثير من الوقت لدرجة أنهم لا يبنون أيضًا فوق إيثيريوم في معظم الأوقات. إنهم منخرطون جدًا في التطوير الأساسي. إنه يستهلك كل وقتهم. ولذا يتعين على بناة التطبيقات حقًا بذل جهد للتدخل والقول، "مرحبًا، نحن بحاجة إلى هذا. هذا أمر بالغ الأهمية لإيثيريوم." فقط للتأكد من وجود المنظور وأنهم لا يتم حصرهم في العمل فقط من أجل المطورين الأساسيين.

كيفية المشاركة (24:40)

إذن كيف تشارك أو تُدخل ميزتك؟ هذه نصيحة عامة نوعًا ما، لكنني أعتقد أنها الأفضل. كن صريحًا بشأن نقاط الصعوبة التي تواجهك. اذهب إلى تويتر (Twitter)، واكتب منشورات مدونة، وحدد حلولاً لنقاط الصعوبة الخاصة بك. تكهن بالأشياء التي يمكن أن تساعدك. إذا وجدت أشخاصًا آخرين لديهم نفس نقاط الصعوبة، فيمكنك عمومًا العثور على مقترح تحسين إيثيريوم (EIP) موجود لمعالجة نقطة الصعوبة تلك أو اطلب من شخص ما مساعدتك في كتابة مقترح تحسين إيثيريوم (EIP) يفعل ذلك.

أحد الأشياء التي تعجبني في البرمجيات مفتوحة المصدر هو أن الشركات ذات رأس المال الجيد بشكل عام ستخصص وقت مطوريها ومواردها للحفاظ على الأدوات مفتوحة المصدر التي يستخدمونها. وينتهي الأمر بمجموعة من الشركات المختلفة التي تتعاون في الحفاظ على هذا الشيء ويمكن أن يكون هذا هو الحال في إيثيريوم أيضًا. لذا إذا كانت لديك نقطة صعوبة حددتها، فيمكنك العثور على مطور في Base لديه نقطة صعوبة مماثلة، و Base هي منظمة ذات رأس مال جيد ولذا فمن المحتمل أن يكونوا على استعداد لتخصيص بعض الموارد لشحن ميزة أو توجيه ميزة من خلال تفرع صلب في إيثيريوم.

سأترك لكم بعض الموارد. Forkcast.org — هذا هو المكان الذي يمكنك الذهاب إليه وإلقاء نظرة على ما يدخل في التفرع، وكيف يؤثر على أصحاب مصلحة معينين. لذا، إذا كنت مطور تطبيقات، فهناك قسم لمطوري التطبيقات. إذا كنت مطور محفظة، أو مطور عميل طبقة الإجماع، فهناك أقسام حول كيفية تأثير كل ذلك عليك. يوتيوب (YouTube) هو المكان الذي يتم فيه تحميل جميع مقاطع فيديو المكالمات تلك. وهي مضمنة أيضًا في صفحة forkcast.org/calls حيث توجد ملخصات، وإسنادات للمتحدثين، لذلك من الأسهل التنقل في تلك المكالمات. دليل مقترحات تحسين إيثيريوم (EIPs)، ومنتدى سحرة إيثيريوم (Ethereum Magicians) حيث يمكنك الذهاب للتحدث إلى أشخاص آخرين حول الحلول المحتملة أو مقترحات تحسين إيثيريوم (EIPs) التي تريد كتابتها. وقريبًا جدًا سيكون لدى فريقي موقع لدعم البروتوكول. يبدو رائعًا. إنه ليس جاهزًا للمشاركة. بريدي الإلكتروني موجود هناك أيضًا — nixo@ethereum.org (opens email client). هذا كل شيء.