¿Por qué no se puede probar la actualización del tamaño del bloque en testnet con una "prueba de estrés" organizada?

Se realizó una prueba de estrés en la red principal para ver el efecto de la demanda exponencial en el volumen de Tx.

¿Por qué no se puede organizar una "prueba de estrés" de testnet para observar las implicaciones del tamaño del bloque de 20 Mb (y otras variables?)

No puedo entender cómo hay tanta especulación cuando un entorno de prueba resolvería parte de esto proporcionando métricas reales.

Respuestas (2)

Hay una serie de alternativas más complejas en discusión que involucran límites más elásticos (en lugar del límite estricto que existe actualmente), límites ajustados automáticamente en función de alguna métrica en la cadena de bloques, o alguna combinación de ambos.

Las alternativas más complejas significan un código más complejo y más posibilidades de errores. Ciertamente podrían y deberían probarse en testnet.

Con la opción "simplemente aumente el límite estricto" (e incluso con algunas de las otras alternativas), la mayoría de las métricas que puede obtener de una prueba de testnet no son muy interesantes y ya son fáciles de calcular. Por ejemplo, es fácil comprender cuáles son los requisitos de ancho de banda, CPU y espacio en disco en el peor de los casos, y no es demasiado difícil simular (sin testnet) cómo el tiempo de propagación de bloque agregado afectará (o no) la eficiencia del minero .

Son los efectos externos los que están causando la mayor parte de la controversia, por ejemplo:

  • ¿Los requisitos adicionales alejarán a más personas de ejecutar nodos completos, aumentando la centralización?
  • ¿ Continuarán en el futuro la Ley de Moore, la Ley de Nielsen y la Tasa de Kryder actual , y ayudarán a mejorar la descentralización a pesar de los bloques más grandes?
  • ¿Un enfoque de "no hacer nada hasta que sea una emergencia" alejará a las personas de Bitcoin cuando los tiempos de confirmación de tx comiencen a aumentar significativamente (y los nodos de Bitcoin Core comiencen a fallar )? ¿O la escasez de espacio de tx simplemente hará que las tarifas de tx aumenten gradualmente (lo que también alejará a los usuarios si aumentan demasiado, aumentando la centralización)?
  • ¿Qué efecto tendrá el límite de tamaño de bloque en el futuro (por ejemplo, en las tarifas de tx) a medida que disminuya el subsidio por bloque?

No estoy tratando de enumerar todas las preguntas/problemas controvertidos (dudo que los sepa), solo para demostrar que hay muchas más que testnet no puede responder que sí.

Fantástica respuesta, compañero. Me inclinaría por un tamaño de bloque específico, ¿usted mismo?
@WizardOfOzzie ¿Cuál es el mejor? Estoy cansado de cualquier solución que intente establecer un límite superior basado en algo almacenado en la cadena de bloques: la cadena de bloques no conoce la Ley de Moore, etc., y al igual que los sistemas PoS, los participantes (mineros) pueden jugar con ella. Creo que me gusta la idea de los límites elásticos (donde los mineros pueden pagar una "penalización" para aumentar los límites más allá de un límite suave hasta un límite máximo duro). A pesar de la complejidad adicional del código, creo que esto podría ser más seguro contra los "bloqueos". Habiendo dicho todo eso... Realmente no lo sé. Es muy complejo, y dudo que haya una respuesta 100% correcta.

Creo que el problema no está solo en el código del programa. Hay un problema ético: Hasta dónde puede llegar el líder de la comunidad queriendo cambiar algo.

¿No es lo mismo que en el mundo fiduciario "fuera de línea"?

I think that the problem is not only in program code. There is an ethical problem: How far can the leader of the community go wanting to change something?Un líder está destinado a liderar la OMI, pero entiendo que hay discordia en la comunidad. ¡Quería aclarar que no era más un problema tecnológico, ya que los problemas tecnológicos son fáciles de resolver en comparación con los sociales!
¿Qué problema? No es posible arreglar perpetuum mobile porque no puede existir. es falso