research: provide Osmosis Hook/ICS27 contract packet calls

[dzmitry-lahoda]

provide ICS20 memo packet handler and/or ICS27 handler contract, so

that it calls host function to find out what program accounts to propagate as part of its execution to subpogram calls

there are 3-4 ways (and slight modifications of these) to do cross chain calls over IBC.

one suggested

https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-hooks

so memo is

{
 "svm": {

   // all accounts from instuctions must be passed to client TX
 // ixs contain program ids, account and input data
   "instructions": [
   "borsch of ix as in invoke",
   "borsch of ix as in invoke",
...   
  ]
  // basicaly hook can do some extra work with without being contract for some reason and build ix on fly
// fully json  encoded
 "extra_accounts" : [ AccountMeta(R/W),  AccountMeta,... ] // 

  }
}

trim spaces, json escape = like in cosmos.

memo handling is part of TX - so if it is not up to ibc-hooks rules -i fails tx

        invoke_signed(
            &instruction,
            accounts,
            &[
              &["transfer", "channel-42", "centauri13123hdjfsfdsfdsf"]],
        )?;

caller/payer account is derived account from channel + sender, as on other chains. that sender receives funds

so sender side MUST know how to form proper caller to produce instructions.

because solana has depth 4 of contracts calls, suggestion is to use traits to implement app stack on solana with and without hook. do not do 2 contracts, as it will eat one program call level.

all ics 20 assets transferred to ibc hook derived account (transfer/channel/sender), it is up to sender to enode SPL or sol transfer as part of instuctions downsteam.

optimizations

accounts in instructions are copied several times, compression or map? nope. why solana does not that already?

and it leads to custom format, so cannot just send borch Vec bytes but some custom format.

Sure until there is cute no_std lib which handles all of that

caller is placeholder

in theory caller account may be placerholder, so that can plug it on relayer side, but that would require ibc and relayer aware of such possibility. not sure if it is good.

not json

who will maintain ibc-go/ibc-apps forks?

[dzmitry-lahoda]

@dhruvja are you aware of some no_std crate to handle manipulation with borch encoded instructions?

[dhruvja]

@dhruvja are you aware of some no_std crate to handle manipulation with borch encoded instructions?

Not that i am aware of. I can ask in the discord if anybody knows it over there.

[dhruvja]

provide ICS20 memo packet handler and/or ICS27 handler contract, so

that it calls host function to find out what program accounts to propagate as part of its execution to subpogram calls

there are 3-4 ways (and slight modifications of these) to do cross chain calls over IBC.

one suggested

https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-hooks

so memo is

{
 "svm": {
   "instructions": "some raw broach bytes encoding of vector of instructions" 
 }
}

trim spaces, json escape = like in cosmos.

memo handling is part of TX - so if it is not up to ibc-hooks rules -i fails tx

        invoke_signed(
            &instruction,
            accounts,
            &[
              &["transfer", "channel-42", "centauri13123hdjfsfdsfdsf"]],
        )?;

caller/payer account is derived account from channel + sender, as on other chains. that sender receives funds

so sender side MUST know how to form proper caller to produce instructions.

because solana has depth 4 of contracts calls, suggestion is to use traits to implement app stack on solana with and without hook. do not do 2 contracts, as it will eat one program call level.

all ics 20 assets transferred to ibc hook derived account (transfer/channel/sender), it is up to sender to enode SPL or sol transfer as part of instuctions downsteam.

optimizations

accounts in instructions are copied several times, compression or map? nope. why solana does not that already?

and it leads to custom format, so cannot just send borch Vec bytes but some custom format.

Sure until there is cute no_std lib which handles all of that

caller is placeholder

in theory caller account may be placerholder, so that can plug it on relayer side, but that would require ibc and relayer aware of such possibility. not sure if it is good.

not json

who will maintain ibc-go/ibc-apps forks?

Still wondering on how you would know which accounts are required by the sub program you would be calling?

[dzmitry-lahoda]

relayer will parse memo instructions. instructions tell accs read and write. relayer passes these to ibc contract. ibc send these to hook trait as vec. trait impl picks relavn accs if it needs. but fun thing is, that ix already contain all accs. so really do nothing.

so relayr must tx these as rest of input array. just it.
so really hook does only look over memo ixs, inv9ke signed with derivation.

[dhruvja]

Would u be sending the accounts in the order the program expects?

[dzmitry-lahoda]

sorted. jusr grab all accas from all instructions and sort. use highest priviledge, like write if it is write on any.

[dzmitry-lahoda]

so i not sure if it is needed, but seems it is root to grow cvm(evm analog)

[dhruvja]

Right right, we can try and test this once the bridge is up because i still doubt the order of the accounts depends on how the program is written.

[dzmitry-lahoda]

invoke program on chain does picks axcpunts automatically as written in ix. but accounts must be sent by relayer. and only ix of relayer cares order.

[dzmitry-lahoda]

but, in order to write conditional instructions, i mean assemle instructions on the go, need sorted array of possible. accounts depending on ifs in cvm.

[dzmitry-lahoda]

@dhruvja

pub fn invoke_signed(
    instruction: &[Instruction](https://docs.rs/solana-program/latest/solana_program/instruction/struct.Instruction.html),
    account_infos: &[[AccountInfo](https://docs.rs/solana-program/latest/solana_program/account_info/struct.AccountInfo.html)<'_>],
    signers_seeds: &[&[&[[u8](https://doc.rust-lang.org/nightly/std/primitive.u8.html)]]]
) -> [ProgramResult](https://docs.rs/solana-program/latest/solana_program/entrypoint/type.ProgramResult.html)

instruction has proper ordered list of AccountMeta, so from list of AccountMeta and other sorted AccountInfo[] can filter and sort AccountInfo for each subprogram call.

[dzmitry-lahoda]

it seems okey. just provide set of account infos to hook trait. so that hook can parse ixs, and pick accountinfos or each call.

[dhruvja]

@dhruvja

pub fn invoke_signed(
    instruction: &[Instruction](https://docs.rs/solana-program/latest/solana_program/instruction/struct.Instruction.html),
    account_infos: &[[AccountInfo](https://docs.rs/solana-program/latest/solana_program/account_info/struct.AccountInfo.html)<'_>],
    signers_seeds: &[&[&[[u8](https://doc.rust-lang.org/nightly/std/primitive.u8.html)]]]
) -> [ProgramResult](https://docs.rs/solana-program/latest/solana_program/entrypoint/type.ProgramResult.html)

instruction has proper ordered list of AccountMeta, so from list of AccountMeta and other sorted AccountInfo[] can filter and sort AccountInfo for each subprogram call.

Cool, that makes sense.

[dzmitry-lahoda]

is it required #104 for this?

did you tried just array for accounts info in the end for macro? i guess it will be expanded

[dzmitry-lahoda]

evm side https://github.com/ComposableFi/yui-ibc-solidity-private/issues/84

[dzmitry-lahoda]

Dzmitry Lahoda
14 hours ago
@mina86
just for future ongoing work. for cross chain contract calls , what to use ICS20(json)+memo(memo json or not? de facto spec is json payload/call) or ICS20(json)+ICS27(borsch by spec) ? ICS20 memo is single packet (single set of accounts/input IXs for ICS20 and for memo call). ICS20/ICS27 is multipacket (ICS20 accounts/IX only for transfer) and ICS27 accounts/IX for calls). we drafted some memo based desing with dhruv on solana repo issue some time ago.
not urgent. so i think soon to be active there (edited)
17 replies
Dzmitry Lahoda
14 hours ago
#111

#111 feat: provide Osmosis Hook/ICS27 contract packet calls
provide ICS20 memo packet handler and/or ICS27 handler contract, so
that it calls host function to find out what program accounts to propagate as part of its execution to subpogram calls
there are 3-4 ways (and slight modifications of these) to do cross chain calls over IBC.
one suggested
https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-hooks
so memo is
{
"svm": {

// all accounts from instuctions must be passed to client TX
// ixs contain program ids, account and input data
Show more
Comments
14
https://github.com/[ComposableFi/emulated-light-client](https://github.com/ComposableFi/emulated-light-client)|ComposableFi/emulated-light-clientComposableFi/emulated-light-client | Nov 20th, 2023 | Added by GitHub

Dzmitry Lahoda
14 hours ago
ComposableFi/composable-ibc#457

#457 feat(solana): manual instruction ls accounts propagation to cross chain calls
ComposableFi/emulated-light-client#111 (comment)
Assignees
@dhruvja
Comments
3
https://github.com/[ComposableFi/composable-ibc](https://github.com/ComposableFi/composable-ibc)|ComposableFi/composable-ibcComposableFi/composable-ibc | Nov 21st, 2023 | Added by GitHub
Dzmitry Lahoda
14 hours ago
so i not aware how it fits solana constrains on resources
Dzmitry Lahoda
14 hours ago
and current ibc impl
Dzmitry Lahoda
14 hours ago
i would be happy to plug ICS20+memo(json) if it works
Dzmitry Lahoda
14 hours ago
problems on Ethreum ICS20 memo https://github.com/ComposableFi/yui-ibc-solidity-private/issues/84

#84 research: cross chain transactions gas fees
i feel that osmosis hooks directly ported as is may be bearish in terms of gas,
there are 3 knows issues:
• non binary ABI encoding of memo
• mixing ICS20 with Memo (leading to need to replace calldata with memory)
• delegation is done via contract instantiation of executor
also each of these points separately may be ok, but all combined feels like very bad.
Using ABI is simple to try, but pure linear custom json parser may be quite fast and may be overhelmed by other costs.
Using ICS20 memo vs ICS27 requires ICS27 impl to be done, but may be right solution to split costs. ICS27 already binary ABI by spec too - which is awesome. (making ICS20 no json breaks all senders/indexers expectancies - so no… Show more
https://github.com/[ComposableFi/yui-ibc-solidity-private](https://github.com/ComposableFi/yui-ibc-solidity-private)|ComposableFi/yui-ibc-solidity-privateComposableFi/yui-ibc-solidity-private | Jan 10th | Added by GitHub
Dzmitry Lahoda
14 hours ago
no urgent, as I see need to release
Dzmitry Lahoda
14 hours ago
so some work for newcomer to be defined, may be he can detail on this.
Dzmitry Lahoda
14 hours ago
unless Blas will ask him to work on something else
Michał Nazarewicz
12 hours ago
I think borsh is better to be honest. Or protobuf. I still hope that cosmos/ibc-rs#1019 this will happen and we’ll be able to skip base64 encoding.

#1019 FR: Allow binary data in ibc::apps::transfer::types::Memo
Change ibc::apps::transfer::types::Memo type to wrap Vecu8 rather than a String so that it doesn’t have to be valid UTF-8. With ICS-20 memo is used to transfer machine-readable instructions to execute after a transfer. However, the field being a String forces them to be valid UTF-8. In some situations, this prevents most efficient memo representation to be used.
For example, on Ethereum one might define memo to use/include Ethereum ABI encoded function call but to be able to include that in memo it must be UTF-8 which forces users to waste time and space doing hex or base64 encoding.
Notably, in Proto converting string field into bytes is backwards compatible. Furthermore, Go (as far as I know) accepts invalid en… Show more
https://github.com/[cosmos/ibc-rs](https://github.com/cosmos/ibc-rs)|cosmos/ibc-rscosmos/ibc-rs | Dec 28th, 2023 | Added by GitHub
👍:skin-tone-6:
1

Dzmitry Lahoda
12 hours ago
what about having transfer and call in single packet? or having transfer and call different packets?
is it possible to split single packet if it will be needed into chunks? i think that single packet will slow down exectution of transfer without call too (no memo)
Michał Nazarewicz
11 hours ago
Splitting into chunks is an implementation detail of how some of the calls will need to be made. From IBC’s point of view, better do to everything in one go.
Michał Nazarewicz
11 hours ago
*Some of the calls to the smart contract. It’s something relayer needs to worry about.
Dzmitry Lahoda
11 hours ago
ok.
Dzmitry Lahoda
11 hours ago
so memo approach. and if ibc-rs will support not string, than binary endcoding (protobuf or borsch)
Dzmitry Lahoda
11 hours ago
i feel that 2 packets are better still so, but as it seems 3 votes for memo.
Dzmitry Lahoda
11 hours ago
so will explain newcomer memo approach