Reenviar el Título Original 'Limitaciones de escalar blockchains y qué VM's son teóricamente más rápidos'

TL; DR

Estamos viendo un cambio hacia servidores únicos y potentes; Solana, Megaeth y la amplia gama de secuenciadores individuales se inclinan hacia una sola cosa: un servidor único de alto rendimiento y gran capacidad de memoria (de estos, el no L2 siempre será prácticamente el más rápido).

Recientemente estaba charlando con otro fundador a quien respeto mucho, él mencionó que debería escribir nuestra conversación.

Todo comenzó con una pregunta sencilla; “¿Sonic paraleliza la ejecución de transacciones de alguna manera?”. La respuesta es no. Y esto, al principio, podría parecer una elección extraña, ya que en los últimos 2 años, si has estado leyendo sobre tecnología VM, habrías visto la paralelización prácticamente en todas partes. Entonces, ¿por qué no lo estamos haciendo?

Para responder a eso, primero tenemos que ver cómo la ingeniería de Sonic evalúa en qué debemos trabajar, teníamos un montón de teorías, que sobre el papel suenan prácticas, que queríamos implementar, pero recursos físicos limitados del equipo, entonces, ¿cómo elegimos cuál es la más impactante? Entonces, en lugar de trabajar en CUALQUIERA de esas ideas, el equipo decidió pasar un año para construir Aida, Aida es una herramienta increíblemente poderosa que nos permite reproducir cadenas de bloques completas (cualquiera) en minutos en lugar de meses con métricas de rendimiento útiles incorporadas. Esto significa que podríamos crear prototipos, probar en Aida y saber muy rápidamente qué teorías se sostienen y cuáles no.

Aida también nos permite algunos perfiles bastante poderosos, lo que conduce a salidas como;

Por lo tanto, con lo anterior en su lugar, podríamos probar muy rápidamente y con precisión nuestras suposiciones de rendimiento, así que nos propusimos comparar puramente en memoria VM vs disco, ejecución paralela, RDMS vs KV vs archivo plano, subconjuntos, nuevos modelos de consenso y más

La mayor mejora, fue DB, un aumento del 800%, los siguientes superconjuntos, seguidos por el consenso, y muy abajo en esa lista, con una modesta mejora del 30%, fue la ejecución paralela. Esto parece contradictorio, ya que un modelo mental para algo como la ejecución paralela parece intuitivamente mejor que los resultados. Entonces, ¿cómo paralelizamos? Tal vez cometimos un error, la prueba fue "Clarividencia", la forma perfecta de ordenar, un motor que conoce la clasificación y paralelización óptimas antes de la ejecución (algo que en la práctica ya es imposible, por lo que incluso el 30% es más alto de lo que debería ser).

Los VM y blockchains son componentes muy complejos, y a menudo medimos métricas incorrectas (o no medimos en absoluto).

Entonces me preguntó: "¿De dónde viene entonces la velocidad de Solana? ¿O no es prácticamente más alto que Sonic?". La respuesta "Sonic es más rápido que Solana, pero Sonic no es más rápido de lo que puede ser Solana".

Estamos viendo un cambio hacia servidores únicos y potentes; Solana, Megaeth y la amplia gama de secuenciadores únicos se inclinan hacia una sola cosa: un servidor único de alto rendimiento y alta memoria (de estos, el no L2 siempre será prácticamente el más rápido). Esta solución, si está optimizada correctamente, siempre será más rápida que múltiples participantes. Por lo tanto, el rendimiento máximo optimizado de algo como Solana o Megaeth sería mayor que el de su próximo competidor más rápido que hace consenso con 2+ servidores.

Entonces, la siguiente pregunta es probablemente, ¿por qué Sonic no elige servidores de un solo líder? Y la respuesta aquí es que no es para eso para lo que estamos optimizando. Uno de nuestros comienzos del norte sobre el que escribí en 2018 fue que, a medida que vemos el advenimiento de programas intercomunicados, en algún momento, se requiere consenso. Suponga una intersección concurrida sin señales de alto ni semáforos y cientos de tráfico de automóviles. El método más optimizado es que los coches se "registren" en la intersección y luego acuerden un orden de clasificación y el método más optimizado en el que cada coche debe moverse para maximizar el rendimiento. Aquí no se puede utilizar un sistema basado en líderes, y no se puede asumir que una parte no es maliciosa, en este caso, el consenso de Sonic está optimizado hasta el punto de que ya puede validarse en una raspberry pi hoy sin perder ningún rendimiento, por lo que todos los coches pueden ponerse de acuerdo en el orden basado en el consenso de Sonic. Sonic está optimizado para redes de malla.

De todos modos, divagaciones aleatorias, espero que haya ayudado de alguna manera.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Andre Cronje]. Todos los derechos de autor pertenecen al autor original [Andre Cronje]. Si hay objeciones a esta reimpresión, póngase en contacto con el Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen asesoramiento de inversión.
3. El equipo de gate Learn realiza traducciones del artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.