(feat) Synthetic change to test CI

.github/workflows/ci-bridge.yml

@@ -1,4 +1,4 @@
-name: "CI for Product Bridge"
+name: "CI for Product Bridge - synthetic change for testing"
 
 on:
   push: {}
@@ -27,5 +27,5 @@ jobs:
           version: nightly
 
       - name: Run Foundry tests
-        run: forge test
+        run: forge test --disable-block-gas-limit
         working-directory: smart-contracts

.gitignore

@@ -9,3 +9,4 @@ Debug/
 
 .trunk/**
 !.trunk/trunk.yaml
+**/.env

docs/zilbridge.md

@@ -0,0 +1,27 @@
+# Zilbridge/XBridge integration
+
+
+## CrossChainManager extensions
+
+The currently deployed CCM on Ethereum does not contain functions to register lockProxy extensions.
+
+These can be run remotely from the `counterpartChainId` (in `lockProxy`), currently set to 5 (which is presumably Carbon).
+
+This means we need to either proxy or replace it.
+
+Replacing it is undesirable, because the address of the CCM is baked into the configuration files for the relayers.
+
+My first attempt was to proxy it with a `CCMExtendProxy`, but this doesn't work, because:
+
+ * To upgrade you have to call `ccmProxy::upgradeEthCrossChainManager()`
+ * (side-note: this calls the _current_ `eccm.upgradeToNew()` which hands ownership of the CCM data (proxied by the CCM contract) to the CCMExtendProxty, which now needs to hand it back to the old `ccm`)
+ * Subsequent calls through the `CCMExtendProxy` need to use the original `ccm` state, and therefore have the `CCMExtendProxy` as `msg.sender`.
+ * But there is no way to make the `CCMExtendProxy` an owner of the `ccm`.
+
+The second attempt is to write a new CCM contract which duplicates the
+original CCM and contains the new functions. Sadly, this means that
+someone needs to remember what the whitelist parameters were, because
+it is a map that does not emit events and we thus can't work out what
+is in it.
+
+

smart-contracts/README.md

@@ -1,4 +1,4 @@
 # UCCB Contracts
 
 The contracts are split into 2 sections:
 
@@ -134,6 +134,22 @@
 
 To deploy the `TokenManagers` on new chains the `LockAndReleaseTokenManagerUpgradeableV3` and `MintAndBurnTokenManagerUpgradeableV3` on each end of the chain if not already there. The initializer function needs to be added to these functions to initialize the owner and setting the gateways necessary. Then a new deployment script can be created and used accordingly.
 
+### ZilBridge
+
+`zilbridge` contains contracts used to assume the functionality of
+ZilBridge. The tests for zilbridge are mostly over in the parallel
+`zilbridge-hardhat` directory, because a lot of them depend on Scilla
+contracts and forge does not yet support Scilla.
+
+`zilbridge/1` are taken from:
+
+ - [lockproxy.sol](https://etherscan.io/address/0x9a016ce184a22dbf6c17daa59eb7d3140dbd1c54#code)
+ - [ccmproxy.sol](https://etherscan.io/address/0x5a51E2ebF8D136926b9cA7b59B60464E7C44d2Eb#code)
+ - [ccmCrossChainManager.sol](https://etherscan.io/address/0x14413419452Aaf089762A0c5e95eD2A13bBC488C#code)
+
+And modified for a modern solc so that they will run in our environment.
+
+
 ## Creating custom cross-chain messaging protocols
 
 Essentially there are 2 main interfaces on contracts that need to be satisfied to send a cross-chain message from a source chain to the target chain: