هناك نسخة من الـstaking حيث لا تكون أنت من يقوم بـstaking.
كنت غالبًا أظن أن الـstaking شيء يمكن أن تفعله المحفظة فقط. اتصال، تفويض، انتظار. هذا هو النموذج في كل الأماكن التي استخدمتها من قبل.
لكن عندما قرأت قسم abstraction في @Dusk stake، افترضت أنه مجرد تفويض تحت اسم جديد. احتجت إلى عدة مرورّات على الوثائق قبل أن أدرك أن الأمر ليس كذلك.
اتضح أن الموضوع يعتمد على كيفية تعامل Dusk مع العقود: يمكنها الاحتفاظ وإدارة الحالة مثلما تفعل المحفظة، وليس فقط تشغيل المنطق. لذلك يمكن للعقد أن يقوم بـstaking، وليس فقط المحفظة.
إليك التسلسل: العقد لا يستدعي دالة الـstaking مباشرة. الأموال تدخل إلى العقد أولًا، ثم يقوم بتحويل من عقد إلى عقد إلى عقد الـstake. يعمل إلغاء الـstaking والمكافآت عبر الاستدعاءات الراجعة (callbacks). الحد الأدنى ما زال 1,000 DUSK، والقواعد الخاصة بالتفعيل هي نفسها تمامًا كما في الحالة العادية.
ما الذي جعلني أندهش من كلمة "abstraction" هنا؟ لا يعني تعقيدًا أقل، بل يعني فقط تغيير من يتولى المسؤولية. الـstaking بواسطة المحفظة يكون بسيطًا لأن الشخص هو من يقرر. أما الـstaking بواسطة عقد فيعني أن الكود يجب أن ينجز كل قرار وحده. callback واحد سيئ، وقد تتعطل المكافآت.
ومع ذلك، لست متأكدًا من أين تقع الحدود عندما يتعطل شيء ما. العقد يملك سير العمل (workflow)، لكن البروتوكول ما زال يملك أهلية المشاركة في الإجماع (consensus eligibility). لذا إذا تعثّر عقد الـstaking المُجمَّع، فهل هذا خلل في العقد أم مخاطرة في البروتوكول؟ لم أجد إجابة لذلك بعد.
@Dusk $DUSK #dusk
كنت غالبًا أظن أن الـstaking شيء يمكن أن تفعله المحفظة فقط. اتصال، تفويض، انتظار. هذا هو النموذج في كل الأماكن التي استخدمتها من قبل.
لكن عندما قرأت قسم abstraction في @Dusk stake، افترضت أنه مجرد تفويض تحت اسم جديد. احتجت إلى عدة مرورّات على الوثائق قبل أن أدرك أن الأمر ليس كذلك.
اتضح أن الموضوع يعتمد على كيفية تعامل Dusk مع العقود: يمكنها الاحتفاظ وإدارة الحالة مثلما تفعل المحفظة، وليس فقط تشغيل المنطق. لذلك يمكن للعقد أن يقوم بـstaking، وليس فقط المحفظة.
إليك التسلسل: العقد لا يستدعي دالة الـstaking مباشرة. الأموال تدخل إلى العقد أولًا، ثم يقوم بتحويل من عقد إلى عقد إلى عقد الـstake. يعمل إلغاء الـstaking والمكافآت عبر الاستدعاءات الراجعة (callbacks). الحد الأدنى ما زال 1,000 DUSK، والقواعد الخاصة بالتفعيل هي نفسها تمامًا كما في الحالة العادية.
ما الذي جعلني أندهش من كلمة "abstraction" هنا؟ لا يعني تعقيدًا أقل، بل يعني فقط تغيير من يتولى المسؤولية. الـstaking بواسطة المحفظة يكون بسيطًا لأن الشخص هو من يقرر. أما الـstaking بواسطة عقد فيعني أن الكود يجب أن ينجز كل قرار وحده. callback واحد سيئ، وقد تتعطل المكافآت.
ومع ذلك، لست متأكدًا من أين تقع الحدود عندما يتعطل شيء ما. العقد يملك سير العمل (workflow)، لكن البروتوكول ما زال يملك أهلية المشاركة في الإجماع (consensus eligibility). لذا إذا تعثّر عقد الـstaking المُجمَّع، فهل هذا خلل في العقد أم مخاطرة في البروتوكول؟ لم أجد إجابة لذلك بعد.
@Dusk $DUSK #dusk
