Rust العقود الذكية养成日记(11): تحليل آلية اقتراح DAO Sputnik
تعمل Sputnik-DAO كالبنية التحتية لبروتوكول NEAR، مما يدفع نظام NEAR البيئي نحو التطور في اتجاه اللامركزية. في الوقت الحالي، ساهمت هذه المنصة في إنشاء العديد من المجتمعات الذاتية لمشاريع NEAR، كما أنها تقدم حلولاً كاملة ومرنة وفعالة لحوكمة اتخاذ القرارات المجتمعية.
Sputnikdaov2 هو عقد ذكي مخصص للتصويت على إدارة مجتمع Sputnik-DAO. ستقدم هذه المقالة المفاهيم الأساسية لهذا العقد: الاقتراح (Proposal)، وستتناول نماذج إدارة مجتمع DAO ذات الصلة بالاقتراح (Policy).
1. بدء الاقتراح
يمكن لكل عضو في مجتمع Sputnik-DAO التعبير عن آرائه أو تقديم مقترحات بشأن إدارة المشروع أو حكمه. بعد ذلك، يمكن لكل عضو في المجتمع يمتلك أسهمًا في DAO مراجعة الاقتراح والتصويت عليه. بعبارة أخرى، يمكن لكل عضو في Sputnik-DAO التأثير على الاتجاه المستقبلي للمشروع من خلال التصويت على مقترحات الآخرين أو من خلال تقديم مقترحات إدارية جديدة.
من منظور العقد، يمكن لأعضاء مجتمع DAO استدعاء طريقة add_proposal() لعقد sputnikdaov2 لبدء اقتراح جديد.
في هذه اللحظة، يحتاج مقدم الاقتراح إلى تقديم تفاصيل الاقتراح (ProposalInput):
وصف الاقتراح ( Description ). ستظهر هذه المعلومات علنًا في الواجهة الأمامية لصفحة Sputnik-DAO، لمساعدة أعضاء المجتمع على فهم هدف الاقتراح ومعناه.
نوع الاقتراح ( kind ). يجب على مقدم الاقتراح اختيار النوع المناسب بناءً على نوع الآراء المقدمة بشأن إدارة المشروع ( مثل استدعاء الوظائف الرئيسية للعقد ، يجب اختيار نوع FunctionCall ، ونقل أموال مشروع العقد يجب اختيار نوع Transfer ، وغيرها ).
هذه المعلومات ProposalInput ستُمرر كمعلمات إلى طريقة add_proposal()، ستقوم هذه الطريقة بإجراء التحقق والمعالجة ذات الصلة، وتوليد اقتراح يحمل معلومات تهيئة كاملة (Proposal). في النهاية، سيتم ربط هذا الاقتراح بمعرف proposal_id الفريد، ليتم إضافته إلى خريطة Contract.proposals التي تحافظ عليها العقود الذكية Sputnik-DAO بشكل عالمي، داخل حوض الاقتراحات (.
من المهم ملاحظة أن هناك مفهوم إيداع الاقتراح )proposal_bond( في Sputnik-DAO، وسيتم إدارة هذا الإيداع وفقًا لنموذج حوكمة مجتمع Sputnik-DAO المحدد )Policy(. يتطلب العقد من مقدم الاقتراح أن يدعم مبلغًا معينًا من رموز NEAR كضمان للاقتراح الجديد عند استدعاء طريقة add_proposal)(. سيتم رد هذا الإيداع إلى مقدم الاقتراح من خلال استدعاء الدالة الداخلية للعقد internal_return_bonds)( عندما ينتهي الاقتراح بشكل طبيعي ) وتتم الموافقة أو الرفض من قبل تصويت المجتمع (.
أي اقتراح قياسي في Sputnik-DAO قد يمر بمراحل متعددة ) يتم تهيئة حالة الاقتراح الجديدة إلى InProgress (:
InProgress: التصويت جارٍ
المعتمد: تم الموافقة على الاقتراح
مرفوض: تم رفض الاقتراح
Removed: تم إزالة الاقتراح
فشل: فشل تنفيذ الاقتراح
expired: الاقتراح قد انتهت صلاحيته
تغيير حالة الاقتراحات في صندوق الاقتراحات مدفوع بواسطة طريقة العقد act_proposal)(. يمكن لأعضاء Sputnik-DAO استدعاء طريقة act_proposal)( لتنفيذ العمليات على اقتراح معين ) عن طريق تحديد id (.
بالنسبة للاقتراحات التي في حالة InProgress، يمكن لأعضاء مجتمع DAO استدعاء act_proposal)( لتنفيذ عمليات التصويت المحددة:
الإجراء::التصويتموافقة: التصويتالموافقة
الإجراء::VoteReject: جدول ضد
Action::VoteRemove:يعتقد أن هذا الاقتراح ليس له معنى عملي، ويجب إزالته
وفقًا للتنفيذ، بعد استدعاء دالة update_votes)( داخليًا، سيقوم البرنامج باستدعاء policy.proposal_status)( بشكل نشط لإجراء عملية التصويت. بالنسبة للاقتراحات التي تلبي عتبة التصويت، سيتم تغيير حالة الاقتراح وفقًا لذلك.
بعد التعديل:
إذا كانت حالة الاقتراح Approved، فسيتم تنفيذ هذا الاقتراح من خلال استدعاء internal_execute_proposal)(؛
إذا كانت حالة الاقتراح Rejected أو Removed، فسيتم تنفيذ العمليات الختامية من خلال استدعاء internal_reject_proposal)(.
من الجدير بالذكر أن الفرق بين حالة Rejected وحالة Removed هو أن الاقتراح الذي يتم تحديده على أنه Removed سيتم إزالته مباشرة من مجموعة الاقتراحات، ولن يتم إعادة الوديعة التي تم التعهد بها سابقًا للمقترح. أما بالنسبة للاقتراح في حالة Rejected، فسيظل هذا الاقتراح محفوظًا في مجموعة الاقتراحات، وسيتم إعادة الوديعة المقابلة.
إذا كانت الحالة لأي اقتراح بعد انتهاء التصويت هي Approved، فستستمر دالة العقد act_proposal)( في استدعاء وظيفة internal_execute_proposal)( لتنفيذ محتوى القرار الذي يحتويه الاقتراح.
يدعم Sputnik-DAO أنواع المقترحات التالية: ChangeConfig وChangePolicy وAddMemberToRole وRemoveMemberFromRole وFunctionCall وUpgradeSelf وUpgradeRemote وTransfer وSetStakingContract وAddBounty BountyDone وتصويت وFactoryInfoUpdate وChangePolicyAddOrUpdateRole وChangePolicyRemoveRole وChangePolicyUpdateDefaultVotePolicy وChangePolicyUpdateParameters، وما إلى ذلك.
فيما يلي نعرض عمليتين نموذجيتين لمعالجة أنواع الاقتراحات.
) 3.1 تنفيذ اقتراح دالة العقد###ProposalKind::FunctionCall(
تم تمرير العمليات المحددة التي يجب تنفيذها في الاقتراح من خلال معلمة ProposalInput عند استدعاء المقترح add_proposal)( من نوع FunctionCall. يسمح عقد NEAR بربط عدة استدعاءات دالة متتالية في وعد واحد. لذلك يمكن أن تحتوي العمليات التي حددها المقترح الأصلي داخل actions على عدة كائنات ActionCall، حيث يمكن لكل ActionCall تحديد اسم طريقة العقد المقابلة والمعلمات الخاصة بالطريقة.
اعتمد Sputnik-DAO على شكل إجراءات دفعة الوعد لإكمال تنفيذ اقتراح نوع تنفيذ دالة العقد.
) 3.2 اقتراح نقل أموال العقد ( ProposalKind::Transfer )
عند تشغيل مشروع العقود الذكية NEAR لفترة من الوقت، قد تكون حسابات العقود قد تراكمت فيها كمية كبيرة من الرموز القابلة للتداول ### بما في ذلك الرموز الأصلية NEAR، أو غيرها من الرموز التي تتوافق مع معيار NEP-141 (.
في هذه الحالة، يمكن لأعضاء مجتمع Sputnik-DAO تجميع هذه الرموز في حساب receiver_id المحدد من خلال تقديم مقترح لتحويل أموال العقد. internal_execute_proposal)( قد نفذت أيضًا نقطة معالجة مناسبة للمقترحات التي تتطابق مع ProposalKind من نوع Transfer.
سيقوم فرع المعالجة هذا باستدعاء دالة internal_payout)(، لتنفيذ عمليات تحويل لفئات مختلفة من الرموز القابلة للتداول وكذلك لمعرفات المستلمين المختلفة receiver_id)EOA أو حسابات العقود (.
تقدم هذه المقالة المفاهيم الأساسية لعقد Sputnik DAO - الاقتراح )Proposal(، كما توضح بإيجاز كيفية إنشاء اقتراحات جديدة في Sputnik DAO والتصويت عليها وتنفيذها، وقواعد تغيير الحالة الأساسية للاقتراحات ذات الصلة )Status(.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
شرح آلية اقتراحات Sputnik DAO: تحليل كامل للعملية من الإطلاق إلى التنفيذ
Rust العقود الذكية养成日记(11): تحليل آلية اقتراح DAO Sputnik
تعمل Sputnik-DAO كالبنية التحتية لبروتوكول NEAR، مما يدفع نظام NEAR البيئي نحو التطور في اتجاه اللامركزية. في الوقت الحالي، ساهمت هذه المنصة في إنشاء العديد من المجتمعات الذاتية لمشاريع NEAR، كما أنها تقدم حلولاً كاملة ومرنة وفعالة لحوكمة اتخاذ القرارات المجتمعية.
Sputnikdaov2 هو عقد ذكي مخصص للتصويت على إدارة مجتمع Sputnik-DAO. ستقدم هذه المقالة المفاهيم الأساسية لهذا العقد: الاقتراح (Proposal)، وستتناول نماذج إدارة مجتمع DAO ذات الصلة بالاقتراح (Policy).
1. بدء الاقتراح
يمكن لكل عضو في مجتمع Sputnik-DAO التعبير عن آرائه أو تقديم مقترحات بشأن إدارة المشروع أو حكمه. بعد ذلك، يمكن لكل عضو في المجتمع يمتلك أسهمًا في DAO مراجعة الاقتراح والتصويت عليه. بعبارة أخرى، يمكن لكل عضو في Sputnik-DAO التأثير على الاتجاه المستقبلي للمشروع من خلال التصويت على مقترحات الآخرين أو من خلال تقديم مقترحات إدارية جديدة.
من منظور العقد، يمكن لأعضاء مجتمع DAO استدعاء طريقة add_proposal() لعقد sputnikdaov2 لبدء اقتراح جديد.
في هذه اللحظة، يحتاج مقدم الاقتراح إلى تقديم تفاصيل الاقتراح (ProposalInput):
وصف الاقتراح ( Description ). ستظهر هذه المعلومات علنًا في الواجهة الأمامية لصفحة Sputnik-DAO، لمساعدة أعضاء المجتمع على فهم هدف الاقتراح ومعناه.
نوع الاقتراح ( kind ). يجب على مقدم الاقتراح اختيار النوع المناسب بناءً على نوع الآراء المقدمة بشأن إدارة المشروع ( مثل استدعاء الوظائف الرئيسية للعقد ، يجب اختيار نوع FunctionCall ، ونقل أموال مشروع العقد يجب اختيار نوع Transfer ، وغيرها ).
هذه المعلومات ProposalInput ستُمرر كمعلمات إلى طريقة add_proposal()، ستقوم هذه الطريقة بإجراء التحقق والمعالجة ذات الصلة، وتوليد اقتراح يحمل معلومات تهيئة كاملة (Proposal). في النهاية، سيتم ربط هذا الاقتراح بمعرف proposal_id الفريد، ليتم إضافته إلى خريطة Contract.proposals التي تحافظ عليها العقود الذكية Sputnik-DAO بشكل عالمي، داخل حوض الاقتراحات (.
من المهم ملاحظة أن هناك مفهوم إيداع الاقتراح )proposal_bond( في Sputnik-DAO، وسيتم إدارة هذا الإيداع وفقًا لنموذج حوكمة مجتمع Sputnik-DAO المحدد )Policy(. يتطلب العقد من مقدم الاقتراح أن يدعم مبلغًا معينًا من رموز NEAR كضمان للاقتراح الجديد عند استدعاء طريقة add_proposal)(. سيتم رد هذا الإيداع إلى مقدم الاقتراح من خلال استدعاء الدالة الداخلية للعقد internal_return_bonds)( عندما ينتهي الاقتراح بشكل طبيعي ) وتتم الموافقة أو الرفض من قبل تصويت المجتمع (.
! [])https://img-cdn.gateio.im/webp-social/moments-84ee9ca630a4cdcdb0d2eb63450a7cf4.webp(
2. حالة الاقتراح
أي اقتراح قياسي في Sputnik-DAO قد يمر بمراحل متعددة ) يتم تهيئة حالة الاقتراح الجديدة إلى InProgress (:
تغيير حالة الاقتراحات في صندوق الاقتراحات مدفوع بواسطة طريقة العقد act_proposal)(. يمكن لأعضاء Sputnik-DAO استدعاء طريقة act_proposal)( لتنفيذ العمليات على اقتراح معين ) عن طريق تحديد id (.
بالنسبة للاقتراحات التي في حالة InProgress، يمكن لأعضاء مجتمع DAO استدعاء act_proposal)( لتنفيذ عمليات التصويت المحددة:
وفقًا للتنفيذ، بعد استدعاء دالة update_votes)( داخليًا، سيقوم البرنامج باستدعاء policy.proposal_status)( بشكل نشط لإجراء عملية التصويت. بالنسبة للاقتراحات التي تلبي عتبة التصويت، سيتم تغيير حالة الاقتراح وفقًا لذلك.
بعد التعديل:
من الجدير بالذكر أن الفرق بين حالة Rejected وحالة Removed هو أن الاقتراح الذي يتم تحديده على أنه Removed سيتم إزالته مباشرة من مجموعة الاقتراحات، ولن يتم إعادة الوديعة التي تم التعهد بها سابقًا للمقترح. أما بالنسبة للاقتراح في حالة Rejected، فسيظل هذا الاقتراح محفوظًا في مجموعة الاقتراحات، وسيتم إعادة الوديعة المقابلة.
! [])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(
3. تنفيذ الاقتراح
إذا كانت الحالة لأي اقتراح بعد انتهاء التصويت هي Approved، فستستمر دالة العقد act_proposal)( في استدعاء وظيفة internal_execute_proposal)( لتنفيذ محتوى القرار الذي يحتويه الاقتراح.
يدعم Sputnik-DAO أنواع المقترحات التالية: ChangeConfig وChangePolicy وAddMemberToRole وRemoveMemberFromRole وFunctionCall وUpgradeSelf وUpgradeRemote وTransfer وSetStakingContract وAddBounty BountyDone وتصويت وFactoryInfoUpdate وChangePolicyAddOrUpdateRole وChangePolicyRemoveRole وChangePolicyUpdateDefaultVotePolicy وChangePolicyUpdateParameters، وما إلى ذلك.
فيما يلي نعرض عمليتين نموذجيتين لمعالجة أنواع الاقتراحات.
) 3.1 تنفيذ اقتراح دالة العقد###ProposalKind::FunctionCall(
تم تمرير العمليات المحددة التي يجب تنفيذها في الاقتراح من خلال معلمة ProposalInput عند استدعاء المقترح add_proposal)( من نوع FunctionCall. يسمح عقد NEAR بربط عدة استدعاءات دالة متتالية في وعد واحد. لذلك يمكن أن تحتوي العمليات التي حددها المقترح الأصلي داخل actions على عدة كائنات ActionCall، حيث يمكن لكل ActionCall تحديد اسم طريقة العقد المقابلة والمعلمات الخاصة بالطريقة.
اعتمد Sputnik-DAO على شكل إجراءات دفعة الوعد لإكمال تنفيذ اقتراح نوع تنفيذ دالة العقد.
) 3.2 اقتراح نقل أموال العقد ( ProposalKind::Transfer )
عند تشغيل مشروع العقود الذكية NEAR لفترة من الوقت، قد تكون حسابات العقود قد تراكمت فيها كمية كبيرة من الرموز القابلة للتداول ### بما في ذلك الرموز الأصلية NEAR، أو غيرها من الرموز التي تتوافق مع معيار NEP-141 (.
في هذه الحالة، يمكن لأعضاء مجتمع Sputnik-DAO تجميع هذه الرموز في حساب receiver_id المحدد من خلال تقديم مقترح لتحويل أموال العقد. internal_execute_proposal)( قد نفذت أيضًا نقطة معالجة مناسبة للمقترحات التي تتطابق مع ProposalKind من نوع Transfer.
سيقوم فرع المعالجة هذا باستدعاء دالة internal_payout)(، لتنفيذ عمليات تحويل لفئات مختلفة من الرموز القابلة للتداول وكذلك لمعرفات المستلمين المختلفة receiver_id)EOA أو حسابات العقود (.
! [])https://img-cdn.gateio.im/webp-social/moments-ef0b959c42e1f5fc6263cd4a86fd078e.webp(
4. ملخص
تقدم هذه المقالة المفاهيم الأساسية لعقد Sputnik DAO - الاقتراح )Proposal(، كما توضح بإيجاز كيفية إنشاء اقتراحات جديدة في Sputnik DAO والتصويت عليها وتنفيذها، وقواعد تغيير الحالة الأساسية للاقتراحات ذات الصلة )Status(.
! [])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(</key,>