Topic: Problema de escalabilidad (Read 1152 times)

Interesante. Gracias por traducirlo

¿Alguna respuesta de la comunidad/mineros al respecto?

Gracias javijavier por tu esfuerzo para todos.

Sí, es cierto, lo edito para que no haya malos entendidos.


También edito y corrijo tiempos verbales para solventar el fallo 


Corregida también esa mala interpretación, gracias dserrano.
Pido perdón por los desaciertos en la redacción. Creo que quedó arreglado.


Sí, esto lo comenta Gavin en una de las respuestas de su post:




Saludos!

Correcto Dserrano5 a lo que me has contestado, hoy no estoy nada bien de salud, pero tu has completado y terminado de aclarar a lo que me refería en mis pobres líneas.

Me vuelvo a la cama que estoy pachucho y con fiebre.
Antuam.

El post no dice nada de OP_RETURN. Lo digo por aclarar, ya que tu redacción puede dar lugar a que alguno piense que así es, pero no.



Estos problemas se los encontró él durante sus pruebas. No van a darse en el momento de actualizar.



Esa nueva cadena la creó él durante sus pruebas. De hecho en la primera línea del post dice "he estado ocupado llenando mi disco duro con copias de la cadena de bloques". Nosotros seguiremos usando la misma de siempre!



Lo que se va a cambiar es el LÍMITE del tamaño de los bloques. No significa que a partir del día X todos los bloques vayan a ser de 200 Mb. De hecho, hoy día casi ningún bloque es de 1 Mb .



Pronto tendremos autoprune y podremos limitar la cantidad de tamaño que le dedicamos a la cadena de bloques. Los nodos que tiren de este mecanismo ya no podrán ser considerados "full", claro, porque ya no tendrán la cadena de bloques entera, pero serán útiles de todos modos porque validarán todas las transacciones y bloques y seguirán ofreciendo bloques a los nodos nuevos que se unan a la red.



Lo dicho, con autoprune le dices al sistema que no use más de 63 Gb y problema solucionado. Pendrive military grade forever. Forever del bueno, que los bloques solo se escriben una vez y a partir de ahí ya solo sirven para leer, no se reescriben ni nada.



No estoy seguro de a qué te refieres con esto. No hay que recrear ninguna cadena de bloques, simplemente a partir del bloque X podría empezar a haber alguno que superara el Mb de tamaño, porque a partir de dicho bloque X el límite ya sería otro. Pero todos los bloques desde el génesis hasta el X seguirán inalterados.



Sin saber tampoco a qué te refieres (¿"protocolo"?), quiero decir que el fork será un proceso de varias semanas o meses, durante l@s cuales la gente se actualiza a una versión nueva que soporte los bloques más grandes y solo cuando determinado porcentaje de la red se haya actualizado, estos bloques podrían realmente empezar a aparecer. Ya hemos pasado por una transición así y no hubo ningún problema.

Edito para añadir: el fork real solo sucederá cuando aparezca el primer bloque de más de 1 Mb de tamaño, y solo sucederá para aquellos usuarios que no se hayan actualizado, que serán minoría. Rechazarán el bloque y probablemente se quedarán atascados en ese punto, puesto que el resto de la red seguirá construyendo la cadena teniendo en cuenta este bloque grande, y todos esos nuevos bloques también serán rechazados por la minoría porque no les encajan en la cadena que tienen. En este punto, se verán forzados a actualizar.

Si, estoy de acuerdo, pero el Pendrive que uso es de los que llaman grado militar, con cifrado, y resistente a golpes y agua, y digamos que no son nada baratos como para estar cambiándolo, además, también se tiene que contar con la velocidad de lectura y escritura, por que los hay de 64Gb que aunque anuncien  USB 3.0 , son lentorros.

Y volviendo al post, es necesario poder recrear la cadena de bloques para soportar los tamaños que se nos avecinan, pero tendría que hacerse de a poco dicho cambio.
Me explico, digamos que un nuevo cliente que se saque, soporte ya dicho protocolo, pero que aún continue soportando el antiguo/actual un par de versiones mas/meses, para dar tiempo a que se actualize el máximo número de usuarios y nodos y que a una fecha, ya no se sincronize y te oblige a actualizarlo sacando un mensaje. Me suena haber visto esto en algún Wallet de alguna altcoin, y es el propio Wallet el que te indicaba que actualiza y quieres seguir usándolo.


Saludos.
Antuam

A mi me parece que al ritmo que crece la capacidad de los pendrives supera de lejos la velocidad con la que crece la cadena de bloques.

Sólo es cuestión de cambiar a un pendrive con mayor capacidad y tienes para unos cuantos años todavía. Así hasta el infinito.

Saludos.

La cadena de bloques actual ya está en 31,1Gb y creciendo.
Yo he tenido que migrar la maquina virtual que hace de nodo a un Pendrive de 64Gb, pero a este paso, me despediré de ella y seremos muchos los que nos tocara migrar a monederos online o a otro monedero que no necesite tener descargada la cadena de bloques.

Saludos.
Antuam

Madre mía, bloques de 200 mb conllevarían 28 gb diarios nuevos en el disco duro. Costaría 30€ al mes mantener un nodo en casa, solo en discos duros externos  

Hola Alexr.

Mis niveles de conocimiento son medios en ambos casos (quizás algo mejor en inglés que en bitcoin, pero medios definitivamente) de todas maneras lo que viene contando Gavin es algo que él ya había comentado varias veces y trata de la escalabilidad y por ende de la necesidad de bloques más grandes que la soporten.
Actualmente, en la cadena de bloques, estos tienen un tamaño de 1MB y en el post dice haber estado probando ditintas cadenas de bloques con un tamaño de 20MB cada uno (e incluso 200MB!), lo cual nos permitiría incluír muchísimas más transacciones por bloque y quizás pueda ayudar para volver a aumentar el valor de OP_RETURN el cual había sido reducido de 80 bytes a 40 anteriormente (esto es último es una suposicion mia). Esto puede ser bastante importante si hablamos de una cadena de bloques que puede llegar a ser el futuro de internet. Cada transacción podria albergar más información.
Este cambio necesitaría un Hard Fork, el cambio en el código nos obligaría a todos a actualizar nuestro actual sofware (cartera) por una versión nueva configurada para funcionar con estos nuevos bloques más grandes. Según comenta en el post este cambio sería MUY facil, tan solo cambiar tres lineas de código. En su prueba le surgieron dos problemas (ambos solucionados):
Las transacciones con "locktime" (que tienen un tiempo de espera) y las "coinbase" (es la primer transacción del bloque, las monedas creadas mas las comisiones de todas las transacciones que se van a estampar en él).
El primer problema lo solucionó poniendo todas las transacciones como final.
Para el segundo fue mas complicado, pero también tuvo arreglo. Creó una herramienta: gen_megablocks en el que se indexan todas las "coinbase" en un único fichero .dat y crea los blk*.dat que se usarán para indexar la cadena de bloques. Ha probado leer esos ficheros con el bitcoind y la opción -loadblock en la linea de comandos y funcionó perfectamente tanto con los bloques de 20MB con como los de 200. Bitcoind creó una cadena de bloques completa e indexada con todas las transacciones reales de la historia de bitcoin. Pudo también crear transacciones las cuales son posibles realizarlas en la cadena de 20MB como en la original de 1MB, ya que dice que las transacciones ordinarias son independientes del bloque. Las "coinbase" tambien tuvieron otro cambio para poder ser gastadas en el mismo bloque.
Luego nos cuenta detalles de procesamiento en tiempo con su ordenador para indexar la nueva cadena de bloques y que seguirá haciendo pruebas, luego tendremos un futuro post con los resultados.
Más o menos es eso. Con algunos detalles técnicos que se me escaparon, pero en sintesis eso.
Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe. Como bien dice dserrano, continuaremos usando la misma cadena de bloques, ya que solo cambia los valores MAX_SIZE.

Gavin quiere bloques más grandes para así estar prepadados para la escalabilidad posible si en un futuro Bitcoin llega a ser lo que nosotros bitcoiners creemos que será. Evidentemente en ese caso y ante la necesidad de realizar un Hard Fork, éste siempre es más "facil" de realizar mientras menos usuarios seamos, ya que somos menos a los que avisar de la necesidad de actualización obligatoria. Personalmente me parece lo mas sensato.

Como siempre creo que acabo liándome la manta a la cabeza y no se entiende nada de lo que escribo. Espero se haya entendido. Si tuve algún fallo de traducción, compresión o conocimiento espero me corrijan.

Saludos!

Bueno, pues Gavin Andersen, según su último tweet parece que ha estado trabajando en este problema:

https://twitter.com/gavinandresen/status/552540066959331330

Alguien con muy buen nivel de ingles y grandes conocimientos de bitcoin podría explicarnos este articulo.