الرمز موجود على السلسلة. لكن من يراقب السوق؟
أنا أنظر إلى @Dusk وإعداد NPEX + Chainlink، وهناك شيء يبدو سهلًا التغاضي عنه. وضع أصل مالي على السلسلة يحل مشكلة الملكية. لكنه لا يحل مشكلة المعلومات. تُظهر السجلات من يملك الضمان. لكنها لا تعرف تلقائيًا ما قيمة هذا الضمان خارج السلسلة.
حسنًا، الأصل موجود على السلسلة. لكن السعر ما زال يأتي من مكان آخر. هنا يجعل DataLink المزيد من المعنى بالنسبة لي. تقول Dusk إن الهدف هو جلب بيانات تبادل NPEX الرسمية إلى السلسلة. الجزء المفيد ليس فقط إدخال السعر في عقد ذكي. بل منح العقد اتصالًا بالسوق الذي يوجد فيه الأصل. وإلا فقد تكون البلوكشين صحيحة وتعمل، لكنها تعمل بصورة السوق الخاطئة.
وهنا تغيّر Data Streams طبيعة السؤال. أليست أيضًا جلب بيانات السوق على السلسلة؟ الفرق هو مدى سرعة وصول هذه المعلومات. تم تصميم Data Streams لبيانات سوق منخفضة التأخير وعالية التردد. فإذا تحرّك السوق أولًا ووصلت البيانات لاحقًا، يمكن أن ينفذ التنفيذ المعاملة كما هو مبرمج مع الاستمرار في استخدام معلومات قديمة.
يضيف CCIP جزءًا آخر من اللغز. فهو يتولى قابلية التشغيل البيني عبر السلاسل، بينما يتولى معيار Cross-Chain Token تنقل DUSK عبر آليات الحرق والمِنت. هكذا يمكن للأصل أن ينتقل بين الشبكات دون ادّعاء أن حركة عبر السلاسل واكتشاف السعر وبيانات السوق هي مشكلة واحدة.
هذا يجعلني أرى عملية تحويل الأصول إلى رموز أقل “مرتّبة” مما كنت أظن. أصدر الضمان. سجّل الملكية. اجلب سعر السوق. حافظ على حداثة هذه المعلومات. ثم اترك التطبيق يتصرف بناءً عليها.
وفجأة، لا يؤدي الرمز كل هذا القدر بمفرده.
لبعض الوقت كنت أتعامل مع تحويل الرموز إلى واجهة أساسية باعتباره مشكلة بلوكشين. لكنني لم أعد مقتنعًا بذلك. قد تكون الجزء الأصعب هو الحفاظ على اتصال البلوكشين بكل ما يمنح الأصل معناه المالي.
لأنّه عندما يبدأ التداول ويتحرك السوق، لا يحق للعقد الذكي أن يقول: “سألحق لاحقًا.” $DUSK #dusk
$SKYAI $BNB
أنا أنظر إلى @Dusk وإعداد NPEX + Chainlink، وهناك شيء يبدو سهلًا التغاضي عنه. وضع أصل مالي على السلسلة يحل مشكلة الملكية. لكنه لا يحل مشكلة المعلومات. تُظهر السجلات من يملك الضمان. لكنها لا تعرف تلقائيًا ما قيمة هذا الضمان خارج السلسلة.
حسنًا، الأصل موجود على السلسلة. لكن السعر ما زال يأتي من مكان آخر. هنا يجعل DataLink المزيد من المعنى بالنسبة لي. تقول Dusk إن الهدف هو جلب بيانات تبادل NPEX الرسمية إلى السلسلة. الجزء المفيد ليس فقط إدخال السعر في عقد ذكي. بل منح العقد اتصالًا بالسوق الذي يوجد فيه الأصل. وإلا فقد تكون البلوكشين صحيحة وتعمل، لكنها تعمل بصورة السوق الخاطئة.
وهنا تغيّر Data Streams طبيعة السؤال. أليست أيضًا جلب بيانات السوق على السلسلة؟ الفرق هو مدى سرعة وصول هذه المعلومات. تم تصميم Data Streams لبيانات سوق منخفضة التأخير وعالية التردد. فإذا تحرّك السوق أولًا ووصلت البيانات لاحقًا، يمكن أن ينفذ التنفيذ المعاملة كما هو مبرمج مع الاستمرار في استخدام معلومات قديمة.
يضيف CCIP جزءًا آخر من اللغز. فهو يتولى قابلية التشغيل البيني عبر السلاسل، بينما يتولى معيار Cross-Chain Token تنقل DUSK عبر آليات الحرق والمِنت. هكذا يمكن للأصل أن ينتقل بين الشبكات دون ادّعاء أن حركة عبر السلاسل واكتشاف السعر وبيانات السوق هي مشكلة واحدة.
هذا يجعلني أرى عملية تحويل الأصول إلى رموز أقل “مرتّبة” مما كنت أظن. أصدر الضمان. سجّل الملكية. اجلب سعر السوق. حافظ على حداثة هذه المعلومات. ثم اترك التطبيق يتصرف بناءً عليها.
وفجأة، لا يؤدي الرمز كل هذا القدر بمفرده.
لبعض الوقت كنت أتعامل مع تحويل الرموز إلى واجهة أساسية باعتباره مشكلة بلوكشين. لكنني لم أعد مقتنعًا بذلك. قد تكون الجزء الأصعب هو الحفاظ على اتصال البلوكشين بكل ما يمنح الأصل معناه المالي.
لأنّه عندما يبدأ التداول ويتحرك السوق، لا يحق للعقد الذكي أن يقول: “سألحق لاحقًا.” $DUSK #dusk
$SKYAI $BNB
