مقابلة مع والد لغة الحركة: لماذا تعتبر لغة العقد الذكية Sui Move مناسبة لبناء منتجات Web3؟

[مقابلة مع والد لغة النقل: لماذا تعتبر لغة العقد الذكية Sui Move مناسبة لبناء منتجات Web3؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-24288c0152-dd1a6f-7649e1)

تحدثنا مؤخرًا مع Sam Blackshear ، كبير مسؤولي التكنولوجيا في Mysten Labs ومبتكر لغة برمجة Move ، حول سبب تطويره Sui Move ، وهي لغة برمجة عقود ذكية جديدة ، والقدرات التي يمكن أن توفرها Sui ، وتأثير التكنولوجيا اللامركزية على بناء الفائدة. من المتلقي.

فيما يلي محتوى هذه المقابلة:

** س 1: أولاً ، هل يمكنك إعطاء نظرة عامة عن ماهية لغة البرمجة ، وما هي الصفات التي يبحث عنها المطورون أكثر عند اختيار لغة البرمجة ، وما الذي يدفعك إلى تطوير لغة البرمجة الخاصة بك؟ **

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

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

** أعتقد أن لغات البرمجة ذات طبيعة خاصة بمجال أو مهمة محددة ، على عكس اللغات الطبيعية. ** بخلاف ذلك باستخدام لغة برمجة واحدة فقط ، يمكنك فعل كل شيء. لكن السبب في وجود لغات برمجة متعددة هو أنك لا تستطيع أن تكون جيدًا في جميع المجالات. إنهم يحاولون استهداف مجالات مشكلة معينة والتركيز على حل تلك المشكلات. على سبيل المثال ، إذا نظرت إلى لغة البرمجة Rust التي نستخدمها لكتابة Sui blockchain ومعظم أعمال النظام الأخرى التي نقوم بها في Mysten ، فإنها تركز على كتابة التعليمات البرمجية التي تتسم بالسرعة والأداء مع الحفاظ على الأمان. يمنحك الوصول إلى تفاصيل منخفضة المستوى مثل الذاكرة أو هياكل الخيوط أو التزامن ، لكنه لا يسمح لك بارتكاب أخطاء مثل اللغات السابقة مثل C أو C ++.

لذا فإن قصة Move مشابهة جدًا لذلك. عندما قمت بإنشائه ، لم يكن لإنشاء لغة جديدة. لقد ذكرت سابقًا ما يبحث عنه المطورون في اللغة. يسألون ، "* هل هذه اللغة جيدة لما أحاول تحقيقه؟ " لكنني أعتقد أنه ربما يكون الأهم من ذلك ، " هل هذه اللغة بها مجتمع كبير؟ هل هناك العديد من قواعد البيانات المتاحة؟ هل هناك العديد من المبرمجين يستخدمونها؟ هل هناك موارد تعليمية جيدة؟ من الصعب جدًا بناء مجتمع كبير وحيوي من الصفر.

** Q2 、 **** هل يمكنك مشاركة المزيد حول تطوير Move؟ **

** نشأت الحركة من مشروع Libra على Facebook. ** لم تكن مهمتي في ذلك الوقت إنشاء لغة جديدة ، ولكن "* الميزان يحتاج إلى عقود ذكية ، لذا اكتشف ما يجب علينا فعله. *" نظرت في جميع أنواع الأشياء. هل يمكننا استخدام Solidity في EVM؟ هل يجب أن نأخذ لغة عامة للأغراض العادية ، مثل WASM أو JVM ، ونستخدمها في الميزان؟ أم يجب علينا إنشاء منطقتنا؟

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

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

لذا فإن هذه العقود الذكية بسيطة للغاية ، فهي تقوم في الأساس بأمرين. ** تحدد أنواع الأصول ، بما في ذلك القواعد الخاصة بوقت نقل الأصول ، وماذا يمكنك فعله بها ، ومن يمكنه قراءتها ، ومن يمكنه الكتابة إليها ****. **** وتحقق من سياسة التحكم في الوصول لتحديد من يملك الأصل ، ومن يُسمح له باستخدامه ، ومن يُسمح له بالعمل عليه. ** كل شيء يدور حول الأصول ، وتريد أن يكون لتلك الأصول نفس سمات الأصول المادية. إذا سلمتك شيئًا ما ، فيجب أن تحصل عليه ولن أحصل عليه بعد الآن.

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

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

** Q3 、 **** يستخدم Sui متغيرًا من Move يسمى Sui Move. ما الذي دفع هذه التغييرات؟ ما هي ميزات Sui Move المثالية لبناء المنتجات في Web3؟ **

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

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

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

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

** Q4 、 **** هل يمكنك من فضلك مشاركة المزيد من المعلومات حول كتل المعاملات القابلة للبرمجة ووظائفها؟ **

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

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

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

** Q5 、 **** ما هي فوائد كتل المعاملات القابلة للبرمجة للمستخدمين؟ **

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

** س 6 ، **** سمعت أنك وآخرون تتحدثون عن التطوير على Sui كتجربة رائعة للمبرمجين وهو أمر مهم. هل لديك أي حكايات لمشاركتها مع مبرمجي Web3 ذوي الخبرة والجدد الذين يبدؤون مع Sui Move؟ **

بالنسبة للمطورين القادمين من لغات برمجة Web3 الأخرى ، ** تعد تجربة التطوير الخاصة بهم في Move و Sui Move أكثر كفاءة وأمانًا **. لقد كنت للتو في بودكاست حول Bucket Protocol وهم يقومون ببناء مشروع DeFi رائع حقًا على Sui. أثناء إظهارهم لبنية النظام ، يصفون كيفية عمل المكونات المختلفة معًا. قالوا إنهم لو كتبوا هذا المشروع في Solidity ، فربما استغرق الأمر ثمانية أشهر ، لكن مع Sui Move استغرق الأمر شهرين فقط ، وهم واثقون جدًا من أمنه. الطريقة التي تعمل بها اللغة قريبة جدًا من فكرة وجود مجموعة من المشاريع في رؤوسهم. في عالم Solidity ، يكون الاتصال أقل مباشرة.

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

** يقولون إن ميزة المحرك الأول مهمة ، لكنني أعتقد في هذه الحالة ، أن ميزة المحرك المتأخر هي التي تهم أكثر. **

هذا صحيح ، هذا كل شيء.

** Q7 、 **** لقد تطرقت إلى هذا عندما ذكرت ميزات Sui Move و Sui الشاملة الموجهة للكائنات. ولكن هل يمكنك توضيح العلاقة بين تصميم Sui Move وقدرة Sui على تحقيق تبني Web3 الشامل ، وزمن وصول منخفض ، وتكلفة منخفضة ، وقابلية للتوسع بشكل أكثر وضوحًا؟ **

أحد الأشياء التي نتوخى الحذر الشديد حيالها من المساهمة في Sui ، والمشكلة التي تواجهها الأنظمة الأساسية الأخرى ، هي أنه إذا كانت لديك سعة محدودة ، سواء كان ذلك مثل 15 معاملة في الثانية (TPS) مثل Ethereum أو 100 أو 1000 معاملة ، إذا كان الأمر كذلك رقم ثابت ، فعندما تصبح المنصة ناجحة للغاية ، ستصل إلى الحد الأقصى من السعة. في هذه المرحلة ، تتدهور تجربة كل شخص يستخدم النظام الأساسي. إذا كان هناك 1000 وظيفة شاغرة فقط ، فيجب عليك اختيار أهم 1000 وظيفة ، والتي يمكن اختيارها من خلال مزايدة الغاز أو طرق أخرى. للجميع ، سترتفع أسعار الغاز ، سيزداد زمن الوصول ، أو كلاهما. تم استبعاد العديد من حالات الاستخدام ، حيث لن ينجح سوى أولئك القادرين على دفع أعلى الرسوم ، بينما سيتعين على الآخرين البحث في مكان آخر أو الانتظار لفترة أطول. هذا ليس وضعا جيدا.

** تستهدف Sui قابلية التوسع الأفقي. ** يمكن تحقيق قدر معين من الإنتاجية إذا تم تخصيص قدر معين من الأجهزة. في حالة الحاجة إلى مزيد من الإنتاجية ، يمكن للمدقق تقديم المزيد من تسهيلات الأجهزة ، بدون حد أعلى. هذه هي الطريقة التي تعمل بها كل خدمة Web2. أعني ، هناك بعض القيود الهندسية التي يتعين عليك حلها ، وهذا ليس بالأمر المؤكد أو السهل القيام به ، لكن الجميع يريد تحقيق قابلية التوسع الأفقي عند تصميم خدمات ويب قابلة للتطوير.

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

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

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

** Q8 、 **** على مستوى أعلى ، كيف تناقش إمكانات التكنولوجيا اللامركزية مع المطورين الذين يشككون في Web2؟ **

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

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

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

** Q9 、 **** بالنسبة للمستخدمين النهائيين ، حتى لو لم يكن لديهم معرفة تقنية ، هل تشعر بالتردد عندما يفكرون في الثقة في الكود ، حتى لو كان الخيار الآخر هو كيان مركزي كبير غير شفاف؟ **

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

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

** Q10 、 **** ما هي توقعاتك للتطوير المستقبلي لـ Sui Move؟ **

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

** نحن نعمل على الكثير من الميزات المتعلقة بهذا خاصة أنواع التعداد. ** نحن أيضًا نقوم بالكثير من العمل لتحسين تجربة ربط Move برمز الواجهة الأمامية. غالبًا ما نمزح أن تطبيق Sui النموذجي هو رمز نقل بنسبة 5٪ ورمز واجهة بنسبة 95٪. لذلك نحن نركز بشدة على 95٪. لقد أمضينا الكثير من الوقت في الحديث عن Move ، لكننا ركزنا أيضًا كثيرًا على جعل الأجزاء الأخرى أكثر كفاءة وتسهيل الاتصالات. بشكل عام ، نحن نركز بشدة على كيفية جعل التطبيق يتكون بشكل أكبر من Move لمزيد من الأمان. في الوقت نفسه ، كيف نجعل 95٪ من الشفرة مفهومة لكل من مبرمجي Move وغير مبرمجي Move.