مجرد

تتعمق هذه المقالة في الطرق العملية لتمكين التحقق من ZK في Bitcoin ، والتي تغطي موضوعات مثل نموذج UTXO الخاص ب Bitcoin ، وقيود البرمجة النصية ، و Taproot ، و OP_CAT ، و BitVM ، و Chain State Proofs. يقدم حجة واضحة مفادها أن دمج ZK في بروتوكول Bitcoin أمر لا مفر منه. تم تسليط الضوء على طريقين محتملين: أحدهما هو إعادة تقديم رمز التشغيل OP_CAT لدعم التحقق من SNARK مباشرة في نصوص Bitcoin - وهو تغيير لديه احتمال كبير للموافقة النهائية. يدور النهج الثاني حول BitVM ، والذي يتضمن أدلة على الاحتيال. بالإضافة إلى ذلك ، يهدف اقتراح فريق ZeroSync لإثبات حالة السلسلة إلى تقليل تكلفة التحقق من البيانات التاريخية لعملاء العقدة.

النص الرئيسي: لفهم البيتكوين بشكل كامل ، من المفيد النظر إليه كنظام اجتماعي. في أيامها الأولى ، حدد منشئو Bitcoin البرنامج الذي يجب أن تعمل العقد ، تماما مثل وضع القواعد التي تحكم المجتمع. يعتمد استقرار البيتكوين على إجماع واسع حول طبيعتها الأساسية، مما يؤدي إلى أسئلة مثل "ما هي بيتكوين في جوهرها؟" و "ما الذي يجب أن تتطور إليه بيتكوين؟" ومع ذلك، من المعروف أن التوصل إلى توافق في الآراء بشأن هذه المسائل أمر صعب، حيث تختلف الآراء على نطاق واسع وتتطور باستمرار.

هذا يعود إلى الأصل التاريخي للبيتكوين. عندما أصدر ساتوشي ناكاموتو ورقة بيتكوين البيضاء، قال: "أنا أعمل على نظام دفع إلكتروني جديد تماما. هذا النظام هو P2P بالكامل ولا يحتاج إلى الاعتماد على أي طرف ثالث ". تم نشر هذا المقطع على القائمة البريدية ل Cypherpunks (مجموعة مناقشة عبر البريد الإلكتروني تأسست في عام 1992 ، وتتألف من مجموعة من مصممي التشفير وعشاق التكنولوجيا المهتمين بحماية الخصوصية وتكنولوجيا التشفير).

ومع ذلك، تقيد بيتكوين بمعدل تدفق البيانات على مستوى تصميم المنتج. يتم تقييد عدد المعاملات التي يمكنها معالجتها في وحدة الزمن. إذا زاد عدد المعاملات التي يجب معالجتها بسرعة، سيبدأ المستخدمون حرب الأسعار من أجل إتمام المعاملة بنجاح بسرعة، مما يؤدي إلى زيادة سريعة في الرسوم التي يتم دفعها. حدثت المعاملة الفردية ذات الرسوم التشغيلية الأعلى في شبكة بيتكوين بعد تقليص مكافأة الكتلة إلى النصف في عام 2024، ووصلت رسوم التشغيل للمعاملة ذات الأولوية المتوسطة على السلسلة إلى 150 دولارًا. يمكن القول إن الرسوم المكلفة للمعاملات في شبكة بيتكوين أصبحت مشكلة.

لحل مشكلة رسوم المعاملات، قام الناس بإستثمار الكثير من الموارد في تطوير شبكة البرق. ولكن وفقًا لورقة بحث نشرت في عام 2016، يمكن لشبكة البرق تحقيق الدعم فقط لعشرات الملايين من المستخدمين عمليًا ولا يمكنها تحقيق رؤيتها لنظام دفع عالمي. بالإضافة إلى رسوم المعاملات المكلفة للغاية، هناك مشكلة أخرى، وهي أن بيتكوين لم يستطع أبدًا تحقيق التحجب الذي تصوره.

أشار ساتوشي ناكاموتو في مجموعة مناقشة البريد الإلكتروني cypherpunk إلى أن Bitcoin لديها وظيفة حماية الخصوصية ويمكن أن يكون بادئ المعاملة مجهولا تماما. ومع ذلك ، على الرغم من أن بادئ المعاملة لا يتطلب KYC ، فإن بيانات المعاملة على سلسلة Bitcoin تسرب الكثير من المعلومات ، مما يعرض خصوصية المستخدم إلى حد كبير. على الرغم من وجود بعض عملاء المحفظة الذين لديهم وظائف خصوصية تحل المشكلات المذكورة أعلاه إلى حد ما ، إلا أن مطوري عملاء المحفظة هؤلاء يواجهون تهديدات بأحجام مختلفة. على سبيل المثال ، تم القبض على مطور محفظة Samourai CoinJoin من قبل مكتب التحقيقات الفيدرالي في أبريل 2024 ، وبعد أسبوع ، أغلق مطور محفظة Wasabi مكون تنسيق CoinJoin الخاص به. من الواضح أن محافظ الخصوصية المزعومة هذه لا تستحق ثقة المستخدمين تماما.

لإجمال، العديد من مفاهيم بيتكوين لم تتحقق حتى اليوم، والتقنيات المتعلقة ما زالت تحت التطوير المتواصل. وحتى في ذلك الوقت، يعتقد العديد من الأشخاص في مجتمع بيتكوين أن تصميم بروتوكول بيتكوين يجب أن يبقى دون تغيير، ولكن هناك أيضًا العديد من الأشخاص، مثلي، الذين يشعرون بشغف لتحقيق تحسينات على بيتكوين. فإلى أي اتجاه ينبغي لبيتكوين التحسين؟

رداً على المسائل المذكورة أعلاه، هناك العديد من الاقتراحات في مجتمع بيتكوين، ويجب أن تتعلق الأفضل منها نتائجها النظرية بـ ZK و SNARKs. باستخدام ZK و SNARKs، يمكن تحقيق الميزات التالية:

1. خصوصية محسنة بشكل كبير: استخدام الالتزام بيترسون الهومومورفي لمبلغ المعاملة وإثبات المدى لتحسين خصوصية المستخدم بشكل كبير (مثل ما يحدث في سلسلة الجانب الخاصة بـ Blockstream's Element) ؛ استخدام تواقيع قابلة للربط (مثل Monero) لإخفاء آثار المعاملة ؛ تحقيق معاملات خاصة حقًا (مثل Zcash).

2. تحسين كفاءة المعاملات

يمكن أن تعالج العديد من الحلول التقنية المشاكل الحالية في بيتكوين، ولكن لماذا لم يتم دمج هذه التقنيات في بروتوكول بيتكوين؟ الجواب يكمن في صعوبة تعديل البروتوكول. على عكس إثريوم، لا يوجد لدى بيتكوين منظمة مركزية مثل مؤسسة إثريوم. يتطلب أي تغيير في البروتوكول مستوى عالٍ من التوافق في المجتمع، وينطوي على مفاوضات وتوازنات مكثفة للمصالح. نتيجة لذلك، في حين يقوم إثريوم بتحديث رموزه EVM بانتظام، فإن بروتوكول بيتكوين لم يشهد تغييرات كثيرة منذ بدايته.

من ناحية ما، فإن هذه الصعوبة في تعديل البروتوكول مفيدة. إذا كان من السهل تنفيذ التغييرات، فإن التعديلات الخبيثة أو الهجمات ستكون أكثر احتمالاً. وهذا يثير السؤال: كيف يمكن تحسين أداء البيتكوين دون تغيير البروتوكول؟

للرد على هذا، نحتاج إلى إعادة زيارة بعض أساسيات البيتكوين. عندما تقوم بتحويل بيتكوين لشخص آخر، فإنك تقوم بإنشاء معاملة وبثها إلى شبكة البيتكوين. تحدد بيانات الإخراج للمعاملة مبلغ البيتكوين المحول. يمكن للمستلم بعد ذلك إنشاء معاملة جديدة لإنفاق البيتكوين المستلمة، مما يولد بيانات إخراج جديدة في العملية.

من المهم ملاحظة أن بيتكوين لا يمتلك حالة عالمية مثل إيثريوم، ويفتقر بشكل خاص إلى حالة الحساب، فهو يحتوي فقط على بيانات إخراج المعاملات. يحتوي كل إخراج للمعاملة على حالتين: إما أن يكون قد تم إنفاقه من قبل المستلم أو لا يزال غير مستنفد. إخراجات المعاملات غير المستنفدة (UTXOs) هي ما نعرفه. بالإضافة إلى كمية بيتكوين المرتبطة به، يحتوي كل إخراج للمعاملة أيضًا على سكريبت مرفق مكتوب بلغة Bitcoin Script. يمكن لمن يستطيع تقديم البرهان الصحيح (الشاهد) لهذا السكريبت أن ينفق UTXO.

البرنامج النصي بيتكوين هو لغة برمجة تعتمد على الكومة مع سلسلة من أوبكود. البرامج المرفقة بـ UTXOs غالبًا ما تتكون من عدة أوبكود ، تقوم بالحسابات بناءً على الكومة وتعيد النتائج إليها. هناك العديد من البرامج النصية الشائعة في بيتكوين منذ بدايته. على سبيل المثال ، يتكون البرنامج النصي الأكثر شيوعًا من مفتاح عام وأوبكود يتحقق من التوقيع الرقمي. يتطلب هذا الأوبكود توفير توقيع رقمي مطابق للمفتاح العام لإنفاق أو فتح UTXO.

القراءة الموصى بها: [الاقتراب من بيتكوين: المعرفة الأساسية لفهم BitVM (1)]

قدرات سكريبت بيتكوين

ما الذي يمكن أن يفعله سكريبت البيتكوين:

• أعد ترتيب الكومة وقم بإجراء فحوصات المساواة (للتحقق من الشروط المحددة وضمان أمان وصحة المعاملة).
• تنفيذ عمليات شرطية مشابهة لعبارات if-else.
• القيام بعمليات حسابية محدودة على الأرقام بتنسيق 32 بت، مثل الجمع والطرح.
• بيانات التجزئة والتحقق من توقيعات ECDSA وSchnorr.

ما لا يمكن أن يفعله سكريبت بيتكوين:

• لا توجد حلقات أو قفزات أو تكرار؛ إنها ليست قادرة على التعامل مع أي مهام برمجية محدودة جدًا.
• لا يمكن تنفيذ العمليات الثنائية.
• يفتقر إلى الأوبكود لعمليات الضرب والقسمة.
• لا يمكن دمج العناصر على الكومة.
• لديه قدرة محدودة جدًا على قراءة والتحقق من بيانات المعاملات في السلسلة النصية لبيتكوين. لا يمكن لسكريبت بيتكوين الوصول المباشر إلى مبلغ كل معاملة ولا يمكنه تمرير الحالة (يتم استخدام UTXOs مرة واحدة فقط، ويتم حرق القديمة وإنشاء جديدة في كل عملية نقل).

في النسخ المبكرة من بيتكوين، كانت بعض وظائف 'لا يمكن القيام بها' المذكورة أعلاه ممكنة، ولكن تم تعطيل بعض كودات التشغيل لاحقًا بواسطة ساتوشي ناكاموتو بسبب ثغرات الأمان. على سبيل المثال، تم استخدام كود التشغيل OP_CAT لدمج عنصرين من الدرج في هجمات عن بعد على عقد بيتكوين وتسبب في تعطلها. قام ساتوشي بتعطيل OP_CAT وكودات التشغيل الأخرى لأسباب أمان.

هل يمكن لـ Bitcoin Script التحقق من SNARKs؟ من الناحية النظرية، على الرغم من أن Bitcoin Script ليست كاملة من الناحية العملية، فإن عملياتها الأساسية كافية للتحقق من أي حساب. ومع ذلك، من الناحية العملية، فإن التحقق من SNARK غير ممكن لأن حجم البرنامج المطلوب لخطوات التحقق يتجاوز الحد الأقصى للكتلة في Bitcoin والبالغ 4 ميجابايت. بينما يمكننا محاولة عمليات الحساب في حقول محددة كبيرة، فإن التكلفة ستكون مرتفعة بشكل لا يمكن تحمله. على سبيل المثال، في BitVM، أدى ضرب عددين من 254 بت إلى حجم برنامج Bitcoin Script يبلغ ما يقرب من 8 كيلوبايت. علاوة على ذلك، بدون OP_CAT، فإن تكلفة التحقق من دلائل Merkle عالية أيضًا، حيث يتطلب ذلك عمليات مشابهة لحلقات.

فلماذا لا نقوم بتعديل بروتوكول البيتكوين لإضافة مزيد من التعليمات البرمجية القوية؟ كما ذُكر سابقًا، فإن تحقيق توافق الغالبية بشأن قواعد بروتوكول جديدة يعد أمرًا صعبًا للغاية. يفتقر البيتكوين إلى من يتخذ القرار بشكل مركزي، وتواجه أي مقترح لتحسين برنامج البيتكوين النصي معارضة كبيرة من أصحاب المصلحة الذين يحملون آراء مختلفة. لا يوجد طريقة فعالة لقياس توافق المجتمع في شبكة البيتكوين، وقد يؤدي إجبار التحديث دون ذلك إلى تقسيم السلسلة. بالطبع، ليس البيتكوين غير قابل للتعديل تمامًا. كانت أحدث التحديثات SegWit في عام 2017 و Taproot في عام 2021.

ترقية تابروت، التي غيرت العديد من القواعد، استغرقت ثلاث سنوات ونصف للانتقال من الإصدار النظري إلى التنشيط الفعلي. العامل الرئيسي في تمكين تابروت كان أنها لم تغير الافتراضات الأمان الحالية وقدمت تحسينات واضحة لبروتوكول بيتكوين. على سبيل المثال، يسمح باستخدام تواقيع شنور بدلاً من ECDSA. كلاهما مستند إلى افتراضية اللوغاريتم ال diskrete ويستخدمان نفس المنحنى البيضاوي، ولكن الأول أكثر كفاءة ويتطلب أقل حساب.

علاوة على ذلك ، يمكن تصنيف تحسينات تابروت لبيتكوين إلى الجوانب الثلاث التالية:

أولاً، يقلل Taproot من تكاليف التحقق من النصوص ذات الفروع الشرطية الكثيرة، مما يتيح لبيتكوين دعم برامج أكثر تعقيداً.

ثانيًا ، يقلل Taproot من كمية بيانات البرنامج النصي التي يتعين الكشف عنها على السلسلة ، ويمكنك تجميع برامج البرنامج النصي المتعددة في شجرة ميركل ، حيث يتم وضع كل برنامج نصي على ورقة مختلفة. إذا أردت تنشيط برنامج نصي معين ، فأنت بحاجة فقط إلى كشف الورقة التي يتم توضع البرنامج النصي فيها وإثبات ميركل؛

ثالثاً، أضاف Taproot أيضاً تصميمات ميكانيكية أخرى.

بالنظر إلى سابقة Bitcoin مع Taproot لدمج ميزات أكثر تقدما ، قد يتساءل المرء عن سبب عدم تقديم رمز تشغيل مخصص للتحقق من SNARK. يكمن الاختلاف الرئيسي في التعقيد والإجماع المطلوبين OP_SNARK. على عكس Taproot ، التي كان لها تصميم واضح ومباشر حصل على دعم واسع ، تختلف مقترحات OP_SNARK على نطاق واسع ، مما يجعل من الصعب حشد المجتمع حول نهج واحد. إذا تم تنفيذه ، فستحتاج كل عقدة Bitcoin إلى دعم طريقة التحقق SNARK المحددة هذه ، مما سيزيد بشكل كبير من المتطلبات الفنية. علاوة على ذلك ، يعد التعقيد المتأصل في OP_SNARK عقبة رئيسية - أضاف Taproot حوالي 1,600 سطر من التعليمات البرمجية ، يمكن التحكم فيها وفقا لمعايير المجتمع ، في حين أن OP_SNARK يستلزم ترميزا أكثر تعقيدا. وعلاوة على ذلك، فإن تحديد من سيقيم تفعيل OP_SNARK وتحقيق توافق في الآراء عندما لا يدرك سوى القليل تعقيداته بشكل كامل يضيف طبقات من الصعوبة. وبالنظر إلى هذه التحديات، من غير المرجح أن تتحقق ترقية OP_SNARK في المستقبل القريب.

مع ذلك، هناك طرق أخرى للتحقق من SNARKs في Bitcoin Script. يمكننا جعل نصوص Bitcoin أكثر وظيفية عن طريق إضافة أوامر أكثر بساطة، مما يتيح للناس تنفيذ برامج تحقق من SNARKs في النصوص. ولكن في الواقع، من الصعب جدًا كتابة برنامج تحقق من SNARK في لغة Bitcoin script. لذلك، فريق البحث في Blockstream يعمل على تطوير Simplicity، وهي لغة برمجة مصممة لاستبدال لغة Bitcoin Script. تم تصميم Simplicity بشكل خاص لأنظمة توافق سلسلة الكتل وهي ليست كاملة المواصفات، مما يجعل النمذجة الثابتة والتحقق الرسمي سهلين.

دعونا نولي اهتمامنا بمقترح بسيط يبدو ولكنه قد يكون له تأثير كبير يمكن أن يعزز قدرات بيتكوين النصية بشكل كبير: إعادة تنشيط رمز التشغيل OP_CAT. تم تضمين OP_CAT أصلاً في الكود المبكر لبيتكوين ولكنه تم تعطيله لاحقًا من قبل ساتوشي ناكاموتو بسبب إمكانية تمكين هجمات DoS تحت ظروف معينة. ومع ذلك، هناك اهتمام متزايد الآن داخل مجتمع بيتكوين لإعادته.

وظيفة OP_CAT بسيطة - فهي تأخذ العنصرين الأعلى من الكومة ، وتربطهما ، ثم تدفع النتيجة مرة أخرى إلى الكومة. على الرغم من أن هذا قد يبدو أساسيًا ، إلا أنه لديه القدرة على فتح تحسينات كبيرة في لغة برمجة بيتكوين. على سبيل المثال ، البرامج النصية الحالية لبيتكوين غير قادرة على الوصول إلى بعض بيانات المعاملات على السلسلة ، مثل المبالغ المتضمنة ، ولكن مع OP_CAT ، يمكن إدخال هذه القدرة. بالإضافة إلى ذلك ، يمكن أن يكون OP_CAT حاسمًا في التحقق من دلائل ميركل.

في جوهره، OP_CAT هو ترقية رمز التشغيل منخفض المستوى التي يمكن أن تؤدي إلى مجموعة واسعة من الوظائف الجديدة. لقد أشار العديد من الأشخاص إلى أن OP_CAT قد يكون حاسمًا في تحقيق أهداف مختلفة. السؤال الرئيسي هو ما إذا كان يمكن لـ OP_CAT المساعدة في التحقق من SNARK داخل السكربتات. الجواب هو نعم. نظرًا لأن التحقق من دليل ميركل هو خطوة نحو التحقق من FRI-based SNARKs، فإن OP_CAT سيكون إضافة قيمة. في الماضي، قد تكون السكربتات المصممة للتحقق من SNARK كانت كبيرة للغاية بحيث لا تتناسب مع حدود حجم كتلة بيتكوين، ولكن OP_CAT يمكن أن يساعد في تبسيط هذه السكربتات، مما يجعلها أكثر انضباطًا.

تمت مناقشة OP_CAT لسنوات ، مع زيادة الوعي بدورها المحتمل في استبطان المعاملات. واحدة من مزاياها الرئيسية على المقترحات الأخرى هي أنها كانت ذات يوم جزءا لا يتجزأ من Bitcoin Script ، مما قد يسهل تحقيق إجماع المجتمع. ومع ذلك ، فإن الجانب السلبي هو أن تمكين OP_CAT يمكن أن يؤثر سلبا على أرباح MEV (القيمة القابلة للاستخراج من عمال المناجم) بالنسبة للبعض ، مما أدى إلى نقاش مستمر داخل المجتمع حول إعادة تنشيطه.

في الختام، يمكن أن يتخذ بيتكوين خطوة نحو تمكين التحقق من SNARK في السكربتات من خلال إعادة تقديم أوامر تشفير مباشرة مثل OP_CAT. بالإضافة إلى ذلك، يجدر بالذكر اقتراحًا حديثًا يُسمى "Great Script Restoration"، الذي يُعيد إدخال أمر الضرب ويمكن جميع العمليات الحسابية من القيام بها بدقة تامة.

بالإضافة إلى ذلك، عند تقييم تأثير OP_CAT على شبكة البيتكوين، من المهم أن ننظر إلى تأثيره على مشغلي العقد الذاتي للبيتكوين. من أجل ضمان استمرارية بيتكوين كمقاوم للرقابة ومركزي، تسعى المجتمع لجذب أكبر عدد ممكن من الأشخاص لتشغيل العقد الذاتي للتحقق من العمليات. إذا تم تنفيذ التحقق من SNARK في بيتكوين، فإنه لن يرفع تكلفة تشغيل العقد الذاتي بشكل كبير، وهو ما لن يؤثر بشكل كبير على أمان بيتكوين أو مقاومته للرقابة.

حالياً، يمكن لكتلة البيتكوين أن تحتوي على ما يصل إلى 4 ميجابايت من البيانات، مع تعدين كتل جديدة تقريباً كل 10 دقائق. تمتلئ معظم الكتل بنصوص البيتكوين وبيانات الشاهد (مماثلة للتواقيع الرقمية). في المتوسط، يمكن لكل كتلة أن تستوعب ما بين 7,000 و 10,000 تحقق من التوقيعات، مع حد أقصى يصل إلى حوالي 80,000 تحقق في الكتلة. على سبيل المقارنة، يستغرق معالج إنتل CPU 2020 الخاص بي حوالي 3.2 ثانية للتحقق من كتلة البيتكوين. بشكل طبيعي، سرعة التحقق من الكتلة تتأثر بعوامل تتجاوز مجرد الوقت المستغرق في التحقق من التوقيع.

علاوة على ذلك ، إذا كانت معاملات Bitcoin تدعم في النهاية إثباتات المعرفة الصفرية (ZK) ، فقد لا تكون أي زيادة في وقت إنشاء المعاملات مصدر قلق كبير. عادة ما تحتوي محافظ الأجهزة ، التي تستخدم لتخزين الأصول على المدى الطويل ، على شاشات وتصميمات مدمجة تركز على تخزين المفاتيح وإنشاء التوقيع. عادة ما تتميز هذه المحافظ بوحدات معالجة مركزية منخفضة الطاقة نسبيا ، مثل معالج ثنائي النواة بسرعة 240 ميجاهرتز ، ولكنها تتعامل مع معاملات Bitcoin بكفاءة.

قمت بإجراء استطلاع صغير طلبت فيه من المستخدمين حول أقصى تأخير يمكنهم قبوله لجهاز التوقيع الإلكتروني لإنشاء دليل، وكان كثير من الناس على ما يبدو على استعداد للانتظار لفترة أطول، خاصة إذا كان هناك مكاسب كبيرة يمكن تحقيقها. لذا إذا قمنا بإدخال ZK إلى معاملات بيتكوين، لا يبدو أن هناك الكثير من المشاكل. لقد قضينا وقتًا طويلاً في مناقشة التغييرات المحتملة على التصميم الأساسي لبيتكوين، ولكن هناك العديد من التطبيقات التي يمكن تطويرها دون تغيير بيتكوين نفسه. أحد هذه التطبيقات الجديرة بالذكر هو Chain State Proofs، والتي تتعلق بـ BitVM. تستخدم هذه الطريقة الدلائل على الصفر المعرفة للتحقق من صحة تجزئة الكتل.

ما هو تأثير هذه التكنولوجيا على البيتكوين؟ أولا ، يمكن ل Chain State Proofs أن تقلل بشكل كبير من عبء العمل المتضمن في مزامنة بيانات Bitcoin التاريخية والتحقق منها ، مما يقلل بدوره من تكاليف تشغيل العقدة. حاليا ، تستغرق مزامنة البيانات والتحقق منها من كتلة التكوين إلى أحدث كتلة حوالي 5 ساعات و 30 دقيقة على جهاز متطور ، وعدة أيام على جهاز على مستوى Raspberry Pi. يمكن لبراهين حالة السلسلة تقصير هذه العملية بشكل كبير.

ثانيًا، تلعب دلائل حالة السلسلة دورًا حاسمًا في تقدم BitVM. فريق ZeroSync قام بالبحث بشكل شامل في دلائل حالة السلسلة وطور نسخة مبسطة تسمى "دلائل سلسلة الرؤوس". تستخدم هذه الطريقة دلائل الصفر المعرفة للتحقق من رؤوس كتل بيتكوين، مما يخلق "سلسلة رؤوس" تضم كل 850,000 رأس كتلة في تاريخ بيتكوين. يتم تجزئة كل رأس كتلة لإنتاج دليل بطول 80 بايت. تتطلب هذه الطريقة حسابات SHA-256 المزدوجة لكل رأس للتحقق من العملية الدليلية المرتبطة. يستخدم ZeroSync تقنية STARKs لتوليد هذه الدلائل، مما يتكلف حوالي 4,000 دولار للإنتاج، بينما يستغرق التحقق حوالي 3 ثوان فقط في متصفحي.

ومع ذلك، نظرًا لأن دلائل سلسلة الرؤوس لا تتحقق من المعاملات داخل الكتل، يمكنها فقط أن تفترض أن سلسلة الكتل التي تحتوي على أكبر دليل على العمل (PoW) صالحة والاعتماد على عملاء البيتكوين لمزامنة أحدث الكتل من هذه السلسلة. في هذا الإعداد، يمكن للمهاجم نظريًا إنشاء كتل بمعاملات غير صالحة، وإضافة المزيد من الكتل بعد ذلك، وتوليد دليل سلسلة الرؤوس لضلّل عملاء مزامنة البيانات التاريخية. ومع ذلك، ستكون تكلفة مثل هجوم بشكل محظوري ومرجح أن يتم اكتشافه من قبل عملاء البيتكوين بالكامل الحالية.

ومع ذلك ، على الرغم من أن فرص نجاح مثل هذا الهجوم منخفضة ، إذا كان من الممكن أن يسمح للمهاجمين بسرقة كمية كبيرة من BTC ، فلن تعتبر أدلة سلسلة الرأس حلا آمنا تماما. للتحقق من الحالة الكاملة للسلسلة ، نحتاج إلى التأكد من أن جميع محتويات كتلة Bitcoin صالحة ، بما في ذلك عمليات التحقق من توقيع ECDSA و Schnorr بناء على المنحنى الإهليلجي secp256k1. تحتوي كتل البيتكوين التاريخية على ما يقرب من 30 مليون توقيع كل شهر ، بإجمالي حوالي 2.5 مليار توقيع تاريخيا ، إلى جانب العديد من حسابات SHA-256. نتيجة لذلك ، تولد شبكة Bitcoin حوالي 7 جيجابايت من بيانات الكتلة شهريا ، مع تجاوز البيانات التاريخية 650 جيجابايت - وفي الممارسة العملية ، قد يكون هذا الرقم أعلى من 2 إلى 3 مرات.

الآن، دعونا نلقي نظرة على BitVM. يسمح BitVM لبيتكوين بالتحقق من أي مهمة حسابية، مما يوفر وسيلة مثلى لأداء التحقق SNARK دون تعديل البروتوكول. يتغلب BitVM على قيود حجم سكريبت بيتكوين باستخدام طريقتين. أولاً، يستفيد من هيكل سكريبت Taproot MerkleTree. ثانياً، يستخدم نظام تخزين KV يمكن الوصول إليه عبر سكريبتات فردية، مما ييس faciliting الاتصالات مع عدد كبير من برامج السكريبت. ومع ذلك، لا يفرض بروتوكول بيتكوين سلامة هذا النظام KV للتخزين. يعالج BitVM هذا من خلال استخدام دلائل الغش لاكتشاف المثبتين الخبيثين. إذا قام مثبت بادعاءات غير صالحة أو استخدم تخزين KV معيب، يمكن للآخرين بادئ معاملة على سلسلة كتل بيتكوين للإبلاغ عن سلوك المثبت واستولاء على الأصول المراهن عليها.

في الختام، يواجه بيتكوين تحديات كبيرة، وعلى الرغم من أن مقترحات مختلفة قدمت لمعالجتها، إلا أن الحصول على قبول سريع من مجتمع بيتكوين غير محتمل. التغييرات في البروتوكول ليست قابلة للتحقيق في المدى القصير، مما يعكس قوة وقيود اللامركزية والأمان في بيتكوين. إن إمكانية SNARKs وSTARKs تولد إثارة كبيرة داخل المجتمع. يبدو أن BitVM هو الطريقة الأكثر وعدًا لدمج التحقق من SNARK في المدى المتوسط ​​إلى الطويل، على الرغم من أنه يتطلب مزيدًا من البحث والتطوير ليكون عمليًا بشكل كامل. إعادة تمكين رمز التشغيل OP_CAT هو طريق آخر لاستكشافه، لكنه يحتاج إلى إظهار أن فوائد إعادة التنشيط تتجاوز المخاطر، وتحديد أي رموز تشغيل بسيطة يمكن أن تسهل التحقق من SNARK أو وظائف مماثلة في نصوص بيتكوين. في نهاية المطاف، يهدف مجتمع بيتكوين إلى تعزيز القابلية العملية للتكنولوجيا ودعم حالات الاستخدام الأكثر جدوى أكثر.

اقرأ المحتوى الأصلي هنا: https://www.youtube.com/watch?v=GrSCZmFuy7U

تنصل من المسؤولية:

1. تم نقل هذه المقالة من [ المحترف Web3], جميع حقوق النشر تنتمي إلى المؤلف الأصلي [جيك ويب 3]. إذا كان هناك اعتراضات على هذا النشر المكرر، يرجى التواصل مع بوابة تعلمالفريق، وسيتعاملون معه بسرعة.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك الخاصة بالمؤلف ولا تشكل أي مشورة استثمارية.
3. تتم ترجمة المقالات إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يذكر ، فإن نسخ أو توزيع أو ارتكاب السرقة في المقالات المترجمة محظور.