A method for implementing an oracle to map fiat currency to blockchain

Abstract

The present invention discloses a method for realizing a prophecy machine that maps legal currency to a blockchain, and relates to the field of blockchain, and includes the following steps: S1, a validator application process: the applicant initiates an application operation to the chain payment issuance contract, and after the system determines whether the applicant is a validator with bad behavior in the past, the applicant joins the validator; S2, a recharge process: the user first initiates a recharge transfer, and then initiates a recharge statement in the chain payment issuance contract, and after the statement is verified, the recharge is completed; S3, a cash withdrawal process: the user operates the chain payment issuance contract to initiate a cash withdrawal operation, and the bank system queries the transaction status in the blockchain through the order number query, and confirms whether the information is in compliance by comparing the hash value, until the cash is issued to the user's designated account. The present invention combines blockchain, smart contracts and validator services to realize a safe, transparent, efficient and low-cost chain payment system; all operations are recorded on the blockchain to ensure transparency and traceability.

Description

Technical Field

[0001] The present invention mainly relates to the technical field of blockchain, and specifically to a method for implementing an oracle that maps legal currency to blockchain. Background Art

[0002] In blockchain technology, oracles play an important role in connecting on-chain smart contracts with external data sources. They are a bridge between the real world and blockchain systems to achieve data exchange. Through data verification and contract execution, oracles provide a reliable external data source for blockchain networks, ensuring the reliability and security of smart contracts. In blockchain application scenarios such as stablecoins, lending, financial derivatives, insurance, and prediction markets, oracles play a key role.

[0003] At present, common technologies include smart contract payment, multi-signature and stablecoin payment; smart contracts automatically execute payments, multi-signatures enhance security, and stablecoins maintain price stability; blockchain payment technology has significant advantages in improving efficiency and reducing costs, but it also faces some technical problems; although smart contract payments are automated and transparent, the execution cost is high, especially when the network is congested; multi-signatures enhance security but are complex to operate and may result in slow payments; stablecoins are subject to regulation and market trust restrictions; these challenges require technological innovation and solutions to address. Summary of the invention

[0004] Based on this, the purpose of the present invention is to provide a method for implementing an oracle that maps legal currency to a blockchain, so as to solve the technical problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] A method for implementing a oracle machine for mapping legal currency to a blockchain, the oracle machine implementation method comprising the following steps:

[0007] S1. Validator application process: The applicant initiates an application to the Chainpay issuance contract. After the system determines whether the applicant is a validator with a history of bad behavior, the applicant will be added as a validator.

[0008] S2. Recharge process: The user first initiates a recharge transfer, then initiates a recharge statement in the chain payment issuance contract. After the statement is verified, the recharge is completed;

[0009] S3. Withdrawal process: The user operates the payment issuance contract on the chain to initiate a withdrawal operation. The bank system queries the transaction status on the blockchain through the order number, and confirms whether the information is consistent by comparing the hash value until the cash is issued to the user's designated account;

[0010] The on-chain payment issuance contract in the oracle implementation method also includes an abnormal order publicity mechanism. If the first validator or other validators submit an incorrect verification result, the system will immediately form and publicize the incorrect order, and other validators can intervene to handle the incorrect order at the first time.

[0011] Preferably, the S1, verifier application process further includes the following sub-steps:

[0012] S11. Applicants need to submit a certain number of tokens, and the number of tokens must be greater than 0;

[0013] S12. The on-chain payment issuance contract first determines whether the applicant has any bad behavior in the past. If so, the collateral assets of the validator are returned and the request is returned; if not, S13 is executed; the bad behavior specifically refers to the validator being marked as a historical saboteur in the past order processing process;

[0014] S13. Record the applicant's data, including the mortgage amount, account, status, and priority;

[0015] S14. The on-chain payment issuance contract adds qualified applicants to the validator list.

[0016] Preferably, the recharge transfer in S2, the recharge process, is specifically:

[0017] S21. The user initiates a recharge transfer request to the bank system and enters the required information, including bank card number, expiration date, CVV code, cardholder name, mobile phone number and recharge amount;

[0018] S22. The bank system sends the generated verification code to the mobile phone number bound by the user, and the user confirms the payment request by entering the verification code;

[0019] S23. The bank system processes the payment request and returns payment success information to the user after completion.

[0020] Preferably, the recharge statement in the recharge process S2 is specifically:

[0021] S24. After completing the payment in the bank system, the user submits a recharge statement to the Chainpay issuance contract; the statement includes the order number and recharge amount information;

[0022] S25. After receiving the recharge statement, the Chain Payment Issuing Contract first determines whether the order has been processed based on the order number; if the order has been processed, the system marks the order as completed, the process ends, and the subsequent steps are skipped; if the order has not been processed, execute S26;

[0023] S26. The system records relevant information of the order, including order number, recharge time, recharge amount, and order status data.

[0024] Preferably, the declaration verification in S2, the recharge process, is specifically as follows:

[0025] S27. All active validators will compete to process the order and enter the declaration verification phase;

[0026] When executing S27, in order to ensure the fairness and efficiency of order allocation, the system will use a competitive algorithm to select validators. The calculation formula of the competitive algorithm is as follows:

[0027] in, is the weight coefficient;

[0028] : indicates competition score;

[0029] : Score historical performance, including the validator’s past verification accuracy score (AS) and submission speed score (T). The higher the accuracy and the faster the submission speed, the higher the score; : Total number of verifications, : Total time for verification request;

[0030] is the weight coefficient;

[0031] : A constant that amplifies the fraction so that sufficient accuracy can be maintained even when the fraction is very small;

[0032] : Number of verifications, : Total number of verifications;

[0033] : refers to the number of pledged tokens. The higher the number of pledged tokens, the higher the score.

[0034] : the amount of mortgage, : Scaling factor to scale or weight the amount of collateral;

[0035] : refers to the response speed after receiving the order to be verified. The faster the response, the higher the score;

[0036] : Indicates the time required for the verifier to respond to the verification request;

[0037] Based on competition rating The system calculates the score of each validator based on the formula. The system selects the validator with the highest score for the order. If multiple validators have the same score, a validator is randomly selected for verification.

[0038] S28. The selected verifier obtains the list of statements to be verified from the on-chain payment issuance contract and prepares for verification;

[0039] S29. The verifier queries the order data from the recharge query API of the bank system according to the order number to verify the authenticity and consistency of the payment;

[0040] S210. The verifier checks the order data and the results of the on-chain payment to confirm or question the validity of the payment;

[0041] S211. The verifier uploads the verification result to the blockchain, and the result is recorded in the blockchain to ensure that the data cannot be tampered with.

[0042] S212. The first verifier who successfully submits the correct verification result will receive the transaction fee paid by the user as a reward.

[0043] Preferably, S2, the recharge process also includes avoiding and handling sabotage behaviors:

[0044] S213. When the first verifier submits the verification result, the system first determines whether the order status is still pending verification; if the verification result has been submitted, the order status will change to pending confirmation;

[0045] S214. When the first verifier submits the verification result, the system checks whether the number of collateral tokens of the verifier is greater than the amount of the order to be verified; the verification is allowed only if the collateral amount is greater than the order amount in the system check;

[0046] S215. When the first validator submits the verification result, other validators can question the result;

[0047] If the challenge is successful, these validators will equally share all the token assets pledged by the first validator;

[0048] If the challenge fails, the challenger does not need to take any further action and the order status remains unchanged.

[0049] Preferably, in S215, when there are doubts, manual processing will be involved. The manual operator will re-query the bank API, confirm the final result of the order, and handle it according to right or wrong. The verifier who submits the wrong verification result will be punished; the punishment is to mark the verifier who submits the wrong verification result as a history destroyer.

[0050] Preferably, if the manual processing is performed or the verification result of the first verifier is not questioned within two hours, S216 is executed;

[0051] S216. The on-chain payment issuance contract will issue an equal proportion of token assets to the user’s blockchain account;

[0052] S217. At this point, the recharge process is completed and the user successfully receives the recharged token assets.

[0053] Preferably, the S3, user withdrawal is specifically:

[0054] S31. The user first operates the on-chain payment issuance contract, initiates a withdrawal operation, and transfers the token assets into the contract;

[0055] S32. Based on the hash and order number returned by the blockchain, the user then generates a signature using the timestamp to initiate a withdrawal request to the bank;

[0056] S33, the bank system first verifies whether the sender is the person who made the transaction hash by signing, and then executes S34 after confirmation;

[0057] S34. The banking system queries the transaction status in the blockchain through the order number and hash query;

[0058] S35. When the number of transaction confirmations reaches 20, the transaction will be considered successful and cash will be issued to the user's designated account. The user's withdrawal is now complete.

[0059] Preferably, the on-chain payment issuance contract in the oracle implementation method also includes an abnormal order publicity mechanism. If the first validator or other validators submit an erroneous verification result, the system will immediately publicize the erroneous order, and other validators can intervene to deal with the damaged order as soon as possible.

[0060] In summary, the present invention mainly has the following beneficial effects:

[0061] This method combines blockchain, smart contracts and verifier services to realize a secure, transparent, efficient and low-cost on-chain payment system. The authenticity of identity is ensured through real-name authentication contracts, and all operations are recorded on the blockchain to ensure transparency and traceability.

[0062] The oracle service verifies the order and payment results to ensure data accuracy. Users can make payments and withdrawals conveniently, providing users and merchants with convenient and secure payment solutions.

[0063] The solution enables users to quickly deposit and withdraw money. At the same time, the mutual questioning of validators is used to ensure the security of each transaction order.

[0064] In addition, hash algorithms are used in information verification and comparison to ensure unified security. At the same time, the huge amount of information stored in the entire system is protected to ensure transparency and security. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 It is the overall process framework diagram of the method of the present invention;

[0066] Figure 2 It is the overall flow chart of the method of the present invention;

[0067] Figure 3 A flow chart for verification by a verifier of the present invention;

[0068] Figure 4 The applicant's flowchart for the present invention;

[0069] Figure 5 This is a flow chart of recharge and transfer of the present invention;

[0070] Figure 6 It is a flow chart of the recharge statement of the present invention;

[0071] Figure 7 Logic flow chart for the operation of the oracle of the present invention. DETAILED DESCRIPTION

[0072] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention. Example

[0073] like Figure 1 , 3 As shown in , 5, 6, and 7, the statement verification in S2, the recharge process is specifically as follows:

[0074] S27. All active validators will compete to process the order and enter the declaration verification phase;

[0075] When executing S27, in order to ensure the fairness and efficiency of order allocation, the system will use a competitive algorithm to select validators. The calculation formula of the competitive algorithm is as follows:

[0076] in, is the weight coefficient;

[0077] : indicates competition score;

[0078] : Score historical performance, including the validator’s past verification accuracy score (AS) and submission speed score (T). The higher the accuracy and the faster the submission speed, the higher the score;

[0079] : Total number of verifications, : Total time for verification request;

[0080] is the weight coefficient;

[0081] : A constant that amplifies the fraction so that sufficient accuracy can be maintained even when the fraction is very small;

[0082] : Number of verifications, : Total number of verifications;

[0083] : refers to the number of pledged tokens. The higher the number of pledged tokens, the higher the score.

[0084] : the amount of mortgage, : Scaling factor to scale or weight the amount of collateral;

[0085] : refers to the response speed after receiving the order to be verified. The faster the response, the higher the score; : Indicates the time required for the verifier to respond to the verification request;

[0086] Based on competition rating The system calculates the score of each validator based on the formula. The system selects the validator with the highest score for the order. If multiple validators have the same score, a validator is randomly selected for verification.

[0087] S28. The selected verifier obtains the list of statements to be verified from the on-chain payment issuance contract and prepares for verification;

[0088] S29. The verifier queries the order data from the recharge query API of the bank system according to the order number to verify the authenticity and consistency of the payment;

[0089] S210. The verifier checks the order data and the results of the on-chain payment to confirm or question the validity of the payment;

[0090] S211. The verifier uploads the verification results to the blockchain, which is used to ensure that the data cannot be tampered with.

[0091] S212. The first validator who successfully submits the correct verification result will receive the transaction fee paid by the user as a reward;

[0092] S2. The recharge process also includes the avoidance and disposal of sabotage behavior:

[0093] S213. When the first verifier submits the verification result, the system first determines whether the order status is still pending verification; if the verification result has been submitted, the order status will change to pending confirmation;

[0094] S214. When the first verifier submits the verification result, the system checks whether the number of collateral tokens of the verifier is greater than the amount of the order to be verified. The verification is allowed only when the collateral amount is greater than the order amount.

[0095] S215. When the first validator submits the verification result, other validators can question the result;

[0096] If the challenge is successful, these validators will equally share all the token assets pledged by the first validator;

[0097] If the challenge fails, the challenger does not need to take any further action and the order status remains unchanged;

[0098] In S215, when there is a doubt, manual processing will be involved. The manual operator will re-query the bank API, confirm the final result of the order, and handle it according to right or wrong. The validator who submits the wrong verification result will be punished; the penalty is to mark the validator who submits the wrong verification result as a history destroyer;

[0099] If the verification result is not challenged within two hours after manual processing, S216 is executed;

[0100] S216. The on-chain payment issuance contract will issue an equal proportion of token assets to the user’s blockchain account;

[0101] S217. At this point, the recharge process is completed and the user successfully receives the recharged token assets;

[0102] The on-chain payment issuance contract in the oracle implementation method also includes an abnormal order publicity mechanism. If the first validator or other validators submit an incorrect verification result, the system will immediately publicize the incorrect order, and other validators can intervene to deal with the damaged order as soon as possible.

[0103] It should be noted that, in this embodiment, Chain Payment is the name of an implementation carrier of the oracle implementation method of mapping legal currency to blockchain in the present invention;

[0104] The user first initiates a recharge request to the bank system, first obtains the current timestamp locally for use; the user's blockchain private key is used to calculate the signature, and the payment request is made by entering the user's personal information.

[0105] The bank system returns the verification code of the mobile phone number bound to the user's bank card. The user uses the verification code to initiate a payment request. Then the user initiates a recharge statement to the Chain Payment Issuance Contract. The Chain Payment Issuance Contract first determines whether the order has been processed based on the order number. If the order has not been processed, the data of the order is recorded.

[0106] All active validators will compete for this order; the system will The system calculates the score of each validator based on the formula. The system selects the validator with the highest score for the order. If multiple validators have the same score, a validator is randomly selected for verification.

[0107] The selected validator obtains the list of statements to be verified from the on-chain payment issuance contract and prepares for verification. According to the order number, the validator queries the recharge query API of the bank system for order data and uploads the verification results to the chain.

[0108] Before submitting the result, on the one hand, it is determined whether the order status is still pending verification. If it is verified, the order status will be pending confirmation. On the other hand, the number of collateral tokens of the current verifier and the user's recharge amount will be compared. Only orders with a collateral amount greater than the amount to be verified will be allowed to be verified;

[0109] The first verifier who uploads the verification result to the chain will receive the user's recharge fee if the verification result is correct.

[0110] At the same time, the order data and the on-chain payment result verifier can question it. If the question is raised, the verification result needs to be further uploaded to the chain.

[0111] If other validators submit verification results that they question, then manual intervention will be required. Manual query of the correct order results will be conducted through the re-query API, and then the validator who submitted the wrong verification results will be punished according to the correctness. At the same time, these validators who successfully questioned will share all the token assets pledged by the first validator.

[0112] When the manual processing is completed or the verification result submitted by the first verifier is not submitted by anyone else within two hours, the recharge will end and the on-chain payment issuance contract will issue an equal proportion of token assets to the user's blockchain account. At this point, the recharge is completed.

[0113] In addition, the system has an abnormal order disclosure mechanism. If the first validator or other validators submit an incorrect verification result, it will be seen by all other validators at the first time, and the order can be destroyed immediately.

[0114] like Figure 1 , 4As shown, S1. Validator application process: the applicant initiates an application operation to the chain payment issuance contract. After the system determines whether the applicant is a validator with a history of bad behavior, he / she joins the validator; S1. Validator application process also includes the following sub-steps:

[0115] S11. Applicants need to submit a certain number of tokens, and the number of tokens must be greater than 0;

[0116] S12. The on-chain payment issuance contract first determines whether the applicant has any bad behavior in the past. If so, the collateral assets of the validator are returned and the request is returned; if not, S13 is executed; the bad behavior specifically refers to the validator being marked as a historical saboteur in the past order processing process;

[0117] S13. Record the applicant's data, including the mortgage amount, account, status, and priority;

[0118] S14. The on-chain payment issuance contract adds qualified applicants to the validator list.

[0119] It should be noted that in this embodiment, applicants need to undergo qualification certification before becoming a verifier.

[0120] The applicant initiates an application operation to the Chainpay issuance contract. First, it is determined whether the applicant is a historical saboteur. After verification, it is confirmed that the applicant is not a historical saboteur, and the applicant's mortgaged assets are recorded before the applicant can join the validator.

[0121] If a validator engages in deliberate sabotage during the subsequent order competition process, he or she will be marked as a saboteur and removed from the validator list, ensuring that the entire system runs safely, quickly and stably.

[0122] like Figure 1 , 2 As shown, S3, withdrawal process: the user operates the payment issuance contract on the chain to initiate a withdrawal operation, the bank system queries the transaction status on the blockchain through the order number, and confirms whether the information is consistent by comparing the hash value until the cash is issued to the user's designated account;

[0123] S3. User withdrawal details are as follows:

[0124] S31. The user first operates the on-chain payment issuance contract, initiates a withdrawal operation, and transfers the token assets into the contract;

[0125] S32. Based on the hash and order number returned by the blockchain, the user then generates a signature using the timestamp to initiate a withdrawal request to the bank;

[0126] S33, the bank system first verifies whether the sender is the person who made the transaction hash by signing, and then executes S34 after confirmation;

[0127] S34. The banking system queries the transaction status in the blockchain through the order number and hash query;

[0128] S35. When the number of transaction confirmations reaches 20, the transaction is considered successful and cash is distributed to the user's designated account. The user's cash withdrawal is now complete.

[0129] It should be noted that in this embodiment, the user first operates the on-chain payment issuance contract to initiate a withdrawal operation, transfers the token assets into the contract, and then uses the hash and order number returned by the blockchain, and then the user uses the timestamp to generate a signature to initiate a withdrawal request to the bank;

[0130] The bank system first verifies through signature whether the sender is the person who sent the transaction hash. After confirmation, the bank system queries the transaction status in the blockchain through the order number and hash query, and distributes cash to the user's designated account. At this point, the user's withdrawal is completed.

[0131] The working principle of the present invention is:

[0132] The system constructed by this method combining blockchain, smart contracts and validator services includes users, validators, system personnel, bank systems, and on-chain payment issuance contracts. In the construction of this method, it is assumed that the bank has products of this solution.

[0133] Among the above-mentioned verifiers, only those who have passed the applicant qualification certification can become verifiers.

[0134] The applicant initiates an application operation to the Chainpay issuance contract. First, it is determined whether the applicant is a historical saboteur. After verification, it is confirmed that the applicant is not a historical saboteur, and the applicant's mortgaged assets are recorded before the applicant can join the validator.

[0135] If a validator shows deliberate sabotage during the subsequent order competition process, he / she will be marked as a saboteur and removed from the validator list, ensuring the safe, fast and stable operation of the entire system.

[0136] The contract first calls the historical record checking algorithm to determine whether the applicant is a validator with a history of bad behavior.

[0137] if is_malicious_verifier(applicant):

[0138] return reject_application()

[0139] When a user tops up,

[0140] The user initiates a recharge request to the bank system, first obtains the current timestamp locally for use; the user's blockchain private key is used to calculate the signature, and the payment request is made by entering the user's personal information.

[0141] The bank system returns the verification code of the mobile phone number bound to the user's bank card. The user uses the verification code to initiate a payment request. Then the user initiates a recharge statement to the Chain Payment Issuance Contract. The Chain Payment Issuance Contract first determines whether the order has been processed based on the order number. If the order has not been processed, the data of the order is recorded.

[0142] The specific judgment method is to use a hash mapping algorithm to judge whether the order number has been processed;

[0143] order_hash = keccak256(order_id)

[0144] if is_order_processed(order_hash):

[0145] return complete_process()

[0146] All active validators will compete for this order; the system will The system calculates the score of each validator based on the formula. The system selects the validator with the highest score for the order. If multiple validators have the same score, a validator is randomly selected for verification.

[0147] The selected validator obtains the list of statements to be verified from the on-chain payment issuance contract and prepares for verification. According to the order number, the validator queries the recharge query API of the bank system for order data and uploads the verification results to the chain.

[0148] Among them, the query verification algorithm involved is:

[0149] bank_data = query_bank_api(order_id)

[0150] if verify_payment_consistency(bank_data, chain_data):

[0151] submit_verification_result()

[0152] Before submitting the result, on the one hand, it is determined whether the order status is still pending verification. If it is verified, the order status will be pending confirmation. On the other hand, the number of collateral tokens of the current verifier and the user's recharge amount will be compared. Only orders with a collateral amount greater than the amount to be verified will be allowed to be verified;

[0153] The first verifier who uploads the verification result to the chain will receive the user's recharge fee if the verification result is correct.

[0154] At the same time, the order data and the on-chain payment result verifier can question it. If the question is raised, the verification result needs to be further uploaded to the chain.

[0155] If other validators submit verification results that they question, then manual intervention will be required. Manual query of the correct order results will be conducted through the re-query API, and then the validator who submitted the wrong verification results will be punished according to the correctness. At the same time, these validators who successfully questioned will share all the token assets pledged by the first validator.

[0156] When the manual processing is completed or the verification result submitted by the first verifier is not submitted by anyone else within two hours, the recharge will end and the on-chain payment issuance contract will issue an equal proportion of token assets to the user's blockchain account. At this point, the recharge is completed.

[0157] In addition, the system has an abnormal order disclosure mechanism. If the first validator or other validators submit an incorrect verification result, it will be seen by all other validators at the first time, and the order can be destroyed immediately.

[0158] When users withdraw cash,

[0159] The user first operates the on-chain payment issuance contract to initiate a withdrawal operation, transfers the token assets into the contract, and then uses the hash and order number returned by the blockchain, and then uses the timestamp to generate a signature to initiate a withdrawal request to the bank; the signature generation algorithm is specifically as follows:

[0160] TypeHash = keccak256("Message(uint256 timestamp,string orderId)")

[0161] MessageHash = keccak256(TypeHash, keccak256(timestamp), keccak256(orderId))

[0162] DomainSeparator = keccak256(DomainTypeHash, keccak256(name),keccak256(version), chainId, address)

[0163] Digest = keccak256("\x19\x01", DomainSeparator, MessageHash)

[0164] Signature = Sign(PrivateKey, Digest)

[0165] The bank system first verifies through signature whether the sender is the person who sent the transaction hash. After confirmation, the bank system queries the transaction status in the blockchain through the order number and hash query, and distributes cash to the user's designated account. At this point, the user's withdrawal is completed.

[0166] The above embodiments are only for illustrating the technical idea of ​​the present invention, and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution in accordance with the technical idea proposed by the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for implementing a oracle that maps legal currency to a blockchain, characterized in that ,The oracle implementation method includes the following steps: S1. Validator application process: The applicant initiates an application to the Chainpay issuance contract. After the system determines whether the applicant is a validator with a history of bad behavior, the applicant will be added as a validator. S2. Recharge process: The user first initiates a recharge transfer, then initiates a recharge statement in the chain payment issuance contract. After the statement is verified, the recharge is completed; S3. Withdrawal process: The user operates the on-chain payment issuance contract to initiate a withdrawal operation. The bank system queries the transaction status on the blockchain through the order number, and confirms whether the information is consistent by comparing the hash value until the cash is issued to the user's designated account; The statement verification in S2, the recharge process is specifically as follows: S27. All active validators will compete to process orders and enter the statement verification phase; When executing S27, in order to ensure the fairness and efficiency of order allocation, the system will use a competitive algorithm to select validators. The calculation formula of the competitive algorithm is as follows: Score=α1*PS+α2*SS+α3*RS in, α1, α2, and α3 are weight coefficients; Score: indicates the competition score; PS: Score historical performance, including the validator's past verification accuracy score AS and submission speed score T. The higher the accuracy and the faster the submission speed, the higher the score; PS=α*AS+β*T tr: total number of verifications, t i : Total time for verification request; α and β are weight coefficients; 1e18: A constant used to magnify the fraction so that sufficient accuracy can be maintained even when the fraction is very small; sv: number of verifications, tv: total number of verifications; SS: refers to the number of pledged tokens. The higher the number of pledged tokens, the higher the score. SS=sa*sf sa: the amount of collateral, sf: the scaling factor to scale or weight the collateral amount; RS: refers to the response speed after receiving the order to be verified. The faster the response, the higher the score; RT: represents the time required for the verifier to respond to the verification request; The system calculates the score of each validator based on the competition score formula. The system selects the validator with the highest score for the order. If multiple validators have the same score, a validator is randomly selected for verification. S28. The selected verifier obtains the list of statements to be verified from the on-chain payment issuance contract and prepares for verification; S29. The verifier queries the order data from the recharge query API of the bank system according to the order number to verify the authenticity and consistency of the payment; S210. The verifier checks the order data and the results of the on-chain payment to confirm or question the validity of the payment; S211. The verifier uploads the verification result to the blockchain, and the result is recorded in the blockchain to ensure that the data cannot be tampered with. S212. The first verifier who successfully submits the correct verification result will receive the transaction fee paid by the user as a reward.

2. According to claim 1, a method for implementing a oracle for mapping legal currency to a blockchain is characterized in that: The S1. Verifier application process also includes the following sub-steps: S11. Applicants need to submit a certain number of tokens, and the number of tokens must be greater than 0; S12. The on-chain payment issuance contract first determines whether the applicant has any bad behavior in the past. If so, the collateral assets of the validator are returned and the request is returned; if not, S13 is executed; the bad behavior specifically refers to the validator being marked as a historical saboteur in the past order processing process; S13. Record the applicant's data, including the mortgage amount, account, status, and priority; S14. The on-chain payment issuance contract adds qualified applicants to the validator list.

3. According to claim 1, a method for implementing a oracle that maps legal currency to a blockchain is characterized in that: The recharge transfer described in S2, the recharge process is specifically as follows: S21. The user initiates a recharge transfer request to the bank system and enters the required information, including bank card number, expiration date, CVV code, cardholder name, mobile phone number and recharge amount; S22. The bank system sends the generated verification code to the mobile phone number bound by the user, and the user confirms the payment request by entering the verification code; S23. The bank system processes the payment request and returns payment success information to the user after completion.

4. According to claim 1, a method for implementing a oracle for mapping legal currency to a blockchain is characterized in that: The recharge statement in S2, the recharge process is specifically: S24. After completing the payment in the bank system, the user submits a recharge statement to the Chainpay issuance contract; the statement includes the order number and recharge amount information; S25. After receiving the recharge statement, the Chain Payment Issuing Contract first determines whether the order has been processed based on the order number; if the order has been processed, the system marks the order as completed, the process ends, and the subsequent steps are skipped; if the order has not been processed, execute S26; S26. The system records relevant information of the order, including order number, recharge time, recharge amount, and order status data.

5. According to claim 1, a method for implementing a oracle for mapping legal currency to a blockchain, characterized in that: S2. The recharge process also includes the avoidance and disposal of sabotage behavior: S213. When the first verifier submits the verification result, the system first determines whether the order status is still pending verification; if the verification result has been submitted, the order status will change to pending confirmation; S214. When the first verifier submits the verification result, the system checks whether the number of collateral tokens of the verifier is greater than the amount of the order to be verified; The system checks that verification is allowed only if the deposit amount is greater than the order amount; S215. When the first validator submits the verification result, other validators can question the result; If the challenge is successful, these validators will equally share all the token assets pledged by the first validator; If the challenge fails, the challenger does not need to take any further action and the order status remains unchanged.

6. According to claim 5, a method for implementing a oracle for mapping legal currency to a blockchain is characterized in that: In S215, when there are doubts, manual processing will be involved. The manual operator will re-query the bank API, confirm the final result of the order, and handle it according to right or wrong. The verifier who submits the wrong verification result will be punished; the punishment is to mark the verifier who submits the wrong verification result as a history destroyer.

7. A method for implementing a oracle for mapping legal currency to a blockchain according to claim 6, characterized in that: If the manual processing is carried out, or the verification result of the first verifier is not questioned within two hours, execute S216; S216. The on-chain payment issuance contract will issue an equal proportion of token assets to the user’s blockchain account; S217. At this point, the recharge process is completed and the user successfully receives the recharged token assets.

8. According to claim 1, a method for implementing a oracle that maps legal currency to a blockchain is characterized in that: The S3, user withdrawal is specifically as follows: S31. The user first operates the on-chain payment issuance contract, initiates a withdrawal operation, and transfers the token assets into the contract; S32. Based on the hash and order number returned by the blockchain, the user then generates a signature using the timestamp to initiate a withdrawal request to the bank; S33, the bank system first verifies whether the sender is the person who made the transaction hash by signing, and then executes S34 after confirmation; S34. The banking system queries the transaction status in the blockchain through the order number and hash query; S35. When the number of transaction confirmations reaches 20, the transaction will be considered successful and cash will be issued to the user's designated account. The user's withdrawal is now complete.

9. According to claim 1, a method for implementing a oracle for mapping legal currency to a blockchain, characterized in that: The on-chain payment issuance contract in the oracle implementation method also includes an abnormal order publicity mechanism. If the first validator or other validators submit an incorrect verification result, the system will immediately publicize the incorrect order, and other validators can intervene and deal with the damaged order as soon as possible.

Images