11.3 Formato Transazione

11.3.1 Schema

  {
    "data": {
        "account": string,
        "nonce": bytes,
        "network": string,
        "contract": bytes,
        "method": string,
        "caller": {
          "type": string,
          "curve": string,
          "value": bytes,
        },
        "args": bytes,
    },
    "signature": bytes
  }

  • account: identificatore dell'account di destinazione (come definito here). Questo è l'account su cui verrà eseguito il metodo di contratto richiamato.

  • nonce: valore pseudo-casuale per la protezione anti-riproduzione. Consente di ottenere un hash diverso per le transazioni con lo stesso carico utile.

  • network: nome della rete blockchain. Blockchain con nomi diversi sono incompatibili. Ogni nodo è configurato per funzionare su una rete specifica.

  • contract: identificatore di smart contract definito come contrattowasm multihash.

  • method: nome della funzione dello smart contract da eseguire.

  • caller: identità del mittente della transazione utilizzata per la verifica della firma digitale e (facoltativamente) utilizzata dagli smart contract per prendere decisioni specifiche dell'applicazione:

    • type: identificatore dell'algoritmo di firma digitale (e.g. "ecdsa").
    • curve: identificatore della curva ecdsa (e.g. "secp284r1").
    • value: valore della chiave pubblica.

  • args: argomentazioni specifiche per smart contract. Queste informazioni sono opache al core e vengono trasmesse "così com'è" allo smart contract. Può essere qualsiasi cosa ed è un dovere di smart contract decodificare il contenuto nel modo che meglio si adatta all'applicazione (pacchetto di messaggi per impostazione predefinita).

  • signature: firma digitale del campo dati compresso del messaggio. Verificato utilizzando la chiave pubblica contenuta nel campo data stesso.

11.3.2 Esempio:

  {
    "data": {
      "account": "QmYHnEQLdf5....SPgdXrJWFh5W696HPfq7i",
      "nonce": 0102030405060708,
      "network": "skynet",
      "contract": 12202c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f9...,
      "method": "terminate",
      "caller": {
        "type": "ecdsa",
        "curve": "secp384r1",
        "value": 045936d631b849bb5760bcf62e0d1261b6b6e227dc0a389...
      },
      args: 82a46e616d65a4436f6c65a5656d61696cb263727573746e3440746f706c...
    },
    "signature": 69bc880acdab862ebbf776b5411b04b5e872369d3b40ca448832...
  }

11.3.3 Serializzazione dei dati

Le strutture delle transazioni sono codificate utilizzando il formato binario [MessagePack] (https://msgpack.org).

Entrambi i formati di serializzazione anonymous e named sono supportati dal core durante la convalida della transazione.

Quando si utilizza il formato anonimo, l'ordine dei campi è importante.

Quando si utilizza il formato denominato, l'ordine dei campi non è importante. In ogni caso, per ottenere le migliori prestazioni durante la fase di deserializzazione, è buona norma organizzare i campi nello stesso ordine descritto da questo documento.

11.3.4 Firma digitale dei dati

Steps:

  1. Il campo data viene serializzato come un array di byte.

    data_bytes = msgpack.serialize(data);

  2. I byte sono firmati digitalmente utilizzando la chiave privata del mittente.

    signature = ecdsa-sign(submitter-private-key, data_bytes);

  3. Il campo firma è aggiunto alla struttura precedente:

  transaction {
    "data": {
      ...
    },
    "signature": ...
  }

  1. La struttura complessiva della transazione viene serializzata utilizzando il formato MessagePack.

    tx_bytes = msgpack.serialize(transaction);

  2. I byte della transazione (tx_bytes) vengono infine inviati al nodo blockchain.

Importante: se la firma digitale è stata prodotta utilizzando un formato di serializzazione (anonimo o denominato), lo stesso formato sarà utilizzato durante la serializzazione della transazione complessiva per l'invio principale.