TL-B Schemas op codes looks incorrectly calculated

[xssnick]

Hey @arseny30, I checked some of op codes and got totally different values.

For example for teleitem_msg_cancel_auction query_id:int64 = TeleitemMsg I've got 3002b06b, but you have 371638ae. Which method you used for calculation? I think it should be crc32 with IEEE table. Or you can use tlbc tool from ton for it.

I've tried the same method of calculation on jetton transfer just for test to be sure, and got the same result as in schema.
(ton-blockchain/TIPs#74)

To check I calculated crc on:
transfer query_id:uint64 amount:VarUInteger 16 destination:MsgAddress response_destination:MsgAddress custom_payload:Maybe ^Cell forward_ton_amount:VarUInteger 16 forward_payload:Either Cell ^Cell = InternalMsgBody` and got `8f8a7ea5`, then `0x8f8a7ea5 & 0x7FFFFFFF = 0x0f8a7ea5

Also, as far as I know all messages that are intended to be used as message body should be = InternalMsgBody (by TON standards)

[arseny30]

Yes, opcodes are just some hardcoded constants. Do you think it is a problem?

Regarding = InternalMsgBody, one may always write

internal_msg_body_teleitem$_ _:TeleitemMsg = InternalMsgBody;

[xssnick]

Yea, I think it can be a problem, because as I know in some products (especially libraries) those op codes are calculated based on tlb schemas, and also in almost all widely used contracts op codes has calculated values. So it will be better to use same approach here too.

If you want, I can help you with calculation :)

About the internal_msg_body_teleitem$_ _:TeleitemMsg = InternalMsgBody; - yea, but that not looks so clean :D
IMO - it is better to use InternalMsgBody explicitly.

[xssnick]

FYI: this is the tool which should be used for calculation (or something with similar algo)
https://github.com/ton-blockchain/ton/blob/4b940f8bad9c2d3bf44f196f6995963c7cee9cc3/crypto/tl/tlbc.cpp#L3085

tlbc -q -vvv schema.tlb

[arseny30]

Could you please give some examples of such libraries? Just curious. If the opcode is hard coded in the tlb schema, it is hard to miscalculate it based on the same schema.

but that not looks so clean :D

The schema is used internally to generate c++ code. In this code, it is pretty helpful to distinguish between all possible internal messages and internal messages valid for a specific smart contract.

[xssnick]

Could you please give some examples of such libraries? Just curious. If the opcode is hard coded in the tlb schema, it is hard to miscalculate it based on the same schema.

Thought about Ton Kotlin for example, but I see now that it should work fine with predefined tags, so technically it is ok to keep format we have now.

Some time ago I saw info about this in official smart contract writing recommendations, not see it in ton.org doc now.

But since such approach is used in standard contracts, still think it is better to follow it. Example

[andreypfau]

Could you please give some examples of such libraries? Just curious. If the opcode is hard coded in the tlb schema, it is hard to miscalculate it based on the same schema.

Thought about Ton Kotlin for example, but I see now that it should work fine with predefined tags, so technically it is ok to keep format we have now.

Some time ago I saw info about this in official smart contract writing recommendations, not see it in ton.org doc now.

But since such approach is used in standard contracts, still think it is better to follow it. Example

In ton-kotlin uses prefix calculation only if it is not present in the schema itself, in this case, since the constructor prefix is provided, it will not calculate it again.

But I agree with the argument that using random magic numbers as constants is bad practice. It is always better to use a transparent deterministic algorithm to generate them, for example, as already suggested above: tlbc CLI tool

UPD: prefix calculation uses only for Telegram TL, not for TON TL-B

[xssnick]

UPD: prefix calculation uses only for Telegram TL, not for TON TL-B

Actually not only TL, TL-B too, example. It will not calculate prefix only if _ exists after name.