بروتوكول ملف CSV المحمي 🛡️

مقدمة

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

في ورقتنا الصادرة حديثًا، قامت Blockstream بالتعاون مع Alpen Labs و ZeroSync بتقديم بروتوكول CSV المحمي، وهو تحسين على التحقق من الجانب العميل (CSV) الذي يقدم معاملات خاصة حقًا. هذا البروتوكول الجديد هو خطوة هامة نحو تعزيز خصوصية معاملات بيتكوين وله القدرة على زيادة سعة المعاملات من 11 في الثانية إلى أكثر من 100 في الثانية، من خلال بعض التدابير الإضافية التي سنغطيها في هذا المنشور على المدونة.

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

بيتكوين ثم والآن

مشكلة الاستثمار المزدوج: كيف حلت بيتكوين ذلك

قبل Bitcoin ، كان يعتقد على نطاق واسع أن إنشاء عملة رقمية موثوقة كان مستحيلا بدون وسيط موثوق به. تعني مشكلة الإنفاق المزدوج أنه لا توجد طريقة لضمان عدم إمكانية إنفاق “عملة رقمية” أكثر من مرة. لقد كان عيبا أساسيا منع العملة الرقمية من أن تصبح حقيقة واقعة.

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

عندما يتم إضافة عملية بيتكوين إلى السلسلة ، يتبع هذه العملية:

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

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

غرض الدفتر هو الاحتفاظ بالمعاملات في الطلب01928374656574839201، مما يجعل من الواضح من يمتلك أي عملات ومتى تم إرسالها.

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

مشكلة الخصوصية: المعاملات العامة

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

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

وفي الرد، قد قدمت بروتوكولات موجهة نحو الخصوصية مثل Zcash طرقًا جديدة لإخفاء تفاصيل المعاملات باستخدام تشفير متقدم أكثر وأشياء مثل zk-SNARKs. ولكن هذه الطرق تأتي مع تنازلات كبيرة: المعاملات أكبر حجمًا، مما يجعل عملية التحقق للعقد أكثر استهلاكًا للموارد وتكلفة للتحقق.

مشكلة اتصال: الاتصال غير كفء

في تصميم بيتكوين، يخدم التعدين غرضين أساسيين: (1) إثبات النشر للمعاملات و (2) توفير توافق بشأن الطلبات للمعاملات. ومع ذلك، يشابك بيتكوين أيضًا هذه الوظائف الأساسية مع مهام أقل أهمية، مثل التحقق من المعاملات وإصدار العملة.

عبر جميع سلاسل الكتل ، سواء كان الأمر يتعلق ببيتكوين، إثيريوم، Zcash، أو Dogecoin، يبدو عملية العملية دائمًا نفسها: توقيع المحافظ على العمليات، وبثها إلى الشبكة، والقيام بالتحقق منها من قبل العقد الكاملة. لكن هل يتعين فعلا التحقق من كل عملية مباشرة على سلسلة الكتل؟

نحن نعتقد أن هناك طريقة أفضل. تعود الفكرة إلى رؤية في عام 2013، عندما ذكر بيتر تود أول مرة التحقق من الجانب العميل. في هذا المنشور البريدي الذي يطلب القائمة، يسأل، ‘بمراعاة الإثبات فقط للنشر، والاتفاق على الطلبات من المعاملات، هل يمكننا جعل عملة معماة ناجحة؟ بشكل مدهش، الإجابة هي نعم!’

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

CSV: حل التحجيم الند للند

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

عندما يتعين على كل عقدة التحقق من كل معاملة، فإنه يزدحم الشبكة ويبطئها. عن طريق نقل التحقق من المعاملات إلى الجانب العميل، يمكن تقليل كمية البيانات المخزنة على سلسلة الكتل بشكل كبير - من 560 وحدة وزن (WU) في المتوسط إلى شيء يقترب من 64 WU، مما يجعلها أكثر نحافة وكفاءة بنسبة 8.75 مرة تقريبًا.

بروتوكول الامتثال يمنح بيتكوين زيادة هائلة في قابلية التوسع، مما يتيح للمستخدمين معالجة ما يقرب من 10 مرات أكثر من المعاملات - قرابة 100 في الثانية.

بيتكوين غداً

ربما تفكر، “هذا يبدو رائعًا، لكن كيف يعمل هذا في الواقع، وما هي التنازلات هنا؟”

كيف يجعل بيتكوين المحمية CSV أكثر خصوصية؟

تعمل بروتوكولات CSV بشكل عام على تحسين الخصوصية عبر معاملات blockchain الشفافة لأنه يتم نقل بعض المعلومات من جانب العميل. ولكن في بروتوكولات CSV التقليدية مثل RGB و Taproot Assets ، عند إرسال عملة ، يمكن لكل من المرسل والمستلم عرض سجل المعاملات الكامل.

في Shielded CSV، نستخدم مخططات مشابهة لـ zk-SNARK لـ “ضغط” البراهين، مضمنًا عدم تسرب معلومات المعاملات. هذا يعني أن تاريخ المعاملات يظل مخفيًا، مما يوفر خصوصية أفضل مقارنة بالبروتوكولات الحالية.

ما هو الألغام، وكيف يمنع الإنفاق المزدوج؟

عند إجراء الدفع، يسلم الراسل المعاملة مباشرة إلى المستلم. يتم كتابة قطعة صغيرة من البيانات المستمدة من المعاملة إلى البلوكشين وتسمى العازل.

العقد الكاملة في الشبكة لا تحتاج إلى أداء عملية واحدة فقط للتحقق من التوقيع Schnorr لكل nullifier عملة Shielded CSV. يقوم المستلم بالتحقق من صحة العملة والتأكد من أن ال nullifier موجود في سلسلة الكتل لمنع أي عملية إنفاق مزدوجة.

البروتوكولات الأخرى لـ CSV لديها مُبطّلات أيضًا، ولكن في كثير من الحالات يتعلق الأمر بمعاملات بيتكوين كاملة، وليس بـ “كتل عشوائية” مشتقة كما هو الحال هنا. تجعل مُبطّلات CSV المدعومة من الدروع صعبًا تحليل السلسلة الزمنية.

هل يتطلب Shielded CSV شوكة ناعمة أم هارد فورك؟

CSV المحمي لا يتطلب فورك ناعم أو صلب. إنه يعمل مع بيتكوين كما هو. يفصل CSV تحقق المعاملات عن قواعد الاتفاق، مما يتيح المرونة دون تغيير بروتوكول النواة. نظرًا لأن كتل بيتكوين يمكن أن تخزن أي نوع من البيانات، يمكن لبروتوكولات CSV المحمية المختلفة مثل RGB، وأصول تابروت، أو الإصدارات المتعددة لـ CSV المحمية أن تتعايش دون تضارب.

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

هل يسمح لي Shielded CSV بالتعامل في بيتكوين؟

يعمل Shielded CSV ككيان منفصل ، باستخدام سلسلة بيتكوين لتسجيل المحوّلات ومنع الإنفاق المزدوج داخل بروتوكول CSV. ولكن لكي تتمكن من دمجها مباشرة مع بيتكوين والسماح بالمعاملات بسلاسة ، ما زالت هناك حاجة إلى حل جسري. لا يتطرق البروتوكول الحالي بشكل عميق إلى كيفية عمل الجسر مع BitVM ، ولكن هذا المجال لا يزال قيد البحث النشط.

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

اقرأ الورقة الكاملة

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

هذا مشاركة ضيف من كيارا بيكرز. الآراء المعبر عنها هي تماما شخصيتهم الخاصة وليست بالضرورة تعكس تلك التي لدى BTC Inc أو مجلة بيتكوين.