All Products
Search

This Product

    :Transaction models for attestation

    Document Center

    :Transaction models for attestation

    Last Updated:Jan 20, 2023

    The SDK implements a complete set of content notarization transaction models in accordance with the antblockchain-gl protocol, including transaction code, transaction verification, encryption suite, and transaction signing.

    TransactionBuilder

    In the SDK, we recommend that you use TransactionBuilder to build content notarization transactions.

    Different transaction models will obtain different builders to build transactions

    The following example builds a notary transaction

    TransactionDO tx = TransactionBuilder.getContentOnlyNotaryPayloadBuilder()
  .setContent(bizData)
  .setCategory(category)
  .setTimestamp(System.currentTimeMillis())
  .build();

    Supported transaction builders

    // Get the link notary model builder
TransactionBuilder.getLinkNotaryPayloadBuilder()
// Get the content notary model builder
TransactionBuilder.getContentOnlyNotaryPayloadBuilder()
// Get the hash notary builder
TransactionBuilder.getHashOnlyNotaryPayloadBuilder()
// Get the ciphertext notary model builder
TransactionBuilder.getEncryptNotaryPayloadBuilder()
// Get the privacy sharing model builder
TransactionBuilder.getEncryptShareNotaryPayloadBuilder()
// Get the ciphertext-only notary model builder
TransactionBuilder.getEncryptContentOnlyNotaryPayloadBuilder()

    Notary Transaction

    The following shows the properties of the Transaction. The payload sub-types of different types hold specific content. See For PayloadType for information about type mapping

    // Transaction structure version
int version

// Transaction type
int type

// A random number for ensuring the uniqueness of a transaction
long nonce

// Transaction content
Payload payload

    See sub-types for information about the types of payloads. Currently only the notary model is supported. The following are the payloads currently supported:

    • ContentOnlyNotaryPayloadDO
    • HashOnlyNotaryPayloadDO
    • LinkNotaryPayloadDO
    • EncryptContentOnlyNotaryPayloadDO
    • EncryptShareNotaryPayloadDO
    • EncryptNotaryPayloadDO

    The following are several critical Transaction methods:

    • Model encoding: marshal() encodes transactions and unmarshal() decodes transactions.
    • Transaction verification: verify() checks the validity of transactions according to the protocol.
    • Transaction hash: The getTxHash() model does not store hash. Instead, this method computes hash after transactions are serialized.

    ContentOnlyNotaryPayloadDO

    Content notary model
​
 If a source file needs to be notarized, you can write this source file to the blockchain. This model limits the source file size to no more than 512 KB.
 You can write notary files within this size limit to a blockchain. For notary files that are too large (such as images and videos), you can use LinkNotaryPayloadDO to store them in the blockchain
 by using the link model.
​
Notary structure
 - content: notary file content
 Type: byte[] (The blockchain does not have limits on encoding methods. Notary file content is encoded by the business itself.)
        Length: no more than 512 KB

    HashOnlyNotaryPayloadDO

    Hash notary model
​
 If you want to notarize a file and not write its source file to a blockchain, or a file is too large to be written to a blockchain, you can 
write the hash value of that file to a blockchain.
​
Notary structure
 - hash: the hash value of a source file. A hash value is obtained by computing the digest of the actual source file outside the blockchain.
        Hash algorithm: The blockchain cannot obtain the source file and cannot verify the validity of this hash. For this model, we recommend that you use sha-256 to limit the digest to a 256-bit value.
        Type: byte[]
 Length: fixed 32 bytes

    LinkNotaryPayloadDO

    Link notary model
​
 If you want to notarize a file and not write its source file to a blockchain, or a file is too large to be written to a blockchain, you can
write the hash value as well as the link to this file (the fixed URI of that file) to a blockchain. When retrieving data later, you can use this URI to find the source file.
​
Notary structure
 - link: the link to notary content, which can be a URI or other clues that can be used to locate a source file.
        Content: the URI of a source file, or other retrievable addresses
 Type: byte[] (A byte array is obtained after content strings are encoded. The blockchain does not verify this, nor does it limit encoding methods. Encoding is done by the business itself.)
 Length: no more than 64 KB
​
 - hash: the hash value of a source file. A hash value is obtained by computing the digest of an actual source file that is outside the blockchain and retrieved with a link.
        Hash algorithm: The blockchain cannot obtain the source file of a link and cannot verify the validity of the hash value. For this model, we recommend that you use sha-256 to limit the digest to a 256-bit value.
        Type: byte[]
 Length: fixed 32 bytes

    EncryptNotaryPayloadDO

    Privacy notary model
​
 If you want to notarize a file and not disclose its content, you can encrypt the source file through a symmetric encryption algorithm and then notarize it in the blockchain.
​
Notary structure
 - contentHash: the hash value of the notarized plaintext content. The blockchain cannot restrict the hash of the notarized plaintext to this hash value.
        Hash algorithm: The blockchain cannot obtain plaintext and cannot verify the validity of this hash. For this model, we recommend that you use sha-256 to limit the digest to a 256-bit value.
        Type: byte[]
 Length: fixed 32 bytes
​
 - encryptContent: the ciphertext of the source file. The encryption key and nonce encrypt the plaintext to obtain this value, and the encryption key and nonce decrypt the value to obtain the ciphertext value.
        Type: byte[]
 Length: no more than 512 KB
​
 - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
        Type: byte[]
 Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long

    EncryptShareNotaryPayloadDO

    Privacy sharing notary model
​
 If you want to notarize a file and not disclose its content, you can encrypt the source file through a symmetric encryption algorithm and then notarize it in the blockchain.
   The key for encrypting the plaintext is disclosed after another private key has been used to wrap the key.
 When you need to read the ciphertext data, the private key is needed to decrypt the wrapped key to get the key for the ciphertext before you can obtain the ciphertext data.
​
 This encryption rule can be used for business design
 For example, use the KDF algorithm to design a key tree, assign a proper private key to data according to data security levels, the scope of shared data and some other factors, and use this private key to encrypt data within a specific scope. Then you can simply share this key
 with specified persons to share the specified data.
​
Notary structure
 - contentHash: the hash value of the notarized plaintext content. The blockchain cannot restrict the hash of the notarized plaintext to this hash value.
        Hash algorithm: The blockchain cannot obtain plaintext and cannot verify the validity of this hash. For this model, we recommend that you use sha-256 to limit the digest to a 256-bit value.
        Type: byte[]
 Length: fixed 32 bytes
​
 - encryptContent: the ciphertext of the source file. The encryption key and nonce encrypt the plaintext to obtain this value, and the encryption key and nonce decrypt the value to obtain the ciphertext value.
        Type: byte[]
 Length: no more than 512 KB
​
 - keyName: the path for deriving the key using KDF. The parent node of the key tree can derive the path to the private key based on this path
 Type: byte[]
        Length: up to 512 bytes
​
    - keyWrap: the wrap key of the encrypted key. The encrypted key is randomly generated to encrypt the plaintext, and the key has a private key to be disclosed after the key wrap has been performed.
                When used, the wrap key is decrypted by the private key to obtain the encrypted key, through which the ciphertext is decrypted.
        Type: byte[]
        Length: The model supports the antblockchain encryption library and limits the wrap key to 40 bytes.
​
 - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
        Type: byte[]
 Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long

    EncryptContentOnlyNotaryPayloadDO

    Privacy notary model
​
 If you want to notarize a file and not disclose its content, you can encrypt the source file through a symmetric encryption algorithm and then notarize it in the blockchain.
​
Notary structure
    - encryptContent: the ciphertext of the source file. The encryption key and nonce encrypt the plaintext to obtain this value, and the encryption key and nonce decrypt the value to obtain the ciphertext value.
        Type: byte[]
 Length: no more than 512 KB
​
 - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
        Type: byte[]
 Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long.