Este post es el resultado de leer a fondo el whitepaper de Hive para entender mejor sus fundamentos y funcionamiento. El texto a continuación es un resumen de los aspectos que he considerado importantes antes de disponerse a desarrollar o utilizar herramientas (DApps) que utilizan la blockchain de Hive. El siguiente texto no es una traducción fiel al contenido original que puede encontrarse en https://hive.io/whitepaper.pdf. He omitido algunos párrafos y modificado otros buscando explicar de una manera más simple el contenido original.

I. Introducción

Hive es una blockchain descentralizada e innovadora, basada en el protocolo de consenso Delegated Proof of Stake (DPoS). En otros posts hablaré un poco más sobre DPoS lo importante ahora es que DPoS funciona de manera similar a Proof of Stake (PoS) [Google It] sin embargo agrega un mecanismo de votación y delegación que hace que el proceso de construcción y validación de bloques sea más democrático.

Hive aborda de manera eficiente los problemas de escalabilidad, adopción masiva y versatilidad que presentan otras blockchains a la hora de construir aplicaciones descentralizadas. Permite un método fácil de almacenamiento inmutable y recuperación de información. Hive reconoce que las tarifas de transacción son a menudo uno de los mayores desafíos para facilitar el desarrollo y la flexibilidad de uso de las aplicaciones descentralizadas (DApps). En lugar de requerir tarifas de transacción potencialmente costosas e inconvenientes, Hive utiliza un mecanismo novedoso de crédito de recursos basado en participaciones para crear un modelo sin tarifas.

En Hive se aprovecha el concepto acuñado Proof-of-Brain (PoB) [Google It] distribuyendo una parte de la inflación a los creadores de contenido y consumidores. Para ganar sin inversión financiera, las personas participan en una amplia gama de actividades. Estos incluyen blogs, participar en discusiones, construir e interactuar con DApps, jugar juegos y más; sus límites solo están limitados por su propia imaginación para promover la descentralización del sistema. Todo el contenido está siempre disponible en la blockchain y conserva su integridad original.

Hive fue creado como una bifurcación independiente y descentralizada de la cadena de bloques Steem. Como una bifurcación impulsada por la comunidad, su intención es continuar con los sólidos valores comunitarios que se han establecido, al tiempo que libera al ecosistema de la carga de Steemit Inc. y su influencia desproporcionada. Si bien esa influencia había amenazado la descentralización de Steem desde su inicio en 2016, se mantuvo bajo control mediante un contrato social. Tras la venta de Steemit Inc a Sun Yuchen de la Fundación Tron en febrero de 2020, la explotación de esta influencia y la pérdida de confianza en la viabilidad continua de Steem finalmente llevaron a la creación de la cadena de bloques Hive.

II Hive Assets

II.1 Assets

La red de Hive posee dos clases de assets llamados HIVE y Hive Backed Dollar (HBD). Los HBD están destinados a vincularse al dólar estadounidense (USD) a una tasa de uno a uno.. El asset HIVE se puede poseer de forma "líquida" (o sea que puede ser transferido, comprado, vendido al igual que cualquier criptomoneda) o en forma de Hive Power que es el mecanismo empleado para hacer stacking en la red de Hive. Los Hive Power (HP) se adquieren mediante un proceso denominado "Power Up". Los HP también pueden convertirse nuevamente a su estado "líquido" mediante un proceso denominado "Power Down". El proceso de Power Down dura 13 semanas, durante esas semanas los HP se van transformando en HIVE con con un segmento entregado cada 7 días. Es decir la cantidad de HP que desee transformar en HIVE será dividida en 13 partes iguales que le serán entregadas cada una semana hasta completar el proceso.

II.2 Créditos de Recursos (Resource Credits - RC)

En lugar de depender de las tarifas de transacción, Hive utiliza un sistema sin tarifas que aprovecha los Resource Credits (RC) recargables. En este marco, cada cuenta tiene una determinada cantidad de créditos relacionados con su participación. Luego, esos créditos se consumen cuando las transacciones se ejecutan en la blockchain y se recuperan automáticamente con el tiempo. La cantidad de Hive Power adjunta a una cuenta determinada determina su nivel de participación y permite el cálculo del ancho de banda asociado. Este último indica cuánto podría realizar una cuenta determinada en un período de tiempo específico y se origina en los RC disponibles de la cuenta, que se muestran como maná.

Los RC se auto-reponen a una tasa del 20% cada 24 horas. Dicha tasa de reabastecimiento actúa como un autolimitador y requiere que la cuenta cuente con Hive Power directamente proporcional al propósito y la intención de uso de la cuenta. Una cuenta que proyecta una tasa de uso más alta necesitará más Hive Power que una cuenta que rara vez realiza transacciones.

Los RC son utilizados por diferentes formas de transacciones a diferentes tasas. Una transacción que implica la publicación de un párrafo de material textual agotará más maná que una transacción que consiste en una transferencia de activos. La cantidad de maná necesaria para realizar transacciones también se ve afectada por la cantidad de transacciones durante el tiempo de uso. Las transacciones realizadas en horas pico consumen más recursos que las realizadas durante períodos de bajo uso.

Las cuentas que se quedan sin RC pueden emitir transacciones a través de un mecanismo de delegación que se explicará más adelante. Las cuentas que tienen 0 HP Power aún pueden emitir transacciones limitadas que varían según el tiempo de uso y la carga de la blockchain. Por ejemplo, una cuenta con 0 HP puede tener suficientes RC para emitir con éxito 2 publicaciones textuales o alrededor de 17 transferencias durante un período de uso específico. De esta forma, Hive elimina una de las mayores barreras de entrada para usuarios y desarrolladores.

II.3 Delegación

El Hive Power puede prestarse temporalmente a otras cuentas mediante una función llamada "delegación". Se puede otorgar HP delegado a otras cuentas durante cualquier período de tiempo. La retractación de una delegación existente tarda un total de cinco días en volver a su billetera de origen.

El HP delegado no se cuenta como deducido de la participación del delegador con respecto al impacto a nivel de gobierno, pero ya no cuenta para sus totales de RC. Por el contrario, el HP delegado aumenta los RC de la cuenta del destinatario durante la duración de la delegación, pero no aumenta su propia participación preexistente en lo que respecta al impacto a nivel de gobernanza. El delegador retiene la propiedad de la participación.

II.4 Asignación y oferta inicial, inflación y oferta final.

Hive se inicializó replicando una instantánea de la cadena de Steem, pero excluyendo las participaciones relacionadas con el ataque de 51% realizado a Steem, con el objetivo de proteger la nueva cadena. Todas las cuentas, excepto aquellas que influyeron explícitamente en la falla de seguridad de DPoS en Steem, recibieron un suministro inicial de HIVE, HBD y HP reflejando directamente sus saldos existentes en Steem.

La tasa de inflación decreciente de Hive es una de sus características monetarias clave y la reducción de la acuñación con el tiempo. La tasa de inflación disminuye un 0,01% cada 250.000 bloques, aproximadamente un 0,5% anual, hasta llegar al 0,95%.

La inflación de Hive se distribuye de la siguiente manera:

1. El 65% se utiliza para llenar la pool de recompensas (que se divide en partes iguales entre productores de contenido y curadores)
2. El 15% se destina a los poseedores (stakeholders) de HP.
3. El 10% va a los testigos para la firma en bloque.
4. El 10% se destina Decentralized Hive Fund (Fondo Descentralizado de Hive).

No existe un límite de valor conocido predefinido para el suministro de Hive. La oferta depende de la tasa de inflación.

II.5 Descentralized Hive Fund (DHF)

DHF es una alternativa de financiación de DPoS basada en propuestas. El DHF pone el consenso detrás del financiamiento directo del desarrollo y otros proyectos positivos para el ecosistema en manos de las partes interesadas. La distribución del DHF está descentralizada por diseño. El apoyo a una propuesta se calcula sobre la base de la participación total en apoyo de esa propuesta. Cuando un usuario opta por apoyar una serie de propuestas, su participación influye en las propuestas por igual. Se puede otorgar o eliminar el apoyo a una propuesta, pero el mecanismo no se puede utilizar para negar la suma de la participación de apoyo con un voto negativo. Esto evita que un solo gran actor duplique el impacto de su participación e influya en la remuneración de numerosas propuestas, creando un campo de juego equitativo.

NOTA: Recomiendo leer más sobre DHF en el texto original en inglés y buscar más información sobre el tema si está realmente interesado en él.

III Producción de bloques, firma y consenso

III.1 Delegated Proof of Stake (DPoS)

Prueba de participación delegada (DPoS) es el algoritmo de consenso detrás de Hive. En DPoS, la selección de los productores de bloques (llamados "testigos" - "witnesses" en Hive) y todas las demás funciones basadas en consenso se deciden en función del peso de los fondos apostados que los respaldan (stake funds o sea el Hive Power). Los Stakeholders tienen la mayor prominencia en DPoS. El consenso DPoS se considera el más inclusivo y el menos centralizado de todos los protocolos de blockchain.

III.1.1 Ataques del 51%

Puede ocurrir un ataque del 51% en una cadena de bloques DPoS cuando un solo stakeholder toma el control directo o indirecto del 51% o más de los activos apostados (staked assets). Hive se creó originalmente como resultado directo de un ataque del 51% a la cadena de bloques Steem cometido por la empresa fundadora Steemit Inc. a través de una colusión sin precedentes. Debido a su experiencia directa con el patrón, las señales de advertencia, las capacidades y los resultados de tales ataques, la comunidad descentralizada de Hive monitorea regularmente dichos ataques. Además, Hive ha tomado medidas para disuadir y mitigar los ataques del 51% a nivel de blockchain a través de disposiciones de gobernanza, incluida la votación diferida con cualquier HP recién apostado (stacked HP).

III.2 Cambios en el protocolo

Las bifurcaciones y los cambios clave en el protocolo son aceptados por 17 de los 20 testigos de consenso. Los testigos aceptan cambios de protocolo actualizando sus nodos o los rechazan al continuar ejecutando la versión actual. Los cambios de protocolo no se aplicarán y entrarán en vigor hasta que se alcance un consenso. Todos los cambios de protocolo se proponen, desarrollan, preparan e implementan a través de un entorno de trabajo en equipo transparente y colaborativo. Son completamente de código abierto desde el inicio hasta su lanzamiento final.

III.3 Producción de bloques

Los bloques se producen a intervalos de 3 segundos y están firmados por "Testigos" seleccionados en función del peso total del Hive Power que los respalda mediante aprobaciones individuales. Hay 20 testigos de consenso a los que se les otorgan operaciones de firma de bloques en un horario rotativo.

Con cada iteración se pueden seleccionar hasta 30 testigos. Los testigos se ordenan en función de la cantidad que poseen. Si bien los 20 testigos de consenso tienen la misma oportunidad de firmar bloques, los testigos clasificados como 21 y posteriores son tratados como testigos de respaldo. El número de oportunidades de firmar que reciben es directamente proporcional al HP que poseen.

Si un testigo no puede firmar un bloqueo debido a que opera en una versión de protocolo incompatible con la cadena principal o debido a cualquier otro problema técnico, la oportunidad de firmar se otorgará automáticamente al siguiente testigo programado. El testigo que no firmó se registrará en la cadena como si se hubiera perdido un bloque.

NOTA: Recomiendo leer mejor esta parte en el whitepaper original, el texto anterior es la interpretación que yo logré hacer, sin embargo no estoy 100% seguro de que este sea exactamente el funcionamiento. Estoy dispuesto a escuchar cualquier opinión con respecto al post y a realizar correcciones en caso de ser necesario.

III.4 Price Feed Consensus

Los testigos de Hive son responsables de garantizar precios fiables y constantes. El propósito de los feeds de precios es promover:

1. Estabilidad del tipo de cambio
2. Precisión de precios
3. Política monetaria confiable

III.5 Tipos de nodos

1. Witness Nodes: Los nodos testigos (witness nodes) se utilizan para firmar bloques.
2. Seed Nodes: Un nodo semilla (seed node) permite conexiones externas peer-to-peer (P2P).
3. API Nodes: Un nodo de API es cualquier nodo que permite conexiones de llamada a procedimiento remoto (RPC) externo. Puede tener una selección de complementos.

III.6 Llaves (Keys)

Hay pares de llaves públicas y privadas en Hive. Todos los pares de llaves se derivan directamente de una contraseña, que en sí misma no es una llave. Cambiar la contraseña regenera los pares de llaves. Las llaves públicas están disponibles abiertamente en la cadena de bloques, mientras que sus contrapartes privadas solo se otorgan al propietario de la cuenta. Ambos pares son necesarios para validar una transacción.

III.6.1 Key Hierarchy

1. Owner Key (Clave de propietario): se utiliza para recuperar cuentas y regenerar otras llaves, así como para establecer una nueva contraseña.
2. Active Key: se utiliza para transferir y administrar fondos, votar por testigos o aprobar propuestas de DHF.
3. Posting Key (Clave de publicación): se utiliza para difundir transacciones de publicación.
4. Memo Key: se utiliza para descifrar mensajes cifrados dentro del parámetro memo de transferencias de fondos.

Los testigos usan sus cuentas para generar una clave adicional llamada Clave de firma (Signing Key). Esa clave se utiliza para indicar que un testigo está disponible para la producción de bloques y es exclusivo de ese testigo. Una cuenta de testigo puede transmitir una clave de firma estática predeterminada para deshabilitarse como firmante de bloque. Esto le permite a la cadena de bloques saber que no debe programar ese testigo en la orden de producción. Para reanudar la firma en bloque, el testigo debe volver a transmitir su clave de firma única.

III.6.2 Sistema fiduciario y recuperación (Trustee System and Recovery)

Cuando una cuenta se ve comprometida a través de suplantación de identidad o un robo similar y sus llaves se cambian sin el consentimiento del propietario, su cuenta de fideicomisario puede recuperarla. El fideicomisario predeterminado de una cuenta es la cuenta que la creó en primer lugar. Tras su creación, una nueva cuenta puede transmitir una transacción solicitando un Fideicomisario diferente. El cambio de fideicomisario tarda 30 días en llegar a ser definitivo. La recuperación solo es posible cuando el período entre el cambio de contraseña o la regeneración de la clave del propietario y la recuperación en sí es inferior a 30 días.

NOTA: Este punto es importante sin embargo no queda claro cuál sería el proceso a seguir. Investigaré un poco más sobre el tema y compartiré información más detallada en otro post. Si tienes conocimientos sobre este proceso siéntete libre de comentar el post o compartir un enlace a otro post donde se pueda obtener más información.

IV. Desarrollo e Integración con Hive

En esta parte del whitepaper se muestra información clave sobre el tema que me interesa personalmente a mí y probablemente a usted que me lee. Le invito a que lea el whitepaper original para que obtenga un background sobre el desarrollo de DApps utilizando Hive. He decidido no mostrar esta parte en este post ya que considero que sería mejor verlo a través de ejemplos de aplicaciones reales que será la tarea que llevaré a cabo en los siguientes post que escriba. Sin embargo insisto en que es sumamente necesario leerse el whitepaper oficial para tener una visión más amplia y adquirir los fundamentos necesarios antes de empezar a escribir código.

Hasta aquí se han mostrado los aspectos básicos de cómo es el funcionamiento de la blockchain de Hive, el protocolo de consenso que utiliza, cómo surge Hive, los tipos de nodos y los tipos llaves que existen en este ecosistema.

Mi objetivo con este escrito es principalmente organizar las ideas e interpretaciones que he ido realizando sobre el whitepaper y compartir esa información un poco más resumida y simplificada con la comunidad. Espero que le sea de utilidad leerlo así como me sirvió a mí de utilidad escribirlo 😀. Nos vemos en un próximo post, o tal vez vídeo. Todavía falta mucho por aprender y hacer pero pienso que este es realmente que Hive o tecnologías similares son el futuro de la web lo importante ahora es ver a Hive como una plataforma para crear y compartir conocimientos; y formar parte de la siguiente revolución de Internet.