[ansi09]

الإعلان عن إستراتيجية التفويض (Delegation) لمؤسسة Solana


تخصيص عدد 100 مليون من عملة SOL لمقاومة الرقابة (Censorship Resistance)

رابط المقال الأصلي باللغة الإنجليزية: https://medium.com/solana-labs/annou...y-5bcccf9104ab
رابط إضافي بصيغة PDF على GoogleDrive من هذا الرابط: https://bit.ly/36Ap5tB


هذه هي المقالة الأولى في سلسلة مدونات من ثلاثة أجزاء حول المبادرات التي ستتخذها مؤسسة Solana Foundation لتعزيز مقاومة الرقابة (Censorship Resistance) على الشبكة خلال الأشهر القادمة. يعلن هذا المنشور عن إستراتيجية تفويض الحصص (Stake Delegation Strategy) الجديدة للمؤسسة، بينما ستغطي المنشورات التالية على التوالي جزيئتي التضخم (Inflation) / الفائدة وأحواض (Pools) إثبات الحصة (Staking).
لمزيد من الأسئلة، يرجى الإنضمام إلى جروب ال Discordالخاص بمشروع Solana.



نظرة عامة
تلتزم مؤسسة Solana Foundation بتنمية شبكة بلوكشاين Solana لتصبح أكثر بلوكشاين لامركزي (Decentralized) ومقاوم للرقابة (Censorship Resistance) في العالم. تواصل المؤسسة إنفاق قدر كبير من الموارد على الإبتكار حول كيفية تحقيق هذه الأهداف اليوم وعلى المدى الطويل.
وفقا لميثاقها، تلتزم المؤسسة بتفويض (Delegate) عدد 100،000،000 من عملة SOL (أكثر من 80ظھ من خزانة المؤسسة) من خلال إستراتيجية التفويض التلقائي (Auto-Delegation Strategy) التي تستهدف الأهداف التالية:

• تحسين مقاومة الرقابة (Censorship Resistance) والأمن على الشبكة من خلال تحفيز التوزيع المتساوي للحصص لتجنب تركيز عدد صغيرمن العقد (Nodes) لأغلبية كبيرة من التفويضات (Delegations).

• تشجيع نمو عدد المدققين (Validators) من خلال توفير تفويض أساسي، يرتبط حجمه عكسا بحجم عدد العقد (Nodes) على الشبكة، إلى العقد (Node) الأقل نشاطا في عملية إثبات الحصة (Staking) للمساعدة في تشغيل المدقق (Validator) بكفاءة عالية، عملية ومجدية من الناحية المالية حتى للوافدين الجدد إلى الشبكة.

لتحقيق هذه الغايات، ستنشر المؤسسة سكريبت (Script) مستقل يقسم بشكل ديناميكي وموحد ويفوض (delegates) عدد 100،000،000 من عملة SOL بهذه الطريقة لتكبير الحد الأدنى لعدد العقد الفريدة (Unique Nodes) التي تشكل 33ظھ من كل عمليات إثبات الحصة (Global Stake). يتم توفير التفاصيل الكاملة لإستراتيجية التفويض (Delegation Strategy) أدناه.


تخطط مؤسسة Solana Foundation لتنفيذ إستراتيجية التفويض (Delegation Strategy) هذه على شبكة Tour de SOL التجريبية خلال الأسبوع من يوم 16 نوفمبر و الشبكة الرئيسية التجريبية (Mainnet Beta) إلى حدود أو حوالي 1 ديسمبر 2020. نجاح العملية وموازنة إثبات الحصة (Staking Balancing) من بين المتطلبات الأساسية لتفعيل خاصية التضخم (Inflation) / الفائدة في الشبكة الرئيسية التجريبية (Mainnet Beta)، والذي يتم إستهدافه للتفعيل لاحقا في ديسمبر 2020.
يجب أن تستوفي العقد (Nodes) معايير الأهلية المحددة قبل إستلام أي تفويض (Delegation) من المؤسسة. العقد (Nodes) التي تفشل في الحفاظ على مقاييس أداء معينة ستتم إزالتها من تفويض المؤسسة حتى تفي بمتطلبات التفويض الأولية (Initial Delegation Requirements) مرة أخرى. تفاصيل حول معايير الأهلية الموضحة أدناه.


ستقوم المؤسسة بإنتظام بإعادة توازن توزيع التفويضات (Re-Balance Its Distribution Of Delegations) لحساب العدد المتغير من العقد (Nodes) على الشبكة بالإضافة إلى أي تغييرات في تفويضات أصحاب المصالح غير التابعة للمؤسسة (Non-Foundation Stake Delegations) عبر الشبكة. يمكن الإطلاع على تفاصيل توقيت إعادة التوازن أدناه.


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


التفاصيل الفنية لإستراتيجية التفويض (Delegation Strategy)
يصف هذا القسم الخطوات التي ستتخذها المؤسسة، من خلال روبوت التفويض التلقائي ( Auto-Delegation Bot) الخاص بها، لتحديد كيفية توزيع تفويضات التحصيص (Stake Delegation) وفقا لإستراتيجية التفويض (Delegation Strategy) الخاصة بها.


تحديد مجموعة الأمان القصوى (Maximal Security Group)
تُعرَّف “مجموعة الأمان” (Security Group) هنا على أنها أصغر مجموعة من العقد الفريدة (Unique Nodes) التي تضم ≥ 33ظھ من إجمالي عدد الحصة (Stake) على الشبكة. على قدم المساواة، تمثل هذه المجموعة الحد الأدنى من عدد العقد (Nodes) التي قد تحتاج إلى إختراق من أجل فرض الرقابة أو المساومة بشكل عام على الأمن العام للشبكة. توفر إستراتيجية تفويض المؤسسة (Foundation Delegation Strategy) التفويضات إلى عقد التحقق (Validator Nodes) المؤهلة التي تقع خارج مجموعة الأمان.


تُعرَّف ” مجموعة الأمان القصوى ” (Maximal Security Group) بأنها أكبر مجموعة أمان يمكن إنشاؤها، نظرا للتفويض الإستراتيجي لرموز المؤسسة عبر العقد (Nodes) المؤهلة على الشبكة خارج هذه المجموعة. الخوارزمية لتحديد هذه المجموعة هي كما يلي:

• إحسب 33ظھ من العدد الإجمالي للحصة (Stake) على الشبكة، بما في ذلك الرموز التي ستفوضها المؤسسة.

• حدد الحد الأدنى لمجموعة عُقد المدقق (Validator Nodes) التي تكون فيها الحصة التراكمية الغير تابعة للمؤسسة (Cumulative, Non-Foundation Stake)، أكبر من أو تساوي هذا العدد. هذه هي مجموعة الأمان القصوى (Maximal Security Group) الحالية للشبكة.

تفويض الرموز / العملات للعقد (Nodes) المؤهلة خارج مجموعة الأمان القصوى (Maximal Security Group)


بمجرد تحديد – مجموعة الأمان القصوى (Maximal Security Group) للشبكة، يتم تقسيم إجمالي مجموعة رموز المؤسسة (في البداية عدد 100،000،000 من عملة SOL) إلى أجزاء متساوية بناء على عدد العقد (Nodes) المؤهلة خارج هذه المجموعة.


بالإضافة إلى ذلك، لن تقوم المؤسسة بتفويض الكثير من الرموز لأي عقدة (Node) واحدة بحيث يتجاوز إجمالي حصتها التراكمية (Cumulative Stake) التابعة وغير التابعة للمؤسسة (Foundation + non-Foundation) إجمالي حصتها (Stake) لأي عقدة في مجموعة الأمان (Security Group) التي لا تتلقى تفويضا من المؤسسة. في هذه الحالة، ستتلقى العقدة (Node) أو العقد (Nodes) تفويضا (Delegation) من المؤسسة بحيث يتطابق إجمالي حصتها (Stake) الناتجة مع حصة العقدة (Node) ذات حصة (Stake) أقل في مجموعة الأمان (Security Group). ثم يتم توزيع أي رموز متبقية من هذه التفويضات (Delegations) المخفضة بالتساوي على جميع العقد (Nodes) المتبقية جنبا إلى جنب مع تفويض (Delegation) المؤسسة بالحجم الكامل. ينتج عن هذا تفويض مؤسسة (Foundation Delegation) متناقص تستقبله عقدة (Node) واحدة مع إقتراب إجمالي التفويضات أو تجاوز العدد المطلوب لدخول مجموعة الأمان (Security Group) دون تغيير ترتيب إجمالي الحصة (Stake) لعقد (Nodes) الشبكة. يتم تقديم هذا السيناريو كمثال رقم 2 أدناه.


المثال رقم 1#
تصور مثلا شبكة إفتراضية بها 10 ملايين من الرموز غير تابعة للمؤسسة (Non-Foundation Tokens) التي تم جمعها عبر 40 مدققا (Validators)، جنبا إلى جنب مع مؤسسة إفتراضية لها 5 ملايين رمز يمكن تفويضها (Delegate) متى شاءت. لنفترض توزيعا أوليا منحرفا للحصة (Stake) (قبل تفويض المؤسسة) يبدو كما يلي:



في هذا المثال، نرى “مجموعة أمان ” (Security Group) ما قبل تفويض المؤسسة (Pre-Foundation Delegation) تتكون من عقدتين (Nodes) (تظهر باللون الأزرق). بمعنى آخر. سيحتاج المهاجم فقط إلى السيطرة على هاتين العقدتين (Nodes) ليتمكن من إيقاف الشبكة بالكامل.


كما هو موضح أعلاه، فإن الخطوة الأولى في تطبيق إستراتيجية التفويض (Delegation Strategy) المقترحة، هي حساب مجموعة الأمان القصوى (Maximal Security Group) للشبكة مع مراعاة مقتنيات المؤسسة بالإضافة إلى الحصة الغير تابعة أو مملوكة للمؤسسة (Non-Foundation Tokens). في هذا المثال، تحتفظ المؤسسة بـ5 ملايين رمز، لذا فإن العدد الإجمالي للحصة (Stake) على الشبكة سيكون 15 مليون رمز (10 مليون رمز للحصة الغير تابعة أو مملوكة للمؤسسة (Non-Foundation Tokens)، و 5 ملايين مفوضة من المؤسسة). لذلك، ستكون مجموعة الأمان القصوى (Maximal Security Group) هي الحد الأدنى لعدد المدققين (Validators) الذين يتألفون > = 5 مليون رمز (أي 33ظھ من 15 مليون) من الحصة غير التابعة أو المملوكة للمؤسسة (Non-Foundation Stake). تم تحديد هذه المجموعة هنا:



في هذه الحالة، فإن أعلى 4 مدققات (Validators) ذات حصة غير تابعة أو مملوكة للمؤسسة (Non-Foundation Stake) يكون مجموعها > 5 ملايين رمز (33ظھ من إجمالي الحصة) وبالتالي فهذا يمثل مجموعة الأمان القصوى (Maximal Security Group). لذلك، لضمان مجموعة الأمان القصوى (Maximal Security Group) هذه، يجب على المؤسسة تقسيم إحتياطي الرموز الخاصة بها عبر عقد (Nodes) مجموعة الأمان غير القصوى مع تفويضات متساوية الحجم (Equally Sized Delegations).
في هذا المثال، هناك 36 عقدة (Validators) مؤهلة خارج مجموعة الأمان القصوى (Maximal Security Group)، لذلك يتلقى كل منها تفويضا (Delegation) من عدد 138،889 رمز (5،000،000 رمز مقسمة / على عدد 36 عقدة):



من خلال التوزيع المتساوي لرموز المؤسسة عبر عقد المجموعة غير الأمنية (Non-Security Group Nodes)، تمت مضاعفة مجموعة أمان (Security Group) الشبكة من عقدتين إلى أربع عقد. بالإضافة إلى ذلك، حصلت العقد الجديدة والأقل حجما على حصة يمكن من خلالها المساعدة في إضافة الأمان إلى الشبكة من خلال اللامركزية (Decentralization).
من خلال النشر الإستراتيجي لرموز للمؤسسة (Foundation Tokens)، تم تحسين مقاومة الرقابة (Censorship Resistance) على الشبكة بشكل عام وتم تقديم فرص التحقق من الصحة (Validations) للعقد التي لديها حصة أقل على الشبكة.


المثال رقم 2#
تحافظ الخوارزمية المستخدمة لتقسيم إجمالي حوض تجميع المؤسسة (Foundation Pool) وتسليم التفويضات المتساوية إلى العقد غير الأمنية (Non-Security Group Nodes) على شرط أن يكون ترتيب الحصة (Stake) الإجمالي للعقد بعد التفويضات هو نفسه الترتيب الذي لدى الحصة الغير تابعة أو مملوكة للمؤسسة (Non-Foundation Stake).


ومع ذلك، قد لا يتم إستيفاء هذا المطلب مبدئيا على الحدود بين عقد مجموعة الأمان (Security Group) وعقد المجموعة غير الأمنية (Non-Security Group Nodes). كمثال على هذا السيناريو، فإن التفويض من المؤسسة (Delegation From The Foundation)، كما تم حسابه مبدئيا على أنه جزء متساو من إجمالي حصة المؤسسة عبر جميع عقد المجموعة غير الأمنية (Non-Security Group Nodes)، سيؤدي إلى العقدة الأكثر رصانة خارج مجموعة الأمان (Security Group)، والتي تتلقى هذا التفويض (Delegation)، الذي لديه حصة إجمالية أكبر من العقدة الأقل رصانة داخل مجموعة الأمان (Security Group)، والتي لا تتلقى تفويضا (Delegation). يتم شرح هذا الموقف بأكثر تبسيط في هذا التمثيل الرسومي هنا:



في هذا السيناريو الافتراضي، قامت تفويضات المؤسسة (Foundation Delegation) التي تم تسليمها إلى العقد 10 و 11 و 12 بتغيير ترتيب الحصة (Stake) الإجمالي لمجموعة المدققين (Validations)، وهو ما ينتهك القيد أو الشرط المحدد في الإستراتيجية. بدلاً من ذلك، ستتخذ خوارزمية التسليم الخطوات التالية:


1 – تقليل تفويض العقدة 10، حتى تصبح الحصة (Stake) على العقدة 10 مساو للحصة (Stake) على العقدة 9.


2 – إعادة حساب تفويض المؤسسة (Foundation Delegation) لكل عقدة (Node) بعد إضافة مقدار تفويض المؤسسة (Foundation Delegation) الذي ” تمت إزالته ” من العقدة 10 إلى المجموعة بأكملها.


3 – الأخذ في الإعتبار إعادة توزيع الحصة (Stake) الخاصة بكل عقدة تابعة للمؤسسة على العقد (Nodes) ذات الحصة الغير تابعة أو مملوكة للمؤسسة (Non-Foundation Stake) < العقدة 10 (أي العقد 11+).


4 – إذا كان إجمالي التفويض المحتمل على العقدة 11 أكبر الآن من العقدة 10، أعد تشغيل هذه العملية عن طريق تقليل التفويض (Reducing The Delegation) على العقدة 11 وإعادة حساب حصة كل عقدة للتوزيع بإتجاه العقد المستهدفة (أي العودة إلى الخطوة 1).


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



بعد عملية التخفيض هذه، في هذا المثال، زاد مقدار التفويض للعقد 13+ بشكل متناسب بالمقدار الذي تمت إزالته من العقد 10 و 11 و 12 من أجل تلبية قيود التصميم دون تقليل الكمية الإجمالية للتفويضات الموزعة.


يجب أن يتجنب تقليل تفويض المؤسسة (Foundation Delegation) بالقرب من حدود المجموعة الأمنية (Security Group) السيناريوهات التي تقدم نواقل الهجوم الإقتصادي (Economic Attack Vectors) والحوافز المتطرفة (Edge-Case Incentives) التي قد لا تتوافق مع الأهداف الشاملة للإستراتيجية.


فترة إعادة التوازن (ReBalancing Period)
ستتم إعادة تقييم تفويضات المؤسسة (Foundation Delegations) وإعادة التوازن كل 4 فترات (Epochs) (كل 8 أيام تقريبا) وفقا للعملية الموضحة أدناه. لن تتم إضافة أي تفويضات إلا في فترات إعادة التوازن (Re-Balance Intervals)، على الرغم من أنه يمكن إلغاء تنشيط التفويضات في أي وقت إذا فشلت العقدة في أن تظل مؤهلة للتفويض.


في وقت إعادة التوازن (Re-Balance Period)، سيتم حصر جميع التفويضات الغير مملوكة للمؤسسة (Non-Foundation Delegations)، وسيتم إحتساب التفويضات المعدلة. تعني فترة إعادة التوازن (Re-Balance Intervals) المكونة من 4 فترات (Epochs) أنه سيكون هناك قدر من التأخر بين التغيير في الحصة الغير تابعة أو مملوكة للمؤسسة (Non-Foundation Stake) ونشر لتفويض المؤسسة المحدث. نظرا لمقدار الحصة (Stake) التي قد تحركها المؤسسة في عملية إعادة توازن واحدة، فقد يستغرق الأمر أكثر من فترة واحدة للإحماء (Warm Up) أو التهدئة (Cool Down)، إستنادا إلى الحد الأقصى لبروتوكول Solana الذي لا يمكنه إضافة أو إزالة أكثر من 25ظھ من إجمالي تفويض الحصة (Stake) في الشبكة في فترة (Epoch) واحدة. من خلال ترك فاصل زمني بين إعادة التوازن (Re-Balancing)، فإن هذا يمنح وقتا لتفعيل تغييرات الحصة المملوكة للمؤسسة (Foundation Stake)، فضلا عن تقليل مخاطر إختناق المستخدمين الآخرين للشبكة الذين يرغبون في تفويض حصتهم.


تم تصميم هذا ليكون إستراتيجية تفويض طويلة الأمد، لتحفيز سلوك المداومة على مدى عدة أشهر أو سنوات، لذا فإن تجاوز التقلبات الأصغر لكل فترة (Epoch) من قبل المفوضين غير التابعين للمؤسسة (Non-Foundation Delegators) أمر مقبول.


الإعتبارات
تم تصميم إستراتيجية التفويض (Delegation Strategy) المقترحة لخلق حوافز لتعزيز أمن الشبكة ولتوسيع الشبكة. يتم زيادة أمان الشبكة من خلال تفويض رموزها بطريقة تزيد من الحد الأدنى لعدد العقد التي تشكل أكثر من 33ظھ من إجمالي الحصة (Stake). يتم تشجيع نمو الشبكة من خلال تسهيل المسار للمدققين الجدد للحصول على تفويض من المؤسسة يتم من خلاله بدء خدمات التحقق من الصحة (Validation) الخاصة بهم.


نظرا لأن حوض تجميع المؤسسة (Foundation Pool) يتم توزيعه بالتساوي عبر جميع عقد المجموعة غير الأمنية (Non-Security Group Nodes)، فإن مقدار كل تفويض مؤسسة (Foundation Delegation) يتناسب عكسا مع عدد عقد المجموعة غير الأمنية (Non-Security Group) المؤهلة لإستقبال التفويض. وبهذه الطريقة، نتوقع أن تنمو الشبكة مع مدققين (Validators) جدد إلى الحد الذي يكون فيه الناتج من العائد من تفويض المؤسسة يستحق التكلفة والجهد المبذولين لدعم المدقق الذي يلبي متطلبات التفويض.


بالإضافة إلى ذلك، يجب أن تقوم العقد (Nodes) في مجموعة الأمان (Security Group) بتقييم مستمر إذا ما كان ذلك مفيد إقتصاديا، إلى أقصى حد ممكن، تقسيم تفويضاتها عبر عقد متعددة. من خلال القيام بذلك، من المحتمل إنشاء عقد خارج مجموعة الأمان، وإكتساب تفويضات المؤسسة (Foundation Delegation) ومعها إيرادات إضافية.


ستحصل تفويضات المؤسسة (Foundation Delegations) على عائد إثبات حصة (Staking Yield) تماما مثل الرموز الأخرى التي تقوم بعملية إثبات الحصة. مع ذلك، فإن العوائد الموزعة على تفويضات المؤسسة (Foundation Delegations)، مطروحا منها العمولات التي حددها المدققون (Validators)، تتم إضافتها على الفور إلى إجمالي مجموعة الرموز للمؤسسة المستخدمة لهذه الإستراتيجية. بمعنى آخر. ستتم إعادة تفويض الفائدة المكتسبة من الرموز للمؤسسة، وفقا للإستراتيجية الموضحة أعلاه، عبر الشبكة. يوفر هذا مجموعة تفويض متزايدة لتحفيز أمان الشبكة ونموها بإستمرار.
بالإضافة إلى ذلك، نتيجة لإعادة تفويض عائدات المؤسسة (Re-Delegation Of Foundation Staking yields)، فإن التأثير على إجمالي المعروض المتداول، كما هو محدد بعدد الرموز التي تم رفع التجميد عنها حاليا وفي الحسابات الخارجة عن سيطرة مؤسسة Solana Foundation أو Solana Labs، قد تم تقليل حجمه إلى الرموز التي حصل عليها المدققون (Validators) الذين يستقبلون تفويضات المؤسسة (Foundation Delegations) من خلال معدلات العمولات الخاصة بهم. يمكننا تقدير ما قد تكون عليه الزيادة الشهرية للمعروض المتداول للسنة الأولى بعد تفعيل خاصية التضخم (Inflation) أو الفائدة، مع بعض الإفتراضات حول متوسط معدل عمولة المدقق (Validator)، والنسبة المائوية من إجمالي المعروض المتداول، والمعدل العالمي الأولي للتضخم (Inflation) أو الفائدة.


أولاً، نتخذ الحد الأقصى من الإفتراضات بمتوسط ​​عمولة 10ظھ يحددها المدققون الذين يتلقون منح المؤسسة (لاحظ أن الحد الأقصى للعمولة لتكون مؤهلاً هو 10ظھ). بالإضافة إلى ذلك، من أجل التبسيط، نقدر أن متوسط ​​الكسر من إجمالي الحصة (Stake) على الشبكة خلال العام الأول هو 65ظھ وأن معدل التضخم (Inflation) أو الفائدة خلال العام الأول هو 7.5ظھ (بإستخدام متوسط ​​نطاق معايير التضخم (Inflation) أو الفائدة المحتملة التي تم إستكشافها من هذا الرابط هنا). مع هذه الإفتراضات، نتوقع متوسط ​​عائد إثبات حصة (Staking Yield) للسنة الأولى يبلغ حوالي 11.5ظھ. نظرا للإلتزام بتفويض عدد 100 مليون من الرموز، وتجاهل الفائدة المركبة (Compound Interest) عبر تلك السنة الأولى من أجل البساطة، نتوقع أن تنتج تفويضات المؤسسة (Foundation Delegations) حوالي 11.5 مليونا من الرموز. بتقديرنا الأعلى لمتوسط ​​عمولة 10ظھ للمدققين الذين يتلقون تفويض المؤسسة (Foundation Delegation)، نتوقع بعد ذلك ≤ 10ظھ (≤ 1.15M) من هذه الرموز عدد 11.5 مليون للدخول إلى المعروض المتداول على مدار العام، بينما ≥ 90ظھ (≥ عدد 10.5 مليون رمز) لإعادة تقديمها تلقائيا في برنامج التفويض والإحتفاظ بها كحسابات إثبات حصة مفوضة (Delegated Stake Accounts). يشير هذا إلى حد أقصى للزيادة في المعروض المتداول نتيجة لإستراتيجية التفويض بما لا يزيد عن عدد 100000 رمز في الشهر.


متطلبات الأهلية(Eligibility Requirements)
يرجى ملاحظة أن شبكة Solana كانت دائما وستظل دائما لا تحتاج إذنا مسبقا (Permissionless). يمكن لأي شخص تشغيل المدقق (Validator) والحصول على مكافآت من التفويضات في أي وقت، دون الحاجة إلى موافقة مؤسسة Solana. مع ذلك، من أجل إستقبال تفويض مباشرة من المؤسسة والتأهل للبرنامج الموصوف في هذه الوثيقة، يجب إستيفاء جميع المعايير التالية.


المتطلبات الأساسية (Prerequisites)
يجب إستيفاء ما يلي قبل أن تقوم مؤسسة Solana Foundation بتضمين عقدة تحقق (Validator Node) على الشبكة الرئيسية التجريبية (Mainnet Beta) في إستراتيجية توزيع التفويض الخاصة بها.

• يجب أن يجتاز مشغلو العقدة (Node) معايير التعرف على الزبون (Know Your Customer) أو ما يعرف إختصارا بKYC

• يجب على مشغلي العقدة (Node) الموافقة على إتفاقية المشاركة (Participation Agreement) الخاصة بنا والتوقيع عليها.

يجب على مشغلي العقدة (Node)المشاركة في مرحلة كاملة واحدة على الأقل (مدة شهر تقريبا) من برنامج شبكة الإختبارات المحفزة Tour de SOL. بعد المشاركة الناجحة في Tour de SOL، سيكون المدققون مؤهلين للمشاركة في برنامج التفويض على الشبكة الرئيسية التجريبية (Mainnet Beta) التابعة لـSolana.

• قد يختار المدقق (Validator) المؤهل لتفويض المؤسسة على الشبكة الرئيسية التجريبية (Mainnet Beta) ترحيل عقدة Tour de SOL الخاصة به من الشبكة التجريبية (TestNet) إلى الشبكة الرئيسية التجريبية (Mainnet Beta)، أو قد يختار الإستمرار في المشاركة في Tour de SOL وكسب التعويض المقابل، وبدء عقدة ثانية مخصصة فقط للشبكة الرئيسية التجريبية (Mainnet Beta).

متطلبات تقنية (Technical Requirements)
يجب أن تحتفظ العقدة بالمقاييس الفنية التالية لكي تظل مؤهلة لتفويض المؤسسة (Foundation Delegation). يجب أن تحافظ العقد الجديدة المشاركة في البرنامج بإستمرار على هذه المعايير طوال – فترة الإستبعاد من التفويض (Delegation Exclusion Period) (المحددة أدناه) قبل أن تتلقى التفويض الأولي الخاص بها من قبل المؤسسة.


لاحظ أن هذه المتطلبات الفنية تهدف إلى التغير بمرور الوقت حيث يصبح أداء الشبكة مفهوما بشكل أفضل.

• التصويت على أكثر من 90ظھ على جميع الكتل (Blocks) الصالحة أثناء فترة المعاينة / التجربة.

• تعتبر الكتلة (Block) صالحة إذا تلقت كحد أقصى عدد (32) تأكيد من قبل العنقود (Cluster)، أو كانت سلفا لكتلة سابقة.

• الإحتفاظ بمعدل تأخير في السداد <10ظھ على مدار 48 ساعة من نافذة متوسط ​​الوقت المتحرك.

• تُعتبر العقدة متأخرة الدفع إذا كانت فتحة الجذر (Root Slot) الخاصة بها أكثر من 256 فتحة خلف فتحة جذر الأغلبية العظمى للشبكة (s Network SuperMajority’Root Slot). سيتم إستقصاء حالة التأخر في السداد كل ساعة. إذا تم أخذ عينة من العقدة على أنها متأخرة في الدفع في أكثر من 10ظھ من عمليات التحقق السابقة البالغة 48 ساعة، فيُعتبر أنها فشلت في هذا المطلب.

• إقتراح الكتل (Blocks) في > 90ظھ من خانات الصدارة المجدولة (Scheduled Leader Slots).
• المدققون الذين لم يتلقوا أي تفويض بعد ولم يتم تضمينهم في جدول قائد الفترة الحالي (Epoch Leader’s Schedule) مستثنون من هذه المعايير. بمجرد إستلام تفويض المؤسسة (Foundation Delegation) ودخول العقدة (Node) في جدول القائد (منتج الكتلة – Block Producer)، سيتم تنفيذ هذا المطلب.

• الإحتفاظ بعمولة 10ظھ

إذا أخفق المدقق في أي من المعايير المذكورة أعلاه، فسيتم إلغاء تنشيط تفويض المؤسسة (Foundation Delegation) الخاص به في الفترة (Epoch) الحالية وتدخل العقدة في فترة إستبعاد التفويض (Delegation Exclusion).


فترة الاستبعاد من التفويض (Delegation Exclusion Period)
العقد (Nodes) الجديدة في البرنامج، وتلك التي فشلت في الحفاظ على معايير التفويض غير مؤهلة لتفويض المؤسسة لمدة لا تقل عن فترتين (Epochs) لإعادة التوازن، تُعرف باسم فترة إستبعاد التفويض (Delegation Exclusion Period). طوال هذه الفترة، ستستمر مراقبة أداء العقد جنبا إلى جنب مع جميع العقد المفوضة. يجب الحفاظ على معايير التفويض طوال فترة إستبعاد التفويض بالكامل، وبعد ذلك ستتلقى العقدة تفويضا من المؤسسة (Foundation Delegation) في فترة إعادة الموازنة (Rebalancing Period) التالية. إذا فشلت العقدة في الحفاظ على المتطلبات خلال فترة الإستبعاد، يبدأ توقيت فترة الإستبعاد للتفويض.


تغيير نموذج التوزيع الحالي الخاص بإثبات الحصة التابع للمؤسسة
تلقى معظم المدققين الذين شاركوا في الشبكة الرئيسية التجريبية (Mainnet Beta) حتى الآن ما يصل إلى عدد 550.000 من عملة SOL كتفويض من المؤسسة. حتى الآن، كانت هذه القيمة عشوائية إلى حد ما. للتحضير لإستراتيجية التوزيع الجديدة، سيتم تعديل النص الحالي المستخدم لتفويض إثبات الحصة المملوكة للمؤسسة (Foundation Stake) تلقائيا لتفويض ما لا يزيد عن عدد 270،000 من عملة SOL لكل عقدة واحدة، وسيتم إجراء تفويضات جديدة تصل إلى عدد 270،000 من عملة SOL للمدققين الذين إنضموا مؤخرا إلى الشبكة الرئيسية التجريبية (Mainnet Beta). سيوفر هذا تقديرا تقريبيا للغاية لنتائج أول إعادة موازنة للإستراتيجية الجديدة بمجرد تنفيذها. من خلال ترحيل الحصة (Stake) بالجملة الآن على مدى عدة فترات (Epochs)، سنتجنب التحريك الكبير للحصة (Stake) في فترة (Epoch) واحدة عند بدء برنامج الإستراتيجية الجديدة.


لن يخضع المدققون (Validatos) الذين الذين قاموا بإثبات حصصهم على الشبكة الرئيسية التجريبية (Mainnet Beta) لفترة إستبعاد التفويض، لتجنب تجريد كل شخص على الشبكة من تفويضاته مرة واحدة. إذا فشل المدقق في تلبية المعايير الفنية عند تمكين البرنامج الجديد، فسيكون خاضعا لفترة إستبعاد التفويض.


التغييرات في خطة تعويض الشبكة الرئيسية التجريبية (Mainnet Beta) الحالية
حصل المدققون المشاركون في الشبكة الرئيسية التجريبية (Mainnet Beta) حتى الآن على تعويض شهري مباشرة من مؤسسة Solana مقابل خدماتهم. من المتوقع أن ينتهي برنامج التعويض هذا قبل تفعيل خاصية التضخم (Inflation) / الفائدة في الشبكة الرئيسية التجريبية (Mainnet Beta). سيتم الإعلان النهائي بخصوص ذلك من قبل مؤسسة Solana Foundation عبر منتديات Discord و Solana لإنهاء تلك العقود الحالية. سيكون الحافز المالي للمدققين حصريا من مضاعفة المكافآت التضخمية / الفوائد المدفوعة بالبروتوكول.


لن تتغير خطة التعويض للمشاركة في برنامج الشبكة التجريبية (TesNet) المحفز Tour de SOL مع تنشيط التضخم (Inflation) أو الفائدة في الشبكة الرئيسية التجريبية (Mainnet Beta).


لمزيد من الأسئلة، يرجى الإنضمام إلى جروب ال Discordالخاص بمشروع Solana.


تأكد من متابعتنا على قنوات التواصل الإجتماعية المختلفة أدناه لتلقي التحديثات اليومية حول ما يجري في نظام Solana البيئي. نقدم أيضا تحديثات متكررة عبر Blockfolio Signal، لذا أضف رمز عملة SOL$ إلى محفظتك (Portfolio) إذا كنت مهتما بتلقي آخر تحديثات المشروع مباشرة فور صدورها.


Twitter | Telegram | Reddit | Youtube | Medium | VK | Weibo | Blockfolio



لمتابعة آخر تحديثات وأخبار مشروع Solana (مسابقات، جوائز، شراكات ...) تابعونا على مدونة Solana بالعربي من الرابط التالي: https://arabicsolana.wordpress.com/blog

أو حساب الTwitter الخاص بمشروع Solana بالعربي من الرابط التالي: https://twitter.com/SolanaArabic