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

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

يُعد بروتوكول NEAR عبارة عن بلوكتشين طبقة 1 يعمل بآلية إثبات التخزين (PoS)، وقد أطلق المينيت الخاص به في عام 2020. تم إنشاؤه بواسطة شركة NEAR Inc. (التي تعمل الآن باسم Pagoda)، وهي مؤسسة لأدوات المطورين تواصل صيانة NEAR SDK والبنية التحتية الأساسية للبروتوكول. يستخدم بروتوكول NEAR تقنية Nightshade للتجزئة (sharding) لتقسيم الشبكة إلى أجزاء متوازية، وتلعب معرفات الحسابات دوراً في تخصيص الأجزاء، وهو أمر يهم المطورين الذين يفكرون في أنماط استدعاء العقود المتقاطعة.

أربع خصائص تميز نموذج حساب NEAR عن أنظمة حسابات طبقة 1 الأخرى:

["- Account IDs are human-readable strings, not random hexadecimal sequences","- A single account can hold an unlimited number of access keys, each with its own permission scope","- Any account can hold both a token balance and a deployed smart contract, with no architectural distinction between "user accounts" and "contract accounts"","- Accounts must maintain a NEAR token balance proportional to their on-chain storage usage, a mechanism called storage staking"]

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

انتقل إلى قسم:

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

معرفات حساب NEAR: الحسابات المسماة والحسابات الضمنية

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

الحسابات المسماة: معرفات قابلة للقراءة البشرية

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

يتطلب تسجيل حساب مسمى إيداعاً صغيراً من رموز NEAR. لإنشاء حساب، قم بزيارة واجهة محفظة متوافقة مع NEAR مثل MyNEARWallet أو Meteor Wallet، واختر معرف حسابك، وقم بتمويل إيداع التسجيل. يمكن للحسابات المسماة أيضاً إنشاء حسابات فرعية ضمن مساحة الاسم الخاصة بها (على سبيل المثال، يمكن لـ alice.near إنشاء app.alice.near)، وهو موضوع تمت تغطيته بالكامل في قسم الحسابات الفرعية أدناه.

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

الحسابات الضمنية: مشتقة من المفاتيح العامة

الحساب الضمني هو معرّف حساب بنظام ستة عشري مكون من 64 خانة، مشتق بشكل حتمي من مفتاح عمومي من نوع Ed25519. يبدو مثال لمعرّف حساب ضمني كالتالي: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. بالنسبة للمطورين القادمين من إيثيريوم، يعد هذا النوع من الحسابات هو الأكثر ألفة من حيث الهيكل، لأن عملية الاشتقاق مماثلة لكيفية حساب عناوين إيثيريوم من المفاتيح العمومية.

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

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

الحسابات المسماة مقابل الحسابات الضمنية: مقارنة جنبًا إلى جنب

يختلف نوعا معرّف الحساب عبر خمسة أبعاد:

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

مفاتيح الوصول NEAR: كيف تعمل أذونات الحساب

تُعد مفاتيح الوصول الخاصة بـ NEAR طبقة التفويض لنموذج الحساب. يمكن لكل حساب NEAR الاحتفاظ بعدة مفاتيح وصول في وقت واحد، ويحمل كل مفتاح نطاق إذن مميز. يمكن لحساب NEAR الاحتفاظ بعدد غير محدود من مفاتيح الوصول في آن واحد. كل مفتاح هو زوج مفاتيح تشفير Ed25519 مستقل، ويمكنك إضافة أو إزالة المفاتيح دون إنشاء حساب جديد. تتم إضافة المفاتيح عبر معاملة موقعة بواسطة مفتاح وصول كامل (Full Access Key) موجود، وذلك باستخدام NEAR CLI (near add-key) أو برمجياً عبر SDK.

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

مفاتيح الوصول الكامل: بيانات الاعتماد الرئيسية

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

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

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

مفاتيح الوصول لاستدعاء الدوال: أذونات محددة النطاق للتطبيقات اللامركزية (dApps)

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

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

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

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

ملاحظة للمطور: تتيح مفاتيح الوصول لاستدعاء الوظائف (Function Call Access Keys) أنماط مفاتيح الجلسة في التطبيقات اللامركزية (dApps). يمكن للمستخدم تفويض مفتاح لجلسة لعب أو جلسة تداول DeFi، ويعمل التطبيق ضمن هذا النطاق دون الحاجة إلى موافقات لكل معاملة. يعد هذا أحد أهم فروق تجربة المستخدم (UX) ذات الصلة بالمطورين بين البناء على NEAR مقابل Ethereum.

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

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

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

رهن التخزين: كيف يربط NEAR رصيد الرموز بالتخزين داخل الكتلة

يُعد تخصيص رصيد للتخزين (Storage Staking) أحد مكونات بنية حساب NEAR التي تتجاهلها معظم المصادر التعليمية للبلوكتشين، ولكنه يحمل آثارًا عملية مباشرة لكل مطور يبني على NEAR ولكل مستخدم يدير حسابًا.

لماذا يتطلب NEAR رصيدًا من الرموز للتخزين

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

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

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

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

التخزين بالرهن عمليًا: ما يعنيه للحسابات والعقود

يؤثر تحصيص مساحة التخزين على الحسابات على ثلاثة مستويات:

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

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

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

حسابات NEAR الفرعية: مساحات أسماء الحسابات الهرمية

حساب NEAR الفرعي هو حساب يُسبق معرّفه بمعرّف الحساب الأساسي. على سبيل المثال، يعد app.alice.near حساباً فرعياً لـ alice.near‏، وفقط alice.near يمكنه إنشاء حسابات في نطاق الأسماء هذا.

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

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

نمط الاستخدام النموذجي لفرق البروتوكول يكون على النحو التالي:

myprotocol.near → token.myprotocol.near → staking.myprotocol.near → dao.myprotocol.near

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

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

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

نموذج حساب NEAR مقابل إيثيريوم: الاختلافات المعمارية الرئيسية

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

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

تستخدم NEAR نموذجاً موحداً. يمكن لأي حساب NEAR أن يمتلك رصيداً من الرموز المميزة وأن يتم نشر عقد ذكي عليه في آن واحد. لا يوجد نوع منفصل لـ "حساب العقد". يمكن للحساب alice.near الاحتفاظ برموز NEAR، وتشغيل عقد WASM منشور، والاحتفاظ بمفاتيح وصول متعددة بنطاقات أذونات مختلفة، كل ذلك ككائن بروتوكول واحد. يمكن لأي حساب NEAR أن يحتوي على عقد ذكي، ورصيد من الرموز المميزة، ومفاتيح وصول متعددة في نفس الوقت.

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

ملاحظة: يمكن تشغيل العقود الذكية المتوافقة مع الإيثيريوم على NEAR عبر Aurora، وهي طبقة توافق EVM مُنشَرة كعقد ذكي على NEAR. Aurora هي طبقة منفصلة؛ التطوير الأصلي لـ NEAR يستخدم WebAssembly (WASM) مُجمَّعة من Rust أو JavaScript، وليس Solidity. راجع وثائق نموذج حساب الإيثيريوم) للمواصفات الكاملة لحساب الإيثيريوم.

ماذا تعني بنية الحسابات الموحدة في بروتوكول NEAR من الناحية العملية

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

ضع في اعتبارك حساب NEAR واحد، alice.near. يمكن لحساب أليس بشكل متزامن:

1. امتلاك رصيد من رموز NEAR المميزة
2. وجود عقد ذكي منشور عليه، ومُترجم برمجياً إلى WebAssembly (WASM) من لغة Rust
3. امتلاك ثلاثة مفاتيح وصول: مفتاح وصول كامل مخزن في محفظة الأجهزة الخاصة بها، ومفتاح وصول كامل على جهاز الكمبيوتر المحمول الخاص بها، ومفتاح وصول لاستدعاء الوظائف ممنوح لتطبيق DeFi لا مركزي (dApp) للتداول القائم على الجلسات
4. امتلاك حسابين فرعيين (app.alice.near لعقد لعبة منشور، وvault.alice.near لعقد خطط المُدَّخرات)، يتم التحكم في كل منهما بشكل مستقل

معرّف حساب أليس قابل للقراءة والمشاركة. وهي لا تضطر أبداً لنسخ سلسلة سداسية عشرية مكونة من 42 حرفاً لاستلام الرموز المميزة أو التفاعل مع عقد ما.

للمطورين، فإن التبعات العملية جوهرية. تقضي أنماط مفاتيح الجلسة على احتكاك المحفظة لكل معاملة في الألعاب والتطبيقات الاجتماعية. تسمح بنية الحسابات الفرعية لفرق البروتوكول بنشر عقود وحداتية بمسارات ترقية مستقلة. يخلق تخزين التثبيت نموذج تكلفة يمكن التنبؤ به للبيانات داخل الكتلة، والذي يجب أن يؤخذ في الاعتبار في اقتصاديات الإعداد onboarding. يمكن للحسابات أيضًا التفاعل مع جسر Rainbow Bridge لنقل الأصول بين NEAR و Ethereum، ويتم إدارتها عبر واجهات محافظ متوافقة مع NEAR مثل MyNEARWallet أو Meteor Wallet.

بالنسبة للمستخدمين النهائيين، يُترجم نموذج الحساب إلى معرفات حسابات مقروءة تعمل كأسماء مستخدمين، وجلسات تطبيقات لامركزية (dApp) لا تقاطع التجربة بالنوافذ المنبثقة للمحافظ، ونموذج تدوير المفاتيح الذي يسمح باسترداد الحساب دون الاعتماد على العبارة الأوَّلية الواحدة.

الأسئلة الشائعة حول نموذج حساب NEAR

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

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

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

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

ما هو تخزين التخزين (Storage Staking) في بروتوكول NEAR؟

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

هل يمكن لحساب NEAR أن يحتوي على عقد ذكي؟

نعم. يمكن لأي حساب NEAR أن يتم نشر عقد ذكي عليه. على عكس الإيثيريوم، التي تفصل الحسابات المملوكة خارجيًا (حسابات المستخدم التي لا يمكنها الاحتفاظ بالتعليمات البرمجية) عن حسابات العقود (حسابات تحتفظ بالكود بدون مفتاح سري)، يستخدم NEAR نموذج حساب موحدًا حيث يمكن لأي حساب أن يحتفظ في نفس الوقت برصيد رمز NEAR وكود عقد منشور. يتم ترجمة العقود على NEAR إلى WebAssembly (WASM) من كود مصدر Rust أو JavaScript، وليس Solidity. انظر قسم مقارنة الإيثيريوم للحصول على التفاصيل المعمارية الكاملة.

ماذا يحدث إذا انخفض رصيد حساب NEAR الخاص بي عن متطلبات التخزين؟

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

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

الحساب الفرعي في NEAR هو حساب يُسبق معرّفه (ID) بمعرّف حساب أب. على سبيل المثال، app.alice.near هو حساب فرعي لـ alice.near، ولا يمكن لـ alice.near فقط إنشاء حسابات في هذا النطاق. بعد الإنشاء، لا يتحكم الحساب الأب في الحساب الفرعي. الحساب الفرعي مستقل تمامًا ولديه مفاتيح الوصول الخاصة به، ورصيد توكن NEAR الخاص به، وحالته داخل الكتلة الخاصة به. سلطة التسمية الخاصة بالحساب الأب تقتصر على فعل الإنشاء. راجع قسم الحسابات الفرعية للشرح الكامل.

كيف يختلف NEAR Protocol عن Ethereum من حيث الحسابات؟

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

ما هو مفتاح الوصول الكامل مقابل مفتاح استدعاء الوظيفة على NEAR؟

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

كيف يبدو معرف حساب NEAR؟

تأتي معرفات حسابات NEAR في شكلين. تظهر الحسابات المسماة كأسماء مستخدمين أو أسماء نطاقات قابلة للقراءة: alice.near وmyprotocol.near وapp.alice.near. الحسابات الضمنية هي سلاسل سداسية عشرية مكونة من 64 حرفاً مشتقة من المفتاح العمومي، وتتشابه في شكلها المرئي مع عناوين Ethereum ولكنها أطول: على سبيل المثال، 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. تستخدم الحسابات المسماة اللاحقة .near على المينيت و.testnet على شبكة الاختبار. راجع قسم معرفات الحسابات للحصول على التفصيل الكامل وجدول المقارنة.

هل بروتوكول NEAR يعتمد على إثبات التخزين؟

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

النقاط الرئيسية والخطوات التالية

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

أبرز النقاط:

• تُعد معرفات حسابات NEAR حسابات مُسماة قابلة للقراءة من قبل البشر (مثل alice.near) أو حسابات ضمنية مكونة من 64 حرفاً مشتقة من المفتاح العمومي، وليست عناوين سداسية عشرية
• تتطلب الحسابات المُسماة إيداع رمز NEAR عند التسجيل؛ بينما يتم تنشيط الحسابات الضمنية تلقائياً عند استلام أول رمز
• يمكن لكل حساب NEAR الاحتفاظ بمفاتيح وصول متعددة في وقت واحد، ولكل منها نطاق أذونات متميز
• تفوض مفاتيح الوصول الكامل (Full Access Keys) جميع إجراءات الحساب وتخص صاحب الحساب؛ بينما تقتصر مفاتيح الوصول لطلب الوظائف (Function Call Access Keys) على طرق عقد محددة ويتم إصدارها للتطبيقات
• يمكن لأي حساب NEAR أن يحمل رصيداً من رموز NEAR وعقداً ذكياً منشراً في نفس الوقت. لا يوجد نوع حساب عقد منفصل
• يتطلب تخزين البيانات (Storage staking) رصيداً محجوزاً من رموز NEAR يتناسب مع استهلاك التخزين داخل الكتلة. هو إيداع قابل للاسترداد، وليس رسوماً، ويختلف عن كل من رسوم الغاز وتخزين الموثقين
• تتبع الحسابات الفرعية اصطلاح تسمية هرمي، ولكن الحساب الأب لا يتحكم في الحسابات الفرعية بعد إنشائها. كل حساب فرعي يتمتع باستقلالية كاملة

يمكن للمطورين المستعدين للبناء على NEAR البدء بالاطلاع على توثيق نموذج حساب NEAR Protocol,)، الذي يوفر المواصفات الفنية ومراجع SDK. فيما يتعلق بتفاصيل تخزين الحصص (staking) ومعلمات المعدل الحالية، استشر التوثيق الرسمي لتخزين الحصص (staking) على NEAR) قبل اتخاذ قرارات معمارية، حيث يمكن تغيير معلمات البروتوكول من خلال الحوكمة. يمكن للمستخدمين الذين ينشئون حساب NEAR الأول الخاص بهم القيام بذلك عبر واجهة محفظة متوافقة مع NEAR مثل MyNEARWallet أو Meteor Wallet.

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