حل مشكلة الغاز في البيتكوين (بدون هارد فورك) | رأي

كل منصة عقود ذكية تحتوي على أصل رسوم مدمج. على سبيل المثال، إيثريوم (ETH) لديها ETH، سولانا (SOL) لديها SOL، ولكن مع بيتكوين (BTC)، الأمور تصبح أكثر تعقيدًا. إذا كنت تريد تطبيقات تعبيرية، عادةً ما تضطر إلى اعتماد اقتصاد شبكة ثانية.

ملخص

• بيتكوين لا يقيّم الحسابات، بل يقيّم مساحة الكتلة فقط. على عكس إيثريوم أو سولانا، سوق الرسوم في BTC مبني على sat/vB لإدراج المعاملات، وليس قياس تنفيذ العقود الذكية.
• يمكن أن تتم عمليات التنفيذ خارج السلسلة بينما تظل التسوية على بيتكوين. أنظمة مثل OpNet تدير منطق العقود في بيئة Wasm VM مع تأمين المدفوعات والتغييرات النهائية للحالة من خلال معاملات BTC العادية.
• يمكن أن يعمل BTC كأصل للغاز بدون رمز جديد. من خلال تسعير تكاليف التنفيذ بالسواتوشي وتسوية التفاعلات عبر معاملات بيتكوين، تتجنب التطبيقات إنشاء اقتصاد رسوم ثانٍ.

على سبيل المثال، في Stacks، تدفع الرسوم بـ STX. على طبقات بيتكوين المستندة إلى EVM، قد يُقال إن BTC هو رمز الغاز، لكنه عادةً تمثيل أصلي من الطبقة الثانية مع قواعد EVM (بما في ذلك 18 خانة عشرية)، وأنت لا تزال تعمل داخل بيئة تلك الطبقة الثانية. أما بيتكوين نفسه، فله سوق رسوم نظيف حيث يزايد المستخدمون على مساحة الكتلة بالسواتوشي/vB، ويعطي المعدنون الأولوية للرسوم الأعلى.

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

بيتكوين لا يقيس الحسابات (هذه مشكلة)

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

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

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

التنفيذ ليس ما يحتاجه بيتكوين

بمجرد أن تقبل أن سكريبت بيتكوين محدود عمدًا (بدون حالة وليس مصممًا للحساب غير المحدود)، تبدأ في التفكير بكيفية تسوية بيتكوين للنتائج والمدفوعات.

في الواقع، يمكن أن يحدث التنفيذ في آلة افتراضية مخصصة مصممة لتشغيل منطق العقود الذكية بشكل حتمي، بينما يظل بيتكوين الطبقة الأساسية التي تؤرخ وتطلب وترتب التفاعلات من خلال سوق الرسوم الحالية. في تصميم OpNet، يتم تقييم منطق العقد بواسطة بيئة VM موجهة لـ Wasm (OP-VM)، بينما يتم بناء مجموعة العقد بشكل صريح لإدارة وتنفيذ العقود الذكية باستخدام آليات معاملات وUTXO الموجودة في بيتكوين.

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

كيف يبدو استدعاء عقد مدفوع بـ BTC

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

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

• رسوم المعدنين أصلية لبيتكوين. تختار معدل رسوم بالسواتوشي/vB، وتضيف اختيارياً رسوم أولوية بالسواتوشي، وتحدد حدًا أقصى للإنفاق على الرسوم عبر parameter يسمى maximumAllowedSatToSpend.
• هدف العقد يُعبّر عنه كعنوان عقد من نوع P2OP. يعرض عقد الحالة الخاص به تنسيق عنوان p2op، والمعاملات تشير إلى “عنوان عقد p2op” كوجهة للعقد.

وفي الوقت نفسه، لا تزال آلية قياس الحسابات الخاصة بـ OpNet موجودة. لكنها محسوبة بالسواتوشي (تقديرات SATS Gas، استردادات بالسواتوشي، إلخ)، بحيث لا ينحرف الوحدة إلى اقتصاد رمز منفصل.

تقليل الاحتكاك، وتحفيزات أنظف

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

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

بيتكوين كغاز، بدون رمز ثانٍ

الادعاء بأن BTC لا يمكن أن يعمل كغاز غالبًا ما يعتمد على الافتراض أن الطبقة الأساسية يجب أن تقيس الحسابات لتسعيرها. بيتكوين لا يقيس الحسابات؛ هو يقيس مساحة الكتلة ويقوم بالتسوية.

الحل هو أن تسمح لآلة افتراضية بمعالجة التنفيذ بشكل حتمي، ثم تمرر كل تفاعل يغير الحالة عبر معاملة بيتكوين قياسية، حيث تُعبر الرسوم عن طريق مصطلحات مألوفة مثل sat/vB وتُحدد بالسواتوشي. في حالتنا، يتم تنفيذ ذلك على مستوى العميل عبر معلمات مثل feeRate و maximumAllowedSatToSpend.

لذا، ربما يكون BTC كغاز ممكنًا حقًا. تبقى الرسوم أصلية لبيتكوين من البداية للنهاية، بينما يظل تشغيل العقد في بيئة WebAssembly (AssemblyScript → Wasm)، مما يحافظ على التعبيرية دون تغيير عملة الرسوم.

فريدريك فوسكو

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