CN111292191A - Acceptance service alliance method, apparatus and storage medium - Google Patents
Acceptance service alliance method, apparatus and storage medium Download PDFInfo
- Publication number
- CN111292191A CN111292191A CN202010099077.4A CN202010099077A CN111292191A CN 111292191 A CN111292191 A CN 111292191A CN 202010099077 A CN202010099077 A CN 202010099077A CN 111292191 A CN111292191 A CN 111292191A
- Authority
- CN
- China
- Prior art keywords
- user
- transaction
- alliance
- federation
- rule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 72
- 230000004044 response Effects 0.000 claims description 26
- 238000012795 verification Methods 0.000 claims description 18
- 238000012546 transfer Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 8
- 238000010586 diagram Methods 0.000 description 12
- 230000008014 freezing Effects 0.000 description 5
- 238000007710 freezing Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000007812 deficiency Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention provides a acceptance service alliance method, equipment and a storage medium, which relate to the technical field of block chains and the like, and the method comprises the following steps: receiving a first create federation transaction including an address of a second user and first acceptance service federation rules; when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain; receiving a second create federation transaction including an address of the first user and second acceptance service federation rules; executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; otherwise, the second create federation transaction execution fails. The method and the device enable the payment channel in the lightning network or the lightning network to be available to the maximum, and improve the availability of the lightning network or the lightning network.
Description
Technical Field
The present application relates to the field of block chain technology, and in particular, to a method, device and storage medium for acceptance service federation.
Background
The acceptance trader provides acceptance services for the users who do not directly pass through the established channel in the lightning network or the lightning network in batch, namely, the users who do not directly pass through the established channel can carry out chain down-link account in batch;
if the users 1 and 2 are contractors, the users 3 and 1 have channels, and the users 4 and 2 have channels; user3 wants to initiate a chain down-link to user4, but the transactions of user3 and user4 are very low frequency, and the transactions of user3 and user2 are also very low frequency; in this case, the user3 initiates the offline transaction to the user4, which can either directly establish a channel with the user4 or establish a channel with the user2, but in either way, the highest availability of the payment channel cannot be achieved.
Disclosure of Invention
In view of the above-described deficiencies or inadequacies in the prior art, it would be desirable to provide an acceptance service federation method, apparatus, and storage medium that improves the availability of a lightning network or a lightning network.
In a first aspect, the present invention provides a method for acceptance service federation for blockchain nodes, the method comprising:
receiving a first create federation transaction; the first created alliance transaction is generated and sent by the first client in response to the first user and the second user providing acceptance services mutually, and comprises the address of the second user and first acceptance service alliance rules;
when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain;
receiving a second create federation transaction; the second established alliance transaction comprises the address of the first user and the second acceptance service alliance rule;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for carrying out arbitration and recording an arbitration result on the block chain.
In a second aspect, the present invention provides a method for a federation of acceptance services for a client, the method comprising:
in response to the current user and the second user providing acceptance services with each other, generating a first create federation transaction including an address of the second user and first acceptance service federation rules and sending to the blockchain node for the blockchain node to:
when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain;
receiving a second create federation transaction generated by a second client of a second user; the second established alliance transaction comprises the address of the current user and the second acceptance service alliance rule;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the current user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating the block chain nodes and recording the arbitration result on the block chain.
In a third aspect, the present invention provides a method for a federation of acceptance services applicable to a client, the method comprising:
generating a second created federation transaction including the address of the first user and the second acceptance service federation rule in response to the current user querying the first acceptance service federation rule from the blockchain and providing acceptance services to and from the first user; the first acceptance service alliance rule and the address of the current user are recorded on the blockchain when the first alliance creating transaction is successfully executed by the blockchain node, and the first alliance creating transaction is generated by a first client in response to the first user and the current user providing acceptance services mutually and is sent to the blockchain node;
sending the second create federation transaction to the blockchain node for the blockchain node to:
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating the block chain nodes and recording the arbitration result on the block chain.
In a fourth aspect, the present invention also provides an apparatus comprising one or more processors and memory, wherein the memory contains instructions executable by the one or more processors to cause the one or more processors to perform an acceptance service federation method provided according to embodiments of the present invention.
In a fifth aspect, the present invention also provides a storage medium storing a computer program for causing a computer to execute the acceptance service federation method provided according to the embodiments of the present invention.
Embodiments of the present invention provide a method, apparatus, and storage medium for a redemption service federation by receiving a first create federation transaction including an address of a second user and first redemption service federation rules; when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain; receiving a second create federation transaction including an address of the first user and second acceptance service federation rules; executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; and if not, the second alliance transaction establishment execution failure method enables the payment channel in the lightning network or the lightning network to reach the highest availability, and the availability of the lightning network or the lightning network is improved.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
fig. 1 is a flowchart of a method for acceptance service federation according to an embodiment of the present invention.
FIG. 2 is a flow diagram of a preferred embodiment of the method shown in FIG. 1.
FIG. 3 is a flow chart of a preferred embodiment of the method shown in FIG. 2.
Figure 4 is a flow diagram of another acceptance service federation method provided by an embodiment of the present invention.
FIG. 5 is a flow chart of a preferred embodiment of the method shown in FIG. 4.
Figure 6 is a flow diagram of another acceptance service federation method provided by an embodiment of the present invention.
FIG. 7 is a flow chart of a preferred embodiment of the method shown in FIG. 6.
Fig. 8 is a schematic structural diagram of an apparatus according to an embodiment of the present invention.
Detailed Description
The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 is a flowchart of a method for acceptance service federation according to an embodiment of the present invention. As shown in fig. 1, in this embodiment, the present invention provides a method for a block chain node to join acceptance services, where the method includes:
s12: receiving a first create federation transaction; the first created alliance transaction is generated and sent by the first client in response to the first user and the second user providing acceptance services mutually, and comprises the address of the second user and first acceptance service alliance rules;
s13: when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain;
s14: receiving a second create federation transaction; the second established alliance transaction comprises the address of the first user and the second acceptance service alliance rule;
s15: executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for carrying out arbitration and recording an arbitration result on the block chain.
Specifically, a first user (a contractor A) and a second user (a contractor B) mutually agree to provide a contractor service, and the contractor A firstly sends a alliance creating transaction; the first acceptance service alliance rule comprises a first guarantee of the first user, a first penalty of the first user, a second guarantee of the second user and a second penalty of the second user, and the second acceptance service alliance rule comprises a third guarantee of the first user, a third penalty of the first user, a fourth guarantee of the second user and a fourth penalty of the second user; step S13 is configured to "upon successful execution of the first create federation transaction, freeze the first deposit from the account of the first user, record the address of the second user, the first deposit, the first penalty, the second deposit, and the second penalty on the blockchain"; step S15 is configured to "execute the second create federation transaction, perform the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty; when at least one item fails to verify, the second alliance transaction establishment fails to execute, and the first insurance fund is unfrozen; recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on the block chain when all the verification items are successful as an example;
a first client of underwriter a generates a first create federation transaction tx1 in response to underwriter a and underwriter B providing acceptance services with each other, tx1 including address addr (B) of underwriter B, first guarantee fund of underwriter a (a1), first penalty fund of underwriter a (a1), second guarantee fund of underwriter B (B1), second penalty of underwriter B (B1);
the blockchain node executes step S12, and receives tx1(addr (B), estimate (a1), penalty (a1), estimate (B1), penalty (B1));
the block chain node executes step S13, and when the execution of tx1 is successful, the account of the contractor a is frozen (a1), and addr (B), the account (a1), the penalty (a1), the account (B1), and the penalty (B1) are recorded on the block chain;
when the execution of tx1 is unsuccessful, then nothing is frozen from the account of the underwriter A (A1), and addr (B), nothing (A1), penalty (A1), intent (B1), penalty (B1) are recorded on the blockchain;
the second client of underwriter B generates a second create federation transaction tx2 in response to underwriter B querying from the blockchain for amount (A1), pensty (A1), amount (B1), pensity (B1), providing acceptance services with underwriter A, tx2 including address addr (A) of underwriter A, third deposit amount (A2) of underwriter A, third penalty penity (A2) of underwriter A, fourth deposit amount (B2) of underwriter B, and fourth penalty penity (B2) of underwriter B;
the blockchain node executes step S14, and receives tx2(addr (a), estimate (a2), penalty (a2), estimate (B2), penalty (B2));
the blockchain node performs step S15, performs tx2, performs the following verifications: verifying whether freezing of amount (B2) from the account of the underwriter B was successful, verifying whether amount (A1) is the same as amount (A2), verifying whether amount (A2) is the same as amount (B2), verifying whether penalty (A1) is the same as penalty (A2), and verifying whether penalty (B1) is the same as penalty (B2); when at least one item fails to verify, the second create alliance transaction fails to execute, unfreezing the amout (A1); when all the verification items are successful, addr (A), amunt (A2), pending (A2), amunt (B2) and pending (B2) are recorded on the block chain.
The first established alliance transaction and the second established alliance transaction which are successfully executed are used for providing acceptance services for the first user and the second user according to corresponding acceptance service alliance rules, the first acceptance service alliance rules and the second acceptance service alliance rules are used for conducting arbitration, and arbitration results are recorded on the block chain;
suppose that user C accepts a chain transfer with an amount of 100aaa to user D through the accepting merchant A and then through the accepting merchant B, and the accepting process of the chain transfer is as follows:
the user C sends request information of which the request firstly passes through the acceptance company A and then accepts the account transfer of the 100aaa link through the acceptance company B to the user D, the user D generates a first random number R after agreeing, and sends a first hash value H (R) of the first random number to the user A;
the user C sends H (R) to the acceptance company A, judges whether the balance which can be accepted in the channel of the acceptance company A is more than or equal to 100 aaa: if yes, 100aaa is frozen, and if the first random number R sent by the acceptance company a is received and hash (R) ═ h (R), 100aaa is defrosted, and the downlink transaction including 100aaa is sent to the acceptance company a;
the acceptance company A sends H (R) to the acceptance company B, and judges whether the balance which can be accepted in the channel of the acceptance company B is more than or equal to 100 aaa: if yes, 100aaa is frozen, and if the first random number R sent by the acceptance company B is received and hash (R) ═ h (R), 100aaa is defrosted, and the downlink transaction including 100aaa is sent to the acceptance company B;
the acceptance company B sends H (R) to the user D, and judges whether the acceptance balance in the channel with the user D is more than or equal to 100 aaa: if yes, freezing 100aaa, and committing to unfreeze 100aaa and send the downlink transaction including 100aaa to user D if the first random number R sent by user D is received and hash (R) ═ h (R);
assuming that the contractor a receives the R sent by the contractor B at this time, but does not send the offline transaction including 100aaa to the contractor B within the pre-configured first time duration, the process of arbitrating the block chain node and recording the arbitration result on the block chain is as follows:
the underwriter B will generate an arbitrated transaction comprising R, H (R), frozen 100aaa and the latest one-chain transaction sent by underwriter A, and the blockchain link point will record R, H (R), frozen 100aaa and the latest one-chain transaction sent by underwriter A on the blockchain;
if the block link point fails to receive the transfer certification of the offline transaction including 100aaa, which is submitted by the acceptor A and sent to the acceptor B, within the preconfigured second time length, at this time, the block link point unfreezes the dependency (A1) in the dependency (A1) according to the dependency (A1) and the dependency (A1) recorded on the block chain, transfers the dependency (A1) to the acceptor B, and records the arbitration result (the current collection amount of the acceptor B is the sum of the latest offline transaction amount sent by the acceptor A and 100aaa) on the block chain.
In more embodiments, the order of sending the alliance creating transaction is not limited to the above examples, and the alliance creating transaction can be sent by the acceptance provider B first, so long as the acceptance provider a queries the acceptance service alliance rule of the acceptance provider B from the block chain, then the alliance creating transaction of the acceptance provider a is generated and sent to the block chain node, and the same technical effect can be achieved.
In further embodiments, the first acceptance service federation rule and the second acceptance service federation rule may be further configured according to actual requirements, for example, the first acceptance service federation rule is configured as a first deposit for the first user, a first penalty for the first user, a second deposit for the second user, a second penalty for the second user, a first service fee for the first user, a second service fee for the second user; configuring a second acceptance service federation rule as: the third guarantee fee of the first user, the third penalty fee of the first user, the fourth guarantee fee of the second user, the fourth penalty fee of the second user, the third service fee of the first user and the fourth service fee of the second user can realize the same technical effect. Accordingly, step S13 is configured to "freeze the first deposit from the account of the first user and record the address of the second user, the first deposit, the first penalty, the second deposit, the second penalty, the first service fee, and the second service fee on the blockchain" when the execution of the first create federation transaction is successful; step S15 is configured to "execute the second create federation transaction, perform the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, verifying whether the second penalty is the same as the fourth penalty, verifying whether the first service charge is the same as the third service charge, and verifying whether the second service charge is the same as the fourth service charge; when at least one item fails to verify, the second alliance transaction establishment fails to execute, and the first insurance fund is unfrozen; and recording the address of the first user, the third guarantee fund, the third penalty fund, the fourth guarantee fund and the fourth penalty fund on the block chain when all the verification items are successful.
The above-mentioned embodiments enable the payment channel in the lightning network or the lightning network to reach the highest availability, and improve the availability of the lightning network or the lightning network.
Preferably, the first acceptance service federation rule includes a first guarantee of the first user, a first penalty of the first user, a second guarantee of the second user, and a second penalty of the second user, the second acceptance service federation rule includes a third guarantee of the first user, a third penalty of the first user, a fourth guarantee of the second user, and a fourth penalty of the second user, and the recording of the address of the second user and the first acceptance service federation rule on the blockchain upon successful execution of the first create federation transaction includes:
when the first alliance establishing transaction is successfully executed, freezing a first insurance fund from an account of a first user, and recording an address of a second user, the first insurance fund, a first penalty, a second insurance fund and a second penalty on a blockchain;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment failure comprises the following steps:
performing a second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction establishment fails to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 1, and the details are not repeated here.
FIG. 2 is a flow diagram of a preferred embodiment of the method shown in FIG. 1. As shown in fig. 2, in a preferred embodiment, the method further comprises:
s16: receiving a first alliance removing transaction sent by a first client; wherein the first de-alliance transaction is generated and sent by the first client in response to the first user and the second user de-offering the acceptance service from each other, the first de-alliance transaction comprising an address of the second user;
s17: and when the execution of the first alliance removing transaction is successful, unfreezing all the frozen first funds of the first user, transferring the unfrozen first funds to the first user and the second user according to a pre-configured alliance removing rule, and recording the address of the second user on the block chain.
Specifically, pre-configured rules for releasing the alliance are used for deducting 30% of the guarantee fund of an acceptance company which provides acceptance services mutually from the first acceptance company to another acceptance company of the acceptance service alliance;
the first client responds to the release of mutual acceptance service provided by the acceptance company A and the acceptance company B, generates a first release alliance transaction tx3(addr (B)) including the address of the acceptance company B and sends the address to the blockchain node;
the blockchain node performs step S16, receiving tx3(addr (b));
the blockchain node performs step S17, and when tx3(addr (B)) is successfully performed, unfreezes all of the frozen first deposit of the acceptor a, transfers 30% of the unfrozen first deposit to the acceptor B, transfers 70% of the unfrozen first deposit to the acceptor a, and records addr (B) on the blockchain.
In further embodiments, the rules for clearing the coalition may also be configured according to actual requirements, for example, by deducting 50aaa from a guarantee fund that first proposes to clear the contractors who provide the acceptance service with each other to another contractor of the acceptance service coalition, which may achieve the same technical effect.
In further embodiments, a first decombination transaction may also be generated and transmitted by the second client in response to acceptance merchant B and acceptance merchant a releasing the mutual provision of acceptance services, the first decombination transaction including address addr (a) of acceptance merchant a; correspondingly, when the first alliance removing transaction is successfully executed, the blockchain link point unfreezes all the frozen first deposit of the accepting company B, transfers 30% of the unfrozen first deposit to the accepting company A, transfers 70% of the unfrozen first deposit to the accepting company B, and records addr (A) on the blockchain, so that the same technical effect can be achieved.
FIG. 3 is a flow chart of a preferred embodiment of the method shown in FIG. 2. As shown in fig. 3, in a preferred embodiment, the method further includes:
s18: receiving a second alliance removing transaction sent by a second client; the second alliance removing transaction is generated and sent by the second client in response to the second user inquiring the first alliance removing transaction from the blockchain and providing acceptance services with the first user removing mutually, and the second alliance removing transaction comprises the address of the first user;
s19: and when the execution of the second alliance removing transaction is successful, unfreezing all the frozen fourth deposit of the second user, transferring the unfrozen fourth deposit to the second user, and recording the address of the first user on the block chain.
If the contractor B does not want to release the mutual offering of the acceptance service with the contractor A, the steps S18 and S19 are not performed; however, if steps S18 and S19 are not executed, the deposit frozen by contractor B cannot be retrieved.
And when the acceptance manager B does not execute the step S18 and the step S19, if the first client of the acceptance manager A sends a third created alliance transaction comprising the address of the acceptance manager B and a third acceptance service alliance rule to the block chain node, the block chain node executes the third created alliance transaction, and the third acceptance service alliance rule is judged to be matched with the second acceptance service alliance rule, the third created alliance transaction and the second created alliance transaction which are both executed successfully are used for providing acceptance services for the acceptance manager A and the acceptance manager B according to the corresponding acceptance service alliance rules.
In further embodiments, if the first de-alliance transaction is generated by the second client, the second de-alliance transaction is generated and transmitted by the first client in response to acceptance merchant a querying the first de-alliance transaction from the blockchain, and releasing mutual acceptance services with acceptance merchant B, the second de-alliance transaction comprising address addr (B) of acceptance merchant B; accordingly, upon successful execution of the second decombination transaction, the frozen first funds of the underwriter a are all thawed, the thawed first funds are transferred to the underwriter a, and addr (b) is recorded on the blockchain.
Figure 4 is a flow diagram of another acceptance service federation method provided by an embodiment of the present invention. As shown in fig. 4, in this embodiment, the present invention provides a method for a compliance service federation applicable to a client, where the method includes:
s22: in response to the current user and the second user providing acceptance services with each other, generating a first create federation transaction including an address of the second user and first acceptance service federation rules and sending to the blockchain node for the blockchain node to:
when the first alliance establishing transaction is successfully executed, recording the address of the second user and the first acceptance service alliance rule on the block chain;
receiving a second create federation transaction generated by a second client of a second user; the second established alliance transaction comprises the address of the current user and the second acceptance service alliance rule;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the current user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating the block chain nodes and recording the arbitration result on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 1, and the details are not repeated here.
Preferably, the first acceptance service alliance rule comprises a first guarantee of the current user, a first penalty of the current user, a second guarantee of the second user, and a second penalty of the second user, the second acceptance service alliance rule comprises a third guarantee of the current user, a third penalty of the current user, a fourth guarantee of the second user, and a fourth penalty of the second user, and the recording of the address of the second user and the first acceptance service alliance rule on the blockchain upon successful execution of the first create alliance transaction comprises:
when the first alliance establishing transaction is successfully executed, freezing a first insurance fund from an account of a current user, and recording an address of a second user, the first insurance fund, a first penalty, a second insurance fund and a second penalty on a blockchain;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the current user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment failure comprises the following steps:
performing a second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction establishment fails to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 1, and the details are not repeated here.
FIG. 5 is a flow chart of a preferred embodiment of the method shown in FIG. 4. As shown in fig. 5, in a preferred embodiment, the method further includes:
s23: and responding to the release of mutual acceptance service between the current user and the second user, generating a first release alliance transaction comprising the address of the second user, and sending the first release alliance transaction to the blockchain node, so that the blockchain node unfreezes all the frozen first security funds of the current user when the first release alliance transaction is successfully executed, transferring the unfrozen first security funds to the first user and the second user according to a pre-configured release alliance rule, and recording the address of the second user on the blockchain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 3, and the details are not repeated here.
Preferably, after the first alliance removing transaction is inquired by the second user, the second client responds to mutual acceptance service removal between the second user and the current user, generates a second alliance removing transaction including the address of the current user and sends the second alliance removing transaction to the block chain node, so that when the block chain node executes the second alliance removing transaction successfully, the block chain node unfreezes all the frozen fourth deposit of the second user, transfers the unfrozen fourth deposit to the second user, and records the address of the current user on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 4, and the details are not repeated here.
Figure 6 is a flow diagram of another acceptance service federation method provided by an embodiment of the present invention. As shown in fig. 6, in this embodiment, the present invention provides a method for federation of acceptance services applicable to a client, where the method includes:
s32: generating a second created federation transaction including the address of the first user and the second acceptance service federation rule in response to the current user querying the first acceptance service federation rule from the blockchain and providing acceptance services to and from the first user; the first acceptance service alliance rule and the address of the current user are recorded on the blockchain when the first alliance creating transaction is successfully executed by the blockchain node, and the first alliance creating transaction is generated by a first client in response to the first user and the current user providing acceptance services mutually and is sent to the blockchain node;
s33: sending the second create federation transaction to the blockchain node for the blockchain node to:
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed;
and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating the block chain nodes and recording the arbitration result on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 1, and the details are not repeated here.
Preferably, the first acceptance service alliance rule comprises a first guarantee of the first user, a first penalty of the first user, a second guarantee of the current user, and a second penalty of the current user, the second acceptance service alliance rule comprises a third guarantee of the first user, a third penalty of the first user, a fourth guarantee of the current user, and a fourth penalty of the current user, and the recording the address of the current user and the first acceptance service alliance rule on the blockchain upon successful execution of the first create alliance transaction comprises:
when the first alliance establishing transaction is successfully executed, freezing a first security deposit from an account of a first user, and recording the address of the current user, the first security deposit, a first penalty, a second security deposit and a second penalty on a blockchain;
executing a second create federation transaction, verifying whether the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment failure comprises the following steps:
performing a second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the current user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction establishment fails to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on the block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 1, and the details are not repeated here.
FIG. 7 is a flow chart of a preferred embodiment of the method shown in FIG. 6. As shown in fig. 7, in a preferred embodiment, the method further includes:
s34: in response to a current user querying a first deordorization transaction from a blockchain, deproviding an acceptance service with the first user to generate a second deordorization transaction that includes an address of the first user; the first alliance removing transaction comprises an address of a current user, the first alliance removing transaction is generated by the first client in response to the first user and the current user removing mutual provision acceptance service and is sent to a block chain node, so that when the block chain node successfully executes the first alliance removing transaction, all frozen first funds of the first user are unfrozen, the unfrozen first funds are transferred to the first user and the current user according to a pre-configured alliance removing rule, and the address of the current user is recorded on a block chain;
s35: and sending the second alliance removing transaction to a block chain node, so that when the block chain node successfully executes the second alliance removing transaction, the block chain node unfreezes all the frozen fourth deposit of the current user, transfers the unfrozen fourth deposit to the current user, and records the address of the first user on a block chain.
The acceptance service alliance principle of the above embodiment can refer to the method shown in fig. 4, and the details are not repeated here.
Fig. 8 is a schematic structural diagram of an apparatus according to an embodiment of the present invention. As shown in fig. 8, as another aspect, the present application also provides an apparatus 800 including one or more Central Processing Units (CPUs) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM803, various programs and data necessary for the operation of the apparatus 800 are also stored. The CPU801, ROM802, and RAM803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.
In particular, the acceptance service federation method described in any of the above embodiments may be implemented as a computer software program, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program comprising program code for performing an acceptance service federation method. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811.
As yet another aspect, the present application also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the apparatus of the above-described embodiment; or it may be a separate computer readable storage medium not incorporated into the device. The computer readable storage medium stores one or more programs for use by one or more processors in performing the acceptance service federation methods described in the present application.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units or modules described in the embodiments of the present application may be implemented by software or hardware. The described units or modules may also be provided in a processor, for example, each of the described units may be a software program provided in a computer or a mobile intelligent device, or may be a separately configured hardware device. Wherein the designation of a unit or module does not in some way constitute a limitation of the unit or module itself.
The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the present application. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.
Claims (13)
1. An acceptance service federation method, adapted for use with a blockchain node, the method comprising:
receiving a first create federation transaction; wherein the first create federation transaction is generated and sent by a first client in response to a first user and a second user providing acceptance services with each other, the first create federation transaction including an address of the second user and first acceptance service federation rules;
upon successful execution of the first create federation transaction, recording the address of the second user and the first acceptance service federation rules on a blockchain;
receiving a second create federation transaction; wherein the second CreateFederation transaction is generated and sent by a second client in response to a second user querying the first acceptance service federation rule from a blockchain, providing acceptance services with the first user, the second CreateFederation transaction including the address of the first user and a second acceptance service federation rule;
executing the second create federation transaction, verifying that the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on a block chain; if not, the second alliance transaction establishment is failed to execute;
and the first established alliance transaction and the second established alliance transaction which are successfully executed are used for providing acceptance services for the first user and the second user according to corresponding acceptance service alliance rules, and the first acceptance service alliance rule and the second acceptance service alliance rule are used for carrying out arbitration and recording arbitration results on a block chain.
2. The method of claim 1, wherein the first acceptance service federation rule includes a first guarantee of the first user, a first penalty of the first user, a second guarantee of the second user, a second penalty of the second user, the second acceptance service federation rule including a third guarantee of the first user, a third penalty of the first user, a fourth guarantee of the second user, a fourth penalty of the second user, the recording the address of the second user and the first acceptance service federation rule on a blockchain upon successful execution of the first create federation transaction comprises:
when the first alliance establishing transaction is executed successfully, the first insurance fund is frozen from the account of the first user, and the address of the second user, the first insurance fund, the first penalty, the second insurance fund and the second penalty are recorded on a block chain;
said executing said second create federation transaction, verifying that said first acceptance service federation rule and said second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on a block chain; if not, the second alliance transaction establishment failure comprises the following steps:
executing the second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction is failed to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on a blockchain.
3. The method of claim 2, further comprising:
receiving a first alliance removing transaction sent by a first client; wherein the first de-alliance transaction is generated and sent by the first client in response to the first user and the second user de-offering the acceptance service from each other, the first de-alliance transaction comprising an address of the second user;
and when the execution of the first alliance removing transaction is successful, unfreezing all the frozen first funds of the first user, transferring the unfrozen first funds to the first user and the second user according to a pre-configured alliance removing rule, and recording the address of the second user on a block chain.
4. The method of claim 3, further comprising:
receiving a second alliance removing transaction sent by a second client; wherein the second de-alliance transaction is generated and sent by the second client in response to a second user querying the first de-alliance transaction from a blockchain, the second de-alliance transaction comprising an address of the first user, and the first user de-offering acceptance services from each other;
and when the second alliance removing transaction is successfully executed, unfreezing all the frozen fourth deposit of the second user, transferring the unfrozen fourth deposit to the second user, and recording the address of the first user on a block chain.
5. A method of acceptance service federation applicable to a client, the method comprising:
in response to the current user and the second user providing acceptance services with each other, generating a first create federation transaction including an address of the second user and first acceptance service federation rules and sending to a blockchain node for the blockchain node to:
upon successful execution of the first create federation transaction, recording the address of the second user and the first acceptance service federation rules on a blockchain;
receiving a second create federation transaction generated by a second client of the second user; wherein the second create federation transaction is generated and sent by the second client in response to the second user querying the first acceptance service federation rule from the blockchain, providing acceptance services with the current user, the second create federation transaction including the address of the current user and the second acceptance service federation rule;
executing the second create federation transaction, verifying that the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the current user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment is failed to execute; and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating by the blockchain node and recording an arbitration result on the blockchain.
6. The method of claim 5, wherein the first acceptance service federation rule includes a first guarantee of a current user, a first penalty of the current user, a second guarantee of the second user, and a second penalty of the second user, wherein the second acceptance service federation rule includes a third guarantee of the current user, a third penalty of the current user, a fourth guarantee of the second user, and a fourth penalty of the second user, and wherein recording the address of the second user and the first acceptance service federation rule on a blockchain upon successful execution of the first create federation transaction comprises:
when the first alliance establishing transaction is successfully executed, the first insurance fund is frozen from the account of the current user, and the address of the second user, the first insurance fund, the first penalty, the second insurance fund and the second penalty are recorded on a block chain;
said executing said second create federation transaction, verifying that said first acceptance service federation rule and said second acceptance service federation rule match: if yes, recording the address of the current user and the second acceptance service union rule on the block chain; if not, the second alliance transaction establishment failure comprises the following steps:
executing the second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the second user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction is failed to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on a blockchain.
7. The method of claim 5, further comprising:
responding to the situation that the current user and the second user release mutual offering of acceptance services, generating a first alliance releasing transaction comprising the address of the second user and sending the first alliance releasing transaction to a blockchain node, so that the blockchain node unfreezes all frozen first guarantees of the current user when the first alliance releasing transaction is executed successfully, transferring the unfrozen first guarantees to the first user and the second user according to a pre-configured alliance releasing rule, and recording the address of the second user on a blockchain.
8. The method of claim 7, wherein after the first deagglomeration transaction is queried by the second user, the second client responds to the second user and the current user to release the mutual acceptance service, generates a second deagglation transaction including an address of the current user and sends the second deagglation transaction to the blockchain node, so that the blockchain node unfreezes all of the frozen fourth deposit of the second user when the second deagglation transaction is successfully performed, transfers the unfrozen fourth deposit to the second user, and records the address of the current user on the blockchain.
9. A method of acceptance service federation applicable to a client, the method comprising:
generating a second create federation transaction including an address of the first user and a second acceptance service federation rule in response to the current user querying the first acceptance service federation rule from the blockchain to provide acceptance services to and from the first user; the first acceptance service alliance rule and the address of the current user are recorded on a blockchain when the first alliance creating transaction is successfully executed by the blockchain node, and the first alliance creating transaction is generated by a first client in response to the first user and the current user providing acceptance services mutually and is sent to the blockchain node;
sending the second create federation transaction to a blockchain node for the blockchain node to:
executing the second create federation transaction, verifying that the first acceptance service federation rule and the second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on a block chain; if not, the second alliance transaction establishment is failed to execute;
and the first established alliance transaction and the second established alliance transaction which are successfully executed are used for providing acceptance services for the first user and the current user according to corresponding acceptance service alliance rules, and the first acceptance service alliance rule and the second acceptance service alliance rule are used for arbitrating by the blockchain nodes and recording the arbitration result on the blockchain.
10. The method of claim 9, wherein the first acceptance service federation rule includes a first guarantee of the first user, a first penalty of the first user, a second guarantee of the current user, a second penalty of the current user, the second acceptance service federation rule including a third guarantee of the first user, a third penalty of the first user, a fourth guarantee of the current user, a fourth penalty of the current user, the recording of the address of the current user and the first acceptance service federation rule on a blockchain upon successful execution of the first create federation transaction comprises:
when the first alliance establishing transaction is successfully executed, the first insurance fund is frozen from the account of the first user, and the address of the current user, the first insurance fund, the first penalty, the second insurance fund and the second penalty are recorded on a block chain;
said executing said second create federation transaction, verifying that said first acceptance service federation rule and said second acceptance service federation rule match: if yes, recording the address of the first user and the second acceptance service union rule on a block chain; if not, the second alliance transaction establishment failure comprises the following steps:
executing the second create federation transaction, performing the following verifications: verifying whether the fourth deposit is successfully frozen from the account of the current user, verifying whether the first deposit is the same as the third deposit, verifying whether the second deposit is the same as the fourth deposit, verifying whether the first penalty is the same as the third penalty, and verifying whether the second penalty is the same as the fourth penalty;
when at least one item fails to verify, the second alliance transaction is failed to execute, and the first insurance fund is unfrozen;
and when all the verification items are successful, recording the address of the first user, the third guarantee deposit, the third penalty deposit, the fourth guarantee deposit and the fourth penalty deposit on a blockchain.
11. The method of claim 9, further comprising:
in response to a current user querying a first deordorization transaction from a blockchain, deproviding an acceptance service with the first user to generate a second deordorization transaction that includes an address of the first user; the first alliance removing transaction comprises an address of a current user, the first alliance removing transaction is generated by the first client in response to the first user and the current user removing mutual provision acceptance service and is sent to a block chain node, so that when the block chain node successfully executes the first alliance removing transaction, all frozen first funds of the first user are unfrozen, the unfrozen first funds are transferred to the first user and the current user according to a pre-configured alliance removing rule, and the address of the current user is recorded on a block chain;
and sending the second alliance removing transaction to a block chain node, so that when the block chain node successfully executes the second alliance removing transaction, the block chain node unfreezes all the frozen fourth deposit of the current user, transfers the unfrozen fourth deposit to the current user, and records the address of the first user on a block chain.
12. An apparatus, characterized in that the apparatus comprises:
one or more processors;
a memory for storing one or more programs,
the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method recited in any of claims 1-11.
13. A storage medium storing a computer program, characterized in that the program, when executed by a processor, implements the method according to any one of claims 1-11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010099077.4A CN111292191A (en) | 2020-02-18 | 2020-02-18 | Acceptance service alliance method, apparatus and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010099077.4A CN111292191A (en) | 2020-02-18 | 2020-02-18 | Acceptance service alliance method, apparatus and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111292191A true CN111292191A (en) | 2020-06-16 |
Family
ID=71025596
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010099077.4A Pending CN111292191A (en) | 2020-02-18 | 2020-02-18 | Acceptance service alliance method, apparatus and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111292191A (en) |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109191288A (en) * | 2018-07-03 | 2019-01-11 | 深圳声笑科技有限公司 | Transaction system, method, apparatus and storage medium based on block chain |
| CN109377208A (en) * | 2018-10-24 | 2019-02-22 | 天津理工大学 | A kind of wisdom chemical industrial park credit payment based on block chain and circulation method |
| CN109726251A (en) * | 2018-12-28 | 2019-05-07 | 苏州鸿链信息科技有限公司 | A kind of across chain distributed business system and method based on the development of block chain |
| CN109829719A (en) * | 2019-02-22 | 2019-05-31 | 中国农业银行股份有限公司 | A kind of connectionless across account book DvP settlement method and system |
| JP2019087167A (en) * | 2017-11-10 | 2019-06-06 | 齋 石田 | Remittance system, remittance method, and device for undertaking remittance and method for undertaking remittance |
| CN109872235A (en) * | 2019-01-25 | 2019-06-11 | 东莞市大易产业链服务有限公司 | A kind of digital asset interoperability methods based on block chain technology |
| US20190213584A1 (en) * | 2018-01-11 | 2019-07-11 | Mastercard International Incorporated | Method and system for tokenized replacement of crypto currency addresses |
| CN110084594A (en) * | 2019-04-01 | 2019-08-02 | 杜晓楠 | A kind of block chain method of commerce and device by lightning network |
| CN110232572A (en) * | 2019-06-10 | 2019-09-13 | 深圳市链联科技有限公司 | A kind of transaction implementation method in alliance's block catenary system |
| CN110417917A (en) * | 2019-08-26 | 2019-11-05 | 京东数字科技控股有限公司 | Method, system, computer equipment and medium for bill circulation |
| CN110599143A (en) * | 2019-07-31 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Data processing method, related device and medium |
| CN110796549A (en) * | 2019-11-06 | 2020-02-14 | 杭州复杂美科技有限公司 | Transaction method, apparatus and storage medium |
-
2020
- 2020-02-18 CN CN202010099077.4A patent/CN111292191A/en active Pending
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2019087167A (en) * | 2017-11-10 | 2019-06-06 | 齋 石田 | Remittance system, remittance method, and device for undertaking remittance and method for undertaking remittance |
| US20190213584A1 (en) * | 2018-01-11 | 2019-07-11 | Mastercard International Incorporated | Method and system for tokenized replacement of crypto currency addresses |
| CN109191288A (en) * | 2018-07-03 | 2019-01-11 | 深圳声笑科技有限公司 | Transaction system, method, apparatus and storage medium based on block chain |
| CN109377208A (en) * | 2018-10-24 | 2019-02-22 | 天津理工大学 | A kind of wisdom chemical industrial park credit payment based on block chain and circulation method |
| CN109726251A (en) * | 2018-12-28 | 2019-05-07 | 苏州鸿链信息科技有限公司 | A kind of across chain distributed business system and method based on the development of block chain |
| CN109872235A (en) * | 2019-01-25 | 2019-06-11 | 东莞市大易产业链服务有限公司 | A kind of digital asset interoperability methods based on block chain technology |
| CN109829719A (en) * | 2019-02-22 | 2019-05-31 | 中国农业银行股份有限公司 | A kind of connectionless across account book DvP settlement method and system |
| CN110084594A (en) * | 2019-04-01 | 2019-08-02 | 杜晓楠 | A kind of block chain method of commerce and device by lightning network |
| CN110232572A (en) * | 2019-06-10 | 2019-09-13 | 深圳市链联科技有限公司 | A kind of transaction implementation method in alliance's block catenary system |
| CN110599143A (en) * | 2019-07-31 | 2019-12-20 | 腾讯科技（深圳）有限公司 | Data processing method, related device and medium |
| CN110417917A (en) * | 2019-08-26 | 2019-11-05 | 京东数字科技控股有限公司 | Method, system, computer equipment and medium for bill circulation |
| CN110796549A (en) * | 2019-11-06 | 2020-02-14 | 杭州复杂美科技有限公司 | Transaction method, apparatus and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 李博 等: "区块链技术在金融方向应用的发展及展望" * |
| 黄涵禧: "应用智能合约的简易承兑汇票实践" * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110175913B (en) | Data processing system, method, computing device and storage medium based on block chain | |
| US20210326813A1 (en) | Parallel Chain Cross-Chain Transaction Method, Device and Storage Medium | |
| CN108764868B (en) | Block chain node proxy reconciliation method and block reconciliation proxy node | |
| CN110363665B (en) | Credit right data processing method, device, equipment and medium | |
| CN110458557B (en) | Payment method, payment equipment and storage medium | |
| WO2020029631A1 (en) | Transaction method and system based on centralized settlement and blockchain deposit certificates | |
| CN110866824A (en) | Cross-chain transaction method and device based on parallel chain and block chain system | |
| CN110070357B (en) | Data processing method, device and system | |
| US20240281802A1 (en) | Digital Currency-Based Payment Method, Platform and System, and Terminal | |
| CN111598650A (en) | Resource request transaction method based on block chain network and related device | |
| Su et al. | Cross-chain exchange by transaction dependence with conditional transaction method | |
| CN112488725A (en) | Private authorized transfer method, device and storage medium | |
| CN111242614A (en) | Wallet account asset retrieving method, collection guarantee method, equipment and storage medium | |
| CN110889682A (en) | Payment information processing method, device, medium and equipment based on block chain | |
| CN112184228B (en) | Asset exchange method, device and storage medium | |
| CN111292191A (en) | Acceptance service alliance method, apparatus and storage medium | |
| CN111524011B (en) | Parallel link consensus validation method, apparatus, and storage medium | |
| CN114238520A (en) | Data sharing method and device | |
| CN112598411A (en) | Retrievable privacy authorization transfer method, apparatus and storage medium | |
| CN111586172A (en) | Data processing method, device, equipment and medium | |
| CN110992172A (en) | Offline payment method, device and storage medium | |
| CN113222576B (en) | Delayed transfer method, computer device and storage medium | |
| KR102475662B1 (en) | Method and system for managing point using blockchain based on distributed ledger | |
| CN112000731B (en) | Data processing method and device, electronic equipment and storage medium | |
| CN111311407B (en) | Data processing method and device based on block chain system and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200616 |