Method and system for divisible non-fungible tokens in a multiple distributed ledger system

Abstract

To provide methods for splittable non-fungible tokens (NFTs) with cross-ledger ability in a multiple distributed ledger system.SOLUTION: A method comprises the steps of: identifying, from a source distributed ledger where an NFT is originally exists, a source NFT having source NFT information comprising a splitting rule and a genesis NFT identifier; locking or deleting, by a locking transaction, the source NFT in the source distributed ledger; and unlocking or minting, by a completing transaction, a target NFT corresponding to the source NFT in the target distributed ledger of a recipient of the NFT. The target NFT may also comprise the source NFT information to enable splitting or merging of the target NFT in the target distributed ledger.SELECTED DRAWING: None

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 484,742, filed February 13, 2023, entitled "A SPLITTABLE SELF-EVOLVED NFT TOKEN AND METHODS THEREOF," which is incorporated herein by reference in its entirety.

[0002] The present invention relates to a method and system for providing divisible non-fungible tokens (NFTs) with cross-ledger capabilities in a multiple distributed ledger system. [Background technology]

[0003] A distributed ledger is a consensus of replicated, shared, synchronized digital data that is geographically spread (distributed) across many sites. A distributed ledger does not require a central authority and, as a result, there is no single (significant) point of failure. The most common form of distributed ledger technology is the blockchain, which is a distributed ledger with a growing list of records securely linked together via cryptographic hashes. Each block in a blockchain contains a cryptographic hash of the previous block, a timestamp, and transaction data. Due to the sequential nature of blockchain, blockchain transactions are irreversible in that, once recorded, the data in any given block cannot be retroactively modified without modifying all subsequent blocks.

[0004] Both fungible and non-fungible tokens may be issued and recorded on the distributed ledger based on the ledger's configuration. Fungible tokens are divisible, non-unique digital assets. Non-fungible tokens (NFTs), on the other hand, are unique digital identifiers that are recorded on the blockchain and used to verify ownership and authenticity. NFTs generally cannot be copied, substituted, or subdivided. Ownership of NFTs is recorded within the blockchain and can be transferred by the owner, allowing NFTs to be sold and exchanged. NFTs typically contain references to digital files such as artwork, photographs, videos, and audio. NFTs differ from cryptocurrencies, which are fungible, because they are uniquely identifiable. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] U.S. Provisional Patent Application No. 63 / 484,742 [Patent Document 2] International Publication No. 2019 / 125506 Summary of the Invention [Problem to be solved by the invention]

[0006] The uniqueness and non-fungible nature of every single NFT has driven NFT prices to astonishingly high values ​​in some highly acclaimed projects. This effectively makes these highly prized NFTs unavailable to the general public, as NFTs can typically only be purchased and owned on the blockchain as a whole. [Means for solving the problem]

[0007] Provided herein are methods for divisible non-fungible tokens (NFTs), particularly for divisible NFTs with cross-ledger capabilities in a multiple distributed ledger system.

[0008] A method for transferring a divisible non-fungible token (NFT) from a source distributed ledger to a target distributed ledger different from the source distributed ledger, the method comprising: identifying a source NFT from the source distributed ledger having source NFT information comprising a division rule and an origin NFT identifier; locking or deleting the source NFT in the source distributed ledger through a lock transaction; and unlocking or minting a target NFT corresponding to the source NFT in the target distributed ledger through a completion transaction. The target NFT may comprise source NFT information that enables the target NFT to be split or merged in the target distributed ledger.

[0009] In one embodiment, before locking or deleting the source NFT with the lock transaction, the method further comprises generating and submitting a begin transaction comprising the target NFT for committing to the target distributed ledger, and generating and submitting a lock transaction for committing to the source distributed ledger. And before unlocking or minting the target NFT with the completion transaction, the method further comprises verifying the existence of the begin transaction by referencing the begin transaction in the target distributed ledger with the lock transaction, and generating and submitting a completion transaction for committing to the target distributed ledger.

[0010] In one embodiment, splitting the target NFT includes locking or deleting the target NFT on the target distributed ledger after receiving a split request that conforms to the split rule, and generating multiple split NFTs, each having split NFT information that includes at least a portion of the source NFT information, based on the origin NFT identifier and the split request. The split NFT information for each of the multiple split NFTs may include the split rule and the origin NFT identifier.

[0011] In one embodiment, merging the target NFT comprises receiving a merge request to merge the target NFT with one or more sibling NFTs that have the same origin NFT identifier and the same owner as the target NFT, locking or deleting the target NFT and the one or more sibling NFTs in the target distributed ledger, and generating a merged NFT having merged NFT information comprising at least a portion of the source NFT information. In this embodiment, the merged NFT information may comprise a split rule and an origin NFT identifier.

[0012] In one embodiment, both the source NFT and the target NFT refer to an origin NFT having an origin NFT identifier and a division rule, where the origin NFT is the first minted NFT among all NFTs having the origin NFT identifier. The source NFT may be the origin NFT, or it is also possible that neither the source NFT nor the target NFT is an origin NFT. In a specific embodiment, the origin NFT identifier is the token ID of the origin NFT. In a specific embodiment, the division rule determines the minimum division unit of the origin NFT. The minimum division unit may be determined by a horizontal segmentation number and a vertical segmentation number. The division rule may also include a division number that determines the maximum number of times the origin NFT can be divided.

[0013] In one embodiment, the origin NFT is configured to be divided into multiple child NFTs based on a division rule, each of the multiple child NFTs comprising one or more minimum division units of the origin NFT. The metadata of the origin NFT may comprise an origin image, and the metadata of each of the multiple child NFTs comprises a child image representing a portion of the origin image.

[0014] In one embodiment, a lock transaction locks a source NFT in a smart contract to transfer a divisible NFT from a source distributed ledger to a target distributed ledger. The locked source NFT is unlocked only after an external distributed ledger request transfers an external NFT corresponding to the source NFT from the external distributed ledger to the source distributed ledger. The external distributed ledger may be the same as the target distributed ledger or may be different from the distributed ledger.

[0015] In one embodiment, a three-transaction cross-ledger transfer is performed. These transactions include an initiating transaction on the target distributed ledger, a locking transaction on the source distributed ledger, and a completing transaction on the target distributed ledger. In a particular embodiment, the target NFT created in the initiating transaction can be transferred by the completing transaction only if the completing transaction references the locking transaction and if the target NFT information of the target NFT in the initiating transaction matches the source NFT information of the source NFT identified in the source distributed ledger. In this implementation, the completing transaction may use a Merkle tree reference that references the locking transaction.

[0016] In a specific embodiment for performing a three-transaction cross-ledger transfer, the method is performed by a node stack of a source distributed ledger, where the initiating transaction and the completed transaction are submitted to a node stack of a target distributed ledger, which further submits the initiating transaction and the completed transaction to the target distributed ledger.

[0017] In a specific embodiment for performing a three-transaction cross-ledger transfer, the method is performed by a node stack of a target distributed ledger, where the lock transaction is submitted to a node stack of a source distributed ledger, which further submits the lock transaction to the source distributed ledger.

[0018] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description when considered in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0019] [Figure 1] 1 illustrates the function of smart contracts in the present invention. [Figure 2] This shows the splitting and merging of a series of NFTs derived from the origin NFT. [Figure 3] Indicates that the minted NFT may be split or deleted in the future. [Figure 4] Indicates that the parent NFT, NFT.CD, is split into two child NFTs, NFT.C and NFT.D. NFT.C and NFT.D are created and the status of NFT.CD is changed to "Split." [Figure 5] Indicates that two NFTs, NFT.A and NFT.B, are merged into a merged NFT, NFT.AB. NFT.AB is created and the status of NFT.A and NFT.B is changed to "Merged." [Figure 6] 1 shows the data schema of an NFT in the present invention. [Figure 7] 1 shows the data schema of an NFT in the present invention with blockchain memory as another part of the on-chain data. [Figure 8A] Showing an example of an NFT linked to a museum art object, showing the origin NFT split into three child NFTs. [Figure 8B] Figure 8A shows an example of an NFT linked to a museum artwork, showing two of the three child NFTs in Figure 8A being merged together to form a merged NFT. [Figure 9] An example of data stored on a blockchain is shown below. The data comprises three parts: blockchain data, blockchain memory, and off-chain data. [Figure 10A]8B shows the data of the NFT to be split and the three created child NFTs. FIG. 8C shows the data changes of the origin NFT of FIG. 8A after splitting and deactivation. [Figure 10B] 8A shows the data of the NFT to be split and the three generated child NFTs. [Figure 10C] 8A shows the data of the NFT to be split and the three generated child NFTs. [Figure 10D] 8A shows the data of the NFT to be split and the three generated child NFTs. [Figure 11A] 8A shows the two NFTs to be merged and the data of the merged NFT. FIG. 8B shows the data changes of the two NFTs to be merged after merging. [Figure 11B] 8A shows the two NFTs to be merged and the data of the merged NFT. FIG. 8B shows the data changes of the two NFTs to be merged after merging. [Figure 11C] 8A and 8B show data for the two NFTs being merged and the merged NFT. [Figure 12A] 8A illustrates data changes in an NFT lease for the NFT at index 2 in FIG. 8A after the lease has been initiated and canceled. [Figure 12B] Showing data changes for an NFT after a lease is initiated and then cancelled. Showing data changes when a lease is cancelled. [Figure 13] The function calls implemented in the examples shown in Figures 8 to 12 are shown below. The ERC721 functions are listed below. [Figure 14] The function calls implemented in the examples shown in Figures 8 to 12 are shown below. The customized functions are described below. [Figure 15] We demonstrate a three-transaction cross-ledger transfer method that prevents double spending. [Figure 16] We present a system architecture that embeds external payment verification (PV) nodes into a distributed ledger network. [Figure 17] Although not every node is a shared node, a system architecture utilizing a set of shared complete nodes is shown. DETAILED DESCRIPTION OF THE INVENTION

[0020] The terminology used in the description provided below is intended to be interpreted in its broadest reasonable manner, even when used in connection with detailed descriptions of certain specific embodiments of the present technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restrictive manner is specifically defined as such in this "Detailed Description" section.

[0021] The embodiments described below may be implemented with programmable circuitry that is programmed or configured by software and / or firmware, or with entirely special purpose circuitry, or with a combination of these forms, which (if any) may take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), graphics processing units (GPUs), etc.

[0022] The present application relates to a method for divisible non-fungible tokens (NFTs), particularly suitable for divisible NFTs with cross-ledger capabilities in a multiple distributed ledger system.

[0023] Divisible NFTs The following provides a genuine self-developing NFT with new functionality. "Authentic" means that an NFT may be tied to some physical or virtual asset and that an authority exists that can determine the authenticity between the NFT and the asset. "Self-evolving" means that each NFT can generate a series of next-generation NFTs, each of which inherits some of the characteristics, attributes, and privileges of the first NFT. Furthermore, operations between NFTs of the same / different generations are eligible to support various blockchain-based operations and functions. These actions may include new features such as NFT leasing. The entire history of creation and operation is recorded in a distributed manner due to the nature of the blockchain. The lifecycle of an NFT is faithfully written into a distributed ledger.

[0024] In one example, museum artworks could be minted into NFTs. Museums will obviously have the ability to specify authenticity when duplicate NFTs occur. An NFT representing a work of art may be designed to be digitally divisible into several pieces, each of which inherits certain properties from the original NFT, such as the ability to be given away, rented, borrowed, or divided into more NFTs. In contrast to splitting, a merge operation may also be provided to create a new NFT from two or more existing NFTs derived from the same initial NFT. All functions, including splitting and merging, are implemented as unique transactions via the blockchain platform. Due to the nature of the blockchain environment, NFTs will develop into a rich transaction history.

[0025] This NFT platform will be designed with the following features: (1) property owners (e.g., museums) will be able to issue NFTs based on their assets after proving ownership; (2) several platform-wide features will be attached to minted NFTs, such as token minting, transfer, deletion, division, merging, leasing, revocation, and return; and (3) trading of NFTs can be governed by different trading models, such as transfer, buy / sell, or leasing. The above functionality is implemented on a decentralized ledger (blockchain) that may be supported by smart contracts deployed on the decentralized ledger. A smart contract is a piece of software deployed on a decentralized ledger whose state is not synchronized but distributed. Smart contracts on an NFT platform may implement NFT-related functionality, such as functionality described in the ERC-721 standard. In addition, smart contracts may implement some customized functions to provide special features such as division / merger functionality and leasing functionality.

[0026] In one example, three types of participants are registered in the system: (1) Admin, (2) User, and (3) Smart Contract. Preferably, the system is implemented on a private blockchain, a decentralized distributed ledger operated by a single entity or group of parties that can control access to the network.

[0027] In this system, the administrator refers to the system builder and maintainer. Besides building and maintaining the system (including smart contracts), the administrator's main responsibility is membership management, allowing or denying new members to register.

[0028] The user is the primary participant in this system. User participation in the system is controlled by an administrator. Users may interact with other users or smart contracts.

[0029] A smart contract is an immutable segment of code that is deployed by an administrator. Once deployed, blockchain nodes faithfully execute smart contract code in a distributed manner. Due to the nature of distributed ledgers, these deployed smart contracts cannot be modified or revoked, even by the administrators themselves. This immutability allows users to trust and interact with these smart contracts to handle their digital assets as synchronized, immutable, and sustainable assets. The function of smart contracts in this system is shown in Figure 1. Smart contracts are developed and implemented by administrators. In one embodiment, an ERC721 contract with additional customized functionality is introduced.

[0030] Smart contract functionality As described above, smart contracts that allow for splitting and merging NFTs have both ERC721 functionality and customized functionality. Functions according to the ERC721 standard include creating, transferring, or deleting tokens. Customized features include splitting and merging tokens.

[0031] In token generation (or the "Mint" feature), a user inputs details of a digital asset into the system, and the smart contract then returns an NFT token that corresponds to a real asset owned by the user (for example, a piece of art owned by a museum). To provide authenticity, there must be an entity that controls the issuance of new NFTs. In one embodiment, users send API calls to an administrator, who implements membership management that allows some specific users (e.g., museums) to mint and decline other general users. For these approved users, the administrator forwards mint queries to the blockchain. The initial owner of a minted NFT token is the user. The newly minted NFT token is called the "Provenance NFT."

[0032] Once minted, owners may transfer their NFTs to other users directly or indirectly with the help of smart contracts using the "Transfer" feature. Furthermore, a minted NFT may be deleted at the end of its lifecycle via a "Burn" function. This may be done somewhat based on smart contract settings or updated smart contracts.

[0033] Besides the ERC721 standard, it also specifies some customized smart contract functions such as "Split" and "Merge" to operate digital assets in this system. The "Split" function is configured to split a digital asset into several segments. The split child assets in the form of child NFTs will initially belong to the same owner as the parent NFT.

[0034] The "Merge" function is configured to merge several digital assets (NFTs) into a single merged digital asset (Merged NFT) when a user collects several segments split from the same origin NFT.

[0035] With the help of these actions, every NFT becomes a self-evolving digital asset that continues to generate child NFTs during its lifecycle. The entire lifecycle of an NFT token is faithfully recorded within a distributed ledger. The attributes and privileges of the parent NFT are intuitively inherited by creating a new child NFT, as shown in Figure 2.

[0036] Token Lifecycle The lifecycle of an NFT may begin with the Mint, Split, or Merge functions, which are exemplified in more detail below.

[0037] (1) Minting NFTs from metadata In this step, a “Provenance NFT” is generated. A Provenance NFT is created from the minting step without any preceding splitting or merging steps. This is the common case where an NFT is obtained from a minting process run by a minter / user. Minted NFTs may be further divided or deleted in the future if desired or necessary, as shown in Figure 3.

[0038] (2) Splitting the NFT into new NFTs An NFT may be split into several different parts that are also NFTs. For example, taking the flow diagram in Figure 4, the following events occur as NFT.CD splits into NFT.C and NFT.D: (a) NFT.CD ends in the Split state, and (b) two child NFTs, NFT.C and NFT.D, are created.

[0039] (3) Merge NFTs into new NFTs An NFT may be created by merging several NFTs if these NFTs can be traced back to the same origin NFT. For example, taking the flow diagram in Figure 5, as NFT.A and NFT.B are merged into NFT.AB, the following events occur: (a) NFT.A and NFT.B end up in the Merged state, and (b) a new NFT, NFT.AB, is created.

[0040] Different NFT division rules may be applied to the generated NFTs. This may include, but is not limited to, rules that allow an NFT to be divided only once, or rules that only allow an NFT to be divided into pieces of a specific size. The division rules that apply to the generated NFTs are determined by the smart contract that generates the NFT and cannot be changed during the NFT's lifecycle. Similarly, the rules for merging NFTs are also determined by the smart contract.

[0041] Several methods are used to "terminate" NFTs during splits or merges. In one embodiment, the terminated NFT is deleted, but some token-related information is retained in the split or merged NFT. In this embodiment, each time a split operation is performed, the first NFT to be split is deleted and the multiple split NFTs are minted, and each time a merge operation is performed, the first NFT to be merged together is deleted and a merged NFT representing the merged portion is minted.

[0042] In another embodiment, the terminated NFT is locked in a smart contract until the conditions to unlock the NFT are met. In this embodiment, each time a split operation is performed, the first NFT to be split is locked and multiple split NFTs are minted or unlocked based on the availability of such NFTs on the split ledger, and each time a merge operation is performed, the first NFTs to be merged together are all locked and a merged NFT representing the merged portions is minted or unlocked based on the availability of the merged NFT on the distributed ledger. During locking, the NFT may be transferred to the contract address of the smart contract, and the locked NFT may be transferred to the user's standard account after unlocking.

[0043] In an alternative embodiment, an NFT may also be "terminated" by recording its status as locked or inactive in the NFT's metadata, rather than by locking or deleting the token itself.

[0044] Ownership Management In this system, a method for leasing digital assets between users may also be adopted for better asset utilization. The lease agreement comprises a digital asset, an expiration date, and an action upon expiration, which may be one of auto-renew, return, and cancellation.

[0045] Compared to "Transfer", the "Lease" function is a relatively sophisticated operation that takes into account the assistance of smart contracts. The "Lease" operation involves the collaboration of three parties: the lessee, the lessor, and the smart contract. The NFT owner (the lessee) makes a request to the smart contract, providing the NFT token ID, the lessor's address, the expiration period, and the actions to be taken when the period expires. Simply put, the command means that the owner is lending the NFT token to a lessee until an expiration date, during which time the smart contract will execute one or more associated actions.

[0046] The first example of an action during expiration is "Auto-renewal." This feature may auto-renew the rental relationship during the expiration of the NFT token if some conditions are in effect, such as those agreed to by both parties or more flexible terms stipulated and overseen by a smart contract.

[0047] A second example of an expired action is "Return." This function may lead to the termination of the lease relationship while the lease relationship has expired. Generally, this may be the default action when the deadline expires.

[0048] A third example of an expired action is "Revoke." This function may terminate the lease relationship before the expiration date if some provisions are found to be violated. The terms and conditions of business while entering the system may list and detail the relevant rules. In addition to automatic revocation, an authorized third party (e.g., an administrator) may also take action to determine whether a provision has been violated and whether revocation action should be taken.

[0049] If an NFT is available for lending, the user may manage the NFT through a lease agreement. A "holder" is the party that currently controls the NFT, whether that party owns the NFT or leases the NFT. In contrast, an "owner" owns an NFT by minting a new NFT or receiving an NFT from another person (rather than receiving an NFT by leasing it). Thus, the owner may retain all rights to operate the NFT based on pre-defined rules (called "privileges"), while the owner's privileges may be more or less restricted.

[0050] Privilege and its amendment The "privileges" are defined in the rules during activities such as minting, division, annexation, or leasing. Examples of rules and regulations include, but are not limited to: Privileges are usually defined as rules and are initially set during minting. Privileges may be verified before executing smart contract functions. Once the privileges are verified, the user may be allowed to invoke smart contract functions and add additional constraints to the privileges for further use.

[0051] For the "Split" function, the rules may include: (a) not divisible, (b) divisible only once, or (c) divisible more than once. In the "Merge" function, the rules may be that (a) NFTs are allowed to be merged together if they originated from the same origin NFT, and (b) NFTs are only allowed to be merged together if they were split from the same parent NFT (i.e., have the same parent in the immediately preceding generation). In the "Lease" function, the rules may include: (a) available for lease, and (b) not available for lease.

[0052] Generally, the rules become stricter as the generation of NFTs increases. In a split-and-lease operation, the new NFT inherits privileges from its parent NFT unless otherwise specified. The privileges, when specified along with the function call, may only be stricter than the privileges of the parent NFT. For example, a parent NFT that is not allowed to be rented cannot be split into child NFTs that can be rented. In a merger, the authority is equal to or less than the authority of the closest (smallest generation difference) NFT encompassing the same segment portion.

[0053] For better understanding, some examples are provided below. Assume that an NFT called NFT.AB is owned by a user called Alice and is initially divisible.

[0054] In Case 1, Alice splits NFT.AB into NFT.A and NFT.B, while disabling the divisible properties of NFT.A and NFT.B so that neither NFT.A nor NFT.B can be further divided.

[0055] In Case 2, Alice rents NFT.AB to Bob. In a first embodiment, Alice does not allow Bob to take further action, revoking all privileges including leasing, dividing, and merging. In the second embodiment, Alice does not restrict Bob's actions, but the NFT must be returned as originally intended (not split, leased, or merged with other NFTs). The redemption process is carried out automatically by smart contract.

[0056] In Case 3, Alice merges NFT.AB and NFT.CD into NFT.ABCD (NFT.AB and NFT.CD originate from the same origin NFT). The merged NFT, ABCD, inherits privileges from the most recent NFT encompassing segments AB and CD.

[0057] Data Schema Figure 6 depicts the data schema of an NFT. The data structure comprises on-chain data and off-chain data. The on-chain data comprises "tokens," which are NFT tokens composed of tuples. A token comprises an owner, a token ID, and a URI. The "owner" part is the owner's address on the blockchain. The "owner" portion is overwritten by the smart contract during the transfer. In cases where the rental functionality is available, the "owner" portion is also overwritten by the smart contract during rental, return, and cancellation. "Token ID" is the NFT token ID generated by the smart contract. The token ID is used to differentiate NFTs across instances of smart contracts on the blockchain. Once generated, the token ID is immutable. The "URI" part represents off-chain metadata that records detailed information about the digital asset. The URI is also immutable.

[0058] With on-chain storage available, the most detailed information about digital assets is stored in off-chain databases. The connection between on-chain and off-chain data relies on URI attributes recorded in the NFT that point to off-chain metadata. On the one hand, the decoupled design allows for concise storage of on-chain data, and on the other hand, off-chain data may be flexible enough to support different data schemas in different scenarios. The off-chain data field is not required. In the specific example provided in this application, the NFT is linked to a famous museum artwork and may therefore contain some art-related information.

[0059] Figure 7 is an alternative embodiment of an NFT data schema. In this embodiment, the on-chain data further comprises a blockchain memory portion. Blockchain memory is the memory of the node that runs the blockchain program. Blockchain memory may record flexible data related to any current state, such as divisions, mergers, and leases.

[0060] Example of NFT operation on a single chain Below are some examples of how NFT data can look and be arranged: A smart contract is an executable program that runs on all blockchain nodes. NFTs are immutable data generated by smart contracts that are stored on the blockchain and considered transferable tokens of assets. However, the actual data related to NFTs is largely not recorded on the blockchain. There is a metadata URI record within the NFT that is called an off-chain storage area that stores detailed information. Along with the management of the NFT, some modifiable data is stored in the blockchain memory that remembers the current state, such as lease, separation, and merging. Finally, since space on the blockchain is quite expensive, most detailed data is recorded in an off-chain manner. Off-chain data is ideally immutable, but not required.

[0061] 8A and 8B show examples of NFTs linked to museum artworks. The newly minted genesis NFT with index number 1 is then split into three child NFTs with index numbers 2, 3, and 4. The child NFTs with index numbers 3 and 4 are then merged together to produce a merged NFT with index number 5. Figure 9 shows the data stored on the blockchain, i.e., on the blockchain memory, and the data stored off-chain when minting a new genesis NFT. FIG. 10A shows the data changes in the origin NFT (index 1) after it has been split and deactivated. The activation state and the divided child NFTs are recorded on the blockchain memory. Figures 10B, 10C, and 10D are data for child NFTs with index numbers 2, 3, and 4, respectively.

[0062] The token ID and segmentation information of the origin NFT (such as the generation number, origin NFT, maximum division, and parent NFT) are recorded in the form of off-chain data. In this example, the image of the origin NFT is segmented both horizontally and vertically. This is recorded by the horizontal and vertical segmentation numbers as shown in Figures 10B and 10C for the "partitions" of off-chain data. The two segmentation numbers determine the smallest division unit visible in the "max_part" and "min_segment" that may be generated from the origin NFT. In other words, the origin NFT is configured to be divided into multiple child NFTs based on division rules, and each of the multiple child NFTs comprises one or more minimum division units of the origin NFT. Additionally, the location of the split NFTs relative to the image of the origin NFT may be provided as coordinates shown as "Sub_Asset" in the off-chain data in Figures 10B and 10C.

[0063] The division rules may further include a division count that determines the maximum number of times the origin NFT can be divided. As shown in the off-chain data “policy” in Figures 10B and 10C, the NFT in this example is only allowed to split once.

[0064] The metadata of the origin NFT may include an origin image (in this example, an image of a museum artwork), and the metadata of each of the origin NFT's child NFTs includes a child image that represents a portion of the origin image.

[0065] 11A and 11B show data changes for NFTs with index numbers 3 and 4, respectively. The activation state and the token ID of the merged NFT are recorded on the blockchain memory. Figure 11C is data for the merged NFT with index number 5. The origin NFT token ID and segmentation information are recorded in the form of off-chain data.

[0066] FIG. 12A shows data changes for an NFT (index: 2) in an NFT lease, and FIG. 12B shows data changes when the lease is canceled. For example, when an NFT is leased to the address “764ae042539cc9780bfac21d6890f3c2c8481a7d1d4678049f718b771c4d260d,” the leaseholder and maturity date are recorded on the blockchain memory. When a revocation occurs, information related to the revocation is also recorded on the blockchain memory. In other words, the lease operation only modifies the data in the blockchain memory.

[0067] The function calls implemented in the above example are as shown in Figures 13 and 14. Figure 13 describes the ERC721 function, and Figure 14 describes the customized function.

[0068] Cross-chain features for divisible NFTs Since NFTs may persist on different distributed ledgers, a reliable method for cross-chain NFT transfer is desirable to improve the liquidity of NFT assets. With respect to cross-chain techniques, international patent application WO 2019 / 125506 describes a method for inter-ledger transfer between distributed ledgers, and is incorporated herein by reference.

[0069] Generally speaking, a cross-chain transfer involves locking an NFT on one distributed ledger and creating a corresponding NFT on another distributed ledger. The ledger where the NFT initially resides is called the "source distributed ledger," and the ledger to which the NFT is transferred is called the "target distributed ledger." To prevent double spending of an NFT, a locking and generation step is required. More specifically, this may include identifying an NFT to be transferred from a source distributed ledger (referred to as the "source NFT"), locking the source NFT in the source distributed ledger via a smart contract, and generating a corresponding NFT in the target distributed ledger (referred to as the "target NFT"). As described above, the blockchain that generates the provenance NFT is preferably a private chain in order to control which users are eligible to issue new NFTs. However, the target distributed ledger to which the source NFT is transferred may be a private chain or a public chain.

[0070] However, the above features are not sufficient for divisible NFTs to perform cross-chain operations. A divisible NFT should record an identifier uniquely linked to the origin NFT, as well as the split and merge rules for every token of every generation, so that every token derived from the same origin NFT can recognize each other and perform split / merge functions even after several split / merge / cross-chain operations. Therefore, the source NFT must contain source NFT information that records essential information that can be traced back to the origin NFT. The essential information may include division rules and a unique provenance NFT identifier. An example of a provenance NFT identifier is the token ID of the provenance NFT. The origin NFT is the first minted NFT of all NFTs with the origin NFT identifier. Therefore, the token can be traced back to the origin NFT, which is the first NFT minted.

[0071] In a cross-chain transfer, the source NFT may be deactivated using locking or deleting the NFT, and the target NFT may be generated by unlocking or minting with the help of a smart contract. The target NFT has the same split and merge capabilities as the source NFT. More specifically, the target NFT can be locked or deleted upon receiving a split request that complies with the split rules, and can generate multiple split NFTs, each having split NFT information that includes at least a portion of the source NFT information based on the origin NFT identifier and the split request. A target NFT can also be merged with other NFTs (called "sibling NFTs") that have the same origin NFT identifier on the target distributed ledger, provided that all of the sibling NFTs are owned by the same owner. The merging step should include receiving a merge request to merge the target NFT with one or more sibling NFTs, locking and deleting the target NFT and one or more sibling NFTs in the target distributed ledger, and generating a merged NFT. A merged NFT represents a larger fragment merged from all fragments of the sibling NFTs being merged, and has merged NFT information comprising the split rule and origin NFT identifier.

[0072] In one embodiment, the approach to deactivating the source NFT is to lock it instead of erasing it. This approach may comprise a lock transaction that locks the source NFT in a smart contract to transfer the divisible NFT from the source distributed ledger to the target distributed ledger, and the locked source NFT may be unlocked only after an external distributed ledger request that transfers the external NFT corresponding to the source NFT from the external distributed ledger to the source distributed ledger. In this case, the external distributed ledger may be the same as the target distributed ledger, but may also be different from the target distributed ledger. The only important thing is that the corresponding NFT that is already active is deactivated before unlocking the source NFT.

[0073] As noted above, the origin NFT is the first minted NFT of all NFTs with the origin NFT identifier. Both the source NFT and the target NFT may then reference the origin NFT, which has an origin NFT identifier and division rules. The source NFT being transferred may be the origin NFT, but may also be other than the origin NFT. For example, the source NFT may be an NFT that corresponds to an origin NFT on another chain, meaning that at least one cross-chain operation has already been performed. In another example, the source NFT may be a child NFT that represents a portion of the origin NFT, meaning that at least one split operation has already been performed.

[0074] 3-transaction cross-ledger transfer to prevent double use To further strengthen the system's ability to prevent double-spending, we provide a method for transferring digital assets between distributed ledgers, depicted in Figure 15. Cross-ledger transfers are accomplished on two or more target distributed ledgers via a series of handshakes that ensure value cannot be created from anywhere by consuming unconsumed value on the source distributed ledger.

[0075] As shown in Figure 15, a typical implementation of such a cross-ledger transfer generates and commits a series of three separate transactions to the system's distributed ledger. These transactions include an initiating transaction on the target distributed ledger, a locking transaction on the source distributed ledger, and a completing transaction on the target distributed ledger.

[0076] The first step in the method for transferring digital assets between distributed ledgers is to locate and identify unspent transaction outputs (UTXOs, in this case the source NFT) of an existing transaction 1502 in the source distributed ledger 200S. It is this UTXO in the source ledger that should be consumed in the target ledger 200T.

[0077] In the second stage of the method, an initiating transaction 1504 is created and committed to the target distributed ledger 200T. The initiating transaction 1504 creates the same digitally represented economic value (in this case, the target NFT) as the identified UTXO of the existing transaction 1502. However, according to an embodiment of the present invention, begin transaction 1504 has special properties in that its outputs cannot be consumed in the normal manner (more particularly, as discussed below, the UTXO of begin transaction 1504 can only be spent by a completed transaction 1508 that references a locking transaction 1506 that references begin transaction 1504 and consumes the identified UTXO of existing transaction 1502).

[0078] In a third stage of the method, after committing the begin transaction 1504 to the target distributed ledger 200T, a lock transaction 1506 is created and committed to the source distributed ledger 200S. The transaction input of the lock transaction 1506 is the identified UTXO of an existing transaction 1502 in the source distributed ledger 200S. Thus, the locking transaction 1506 consumes the identified UTXO of the existing transaction 1502 so that the output becomes a TXO that has been consumed (and is therefore no longer consumable) in the source distributed ledger 200S. However, by definition, the output of a locking transaction is non-consumable (i.e., the output of a locking transaction can never be consumed). In effect, lock transaction 1506 locks the identified UTXO of existing transaction 1502 so that it is never spent in the source distributed ledger 200S.

[0079] Additionally, the lock transaction 1506 references the begin transaction 1504 in the target distributed ledger 200T (e.g., by providing the entire begin transaction and hashes of the Merkle root and Merkle branch to verify the existence of the begin transaction in the target block). This "Merkle reference" from lock transaction 1506 to initiating transaction 1504 is used to prevent the value of the identified UTXO from being spent more than once.

[0080] In a fourth step of the method, after committing the lock transaction 1506 to the source distributed ledger 200S, a complete transaction 1508 is generated and committed to the target distributed ledger 200T. A valid completed transaction 1508 consumes the UTXO created by the begin transaction 1504.

[0081] To be valid, a completed transaction 1508 must reference the lock transaction 1506 that consumes the identified UTXO (e.g., by providing the entire lock transaction, as well as a hash of the Merkle root and Merkle branch, which may be used to verify the existence of the lock transaction in the source block). Because the output of the lock transaction 1506 cannot be spent, the presence of the lock transaction 1506 in the source distributed ledger 200S provides assurance that the identified UTXO has in fact expired in the source distributed ledger 200S.

[0082] No more than one completed transaction 1508 can be committed. This is because the completed transaction 1508 is valid only if it consumes the UTXO of the begin transaction 1504 referenced by the lock transaction 1506 (through the transaction input of the completed transaction 1508). Therefore, if the output that the completed transaction 1508 is consuming is not the output of the begin transaction 1504 referenced by the locking transaction 1506, the completed transaction 1508 is invalid and cannot be committed to the target distributed ledger 200T.

[0083] The transaction output, or output (one or more TXOs) of a valid completed transaction 1508, represents the completion of a cross-ledger digital representation economic value transfer to one or more recipients on the target distributed ledger 200T. One or more TXOs of the completed transaction 1508 may be successfully consumed within the target distributed ledger 200T by one or more recipients. In other words, upon committing a completed transaction to a target distributed ledger, one or more TXOs of the completed transaction may be consumed within the target distributed ledger without the need to further reference any transactions in the source distributed ledger.

[0084] 3. System architecture supporting cross-ledger transfer of transactions In a distributed ledger, a node that contains a complete, up-to-date copy of the data in the distributed ledger is called a complete node. In contrast, some lightweight nodes do not maintain a complete up-to-date copy of the distributed ledger, but still have the ability to verify transactions on the distributed ledger. One example is a payment verification (PV) node, which may verify transactions using payment verification methods. A PV node may be an incomplete node connected to a distributed ledger network that holds data required to prove the validity of transactions on the distributed ledger. Since PV node data generally lacks individual transaction records, PV nodes can be thought of as clients of the distributed ledger network. In one exemplary implementation, when the distributed ledger is a blockchain, the PV nodes may be simplified payment verification (SPV) nodes, and the required data includes the Merkle root of the transactions in the block, the preceding block hash, and a list of block signatures created by block verifiers.

[0085] One system architecture that may be used to support cross-ledger transfers may have full nodes of the source distributed ledger that are also full nodes of the target distributed ledger. Such a fully redundant system architecture supports cross-ledger transfers, but requires significant extra resources at each node.

[0086] Disclosed herein is an exemplary system architecture that supports cross-ledger transfers while requiring fewer resources than a fully redundant system architecture. The first representative system architecture embeds external payment verification (PV) nodes within a distributed ledger network. A second exemplary system architecture utilizes a set of shared complete nodes, although not every node has a shared complete node.

[0087] In a first exemplary system architecture, depicted in Figure 16, payment verification (PV) nodes for other (i.e., external) distributed ledgers are co-located with all or a subset of the nodes in each distributed ledger network of the multiple distributed ledger system. Supports cross-ledger payment validation using co-located PV nodes.

[0088] To reduce the resources required to implement the system, the PV nodes may be incomplete nodes. In a representative implementation, each PV node may be implemented as a simplified payment verification (SPV) node. Furthermore, although Figure 16 depicts a multiple distributed ledger system with four ledgers, a multiple distributed ledger system may include any number of distributed ledgers.

[0089] In the example shown in Figure 16, a first distributed ledger A is maintained by a first distributed ledger network 100A, a second distributed ledger B is maintained by a second distributed ledger network 100B, a third distributed ledger C is maintained by a third distributed ledger network 100C, and a fourth distributed ledger D is maintained by a fourth distributed ledger network 100D. Each of these distributed ledger networks (100A, 100B, 100C, and 100D) includes its own nodes with interconnections between its own nodes. Additionally, according to an embodiment of the present invention, there are further communication interconnections 502 between several nodes in different consensus networks so as to communicatively interconnect the consensus networks (100A, 100B, 100C, and 100D).

[0090] However, simply interconnecting a distributed ledger network of ledgers in a communicative manner is not sufficient, as cross-ledger transaction submission and validation is also required to support inter-ledger transfers. For this reason, at least some of the nodes 102 in each distributed ledger network may be configured to run both a "local" full node stack for their own distributed ledger and an "outward-facing" PV node stack for any other ledgers with which they may interact.

[0091] A complete node stack for a distributed ledger comprises a set of software routines or programs on a complete node of the distributed ledger network. A set of software routines or programs performs tasks and / or functions related to a distributed ledger, including translating API (application program interface) requests into distributed ledger transactions, where applicable, managing user keys, signing transactions, notifying other systems when transactions are committed, submitting transactions to the distributed ledger, and providing inclusion proofs for transactions. A PV node stack for a distributed ledger comprises a reduced set of software routines or programs on a client that communicates with a distributed ledger network. The reduced set of software routines or programs performs tasks and / or functions including providing inclusion proofs for transactions and submitting transactions to a distributed ledger.

[0092] In the example of FIG. 16, at least some of the nodes 102 in the first network 100A are also configured to run PV nodes (PV-B, PV-C, and PV-D) for each of the second network, third network, and fourth network (100B, 100C, and 100D). Similarly, at least some of the nodes 102 in the second network 100B are also configured to run PV nodes (PV-A, PV-C, and PV-D) for each of the first, third, and fourth networks (100A, 100C, and 100D). Also, at least some of the nodes 102 in the third network 100C are configured to run PV nodes (PV-A, PV-B, and PV-D) for each of the first, second, and fourth networks (100A, 100B, and 100D). Finally, at least some of the nodes 102 in the fourth network 100D are also configured to run PV nodes (PV-A, PV-B, and PV-C) for each of the first, second, and third networks (100A, 100B, and 100C).

[0093] Each PV-A node maintains a chain of block headers and signatures (i.e., a block header / signature chain) for common ledger A. Similarly, each PV-B node maintains a block header / signature chain for common ledger B, each PV-C node maintains a block header / signature chain for common ledger C, and each PV-D node maintains a block header / signature chain for common ledger D.

[0094] The computer system in this example includes a complete node stack A for a local distributed ledger A. A complete node stack A contains a complete copy for local distributed ledger A. In addition, the computer system includes an SPV node stack B for external distributed ledger B, an SPV node stack C for external distributed ledger C, and an SPV node stack D for external distributed ledger D. SPV Node Stack B contains the block header / signature chain for external distributed ledger B. The SPV node stack C contains the block header / signature chain for the external distributed ledger C. And the SPV node stack D contains the block header / signature chain for the external distributed ledger D.

[0095] The block header / signature chain structure that may be maintained by a PV node, particularly a PV node implemented as an SPV node, may include block headers and block signatures of the relevant distributed ledger, where the block signatures are signatures by block validators of the relevant distributed ledger network indicating that the validators accept that the signed block is valid.

[0096] In a second exemplary system architecture, depicted in Figure 17, a set of nodes is shared by all distributed ledger networks within a multiple distributed ledger system. Each of these shared nodes may act as a full node for all ledgers in the multiple distributed ledger system to efficiently support cross-ledger transfers. A multi-distributed ledger system with three distributed ledgers is depicted in Figure 17, but note that any number of ledgers may be included in the system.

[0097] In the example shown in Figure 17, a first distributed ledger A is maintained by a first distributed ledger network 100A, a second distributed ledger B is maintained by a second distributed ledger network 100B, and a third distributed ledger C is maintained by a third distributed ledger network 100C. Each of these distributed ledger networks (100A, 100B, and 100C) includes nodes with interconnections between them.

[0098] According to an embodiment of the present invention, there is a shared set of complete nodes (100ABC). Each node in the shared set 100ABC is capable of operating as a full node in each of the three distributed ledger networks (100A, 100B, and 100C). Thus, each node in the shared set 100ABC contains a copy of each of the three distributed ledgers (A, B, and C). Note that the three distributed ledgers (A, B, C) remain separate distributed ledgers, each recording a separate ledger of transactions.

[0099] According to an embodiment of the present invention, a block hash-to-block header index for each distributed ledger in the system may be created from the distributed ledger data and provided at each node in the shared set of complete nodes (100ABC). The index may be used for Merkle tree lookups depicted in FIG. 15 (from lock transaction 1506 to begin transaction 1504, and from inter-complete 1508 to lock transaction 1506) to perform cross-ledger validation.

[0100] Any participant node may send queries across the network to nodes in the shared set of full nodes (100ABC) to verify cross-ledger transactions. This implies trust in a central entity or other trusted entity that guarantees or certifies that the complete nodes provided for the ledger are not lying about the contents of the ledger.

[0101] The computer system in this example includes a complete node stack A for local distributed ledger A, a complete node stack B for local distributed ledger B, and a complete node stack C for local distributed ledger C. A complete node stack A contains a complete copy of local distributed ledger A. A complete node stack B contains a complete copy of the local distributed ledger B. The complete node stack C then contains a complete copy of the local distributed ledger C.

[0102] The description of the preceding embodiments is provided to enable any person skilled in the art to make or use the subject matter. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the novel principles and subject matter disclosed herein may be applied to other embodiments without the use of innovative faculty. The claimed subject matter set forth in the following claims is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Still other embodiments are contemplated within the spirit and true scope of the disclosed subject matter. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

1. 1. A computer-implemented method for transferring a divisible non-fungible token (NFT) from a source distributed ledger to a target distributed ledger that is different from the source distributed ledger, comprising: Locking or deleting the source NFT to be transferred on the source distributed ledger by a lock transaction; unlocking or minting a target NFT corresponding to the source NFT in the target distributed ledger by a completed transaction; wherein the source NFT has source NFT information comprising a split rule and an origin NFT identifier, and the target NFT has the source NFT information that enables splitting or merging of the target NFT in the target distributed ledger.

2. prior to the step of locking or deleting the source NFT with the lock transaction, Upon identifying the source NFT in the source distributed ledger, generating and submitting an initiation transaction comprising the target NFT for committing to the target distributed ledger; generating and submitting the lock transaction for committing to the source distributed ledger; Furthermore, Prior to the step of unlocking or minting the target NFT with the completed transaction, verifying the existence of the initiating transaction by referencing the initiating transaction in the target distributed ledger via the locking transaction; generating and submitting the completed transaction for committing to the target distributed ledger; Further equipped 2. The method of claim 1.

3. The step of dividing the target NFT comprises: locking or deleting the target NFT in the target distributed ledger after receiving a split request that complies with the split rules; generating a plurality of split NFTs based on the origin NFT identifier and the split request, each having split NFT information comprising at least a portion of the source NFT information; Equipped with The split NFT information for each of the plurality of split NFTs comprises the split rule and the origin NFT identifier.

2. The method of claim 1.

4. The step of merging the target NFTs includes: receiving a merge request to merge the target NFT with one or more sibling NFTs having the same origin NFT identifier and the same owner as the target NFT; locking or deleting the target NFT and the one or more sibling NFTs in the target distributed ledger; generating a merged NFT having merged NFT information comprising at least a portion of the source NFT information; Equipped with The merged NFT information of the merged NFT comprises the splitting rule and the origin NFT identifier.

2. The method of claim 1.

5. Both the source NFT and the target NFT refer to an origin NFT having the origin NFT identifier and the splitting rule; The origin NFT is the first minted NFT among all NFTs that have the origin NFT identifier.

2. The method of claim 1.

6. The method of claim 5 , wherein the source NFT is the origin NFT.

7. The method of claim 5 , wherein neither the source NFT nor the target NFT is the origin NFT.

8. The method of claim 5 , wherein the origin NFT identifier is a token ID of the origin NFT.

9. The method of claim 5 , wherein the division rule determines a minimum division unit of the origin NFT.

10. 10. The method of claim 9, wherein the minimum division unit is determined by a horizontal segmentation number and a vertical segmentation number.

11. The method of claim 9 , wherein the splitting rules further comprise a split number that determines the maximum number of times the origin NFT can be split.

12. The method of claim 9, wherein the origin NFT is configured to be divided into a plurality of child NFTs based on the division rule, each of the plurality of child NFTs comprising one or more minimum division units of the origin NFT.

13. 13. The method of claim 12, wherein the metadata of the origin NFT comprises an origin image, and the metadata of each of the plurality of child NFTs comprises a child image that represents a portion of the origin image.

14. the lock transaction locks the source NFT in a smart contract to transfer the divisible NFT from the source distributed ledger to the target distributed ledger; The locked source NFT is unlocked only after an external distributed ledger request that transfers the external NFT corresponding to the source NFT from the external distributed ledger to the source distributed ledger.

2. The method of claim 1.

15. 15. The method of claim 14, wherein the external distributed ledger is the same as the target distributed ledger.

16. 15. The method of claim 14, wherein the external distributed ledger is different from the target distributed ledger.

17. 3. The method of claim 2, wherein the target NFT created in the initiating transaction is transferable by the completed transaction only when the completed transaction references the locking transaction and when target NFT information of the target NFT in the initiating transaction matches the source NFT information of the source NFT identified in the source distributed ledger.

18. 18. The method of claim 17, wherein the completion transaction uses a Merkle tree reference that references the lock transaction.

19. 3. The method of claim 2, performed by a node stack of the source distributed ledger.

20. 20. The method of claim 19, wherein the initiate transaction and the completed transaction are submitted to a node stack of the target distributed ledger, and the node stack of the target distributed ledger further submits the initiate transaction and the completed transaction to the target distributed ledger.

21. 3. The method of claim 2, performed by a node stack of the target distributed ledger.

22. 22. The method of claim 21, wherein the lock transaction is submitted to the node stack of the source distributed ledger, and the node stack of the source distributed ledger further submits the lock transaction to the source distributed ledger.

Images