[Bug]: Teleporter deployment failure

[tactical-retreat]

Describe the bug
Deploying teleporter failed.

I got all the way through setting up a token bridge and enabling relayer, but the relayer kept failing with this error:

{"level":"error","timestamp":"2024-03-02T20:44:43.440-0500","logger":"awm-relayer","caller":"relayer/message_relayer.go:84","msg":"Failed to check if message should be sent","error":"no contract code at given address"}

Turns out, the teleporter contract doesn't exist on my subnet.

$ cast code  --rpc-url=https://testnet-rpc.ferdyflip.xyz/rpc 0xF7cBd95f1355f0d8d659864b92e2e9fbfaB786f7
0x

This surprised me, since I 'successfully' deployed it yesterday. The logs are gone though. So I tried to deploy the v0.1.0 version instead.

$ ./scripts/deploy_teleporter.sh --rpc-url https://testnet-rpc.ferdyflip.xyz/rpc --version v0.1.0 --fund-deployer $PRIVATE_KEY
TeleporterMessenger v0.1.0 contract address: 0x1b0505EaC728Efc30414ce0035BcC4DC5994a563
TeleporterMessenger v0.1.0 deployer address: 0xa21D65b03A07548F001b6C1422614BEa28370FdA
Funding deployer address with 10000000000000000000 wei

blockHash               0x40e82ce93c80a5b13b81dd85835acf3b7907d9273e6fed4a950f6bf160f7d3df
blockNumber             9907
contractAddress         
cumulativeGasUsed       21000
effectiveGasPrice       18000000000
from                    0xB34D4AE19393115CC5af8fa5f2b1cB4B5d682775
gasUsed                 21000
logs                    []
logsBloom               0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root                    
status                  1
transactionHash         0x31cde0c7bba1590fd75d5c28b4bb651abc54853d0bbd973ca2073dcc3864e261
transactionIndex        0
type                    2
to                      0xa21D65b03A07548F001b6C1422614BEa28370FdA
Deploying TeleporterMessenger v0.1.0
{"transactionHash":"0x39b4b4e4fe383ebd238c0b265712de725a8ba9a1f58f6b43c15accd55b810896","transactionIndex":"0x0","blockHash":"0xa39ceaf1e98981e510de92c3522caa3c0987328f9b61fc1a192d184795fd4d72","blockNumber":"0x26b4","from":"0xa21d65b03a07548f001b6c1422614bea28370fda","to":null,"cumulativeGasUsed":"0x3d0900","gasUsed":"0x3d0900","contractAddress":"0x1b0505eac728efc30414ce0035bcc4dc5994a563","logs":[],"status":"0x0","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","type":"0x0","effectiveGasPrice":"0x246139ca800","deposit_nonce":null}
Success! TeleporterMessenger v0.1.0 deployed to 0x1b0505EaC728Efc30414ce0035BcC4DC5994a563

You'll notice that the status of the fund transfer is 0x1, but the status of the deployment is 0x0. Oops. The Success! TeleporterMessenger v0.1.0 deployed from yesterday LIED TO ME.

The warp precompile is enabled on my subnet. I don't have a good explorer running yet, but the routescan dev explorer shows that the TX used 4M gas and failed (I think, it seems to not show contract deployments properly).

Not sure what you can personally do to repro this. You could deploy the v0.0.0 version I guess?

I think my subnet is kind of borked now, until a new teleporter version is released, right?

[tactical-retreat]

AHHH shoot I was just thinking about how you could repro this and I realized that this is probably due to the deployment Allowlist precompile not having the teleporter deploy address in it.

[tactical-retreat]

Maybe this is a feature request to check the Allowlist precompile before execution then lmao

[michaelkaplan13]

Yeah absolutely. The script should definitely check prior to sending the transaction, and also check the status of the transaction afterward since it could potentially revert for other reasons depending on the subnet's configuration.

Thanks going through this and calling it out!

[tactical-retreat]

Just manually upgraded my subnet to deploy the appropriate code to the teleporter address, thanks for the suggestion on twitter.

It occurred to me that I borked this by accident, but a malicious user could deliberately bork the upgrade, causing work for the subnet operator, so this might be a more common thing to do than expected.

[michaelkaplan13]

Great to hear, I've actually never have gone through that state upgrade flow myself, but we will document it as a possible fallback option.

It occurred to me that I borked this by accident, but a malicious user could deliberately bork the upgrade, causing work for the subnet operator, so this might be a more common thing to do than expected.

I think the only case where the deployer allowlist specifically would be an issue here is if a Subnet initially does not want to support Teleporter (and doesn't set the deployer address as an allowed deployer), and then later on decides that they do want to support Teleporter. In that event, it would require a network upgrade either way to either add the deployer address as an allowed deployer, or to directly add the code at the address via a state upgrade. If they want to support it from the start and are limiting who is able to deploy contracts on their new chain, then they should include the deployer address on the deploy list. If they never want to support Teleporter, it's not an issue that the transaction gets sent and reverts.

Aside from the deployer allowlist though, different rulesets and conditions on different chains makes it impossible to ensure the Nick's method transaction will work on all chains. For instance, a chain could have a minimum gas price above the gas price set in the transaction (2500 GWEI), or could have different gas costs for certain opcodes such that the transaction runs out of gas (4M gas limit).

We'll continue exploring options for improvements. Ensuring that the same bytecode can be deployed to the same address on arbitrary chains without needing a central authority to explicitly support new chains is a frustrating problem. One option would be to include the Teleporter bytecode baked into subnet-evm with a configuration switch that can be set in the genesis configuration to enable it or not (basically a precompile). That may be the least error prone for new Subnets since they wouldn't have to deploy the contract at all, but we're also conscious of not wanting to "enshrine" Teleporter in the protocol.

[tactical-retreat]

I think the only case where the deployer allowlist specifically would be an issue here is if a Subnet initially does not want to support Teleporter (and doesn't set the deployer address as an allowed deployer), and then later on decides that they do want to support Teleporter.

Agree in general, but the deployer address is different for every teleporter release right? Which means that it's not just 'if they want to support teleporter' but 'if they want to support an updated version of teleporter'. I thought that was the point of the teleporter registry right?

Basically I'm saying you could be an annoying troll by watching for teleporter release publications and then pre-borking them on subnets.

But as you mentioned elsewhere in this post there's not really a good solution for this. The state upgrade wasn't that bad, I think just making it documented / easy as possible for people to do is good enough.

[michaelkaplan13]

Ah yeah, great point about the future releases. The deployer allowlist really doesn't play nicely with this model.

The state upgrade wasn't that bad, I think just making it documented / easy as possible for people to do is good enough.
100%. We'll add documentation for that option 🙏