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
- The application calls a blockchain node remotely to write data
- The blockchain node writes the data into the transaction pool
- The blockchain node returns the successful acceptance information
- The application saves the transaction hash and associates it with the local service configuration
- The blockchain completes the data consensus on the chain asynchronously
- The application queries blockchain transactions based on the transaction hash (proof of existence)
Content notary query
// Load the client configuration file
Properties p = new Properties();
p.load(new FileInputStream("sdk.properties"));
ClientConfig config = new ClientPropertyConfig(p);
// Initialize the client using the specified client configuration
Client client = new Client(config);
// Query according to tx hash
Response<TransactionDO> response =client.getTransaction("462da7df7c10f9b12137549b83bd77b7335cfdd5bf8a060013a111748b564e94");
if(response.isSuccess()){
TransactionDO tx = response.getData();
// Query succeeded
if(null == tx){
// The Tx does not exist on the chain
return null;
}
// Read the specific transaction content based on the transaction type
if (tx.getType() == PayloadType.TX_TYPE_NOTARY_CONTENT_ONLY.code) {
// Read content notary transaction
// case the payload type
ContentOnlyNotaryPayloadDO payloadDO = (ContentOnlyNotaryPayloadDO)tx.getPayload();
// do something about the payload
// ...
// read content
System.out.println(new String(payloadDO.getContent(), "UTF-8"));
// read biz time
System.out.println(payloadDO.getTimestamp());
}
return tx.getTxHashValue()
}else{
// The query is exceptional,
}
Block query
// Load the client configuration file
Properties p = new Properties();
p.load(new FileInputStream("sdk.properties"));
ClientConfig config = new ClientPropertyConfig(p);
// Initialize the client using the specified client configuration
Client client = new Client(config);
// Query the block height
Response<Block> response = client.getBlock(4);
if(response.isSuccess()){
// Query succeeded
if(null == response.getData()){
// The block does not exist on the chain
return null;
}
// read block
// ....
}
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:
- The application calls a blockchain node remotely to write data
- The blockchain node writes the data into the transaction pool, and returns successful acceptance information
- The blockchain completes data consensus on the chain asynchronously and issues block notifications
- Business systems subscribe to and receive the out-of-block notification from the blockchain node and pull blocks from the blockchain as needed
- Business systems process transaction data according to business requirements, format the storage, and index the related businesses
- The application queries data on the chain according to the attribute of the business data
Out-of-block event subscription
// Subscribe to the out-of-block event of the node and send a push block notification when the node generates a block
// The remote node calls back the Consumer when a block is generated and the out-of-block notification can be processed in the Consumer
// For subscribers with the same groupId, push notifications to only one of them
Response<Boolean> response = client.subscribeBlockEvent("group0", new Consumer<NewBlockEventBody>() {
@Override
public void accept(NewBlockEventBody body) {
// Obtain the block height
Long final_height = body.getHeight();
// Pull blocks and process transaction data to format storage
// ...
}
});
if(! response.isSuccess()){
// Subscription failed
// Process failed process
}
In addition to event subscription, the latest blocks can also be obtained through scheduled tasks.
@Scheduled(cron="* 1/1 * * * *")
public void fetchBlock() {
final Response<BlockHeader> blockHeader = client.getLatestBlockHeader();
if(! blockHeader.isSuccess()) {
LOGGER.error("Get block header fail: ", blockHeader.getErrorMsg());
return;
}
// Obtain the block height
long finalHeight = blockHeader.getData().getHeight();
// Pull blocks and process transaction data to format storage
// ...
}