Transactions
Una transaction es la unidad atómica de cambio en ULedger. Toda mutación del estado de la cadena - crear una billetera, invocar un contrato, transferir tokens, actualizar una entity - es una transaction firmada.
Estructura de la transaction
| Campo | Descripción |
|---|---|
type | El tipo de transaction (p. ej., CREATE_WALLET, INVOKE_SMART_CONTRACT). Determina qué procesador la gestiona. |
sender | La dirección de la billetera que envía la transaction. |
signature | Firma criptográfica sobre el payload usando la clave privada del remitente. |
payload | Campos específicos del tipo (dirección del contrato, nombre de la función, argumentos, monto de tokens, etc.). |
Ciclo de vida
CONSTRUCT El SDK construye el payload (tipo, campos, dirección del remitente)
SIGN El SDK firma el payload con la clave privada del remitente
SUBMIT HTTP POST a cualquier nodo → pool de pendientes
GOSSIP El nodo transmite a los pares mediante GossipSub (libp2p)
VALIDATE Las verificaciones de autorización se ejecutan durante la propuesta del bloque
EXECUTE El procesador de bloques ejecuta: actualiza billeteras, entities, contratos
COMMIT Bloque finalizado, estado escrito en BadgerDB + archivos sidecar
CONFIRM El SDK consulta el recibo, se verifica la consistencia entre nodos
Verificaciones de autorización (pasos VALIDATE y EXECUTE):
- La cadena de ancestros de la entity del remitente debe estar completamente habilitada.
- La cadena de gobernanza de la entity destino respeta las listas negras.
- Las billeteras restringidas por capability se verifican contra las capabilities que poseen.
- El vencimiento de la capability se evalúa al momento de la ejecución (comparación de altura de bloque).
Categorías de transactions
ULedger admite más de 60 tipos de transaction en los siguientes dominios:
| Dominio | Ejemplos |
|---|---|
| Gestión de billeteras | CREATE_WALLET, ALTER_WALLET |
| Gestión de entities | CREATE_ENTITY, ALTER_ENTITY, LINK_WALLET_TO_ENTITY |
| Smart contracts | DEPLOY_CONTRACT, INVOKE_SMART_CONTRACT |
| Tokens | MINT_TOKEN, TRANSFER_TOKEN, BURN_TOKEN |
| Identidad | CREATE_DID, ISSUE_CREDENTIAL, REVOKE_CREDENTIAL |
| Recuperación | CONFIGURE_ENTITY_RECOVERY, APPROVE_ENTITY_RECOVERY |
| Datos | DATA_TX (payload arbitrario anclado on-chain) |
| Gobernanza del council | ADD_COUNCIL_MEMBER, FINALIZE_PROPOSAL |
Inmutabilidad
Una vez que una transaction se confirma en un bloque finalizado, no puede alterarse ni eliminarse. El bloque está:
- Encadenado mediante Merkle al bloque anterior.
- Incluido en la prueba de checkpoint Helix STARK de su época.
- Replicado en cada nodo del council.
Cualquier intento de alterar el registro invalida tanto la cadena Merkle como la prueba STARK.
Referencias detalladas
- Referencia de tipos de transaction - catálogo completo con todos los campos y reglas de procesamiento
- Operaciones de transactions en el SDK de Go
- Arquitectura: ciclo de vida de la transaction