La blockchain Ethereum, lancée publiquement en 2015, est actuellement la plateforme la plus plébiscitée par les développeurs pour la création d’application décentralisées, de marketplaces ou bien sûr de nouvelles solutions de paiement en cryptomonnaies💰. Cependant, le succès toujours grandissant d’Ethereum n’est pas sans inconvénients pour les utilisateurs car cette blockchain souffre historiquement de frais de transaction dissuasifs et de congestion pour une utilisation dans des applications à fort trafic. Par exemple pour une billetterie NFT de concerts, le risque de devoir payer plus de 10 dollars pour valider une place de concert est rédhibitoire d’autant plus si la validation d’un millier de personnes doit prendre plusieurs heures 😱… Conscient de ces problèmes Ethereum a modifié en profondeur son fonctionnement à l’occasion d’une mise à jour 2.0 majeure appelée The Merge dont nous étudierons le fonctionnement.
Pour avoir une vision exhaustive, nous avons cherché s’il existait des blockchains alternatives pour développer un smart-contract offrant un coût plus maîtrisé et une meilleure performance, nous avons notamment regardé des blockchains telles que Cardano (https://cardano.org/), Terra (https://www.terra.money/) ou æternity (https://aeternity.com/) mais notre intérêt s’est finalement tourné vers Solana (https://solana.com/fr).
Nous vous proposons ici une petite plongée dans le fonctionnement des smart-contracts 📝 pour les blockchains Ethereum et Solana.
Les problèmes d’Ethereum avant The Merge
Le réseau Ethereum culminait à 20 transactions par seconde (TPS) ⏱ dans les bons jours, et se situait généralement entre 10 et 15 TPS. Il s’agit bien du nombre de transactions pouvant être effectuées par la totalité du réseau, ce qui semble extrêmement faible en comparaison du nombre d’utilisateurs (environ 500 000 actifs) et d’une capitalisation de marché (https://www.investopedia.com/terms/m/marketcapitalization.asp) avoisinant 200 000 000 000 $ (si vous ne voulez pas compter les zéros on parle ici de deux cent milliards de dollars).
Ce faible taux de TPS mettait les utilisateurs en concurrence puisque toute opération effectuée sur la blockchain (une transaction) nécessitait le paiement de frais (communément appelé le GAS pour « carburant »). Afin d’augmenter ses chances de voir ses transactions inclues dans la blockchain, les utilisateurs ont donc tendance à proposer une rémunération toujours plus élevée pour ces frais afin d’inciter les « mineurs » à prendre leurs transactions en priorité. Le coût d’une transaction, généralement en dessous d’un dollar, a pu dépasser 25 dollars en 2021 et certaines transactions plus complexes ont couté parfois plus de 100 dollars. Le prix dépendait de l’offre (la puissance de calcul des mineurs) et de la demande (les utilisateurs souhaitant effectuer des transactions) dans le cadre d’un algorithme de consensus de validation des transactions « Proof of Work » (algorithme sûr mais très énergivore).
Ethereum 2.0
La mise à jour 2.0 de la blockchain Ethereum 🚀 – appelé The Merge – déployée le 15 septembre 2022 introduit un nouvel algorithme de consensus appelé « Proof of Stake », pour « preuve d’enjeu ». Cette méthode repose sur une sélection aléatoire d’un mineur (ou plutôt d’un « minter » dans le cas du PoS) et d’une somme de cryptomonnaie mise en jeu par tous les mineurs.
Dans un système « Proof of Stake », les mineurs doivent mettre une certaine somme en jeu pour pouvoir être tirés au sort et pour pouvoir valider les blocs forgés. Les mineurs forgeant ou validant un bloc qui n’est finalement pas choisi par le reste du réseau sont pénalisées, une partie de leur mise est détruite, tandis que les participants au bloc ayant fait consensus sont récompensés 🤑. On peut retenir qu’il n’est plus nécessaire de calculer des millions de hashes pour en trouver un répondant à un certain critère, un bloc est calculé une seule fois, rendant ainsi beaucoup plus rapide l’ajout de ce bloc à la chaîne. Autre élément positif, la réduction d’électricité consommée est estimée à 99,95 % #GreenBlockchain !
Les développeurs estiment pouvoir atteindre les 100 000 TPS (au lieu de 20 !) avec ce système. Cela ne résout pas le problème du choix des transactions inclues dans les blocs choisies par les mineurs en fonction de ce que cela leur rapporte mais un TPS 5 000 fois supérieur laisse certainement la place aux transactions les moins onéreuses. Ainsi, les coûts d’utilisation de la blockchain Ethereum devraient diminuer fortement même s’il faut attendre la fin de la période de mise à jour et une période de stabilisation pour voir si ces modifications tiennent leur promesses.
Solana
Dès sa conception, la blockchain Solana a tenu compte des problématiques de performance, de concurrence et d’énergie grâce à l’utilisation du modèle de consensus « Proof of History » 🎯.
Le « Proof of History », repose sur une « Verifiable Delay Function », c’est à dire un algorithme permettant de vérifier qu’un mineur a bien reçu et publié les transactions aux dates et heures prétendues. Plusieurs mineurs peuvent ainsi générer plusieurs blocs en parallèle tout en conservant un ordre déterminé par l’algorithme. Les développeurs parlent de 12 0000 TPS mais la blockchain étant jeune (et encore en version beta), on compte environ 2 000 TPS pour le moment. La réactivité des mineurs et le modèle de développement permet un prix de transaction d’environ 0,00025 dollars 🤗 ! De plus, ce modèle permet également à un seul mineur de valider et voter sur plusieurs blocks en même temps, en profitant des architectures multi-cœurs de nos machines en calculant plusieurs hashes en parallèle, puisque plusieurs blocs peuvent être gérés en parallèle. À noter, la « Proof of Work » bénéficie également des processeurs multi-cœurs en calculant autant de hashes en même temps qu’une machine compte de cœurs CPU, mais plus de 99% de ces hashes sont simplement jetés. Dans le cas de Solana, chaque calcul est utile.
Toutefois, Solana qui est encore en version beta, a malheureusement connu trois coupures majeures qui ont fait tomber le réseau. L’intégrité des données n’a pas été altérée mais l’impossibilité de réaliser une transaction pendant plusieurs heures a de quoi inquiéter, bien que cela n’ait pas semblé entacher l’enthousiasme grandissant du public. Il convient aussi de considérer la décentralisation insuffisante de Solana. En effet, les équipes de Solana (et l’entreprise qui en est à l’origine) détiennent la majorité des nœuds de vérification et surtout des capitaux transformés en monnaie native (le SOL). Si cela est pratique en version beta pour réagir rapidement aux différents problèmes inhérents à un projet de cette envergure, cela empêche Solana pour le moment de devenir l' »Ethereum Killer » comme on peut parfois le lire.
Smart Contract sur Ethereum
Les smart-contracts de la blockchain Ethereum sont écrits dans le langage Solidity, un langage orienté objet. Chaque smart-contract définit des données à stocker, et le code permettant de créer et mettre à jour ces données 💾. En programmation, la notion la plus proche est simplement une « classe ». Écrire un smart-contract sur Solidity est relativement facile car ce langage a été créé spécifiquement pour sa blockchain.
Imaginons une cryptomonnaie fictive, l’AGIL. Cette cryptomonnaie peut exister grâce à un smart-contract qui tient une liste de compte utilisateurs indiquant pour une personne donnée, ou plutôt pour son adresse sur la blockchain, combien d’AGIL sont associés à cette adresse. Le smart-contract définit également des fonctions (techniquement, des « méthodes »), par exemple `name()` qui renvoie simplement ` »Agilap Coin »`, `symbol()` qui renvoie ` »AGIL »`, `balanceOf(address owner)` qui indique combien d’AGIL sont détenus par une adresse donnée, et bien sûr `transfer(address to, unit256 value)` qui permet d’envoyer un certain montant d’AGIL à l’adresse `to` de la part de la personne émettant la transaction (celle qui appelle cette fonction).
Un certain nombre de standards ont été mis en place pour que toutes les cryptomonnaies créées puissent être facilement gérées et surtout adoptées par le public. Par exemple, le standard ERC-20 définit le fonctionnement d’une cryptomonnaie et requiert l’existence, entre autres, des méthodes listées ci-dessus. En programmation, c’est simplement une interface. Le standard ERC-721 définit le comportement d’un NFT. L’adhésion à ces standards facilite l’adoption des smart-contracts par le réseau. La majorité des « exchanges » permettant d’acheter et vendre plusieurs cryptomonnaies, ne listent que celles au standard ERC-20 car elles dépendent de la présence des fonctions définies dans ce standard (du moins pour les tokens Ethereum).
Ce modèle orienté objet ne permet pas l’utilisation du smart-contract pour gérer plusieurs blocs en parallèle. En effet, lorsqu’il est appelé dans une transaction, le contrat a besoin de lire, de modifier puis de sauvegarder ses données avant de pouvoir traiter une autre transaction. De plus, chaque smart-contract doit être publié indépendamment afin de pouvoir personnaliser le code. Si notre fonction renvoie ` »AGIL »`, d’autres cryptomonnaies voudront utiliser un symbole différent, comme ` »USDT »`, ` »HEX »`, ` »SHIB »`, etc. On constate donc une large duplication du code puisqu’au-delà de ces différences mineures, la grande majorité de ces tokens suivent le même fonctionnement. Des librairies comme OpenZeppelin (https://www.openzeppelin.com/) permettent d’utiliser du code de qualité en ne définissant finalement que ce qui diffère des autres cryptomonnaies, mais l’intégralité du code doit tout de même être déployée sur la blockchain. En contrepartie, si cela semble regrettable dans le cas d’un token standard, il est très simple de créer et de publier un smart-contract personnalisé.
Smart Contract sur Solana
Les smart-contracts Solana nous ont particulièrement séduits, ils diffèrent sur deux aspects majeurs.
D’une part, ils sont écrits dans le langage Rust (https://www.rust-lang.org/fr), ce qui en principe suppose une qualité de code supérieure à la sortie, mais demande également un niveau de compétence supérieur en entrée. C et C++ sont également disponibles.
D’autre part, et c’est là que Solana est très satisfaisante, les smart-contracts (appelés « on-chain programs ») contiennent uniquement du code🕹, et aucune donnée. Celles-ci sont stockées ailleurs, sur d’autres adresses dérivées qui appartiennent aux différents utilisateurs mais dédiées à un programme donné. Notre symbole, ` »AGIL »` serait lui aussi stocké sur une adresse de données appartenant à Agilap. Ainsi, si deux personnes souhaitent échanger des tokens, le code du programme est simplement lu, et seules les données à leurs adresses respectives sont modifiées. Deux autres personnes peuvent effectuer une transaction en parallèle, le code du programme est également lu, mais seules les données appartenant à ces nouvelles personnes sont modifiées. Les deux transactions peuvent donc avoir lieu en même temps car elles touchent deux espaces de données différents. Cela signifie également qu’une seule copie d’un programme pourrait être utilisée par plusieurs cryptomonnaies différentes. Plusieurs programmes open-source sont publiés et maintenus par les développeurs de Solana et la communauté. Notamment le « Token Program », permettant de créer des cryptomonnaies et des NFT (ERC-20 et ERC-721 réunis en quelques sortes).
Il est aussi possible de créer un token depuis la ligne de commande, en utilisant un client écrit spécifiquement pour le Token Program, sans écrire une seule ligne de Rust ou même de JavaScript (utilisé pour les déploiements). En comparaison d’Ethereum, la création de tokens est grandement facilitées et les risques financiers liés à des erreurs logiques ou des bugs sont négligeables.
Notre avis
Ethereum permet de créer rapidement un smart-contract mais comporte à date un risque structurel important pour lancer un nouveau service. La mise à jour – The Merge – de Ethereum 2.0 connaît un démarrage en dessous des espoirs qu’elle suscitait, le prix du GAS n’a pas encore réduit et le gain de temps pour la validation des blocs est faible 🤨. Toutefois, il s’agit certainement de problèmes liés à l’ampleur du changement qui devraient être corrigés rapidement, aussi The Merge devrait permettre à terme de résoudre les deux problèmes majeurs d’Ethereum, la fluctuation du coût des transactions et des performances de la blockchain.
Solana de son côté nous a agréablement surpris et nous semble à date adapté pour développer une application web s’appuyant sur un smart-contract – applications de « ticketing » (par exemple, billetterie de concerts) ou de « tokenization » (NFT pour une mise sur le marché crypto de biens réels) – tant au niveau du coût des transactions que des performances de la blockchain 🤸🏼♂️.
Ainsi, Ethereum et Solana sont deux blockchains qui permettent de créer des applications web s’appuyant sur des smart-contracts. Si notre préférence penche aujourd’hui vers Solana, nous attendons avec impatience de voir si la mise à jour d’Ethereum 2.0 va être à la hauteur des espérances 😍 qu’elle a créée pour résoudre les problèmes qui ont fait fuir une partie des développeurs, car si tel est le cas Ethereum risque de s’imposer définitivement comme la blockchain de référence pour les smart-contracts !
A disposition pour en parler, bons projets et à bientôt, l’équipe d’Agilap 🌈
