All Products
Search
Document Center

Best practice

Last Updated: Jun 06, 2019

When an application uses a blockchain for data notarization, typically, it can be divided into two types of modes according to the application scenario

  • Data notary mode
  • Data access mode

Data notary mode refers to the use of the blockchain as a data notary system by taking advantage of the irreversibility, consensus timestamp, and other technical characteristics of the blockchain. In this mode, the application writes the critical business certificate information (such as contracts, payment vouchers, and other key business information) into the blockchain, saves the blockchain transaction hash stub, and regards the blockchain as a notary system. When proof is needed, the original data notarized before is queried according to the transaction hash of the blockchain to prove the existence of the business certificate information.

Data access mode refers to the use of the blockchain as a trusted distributed ledger by utilizing the irreversibility, distributivity, and other technical characteristics of the blockchain, to implement distributed business cooperations based on shared and trusted data ledgers. In this mode, the application writes the key business data into the blockchain, and multiple participants can query and retrieve the business data on the blockchain in real time according to the business data attributes.

The following are two common application interaction modes.

Data notary interaction mode

In the notary mode, the blockchain system serves as a notary system, stores the notary data of the business, and makes the data reach a consensus. The original notary data is queried from the blockchain according to the transaction hash when necessary.

Application interaction process

  1. The application calls a blockchain node remotely to write data
  2. The blockchain node writes the data into the transaction pool
  3. The blockchain node returns the successful acceptance information
  4. The application saves the transaction hash and associates it with the local service configuration
  5. The blockchain completes the data consensus on the chain asynchronously
  6. The application queries blockchain transactions based on the transaction hash (proof of existence)

Content notary query

  1. // Load the client configuration file
  2. Properties p = new Properties();
  3. p.load(new FileInputStream("sdk.properties"));
  4. ClientConfig config = new ClientPropertyConfig(p);
  5. // Initialize the client using the specified client configuration
  6. Client client = new Client(config);
  7. // Query according to tx hash
  8. Response<TransactionDO> response =client.getTransaction("462da7df7c10f9b12137549b83bd77b7335cfdd5bf8a060013a111748b564e94");
  9. if(response.isSuccess()){
  10. TransactionDO tx = response.getData();
  11. // Query succeeded
  12. if(null == tx){
  13. // The Tx does not exist on the chain
  14. return null;
  15. }
  16. // Read the specific transaction content based on the transaction type
  17. if (tx.getType() == PayloadType.TX_TYPE_NOTARY_CONTENT_ONLY.code) {
  18. // Read content notary transaction
  19. // case the payload type
  20. ContentOnlyNotaryPayloadDO payloadDO = (ContentOnlyNotaryPayloadDO)tx.getPayload();
  21. // do something about the payload
  22. // ...
  23. // read content
  24. System.out.println(new String(payloadDO.getContent(), "UTF-8"));
  25. // read biz time
  26. System.out.println(payloadDO.getTimestamp());
  27. }
  28. return tx.getTxHashValue()
  29. }else{
  30. // The query is exceptional,
  31. }

Block query

  1. // Load the client configuration file
  2. Properties p = new Properties();
  3. p.load(new FileInputStream("sdk.properties"));
  4. ClientConfig config = new ClientPropertyConfig(p);
  5. // Initialize the client using the specified client configuration
  6. Client client = new Client(config);
  7. // Query the block height
  8. Response<Block> response = client.getBlock(4);
  9. if(response.isSuccess()){
  10. // Query succeeded
  11. if(null == response.getData()){
  12. // The block does not exist on the chain
  13. return null;
  14. }
  15. // read block
  16. // ....
  17. }

Data access interaction mode

In the data access mode, the blockchain system is used as a distributed ledger, and multiple participants read and write the shared ledger together to complete distributed collaboration.

Data access system architecture

In order to meet the extended needs of diverse business scenaios, the blockchain architecture in the data access mode is divided into two layers

  • Blockchain
  • Business system

Blockchains complete data consensus and ledger storage, and provide transaction verification capabilities.

Business systems synchronize blockchain ledgers in real time, process transaction information on blocks according to business requirements, and complete customized business logic, data storage, and relevant indexing. Business systems can be deployed in clusters to provide stable and efficient query capabilities.

Overall interaction process:

  1. The application calls a blockchain node remotely to write data
  2. The blockchain node writes the data into the transaction pool, and returns successful acceptance information
  3. The blockchain completes data consensus on the chain asynchronously and issues block notifications
  4. Business systems subscribe to and receive the out-of-block notification from the blockchain node and pull blocks from the blockchain as needed
  5. Business systems process transaction data according to business requirements, format the storage, and index the related businesses
  6. The application queries data on the chain according to the attribute of the business data

Out-of-block event subscription

  1. // Subscribe to the out-of-block event of the node and send a push block notification when the node generates a block
  2. // The remote node calls back the Consumer when a block is generated and the out-of-block notification can be processed in the Consumer
  3. // For subscribers with the same groupId, push notifications to only one of them
  4. Response<Boolean> response = client.subscribeBlockEvent("group0", new Consumer<NewBlockEventBody>() {
  5. @Override
  6. public void accept(NewBlockEventBody body) {
  7. // Obtain the block height
  8. Long final_height = body.getHeight();
  9. // Pull blocks and process transaction data to format storage
  10. // ...
  11. }
  12. });
  13. if(! response.isSuccess()){
  14. // Subscription failed
  15. // Process failed process
  16. }

In addition to event subscription, the latest blocks can also be obtained through scheduled tasks.

  1. @Scheduled(cron="* 1/1 * * * *")
  2. public void fetchBlock() {
  3. final Response<BlockHeader> blockHeader = client.getLatestBlockHeader();
  4. if(! blockHeader.isSuccess()) {
  5. LOGGER.error("Get block header fail: ", blockHeader.getErrorMsg());
  6. return;
  7. }
  8. // Obtain the block height
  9. long finalHeight = blockHeader.getData().getHeight();
  10. // Pull blocks and process transaction data to format storage
  11. // ...
  12. }