小白 Vera

تابع الاندفاع بقوة!

جوهرة اللؤلؤ

لقد تعاملت على مرّ هذه السنوات مع عدد كبير من قضايا المنازعات المتعلقة بالأوراق المالية، وكانت لدي قناعة عميقة بنقطة واحدة: في السوق التقليدي، فإن حالات مثل «سرقة الأسهم، أو إساءة استخدام الحساب، أو صدور أوامر تجميد من المحكمة تُلزم بإعادة حيازة الأصول قسرًا» تكون في غاية التعقيد. فإذا أرادت الجهة المُصدِرة أو الجهة الرقابية إجبار استرجاع أصلٍ ورقة مالية تم تحويله بالفعل إلى أطراف أخرى، فعليها اللجوء إلى التقاضي ثم إلى التنفيذ الجبري عبر المحكمة؛ وخلال ذلك، قد تمر ما لا يقل عن بضعة أسابيع، وقد تمتد القضية أحيانًا لعام ونصف العام إذا كانت معقّدة. وفي هذه الأثناء، يَشاهد المساهمون المتضررون الأصول محل النزاع وهي تتداول بشكل طبيعي في السوق، فيشعرون بالعجز والقلق دون أي حل.

كنت أظن في البداية أن تقنية البلوك تشين ستجعل الأمر أصعب — لكونها لامركزية وغير قابلة للتلاعب؛ وكأنها «مرادف لقول: إذا حوّلتَها إلى شخص ما، فلن يستطيع أحد استعادتها». حتى تصفّحت معايير عقود الأوراق المالية الخاصة بـ Zedger ووجدت ميزة «التحويل القسري من المُصدِر»، عندها أدركت أن الأمر ليس كما توقعت تمامًا. فهي تتيح للمُصدِر، وبمراعاة شروط امتثال محددة، بدء التحويل القسري مباشرة على مستوى البروتوكول، وسحب الحيازات المٌشكلة إلى الوراء، دون الحاجة إلى إتمام كامل سلسلة إجراءات المحكمة أولًا كي يصبح ذلك نافذًا داخل النظام.

قد يبدو هذا التصميم كأنه يمنح السلطة للمُصدِر، لكن بالتفكير ستجد أنه في الحقيقة يعيد «تركيب» خطوة «حكم — تنفيذ» التي كان من المفترض فصلها في التنفيذ القانوني التقليدي، والتي غالبًا ما يحدث انفصال بينها بسبب بطء مرحلة التنفيذ، على المستوى التقني. غير أن التناقض موجود بالفعل أيضًا: إذا كان أصلٌ يمكن للمُصدِر تحويله قسرًا من جانب واحد، فبناء ثقة حامل هذا الأصل بأن «هذه الصفقة من الأصول تخصّه فعليًا، ولن تُنتزع منه بشكل عشوائي» ينبغي أن يستند إلى أي أساس؟ هنا يتحوّل الموضوع إلى تصميم الصلاحيات القانونية، وليس مجرد مسألة تقنية. لأن قدرة البروتوكول على إجراء تحويل قسري لا تعني أن الجهة الرقابية ستُقرّ تلقائيًا بالآثار القانونية لهذا التحويل. ويبدو أن الفجوة بين الأمرين هي المفتاح في ما إذا كانت هذه الميزة ستُعتمد فعليًا.

ما رأيك في تصميم «التحويل القسري من المُصدِر» على السلسلة: هل هو شبكة أمان للمساهمين العاديين، أم نقطة مخاطرة جديدة؟
@Dusk $DUSK #dusk

16 أغسطس، فريق Dusk رصد مرة أخرى نشاطًا شاذًا متعلقًا بمحافظ تقوم بعمليات الربط (Bridge). جرى إيقاف خدمة الربط فورًا بشكل عاجل، واستُعيدت العناوين ذات الصلة، وتمت إضافة قوائم سوداء لاعتراض محافظ الويب. وبعد ذلك أكدت الجهة الرسمية عدم وقوع أي خسائر في أموال المستخدمين. كانت أول ردة فعل لدي بعد قراءتها ليست «نجونا مرة أخرى»، بل: «هذه هي المرة الثانية خلال نصف عام».

أتذكر بوضوح حادث يناير أيضًا: كانت المشكلة في محفظة موقّعة من طبقة التشغيل الخاصة بالفريق، ولم يكن هناك خلل في البلوكشين/السلسلة الرئيسية نفسها؛ بل كان الخلل في «الأعمال التي يديرها البشر» ضمن الحلقة التي تشغّل البروتوكول. أما حادث أغسطس، فالتفاصيل تكاد تكون من نفس القالب حرفيًا—النظام المراقب اكتشف شذوذًا، وتم تعليق الخدمة، وتنسيق البورصات لاعتراض التدفقات المشبوهة، ثم إضافة القائمة السوداء لاحقًا. في كلتا الحادثتين كانت إجراءات الاستجابة احترافية، وسرعة التفاعل لم تكن بطيئة، لكن ما يهمني أكثر هو أمر آخر: تكرار نفس نوع المشكلة مرتين خلال ستة أشهر يعني أن «التعزيز» بعد الحادث الأول—ربما كان مجرد ترقيع، ولم يعالج الجذر الحقيقي للمشكلة.

عملت في هذا المجال لسنوات، ورأيت كثيرًا فرقًا تعالج حوادث الأمان بوضع التركيز كله على «كم بلغت الخسارة هذه المرة؟ وكم بسرعة وقفنا النزيف؟»، بينما قلّ جدًا من يريد الإجابة عن سؤال أصعب—لماذا تظهر الثغرة من نفس النوع مرة ثانية داخل نفس منظومة التشغيل؟ عبارة أن «طبقة البروتوكول ليست بها مشكلة» تُقبل مرة واحدة لتصدقها، لكن قولها مرتين يضع علامة استفهام كبيرة. الأمر ليس موضع شك في قدرات Dusk التقنية، بل في انضباط إدارة المفاتيح، والموافقات متعددة التوقيعات (multisig)، والاستجابة للمراقبة—أي كامل منظومة التشغيل المحيطة بخدمة الربط.

لم تحدث خسارة أموال هذه المرة، فهل كان ذلك حظًا أم أن العملية قد اكتملت بالفعل؟ لا يزال الأمر غير واضح الآن. لكن بالنسبة لسلسلة تسعى إلى جذب أموال المؤسسات، فإن قسم الامتثال لدى المؤسسات لا يهتم أبدًا بعبارة «هل حدثت مشكلة أم لا»، بل يهتم بعبارة «كم مرة عُثر على نفس الحفرة وتم الدوس عليها». هذا السجل، سأحتفظ به وسأتذكره دائمًا.

هل تعتقد أن تكرار نفس نوع حادث الأمان مرتين خلال نصف عام يُعد مجرد تقلب طبيعي لـ «استمرار تعزيز التشغيل»، أم أنه ينبغي أن يكون بمثابة جرس إنذار؟
@Dusk $DUSK #dusk

في البداية اعتقدت أن "إضفاء الأصول على السلسلة" هو الشيء نفسه—أن تضع الأشياء على البلوكشين، فيستطيع الجميع التحقق والتداول، إلى أن تعقبت في Dusk ووجدت الفرق بين كلمتَي "الترميز" و"الإصدار الأصلي"؛ عندها أدركت أنني كنت أبسط الأمر أكثر من اللازم، فهما ليسا شيئًا واحدًا.

بعبارة واضحة، الترميز يعني أن يكون هناك أصل موجود مسبقًا في الواقع—مثل سندٍ إذني/سند دين فعلي—ثم تمنحه "نسخة رقمية" وتضعها على السلسلة. هذا ما فهمته: يشبه إلى حدٍ ما نقل ملكية منزل مُشترى مسبقًا—فالمنزل مكتمل البناء والملكية موجودة سلفًا، وما تفعله هو نقل سجلات المعاملة وتغيّر الملكية إلى نظام جديد للتسجيل فقط. لا يحدث بناء المنزل ولا إجراءات الموافقة ضمن ذلك النظام الجديد؛ وما تراه السلسلة هو مجرد "صورة/مرآة للنتيجة". أمّا الإصدار الأصلي فليس كذلك؛ فهو يعني أن الأصل يبدأ "حياته" على السلسلة منذ لحظة الولادة، فتتم عملية الإصدار وتأكيد الملكية من البداية مباشرة على السلسلة. وهو أقرب إلى توقيع عقد شراء عقار على الخارطة مباشرة عبر الإنترنت—من الاكتتاب إلى التوقيع الإلكتروني والتسجيل/الاعتماد، يجري كامل سير العمل ضمن نظام واحد، وليس مجرد نقل شيء موجود أصلًا لاحقًا إلى السلسلة.

في البداية ظننت أن هذا الفرق ليس مهمًا، لكن كلما فكرت أكثر شعرت أنه جوهري—فإذا كان الأمر مجرد ترميز، فالسلسلة لا تُظهر إلا "ظل" الأصل، بينما قد تكون المنطقيات الأساسية التي تحدد لمن يعود هذا الأصل، وهل يمكن نقله/تداوله، وهل توجد نزاعات أم لا، ما زالت تُدار في الأنظمة التقليدية خارج السلسلة؛ والطبقة على السلسلة تبدو أشبه بـ"لوحة عرض". أما الإصدار الأصلي فهو حقًا ينقل المراحل المحورية في دورة حياة الأصل إلى السلسلة، والصعوبة هنا ليست على الإطلاق بمستوى مجرد "التقاط صورة لأصل موجود ورفعها".

ما يثير فضولي الآن هو أن Dusk تقول إن طريقها الذي تريد سلوكه هو إصدار أصلي (وهذا أصعب)، لكن في الواقع—ما هي الخطوة الفعلية التي وصل إليها المثال/الأمثلة التي طُبّقت حتى الآن على أرض الواقع؟ لم أستطع التحقق من ذلك بعد.

برأيك، أيّهما يُعد فعلاً تمويلًا ماليًا قائمًا على البلوكشين: "وضع ظل الأصل على السلسلة" أم أن يكون الأصل "موجودًا على السلسلة منذ ولادته"؟

@Dusk $DUSK #dusk