كنت أظن دائمًا أن «العقد السري» يعني قفل الكود والبيانات بالكامل، بحيث لا يستطيع أي طرف خارجي معرفة ما يحدث داخله، إلى أن بحثت أخيرًا في معيار XSC داخل Dusk وفهمت طريقة عمله بالفعل، عندها أدركت أنني كنت أفهم الاتجاه بشكل خاطئ.
لنضرب مثالًا: هذا المنطق يشبه صندوق الاقتراع المغلق في الانتخابات—بعد أن تُدفع كل ورقة اقتراع إلى الصندوق، لا يستطيع من هم خارج الصندوق رؤية لمن صوّتَ كل شخص تحديدًا، لكن عند انتهاء فرز الأصوات وإعلان النتيجة، يستطيع الجميع التأكد أن النتيجة حُصِلت عليها فعلاً من إحصاء حقيقي، ولا يمكن لأي أحد أن يضع أوراقًا سرًا أو يعبث بالعدد؛ لأن العملية برمتها تعتمد على مجموعة من طرق التحقق المتعارف عليها من الجميع، ولا تحتاج إلى فتح كل ورقة اقتراع لتصدق النتيجة. وما تفعله XSC يشبه ذلك—المحتوى التفصيلي لتنفيذ العقد السري لا يُنشر للعموم، لكن البرهان الصفري للمعرفة (zero-knowledge proof) يضمن أن العقد قد نفّذ فعلًا وفقًا للقواعد، دون أن يتمكن أحد من إجراء تلاعب «في الخفاء» دون أن يراه أحد. وعند الحاجة إلى تدقيق، يستطيع الجهة الرقابية التحقق من الالتزام، دون أن يكون مطلوبًا كشف المحتوى للجميع.
وأرى أن هذا أذكى بكثير من مجرد «إخفائه»، لأن «الإخفاء» و«القدرة على الوثوق» أمران متعارضان بطبيعتهما—إذا أخفيت كل شيء بإحكام شديد، فلماذا ينبغي للآخرين أن يصدقوا أنك لم تُجرِ غشًا؟ ما تسعى XSC إلى حله هو هذا التناقض، بحيث يمكن لـ «غير المرئي» و«الموثوق» أن يتحققا معًا. لكن في ذهني أيضًا سؤال جديد: إن نظام التحقق هذا يعتمد على منطق الكود أم في النهاية يحتاج إلى جهة ما لتختم كل شيء رسميًا وتؤكد صحة الأمر؟ لم أفهم ذلك بالكامل بعد، لذلك ما زلت بحاجة إلى مواصلة البحث.
إذا كنت أنت، فماذا تميل أكثر إلى تصديق أي نوع من آليات «غير مرئية لكنها موثوقة»؟
حسبتُ مساحة «مهمة الساحة»: نافذة التحقق مهووسة—بعد استبعاد الطرفين، فهي لا تعمل إلا لأقل من 21 ساعة. كثيرون يظنون: «في يوم 24 فقط اضغط بشكل عشوائي»، لكن هذا الفهم خاطئ.
لتوضيح التفاصيل: تبدأ نافذة التحقق في 24 أغسطس الساعة 03:00 بالتوقيت العالمي (UTC) وتنتهي عند 23:59 (UTC). المدة أقل من 21 ساعة. بعد هذا الوقت، حتى لو كنت قد نشرت في وقتٍ سابق ودخلت ضمن المراكز الـ500 الأولى في لوحة الترتيب، فلن تتمكن من تأكيد ذلك.
أنصحك بهذا التفصيل لكل من يريد المنافسة على المراكز: احفظه الآن في مذكّراتك، ولا تنتظر حتى يوم 24 لتبحث عنه من جديد.
فما هو التسلسل الكامل للعملية؟ مررتُ بها بنفسي وقسّمتها إلى خطوات: أولاً، ابحث في Binance Wallet عن مدخل النشاط—يمكنك الدخول عبر شريط اللافتة في الصفحة الرئيسية أو عبر قسم Booster في صفحة Discover. ثم اختر نشاط TermMax. بعد ذلك توجد خمس مهام: متابعة X، وإعادة تغريد بيان رسمي، والإجابة عن سؤال اختيار من متعدد، والانضمام إلى Discord، وربط المحفظة. يجب إنجاز الخمس كلها؛ أي مهمة ناقصة لا تُحسب—هنا النقطة المهمّة: ليس معنى ذلك أن القيام بعدد أكبر يزيد فرصة الفوز. بل يجب إكمال المهام الخمس بالكامل للحصول على أهلية الدخول. إنجازه أكثر لا يفيد، وإن كان ناقصًا فهو غير صالح. بعد إتمام كل مهمة، ارجع واضغط مرة واحدة على «Verify». عندما تظهر لك جميع المهام الخمس على أنها «تم التحقق»، تكون عندها قد دخلت رسميًا في قرعة السحب.
أما مهمة الساحة فهي خط مستقل آخر: نافذة النشر من 17 إلى 21. هذه النافذة تجاوزت نصفها تقريبًا—ومن لم ينشر بعد، فليغتنم آخر يومين. ثم تنتظر نافذة التحقق الـ21 ساعة في يوم 24، وبعدها ارجع للضغط على التأكيد.
تقييمي الشخصي هو أن عتبة هذا النشاط مصممة عمدًا لانتقاء المشاركين: إنجاز المهام الخمس كلها هو الشرط، وهذه فكرة «كل شيء لازم يكون صحيحًا كي تُحسب» تختلف عن الأنشطة التي «كل مهمة تُحسب وحدها». نعم، قد تتطلب هذه العملية بعض الجهد الإضافي، لكن بالمقابل يعني ذلك أن «المتطفّلين» أقل احتمالًا للحصول على أهلية الدخول دون جدية، بينما الذين يشاركون بجد لديهم ميزة نسبية.
@TermMax هذا المشروع بحد ذاته يحل مشكلة قديمة تتعلق بعدم قابلية التنبؤ بأسعار/معدلات الإقراض، والنشاط مجرد بوابة. إذا كنت حقًا تريد البقاء، ففهم منطق السعر الثابت يستحق بضع دقائق أكثر من التعلّق بتسلسل المهام إلى حدّ الاختناق. #TermMax
هل تسمحون لي أن أسمع خططكم الزمنية؟
أمام نافذة التحقق التي تقل عن 21 ساعة—كيف ستنظم وقتك؟
كنت أظن دائمًا أن عنوان المحفظة يجب أن يكون مثل: "شخص واحد لكل هوية"، إلى أن عثرت على منطق توليد محفظة Dusk؛ عندها اكتشفت أنني فكرت في الأمر بطريقة جامدة أكثر من اللازم.
والتفاصيل كالتالي: تُنشأ محفظتك من "بذرة" واحدة، لكن هذه البذرة ليست مُقيَّدة بأن تنبت منها هوية واحدة فقط؛ بل يمكنها أن تُنتج في الوقت نفسه عدة "سجلات" مختلفة. وتحت كل سجل، يوجد عنوان عام وعنوان خفي على حدٍّ سواء، فوجهان مختلفان مُعلّقان تحت الهوية نفسها. وبعدها فهمت هذا بتشبيه — يشبه قليلًا امتلاكك حسابات اجتماعية متعددة على هاتفك، كلها مسجّلة بنفس رقم الهاتف، لكن يمكنك أن تجعل "حساب العمل" يظهر تحديثاته للعموم، بينما تجعل "حسابًا خاصًا" لا يراه إلا أنت. في الحقيقة، ما خلف الحسابات هو نفس الشخص، لكن الوجوه التي تُعرض للآخرين يمكن أن تكون مختلفة تمامًا. والأهم أن هذه "الوجوه" ليست حسابات مُسجّلة بشكل مستقل عن بعضها، بل تنمو من نفس الجذر.
هذا التصميم كلما فكرت فيه أكثر وجدته مثيرًا للاهتمام، لأنه يعالج مشكلة صغيرة لم تكن تخطر ببالي سابقًا: إذا كان الخصوصي والعلني لا بد أن يكونا محفظتين منفصلتين تمامًا، فسيكون عليك إدارة مجموعتين من عبارات الاسترجاع، وعند التحويل ستحتاج أيضًا إلى التفكير أولًا: "أي محفظة سأستخدم هذه المرة؟" الأمر مزعج بالتأكيد، وقابل للالتباس بسهولة. أما تصميم "بذرة واحدة، سجلات متعددة" فهو عمليًا يحوّل موضوع "الانتحال" من "إطلاق مشروع جديد" إلى "تفرّع أغصان على الشجرة نفسها"، فتَنخفض تكاليف الإدارة فورًا.
الشيء الذي يثير فضولي الآن أكثر هو: عند الاستخدام الفعلي، هل سيُميّز الناس فعلاً بدقة بين "هذا السجل مخصص لهذا فقط"، أم سيكتفون بالكسل ويستخدمون سجلًا واحدًا لتغطية كل شيء؟ لا أعرف إجابة ذلك في نفسي.
إذا كنت أنت، فكيف ستستخدم تصميم "بذرة واحدة ووجوه متعددة"؟
لقد قمت بنفسي بعمل رافعة دورة مرة واحدة يدويًا؛ في النهاية عبثت بست صفقات كاملة، فابتلعت الرسوم قرابة نصف الأرباح. لم أفهم الأمر حقًا إلا بعد إتمام العمل أن هذا يمكن إنجازه بصفقة واحدة الآن.
وهذا هو سبب رغبتي في الحديث عن هذا الشيء المسمى GT. كثيرون ما إن يروا كلمتي «الرافعة» حتى يعتقدوا تلقائيًا أنها معقدة وخطرة. في الحقيقة فهمها للمبتدئين ليس بتلك الصعوبة؛ الأهم هو معرفة أي خطوة يوفرها لك.
في السابق، إذا أردت في DeFi تنفيذ اقتراض دائري مع إضافة رافعة، كانت العملية تقريبًا كالتالي: تودع، ثم تقترض، ثم تودع مرة أخرى، ثم تقترض مرة أخرى... وتكرر ذلك لعدة جولات. في كل خطوة كان عليك أن تؤكد بنفسك، وكان عليك دفع gas مرة لكل خطوة. وأي انزلاقة في أثناء أي خطوة قد تقود إلى الوقوع في فخ. هذه السلسلة من الخطوات غير ودية تمامًا للمبتدئين؛ حتى مجرد قراءة الدروس قد يستغرق عشر دقائق.
GT الخاص بـ @TermMax (Gearing Token) ضغط هذه السلسلة كلها في صفقة واحدة؛ لا يحتاج المستخدم إلى التنقل ذهابًا وإيابًا بين عدة خطوات بنفسه. والأهم من ذلك أنه ليس مثل استراتيجيات المراكز الرافعة التقليدية التي «قد تتم تصفيتها في أي لحظة». لأن هيكل الفائدة الثابت الكامن وراءه يجعل التكاليف مُقفلة عند لحظة فتح المركز، ولا يمكن أن تنفجر فجأة بسبب تقلبات السوق برسوم كثيرة لم تكن قد حسبتها.
برأيي الشخصي، هذه النقطة تستحق أن يقضي المبتدئون وقتًا في فهمها أكثر من مجرد «كم تبلغ قيمة جائزة المسبح $TMX». فإدراك المخاطر لأدوات الرافعة أهم بكثير من اقتناص مكافأة من فعالية مرة واحدة. طبعًا، قفل التكاليف لا يعني عدم وجود مخاطر؛ تذبذب سعر الأصل محل التعامل نفسه وتغيرات السيولة في السوق—هذه الحيطة اللازمة لا بد ألا تنقص، خصوصًا ألا يفهم المبتدئ أن «عدم وجود تصفية» يعني «عدم وجود مخاطر».
إذا كنت تتعامل مع منتجات من هذا النوع لأول مرة، فاقتراحي هو أن تبدأ أولًا بمبلغ صغير لتجرب مرة واحدة، لتشعر بالعملية الكاملة من فتح الصفقة حتى الاستحقاق، ثم فكر في زيادة الاستثمار. لا تبدأ فورًا برافعة بحجم كبير.#TermMax
في الأسبوع الماضي، قمت بإضافة مبلغ إضافي إلى DUSK التي كنت قد قمت بتعليقها بالفعل (staking). ظننت—مثل المرّة الأولى—أن الإضافة ستصبح فعّالة بالكامل فورًا وتبدأ باحتساب الأرباح. لكن عندما فتحت صفحة الـ staking، شعرت بالارتباك قليلًا: يظهر أن 90% من الجزء الإضافي يتم احتسابه فورًا كحالة فعّالة، بينما الـ10% المتبقية تبقى هناك «مُعلّقة» دون إيرادات، ولا يمكنك تحريك هذه النسبة إلا إذا قمت بإلغاء الـ staking بالكامل واسترجعت المبلغ.
في البداية، اعتقدت أن هذا التصميم غريب بعض الشيء، ثم اتّضح لي المنطق تقريبًا—يشبه إلى حدّ ما إعادة شحن باقة الهاتف: تظن أنك إذا شحنت 100 يوان ستستهلك فورًا 100 يوان من رصيد/بيانات، لكن النظام يخبرك أن 90 يوان تصبح فعّالة مباشرة، والـ10 يوان المتبقية يجب أن تنتظر حتى تلغي الباقة وتُعيد الاشتراك لتُستخدم. أليس هذا مزعجًا؟ ولكن من زاوية أخرى، يبدو أن الهدف هو منع من يستغل فكرة «التكديس غير المتناهي للـ staking في أي وقت» لتضخيم تأثيره في الإجماع (consensus) بشكل لحظي. لذلك يضيف عامل احتكاك يجعل التغيّر في الحجم لا يتم دفعة واحدة.
كما اكتشفت تفصيلًا آخر: كي يشارك الـ staking الإضافي فعليًا في الإجماع، يجب أيضًا انتظار فترة نضج تقارب 4320 بلوك—حوالي 12 ساعة تقريبًا. أي أنه لا يكفي تقديمه ليصبح قابلًا للاستخدام فورًا، وهذا يختلف تمامًا عن فهمي السابق «الـ staking = يصبح فعّالًا فورًا». إضافةً إلى ذلك، لاحظت أن الذين يحصلون على أرباح «نظيفة بالكامل» (بنفسهم مباشرة) هم بشكل أساسي أولئك الذين يشغّلون العقد بأنفسهم على مدار 24 ساعة. أما أنا، الذي لا أريد إدارة الخوادم بنفسي وأفضّل استخدام مجمّع staking من طرف ثالث لتشغيله نيابةً عني، فإن أرباحي تكون مُعبّأة عبر طبقة التفويض (delegation). وبالتالي فهي ليست مطابقة تمامًا للأرباح التي يحصل عليها من يشغّل عقدًا بنفسه.
هذه التفاصيل لم أكن أفكر فيها من قبل في هذا الاتجاه. اتضح أن موضوع الـ staking ليس «بسيطًا وغبيًا» كما يتصوّره البعض.
إذا كنت أنت، واكتشفت أن الـ staking الإضافي لا يُفعّل سوى 90% مباشرة، ما سيكون رد فعلِك الأول؟
في الأسبوع الماضي، رأيت زميلة منشورًا يقول: "Dusk يمكنه إخفاء التحويل بالكامل". ثم التفتت إليّ وسألت: "أليس هذا هو البلوك تشين الخاص بالأموال السوداء؟" توقفت للحظة، لأن الأمر لا يتطابق إطلاقًا مع ما أفهمه. فبدأت أبحث بسرعة: ما الذي يحدث بالضبط؟
لاحقًا فهمت كيف أشرح لها. الفكرة أنَّه عندما تستلم طردًا، يعرف موظف التوصيل رقم طلبك ووزن الطرد وهل توجد أي حالة غير طبيعية، لكنه لا يعرف ما الذي يوجد داخل الصندوق فعليًا. وإذا حدث نزاع، يمكن للمنصة الرجوع إلى السجلات لإثبات أن "هذا الطرد موجود فعلًا، والإجراءات تمت بشكل مطابق"، دون الحاجة إلى فتح الصندوق وإظهاره للكل.
في Dusk يوجد تصميم يُسمى "الإفصاح الانتقائي" يشبه هذا تمامًا: تفاصيل المعاملات غير مرئية افتراضيًا للآخرين، لكن يمكنك أنتَ توليد وثيقة/إثبات بشكل متعمد لإظهار أن هذه المعاملة "مطابقة للإجراءات" و"تمت فعلاً" لفئات محددة فقط—مثل الجهة التنظيمية أو الطرف المتعاقد—دون عرض جميع التفاصيل على الجميع.
هذا الأمر مختلف تمامًا عما ظنته زميلتي بأنه "إخفاء كامل". الخصوصية هنا ليست زر تشغيل/إيقاف، وليست "إما أن تُخفي كل شيء أو تُظهر كل شيء"؛ بل هي أشبه بمسار/توجيه: أنتَ تحدد إلى من تُعرض المعاملة وكم مقدار ما يتم إظهاره.
بعد أن فكرت أكثر، وجدت أن هذا التصميم واقعي جدًا. ما تخشاه المؤسسات حقًا ليس "أن تُراجع/تُدقق" بقدر ما هو "أن تنكشف أوراقها وخططها أمام المنافسين". والإفصاح الانتقائي يعالج هذا الألم تحديدًا، وليس وسيلة لمساعدة أي طرف على التهرب من التنظيم.
وهذا مختلف تمامًا عما كنت أعتقده عن العملات الخصوصية. كلما حاولت أن أتعمق، كلما شعرت أن هذه التفاصيل يتجاهلها معظم الناس.
إذا كنت مكانك، فما الحالة التي تفضلها لسجل التحويل الخاص بك؟
كنت دائمًا أشعر أن موضوع "إجراء KYC على السلسلة" متناقض نوعًا ما—تريد الخصوصية، وفي الوقت نفسه يتوجب عليك تمكين الآخرين من التحقق من هويتك، أليس هذا تناقضًا؟ إلى أن حَفرت ووجدت داخل Dusk شيئًا اسمه Citadel، حينها اكتشفت أن الأمرين لا يتعارضان أصلًا، وأنني كنت أفهمه بشكل خاطئ.
خلّيني أضرب مثالًا: عندما تتعامل عادةً في أمورك، يتوجب عليك إبراز بطاقة الهوية مرارًا—فتح حساب في البنك يتطلب التحقق مرة، استئجار شقة يتطلب تحققًا مرة، التسجيل للامتحان يحتاج تحققًا مرة أخرى. في كل مرة، عليك تصوير وجه بطاقة الهوية ظهرها ووجهها وإرسال ذلك للطرف الآخر، ويتم حفظ معلوماتك مرة بعد مرة، ولا تعرف أبدًا إلى أين ذهبت هذه البيانات في النهاية. ما يفعله Citadel يشبه إصدارك "وثيقة يمكنك من خلالها إثبات من أنت، لكن دون أن تضطر في كل مرة إلى إظهار كل المعلومات". بعد أن تحصل على هذه الوثيقة، عندما تحتاج لاحقًا إلى إثبات مثلًا "أنني بلغت 18 عامًا" أو "لقد اجتزت أحد المتطلبات/عمليات المراجعة"، يمكنك استخدام هذه الوثيقة لإثبات ذلك مباشرةً، دون أن تقوم بتسليم صورة وجه وبظهر بطاقة الهوية مرة أخرى. يعتمد النظام على الإثباتات الصفرية المعرفة للتحقق من صلاحية الوثيقة، وليس على أن يرى الطرف الآخر بياناتك الأصلية.
أرى أن هذه الفكرة مدهشة ومُحِدِثة لتغيير كبير. منطق KYC التقليدي هو: "لا بد أن تجمع كل مؤسسة تثق بها معلوماتك من جديد"؛ كلما انتقلت المعلومات أكثر، ازدادت النسخ، وبالتالي يزداد خطر التسريب. نهج Citadel أقرب إلى: "التحقق من الهوية يتم مرة واحدة فقط، ثم تتم إعادة استخدام نفس الإثبات الموثوق مرارًا"؛ تقليل خطوة جمع المعلومات يعني تقليل خطر التسريب. وهذا مفيد جدًا في سياقات المؤسسات—تتضمن تداولات الأوراق المالية الكثير من مراحل الامتثال. إذا كان كل إطار يتطلب إعادة التحقق من الهوية، فهذا لا يسبب فقط تدني الكفاءة، بل يزيد أيضًا من مخاطر أمن المعلومات.
كنت سابقًا أركز فقط على الخصوصية في طبقة التداول، ولم يخطر ببالي أن طبقة التحقق من الهوية يمكن تصميمها بهذه الطريقة. ومن هذا المنظور، لم تكن هناك مناقشات كثيرة على المنصة.
هل سبق لك أن مررت بموقف طُلب منك فيه تقديم معلومات الهوية بشكل متكرر، وشعرت أنه مزعج جدًا؟