From dc9e17b1caeacdc588ec91a70ac04e4e79b28cf0 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 1 Dec 2024 20:53:42 +0300 Subject: [PATCH 1/3] typos CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 194294ad..4e569369 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,7 +17,7 @@ To start developing on Teleporter, you'll need Solidity >= v0.8.25. [Foundry](ht ## Features -- If you want to start a discussion about the development of a new feature or the modfiication of an existing one, start a thread under GitHub [discussions](https://github.com/ava-labs/teleporter/discussions/categories/ideas). +- If you want to start a discussion about the development of a new feature or the modification of an existing one, start a thread under GitHub [discussions](https://github.com/ava-labs/teleporter/discussions/categories/ideas). - Post a thread about your idea and why it should be added to Teleporter. - Don't start working on a pull request until you've received positive feedback from the maintainers. From ad8014233a9788909c4f0d978e16d3dd07235ab0 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 1 Dec 2024 20:56:42 +0300 Subject: [PATCH 2/3] typo README.md --- contracts/teleporter/registry/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contracts/teleporter/registry/README.md b/contracts/teleporter/registry/README.md index 3057e237..6bdf271b 100644 --- a/contracts/teleporter/registry/README.md +++ b/contracts/teleporter/registry/README.md @@ -86,7 +86,7 @@ To prevent anyone from calling the dApp's `updateMinTeleporterVersion`, which wo } ``` -Another example would be a dApp that has different roles and priveleges. `_checkTeleporterRegistryAppAccess` can be implemented to check whether the caller is a specific role. +Another example would be a dApp that has different roles and privileges. `_checkTeleporterRegistryAppAccess` can be implemented to check whether the caller is a specific role. ```solidity function _checkTeleporterRegistryAppAccess() internal view virtual override { From 1dcb6f0868c3f05d676e0c8175fd96a082bdf13e Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 1 Dec 2024 20:57:48 +0300 Subject: [PATCH 3/3] typos README.md --- contracts/teleporter/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contracts/teleporter/README.md b/contracts/teleporter/README.md index d51220f8..25cc6332 100644 --- a/contracts/teleporter/README.md +++ b/contracts/teleporter/README.md @@ -65,10 +65,10 @@ Teleporter messages are delivered by calling the `receiveTeleporterMessage` func ## Teleporter Contract Deployment -The `TeleporterMessenger` contract must be deployed to the same contract address on every chain. This is acheived using Nick's keyless transaction method as described [here](../../../utils/contract-deployment/README.md). As a result, Warp messages sent from the resulting contract address are ensured to have the same payload format as defined by the contract itself. +The `TeleporterMessenger` contract must be deployed to the same contract address on every chain. This is achieved using Nick's keyless transaction method as described [here](../../../utils/contract-deployment/README.md). As a result, Warp messages sent from the resulting contract address are ensured to have the same payload format as defined by the contract itself. ## Message Delivery and Execution -Teleporter is able to ensure that messages are considered delivered even if their execution fails (i.e. reverts) by using `evm.Call()` with a pre-defined gas limit to execute the message payload. This gas limit is specified by each message in the call to `sendCrossChainMessage`. Relayers must provide at least enough gas for the sub-call in addition to the standard gas used by a call to `receiveCrossChainMessage`. In the event that a message execution runs out of gas or reverts for any other reason, the hash of the message payload is stored by the receiving Teleporter contract instance. This allows for the message execution to be retried in the future, with possibly a higher gas limit by calling `retryMessageExecution`. Importantly, a message is still considered delivered on its destination chain even if its execution fails. This allows the relayer of the message to redeem their reward for deliverying the message, because they have no control on whether or not its execution will succeed or not so long as they provide sufficient gas to meet the specified `requiredGasLimit`. +Teleporter is able to ensure that messages are considered delivered even if their execution fails (i.e. reverts) by using `evm.Call()` with a pre-defined gas limit to execute the message payload. This gas limit is specified by each message in the call to `sendCrossChainMessage`. Relayers must provide at least enough gas for the sub-call in addition to the standard gas used by a call to `receiveCrossChainMessage`. In the event that a message execution runs out of gas or reverts for any other reason, the hash of the message payload is stored by the receiving Teleporter contract instance. This allows for the message execution to be retried in the future, with possibly a higher gas limit by calling `retryMessageExecution`. Importantly, a message is still considered delivered on its destination chain even if its execution fails. This allows the relayer of the message to redeem their reward for delivering the message, because they have no control on whether or not its execution will succeed or not so long as they provide sufficient gas to meet the specified `requiredGasLimit`. Note that due to [EIP-150](https://eips.ethereum.org/EIPS/eip-150), the lesser of 63/64ths of the remaining gas and the `requiredGasLimit` will be provided to the code executed using `evm.Call()`. This creates an edge case where sufficient gas is provided by the relayer at time of the `requiredGasLimit` check, but less than the `requiredGasLimit` is provided for the message execution. In such a case, the message execution may fail due to having less than the `requiredGasLimit` available, but the message would still be considered received. Such a case is only possible if the remaining 1/64th of the `requiredGasLimit` is sufficient for executing the remaining logic of `receiveCrossChainMessage` so that the top level transaction does not also revert. Based on the current implementation, a message must have a `requiredGasLimit` of over 1,200,000 gas for this to be possible. In order to avoid this case entirely, it is recommended for applications sending Teleporter messages to add a buffer to the `requiredGasLimit` such that 63/64ths of the value passed is sufficient for the message execution.