How can i know what data pass to contract ?
for example what data pass in this transaction ?
https://tonscan.org/tx/kYzszhSP6vaDyfg1RK7kWfDMzTYV-6cx8gUWvcdCA-U=

You need decode it.

what data ?

Each smart contract accepts a few different types of input. It checks the input against those different types. If it matches one, it'll execute it.

Usually, the first 32 bits of data is the operation code and is used to identify the type of data that is being sent.

Smart contracts usually read this 32 bit op code first, and then decode the rest of it.

anyone know how to read mapping data on Smart Contract through TypeScript?

Like this

It's in BOC, you need to know the TL-B schema of the data. Then you can use any Slice implementation to read the data according to the schema.

Hi, anyone know how to implement fromBoc?

Let say the data I got here is an Object in TypeScript, which is Boc in TVM.

Red area is the BOC data.

And the Green area is the Cell deserialization?

🙈😵‍💫

It looks more like BOC represented as a byte array.

green area - serialized boc in regular bytearray

b5ee9c72 - magic constant for BOC file format

Yes, the original data structure I stored is like this, does that related?

I still can't read or decoded it properly once I want to read those data directly from Smart Contract then.

what is b5ee9c72 means?

constructor prefix

it does... looks like magic

its crc32 of scheme

precalculated

For `toBoc method, is there any more description for how to use this method in `tonWeb?

- What is idx for?
- What is crc32 usage?
- What is cacheBits?
- What is flags for?

idx - indexed cells, for optimization purposes
crc32 - checksum for boc
cacheBits - cache bits for optimization purposes
flags - reserved, always 0

TL-B schema of the data, yeh, I know what is the input I send in.

The TL-B schema is more like this, right?

Person#1 {
name:string;
age:int;
}


Then basically is a big object called Cell[] from on-chain data.

seems not this issued

One question expand with BOC (Bags Of Cells):
Is there any better way to parsing & decoding those data?


https://t.me/tondev_eng/15458
https://t.me/tondev_eng/24321

https://docs.ton.org/develop/data-formats/cell-boc#bag-of-cells
https://docs.ton.org/develop/research-and-development/boc

https://explorer.toncoin.org/account?account=Ef8U8XeSb5hTz5TjWrO9Y0oFHDUsu0qcmi2hg6r_tADNScU_

Hey 👋
Is there any standard for assigning names to transaction op-codes, to be displayed in TON explorers?

I think a get-method in each contract can help here.

Hello! There is, defined by TL-B standard https://docs.ton.org/develop/data-formats/tl-b-language#constructors.
> If a tag is not explicitly provided, the TL-B parser must compute a default 32-bit constructor tag by hashing with CRC32 algorithm the text of the “equation” with | 0x80000000 defining this constructor in a certain fashion.

I didn't phrase it correctly. Here I try once more:

In explorers, in front of each tx, an op code is displayed, which is 8 hex digits. This is not readable.

Specific opcodes like jetton or nft show the operation name instead. This makes them more readable.

I want to define these names for my smart contract, so that when anyone visits the explorer and opens one of these contracts, views readable operation names instead of opcodes.

You need to reach out to explorers' authors for that.

I thought devs of multiple explorers might be here and have an idea on that.

We need to develop ABI for smart contracts, which will do that.

But it's not quite easy task, and there's no active discussion currently

You're the expert here, but to keep the discussion active, how about this:

Currently explorers show the Jetton balance of an smart contract if it is TEP74. And it looks like they update the balance quite frequently.

- Another TEP could decide on the standard.

- (1) One idea is that this get method is named, for example, get_opcode_names and returns a dictionary mapping 32bit op codes to short strings. It also might have a limit of at most, let's say, 100 entries.

- (2) Another idea is that this get method is named, for example, get_opcode_name and returns a short string when given an opcode as argument.

- (3) The next idea is that each smart contract can send a message to a specific address with a specific opcode. In the message body, there can be a dictionary mapping these opcodes to short string names. Explorers can look for the last message from this smart contract to that specific address and use those names for opcodes. This way, smart contract developers can send that message, whenever they want to update the opcode names.

- In the options above, there is the problem of caching. For how long should they be cached? When and how should they be invalidated and what if a name changes?

- The next step after showing opcode names, is showing values for other parameters in the message along with their name. How about just returning a TLB scheme instead of a short name string, so that explorers can also show other parameters, for example, in details of each transaction.

The option (3) has the problem that child smart contracts must also send a message to the address, which makes it unfeasible. In the case of child smart contracts, op-codes can be looked up from parent smart contract.

For example, jetton wallets have get_wallet_data which identifies their parent. In this case, op-code names can be delegated to parent, i.e. jetton master.