Operaciones y transacciones

Operaciones y transacciones: cómo funcionan

Para realizar acciones con una cuenta en la red Stellar, compones operaciones, las agrupar en una transacción y luego firmas y envías la transacción a la red. Las transacciones de contratos inteligentes (aquellas con operaciones InvokeHostFunctionOp, ExtendFootprintTTLOp o RestoreFootprintOp) pueden tener solo una operación por transacción.

Operaciones

Las operaciones son comandos individuales que modifican el ledger. Las operaciones se usan para enviar pagos, invocar una función de contrato inteligente, ingresar órdenes en el exchange descentralizado, cambiar configuraciones en cuentas y autorizar cuentas para mantener activos.

Todas las operaciones caen en una de tres categorías de umbral: bajo, medio o alto, y cada categoría de umbral tiene un peso entre 0 y 255 (que se puede determinar usando set_options). Los umbrales determinan qué peso de firma se requiere para que la operación sea aceptada. Por ejemplo, digamos que una cuenta establece el peso de umbral medio en 5. Si la cuenta quiere establecer con éxito una línea de confianza con la operación changeTrust, el peso de la firma debe ser mayor o igual a 5.

Para aprender más sobre el peso de la firma, consulta la Entrada de la Enciclopedia de Firma y Multifirma.

Consulta una lista completa de las operaciones de Stellar y sus niveles de umbral en la sección de Lista de Operaciones.

Transacciones

La red Stellar codifica transacciones usando un protocolo estandarizado llamado Representación de Datos Externos (XDR). Puedes leer más sobre esto en nuestra Entrada de la Enciclopedia de XDR.

Las cuentas solo pueden realizar una transacción a la vez.

Las transacciones comprenden un paquete de entre 1 y 100 operaciones (excepto las transacciones de contratos inteligentes, que solo pueden tener una operación por transacción) y son firmadas y enviadas al ledger por las cuentas. Las transacciones siempre necesitan ser autorizadas por la clave pública de la cuenta de origen para ser válidas, lo que implica firmar el objeto de la transacción con la clave secreta asociada a la clave pública. Una transacción más su(s) firma(s) se llama sobre de transacción.

Una transacción puede necesitar más de una firma: esto ocurre si tiene operaciones que afectan a más de una cuenta o si tiene un peso de umbral alto. Consulta la Entrada de la Enciclopedia de Firma y Multifirma para más información.

Las transacciones son atómicas. Esto significa que si una operación en una transacción falla, todas las operaciones fallan y la transacción completa no se aplica al ledger.

Las operaciones se ejecutan para la cuenta de origen de la transacción a menos que se defina una anulación de operación.

Las transacciones de contratos inteligentes también pasan por un proceso de simulación donde los desarrolladores pueden probar cómo se ejecutaría la transacción en la red usando el punto final RPC simulateTransaction. Lee más en la documentación de Soroban.

Atributos de la transacción

Validez de la transacción y operación

Antes de ser enviadas con éxito a la red Stellar, las transacciones pasan por varias verificaciones de validez. Estas verificaciones se agrupan en tres categorías:

Precondiciones (opcional)

Las precondiciones se verifican primero.

Todas las precondiciones son opcionales. Se recomienda establecer límites de tiempo, pero las otras precondiciones se utilizan en circunstancias más especializadas. Puedes establecer múltiples precondiciones siempre que la combinación tenga sentido lógicamente.

Límites de tiempo

Válido si está dentro de los límites de tiempo establecidos de la transacción

Los límites de tiempo son una marca de tiempo UNIX opcional (en segundos), determinada por el tiempo del ledger, de un límite inferior y superior de cuándo será válida una transacción. Si una transacción se presenta demasiado temprano o demasiado tarde, no podrá entrar en el conjunto de transacciones.

Establecer límites de tiempo en las transacciones se recomienda encarecidamente, y muchos SDK los imponen.

Si maxTime es 0, no se establecen límites de tiempo superiores. En este caso, si una transacción no llega al conjunto de transacciones, se mantiene en memoria y trata de llegar continuamente al siguiente conjunto de transacciones. Debido a esto, recomendamos que todas las transacciones se creen con límites de tiempo para invalidar transacciones después de un cierto período, especialmente si planeas reenviar tu transacción más tarde.

Límites del ledger

Válido si está dentro de los límites del ledger establecidos de la transacción

Los límites del ledger se aplican a los números del ledger. Con estos definidos, una transacción solo será válida para los números del ledger que caigan dentro del rango determinado.

El límite inferior es inclusivo (menor o igual a) mientras que el límite superior no lo es (solo mayor que).

Si el límite superior se establece en 0, esto indica que no hay límite superior.

Número de secuencia mínimo

Si se establece un número de secuencia mínimo, la transacción solo será válida cuando el número de secuencia de su cuenta de origen (llámalo S) sea lo suficientemente grande. Específicamente, es válida cuando S satisface minSeqNum <= S < tx.seqNum.

Si se omite esta precondición, se aplicará el comportamiento predeterminado: el número de secuencia de la transacción debe ser exactamente uno mayor que el número de secuencia de la cuenta.

Ten en cuenta que después de que se ejecute una transacción, la cuenta siempre establecerá su número de secuencia en el número de secuencia de la transacción.

Edad mínima de secuencia

La transacción es válida después de que transcurra una duración particular (expresada en segundos) desde que se tocó la edad del número de secuencia de la cuenta.

La edad de secuencia mínima es una precondición relacionada con el tiempo, pero a diferencia de los límites de tiempo, que expresan tiempos absolutos, la edad de secuencia mínima es relativa a cuándo se tocó el número de secuencia de la cuenta de origen de la transacción.

Gap mínimo de secuencia

Válido si se presenta en un ledger que cumpla o exceda la edad del número de secuencia de la cuenta de origen

Esto es similar a la edad mínima de secuencia, excepto que se expresa como un número de ledgers en lugar de una duración de tiempo.

Firmantes adicionales

Válido si se presenta con firmas que cumplan con cada uno de los firmantes adicionales

Una transacción puede especificar hasta dos firmantes adicionales como precondición, lo que significa que debe tener firmas que correspondan a esos firmantes adicionales, incluso si esas firmas no serían requeridas de otra manera para autorizar la transacción (es decir, para su cuenta de origen u operaciones).

Los firmantes adicionales pueden ser de cualquier tipo además del firmante preautorizado de la transacción, ya que para preautorizar una transacción, necesitas conocer su hash, pero el hash debe incluir a los firmantes adicionales. Esta relación Catch-22 significa que incluir este tipo de firmante adicional devolverá un error.

Validez de la operación

Cuando se presenta una transacción a un nodo, el nodo verifica la validez de cada operación en la transacción antes de intentar incluirla en un conjunto de transacciones candidatas. Estas verificaciones iniciales de validez de operaciones están destinadas a ser rápidas y simples, con verificaciones más intensivas después de que se hayan consumido las tarifas. Para que una operación pase esta verificación de validez, debe cumplir con las siguientes condiciones:

Las firmas en la transacción deben ser válidas para la operación

Las firmas son de firmantes válidos para la cuenta de origen de la operación. El peso combinado de todas las firmas para la cuenta de origen de la operación cumple con el umbral para la operación.

La operación debe estar bien formada

Normalmente esto significa verificar los parámetros de la operación para ver si están en un formato válido. Por ejemplo, solo se pueden establecer valores positivos para el monto de una operación de pago.

La operación debe ser válida en la versión actual del protocolo de la red

Las operaciones obsoletas, como la inflación, son inválidas por diseño.

Validez de la transacción

Finalmente, se llevan a cabo las siguientes verificaciones de transacción:

Cuenta de origen

La cuenta de origen debe existir en el ledger.

Tarifa

La tarifa debe ser mayor o igual a la tarifa mínima de la red para el número de operaciones presentadas como parte de la transacción. Esto no garantiza que la transacción se aplique, solo que es válida. Además, la cuenta de origen debe poder pagar la tarifa especificada. Si se presentan múltiples transacciones pero solo un subconjunto de ellas puede ser pagado, se verifican su validez en orden de número de secuencia.

Aumento de tarifa (si corresponde)

Consulta la validez de la Sección de Transacciones de Aumento de Tarifa

Número de secuencia

El número de secuencia debe ser uno mayor que el número de secuencia almacenado en la entrada de la cuenta de origen cuando se aplica la transacción, a menos que se establezcan precondiciones del número de secuencia. Al verificar la validez de múltiples transacciones con la misma cuenta de origen en un conjunto de transacciones candidatas, todas deben ser transacciones válidas y sus números de secuencia deben ser desfasados por uno. Luego se ordenan y aplican de acuerdo con su número de secuencia.

Lista de operaciones

Cada operación debe pasar todas las verificaciones de validez para una operación, descritas en la sección de Validez de Operación anterior.

Lista de firmas

Cumplir con los requisitos de firma para cada operación en la transacción
La frase secreta de la red apropiada es parte del hash de la transacción firmado por cada firmante
El peso combinado de las firmas para la cuenta de origen de la transacción cumple con el umbral bajo para la cuenta de origen.

Memo (si corresponde)

El tipo de memo debe ser un tipo válido, y el memo mismo debe adherirse al formato del tipo de memo.