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

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

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

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

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

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

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

في بيتكوين++ في أوستن في بداية شهر مايو ، قدم مطور Core Lightning Rusty Russell اقتراحا جذريا جدا خلال العرض الأول للمؤتمر. لقد طرح بشكل أساسي فكرة التراجع عن معظم رموز التشغيل التي ساتوشي تعطيلها في عام 2010 قبل اختفائه.

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

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

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

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

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

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

THE OPCODES

• 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: عوامل تشغيل الرياضيات لعمليات الضرب والقسمة والمعامل (إرجاع باقي القسمة).

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

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

WHY WE WANT TO DO THIS

Layer 2s هي بطبيعتها امتداد للطبقة الأساسية بيتكوين، فهي بطبيعتها مقيدة من حيث الوظائف من خلال وظائف الطبقة الأساسية. تطلب Lightning ثلاث سوفت فورك منفصلة ، CHECKLOCKTIMEVERIFY (CLTV) ، CHECKSEQUENCEVERIFY (CSV) ، و الشاهد المنفصل قبل أن يكون من الممكن تنفيذه بالفعل.

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

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

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

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

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

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

كيفية جعل هذا آمنا: VAROPS

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

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

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

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

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

FORWARD MOMENTUM

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

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

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

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

إخلاء المسؤولية:

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