# Blockchain Interoperability for Future Telecoms
## 3 Literature Review
### Review of Well-Known Permissioned Blockchain Interoperability Projects  
Hyperledger Cactus [63] is the Hyperledger Foundation's initial interoperability project. It has been built as a bridge between Hyperledger Fabric and Ethereum for cross-chain communications. This was one of the earliest solutions implemented as a proof-of-concept for permissioned blockchains, in which the cactus is considered a notary. Similar notary solutions built between two interoperated blockchains are classified as centralized solutions and intermediaries. This type of intermediary architecture also introduces an SPoF when an intermediary is unavailable. [PERSON] et al. [64] proposed a gateway-based solution in 2022, where a gateway was used for cross-chain communications between two interoperating blockchains, namely Hyperledger and Corda. In the gateway part, a router is responsible for routing the message from the Hyperledger connector to the Corda connector. This approach can be considered a cross-chain trusted relay. [PERSON] et al. called this solution middleware, which is, by other means, an intermediary. As such, an intermediary solution is deployed outside both chains, it raises the question of who maintains this component. This approach generally breaks down decentralized architectures and presents a centralized solution. Weaver [65] is a new approach that provides substantial enhancements compared with existing solutions. Weaver is based on Hyperledger Fabric and aims to provide interoperability between DLTs of the same or different types in permissioned blockchains. Weaver offers three use cases: data sharing, asset transfer, and asset exchange. Weaver introduces two modules as side components for each interoperating blockchain. The Intop is responsible for communicating with the core blockchain, while a relay is used to communicate with the interoperated blockchain and includes a communication module for each blockchain type (e.g., Corda, Hyperledger, and Ethereum). Weaver access management modules are currently being developed. Weaver's design is a side-by-side architecture and isolated framework, making it a decentralized solution. Weaver also uses asynchronous and message-based communication between interoperation modules. These two features make Weaver a more flexible and fault-tolerant solution. The fast and efficient communication protocol gRPC is also used to communicate between interoperated blockchains. The design choices were carefully made and could be essential for the provision of an ideal solution. It also aims to deploy a DID architecture for identity management. This design allows more than two blockchains to interoperate, making Weaver a strong candidate for the final permissioned blockchain interoperability solution. Hyperledger Firefly [66] is a promising solution for the future of blockchain technologies. This project aims to accelerate the development time for future blockchains, notably through the introduction of a Web3 development framework. Firefly offers a solution based on the permissioned data passing through multiple chains. According to [PERSON] et al. [67], Firefly requires a third party to validate the nodes, which introduces a security bottleneck. This type of third-party validation also introduces an intermediary that can be considered to be centralized. Although Firefly provides flexible development environment tools for dApps in Web3, its design architecture is very complex for simple data and asset transfers. Hermes [68] was proposed by [PERSON] et al. and concentrates on fault tolerance for possible crash cases of middleware-based interoperability. Hermes aims to achieve an SPoF-free architecture to eliminate crash-causing cases and provide crash resilience. Hermes presented a valid use case that can be integrated into future designs. However, using a gateway-based intermediary architecture, particularly for a fault-tolerant design, renders Hermes a centralized architecture.