v1.4.0 (CosmWasm v1)

[assafmo]

• In ContractInstance/start_engine(), check whether the wasm is v0.10 or v1 (using this export) and store it in ContractInstance, then (after the crypto stuff) according to the cosmwasm version, initialize the env object that is given to the contract in:
  • init
  • handle
  • query (in v1 query has env too).
    • Pass env from Go to query.
    • In query, don't need to pass contract_key prefixed to msg anymore, because it's also inside env.
• Also, invoke the right wasm function:
  • v0.10 init or v1 instantiate (link).
  • v0.10 handle or v1 execute (link)
• Afterwards, translate the v1 output into v0.10 output so that the Go code will handle it nicely.
  • Add plaintext_log() to cosmwasm-std v1
  • Handle v1 submessages. TODO: See how cosmwasm implemented this, we might want to piggyback off messages and handle it in the Go code, or maybe we can handle it right there inside the enclave by converting them to normal messages.
• Fix wasm validation. The new v1 API needs these while we currently have the v0.10 API which validates these. In order to support both in parallel, we need to fix the validation code.
• Implement new v1 API
  • db_read - we already have this from v0.10
  • db_write - we already have this from v0.10
  • db_remove - we already have this from v0.10
  • addr_validate
  • addr_canonicalize - need to alias from canonicalize_address (v0.10)
  • addr_humanize - need to alias from humanize_address (v0.10)
  • secp256k1_verify
  • secp256k1_recover_pubkey
  • ed25519_verify
  • ed25519_batch_verify
  • ed25519_sign - we've added on top on v1
  • secp256k1_sign - we've added on top on v1
  • debug - debug prints from inside the contract
  • query_chain - we already have this from v0.10
  • Charge gas for all functions that don't go back into the chain (Basically the addr & crypto ones).
• New contract entry points
  • ibc_channel_open()
  • ibc_channel_connect()
  • ibc_channel_close()
  • ibc_packet_receive()
  • ibc_packet_ack()
  • ibc_packet_timeout()
  • reply()
• Implement migration for cotnractInfo due to the new changes (added IBC port for each contract)
• When handling submessages of v0.10, make sure that errors when ReplyOn::Never fails the tx (because in v0.10 errors on submessages always failed the tx) - Code-Wise we saw that the behavior is as expected but a test need to be written
• Add Withdraw handler to v1 StakingMsg
• Handler callback_sig for v1 result inside the enclave
• Audit StargateQuery's whitelist
• Audit StargateMsg
• Test the data field - v1 lets replies override the data field, while v0.10 always returns the first message's data field.
• Initialize Env.TransactionInfo

[faddat]

So, I did this

• Scrt 46 cosmos-sdk#167

• Cosmos SDK v46 CosmWasm/wasmd#863

and

• ibc-go v5: cosmos-sdk 46 cosmos/ibc-go#1653

but depends on if ya'd like to get freaky or nah I suppose?

:P

downside: grpc only
upside: grpc only
upside: mempool prioritization

[assafmo]

So, I did this

• Scrt 46 cosmos-sdk#167
• Cosmos SDK v46 CosmWasm/wasmd#863

and

• cosmos sdk 46 upgrade cosmos/ibc-go#1653

but depends on if ya'd like to get freaky or nah I suppose?

:P

downside: grpc only upside: grpc only upside: mempool prioritization

We do want it, also has gov and authz goodies. But first we just need to check with all exchanges that they're not using the old REST API.

[assafmo]

But yeah please base new work on the cosmwasm-v1 branch ❤️

[faddat]

About the API, I think that these breaking changes are worth exploring because I think others will have similar concerns. It is my understanding that the GRPC gateway could get us around this but I don't know how accurate that is.

[assafmo]

It is my understanding that the GRPC gateway could get us around this but I don't know how accurate that is.

Yes that's accurate.

[faddat]

OK, so basically -- if we're fundamentally good with "we won't break exchange API's if go to 46" -- I'd like to either invite you guys to the Notional slack server, or to a call or something.

We're doing 46 on numerous chains and I'd love for secret to be one of them.

[assafmo]

OK, so basically -- if we're fundamentally good with "we won't break exchange API's if go to 46" -- I'd like to either invite you guys to the Notional slack server, or to a call or something.

We're doing 46 on numerous chains and I'd love for secret to be one of them.

We'd love to open a Slack connect! Our Slack org name is enigmaco.

We're still reaching out to exchanges and we'll know for sure in a few weeks. Our next chain upgrade is planned for September, so there's some time before we need to make a decision re 45->46.

Cc @YonatanE22