ICTT Feature Request: Return Teleporter Message ID from Functions and additional Events

[midnight-commit]

Overview

This is a feature request for the ICTT contracts to add Teleporter message IDs to function returns and additional events.

Proposed Changes

1. Return Message IDs from Send Functions

Currently, these functions don't return values:

function send(
    SendTokensInput calldata input
) external;

function sendAndCall(
    SendAndCallInput calldata input
) external;

Proposed Change:
Modify these functions to return the bytes32 teleporterMessageID:

function send(
    SendTokensInput calldata input
) external returns (bytes32);

function sendAndCall(
    SendAndCallInput calldata input
) external returns (bytes32);

2. Add Message IDs to Events

Currently, these events are emitted when receiving messages:

event TokensWithdrawn(address indexed recipient, uint256 amount);
event CallSucceeded(address indexed recipientContract, uint256 amount);
event CallFailed(address indexed recipientContract, uint256 amount);

Proposed Change:
Add the teleporterMessageID as the first parameter (and indexed) to these events:

event TokensWithdrawn(bytes32 indexed teleporterMessageID, address indexed recipient, uint256 amount);
event CallSucceeded(bytes32 indexed teleporterMessageID, address indexed recipientContract, uint256 amount);
event CallFailed(bytes32 indexed teleporterMessageID, address indexed recipientContract, uint256 amount);

Suggestion for Implementation of Change #2

For implementing change #2, we suggest the ITeleporterReceiver interface could be updated to pass the message ID:

interface ITeleporterReceiver {
    function receiveTeleporterMessage(
        bytes32 teleporterMessageID,
        bytes32 sourceBlockchainID,
        address originSenderAddress,
        bytes calldata message
    ) external;
}

This is just a suggestion for one possible implementation approach and could benefit other ITeleporterReceiver implementers as well.

Rationale

We're building on top of ICTT and would like to use the message ID in our own logs for tracking cross-chain messages.

[geoff-vball]

Hey, thanks for your interest in our contracts! I doubt we would include these changes in future versions. On the ITeleporterReceiver side, this breaking change would break compatibility with all currently deployed TeleporterMessenger instances. We will only release a new version in extraordinary circumstances.

In general, I think these changes include passing more information than is necessary because the data you're looking for can be fetched client-side. If you're looking to find out when a particular transaction sent from your application has been processed on the destination chain, you can query for the log of the transaction you're curious about. Ethereum logs come with the transaction hash to fetch the entire transaction, which you could then query for the SendCrossChainMessage event emitted by TeleporterMessenger.

[midnight-commit]

Thank you @geoff-vball for the swift response. We expected as much, but thought it's worth a try. :-)

I am curious though why you think the message id is more important on the sending side than on the receiving side. Teleporter will return message id from send but won't pass it on in receive.

In ICTT the message id on send side will also only be used for logging:

icm-contracts/contracts/ictt/interfaces/ITokenTransferrer.sol

Line 174 in 51dd215

event TokensSent(

icm-contracts/contracts/ictt/interfaces/ITokenTransferrer.sol

Line 184 in 51dd215

event TokensAndCallSent(

Which also will be duplicated here:

icm-contracts/contracts/teleporter/TeleporterMessenger.sol

Line 680 in 51dd215

emit SendCrossChainMessage(

If the message id is important and useful on the send side on contract level, why does ICTT not also return it from its send functions to its potential smart contract callers?

We know we can get all logs of a transaction but if we have to use eth_getTransaction and eth_getTransactionReceipt our batch processing (for hopefully hundreds of L1s) will be inefficient.