¿Por qué cada nodo no almacena solo una parte de la cadena de bloques?
Por ejemplo, si tuviera 100 nodos, cada nodo almacenaría el 10 % de la cadena de bloques. Esto equivaldría a una superposición significativa de cada aspecto de la cadena de bloques, y a medida que los nodos entraran y salieran, aumentaría o disminuiría el uso compartido de la cadena de bloques.
¿Es inviable? Si es así, ¿por qué? Estoy interesado en continuar con este proyecto porque creo que podría resolver muchos de los problemas de escalabilidad/descentralización de bitcoin.
Desde mi comprensión de la cadena de bloques, supongamos que un nodo en particular comienza en el bloque de génesis. Supongamos que otro nodo almacena el 1 % de la cadena de bloques más allá del bloque de génesis. ¿No podrían varios nodos verificar hashes de bloque para su 9% compartido a una tasa de una vez cada 10 minutos? En realidad, no usaría tantos datos: podría convertir el 9% de la cadena de bloques en un valor particular, producir una clave pública y ver si los otros nodos pueden hacer coincidir una clave privada con dicha clave pública.
Una pregunta relacionada: ¿Es esto lo que hace Electrum? ¿O simplemente almacena Electrum toda la cadena de bloques en varios servidores a los que puede conectarse?
¿Por qué cada nodo no almacena solo una parte de la cadena de bloques?
Esto se ha propuesto antes y es posible con Bitcoin, pero no está claro cómo se ejecutaría. Los bloques no son una parte importante de un nodo en ejecución; para la mayoría de las personas, puede desecharlos tan pronto como los haya procesado en su base de datos UTXO.
El problema surge al decidir qué partes almacenar y señalar a otras personas en la red que tiene un determinado subconjunto de bloques. No puede anunciar una lista de hashes, ya que sería masivo e ineficiente (muchos megabytes para cada par), y hacer una selección aleatoria determinista es extremadamente problemático. Elegir rangos de bloques no es ideal porque los tamaños no son consistentes, 1,000 bloques al comienzo de la cadena son servidores de órdenes de magnitud más pequeños que los de la punta. En una implementación ingenua de selecciones aleatorias, los pares que intentan sincronizar con la red pueden necesitar hacer miles de conexiones para encontrar un solo par que tenga un bloque específico, lo que obviamente no es factible.
Desde mi comprensión de la cadena de bloques, supongamos que un nodo en particular comienza en el bloque de génesis. Supongamos que otro nodo almacena el 1 % de la cadena de bloques más allá del bloque de génesis. ¿No podrían varios nodos verificar hashes de bloque para su 9% compartido a una tasa de una vez cada 10 minutos? En realidad, no usaría tantos datos: podría convertir el 9% de la cadena de bloques en un valor particular, producir una clave pública y ver si los otros nodos pueden hacer coincidir una clave privada con dicha clave pública.
Esto no es necesario y es altamente vulnerable a los ataques de Sybil, no necesita verificar los bloques una vez que los haya visto. Los nodos podados funcionan así hoy en día, solo que tiran todos los bloques y no almacenan absolutamente nada más de lo que se especifica para el dolor. No anuncian qué bloques tienen porque no hay ningún mecanismo para eso.
Es posible que desee leer sobre cómo funciona el parche de autoprune y obtener una mejor comprensión de los modelos de amenazas que deben abordarse aquí. Se ha perdido algo de la operación, tenga en cuenta que la poda de nodos no funciona de la manera descrita en el documento técnico, el UTXO es un concepto nuevo agregado en la era 0.8.0 de Bitcoin Core.
Una pregunta relacionada: ¿Es esto lo que hace Electrum?
En absoluto, los servidores Electrum son un nodo completo y un índice basado en direcciones extremadamente pesado, casi duplicando el tamaño de almacenamiento. El cliente es liviano, pero el servidor definitivamente no lo es. No existe una forma sensata de mantener estos índices fragmentados, aunque podría dividir las direcciones en varios grupos y esperar que las personas mantengan suficiente de cada fragmento para que los clientes puedan solicitar suscripciones para todas sus direcciones. Lo ideal sería diseñar sistemas que no requieran índices completos, ya que cada vez es más difícil trabajar con ellos.
Algo así se implementó y lanzó en v0.11.0 en el cliente Bitcoin Core. Se llama poda y ahora puede usar la opción -prune para especificar la cantidad de datos de la cadena de bloques que desea almacenar.
-prune=N: where N is the number of MB to allot for raw block & undo data
Esto aún no funciona en términos de billetera, por lo que al podar no puede usar la billetera en el cliente principal. También deja de retransmitir, aunque están trabajando en formas de incorporar eso para permitir que los nodos sigan retransmitiendo bloques.
Sin embargo, esto no significa que los nodos almacenen diferentes partes de la cadena de bloques.
Tenga en cuenta que un nuevo nodo en modo de poda aún se descargará y se abrirá camino a través de todos los bloques, pero no conservará todos los bloques antiguos.
Tengo entendido que esto se actualizará para admitir el uso de la billetera en modo de poda en el futuro. EDITAR: Aparentemente, la rama maestra del núcleo de bitcoin ya admite el uso de la billetera en modo de poda.
BT
claris
BT
BT