Suppose my message call order is like External World -> Contract A -> Contract B -> Contract C:
1. Would the messages be build into one block or possiblely into multiple blocks?
2. what if the last message call(B->C) failed, how could the state of Contract A and B be reverted?

Can anyone explain it to me? Still confused about the messaging mechanism in TON.

https://docs.ton.org/develop/smart-contracts/guidelines/message-delivery-guarantees

hope this helps

1. They can possibly be split into several blocks (especially if the contracts are in different shards)

2. When a transaction fails, it bounces a message back to the sender, so that smart contract can handle the error case

So it's not quite feasible to build latency/state sensitive cross-contract applications in TON, right? Like DeFi?

It’s all possible, just can be a little bit harder to architect

I think the only thing we can’t have here are flash loans

For case 2, the bounced message might get back to contract A a few blocks later, which leads to my contract A state inconsistent for short period? Put it in another way, the exception handle logic would guarantee TON blockchain to achieve eventual consitency.

Yes, quite tricky to reason about the logic for me now.

State may change by other transactions while the bounced one travels back. Same for the regular messages that contracts send to each other.

Generally, you need reentrancy consistency guarantees. Eth contracts also require them, but sometimes developers just use workarounds like a lock.

So, the state of your contract should be consistent at any time.

Not expect flashloan magic in TON, but would like to build complex DeFi Lego upon it, so it leads me to above questions.

Take jetton tranfer as a example, Jetton-wallet-A reduced by 10 jettons at logic time n, while Jetton-wallet-B failed for some wired reason(Like blacklisting A), but before the bounced message be handled at logic time n+3(3 blocks later) and revert A's balance. Between logic time n to n+2, the state of A is not quite consistent right?

The state is consistent, as it doesn't allow to do any unexpected operation. Until transfer "fully failed", including that jettons returned, user shouldn't be able to use those sent jettons for anything else.

I get it. Before A get the response message from B, contract A is locked preventing from further state operation, right?

You can do that, but it's not a best practice.

Jetton wallet, for instance, allows to send any jettons remaining on balance (in particular because it doesn't expect response on successful transfer).

And bounced message with K jettons just adds K jettons to balance.

Yes, but if some other contract try to read the my Jetton-wallet-A between logic time n, n+1, n+2, it would get the wrong balance, doesn't it? Only after n+3, the reverted operation would correct the A's balance.

That's why there is no way to call get-methods of other contracts.

This pattern is called "value-carrying messages": some part of jettons are stored not inside contracts but inside messages between them.

https://docs.ton.org/develop/smart-contracts/guidelines/get-methods#invoking-get-methods-from-other-contracts

It's like two POSTs between contracts instead of one GET to exchange state info.

Still not quite clear about the implication of async feature for complicated multi-contract applications, but very appreciate for your help. Gonna dive deeper.

Yes, but you usually don’t need such actions

Could be usual in DeFi apps? Read states from different contract on chain.

What kind of states do you need to read from your smart contract?

Here you usually need to spend some time designing architecture of smart contracts so that they will work efficiently in asynchronous and distributed environment of TON blockchain. It’s harder than on synchronous chains, but it allows TON to scale almost infinitely

I get the tradeoff.

Gonna read codes from open sourced FunC project.

This may help:
https://docs.ton.org/develop/smart-contracts/examples

You can also check some of my repositories, like “airdrop”, “fundraiser” or “jetton-migration”:
https://github.com/Gusarich?tab=repositories

thx!

It's wrong argument. We can't use get methods not because they're useless. There are a lot of cases, when such calls can greatly reduce contract complexity.
But it's not possible in ton because of sharding architecture.
To call get method on contract A from contract B, validator needs to know exact state of both of them and acquire lock. But it's not always possible, because contract A can be on different shard from contract B and validator of contract A may not even know state of contract B, let alone acquire any locks.
It's a tradeoff that allows scalability, but changes way you interact between contra ts.
@bitrocks01