Entretien avec le père du Move : pourquoi le langage de contrat intelligent Sui Move est-il adapté à la construction de produits Web3 ?
Récemment, nous avons parlé avec Sam Blackshear, le directeur technique de Mysten Labs et créateur du langage de programmation Move, pour discuter de pourquoi il a développé Sui Move, ce que Sui peut accomplir en termes d'évolutivité et des avantages que les technologies décentralisées apportent aux bâtisseurs.
Voici le contenu de cette interview :
Q1. Tout d'abord, pouvez-vous donner un aperçu de ce qu'est un langage de programmation, quelles sont les qualités les plus importantes que les développeurs recherchent en choisissant un langage de programmation, et qu'est-ce qui vous a poussé à développer votre propre langage de programmation ?
Les langages de programmation sont des outils permettant d'interagir de manière amicale, sécurisée, efficace et précise avec les ordinateurs. Cela est particulièrement important pour les ordinateurs. Nous ne pouvons pas communiquer avec les ordinateurs en utilisant un langage naturel, car tout le sens du langage naturel réside dans sa richesse et sa capacité d'expression.
Dans un langage de programmation, ce qui est le plus important, c'est d'avoir une sémantique précisément définie. Lorsque vous écrivez un programme, vous savez clairement ce qu'il va faire. Si vous apportez de petits ajustements, vous savez quel résultat ce changement va produire.
Je pense que, contrairement aux langages naturels, l'essence des langages de programmation est de cibler des domaines spécifiques ou des tâches spécifiques. Sinon, une seule langue de programmation pourrait suffire à accomplir toutes les tâches. Mais la raison pour laquelle il existe plusieurs langages de programmation, c'est que vous ne pouvez pas exceller dans tous les domaines. Ils s'efforcent de cibler des domaines de problèmes spécifiques et se concentrent sur la résolution de ces problèmes.
Ainsi, l'histoire de Move est très similaire à cela. Lorsque je l'ai créé, ce n'était pas pour créer un nouveau langage. Les développeurs, lorsqu'ils choisissent un langage, se posent la question : "Ce langage est-il adapté à la tâche que je veux accomplir ?" Mais je pense qu'il est peut-être plus important de se demander : "Ce langage a-t-il une grande communauté ? Y a-t-il beaucoup de bases de données disponibles ? Y a-t-il beaucoup de programmeurs qui l'utilisent ? Y a-t-il de bonnes ressources éducatives ?" Tout cela est très important, donc le seuil pour créer un nouveau langage doit être très élevé.
Q2, pouvez-vous partager plus d'informations sur le développement de Move ?
Move vient du projet Libra de Facebook. Ma tâche à l'époque n'était pas de créer un nouveau langage, mais de dire : "Libra a besoin de smart contracts, alors découvrons ce que nous devrions faire." J'ai examiné toutes sortes de choses. Pouvons-nous utiliser Solidity dans l'EVM ? Devons-nous utiliser un langage général conventionnel, comme WASM ou JVM, et l'appliquer à Libra ? Ou devrions-nous créer notre propre chose ?
La décision de créer quelque chose de notre propre initiative est basée sur l'étude des smart contracts existants, la compréhension de ce que les programmeurs essaient de faire et des domaines dans lesquels certains langages les aident et les déçoivent. Ma conclusion est que, dans de nombreux cas, les langages de smart contracts existants les déçoivent effectivement.
Cela se voit clairement dans le mauvais dossier de sécurité de Solidity, mais plus fondamentalement, ces smart contracts ne sont pas des types de programmes très traditionnels. Solidity n'est pas un langage construit pour les choses que les gens font actuellement.
Donc, ces smart contracts sont très simples, ils font essentiellement deux choses. Ils définissent le type d'actif, y compris quand l'actif peut être transféré, ce que vous pouvez en faire, qui peut les lire, et les règles qui gouvernent qui peut les écrire. Ils vérifient également les politiques de contrôle d'accès pour déterminer qui possède l'actif, qui est autorisé à l'utiliser et qui est autorisé à l'opérer. Tout tourne autour de l'actif, vous voulez que ces actifs aient les mêmes attributs que les actifs physiques.
Les smart contracts contiennent le concept de propriété et de transfert de propriété, mais sur un ordinateur, tout n'est que des chiffres et des octets, et peut être copié librement. De plus, vous savez que ces concepts n'existent pas dans le monde réel. Par conséquent, vous souhaitez avoir un langage qui puisse vous fournir une bonne abstraction sur la propriété et l'homogénéité. Comme dans le monde réel, mais sans obliger les programmeurs à le réinventer. Vous souhaitez obtenir des garanties de sécurité fondamentales.
C'est cela le rôle de Move et pourquoi nous avons finalement créé ce nouveau langage. Ces tâches sont fondamentales pour la programmation des smart contracts. Elles sont difficiles à recréer dans d'autres langages, y compris les langages de smart contracts existants. Nous souhaitons concevoir un langage entier autour de la fourniture de ces fonctionnalités de base, afin que les programmeurs puissent écrire du code de manière sûre et efficace, sans avoir à réinventer la roue à chaque fois qu'ils souhaitent écrire un certain code.
Q3, Sui utilise une variante de Move appelée Sui Move. Qu'est-ce qui a motivé ces changements ? Quelles caractéristiques de Sui Move sont particulièrement adaptées à la construction de produits dans le Web3 ?
Plusieurs facteurs ont contribué à ces changements, l'un d'eux étant que l'objectif initial du projet Libra était de construire un réseau de paiement conforme. Par conséquent, nous avons essayé de concevoir Move comme un langage universel. Mais nous avons également fait des choix délibérés, car Libra souhaitait avoir des conditions restrictives. L'une des choses importantes est qu'ils ne voulaient pas que les gens puissent envoyer certains actifs n'importe où. Ils voulaient que les gens créent explicitement un compte et établissent certaines règles lors de la création du compte, par exemple que le propriétaire du compte doit effectuer une vérification KYC. Ou il pourrait être nécessaire de payer des frais pour créer un compte, ou seuls un petit nombre de personnes ayant le droit de créer un compte pourraient le faire. Étant donné que l'objectif était que Libra souhaite effectuer des paiements conformes et des smart contracts conformes, ces restrictions existent. Mais dans le domaine plus général de Web3, c'est exactement le contraire. Vous ne souhaitez pas être conforme au niveau fondamental, c'est le concept des smart contracts. Vous voulez que les choses soient aussi libres que possible, et vous devez pouvoir envoyer quelque chose à n'importe quelle adresse. Ensuite, vous ne devez pas procéder à une création de compte explicite, car cela bloquerait divers cas d'utilisation. C'est un facteur important.
Un autre facteur est que, bien que nous nous concentrions sur les actifs dans Move, nous n'avons pas pris en compte à l'époque comment intégrer l'accent sur les actifs dans la transaction elle-même dans Libra. Ainsi, lorsque vous atteignez le niveau de la transaction, vous n'avez toujours que cette API, où vous entrez des chiffres et des valeurs booléennes, etc., qui ne sont pas des actifs, puis dans Move, vous utilisez ces chiffres pour extraire des actifs du compte et effectuer d'autres opérations. Il s'avère que la plupart du code que vous exécutez consiste en ce travail de livre déplaisant, qui implique de retirer cette chose, de retirer cette autre chose, de retirer d'autres choses, d'accord, j'ai tous les actifs que je veux. Ils sont ici, dans mon studio, maintenant je peux commencer à faire quelque chose de significatif. Puis à la fin de ce processus, vous pourriez dire : "D'accord, remettez ces actifs dans ce compte, remettez-les dans cet autre compte, réorganisez-les."
Dans Sui, nous avons réfléchi profondément à la question de savoir si nous pouvions abstraire le fait que chaque programme commence et se termine de cette manière. Ainsi, la logique pour traiter les transactions sera réalisée par le programmeur, qui, de son point de vue, n'a qu'à préparer les actifs nécessaires et peut immédiatement commencer à travailler sur des tâches intéressantes. C'est le modèle de données centré sur les objets qui existe dans Sui. Dans le Move original, nous avons un modèle de données basé sur les comptes, où les actifs sont stockés sous les comptes et où les programmeurs doivent les extraire explicitement. En revanche, dans Sui, au moment où ils entrent dans la partie Move de la transaction, les actifs sont déjà récupérés par l'exécution de Sui. Cela est plus pratique pour les programmeurs, car ils n'ont pas à effectuer tout ce travail de comptabilité avant et après, et c'est aussi l'arme secrète qui nous permet de déterminer sans exécution réelle si une transaction peut être exécutée en parallèle avec une autre, d'assurer l'évolutivité horizontale de Sui et d'effectuer d'autres opérations de manière plus efficace.
Nous avons également effectué d'autres travaux très intéressants, comme l'utilisation de modèles de données basés sur des objets pour des blocs de transaction programmables. C'est un sujet plutôt technique, et je serais ravi d'en discuter plus en profondeur. Mais ces deux facteurs sont les principaux moteurs de la divergence par rapport à l'original Move.
Q4, pouvez-vous partager plus d'informations sur les blocs de transaction programmables et leurs fonctionnalités ?
J'aime utiliser une analogie pour expliquer, d'autres blockchains ressemblent à une aire de restauration dans un centre commercial. Si vous voulez manger une glace, vous allez au stand de glaces et sortez votre carte de crédit pour payer. Mais si vous décidez que vous voulez aussi un hamburger, vous allez au stand de hamburgers et payez à nouveau. Je ne suis pas une personne gloutonne, mais si je veux manger huit choses, je dois effectuer huit transactions distinctes. Sui est plus comme un buffet, chaque transaction n'est pas qu'une seule chose. Une fois que vous avez payé le coût du buffet, vous pouvez faire beaucoup de choses sans débourser d'argent supplémentaire. Vous pouvez manger de la glace, vous pouvez manger un hamburger, vous pouvez les mélanger.
Pour rendre ce concept un peu plus concret, dans un cas simple, si vous devez envoyer 100 transactions pour frapper 100 NFT, vous pouvez envoyer une transaction pour frapper 100 NFT. Le coût de cela est presque identique à celui de frapper un NFT. Vous pouvez également effectuer un emballage de transactions hétérogènes, par exemple, la première transaction dans le bloc retire un personnage Mario de votre portefeuille multi-signatures, tandis que la deuxième transaction demande un Mario, puis vous permet de jouer au jeu. Si vous gagnez le jeu et obtenez un trophée, peut-être que la troisième transaction placera le trophée dans une vitrine partagée avec des amis. Ce qui est cool, c'est que les blocs de transactions programmables permettent aux programmeurs d'écrire du code de cette manière, le jeu n'a pas besoin de connaître le portefeuille multi-signatures ou la manière dont Mario est stocké, il n'a pas non plus besoin de connaître votre vitrine ou la manière dont elle est mise en œuvre.
Les blocs de transactions programmables sont composés de transactions ayant des objets d'entrée et de sortie. Si vous avez besoin d'un objet d'entrée, vous pouvez obtenir cet objet sans vous soucier de son origine, puis transmettre sa sortie à l'objet qui en a besoin, sans avoir à vous soucier non plus de sa destination. Dans d'autres blockchains, la couplage est plus fort, donc les jeux doivent s'intégrer à des portefeuilles multi-signatures et des vitrines de trophées, ou ils doivent tous mettre en œuvre certaines interfaces communes et avoir un couplage plus fort. Sui facilite les soi-disant combinaisons temporaires. Comme si les canalisations correspondent, nous pouvons accomplir cela en une seule transaction.
Q5, quels sont les avantages des blocs de transactions programmables pour les utilisateurs ?
Pour les utilisateurs, les avantages des blocs de transactions programmables incluent des frais de gaz plus bas, car vous pouvez regrouper toutes les opérations en une seule transaction, au lieu de faire des transactions séparées. De plus, le nombre d'approbations nécessaires sera également réduit. Si le système que vous utilisez nécessite une approbation de transaction, vous n'avez besoin de faire une seule approbation, puis il effectuera toutes les opérations en une fois. Un autre avantage est l'atomicité ; si vous voulez faire trois choses différentes et que vous souhaitez que la troisième ne réussisse que si les deux premières opérations réussissent, vous ne pouvez pas réaliser cela si ces opérations doivent être des transactions indépendantes. Cependant, si vous pouvez les placer toutes dans une seule transaction, vous pouvez facilement y parvenir.
Q6, J'ai entendu dire que vous et d'autres parliez du fait que développer sur Sui est une expérience formidable pour les programmeurs, et c'est important. Avez-vous des anecdotes à partager pour les programmeurs Web3 expérimentés et nouveaux qui commencent à utiliser Sui Move ?
Pour les développeurs venant d'autres langages de programmation Web3, leur expérience de développement sur Move et Sui Move est effectivement plus efficace et plus sécurisée. Je viens de participer à un podcast sur le Bucket Protocol, où ils construisent un projet DeFi très cool sur Sui. Lorsqu'ils ont présenté l'architecture du système, ils ont expliqué comment les différents composants travaillaient ensemble. Ils ont dit que s'ils avaient utilisé Solidity pour rédiger ce projet, cela aurait pu prendre huit mois, mais avec Sui Move, cela n'a pris que deux mois, et ils ont une grande confiance en sa sécurité. La façon dont ce langage fonctionne est très proche de l'idée de leur portefeuille de projets. En revanche, dans le domaine de Solidity, ce lien n'est pas aussi direct.
C'est juste un exemple, mais nous avons entendu beaucoup de cas similaires, des gens disant qu'ils développaient plus rapidement dans ce langage et se sentaient plus confiants une fois terminé. Cela me rend heureux d'entendre cela. Mais d'une certaine manière, ce n'est pas surprenant, nous avons étudié Solidity et compris ses problèmes. Nous avons conçu explicitement des solutions sur la façon de le rendre plus sûr et plus rapide. Nous avons examiné ce que les développeurs utilisant ce langage essayaient de faire et comment concevoir un langage qui réponde à leurs besoins, plutôt que de s'adapter à des situations existantes. Ce langage est conçu pour les problèmes que les gens rencontrent, donc quand ils passent à celui-ci, ils l'apprécient vraiment.
Ils disent que l'avantage du premier arrivé est important, mais je pense que dans ce cas, l'avantage du dernier arrivé est plus important.
C'est exactement ça.
Interprétation du fondateur de Move : pourquoi Sui Move est mieux adapté à la construction de produits Web3.
Entretien avec le père du Move : pourquoi le langage de contrat intelligent Sui Move est-il adapté à la construction de produits Web3 ?
Récemment, nous avons parlé avec Sam Blackshear, le directeur technique de Mysten Labs et créateur du langage de programmation Move, pour discuter de pourquoi il a développé Sui Move, ce que Sui peut accomplir en termes d'évolutivité et des avantages que les technologies décentralisées apportent aux bâtisseurs.
Voici le contenu de cette interview :
Q1. Tout d'abord, pouvez-vous donner un aperçu de ce qu'est un langage de programmation, quelles sont les qualités les plus importantes que les développeurs recherchent en choisissant un langage de programmation, et qu'est-ce qui vous a poussé à développer votre propre langage de programmation ?
Les langages de programmation sont des outils permettant d'interagir de manière amicale, sécurisée, efficace et précise avec les ordinateurs. Cela est particulièrement important pour les ordinateurs. Nous ne pouvons pas communiquer avec les ordinateurs en utilisant un langage naturel, car tout le sens du langage naturel réside dans sa richesse et sa capacité d'expression.
Dans un langage de programmation, ce qui est le plus important, c'est d'avoir une sémantique précisément définie. Lorsque vous écrivez un programme, vous savez clairement ce qu'il va faire. Si vous apportez de petits ajustements, vous savez quel résultat ce changement va produire.
Je pense que, contrairement aux langages naturels, l'essence des langages de programmation est de cibler des domaines spécifiques ou des tâches spécifiques. Sinon, une seule langue de programmation pourrait suffire à accomplir toutes les tâches. Mais la raison pour laquelle il existe plusieurs langages de programmation, c'est que vous ne pouvez pas exceller dans tous les domaines. Ils s'efforcent de cibler des domaines de problèmes spécifiques et se concentrent sur la résolution de ces problèmes.
Ainsi, l'histoire de Move est très similaire à cela. Lorsque je l'ai créé, ce n'était pas pour créer un nouveau langage. Les développeurs, lorsqu'ils choisissent un langage, se posent la question : "Ce langage est-il adapté à la tâche que je veux accomplir ?" Mais je pense qu'il est peut-être plus important de se demander : "Ce langage a-t-il une grande communauté ? Y a-t-il beaucoup de bases de données disponibles ? Y a-t-il beaucoup de programmeurs qui l'utilisent ? Y a-t-il de bonnes ressources éducatives ?" Tout cela est très important, donc le seuil pour créer un nouveau langage doit être très élevé.
Q2, pouvez-vous partager plus d'informations sur le développement de Move ?
Move vient du projet Libra de Facebook. Ma tâche à l'époque n'était pas de créer un nouveau langage, mais de dire : "Libra a besoin de smart contracts, alors découvrons ce que nous devrions faire." J'ai examiné toutes sortes de choses. Pouvons-nous utiliser Solidity dans l'EVM ? Devons-nous utiliser un langage général conventionnel, comme WASM ou JVM, et l'appliquer à Libra ? Ou devrions-nous créer notre propre chose ?
La décision de créer quelque chose de notre propre initiative est basée sur l'étude des smart contracts existants, la compréhension de ce que les programmeurs essaient de faire et des domaines dans lesquels certains langages les aident et les déçoivent. Ma conclusion est que, dans de nombreux cas, les langages de smart contracts existants les déçoivent effectivement.
Cela se voit clairement dans le mauvais dossier de sécurité de Solidity, mais plus fondamentalement, ces smart contracts ne sont pas des types de programmes très traditionnels. Solidity n'est pas un langage construit pour les choses que les gens font actuellement.
Donc, ces smart contracts sont très simples, ils font essentiellement deux choses. Ils définissent le type d'actif, y compris quand l'actif peut être transféré, ce que vous pouvez en faire, qui peut les lire, et les règles qui gouvernent qui peut les écrire. Ils vérifient également les politiques de contrôle d'accès pour déterminer qui possède l'actif, qui est autorisé à l'utiliser et qui est autorisé à l'opérer. Tout tourne autour de l'actif, vous voulez que ces actifs aient les mêmes attributs que les actifs physiques.
Les smart contracts contiennent le concept de propriété et de transfert de propriété, mais sur un ordinateur, tout n'est que des chiffres et des octets, et peut être copié librement. De plus, vous savez que ces concepts n'existent pas dans le monde réel. Par conséquent, vous souhaitez avoir un langage qui puisse vous fournir une bonne abstraction sur la propriété et l'homogénéité. Comme dans le monde réel, mais sans obliger les programmeurs à le réinventer. Vous souhaitez obtenir des garanties de sécurité fondamentales.
C'est cela le rôle de Move et pourquoi nous avons finalement créé ce nouveau langage. Ces tâches sont fondamentales pour la programmation des smart contracts. Elles sont difficiles à recréer dans d'autres langages, y compris les langages de smart contracts existants. Nous souhaitons concevoir un langage entier autour de la fourniture de ces fonctionnalités de base, afin que les programmeurs puissent écrire du code de manière sûre et efficace, sans avoir à réinventer la roue à chaque fois qu'ils souhaitent écrire un certain code.
Q3, Sui utilise une variante de Move appelée Sui Move. Qu'est-ce qui a motivé ces changements ? Quelles caractéristiques de Sui Move sont particulièrement adaptées à la construction de produits dans le Web3 ?
Plusieurs facteurs ont contribué à ces changements, l'un d'eux étant que l'objectif initial du projet Libra était de construire un réseau de paiement conforme. Par conséquent, nous avons essayé de concevoir Move comme un langage universel. Mais nous avons également fait des choix délibérés, car Libra souhaitait avoir des conditions restrictives. L'une des choses importantes est qu'ils ne voulaient pas que les gens puissent envoyer certains actifs n'importe où. Ils voulaient que les gens créent explicitement un compte et établissent certaines règles lors de la création du compte, par exemple que le propriétaire du compte doit effectuer une vérification KYC. Ou il pourrait être nécessaire de payer des frais pour créer un compte, ou seuls un petit nombre de personnes ayant le droit de créer un compte pourraient le faire. Étant donné que l'objectif était que Libra souhaite effectuer des paiements conformes et des smart contracts conformes, ces restrictions existent. Mais dans le domaine plus général de Web3, c'est exactement le contraire. Vous ne souhaitez pas être conforme au niveau fondamental, c'est le concept des smart contracts. Vous voulez que les choses soient aussi libres que possible, et vous devez pouvoir envoyer quelque chose à n'importe quelle adresse. Ensuite, vous ne devez pas procéder à une création de compte explicite, car cela bloquerait divers cas d'utilisation. C'est un facteur important.
Un autre facteur est que, bien que nous nous concentrions sur les actifs dans Move, nous n'avons pas pris en compte à l'époque comment intégrer l'accent sur les actifs dans la transaction elle-même dans Libra. Ainsi, lorsque vous atteignez le niveau de la transaction, vous n'avez toujours que cette API, où vous entrez des chiffres et des valeurs booléennes, etc., qui ne sont pas des actifs, puis dans Move, vous utilisez ces chiffres pour extraire des actifs du compte et effectuer d'autres opérations. Il s'avère que la plupart du code que vous exécutez consiste en ce travail de livre déplaisant, qui implique de retirer cette chose, de retirer cette autre chose, de retirer d'autres choses, d'accord, j'ai tous les actifs que je veux. Ils sont ici, dans mon studio, maintenant je peux commencer à faire quelque chose de significatif. Puis à la fin de ce processus, vous pourriez dire : "D'accord, remettez ces actifs dans ce compte, remettez-les dans cet autre compte, réorganisez-les."
Dans Sui, nous avons réfléchi profondément à la question de savoir si nous pouvions abstraire le fait que chaque programme commence et se termine de cette manière. Ainsi, la logique pour traiter les transactions sera réalisée par le programmeur, qui, de son point de vue, n'a qu'à préparer les actifs nécessaires et peut immédiatement commencer à travailler sur des tâches intéressantes. C'est le modèle de données centré sur les objets qui existe dans Sui. Dans le Move original, nous avons un modèle de données basé sur les comptes, où les actifs sont stockés sous les comptes et où les programmeurs doivent les extraire explicitement. En revanche, dans Sui, au moment où ils entrent dans la partie Move de la transaction, les actifs sont déjà récupérés par l'exécution de Sui. Cela est plus pratique pour les programmeurs, car ils n'ont pas à effectuer tout ce travail de comptabilité avant et après, et c'est aussi l'arme secrète qui nous permet de déterminer sans exécution réelle si une transaction peut être exécutée en parallèle avec une autre, d'assurer l'évolutivité horizontale de Sui et d'effectuer d'autres opérations de manière plus efficace.
Nous avons également effectué d'autres travaux très intéressants, comme l'utilisation de modèles de données basés sur des objets pour des blocs de transaction programmables. C'est un sujet plutôt technique, et je serais ravi d'en discuter plus en profondeur. Mais ces deux facteurs sont les principaux moteurs de la divergence par rapport à l'original Move.
Q4, pouvez-vous partager plus d'informations sur les blocs de transaction programmables et leurs fonctionnalités ?
J'aime utiliser une analogie pour expliquer, d'autres blockchains ressemblent à une aire de restauration dans un centre commercial. Si vous voulez manger une glace, vous allez au stand de glaces et sortez votre carte de crédit pour payer. Mais si vous décidez que vous voulez aussi un hamburger, vous allez au stand de hamburgers et payez à nouveau. Je ne suis pas une personne gloutonne, mais si je veux manger huit choses, je dois effectuer huit transactions distinctes. Sui est plus comme un buffet, chaque transaction n'est pas qu'une seule chose. Une fois que vous avez payé le coût du buffet, vous pouvez faire beaucoup de choses sans débourser d'argent supplémentaire. Vous pouvez manger de la glace, vous pouvez manger un hamburger, vous pouvez les mélanger.
Pour rendre ce concept un peu plus concret, dans un cas simple, si vous devez envoyer 100 transactions pour frapper 100 NFT, vous pouvez envoyer une transaction pour frapper 100 NFT. Le coût de cela est presque identique à celui de frapper un NFT. Vous pouvez également effectuer un emballage de transactions hétérogènes, par exemple, la première transaction dans le bloc retire un personnage Mario de votre portefeuille multi-signatures, tandis que la deuxième transaction demande un Mario, puis vous permet de jouer au jeu. Si vous gagnez le jeu et obtenez un trophée, peut-être que la troisième transaction placera le trophée dans une vitrine partagée avec des amis. Ce qui est cool, c'est que les blocs de transactions programmables permettent aux programmeurs d'écrire du code de cette manière, le jeu n'a pas besoin de connaître le portefeuille multi-signatures ou la manière dont Mario est stocké, il n'a pas non plus besoin de connaître votre vitrine ou la manière dont elle est mise en œuvre.
Les blocs de transactions programmables sont composés de transactions ayant des objets d'entrée et de sortie. Si vous avez besoin d'un objet d'entrée, vous pouvez obtenir cet objet sans vous soucier de son origine, puis transmettre sa sortie à l'objet qui en a besoin, sans avoir à vous soucier non plus de sa destination. Dans d'autres blockchains, la couplage est plus fort, donc les jeux doivent s'intégrer à des portefeuilles multi-signatures et des vitrines de trophées, ou ils doivent tous mettre en œuvre certaines interfaces communes et avoir un couplage plus fort. Sui facilite les soi-disant combinaisons temporaires. Comme si les canalisations correspondent, nous pouvons accomplir cela en une seule transaction.
Q5, quels sont les avantages des blocs de transactions programmables pour les utilisateurs ?
Pour les utilisateurs, les avantages des blocs de transactions programmables incluent des frais de gaz plus bas, car vous pouvez regrouper toutes les opérations en une seule transaction, au lieu de faire des transactions séparées. De plus, le nombre d'approbations nécessaires sera également réduit. Si le système que vous utilisez nécessite une approbation de transaction, vous n'avez besoin de faire une seule approbation, puis il effectuera toutes les opérations en une fois. Un autre avantage est l'atomicité ; si vous voulez faire trois choses différentes et que vous souhaitez que la troisième ne réussisse que si les deux premières opérations réussissent, vous ne pouvez pas réaliser cela si ces opérations doivent être des transactions indépendantes. Cependant, si vous pouvez les placer toutes dans une seule transaction, vous pouvez facilement y parvenir.
Q6, J'ai entendu dire que vous et d'autres parliez du fait que développer sur Sui est une expérience formidable pour les programmeurs, et c'est important. Avez-vous des anecdotes à partager pour les programmeurs Web3 expérimentés et nouveaux qui commencent à utiliser Sui Move ?
Pour les développeurs venant d'autres langages de programmation Web3, leur expérience de développement sur Move et Sui Move est effectivement plus efficace et plus sécurisée. Je viens de participer à un podcast sur le Bucket Protocol, où ils construisent un projet DeFi très cool sur Sui. Lorsqu'ils ont présenté l'architecture du système, ils ont expliqué comment les différents composants travaillaient ensemble. Ils ont dit que s'ils avaient utilisé Solidity pour rédiger ce projet, cela aurait pu prendre huit mois, mais avec Sui Move, cela n'a pris que deux mois, et ils ont une grande confiance en sa sécurité. La façon dont ce langage fonctionne est très proche de l'idée de leur portefeuille de projets. En revanche, dans le domaine de Solidity, ce lien n'est pas aussi direct.
C'est juste un exemple, mais nous avons entendu beaucoup de cas similaires, des gens disant qu'ils développaient plus rapidement dans ce langage et se sentaient plus confiants une fois terminé. Cela me rend heureux d'entendre cela. Mais d'une certaine manière, ce n'est pas surprenant, nous avons étudié Solidity et compris ses problèmes. Nous avons conçu explicitement des solutions sur la façon de le rendre plus sûr et plus rapide. Nous avons examiné ce que les développeurs utilisant ce langage essayaient de faire et comment concevoir un langage qui réponde à leurs besoins, plutôt que de s'adapter à des situations existantes. Ce langage est conçu pour les problèmes que les gens rencontrent, donc quand ils passent à celui-ci, ils l'apprécient vraiment.
Ils disent que l'avantage du premier arrivé est important, mais je pense que dans ce cas, l'avantage du dernier arrivé est plus important.
C'est exactement ça.
![Entretien avec le père du langage Move : Pourquoi le langage de smart contracts Sui Move est-il adapté à la construction de produits Web3 ?](