[INT-295] Feature Move Oapp example move vm decoding

[AlexanderLiteplo]

Beefing up the move oapp example with useful parameter encoding sent from evm-send.ts

Adding some utils on move side to assist people in parsing data. I think its useful to have amore built out move example here because most partners come form evm land and have no idea what they're doing in move vm land. The current implementation was built for a partner.

[shankars99]

also pnpm changeset pls

[abaltes-lz]

any reason not to use environment variable or config file for this? might be worth having a config.ts that just sets the oapp address, network, eids for the aptos and evm sends

[AlexanderLiteplo]

Its really just a personal preference thing. We don't usually offer this type of script in our devtools. I've just added it because I think it would be useful to have some scripts where people can play around and get an idea of how to call our contracts.

I think a config.ts file is overkill as this isn't supposed to be someone's workhorse. Just a simple hello world style script to get people started.

[abaltes-lz]

generally, we wouldn't be sending a hex string over the wire. is this necessary?

[AlexanderLiteplo]

in MyOApp.sol we do this:

    // ──────────────────────────────────────────────────────────────────────────────
    // 1. Send business logic
    //
    // Example: send a simple string to a remote chain. Replace this with your
    // own state-update logic, then encode whatever data your application needs.
    // ──────────────────────────────────────────────────────────────────────────────

    /// @notice Send a string to a remote OApp on another chain
    /// @param _dstEid   Destination Endpoint ID (uint32)
    /// @param _message  The string to send
    /// @param _options  Execution options for gas on the destination (bytes)
    function send(uint32 _dstEid, string calldata _message, bytes calldata _options) external payable {
        // 1. (Optional) Update any local state here.
        //    e.g., record that a message was "sent":
        //    sentCount += 1;

        // 2. Encode any data structures you wish to send into bytes
        //    You can use abi.encode, abi.encodePacked, or directly splice bytes
        //    if you know the format of your data structures
        bytes memory _message = abi.encode(_message);

        // 3. Call OAppSender._lzSend to package and dispatch the cross-chain message
        //    - _dstEid:   remote chain's Endpoint ID
        //    - _message:  ABI-encoded string
        //    - _options:  combined execution options (enforced + caller-provided)
        //    - MessagingFee(msg.value, 0): pay all gas as native token; no ZRO
        //    - payable(msg.sender): refund excess gas to caller
        //
        //    combineOptions (from OAppOptionsType3) merges enforced options set by the contract owner
        //    with any additional execution options provided by the caller
        _lzSend(
            _dstEid,
            _message,
            combineOptions(_dstEid, SEND, _options),
            MessagingFee(msg.value, 0),
            payable(msg.sender)
        );
    }
    ```

[AlexanderLiteplo]

I'm building this entire example around the existing OApp.sol so it will integrate into existing examples

[AlexanderLiteplo]

@St0rmBr3w what do you think?

[St0rmBr3w]

It may be worth just using a simpler data structure in the long-run, the string passing OApp is abi.encoded on EVM, which results in a complex data structure on non-EVM chains to unpack.

If you abi.encode("Hello World"), you will get the following byte structure:

// The function above will return the following raw bytes value.
0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000b48656c6c6f20576f726c64000000000000000000000000000000000000000000

// We can split this into words that are 32 bytes long to get:
0x0000000000000000000000000000000000000000000000000000000000000020  // offset
  000000000000000000000000000000000000000000000000000000000000000b   // length 
  48656c6c6f20576f726c64000000000000000000000000000000000000000000     // string

While "Hello World" makes sense for EVM chains, given the general complexity of implementing decoding for this message structure, I think it'd be better to have it just pass a uint value of some kind, and set a variable.

[St0rmBr3w]

Nazreen got around this by changing the encoding format from the standard abi.encode, but I think this is generally more distracting from the point of the example: to show users how to simply encode a data structure and decode it on a non-EVM chain.

devtools/examples/oapp-solana/contracts/MyOApp.sol

Line 31 in 8641261

bytes memory _message = abi.encodePacked(abi.encode(uint256(bytes(_string).length)), bytes(_string));

[DanL0]

this comment seems inaccurate

it mentions "last string received"

while below there are three variables: address, address, uint256 and none of them is string

maybe better to change comment to "last data received"?

[AlexanderLiteplo]

This is taken directly from the EVM OApp example (that devrel wrote) I'm just updating these files with their implementation. If you want me to change it across all examples I can do that, but it should be a separate PR.

[DanL0]

I think this is an anti pattern to force users to use native gas for paying fee and hardcoding it in the code.

This makes it impossible in future to pay with ZRO token, I don't think we want to encourage users to follow this pattern and disable it in their OApps they are building on top of this example.

Instead, send method should accept MessagingFee struct, like OFTCore: https://github.com/LayerZero-Labs/devtools/blob/main/packages/oft-evm/contracts/OFTCore.sol#L177

[AlexanderLiteplo]

This is taken directly from the EVM OApp example (that devrel wrote) I'm just updating these files with their implementation. If you want me to change it across all examples I can do that, but it should be a separate PR.

[DanL0]

does it work if you are currently encoding a "string" on send:

bytes memory _message = abi.encode(_message);

and on receive you are decoding "address, address, uint"?:

(address1, address2, num) = abi.decode(_message, (address, address, uint256));

I did a Foundry small test and I think if you currently do abi.encode offchain, pass it onchain and then do abi.encode again in Solidity before sending it results in wrong data:

function test_msg_passing() public virtual {
        bytes memory encoded = abi.encode(string(abi.encode(address(1), address(2), 100)));
        console.logBytes(encoded);

        (address address1, address address2, uint256 num) = abi.decode(encoded, (address, address, uint256));
        console.log(address1);
        console.log(address2);
        console.log(num);
    }

result:

Logs:
  0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000064
  0x0000000000000000000000000000000000000020
  0x0000000000000000000000000000000000000060
  1

Expected:

0x000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000064
  0x0000000000000000000000000000000000000001
  0x0000000000000000000000000000000000000002
  100

Could you create a test case in Foundry for sending messages from EVM to EVM using this OApp Solidity code and double check if the encoding and decoding logic is consistent and works?

[AlexanderLiteplo]

Sounds good. Putting this on pause until sla-tracker work is finished.