Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
||
| ## Why normalization is needed | ||
|
|
||
| In TON, an external-in message can be constructed and packed in different ways that are all logically identical. Fields such as the source address (`src`), the `import_fee`, and the state initialization (`init`) can vary depending on the sender's implementation or the API provider processing the message. |
There was a problem hiding this comment.
I wouldn't say that these variants are logically identical. We calculate normalized hash only for message lookup. Init field actually matters and actively used. Provider do not change the message content normally, it just calculated the hash from slightly different structure
| - The wallet contract is never deleted. | ||
|
|
||
| <Aside type="note"> | ||
| For dApps interacting with user wallets via TON Connect, or for exchanges controlling their outbound external messages, it is safe to reference traces using the normalized hash. This applies even before the transactions are finalized. |
There was a problem hiding this comment.
I don't get this paragraph. How outbound external messages are connected?
| ```typescript | ||
| import { beginCell, Cell, Address } from "@ton/core"; | ||
|
|
||
| function normalizeExternalMessage(destAddress: Address, bodyCell: Cell): Cell { |
There was a problem hiding this comment.
more like buildNormalizedExtIn(), not normalize
| 3. **InitState (`init`)**: Set to `nothing$0`. | ||
| 4. **Body (`body:(Either X ^X)`)**: Always store as a reference (`^X`). The content of the body itself is included without modification. | ||
|
|
||
| After constructing the cell with these standardized values, calculate its standard [cell hash](/foundations/serialization/cells) (the SHA-256 of the root cell). |
There was a problem hiding this comment.
This is misleading -> (the SHA-256 of the root cell).
|
|
||
| ## Uniqueness constraints | ||
|
|
||
| The normalized message hash is **not** a globally unique identifier across the entire blockchain. It is possible for custom smart contracts to process identical external messages that produce the same normalized hash, resulting in multiple distinct transaction chains. |
There was a problem hiding this comment.
as this paragraph exists (and it actually should), you should provide some guidance on what to do if someone need a globally unique identifier, maybe guide them to transactions or suggest LT + message
Shvandre
left a comment
There was a problem hiding this comment.
The new article brings very little additional info and duplicates significant part of message-lookup article. Consider removing theoretical info from message-lookup or on the opposite hand, expand the message-lookup acticle using new info. The main issue is same as were in old docs, I can't clearly see how the information is divided into the articles
Closes #1877
This PR adds a new page about the normalized hash