Esta publicación está coescrita con el Dr. Quan Hoang Nguyen, CTO de Fantom Foundation.

Aquí en Fundación Fantom (Fantom), hemos desarrollado una plataforma de contrato inteligente de alto rendimiento, altamente escalable y segura. Está diseñado para superar las limitaciones de la generación anterior de plataformas blockchain. La plataforma Fantom no requiere permisos, es descentralizada y de código abierto. La mayoría de las aplicaciones descentralizadas (dApps) alojadas en la plataforma Fantom carecen de una página de análisis que proporcione información a los usuarios. Por lo tanto, nos gustaría construir una plataforma de datos que admita una interfaz web que se hará pública. Esto permitirá a los usuarios buscar una dirección de contrato inteligente. Luego, la aplicación muestra métricas clave para ese contrato inteligente. Dicha plataforma de análisis puede brindar información y tendencias para las aplicaciones implementadas en la plataforma para los usuarios, mientras que los desarrolladores pueden continuar enfocándose en mejorar sus dApps.

Laboratorio de datos de AWS ofrece compromisos acelerados de ingeniería conjunta entre los clientes y los recursos técnicos de AWS para crear productos tangibles que aceleren las iniciativas de modernización de datos y análisis. Data Lab tiene tres ofertas: Build Lab, Design Lab y Resident Architect. Build Lab es una construcción intensiva de 2 a 5 días con un equipo técnico del cliente. Design Lab es un compromiso de medio día a 2 días para clientes que necesitan una recomendación de arquitectura del mundo real basada en la experiencia de AWS, pero que aún no están listos para construir. Ambos compromisos se alojan en línea o en un centro de laboratorio de datos de AWS en persona. El arquitecto residente brinda a los clientes de AWS orientación técnica y estratégica para refinar, implementar y acelerar su estrategia y soluciones de datos durante un compromiso de 6 meses.

En esta publicación, compartimos la experiencia de nuestro compromiso con AWS Data Lab para acelerar la iniciativa de desarrollar una canalización de datos desde una idea hasta una solución. Durante 4 semanas, llevamos a cabo sesiones de diseño técnico, revisamos las opciones de arquitectura y construimos la canalización de datos de prueba de concepto.

Revisión de casos de uso

El proceso comenzó cuando nos comprometimos con nuestro equipo de cuentas de AWS para enviar una nominación para el laboratorio de datos. A esto le siguió una llamada con el equipo de AWS Data Lab para evaluar la idoneidad de los requisitos con respecto al programa. Después de programar el laboratorio de compilación, un arquitecto de laboratorio de datos de AWS se comprometió con nosotros a realizar una serie de llamadas previas al laboratorio para finalizar el alcance, la arquitectura, los objetivos y los criterios de éxito del laboratorio. El alcance era diseñar una canalización de datos que recopilaría y almacenaría datos de transacciones en cadena históricas y en tiempo real, y crearía una canalización de datos para generar métricas clave. Una vez ingeridos, los datos deben transformarse, almacenarse y exponerse a través de API basadas en REST y ser consumidos por una interfaz de usuario web para mostrar métricas clave. Para este Build Lab, elegimos ingerir datos para Escalofriante, que es un intercambio descentralizado (DEX) implementado en la plataforma Fantom y tenía el valor total bloqueado (TVL) más grande en ese momento. Se seleccionaron métricas clave como la cantidad de billeteras que han interactuado con la dApp a lo largo del tiempo, la cantidad de tokens y su valor intercambiado por la dApp a lo largo del tiempo y la cantidad de transacciones para la dApp a lo largo del tiempo para visualizar a través de una interfaz de usuario basada en la web.

Exploramos varias opciones de arquitectura y elegimos una para el laboratorio que se alineaba estrechamente con nuestro objetivo final. Los datos históricos totales del contrato inteligente seleccionado fueron de aproximadamente 1 GB desde la implementación de dApp en la plataforma Fantom. Nosotros usamos Ftmscan, que nos permite explorar y buscar transacciones en la plataforma Fantom, para estimar la tasa de transacciones de transferencia en aproximadamente tres o cuatro por minuto. Esto nos permitió diseñar una arquitectura para el laboratorio que puede manejar esta tasa de ingesta de datos. Acordamos utilizar una aplicación existente conocida como productor de datos que fue desarrollado internamente por el equipo de Fantom para ingerir transacciones en cadena en tiempo real. Al verificar el tamaño de la carga útil de las transacciones, se encontró que no excedía los 100 kb para cada transacción, lo que nos dio la medida de la cantidad de archivos que se crearán una vez ingeridos a través de la aplicación productora de datos. Se tomó la decisión de ingerir los últimos 45 días de transacciones históricas para llenar la plataforma con suficientes datos para visualizar métricas clave. Debido a que la función de retroactividad existe dentro de la aplicación del productor de datos, acordamos usarla. El Arquitecto del Laboratorio de Datos también nos aconsejó considerar el uso de Servicio de migración de bases de datos de AWS (AWS DMS) para ingerir datos de transacciones históricas posteriores al laboratorio. Como último paso, decidimos crear una página web basada en React con Material-IU que permite a los usuarios ingresar una dirección de contrato inteligente y elegir el intervalo de tiempo, y la aplicación obtiene los datos necesarios para mostrar el valor de las métricas.

Resumen de la solución

Acordamos colectivamente incorporar los siguientes principios de diseño para la arquitectura del laboratorio de datos:

• Canalizaciones de datos simplificadas
• Arquitectura de datos descentralizada
• Minimice la latencia tanto como sea posible

El siguiente diagrama ilustra la arquitectura que construimos en el laboratorio.

Definimos colectivamente los siguientes criterios de éxito para el laboratorio de compilación:

• Tubería de transmisión de datos de extremo a extremo para ingerir transacciones en cadena
• Ingestión de datos históricos del contrato inteligente seleccionado
• Almacenamiento de datos y procesamiento de transacciones en cadena
• API basadas en REST para proporcionar métricas basadas en el tiempo para los tres casos de uso definidos
• Una interfaz de usuario web de muestra para mostrar métricas agregadas para el contrato inteligente

Antes del laboratorio de construcción

Como requisito previo para el laboratorio, configuramos la aplicación de producción de datos para usar el Kit de desarrollo de software de AWS (SDK de AWS) y PUTRecords Operación API para enviar datos de transacciones a un Servicio de almacenamiento simple de Amazon (Amazon S3) cubeta. Para Build Lab, creamos una lógica adicional dentro de la aplicación para ingerir datos de transacciones históricas junto con datos de transacciones en tiempo real. Como último paso, verificamos que los datos de las transacciones se capturaron e incorporaron en un depósito S3 de prueba.

Servicios de AWS utilizados en el laboratorio

Utilizamos los siguientes servicios de AWS como parte del laboratorio:

• Administración de acceso e identidad de AWS (IAM) – Creamos múltiples roles de IAM con relaciones de confianza apropiadas y los permisos necesarios que pueden ser utilizados por múltiples servicios para leer y escribir datos de transacciones en cadena y registros generados.
• Amazon S3 – Creamos un depósito S3 para almacenar los datos de las transacciones entrantes como archivos basados ​​en JSON. Creamos un depósito S3 separado para almacenar los datos de transacciones entrantes que no se pudieron transformar y se volverán a procesar más adelante.
• Secuencias de datos de Amazon Kinesis – Creamos un nuevo flujo de datos de Kinesis en modo bajo demanda, que se escala automáticamente en función de los patrones de ingesta de datos y proporciona administración de capacidad de manos libres. Esta transmisión fue utilizada por la aplicación del productor de datos para ingerir transacciones en cadena históricas y en tiempo real. Hablamos de tener la capacidad de administrar y predecir costos y, por lo tanto, se nos recomendó usar el modo aprovisionado cuando se dispusiera de estimaciones confiables para los requisitos de rendimiento. También se nos aconsejó que siguiéramos usando el modo bajo demanda hasta que los patrones de tráfico de datos fueran impredecibles.
• Manguera de bomberos de datos de Amazon Kinesis – Creamos un flujo de entrega de Firehose para transformar los datos entrantes y escribirlos en el depósito S3. Para minimizar la latencia, configuramos el tamaño del búfer del flujo de entrega en 1 MiB y el intervalo del búfer en 60 segundos. Esto garantizaría que se escriba un archivo en el depósito S3 cuando cualquiera de las dos condiciones se cumpla, independientemente del orden. Los datos de transacciones escritos en el depósito S3 estaban en formato JSON Lines.
• Servicio de cola simple de Amazon (Amazon SQS) – Configuramos una cola SQS del tipo Estándar y una política de acceso para esa cola SQS para permitir los mensajes entrantes generados a partir de las notificaciones de eventos del depósito S3.
• Amazon DynamoDB – Para elegir un almacén de datos para las transacciones en cadena, necesitábamos un servicio que pudiera almacenar la carga útil de transacciones de datos no estructurados con esquemas variables, brindar la capacidad de almacenar en caché los resultados de las consultas y ser un servicio administrado. Elegimos DynamoDB por esos motivos. Creamos una sola tabla de DynamoDB que contiene los datos de las transacciones entrantes. Después de analizar los patrones de consulta de acceso, decidimos utilizar el campo de dirección del contrato inteligente como clave de partición y el campo de marca de tiempo como clave de ordenación. La tabla se creó con escalado automático de los modos de capacidad de lectura y escritura porque los requisitos de uso reales serían difíciles de predecir en ese momento.
• AWS Lambda – Creamos las siguientes funciones:
  • Una función Lambda basada en Python para realizar transformaciones en los datos entrantes de la aplicación productora de datos para aplanar la estructura JSON, convertir la marca de tiempo de época basada en Unix en un valor de fecha/hora y convertir valores de cadena hexadecimales en un valor decimal que representa el número de fichas.
  • Una segunda función de Lambda para analizar los mensajes de cola de SQS entrantes. Este mensaje contenía valores para bucket_name y object_key, que contiene la referencia a un objeto recién creado dentro del depósito S3. La lógica de la función Lambda incluía el análisis de este valor para obtener la referencia al objeto de S3, obtener el contenido del objeto, leerlo en un objeto de marco de datos mediante el SDK de AWS para pandas (awswrangler) librería, conviértalo en un objeto de marco de datos de Pandas y use el poner_df Llamada a la API para escribir un objeto de marco de datos de Pandas como un elemento en una tabla de DynamoDB. Elegimos usar Pandas debido a la familiaridad con la biblioteca y las funciones necesarias para realizar operaciones de transformación de datos.
  • Tres funciones Lambda separadas que contienen la lógica para consultar la tabla de DynamoDB y recuperar elementos para agregar y calcular valores de métricas. Este valor de métrica calculado dentro de la función Lambda se formateó como una respuesta HTTP para exponer como API basadas en REST.
• Puerta de enlace API de Amazon – Creamos un punto final de API basado en REST que utiliza la integración de proxy de Lambda para pasar una dirección de contrato inteligente y un intervalo de tiempo en minutos como un parámetro de cadena de consulta a la función Lambda de backend. La respuesta de la función Lambda fue un valor de métrica. también habilitamos intercambio de recursos de origen cruzado (CORS) soporte dentro de API Gateway para consultar con éxito desde la interfaz de usuario web que reside en un dominio diferente.
• Reloj en la nube de Amazon – Utilizamos un mecanismo integrado de función Lambda para enviar métricas de funciones a CloudWatch. Las funciones de Lambda vienen con un grupo de registro de CloudWatch Logs y un flujo de registro para cada instancia de su función. El entorno de tiempo de ejecución de Lambda envía detalles de cada invocación al flujo de registro y transmite registros y otros resultados del código de su función.

Enfoque de desarrollo iterativo

A lo largo de 4 días del Build Lab, llevamos a cabo un desarrollo iterativo. Comenzamos desarrollando la capa fundamental y agregamos características adicionales de manera iterativa a través de pruebas y validación de datos. Esto nos permitió desarrollar la confianza en la solución que se está construyendo a medida que probamos el resultado de las métricas a través de una interfaz de usuario basada en web y verificamos con los datos reales. Cuando se descubrieron errores, eliminamos todo el conjunto de datos y volvimos a ejecutar todos los trabajos para verificar los resultados y resolver esos errores.

resultados de laboratorio

En 4 días, construimos una tubería de transmisión de extremo a extremo que ingirió 45 días de datos históricos y datos de transacciones en cadena en tiempo real para el contrato inteligente Spooky seleccionado. También desarrollamos tres API basadas en REST para las métricas seleccionadas y una interfaz de usuario web de muestra que permite a los usuarios insertar una dirección de contrato inteligente, elegir una frecuencia de tiempo y visualizar los valores de las métricas. En una llamada de seguimiento, nuestro arquitecto de laboratorio de datos de AWS compartió una guía posterior al laboratorio sobre los siguientes pasos necesarios para poner en producción la solución:

• Escalado de la prueba de concepto para manejar mayores volúmenes de datos
• Mejores prácticas de seguridad para proteger los datos mientras están en reposo y en tránsito
• Mejores prácticas para el modelado y almacenamiento de datos
• Creación de una técnica de resiliencia automatizada para manejar el procesamiento fallido de los datos de las transacciones
• Incorporar soluciones de alta disponibilidad y recuperación ante desastres para manejar las solicitudes de datos entrantes, incluida la adición de la capa de almacenamiento en caché

Conclusión

A través de un compromiso corto y un equipo pequeño, aceleramos este proyecto de una idea a una solución. Esta experiencia nos dio la oportunidad de explorar en profundidad los servicios de AWS y sus capacidades analíticas. Como próximo paso, continuaremos aprovechando los equipos de AWS para mejorar la solución creada durante este laboratorio para que esté lista para la implementación de producción.

Aprenda más sobre cómo AWS Data Lab puede ayudar a sus datos y análisis en el viaje a la nube.

Acerca de los autores

Dr. Quan Hoang Nguyen Actualmente es CTO en Fantom Foundation. Sus intereses incluyen DLT, tecnologías de cadena de bloques, análisis visual, optimización de compiladores y memoria transaccional. Tiene experiencia en I+D en la Universidad de Sydney, IBM, Capital Markets CRC, Smarts – NASDAQ y National ICT Australia (NICTA).

Ankit Patira es arquitecto de laboratorio de datos en AWS con sede en Melbourne, Australia.