\section{Introduction}
\label{sec_intro}

The metaverse attracts significant attention in recent years. It is a computer-generated virtual world and can be intertwined with the physical world.
Users in the metaverse gain immersion during interacting with virtual objects or other users, which makes the metaverse a new paradigm of the Internet.
To achieve this, the metaverse requires the integration of various technologies. These include but not limited to augmented reality (AR), digital twin (DT), blockchain, interactivity, game, artificial intelligence (AI), networking, and Internet of Things (IoTs) \cite{lee2021all}. For example, AR provides an immersive experience;  DT generates a mirror image of physical world entities; blockchains build metaverse  economic systems.

In metaverse, an avatar is the digital representation of a user within a virtual space. The avatar can be integrated with blockchain, to become the digital DNA of this user. In addition, a user may have digital assets in the metaverse, which can be cryptocurrencies, skins, or objects that feed from the physical world. Such assets become valuable and tradable by using blockchain. Further, blockchain, such as Ethereum, forms the fundamental economic system in the metaverse. On the other hand, non-fungible tokens (NFT) ensure that non-monetary digital assets owned by a user can't be copied or fabricated.

To date, there are numerous metaverses have been built~{\color{black}\cite{Huang2022Economic}}. Examples include Roblox \cite{roblox} for productivity, Sandbox \cite{sandbox2023Sandbox} for virtual real estate, Axie Infinity \cite{axieinfinity} for gaming. Moreover, a number of top companies propose their own metaverse, such as Meta, Nvidia, and Google, to name a few~\cite{Huang2022Economic}. These metaverses usually have independent economic systems, i.e., they use different tokens or currencies, and  rules, i.e., representing avatars in 2D or 3D form. Hence, it is inconvenient for users to interchange between metaverses. This slackens the development of the metaverse society. Therefore, an efficient cross-metaverse strategy is desired to enable users to switch between metaverses with negligible effort. We call this \textit{cross-metaverse interoperability}.

In a nutshell, cross-metaverse interoperability provides a seamless experience for users to interact with metaverses. We now use an example in the commercial metaverses to illustrate the key features of cross-metaverse interoperability. Consider a user purchased a digital asset, say an `axe', from metaverse \textit{Alpha}, the cross-metaverse interoperability ensures that this  asset has the same value and functions when the user using it in another metaverse \textit{Beta}. Note that, the metaverse \textit{Alpha} and \textit{Beta} may have different economic systems based on Bitcoin, Ethereum, or some type of centralized currency derived from offline central bank. Moreover, these metaverses may have different virtual environments, but the  cross-metaverse interoperability ensures that the digital `axe' is used to `cut trees' in all of them.

In order to achieve cross-metaverse interoperability, the following two basic components need to be interoperable between metaverses:
\begin{itemize}
    \item {\em Identity}.
    %
    The identity defines the uniqueness of users and digital assets across metaverses. In addition, identities and their relationship are essential to connecting users with their actions and assets.

    For cross-metaverse interoperability, identity is fundamental for building trustworthiness. This requires the standardization of identities among various types, such as users, assets, currencies, objects, and motions, in all metaverses.
    %
    It should be noted that one natural person may create multiple user identities in one or many metaverses. However, each of these identities needs to be treated independently, the same with multiple social accounts owned by the same person.

    \item {\em Object}. This includes avatars, digital assets, and interactable entities in metaverses. Each object has its own properties, such as gender, material, rendering, and functionality. These properties can be fed from physical words, e.g., via DT and 3D scanning, or created by users out of thin air. For cross-metaverse interoperability, the objects in different metaverse with the same identity must have the same properties.

\end{itemize}

In this article, we first present a comprehensive review of existing technologies that enable cross-metaverse interoperability.
We show that these technologies lack generality, making them hard to implement for interoperability between arbitrary centralized or decentralized metaverses.
We then propose a metaverse interoperability protocol named \textsf{MetaOpera}. It enables interoperability between any two metaverses regardless of their centralized or decentralized system models. By employing NFT technologies, all metaverse components are monetized as unique assets. Thus, they are exchangeable and satisfy the requirement of crossing the metaverses. As an exemplary concrete instantiation for \textsf{MetaOpera}, we describe two \textsf{MetaOpera} workflows in detail, which demonstrate how \textsf{MetaOpera} support metaverses interoperate with each other.

To evaluate the validity of \textsf{MetaOpera}, we develop a proof-of-concept (PoC) implementation for \textsf{MetaOpera} metaverse and Sandbox metaverse. Without loss of generality, our \textsf{MetaOpera} metaverse is also applicable to any other metaverses. We evaluate the performance of \textsf{MetaOpera} and compare it with a cross-metaverse scheme based on Sidechains \cite{Peter2019Proof}. Experiment results show that the cross-metaverse proof of \textsf{MetaOpera} is roughly 1.7 KB, which is 8 times smaller than the Sidechains approach; and that the average time of cross-metaverse transactions is about 1.8 hours, which is 3 times smaller than the Sidechains approach.
Lastly, we summarize open issues and challenges faced by cross-metaverse interoperability, which include economic systems, applications, physical/virtual interoperability, security, off-line trustworthiness, universal data structure, and policy.

The rest of this paper is organized as follows. Section \ref{sec:preliminaries} introduces the preliminaries and state-of-the-art cross-metaverse technologies. Section \ref{sec:MetaOpera} demonstrates the proposed \textsf{MetaOpera} protocol.
The performance of \textsf{MetaOpera} is evaluated in Section \ref{sec:performanceEvaluation}.
Section \ref{sec:OpenIssuesandChallenge} suggests open issues and challenges for
cross-metaverse interoperability. Section \ref{sec:Conclusion} concludes this paper.

\section{Preliminaries and State-of-the-Art Cross-Metaverse Technologies}\label{sec:preliminaries}

According to the system model of metaverses, cross-metaverse interoperability is divided into two categories: (1) the interoperability between decentralized metaverses built at the top of blockchain technology, and (2) the interoperability between decentralized and centralized metaverses, where the centralized metaverses are built at the top of a centralized server. For the former, the underlying technology of interoperability is cross-chain. For the latter, the underlying technology of interoperability is on-chain and off-chain exchange. These two types of underlying technologies are described in detail below.
\begin{table*}[ht]
\caption{Cross-chain technologies}

\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{1.9cm}<{\centering}|m{3.3cm}|m{5cm}|m{1.cm}<{\centering}|m{1.cm}<{\centering}|m{1.5cm}<{\centering}|m{1.1cm}<{\centering}|}%
\hline
\textbf{Technical Scheme} & \textbf{Typical Project} & \textbf{Description}& \textbf{Security}& \textbf{Efficiency}& \textbf{Generality}& \textbf{Scalability} \\
\hline
    Notary & Interledger \cite{thomas2015protocol}, Tokrex \cite{Tokrex}, Croda \cite{croda}, BTCB \cite{binance}, HBTC \cite{Hbtc}, tBTC \cite{tBTC}, ren \cite{ren}, DeCus \cite{decus}, Hop Exchange \cite{whinfrey2021hop}, Hyphen \cite{biconomy}, Degate Bridge \cite{degate}, Wanchain \cite{wanchain}, Fusion \cite{fusion}
& A mutually trusted third party is used between different blockchains to act as a notary for cross-chain message verification and forwarding.&Low \cite{yin2022bool,xie2022zkbridge,bentov2019tesseract} & High &High& High\\
    \hline
     Hashed Time-Lock
 & WBTC \cite{wbtc}, Bridge \cite{cBridge}, Lightning Network\cite{lightningNetwork}, Zcash XCAT \cite{zcashXCAT}
& The asset receiver is forced to determine the collection and produce proof of collection to the payer within the cut-off time, or the asset will be returned via hash locks and blockchain "time" locks. The proof of receipt can be used by the payer to acquire assets of equal value on the recipient's blockchain or trigger other events.& Medium \cite{thyagarajan2022universal,tsabary2021mad} & High &Medium \cite{bentov2019tesseract}& Low\\
    \hline
  Sidechains/Relay
 &BTCRelay \cite{btcrelay}, RootStock \cite{rsk}, Plasma \cite{PLASMA}, Ronin \cite{Ronin}, Elements \cite{Elements}, LayerZero \cite{LayerZero}, Waterloo \cite{Waterloo}, Polygon \cite{Polygon},
 &Interoperation (transfer, communication, operation) of on-chain objects (assets, data, functions) through two-way anchoring and relay mechanisms.&High \cite{gavzi2019proof} & Medium \cite{gavzi2019proof,yin2021sidechains}&Medium \cite{zamyatin2019xclaim,yin2021sidechains}& High \cite{gavzi2019proof,yin2021sidechains}\\
    \hline
Relay chain
 &Polkadot \cite{Polkadot}, Cosmos \cite{kwon2019cosmos}
 & To achieve cross-chain object interoperation by the relay chain.& Medium & Low &Medium \cite{tian2021enabling}& High\\
    \hline
\end{tabular}
\label{Table:auction}
\end{table*}
\subsection{Cross-Chain Technologies}

To further understand cross-chain technologies, we review state-of-the-art cross-chain works. As described in table \ref{Table:auction}, there are four kinds of cross-chain technologies: Notary, Hash Time-Lock, Sidechains/Relay, and Relay chain. Notary scheme is the most widely used due to its high efficiency and convenient deployment. A typical example of a notary scheme is centralized exchange. All cross-chain assets in the exchange are maintained and managed by a trusted third party called notary. It is easy to see that if the notary is fail, cross-chain interoperability will be suspended. To avoid the single-point-failures, the notary consists of multiple parties based on their weights (i.e., coin) or reputation. However, the notary still suffers from security challenges such as external trust assumption. Indeed, Ronin bridge \cite{roninbridge}, a well-known notary scheme, lost 624 million USD due to malware attacks. The main reason behind this attack is that an attacker illicitly obtains the majority keys of the notary members through the malware.

To overcome the external trust assumption, the Hash time-lock scheme is proposed, which utilizes a hash function and time-lock features to achieve cross-chain interoperability. the security of the Hash time-lock scheme is based on cryptographic hardness assumptions. Consider two users: Alice with $x$ coins on chain $\mathcal{C}_1$ and Bob with $y$ coins on chain $\mathcal{C}_2$. They want to exchange their assets at the exchange rate of 1. First, Alice generates a hash value $p$ = $H$($p$) via a hash function $H(\cdot)$ and hereby uses it to create a transaction $tx_1$ that transfers $x$ coins to Bob's address on $\mathcal{C}_1$. That is, Bob can receive these $x$ coins from Alice if Bob knows the preimage $p$ corresponding to the $h$. Once the $tx_1$ is included on $\mathcal{C}_1$, Bob also uses the hash value $p$ to generate a transaction $tx_2$ that transfers $y$ coins to Alice's address on $\mathcal{C}_2$, and broadcasts it into $\mathcal{C}_2$ network. To gain these $y$ coins from Bob, Alice reveals the preimage $p$ in $tx_2$. Meanwhile, Bob also knows the $p$ via observing the $tx_2$ on $\mathcal{C}_2$. Subsequently, Bob publishes the obtained preimage $p$ in $tx_1$ and hereby receives these $x$ coins from Alice, completing the asset exchange. However, this scheme only supports monetary  exchange and thus has low scalability.

The sidechains/relay scheme supports the interoperability of multiple objects such as assets and other data, thus having high scalability. Sidechain is a blockchain that communicates with other blockchains via a two-way peg. In particular, the two-way peg is a mechanism that allows bidirectional communication between blockchains. An example of a two-way peg is simplified payment verification (SPV) in Bitcoin.
Specifically, to perceive events on a mainchain, all block headers of the mainchain are relayed into the sidechain pegged with the mainchain. The sidechain can determine whether an event has occurred on the mainchain by verifying the stored block headers of the mainchain and the Merkle tree verification path regarding the event. However, the sidechains/relay scheme can only be applied to specific blockchains, and thus has a low generality.

A relay chain is a third-party blockchain that other blockchains can connect to, which enables these blockchains to communicate with each other. The relay chain scheme has high scalability, and supports multiple objects interoperability between blockchains connected to the relay chain. However, as compared with other cross-chain schemes, the relay chain scheme has relatively low efficiency, especially in terms of cross-chain time.

\subsection{On-Chain and Off-Chain Technologies}

On-chain and off-chain technologies, often called oracle technologies, connect on-chain blockchain systems to off-chain systems, which further enables the interoperability of decentralized systems and centralized systems. Currently, oracles can be generally classified into two types: voting-based oracles and reputation-based oracles. The voting-based oracles are usually designed for  single centralized systems, which employ participants' weight to finalize interoperability outcomes. The widely deployed strategy of achieving these oracles includes stake-based oracles, multisignature-based oracles, schelling point-based oracles, and conventional oracles. However, these oracles are hard to verify the outcome integrity. On the other hand, reputation-based oracles are suitable for multiple centralized systems. Their aims are to authenticate the integrity of interoperability outcomes. These oracles utilize software (i.e., TLS protocol) or hardware (i.e., Intel Software Guard Extension) to generate a proof. The performance comparison of oracles is shown in Table \ref{Table:on-off-chain}.

\begin{table*}[ht]
\caption{Oracle technologies}

\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{3cm}<{\centering}|m{2.6cm}|m{5.2cm}|m{1.3cm}<{\centering}|m{1.3cm}<{\centering}|m{1.9cm}<{\centering}|}%
\hline
\textbf{Technical Scheme} & \textbf{Specific Type} & \textbf{Description}& \textbf{Security}& \textbf{Integrity}& \textbf{Confidentiality} \\
\hline
 \multirow{4}{*}{Voting-based Oracles}
& Stake-based \cite{merlini2019public, adler2018astraea, ryuuji2018Shintaku, nelaturu2020public, peterson2015augur, tellor2021Tellor, dIA2021Decentralized, paul2021Truthcoin} & This scheme employs the stake held by participants for finalizing the outcome. Participants are rewarded if the outcome is matched and penalized otherwise. & High & Low & Low \\
    \cline{2-6}
      & Multi-signature based \cite{orisi2014Orisi, gnosis2017Gnosis, delphi2017Delphi, moudoud2019iot, dOS2019DOS}
& Finalizing the outcome is determined collectively by multi-participants via making a signature on the outcome. & Medium & Medium & Low \\
    \cline{2-6}
 & Schelling point based \cite{vitalik2014SchellingCoin, roman2017Oracul, MarkerDAO2014The}  & According to the median value, the outcome is derivated from a group of data providers' answers. & Low  & Low & Low  \\
    \cline{2-6}
 & Conventional \cite{IOTA2021Introducing, eskandari2017feasibility, zhang2020industrial, Thomas2020ternity}
 & The outcome is directly from the raw answer of the data provider.& Low & Low & Low \\
    \hline
 \multirow{3}{*}{Reputation-based Oracles} & Software-based Proof \cite{zhang2020deco, guarnizo2019pdfs, tlsnotary2023TLSnotary, bridge2021oracle, liang2021polkaoracel}
 & Utilizing the TLS/SSL protocols, the scheme generates a data authenticate proof which is used to verify the integrity of outcomes.& Medium & Medium & Medium \\
    \cline{2-6}
 & Hardware-based Proof \cite{zhang2016town, schaad2019integration, coldcard2021coldcard, ellis2017chainlink} & The scheme provides the integrity and conidentiality for the outcome based on the Software Guard Extension (SGX) technology in the Inter CPUs. & Medium & High & High \\
    \cline{2-6}
 & Proofless \cite{wang2019novel, al2019decentralized, fujihara2019proposing, de2017witnet}
 & The scheme retrieves directly from data sources without providing authenticated proof of the outcome. & Low & Low & Low \\
    \hline
\end{tabular}
\label{Table:on-off-chain}
\end{table*}

\subsection{Cross-Metaverse Technologies}

In terms of cross-metaverse interoperability,
industrials have proposed prototypes.
For example, \textit{STYLE} protocol \cite{styleprotocol2023}, which is a virtual asset infrastructure across-metaverse, has been proposed in 2022 and will be implemented this year. The goal of \textit{STYLE} is to enable assets to exchange across the metaverses. To achieve this, two key features: usability and visualization for assets, are introduced into this protocol. Cross-metaverse avatar scheme \cite{crossmetaverse2023} aims to enable avatar interoperability across-metaverse. Same with in the real world to interact and communicate, avatars, a digital representation in metaverse, also allow people to feel and travel in multiple metaverses. Similarly, the scheme will be launched in 2023. In academics, Huang et al. \cite{Huang2022Economic} presented a cross-chain ecosystem for metaverse. As an example, this work depicts assets interoperability between Sandbox’s and Axie Infinity’s metaverses. However, this study focuses only on decentralized metaverses. Chen et al. \cite{chen2022cross} proposed a cross-platform metaverse data management system. The system designs plug-ins for different metaverse/games, enabling the profile and space share cross-platform metaverse.

\section{\textsf{MetaOpera} Protocol}\label{sec:MetaOpera}
\begin{figure*}[t]
    \centering
\includegraphics[width=0.95\textwidth]{figure/MetaOperaProtocol.pdf}
    \caption{The design of \textsf{MetaOpera} illustrated with the example of four metaverse interoperability. The blue arrows denote the direction of cross-metaverse object transfer. For clarity we only show two workflows of \textsf{MetaOpera} and the opposite direction is symmetric.}
    \label{fig:MetaOperaProtocol}
\end{figure*}
In this section, we present a novel cross-metaverse interoperability protocol: \textsf{MetaOpera}. We first give an overview of \textsf{MetaOpera}, and then present its core components and workflow.

\subsection{Overview}

At a high level, \textsf{MetaOpera} is a cross-metaverse interoperability infrastructure, which enables interoperability between any two metaverses. \textsf{MetaOpera} implements NFT technologies to monetize all metaverse components as unique assets. Therefore, arbitrary metaverse users and objects are able to interoperate with each other. Its key idea is shown in Figure \ref{fig:MetaOperaProtocol}. Briefly, the user of the metaverse connected to \textsf{MetaOpera} first locks its asset, and then mints the corresponding asset, in the form of NFT, in the \textsf{MetaOpera}. Next, the user of the \textsf{MetaOpera} stakes its NFT and then mints the corresponding NFT in another metaverse it wishes, completing metaverse object interoperability.

\subsection{\textsf{MetaOpera} Core Components}

MaoetaOpera is essentially a relay metaverse built at the top of \textsf{MetaOpera} blockchain, which is used to connect another metaverse. Upon connecting to the \textsf{MetaOpera}, any metaverse can communicate with each other. To achieve a variety of metaverse interoperability, \textsf{MetaOpera} has two key underlying technologies: cross-chain technology and on-chain and off-chain technology. The former can support \textsf{MetaOpera} to interoperate with the decentralized metaverse based on blockchain. The latter can achieve \textsf{MetaOpera} to interoperate with the centralized metaverse built at top of centralized servers. these underlying technologies adopted in the \textsf{MetaOpera} are resilient. To reach high efficiency across decentralized metaverse, for instance, the cross-chain scheme may be a notary technology as described in Table \ref{Table:auction}.

There are five components in \textsf{MetaOpera} listed as follows:

\begin{itemize}
    \item Metaverse. A metaverse is a virtual world. Metaverses are classified into two categories: decentralized metaverse (DM) and centralized metaverse (CM) based on underlying technologies. Here, DM is built at the top of decentralized blockchain technology. while CM is built at the top of centralized serves.
    \item Object. An object is a virtual digital item in the metaverse, such as cryptocurrency, avatar, skin, pet, fashion, etc. These objects can be transferred, sold, rented, and staked across metaverses. Each metaverse includes \textit{outbound objects} and  \textit{inbound objects}. An object is referred to as an outbound object if it had been locked in the metaverse it belongs; subsequently, a corresponding object will be minted in another metaverse. On the contrary, an inbound object denotes the object moved from another metaverse.
    \item Owner. An owner represents a metaverse user, who holds some objects and wishes to transfer them from one metaverse to another metaverse.
    \item Customizer. A customizer is a \textsf{MetaOpera} worker who assists in object transformation from \textsf{MetaOpera} to another metaverse in exchange for a reward. For example, the 2D object of \textsf{MetaOpera} can be tailored into the 3D object residing on a metaverse through a customizer.
    \item NFT. NFT (non-fungible token) is a unique and exchangeable digital token. NFT has the characteristics of rareness, indivisibility, and uniqueness. Thus, it can denote the ownership of an object from metaverse, specifically for the centralized metaverse.
\end{itemize}

\subsection{\textsf{MetaOpera} Workflow}

In this subsection, we demonstrate the interoperability workflow of the \textsf{MetaOpera} by depicting two across-metaverse interoperability scenarios, see in Figure \ref{fig:MetaOperaProtocol}.
The first workflow is DM to DM, e.g., Axie Infinity metaverse \cite{axieinfinity} to \textsf{MetaOpera} to Sandbox metaverse \cite{sandbox2023Sandbox}. The other workflow is CM to CM, e.g., Minecraft metaverse \cite{minecraft} to \textsf{MetaOpera} to Roblox metaverse \cite{roblox}. It is worth noting that \textsf{MetaOpera} can support any two metaverses to interoperate regardless of the CM or DM models of the metaverse.

\subsubsection{DM to \textsf{MetaOpera} to DM}

   As depicted in Figure\ref{fig:MetaOperaProtocol}, two decentralized metaverses (DM), Axie Infinity and Sandbox, can communicate with each other through \textsf{MetaOpera}. Specifically speaking, the owner of Axie Infinity wishes to transfer assets into Sandbox. First, the owner issues a transaction $tx_{x1}$ that locks its asset \textit{Axies}. Once it has been locked, \textit{Axies} will become an outbound object in Axie Infinity. Meanwhile, the proof attesting to the validity of $tx_{x1}$ is generated by a committee of \textsf{MetaOpera}. Here the committee is a notary scheme described in Figure \ref{Table:auction}, The members of the committee select from the maintainer of \textsf{MetaOpera} according to their weights (i.e., coins). If the above $tx_{x1}$ and its proof are considered valid, \textsf{MetaOpera} will mint an NFT corresponding to \textit{Axies}, The minting action is achieved by a mint transaction $tx_{x2}$ generated by the owner. Until now, the owner of Axie Infinity has transformed its \textit{Axies} into the NFT of \textsf{MetaOpera}.

    Further, the owner sequentially transfers the NFT corresponding to \textit{Axies} into Sandbox. This process is similar to the transfer from Axie Infinity to \textsf{MetaOpera}. The main difference is that a customizer may participate in the transformation of object format, such as casting 2D NFT into 3D NFT, The reason behind the difference is the heterogeneity of metaverse model so that an object of a metaverse is incompatible with another metaverse version. The owner first stakes its NFT corresponding to \textit{Axies} in \textsf{MetaOpera} by issuing a staking transaction \textit{$tx_{x3}$}. According to the NFT format, a customizer tailors it into another NFT format supported by Sandbox. Subsequently, proof testifying that \textit{$tx_{x3}$} is valid is produced by the committee of \textsf{MetaOpera}. Finally, Sandbox mints corresponding NFT to the owner based on the proof and NFT format cast by the customizer, completing the interoperability for Axie Infinity and Sandbox.

\subsubsection{CM to \textsf{MetaOpera} to CM}

    Upon connecting to the \textsf{MetaOpera}, any two centralized metaverse (CM) can interoperate with each other. Figure \ref{fig:MetaOperaProtocol} shows such an example that an avatar of Minecraft travels to Roblox. The owner of Minecraft generates a lock transaction \textit{$tx_{y1}$} to lock its avatar. A committee of \textsf{MetaOpera} observes the Minecraft state. Here the committee is a multi-signature oracle described in Table \ref{Table:on-off-chain} and consists of \textsf{MetaOpera} users. If \textit{$tx_{y1}$} is confirmed in Minecraft. The committee will generate a proof for \textit{$tx_{y1}$} to convince all \textsf{MetaOpera} maintainers that the avatar has been locked successfully. Once the proof is generated, the owner issues a mint transaction \textit{$tx_{y2}$} to mint an NFT corresponding to the avatar into its \textsf{MetaOpera} address. The action of minting the NFT will be implemented if the \textit{$tx_{y2}$} and proof are considered valid. This means that the avatar has transferred from Minecraft to \textsf{MetaOpera}.

    Next, the owner further transfers the avatar from \textsf{MetaOpera} to Roblox. The owner first generates a staking transaction \textit{$tx_{y3}$} to lock the NFT above. Similarly, the proof for \textit{$tx_{y3}$} is also generated. A customizer issues a mint transaction \textit{$tx_{y4}$} in Roblox to cast an NFT-derivative corresponding to the locked NFT. Where NFT-derivative is not NFT but an object compatible with Roblox, since Roblox does not support NFT. To keep the format persistence of the NFT-derivative and the Minecraft avatar, casting NFT-Derivative is essential. This is done by the customizer. The above casting action will be executed eventually if the \textit{$tx_{y4}$} and proof are considered valid. Until now, the avatar of Minecraft has been transferred into Roblox, completing the interoperability for Minecraft and Roblox.

\subsubsection{DM/CM to \textsf{MetaOpera} to CM/DM}

As discussed earlier, \textsf{MetaOpera} is a decentralized metaverse built at the top of the blockchain.
Objects are able to interoperate from DM or CM to \textsf{MetaOpera} and then interoperate to DM or CM again.
Alternatively, \textsf{MetaOpera} can support objects interoperating from DM to CM or CM to DM.

\section{Performance Evaluation}\label{sec:performanceEvaluation}

In this section, we implement the proposed \textsf{MetaOpera} protocol and evaluate its performance. We first measure the cross-metaverse proof size and the average time of cross-metaverse transactions. We then compare them with a state-of-the-art cross-metaverse scheme based on Sidechains \cite{Peter2019Proof}.

\textbf{Implemention Setting.} To simulate the performance of \textsf{Metaopera} prorocol from Section \ref{sec:MetaOpera}, we make a proof-of-concept (PoC) implementation for \textsf{Metaopera} and Sandbox. Without loss of generality, the PoC implementation is also applicable to both \textsf{Metaopera} and anyone metaverse connected to \textsf{Metaopera}. In our PoC implementation, the blockchain of \textsf{Metaopera} is instantiated as Cardano \cite{aggelosre2017Ouroboros}. While the blockchain of Sandbox is based on Ethereum \cite{buterin2014next}, which follows the Sandbox implementations of \cite{sandbox2023Sandbox}). The PoC implementations for \textsf{MetaOpera} and Sandbox are executed in a personal platform installed with Windows 11 operating system and equipped with Intel(R) Core(TM) i7-12700KF CPU 3.60 GHz 32.00GB RAM. We carry out our \textsf{MetaOpera} blockchain in standard C language. To achieve committee members' vote, the multi-signature scheme \cite{boldyreva2003Threshold}, a cryptographic primitive, is employed in our PoC implementations. Here the size of public key $|vk_i|$ = 272 bits, the size of signature $|\sigma_i|$ = 528 bits, the size of proof-of-possession $|POP|$ = 528 bits. A 256-bit hash function $H(\cdot)$ is also applied in the PoC implementations, meaning that $|H(\cdot)|$ = 256 bits. Following Cardano implementation, we denote by $k$ a common prefix parameter. To form a decentralized \textsf{Metaopera} committee, the chain quality, a blockchain fundamental security property, is adopted in the committee selection. In short, the committee members are selected from nodes that have generated any $k$ consecutive blocks of Cardano. Moreover, we set that the transaction size $|tx|$ = 250 bytes, block height size $|h|$ = 32 bytes, and the random number size $|r|$ = 32 bytes, these parameters are important components of the above proof. On the other hand, we use $k^{\prime}$ to indicate a common prefix parameter of Ethereum. In addition, both the block-generating times of Cardano and Ethereum are set to 5 seconds.

\textbf{Implementations and Evaluations.} In our \textsf{Metaopera}, the proof attesting to the validity of cross-metaverse transactions is generated by a committee of \textsf{Metaopera}. Its size affects the efficiency of cross-metaverse transactions, For example, The larger the proof size is, the longer its verification time will be. Thus, we evaluate it. A proof is composed of public keys, signatures, and hash values. Based on the principle of the adopted multi-signature scheme, the proof can be further improved by the optimized tips used in \cite{Peter2019Proof}. Formally speaking, the improved proof can be denoted as
$|tx|+|h|+|r|+0.1\cdot k \cdot |vk_i|+ |\sigma_i|$. As depicted in Figure \ref{CommitteeProof}, the proof size of \textsf{Metaopera} increases linearly in the size of committee $\textit{c}$. This is because the proof size increases as the number of committee members increases. More precisely, in the case of the committee size of 400, the proof size is roughly 1.7 KB, which is 8 times smaller than the proof size of PoS sidechains \cite{Peter2019Proof}.
\begin{figure}[ht]
	\centering
	\includegraphics[width=0.400\textwidth]{figure/CommitteeProof.pdf}
	\caption{The proof size at different committee sizes.}
	\label{CommitteeProof}
\end{figure}

In our PoC implementation, cross-metaverse transactions consist of two transactions: \textit{tx} included in \textsf{Metaopera} and  \textit{$tx^{\prime}$} included in Sandbox. To verify the validity of \textit{$tx$}, the proof is essential. Therefore, the time of cross-metaverse transactions includes both the confirmed time of \textit{tx} and \textit{$tx^{\prime}$}, as well as the proof generating time. Let \textit{k} and \textit{$k^{\prime}$} be 400 and 500 respectively. We have that the confirmed time of \textit{tx} is roughly 5\textit{k} = 5 $\times$ 400 = 33.33 minutes and the confirmed time of \textit{$k^{\prime}$} is roughly 5\textit{$k^{\prime}$} = 5 $\times$ 500 = 41.67 minutes. In the case of a committee size of 400, we measure the time \textit{t} that these committee members collectively generate the proofs for 200 different cross-metaverse transactions. Measurement results show that the average time for generating a proof is roughly 1.5 minutes. To this end, the average time of cross-metaverse transactions is roughly 76.5 minutes, as described in Table \ref{Table:TimeCrossMetaverse}. As a comparison, the average time of transactions of Sidechains \cite{Peter2019Proof} is 5.251 hours, which is 3 times more than our \textsf{MetaOpera}.

\begin{table*}[ht]
\caption{The average time of cross-metaverse transactions.}
\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{5.5cm}<{\centering}|m{2.2cm}<{\centering}|m{2.4cm}<{\centering}|m{2.4cm}<{\centering}|m{2.6cm}<{\centering}|}%
\hline
\textbf{Time of cross-metaverse transaction} & \textbf{\textsf{MetaOpera} time} & \textbf{\textsf{MetaOpera} time/h} & \textbf{Sidechains \cite{Peter2019Proof} time} & \textbf{Sidechains \cite{Peter2019Proof} time/h} \\
\hline
\textbf{Confirm Time of \textit{tx} in \textsf{MetaOpera}} & \textit{2k} & 1.112 & \multirow{2}{*}{\textit{10k}} & \multirow{2}{*}{5.556} \\
\cline{1-3}
\textbf{Proof Generating Time} & \textit{t} & 0.025 & & \\
\hline
\textbf{Confirm Time \textit{$tx^{\prime}$} in Sandbox} & \textit{$k^{\prime}$} & 0.695 & \textit{$k^{\prime}$} & 0.695 \\
\hline
\textbf{Average time of cross-metaverse transaction} & \textit{2k} + \textit{t} + \textit{$k^{\prime}$} & 1.832 & \textit{10k} + \textit{$k^{\prime}$} & 6.251 \\
\hline
\end{tabular}
\label{Table:TimeCrossMetaverse}
\end{table*}

\section{Open Issues and Challenges}\label{sec:OpenIssuesandChallenge}
Although we have proposed the \textsf{MetaOpera} protocol, cross-metaverse interoperability is still in its initial stage from the perspective of either industry or academia. In this section, we summarize open issues and challenges in cross-metaverse interoperability and suggest potential future research directions.

\subsection{Economic System}

To date, most metaverse builds their economic system using smart contracts on the Ethereum blockchain. This raises the risk that a single security hazard in Ethereum will affect a majority of metaverses. To this end, diversified economic systems are desired in co-existing metaverses, to enhance their robustness against single-system crashes. This also requires cross-metaverse interoperability of these systems.

\subsection{Applications}
  At the current stage of metaverse development, almost all the applications
  provided by the blockchain-based metaverses are the circulation of cryptocurrencies and NFT. However, the metaverse has more potential applications other than this. For example, the immersive experience can be used for a deep interaction between humans and multiple physical or virtual environments. This needs further development of cross-metaverse interoperability technologies to boost the application scenarios of the metaverse.

\subsection{Physical/Virtual Interoperability }
Most research and implementation of metaverse focus on mapping physical objects to the virtual metaverse. There are a number of technologies that can be used, such as 3D scanning. However, how the actions in the virtual world reflect in the physical world is also a key concern. This is important for production metaverse applications such as surgery and driving. Such interoperability requires trustworthiness, low latency, and accuracy of the reflection of the action.

\subsection{Security}
The security issues in cross-metaverse interoperability concern with authentication and permissions for assets and data exchanges. In particular, when an asset or object data is crossing metaverses, both metaverses need to confirm their ownership. Moreover, these metaverses need to ensure the asset or data is only valid in only one metaverse. For the objects existing in a metaverse, permission is important to specify who and what actions can be interacting with the objects.

\subsection{Off-line Trustworthiness}
Even though the Internet is universal existence in the physical world, it is inevitable that some locations still have no Internet connection, such as in a desert. After an object lost connection with the metaverse, its properties may be changed before back online. In such a situation, cross-metaverse interoperability needs to ensure the trustworthiness of the changes from a tiny centralized server, i.e., an offline data collector, to the centralized or decentralized online metaverse.

\subsection{Universal Data Structure}
Physical objects have common properties, such as shape, weight, and color. However, some of their properties are unique and independent. For example, a cup has the capacity property, but a pencil does not. Hence, cross-metaverse interoperability needs to design a universal data structure to describe the physical objects in the metaverse. In addition, this data structure needs to be a standard for all metaverses to enable interoperability.

\subsection{Universal Policy}

The challenges of the universal policy include two perspectives: governance and metaverse platform. In terms of governance policy, a universal law or rule is required to restrain criminal behavior. This is because metaverses have independent rules, and their evaluation criteria for improper behavior are different. Hence, a universal governance policy is vital to prevent cross-metaverse crimes.  On the other hand, existing metaverse platforms usually have different user policies. Hence, users are hard to control the privacies, copyrights, and exchange of their assets in multiple metaverses. Therefore, a universal metaverse platform policy is also critical for  cross-metaverse interoperability.

\section{Conclusion}\label{sec:Conclusion}
Cross-metaverse interoperability is a fundamental requirement when users move their digital assets between diverse metaverses. This paper first introduces the preliminaries and basics of interoperability of cross-metaverse. It then proposes the \textsf{MetaOpera} protocol for cross-metaverse interoperability and evaluated its performance. This paper also discusses the challenges and open issues of cross-metaverse interoperability. Furthermore, we hope this article is capable to inspire researchers, engineers, and educators to explore more cooperative metaverse applications to establish a better metaverse society.

\bibliographystyle{IEEEtran}

\section{Introduction}
\label{sec_intro}

The metaverse attracts significant attention in recent years. It is a computer-generated virtual world and can be intertwined with the physical world.
Users in the metaverse gain immersion during interacting with virtual objects or other users, which makes the metaverse a new paradigm of the Internet.
To achieve this, the metaverse requires the integration of various technologies. These include but not limited to augmented reality (AR), digital twin (DT), blockchain, interactivity, game, artificial intelligence (AI), networking, and Internet of Things (IoTs) \cite{lee2021all}. For example, AR provides an immersive experience;  DT generates a mirror image of physical world entities; blockchains build metaverse  economic systems.

In metaverse, an avatar is the digital representation of a user within a virtual space. The avatar can be integrated with blockchain, to become the digital DNA of this user. In addition, a user may have digital assets in the metaverse, which can be cryptocurrencies, skins, or objects that feed from the physical world. Such assets become valuable and tradable by using blockchain. Further, blockchain, such as Ethereum, forms the fundamental economic system in the metaverse. On the other hand, non-fungible tokens (NFT) ensure that non-monetary digital assets owned by a user can't be copied or fabricated.

To date, there are numerous metaverses have been built~{\color{black}\cite{Huang2022Economic}}. Examples include Roblox \cite{roblox} for productivity, Sandbox \cite{sandbox2023Sandbox} for virtual real estate, Axie Infinity \cite{axieinfinity} for gaming. Moreover, a number of top companies propose their own metaverse, such as Meta, Nvidia, and Google, to name a few~\cite{Huang2022Economic}. These metaverses usually have independent economic systems, i.e., they use different tokens or currencies, and  rules, i.e., representing avatars in 2D or 3D form. Hence, it is inconvenient for users to interchange between metaverses. This slackens the development of the metaverse society. Therefore, an efficient cross-metaverse strategy is desired to enable users to switch between metaverses with negligible effort. We call this \textit{cross-metaverse interoperability}.

In a nutshell, cross-metaverse interoperability provides a seamless experience for users to interact with metaverses. We now use an example in the commercial metaverses to illustrate the key features of cross-metaverse interoperability. Consider a user purchased a digital asset, say an `axe', from metaverse \textit{Alpha}, the cross-metaverse interoperability ensures that this  asset has the same value and functions when the user using it in another metaverse \textit{Beta}. Note that, the metaverse \textit{Alpha} and \textit{Beta} may have different economic systems based on Bitcoin, Ethereum, or some type of centralized currency derived from offline central bank. Moreover, these metaverses may have different virtual environments, but the  cross-metaverse interoperability ensures that the digital `axe' is used to `cut trees' in all of them.

In order to achieve cross-metaverse interoperability, the following two basic components need to be interoperable between metaverses:
\begin{itemize}
    \item {\em Identity}.
    %
    The identity defines the uniqueness of users and digital assets across metaverses. In addition, identities and their relationship are essential to connecting users with their actions and assets.

    For cross-metaverse interoperability, identity is fundamental for building trustworthiness. This requires the standardization of identities among various types, such as users, assets, currencies, objects, and motions, in all metaverses.
    %
    It should be noted that one natural person may create multiple user identities in one or many metaverses. However, each of these identities needs to be treated independently, the same with multiple social accounts owned by the same person.

    \item {\em Object}. This includes avatars, digital assets, and interactable entities in metaverses. Each object has its own properties, such as gender, material, rendering, and functionality. These properties can be fed from physical words, e.g., via DT and 3D scanning, or created by users out of thin air. For cross-metaverse interoperability, the objects in different metaverse with the same identity must have the same properties.

\end{itemize}

In this article, we first present a comprehensive review of existing technologies that enable cross-metaverse interoperability.
We show that these technologies lack generality, making them hard to implement for interoperability between arbitrary centralized or decentralized metaverses.
We then propose a metaverse interoperability protocol named \textsf{MetaOpera}. It enables interoperability between any two metaverses regardless of their centralized or decentralized system models. By employing NFT technologies, all metaverse components are monetized as unique assets. Thus, they are exchangeable and satisfy the requirement of crossing the metaverses. As an exemplary concrete instantiation for \textsf{MetaOpera}, we describe two \textsf{MetaOpera} workflows in detail, which demonstrate how \textsf{MetaOpera} support metaverses interoperate with each other.

To evaluate the validity of \textsf{MetaOpera}, we develop a proof-of-concept (PoC) implementation for \textsf{MetaOpera} metaverse and Sandbox metaverse. Without loss of generality, our \textsf{MetaOpera} metaverse is also applicable to any other metaverses. We evaluate the performance of \textsf{MetaOpera} and compare it with a cross-metaverse scheme based on Sidechains \cite{Peter2019Proof}. Experiment results show that the cross-metaverse proof of \textsf{MetaOpera} is roughly 1.7 KB, which is 8 times smaller than the Sidechains approach; and that the average time of cross-metaverse transactions is about 1.8 hours, which is 3 times smaller than the Sidechains approach.
Lastly, we summarize open issues and challenges faced by cross-metaverse interoperability, which include economic systems, applications, physical/virtual interoperability, security, off-line trustworthiness, universal data structure, and policy.

The rest of this paper is organized as follows. Section \ref{sec:preliminaries} introduces the preliminaries and state-of-the-art cross-metaverse technologies. Section \ref{sec:MetaOpera} demonstrates the proposed \textsf{MetaOpera} protocol.
The performance of \textsf{MetaOpera} is evaluated in Section \ref{sec:performanceEvaluation}.
Section \ref{sec:OpenIssuesandChallenge} suggests open issues and challenges for
cross-metaverse interoperability. Section \ref{sec:Conclusion} concludes this paper.

\section{Preliminaries and State-of-the-Art Cross-Metaverse Technologies}\label{sec:preliminaries}

According to the system model of metaverses, cross-metaverse interoperability is divided into two categories: (1) the interoperability between decentralized metaverses built at the top of blockchain technology, and (2) the interoperability between decentralized and centralized metaverses, where the centralized metaverses are built at the top of a centralized server. For the former, the underlying technology of interoperability is cross-chain. For the latter, the underlying technology of interoperability is on-chain and off-chain exchange. These two types of underlying technologies are described in detail below.
\begin{table*}[ht]
\caption{Cross-chain technologies}

\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{1.9cm}<{\centering}|m{3.3cm}|m{5cm}|m{1.cm}<{\centering}|m{1.cm}<{\centering}|m{1.5cm}<{\centering}|m{1.1cm}<{\centering}|}%
\hline
\textbf{Technical Scheme} & \textbf{Typical Project} & \textbf{Description}& \textbf{Security}& \textbf{Efficiency}& \textbf{Generality}& \textbf{Scalability} \\
\hline
    Notary & Interledger \cite{thomas2015protocol}, Tokrex \cite{Tokrex}, Croda \cite{croda}, BTCB \cite{binance}, HBTC \cite{Hbtc}, tBTC \cite{tBTC}, ren \cite{ren}, DeCus \cite{decus}, Hop Exchange \cite{whinfrey2021hop}, Hyphen \cite{biconomy}, Degate Bridge \cite{degate}, Wanchain \cite{wanchain}, Fusion \cite{fusion}
& A mutually trusted third party is used between different blockchains to act as a notary for cross-chain message verification and forwarding.&Low \cite{yin2022bool,xie2022zkbridge,bentov2019tesseract} & High &High& High\\
    \hline
     Hashed Time-Lock
 & WBTC \cite{wbtc}, Bridge \cite{cBridge}, Lightning Network\cite{lightningNetwork}, Zcash XCAT \cite{zcashXCAT}
& The asset receiver is forced to determine the collection and produce proof of collection to the payer within the cut-off time, or the asset will be returned via hash locks and blockchain "time" locks. The proof of receipt can be used by the payer to acquire assets of equal value on the recipient's blockchain or trigger other events.& Medium \cite{thyagarajan2022universal,tsabary2021mad} & High &Medium \cite{bentov2019tesseract}& Low\\
    \hline
  Sidechains/Relay
 &BTCRelay \cite{btcrelay}, RootStock \cite{rsk}, Plasma \cite{PLASMA}, Ronin \cite{Ronin}, Elements \cite{Elements}, LayerZero \cite{LayerZero}, Waterloo \cite{Waterloo}, Polygon \cite{Polygon},
 &Interoperation (transfer, communication, operation) of on-chain objects (assets, data, functions) through two-way anchoring and relay mechanisms.&High \cite{gavzi2019proof} & Medium \cite{gavzi2019proof,yin2021sidechains}&Medium \cite{zamyatin2019xclaim,yin2021sidechains}& High \cite{gavzi2019proof,yin2021sidechains}\\
    \hline
Relay chain
 &Polkadot \cite{Polkadot}, Cosmos \cite{kwon2019cosmos}
 & To achieve cross-chain object interoperation by the relay chain.& Medium & Low &Medium \cite{tian2021enabling}& High\\
    \hline
\end{tabular}
\label{Table:auction}
\end{table*}
\subsection{Cross-Chain Technologies}

To further understand cross-chain technologies, we review state-of-the-art cross-chain works. As described in table \ref{Table:auction}, there are four kinds of cross-chain technologies: Notary, Hash Time-Lock, Sidechains/Relay, and Relay chain. Notary scheme is the most widely used due to its high efficiency and convenient deployment. A typical example of a notary scheme is centralized exchange. All cross-chain assets in the exchange are maintained and managed by a trusted third party called notary. It is easy to see that if the notary is fail, cross-chain interoperability will be suspended. To avoid the single-point-failures, the notary consists of multiple parties based on their weights (i.e., coin) or reputation. However, the notary still suffers from security challenges such as external trust assumption. Indeed, Ronin bridge \cite{roninbridge}, a well-known notary scheme, lost 624 million USD due to malware attacks. The main reason behind this attack is that an attacker illicitly obtains the majority keys of the notary members through the malware.

To overcome the external trust assumption, the Hash time-lock scheme is proposed, which utilizes a hash function and time-lock features to achieve cross-chain interoperability. the security of the Hash time-lock scheme is based on cryptographic hardness assumptions. Consider two users: Alice with $x$ coins on chain $\mathcal{C}_1$ and Bob with $y$ coins on chain $\mathcal{C}_2$. They want to exchange their assets at the exchange rate of 1. First, Alice generates a hash value $p$ = $H$($p$) via a hash function $H(\cdot)$ and hereby uses it to create a transaction $tx_1$ that transfers $x$ coins to Bob's address on $\mathcal{C}_1$. That is, Bob can receive these $x$ coins from Alice if Bob knows the preimage $p$ corresponding to the $h$. Once the $tx_1$ is included on $\mathcal{C}_1$, Bob also uses the hash value $p$ to generate a transaction $tx_2$ that transfers $y$ coins to Alice's address on $\mathcal{C}_2$, and broadcasts it into $\mathcal{C}_2$ network. To gain these $y$ coins from Bob, Alice reveals the preimage $p$ in $tx_2$. Meanwhile, Bob also knows the $p$ via observing the $tx_2$ on $\mathcal{C}_2$. Subsequently, Bob publishes the obtained preimage $p$ in $tx_1$ and hereby receives these $x$ coins from Alice, completing the asset exchange. However, this scheme only supports monetary  exchange and thus has low scalability.

The sidechains/relay scheme supports the interoperability of multiple objects such as assets and other data, thus having high scalability. Sidechain is a blockchain that communicates with other blockchains via a two-way peg. In particular, the two-way peg is a mechanism that allows bidirectional communication between blockchains. An example of a two-way peg is simplified payment verification (SPV) in Bitcoin.
Specifically, to perceive events on a mainchain, all block headers of the mainchain are relayed into the sidechain pegged with the mainchain. The sidechain can determine whether an event has occurred on the mainchain by verifying the stored block headers of the mainchain and the Merkle tree verification path regarding the event. However, the sidechains/relay scheme can only be applied to specific blockchains, and thus has a low generality.

A relay chain is a third-party blockchain that other blockchains can connect to, which enables these blockchains to communicate with each other. The relay chain scheme has high scalability, and supports multiple objects interoperability between blockchains connected to the relay chain. However, as compared with other cross-chain schemes, the relay chain scheme has relatively low efficiency, especially in terms of cross-chain time.

\subsection{On-Chain and Off-Chain Technologies}

On-chain and off-chain technologies, often called oracle technologies, connect on-chain blockchain systems to off-chain systems, which further enables the interoperability of decentralized systems and centralized systems. Currently, oracles can be generally classified into two types: voting-based oracles and reputation-based oracles. The voting-based oracles are usually designed for  single centralized systems, which employ participants' weight to finalize interoperability outcomes. The widely deployed strategy of achieving these oracles includes stake-based oracles, multisignature-based oracles, schelling point-based oracles, and conventional oracles. However, these oracles are hard to verify the outcome integrity. On the other hand, reputation-based oracles are suitable for multiple centralized systems. Their aims are to authenticate the integrity of interoperability outcomes. These oracles utilize software (i.e., TLS protocol) or hardware (i.e., Intel Software Guard Extension) to generate a proof. The performance comparison of oracles is shown in Table \ref{Table:on-off-chain}.

\begin{table*}[ht]
\caption{Oracle technologies}

\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{3cm}<{\centering}|m{2.6cm}|m{5.2cm}|m{1.3cm}<{\centering}|m{1.3cm}<{\centering}|m{1.9cm}<{\centering}|}%
\hline
\textbf{Technical Scheme} & \textbf{Specific Type} & \textbf{Description}& \textbf{Security}& \textbf{Integrity}& \textbf{Confidentiality} \\
\hline
 \multirow{4}{*}{Voting-based Oracles}
& Stake-based \cite{merlini2019public, adler2018astraea, ryuuji2018Shintaku, nelaturu2020public, peterson2015augur, tellor2021Tellor, dIA2021Decentralized, paul2021Truthcoin} & This scheme employs the stake held by participants for finalizing the outcome. Participants are rewarded if the outcome is matched and penalized otherwise. & High & Low & Low \\
    \cline{2-6}
      & Multi-signature based \cite{orisi2014Orisi, gnosis2017Gnosis, delphi2017Delphi, moudoud2019iot, dOS2019DOS}
& Finalizing the outcome is determined collectively by multi-participants via making a signature on the outcome. & Medium & Medium & Low \\
    \cline{2-6}
 & Schelling point based \cite{vitalik2014SchellingCoin, roman2017Oracul, MarkerDAO2014The}  & According to the median value, the outcome is derivated from a group of data providers' answers. & Low  & Low & Low  \\
    \cline{2-6}
 & Conventional \cite{IOTA2021Introducing, eskandari2017feasibility, zhang2020industrial, Thomas2020ternity}
 & The outcome is directly from the raw answer of the data provider.& Low & Low & Low \\
    \hline
 \multirow{3}{*}{Reputation-based Oracles} & Software-based Proof \cite{zhang2020deco, guarnizo2019pdfs, tlsnotary2023TLSnotary, bridge2021oracle, liang2021polkaoracel}
 & Utilizing the TLS/SSL protocols, the scheme generates a data authenticate proof which is used to verify the integrity of outcomes.& Medium & Medium & Medium \\
    \cline{2-6}
 & Hardware-based Proof \cite{zhang2016town, schaad2019integration, coldcard2021coldcard, ellis2017chainlink} & The scheme provides the integrity and conidentiality for the outcome based on the Software Guard Extension (SGX) technology in the Inter CPUs. & Medium & High & High \\
    \cline{2-6}
 & Proofless \cite{wang2019novel, al2019decentralized, fujihara2019proposing, de2017witnet}
 & The scheme retrieves directly from data sources without providing authenticated proof of the outcome. & Low & Low & Low \\
    \hline
\end{tabular}
\label{Table:on-off-chain}
\end{table*}

\subsection{Cross-Metaverse Technologies}

In terms of cross-metaverse interoperability,
industrials have proposed prototypes.
For example, \textit{STYLE} protocol \cite{styleprotocol2023}, which is a virtual asset infrastructure across-metaverse, has been proposed in 2022 and will be implemented this year. The goal of \textit{STYLE} is to enable assets to exchange across the metaverses. To achieve this, two key features: usability and visualization for assets, are introduced into this protocol. Cross-metaverse avatar scheme \cite{crossmetaverse2023} aims to enable avatar interoperability across-metaverse. Same with in the real world to interact and communicate, avatars, a digital representation in metaverse, also allow people to feel and travel in multiple metaverses. Similarly, the scheme will be launched in 2023. In academics, Huang et al. \cite{Huang2022Economic} presented a cross-chain ecosystem for metaverse. As an example, this work depicts assets interoperability between Sandbox’s and Axie Infinity’s metaverses. However, this study focuses only on decentralized metaverses. Chen et al. \cite{chen2022cross} proposed a cross-platform metaverse data management system. The system designs plug-ins for different metaverse/games, enabling the profile and space share cross-platform metaverse.

\section{\textsf{MetaOpera} Protocol}\label{sec:MetaOpera}
\begin{figure*}[t]
    \centering
\includegraphics[width=0.95\textwidth]{figure/MetaOperaProtocol.pdf}
    \caption{The design of \textsf{MetaOpera} illustrated with the example of four metaverse interoperability. The blue arrows denote the direction of cross-metaverse object transfer. For clarity we only show two workflows of \textsf{MetaOpera} and the opposite direction is symmetric.}
    \label{fig:MetaOperaProtocol}
\end{figure*}
In this section, we present a novel cross-metaverse interoperability protocol: \textsf{MetaOpera}. We first give an overview of \textsf{MetaOpera}, and then present its core components and workflow.

\subsection{Overview}

At a high level, \textsf{MetaOpera} is a cross-metaverse interoperability infrastructure, which enables interoperability between any two metaverses. \textsf{MetaOpera} implements NFT technologies to monetize all metaverse components as unique assets. Therefore, arbitrary metaverse users and objects are able to interoperate with each other. Its key idea is shown in Figure \ref{fig:MetaOperaProtocol}. Briefly, the user of the metaverse connected to \textsf{MetaOpera} first locks its asset, and then mints the corresponding asset, in the form of NFT, in the \textsf{MetaOpera}. Next, the user of the \textsf{MetaOpera} stakes its NFT and then mints the corresponding NFT in another metaverse it wishes, completing metaverse object interoperability.

\subsection{\textsf{MetaOpera} Core Components}

MaoetaOpera is essentially a relay metaverse built at the top of \textsf{MetaOpera} blockchain, which is used to connect another metaverse. Upon connecting to the \textsf{MetaOpera}, any metaverse can communicate with each other. To achieve a variety of metaverse interoperability, \textsf{MetaOpera} has two key underlying technologies: cross-chain technology and on-chain and off-chain technology. The former can support \textsf{MetaOpera} to interoperate with the decentralized metaverse based on blockchain. The latter can achieve \textsf{MetaOpera} to interoperate with the centralized metaverse built at top of centralized servers. these underlying technologies adopted in the \textsf{MetaOpera} are resilient. To reach high efficiency across decentralized metaverse, for instance, the cross-chain scheme may be a notary technology as described in Table \ref{Table:auction}.

There are five components in \textsf{MetaOpera} listed as follows:

\begin{itemize}
    \item Metaverse. A metaverse is a virtual world. Metaverses are classified into two categories: decentralized metaverse (DM) and centralized metaverse (CM) based on underlying technologies. Here, DM is built at the top of decentralized blockchain technology. while CM is built at the top of centralized serves.
    \item Object. An object is a virtual digital item in the metaverse, such as cryptocurrency, avatar, skin, pet, fashion, etc. These objects can be transferred, sold, rented, and staked across metaverses. Each metaverse includes \textit{outbound objects} and  \textit{inbound objects}. An object is referred to as an outbound object if it had been locked in the metaverse it belongs; subsequently, a corresponding object will be minted in another metaverse. On the contrary, an inbound object denotes the object moved from another metaverse.
    \item Owner. An owner represents a metaverse user, who holds some objects and wishes to transfer them from one metaverse to another metaverse.
    \item Customizer. A customizer is a \textsf{MetaOpera} worker who assists in object transformation from \textsf{MetaOpera} to another metaverse in exchange for a reward. For example, the 2D object of \textsf{MetaOpera} can be tailored into the 3D object residing on a metaverse through a customizer.
    \item NFT. NFT (non-fungible token) is a unique and exchangeable digital token. NFT has the characteristics of rareness, indivisibility, and uniqueness. Thus, it can denote the ownership of an object from metaverse, specifically for the centralized metaverse.
\end{itemize}

\subsection{\textsf{MetaOpera} Workflow}

In this subsection, we demonstrate the interoperability workflow of the \textsf{MetaOpera} by depicting two across-metaverse interoperability scenarios, see in Figure \ref{fig:MetaOperaProtocol}.
The first workflow is DM to DM, e.g., Axie Infinity metaverse \cite{axieinfinity} to \textsf{MetaOpera} to Sandbox metaverse \cite{sandbox2023Sandbox}. The other workflow is CM to CM, e.g., Minecraft metaverse \cite{minecraft} to \textsf{MetaOpera} to Roblox metaverse \cite{roblox}. It is worth noting that \textsf{MetaOpera} can support any two metaverses to interoperate regardless of the CM or DM models of the metaverse.

\subsubsection{DM to \textsf{MetaOpera} to DM}

   As depicted in Figure\ref{fig:MetaOperaProtocol}, two decentralized metaverses (DM), Axie Infinity and Sandbox, can communicate with each other through \textsf{MetaOpera}. Specifically speaking, the owner of Axie Infinity wishes to transfer assets into Sandbox. First, the owner issues a transaction $tx_{x1}$ that locks its asset \textit{Axies}. Once it has been locked, \textit{Axies} will become an outbound object in Axie Infinity. Meanwhile, the proof attesting to the validity of $tx_{x1}$ is generated by a committee of \textsf{MetaOpera}. Here the committee is a notary scheme described in Figure \ref{Table:auction}, The members of the committee select from the maintainer of \textsf{MetaOpera} according to their weights (i.e., coins). If the above $tx_{x1}$ and its proof are considered valid, \textsf{MetaOpera} will mint an NFT corresponding to \textit{Axies}, The minting action is achieved by a mint transaction $tx_{x2}$ generated by the owner. Until now, the owner of Axie Infinity has transformed its \textit{Axies} into the NFT of \textsf{MetaOpera}.

    Further, the owner sequentially transfers the NFT corresponding to \textit{Axies} into Sandbox. This process is similar to the transfer from Axie Infinity to \textsf{MetaOpera}. The main difference is that a customizer may participate in the transformation of object format, such as casting 2D NFT into 3D NFT, The reason behind the difference is the heterogeneity of metaverse model so that an object of a metaverse is incompatible with another metaverse version. The owner first stakes its NFT corresponding to \textit{Axies} in \textsf{MetaOpera} by issuing a staking transaction \textit{$tx_{x3}$}. According to the NFT format, a customizer tailors it into another NFT format supported by Sandbox. Subsequently, proof testifying that \textit{$tx_{x3}$} is valid is produced by the committee of \textsf{MetaOpera}. Finally, Sandbox mints corresponding NFT to the owner based on the proof and NFT format cast by the customizer, completing the interoperability for Axie Infinity and Sandbox.

\subsubsection{CM to \textsf{MetaOpera} to CM}

    Upon connecting to the \textsf{MetaOpera}, any two centralized metaverse (CM) can interoperate with each other. Figure \ref{fig:MetaOperaProtocol} shows such an example that an avatar of Minecraft travels to Roblox. The owner of Minecraft generates a lock transaction \textit{$tx_{y1}$} to lock its avatar. A committee of \textsf{MetaOpera} observes the Minecraft state. Here the committee is a multi-signature oracle described in Table \ref{Table:on-off-chain} and consists of \textsf{MetaOpera} users. If \textit{$tx_{y1}$} is confirmed in Minecraft. The committee will generate a proof for \textit{$tx_{y1}$} to convince all \textsf{MetaOpera} maintainers that the avatar has been locked successfully. Once the proof is generated, the owner issues a mint transaction \textit{$tx_{y2}$} to mint an NFT corresponding to the avatar into its \textsf{MetaOpera} address. The action of minting the NFT will be implemented if the \textit{$tx_{y2}$} and proof are considered valid. This means that the avatar has transferred from Minecraft to \textsf{MetaOpera}.

    Next, the owner further transfers the avatar from \textsf{MetaOpera} to Roblox. The owner first generates a staking transaction \textit{$tx_{y3}$} to lock the NFT above. Similarly, the proof for \textit{$tx_{y3}$} is also generated. A customizer issues a mint transaction \textit{$tx_{y4}$} in Roblox to cast an NFT-derivative corresponding to the locked NFT. Where NFT-derivative is not NFT but an object compatible with Roblox, since Roblox does not support NFT. To keep the format persistence of the NFT-derivative and the Minecraft avatar, casting NFT-Derivative is essential. This is done by the customizer. The above casting action will be executed eventually if the \textit{$tx_{y4}$} and proof are considered valid. Until now, the avatar of Minecraft has been transferred into Roblox, completing the interoperability for Minecraft and Roblox.

\subsubsection{DM/CM to \textsf{MetaOpera} to CM/DM}

As discussed earlier, \textsf{MetaOpera} is a decentralized metaverse built at the top of the blockchain.
Objects are able to interoperate from DM or CM to \textsf{MetaOpera} and then interoperate to DM or CM again.
Alternatively, \textsf{MetaOpera} can support objects interoperating from DM to CM or CM to DM.

\section{Performance Evaluation}\label{sec:performanceEvaluation}

In this section, we implement the proposed \textsf{MetaOpera} protocol and evaluate its performance. We first measure the cross-metaverse proof size and the average time of cross-metaverse transactions. We then compare them with a state-of-the-art cross-metaverse scheme based on Sidechains \cite{Peter2019Proof}.

\textbf{Implemention Setting.} To simulate the performance of \textsf{Metaopera} prorocol from Section \ref{sec:MetaOpera}, we make a proof-of-concept (PoC) implementation for \textsf{Metaopera} and Sandbox. Without loss of generality, the PoC implementation is also applicable to both \textsf{Metaopera} and anyone metaverse connected to \textsf{Metaopera}. In our PoC implementation, the blockchain of \textsf{Metaopera} is instantiated as Cardano \cite{aggelosre2017Ouroboros}. While the blockchain of Sandbox is based on Ethereum \cite{buterin2014next}, which follows the Sandbox implementations of \cite{sandbox2023Sandbox}). The PoC implementations for \textsf{MetaOpera} and Sandbox are executed in a personal platform installed with Windows 11 operating system and equipped with Intel(R) Core(TM) i7-12700KF CPU 3.60 GHz 32.00GB RAM. We carry out our \textsf{MetaOpera} blockchain in standard C language. To achieve committee members' vote, the multi-signature scheme \cite{boldyreva2003Threshold}, a cryptographic primitive, is employed in our PoC implementations. Here the size of public key $|vk_i|$ = 272 bits, the size of signature $|\sigma_i|$ = 528 bits, the size of proof-of-possession $|POP|$ = 528 bits. A 256-bit hash function $H(\cdot)$ is also applied in the PoC implementations, meaning that $|H(\cdot)|$ = 256 bits. Following Cardano implementation, we denote by $k$ a common prefix parameter. To form a decentralized \textsf{Metaopera} committee, the chain quality, a blockchain fundamental security property, is adopted in the committee selection. In short, the committee members are selected from nodes that have generated any $k$ consecutive blocks of Cardano. Moreover, we set that the transaction size $|tx|$ = 250 bytes, block height size $|h|$ = 32 bytes, and the random number size $|r|$ = 32 bytes, these parameters are important components of the above proof. On the other hand, we use $k^{\prime}$ to indicate a common prefix parameter of Ethereum. In addition, both the block-generating times of Cardano and Ethereum are set to 5 seconds.

\textbf{Implementations and Evaluations.} In our \textsf{Metaopera}, the proof attesting to the validity of cross-metaverse transactions is generated by a committee of \textsf{Metaopera}. Its size affects the efficiency of cross-metaverse transactions, For example, The larger the proof size is, the longer its verification time will be. Thus, we evaluate it. A proof is composed of public keys, signatures, and hash values. Based on the principle of the adopted multi-signature scheme, the proof can be further improved by the optimized tips used in \cite{Peter2019Proof}. Formally speaking, the improved proof can be denoted as
$|tx|+|h|+|r|+0.1\cdot k \cdot |vk_i|+ |\sigma_i|$. As depicted in Figure \ref{CommitteeProof}, the proof size of \textsf{Metaopera} increases linearly in the size of committee $\textit{c}$. This is because the proof size increases as the number of committee members increases. More precisely, in the case of the committee size of 400, the proof size is roughly 1.7 KB, which is 8 times smaller than the proof size of PoS sidechains \cite{Peter2019Proof}.
\begin{figure}[ht]
	\centering
	\includegraphics[width=0.400\textwidth]{figure/CommitteeProof.pdf}
	\caption{The proof size at different committee sizes.}
	\label{CommitteeProof}
\end{figure}

In our PoC implementation, cross-metaverse transactions consist of two transactions: \textit{tx} included in \textsf{Metaopera} and  \textit{$tx^{\prime}$} included in Sandbox. To verify the validity of \textit{$tx$}, the proof is essential. Therefore, the time of cross-metaverse transactions includes both the confirmed time of \textit{tx} and \textit{$tx^{\prime}$}, as well as the proof generating time. Let \textit{k} and \textit{$k^{\prime}$} be 400 and 500 respectively. We have that the confirmed time of \textit{tx} is roughly 5\textit{k} = 5 $\times$ 400 = 33.33 minutes and the confirmed time of \textit{$k^{\prime}$} is roughly 5\textit{$k^{\prime}$} = 5 $\times$ 500 = 41.67 minutes. In the case of a committee size of 400, we measure the time \textit{t} that these committee members collectively generate the proofs for 200 different cross-metaverse transactions. Measurement results show that the average time for generating a proof is roughly 1.5 minutes. To this end, the average time of cross-metaverse transactions is roughly 76.5 minutes, as described in Table \ref{Table:TimeCrossMetaverse}. As a comparison, the average time of transactions of Sidechains \cite{Peter2019Proof} is 5.251 hours, which is 3 times more than our \textsf{MetaOpera}.

\begin{table*}[ht]
\caption{The average time of cross-metaverse transactions.}
\centering
\footnotesize
\renewcommand{\arraystretch}{1.5}
\renewcommand{\arraystretch}{1.5}
\begin{tabular}{|m{5.5cm}<{\centering}|m{2.2cm}<{\centering}|m{2.4cm}<{\centering}|m{2.4cm}<{\centering}|m{2.6cm}<{\centering}|}%
\hline
\textbf{Time of cross-metaverse transaction} & \textbf{\textsf{MetaOpera} time} & \textbf{\textsf{MetaOpera} time/h} & \textbf{Sidechains \cite{Peter2019Proof} time} & \textbf{Sidechains \cite{Peter2019Proof} time/h} \\
\hline
\textbf{Confirm Time of \textit{tx} in \textsf{MetaOpera}} & \textit{2k} & 1.112 & \multirow{2}{*}{\textit{10k}} & \multirow{2}{*}{5.556} \\
\cline{1-3}
\textbf{Proof Generating Time} & \textit{t} & 0.025 & & \\
\hline
\textbf{Confirm Time \textit{$tx^{\prime}$} in Sandbox} & \textit{$k^{\prime}$} & 0.695 & \textit{$k^{\prime}$} & 0.695 \\
\hline
\textbf{Average time of cross-metaverse transaction} & \textit{2k} + \textit{t} + \textit{$k^{\prime}$} & 1.832 & \textit{10k} + \textit{$k^{\prime}$} & 6.251 \\
\hline
\end{tabular}
\label{Table:TimeCrossMetaverse}
\end{table*}

\section{Open Issues and Challenges}\label{sec:OpenIssuesandChallenge}
Although we have proposed the \textsf{MetaOpera} protocol, cross-metaverse interoperability is still in its initial stage from the perspective of either industry or academia. In this section, we summarize open issues and challenges in cross-metaverse interoperability and suggest potential future research directions.

\subsection{Economic System}

To date, most metaverse builds their economic system using smart contracts on the Ethereum blockchain. This raises the risk that a single security hazard in Ethereum will affect a majority of metaverses. To this end, diversified economic systems are desired in co-existing metaverses, to enhance their robustness against single-system crashes. This also requires cross-metaverse interoperability of these systems.

\subsection{Applications}
  At the current stage of metaverse development, almost all the applications
  provided by the blockchain-based metaverses are the circulation of cryptocurrencies and NFT. However, the metaverse has more potential applications other than this. For example, the immersive experience can be used for a deep interaction between humans and multiple physical or virtual environments. This needs further development of cross-metaverse interoperability technologies to boost the application scenarios of the metaverse.

\subsection{Physical/Virtual Interoperability }
Most research and implementation of metaverse focus on mapping physical objects to the virtual metaverse. There are a number of technologies that can be used, such as 3D scanning. However, how the actions in the virtual world reflect in the physical world is also a key concern. This is important for production metaverse applications such as surgery and driving. Such interoperability requires trustworthiness, low latency, and accuracy of the reflection of the action.

\subsection{Security}
The security issues in cross-metaverse interoperability concern with authentication and permissions for assets and data exchanges. In particular, when an asset or object data is crossing metaverses, both metaverses need to confirm their ownership. Moreover, these metaverses need to ensure the asset or data is only valid in only one metaverse. For the objects existing in a metaverse, permission is important to specify who and what actions can be interacting with the objects.

\subsection{Off-line Trustworthiness}
Even though the Internet is universal existence in the physical world, it is inevitable that some locations still have no Internet connection, such as in a desert. After an object lost connection with the metaverse, its properties may be changed before back online. In such a situation, cross-metaverse interoperability needs to ensure the trustworthiness of the changes from a tiny centralized server, i.e., an offline data collector, to the centralized or decentralized online metaverse.

\subsection{Universal Data Structure}
Physical objects have common properties, such as shape, weight, and color. However, some of their properties are unique and independent. For example, a cup has the capacity property, but a pencil does not. Hence, cross-metaverse interoperability needs to design a universal data structure to describe the physical objects in the metaverse. In addition, this data structure needs to be a standard for all metaverses to enable interoperability.

\subsection{Universal Policy}

The challenges of the universal policy include two perspectives: governance and metaverse platform. In terms of governance policy, a universal law or rule is required to restrain criminal behavior. This is because metaverses have independent rules, and their evaluation criteria for improper behavior are different. Hence, a universal governance policy is vital to prevent cross-metaverse crimes.  On the other hand, existing metaverse platforms usually have different user policies. Hence, users are hard to control the privacies, copyrights, and exchange of their assets in multiple metaverses. Therefore, a universal metaverse platform policy is also critical for  cross-metaverse interoperability.

\section{Conclusion}\label{sec:Conclusion}
Cross-metaverse interoperability is a fundamental requirement when users move their digital assets between diverse metaverses. This paper first introduces the preliminaries and basics of interoperability of cross-metaverse. It then proposes the \textsf{MetaOpera} protocol for cross-metaverse interoperability and evaluated its performance. This paper also discusses the challenges and open issues of cross-metaverse interoperability. Furthermore, we hope this article is capable to inspire researchers, engineers, and educators to explore more cooperative metaverse applications to establish a better metaverse society.

\bibliographystyle{IEEEtran}


\section{Introduction}\label{sec:intro}

The nonlinear Helmholtz equation (NLH) models the propagation of electromagnetic
waves in Kerr media, and describes a range of important phenomena in nonlinear
optics and in other areas \cite{FibTsy01,FibTsy05,BarFibTsy07}.
In this paper, we consider forward and inverse problems regarding the following nonlinear Helmholtz equation in $\mathbb R^3$:
\begin{equation}\label{equ:Helm}
 \Delta U(\boldsymbol{x}) + k^2  \nu(\boldsymbol{x}) U(\boldsymbol{x}) =  -\epsilon(\boldsymbol{x}) F(|U(\boldsymbol{x})|^2) U(\boldsymbol{x}),
\quad \boldsymbol{x} \in \Omega \subset \mathbb R^3.
\end{equation}
where $\boldsymbol{x}=(x_1,x_2,x_3)$ are the spatial coordinates, $U = U(\boldsymbol{x})$ denotes
the scalar electric field, $|\cdot|$ denotes the Euclidean norm,
$\Delta = \partial^2_{x_1} + \partial^2_{x_2} + \partial^2_{x_3}$ is
the Laplacian operator, $\nu(\boldsymbol{x})$ and $\epsilon(\boldsymbol{x})$ are some functions.

For simplicity, we consider the case where $\Omega$ is a spherical shell
between two concentric spheres of radii $R_0$ and $R_1$ centred at the origin,
that is
\[
  \Omega := \{ \boldsymbol{x} \in \mathbb R^3:    R_0 \le |\boldsymbol{x}| \le R_1 \}.
\]
We also assume that $\nu$ and $\epsilon$ are radially symmetric and the $U$
satisfies the axially symmetric boundary conditions
\begin{equation}\label{equ:boundary}
U|_{r=R_0} = H(t), \qquad
\left. \frac{ \partial U } {\partial r } \right|_{r=R_0} = G(t), \quad -1 \le t \le 1,
\end{equation}
where $r = |\boldsymbol{x}|$ and $t = \cos \theta$, with $\theta$ being the polar angle
measured from the north pole.
The solution $U$ is then axially symmetric as well.
Equation~\eqref{equ:Helm} takes the form
\begin{equation}
\label{eq:helmradial}
\frac{1}{r}\frac{\partial^2}{\partial r^2}(rU(r,t))+\frac{1}{r^2}\Delta^{(L)}U(r,t)+ k^2  \nu(r) U(r,t) =  -\epsilon(r) F(|U(r,t))|^2) U(r,t),
\end{equation}
where $\Delta^{(L)}$ is the Legendre differential operator defined below in \eqref{eq:legendreeqn}.

In the forward problem, $U$ is unknown, $F$ is non-linear, e.g.  $F(|U|^2) = |U|^{2p}$ with
some integer $p$, or $F=\sin(|U|^2)$, and we find an approximation of $U$.
In the inverse problem, the values of the solution $U(\boldsymbol{x}_q)$, for $q=1,\ldots,Q$ are known, and the problem is to approximate the unknown nonlinear function $F$.

The paper is organized as follows. In Section~\ref{sec:forward} we introduce a spectral method
for the forward problem and a fast algorithm to evaluate the non-linear term. In Section~\ref{sec:inverse}
we describe an algorithm for the inverse problem to identify the nonlinearity of the $F$ via its
Chebyshev coefficients. The paper is concluded with some numerical experiments described
in Section~\ref{sec:numerics}.

\section{Background}\label{sec:back}

The Legendre polynomial $P_\ell$ is a polynomial of degree $\ell$ with leading coefficients.
We have the orthogonality relation
\begin{equation}
\label{eq:legendreortho}
\int_{-1}^1P_\ell(t)P_{\ell'}(t)dt=\frac{2\ell+1}{2}\delta_{\ell,\ell'}.
\end{equation}
The polynomials $P_\ell$ satisfy
\begin{equation}
\label{eq:legendreeqn}
\Delta^{(L)}P_\ell(t)=(1-t^2)P_\ell''(t)-2tP_\ell'(t)=-\ell(\ell+1)P_\ell(t)=-\lambda_\ell P_\ell(t).
\end{equation}
The Fourier-Legendre coefficients of an integrable function $g: [-1,1]\to \mathbb R$ are defined by
\begin{equation}
\label{eq:legendrefour}
\hat{g}(\ell)=\int_{-1}^1 g(t)P_\ell(t)dt, \qquad \ell\in \mathbb Z_+,
\end{equation}
To compute the Fourier-Legendre coefficients of a product of two functions, we define
\begin{equation}
\label{eq:legendreconn}
\Gamma(L;\ell,\ell')=\frac{2L+1}{2}\int_{-1}^1 P_L(t)P_\ell(t)P_{\ell'}(t)dt.
\end{equation}
It is known that $0\le \Gamma(L;\ell,\ell')\le 1$ and $\sum_{L=0}^{\ell+\ell'} \Gamma(L;\ell,\ell')=1$,
see \cite[Chapter~5]{askeyspecial}.
Obviously, the following formal equation holds:
\begin{equation}
\label{eq:jacobiconv}
\widehat{g_1g_2}(L)=\sum_{\ell,\ell'}\Gamma(L;\ell,\ell')\hat{g_1}(\ell)\hat{g_2}(\ell').
\end{equation}
In terms of the sequences of Fourier-Legendre coefficients, we denote
\begin{equation}
\label{eq:jacobiconvfour}
\left(\hat{g_1}\star \hat{g_2}\right)(L)=\sum_{\ell,\ell'}\Gamma(L;\ell,\ell')\hat{g_1}(\ell)\hat{g_2}(\ell').
\end{equation}

\section{Spectral method for the forward problem}\label{sec:forward}
In this section,  we discuss how to construct a numerical solution to \eqref{equ:Helm}.
For this purpose, we first establish some notation.

The spectral method for the forward problem is to find an approximation $U_N$ defined by
\begin{equation}\label{AxSuN}
   U_N(r, t) = \sum_{\ell=0}^N  u_{\ell}(r) P_{\ell}(t),\qquad u_\ell(r)=\widehat{u(r,\cdot)}(\ell),
\end{equation}
and find the coefficients $u_\ell(r)$ so that $U_N$ satisfies \eqref{eq:helmradial}.
 By substituting $U_N$ into \eqref{eq:helmradial},  we deduce using \eqref{eq:legendreeqn} that
\begin{equation}\label{ode:uell}
\frac{2}{2\ell+1} \left( \frac{1}{r} \frac{\partial^2}{\partial^2 r} (r u_{\ell} )
 - \frac{\lambda_\ell}{r^2} u_{\ell}  + k^2 \nu(r)  u_{\ell} \right) =
-\epsilon(r)  \mathcal{F}_{\ell},
\end{equation}
where
\begin{equation}\label{eq:Fell}
 \mathcal{F}_{\ell} = \mathcal{F}_{\ell}(r)= \int_{-1}^{1} U_N(r,t) F(|U_N(r,t)|^2) P_{\ell}(t) dt .
\end{equation}
Equivalently,
\begin{equation}\label{ODE_Fell}
\frac{ \partial^2}{\partial r^2} (ru_{\ell}) = \frac{\lambda_{\ell}}{r} u_{\ell} - rk^2\nu u_{\ell} - r\epsilon(r)  (\ell+1/2) \mathcal{F}_{\ell}
\end{equation}

We note from \eqref{eq:Fell} that $\mathcal{F}_L$'s are the Fourier-Legendre coefficients of $U_N(r,t) F(|U_N(r,t)|^2)$.
Clearly, there exist $\alpha,\beta$ such that  $|U_N|^2\in [\alpha,\beta]$.
We assume $\alpha,\beta$ to be known.
Our strategy is to approximate $F$ using its Fourier-Chebyshev expansion:
\begin{equation}
\label{eq:Fcheb}
F(|U_N|^2)\approx \mathcal{P}_d\left(\frac{2|U_N|^2-\alpha-\beta}{\beta-\alpha}\right)=\sum_{k=0}^{2^d-1} a_kT_k\left(\frac{2|U_N|^2-\alpha-\beta}{\beta-\alpha}\right),
\end{equation}
where $T_k$'s are the Chebyshev polynomials defined by $T_k(\cos\phi)=\cos(k\phi)$.
We need to evaluate the Fourier-Legendre coefficients $\mathcal{F}_L$ of $U_NF(|U_N|^2)$ in terms of the $a_k$'s.
In Section~\ref{sec:legtocheb}, we describe a general procedure to accomplish this task efficiently.

Towards this goal, we note first using \eqref{eq:jacobiconv} that
$$
|U_N|^2(t) = \left( \sum_{\ell=0}^N u_{\ell} P_{\ell} (t) \right)^2 = \sum_{\ell=0}^{2N} d_L P_L(t), \qquad d_L=(\{u_\ell\}\star\{u_{\ell}\})(L),
$$
\begin{equation}
\label{eq:translegendre}
\frac{2|U_N(t)|^2-\alpha-\beta}{\beta-\alpha}=\frac{1}{\beta-\alpha}\left\{(2d_0-\alpha-\beta)P_0(t)+2\sum_{\ell=1}^{2N} d_L P_L(t)\right\}.
\end{equation}
Similarly,
\begin{equation}\label{eq:cLPL}
|U_N|^2 U_N  = \left(  \sum_{\ell=0}^{2N} d_\ell P_{\ell} (t)\right) \left( \sum_{\ell=0}^N u_{\ell'}  P_{\ell'}(t) \right)
               = \sum_{L=0}^{3N} c_L P_L(t), \qquad c_L=(\{d_\ell\}\star\{u_\ell\})(L).
\end{equation}
By comparing \eqref{eq:cLPL} with \eqref{eq:Fell} we also have
$
  c_L = \frac{2L+1}{2} \mathcal{F}_L.
$

We convert the system of second order ODEs \eqref{ODE_Fell} to first order ODEs as follows.

For $\ell = 0,\ldots,N$ let
$
    v_{\ell} = \frac{ d (r u_{\ell}) } {dr},
$
then the boundary conditions are
$
   v_{\ell}(R_0) = u_{\ell}(R_0) + R_0 \frac{d u_{\ell}}{dr}|_{r=R_0} = h_{\ell} + R_0 g_{\ell}.
$

 Let
\[
\vec{Z} = [  Z_1 \;  Z_2 \; \cdots \; Z_{2N+2}]^\top =
   [ ru_0 \; ru_1 \; \cdots  \; ru_N \; v_0 \; v_1 \; \cdots \; v_N]^\top
\]
We can re-write the above system into the form $d\vec{Z}/dr = \mathfrak{F}(r,\vec{Z})$ with
\[
\mathfrak{F}(r,\vec{Z}) =
\begin{bmatrix}
Z_{N+2} \\
Z_{N+3} \\
\vdots \\
Z_{2N+2} \\
\frac{\lambda_0}{r^2} Z_{1}
 - k^2 \nu(r) Z_{1} - r\epsilon(r) (0+1/2) \mathcal{F}_{0} \\
\frac{\lambda_1}{r^2} Z_{2}
 - k^2 \nu(r) Z_{2} - r\epsilon(r) (1+1/2) \mathcal{F}_{1} \\
\vdots \\
\frac{\lambda_L}{r^2} Z_{N+1}
 - k^2 \nu(r) Z_{N+1} - r\epsilon(r) (L+1/2) \mathcal{F}_{N}
\end{bmatrix}
\]
with the initial condition
\begin{align*}
Z(R_0) &=
[ru_0(R_0) \; ru_1(R_0) \; \cdots \; r u_N(R_0) \; v_0 (R_0)\; v_1(R_0) \; \cdots \; v_N (R_0) ]  \\
&=
[R_0 h_0 \; R_0 h_1 \; \cdots \; R_0 h_N \;  h_0 + R_0 g_0 \;  h_1 + R_0 g_1 \; \cdots \; h_N + R_0 g_N]
\end{align*}

We may now use standard ODE solvers.
In our experiments we used the adaptive solver \textsf{ode45} in Matlab\textsuperscript{\textregistered}.

\section{The inverse problem}\label{sec:inverse}
In the inverse problem, we are given the values
$U(r_i)$ are known on the collection of points $\mathcal{R}:=\{r_i : i=1,\ldots, M\}$ which might not be equally spaced on the
interval $[R_0, R_1]$ since they might come from an adaptive ODE solver.
The corresponding values $u_\ell(r_j)$ can be computed using numerical integration.
In our numerical experiments, we can extract $u_{\ell}$ directly from the numerical solutions of the ODE solver.

Our approach is to evaluate $\mathcal{F}_L$ first using \eqref{ode:uell}.
In turn, this requires computing the second derivative of  $ru_{\ell}$ at $r=r_j$ for non-equidistant values $r_j$.
These are  computed  by
\[
\left. \frac{\partial^2}{\partial^2 r} (ru_{\ell}(r) ) \right|_{r = r_j}
                \approx
\frac{h^{-}_{j} r_{j+1}u_{\ell}(r_{j+1})  + h^{+}_{j} r_{j-1}u_{\ell}(r_{j-1}) - (h^{+}_j + h^{-}_j) r_j u_{\ell}(r_j)}
                { 0.5 h^{-}_j h^{+}_j (h_j^{+} + h_j^{-})},
\]
with $h^{+}_j = r_{j+1} - r_{j}$ and $h^{-}_j = r_{j}-r_{j-1}$.
We then compute the approximated $\mathcal{F}_{\ell}$ at $r = r_j$ via
\[
\mathcal{F}_{\ell} = \frac{-2}{(2\ell+1)\epsilon(r)} \left( \frac{1}{r} \frac{\partial^2}{\partial^2 r} (r u_{\ell} )
 - \frac{\lambda_\ell}{r^2} u_{\ell}  + k^2 \nu(r)  u_{\ell} \right)
\]
The next task is to approximate $F$ from the values of $\mathcal{F}_L$'s.
Since we know $\mathcal{F}_L$'s, this leads to a  (not necessarily square) system of non-linear equations.
In turn, the $a_k$'s are determined using a least squares computation.
Thus, the problem reduces to computing $a_k$'s using the expansion \eqref{eq:translegendre}.

\section{Numerical experiments}\label{sec:numerics}
The expansion of a plane wave is given by Morse and Ingard \cite{MorIng68}
\begin{equation}
e^{i \boldsymbol{k} \cdot \boldsymbol{r}} =
\sum_{\ell=0}^\infty (2\ell+1) i^{\ell}
 P_\ell(\widehat{\boldsymbol{k}} \cdot \widehat{\boldsymbol{r}}) j_{\ell}(kr),
\end{equation}
where $\widehat{\boldsymbol{k}} = \boldsymbol{k} / \|\boldsymbol{k}\|$,
$\widehat{\boldsymbol{r}} =  \boldsymbol{r} /\|\boldsymbol{r}\|$, $P_{\ell}(t)$ is
the Legendre polynomial of degree $\ell$ and $j_{\ell}(kr)$ is the $\ell$th
spherical Bessel function of the first kind.
Here $\boldsymbol{r}$ is the position vector of length $r$, $\boldsymbol{k}$ is the wave
vector of length $k$. In the special case when $\boldsymbol{k}$ is aligned with
the $z$-axis, we have
\[
 e^{ikr \cos\theta} = \sum_{\ell=0}^\infty (2\ell+1) i^{\ell}
 P_\ell(\cos\theta) j_{\ell}(kr),
\]
where $\theta$ is the spherical polar angle of $\boldsymbol{r}$. With $t=\cos\theta$, we have $H = e^{ikR_0 t}$ and
\[
  h_{\ell} = (2\ell+1) i^{\ell} j_{\ell}(k R_0)
\]
and by using the identity $\frac{d}{dz}j_{\ell}(z) = j_{\ell-1}(z) - \frac{(\ell+1)}{z} j_{\ell}(z)$, we have
\begin{align*}
  g_{\ell} &= (2\ell+1) i^{\ell} \left. \frac{\partial j_{\ell}(kr) }{\partial r} \right|_{r=R_0}
   =(2\ell+1) i^{\ell}
  \frac{1}{k}\left( j_{\ell-1}(kR_0) - \frac{\ell+1}{kR_0} j_{\ell}(kR_0)\right) .
\end{align*}

\subsection{Experiment 1}
We consider the forward problem
\begin{equation}
\Delta U(\boldsymbol{x}) + k^2 \nu U(\boldsymbol{x}) = -\epsilon |U(\boldsymbol{x})|^4 U(\boldsymbol{x}),
\end{equation}
where $k,\nu$ and $\epsilon$ are positive constants
on the spherical shell $\Omega$ with inner radius $R_0=1$ and outer radius $R_1=2$.
The boundary conditions on the inner sphere are given by
\[
 U(R_0) = e^{ikR_0 t}, \quad \frac{\partial U}{\partial r} = \frac{\partial}{\partial r} e^{ikrt}|_{r=R_0}, \quad t = \cos\theta
\]
The numerical solution $U(R_1)$ of the forward problem is given in the left panel of Figure~\ref{fig:U80 sol experiment1}.
\begin{figure}[h]
\centering
\begin{tabular}{cc}
\includegraphics[width=0.5\textwidth]{solnU80.jpg} &
\includegraphics[width=0.5\textwidth]{solU50_F_sinU2.jpg}
\end{tabular}
\caption{$U(r=R_1)$ with $R_1=2$ for $\epsilon=2$, $\nu=0.1$ and $k=1$ for Experiment 1 (left panel) and Experiment
2 (right panel).}\label{fig:U80 sol experiment1}
\end{figure}

We now consider the inverse problem. On the right-hand side, in our framework $F(|U|^2) = |U|^4$, so $F(t) = t^2$. The function $F$
can be expressed as a linear combination of Chebyshev polynomials $T_0$ and $T_2$ as
\[
 F(t) = \frac{1}{2} T_0(t) + \frac{1}{2} T_2 (t).
\]
So the exact coefficients are $a_0 = 0.5$, $a_1 = 0$ and $a_2 = 0.5$.
The computed coefficients from the inverse problem $a_0, a_1, a_2$ on each ring are shown in Table~\ref{tab:FU4coeff}.

\begin{table}[h]
\centering
\begin{tabular}{|c|c|c|c|}
\hline
    $r$  & $a_0$ & $a_1$  & $a_2$ \\
    \hline
1.0009 &  5.0000e-01 & -6.3171e-06 &  5.0000e-01\\
1.0018 &  5.0000e-01 &-6.2524e-06 &  5.0000e-01\\
1.0027 &  5.0000e-01 & -6.3744e-06 &   5.0000e-01\\
1.0036 &  4.9591e-01 & -7.1347e-03 &  4.9815e-01\\
1.0065 &  4.9995e-01 &  -6.3584e-05&   4.9997e-01\\
1.0094 &  4.9996e-01 & -6.1446e-05 &  4.9997e-01\\
1.0123 &  4.9995e-01 & -6.5269e-05 &  4.9997e-01\\
1.0152 &  4.9992e-01 & -1.2534e-04  & 4.9995e-01\\
1.0181 &  4.9995e-01 & -6.4420e-05  & 4.9997e-01\\
\hline
\end{tabular}
\caption{Computed Chebyshev coefficients for $F(|U|^2) = |U|^4$} \label{tab:FU4coeff}
\end{table}

\subsection{Experiment 2}
Let $F(|U|^2) = \sin |U|^2$ and $|U|^2 \in [\alpha, \beta]$.
Let
\[
  q_k (z) := \begin{cases}
            J_0 (z), & \text{ if } k = 0,\\
            2 J_k(z), &\text{ if } k \in \mathbb N,
            \end{cases}
\]
where $J_k$ is the Bessel's function of order $k$.
From Watson's book, \cite[page 22,(3)-(4)]{Watson}, we have for $t \in [-1,1]$,
\begin{align*}
\sin (\gamma + zt) &= \sin \gamma \cos(zt) + \cos \gamma \sin(zt) \\
    &= \sin\gamma \sum_{k=0}^\infty (-1)^k q_{2k}(z) T_{2k}(t) + \cos\gamma  \sum_{k=0}^\infty (-1)^k q_{2k+1}(z) T_{2k+1}(t) \\
    &=  \sum_{k=0}^\infty \sin \left(\gamma+ \frac{2k \pi}{2} \right) q_{2k}(z) T_{2k}(t)
    + \sum_{k=0}^\infty \sin \left(\gamma+ \frac{(2k +1)\pi}{2} \right)  q_{2k+1}(z) T_{2k+1}(t) \\
     &= \sum_{n=0}^\infty \sin \left( \gamma + \frac{n\pi}{2} \right) q_n(z) T_n(t).
\end{align*}
So with $\gamma = (\alpha+\beta)/2$ and $z=(\beta-\alpha)/2$, $|U|^2 = \gamma+ zt$, then $t \in [-1,1]$ and
\[
\sin(|U|^2) = \sum_{n=0}^\infty \sin \left( \frac{\alpha+\beta}{2} + \frac{n\pi}{2}\right) q_n \left(  \frac{\beta-\alpha}{2}\right) T_n(t),
\quad t = \frac{2|U|^2-\alpha-\beta}{\beta-\alpha}.
\]

Let's assume $|U| \in [0,1]$, that is, $\alpha = 0$, $\beta = 1$ and we use only the first $8$ terms of the infinite series above to define
\begin{equation}\label{eq:FsinU}
F(|U|^2) = \sum_{n=0}^7 \sin \left( \frac{1}{2} + \frac{n\pi}{2}\right) q_n \left(  \frac{1}{2}\right) T_n(t),
        \quad t = 2|U|^2-1.
\end{equation}
So the exact coefficients are $a_n = \sin(1/2+n \pi/2) q_n(1/2)$ for $n=0,\ldots,7$.
The numerical solution of the forward problem $U(R_1)$ is given in right panel of Figure~\ref{fig:U80 sol experiment1}.
For the inverse problem, the computed
coefficients $a_n$ for $n=0,\ldots,7$ on each ring are shown in Table~\ref{tab:FsinUcoeff}.

\begin{table}[h]
\centering
\begin{tabular}{|c|c|c|c|c|}
\hline
        & $a_0$      &  $a_1$      &  $a_2$      & $a_3$ \\
exact   & 4.4993e-01 &  4.2522e-01 & -2.9345e-02 &   -4.4998e-03 \\
\hline
$r=$1.001634 & 4.4993e-01 &  4.2522e-01 & -2.9344e-02 &   -4.4999e-03\\
$r=$1.003268 & 4.4993e-01 &  4.2522e-01 & -2.9344e-02 &   -4.4999e-03\\
$r=$1.004902 & 4.4993e-01 &  4.2522e-01 & -2.9344e-02 &   -4.4999e-03\\
\hline
\end{tabular}
\begin{tabular}{|c|c|c|c|c|}
\hline
         & $a_4$ & $a_5$ & $a_6$ & $a_7$ \\
exact    & 1.5412e-04 &  1.4135e-05 & -3.2224e-07 &   -2.1090e-08 \\
\hline
$r=$1.001634 & 1.5409e-04 & 1.4148e-05 & -3.2558e-07 &  -2.0502e-08\\
$r=$1.003268 & 1.5408e-04 & 1.4150e-05 & -3.2638e-07 &  -2.0376e-08\\
$r=$1.004902 & 1.5408e-04 & 1.4150e-05 & -3.2587e-07 &  -2.0499e-08\\
\hline
\end{tabular}
\caption{Computed Chebyshev coefficients for $F(|U|^2)$ as in \eqref{eq:FsinU}} \label{tab:FsinUcoeff}
\end{table}

\section{Computational issues}\label{sec:legtocheb}
Let $f \in C([-1,1]$,
$$
\mathcal{P}_d(t)=\sum_{k=0}^{2^d-1} a_kT_k(t), \quad \mathbb{P}_d(t)=\mathcal{P}_d(f(t)), \qquad t\in [-1,1].
$$
We wish to compute the Fourier-Legendre coefficients $\{b_\ell\}$ of $\mathbb{P}_d$ explicitly and efficiently using the Fourier-Legendre coefficients of $f$ and the coefficients $a_k$.

We proceed inductively.
If $d=1$, then we observe that
\begin{equation}
\label{eq:initialization}
\begin{aligned}
\langle T_0(f), P_0\rangle&=1, \qquad \langle T_1(f), P_1\rangle=\hat{f}(1)\\
\mathbb{P}_1(t)&=\frac{1}{2}+\frac{3}{2}\hat{f}(1)P_1(t).
\end{aligned}
\end{equation}

Next, we assume that the problem is solved in the case of polynomials of degree $\le 2^{d-1}-1$.
Using the recurrence relations
\begin{equation}\label{eq:chebrecur}
 T_{2^j+k}= 2T_{2^j}T_k -T_{2^j-k}, \qquad j=1,2,\cdots, \ k=1,\cdots 2^j,
\end{equation}
it is not difficult to deduce that
\begin{equation}
\label{eq:dyadicrec}
\begin{aligned}
\sum_{k=0}^{2^d-1}a_kT_k&=\sum_{k=0}^{2^{d-1}-1}(a_k-a_{2^d-k})T_k +2T_{2^{d-1}}\sum_{k=0}^{2^{d-1}}a_{k+2^{d-1}}T_k\\
&=\mathcal{Q}_{d-1}+2T_{2^{d-1}}\widetilde{\mathcal{R}}_{d-1}
\end{aligned}
\end{equation}
for polynomials $\mathcal{Q}_{d-1}$, $\widetilde{\mathcal{R}}_{d-1}$ of degree at most $2^{d-1}$.
We let $\mathbb{Q}_{d-1}(t)=\mathcal{Q}_{d-1}(f(t))$ and $\widetilde{\mathbb{R}}_{d-1}(t)=\widetilde{\mathcal{R}}_{d-1}(f(t))$.
Given our induction hypothesis, we may now compute
\begin{equation}
\label{eq:finalsol}
\widehat{\mathbb{P}_d}= \widehat{\mathbb{Q}_{d-1}}
+2(\widehat{T_{2^{d-1}}\circ f})\star\widehat{\widetilde{\mathbb{R}}_{d-1}}.
\end{equation}
Using \eqref{eq:initialization} and \eqref{eq:finalsol}
one can compute $\widehat{\mathbb{P}_d} = \widehat{F}$ with $O(d)$ convolutions.
\begin{comment}
\subsection{Computing the triple integrals effectively}
The Legendre polynomials satisfy the following recurrent relation,
\[
  (n+1) P_{n+1}(x) = (2n+1)x P_n(x) - n P_{n-1}(x), \quad n=1,2,\ldots
\]
with $P_0 = 1, P_1 = x$. Equivalently,
\begin{align}
      x P_n(x) &= \frac{(n+1)}{(2n+1) }P_{n+1}(x) + \frac{n}{(2n+1) } P_{n-1}(x), \quad n=1,2,\ldots \nonumber\\
               &=  a_n P_{n+1} + b_{n-1} P_{n-1} \nonumber
\end{align}
Let
\begin{equation}
  P_{\ell}(x) P_m(x) = \sum_{k= | \ell-m |}^{\ell+m} C(k,\ell,m) P_k(x) \label{eqP}
\end{equation}
Then
\begin{align}
  x P_m(x) P_{\ell}(x) &= a_m P_{m+1}(x)P_{\ell}(x) + b_{m-1} P_{m-1} (x) P_{\ell} (x) \nonumber \\
   & =\sum_k [a_m C(k,\ell,m+1) + b_{m-1} C(k,\ell,m-1) ] P_k(x) \label{eq4}
\end{align}
On the other hand,
\begin{align}
 x P_{m}(x) P_{\ell}(x) &= \sum_k C(k,\ell,m) x P_k(x) \nonumber  \\
    &=\sum_{k} C(k,\ell,m) [ a_k P_{k+1}(x) + b_{k-1} P_{k-1}(x) ] \nonumber \\
    &=\sum_k [a_{k-1} C(k-1,\ell,m) + b_kC(k+1,\ell,m) ] P_k(x) \label{eq5}
\end{align}
Comparing \eqref{eq4} and \eqref{eq5} we have
\begin{align}
 a_m C(k,\ell,m+1)  &= a_{k-1} C(k-1,\ell,m) + b_kC(k+1,\ell,m) \nonumber \\
                 & \quad - b_{m-1} C(k,\ell,m-1) \label{eq6}
\end{align}
Putting  $m=0$ in \eqref{eqP} we have
\[
   C(k,\ell,0) = \delta_{\ell,k}.
\]
For $k=0$, multiplying equation \eqref{eqP} with $P_0$ and integrate on $[-1,1]$, we get
\[
  C(0,\ell,m) = \delta_{\ell,m} \frac{1}{2\ell+1}.
\]
We also have
\[
  C(k,0,m) = \delta_{k,m}.
\]
Let us define $C(k,\ell,-1)=0$ for all $k,\ell=0,1,\ldots$.
Assume that we know $C(k,\ell,j)$ for all $k,\ell = 0,1,2,\ldots$, and $-1 \le j \le m-1$, we can
use \eqref{eq6} to compute all $C(k,\ell,m)$.

From \eqref{eqP} we have
\begin{equation}
  C(k,\ell,m) = \frac{2k+1}{2} \int_{-1}^1 P_k(t) P_{\ell}(t) P_m(t) dt.
\end{equation}
\end{comment}

\paragraph{Acknowledgements}
The authors thank the support of the Australian Research Council,
Q.L.G. was supported by DP180100506.
The research of HNM was supported in part by ARO grant W911NF2110218 and NSF DMS grant 2012355.
\ifx\printbibliography\undefined
    \bibliographystyle{plain}