Production of NFT ID.

NFT is a file format (commonly used to transfer messages or values over the network) and NFT exists on the blockchain, so these tokens (or files) contain properties similar to Bitcoin, mainly digital ownership (tokens in a wallet) and transparency (all activity is recorded on the blockchain). Each NFT in the blockchain has a unique token (or message), a common example of which might be a digital trading card or a digital artwork. The value of NFT will vary depending on how it is used. Currently, NFT has the following characteristics: uniqueness, permanence, programmability, no privileges, and digital ownership. The steps for generating NFT id data are as follows. (1) I stand for the input substance; F stands for the processing function, which can also be called a processing method; and id stands for the unique signature intermediate product.

1. Step 1: Obtain data information media to determine the content of the NFT data. the NFT can support a range of files (JPG, PNG, GIF, MP3, etc.).
2. Step 2: Set up a wallet. For storing cryptocurrencies for rewarding receipts or penalizing payments in cross-chain transactions.
3. Step 3: Edit the data information on each NFT to generate NFT data.

Pass-through of NFT.

Pass-through is the conversion of an asset into a digital pass-through on a blockchain system. The biggest difference between pass-through and securitization is the introduction of programmability into pass-through assets. By the same token, pass-through cation allows for the introduction of business logic and reduces the need for manual settlement, while smart contracts in turn have automated trading, calculation of asset prices, and other specific functions.

Pass-Through contains three key principles. a) Liquidity. Increased liquidity helps to unlock value for the market through a liquidity premium. b) Tokens with programmability. Programmability refers to the ability to introduce specific business logic into a smart contract, allowing it to automate operations. c) Immutable proof of ownership. Blockchain is immutable and can be publicly tracked for every transfer and owner. Digitally tracking transactions not only provides a history of ownership changes but also reduces fraud.

Smart contract of NFT.

NFT smart contracts can be developed based on different public chains, and it is not limited to any one public chain. Different public chains have different implementations of smart contract schemes, and this article shows it with the Ethernet public chain. On top of Ethernet, there are many standards for developing NFT smart contracts, such as ERC-721 \1155 \998, each of which has its own characteristics, but their characteristics are expanded on the basic properties. We choose the ERC-721 standard to develop NFT smart contracts, in the metadata storage section, there is tokenUrl equivalent to the unique id of the substance. links to files stored on top of IPFS or other services, but are not limited to links, but can also be other content.

The entire contract needs to have the following binding features. a) NFT holder. That is, msg.sender(owner) and tokenId are in a one-to-many relationship, representing that a person can have multiple NFTs. b) tokenId and tokenUrl have a one-to-one relationship, representing a unique id in the chain for each copy of data, while tokenUrl is not required to be unique, but on the caller side, tokenUrl is usually set to be unique, even if it is not unique, it does not matter, and in case of conflict, the smaller the tokenId, the earlier it was set in the first place. c) After writing data to the chain, the NFT holder is able to obtain the unique id of the chain for the NFT and can subsequently perform a series of read and write operations based on the id.

Super-contract pairs.

The ERC (Ethereum Request for Comment) pass-through standard is a specification for creating pass-throughs through Ethereum. According to the ERC specification, a smart contract can be written to create “fungible passes”. Deploying a super-contract pair consisting of an ERC transaction contract and an ERC super-object contract, on the one hand, allows NFT to be decentralized across chains, making it truly mobile and instantaneous; on the other hand, it allows NFT to conduct “fragmented” transactions, lowering the threshold for NFT to cross chains. The dynamics and supply of ERC are managed by the bonding curve as AMM (Automated Market Maker) and have instant liquidity, and the contract automatically adjusts the liquidity trading credit according to the circulating supply. The conceptual diagram of the liquidity super-contract pairs is shown in Fig 3.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. The conceptual diagram of the liquidity super-contract pairs.

https://doi.org/10.1371/journal.pone.0302145.g003

NFT is stateful, programmable, and networked. A graph is formed in which items, markets, and social are wrapped in it. Each piece of information becomes its own micro-economy with native incentives for investment builders to develop spaces and systems for the ecology of items. This is a better way to implement a scenario of liquid cross-chain transactions.

AMM liquidity trading mathematical model. A trading pair is based on two Tokens, let’s assume they are X and Y. Then x and y are the number of tokens X and Y have as reserves in this trading pair. This ratio of pairs is determined based on the number of X and Y in the pair. The k iny*x = k is certain during the whole trading process. It is possible to keep the two coins to be traded at a corresponding price and quantity all the time. Set the trading formula as shown below. (2) Where δx represents the value-added coins and δy represents the sold coins, set α = δx/x and β = δy/y. The equations that can be derived are shown below. (3) (4) (5) (6) When the k of the model is not constant but will have a slow growth with the transaction, it shows the liquidity share calculation and updates to achieve the mathematical model of increasing liquidity across the chain of transactions, as shown in the following equation. (7) where e represents the number of ether, t represents the number of transactions to another coin, and l represents the number of increased liquidity. e′, t′, l′ represent the values after the state has changed, respectively, and are all at rest, that is, their values change only after changing from one state to the next, and let α = δe/e, that is (8) (9) (10) where the ratio of e:t:l is fixed, i.e. (11)

Endpoint.

Liquidity Layerzero deploys an outlet (i.e. a series of smart contracts that can handle logic) on both chains to each other to interact with the other chain, called an “Endpoint”. The user application calls send to transfer messages and set up its own UA-configured deployed contract. It is also understood that Endpoint will run a “super light node”. The core components of the Endpoint are Communicator, Validator, and Network, whose function is to notify the super-contract pairs, Oracle, and Relayer to get specific information and receive messages from them.

Oracle.

The closed nature of the blockchain system makes it not only consumes a lot of resources in obtaining outside information but also the authenticity difficult to guarantee. The emergence of the prophecy machine solves this problem, which introduces credible external data to the blockchain system and provides the necessary conditions for data sharing and exchange between smart contracts in the system and external systems. This data is necessary for the smart contract to run when the conditions are met and can be any data related to the smart contract: temperature, payment completion, price, etc. Also, the prophecy machine itself is a smart contract that allows the blockchain to connect to any existing API and allows smart contracts to interact with other blockchains. The prophecy machine is tamper-proof, service-stable, auditable, and powered by incentives to run. The schematic diagram of the operation of the prophecy machine is shown in Fig 4.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. Prophecy machine working schematic.

https://doi.org/10.1371/journal.pone.0302145.g004

On-chain mechanism. There are four types of smart contracts included in the blockchain on-chain mechanism, namely data request a smart contract, reputation contract, matching contract, and aggregation contract.

• Data Request Smart Contract. Also called user contracts, they are the demanders of data.
• Reputation contracts. It can be benchmarked against the intangible asset “goodwill”, which refers to the valuation of reputation, but the subject of reputation covers all organizational forms such as natural persons and merchants, and all content forms such as novels, music, movies, and dramas. At the same time, the reputation contract will check the historical service level of the prophecy machine service provider, verify its authenticity and historical performance, and eliminate the prophecy machine nodes with a poor reputation or low reliability.
• Matching contract. The data request from the request contract is sent to the node and the bid from the node is accepted. Then the order-matching contract selects the appropriate number and type of prophecy machines to complete the task.
• Aggregation Contract. Get all the data from the chosen prognosticator, validate and aggregate the data, and finally produce accurate results. The aggregation contract can validate data from a single data source or from multiple data sources. In addition, it can aggregate data from multiple data sources.

At work, the data request smart contract sends a data request when it has a data demand. After the reputation contract receives the confirmation from the user contract, the predictive machine submits the data request. Then the data node receives the request, makes a data query, and submits the query result to the aggregation contract, which aggregates the data, and submits the final query result to the user contract, finally completing the user’s data query request.

Off-chain consensus algorithm. The (t,n) threshold signature technique is used to achieve off-chain consensus in the distributed prophecy machine network. The (t,n) threshold signature technique is to have a public-private key pair in a signature population consisting of n participants, and this private key is sliced into many pieces in a certain way and distributed to all participants in the population. When any number of participants in the group greater than or equal to t sign the same data using their respective private key fragments, a complete and valid signature is generated. where t is the threshold value and also the minimum number of participants with respect to generating a legitimate signature, when the number of signatories is less than t, then no valid signature can be generated.

The off-chain consensus process consists of 4 phases: key generation, signature generation, signature verification, and prophet reward mechanism. Through the threshold signature technique, prophet nodes in a distributed prophet network interact with each other off-chain. When prophecy machine nodes generate partial signatures separately for a total of one value, they can aggregate into a complete key signature and approve the data transmission to send the consensus data to the prophecy machine-wise contract on the blockchain.

Assuming that there are f < n/3 prophecy machines with a threshold t = f + 1, the problematic nodes may have “empty pay” behavior or other dishonest operations, such as illegal signatures. The complete off-chain consensus process consists of the following four stages.

1. (1) Key generation. Execute the distributed key generation protocol, outputting the global public key Y and each propagator node O, each all key shares s_i and public key shares Y_i.
2. (2) Signature generation. Each propagator node generates partial signatures δ_i by its own key share s_i and then aggregates them to obtain verifiable full signatures δ.
3. (3) Signature verification. After the aggregated prophecy machine submits data D and signature δ, the prophecy machine-wise contract verifies the signature based on the public parameters and global public key Y.
4. (4) Prophecy Machine Reward. The prophecy machine smart contract rewards the prophecy machine nodes that have truly acquired the data to generate the signature without annoying your threshold according to the data submitted by each prophecy machine node.

Suppose the set of propagator nodes participating in consensus is O = O₁, O₂, O₃, …, O_n, with a total of n propagator nodes and a threshold value of t. The security parameter k is selected and a cyclic group G of order q is chosen whose discrete logarithm problem is intractable with finite field Z_q with a number of elements q and eigenvalues p. p, q are large prime numbers and g is a generating element of G. Choose secure hash function , . The overt parameters are k, p, q, g, G, H₁, and H₂. In addition, we denote by x ← S the selection of a random number x from S.

Relayer.

Relayer is used in the cross-chain model to obtain proof of transaction events. The Layerzero cross-chain model is based on ultralight nodes linking full chains, and ultralight node V connects multiple full nodes P, at least one of which is a non-evil full node. V requests P to verify whether a transaction really exists on the chain, P returns the relevant proof, and V makes a judgment based on the result returned by P.

The first step of the determination is to identify the non-evil full node, and the second step is to verify whether a transaction really exists on the chain based on the data refig 4 by that node.

Dynamic evaluation model.

The liquidity cross-chain transaction node creditworthiness evaluation model consists of a broadcast version, transaction node module, data collection module, data storage module, and credit ranking module, and the working principle is shown in Fig 5 [28–31].

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Working schematic of node evaluation model.

https://doi.org/10.1371/journal.pone.0302145.g005

The broadcast board is a module for displaying voting content, transaction node evaluation content, and announcement information. The voting content contains the information of the trading node voting, the signature Fig 5 of the voter, and the signature of the broadcast board; the evaluation process contains the evaluation content and the evaluation result; the announcement information includes the addresses of the trading nodes participating in the voting and the voting start and end times. The trading node module is used for filling in voting information and verification of trading nodes [32]. It includes a node login verification module and an information filling module. The data collection module is used to collect transaction node evaluation information and historical transaction evaluation information. The data storage module is used to store node information and credit ranking information [33–35].

In this model, within a specified time, the system evaluates the trust degree of existing nodes; the system will send evaluation signals to the existing nodes and broadcast the system public key and address; each node receives the signal, encrypts it using the system public key and encrypts the signature using its own private key; the system will collect the encrypted data of each node and decrypt it using the system private key, and finally form the trust relationship graph and broadcast it. If the system does not receive any objection information within the specified time, it proceeds to the next step of the plan, and if there is, it re-votes. The system automatically collects the historical transaction information of each node ranks the creditworthiness, and announces the results and the calculation process, if the system does not receive any objection information within the specified time, it automatically eliminates the nodes ranked at the bottom according to the process. The flow chart of transaction node evaluation is shown in Fig 6.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Evaluation flow chart.

https://doi.org/10.1371/journal.pone.0302145.g006

Among them, the user feedback evaluation in the transaction node’s historical transaction information refers to the user’s evaluation of the transaction after its final completion, with the score value ranging from 1–5 from low to high. The transaction node processing efficiency refers to the time required by users from initiating a transaction to final confirmation of the transaction, and the negative transaction information includes transactions that are not completed and transactions with fraud and other behaviors.

Node trust model.

The set of all participants in a cross-chain is called the set of nodes, denoted as E. The trust degree of a node, as a notary, is a quantitative representation of the degree of trust of the relevant nodes and is a cumulative evaluation reflecting the behavior of nodes in the long-term operation of a cross-chain. To cope with the trust requirements of cross-chain scenarios, the trust degree values of nodes are distributed in the interval of real numbers. The request to evaluate the trust degree T of node i to node j consists of the direct trust value DT(i, j), the recommended trust value RT(i, j), and the negative penalty value PT(i, j), which is calculated as follows. (12)

The direct trust DT(i, j) is the trust evaluation of node j by the requesting evaluation node i ∈ E based on the historical interaction experience with the evaluated node j ∈ E [19]. If requesting node i and node j have directly occurred in a period or N transaction transmissions, the satisfaction of the nth transaction transmission is S(i, j) ∈ [0, 1], which takes the values shown in the table. The thing impact factor of the nth event is IF(j, n), then the direct trust value of requesting node i to node j is (13) where IF(j, n) is the transaction impact factor of the nth interaction, IF(j, n) ∈ (0, 1); δ_k is the time decay factor corresponding to a period , k ∈ T_k, which is a monotonically increasing function, the larger the IF(j, n) is from the current transaction time; T_k is the set of transaction periods. The node evaluation satisfaction values are taken as shown in Table 3.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 3. Node evaluation satisfaction values.

https://doi.org/10.1371/journal.pone.0302145.t003

Direct trust exists only between nodes that have already had cross-chain transactions, however, evaluation nodes often encounter uninteracted nodes with no direct experience to refer to, and then they can only rely on recommendations from other nodes. The recommended trust value RT(i, j) is the trust judgment of a node formed by the evaluation node i ∈ E based on the trust evaluation of node j ∈ E provided by a third-party node k ∈ E. When node i evaluates node j, its interaction history with node j alone may not be objective enough, and the trust information of other entities recommending the evaluated node is still needed, especially if node i has never interacted with node j. The trust value RT(i, j) is (14)

G is the set of recommenders; DT(m, j) is the direct trust value of the recommended node m to node j; Ht(i, m) is the recommendation trustworthiness of the recommended node m according to node i, which indicates the recommendation ability of the recommended node m; Sim(i, m) is the similarity between the recommended node m and the evaluation of node i’s trust evaluation of node j. The higher the similarity, the more node i and node m agree on each other the more consistent node i and node m’s perceptions of other nodes in the network. Can the recommending node provide a trustworthy recommendation? In G, the node with higher similarity is generally selected as the recommendation node, and the appropriate recommendation node can be selected by setting a similarity threshold ∂ ∈ [0, 1] such that Sim(i, m) ≥ ∂.

The degree of credibility is calculated as follows. (15)

S_t(i, m) denotes the number of satisfactory recommendations provided by recommendation node m among all transaction histories of requesting node i; F_t(i, m) is the number of unsatisfactory recommendations provided.

The degree of similarity between two nodes is portrayed by the cosine similarity function, and the similarity is calculated as follows. (16)

S_t(i, m) denotes the number of satisfactory recommendations provided by recommendation node m among all transaction histories of requesting node i; F_t(i, m) is the number of unsatisfactory recommendations provided.

The degree of similarity between two nodes is portrayed by the cosine similarity function, and the similarity is calculated as follows.

m is the node that has traded with both node i and node j.

The negative transaction penalty value RT(i, j) can be understood as the price paid by a node for causing trust fluctuations after using its trustworthiness to make false transactions, and the purpose of introducing the penalty value is to impose a certain penalty effect on nodes whose behavior changes dynamically by assigning appropriate weights to make the node’s trustworthiness fall more quickly, to achieve suppression of dynamic changes in node behavior. (17)

RT^k(i, j) is the recommended trust value of node j that can be obtained by requesting node i by pooling all recommended nodes in time period k; DT^k(i, j) is the direct trust value of requesting node i to node j in time period k; δ_k is the time decay factor corresponding to time period k.