jakiro
Autor: Toly, Solana Labs Fuente conjunta: X,@Aeyakovenko Traducción: Shan Ouba, Bit Chain Vision Realm
En Solana, la organización estatal es un almacenamiento de valor de clave plana, y el programa ejecuta el valor de actualización en este estado, incluidos los procedimientos de votación clave para el consenso.El objetivo principal de la ejecución asincrónica es permitir que los procedimientos de votación operen independientemente de todos los demás programas.Para lograr siempre este objetivo, necesitamos garantizar varios principios clave.
Dominio de ejecución
El dominio de ejecución es un conjunto de procedimientos y sus claves y valores de operación, que son independientes entre sí durante la ejecución.El dominio de ejecución se puede ejecutar en diferentes hilos y núcleos, y se completa en diferentes momentos en varias máquinas.Lo importante es que un dominio de ejecución (por ejemplo, el dominio a) no puede leer o escribir ningún valor en otro dominio (por ejemplo, dominio b).Sin embargo, el dominio se puede compartir en un estado consistente durante la ejecución de cualquier dominio.Se requiere un protocolo para sincronizar el estado entre el campo y promover el movimiento de la clave y el valor.
La persona de pago de la tarifa de transacción determina el dominio de la ejecución de la transacción.
Dominio clave: Ved y Ued
En Solana, nos centramos principalmente en dos dominios: dominio de ejecución de votación (VED) y dominio de ejecución del usuario (UED).El objetivo es permitir que las verificaciones voten antes de que se realicen todos los programas de usuarios.
Componente VED
-
Programa del sistema: Para la transferencia
-
Variable del sistema del programa de votación: Variable del sistema del programa de votación para votar
-
Votación: Procedimiento de votación central.Este programa es estático y consistente, y debe estar disponible en UED y VED.
-
Autoridad votante: Cuenta con el derecho a votar
-
Pago de tarifas de votación: Cuentas que pagan tarifas relacionadas por votar
-
Fondo de Payer de costos: Se puede usar para mover SOL a la cuenta actualizada de Ved
-
Todas las demás cuentas se colocan en UED
Calcule el estado VED
En el límite de adiós entre N-1 y N, calcule el estado de VED del dominio N+1 cuando sea tiempo de ejecución.Este cálculo debe completarse antes de la época n.Los cálculos de UED deben comenzar después de que se complete la ERA N-1.
Estándar en estado de VED
-
Cuenta de votación: Paquete de más de 5000 SOL y estado activo.
-
Permisos de pagador de costos y votación, fondos de pagadores de gastos: Asociado con la cuenta de votación anterior.
-
La cuenta de votación recién creada se estableció inicialmente como activa.Los usuarios deben activar estas cuentas.Los usuarios pueden detener la cuenta, y la cuenta se eliminará del estado VED en la era N+1.
Mover fondos en VED
Las cuentas de fondos declaradas en la cuenta de votación se pueden usar para mover fondos en VED.Después de actualizar el costo de pago en la cuenta de votación, el Fondo de Payer de Gastos actual permanecerá activo antes del final de la próxima era.Una vez que la activación de VED calculada con referencia, el nuevo fondo de pago de costos ingresará al estado VED y se puede utilizar para agregar SOL adicional al pago de costos.El Fondo de pago de costos antiguos ingresará al estado de UED, por lo que los fondos pueden transferirse a la cuenta en la UED.
Aunque se puede fusionar con el pagador de gastos, para minimizar el número de firmas utilizadas para cada votación, el pago de costos generalmente se establece en el mismo valor que los permisos de votación. y UED.
Dominio de ejecución universal
El método anterior está muy dirigido a los procedimientos de votación.Este método puede promover aún más al dominio de ejecución de cualquier número.Rastreo de cuentas El dominio de ejecución se asigna, al igual que el programa de gestión del sistema operativo rastrea VMID en la página física.Para este proyecto específico, una pequeña parte del mapeo es útil:
-
Rx-acompañamiento: Leer y ejecutar en UED
-
Rx-achapado: Leer y ejecutar en UED y Ved
-
Rw-ved: Leer y escribir en Ved
-
Rw-ood: Leer y escribir en UED
Dado que la cuenta no puede leer y escribir al mismo tiempo en múltiples dominios, otro mapeo no es válido.
-
programa: Solo se puede asignar como rx-uy o rx-uy-ved, es decir, legible y ejecutable en usuarios o dos dominios, pero no se puede escribir.Cualquier transacción que incluya el programa debe fallar.
-
Cuenta: Solo MAP o RW-OED solo se puede mapear.
Instantánea del sistema Configure el programa de votación y el programa del sistema a RX-OD-Ved.El programa del sistema proporciona una cuenta de la cuenta del sistema y al programa de votación a VED y interfaces móviles de VED.La actualización real aún requiere una era completa para activar.
Solo cuando el programa del propietario se encuentra en el dominio objetivo, la cuenta puede reiniciarse entre los dominios.Por lo tanto, solo las cuentas del programa de votación y el programa del sistema pueden moverse entre VED y UED.
Después de usar el método general, no se necesita una cuenta de fondos de pago de costo explícito.Los desarrolladores pueden rehacer cualquier cuenta del sistema entre VED y UED para mover fondos entre dominios.
Calcula el hash Ved
Después de recibir el bloque, el nodo ejecuta todas las transacciones.El proceso es el siguiente:
-
La ejecución implica solo transacciones que involucran cuentas VED.
-
La transacción del pago de costos de VED pero una cuenta mixta falló.
-
Omita todas las demás transacciones.
La actualización de estado VED generada se utiliza para calcular el hash del banco, es decir, hash hash.Las verificaciones ahora pueden votar con Ved Hash en lugar del antiguo hash del banco.Si hay una actualización de hash UED desde la última votación de la bifurcación, el hash y el espacio se incluirán en la votación.
Calcular el hash UED
Después de recibir el bloque, el nodo procesa todas las transacciones:
-
Las cuentas que no están en VED se consideran parte de UED.
-
La ejecución implica solo transacciones que involucran cuentas UED.
-
La transacción que contiene pagos de gastos UED pero una cuenta mixta falló.
-
Omita todas las demás transacciones.
La actualización de estado de UED generada se utiliza para calcular el hash del banco, el hash UED.
Último
El sexo final permanece sin cambios.
Código de estado de ejecución de transacciones
Los efectos secundarios de la ejecución asincrónica pueden no detectarse inmediatamente al votar.Si 1/3 o más verificaciones presentan un hash diferente UED, todos los nodos deben detener la confirmación y los operadores de votación y advertir.
Para obtener el código de estado, la solicitud de API RPC debe permitir a los usuarios especificar la promesa observada por la misma observación de hash UED.El estado de ejecución se puede expresar como ejecutorStatus (firma, compromiso = x), donde x puede ser 0 o un cierto valor predeterminado.En la configuración de múltiples nodos y clientes, el valor X es aceptable para 0, lo que trae a los usuarios la confianza que no está confirmada e imposible.
No determinista es la única falla que debe detectarse antes de devolver el código de estado de las transacciones confirmadas al usuario.
Líder y generación de bloques
Los líderes deben poder comenzar a crear bloques inmediatamente después de completar el VED.Esto significa que el líder tendrá parte del estado e información incompleta de cualquier pago de costos de UED.
-
Los líderes ejecutan el dominio VED solo para los bloques que crearon
-
La carga de UED debe omitir el pago de costo no válido
Activación funcional de los procedimientos de votación
El programa de votación debe diseñarse cuando la votación de VED puede cruzar el límite de la época cuando se activa la función y opera el tiempo de otras transacciones que están en contacto con el programa de votación en el UED.
otorgar
Solo en las cuentas de votación de Ved deben ser recompensadas.
castigar
Todas las cuentas de votación corren el riesgo de ser castigados si están activos o VED.
Actualización global de reloj
La variable del sistema de reloj se actualiza mediante la votación.El método alternativo debe usarse.Por el contrario, cada líder de bloque puede mover el reloj hasta 1 segundo delantero.Al menos el 40%de la red requiere malicia, y los relojes pueden crecer más rápido que el tiempo real.El reloj también puede avanzar por 400 milisegundos por defecto.Suponiendo la deriva de 50 milisegundos, solo el 12.5%de los líderes deben ajustar el reloj para mantener la sincronización.
