Method and system for digital item tokenization and trading using state-based smart contract

Abstract

A method for tokenizing and trading digital items using a state-based smart contract and a system thereof are disclosed. A method for trading digital items performed by an item trading system according to one embodiment may include: a step of obtaining a verification result through data verification of said digital item in response to a buyer's request to trade a digital item; a step of executing a state-based smart contract by verifying transaction conditions for executing a transaction of said digital item based on the obtained verification result; and a step of trading said digital item through escrow processing using said executed state-based smart contract.

Description

Technology Field

[0001] The following description concerns digital item tokenization and trading technology using smart contracts. Background Technology

[0003] We will now discuss the user trading needs regarding digital objects that are uniquely present in digital services and applications. In digital services and applications, such as games and AR / VR, various elements possessing scarcity value within individual services or applications—including characters, items, music, art, and design information (virtual space services)—become primary interests and trading targets for users. In the case of individual characters or items, the service or application may set a purchase cost, or the value of the digital object or item may be calculated based on usage rates; furthermore, users who possess or acquire these items directly assign value to them and trade them.

[0004] However, issues regarding the trading of digital items may arise. When transactions occur between individuals rather than purchasing digital objects or items directly from a service provider, there is a possibility of abnormal transactions. If the legitimate transfer of the digital item is not completed despite the buyer's payment, the buyer may suffer damages from the transaction.

[0005] Furthermore, various problems, such as theft and theft, may occur during the process of users making unauthorized transactions within a specific service. Additionally, in the case of small-scale services, there may be issues such as a lack of a sufficient trading market, or problems like excessive fees may arise when using specific external trading services.

[0006] There is a need for a secure peer-to-peer method for trading digital objects and items based on decentralization. Support for secure trading methods between B2B, B2C, and C2C, along with payment methods for such transactions, is required within a decentralized environment that is not dependent on specific operators. In this process, a method that enables mutual trust must be provided. The problem to be solved

[0008] A method and system for trading digital items using state-based smart contracts can be provided. means of solving the problem

[0010] A digital item trading method performed by an item trading system may include: a step of obtaining a verification result through data verification of said digital item in response to a buyer's request to trade the digital item; a step of executing a state-based smart contract by verifying transaction conditions for executing the transaction of said digital item based on the obtained verification result; and a step of trading said digital item through escrow processing using said executed state-based smart contract.

[0011] The above-mentioned acquisition step may include receiving a transaction request for a digital item from a buyer, the request including the ID, metadata, transaction conditions, and owner information of the digital item, and initializing the transaction status of the received digital item.

[0012] The above-mentioned acquisition step may include a step of verifying a zero-knowledge proof of ownership of the digital item on-chain or off-chain.

[0013] The above acquisition step may include a step of verifying external data through an oracle network to reflect market data containing real-time price information in the digital item.

[0014] The above execution step may include setting transaction conditions and constraints in the state-based smart contract and notifying the buyer of the set state-based smart contract.

[0015] The above transaction step may include verifying the buyer's payment amount through the executed state-based smart contract, processing the transfer of the verified payment amount to an escrow account, and setting the transferred payment amount to a locked state.

[0016] The above transaction step may include the step of approving the buyer through multi-signature verification in accordance with the execution of the escrow agreement, and unlocking the payment amount set to the above locked state and delivering it to the seller.

[0017] The above transaction step may include setting conditions for the cancellation and refund of a transaction of a digital item, and monitoring the status of the execution of the escrow contract according to the set conditions for the cancellation and refund of a transaction of a digital item.

[0018] The above digital item trading method may further include a step of linking a digital object and item supplier with a minting system.

[0019] The above-mentioned linking step may include the step of registering a digital item in a minting system in response to a minting request by a digital object and item provider.

[0020] The above-mentioned linking step may include the step of registering a schema in the minting system in response to a request for schema registration of the digital item, and confirming the existence of the item within the service by verifying whether the registered schema matches through item verification of the digital item in response to an item minting request.

[0021] The above-mentioned integration step may include the step of storing metadata of the digital item upon confirming whether an item exists within the service, executing a state-based smart contract in response to a request for token issuance of the digital item, and issuing token information based on the executed state-based smart contract.

[0022] The above-mentioned integration step may include a step of completing minting by updating state information within the service based on the above-mentioned issued token information.

[0023] An item trading system comprises at least one processor configured to execute computer-readable instructions contained in memory, wherein the at least one processor obtains a verification result through data verification of the digital item in response to a buyer's request to trade the digital item, verifies transaction conditions for executing the transaction of the digital item based on the obtained verification result, executes a state-based smart contract, and trades the digital item through escrow processing using the executed state-based smart contract. Effects of the invention

[0025] 1. Extended State-Based Trading Architecture

[0026] Advantages: The entire transaction lifecycle can be systematically managed based on a state-based approach. Transaction stability can be guaranteed through clear entry and exit conditions for each state. System reliability can be enhanced through automated rollback mechanisms in the event of exceptions. Transaction traceability and auditability can be significantly improved. Complex multi-stage transaction processes can be handled efficiently.

[0027] Technical Excellence: The system offers excellent scalability through a state machine-based design. Its modular structure facilitates the addition of new features. It can provide high performance through parallel processing. System management is efficient through state-based monitoring. Operating costs can be reduced through automated state transitions.

[0028] 2. Enhanced Hybrid Verification System

[0029] Advantages: Reliability can be enhanced through the integrated verification of on-chain and off-chain data. Zero-knowledge proofs can provide transparency while protecting privacy. Real-time data verification is possible through an Oracle network. Transaction security can be guaranteed through multiple verification steps. Operational efficiency can be increased through the automation of the verification process.

[0030] Technical Excellence: Maintenance is easy due to the modularization of verification logic. System reliability can be enhanced through real-time data verification. A scalable verification framework can be provided. The balance between security and efficiency can be optimized. Integration of various verification methods is possible.

[0031] 3. Standardized game service integration system

[0032] Advantages: It can provide a standard interface that enables easy integration with game services. Data consistency can be guaranteed through real-time state synchronization. The processing of large volumes of item minting can be performed efficiently. It can provide a flexible structure that facilitates service-specific customization. Stable error handling and recovery mechanisms can be implemented.

[0033] Technical Excellence: It supports efficient communication via RESTful APIs and WebSockets. It can provide high scalability through a microservices architecture. It can include automated monitoring and notification systems. The reliability of data synchronization can be guaranteed. Efficient resource management is possible.

[0034] 4. Optimized blockchain integration structure

[0035] Advantages: Operating costs can be reduced through efficient transaction management. Maintenance is easy due to the modularization of smart contracts. The processing speed of blockchain transactions can be optimized. Secure token issuance and management are possible. Transparent transaction history management can be provided.

[0036] Technical Excellence: Can provide an optimized smart contract structure. Can support efficient transaction batch processing. Blockchain node management can be automated. Can utilize a decentralized data store. Can provide a scalable blockchain integration structure.

[0037] 5. Advanced security system

[0038] Advantages: Security can be enhanced through multi-factor authentication and authorization management. Information security can be guaranteed through encrypted data processing. Risk factors can be detected early through real-time security monitoring. An automated security response system can be implemented. Auditing functions for regulatory compliance can be provided.

[0039] Technical Excellence: Data security can be enhanced through the application of the latest encryption technology. A systematic access control system can be implemented. Real-time detection and response to security threats are possible. A logging system capable of complete audit trails can be provided. Automated security policy management is possible. Brief explanation of the drawing

[0041] FIG. 1 is a diagram illustrating a system linkage operation for minting with a digital object and item provider in one embodiment. FIG. 2 is a diagram illustrating the operation of trading, payment, and ownership transfer through the minting of digital items in one embodiment. FIG. 3 is a diagram illustrating the procedure for registering a digital item in a minting system in one embodiment. FIG. 4 is a drawing for explaining a minting system in one embodiment. FIG. 5 is a diagram illustrating a state-based smart contract in one embodiment. FIG. 6 is a diagram illustrating a transaction state in one embodiment. FIG. 7 is a diagram illustrating a hybrid verification mechanism in one embodiment. FIG. 8 is a drawing for explaining an item trading system in one embodiment. FIG. 9 is a diagram illustrating the detailed operation of a main module in one embodiment. FIG. 10 is a diagram illustrating a state-based transaction management module in one embodiment. FIG. 11 is a diagram illustrating the process of a core system in one embodiment. FIG. 12 is a diagram illustrating the operation of linking game service item minting in one embodiment. Specific details for implementing the invention

[0042] Hereinafter, embodiments will be described in detail with reference to the attached drawings.

[0044] FIG. 1 is a diagram illustrating a system linkage operation for minting with a digital object and item provider in one embodiment.

[0045] A Digital Objects / Items Provider (service or application provider) that supplies digital objects or / and items possesses shared information regarding individual digital objects and items. Here, it is assumed that the shared information regarding individual digital objects and items is linked to identifiable owner information.

[0046] At this time, the digital object and item provider may provide meta-information about individual digital objects and items in the form of an API, or provide a function to look up information on identification systems (including unique URLs / URIs, etc.) such as IDs.

[0047] Providers of digital objects and items may link with external minting systems for the secure trading and distribution of their digital objects and items. In this case, the linkage with the external minting system may be conducted in a formalized manner, or users may directly utilize the trading of digital objects and items through minting without such a formalized step.

[0048] For users to conduct transactions using direct minting, digital object and item providers must provide functions such as generating and retrieving unique codes or temporary transfer information for the transfer of objects and items for minimal transactions.

[0049] In the future, trading information of digital objects and items provided by the minting system can be utilized for digital object and item supply strategies.

[0050] Upon a request for integration (contract) with the Minting System, the Minting System may provide future minting services for the digital objects and items of the relevant provider based on the said information (meta-information of the digital objects and items). In this case, if there is no formalized minting contract, the process may proceed if the unique ID of the relevant service provider can be verified through a user request.

[0051] When a transaction occurs through the minting system, the minting system can provide information on the minted items in the form of summaries and reports by digital object and item suppliers.

[0052] FIG. 2 is a diagram illustrating the operation of trading, payment, and ownership transfer through the minting of digital items in one embodiment.

[0053] We will now explain the data transmission and reception operations between the seller, buyer, minting system, and transaction system.

[0054] After selecting objects and items, sellers can register tradable information on the minting system (including signing if necessary). Based on the tradable information registered by sellers, the minting system can convert it into publicly available and verifiable issuance information by performing minting for the corresponding digital objects and items. Buyers can browse tradable digital object and item information from the minting system.

[0055] The buyer can identify the digital objects and items they wish to trade (purchase) and request a transaction for the identified digital objects and items. The minting system can generate transaction information for the digital objects and items for which a transaction has been requested and request a response from the transaction system regarding the generated transaction information. The transaction system can generate transaction information for the requested digital objects and items and wait for the generated transaction information. As payment is made by the buyer for the digital objects and items for which a transaction has been requested, the transaction system can set a lock on the payment after confirming the deposit.

[0056] The minting system may request the seller to sign for the transfer of ownership of digital objects and items for which payment has been completed. The seller may update the owner information based on the transaction details of the digital objects and items and provide seller signing information to the minting system to complete the transaction. The minting system may verify the seller signing information and transfer the digital objects and items corresponding to the verified seller signing information to the buyer. The buyer may check whether the ownership information of the digital objects and items has been updated. In this case, if the information of the seller's digital objects and items belongs to a Digital Service / Application Provider registered on the minting system, it may be directly reflected in the information on that system. Otherwise, the buyer must be able to directly register the information of the relevant digital objects and items on the relevant service. The registration method in this case must be based on the unique code or temporary information for transfer of the relevant digital objects and items.

[0057] The buyer can transmit buyer signing information to the minting system. The minting system can update the buyer signing information on the minting system. At this time, the privacy status of the minting information based on the buyer's request may be determined. Once the minting system updates the buyer signing information, the transaction system can unlock the transaction costs. The seller can check the transaction costs.

[0058] FIG. 3 is a diagram illustrating the procedure for registering a digital item in a minting system in one embodiment.

[0059] In the embodiments, the procedure for registering digital items in the minting system is described by distinguishing between cases where the digital object and item provider is registered in the minting system and cases where the digital object and item provider is not registered.

[0060] If the minting system is a registered provider of digital objects and items, it can request the metadata of the unique digital objects and items of the registered provider and receive the requested metadata. In this case, if the digital object and item provider is registered with the minting system, it can retrieve a list of digital objects and items of the relevant service or application owned by the user by querying user identification information, such as a user ID, through inter-system linkage, and can support a registration function for trading the corresponding objects and items based on the user's selection.

[0061] The minting system can verify the validity of the digital object and item based on the unique meta information of the digital object and item from the received digital object and item provider. This can be done through the digital object and item provider, or by checking for previous registration status on the minting system.

[0062] In addition, if the minting system is an unregistered provider of digital objects and items, it may request meta information of unique digital objects and items provided by a user who wishes to register, and receive the requested meta information of unique digital objects and items. At this time, the minting system must be able to query the information of the relevant digital objects and items in the form of code on an external system. That is, it must be possible to query the digital objects and items to be traded based on the code on a smart contract.

[0063] The minting system can verify the validity of the received unique digital objects and items based on their metadata. It can proceed by checking for previous registration status on the minting system. Additionally, the minting system can query the identity of the user wishing to trade or an evaluation based on past transaction history through an external system.

[0064] The minting system can register tradable information by verifying the validity of the relevant digital objects and items. The minting system can pre-register transaction-related information, such as available trading hours, trading methods and payment plans, user information disclosure status, and user authentication status. In this process, the payment methods available for trading digital objects and items are systems that can be connected to the minting system. In addition to general payment gateways, crypto-based services can also be eligible for payment if they can be integrated.

[0065] The minting system reviews the seller's transaction availability information and can decide on the transfer of ownership based on the reviewed information. It may also follow the seller's choice regarding whether to transfer ownership in advance. That is, it can be decided whether to transfer ownership on the minting system upon a buyer's request or to provide ownership on the minting system at the time of prior registration. In this case, to prevent the exposure of the seller's personal information and the unique information of digital objects and items, information may be generated and recorded in the form of a separate DID.

[0066] The minting system can generate smart contracts for relevant transaction information and include these generated smart contracts in the minting information. By enabling the retrieval of basic information related to the transaction through the smart contract, buyers can verify the validity of the transaction. For example, if a buyer attempts to trade after generating multiple tradable entries for the same object or item, normal retrieval on other smart contracts will not be possible once one transaction is completed.

[0067] The minting system can publish digital objects and items through minting. In this case, the scope of publication may be restricted according to the seller's requirements. For example, a series of privacy-related features may be provided, such as anonymizing seller information of digital objects and items or providing only partial information about the digital items.

[0068] FIG. 4 is a drawing for explaining a minting system in one embodiment.

[0069] Digital Object & Item Providers refer to service providers that supply digital-based objects or items, and may include game and service providers, application providers, etc.

[0070] Digital object and item providers may include unique objects and items. In addition to pure digital information, unique objects and items may include real-world objects connected via technologies such as digital twins or CSPs, or real-world assets tokenized through STOs, etc. Furthermore, digital objects acquired and controlled in AR / MR, etc., may also be included.

[0071] The Digital Object and Item Provider may include the Original Object and Item Schema. The Digital Object and Item Provider refers to schema information regarding digital objects and items, and must be able to provide at least the minimum information necessary for external recognition of the uniqueness of the said object or item. The said object or schema may have a structured (public) data structure for external recognition and may provide it externally. To provide it externally, a schema lookup service in the form of an API may be provided.

[0072] Providers of digital objects and items may include original applications. Original applications refer to independent applications or services, etc., capable of operating digital objects or services. The form of the original application may vary depending on the environmental characteristics in which the object or item operates, and within said application, each object must be distinguishable and possess at least a minimum level of uniqueness.

[0073] Providers of digital objects and items may include third-party applications. If publicly available schema information for a digital object or item is available, services regarding that object may also be provided through external applications or services. This enhances interoperability and improves the usability of the object.

[0074] The Data Connect Layer is a layer that provides data linkage functions between information on digital object and item suppliers and the minting system and other external systems. Since the Data Connect Layer is configured for individual digital objects and items to operate in specific operational and service environments, separate data adaptation and connection functions must be provided to connect with the external minting system.

[0075] APIs can be utilized in situations where digital object and item providers are linked with a minting system based on APIs. In this case, to effectively utilize APIs, the two entities must share compatible API specifications and be able to connect them.

[0076] Oracles can provide a method to connect digital objects and items—the external world—to the minting system through the Oracle. In an environment where multiple providers of digital objects and items exist, technologies such as Blockchain can be utilized as a means for decentralized minting systems to interoperate.

[0077] Data Connectors can provide dedicated module functions for data interoperability. Data Connectors may use separate connectors for effective data transmission and reception through mutual cooperation between digital object and item providers and the minting system.

[0078] A Minting System is a system that provides functions for registering, managing, and trading objects and items from digital object and item suppliers as unique object information within a digital environment. The Minting System can provide the capability to generate identification information that grants uniqueness in a global network environment for digital objects or items that are restricted to specific services. Consequently, digital objects or items that possess uniqueness in a global network environment can be utilized for valuation, assignment, and trading based on that uniqueness.

[0079] The minting system may include a minting service layer, a contract event repository, sandbox execution environments, and a blockchain or local database. The minting service layer may include an object search function and an object transaction function.

[0080] FIG. 5 is a diagram illustrating a state-based smart contract in one embodiment.

[0081] Referring to Fig. 5, code information regarding the implementation method of a state-based smart contract is described. The item trading system can manage the entire process of digital item trading based on states through a state-based smart contract system. In this case, each state has clear entry / exit conditions, and transition to the next state is possible only when the conditions are met. All state transitions are recorded on the blockchain, making them traceable and auditable. In the event of an exception, a rollback to the previous state can be performed automatically.

[0082] State-based smart contracts enable clear tracking of transaction processes due to their state-based design, enhance transaction stability through automated state management, and allow for the systematic processing of complex transaction conditions.

[0083] FIG. 6 is a diagram illustrating a transaction state in one embodiment.

[0084] This is a transaction state diagram covering transaction creation, item verification, buyer deposit, seller approval, and buyer approval. Upon transaction creation, the item trading system can verify ownership through item metadata verification. During item verification, the system can check the price information of the digital item and verify buyer eligibility. Upon buyer deposit, the system can set a lock on the amount and manage smart contracts. In this case, if the buyer deposit times out, the transaction may be canceled. Upon seller approval, the system can verify multi-signature verification and state transition conditions. Through this, buyer approval may be completed or rejected.

[0085] FIG. 7 is a diagram illustrating a hybrid verification mechanism in one embodiment.

[0086] The item trading system can verify the authenticity of digital items through integrated verification of on-chain and off-chain data. The item trading system can provide privacy protection features utilizing zero-knowledge proofs. The item trading system can perform real-time data verification through an oracle network.

[0087] FIG. 8 is a drawing for explaining an item trading system in one embodiment.

[0088] The item trading system may include a Client Layer, an API Gateway Layer, a Core Service Layer, a Blockchain Layer, and External Systems.

[0089] The client layer provides a user interface and can provide a standardized interface (SDK / API Client) for system integration.

[0090] The API Gateway layer may include an API Gateway, a WebSocket Server, and a GraphQL Endpoint.

[0091] API gateways can process and route external requests.

[0092] WebSocket servers can synchronize real-time data.

[0093] GraphQL endpoints can query and process flexible data.

[0094] The core service layer can perform trade management, verification management, and security management.

[0095] The core service layer can include a State Controller to manage transaction states, a Trade Controller to control transaction processes, and an Escrow Controller to handle escrow for transaction management.

[0096] The core service layer can control the verification process (Verification Controller), process Zero Knowledge Proofs, and validate external data (Oracle Validator) for verification management.

[0097] The core service layer can control access (Access Controller), manage decentralized identities (DID Service), and manage keys (Key Management) for security management.

[0098] The Blockchain Layer can process state-based transactions through the Smart Contract Layer, manage verification contracts, and manage escrow contracts.

[0099] Through blockchain layer chain management, it provides a consensus mechanism and can manage the ledger.

[0100] External systems may include a Digital Item Provider, an Oracle Network providing external data, and a Payment System.

[0101] FIG. 9 is a diagram illustrating the detailed operation of a main module in one embodiment.

[0102] 1. Item Registration Step

[0103] The item trading system can handle API gateways. The item trading system can receive registration requests from users or providers of digital objects and items. The item trading system can validate API keys and check the validity of request formats. The item trading system can process requests by normalizing them through GraphQL endpoints. The item trading system can forward request data to the Core Service Layer.

[0104] The item trading system can verify basic validity. The item trading system can check for the existence of required fields (e.g., item ID, metadata, owner information, etc.). The item trading system can verify whether the format of digital item metadata matches a defined schema. The item trading system can prevent duplicate registrations by checking for duplicate entries. The item trading system can perform basic verification regarding registration authority.

[0105] 2. Item Verification Step

[0106] The item trading system can verify Zero-Knowledge Proofs (ZKPs). The item trading system can generate Zero-Knowledge Proofs regarding item ownership. The item trading system can verify the generated proofs through a verification contract. The item trading system can record the verification results on the blockchain and issue events. The item trading system can enable proof of ownership while protecting privacy.

[0107] The item trading system can verify Oracle data. The item trading system can request external data through the Oracle network. The item trading system verifies the reliability of the received data and can update the smart contract with the verified data. The item trading system can reflect real-time price information and market data in the updated smart contract.

[0108] 3. Trade Creation Phase

[0109] The item trading system can deploy smart contracts. The item trading system can create state-based trading contracts. The item trading system can set trading conditions and constraints in the contract. The item trading system can generate contract addresses and store related information. The item trading system can notify trading participants of contract information.

[0110] The item trading system can initialize the state. The item trading system can set the initial state of a trade. The item trading system can define the roles and permissions of participants. The item trading system can set timelines and expiration conditions. The item trading system can issue an initialization completion event.

[0111] 4. Escrow Process Step

[0112] The item trading system can verify amounts. The item trading system can verify the buyer's payment amount. The item trading system can verify the validity of amounts. The item trading system can process transfers to escrow accounts. The item trading system can set the amount lock status.

[0113] The item trading system can execute escrow contracts. The item trading system can activate escrow smart contracts. The item trading system can set multi-signature conditions. The item trading system can define transaction cancellation and refund conditions. The item trading system can monitor the escrow status.

[0114] 5. State Update Phase (StateUpdate)

[0115] The item trading system can issue state change events. The item trading system can check the current trading status. The item trading system can verify whether the state change conditions are met. The item trading system can execute a transition to a new state. The item trading system can generate and issue state change events.

[0116] The item trading system can perform real-time updates. The item trading system can notify of state changes via WebSocket. The item trading system can send state change notifications to participants. The item trading system can synchronize the state of related systems. The item trading system can process final settlements after a transaction is completed.

[0117] The item trading system can synchronize data. The item trading system can query the latest state of the blockchain. The item trading system can update the off-chain database. The item trading system synchronizes with the systems of digital object and item suppliers, and can confirm the final state after synchronization is complete.

[0118] FIG. 10 is a diagram illustrating a state-based transaction management module in one embodiment.

[0119] The State Based Trading Module may include a State Controller, a Trade Executor, and an Event Manager.

[0120] The state controller is a core module that manages and controls state transitions throughout the entire lifecycle of a transaction. It can be implemented by combining Ethereum smart contracts with state machines. The state controller can verify and execute transition conditions between states and manage history. It can support state transitions based on external data by integrating with an oracle system. The state controller can handle exceptional situations through a rollback mechanism.

[0121] A transaction executor is an execution engine that handles all processes related to actual transaction execution. Transaction executors can be implemented based on EVM-compatible smart contracts. Transaction executors can handle multisig-based transaction approval and execution. Transaction executors can process financial transactions by integrating with payment systems. Transaction executors can perform transaction management to guarantee atomicity.

[0122] The event manager can generate all transaction-related events and deliver them to subscribers. The event manager can utilize event streaming and WebSocket protocols. The event manager can perform real-time event processing and subscriber management. The event manager can support event synchronization with external systems. The event manager can implement a retry mechanism to prevent event loss.

[0123] The Hybrid Verification Module may include a Zero-Knowledge Proof Processor (ZKP Processor), an Oracle Validator, and a Metadata Manager.

[0124] Zero-knowledge proof processors can verify the authenticity of digital items while protecting privacy. Zero-knowledge proof processors can perform verification by implementing the zk-SNARKs protocol. Zero-knowledge proof processors can separate the processing of proof generation and verification. Zero-knowledge proof processors can perform on-chain verification by integrating with smart contracts. Zero-knowledge proof processors can guarantee security based on mathematical proofs.

[0125] The Oracle Validator can verify the reliability of external data and reflect it in the system. The Oracle Validator can utilize an Oracle network based on the Chainlink Protocol. The Oracle Validator can aggregate and verify results from multiple data sources. The Oracle Validator can integrate real-time price information and metadata. The Oracle Validator can implement a data integrity verification mechanism.

[0126] The metadata manager can manage and validate the metadata of digital items. The metadata manager can utilize distributed storage integrated with IPFS. The metadata manager can manage the storage, validation, and updating of metadata. The metadata manager can support data synchronization with content providers. The metadata manager can perform checksum-based data validation.

[0127] The API Gateway Module may include a Request Router, an Auth Manager, and a Response Handler.

[0128] The request router can route client requests to the appropriate service. The request router can support the integration of GraphQL and REST APIs. The request router can perform dynamic routing based on request types. The request router can support load balancing and service discovery. The request router can manage failures by implementing the circuit breaker pattern.

[0129] The authentication manager can perform authentication and authorization management for API requests. The request router can implement a JWT-based token management system. The request router can perform request-specific authorization verification and token management. The request router can support identity verification by integrating with a DID system. The request router can implement token renewal and revocation mechanisms.

[0130] Response handlers can convert API responses into a standardized format and deliver them. Response handlers can use JSON-LD-based data formats. Response handlers can handle the transformation and caching of response data. Response handlers can support real-time data streaming. Response handlers can verify the integrity of response data.

[0131] A State Controller may include a State Manager, a State Validator, a State Transition Engine, and a State History Manager.

[0132] The state manager can comprehensively manage the creation, retrieval, updating, and deletion of transaction states. The state manager can perform primary validation of state transition requests. The state manager can guarantee the persistence of state information and manage caching. The state manager can handle state synchronization in a multi-chain environment. The state manager can provide a resolution mechanism in the event of state inconsistencies.

[0133] The state validator can implement a rule engine that validates the validity of state transitions. The state validator can determine whether a state transition is possible based on business logic. The state validator can execute validation logic based on external data. The state validator can manage the history of validation results. The state validator can provide a rollback process for failed validations.

[0134] The state transition engine can actually execute verified state transitions. The state transition engine can handle state transitions with guaranteed atomicity. The state transition engine can generate events that occur during state transitions. The state transition engine can execute a compensation transaction in the event of a transition failure. The state transition engine can manage the transaction log of state transitions.

[0135] The status history manager can record and manage the history of all status changes. The status history manager can support audit trails of status changes. The status history manager can provide point-in-time status lookup capabilities. The status history manager can handle the archiving of historical data. The status history manager can manage snapshots for status recovery.

[0136] A trade executor may include a trade controller, a transaction lock manager, a trade processor, and a transaction recovery unit.

[0137] The transaction controller can coordinate the entire process of transaction execution. The transaction controller can verify the authority of transaction participants. The transaction controller can check whether transaction conditions are met. The transaction controller can manage the priority of transaction execution. The transaction controller can handle transaction cancellations and rollbacks.

[0138] A transaction lock manager can manage locks for concurrency control. A transaction lock manager can implement deadlock prevention algorithms. A transaction lock manager can handle timeout-based lock releases. A transaction lock manager can provide monitoring of lock states. A transaction lock manager can implement a forced lock release mechanism.

[0139] The transaction processor can handle the actual execution of transactions. The transaction processor can perform amount settlement and fee calculation. The transaction processor can complete transactions by integrating with escrow contracts. The transaction processor can record the results of transaction executions. The transaction processor can collect execution performance metrics.

[0140] The transaction recovery unit can manage the recovery of failed transactions. The transaction recovery unit can handle the cleanup of partially completed transactions. The transaction recovery unit can manage the priority of the recovery process. The transaction recovery unit can log recovery operations. The transaction recovery unit can identify cases requiring manual intervention.

[0141] An Event Manager may include an Event Emitter, an Event Subscriber, an Event Queue, and an Event Processor.

[0142] The event generator can generate and publish system events. The event generator can set event priorities. The event generator can add event metadata. The event generator can perform event filtering. The event generator can handle event versioning.

[0143] Event subscribers can perform event subscription management. Event subscribers can handle subscriber authentication. Event subscribers can track event delivery status. Event subscribers can manage retry policies. Event subscribers can handle subscription expiration.

[0144] An event queue can buffer event messages. An event queue can manage message priorities. An event queue can monitor queue size. An event queue can handle message expiration. An event queue can manage queue backups.

[0145] An event processor can execute event processing logic. An event processor can perform event transformation. An event processor can log processing results. An event processor can perform error handling. An event processor can monitor processing performance.

[0146] FIG. 11 is a diagram illustrating the process of a core system in one embodiment.

[0147] In the embodiments, data transmission and reception operations between the client / SDK, API gateway, state controller, transaction executor, verification module, blockchain, and oracle network will be described.

[0148] 1. Transaction Initialization Phase

[0149] A client can request the API gateway to create a transaction using the digital item ID, transaction conditions, and participant information. The API gateway can output a validated transaction request object through request validation and routing. In this case, the processing time is within a maximum of 1 second.

[0150] The API Gateway can initialize the transaction state. The API Gateway can output a transaction state object by performing initial transaction state creation and validation using a validated transaction request object. The API Gateway can initialize state information. The state controller can validate the initial state based on the transaction state initialization. The state controller can request item validation from the validation module.

[0151] 2. Verification Process

[0152] The verification module can execute parallel verification. Through on-chain data verification, the verification module can confirm ownership, verify previous transaction history, and check smart contract status. Through off-chain data verification, the verification module can verify real-time price information using an oracle network, verify item metadata, and check the status of integration with external systems.

[0153] The verification module can make a final decision by integrating the verification results using the results of each verification process. The verification module can output an integrated verification result object. In this case, the status information will be VERIFIED or VERIFICATION_FAILED. The verification module can return the verification result to the status controller.

[0154] 3. Transaction Execution Phase

[0155] The state controller may request the execution of a transaction based on the verification result returned to the transaction executor. The transaction executor may verify the transaction conditions. Using the verified transaction information, the transaction executor may check the participant balances, verify transaction constraints, and calculate fees to output a result determining whether execution is feasible.

[0156] The transaction executor can execute the smart contract upon successful verification of transaction conditions. Using the verified transaction information, the transaction executor can deploy the escrow contract, set a token lock, and execute a state-change transaction, thereby outputting the transaction hash and execution result. Based on the execution result, the transaction executor can establish escrow. If the transaction condition verification fails, the state controller can roll back the state.

[0157] 4. State Management and Event Handling

[0158] The state controller can update state information based on the transaction execution results. The state controller can output updated state information by using the transaction execution results to update the state database, generate history records, and update participant information.

[0159] The state controller can process events. The state controller can forward creation events, including state change events, notification events, and audit log events, to real-time WebSocket events, blockchain event logs, and internal system events.

[0160] 5. Exception Handling Process

[0161] The state controller can handle validation failures. The state controller can execute a rollback process, log the cause of the failure, notify participants, and clean up resources.

[0162] The transaction executor can release escrow, restore the state, log errors, and execute a compensation transaction upon handling a transaction failure.

[0163] FIG. 12 is a diagram illustrating the operation of linking game service item minting in one embodiment.

[0164] 1. Initial Integration Setup Steps

[0165] Game services can request service integration through the API Gateway. The API Gateway can issue API keys, set access permissions, and configure the integration environment using game service information, service authentication information, and technical specifications, and then output API keys, webhook URLs, and developer guides. The API can transmit integration information to the game service.

[0166] The game service may request item schema registration through the API Gateway. The API Gateway may verify the schema for validity, existence of required fields, and data type consistency using a schema configuration that includes item basic attributes, in-game attribute information, tradability, and rarity information, and store the verified schema in the minting service. The minting service may store the verified schema in the data repository. The minting service may return the schema ID to the API Gateway. The API Gateway may notify the game service that schema registration has been completed.

[0167] 2. Item Minting Process

[0168] Game services can request item minting through the API Gateway. The API Gateway can perform verification processes, such as verifying item existence, ownership, and schema compliance, using item identifiers, metadata, owner information, and issuance quantities.

[0169] The minting service can issue tokens. The minting service can prepare a smart contract, store metadata in IPFS, execute token issuance, and assign a token ID. In this case, the integration information consists of the token ID, contract address, and transaction hash.

[0170] 3. State Synchronization Process

[0171] Game services can synchronize. Game services can synchronize token issuance status, ownership information, and item status through real-time webhooks, batch synchronization, and state verification.

[0172] The minting system can monitor the minting progress status, transaction status, and error occurrence status of the game service. The minting system can set notifications such as status change alerts, error occurrence alerts, and completion alerts.

[0173] 4. Error Handling and Recovery

[0174] The minting system can detect errors such as API communication errors, blockchain transaction failures, and data synchronization errors. The minting system can respond to errors through automatic retries, manual intervention notifications, and rollback processes.

[0175] The minting system can manage data consistency, such as game-blockchain state alignment, token-item mapping accuracy, and ownership information consistency, through periodic verification, inconsistency detection, and automatic recovery processing.

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

[0177] 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 instruct the processing unit independently or collectively. Software and / or data may be embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and may be stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0178] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

[0179] Although the embodiments have been described above with reference to limited examples and drawings, those skilled in the art can make various modifications and variations from the description above. For example, suitable results can be achieved even if the described techniques are performed in a different order than described, and / or the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

[0180] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims set forth below.

Claims

Claim 1 A digital item trading method performed by an item trading system, comprising: a step of obtaining a verification result through data verification of the digital item in accordance with a buyer's request to trade the digital item; a step of executing a state-based smart contract by verifying transaction conditions for executing the transaction of the digital item based on the obtained verification result; and a step of trading the digital item through escrow processing using the executed state-based smart contract. Claim 2 A digital item trading method according to claim 1, wherein the acquiring step comprises receiving a digital item trading request from a buyer including the ID, metadata, trading conditions, and owner information of the digital item, and initializing the trading status of the received digital item. Claim 3 A digital item trading method according to paragraph 2, wherein the acquiring step comprises verifying a zero-knowledge proof of ownership of the digital item in an on-chain or off-chain manner. Claim 4 A digital item trading method according to paragraph 2, wherein the acquiring step comprises the step of verifying external data through an oracle network to reflect market data including real-time price information in the digital item. Claim 5 A digital item trading method according to claim 1, wherein the executing step comprises setting transaction conditions and constraints in the state-based smart contract and notifying the buyer of the set state-based smart contract. Claim 6 A digital item trading method according to claim 1, wherein the step of trading comprises verifying the buyer's payment amount through the executed state-based smart contract, processing the transfer of the verified payment amount to an escrow account, and setting the transferred payment amount to a locked state. Claim 7 A digital item trading method according to claim 6, wherein the trading step comprises the step of approving the buyer through multi-signature verification in accordance with the execution of the escrow agreement, and unlocking the payment amount set to the locked state and delivering it to the seller. Claim 8 A digital item trading method according to claim 7, wherein the trading step comprises the step of setting conditions for the cancellation and refund of a digital item transaction and monitoring the status of the execution of the escrow contract according to the set conditions for the cancellation and refund of a digital item transaction. Claim 9 A digital item trading method according to claim 1, further comprising the step of linking a digital object and item provider with a minting system. Claim 10 In claim 9, the above-mentioned linking step comprises a digital item trading method including the step of registering a digital item in a minting system in response to a minting request by a digital object and item supplier. Claim 11 A digital item trading method according to claim 10, wherein the above-mentioned linking step includes the step of registering a schema in the above-mentioned minting system in accordance with a request to register a schema of the digital item, and confirming the existence of an item within the service by verifying whether the registered schema matches through item verification of the digital item in accordance with an item minting request. Claim 12 A digital item trading method according to claim 11, wherein the interlocking step comprises the step of storing metadata of the digital item upon confirming whether an item exists within the service, executing a state-based smart contract upon a request for token issuance of the digital item, and issuing token information based on the executed state-based smart contract. Claim 13 A digital item trading method according to claim 12, wherein the above-mentioned linking step includes the step of completing minting by updating state information within the service based on the above-mentioned issued token information. Claim 14 An item trading system comprising at least one processor configured to execute computer-readable instructions contained in memory, wherein the at least one processor obtains a verification result through data verification of the digital item in response to a buyer's request to trade the digital item, verifies transaction conditions for executing the transaction of the digital item based on the obtained verification result and executes a state-based smart contract, and trades the digital item through escrow processing using the executed state-based smart contract.

Images