El camino de BNB Chain hacia los grandes bloques

El camino de los grandes bloques en BNB Chain

Al igual que Solana, Heco y otras cadenas públicas respaldadas por exchanges, la cadena pública de BNB Chain, BNB Smart Chain (BSC), ha perseguido durante mucho tiempo un alto rendimiento. Desde su lanzamiento en 2020, BSC ha establecido el límite de capacidad de gas para cada bloque en 30 millones, con un intervalo de bloque estable de 3 segundos. Con tales parámetros, BSC logró un TPS máximo (TPS con varias transacciones mezcladas) de más de 100. En junio de 2021, el límite de gas de bloque de BSC se incrementó a 60 millones. Sin embargo, en julio del mismo año, un juego en cadena llamado CryptoBlades explotó en BSC, lo que provocó que los volúmenes de transacciones diarias superaran los 8 millones y provocara un aumento vertiginoso de las tarifas. Resultó que el cuello de botella de la eficiencia de BSC todavía era bastante obvio en ese momento.

(Fuente: BscScan)

Para abordar los problemas de rendimiento de la red, BSC volvió a aumentar el límite de gas para cada bloque, que se mantuvo estable en torno a los 80-85 millones durante mucho tiempo. En septiembre de 2022, el límite de gas por bloque de BSC Chain se incrementó a 120 millones, y a finales de año, se elevó a 140 millones, casi cinco veces el de 2020. Anteriormente, BSC había planeado aumentar el límite de capacidad de gas de bloque a 300 millones, pero tal vez teniendo en cuenta la pesada carga sobre los nodos validadores, la propuesta de tales bloques súper grandes no se ha implementado.

fuente: YCHARTS

Más tarde, BNB Chain pareció centrarse más en la pista modular/Layer2 en lugar de persistir en la expansión Layer1. Esta intención se hizo cada vez más evidente desde el lanzamiento de zkBNB en la segunda mitad del año pasado a GreenField a principios de este año. Debido a un gran interés en la cadena de bloques modular/Layer2, el autor de este artículo utilizará opBNB como objeto de investigación para revelar los cuellos de botella de rendimiento de Rollup comparándolo con Ethereum Layer2.

El impulso del alto rendimiento de BSC a la capa DA de opBNB

Como todos sabemos, Celestia ha resumido cuatro componentes clave de acuerdo con el flujo de trabajo de la cadena de bloques modular: Capa de ejecución: ejecuta el código del contrato y completa las transiciones de estado; Capa de liquidación: Maneja pruebas de fraude/pruebas de validez y aborda los problemas de puente entre L2 y L1. Capa de consenso: Llega a un consenso sobre el orden de las transacciones. Capa de disponibilidad de datos (DA): Publica datos relacionados con el libro mayor de la cadena de bloques, lo que permite a los validadores descargar estos datos.

Entre ellas, la capa DA a menudo se combina con la capa de consenso. Por ejemplo, los datos del DA de Optimistic Rollup contienen un lote de secuencias de transacciones en bloques L2. Cuando los nodos completos de L2 obtienen datos de DA, conocen el orden de cada transacción en este lote. (Por esta razón, la comunidad de Ethereum cree que la capa DA y la capa de consenso están relacionadas cuando se superpone Rollup).

Sin embargo, para Ethereum Layer2, el rendimiento de datos de la capa DA (Ethereum) se ha convertido en el mayor cuello de botella que restringe el rendimiento de Rollup. Esto se debe a que el rendimiento actual de datos de Ethereum es demasiado bajo, lo que obliga a Rollup a suprimir su TPS tanto como sea posible para evitar que la red principal de Ethereum no pueda soportar los datos generados por L2. Al mismo tiempo, el bajo rendimiento de datos hace que un gran número de instrucciones de transacción dentro de la red Ethereum estén en estado pendiente, lo que lleva a que las tarifas de gas se eleven a niveles extremadamente altos y aumente aún más el coste de la publicación de datos para la capa 2. Por último, muchas redes de capa 2 tienen que adoptar capas de DA fuera de Ethereum, como Celestia, y opBNB, que está cerca del agua, ha optado por utilizar directamente el alto rendimiento de BSC para implementar DA para resolver el problema del cuello de botella de la publicación de datos. Para facilitar la comprensión, vamos a presentar el método de publicación de datos de DA para Rollup. Tomando Arbitrum como ejemplo, la cadena Ethereum controlada por la dirección EOA del secuenciador de capa 2 enviará periódicamente transacciones al contrato especificado. En los parámetros de entrada calldata de esta instrucción, se escriben los datos de transacción empaquetados y se activan los eventos on-chain correspondientes, dejando un registro permanente en los registros de contratos.

De esta manera, los datos de transacción de Layer2 se almacenan en bloques de Ethereum durante mucho tiempo. Las personas que son capaces de ejecutar nodos L2 pueden descargar los registros correspondientes y analizar los datos correspondientes, pero los nodos de Ethereum en sí mismos no ejecutan estas transacciones L2. Es fácil ver que L2 solo almacena los datos de las transacciones en bloques de Ethereum, incurriendo en costos de almacenamiento, mientras que los costos computacionales de ejecutar transacciones son asumidos por los propios nodos L2. Lo anterior es el método de implementación del DA de Arbitrum, mientras que Optimism utiliza una dirección EOA controlada por el secuenciador para transferir a otra dirección EOA especificada, llevando un nuevo lote de datos de transacciones de capa 2 en los datos adicionales. En cuanto a opBNB, que utiliza OP Stack, su método de publicación de datos DA es básicamente el mismo que el de Optimism.

Es obvio que el rendimiento de la capa DA limitará el tamaño de los datos que Rollup puede publicar en una unidad de tiempo, lo que limitará TPS. Teniendo en cuenta que después de EIP1559, la capacidad de gas de cada bloque de ETH se estabiliza en 30 millones, y el tiempo de bloque después de la fusión es de unos 12 segundos, Ethereum puede manejar un máximo de solo 2,5 millones de gas por segundo. La mayoría de las veces, el gas consumido al acomodar los datos de transacciones L2 por byte en los datos de llamadas es de 16, por lo que Ethereum puede manejar un tamaño máximo de datos de llamadas de solo 150 KB por segundo. Por el contrario, el tamaño medio máximo de los datos de llamadas procesados por segundo de BSC es de unos 2910 KB, que es 18,6 veces el de Ethereum. La diferencia entre las dos como capas de DA es obvia.

En resumen, Ethereum puede transportar unos 150 KB de datos de transacciones L2 por segundo. Incluso después del lanzamiento de EIP 4844, este número no cambiará mucho, solo reducirá la tarifa DA. Entonces, ¿cuántos datos de transacciones se pueden incluir en aproximadamente 150 KB por segundo? Aquí tenemos que explicar la tasa de compresión de datos de Rollup. Vitalik se mostró demasiado optimista en 2021, estimando que Optimistic Rollup puede comprimir el tamaño de los datos de las transacciones hasta el 11% del tamaño original. Por ejemplo, una transferencia ETH básica, que originalmente ocupaba un tamaño de datos de llamada de 112 bytes, se puede comprimir a 12 bytes mediante Optimistic Rollup, las transferencias ERC-20 se pueden comprimir a 16 bytes y las transacciones de intercambio en Uniswap se pueden comprimir a 14 bytes. Según su estimación, Ethereum puede registrar alrededor de 10.000 transacciones L2 por segundo (con varios tipos mezclados). Sin embargo, según los datos divulgados por el equipo de Optimism en 2022, la tasa de compresión de datos real puede alcanzar un máximo de solo alrededor del 37%, que es 3,5 veces menor que la estimación de Vitalik.

(La estimación de Vitalik del efecto de escalabilidad de Rollup se desvía significativamente de las condiciones reales)

(Tasas de compresión reales alcanzadas por varios algoritmos de compresión revelados por Optimism)

Así que demos un número razonable: incluso si Ethereum alcanza su límite de rendimiento, el TPS máximo de todos los Optimistic Rollups combinados es solo un poco más de 2000. En otras palabras, si los bloques de Ethereum se utilizaran en su totalidad para transportar los datos publicados por los Optimistic Rollups, como los distribuidos entre Arbitrum, Optimism, Base y Boba, el TPS combinado de estos Optimistic Rollups ni siquiera llegaría a 3000, incluso bajo los algoritmos de compresión más eficientes. Además, debemos considerar que después de EIP1559, la capacidad de gas de cada bloque promedia solo el 50% del valor máximo, por lo que el número anterior debe reducirse a la mitad. Después del lanzamiento de EIP4844, aunque las tarifas de transacción para la publicación de datos se reducirán significativamente, el tamaño máximo de bloque de Ethereum no cambiará mucho (ya que demasiados cambios afectarían la seguridad de la cadena principal de ETH), por lo que el valor estimado anterior no progresará mucho.

Según datos de Arbiscan y Etherscan, un lote de transacciones en Arbitrum contiene 1115 transacciones, consumiendo 1,81 millones de gas en Ethereum. Por extrapolación, si la capa DA se rellena en cada bloque, el límite teórico de TPS de Arbitrum es de aproximadamente 1500. Por supuesto, teniendo en cuenta el problema de la reorganización de bloques L1, Arbitrum no puede publicar lotes de transacciones en cada bloque de Ethereum, por lo que los números anteriores son actualmente solo teóricos. Además, con la adopción generalizada de billeteras inteligentes relacionadas con EIP 4337, el problema de DA se volverá aún más grave. Porque con el soporte para EIP 4337, la forma en que los usuarios verifican su identidad se puede personalizar, como cargar datos binarios de huellas dactilares o iris, lo que aumentará aún más el tamaño de los datos ocupados por las transacciones regulares. Por lo tanto, el bajo rendimiento de datos de Ethereum es el mayor cuello de botella que limita la eficiencia de Rollup, y es posible que este problema no se resuelva adecuadamente durante mucho tiempo. Por otro lado, en la Cadena BNB de la cadena pública BSC, el tamaño máximo promedio de datos de llamadas procesados por segundo es de aproximadamente 2910 KB, que es 18,6 veces el de Ethereum. En otras palabras, siempre que la capa de ejecución pueda seguir el ritmo, el límite superior teórico de TPS de la capa 2 dentro del ecosistema de BNB Chain puede alcanzar aproximadamente 18 veces el de ARB u OP. Este número se calcula en función de la capacidad máxima de gas de bloque actual de BNB Chain de 140 millones, con un tiempo de bloqueo de 3 segundos.

En otras palabras, el límite actual de TPS agregado de todos los Rollups dentro del ecosistema de BNB Chain es 18,6 veces mayor que el de Ethereum (incluso si se considera ZKRollup). Desde esta perspectiva, es fácil entender por qué tantos proyectos de capa 2 utilizan la capa DA bajo la cadena Ethereum para publicar datos, ya que la diferencia es bastante evidente. Sin embargo, la cuestión no es tan sencilla. Además del problema del rendimiento de los datos, la estabilidad de la propia capa 1 también puede afectar a la capa 2. Por ejemplo, la mayoría de los Rollups suelen esperar varios minutos antes de publicar un lote de transacciones en Ethereum, teniendo en cuenta la posibilidad de una reorganización de bloques de capa 1. Si se reorganiza un bloque de Layer1, afectaría al libro mayor de blockchain de Layer2. Por lo tanto, el secuenciador esperará a que se publiquen varios bloques nuevos de capa 1 después de cada lanzamiento de un lote de transacciones L2, lo que reduce significativamente la probabilidad de reversión de bloques, antes de publicar el siguiente lote de transacciones L2. En realidad, esto retrasa el momento en que los bloques L2 finalmente se confirman, lo que reduce la velocidad de confirmación de las transacciones grandes (las transacciones grandes requieren resultados irreversibles para garantizar la seguridad). En resumen, las transacciones que se producen en L2 solo se vuelven irreversibles después de ser publicadas en los bloques de la capa DA y después de que la capa DA haya generado un cierto número de nuevos bloques. Esta es una razón importante que limita el rendimiento del paquete acumulativo. Sin embargo, Ethereum tiene una velocidad de generación de bloques lenta, tardando 12 segundos en producir un bloque. Suponiendo que Rollup publique un lote de transacciones L2 cada 15 bloques, habrá un intervalo de 3 minutos entre diferentes lotes y, después de que se publique cada lote, aún debe esperar a que se generen varios bloques de capa 1 antes de que se vuelvan irreversibles (suponiendo que no se impugnen). Obviamente, el tiempo desde el inicio hasta la irreversibilidad de las transacciones en la capa 2 de Ethereum es bastante largo, lo que resulta en una velocidad de liquidación lenta; mientras que BNB Chain solo tarda 3 segundos en producir un bloque, y los bloques se vuelven irreversibles en solo 45 segundos (el tiempo que se tarda en producir 15 nuevos bloques). Con base en los parámetros actuales, asumiendo el mismo número de transacciones L2 y considerando la irreversibilidad de los bloques L1, el número de veces que opBNB puede publicar datos de transacciones en una unidad de tiempo puede alcanzar hasta 8.53 veces el de Arbitrum (una vez cada 45 segundos para el primero, y una vez cada 6.4 minutos para el segundo). Claramente, la velocidad de liquidación de las grandes transacciones en opBNB es mucho más rápida que en la capa 2 de Ethereum. Además, el tamaño máximo de los datos publicados por opBNB cada vez puede alcanzar 4,66 veces el de la capa 2 de Ethereum (el límite de gas de bloque L1 del primero es de 140 millones, mientras que el del segundo es de 30 millones). 8,53 * 4,66 = 39,74. Esto representa la brecha entre opBNB y Arbitrum en términos de límite de TPS en la implementación práctica (actualmente, por razones de seguridad, ARB parece reducir activamente el TPS, pero teóricamente, si se aumentara el TPS, seguiría siendo muchas veces menor en comparación con opBNB).

(El secuenciador de Arbitrum publica un lote de transacciones cada 6-7 minutos)

(El secuenciador de opBNB publica un lote de transacciones cada 1-2 minutos, y el más rápido tarda solo 45 segundos). Por supuesto, hay otra cuestión crucial a tener en cuenta, que son las tarifas de gas en la capa DA. Cada vez que L2 publica un lote de transacciones, hay un costo fijo de 21.000 gas no relacionado con el tamaño de los datos de llamada, lo cual es un gasto. Si las tarifas de gas para la capa DA/L1 son altas, lo que hace que el costo fijo de publicar un lote de transacciones en L2 siga siendo alto, el secuenciador reducirá la frecuencia de publicación de lotes de transacciones. Además, al considerar los componentes de las tarifas L2, el costo de la capa de ejecución es muy bajo y, a menudo, se puede ignorar, centrándose solo en el impacto de los costos de DA en las tarifas de transacción. En resumen, mientras que la publicación de datos de llamadas del mismo tamaño consume la misma cantidad de gas en Ethereum y BNB Chain, el precio del gas que cobra Ethereum es entre 10 y docenas de veces mayor que el de BNB Chain. Traducido a las tarifas de transacción L2, las tarifas de transacción de usuario actuales en Ethereum Layer2 también son entre 10 y docenas de veces más altas que las de opBNB. En general, las diferencias entre opBNB y Optimistic Rollup en Ethereum son bastante evidentes.

(Una transacción que consume 150.000 de gas en Optimism cuesta 0,21 dólares)

(Una transacción que consume 130,000 de gas en opBNB cuesta USD 0.004) Sin embargo, el aumento del rendimiento de datos de la capa DA, aunque puede mejorar el rendimiento general del sistema de capa 2, sigue teniendo un impacto limitado en la mejora del rendimiento de los paquetes acumulativos individuales. Esto se debe a que la capa de ejecución a menudo no procesa las transacciones lo suficientemente rápido. Incluso si se pueden ignorar las limitaciones de la capa DA, la capa de ejecución se convierte en el siguiente cuello de botella que afecta al rendimiento del resumen. Si la velocidad de ejecución de la capa de ejecución de la capa 2 es lenta, el desbordamiento de la demanda de transacciones se extenderá a otras capas 2, lo que en última instancia provocará la fragmentación de la liquidez. Por lo tanto, mejorar el rendimiento de la capa de ejecución también es crucial, sirviendo como otro umbral por encima de la capa DA.

Impulso de opBNB en la capa de ejecución: optimización de caché

Cuando la mayoría de la gente habla de los cuellos de botella de rendimiento de las capas de ejecución de blockchain, inevitablemente mencionan dos cuellos de botella importantes: la ejecución en serie de un solo hilo de la EVM que no utiliza completamente la CPU, y la búsqueda ineficiente de datos del Merkle Patricia Trie adoptado por Ethereum. En esencia, las estrategias de escalado para la capa de ejecución giran en torno a hacer un uso más eficiente de los recursos de la CPU y garantizar que la CPU pueda acceder a los datos lo más rápido posible.

Las soluciones de optimización para la ejecución de EVM en serie y Merkle Patricia Trie suelen ser complejas y difíciles de implementar, mientras que los esfuerzos más rentables tienden a centrarse en la optimización de la caché. De hecho, la optimización de la caché nos lleva de vuelta a puntos que se discuten con frecuencia en los contextos tradicionales de la Web2 e incluso de los libros de texto.

Normalmente, la velocidad a la que la CPU recupera datos de la memoria es cientos de veces más rápida que la recuperación de datos del disco. Por ejemplo, la recuperación de datos de la memoria puede tardar solo 0,1 segundos, mientras que la recuperación del disco puede tardar 10 segundos. Por lo tanto, reducir la sobrecarga generada por las lecturas y escrituras de disco, es decir, la optimización de la caché, se convierte en un aspecto esencial de la optimización de la capa de ejecución de la cadena de bloques.

En Ethereum y en la mayoría de las otras cadenas públicas, la base de datos que registra los estados de las direcciones en cadena se almacena completamente en el disco, mientras que el llamado World State trie es simplemente un índice de esta base de datos, o un directorio utilizado para la búsqueda de datos. Cada vez que la EVM ejecuta un contrato, necesita acceder a los estados de dirección relevantes. La obtención de datos de la base de datos basada en disco uno por uno ralentizaría significativamente la ejecución de transacciones. Por lo tanto, configurar una caché fuera de la base de datos/disco es un medio necesario para acelerar.

opBNB adopta directamente la solución de optimización de caché utilizada por BNB Chain. De acuerdo con la información revelada por el socio de opBNB, NodeReal, la primera cadena BSC estableció tres capas de caché entre la EVM y la base de datos LevelDB que almacena el estado. El concepto de diseño es similar al de las cachés tradicionales de tres niveles, donde los datos con mayor frecuencia de acceso se almacenan en la caché. Esto permite que la CPU busque primero los datos necesarios en la memoria caché. Si la tasa de aciertos de caché es lo suficientemente alta, la CPU no necesita depender demasiado del disco para obtener datos, lo que resulta en una mejora significativa en la velocidad de ejecución general.

Más tarde, NodeReal agregó una función además de esto, que aprovecha los núcleos de CPU no utilizados para leer de forma preventiva los datos que la EVM necesitará procesar en el futuro desde la base de datos y almacenarlos en la memoria caché. Esta característica se denomina "precarga de estado".

El principio de precarga de estado es simple: las CPU de los nodos de blockchain son de varios núcleos, mientras que la EVM opera en un modo de ejecución en serie de un solo hilo, utilizando solo un núcleo de CPU, dejando otros núcleos de CPU infrautilizados. Para solucionar esto, los núcleos de CPU que no utiliza la EVM pueden ayudar en las tareas mediante la predicción de los datos que la EVM necesitará de la secuencia de transacciones que aún no se ha procesado. Estos núcleos de CPU fuera de la EVM recuperarán los datos que la EVM necesitará de la base de datos, lo que ayudará a la EVM a reducir la sobrecarga de la recuperación de datos y, por lo tanto, acelerará la ejecución.

Con la optimización de la caché y suficientes configuraciones de hardware, opBNB ha llevado efectivamente el rendimiento de la capa de ejecución de su nodo cerca del límite de la EVM, procesando hasta 100 millones de gas por segundo. Estos 100 millones de gas son esencialmente el techo de rendimiento de la EVM no modificada, como lo demuestran los datos de pruebas experimentales de una cadena pública prominente.

En pocas palabras, opBNB puede procesar hasta 4761 transferencias simples por segundo, 15003000 transferencias de tokens ERC20 por segundo y aproximadamente 5001000 operaciones de SWAP por segundo según los datos de transacciones observados en los exploradores de blockchain. Comparando los parámetros actuales, el límite de TPS de opBNB es 40 veces mayor que el de Ethereum, más de 2 veces el de BNB Chain y más de 6 veces el de Optimism.

Por supuesto, para las soluciones de capa 2 de Ethereum, debido a las severas limitaciones de la propia capa DA, el rendimiento se descuenta significativamente en función del rendimiento de la capa de ejecución, al considerar factores como el tiempo de generación de bloques y la estabilidad de la capa DA.

Para BNB Chain con una capa DA de alto rendimiento como opBNB, el efecto de duplicación del escalado es valioso, especialmente teniendo en cuenta que BNB Chain puede albergar múltiples proyectos de escalado de este tipo. Se puede prever que BNB Chain ya ha incorporado soluciones de capa 2 lideradas por opBNB en sus planes estratégicos, y continuará incorporando más proyectos de blockchain modulares, incluida la introducción de pruebas de ZK en opBNB y el suministro de capas de DA de alta disponibilidad con infraestructura complementaria como GreenField, en un intento de competir o cooperar con el ecosistema de capa 2 de Ethereum.

En la era en la que el escalado por capas se ha convertido en la tendencia, queda por ver si otras cadenas públicas también se apresurarán a respaldar sus propios proyectos de capa 2, pero sin duda, el cambio de paradigma hacia la infraestructura modular de blockchain ya está ocurriendo.

Renuncia:

1. Este artículo es una reimpresión de [极客 Web3], Todos los derechos de autor pertenecen al autor original [Faust, 极客web3]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.