Frontends alternatifs : Pourquoi et comment ? - Censorship.wtf

Quelles sont ces ressources IPFS ?

Les frontends (interfaces web) décentralisées peuvent être déployées en utilisant IPFS, avec une résolution ENS pour mapper les domaines aux ressources IPFS appropriées. Cependant, la question est : quelles sont ces ressources IPFS ?

Pour ce qui est des frontends, on prend un grand code source, on le génère pour produire des artefacts, et on stocke ces artefacts sur IPFS de manière décentralisée. Cependant, en y regardant de plus près, ces artefacts contiennent toujours des liens vers des services centralisés comme des API s'exécutant sur AWS (Amazon Web Services).

Par ailleurs, bien que les artefacts des frontends soient eux-mêmes décentralisés sur IPFS, ils dépendent toujours de services centralisés traditionnels, contrecarrant ainsi une partie de l'objectif d'une véritable interface web décentralisée.

Certaines couches ne sont pas décentralisées

Les smart contracts peuvent être décentralisés on-chain, mais les frontends dépendent souvent encore d'API centralisées par défaut.

Le code client gère les appels RPC, donc la décentralisation des nœuds et des connexions importe aussi.

Les frontends "alternatifs" fournissent une sauvegarde si le frontend officiel du projet est forcé de fermer, si l'équipe de développement jette l'éponge, ou si le marché haussier se transforme en marché baissier.

Certains projets DeFi ont disparu mais la liquidité est toujours sur la blockchain - sans frontend, il est difficile pour les utilisateurs de les retirer.

Les frontends alternatives permettent aux utilisateurs d'accéder en continu même si l'interface avant du projet d'origine est abandonnée.

Pour ces raisons, les frontends alternatifs sont importants pour la résilience et la protection des utilisateurs.

Comment pouvons-nous faire confiance aux frontends alternatifs ?

La principale question est : comment pouvons-nous faire confiance à ces interfaces alternatives, même au-delà des artefacts & des APIs ?

Sachant que nous n'avons probablement pas besoin d'un redéploiement des repos des frontends d'origine.

Le problème, c'est la confiance

Comment pouvons-nous faire confiance aux interfaces ?

Il s'agit d'une architecture simplifiée avec des artefacts de construction se connectant via des SDK et RPC/API à la blockchain. Voici les tiers de confiance :

• URL/ENS
• API
• RPC
• L'implémentation elle-même du frontend

Cela nous donne 4 intermédiaires techniques auxquels nous devons faire confiance.

A quoi ressemble un vrai frontend

La page "ajouter de la liquidité" d'Uniswap contient plus de 500 lignes de Javascript, sans compter le nombre de bibliothèques différentes, de composants SDK, de hooks, etc. Si on les inclut tous, on a des milliers de lignes de code juste pour construire une interaction.

Beaucoup de code signifie que la sémantique des transactions est divisée, ce qui rend difficile la vérification de ce que nous calculons pour construire et soumettre la transaction.

Cette base de code évolue en permanence, et chaque mise à jour nécessite un audit pour s'assurer de la sécurité.

Avec des milliers de projets, valider la sécurité de chaque interface est extrêmement difficile.

La solution d'OKcontract

L'idée est de construire un moteur de frontend commun au lieu d'implémentations séparées pour chaque projet.

Le moteur gère des choses comme la récupération de données depuis des nœuds, les interactions utilisateur, la construction de transactions de manière générique plutôt que d'avoir des implémentations personnalisées pour chaque projet.

Cela permet la réutilisation, des outils/audits partagés entre les projets, et peut avoir de multiples implémentations alternatives, mais les spécifications transmises à celles-ci sont communes.

Minimalisme

Spécification de la sémantique d'interaction

Les spécifications de transaction sont écrites en "lambdascript", un langage de programmation purement fonctionnel pour spécifier une transaction (il faut penser à une intention de bas niveau ou une transaction de haut niveau).

Le lambdascript est une alternative à la propagation de la sémantique des transactions dans diverses parties du code complexe du frontend, et inclut des détails de haut niveau comme le contrat cible, les paramètres, les calculs pour les montants. De plus, le compilateur peut détecter les erreurs et les utilisateurs/auditeurs peuvent facilement vérifier le comportement on-chain.

Sur les mécanismes de vérification et de confiance :

• Il y a beaucoup moins de code à auditer par rapport à l'ensemble du code de base du frontend
• Le moteur générique peut être audité à fond une seule fois pour tous les projets plutôt que de le refaire par projet.
• Les membres de la communauté peuvent vérifier et signer numériquement des spécifications valides qui correspondent aux interactions prévues.

Sur les signatures on-chain :

• Cela permet de s'appuyer sur un enregistrement décentralisé plutôt que de faire confiance à n'importe quel fournisseur d'interface centralisé.
• Les signatures sont liées à un hachage spécifique, à partir d'une référence transparente et immuable.

Génération automatisée de frontend pour toute transaction

L'interface utilisateur est importante pour les utilisateurs finaux même avec une définition de transaction adéquate et un runtime vérifié au niveau du SDK, la façon dont ils sont assemblés peut avoir un impact sur la sécurité. Plutôt que des interfaces personnalisées, une génération standardisée à partir de spécifications de transaction garantit moins de problèmes de sécurité que des artefacts de construction entièrement personnalisés.

L'histoire récente montre que les attaques de frontend peuvent être très dommageables, comme BadgerDAO pour 120 millions de dollars :

1. Les attaquants ont réussi à injecter du code dans l'interface avant pour faire des approbations, en fait des jetons utilisateur à leurs propres adresses.
2. En fait, les gens ont commencé à approuver des jetons et ils n'ont rien fait, ils ont juste gardé les approbations et ont juste surveillé l'approbation en cours.
3. Ensuite, les attaquants ont récolté toutes les approbations qu'ils avaient.

D'autres attaques via des dépendances comme Google Tag Manager dans KyberSwap existent également.

Spécification de la sémantique + génération automatisée = notre programme

Le système proposé est un frontend compilé à partir de sémantiques concises et d'un runtime commun. Il réduit la complexité et le code pour plus de confiance, même s'il y a moins de personnalisation de l'interface utilisateur.

Les screens ci-dessus montrent des interfaces générées pour des interactions réelles.

Regardons en arrière

La confiance et le minimalisme sont la voie à suivre pour construire des frontends alternatifs.

Architecture alternative de frontend

L'image ci-dessus est l'architecture proposée qui a une frontend unique généré à partir de la définition de la sémantique des transactions.

Déployer des constructions statiques

Nous pouvons déployer ces constructions statiques qui peuvent fournir des interfaces alternatives par défaut utilisant l'interface générée et le runtime universel et ainsi décentraliser les nœuds API.

Nous pouvons créer un référentiel d'interactions et de frontends alternatifs pour des projets DeFi/NFT, et la communauté peut vérifier que les définitions et les runtimes sont corrects.

Comment contribuer ?

Prochaines étapes : contribuer à une EIP pour standardiser la spécification des transactions.

Les projets peuvent contacter OKContract pour rejoindre la version bêta privée, et l'orateur peut être contacté via Twitter ou le nouveau groupe Telegram pour contribuer ou s'impliquer.

L'objectif final est de s'assurer que les projets puissent avoir des frontends alternatifs