@Dusk #dusk
$DUSK مكونات أساسية
تستخدم شبكة Dusk معمارةً معيارية مصممة للتمويل الخاضع للرقابة: الخصوصية حيث يلزم، والشفافية حيث تكون مفيدة، والتسوية الحتمية حيث تتطلبها مسارات العمل في السوق. وعلى مستوىً عالٍ:
المكوّن :
1. DuskDS
الدور :
أساس التسوية وتوافر البيانات: توافق في الآراء (consensus)، الحتمية النهائية (finality)، ونماذج معاملات Dusk
إلى أين تذهب بعد ذلك :
لدى Dusk معمارية من طبقتين:
DuskDS – طبقة التسوية والبيانات (التوافق، توافر البيانات، نماذج المعاملات)
DuskEVM – طبقة تنفيذ EVM حيث تعمل العقود الذكية وحيث يقيم Hedger
تصف هذه الصفحة نماذج المعاملات على DuskDS. إنها خلفية للأشخاص الذين يريدون فهم كيفية عمل التسوية والخصوصية من تحت الغطاء. إذا كنت تقوم ببناء dApps على DuskEVM، فسوف تتعامل غالبًا مع Hedger وعقود EVM بدلاً من ذلك.
Phoenix مقابل Moonlight (على DuskDS)على DuskDS، يمكن أن تنتقل القيمة بطريقتين أصليتين:
Moonlight – عمليات تحويل عامة قائمة على الحسابات
Phoenix – تحويلات مُشفّاة قائمة على الملاحظات (notes) باستخدام إثباتات معرفة-صفرية
يتم في النهاية تسوية كلاهما على السلسلة نفسها، لكنهما يتيحان معلومات مختلفة للمراقبين.
للتفاصيل الكاملة حول التنفيذ يمكنك الرجوع إلى الورقة البيضاء (Whitepaper).
Moonlight – أرصدة عامة
Moonlight هو نموذج المعاملات الشفاف:
لدى الحسابات أرصدة مرئية.
تعرض عمليات التحويل المُرسل والمُستلم والمبلغ.
وهو مناسب للتدفقات التي يجب أن تكون قابلة للملاحظة (مثل بعض سيناريوهات الخزينة أو التقارير).
مفاهيميًا يتصرف مثل نموذج حساب قياسي.
بالنسبة لمعظم المستخدمين، هذا هو “الطريقة الشفافة فقط لتحريك DUSK” على مستوى البروتوكول.
Phoenix – أرصدة مُشفّاة
Phoenix هو النموذج الذي يحافظ على الخصوصية:
تعيش الأموال كـ “ملاحظات” مُشفّرة بدلًا من أرصدة صريحة.
تُثبت المعاملات صحة التنفيذ (لا توجد تحويلات مزدوجة، وجود أموال كافية) باستخدام إثباتات معرفة-صفرية دون الكشف عن:كم يتم نقله،من أرسل الملاحظة،باستثناء المُستلم،وبين أي ملاحظات محددة.
يمكن للمستخدمين كشف المعلومات بشكل انتقائي عبر مفاتيح العرض (viewing keys) عندما تتطلب اللوائح أو عمليات التدقيق ذلك.
$DUSK مكونات أساسية
تستخدم شبكة Dusk معمارةً معيارية مصممة للتمويل الخاضع للرقابة: الخصوصية حيث يلزم، والشفافية حيث تكون مفيدة، والتسوية الحتمية حيث تتطلبها مسارات العمل في السوق. وعلى مستوىً عالٍ:
المكوّن :
1. DuskDS
الدور :
أساس التسوية وتوافر البيانات: توافق في الآراء (consensus)، الحتمية النهائية (finality)، ونماذج معاملات Dusk
إلى أين تذهب بعد ذلك :
لدى Dusk معمارية من طبقتين:
DuskDS – طبقة التسوية والبيانات (التوافق، توافر البيانات، نماذج المعاملات)
DuskEVM – طبقة تنفيذ EVM حيث تعمل العقود الذكية وحيث يقيم Hedger
تصف هذه الصفحة نماذج المعاملات على DuskDS. إنها خلفية للأشخاص الذين يريدون فهم كيفية عمل التسوية والخصوصية من تحت الغطاء. إذا كنت تقوم ببناء dApps على DuskEVM، فسوف تتعامل غالبًا مع Hedger وعقود EVM بدلاً من ذلك.
Phoenix مقابل Moonlight (على DuskDS)على DuskDS، يمكن أن تنتقل القيمة بطريقتين أصليتين:
Moonlight – عمليات تحويل عامة قائمة على الحسابات
Phoenix – تحويلات مُشفّاة قائمة على الملاحظات (notes) باستخدام إثباتات معرفة-صفرية
يتم في النهاية تسوية كلاهما على السلسلة نفسها، لكنهما يتيحان معلومات مختلفة للمراقبين.
للتفاصيل الكاملة حول التنفيذ يمكنك الرجوع إلى الورقة البيضاء (Whitepaper).
Moonlight – أرصدة عامة
Moonlight هو نموذج المعاملات الشفاف:
لدى الحسابات أرصدة مرئية.
تعرض عمليات التحويل المُرسل والمُستلم والمبلغ.
وهو مناسب للتدفقات التي يجب أن تكون قابلة للملاحظة (مثل بعض سيناريوهات الخزينة أو التقارير).
مفاهيميًا يتصرف مثل نموذج حساب قياسي.
بالنسبة لمعظم المستخدمين، هذا هو “الطريقة الشفافة فقط لتحريك DUSK” على مستوى البروتوكول.
Phoenix – أرصدة مُشفّاة
Phoenix هو النموذج الذي يحافظ على الخصوصية:
تعيش الأموال كـ “ملاحظات” مُشفّرة بدلًا من أرصدة صريحة.
تُثبت المعاملات صحة التنفيذ (لا توجد تحويلات مزدوجة، وجود أموال كافية) باستخدام إثباتات معرفة-صفرية دون الكشف عن:كم يتم نقله،من أرسل الملاحظة،باستثناء المُستلم،وبين أي ملاحظات محددة.
يمكن للمستخدمين كشف المعلومات بشكل انتقائي عبر مفاتيح العرض (viewing keys) عندما تتطلب اللوائح أو عمليات التدقيق ذلك.
