لم أجد أبدًا أن TPS وحده مفيد جدًا عند تقييم سلسلة مثل DUSK.
يبدو مميزًا على مخطط.
ثم تصل الأحمال الحقيقية.
الخصوصية. توليد الإثباتات. تنفيذ العقود. نمو الحالة. عقد تحاول البقاء متزامنة.
هنا تصبح الأمور مثيرة للاهتمام.
يبدو أن DUSK تفهم ذلك أفضل من معظم الأنظمة.
بدلًا من جعل طبقة واحدة تقوم بكل شيء، يقوم الشبكة بتقسيم العمل.
DuskDS يتولى الإجماع والتسوية وتوفر البيانات.
DuskVM يتولى العقود الأصلية.
وDuskEVM يوفر بيئة تنفيذ مألوفة لتطبيقات مبنية على Solidity.
قد يبدو الأمر وكأنه حديث عن المعمارية.
لكن الأمر يهم لأن كل حمل عمل له طريقة مختلفة ليصبح بطيئًا.
وهناك جزء آخر هادئ: Kadcast.
بدلًا من التلويح بلا نهاية لتبادل أخبار الكتل عبر أقران عشوائيين، يستخدم شبكة منظمة لنشر البيانات. ازدواجية أقل في حركة المرور، وتسليم أكثر قابلية للتنبؤ.
قد لا يكون ذلك مادة جيدة لرسمة تسويقية لافتة.
لكن عندما يصبح أداء الشبكة مزدحمًا، تصبح سعة النطاق المهدورة واقعًا حقيقيًا.
ثم يأتي الجزء الذي يتجاوزه الناس عادةً:
تكاليف الخصوصية تُكلّف حسابات (Compute).
إثباتات المعرفة الصفرية هي عمل فعلي. يمكنك الحصول على إجماع سريع وما زلت تصطدم بجدار إذا أصبحت عملية الإثبات هي عنق الزجاجة.
لذلك لا أعتقد أن سؤال قابلية التوسع الحقيقية لدى DUSK هو:
«هل يمكنها معالجة عدد هائل من المعاملات؟»
بل هو:
ماذا يحدث عندما تصبح تلك المعاملات مكلفة؟
هل يمكن أن تبقى الحتمية/النهائية قابلة للتنبؤ؟
هل تستطيع العقد اللحاق؟
هل يمكن للمعاملات الخاصة أن تتعايش مع نشاط العقود الذكية العادي؟
هذا هو الاختبار الأصعب.
وبصراحة، قرارات الهندسة الصغيرة تُخبرني أكثر من الأرقام الكبيرة.
كيف تتحرك البيانات. كيف يتم الوصول إلى الحالة. كيف تتزامن العقد. كيف تُنتج الإثباتات. وكيف يتم فصل التنفيذ عن التسوية.
لا يبدو أي من ذلك مثيرًا.
لكن هذا عادةً المكان الذي تعيش فيه قابلية التوسع الحقيقية.
السلسلة المتينة ليست تلك التي تكون فيها كل مكوّناتها سريعة بشكل مبالغ فيه.
بل هي تلك التي تعرف فيها الأعمال المكلفة كيف تبقى ضمن مجالها.
وهذا الجزء من DUSK الذي أواصل مراقبته.
#dusk $DUSK @Dusk
يبدو مميزًا على مخطط.
ثم تصل الأحمال الحقيقية.
الخصوصية. توليد الإثباتات. تنفيذ العقود. نمو الحالة. عقد تحاول البقاء متزامنة.
هنا تصبح الأمور مثيرة للاهتمام.
يبدو أن DUSK تفهم ذلك أفضل من معظم الأنظمة.
بدلًا من جعل طبقة واحدة تقوم بكل شيء، يقوم الشبكة بتقسيم العمل.
DuskDS يتولى الإجماع والتسوية وتوفر البيانات.
DuskVM يتولى العقود الأصلية.
وDuskEVM يوفر بيئة تنفيذ مألوفة لتطبيقات مبنية على Solidity.
قد يبدو الأمر وكأنه حديث عن المعمارية.
لكن الأمر يهم لأن كل حمل عمل له طريقة مختلفة ليصبح بطيئًا.
وهناك جزء آخر هادئ: Kadcast.
بدلًا من التلويح بلا نهاية لتبادل أخبار الكتل عبر أقران عشوائيين، يستخدم شبكة منظمة لنشر البيانات. ازدواجية أقل في حركة المرور، وتسليم أكثر قابلية للتنبؤ.
قد لا يكون ذلك مادة جيدة لرسمة تسويقية لافتة.
لكن عندما يصبح أداء الشبكة مزدحمًا، تصبح سعة النطاق المهدورة واقعًا حقيقيًا.
ثم يأتي الجزء الذي يتجاوزه الناس عادةً:
تكاليف الخصوصية تُكلّف حسابات (Compute).
إثباتات المعرفة الصفرية هي عمل فعلي. يمكنك الحصول على إجماع سريع وما زلت تصطدم بجدار إذا أصبحت عملية الإثبات هي عنق الزجاجة.
لذلك لا أعتقد أن سؤال قابلية التوسع الحقيقية لدى DUSK هو:
«هل يمكنها معالجة عدد هائل من المعاملات؟»
بل هو:
ماذا يحدث عندما تصبح تلك المعاملات مكلفة؟
هل يمكن أن تبقى الحتمية/النهائية قابلة للتنبؤ؟
هل تستطيع العقد اللحاق؟
هل يمكن للمعاملات الخاصة أن تتعايش مع نشاط العقود الذكية العادي؟
هذا هو الاختبار الأصعب.
وبصراحة، قرارات الهندسة الصغيرة تُخبرني أكثر من الأرقام الكبيرة.
كيف تتحرك البيانات. كيف يتم الوصول إلى الحالة. كيف تتزامن العقد. كيف تُنتج الإثباتات. وكيف يتم فصل التنفيذ عن التسوية.
لا يبدو أي من ذلك مثيرًا.
لكن هذا عادةً المكان الذي تعيش فيه قابلية التوسع الحقيقية.
السلسلة المتينة ليست تلك التي تكون فيها كل مكوّناتها سريعة بشكل مبالغ فيه.
بل هي تلك التي تعرف فيها الأعمال المكلفة كيف تبقى ضمن مجالها.
وهذا الجزء من DUSK الذي أواصل مراقبته.
#dusk $DUSK @Dusk
