CN112400298B

CN112400298B - Verification transaction system and method for adding to an electronic blockchain

Info

Publication number: CN112400298B
Application number: CN201880094976.6A
Authority: CN
Inventors: 杰夫·斯托尔曼
Original assignee: Jie FuSituoerman
Current assignee: Jie FuSituoerman
Priority date: 2018-06-22
Filing date: 2018-06-22
Publication date: 2024-04-02
Anticipated expiration: 2038-06-22
Also published as: WO2019245577A1; CN112400298A; EP3811581A4; JP7179300B2; JP2023015223A; EP3811581A1; JP2021530010A

Abstract

A system is disclosed for verifying blockchain transaction integrity before transactions are added to an electronic blockchain, in part, using a protocol-based automated method. The use of such a system circumvents the current expensive consensus mechanism for validating transactions prior to inclusion in the underlying electronic blockchain. In a preferred embodiment, the disclosed system may be implemented in a blockchain environment in which both parties to a transaction "trust" each other, where trust may be demonstrated in different ways. In such an example, the system provides a protocol-based automated verification of transactions that have been approved by both parties to the transaction, so that records of the verified transactions can be appended to a blockchain.

Description

Verification transaction system and method for adding to an electronic blockchain

Technical Field

The present invention relates generally to the field of blockchain validation. One mechanism, commonly referred to as a consensus mechanism, verifies the integrity of the new transaction, may incorporate the new transaction into an electronic blockchain in which it was added prior to adding it to the blockchain, and further verifies the integrity of the generated updated blockchain. More particularly, the present invention relates to a system implemented in a blockchain environment, wherein the transaction parties "trust" each other, wherein trust may be one or more of the following: (a) Known to other parties, (b) trust in available chase compensation if the transaction is not completed as expected; or (c) the ability to verify the accuracy and integrity of the transaction prior to verifying the transaction, such that a protocol-based automated transaction verification may verify the new transaction prior to attachment to an electronic blockchain.

Background

The purpose of a cryptocurrency protocol such as bitcoin is to maintain a real-time transaction ledger that is resistant to double-flower attacks by a malicious bye-court general attack by a actor who may wish to violate an accepted protocol. See lamort, l.shostak, r.; pease, m. (1982), "The Byzantine Generals Problem" and "ACM Transactions on Programming Languages and Systems". To support anonymity of the transaction party (more precisely, pseudonyms) while avoiding the override of the owning ledger "owner", bitcoin employs a decentralized verification process in which the mineworker network ensures consensus of bitcoin transaction ledgers. These miners are motivated to participate in the consensus mechanism by a rewards program to provide a consensus confirmation regarding the blocks to be appended to the blockchain.

The work of miners, or mining, includes a workload proof calculation that is so difficult to design and resource complex that it is costly for any one miner (or attacker) to create multiple accounts to attempt to control or transfer the blockchain. For example, miners may obtain rewards of approximately $1,500,000 per day to protect blockchains, according to current bitcoin prices and rewards schedules. It is pointed out that a significant portion of this money is only used for power to perform the necessary processing for the proof of workload calculation. Given the increasing computational complexity required to establish consensus (depending in part on the history and size of the bitcoin blockchain), the workload-based consensus protocol is slow, requiring up to an hour to reasonably confirm a payment to prevent double flowers. See Jae Kwon, "Tendermint: consensus Without Mining", draft V0.6, http: /(tendermint.com/docs/enddermint.pdf).

End-users or consumer markets that use blockchain technology (e.g., many cryptocurrencies) are de-centralized so that they are not unduly affected by individual users, businesses, or government entities. This decentralized or decentralized market is the motive force for many customers. In fact, many such markets are deliberately designed to support anonymous, untrusted participants.

The combination of decentralization and anonymous-or more precisely, support of a actor using a pseudonym-has led to a bias in such markets and such people towards unauthorized verification systems (i.e., verification systems in which anyone can compete for rewards without any competition for permission) because by design, no central authority exercises override to the system. The transaction is authenticated by having both parties authorize the transaction. Typically, this is accomplished by each party applying its own digital signature, thereby establishing its own authorization and consent to the transaction. Such agreed transactions are then bundled into a block in the context of a blockchain system and then appended to a blockchain that may be a "parent" blockchain.

Such systems then rely on anonymous validators (e.g., bitcoin miners) to add these chunks to the blockchain, e.g., workload certification calculations, using the consensus mechanism. The bitcoin uses this consensus mechanism, which is initially a mechanism to ensure the integrity of transaction blocks added to blockchain logs or ledgers, by anonymous, self-selecting, unauthorized miners to verify new blocks. Such unauthorized consensus systems generally follow the bitcoin paper written by Satoshi Nakamoto. See S.Nakamoto, "Bitcoin: A peer-to-peer electronic cash system",2008.

One disadvantage of this consensus mechanism is that rewards must be provided to entice people to become miners. In addition, bitcoin and other markets have established proof of work tests for miners to limit the ability of any miner or group of miners to take over the system and add contaminated blocks to the blockchain. The cost of testing is high or difficult by workload proven, for example: through brute force calculations, it can be very expensive to create too many validators to overwhelm system consensus and validate improper transactions. At the same time, these markets need to provide sufficiently valuable rewards to entice miners to make the necessary investments to pass the workload certification tests. This results in the high cost of the consensus mechanism described above.

The mechanism also allows certain blocks to be rolled back. In the event of a conflict found in the verified blocks, the "undo" of some blocks of the blockchain will provide a higher level of assurance of the integrity of the entire blockchain. But this further delays the final verification of the transaction.

Other cryptocurrencies attempt to reduce the cost of authentication by implementing different consensus techniques. The ethernet platform strives to implement a equity proof program that does not create computational challenges for workload proof and does not require the expense of high electricity to solve a problem. Although the rewards of the ethernet are less than the rewards provided by the bitcoin, the same is true of the fees charged.

In contrast to the off-centered market, the enterprise market (e.g., financial market clearing systems) is typically centered. They serve both anonymous and identified but untrusted participants. Because of their centralization, they can be serviced by a more cost-effective, authority-bearing billing system. In such a licensed system, a central institution reviews and distributes system validators, but the validation process is still distributed among the validators, who must still agree to approve the transaction block. These validated and audited verifiers need not pay a large amount of rewards, but need only be paid a simple salary. In addition, because the central authority has a higher degree of trust in its licensed agents, the verification process can be shortened and the chance or need for rollback reduced. Because of its lower operating costs, this alternative consensus mechanism is being used to develop many new licensed applications. Such a system allows transactions of anonymous parties to be verified by a determined verifier. The audit process and periodic audits of the central manager may further enhance collusion resistance. JaeKwon writes a description of a solution regarding this set of rights, "Tendermint: consensus WithoutMining".

Other applications seeking blockchain technical advantages cover transactions made by parties that know each other and who are reasonably trusted (e.g., existing constrained contracts or other legal basis that provides relatively predictable compensation for pursuit). For such transactions, there is an opportunity to completely circumvent the consensus mechanism described above, thereby further reducing operating costs. In addition, for transactions that include details of highly confidential nature, it may be beneficial to be able to avoid exposing transaction information to the verifier only. So far, such a mechanism has not been proposed. Thus, opportunities for such systems have matured.

The present disclosure addresses the problems and opportunities. In a preferred embodiment, the described systems and methods provide an application in which transactions are conducted between participants that are known and trusted to each other (or, without a sufficient level of trust, participants have sufficient chase compensation to correct false statements or improper behavior of one or more participants). The disclosed system and method creates an efficient protocol-based automated system that validates transactions by following a computer-readable protocol to assemble blocks to be added to a blockchain without the intervention of numerous agents to reach consensus.

A variety of consensus models have been developed in an attempt to address the block verification problem. For the purpose of the present invention, these various consensus models are affected by two criteria: no authority and authority. As can be seen from table 1 below, both systems can support anonymous (pseudonymous) and known users. Neither mode requires users to trust each other. Both provide incentives (e.g., rewards or salaries) for parties willing to participate in establishing a consensus to verify a transaction block attached to a blockchain.

Table 1: comparison of blockchain verification methods

^₁ _{Trust means that each party has confidence that (1) each contractor will fully fulfill its transaction or (2) have valid laws or other means to correct the situation where the party cannot fulfill its obligation.}

The incentive mechanisms provided to consensus participants vary from model to model. The unlicensed system provides a high prize to justify the competing costs of winning the prize. On the other hand, a licensed system typically pays a fixed salary to a known censored agent.

Some examples of such systems have been designed and disclosed. A method and system is disclosed in a U.S. patent No.: 9569771, name of invention: method and System For Storage and Retrieval ofBlockchain Block Using Galois Fields to Lesavic et al ("771 patent" or "Lesavicut al"). The' 771patent discloses a method and system for securely storing and retrieving one or more chunks of a blockchain using modified galois fields on a cloud or point-to-point communication network. More specifically, the' 771patent appears to focus on the use of the galois field to enhance the security of storing and retrieving electronic data over a cloud communication network. The 771patent appears to have failed to disclose or suggest a method for protocol-based automated transaction integrity verification prior to attaching a transaction record to a tile or directly to a parent blockchain.

Another example of a system is disclosed in a U.S. patent application, application number: 15/086801, name of invention: systems and Methods of Blockchain Transaction Recordation applicants: fay et al ("801 application" or "Fay et al"). The' 801application teaches a computer system in communication with a distributed blockchain computing system that includes a plurality of computing nodes. One obvious core element and step of the' 801application method is to monitor the process and generate transactions, depending on the determination of when to verify two separate transactions to form a record of the transaction exchange (e.g., one transaction from a to B, another transaction from B to a). If one of the parties fails to submit a transaction or the submitted transaction fails, the computer system may generate a new blockchain transaction that cancels the other of the two related transactions.

Thus, the' 801application relies significantly on matching of a single transaction record. This creates several problems. First, at least two component transactions are required for each complete transaction. This requires additional processing time and results in the blockchain becoming larger and at a faster rate. Second, when the initial transaction needs to be canceled, the completed transaction needs to process at least four component transactions, further exacerbating the performance and scalability costs. Finally, the process of "Fay et al" does not provide a method or system for protocol-based automated verification of completed transactions. For example, in "Fay et al," where it may be necessary to reverse or undo the initial transaction component, the process cannot be automatically handled because it is not possible for the protocol-based process to anticipate all possible revisions.

Because the protocol-based automation system of the present invention expects and relies on the following conditions: all parties to the transaction verify their trust in candidate transactions that have been or are to be conducted, and in the event these conditions are met, no consensus incentive needs to be reached to verify the transaction. The preconditions for the confirmation of the transaction party and the preconditions for the party to agree to the items and conditions of the specified transaction are that the underlying transaction is sufficiently verified.

Disclosure of Invention

The present invention overcomes the shortcomings of the prior art and meets the needs described above by providing a system and method for verifying the integrity of a transaction prior to recording the verified transaction into an electronic blockchain.

The preferred embodiment of the present invention is a protocol-based method for verifying the integrity of an electronic record of a transaction-prior to adding the record to an electronic tile in an electronic blockchain-the protocol comprising the steps of: (a) Obtaining a first confirmation from at least a first party, transferring an asset as part of a transaction, each of the first parties agreeing to at least one transaction condition of the transaction; (b) Obtaining a second acknowledgement from at least one second party to receive an asset as part of said transaction, each of said second parties verifying a respective agreement of each of said first parties and at least one transaction condition of said transaction; (c) Creating a verified electronic record of the transaction based on the received first and second acknowledgements; (d) Adding the verified electronic record to a block of an electronic transaction; and (e) adding the electronic transaction block to the blockchain.

Another preferred embodiment of the present invention is a protocol-based method for verifying the integrity of an electronic record of a transaction before it is added to an electronic tile in an electronic blockchain, the method comprising the steps of: (a) Verifying that all electronic records contained in a block are validated by a transferor and at least one recipient of at least one underlying transaction, wherein the electronic transaction is associated with at least one condition of the at least one underlying transaction; (b) Adding the verified block to the electronic blockchain.

Another preferred embodiment of the present invention is a computer system for verifying the integrity of an electronic record of a transaction before the electronic record is added to an electronic block in an electronic blockchain, the system comprising: (a) at least one computer server; (b) A set of terminals, each of the set of terminals being associated with a first and second set of parties respectively associated with a transaction; (c) Machine-readable instructions stored on the at least one computer server, and when executed, manage a blockchain data structure associated with the transaction and cause the at least one computer server to:

i. receiving a transaction specification associated with the transaction from at least one of the set of first parties;

obtaining a confirmation from at least one of the set of second parties confirming that the transaction specification is verified;

sending an electronic data transmission request to each of said remaining group of terminals, said electronic data transmission request requesting said acquisition confirmation of verification of said transaction specification;

receiving a validation of verification of the transaction specification associated with the first and second sets of parties from each of the remaining sets of terminals;

creating a validated electronic record of said transaction, wherein said validated electronic record of said transaction is based on a receipt of a validation of said set of parties;

adding the validated electronic record to a transaction block, wherein the transaction block is appended to the blockchain data structure; and

adding the transaction block to the blockchain data structure.

Drawings

For the purpose of illustrating the invention, the drawings show certain aspects and preferred embodiments that are presently preferred. It is to be understood, however, that the invention is not limited to the specific method or process steps or system elements illustrated in the drawings, but is further disclosed and claimed in accordance with the appended claims.

FIG. 1 is an overview system diagram illustrating key participants and elements associated with an exemplary embodiment of the system of the invention for verifying transactions to be maintained on an electronic blockchain.

Fig. 2 is another system block diagram of an exemplary embodiment of the primary system elements and communication processes within the system of the present invention.

FIG. 3 is a system flow diagram of an exemplary embodiment of certain steps of the method of the present invention, providing an exemplary overview of the process flow.

Fig. 4 is another system flow diagram of an exemplary embodiment of certain steps of the method of the present invention including registration of a transferor and a transferee.

Description of the embodiments

Innovative systems, processes and methods for verifying transaction accuracy are disclosed and described with respect to several preferred embodiments and exemplary uses. The disclosed systems and methods implemented in those systems may have applicability to verifying transactions, including electronic distributed ledger transactions, such as tracking the sale or transfer of assets, whether physical or intangible. Table 1 above outlines various elements and elements related to verifying transactions between two or more parties.

Certain terms are used interchangeably throughout this application to describe certain preferred embodiments of the systems, processes and methods of the present invention. The use of these terms as references to specific embodiments or figures should not be construed as limiting the scope of the method or system of the present invention. At its heart, an embodiment of the present method and system is shown in FIG. 1, which shows a transferor (or seller) 70, an associated participant of a transferee (or recipient or buyer) 90, each having a computer terminal or computer input/output device, each such device being communicatively connected to a blockchain server 30 (maintained in the cloud 110). With respect to a participant, the term "seller" or "transferor" may include, for example, an entity that exchanges an asset for cash or some other form of compensation, or may simply transfer custody of the asset (e.g., legal evidence) to another entity. Likewise, the term "buyer" or "transferee" or "recipient" may include an entity that purchases an asset in cash or other form of compensation, or may be receiving temporary or final escrow of the asset (e.g., legal evidence) from another entity, including an intermediary, such as a shipper or courier service.

Still further, the term "asset" is intended to broadly encompass any product, material, equipment component, packaging, and/or physical or electronic document or file, including virtual assets, such as data, electronic files, intangible assets (e.g., domain names, various intellectual property, trademark, or copyright). Furthermore, the term "blockchain" is used in this application to refer to any technology that allows for the creation of non-repudiatable transaction records or ledgers that can resist counterfeiting.

The core or primary element of the innovative system is to verify (or confirm) various aspects of the transaction between the transferor and the recipient using a protocol implemented method. In more detail, the core of the method comprises: (a) Verifying an item associated with the transaction by a transferor of the asset; (b) Verifying a transferor of the verification item by a recipient of the asset; (c) The completed transaction is verified based on the verification of the party prior to appending the transaction record to the blockchain. The disclosed processes and underlying techniques are used to create an electronic log of non-repudiatable and verifiable transactions. The electronic log is validated using a secure identifier provided to and maintained by each system user. For example, each of several asset hosts uses the secure identifier each time an asset hosting entity creates, transfers, or receives an asset. Any other party to the potential witness transaction also uses this secure identifier.

The preferred embodiment of the transaction verification technique is particularly well suited for and useful for electronic blockchain verification. In accordance with the background overview, a blockchain is an electronic ledger of transactions. The blockchain or ledger "grows" as a "completed" block, and correspondingly, new transactions (e.g., changes in escrow or ownership) are added to the blockchain. The new transaction is divided into blocks and then the new blocks are added or appended to the blockchain only after each new block has undergone a verification process. As described above, in current blockchain systems, new blockverification is performed through a consensus mechanism that requires multiple agents, typically independent of transactions, to agree on the accuracy of the transaction and the blockbefore adding the transaction and the blockto the blockchain (which may also be the parent blockchain). In various embodiments, as disclosed herein, the block verification process is a protocol-based automated process, thereby greatly reducing the running cost of a distributed ledger and improving the performance of the system (i.e., the number of transactions that can be processed in a given time is greatly increased and the time required before a transaction can be verified can be greatly reduced).

Fig. 2 is an embodiment depicting the basic functional components of system 100 in a sales transaction for an asset. The seller (e.g., a manufacturer) attempts to sell some of its products to a buyer (e.g., one of its regular distributors). Because the buyer is a regular distributor of the manufacturer, each transaction party is known to each other. With this information, a certain degree of trust is established between the two parties. More specifically, a historical relationship between parties provides both a degree of trust that the seller is willing to deliver the product to the buyer and relies on the fact that the buyer will accurately verify receipt of the shipped product.

In the embodiment shown, the transferor uses a terminal 10 to authenticate his identity through an authentication service 15 trusted by the transferee. By way of example, the terminal 10 may be a desktop computer, a tablet computer, a mobile telephone or any other similar type of computer input-output device. The authentication service 15 may be part of the blockchain provider or may simply be a separate service that is accepted by both the acquirer and the blockchain provider. The authentication service 15 then provides authentication to the blockchain server 30, thereby causing the blockchain server 30 to provide access rights to the blockchain server 30 to the transferor.

Similarly, the transferee uses his terminal 20 to authenticate his identity through an authentication service 25. The authentication service 25 of the transferee. The authentication service 25 of the transferee may be the same service as the transferor or the authentication service of the transferee may be a different service accepted by the transferor and the blockchain vendor. The authentication service 25 of the transferee provides authentication to the blockchain server 30, thereby providing access to the blockchain server 30 to the transferee.

Next, when the transferor ships the specified asset, the transferor uploads a digitally signed transaction 18 (e.g., invoice or bill of lading) to the blockchain server 30. The digital transaction 18 will include a list of products in a transaction. At least the transferee name or the recipient of the product listed on the invoice is further included in the digital transaction 18 data. The blockchain server 30 then informs the transferee that the transaction is waiting for verification. The digital transaction 18 does not have to be transmitted to the transferee, but he or she may be informed of the transaction record that the transferee may access by logging into the blockchain server 30 and viewing the same digital transaction 18. In some embodiments, as shown in FIG. 2, the blockchain server 30 may be comprised of separate servers 30a,30b,30c, (1) manage transactions prior to adding transactions to a blockchain, (2) validate transactions, (3) add validated transactions to a blockchain, (4) validate the blockchain prior to adding the blockchain to the blockchain, and/or (5) add validated blockchains to the blockchain.

Next, the transferee looks at the identified and notified transactions on the blockchain server 30. If the transferee agrees that the received product matches the product contained in the digital transaction 18 specified by the transferor, the transferee then digitally uploads or signs a digital transaction 28 on the blockchain server 30. Once the digital transaction 28 is uploaded or signed by the transferee, the transaction is verified. More specifically, since both the transferee and the transferee know each other and/or have sufficient confidence in each other, once the confirmation record of the shipped product is known to be the same as the received product, the digital signatures of the transferee and the transferee are used as evidence without further independent verification or validation of the transaction. Thus, transactions may then be added to a block to be attached to the blockchain 35, or may be directly attached to the blockchain 35.

As shown in FIG. 2, the blockchain server 30 and the blockchain 35 may be replicated to allow multiple copies of the blockchain server 30, 30a,30b,30c and multiple copies of the blockchain 35, 35a,35b,35c to allow each transaction to be processed in parallel. Such a redundant system architecture eliminates the problem that any one component (either the blockchain server 30 or the blockchain 35) may be a single point of failure. For such redundant systems, a protocol-based automated consensus algorithm will be implemented within each blockchain server 30 to compare the results of the calculations and discard any calculations or vote to eliminate any of the blockchain servers 30 that are different from the rest of the majority of the blockchain servers 30. The blockchain server 30 is well known in redundant computer systems, and the comparison and voting process is a protocol-based automated process that does not require the intervention of a separate or independent agent.

Alternatively, in another embodiment of the system of the present invention, processing different asset transactions, such as one wine blockchain and another handbag blockchain, with multiple independent blockchain servers may be implemented.

Fig. 3 illustrates an exemplary embodiment of a process as disclosed above with respect to fig. 2. More specifically, the transferor authenticates its identity to the system via the authentication server 15 (step 115). The transferor then defines the contents of the transaction (step 116) and digitally signs the transaction 18 and uploads it to the blockchain server (step 118) to indicate that the transaction file 18 (e.g., invoice) accurately reflects the products and/or services provided to the transferee. The transferee also authenticates its identity to the blockchain server 30 via a separate authentication server 25 or the same authentication server 25 used by the transferor to the system. Further, as shown in FIG. 4, in another embodiment, if there are multiple transferors of elements of an asset to be transferred, each of the transferors registers in the system (step 135) and likewise the transferee registers in the system (step 145). Registration 135, 145 may be performed using different registration services 12 or a single registration service 12 agreed upon, as shown in fig. 1.

The blockchain server 30 then informs the transferee of a transaction, wherein the transaction waits for its approval (step 132), and the transferee reviews and verifies details of the transaction 18 on the blockchain server 30 (step 227) on the blockchain server 30 (e.g., compares the received item to the invoiced item). If everything is normal, the assignee attaches its digital signature to the transaction 28 on the blockchain server 30 (step 228). Having agreed to obtain approval from both parties, the blockchain server 30 can then add the transaction to a block (step 332) and then attach a new block to the blockchain 35, indicating that the transaction is approved.

The above example does not describe the situation in which the transferee is objecting to the accuracy of invoice 18. In this case, the transferee accounts for differences from transactions on the blockchain server 30. The blockchain server 30 notifies the transferor that the identified discrepancy requires at least review by the transferor.

At this stage, the transferor has several options. First, the transferor may modify the prior transaction 18 to account for differences recorded by the transferee and notified by the blockchain server 30, and sign a new transaction 18a. In this case, the original transaction 18 provided by the transferor, but perhaps (but not necessarily) not approved by the transferee, is recorded in a data structure that may be within or part of the subject blockchain.

Alternatively, the transferor may negotiate a difference with the transferee. If negotiations are performed between the transferor and the transferee, and the transferee accepts the original transaction 18, the transferee only digitally signs the transaction 28. However, if any changes occur to the original transaction 18, the transferor must sign the revised transaction 18a and obtain the transferee's signature before the recorded transaction can be added to a new block. As described above, in various embodiments, the blockchain server 30 may or may not track or record the history of negotiated or revised transactions before they are added to a block. For some purposes, a record or all of the negotiated and/or revised transaction information may need to be maintained and recorded in the blockchain. However, for other uses, such detailed history, negotiation and revised transaction information is of little or no importance after final transaction confirmation. Any of these may be readily implemented and realized by the disclosed methods and systems in various embodiments. For example, to simplify and reduce the complexity and data storage requirements of the core blockchain, a separate ledger or record may be created and maintained for negotiating or transacting revision logs.

Having described and disclosed preferred embodiments of the present systems, processes and methods, and in particular with reference to certain drawings and exemplary embodiments for verifying the integrity of blockchain transactions prior to adding the transactions to an electronic blockchain using a protocol-based automated method, such exemplary expressions should not be construed as limiting the scope of application of the methods or systems of the present invention. For example, the transaction integrity verification system described herein may be readily applied to other non-sales environments. The system of the present invention is equally applicable to the transfer of assets, such as evidence or other intangible assets, even if no transfer fees, offsets or costs are required. An example of such evidence or intangible asset transfer is a record of a legacy, such as a legacy registry. Another exemplary application of the system of the present invention relates to the use of contracts or transactions in which principal obligations, responsibilities and behaviors, such as "smart contracts", can be automatically monitored and recorded.

Those skilled in the art will appreciate that other modifications, alternatives, and/or other embodiments are possible and are within the true scope and spirit of the invention. It should also be understood that the appended claims are intended to cover all such modifications, alternatives, and/or other embodiments.

Claims

1. A protocol-based method for verifying the integrity of an electronic record of a transaction before the electronic record is added to an electronic block in an electronic blockchain, comprising the steps of:

a. obtaining a first confirmation from at least a first party, transferring an asset as part of a transaction, each of the first parties agreeing to at least one transaction condition of the transaction;

b. obtaining a second confirmation from at least a second party, receiving an asset as part of said transaction, each said second party verifying a respective agreement for each said first party and at least one transaction condition for said transaction;

c. creating a verified electronic record of the transaction based on the received first and second acknowledgements;

d. adding the verified electronic record to a block of an electronic transaction; and

e. adding the electronic transaction block to the blockchain, wherein the first party may negotiate a difference with the second party if the first party proposes a objection to the accuracy of the transaction; when any change occurs to the original transaction, the transferor must sign the revised transaction and obtain the signature of the second party before adding the revised transaction to a new block; to simplify or reduce the complexity and data storage requirements of the core blockchain, a separate ledger or record is created and maintained for the transaction revision log.

2. The protocol-based method of claim 1, further comprising registering each of the at least one first party to transfer an asset as part of the transaction and registering each of the at least one second party to receive an asset as part of the transaction.

3. The protocol-based method of claim 2, further comprising the steps of authenticating each of the at least one first party to transfer an asset as part of the transaction and authenticating each of the at least one second party to receive an asset as part of the transaction.

4. The protocol-based method of claim 1, wherein at least one of the first and second acknowledgements is a digital signature specification of the transaction.

5. The protocol-based method of claim 1, wherein at least one condition of the transaction is a transfer of asset hosting between at least two parties to the transaction.

6. The protocol-based method of claim 1, wherein the transaction is an asset transfer of the transaction between transaction parties.

7. The protocol-based method of claim 1, wherein the transaction is an asset sales of the transaction between parties.

8. The protocol-based method of claim 1, wherein step (a) is performed by obtaining a first acknowledgement from at least a first party to transfer at least a portion of an asset as part of a transaction, and each of the first party and each of the second parties agreeing to the same condition of at least one of the transactions.

9. The protocol-based method of claim 1, wherein the verified electronic record is added directly to the blockchain.

10. The protocol-based method of claim 1, wherein a record of any modification to at least one transaction condition of the transaction and any data record associated with the modification are separately recorded.

11. A protocol-based method for verifying the integrity of an electronic record of a transaction before the electronic record is added to an electronic block in an electronic blockchain, comprising the steps of:

a. verifying that all electronic records contained in a block are validated by a transferor and at least one recipient of at least one underlying transaction, wherein the electronic records are associated with at least one condition of the at least one underlying transaction; and

b. adding the verified block to the electronic blockchain, wherein if the transferee proposes objection to the accuracy of the transaction, the transferor may negotiate a discrepancy with the transferee; when the original transaction releases any changes, the transferor must sign the revised transaction and obtain the transferee's signature before adding the revised transaction to a new block; to simplify or reduce the complexity and data storage requirements of the core blockchain, a separate ledger or record is created and maintained for the transaction revision log.

12. The protocol-based method of claim 11, further comprising registering each of the at least one transferor and the at least one recipient with the at least one base transaction.

13. The protocol-based method of claim 11, further comprising authenticating each of the at least one transferor and the at least one recipient for the at least one base transaction.

14. The protocol-based method of claim 11, wherein the verification is a specification of a digital signature of the transaction.

15. The protocol-based method of claim 11, wherein the validation of the electronic record is validated by all parties to the underlying transaction.

16. The protocol-based method of claim 11, wherein the base transaction is a transfer of asset hosting of the transaction between parties.

17. A computer system for verifying the integrity of an electronic record of a transaction before the electronic record is added to an electronic block in an electronic blockchain, the computer system comprising:

a. at least one computer server;

b. a set of terminals, each of the set of terminals being associated with a first set of transferors and a second set of receiving partners respectively associated with a transaction;

c. machine-readable instructions stored on the at least one computer server, and when executed, manage a blockchain data structure associated with the transaction and cause the at least one computer server to:

i. receiving a transaction specification associated with the transaction from at least one of the first group of transferors;

obtaining a confirmation from at least one of the second set of receiving parties confirming that the transaction specification is verified;

sending an electronic data transfer request to each of the remaining group of terminals, said electronic data transfer request requesting said acquisition confirmation of verification of said transaction specification;

receiving a confirmation of verification of the transaction specification associated with the first and second sets of parties from each of the remaining set of terminals;

creating a validated electronic record of said transaction, wherein said validated electronic record of said transaction is based on validated receipts of said first and second sets of parties;

adding the transaction block to the blockchain data structure, wherein the first set of parties negotiates differences with the second set of parties if the second set of parties objectively addresses the accuracy of the transaction; when any change occurs to the original transaction, the first set of parties must sign the revised transaction and obtain the signature of the second set of parties before adding the revised transaction to a new block; to simplify or reduce the complexity and data storage requirements of the core blockchain, a separate ledger or record is created and maintained for the transaction revision log.

18. The computer system of claim 17, further comprising the step of registering each of the parties of the authenticated group associated with the transaction.

19. The computer system of claim 17, further comprising the step of verifying each of the set of parties associated with the transaction.

20. The computer system of claim 17, wherein the verified electronic record is a digital signature specification associated with the transaction.

21. The computer system of claim 17, wherein the transaction specification is a receipt of an asset transferred between a plurality of parties.

22. The computer system of claim 17, wherein the transaction is an asset transfer between a plurality of parties.

23. The computer system of claim 17, wherein the transaction is an asset sales between a plurality of parties.

24. The computer system of claim 17, wherein the verified electronic record is added directly to the blockchain.