Web3 automatic unmanned aerial vehicle distribution system and method based on block chain

Abstract

The invention relates to the technical field of unmanned aerial vehicle distribution, and discloses a Web3 automatic unmanned aerial vehicle distribution system and method based on a block chain, and the system comprises an unmanned aerial vehicle identity management module which is used for registering and building an on-chain identity containing a distributed identity for each unmanned aerial vehicle; the path planning and task matching module is used for screening candidate unmanned aerial vehicles and calculating comprehensive path cost; the dual-stage zero-knowledge proof verification module is used for generating a first zero-knowledge proof to verify the legality of path planning and generating a second zero-knowledge proof to verify the consistency of an actual track log and a planned path after the task is executed; and the excitation and state updating module is used for executing reward distribution and updating the dynamic reputation score of the unmanned aerial vehicle. According to the method, the candidate unmanned aerial vehicles are quantitatively evaluated by using the comprehensive utility function, and the optimal transport capacity resource can be dynamically matched for the specific task, so that the operation efficiency and the resource utilization rate of the whole distribution network are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of drone delivery technology, specifically to a blockchain-based Web3 automated drone delivery system and method. Background Technology

[0002] With the rapid development of blockchain, the Internet of Things (IoT), and intelligent robotics technologies, automated drone delivery is gradually moving towards practical applications. However, existing drone logistics systems generally use centralized platforms for scheduling and management, which suffers from problems such as low resource scheduling efficiency, insufficient transparency in task execution, and limited user participation, making it difficult to meet the Web3 requirements for openness, fairness, and verifiability. In traditional systems, users can only passively receive services, lacking management of personalized needs and a unified on-chain verification mechanism to ensure the credibility and auditability of task execution results.

[0003] Current automated drone delivery systems generally rely on centralized platforms for scheduling and management, but this leads to several technical drawbacks. First, the task execution process lacks transparency and reliable verification and auditing mechanisms. Second, the closed platform architecture restricts the access of socialized delivery resources (such as private drones), hindering network openness and scalability. Finally, this centralized model results in inefficient resource scheduling and makes it difficult to achieve decentralized, precise delivery and user control at the final delivery stage.

[0004] While some blockchain-based smart logistics concepts that have emerged in recent years (such as distributed warehousing chains and decentralized express delivery platforms) have made initial explorations into on-chain task publishing and result confirmation, they remain limited to task registration and points recording, failing to truly achieve a closed-loop on-chain process from warehouse scheduling and drone flight planning to final delivery. Furthermore, existing systems typically treat drones as platform resources for unified scheduling, neglecting users' contributions and control at the node level, and failing to support user-defined deployment, management, and incentive mechanisms, thus limiting the user ownership and participation philosophy advocated by Web3. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a blockchain-based Web3 automated drone delivery system and method, which solves the problems of opaque task scheduling, lack of reliable verification of the execution process, and closed and difficult-to-expand delivery network caused by existing centralized drone delivery systems.

[0006] To achieve the above objectives, the first aspect of the present invention provides a blockchain-based Web3 automated drone delivery system;

[0007] The system is built on a Web3 infrastructure consisting of blockchain, decentralized identity protocols, and smart contracts;

[0008] The drone identity management module is responsible for establishing a globally unique, tamper-proof, and owner-controlled on-chain identity for each drone in the network. The core of this identity is a Distributed Identity (DID). In one specific implementation, this DID is pegged to a digital asset created for the drone, conforming to a specific non-fungible token (NFT) standard (e.g., ERC-721). Its DID string is deterministically composed of the NFT's unique tokenId, the blockchain network ID, and the contract address. Simultaneously, metadata such as the drone's public key, supported authentication methods, and on-chain interaction addresses are recorded in a DID document associated with this DID. This document is stored on a decentralized storage network and, after being digitally signed by its owner, is also recorded on-chain.

[0009] Once a delivery task is posted, the route planning and task matching module initially filters candidate drones from the drones recorded on the blockchain, identifying those whose capability parameter vectors meet the task requirements. Then, the built-in scheduling engine scores and ranks the candidate drones based on a comprehensive utility function.

[0010] The overall path cost is calculated using a hybrid navigation strategy. This strategy first employs A... The algorithm calculates a global reference path on a weighted graph that integrates static obstacles and airspace rules. Subsequently, during actual flight, the onboard Proximity Policy Optimization (PPO) model dynamically avoids obstacles based on real-time data collected by sensors, making local adjustments to the global reference path.

[0011] Two-phase zero-knowledge proof verification is used to generate proofs at two key phases of the task:

[0012] Mission Authorization Phase: Before issuing the mission to the UAV, a first zero-knowledge proof is generated. This process uses the complete path planning sequence as private input, and publicly available digitized 3D flight maps and mission descriptions (origin and destination, time window) as public input. The proof itself demonstrates that the private path satisfies a predefined first-order constraint system (R1CS).

[0013] Post-mission verification phase: Generating a second zero-knowledge proof (π2). During mission execution, the UAV periodically hashes its actual flight path logs and submits the generated Merkle root on the blockchain as a state commitment. After the mission ends, the UAV uses the complete actual flight path logs and the original path planning sequence as private inputs to generate π2.

[0014] The incentive and state update module performs closed-loop settlement for tasks. Once the second zero-knowledge proof π2 is verified on-chain by the smart contract, the final total reward amount due to the drone is determined through a dynamic reward calculation formula. After the reward is distributed, the drone's dynamic reputation score is updated based on its overall performance in this task, forming a long-term evolution mechanism.

[0015] In addition, to protect the physical location privacy of user terminals, the system also includes a Home-Port terminal and a precise delivery module. When a user registers a delivery point, this module obtains the geospatial coordinates of that point and, combined with an independently generated secret salt value, calculates a location commitment hash using a hash function. Only this hash is uploaded to the blockchain and bound to the user's address. During the task execution phase, only authorized drones can decrypt the geospatial coordinates and secret salt value required to decrypt the hash. Once the drone reaches the vicinity of the destination, it uses its onboard camera to identify visual landmarks deployed on the Home-Port for hovering positioning; and through a challenge-response handshake protocol based on short-range communication, it uses the drone's private key to sign the challenge information, completing the final authentication of the drone's on-chain identity before authorizing the final delivery of the package.

[0016] A second aspect of this invention provides a blockchain-based Web3 automated drone delivery method.

[0017] This method is executed on the Web3 infrastructure provided by the aforementioned system and includes the following steps:

[0018] Identity registration and parameter reporting: Through the drone identity management module, a distributed identity is generated for a drone, and the capability parameter vector signed and confirmed by its owner is recorded on the blockchain to complete the network access of the drone.

[0019] Path planning and task matching: After a delivery task is generated on the blockchain, the path planning and task matching module automatically filters and sorts candidate drones according to the comprehensive utility function, and plans the path sequence for the best candidate drone.

[0020] Planning Verification and Trusted Authorization: Based on the two-stage zero-knowledge proof verification module, a first zero-knowledge proof is generated for the path sequence of the path planning generated in the previous step and submitted to the blockchain. After the smart contract verifies that the proof is passed, the task status is updated on the chain to complete the mission authorization for the drone.

[0021] Mission oversight and status monitoring: When the drone is performing a mission, it periodically calculates and submits its actual flight path logs to the blockchain as an immutable state commitment for its flight process.

[0022] Compliance verification: After the mission is completed, the UAV generates a second zero-knowledge proof using the two-stage zero-knowledge proof verification module and submits it to the blockchain. This proof is used to confirm to the blockchain that the actual flight logs it has committed to on the blockchain are consistent with the path sequence of the path plan based on the authorization within a preset tolerance.

[0023] Incentive Allocation and Update: After the second zero-knowledge proof is verified on-chain, the incentive and state update module is automatically triggered. The task reward is calculated and allocated to the drone owner's address according to the dynamic reward calculation formula. At the same time, the drone's dynamic reputation score is updated based on the performance data of this task.

[0024] This invention provides a blockchain-based Web3 automated drone delivery system and method. It offers the following advantages:

[0025] 1. This invention uses a path planning and task matching module to quantitatively evaluate candidate drones using a comprehensive utility function. This enables the system to dynamically match the optimal transportation resources for a specific task from a heterogeneous network of drones of different models and capabilities, thereby significantly improving the operational efficiency and resource utilization of the entire delivery network.

[0026] 2. This invention uses a two-stage zero-knowledge proof verification module. The first zero-knowledge proof verifies the legality of the route planning on-chain without exposing flight path details. The second zero-knowledge proof verifies the consistency between the actual flight log and the authorized route. This allows users or regulatory authorities and other third parties to confirm the compliance and authenticity of the task execution without obtaining sensitive commercial data, thus solving the technical problem of opacity in traditional scheduling systems.

[0027] 3. This invention introduces a Home-Port terminal and a precise delivery module. Firstly, it utilizes a location commitment hashing scheme to record only the hash value of the delivery point's geographic spatial coordinates on the blockchain, effectively avoiding the public exposure of the user's physical address. During delivery, hovering positioning can also be implemented to ensure that packages are accurately and securely delivered to the correct location by authorized drones, balancing privacy protection and physical security.

[0028] 4. This invention implements an incentive settlement mechanism through a drone identity management module and an incentive and status update module, dynamically calculating rewards and incorporating their performance into a dynamic reputation score. This forms a closed loop of contribution-reward-reputation, attracting broad participation from social transportation resources. It relies on preset smart contract rules rather than a centralized entity to regulate transportation supply and demand, enabling user-customized deployment. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0030] Figure 2 This is the overall process of the drone delivery system of the present invention;

[0031] Figure 3 This is a schematic diagram of the private drone blockchain on-chain and unified scheduling mechanism of the present invention;

[0032] Figure 4 This is a flowchart illustrating the automatic execution and archiving process on the drone mission chain of the present invention. Detailed Implementation

[0033] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] To better understand the present invention, the above content will be described in detail below with reference to specific embodiments.

[0035] Please see the appendix Figure 1 -Appendix Figure 4 This invention provides a blockchain-based Web3 automated drone delivery system. The system includes: an on-chain warehouse scheduling and task generation module, a drone identity management module, a route planning and task matching module, a Home-Port terminal and precise delivery module, a two-stage zero-knowledge proof verification module, and an incentive and state update module. These modules are built on a Web3 infrastructure consisting of blockchain, decentralized identity protocols, and smart contracts. After receiving a delivery task request, the warehouse system can then identify the package and activate the drone for delivery.

[0036] In one embodiment, the drone can be a public device operated by the platform or a private device registered by the user. Regardless of whether it's a public device operated by the platform or a private device registered by the user, establishing a unique, trusted digital identity controlled by its owner is fundamental to building the entire decentralized delivery system. This invention can achieve this goal using a distributed identity mechanism conforming to W3C (World Wide Web Consortium) standards. Each DID serves as a persistent, globally unique identifier and is bound to its encryption key and on-chain interaction address.

[0037] The generation and management process of DIDs is designed as a standardized, cryptographically based operation, which can be broken down into the following steps:

[0038] Key pair generation: Before registering the drone, the drone owner (who can be a platform provider or an individual user) first needs to generate an asymmetric encryption key pair, i.e., a private key. and a public key Its formula is:

[0039] ;

[0040] In the formula, For key pair generation algorithms, Represents the selected elliptic curve (e.g., secp256k1). Private key. Securely stored offline by the owner, it is the only credential proving their control over the drone's identity. Public key It will then be made public and used to verify the digital signature generated by the private key.

[0041] Instantiation of on-chain identity:

[0042] To anchor an abstract identity to a concrete entity on the blockchain, this invention uses a non-fungible token (NFT) minted in the identity registration and management contract at the execution layer to represent each drone. This NFT conforms to the ERC-721 standard, possessing global uniqueness and indivisibility, mapping to the unique properties of drones in the physical world. When the owner calls the contract's registration function, the contract mints a new NFT and assigns it to the owner's on-chain address. The unique tokenId of this newly minted NFT then serves as the core identifier for constructing the drone's DID.

[0043] Construction of Distributed Identity (DID):

[0044] The drone's DID string is constructed following the standard format:did:method:identifier. In this specific implementation, the method is defined as a method name unique to this system (e.g., UAV), while the identifier part is composed of blockchain information and the tokenId generated in the previous step, ensuring its global uniqueness and resolvability. The formula is as follows:

[0045] ;

[0046] In the formula, This represents the final generated distributed identity string for the drone; This represents a string concatenation operation; A chain ID that represents the blockchain network (e.g., 137 for the Polygon mainnet). The deployment address for the identity registration and management contract; A unique token ID representing the ERC-721NFT corresponding to this drone;

[0047] DID document generation and association: Each DID corresponds to a DID document, which is a structured data object in JSON-LD format, used to describe the metadata of that DID. This document is generated during registration and stored in a decentralized storage network (such as IPFS). A typical DID document contains at least the following key information:

[0048] id: This refers to the DID string described in the document. .

[0049] A list of objects used to declare the encrypted public key associated with this DID. This list must include the drone's public key. And specify its type (such as EcdsaSecp256k1VerificationKey2019) and the controller to which it belongs (i.e., the DID itself).

[0050] The reference list explicitly specifies which public key(s) in the list can be used for authentication, i.e., to prove control over the DID. This section will reference public keys. The entry.

[0051] A custom service endpoint explicitly binds this DID to one or more EVM addresses (i.e., operation addresses) used by the drone when interacting on-chain, establishing a clear and publicly verifiable association that indicates the on-chain account used by the drone when performing tasks and receiving rewards.

[0052] By following the steps above, a complete closed loop for creating and managing a drone's distributed identity is achieved. Ownership of this identity is represented by the owner of the corresponding NFT, while control resides with the holder of the private key. The entity possesses the private key. In any subsequent critical operations, such as updating the drone's capability parameters or confirming mission reception, the private key must be provided. The generated digital signature.

[0053] After establishing a unique DID for the drone, the next step is to record its physical performance parameters on the blockchain. The accuracy and immutability of these parameters directly affect the security and efficiency of the entire system. This invention ensures data validity by combining digital signatures and on-chain contract verification mechanisms, specifically:

[0054] After completing identity registration, drone owners need to call specific functions in the identity registration and management contract to declare or update their drone's capability parameters. This process involves the following steps:

[0055] First, the key physical properties of the drone are abstracted and unified into a standardized capability parameter vector. This vector is a dataset containing the metrics necessary for task matching, represented as:

[0056] ;

[0057] in: Representing drones Ability parameter vector; This is the maximum effective payload weight of the drone; This represents the maximum flight range of the drone. This refers to the average cruising speed of the drone; For drone battery capacity; This parameter vector represents the drone's three-dimensional dimensions (length, width, and height) to determine compatibility with Home-Port devices. This vector is scalable, allowing for the addition of more parameters in the future, such as wind resistance and waterproofing ratings, based on business needs.

[0058] The above capability parameter vector Serialization is performed into a standard format data packet (e.g., a JSON string), denoted as... To prove that the data was indeed submitted by the owner and has not been tampered with during transmission, the owner must use the private key they hold, which is linked to the drone's DID. The hash value of this data packet is signed using the following formula:

[0059] ;

[0060] in: It is a standard cryptographic hash function, such as SHA-256; It is a signature function based on the Elliptic Curve Digital Signature Algorithm (ECDSA); It is the generated digital signature.

[0061] On-chain contract two-factor authentication mechanism: After receiving a request to update capability parameters, the identity registration and management contract does not immediately accept the data, but instead executes a strict two-factor authentication procedure:

[0062] The first layer: signature verification. The contract first uses the tokenId provided in the transaction to query and retrieve the public key that the drone recorded on the blockchain during registration. Then, the contract uses the public key to check the received data packets. and signature Verification is performed. The formula is expressed as:

[0063] ;

[0064] In the formula, This represents the boolean result of the verification operation. This represents a standard asymmetric cryptographic signature verification function implemented in a smart contract. Represents the original data packet The digest obtained after hash calculation;

[0065] Only when The first layer of verification is confirmed when the function returns true, proving that the request was indeed initiated by a legitimate owner. Any request without a proper signature will be immediately rejected.

[0066] The second layer: Structure and scope verification. To prevent malicious or erroneous data from being uploaded to the blockchain, the contract will also perform... The content is validated. Specifically, this includes:

[0067] Format validation: Checks whether the data packet conforms to a predefined structure (e.g., JSON), whether all required fields exist and whether the data types are correct (e.g., ...). (Must be a positive number).

[0068] Reasonableness range verification: Checks whether each parameter value falls within the system's preset reasonable range. For example, the contract can set the maximum payload weight of the drone. The weight limit must not exceed a global limit (e.g., 50kg), and the driving range must be within a certain range. It must be greater than a minimum threshold (e.g., 5km).

[0069] Only after both verifications pass will the identity registration and management contract release the parsed capability parameter vector. Write the data to the storage area and associate it with the corresponding tokenId. Ensure that the capability parameters of each drone on the blockchain are verified, in a valid format, and have reasonable values.

[0070] In one embodiment, to quantitatively assess the reliability and historical performance of drones in a network, this invention introduces a dynamic reputation scoring model. This model maintains a dynamically updated reputation score for each registered drone. This reputation score is not only an important component of the drone's digital identity but also a key decision-making basis for the system when scheduling tasks and matching resources, thereby constructing an effective performance-based trust mechanism and a positive incentive loop.

[0071] This credit score It is a numerical value recorded in the identity registration and management contract at the execution layer and associated with the drone's DID. Its initial value is set to a neutral default value when the drone is first registered. Thereafter, whenever the drone successfully completes a delivery task (i.e., the zero-knowledge (ZKP) proof π2 of the task execution is verified on-chain), this reputation score will automatically trigger an update.

[0072] The reputation score is updated using an exponential moving average algorithm, designed to combine the drone's historical performance with the completion of its most recent mission. This update logic is executed by a smart contract, and its calculation formula is as follows:

[0073] ;

[0074] In the formula: Representing drones After completing the task After that, the updated credit score; Representing drones In performing the task Previous credit score; The update weighting factor (or smoothing coefficient) is a constant between 0 and 1 (0 < α ≤ 1), determining the degree to which the latest task performance affects the overall reputation score. A higher [α] indicates a higher [smoothing factor]. A higher value means that the credit score is more sensitive to recent performance, while a lower value indicates that the credit score is more sensitive to recent performance. This value indicates that the credit score is more stable and relies more on long-term historical accumulation; Representing the drone in this mission The overall performance score.

[0075] The overall performance here is as follows: This is not a subjective evaluation, but rather a calculation based on a series of objectively quantifiable and on-chain verifiable indicators. To ensure consistency between the incentive and reputation evaluation systems, The calculation method is completely consistent with the performance evaluation part used to calculate token rewards in the incentive module. Specifically, it is a weighted sum of multiple normalized performance metrics, expressed by the following formula:

[0076] ;

[0077] in, Represents a specific task The total amount of final token rewards calculated; , , The weighting coefficients representing time efficiency, energy efficiency, and path accuracy are summed to 1 to reflect the system's emphasis on different optimization objectives during a specific period. , , These represent the normalized scoring functions for time efficiency, energy efficiency, and path accuracy, respectively. This represents the estimated flight time to complete the mission, calculated by the path planning module during the mission scheduling phase. The ratio represents the actual time taken for a drone to complete its delivery and be confirmed by the system. Reflects the time efficiency of the task; This represents the actual amount of electricity consumed by the drone during the entire mission, and this data can be recorded by the onboard battery management system (BMS). This represents the total battery capacity of the drone performing the mission. The percentage of remaining battery power of the drone after the mission is completed is calculated as an indicator of energy efficiency, encouraging drones to adopt more energy-efficient flight strategies. This represents the actual three-dimensional flight trajectory of the drone during mission execution, recorded by its GPS module and other sensors. This represents the planned flight path generated by the path planning module during the mission scheduling phase and verified by zero-knowledge proof π1. Represents the flight trajectory planning path The total length is used to normalize the path deviation, making the path accuracy indicators of different tasks comparable. This is a deviation measurement function used to calculate the degree of deviation between the actual flight trajectory and the planned trajectory. For the sake of full disclosure, the specific implementation of this function can take one of several forms, for example:

[0078] Average distance method: Calculate the average Euclidean distance between corresponding sampling points on two trajectories;

[0079] Dynamic time warping distance: used to handle the problem of inconsistent speeds or local scaling between two trajectories on the time axis, and calculate the cost of the optimal matching path between them;

[0080] In a preferred embodiment of the invention, using DTW distance or Fraser distance can more accurately assess whether the UAV intends to follow the planned path, rather than simply being close to the location in space.

[0081] In this way, a high-quality task execution (such as efficient, energy-saving, and accurate) will not only bring more token rewards, but will also directly translate into higher performance scores. This will enhance the drone's long-term reputation.

[0082] Furthermore, dynamic credit score It is also an important input for the path planning and task matching modules when making decisions, and provides a specific implementation path for the functional requirement of providing a basis for subsequent scheduling and sorting, which is mainly reflected in the following two aspects:

[0083] Task candidate qualification filtering: For some high-value, high-priority, or special-requirement tasks, the task issuer or system can set a minimum reputation score threshold through DAO governance. When the dispatch system filters available drones, it first excludes all those with a reputation score lower than [a certain threshold]. The drone, that is, only those that meet the requirements ≥ Only drones that meet the criteria are eligible to proceed to the next round of matching and sorting.

[0084] Scheduling Priority Ranking: Among all candidate drones that meet the basic capability requirements and reputation threshold, the scheduling system uses a utility function. They are all comprehensively evaluated to select the best executor. Reputation score. It is a key positive factor in this utility function, expressed as:

[0085] ;

[0086] in, It is a drone Overall utility score for the current task; It is its reputation score; It is the distance from its current position to the starting point of the task; This is its current remaining battery power; , , It is a weighting coefficient, and , , It is a function that unifies different physical dimensions. The scheduling system will select the drone with the highest utility score. To perform the task. Due to reputation score Weighting coefficients A positive credit score will increase the overall utility score of the drone, making it more competitive.

[0087] In this embodiment, users are allowed to register their private physical locations (such as their home balcony, windowsill, or yard) as a standardized delivery endpoint for drone delivery, i.e., a Home-Port. Simultaneously, user address privacy is protected by password to prevent its disclosure on a public blockchain. This registration and privacy protection mechanism is implemented through a collaborative scheme of on-chain commitment and off-chain decryption, with the specific implementation steps as follows:

[0088] Users initiate the Home-Port registration process through the decentralized application (DApp) front-end interface. Users first enter descriptive information about their physical address or select a precise drop-off point on a map. The application's front-end logic then calls a geocoding service to convert the user's address information into precise, machine-readable geospatial coordinates, typically including longitude, latitude, and altitude.

[0089] To prevent rainbow table attacks or brute-force attacks targeting coordinate hashes, the client application generates a high-entropy random string on the user's local device for this registration, denoted as . . This value is unique for each Home-Port registration and is the core secret for achieving privacy protection. The value must be properly safeguarded by the user or their client application, for example, by being encrypted and stored locally or managed by the user's digital wallet, and must not appear in plaintext form in any on-chain transaction or public network transmission.

[0090] The client application performs the hash commitment generation operation locally. It combines the standard-formatted raw coordinate string with the secret salt value generated in the previous step. The hash is then concatenated and calculated using a standard one-way cryptographic hash function (such as Keccak-256, which is natively compatible with the Ethereum Virtual Machine and can be verified in smart contracts). This final hash value is called the position commitment, denoted as . The formula for this process is as follows:

[0091] ;

[0092] In the formula, This represents the final calculated hash value of the location commitment that will be recorded on the blockchain; Represents a hash function; It is a string converted from precise geographic coordinates according to predefined rules, such as separating longitude, latitude, and altitude with commas and retaining a fixed number of decimal places; This represents a secret salt value held solely by the user; Represents string concatenation operations;

[0093] The user authorizes their wallet to send a registration transaction to the Home-Port management contract on the blockchain. The core payload of this transaction is the location commitment hash generated in the previous step. Instead of the original coordinates, the contract receives the transaction and establishes a mapping in its internal storage, binding the user's on-chain address (or a newly generated Home-Port unique ID) to this location commitment. At this point, the registration of a Home-Port is complete.

[0094] When a drone is officially assigned a delivery mission to this Home-Port by the system, a secure information disclosure process is triggered. Before the mission begins, the user (or their DApp agent) transmits the complete information necessary to decrypt the location—the original coordinates and a secret salt—through an encrypted, peer-to-peer off-chain channel. The information is sent directly to the authorized drone performing the mission. This off-chain channel can be established using the encryption key published in the drone's Distributed Identity (DID) document, ensuring that this sensitive information is only visible to the legitimate mission executor.

[0095] The drone receives the original coordinates and Upon receiving the information, its onboard computing unit will immediately perform a verification operation.

[0096] The drone will repeat the hash calculation process, that is, use the received coordinates and salt value to calculate a verification hash value. The calculation formula is:

[0097] ;

[0098] Then, this locally calculated Commitment to the target location obtained from the on-chain task description A comparison will be performed. Only when... and Only when the coordinates are completely identical can the drone confirm that the coordinates it received are genuine, accurate, and tamper-proof. After successful verification, the drone will use the coordinates for precise navigation and delivery at the last mile.

[0099] After the drone arrives at its delivery destination, GPS signal accuracy degrades in urban areas or near buildings. Therefore, this invention utilizes two heterogeneous sensing and communication methods—visual landmark recognition and short-range communication—in a coordinated manner. Through a phased and progressive strategy, it guides the drone to achieve precise positioning from meter-level to centimeter-level accuracy, and safely completes the final delivery authorization. The specific implementation steps of this coordinated mechanism are as follows:

[0100] GPS-assisted area approach. The drone first uses its built-in GPS and inertial measurement unit (IMU) for macroscopic path navigation based on the hash-verified Home-Port target geographic coordinates obtained from off-chain channels. The goal of this stage is to guide the drone into a pre-defined spherical area with a radius of several meters around the target coordinates. After entering this area, the drone switches from high-speed cruise mode to low-speed search mode and activates its multimodal perception system.

[0101] Attitude alignment and hovering are based on visual landmarks. The drone activates its onboard visual sensors (typically a downward-facing high-resolution camera) to begin performing a visual landmark recognition task. Here, a visual landmark is a unique, high-contrast, and easily machine-recognizable marker deployed on the Home-Port physical installation.

[0102] In one specific embodiment, the landmark can be a QR code or an ArUco marker containing a unique Home-Port ID. The drone's onboard computer continuously runs image processing algorithms to search for and locate the marker in real time within the video stream.

[0103] Once successfully identified, the drone can use attitude estimation algorithms in computer vision to calculate the drone's three-dimensional relative position (X, Y, Z translation) and three-dimensional relative attitude (roll, pitch, yaw) relative to the landmark by analyzing the perspective distortion of the marker in the image and referring to the real physical size of the marker known at the time of registration.

[0104] This frequently updated relative position information is then fed into the UAV's flight control system, serving as the core input to its position control closed loop. The flight control system uses a PID (proportional-integral-derivative) controller or more advanced control algorithms to adjust the motor speeds in real time, continuously reducing the error between the UAV's current position and the preset target position (e.g., 0.5 meters directly above a landmark). Through visual servoing, the UAV can autonomously correct positional deviations caused by GPS drift or external airflow interference, ultimately achieving stable hovering relative to the landmark with an error at the centimeter level.

[0105] Authentication and interaction based on short-range communication. Simultaneously or subsequently, as the UAV approaches the target via visual servoing and enters a stable hovering state, the system initiates a short-range communication interaction process, providing crucial security for delivery.

[0106] The drone uses its short-range communication modules (such as low-power, long-range LoRa modules for initial wake-up, or high-bandwidth Wi-Fi modules for short-range big data interaction) to broadcast a connection request signal containing its own DID to the surrounding area.

[0107] Upon receiving this signal, a smart Home-Port device with the corresponding communication capabilities will initiate an encrypted challenge-response handshake protocol. For example, the Home-Port can generate a random number and send it to the drone. The drone must sign the random number using its private key bound to its DID and send the signature (response) back to the Home-Port.

[0108] Home-Port then uses its known drone public key, which is tied to the mission, to verify the signature. Only if the verification is successful can Home-Port confirm that the currently hovering drone is the only legitimate and authorized delivery executor, and not any deceptive device.

[0109] Collaborative authorization and final delivery. This step embodies deep collaboration between the two modalities. Visual positioning ensures physical alignment, while communication interaction completes identity verification.

[0110] After successful communication confirmation, the Home-Port device can send a final, encrypted delivery authorization instruction to the drone. This instruction can include additional information, such as: the container lid is open, delivery is permitted, or the landing pad is empty, landing is permitted.

[0111] In a further embodiment, if the Home-Port itself is equipped with a higher-precision positioning system (such as Ultra-Wideband UWB), the final clearance command can also include a sub-centimeter-level fine-tuning correction vector for the drone's hovering position, based on its own measurements. Upon receiving this, the drone can superimpose this correction onto the visually servoed target to achieve ultimate positioning accuracy.

[0112] Only after the drone has met both the conditions of stable visual positioning and received communication authorization can it perform the final physical delivery action, such as opening the cargo door, dropping the package, or landing smoothly.

[0113] To ensure that drone delivery missions achieve both global path optimization and local environmental adaptability in the complex and dynamic urban airspace, this invention employs a hybrid navigation strategy. This strategy is a more in-depth and concrete implementation of path planning, organically combining classic graph search algorithms with deep reinforcement learning models to form a two-stage, collaborative decision-making framework, which may include:

[0114] Global path planning based on a discretized environment model. In the task scheduling phase, the system's computing nodes first assume the role of basic path planning. The goal of this phase is to calculate a globally optimal or suboptimal reference path from the starting point (warehouse) to the ending point (Home-Port) based on known, relatively static environmental information.

[0115] First, based on A / Dijkstra's global reference path generation. Upon receiving the task instruction, the compute node first performs global path planning. The core of this stage is to preprocess and abstract the three-dimensional spatial environment, which includes static obstacles (such as buildings and towers), a known flight map, and explicit airspace rules (such as no-fly zones and height-restricted zones), into a weighted graph.

[0116] In this diagram, each node represents a passable spatial location, while the edges connecting nodes are assigned a comprehensive cost. This cost not only reflects physical distance but also quantifies flight rules. For example, traversing areas with slight signal interference increases the cost of an edge, while nodes representing no-fly zones are assigned infinite costs, thus being naturally avoided at the algorithmic level.

[0117] Subsequently, the system utilizes A The (A-Star) algorithm searches this weighted graph. A The algorithm uses its classic cost evaluation function to guide the search direction in order to find a globally optimal reference path from the starting point to the ending point. The expression for this evaluation function is as follows:

[0118] ;

[0119] In the formula: Represents passing through nodes from the starting point. The estimated total cost to reach the target point. A The algorithm will prioritize expanding the node with the smallest f(n) value; This represents the journey from the starting point to the current node. The actual cumulative cost is a multi-factor weighted value, which may include the distance flown, the estimated energy consumption, and the penalty cost of flying over specific areas (such as signal interference areas). Represents starting from the current node The heuristic cost estimation for reaching the target point, to ensure an optimal solution, ensures that the estimated cost of this function never exceeds the actual cost. In this invention, a simple lower-level implementation uses nodes. The three-dimensional Euclidean distance between the target point and the target point.

[0120] Finally, A The algorithm ultimately outputs a sequence of three-dimensional waypoints, which constitutes the global reference flight trajectory of the UAV.

[0121] In one embodiment, the present invention also provides a real-time dynamic obstacle avoidance mode based on deep reinforcement learning. While the global reference path solves the macroscopic route problem, it cannot handle dynamic obstacles (such as other drones or birds) or unexpected situations (such as a temporarily appearing crane) that occur during flight and are not marked on a static map. Therefore, the present invention further introduces a proximal policy optimization model based on deep reinforcement learning to achieve dynamic, real-time intelligent obstacle avoidance.

[0122] Model localization: The PPO model is not used to replan the entire path, but to make local avoidance actions based on the UAV following the global reference path.

[0123] First, the trained PPO policy network is deployed on the UAV's onboard computing unit. Its input state consists of a set of multimodal sensor data and mission information, which may include: the UAV's current kinematic state (velocity, acceleration), the relative positions and velocities of surrounding obstacles detected by onboard sensors (such as LiDAR or stereo cameras), the relative vector with the next waypoint on the global reference path, and the remaining battery power, etc.

[0124] Action space: The model's output is a set of continuous, fine-tuning commands for the drone's flight attitude or velocity. For example, the output could be a three-dimensional vector ( ), representing the adjustment amount of the current X, Y, and Z axis speeds.

[0125] Reward Function: The training objective of the PPO model is to maximize the cumulative reward. Its reward function is used to guide the drone to achieve multiple objectives.

[0126] Path following reward: A positive reward is given when the distance between the drone and the global reference path decreases.

[0127] Efficiency Reward: A positive reward is given when the drone moves toward the next waypoint.

[0128] Safety penalty: A large negative reward is given when the drone comes within a safe threshold distance of any detected obstacle. The largest negative reward is given if a collision occurs.

[0129] Energy penalty: A slight negative reward is given for violent, high-energy-consuming maneuvers (such as rapid acceleration and sharp turns).

[0130] Real-time decision-making: In actual flight, the onboard PPO model operates at an extremely high frequency (e.g., tens of times per second). It continuously perceives the local environment and, based on the trained strategy, outputs the optimal fine-tuning actions in real time, guiding the UAV to avoid sudden obstacles without deviating too far from the main flight path, and autonomously returning to the original global reference path after the detour is completed.

[0131] By A By combining the algorithm's global planning capability with the PPO model's local and real-time response capability, this hybrid navigation strategy ensures that the UAV can select the globally optimal route while handling local emergencies, thereby achieving safe and efficient autonomous navigation in complex environments and reducing the probability of collisions.

[0132] In one embodiment, the present invention also provides a scheduling engine for automating resource allocation, which can make the optimal drone selection from a pool of hybrid public and private resources across the network for each newly generated delivery task. This selection process is linked to the aforementioned path planning and takes the path cost output by the hybrid navigation strategy as input, and integrates task requirements, drone real-time status, and long-term reputation, through a phased intelligent matching process, specifically including...

[0133] Hard screening of candidate qualifications. When a new task enters the task pool, the scheduling engine first initiates a qualification pre-screening process. The purpose of this stage is to quickly filter out all drones that clearly lack the basic capabilities to perform the task, using hard constraints with low computational cost. This screening process specifically includes:

[0134] Capability parameter matching: The engine analyzes the requirements for package weight and volume in the task description and compares them with the capability parameters registered by the drone on the chain, eliminating devices that do not meet the physical requirements. This includes:

[0135] Phase 1:

[0136] Path and energy estimation and verification: For each potential candidate drone, the scheduling engine will call the aforementioned A The algorithm generates a global reference path from the drone's current position to the mission's starting point and then to its destination. This serves two purposes: first, for subsequent navigation, and second, to obtain an accurate estimated flight range and corresponding estimated energy consumption at this moment. Based on this estimate, the engine then filters out drones with insufficient maximum range or insufficient remaining battery power to complete the estimated path (while maintaining a safety margin).

[0137] Reputation threshold filtering: For high-value or high-priority tasks, the engine reads the drone's dynamic reputation score and excludes drones with scores below a preset threshold.

[0138] Status Availability Check: The engine only considers drones that report an idle or standby status.

[0139] Phase Two:

[0140] Comprehensive utility function evaluation and ranking. After passing the first stage of screening, all remaining drones are considered qualified candidates. To find the optimal selection from these candidates, the scheduling engine will assign a task to each candidate drone. Calculate a comprehensive utility score for the current task. This score is a quantitative evaluation value; the higher the score, the more ideal the drone is as a executor. The utility score is calculated using a multi-factor weighted utility function, the expression of which is:

[0141] ;

[0142] In the formula, Representative candidate drones Total overall utility score for the current task; , , These represent the weighting coefficients for the three evaluation dimensions: path cost, reputation score, and energy redundancy, respectively, with a total of 1. , , It is a function that normalizes the original indicators of physical units to a uniform scoring range; Representing drones The total path cost required to perform this task is determined by A. The algorithm calculates a path that takes into account multiple factors such as flight distance, energy consumption, and airspace rules. The value directly reuses the results of the hybrid navigation strategy, ensuring the accuracy of cost assessment, and the normalization function. This is treated as an inverse relationship, meaning the lower the path cost, the higher the score; Representing drones The dynamic reputation score directly reflects its long-term service quality. Representing drones The predicted percentage of remaining battery power after completing the estimated path encourages the selection of drones that are more energy efficient and in better condition after the mission.

[0143] Calculate the overall utility score for all qualified candidate drones. Then, the scheduling engine executes the final assignment decision, selecting the drone with the highest utility score from the sorted list. ,Right now:

[0144] ;

[0145] As the optimal executor of this task.

[0146] The system then sent a signal to the drone. The control terminal sends an encrypted task invitation. If the drone accepts the invitation, its on-chain state will be updated to "Task in Progress," and it will begin following the pre-planned global path, while simultaneously activating the PPO model for real-time obstacle avoidance.

[0147] To ensure the robustness of the scheduling system, this logic also includes rollback and rescheduling mechanisms. If the optimal choice... If a task is not responded to or is rejected, the engine will automatically sort by utility score and send task invitations to the next candidate in sequence until the task is successfully accepted.

[0148] After the scheduling engine matches the optimal drone for the task based on the comprehensive utility function and plans its initial path using a hybrid navigation strategy, the entire process enters the verifiable computation and authorization phase. The core objective of this phase is to allow scheduling nodes that successfully complete path planning to prove the legitimacy of their scheduling results to the blockchain, without exposing their specific path schemes—their core competitive advantage—on the public ledger, thereby achieving task authorization and policy privacy protection in a decentralized environment. This phase consists of two stages:

[0149] The first stage:

[0150] First, the entire complex path planning and scheduling problem is rigorously and mathematically formalized into an Application-Specific Problem (ASP). This ASP is constructed as a standard triple structure. The scheduling strategy, rule constraints, and optimization objectives are clearly defined. It needs to be clarified that when generating the final proof π1, the objects directly affected and verified are R1CS (rules) and the specific inputs / outputs (solutions), while... (Strategy) and The (objective) serves as the off-chain driving force of this process, and the validity of its execution result will be verified by R1CS. The specific meaning of this triple is as follows:

[0151] Task allocation strategy model. This is the core algorithm that runs off-chain and schedules nodes, corresponding to the aforementioned automated resource allocation scheduling engine. It represents how nodes allocate tasks based on task descriptions. and the status of the entire network The ability to intelligently find the optimal solution. In this invention, this model can be concretized as A. A hybrid navigation strategy combining global path planning and a PPO deep reinforcement learning model is proposed, with decision optimization performed through a comprehensive utility function. This model itself is the proprietary intellectual property of the scheduling node, and one of the purposes of zero-knowledge proofs is to protect it from being leaked.

[0152] Task objective. This is the model. Optimization direction at runtime. It can be defined as "finding a way to maximize the overall utility distribution". "Maximizing the number of drones and their corresponding paths." At a deeper level, this means pursuing a comprehensive optimization in terms of time, energy consumption, and reliability. This goal guides the decision-making process of the scheduling engine.

[0153] R1CS: First-order constraint system. This is a mathematical expression of all the hard constraints that a legal path solution must satisfy. It doesn't care whether the path is "optimal," only whether it is "legal." It transforms real-world rules such as "the path cannot cross a no-fly zone" and "the total energy consumption must be less than the drone's current battery level" into algebraic circuits that the zk-SNARK protocol can understand and verify. This part is the core of zero-knowledge proof verification.

[0154] exist Within this framework, the specific inputs and constraints used to generate the first zero-knowledge proof (π1) can be further refined into the following three parts:

[0155] The first part is the public input: it contains all background information that can be publicly accessed and verified by all participants. This part of the data highly overlaps with the information that the scheduling engine relies on to make decisions, including: digitized 3D flight maps (including buildings, no-fly zones, etc.), detailed descriptions of the mission (such as pickup point coordinates, Home-Port target location commitment hash), package weight and dimensions, and mission time windows, etc.

[0156] The second part is the constraint system: a concretization of the aforementioned R1CS, which is a set of algebraic constraints that transform all real-world flight rules, physical limitations, and business logic into machine-understandable and verifiable mathematical relationships. Any legal path must simultaneously satisfy all constraints in this system.

[0157] The third part is private input or witness: this is where the scheduling node uses its private model. In the mission objective Guided by [the relevant information], the final solution was found. Specifically, it consists of a complete path sequence composed of continuous three-dimensional waypoints, along with the total estimated flight time and total estimated energy consumption calculated along that path. This information represents the labor output and policy privacy of the scheduling nodes, and is a core secret that needs to be protected by zero-knowledge proofs.

[0158] Modeling of First-Order Constraint Systems (R1CS). To be processable by modern zero-knowledge proof algorithms such as zk-SNARK, the aforementioned constraint systems are specifically modeled as a special algebraic circuit called a first-order constraint system. This process involves compiling abstract rules into concrete, computable constraint equations. The following is a textual explanation of how several key real-world rules are transformed into R1CS constraints:

[0159] Path validity constraints: To verify that the path does not pass through walls or enter no-fly zones, the system generates a constraint for each waypoint in the path. This constraint checks whether the coordinates of the point are within a passable voxel in the flight map. Additionally, connectivity constraints are generated between every two consecutive waypoints to verify that they are directly adjacent in the predefined flight network graph, ensuring path continuity.

[0160] Energy consumption constraint: The system generates an energy consumption calculation constraint for each segment of the path based on the drone's physical model. Then, the summation constraint adds up the energy consumption of all segments and verifies whether this total energy consumption is less than or equal to the available power reported by the selected drone (minus a preset safety redundancy).

[0161] Time window constraint: Similar to energy consumption, the system calculates the estimated flight time for each segment of the path and then sums them all up using a total constraint. Finally, a comparison constraint verifies whether this total flight time is within the time window specified by the mission, ensuring that the mission can be completed on time.

[0162] The generation and verification of the first zero-knowledge proof (π1). After the scheduling node successfully finds a path scheme that satisfies all R1CS constraints, it initiates the generation and verification process of the zero-knowledge proof in order to obtain the formal execution right of the task.

[0163] Proof generation: The scheduling node runs a zk-SNARK prover algorithm locally (off-chain). This algorithm takes the public input, the private input (i.e., the path scheme), and the R1CS constraint system as input, and outputs a tiny proof string, denoted as π1, that is independent of the private input. This π1 is the mathematical proof of the statement that I know a valid path scheme for this task that satisfies all the rules.

[0164] Proof Verification and Authorization: The scheduling node submits a transaction to the blockchain containing only the proof π1 and publicly available information such as the task ID. The target of this transaction is a smart contract called zkVerifier deployed on the chain. This contract has a pre-set verification key matching R1CS and executes a verification algorithm upon receiving π1. If the verification passes, the contract confirms that the scheduling node has indeed completed legitimate path planning. At this point, the zkVerifier contract triggers an authorization action, for example, updating the task's status to authorized in the task management contract and recording the DID of the authorized drone. This change in on-chain state constitutes formal authorization for the optimal drone selected in the previous section to perform subsequent physical flights, marking a crucial and reliable transition point from the planning phase to the execution phase of the task.

[0165] The second stage:

[0166] After the scheduling node successfully obtains task authorization through the first zero-knowledge proof (π1) and securely transfers execution rights to the selected drone, the task transitions from the digital planning phase to the execution phase. The significance of this phase lies in how to supervise and verify whether the drone executes the previously authorized plan in a decentralized and trustless manner, thereby providing an immutable basis for the final value settlement. This includes:

[0167] Mission execution and periodic state commitment. After takeoff and commencement of physical flight, the UAV's onboard sensors (such as GPS and IMU) continuously collect its spatiotemporal state data, forming an actual flight track log.

[0168] During flight, the drone's onboard computer collects actual waypoints (each point can be represented as a tuple containing timestamp, longitude, latitude, and altitude). Processing is done in batches. For each batch of n waypoints:

[0169]

[0170] The drone locally computes a cryptographic accumulator for this data, specifically using a Merkle tree in this embodiment. Then, it hashes each waypoint data point to obtain a set of leaf nodes, and then calculates the hash layer by layer upwards, ultimately obtaining a unique Merkle root, denoted as . , is represented as:

[0171] ;

[0172] in: Representing the The status commitment for each batch of track data, namely Merkelgen; Representing the The first batch One actual waypoint data; This represents a standard cryptographic hash function, such as Keccak-256; The standard Merkel root calculation process.

[0173] Furthermore, the drone will periodically (e.g., every minute or by flying a fixed distance) transmit this calculated Merkelgen. As a transaction payload, it is sent to a specific smart contract on the chain (such as a flight log contract) for recording. This series of on-chain transactions... Together, they form an immutable and cost-effective chain of evidence regarding this flight, laying a solid data foundation for subsequent final verification.

[0174] The second zero-knowledge proof (π2) is constructed using an application-specific problem (ASP). After the drone completes its delivery mission and successfully delivers the goods to the Home-Port, the final settlement verification phase begins. To prove that the actual execution process fully conforms to the pre-authorized plan, the system constructs a second application-specific problem (ASP), similar in structure to the first proof but with a different objective:

[0175] Common input: The common input at this point includes the task ID, as well as the entire Merklegen sequence recorded in the flight log contract in the previous step. .

[0176] Private Input / Witness: This part is the core secret of this proof, held by the node responsible for generating the proof (usually the original scheduling node). It includes:

[0177] The complete original route plan, which was planned in the first phase and whose validity was proven by π1, is the waypoint sequence.

[0178] The drone uploads a complete actual flight log after the flight, and for each actual flight point, it can prove that it belongs to a certain on-chain Merkle root. The required Merkel proof path.

[0179] This ASP construction links the first and second phases together, with the aim of verifying the consistency between the two.

[0180] The second proof (π²) R1CS modeling and core constraints. Similar to the first stage, to generate the π² proof, this new ASP must also be modeled as an R1CS circuit. The core constraints of this circuit are for verifying consistency, specifically including:

[0181] Track log integrity constraints: For each actual track point in the private input, the circuit includes a constraint that uses its corresponding Merkle proof path to verify that it is indeed part of a public Merkle root that is already on-chain. This set of constraints ensures that the actual track data used for verification is authentic and not forged.

[0182] Planning-Execution Compliance Constraints: This is the core of the entire π² verification process. The circuit contains a series of core constraints to prove the fit between planning and execution. Specifically, for each critical waypoint in the original planned path, the circuit must have a constraint to verify that in the complete actual track log, there exists at least one actual trackpoint such that the three-dimensional Euclidean distance between these two points is less than a preset, extremely small tolerance value.

[0183] This constraint, under zero-knowledge conditions, strongly demonstrates that the actual flight trajectory of the drone is macroscopically completely consistent with the pre-authorized path.

[0184] The generation and final settlement of the second zero-knowledge proof (π2). Once the R1CS circuit is constructed, the node holding the private witness can generate and submit the final execution proof, thereby closing the trust loop of the entire task.

[0185] Proof Generation: This node runs the zk-SNARK prover, taking the ASP of π2 as input, and generates an extremely concise proof string π2. π2 mathematically proves the planned path and an actual track that has been committed to on the chain, and proves that the two paths are completely consistent within a preset tolerance range.

[0186] Verification and Settlement: The node submits π2 to a second zkVerifier contract (or a different function of the same contract) on the chain. This contract verifies the π2 using a verification key that matches the R1CS circuitry of π2. Once verification is successful, the task has been successfully planned and executed. At this point, the contract triggers the final atomic settlement logic: it automatically invokes the payment contract to transfer the agreed-upon reward to the drone owner (hardware and energy provider) and the scheduling node (computing power and strategy provider), while simultaneously invoking the reputation contract to add a reputation score to both parties' DIDs, and finally marks the task status as completed and settles the payment.

[0187] After the scheduling node passes the second zero-knowledge proof (π2), the task flow moves from the execution verification phase, which specifically includes:

[0188] The incentive triggering mechanism and token standard, specifically, involve the zkVerifier contract on the chain successfully verifying the π2 proof, which then calls the task settlement contract. This call is completed within an atomic operation of the blockchain. The incentive medium used by this settlement contract for value transfer is a native utility token conforming to the ERC20 standard, which can be named Delivery-Token (DELT) in this invention. With a standardized incentive medium, the next key issue is how to accurately calculate the amount of reward to be distributed to fairly reflect the quality of task execution.

[0189] The final reward is determined by a dynamic reward calculation formula embedded in the task settlement contract. This formula is based on the task's base reward and adjusted according to multiple verifiable performance indicators, ensuring the transparency, fairness, and automation of the reward calculation.

[0190] The formula for calculating this reward can be expressed as:

[0191] ;

[0192] The total reward will then be distributed among the different contributors:

[0193] ;

[0194] ;

[0195] In the formula, This represents the final total reward amount payable for this task after performance adjustments; This represents the basic reward that the task publisher pre-deposits and locks in the contract when creating the task; This represents the overall performance coefficient, which can be positive (reward) or negative (penalty). and These represent the final reward amounts allocated to the drone owner and the scheduling node, respectively. and : Represents the reward distribution ratio between drone owners and scheduling nodes.

[0196] And the overall performance coefficient The calculation of the dynamic reward is central and is determined by the following real data verified during the proof of π²:

[0197] ;

[0198] In the formula, , , These are the weighting coefficients for various performance indicators (time, energy consumption, path offset), which are also set by DAO governance and used to adjust the network's incentive emphasis for different behaviors. This represents the estimated flight time to complete the mission, calculated by the path planning module during the mission scheduling phase. The ratio represents the actual time taken for a drone to complete its delivery and be confirmed by the system. It intuitively reflects the time efficiency of the task; and : These represent the planned electricity consumption and the actual electricity consumption, respectively; Average path offset distance.

[0199] An automated incentive model ensures that every contribution receives fair quantitative evaluation and value feedback, thereby driving the entire decentralized delivery network to continuously improve in a more efficient, reliable, and economical direction.

[0200] After the smart contract automatically completes the reward distribution for that task, the execution data for that task is recorded in the feedback mechanism. Specifically, this includes:

[0201] When the mission settlement contract successfully allocates rewards, it invokes the reputation contract in the system. This reputation contract receives the exact same performance data used in the reward calculation, including the ratio of actual flight time to planned time, the ratio of actual energy consumption to planned energy consumption, and the average path deviation. It then scores this data, specifically:

[0202] A successful mission of standard quality adds a base reputation score to the DID of both the drone owner and the scheduling node; if the mission is performed exceptionally well (e.g., significantly faster than planned and with lower energy consumption), additional bonus points are awarded; conversely, points are deducted for poor performance. Mission failures or fraudulent activities (such as π2 verification failure) will result in a reduction of reputation points.

[0203] This dynamic reputation score is directly fed back to the task matching process, serving as a key weighting factor in the scheduling engine's evaluation of candidate drones. This allows drones with high reputation scores to receive significant priority in future task allocation, especially when faced with high-value or high-priority tasks, thus creating a positive feedback loop.

[0204] High-quality service leads to high reputation, which in turn brings more job opportunities and rewards, thus incentivizing all participants to continuously provide the best service. Conversely, low-quality service leads to lower reputation.

[0205] Furthermore, the decentralized governance structure of this invention is based on its native token, DELT. When network participants (e.g., a consortium of numerous drone owners) believe that a key parameter in the system needs adjustment, they can initiate a governance proposal by staking a certain amount of DELT tokens.

[0206] In one embodiment, once a proposal is formally submitted to the DAO's governance contract, a public voting period (e.g., 7 days) begins. During this period, all DELT token holders can vote for, against, or abstain on the proposal by interacting with the governance contract.

[0207] After the voting period ends, two conditions are usually required for a resolution to pass: a quorum, meaning the total number of tokens participating in the vote must exceed a minimum percentage of the total supply to prevent a small number of people from easily manipulating the decision; and an absolute majority, meaning the number of votes in favor must exceed the number of votes against.

[0208] Once a proposal is approved, the DAO can automatically execute the instructions in the proposal. For example, it can directly call a specific function in the task settlement contract to change the reward weight coefficient from 0.4 to 0.5. In this way, true, community-driven, transparent, and trustworthy decentralized governance is achieved.

Claims

1. A blockchain-based Web3 automated drone delivery system, characterized in that, The system is built on the Web3 infrastructure consisting of blockchain, decentralized identity protocol and smart contract, including: An unmanned aerial vehicle identity management module for registering each unmanned aerial vehicle to establish a chain identity containing a distributed identity and recording a digitally signed capability parameter vector; A path planning and task matching module for screening candidate unmanned aerial vehicles from the chain according to task requirements and planning paths for the candidate unmanned aerial vehicles to calculate comprehensive path costs; A two-stage zero-knowledge proof verification module for generating a first zero-knowledge proof to verify the legality of path planning in the task authorization stage and generating a second zero-knowledge proof to verify the consistency of the actual flight log and the planned path after task execution; An incentive and state update module for performing reward distribution after the second zero-knowledge proof passes the on-chain verification and updating the dynamic reputation score of the unmanned aerial vehicle according to the task execution data.

2. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, The distributed identity is anchored with a non-fungible token created for the unmanned aerial vehicle and is composed of the unique tokenId, blockchain network ID and contract address of the non-fungible token; And the unmanned aerial vehicle identity management module is further configured to record the public key, authentication method and on-chain interaction address of the unmanned aerial vehicle in the DID document associated with the on-chain identity, and store the DID document in the decentralized storage network.

3. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, The system further includes a Home-Port terminal and a precise delivery module, which is configured to: In the registration stage, obtain the geographic spatial coordinates of the user-specified delivery point, combine a secret salt value independently generated for this registration, calculate the location commitment hash through a hash function, and bind the location commitment hash and the user address on the chain; In the task execution stage, through an encrypted off-chain channel, send the geographic spatial coordinates of the user-specified delivery point and the secret salt value independently generated when the unmanned aerial vehicle is registered only to the authorized unmanned aerial vehicle.

4. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, The path planning and task matching module scores and sorts the candidate unmanned aerial vehicles through a comprehensive utility function, wherein the input of the comprehensive utility function includes: The dynamic reputation score of the unmanned aerial vehicle; The comprehensive path cost of the unmanned aerial vehicle executing the task; The predicted remaining battery percentage of the unmanned aerial vehicle after completing the task.

5. The blockchain-based Web3 automated drone delivery system of claim 4, wherein, The comprehensive path cost is calculated by a hybrid navigation strategy, which includes: Adopting A algorithm, a global reference path is calculated on a weighted graph constructed based on static obstacles and airspace rules; Using a proximal strategy optimization model to perform real-time dynamic obstacle avoidance based on onboard sensor data and making local adjustments to the global reference path.

6. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, When generating the first zero-knowledge proof, the two-stage zero-knowledge proof verification module includes: Taking the path sequence of path planning as private input and taking the digital three-dimensional flight map and task description as public input, proving that the private input satisfies the predefined first-order constraint, and the first-order constraint includes the constraints of path legality, energy consumption limit and time window.

7. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, When generating the second zero-knowledge proof, the two-stage zero-knowledge proof verification module includes: During the execution of the task by the unmanned aerial vehicle, receiving and recording the Merkle root generated by periodically submitting the actual flight log by the unmanned aerial vehicle after hash operation; After the task is completed, the complete actual flight log and the original path planning path sequence are taken as private inputs to prove that each part of the actual flight log can be traced back to the chained Merkle root.

8. The blockchain-based Web3 automated drone delivery system of claim 1, wherein, The incentive and state update module determines the final total reward by a dynamic reward calculation formula when performing reward allocation, including: The ratio of actual time consumption to planned flight time; The ratio of actual power consumption to planned power consumption; The average path offset distance.

9. The blockchain-based Web3 automated drone delivery system of claim 3, wherein, The Home-Port terminal and the precise delivery module after the UAV reaches the destination: Through visual servo, the onboard camera identifies the visual landmarks deployed on the Home-Port to achieve hovering positioning; Through short-range communication, the UAV's private key is used to sign the challenge to complete the authentication of the UAV's identity, and to authorize the final delivery after successful authentication. 10.A Web3 automated drone delivery method based on blockchain, based on the Web3 automated drone delivery system based on blockchain in any one of claims 1-9, characterized in that, The steps include: Identity registration and parameter reporting: generate a distributed identity for the UAV, and record the owner's signed capability parameter vector of the UAV on the blockchain; Path planning and task matching: when the task is generated, the candidate UAVs are screened and sorted, and the optimal candidate UAV is planned with a path planning path sequence; Planning verification and trusted authorization: generate the first zero-knowledge proof based on two-stage zero-knowledge proof verification, prove to the blockchain that the path planning path sequence scheme meets all flight rules, and after verification, authorize the UAV to contract tasks; Task supervision and state monitoring: the UAV periodically calculates and reports the Merkle root of the actual flight log when executing the contract task; Execution compliance verification: after the task is completed, the second zero-knowledge proof is generated by two-stage zero-knowledge proof verification, and the blockchain is proved that the actual flight track committed and the authorized path planning path sequence are consistent; Incentive allocation and update: after the second zero-knowledge proof verification is passed, the task reward is calculated and allocated, and the dynamic reputation score of the UAV is updated according to the comprehensive performance score of this task.

Images