contracts/opl: Host requires Encave address, Enclave requires Host address?

[CedarMist]

There is a permanent 1:1 pairing between the two contracts on either side of the MessageBus, and the constructor for either requires the others contract address.

The address can be predicted using const newContractAddress = ethers.utils.getContractAddress({ from: signerAddr, nonce });

However, this could make building OPL contracts difficult when using @oasisprotocol/sapphire-contracts/contracts/OPL.sol as the remote variable of BaseEndpoint is private so it can't be changed after creation so the contracts must be deployed together.

Additionally, the 1:1 relationship between contracts limits the use cases.

Need to document this, and recommend using the Celer IM SDK for more complex use cases.

[nhynes]

recommend using the Celer IM SDK

The reason it's not like that is because giving up your primary interaction surface (i.e. API) to a third party is bad for the longevity of your business.

And the reason it's "circular" is to avoid making calls to the expensive home chain. I'm also not aware of any concrete use-cases that require octopus messaging. I'd suggest making a separate or extension library for that before making the common case (additionally?) difficult.

[CedarMist]

I agree that OPL can be very neat when the contracts are deployed 1:1 together, with one endpoint on Sapphire and another on a foreign chain, and we should keep it simple.

That being said, I'm sure people will come up with interesting octopus (1:N or N:1) & graph (N:M) patterns, although these can be made with the current pattern by deploying a factory on each chain, or just one pair of contracts for each chain<->chain connection.

[CedarMist]

One suggestion would just be to let the remote address & chainID to be set whenever the contract wants, so just making them internal rather than private, giving a bit of extra flexibility and options versus the strict 1:1 paired constructors.