أعود باستمرار إلى رقم هيدجر الأكثر لفتًا للانتباه: "أقل من ثانيتين."
يقول Dusk Network إن دوائره خفيفة الوزن يمكنها توليد إثباتات على جانب العميل داخل المتصفح خلال ذلك الوقت. بالنسبة لمسار EVM سري، هذا أمر مهم. يجب ألا يضطر المستخدمون إلى إرسال مدخلات خاصة إلى مُثبت بعيد فقط لتحريك أصل.
لكن زمن إثبات واحد على جهاز واحد ليس مقياسًا لإنتاجية السوق.
يجمع Hedger بين التشفير المتماثل مع إثباتات المعرفة الصفرية حتى تظل الأرصدة والتحويلات المشفّرة قابلة للتحقق. أن يكتمل إثبات واحد بسرعة يبيّن أن التفاعل قد يبدو قابلاً للاستخدام. لكنه لا يخبرني كيف يتصرف النظام عبر أجهزة محمولة أضعف، أو متصفحات الهاتف، أو عدد كبير من الأصول، أو اندفاع من صفقات متزامنة.
هذه الفروقات مهمة لأن Hedger يعمل على testnet وتهدف إلى تطبيقات مالية خاضعة للرقابة. في سير العمل المؤسسي يوجد أكثر من إجراء تشفيري واحد. قد يشمل فحوصات الأهلية، وأمرًا، وتسوية، وإفصاحًا، وإعداد تقارير. قد تصبح الثانيتان المتكررتان عبر عدة خطوات احتكاكًا واضحًا.
سأختبر الادعاء كتوزيع، لا كمتوسط.
ما هو زمن الإثبات الوسيط؟ ماذا يحدث عند المئوي 95؟ كم مرة يؤدي ضغط الذاكرة إلى تعطل المتصفح؟ هل يمكن للمستخدم استئناف العملية بأمان، أم يجب إعادة بناء كامل المعاملة؟
يمكن توسيع سعة الخادم بواسطة مشغّل. ووقت الإثبات على العميل يرث كل جهاز يجلبه المستخدم. هذا ينقل مخاطر الأداء من مركز البيانات إلى الحافة.
الدليل الذي أريده من Dusk هو مصفوفة قياس أداء عامة، تليها معدلات إكمال حية على testnet تحت طلب متزامن. عرض سريع على جهاز مطور بداية مفيدة. يحتاج السوق الخاضع للرقابة إلى إكمال يمكن التنبؤ به على العتاد العادي.
سيشعر Hedger بأنه قابل للتوسع عندما لا يزال بإمكان أبطأ عميل معقول إكمال المسار الخاص، وليس عندما يجعل أسرع إثبات هو العنوان.
@Dusk $DUSK #dusk
$ACE $CYS
يقول Dusk Network إن دوائره خفيفة الوزن يمكنها توليد إثباتات على جانب العميل داخل المتصفح خلال ذلك الوقت. بالنسبة لمسار EVM سري، هذا أمر مهم. يجب ألا يضطر المستخدمون إلى إرسال مدخلات خاصة إلى مُثبت بعيد فقط لتحريك أصل.
لكن زمن إثبات واحد على جهاز واحد ليس مقياسًا لإنتاجية السوق.
يجمع Hedger بين التشفير المتماثل مع إثباتات المعرفة الصفرية حتى تظل الأرصدة والتحويلات المشفّرة قابلة للتحقق. أن يكتمل إثبات واحد بسرعة يبيّن أن التفاعل قد يبدو قابلاً للاستخدام. لكنه لا يخبرني كيف يتصرف النظام عبر أجهزة محمولة أضعف، أو متصفحات الهاتف، أو عدد كبير من الأصول، أو اندفاع من صفقات متزامنة.
هذه الفروقات مهمة لأن Hedger يعمل على testnet وتهدف إلى تطبيقات مالية خاضعة للرقابة. في سير العمل المؤسسي يوجد أكثر من إجراء تشفيري واحد. قد يشمل فحوصات الأهلية، وأمرًا، وتسوية، وإفصاحًا، وإعداد تقارير. قد تصبح الثانيتان المتكررتان عبر عدة خطوات احتكاكًا واضحًا.
سأختبر الادعاء كتوزيع، لا كمتوسط.
ما هو زمن الإثبات الوسيط؟ ماذا يحدث عند المئوي 95؟ كم مرة يؤدي ضغط الذاكرة إلى تعطل المتصفح؟ هل يمكن للمستخدم استئناف العملية بأمان، أم يجب إعادة بناء كامل المعاملة؟
يمكن توسيع سعة الخادم بواسطة مشغّل. ووقت الإثبات على العميل يرث كل جهاز يجلبه المستخدم. هذا ينقل مخاطر الأداء من مركز البيانات إلى الحافة.
الدليل الذي أريده من Dusk هو مصفوفة قياس أداء عامة، تليها معدلات إكمال حية على testnet تحت طلب متزامن. عرض سريع على جهاز مطور بداية مفيدة. يحتاج السوق الخاضع للرقابة إلى إكمال يمكن التنبؤ به على العتاد العادي.
سيشعر Hedger بأنه قابل للتوسع عندما لا يزال بإمكان أبطأ عميل معقول إكمال المسار الخاص، وليس عندما يجعل أسرع إثبات هو العنوان.
@Dusk $DUSK #dusk
$ACE $CYS