KR20220108358A - Smart Contract Data Feed Framework for Privacy Preserving Oracle System on Blockchain - Google Patents

Abstract

Disclosed is a smart contract feed framework for protecting an oracle system in a blockchain. According to an embodiment of the present invention, a signature system necessary for non-repudiation of a data source necessary to authenticate externally provided data is introduced. A blockchain can authenticate a data source presented by a data owner, and confirm that correct data is verified, based on the signature system. The data owner (verifier) cannot manipulate the data received from the data source in the middle, and an oracle interface which can be written in Solidity is provided to verify a proof including authentication of external data, such that a design for the privacy of a prover can solve a problem which is difficult to be implemented by a smart contract developer. Also, evaluation of the performance and costs for a protocol and a language which can be referred when implementing a proposed framework against costs of proof data generation and smart contract verification implemented in Solidity on Ethereum, and the size of stored data can be provided.

Description

Smart Contract Data Feed Framework for Privacy Preserving Oracle System on Blockchain

The present invention relates to a smart contract feed framework for protecting an oracle system in a block chain, and more particularly, it is a framework composed of middleware of an external source server, a data prover, and a verification contract. It is about a technology that allows the data owner to prove the extracted data with zk-SNARKs and provide a smart contract that can be verified.

Blockchain is used in cryptocurrencies such as Bitcoin, and smart contracts are programs that operate on such block chains and are used to build various decentralized applications such as games, insurance, and finance.

To achieve decentralization, the blockchain validates transactions by consensus (e.g. Bitcoin PoW [4]). The consensus of the blockchain is verified only for the elements that need to be verified by the internal system (e.g. account balance), and the function implemented in the smart contract guarantees the execution of the input data, but does not guarantee the reliability of the data. In particular, when a function that implements a large amount of money transfer is executed through the input data, the result derived from the input data becomes very important. However, the security provided by the blockchain or smart contract does not support authentication of the source of external data or proof of integrity in the inflow process.

Data generated outside the block chain is information that cannot be verified inside the block chain, and it is necessary to secure the trust of the data generated outside the block chain. The smart contract's process is called "Oracle", which serves to provide these external data to the blockchain.

Decentralized finance (De-Fi) is a typical field where oracles can be used. In order to implement the necessary collateral loans and interest products in decentralized finance, it is necessary to stabilize the coin or token, which is the basis of the product. For example, the current Bitcoin price per dollar exchange rate information corresponds to this. Since coin market caps and exchanges exist as representative websites that provide price information per coin, an oracle is required to utilize such information in the block chain.

In blockchain, transactions are basically publicly stored in order to verify and constitute a shared ledger. Although the hash value of the public key address is used to provide pseudonymity, the movement of funds and the total amount of money can be tracked. Transaction disclosure is problematic in systems that require anonymity because it allows prior information to be known through state changes in smart contracts.

The problem of oracles for introducing information from outside the blockchain is emerging. Among the methods to solve the Oracle problem, a method of configuring an Oracle based on TLS (Transport Layer Security), an existing Internet infrastructure, has been proposed. However, currently, these methods have the disadvantage that they do not support privacy protection for external data, and there is a limitation in configuring the process of smart contract based on data to be automated through verification.

Accordingly, the present applicant proposes a method to provide a smart contract that enables the data owner to prove and verify the data extracted from the searched page with zk-SNARKs as a framework consisting of middleware of external source server, data prover, and verification contract would like to propose

Therefore, the present invention is an Oracle system in a blockchain where the data owner can prove and verify the data extracted from the searched page with zk-SNARKs as a framework composed of middleware of external source server, data prover, and verification contract. It is intended to provide a smart contract feed framework to protect

The object of the present invention is not limited to the object mentioned above, and other objects and advantages of the present invention not mentioned can be understood by the following description, and will be more clearly understood by the examples of the present invention. Moreover, it will be readily apparent that the objects and advantages of the present invention can be realized by the means and combinations thereof indicated in the claims.

A smart contract feed framework for protecting an oracle system in a blockchain according to an embodiment of the present invention is

A preprocessor that compiles external data through an interface and distributes it as bytecode in order to support the Oracle type that developers can utilize and to support the verification contract that protects privacy;

a framework generator that configures the Ziraffe framework for the bytecode of the preprocessor; and

It is characterized in that it includes a verification unit that performs verification on the data preprocessed by the generated framework.

According to an embodiment, a signature scheme necessary for non-repudiation of a data source necessary for authenticating externally provided data is introduced. Based on this, the blockchain can authenticate the source of the data presented by the owner of the data and confirm that the correct data has been verified. The data owner (prover) cannot manipulate the data received from the data source in the middle.

By providing an oracle interface that can be written in Solidity to verify proofs including authentication of external data, designing for prover privacy can solve problems that are difficult for smart contract developers to implement.

We will provide an evaluation of the performance and cost of protocols and languages that can be referenced when implementing the proposed framework against the cost of proof data generation and smart contract verification operation implemented in Solidity on Ethereum and the size of the data to be stored. can

The following drawings attached to this specification illustrate preferred embodiments of the present invention, and serve to further understand the technical spirit of the present invention together with the detailed description of the present invention to be described later, so the present invention is a matter described in such drawings should not be construed as being limited only to
1 is a conceptual diagram of a smart contract feed framework for protecting an oracle system in a blockchain according to an embodiment.
2 is a configuration diagram for explaining the pre-processing of Ziraffe framwork according to an embodiment.
3 is an exemplary diagram illustrating the Ziraffe language according to an embodiment.
4 is a diagram illustrating verification generation and verification results according to an embodiment.

Specific structural or functional descriptions of the embodiments are disclosed for purposes of illustration only, and may be changed and implemented in various forms. Accordingly, the embodiments are not limited to a specific disclosure form, and the scope of the present specification includes changes, equivalents, or substitutes included in the technical spirit.

Although terms such as first or second may be used to describe various elements, these terms should be interpreted only for the purpose of distinguishing one element from another. For example, a first component may be termed a second component, and similarly, a second component may also be termed a first component.

When a component is referred to as being “connected” to another component, it may be directly connected or connected to the other component, but it should be understood that another component may exist in between.

The singular expression includes the plural expression unless the context clearly dictates otherwise. In this specification, terms such as "comprise" or "have" are intended to designate that the described feature, number, step, operation, component, part, or combination thereof exists, and includes one or more other features or numbers, It should be understood that the possibility of the presence or addition of steps, operations, components, parts or combinations thereof is not precluded in advance.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present specification. does not

Hereinafter, the present invention will be described in detail by describing preferred embodiments of the present invention with reference to the accompanying drawings.

1 is a conceptual diagram of a smart contract feed framework for protecting an oracle system in a block chain of an embodiment, FIG. 2 is a configuration diagram illustrating preprocessing of the Ziraffe framwork of an embodiment, and FIG. 3 is a Ziraffe language of an embodiment It is an exemplary view, and FIG. 4 is a view showing the verification generation and verification results according to an embodiment.

1 to 4 , the block chain is utilized in cryptocurrencies such as Bitcoin. An important point of decentralization is that when participants participate in the protocol in the blockchain, they all have equal rights and are not controlled by any single institution. As consensus-based decentralization is not controlled by a specific few or a single institution, the blockchain has censorship resistance. In addition, as a ledger, blockchain has an irreversible (or immutable, immutable) nature, making it difficult to forge or falsify past details. In blockchain, irreversibility is proportional to the length of the chain that accumulates over time, and integrity is secured by connecting each block with a cryptographic one-way function.

In blockchain, transactions are basically publicly stored in order to verify and constitute a shared ledger. Although the hash value of the public key address is used to provide pseudonymity, the movement of funds and the total amount of money can be tracked. Transaction disclosure changes the state in the smart contract, through which prior information is known. This is a problem in systems where anonymity is required.

A smart contract is a program that runs on a block chain, and Solidity of Ethereum is a representative development language. Solidity runs within the Ethereum Virtual Machine (EVM), a virtual machine in Turing-Complete Languages. The Ethereum virtual machine runs with the input value passed to the smart contract, and the gas concept was introduced to prevent DoS (Denial of Service). Therefore, a smart contract platform such as Ethereum must present the transaction cost of the computation executed within the blockchain along with a fee. On the other hand, there is no cost because the operation executed off-chain is independent of the operation executed on the block chain. It is cost-effective to use verifiable operations to verify operations performed off-chain in on-chain.

On the other hand, in the blockchain, smart contract oracles deal with the difficult problem of securing the reliability of external information. In the case of fetching information from outside the blockchain, the oracle is responsible for the data feed. TLS can be applied to verify that the information is obtained from a data source. Currently, modified TLS 1.3 supports public key cryptography, but does not provide a signature function for non-repudiation of the web server, so a separate web server must participate in the blockchain network or the protocol must be modified so that the server signs with the private key . TLS-N configures oracles by adding a non-repudiation mechanism to TLS. TLS-N is configured to be compatible with TLS1.3, and during the TLS handshake process, the requester and generator verify the result of signing the TLS record exchanged with each other in the blockchain, and proposed a mechanism that cannot deny the process of communicating with each other.

Since the web server does not communicate directly with the blockchain, the data provided must be verified by the data owner directly on the blockchain. For this, the user who owns the data must be configured so that his/her data provided on the web can be issued in a signed form and verified by providing it in the blockchain. In order to provide the data format that can be sent and received in the client-server structure in JSON type and to be provided in a verifiable format so that it can be stored as a smart contract stored in the blockchain, middleware of the server must be added separately. We have built the Oracle framework with this approach.

Here, the zero-knowledge proof is a cryptographic protocol constructed in the presence of a prover to prove and a verifier to verify when a certain fact exists. For example, when zero-knowledge proof is applied in the authentication system, it can be configured in such a way that it proves that it knows the value without revealing the password or personal information required for authentication. With zero-knowledge proof, it can be implemented as a protocol by defining what facts to prove and verify and what secret values to hide.

In the zero-knowledge proof, in the protocol between the prover and the verifier, the prover does not reveal the secret value and only verifies the truth/false of the statement about the fact that the verifier wants to prove. When a function given to a prover and a verifier exists, if a proof value is generated by inputting a sentence and a secret value (witness) as input to the function, the verifier should not be able to know any value related to the secret during the verification process. Summarizing these characteristics, zero-knowledge proof must satisfy the following three conditions.

Completeness: If a statement is true, the verifier must be able to understand this fact.

Soundness: If a statement is false, the verifier must not be convincing.

Zero Knowledgeness: During the proof process, the verifier should be able to know nothing other than the truth or falsehood of a statement.

NIZK (Non-Interactive Zero-Knowledge) converts the prover's statement to be verifiable through zk-SNARK (zero knowledge Succint Non-Interactive Argument of Knowledge) [27] does not interact in a non-interactive manner from short short proofs. Thus, the prover can persuade the verifier with a single message. The prover can use the personal information during proof creation, and the verifier knows nothing about that information.

In off-chain operations, zk-SNARKs can perform computations after a validator with weak computations outsources the computations to untrustworthy validators and return a result including proof that the result is correct. In particular, zk-SNARK is cost-effective on platforms that require computational costs, such as Ethereum, because verification costs are independent of computation. After zk-snarks was introduced, methods such as optimization were also studied [28].

To enable smart contracts to validate data outside of the blockchain, we utilize the ZoKrates toolbox. ZoKrates uses the Rust implementation of the Bellman library of zk-SNARKs. ZoKrates provides a verification contract implemented in Solidity for verification on Ethereum. The language proposed by zkay utilizes ZoKrates to help developers configure and deploy applications. By supporting this at the level of the development language, developers can more easily deploy and operate the verification contract and manage transactions. Reflecting these advantages, we designed to support a new language type for Oracle for validating external data.

The Ziraffe framework consists of three parts as shown in FIG. 1 . First, it can help deploy smart contracts on the blockchain. The second is to allow the user to access the source of external data and deliver the imported value to the block chain. Finally, when a user pulls data from a data source, it allows the server to prove its external origin by signing the issuance. Chapter 3 will explain each detail.

A smart contract developer writes a contract using a high-level language. Various applications using Solidity, the most widely used language at present, have been developed. Solidity can be compiled and used on various platforms such as Klaytn, RSK, TRON, and Hyperledger as well as Ethereum. However, in order to implement Oracle in Solidity, it is developed in a way that utilizes the Oracle infrastructure after it is implemented, so the Oracle interface to Solidity itself is not supported.

From the developer's point of view, when creating applications that require oracles, there is a problem of developing with Solidity and interworking with platforms such as Chainlink and Provable. This is because Oracle is not an interface supported by Solidity, but an interface supported by the platform. Therefore, from the developer's point of view, there is a problem in selecting an Oracle platform operator. This creates a fee issue for Oracle costs.

Another issue is the privacy that arises when fetching external data from smart contracts. Storing external data on the blockchain or submitting it to request verification leads to undesired disclosure of information from users. By using methods such as off-chain computation, calculations related to personal information can be performed off-chain, and only verification can be performed with smart contracts. However, in order for a developer to design in consideration of this, it is necessary to be able to directly develop a verification contract, and cryptographic knowledge about it is required. As a result, without a simple interface, it is difficult to solve the requirements for privacy issues.

The purpose of our framework is to allow users who are dependent on the application to prove external data. Therefore, in an application developed using the Ziraffe framework, the user can directly transmit external data if necessary. A developer only needs to develop an application using the provided interface. Our solution is to introduce a type for the smart contract language and a preprocessor that supports it to provide an interface that can replace the oracle to developers.

The role of the preprocessor can be divided into two main categories. The first is to support Oracle types that developers can use. Any developer who knows and can develop Solidity language supports to implement Oracle using types. The second is to support the verification contract of the privacy protection type. We utilize systems like Zokrates to support the creation of contracts that require oracle verification. The framework allows developers to implement verification contracts written in Solidity by utilizing the interface without knowing about the tool.

By utilizing the interface, not only can the developer's contract development become easier, but the user's privacy can also be protected. For this purpose, the type supported by the Solidity language was implemented and applied to the development and distribution stage of the block chain. The contract required for proof of external data is compiled by preprocessing the result of implementing the interface and distributed as bytecode.

Data that a user can prove by importing data from an external source may include proof of bank balance or issued credentials, proof of current server status (for example, current status for insurance payment), and the like. In order for a user to directly provide a source for external data, it should be possible to verify the presented data first. Another important thing is to be able to protect privacy while generating a provable proof.

We use zk-SNARK to construct such a framework. Proof generated by Zk-snarks is included in the blockchain transaction, propagated, and configured to be verifiable on the blockchain. In the blockchain, from the transaction submitted by the user, the authentication of the source of the data and the necessary facts can be verified. At this time, the details of the user's personal information are not revealed.

Zk-snarks needs a trusted setup for initial configuration. Therefore, in the smart contract development stage, the fields of the transaction that the user wants to present and the data provision details of the server must be defined in advance. When the fact to be verified is confirmed, the contract for this is distributed, and the user can prove the fact by submitting the result of the signed data received from the server.

In the Ziraffe framework, the signature of the data source is mandatory. The ECDH protocol used in the TLS protocol is used for key exchange for HTTSP, but does not provide signed data, thus providing users with non-repudiation of the data source. Therefore, in order to authenticate that the user's data came from the correct source, authentication of the source of the data source is required. For this, we configured the framework to be signed by the server using the cryptographic key exchanged with ECDH.

In order for the server to sign the data details to the user, it is necessary to exchange data of a set standard between the user and the server. In order to generate a proof of the data the user wants to prove with zk-snark, parameters for input data needed in the proof and verification process must be defined. For this, we put middleware on the server and configure it to communicate with the user.

The server's middleware communicates with the user, not the blockchain. Therefore, there is no need to connect directly to the blockchain or register an account on the blockchain. The server only communicates with the user and is responsible for signing and returning the data the user needs. This is an extension of the HTTPS protocol. However, in order to verify the result of the data signed by the server with the private key, the developer must be able to register the smart contract public key in the application development stage.

When the middleware issues signed data, the user takes the signed data as input and creates a proof that does not reveal the secret value. The contract for verifying proof uses the server's public key to verify that the proof submitted by the user came from the correct data source and that the accuracy of the fact to be proved is guaranteed.

When building an application using the Ziraffe framework, it consists of the following procedures. A developer writes a contract using the Solidity language, and writes an oracle function for the data required by the application using the API of the framework. In addition, the application registers the public key of the source corresponding to the data source. The developer compiles the written contract and distributes it to the blockchain network. While operating the application, when verification of external data such as user credentials is required, the user requests the data source to perform HTTPS communication. The data source responds to the user by signing the data requested by the user in the middleware. The user generates a proof that can be verified by calculating the data received from the data source with zk-SNARKs. The user sends the transaction including the proof to the oracle contract. The Oracle contract verifies the user's credentials by verifying the submitted proof.

To program a contract to fetch external information, we provide an interface for a solidity-based contract. The process to be converted into a Solidity contract is shown in [Fig. ZIRF is converted through Lexer, Parser, and Rewriter for the written language. Here, lexer converts keywords (URL, JSON, function) or operators specified in ziraffe and existing solidity into tokens. The paser creates an Abstract Syntax Tree according to ziraffe's grammar rules. After that, the Rewriter rewrites the code after checking the type while traversing the AST tree.

The format of the data that the user's client gets from an external source is composed of JSON as shown in Figures (a) and (b). JSON means the type to specify for the value to be received as a result of the https request. It can be used in the same way as a structure, and when verifying a signature, the hash function is calculated according to the order of the values inside. In Ethereum, it is stored in the form of a struct. Here, in the case of the format shown in Figure (a), Hash (balance | dataOfInquiry) value is stored.

Change the arbitrarily added type and variable JSON and URL to the soldity type and variable. JSON and URL are converted into structs used in Ethereum, respectively. The ReqParam variable is expressed in ZRF, but in the rewritten solidity contract, the value is removed so that the value does not increase on-chain. For the newly added functions get and post, a value is requested from the url, and the requested value is converted into a contract that can verify signature verification with zero-knowledge proof.

For the creation of contract VC for verification, it is created based on ZoKrates. VC receives proof as input and can prove it without revealing the value (e.g. balance) of the input information. The URL type defines the public key pk required to verify the signature of the url string value and the value transmitted from the url, and is stored in the form of a struct in Ethereum. ReqParm receives a string value as a value that specifies the parameter used in the https request. The parameters used in the request are used only for https requests and are not stored in the blockchain. When making a request, enter it in the form of {id, password} as the second argument of the function that makes an https request.

get<Bank> is a function that sends a get request to the url passed as the first argument. It receives the JSON value that receives the request result in the form of a bank and verifies the signature with the pk corresponding to the url. The request function supports get and post among https requests. When get<Bank> is requested, the request result JSON value is shown as (c) of [Figure ]. The value of the message is used as the Bank value and the signature is used by reading the signature value. An example for developing 1 contract to prove the balance of a bank that implements such a function is shown in (d).

TLS 1.3 exchanges keys to be used for https via ECDHE. Using the server's certificate received through key exchange, you can check whether the currently connected server is an authenticated server. After that, the client requests data and the server performs encrypted communication and receives a response. However, since the TLS 1.3 protocol does not support application-level signing in the server, there is a problem that the client cannot prove to a third party that the data is issued by the server. In Ziraffe, it is configured to support signing by applying middleware that can be utilized in the server.

After a normal key exchange, the server responds to the client's data request. The middleware responds with the JSON standard defined for the data the server responds to, and is configured to respond by signing the server's private key. As shown in c of [Figure ], the server's signature is added according to the JSON requested by the client. The data to be signed may include the data value to be responded to (e.g. balance), timestamp, Blockcnumber, user's address, and ID value used for server authentication.

The role of the server is only to sign the issued data for non-repudiation. Therefore, when developing using the Ziraffe framework, the programmer must define the standard between the user (client) and the external source (server) in the application building phase. The specified standard is required in the setup process in zk-SNARK.

The user creates a Proof that can be verified by the contract as a prover to prove data with the role of a client communicating with an external source. For example, a prover can create a Proof so that the amount is not revealed while verifying by submitting “How much do I have” to the blockchain.

Since zk-SNARKs require an initial trusted setup, the developer defines the facts that the user needs to prove in advance, and defines the operation while simultaneously deploying the JSON and verifiable contract for this. The main contents of the operation are (1) verification of the source of the server and the pk corresponding to the URL (2) verification of the signature of the data issued from the server (3) The value of private data among JSON values can be verified without revealing it Create a Proof so that

The generated Proof composes and submits a transaction that calls the verification contract VC, and submits the input value used to generate the Proof and the signature of the server. In VC, the Proof operation is verified, and true/false is determined as the result of the operation.

Evaluate the implementation of the Ziraffe framework described above. In the blockchain, smart contract platforms such as Ethereum have to pay the cost of computation. In addition, if you write a value to storage data that is permanently stored in Ethereum, you will also have to pay for it. Since on-chain operations require cost, off-chain operations require no cost, the main performance can be measured in time. Therefore, the main performance indicators are the time to generate Proof off-chain with zk-SNARKs for the data issued by the server, the gas cost consumed to verify the Proof in the contract deployed on Ethereum, and the size required to store the Proof.

The Ethereum network used for evaluation was conducted based on the Rapsten Test network, and the client that generated Proof in off-chaion operation has Intel i7 811 CPU 3.67GHZ and 16GB RAM. The data used to generate Proof may vary depending on how many times the hash value required to fix the length of JSON is performed. Therefore, the test was conducted on the Proof that verified the execution of the hash function and the signature. ECDSA- (how many curves? something like this) was used to generate the signature.

As a result of using Ziraffe framwork for JSON input, the time to generate Proof is 12,413 msec by signing the hash value to JSON data. At this time, 256,112 gas appears as the required value to verify the Proof. The value stored in the storage of the contract is 256 bytes, and in the case of zk-SNRAKs, since the complexity of the verification cost is constant, it can be seen that the value reflects only the price of the network state regardless of the Proof creation time.

Ziraffe framwor aims to support an environment for Oracle contract programmers to easily build oracles. This chapter explains the differences between the existing research and the proposed framework.

Blockchain and Privacy A decentralized blockchain can cause privacy issues because it stores and verifies the validity of transactions. To solve this problem, there are studies [][] that apply zero-knowledge proof to zerocash[] or Monero[], or payment channels to ensure the anonymity of transactions. However, these studies do not support data source authentication because they are designed for the purpose of verifying without revealing facts that can be verified on-chain.

Oracle with TLS There are studies that try to vote in a decentralized environment to implement an oracle, but they do not support the authentication procedure for users to bring their own data. On the other hand, Town Crier[], TLS-N[], and Deco[] support data authentication by presenting a protocol for connecting TLS to the blockchain. In particular, in the case of Deco, in TLS 1.3 version, the protocol is configured so that the prover can verify to the oracle (verifier) through the three-party handshake method without modifying the server for authentication of external sources. In this study, Oracle is configured to operate without a separate operation to eliminate platform dependence, and the framework is supported so that developers can develop such an environment.

Zero knowledge Proof for Smart Contract In order to apply zero knowledge proof to smart contract, hawk configured a protocol using manager. Zokrates[] and zkay[] proposed languages that support developers to implement off-chain operations and verify them with contracts on-chain. The ziraffe framework proposes a framework that can solve the oracle problem by utilizing Zorkates to provide external data source authentication and an interface to it.

Accordingly, one embodiment showed that it is possible to support source authentication for external data and protection of user privacy. In addition, it is configured to support the interface so that the programmer can easily implement the contract for verification. The proposed process makes it easy to implement the verification of zk-SNARKs when building applications that require data from external sources, and can bring usefulness to the development stage. Reflecting this, developers can build the necessary environment according to the requirements of the application, and users are guaranteed to hide their private data when submitting data to the blockchain.

The embodiments described above may be implemented by a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the apparatus, methods and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate (FPGA). array), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general purpose or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that may include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

Software may comprise a computer program, code, instructions, or a combination of one or more thereof, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. , or may be permanently or temporarily embody in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored in 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 in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the computer-readable medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic such as floppy disks. Included are magneto-optical media, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with reference to the limited drawings, those skilled in the art may apply various technical modifications and variations based on the above. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Claims (1)

A preprocessor that compiles external data through an interface and distributes it as bytecode to support the Oracle type that developers can utilize and to support the verification contract that protects privacy;
a framework generator that configures the Ziraffe framework for the bytecode of the preprocessor; and
A smart contract feed framework for protecting an oracle system in a blockchain, characterized in that it includes a verification unit that performs verification on the data preprocessed with the generated framework.

Images