إليك سؤال لم أرَ له إجابة جيدة في أي مكان ضمن مجال RWA. إذا كانت الحيازات خاصة، فكيف يدفع المُصدر القسيمة؟
لا “يكتفي” السند بالجلوس في مكانه. كل نصف سنة يدفع. أحيانًا يتم استدعاؤه مبكرًا، وأحيانًا تُعدَّل الشروط، وأحيانًا يكون هناك تصويت. في الأسواق التقليدية هذا عمل روتيني للبنية التحتية. يعرف نظام الإيداع المركزي (CSD) سجلّ المالكين في تاريخ السجل، ثم تتدفق المدفوعات عبر سلسلة الحيازة، فيحصل الجميع على حصته.
الآن اعزل الحيازات. لم يعد المُصدر يعرف من يملك ماذا أو بكم. البنية التحتية التي جعلت مدفوعات القسائم مملة تحوّلت للتوقف.
هناك شكلان يمكن أن تتخذهما الإجابة، وهما ليسا متكافئين.
أحدهما أن العقد يوزّع على نحوٍ ذاتي. تُنفَّذ منطقية الدفع على أرصدةٍ مُشفّرة؛ فيتم اعتماد كل حامل بنسبةٍ معِينة (pro rata) دون أن يتعلم أحد تفاصيل التوزيع. هنا يتوقف التشفير المتجانس (HE) عن كونه مجرد مصطلح رائج، لأنك لا تستطيع حساب تقسيم pro rata على بيانات لا يُسمح لك بقراءتها باستخدام إثباتات المعرفة الصفرية (ZK) وحدها. يثبت ZK عبارةً ما، ويُجري HE عمليات حسابية على النصوص المشفّرة. أما الخدمة (servicing) فتحتاج إلى الحسابات.
والآخر أن يطالب الحاملوّن. في تاريخ السجل تُثبت السلسلة (commit) حالةً ما، وبعد ذلك تُثبت أنك كنت تملك مركزًا في ذلك البلوك دون كشف المركز نفسه. هذه أنظف تشفيريًا، لكنها تنقل العبء إلى المستثمر وتُدخل بهدوء إمكانية بقاء الاستحقاقات غير المُطالَبة هناك إلى الأبد.
الأول يحافظ على أن الأصل يتصرف كأداة (instrument). والثاني يجعله يتصرف كعملية إسقاط جوائز (airdrop).
@Dusk أي نموذج يفترضه المكدس للخدمة (servicing)، وهل يمكن إثبات حالة تاريخ السجل تاريخيًا أم فقط في رأس السلسلة الحالي؟ هذا الفرق يحدد ما إذا كان من الممكن للأصل المُعزَّز (shielded security) أن يدفع توزيعة/قسيمة أصلًا.
أنا في غاية الفضول لمعرفة ما إذا كان أي شخص هنا قد رأى سندًا مُرمّزًا يخدم قسيمة بالفعل على السلسلة (onchain)، وليس في ورقة بيضاء.
@Dusk $DUSK #dusk #RWA
لا “يكتفي” السند بالجلوس في مكانه. كل نصف سنة يدفع. أحيانًا يتم استدعاؤه مبكرًا، وأحيانًا تُعدَّل الشروط، وأحيانًا يكون هناك تصويت. في الأسواق التقليدية هذا عمل روتيني للبنية التحتية. يعرف نظام الإيداع المركزي (CSD) سجلّ المالكين في تاريخ السجل، ثم تتدفق المدفوعات عبر سلسلة الحيازة، فيحصل الجميع على حصته.
الآن اعزل الحيازات. لم يعد المُصدر يعرف من يملك ماذا أو بكم. البنية التحتية التي جعلت مدفوعات القسائم مملة تحوّلت للتوقف.
هناك شكلان يمكن أن تتخذهما الإجابة، وهما ليسا متكافئين.
أحدهما أن العقد يوزّع على نحوٍ ذاتي. تُنفَّذ منطقية الدفع على أرصدةٍ مُشفّرة؛ فيتم اعتماد كل حامل بنسبةٍ معِينة (pro rata) دون أن يتعلم أحد تفاصيل التوزيع. هنا يتوقف التشفير المتجانس (HE) عن كونه مجرد مصطلح رائج، لأنك لا تستطيع حساب تقسيم pro rata على بيانات لا يُسمح لك بقراءتها باستخدام إثباتات المعرفة الصفرية (ZK) وحدها. يثبت ZK عبارةً ما، ويُجري HE عمليات حسابية على النصوص المشفّرة. أما الخدمة (servicing) فتحتاج إلى الحسابات.
والآخر أن يطالب الحاملوّن. في تاريخ السجل تُثبت السلسلة (commit) حالةً ما، وبعد ذلك تُثبت أنك كنت تملك مركزًا في ذلك البلوك دون كشف المركز نفسه. هذه أنظف تشفيريًا، لكنها تنقل العبء إلى المستثمر وتُدخل بهدوء إمكانية بقاء الاستحقاقات غير المُطالَبة هناك إلى الأبد.
الأول يحافظ على أن الأصل يتصرف كأداة (instrument). والثاني يجعله يتصرف كعملية إسقاط جوائز (airdrop).
@Dusk أي نموذج يفترضه المكدس للخدمة (servicing)، وهل يمكن إثبات حالة تاريخ السجل تاريخيًا أم فقط في رأس السلسلة الحالي؟ هذا الفرق يحدد ما إذا كان من الممكن للأصل المُعزَّز (shielded security) أن يدفع توزيعة/قسيمة أصلًا.
أنا في غاية الفضول لمعرفة ما إذا كان أي شخص هنا قد رأى سندًا مُرمّزًا يخدم قسيمة بالفعل على السلسلة (onchain)، وليس في ورقة بيضاء.
@Dusk $DUSK #dusk #RWA
