Bitcoin Forum
November 07, 2024, 04:26:04 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Problema de escalabilidad  (Read 1151 times)
alexr_96 (OP)
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500

0x9CE937CD


View Profile WWW
January 06, 2015, 08:00:07 PM
 #1

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.
javijavier
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
January 08, 2015, 12:17:01 AM
Last edit: January 08, 2015, 06:45:27 PM by javijavier
 #2

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!
alexr_96 (OP)
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500

0x9CE937CD


View Profile WWW
January 08, 2015, 12:33:36 AM
 #3

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  Shocked
Antuam
Legendary
*
Offline Offline

Activity: 1722
Merit: 1005



View Profile
January 08, 2015, 01:02:09 AM
 #4

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

XG
Sr. Member
****
Offline Offline

Activity: 286
Merit: 250



View Profile
January 08, 2015, 06:49:11 AM
 #5

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

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.
Antuam
Legendary
*
Offline Offline

Activity: 1722
Merit: 1005



View Profile
January 08, 2015, 07:12:20 AM
 #6

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

dserrano5
Legendary
*
Offline Offline

Activity: 1974
Merit: 1029



View Profile
January 08, 2015, 08:25:36 AM
 #7

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.

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.


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. Pero surgen dos problemas:
Las transacciones con "locktime" […] y las "coinbase" […]

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


Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe.

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!


Madre mía, bloques de 200 mb conllevarían 28 gb diarios nuevos en el disco duro.

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 Roll Eyes.


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.

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.


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.

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.


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.

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.


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.

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.
Antuam
Legendary
*
Offline Offline

Activity: 1722
Merit: 1005



View Profile
January 08, 2015, 08:47:43 AM
 #8

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.



javijavier
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
January 08, 2015, 07:01:39 PM
 #9

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.

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.

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

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. Pero surgen dos problemas:
Las transacciones con "locktime" […] y las "coinbase" […]

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

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

Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe.

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!

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

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.

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.

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

Quote
I'll be proposing what we did for the block.version=1 to block.version=2 soft fork: miners signal that they approve of the new rules by producing less-than-1-MB-blocks with version=3 (the version number is part of the block header of every block).

When 50% of blocks are version=3, old version of the reference implementation start complaining: "Warning: This version is obsolete, upgrade required!"

Whenever... uhh... 80% of blocks produced are version=3, the fork happens: version=2 blocks are rejected, and miners are free to build bigger-than-1-MB version=3 blocks.

The hard fork would happen sometime after that, when a miner actually DOES produce a bigger-than-1-MB block (that is assuming that we don't decide to make some other incompatible hard-forking change that is also tied to block.version=3 blocks becoming a supermajority).



Saludos!
JhonDoe
Sr. Member
****
Offline Offline

Activity: 323
Merit: 250



View Profile
January 12, 2015, 09:45:08 AM
 #10

Gracias javijavier por tu esfuerzo para todos.
Srbotones
Sr. Member
****
Offline Offline

Activity: 391
Merit: 250


View Profile
January 12, 2015, 12:07:32 PM
 #11

Interesante. Gracias por traducirlo

¿Alguna respuesta de la comunidad/mineros al respecto?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!