Call to Action for L2 <-> L2 Interop Testing for those organizations interested: Referencing Crosschain Interop Testing Plan (see below)

[Therecanbeonlyone1969]

This issue is a copy of this issue from the EEA Crosschain Interop WG https://github.com/EntEthAlliance/crosschain-interoperability/issues/163 -> call for action to participate in L2 <-> L2 interop testing!!

The following is a broad plan for crosschain interop testing. Some of the steps can be done in parallel. Please comment on this issue to provide feedback.

Step 1: Define interfaces in Java and Solidity for Crosschain Function Call Layer and Crosschain Messaging Layer.

@drinkcoffee will have PRs ready today / Monday Feb 7 for this.
Step 2: Vendors should express interest in participating in the crosschain interop testing. At this point, this is just an expression of interest, and does not commit your company to the process. Please comment on this issue, stating the information below. If you don't have all of the information yet, please state the information you have, and then later put in an additional comment to indicate your updated information:

Company name.
Company website.
Contact name.
Contact email address.
Which layer of the protocol stack you have a component that you wish to interop test: Crosschain Application, Crosschain Function Call, Crosschain Messaging.
The name of the protocol that you wish to test, and any documentation on the protocol.
Whether the protocol will work on Consortium blockchains (QBFT consensus with zero gas cost), a public Ethereum test network (PoS, PoA, or PoW consensus with some gas fees), and / or Abitrum optimistic rollup test network.
The programming language of the contract code for your component(s).
The programming language of the Software Development Kit (SDK) library for your component(s).
If the code is available in a public repo, please provide a link to the repo.
Step 3: Define the Crosschain Function Call Layer and Crosschain Messaging Layer APIs for the SDK for the programming languages that vendors have SDKs.

Step 4: In addition to applications that vendors may have nominated in Step 2, define and agree on applications / use cases to be tested. I suggest the creation of a document that captures the detail of each test application.

Step 5: Define which test networks will be used for the testing. This will be in part based on what vendors say in response to Step 2.

Step 6: Vendors supply binaries and / or source code / deployed addresses of their SDK and contracts.

Step 7: Vendors attempt to have SDK libraries defined by different vendors compile with their own libraries.

Step 8: Informal testing of applications.

Step 9: Resolve issues. Go back to step 6 until all issues resolved.

Step 10: Formal testing and deployment. Have systems available for public demonstrations.

Step 11: Big media announcement.

[Therecanbeonlyone1969]

Effort is on hold. Can close for now