النقاط: محفز للمشاركة في النظام البيئي للعملات المشفرة

المؤلف: Kautuk Kundan, Manan @Stackr Labs; المترجم: Leia @TEDAO

مقدمة المترجم:

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

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

هذا هو فهو لا يوفر للمطورين أداة جديدة فحسب، بل يوفر لنظام التشفير البيئي بأكمله طريقة جديدة للتفكير حول كيفية تطبيق الابتكار التكنولوجي لتحسين مشاركة المستخدم وآليات الحوافز.

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

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

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

مشكلة النقاط

لا ينبغي فهم PMF على أنه "Points Market Fit". إذا لم يتمكن المنتج من اكتساب قوة جذب بين المستخدمين بدون نظام النقاط، فإن إضافة نظام النقاط فوقه وتسميته PMF لن يساعد. لا ينبغي أن تكون النقاط هي العامل الرئيسي في تحديد ما إذا كان المستخدم سيختار المنتج X أو المنتج Y. بدلاً من ذلك، يجب أن يوفر كلا المنتجين X وY قيمة جوهرية للمستخدم.

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

قواعد الحصول على نقاط الخبرة (أي النقاط) في اللعبة ينبغي أن تكون واضحة ويمكن التنبؤ بها!

إذا كان نظام النقاط قابلاً للتدقيق وشفافاً ويمكن التنبؤ به، بينما مع الحفاظ على المرونة الكافية للفرق لتصميم الأنشطة حولها، كيف سيكون الأمر؟

نقاط على السلسلة< / p>

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

اعتبر النقاط الموجودة في السلسلة وجودًا مختلفًا عن الرموز المميزة لـ ERC-20. مزيج من نظام النقاط، يمكن إنشاء تجارب فريدة للمستخدمين. ومع ذلك، فإن تنفيذ نظام تتبع النقاط على السلسلة على مستوى الطبقة 1 أو الطبقة 2 يتطلب تكاليف عالية، مما يثير سؤالًا بالغ الأهمية: لماذا لا تستخدم رموز ERC-20 بشكل مباشر لتمثيل النقاط؟

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

البدء السريع للمجموعات الصغيرة

سير عمل Micro-Rollup الشامل

< تمتد نمط = "font-size: 18px؛">المجموعات الصغيرة هي في الأساس أجهزة حالة يمكنها إجراء عمليات منطقية محددة خارج السلسلة ثم الاستعانة بمصادر خارجية للتحقق من التنفيذ إلى برنامج يسمى طبقة التحقق من الصحة "Vulcan". Vulcan مسؤول عن التحقق من صحة تحديثات الحالة وإرسال البيانات المحسوبة إلى السلسلة.

- آلة الحالة لها شكل حالة محدد وحالة التهيئة (حالة التكوين) ) لتحديد حالة البداية لجهاز الحالة.

- تحتوي آلة الحالة على مجموعة من الإجراءات (يمكن فهمها على أنها أنواع المعاملات )، عند استدعائها، تؤدي هذه الإجراءات إلى تشغيل وظائف انتقال الحالة على جهاز الحالة.

-وظيفة انتقال الحالة (STF) هي المسؤولة عن إجراء الحسابات وتحديث الحالة من آلة الدولة. بعد تنفيذ STF، سيتم تجميع هذه الإجراءات في كتلة وإرسالها إلى Vulcan.

أخيرًا، سوف يقوم فولكان بما يلي:

• افترض بشكل متشائم نتيجة الحساب لـ STF قد تكون هناك أخطاء أو تلاعب خبيث، أعد تنفيذ الإجراءات الموجودة في الكتلة للتأكد من صحة النتائج.

• إنشاء بيانات تعريف للكتل التي تم التحقق منها .

• تسوية كاملة على الطبقة 1 وDA .

• يتم إرسال حالة تحديث مجموعة صغيرة إلى DA .

• البيانات الوصفية للكتلة التي تم التحقق منها والمحدثة يتم وضع جذر الحالة في عقد علبة الوارد الصغيرة على الطبقة 1.

  تشكل العملية المذكورة أعلاه معًا مبدأ العمل لإطار عمل Micro-Rollup الخاص بـ Stackr.

نظام النقاط Micro-Rollup

لذا، لماذا تعتبر المجموعات الصغيرة مناسبة بشكل خاص لبناء نظام النقاط؟؟

• توفر المجموعات الصغيرة بيئة تنفيذ سريعة ومرنة ومستضافة ذاتيًا.

  وهذا يضمن أن إصدار النقاط لن يتسبب في "تشغيل" -chain "، ويتم إجراء جميع تحديثات الحالة في أسرع وقت ممكن.

• تدعم المجموعات الصغيرة إمكانية التحقق منها -حسابات السلسلة.

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

• المجموعات الصغيرة تصنع الحالة التدقيق المتاح.

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

• يمكن إنشاء مجموعات صغيرة مباشرة تتم التسوية على الطبقة الأولى.

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

استكشاف بناء النقاط رحلة النظام

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

عند تطوير مجموعة صغيرة، في شكل آلة الحالة ومن الأهمية بمكان أن نفكر في المنطق. يتطلب هذا دراسة متأنية لحالة المجموعة الصغيرة (أي البيانات التي ستحفظها)، والإجراءات التي تحدد سلوك STF (تعمل الوظيفة على الحالة).

التفكير في إنشاء التطبيق من منظور آلة الحالة

التزامًا بالمفهوم أعلاه، استخدمنا Stackr's SDK (مجموعة أدوات التطوير) لبدء تصميم حالة التجميع الجزئي.

التصميم

• عندما يكون المستخدم على المنصة عند تنفيذ إجراءات خارج السلسلة أو على السلسلة، سيتم تشغيل الأحداث. يمكن للمسؤولين أيضًا تعيين الأحداث للمستخدمين.

• يتم تخزين النقاط في جهاز الحالة خارج- سلسلة .

• يحتوي النظام على STF يستخدم لـ تحديد وقت المنحة ومقدار نقاط المستخدم.

• سيؤدي الحدث إلى تشغيل STF والحالة سوف يعتمد على المستخدم ويتم تحديث أحدث النقاط.

• في كل مرة تمر فترة زمنية محددة (عصر )، سيتم إنشاء كتلة تحتوي على تفاصيل حدث المستخدم وحالة جدول النتائج المحدثة.

• يتم إرسال الكتلة إلى شبكة Vulcan لـ تَحَقّق .

• إذا كانت الكتلة تتوافق مع قواعد تمت الموافقة على آلة الدولة.

• تنقسم بيانات الكتلة إلى جزأين. يتم تنفيذ التسوية على Layer-1 وDA على التوالي.

نظام النقاط في بنية المجموعة الصغيرة

تحديد الحالة الأساسية

1. أولاً، نضيفمسؤولين (المسؤول) ) وeventRegistry(تسجيل الأحداث):

• المسؤولين: يمكنهم تسجيل كيانات الأحداث وإنشاء أحداث للمستخدمين العنوان الذي تم تخصيص النقاط له.

• الحدث: أي نوع من الكيانات التي يمكن للمستخدمين كسب النقاط لها. يمكن أن يكون حدثًا على السلسلة أو حدثًا مخصصًا تتم إضافته يدويًا. على سبيل المثال: يمكن أن يحصل حدث التسجيل "التسجيل" (مخصص) على 200 نقطة، ويمكن أن يحصل حدث الاسترداد "المبادلة" (على السلسلة) على 500 نقطة، وما إلى ذلك.

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

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

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

إضافة معالجة تحديث الحالة< /p>

بعد تحديد الحد الأدنى للحالة القابلة للحياة، نحتاج إلى تحديد المخفضات التي تعمل على تحديث الحالة.

3. أضف logEventReducer، المسؤول عن إنشاء إدخالات السجل لأحداث المستخدم.

التفكيك التفصيلي هو كما يلي:

• يستدعي المسؤول إجراء logEvent باستخدام اسم الحدث و معرف المستخدم (لا تحتوي هذه المقالة على مناقشة مفصلة لهذه العملية).

• سيؤدي هذا الإجراء إلى تشغيل آلة الحالة والاتصال logEventReducer .

• سيقوم هذا المخفض بعد ذلك بما يلي:

• ابحث عن النقاط المقابلة للحدث.

• تحديث المستخدمين بناءً على الأحداث وحدث النقاط المقابلة سجل.

على سبيل المثال:< /span>

• يقوم المسؤول باستدعاء logEvent({user: mg-labs.eth, events: "deposit"})

• سوف يجد المخفض إجراء الإيداع في EventRegistry ويسجل حدث الإيداع والنقاط المقابلة له للمستخدم mg-labs.eth.

في هذه المرحلة، قمنا ببناء الحد الأدنى من نظام النقاط قابلة للحياة.

العقد الذكي مقابل العقد الصغير

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

إذا تم إنشاء نظام النقاط كعقد ذكي، فقد يكون هذا النهج ممكنًا ، ولكن تكاليف التخزين في EVM مرتفعة للغاية مقارنة بالتجميع الصغير، وقد لا يكون هذا التصميم مثاليًا.

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

نقاط التخزين المحسوبة

4. إضافة نقاط المستخدم إلى الحالة

سيكون مسؤولاً عن الحفظ إجمالي النقاط المخصصة للمستخدم.

عند تسجيل حدث ما، نقوم أيضًا بتحديث logEventReducer لتحديث نقاط المستخدم.

تم!

إنشاء تكامل قائم على الأحداث مع إمكانية التتبع على السلسلة النظام بهذه البساطة! هل من السهل منح قوى خارقة على السلسلة للخوادم الخلفية؟

نقاط خارج السلسلة على السلسلة - إنزال جوي والمزيد من الاحتمالات✨

جمال هذا النظام هو أنه يسمح بتحديد النقاط يتم استخدامه بسلاسة على السلسلة دون حمل مرتفع.

كما ذكرنا في بداية المقالة، فإن جذر الحالة للمجموع الصغير سيكون في الطبقة 1 عند التسوية. تجدر الإشارة إلى أنه يمكن للمطورين اختيار بيانات الحالة التي تتم تسويتها على الطبقة 1 والتي يتم وضعها كبيانات تعريف على DA، وبالتالي تمكين افتراضات الأمان المختلطة.

في هذا المثال إذا قمنا باستخراج نقاط المستخدم وميركلها عند تسوية الجذر على الطبقة 1، يمكن تحقيق إثباتات تضمين المستخدم في شجرة Merkle مباشرة.

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

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

الخيال

نظام النقاط الذي تم إنشاؤه حاليًا في هذه المقالة هو مجرد غيض من فيض ويمكن تعديله بشكل كبير - التوسع في تنفيذ العديد من الوظائف . فيما يلي بعض اتجاهات التوسيع المحتملة:

المضاعفات ( < /strong>متعددة)

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

أولاً، قم بتحديث سجل الأحداث واحفظ قائمة المضاعفات لكل حدث.

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

لدعم تحديثات الحالة المذكورة أعلاه، قمنا بتحديث logEventReducer لجعله قابلاً للتطبيق  المضاعفات.

لا يمكن للمنطق أعلاه تطبيق مضاعف واحد فحسب، بل يمكنه أيضًا تركيب مضاعفات متعددة عند حساب عدد النقاط المخصصة لحدث ما.

مستحسن

على غرار المُضاعفات، تعد أنظمة التوصية أيضًا أساسية للعديد من أنظمة النقاط. من الصعب إنشاء أنظمة التوصية بشكل كامل على السلسلة نظرًا لأن هياكلها قد تكون معقدة للغاية.

على سبيل المثال، لدى MarginFi نظام توصية متعدد المستويات -

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

أتمتة النقاط

يوفر النظام أعلاه قدرًا كبيرًا من المرونة، ولكنه يتطلب أيضًا بنية تحتية إضافية لمستخدم تحديث المسؤول (أو الروبوتات) نقاط لزيادة عبء العمل.

يمكننا نقل جميع أحداث المستخدم من العقود المحددة ويتم استيرادها إلى مجموعة صغيرة ؛ وفي الوقت نفسه، يركز STF الخاص بـ Rollup على خوارزمية حساب نقاط المستخدم ويعرض طريقة حساب النقاط بشفافية، حتى نتمكن من تحسين استقلالية النظام.

النقاط هي السمعة

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

على سبيل المثال، إذا كانت نقاط Karma الخاصة بـ Reddit مبنية على مجموعة صغيرة ، وربما جعل ما يسمى مازحا "نقاط الإنترنت عديمة الفائدة" متاحة على السلسلة على الفور.

باستخدام إطار العمل هذا، قد يستغرق الأمر بضعة أيام فقط من العمل يمكن نقل نظام نقاط الكارما الحالي إلى السلسلة.

الاستنتاج

أظهر نظام النقاط إمكانات كبيرة عند تقاطع Web2 وWeb3، وهناك حاجة إلى بنية هجينة جديدة لتحقيق ذلك . هذا هو المكان الذي توفر فيه المجموعات الصغيرة الفرص.

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