block ConceptImage

docs/develop/dapps/telegram-apps/testing-apps.mdx

@@ -87,6 +87,7 @@ eruda.init()
 ### Step 3: Launch Eruda
 
 Deploy your Mini App, launch it and just press Eruda icon to start debugging!
-
+````mdx-code-block
 <ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt 0 0', display: 'flex-box'}} src="/img/docs/telegram-apps/eruda-2.png" />
-<ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt', display: 'flex-box'}}  src="/img/docs/telegram-apps/eruda-3.png" />
+<ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt', display: 'flex-box'}}  src="/img/docs/telegram-apps/eruda-3.png" />
+````

docs/develop/smart-contracts/guidelines/message-delivery-guarantees.mdx

@@ -110,9 +110,9 @@ Fortunately, TON works in such a way that any internal message will definitely b
 It therefore seems like _lt_ solves the issue about message delivery order, because we know that a transaction with a lower _lt_ will be processed first. But this doesn't work in every scenario.
 
 Suppose that there are two contracts - _A_ and _B_. _A_ receives an external message which triggers it to send two internal messages to _B_, let's call these messages _1_ and _2_. In this simple case, we can be 100% sure that _1_ will be processed by _B_ before _2_ because it has a lower _lt_.
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-1.png" />
-
+````
 But this is just a simple case when we only have two contracts. How does our system works in more complex cases?
 
 ### Several Smart Contracts
@@ -151,15 +151,15 @@ We have two possible trace for these transaction,
 <br></br>
 ````
 The same thing happens in the reverse case, when two contracts _B_ and _C_ send a message to one contract _A_. Even if message `B -> A` was sent before `C -> A`, we can't know which one of them will be delivered first. The `B -> A` route may require more shard chain hops.
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-3.png" />
-
+````
 There can be many possible scenarios of smart contract interactions, and in any scenario with more than 2 contracts, the order of messages delivery may be arbitrary. The only guarantee is that messages from any contract _A_ to any contract _B_ will be processed in order of their logical time. Some examples are below.
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-4.png" />
 <ConceptImage src="/img/docs/msg-delivery-5.png" />
 <ConceptImage src="/img/docs/msg-delivery-6.png" />
-
+````
 ## Conclusion
 
 The TON blockchain's asynchronous structure creates challenges for message delivery guarantees. Logical time helps to establish event and transaction order but doesn't guarantee message delivery order between multiple smart contracts due to varying routes in shard chains. Despite these complexities, TON ensures internal message delivery, maintaining network reliability. Developers must adapt to these nuances to harness TON's full potential in building innovative decentralized applications.

i18n/zh-CN/docusaurus-plugin-content-docs/current/develop/dapps/telegram-apps/testing-apps.mdx

@@ -87,6 +87,7 @@ eruda.init()
 ### 步骤 3：启动 Eruda
 
 部署你的小程序，启动它，然后只需按 Eruda 图标即可开始调试！
-
+````mdx-code-block
 <ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt 0 0', display: 'flex-box'}} src="/img/docs/telegram-apps/eruda-2.png" />
-<ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt', display: 'flex-box'}}  src="/img/docs/telegram-apps/eruda-3.png" />
+<ConceptImage style={{maxWidth:'200pt', margin: '10pt 20pt', display: 'flex-box'}}  src="/img/docs/telegram-apps/eruda-3.png" />
+````

i18n/zh-CN/docusaurus-plugin-content-docs/current/develop/smart-contracts/guidelines/message-delivery-guarantees.mdx

@@ -105,9 +105,9 @@ TON 中的一笔交易包括以下内容：
 因此，看起来 _lt_ 解决了消息传递顺序的问题，因为我们知道具有较低 _lt_ 的交易将首先被处理。但这并不适用于每个场景。
 
 假设有两个合约 - _A_ 和 _B_。_A_ 收到一个外部消息，触发它向 _B_ 发送两个内部消息，我们称这些消息为 _1_ 和 _2_。在这个简单的情况下，我们可以 100% 确定 _1_ 将在 _2_ 之前被 _B_ 处理，因为它具有较低的 _lt_。
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-1.png" />
-
+````
 但这只是一个简单的案例，当我们只有两个合约时。我们的系统在更复杂的情况下是如何工作的？
 
 ### 多个智能合约
@@ -145,15 +145,15 @@ TON 中的一笔交易包括以下内容：
 <br></br>
 ````
 同样，当两个合约 _B_ 和 _C_ 向一个合约 _A_ 发送消息时，情况也是如此。即使 `B -> A` 的消息在 `C -> A` 之前发送，我们也无法知道哪一个将先被送达。`B -> A` 的路由可能需要更多的分片链转运。
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-3.png" />
-
+````
 在多个智能合约互动的许多可能的场景中，消息传递顺序可能是任意的。唯一的保证是，来自任何合约 _A_ 到任何合约 _B_ 的消息将按照它们的逻辑时间顺序处理。下面是一些示例。
-
+````mdx-code-block
 <ConceptImage src="/img/docs/msg-delivery-4.png" />
 <ConceptImage src="/img/docs/msg-delivery-5.png" />
 <ConceptImage src="/img/docs/msg-delivery-6.png" />
-
+````
 ## 结论
 
 TON 区块链的异步结构为消息传递保证带来挑战。逻辑时间有助于确定事件和交易顺序，但由于分片链中的路由不同，它并不能保证多个智能合约之间的消息传递顺序。尽管存在这些复杂性，TON 仍然能够确保内部消息的传递，维护网络的可靠性。开发人员必须适应这些细微差别，以充分利用 TON 的潜力构建创新的去中心化应用程序。