كنت أقرأ في TermMax، وأول شيء لم يخطر ببالي في البداية هو تاريخ الاستحقاق.
عندما ترى “سعرًا ثابتًا”، من السهل أن تركز على الرقم. كانت هذه أيضًا أول ردة فعل لدي: هل السعر جيد أم سيئ مقارنةً بما يمكنني الحصول عليه في مكان آخر؟
لكن في سوق الأجل الثابت، فإن التاريخ المرتبط بهذا السعر مهم بقدر أهمية الرقم نفسه.
يبدو هذا مختلفًا تمامًا عن تجربة الإقراض المعتادة في DeFi. في الأسواق ذات السعر المتغير، تعودت على إيداع الأموال ثم اتخاذ القرار لاحقًا بشأن متى أريد نقلها. يتغير السعر، لكن ليس دائمًا هناك تاريخ محدد حاضر في ذهني.
يقلب TermMax هذه الفكرة قليلًا. قد يكون السعر أكثر قابلية للتنبؤ، لكن عليك أن تفكر مسبقًا في المدة التي تريد فيها فعليًا الاحتفاظ بالصفقة.
أفهم لماذا يعمل النظام بهذه الطريقة. إن تحديد آجال الاستحقاق هو جزء من جعل الاقتراض والإقراض بسعر ثابت ممكنًا، وبالنسبة لشخص يعرف بالفعل نطاقه الزمني، يمكن أن تكون هذه القابلية للتنبؤ مفيدة حقًا.
ومع ذلك، أعتقد أن هذا شيء قد يتجاوزه بسهولة المستخدمون الجدد. وجود معدل ثابت يبدو جيدًا لا يعني تلقائيًا أن الصفقة تلائم ما تحتاجه. قد يكون تاريخ الاستحقاق هو الجزء الأكثر أهمية في اتخاذ القرار.
بعد قضاء بعض الوقت في النظر إلى الأمر، وجدت نفسي أتحقق من التواريخ قبل مقارنة الأسعار.
أتساءل: هل يفعل الآخرون الذين يستخدمون DeFi بسعر ثابت الشيء نفسه؟ أم أن APY ما زال هو أول شيء تنظر إليه.
كنت أقرأ عبر وثائق Dusk ووجدت شيئًا جعلني أنظر إلى إعدادات الخصوصية بطريقة مختلفة قليلًا.
كنت أظن في الأصل أن الخصوصية في Dusk تعمل مثل مفتاح بسيط: المعاملات إما تكون خاصة أو لا تكون. لكن الأمر ليس كذلك حقًا.
تحتوي Dusk على Moonlight وPhoenix، وكلاهما يخدم أغراضًا مختلفة جدًا. Moonlight أقرب إلى ما اعتدنا عليه في سلاسل عامة، حيث تكون الأرصدة وتفاصيل المعاملات مرئية. تستخدم Phoenix ملاحظات مُشفّرة وإثباتات معرفة-صفرية، بحيث يمكن التحقق من المعاملة دون وضع جميع تفاصيلها في العلن.
الجزء الذي وجدته أكثر إثارة للاهتمام كان مفاتيح العرض.
يمكن لمعاملة على Phoenix أن تبقى خاصة عن العامة بينما لا يزال بإمكان المستخدم منح أطراف محددة وصولًا إلى معلومات معينة. قد يبدو هذا تفصيلًا صغيرًا، لكنه منطقي جدًا بالنسبة للتطبيقات المالية. فالخصوصية مفيدة، لكن الشركات قد لا تزال بحاجة إلى إظهار السجلات للمُدققين أو لأطراف أخرى مخوّلة.
لكن توجد سلبيّة أيضًا.
وجود نموذجين للمعاملات يعني أن المستخدمين يحتاجون فعلًا إلى معرفة أيهما يستخدمون. قد يسمع شخص ما عبارة “Dusk تركز على الخصوصية” ويظن أن كل معاملة تمتلك تلقائيًا المستوى نفسه من الخصوصية. هذا غير صحيح.
في الواقع، أفضل التفكير في Dusk بهذا الشكل: الأمر ليس بقدر إخفاء كل شيء، بل بقدر التحكم في ما يصبح علنيًا وما لا يصبح.
أنا متشوق لمعرفة ما إذا كانت هذه الخصوصية الانتقائية ستكون أسهل بالنسبة للمؤسسات المالية الواقعية للتعامل معها مقارنةً بأنظمة تكون خاصة-بشكل-افتراضي بالكامل.
ما لفت انتباهي أثناء قراءتي لوثائق Dusk هو شيء بسيط إلى حد ما: خصوصية الشبكة ليست مجرد مفتاح تشغيل/إيقاف.
يمتلك Dusk معاملات Moonlight وPhoenix. تكون Moonlight شفافة، بينما صُممت Phoenix لتحويلات مُحمّاة (مشفّاة) بحيث يمكن أن تبقى تفاصيل مثل المُرسِل والمُستلم والمبلغ خاصة.
قد يبدو ذلك كاختلاف تقني صغير، لكنني أعتقد أنه مهم جدًا لطريقة فهم الناس للشبكة.
عندما تسمع «بلوكشين خصوصية»، فمن السهل افتراض أن كل ما تقوم به يكون مخفيًا تلقائيًا. مع Dusk، هذا ليس بالضرورة هو الحال. مستوى الخصوصية يعتمد على نوع المعاملة أو التطبيق الذي تستخدمه فعليًا.
أفهم لماذا صمموه بهذه الطريقة. غالبًا ما تحتاج التطبيقات المالية إلى مرونة أكبر من مجرد إخفاء الهوية بالكامل. قد يكون من الضروري أن تبقى بعض الأنشطة عامة، بينما يجب أن تظل معلومات أخرى سرّية أو لا تظهر إلا لأطراف معيّنة.
الجزء الذي قد يصبح مربكًا هو تجربة المستخدم. لن يفكر معظم الناس في نماذج الحسابات أو UTXOs المُحمّاة قبل إجراء معاملة. سيكتفون غالبًا بتوقع أن يجعل التطبيق الأمر واضحًا: ما الذي هو خاص وما الذي ليس كذلك.
بالنسبة لي، هذه هي النقطة الأكثر إثارة للاهتمام في نهج Dusk. يمكن للتقنية أن تدعم مستويات مختلفة من درجة الإظهار، لكن الاختبار الحقيقي سيكون ما إذا كان المستخدمون قادرين على فهم تلك الخيارات دون الحاجة إلى قراءة التوثيق أولًا.
هل تتساءلون إن كانت الخصوصية الانتقائية ستصبح أكثر عملية من جعل كل شيء خاصًا افتراضيًا.
كنت أقرأ وثائق Dusk ولاحظت تفصيلة صغيرة علقت في ذهني: إن استخدام شبكة تركز على الخصوصية لا يعني بالضرورة أن كل ما تفعله سيكون خاصًا.
لدى Dusk نموذجين مختلفين للمعاملات. Moonlight هي العامة، بينما Phoenix هي الجهة المُشفّرة. يبدو هذا كاختلاف تقني، لكنني أعتقد أنه يغيّر طريقة تفكير المستخدمين في الشبكة.
كان افتراضي الأول أن الخصوصية ستكون هي الإعداد الافتراضي في كل مكان. بدلًا من ذلك، يبدو أن Dusk يعامل الخصوصية كخيار يعتمد على ما تفعله. بالنسبة للتطبيقات المالية، يمكنني فهم المنطق. ليست كل المعاملات بحاجة إلى الإخفاء، وأحيانًا يلزم أن تكون بعض المعلومات مرئية لأغراض مثل التدقيق أو الامتثال. يمكن لـ Phoenix الحفاظ على تفاصيل المعاملات خاصة مع السماح بالإفصاح الانتقائي عبر مفاتيح العرض.
لكن ما لست متأكدًا منه هو مدى وضوح ذلك للمستخدمين العاديين.
غالبًا لن يقضي معظم الناس وقتًا في تعلم الفرق بين نماذج المعاملات قبل استخدام تطبيق. إذا رأوا عبارة “بلوكشين للخصوصية”، فقد يفترضون تلقائيًا أن نشاطهم خاص. وهذا يجعل تصميم الواجهة مهمًا جدًا. يجب أن يتمكن المستخدمون من معرفة ما هو عام وما هو مُشفّر دون التعمّق في الوثائق.
لا أعتقد أن وجود نموذجين ليس بالضرورة نقطة ضعف. في التطبيقات المالية، قد تكون هذه المرونة مفيدة بالفعل. لكن هذا يجعل نهج Dusk في الخصوصية أكثر تعقيدًا قليلًا مما يوحي به الوصف.
أتساءل كيف سيشعر المستخدمون بذلك في الواقع بمجرد أن تبدأ المزيد من التطبيقات باستخدام النموذجين. هل سيثمّن المستخدمون وجود خيار، أم يفضلون أن تحدث الخصوصية تلقائيًا في الخلفية؟
كنت أراجع توثيقات Dusk وتفصيلة صغيرة واحدة غيّرت طريقة تفكيري بالكامل في وصف «سلسلة بلوكشين الخصوصية».
الخصوصية ليست مجرد ميزة يتم تفعيلها لكل شيء.
لدى Dusk نموذجـان للمعاملات يتصرفان بشكل مختلف تمامًا. Moonlight أقرب إلى ما اعتدنا عليه أغلبنا في السلاسل العامة، حيث يمكن رؤية الأرصدة والنشاط. أما Phoenix فيسلك الطريق الخاص؛ إذ يستخدم ملاحظات مُشفّرة وإثباتات معرفة-صفرية لإخفاء تفاصيل المعاملات.
في البداية تساءلت لماذا لا يجعلون Phoenix هو التجربة الافتراضية في كل مكان. لكن كلما فكرت أكثر في التطبيقات المالية، بدا أن هذا الانقسام صار منطقيًا أكثر.
على سبيل المثال، قد ترغب بورصة في معاملات يسهل تتبعها والتوفيق بينها. أما الشخص الذي ينقل أصولًا فقد تكون لديه توقعات مختلفة تمامًا ويفضّل السرية. إن إجبار كلا النوعين من المستخدمين على نموذج واحد قد يخلق مشكلات خاصة به.
الجزء الذي أظن أنه قد يربك الناس هو صياغة الحديث عن الخصوصية. قد يسمع أحدهم «بلوكشين يركز على الخصوصية» ويستنتج تلقائيًا أن أي شيء يفعله هناك سيكون خاصًا. على Dusk، ما زلت بحاجة إلى فهم نموذج المعاملة الذي تستخدمه.
وهذا يجعل تصميم المحافظ مهمًا جدًا. إذا كانت التطبيقات تشرح الفرق بوضوح، فقد تبدو الخيارات المزدوجة مفيدة. أما إذا لم تفعل، فقد يتعلم الناس الفرق فقط بعد افتراض أن المعاملة كانت أكثر خصوصية مما كانت عليه فعليًا.
ما زلت أحسم موقفي من هذا المقايضة. هل ينبغي للمستخدمين أن يتحكموا بنشاط في اختيار الشفافية أم الخصوصية، أم ينبغي للمحافظ أن تتولى هذه القرارات إلى حد كبير نيابةً عنهم?
أمر واحد لم أفهمه بالكامل عن Dusk إلا بعد أن قضيت بعض الوقت في قراءة الوثائق، وهو أن “الخصوصية” لا تعني أن كل معاملة على الشبكة تكون خاصة.
في الواقع، لدى Dusk نماذج معاملات مختلفة. فـ Phoenix مصمّم للتحويلات السرّية باستخدام ملاحظات مُشفّرة وإثباتات معرفة-صفرية، بينما يعمل Moonlight بطريقة أقرب إلى نموذج حساب شفاف تقليدي.
وقد لفتتني هذه النقطة على حين غرة في البداية.
إذا سمع أحدهم عبارة “بلوكشين للخصوصية”، فأظن أن الافتراض الطبيعي هو أن نشاطك يكون مخفيًا افتراضيًا. لكن يبدو أن Dusk تتبع نهجًا أكثر عملية: أحيانًا تحتاج إلى السرية، وأحيانًا تكون الشفافية مفيدة أو حتى ضرورية.
بالنسبة للتطبيقات المالية، أفهم لماذا صمّموا ذلك بهذه الطريقة. فالخصوصية ليست دائمًا متعلقة بإخفاء كل شيء عن الجميع. قد ترغب شركة في إبقاء تفاصيل المعاملات بعيدًا عن العلن، مع قدرتها في الوقت نفسه على تقديم معلومات محددة عند وجود سبب مشروع للتدقيق أو الامتثال.
المقابل هو أن هذا يضع مسؤولية أكبر على تجربة المستخدم.
إذا كنتُ أجري معاملة، فلا ينبغي أن أحتاج إلى فهم التشفير الأساسي، لكن من الأفضل أن أعرف ما إذا كنتُ أستخدم Phoenix أو Moonlight وأن أفهم ما الذي يعنيه ذلك بالنسبة للمعلومات التي أُظهرها. إذا لم تُوضّح المحافظ والتطبيقات ذلك بوضوح، فقد تؤدي كلمة “خصوصي” بسهولة إلى خلق توقع خاطئ لدى الناس.
بعد قراءة المزيد عن ذلك، أرى أن نهج Dusk أقل اهتمامًا بجعل كل شيء غير مرئي تمامًا وأكثر تركيزًا على تحديد مكان التي تكون فيها السرية منطقية فعلًا.
هذا يبدو أقرب إلى كيفية عمل الأنظمة المالية الواقعية، لكنني ما زلت أتساءل عمّا إذا كانت وجود نماذج متعددة للخصوصية سيجعل الأمور أوضح للمستخدمين أم سيضيف شيئًا آخر يحتاجون إلى فهمه.
$ETH يظهر زخمًا قويًا حول منطقة 1,926 دولار. يظل المشترون في السيطرة بينما يستمر الهيكل في الحفاظ على ثباته.
السعر المستهدف (EP) 1,918 - 1,926
الأهداف (TP) 1,943 1,960 1,980
وقف الخسارة (SL) 1,898
تتراكم السيولة فوق القمم الأخيرة، بينما يستمر السعر في إظهار رد فعل قوي من منطقة الدعم. الحفاظ على هذا الهيكل يبقي الإعداد الصعودي سليمًا ويفتح الباب أمام التوسع باتجاه مناطق السيولة التالية.
$ETH يُظهر زخمًا قويًا حول $1,923. لا يزال المشترون في السيطرة بينما تواصل بنية الإطار الزمني 4H الحفاظ على قمة أعلى.
EP $1,915 - $1,925
TP $1,943 $1,965 $2,000
SL $1,898
يتم بناء السيولة فوق القمة الأخيرة عند $1,943. قد يؤدي رد فعل واضح من منطقة الدخول إلى الحفاظ على الهيكل الصاعد وفتح الباب لموجة أخرى باتجاه سيولة أعلى.
لا يزال المشترون في السيطرة مع استمرار بقاء البنية الصعودية.
EP 1910–1920
TP TP1: 1943 TP2: 1975 TP3: 2000
SL 1890
تم أخذ السيولة فوق القمم الأخيرة، ويُظهر السعر رد فعل إيجابي بعد استعادة المستويات الرئيسية. طالما أن البنية الحالية ما زالت سليمة، يحتفظ المشترون بالأفضلية مع مجال للاستمرار نحو مقاومات أعلى.
لا يزال المشترون في السيطرة حيث يستمر الهيكل الصعودي في الحفاظ على نفسه.
EP 1910–1920
TP TP1: 1943 TP2: 1975 TP3: 2000
SL 1890
تم أخذ السيولة فوق القمم الأخيرة، ويجري السعر تفاعلًا إيجابيًا بعد استعادة المستويات الرئيسية. طالما أن البنية الحالية ما تزال سليمة، يحتفظ المشترون بالأفضلية مع مجال للمتابعة باتجاه مقاومات أعلى.
السيوويسية العالية فوقٍ القيمة الإخيرة هي الهدف الرئيسي. الاستمرار فوقٍ الدعم يبقى يحافظ المشترين بسيطرة، والبنية الحالية يستمر في التفويذ للتوسع المزيد بعد الانفتاح.
قضيت بعض الوقت في قراءة وثائق بابل ثم قارنتها ببعض المناقشات الأخيرة من المجتمع. شيء كنت ألاحظه باستمرار هو أن الناس كثيرًا ما يصفون ذلك بأنه "الاستيثاق عبر بيتكوين"، لكن هذا التعبير قد يعطي انطباعًا أوليًا غير صحيح.
في البداية، افترضت أن التجربة ستكون مشابهة لاستيثاق سلسلة PoS نموذجية. لكن بعد أن قرأت أكثر قليلًا، أدركت أن هذا ليس بالضبط ما تحاول بابل بناؤه. يبدو أن البروتوكول يركز أكثر على الحفاظ على بيتكوين كما هي، بدلًا من جعلها تتصرف مثل الأصول على شبكات أخرى.
غيّر ذلك طريقتي في النظر إلى المشروع. بدلًا من السؤال: "هل يحتوي هذا على كل المرونة التي اعتدت عليها؟" بدأت أسأل: "لماذا تم اتخاذ اختيارات التصميم هذه أصلًا؟" وعندما تفكر في الأمر من منظور بيتكوين، تصبح بعض المفاضلات أسهل للفهم، حتى لو لم تكن هي ما يريده كل مستخدم.
يمكنني أيضًا فهم سبب حدوث هذا الالتباس. لقد درّبتنا صناعة الكريبتو على توقع أن يعمل الاستيثاق بطريقة معينة، لذلك من السهل نقل تلك التوقعات إلى بابل. ثم تقرأ الوثائق وتدرك أنها تحل مشكلة مختلفة تمامًا.
بالنسبة لي، هذا هو الجزء المثير للاهتمام. سواء أعجب أحدٌ بهذا التصميم أم لا، يصبح الأمر منطقيًا أكثر عندما تتوقف عن مقارنته بتجربة استيثاق PoS قياسية. إنها تحاول الحفاظ على مبادئ بيتكوين مع توسيع دورها، وهذا هدف مختلف جدًا.
ما زلت أتساءل كيف سيتفاعل المستخدمون الجدد عندما يتعلمون أكثر. هل سيبدأ الناس في النهاية اعتبار هذه المفاضلات نقطة قوة، أم أن التوقعات المرتبطة بكلمة "staking" ستواصل التسبب في الالتباس؟