Actualización del Desarrollador de Steem (Graphene 2.0)

Imágen creada por AlexanderAlUS conforme a
CC By-SA 3.0

Esta actualización es para aquellos que están interesados respecto al trabajo actual tras bambalinas de nuestro equipo y para dar a conocer a la comunidad que esperar en las próximas semanas. Estamos realmente entusiasmados respecto de lo que significan algunas de estas actualizaciones tanto para Steem como para la tecnología blockchain en general.

Presentando a Graphene 2.0

Graphene es la tecnología subyacente que potencia a diversas blockchains (Steem, Bitshares, Golos, etc). Graphene 1.0 fue disruptivo debido a su capacidad para procesar cientos de miles de transacciones por segundo. Es extremadamente amigable con los desarrolladores y permitió el desarrollo de Steem en solo un par de meses. Graphene 2.0 es una revisión significativa respecto de esta tecnología de soporte que está orientada a ayudar a plataformas tales como steemit.com a escalar de forma segura y económica.

Adoptando Archivos Mapeados en Memoria para el Almacenamiento

En Graphene 2.0 todos los estados de consenso de la blockchain serán mantenidos en un archivo mapeado en memoria que se podrá compartir entre múltiples procesos. Esto implica que el estado de la aplicación se encuentra efectivamente "en el disco" y que el sistema operativo se encargará de paginas los datos hacia/desde el disco a medida que sea necesario. En la medida que los requerimientos de memoria de la blockchain crecen, esto proporcionará diversos importantes beneficios:

1. Tiempos de carga y salida mas rápidos
2. Acceso paralelo a la base de datos
3. Mayor robustez contra cuelgues
4. Menor frecuencia de corrupción de la base de datos
5. "Copia instantánea" de todo el estado
6. Servir a mas requerimientos RPC (Llamada a Procedimiento Remoto) con la misma memoria

Problemas con Graphene 1.0

Graphene esta diseñado para mantener todo el estado de consenso de la blockchain en memoria empleando lo que probablemente sea una de las estructuras de datos de memoria de mayor rendimiento Boost Multi-index Containers. Para las cryptomonedas tradicionales, este enfoque escala bien porque el estado de la aplicación (balances de cuenta) es relativamente pequeño comparado con el throughput (volumen de información neto) transaccional (transferencia de balance y operaciones).

Steem posee un estado de aplicación mucho mayor al de cualquier otra cryptomoneda. Este estado incluye todo el contenido del artículo, listas de feed y votos. Adicionalmente, este estado es consultado por miles de lectores pasivos que están interesados en navegar exploradores de blockchain como ser steemit.com.

Steem es actualmente la segunda blockchain mas grande medida en transacciones-por-segundo. Solo Bitcoin está procesando mas transacciones que Steem. El estado de consenso de Steem esta creciendo a un ritmo más rápido que cualquier otra blockchain ya que casi cada operación agrega mas estado del que consume (especialmente para el caso de nodos completos que están sirviendo a steemit.com).

Actualmente los nodos de Steem que potencian a steemit.com consumen más de 14 GB de RAM y esta cifra está creciendo a un ratio veloz. Cada vez que queremos agregar una nueva característica, significa por lo general el incrementar la cantidad de RAM requerida.

Tiempos Lentos de Entrada y Salida

Cuando un nodo completo arranca, debe procesar e indexar muchos gibabytes de datos. Este proceso actualmente demora 10s de segundos cuando no hay contratiempos. Si se detecta algún contratiempo al cargar el estado grabado, entonces toda la blockchain debe ser procesada para regenerar el estado a partir del historial de transacciones. Este reproceso de la blockchain puede demorar mas de 5 minutos incluso en las máquinas mas rápidas.

Cuando un nodo completo se cierra, debe guardar todos estos datos en disco. Esto también puede demorar 10s de segundos. Si algo sale mal mientras se los guarda, entonces la próxima vez que se carga la base de datos se necesitarán unos 5+ minutos para recargar la blockchain.

El Cuello de Botella del Subproceso Unico limita las Conexiones

Graphene fue diseñado para ser un subproceso único por razones de rendimiento. La naturaleza de la tecnología blockchain requiere una generación de estado de consenso determinístico, lo cual implica un órden secuencial definido de operaciones para todo aquello que impacte el estado compartido. La sobrecarga de la sincronización de subproceso múltiple es mayor que cualquiera de los beneficios que pudieramos obtener.

En un ambiente normal de blockchain, esto es perfectamente aceptable, pero Steem no es una blockchain normal. Nuestros nodos de Steem están procesando pedidos de miles de clientes en cada segundo. Cada uno de estas solicitudes deben ser procesadas por el servidor proxy al subproceso que tiene permitido leer y escribir en la base de datos. En resúmen, cada nodo Steem solo posee la capacidad de procesar cerca de 150 conexiones simultáneas antes de que los usuarios comiencen a experimentar una degradación en el rendimiento del sitio web.

Para poder mantener un buen rendimiento para todos los usuarios, steemit.com ejecuta varias instancias del nodo Steem y los balances de pedidos de carga entre todas las instancias. Cada una de estas instancias requiere otros 14 GB de RAM (y creciendo).

Recuperar un Cuelgue de Software es Caro

Cualquier error de software puede causar un cuelgue inesperado que redundará en un estado de aplicación corrompido. Cuando un nodo se cuelga, puede demorar minutos en recuperar al mismo tiempo que emplea al máximo el núcleo del CPU.

Cualquier proceso que esté sirviendo a pedidos de usuarios se encuentra expuesto a un mayor riesgo de errores de software y cuelgues debido a que los procesos cambian en forma más frecuente que el núcleo de la lógica de consenso.

Versionado de la API

Cada vez que actualizamos nuestra API, esto nos demanda que ejecutemos un núcleo completo. El apoyar múltiples versiones de nuestra API en forma paralela demanda recursos significativos. Bajo Graphene 2.0, varias APIs pueden compartir la misma base de datos compartida y se pueden arrancar y detener a voluntad.

Mejor Control de Acceso

Ahora es posible servir a todos los pedidos de nuestra bases de datos de la blockchain desde un proceso que ha sido mapeado en la base de datos en modo SOLO-LECTURA. Esto significa que el sistema operativo impondrá que ninguna llamada API pueda corromper el estado de consenso de la base de datos de la blockchain en forma inadvertida.

Protocolos de Red Paralela

Bajo el nuevo modelo, podemos separar el codigo de red P2P del codigo núcleo y logico de la base de datos. Esta separación nos permitirá el agregar múltiples protocolos de red en forma paralela al mismo tiempo que matenemos un firewall impuesto por sistema operativo entre el código de red expuesto al público y el código de validación lógica núcleo de la blockchain.

Esto nos permitirá arrancar, detener y rearrancar la infraestructura de red P2P sin tener que rearrancar toda la base de datos de la blockchain.

Resúmen

Graphene 2.0 implicará actualizaciones significativas al núcleo mismo de Steem y nos demandará varias semanas de implementación y testeo. Debido a que esta actualización tiene implicancias tan abarcativas, todas las demás nuevas características de la blockchain a introducir, se pausaran hasta que esta migración este completada. Habrá un extenso periodo de testeo en donde las versiones antigua y nueva de Steem estarán siendo ejecutadas al mismo tiempo para asegurar que no introduzcamos ningun cambio de consenso inesperado que produzca un hard-fork.

Cuando la migración a Graphene 2.0 esté lista, enfocaremos nuestra atención en los Curation Guilds (Gremios de Curado).

Read the original article by @steemitblog here!