jakiro
Autor: Chakra;
Bitcoin es la cadena de bloques de valor de mercado más temprana, segura, más descentralizada y más alta del mundo.Sin embargo, su bajo volumen de transacción por segundo (TPS) y capacidades de programación limitadas a menudo son criticadas por su dificultad para apoyar aplicaciones a gran escala, obstaculizando seriamente el desarrollo del ecosistema de bitcoin.Como constructor del ecosistema de bitcoin, este artículo lo guiará a través del pasado, el presente y el futuro de las soluciones de expansión de Bitcoin.
Este artículo es el primer artículo de una serie de artículos de escalabilidad de Bitcoin, principalmente que introduce las soluciones de expansión nativa implementadas en la historia de la red principal de Bitcoin.El próximo artículo discutirá soluciones de expansión fuera de cadena con mayor escalabilidad.Manténganse al tanto.
Aumentar el límite del tamaño del bloque
En 2010, Satoshi Nakamoto introdujo un límite de tamaño de bloque de 1 MB en el núcleo bitcoin.Esta clara restricción no se ha revisado durante más de diez años desde entonces.
Curiosamente, Satoshi Nakamoto no explicó públicamente por qué propuso el límite del tamaño del bloque, que está «oculto» en el PR de la fusión del código y no tiene una explicación detallada.Unos años después de que Satoshi Nakamoto se fue, la comunidad tuvo un desacuerdo grave sobre las restricciones de tamaño de bloque, y la demanda de bloques más grandes provocó una discusión generalizada.
Cuanto más grande sea el bloque, más transacciones se adapta.Suponiendo que el tiempo de consenso permanece sin cambios, cuanto más grande sea el bloque, mayor será el TPS.
¿Por qué es tan importante TPS?Porque bajo el límite de bloque de 1 MB, con la escala de transacción en ese momento, el número de transacciones que se pueden completar por segundo solo puede ser de 3-7 transacciones, lo que está lejos de ser suficiente para aplicaciones a gran escala, y es imposible realizar La visión «Sistema de efectivo electrónico de punto a punto de Bitcoin».
Sin embargo, los bloques más grandes también traen problemas a diversos grados.
Primero, los bloques más grandes tienen requisitos más altos para el hardware, como el almacenamiento, la computación y el ancho de banda, lo que resulta en un mayor costo operativo para todo el nodo.Los datos de transacciones históricas de Bitcoin se están expandiendo rápidamente, lo que requiere nuevos nodos completos para pasar más tiempo sincronizando con la red.Estos requisitos reducen la disposición de los usuarios para operar nodos completos, reduciendo así el grado de descentralización.
En segundo lugar, cuanto más grande sea el bloque, mayor es el tiempo de sincronización entre los nodos, mayor será la posibilidad de que aparezcan bloques huérfanos, lo que resulta en una reorganización de bloque más frecuente, aumentando el riesgo de bifurcar, reduciendo en gran medida la seguridad.
Más tarde, este problema fue llamado triángulo imposible de blockchain por Vitalik, es decir, blockchain no puede lograr la descentralización, la escalabilidad y la seguridad al mismo tiempo.Cuanto más grande sea el bloque, más fuerte es la escalabilidad, pero el costo es más débil que la descentralización y la seguridad.
Lo más importante es que modificar el límite del tamaño del bloque requiere una bifurcación dura, lo que requiere que todos los nodos en toda la red se actualicen al mismo tiempo, de lo contrario conducirá a la división de la red.Esta no es una buena opción para Bitcoin que se basa en un consenso descentralizado.Bajo la influencia de Satoshi Nakamoto, evitar horquillas duras parece haberse convertido en el principio de facto de Bitcoin.
Desafortunadamente, la división ocurrió.A pesar de la falta de consenso dentro de la comunidad, algunos mineros y desarrolladores han cambiado el límite del tamaño del bloque en el cliente, lo que finalmente conduce a una bifurcación de red.En 2016, Bitcoin Classic usó BIP 109 para desembolsar el límite del tamaño del bloque a 2 MB;Sin embargo, la gran mayoría de los mineros y usuarios permanecen en el bitcoin Mainnet tal como lo conocemos ahora.
El esfuerzo por aumentar explícitamente el tamaño del bloque por Hard Fork falló.
Testigo de cuarentena
Si las horquillas duras son inaceptables, ¿se pueden usar horquillas blandas como solución?Segwit es uno de los métodos.
El testigo es el cupón para desbloquear Utxo, y durante mucho tiempo, el testigo ha sido colocado en el campo de script de entrada de UTXO para completar la transacción.Sin embargo, este método tiene problemas potenciales, como dependencia circular, ductilidad de transacciones de terceros y ductilidad de transacción de dos partes.
Ya en 2011, los desarrolladores notaron este problema y propusieron una solución a Segwit, que está a punto de separar el testigo de otros datos de transacciones.Sin embargo, la propuesta de Hard Fork en ese momento no fue compatible, y no fue hasta la propuesta de Segwit Soft Fork en 2015 que la fusión finalmente se logró.
¿Cómo logra SEGWIT la compatibilidad hacia atrás a través de horquillas suaves?Esto incluye principalmente los siguientes dos aspectos:
-
Los nodos de nueva versión pueden reconocer y aceptar bloques y transacciones generadas por nodos de versión antiguos.
-
Aunque los nodos de versión antiguos no pueden reconocer nuevas reglas y características introducidas por nuevas versiones, todavía tratan los bloques generados por nuevas versiones como válidas.
Segwit Soft Fork permite nuevas transacciones para usar scripts de entrada vacíos y agregar campos de testigos en la estructura de bloques para almacenar testigos.Dado que el núcleo de bitcoin antes de la actualización admite scripts de entrada vacíos, el nodo de versión anterior no rechazará los bloques generados por la nueva versión.Además, al usar el campo de la versión, los tipos de transacciones antiguos todavía están disponibles y los nodos los procesan de diferentes maneras dependiendo de la versión.
La extensión en Segwit se implementa en forma de pesos, con los pesos de bytes de testigos de 1 y los otros bytes de datos son 4, lo que limita el peso máximo de cada bloque a 4 millones.¿Por qué desea asignar diferentes pesos a diferentes tipos de datos?Una idea de sentido común es que los datos de los testigos solo sirven como una función de verificación cuando se usan y no necesita almacenarse en almacenamiento durante mucho tiempo, por lo que tiene un costo relativamente bajo y tiene bajo peso.
Esto en realidad aumenta el límite del tamaño del bloque disfrazado.A juzgar por la antigua estructura de bloque, esto todavía se adhiere al límite original del bloque de Satoshi Nakamoto de no más de 1 MB por bloque.
Raíz principal
Utilizando los códigos de operación de Bitcoin, como OP_IF, podemos establecer condiciones complejas para scripts de gasto de Bitcoin, como bloqueos de tiempo, firmas múltiples, etc.Sin embargo, las condiciones de gasto complejas a menudo requieren múltiples entradas y firmas para la verificación, aumentando así la carga de bloques y reduciendo las velocidades de transacción al tiempo que expone todas las condiciones de pago, lo que resulta en fugas de privacidad.
Taproot usa Mast para mejorar Bitcoin, y los usuarios usan Merkle Trie para indicar condiciones de gasto.Cada nodo de hoja representa un script de gasto.Esto reduce el consumo de espacio en bloque y aumenta la privacidad.
La actualización de Taproot también presenta una firma Schnorr que tiene propiedades homomórficas aditivas que permiten la agregación de firma y la validación por lotes, aumentando así las transacciones generales por segundo (TPS).La ventaja de la firma de agregación de las firmas de Schnorr simplifica enormemente la lógica de validar las transacciones de firma múltiple.Anteriormente, las firmas de ECDSA requerían enviar múltiples firmas a la cadena para que coincidan con el script, mientras que las firmas de Schnorr solo requerían enviar una sola firma agregada fuera de cadena a la cadena, reduciendo el uso de espacio en la cadena por pagos de firma múltiple.
Los códigos de contrato complejos se presentan a través de la raíz del mástil combinando firmas de Schnorr con Mast y utilizando el concepto Pay to Contract (P2C) para ajustar y generar una clave pública estándar de bitcoin que admite pagos con una sola firma de Schnorr.
Curiosamente, debido a que la firma única y las firmas múltiples de las firmas de Schnorr se ven lo mismo en la cadena, la lógica de scripts complejos, múltiples firmas y firmas individuales es indistinguible en la cadena, mejorando aún más la privacidad.
en conclusión
Las soluciones de escalabilidad de Bitcoin reflejan su enfoque en evolución para mejorar el rendimiento mientras se mantiene la descentralización y la seguridad.
Inicialmente, considerando aumentar el tamaño del bloque que aborda directamente el problema de las bajas tasas de transacción, pero planteando problemas relacionados con los costos de nodo y las horquillas de red, lo que plantea desafíos para el consenso de la comunidad.
La introducción de SEGWIT marca un avance significativo al optimizar la capacidad de bloque a través de horquillas suaves, garantizar la compatibilidad hacia atrás y evitar las horquillas duras divididas.
Taproot mejoró aún más la escalabilidad y la privacidad a través de firmas de Mast y Schnorr, reduciendo el espacio de transacciones y mejorando la eficiencia de verificación.Más importante aún, Taproot puede implementar secuencias de comandos complejos en Bitcoin, allanando el camino para futuros intentos de expansión.
Estos desarrollos destacan el movimiento cauteloso e innovador de Bitcoin hacia una red más escalable y poderosa, que es crucial para su futuro como sistema de pago global.
Sin embargo, el impacto de estas soluciones de expansión no es suficiente para realizar la visión de un «sistema de efectivo electrónico punto a punto».
