Teleporter registry upgrade #43
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
contracts/src/CrossChainApplications/ExampleMessenger/ExampleCrossChainMessenger.sol
Fixed
Show fixed
Hide fixed
contracts/src/CrossChainApplications/VerifiedBlockHash/BlockHashPublisher.sol
Fixed
Show fixed
Hide fixed
contracts/src/CrossChainApplications/VerifiedBlockHash/BlockHashReceiver.sol
Fixed
Show fixed
Hide fixed
minghinmatthewlam
dismissed stale reviews from geoff-vball and cam-schultz
via
a2d0d44
minghinmatthewlam
dismissed stale reviews from michaelkaplan13, cam-schultz, and geoff-vball
via
000a894
| }) | ||
| ); | ||
| messageID = teleporterRegistry | ||
| .getLatestTeleporter() |
There was a problem hiding this comment.
I just want to confirm that we never plan to send out blockhash using an older version of teleporter.
There was a problem hiding this comment.
no don't think so, any particular use case you're thinking of?
Signed-off-by: minghinmatthewlam <[email protected]>
minghinmatthewlam
requested review from
bernard-avalabs,
michaelkaplan13 and
cam-schultz
| bridge_a_deploy_result=$(forge create --private-key $user_private_key --constructor-args $teleporter_contract_address \ | ||
| --rpc-url $subnet_a_url src/CrossChainApplications/ERC20Bridge/ERC20Bridge.sol:ERC20Bridge) | ||
| # Deploy the ERC20 bridge contract to all chains. | ||
| bridge_a_deploy_result=$(forge create --private-key $user_private_key \ |
There was a problem hiding this comment.
Was there a need to move --constructor-args to be the last argument here with the last foundry version, or did you just move it to be consistent in our usage?
There was a problem hiding this comment.
Was not due to last version, but on their page they say "The --constructor-args flag must be positioned last in the command, since it takes multiple values.", even though it seemed to work previously without being last position. https://book.getfoundry.sh/reference/forge/forge-create
Why this should be merged
Provides upgradeability of Teleporter through a registry contract #7. Creates a warp protocol registry that can be inherited by warp protocols, and for Teleporter specifically has
TeleporterRegistry.How this works
Adds a warp registry contract that gets inherited by
TeleporterRegistry. The registry can add new protocol versions through a warp out of band message, then keeps track of the version and protocol address mappings. The constructor of the registry also allows for initialization, so that the registry initially doesn't need an additional warp out of band message if Teleporter is already deployed.Cross chain apps will take in the registry instead of previous passing Teleporter in their constructor. The best practice for sending will be to ask the registry every time for sending with the latest version. For receiving, cross chain apps are recommended to have a
minTeleporterVersion, and for theirITeleporterReceiver.receiveTeleporterMessageimplementation to check that themsg.sendermatches aversion > _minTeleporterVersion.TeleporterUpgradeableprovides these best practices as an abstract contract that cross chain apps built on Teleporter can inherit and use.How this was tested
Unit Tests, adding tests for Teleporter/Warp registry and
TeleporterUpgradeableE2E test update to pass in registry for cross chain apps while warp out of band messages are still being implemented.
How is this documented
upgrade README