Прогнозирование профиля инвестора Ethereum с помощью AWS SageMaker

TL;DR

Этот проект направлен на объединение набора данных Ethereum, машинного обучения и облачных технологий в одном проекте. Результатом является неконтролируемый продукт данных машинного обучения, доступный через веб-интерфейс. Он прогнозирует профиль инвестора (кластер) на основе функций, созданных на лету с предоставленным адресом Ethereum и общедоступными данными.

Код проекта доступен на Github.

Определение

Обзор проекта

Проект объединяет данные блокчейна, машинное обучение и облачные управляемые сервисы в конечный продукт в виде веб-приложения. Данные Ethereum доступны в виде общедоступного набора данных GCP.

Веб-приложение предсказывает профиль инвестора (кластер) адреса Ethereum, который вводится в пользовательском интерфейсе. Это основано на трех характеристиках, извлеченных из источника данных: Текущий баланс, уникальные переводы и уникальные токены.

На финансовом жаргоне профиль инвестора определяет предпочтения человека при принятии инвестиционных решений. Примерами этого являются неприязнь к риску / толерантность к риску, разнообразие классов активов и отдельных активов, инвестиции в акции роста или ценные бумаги и т. Д. В этом проекте это относится к любому типу инвестиционного поведения, которое можно количественно оценить и использовать для дифференциации между разными адресами Ethereum.

Данные доступны в BigQuery и готовы к использованию. Задача состоит в моделировании данных и использовании их в моделях машинного обучения. Данные не помечены, поэтому проблема сформулирована как задача машинного обучения без учителя. Поскольку данные о ценах более доступны и монетизируются, большинство проектов крипто-машинного обучения сосредоточены на прогнозировании этого.

С другой стороны, этот проект фокусируется на поведенческих следах отдельных адресов (инвесторов) и их кластеризации на основе доступных данных о транзакциях.

Облачные сервисы AWS использовались для предоставления модели в веб-интерфейсе. AWS SageMaker для всех этапов машинного обучения и использования модели в качестве конечной точки прогнозирования. Затем это запускается как функция Lambda через развернутую конечную точку API с API Gateway. Эта конечная точка используется для прогнозирования профиля инвестора Ethereum в веб-интерфейсе.

Описание проблемы

Хотя данные об общедоступных блокчейнах открыты, пока не так много приложений машинного обучения (кроме прогнозов цен), которые их используют. Одна из причин заключается в том, что базовые структуры данных основаны на системах OLTP, которые трудно анализировать (в отличие от OLAP).

Для каждой транзакции, которая выполняется в общедоступных цепочках блоков, есть трассировка, которую мы можем проанализировать. В отличие от других классов активов, у нас есть доступные данные о поведении индивидуальных инвесторов. Цель проекта - ответить на вопрос:

Можем ли мы использовать принцип BYOD (приносить свои данные) и кластеризовать инвестора Ethereum только с предоставленным адресом?

Учитывая сложность проблемы, я не ожидал, что получу результаты, которые обязательно будут проницательными. В настоящее время существует почти 100 миллионов уникальных адресов Ethereum, которые очень разнообразны. Цель состояла в том, чтобы построить работоспособное решение. А для этого нужно было сделать некоторые предположения.

Одно из основных (чрезмерно) упрощающих предположений состоит в том, что один адрес равен одному инвестору. С этим трудно спорить, поскольку в экосистеме Ethereum есть много подгрупп, таких как майнеры, биржи и кошельки ICO. Между тем, различие между ними выходит за рамки этого проекта, который фокусируется на создании доказательства концепции конвейера.

Метрики

При заданном количестве кластеров каждая модель объединяет все выбранные адреса Ethereum в отдельные кластеры. Метрика, используемая в этом проекте, - Силуэтная оценка. Коэффициент рассчитывается с использованием среднего внутрикластерного расстояния и среднего расстояния до ближайшего кластера для каждой выборки. Это идеально подходит для варианта использования, так как у нас нет доступных истинных значений.

Анализ

Исследование данных

Извлечена выборка из 10000 адресов Ethereum. Поскольку некоторые из них не удовлетворяют дальнейшим условиям в указанном запросе, во фрейме данных доступно около 8000. Как видно из таблицы ниже, минимальный порог для ether_balance составляет 1 эфир. Это была произвольно установленная граница, поскольку многие адреса Ethereum имеют нулевой баланс.

Среднее значение составляет 138 эфиров (на данный момент около 25 тысяч евро по состоянию на 15 мая 2020 г.), что указывает на асимметрию распределения, когда мы смотрим на значение 75-го процентиля. В то время как 75-й процентиль составляет менее 13 эфиров, среднее значение составляет 138. В выборке явно есть некоторые сильные выбросы, такие как наибольшее значение с балансом 300000 эфиров.

Функция unique_tokens не так рассредоточена на балансе эфира. Обычная стоимость варьируется от 2 уникальных жетонов до 8 имеющихся жетонов.

Уникальные_передачи сильно различаются. В то время как среднее количество передач составляет 26, наибольшее количество - 28 560. Мы видим, что верхние 25% адресов генерируют большую часть передач, поскольку ни один из адресов в 75 процентиле не имеет более одной передачи.

Исследовательская визуализация

Ниже представлена ​​матрица рассеяния для всех построенных функций. Как видно из визуализации, в функциях eth_balance и unique_transfers присутствует степенное распределение. Подавляющее большинство совокупной стоимости обоих генерируется меньшинством адресов.

Между тем, между различными функциями не наблюдается особой корреляции.

Ниже представлена ​​тепловая карта корреляции для всех доступных функций. Как уже указывалось выше, между разными характеристиками мало корреляции. Это положительный знак, поскольку мы хотим исследовать разные области пространства функций с разными функциями. Если бы была сильная корреляция, мы могли бы объяснять одни и те же явления с разными характеристиками.

Алгоритмы и техники

Все методы, используемые для прогнозирования кластеров, представляют собой алгоритмы машинного обучения без учителя. Выбраны K-средние, модели гауссовой смеси и иерархическая кластеризация.

Как и в K-средних, границы между кластерами всегда линейны, два других алгоритма используются для обработки более сложных границ. Кроме того, есть возможность расширить анализ, измерив вероятность или неопределенность кластерных присвоений. Это не делается в анализе, но это возможное расширение.

Контрольный показатель

В качестве эталонной модели для проекта используется показатель Silhouette Score по алгоритму K-средних. После этого используются более сложные алгоритмы для сравнения производительности. Как показывает практика, оценка Silhouette 0,5 определяется как пороговое значение для решения, которое считается приемлемым с точки зрения производительности.

Методология

Предварительная обработка данных

Извлечены три функции:

  • Текущий баланс Ethereum
  • Уникальные жетоны, которые исторически хранились
  • Уникальные переводы по адресу Ethereum

Реализация

В проекте используется довольно много модулей Python. Между тем, некоторые из них являются ключевыми для реализации. Для запроса источника данных BigQuery Ethereum использовалась библиотека Pandas_gbq. Google-cloud-bigquery использовался для аутентификации в учетной записи службы GCP. Scikit-learn использовался как инструмент для всех моделей.

Сервисы AWS, используемые в проекте:

  • S3 для хранения обучающих данных, предварительной обработки с помощью объекта-преобразователя и учетных данных GCP
  • SageMaker для использования экземпляров записных книжек и сквозного подключения проекта
  • Лямбда-функция для запуска сценария прогнозирования
  • API Gateway для создания API, который используется в веб-интерфейсе пользователя, с которым взаимодействует пользователь.
  • CloudWatch для регистрации и отладки возможных проблем, возникших в процессе создания решения.

Используются две таблицы из общедоступного источника данных Ethereum:

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

Потрясающие представления BigQuery на Github использовались для построения запросов SQL и лучшего понимания модели данных Ethereum.

Ниже мы можем увидеть несколько примеров построенных функций для разных адресов Ethereum.

После этого функциональность конвейера Sklearn используется для предварительной обработки функций. Мы нормализуем их, чтобы убедиться, что функции полезны для использования в моделях. Это делается с помощью преобразования мощности, стандартного масштабирования и преобразования PCA. Преобразование PCA может быть здесь избыточным, поскольку есть только три функции, сопоставленные с тремя компонентами, но может быть полезно, если набор функций расширен, а размерность должна быть уменьшена с учетом размера выборки.

С помощью последнего набора функций обучаются все три альтернативных алгоритма кластеризации: модель K-средних, модель GMM и модель иерархической кластеризации.

Визуализация ниже отображает количество экземпляров в каждом из 4 кластеров.

Выбранное количество кластеров - 4. Оно выбрано методом проб и ошибок различных значений. Поскольку производительность альтернативных алгоритмов существенно не улучшает коэффициент Силуэт, в решении, которое используется в развернутой модели, используется метод K-средних.

После обучения с использованием обучающего сценария метаданные обученной модели объединяются со сценарием прогнозирования для прогнозирования значения кластера отдельных адресов Ethereum.

Сценарий прогнозирования на лету выполняет расчет значений характеристик предоставленного адреса Ethereum. Он запрашивает источник данных Ethereum и возвращает нормализованные значения функций. Затем они используются в качестве входных данных в обученной модели, которая возвращает прогнозируемое значение кластера.

Окончательное решение - это конечная точка прогнозирования, запускаемая как лямбда-функция через API-шлюз. Лямбда-функция - это облачная функция, основанная на бессерверной архитектуре. Он развертывается через API-шлюз как API, который можно использовать в пользовательском интерфейсе веб-приложения.

Каждый раз, когда пользователь вводит адрес Ethereum и нажимает кнопку «Отправить», прогнозируемое значение кластера отображается в пользовательском интерфейсе.

Полученные результаты

Оценка и проверка модели

Конечным результатом является веб-приложение, которое возвращает профиль инвестора на основе предоставленного пользователем адреса Ethereum. Пользователю не нужно предоставлять какие-либо свои личные данные, поскольку все необходимые данные могут быть извлечены из общедоступного источника данных Ethereum.

Модели оцениваются по шкале Silhouette. Поскольку в настоящее время существует более 100 миллионов существующих адресов Ethereum, трудно надежно выбрать адреса без применения некоторых явных правил, таких как фильтрация нетривиальных балансовых сумм.

Модель оценивается эмпирически с выбранной метрикой. Оценка K-means по Silhouette составляет 0,38. Поскольку нет доступных истинных значений, невозможно объективно проверить это масштабируемым образом. С другой стороны, выбранная метрика хорошо определяет, насколько разные кластеры различаются в пространстве признаков.

Окончательное решение тестируется в веб-приложении, где прогнозируемое значение кластера извлекается для образца адреса Ethereum.

Учитывая производительность, ясно, что в извлеченных данных недостаточно разброса, чтобы можно было создавать интерпретируемые кластеры. При просмотре различных кластеров также не удалось найти значимого наименования кластеров.

Обоснование

Пороговые значения 0,5 для коэффициента Silhouette не достигаются, что означает, что с учетом этого показателя мы не можем описать модели, чтобы иметь четкое представление о лежащих в основе данных. Между тем, главной целью проекта было создание минимально жизнеспособного решения, которое затем можно было бы улучшить.

Самыми большими узкими местами производительности являются функции, заложенные в модели. Обладая лучшим пониманием базовой модели данных, мы могли бы создать лучший набор функций.

Кроме того, можно улучшить предварительную обработку. Кроме того, количество кластеров было выбрано методом проб и ошибок с одинаковыми значениями для всех алгоритмов. Это можно ускорить, используя более сложный анализ (анализ силуэта).

Заключение

Этот проект показывает, как можно относительно быстро настроить конвейер машинного обучения и предоставить его в виде продукта данных в веб-интерфейсе.

Учитывая развитие как науки о данных, так и криптоиндустрии, мы постепенно увидим сдвиг, когда станет более обычным объединение этих технологий таким образом, который ранее был невозможен.

Благодаря облачным сервисам многие сложности абстрагируются, что помогает специалистам по данным, которые часто не имеют подготовки в области разработки программного обеспечения и DevOps / MLOps. Кроме того, высокоуровневые API-интерфейсы могут помочь инженерам создавать продукты данных, которые ранее были доступны только специализированным специалистам в области данных. По мере развития этих областей мы можем увидеть много нового, чему поучиться друг у друга, что позволит создать новую парадигму программных продуктов.

Дальнейшие исследования

Некоторые другие проекты, работающие над решениями для шифрования данных: