انغمس في Move ، لغة برمجة Libra Blockchain على Facebook

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

مقدمة

Move هي لغة رموز ثنائية قابلة للتنفيذ تُستخدم لتنفيذ معاملات المستخدم والعقود الذكية. انتبه إلى نقطتين:

1. في حين أن Move هي لغة بايت كود يمكن تنفيذها مباشرة على الجهاز الظاهري Move، فإن Solidity (لغة العقد الذكية في Ethereum) هي لغة ذات مستوى أعلى يتم تجميعها أولاً في كود بايت قبل التنفيذ في EVM (جهاز Ethereum الظاهري).
2. يمكن استخدام Move ليس فقط لتنفيذ العقود الذكية، ولكن أيضًا لمعاملات المستخدم (سنتحدث عن هذا لاحقًا)، في حين أن Solidity هي لغة العقود الذكية فقط.

تمت الترجمة من قبل فريق مشروع بروتوكول INDEX. لقد قمنا بالترجمة من قبل مادة رائعة تصف مشروع الميزان، حان الوقت الآن لإلقاء نظرة فاحصة على لغة الحركة. تمت الترجمة مع الحارس com.coolsiu

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

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

تمثيل الأصول الرقمية في الأنظمة المفتوحة

هناك خاصيتان للأصول المادية يصعب تمثيلهما رقميًا:

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

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

ولتوضيح كيف وصلنا إلى هاتين الخاصيتين، لنبدأ بالجمل التالية:

الاقتراح رقم 1: أبسط قاعدة دون الندرة والتحكم في الوصول

• ز[ك]:=ن يدل على تحديث رقم يمكن الوصول إليه عن طريق المفتاح К في الحالة العالمية لسلسلة الكتل، بمعنى جديد n.
• معاملة ⟨أليس، 100⟩ يعني ضبط رصيد حساب أليس على 100.

الحل أعلاه لديه العديد من المشاكل الخطيرة:

• يمكن لأليس الحصول على عدد غير محدود من العملات المعدنية ببساطة عن طريق الإرسال معاملة ⟨أليس، 100⟩.
• العملات المعدنية التي ترسلها أليس إلى بوب لا قيمة لها، حيث يمكن لبوب أن يرسل لنفسه عددًا غير محدود من العملات المعدنية باستخدام نفس التقنية.

الاقتراح رقم 2: مراعاة العجز

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

الاقتراح رقم 3: الجمع بين الندرة والتحكم في الوصول

نحن نحل هذه المشكلة باستخدام آلية التوقيع الرقمي Verify_sig قبل التحقق من الرصيد، مما يعني أن أليس تستخدم مفتاحها الخاص لتوقيع المعاملة والتأكد من أنها مالكة عملاتها المعدنية.

لغات برمجة البلوكشين

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

التمثيل غير المباشر للأصول. يتم ترميز الأصل باستخدام عدد صحيح ، ولكن القيمة الصحيحة ليست هي نفسها الأصل. في الواقع ، لا يوجد نوع أو قيمة تمثل bitcoin / ether / <Any Coin>! هذا يجعل كتابة البرامج التي تستخدم الأصول صعبة وعرضة للخطأ. تتطلب الأنماط مثل نقل الأصول إلى / من الإجراءات أو تخزين الأصول في الهياكل دعمًا خاصًا من اللغة.

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

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

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

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

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

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

نقل أساسيات تصميم اللغة

موارد الطلب الأول

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

مرونة

يضيف Move المرونة إلى الميزان من خلال البرمجة النصية. تتضمن كل معاملة في Libra برنامجًا نصيًا ، وهو في الواقع الإجراء الرئيسي للمعاملة. يمكن للبرنامج النصي إما تنفيذ إجراء واحد محدد ، على سبيل المثال ، إجراء مدفوعات لقائمة محددة من المستلمين ، أو إعادة استخدام موارد أخرى ، على سبيل المثال ، من خلال استدعاء إجراء يحدد المنطق المشترك. هذا هو السبب في أن نصوص المعاملات Move تقدم قدرًا كبيرًا من المرونة. يمكن أن يستخدم البرنامج النصي كلاً من السلوكيات لمرة واحدة والسلوكيات المتكررة ، بينما يمكن لـ Ethereum فقط تنفيذ البرامج النصية المتكررة (استدعاء طريقة عقد ذكي واحد). سبب تسميته "مكرر" هو أنه يمكن تنفيذ وظائف العقد الذكي عدة مرات. (ملحوظة: هنا اللحظة دقيقة للغاية. من ناحية أخرى ، هناك نصوص معاملات في شكل pseudo-bytecode في Bitcoin. من ناحية أخرى ، كما أفهمها ، توسع Move هذه اللغة ، في الواقع ، إلى مستوى لغة عقد ذكية كاملة).

أمن

تنسيق النقل القابل للتنفيذ هو رمز بايت ، وهو ، من ناحية ، لغة ذات مستوى أعلى من لغة المجمّع ، ولكنها ذات مستوى أقل من كود المصدر. يتم التحقق من الرمز الثانوي في وقت التشغيل (على السلسلة) من أجل الموارد والأنواع وسلامة الذاكرة باستخدام مدقق الرمز الثنائي ثم يتم تنفيذه بواسطة المترجم الفوري. يسمح هذا الأسلوب لـ Move بتوفير أمان الكود المصدري ، ولكن بدون عملية التجميع والحاجة إلى إضافة مترجم إلى النظام. إن جعل لغة Move a bytecode فكرة جيدة حقًا. لا يلزم تجميعها من المصدر ، كما في حالة Solidity ، لا داعي للقلق بشأن الفشل أو الهجمات المحتملة على البنية التحتية للمترجم.

إمكانية التحقق

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

نمطية

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

نقل المراجعة

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

المدفوعات من نظير إلى نظير

سيتم تحويل عدد العملات المحددة بالمبلغ من رصيد المرسل إلى المستلم.
هناك عدة نقاط جديدة هنا (مظللة بالنقوش الحمراء):

• 0x0: عنوان الحساب الذي تم تخزين الوحدة فيه
• العملة: اسم وحدة
• عملة: نوع المورد
• قيمة العملة التي يتم إرجاعها بواسطة الإجراء هي قيمة مورد نوعها هو 0x0.Currency.Coin
• يتحرك(): لا يمكن استخدام القيمة مرة أخرى
• نسخة (): يمكن استخدام القيمة لاحقًا

دعونا نلقي نظرة على الكود: في الخطوة الأولى، يقوم المرسل باستدعاء إجراء اسمه draw_from_sender من الوحدة النمطية المخزنة في 0x0.العملة. في الخطوة الثانية ، يقوم المرسل بتحويل الأموال إلى المستلم عن طريق نقل قيمة مورد العملة إلى إجراء إيداع الوحدة النمطية 0x0.العملة.

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

إعادة استخدام الأموال عن طريق التحديد تحرك (عملة) مرتين . مضيفا خط 0x0.Currency.deposit (نسخ (some_other_payee) ، نقل (عملة)) المثال أعلاه سيسمح للمرسل "بإنفاق" العملات المعدنية مرتين - المرة الأولى مع المستفيد ، والمرة الثانية مع بعض_الدفع_الآخر. هذا سلوك غير مرغوب فيه غير ممكن مع الأصل المادي. لحسن الحظ ، سترفض Move هذا البرنامج.

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

وحدة العملة

يمكن أن يحتوي كل حساب على 0 أو أكثر من الوحدات النمطية (كما هو موضح في المربعات) وقيم مورد واحد أو أكثر (موضحة على شكل أسطوانات). على سبيل المثال ، حساب في 0x0 يحتوي على وحدة 0x0.العملة وقيمة مورد من النوع 0x0.Currency.Coin. الحساب في العنوان 0x1 له مواردان ووحدة واحدة ؛ الحساب في العنوان 0x2 يحتوي على وحدتين وقيمة مورد واحد.

بعض اللحظات:

• البرنامج النصي للمعاملة هو ذري - إما تم تنفيذه بالكامل أو لا يتم تنفيذه على الإطلاق.
• الوحدة النمطية هي جزء طويل من التعليمات البرمجية متاح عالميًا.
• يتم تنظيم الحالة العالمية كجدول تجزئة ، حيث يكون عنوان الحساب هو المفتاح
• لا يمكن أن تحتوي الحسابات على أكثر من قيمة مورد واحدة من نوع معين ولا يمكن أن تحتوي على أكثر من وحدة واحدة باسم معين (حساب في 0x0 لا يمكن أن تحتوي على مورد إضافي 0x0.Currency.Coin أو وحدة أخرى مسماة العملة)
• عنوان الوحدة المعلنة هو جزء من النوع (0x0.Currency.Coin и 0x1.Currency.Coin هي أنواع منفصلة لا يمكن استخدامها بالتبادل)
• يمكن للمبرمجين تخزين مثيلات متعددة لنوع مورد معين في حساب عن طريق تحديد موردهم المخصص - (مورد TwoCoins {c1: 0x0.Currency.Coin ، c2: 0x0.Currency.Coin})
• يمكنك الرجوع إلى مورد باسمه دون تعارض ، على سبيل المثال يمكنك الرجوع إلى مصدرين باستخدام TwoCoins.c1 и TwoCoins.c2.

بيان موارد العملة

الوحدة المسماة العملة ونوع المورد المسمى عملة

بعض اللحظات:

• عملة هي بنية ذات مجال واحد من النوع u64 (عدد صحيح بدون إشارة 64 بت)
• إجراءات الوحدة فقط العملة يمكن أن تخلق أو تدمر قيم من النوع عملة.
• يمكن للوحدات والنصوص الأخرى كتابة حقل القيمة أو الرجوع إليه فقط من خلال الإجراءات العامة التي توفرها الوحدة النمطية.

تنفيذ الوديعة

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

1. إتلاف مصدر الإدخال عملة وكتابة قيمتها.
2. الحصول على رابط إلى مورد Coin فريد مخزن على حساب المستلم.
3. تغيير قيمة عدد العملات بالقيمة التي تم تمريرها في المعلمة عند استدعاء الإجراء.

بعض اللحظات:

• فك ، BorrowGlobal - إجراءات مدمجة
• أفرغ هذه هي الطريقة الوحيدة لحذف مورد من النوع T. يأخذ الإجراء موردًا كمدخل ، ويدمره ، ويعيد القيمة المرتبطة بحقول المورد.
• استعارة العالمية يأخذ العنوان كمدخل ويعيد مرجعًا إلى المثيل الفريد لـ T المنشور (المملوك) بواسطة هذا العنوان
• & mut Coin هذا رابط لمورد عملة

تنفيذ pull_from_sender

هذا الإجراء:

1. يحصل على ارتباط إلى مورد فريد عملةالمرتبط بحساب المرسل
2. يقلل من قيمة المورد عملة بالرجوع إلى المبلغ المحدد
3. ينشئ ويعيد موردا جديدا عملة مع رصيد محدث.

بعض اللحظات:

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

اختتام

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

المصدر: www.habr.com