$SUI يوضح الحد الأقصى لمعدل المعالجة بالمعاملات في الثانية (TPS) عدد العمليات التي يستطيع النظام التعامل معها، لكن ثمة سؤال آخر يشغل المستخدمين أكثر: كيف يمكنهم استعادة عملات BTC التي أودعوها؟ تناول المقال السابق أوجه استخدام تمويل Hashi والتزامات رأس المال، وهذه المرة راجعت مسارات السحب بالاستناد إلى وثائق التصميم. وبعد قراءتها، لن أعتبر أن «بقاء BTC على شبكة Bitcoin» يعني تلقائيًا أن «بإمكان المستخدم تحويلها بمفرده في أي وقت».
التمييز الأساسي الذي أضافته الوثائق هو أن السلسلة التي يوجد عليها الأصل والجهة المخوّلة بالموافقة على إنفاقه مسألتان مختلفتان. وفقًا لمسارات المستخدم في Hashi، يودع المستخدم BTC في عنوان Bitcoin مخصص، وبعد التأكيد يحصل على hBTC على Sui. أما الإنفاق المعتاد فيعتمد هيكلية 2 من 2: أحد الطرفين لجنة MPC التابعة لـHashi، والطرف الآخر هو Guardian. وتُنجز MPC التوقيع بالتعاون بين عدة أطراف، فيما يوفر Guardian طبقة تحقق ثانية. لذا فإن تقديم المستخدم طلب سحب لا يعني أنه يملك مفتاحًا يتيح له تحويل BTC مباشرةً متجاوزًا البروتوكول.
تكمن فائدة هذا التحقق في تقييد تحرير الأصول عند وقوع ظروف استثنائية، مثل الثغرات أو السلوك الخبيث. لكن تصميم الأمان يؤثر أيضًا في سرعة السحب. وتوضح وثائق Limiter أن للسحب حدًا أقصى للسعة ومخصصًا يُجدّد باستمرار؛ وعندما لا تكفي السعة، يتعين الانتظار. وإذا تجاوز الطلب الواحد الحد الأقصى للسعة، فسيُتخطى إلى أن يُرفع الحد، ويمكن للمستخدم أيضًا إلغاء طلبه وفقًا للقواعد. عادةً ما تُعالج الطلبات حسب أسبقية ورودها، لكن ذلك غير مضمون على نحو صارم. لذلك، إذا طال انتظار عملية سحب، فلا يكفي وجودها في قائمة الانتظار للجزم بأن الأموال سُرقت، كما أن وجود وسائل حماية في النظام لا يضمن وصولها فورًا. وينبغي النظر معًا إلى إعدادات السعة وقائمة الانتظار والتنفيذ الفعلي.
وهناك أيضًا مسار استرداد يستحق شرحًا مستقلًا. توضح وثائق Address Scheme أن البرنامج النصي، إلى جانب الإنفاق المعتاد، يسمح للجنة MPC بالإنفاق منفردةً بعد تأكيد UTXO وانقضاء قفل زمني نسبي مدته 60 يومًا. ويمكن فهم UTXO على أنها مخرَج على السلسلة لم يُنفق بعد. صُمم هذا المسار للتعامل مع حالات مثل فقدان مفتاح Guardian، وتوفير سبيل آخر للاسترداد؛ وتبدأ المدة من تأكيد ذلك المخرَج، لا من تقديم المستخدم طلب السحب. كما أن هذا التصميم لا يمنح كل مستخدم حق الاسترداد، ولا يشكل وعدًا خدميًا بأن «كل عمليات السحب لن تستغرق أكثر من 60 يومًا».
لذلك، عند تقييم مدى وفاء Hashi بوعوده، لا أنظر إلى كمية BTC التي يمكن إيداعها فحسب، بل أيضًا إلى سلاسة السحب المعتاد، ومدى شفافية معايير تحديد المعدلات، وكيفية التحقق من الاسترداد وتسليم المهام بين أعضاء اللجنة عند تعطل Guardian. فإضافة طبقة تحقق أمنية والحفاظ على سيطرة المستخدم الكاملة والمنفردة ترتيبتان مختلفتان؛ ولتحديد مدى ملاءمة النظام لنوع معين من الأموال، يجب أخذ شروط السحب هذه كلها في الحسبان.
يستند هذا التقييم إلى وثائق التصميم المتاحة حاليًا، وما زالت الصفحة تشير إلى Testnet، لذا لا يصح الاستنتاج منها أن الشبكة الرئيسية تعمل بالكامل وفق المعايير نفسها. أما إعلان 8 أكتوبر فيتحدث عن إطلاق تدريجي خلال هذا الشهر، وينبغي لاحقًا إعادة التحقق بالاستناد إلى عمليات النشر الفعلية وسجلات السحب الحقيقية. ولا يمكن لاستعراض معدل يبلغ 4060万TPS أو التزامات رأسمالية تتجاوز 500 مليون دولار أن يحل محل هذه الخطوة. والخلاصة الجديدة حاليًا هي أن التحقق من قيمة Hashi يتطلب النظر إلى جانبين: قدرة الأنشطة على الدخول إلى النظام، وقدرة الأصول على الخروج منه وفقًا للقواعد في الظروف العادية والاستثنائية. المصادر: وثائق Mysten Labs الخاصة بـHashi، وهي User Flows وGuardian وLimiter وAddress Scheme؛ والصورة المرفقة توضيح تخطيطي للآلية.
التمييز الأساسي الذي أضافته الوثائق هو أن السلسلة التي يوجد عليها الأصل والجهة المخوّلة بالموافقة على إنفاقه مسألتان مختلفتان. وفقًا لمسارات المستخدم في Hashi، يودع المستخدم BTC في عنوان Bitcoin مخصص، وبعد التأكيد يحصل على hBTC على Sui. أما الإنفاق المعتاد فيعتمد هيكلية 2 من 2: أحد الطرفين لجنة MPC التابعة لـHashi، والطرف الآخر هو Guardian. وتُنجز MPC التوقيع بالتعاون بين عدة أطراف، فيما يوفر Guardian طبقة تحقق ثانية. لذا فإن تقديم المستخدم طلب سحب لا يعني أنه يملك مفتاحًا يتيح له تحويل BTC مباشرةً متجاوزًا البروتوكول.
تكمن فائدة هذا التحقق في تقييد تحرير الأصول عند وقوع ظروف استثنائية، مثل الثغرات أو السلوك الخبيث. لكن تصميم الأمان يؤثر أيضًا في سرعة السحب. وتوضح وثائق Limiter أن للسحب حدًا أقصى للسعة ومخصصًا يُجدّد باستمرار؛ وعندما لا تكفي السعة، يتعين الانتظار. وإذا تجاوز الطلب الواحد الحد الأقصى للسعة، فسيُتخطى إلى أن يُرفع الحد، ويمكن للمستخدم أيضًا إلغاء طلبه وفقًا للقواعد. عادةً ما تُعالج الطلبات حسب أسبقية ورودها، لكن ذلك غير مضمون على نحو صارم. لذلك، إذا طال انتظار عملية سحب، فلا يكفي وجودها في قائمة الانتظار للجزم بأن الأموال سُرقت، كما أن وجود وسائل حماية في النظام لا يضمن وصولها فورًا. وينبغي النظر معًا إلى إعدادات السعة وقائمة الانتظار والتنفيذ الفعلي.
وهناك أيضًا مسار استرداد يستحق شرحًا مستقلًا. توضح وثائق Address Scheme أن البرنامج النصي، إلى جانب الإنفاق المعتاد، يسمح للجنة MPC بالإنفاق منفردةً بعد تأكيد UTXO وانقضاء قفل زمني نسبي مدته 60 يومًا. ويمكن فهم UTXO على أنها مخرَج على السلسلة لم يُنفق بعد. صُمم هذا المسار للتعامل مع حالات مثل فقدان مفتاح Guardian، وتوفير سبيل آخر للاسترداد؛ وتبدأ المدة من تأكيد ذلك المخرَج، لا من تقديم المستخدم طلب السحب. كما أن هذا التصميم لا يمنح كل مستخدم حق الاسترداد، ولا يشكل وعدًا خدميًا بأن «كل عمليات السحب لن تستغرق أكثر من 60 يومًا».
لذلك، عند تقييم مدى وفاء Hashi بوعوده، لا أنظر إلى كمية BTC التي يمكن إيداعها فحسب، بل أيضًا إلى سلاسة السحب المعتاد، ومدى شفافية معايير تحديد المعدلات، وكيفية التحقق من الاسترداد وتسليم المهام بين أعضاء اللجنة عند تعطل Guardian. فإضافة طبقة تحقق أمنية والحفاظ على سيطرة المستخدم الكاملة والمنفردة ترتيبتان مختلفتان؛ ولتحديد مدى ملاءمة النظام لنوع معين من الأموال، يجب أخذ شروط السحب هذه كلها في الحسبان.
يستند هذا التقييم إلى وثائق التصميم المتاحة حاليًا، وما زالت الصفحة تشير إلى Testnet، لذا لا يصح الاستنتاج منها أن الشبكة الرئيسية تعمل بالكامل وفق المعايير نفسها. أما إعلان 8 أكتوبر فيتحدث عن إطلاق تدريجي خلال هذا الشهر، وينبغي لاحقًا إعادة التحقق بالاستناد إلى عمليات النشر الفعلية وسجلات السحب الحقيقية. ولا يمكن لاستعراض معدل يبلغ 4060万TPS أو التزامات رأسمالية تتجاوز 500 مليون دولار أن يحل محل هذه الخطوة. والخلاصة الجديدة حاليًا هي أن التحقق من قيمة Hashi يتطلب النظر إلى جانبين: قدرة الأنشطة على الدخول إلى النظام، وقدرة الأصول على الخروج منه وفقًا للقواعد في الظروف العادية والاستثنائية. المصادر: وثائق Mysten Labs الخاصة بـHashi، وهي User Flows وGuardian وLimiter وAddress Scheme؛ والصورة المرفقة توضيح تخطيطي للآلية.