Cofundador de Solana: Construcción de una máquina de estado global y análisis de la arquitectura definitiva de Solana

**Texto: Anatoly Yakovenko, CEO (Co-Fundador y CEO), Solana

Compilador: 1912212.eth, Foresight News

El objetivo de Solana es sincronizar una única máquina de estado global sin permisos lo más rápido posible, de acuerdo con las leyes de la física. Creo que la arquitectura que será capaz de lograr esto se verá así:

• Gran número de nodos completos, más de 10.000 (N > 10.000)

Para que la red funcione como una máquina de estado global, debe admitir numerosos nodos completos. Turbine ha demostrado que la replicación rápida en redes muy grandes es escalable en hardware y redes modernas.

• Gran número de líderes de generación de bloques, más de 10.000 (N > 10.000)
• Los líderes simultáneos producen bloques al mismo tiempo, seleccionados aleatoriamente en el rango de 4 a 16.

Concurrency Leader permite que la red tenga varias ubicaciones en todo el mundo para solicitar las transacciones de los usuarios. Reduce la distancia entre los usuarios y la red, eliminando la necesidad de verificación completa del nodo antes de que las transacciones se agreguen a la cadena.

• El tiempo de bloqueo es de 120 milisegundos

Los tiempos de bloqueo cortos crean puntos de finalidad rápidos, mejoran la resistencia a la censura, mejoran la experiencia del usuario, reducen las ventanas para reordenar las transacciones y aceleran la red en general.

• Algunos de los nodos de consenso de votación en el subcomité de aprobación, con un número de entre 200 y 400, se seleccionan aleatoriamente y rotan cada 4 a 8 horas por época.

El consenso es esencial para elegir una bifurcación, lo que ocurre debido a la partición de la red. Una muestra de 200 o más nodos será estadísticamente representativa de todas las particiones principales de la red y coincidirá estrechamente con su distribución real. Por lo tanto, no se requieren todos los votos de nodo completos, 200 es suficiente. Limitar la aprobación a los subcomités para reducir la memoria y el ancho de banda de red necesarios para admitir bloques de 120 ms. La reducción del tiempo de bloqueo aumenta naturalmente el número de votos enviados por segundo, lo que ejerce cierta presión sobre los recursos asignados para el consenso.

El verdadero desafío en el bloque de 120 ms es reproducir todas las transacciones de los usuarios. Dado que la red no tiene permisos, es extremadamente difícil garantizar un entorno de ejecución homogéneo con un tiempo confiable para ejecutar código de usuario arbitrario. Si bien existe la posibilidad, solo se puede lograr limitando los recursos informáticos disponibles para las transacciones de los usuarios y asegurándose de que cada nodo esté sobreasignado al peor de los casos.

Sin embargo, no hay ninguna razón para imponer un estado completo para los nodos de consenso que votan por una bifurcación o un líder que se basa en una bifurcación. Para mantener sincronizadas las aprobaciones de los nodos de consenso y los líderes, el estado solo debe calcularse una vez por período.

Ejecución asincrónica

Motivación

La ejecución síncrona requiere que todos los nodos que votan y crean bloques estén superconfigurados en cualquier bloque para determinar el tiempo de ejecución en el peor de los casos. La ejecución asincrónica es uno de los pocos casos en los que hay pocas compensaciones. Los nodos de consenso pueden realizar menos trabajo antes de la votación. El trabajo se puede agregar y agrupar, lo que lo hace eficiente en la ejecución sin pérdida de caché. Incluso se puede ejecutar en una máquina completamente diferente a la del nodo de consenso o líder. Los usuarios que desean una ejecución sincrónica pueden asignar suficientes recursos de hardware para realizar cada transición de estado en tiempo real sin tener que esperar a toda la red.

Dada la diversidad de aplicaciones y desarrolladores principales, vale la pena planificar un cambio importante en el protocolo cada año. Si tuviera que elegir uno, mi elección sería ejecutarlo de forma asíncrona.

DESCRIPCIÓN GENERAL

Actualmente, los validadores repiten rápidamente todas las transacciones en cada bloque y votan solo después de que se haya calculado el estado completo del bloque. El objetivo de esta propuesta es separar las decisiones de voto sobre las bifurcaciones del cálculo de las transiciones de estado completas de los bloques.

Los validadores que votan en la aprobación solo necesitan seleccionar la bifurcación; no necesitan realizar ningún estado en absoluto. Solo en cada época necesitan el estado para calcular la siguiente aprobación.

El procedimiento de votación se ajustó para que pudiera llevarse a cabo de forma independiente. Los nodos ejecutan los procedimientos de votación solo antes de votar. Dado que los validadores no ocupan mucho espacio, los requisitos de memoria deben ser relativamente pequeños. Dado que la votación tiene un tiempo de ejecución muy predecible, debería haber poca o ninguna fluctuación en la ejecución del procedimiento de votación.

Todas las transacciones sin derecho a voto se pueden calcular de forma asíncrona. Esto permite que la reproducción ejecute todas las transacciones sin derecho a voto en lotes, la captura previa y JIT de todos los programas por adelantado, eliminando prácticamente toda la pérdida de caché. El objetivo a largo plazo es que solo las máquinas que requieran cálculos en tiempo real, de baja latencia y de estado completo se configurarán para esta tarea. Presumiblemente, los usuarios pagarán por el hardware adicional.

Una vez que se separan la selección de la bifurcación y la ejecución del estado, es más fácil acelerar las cosas:

• Ejecución asíncrona
• Cada época rota un número fijo de comités de votación
• Tiempo de bloque de 200 ms

Dado que la reproducción de la transacción del usuario no bloquea la selección de la bifurcación, la volatilidad ya no es un problema al restar el tiempo de bloqueo. Lo único que hay que tener en cuenta es que a los 200 milisegundos, la tasa de votación del validador se duplica. Hacer un cambio bastante sencillo en la forma en que se calcula la cuota para las aprobaciones nos permitirá fijar el tamaño de la aprobación en 200 o 400, o cualquier número que parezca apropiado.

También es natural separar completamente la implementación del consenso. Será más rápido reiniciar el nodo de consenso que solo necesita verificar la cuenta del programa de votación en la aprobación de tamaño fijo.

De hecho, creo que el tiempo de confirmación aumentará porque la gran mayoría de las aprobaciones se votan lo más rápido posible y, mientras se propagan estos votos, los nodos que proporcionan a los usuarios los resultados completos de la ejecución del estado pueden ejecutar transacciones al mismo tiempo. Por lo tanto, cualquier fluctuación de repetición que veamos hoy en día debería ocurrir al mismo tiempo que la propagación de la red de votación.

Votar

• Las cuentas de votación deben tener un número suficiente de SOL para cubrir los votos de 2 épocas.
• Las transacciones de votación deben ser simples. Una votación no simple está condenada al fracaso. Los generadores de bloques deberían renunciar a las votaciones complejas.
• Se permite retirar SOL de las cuentas de votación, siempre y cuando el saldo no baje a menos de 1 época de votos.
• Con el fin de poner a cero todas las lamports, la directiva Vote CLOSE debe requerir que transcurra la época completa. Las cuentas de votación se marcan como CERRADAS en la Era 1, pero solo se pueden CERRAR en la Era 2. CLOSE le permite retirar todos los SOL y eliminar cuentas de votación. Una vez que una cuenta está marcada como CERRAR, solo se puede eliminar por completo y no se puede volver a abrir.
• Los votos contienen un VoteBankHash en lugar de un BankHash normal.

Regulación y aprobación del líder

Solo los validadores cumplen los siguientes criterios:

• Monto de la apuesta > X
• Así como SOL > 2 épocas de votación
• y no está marcado como CLOSE

para introducir el cronograma del líder y contar para su aprobación. Para la versión 2, podemos separar el LeaderSchedule del Quorum, y no es necesario que tengan los mismos requisitos cada uno.

Cálculo de VoteBankHash

A diferencia de Bankhash, que calcula todas las transacciones, los validadores solo calculan VoteBankHash para transacciones de votación simples relacionadas con validadores en LeaderScheduler. Todas las demás transacciones se ignoran. Después de reproducir todos los votos, el VoteBankHash se calcula en el mismo formato que el BankHash actual.

El VoteBankHash debe acumular el VoteBankHash anterior, no el BankHash completo.

Cálculos de BankHash

Para todos los bloques confirmados optimistas (configurables para todos los bloques), el validador comienza a calcular el UserBankHash, que incluye todas las transiciones de estado, pero excluye las transacciones que se han considerado en el cálculo de VoteBankHash.

El BankHash se deriva de la acumulación de (VoteBankHash, UserBankHash). El 99,5% de los mejores validadores envían BankHash como parte de su votación cada 100 franjas horarias. Si bien se confirma cada 100 franjas horarias, se calcula en cada franja horaria. Vale la pena señalar que podría valer la pena que un pequeño porcentaje de nodos envíe constantemente BankHash en chismes como una señal suave sin observar nada no determinista.

Si menos del 67% de los validadores envían cálculos completos de BankHash, los líderes deben reducir el espacio de bloque disponible para las transacciones de los usuarios y las cuentas escriturables en un 50%. Esta medida es para proteger la cadena de abusos que podrían aumentar excesivamente el tiempo de repetición.

BankHash debe acumular BankHashes anteriores.

Ir al líder del banco

Durante la creación del bloque, es probable que el líder no pueda obtener el estado utilizado para crear el bloque, y no es ideal ejecutar todas las transacciones durante el período de creación del bloque.

• Los líderes mantienen un caché de saldos de cuentas pagadas.
• Si se utiliza una cuenta de pago como fuente para las transferencias del sistema, o como una cuenta de escritura que se transfiere junto con un programa del sistema a otro programa, el saldo de la cuenta de pago se establece en 0.
• Los bloques se empaquetan de acuerdo con las unidades de cómputo (CU) declaradas en orden de prioridad de tarifa local hasta que se llenan los bloques.
• Las tarifas se deducen de la caché de saldo de la cuenta pagada.
• El almacenamiento en caché del saldo de la cuenta pagada se complementa con los cálculos de BankHash.

La red incurre en un costo relativamente bajo por las fallas de spam en las transacciones, que consisten solo en los bytes almacenados en el archivo y el ancho de banda requerido para propagar las transacciones en el bloque.

Dado que los validadores ya buscan maximizar sus ganancias, tienen amplios incentivos para mantener un caché preciso de cuentas pagas. Además, si no hay ninguna penalización, cualquier persona en cualquier red puede servir fácilmente la caché a largo plazo. En caso de corrupción del servidor, un operador líder sin banco debe poder cambiar o muestrear fácilmente de múltiples fuentes.

Esto significa que, debido a la motivación de los validadores para maximizar las ganancias, se esforzarán por mantener un caché preciso de cuentas pagas. En ausencia de un mecanismo de penalización, esta caché puede ser servida por cualquier nodo de la red durante mucho tiempo. Además, si un servidor falla, un operador sin un líder bancario debería poder cambiar o muestrear fácilmente de múltiples fuentes.

Compensaciones

La principal desventaja es la falta de una firma de confirmación en el nodo completo que atiende el estado del usuario para confirmar que su estado de entrega es exactamente el mismo que el resto aprobado. La única explicación autorizada del estado debe seguir siendo la misma, incluso si cada transacción se reproduce secuencialmente en el libro mayor. Las optimizaciones de rendimiento no deben alterar los resultados. Por lo tanto, una vez finalizada la bifurcación, solo queda el estado correcto para calcular, siempre que la implementación en tiempo de ejecución esté libre de errores.

Los nodos diseñados para proporcionar un estado de forma confiable deben ejecutar varias máquinas y clientes y, si hay una discrepancia en la ejecución del estado, deben dejar de funcionar. Esto es esencialmente lo que los operadores deberían estar haciendo hoy en día, porque confiar únicamente en el resto de la red introduce la mayoría de las suposiciones de integridad.

Los usuarios también pueden firmar transacciones que afirmen un BankHash o desencadenen una anulación. El resto de la red ejecutará estas transacciones solo si el BankHash exacto calculado es exactamente el mismo que el BankHash proporcionado al usuario por el proveedor de RPC.

Hoja de ruta de nodos de consenso sin estado a largo plazo

Las redes con aprobaciones de tamaño fijo solo requieren una cantidad muy pequeña de estado para iniciarse. La aprobación en sí y el peso de su promesa, así como todos los saldos de las cuentas con derecho a voto. Se trata de una cantidad muy pequeña de memoria y un pequeño archivo de instantánea que se puede distribuir e inicializar rápidamente en un reinicio.

Si la aprobación no es coherente con el nodo completo, el nodo completo que realiza el seguimiento tanto de la aprobación como del estado dejará de ejecutarse. Esto significa que si hay un desacuerdo entre la aprobación y el estado, el intercambio, el canal fiduciario, el RPC, el puente, etc., dejarán de funcionar. Esto requiere solo un porcentaje muy pequeño de nodos de consenso sin estado defectuosos.

Los líderes sin bancos pueden confiar en una muestra de múltiples nodos completos para proporcionar un caché del saldo inicial de una cuenta paga. Incluso si es defectuoso, el resultado será spam en el bloque en lugar de una falla de consenso. Los operadores deben ser capaces de supervisar la salud de sus líderes y el porcentaje de spam que inyectan en sus bloques, y responder rápidamente a los fallos.