التحقق عديم الحالة في NEAR: المرحلة الثانية من التجزئة

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

تغطي هذه المقالة ماهية بروتوكول NEAR، وكيفية عمل تجزئة Nightshade، والآليات الدقيقة للتحقق عديم الحالة بما في ذلك دورة حياة شاهد الحالة وهرمية أدوار المدققين، وفوائد اللامركزية وقابلية التوسع، ومقارنة مباشرة مع خارطة طريق Ethereum عديمة الحالة، والآثار المترتبة على المدققين والمُخزِّنين والمطورين، وأي شخص يقيم NEAR لنشر التطبيقات اللامركزية.

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

بروتوكول NEAR هو بلوكتشين من الطبقة الأولى يعتمد على إثبات التخزين (proof-of-stake)، ويستخدم تقنية Nightshade sharding (إطار عمل التقسيم الخاص بـ NEAR) لتقسيم معالجة المعاملات عبر عدة أقسام متوازية، مما يتيح إنتاجية عالية برسوم معاملات تقترب من الصفر. تم تصميم NEAR لنشر التطبيقات اللامركزية على نطاق واسع، مع أدوات للمطورين وهندسة إجماع مبنية على افتراض أن عدد الأقسام سينمو بمرور الوقت.

الهندسة الجوهرية لـ NEAR

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

تؤدي عملة NEAR وظيفتين أساسيتين: دفع رسوم الغاز للمعاملات وتنفيذ العقود، والرهن (staking) كضمان للمدققين لكسب حق المشاركة في آلية الإجماع. تُجمّع عقود NEAR الذكية إلى WebAssembly (WASM)، وهو تنسيق ثنائي محمول يتيح للعقود المكتوبة بلغة Rust أو JavaScript التنفيذ ضمن بيئة تشغيل حتمية. تتبع معالجة المعاملات على NEAR نموذجاً يعتمد على القِطع (chunks)، حيث ينتج كل قسم (shard) قطعة (وهي كتلة على مستوى القسم تُعالج بالتوازي) في كل فاصل زمني للكتلة، وتُجمع كافة القِطع في كتلة أساسية واحدة.

ما الذي يميز NEAR عن غيرها من سلاسل بلوكشين الطبقة الأولى (L1)؟

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

• تجزئة التنفيذ Nightshade: يقوم NEAR بتقسيم كل من الحالة والحساب، وليس فقط توفر البيانات. يختلف هذا عن نهج Danksharding الخاص بالإيثيريوم (EIP-4844)، الذي يستهدف تجزئة توفر البيانات للتراكمية من الطبقة 2 بدلاً من تجزئة التنفيذ.
• التحقق عديم الحالة (المرحلة 2): يعمل مدققو الأجزاء (Chunks) بدون تخزين محلي للحالة، وهو خيار تصميم له آثار مباشرة على اللامركزية وقابلية توسيع الشظايا، ويتم تغطيته بعمق في هذه المقالة.
• بيئة تشغيل العقود الذكية WASM: تعمل العقود ضمن بيئة WASM معزولة (sandbox)، تدعم Rust و JavaScript كلغات تطوير أساسية.
• أسماء حسابات قابلة للقراءة البشرية: تستخدم حسابات NEAR معرفات مسماة بدلاً من تجزئات المفتاح العمومي الخام.
• نموذج تخزين التثبيت (Storage staking): تدفع العقود مقابل التخزين داخل الكتلة عن طريق تثبيت رموز NEAR، مما يربط تكاليف التخزين بالضمانات المثبتة بدلاً من الرسوم لكل بايت.
• رسوم معاملات قريبة من الصفر: تم تصميم هيكل رسوم NEAR ليظل ميسور التكلفة حتى تحت حمل الشبكة المعتدل.

تتوسع سولانا من خلال التوازي في السلسلة الواحدة باستخدام بيئة تشغيل Sealevel الخاصة بها؛ بينما تتوسع NEAR من خلال التجزئة (sharding) عبر أجزاء متوازية ومستقلة. وتعد هذه التوجهات استجابات معمارية مختلفة لنفس مشكلة سعة المعالجة (throughput). وسيتم تناول المقارنة مع إيثيريوم بشكل مفصل لاحقاً في هذا المقال.

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

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

التحقق مع تخزين الحالة مقابل التحقق بدون تخزين الحالة: الفرق الرئيسي

يتمثل الفرق بين التحقق المعتمد على الحالة والتحقق غير المعتمد على الحالة في مكان وجود بيانات الحالة أثناء التنفيذ: سواء مع المدقق، أو مع العمل.

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

لماذا احتاج بروتوكول NEAR إلى التحقق غير المعتمد على الحالة

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

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

--- ## فهم تقنية التجزئة (Sharding): حجر الأساس لقابلية التوسع في شبكة NEAR

يعمل التحقق عديم الحالة لـ NEAR ضمن بنية المشاركة (Sharding) الخاصة بـ Nightshade، والتي تقسم الحالة العامة للشبكة ومعالجة المعاملات عبر أجزاء (shards) متعددة ومتوازية. فهم هذه البنية هو شرط مسبق لشرح الآلية الذي يتبع، لأن التحقق عديم الحالة هو ترقية محددة لكيفية مشاركة المدققين ضمن هيكل Nightshade.

كيف تعمل المشاركة (Sharding) على NEAR

Nightshade هو إطار التجزئة الخاص بـ NEAR Protocol، حيث تُقسم الحالة العامة للبلوكتشين عبر أجزاء (shards) متعددة، ينتج كل منها "تشك" (chunk) (وهو عبارة عن كتلة على مستوى الجزء) في كل فترة زمنية للكتلة. تُنتج تشكات متعددة بالتوازي عبر جميع الأجزاء النشطة وتُجمّع في كتلة واحدة أساسية (canonical block) من قبل منتج الكتلة لتلك الفترة.

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

يتم تعيين المدققين عشوائيًا للأجزاء (shards) في كل حقبة (epoch)، مما يحد من خطر تعرض مجموعة مدققي أي جزء بمفرده لهجوم انتقائي أو الاستيلاء عليها. لا يمتلك المدقق تعيينًا دائمًا لجزء معين؛ بل يتم تدويره مع كل حقبة، مما يوزع المسؤولية والمخاطر عبر الشبكة.

يتم تنفيذ تطبيق Nightshade الكامل عبر ثلاث مراحل. أرست المرحلة الأولى قواعد التجزئة (sharding) الأساسية مع معالجة الأجزاء (chunk processing)، حيث احتفظ المدققون بنسخ كاملة من الحالة المحلية. المرحلة الثانية هي التحقق من الصحة عديم الحالة (stateless validation)، وهو موضوع هذا المقال. المرحلة الثالثة هي إعادة التجزئة الديناميكية (dynamic resharding)، والتي تمنح NEAR القدرة على تعديل عدد الأجزاء تلقائياً بناءً على طلب الشبكة في الوقت الفعلي. للحصول على الوثائق التقنية الكاملة حول نموذج التجزئة في NEAR، راجع docs.near.org/concepts/advanced/sharding.

كيف تعمل آلية التحقق عديم الحالة في NEAR

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

ما هو شاهد الحالة؟

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

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

تغطي دورة حياة شاهد الحالة خمس مراحل متميزة:

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

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

3. البث: يقوم منتج القطعة ببث القطعة وشاهد حالتها معًا إلى مدققي القطع المعينين عشوائيًا لتلك الشاردة لفترة الكتلة الحالية.

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

5. تجاهل: بعد اكتمال التحقق، يتجاهل مدقق القطعة شاهد الحالة. لا يتم الاحتفاظ بالشاهد، ولا تخزينه، ولا استخدامه لتحديث أي قاعدة بيانات محلية للحالة.

بنية الشاهد للحالة محددة رسميًا ضمن مقترحات تحسين NEAR (NEP). للمواصفات الدقيقة ورقم NEP الحالي، انظر مستودع NEAR NEPs على GitHub.). وللحصول على تفاصيل التنفيذ في عميل البروتوكول الأساسي، انظر مستودع nearcore على GitHub.). ### دور مدققي الأجزاء مقابل منتجي الكتل

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

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

تدفق التحقق في ظل التحقق عديم الحالة

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

1. إنتاج الأجزاء (Chunk production): يقوم منتج الأجزاء المعين لكل جزء نشط (shard) ببناء جزء (كتلة على مستوى الجزء) يحتوي على المعاملات المعلقة التي سيتم معالجتها في فترة هذه الكتلة.

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

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

4. التنفيذ غير المرتبط بالحالة: يقوم كل مدقق لمجموعة البيانات (chunk validator) بتنفيذ معاملات المجموعة باستخدام بيانات شاهد الحالة (state witness) فقط، دون إجراء أي بحث محلي عن الحالة في أي وقت. وبعد التنفيذ، يشهد مدقق مجموعة البيانات على صحة المجموعة ويتخلص من شاهد الحالة.

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

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

--- ## فوائد التحقق عديم الحالة لـ NEAR

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

متطلبات أجهزة أقل وتحقيق لامركزية أكبر

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

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

ينبع أثر اللامركزية مباشرة من هذا التغيير في العتاد. تؤدي تكاليف التخزين المنخفضة إلى تقليل إجمالي التكاليف التشغيلية لتشغيل مدقق الأجزاء، مما يقلل من الحاجز الاقتصادي الفعلي للمشاركة. وهذا يتيح وجود مجموعة مدققين أكبر وأكثر تنوعًا جغرافيًا، مما يقلل بدوره من خطر تركز المدققين. إن الشبكة التي يمكن لغالبية مدققيها العمل على عتاد استهلاكي هي أكثر مقاومة هيكليًا للمركزية من الشبكة التي تتطلب أهلية المدقق فيها إنفاقًا رأسماليًا كبيرًا في البنية التحتية للتخزين. يتم الحفاظ على مواصفات متطلبات العتاد الحالية لمدققي الأجزاء في ظل التحقق عديم الحالة في docs.near.org/validator;؛ يرجى مراجعة تلك الوثائق للاطلاع على الأرقام الحالية.

القابلية للتوسع دون التضحية بالأمان

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

تتوسع إنتاجية الشبكة على NEAR بشكل طردي تقريباً مع عدد الأجزاء (shards). ويعني وجود المزيد من الأجزاء النشطة معالجة المزيد من الـ chunks بالتوازي خلال كل فاصل زمني للكتلة، مما يزيد من عدد المعاملات التي يمكن للشبكة تأكيدها في الثانية. ويُعد التحقق عديم الحالة (Stateless validation) المتطلب الأساسي لوصول NEAR إلى أعداد أكبر من الأجزاء على نطاق واسع. توفر وثائق مؤسسة NEAR أرقام الإنتاجية الحالية فور تحديثها؛ وللحصول على بيانات عدد المعاملات في الثانية (TPS) الحالية المرتبطة بإعدادات محددة للأجزاء، راجع docs.near.org.

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

ما يعنيه هذا للمطورين الذين يبنون على NEAR

إذا كنت تقيّم NEAR كمنصَّة نشر، فإن التحقق من الصحة عديم الحالة (stateless validation) يؤثر على تطبيقاتك في طبقة البنية التحتية، وليس في طبقة العقود. هناك أربعة تداعيات عملية يجدر بك فهمها قبل الالتزام بقرار معماري:

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

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

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

مسار مطوري الإيثيريوم. تدعم NEAR شبكة Aurora، وهي بيئة تنفيذ متوافقة مع EVM تسمح لمطوري الإيثيريوم بنشر عقود Solidity على NEAR دون الحاجة إلى إعادة كتابتها بلغة Rust أو JavaScript. تعمل هذه العقود على نفس الشبكة الأساسية وتستفيد من نفس تحسينات البنية التحتية للتحقق عديمة الحالة.

التحقق من الصحة بدون حالة في NEAR مقابل خارطة طريق إيثيريوم للتحقق بدون حالة

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

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

فيما يخص بُعد التجزئة تحديداً: يُعد إطار عمل نايتشايد (Nightshade) الخاص بـ NEAR تصميماً لتجزئة التنفيذ، حيث يُقسّم كلاً من الحالة والحوسبة عبر الأجزاء. أما مقترح دانك شاردينج (Danksharding) الخاص بإيثيريوم فيستهدف تجزئة توفر البيانات للحلول التراكمية في الطبقة 2، وليس تصميماً لتجزئة التنفيذ. هذه أهداف مختلفة معمارياً تخدم هياكل شبكية مختلفة، والمقارنات المباشرة بين نايتشايد (Nightshade) ودانك شاردينج (Danksharding) تتطلب الإقرار بأنهما يعالجان مشكلات مختلفة.

ما هو موقع التحقق عديم الحالة ضمن خارطة طريق NEAR؟

المرحلة الثانية من Nightshade هي التحقق عديم الحالة. من الجدير التوضيح هذا التكافؤ بشكل صريح لأن وثائق NEAR ومناقشات المجتمع تستخدم أحيانًا "المرحلة 2" و"التحقق عديم الحالة" بالتبادل، ومعرفة المرحلة الحالية يحدد حالة هندسة توسع الشبكة.

مراحل Nightshade الثلاث مشروحة

يتم التنفيذ الكامل لـ Nightshade عبر ثلاث مراحل متميزة، حيث تبني كل مرحلة على سابقتها وتضع الشروط المسبقة للمرحلة التالية.

المرحلة الأولى: التجزئة الأساسية (مكتمل)

قامت NEAR بتقسيم حالة شبكتها عبر عدة أجزاء (shards)، حيث يعالج كل جزء المعاملات بالتوازي. احتفظ المدققون بنسخ محلية كاملة لحالة الجزء المخصص لهم. وقام منتجو الكتل بتجميع القطع (chunks) من جميع الأجزاء في كتل أساسية موحدة. أرست المرحلة 1 بنية Nightshade القائمة على القطع، لكنها أبقت متطلبات الأجهزة مرتبطة مباشرة بحجم حالة الجزء، مما أدى إلى خلق سقف للتوسع تعالجه المرحلة 2.

المرحلة 2: التحقق عديم الحالة (المرحلة الحالية)

لم تعد مدققات القطع تحتفظ بحالة التقسيم المحلية. يقوم منتجو القطع بإنشاء شهود الحالة وتسليمهم إلى جانب القطع. هذا يفصل متطلبات أجهزة مدققات القطع عن حجم حالة التقسيم ويمكّن الشبكة من التوسع إلى المزيد من التقسيمات دون زيادة متناسبة في تكاليف أجهزة المدققين. وقت كتابة هذه السطور، تم تفعيل المرحلة الثانية على مينيت NEAR؛ للحصول على تاريخ التفعيل الدقيق وحالة الشبكة الحالية، استشر مدونة مؤسسة NEAR) و docs.near.org، حيث يتم تفعيل مراحل البروتوكول تدريجيًا ويتم تحديث الوثائق وفقًا لذلك.

المرحلة الثالثة: إعادة التجزئة الديناميكية (مخطط لها)

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

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

التحقق عديم الحالة من NEAR: الآثار المترتبة على المدققين والمُخزّنين

بالنسبة لمدققي الأجزاء (chunk validators)، يزيل التحقق عديم الحالة (stateless validation) أكبر مسبب منفرد لتكاليف الأجهزة في بنية NEAR السابقة: وهو متطلب الاحتفاظ بـ نسخ محلية كاملة من حالة الشظية (shard state). ولهذا الأمر انعكاسات مباشرة على اقتصاديات تشغيل المدقق وإمكانية الوصول العملية للمشاركة كمدقق.

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

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

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

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

لتصبح مدققًا على NEAR، يقوم المشارك برهن رموز NEAR بما يتجاوز حد المقعد الحالي وتشغيل برنامج المدقق. للحصول على تعليمات الإعداد الكاملة ومواصفات الأجهزة الحالية المحدثة لتعكس متطلبات التحقق من الصحة بدون حالة (stateless validation)، يرجى مراجعة docs.near.org/validator مباشرةً.

الأسئلة الشائعة

لماذا يُستخدم بروتوكول NEAR؟

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

كيف يعمل بروتوكول NEAR؟

في جوهرها، تعمل NEAR كشبكة بلوكتشين تعتمد على إثبات التخزين ومقسمة إلى عدة أقسام (shards)، حيث يعالج كل قسم المعاملات بالتوازي. ينتج كل قسم "كتلة فرعية" (chunk) (وهي كتلة على مستوى القسم) في كل فاصل زمني للكتل؛ ويقوم منتج كتل بتجميع هذه الكتل الفرعية في كتلة معيارية واحدة. يتم تعيين المدققين عشوائياً للأقسام في كل حقبة (epoch) ويكونون مسؤولين عن تنفيذ المعاملات والمصادقة عليها في الكتلة الفرعية للقسم المخصص لهم، مع تمكين التحقق بدون حالة (stateless validation) لمدققي الكتل الفرعية من أداء هذا الدور دون الحفاظ على حالة القسم المحلية.

ما هو تقسيم نايتشيد (Nightshade sharding)؟

Nightshade هو إطار عمل التجزئة (sharding) لبروتوكول NEAR، حيث يتم تقسيم الحالة العالمية للشبكة ومعالجة المعاملات عبر عدة أجزاء (shards) متوازية. وبخلاف التصاميم التي تعامل كل جزء كـ البلوكتشين منفصل، يعامل Nightshade جميع الأجزاء كمكونات لـ البلوكتشين منطقي واحد، بحيث تحتوي كل كتلة على قطعة واحدة (chunk) لكل جزء نشط. يتم تنفيذ Nightshade عبر ثلاث مراحل: التجزئة الأساسية (المرحلة 1)، والتحقق عديم الحالة (المرحلة 2)، وإعادة التجزئة الديناميكية (المرحلة 3).

ما هو شاهد الحالة (state witness) في البلوكتشين؟

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

كيف يعمل مدققو NEAR؟

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

كيف يعمل التحقق عديم الحالة على تحسين القابلية للتوسع؟

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

هل يُعد NEAR نظام بلوكتشين جيد للمطورين؟

يوفر NEAR Protocol للمطورين عقودًا ذكية قائمة على WASM يمكن كتابتها بلغة Rust أو JavaScript، ونموذج تخزين يتعهد يربط تكاليف تخزين العقود برموز NEAR المتعهدة، وتوافق Aurora EVM لمطوري Ethereum الذين ينشرون عقود Solidity، وأسماء حسابات سهلة القراءة. التحقق عديم الحالة (Stateless validation) هو تحسين للبنية التحتية على مستوى البروتوكول يفيد جميع العقود المنشورة تلقائيًا، دون الحاجة لأي تغييرات في الكود. مع زيادة عدد الشرائح (shards)، تنمو سعة إنتاجية الشبكة وتستفيد العقود من تقليل الازدحام. يجب على المطورين الذين يقيمون NEAR لنشر التطبيقات اللامركزية (dApps) للإنتاج استشارة docs.near.org لمواصفات SDK الحالية وتوثيق الأدوات.

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

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