En quoi Web3 est différent de l'architecture classique
Vous savez probablement déjà que Web3 est synonyme d'applications décentralisées. Lorsque vous recrutez des développeurs de blockchain, vous devez comprendre les principales différences entre Web3 et l'architecture classique.
Front-end et le back-end
Comme pour le Web2, dans le Web3, vous avez toujours front-end et des développeurs back-end. Les applications Front-end fournissent essentiellement une passerelle entre les navigateurs et l'interface utilisateur de votre application et la blockchain. Dans le monde Web2, vous auriez des développeurs ReactJS / AngularJS construisant une application qui se connecte via une API REST ou GraphQL à une application back-end.
Dans Web3, le back-end est une application distribuée qui fonctionne avec des contrats intelligents. Les contrats intelligents sont de petits programmes qui sont exécutés sur un réseau distribué de nœuds. Chaque exécution d'un contrat intelligent vous coûte des frais (gaz). Les développeurs de back-end Web3 devront généralement maîtriser Solidity, un langage décentralisé pour construire des contrats intelligents. C'est un langage complexe qui ne peut pas être maîtrisé rapidement, au moins un an d'expérience est nécessaire pour devenir un développeur Web3 efficace.
Pour interagir avec la blockchain, un développeur Web3 devra utiliser des passerelles HTTP (par exemple Infura, Alchemy et Quicknode), mais cette interaction se fera en lecture seule. Si vous voulez écrire des données sur la blockchain, vous devrez connecter un Wallet (comme Metamask) et utiliser une extension de navigateur, qui injectera du javascript dans chaque page que vous montrerez à vos utilisateurs, les authentifiant ainsi sur la blockchain et leur offrant un moyen d'y placer des données.
Embaucher des développeurs Web3
La pile Web3 à maîtriser
La pile Web3 est très différente des applications Web2 classiques, ne vous laissez pas surprendre par des bibliothèques et des langages absolument inconnus !
Tout d'abord, il faut savoir qu'il existe plusieurs technologies de blockchain, réparties entre celles qui fonctionnent sur les machines virtuelles Ethereum (EVM) et les autres (non EVM).
Exemples de blockchain EVM
- Ethereum - Plate-forme originale de contrats intelligents EVM
- Polygon - Ethereum sidechain
- Arbitrum - blockchain de couche 2 utilisant des rollups optimistes et des preuves de fraude à plusieurs tours
- Optimisme - blockchain de couche 2 utilisant des rollups optimistes et des preuves de fraude à un seul tour
- Hermez - ZK rollup Ethereum Layer 2 network géré par Polygon
- ZKSync - ZK rollup Ethereum Layer 2 network using SNARKs (réseau Ethereum de niveau 2 utilisant des SNARKs)
- Starknet - ZK rollup Ethereum Layer 2 network using STARKs (réseau Ethereum de niveau 2 utilisant des STARKs)
- Avalanche - Couche 1 compatible EVM
- Cronos - Couche 1 compatible EVM
Pour construire sur la blockchain EVM, votre développeur web3 back-end devra maîtriser l'un des environnements de développement suivants :
- Casque
- Truffle (en fait 3 outils de développement : Truffle pour le développement et les tests, Ganache pour créer des blockchains locales, et Drizzle pour front-end).
- Brownie pour ceux qui préfèrent python
Exemples de blockchain non EVM
- Flow - Couche 1 utilisant Cadence, le langage de programmation orienté ressources natif de Flow
- NEAR - Couche 1 utilisant Rust ou Assemblyscript pour les contrats intelligents
- Solana - Couche 1 utilisant Rust C, C++ pour les contrats intelligents
- Terra - Couche 1 : utilisation de Rust pour les contrats intelligents
Autres technologies qui pourraient être obligatoires pour un candidat Web3
- Back-end Web3, construction de contrats intelligents : Solidity
- Expérimentez rapidement Solidity : Scafold ETH
- React Webhooks sur la blockchain : Wagmi
- Passerelles HTTP : Infura, Alchemy, Quicknode
- Connexion au portefeuille : Wagmi ou Rainbowkit
- Connecter Ethereum : Ethers.js, Web3.js
- Stockage décentralisé : IPFS ou Swarm
Web3 CI/CD et tests
Contrairement aux applications web standard, qui peuvent facilement simuler le flux de travail d'un utilisateur pour des tests à grande échelle, les applications web3 souffrent d'un certain nombre de difficultés. L'un des principaux est qu'elles fonctionnent dans un environnement en constante évolution, où chaque transaction doit passer par plusieurs niveaux d'approbation avant d'être finalisée. Un autre problème est que les applications web3 exigent que l'utilisateur télécharge une application client distincte, ce qui nécessite souvent l'intervention d'un tiers pour vérifier les transactions.
Dans l'écosystème de la blockchain Ethereum, vous pouvez tester les contrats intelligents avec Foundry, Dapptools ou Hardhat, qui fournissent généralement une machine virtuelle Ethereum (EVM) pour vous permettre d'interagir avec les contrats intelligents localement. De la même manière, Jest et Mocha sont couramment utilisés pour tester les applications web.
Pour tester les applications Web3, votre développeur devra adopter trois stratégies potentielles :
- Imiter l'utilisateur
- Imiter la pile
- Imiter le flux de travail
Imiter l'utilisateur
Nous pouvons utiliser un fournisseur de brûleur dans le monde Ethereum. Introduit à l'origine par Austin Griffith, un fournisseur de brûleur est un portefeuille Ethereum alimenté par une clé privée stockée dans le stockage du navigateur. En ayant le fournisseur stocké localement, on peut rapidement signer des transactions en tant qu'utilisateur "réel", ce qui, même si ce n'est pas du tout idéal pour les actifs numériques réels, est parfait pour le développement local et, oui, les tests de bout en bout.
Imiter la pile
Selon la blockchain en question, la tâche peut être ardue. Comme nous l'avons déjà mentionné, Ethereum dispose de nombreux outils pour y parvenir, grâce à la communauté dynamique qui entoure le projet. Pour notre exemple, nous utiliserons Hardhat, qui est capable de faire tourner un nœud compatible EVM, exposant une série d'appels RPC** qui peuvent nous aider à falsifier même un utilisateur existant. De plus, nous allons créer un sous-graphe TheGraph, utilisé par notre application de démonstration pour exposer un serveur GraphQL que nous pourrons interroger.
Imiter le flux de travail
La dernière étape consiste alors à imiter le flux de travail de votre application. Vous pouvez le faire en interagissant avec votre contrat intelligent par le biais de votre interface utilisateur (UI). Toute erreur dans votre interface utilisateur doit être détectée par vos tests d'intégration. Si vous ne tenez pas compte de votre propre interface utilisateur, vous rendez l'ensemble du test inutile, car c'est la connexion entre votre contrat intelligent et votre interface utilisateur que nous essayons de tester.
Il existe quelques programmes de test de bout en bout, comme Cypress, mais j'ai beaucoup apprécié Playwright. Pour imiter le flux de travail de votre utilisateur, un test Playwright ressemblerait à ceci (le code complet est disponible ici).
Questions d'entretien avec Web3
Quelles sont les normes communes en matière de contrats intelligents ?
- ERC-20 : Norme de jeton
- ERC-165 : Une norme pour publier et détecter les interfaces mises en œuvre par un contrat intelligent.
- ERC-721 : norme relative aux jetons non fongibles
- ERC-1155 : Norme multi-token
Combien de gaz coûte une simple transaction en Ethereum ?
- Un simple transfert de valeur nécessite 21'000 de gaz.
Qu'est-ce qu'un ABI ?
- ABI est un acronyme pour Application Binary Interface (interface binaire d'application).
- L'ABI est l'interface qui permet d'interagir avec notre contrat intelligent.
- L'ABI peut être générée à partir du code source de votre contrat intelligent (vous devez le compiler).
Pourquoi est-il difficile de générer des nombres aléatoires dans un contrat intelligent ?
- Les contrats Solidity sont déterministes. Quiconque découvre comment votre contrat produit de l'aléatoire peut anticiper ses résultats et utiliser cette information pour exploiter votre application
Dans quels cas une fonction de repli (définie comme payable) est-elle appelée dans Solidity ?
- Un contrat ne reçoit que de l'éther et aucune donnée (msg.data)
- Aucun nom de fonction ne correspond à la fonction appelée
Quelle est la différence entre l'ERC et l'EIP ?
- L'appel à commentaires Ethereum (ERC) définit des normes pour l'utilisation d'Ethereum.
- Les propositions d'amélioration d'Ethereum (EIP) améliorent le protocole Ethereum lui-même.
La mémoire d'un EVM est divisée en trois types :
Stockage :
- Les valeurs de stockage sont stockées de manière permanente sur le réseau Blockchain.
- Il est extrêmement coûteux
Mémoire :
- La mémoire est un stockage temporaire modifiable
- Il n'est accessible que pendant l'exécution du contrat. Une fois l'exécution terminée, ses données sont perdues
Pile :
- Une pile est un espace de stockage temporaire et non modifiable.
- Ici, lorsque l'exécution se termine, le contenu est perdu.
Dans quelles circonstances utiliserez-vous le nouvel opcode CREATE2 pour déployer un contrat ?
- Lorsque vous avez besoin de connaître l'adresse que le futur contrat avec un certain bytecode utilisera avant de le déployer.
Si vous souhaitez utiliser delegateCall pour appeler une fonction d'interface, comment calculer la signature de la fonction ?
- Il s'agit des 4 premiers octets du hachage keccak256 de sa signature canonique, ou theInstance.theFunction.selector.
Comment envoyer de l'Ether à un contrat qui n'accepte pas l'Ether (c'est-à-dire qu'il n'y a pas de fonction de repli ou que la fonction de repli revient toujours en arrière) ?
- Utilisez l'autodestruction, car elle n'exécute pas la fonction de secours.
Où trouver les meilleurs développeurs Web3 ?
Les pays d'Europe de l'Est (Géorgie, Ukraine, Pologne, Arménie, ...) disposent du plus grand nombre de développeurs expérimentés front-end et back-end. La plupart des développeurs demanderont à travailler à distance et c'est une bonne chose lorsque vous construisez une application décentralisée !
code.store a développé une expertise unique dans la recherche, l'embauche et la rémunération des développeurs Web3 à distance. Nos tests d'évaluation uniques comprennent plus de 50 questions. Nous procédons à une analyse approfondie des expériences précédentes de chaque candidat, de leur contribution individuelle à ces projets, ainsi qu'à une vérification des références.
