مع زيادة استخدام الإيثريوم، يصبح تشغيل العقدة الكاملة أكثر تطلبًا للموارد وعرض النطاق الترددي. ويؤدي هذا إلى انخفاض عدد الأشخاص القادرين على تشغيل العقد الكاملة، مما يجعل الشبكة أقل لامركزية. بالإضافة إلى ذلك، تواجه إيثريوم صعوبات في التوسع مع زيادة الطلب على المعاملات، مما يؤدي إلى ازدحام الشبكة وارتفاع رسوم الغاز.
قم بالتسجيل في البورصات الثلاثة الرئيسية في دائرة العملات (انسخ الرابط وافتحه في المتصفح)
https://www.communityrebate.com
يقدم العميل عديم الجنسية الذي اقترحه Vitalik في عام 2017 حلاً محتملاً لتحديات اللامركزية التي تواجه Ethereum. الفكرة الأساسية للعميل عديم الجنسية هي تقليل متطلبات التخزين وعرض النطاق الترددي المطلوبة لتشغيل عقدة كاملة، وتمكين المزيد من الأشخاص من المشاركة وتحقيق اللامركزية في الشبكة. ستلقي هذه المقالة نظرة متعمقة على كيفية عمل العملاء عديمي الجنسية ومزاياهم وعيوبهم المحتملة.
ما هي حالة إيثيريوم؟
لفهم العميل عديم الحالة، نحتاج أولًا إلى فهم مفهوم «الحالة» في إيثيريوم. تشير حالة إيثيريوم إلى الحالة الحالية لجميع الحسابات والعقود والأرصدة وnonce والتخزين في عالم إيثيريوم. ويمكن اعتبارها قاعدة بيانات تحتوي على جميع المعلومات ذات الصلة بالشبكة في نقطة زمنية محددة.
يتم تخزين الحالة بشكل دائم على هيئة Merkle Patricia trie، وهو في الأساس شجرة ميركل مُعدلة تُستخدم لتخزين أزواج key-value. تُلخص التجزئة الجذرية (root hash) لهذه الـtrie الحالة بأكملها. عند كل كتلة جديدة، يتم تحديث الحالة بناءً على المعاملات الموجودة في تلك الكتلة. تتضمن تجزئة جذر الحالة الجديدة في رأس الكتلة.
مع مرور الوقت، ومع إضافة المزيد من الحسابات والعقود والمعاملات، أصبحت حالة إيثيريوم أكبر وأكبر. حاليًا، يتجاوز حجم الحالة 1TB، ويزداد بمئات عشرات الجيجابايت سنويًا. إن هذا النمو المتواصل للحالة هو السبب الجذري لمشكلة اللامركزية.
لماذا يسبب نمو الحالة مشكلة
يؤدي ازدياد حجم حالة إيثيريوم إلى بعض المشكلات الرئيسية:
● وقت مزامنة طويل للعقد الجديدة — يستغرق مزامنة العقد الجديدة لكل تغييرات الحالة التاريخية وقتًا طويلًا. يزيد ذلك من صعوبة تشغيل عقد كاملة جديدة، ويعيق لا مركزية الشبكة. إن مزامنة العقد الجديدة من كتلة التكوين (genesis) حتى الحالة الأحدث حاليًا تستغرق عدة أيام، وربما أسابيع، وهي عقبة رئيسية أمام مشغّلي الأجهزة لدى المستهلكين لبدء عقد جديدة بشكل فعّال والسماح بمشاركة المزيد من الأفراد في الشبكة.
● زيادة متطلبات العتاد — تتطلب الحالة الأكبر مزيدًا من التخزين والذاكرة وقدرات المعالجة لتخزين الحالة والوصول إليها وتحديثها. وهذا يمنع المستخدمين ذوي الموارد المحدودة من تشغيل العقد. يتطلب تشغيل عقد إيثيريوم كاملة متزامنة بالكامل حاليًا — على الأقل — SSD بسعة 1-2TB. وهذا غير متاح للعديد من مشغّلي العقد المحتملين.
● زيادة استخدام النطاق العريض — يجب أن يتضمن بث الكتلة الجديدة أيضًا تحديثات الحالة المحدثة، ما يتطلب نطاقًا عريضًا أكبر. هذا يزيد تكلفة مشغّلي العقد. حاليًا، تهيمن الحالة على معظم بث الكتل، لذلك تستمر أحجام الكتل في الزيادة. مزيد من النطاق العريض يعني تكلفة أعلى على مشغّلي العقد.
● التحقق من الكتل بشكل أبطأ — قراءة وتحديث حالة أكبر يجعل التحقق من الكتل أبطأ، ما يحد من إنتاجية المعاملات. كل معاملة تتطلب عدة عمليات قراءة وكتابة للتخزين لتحديث الرصيد وnonce وحالة العقود وغيرها. تعني الحالة الأكبر قراءات/كتابات أكثر لكل كتلة، ما يقلل عدد المعاملات التي يمكن معالجتها في كل ثانية.
● تكلفة التخزين الدائم — بمجرد إضافة البيانات إلى الحالة، يجب تخزينها بشكل دائم. يؤدي ذلك إلى نمو حالة غير محدد (unbounded). لا توجد حاليًا آلية لحذف تلقائي للبيانات القديمة وغير المستخدمة. لذلك، طالما تستمر إيثيريوم في العمل، ستزداد تكلفة الاحتفاظ بالحالة بشكل لا نهائي.
ما هو العميل عديم الحالة
يوفر العميل عديم الحالة طريقة للتحقق من الكتل الجديدة دون الحاجة إلى الوصول إلى الحالة الكاملة لإيثيريوم. يستخدمون براهين تشفيرية تُسمى «witnesses» لإثبات صحة تغييرات الحالة داخل الكتلة، دون الحاجة إلى بيانات حالة محددة.
يعمل العميل عديم الحالة على النحو التالي:
1، يحتفظ العميل فقط برؤوس الكتل وجذور الحالة، وليس ببيانات الحالة الكاملة. تتضمن رؤوس الكتل بيانات وصفية مثل تجزئة الجذر لشجرة (trie) الحالة بعد معالجة هذه الكتلة.
2، عند التحقق من كتلة جديدة، يستقبل العميل مع الكتلة «witness». هذا الـwitness عبارة عن مجموعة من براهين ميركل (Merkle proofs) تثبت أن تحديثًا معيّنًا للحالة داخل المعاملة صالح.
3، يحتوي الـwitness على برهان ميركل (Merkle proof) لقيم حالة محددة، يُستخدم لمعالجة المعاملة. على سبيل المثال، تحديث رصيد حساب أو تخزين عقد.
4، يستخدم العميل الـwitness لضمان صحة المعاملة بالنسبة إلى جذر الحالة المعروف آخرًا. تتحقق عملية التحقق من البراهين من تغييرات الحالة وتتأكد أنها تطابق الجذر السابق.
5، إذا كان ذلك فعالًا، يقوم العميل بتحديث «جذر الحالة» الجديد المقدم في رأس الكتلة. سيتم استخدام جذر الحالة هذا للتحقق من الكتلة التالية.
باستخدام الـwitness للتحقق من الحالة بدلًا من تخزين الحالة الكاملة محليًا، يحصل العميل عديم الحالة على بعض المزايا:
● وقت مزامنة سريع جدًا — دون الحاجة إلى مزامنة كاملة لتغييرات الحالة التاريخية. يمكن للعميل عديم الحالة أن يزامن تقريبًا فورًا، ولا يحتاج سوى إلى رؤوس الكتل.
● متطلبات تخزين منخفضة — جذر الحالة هو 32 بايت فقط. بدلًا من مئات الجيجابايت من الحالة، يكفي وجود رأس الكتلة.
● استخدام نطاق عريض أقل — يتم نقل رؤوس الكتل وwitnesses فقط، بدلًا من الحالة الكاملة. تقليل استخدام النطاق العريض.
● تحقق سريع — تحتوي الـwitnesses فقط على مجموعة صغيرة مرتبطة من بيانات الحالة. فهي لا تُثبت إلا الحسابات/التخزين التي تم تحديثها بشكل مفيد.
● دعم سهل للعملاء الخفيفين — يمكن للعملاء الخفيفين التحقق من البراهين بسهولة. نموذج العميل عديم الحالة متوافق جدًا مع التحقق عديم الحالة.
تحديات العميل عديم الحالة
على الرغم من أن العميل عديم الحالة يجلب بعض المزايا الكبيرة، إلا أنه توجد أيضًا بعض التحديات التقنية الواضحة:
● حجم الـwitness — قد تكون الـwitnesses كبيرة جدًا بحيث لا يمكن نقلها بكفاءة. إذا تم استخدام براهين ميركل كاملة، فقد تتجاوز حدود حجم الكتلة.
● إنشاء الـwitness — توليد أفضل witness بالنسبة لمقترح الكتلة أمر معقد. يجب على المقترح تجميع أجزاء صحيحة من البراهين للتحقق من كل معاملة.
● لا توجد حوافز للـwitness — لا توجد مكافأة مباشرة لتقديم witness. وعلى عكس التعدين، لا يوجد آلية حوافز مدمجة لإنشاء الـwitness.
● بيانات مؤقتة — تقوم الـwitnesses بإثبات الحالة عند نقطة زمنية معينة، وتحتاج إلى إعادة توليد. لا يمكن إعادة استخدام الـwitness أثناء تطور الحالة.
● تخزين الحالة — ما يزال هناك من يجب أن يحافظ على الحالة الكاملة من أجل توليد الـwitness. يعتمد التحقق عديم الحالة على توليد الـwitness من حالة ذات حالة (stateful).
● تطبيقات معقدة — قد تعتمد بعض العقود على مجموعات كبيرة من بيانات الحالة، ما يجعل الـwitness ضخمًا. على سبيل المثال، قد يقوم كل تحديث معاملة بعدد كبير من منافذ التخزين الخاصة بعقد ما.
حلول محتملة
قدّم الباحثون مجموعة متنوعة من الحلول لمعالجة هذه التحديات:
● شجرة Verkle — بنية بيانات خاصة لتقليل حجم الـwitness. تستخدم شجرة Verkle التزامات تشفيرية موجزة (مختصرة) لتقليل حجم الإثبات إلى الحد الأدنى.
● كاش الـwitness — يمكن للمقترح الاحتفاظ بـwitnesses الحديثة لإعادة استخدامها. ويمكن توزيع تكلفة الإنشاء (إطفاءها) من خلال استخدام الـwitness التي قد تصبح مفيدة مرة أخرى.
● حوافز البروتوكول — آلية مكافآت لتقديم witness مفيد. يمكن لبنية حوافز جديدة تعويض تكلفة إنشاء الـwitness.
● جذر الحالة الوسيط — يتم تتبع الجذور مع مرور الوقت لتجنب إعادة توليد البراهين. يمكن أن يؤدي الحفاظ على جزء من الجذور إلى إعادة استخدام أجزاء من الـwitness.
● رسوم الإيجار على الحالة (state rent) — تتطلب دفع تكلفة للحفاظ على الحالة على المدى الطويل مع تهذيب (pruning) الحالة غير المستخدمة. يفرض الإيجار تنظيف التخزين القديم للحد من حجم الإثبات.
● نموذج تقسيم الـwitness — تقسيم معالجة الحالة بين المقترحين والـمُتحققين. يقوم بعض العقد المتخصصة بالمقترحين بتوليد الـwitness.
توجد مقايضات بين هذه الطرق، وتحتاج إلى مزيد من البحث لاكتشاف أفضل تنفيذ. ولحسن الحظ، قد توفر الابتكارات السريعة في مجال التشفير عديم المعرفة (zero-knowledge) إمكانيات جديدة لعميل عديم الحالة بكفاءة.
الأثر المحتمل
إذا أمكن التغلب على العوائق التقنية، فقد يدفع العميل عديم الحالة تطور إيثيريوم بشكل كبير:
● مزامنة وتحقق أسرع لدعم إنتاجية أعلى للمعاملات. سيؤدي التحقق عديم الحالة إلى تسريع معالجة الكتل بشكل كبير.
● تقليل الموارد اللازمة لتشغيل العقد، وزيادة درجة لا مركزية الشبكة. قد يتمكن الكمبيوتر المحمول والهواة من تشغيل عقد كاملة فعليًا.
● دعم أفضل للعملاء الخفيفين مثل المحافظ المحمولة. تُعد براهين الحالة متوافقة جدًا مع نموذج العملاء الخفيفين.
● إدخال التقسيم/التجزئة بسلاسة أكبر مع التحقق عديم الحالة بين الشرائح. يمكن للمعاملات عبر الشرائح الاستفادة من براهين حالة فعّالة.
● القدرة على حذف وتهذيب (pruning) بيانات الحالة القديمة التي لم تعد مفيدة. يمكن إدارة نمو الحالة بشكل إيجابي بدل أن يصبح بلا حدود.
● مرونة أكبر لمشغّلي العقد لتخصيص الحالة حسب الحاجة. يمكن للعقد تكييف سياسات الاحتفاظ بالحالة وفقًا لحالات الاستخدام.
● الانتقال إلى نموذج حيث تصبح الحسابات والاتصال (النطاق العريض) أكثر أهمية من التخزين. يتغير تصميم البنية نحو نموذج أكثر ملاءمة للسحابة.
توجد أيضًا بعض المخاطر المحتملة، مثل زيادة قابلية التعرض لهجمات DDoS، وأن عددًا قليلًا من مشغّلي العقد فقط قد يعتمد عليهم في تخزين تاريخ سلسلة الكتل بشكل موثوق. ومع ذلك، يمكن أن تقلل البراهين التشفيرية من هذه المخاطر. إجمالًا، يُعد العميل عديم الحالة أحد أكثر الطرق الواعدة للتغلب على القيود الحالية لإيثيريوم.
الخلاصة
مع زيادة التبنّي، يشكل الحجم المتنامي لحالة إيثيريوم تحديًا أمام اللامركزية. يوفر العميل عديم الحالة حلاً عبر تمكين العقد من التحقق من المعاملات دون الحاجة إلى الحالة الكاملة لسلسلة الكتل. وقد يؤدي ذلك في النهاية إلى إمكانية تشغيل إيثيريوم على الهواتف المحمولة، مما يرفع اللامركزية بشكل كبير.