بروتوكول NEAR: شرح التحقق بلا حالة

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

جدول المحتويات

["أصول NEAR: المؤسسون، التاريخ، والرسالة","كيف يعمل بروتوكول NEAR: الإجماع، الرموز، والأساسيات","منظومة NEAR: ما يمكنك بناؤه والقيام به","فهم تجزئة البلوكتشين: الأساس لكل ما سيأتي","خارطة طريق تجزئة Nightshade: من الإطلاق إلى التحقق عديم الحالة","ما هو التحقق عديم الحالة في NEAR؟","NEAR مقابل Ethereum مقابل Solana: مقارنة المعماريات","أسئلة متكررة حول بروتوكول NEAR والتحقق عديم الحالة","خاتمة: لماذا التحقق عديم الحالة مهم لمستقبل NEAR"]

بروتوكول NEAR هو بلوكتشين من الطبقة الأولى يعمل بنظام إثبات الحصة، مصمم لتحقيق قابلية التوسع من خلال بنية تجزئة تسمى نايت شيد. عملته الرقمية الأصلية، توكن NEAR، تدعم رسوم الغاز، تخزين المدققين، وحوكمة البروتوكول. ترقية التحقق عديم الحالة للبروتوكول (المرحلة الثانية من خارطة طريق نايت شيد) تقلل من متطلبات أجهزة المدققين وتدفع نحو لامركزية الشبكة، مع استهداف أكثر من 100,000 معاملة في الثانية (TPS) عند التشغيل الكامل.

يرى مفهوم البلوك تشين والمعضلة الثلاثية، الذي يُنسب عادةً إلى فيتاليك بوتيرين، أن البلوكتشين يمكنها تحقيق خاصيتين فقط من أصل ثلاث في وقت واحد: قابلية التوسع، والأمان، واللامركزية. وقد صُممت الخيارات المعمارية لبروتوكول NEAR، ولا سيما التحقق من الصحة عديم الحالة (stateless validation)، لمعالجة هذه الخصائص الثلاث معاً. بنهاية هذا المقال، ستكون قادراً على شرح ماهية بروتوكول NEAR، ووصف كيف يختلف التحقق عديم الحالة عن التحقق المعتمد على الحالة (stateful validation)، وفهم ما يقوم به شهود الحالة (state witnesses) ومحققي الكتل (chunk validators)، وتحديد موقع التحقق عديم الحالة في خارطة طريق تطوير NEAR مقارنة بعمل إيثيريوم على بنيتها المعمارية عديمة الحالة.

أصول NEAR: المؤسسون، التاريخ، والمهمة

تأسس بروتوكول NEAR في عام 2018 على يد إيليا بولوسوخين وألكسندر سكيدانوف. بولوسوخين هو مؤلف مشارك للورقة البحثية البارزة لعام 2017 "الانتباه هو كل ما تحتاجه"(https://arxiv.org/abs/1706.03762), البحث الذي قدم بنية "المحول" (Transformer) التي تقوم عليها نماذج اللغة الكبيرة الحالية، بما في ذلك GPT و BERT. سكيدانوف هو مهندس سابق في جوجل ولديه خلفية في أبحاث الأنظمة الموزعة. مؤهلاتهم المشتركة وضعت بروتوكول NEAR منذ تأسيسه في أيدي باحثين سبق لهم تقديم أعمال تأسيسية في مجال التعلم الآلي والحوسبة الموزعة واسعة النطاق.

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

أطلق بروتوكول NEAR المينيت الخاص به في أبريل 2020. تُشرف مؤسسة NEAR,، وهي منظمة غير ربحية، على تطوير البروتوكول وبرامج المنح ونمو النظام البيئي. وتُعد المؤسسة كياناً مستقلاً عن بروتوكول NEAR (الشبكة) وعن رمز NEAR (الأصل). وهذا التمييز مهم عند قراءة المراسلات الرسمية حول المشروع.

كيف يعمل بروتوكول NEAR: الإجماع، والرموز المميزة، والأساسيات

يؤمّن بروتوكول NEAR شبكته من خلال نموذج إجماع إثبات الحصة (proof-of-stake)، حيث يقوم المدققون بتخزين رموز NEAR كضمان اقتصادي للمشاركة في إنتاج الكتل والتحقق منها.

إثبات الحصة: كيف يؤمّن NEAR الشبكة

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

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

متطلبات أجهزة المدققين تتشكل مباشرةً بواسطة تصميم التجزئة (sharding) في NEAR. قبل التحقق عديم الحالة (stateless validation)، واجه المدققون الذين يقومون بتخزين حالة التجزئة الكاملة متطلبات كبيرة للتخزين والذاكرة. هذا الارتباط بين تكلفة الأجهزة ومشاركة المدققين هو المشكلة المعمارية التي صُمم التحقق عديم الحالة لمعالجتها. التفاصيل الكاملة موجودة في وثائق مدقق بروتوكول NEAR.)

رمز NEAR: رسوم الغاز، التخزين (Staking)، وحوكمة البروتوكول

رمز NEAR هو العملة الرقمية الأصلية لبروتوكول NEAR، ويؤدي ثلاث وظائف رئيسية: دفع رسوم الغاز (وهي تكاليف المعاملات المدفوعة للمدققين لمعالجة نشاط الشبكة)، وتوفير ضمانات التحصين (Staking) للمدققين، وتمكين المشاركة في حوكمة البروتوكول.

تُنتج NEAR الكتل كل ثانية واحدة تقريبًا. وتُعالج الشبكة حاليًا آلاف المعاملات في الثانية (TPS) عبر أقسامها النشطة، مع هدف معماري طويل المدى يتجاوز 100,000 معاملة في الثانية عند التجزئة الكاملة مع التحقق عديم الحالة. يُعد هذا الرقم هدفاً تصميمياً، وليس ادعاءً بالأداء الحالي. صُممت هذه المعمارية للوصول إلى تلك الإنتاجية من خلال توزيع معالجة المعاملات عبر أقسام متوازية بدلاً من معالجة كل معاملة على سلسلة واحدة. تُعوّض مكافآت التخزين (Staking) المدققين عن مشاركتهم في أمن الشبكة كحافز للمشاركة في الشبكة، وليس كمنتج استثماري.

منظومة NEAR المتكاملة: ما يمكنك بناؤه والقيام به

يدعم بروتوكول NEAR مجموعة من التطبيقات اللامركزية (dApps) عبر DeFi، والألعاب، والرموز غير القابلة للاستبدال (NFTs)، ومنصات التواصل الاجتماعي الخاصة بـ Web3. توفر مكونات النظام البيئي التالية للمطورين والمستخدمين طرقاً متعددة للتفاعل مع الشبكة:

• تطوير العقود الذكية: تُكتب العقود على NEAR بلغة Rust أو JavaScript/TypeScript وتُترجم إلى WebAssembly (WASM)، وهو تنسيق ثنائي محمول يُستخدم كبيئة تشغيل للعقود الذكية على NEAR. يدعم NEAR SDK كلتا اللغتين، مما يجعل المنصَّة متاحة لقاعدة واسعة من المطورين.
• وصول مطوري Ethereum: Aurora، طبقة توافق EVM الخاصة بـ NEAR، تسمح لمطوري Ethereum بنشر عقود Solidity الذكية الحالية على NEAR بأقل قدر من التعديل. Aurora هو منتج منفصل مبني فوق NEAR Protocol، وليس جزءًا من بيئة WASM الأصلية لـ NEAR.
• نقل الأصول عبر السلاسل: يتيح Rainbow Bridge، جسر أصول Ethereum الخاص بـ NEAR، نقل الأصول بلا وثوق بين NEAR Protocol و Ethereum. بلا وثوق هنا يعني أن الجسر يعمل دون الحاجة إلى الثقة في طرف مركزي، مما يسمح للمستخدمين بنقل الرموز المميزة بين الشبكتين دون الاعتماد على جهة حفظ مركزية.
• توفر البيانات للتراكمية: تقدم NEAR أيضًا طبقة توفر البيانات (NEAR DA) التي تسمح للتراكميات الخاصة بـ Ethereum والسلاسل الأخرى باستخدام بنية NEAR المجزأة لتوفير بيانات منخفضة التكلفة وعالية الإنتاجية، مما يوسع فوائد بنية NEAR إلى ما وراء نظامها البيئي الخاص.

يمكن للمطورين المستعدين للبناء البدء بالاطلاع على وثائق مطوري NEAR على docs.near.org، والتي تشمل حزمة أدوات تطوير NEAR (NEAR SDK)، ونشر العقود الذكية، وجميع أدوات المطورين.

يعد فهم بنية التجزئة (sharding) الخاصة بـ NEAR الخطوة التالية لاستيعاب كيفية توفير الشبكة لهذا النظام البيئي على نطاق واسع.

فهم تجزئة البلوكتشين: الأساس لكل ما يتبع ذلك

Sharding هو الأسلوب المعماري في صميم تصميم قابلية التوسع لبروتوكول NEAR، وفهمه هو الأساس لفهم التحقق عديم الحالة.

ما هو تقسيم البلوكتشين؟

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

يقدم تقسيم الشبكة (Sharding) تحدياً في التنسيق تتجنبه بنيات السلسلة الواحدة. فعندما تتضمن المعاملة حسابات أو عقوداً ذكية في أقسام مختلفة، يجب على البروتوكول التنسيق بين الأقسام لإتمامها، مما يتطلب إيصالات ورسائل استدعاء عبر حدود الأقسام. تُسمى هذه بالمعاملات عبر الأقسام (cross-shard transactions)، وتعد إدارة عبء التنسيق هذا إحدى مشكلات التصميم المركزية في بنية البلوكتشين المقسمة. ويرتبط هذا مباشرةً بالسبب وراء أهمية التحقق عديم الحالة (stateless validation) لقابلية توسع NEAR على المدى الطويل.

Nightshade: بنية تقسيم الشبكة (Sharding) في NEAR

نايت شيد (Nightshade) هي بنية التجزئة (sharding) في بروتوكول نير (NEAR Protocol) التي تحافظ على بلوكتشين منطقي واحد مع تقسيم معالجة المعاملات عبر أجزاء متوازية، حيث ينتج كل جزء مجموعة فرعية من المعاملات تسمى كتلة جزئية (chunk) لكل كتلة أساسية. يتم تضمين جميع الكتل الجزئية من كافة الأجزاء في نفس الكتلة، مما يحافظ على مظهر سلسلة موحدة واحدة مع تمكين المعالجة المتوازية في البنية التحتية.

إليك كيف يعالج نايت شيد (Nightshade) المعاملات:

1. يتم تعيين كل حساب على NEAR إلى جزء (shard) معين بناءً على معرف الحساب الخاص به
2. يتم توجيه المعاملات إلى الجزء (shard) الذي يمتلك حساب المرسل
3. ينتج كل جزء (shard) قطعة (chunk) من المعاملات لفترة الكتلة تلك
4. يتم تجميع كافة القطع (chunks) من جميع الأجزاء النشطة في كتلة واحدة
5. يقوم منتجو الكتل بالتحقق من صحة الكتلة؛ ويقوم مدققو القطع (بعد المرحلة الثانية) بالتحقق من القطع الفردية

اعتبارًا من عام 2024، تعمل NEAR بستة أجزاء نشطة، وفقًا لـ وثائق التجزئة Nightshade الخاصة بـ NEAR.). تقدم المرحلة 3+ من خارطة طريق Nightshade إعادة التجزئة الديناميكية، والتي ستسمح لعدد الأجزاء بالتوسع تلقائيًا بناءً على طلب الشبكة بدلاً من أن يكون ثابتًا.

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

فهم التطور المرحلي لـ Nightshade هو السياق الأساسي لوضع التحقق عديم الحالة على خارطة الطريق، والذي يغطيه القسم التالي.

خريطة طريق تجزئة نايت شيد (Nightshade Sharding): من الإطلاق إلى التحقق من الصحة عديم الحالة (Stateless Validation)

تم نشر بنية تقسيم "نايت شيد" (Nightshade sharding architecture) على مراحل، حيث تغير كل مرحلة الطريقة التي يتفاعل بها المدققون مع حالة الشارد (shard state).

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

تركز المرحلة الثانية (التحقق عديم الحالة) في القسم التالي: ماهيتها بالضبط، وكيفية عملها، وما تحدثه من تغييرات للمدققين والمستخدمين على حد سواء.

ما هو التحقق من الصحة عديم الحالة (Stateless Validation) في NEAR؟

التحقق عديم الحالة (Stateless validation) هو ترقية لبروتوكول NEAR (المرحلة الثانية من Nightshade) يتحقق فيها مدققو الأجزاء من أجزاء المعاملات دون تخزين الحالة الكاملة للقسم. بدلاً من الاحتفاظ ببيانات الحالة المستمرة محليًا، يتلقى المدققون شهادات الحالة، وهي حزم بيانات تشفيرية تم إنشاؤها بواسطة منتجي الكتل، تحتوي على المعلومات اللازمة بالضبط للتحقق من كل جزء.

إن التحقق من الصحة عديم الحالة ليس حكراً على NEAR؛ بل هو نهج معماري يتم استكشافه عبر العديد من الأنظمة البيئية لتقنية البلوكتشين. ويُعد تنفيذ NEAR تطبيقاً ملموساً ومحدداً في طبقة التنفيذ، وهو يختلف عن خارطة طريق العميل عديم الحالة لشبكة Ethereum التي تعمل في طبقة الوصول إلى البيانات. المصطلح الرسمي لـ NEAR لهذه الميزة هو "التحقق من الصحة عديم الحالة"، وليس "العملاء عديمو الحالة" (مصطلح Ethereum) أو "التنفيذ عديم الحالة".

للاطلاع على المواصفات الفنية الكاملة، راجع إعلان مؤسسة NEAR حول التحقق من الحالة (stateless validation).

المشكلة: لماذا لا يمكن توسيع نطاق التحقق المعتمد على الحالة (Stateful Validation)

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

يُظهر الجدول أدناه كيف تقارن عمليات التحقق ذات الحالة وعديمة الحالة عبر خمسة أبعاد.

مع نمو الشبكة وتراكم الحالة، يفرض النموذج ذو الحالة في النهاية خيارًا: رفع متطلبات الأجهزة بشكل أكبر، أو تقليل عدد الشرائح، أو قبول مركزية المدققين.

التحقق عديم الحالة: التعريف

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

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

شهود الحالة: المفتاح التشفيري

يُعد "شاهد الحالة" (state witness) في بروتوكول NEAR حزمة بيانات مشفرة يتم إنشاؤها بواسطة منتج كتل، وتتضمن كافة أرصدة الحسابات وقيم تخزين العقود التي يحتاجها مدقق الأجزاء للتحقق من جزء معاملة معين، دون إلزام المدقق بتخزين حالة الشارد الكاملة محلياً.

تعمل الآلية في خمس خطوات:

["يحتفظ منتج الكتلة بالحالة الكاملة للشاردة وينتج قطعة للشاردة المعينة له","يولد منتج الكتلة شهادة حالة لتلك القطعة، تحتوي على قيم الحالة ذات الصلة المسحوبة من شجرة حالة NEAR (بنية البيانات التشفيرية التي تسجل جميع أرصدة الحسابات وتخزين العقود)","تُرسل شهادة الحالة إلى مدققي القطع المعينين لتلك الشاردة لهذه الكتلة","يستخدم مدققو القطع الشهادة للتحقق من صحة المعاملات لكل معاملة في القطعة","يتخلص مدققو القطع من الشهادة بعد التحقق، دون تخزين دائم للحالة"]

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

المصطلح المستخدم في جميع أنحاء مواصفات بروتوكول NEAR هو "state witness"، وليس "state proof" أو أي صيغة أخرى. يمكن للقراء الذين يبحثون عن عمق المواصفات الفنية الرجوع إلى مستودع مقترحات تحسين NEAR (NEPs)).

مدققو الأجزاء مقابل منتجي الكتل: مستويان من المشاركة في الشبكة

مدقق المقطع على NEAR هو عقدة مدقق تقوم بالتحقق من مقطع معاملة معين باستخدام شاهد حالة مقدم من منتج الكتل، دون تخزين حالة التقسيم الكاملة محليًا.

يشكل منتجو البلوكات ومدققو الأجزاء بنية ذات مستويين:

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

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

نظرًا لأن مدققات الأجزاء لا تحتفظ بحالة دائمة، فإن التكلفة الرأسمالية لتشغيلها أقل بكثير من تشغيل عقدة مدقق منتج للكتل.### ما يعنيه التحقق عديم الحالة للامركزية وقابلية التوسع

يحقق التحقق من الصحة بدون حالة ثلاث نتائج مترابطة لشبكة NEAR: لامركزية أوسع، وتحسين قابلية التوسع، وتقدم ملموس فيما يخص البلوك تشين والمعضلة الثلاثية.

اللامركزية. تقلل متطلبات الأجهزة المنخفضة لمدققي القطع (chunk validators) من حاجز رأس المال لتشغيل عقدة مدقق، مما يوسع مجموعة المدققين. لا يزال منتجو الكتل (block producers) يتطلبون مواصفات أجهزة أعلى، لكن مدققي القطع يمثلون الحصة الأكبر والمتزايدة من عمل التحقق النشط مع زيادة عدد الأجزاء (shards). النتيجة هي مسار أوسع وأكثر سهولة للمشاركة في أمن الشبكة.

قابلية التوسع. إن فصل تخزين الحالة عن عمل التحقق يعني أن بروتوكول NEAR يمكنه زيادة عدد الـ Shards دون زيادة متطلبات الأجهزة لكل مدقق بشكل متناسب. تستهدف الشبكة أكثر من 100,000 عملية في الثانية (TPS) مع ميزة الـ Sharding الكاملة والتحقق عديم الحالة (Stateless Validation)، وهو هدف تصميمي تدعمه البنية التحتية، وليس رقماً للأداء الحالي. لم تعد إنتاجية التحقق تواجه اختناقاً في مدخلات/مخرجات تخزين الحالة، والتي كانت العائق الرئيسي في المرحلة الأولى.

تطور البلوك تشين والمعضلة الثلاثية. تنص البلوك تشين والمعضلة الثلاثية (التي تُنسب عادةً إلى فيتاليك بوتيرين) على أن البلوكتشين يمكنه تحقيق اثنين فقط كحد أقصى من قابلية التوسع والأمان واللامركزية في آن واحد. يعالج التحقق عديم الحالة (Stateless validation) هذه الجوانب الثلاثة معاً. تتحسن قابلية التوسع من خلال زيادة إنتاجية التحقق لكل شظية (shard). وتتحسن اللامركزية من خلال خفض متطلبات الأجهزة لمدققي الأجزاء (chunk validators). بينما يتحسن الأمان من خلال التدوير العشوائي لمدققي الأجزاء الذي يمنع الهجمات المستهدفة على شظايا معينة.

الخلاصات الرئيسية:

• التحقق عديم الحالة (Stateless validation) هو ترقية Phase 2 Nightshade من NEAR، مما يزيل متطلبات تخزين الحالة من مدققي الأجزاء (chunk validators).
• يقوم منتجو الكتل (Block producers) بإنشاء شهادات الحالة (state witnesses)؛ ويستخدمها مدققي الأجزاء للتحقق من الأجزاء ثم يتخلصون منها.
• لا يقوم مدققي الأجزاء بتخزين الحالة الكاملة للشارد (shard). هذا هو التمييز المحدد عن التحقق المرتبط بالحالة (stateful validation).
• متطلبات الأجهزة الأقل لمدققي الأجزاء توسع نطاق المشاركين في أمن الشبكة.
• تهدف NEAR إلى تحقيق 100,000+ معاملة في الثانية (TPS) مع التقسيم الكامل (full sharding)؛ ويزيل التحقق عديم الحالة عنق الزجاجة الرئيسي في هذا المسار.

لفهم كيف تتم مقارنة نهج NEAR بما تبنيه Ethereum و Solana، يستعرض القسم التالي المفاضلات المعمارية عبر هذه الشبكات الثلاث.

NEAR مقابل إيثيريوم مقابل سولانا: مقارنة بين البنى المعمارية

يمثل بروتوكول NEAR وإيثيريوم وسولانا ثلاثة مناهج معمارية متميزة لمواجهة التحدي الجوهري نفسه: وهو تحقيق إنتاجية معاملات عالية على نطاق واسع. ويساعد فهم هذه الاختلافات في تقييم مقايضات التصميم لكل بروتوكول دون تفضيل أحدهما على الآخر.

NEAR مقابل إيثيريوم: تجزئة التنفيذ مقابل تجزئة البيانات

تختلف شبكتا NEAR وإيثيريوم في ثلاثة أبعاد معمارية أساسية: نهج التجزئة (sharding)، وتطبيق البنية الهيكلية عديمة الحالة، وأدوات المطورين.

فيما يتعلق بالتجزئة، تتبنى NEAR تجزئة التنفيذ من خلال Nightshade. يتم تقسيم عبء عمل معالجة المعاملات نفسه عبر أجزاء متوازية، حيث ينتج كل جزء "قطعاً" (chunks) يتم تجميعها لتكوين كتل. أما Ethereum، فتتبنى تجزئة البيانات من خلال danksharding (نهج تجزئة توفر البيانات في Ethereum)، الذي يركز على توفير تخزين بيانات رخيص للشبكات التراكمية من الطبقة الثانية بدلاً من تجزئة التنفيذ في الطبقة الأساسية. يتم التعامل مع توسيع نطاق التنفيذ في Ethereum بواسطة الشبكات التراكمية المبنية فوق السلسلة الأساسية، وليس عن طريق تقسيم السلسلة الأساسية نفسها.

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

فيما يتعلق بأدوات المطورين، تستخدم NEAR تقنية WebAssembly (WASM) كبيئة تشغيل لتنفيذ العقود الذكية، مع استخدام Rust وJavaScript/TypeScript كلغات أساسية للعقود الذكية. بينما تستخدم إيثريوم آلة إيثريوم الافتراضية (EVM) مع لغة Solidity كلغة أساسية. توفر NEAR التوافق مع آلة إيثريوم الافتراضية (EVM) من خلال Aurora، مما يجعلها متاحة لمطوري Solidity دون مطالبتهم بتعلم Rust أو JavaScript لتطوير العقود.

تم تصميم NEAR والإيثيريوم لمقايضات معمارية مختلفة بدلاً من أن يكونا قابلين للمقارنة بشكل مباشر على محور أداء واحد. للاطلاع على خارطة طريق مشاركة البيانات التفصيلية للإيثيريوم، راجع خارطة طريق danksharding للإيثيريوم.)

NEAR مقابل Solana: التوسع المجزأ مقابل سرعة السلسلة الواحدة

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

توزع بنية NEAR المجزأة (sharded) عبء العمل عبر أجزاء متوازية، ومن خلال التحقق من الصحة بدون حالة (stateless validation)، فإنها تقلل من متطلبات الأجهزة لكل مدقق بالنسبة لمدققي الأجزاء (chunk validators). ويكمن الاختلاف في فلسفة التصميم في كونه مسألة مفاضلات؛ حيث تعطي سولانا الأولوية لاتساق أداء السلسلة الواحدة، بينما توزع NEAR الحمل عبر الأجزاء للحفاظ على إمكانية وصول المدققين مع توسع نطاق الإنتاجية.

أسئلة متكررة حول بروتوكول NEAR والتحقق عديم الحالة

تتناول الأسئلة التالية استفسارات البحث الأكثر شيوعاً حول بروتوكول NEAR والتحقق من الصحة عديم الحالة.

ما هو بروتوكول NEAR؟

بروتوكول NEAR هو بلوكتشين من الطبقة الأولى يعمل بإثبات الحصة (proof-of-stake)، مصمم لتحقيق إنتاجية عالية عبر بنية تجزئة (sharding) تسمى Nightshade. يقوم المدققون بتخزين (stake) رمز NEAR للمشاركة في إنتاج الكتل وأمن الشبكة. يستهدف البروتوكول تحقيق أكثر من 100,000 معاملة في الثانية (TPS) عند مقياس التجزئة الكامل، وقد أطلق مينيت (mainnet) الخاص به في أبريل 2020. تقلل ترقية التحقق عديم الحالة (stateless validation) (المرحلة 2) من متطلبات أجهزة المدققين وتوسع المشاركة في الشبكة.

ما هو التحقق عديم الحالة في NEAR؟

التحقق عديم الحالة (Stateless Validation) هو ترقية Nightshade للمرحلة الثانية من NEAR، والتي تقوم فيها مدققات القطع (chunk validators) بالتحقق من قطع المعاملات (transaction chunks) دون تخزين حالة الشاردة الكاملة (full shard state) محليًا. يقوم منتجو الكتل (Block producers) بإنشاء حزم بيانات تشفيرية تسمى شهود الحالة (state witnesses) لكل قطعة. تستلم مدققات القطع هذه الشهود، وتتحقق من المعاملات، ثم تتخلص من الشهود. النتيجة هي متطلبات أجهزة أقل للتحقق ونموذج مشاركة مدقق أكثر سهولة.

ما هو تشظي (Sharding) Nightshade؟

نايت شيد (Nightshade) هي بنية التجزئة الخاصة ببروتوكول نير (NEAR Protocol) التي تحافظ على البلوكتشين منطقي واحد مع تقسيم معالجة المعاملات عبر أجزاء متوازية، حيث ينتج كل منها مجموعة (chunk) من المعاملات لكل كتلة. يتم تجميع كافة المجموعات في كتلة واحدة. يتم تخصيص المعاملات للأجزاء بناءً على معرف الحساب. واعتباراً من عام 2024، يشغل بروتوكول نير ستة أجزاء، مع تقديم المرحلة 3+ لخاصية إعادة التجزئة الديناميكية لتوسيع عدد الأجزاء بناءً على الطلب.

من الذي أنشأ بروتوكول نير (NEAR Protocol)؟

تأسس بروتوكول NEAR في عام 2018 من قِبل إليا بولوسوخين وألكسندر سكيدانوف. ويعد بولوسوخين مؤلفاً مشاركاً في ورقة البحث الصادرة عام 2017 بعنوان "Attention Is All You Need" والتي قدمت بنية Transformer الكامنة وراء نماذج الذكاء الاصطناعي الحديثة، بما في ذلك GPT. أما سكيدانوف فهو مهندس سابق في Google ويمتلك خبرة في الأنظمة الموزعة. أُطلق البروتوكول على مينيت في أبريل 2020، حيث تعمل مؤسسة NEAR كوكيل غير ربحي.

ما هو مدقق الأجزاء (chunk validator)؟

مدقق الأجزاء (Chunk validator) على شبكة NEAR هو عقدة مدقق تتحقق من جزء معاملة معين (transaction chunk) داخل الكتلة باستخدام شاهد الحالة (state witness) المقدم من منتج الكتلة، وذلك دون تخزين الحالة الكاملة للجزئية (shard) المخصصة له. يتم تدوير مدققي الأجزاء عشوائياً عبر الأجزاء في كل حقبة (epoch)، مما يقلل من مخاطر التواطؤ. ونظراً لعدم حاجتهم لتخزين حالة مستمرة، فإن متطلبات أجهزتهم أقل بكثير من متطلبات المدققين المنتجين للكتل.

ما هي شواهد الحالة (state witnesses)؟

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

ما مدى سرعة بروتوكول NEAR؟

تنتج NEAR الكتل تقريبًا كل ثانية واحدة، مما يمنحها أوقات إنهاء معاملات منخفضة مقارنة بالعديد من شبكات الطبقة الأولى (Layer-1). يُقاس معدل الإنتاجية المستمر الحالي عبر الشرائح النشطة بآلاف المعاملات في الثانية (TPS)، مع تصميم البنية لتصل إلى أكثر من 100,000 معاملة في الثانية (TPS) عند التجزئة الكاملة (sharding) وقابلية التوسع للتحقق بدون حالة (stateless validation). للسرعة على NEAR بُعدان: الإنتاجية (TPS عبر جميع الشرائح) وزمن الوصول/الكمون (وقت الإنهاء)، وكلاهما يتحسن مع زيادة عدد الشرائح ضمن نموذج Nightshade.

في أي مرحلة حاليًا خارطة طريق التجزئة (sharding) الخاصة بـ NEAR؟

في أواخر عام 2024، تعمل NEAR في المرحلة الثانية (التحقق عديم الحالة)، والتي نشطت على المينيت. اكتملت كل من المرحلة 0 (إطلاق المينيت بدون تقسيم الحالة) والمرحلة 1 (تقسيم الحالة مع احتفاظ المدقق بالحالة). المرحلة 3+ (إعادة التقسيم الديناميكي، حيث يتوسع عدد الأجزاء بناءً على الطلب) قيد التطوير النشط. تحقق من حالة النشر الحالية وتحديثات خارطة الطريق على near.org/blog.

كيف تختلف NEAR عن Ethereum؟

تختلف شبكة NEAR وإيثيريوم بشكل أساسي في ثلاثة مجالات. أولاً، نهج التجزئة الخاص بهما: تستخدم NEAR تجزئة التنفيذ (Nightshade) لتوزيع معالجة المعاملات؛ بينما تستخدم إيثيريوم تجزئة البيانات (danksharding) لدعم الشبكات التراكمية من الطبقة الثانية، مع ترك توسيع نطاق التنفيذ لتلك الشبكات التراكمية. ثانياً، حالة البنية التحتية عديمة الحالة: تمتلك NEAR ميزة التحقق عديم الحالة النشط؛ بينما لا يزال عمل العميل عديم الحالة في إيثيريوم عبر أشجار Verkle قيد التطوير. ثالثاً، أدوات المطورين: تستخدم بيئة NEAR الأصلية تقنية WASM ولغتي Rust وJavaScript؛ بينما تستخدم إيثيريوم آلة إيثيريوم الافتراضية (EVM) ولغة Solidity بشكل أصلي.

هل بروتوكول NEAR استثمار جيد؟

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

الخاتمة: لماذا يعد التحقق من الصحة عديم الحالة أمراً بالغ الأهمية لمستقبل NEAR

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

المرحلة 3+ (التجزئة الديناميكية) هي المحطة القادمة في خارطة طريق NEAR. ستسمح هذه المرحلة لعدد الأجزاء النشطة بالتوسع تلقائيًا استجابةً لحمل الشبكة، بدلاً من الحاجة إلى ترقيات يدوية للبروتوكول. توفر البنية التي تم بناؤها عبر المرحلة 2 الأساس لكي يعمل هذا التوسع الديناميكي دون زيادة متناسبة في عبء الأجهزة على المدققين الأفراد.

للقراء الذين يرغبون في الاستزادة، فإن الخطوات التالية تعتمد على وجهة نظرك:

• المستثمرون والباحثون: تابعوا الموقع الرسمي لمؤسسة NEAR على near.org ومدونة مؤسسة NEAR للحصول على إعلانات خارطة الطريق، وتحديثات التطوير للمرحلة 3+، وأخبار النظام البيئي.
• المطورون: تغطي وثائق مطوري NEAR على docs.near.org حزمة تطوير NEAR (SDK)، ونشر العقود الذكية بلغة Rust و JavaScript/TypeScript، والهندسة المعمارية التقنية الكاملة لـ Nightshade.
• المدققون ومشغلو العقد: توضح وثائق مدقق NEAR Protocol) متطلبات المدقق، وآليات التخزين المؤقت (staking)، والمواصفات الفنية لكل من منتجي الكتل ومدققي الأجزاء في ظل التحقق عديم الحالة.

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