Skip to content

Conversation

@EmelyanenkoK
Copy link
Member

No description provided.


# Summary

This TEP proposes a way of how one contract may execute code (including get nethods) or read data of other contracts in asynchronous manner. Note: data may and often will become outdated during delivery and it MUST to be taken into account dduring protocol ddevelopment.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

during

@mr-tron
Copy link

mr-tron commented Jan 23, 2024

I don't understand why are you want to use all three flags (ihr, bounce, bounced) if you need only first. less changes in schemes.

@mr-tron
Copy link

mr-tron commented Jan 23, 2024

also not all messages in the past has flag ihr_disabled = true

select ihr_disabled, msg_type, count(1)  from blockchain.messages group by ihr_disabled, msg_type
+------------+---------+---------+
|ihr_disabled|msg_type |count    |
+------------+---------+---------+
|false       |ExtInMsg |53448826 |
|false       |ExtOutMsg|1923844  |
|false       |IntMsg   |3417621  |
|true        |IntMsg   |248430531|
+------------+---------+---------+

so we will need to parse old messages with one scheme and new with another based on additional context information

@mr-tron
Copy link

mr-tron commented Jan 23, 2024

select ihr_disabled, bounce,bounced,  count(1)  from blockchain.messages where msg_type = 'IntMsg' group by ihr_disabled, bounce, bounced
+------------+------+-------+---------+
|ihr_disabled|bounce|bounced|count    |
+------------+------+-------+---------+
|false       |false |false  |1586934  |
|false       |true  |false  |1830692  |
|true        |false |false  |71614077 |
|true        |false |true   |1999833  |
|true        |true  |false  |174818024|
+------------+------+-------+---------+


// We keep it to be able to parse history
int_msg_info_ihr_usual$0010 _:CommonInternalMsgInfo = CommonMsgInfo;
int_msg_info_ihr_no_bounce$0000 _:CommonInternalMsgInfo = CommonMsgInfo;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about ..._ihr_bounced$0001? That case is not possible?

```


Now we "freed" `0111` prefix space and can use it for new types of internal messages, for instance

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically, prefix 0011 is also not possible (ihr + bounce + bounced).


# Summary

This TEP proposes a way of how one contract may execute code (including get nethods) or read data of other contracts in asynchronous manner. Note: data may and often will become outdated during delivery and it MUST to be taken into account dduring protocol ddevelopment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"get nethods", "dduring", "ddevelopment" 🤔

@EmelyanenkoK
Copy link
Member Author

Another opportunity for new type of special messages is InternalExternal type:
that is message sent by onchain and delivered to the destination via hypercube router, however processed by TVM as external message:

  1. function selector set to -1
  2. balance bm of inbound message equal to real message balance
  3. Initial gas credit gc = 0, the initial current gas limit gl calculated the same way as with internal message

This will allow
a) gasless support even from old wallets
b) smart-contract unstucking in the case when it expects external message but for some reason doesn't fit to gas credit anymore

int_msg_info_external$01110000 _:CommonInternalMsgInfo = CommonMsgInfo;

can be used for this

@tikto29

This comment was marked as spam.

@galaxycores
Copy link

#141

Copy link

@galaxycores galaxycores left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave a reviwe

@ProgramCrafter
Copy link

An alternative is to allocate a fundamental smart contract, which would respond to a message address with state of that address at the beginning of the relevant masterchain block. Then, the requester might do anything using RUNVM or like.

Proof that this produces expected results with TON transaction ordering is left to the reader.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants