Blockchain platform for transmitting transaction data between blockchains and method of transmitting transaction data using the same

Abstract

A blockchain platform for transmitting transaction data between blockchains according to one embodiment of the present disclosure may include a consortium chain, at least one user service connected to the consortium chain through a bridge, and a Blockchain Utility Service (BUS) for transmitting transaction data between the consortium chain and the at least one user service. The consortium chain may establish a consortium access right for executing a smart contract based on a smart contract execution request from the at least one user service. The at least one user service may transmit the transaction data to the consortium chain through either the bridge or the BUS based on the consortium access right.

Description

Technology Field

[0001] The embodiments disclosed in this document relate to a technology for transmitting transaction data between multiple blockchains, and more specifically, to a blockchain platform for transmitting transaction data between multiple blockchains using a bridge and a BUS (Blockchain Utility System) and a method for transmitting transaction data using the same. Background Technology

[0002] Blockchain networks have various forms and structures, and each blockchain included in a blockchain network can have unique characteristics and functions.

[0003] Depending on the various forms and structures of blockchain networks, multiple blockchains can be interconnected on a blockchain network centered around a main blockchain. Interoperability between these various blockchain networks can enhance the scalability and multifunctionality of blockchain technology.

[0004] Meanwhile, on a blockchain network, various forms of transaction data can be transmitted and received between multiple blockchains. For example, transaction data may be interchain data transmitted and received between different blockchains. Transaction data may include transaction information, smart contract call information, state updates, security-related data, and messaging and information sharing.

[0005] Transaction data transmitted and received on a blockchain network can be transmitted in various ways depending on the function and purpose of the data. Therefore, a transaction data transmission and reception mechanism is required to quickly and securely transmit transaction data between multiple blockchains. The problem to be solved

[0006] One objective of the present invention is to provide a blockchain platform and a method for transmitting transaction data using the same, which improve interoperability between blockchains and maximize the security and efficiency of transmitting and receiving transaction data by determining a transaction data transmission method based on consortium access rights for executing smart contracts.

[0007] However, the problem that the present invention aims to solve is not limited to the problem mentioned above, and may be expanded in various ways without departing from the spirit and scope of the present invention. means of solving the problem

[0008] A blockchain platform for transmitting transaction data between blockchains according to embodiments of the present disclosure may include a consortium chain, at least one user service connected to the consortium chain through a bridge, and a Blockchain Utility Service (BUS) for transmitting transaction data between the consortium chain and the at least one user service. The consortium chain may establish a consortium access right for executing a smart contract based on a smart contract execution request from the at least one user service. The at least one user service may transmit the transaction data to the consortium chain through either the bridge or the BUS based on the consortium access right.

[0009] In one embodiment, the consortium access right may include at least one of a service security level set based on the type of at least one user service, an ID access right set based on a user ID, and a smart contract execution level set based on the type of smart contract.

[0010] In one embodiment, the BUS may include an access authority management unit that verifies the consortium access authority, an API management unit that processes API calls between the at least one user service and the consortium chain, and a transaction management unit that transmits and receives the transaction data.

[0011] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records a DATA ID, a payment smart contract that pays the settlement amount of a token security, a validation smart contract that verifies the validity of the data, a token security smart contract that issues the token security, a marketplace smart contract that brokers the trading of the token security, and an interchain smart contract that sets the consortium access rights.

[0012] In one embodiment, the interchain smart contract can execute at least one of a service map for setting a service security level, an ID map for setting ID access rights, and an SC map for setting a smart contract execution level.

[0013] In one embodiment, the service map may set the service security level for each of the at least one user service based on the security requirement level according to the type of the at least one user service connected to the consortium chain through the bridge. The service map may distribute the service security level to the at least one user service.

[0014] In one embodiment, the at least one user service can transmit the transaction data to the consortium chain through the BUS when the service security level is a first security level. The at least one user service can transmit the transaction data to the consortium chain through the bridge when the service security level is a second security level.

[0015] In one embodiment, the ID map can set the ID access rights for each user ID based on the DATA ID of the user ID using the at least one user service. The ID map can distribute the ID access rights to the at least one user service.

[0016] In one embodiment, the at least one user service can transmit the transaction data to the consortium chain through the bridge when the ID access authority of the user ID is a first access level. The at least one user service can transmit the transaction data to the consortium chain through the BUS when the ID access authority of the user ID is a second access level.

[0017] In one embodiment, the SC map can set a smart contract execution level for each smart contract based on the contract characteristics of the smart contract included in the consortium chain. The SC map can distribute the smart contract execution level to at least one user service.

[0018] In one embodiment, the at least one user service can transmit the transaction data to the consortium chain through the BUS when the smart contract execution level of the smart contract is a first execution level. The at least one user service can transmit the transaction data to the consortium chain through the bridge when the smart contract execution level of the smart contract is a second execution level.

[0019] A method for transmitting transaction data between blockchains according to embodiments of the present disclosure may include: an operation of establishing a consortium access right for executing a smart contract based on a smart contract execution request from at least one user service connected to the consortium chain through a bridge; and an operation of transmitting the transaction data to the consortium chain through either the bridge or a BUS (Blockchain Utility Service) based on the consortium access right.

[0020] In one embodiment, the consortium access right may include at least one of a service security level set based on the type of at least one user service, an ID access right set based on a user ID, and a smart contract execution level set based on the type of smart contract.

[0021] In one embodiment, the BUS can verify the consortium access rights, process API calls between the at least one user service and the consortium chain, and transmit and receive the transaction data.

[0022] In one embodiment, the consortium chain may include at least one of a DATA ID smart contract that records a DATA ID, a payment smart contract that pays the settlement amount of a token security, a validation smart contract that verifies the validity of the data, a token security smart contract that issues the token security, a marketplace smart contract that brokers the trading of the token security, and an interchain smart contract that sets the consortium access rights.

[0023] In one embodiment, the interchain smart contract can execute at least one of a service map for setting a service security level, an ID map for setting ID access rights, and an SC map for setting a smart contract execution level.

[0024] In one embodiment, the service map may set the service security level for each of the at least one user service based on the security requirement level according to the type of at least one user service connected to the consortium chain through the bridge, and distribute the service security level to the at least one user service.

[0025] In one embodiment, the operation of the at least one user service transmitting the transaction data may include, when the service security level is a first security level, the operation of transmitting the transaction data to the consortium chain through the BUS, and when the service security level is a second security level, the operation of transmitting the transaction data to the consortium chain through the bridge.

[0026] In one embodiment, the ID map may set the ID access rights for each user ID based on the DATA ID of the user ID using the at least one user service, and distribute the ID access rights to the at least one user service.

[0027] In one embodiment, the operation of the at least one user service transmitting the transaction data may include the operation of transmitting the transaction data to the consortium chain through the bridge when the ID access authority of the user ID is a first access level, and the operation of transmitting the transaction data to the consortium chain through the BUS when the ID access authority of the user ID is a second access level.

[0028] In one embodiment, the SC map can set a smart contract execution grade for each smart contract based on the contract characteristics of the smart contract included in the consortium chain, and distribute the smart contract execution grade to at least one user service.

[0029] In one embodiment, the operation of the at least one user service transmitting the transaction data may include the operation of transmitting the transaction data to the consortium chain through the BUS when the smart contract execution level of the smart contract is a first execution level, and the operation of transmitting the transaction data to the consortium chain through the bridge when the smart contract execution level of the smart contract is a second execution level. Effects of the invention

[0030] A blockchain platform and a transaction data transmission method using the same, according to the various embodiments disclosed in this document, can determine a transaction data transmission method based on consortium access rights for executing smart contracts. Accordingly, the blockchain platform and the transaction data transmission method using the same can improve interoperability between blockchains and maximize the security and efficiency of transaction data transmission and reception.

[0031] The effects obtainable from the exemplary embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by those skilled in the art to which the exemplary embodiments of the present disclosure belong from the description below. That is, unintended effects resulting from the implementation of the exemplary embodiments of the present disclosure can also be derived by those skilled in the art from the exemplary embodiments of the present disclosure. Brief explanation of the drawing

[0032] FIG. 1 illustrates the structure of a blockchain network according to one embodiment. FIG. 2 illustrates the configuration of a blockchain platform according to one embodiment. FIG. 3 illustrates the configuration of a user service according to one embodiment. FIG. 4 illustrates a smart contract of a consortium chain according to one embodiment. FIG. 5 illustrates the transmission of transaction data between a user service and a consortium chain according to one embodiment. FIG. 6 illustrates a method for transmitting transaction data of a blockchain platform according to a specific example. FIG. 7 illustrates a transaction data transmission method according to a service security level according to one embodiment. FIG. 8 illustrates a method for transmitting transaction data according to ID access rights according to one embodiment. FIG. 9 illustrates a method for transmitting transaction data according to a smart contract execution level according to one embodiment. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Specific details for implementing the invention

[0033] Hereinafter, embodiments of the present disclosure are described in detail with reference to the drawings so that those skilled in the art can easily practice them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and brevity.

[0034] FIG. 1 illustrates the structure of a blockchain network (10) according to one embodiment.

[0035] Referring to FIG. 1, on a blockchain network (10), multiple blockchains can be interconnected on the blockchain network (10) with the main blockchain at the center. Interoperability between these various blockchains can improve the scalability and multifunctionality of blockchain technology.

[0036] For example, on a blockchain network (10), multiple service chains (12a, 12b, 12c, 12d, 12e, 12f) may be interconnected around a consortium chain (11). The consortium chain (11) may be an interchain connecting multiple blockchains. The consortium chain (11) may receive smart contract execution requests from multiple blockchains and execute smart contracts based on said smart contract execution requests. The consortium chain (11) may receive a request signal from one blockchain and transmit said request signal to another blockchain. The consortium chain (11) may receive a response signal from one blockchain and transmit said response signal to another blockchain.

[0037] Multiple service chains (12a, 12b, 12c, 12d, 12e, 12f) may include various types of blockchains based on user services. For example, a service chain may be an on-chain layer of a user service. For example, a service chain may include at least one of an enterprise blockchain (12a), a job search blockchain (12b), a data ID blockchain (12c), a content blockchain (12d), a marketplace blockchain (12e), and a financial blockchain (12f).

[0038] The enterprise blockchain (12a) may be a blockchain designed to meet the needs of a specific enterprise or industry sector. The enterprise blockchain (12a) may provide enterprise operational services including at least one of supply chain management, enterprise resource planning, and enterprise internal data management. For example, the enterprise blockchain (12a) may only allow participation by specific enterprises and certified partners.

[0039] The recruitment blockchain (12b) may be a blockchain designed to increase transparency in the recruitment process and to securely manage worker information. For example, the recruitment blockchain (12b) may securely store worker information including at least one of a resume, credentials, and past work experience. For example, the recruitment blockchain (12b) may increase the reliability of the recruitment process by sharing the worker information with authenticated users.

[0040] The DATA ID blockchain (12c) may be a blockchain for managing the DATA IDs of individuals and organizations. For example, the DATA ID blockchain (12c) may provide at least one of personal identity verification and secure access control based on the DATA ID. The DATA ID blockchain (12c) may store and manage the DATA ID of users and ensure the integrity of the DATA ID.

[0041] The content blockchain (12d) may be a blockchain for the creation, distribution, and copyright management of digital content. For example, the content blockchain (12d) may manage ownership of content such as digital art, music, and video. For example, the content blockchain (12d) may mediate transactions of content such as digital art, music, and video.

[0042] A marketplace blockchain (12e) may be a blockchain for online trading of goods and services. For example, a marketplace blockchain (12e) may broker the buying and selling of token securities. A marketplace blockchain (12e) may provide trading services including at least one of the integrity of transaction records, the assurance of the reliability of user ratings and reviews, and secure payment processing.

[0043] A financial blockchain (12f) may be a blockchain for banking, investment, insurance, and other financial services. A financial blockchain (12f) may be used for the purpose of improving the efficiency, transparency, and security of financial transactions. For example, a financial blockchain (12f) may provide fast transaction processing, low transaction costs, enhanced security, and transparency of transactions. For example, a financial blockchain (12f) may provide automated financial services through smart contracts.

[0044] In this way, on the blockchain network (10), the service chain can perform functions suitable for the purpose of at least one user service among the enterprise blockchain (12a), job search blockchain (12b), DATA ID blockchain (12c), content blockchain (12d), marketplace blockchain (12e), and financial blockchain (12f) by executing smart contracts through the consortium chain (11).

[0046] FIG. 2 illustrates the configuration of a blockchain platform according to one embodiment, and FIG. 3 illustrates the configuration of a user service according to one embodiment.

[0047] Referring to FIGS. 2 and 3, the blockchain platform (20) of the present disclosure may include at least one user service (22, 23) connected to the consortium chain (21) via a consortium chain (21) and a bridge (e.g., Bridge1, Bridge2) to share transaction data between heterogeneous services on the blockchain. For example, at least one user service (22, 23) can efficiently share transaction data with the consortium chain (21) by being connected to the consortium chain (21) via a bridge on the blockchain. For example, at least one user service (e.g., provider service (22)) can efficiently share transaction data with at least one other service (e.g., requester service (23)) by being connected to the consortium chain (21) via a bridge on the blockchain.

[0048] The consortium chain (21) may be a blockchain tier including at least one consortium node. The consortium chain (21) may mediate the sharing of transaction data between at least one user service (22, 23) by being connected to at least one user service (22, 23) through a bridge. For example, the consortium chain (21) may verify transaction data received from at least one user service (22, 23) and create a new consortium node based on said transaction data.

[0049] A consortium chain (21) may be a permitted blockchain layer for sending and receiving transaction data of at least one user service (22, 23). At least one user service (22, 23) may request a lookup of a consortium node of the consortium chain (21). At least one user service (22, 23) may request a record of a consortium node of the consortium chain (21). For example, the consortium chain (21) may receive authentication data from at least one user service (22, 23). The consortium chain (21) may record authentication data in a consortium node. For example, the consortium chain (21) may receive a request for an authentication data lookup from at least one user service (22, 23) and send an authentication data lookup response to at least one service.

[0050] A bridge may be a data exchange system (e.g., a data transmission protocol) that transmits transaction data received from at least one user service (22, 23) to a consortium chain (21). For example, at least one user service (22, 23) and a consortium chain (21) may transmit and receive transaction data by being interconnected through at least one bridge.

[0051] In one embodiment, at least one user service (22, 23) may lock transaction data and transmit the locked transaction data to a bridge. The bridge may transmit the transaction data received from at least one user service (22, 23) to a consortium chain (21). The consortium chain (21) may receive the locked transaction data through the bridge and unlock the locked transaction data.

[0052] In one embodiment, the consortium chain (21) may lock transaction data and transmit the locked transaction data to a bridge. The bridge may transmit the transaction data received from the consortium chain (21) to at least one user service (22, 23). At least one user service (22, 23) may receive the locked transaction data through the bridge and unlock the locked transaction data.

[0053] At least one user service (22, 23) may include an off-chain layer including at least one processor and an on-chain layer including said at least one block node. For example, the on-chain layer may be a private blockchain layer for recording transaction data. At least one user service (22, 23) may generate transaction data based on input data received from an external source (e.g., user) and store transaction data. For example, said off-chain layer may generate said transaction data based on input data. For example, said on-chain layer may record said transaction data on said at least one block node.

[0054] As shown in FIG. 3, the off-chain layer can be implemented as an electronic device (310). The electronic device (310) may include a memory (311), a processor (312), and a communication unit (313). For example, the electronic device (310) can transmit transaction data generated in the off-chain layer to the on-chain layer and manage said transaction data on the on-chain layer. For example, the on-chain layer may include at least one block node for recording said transaction data. For example, the on-chain layer may include a smart contract for managing said transaction data.

[0055] Meanwhile, the configuration illustrated in FIG. 3 illustrates a configuration for describing an embodiment according to the present disclosure, and other configurations for performing the functions of the electronic device (310) and the on-chain layer may be added in addition to the illustrated configuration, and the illustrated configurations may be omitted. For example, the electronic device (310) may be a transaction data generation server. For example, the electronic device (310) may be a personal information server.

[0056] In one embodiment, the memory (311) is a storage medium used by the electronic device (310) and can store data such as at least one instruction or setting information corresponding to at least one program. The program may include an operating system (OS) program and various application programs.

[0057] In one embodiment, the memory (311) may include at least one type of storage medium among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), RAM (random access memory, RAM), SRAM (static random access memory), ROM (read only memory, ROM), EEPROM (electrically erasable programmable ROM), PROM (programmable ROM), magnetic memory, a magnetic disk, and an optical disk.

[0058] A communication unit (313) according to one embodiment can perform direct (e.g., wired) communication between an electronic device (310) and at least one external device (e.g., client device (not shown), IAM server (not shown), billing server (not shown), cloud server (not shown), IPFS (not shown)). For example, the communication unit (313) can receive input data transmitted from a client device. Additionally, for example, the communication unit (313) can transmit unique NFT attribute values ​​of the generated NFT to a cloud server (not shown) and IPFS (not shown).

[0059] In one embodiment, the communication unit (313) may include a wireless communication unit (e.g., a cellular communication module, a short-range wireless communication module, or a GNSS (global navigation satellite system) communication module) or a wired communication unit. The corresponding communication unit among these may communicate with at least one external device (e.g., a client device, an IAM server, a billing server, a cloud server, an IPFS) through a network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a wide-area communication network such as a computer network (e.g., a LAN or WAN).

[0060] In one embodiment, the communication unit (313) may support a 5G network following a 4G network and next-generation communication technology, for example, new radio access technology. The NR access technology may support high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and connection of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low-latency communications (URLLC)). The communication unit (313) may support a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate, for example. The communication unit (313) can support various technologies for securing performance in the high-frequency band, such as beamforming, massive MIMO (multiple-input and multiple-output), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna.

[0061] In one embodiment, the communication unit (313) can support various requirements defined in the electronic device (310), at least one external device (e.g., client device (not shown), IAM server (not shown), billing server (not shown), cloud server (not shown), IPFS (not shown)) or network system.

[0062] In one embodiment, the processor (312) can execute software (e.g., a program) to control at least one other component (e.g., a hardware or software component) of the electronic device (310) connected to the processor (312) and can perform various data processing or operations.

[0063] In one embodiment, the processor (312) may store commands or data received from another component (e.g., communication unit (313)) in volatile memory as at least part of data processing or computation, process the commands or data stored in volatile memory, and store the result data in non-volatile memory.

[0064] In one embodiment, the processor (312) may include a main processor (e.g., a central processing unit or an application processor) or an auxiliary processor that can be operated independently or together with it (e.g., a graphics processing unit, a neural processing unit (NPU), or a communication processor).

[0065] In one embodiment, the processor (312) may generate transaction data based on input data and transmit the transaction data to the consortium chain. For example, the processor (312) may generate TR data containing information regarding work performed by a worker based on a work specification received from a worker. For example, the processor (312) may record the TR data on the on-chain layer and transmit the TR data to the consortium chain based on a request from the consortium chain.

[0066] The processor (312) can query transaction data recorded on a consortium node on the consortium chain. For example, the processor (312) can access TR data recorded on a consortium node based on a request from an employer and query information regarding work performed by a worker included in the TR data. The processor (312) can request the execution of at least one smart contract on the consortium chain. For example, the processor (312) can request the execution of at least one of a DATA ID smart contract, a payment smart contract, a validation smart contract, a token security smart contract, and a marketplace smart contract from the consortium chain.

[0067] As shown in FIG. 3, the on-chain layer may be a blockchain layer that operates in conjunction with the off-chain layer. The on-chain layer may be implemented as a service chain (320). For example, the service chain (320) may be a decentralized network including a smart contract and a plurality of block nodes. For example, the service chain (320) may include at least one of an enterprise blockchain (e.g., 12a of FIG. 1), a job search blockchain (e.g., 12b of FIG. 1), a data ID blockchain (e.g., 12c of FIG. 1), a content blockchain (e.g., 12d of FIG. 1), a marketplace blockchain (e.g., 12e of FIG. 1), and a financial blockchain (e.g., 12f of FIG. 1).

[0068] In one embodiment, the electronic device (310) may be configured to support a user accessing a smart contract and a specific node of the service chain (320). For example, the electronic device (310) may act as an intermediary for connection to a node by transmitting a front-end code to the user. In another example, the electronic device (310) may act as a direct link between the user and the specific node.

[0069] In one embodiment, the smart contract may be an automated program executed on the service chain (320) in the form of a digital contract. For example, the smart contract may be executed upon fulfillment of certain conditions. For example, the result of the execution of the smart contract may be permanently recorded on a block node of the service chain (320).

[0070] In one embodiment, a smart contract can record transaction data received from an off-chain layer on a block node of an on-chain layer. Additionally, the smart contract can generate transaction data on the on-chain layer based on input data. For example, the smart contract can ensure transparency and reliability regarding transaction data by directly generating transaction data or by recording transaction data on a block node.

[0071] In one embodiment, at least one user service may include a provider service (22) that provides the transaction data and a requester service (23) that requests the transaction data. For example, the provider service (22) may be a job matching service that generates a DATA ID based on work performance history. For example, the provider service (22) may be an owner service used by an owner selling token securities. For example, the requester service (23) may be a financial service that evaluates a user's financial credit using the DATA ID. For example, the requester service (23) may be a buyer service used by a buyer purchasing token securities. The provider service (22) may provide the transaction data to the requester service (23) based on the consortium chain (21). The requester service (23) may verify the validity of the transaction data based on the consortium chain (21).

[0072] Specifically, the provider service (22) can generate main data and authentication data based on the transaction data recorded in at least one block node. The provider service (22) can provide the main data to the requester service (23). The provider service (22) can provide the authentication data to the consortium chain (21). The requester service (23) can verify the validity of the main data based on the authentication data of the consortium chain (21).

[0073] The provider service (22) can generate main data and validation data for transaction data based on the transaction data request from the requester service (23). For example, the total data generated by the provider service (22) may include main data and validation data. The main data may include at least one of a transaction data summary, aggregated data, and raw data. The validation data may include at least one of KYC information, PoE information, and template information.

[0074] The consortium chain (21) can be connected to the provider service (22) through the first bridge (Bridge1). The consortium chain (21) can receive the authentication data from the provider service (22) through the first bridge (Bridge1). The consortium chain (21) can write the authentication data to at least one consortium node.

[0075] The consortium chain (21) can be connected to the requester service (23) through the second bridge (Bridge2). The consortium chain (21) can receive a request for authentication data lookup from the requester service (23) through the second bridge (Bridge2). The consortium chain (21) can send an authentication data lookup response to the requester service (23) based on the authentication data.

[0076] The requester service (23) can verify the validity of the main data received from the provider service (22) based on the authentication data lookup response received from the consortium chain (21). For example, the requester service (23) can verify at least one of the details regarding the user of the main data, details regarding the existence of the main data, and details regarding the transaction data included in the main data.

[0077] In this way, the blockchain platform of the present disclosure can securely share transaction data between heterogeneous services and secure trust among sharers regarding the shared transaction data by verifying main data using authentication data recorded in the consortium chain (21).

[0079] FIG. 4 illustrates a smart contract of a consortium chain (400) according to one embodiment.

[0080] Referring to FIG. 4, the consortium chain (400) may include at least one smart contract. The smart contract may be an automated program executed on the consortium chain (400). For example, the smart contract may be executed upon fulfillment of certain conditions. For example, the result of the execution of the smart contract may be permanently recorded on the consortium node of the consortium chain (400).

[0081] In one embodiment, the consortium chain (400) may include at least one of a DATA ID smart contract (410) that records and manages DATA IDs, a payment smart contract (420) that pays the settlement amount of token securities, a validation smart contract (430) that validates the validity of transaction data, a token securities smart contract (440) that issues token securities, a marketplace smart contract (450) that brokers the trading of token securities, and an interchain smart contract (460) that sets consortium access rights.

[0082] For example, at least one user service (e.g., service (22, 23) of FIG. 1) may request the consortium chain (400) to execute at least one of a DATA ID smart contract (410), a payment smart contract (420), a validation smart contract (430), a token security smart contract (440), a marketplace smart contract (450), and an interchain smart contract (460). The consortium chain (400) may execute at least one smart contract based on the smart contract execution request from at least one user service.

[0083] The DATA ID smart contract (410) can manage at least one transaction data. The DATA ID may be a worker’s CV (Curriculum Vitae) generated based on information regarding work. For example, the DATA ID may include at least one of worker personal information (e.g., worker name, worker age, DATA ID authentication means), work performance history (e.g., number of times the worker performed work, worker evaluation grade), and revenue information (e.g., total revenue, monthly average revenue, average hourly wage).

[0084] For example, the DATA ID smart contract (410) can record and manage a DATA ID containing at least one of information about work performed by a worker, TR data, an employment contract, and a worker's resume. For example, the DATA ID smart contract (410) can record the DATA ID on at least one consortium node. For example, the DATA ID smart contract (410) can unlock the DATA ID recorded on the consortium node based on a DATA ID lookup request from at least one user service and transmit the DATA ID to at least one user service. For example, the DATA ID smart contract (410) can request the validation smart contract (430) to validate the DATA ID.

[0085] The payment smart contract (420) can pay money to at least one user service based on transaction data. For example, the payment smart contract (420) can pay wages to a worker based on a DATA ID that includes at least one of information about work performed by the worker, TR data, a labor contract, and the worker's resume.

[0086] For example, the payment smart contract (420) can settle wages agreed upon by the worker and the employer in the employment contract based on TR data. For example, the payment smart contract (420) can request the employer service to deposit the settlement amount. For example, the payment smart contract (420) can transmit the settlement amount to the worker service.

[0087] The validation smart contract (430) can validate the validity of transaction data. For example, the validation smart contract (430) can validate the validity of the DATA ID based on a DATA ID lookup request.

[0088] For example, the validation smart contract (430) can validate the validity of an employment contract based on a wage settlement request. For example, the validation smart contract (430) can validate the validity of TR data based on a request to issue token securities with wages as the underlying transaction.

[0089] The token securities smart contract (440) can manage issued token securities based on transaction data. Specifically, the token securities smart contract (440) can create, transfer, and settle token securities based on transaction data. For example, the token securities smart contract (440) can issue token securities of a predetermined type based on a request for issuance of token securities from at least one user service. For example, the token securities smart contract (440) can change the owner of the token securities based on a request to change the owner of the token securities. For example, the payment smart contract (420) can request payment of the settlement amount of the token securities based on the issuance conditions of the token securities.

[0090] A marketplace smart contract (450) can mediate transactions of goods or non-goods based on transaction data. For example, the marketplace smart contract (450) can mediate transactions of goods or non-goods including at least one of data, tokens, intangible assets, and tangible assets. For example, the marketplace smart contract (450) can register the sale of said token securities based on a seller's request to sell the token securities.

[0091] For example, the marketplace smart contract (450) may create a sales contract for said token security based on a purchase request for said token security. For example, the marketplace smart contract (450) may request the proceeds from the sale of the token security from the buyer service and transfer the proceeds received from the buyer service to the owner service. The marketplace smart contract (450) may use at least one of DC, EWA DC, token, and fiat currency as the proceeds from the sale of the token security.

[0092] An interchain smart contract (460) can manage the transmission and reception of transaction data between different blockchains. For example, an interchain smart contract (460) can manage the transmission of transaction data between a consortium chain and a service chain. For example, an interchain smart contract (460) can set consortium access rights. For example, an interchain smart contract (460) can execute at least one of a service map that sets service security levels, an ID map that sets ID access rights, and an SC map that sets smart contract execution levels.

[0094] FIG. 5 illustrates the transmission of transaction data between a user service and a consortium chain according to one embodiment, and FIG. 6 illustrates a method for transmitting transaction data of a blockchain platform according to one embodiment.

[0095] Referring to FIGS. 5 and 6, a blockchain platform for transmitting transaction data between blockchains according to embodiments of the present disclosure may include a consortium chain (51), at least one user service (52) connected to the consortium chain (51) through a bridge, and a BUS (54) (Blockchain Utility Service) for transmitting transaction data between the consortium chain (51) and the at least one user service (52).

[0096] Specifically, the consortium chain (51) can transmit and receive transaction data with at least one user service (52) by being connected to at least one user service (52) through a bridge. For example, the consortium chain (51) can verify transaction data received from at least one user service (52) and create a new consortium node based on said transaction data. Meanwhile, the consortium chain (51) can determine the method of transmitting transaction data based on consortium access rights. For example, the consortium chain (51) can transmit or receive transaction data through at least one of a bridge and a BUS (54) based on consortium access rights.

[0097] For example, a bridge may be a data exchange system (e.g., a data transmission protocol) that transmits transaction data received from at least one user service (52) to a consortium chain (51). For example, at least one user service (52) and a consortium chain (51) may transmit and receive transaction data by being interconnected through at least one bridge.

[0098] For example, as shown in FIG. 5, the BUS (54) may include an access authority management unit that checks the consortium access authority, an API management unit that processes API calls between the at least one user service (52) and the consortium chain (51), and a transaction management unit that transmits and receives the transaction data.

[0099] The access rights management unit can verify the access rights of users and systems within the BUS (54) and manage said access rights. The access rights management unit can authenticate the user service (52) and determine the level of permission for the user service (52) to access the consortium chain (51).

[0100] The API management unit can handle API calls between the user service (52) and the consortium chain (51) and manage API calls. For example, the API management unit can support APIs corresponding to the purpose and function of the user service (52) and manage the transmission and reception of transaction data through the APIs.

[0101] The transaction management unit can manage the creation, verification, execution, and recording of transaction data within the BUS (54). For example, the transaction management unit can manage transaction data by considering the efficiency and processing speed of the network between the user service (52) and the consortium chain (51). Based on determining whether the transmission of transaction data through the BUS (54) is appropriate, the transaction management unit can transmit and receive transaction data between the user service (52) and the consortium chain (51).

[0102] According to one example, in operation 610, the consortium chain (51) can establish a consortium access right to execute a smart contract based on a smart contract execution request from at least one user service (52).

[0103] Consortium access rights may include at least one of a service security level set based on the type of at least one user service (52), an ID access right set based on a user ID, and a smart contract execution level set based on the type of smart contract.

[0104] For example, an interchain smart contract included in the consortium chain (51) can set consortium access rights. For example, the interchain smart contract can execute at least one of a service map that sets service security levels, an ID map that sets ID access rights, and an SC map that sets smart contract execution levels.

[0105] In one embodiment, the service map may set the service security level for each of the at least one user service (52) based on the security requirement level according to the type of the at least one user service (52) connected to the consortium chain (51) through the bridge. The service map may distribute the service security level to the at least one user service (52).

[0106] In one embodiment, the ID map can set the ID access rights for each user ID based on the DATA ID of the user ID using the at least one user service (52). The ID map can distribute the ID access rights to the at least one user service (52).

[0107] In one embodiment, the SC map can set a smart contract execution grade for each smart contract based on the contract characteristics of the smart contract included in the consortium chain (51). The SC map can distribute the smart contract execution grade to at least one user service (52).

[0108] According to one example, in operation 620, at least one user service (52) can transmit the transaction data to the consortium chain (51) through either the bridge and the BUS (54) based on the consortium access rights. For example, at least one user service (52) can receive the consortium access rights and determine a method of transmitting the transaction data to the consortium chain (51) based on the consortium access rights.

[0109] In one embodiment, at least one user service (52) may transmit the transaction data to the consortium chain (51) through either the bridge and the BUS (54) based on a service security level. For example, at least one user service (52) may receive a service security level and determine a method of transmitting the transaction data to the consortium chain (51) based on the service security level.

[0110] The service security level may be determined according to the type of user service (52). For example, the service security level may be changed according to the sensitivity and importance of the user service (52). For example, the service security level may include a first security level for a user service (52) requiring high security and a second security level for a user service (52) requiring relatively low security.

[0111] The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the BUS (54) when the service security level is the first security level. The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the bridge when the service security level is the second security level.

[0112] In one embodiment, at least one user service (52) can transmit the transaction data to the consortium chain (51) through either the bridge and the BUS (54) based on ID access rights. For example, at least one user service (52) can receive ID access rights and determine a method of transmitting the transaction data to the consortium chain (51) based on ID access rights.

[0113] ID access rights may be determined based on the user ID that accesses (e.g., logs in) the user service (52). For example, the user ID may be a DATA ID. For example, ID access rights may be changed based on user information such as the user's role, position, and specific requirements stored in the user ID. For example, ID access rights may include a first access level that has the right to access and modify all data and a second access level that has the right to access and view only limited data.

[0114] The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the bridge when the ID access authority of the user ID is of the first access level. The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the BUS (54) when the ID access authority of the user ID is of the second access level.

[0115] In one embodiment, at least one user service (52) may transmit the transaction data to the consortium chain (51) through either the bridge and the BUS (54) based on the smart contract execution grade. For example, at least one user service (52) may receive the smart contract execution grade and determine a method of transmitting the transaction data to the consortium chain (51) based on the smart contract execution grade.

[0116] The smart contract execution level may be determined based on the type and function of the smart contract requested for execution by the user service (52). For example, the smart contract execution level may change depending on the complexity, influence, and risk level of the smart contract. For example, the smart contract execution level may include a first execution level of relatively high importance, such as validation and monetary payment, and a second execution level of relatively low importance, such as data inquiry and data request.

[0117] The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the BUS (54) when the smart contract execution level of the smart contract is the first execution level. The above at least one user service (52) can transmit the transaction data to the consortium chain (51) through the bridge when the smart contract execution level of the smart contract is the second execution level.

[0118] In this way, the blockchain platform of the present disclosure and the transaction data transmission method using the same can determine the transaction data transmission method based on consortium access rights for executing smart contracts.

[0119] Therefore, a blockchain platform and a method for transmitting transaction data using it can improve interoperability between blockchains and maximize the security and efficiency of transmitting and receiving transaction data.

[0121] FIG. 7 illustrates a transaction data transmission method according to a service security level according to one embodiment.

[0122] Referring to FIG. 7, the blockchain platform can determine the method of transferring transaction data between the user service (72) and the consortium chain (71) based on consortium access rights. For example, the blockchain platform can determine the method of transferring transaction data between the user service (72) and the consortium chain (71) based on service security grades.

[0123] An interchain smart contract of a consortium chain (71) may include a service map. The service map may set a service security level for each of the at least one user service (72) based on the security requirement level according to the type of at least one user service (72) connected to the consortium chain (71) through the bridge. The service map may distribute the service security level to the at least one user service (72).

[0124] In one embodiment, at least one user service (72) can transmit the transaction data to the consortium chain (71) through either the bridge and the BUS (74) based on the service security level.

[0125] For example, at least one user service (72) can receive a service security rating and determine a method of transmitting the transaction data to the consortium chain (71) based on the service security rating.

[0126] The service security level can be determined according to the type of user service (72). For example, the service security level can be changed according to the sensitivity and importance of the user service (72).

[0127] As shown in FIG. 7(a), a financial service (72) requiring relatively high security may be a first security grade. The financial service (72) can transmit the transaction data to the consortium chain (71) via the BUS (74). Likewise, the consortium chain (71) can transmit the transaction data to the financial service (72) via the BUS (74).

[0128] As shown in FIG. 7(b), a content service (72) requiring relatively low security may be a second security level. The content service (72) can transmit the transaction data to the consortium chain (71) through a bridge. Likewise, the consortium chain (71) can transmit the transaction data to the content service (72) through a bridge.

[0130] FIG. 8 illustrates a method for transmitting transaction data according to ID access rights according to one embodiment.

[0131] Referring to FIG. 8, the blockchain platform can determine the method of transferring transaction data between the user service (82) and the consortium chain (81) based on consortium access rights. For example, the blockchain platform can determine the method of transferring transaction data between the user service (82) and the consortium chain (81) based on ID access rights.

[0132] An interchain smart contract of a consortium chain (81) may include an ID map. The ID map may set ID access rights for each user ID based on the DATA ID of a user ID using the at least one user service (82). The ID map may distribute the ID access rights to the at least one user service (82).

[0133] In one embodiment, at least one user service (82) can transmit the transaction data to the consortium chain (81) through either the bridge and the BUS (84) based on ID access rights.

[0134] For example, at least one user service (82) may receive an ID access right and determine a method of transmitting the transaction data to the consortium chain (81) based on the ID access right.

[0135] ID access rights may be determined based on the user ID that accesses (e.g., logs in) the user service (82). For example, the user ID may be a DATA ID. For example, ID access rights may be changed based on user information such as the user's role, position, and specific requirements stored in the user ID.

[0136] As shown in FIG. 8(a), the administrator's user ID, which has access to all data, may be a first access level. The user service (82) connected to the administrator's user ID can transmit the transaction data to the consortium chain (81) through a bridge. Likewise, the consortium chain (81) can transmit the transaction data to the user service (82) connected to the administrator's user ID through a bridge.

[0137] As shown in FIG. 8(b), a user ID of a general user who has access to only limited data may be a second access class. The user service (82) to which the general user's user ID is connected can transmit the transaction data to the consortium chain (81) via the BUS (84). Likewise, the consortium chain (81) can transmit the transaction data to the user service (82) to which the general user's user ID is connected via the BUS (84).

[0139] FIG. 9 illustrates a method for transmitting transaction data according to a smart contract execution level according to one embodiment.

[0140] Referring to FIG. 9, the blockchain platform can determine the method of transferring transaction data between the user service (92) and the consortium chain (91) based on consortium access rights. For example, the blockchain platform can determine the method of transferring transaction data between the user service (92) and the consortium chain (91) based on smart contract execution levels.

[0141] An interchain smart contract of a consortium chain (91) may include an SC map. The SC map may set a smart contract execution grade for each smart contract based on the contract characteristics of the smart contract included in the consortium chain (91). The SC map may distribute the smart contract execution grade to at least one user service (92).

[0142] In one embodiment, at least one user service (92) can transmit the transaction data to the consortium chain (91) through either the bridge and the BUS (94) based on the smart contract execution level.

[0143] For example, at least one user service (92) may receive a smart contract execution grade, and the service may determine a method of transmitting the transaction data to the consortium chain (91) based on the smart contract execution grade.

[0144] The smart contract execution level can be determined based on the type and function of the smart contract that the user service (92) requests to execute. For example, the smart contract execution level can be changed based on the complexity, influence, and risk level of the smart contract.

[0145] As shown in FIG. 9(a), smart contracts of relatively low importance, such as data lookup and data request, may be of the second execution level. For example, the DATA ID smart contract may be of the second execution level. The user service (92) can send a smart contract execution request to the consortium chain (91) through the bridge. Likewise, the consortium chain (91) can send the smart contract execution result to the user service (92) through the bridge.

[0146] As shown in FIG. 9(b), smart contracts of relatively high importance, such as proof of validity and monetary payment, may be of the first execution grade. For example, a payment smart contract may be of the first execution grade. The user service (92) can transmit a smart contract execution request to the consortium chain (91) via the BUS (94). Likewise, the consortium chain (91) can transmit the smart contract execution result to the user service (92) via the BUS (94).

[0147] In this way, the blockchain platform of the present disclosure and the transaction data transmission method using the same can determine the transaction data transmission method based on consortium access rights for executing smart contracts.

[0148] Therefore, a blockchain platform and a method for transmitting transaction data using it can improve interoperability between blockchains and maximize the security and efficiency of transmitting and receiving transaction data.

[0149] The electronic device according to the various embodiments disclosed in this document may be of various forms. The electronic device may include, for example, a display device, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a consumer electronics device. The electronic device according to the embodiments of this document is not limited to the devices described above.

[0150] The various embodiments of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said embodiments. For example, a component expressed in the singular should be understood as a concept including a plural component unless the context clearly implies only the singular. It should be understood that the term "and / or" as used in this document encompasses any possible combination of one or more of the listed items. Terms such as "comprising," "having," and "consisting of" used in this disclosure are intended merely to indicate the existence of the features, components, parts, or combinations thereof described in this disclosure, and the use of such terms is not intended to exclude the existence or addition of one or more other features, components, parts, or combinations thereof. In this document, each of the phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “A, B or C,” “at least one of A, B and C,” and “at least one of A, B, or C” may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as “first,” “second,” or “first” or “second” may be used simply to distinguish a component from another component and do not limit the components in any other aspect (e.g., importance or order).

[0151] The terms “part” or “module” as used in the various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. The “part” or “module” may be a component formed integrally, or a minimum unit of said component or a part thereof that performs one or more functions. For example, according to one embodiment, the “part” or “module” may be implemented in the form of an application-specific integrated circuit (ASIC).

[0152] In the various embodiments of this document, the term “in the case of” as used may be interpreted, depending on the context, to mean “when,” “at the time of,” or “in response to a decision,” or “in response to a detection.” Similarly, “in the case where it is determined,” or “in the case where it is detected,” may be interpreted, depending on the context, to mean “at the time of determination,” or “in response to a decision,” or “at the time of detection,” or “in response to a detection.”

[0153] A program executed by an electronic device described in this document may be implemented by hardware components, software components, and / or a combination of hardware and software components. The program may be executed by any system capable of executing computer-readable instructions.

[0154] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software may be implemented as a computer program containing instructions stored on computer-readable storage media. Examples of computer-readable storage media include magnetic storage media (e.g., ROM (Read-Only Memory), RAM (Random-Access Memory), floppy disks, hard disks, etc.) and optical reading media (e.g., CD-ROMs, DVDs (Digital Versatile Discs)). Computer-readable storage media may be distributed across networked computer systems, allowing computer-readable code to be stored and executed in a distributed manner. Computer programs may be distributed online (e.g., download or upload) via an application store (e.g., Play Store™) or directly between two worker devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0155] According to various embodiments, each component (e.g., module or program) of the components described above may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to various embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as those performed by the corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by the module, program, or other components may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

Claim 1 A blockchain platform for transmitting transaction data between blockchains comprises: a consortium chain; at least one user service connected to the consortium chain through a bridge; and a Blockchain Utility Service (BUS) for transmitting transaction data between the consortium chain and the at least one user service, wherein the consortium chain establishes a consortium access right for executing a smart contract based on a smart contract execution request from the at least one user service, and the at least one user service transmits the transaction data to the consortium chain through either the bridge or the BUS based on the consortium access right. Claim 2 A blockchain platform according to claim 1, wherein the consortium access right comprises at least one of a service security level set based on the type of at least one user service, an ID access right set based on a user ID, and a smart contract execution level set based on the type of smart contract. Claim 3 A blockchain platform according to claim 1, wherein the BUS comprises: an access right management unit for verifying the consortium access right; an API management unit for processing API calls between the at least one user service and the consortium chain; and a transaction management unit for transmitting and receiving the transaction data. Claim 4 In claim 1, the consortium chain comprises at least one of a DATA ID smart contract that records a DATA ID, a payment smart contract that pays the settlement amount of a token security, a validation smart contract that verifies the validity of data, a token security smart contract that issues the token security, a marketplace smart contract that brokers the trading of the token security, and an interchain smart contract that establishes the consortium access rights. Claim 5 In paragraph 4, the above-mentioned interchain smart contract is a blockchain platform that executes at least one of a service map for setting service security levels, an ID map for setting ID access rights, and an SC map for setting smart contract execution levels. Claim 6 In paragraph 5, the service map is a blockchain platform that sets a service security grade for each of the at least one user service based on a security requirement level according to the type of at least one user service connected to the consortium chain through the bridge, and distributes the service security grade to the at least one user service. Claim 7 A blockchain platform according to claim 6, wherein at least one user service transmits the transaction data to the consortium chain through the BUS when the service security level is a first security level, and transmits the transaction data to the consortium chain through the bridge when the service security level is a second security level. Claim 8 In paragraph 5, the ID map is a blockchain platform that sets the ID access rights for each user ID based on the DATA ID of a user ID using the at least one user service, and distributes the ID access rights to the at least one user service. Claim 9 A blockchain platform according to claim 8, wherein at least one user service transmits the transaction data to the consortium chain through the bridge when the ID access authority of the user ID is a first access level, and transmits the transaction data to the consortium chain through the BUS when the ID access authority of the user ID is a second access level. Claim 10 In paragraph 5, the above SC map is a blockchain platform that sets a smart contract execution grade for each smart contract based on the contract characteristics of the smart contract included in the above consortium chain, and distributes the smart contract execution grade to at least one user service. Claim 11 A blockchain platform according to claim 10, wherein at least one user service transmits the transaction data to the consortium chain via the BUS when the smart contract execution level of the smart contract is a first execution level, and transmits the transaction data to the consortium chain via the bridge when the smart contract execution level of the smart contract is a second execution level. Claim 12 A method for transmitting transaction data between blockchains, comprising: an operation of establishing a consortium access right for executing a smart contract based on a smart contract execution request from at least one user service connected to the consortium chain through a bridge; and an operation of the at least one user service transmitting the transaction data to the consortium chain through either the bridge or a BUS (Blockchain Utility Service) based on the consortium access right. Claim 13 A transaction data transmission method according to claim 12, wherein the consortium access right comprises at least one of a service security level set based on the type of at least one user service, an ID access right set based on a user ID, and a smart contract execution level set based on the type of smart contract. Claim 14 In claim 12, the above BUS verifies the consortium access rights, processes API calls between the at least one user service and the consortium chain, and transmits and receives the transaction data, a transaction data transmission method. Claim 15 A transaction data transmission method according to claim 12, wherein the consortium chain comprises at least one of a DATA ID smart contract that records a DATA ID, a payment smart contract that pays the settlement amount of a token security, a validation smart contract that verifies the validity of data, a token security smart contract that issues the token security, a marketplace smart contract that brokers the trading of the token security, and an interchain smart contract that establishes the consortium access rights. Claim 16 In claim 15, the above-mentioned interchain smart contract executes at least one of a service map for setting service security levels, an ID map for setting ID access rights, and an SC map for setting smart contract execution levels, a transaction data transmission method. Claim 17 A transaction data transmission method according to claim 16, wherein the service map sets the service security grade for each of the at least one user service based on the security requirement level according to the type of at least one user service connected to the consortium chain through the bridge, and distributes the service security grade to the at least one user service. Claim 18 A method for transmitting transaction data according to claim 17, wherein the operation of at least one user service transmitting the transaction data comprises: transmitting the transaction data to the consortium chain through the BUS when the service security level is a first security level; and transmitting the transaction data to the consortium chain through the bridge when the service security level is a second security level. Claim 19 In claim 16, the above ID map sets the ID access rights for each user ID based on the DATA ID of the user ID using the at least one user service, and distributes the ID access rights to the at least one user service, a transaction data transmission method. Claim 20 A method for transmitting transaction data according to claim 19, wherein the operation of transmitting the transaction data by at least one user service comprises: transmitting the transaction data to the consortium chain through the bridge when the ID access authority of the user ID is a first access level; and transmitting the transaction data to the consortium chain through the BUS when the ID access authority of the user ID is a second access level. Claim 21 In claim 16, the above SC map sets a smart contract execution grade for each smart contract based on the contract characteristics of the smart contract included in the above consortium chain, and distributes the smart contract execution grade to at least one user service, a transaction data transmission method. Claim 22 A method for transmitting transaction data according to claim 21, wherein the operation of at least one user service transmitting the transaction data comprises: transmitting the transaction data to the consortium chain through the BUS when the smart contract execution level of the smart contract is a first execution level; and transmitting the transaction data to the consortium chain through the bridge when the smart contract execution level of the smart contract is a second execution level.

Images