مقابلة مع والد لغة Move: لماذا تعتبر لغة العقود الذكية Sui Move مناسبة لبناء منتجات Web3؟
مؤخراً، تحدثنا مع كبير موظفي التكنولوجيا في Mysten Labs ومؤسس لغة البرمجة Move، سام بلاكشير، حول سبب تطويره للغة البرمجة الجديدة للعقود الذكية Sui Move، والوظائف القابلة للتوسع في Sui، وفوائد التكنولوجيا اللامركزية للبنائين.
فيما يلي محتوى هذه المقابلة:
س1، أولاً، هل يمكنك تلخيص ما هي لغات البرمجة، وما هي الصفات التي يهتم بها المطورون عند اختيار لغة برمجة، وما الذي دفعك لتطوير لغتك البرمجية الخاصة؟
تُعتبر لغات البرمجة أدوات تفاعلية ودية وآمنة وفعالة وواضحة للتواصل مع الحواسيب، وهذا أمر مهم بشكل خاص بالنسبة للحواسيب. لا يمكننا التواصل مع الحواسيب باستخدام اللغة الطبيعية، لأن المعنى الكامل للغة الطبيعية يتميز بالغنى وقدرة التعبير. عندما تعبر عن الكلمات بنغمة مختلفة قليلاً أو تختار طريقة تعبير دقيقة مختلفة، فإن معنى جملتك أو فقرتك قد يتغير تمامًا.
وفي لغات البرمجة، الأمر الأكثر أهمية هو وجود دلالة محددة بدقة. عندما تكتب برنامجًا، تكون على دراية بما سيفعله. إذا قمت بإجراء تعديلات طفيفة عليه، فإنك تعرف النتائج التي سيترتب عليها هذا التغيير. يجب الحفاظ على هذه النقطة على عدة مستويات، على سبيل المثال، يمكنك كتابة الكود بلغة مصدر معينة، التي تحمل معنى ما، ثم يتم تحويلها إلى أشكال أخرى للتعبير، وبالتالي يجب أن تحتفظ بنفس المعنى، حتى عندما تصل إلى وحدات معالجة الآلات.
أعتقد أن طبيعة لغات البرمجة، على عكس اللغات الطبيعية، موجهة نحو مجالات معينة أو مهام محددة. خلاف ذلك، يمكن استخدام لغة برمجة واحدة فقط لإكمال جميع المهام. ولكن السبب في وجود لغات برمجة متعددة هو أنك لا يمكنك أن تكون جيدًا في جميع المجالات. إنها تسعى لتحقيق تحديد الأهداف لمجالات المشاكل المحددة، وتركز على حل هذه المشاكل. على سبيل المثال، إذا نظرت إلى لغة البرمجة Rust التي نستخدمها لكتابة سلسلة الكتل Sui ومعظم الأنظمة الأخرى التي تعمل في Mysten، فهي تركز على كتابة كود سريع وعالي الأداء، مع ضمان الأمان. إنها تتيح لك الوصول إلى تفاصيل منخفضة المستوى مثل الذاكرة، وهياكل الخيوط، أو التزامن، ولكنها لا تجعلك ترتكب الأخطاء كما كانت اللغات السابقة (مثل C أو C++).
لذلك، قصة Move مشابهة جدًا لذلك. عندما أنشأته، لم يكن الهدف هو خلق لغة جديدة. لقد ذكرت سابقًا ما يبحث عنه المطورون في لغة ما. سيسألون، "هل هذه اللغة مناسبة للمهمة التي أريد إنجازها؟" لكنني أعتقد أن ما هو أكثر أهمية هو، "هل تمتلك هذه اللغة مجتمعًا ضخمًا؟ هل هناك الكثير من قواعد البيانات المتاحة؟ هل هناك العديد من المبرمجين المستخدمين لها؟ هل هناك موارد تعليمية جيدة؟" كل هذه الأمور مهمة جدًا، لذلك يجب أن تكون عتبة إنشاء لغة جديدة مرتفعة جدًا، حتى لو كانت هذه اللغة أفضل في حد ذاتها، ولكن إذا لم يكن لديها تلك العوامل، فإن ميزتها تصبح بلا معنى. بناء مجتمع ضخم وحيوي من الصفر هو أمر صعب جدًا.
Q2، هل يمكنك مشاركة المزيد عن حالة تطوير Move؟
نشأت Move من مشروع Libra الخاص بفيسبوك. لم تكن مهمتي في ذلك الوقت هي إنشاء لغة جديدة، بل كانت "يحتاج Libra إلى عقود ذكية، لذا اكتشف ما يجب علينا فعله." نظرت إلى مجموعة متنوعة من الأشياء. هل يمكننا استخدام Solidity في EVM؟ هل يجب علينا استخدام لغة عامة تقليدية، مثل WASM أو JVM، واستخدامها لـ Libra؟ أم يجب علينا إنشاء شيء خاص بنا؟
إن قرار إنشاء شيء خاص بنا يستند إلى دراسة العقود الذكية الحالية، وفهم ما يحاول المبرمجون القيام به، والأماكن التي تساعدهم فيها بعض اللغات وتلك التي تخيب آمالهم. استنتجت أنه في العديد من الحالات، فإن لغات العقود الذكية الحالية تخيب آمالهم بالفعل.
يمكن رؤية هذه النقطة بوضوح من سجل الأمان السيئ لـ Solidity، لكن الأمر أكثر أساسية من ذلك، حيث أن هذه العقود الذكية ليست نوعًا تقليديًا جدًا من البرامج. Solidity ليست لغة مبنية لما يفعله الناس الآن. لا أريد انتقادها، لأنها كانت أول لغة للعقود الذكية، ولم تكن تعرف بعد ما الذي يريد الناس استخدامه من أجلها. بمجرد أن ترى ما يحاول الناس القيام به بها، أعتقد أنه من الواضح أنك بحاجة إلى مجموعة مختلفة من التجريدات وأدوات البرمجة، والتي لا توفرها لغة Solidity.
لذا فإن هذه العقود الذكية بسيطة جداً، فهي تقوم بشكل أساسي بعمل شيئين. فهي تحدد نوع الأصول، بما في ذلك متى يمكن نقل الأصل، وماذا يمكنك أن تفعل به، ومن يمكنه قراءته، وقواعد من يمكنه كتابته. وكذلك تحقق من سياسة التحكم في الوصول، لتحديد من يمتلك الأصل، ومن يُسمح له باستخدامه، ومن يُسمح له بالتلاعب به. كل شيء يدور حول الأصول، وترغب في أن تمتلك هذه الأصول خصائص مماثلة للأصول المادية. إذا سلمت شيئاً لك، فيجب أن تمتلكه، ولم أعد أملكه.
تحتوي العقود الذكية على مفهوم الملكية ونقل الملكية، ولكن على الكمبيوتر، كل شيء هو مجرد أرقام وبتات، ويمكن نسخه بحرية. وأنت تعلم أن هذه المفاهيم غير موجودة في العالم الحقيقي. لذلك، أنت ترغب في وجود لغة توفر لك تجريدًا جيدًا حول الملكية والتجانس. تمامًا كما هو الحال في العالم الحقيقي، ولكن دون الحاجة لإجبار المبرمجين على إعادة اختراعها. أنت تأمل في الحصول على ضمانات أساسية للأمان.
هذا هو دور Move ولماذا أنشأنا في النهاية هذه اللغة الجديدة. هذه المهام أساسية لبرمجة العقود الذكية. من الصعب إعادة إنشائها في لغات أخرى، بما في ذلك لغات العقود الذكية الحالية، ونأمل في تصميم اللغة بأكملها حول تقديم هذه الوظائف الأساسية، بحيث يمكن للمبرمجين كتابة التعليمات البرمجية بأمان وكفاءة دون الحاجة إلى إعادة اختراع العجلة في كل مرة يريدون فيها كتابة بعض التعليمات البرمجية.
Q3، استخدمت Sui متغيرًا من Move يسمى Sui Move. ما الذي دفع هذه التغييرات؟ ما هي الخصائص في Sui Move التي تجعلها مناسبة جدًا لبناء المنتجات في Web3؟
تسببت عدة عوامل في هذه التغييرات، أحدها هو أن الهدف من مشروع Libra الأصلي كان بناء شبكة مدفوعات متوافقة. لذلك، حاولنا تصميم Move كلغة عامة. لكننا قمنا بعمل بعض الأشياء عن وعي، لأن Libra كانت ترغب في وجود قيود. أحد الأمور المهمة هو أنهم لا يريدون أن يتمكن الناس من إرسال أصول معينة إلى أي مكان. كانوا يريدون من الناس إنشاء حسابات بشكل واضح، وتحديد بعض القواعد عند إنشاء الحساب، مثل أن مالك الحساب يجب أن يجري عملية التحقق من الهوية (KYC). أو قد يحتاج إلى دفع رسوم لإنشاء الحساب، أو يمكن أن يتم إنشاء الحساب فقط من قبل عدد قليل من الأشخاص الذين لديهم صلاحية إنشاء الحسابات. نظرًا لأن الهدف الكلي هو أن ترغب Libra في إجراء مدفوعات متوافقة والعقود الذكية المتوافقة، فهناك هذه القيود. ولكن في مجال Web3 الأكثر عمومية، الحالة هي العكس تمامًا. أنت لا ترغب في الالتزام على المستوى الأساسي، وهذا هو مفهوم العقود الذكية. أنت ترغب في أن تكون الأمور حرة قدر الإمكان، ويجب أن تتمكن تمامًا من إرسال شيء ما إلى أي عنوان. ثم يجب ألا تقوم بإنشاء حسابات بشكل صريح، لأن ذلك سيعيق مجموعة متنوعة من حالات الاستخدام. هذه نقطة مهمة.
عامل آخر هو أنه على الرغم من أننا ركزنا على الأصول في Move ، إلا أننا لم نفكر في كيفية إدخال تركيز الأصول في المعاملات نفسها أثناء وجودنا في Libra في ذلك الوقت. لذلك ، عندما تصل إلى مستوى المعاملة ، لا يزال لديك هذا API فقط ، حيث تدخل أرقامًا وقيمًا منطقية وما إلى ذلك ، وهي أشياء ليست أصولًا ، ثم في Move ، تستخدم هذه الأرقام لاستخراج الأصول من الحساب والقيام بأشياء أخرى. وقد تبين أن معظم الشيفرات التي تقوم بتشغيلها هي من هذا النوع من العمل الدفتري المزعج ، والذي يتضمن استخراج هذا الشيء ، واستخراج ذلك الشيء ، واستخراج أشياء أخرى ، حسنًا ، لدي جميع الأصول التي أريدها. إنها هنا ، في استوديوي ، والآن يمكنني البدء في القيام بشيء ذي معنى. ثم في نهاية هذه العملية ، قد تقول: "حسنًا ، أعد هذه الأصول إلى هذا الحساب ، وأعدها إلى ذلك الحساب ، وأعد تنظيمها.
في Sui، نحن نفكر بعمق، إذا كانت كل برنامج يبدأ وينتهي بهذه الطريقة، هل يمكننا تجريده؟ لذلك، فإن المنطق المستخدم لمعالجة المعاملات سيكون جاهزًا للبرمجيات، من وجهة نظر المبرمجين، هم فقط بحاجة إلى تجهيز الأصول المطلوبة، وبدء العمل الممتع على الفور. هذه هي نموذج البيانات القائم على الكائنات الموجود في Sui. في Move الأصلية، لدينا نموذج بيانات قائم على الحساب، حيث يتم تخزين الأصول تحت الحساب، ويجب على المبرمجين استخراجها بشكل صريح. أما في Sui، فإنه عند دخولهم إلى جزء Move من المعاملة، يتم الحصول بالفعل على الأصول من قبل وقت تشغيل Sui. هذا أكثر ملاءمة للمبرمجين، لأنه لا يحتاجون إلى القيام بكل هذا العمل المحاسبي من قبل ومن بعد، وهذا أيضًا هو السلاح السري الذي يسمح لنا بتحديد ما إذا كان يمكن تشغيل معاملة واحدة بالتوازي مع أخرى، وتوسيع Sui أفقيًا، وأداء بعض العمليات الأخرى بشكل أكثر كفاءة دون تنفيذ فعلي.
لقد قمنا أيضًا ببعض الأعمال المثيرة للاهتمام، مثل استخدام نموذج البيانات القائم على الكائنات لإنشاء كتل تداول قابلة للبرمجة. هذا موضوع تقني إلى حد ما، وأنا سعيد بالتعمق في المناقشة. لكن هذين العاملين هما الدافعان الرئيسيان للاختلاف عن Move الأصلية.
Q4، هل يمكنك مشاركة المزيد من المعلومات حول الكتل التجارية القابلة للبرمجة ووظائفها؟
أحب استخدام تشبيه لشرح ذلك، فblockchains الأخرى تشبه ساحة الطعام في مركز تجاري. إذا كنت تريد تناول الآيس كريم، تذهب إلى كشك الآيس كريم، وتخرج بطاقتك الائتمانية للدفع. ولكن إذا قررت أنك تريد أيضًا تناول همبرغر، فتذهب إلى كشك الهمبرغر، وتدفع مرة أخرى. لست شخصًا شغوفًا بالطعام، ولكن إذا كنت أرغب في تناول ثمانية أشياء، يجب أن أقوم بثماني معاملات منفصلة. بينما Sui تشبه البوفيه، حيث أن كل معاملة ليست مجرد شيء واحد. بمجرد أن تدفع تكلفة البوفيه، يمكنك القيام بالعديد من الأشياء دون دفع إضافي. يمكنك تناول الآيس كريم، يمكنك تناول الهمبرغر، يمكنك مزجهما معًا.
لجعل هذا المفهوم أكثر وضوحًا، في حالة بسيطة، إذا كنت تريد إرسال 100 معاملة لصك 100 NFT، يمكنك إرسال معاملة واحدة لصك 100 NFT. تكاليف مثل هذه المعاملة تكاد تكون مماثلة لتكلفة صك NFT واحد. يمكنك أيضًا القيام بتجميع المعاملات غير المتجانسة، على سبيل المثال، المعاملة الأولى في الكتلة تأخذ شخصية ماريو من محفظتك متعددة التوقيعات، بينما تطلب المعاملة الثانية شخصية ماريو، مما يسمح لك بلعب اللعبة. إذا فزت في اللعبة وحصلت على الكأس، ربما تكون المعاملة الثالثة هي وضع الكأس في خزانة الكؤوس المشتركة مع أصدقائك. الشيء الرائع هو أن كتل المعاملات القابلة للبرمجة تسمح للمبرمجين بكتابة التعليمات البرمجية بهذه الطريقة، حيث لا تحتاج اللعبة إلى معرفة كيفية تخزين المحفظة متعددة التوقيعات أو ماريو، ولا تحتاج أيضًا إلى معرفة خزانة الكؤوس الخاصة بك أو كيفية تنفيذها.
تتكون كتل التداول القابلة للبرمجة من معاملات تحتوي على كائنات إدخال وإخراج. إذا كنت بحاجة إلى كائن إدخال، يمكنك الحصول على هذا الكائن دون الحاجة للقلق بشأن مصدره، ثم تمرير مخرجاته إلى الكائن الذي يحتاج إليه، دون الحاجة أيضاً للقلق بشأن وجهته. في سلاسل الكتل الأخرى، يكون التماسك أقوى، لذا يجب أن تتكامل الألعاب مع المحافظ متعددة التوقيع وخزائن الجوائز، أو يجب أن تطبق جميعها بعض الواجهات المشتركة وتتمتع بتماسك أقوى. تجعل Sui ما يسمى بالتجمع المؤقت أسهل. كما لو أن الأنابيب تتطابق، يمكننا إكمال ذلك في معاملة واحدة.
س5، ما هي فوائد منطقة التداول القابلة للبرمجة للمستخدمين؟
تشمل فوائد الكتل القابلة للبرمجة للمستخدمين رسوم الغاز المنخفضة، لأنه يمكنك تجميع جميع العمليات في صفقة واحدة بدلاً من إجراء صفقات منفصلة. بالإضافة إلى ذلك، ستقل عدد الموافقات المطلوبة. إذا كان النظام الذي تستخدمه يتطلب موافقة على الصفقة، فستحتاج فقط إلى إجراء موافقة واحدة، ثم سيتم تنفيذ جميع العمليات دفعة واحدة. فائدة أخرى هي الذرية، إذا كنت تريد القيام بثلاثة أشياء مختلفة وتريد أن تنجح العملية الثالثة فقط إذا نجحت العمليتين الأوليين، إذا كانت هذه العمليات يجب أن تكون صفقات مستقلة، فلن تتمكن من تحقيق ذلك. ولكن إذا كان بإمكانك وضعها جميعًا في صفقة واحدة، فستتمكن من تحقيق ذلك بسهولة.
س6، لقد سمعتكم تتحدثون أن تطوير على Sui هو تجربة رائعة للمبرمجين، وهذا مهم. هل لديك أي قصص تود مشاركتها حول تجارب المبرمجين ذوي الخبرة والجدد عند البدء في استخدام Sui Move؟
بالنسبة لأولئك المطورين القادمين من لغات برمجة Web3 الأخرى، فإن تجربتهم في التطوير على Move وSui Move تكون أكثر كفاءة وأمانًا. لقد حضرت للتو برنامج بودكاست حول Bucket Protocol، وهم يبنون على Sui غير...
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 6
أعجبني
6
2
إعادة النشر
مشاركة
تعليق
0/400
MoonlightGamer
· منذ 13 س
move هو المستقبل
شاهد النسخة الأصليةرد0
LiquidationWatcher
· منذ 13 س
أه، يوم آخر ولغة عقد ذكي أخرى... فقط أدعُ أن لا يتم استغلالها مثل سولانا
تحليل والد لغة Move لمزايا Sui Move: أداة بناء منتجات Web3
مقابلة مع والد لغة Move: لماذا تعتبر لغة العقود الذكية Sui Move مناسبة لبناء منتجات Web3؟
مؤخراً، تحدثنا مع كبير موظفي التكنولوجيا في Mysten Labs ومؤسس لغة البرمجة Move، سام بلاكشير، حول سبب تطويره للغة البرمجة الجديدة للعقود الذكية Sui Move، والوظائف القابلة للتوسع في Sui، وفوائد التكنولوجيا اللامركزية للبنائين.
فيما يلي محتوى هذه المقابلة:
س1، أولاً، هل يمكنك تلخيص ما هي لغات البرمجة، وما هي الصفات التي يهتم بها المطورون عند اختيار لغة برمجة، وما الذي دفعك لتطوير لغتك البرمجية الخاصة؟
تُعتبر لغات البرمجة أدوات تفاعلية ودية وآمنة وفعالة وواضحة للتواصل مع الحواسيب، وهذا أمر مهم بشكل خاص بالنسبة للحواسيب. لا يمكننا التواصل مع الحواسيب باستخدام اللغة الطبيعية، لأن المعنى الكامل للغة الطبيعية يتميز بالغنى وقدرة التعبير. عندما تعبر عن الكلمات بنغمة مختلفة قليلاً أو تختار طريقة تعبير دقيقة مختلفة، فإن معنى جملتك أو فقرتك قد يتغير تمامًا.
وفي لغات البرمجة، الأمر الأكثر أهمية هو وجود دلالة محددة بدقة. عندما تكتب برنامجًا، تكون على دراية بما سيفعله. إذا قمت بإجراء تعديلات طفيفة عليه، فإنك تعرف النتائج التي سيترتب عليها هذا التغيير. يجب الحفاظ على هذه النقطة على عدة مستويات، على سبيل المثال، يمكنك كتابة الكود بلغة مصدر معينة، التي تحمل معنى ما، ثم يتم تحويلها إلى أشكال أخرى للتعبير، وبالتالي يجب أن تحتفظ بنفس المعنى، حتى عندما تصل إلى وحدات معالجة الآلات.
أعتقد أن طبيعة لغات البرمجة، على عكس اللغات الطبيعية، موجهة نحو مجالات معينة أو مهام محددة. خلاف ذلك، يمكن استخدام لغة برمجة واحدة فقط لإكمال جميع المهام. ولكن السبب في وجود لغات برمجة متعددة هو أنك لا يمكنك أن تكون جيدًا في جميع المجالات. إنها تسعى لتحقيق تحديد الأهداف لمجالات المشاكل المحددة، وتركز على حل هذه المشاكل. على سبيل المثال، إذا نظرت إلى لغة البرمجة Rust التي نستخدمها لكتابة سلسلة الكتل Sui ومعظم الأنظمة الأخرى التي تعمل في Mysten، فهي تركز على كتابة كود سريع وعالي الأداء، مع ضمان الأمان. إنها تتيح لك الوصول إلى تفاصيل منخفضة المستوى مثل الذاكرة، وهياكل الخيوط، أو التزامن، ولكنها لا تجعلك ترتكب الأخطاء كما كانت اللغات السابقة (مثل C أو C++).
لذلك، قصة Move مشابهة جدًا لذلك. عندما أنشأته، لم يكن الهدف هو خلق لغة جديدة. لقد ذكرت سابقًا ما يبحث عنه المطورون في لغة ما. سيسألون، "هل هذه اللغة مناسبة للمهمة التي أريد إنجازها؟" لكنني أعتقد أن ما هو أكثر أهمية هو، "هل تمتلك هذه اللغة مجتمعًا ضخمًا؟ هل هناك الكثير من قواعد البيانات المتاحة؟ هل هناك العديد من المبرمجين المستخدمين لها؟ هل هناك موارد تعليمية جيدة؟" كل هذه الأمور مهمة جدًا، لذلك يجب أن تكون عتبة إنشاء لغة جديدة مرتفعة جدًا، حتى لو كانت هذه اللغة أفضل في حد ذاتها، ولكن إذا لم يكن لديها تلك العوامل، فإن ميزتها تصبح بلا معنى. بناء مجتمع ضخم وحيوي من الصفر هو أمر صعب جدًا.
Q2، هل يمكنك مشاركة المزيد عن حالة تطوير Move؟
نشأت Move من مشروع Libra الخاص بفيسبوك. لم تكن مهمتي في ذلك الوقت هي إنشاء لغة جديدة، بل كانت "يحتاج Libra إلى عقود ذكية، لذا اكتشف ما يجب علينا فعله." نظرت إلى مجموعة متنوعة من الأشياء. هل يمكننا استخدام Solidity في EVM؟ هل يجب علينا استخدام لغة عامة تقليدية، مثل WASM أو JVM، واستخدامها لـ Libra؟ أم يجب علينا إنشاء شيء خاص بنا؟
إن قرار إنشاء شيء خاص بنا يستند إلى دراسة العقود الذكية الحالية، وفهم ما يحاول المبرمجون القيام به، والأماكن التي تساعدهم فيها بعض اللغات وتلك التي تخيب آمالهم. استنتجت أنه في العديد من الحالات، فإن لغات العقود الذكية الحالية تخيب آمالهم بالفعل.
يمكن رؤية هذه النقطة بوضوح من سجل الأمان السيئ لـ Solidity، لكن الأمر أكثر أساسية من ذلك، حيث أن هذه العقود الذكية ليست نوعًا تقليديًا جدًا من البرامج. Solidity ليست لغة مبنية لما يفعله الناس الآن. لا أريد انتقادها، لأنها كانت أول لغة للعقود الذكية، ولم تكن تعرف بعد ما الذي يريد الناس استخدامه من أجلها. بمجرد أن ترى ما يحاول الناس القيام به بها، أعتقد أنه من الواضح أنك بحاجة إلى مجموعة مختلفة من التجريدات وأدوات البرمجة، والتي لا توفرها لغة Solidity.
لذا فإن هذه العقود الذكية بسيطة جداً، فهي تقوم بشكل أساسي بعمل شيئين. فهي تحدد نوع الأصول، بما في ذلك متى يمكن نقل الأصل، وماذا يمكنك أن تفعل به، ومن يمكنه قراءته، وقواعد من يمكنه كتابته. وكذلك تحقق من سياسة التحكم في الوصول، لتحديد من يمتلك الأصل، ومن يُسمح له باستخدامه، ومن يُسمح له بالتلاعب به. كل شيء يدور حول الأصول، وترغب في أن تمتلك هذه الأصول خصائص مماثلة للأصول المادية. إذا سلمت شيئاً لك، فيجب أن تمتلكه، ولم أعد أملكه.
تحتوي العقود الذكية على مفهوم الملكية ونقل الملكية، ولكن على الكمبيوتر، كل شيء هو مجرد أرقام وبتات، ويمكن نسخه بحرية. وأنت تعلم أن هذه المفاهيم غير موجودة في العالم الحقيقي. لذلك، أنت ترغب في وجود لغة توفر لك تجريدًا جيدًا حول الملكية والتجانس. تمامًا كما هو الحال في العالم الحقيقي، ولكن دون الحاجة لإجبار المبرمجين على إعادة اختراعها. أنت تأمل في الحصول على ضمانات أساسية للأمان.
هذا هو دور Move ولماذا أنشأنا في النهاية هذه اللغة الجديدة. هذه المهام أساسية لبرمجة العقود الذكية. من الصعب إعادة إنشائها في لغات أخرى، بما في ذلك لغات العقود الذكية الحالية، ونأمل في تصميم اللغة بأكملها حول تقديم هذه الوظائف الأساسية، بحيث يمكن للمبرمجين كتابة التعليمات البرمجية بأمان وكفاءة دون الحاجة إلى إعادة اختراع العجلة في كل مرة يريدون فيها كتابة بعض التعليمات البرمجية.
Q3، استخدمت Sui متغيرًا من Move يسمى Sui Move. ما الذي دفع هذه التغييرات؟ ما هي الخصائص في Sui Move التي تجعلها مناسبة جدًا لبناء المنتجات في Web3؟
تسببت عدة عوامل في هذه التغييرات، أحدها هو أن الهدف من مشروع Libra الأصلي كان بناء شبكة مدفوعات متوافقة. لذلك، حاولنا تصميم Move كلغة عامة. لكننا قمنا بعمل بعض الأشياء عن وعي، لأن Libra كانت ترغب في وجود قيود. أحد الأمور المهمة هو أنهم لا يريدون أن يتمكن الناس من إرسال أصول معينة إلى أي مكان. كانوا يريدون من الناس إنشاء حسابات بشكل واضح، وتحديد بعض القواعد عند إنشاء الحساب، مثل أن مالك الحساب يجب أن يجري عملية التحقق من الهوية (KYC). أو قد يحتاج إلى دفع رسوم لإنشاء الحساب، أو يمكن أن يتم إنشاء الحساب فقط من قبل عدد قليل من الأشخاص الذين لديهم صلاحية إنشاء الحسابات. نظرًا لأن الهدف الكلي هو أن ترغب Libra في إجراء مدفوعات متوافقة والعقود الذكية المتوافقة، فهناك هذه القيود. ولكن في مجال Web3 الأكثر عمومية، الحالة هي العكس تمامًا. أنت لا ترغب في الالتزام على المستوى الأساسي، وهذا هو مفهوم العقود الذكية. أنت ترغب في أن تكون الأمور حرة قدر الإمكان، ويجب أن تتمكن تمامًا من إرسال شيء ما إلى أي عنوان. ثم يجب ألا تقوم بإنشاء حسابات بشكل صريح، لأن ذلك سيعيق مجموعة متنوعة من حالات الاستخدام. هذه نقطة مهمة.
عامل آخر هو أنه على الرغم من أننا ركزنا على الأصول في Move ، إلا أننا لم نفكر في كيفية إدخال تركيز الأصول في المعاملات نفسها أثناء وجودنا في Libra في ذلك الوقت. لذلك ، عندما تصل إلى مستوى المعاملة ، لا يزال لديك هذا API فقط ، حيث تدخل أرقامًا وقيمًا منطقية وما إلى ذلك ، وهي أشياء ليست أصولًا ، ثم في Move ، تستخدم هذه الأرقام لاستخراج الأصول من الحساب والقيام بأشياء أخرى. وقد تبين أن معظم الشيفرات التي تقوم بتشغيلها هي من هذا النوع من العمل الدفتري المزعج ، والذي يتضمن استخراج هذا الشيء ، واستخراج ذلك الشيء ، واستخراج أشياء أخرى ، حسنًا ، لدي جميع الأصول التي أريدها. إنها هنا ، في استوديوي ، والآن يمكنني البدء في القيام بشيء ذي معنى. ثم في نهاية هذه العملية ، قد تقول: "حسنًا ، أعد هذه الأصول إلى هذا الحساب ، وأعدها إلى ذلك الحساب ، وأعد تنظيمها.
في Sui، نحن نفكر بعمق، إذا كانت كل برنامج يبدأ وينتهي بهذه الطريقة، هل يمكننا تجريده؟ لذلك، فإن المنطق المستخدم لمعالجة المعاملات سيكون جاهزًا للبرمجيات، من وجهة نظر المبرمجين، هم فقط بحاجة إلى تجهيز الأصول المطلوبة، وبدء العمل الممتع على الفور. هذه هي نموذج البيانات القائم على الكائنات الموجود في Sui. في Move الأصلية، لدينا نموذج بيانات قائم على الحساب، حيث يتم تخزين الأصول تحت الحساب، ويجب على المبرمجين استخراجها بشكل صريح. أما في Sui، فإنه عند دخولهم إلى جزء Move من المعاملة، يتم الحصول بالفعل على الأصول من قبل وقت تشغيل Sui. هذا أكثر ملاءمة للمبرمجين، لأنه لا يحتاجون إلى القيام بكل هذا العمل المحاسبي من قبل ومن بعد، وهذا أيضًا هو السلاح السري الذي يسمح لنا بتحديد ما إذا كان يمكن تشغيل معاملة واحدة بالتوازي مع أخرى، وتوسيع Sui أفقيًا، وأداء بعض العمليات الأخرى بشكل أكثر كفاءة دون تنفيذ فعلي.
لقد قمنا أيضًا ببعض الأعمال المثيرة للاهتمام، مثل استخدام نموذج البيانات القائم على الكائنات لإنشاء كتل تداول قابلة للبرمجة. هذا موضوع تقني إلى حد ما، وأنا سعيد بالتعمق في المناقشة. لكن هذين العاملين هما الدافعان الرئيسيان للاختلاف عن Move الأصلية.
Q4، هل يمكنك مشاركة المزيد من المعلومات حول الكتل التجارية القابلة للبرمجة ووظائفها؟
أحب استخدام تشبيه لشرح ذلك، فblockchains الأخرى تشبه ساحة الطعام في مركز تجاري. إذا كنت تريد تناول الآيس كريم، تذهب إلى كشك الآيس كريم، وتخرج بطاقتك الائتمانية للدفع. ولكن إذا قررت أنك تريد أيضًا تناول همبرغر، فتذهب إلى كشك الهمبرغر، وتدفع مرة أخرى. لست شخصًا شغوفًا بالطعام، ولكن إذا كنت أرغب في تناول ثمانية أشياء، يجب أن أقوم بثماني معاملات منفصلة. بينما Sui تشبه البوفيه، حيث أن كل معاملة ليست مجرد شيء واحد. بمجرد أن تدفع تكلفة البوفيه، يمكنك القيام بالعديد من الأشياء دون دفع إضافي. يمكنك تناول الآيس كريم، يمكنك تناول الهمبرغر، يمكنك مزجهما معًا.
لجعل هذا المفهوم أكثر وضوحًا، في حالة بسيطة، إذا كنت تريد إرسال 100 معاملة لصك 100 NFT، يمكنك إرسال معاملة واحدة لصك 100 NFT. تكاليف مثل هذه المعاملة تكاد تكون مماثلة لتكلفة صك NFT واحد. يمكنك أيضًا القيام بتجميع المعاملات غير المتجانسة، على سبيل المثال، المعاملة الأولى في الكتلة تأخذ شخصية ماريو من محفظتك متعددة التوقيعات، بينما تطلب المعاملة الثانية شخصية ماريو، مما يسمح لك بلعب اللعبة. إذا فزت في اللعبة وحصلت على الكأس، ربما تكون المعاملة الثالثة هي وضع الكأس في خزانة الكؤوس المشتركة مع أصدقائك. الشيء الرائع هو أن كتل المعاملات القابلة للبرمجة تسمح للمبرمجين بكتابة التعليمات البرمجية بهذه الطريقة، حيث لا تحتاج اللعبة إلى معرفة كيفية تخزين المحفظة متعددة التوقيعات أو ماريو، ولا تحتاج أيضًا إلى معرفة خزانة الكؤوس الخاصة بك أو كيفية تنفيذها.
تتكون كتل التداول القابلة للبرمجة من معاملات تحتوي على كائنات إدخال وإخراج. إذا كنت بحاجة إلى كائن إدخال، يمكنك الحصول على هذا الكائن دون الحاجة للقلق بشأن مصدره، ثم تمرير مخرجاته إلى الكائن الذي يحتاج إليه، دون الحاجة أيضاً للقلق بشأن وجهته. في سلاسل الكتل الأخرى، يكون التماسك أقوى، لذا يجب أن تتكامل الألعاب مع المحافظ متعددة التوقيع وخزائن الجوائز، أو يجب أن تطبق جميعها بعض الواجهات المشتركة وتتمتع بتماسك أقوى. تجعل Sui ما يسمى بالتجمع المؤقت أسهل. كما لو أن الأنابيب تتطابق، يمكننا إكمال ذلك في معاملة واحدة.
س5، ما هي فوائد منطقة التداول القابلة للبرمجة للمستخدمين؟
تشمل فوائد الكتل القابلة للبرمجة للمستخدمين رسوم الغاز المنخفضة، لأنه يمكنك تجميع جميع العمليات في صفقة واحدة بدلاً من إجراء صفقات منفصلة. بالإضافة إلى ذلك، ستقل عدد الموافقات المطلوبة. إذا كان النظام الذي تستخدمه يتطلب موافقة على الصفقة، فستحتاج فقط إلى إجراء موافقة واحدة، ثم سيتم تنفيذ جميع العمليات دفعة واحدة. فائدة أخرى هي الذرية، إذا كنت تريد القيام بثلاثة أشياء مختلفة وتريد أن تنجح العملية الثالثة فقط إذا نجحت العمليتين الأوليين، إذا كانت هذه العمليات يجب أن تكون صفقات مستقلة، فلن تتمكن من تحقيق ذلك. ولكن إذا كان بإمكانك وضعها جميعًا في صفقة واحدة، فستتمكن من تحقيق ذلك بسهولة.
س6، لقد سمعتكم تتحدثون أن تطوير على Sui هو تجربة رائعة للمبرمجين، وهذا مهم. هل لديك أي قصص تود مشاركتها حول تجارب المبرمجين ذوي الخبرة والجدد عند البدء في استخدام Sui Move؟
بالنسبة لأولئك المطورين القادمين من لغات برمجة Web3 الأخرى، فإن تجربتهم في التطوير على Move وSui Move تكون أكثر كفاءة وأمانًا. لقد حضرت للتو برنامج بودكاست حول Bucket Protocol، وهم يبنون على Sui غير...