All Products
Search
Document Center

Transaction models for attestation

Last Updated: Jan 17, 2019

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

  1. TransactionDO tx = TransactionBuilder.getContentOnlyNotaryPayloadBuilder()
  2. .setContent(bizData)
  3. .setCategory(category)
  4. .setTimestamp(System.currentTimeMillis())
  5. .build();

Supported transaction builders

  1. // Get the link notary model builder
  2. TransactionBuilder.getLinkNotaryPayloadBuilder()
  3. // Get the content notary model builder
  4. TransactionBuilder.getContentOnlyNotaryPayloadBuilder()
  5. // Get the hash notary builder
  6. TransactionBuilder.getHashOnlyNotaryPayloadBuilder()
  7. // Get the ciphertext notary model builder
  8. TransactionBuilder.getEncryptNotaryPayloadBuilder()
  9. // Get the privacy sharing model builder
  10. TransactionBuilder.getEncryptShareNotaryPayloadBuilder()
  11. // Get the ciphertext-only notary model builder
  12. 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

  1. // Transaction structure version
  2. int version
  3. // Transaction type
  4. int type
  5. // A random number for ensuring the uniqueness of a transaction
  6. long nonce
  7. // Transaction content
  8. 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

  1. Content notary model
  2. 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.
  3. 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
  4. by using the link model.
  5. Notary structure
  6. - content: notary file content
  7. Type: byte[] (The blockchain does not have limits on encoding methods. Notary file content is encoded by the business itself.)
  8. Length: no more than 512 KB

HashOnlyNotaryPayloadDO

  1. Hash notary model
  2. 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
  3. write the hash value of that file to a blockchain.
  4. Notary structure
  5. - 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.
  6. 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.
  7. Type: byte[]
  8. Length: fixed 32 bytes

LinkNotaryPayloadDO

  1. Link notary model
  2. 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
  3. 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.
  4. Notary structure
  5. - link: the link to notary content, which can be a URI or other clues that can be used to locate a source file.
  6. Content: the URI of a source file, or other retrievable addresses
  7. 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.)
  8. Length: no more than 64 KB
  9. - 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.
  10. 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.
  11. Type: byte[]
  12. Length: fixed 32 bytes

EncryptNotaryPayloadDO

  1. Privacy notary model
  2. 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.
  3. Notary structure
  4. - contentHash: the hash value of the notarized plaintext content. The blockchain cannot restrict the hash of the notarized plaintext to this hash value.
  5. 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.
  6. Type: byte[]
  7. Length: fixed 32 bytes
  8. - 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.
  9. Type: byte[]
  10. Length: no more than 512 KB
  11. - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
  12. Type: byte[]
  13. Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long

EncryptShareNotaryPayloadDO

  1. Privacy sharing notary model
  2. 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.
  3. The key for encrypting the plaintext is disclosed after another private key has been used to wrap the key.
  4. 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.
  5. This encryption rule can be used for business design
  6. 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
  7. with specified persons to share the specified data.
  8. Notary structure
  9. - contentHash: the hash value of the notarized plaintext content. The blockchain cannot restrict the hash of the notarized plaintext to this hash value.
  10. 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.
  11. Type: byte[]
  12. Length: fixed 32 bytes
  13. - 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.
  14. Type: byte[]
  15. Length: no more than 512 KB
  16. - 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
  17. Type: byte[]
  18. Length: up to 512 bytes
  19. - 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.
  20. When used, the wrap key is decrypted by the private key to obtain the encrypted key, through which the ciphertext is decrypted.
  21. Type: byte[]
  22. Length: The model supports the antblockchain encryption library and limits the wrap key to 40 bytes.
  23. - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
  24. Type: byte[]
  25. Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long

EncryptContentOnlyNotaryPayloadDO

  1. Privacy notary model
  2. 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.
  3. Notary structure
  4. - 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.
  5. Type: byte[]
  6. Length: no more than 512 KB
  7. - nonce: An IV for encryption. Specify the randomly-generated IV when using AES for encryption, which is required for decryption later.
  8. Type: byte[]
  9. Length: less than or equal to 16 bytes. When the AES GCM algorithm is used, this value is usually 12 bytes long.