نموذج حسابات NEAR: الأسماء والمفاتيح والتخزين

المحتويات

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

ما هو بروتوكول NEAR؟ (مقدمة موجزة)

NEAR Protocol عبارة عن بروتوكول بلوكتشين من الطبقة الأولى (Layer-1) يعتمد على آلية إثبات تخزين (proof-of-stake)، وقد صُمم لتسهيل وصول المطورين، مع رسوم معاملات منخفضة ومتوقعة وهيكل تجزئة (sharding) مصمم للتوسع دون التضحية بسهولة الاستخدام. شارك في تأسيسه إليا بولوسوخين وألكسندر سكيدانوف، وصُمم NEAR Protocol منذ البداية مع وضع تجربة المطور وسهولة وصول المستخدم النهائي كأهداف أساسية، بدلاً من تعديل سهولة الاستخدام لتناسب بنية صُممت لأغراض أخرى.

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

إن أوضح تعبير عن فلسفة "المطور أولاً" هذه هو نموذج حسابات NEAR، وهو تصميم يعيد التفكير في كيفية عمل إدارة الهوية والأذونات في البلوكتشين من الأساس.

باختصار: لمحة عن نموذج حساب NEAR

ملخص سريع للقراء العابرين:

• تستخدم حسابات NEAR أسماء قابلة للقراءة البشرية (مثل alice.near) بدلاً من سلاسل تجزئة تشفيرية مثل عناوين Ethereum التي تبدأ بـ 0x742d35Cc....
• يمكن لكل حساب أن يمتلك مفاتيح وصول متعددة في وقت واحد، ولكل منها مستوى أذونات خاص به، من التحكم الكامل غير المقيد إلى تفاعلات العقود المحدودة النطاق.
• يمكن لأي حساب NEAR نشر عقد ذكي؛ لا يوجد نوع حساب عقد منفصل كما هو الحال في Ethereum.
• تتبع الحسابات الفرعية مساحة أسماء هرمية (مثل contract.myapp.near تحت myapp.near) ، وتعمل مثل النطاقات الفرعية لحسابات البلوكتشين.
• يجب أن تحافظ الحسابات على حد أدنى من رصيد رموز NEAR بما يتناسب مع استخدام التخزين الخاص بها داخل الكتلة، وهي آلية تسمى تخزين الضمان للمساحة.
• يحقق نظام أذونات المفاتيح المتعددة الأصلي في NEAR العديد من الأهداف التي تسعى Ethereum لتحقيقها من خلال تجريد الحساب (EIP-4337)، ولكن من خلال نهج معماري مختلف تم بناؤه منذ البداية.

ما هو نموذج حساب NEAR؟

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

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

يحتوي حساب NEAR على خمسة عناصر في وقت واحد: معرّف حساب فريد، ورصيد من رموز NEAR، وحالة الحساب (تخزين البيانات داخل الكتلة)، وعقد ذكي اختياري تم نشره وتجميعه إلى WebAssembly (WASM، مما يتيح العقود المكتوبة بلغة Rust أو JavaScript)، ومفتاح وصول واحد أو أكثر بمستويات أذونات متميزة. يعني هذا الهيكل الموحد عدم وجود فصل بين "حسابات المستخدمين" و"حسابات العقود الذكية" كما هو الحال في Ethereum. يمكن لأي حساب NEAR استضافة عقد ذكي اختيارياً دون أن يصبح فئة مختلفة من الكائنات. تعمل الحسابات التي لا تحتوي على عقود منشورة كحسابات مستخدمين عادية؛ بينما تكون الحسابات التي تحتوي على عقود منشورة حسابات مستخدمين ومضيفة للعقود في آن واحد.

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

للحصول على المواصفات الفنية الكاملة، راجع وثائق نموذج حساب بروتوكول NEAR في docs.near.org/concepts/basics/accounts/model.

الحسابات المسماة والحسابات الضمنية: كيف تحدد NEAR المستخدمين

تتعرف شبكة NEAR على المستخدمين والتطبيقات داخل الكتلة من خلال تنسيقين للحسابات: الحسابات المسماة، التي تستخدم سلاسل نصية سهلة القراءة مثل alice.near، والحسابات الضمنية، وهي عبارة عن سلاسل نصية بنظام الستة عشر (hex) مكونة من 64 حرفاً مشتقة من المفتاح العمومي.

الحسابات المسماة: هويات البلوكتشين سهلة القراءة

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

التباين فوري: alice.near مقابل 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. كلاهما معرفات صالحة على البلوكتشين، لكن أحدهما قابل للقراءة والآخر يتطلب تحقُّقًا دقيقًا عند النسخ واللصق. فكر في حساب NEAR المسمى كعنوان بريد إلكتروني: قابل للقراءة ومرتبط بهوية، بدلاً من سلسلة عشوائية من الأحرف التي تتطلب مقارنة حرف بحرف للتحقق.

تتبع الحسابات المسماة قواعد تسمية محددة: معرفات الحسابات هي سلاسل أبجدية رقمية، يمكنها استخدام النقاط كفواصل، ويجب أن يتراوح طولها بين 2 و 64 حرفًا، ويجب أن تنتهي بـ .near على مينيت أو .testnet على الشبكة التجريبية. ينشئ الهيكل المفصول بنقاط تسلسلًا هرميًا يشبه النطاق: myapp.near هو حساب مسمى من المستوى الأعلى، و contract.myapp.near هو حساب فرعي تحته (المزيد عن الحسابات الفرعية في القسم التالي).

تتجاوز دوافع تجربة المستخدم وراء الحسابات المسماة مجرد الجماليات. المعرفات القابلة للقراءة تقلل من خطر إرسال المعاملات إلى حسابات خاطئة، وتجعل عناوين العقود قابلة للاكتشاف، وتقلل العبء المعرفي لإدارة الهويات داخل الكتلة. بالنسبة لأي شخص قام بالتحقق ثلاث مرات من عنوان MetaMask قبل إرسال معاملة، فإن جاذبية alice.near بدلاً من سلسلة سداسية عشرية مكونة من 42 حرفًا هي أمر ملموس بدلاً من كونه مجردًا. يقوم المستخدمون بتسجيل وإدارة الحسابات المسماة من خلال MyNEARWallet على mynearwallet.com، وهي واجهة الحساب الأساسية التي تحتفظ بها المجتمع (تم إهمال wallet.near.org الأصلية التي تديرها NEAR Foundation).

الحسابات الضمنية: تنسيق الحساب البديل

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

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

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

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

حسابات فرعية: تنظيم الحسابات الهرمي على NEAR

تعمل الحسابات الفرعية في NEAR مثل النطاقات الفرعية على الويب: تماماً كما أن docs.myapp.com وapi.myapp.com هما عنوانان مميزان تحت نطاق myapp.com؛ فإن token.myapp.near وstaking.myapp.near هما حسابات البلوكتشين مميزة تحت مساحة الاسم myapp.near.

الحساب الفرعي هو حساب يقع معرفه ضمن نطاق حساب رئيسي. الحساب contract.myprotocol.near هو حساب فرعي لـ myprotocol.near. يمكن للحساب الرئيسي فقط إنشاء حساب فرعي: يمكن لـ myprotocol.near إنشاء contract.myprotocol.near، ولكن لا يمكن لأي حساب آخر إنشاء حساب تحت هذا النطاق دون تفويض من الحساب الرئيسي.

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

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

بالنسبة لمطوري التطبيقات اللامركزية (dApp)، توفر الحسابات الفرعية نمطاً معمارياً عملياً. وبما أن أي حساب على NEAR يمكنه نشر عقد ذكي (مترجم إلى WASM)، تصبح الحسابات الفرعية وسيلة طبيعية لمنح كل مكون من مكونات العقد معرف حساب مقروءاً ومنظماً. قد يقوم بروتوكول DeFi بنشر token.myprotocol.near لعقد الرمز المميز الخاص به، و staking.myprotocol.near لعقد التحصيص الخاص به، و governance.myprotocol.near لعقد الحوكمة الخاص به. كل واحد منها عبارة عن حساب مستقل له عقده الخاص وحالته الخاصة وإدارة مفاتيحه الخاصة، ولكن مساحة الأسماء تجعل العلاقة بين المكونات واضحة تماماً لأي شخص يقرأ السلسلة. للحصول على تعليمات إنشاء حساب فرعي خطوة بخطوة، راجع وثائق حساب NEAR الفرعي في docs.near.org/concepts/basics/accounts/model#named-accounts.

إن فهم كيفية تسمية الحسابات وتنظيمها يمهد الطريق للطبقة المعمارية التالية: كيفية تأمينها ومنح الأذونات لها من خلال مفاتيح الوصول.

مفاتيح الوصول NEAR: الوصول الكامل مقابل أذونات استدعاء الوظائف

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

كيف يعمل نظام NEAR متعدد المفاتيح

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

تستخدم مفاتيح وصول NEAR أزواج مفاتيح Ed25519 افتراضيًا (مع دعم secp256k1 أيضًا لضمان التوافق مع مجموعة أدوات Ethereum). إن نظام الصلاحيات المبني فوق أزواج المفاتيح هذه هو ما يجعل نموذج NEAR متميزًا من الناحية المعمارية. تخيل الأمر كأنه حلقة مفاتيح: مفتاح الوصول الكامل (Full Access Key) هو المفتاح الرئيسي الذي يفتح كل قفل، بينما مفتاح وصول استدعاء الوظائف (Function Call Access Key) هو مفتاح مخصص يفتح بابًا واحدًا محددًا فقط. تستهلك كل معاملة يتم توقيعها بواسطة أي مفتاح وصول في الحساب "غاز" (gas) يتم دفعه برموز NEAR، إلا أن رسوم المعاملات في NEAR منخفضة ويمكن التنبؤ بها حسب التصميم، وذلك على عكس تسعير الغاز في Ethereum الذي اتسم بالتقلب تاريخيًا.

لمزيد من التفاصيل حول إضافة وإدارة مفاتيح الوصول برمجياً، راجع وثائق مرجع مفاتيح الوصول NEAR على docs.near.org/concepts/basics/accounts/access-keys.

مفاتيح الوصول الكاملة: تحكم غير مقيد بالحساب

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

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

تعد المقارنة مع إيثيريوم (Ethereum) مفيدة هنا. في إيثيريوم، يعمل مفتاحك السري الوحيد للحساب المملوك خارجيًا (EOA) كـ "مفتاح وصول كامل": فهو يتحكم في كل شيء، ولا توجد طريقة أصلية لمنح تطبيق لامركزي (dApp) مفتاحاً بصلاحيات أقل لتفاعل محدد مع العقد. إن كل اتصال بتطبيق لامركزي عبر MetaMask يعرض مفتاح حسابك الكامل لتدفق توقيع المعاملات. وقيد المفتاح الواحد هذا هو بالضبط المشكلة التي صُمم تجريد الحساب (EIP-4337) لمعالجتها في إيثيريوم. أما في نير (NEAR)، فقد تم دمج الحل في نموذج الحساب الأساسي.

مفاتيح الوصول لاستدعاء الوظائف: صلاحيات محددة النطاق لأمان التطبيقات اللامركزية

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

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

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

تتحكم مفاتيح الوصول في الإجراءات التي يمكن للحساب اتخاذها. تخزين التخزين يحكم ما يجب على الحساب الاحتفاظ به لكي يوجد داخل الكتلة.

مشاركة التخزين: لماذا تتطلب حسابات NEAR حدًا أدنى للرصيد

رهان التخزين على NEAR هو الآلية التي يجب بموجبها على كل حساب الاحتفاظ بحد أدنى من رصيد رموز NEAR يتناسب مع حجم التخزين داخل الكتلة (الحالة) الذي يستخدمه الحساب.

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

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

بشكل ملموس، يبلغ معدل تخزين الستاكينغ حوالي 1 توكن NEAR لكل 10 كيلوبايت من التخزين داخل الكتلة، ويتطلب حساب NEAR فارغ تم إنشاؤه حديثًا رصيدًا أدنى يبلغ حوالي 0.00182 NEAR لتغطية بصمة حالته الأساسية. تحقق من الأرقام الحالية مقابل وثائق تخزين الستاكينغ الخاصة بـ NEAR على docs.near.org/concepts/storage/storage-staking قبل الاعتماد على هذه الأرقام لتخطيط التطوير، حيث تتغير معلمات البروتوكول مع الترقيات.

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

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

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

تُعد رسوم الغاز (تكاليف تنفيذ المعاملات) منفصلة عن رهن التخزين. يتم استهلاك رسوم الغاز لكل معاملة وتُدفع برموز NEAR في وقت التوقيع؛ أما رهن التخزين فهو رصيد محجوز يظل مرتبطاً بالحساب طالما بقيت الحالة المرتبطة موجودة.

إن فهم رهن التخزين يكمل الصورة حول كيفية عمل حسابات NEAR بشكل منفرد. والسؤال التالي هو كيف تقارن هذه البنية ببنية إيثيريوم.

نموذج حساب NEAR مقابل إيثيريوم: مقارنة جنباً إلى جنب

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

نظام حسابي إيثيريوم ذي الحسابين مقابل نموذج NEAR للحساب الموحد

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

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

يلغي نوع الحساب الموحد في NEAR الفصل بين حسابات المستخدم العادية (EOA) والعقود الذكية. كل حساب في NEAR هو بطبيعته مضيف للعقود الذكية، ونظام المفاتيح المتعددة مع مفاتيح الوصول لاستدعاء الدوال (Function Call Access Keys) يعالج قيود المفتاح الواحد دون الحاجة إلى طبقة بروتوكول منفصلة. يعمل كل من NEAR و Ethereum ضمن نموذج يعتمد على الحسابات، على عكس نموذج UTXO الخاص ببيتكوين حيث يتم تتبع الأرصدة كمخرجات معاملات غير منفق عليها بدلاً من حالة الحساب؛ يكمن الاختلاف بين NEAR و Ethereum في كيفية هيكلة تلك الحسابات ومنحها الأذونات، وليس في النموذج الأساسي.

نموذج حساب NEAR وتجريد الحساب الخاص بـ Ethereum (EIP-4337)

يُعد EIP-4337 (تجريد الحساب) مسعى من إيثيريوم لمنح الحسابات المملوكة خارجيًا (EOAs) ذلك النوع من ميزات الأذونات القابلة للبرمجة وإمكانيات مفاتيح الجلسة التي صُمم نموذج حسابات NEAR ليشملها منذ البداية.

يُعد معيار EIP-4337 معياراً مفعلاً لشبكة إيثيريوم (وليس مجرد مقترح نظري) يُمكّن محافظ العقود الذكية من العمل كعناصر أساسية، مما يدعم التحقق البرمجي من المعاملات، ومفاتيح الجلسات، والاسترداد الاجتماعي، والمعاملات المدعومة. يتطلب هذا المعيار بنية تحتية محددة للمجمّعين (bundlers) ليعمل، وهو مُطبق بفعالية عبر منظومة إيثيريوم، على الرغم من أنه ليس ترقية شاملة يتم تطبيقها على جميع الحسابات تلقائياً.

التوازي مع مفاتيح الوصول لاستدعاء الوظائف (Function Call Access Keys) الخاصة بـ NEAR حقيقي: كلا النهجين يعالجان مشكلة منح التطبيقات اللامركزية (dApps) وصولاً محدود الصلاحيات والنطاق لتفاعلات محددة دون كشف مفتاح الحساب بالكامل. سيجد المطور المعتاد على مفاتيح جلسات EIP-4337 مفاتيح الوصول لاستدعاء الوظائف الخاصة بـ NEAR مألوفة من الناحية المفاهيمية. الفارق المهم هو أن هذه تطبيقات مميزة هيكليًا لأفكار متداخلة، وليست أنظمة متطابقة. نموذج الأذونات المتعددة للمفاتيح في NEAR هو جزء أصيل من البروتوكول الأساسي؛ EIP-4337 يضيف منطق محفظة العقد الذكي فوق نموذج حسابات المستخدمين القياسية (EOA) الحالي في إيثيريوم. المشاكل التي يعالجونها تتداخل بشكل كبير؛ الآليات تختلف. للمواصفات الكاملة لـ EIP-4337، راجع مواصفات تجريد الحساب EIP-4337 على eips.ethereum.org/EIPS/eip-4337.

للمطورين في إيثيريوم الذين يقيمون NEAR، هناك جسران للنظام البيئي جديران بالملاحظة. Aurora على aurora.dev، وهي بيئة متوافقة مع EVM مبنية على NEAR، تسمح لمطوري إيثيريوم بنشر عقود Solidity على بنية NEAR التحتية، بينما تعمل حسابات NEAR كطبقة الهوية الأساسية. يمكن للمطورين العاملين عبر كلا النظامين البيئيين استخدام Rainbow Bridge على rainbowbridge.app لنقل الأصول بين حسابات NEAR وعناوين إيثيريوم دون الاعتماد على الحفظ المركزي.

الآن وبعد أن أصبحت البنية واضحة، إليك ما يتطلبه إنشاء وإدارة حساب NEAR فعلياً من الناحية العملية.

دليل البدء: إنشاء وإدارة حساب NEAR الخاص بك

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

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

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

هناك ثلاث مخاطر يجدر بك معرفتها قبل البدء. أولاً، إذا فقدت مفتاح الوصول الكامل الخاص بك ولم يتم تكوين آلية استرداد، فلن يكون الحساب قابلاً للاسترداد. قم بتخزين مفتاح الوصول الكامل الخاص بك في التخزين البارد وقم بتكوين أي خيارات استرداد متاحة قبل الحاجة إليها. ثانياً، رموز NEAR المحجوزة لتأمين التخزين تكون مقفلة طالما كانت الحالة المرتبطة موجودة؛ هذا التزام رأسمالي، وليس رسومًا. ثالثاً، حذف الحساب على NEAR لا رجعة فيه. للحصول على دليل شامل لإنشاء الحساب خطوة بخطوة، راجع وثائق مطوري NEAR على docs.near.org/concepts/basics/accounts/model.

تتم الإجابة أدناه على الأسئلة الأكثر شيوعاً حول نموذج حساب NEAR.

أسئلة متكررة: نموذج حساب NEAR

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

هل يمكن لأي حساب NEAR نشر عقد ذكي؟

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

كيف تجعل مفاتيح الوصول في NEAR التطبيقات اللامركزية (dApps) أكثر أمانًا للاستخدام؟

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

ماذا يحدث إذا فقدت مفتاح الوصول الكامل الخاص بي؟

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

هل رسوم الغاز هي نفسها رهن التخزين؟

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

كيف يرتبط نموذج حساب NEAR بتجريد الحساب في إيثيريوم (EIP-4337)؟

يحقق نظام NEAR الأصلي متعدد المفاتيح والصلاحيات العديد من الأهداف التي تم تصميم EIP-4337 لإضافتها إلى Ethereum، بما في ذلك الأذونات المقيدة المستندة إلى الجلسة لتفاعلات التطبيقات اللامركزية (dApps) ومنطق المفاتيح القابل للبرمجة. التنفيذان متميزان من الناحية المعمارية لأفكار متداخلة: نهج NEAR أصلي للبروتوكول الأساسي، بينما يضيف EIP-4337 منطق محافظ العقود الذكية فوق نموذج حسابات المستخدمين الخارجية (EOA) الحالي في Ethereum. إنهما يحلان مشاكل متشابهة من خلال معماريات مختلفة. انظر قسم NEAR مقابل Ethereum للمقارنة التفصيلية.

ما الفرق بين الحساب المسمى والحساب الضمني على NEAR؟

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

كم عدد مفاتيح الوصول التي يمكن لحساب NEAR واحد امتلاكها؟

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

هل يعني تخزين التخزين أنني سأفقد رموز NEAR الخاصة بي؟

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

خاتمة: ما يعنيه نموذج حساب NEAR للمطورين والمستخدمين

يعكس نموذج حساب NEAR مجموعة من الخيارات المعمارية المدروسة: أسماء الحسابات سهلة القراءة تخفض حاجز الدخول وتقلل أخطاء المعاملات؛ نظام الأذونات متعدد المفاتيح يقلل المخاطر الأمنية لتفاعلات التطبيقات اللامركزية (dApps) عبر تحديد نطاق وصول طرف ثالث دون كشف المفاتيح الرئيسية؛ التخزين المكدس (storage staking) يخلق توافقاً اقتصادياً بين استخدام الموارد والتكلفة؛ وهيكل الحساب-العقد الموحد يلغي فصل الحسابات الخارجية (EOA) عن العقود الذي يضيف احتكاكًا لتطوير الإيثيريوم.

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

الخطوات التالية حسب فئة المستخدم:

• المطورون: ابدأ التطوير على NEAR Protocol في docs.near.org/develop
• المستخدمون: أنشئ حساب NEAR الخاص بك على MyNEARWallet at mynearwallet.com
• الباحثون: تعمق في مواصفات نموذج الحساب الكامل في NEAR Protocol account model documentation at docs.near.org/concepts/basics/accounts/model)

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