Quiénes somos

Bitcoin Verde es una implementación de nodo completo BCH fundada por Josh Green, propietario de Software Verde. Software Verde es un grupo de desarrolladores de software full-stack basados en Columbus, Ohio. El grupo está dedicado al desarrollo de tecnología al servicio de nuestra comunidad, clientes y amigos. Tenemos afinidad por el software open source y, en general, somos todos entusiastas de la tecnología desde siempre. Nuestro equipo está compuesto principalmente por Josh Green, Andrew Groot, Eliot Lesar y John Jamiel.

Comenzamos nuestro viaje para la creación de Bitcoin Verde a fines del 2017, justo unos meses después del hard-fork de BCH. Con deseos de contribuir, decidimos aprender haciendo. Un tanto inseguro de por dónde comenzar, Josh se dio cuenta de que la mayoría de las implementaciones eran versiones provenientes del mismo cliente de referencia: Bitcoin (Core). Decidimos entonces que la mejor manera de contribuir, al tiempo que aprendíamos todos los detalles, era con una construcción desde la base. Uniéndose al ecosistema en enero de 2019, Bitcoin Verde siempre ha tenido objetivo principal proporcionar diversidad a la red BCH. Creemos que hemos logrado ese objetivo a través del lanzamiento de nuestra implementación indexada de nodo completo en Java.

Desde el comienzo hemos trabajado con varios grupos, sean tecnólogos o no, para contribuir con la comunidad de todos los modos que nos fuera posible. Participar en innumerables debates, educar a los gobiernos locales, asociarnos con Bitcoin Unlimited para crear una especificación de BCH descriptiva y continuar mejorando nuestra implementación son aspectos destacados de nuestro trabajo del que estamos orgullosos. Hemos trabajado arduamente durante los últimos años para asegurarnos de que nuestro producto sea significativo y valioso para la comunidad. Actualmente, Bitcoin Verde proporciona a la red una implementación de nodo completo, un explorador de bloques y una librería de desarrollo. Nuestras ambiciones para el futuro son continuar realizando mejoras en nuestra implementación y eventualmente proporcionar módulos para carteras y pools de minería.

Nuestro Objetivo

Nuestro objetivo para esta campaña es generar suficiente interés y apoyo como para financiar la hoja de ruta de nuestro desarrollo actual. A la fecha, Bitcoin Verde tiene cuatro funcionalidades principales identificadas. Creemos que las mismas serán necesarias para continuar operando como una opción competitiva y viable para los operadores de BCH, ya sean nodos completos o mineros. Estas cuatro características incluyen:

• Crear un Módulo Non-Indexing
• Crear un servicio de validación de Block Template
• Implementar la configuración de Testnet
• Modificar el explorador de Bitcoin Verde para soportar Memo

El Trabajo

Creación de Módulo Non-Indexing

Actualmente, Bitcoin Verde indexa gran parte del Blockchain. Algunos de estos componentes indexados incluyen (entre otros):

• todas las transacciones.
• todas las salidas y entradas (gastadas y no gastadas).
• direcciones P2PK/P2SH.
• tokens SLP.
• validación SLP.
• bloques contenciosos/huérfanos.

A pesar de ser muy útiles para los exploradores y los servicios de cartera, estos index proporcionan muchos inconvenientes para los servicios de validación y no tienen un valor real para los nodos de minería. La creación de un módulo non-indexing para Bitcoin Verde proporcionará varios beneficios que contribuirán en última instancia a los objetivos de nuestro equipo para convertirse en un módulo viable para minería. Los beneficios de esta adición incluyen:

• Reducción del tiempo de descarga inicial de bloques.
• Permite que los pools de minería comiencen a correr un nodo Bitcoin Verde en un período de tiempo más razonable.
• Reducción de los recursos mínimos necesarios.
• Reduce las barreras de entrada tanto para los mineros como para los operadores de nodos no indexados.
• Permite a los operadores de pools ejecutar nodos redundantes/de-respaldo para su pool a un costo menor.
• Reducción del costo general de infraestructura para ejecutar un nodo Bitcoin Verde.

La Solución

Con cacheBlocks, los bloques se almacenan serializados en disco. Muchas de las tablas SQL relacionadas a transacciones, direcciones y slp serán removidas.

• Se creará una nueva tabla de transacciones con columnas que pueden ser utilizadas para apuntar a la ubicación en disco donde está almacenado el bloque de la transacción, y un offset de dónde se encuentra la transacción dentro del archivo de bloque.
• Esto migra las transacciones minadas de la base de datos (que está indexada y normalizada, que es ineficiente en espacio y con menor rendimiento) a un formato más compacto en un archivo plano.
• Para mantener la lógica de mempool/transacciones no confirmadas coherente entre los módulos, las antiguas tablas de transaction_* serán renombradas y reutilizadas para transacciones no confirmadas.
• Tener transacciones no confirmadas indexadas y normalizadas nos permite mantener un límite infinito de transacciones encadenadas sin ningún desarrollo adicional.
• A medida que las transacciones son minadas en un bloque, son eliminadas de la tabla unconfirmed_transactions_* y solo son almacenadas en archivos de bloque.
• Dado que las tablas SQL de transacciones no serán grandes, solo la indexación de transacciones no confirmadas es lo que aumenta nominalmente la impronta en disco del nodo, al tiempo que permite la extensibilidad de características futuras así como de decisiones complejas a ser tomadas en relación a la inclusión de transacciones no confirmadas en el siguiente bloque.
• El tamaño total de la transacción y el monto de la tasa serán agregadas a la tabla de transacciones para mejorar la generación del template de bloque.

Los cambios afectarán principalmente a la capa de datos, que está encapsulada por el TransactionDatabaseManager y las clases relacionadas. La lógica de validación y la lógica de red pueden verse mínimamente afectadas. Muchos de los tests existentes dependen de la manipulación directa de los datos de la base de datos para su configuración.

Con un esquema diferente, estos tests fallarán al ser ejecutados con los cambios de esquema para este módulo. Estos cambios de esquema no harán que el conjunto de tests original falle, ya que el conjunto de tests cargan el esquema de indexación de forma predeterminada. Sin embargo, con esta configuración, muchos de los tests no serán ejecutados contra el nuevo esquema, lo que provocará una brecha bastante grande en la cobertura de tests para funcionalidades críticas.

• Esta propuesta incluye la extensión de los tests existentes para incluir la cobertura del esquema de no indexación, así como el esquema de indexación.

Metas, Entregables y Complejidad Estimada

Hemos estimado que este trabajo tomará aproximadamente 180 horas de tiempo de desarrollo para ser completado. Nuestra solución se puede dividir en 3 metas principales , cada una con diferentes grados de complejidad. Proponemos asignar fondos de forma proporcional a la complejidad y al tiempo estimado para el desarrollo necesario, con los fondos recibidos al alcanzar cada meta.

1. Esquema de refactorización de SQL y migraciones de data-layer. 80/180 horas (45%)

   La primera meta consistirá en el esquema SQL y los cambios lógicos discutidos en la descripción general de la solución. Esta meta se considera completa una vez que las tablas sean eliminadas y el nodo complete con éxito su descarga de bloques inicial en main-net.

2. Actualización de tests para nuevo data-layer. 60/180 horas (33%)

   La segunda meta consiste en actualizar todas los tests fallidos para garantizar que se aprueben los tests de regresión existentes. Además, incluye la expansión del conjunto de tests existente para que se ejecuten tanto en esquemas de indexación como de no indexación.

3. Tests de la red principal por un mes ejecutados a través del block template aggregator. 40/180 horas (22%)

   La tercera meta será alcanzada después de que el nodo se sincronice con la red principal y su template de bloque se considere compatible con los nodos Bitcoin ABC y Bitcoin Unlimited.

   La finalización de esta meta requiere que el nodo sea actualizado para el nuevo conjunto de reglas sigops incluido en la actualización 2020-05, y requiere que se complete el block template aggregator para que el block template generado por Bitcoin Verde pueda ser validado automáticamente por otras implementaciones de nodo. Después de un mes de crear templates de bloque en red principal sin incompatibilidades, la meta se considerará alcanzada.

Servicio de Validación de Template de Bloque

Existe el riesgo de que bloques extraídos por mineros puedan causar una división de la cadena o quedar huérfanos debido a que son incompatibles entre las implementaciones de nodos. Desde la perspectiva de un minero, incluso un pequeño riesgo asociado con estas incompatibilidades puede tener un gran impacto en la rentabilidad. Este riesgo de incompatibilidad aumenta el incentivo para que los mineros y los pools ejecuten la misma implementación, lo que reduce en gran medida la diversidad de nodos entre los mineros.

Este servicio de validación de template de bloque (TVS) tiene como objetivo reducir el riesgo de que los mineros creen un bloque no válido a casi cero al validar el template de bloque frente a otras implementaciones antes de realizar cualquier trabajo en el template de bloque. Los beneficios de completar este trabajo incluyen:

• Reducir el riesgo de minar involuntariamente un bloque que causaría una división de red.
• Reducir el riesgo financiero para los mineros de ejecutar diferentes implementaciones de nodos.
• Aumentar la confianza del minero en la diversidad de nodos.
• Alertar a los desarrolladores de posibles bloques incompatibles.

La Solución

Crear un servicio que esté conectado a la última versión de implementaciones de múltiples nodos ("nodos de validación"):

• BCHD
• Bitcoin ABC
• Bitcoin Unlimited
• Bitcoin Verde
• Flowee The Hub

Este servicio debe aceptar un template de bloque estándar de getblocktemplate como se especifica en BIP-22, BIP-23, BIP-9 y BIP-145.

Una vez que el template de bloque es recibido, el servicio garantiza que cada nodo de validación haya visto cada transacción dentro del template de bloque.

• Luego el servicio intentará validar el template de bloque para cada implementación.
• Luego el servicio responderá al solicitante si algún nodo encuentra que el template no es válido.

El servicio hará un esfuerzo mayor por determinar que transacción(es) dispararó el estado inválido para el template de bloque con la intención de que el solictante pueda optar por omitirlas.

Los nodos de validación pueden no estar equipados para validar un template de bloque. Esta solución procederá:

• Definir un BIP formal para extender el getblocktemplate y permitir que su modo de propuesta permita la existencia de un indicador para ignorar la validación de prueba de trabajo para los datos del bloque.
• Crear una implementación de referencia y un pull request para que Bitcoin ABC cumpla con la extensión anterior de getblocktemplate.
• Proporcionando una implementación para Bitcoin ABC debido a su actual mayor porción de mercado.
• Si otras implementaciones proporcionan una funcionalidad similar sin usar directamente getblocktemplate, entonces este problema puede ser luego extendido para crear compatibilidad con esas implementaciones.

Bitcoin Verde actualmente no admite el modo propuesto por getblocktemplate. Este issue va a modificar la funcionalidad actual equivalente para que coincida con la API getblocktemplate RPC, incluyendo el modo de propuesta.

Metas y Entregables Estimados

Hemos estimado que esta adición tomará aproximadamente 160 horas de tiempo de desarrollo para completarla. Nuestra solución se puede dividir en 4 metas principales, cada una con diferentes grados de complejidad. Proponemos asignar fondos de forma proporcional a la complejidad y al tiempo estimado para el desarrollo necesario, con los fondos recibidos al cumplir cada meta.

1. Definir la API de servicio para validar el template de bloque. 30/160 horas (18.75%)
2. Invocar múltiples llamadas RPC getblocktemplate:proposal a los nodos conectados para validar el template de bloque y devolver el estado de validación. 30/160 horas (18.75%)
3. Crear un BIP formal para ampliar la funcionalidad existente de getblocktemplate:proposal. Y la implementación de referencia para Bitcoin ABC. 60/160 horas (37.5%)
4. Modificar Bitcoin Verde para cumplir con el BIP propuesto. 40/160 horas (25%)

Implementar Configuración de Testnet

Actualmente, Bitcoin Verde solo permite conexiones al mainnet. Si bien, históricamente las pruebas de casos extremos han sido realizadas en gran medida a través de unit tests usando vectores de prueba públicos. Existen tests de integración adicionales de los que Bitcoin Verde podría beneficiarse al conectarse al testnet, particularmente en el tiempo previo a los hard-forks en donde el testnet es usado de forma masiva.

Conectarse al testnet también puede proporcionar una forma para que la perspectiva única de Bitcoin Verde de realizar tests de Bitcoin Cash beneficie a otras implementaciones de nodos en caso de que las muchas diferencias entre Bitcoin Verde y esas implementaciones puedan conducir a diferentes tipos de transacciones de test.

Una de las razones clave por las que esto aún no está implementado es que el testnet tiene una serie de diferencias en términos de cómo se transmiten, validan y extraen las transacciones y los bloques. Por tal motivo, todas estas diferencias deberán implementarse como opcionales en función de un nuevo campo de configuración.

Esta solución proporcionará:

• Un modo adicional de test que debería proporcionar beneficios en relación a los modos actuales.
• Mayor exposición a transacciones de casos límite que sean menos prohibitivas en testnet.
• Coordinación mejorada con otras implementaciones de nodos para tests de hard-fork.

La Solución

Si bien Bitcoin Verde actualmente no fuerza la estandarización de las transacciones, algunas medidas deben ser tomadas para garantizar que, si Bitcoin Verde comenzara a hacerlo esa opción estará desactivada por defecto al conectarse al testnet.

Para operar con testnet, se requerirán las siguientes actualizaciones:

• Números de puerto alternativos, magic number y seeds DNS.
• Número de dirección y prefijo.
• Bloque de génesis diferente.
• Reglas adicionales de ajuste de dificultad.

Metas y Entregables Estimados

Hemos estimado que esta adición tomará aproximadamente 60 horas de tiempo de desarrollo para completarla. Nuestra solución se puede dividir en 2 metas principales, cada una con diferentes grados de complejidad. Proponemos asignar fondos de forma proporcional a la complejidad y al tiempo estimado para el desarrollo necesario, con los fondos recibidos al cumplir cada meta.

1. Actualizar componentes con diferentes contenidos estáticos. 20/60 horas (33%)

   La primera meta consiste en los cambios necesarios únicamente para la comunicación con el testnet de BCH. Esto incluye números de puerto, cualquier cosa que afecte el contenido del mensaje de protocolo e información sobre el bloque de génesis. Esta meta se considerará completa una vez que todos los componentes hayan sido actualizados y publicados.

2. Asegurarde de que una sincronización completa es posible. 40/60 horas (67%)

   La segunda meta de esta adición requerirá que actualicemos las reglas de validación de transacciones y bloques para garantizar que Bitcoin Verde acepta el contenido y es ahora capaz de solicitarlo y recibirlo. Solo cuando se haya confirmado la sincronización completa, esta meta será marcada como completa.

Modificar el Explorador de Bitcoin Verde

El nodo y el explorador de Bitcoin Verde actualmente no soportan Memo. Tanto los usuarios finales como los desarrolladores dependen de los exploradores de bloque para validar sus acciones en blockchain.

El soporte que nuestro explorador ofrece actualmente se considera como mínimo, lo que disuade a los usuarios de utilizarlo en todo su potencial. Soportar las acciones de SLP y Memo proporcionará redundancia viable para otros exploradores de bloque, e incrementará la selección de plataforma por usuarios corriendo su propio explorador de bloques.

Estas características adicionales permitirán a otros desarrolladores revisar fácilmente lo que Bitcoin Verde considera com válido. Esto es especialmente valioso para aplicaciones del tipo OP_RETURN, ya que su estado no es inherentemente validado por los mineros.

Como resultado, esta modificación permitirá:

• Atraer usuarios del protocolo Memo al explorador de Bitcoin Verde.
• Permitir que otros desarrolladores validen facilmente sus transacciones basadas en OP_RETURN para certificar implementaciones y consenso.
• Mantener el soporte para el formato de dirección legacy al tiempo que se agrega soporte para CashAddr.

La Solución

Adicionar soporte a Memo

• Bitcoin Verde será extendido para procesar las transacciones del protocolo Memo.
• Las transacciones Memo serán indexadas por el nodo.
• Se implementará una rutina para back-port de los index de los nodos actualmente sincronizados.
• Las llamadas RPC serán actualizadas para incluir datos Memo, similar a la funcionalidad proporcionada para SLP.
• La API del explorador será actualizado para incluir datos Memo de transacción.
• El explorador mostrará datos Memo tabulados, similares a bitcoin.com.

Metas y Entregables Estimados

Hemos estimado que estas modificaciones tomarán aproximadamente 56 horas de tiempo de desarrollo para completarla. Esta modificación puede ser dividida en 2 metas principales, cada una con diferentes grados de complejidad. Proponemos asignar fondos de forma proporcional a la complejidad y al tiempo estimado para el desarrollo necesario, con los fondos recibidos al finalizar cada meta.

1. Soporte de Bitcoin Verde (Nodo) a Memo 40/56 horas (71.5%)

   La primera meta consistirá en todos los cambios sobre el nodo que son necesarios para admitir el protocolo Memo, incluidas las llamadas RPC. Esta meta excluye todo el soporte a Memo desde el explorador.

2. Soporte del explorador Bitcoin Verde (Node) a Memo 16/56 horas (28.5%)

   La segunda meta consistirá en todos los cambios requeridos en el explorador para soportar el protocolo Memo.

Financiamiento Solicitado

En total, según nuestras estimaciones, el próximo ciclo de desarrollo de Bitcoin Verde requerirá aproximadamente 456 horas considerando 3 de nuestros ingenieros y 1 escritor técnico. A una tasa de 0.6 BCH/h, el financiamiento total solicitado para esta propuesta sería de 273.6 BCH. Sin embargo, antes de la creación de esta campaña de financiación, Josh Green había escrito propuestas de financiación para cada función, registradas como issues individuales en GitHub.

Habiendo ya recaudado fondos (24.838 BCH) con la intención de apoyar este ciclo de desarrollo, sería irresponsable no deducir esas contribuciones ya realizadas de sus respectivos entregables. Luego de ajustar las contribuciones ya recibidas, el total de fondos restantes solicitados para este ciclo es de 241.162 BCH o aproximadamente $ 62000, en donde los fondos son divididos en 4 entregables que completan las 11 metas propuestas.

Agradecimento

La realización de este proyecto no es un esfuerzo pequeño. Es debido a la continua generosidad y al apoyo de nuestra comunidad que podemos continuar nuestras operaciones hoy en día. Apreciamos cada oportunidad que la red y todos los contribuyentes nos han brindado. Esperamos continuar nuestra participación en la comunidad BCH y ayudar en la maduración de nuestra red.