Transaction execution result determination method, device and electronic equipment

Abstract

The present invention discloses a method, device, and electronic device for determining a transaction execution result. The method comprises: receiving a transaction request; determining the first time of receiving the transaction request in response to the transaction request; generating a first hash value corresponding to the target transaction based on target transaction information and the first time; encrypting the first hash value based on the initiator's private key to obtain a target digital signature; sending the target digital signature and target transaction information to a blockchain so that the blockchain obtains a verification result; receiving the verification result returned by the blockchain, and determining, based on the verification result, whether the target transaction can be executed. The present invention solves the technical problem in related technologies that, when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security for payment transactions.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a method, device and electronic device for determining transaction execution results. Background Art

[0002] In related technologies, when executing payment transactions, a third-party centralized organization is usually used to verify the security of the transaction. However, centralized organizations are prone to the risk of being attacked and prone to internal problems, resulting in lower security of payment transactions.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] Embodiments of the present invention provide a method, device, and electronic device for determining transaction execution results to at least address the technical problem in related technologies that, when executing payment transactions, centralized institutions are prone to the risk of being attacked and having internal problems, resulting in low security of payment transactions.

[0005] According to one aspect of an embodiment of the present invention, a method for determining a transaction execution result is provided, comprising: receiving a transaction request, wherein the transaction request carries target transaction information; determining, in response to the transaction request, a first time of receiving the transaction request; generating a first hash value corresponding to the target transaction based on the target transaction information and the first time; encrypting the first hash value using an initiator's private key to obtain a target digital signature; sending the target digital signature and the target transaction information to a blockchain, so that the blockchain obtains a verification result, the verification result including an abnormal transaction result and, if the abnormal transaction result is non-abnormal, also multiple transaction results, the blockchain determining whether the target transaction is an abnormal transaction result based on a second hash value and a third hash value, the second hash value being obtained by the blockchain using the initiator's public key to decrypt the received target digital signature, the third hash value being generated by the blockchain based on the received transaction information and the second time, and if the abnormal transaction result is non-abnormal, the blockchain determining whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; receiving a verification result returned by the blockchain, and determining, based on the verification result, an execution result indicating whether the target transaction can be executed.

[0006] Optionally, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: when the target transaction information includes an initiator account, a recipient account, and a payment amount, determining a first account behavior of the initiator account and a second account behavior of the recipient account;

[0007] Determine a first security index of the target transaction based on the first account behavior and the second account behavior; determine a second security index of the target transaction based on the historical transaction records of the initiator account and the payment amount; determine a target security index based on the first security index and the second security index; and generate the first hash value based on the target transaction information and the first time when the target security index is greater than a predetermined security threshold.

[0008] Optionally, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: determining multiple information items included in the target transaction information; determining a security item whose confidentiality index is greater than a predetermined confidentiality threshold from the multiple information items; performing masking on data corresponding to the security item to obtain the masked target transaction information; and generating a first hash value corresponding to the target transaction based on the masked target transaction information and the first time.

[0009] Optionally, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: determining an information length of the target transaction information; compressing the target transaction information when the information length is greater than a predetermined length threshold to obtain compressed target transaction information; and generating a first hash value corresponding to the target transaction based on the compressed target transaction information and the first time.

[0010] Optionally, before sending the target digital signature and the target transaction information to the blockchain, the method further includes: compiling a contract code based on a transaction scenario corresponding to the target transaction, wherein the contract code includes a code for determining whether it corresponds to an abnormal transaction and a code for determining whether it corresponds to multiple transactions; and deploying the contract code in the blockchain so that the blockchain executes the contract code.

[0011] Optionally, the second time is at least one of the following: the second time is sent by the terminal to the blockchain, and the second time is determined based on data reception time and data transmission time.

[0012] Optionally, the execution result of determining whether the target transaction can be executed based on the verification result includes: if the target transaction information includes the initiator account, the recipient account, and the payment amount, and the verification result is that the verification is passed, determining the execution result as executing the target transaction, deducting the payment amount from the initiator account, and transferring the payment amount to the recipient account to determine the payment result.

[0013] According to one aspect of an embodiment of the present invention, a transaction execution result determination device is provided, comprising: a receiving module for receiving a transaction request, wherein the transaction request carries target transaction information; a first determining module for determining a first time of receiving the transaction request in response to the transaction request; a generating module for generating a first hash value corresponding to the target transaction based on the target transaction information and the first time; an encrypting module for encrypting the first hash value based on an initiator's private key to obtain a target digital signature; and a sending module for sending the target digital signature and the target transaction information to a blockchain, so that the blockchain obtains a verification result, wherein the verification result includes Abnormal transaction results and multiple transaction results, the blockchain determines whether the target transaction is an abnormal transaction result of an abnormal transaction based on the second hash value and the third hash value information, the second hash value is obtained by the blockchain using the initiator's public key to decrypt the target digital signature, and the third hash value is generated by the blockchain based on the target transaction information and the second time. When the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; the second determination module is used to receive the verification result returned by the blockchain, and determine the execution result of whether the target transaction can be executed based on the verification result.

[0014] According to one aspect of an embodiment of the present invention, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement any one of the above-mentioned transaction execution result determination methods.

[0015] According to one aspect of an embodiment of the present invention, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any one of the transaction execution result determination methods described above.

[0016] In an embodiment of the present invention, a transaction request is received, wherein the transaction request carries target transaction information; in response to the transaction request, a first time of receiving the transaction request is determined; a first hash value corresponding to the target transaction is generated based on the target transaction information and the first time; the first hash value is encrypted using the initiator's private key to obtain a target digital signature; the target digital signature and the target transaction information are sent to a blockchain so that the blockchain obtains a verification result, the verification result including an abnormal transaction result and, if the abnormal transaction result is non-abnormal, multiple transaction results; the blockchain determines whether the target transaction is an abnormal transaction based on a second hash value and a third hash value, the second hash value being obtained by the blockchain using the initiator's public key to decrypt the received digital signature; the third hash value being generated by the blockchain based on the received transaction information and the second time; if the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result based on the third hash value; the verification result returned by the blockchain is received, and an execution result of whether the target transaction can be executed is determined based on the verification result. By receiving and responding to the transaction request containing the target transaction information submitted by the initiator, an accurate data foundation is provided for subsequent determination of the transaction execution result based on the specific target transaction information. By determining the first time of a transaction request, this first time can be used to verify transaction order, avoid double spending, detect transaction delays or anomalies, and ensure transaction timeliness and validity. By generating a first hash value corresponding to the target transaction based on the target transaction information and the first time, the integrity and immutability of the target transaction information are ensured, ensuring the legitimacy and validity of the transaction while protecting user privacy. Based on the hash value comparison, the blockchain generates a verification result. Based on the second and third hash values, the blockchain determines whether the target transaction is an abnormal transaction, preventing tampering of transaction data during transmission and the risk of double spending. Thanks to the blockchain's immutability, transaction records and verification results are permanently preserved, ensuring transaction transparency and traceability. This ensures the legitimacy and validity of transactions on a decentralized basis, improving transaction security and credibility. This addresses the technical issue in related technologies where centralized institutions are susceptible to attacks and internal issues when executing payment transactions, resulting in lower security. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0018] Figure 1 is a flowchart of a method for determining a transaction execution result according to an embodiment of the present invention;

[0019] Figure 2 is a timing diagram for determining transaction execution results provided by an optional embodiment of the present invention;

[0020] Figure 3 is a timing diagram of the contract code processing mechanism provided by an optional embodiment of the present invention;

[0021] Figure 4 4 is a structural block diagram of a device for determining a transaction execution result according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0024] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0025] Blockchain: Blockchain is a distributed database technology in which data is added to an ever-growing chain in the form of blocks. Each block contains the hash value of the previous block, a timestamp, and transaction data. This structure ensures that data on the blockchain is virtually impossible to tamper with once recorded, as modifying the data in one block would require recalculating the hash values ​​of all subsequent blocks, which is extremely computationally difficult.

[0026] Smart Contracts: A smart contract is a computer program or protocol that automatically executes the terms of a contract. It runs on a blockchain and can be considered a self-executing contract, where the rules and penalties are written directly into the code. When certain conditions are met, the smart contract automatically performs a pre-defined action, such as transferring assets, making payments, or executing other transactions.

[0027] Hash algorithm: A hash algorithm is a common encryption algorithm in computer science that converts input data of arbitrary length (often called a "message") into an output of fixed length (often called a "hash value" or "digest"). For each unique piece of input data, the hash algorithm produces a unique hash value. Even slight changes in the input data will result in a completely different hash value. It is difficult (computationally infeasible) to infer the original input data from the hash value, providing a one-way encryption method for data.

[0028] Apache Kafka: Apache Kafka is an open source stream processing platform. Apache Kafka is mainly used to build real-time data pipelines and streaming applications. It can process and transmit large amounts of streaming data with high throughput and low latency. Apache Kafka's design makes it very reliable and efficient in distributed systems. It is suitable for a variety of scenarios such as log aggregation, messaging, data integration, and streaming data analysis.

[0029] Apache Flink: Apache Flink is the Apache stream processing framework, or Apache real-time data processing engine. Apache Flink is an open-source distributed processing engine designed for real-time computations on both streaming and batch data. It provides efficient and reliable data stream processing, capable of handling both unbounded (continuous) and bounded (finite) data streams.

[0030] NoSQL databases: NoSQL databases are non-relational databases designed to process large amounts of data, particularly complex, unstructured, or semi-structured data that doesn't conform to traditional SQL (Structured Query Language) rules. They typically offer greater scalability and flexibility, supporting large-scale data storage and fast data access. They are suitable for scenarios such as real-time big data processing, high-concurrency read / write operations, and distributed storage.

[0031] MongoDB Database: MongoDB is a document-oriented, or schema-free, database. It is an open-source NoSQL database that stores data in JSON (JavaScript Object Notation) or BSON (BinaryJSON) format, making data storage and querying more flexible and efficient. MongoDB is particularly well-suited for handling large, complex data sets. It offers high performance, high availability, and scalability, making it widely used in websites, mobile applications, real-time data analytics, content management systems, and other application scenarios.

[0032] Cassandra: Cassandra is a high-performance, distributed NoSQL database system designed to handle large amounts of data, providing high availability and linear scalability. It is particularly well-suited for distributed deployments across data centers. Due to its excellent read and write performance and fault tolerance, Cassandra is widely used in applications with large data volumes, frequent read and write operations, and high data consistency requirements.

[0033] Redis: Redis, or Remote Dictionary Server, is an open-source, high-performance, in-memory data structure storage system that can be used as a database, cache, and message middleware. It supports a variety of data structures, such as strings, hashes, lists, sets, and ordered sets, making it extremely powerful for handling complex data structures and achieving efficient data access. Because Redis stores data in memory, it offers very fast read and write speeds, making it suitable for applications requiring high-speed data access and caching, such as real-time data analysis, session management, and message queuing.

[0034] Docker: Docker is container technology, or containerization platform. Docker is an open source containerization platform that provides lightweight, portable containers for encapsulating and running applications. Docker containers can run on any host that supports Docker, including development, testing, and production environments, making application deployment and migration easier and more consistent. Docker uses the concepts of images and containers to package and isolate applications and their dependencies, while also providing network communication and data persistence between containers. Docker's containerization technology is widely used in continuous integration, continuous deployment (CI / CD), microservices architecture, cloud computing, and other fields, providing strong support for application development, testing, and deployment.

[0035] Kubernetes: Kubernetes is a container orchestration system, or container management platform. Kubernetes is an open source container orchestration system used to automate the deployment, scaling, and management of container applications. It can deploy containerized applications on multiple servers in a cluster, ensuring high availability and performance of applications through automated scheduling and load balancing. Kubernetes provides a set of standardized APIs and tools that allow developers to describe the deployment, configuration, and policies of applications in a declarative manner. Kubernetes is responsible for implementing these descriptions in the cluster, including operations such as starting, stopping, scaling, and self-healing containers. Kubernetes' container orchestration capabilities make it one of the key technologies for building containerized microservice architectures, achieving multi-cloud and hybrid cloud deployments, and supporting DevOps practices.

[0036] Example 1

[0037] According to an embodiment of the present invention, an embodiment of a method for determining a transaction execution result is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0038] Figure 1 is a flow chart of a method for determining a transaction execution result according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0039] S102, receiving a transaction request, wherein the transaction request carries target transaction information;

[0040] In step S102 provided in this application,

[0041] Among them, a transaction request is involved. The transaction request is initiated by the target account and is a request for executing a transaction operation. The transaction request carries target transaction information.

[0042] Among them, the target transaction information is involved. The target transaction information is the data carried in the transaction request to describe the transaction intention and details, which may include the identity information of the two parties to the transaction, the transaction amount, the transaction time, the transaction type, and possible transaction conditions or constraints.

[0043] Through the transaction request, the transaction request carries the target transaction information, providing an accurate data basis for the subsequent determination of the transaction execution results based on these specific target transaction information, thereby helping to ensure that the correct transaction execution payment logic is matched according to the transaction request, as well as the relevant target transaction information of the target account. This will help to solve the technical problem in related technologies that when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security of payment transactions.

[0044] It should be noted that there is no specific restriction on the method of receiving transaction requests, and customized settings can be made according to actual applications and scenarios.

[0045] S104, in response to the transaction request, determining a first time of receiving the transaction request;

[0046] In step S104 provided in the present application, the transaction request is responded to and the first time of receiving the transaction request is determined.

[0047] The first time involved is the time when the transaction request is received. This first time can be used to verify the order of transactions, avoid double payments, detect transaction delays or anomalies, and ensure the timeliness and effectiveness of transactions. Taking into account the time delays of network transmission and system processing, the time when the transaction system receives the transaction request is considered the time when the transaction request was initiated. For example, if the target account initiates a transfer request at 14:30:00, the transaction system will record the timestamp at the moment of receiving this request. Assuming the time recorded by the system is 14:30:02 (taking into account the time delays of network transmission and system processing), then 14:30:02 is the first time the transaction request was received.

[0048] By responding to transaction requests and determining the first time they were received, the time when the transaction request was initiated can be clearly defined, solving the problem of accurately recording the first time of the transaction request, and helping to achieve fairness and consistency in transactions. By accurately recording the first time a transaction request arrives, it is possible to ensure that transactions are executed in the expected order, avoid confusion in transaction sequencing, and ensure the correctness of transaction logic. Furthermore, as part of transaction data, the first time can be used for subsequent audits, dispute resolution, and compliance checks, ensuring transaction transparency and traceability, thereby helping to reduce transaction errors and disputes and improving the user experience.

[0049] It should be noted that the method for determining the first time of receiving a transaction request in response to the transaction request is not specifically limited here and can be customized according to actual applications and scenarios.

[0050] S106, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time;

[0051] In step S106 provided in the present application, a first hash value corresponding to the target transaction is generated.

[0052] The first hash value is a fixed-size output value generated by a hash algorithm based on the target transaction information and the time the transaction was received after the transaction request is received. This first hash value is a unique identifier for the target transaction and is used to verify the integrity and consistency of the transaction data.

[0053] Based on the target transaction information and the first time, a hash algorithm is used to generate a first hash value corresponding to the target transaction. This can be used to verify whether the target transaction information has been tampered with during transmission and to ensure that the transaction data remains unchanged during subsequent processing, thereby ensuring the integrity and immutability of the target transaction information. By generating a first hash value corresponding to the target transaction based on the target transaction information and the first time, it is possible to ensure the legitimacy and validity of the transaction while protecting user privacy, thereby facilitating subsequent transaction verification, recording, and tracking, and further helping to resolve the technical problem in related technologies that centralized institutions are susceptible to attacks and internal problems when executing payment transactions, resulting in low security for payment transactions.

[0054] It should be noted that the method for generating the first hash value corresponding to the target transaction based on the target transaction information and the first time is not specifically limited here and can be customized according to actual applications and scenarios.

[0055] S108, encrypting the first hash value according to the initiator's private key to obtain a target digital signature;

[0056] In step S108 provided in this application, the target digital signature is obtained.

[0057] Among them, the private key is involved, which is one of a pair of keys in public key cryptography and is used to decrypt information and create digital signatures.

[0058] Among them, a target digital signature is involved, and the target digital signature is a signature obtained by encrypting the first hash value using the initiator's private key.

[0059] By encrypting the first hash value with the initiator's private key, the resulting target digital signature addresses the security and verification issues of transaction requests. The target digital signature not only verifies the initiator's identity but also ensures the integrity and non-tampering of the transaction request data during transmission. This ensures the authenticity and integrity of the transaction request, prevents identity impersonation and data tampering, and effectively distinguishes legitimate transaction requests from illegal or forged requests, protecting user transaction security, ensuring the fairness and reliability of transactions, and ultimately improving the user transaction experience.

[0060] It should be noted that the method of encrypting the first hash value based on the initiator's private key to obtain the target digital signature is not specifically limited here and can be customized according to actual applications and scenarios.

[0061] S110, sending the target digital signature and target transaction information to the blockchain, so that the blockchain obtains a verification result, the verification result including the abnormal transaction result, and if the abnormal transaction result is non-abnormal, also including multiple transaction results, the blockchain determines whether the target transaction is an abnormal transaction result of an abnormal transaction based on the second hash value and the third hash value, the second hash value is obtained by the blockchain using the initiator's public key to decrypt the received target digital signature, and the third hash value is generated by the blockchain based on the received transaction information and the second time, if the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value;

[0062] In step S110 provided in this application, the target digital signature and target transaction information are sent to the blockchain so that the blockchain can obtain a verification result.

[0063] Among them, the blockchain is involved. The blockchain is a distributed ledger technology composed of a series of blocks, each of which contains multiple transaction records. The blockchain uses cryptographic technology to ensure the integrity and security of the data. Once the transaction records are on the chain, they cannot be changed, which improves the transparency and trust of the transaction.

[0064] Among them, the verification result is involved. The verification result is the result obtained after performing abnormal transaction verification on the transaction request based on the target digital signature and the target transaction information. The verification result includes the abnormal transaction result.

[0065] Among them, abnormal transaction results are involved, which are the results of discovering abnormalities in the target transaction information or target digital signature during the transaction verification process, for example, the target transaction information has been tampered with.

[0066] This involves multiple transaction results, which are verification results obtained when a transaction request is deemed to be a duplicate submission or a double-spend attempt. For example, if the same transaction is detected to have been submitted multiple times, a multiple transaction result will be generated to identify the duplicate status of the transaction and prevent the reuse of funds.

[0067] The second hash value is obtained by performing a hash operation on the decrypted target digital signature using the initiator's public key. This second hash value should match the third hash value to verify the validity of the target digital signature.

[0068] This involves a third hash value, which is generated based on the received transaction information and the time the blockchain receives the transaction request (i.e., the second time). This third hash value is used to confirm the uniqueness and order of transactions, ensure the integrity of transaction data, and avoid duplicate transactions.

[0069] This involves a public key, which is one of a pair of keys in public key cryptography and is used to encrypt data or verify digital signatures. This public key is used to verify the initiator's target digital signature, ensuring that the transaction request comes from the correct initiator.

[0070] Among them, a second time is involved, which is the time point when the transaction request is received by the blockchain node. The second time can be used to generate a third hash value to help ensure the order of transactions and avoid tampering with transaction time.

[0071] The blockchain uses the public key provided by the initiator to decrypt the received target digital signature, generating a second hash value. This value is then compared with a third hash value to verify the validity of the digital signature. If the second and third hash values ​​do not match, the transaction is considered abnormal and an abnormal transaction result is generated. This comparison ensures that the transaction data has not been tampered with during transmission, thereby improving data integrity and reliability. Simultaneously, the blockchain node generates a third hash value based on the received transaction information and the recorded second time of receipt. This hash value is then checked to see if it matches any previously recorded hash values ​​to detect duplicate transactions. Based on the hash value comparison, a verification result is generated. If the third hash value matches the previously recorded hash value, the transaction is considered a duplicate and a multiple transaction result is generated. This third hash value verification prevents the reuse of the same funds, mitigates the risk of double spending, ensures that transactions are processed in chronological order, and prevents transaction time tampering. Through the immutability of blockchain, transaction records and verification results are permanently preserved, providing guarantees for the transparency and traceability of transactions, thereby ensuring the legitimacy and validity of transactions on a decentralized basis, and improving the security and credibility of transactions.

[0072] It should be noted that there is no specific limitation on the method of sending the target digital signature and target transaction information to the blockchain so that the blockchain can obtain the verification result, and customized settings can be made according to actual applications and scenarios.

[0073] S112, receiving the verification result returned by the blockchain, and determining whether the target transaction can be executed based on the verification result.

[0074] In step S112 provided in this application, the verification result returned by the blockchain is received, and based on the verification result, the execution result of whether the target transaction can be executed is determined.

[0075] Among them, the execution result is involved, which is the final result of determining whether to execute the target transaction based on the verification result.

[0076] By receiving verification results returned by the blockchain and determining whether the target transaction can be executed based on the verification results, this ensures that only authorized and verified transactions can be executed, protecting user transaction security. By detecting and blocking abnormal or duplicate transactions, illegal transactions are prevented, avoiding unnecessary financial losses and fraud. The blockchain's decentralized verification mechanism ensures the fairness and transparency of transactions, thereby resolving the technical problem in related technologies that centralized institutions are susceptible to attacks and internal issues when executing payment transactions, resulting in low payment security.

[0077] It should be noted that the method for receiving the verification result returned by the blockchain and determining whether the target transaction can be executed based on the verification result is not specifically limited here and can be customized according to actual applications and scenarios.

[0078] Through the above steps S102-S112, a transaction request is received, wherein the transaction request carries target transaction information; in response to the transaction request, a first time of receiving the transaction request is determined; a first hash value corresponding to the target transaction is generated based on the target transaction information and the first time; the first hash value is encrypted based on the initiator's private key to obtain a target digital signature; the target digital signature and the target transaction information are sent to the blockchain so that the blockchain obtains a verification result, the verification result including an abnormal transaction result, and when the abnormal transaction result is non-abnormal, it also includes multiple transaction results, the blockchain determines whether the target transaction is an abnormal transaction result based on the second hash value and the third hash value, the second hash value is obtained by the blockchain using the initiator's public key to decrypt the received digital signature, the third hash value is generated by the blockchain based on the received transaction information and the second time, when the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; the verification result returned by the blockchain is received, and based on the verification result, an execution result of whether the target transaction can be executed is determined. By receiving and responding to transaction requests submitted by the initiator containing target transaction information, an accurate data foundation is provided for subsequent determination of transaction execution results based on this specific target transaction information. By determining the initial time of the transaction request, this initial time can be used to verify transaction order, avoid double spending, detect transaction delays or anomalies, and ensure the timeliness and validity of transactions. By generating a first hash value corresponding to the target transaction based on the target transaction information and the initial time, the integrity and immutability of the target transaction information are ensured, ensuring the legitimacy and validity of the transaction while protecting user privacy. Based on the hash value comparison results, the blockchain generates a verification result. The abnormal transaction result of determining whether the target transaction is an abnormal transaction is determined based on the second hash value and the third hash value, thereby avoiding the risk of transaction data being tampered with during transmission and the risk of double payment. Through the immutability of the blockchain, the transaction records and verification results are permanently preserved, providing guarantees for the transparency and traceability of the transaction, thereby ensuring the legality and validity of the transaction on the basis of decentralization, improving the security and credibility of the transaction, and thus solving the technical problem in related technologies that when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security of payment transactions.

[0079] As an optional embodiment, a first hash value corresponding to the target transaction is generated based on the target transaction information and the first time, including: when the target transaction information includes the initiator account, the recipient account, and the payment amount, determining the first account behavior of the initiator account and the second account behavior of the recipient account; determining a first security index of the target transaction based on the first account behavior and the second account behavior; determining a second security index of the target transaction based on the historical transaction records and the payment amount of the initiator account; determining a target security index based on the first security index and the second security index; and generating a first hash value based on the target transaction information and the first time when the target security index is greater than a predetermined security threshold.

[0080] In this embodiment, specific steps of generating a first hash value corresponding to a target transaction based on target transaction information and a first time are described.

[0081] This involves the initiator account, which is the account held by the party that actively initiates the payment request in a payment transaction. The initiator account contains the digital assets or currencies used to initiate the transaction. For example, in cryptocurrency transactions, users initiate transactions through their wallet addresses, and this wallet address represents the initiator account.

[0082] This involves the recipient account, which is the account held by the party receiving funds or digital assets in a payment transaction. This recipient account needs to be able to receive and store the payment amount. Generally, the recipient account is identified by its wallet address or bank account information. For example, when a user initiates a transfer to another user's cryptocurrency address, that address is the recipient account.

[0083] Among them, the payment amount is involved, which is the amount of currency or assets specified in the payment transaction, and is the specific value transferred from the initiator's account to the recipient's account.

[0084] The first account behavior is involved, which represents the behavior of the initiator's account during the payment transaction process, including the transaction frequency and historical transaction behavior of the initiator's account. The first account behavior can be used to assess the normality and risk level of the initiator's account.

[0085] This involves second account behavior, which represents the behavior of the recipient's account during the payment transaction process, including information such as the recipient's account's transaction frequency and historical transaction behavior. This second account behavior can be used to assess the normality and risk level of the recipient's account.

[0086] Among them, a first security index is involved, which is a security indicator determined based on the first account behavior of the initiator's account and the second account behavior of the recipient's account to reflect the security level of the target transaction.

[0087] Among them, the second security index is involved. The second security index is a security indicator used to evaluate the capital flow risk of the initiator's account and the rationality of the transaction based on the historical transaction records and payment amounts of the initiator's account.

[0088] Among them, the target safety index is involved, which is the final safety evaluation index obtained by combining the first safety index and the second safety index.

[0089] This involves a predetermined security threshold, which is a pre-set threshold used to measure the security level of a target transaction. For example, if the target security index exceeds the predetermined security threshold, the target transaction will be considered safe. Otherwise, the target transaction may be marked as high risk and require additional review or verification steps.

[0090] In the steps involved in this embodiment, the first account behavior of the initiator's account and the second account behavior of the recipient's account are first analyzed. Based on the first and second account behaviors, a first security index is determined to reflect the security level of the target transaction. Next, based on the historical transaction records and payment amounts of the initiator's account, a second security index is determined. Based on the first and second security indices, a comprehensive target security index is determined to comprehensively assess the normality and potential risks of both parties to the transaction. If the target security index is higher than a pre-set security threshold used to measure the security level of the target transaction, it indicates that the target transaction will be deemed safe and the transaction will proceed. Then, based on the target transaction information and the first time, a first hash value corresponding to the target transaction is generated.

[0091] By determining a first security index reflecting the security level of the target transaction based on the first account behavior and the second account behavior, and determining a second security index based on the historical transaction records and payment amounts of the initiator's account, and determining a target security index based on the first security index and the second security index, a comprehensive assessment of the security of the target transaction is achieved, thereby helping to effectively prevent malicious transactions and financial losses, improving the security and reliability of the payment system, and reducing risks that may be encountered during the transaction process. If the target security index is higher than a pre-set predetermined security threshold, a first hash value corresponding to the target transaction is generated based on the target transaction information and the first time, thereby achieving the automatic generation of the first hash value while ensuring that the transaction risks are controllable, and continuing the transaction process, thereby improving the automated processing capabilities of the payment system, effectively protecting user funds from fraud and illegal transactions, and further helping to resolve the technical problem in related technologies that when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security of payment transactions.

[0092] As an optional embodiment, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: determining multiple information items included in the target transaction information; determining a security item whose confidentiality index is greater than a predetermined confidentiality threshold from the multiple information items; masking the data corresponding to the security item to obtain the masked target transaction information; generating the first hash value corresponding to the target transaction based on the masked target transaction information and the first time.

[0093] In this embodiment, specific steps of generating a first hash value corresponding to a target transaction based on target transaction information and a first time are described.

[0094] Among them, an information item is involved, which is an item contained in the target transaction information and reflects a specific data feature of the target transaction information. The information item can be an account address item, a transaction amount item, a transaction time item, a transaction type item, etc.

[0095] Among them, the confidentiality index is involved, which is a quantitative index used to evaluate the sensitivity or confidentiality requirement of each information item in the target transaction information.

[0096] This involves a predetermined confidentiality threshold, which is a pre-set threshold used to determine whether the confidentiality level of an information item requires masking. For example, if the confidentiality index of an information item is higher than the predetermined confidentiality threshold, the information item will be considered sensitive information requiring additional protection.

[0097] This involves security items, which are information items within the target transaction information whose confidentiality index exceeds a predetermined confidentiality threshold. Due to their high sensitivity, these security items require masking to protect them. For example, in a payment transaction, the full real name of the initiating account can be considered a security item.

[0098] This involves masking, a data protection technique that replaces part or all of sensitive information with unrecognizable characters or data to prevent direct leakage or unauthorized access. Masking can include methods such as complete blocking, partial blocking, and data replacement. For example, when displaying a credit card number, typically only the last four digits are displayed, with the rest replaced by asterisks or other characters. This is a form of masking.

[0099] In the steps involved in this embodiment, multiple information items included in the target transaction information are first determined, and then the confidentiality index of each information item is used to identify which information items are more sensitive and require additional protection. If the confidentiality index of an information item exceeds a predetermined confidentiality threshold, then this information item will be regarded as a safe item. Then, the data corresponding to these safe items are masked, and finally, a first hash value corresponding to the target transaction is generated based on the masked target transaction information and the first time.

[0100] By determining multiple information items included in the target transaction information and identifying security items with confidentiality indexes greater than a predetermined confidentiality threshold from the multiple information items, the data corresponding to these security items is masked, thereby avoiding direct exposure of the user's sensitive information during the transaction process and protecting the privacy of the user's data. At the same time, masking provides an additional defense mechanism to prevent malicious tampering of the transaction information during transmission, ensuring the integrity and authenticity of the transaction information. Based on the masked target transaction information and the first time, a first hash value corresponding to the target transaction is generated. This ensures that even if the transaction information contains sensitive information, it will be protected during transmission and recording. Only necessary data is used for transaction verification and execution, while sensitive information is shielded, ensuring data privacy and security, enhancing user privacy protection, and improving the security of the entire transaction process.

[0101] As an optional embodiment, generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: determining the information length of the target transaction information; when the information length is greater than a predetermined length threshold, compressing the target transaction information to obtain compressed target transaction information; and generating the first hash value corresponding to the target transaction based on the compressed target transaction information and the first time.

[0102] In this embodiment, specific steps of generating a first hash value corresponding to a target transaction based on target transaction information and a first time are described.

[0103] The message length is the original size of the target transaction information before any data processing, measured in bytes. The message length can be the sum of all data in the transaction information, including the size of all fields such as account information, transaction amount, timestamp, and notes. For example, a specific transaction may contain 200 bytes of initiator account address information, 100 bytes of recipient account address information, 50 bytes of payment amount information, and 50 bytes of timestamp information. In this case, the total message length of the target transaction information may be 400 bytes.

[0104] This involves a predetermined length threshold, which is a pre-set threshold used to determine whether target transaction information requires compression. For example, if the target transaction information exceeds this threshold, it will be compressed to shorten the data length. This predetermined length threshold can be set based on various factors, such as network transmission efficiency, storage costs, and processing speed.

[0105] Among them, compression processing is involved, which is a data optimization technology used to reduce the data volume of target transaction information while preserving the integrity and availability of the information as much as possible.

[0106] In the steps involved in this embodiment, the original information length of the target transaction information is first determined. If this length exceeds a preset predetermined length threshold, the target transaction information is compressed to obtain compressed target transaction information. Then, a first hash value corresponding to the target transaction is generated based on the compressed target transaction information and the first time.

[0107] By compressing the original length of target transaction information that exceeds a predetermined length threshold, efficient hash calculations can be performed even when the transaction information contains large amounts of data. This ensures the timeliness and reliability of transactions, while also facilitating the effective utilization of network and storage resources, allowing for the processing of more transactions. Based on the compressed target transaction information and the first time, a first hash value corresponding to the target transaction is generated, reducing processing and transmission time, enabling transactions to be confirmed and executed more quickly, and improving the efficiency and speed of transaction processing. This, in turn, increases transaction processing speed and blockchain performance, providing users with a faster payment experience.

[0108] As an optional embodiment, before sending the target digital signature and target transaction information to the blockchain, it also includes: compiling a contract code based on the transaction scenario corresponding to the target transaction, wherein the contract code includes a code for determining whether it corresponds to an abnormal transaction and a code for determining whether it corresponds to multiple transactions; and deploying the contract code in the blockchain so that the blockchain executes the contract code.

[0109] In this embodiment, the specific steps before sending the target digital signature and target transaction information to the blockchain are described.

[0110] The transaction scenario is used to describe the specific scenario of the target payment transaction. For example, the transaction scenario of purchasing goods involves product information and payment amount, while the transaction scenario of transferring funds requires attention to account balance and transfer limit.

[0111] This involves contract code, which is used to execute specific transaction logic. This contract code can include the transaction conditions involved in the transaction process. For example, the contract code can be compiled into code for detecting abnormal transactions and multiple transactions.

[0112] In this embodiment, before sending the target digital signature and target transaction information to the blockchain, contract code must be compiled based on the transaction scenario corresponding to the target transaction. This contract code can be compiled into code for detecting abnormal transactions and multiple transactions. The compiled contract code is then deployed on the blockchain, allowing it to automatically execute the contract code.

[0113] Before sending the target digital signature and target transaction information to the blockchain, contract code is compiled based on the transaction scenario corresponding to the target transaction. By integrating code for detecting abnormal and multiple transactions into the contract code, it can effectively identify and handle abnormal and multiple transactions, ensuring strict compliance with transaction rules, reducing human error and fraud, and thus maintaining transaction fairness and transparency. Deploying the compiled contract code on the blockchain enables decentralized transaction verification, ensuring transaction fairness and immutability. Automatically executing contract code through the blockchain effectively avoids the complexity and potential errors of manual review, speeds up transaction processing, and provides users with a more secure payment environment, enabling faster transaction confirmation and execution, and enhancing the user experience.

[0114] As an optional embodiment, the second time is at least one of the following: the second time is sent by the terminal to the blockchain, and the second time is determined based on the data reception time and the data transmission time.

[0115] In this embodiment, the second time is specifically described.

[0116] This involves a terminal, which is the hardware device used by the initiator to interact with the blockchain network. This terminal can be any device capable of data transmission, such as a mobile terminal or a computer. For example, when conducting a cryptocurrency transaction, a user submits a transaction request through a wallet app on their smartphone, and this smartphone serves as the payment terminal.

[0117] The data reception time is the time when the transaction data is received by the node in the blockchain network. For example, if a user sends a transaction through their device at 2:30 PM and the blockchain node receives and records the transaction at 2:31 PM, then 2:31 PM is the data reception time.

[0118] This involves data transmission time, which is the length of time it takes for transaction data to be sent from a terminal to a blockchain network node. This data transmission time includes network transmission delays, such as internet latency, encryption time, and signature time. For example, if transaction data is sent from a user terminal at 2:30 PM and arrives at a blockchain node at 2:31 PM, the period between 2:30 PM and 2:31 PM is the data transmission time.

[0119] The steps involved in this embodiment specifically involve determining the second time of a transaction in a blockchain payment system. This second time can be the time when the transaction data is received by the terminal and sent to the blockchain network, or the time when the transaction data is transmitted from the terminal to the blockchain network node.

[0120] Accurately determining the second time allows all transactions to be sorted and confirmed in the order in which they actually occurred, ensuring that transactions are correctly sequenced and avoiding confusion. This helps the blockchain effectively detect and prevent double spending, preventing the same funds from being used or paid multiple times. This protects transaction security and user assets, thereby improving the overall reliability of the payment system and reducing errors and disputes in transaction processing.

[0121] As an optional embodiment, the execution result of determining whether the target transaction can be executed is determined based on the verification result, including: when the target transaction information includes the initiator account, the recipient account, and the payment amount, and the verification result is that the verification is passed, the execution result is determined to be the execution of the target transaction, so as to deduct the payment amount from the initiator account and transfer the payment amount to the recipient account to determine the payment result.

[0122] In this embodiment, specific steps of determining whether the target transaction can be executed based on the verification result are described.

[0123] In the steps involved in this embodiment, the target transaction information includes the initiator's account, the recipient's account, the payment amount, and when the verification result is passed, the execution result is determined to be the execution of the target transaction, then the specified payment amount is deducted from the initiator's account, and the payment amount is transferred to the recipient's account, and finally the payment result is determined.

[0124] By including the initiator's account, the recipient's account, the payment amount in the target transaction information, and the verification result being passed, the execution result of the target transaction is determined, ensuring that only legal transactions that have been strictly verified will be executed, and those transactions that are abnormal or do not meet the conditions will be rejected, achieving the purpose of safe payment, effectively avoiding the risks of repeated payments, illegal transactions, fraud or fund theft, thereby protecting the asset security of both parties involved in the transaction, maintaining the overall stability of the transaction, and providing users with a more trustworthy and reliable payment environment and enhancing the user experience.

[0125] Based on the above embodiment and optional embodiment, an optional implementation manner is provided, which is described in detail below.

[0126] In related technologies, when executing payment transactions, a third-party centralized organization is usually used to verify the security of the transaction. However, centralized organizations are prone to the risk of being attacked and prone to internal problems, resulting in lower security of payment transactions.

[0127] To address the above-mentioned problems, no effective solutions have been proposed so far.

[0128] In view of this, an optional embodiment of the present invention provides a method that can be used.

[0129] In view of this, a method for determining transaction execution results is provided in an optional embodiment of the present invention, which can also be called a wallet payment method, which can effectively solve the technical problems in related technologies where users face the diversity of point deduction methods and the complexity of discount information, resulting in high manual calculation costs and inconvenient operations.

[0130] Figure 2 is a timing diagram for determining transaction execution results provided by an optional embodiment of the present invention, Figure 3 This is a timing diagram of the contract code processing mechanism provided by an optional embodiment of the present invention, such as Figure 2 ,as well as Figure 3 As shown, the following will be introduced in detail.

[0131] S1. Receive a transaction request, wherein the transaction request carries target transaction information;

[0132] For example, a user initiates a payment request, specifically through a wallet application (the same as the initiator account mentioned above), and provides payment-related information, such as the payment amount and payee information (the same as the recipient account mentioned above). The user selects the amount to be paid and the payee in the wallet application, and then initiates the payment request.

[0133] The payment data is transmitted to the smart contract network. Specifically, the wallet application transmits the payment request initiated by the user and the relevant payment data (the same as the target transaction information mentioned above) to the smart contract network. This payment data may include the payment amount, payer information, payee information, and other payment conditions and constraints.

[0134] S2. In response to the transaction request, determining a first time of receiving the transaction request;

[0135] S3. Generate a first hash value corresponding to the target transaction based on the target transaction information and the first time;

[0136] Specifically, S3 also includes:

[0137] S301: When the target transaction information includes an initiator account, a recipient account, and a payment amount, determine a first account behavior of the initiator account and a second account behavior of the recipient account;

[0138] S302: Determine a first security index of the target transaction based on the first account behavior and the second account behavior;

[0139] S303. Determine a second security index of the target transaction based on the historical transaction records and payment amount of the initiator's account;

[0140] S304, determining a target safety index based on the first safety index and the second safety index;

[0141] S305: When the target security index is greater than a predetermined security threshold, generate a first hash value according to the target transaction information and the first time.

[0142] For example, payment restrictions (similar to the target security index mentioned above) can be implemented to set payment conditions and constraints to ensure that payment transactions can only be executed if they meet specific conditions. Payment transactions may require certain conditions such as fund limits and identity verification of the payment recipient, otherwise the payment will be rejected or suspended.

[0143] Specifically, S3 also includes:

[0144] S311. Determine multiple information items included in the target transaction information;

[0145] S312. Determine, from the plurality of information items, a security item whose confidentiality index is greater than a predetermined confidentiality threshold;

[0146] S313. Mask the data corresponding to the security item to obtain the masked target transaction information;

[0147] S314: Generate a first hash value corresponding to the target transaction based on the masked target transaction information and the first time.

[0148] Specifically, S3 also includes:

[0149] S321. Determine the information length of the target transaction information;

[0150] S322: If the information length is greater than a predetermined length threshold, compress the target transaction information to obtain compressed target transaction information;

[0151] S323: Generate a first hash value corresponding to the target transaction based on the compressed target transaction information and the first time.

[0152] For example, smart contracts (the same as the contract code above) use intelligent algorithms to verify payment transactions to ensure their uniqueness and legitimacy. This can include verifying information such as the payment amount and the identity of the payer to prevent duplicate payments or tampering. The details are as follows:

[0153] B1. Efficient algorithm selection.

[0154] Select efficient verification algorithms to ensure the uniqueness and legitimacy of payment transactions. This may include algorithms that verify key information such as the payment amount, payer identity, and transaction hash values. For example, use hash functions to encrypt and verify transaction data.

[0155] B2. Smart contract optimization.

[0156] Optimize the programming and execution logic of smart contracts to enable them to quickly and accurately verify payment transactions. This includes avoiding redundant calculations and data processing, and optimizing the contract's code structure and algorithm implementation.

[0157] B3. Data preprocessing and caching.

[0158] Perform necessary data preprocessing and caching before verification to reduce computational costs and latency during real-time verification. For example, cache verified payment transaction information for quick access and verification later.

[0159] B4. Parallel processing and distributed verification.

[0160] Utilize parallel processing and distributed computing technologies to accelerate the verification process, especially when processing a large number of concurrent payment transactions. By distributing verification tasks to multiple nodes or processing units for parallel execution, the efficiency and throughput of verification can be significantly improved.

[0161] B5. Real-time data stream processing.

[0162] Streaming data processing technology is used to capture and process payment transaction data streams in real time to quickly identify and verify abnormal or duplicate payments. Streaming processing enables immediate verification of transactions as they occur and timely implementation of necessary measures.

[0163] B6. Automated auditing and monitoring.

[0164] Establish an automated audit and monitoring system to regularly or in real time check the verification process and results of smart contracts. Through the automated audit mechanism, possible verification issues or vulnerabilities can be discovered and fixed in a timely manner.

[0165] S4. Encrypt the first hash value according to the initiator's private key to obtain a target digital signature;

[0166] S5. Send the target digital signature and target transaction information to the blockchain, so that the blockchain obtains a verification result, the verification result including the abnormal transaction result and, if the abnormal transaction result is non-abnormal, the multiple transaction results. The blockchain determines whether the target transaction is an abnormal transaction result of an abnormal transaction based on the second hash value and the third hash value. The second hash value is obtained by the blockchain using the initiator's public key to decrypt the received target digital signature, and the third hash value is generated by the blockchain based on the received transaction information and the second time. If the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value.

[0167] For example, smart contracts monitor double payments in real time during payment transactions. Once a duplicate payment is detected, the smart contract can immediately take appropriate measures, such as rejecting subsequent duplicate payment requests. The details are as follows:

[0168] C1. Event-driven architecture.

[0169] Adopting an event-driven design pattern enables the monitoring system to capture key events and status changes in payment transactions in real time. This architecture ensures that the monitoring system only processes when needed, saving resources and improving response time.

[0170] C2. Stream processing technology.

[0171] Use stream processing technologies (such as Apache Kafka and Apache Flink) to process payment transaction streams, capturing and processing transaction events in real time. Stream processing technologies achieve high throughput and low latency, ensuring that the monitoring system can respond to and process large amounts of transaction data in a timely manner.

[0172] C3, real-time data storage and indexing.

[0173] Use efficient real-time data storage and indexing technologies, such as NoSQL databases (such as MongoDB, Cassandra, etc.) or in-memory databases (such as Redis) to support fast data writing and query operations. This ensures that the monitoring system can quickly access and update payment transaction status information.

[0174] C4, distributed computing and scalability.

[0175] Use distributed computing architecture and scalable system design to ensure that the monitoring system can handle large-scale payment transactions and maintain high performance. This includes using containerization technologies (such as Docker and Kubernetes) and automated scaling mechanisms to dynamically adjust system resources based on load.

[0176] C5. Real-time alarm and response mechanism.

[0177] Establish a real-time alert system. Once abnormal or duplicate payments are detected, the pre-set alert mechanism will be triggered immediately to notify the relevant operation and maintenance personnel or system administrators. At the same time, set up an automated response mechanism, such as suspending transactions or automatically rolling back non-compliant transactions.

[0178] Specifically, before S5, it also includes:

[0179] S051. Compile contract code based on the transaction scenario corresponding to the target transaction, where the contract code includes code for determining whether it corresponds to an abnormal transaction and code for determining whether it corresponds to multiple transactions;

[0180] S052. Deploy the contract code in the blockchain so that the blockchain executes the contract code.

[0181] For example, a payment confirmation time limit can be compiled into the contract code, stipulating that the payee must confirm the payment within a certain period of time, otherwise the payment will be canceled or returned to the payer. This can prevent long waiting times during the payment process and ensure that the payment transaction can be completed in a timely manner.

[0182] Furthermore, dispute mediation processes and mechanisms can be designed, including automatic initiation of mediation, invitation of relevant parties to participate in mediation, and recording of mediation results. Smart contracts can automatically execute the dispute mediation process based on pre-set code to ensure that payment disputes are resolved promptly and fairly.

[0183] Specifically, the second time in S5 is at least one of the following:

[0184] A1, the second time is sent by the terminal to the blockchain;

[0185] A2. The second time is determined based on the data receiving time and the data transmitting time.

[0186] For example, unique identifier records, which record the unique identifier of each payment transaction through smart contracts, such as transaction hash or other unique identifiers. This identifier ensures that each transaction is unique and can be used for subsequent verification and detection. The details are as follows:

[0187] D1. Use composite identifiers.

[0188] Combining multiple elements into a composite identifier increases uniqueness and security. For example, the transaction timestamp (same as the first time), the payer and payee addresses, the transaction amount, and other information can be combined to generate a unique identifier (same as the first hash value).

[0189] D2. Encryption and hashing.

[0190] The generated unique identifier is encrypted or hashed to ensure that the resulting identifier (similar to the target digital signature mentioned above) is irreversible and secure. This prevents the identifier from being tampered with or forged, ensuring the uniqueness and authenticity of each transaction.

[0191] D3. Combination of timestamp and sequence number.

[0192] Combining an accurate timestamp (same as the second time mentioned above) with a unique sequence number generation mechanism ensures that each transaction has a different identifier. This method can effectively prevent duplicate transactions or confusion of transaction order occurring at the same time.

[0193] D4. Blockchain records.

[0194] The generated unique identifier is recorded directly on the blockchain as part of the transaction. This leverages the blockchain's immutability and transparency to ensure the uniqueness and traceability of each transaction.

[0195] D5. Real-time update and verification.

[0196] Ensure that smart contracts can update and verify unique identifiers in real time to reflect the latest transaction status and details. This can be achieved by monitoring changes and events in the payment transaction process in real time.

[0197] S6. Receive the verification result returned by the blockchain, and determine whether the target transaction can be executed based on the verification result.

[0198] Specifically, S6 also includes:

[0199] When the target transaction information includes the initiator's account, the recipient's account, and the payment amount, and the verification result is passed, the execution result is determined to be executing the target transaction, so as to deduct the payment amount from the initiator's account and transfer the payment amount to the recipient's account to determine the payment result.

[0200] For example, a smart contract executes a payment. Specifically, after receiving payment data, the smart contract network executes the corresponding payment operation according to pre-programmed smart contract code. A smart contract may include functions such as verifying the legitimacy of the payment data, checking the payer's account balance, updating account balances, and recording payment transaction details. The payment result is recorded on the blockchain. Specifically, after executing the payment operation, the smart contract records the payment result on the blockchain. This includes transaction details such as the payer, payee, payment amount, and payment time. Due to the decentralized and immutable nature of the blockchain, once a payment transaction is recorded on the blockchain, it cannot be altered, ensuring its security and credibility. Users can query the status and details of payment transactions at any time through their wallet application or other blockchain explorer. Users can view information such as payment success, payment amount, and payment time, ensuring the transparency and fairness of the payment process.

[0201] Smart contracts record and track the status and details of payment transactions, including unique payment identifiers, payment amounts, payment times, and other information. This provides data support for subsequent audits and regulations, ensuring the transparency and fairness of the payment system. The details are as follows:

[0202] E1. Efficient data structure and storage.

[0203] Select appropriate data structures and storage technologies to ensure efficient recording and retrieval of payment transaction data. For example, use appropriate database systems or blockchain technology to store payment transaction information to ensure data security and scalability.

[0204] E2. Real-time data capture and processing.

[0205] Real-time data stream processing technology is used to capture and process payment transaction data in a timely manner. This ensures that the status and details of payment transactions are recorded in a timely manner, allowing for timely subsequent processing and analysis.

[0206] E3. Integrity and non-tampering guarantee.

[0207] Leveraging the immutability and integrity of blockchain technology, the authenticity and credibility of payment transaction records can be ensured. Each transaction's unique identifier, transaction hash value, and key metadata should be accurately recorded on the blockchain to prevent data tampering or loss.

[0208] E4. Data encryption and privacy protection.

[0209] Appropriate encryption and privacy protection measures are implemented for payment transaction data to protect users' personal information and transaction details from unauthorized access or disclosure.

[0210] E5. Smart contract integration.

[0211] Tightly integrating data recording and tracking with smart contracts ensures that the status changes and audit trails of each transaction can be tracked and recorded by smart contracts. Smart contracts can automatically record transaction status changes, perform auditing, and monitor tasks.

[0212] E6. Real-time monitoring and alarm system.

[0213] A real-time monitoring and alert system is established to detect abnormalities or unusual changes in payment transaction data. When anomalies are detected, the system can promptly issue an alert and take necessary countermeasures to ensure the stability and security of the payment system.

[0214] E7. Audit and compliance checks.

[0215] Regularly conduct audits and compliance checks on payment transaction data to ensure the completeness and accuracy of records. These audits can be conducted by an independent third party or an internal team to verify that the system complies with regulations and standards.

[0216] Through the above optional implementation, at least the following beneficial effects can be achieved:

[0217] (1) Compared with the related art, the present invention determines the first time of the transaction request, which can be used to verify the order of transactions, avoid double payment, detect transaction delays or anomalies, and ensure the timeliness and validity of transactions. By generating a first hash value corresponding to the target transaction based on the target transaction information and the first time, the integrity and non-tamperability of the target transaction information are ensured, and the legitimacy and validity of the transaction can be ensured while protecting user privacy. According to the comparison result of the hash value, the blockchain generates a verification result. According to the second hash value and the third hash value, it is determined whether the target transaction is an abnormal transaction result of an abnormal transaction, thereby avoiding the transaction data being tampered with during transmission and the risk of double payment. Through the non-tamperability of the blockchain, the transaction records and verification results are permanently preserved, providing a guarantee for the transparency and traceability of the transaction, thereby ensuring the legitimacy and validity of the transaction on the basis of decentralization, improving the security and credibility of the transaction, and thus solving the technical problem in the related art that when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security of payment transactions.

[0218] (2) Compared with the related art, the present invention determines a first security index for reflecting the security level of the target transaction based on the first account behavior and the second account behavior, and determines a second security index based on the historical transaction records and payment amount of the initiator's account, and determines the target security index by combining the first security index and the second security index, thereby achieving a comprehensive assessment of the security of the target transaction, thereby helping to effectively prevent malicious transactions and capital losses, improve the security and reliability of the payment system, and reduce the risks that may be encountered during the transaction process. If the target security index is higher than a pre-set predetermined security threshold, a first hash value corresponding to the target transaction is generated based on the target transaction information and the first time, thereby achieving the automatic generation of the first hash value while ensuring that the transaction risk is controllable, continuing the transaction process, improving the automated processing capability of the payment system, effectively preventing user funds from being infringed by fraud and illegal transactions, and thus helping to solve the technical problem in the related art that when executing payment transactions, centralized institutions are prone to attacks and internal problems, resulting in low security of payment transactions.

[0219] (3) Compared with the related art, the present invention determines multiple information items included in the target transaction information, and determines security items with a confidentiality index greater than a predetermined confidentiality threshold from the multiple information items, and performs masking on the data corresponding to these security items, thereby avoiding direct exposure of the user's sensitive information during the transaction process and protecting the privacy of the user's data. At the same time, through masking, an additional defense mechanism is provided to prevent the transaction information from being maliciously tampered with during transmission, thereby ensuring the integrity and authenticity of the transaction information. Based on the target transaction information after masking and the first time, a first hash value corresponding to the target transaction is generated, so that even if the transaction information contains sensitive information, it will be protected during the transmission and recording process. Only necessary data is used for transaction verification and execution, while sensitive information is shielded, ensuring the privacy and security of the data, enhancing the protection of user privacy, and improving the security of the entire transaction process.

[0220] (4) Compared with related technologies, the present invention compiles the contract code according to the transaction scenario corresponding to the target transaction before sending the target digital signature and target transaction information to the blockchain. By compiling the code for detecting abnormal transactions and multiple transactions in the contract code, it can effectively identify and handle abnormal transactions and multiple transactions, ensure strict compliance with transaction rules, reduce human errors and fraudulent behavior, and thus maintain the fairness and transparency of transactions. By deploying the compiled contract code in the blockchain, decentralized transaction verification is achieved, ensuring the fairness and non-tamperability of transactions. By automatically executing the contract code through the blockchain, the complexity and potential errors of manual review are effectively avoided, the speed of transaction processing is improved, and a safer payment environment is provided for users, so that transactions can be confirmed and executed more quickly, and the user experience is enhanced.

[0221] (5) Compared with the related art, the present invention decrypts the received target digital signature using the public key provided by the initiator based on the blockchain to obtain a second hash value, and compares the second hash value with the third hash value to verify the validity of the digital signature. If the second hash value does not match the third hash value, the transaction is considered abnormal and an abnormal transaction result is generated. By comparing the second hash value and the third hash value, it is ensured that the transaction data has not been tampered with during the transmission process, thereby improving the integrity and reliability of the data. At the same time, the blockchain node generates a third hash value based on the received transaction information and the second time of the recorded transaction, and checks whether the third hash value matches any previously recorded hash value to detect whether the transaction is a repeated submission. Based on the comparison result of the hash value, a verification result is generated. If the third hash value matches the previously recorded hash value, the transaction is considered a duplicate and multiple transaction results are generated. By detecting the third hash value, the reuse of the same funds is prevented, the risk of double payment is avoided, and the transaction time is ensured to be processed in chronological order, which prevents the transaction time from being tampered with. Through the immutability of blockchain, transaction records and verification results are permanently preserved, providing guarantees for the transparency and traceability of transactions, thereby ensuring the legitimacy and validity of transactions on a decentralized basis, and improving the security and credibility of transactions.

[0222] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that the present invention is not limited by the order of the actions described, because according to the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0223] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of various embodiments of the present invention.

[0224] Example 2

[0225] According to an embodiment of the present invention, there is also provided a device for implementing the above transaction execution result determination method. Figure 4is a structural block diagram of a device for determining a transaction execution result according to an embodiment of the present invention. Figure 4 As shown, the device includes: a receiving module 402, a first determining module 404, a generating module 406, an encrypting module 408, a sending module 410 and a second determining module 412. The device will be described in detail below.

[0226] The receiving module 402 is used to receive a transaction request, wherein the transaction request carries target transaction information; the first determining module 404 is connected to the receiving module 402 and is used to respond to the transaction request and determine the first time of receiving the transaction request; the generating module 406 is connected to the first determining module 404 and is used to generate a first hash value corresponding to the target transaction based on the target transaction information and the first time; the encryption module 408 is connected to the generating module 406 and is used to encrypt the first hash value based on the initiator's private key to obtain a target digital signature; the sending module 410 is connected to the encryption module 408 and is used to send the target digital signature and the target transaction information to the blockchain so that the blockchain can be used to store the target digital signature and the target transaction information. The blockchain obtains a verification result, which includes an abnormal transaction result and a multiple transaction result. The blockchain determines whether the target transaction is an abnormal transaction result based on the second hash value and the third hash value. The second hash value is obtained by the blockchain using the initiator's public key to decrypt the target digital signature. The third hash value is generated by the blockchain based on the target transaction information and the second time. When the abnormal transaction result is non-abnormal, the blockchain determines whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; the second determination module 412 is connected to the above-mentioned sending module 410, and is used to receive the verification result returned by the blockchain, and determine the execution result of whether the target transaction can be executed based on the verification result.

[0227] It should be noted here that the above-mentioned receiving module 402, first determination module 404, generation module 406, encryption module 408, sending module 410 and second determination module 412 correspond to steps S102 to S112 in the method for determining the transaction execution result. The instances and application scenarios implemented by multiple modules and corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned embodiment 1.

[0228] Example 3

[0229] According to another aspect of an embodiment of the present invention, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions, wherein the processor is configured to execute the instructions to implement any of the above transaction execution result determination methods.

[0230] Example 4

[0231] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any of the above-mentioned transaction execution result determination methods.

[0232] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0233] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0234] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0235] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0236] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0237] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program codes.

[0238] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for determining a transaction execution result, characterized in that: include: receiving a transaction request, wherein the transaction request carries target transaction information; In response to the transaction request, determining a first time of receiving the transaction request; Generate a first hash value corresponding to the target transaction based on the target transaction information and the first time; Encrypting the first hash value according to the initiator's private key to obtain a target digital signature; Sending the target digital signature and the target transaction information to the blockchain so that the blockchain obtains a verification result, the verification result including an abnormal transaction result and, if the abnormal transaction result is non-abnormal, also including multiple transaction results, the blockchain determining whether the target transaction is an abnormal transaction result of an abnormal transaction based on a second hash value and a third hash value, the second hash value being obtained by the blockchain using the initiator's public key to decrypt the received target digital signature, the third hash value being generated by the blockchain based on the received transaction information and the second time, and if the abnormal transaction result is non-abnormal, the blockchain determining whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; Receive the verification result returned by the blockchain, and determine, based on the verification result, whether the target transaction can be executed.

2. The method according to claim 1, characterized in that Generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: When the target transaction information includes an initiator account, a recipient account, and a payment amount, determining a first account behavior of the initiator account and a second account behavior of the recipient account; determining a first security index of the target transaction based on the first account behavior and the second account behavior; determining a second security index of the target transaction based on historical transaction records of the initiator's account and the payment amount; determining a target safety index based on the first safety index and the second safety index; When the target security index is greater than a predetermined security threshold, the first hash value is generated according to the target transaction information and the first time.

3. The method according to claim 1, characterized in that Generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: determining a plurality of information items included in the target transaction information; Determining, from the plurality of information items, a security item having a confidentiality index greater than a predetermined confidentiality threshold; Performing masking on the data corresponding to the security item to obtain masked target transaction information; A first hash value corresponding to the target transaction is generated according to the masked target transaction information and the first time.

4. The method according to claim 1, wherein Generating a first hash value corresponding to the target transaction based on the target transaction information and the first time includes: Determining the information length of the target transaction information; When the information length is greater than a predetermined length threshold, compressing the target transaction information to obtain compressed target transaction information; A first hash value corresponding to the target transaction is generated according to the compressed target transaction information and the first time.

5. The method according to claim 1, wherein Before sending the target digital signature and the target transaction information to the blockchain, the method further includes: Compiling a contract code based on a transaction scenario corresponding to the target transaction, wherein the contract code includes a code for determining whether the transaction corresponds to an abnormal transaction and a code for determining whether the transaction corresponds to multiple transactions; The contract code is deployed in the blockchain so that the blockchain executes the contract code.

6. The method according to claim 1, characterized in that The second time is at least one of the following: the second time is the data reception time when the transaction data is sent by the terminal to the blockchain network, and the second time is the data transmission time when the transaction data is sent from the terminal to the blockchain network node.

7. The method according to any one of claims 1 to 6, characterized in that The execution result of determining whether the target transaction can be executed based on the verification result includes: The target transaction information includes the initiator account, the recipient account, and the payment amount. If the verification result is passed, the execution result is determined to be executing the target transaction, so as to deduct the payment amount from the initiator account and transfer the payment amount to the recipient account to determine the payment result.

8. A transaction execution result determination device, characterized in that: include: A receiving module, configured to receive a transaction request, wherein the transaction request carries target transaction information; a first determining module, configured to determine, in response to the transaction request, a first time of receiving the transaction request; a generating module, configured to generate a first hash value corresponding to the target transaction based on the target transaction information and the first time; An encryption module, configured to encrypt the first hash value according to the initiator's private key to obtain a target digital signature; a sending module, configured to send the target digital signature and the target transaction information to a blockchain, so that the blockchain obtains a verification result, the verification result including an abnormal transaction result and a multiple transaction result, the blockchain determining whether the target transaction is an abnormal transaction result of an abnormal transaction based on a second hash value and a third hash value, the second hash value being obtained by the blockchain decrypting the target digital signature using an initiator's public key, the third hash value being generated by the blockchain based on the target transaction information and a second time, and if the abnormal transaction result is non-abnormal, the blockchain determining whether the target transaction is a multiple transaction result of multiple transactions based on the third hash value; The second determination module is used to receive the verification result returned by the blockchain and determine, based on the verification result, whether the target transaction can be executed.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the transaction execution result determination method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the transaction execution result determination method according to any one of claims 1 to 7.

Images