تَحَرّكْتُ طوال ليلةٍ في اختبار الشبكة، ولم أُدرك إلا حينها أنني لستُ “ألعب” محفظة، بل أُشغّل نظامَ محاسبةٍ بمستوى مالي. تصميم حسابين مزدوجَين للرقم #dusk ليس مجرّد فتح تبويبٍ إضافي للمستخدم؛ إنه إدخال بالقسر لمجموعتين مختلفتين تمامًا من “رؤى العالم” داخل السلسلة نفسها.
من جهةٍ هناك Moonlight: نموذج حسابي نموذجي، محاسبة مكشوفة وواضحة؛ مَنصّات التداول والجهات الرقابية مرتاحة له. ومن جهةٍ أخرى هناك Phoenix: UTXO مع إثباتات معرفة صفرية PLONK؛ في كل معاملة التزامٌ مُشفّر، ويتم دفن المبلغ وطرف المعاملة بالكامل داخل “ثقبٍ أسود” رياضي. ورغم أنهما يشتركان في طبقة توافقٍ واحدة، فإن آلة الحالة الأساسية مختلفة تمامًا كليهما عن الآخر. كنتُ أظن أن تبديل الأصول سيكون انسيابيًا مثل جسرٍ عبر السلاسل؛ لكن اتضح أنني أُجبر لغتين لا تتواصلان على القيام بترجمة بينهما—كل انتقال من Moonlight إلى Phoenix هو في جوهره عملية “إخفاء/تمويه”: يتطلب إنشاء إثباتات ZK معقدة محليًا، ولا يقوم المُتحقِّق إلا بالتصديق دون لمس البيانات. وبين هذا وذاك، تقفز تكاليف الحساب مباشرةً فتجعل رسوم الغاز ترتفع إلى ثلاثة أضعاف.
هذا النوع من البنية منطقي في سيناريوهات RWA: تحتاج المؤسسات إلى محاسبةٍ مكشوفة كي تُظهر للجهات الرقابية محافظها، وفي الوقت نفسه تحتاج إلى حوضٍ مظلم لحماية استراتيجيات التداول. لكن بالنسبة للمستخدم الفردي فهو كارثة. أنت لا تحتاج فقط إلى فهم ما هو UTXO، بل أيضًا لماذا يتعيّن انتظار تأكيد كتلتين عند تحويل الأموال، ولماذا لا يمكن لاستعمال تحويلاتٍ صغيرة أن يُغطي حتى رسوم الغاز. لا توجد في الوثائق الحالية حلول لمسارات المعالجة الدفعية؛ وهذا يعني أن المستخدم لا يملك إلا “ترجمة” كل معاملة على حدة، بتكلفة زمنية ومالية فاحشة.
لا تنخدع بمصطلح “الحسابين المزدوجين” اللطيف؛ فهذه في الحقيقة هي دفع تعقيد Layer2 قسرًا إلى طبقة التطبيق. وإذا تعذّر لاحقًا تجميع عدة عمليات في تسويةٍ ذرّية واحدة عبر الإثباتات التراجعية/التركيبية (recursive proofs)، فستبقى رؤية “التوافق مع اللوائح والخصوصية معًا” في النهاية مجرد لعبة باهظة التكاليف لا يقدر عليها إلا الكيانات الكبيرة، بينما يُحاصر الأفراد داخل Moonlight المكشوفين دون حماية. @Dusk $DUSK
من جهةٍ هناك Moonlight: نموذج حسابي نموذجي، محاسبة مكشوفة وواضحة؛ مَنصّات التداول والجهات الرقابية مرتاحة له. ومن جهةٍ أخرى هناك Phoenix: UTXO مع إثباتات معرفة صفرية PLONK؛ في كل معاملة التزامٌ مُشفّر، ويتم دفن المبلغ وطرف المعاملة بالكامل داخل “ثقبٍ أسود” رياضي. ورغم أنهما يشتركان في طبقة توافقٍ واحدة، فإن آلة الحالة الأساسية مختلفة تمامًا كليهما عن الآخر. كنتُ أظن أن تبديل الأصول سيكون انسيابيًا مثل جسرٍ عبر السلاسل؛ لكن اتضح أنني أُجبر لغتين لا تتواصلان على القيام بترجمة بينهما—كل انتقال من Moonlight إلى Phoenix هو في جوهره عملية “إخفاء/تمويه”: يتطلب إنشاء إثباتات ZK معقدة محليًا، ولا يقوم المُتحقِّق إلا بالتصديق دون لمس البيانات. وبين هذا وذاك، تقفز تكاليف الحساب مباشرةً فتجعل رسوم الغاز ترتفع إلى ثلاثة أضعاف.
هذا النوع من البنية منطقي في سيناريوهات RWA: تحتاج المؤسسات إلى محاسبةٍ مكشوفة كي تُظهر للجهات الرقابية محافظها، وفي الوقت نفسه تحتاج إلى حوضٍ مظلم لحماية استراتيجيات التداول. لكن بالنسبة للمستخدم الفردي فهو كارثة. أنت لا تحتاج فقط إلى فهم ما هو UTXO، بل أيضًا لماذا يتعيّن انتظار تأكيد كتلتين عند تحويل الأموال، ولماذا لا يمكن لاستعمال تحويلاتٍ صغيرة أن يُغطي حتى رسوم الغاز. لا توجد في الوثائق الحالية حلول لمسارات المعالجة الدفعية؛ وهذا يعني أن المستخدم لا يملك إلا “ترجمة” كل معاملة على حدة، بتكلفة زمنية ومالية فاحشة.
لا تنخدع بمصطلح “الحسابين المزدوجين” اللطيف؛ فهذه في الحقيقة هي دفع تعقيد Layer2 قسرًا إلى طبقة التطبيق. وإذا تعذّر لاحقًا تجميع عدة عمليات في تسويةٍ ذرّية واحدة عبر الإثباتات التراجعية/التركيبية (recursive proofs)، فستبقى رؤية “التوافق مع اللوائح والخصوصية معًا” في النهاية مجرد لعبة باهظة التكاليف لا يقدر عليها إلا الكيانات الكبيرة، بينما يُحاصر الأفراد داخل Moonlight المكشوفين دون حماية. @Dusk $DUSK