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

مذكرة حصان الكتلة: راستي راسل هو مطوّر نشط في مجتمع بيتكوين ويحظى باحترام كبير داخله. لقد قدم مساهمات ملحوظة في تطوير نواة لينكس وشارك في مشاريع تطوير بيتكوين كور المختلفة.

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

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

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

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

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

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

استرداد البرنامج العظيم

في مؤتمر Bitcoin++ في أوستن في أوائل مايو، قدم المطور الأساسي لشبكة Lightning Network، راستي راسل، اقتراحًا جدًا جذريًا في حديثه الأول في المؤتمر، حيث اقترح بشكل أساسي إعادة تمكين معظم أوب كودات تم تعطيلها من قبل ساتوشي ناكاموتو قبل اختفائه في عام 2010.

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

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

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

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

بالإضافة إلى المقترحين، لا أحد يعتقد أن أي مقترح شامل بما يكفي ليُعتبر خطوة معقولة تالية.

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

أكواد العمليات (Operation Codes)

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

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

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

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

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

لماذا نفعل ذلك؟

شبكات الطبقة 2 هي في الأساس تمديدات لطبقة بيتكوين الأساسية، وهي مقيدة بوظائف الطبقة الأساسية. قبل أن يمكن تنفيذ شبكة البرق، كان هناك حاجة إلى ثلاثة فروقات ناعمة منفصلة: التحقق من وقت الإقفال (CLTV)، التحقق من التسلسل (CSV)، والشاهد المنفصل (SegWit).

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

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

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

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

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

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

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

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

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

القوة الدافعة إلى الأمام

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

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

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

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

بيان:

1. This article originally titled “伟大的脚本恢复：比特币的前进之路” is reproduced from [كتلة حصان وحيد]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [SHINOBI]. إذا كان لديك أي اعتراض على إعادة النشر، يرجى التواصل مع بوابة تعلمالفريق، سيتولى الفريق ذلك في أقرب وقت ممكن.

2. تنويه: الآراء والآراء الواردة في هذه المقالة تمثل وجهات نظر الكاتب فقط ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.