المؤلف الأصلي: شينوبي

التجميع الأصلي: كتلة يونيكورن

على الرغم من نطاق الاقتراح ، ما هو السبب في أن "استعادة النص العظيم" لرستي راسل يمكن أن تكون الطريق إلى الأمام لتطوير بيتكوين؟

كتلة يونيكورن ملاحظة: راستي راسل مطور نشط في مجتمع بيتكوين ويحظى باحترام كبير في المجتمع. لقد عمل على نطاق واسع في تطوير نواة Linux وشارك في العديد من مشاريع التطوير الأساسية طويل بيتكوين.

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

"جوهر بيتكوين هو أنه بمجرد إصدار الإصدار 0.1 ، يتم تحديد التصميم الأساسي لبقية دورة الحياة. لذلك ، أردت تصميمه الدعم كل نوع تداول ممكن يمكن أن أفكر فيه. المشكلة هي أن كل شيء يتطلب رموز الدعم خاصة وحقول بيانات ، سواء تم استخدامها أم لا ، مما يؤدي إلى أطول حالات خاصة. الحل هو برنامج نصي يعمم المشكلة حتى يتمكن الطرفان من وصف معاملاتهما بشروط محددة تقوم شبكة العقدة بتقييمها أو التحقق من صحتها بناء على تلك الشروط ". - ساتوشي ناكاموتو ، 17 يونيو 2010

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

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

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

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

استعادة البرنامج النصي كبيرة

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

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

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

على سبيل المثال ، ANYPREVOUT (APO) هو اقتراح يسمح بإعادة استخدام التوقيعات في معاملات مختلفة ، طويل أن البرنامج النصي والمبلغ الذي تم إدخاله متماثلان ، وهذا الاقتراح مصمم خصيصا لتحسين شبكة الإضاءة وإصداراته أطول. CHECKTEMPLATEVERIFY (CTV) هو اقتراح يتطلب إنفاق العملات الورقية فقط من خلال المعاملات التي تتطابق تماما مع المعاملات المحددة مسبقا ، وقد تم تصميم هذا الاقتراح لتوسيع وظائف سلاسل المعاملات الموقعة مسبقا بجعلها غير موثوقة تماما. تم تصميم OP_VAULT خصيصا لتعيين "مهلة" لحل التخزين البارد ، بحيث يمكن للمستخدمين "إلغاء جلبه" من التخزين البارد عن طريق إرساله إلى إعدادات طويل أكثر برودة لمنع تعرض المفتاح السري للخطر.

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

لا أحد غير مقدم الاقتراح يعتقد أن أي اقتراح شامل بما يكفي لاعتباره خطوة تالية معقولة.

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

رموز العمليات (رمز العملية)

• OP_CAT: يأخذ قطعتين من البيانات من المكدس ويجمعهما معا لتشكيل بيانات واحدة.
• OP_SUBSTR: اقبل معلمة طول (بالبايت) ، واحصل على جزء من البيانات من المكدس ، وقم بإزالة البايتات بهذا الطول ووضعها مرة أخرى على المكدس.
• OP_LEFT و OP_RIGHT: يقبل معلمة طول تأخذ جزءا من البيانات من المكدس وتزيل وحدات البايت من الطول المحدد من جانب أو آخر.
• OP_INVERT و OP_AND و OP_OR و OP_XOR و OP_UPSHIFT و OP_DOWNSHIFT: يقبل عنصر بيانات وينفذ عمليات البت المقابلة عليه.
• OP_ 2 MUL و OP_2D IV و OP_MUL و OP_DIV و OP_MOD: عوامل تشغيل الرياضيات لعمليات الضرب والقسمة والمعيارية (إرجاع باقي القسمة).

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

OP_CTV (أو TXHASH / ما يعادله رمز العملية): يسمح بالتنفيذ الدقيق لأجزاء معينة من المعاملة التي يجب أن تكون محددة مسبقا تماما.

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

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

لماذا نفعل هذا

الشبكات طبقة 2 هي في الأساس امتدادات للطبقة الأساسية ل بيتكوين ، وهي مقيدة وظيفيا بوظائف الطبقة الأساسية. يتطلب شبكة الإضاءة ثلاث سوفت فورك منفصلة قبل أن يتم تنفيذها بالفعل: CHECKLOCKTIMEVERIFY (CLTV) و checksequenceverify (csv) و SegWit (الشاهد المنفصل).

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

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

من منظور أعلى ، هذا ما نحتاجه:

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

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

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

كيف تكون آمنا: VAROPS كما قلت أعلاه ، فإن سبب تعطيل جميع رموز التشغيل هذه هو معالجة هجمات DOS (التي تتسبب في تعطل الشبكة عن طريق إرسال عدد كبير من طلبات البريد العشوائي) ، والتي يمكن أن تتسبب في تعطل العقد التي تشكل الشبكة. تتمثل إحدى طرق حل هذه المشكلة في الحد من كمية الموارد التي يمكن استخدامها بواسطة أي من رموز التشغيل هذه.

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

Taproot يغير طريقة العمل هذه ، ولا أطول استخدام حد كتلة عالمي واحد ، ولكن بدلا من ذلك ، يكون لكل معاملة حد sigops (عملية التوقيع) الخاص بها ، بما يتناسب مع حجم المعاملة. هذا يساوي بشكل أساسي نفس الحد العالمي ، ولكن من الأسهل أن نفهم أن كل معاملة لديها طويل أقل من sigops المتاحة.

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

سيؤدي ذلك إلى حل هجوم DOS (عن طريق إرسال الكثير من طلبات البريد العشوائي ، مما يتسبب في تعطل الشبكة) بسبب معاملات البريد العشوائي هذه ، وما الذي تسبب في قيام ساتوشي ناكاموتو في البداية بتعطيل جميع رموز التشغيل هذه.

الزخم للمضي قدما

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

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

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

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