Transacciones
Una transacción es una instrucción firmada a la cadena: pagar a alguien, emitir un token, colocar una orden, vincular una dirección a un grupo. ZooBC no tiene máquina virtual para código de usuario. Cada función es un tipo de transacción integrado con reglas fijas que todos los nodos aplican exactamente de la misma manera, así que una billetera sabe, antes de firmar, todo lo que puede hacer una transacción y cuál será su comisión mínima.
Tipos integrados
A partir de la versión 0.5.8 ZooBC define 73 números de tipo de transacción, incluido el tipo 0, en doce familias.
Un número de tipo es un grupo más 256 veces un subtipo, así que la numeración tiene huecos: 2 es NodeRegistration, y 258 (grupo 2, subtipo 1) es su actualización. Un número que la cadena no define se rechaza, y todos los tipos definidos se aceptan desde el bloque 1.
Dos números son especiales. El tipo 0, Empty, no mueve nada: existe para llevar un mensaje, debe pagar igualmente una comisión mayor que cero y no incrementa el nonce del remitente, el contador por remitente que lleva la cadena. El tipo 53, CancelLongevity, está retirado: todas las cadenas lo rechazan, y en su lugar se usa CloseLongevity (309).
La vida de una transacción
- Una billetera construye el sobre, con la misma estructura para todos los tipos, y lo firma para una cadena.
- Envía los bytes firmados con
POST /api/v1/transactions. HTTP 202 significa que el nodo aceptó la transacción en su conjunto de espera, no que esté en un bloque. Reenviar los mismos bytes no tiene riesgo: la copia se marca como duplicada. - Los nodos se pasan la transacción, y un productor de bloques la incluye. Un bloque contiene como máximo 2000 transacciones y 524 288 bytes de carga, y como máximo una transacción de cada cuenta (véase una transacción por cuenta y bloque, y los lotes).
GET /api/v1/transactions/<hash>/statusinforma de su avance: staging, mempool (con su posición), confirmed (con la altura del bloque), rejected (con el motivo) o not_found.
Una transacción que ningún bloque incluye dentro de su ventana caduca (véase caducidad y marcas de tiempo).
Cuando el estado cambia entre medias
Entre la firma y la inclusión en un bloque, otras transacciones pueden cambiar aquello de lo que depende una transacción: un escrow se liquida, otra persona acepta una oferta, un token caduca. Una transacción así se convierte en una operación nula pagada: se incluye en un bloque, paga su comisión y no cambia nada más. El bloque sigue siendo válido en todos los nodos, así que nadie puede bloquear la cadena enviando transacciones a punto de quedar obsoletas.
Un bloque solo es inválido por fallos que todos los nodos ven de la misma manera, como una firma incorrecta, una comisión por debajo del suelo (véase comisiones) o un pago mayor que el saldo del remitente.
Artículos de esta categoría
- El sobre de la transacción: los campos que lleva cada transacción, y su comisión.
- Firmar una transacción: el resumen vinculado a la cadena y los tipos de clave que pueden firmar.
- Caducidad y marcas de tiempo: cuánto tiempo sigue siendo válida una transacción firmada.
- Una transacción por cuenta y bloque, y los lotes: una transacción por cuenta y bloque, y los lotes.
- Escrow: pagos que la cadena retiene hasta que decide un aprobador.
- Multifirma: cuentas que solo gastan con varias firmas.
- Pagos líquidos (flujos): dinero que fluye hacia un destinatario a lo largo de minutos.
- Transferencias programadas: una serie de pagos firmados una sola vez.
- Disparadores y atestaciones: dinero liberado en una altura o tras un evento.
- Grupos de cuentas: muchas direcciones que comparten una cuenta.
Véase también
Artículos de este tema
- Caducidad y marcas de tiempo
Por qué toda transacción de ZooBC lleva su propia hora, cuánto tiempo sigue siendo válida (una hora por defecto, como máximo un día) y cómo usan el tiempo los bloques y las liquidaciones. - Disparadores y atestaciones
Cómo un disparador de ZooBC bloquea ZBC hasta una altura de bloque futura o hasta un evento del mundo exterior, y cómo los nodos registrados resuelven los eventos mediante atestaciones. - El sobre de la transacción
Los campos que lleva toda transacción de ZooBC, en orden, qué contiene cada uno y qué falta a propósito, como un límite de gas o un id de cadena. - Escrow
Cómo la cadena puede retener un pago de ZooBC hasta que decida un aprobador designado, sus cuatro finales posibles, lo que cuesta y las solicitudes de escrow emitidas por el beneficiario. - Firmar una transacción
Qué cubre una firma de ZooBC, cómo se derivan el hash y el id de una transacción, qué tipos de clave pueden firmar y cómo las billeteras de otras cadenas firman transacciones de su propia cadena. - Grupos de cuentas
Cómo un grupo de cuentas de ZooBC permite que muchas direcciones, de cualquier tipo de clave, compartan un solo saldo, con un controlador que decide lo que puede gastar cada miembro. - Multifirma
Cómo una cuenta multifirma de ZooBC solo gasta cuando ha firmado un número fijado de sus participantes, incluso cuando usan claves de cadenas distintas. - Pagos líquidos (flujos)
Cómo un pago líquido de ZooBC transmite ZBC o un token a un destinatario a lo largo de un número de minutos, y cómo cualquiera de las dos partes puede detenerlo con un reparto justo. - Transferencias programadas
Cómo una sola ScheduledTransfer de ZooBC establece una serie de pagos en ZBC o en un token, bloqueados por adelantado o tomados al vencer, y cómo puede cancelarse o redirigirse. - Una transacción por cuenta y bloque, y los lotes
Por qué un bloque de ZooBC solo puede llevar una transacción de cada cuenta, y cómo un lote permite a una cuenta hacer varios pagos o transferencias en una sola transacción.