أصبحت عمليات التجميع مؤخرا محور تحجيم BTC ، لتصبح أول شيء “يسرق العرض” حقا من شبكة الإضاءة من حيث الاهتمام الأوسع. تم تصميم التراكمات لتكون طبقة ثانية لا تخضع لقيود أو قيود شبكة الإضاءة الأساسية السيولة، أي أن المستخدم النهائي يحتاج إلى شخص ما لتخصيص (أو “إقراض”) الأموال مقدما من أجل تلقي الأموال، أو يحتاج المسار الوسيط إلى رصيد قناة لتسهيل التدفق الكامل لمبلغ الدفع من المرسل إلى المستلم.
كانت هذه الأنظمة في الأصل تعمل على شبكة Ethereum وأنظمة أخرى اكتملت الجولة ، لكن التركيز قد تحول مؤخرًا إلى نقلها إلى سلسلة كتل مبنية على UTXO (مثل BTC). لا يقصد هذا المقال مناقشة الوضع الحالي للتطبيق على BTC ، بل مناقشة وظائف Rollup المثالية التي يسعى الناس إليها على المدى الطويل ، والتي تعتمد على قدرة BTC الحالية على دعم القدرة على التحقق من الدليل بدون معرفة (ZKP) مباشرة على BTC.
تتكون البنية الأساسية لـ Roll على النحو التالي: يحتوي حساب واحد (UTXO في BTC) على رصيد جميع المستخدمين في Rollup. يتضمن هذا UTXO التزامًا يأخذ شكل جذر Merkle في شكل شجرة Merkle ، ويتعهد بجميع الأرصدة الحالية للحسابات في Rollup. يتم تخويل جميع هذه الحسابات باستخدام المفتاح العام / المفتاح الخاص ، لذلك من أجل إجراء صرف خارج السلسلة ، يجب على المستخدمين ما زالوا يستخدمون المفتاح السري لتوقيع بعض المحتويات. تتيح هذه الجزء من الهيكل للمستخدمين مغادرة Rollup في أي وقت دون الحاجة إلى إذن ، بمجرد قيامهم بإثبات المعاملة الخاصة بهم كجزء من شجرة Merkle ، يمكنهم الخروج من Rollup من دون الحاجة إلى إذن من مشغل الشبكة.
يجب أن يتضمن مشغل Rollup ZKP في المعاملة لتحديث جذر ال merkle لرصيد الحساب في داخل السلسلة خلال عملية إتمام المعاملة الخارج السلسلة. إذا لم يكن هناك ZKP ، فإن المعاملة ستكون غير صالحة ولا يمكن أن تكون جزءًا من الكتلة. هذا البرهان يسمح للأشخاص بالتحقق مما إذا كانت جميع التغييرات على رصيد الحساب في الخارج السلسلة قد تمت بموجب تفويض صحيح من صاحب الحساب ، وما إذا كان المشغل لم يقم بتحديث الرصيد بشكل خبيث لسرقة أموال المستخدمين أو إعادة توزيعها بشكل غير أمين للمستخدمين الآخرين.
المشكلة هي، إذا تم نشر جذر شجرة Merkle فقط في السلسلة، يمكن للمستخدمين رؤيته والوصول إليه، فكيف يمكنهم وضع فروعهم في الشجرة بحيث يمكنهم الخروج في أي وقت دون الحاجة إلى إذن؟
Rollup المناسب
في Rollup المناسب، يتم وضع المعلومات مباشرة في سلسلة الكتل كلما تم تأكيد صفقة خارج السلسلة جديدة وتغيرت حالة الحساب Rollup. ليس الشجرة بأكملها، فهذا سخيف جدًا، بل المعلومات اللازمة لإعادة بناء الشجرة. في تنفيذ بسيط، ستحتوي ملخصات جميع الحسابات الحالية في Rollup على الأرصدة، وسيتم إضافة الحسابات فقط في صفقات Rollup الجديدة.
في التطبيقات الأكثر تقدما ، يتم استخدام فروق التوازن. هذا هو في الأساس ملخص للحساب الذي زاد أو نقص الأموال أثناء عملية التحديث. هذا يجعل كل تحديث تراكمي يحتوي فقط على تغييرات رصيد الحساب التي تحدث. يمكن للمستخدم بعد ذلك ببساطة مسح السلسلة و “إجراء الحساب” من بداية الإظهار للوصول إلى الحالة الحالية لرصيد الحساب ، مما يسمح له بإعادة بناء شجرة Merkle للرصيد الحالي.
هذا يمكن أن يوفر الكثير من التكاليف ومساحة الكتلة (وبالتالي توفير الأموال)، مع السماح للمستخدمين بضمان الوصول إلى المعلومات المطلوبة للخروج من جانب واحد. تتطلب قواعد ال rollup تضمين هذه البيانات في ال rollup الرسمي المقدم من سلسلة الكتل للمستخدمين، حيث يعتبر التداول الذي لا يتضمن ملخص الحساب أو الاختلاف في الحسابات تداولًا غير صالحًا.
تاريخ انتهاء الصلاحية
طريقة أخرى لمعالجة مشكلة توفر بيانات سحب المستخدم هي وضع البيانات في مكان آخر خارج سلسلة الكتلة. يترتب على ذلك مشكلات دقيقة حيث يجب على rollup التأكد من توفر البيانات في المكان الآخر. تستخدم التلكؤات الأخرى تقليدياً لهذا الغرض، والتي تم تصميمها خصيصًا كطبقة توفر البيانات لأنظمة rollup وغيرها.
هذا يخلق وضعاً حرجاً لضمان الأمان. عندما يتم نشر البيانات مباشرة على سلسلة كتل بيتكوين، يمكن لقواعد الإجماع ضمان صحتها تمامًا. ومع ذلك، عندما يتم نشرها على أنظمة خارجية، فإن أفضل ما يمكن أن تفعله هو التحقق من صحة إثبات SPV، أي أن البيانات قد تم نشرها على نظام آخر.
هذا يتطلب دليلاً على أن البيانات موجودة في دليل السلسلة الأخرى، وهذه في النهاية مشكلة آلة الأوراق. يتعذر على سلسلة كتل بيتكوين التحقق الكامل من أي شيء يحدث خارج كتلتها الخاصة، وأفضل ما يمكنها فعله هو التحقق من ZKP. ومع ذلك، لا يمكن لـ ZKP التحقق مما إذا كانت البيانات في كتلة الرول أب قد تم بثها علنًا بعد إنشائها حقًا. لا يمكنها التحقق مما إذا كانت المعلومات الخارجية قد تمت إظهارها للجميع.
هذا فتح الباب أمام هجمات الاحتجاز البيانات ، وهذا يعني إنشاء التزامات بالبيانات المنشورة واستخدامها لتعزيز الـrollup ، ولكن البيانات في الواقع غير متوفرة. وهذا يؤدي إلى عدم قدرة المستخدمين على سحب الأموال. الحل الوحيد الحقيقي هو الاعتماد بشكل كامل على قيمة وهيكلية التحفيز خارج الـBTC.
تذبذب بين الانسحاب والتقدم
هذا يجلب للرول أب مأزقًا. عندما يتعلق الأمر بمشكلة توافر البيانات، فإن هناك اختيار ثنائي أساسي بين نشر البيانات على سلسلة كتل بيتكوين أو في مكان آخر تقريبًا. هذا الاختيار له تأثير كبير على أمان الرول أب وسيادته وكفاءته التوسعية.
من ناحية، استخدام سلسلة الكتل بيتكوين كطبقة قابلة للتوسعية للبيانات سيضع حدًا صارمًا لقابلية التوسع لـ rollup. المساحة الكتلية محدودة، وهذا يحدد الحد الأقصى لعدد rollup الممكن ومجموع عدد المعاملات التي يمكن معالجتها خارج السلسلة. يلزم تخصيص مساحة كتلة متناسبة مع عدد حسابات الحساب التي تغيرت رصيدها منذ آخر تحديث لل rollup. تسمح نظرية المعلومات فقط بضغط البيانات إلى حد معين، وفي هذه النقطة لا يوجد مزيد من إمكانات التوسع.
من ناحية أخرى، سيؤدي استخدام طبقات مختلفة لتحقيق توافر البيانات إلى القضاء على الحد الأقصى الصلب لفوائد التوسع، لكنه يأتي أيضًا مع قضايا أمان وسيادة جديدة. في Rollup الذي يستخدم BTC لتحقيق توافر البيانات، إذا لم يتم نشر البيانات التي يحتاجها المستخدم تلقائيًا على سلسلة الكتل، فإن حالة Rollup لن تتغير. باستخدام Validiums، تعتمد هذه الضمانات بشكل كامل على قدرة النظام الخارجي المستخدم على ردع الخداع وإخفاء البيانات.
الآن، يمكن لأي منتج للكتلة على نظام توفر البيانات الخارجية أن يختطف أموال مستخدمي BTCRollup عن طريق إنتاج الكتلة بدلاً من بث الكتلة فعليًا، وبالتالي تحقيق توفر البيانات.
إذا تمكنا حقًا من تحقيق تنفيذ Rollup المثالي على BTC وتمكين سحب الأموال من جانب واحد فقط للمستخدمين، فما الذي سيحدث؟
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مجلة بيتكوين: ما هي المصاعب التي تواجه تقنية الRollup؟
مصدر: مجلة بيتكوين. الترجمة: وو زو، Jinse Finance
أصبحت عمليات التجميع مؤخرا محور تحجيم BTC ، لتصبح أول شيء “يسرق العرض” حقا من شبكة الإضاءة من حيث الاهتمام الأوسع. تم تصميم التراكمات لتكون طبقة ثانية لا تخضع لقيود أو قيود شبكة الإضاءة الأساسية السيولة، أي أن المستخدم النهائي يحتاج إلى شخص ما لتخصيص (أو “إقراض”) الأموال مقدما من أجل تلقي الأموال، أو يحتاج المسار الوسيط إلى رصيد قناة لتسهيل التدفق الكامل لمبلغ الدفع من المرسل إلى المستلم.
كانت هذه الأنظمة في الأصل تعمل على شبكة Ethereum وأنظمة أخرى اكتملت الجولة ، لكن التركيز قد تحول مؤخرًا إلى نقلها إلى سلسلة كتل مبنية على UTXO (مثل BTC). لا يقصد هذا المقال مناقشة الوضع الحالي للتطبيق على BTC ، بل مناقشة وظائف Rollup المثالية التي يسعى الناس إليها على المدى الطويل ، والتي تعتمد على قدرة BTC الحالية على دعم القدرة على التحقق من الدليل بدون معرفة (ZKP) مباشرة على BTC.
تتكون البنية الأساسية لـ Roll على النحو التالي: يحتوي حساب واحد (UTXO في BTC) على رصيد جميع المستخدمين في Rollup. يتضمن هذا UTXO التزامًا يأخذ شكل جذر Merkle في شكل شجرة Merkle ، ويتعهد بجميع الأرصدة الحالية للحسابات في Rollup. يتم تخويل جميع هذه الحسابات باستخدام المفتاح العام / المفتاح الخاص ، لذلك من أجل إجراء صرف خارج السلسلة ، يجب على المستخدمين ما زالوا يستخدمون المفتاح السري لتوقيع بعض المحتويات. تتيح هذه الجزء من الهيكل للمستخدمين مغادرة Rollup في أي وقت دون الحاجة إلى إذن ، بمجرد قيامهم بإثبات المعاملة الخاصة بهم كجزء من شجرة Merkle ، يمكنهم الخروج من Rollup من دون الحاجة إلى إذن من مشغل الشبكة.
يجب أن يتضمن مشغل Rollup ZKP في المعاملة لتحديث جذر ال merkle لرصيد الحساب في داخل السلسلة خلال عملية إتمام المعاملة الخارج السلسلة. إذا لم يكن هناك ZKP ، فإن المعاملة ستكون غير صالحة ولا يمكن أن تكون جزءًا من الكتلة. هذا البرهان يسمح للأشخاص بالتحقق مما إذا كانت جميع التغييرات على رصيد الحساب في الخارج السلسلة قد تمت بموجب تفويض صحيح من صاحب الحساب ، وما إذا كان المشغل لم يقم بتحديث الرصيد بشكل خبيث لسرقة أموال المستخدمين أو إعادة توزيعها بشكل غير أمين للمستخدمين الآخرين.
المشكلة هي، إذا تم نشر جذر شجرة Merkle فقط في السلسلة، يمكن للمستخدمين رؤيته والوصول إليه، فكيف يمكنهم وضع فروعهم في الشجرة بحيث يمكنهم الخروج في أي وقت دون الحاجة إلى إذن؟
Rollup المناسب
في Rollup المناسب، يتم وضع المعلومات مباشرة في سلسلة الكتل كلما تم تأكيد صفقة خارج السلسلة جديدة وتغيرت حالة الحساب Rollup. ليس الشجرة بأكملها، فهذا سخيف جدًا، بل المعلومات اللازمة لإعادة بناء الشجرة. في تنفيذ بسيط، ستحتوي ملخصات جميع الحسابات الحالية في Rollup على الأرصدة، وسيتم إضافة الحسابات فقط في صفقات Rollup الجديدة.
في التطبيقات الأكثر تقدما ، يتم استخدام فروق التوازن. هذا هو في الأساس ملخص للحساب الذي زاد أو نقص الأموال أثناء عملية التحديث. هذا يجعل كل تحديث تراكمي يحتوي فقط على تغييرات رصيد الحساب التي تحدث. يمكن للمستخدم بعد ذلك ببساطة مسح السلسلة و “إجراء الحساب” من بداية الإظهار للوصول إلى الحالة الحالية لرصيد الحساب ، مما يسمح له بإعادة بناء شجرة Merkle للرصيد الحالي.
هذا يمكن أن يوفر الكثير من التكاليف ومساحة الكتلة (وبالتالي توفير الأموال)، مع السماح للمستخدمين بضمان الوصول إلى المعلومات المطلوبة للخروج من جانب واحد. تتطلب قواعد ال rollup تضمين هذه البيانات في ال rollup الرسمي المقدم من سلسلة الكتل للمستخدمين، حيث يعتبر التداول الذي لا يتضمن ملخص الحساب أو الاختلاف في الحسابات تداولًا غير صالحًا.
تاريخ انتهاء الصلاحية
طريقة أخرى لمعالجة مشكلة توفر بيانات سحب المستخدم هي وضع البيانات في مكان آخر خارج سلسلة الكتلة. يترتب على ذلك مشكلات دقيقة حيث يجب على rollup التأكد من توفر البيانات في المكان الآخر. تستخدم التلكؤات الأخرى تقليدياً لهذا الغرض، والتي تم تصميمها خصيصًا كطبقة توفر البيانات لأنظمة rollup وغيرها.
هذا يخلق وضعاً حرجاً لضمان الأمان. عندما يتم نشر البيانات مباشرة على سلسلة كتل بيتكوين، يمكن لقواعد الإجماع ضمان صحتها تمامًا. ومع ذلك، عندما يتم نشرها على أنظمة خارجية، فإن أفضل ما يمكن أن تفعله هو التحقق من صحة إثبات SPV، أي أن البيانات قد تم نشرها على نظام آخر.
هذا يتطلب دليلاً على أن البيانات موجودة في دليل السلسلة الأخرى، وهذه في النهاية مشكلة آلة الأوراق. يتعذر على سلسلة كتل بيتكوين التحقق الكامل من أي شيء يحدث خارج كتلتها الخاصة، وأفضل ما يمكنها فعله هو التحقق من ZKP. ومع ذلك، لا يمكن لـ ZKP التحقق مما إذا كانت البيانات في كتلة الرول أب قد تم بثها علنًا بعد إنشائها حقًا. لا يمكنها التحقق مما إذا كانت المعلومات الخارجية قد تمت إظهارها للجميع.
هذا فتح الباب أمام هجمات الاحتجاز البيانات ، وهذا يعني إنشاء التزامات بالبيانات المنشورة واستخدامها لتعزيز الـrollup ، ولكن البيانات في الواقع غير متوفرة. وهذا يؤدي إلى عدم قدرة المستخدمين على سحب الأموال. الحل الوحيد الحقيقي هو الاعتماد بشكل كامل على قيمة وهيكلية التحفيز خارج الـBTC.
تذبذب بين الانسحاب والتقدم
هذا يجلب للرول أب مأزقًا. عندما يتعلق الأمر بمشكلة توافر البيانات، فإن هناك اختيار ثنائي أساسي بين نشر البيانات على سلسلة كتل بيتكوين أو في مكان آخر تقريبًا. هذا الاختيار له تأثير كبير على أمان الرول أب وسيادته وكفاءته التوسعية.
من ناحية، استخدام سلسلة الكتل بيتكوين كطبقة قابلة للتوسعية للبيانات سيضع حدًا صارمًا لقابلية التوسع لـ rollup. المساحة الكتلية محدودة، وهذا يحدد الحد الأقصى لعدد rollup الممكن ومجموع عدد المعاملات التي يمكن معالجتها خارج السلسلة. يلزم تخصيص مساحة كتلة متناسبة مع عدد حسابات الحساب التي تغيرت رصيدها منذ آخر تحديث لل rollup. تسمح نظرية المعلومات فقط بضغط البيانات إلى حد معين، وفي هذه النقطة لا يوجد مزيد من إمكانات التوسع.
من ناحية أخرى، سيؤدي استخدام طبقات مختلفة لتحقيق توافر البيانات إلى القضاء على الحد الأقصى الصلب لفوائد التوسع، لكنه يأتي أيضًا مع قضايا أمان وسيادة جديدة. في Rollup الذي يستخدم BTC لتحقيق توافر البيانات، إذا لم يتم نشر البيانات التي يحتاجها المستخدم تلقائيًا على سلسلة الكتل، فإن حالة Rollup لن تتغير. باستخدام Validiums، تعتمد هذه الضمانات بشكل كامل على قدرة النظام الخارجي المستخدم على ردع الخداع وإخفاء البيانات.
الآن، يمكن لأي منتج للكتلة على نظام توفر البيانات الخارجية أن يختطف أموال مستخدمي BTCRollup عن طريق إنتاج الكتلة بدلاً من بث الكتلة فعليًا، وبالتالي تحقيق توفر البيانات.
إذا تمكنا حقًا من تحقيق تنفيذ Rollup المثالي على BTC وتمكين سحب الأموال من جانب واحد فقط للمستخدمين، فما الذي سيحدث؟