تصفّح الكتل يرى الاسترداد، فلماذا لا يزال $BTC غير قادر على الإفراج
تم بث معاملة Ethereum بالفعل، وتم تجميعها، وتوليد receipt، وحتى أنه يمكن العثور على حدث redemption. هذا لا يثبت إلا أن كتلة تنفيذ واحدة تحتوي هذه السجلات. وبالنسبة لـ TBV في الشبكة الاختبارية العامة الحالية، فهذا لا يزال غير كافٍ لإطلاق BTC، لأنه يجب أيضًا إثبات أن هذه الكتلة تنتمي إلى السجل التاريخي الذي اعتمدته Ethereum نهائيًا.
إن قام المستخدم بتسديد الدَّين بالكامل ثم withdraw Vault، أو أدى سير عملية التصفية إلى تسليم Vault إلى جهة الاسترداد اللاحقة، فسيؤدي ذلك إلى تشغيل حدث redemption. ينشئ مُثبت SP1 خارج السلسلة الإثباتات بالترتيب الثابت التالي: أولًا تؤكد Beacon finality أن beacon block قد تم بالفعل إتمامه (finalize) على طبقة الإجماع؛ ثم تقوم Execution finality بربط هذا الـ beacon block المُتمَّم مع block تنفيذ يحتوي على معاملة الاسترداد؛ وأخيرًا يؤكد Receipt inclusion أن log الخاص بـ redemption الهدف موجود ضمن transaction receipt لهذه الكتلة. يقوم Groth16 فقط بضغط ودمج الإثباتات في الطبقات الثلاث الأولى إلى proof مضغوط ومتماسك، ولا يمنح الكتلة صفة النهائيّة (finality).
لقد غيّرت هذه المجموعة من الطبقات حكمِي: لم أعد أعتبر أن “المتصفح شاهد المعاملة” يعني أن حق الاسترداد عبر السلاسل قد أصبح حقيقةً ثابتة، بل سأتأكد من أن أمرين يمكنهما إثبات الشيء نفسه معًا—أن الحدث تم تضمينه فعلًا، وأن block التنفيذ الحامل له قد تم الاعتراف به أيضًا من قبل beacon chain النهائية. الطبقة الأولى تجيب: “ما الذي حدث؟” والطبقة الثانية تجيب: “هل أصبح ضمن الحالة النهائية لـ Ethereum؟”. إن غابت الطبقة الأخيرة، فقد تُبنى عملية دفع Bitcoin (Bitcoin Payout) على تاريخ خارجي غير مستقر بعد.
بعد إكمال إثبات finality وإثبات inclusion، يقوم المُطالب (claimer) عندها بإدخال proof المضغوط إلى جانب Bitcoin عبر Claim وAssert ونافذة الـ challenge. يؤكد finality في Ethereum أن الحدث الخارجي ينتمي إلى أي جزء من السجل التاريخي النهائي؛ بينما تتحقق فترة التحدي في Bitcoin من أن الـ proof المقدَّم إلى جانب Bitcoin يمكن أن يثبت صحته. هذان لا ينتظر أحدهما نفس الشيء، ولا يمكن أن يتبدلا؛ وما لم يتم دحض الـ proof بشكل فعّال، فلن يدخل Payout مرحلة التنفيذ.
كما يجب تحديد الحدود بوضوح: إن إثبات حدث redemption المُتمَّم يعني فقط أن هذا الـ log قد دخل السجل التاريخي النهائي لـ Ethereum، ولا يعني بالضرورة أن التعاقدات العلوية أو آليات الأوراكل أو أحكام التصفية صحيحة اقتصاديًا دائمًا؛ وإذا ظهرت أعطال عميقة في إجماع Ethereum، فقد يؤدي ذلك أيضًا إلى تعطّل التحقق أو حدوث خطأ. يقوم @BabylonLabs_io بوضع العتبة على “الحدث داخل التاريخ النهائي”، وليس على “الحدث الذي يمكن رؤيته في المتصفح”، وهذا بالضبط لأن إطلاق Bitcoin لن يتم إلغاؤه تلقائيًا بسبب تغيّرات لاحقة في السلسلة الخارجية. $ETH
$BABY
#baby
تم بث معاملة Ethereum بالفعل، وتم تجميعها، وتوليد receipt، وحتى أنه يمكن العثور على حدث redemption. هذا لا يثبت إلا أن كتلة تنفيذ واحدة تحتوي هذه السجلات. وبالنسبة لـ TBV في الشبكة الاختبارية العامة الحالية، فهذا لا يزال غير كافٍ لإطلاق BTC، لأنه يجب أيضًا إثبات أن هذه الكتلة تنتمي إلى السجل التاريخي الذي اعتمدته Ethereum نهائيًا.
إن قام المستخدم بتسديد الدَّين بالكامل ثم withdraw Vault، أو أدى سير عملية التصفية إلى تسليم Vault إلى جهة الاسترداد اللاحقة، فسيؤدي ذلك إلى تشغيل حدث redemption. ينشئ مُثبت SP1 خارج السلسلة الإثباتات بالترتيب الثابت التالي: أولًا تؤكد Beacon finality أن beacon block قد تم بالفعل إتمامه (finalize) على طبقة الإجماع؛ ثم تقوم Execution finality بربط هذا الـ beacon block المُتمَّم مع block تنفيذ يحتوي على معاملة الاسترداد؛ وأخيرًا يؤكد Receipt inclusion أن log الخاص بـ redemption الهدف موجود ضمن transaction receipt لهذه الكتلة. يقوم Groth16 فقط بضغط ودمج الإثباتات في الطبقات الثلاث الأولى إلى proof مضغوط ومتماسك، ولا يمنح الكتلة صفة النهائيّة (finality).
لقد غيّرت هذه المجموعة من الطبقات حكمِي: لم أعد أعتبر أن “المتصفح شاهد المعاملة” يعني أن حق الاسترداد عبر السلاسل قد أصبح حقيقةً ثابتة، بل سأتأكد من أن أمرين يمكنهما إثبات الشيء نفسه معًا—أن الحدث تم تضمينه فعلًا، وأن block التنفيذ الحامل له قد تم الاعتراف به أيضًا من قبل beacon chain النهائية. الطبقة الأولى تجيب: “ما الذي حدث؟” والطبقة الثانية تجيب: “هل أصبح ضمن الحالة النهائية لـ Ethereum؟”. إن غابت الطبقة الأخيرة، فقد تُبنى عملية دفع Bitcoin (Bitcoin Payout) على تاريخ خارجي غير مستقر بعد.
بعد إكمال إثبات finality وإثبات inclusion، يقوم المُطالب (claimer) عندها بإدخال proof المضغوط إلى جانب Bitcoin عبر Claim وAssert ونافذة الـ challenge. يؤكد finality في Ethereum أن الحدث الخارجي ينتمي إلى أي جزء من السجل التاريخي النهائي؛ بينما تتحقق فترة التحدي في Bitcoin من أن الـ proof المقدَّم إلى جانب Bitcoin يمكن أن يثبت صحته. هذان لا ينتظر أحدهما نفس الشيء، ولا يمكن أن يتبدلا؛ وما لم يتم دحض الـ proof بشكل فعّال، فلن يدخل Payout مرحلة التنفيذ.
كما يجب تحديد الحدود بوضوح: إن إثبات حدث redemption المُتمَّم يعني فقط أن هذا الـ log قد دخل السجل التاريخي النهائي لـ Ethereum، ولا يعني بالضرورة أن التعاقدات العلوية أو آليات الأوراكل أو أحكام التصفية صحيحة اقتصاديًا دائمًا؛ وإذا ظهرت أعطال عميقة في إجماع Ethereum، فقد يؤدي ذلك أيضًا إلى تعطّل التحقق أو حدوث خطأ. يقوم @BabylonLabs_io بوضع العتبة على “الحدث داخل التاريخ النهائي”، وليس على “الحدث الذي يمكن رؤيته في المتصفح”، وهذا بالضبط لأن إطلاق Bitcoin لن يتم إلغاؤه تلقائيًا بسبب تغيّرات لاحقة في السلسلة الخارجية. $ETH
$BABY
#baby