AMA sur le bridge d’Alephium — partie 2 — La feuille de route
Un mois après la sortie du bridge sur le mainnet, Cheng, Hongchao et Maud ont été interviewés par Vladimir dans un AMA Twitter space. Vous pouvez écouter le Twitter space ici, ou lire la suite à votre rythme ! Cet article est une version légèrement éditée de l’AMA, afin d’en améliorer la clarté et la lisibilité. Il s’agit de la partie 2 sur 3, et vous pouvez trouver la partie 1 ici.
La feuille de route
Après avoir franchi des étapes importantes, il y a toujours une période d’adaptation pendant laquelle nous passons à la phase suivante. Comme notre équipe est composée de builders qui donnent la priorité au développement, nous avons toujours une liste de choses que nous voulons construire à court et à long terme. Souvent, nous travaillons sur plusieurs projets simultanément. Avec le lancement du wallet mobile et du bridge, notre attention se tourne vers les optimisations futures et les nouveaux développements, le prochain projet majeur étant la mise à jour du réseau.
Vladimir : Cheng a fait allusion à la prochaine mise à jour du réseau sur Discord. Pourriez-vous nous donner plus de détails sur cette mise à jour ? Plus précisément, quels sont les points essentiels de la prochaine mise à jour et quel est le calendrier prévu pour sa mise en œuvre ?
Cheng : La première mise à jour du réseau, Leman, a été énorme. Elle a amélioré Alephium de manière significative, permettant les dapps actuelles. Cette mise à jour a été conçue parallèlement au développement du bridge et du DEX. Parmi les principales caractéristiques, citons le système de sous-traitance des dApps, le système APS et un nouvel algorithme d’ajustement de la difficulté pour stabiliser les changements de difficulté sur différents canaux. Étant donné qu’il s’agissait de la première mise à jour du réseau pour une nouvelle couche avec une nouvelle machine virtuelle et un nouveau langage de programmation, il fallait s’attendre à quelques améliorations après le lancement.
Depuis lors, les fondations se sont avérées solides, comme en témoigne le développement réussi de produits tels que le DEX, le bridge et la marketplace NFT Deadrare. Nous avons également reçu de précieux commentaires de la part de la communauté et des développeurs. La prochaine mise à jour se concentrera sur l’amélioration de la blockchain sur la base de ces commentaires, en ciblant spécifiquement les expériences des utilisateurs et des développeurs. Cet objectif vise à répondre aux commentaires les plus courants et devrait stimuler considérablement l’adoption de la blockchain.
Vladimir : Pouvez-vous nous en dire plus sur la réduction du “ block time “ ? Vous en avez parlé plusieurs fois sur Discord. Pourquoi avez-vous décidé que c’était l’une des priorités ? La réduction du “block time” est-elle sûre ?
Cheng : La réduction du “block time” est un sujet très débattu dans le domaine du “proof-of-work, et il n’y a pas de consensus sur le block time idéal pour les blockchains de “proof-of-work”. Des temps de bloc plus longs signifient une chaîne plus légère en termes de stockage et de calcul par l’unité centrale, car le taux de blocs non-classés/orphelins est plus faible. Toutefois, des “block time” plus courts sont plus conviviaux, en particulier pour les utilisateurs non techniques, car ils n’ont pas à se demander pourquoi les transactions prennent tant de temps à être incluses dans la blockchain. Des “block time” plus courts présentent également des avantages techniques, tels qu’un mempool plus petit dans les cas normaux, ce qui simplifie le développement à la fois du côté du nœud complet et des applications qui interagissent avec le mempool.
Le défi consiste à trouver un équilibre qui permette à la blockchain de fonctionner efficacement, même à grande échelle, à l’instar de réseaux tels que Bitcoin ou Ethereum. Une préoccupation majeure est le temps de propagation des blocs dans les grands réseaux ; un temps de propagation trop court pourrait augmenter le nombre de blocs orphelins ou non nettoyés, ce qui nuirait à la sécurité du réseau. Actuellement, les paramètres sélectionnés par Ethereum représentent un choix solide. Nous prévoyons d’adopter une approche similaire pour notre prochaine mise à jour, mais il pourrait être possible de réduire davantage le temps de propagation des blocs à long terme.
Je tiens à souligner que la réduction du temps du “block time” peut avoir des répercussions sur la sécurité. Par exemple, une réduction de 10 à 20 secondes pourrait entraîner un taux d’orphelins d’environ 15 %, ce qui signifie une compromission potentielle de 15 % de la sécurité. Toutefois, il existe des méthodes pour atténuer ce problème, comme l’algorithme Ghost. Cet algorithme incorpore les hachages des blocs orphelins dans de nouveaux blocs, ce qui garantit que les efforts déployés pour créer ces blocs orphelins ne sont pas gaspillés et qu’ils font toujours partie de la blockchain principale. En contrepartie, les besoins en stockage augmentent, car davantage de données seront stockées sur le disque.
Ce compromis est acceptable pour Alephium, qui est conçue comme une blockchain légère et efficace. Un “block time” de 16 secondes est actuellement réalisable pour Alephium. Il est possible de réduire davantage le “block time” en fonction de l’évolution annuelle de la bande passante et des capacités de l’unité centrale. Cela signifie que la propagation et la validation des blocs deviennent plus rapides chaque année. Le taux d’orphelins n’est donc pas un problème.
Vladimir : Vous dites donc que notre objectif actuel est de réduire le “block time” de 64 secondes à 16 secondes. Ce faisant, nous visons à maintenir le même niveau de sécurité tout en augmentant sensiblement la vitesse des transactions. La seule contrepartie de cette amélioration serait une légère augmentation des besoins en stockage.
Cheng : Exactement, c’est ainsi que l’on peut résumer la situation.
Vladimir : La multiplication par quatre du nombre de blocs dans le même laps de temps signifie-t-elle que chaque bloc ne recevra qu’un quart de la récompense précédente ? Et quels sont les compromis potentiels, en particulier en ce qui concerne l’impact sur la vitesse d’émission des tokens ?
Cheng : Nous prévoyons d’ajuster les émissions de tokens afin de garantir que l’émission totale reste cohérente. Cela signifie que le protocole émettra globalement la même quantité de tokens.
Lorsque nous réduisons le “block time” de 64 secondes à 16 secondes, la récompense du bloc est divisée par quatre. Cependant, cet ajustement seul est insuffisant en raison de la présence de blocs orphelins dans la blockchain, similaires à la version “proof-of-work” d’Ethereum. Par conséquent, nous récompenserons également les mineurs pour ces blocs orphelins. Pour ce faire, nous devons allouer une partie de la récompense de la chaîne principale à ces blocs orphelins. Pour y parvenir efficacement, nous devons d’abord estimer le taux de blocs orphelins. Nous prévoyons d’utiliser les données de la chaîne “proof-of-work” d’Ethereum comme référence, en procédant aux ajustements nécessaires pour les adapter à notre contexte.
Vladimir : Dans l’ensemble, cela ne change rien au calendrier d’émission des tokens. Cela ne change pas grand-chose pour les mineurs non plus, n’est-ce pas ?
Cheng : La modification de la durée des blocs ne changera pas l’émission globale.
Vladimir : Pouvez-vous expliquer ce que signifie l’abstraction de groupe et pourquoi elle est importante ? Cela signifie-t-il que je n’aurai plus jamais à me demander sur quel groupe je crée une adresse ? Comment l’abstraction de groupe fonctionne-t-elle avec les dApps ?
Hongchao : La nécessité d’une abstraction de groupe découle de notre architecture shardée, qui, tout en améliorant l’évolutivité, peut présenter certains inconvénients. Par exemple, avec des adresses existant dans différents groupes, les applications déployées dans un groupe ne sont accessibles que par les adresses de ce groupe spécifique. Il est important de noter que cette limitation ne s’applique pas aux transferts de tokens. Vous pouvez librement transférer des tokens d’une adresse d’un groupe à une adresse de n’importe quel autre groupe sans problème. Par conséquent, lorsque nous parlons d’abstraction de groupe, cela concerne spécifiquement les scénarios dans lesquels les adresses et les applications se trouvent dans des groupes différents, voire dans plusieurs groupes.
Comment le wallet et les dApps interagissent-ils pour offrir aux utilisateurs une expérience fluide ? Par exemple, la marketplace NFT est actuellement déployée dans le groupe zéro, ce qui oblige les utilisateurs à avoir une adresse dans ce groupe. Si un utilisateur possède une adresse dans le groupe 2 et souhaite acheter un NFT, le processus n’est pas transparent pour le moment. Avant de procéder à l’achat, il doit créer une adresse dans le groupe zéro et transférer manuellement les tokens de son adresse du groupe deux vers cette nouvelle adresse.
Ce n’est pas une expérience optimale. Cependant, le wallet a la possibilité d’automatiser ce processus, en gérant ces transferts et ces interactions de manière plus efficace. Par exemple, si un utilisateur souhaite acheter quelque chose sur la marketplace NFT déployée dans le groupe zéro, mais que son adresse se trouve dans le groupe deux, le wallet pourrait automatiquement créer une adresse dans le groupe zéro pour lui. Il pourrait alors transférer les tokens nécessaires à cette nouvelle adresse, effectuer l’achat et retransférer l’article acheté à l’adresse du groupe deux de l’utilisateur. Ce processus éliminerait le besoin de transferts manuels et de gestion des adresses de la part de l’utilisateur.
Ce scénario n’est qu’un exemple de la manière dont nous pouvons abstraire le concept de groupe pour améliorer le parcours de l’utilisateur. L’efficacité de cette abstraction dépend largement de la manière dont la dApp est écrite. Pour obtenir une expérience transparente, il faut un effort coordonné entre la dApp et le wallet, ce qui est un aspect clé de ce que je considère comme l’abstraction de groupe dans la fonctionnalité du wallet.
Vladimir : L’objectif est donc que les gens ne s’inquiètent pas des groupes lorsqu’ils utilisent le wallet.
Hongchao : Je ne sais pas s’il est possible d’éliminer complètement ce problème, l’objectif est de le minimiser de manière significative. L’objectif est de s’assurer que cela ne devienne pas un problème majeur pour l’expérience utilisateur (UX), car c’est actuellement l’une des principales plaintes des utilisateurs.
Vladimir : Maud veut ajouter quelque chose.
Maud : En effet, comme indiqué précédemment, il existe plusieurs méthodes pour améliorer l’expérience de l’utilisateur, notamment en améliorant les wallets et en développant le backend. Des modifications au niveau de la blockchain ou du point final pourraient également faciliter les interactions. Il est important de reconnaître que, malgré les défis existants, notre expérience du sharding reste relativement fluide. Notre conception basée sur l’UTXO nous permet de mettre en œuvre une conception du sharding plus conviviale. Même si elle n’est pas parfaite, il est encourageant de savoir que l’amélioration de cet aspect sera un objectif prioritaire à l’avenir.
Vladimir : Le processus de construction et d’optimisation, avec sa dynamique de va-et-vient permanent, est en effet fascinant. Cela m’amène à poser une question à Chang concernant d’autres éléments passionnants de la feuille de route, tels que la prise en charge des transactions sans gas et le développement d’un plus grand nombre de “proof-of-concept”. Ces “proof-of-concept”pour les dApps sont cruciales car elles fournissent des modèles fondamentaux sur lesquels les équipes peuvent s’appuyer, comme en témoigne leur rôle déterminant dans le développement du DEX et de la marketplace NFT.
Cheng, pourriez-vous expliquer brièvement ce que signifie la prise en charge des transactions sans gas ? En outre, pourriez-vous nous donner des informations sur les dApps à venir et nous dire s’il est prévu d’étendre la prise en charge des hardware wallets ? Vous pouvez répondre à la première partie, et je pourrai poursuivre avec les autres questions par la suite.
Cheng : Pour répondre à la première question, les transactions sans gas concernent principalement l’expérience de l’utilisateur. Par exemple, lorsqu’un nouvel utilisateur transfère des tokens d’Ethereum à Alephium, il utilise $ETH pour payer la transaction qui envoie les tokens au bridge. Du côté d’Alephium, ils auront besoin de $ALPH pour interagir avec la blockchain et réclamer leurs tokens au bridge. Cette exigence est gênante pour les utilisateurs qui n’ont pas un accès immédiat aux $ALPH, car ils doivent généralement les acheter au préalable auprès d’échanges centralisés, ce qui peut être problématique.
Les transactions sans gas visent à aider les utilisateurs dans les situations où ils ont des tokens mais ne disposent pas de l’ALPH nécessaire pour payer le gas nécessaire à la transaction. Dans l’écosystème Ethereum, il existe des propositions pour résoudre ce problème, la plupart d’entre elles impliquant l’utilisation de relais off-chain pour couvrir les frais de gas au nom des utilisateurs. Cette approche est conçue pour simplifier le processus pour les nouveaux utilisateurs qui n’ont pas les tokens nécessaires pour payer les frais de gas.
Le défi de cette mise en œuvre est la nécessité d’un composant off-chain, ce qui implique un travail considérable. Nous disposons actuellement d’un relai pour le bridge, et sa gestion implique une quantité importante de code et la nécessité de répondre aux préoccupations en matière de sécurité. Cependant, nous prévoyons d’introduire de nouvelles instructions dans la machine virtuelle lors de notre prochaine mise à jour. Ces instructions permettront à chaque projet de créer un contrat sans gas, permettant aux utilisateurs de voir leurs frais de gas couverts pour des services spécifiques.
Cette approche sera entièrement on-chain, éliminant le besoin de tout composant off-chain, ce qui la rendra entièrement décentralisée et plus sûre. Elle simplifie le processus, car les projets n’ont qu’à écrire un simple contrat intelligent à l’aide de notre cadre. Cela le rend non seulement sûr, mais aussi pratique à mettre en œuvre. Cela pourrait conduire à la création de divers projets et de nouveaux services sur notre plateforme, ce qui est une perspective passionnante.
Vladimir : C’est en effet un développement passionnant. Elle facilitera considérablement l’accès à Alephium pour les utilisateurs et les développeurs, ce qui est une excellente nouvelle. Un autre aspect à prendre en compte est l’expérience du wallet. Cela inclut une meilleure prise en charge de la fonctionnalité multi-signature dans le SDK et une meilleure prise en charge des hardware wallets. Pourriez-vous nous en dire plus sur ces améliorations ?
Cheng : Oui, la prise en charge des hardware wallets a toujours été un objectif pour nous, mais les limitations de la bande passante ont retardé sa mise en œuvre. Après la mise à jour du réseau, nous prévoyons de donner la priorité à ce développement. Le code est ouvert, ce qui permet aux utilisateurs d’envoyer des transactions en mode “blind”. Cela signifie qu’avec l’installation manuelle de l’application Ledger, les utilisateurs peuvent déjà utiliser le matériel Ledger pour envoyer des transactions sur la base du hachage de la transaction. Il s’agit d’une avancée significative, que nous souhaitons développer après la mise à jour du réseau.
L’aspect principal qu’il nous reste à mettre en œuvre est la fonctionnalité de décodage. Cela implique que le hardware wallet reçoive et décode la transaction, calcule le hachage de la transaction à partir des données brutes et affiche les détails de la transaction à l’intention de l’utilisateur. La mise en œuvre de cette fonctionnalité renforcera la sécurité, bien que même notre processus de transaction “blind” actuel représente une amélioration significative de la sécurité.
Nous prévoyons de nous concentrer prochainement sur le développement de cette fonction de décodage. Étant donné les bases solides que nous avons déjà établies, cela ne devrait pas prendre trop de temps. La seule contrainte a été notre temps, mais nous nous sommes engagés à en faire une priorité.
Vladimir : La dernière question sur ce sujet porte sur les “proof of concepts” de dApps. Quels sont ceux qui vous intéressent le plus ?
Cheng : Les protocoles de prêt m’intriguent particulièrement, ainsi que les stablecoins. Mon intérêt personnel réside dans l’exploration de deux concepts. Le premier est celui des protocoles sans Oracle, généralement plus sûrs que ceux basés sur Oracle et moins vulnérables aux attaques de manipulation des prix. De telles attaques ont souvent visé les protocoles sur l’EVM, affectant même les principaux projets DeFi. Actuellement, les protocoles sans Oracle gagnent du terrain dans ce domaine. Sur EVM, l’adaptation à de nouveaux protocoles est plus difficile en raison de la forte intégration des protocoles existants basés sur Oracle dans divers systèmes, ce qui les rend difficiles à remplacer. Notre blockchain étant relativement récente, elle offre une excellente occasion d’expérimenter et d’adopter ces protocoles.
Une autre application que je suis impatient de voir évoluer est le trading basé sur l’intention. De nombreux échanges décentralisés (DEX) fonctionnent actuellement sur le modèle “automated market-making” (AMM), qui fonctionne bien en cas de liquidité importante. Toutefois, dans les cas où la liquidité n’est pas aussi élevée, un modèle de carnet d’ordres pourrait s’avérer plus efficace. C’est pourquoi le modèle de négociation basé sur l’intention (intent-based trading) suscite un intérêt croissant. La version d’Uniswap va dans ce sens, ainsi que d’autres projets explorant des concepts similaires.
Étant donné qu’il s’agit de projets relativement précoces, nous pouvons adopter et adapter ces nouveaux types de protocoles. Notre utilisation du modèle UTXO s’aligne bien avec le style de carnet d’ordres des dApps, offrant un avantage significatif pour la mise en œuvre de protocoles d’échange basés sur l’intention et la facilitation des transactions peer-to-peer. Contrairement au modèle Ethereum, qui n’autorise généralement qu’un seul expéditeur par transaction, notre plateforme peut gérer plusieurs expéditeurs, ce qui ouvre la voie à toute une série de nouveaux cas d’utilisation. Je suis particulièrement enthousiaste à l’idée de voir des expériences et des développements dans ce domaine, car ils promettent d’apporter des fonctionnalités innovantes et diverses à notre plateforme.
C’est la fin de la deuxième partie de la transcription de l’AMA ! La troisième partie sera disponible dans les prochains jours !
Si vous avez des questions supplémentaires, vous êtes invités à rejoindre le canal # 🎨dev-dapp sur Discord, ou le canal Telegram Alephium. N’oubliez pas de suivre @alephium et @Alephiumfr sur Twitter pour rester informé.
