TBV يتجاوز Bitcoin وEthereum، لكنه ليس مجرد أن يقول لـEthereum: “ثق بي، لقد تم حجز BTC بالفعل.”
عند إنشاء Vault، يقوم المستخدم أولًا بتوليد قيمة سرية لا يعرفها إلا هو، ويرسل هاشها إلى Ethereum. ومن جهة Bitcoin، تُربط مخرجات Pre-PegIn بنفس شرط الهاش. وعندما تكون معاملات Bitcoin والتواقيع ذات الصلة جاهزة، يقوم المستخدم بإعلان القيمة السرية علنًا على Ethereum، عندها فقط يستخدم البروتوكول هذه المعلومة لإكمال المعاملة اللاحقة على جهة Bitcoin.
أفهم أن جوهر هذا التصميم هو ربط حالة الجانبين معًا باستخدام شرط تشفير واحد. بدون القيمة السرية الصحيحة، لا يمكن للخطوات أن تمضي عشوائيًا للأمام؛ كما لا يحتاج المستخدم إلى الوثوق بأن أحد مشغّلي الربط بين السلاسل يقوم بمزامنة قاعدة البيانات بشكل صحيح في الخلفية.
هذه الطريقة ما زالت ليست “قابلة للتنفيذ الذري ضمن معاملة واحدة” بالمعنى التقليدي لعبارة عبر السلاسل، لأن لـBitcoin وEthereum إيقاع إصدار الكتل والتحقق الخاص بهما. لكنّها تسعى إلى ضمان أن الإجراءات الرئيسية على السلسلتين تحدث حول نفس الشرط القابل للتحقق علنًا.
إذا فشل التنسيق خارج السلسلة (off-chain)، فقد تم أيضًا تضمين مسار ردٍّ مرتبط بقفل زمني (time lock) ضمن الإخراج المؤقت على Bitcoin، بحيث لا يفقد المستخدم BTC بشكل دائم لمجرد أن جانب Ethereum لم يُفعَّل بنجاح.
أعتقد أن أكثر ما يخشاه أمن الربط بين السلاسل ليس البطء، بل أن تعرض كل سلسلة نتيجة مختلفة، ثم يتعيّن الانتظار حتى يقوم مسؤول (administrator) بإصلاحها يدويًا. رؤية TBV هي تصميم حالات الفشل مسبقًا، بحيث يمكن أن ينتهي كل من مسار النجاح ومسار الفشل وفق قواعد علنية.
إن نظام الربط بين السلاسل الموثوق حقًا لا يقتصر على إخبار المستخدم بكيفية الدخول، بل يجب أيضًا أن يوضح له، عندما لا يتم إتمام الدخول، كيف يمكنه الرجوع بأمان إلى نقطة البداية. #baby $BABY @BabylonLabs_io
عند إنشاء Vault، يقوم المستخدم أولًا بتوليد قيمة سرية لا يعرفها إلا هو، ويرسل هاشها إلى Ethereum. ومن جهة Bitcoin، تُربط مخرجات Pre-PegIn بنفس شرط الهاش. وعندما تكون معاملات Bitcoin والتواقيع ذات الصلة جاهزة، يقوم المستخدم بإعلان القيمة السرية علنًا على Ethereum، عندها فقط يستخدم البروتوكول هذه المعلومة لإكمال المعاملة اللاحقة على جهة Bitcoin.
أفهم أن جوهر هذا التصميم هو ربط حالة الجانبين معًا باستخدام شرط تشفير واحد. بدون القيمة السرية الصحيحة، لا يمكن للخطوات أن تمضي عشوائيًا للأمام؛ كما لا يحتاج المستخدم إلى الوثوق بأن أحد مشغّلي الربط بين السلاسل يقوم بمزامنة قاعدة البيانات بشكل صحيح في الخلفية.
هذه الطريقة ما زالت ليست “قابلة للتنفيذ الذري ضمن معاملة واحدة” بالمعنى التقليدي لعبارة عبر السلاسل، لأن لـBitcoin وEthereum إيقاع إصدار الكتل والتحقق الخاص بهما. لكنّها تسعى إلى ضمان أن الإجراءات الرئيسية على السلسلتين تحدث حول نفس الشرط القابل للتحقق علنًا.
إذا فشل التنسيق خارج السلسلة (off-chain)، فقد تم أيضًا تضمين مسار ردٍّ مرتبط بقفل زمني (time lock) ضمن الإخراج المؤقت على Bitcoin، بحيث لا يفقد المستخدم BTC بشكل دائم لمجرد أن جانب Ethereum لم يُفعَّل بنجاح.
أعتقد أن أكثر ما يخشاه أمن الربط بين السلاسل ليس البطء، بل أن تعرض كل سلسلة نتيجة مختلفة، ثم يتعيّن الانتظار حتى يقوم مسؤول (administrator) بإصلاحها يدويًا. رؤية TBV هي تصميم حالات الفشل مسبقًا، بحيث يمكن أن ينتهي كل من مسار النجاح ومسار الفشل وفق قواعد علنية.
إن نظام الربط بين السلاسل الموثوق حقًا لا يقتصر على إخبار المستخدم بكيفية الدخول، بل يجب أيضًا أن يوضح له، عندما لا يتم إتمام الدخول، كيف يمكنه الرجوع بأمان إلى نقطة البداية. #baby $BABY @BabylonLabs_io
