مقابلة مع والد لغة Move: لماذا تعتبر لغة العقود الذكية Sui Move مناسبة لبناء منتجات Web3؟
مؤخراً، أجرينا محادثة مع سام بلاكشيار، المدير الفني لشركة ميسن لابز ومؤسس لغة البرمجة موف، حيث ناقشنا سبب تطويره للغة البرمجة الجديدة للعقود الذكية Sui Move، والقدرات القابلة للتوسع التي يمكن أن تقدمها Sui، وفوائد التكنولوجيا اللامركزية للبناة.
فيما يلي محتوى هذه المقابلة:
السؤال 1: أولاً، هل يمكنك تلخيص ما هي لغات البرمجة، وما هي الصفات التي يهتم بها المطورون أكثر عند اختيار لغة البرمجة، وما الذي دفعك لتطوير لغتك البرمجية الخاصة؟
تعتبر لغات البرمجة أداة للتفاعل الودي والآمن والفعال والواضح مع الكمبيوتر. وهذا أمر مهم بشكل خاص بالنسبة للكمبيوتر. لا يمكننا التواصل مع الكمبيوتر باستخدام اللغة الطبيعية، لأن المعنى الكامل للغة الطبيعية يتمثل في ثرائها وقدرتها التعبيرية.
في لغات البرمجة، من الأهم أن تكون لديك دلالة محددة بدقة. عندما تكتب برنامجًا، تكون واضحًا بشأن ما سيفعله. إذا أجريت تعديلات طفيفة عليه، فأنت تعرف ما ستكون نتائج هذا التغيير.
أعتقد أن طبيعة لغات البرمجة، بخلاف اللغات الطبيعية، تستهدف مجالًا معينًا أو مهمة معينة. وإلا، فسيكون من الممكن استخدام لغة برمجة واحدة لإنجاز جميع المهام. لكن وجود عدة لغات برمجة هو لأنك لا تستطيع التميز في جميع المجالات. إنهم يحاولون تحديد أهداف معينة لمجالات مشاكل محددة، ويركزون على حل هذه المشكلات.
لذلك، فإن قصة Move مشابهة جدًا لهذا. عندما أنشأته، لم يكن الهدف هو إنشاء لغة جديدة. يسأل المطورون عند اختيار لغة: "هل هذه اللغة مناسبة للمهام التي أريد إنجازها؟" لكنني أعتقد أن ما هو أكثر أهمية قد يكون: "هل لهذه اللغة مجتمع كبير؟ هل هناك العديد من قواعد البيانات المتاحة؟ هل هناك العديد من المبرمجين الذين يستخدمونها؟ هل هناك موارد تعليمية جيدة؟" كل هذه الأمور مهمة للغاية، لذا يجب أن تكون عتبة إنشاء لغة جديدة عالية جدًا.
Q2، هل يمكنك مشاركة المزيد عن حالة تطوير Move؟
نشأت Move من مشروع Libra الخاص بفيسبوك. لم تكن مهمتي في ذلك الوقت هي إنشاء لغة جديدة، بل كانت "يحتاج Libra إلى عقود ذكية، لذا اكتشف ما ينبغي علينا فعله." نظرت إلى مجموعة متنوعة من الأشياء. هل يمكننا استخدام Solidity في EVM؟ هل ينبغي علينا استخدام لغة عامة تقليدية، مثل WASM أو JVM، واستخدامها لـ Libra؟ أم ينبغي علينا إنشاء شيء خاص بنا؟
إن قرار إنشاء شيء خاص بنا يعتمد على دراسة العقود الذكية الحالية، وفهم ما يحاول المبرمجون القيام به، بالإضافة إلى الأماكن التي تساعدهم فيها بعض اللغات والأماكن التي تخيب آمالهم. خلاصة القول، في كثير من الحالات، فإن لغات العقود الذكية الحالية تخيب آمالهم بالفعل.
يمكن رؤية هذه النقطة بوضوح من السجل السيئ للأمان في Solidity، ولكن الأهم من ذلك، أن هذه العقود الذكية ليست نوع البرامج التقليدية جدًا. Solidity ليست لغة تم بناؤها للأشياء التي يقوم بها الناس الآن.
لذلك فإن هذه العقود الذكية بسيطة للغاية، فهي تقوم بشكل أساسي بشيئين. إنها تحدد نوع الأصول، بما في ذلك متى يمكن نقل الأصول، وما يمكنك فعله بها، ومن يمكنه قراءتها، ومن يمكنه كتابة قواعدها. وتتحقق من سياسات التحكم في الوصول، لتحديد من يمتلك الأصل، ومن يُسمح له باستخدامه، ومن يُسمح له بالتعامل معه. كل شيء يدور حول الأصول، أنت ترغب في أن تمتلك هذه الأصول الخصائص نفسها التي تمتلكها الأصول المادية.
تحتوي العقود الذكية على مفهوم الملكية ونقل الملكية، ولكن على الكمبيوتر، كل شيء مجرد أرقام وبتات، ويمكن نسخه بحرية. وأنت تعلم، أن هذه المفاهيم غير موجودة في العالم الحقيقي. لذلك، أنت تأمل أن تكون هناك لغة يمكن أن تقدم لك تجريدًا جيدًا حول الملكية والتجانس. تمامًا كما في العالم الحقيقي، ولكن دون الحاجة لإجبار المبرمجين على إعادة اختراعه. أنت تأمل في الحصول على ضمانات أمان أساسية.
هذه هي وظيفة Move ولماذا أنشأنا في النهاية هذه اللغة الجديدة. هذه المهام أساسية لبرمجة العقود الذكية. من الصعب إعادة إنشائها في لغات أخرى، بما في ذلك لغات العقود الذكية الحالية، ونرغب في تصميم لغة كاملة حول توفير هذه الوظائف الأساسية حتى يتمكن المبرمجون من كتابة الكود بأمان وكفاءة دون الحاجة إلى اختراع العجلات في كل مرة يفكرون فيها في كتابة بعض الأكواد.
Q3، استخدمت Sui نوعًا معدلاً من Move يسمى Sui Move. ما الذي دفع لهذه التغييرات؟ ما هي الخصائص في Sui Move التي تجعلها مناسبة جدًا لبناء المنتجات في Web3؟
تسببت بعض العوامل في هذه التغييرات، أحدها هو أن الهدف الأصلي لمشروع ليبرا كان بناء شبكة دفع متوافقة. لذلك، حاولنا تصميم Move كلغة عالمية. ولكننا قمنا بوعي ببعض الأمور، لأن ليبرا كانت تأمل في وجود قيود. واحدة من الأمور المهمة هي أنهم لم يرغبوا في أن يتمكن الناس من إرسال أصول معينة إلى أي مكان. كانوا يريدون من الناس إنشاء حساب بشكل واضح، وتحديد بعض القواعد عند إنشاء الحساب، مثل ضرورة إجراء مالك الحساب لعملية KYC. أو قد يحتاجون إلى دفع رسوم لإنشاء الحساب، أو يمكن فقط لشخص واحد لديه صلاحيات إنشاء الحساب القيام بذلك. نظرًا لأن الهدف الكامل هو أن ليبرا تأمل في إجراء مدفوعات متوافقة والعقود الذكية المتوافقة، كانت هناك هذه القيود. ولكن في مجال Web3 الأكثر عمومية، فإن الوضع هو العكس تمامًا. لا ترغب في التوافق على المستوى الأساسي، هذه هي فكرة العقود الذكية. تريد أن تكون الأمور حرة قدر الإمكان، ويجب أن تكون قادرًا على إرسال شيء ما إلى أي عنوان. ثم لا ينبغي عليك إجراء إنشاء حساب صريح، لأن ذلك سيعيق حالات الاستخدام المختلفة. هذه هي نقطة مهمة.
عامل آخر هو أنه على الرغم من أننا ركزنا على الأصول في Move، إلا أننا لم نفكر في كيفية إدخال تركيز الأصول في المعاملات نفسها في ذلك الوقت في Libra. لذا، عندما تصل إلى مستوى المعاملات، لا تزال لديك هذا API فقط، حيث تدخل أرقامًا وقيمًا بوليانية وما إلى ذلك، وهي أشياء ليست أصولًا، ثم في Move، تستخدم هذه الأرقام لاستخراج الأصول من الحساب وإجراء عمليات أخرى. وقد أظهرت التجربة أن معظم الشيفرة البرمجية التي تشغلها هي من هذا النوع من الأعمال الدفترية المزعجة، والتي تشمل استخراج هذا الشيء، واستخراج ذلك الشيء، واستخراج أشياء أخرى، حسنًا، لقد حصلت على جميع الأصول التي أريدها. إنها هنا، في استوديوي، الآن يمكنني البدء في القيام بشيء ذي معنى. ثم في نهاية هذه العملية، قد تقول: "حسنًا، أعد هذه الأصول إلى هذا الحساب، وأعدها إلى ذلك الحساب، وأعد تنظيمها.
في Sui، فكرنا بعناية، إذا بدأ كل برنامج وانتهى بهذه الطريقة، هل يمكننا تجريد ذلك؟ لذلك، ستكون المنطق المستخدمة لمعالجة المعاملات متاحة للمبرمجين لإتمام ذلك، ومن وجهة نظر المبرمجين، يحتاجون فقط إلى تجهيز الأصول المطلوبة، والبدء فورًا في العمل الممتع. هذا هو نموذج البيانات القائم على الكائنات الموجود في Sui. في Move الأصلية، لدينا نموذج بيانات يعتمد على الحساب، حيث يتم تخزين الأصول تحت الحساب، ويجب على المبرمجين استخراجها بشكل صريح. بينما في Sui، يتم الحصول على الأصول من قبل وقت تشغيل Sui عند دخول جزء المعاملة في Move. هذا أكثر ملاءمة للمبرمجين، لأنهم لا يحتاجون إلى القيام بكل تلك الأعمال المحاسبية قبل وبعد، وهذا أيضًا هو السلاح السري الذي يسمح لنا بتحديد ما إذا كان يمكن تنفيذ معاملة واحدة بالتوازي مع أخرى دون تنفيذ فعلي، مما يسمح بتوسيع Sui أفقيًا وتنفيذ بعض العمليات الأخرى بشكل أكثر كفاءة.
لقد قمنا أيضًا ببعض الأعمال المثيرة للاهتمام، مثل استخدام نموذج البيانات القائم على الكائنات لإنشاء كتل قابلة للبرمجة. هذه مسألة تقنية إلى حد ما، وأنا سعيد بالتعمق في المناقشة. لكن هذان العاملان هما المحركان الرئيسيان وراء الاختلافات مع Move الأصلية.
Q4، هل يمكنك مشاركة المزيد من المعلومات حول الكتل القابلة للبرمجة ووظائفها؟
أحب استخدام تشبيه لشرح ذلك، حيث أن سلاسل الكتل الأخرى تشبه منطقة الطعام في مركز تجاري. إذا كنت ترغب في تناول آيس كريم، تذهب إلى كشك الآيس كريم، وتخرج بطاقتك الائتمانية للدفع. ولكن إذا قررت أنك تريد أيضًا تناول برجر، ستذهب إلى كشك البرجر، وتدفع مرة أخرى. أنا لست شخصًا محبًا للطعام، ولكن إذا كنت أريد تناول ثمانية أشياء، يجب أن أجري ثمانية معاملات منفصلة. بينما Sui تشبه أكثر بوفيه حيث كل معاملة ليست مجرد شيء واحد. بمجرد أن تدفع ثمن البوفيه، يمكنك القيام بالكثير من الأشياء دون تكاليف إضافية. يمكنك تناول الآيس كريم، يمكنك تناول البرجر، يمكنك خلطهما معًا.
لجعل هذا المفهوم أكثر وضوحًا، في حالة بسيطة، إذا كنت تريد إرسال 100 معاملة لصك 100 NFT، يمكنك إرسال معاملة واحدة لصك 100 NFT. تكلفة هذه العملية تقريبًا تعادل تكلفة صك NFT واحد. يمكنك أيضًا تنفيذ تجميع معاملات غير متجانسة، مثل أن المعاملة الأولى في الكتلة تسحب شخصية ماريو من محفظتك متعددة التوقيع، بينما تطلب المعاملة الثانية ماريو، مما يسمح لك باللعب. إذا فزت في اللعبة وحصلت على الكأس، ربما ستقوم المعاملة الثالثة بوضع الكأس في خزانة أكواب مشتركة مع أصدقائك. ما هو رائع هو أن كتل المعاملات القابلة للبرمجة تسمح للمطورين بكتابة الكود بهذه الطريقة، حيث لا تحتاج اللعبة إلى معرفة كيفية تخزين المحفظة متعددة التوقيع أو ماريو، ولا تحتاج إلى معرفة خزانة الكؤوس الخاصة بك أو كيفية تنفيذها.
تتكون كتل المعاملات القابلة للبرمجة من معاملات تحتوي على كائنات دخول وخروج. إذا كنت بحاجة إلى كائن دخول، يمكنك الحصول على هذا الكائن دون أن تهتم من أين أتى، ثم تمرر مخرجاته إلى الكائن الذي يحتاجه، دون أن تهتم أيضاً إلى أين ستنتقل. في سلاسل الكتل الأخرى، يكون التزاوج أقوى، لذا يجب أن تتكامل الألعاب مع المحافظ متعددة التوقيع وخزائن الجوائز، أو يجب أن تنفذ جميعها بعض الواجهات المشتركة وتكون لديها تزاوج أقوى. تجعل Sui ما يسمى بالتجميع المؤقت أسهل. مثل، إذا كانت الأنابيب متطابقة، يمكننا إتمام ذلك في معاملة واحدة.
Q5، ما هي فوائد منطقة التداول القابلة للبرمجة للمستخدمين؟
بالنسبة للمستخدمين، تشمل فوائد كتل التداول القابلة للبرمجة تكاليف غاز أقل، حيث يمكنك تجميع جميع العمليات في صفقة واحدة بدلاً من إجراء صفقات منفصلة. بالإضافة إلى ذلك، سيتم تقليل عدد الموافقات المطلوبة. إذا كان النظام الذي تستخدمه يتطلب موافقة على الصفقة، فستحتاج فقط إلى إجراء موافقة واحدة، ثم سيتم تنفيذ جميع العمليات دفعة واحدة. فائدة أخرى هي الذرية، إذا كنت ترغب في القيام بثلاثة أشياء مختلفة، وترغب في أن تنجح العملية الثالثة فقط إذا نجحت العمليتان الأولى والثانية، وإذا كانت هذه العمليات يجب أن تكون صفقات مستقلة، فلن تتمكن من تحقيق ذلك. ولكن، إذا كان بإمكانك وضعها جميعًا في صفقة واحدة، فستتمكن من تحقيق ذلك بسهولة.
Q6، لقد سمعتك تتحدث مع آخرين عن أن تطوير على Sui هو تجربة رائعة للمبرمجين، وهذا أمر مهم. هل لديك أي قصص تود مشاركتها حول بدء المبرمجين ذوي الخبرة والجدد في Web3 باستخدام Sui Move؟
بالنسبة لأولئك المطورين القادمين من لغات برمجة Web3 الأخرى، فإن تجربة التطوير على Move وSui Move هي بالتأكيد أكثر كفاءة وأماناً. لقد حضرت للتو برنامج بودكاست حول بروتوكول Bucket، حيث يقومون بإنشاء مشروع DeFi رائع على Sui. أثناء عرضهم لهندسة النظام، تحدثوا عن كيفية تعاون المكونات المختلفة. قالوا إنه إذا كانوا سيكتبون هذا المشروع باستخدام Solidity، فقد يستغرق الأمر ثمانية أشهر، لكن باستخدام Sui Move استغرق الأمر شهرين فقط، وهم واثقون جدًا من أمانه. تعمل هذه اللغة بطريقة قريبة جدًا من أفكارهم حول مجموعة المشاريع في أذهانهم. بينما في مجال Solidity، فإن هذا الاتصال ليس مباشرًا جدًا.
هذه مجرد مثال، لكننا سمعنا العديد من الحالات المماثلة، حيث يقول الناس إنهم يطورون بشكل أسرع بلغة البرمجة هذه، ويشعرون بثقة أكبر بعد الانتهاء. سماع هذا يجعلني سعيداً. لكن إلى حد ما، ليس من المستغرب، لقد بحثنا في Solidity وفهمنا المشكلات الموجودة. لقد صممنا بوضوح حلولاً حول كيفية جعلها أكثر أمانًا وأسرع. نظرنا فيما يحاول المطورون الذين يستخدمون هذه اللغة القيام به، وكيفية تصميم لغة تلبي احتياجاتهم بدلًا من تلبية الظروف القائمة. تم تصميم هذه اللغة لحل المشكلات التي يواجهها الناس، لذلك عندما يقومون بالتبديل، فإنهم سيقدرون هذه اللغة حقًا.
يقولون إن الميزة الأولى مهمة ، لكنني أعتقد أنه في هذه الحالة ، الميزة المتأخرة هي الأكثر أهمية.
نعم، هكذا.
، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
5
إعادة النشر
مشاركة
تعليق
0/400
DegenWhisperer
· 08-18 15:44
قال لوه هي هذه المرة بشكل جيد
شاهد النسخة الأصليةرد0
BearMarketBro
· 08-18 06:41
حمقى الجدد لا تأتي بعد الآن
شاهد النسخة الأصليةرد0
OnchainDetective
· 08-17 04:31
move رائع sui跟着 للقمر
شاهد النسخة الأصليةرد0
GateUser-44a00d6c
· 08-17 04:22
لقد كنت أتابع Move رائع
شاهد النسخة الأصليةرد0
AirdropHuntress
· 08-17 04:22
توجد تساؤلات حول سرعة تكرار كود Sui، حيث تظهر البيانات أن نشاط الشبكة الرئيسية لا يفي بالمعايير.
تفسير مؤسس لغة Move: لماذا يعتبر Sui Move أكثر ملاءمة لبناء منتجات Web3
مقابلة مع والد لغة Move: لماذا تعتبر لغة العقود الذكية Sui Move مناسبة لبناء منتجات Web3؟
مؤخراً، أجرينا محادثة مع سام بلاكشيار، المدير الفني لشركة ميسن لابز ومؤسس لغة البرمجة موف، حيث ناقشنا سبب تطويره للغة البرمجة الجديدة للعقود الذكية Sui Move، والقدرات القابلة للتوسع التي يمكن أن تقدمها Sui، وفوائد التكنولوجيا اللامركزية للبناة.
فيما يلي محتوى هذه المقابلة:
السؤال 1: أولاً، هل يمكنك تلخيص ما هي لغات البرمجة، وما هي الصفات التي يهتم بها المطورون أكثر عند اختيار لغة البرمجة، وما الذي دفعك لتطوير لغتك البرمجية الخاصة؟
تعتبر لغات البرمجة أداة للتفاعل الودي والآمن والفعال والواضح مع الكمبيوتر. وهذا أمر مهم بشكل خاص بالنسبة للكمبيوتر. لا يمكننا التواصل مع الكمبيوتر باستخدام اللغة الطبيعية، لأن المعنى الكامل للغة الطبيعية يتمثل في ثرائها وقدرتها التعبيرية.
في لغات البرمجة، من الأهم أن تكون لديك دلالة محددة بدقة. عندما تكتب برنامجًا، تكون واضحًا بشأن ما سيفعله. إذا أجريت تعديلات طفيفة عليه، فأنت تعرف ما ستكون نتائج هذا التغيير.
أعتقد أن طبيعة لغات البرمجة، بخلاف اللغات الطبيعية، تستهدف مجالًا معينًا أو مهمة معينة. وإلا، فسيكون من الممكن استخدام لغة برمجة واحدة لإنجاز جميع المهام. لكن وجود عدة لغات برمجة هو لأنك لا تستطيع التميز في جميع المجالات. إنهم يحاولون تحديد أهداف معينة لمجالات مشاكل محددة، ويركزون على حل هذه المشكلات.
لذلك، فإن قصة Move مشابهة جدًا لهذا. عندما أنشأته، لم يكن الهدف هو إنشاء لغة جديدة. يسأل المطورون عند اختيار لغة: "هل هذه اللغة مناسبة للمهام التي أريد إنجازها؟" لكنني أعتقد أن ما هو أكثر أهمية قد يكون: "هل لهذه اللغة مجتمع كبير؟ هل هناك العديد من قواعد البيانات المتاحة؟ هل هناك العديد من المبرمجين الذين يستخدمونها؟ هل هناك موارد تعليمية جيدة؟" كل هذه الأمور مهمة للغاية، لذا يجب أن تكون عتبة إنشاء لغة جديدة عالية جدًا.
Q2، هل يمكنك مشاركة المزيد عن حالة تطوير Move؟
نشأت Move من مشروع Libra الخاص بفيسبوك. لم تكن مهمتي في ذلك الوقت هي إنشاء لغة جديدة، بل كانت "يحتاج Libra إلى عقود ذكية، لذا اكتشف ما ينبغي علينا فعله." نظرت إلى مجموعة متنوعة من الأشياء. هل يمكننا استخدام Solidity في EVM؟ هل ينبغي علينا استخدام لغة عامة تقليدية، مثل WASM أو JVM، واستخدامها لـ Libra؟ أم ينبغي علينا إنشاء شيء خاص بنا؟
إن قرار إنشاء شيء خاص بنا يعتمد على دراسة العقود الذكية الحالية، وفهم ما يحاول المبرمجون القيام به، بالإضافة إلى الأماكن التي تساعدهم فيها بعض اللغات والأماكن التي تخيب آمالهم. خلاصة القول، في كثير من الحالات، فإن لغات العقود الذكية الحالية تخيب آمالهم بالفعل.
يمكن رؤية هذه النقطة بوضوح من السجل السيئ للأمان في Solidity، ولكن الأهم من ذلك، أن هذه العقود الذكية ليست نوع البرامج التقليدية جدًا. Solidity ليست لغة تم بناؤها للأشياء التي يقوم بها الناس الآن.
لذلك فإن هذه العقود الذكية بسيطة للغاية، فهي تقوم بشكل أساسي بشيئين. إنها تحدد نوع الأصول، بما في ذلك متى يمكن نقل الأصول، وما يمكنك فعله بها، ومن يمكنه قراءتها، ومن يمكنه كتابة قواعدها. وتتحقق من سياسات التحكم في الوصول، لتحديد من يمتلك الأصل، ومن يُسمح له باستخدامه، ومن يُسمح له بالتعامل معه. كل شيء يدور حول الأصول، أنت ترغب في أن تمتلك هذه الأصول الخصائص نفسها التي تمتلكها الأصول المادية.
تحتوي العقود الذكية على مفهوم الملكية ونقل الملكية، ولكن على الكمبيوتر، كل شيء مجرد أرقام وبتات، ويمكن نسخه بحرية. وأنت تعلم، أن هذه المفاهيم غير موجودة في العالم الحقيقي. لذلك، أنت تأمل أن تكون هناك لغة يمكن أن تقدم لك تجريدًا جيدًا حول الملكية والتجانس. تمامًا كما في العالم الحقيقي، ولكن دون الحاجة لإجبار المبرمجين على إعادة اختراعه. أنت تأمل في الحصول على ضمانات أمان أساسية.
هذه هي وظيفة Move ولماذا أنشأنا في النهاية هذه اللغة الجديدة. هذه المهام أساسية لبرمجة العقود الذكية. من الصعب إعادة إنشائها في لغات أخرى، بما في ذلك لغات العقود الذكية الحالية، ونرغب في تصميم لغة كاملة حول توفير هذه الوظائف الأساسية حتى يتمكن المبرمجون من كتابة الكود بأمان وكفاءة دون الحاجة إلى اختراع العجلات في كل مرة يفكرون فيها في كتابة بعض الأكواد.
Q3، استخدمت Sui نوعًا معدلاً من Move يسمى Sui Move. ما الذي دفع لهذه التغييرات؟ ما هي الخصائص في Sui Move التي تجعلها مناسبة جدًا لبناء المنتجات في Web3؟
تسببت بعض العوامل في هذه التغييرات، أحدها هو أن الهدف الأصلي لمشروع ليبرا كان بناء شبكة دفع متوافقة. لذلك، حاولنا تصميم Move كلغة عالمية. ولكننا قمنا بوعي ببعض الأمور، لأن ليبرا كانت تأمل في وجود قيود. واحدة من الأمور المهمة هي أنهم لم يرغبوا في أن يتمكن الناس من إرسال أصول معينة إلى أي مكان. كانوا يريدون من الناس إنشاء حساب بشكل واضح، وتحديد بعض القواعد عند إنشاء الحساب، مثل ضرورة إجراء مالك الحساب لعملية KYC. أو قد يحتاجون إلى دفع رسوم لإنشاء الحساب، أو يمكن فقط لشخص واحد لديه صلاحيات إنشاء الحساب القيام بذلك. نظرًا لأن الهدف الكامل هو أن ليبرا تأمل في إجراء مدفوعات متوافقة والعقود الذكية المتوافقة، كانت هناك هذه القيود. ولكن في مجال Web3 الأكثر عمومية، فإن الوضع هو العكس تمامًا. لا ترغب في التوافق على المستوى الأساسي، هذه هي فكرة العقود الذكية. تريد أن تكون الأمور حرة قدر الإمكان، ويجب أن تكون قادرًا على إرسال شيء ما إلى أي عنوان. ثم لا ينبغي عليك إجراء إنشاء حساب صريح، لأن ذلك سيعيق حالات الاستخدام المختلفة. هذه هي نقطة مهمة.
عامل آخر هو أنه على الرغم من أننا ركزنا على الأصول في Move، إلا أننا لم نفكر في كيفية إدخال تركيز الأصول في المعاملات نفسها في ذلك الوقت في Libra. لذا، عندما تصل إلى مستوى المعاملات، لا تزال لديك هذا API فقط، حيث تدخل أرقامًا وقيمًا بوليانية وما إلى ذلك، وهي أشياء ليست أصولًا، ثم في Move، تستخدم هذه الأرقام لاستخراج الأصول من الحساب وإجراء عمليات أخرى. وقد أظهرت التجربة أن معظم الشيفرة البرمجية التي تشغلها هي من هذا النوع من الأعمال الدفترية المزعجة، والتي تشمل استخراج هذا الشيء، واستخراج ذلك الشيء، واستخراج أشياء أخرى، حسنًا، لقد حصلت على جميع الأصول التي أريدها. إنها هنا، في استوديوي، الآن يمكنني البدء في القيام بشيء ذي معنى. ثم في نهاية هذه العملية، قد تقول: "حسنًا، أعد هذه الأصول إلى هذا الحساب، وأعدها إلى ذلك الحساب، وأعد تنظيمها.
في Sui، فكرنا بعناية، إذا بدأ كل برنامج وانتهى بهذه الطريقة، هل يمكننا تجريد ذلك؟ لذلك، ستكون المنطق المستخدمة لمعالجة المعاملات متاحة للمبرمجين لإتمام ذلك، ومن وجهة نظر المبرمجين، يحتاجون فقط إلى تجهيز الأصول المطلوبة، والبدء فورًا في العمل الممتع. هذا هو نموذج البيانات القائم على الكائنات الموجود في Sui. في Move الأصلية، لدينا نموذج بيانات يعتمد على الحساب، حيث يتم تخزين الأصول تحت الحساب، ويجب على المبرمجين استخراجها بشكل صريح. بينما في Sui، يتم الحصول على الأصول من قبل وقت تشغيل Sui عند دخول جزء المعاملة في Move. هذا أكثر ملاءمة للمبرمجين، لأنهم لا يحتاجون إلى القيام بكل تلك الأعمال المحاسبية قبل وبعد، وهذا أيضًا هو السلاح السري الذي يسمح لنا بتحديد ما إذا كان يمكن تنفيذ معاملة واحدة بالتوازي مع أخرى دون تنفيذ فعلي، مما يسمح بتوسيع Sui أفقيًا وتنفيذ بعض العمليات الأخرى بشكل أكثر كفاءة.
لقد قمنا أيضًا ببعض الأعمال المثيرة للاهتمام، مثل استخدام نموذج البيانات القائم على الكائنات لإنشاء كتل قابلة للبرمجة. هذه مسألة تقنية إلى حد ما، وأنا سعيد بالتعمق في المناقشة. لكن هذان العاملان هما المحركان الرئيسيان وراء الاختلافات مع Move الأصلية.
Q4، هل يمكنك مشاركة المزيد من المعلومات حول الكتل القابلة للبرمجة ووظائفها؟
أحب استخدام تشبيه لشرح ذلك، حيث أن سلاسل الكتل الأخرى تشبه منطقة الطعام في مركز تجاري. إذا كنت ترغب في تناول آيس كريم، تذهب إلى كشك الآيس كريم، وتخرج بطاقتك الائتمانية للدفع. ولكن إذا قررت أنك تريد أيضًا تناول برجر، ستذهب إلى كشك البرجر، وتدفع مرة أخرى. أنا لست شخصًا محبًا للطعام، ولكن إذا كنت أريد تناول ثمانية أشياء، يجب أن أجري ثمانية معاملات منفصلة. بينما Sui تشبه أكثر بوفيه حيث كل معاملة ليست مجرد شيء واحد. بمجرد أن تدفع ثمن البوفيه، يمكنك القيام بالكثير من الأشياء دون تكاليف إضافية. يمكنك تناول الآيس كريم، يمكنك تناول البرجر، يمكنك خلطهما معًا.
لجعل هذا المفهوم أكثر وضوحًا، في حالة بسيطة، إذا كنت تريد إرسال 100 معاملة لصك 100 NFT، يمكنك إرسال معاملة واحدة لصك 100 NFT. تكلفة هذه العملية تقريبًا تعادل تكلفة صك NFT واحد. يمكنك أيضًا تنفيذ تجميع معاملات غير متجانسة، مثل أن المعاملة الأولى في الكتلة تسحب شخصية ماريو من محفظتك متعددة التوقيع، بينما تطلب المعاملة الثانية ماريو، مما يسمح لك باللعب. إذا فزت في اللعبة وحصلت على الكأس، ربما ستقوم المعاملة الثالثة بوضع الكأس في خزانة أكواب مشتركة مع أصدقائك. ما هو رائع هو أن كتل المعاملات القابلة للبرمجة تسمح للمطورين بكتابة الكود بهذه الطريقة، حيث لا تحتاج اللعبة إلى معرفة كيفية تخزين المحفظة متعددة التوقيع أو ماريو، ولا تحتاج إلى معرفة خزانة الكؤوس الخاصة بك أو كيفية تنفيذها.
تتكون كتل المعاملات القابلة للبرمجة من معاملات تحتوي على كائنات دخول وخروج. إذا كنت بحاجة إلى كائن دخول، يمكنك الحصول على هذا الكائن دون أن تهتم من أين أتى، ثم تمرر مخرجاته إلى الكائن الذي يحتاجه، دون أن تهتم أيضاً إلى أين ستنتقل. في سلاسل الكتل الأخرى، يكون التزاوج أقوى، لذا يجب أن تتكامل الألعاب مع المحافظ متعددة التوقيع وخزائن الجوائز، أو يجب أن تنفذ جميعها بعض الواجهات المشتركة وتكون لديها تزاوج أقوى. تجعل Sui ما يسمى بالتجميع المؤقت أسهل. مثل، إذا كانت الأنابيب متطابقة، يمكننا إتمام ذلك في معاملة واحدة.
Q5، ما هي فوائد منطقة التداول القابلة للبرمجة للمستخدمين؟
بالنسبة للمستخدمين، تشمل فوائد كتل التداول القابلة للبرمجة تكاليف غاز أقل، حيث يمكنك تجميع جميع العمليات في صفقة واحدة بدلاً من إجراء صفقات منفصلة. بالإضافة إلى ذلك، سيتم تقليل عدد الموافقات المطلوبة. إذا كان النظام الذي تستخدمه يتطلب موافقة على الصفقة، فستحتاج فقط إلى إجراء موافقة واحدة، ثم سيتم تنفيذ جميع العمليات دفعة واحدة. فائدة أخرى هي الذرية، إذا كنت ترغب في القيام بثلاثة أشياء مختلفة، وترغب في أن تنجح العملية الثالثة فقط إذا نجحت العمليتان الأولى والثانية، وإذا كانت هذه العمليات يجب أن تكون صفقات مستقلة، فلن تتمكن من تحقيق ذلك. ولكن، إذا كان بإمكانك وضعها جميعًا في صفقة واحدة، فستتمكن من تحقيق ذلك بسهولة.
Q6، لقد سمعتك تتحدث مع آخرين عن أن تطوير على Sui هو تجربة رائعة للمبرمجين، وهذا أمر مهم. هل لديك أي قصص تود مشاركتها حول بدء المبرمجين ذوي الخبرة والجدد في Web3 باستخدام Sui Move؟
بالنسبة لأولئك المطورين القادمين من لغات برمجة Web3 الأخرى، فإن تجربة التطوير على Move وSui Move هي بالتأكيد أكثر كفاءة وأماناً. لقد حضرت للتو برنامج بودكاست حول بروتوكول Bucket، حيث يقومون بإنشاء مشروع DeFi رائع على Sui. أثناء عرضهم لهندسة النظام، تحدثوا عن كيفية تعاون المكونات المختلفة. قالوا إنه إذا كانوا سيكتبون هذا المشروع باستخدام Solidity، فقد يستغرق الأمر ثمانية أشهر، لكن باستخدام Sui Move استغرق الأمر شهرين فقط، وهم واثقون جدًا من أمانه. تعمل هذه اللغة بطريقة قريبة جدًا من أفكارهم حول مجموعة المشاريع في أذهانهم. بينما في مجال Solidity، فإن هذا الاتصال ليس مباشرًا جدًا.
هذه مجرد مثال، لكننا سمعنا العديد من الحالات المماثلة، حيث يقول الناس إنهم يطورون بشكل أسرع بلغة البرمجة هذه، ويشعرون بثقة أكبر بعد الانتهاء. سماع هذا يجعلني سعيداً. لكن إلى حد ما، ليس من المستغرب، لقد بحثنا في Solidity وفهمنا المشكلات الموجودة. لقد صممنا بوضوح حلولاً حول كيفية جعلها أكثر أمانًا وأسرع. نظرنا فيما يحاول المطورون الذين يستخدمون هذه اللغة القيام به، وكيفية تصميم لغة تلبي احتياجاتهم بدلًا من تلبية الظروف القائمة. تم تصميم هذه اللغة لحل المشكلات التي يواجهها الناس، لذلك عندما يقومون بالتبديل، فإنهم سيقدرون هذه اللغة حقًا.
يقولون إن الميزة الأولى مهمة ، لكنني أعتقد أنه في هذه الحالة ، الميزة المتأخرة هي الأكثر أهمية.
نعم، هكذا.
![مقابلة مع والد لغة Move: لماذا تعتبر لغة العقود الذكية Sui Move مناسبة لبناء منتجات Web3؟](