كنت أقرأ وثائق Dusk اليوم، وتوقفني شيء ما. أغلب سلاسل الكتل تعطيك نموذجًا واحدًا للمعاملات. شفافة. كل شيء ظاهر. هذا كل شيء.
لكن Dusk يعطيك اثنين.
Moonlight لمسارات الحسابات العامة. Phoenix لتحويلات محمية سرّية. نفس الشبكة. نفس الإجماع. نفس طبقة التسوية. لكنك تختار وضع المعاملة الذي يناسبها.
فكرة بهذه البساطة، لكنها تغيّر كل شيء في طريقة بناء التطبيقات المالية. دفعة خزينـة تحتاج أن تكون موثقة؟ Moonlight. نقل مركز بين حساباتك أنت التي لا ينبغي أن يبثّ محفظتك؟ Phoenix. كلاهما على السلسلة نفسها، لا سلسلتان تتظاهر كل واحدة بأنها الأخرى.
ما شد انتباهي أكثر كان جزء التسوية. Succinct Attestation — بروتوكول الإجماع لدى Dusk — مبني على حتمية نهائية (deterministic finality). بمجرد اعتماد كتلة ما، تصبح نهائية. لا إعادة تنظيم تظهر للمستخدم. لا "انتظر ست تأكيدات لتكون في الأمان". بالنسبة للأسواق المالية، هذا أهم من السرعة. تحتاج أن تعرف أن التسوية قد تمت فعلًا.
أتفكر باستمرار في كيفية انسجام هذه الأجزاء معًا. نموذجـان للمعاملات للخصوصية عند الحاجة. حتمية نهائية لثقة أعلى في التسوية. تسليم مقابل دفع مدمج داخليًا، بحيث تتحرك الأصول والدفع معًا بشكل ذري (atomically). هذه ليست سلسلة عامة الغرض مع ميزات مالية ملحقة. بل تبدو كأنها بنية تحتية مالية يحدث لها أن تكون سلاسل كتل.
ما زلت أعمل على فهم ما الذي تعنيه عمليًا. هل يمكن للمؤسسات استخدام نموذجَي المعاملات في نفس سير العمل؟ وهل يعمل الإبلاغ التنظيمي بشكل مختلف بين Moonlight وPhoenix؟ تبدو هذه هي الأسئلة الصحيحة التي ينبغي طرحها.
هل كنت ستحتاج إلى وضعين للمعاملات داخل السلسلة نفسها، أم أن هذا تعقيد مضاف لمعظم المستخدمين؟
#dusk $DUSK @Dusk
لكن Dusk يعطيك اثنين.
Moonlight لمسارات الحسابات العامة. Phoenix لتحويلات محمية سرّية. نفس الشبكة. نفس الإجماع. نفس طبقة التسوية. لكنك تختار وضع المعاملة الذي يناسبها.
فكرة بهذه البساطة، لكنها تغيّر كل شيء في طريقة بناء التطبيقات المالية. دفعة خزينـة تحتاج أن تكون موثقة؟ Moonlight. نقل مركز بين حساباتك أنت التي لا ينبغي أن يبثّ محفظتك؟ Phoenix. كلاهما على السلسلة نفسها، لا سلسلتان تتظاهر كل واحدة بأنها الأخرى.
ما شد انتباهي أكثر كان جزء التسوية. Succinct Attestation — بروتوكول الإجماع لدى Dusk — مبني على حتمية نهائية (deterministic finality). بمجرد اعتماد كتلة ما، تصبح نهائية. لا إعادة تنظيم تظهر للمستخدم. لا "انتظر ست تأكيدات لتكون في الأمان". بالنسبة للأسواق المالية، هذا أهم من السرعة. تحتاج أن تعرف أن التسوية قد تمت فعلًا.
أتفكر باستمرار في كيفية انسجام هذه الأجزاء معًا. نموذجـان للمعاملات للخصوصية عند الحاجة. حتمية نهائية لثقة أعلى في التسوية. تسليم مقابل دفع مدمج داخليًا، بحيث تتحرك الأصول والدفع معًا بشكل ذري (atomically). هذه ليست سلسلة عامة الغرض مع ميزات مالية ملحقة. بل تبدو كأنها بنية تحتية مالية يحدث لها أن تكون سلاسل كتل.
ما زلت أعمل على فهم ما الذي تعنيه عمليًا. هل يمكن للمؤسسات استخدام نموذجَي المعاملات في نفس سير العمل؟ وهل يعمل الإبلاغ التنظيمي بشكل مختلف بين Moonlight وPhoenix؟ تبدو هذه هي الأسئلة الصحيحة التي ينبغي طرحها.
هل كنت ستحتاج إلى وضعين للمعاملات داخل السلسلة نفسها، أم أن هذا تعقيد مضاف لمعظم المستخدمين؟
#dusk $DUSK @Dusk