استمررتُ في التفكير في تنفيذ Dusk لـ BLS12-381 بعد أن لاحظتُ تفصيلة صغيرة في العمل التقني: كانت هناك حاجة إلى وظائف إضافية حول المنحنى تتناسب مع متطلبات الشبكة الخاصة بهم.
في البداية، بدا الأمر كأنه مجرد هندسة عادية.
لكن كلما نظرتُ أكثر، قلَّت صفة «العادي» عنه.
BLS12-381 هي منحنى إهليلجي معروف ومناسب لأعمال الاقتران (pairing) ويُستخدم في الأنظمة التي تعتمد على عمليات متقدمة للتحقق والتوقيع. لم يُبدع Dusk المنحنى. بل قام بتكييف التنفيذ بحيث يمكن للتقنيات التشفيرية أن تنسجم فعليًا مع طريقة عمل شبكته.
وهذا الفارق مهم.
فكثير من البنية التحتية لسلاسل الكتل يُوصَف الأمر فيها كما لو أن التحدي الرئيسي هو إيجاد المكوّن التشفيري الصحيح ثم توصيله بالبروتوكول.
في الواقع، قد يأتي الجزء الأصعب بعد ذلك.
يجب أن تعيش التشفيرات داخل بيئة تنفيذ. عليها أن تدعم نموذج التحقق، وأن تتفاعل بشكل صحيح مع بقية البروتوكول، وأن تظل موثوقة في ظل الظروف التي تُنتجها الشبكة فعلًا.
وهذا يعني أن الحدّ الفاصل بين «التشفير» و«هندسة البروتوكول» أضيق مما يبدو لأول وهلة.
وأعتقد أن هذه هي الجزئية التي يستحق الانتباه لها مع Dusk.
ما تزال الرياضيات الأساسية مستمدة من بناءٍ مُتعارف عليه. أما العمل الإضافي فيكمن في جعل ذلك البناء مفيدًا داخل بنية شبكة محددة، دون الادعاء بأن عملية التكييف نفسها تجعل التشفير أكثر أمانًا بشكلٍ سحري.
لا يزال الأمان يعتمد على الرياضيات، وجودة التنفيذ، والاختبارات، وكل ما يحيط بذلك.
ربما لن تُحدَّد الأجيال القادمة من البنية التحتية لسلاسل الكتل من خلال ابتكار تشفير جديد تمامًا.
ربما ستُحدَّد من خلال مدى نجاح جعل التشفير القائم يعمل داخل الأنظمة التي تتطلب شيئًا أكثر تحديدًا.
@Dusk #DUSK $DUSK
في البداية، بدا الأمر كأنه مجرد هندسة عادية.
لكن كلما نظرتُ أكثر، قلَّت صفة «العادي» عنه.
BLS12-381 هي منحنى إهليلجي معروف ومناسب لأعمال الاقتران (pairing) ويُستخدم في الأنظمة التي تعتمد على عمليات متقدمة للتحقق والتوقيع. لم يُبدع Dusk المنحنى. بل قام بتكييف التنفيذ بحيث يمكن للتقنيات التشفيرية أن تنسجم فعليًا مع طريقة عمل شبكته.
وهذا الفارق مهم.
فكثير من البنية التحتية لسلاسل الكتل يُوصَف الأمر فيها كما لو أن التحدي الرئيسي هو إيجاد المكوّن التشفيري الصحيح ثم توصيله بالبروتوكول.
في الواقع، قد يأتي الجزء الأصعب بعد ذلك.
يجب أن تعيش التشفيرات داخل بيئة تنفيذ. عليها أن تدعم نموذج التحقق، وأن تتفاعل بشكل صحيح مع بقية البروتوكول، وأن تظل موثوقة في ظل الظروف التي تُنتجها الشبكة فعلًا.
وهذا يعني أن الحدّ الفاصل بين «التشفير» و«هندسة البروتوكول» أضيق مما يبدو لأول وهلة.
وأعتقد أن هذه هي الجزئية التي يستحق الانتباه لها مع Dusk.
ما تزال الرياضيات الأساسية مستمدة من بناءٍ مُتعارف عليه. أما العمل الإضافي فيكمن في جعل ذلك البناء مفيدًا داخل بنية شبكة محددة، دون الادعاء بأن عملية التكييف نفسها تجعل التشفير أكثر أمانًا بشكلٍ سحري.
لا يزال الأمان يعتمد على الرياضيات، وجودة التنفيذ، والاختبارات، وكل ما يحيط بذلك.
ربما لن تُحدَّد الأجيال القادمة من البنية التحتية لسلاسل الكتل من خلال ابتكار تشفير جديد تمامًا.
ربما ستُحدَّد من خلال مدى نجاح جعل التشفير القائم يعمل داخل الأنظمة التي تتطلب شيئًا أكثر تحديدًا.
@Dusk #DUSK $DUSK
