CN111475522A

CN111475522A - Block chain-based warehouse receipt data management method and device and electronic equipment

Info

Publication number: CN111475522A
Application number: CN202010586339.XA
Authority: CN
Inventors: 韩喆; 张鸿
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-06-24
Filing date: 2020-06-24
Publication date: 2020-07-31

Abstract

Disclosed are a block chain-based warehouse receipt data management method and device and electronic equipment, wherein the method comprises the following steps: receiving a first target transaction sent by a warehousing party; the first target transaction comprises warehousing data of the goods and a contract address of the intelligent contract, wherein the warehousing data of the goods and the contract address of the intelligent contract are acquired by sensing hardware carried in the warehousing space; after the first target transaction is passed, responding to the first target transaction, calling and deploying the warehousing check logic in the intelligent contract corresponding to the contract address, and checking the warehousing data; and after the warehousing data passes the verification, further calling the state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse receipt data stored in the block chain into a warehousing state, so that when the bank side determines that the warehouse receipt data is modified into the warehousing state, the warehouse receipt data is used as a warranty to release a loan to the supplier side.

Description

Block chain-based warehouse receipt data management method and device and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for managing data of a manifest based on a block chain, and an electronic device.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

The specification provides a warehouse slip data management method based on a block chain, which is applied to a warehouse slip data management system built based on a block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the blockchain; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the method comprises the following steps:

Receiving a first target transaction sent by a warehousing party; the first target transaction comprises warehousing data of the goods and a contract address of the intelligent contract, wherein the warehousing data of the goods and the contract address of the intelligent contract are acquired by sensing hardware carried in the warehousing space;

Sending the first target transaction to other node equipment in the block chain, and performing consensus processing on the first target transaction;

After the first target transaction is passed, responding to the first target transaction, calling the warehousing verification logic in the intelligent contract corresponding to the contract address, and verifying the warehousing data;

And after the warehousing data passes the verification, further calling the state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse receipt data stored in the block chain into a warehousing state, so that when the bank side determines that the warehouse receipt data is modified into the warehousing state, the warehouse receipt data is used as a warranty to release a loan to the supplier side.

Optionally, the intelligent contracts are deployed to the blockchain by the supplier side; the intelligent contract comprises a white list with the authority of calling the intelligent contract to update the state of the warehouse receipt data; the white list includes warehousing parties, supplier parties, and banking parties associated with the manifest data. Further comprising:

Deploying the smart contract into the blockchain in response to a second target transaction sent by a supplier; and the warehousing party, the supplier and the bank party related to the pledge data have white list authority for calling the intelligent contract to modify the contract state.

Optionally, the code logic further includes warehouse-out checking logic for the manifest data, further including:

Receiving a third target transaction sent by a warehousing party after goods corresponding to the manifest data are extracted from the warehousing space by a supplier party; the third target transaction comprises the outbound data of the goods and the contract address of the intelligent contract, which are acquired by sensing hardware carried by the warehousing space;

Responding to the third target transaction, calling the ex-warehouse verification logic in the intelligent contract corresponding to the contract address, and verifying the ex-warehouse data;

And after the warehouse-out data passes the verification, further calling the state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse entry data stored in the block chain from a warehouse entry state to a warehouse-out state.

Optionally, the method further includes:

And responding to a fourth target transaction sent by the bank party after the warehouse receipt data is used as a warranty to be sent to the supplier party for loan issuance, calling the state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse receipt data stored in the block chain from a warehouse entry state to a guaranteed state, so that the supplier party determines the warehouse receipt data to take effect as the warranty when determining that the warehouse receipt data is modified to the guaranteed state.

Optionally, the method further includes:

And in response to a fifth target transaction sent by the supplier after receiving a loan which is issued by the bank as a pledge, the supplier calls the state maintenance logic in the intelligent contract corresponding to the contract address, modifies the invoice data stored in the blockchain from a guaranteed state to a confirmed guaranteed state, and updates the ownership of the invoice data recorded in the blockchain from the supplier to the bank.

Optionally, the method further includes:

And responding to a sixth target transaction sent by the supplier after the supplier starts loan repayment after using the loan, calling the state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse bill data stored in the block chain from the confirmed guarantee state to a submitting return state so that the supplier starts loan repayment to the bank.

Optionally, the method further includes:

And responding to a seventh target transaction sent by the bank party after receiving the loan repayed by the supplier party, calling the state maintenance logic in the intelligent contract corresponding to the contract address, revising the warehouse receipt data stored in the block chain from a submitting and returning state to a warehousing state, and updating the ownership of the warehouse receipt data recorded in the block chain from the bank party to the supplier party.

Optionally, the method further includes:

And when the bank party does not receive the loan which is required to be paid by the supplier party after the expiration or reaches a preset flat line related to the bill data, responding to an eighth target transaction sent by the bank party, calling the state maintenance logic in the intelligent contract corresponding to the contract address, revising the bill data stored in the block chain from the confirmed guarantee state to the warehousing state again, and updating the ownership of the bill data recorded in the block chain from the supplier party to the bank party.

Optionally, the block chain is a federation chain.

Optionally, the sensing hardware includes image acquisition equipment deployed at the warehouse space access control.

The specification also provides a warehouse slip data management device based on the block chain, which is applied to a warehouse slip data management system built based on the block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the blockchain; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the device comprises:

The receiving module is used for receiving a first target transaction sent by a warehousing party; the first target transaction comprises warehousing data of the goods and a contract address of the intelligent contract, wherein the warehousing data of the goods and the contract address of the intelligent contract are acquired by sensing hardware carried in the warehousing space;

The consensus module is used for sending the first target transaction to other node equipment in the block chain and carrying out consensus processing on the first target transaction;

The verification module is used for responding to the first target transaction after the first target transaction passes the consensus, calling the warehousing verification logic in the intelligent contract corresponding to the contract address and verifying the warehousing data;

And the pledge module is used for further calling the state maintenance logic in the intelligent contract corresponding to the contract address after the warehousing data passes the verification, and modifying the warehouse receipt data stored in the block chain into a warehousing state, so that the warehouse receipt data is used as a pledge to send loan to a supplier party when the bank party determines that the warehouse receipt data is modified into the warehousing state.

Optionally, the intelligent contracts are deployed to the blockchain by the supplier side; the intelligent contract comprises a white list with the authority of calling the intelligent contract to update the state of the warehouse receipt data; the white list includes warehousing parties, supplier parties, and banking parties associated with the manifest data.

Optionally, the code logic further includes warehouse exit checking logic for the manifest data, and the receiving module further:

Optionally, the pledge module further:

Optionally, the block chain is a federation chain.

The present specification also provides an electronic device, including a communication interface, a processor, a memory, and a bus, where the communication interface, the processor, and the memory are connected to each other through the bus;

The memory stores machine-readable instructions, and the processor executes the method by calling the machine-readable instructions.

The present specification also provides a machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, carry out the method described above.

In the technical scheme, the real-time monitoring is carried out on the goods corresponding to the manifest data based on the sensing hardware carried in the storage space, and the verification and the state maintenance are carried out on the manifest data based on the intelligent contract which is deployed on the block chain and corresponds to the manifest data; on one hand, the circulation efficiency and the information transparency of the warehouse bill data are improved; on the other hand, the potential safety hazard of each business link related to the warehouse receipt data is reduced, and reliable guarantee is provided for the equity circulation in the warehouse receipt pledge process.

Drawings

Fig. 1 is a schematic networking diagram of a warehouse data management system constructed based on a blockchain network according to an embodiment of the present specification;

Fig. 2 is a flowchart of a block chain-based method for managing data of a manifest according to an embodiment of the present disclosure;

FIG. 3 is a state diagram of a smart contract-based inventory data pledge process provided in one embodiment of the present description;

Fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present specification;

Fig. 5 is a block diagram of a policy data management apparatus according to an embodiment of the present specification.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

For ease of understanding, the underlying concepts related to the lower blockchain are briefly introduced here.

Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.

Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.

Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.

A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.

Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.

The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.

The consensus algorithm supported in the blockchain may include:

The first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

The second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

In the field of blockchain, another important concept is Account (Account); taking an ether house as an example, the ether house generally divides an account into an external account and a contract account; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract).

Of course, for some blockchain models derived from the ethernet-based architecture (such as ant blockchains), account types supported by the blockchain may be further expanded, and are not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

Taking etherhouses as an example, the structure of an account usually includes fields such as Balance, Nonce, Code and Storage. Wherein:

A Balance field for maintaining the current account Balance of the account;

A Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;

A Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.

A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account. The storage content of the contract account is usually constructed into a data structure of an MPT (MerklePatricia Trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.

Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.

For most blockchain models, Merkle trees are typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. Taking etherhouses as an example, the etherhouses use MPT tree (a Merkle tree variation) as a data organization form for organizing and managing important data such as account status, transaction information, and the like.

The Etherhouse designs three MPT trees, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree, aiming at data needing to be stored and maintained in a block chain. In addition to the three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.

An MPT state tree, which is an MPT tree organized by account state data of all accounts in a blockchain; an MPT transaction tree, which is an MPT tree organized by transaction (transaction) data in a blockchain; the MPT receipt tree is organized into transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are eventually added to the block header of the corresponding block.

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.

for the organized MPT transaction tree, MPT receipt tree, and MPT status tree, it is eventually stored in a key-value type database (e.g., L evelDB) that employs a multi-level data storage structure.

the database adopting the multi-level data storage structure is usually a multi-level data storage structure and can be divided into n-level data storage, for example, each level of data storage can be sequentially set to be L0, L1, L2, L3.

Wherein, the read-write performance of the storage medium corresponding to each level of data storage may also have performance difference in general; for example, the read/write performance of the storage medium corresponding to the data storage with a higher rank (i.e., with a smaller rank number) may be higher than the read/write performance of the storage medium corresponding to the data storage with a lower rank. In practical application, a storage medium with higher storage cost and better storage performance can be used for storing data with high level; and the storage medium with low unit cost and large capacity can be used for storing the data with low level.

In practical applications, as the block number of a block chain increases (also referred to as block height), the data stored in the database contains a lot of historical data; also, the longer the data in a block with a smaller block number is, the less important it is. Therefore, in order to reduce the overall storage cost, data of different block heights can be generally treated differently; for example, the data in the block with the smaller block number can be stored on a storage medium with lower cost; and the data in the block with larger block number is stored on the storage medium with higher cost.

It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;

For example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.

After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is completed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

In this specification, a technical solution is provided for monitoring the goods corresponding to the manifest data by using sensing hardware, and managing the manifest data according to an intelligent contract corresponding to the manifest data deployed in a block chain.

Referring to fig. 1, fig. 1 is a schematic diagram of a networking of a built warehouse slip data management system based on block chains according to an embodiment of the present disclosure.

As shown in fig. 1, the warehouse slip data management system for warehouse slip data management is built based on a block chain network, and warehouse slip data is stored in the block chain network; wherein the manifest data corresponds to goods in a warehousing space managed by a warehousing party;

The block chain network comprises a warehousing party node, a supplier party node and a bank party node; the warehousing party node, the supplier party node and the bank party node are used as block chain link point equipment to be accessed into the block chain network;

The warehousing party node is provided with sensing hardware, can monitor goods in a warehousing space managed by the warehousing party in real time and issue monitoring data to the block chain for storage, and can be accessed to the warehousing party node based on a client corresponding to the warehouse receipt data management system; the provider side may access the provider side node access block chain based on a client corresponding to the manifest data management system; the banking party may access the provider-side node access blockchain based on a client corresponding to the manifest data management system.

As shown in fig. 1, an intelligent contract for managing the inventory data is deployed on the blockchain, and after the intelligent contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific contract account address; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the bank side, the supplier side and the warehouse side can check and manage the account state in the contract account of the intelligent contract by accessing the corresponding block chain nodes (the bank side node, the supplier side node and the warehouse side node) based on the held client side.

The warehouse receipt data management system receives a first target transaction sent by a warehouse storage party; the first target transaction comprises warehousing data of goods and a contract address of the intelligent contract, wherein the warehousing data of the goods are collected by sensing hardware carried in a warehousing space; sending the first target transaction to other node equipment in the block chain, and performing consensus processing on the first target transaction; and after the first target transaction passes the consensus, responding to the first target transaction, calling the warehousing verification logic in the intelligent contract corresponding to the contract address, and verifying the warehousing data.

Further, after the warehousing data passes the verification, state maintenance logic in the intelligent contract corresponding to the contract address is further called, the warehouse slip data stored in the block chain is modified into a warehousing state, and therefore when the bank side determines that the warehouse slip data is modified into the warehousing state, the warehouse slip data serves as a warranty to send a loan to the supplier side.

Referring to fig. 2, fig. 2 is a flowchart of a block chain-based warehouse slip data management method according to an exemplary embodiment, where the method is applied to a warehouse slip data management system built on a block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the block chain; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the method specifically comprises the following steps:

Step 202, receiving a first target transaction sent by a warehousing party; the first target transaction comprises warehousing data of the goods and a contract address of the intelligent contract, wherein the warehousing data of the goods are collected by sensing hardware carried by the warehousing space.

Step 204, sending the first target transaction to other node equipment in the block chain, and performing consensus processing on the first target transaction;

And step 206, after the first target transaction is passed, responding to the first target transaction, calling the warehousing check logic in the intelligent contract corresponding to the contract address, and checking the warehousing data.

And step 208, after the warehousing data passes the verification, further calling a state maintenance logic in the intelligent contract corresponding to the contract address, and modifying the warehouse receipt data stored in the block chain into a warehousing state, so that when the bank party determines that the warehouse receipt data is modified into the warehousing state, the warehouse receipt data is used as a warranty to send a loan to the supplier party.

In this specification, the aforementioned data of the manifest includes the manifest and any data related to the manifest. For example, the aforementioned warehouse slip data may specifically include warehouse slip physical pick voucher data or warehouse slip pledge contract data, and the like.

In this specification, the aforementioned warehouse slip data management system refers to a warehouse slip business system that is built based on a block chain network and is used for managing the aforementioned warehouse slip data;

The block chain network comprises a warehousing party node managed by a warehousing party, a supplier party node accessed by a supplier and a bank party node accessed by a bank party. For example, please refer to fig. 1 and the related description of fig. 1, which are not repeated herein for the networking architecture of the aforementioned warehouse data management system.

Accordingly, the blockchain described in this specification may specifically include any type of blockchain network to which the warehousing party node, the supplier party node, and the banking party node are connected as members.

In one embodiment, the blockchain is a federation chain, and the warehousing party node, the supplier party node and the banking party node can be added into the blockchain as member devices.

In this specification, the warehousing party refers to a warehousing party node for any form of warehousing space management in the access block chain network. Such as: the storage space managed by the storage party may be a storage space for storing goods or a truck space.

The warehouse space managed by the warehouse side actually stores goods corresponding to the manifest data, and the warehouse space is provided with sensing hardware;

The sensing hardware can monitor goods stored in or taken out of the storage space in real time.

For example, in practical applications, the sensing hardware is usually deployed at a storage space entrance guard for real-time monitoring of goods stored in or taken out of the storage space, and the sensing hardware may specifically include an image acquisition device (e.g., a camera, etc.), and a wireless sensing acquisition device (e.g., an RFID tag acquisition hardware, etc.).

In this specification, the provider side refers to a provider side node in an access block chain network; the supplier initially holding the warehouse bill data can access the block chain network through the supplier side node and participate in the warehouse bill service related to the warehouse bill data.

In this specification, the banking party refers to a banking party node in an access block chain network; the bank side accesses the block chain network through the bank side node and participates in the warehouse bill business related to the warehouse bill data.

In this specification, the block chain stores the manifest data corresponding to the goods in the storage space managed by the storage party. For example, in practical applications, the block chain stores manifest data indicating information such as the type of goods, the quantity of goods, the source of goods, and the receipt of goods in the storage space managed by the storage party.

In this specification, the intelligent contract refers to an intelligent contract that is deployed on a block chain of the manifest data management system and is used for performing manifest service management on the manifest data; and the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data.

For ease of understanding, the underlying concepts related to intelligent contracts are presented herein.

In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a smart contract (Smartcontract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode. After the EtherFang nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.

After the intelligent contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address. The contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.

for intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte code which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage tree) field of an intelligent contract to save the state of the contract.

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.

An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.

Intelligent contracts deployed on blockchains can generally only refer to data contents stored on blockchains; in practical applications, for some complex business scenarios implemented based on the intelligent contract technology, the intelligent contract may need to refer to some external data on the data entities outside the chain.

The event mechanism of the intelligent contract is a mode for the interaction between the intelligent contract and the out-of-chain entity. For intelligent contracts deployed on blockchains, direct interaction with out-of-chain entities is generally not possible; for example, the intelligent contract cannot generally send the call result of the intelligent contract to the call initiator of the intelligent contract point to point after the call is completed.

The call results (including intermediate results and final call results) generated during the call of the intelligent contract are usually recorded in the form of events (events) to the transaction log (transactions logs) of the transaction that called the intelligent contract, and stored in the memory space of the node device. The entity outside the chain which needs to interact with the intelligent contract can acquire the calling result of the intelligent contract by monitoring the transaction log stored in the storage space of the node equipment;

For example, in the case of an Etherhouse, the transaction log will eventually be stored in the MPT receipt tree described above as part of the receipt (receipt) of the transaction pen transaction that invoked the smart contract. And the entity outside the chain interacting with the intelligent contract can monitor the transaction receipts stored in the storage space of the node device on the MPT receipt tree and acquire the events generated by the intelligent contract from the monitored transaction receipts.

In one illustrated embodiment, the manifest data management system may receive and respond to a second targeted transaction sent by the supplier, where the second targeted transaction deploys into the blockchain an intelligent contract for the manifest service management of the manifest data.

For example, in practical applications, the supplier may create an intelligent contract for conducting the inventory mortgage service in advance, and deploy the intelligent contract into the blockchain in a trading manner;

The intelligent contract is preset with a section of authority control logic, and before the calling party of the intelligent contract modifies the state of the warehouse slip data, the authority control logic is triggered and called in advance to carry out authority control, and whether the calling party of the intelligent contract hits a white list is checked; if yes, then allowing the calling party to call the intelligent contract to update the state of the warehouse receipt data; otherwise, the calling party is prohibited from calling the intelligent contract to update the state of the warehouse receipt data.

For example, in the implementation, based on the authority control logic in the intelligent contract, only the account address of the warehousing party, the account address of the supplier and the account address of the banking party, which are related to the warehouse data pledge, are used as the calling party in the white list which allows the intelligent contract to be called for contract state modification, the intelligent contract is allowed to be called for contract state modification, and the account addresses of other nodes which are not in the white list corresponding to the intelligent contract are prohibited from calling the intelligent contract to modify the contract state, so that malicious tampering of an unauthorized calling party is avoided, and the system security is improved.

In practical applications, it is also possible to preset that all nodes in the block chain are allowed to perform contract status inquiry in the authority control logic in the intelligent contract, so as to obtain the latest status of the contract, and prevent the malicious behavior of the warehousing party, the supplier, and the banking party related to the warranty data pledge.

In this specification, after the supplier side deploys the intelligent contract to the block chain, the warehousing side may store the manifest data in a Storage space (Storage tree) of the intelligent contract by calling the intelligent contract. The intelligent contract may subsequently maintain a state machine for the manifest data in the storage space.

For example, in implementation, the warehousing party may invoke an intelligent contract to store the manifest data for evidence, and specifically, the warehousing party may use a hash value of the manifest data as a key and a state as a value, and store the hash value and the state in a key-value pair form in a storage space of the intelligent contract, so that the intelligent contract is convenient to maintain the state of the manifest data.

It should be noted that, by storing the aforementioned stock bill data in the Storage space (Storage tree) of the intelligent contract, on the one hand, the management is more flexible, and on the other hand, the consumption of the block chain system is reduced, compared with storing the aforementioned stock bill data in the blocks of the block chain in a transaction form.

In this specification, the warehousing data may include information of goods actually loaded into the warehousing space corresponding to the manifest data, which is collected by the sensing hardware mounted in the warehousing space managed by the warehousing party.

For example, in practical applications, the warehousing data may include the number of goods actually loaded into the warehousing space, the type of goods, and the like, which are collected by a camera mounted in the warehousing space managed by the warehousing party and correspond to the warehouse entry data.

In this specification, after the intelligent contract is deployed to the blockchain, the warehouse data management system receives a first target transaction sent by the warehousing party; the first target transaction comprises the warehousing data and a contract address of the intelligent contract.

For example, in practical applications, the warehouse data management system receives a target transaction sent by the warehousing party; the target transaction comprises the actual goods quantity loaded into the storage space corresponding to the manifest data and the contract address of the intelligent contract.

In this specification, the manifest data management system further transmits the first target transaction to another node device in the block chain, and performs consensus processing on the first target transaction. For a specific consensus process, please refer to the above-described consensus mechanism of the blockchain, which is not described herein.

In this specification, after the first target transaction is passed, in response to the first target transaction, the warehouse data management system checks the warehouse data by calling a warehouse check logic in the intelligent contract corresponding to the contract address of the intelligent contract.

For example, in practical applications, the number of goods included in the warehouse entry data is 10000, and the number of goods included in the warehouse entry data is 5000, the warehouse entry data management system verifies the number of goods included in the warehouse entry data and the number of goods included in the warehouse entry data by calling a warehouse entry verification logic in an intelligent contract, and recognizes that the number of goods included in the warehouse entry data is less than the number of goods included in the warehouse entry data.

It should be noted that, after the warehousing data is matched with the warehousing data, the nodes in the block chain may further perform consensus check on the result of matching between the warehousing data and the warehousing data, so as to prevent a plurality of nodes from acting together to malicious and falsified data. In addition, in practical application, the sensing hardware is also used as member equipment to be directly connected to the block chain, and the sensing hardware can directly submit the warehousing data to the block chain without passing through the warehousing party, so that potential safety hazards of warehousing environments are reduced.

In this specification, after the warehousing data passes the verification, the warehouse data management system further invokes a state maintenance logic in the intelligent contract based on a contract address of the intelligent contract, and modifies the warehouse data stored in the block chain into a warehousing state, so that the banking party issues a loan to the supplier party as a warranty when determining that the warehouse data is modified into the warehousing state.

Continuing to give an example in the above example, in practical application, after the warehousing data passes verification, the warehousing data management system further calls a state maintenance logic in the intelligent contract based on the contract address of the intelligent contract, and modifies the circulation state of the warehousing data stored in the contract account in the intelligent contract into a warehousing state, so that when the banking party obtains the circulation state in the intelligent contract as the warehousing state through inquiry, the warehousing data is used as a warranty to deliver a loan to the supplier party in a block chain or chain-down manner.

In this specification, the ex-warehouse data may include information on the goods actually moved from the warehouse space, which is collected by the sensor hardware mounted in the warehouse space managed by the warehouse owner, and corresponds to the manifest data.

For example, in practical applications, the warehouse-out data may include the number of goods actually moved out of the warehouse space, the types of goods, and the like, which are collected by a camera mounted in the warehouse space managed by the warehouse owner and correspond to the manifest data.

In an embodiment shown in the above, the code logic of the intelligent contract may further include a delivery verification logic for the manifest data, and after the manifest data is in a warehousing state, the manifest data management system receives a third target transaction sent by the warehousing party after the warehousing party extracts the stock of the goods corresponding to the manifest data from the supplier party; wherein the third target transaction includes the outbound data and a contract address of the intelligent contract.

In this specification, further, in response to the third target transaction, the outbound verification logic in the intelligent contract is invoked based on the contract address of the intelligent contract to verify the outbound data.

It should be noted that the process of checking the ex-warehouse data is similar to the process of checking the in-warehouse data, and is not described herein again.

In this specification, after the check of the ex-warehouse data is passed, a state maintenance logic in the intelligent contract is further invoked based on the contract address of the intelligent contract, and the inventory data stored in the block chain is modified from an in-warehouse state to an out-warehouse state.

For example, in practical applications, after the check of the outbound data is passed, the manifest data management system further invokes a state maintenance logic in the intelligent contract based on the contract address of the intelligent contract, and changes the circulation state of the manifest data stored in the contract account in the intelligent contract from the inbound state to the outbound state.

In one embodiment, the receipt data management system receives and responds to a fourth target transaction sent by the bank party after the receipt data is issued as a warranty to the supplier party, invokes state maintenance logic in the intelligent contract based on a contract address of the intelligent contract, and modifies the receipt data from a warehousing state to a guaranteed state, so that the supplier party further determines whether the receipt data is effective as the warranty when determining that the receipt data is modified to the guaranteed state.

For example, in practical applications, the bank may issue a loan to the supplier as a warranty through a block chain or a chain, after the loan is issued to the supplier, the bank sends a fourth target transaction to the policy data management system, and the policy data management system receives and responds to the fourth target transaction sent by the bank, invokes a state maintenance logic in the intelligent contract based on a contract address of the intelligent contract, and modifies a circulation state of the policy data stored in a contract account in the intelligent contract from a warehousing state to a secured state, so that the supplier further determines whether the policy data takes effect as the warranty when determining that the policy data is modified to the secured state.

It should be noted that, after the bank has completed loan issuance to the supplier, the receipt data has not yet been fully validated as a pledge, and the supplier needs to further determine whether the receipt data has been validated as a pledge.

In one illustrated embodiment, the receipt data management system receives and responds to a fifth target transaction sent by the supplier after receiving a loan issued by the bank as a warranty, invokes a status maintenance logic in the intelligent contract based on a contract address of the intelligent contract, modifies the receipt data stored in the block chain from a warranted status to a confirmed warranted status, and updates ownership of the receipt data recorded in the block chain from the supplier side to the bank side so that the receipt data becomes effective as the warranty.

For example, in practical applications, after the supplier side receives a loan issued by the bank side as a warranty by the bank side in a block chain or in a chain, the supplier side sends a fifth target transaction to the receipt data management system, the receipt data management system receives and responds to the fifth target transaction sent by the supplier side, invokes a state maintenance logic in the intelligent contract based on a contract address of the intelligent contract, modifies a circulation state of the receipt data stored in a contract account in the intelligent contract from a secured state to a confirmed secured state, and records in the block chain that ownership of the receipt data is updated from the supplier side to the bank side so that the receipt data becomes effective as the warranty.

In one embodiment, the receipt data management system calls a status maintenance logic in the intelligent contract based on a contract address of the intelligent contract in response to a sixth target transaction sent by the supplier after loan payment is initiated using the supplier, and modifies the receipt data stored in the block chain from a confirmed warranty status to a delivery return status so that the supplier makes loan payment to the bank.

For example, in practical applications, when the supplier performs loan repayment in a block-up or block-down manner after completing the loan, the supplier sends a sixth target transaction to the invoice data management system, and the invoice data management system receives and responds to the sixth target transaction sent by the supplier, invokes state maintenance logic in the intelligent contract based on the contract address of the intelligent contract, and modifies the circulation state of the invoice data stored in the contract account in the intelligent contract from a confirmed warranty state to a submission and return state.

In one embodiment, the manifest data management system calls a status maintenance logic in the smart contract based on a contract address of the smart contract in response to a seventh target transaction sent by the bank after receiving a loan repayed by the supplier, re-modifies the manifest data stored in the block chain from a submission-return status to a warehousing status, so that a warranty of the manifest data is released, and updates ownership of the manifest data recorded in the block chain from the bank to the supplier.

For example, in practical applications, after the banking party receives the loan repayed by the supplier, the banking party sends a seventh target transaction to the inventory data management system, the inventory data management system receives and responds to the seventh target transaction sent by the supplier, invokes state maintenance logic in the intelligent contract based on the contract address of the intelligent contract, and modifies the circulation state of the inventory data stored in the contract account in the intelligent contract from the submission and return state to the warehousing state, so as to release the warranty of the inventory data, and records in the contract account in the intelligent contract in the block chain, and updates the ownership of the inventory data from the banking party to the supplier.

In an illustrated embodiment, when the bank party does not receive a loan due to the payment of the supplier party after the expiration or when a preset flat line related to the receipt data is reached, the receipt data management system calls a state maintenance logic in the intelligent contract based on a contract address of the intelligent contract in response to an eighth target transaction sent by the bank party, modifies the receipt data stored in the block chain from a confirmed warranty state to a warehousing state, so that the warranty of the receipt data is released, and records in the block chain that the ownership of the receipt data is updated from the supplier party to the bank party.

For example, in practical applications, when the bank party does not receive the loan to be paid back by the supplier party after the past due by the way of the block chain or the way of the block chain, or when a contract event reaching a preset flat-binning line associated with the above-mentioned bin list data is intercepted, the bank sends an eighth target transaction to the receipt data management system, the receipt data management system receives and responds to the eighth target transaction sent by the supplier, invokes state maintenance logic in the intelligent contract based on the contract address of the intelligent contract, and modifies the circulation state of the receipt data stored in the contract account in the intelligent contract from a confirmed guarantee state to a warehousing state, so as to release the pledge of the warehouse slip data and update the ownership of the warehouse slip data recorded in the contract account in the intelligent contract in the block chain from the bank side to the supplier side.

It should be noted that, a plurality of states of ownership of the aforementioned manifest data may also be distinguished by defining corresponding variables in the Storage (Storage tree) of the contract account in the aforementioned intelligent contract and using different enumerated values for indication; the fourth target transaction, the fifth target transaction, the sixth target transaction, the seventh target transaction, and the eighth target transaction each carry a contract address of the intelligent contract, so as to perform the state maintenance logic call in the intelligent contract based on the contract address.

To facilitate understanding of the overall process of managing the inventory data based on the smart contracts, please refer to fig. 3, where fig. 3 is a schematic diagram of a state of an inventory data pledge process based on the smart contracts according to an embodiment of the present disclosure.

As shown in fig. 3, after "creating and deploying an intelligent contract corresponding to the inventory data" on the block chain by the supplier, and "the warehousing party confirms" (for example, please refer to the warehousing party described above for performing warehousing confirmation based on the mounted sensing hardware), the intelligent contract is triggered to set the inventory data to the "warehousing state"; after the supplier takes goods (for example, please refer to the warehouse side for warehouse-out confirmation based on the sensor hardware mounted in the warehouse), the intelligent contract is triggered to update the warehouse receipt data from the warehouse-in state to the warehouse-out state; after the bank provides loan guarantee, triggering an intelligent contract to update the warehouse receipt data from the warehousing state to the guaranteed state; after the 'supplier confirms the guarantee', triggering the intelligent contract to update the warehouse bill data from the 'guaranteed state' to the 'confirmed guarantee state'; when the warehouse is triggered, triggering an intelligent contract to directly update the warehouse bill data from the confirmed guarantee state to the warehouse entry state; after the supplier finishes using the loan, triggering the intelligent contract to update the warehouse receipt data from the confirmed guarantee state to a submitting return state; after the bank side confirms (for example, please refer to the bank side described above to confirm the timely returning of the loan), the intelligent contract is triggered to update the warehouse receipt data from the submitting returning state to the warehousing state.

As can be seen from the above embodiments, the sensing hardware carried on the basis of the warehousing space monitors the goods corresponding to the manifest data in real time, and checks and maintains the state of the manifest data on the basis of the intelligent contracts deployed on the block chain and corresponding to the manifest data; on one hand, the circulation efficiency and the information transparency of the warehouse bill data are improved; on the other hand, the potential safety hazards of all business links related to the warehouse receipt data (such as tampering of warehouse receipt data by all links and the risk of cheating loan from a warehouse receipt to multiple banks repeatedly) are reduced, and the reliable guarantee is provided for the rights and interests transfer in the warehouse receipt mortgage process (such as ownership of all links in the warehouse receipt mortgage process).

Corresponding to the method embodiment, the application also provides an embodiment of the device.

Corresponding to the above method embodiments, the present specification further provides an embodiment of a block chain-based manifest data management apparatus.

The embodiment of the block chain-based hierarchical storage device of the present specification can be applied to an electronic device. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

From a hardware aspect, as shown in fig. 4, the hardware structure diagram of the electronic device where the block chain-based warehouse receipt data management apparatus of the present specification is located is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 4, the electronic device where the apparatus is located in the embodiment may also include other hardware according to the actual function of the electronic device, which is not described again.

Fig. 5 is a block diagram of a block chain-based manifest data management apparatus according to an exemplary embodiment of the present specification.

Referring to fig. 5, the block chain-based warehouse slip data management apparatus 50 may be applied to the aforementioned electronic device shown in fig. 4, and is a warehouse slip data management system built based on a block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the blockchain; the code logic corresponding to the contract code in the intelligent contract includes warehousing check logic and state maintenance logic for the inventory data, and the apparatus 50 includes:

The receiving module 501 receives a first target transaction sent by a warehousing party; the first target transaction comprises warehousing data of the goods and a contract address of the intelligent contract, wherein the warehousing data of the goods and the contract address of the intelligent contract are acquired by sensing hardware carried in the warehousing space;

A consensus module 502, configured to send the first target transaction to other node devices in the block chain, and perform consensus processing on the first target transaction;

The checking module 503, after the first target transaction is passed, responds to the first target transaction, and invokes the warehousing checking logic in the intelligent contract corresponding to the contract address to check the warehousing data;

And the pledge module 504 is further used for calling the state maintenance logic in the intelligent contract corresponding to the contract address after the warehousing data passes the verification, and modifying the warehouse receipt data stored in the block chain into a warehousing state, so that the warehouse receipt data is used as a pledge to offer loan to a supplier party when the bank party determines that the warehouse receipt data is modified into the warehousing state.

In this embodiment, the smart contracts are deployed to the blockchain by the supplier side; the intelligent contract comprises a white list with the authority of calling the intelligent contract to update the state of the warehouse receipt data; the white list includes warehousing parties, supplier parties, and banking parties associated with the manifest data.

In this embodiment, the code logic further includes warehouse exit checking logic for the manifest data, and the receiving module 501 further:

In this embodiment, the pledge module 504 further:

In this embodiment, the block chain is a federation chain.

In this embodiment, the sensing hardware includes image capture equipment deployed at the storage space access control.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A warehouse slip data management method based on block chains is applied to a warehouse slip data management system built based on a block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the blockchain; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the method comprises the following steps:

2. The method of claim 1, the smart contract being deployed to the blockchain by the supplier party; the intelligent contract comprises a white list with the authority of calling the intelligent contract to update the state of the warehouse receipt data; the white list includes warehousing parties, supplier parties, and banking parties associated with the manifest data.

3. The method of claim 1, the code logic further comprising ex-warehouse check logic for the manifest data, further comprising:

4. The method of claim 1, further comprising:

5. The method of claim 4, further comprising:

6. The method of claim 4, further comprising:

7. The method of claim 6, further comprising:

8. The method of claim 6, further comprising:

9. The method of claim 1, the blockchain is a federation chain.

10. The method of claim 1, the sensing hardware comprising image capture equipment deployed at the warehouse space gate.

11. A warehouse slip data management device based on a block chain is applied to a warehouse slip data management system built based on a block chain network; the block chain stores warehouse bill data corresponding to goods in a warehouse space managed by a warehouse; intelligent contracts used for managing the warehouse bill data are deployed in the blockchain; the code logic corresponding to the contract code in the intelligent contract comprises warehousing check logic and state maintenance logic aiming at the warehouse receipt data; the device comprises:

12. The apparatus of claim 11, the smart contract deployed to the blockchain by the supplier party; the intelligent contract comprises a white list with the authority of calling the intelligent contract to update the state of the warehouse receipt data; the white list includes warehousing parties, supplier parties, and banking parties associated with the manifest data.

13. The apparatus of claim 11, the code logic further comprising ex-warehouse check logic for the manifest data, the receive module further to:

14. The apparatus of claim 11, the pledget module further to:

15. The apparatus of claim 14, the pledget module further to:

16. The apparatus of claim 14, the pledget module further to:

17. The apparatus of claim 16, the pledget module further to:

18. The apparatus of claim 16, the pledget module further to:

19. The apparatus of claim 11, the blockchain is a federation chain.

20. The apparatus of claim 11, the sensing hardware comprising image capture equipment deployed at the warehouse space gate.

21. An electronic device, comprising:

A processor;

A memory for storing processor-executable instructions;

Wherein the processor implements the method of any one of claims 1-10 by executing the executable instructions.