Ciclo de vida de la transacción
Este es el ciclo de vida de la transacción para una transacción Stellar clásica. Agregar componentes de contrato inteligente a esta sección es actualmente un trabajo en progreso. Agregar componentes de contratos inteligentes a esta sección es actualmente un trabajo en progreso.
1. Creación (Creador de la transacción)
Un usuario crea una transacción configurando la cuenta fuente, el número de secuencia, la lista de operaciones y sus respectivos parámetros, la tarifa o tarifa adicional, y opcionalmente un memo y/o precondiciones.
2. Firma (Firmantes de la transacción)
Una vez que la transacción está completa, se convierte en un sobre de transacción que contiene la transacción en sí y una lista de firmantes. Todas las firmas requeridas deben ser recolectadas y añadidas a la lista de firmantes del sobre de transacción. Comúnmente, es solo la firma de la cuenta que realiza la transacción, pero configuraciones más complicadas pueden requerir recolectar firmas de múltiples partes. Todas las firmas requeridas deben ser recolectadas y agregadas a la lista de firmantes del sobre de la transacción. Comúnmente, es solo la firma de la cuenta que realiza la transacción, pero configuraciones más complicadas pueden requerir recoger firmas de múltiples partes.
3. Presentación (Presentador de la transacción)
Después de firmar, la transacción ahora puede ser presentada a la red Stellar. Si la transacción es inválida, será rechazada inmediatamente por Stellar Core, el número de secuencia de la cuenta no se incrementará, y no se consumirá ninguna tarifa de la cuenta fuente. Si la transacción es inválida, será rechazada inmediatamente por Stellar Core, el número de secuencia de la cuenta no se incrementará, y no se consumirá ninguna tarifa de la cuenta fuente. Se pueden enviar múltiples transacciones para la misma cuenta, siempre que cada número de secuencia sea diferente por uno (a menos que se hayan establecido precondiciones de número de secuencia mínimos). Si todas son válidas, Stellar Core elaborará un conjunto de transacciones con cada una de esas transacciones aplicadas en orden de número de secuencia. Las transacciones generalmente se envían utilizando Horizon, pero también puedes enviar la transacción directamente a una instancia de Stellar Core.
4. Propagando (Validador)
Una vez que Stellar Core ha determinado que una transacción es válida, propagará la transacción a todos los demás servidores a los que está conectado. De esta manera, una transacción válida se inunda a toda la red Stellar. De este modo, una transacción válida se inunda en toda la red Stellar.
5. Creando un conjunto de transacciones candidato (Validador)
Cuando es el momento de cerrar el ledger, cada validador de Stellar Core toma todas las transacciones válidas que conoce desde el último cierre del ledger y las recopila en un conjunto de transacciones candidato. Si escucha sobre alguna transacción entrante ahora, la pone a un lado para el próximo cierre del ledger. Si el número de operaciones en el conjunto de transacciones candidato es mayor que el número máximo de operaciones por ledger, las transacciones serán priorizadas por su tarifa para inclusión en el conjunto. Si escucha sobre cualquier transacción entrante ahora, las aparta para el próximo cierre de ledger. Si el número de operaciones en el conjunto de transacciones candidato es mayor que el número máximo de operaciones por ledger, las transacciones se priorizarán por su tarifa para inclusión en el conjunto.
6. Nominando un conjunto de transacciones (Validador)
Una vez que cada validador ha creado un conjunto de transacciones candidato, el conjunto es nominado a la red.
7. El Protocolo de Consenso Stellar (SCP) determina el conjunto final de transacciones (Red de Validadores)
SCP resuelve cualquier diferencia entre los conjuntos de transacciones candidato y finalmente determina un único conjunto de transacciones para aplicar, el tiempo de cierre del ledger y cualquier actualización al protocolo que necesite aplicarse en toda la red al momento de aplicar.
Si una transacción no llega al conjunto de transacciones, se mantiene en memoria para ser añadida al siguiente conjunto de transacciones en base a un esfuerzo de mejor intento.
Si una transacción se mantiene en memoria después de un cierto número de cierres del ledger, será prohibida para varios ledgers adicionales. Esto significa que no se intentará incluirla en un conjunto de transacciones candidato de ledgers adicionales durante este tiempo. Esto significa que no se hará ningún intento por incluirlo en un conjunto candidato de transacciones en ledgers adicionales durante este tiempo.
8. El orden de aplicación de las transacciones se determina (Red de Validadores)
Una vez que SCP acuerda un conjunto de transacciones particular, se calcula el orden de aplicación para el conjunto de transacciones. Esto mezcla el orden del conjunto para crear incertidumbre para las transacciones en competencia y mantiene el orden de los números de secuencia para múltiples transacciones por cuenta.
9. Se recogen las tarifas (Validador)
Las tarifas se recogen para todas las transacciones simultáneamente.
10. Aplicación (Validador)
Cada transacción se aplica en el orden previamente determinado. Para cada transacción, el número de secuencia de la cuenta se consume (aumentado en 1), se vuelve a verificar la validez de la transacción y se aplica cada operación en el orden en que ocurren en la transacción. Las operaciones pueden fallar en esta etapa debido a errores que pueden ocurrir fuera de la verificación de validez de la transacción y la operación. Por ejemplo, un saldo insuficiente para un pago no se verifica en la presentación y fallaría en este momento. La transacción completa fallará si alguna operación falla, y todas las operaciones anteriores serán revertidas.
11. Actualizaciones del Protocolo (Validador)
Finalmente, se ejecutan actualizaciones si se llevó a cabo una actualización. Esto puede incluir lógica arbitraria para actualizar el estado del ledger para actualizaciones del protocolo, junto con modificaciones de encabezado del ledger, incluyendo la versión del protocolo, la tarifa base, el número máximo de operaciones por ledger, etc. Una vez que esto se ha completado, el ciclo de vida comienza de nuevo.