ما وجدته مثيرًا للاهتمام في فاينيكس هو أنها تحاول أيضًا جعل المعاملات أصعب في الربط بينها.
تستخدم فاينيكس ملاحظات مخزّنة داخل شجرة ميركل. كل ملاحظة لديها مفتاحها العام الخاص بالملاحظة.
بدلًا من استخدام نفس المفتاح العام مرارًا وتكرارًا، تنشئ فاينيكس مفتاحًا عامًا للملاحظة يُستخدم مرة واحدة لكل ملاحظة.
لفت ذلك انتباهي لأن إعادة استخدام نفس المُعرّف قد تجعل من السهل ربط معاملات مختلفة بالمستخدم نفسه.$GRASS
يقول الورقة البحثية (الوايت بابر) إن هذا المفتاح المُستخدم مرة واحدة مُصمَّم لتوفير عدم القابلية للربط بين المعاملات.$UAI
هناك جزء آخر وجدته مثيرًا للاهتمام.
يمكن للمستلم استخدام مفتاح عرض للتحقق مما إذا كانت الملاحظة تخصه، بينما لا يمكن اشتقاق مفتاحه السري المطلوب لإنفاق تلك الملاحظة إلا باستخدام مفتاحه السري الكامل.
لذا فإن فكرة الخصوصية هنا ليست مجرد إخفاء كل شيء.
بل هي بالأحرى التحكم فيما يمكن ربطه علنًا.
لهذا جعلني ذلك أنظر إلى فاينيكس بشكل مختلف.
المعاملة الخاصة شيء.
والجعل أصعب على شخص ما أن ينظر إلى عدة معاملات ويربطها معًا شيء آخر.
إرسال كل رسالة بلوك تشين إلى الجميع يبدو آمنًا. كما يبدو أيضًا مهدِرًا بشكلٍ لا يصدق.
وهذا ما جعل Kadcast مثيرًا للاهتمام عندما راجعت ورقة Dusk البيضاء.
يستخدم Dusk Kadcast لبث كتل المعاملات وأصوات التوافق. بدلًا من مجرد فيضان كل عقدة مجاورة بنفس الرسالة، ينظّم Kadcast العقد باستخدام أفكار من Kademlia.
تحافظ كل عقدة على معلومات التوجيه مُجمّعة في سِلال بناءً على المسافة XOR بين معرّفات العقد.
ثم تصبح عملية الانتشار أكثر انتقائية.
تقوم العقدة بإعادة توجيه رسالة إلى أقران مختارين عند مسافات XOR متزايدة. تُكمل تلك الأقران العملية، لتنشئ سلسلة مُنظّمة عبر الشبكة.
يستخدم Kadcast أيضًا أشجار البثّ المتعدد. تبدأ الرسالة مع أقران قريبين، ثم يمررونها إلى العقد الأبعد في الشبكة. يتيح ذلك للشبكة تغطية عقدها عبر عدد أقل من المرحّلات بدلًا من إرسال نفس المعلومات بشكل متكرر عبر مسارات غير ضرورية.$TUT
هذا التمييز لفت انتباهي لأن شبكات البلوك تشين قد تصبح مكلفة عندما تواصل كل عقدة إعادة توجيه كل شيء إلى كل جار.
ليس الهدف مجرد جعل الرسائل تنتقل بسرعة.
الهدف هو تقليل عمليات الإرسال المتكررة مع الحفاظ على انتشار موثوق وفي الوقت المناسب.
أعجبني ذلك لأنه يُظهر أن أداء بلوك تشين لا يتعلق فقط بالتوافق أو إنتاج الكتل.$PUMP
يجب أيضًا على الشبكة نقل المعلومات بكفاءة.
أحيانًا يكون التصميم الأذكى هو عدم إرسال المزيد من الرسائل.
السوق يجلب أسماءً مثيرة للاهتمام مرة أخرى. $TRUMP $BEAT كلاهما يحظيان باهتمام كبير على المخطط. في هذه المرحلة، أحاول فقط فهم كيف يجد الجميع هذه التحركات قبل أن أفعل أنا.
كنت أظن أن استدعاء عقد ذكي فاشل يعني في الأساس مجرد خطأ.
لكن كلما نظرت إلى DuskVM أكثر، أصبحت مسألة مسار الفشل أكثر إثارة للاهتمام.
قبل بدء التنفيذ، يتحقق Dusk من أشياء مثل توقيع رصيد المُرسِل والـ nonce. إذا فشلت هذه الشروط الأساسية، فإن المعاملة لا تصل إلى التنفيذ بشكل طبيعي.
لكن ماذا يحدث عندما يحدث خطأ أثناء التنفيذ؟
هذه هي الجزء الذي أراه أكثر أهمية.
يمكن لعقد ذكي أن يُجري تغييرات في الحالة أثناء التشغيل، لكن الاستدعاء الفاشل لا يترك تلك التغييرات ببساطة موجودة هناك. تغييرات الحالة الناتجة عن هذا التنفيذ الفاشل لا يتم اعتمادها (commit).
لذلك لا ينتهي بك الأمر إلى عقد عالق في منتصف الطريق بين حالته القديمة وحالة جديدة غير مكتملة.
تدخل هنا أيضًا مسألة الغاز (Gas). يستهلك تنفيذ العقد الغاز، ما يعني أن الفشل ليس فقط متعلقًا بما إذا كانت النتيجة النهائية ناجحة. ما زالت هناك موارد تنفيذ تُستهلك في الطريق.
جعلني ذلك أعيد التفكير فيما يعنيه التنفيذ الآمن بالفعل.
ليس الأمر فقط في ضمان عمل المعاملات الناجحة.
بل أيضًا في توفير سلوك يمكن التنبؤ به عندما يفشل التنفيذ.
بالنسبة للتطبيقات المالية، تبرز أهمية هذا التمييز. فالنظام الذي يتعامل مع أصول ذات قيمة يحتاج إلى معرفة ما الذي يحدث عندما ينكسر المسار المتوقع.
أحيانًا لا تكون أهم نقطة في العقد الذكي هي ما يحدث عندما تسير الأمور على ما يرام.
السوق يعرف حقًا كيف يجعلك تُلقي نظرة ثانية. $PEOPLE $ENA
وفي كلتا الحالتين، يظهر بعض القوة الجادة على الرسم البياني.
بدأت أشكّ أن المهارة الحقيقية ليست في إيجاد المتحركين، بل في إيجادهم قبل أن يتحرّكوا.
كنت أعتقد أن البناء مباشرةً فوق البيئة الأصلية لسلسلة بلوكتشين يكون الخيار الأفضل تلقائيًا.
ثم نظرت عن قرب إلى DuskVM.
تمنح DuskVM المطورين وصولًا مباشرًا إلى بيئة الطبقة الأولى (Layer 1) الخاصة بـ Dusk. يمكن للعقود الذكية استخدام بدائيات مخصصة لـ Dusk والتفاعل عن كثب مع قدرات الشبكة الأصلية.
يبدو ذلك كميزة بديهية… إلى أن تنظر إلى الجانب الآخر.
إن البناء مباشرةً على Dusk يعني أيضًا العمل مع أدوات مصممة خصيصًا لـ DuskVM. قد يكون المطورون القادmon من منظومات راسخة بالفعل مرتاحين مع لغات وإطارات وأطر عمل التطوير المألوفة.
لذلك توجد مفاضلة حقيقية.
تحصل على وصول أقرب إلى الـ L1، لكنك تبتعد أكثر عن أدوات التطوير التي تعرفها بالفعل.
جعلني ذلك أعيد التفكير في DuskVM بشكل مختلف.
السؤال ليس فقط ما إذا كانت بيئة التنفيذ الأصلية لدى Dusk قوية.
بل ما إذا كان الوصول إلى بدائيات Dusk الخاصة ذا قيمة كافية للمطورين كي يقبلوا تجربة تطوير أكثر تخصصًا.
بالنسبة للتطبيقات التي تحتاج قدرات مرتبطة ارتباطًا وثيقًا بمعمارية Dusk، قد تكون هذه المفاضلة منطقية.
لكن بالنسبة للمطورين الذين يريدون في المقام الأول أدوات وأطر عمل مألوفة، فقد يكون منحنى التعلّم مهمًا بقدر أهمية التقنية نفسها.
البنية التحتية ليست فقط ما يمكن للمطورين بناؤه.
بل أيضًا ما الذي هم مستعدون لتعلّمه كي يتمكنوا من بنائه.
أعتقد أن هذا قد يكون نوع التداول المفضل لدي.$DOGE رافعة مالية 75x هامش $0.61 + ربح غير محقق $4.58
مجرد المخاطرة بهامش $0.61 ومشاهدة المركز يُظهر ربحًا قدره $4+ أمر مجنون.
وهذا بالضبط هو السبب وراء أن تداول الرافعة المالية يمكن أن يجعل قلبك يخفق بسرعة.
كلما تعمقت في TermMax زاد الأمر إثارةً للاهتمام من ناحية آلية تسعيرها.
قد يبدو أن السوق ذو السعر الثابت يجب أن يكون له سعر واحد.
لكن TermMax يتعامل مع التسعير بشكل مختلف عبر أوامر النطاق (Range Orders).
أمر النطاق هو أمر مستمر يُستخدم لتكوين منحنى تسعير الـ AMM. بدلًا من إجبار كل السيولة المتاحة على المرور عبر سعر واحد، يمكن أن يحتوي السوق على عدة أوامر نطاق، يغطّي كل منها جزءًا مختلفًا من المنحنى.
وهذا يعني أن السعر يمكن أن يتغير اعتمادًا على مكان استقرار السيولة.
تخيل الأمر أقل كأنه سعر ثابت واحد وأكثر كونه مسارًا يحتوي على مستويات تسعير مختلفة على طول الطريق.
المستخدم الذي يدخل السوق عند نقطة ما على المنحنى قد يواجه سعرًا مختلفًا عن شخص يدخل عند نقطة أخرى.
هذا يمنح مزوّدي السيولة مزيدًا من التحكم في كيفية تقديم رأس مالهم، بينما يمكن لمتداولي السيولة التفاعلية (market takers) التعامل مع أسعار مختلفة حسب نقطة دخولهم على المنحنى.
ما يلفت انتباهي هنا هو هذا.
السعر الثابت لا يعني أن كل جزء من السوق يمتلك سعرًا واحدًا مطابقًا.
تُمكّن أوامر النطاق TermMax من بناء منحنى تسعير تكون فيه أجزاء مختلفة من السيولة حاملة لأسعار مختلفة.
السوق يواصل ابتكار أسماء جديدة ليفاجئني. $BOME $RE
كلاهما يحظى بالكثير من الاهتمام على المخطط.
في هذه المرحلة، لم أعد أسأل أيهما سيتحرك بعد ذلك؛ أنا فقط أحاول رصده قبل أن يفعل ذلك الجميع.
كنت أعتقد أن إضافة EVM إلى سلسلة بلوك تشين كانت في المقام الأول بهدف تسهيل التطوير.
لكن عندما نظرت بعمق إلى Dusk بدأت أراها بشكل مختلف.
لدى Dusk بيئتان للتنفيذ: DuskVM و DuskEVM. ويبدو أنهما تحلان مشكلتين مختلفتين للمطورين.
DuskVM هي البيئة الأصلية. يمكن كتابة العقود الذكية بلغة Rust ثم تجميعها إلى WebAssembly، مما يمنح المطورين طريقة للبناء مباشرة داخل بنية Dusk على مستوى L1.
أما DuskEVM فيتبع نهجًا مختلفًا.
فهو يمنح المطورين القادمين من Ethereum بيئة أكثر مألوفة، مع دعم لـ Solidity وVyper، بالإضافة إلى أدوات EVM القائمة.
هذه التفرقة تهم أكثر مما كنت أظن في البداية.
المطور الذي يريد العمل بشكل وثيق مع البنية الأصلية لـ Dusk يمكنه استخدام DuskVM.
لكن شخصًا يعرف Solidity بالفعل وقد أمضى سنوات في استخدام أدوات تطوير Ethereum لا يريد بالضرورة تعلم بيئة مختلفة تمامًا فقط للبدء في التجربة مع Dusk.
لذلك لا أرى DuskVM و DuskEVM كأنهما يتنافسان مع بعضهما.
بل هما أقرب إلى نقطتي دخول إلى الشبكة نفسها.
إحداهما أصلية لـ Dusk.
والأخرى تجعل النظام البيئي أكثر سهولة بالنسبة للمطورين القادمين من عالم EVM.
الآن أصبحت أكثر فضولًا تجاه السؤال الأصعب.
هل يستطيع Dusk جذب كلا المجموعتين من المطورين دون أن تجعل بنية التنفيذ لديه تبدو مجزأة؟
وبطريقة ما، ما زلت أراقب من على الهامش كأنني لم أتعلم شيئًا من التحرك السابق.
ألاحظ باستمرار أن العائد الثابت غالبًا ما يُعامل كشيء تحتفظ به ببساطة حتى تاريخ الاستحقاق.
يجعل TermMax هذه الفكرة أكثر إثارة من خلال Tokens العائد الثابت (Fixed Rate Tokens) المسمّاة FTs.
الـ FT هو توكن ERC-20 مُصمم لتقديم عائد ثابت عند الاستحقاق. بدلًا من شراء الأصل الأساسي والانتظار فقط حتى تتراكم الفائدة، يمكن للدائن شراء FT بخصم عن قيمته الاسمية.
على سبيل المثال، تُظهر وثائق TermMax حالة بسيطة: FT قابل للاسترداد مقابل 110 USDC عند الاستحقاق يمكن شراؤه مقابل 100 USDC. إذا تم الاحتفاظ به حتى تاريخ الاستحقاق، فإن فرق 10 USDC يُمثل العائد.
والجزء المثير للاهتمام هو أن المركز لا يلزم بالضرورة أن يظل مُقفلًا حتى النهاية.
يمكن أيضًا تداول FTs في السوق.
وهذا يضيف طبقة أخرى من المرونة إلى التعرض بسعر ثابت. قيمة المركز ليست مرتبطة فقط بما سيُسترد لاحقًا من الـ FT نفسه؛ بل يمكن نقلها أو تداولها قبل تاريخ الاستحقاق.
لذلك تصبح الفكرة بسيطة جدًا.
اشترِ القيمة المستقبلية بخصم، ثم استرد عند القيمة الاسمية أو تداول المركز قبل تاريخ الاستحقاق.
وهذا يحوّل العائد الثابت إلى شيء أكثر ملموسًا وقابلًا للبناء داخل DeFi.
يمكن لبلوك تشين أن يبدو منظمًا تمامًا عندما يكون كل شيء يعمل. الجزء المثير للاهتمام هو ما يحدث عندما لا يعمل.
ما جذب انتباهي في Dusk هو أن الشبكة لا تفترض ببساطة أن كل بلوك سيصل في الوقت المحدد، أو أن كل موفّر خدمات سيكون دائمًا قابلاً للوصول.
يمكن للرسائل المتأخرة أو المفقودة أن تتسبب في أن تصل عدة بلوكات مرشحة إلى توافق في نفس الجولة، مما يخلق انقسامًا (fork). عادةً ما يحل إجراء Dusk الاحتياطي ذلك باختيار المرشح من أقل تكرار (iteration). وبالتالي يمكن التراجع عن بلوك بتكرار أعلى إذا تحقق توافق لاحقًا مع مرشح بتكرار أقل.
لكن هناك إجراء احتياطي أعمق.
إذا فشلت عدد كافٍ من التكرارات المتتالية بسبب أن الموفرين غير متصلين أو معزولين، يمكن لـ Dusk الدخول في وضع الطوارئ. يتم تعطيل مهلات الخطوة العادية، وتستمر التكرارات حتى يصل بلوك مرشح إلى النصاب (quorum). يمكن أن تعمل عدة تكرارات مفتوحة في الوقت نفسه، مما يزيد فرصة الوصول إلى توافق، رغم أن ذلك أيضًا يرفع احتمال حدوث انقسامات.
هذا جعلني أفكر في التوافق (consensus) بشكل مختلف.
الاختبار الحقيقي للشبكة ليس فقط مدى سلوكها عندما تسير الأمور على ما يرام.
بل ما يحدث عندما ينقطع التواصل.
بالنسبة للبنية التحتية المالية، قد يكون تحديد سلوك واضح لهذه الظروف المربكة مهمًا بقدر ما هو تحقيق توافق سريع في الظروف العادية.
أقسم أن العملات المشفرة لديها موهبة تجعلك تكتشف الحركة بعد أن تكون بدأت بالفعل.
الآن أنا أراقب عن كثب.
ألاحظ باستمرار مشكلة واحدة في التمويل اللامركزي (DeFi) يتم تجاهلها: يمكن أن تتغير الفائدة التي تقترض بها بينما لا تزال استراتيجيتك قيد التنفيذ.
معدلات الاقتراض والإقراض المتغيرة تتحرك مع ظروف السوق. هذا يخلق حالة من عدم اليقين. قد يواجه المقترض تكاليف سداد أعلى بينما يمكن أن تتغير العوائد المتوقعة للمقرض مع تحرك الفائدة.
كلاهما يمر بيوم جيد جدًا بينما أنا هنا أتساءل لماذا ألاحظ دائمًا هذه التحركات بعد حدوثها.
غالبًا ما توصف معاملة البلوك تشين بأنها إما مؤكدة أو غير مؤكدة. يجعل نموذج الإجماع لدى Dusk هذا الجواب أكثر دقة.
يمكن أن ينتقل البلوك عبر أربع حالات: accepted attested confirmed و final. تمثل كل مرحلة مستوى مختلفًا من الثقة بشأن ما إذا كان يمكن استبدال هذا البلوك لاحقًا.
البلوك accepted لديه attestation بالنجاح لكن ما زال يمكن استبداله ببلوك من iteration أدنى مع attestation بالنجاح أيضًا. أما البلوك attested فيمتلك attestation بالنجاح وقد فشلت جميع التكرارات السابقة، لذا لا يمكن استبداله ببلوك من iteration أدنى.
ثم يأتي confirmed. في هذه المرحلة يكون من غير المحتمل استبدال البلوك، على الرغم من أن أحد أجداده قد لا يزال قابلًا للاستبدال. وهذا يجعل confirmed مختلفًا عن final.
البلوك final يتقدم خطوة إضافية: فهو مؤكد، ووالده (parent) هو أيضًا final. وفقًا للوثائق، لا يمكن استبدال البلوك final تحت أي ظرف.
هذا التمييز سهل التغاضي عنه لأن confirmed و final غالبًا ما يُعاملان كشيء واحد. يوضح Dusk هذا التسلسل بشكل صريح.
بالنسبة للتطبيقات المالية، فإن معرفة اللحظة بالضبط التي يصبح فيها البلوك غير قابل للعكس ليست تفصيلًا صغيرًا. فقد يؤثر ذلك على توقيت اعتبار التسوية منتهية حقًا.
واحد يندفع للأعلى بينما الآخر يُسحق تمامًا. يمكن للـ”كريبتو“ أن يغيّر المزاج في ثوانٍ.
الهوية على سلسلة الكتل لا تعني دائمًا عرض كل التفاصيل الخاصة بالمستخدم للعلن.
ولهذا لفتت “Citadel” انتباهي عندما كنت أراجع توثيق “Dusk”. يصف “Glossary” “Citadel” بأنها طبقة هوية وإتاحة لدى “Dusk” مبنية حول الإفصاح الانتقائي.
الفكرة بسيطة، لكن الفرق مهم: إثبات من هو الشخص أو ما إذا كان لديه إمكانية وصول لا يعني تلقائيًا جعل كل جزء من معلومات الهوية مرئيًا للجميع.
في التطبيقات المالية قد يصبح ذلك مهمًا. قد تحتاج الشبكة إلى ضوابط هوية وإتاحة مع الحفاظ أيضًا على سرية المعلومات الحساسة. بدلًا من اعتبار الشفافية خيارًا “كلّه أو لا شيء”، يشير الإفصاح الانتقائي إلى نموذج رؤية أكثر تحكمًا.
ما أراه مثيرًا للاهتمام هو أن “Citadel” تجاور بنية الخصوصية الأوسع لدى “Dusk” بدلًا من استبدالها. كما يعرّف “Dusk” معيار “Confidential Security Contract Standard” كإطار يمكنه التكيّف مع متطلبات الأعمال مثل قيود الخصوصية وقواعد الامتثال.
هذا يجعل الهوية تبدو أقل كأنها صندوق KYC منفصل وأكثر كجزء من البنية التحتية.
السؤال الحقيقي بالنسبة لي هو: إلى أي مدى يمكن أن يصل الإفصاح الانتقائي مع الحفاظ على التطبيقات المالية خاصة وقابلة للاستخدام.
لا يعني الخصوصيّة على سلسلة الكتل بالضرورة أن كل معاملة تصبح غير مرئية للجميع، وأن هذا التمييز مهم للتطبيقات الماليّة.
تتناول Dusk الخصوصيّة عبر مستويات مختلفة من إمكانيّة الظهور. توفّر Moonlight تدفقات حسابات عامة شفّافة، بينما تدعم Phoenix عمليات تحويل مُشفّاة باستخدام إثباتات المعرفة الصفريّة. ومع Phoenix يمكن التحقّق من صحّة المعاملة دون الكشف علنًا عن المبلغ المحوَّل أو المُرسِل أو الملاحظات (الـnotes) المحدّدة المتعلّقة بها.
الجزء المثير للاهتمام هو ما يحدث عندما يحتاج شخص ما فعلًا إلى دليل. يصف توثيق Dusk الإفصاح الانتقائي كوسيلة للأطراف المصرّح لها مثل المُصدِرين أو الجهات/المنصّات أو المدقّقين أو المشرفين للوصول إلى المعلومات المطلوبة دون جعل بيانات غير ضروريّة متاحة للعامة. يمكن استخدام مفاتيح العرض (Viewing keys) عندما تتطلّب القواعد أو عمليات التدقيق إظهارًا مُتحكمًا.
وهذا يخلق فكرة مختلفة عن الشفافية. بدلًا من افتراض أن كل شيء يجب أن يكون عامًا كي تبقى سلسلة الكتل قابلة للتدقيق، تفصل Dusk بين الظهور العام والإفصاح المُتحكم به.
بالنسبة للأسواق المُنظَّمة، قد يهمّ هذا التمييز. قد لا يرغب المستثمر في أن تُعرَض كل الأرصدة أو التحويلات على كامل الشبكة، بينما قد لا يزال المدقق بحاجة إلى أدلة محدّدة للتحقق من معاملة أو عملية مالية.
لذلك فإن الهدف ليس فقط المعاملات الخاصّة. بل هو أكثر دقّة: الحفاظ على سرّية المعلومات الحساسة مع الإبقاء على مسار للتحقق المُصرّح به عندما يكون ذلك مطلوبًا فعلًا.
غالبًا ما تتطلب المعاملات العامة والخاصة نظمًا مختلفة، لكن الغسق يضع النموذجين في نفس الشبكة.
القمر هو نموذج المعاملات العامة للحساب الخاص بالغسق. تحدد المعاملة المُرسِل والمُستقبِل عبر مفاتيحهما العامة، بينما تساعد حقول مثل المبلغ nonce وحدّ الغاز وسعر الغاز والتوقيع الشبكة على التحقق منها ومعالجتها. كما يوفر هذا النموذج حماية مثل عدم القابلية للتزييف ومنع الإنفاق المزدوج وعدم القابلية للتلاعب ومنع هجمات إعادة التشغيل.
تتبع فونيكس نهجًا مختلفًا. فهو مبني على بنية UTXO المشابهة لبيتكوين، لكنه يضيف آليات الخصوصية. بدلًا من كشف أي ملاحظة (note) بعينها تم إنفاقها، تقوم الشبكة بتتبع nullifiers لمنع الإنفاق المزدوج دون تحديد علني للملاحظة الدقيقة داخل شجرة Merkle.
يوجد أيضًا اختلاف مهم في التحقق. تتضمن معاملات فونيكس برهانًا ذا معرفة معدومة (zero knowledge proof) يتيح للشبكة التحقق من أن المعاملة تتبع القواعد دون الاعتماد على نوع الفحوصات المباشرة نفسها المستخدمة بواسطة القمر.
لذا فالقمر وفونيكس ليسا نسختين متنافستين من الغسق. بل يقدمان نموذجين مختلفين للمعاملات وفقًا لمتطلبات الرؤية المختلفة.
غالبًا ما تبدو سلاسل الكتل العامة العامة والتمويل الخاضع للتنظيم وكأنهما تطلبان أشياء متعاكسة. فواحدة تُفضّل الشفافية المفتوحة بينما تحتاج الأخرى إلى قابلية التدقيق للسرية والامتثال.
تم تصميم Dusk لسد هذه الفجوة.
تصف الورقة البيضاء لـ Dusk بلوك تشين جاهزًا للامتثال ومركّزًا على الخصوصية، ومُصممًا لربط المنصات اللامركزية بالأسواق المالية التقليدية. بدلًا من التعامل مع الخصوصية والتنظيم كطبقات منفصلة، تُضمّن Dusk قابلية التدقيق للمعاملات السرّية والامتثال ضمن البنية الأساسية الخاصة بها.
يُعد نموذج المعاملات جزءًا مهمًا من هذا التصميم. تدعم Dusk Moonlight، وهو نموذجها العام المعتمد على الحسابات، إلى جانب Phoenix، وهو نموذجها المعتمد على UTXO المُشفّر. وهذا يمنح الشبكة طرقًا مختلفة للتعامل مع ظهور المعاملات وفقًا لحالة الاستخدام.
يهم ذلك للتطبيقات المالية لأن الخصوصية لا تعني بالضرورة اختفاء المعلومات. نهج Dusk أقرب إلى التحكم بما هو ظاهر ولمن هو ظاهر، مع الحفاظ على القدرة على تلبية متطلبات الأسواق الخاضعة للتنظيم.
بالنسبة لي، يجعل ذلك طرح Dusk أكثر إثارة للاهتمام من مجرد تسميته بلوك تشين للخصوصية. فهو يحاول أن يجعل الخصوصية والامتثال والبنية التحتية المالية تعمل معًا على مستوى البروتوكول.
هناك رمز يطير بينما آخر يتعرض لضربة كبيرة. هكذا هي العملات المشفرة. كنت أراقب الرسوم البيانية اليوم.
غالبًا ما يظن الناس أن سلسلتي بلوكشين تحتاجان إلى فهم بعضهما قبل أن تتمكنا من العمل معًا. كلما درستُ بنية Babylon أكثر، كلما أصبحت هذه الفرضية أقل إقناعًا.
لم يكن بيتكوين مُصممًا أصلًا لتفسير تنفيذ الإيثيريوم أو الاحتفاظ بنسخة من حالته. إن محاولة جعله يفعل ذلك ستغيّر المبادئ نفسها التي تجعل بيتكوين قابلًا للتنبؤ. بدلًا من ذلك، تتعامل Babylon مع المشكلة من اتجاه مختلف. فهي لا “تعلم” بيتكوين أن يفهم بلوكشين آخر، بل تمنح بيتكوين شيئًا يعرف بالفعل كيفية تقييمه: البرهان التشفيري. الهدف ليس فهمًا مشتركًا. بل تحقق مستقل.
غيّر هذا الفرق طريقتي في التفكير بشأن قابلية التشغيل البيني. لا يتعين على نظامين بالضرورة أن يتكلّما اللغة نفسها للوصول إلى النتيجة نفسها. كل ما يحتاجانه هو أدلة يمكن التحقق منها وفقًا لقواعد كلٍ منهما. وبهذا المعنى تصبح البراهين أقل شبهاً بالرسائل وأكثر شبهاً بشهود رياضيين لا يحتاج أي طرف إلى تفسيرها على أساس الثقة.
كلما انعكست على هذا التصميم، كلما ازددت قناعة بأن بنية تحتية للتشغيل البيني عبر السلاسل قد تكون كانت تطرح السؤال الخطأ. بدلًا من التساؤل عن كيفية فهم البلوكشين لبعضها، ربما ينبغي أن نسأل كيف يمكنها التحقق من الواقع نفسه مع البقاء مستقلّة تمامًا.
ربما لا ينتمي مستقبل قابلية التشغيل البيني إلى الشبكات التي تتواصل أكثر. قد ينتمي إلى الشبكات التي تحتاج إلى الثقة في التواصل بأقل قدر ممكن.