## 4 Optimizations for Cross-Chain Scheduling  
The multi-chain cooperative cross-chain system architecture adds a cross-chain scheduling module over the original Fabric system. The cross-chain scheduling module is located between the client and the Fabric network and interacts with the Peer module and Orderer module of the Fabric system to complete cross-chain transaction-related instructions. The architecture of a cross-chain system that includes cross-chain scheduling is shown in Figure 4.  
Two interoperable blockchains need to recognize each other's identity and determine the operation authority of each other's blockchains. For example, Chain A and Chain B are two federated chain blockchains. In the case of isolation between chains, Chain A needs to perform read and write operations on Chain B, while Chain B can only perform read operations on Chain A but has no right to write operations on Chain A. In this case, Chain A and Chain B need to register with cross-chain scheduling separately. Each chain that completes the registration will have interactive interface and access permissions. Blockchains that have been registered tell the cross-chain scheduler how much they are allowed to interoperate with other blockchains, namely read-only, write-only, and read/write (both). Default read/write (both) is unavailable. In this approach, traditional local transactions are still supported. Cross-chain scheduling is transparent to local transactions. For cross-chain transactions, cross-chain scheduling determines whether the target chain permits access to the source chain. If access is available, cross-chain scheduling encapsulates the access request and cross-chain information into a cross-chain proposal and routes it to the target chain. If there is no access, the cross-chain scheduler will not continue forwarding and will construct a cross-chain failure reply without cross-chain permission. Starting from the forwarding of cross-chain requests by cross-chain scheduling, the cross-chain scheduling records outstanding cross-chain transactions and starts timing the cross-chain forwarding time. Before the cross-chain timeout, cross-chain scheduling waits for the results of sub-transactions of the target chains then summarizes the results to judge whether the cross-chain is successful, and sends the results to each relevant blockchain for subsequent operations. If the cross-chain timeout occurs, the default cross-chain failure occurs, and the failure response is sent to all relevant blockchains by the cross-chain scheduling package to restore the cross-chain transaction-related operations. The optimized cross-chain approach utilizes cross-chain scheduling to adopt an optimistic cross-chain consensus when there is only one sub-transaction. In other words, the success of a cross-chain transaction is only related to one sub-transaction, so in this case, there is no need for cross-chain scheduling to collect sub-transactions results and then distribute the result messages to all participating chains again. The result of the target chain is valid immediately after the sub-transaction is processed, and no revalidation is required. At the same time, the target chain feeds back the result of cross-chain transaction execution to the source chain through cross-chain scheduling. The cross-chain scheduler also plays the role of cross-chain transaction sequencing. The relative order of cross-chain transactions should be the same across different blockchains. In other words, if two cross-chain transactions T0 and T1 have sub-transactions on Chain A and Chain B, the order of T0 and T1 must be the same in both chains. The relationship between the cross-chain scheduler and each block chain is equivalent to the relationship between the ordering node and each peer in a fabric. The order of cross-chain transactions depends on the ordering of cross-chain scheduling. The cross-chain method based on the EOVPC process improves the efficiency of cross-chain transaction processing by using cross-chain scheduling.