Method for determining type of specification of smart contract on blockchain and server for executing same

Abstract

A server for determining the type of specification of a smart contract according to the present invention comprises: a specification database in which a function of a smart contract performing a specific function according to an ERC standard and parameters used in the function are configured and stored as a signature; a byte code signature database in which a signature extracted from a byte code existing on a blockchain is stored; and a specification verification unit that, when receiving a request message for verifying the standard specification of a smart contract from a smart contract user terminal, verifies the specification of the smart contract on the basis of the specification database and the byte code signature database.

Description

Method for determining the type of smart contract specification on a blockchain and the server that executes it.

[0001] The present invention relates to a method for determining the type of specification of a smart contract in a blockchain and a device for executing the same, and more specifically, to a method for determining the type of specification of a smart contract in a blockchain and a server for executing the same, which enables interoperability with other services that comply with the specifications by confirming which specifications the source code of the smart contract complies with.

[0002] The ERC (Ethereum Request for Comments) standard for smart contracts was developed to support a variety of use cases on the Ethereum blockchain, including token issuance and management and digital asset exchange. This standard helps developers implement interoperable smart contracts and is contributing significantly to the development of the blockchain ecosystem.

[0003] The advent of blockchain technology has given rise to the concept of smart contracts. Smart contracts are automated contracts implemented in code, with signatures that automatically execute when conditions are met.

[0004] Initially, smart contracts were implemented in various forms and deployed on blockchains. However, this diversity created interoperability issues, necessitating a standard, which led to the emergence of the ERC standard.

[0005] The ERC standard aims to ensure interoperability by standardizing smart contracts that perform specific functions. For example, ERC-20 defines a standard for token issuance and exchange, and ERC-721 is a standard for managing ownership of unique digital assets.

[0006] The ERC standard has evolved through the participation and contributions of the developer community. The diverse opinions and suggestions gathered have enhanced the standard's completeness and contributed to the growth of the blockchain ecosystem.

[0007] However, smart contracts are written in a high-level language (e.g., Solidity), and this code is compiled into binary assembly code and stored. Because smart contracts stored on the blockchain (100) are assembly code, there is a problem in that it is impossible to specify the specification (e.g., ERC-20, ERC-721, ERC-1155).

[0008] Korean Patent Publication No. 10-2022-0012867 relates to a method and device for implementing identity-based key management using a smart contract, and includes a step of executing a smart contract to execute a key management process, wherein the key management process, when a key of a target user needs to be updated, if the target user is an unsupervised user, generates a master public key and a master private key belonging to the target user, acquires identity information of the target user from a blockchain, and generates a first target private key based on the master public key and the master private key belonging to the target user and the identity information of the target user, and replaces the current private key of the target user with the first target private key. However, a solution for solving the above problem is not disclosed.

[0009] The purpose of the present invention is to provide a method for determining the type of specification of a smart contract in a blockchain, which can confirm what specification the source code of a smart contract follows, and a server for executing the method, which can interoperate with other services that comply with the specification.

[0010] In addition, the present invention aims to provide a method for determining the type of specification of a smart contract and a server for executing the method, which can be expected to comply with the security principles defined by the specification by confirming that the smart contract complies with a specific specification.

[0011] In addition, the present invention aims to provide a method for determining the type of specification of a smart contract and a server for executing the method, which can help developers solve problems and provide support by enabling interaction with a developer community that understands and supports the specification by confirming that the smart contract follows a specific specification.

[0012] To achieve this purpose, a server for determining the type of specification of a smart contract includes a specification database in which a function of a smart contract performing a specific function and a parameter used in the function are configured and stored as a signature for each ERC standard, a byte code signature database in which a signature extracted from a byte code existing on a blockchain is stored, and a specification verification unit that verifies the specification of the smart contract based on the specification database and the byte code signature database when receiving a request message for verifying the standard specification of the smart contract from a smart contract user terminal.

[0013] In one embodiment, the specification verification unit can extract the address, function, and parameters used in the function of the smart contract from the standard specification verification request message of the smart contract, extract the byte code of the smart contract from the blockchain using the address of the smart contract, and extract the signature corresponding to the byte code from the byte code signature database.

[0014] In one embodiment, the specification verification unit can check which ERC standard a smart contract follows by matching a signature extracted from the byte code signature database with a signature stored in the specification database.

[0015] In addition, a method for determining the specification type of a smart contract executed on a smart contract specification type determination server for achieving this purpose may include a step of constructing a specification database in which a function of a smart contract performing a specific function by ERC standard and a parameter used in the function are configured as a signature, a step of constructing a byte code signature database in which a signature extracted from a byte code existing on a blockchain is stored, and a step of confirming the specification of the smart contract based on the specification database and the byte code signature database when a request message for confirming the standard specification of the smart contract is received from a smart contract user terminal.

[0016] In one embodiment, the step of verifying the specification of the smart contract based on the specification database and the byte code signature database includes the step of extracting the address of the smart contract from a standard specification verification request message of the smart contract;

[0017] The method may include a step of extracting the byte code of the smart contract from a blockchain using the address of the smart contract and a step of extracting a signature corresponding to the byte code from the byte code signature database.

[0018] In one embodiment, the step of verifying the specification of the smart contract based on the specification database and the byte code signature database may include a step of verifying which ERC standard the smart contract follows by matching a signature extracted from the byte code signature database with a signature stored in the specification database.

[0019] According to the present invention as described above, the present invention has the advantage of being able to check whether the source code of a smart contract complies with a certain specification, thereby enabling interoperability with other services that comply with the specification.

[0020] Additionally, the present invention has the advantage of being able to expect that a smart contract will comply with the security principles defined by a specific specification by verifying that the smart contract complies with the specific specification.

[0021] Additionally, the present invention has the advantage of enabling developers to interact with a developer community that understands and supports a specific specification by verifying that the smart contract complies with that specification, thereby helping developers troubleshoot issues and provide support.

[0022] FIG. 1 is a diagram for explaining a system for determining the type of specifications of a smart contract in a blockchain according to one embodiment of the present invention.

[0023] FIG. 2 is a block diagram illustrating the internal structure of a smart contract specification type determination server according to one embodiment of the present invention.

[0024] Figure 3 is a flowchart illustrating an embodiment of a method for determining the type of specification of a smart contract according to the present invention.

[0025] Figure 4 is an exemplary diagram for explaining the specifications of a smart contract according to one embodiment of the present invention.

[0026]

[0027] <Explanation of symbols>

[0028] 100: Blockchain

[0029] 200: Smart Contract Developer Terminal

[0030] 300: Smart Contract User Terminal

[0031] 400: Server that determines the type of smart contract specification

[0032] 410: Spec Database

[0033] 420: Bytecode Signature Database

[0034] 430: Specification Verification Section

[0035] The above-described objects, signatures, and advantages will be described in detail below with reference to the attached drawings, so that those skilled in the art can easily practice the technical idea of ​​the present invention. In describing the present invention, if it is determined that a detailed description of known technologies related to the present invention may unnecessarily obscure the gist of the present invention, a detailed description thereof will be omitted. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. In the drawings, the same reference numerals are used to indicate the same or similar components.

[0036]

[0037] FIG. 1 is a diagram for explaining a system for determining the type of specifications of a smart contract in a blockchain according to one embodiment of the present invention.

[0038] Referring to FIG. 1, a system for determining the specification type of a smart contract in a blockchain includes a blockchain (100), a smart contract developer terminal (200), a smart contract user terminal (300), and a smart contract specification type determination server (400).

[0039] A smart contract developed by a smart contract developer terminal (200) is stored in the blockchain (100). At this time, during the process of storing the smart contract in the blockchain (100), the source code of the smart contract is compiled, converted into byte code, and stored.

[0040] The blockchain (100) verifies transactions received from users or external systems. At this time, the call to the smart contract included in the transaction is verified, just like a regular transaction. This process verifies whether the transaction signature is valid and whether the required funds are sufficient.

[0041] Additionally, when a verified transaction is included in a block, the blockchain (100) executes the smart contract included in the transaction. During this process, the smart contract's functions are called and the necessary logic is executed. For example, a smart contract may process a remittance or store data.

[0042] Additionally, the blockchain (100) changes its state as a result of the execution of a smart contract. This means that the smart contract performs tasks such as updating data or generating new events. Events are stored on the blockchain and can be retrieved or used later.

[0043] Additionally, when the execution of a smart contract is completed, the blockchain (100) includes the transaction in a block and adds it to the blockchain. To this end, miners create a new block and add the new block, including the verified transaction, to the blockchain.

[0044] A smart contract developer terminal (200) is a terminal owned by a developer who develops and distributes a program for a smart contract.

[0045] The smart contract developer terminal (200) analyzes and designs the requirements for a smart contract to be developed according to the ERC standard. That is, it selects a token standard, such as ERC-20 or ERC-721, and determines the functions and structure of the smart contract according to the requirements defined in the standard.

[0046] Afterwards, the smart contract developer terminal (200) develops a smart contract in a language such as Solidity, based on the selected ERC standard. The smart contract must implement functions such as token issuance, transfer, and ownership management. At this time, the code is written to comply with the requirements defined in the ERC standard.

[0047] As described above, the smart contract developer terminal (200) selects a blockchain network to deploy before deploying the smart contract.

[0048] In one embodiment, the smart contract developer terminal (200) selects either the Mainnet or the Testnet. The Mainnet is the actual Ethereum blockchain, and the Testnet is a network that developers can use for testing.

[0049] The smart contract developer terminal (200) executes the written deployment script to deploy the smart contract to the selected network. During this process, the smart contract is deployed to nodes on the network and recorded on the blockchain (100).

[0050] A smart contract user terminal (300) is a terminal owned by a user who executes a smart contract and receives the results.

[0051] The smart contract user terminal (300) executes and then distributes the smart contract. To this end, the smart contract user terminal (300) creates and signs a transaction that distributes the smart contract to the blockchain (100).

[0052] This transaction is the process of uploading the contract's source code and initial state to the blockchain (100). As described above, when the smart contract user terminal (300) completes deployment of the smart contract to the blockchain network, a unique address is generated on the blockchain (100).

[0053] Afterwards, the smart contract user terminal (300) must obtain the address from the blockchain (100) after the smart contract is deployed on the blockchain (100). Accordingly, the smart contract user terminal (300) can interact with the smart contract using this address.

[0054] To interact with a smart contract, a smart contract user terminal (300) must create, sign, and transmit a blockchain transaction. This transaction calls a smart contract function and transmits the parameters required for that function.

[0055] At this time, the functions and parameters of a smart contract may vary depending on the tasks and functions the smart contract will perform. For example, smart contract functions may include read-only functions, state-changing functions, event functions, and initialization functions.

[0056] Read-only functions read data from the blockchain without modifying the state of the smart contract. These functions are primarily used to query the status of a contract or return specific information. For example, a function might query a specific user's balance.

[0057] State-changing functions are functions that change the state of a smart contract. These functions are executed by creating a transaction on the blockchain, which changes the state of the contract. For example, a function might transfer tokens to a specific user.

[0058] Event functions log events occurring in a smart contract. These functions are used to notify external parties of changes in the contract's status. For example, there might be a function that generates a related event when a specific action occurs.

[0059] The initialization function initializes a smart contract. It is typically executed only once when the smart contract is deployed. There may be a function that sets the initial token supply.

[0060] Afterwards, when a transaction is processed on the blockchain network, the smart contract user terminal (300) executes the corresponding smart contract function. The function performs tasks using the passed parameters and can change the smart contract's status as needed.

[0061] When a smart contract user terminal (300) completes function execution, the value or status change returned by the function is recorded on the blockchain. This information can be confirmed as a transaction result.

[0062] The above smart contract is written in a high-level language (e.g., Solidity), and this code is compiled into binary assembly code and stored.

[0063] As described above, since the smart contract stored in the blockchain (100) is an assembly code, it is not possible to specify what specification (ERC-20, ERC-721, ERC-1155, etc.) it is.

[0064] The smart contract user terminal (300) receives all information existing on the blockchain (100). At this time, among the information collected on the blockchain (100), the smart contract is in assembly code, so its specifications are unknown.

[0065] In order to specify the ERC (Ethereum Request for Comments) standard of a smart contract, a smart contract user terminal (300) must analyze the address, function, and parameters used in the function of the smart contract to determine which ERC standard it follows.

[0066] The ERC standard consists of a set of rules and specifications, primarily applicable when smart contracts issue or manage tokens. The ERC standard typically defines functions and events, which perform specific actions and use specific parameters. The process of specifying an ERC standard can be as follows:

[0067] The smart contract user terminal (300) verifies the address where the smart contract is deployed. The smart contract address is a unique identifier for the contract deployed on the blockchain network.

[0068] Afterwards, the smart contract user terminal (300) analyzes the functions contained in the smart contract. These functions primarily define the tasks the smart contract can perform. In particular, it checks whether there are functions that provide token-related functionality. For example, there may be a function such as "transfer(address to, uint256 amount)."

[0069] The smart contract user terminal (300) verifies the parameters used by each function. According to the ERC standard, specific functions use specific parameters. These parameters may include the recipient address and transfer amount when transferring tokens.

[0070] The smart contract user terminal (300) compares the analyzed information with the ERC standard. The ERC standard defines specific functions and events. Accordingly, the smart contract user terminal (300) verifies that the smart contract's functions and parameters match those defined in the ERC standard.

[0071] Let's explain the process of determining the ERC standard for a general smart contract. A smart contract is expected to have a transfer function. This function is primarily used to transfer tokens to a specific address. The transfer function described above typically takes two parameters.

[0072] The first parameter is the address of the destination to which the tokens will be transferred, and the second parameter is the amount of tokens to transfer. These two parameters are defined as an address type and an integer type.

[0073] For example, parameters can be defined in the form of transfer(address to, uint256 amount), where to is the address of the destination to be transferred, and amount is the amount of tokens to be transferred.

[0074] The smart contract user terminal (300) must examine the source code of the smart contract being analyzed and determine how the transfer function is defined. In other words, the smart contract user terminal (300) must find the function definition in the source code and determine the format in which the parameters are used.

[0075] To this end, the smart contract user terminal (300) may provide a standard specification confirmation request message of the smart contract including the address, function, and parameters used in the function of the smart contract to the smart contract specification type determination server (400), and receive the specification of the smart contract from the smart contract specification type determination server (400).

[0076] As described above, the smart contract user terminal (300) has the advantage of being able to expect that the smart contract will comply with the security principles defined by the specifications by confirming that the smart contract complies with specific specifications.

[0077] When the smart contract specification type determination server (400) receives a standard specification confirmation request message of a smart contract from a smart contract user terminal (300), it extracts the address, function, and parameters used in the function of the smart contract from the standard specification confirmation request message of the smart contract, and analyzes the address, function, and parameters used in the function of the smart contract based on the specification database (410) and the byte code signature database (420) to determine which ERC standard it follows.

[0078] At this time, in the specification database (410), the function of a smart contract that performs a specific function according to the ERC standard and the parameters used in the function are stored as a signature, and in the byte code signature database (420), a signature extracted from the byte code existing on the blockchain is stored.

[0079] Accordingly, the smart contract specification type determination server (400) extracts the byte code of the smart contract from the blockchain (100) using the address of the smart contract. This byte code represents the code by which the smart contract is actually executed.

[0080] After that, the smart contract specification type determination server (400) extracts a signature corresponding to the byte code from the byte code signature database (420) and compares it with the signature stored in the specification database (410) to determine which ERC standard the smart contract follows.

[0081]

[0082] FIG. 2 is a block diagram illustrating the internal structure of a smart contract specification type determination server according to one embodiment of the present invention.

[0083] Referring to FIG. 2, the smart contract specification type determination server (400) includes a specification database (410), a byte code signature database (420), and a specification verification unit (430).

[0084] In the specification database (410), the functions of smart contracts that perform specific functions according to the ERC standard and the parameters used in the functions are stored in the form of signatures.

[0085] The ERC standard primarily defines the functions and parameters used by smart contracts to perform specific functions. These functions and parameters have unique signatures, which allow them to be identified and called.

[0086] For example, the transfer function and its parameters defined in the ERC-20 standard could have a signature like “transfer(address to, uint256 amount).”

[0087] Here, a function signature is created by combining the function name and parameter types. This signature is used to uniquely identify the function and is extracted from the smart contract's bytecode when calling the function. Thus, functions and parameters defined in the ERC standard are composed of signatures, which allow for the identification and interaction of smart contracts that adhere to a specific standard.

[0088] The bytecode signature database (420) stores signatures extracted from bytecodes existing on the blockchain. These signatures extracted from bytecodes primarily relate to functions or events in smart contracts and are used to identify and call the corresponding functions or events.

[0089] The byte code signature database (420) stores function signatures, event signatures, constructor signatures, external call function signatures, and token standard signatures.

[0090] A function signature is created by combining the function's name and the types of its parameters. A function signature is used to uniquely identify a function and allows you to call the function defined in a smart contract.

[0091] An event signature is created by combining the event name and the parameter types. Event signatures are used to detect and handle specific events when they occur.

[0092] A constructor signature is a special function that is executed only once when a smart contract is deployed and is used to identify and call the constructor.

[0093] External call function signatures are the signatures of functions used to interact with other smart contracts or external services.

[0094] Token standard signatures are the signatures of functions defined in token standards, such as ERC-20 and ERC-721. These signatures are used to identify smart contracts that comply with a specific token standard.

[0095] The signatures stored in the bytecode signature database (420) above are extracted from each bytecode and used to identify and invoke functions and events in smart contracts. This allows for the development of various applications that interact with smart contracts on the blockchain.

[0096] When the specification verification unit (430) receives a standard specification verification request message of a smart contract from a smart contract user terminal (300), it extracts the address of the smart contract from the standard specification verification request message of the smart contract, analyzes the address of the smart contract based on the specification database (410) and the byte code signature database (420), and verifies which ERC standard it follows.

[0097] First, the specification verification unit (430) extracts the byte code of the smart contract from the blockchain (100) using the address of the smart contract. This byte code represents the code by which the smart contract is actually executed.

[0098] After that, the specification verification unit (430) extracts a signature corresponding to the byte code from the byte code signature database (420) and compares it with the signature stored in the specification database (410) to check which ERC standard the smart contract follows.

[0099] As described above, the specification verification unit (430) can verify which ERC standard the smart contract follows and then provide a response message to the smart contract user terminal (300) for the standard specification verification request message of the smart contract.

[0100] Therefore, the smart contract user terminal (300) has the advantage of being able to expect that the smart contract will comply with the security principles defined by the specification by confirming that the smart contract follows a specific specification.

[0101]

[0102] Figure 3 is a flowchart illustrating an embodiment of a method for determining the type of specification of a smart contract according to the present invention.

[0103] Referring to FIG. 3, the smart contract specification type determination server (400) builds a specification database in which a function of a smart contract that performs a specific function according to the ERC standard and a parameter used in the function are configured as a signature (step S310).

[0104] The ERC standard primarily defines the functions and parameters used by smart contracts to perform specific functions. These functions and parameters have unique signatures, which allow them to be identified and called.

[0105] The smart contract specification type determination server (400) builds a byte code signature database (step S320) that stores signatures extracted from byte codes existing on the blockchain. These byte code signatures primarily relate to smart contract functions or events, and are used to identify and invoke the corresponding functions or events.

[0106] When the smart contract specification type determination server (400) receives a standard specification confirmation request message of a smart contract from a smart contract user terminal, it confirms the specification of the smart contract based on the specification database and the byte code signature database (step S330).

[0107] In one embodiment of step S330, the smart contract specification type determination server (400) can extract the address of the smart contract from the standard specification confirmation request message of the smart contract, extract the byte code of the corresponding smart contract from the blockchain using the address of the smart contract, and extract the signature corresponding to the byte code from the byte code signature database.

[0108] In another embodiment for step S330, the smart contract specification type determination server (400) can check which ERC standard the smart contract follows by matching the signature extracted from the byte code signature database with the signature stored in the specification database.

[0109]

[0110] Figure 4 is an exemplary diagram for explaining the specifications of a smart contract according to one embodiment of the present invention.

[0111] Referring to Figure 4, among the smart contract specifications, ERC 721 and ERC 165 have a structure similar to Figure 4. The functions of the standard ERC 721 primarily perform functions such as token issuance, transfer, and ownership management, and the parameters required for this are defined.

[0112] For example, approve(address to, uint256 tokenId) is a function that grants another address the owner's rights to a specific token. Another example is setApprovalForAll(address operator, bool approved) , which sets the approval status of all tokens for a specific address.

[0113]

[0114] Although the present invention has been described with reference to the above-described embodiments and drawings, it is not limited to the above-described embodiments. Those skilled in the art will appreciate that various modifications and variations are possible based on this disclosure. Therefore, the scope of the present invention should be understood solely by the scope of the claims set forth below, and all equivalent or equivalent modifications thereof are deemed to fall within the scope of the present invention.

[0115] The present invention is a technology that can be widely used in the blockchain industry to realize practical and economic value by verifying whether the source code of a smart contract in a blockchain follows a certain specification and enabling interoperability with other services that comply with the specification.

Claims

1. A specification database in which the functions of smart contracts that perform specific functions according to the ERC standard and the parameters used in the functions are stored in the form of signatures; A bytecode signature database that stores signatures extracted from bytecodes existing on the blockchain; and When a standard specification verification request message of a smart contract is received from a smart contract user terminal, it is characterized by including a specification verification unit that verifies the specification of the smart contract based on the specification database and the byte code signature database. A server that determines the type of specifications for smart contracts on the blockchain.

2. In paragraph 1, The above specification confirmation section A method characterized in that the address of a smart contract is extracted from a standard specification verification request message of a smart contract, the byte code of the smart contract is extracted from a blockchain using the address of the smart contract, and a signature corresponding to the byte code is extracted from the byte code signature database. A server that determines the type of specifications for smart contracts on the blockchain.

3. In paragraph 2, The above specification confirmation section It is characterized in that it checks which ERC standard a smart contract follows by matching the signature extracted from the byte code signature database with the signature stored in the specification database. A server that determines the type of specifications for smart contracts on the blockchain.

4. In the method for determining the type of specification of a smart contract executed on a server, A step of building a specification database in which the functions of a smart contract that perform a specific function according to the ERC standard and the parameters used in the functions are composed of signatures; A step of constructing a byte code signature database in which signatures extracted from byte codes existing on a blockchain are stored; A method for verifying a standard specification of a smart contract, comprising: receiving a request message for verifying a standard specification of a smart contract from a smart contract user terminal; and verifying the specification of the smart contract based on the specification database and the byte code signature database. How to determine the type of specification of a smart contract on a blockchain.

5. In paragraph 4, The step of verifying the specifications of the smart contract based on the above specification database and the byte code signature database A step of extracting the address of a smart contract from a standard specification verification request message of the above smart contract; A step of extracting the byte code of the smart contract from the blockchain using the address of the smart contract; and characterized in that it comprises a step of extracting a signature corresponding to the byte code from the byte code signature database. How to determine the type of specification of a smart contract on a blockchain.

6. In paragraph 4, The step of verifying the specifications of the smart contract based on the above specification database and the byte code signature database characterized in that it includes a step of checking which ERC standard the smart contract follows by matching the signature extracted from the byte code signature database with the signature stored in the specification database. How to determine the type of specification of a smart contract on a blockchain.

Images