يوميات تطوير العقود الذكية من Rust (10-3): المفاهيم الأساسية ل Sputnik DAO - تحليل (Proposal) الاقتراح

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

Sputnikdaov2 هو عقد ذكي مخصص لأغراض التصويت في إدارة مجتمع Sputnik-DAO. ستتناول هذه المقالة المفاهيم الأساسية لهذا العقد: الاقتراح (Proposal)، وستتناول المقالات اللاحقة "الاقتراح" أنماط إدارة مجتمع DAO ذات الصلة (Policy).

1. بدء الاقتراح ( إضافة اقتراح )

يمكن لكل عضو في مجتمع Sputnik-DAO التعبير عن آرائه أو تقديم اقتراحات حول حوكمة أو إدارة المشروع. بعد ذلك، يمكن لكل عضو في المجتمع يمتلك أسهمًا في DAO مراجعة الاقتراح والتصويت عليه. بعبارة أخرى، يمكن لكل عضو في Sputnik-DAO التأثير على اتجاه المشروع المستقبلي من خلال التصويت على اقتراحات الآخرين أو تقديم اقتراحات إدارية جديدة.

على مستوى العقود, يمكن لأعضاء مجتمع DAO استدعاء طريقة add_proposal() المقدمة من عقد sputnikdaov2 لبدء اقتراح جديد.

صدأ حانة fn add_proposal( & mut self ، اقتراح: ProposalInput) -> u64

يجب على مقدم الاقتراح تقديم تفاصيل الاقتراح (ProposalInput):

• الوصف النصي للاقتراح (Description). ستظهر هذه المعلومات علنًا على الواجهة الأمامية لصفحة Sputnik-DAO، لمساعدة أعضاء المجتمع على فهم هدف الاقتراح ومعناه.

• نوع الاقتراح ( kind ). يجب على مقدم الاقتراح اختيار نوع الاقتراح بناءً على الآراء المقدمة حول إدارة المشروع ( مثل إذا كانت الوظائف الأساسية لعقد الذكاء تتطلب اختيار نوع FunctionCall، وإذا كانت تحويلات أموال المشروع تتطلب اختيار نوع Transfer، وإذا كانت إعدادات/تغييرات مستوى التحكم في صلاحيات إدارة العقد تتطلب اختيار نوع ChangePolicyAddOrUpdateRole، وغيرها ).

ستُستخدم معلومات ProposalInput هذه كمعاملات عند إدخالها في طريقة add_proposal()، حيث ستقوم هذه الطريقة بإجراء التحقق والمعالجة ذات الصلة، وستُنتج اقتراحًا مع معلومات التهيئة الكاملة Proposal(. وفي النهاية، سيتم ربط هذا الاقتراح بمعرّف فريد proposal_id، ليتم إضافته إلى خريطة Contract.proposals المدارة عالميًا بواسطة عقد Sputnik-DAO بالشكل <key, value=""> في مجموعة الاقتراحات ).

تحتوي الاقتراحات المحددة من قبل Sputnik-DAO على المعلومات الكاملة التالية:

صدأ اقتراح هيكل الحانة { معرف الحانة: U64 ، مقترح الحانة: AccountId ، وصف الحانة: سلسلة ، نوع الحانة: ProposalKind ، حالة الحانة: حالة الاقتراح ، حانة vote_period_end: BlockHeight, pub vote_counts: HashMap<votepolicy, hashmap<accountid,="" balance ="">>, تصويتات pub: HashMap<accountid, vote="">, الحانة submission_time: الطابع الزمني ، }

في هذا الاقتراح، سيتم استخراج محتوى الخصائص description و kind من معلومات ProposalInput المقدمة عند إنشاء الاقتراح بواسطة proposer. وبشكل أكثر تحديدًا، تستخدم هذه العقود الذكية خاصية From في لغة Rust لتنفيذ تحويل النوع من ProposalInput إلى Proposal.

هذه العملية التحويلية ترتبط بمزيد من معلومات حالة الاقتراح:

• سيتم تعيين خاصية المقترح في الاقتراحات المضافة تلقائيًا إلى add_proposal()، وهو الشخص الذي استدعى هذه الطريقة، أي env::predecessor_account_id()، وهذه الخاصية حقيقية وغير خاضعة لسيطرة المستخدم؛

• الحالة المقترحة المضافة حديثًا (status) تم تهيئتها بشكل افتراضي إلى ProposalStatus::InProgress، أي أنها لا تزال في مرحلة التصويت؛

• تم تعيين وقت بدء اقتراح الإضافة الجديد (submission_time) إلى طابع الوقت لهذا الكتلة env::block_timestamp();

• نظرًا لعدم وجود أي تصويت عند تقديم الاقتراح الجديد، فإن حالة التصويت (vote_counts، الأصوات ) جميعها مبدئية فارغة HashMap::default().

يجب ملاحظة أن هناك مفهوم إيداع الاقتراح (proposal_bond) في Sputnik-DAO، وسيتم إدارة هذا الإيداع وفقًا لنموذج الحوكمة المجتمعية المحدد لـ Sputnik-DAO (Policy).

يمكن معرفة من خلال قراءة الشيفرة ذات الصلة أن العقد يتطلب من مقدم الاقتراح إيداع مبلغ معين من رموز NEAR كضمان للاقتراح الجديد عند استدعاء طريقة add_proposal(). سيتم إعادة هذا الإيداع إلى مقدم الاقتراح من خلال استدعاء الدالة الداخلية للعقد internal_return_bonds() عند انتهاء الاقتراح بشكل طبيعي ( بتصويت المجتمع لصالح ProposalStatus::Approved | أو بتصويت المجتمع ضد ProposalStatus::Rejected).

ومع ذلك، اكتشفت BlockSec سابقًا عند تفسير كود العقد في هذا المكان:

لا يحتفظ Sputnik-DAO بمبالغ ودائع الاقتراحات التاريخية لكل مستخدم بشكل منفصل عند معالجة ودائع الاقتراحات. وعندما يقوم المستخدم ببدء المعاملة، واستدعاء طريقة العقد add_proposal() لإضافة اقتراح جديد، قد يتم إرفاق هذه المعاملة بأكثر من ما تحدده سياسة الحوكمة الخاصة بالـ DAO (Policy) من حيث policy.bounty_bond من رموز NEAR. وهذا سيؤدي إلى وجود جزء زائد من الوديعة، ولن يتم إرجاعه للمقترح عند تنفيذ الدالة الداخلية internal_return_bonds.

بعد أن تواصل فريق BlockSec مع الجهة المعنية بالمشروع في الوقت المناسب، تم إصلاح هذه المشكلة (160 في النهاية.

سيتم توضيح المزيد من استراتيجيات التحقق والمعالجة المتعلقة بمقترحات سبوتنيك-DAO الداخلية في "يوميات تطوير العقود الذكية Rust )10-4( تحليل نموذج الحكم المجتمعي لسبوتنيك DAO" الذي سيتم إصداره لاحقًا.

2. حالة الاقتراح)Proposal Status#158被确认并及时在PR#

أي اقتراح قياسي في Sputnik-DAO قد يمر عبر مجموعة متنوعة من الحالات. ( حالة الاقتراح الجديدة تم تهيئتها كالتالي: InProgress )

صدأ pub enum ProposalStatus { قيد التقدم, تمت الموافقة, مرفوض, تمت الإزالة, منتهية الصلاحية، تم الانتقال, فشل, }

تغيير حالة الاقتراحات في حوض الاقتراحات مدفوع بطريقة أخرى من العقد act_proposal().

يمكن لأعضاء Sputnik-DAO استدعاء طريقة act_proposal() لتنفيذ الإجراءات التالية على الاقتراح المحدد بواسطة id (:

صدأ pub enum Action { AddProposal, إزالةاقتراح ، التصويتموافقة، التصويترفض ، تصويتإزالة ، إنهاء, MoveToHub ، }

نموذجي، بالنسبة للاقتراحات التي في حالة InProgress، يمكن لأعضاء مجتمع DAO استدعاء act_proposal)( لتنفيذ عمليات التصويت المحددة:

• الإجراء::التصويتموافقة: التصويتموافقة;
• الإجراء::VoteReject: جدول ضد;
• Action::VoteRemove: يعتقد أن هذا الاقتراح ليس له معنى عملي، يجب إزالته؛

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

بعد التغيير:

• إذا كانت حالة الاقتراح هي Approved، فسيتم تنفيذ الاقتراح عن طريق استدعاء internal_execute_proposal)(;

• إذا كانت حالة الاقتراح مرفوضة أو تمت إزالته، فسيتم تنفيذ العمليات الختامية من خلال استدعاء internal_reject_proposal)(.

من الجدير بالذكر أن الحالة Rejected تختلف عن الحالة Removed في أن المقترحات التي تحدد في النهاية على أنها Removed ستتم إزالتها مباشرة من مجموعة المقترحات، و) كعقوبة ( لن يتم إعادة المبلغ المودع في البداية إلى مقدمي المقترحات. أما بالنسبة للمقترحات ذات الحالة Rejected، فسيتم الاحتفاظ بالمقترح في مجموعة المقترحات، وسيتم إعادة المبلغ المودع المناسب.

! [])https://img-cdn.gateio.im/webp-social/moments-84ee9ca630a4cdcdb0d2eb63450a7cf4.webp(

3. تنفيذ الاقتراح ) تنفيذ الاقتراح (

إذا كانت حالة الاقتراح بعد انتهاء التصويت متطابقة مع Approved، فسوف تستمر دالة العقد act_proposal)( في استدعاء دالة internal_execute_proposal)( لتنفيذ محتوى القرار المتضمن في الاقتراح.

أنواع الاقتراحات المدعومة من Sputnik-DAO مدرجة أدناه ) معظم أنواع الاقتراحات تتعلق بتحديث تكوين نمط حوكمة DAO (:

• نوع الاقتراح::ChangeConfig
• نوع الاقتراح::ChangePolicy
• نوع الاقتراح::AddMemberToRole
• ProposalKind::إزالة العضو من الدور
• نوع الاقتراح::FunctionCall
• ProposalKind::UpgradeSelf
• نوع الاقتراح::UpgradeRemote
• نوع الاقتراح::نقل
• نوع الاقتراح::SetStakingContract
• نوع الاقتراح::AddBounty
• نوع الاقتراح::BountyDone
• نوع الاقتراح::تصويت
• نوع الاقتراح::FactoryInfoUpdate
• ProposalKind::تغيير السياسة لإضافة أو تحديث الدور
• نوع الاقتراح::ChangePolicyRemoveRole
• ProposalKind::تغيير سياسة تحديث سياسة التصويت الافتراضية
• ProposalKind::تغيير سياسة تحديث المعلمات

تم تنفيذ كل نوع من أنواع الاقتراحات المذكورة أعلاه في فرع المعالجة المقابل في الدالة internal_execute_proposal)(. ستتناول هذه الفقرة بعمق نوعين نموذجيين من سير العمل لمعالجة الاقتراحات:

• نوع الاقتراح::FunctionCall
• نوع الاقتراح::نقل

) 3.1 تنفيذ اقتراح دالة العقد ( ProposalKind::FunctionCall )

دالة internal_execute_proposal() تنفذ المدخلات التالية لمطابقة ProposalKind كـ FunctionCall:

صدأ ProposalKind::FunctionCall { receiver_id, actions } => { let mut promise = Promise::new###receiver_id.clone()(; لعمل في الإجراءات { وعد = promise.function_call) action.method_name، action.args ، الدعوى.الودائع, action.gas، ( } promise.into() }

تم تمرير مقترح من نوع FunctionCall بالفعل من خلال معلمة ProposalInput عند استدعاء المقترح لطريقة add_proposal)(، والذي يتضمن العمليات الوظيفية المحددة التي يجب تنفيذها )actions(.

تسمح عقود NEAR بربط عدة استدعاءات دالة متتالية داخل وعد واحد. لذلك يمكن أن تحتوي الإجراءات التي حددها المقترح الأصلي على أنواع متعددة من كائنات ActionCall كما يلي:

صدأ pub struct ActionCall { حانة method_name: سلسلة ، حانة args: Vec ، pub الإيداع: الرصيد, غاز الحانة: الغاز ، }

يمكن لكل ActionCall تحديد اسم طريقة العقد المناسبة ووسائط الطريقة وغيرها.

استنادًا إلى ما سبق، اعتمد Sputnik-DAO على شكل إجراءات دفعات الوعد لتنفيذ اقتراح نوع تنفيذ وظيفة العقد.

! [])https://img-cdn.gateio.im/webp-social/moments-427716593b21fa32b47855ceb5e101fc.webp(

) 3.2 تنفيذ اقتراح تحويل الأموال (ProposalKind::Transfer)

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

في هذه المرحلة، يمكن لأعضاء مجتمع Sputnik-DAO تجميع هذه الرموز في حساب receiver_id المحدد من خلال تقديم اقتراح نقل أموال العقد.

نفس internal_execute_proposal###( ينفذ أيضًا نقطة معالجة متناسبة للمقترحات التي نوعها ProposalKind هو Transfer:

صدأ نوع الاقتراح:: نقل { token_id ، receiver_id ، المبلغ } = > { self.internal_payout)token_id ، receiver_id ، amount( .into)( }

سيقوم هذا الفرع الأساسي باستدعاء دالة internal_payout)(، لتنفيذ عملية تحويل لرموز الفونجيبل المختلفة وأنواع مختلفة من receiver_id)EOA أو حسابات العقود(.

! [])https://img-cdn.gateio.im/webp-social/moments-ef0b959c42e1f5fc6263cd4a86fd078e.webp(

4. الملخص والتوقعات

لقد قدمت هذه المقالة للمستخدمين المفاهيم الأساسية لعقد Sputnik DAO - الاقتراح )Proposal(، كما أوضحت بإيجاز كيفية إنشاء اقتراح جديد في Sputnik DAO والتصويت لتنفيذه، وقواعد تغيير الحالة الأساسية للاقتراحات ذات الصلة )Status(.

سيتم توضيح تفاصيل أكثر عن تنفيذ وتكوين نموذج الحوكمة في Sputnik-DAO بناءً على الاقتراح الخاص بمذكرات تطوير عقود Rust الذكية )Policy(، ترقبوا!

! [])https://img-cdn.gateio.im/webp-social/moments-eb73d5e15f6161f0a4b442cd4b99a91e.webp(</accountid,></votepolicy,></key,>