في بيئة Web3، تؤثر سهولة قراءة العناوين بشكل مباشر على أمان المدفوعات، وتجربة المستخدم، وكفاءة التحقق من الهوية. تعتمد التفاعلات التقليدية مع البلوكشين على عناوين نصية طويلة يصعب تذكرها، ما يجعلها عرضة للأخطاء أثناء التحويلات أو الموافقات أو استدعاء العقود. يقلل ENS من عوائق الاستخدام بتحويل العناوين إلى أسماء قابلة للتحقق، ما يتيح للمحافظ، وDApps (التطبيقات اللامركزية)، وDAOs، وNFTs، ومنصات التمويل اللامركزي (DeFi)، وأدوات التواصل الاجتماعي على السلسلة، التكامل حول بوابة هوية موحدة.
من الناحية التقنية، يعمل ENS من خلال وحدات مثل السجل (Registry)، والمحلل (Resolver)، وخوارزمية Namehash، والحل العكسي، وإدارة النطاقات الفرعية، والحل عبر السلاسل. أعلنت ENS Labs مؤخرًا عن تحول استراتيجي مهم: سيواصل ENSv2 العمل على Ethereum L1، مع التخلي عن خطة Namechain المنفصلة. جاء هذا القرار نتيجة لانخفاض رسوم الغاز على الشبكة الرئيسية لإيثريوم، وتسارع التوسع، وتفوق الأمان وإجماع النظام البيئي للطبقة الأولى كطبقة تسوية طويلة الأجل لـ ENS.

تتكون بنية ENS من ثلاث طبقات: طبقة التسمية، وطبقة الملكية، وطبقة الحل. تحدد طبقة التسمية هياكل مثل eth، وalice.eth، وpay.alice.eth؛ أما طبقة الملكية التي يديرها سجل ENS، فتسجل من يملك كل اسم؛ بينما تتولى طبقة الحل، التي يديرها عقد المحلل (Resolver)، إعادة بيانات مثل عناوين Ethereum، أو عناوين بلوكشين أخرى، أو سجلات نصية، أو تجزئة محتوى.
عند إدخال المستخدم اسم ENS، يقوم النظام أولًا بتطبيعه لمنع التناقضات الناتجة عن حالة الأحرف أو الرموز الخاصة أو التشابه البصري. ثم يُحوَّل الاسم عبر خوارزمية Namehash إلى عقدة فريدة—معرف تجزئة معتمد من العقود على السلسلة. لا يخزن سجل ENS السلسلة النصية الكاملة، بل يستخدم هذه العقدة للبحث عن المالك، عنوان المحلل، TTL، وتفاصيل أخرى.
يُدار الحل عادة تلقائيًا عبر المحافظ، أو مستكشفات الكتل، أو DApps، أو أدوات ENS الرسمية، وليس من قبل المستخدمين أنفسهم. تستخدم التطبيقات الحديثة غالبًا Universal Resolver كنقطة دخول موحدة، ما يبسط تجربة المطورين بإخفاء التفاعل المباشر مع السجل، والمحلل، ومنطق الحل عبر السلاسل.
يرتكز ربط نطاقات ENS بعناوين المحافظ على سجلات العناوين في المحلل. على سبيل المثال، يمكن للمستخدمين تعيين عنوان Ethereum إلى alice.eth عبر تطبيق ENS. عند التعيين، يخزن عقد المحلل سجل addr لـ alice.eth.
عند إرسال شخص ما أموالًا إلى alice.eth، تحدد المحفظة المحلل المناسب، ثم تستدعي طريقة addr الخاصة به لاسترجاع عنوان Ethereum. بعد التحقق من العنوان، تُنشئ المحفظة المعاملة. بالنسبة للمستخدم، الإدخال هو اسم نطاق؛ أما بالنسبة للبلوكشين، فالمعاملة تُرسل فعليًا إلى العنوان الفعلي.
كما يمكّن ENS من تخزين سجلات عناوين لعدة عملات، ما يسمح لاسم ENS واحد بربط عناوين من Ethereum، وBitcoin، وLitecoin، وSolana، وغيرها. وهكذا يمكن لـ alice.eth أن تكون بوابة إيداع أصول متعددة السلاسل، وليس مجرد اسم مستعار لإيثريوم.
سجل ENS هو عقد التسجيل الأساسي للنظام، ويخزن ثلاثة حقول رئيسية: مالك الاسم، عنوان المحلل، وTTL. يمكن أن يكون المالك عنوان محفظة عادي، أو محفظة متعددة التواقيع، أو عقدًا ذكيًا، أو DAO. من يسيطر على الاسم يمكنه تعيين المحلل، إنشاء نطاقات فرعية، أو نقل الملكية.
المحلل هو العقد الذي يعيد البيانات، حيث يخزن سجلات العناوين، والسجلات النصية، وتجزئات المحتوى، والأفاتارات، والبريد الإلكتروني، وحسابات التواصل الاجتماعي، وروابط المواقع الإلكترونية، وغيرها. يدعم المحلل العام الرسمي لـ ENS عدة واجهات معيارية، مما يمكّن المحافظ وDApps من الوصول إلى البيانات بتنسيق موحد.
يُعد الفصل بين السجل والمحلل من الركائز التصميمية في ENS. فالسجل يحدد "من يسيطر على الاسم وأي محلل يُستخدم"، بينما المحلل يحدد "ما هي البيانات التي تُعاد للاسم". يتيح هذا التقسيم لـ ENS دعم منطق حل متعدد—على السلسلة فقط، أو خارج السلسلة، أو عبر السلاسل، أو ملفات هوية مخصصة.
يعد ENS جزءًا متجذرًا في نظام Ethereum البيئي. فالمحافظ الرائدة تتعرف على أسماء ENS للمدفوعات والتحويلات وعرض العناوين؛ ويمكن لمستكشفات الكتل حل العناوين عكسيًا إلى أسماء ENS؛ كما تستخدم بروتوكولات التمويل اللامركزي (DeFi)، والمتاجر، وأدوات DAO أسماء ENS كبطاقات هوية للمستخدمين.
على مستوى العقود الذكية، يمكن لـ DApps استدعاء ENS مباشرة. على سبيل المثال، قد يقرأ تطبيق اسم المستخدم المحلول عكسيًا لصفحته الرئيسية، أو يعرض الأفاتار، أو الموقع الإلكتروني، أو الملفات الاجتماعية من سجلات ENS النصية. بذلك يتحول ENS إلى أكثر من مجرد اسم مستعار للمحفظة—بل يصبح طبقة بيانات هوية على السلسلة.
كما يعتمد ENS على آليات مثل CCIP Read لدعم استرجاع البيانات من خارج السلسلة وعبر السلاسل. ففي السيناريوهات المعقدة، قد لا يخزن المحلل جميع البيانات على الشبكة الرئيسية لإيثريوم؛ إذ يمكن معالجة بعض المنطق عبر خدمات خارج السلسلة أو شبكات أخرى، مع قيام العملاء بالتحقق من النتائج. يقلل ذلك التكاليف ويمهد الطريق لتوسعة الهوية المتعددة السلاسل.
يعتمد ENS هيكلية تسمية هرمية مشابهة لـ DNS. eth هو النطاق الأعلى؛ alice.eth هو اسم من المستوى الثاني؛ pay.alice.eth، dao.alice.eth، وteam.alice.eth هي نطاقات فرعية. يمكن لكل اسم أن يكون له مالك خاص، ومحلل، وسجلات حل مستقلة.
يتم تفويض التحكم بالنطاقات الفرعية من قبل مالك النطاق الرئيسي. فعلى سبيل المثال، يمكن لمالك alice.eth إنشاء pay.alice.eth للمدفوعات، أو nft.alice.eth لعرض NFT، أو تخصيص نطاقات فرعية لأعضاء الفريق أو المستخدمين أو وحدات المنتجات.
يمنح نظام النطاقات الفرعية ENS قدرات تنظيمية قوية. يمكن للأفراد تخصيص وظائف مختلفة للنطاقات الفرعية، ويمكن للمشاريع توزيع أسماء الهوية على المستخدمين، كما يمكن لـ DAOs إنشاء مساحات أسماء للأعضاء، أو المقترحات، أو الخزائن، أو فرق العمل. ومن التحديثات الرئيسية في ENSv2 هو توفير سجل فرعي ونموذج أذونات أكثر مرونة لكل اسم، ما يسهل إدارة النطاقات الفرعية.
يقوم DNS بحل أسماء النطاقات إلى عناوين IP، ويتم تنسيقه عبر المسجلين والسجلات والخوادم الجذرية وICANN. أما ENS فيحل الأسماء إلى عناوين على السلسلة، وتجزئات محتوى، وبيانات هوية، مع تحكم حاسم تديره العقود الذكية على Ethereum.
من ناحية الثقة، يعتمد DNS على كيانات مركزية وأنظمة حسابات—حيث يدير حاملو النطاقات السجلات عبر لوحات تحكم المسجلين. أما ENS فيعتمد على المفاتيح السرية والعقود الذكية، مع ملكية قابلة للتحقق على السلسلة، وإمكانية نقل التحكم إلى أنظمة متعددة التواقيع أو عقود أو DAOs.
أما بالنسبة لمحتوى الحل، فـ DNS مخصص للوصول إلى المواقع الإلكترونية (سجلات A، AAAA، CNAME، MX، إلخ)؛ بينما ENS مخصص لتفاعلات Web3 (سجلات addr، contenthash، السجلات النصية، عناوين متعددة السلاسل، الحل العكسي). ويمكن لـ ENS أيضًا التكامل مع DNS، عبر استيراد نطاقات DNS إلى ENS للحل على السلسلة.
أول تحدٍ يواجه ENS هو التكلفة. فعلى الرغم من انخفاض رسوم الغاز على Ethereum L1 من ذروتها، إلا أن تسجيل الأسماء، وتجديدها، وتحديث السجلات، وإنشاء النطاقات الفرعية يمكن أن يظل مكلفًا أثناء ازدحام الشبكة. التزام ENSv2 بالبقاء على L1 يضمن الأمان، لكنه يجعل تجربة المستخدم عرضة لتقلب رسوم الشبكة الرئيسية.
التحدي الثاني هو تعقيد الحل. تتطلب أسماء ENS التطبيع، وتجزئة Namehash، واستعلامات السجل والمحلل، والحل العكسي، وقراءات متعددة السلاسل. بالنسبة للمستخدم النهائي، هذا غير مرئي؛ أما بالنسبة للمطورين، فقد يؤدي الاستخدام غير الصحيح لـ Universal Resolver أو SDKs إلى حل غير مكتمل، أو عدم تطابق السلاسل، أو مشكلات توافق.
أما التحدي الثالث فهو الأمان وسوء الاستخدام. أسماء ENS معرضة لهجمات التصيد، والانتحال، والتشويش البصري. حتى الأسماء التي تبدو موثوقة تتطلب من المستخدمين التحقق من العناوين، ومصادر DApp، ومحتوى التواقيع. أما بالنسبة للأسماء عالية القيمة، فقد تؤدي تسريبات المفاتيح السرية، أو التلاعب بالمحلل، أو أذونات خاطئة إلى خسائر كبيرة.
يركز ENS تقنيًا في المقام الأول على ENSv2. وفقًا لآخر خارطة طريق من ENS Labs، سيبقى ENSv2 على Ethereum L1 بدلاً من الانتقال إلى Namechain منفصلة. يتماشى ذلك مع تقدم التوسع في Ethereum، وانخفاض رسوم الغاز، ومتطلبات الأمان، كما يقلل من تعقيد الانتقال بين الطبقة الثانية والشبكة الرئيسية للمستخدمين.
يقدم ENSv2 سجلًا أكثر طبقية وقابلية للتعديل، وأذونات مرنة، وتسجيلًا أبسط، وحلًا محسّنًا عبر السلاسل، وأدوات جديدة للمستخدمين والمطورين. ومع استقلالية أكبر لكل اسم، تصبح توزيع النطاقات الفرعية، وإدارة هوية المؤسسات، والأذونات المعقدة أكثر سهولة.
سيظل Universal Resolver مكونًا أساسيًا، ليخدم كنقطة دخول موحدة لحل ENS—بغض النظر عما إذا كان الاسم ينتمي إلى ENSv1 أو ENSv2 أو L1 أو L2 أو يُحل خارج السلسلة. بالنسبة للمطورين، يخفض ذلك حواجز التكامل؛ أما للمستخدمين، فيضمن تجربة حل متسقة.
الركيزة التقنية لـ ENS هي السجل للملكية، والمحلل للبيانات، وآليات داعمة مثل Namehash، والحل العكسي، والنطاقات الفرعية، وUniversal Resolver، التي تحول جميعها العناوين المعقدة على السلسلة إلى بوابات هوية قابلة للقراءة والتحقق والتوسع.
ومع تقدم ENSv2، يتطور ENS من خدمة نطاقات .eth إلى بنية تحتية شاملة لأسماء وهوية Web3. وتتمثل قيمته الجوهرية ليس فقط في تسهيل التحويلات، بل أيضًا في توفير معيار موحد لحل الهوية للمحافظ، وDApps، وDAOs، والأصول متعددة السلاسل، ومنصات التواصل الاجتماعي على السلسلة.





