الوظائف والأصول في بروتوكول الطرح

المؤلف: 0xKJ | PoW 2.0 المصدر: X, @kernel1983< /p>

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

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

p>

النقش مقابل بيانات المكالمات

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

تصميم بروتوكول الطرح، في محاولة لإصلاح ذلك، نقوم بدمج العناصر الأساسية في لغة البرمجة، والوظيفة، ومفهوم أصول العنصر الأساسي في blockchain كن مستقلاً. في العقد الذكي، يتعامل كود العقد مع أصول العقد، بينما في بروتوكول الطرح، تتمتع الوظيفة بسلطة تشغيل الأصل. على سبيل المثال، يتمتع النقل بالإذن لتشغيل جميع الأصول، مما يلغي حاجة الأشخاص إلى إعادة كتابة جميع التعليمات البرمجية لكل أصل. بالنسبة لطريقة النعناع، ​​هناك حاجة إلى حرية تعريف أعلى، ويختلف منطق النعناع لأصول meme بالضرورة عن منطق أصول USDT، ويجب كتابة دالة [asset]_mint محددة.

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

النقطة الثالثة، لقد أحببنا دائمًا فكرة ERC6551، ولكن نظرًا لأن 6551 ظهر بعد ERC20، فلا يمكن لجميع ERC20 ربط الأصول معًا. يمكن استخدام NFTs فقط التي تحتفظ بها عناوين Ethereum. العنوان يشبه المفتاح العام، الذي يرتبط بالمفتاح الخاص واحدًا لواحد. لنفترض أنني أشك في أن مفتاحي الخاص لم يعد آمنًا، فعند محاولة تغيير المفتاح الخاص، فهذا يعني أنه يجب تغيير العنوان (اسم المستخدم) في نفس الوقت. لتغيير العناوين على إيثريوم، يحتاج المستخدمون إلى نقل جميع الأصول إلى العنوان الجديد، الأمر الذي يتطلب رسوم غاز كبيرة. لذلك، نعتقد أن التكلفة الأمنية التي سيتحملها المستخدمون لتغيير مفاتيحهم الخاصة ستكون مرتفعة للغاية.

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

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

من المتوقع تشغيله بعد الاختبار في المستقبل القريب! ابقوا متابعين.