Création d’une application Web Crypto ML

Aperçu du projet

Le projet combine les données de la blockchain, l’apprentissage automatique et les services gérés dans le cloud en un produit final en tant qu’application Web. Les données Ethereum sont disponibles en tant que jeu de données public GCP.

L’application Web prédit le profil d’investisseur (cluster) d’une adresse Ethereum qui est entrée dans l’interface utilisateur. Ceci est basé sur trois fonctionnalités extraites de la source de données: Solde actuel, transferts uniques et jetons uniques détenus.

Dans le jargon financier, un profil d’investisseur définit la préférence d’un individu dans les décisions d’investissement. Par exemple, l’aversion au risque / la tolérance au risque, la diversité des classes d’actifs et des actifs individuels, l’investissement dans des actions de croissance ou des actions de valeur, etc. Dans ce projet, il se réfère à tout type de comportement d’investissement qui peut être quantifié et utilisé pour différencier entre différentes adresses Ethereum.

Les données sont disponible sur BigQuery et est prêt à être utilisé. Le défi consiste à modéliser les données et à les utiliser pour alimenter les modèles ML. Les données ne sont pas étiquetées, c’est pourquoi le problème est formulé tâche d’apprentissage automatique non supervisée. Comme les données de tarification sont à la fois plus accessibles et monétisables, la plupart des projets de machine learning crypto se concentrent sur la prévision de cela.

D’autre part, ce projet se concentre sur les empreintes comportementales des adresses individuelles (investisseurs) et leur regroupement en fonction des données transactionnelles disponibles.

Les services cloud d’AWS ont été utilisés pour fournir le modèle dans l’interface utilisateur Web. AWS SageMaker pour toutes les étapes d’apprentissage automatique et pour servir de modèle comme point de terminaison de prédiction. Ceci est ensuite déclenché en tant que fonction Lambda via le point de terminaison API déployé avec API Gateway. Ce point de terminaison est utilisé pour prédire le profil d’investisseur Ethereum dans l’interface utilisateur Web.

Énoncé du problème

Bien que les données sur les chaînes de blocs publiques soient ouvertes, il n’y a pas encore beaucoup d’applications d’apprentissage automatique (à part les prévisions de prix) qui les exploitent. L’une des raisons est que les structures de données sous-jacentes sont basées sur des systèmes OLTP difficiles à analyser (par opposition à OLAP).

Pour chaque transaction exécutée sur les blockchains publiques, il existe une trace que nous pouvons analyser. Contrairement aux autres classes d’actifs, nous disposons de données sur le comportement des investisseurs individuels. Le but du projet est de répondre à la question:

Pouvons-nous utiliser le principe du BYOD (apporter vos propres données) et regrouper un investisseur Ethereum uniquement avec l’adresse fournie?

Compte tenu de la complexité du problème, je ne m’attendais pas à obtenir des résultats qui seraient nécessairement éclairants. Il existe actuellement presque 100 millions d’adresses Ethereum uniques qui sont très diverses. L’objectif était de construire une solution viable. Et pour cela, certaines hypothèses devaient être faites.

Une hypothèse fondamentale (sur) simplificatrice est qu’une adresse équivaut à un investisseur. Ceci est difficile à discuter car il existe de nombreux sous-groupes dans l’écosystème Ethereum tels que les mineurs, les bourses et les portefeuilles ICO. Pendant ce temps, la distinction entre ceux-ci dépasse la portée de ce projet qui se concentre sur la construction d’un pipeline de preuve de concept.

Métrique

Avec un nombre donné de clusters, chaque modèle regroupe toutes les adresses Ethereum échantillonnées en clusters séparés. La métrique utilisée dans ce projet est la Score de silhouette. Le coefficient est calculé en utilisant la distance moyenne intra-grappe et la distance moyenne la plus proche pour chaque échantillon. Ceci est idéal pour le cas d’utilisation car nous n’avons pas de valeurs de vérité au sol disponibles.

Exploration des données

Un échantillon de 10000 adresses Ethereum est extrait. Certains d’entre eux ne remplissant pas les conditions supplémentaires de la requête spécifiée, environ 8 000 sont disponibles dans le bloc de données. Comme le montre le tableau ci-dessous, le seuil minimal de ether_balance est 1 Ether. Il s’agissait d’une limite arbitrairement définie car de nombreuses adresses Ethereum ont un solde nul.

La moyenne est de 138 Ether (actuellement environ 25 000 euros au 15 mai 2020), ce qui indique l’asymétrie de la distribution lorsque nous regardons le 75e centile. Alors que le 75e centile est inférieur à 13 Ether, la moyenne est de 138. Il y a clairement de fortes valeurs aberrantes dans l’échantillon, comme la valeur la plus élevée avec un équilibre de 300000 Ether.

le jetons_uniques caractéristique n’est pas aussi dispersée à la balance Ether. La valeur habituelle varie de 2 jetons uniques à 8 jetons détenus.

Les transferts_uniques la fonction varie considérablement. Alors que le nombre moyen de transferts est de 26, le plus grand nombre est 28560. Nous pouvons voir que les 25% des adresses les plus importantes génèrent la plupart des transferts car aucune des adresses du 75e centile n’a plus d’un transfert.

Visualisation exploratoire

Vous trouverez ci-dessous une matrice de dispersion ci-dessous pour toutes les entités construites. Comme il est clair dans la visualisation, il existe une distribution de loi de puissance dans les deux eth_balance et unique_transfers traits. La grande majorité de la valeur cumulée des deux est générée par une minorité d’adresses.

Pendant ce temps, il n’y a pas beaucoup de corrélation visible entre les différentes fonctionnalités.

Il existe une carte thermique de corrélation ci-dessous pour toutes les fonctionnalités disponibles. Comme cela a déjà été indiqué ci-dessus, il existe peu de corrélation entre les différentes caractéristiques. C’est un signe positif car nous voulons explorer différentes zones de l’espace des fonctionnalités avec différentes fonctionnalités. S’il y avait une forte corrélation, nous pourrions expliquer les mêmes phénomènes avec des caractéristiques différentes.

Algorithmes et techniques

Les techniques utilisées pour prédire les clusters sont tous des algorithmes d’apprentissage automatique non supervisés. Les choix sont K-means, Gaussian Mixture Models et Hierarchical clustering.

Comme dans K-means, les frontières entre les clusters sont toujours linéaires, les deux autres algorithmes sont utilisés pour gérer des frontières plus compliquées. En outre, la possibilité d’étendre davantage l’analyse en mesurant la probabilité ou l’incertitude des affectations de grappes. Cela ne se fait pas dans l’analyse mais c’est une extension possible.

Référence

Le modèle de référence pour le projet est le score de silhouette de l’algorithme K-means. Après cela, des algorithmes plus sophistiqués sont utilisés pour comparer les performances. En règle générale, un score Silhouette de 0,5 est défini comme un seuil pour la solution à considérer avec une performance raisonnable.

Prétraitement des données

Trois fonctionnalités sont extraites:

• Balance Ethereum actuelle
• Jetons uniques qui ont toujours été détenus
• Transferts uniques par l’adresse Ethereum

la mise en oeuvre

Il y a pas mal de modules Python utilisés dans le projet. En attendant, ce sont certains qui sont au cœur de la mise en œuvre. Pandas_gbq La bibliothèque a été utilisée pour interroger la source de données BigQuery Ethereum. Google-cloud-bigquery a été utilisé pour s’authentifier dans le compte de service GCP. Scikit-learn a été utilisé comme un outil pour tous les modèles.

Services AWS utilisés dans le projet:

• S3 pour stocker les données de formation, le prétraitement avec l’objet transformateur et les informations d’identification GCP
• SageMaker pour tirer parti des instances de bloc-notes et connecter le projet de bout en bout
• Fonction Lambda pour déclencher le script de prédiction
• Passerelle API pour créer une API utilisée dans l’interface utilisateur Web avec laquelle l’utilisateur interagit
• CloudWatch pour consigner et déboguer les éventuels problèmes rencontrés lors du processus de création de la solution

Deux tableaux de la source de données publique Ethereum sont utilisés:

• `bigquery-public-data.crypto_ethereum.balances`
• `bigquery-public-data.ethereum_blockchain.token_transfers`

Vues Bigquery impressionnantes La page Github a été utilisée pour construire les requêtes SQL et obtenir une meilleure compréhension du modèle de données Ethereum.

Ci-dessous, nous pouvons voir quelques exemples des fonctionnalités construites pour différentes adresses Ethereum.

Après cela, la fonctionnalité de pipeline de Sklearn est utilisée pour prétraiter les fonctionnalités. Nous les normalisons pour nous assurer que les fonctionnalités sont utiles pour alimenter les modèles. Cela se fait en utilisant la transformation de puissance, la mise à l’échelle standard et la transformation PCA. La transformation PCA peut être redondante ici car il n’y a que trois fonctionnalités mappées sur trois composants, mais peut être utile si l’ensemble de fonctionnalités est développé et que la dimensionnalité doit être réduite compte tenu de la taille de l’échantillon.

Avec l’ensemble final de fonctionnalités, les trois alternatives d’algorithmes de clustering sont entraînées: modèle K-means, modèle GMM et modèle de clustering hiérarchique.

La visualisation ci-dessous trace le nombre d’instances dans chacun des 4 clusters.

Le nombre de clusters choisi est 4. Il est choisi en fonction des essais et erreurs de différentes valeurs. Comme les performances des algorithmes alternatifs n’améliorent pas considérablement le coefficient de Silhouette, K-means est utilisé dans la solution utilisée dans le modèle qui est déployé.

Après la formation à l’aide du script de formation, les métadonnées du modèle formé sont combinées avec le script de prédiction pour prédire la valeur de cluster des adresses Ethereum individuelles.

Le script de prédiction effectue un calcul à la volée des valeurs d’entité de l’adresse Ethereum fournie. Il interroge la source de données Ethereum et renvoie les valeurs de fonctionnalité normalisées. Celles-ci sont ensuite utilisées comme entrée dans le modèle entraîné qui renvoie la valeur de cluster prédite.

La solution finale est un point de terminaison de prédiction déclenché en tant que fonction Lambda via la passerelle API. La fonction Lambda est une fonction cloud basée sur une architecture sans serveur. Il est déployé via la passerelle API en tant qu’API pouvant être utilisée dans l’interface utilisateur de l’application Web.

Chaque fois qu’un utilisateur entre une adresse Ethereum et appuie sur le bouton Soumettre, la valeur de cluster prédite est affichée dans l’interface utilisateur.

Évaluation et validation du modèle

Le résultat final est une application Web qui renvoie un profil d’investisseur basé sur l’adresse Ethereum fournie par l’utilisateur. L’utilisateur n’a pas besoin de fournir ses propres données personnelles, car toutes les données nécessaires peuvent être extraites de la source de données Ethereum accessible au public.

Les modèles sont évalués sur la base du score Silhouette. Comme il existe actuellement plus de 100 millions d’adresses Ethereum existantes, il est difficile d’échantillonner de manière fiable les adresses sans établir de règles explicites telles que le filtrage des montants de solde non triviaux.

Le modèle est évalué empiriquement avec la métrique choisie. Le score Silhouette de K-means est de 0,38. Comme il n’y a pas de valeurs de vérité au sol disponibles, il n’y a aucun moyen de tester cela objectivement de manière évolutive. D’un autre côté, la métrique choisie quantifie bien la façon dont les différents clusters sont différenciés dans l’espace des fonctionnalités.

La solution finale est testée dans une application Web où la valeur de cluster prédite est extraite pour un exemple d’adresse Ethereum.

Compte tenu des performances, il est clair qu’il n’y a pas suffisamment de variance dans les données extraites pour pouvoir créer des clusters interprétables. Lors de l’examen de différents clusters, il n’a pas été possible non plus de trouver un nom significatif pour les clusters.

Justification

Les 0,5 seuils pour le coefficient Silhouette ne sont pas atteints, ce qui signifie que, compte tenu de cette métrique, nous ne pouvons pas décrire les modèles pour avoir une bonne compréhension des données sous-jacentes. Pendant ce temps, l’objectif principal du projet était de construire une solution minimale viable qui puisse ensuite être améliorée.

Les plus gros goulots d’étranglement des performances sont les fonctionnalités qui sont intégrées dans les modèles. Avec une meilleure compréhension du modèle de données sous-jacent, nous pourrions construire un meilleur ensemble de fonctionnalités.

En outre, le prétraitement pourrait être amélioré. En outre, le nombre de clusters a été choisi avec essais et erreurs avec les mêmes valeurs dans tous les algorithmes. Cela pourrait être accéléré en utilisant une analyse plus sophistiquée (analyse Silhouette).

Ce projet montre comment il est possible de configurer relativement rapidement un pipeline d’apprentissage automatique et de le fournir en tant que produit de données dans l’interface utilisateur Web.

Compte tenu de la maturation des industries de la science des données et de la cryptographie, nous verrons lentement un changement où il deviendra plus courant de rapprocher ces technologies d’une manière qui n’était pas possible auparavant.

Avec les services gérés dans le cloud, une grande partie de la complexité est éliminée, ce qui aide les scientifiques des données qui ne sont souvent pas formés en génie logiciel et DevOps / MLOps. En plus de cela, les API de haut niveau peuvent aider les ingénieurs à créer des produits de données qui n’étaient auparavant disponibles que pour les professionnels des données spécialisés. Avec les progrès de ces domaines, nous pouvons voir beaucoup d’apprentissage les uns des autres qui permettra un nouveau paradigme de produits logiciels.

Quelques autres projets travaillant sur des solutions de données cryptographiques: