Sposta valore. Sposta dati. Alle tue condizioni.
Una transazione ZooBC è una busta firmata che racchiude un piccolo corpo tipizzato. La busta è identica per ogni tipo; il corpo e alcuni modificatori facoltativi decidono cosa accade davvero: un semplice invio, un trasferimento di token, uno stipendio in vesting, un accordo in escrow, una mossa in un'app, un trigger programmato. Questa è la mappa completa.
01Anatomia di una transazione
Tutto viene serializzato in little-endian in un unico buffer di byte, poi firmato. I campi blu sono la busta (uguale per tutti i tipi); il corpo viola è ciò che cambia da un tipo all'altro.
Un indirizzo di account è tipo di 4 byte (LE) + chiave pubblica: 00000000+32B ed25519 per ZBC, 04000000+ETH, 05000000+BTC e così via. Un destinatario mancante viene scritto con il tipo vuoto 02000000. La coda messaggio è dove un semplice invio porta la sua causale: il corpo di un SendZBC è solo l'importo; destinatario e causale stanno nella busta.
02Firma
Il tipo di account determina sia il prefisso dell'indirizzo sia lo schema di firma. Si firma l'intera busta (senza il campo della firma), preceduta dal tag di firma e dall'hash di genesis. Tutti e tre gli schemi sono deterministici, quindi un wallet nel browser e il nodo concordano byte per byte.
ZooBC (ed25519) · tipo 00000000
// digest, then sign digest = SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes) sig = ed25519(digest, privkey) // 64 bytes
È anche lo schema di Solana, Cardano, Tezos e Polkadot: stessa chiave ed25519, prefisso dell'indirizzo e codifica di visualizzazione diversi.
Ethereum (secp256k1) · tipo 04000000
// recoverable ECDSA, low-s digest = keccak256(SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes)) r,s,v = secp256k1.sign(digest) sig = r ‖ s ‖ (v+27) // 65 bytes
MetaMask può anche inviare il proprio RLP firmato; il nodo ricava il mittente e lo converte in un trasferimento ZBC.
Bitcoin (secp256k1) · tipo 05000000
// double-sha over the SHA3 payload digest = SHA256d(SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes)) sig = secp256k1.sign(digest) field = [len(2)] ‖ compressedPub(33) ‖ sig
La commissione, in breve
La commissione minima dipende dalla dimensione: una tariffa base × la scala delle commissioni della rete, più una componente per byte legata ad archiviazione e durata. Leggila in tempo reale da https://zoobc.network/api/v1/blockchain/fee-params oppure calcola il prezzo esatto di una tx con /estimate-fee, così il wallet non è mai in disaccordo con il nodo, nemmeno di un'unità atomica. In un invio a commissione precisa l'eccedenza viene rimborsata.
Il digest legato alla chain (versione di firma 2)
Dalla versione v0.4.0 del nodo il termine più interno è lo stesso in tutti e tre gli schemi, perché il nodo calcola quel digest una sola volta e lo passa allo schema di firma selezionato dal tipo di account.
- "ZBC-TX" è composto da sei byte ASCII senza terminatore: 5a 42 43 2d 54 58.
- genesis_hash è costituito dai 32 byte grezzi del blocco 0 della chain per cui si sta firmando.
Leggi genesis_hash da GET /api/v1/node/info; la stessa risposta contiene signing_version: 2 e signing_tag: "ZBC-TX". Non inserirlo mai nel codice in modo fisso: cambia ogni volta che una rete di test viene rilanciata.
Includere l'hash di genesis nel digest è ciò che rende una firma valida su una sola rete, così una transazione firmata per una chain di test non può essere riutilizzata su un'altra. Firmare il semplice SHA3_256(txBytes) corrisponde alla versione di firma 1 e il nodo la rifiuta con:
Invalid transaction signature: legacy unbound digest (signing v1); this chain requires signing v2
03I tre tipi di moneta
Gli importi sono sempre in unità atomiche (1 ZBC = 100,000,000). L'unica cosa che cambia tra una moneta e l'altra è il campo token_id: la meccanica dei movimenti è identica.
① ZBC nativo
token_id = 0 ovunque. La moneta per gas e commissioni, le ricompense di blocco, lo staking. Un SendZBC (tipo 1) è il percorso semplice.
② Token Genesis / bridge
Asset esterni wrapped coniati alla genesis (ZBTC, ZETH, ZSOL…). Sono normali token colorati con un token_id fisso assegnato nella configurazione di genesis: nulla di speciale a livello di protocollo.
③ Token emessi dagli utenti
Chiunque può coniarne uno con IssueToken (tipo 10): simbolo, offerta, decimali, copertura in ZBC facoltativa. Il suo token_id deriva dalla tx di emissione. Valgono gli stessi TransferToken / MintToken / BurnToken.
Ovunque un corpo abbia un token_id (trasferimento, swap, stake nelle app, pagamento liquido, vesting…), passa 0 per ZBC oppure l'id del token per una moneta colorata. I token con copertura possono persino pagare la propria commissione (flag fee_in_token), valutata in base alla loro copertura in ZBC.
04Modificatori: un pagamento, tante forme
Oltre ai tipi di base, quattro wrapper di tempistica e fiducia cambiano quando e se i fondi arrivano davvero. Sono loro a rendere la superficie così ampia.
Escrow
Aggiungi una sezione escrow alla busta di qualsiasi tx di valore (approvatore · commissione · timeout · istruzione). I fondi restano trattenuti finché l'approvatore designato non firma ApprovalEscrow (tipo 4) per rilasciarli o rifiutarli, oppure finché non scade il timeout. Un accordo condizionato sopra qualsiasi trasferimento.
Liquido
LiquidPayment (tipo 6): un singolo pagamento differito su una finestra temporale. Il destinatario riceve l'importo intero quando la finestra si chiude, oppure una quota proporzionale se il mittente lo interrompe in anticipo con LiquidPaymentStop (tipo 262). Breve termine (ore), ZBC o token.
Programmato / In vesting
ScheduledTransfer (tipo 29): rilascio in tranche a tempo, vesting (fondi prebloccati) o stipendio ricorrente (prelevato a ogni periodo). Cliff, revoca, rifiuto del destinatario, riassegnazione. Lungo termine (settimane–anni). I rilasci compaiono come movimenti del registro, non come nuove tx.
Trigger / Stop
Il timer leggero: CreateTrigger (15) blocca un importo da erogare a un'altezza futura; CancelTrigger (16) lo rimborsa. Per fermare quelli lunghi: CancelSchedule (30) revoca/rifiuto, LiquidPaymentStop (262).
Si combinano. Uno stipendio mensile anche in escrow, un'assegnazione in vesting in un token colorato: le primitive si compongono. (La composizione completa di ricorrente con escrow è nella roadmap; i mattoni ci sono già tutti oggi.)
05Mantenere in vita gli oggetti dati
Gli oggetti on-chain che contengono dati, i dataset (profili chiave/valore, chat, moduli aziendali) e i token, pagano un canone per restare in vita. «Aggiungere fondi a un oggetto» significa ricaricarne il finanziamento di sopravvivenza.
Dataset e file → archiviazione prepagata
Scrivi dati con SetupAccountDataset (tipo 3, una coppia proprietà → valore) o archivi un file con DFSCreateFile (8). Ogni blocco addebita il canone di archiviazione sull'archiviazione prepagata del tuo account; quando si esaurisce, l'oggetto viene eliminato. Ricaricala con AddPrepaidStorage (tipo 9): il corpo è solo un importo, accreditato direttamente sul saldo di archiviazione prepagata. Più prepagato = vita più lunga.
Token → finanziamento della persistenza
Anche un token colorato paga per sopravvivere. FinanceToken (tipo 14) estende l'orizzonte di persistenza di un token tramite la commissione, allungando il tempo in cui resta attivo prima che la copertura inutilizzata torni al creatore. Stessa idea, per singolo token.
06Catalogo completo delle transazioni
Tutti i 50 tipi di transazione, con la struttura esatta del corpo in little-endian. moneta = supporta token_id · modificabile = accetta una sezione escrow · nuova chain = a livello di consenso (arriva con il lancio di una chain).