El segundo día de Scaling Bitcoin tuvo lugar el 7 de diciembre en Hong Kong, en el que se continuaron las discusiones comenzadas el día anterior que mostraron diversas opiniones encontradas con respecto al tema de la escalabilidad, pero unidas por un fin en común: la búsqueda del consenso.
Este día vino renovado con la presentación y profundización de distintas alternativas a largo plazo a la escalabilidad. Se aclaró al público el funcionamiento de las capas de la Lightning Network, así como también, Pieter Wuille deslumbró al público con su solución a la escalabilidad: Segregated Witness.
Uno de los aspectos más importantes que destaca en Segregated Witness (SegWit), es que esta propuesta no implica la realización de una bifurcación fuerte, uno de los mayores inconvenientes que presentan algunas de las propuestas de mayor respaldo como la BIP 101. Una bifurcación fuerte necesitaría que todos los miembros de la comunidad actualicen su software al mismo tiempo, con la posibilidad de crearse dos versiones de la blockchain.
No obstante, el entusiasmo que Wuille creó entre los asistentes con esta nueva alternativa, fue un tanto disminuido tras la intervención del fundador de Bloq, Jeff Garzik. Garzik, al contrario de Wuille, insta a la comunidad bitcoin a dejar el miedo que se tiene sobre la bifurcación y a adoptar una solución que requiera una bifurcación fuerte:
Una bifurcación fuerte dará la señal de que nuestra voluntad es crecer, de que queremos cambiar, que queremos cambiar el sistema. No aumentarlo sería visto como que queremos aumentar las tasas, que queremos empujar a la gente fuera del sistema.
Jeff Garzik
El interés de Garzik de tomar una alternativa de bifurcación fuerte no se basa simplemente en la respuesta que esto pueda provocar en la opinión pública, sino que respaldó su ponencia en un basamento académico sólido en el que señalaba que, con el solo aumento del tamaño de los bloques, la masificación de bitcoin seguiría encontrando obstáculos en el futuro, viéndose en la necesidad de buscar nuevas soluciones a la escalabilidad indefinidamente.
Entre discusiones de nuevas alternativas y debates entre minero y desarrolladores, transcurrió el segundo día del evento, lo que se podrá observar en los párrafos subsiguientes.
Segregated Witness
Esta nueva alternativa propuesta por Pieter Wuille, co-fundador de Blockstream, busca cambiar la manera en que las firmas de transacciones son manejadas. Comenzó explicando que las transacciones bitcoin no son más que una suma de entradas y salidas, en la que la entrada contiene una firma para identificar al propietario. En la solución de Wuille, se separaría el testigo (witness) o firma, de la propia transacción, haciendo opcional dicho binomio:
Hoy, éstas son inherentes a la transacción, no puedes removerlas. Con Segregated Witness esto será posible cuando cedas ante las carteras ligeras o dejes ir la blockchain cada año. Recordaremos las transacciones, pero no quien las autorizó.
Jeff Garzik
La propuesta de Wuille es aumentar el tamaño de los bloques con una bifuración suave. Observa que el problema actual se encuentra en el proceso de validación y almacenamiento de data. De llegarse a cambiar la manera en que el sistema maneja la data, el tamaño de los bloques de las transacciones actuales aumentaría a 1.75 mb, y a 4 mb si la mayoría de estas transacciones son multifirma.
Lightning Network
La red relámpago, de la cual ya hemos hablado en CriptoNoticias, fue discutida a profundidad, explicando cómo funciona una solución a la escalabilidad que no implica aumentar el tamaño de los bloques de la blockchain.
Uno de sus desarrolladores, Tadge Dryja, se enfocó en explicar cómo Lightning Network puede ser implementado en la blockchain en tres escenarios distintos, haciendo notar los elementos que estarían disponibles bajo cada uno. Comentó sobre las posibilidades de la red:
Con un tamaño justo y razonable de bloques, puedes obtener miles de millones de usuarios. ¿Cuántas transacciones podrán hacer esos usuarios? Muchísimas. Una vez que tengas el canal abierto, puedes hacer miles de transacciones al día y hora. Eso es alentador.
Jeff Garzik
Por su parte, el socio de Dryja, Joseph Poon, quiso hacer énfasis en el valor que subyace a la red y lo que se cede del diseño al escalar:
No se trata de cómo alcanzar el estado óptimo, sino de cómo se verá si tiene este diseño. Puede ser altamente descentralizado si inclinas el sistema hacia la descentralización.
Jeff Garzik
Múltiples BIPs
Jeff Garzik fue el encargado de hacer una revisión, desde una perspectiva académica de las distintas BIPs o propuestas que existen hoy en día en el ecosistema bitcoin para el aumento del tamaño de los bloques:
(…) podrían los bloques ser tan pequeños como para que los usuarios sean forzados fuera de la blockchain y dentro de los “jardínes de las carteras” de los proveedores de servicios de bitcoin, mientras que los bloques que fueran demasiado grandes prohibirían la descentralización de los nodos de la red. Al final, acabarías con la seguridad y privacidad del sistema.
Jeff Garzik
Garzik disertó en torno a los pros y contras de BIP 100, BIP 101, BIP 103, BIP 105, BIP 106, BIP 248 y BIP 102, la cual, a su parecer, es la mejor opción a tomar en el presente, aumentando el tamaño de los bloques a 2 mb.
Sin embargo, hizo notar que el aumento del tamaño de los bloques no es una solución infalible a la escalabilidad. Habló en contra de lo que caracteriza como los inconvenientes de mantener el tamaño actual de los bloques, cómo el riesgo de que el volumen de las transacciones supere la capacidad de los bloques puede hacer que los usuarios tengan que pagar mayores tasas para que sus transacciones sean incluidas en algún bloque.
Reunión de mineros y desarrolladores
Una de las secciones más políticas, por llamarla de alguna manera, del segundo día de conferencia, fue la mesa redonda que sostuvieron los desarrolladores y mineros, a puerta cerrada y bajo las reglas de Chatman House. Esto con el fin de cerrar las discusiones que tuvieron entre ellos el primer día de la conferencia.
La reunión duró dos horas. A pesar de los problemas de traducción, ambas partes se esforzaron en hacer entender su perspectiva de los asuntos sobre la red bitcoin. Los desarrolladores buscaron determinar la métrica subyacente que afecta los resultados finales de los mineros. Esto con el fin de evaluar como las distintas soluciones podrían afectar la remuneración de los mineros y su capacidad de asegurar la red bitcoin y continuar procesando transacciones.
La discusión también se tensó cuando los desarrolladores demostraron su deseo de diseñar reglas en la red que podrían permitir que esta escale a un uso global, mientras que los mineros apuestan por simplemente aceptar las imperfecciones del sistema sin establecer regulaciones. Los mineros establecen que los desarrolladores no deben temer ningún ataque por parte de los mineros porque sería como atacarse a sí mismos.
A pesar de la polémica existente en ambos sectores del ecosistema, los dos grupos demostraron su rechazo a ser vistos como los responsables primarios de las decisiones que finalmente se tomen para solucionar la escalabilidad:
Nosotros como desarrolladores no queremos que nos vean como si tuviéramos el control sobre bitcoin.
Jeff Garzik
Finalmente, el grupo decidió la métrica en base a la cual cada propuesta debe ser juzgada, incluyendo la latencia entre los nodos establecidos en Chinas y los nodos globales, y la equiparación del terreno entre los grandes mineros y los pequeños mineros. Los objetivos sentados fueron poco concretos, tales como mantener a los desarrolladores comprometidos con la comunidad China en los foros de WeChat.
Scaling Bitcoin sirvió para ratificar las dificultades que se presentan a la hora de establecer un consenso en una comunidad de tanta amplitud y diferencias. Si bien los acuerdos concretados quizás no hayan sido los esperados por una parte optimista de los miembros de la comunidad, si sirvió para poner de relieve nuevas soluciones a la escalabilidad, como Segregated Witness, que brindan nuevas alternativas a tan complejo asunto.
Imagen destacada por skeeze / CC BY 4.0
Ingresar
