KR102671062B1 - Method and system for secret transaction - Google Patents

Abstract

Disclose a method and system for secure transactions. A transaction method according to an embodiment includes at least one of a hidden security transaction for transfer from a public balance to a secure balance, a public security transaction for transfer from a security balance to a public balance, and a security transaction for transfer between security balances. A step of generating a zero-knowledge proof-based proof to prove that you know the information that is not disclosed about at least one transaction, a step of requesting a transaction containing the zero-knowledge proof-based proof to the blockchain network. And it may include steps to prove the transaction. Here, in blockchain, an account for transactions between public balances and a UTXO (Unspent Transaction Output) model that uses a security balance can coexist.

Description

{METHOD AND SYSTEM FOR SECRET TRANSACTION}

The description below relates to methods and systems for secure transactions.

Central Bank Digital Currency (CBDC) is an electronic form of currency issued by the central bank. CBDC implementation methods include a single ledger method in which the central bank or banks store and manage CBDC accounts and related transaction information, and multiple It can be classified as a distributed ledger method in which transaction participants manage the same transaction records.

[Prior document number]

Korean Patent No. 10-1862637

It provides a trading method and system that can hide all or specific transactions in a specific account.

A method of trading on a computer device comprising at least one processor, comprising, by said at least one processor, a hidden security transaction for a transfer from a public balance to a secure balance, a public security transaction for a transfer from a secure balance to a public balance; and creating at least one transaction of a security transaction for transfer between security balances; Generating, by the at least one processor, zero-knowledge proof-based evidence to prove that the at least one transaction is known to the public; requesting, by the at least one processor, a transaction including the zero-knowledge proof-based proof to a blockchain network; and verifying the transaction by the at least one processor.

According to one side, the public balance may be recorded in a public note stored as public information on the blockchain, and the secure balance may be recorded in a secure note encrypted and stored on the blockchain.

According to another aspect, the hidden secure transaction is encrypted and kept private in the secure note in which the recipient's account receives the remittance, and the step of generating the zero-knowledge proof-based evidence involves knowing the encrypted information in the secure note that receives the remittance. It may be characterized by generating evidence that proves.

According to another aspect, the step of verifying the transaction includes creating a note recording the recipient account, the transaction amount of the hidden security transaction, and a random seed; Encrypting the generated note with the recipient's encryption key to create a secure note; And it may be characterized by including a step of checking whether the note hash obtained by hashing the generated secure note is the same as the note hash of the secure note receiving the remittance.

According to another aspect, the signature of the hidden security transaction, the existence and use of the note hash of the secure note receiving the transfer, and the zero-knowledge proof-based proof are each verified by the verifier of the blockchain network. It can be characterized.

According to another aspect, upon successful completion of verification by the verifier, a public note with information of the public balance to be converted is created in the blockchain network, and the remittance is received in the created public note. The note hash of the newly created secure note may be recorded, and the transaction amount may be deducted from the sender's public balance.

According to another aspect, in the public security transaction, if the sender's account is private and the security balance of the first security note making the transfer remains after the transfer of the transaction amount according to the public security transaction, the remaining security balance A second security note is created for, and the step of generating zero-knowledge proof-based evidence includes: the first security note is owned by the sender, and the balance of the first security note is greater than or equal to the transaction amount of the public security transaction. It may be characterized by generating evidence proving recognition, and further generating evidence proving that the encrypted information of the second secure note is known when the second secure note is created.

According to another aspect, verifying the transaction includes verifying whether the security balance of the first security note is greater than or equal to the transaction amount; verifying whether the first secure note belongs to the sender; verifying the validity of the first secure note; Verifying the validity of a second security note created when the security balance of the first security note is greater than the transaction amount; Verifying whether the security balance of the second security note is the difference between the security balance of the first security note and the transaction amount; Verifying whether the second secure note belongs to the sender; and verifying whether the signature of the public security transaction is the sender's signature.

According to another aspect, the existence and use of the first security note, the existence of the second security note, and the zero-knowledge proof-based evidence are each verified by the verifier of the blockchain network. can do.

According to another aspect, upon successful completion of verification by the verifier, in the blockchain network, the first secure note is registered as a note used in a nullifier of the first secure note, When the second secure note is created, the note hash of the second secure note is recorded in the nullifier, the recipient's public note for the public balance is created, and the recipient's public balance is the transaction amount of the public security transaction. It can be characterized as increasing by as much as.

According to another aspect, in the secure transaction, the sender's account, the recipient's account, and the transaction amount are kept private, and in the step of generating the zero-knowledge proof-based evidence, the first secure note for remittance according to the secure transaction is the sender's owned, evidence proving that the sum of the balance of the first security note and the sum of the balance of the second security note newly created through the security transaction are the same, proof that the first security note and the second security note are valid It may be characterized by generating evidence that proves that the signature of the secure transaction is the sender's signature.

According to another aspect, verifying the transaction includes verifying whether the first security note and the second security note are valid; Verifying whether the sum of the security balances of the first security note and the sum of the security balances of the second security note are the same; Verifying whether all of the first secure notes belong to the sender; verifying whether the second secure note belongs to at least one recipient; and verifying whether the signature of the secure transaction is the sender's signature.

According to another aspect, the existence and use of the first security note, the existence of the second security note, and the zero-knowledge proof-based evidence are each verified by the verifier of the blockchain network. can do.

According to another aspect, upon successful completion of verification by the verifier, in the blockchain network, the first secure note is registered as a note used in a nullifier of the first secure note, When the second secure note is created, the note hash of the second secure note may be recorded in the nullifier.

According to another aspect, the transaction method includes sharing, by the at least one processor, the recipient's encryption key and the recipient's account through off-chain before creating the at least one transaction. More may be included.

A computer program stored on a computer-readable recording medium is provided in conjunction with a computer device to execute the method on the computer device.

Provided is a computer-readable recording medium on which a program for executing the above method on a computer device is recorded.

At least one processor configured to execute instructions readable by a computer device, said at least one processor to perform a hidden security transaction for a transfer from a public balance to a secure balance, a transfer from a secure balance to a public balance; Generate at least one transaction among a public security transaction and a security transaction for transfer between security balances, and generate zero-knowledge proof-based evidence to prove that you know non-public information about the at least one transaction, A computer device is provided that requests a transaction including the zero-knowledge proof-based evidence to a blockchain network and proves the transaction.

You can hide all or specific transactions from a specific account.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention.
Figures 3 and 4 are diagrams showing an example of the structure of a UTXO according to an embodiment of the present invention.
Figure 5 is a diagram illustrating an example of a hidden security transaction according to an embodiment of the present invention.
Figure 6 is a diagram illustrating an example of a public security transaction according to an embodiment of the present invention.
Figures 7 and 8 are diagrams showing an example of a secure transaction according to an embodiment of the present invention.
Figure 9 is a flowchart showing an example of a transaction method according to an embodiment of the present invention.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

The trading system according to embodiments of the present invention may be implemented by at least one computer device. At this time, the computer program according to an embodiment of the present invention may be installed and driven in the computer device, and the computer device may perform the transaction method according to the embodiments of the present invention under the control of the driven computer program. The above-described computer program can be combined with a computer device and stored in a computer-readable recording medium to execute the transaction method on the computer.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. The network environment in FIG. 1 shows an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170. Figure 1 is an example for explaining the invention, and the number of electronic devices or servers is not limited as in Figure 1. In addition, the network environment in FIG. 1 only explains one example of environments applicable to the present embodiments, and the environment applicable to the present embodiments is not limited to the network environment in FIG. 1.

The plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smart phones, mobile phones, navigation devices, computers, laptops, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), tablet PC, etc. For example, in FIG. 1, the shape of a smartphone is shown as an example of the electronic device 110. However, in embodiments of the present invention, the electronic device 110 actually communicates with other devices through the network 170 using a wireless or wired communication method. It may refer to one of various physical computer devices capable of communicating with electronic devices 120, 130, 140 and/or servers 150, 160.

The communication method is not limited, and may include not only a communication method utilizing a communication network that the network 170 may include (for example, a mobile communication network, wired Internet, wireless Internet, and a broadcast network), but also short-range wireless communication between devices. For example, the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). , may include one or more arbitrary networks such as the Internet. Additionally, the network 170 may include any one or more of network topologies including a bus network, star network, ring network, mesh network, star-bus network, tree or hierarchical network, etc. Not limited.

Each of the servers 150 and 160 is a computer device or a plurality of computers that communicate with a plurality of electronic devices 110, 120, 130, 140 and a network 170 to provide commands, codes, files, content, services, etc. It can be implemented with devices. For example, the server 150 provides services (e.g., transaction (e.g., remittance) service, payment service, virtual service) to a plurality of electronic devices (110, 120, 130, and 140) connected through the network 170. Exchange service, risk monitoring service, instant messaging service, game service, group call service (or voice conference service), messaging service, mail service, social network service, map service, translation service, financial service, search service, content provision service, etc. ) may be a system that provides.

Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention. Each of the plurality of electronic devices 110, 120, 130, and 140 described above or each of the servers 150 and 160 may be implemented by the computer device 200 shown in FIG. 2.

As shown in FIG. 2, this computer device 200 may include a memory 210, a processor 220, a communication interface 230, and an input/output interface 240. The memory 210 is a computer-readable recording medium and may include a non-permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive. Here, non-perishable large-capacity recording devices such as ROM and disk drives may be included in the computer device 200 as a separate permanent storage device that is distinct from the memory 210. Additionally, an operating system and at least one program code may be stored in the memory 210. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210. Such separate computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, and memory cards. In another embodiment, software components may be loaded into the memory 210 through the communication interface 230 rather than a computer-readable recording medium. For example, software components may be loaded into memory 210 of computer device 200 based on computer programs installed by files received over network 170.

The processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, processor 220 may be configured to execute received instructions according to program code stored in a recording device such as memory 210.

The communication interface 230 may provide a function for the computer device 200 to communicate with other devices (eg, the storage devices described above) through the network 170. For example, a request, command, data, file, etc. generated by the processor 220 of the computer device 200 according to a program code stored in a recording device such as memory 210 is transmitted to the network ( 170) and can be transmitted to other devices. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. Signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or memory 210, and files, etc. may be stored in a storage medium (as described above) that the computer device 200 may further include. It can be stored as a permanent storage device).

The input/output interface 240 may be a means for interfacing with the input/output device 250. For example, input devices may include devices such as a microphone, keyboard, or mouse, and output devices may include devices such as displays and speakers. As another example, the input/output interface 240 may be a means for interfacing with a device that integrates input and output functions, such as a touch screen. At least one of the input/output devices 250 may be configured as one device with the computer device 200. For example, like a smart phone, a touch screen, microphone, speaker, etc. may be included in the computer device 200.

Additionally, in other embodiments, computer device 200 may include fewer or more components than those of FIG. 2 . However, there is no need to clearly show most prior art components. For example, the computer device 200 may be implemented to include at least some of the input/output devices 250 described above, or may further include other components such as a transceiver, a database, etc.

The transaction method and transaction system according to embodiments of the present invention uses zero-knowledge proof (ZKP) in relation to transactions using central bank digital currency (CBDC), You can hide all transactions or specific transactions. Here, hiding the transaction may mean processing the transaction with at least one of the sender (sender), the recipient (receiver), and the transaction amount kept private.

In cryptography, a zero-knowledge proof refers to an interactive procedure in which when someone proves to the other party that a statement is true, nothing is revealed except whether the statement is true or false. The person who tries to prove that a statement is true is called a prover, and the person who participates in the proof process and exchanges information with the prover is called a verifier. When parties participating in a zero-knowledge proof arbitrarily change the protocol for the purpose of deceiving the other party, the parties are said to be dishonest or cheating. In other cases, it is said to be honest. A zero-knowledge proof must satisfy the following three properties:

- Completeness: If a statement is true, an honest prover must be able to convince an honest verifier of this fact.

- Soundness: If a statement is false, no dishonest prover should be able to convince an honest verifier that this statement is true.

- Zero-knowledgeness: If a sentence is true, the verifier should not know anything other than the truth or falsity of the sentence.

The transaction method and transaction system according to embodiments of the present invention can hide all transactions or specific transactions of a specific account using such zero-knowledge proof.

The transaction method and transaction system according to embodiments of the present invention are account-based and can enable both public and private transactions to be carried out in one blockchain, with the advantages of account-based and UTXO (Unspent Transaction Output)-based. You can have all the advantages. Ethereum has a structure that allows anyone to participate in the DApp (Decentralized application) network as long as they are connected to the Internet, and has the advantage of being able to use smart contracts. Ethereum uses an account balance model. Here, the account may be an object that constitutes the state of Ethereum. Meanwhile, unlike Ethereum, Bitcoin has the advantage of security and anonymity by validating transactions and confirming the existence of coins based on UTXO.

The transaction method and transaction system according to embodiments of the present invention adds the UTXO model to the basic account model and uses the account model for public transactions and the UTXO model for secure transactions. During secure transactions, the sender, recipient, and transaction amount can all be hidden. For this purpose, the zcash method can be applied to the UTXO model. At this time, the balance can be divided into a public balance (public balance) and a secure balance (secure balance). The public balance is an account model that is public information that allows the owner's balance to be confirmed, while the secure balance is a balance that only the owner can know and is a UTXO model. One account may have both a public balance and a secure balance, or an account may be configured to use only one of the public balance and secure balance methods. When a transfer is made from a public balance to a secure balance, the public balance is burned for the amount of the transfer and a security balance is issued for the amount of the transfer. Conversely, when a transfer is made from a secure balance to a public balance, the security balance is burned for the amount of the transfer, and the public balance is issued for the amount of the transfer. When the public balance and the secure balance are interchanged, the total monetary volume of the public balance and the total monetary volume of the secure balance change, but the total monetary volume does not change. Information on the issuance and burning of public balances and security balances can be recorded and tracked as public notes.

Figures 3 and 4 are diagrams showing an example of the structure of a UTXO according to an embodiment of the present invention. In the UTXO model, notes can be stored by encrypting the note's owner information (owner address) and balance (balance) with the owner's encryption key (encryptKey). Figure 3 shows a first note 310 of the owner address "A address", a second note 320 of the owner address "B address", and a third note 330 of the owner address "C address". At this time, in FIG. 3, the part where the owner information "A address" and the balance "1000" of the first note 310 are encrypted and stored are expressed as an encrypted body (encryptBody([]byte)). Information encrypted and stored in the encrypted body of the note may include the owner address, the value of the balance, and a random hash value (or a random seed (RandomSeed) to be described later), but Figure 3 The illustration of the random hash value is omitted.

Additionally, the number (block height) of the block in which this note is confirmed to be created can be included in the public note and used to record whether or not the UTXO is executed. These block numbers will be explained in more detail later.

A note's commitments may be a list of hashes of previous notes from which it was derived. When hashes are gathered from multiple notes, there may be two or more hashes, in which case the sum of the values contained in the hashes must equal the current note balance. If a previous note is split, there may be one commitment, and if a note is created from scratch, such as through a block creation reward or coin minting, an empty commitment or zero hash may be recorded. You can. In Figure 4, an example is shown in which the fifth note 420 of the owner address "E address" is created by the third note 330 of the owner address "C address" and the fourth note 410 of the owner address "D address". It is showing. At this time, the commitment of the fifth note 420 may include the hash of the third note 330 and the hash of the fourth note 410, and the hash included in the commitment of the fifth note 420 may include the hash of the third note 330 and the hash of the fourth note 410. The sum of the values (1000+500=1500) must be equal to the balance (1500) of the fifth note (420).

When other notes are created by using that note, hashes of the derived notes can be added to the nullifiers of the note. A single nullifier can be set when only ownership changes or when several other notes are combined into one note. If the balance of the current note is split, multiple nullifiers may be added. At this time, the sum of the balances of all notes corresponding to the nullifier must be equal to the balance of the current note. If the nullifier is null, you can use it for trading with notes that have not yet been spent. If it is burned or the security balance is converted to a public balance, a zero hash may be input. Figure 4 shows an example in which the 5th note 420 of the owner address "E address" is divided into the 6th note 430 of the owner address "F address" and the 7th note 430 of the owner address "G address". there is. At this time, the hash of the sixth note 430 and the hash of the seventh note 430 derived from the fifth note 420 may be added to the nullifier of the fifth note 420. In this case as well, the sum of the hash values (1200+300=1500) included in the nullifier of the fifth note 420 must be equal to the balance (1500) of the fifth note 420.

Since there is a public balance and a secure balance in the embodiments of the present invention, notes in this UTXO structure can also be classified into public notes and secure notes in the embodiments of the present invention.

A secure note is a structure containing information about the actual owner and value (e.g., balance), and an encrypted binary can be stored on the blockchain. Secure notes can be encrypted and decrypted with an encryption key for encryption and decryption. A key different from the signing key may be used as the encryption key. Secure notes can be encrypted with an encryption key and registered with Nullifier. The encrypted content may include the owner address, the balance value, and a random seed selected as a random value used to prevent the content from being inferred when encrypting the note.

A public note is a structure containing information about the owner and the public balance issued or burned, and can be stored as public information on the chain. Public notes can be created when the public balance is burned when a new security note is issued, or when the public balance is generated by the burning of a security note. Content included in the public note may include owner address, balance value, block number, and transaction index. The block number is the height of the block in which the public note is created and can be used to record information on the block in which the public note was created and to prevent identical public notes from being created. Additionally, the transaction index can be used to distinguish each transaction in a block to distinguish cases where the same owner creates the same balance in the same block.

Note hashes can also be divided into secure note hashes and public note hashes.

The secure note hash can be generated by hashing the value that encrypted the secure note, such as secret note hash = s + hash(encrypt(secret note)). These note hashes can be created as a hash of the encrypted data to prevent tampering with the security note and encrypted data created by the ZKP prover. Since the block number cannot be known unless the block is confirmed, it is not used when creating a secure note hash. To distinguish it from a public note hash, an "s" can be added to the front of the secure note hash as a separator.

A public note hash can be created when updating changed state information after verification is completed in the blockchain, such as public note has = p + hash(owner address, value, block height, transaction index). To distinguish a public note hash from a secure note hash, "p" may be added to the front of the public note hash as a separator.

The values recorded in the block may include transaction information and the verification result (verification success or verification failure) of ZKP's proof.

Each transaction can be composed of the following APIs: HideSecretTransaction, PublicSecretTransaction, and SecretTransction. Here, a hidden security transaction may refer to a transaction that transfers money from a public balance to a secure balance, a public security transaction may refer to a transaction that transfers money from a security balance to a public balance, and a secure transaction may refer to a transaction that transfers money from a security balance to a security balance. can do.

In the case of hidden and public security transactions, the amount and information to be converted cannot be hidden because the disclosed information of the public balance must be changed. For example, a hidden secure transaction can hide the recipient's information, but cannot hide the sender's information and the transaction amount, and an open secure transaction can hide the sender's information, but cannot hide the recipient's information and the transaction amount. . However, in the case of secure transactions, the sender, receiver, and transaction amount can all be hidden.

First of all, a public transaction may include information such as the following (1) to (7).

(1) from: Sender account (or address sending transaction, signing entity, sender)

(2) to: Recipient's account (or address to receive remittance)

(3) value: transaction amount (remittance amount)

(4) vin: List of utxo notes (in_note) to be remitted

- note_hash: note hash

(5) vout: List of utxo notes (out_note) to be remitted

- note_encrypt_data: Encrypted data of the note

- note_encrypt_key: Key that encrypted the note (since it is public information, it can be applied as a one-time address for anonymity)

- note_hash: note hash

(6) proof: ZKP proof of hidden information

(7) signature: Signature of the sender of the transaction

Figure 5 is a diagram illustrating an example of a hidden security transaction according to an embodiment of the present invention. 5 shows the owner address, balance value, and random seed in a public note 510 including the owner address, balance value, block number (block height), and transaction index. ) shows an example of a remittance to a secure note 520 containing. In this case, the owner address included in the public note 510 may be the sender's address, and the owner address included in the secure note 520 may be the address of the recipient. Additionally, the balance of the public note 510 may mean a public balance, and the balance of the secure note 520 may mean a secure balance. The secure note 520 derived from the public note 510 may store the note hash of the previous note, the public note 510, in a commitment. At this time, because the previous note is a public note 510, a distinction value of “p” may be given in front of the note hash.

Here, the hidden security transaction may refer to a transaction transferring money from a public balance to a secure balance, as already described. In other words, a hidden secure transaction could be the function of transferring money from the sender's public balance to someone else's secure balance.

In a hidden secure transaction, the sender's account (account) and transaction amount (value) are disclosed, but the recipient's account (account) and the converted UTXO note can be kept private. Since the amount of the new UTXO note owned by the recipient's account can be inferred from the amount of the transfer, the amount of the newly created UTXO note can be prevented from being inferred by including the UTXO note of the security balance held when sending the transfer.

A hidden security transaction may include proof that the utxo note of the newly created security balance with ZKP is hidden as the transaction value, proof that the owner owns the amount and creates a recipient's note. Since the newly created security note is a value converted from the public balance, it can be composed of a newly issued note with UTXO, and the public balance can be burned by the amount of the transaction amount. Therefore, the circulating amount of the entire public balance can be burned equal to the transaction amount.

The information required for hidden secure transactions is as follows.

(1) from: sender’s account

(2) to: hidden

(3) value: Transaction amount (amount of open balance being transferred)

(4) vin: hidden

(5) vout: 1 or more newly created utxo notes

(6) proof: ZKP evidence proving that vout's utxo note is owned by a specific user and corresponds to the transaction amount

(7) signature: Signature of the sender of the transaction

Meanwhile, for a hidden secure transaction, the sender must request and share the recipient's encryption key and information about the recipient's account off-chain with the recipient before creating the transaction and proving it with ZKP.

Additionally, the information that the sender must prove with ZKP for a hidden secure transaction is as follows.

- Proof that you know the encrypted information of the newly created utxo note

- zkp input: out_note(owner address, value, randomSeed), AES_secret_key, out_note_encryptKey, out_note_hash, where out_note can be hidden.

The proof is as follows.

- Create UTXO note with owner address, transaction amount and random seed

- Create an encrypted note by encrypting out_note with the recipient's encryption key.

- You can check whether the hash (encryptNote) of the encrypted data is the same as utxo_hash.

Meanwhile, to verify the transaction, the verifier can first verify the transaction's signature and check the existence and use of utxo_hash. Afterwards, the verifier can verify the proof of ownership of the utxo through ZKP proof verification.

In blockchain, you can create a public note with public balance information (transaction amount) that is converted when verification is successfully completed, add the state and a new utxo note to the state, and deduct the transaction amount from the sender's public balance.

Figure 6 is a diagram illustrating an example of a public security transaction according to an embodiment of the present invention. Figure 6 shows the transition from a secure note 610 containing the owner address, balance value (A value), and random seed to a public note 620 containing the owner address, balance value (B value), block number, and transaction index. This shows an example of remittance. At this time, if the balance value (A value) of the security note 610 is greater than the B value corresponding to the transaction amount, a new security note 630 with the (A-B) value may be created. If the balance value (A value) of the security note 610 is less than the B value corresponding to the transaction amount, the transaction will not be made, and the balance value (A value) of the security note 610 is equal to the transaction amount. If the corresponding B value is the same, the transaction will be made, but a new security note 630 will not be created.

Here, since the public note 620 derived from the secure note 610 has no commitment, there is no space to store the note hash of the previous note, the secure note 610. At this time, a note hash (p + public note hash) may be assigned to the public note 620, and the note hash (p + note hash) of the public note 620 may be recorded in the nullifier of the secure note 610. You can. As already explained, the separator value "p" can be used to indicate that the note hash is a note hash of a public note. If a new security note 630 is created by a public security transaction, a note hash (s + note hash) may be assigned to the security note 630. At this time, the note hash of the secure note 630 may be recorded in the nullifier of the secure note 610. Additionally, the note hash of the security note 610 may be recorded in the commitment of the security note 630. As already described, the separator value "s" can be used to indicate that the note hash is a note hash of a secure note. In this way, in the commitment of one secure note, the note hash of the previous note may be recorded as a point to point to the previous note, and the note hash of the next note may be recorded in the nullifier as a point to point to the next note. . In this way, security notes can be cross-referenced like a linked list through note hashes recorded in commitments and nullifiers.

In this case, the owner address included in the secure note 610 may be the sender's address, and the owner address included in the public note 620 may be the address of the recipient.

At this time, the public security transaction may mean a transaction that transfers money from the secure balance to the public balance, as already described. In other words, a public secure transaction could be the function of transferring money from the sender's secure balance to someone else's public balance.

In a public secure transaction, the recipient's account and transaction amount are disclosed, but the sender's account is not disclosed. For public security transactions, ZKP must be used to prove that the sender is the owner of the corresponding utxo note, that there is no problem with the transaction amount, and that if the security balance is greater than the transaction amount, the newly created utxo note is valid with the balance minus the transaction amount.

The information required for public security transactions is as follows.

(1) from: hidden

(2) to: recipient account

(3) value: Amount of open balance to be transferred

(4) vin: utxo note hash owned by the sender

(5) vout: 1 or more newly created utxo notes

- The first UTXO note is burned immediately, converting to the public balance of the UTXO note to be burned belonging to the recipient.

(6) proof: zkp proof that vin is owned by the sender, vout is owned by a specific user, the amount of vin is equal to the sum of the amount of vout and the remittance amount, and the signature proves that the sender created the public security transaction.

(7) signature: hidden

Meanwhile, for a public secure transaction, the sender must request and share information about the recipient's account off-chain with the recipient before creating the transaction and proving it with ZKP.

Additionally, the information that the sender must prove with ZKP for a public security transaction is as follows.

- Prove that the vin security note belongs to the sender and that it is more than the transaction amount, and if there is a balance after the transfer, prove that you know the encrypted information of the newly created utxo note.

- The signature proves that the public security transaction was created by the sender.

- zkp input: in_note(owner address, value, randomSeed), in_note_AES_secret_key, in_note_encryptKey, in_note_hash, out_note(owner address, value, randomSeed), out_note_AES_secret_key, out_note_encryptKey, out_note_hash, value, sender's public key (sender_pk), sender's signature ( signature), transaction hash (tx_hash), where in_note(), out_note(), the sender's public key, and the sender's signature can be hidden.

The proof is as follows.

- Verify that the amount in in_note is greater than or equal to the transaction amount

- Verify that in_note is owned by the sender

- Validation of in_note: Verify that the hash generated after encrypting the note with a public encryption key is the note hash (note_hash).

- Validation of out_note: Verify that the hash generated after encrypting the note with a public encryption key is the note hash (note_hash).

- Verify that out_note is the difference between the transaction amount in in_note

- Verify that out_note is owned by the sender

- Verify that the signature of the transaction is the sender’s signature

Meanwhile, the verifier can verify the existence and use of in_note (in_note must exist and not be used). Additionally, the verifier can verify the existence of out_note (it should not exist). Additionally, the verifier can verify the evidence of the sending ZKP.

In blockchain, when verification is successfully completed, in_note can be added by registering a nullifier as a used note, adding a new out_note, and creating a public note of public balance. Additionally, in blockchain, the recipient's public balance can be increased by the transaction amount.

Figures 7 and 8 are diagrams showing an example of a secure transaction according to an embodiment of the present invention. A security transaction may refer to a transaction that transfers money from a security balance to a security balance, as already explained. In a secure transaction, the remittance account (sender's address), the receiving account (recipient's address), and the transaction amount may not all be disclosed.

In a secure transaction, it must be possible to verify the validity and owner of UTXO notes sent to ZKP, the amount sent, and the validity of newly created UTXO notes according to the amount sent, and verification of the signature that signed all of this information is also hidden. You may have to do it.

In a secure transaction, a transfer may be made from multiple secured notes to one secured note, or from one secured note to multiple secured notes. Figure 7 shows an example of a transfer being made from n security notes 710 to one security note 720, and Figure 8 shows a transfer from one security note 810 to several security notes 820 and 830. This shows an example of a remittance being made. In FIG. 7, one security note 720 may store the note hash of each of the previous notes 710 in a commitment, and in FIG. 8, each of several security notes 820 and 830 may store one security note 810. ) note hashes can be stored in each commitment.

The information required for secure transactions is as follows.

(1) from: hidden

(2) to: hidden

(3) value: hidden

(4) vin: Secure note hash owned by the sender

(5) vout: 1 or more newly created security notes

(6) proof: ZKP proof that the transaction amount has been transferred from a security note owned by the sender of vin to a security note of vout and a signature proving that the transaction was created by the sender.

(7) signature: hidden

Meanwhile, for a secure transaction, the sender must request and share the recipient's encryption key and information about the recipient's account off-chain with the recipient before creating the transaction and proving it with ZKP.

Additionally, the information that the sender must prove with ZKP for a secure transaction is as follows.

- Prove that vin's security note belongs to the sender and that the sum (sum of amount) is the same as the newly created security note

- Prove that each secure note is valid

- Proof that the signature of the relevant remittance transaction is the sender's signature

- zkp input: in_note(owner, value, randomSeed) list, in_note_AES_secret_key list, in_note_encryptKey list, in_note_hash list, out_note(owner, value, randomSeed) list, out_note_AES secret key list, out_note_encryptKey list, out_note_hash list, transaction amount (value), Sender's public key (sender_pk), sender's signature (signature), transaction hash (tx_hash), where in_note list, out_note list, transaction amount, sender's public key, and sender's signature can be hidden.

The proof is as follows.

- Verify that both in_note and out_note are valid: Verify that the hash generated after encrypting the note with the public encryption key is the note hash (note_hash).

- Verify that the sum of all amounts in in_note is the same as the sum of all amounts in out_note

- Verify that all in_notes are owned by the sender

- Verify that out_note is owned by the recipients: There can be a maximum of 2 recipients.

- Verify that the signature of the transaction is the sender’s signature

Meanwhile, the verifier can verify the existence and use of in_note (in_note must exist and not be used). Additionally, the verifier can verify the existence of out_note (it should not exist). Additionally, the verifier can verify the evidence of the sending ZKP.

In blockchain, when verification is successfully completed, in_note can register a nullifier as a used note and add a new out_note.

In the blockchain, the value of a note can be searched using the note hash.

Proof key pk and verification key vk can be generated by setup for each API of hidden security transaction (HideSecretTransaction), public secret transaction (PublicSecretTransaction), and secret transaction (SecretTransction). The generated verification key pk can be delivered to the prover, and the generated verification key vk can be delivered to the verifiers. Verifiers can process proofs for each API.

Figure 9 is a flowchart showing an example of a transaction method according to an embodiment of the present invention. The transaction method according to this embodiment can be performed by a computer device 200 that implements a sender terminal that transmits money. At this time, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system included in the memory 210 or the code of at least one computer program. Here, the processor 220 causes the computer device 200 to perform steps 910 to 950 included in the method of FIG. 9 according to control instructions provided by code stored in the computer device 200. can be controlled.

In step 910, the computer device 200 may share the recipient's encryption key and the recipient's account through off-chain. Here, off-chain may refer to a network other than the blockchain network where transactions will be processed.

At step 920, computer device 200 executes at least one of: a hidden security transaction for transfers from a public balance to a secure balance, a public security transaction for transfers from a secure balance to a public balance, and a secure transaction for transfers between secure balances. You can create one transaction. At this time, the public balance can be recorded in a public note that is stored as public information on the blockchain, and the secure balance can be recorded in a secure note that is encrypted and stored on the blockchain. As already explained, in addition to the public balance, the owner's address, block number, and transaction index may be additionally recorded in the public note, and in the secure note, the owner's address and random seed may be additionally recorded in addition to the security balance.

In step 930, the computer device 200 may generate zero-knowledge proof-based evidence to prove that it knows non-public information about at least one transaction.

Hidden Secure Transactions can be kept private by encrypting the recipient's account in a secure note receiving the transfer. In this case, the computer device 200 may generate evidence proving that it knows the encrypted information of the secure note receiving the remittance at step 930. At this time, the owner information of the security note receiving the remittance may be the recipient's account, and the security balance of the security note newly created by the hidden security transaction may be the transaction amount of the hidden security transaction. In other words, in a hidden secure transaction, the recipient account and the secure note receiving the transfer according to the recipient account are not disclosed, but a private transaction can be made by proving that the sender knows the encrypted information (owner information and transaction amount) of these secure notes. .

For public secure transactions, the sender's account may be private. On the other hand, when transferring from a security balance to a public balance, if the security balance is more than the transaction amount, that is, if the security balance of the first security note making the transfer remains after the transfer of the transaction amount according to the public security transaction, the remaining security balance is A second security note may be created for security balance. In this case, computer device 200 provides evidence at step 930 proving that the first secure note is owned by the sender and that the balance (remaining security balance) of the first secure note is greater than or equal to the transaction amount of the public security transaction. can be created. If a second secure note is created, evidence proving that the user knows the encrypted information of the created second secure note can be further generated. The owner information of the second security note will be the sender's own address, and since the security balance of the second security note is the remainder minus the transaction amount from the security balance of the first security note, the sender uses the encrypted information of this second security note. Accordingly, the sender can generate evidence proving that he or she knows the encrypted information of the second secure note based on zero-knowledge proof.

In secure transactions, the sender's account, recipient's account, and transaction amount can be kept private. In this case, the computer device 200 determines in step 930 that the first security note making the transfer according to the security transaction is owned by the sender, the sum of the balance of the first security note and the second security note newly created through the security transaction. Evidence proving that the sum of the note balances is the same, evidence proving that the first security note and the second security note are valid, and evidence proving that the signature of the security transaction is the sender's signature can be generated.

In step 940, the computer device 200 may request a transaction including zero-knowledge proof-based evidence from the blockchain network. Here, in the blockchain network, the UTXO (Unspent Transaction Output) model for transactions using security balances (for example, hidden security transactions, public security transactions, and security transactions) and the account model for transactions between public balances can be used together.

At this time, in the case of a hidden security transaction, the signature of the hidden security transaction, the existence and use of the note hash of the security note receiving the remittance, and zero-knowledge proof-based evidence can each be verified by the verifier of the blockchain network. At this time, as the verification by the verifier is successfully completed, a public note with information on the public balance converted in the blockchain network is created, and the note hash of the newly created security note to receive the remittance is added to the created public note. By recording and deducting the transaction amount from the sender's public balance, the hidden secure transaction can be processed through the blockchain network.

In the case of a public security transaction, the existence and use of the first security note, the existence of the second security note, and zero-knowledge proof-based evidence can each be verified by the verifier of the blockchain network. At this time, as verification by the verifier is successfully completed, the first security note is registered in the blockchain network as a note used to nullify the first security note, and a second security note is created. , the note hash of the second secure note is recorded in the nullifier, the recipient's public note for the public balance is created, and the recipient's public balance is increased by the transaction amount of the public security transaction, thereby allowing the public security transaction to use the blockchain network. It can be processed through

In the case of a secure transaction, the existence and use of the first security note, the existence of the second security note, and zero-knowledge proof-based evidence can be verified by the verifier of the blockchain network, respectively. At this time, as verification by the verifier is successfully completed, the first security note is registered in the blockchain network as a note used to nullify the first security note, and a second security note is created. , the note hash of the second secure note is recorded in Nullifier, allowing the corresponding secure transaction to be processed through the blockchain network.

At step 950, computer device 200 may verify the transaction.

In the case of a hidden security transaction, the computer device 200 can create a note recording the recipient's account, the transaction amount and random seed of the hidden security transaction, and encrypt the created security note with the recipient's encryption key to create a security note. You can. These security notes will be identical to the security notes of UTXO created following hidden security transactions. Accordingly, the computer device 200 can prove the transaction by checking whether the note hash obtained by hashing the generated secure note is the same as the note hash of the secure note receiving the remittance.

For an open secure transaction, computer device 200 verifies that the security balance of the first secure note is greater than or equal to the transaction amount, verifies that the first secure note belongs to the sender, verifies the validity of the first secure note, and , Verify the validity of the second security note created when the security balance of the first security note is greater than the transaction amount, and verify whether the security balance of the second security note is the difference between the security balance of the first security note and the transaction amount. , the transaction can be proven by verifying that the second secure note belongs to the sender and verifying that the signature of the public security transaction is the sender's signature.

In the case of a secure transaction, the computer device 200 verifies whether the first security note and the second security note are valid, verifies whether the sum of the security balance of the first security note and the sum of the security balance of the second security note are equal, The transaction can be verified by verifying that all first secure notes are owned by the sender, verifying that the second secure note is owned by at least one recipient, and verifying that the signature of the secure transaction is the sender's signature.

As such, according to embodiments of the present invention, all transactions or specific transactions (for example, transactions related to Central Bank Digital Currency (CBDC)) of a specific account can be hidden.

The system or device described above may be implemented with hardware components or a combination of hardware components and software components. For example, devices and components described in embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), etc. , may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include a plurality of processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. It can be embodied in . Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. The medium may continuously store a computer-executable program, or may temporarily store it for execution or download. In addition, the medium may be a variety of recording or storage means in the form of a single or several pieces of hardware combined. It is not limited to a medium directly connected to a computer system and may be distributed over a network. Examples of media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, And there may be something configured to store program instructions, including ROM, RAM, flash memory, etc. Additionally, examples of other media include recording or storage media managed by app stores that distribute applications, sites or servers that supply or distribute various other software, etc. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the following claims.

Claims (20)

In a method of trading a computer device including at least one processor,
At least one transaction, by the at least one processor, of a hidden security transaction for transfers from a public balance to a secure balance, a public security transaction for transfers from a secure balance to a public balance, and a security transaction for transfers between security balances. generating a;
Generating, by the at least one processor, zero-knowledge proof-based evidence to prove that the sender of the at least one transaction knows information that is kept private about the at least one transaction - the kept information is sent to the recipient Contains at least one of the following: account, sender's account, secure note receiving the transfer, and transaction amount -;
requesting, by the at least one processor, a transaction including the zero-knowledge proof-based proof to a blockchain network; and
verifying the transaction, by the at least one processor.
Transaction methods including. According to paragraph 1,
The public balance is recorded in a public note that is stored as public information on the blockchain.
The security balance is recorded in a secure note that is encrypted and stored on the blockchain.
A trading method characterized by . According to paragraph 1,
A transaction method characterized in that the blockchain network uses a UTXO (Unspent Transaction Output) model for the at least one transaction and an account model for transactions between public balances. According to paragraph 1,
In the above hidden secure transaction, the recipient's account and the security note receiving the remittance are kept private,
The step of generating evidence based on the zero-knowledge proof is,
Generating evidence proving that you know the encrypted information of the secure note receiving the transfer.
A trading method characterized by . According to paragraph 4,
The steps to prove the transaction are:
creating a note recording the recipient account, a transaction amount of the hidden security transaction, and a random seed;
Encrypting the generated secure note with the recipient's encryption key to create a secure note; and
Checking whether the note hash obtained by hashing the generated secure note is the same as the note hash of the secure note receiving the remittance.
A transaction method comprising: According to clause 4,
A transaction method characterized in that the signature of the hidden security transaction, the existence and use of a note hash of the security note receiving the transfer, and the zero-knowledge proof-based evidence are each verified by a verifier of the blockchain network. According to clause 6,
Upon successful completion of verification by the verifier, in the blockchain network,
A public note containing information about the public balance being converted is created,
The note hash of the newly created secure note for receiving the remittance is recorded in the created public note,
The transaction amount is deducted from the sender's public balance.
A trading method characterized by . According to paragraph 1,
In the above public secure transaction, the sender's account is private,
If the security balance of the first security note making the transfer remains after remittance of the transaction amount according to the public security transaction, a second security note is created for the remaining security balance,
The step of generating evidence based on the zero-knowledge proof is,
Generate evidence proving that the first security note is owned by the sender and that the balance of the first security note is greater than or equal to the transaction amount of the public security transaction, but when the second security note is created, the second security note is generated. Generating further evidence proving that you know the note's encrypted information
A trading method characterized by . According to clause 8,
The steps to prove the transaction are:
Verifying whether the security balance of the first security note is greater than or equal to the transaction amount;
verifying whether the first secure note belongs to the sender;
verifying the validity of the first secure note;
Verifying the validity of a second security note created when the security balance of the first security note is greater than the transaction amount;
Verifying whether the security balance of the second security note is the difference between the security balance of the first security note and the transaction amount;
Verifying whether the second secure note belongs to the sender; and
Verifying that the signature of the public security transaction is the sender's signature
A transaction method comprising: According to clause 8,
A transaction method characterized in that the existence and use of the first security note, the existence of the second security note, and the zero-knowledge proof-based evidence are each verified by a verifier of the blockchain network. According to clause 10,
Upon successful completion of verification by the verifier, in the blockchain network,
The first secure note is registered as a note used to nullify the first secure note,
When the second secure note is created, the note hash of the second secure note is recorded in the nullifier,
A recipient's public note for public balance is created,
The recipient's public balance is increased by the transaction amount of the public security transaction.
A trading method characterized by . According to paragraph 1,
In the above secure transaction, the sender's account, recipient's account, and transaction amount are kept private.
The step of generating evidence based on the zero-knowledge proof is,
Evidence proving that the first security note making the transfer according to the security transaction is owned by the sender, and that the sum of the balance of the first security note and the balance of the second security note newly created through the security transaction are the same, Generating evidence proving that the first security note and the second security note are valid and evidence proving that the signature of the secure transaction is the sender's signature.
A trading method characterized by . According to clause 12,
The steps to prove the transaction are:
Verifying whether the first security note and the second security note are valid;
Verifying whether the sum of the security balances of the first security note and the sum of the security balances of the second security note are the same;
Verifying whether all of the first secure notes belong to the sender;
verifying whether the second secure note belongs to at least one recipient; and
Verifying whether the signature of the secure transaction is the sender's signature
A transaction method comprising: According to clause 12,
A transaction method characterized in that the existence and use of the first security note, the existence of the second security note, and the zero-knowledge proof-based evidence are each verified by a verifier of the blockchain network. According to clause 14,
Upon successful completion of verification by the verifier, in the blockchain network,
The first secure note is registered as a note used to nullify the first secure note,
When the second secure note is created, the note hash of the second secure note is recorded in the nullifier.
A trading method characterized by . According to paragraph 1,
sharing, by the at least one processor, the recipient's encryption key and recipient account via off-chain prior to generating the at least one transaction.
Transaction method further comprising: A computer program stored in a computer-readable recording medium in combination with a computer device to cause the computer device to execute the method of any one of claims 1 to 16. A computer-readable recording medium recording a computer program for executing the method of any one of claims 1 to 16 on a computer device. At least one processor implemented to execute readable instructions in a computer device
Including,
By the at least one processor,
Create at least one transaction: a hidden security transaction for transfers from a public balance to a secure balance, a public security transaction for transfers from a secure balance to a public balance, and a security transaction for transfers between security balances;
Generate zero-knowledge proof-based evidence to prove that the sender of the at least one transaction knows information that is to be kept private about the at least one transaction, and the kept information is the recipient's account, the sender's account, and the security for receiving the remittance. Contains at least one of the notes and transaction amount -,
Request a transaction containing the zero-knowledge proof-based evidence from the blockchain network,
Proof of said transaction
A computer device characterized by a. According to clause 19,
The public balance is recorded in a public note that is stored as public information on the blockchain.
The security balance is recorded in a secure note that is encrypted and stored on the blockchain.
A computer device characterized by a.

Images