CN111161074A - Block chain account balance model construction method supporting sum locking - Google Patents
Block chain account balance model construction method supporting sum locking Download PDFInfo
- Publication number
- CN111161074A CN111161074A CN201911411951.7A CN201911411951A CN111161074A CN 111161074 A CN111161074 A CN 111161074A CN 201911411951 A CN201911411951 A CN 201911411951A CN 111161074 A CN111161074 A CN 111161074A
- Authority
- CN
- China
- Prior art keywords
- account
- transaction
- locking
- balance model
- account balance
- 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
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
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
Abstract
The invention discloses a block chain account balance model construction method supporting sum locking, which is characterized in that a main framework of the block chain account balance model is an NULS account balance model based on an Etheng, and the construction method comprises the steps of taking a hash value as a nonce value of each transaction in the account balance model; a locking mechanism to increase the available balance of the account. The invention improves the working efficiency, the account uniqueness and the data stability and the user experience.
Description
Technical Field
The invention relates to the technical field of blockchain, in particular to a method for constructing a blockchain account balance model supporting sum locking.
Background
The account book, as the core of accounting, has ancient history with writing, currency. The breakthrough of computing power and cryptography, as well as the discovery and use of some new interesting algorithms, has allowed the creation of distributed ledgers. In its simplest form, a distributed ledger is a database that is maintained and updated independently by each participant (or node) in a large network. The distribution is unique: records are not communicated with the various nodes through a central authority, but are constructed and maintained independently by each node, that is, each node on the network processes each transaction, reaches its own conclusions, and then votes on those conclusions to determine that most people agree to those conclusions. Once consensus is achieved, the distributed ledger is updated and all nodes keep their own ledger copies. This architecture allows flexibility as a recording system, not just a simple database.
At present, account book models in block chain networks are mature, and the mainstream account book models include two types, one is a UTXO (unified transform and adjustment) account book model of bitcoin, and the other is an etherhouse account balance model.
For the UTXO book model, i.e., in the blockchain of bitcoins, each transaction costs one or several transaction inputs, which are used as a source of funds; one or more transaction outputs are generated and this is the funds go, which is the "unspent transaction output", i.e., the UTXO. Essentially, the UTXO model is in a flow book. The UTXO is characterized in that the total value of the input of each transaction is equal to or greater than the total value of the output, the newly generated UTXO of the transaction can become the input (fund source) of the next transaction, each UTXO can be used only once and is used up after being used, the repeated use (namely the double flower problem) is prevented, and the method is similar to the mode of using paper money to pay for change in a real life scene. For example, as shown in FIG. 1, a guest uses two 100 denominations of banknotes to purchase a 180 dollar worth of merchandise, after the guest pays 200 dollars, 180 dollars to the merchant, the merchant makes change for two 10 dollar banknotes, and then the guest purchases a 15 dollar worth of merchandise with 20 dollars, and finally makes change for 5 dollars. Therefore, it is easy to see that each UTXO is completely stored, and the model generates a large amount of data, which causes waste of resources for storage and network broadcasting; the UTXO does not automatically summarize and requires an additional program to record the total balance of each account at any time; if a plurality of UTXOs are involved in a transaction, the transaction needs to be signed respectively, all related UTXOs need to be traversed during inquiry, and whether spent verification and signature verification are carried out for each change during verification, so that the efficiency is low.
For the Etherhouse account balance model, to prevent transactions from being repeated, Etherhouse requires that each transaction of the account must have a nonce value. As shown in fig. 2, the nonce value is incremented from 0, 1 is added to the nonce value for each transaction sent, and the latter transaction with a larger nonce value is processed only after the processing of the transaction with a smaller nonce value is completed; the account will refuse processing when a transaction is received that is lower than the current user nonce value. Compared with the UTXO model, the account balance model has more advantages in flexibility and programmability; similar to the traditional account balance model (bank, Payment treasures, etc.), there is a fixed account, and the balance of the account is changed every time the account is transferred in and out. The problem of concurrency and double flowers is solved by adopting a self-growing nonce value, but an account model of an etherhouse does not support locking of available balance, and the expandability of an account book for actual business requirements is reduced. In view of the foregoing, there is a need in the art for an account balance model that addresses the above-mentioned problems.
Disclosure of Invention
The invention aims to provide a block chain account balance model construction method supporting sum locking, which improves the working efficiency, improves the account uniqueness and data stability and improves the user experience.
The technical scheme adopted by the invention for solving the technical problems is as follows: a block chain account balance model construction method supporting sum locking is characterized in that a main framework of the block chain account balance model construction method is an NULS account balance model based on an Ether house, and the construction method comprises the steps of taking a hash value as a nonce value of each transaction in the account balance model; a locking mechanism to increase the available balance of the account.
Preferably, when the account actively initiates a new transaction, the valid nonce value of the current account is queried first, the nonce value is assigned to the roll-out of the transaction, and the transaction is broadcast to other p2p nodes.
Preferably, when new transactions sent by other p2p nodes are received and verified, if a nonce value corresponding to the account in the transaction roll-out is found to repeatedly appear, the verification is not passed; if the nonce value is not used and is not the latest valid nonce value of the account, the transaction is put into a cache to be processed, and other transactions are continuously processed until the nonce value can be verified, and then verification is performed.
Preferably, for each account of NULS, the initial nonce value is 80 s of the hexadecimal value.
Preferably, the locking mechanism comprises locking of time and traffic.
Preferably, the time is locked as the limit on the time range of the account transaction, that is, when the transferred lockTime is greater than 0, the account can be unlocked for use only after the time for transferring the transaction amount to the real world is greater than the fixed time defined by the lockTime.
Preferably, the service locking comprises completing a locking of an account available balance by delegating a consensus transaction.
The invention has the beneficial effects that:
1. compared with the UTXO account book model, each UTXO in the UTXO account book model can be completely stored, so that a large amount of data is generated, and the resource waste of storage and network broadcasting is caused;
2. compared with the UTXO account book model, the UTXO account book model cannot automatically summarize the transaction data of the account book, an assembler is additionally added to record the total balance of each account in real time, development and operation cost is increased, the method adopts the Ethenhouse account balance model as a basic structure, has a summarization framework, can finish real-time summarization and deployment by correspondingly editing the Ethenhouse account balance model, and has stronger editability;
3. compared with the UTXO account book model, in the account transaction, if the UTXO transaction is involved, the UTXO transaction needs to be signed respectively, all related UTXOs need to be traversed during query, and whether spent verification and signature verification are needed to be carried out on each change during verification, so that the efficiency is low;
4. compared with an Ether house account balance model, the hash value is used as the nonce value, double flowers are automatically prevented from being generated, meanwhile, the problem that the account cannot support the locking of the available balance is solved by adding a locking mechanism of the available balance of the account, the expandability of the account book for actual business requirements is enhanced, the account balance model is improved, and the operation and maintenance cost is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the present invention will be further described with reference to the accompanying drawings and embodiments, wherein the drawings in the following description are only part of the embodiments of the present invention, and for those skilled in the art, other drawings can be obtained without inventive efforts according to the accompanying drawings:
fig. 1 is a schematic diagram of a UTXO circulation process in a transaction according to the background of the present invention;
FIG. 2 is a schematic diagram of an Etherhouse transaction flow in the background of the invention;
FIG. 3 is a diagram illustrating a transaction process in which a hash value is used as a nonce value in an embodiment of the present invention;
FIG. 4 is a schematic diagram of time locking in an embodiment of the present invention;
fig. 5 is a schematic diagram of service locking in the embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention, and it is obvious that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without inventive step, are within the scope of the present invention.
In embodiment 1, as shown in fig. 3, a method for constructing a blockchain account balance model supporting monetary locking, a main framework of which is an etherhouse-based NULS account balance model, is characterized in that the method includes using a hash value as a nonce value of each transaction in the account balance model; a locking mechanism to increase the available balance of the account.
Specifically, in the NULS account balance model based on etherhouses, a user has accounts, each etherhouse account corresponds to one address, and the account model is consistent with a real account model in reality, such as a bank account. In the application model, two account addresses are provided, one is an external account address which is an account matched with a public key and a private key owned by a common user, namely the account address which is commonly used by people and used for storing tokens of the user; the other is a contract account address, which refers to an account address of an intelligent contract. In the account, 4 states including Nonce, balance, storageRoot and codeHash need to be maintained, wherein Nonce, the external account is the transaction times, and the contract account is the created contract serial number; balance, the Ethernet balance of this address; the Storageroot is used for storing the hash value of the root of the Mercker tree consisting of contents; codeHash, hash value of account EVM code; the contract account is the hash value of the contract code, and the external account is the hash value of the empty character string. The account balance model of the NULS is based on an account balance model of an Ethern, and has a fixed account main body, and the account balance can be updated along with the change of the amount after each transaction.
Further, when the account actively initiates a new transaction, firstly, the valid nonce value of the current account is inquired, the nonce value is assigned to the roll-out of the transaction, and the transaction is broadcasted to other p2p nodes.
Further, when new transactions sent by other p2p nodes are received and verified, if a nonce value corresponding to the account in the transaction roll-out is found to repeatedly appear, the verification is not passed; if the nonce value is not used and is not the latest valid nonce value of the account, the transaction is put into a cache to be processed, and other transactions are continuously processed until the nonce value can be verified, and then verification is performed.
Further, for each account of NULS, the initial nonce value is 80 s of the hexadecimal value. I.e. 8 groups 0000.
Specifically, as shown in fig. 3, when the account actively initiates a new transaction, that is, the transfer party of the transaction is the account, first, a valid nonce value of the current account needs to be queried, the nonce value is assigned to the transfer party of the transaction, and the transaction is broadcasted to other p2p nodes. After the transaction is finally packaged and confirmed by the blocks, the system changes the balance of the account at the bottom layer, and meanwhile, the last 8 bits of the new transaction hash value are used as the latest effective nonce value of the user for persistent storage, so that the next time of the account is convenient to inquire and use when the transaction is actively initiated. When new transactions sent by other p2p nodes are received, if the nonce value corresponding to the transaction transfer-in account appears repeatedly during verification, the verification is not passed; if the nonce value is not used and is not the latest valid nonce value of the account, the transaction is put into a cache to be processed, and other transactions are continuously processed until the nonce value can be verified, and then verification is performed.
Further, the locking mechanism includes locking of time and traffic.
Further, the time is locked as the limit on the time range of the account transaction, that is, when the transferred lockTime is greater than 0, the time for transferring the transaction amount to the real world is greater than the fixed time defined by the lockTime, and then the account can be unlocked for use.
Specifically, as shown in FIG. 4, the carry-in of NULS transactions preserves the lockTime attribute of the transaction output in bitcoins. When the load lockTime >0, the amount of money for the new load must be greater than the fixed time defined by the lockTime before the real-world time can be unlocked for use.
After the NULS block chain bottom layer is confirmed in the blocks, when each transfer transaction is processed, if the checktime attribute of the transfer-in of the transaction is larger than 0, the address of the account is used as a key, and the transfer-in is stored persistently in a list mode. When the user inquires the balance, the bottom layer inquires out all records with the lockTime >0 in the user list, the records are compared with the lockTime of each record according to the current time, the lock can be unlocked if the lockTime is less than the current time, the unlocking amount is converted into the available balance, and the corresponding persistent data is deleted. The lockTime is recorded in seconds with a timestamp. Time locking is similar to regular banking at banks, where a user and an account agree on a locking condition in advance at the time of a transaction, and if the user chooses to put an unlock to the account before expiry, a certain token needs to be paid to the center.
Further, the service locking comprises completing locking of an account available balance by delegating a consensus transaction.
Specifically, for business locking, it is similar to an asset pledge. In the account balance model, NULS supports permanent locking of the available balance of the account portion by special transactions, which then resolve the lock by special transactions. Taking the business of sharing consensus by users using NULS as an example, NULS allows all accounts holding NULS tokens to share consensus, and increases the credit value of nodes by delegating their tokens to a fixed consensus node. After the nodes package out blocks, the principal can obtain a certain out-block reward according to the principal amount.
For the entrusted consensus transaction, namely after the user initiates the entrusted consensus transaction, the mortgage amount is always in the lock, and the unlocking can not be successful until the user initiates the cancellation of the entrusted consensus transaction again. In the process of entrusting consensus transaction, the transaction is transferred in and out, and the address and the amount of money need to be consistent; in the roll-out of the transaction, the lockTime attribute needs to be-1, wherein lockTime = -1, which indicates that the consensus locking is achieved. When the underlying system book module processes the transaction, the account balance is changed, the account nonce value is updated by 8 bits after the transaction hash, and the current nonce value is used as a key to persistently store the current locked amount.
For the transaction of canceling the entrusting consensus, when the user wants to cancel the entrusting and does not participate in the consensus any more, the transaction of the entrusting consensus is found out firstly, an unlocking nonce value is obtained by intercepting 8 bits after the hash of the transaction is intercepted, and then the entrusting-consensus canceling transaction is assembled. In the process of canceling entrusted transaction, transaction is transferred out and transferred in, and the address and the amount of money are required to be consistent; the nonce value transferred by the transaction is not the current valid nonce value, but the unlocking nonce value obtained before; the transfer-in of the transaction must have a locked attribute, and the value is-1, wherein locked = -1 represents unlocking; locktime for the transfer in of the transaction = 0. When the underlying system book module processes transaction, the corresponding persistent record can be found according to the nonce value, whether the address is consistent with the amount of money is verified, and unlocking can be achieved after verification is passed. As shown in fig. 5, NULS uses lockTime = -1 to indicate consensus locking, and negative integers of-2, -3, -4, etc. may also be used to distinguish more different services.
It should be noted that the transaction hash is a unique Identifier (ID) obtained by spalling each attribute including time, type, roll-out, roll-in, etc., thereby ensuring the uniqueness of the transaction in the whole block chain; the nonce value is a random number, a continuity certificate of account amount change is adopted in the account balance model of the application, the nonce value of the Etheng is taken as an example, after the first user account transfer, the nonce value is marked as 1, after the second account transfer, the nonce value is marked as 2, and so on; for the transfer-out (from) and transfer-in (to) of a transaction, from can be understood as the transferor of the transaction, i.e. how much money was transferred out, and to can be understood as the recipient of the transaction, i.e. how much money was received in; the address is an account number of the account and has uniqueness in the whole block chain; repeated transactions (double flowers) are that one person transfers 100 dollars of own bank accounts to two different persons at the same time, and the event is unreasonable in real life and occurs in a distributed account book of a block chain, so that serious transaction problems are caused.
Claims (8)
1. A block chain account balance model construction method supporting sum locking is characterized in that a main framework of the block chain account balance model construction method is an NULS account balance model based on an Ether house, and the construction method comprises the steps of taking a hash value as a nonce value of each transaction in the account balance model; a locking mechanism to increase the available balance of the account.
2. The method for constructing the blockchain account balance model supporting monetary locking according to claim 1, wherein when an account actively initiates a new transaction, a valid nonce value of a current account is firstly inquired, a nonce value is assigned to a transfer-out of the transaction, and the transaction is broadcasted to other p2p nodes.
3. The method for constructing the blockchain account balance model supporting sum locking according to claim 1 or 2, wherein when a new transaction sent by other p2p nodes is received and verified, if a nonce value corresponding to an account in the transaction roll-out is found to repeatedly appear, the verification is not passed; if the nonce value is not used and is not the latest valid nonce value of the account, the transaction is put into a cache to be processed, and other transactions are continuously processed until the nonce value can be verified, and then verification is performed.
4. A method of constructing a blockchain account balance model in support of monetary locking according to claim 1 or claim 2 in which each account of NULS has an initial nonce value of 8 0's of a hexadecimal value.
5. A method of constructing a blockchain account balance model in support of monetary locking as claimed in claim 3 wherein each account of NULS has an initial nonce value of 8 0's of a hexadecimal value.
6. The method of building a blockchain account balance model that supports locking of monetary amounts according to claim 1, 2 or 5 wherein the locking mechanism includes locking of time and traffic.
7. The method for constructing a blockchain account balance model supporting sum locking according to claim 6, wherein the time locking is a limit on a time range of account transaction, that is, when the transferred lockTime is greater than 0, the account can be unlocked for use only after the time for transferring the transaction sum to the real world is greater than a fixed time defined by the lockTime.
8. The method of building a blockchain account balance model supporting monetary locking of claim 6 wherein the business locking includes completing a lock-out of an available balance of an account by committing a consensus transaction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911411951.7A CN111161074A (en) | 2019-12-31 | 2019-12-31 | Block chain account balance model construction method supporting sum locking |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911411951.7A CN111161074A (en) | 2019-12-31 | 2019-12-31 | Block chain account balance model construction method supporting sum locking |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111161074A true CN111161074A (en) | 2020-05-15 |
Family
ID=70560077
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911411951.7A Pending CN111161074A (en) | 2019-12-31 | 2019-12-31 | Block chain account balance model construction method supporting sum locking |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111161074A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111401875A (en) * | 2020-05-29 | 2020-07-10 | 支付宝(杭州)信息技术有限公司 | Block chain transfer method and device based on account model |
-
2019
- 2019-12-31 CN CN201911411951.7A patent/CN111161074A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111401875A (en) * | 2020-05-29 | 2020-07-10 | 支付宝(杭州)信息技术有限公司 | Block chain transfer method and device based on account model |
| CN111401875B (en) * | 2020-05-29 | 2020-09-01 | 支付宝(杭州)信息技术有限公司 | Block chain transfer method and device based on account model |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Sunyaev et al. | Distributed ledger technology | |
| US20230029193A1 (en) | System and method for composite cryptographic transactions | |
| US20220292471A1 (en) | Universal tokenisation system for blockchain-based cryptocurrencies | |
| US20220084020A1 (en) | System and method for scaling blockchain networks with secure off-chain payment hubs | |
| JP7128111B2 (en) | Systems and methods for controlling asset-related activities via blockchain | |
| Poon et al. | The bitcoin lightning network: Scalable off-chain instant payments | |
| Poon et al. | The bitcoin lightning network | |
| TW201810150A (en) | Blockchain implemented method and system | |
| JP2020523677A (en) | Method and system for mining blockchain transactions provided by validator nodes | |
| Nick et al. | Liquid: A bitcoin sidechain | |
| EP3736760A1 (en) | Automated transaction protocol linking renewable energy generation assets to energy power consumers applying distributed digital ledger technology and iot energy meters | |
| CN110555684A (en) | Account and system based on block chain system | |
| Pedrosa et al. | Scalable lightning factories for bitcoin | |
| KR101918446B1 (en) | Double-secured Block-chain Certification System and its method | |
| Kamvar et al. | Celo: A multi-asset cryptographic protocol for decentralized social payments | |
| Drąsutis | IOTA smart contracts | |
| CN111161074A (en) | Block chain account balance model construction method supporting sum locking | |
| CN112513907A (en) | Apparatus and method for providing digital asset exchange protocol | |
| Zhang | Research on multiparty payment technology based on blockchain and smart contract mechanism | |
| Van Hee et al. | A new digital currency system | |
| US20230196310A1 (en) | Methods and system for cross-blockchain collateralization | |
| Schoenfeld et al. | Pascal: An infinitely scalable cryptocurrency | |
| Iushkevich et al. | D3ledger: The decentralized digital depository platform for asset management based on hyperledger iroha | |
| JP2003168004A (en) | Method for processing payment, method for processing financing certification and financial institution system | |
| Zilnieks | Choosing a Consensus Mechanism for a Blockchain Based P2P Instant Transaction System Integrated with IoT |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200515 |
|
| RJ01 | Rejection of invention patent application after publication |