Create 0467-normalized-message-hash.md #467

EmelyanenkoK · 2025-04-06T09:43:52Z

No description provided.

mr-tron · 2025-04-06T10:19:52Z

LGTM

a2468834 · 2025-04-10T11:48:20Z

It is pretty cool idea. 🧐👍

I'm wondering that is there any advantage of norm message hash than the trace_id we already have?

For the trace_id (hash of transaction, which is composed of the starting external-in message), we are able to create the "invariant" of a series of TON transactions emerging on-chain.

For the dapp developers, they can pre-determine the message hash of external-in messages and then focus on tracking the first appeared transaction hash of those external-in messages (i.e., trace_ids).

If the external-in message is under bad format (e.g., invalid boc encoding, wrong action that cannot lead to success account transition, ...) TON nodes or lite-servers will directly reject the message, response error message, and leave zero on-chain log. However, if the external-in message can "produce" at least one TON transaction, we have got trace_id at the same time.

It seems that trace_id would be a more generalized concept about the topic of tracking a series of TON transactions. Besides, the input arguments of trace_id are more than norm message hash, so it's harder to make hash collision than norm message hash (as you mentioned in this TEP's Uniqueness section).

To sum up, I think maybe we could simply relax the current definition of norm message hash into just be the same thing as external-in message hash. Although it contains more items to calculate the hash value than just Hash( src addr_none$00 + dest addr_std$10 + empty state_init + msg_body), I believe the performance between two approaches will be merely no difference but the core concept behind it would be more straight forward.

EmelyanenkoK · 2025-04-18T10:17:50Z

@a2468834 Issue with trace-id (which is essentially the id of first transaction in trace) is that before message reached the blockchain we do not know the trace-id, for now, giving latencies of delivery and indexing it may require up to 20 seconds that is detrimental for UX. It is also not convenient for services : for instance some service made withdrawal and want to both insert it into database and give user link to explorer.

Since explorers (tonscan and tonapi) now can show pending transactions immediately (with latency as low as 200ms) after external reached explorer (not commited to blockchain, but merely got to indexers) it is expedient to provide the way how user can get identifier for such pending events.

a2468834 · 2025-04-18T14:34:12Z

Okay, I see. Waiting for the first transaction hash might be a pain point for some of services.

However, I'm not quite getting the point about why do you choose the current definition of norm message hash? I think it will not be significantly slower if we calculate cell hash of the "full" content of external message. Besides, both choices have the same bit length (i.e., 256 bits), so using hash of full external message would consume the same bits as the norm message hash.

ANIK101532

ARD

ANIK101532 · 2025-05-09T02:37:44Z

ARD

ANIK101532 · 2025-05-09T02:39:09Z

text/0467-normalized-message-hash.md

Create 0467-normalized-message-hash.md

8b3beda

This comment was marked as spam.

Sign in to view

ANIK101532 reviewed May 9, 2025

View reviewed changes

text/0467-normalized-message-hash.md

Copy link

ANIK101532 May 9, 2025

Choose a reason for hiding this comment

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

AR

18211308 reacted with thumbs up emoji

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create 0467-normalized-message-hash.md #467

Create 0467-normalized-message-hash.md #467

This comment was marked as spam.

This comment was marked as spam.

Create 0467-normalized-message-hash.md #467

Are you sure you want to change the base?

Create 0467-normalized-message-hash.md #467

Conversation

This comment was marked as spam.

This comment was marked as spam.

Choose a reason for hiding this comment

Choose a reason for hiding this comment