¿Dónde está el cuello de botella de la escalabilidad de blockchain?

Hay un momento que todavía no entiendo sobre blockchain. Nunca he visto al cliente de ethereum continuamente con una carga de CPU o de red del 100 %. Entonces, ¿por qué no es posible procesar transacciones más rápido? Supongo que el 100 % de la carga de GPU en la máquina de minería no es un cuello de botella, porque el tamaño del bloque es arbitrario. Entonces, ¿dónde está exactamente el cuello de botella?

¡Gracias!

En mi opinión, los canales estatales están muy infrautilizados y gran parte del debate sobre la escala sería discutible si este mecanismo se implementara más ampliamente.

Respuestas (5)

Dos tipos de cuello de botella

Hay dos tipos de límites de velocidad que están en juego aquí. Estos son la latencia y el rendimiento. La latencia es la cantidad de tiempo que se debe esperar hasta que se procese una transacción. El otro es el rendimiento: la cantidad de transacciones que se pueden procesar en un período de tiempo determinado. Imagine la diferencia entre un supermercado con 100 clientes y 10 cajas y una tienda de comestibles con 5 clientes y una caja. Ahora, imagine que cada mostrador de pago puede procesar un usuario por minuto. En el primer caso, la persona promedio espera 5 minutos para que lo revisen. En el segundo, cada persona espera una media de 2,5 minutos. Por otro lado, el supermercado puede manejar 10 veces más clientes por minuto. Por lo tanto, un supermercado concurrido puede tener un mayor rendimiento que una pequeña tienda de comestibles, pero la latencia puede ser mayor. Ahora imagine que ambas tiendas están cerradas durante 20 horas consecutivas al día y recibe 100 clientes al día. Esencialmente, debe esperar, en promedio, 10 horas para comprar sus comestibles (el tiempo de pago es insignificante). Puede ver que los mostradores de pago muestran una baja utilización.

cuello de botella de latencia

En Ethereum, el tiempo mínimo entre bloques es, en promedio, alrededor de 25 segundos en este momento. Por lo tanto, la latencia mínima es un promedio de unos 12,5 segundos (es decir, si su transacción es seleccionada para el siguiente bloque, espera en promedio alrededor de 12,5 segundos para que se incluya). Si solo se enviara una transacción por minuto, esto no tendría ningún efecto sobre la latencia promedio y el rendimiento sería de un bloque por minuto. La utilización de la CPU para el procesamiento de bloques seguiría siendo muy baja. Por razones técnicas, el intervalo entre bloques se estableció anteriormente en un valor más bajo para permitir que la red permanezca sincronizada (es decir, para que los nodos puedan llegar a un consenso). Este número técnicamente podría ser más bajo , y solía serlo. El tiempo de bloque promedio está aumentando debido a la era de hielo/bomba de dificultad de Ethereum, una razón no técnica, que se utiliza para proporcionar fuertes incentivos a los desarrolladores para que se apresuren a introducir la prueba de participación (PoS) para reemplazar la prueba de trabajo y para que los nodos actualicen a sus clientes cuando se introduzca el mecanismo PoS. Dado que gran parte del tiempo se dedica a esperar información, la utilización de la CPU sigue siendo baja.

Cuellos de botella de rendimiento

Mientras tanto, existen limitaciones técnicas con respecto al rendimiento. El primero de estos límites es la practicidad: sería muy difícil para muchos o la mayoría de los operadores de nodos ejecutar un nodo si la capacidad de almacenamiento requerida para almacenar la cadena de bloques creciera 1 TB por semana, ya que supongo que no mucha gente ejecuta (o incluso sabe) cómo ejecutar) sistemas que permiten escalar su almacenamiento a esa velocidad, si es que lo hacen. También hay un aspecto económico en esto: incluso si la gente supiera cómo hacerlo, sería costoso para alguien que solo intentara agregar un nodo para verificar transacciones para mantenerse al día con ese tipo de tasa de crecimiento.

Un segundo límite técnico en el rendimiento es que existen límites en el procesamiento de los nodos y la velocidad de almacenamiento, lo que significa que algunos nodos no podrían verificar los bloques lo suficientemente rápido como para permanecer sincronizados sin algún tipo de límite en el procesamiento/procesamiento involucrado para las transacciones en cada bloque. . Esto da como resultado, por la misma razón, un límite en la cantidad de transacciones que los nodos de minería pueden incluir en un bloque. Sin un límite de procesamiento/almacenamiento por bloque, sería más difícil determinar qué tarifas incluir para una transacción para garantizar el procesamiento oportuno: la cantidad de transacciones incluidas por bloque podría variar drásticamente, según el minero que procese un bloque y la red. a menudo no estaría sincronizado. fragmentaciónes una forma de evitar esta limitación técnica. Tenga en cuenta que mientras espera que un disco devuelva los datos, la CPU está dando vueltas y verá una baja utilización de la CPU. Incluso si los bloques alcanzaran los límites de procesamiento en algunos nodos de minería, los nodos más rápidos tardarían menos en verificar las transacciones de un bloque y no verían una tasa de utilización de la CPU del 100 %.

Un tercer límite surge de los límites técnicos sobre el rendimiento anterior: un límite artificial sobre la cantidad de procesamiento/almacenamiento que pueden utilizar las transacciones en un bloque viene en forma de límite de gas de bloque. Supongo que una de las razones por las que esto está en su lugar es para evitar golpear cualquiera de los dos límites técnicos. Esto hace que sea más fácil y económico ejecutar un nodo. En esa situación, los límites técnicos del rendimiento aumentan proporcionalmente con la cantidad de fragmentos y el límite de gas del bloque también podría aumentar de esa manera. En la práctica, puede que no sea deseable aumentar el límite de gas del bloque de forma directamente proporcional al rendimiento técnico de la red: supongo que es deseable que cualquier nodo pueda verificar que la red Ethereum está funcionando según lo diseñado (es decir, detectar tramposos); como tal, un nodo podría verificar fragmentos aleatoriamente funcionamiento correcto. La posibilidad de detectar tramposos disminuye con la cantidad de fragmentos. Si necesita dedicar un nodo a probar un solo fragmento, para mantenerse al día con las transacciones, entonces puede usar elparadoja de cumpleaños a su favor para mantener un crecimiento sublineal en la cantidad de nodos de verificación (en relación con la cantidad total de fragmentos) para detectar tramposos con una probabilidad razonablemente alta.

Conclusión

Existen cuellos de botella de latencia y rendimiento en Ethereum y se está trabajando en soluciones para solucionar ambos. Los cuellos de botella actuales de Ethereum son artificiales (edad de hielo y límite de gas de bloque), pero son útiles para permitir que existan nodos de Ethereum relativamente económicos y proporcionar un campo de juego más nivelado para los usuarios de la red de Ethereum.

No hay dos tipos de cuellos de botella como "latencia" y "rendimiento". Estos se reducen al cuello de botella del "hardware".

Entonces, de nuevo:

Hay 2 tipos de cuellos de botella.

1.The hardware bottleneck
2.The algorithm bottleneck

El cuello de botella del hardware es básicamente la limitación del hardware en el que está ejecutando su cadena de bloques. Si todos los pares de Ethereum usaran tarjetas Ethernet de 10 Gigabit, procesadores de 16 núcleos, lograrían una tasa de transacción más alta. Teóricamente, Ethereum puede manejar 1000 transacciones por segundo.

Ahora, el cuello de botella del algoritmo. El cuello de botella del algoritmo se explica en lenguaje no técnico en este artículo en mi sitio web: http://www.afterether.org/blockchain-scalability-by-blockchain-clustering.html Pero aquí hay solo un resumen:

  • La red Ethereum es ejecutada por solo 1 computadora a la vez, por lo que puede tener una red de 1 millón de nodos, solo 1 nodo creará el bloque actual en la cadena de bloques. Por lo tanto, básicamente todos los 10 millones de cuentas de Ethereum están utilizando una computadora para todas sus transacciones. Ridículo, lo sé.
  • El algoritmo de la cadena de bloques es serial (a diferencia de los algoritmos paralelos). No se puede paralelizar y, por lo tanto, no se puede escalar. Este es un gran problema de las cadenas de bloques, simplemente no escalan por diseño. No puedes hacer nada al respecto.

Para resolver el problema del cuello de botella, puede ajustar el hardware y el software, o dividir la moneda en muchas cadenas de bloques.

Prueba de que existe un cuello de botella de latencia con el sistema actual: si tuviera una red en la que la mitad de los nodos estuvieran en la Tierra y la otra mitad estuviera cerca del sol, tendría dificultades para mantener la red sincronizada con un bloque de tiempo. menos de ~8 minutos. A menos, por supuesto, que cuente nuestra incapacidad para enviar datos con latencias FTL como un cuello de botella de hardware. Sí, podría tener la propiedad de coherencia eventual (creo), pero también terminaría con reorganizaciones en cadena frecuentes (y enormes) con un tiempo de bloqueo de 1 segundo.
Eso pondría fin a las transacciones que se basan en transacciones anteriores. Fragmentación geográfica para reducir la latencia, pero aún sería necesario tenerlo en cuenta. El límite inferior de latencia para una red terrestre distribuida aleatoriamente que usa Casper es ~2.5s (la latencia de ida y vuelta involucrada para lo que es alrededor de cinco rondas de comunicación); un límite útil más bajo para la latencia para un algoritmo de prueba de trabajo similar es probablemente el tiempo de ping unidireccional (de lo contrario, simplemente terminas reorganizando constantemente la cadena de bloques, lo cual es viable pero no es tan útil si lo que quieres querer es consenso).

Entonces, ¿por qué no es posible procesar transacciones más rápido?

Las transacciones tienen que ser puestas en bloques. El número de transacciones que pueden caber en un bloque está dictado por el límite de gas del bloque , así que...

... porque el tamaño del bloque es arbitrario.

...los bloques no son arbitrariamente grandes. Como se indicó anteriormente, solo pueden ser tan grandes como lo permita el límite de gas del bloque. Así que este es uno de los "cuellos de botella".


Entonces no podemos cambiar cuántas transacciones caben en un bloque. ¿Por qué no tener más bloques, reduciendo la cantidad de tiempo entre cada uno?

El tiempo promedio de bloqueo ahora es de alrededor de 25 segundos . (Es un poco más largo de lo que Thomas sugirió en su respuesta porque nos estamos moviendo hacia Metrópolis, y la "bomba de dificultad" está entrando en acción, lo que aumenta gradualmente el tiempo entre bloques).

Acortar el tiempo entre bloques conduciría a un aumento en el número de bifurcaciones y reordenamientos de la cadena. Considere el escenario descrito en el libro blanco (también tomado de esta pregunta anterior):

... las cadenas de bloques con tiempos de confirmación rápidos (es decir, tiempos de bloqueo) actualmente sufren una seguridad reducida debido a una alta tasa de obsolescencia, porque los bloques tardan cierto tiempo en propagarse a través de la red, si el minero A extrae un bloque y luego el minero B lo hace. otro bloque antes de que el bloque del minero A se propague a B, el bloque del minero B terminará desperdiciado y no contribuirá a la seguridad de la red.

Por lo tanto, se debe encontrar un equilibrio entre incluir rápidamente una transacción en un bloque (tiempos de bloque más cortos) y reducir el número de reordenamientos de la cadena para alcanzar un verdadero consenso (tiempos de bloque más largos). Donde se encuentra el equilibrio depende del caso de uso y el diseño de la cadena. Este es su segundo "cuello de botella" (aunque por diseño).

Finalmente, el tiempo de bloqueo de Ethereum es mucho más corto que el tiempo de bloqueo de Bitcoin (¿10 minutos?). Ethereum puede hacer esto porque usa algo llamado GHOST , que ayuda a recuperar parte del poder de hash utilizado en la extracción de bloques "desperdiciados" ( huérfanos ).

Ver también: ¿Qué sucede si el tiempo de bloqueo cambia a 5 segundos?

El sistema debe llegar a un consenso y hacerlo bajo prueba de trabajo. Los diseñadores del sistema eligieron 14 segundos como la cantidad de trabajo que querían imponer al minero (en promedio) que gana el bloque y recibe la recompensa del bloque. El mejor lugar para ayudarlo a resolver estas cosas sigue siendo, por mi dinero, el libro blanco original de Bitcoin. Otros pueden tener mejores fuentes. Conozca cómo funcionan el consenso y la prueba de trabajo, y tendrá su respuesta.

Lo más probable es que el cuello de botella se deba a un diseño imperfecto del sistema. La prueba de trabajo se usa para resolver algunos problemas juntos en bitcoin. La criptomoneda Ripple funciona sin blockchain y tiene un algoritmo de consenso diferente. Lo cual, como afirman los creadores, permite reducir el costo de la transmisión a fracciones de centavos y el tiempo de confirmación a minutos. Puede ver esta conferencia para obtener más detalles: https://www.youtube.com/watch?v=7abKUs9tYZg

Ripple resuelve un conjunto diferente de problemas a Ethereum, por lo que el sistema está diseñado de manera diferente. No creo que los dos puedan compararse de tal manera que concluya que "cualquier cosa que tenga un tiempo de transacción más lento para Ripple debe ser imperfecto".