كيفية جعل Bitcoin يدعم ZK: من OP_CAT إلى Proof-of-State وBitVM

المؤلف: يانوس نيك، Blockstream

جمعه: باي Ding& ;Faust, Geek Web3

الملخص:تشير هذه المقالة بإيجاز ولكن في صلب الموضوع إلى كيفية جعل Bitcoin تدعم العملة وظيفة التحقق ZK، وتشمل الموضوعات المحددة التي يتم تناولها العيوب الوظيفية في Bitcoin UTXO والبرامج النصية، والمحتوى العام للمفاهيم مثل Taproot وOP_CAT، وBitVM وChain State Proof. تطرح المقالة وجهة نظر واضحة نسبيًا:

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

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

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

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

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

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

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

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

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

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

2. تحسين إنتاجية المعاملات

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

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

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

ما يجب الإشارة إليه هنا هو أن Bitcoin ليس لديها حالة عالمية مثل Ethereum، خاصة دولة بدون حسابات، فقط بيانات مخرجات المعاملات. مخرجات كل معاملة لها حالتان: تم إنفاقها من قبل المستلم أو غير منفقة. مخرجات المعاملة غير المنفقة هي UTXO المألوفة.

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

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

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

نلخص هنا وظيفة البرنامج النصي للبيتكوين. أولاً، ما الذي يمكن أن يفعله Bitcoin Script؟

• يمكن إعادة ترتيب المكدس والتحقق من المساواة (باستخدام فحوصات المساواة للتحقق من استيفاء شروط محددة، وبالتالي ضمان أمن وصحة المعاملات)، يمكن تنفيذ عمليات التفرع المشابهة لـ if-else.

• يمكن إجراء عمليات حسابية محدودة على أرقام 32 بت، وهي الجمع والطرح.

• يمكن تجزئة البيانات، ويمكن التحقق من توقيعات ECDSA وSchnorr.

ما الذي لا يستطيع Bitcoin Script فعله؟

• لا توجد حلقات أو قفزات أو تكرارات، وهذا يعني إنها ليست تورينج كاملة ولها قدرات برمجة محدودة للغاية.

• لا يمكن تنفيذ العمليات المتعلقة بالبت.

• يفتقر إلى أكواد العمليات الخاصة بالضرب والقسمة.

• لا يمكن توصيل العناصر الموجودة على المكدس.

• لا توجد تقريبًا القدرة على قراءة بيانات المعاملات على السلسلة والتحقق منها. لا يمكن لنصوص Bitcoin الوصول مباشرة إلى مبلغ كل معاملة، ولا توجد طريقة لتمرير الحالة (تُستخدم UTXOs لمرة واحدة، ويتم تدمير القديمة وإنشاء أخرى جديدة مع كل عملية تحويل).

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

إذن، هل يمكن لبرنامج Bitcoin Script التحقق من SNARKs؟ على الرغم من أن نص Bitcoin ليس مكتملًا من الناحية النظرية، إلا أن عملياته الأساسية كافية للتحقق من أي عملية حسابية. ومع ذلك، من الناحية العملية، لا يزال التحقق من SNARK غير قابل للتحقيق لأن حجم البرنامج المطلوب لخطوة التحقق يتجاوز الحد الأقصى لكتلة Bitcoin - 4 ميجابايت .

ربما يمكننا محاولة إجراء عمليات حسابية في حقول محدودة كبيرة، ولكن التكلفة مرتفعة جدًا، مثل ضرب عددين صحيحين 254 بت يتم تنفيذه بواسطة BitVM ذات صلة يصل حجم نص Bitcoin إلى 8 كيلو بايت تقريبًا.

أيضًا، من المكلف أيضًا التحقق من إثبات Merkle بدون OP_CAT، لأنه يتطلب عمليات مشابهة للحلقات.

لذانعود إلى السؤال السابق: لماذا لا يمكننا ببساطة تغيير بروتوكول Bitcoin وإضافة أكواد تشغيل أكثر قوة؟

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

بالطبع،عملة البيتكوين ليست ثابتة تمامًا. آخر التحديثات هي SegWit في عام 2017 وTaproot في عام 2021.

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

علاوة على ذلك، تنقسم تحسينات Taproot للبيتكوين بشكل أساسي إلى الأجزاء الثلاثة التالية:

أولاً ، يقلل Taproot من تكلفة التحقق من البرامج النصية مع عدد كبير من الفروع الانتقائية، مما يسمح لبيتكوين بدعم البرامج الأكثر تعقيدًا؛

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

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

ومع ذلك، نظرًا لأن Bitcoin لديها سابقة في إضافة وظائف أكثر قوة مثل Tarpoot، فلماذا لا تضيف رمز تشغيل مخصصًا للتحقق من SNARK؟ وهذا لأن إضافة ما يسمى بكود التشغيل OP_SNARK يختلف تمامًا عن ترقية Taproot.

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

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

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

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

لذلك، يقوم فريق بحث Blockstream بتطوير Simplicity، وهي لغة برمجة مصممة لتحل محل Bitcoin Script. تم تصميم Simplicity خصيصًا لأنظمة إجماع blockchain وهي ليست مكتملة من خلال Turing عمدًا، مما يجعل من السهل إجراء التحليل الثابت والتحقق الرسمي.

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

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

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

وهل يساعد OP_CAT في التحقق من SNARKs في البرامج النصية؟ الإجابة مفيدة، لأن دعم التحقق من أدلة Merkle يساعد في التحقق من SNARKs المستندة إلى FRI، ويمكن لـ OP_CAT دعم ذلك. في الماضي، ربما كانت البرامج النصية المشاركة في التحقق من SNARK كبيرة جدًا بحيث لا يمكن وضعها في كتلة Bitcoin، باستخدام OP_CAT، يمكن تقليل حجم البرنامج.

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

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

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

في الوقت الحالي، يمكن أن تحتوي كتلة البيتكوين على ما يصل إلى 4 ميجا بايت من البيانات، ومن المتوقع أن يتم تعدين كتلة واحدة كل 10 دقائق، تقريبًا جميعها. يمكن ملء كلا الكتلتين بنصوص Bitcoin وشهود الشهود (على غرار التوقيعات الرقمية). تم حسابه، يمكن أن تحتوي كل كتلة حاليًا على ما يصل إلى 80 ألف عملية تحقق من التوقيع، في المتوسط، تدعم كل كتلة عمليات التحقق من التوقيع من 7 آلاف إلى 10 آلاف، وتستغرق وحدة المعالجة المركزية Intel 2020 الخاصة بي 3.2 ثانية في المتوسط ​​للتحقق من كتلة Bitcoin. وبطبيعة الحال، ليس فقط التحقق من التوقيع الذي يستغرق وقتًا طويلاً هو الذي يؤثر على سرعة التحقق من الكتلة.

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

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

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

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

أجرى فريق ZeroSync بحثًا متعمقًا حول Chain State Proofs وقام بإنشاء "header chain Proofs" خفيف الوزن مع دمج هذا الحل مع ZK. إنه يثبت فقط صحة رأس كتلة البيتكوين، وبالتالي تشكيل "سلسلة رأس" تحتوي على جميع رؤوس الكتل البالغ عددها 850,000 في تاريخ البيتكوين، وتولد تجزئة 80 بايت لكل رأس كتلة.

يتطلب هذا الحل حسابات SHA-256 مزدوجة لكل رأس كتلة Bitcoin للتحقق من إثبات إثبات العمل (PoW) المقابل. يستخدم ZeroSync STARKs لإنشاء إثبات لسلسلة رأس Bitcoin. وتبلغ تكلفة إنشاء الدليل حوالي 4000 دولار، ويستغرق الأمر 3 ثوانٍ فقط للتحقق من الدليل باستخدام متصفحي.

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

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

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

الآن دعونا نلقي نظرة على BitVM. يسمح BitVM لـ Bitcoin بالتحقق من أي مهمة حوسبة وهو أفضل مسار لتحقيق التحقق من SNARK دون تغيير البروتوكول. يستخدم BitVM طريقتين لتجاوز الحد الأقصى لحجم البرنامج النصي لكتلة Bitcoin. أولاً، يستخدم بنية البرنامج النصي Taproot MerkleTree؛

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

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

الكثير من مجتمع Bitcoin متحمسون لإمكانيات SNARK/STARK. الطريقة الأكثر جدوى لتحقيق التحقق من SNARK على المدى المتوسط ​​إلى الطويل هي على الأرجح BitVM، ولكنها تتطلب المزيد من الاستثمار في البحث والتطوير لتكون فعالة في الممارسة العملية؛

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

الرابط الأصلي: https://www.youtube.com/watch?v=GrSCZmFuy7U< / ع>