详解 TON 区块链交易的底层细节

Created: <2024-05-27 Mon>

Last updated: <2024-11-12 Tue>

TON Raw Tx Breakdown

1. TON 交易

在 TON 区块链中，通过 RPC sendBocReturnHash（或者 sendBoc）可以把签名后的 Tx 提交到链上。

1.1. Tx 解析实例 1（V4R2 钱包原生币转帐）

下面以 TON 测试网上的 Tx _6N7CAGyVt9UO_c10dgJHsS6x6SYey7kRJtU32DXGsg= 为例介绍一下这个 Tx 的细节。

这个交易的功能是测试网上 V4R2 钱包进行原生币 TON 的转帐：

0QCM8Tds9jQwLbxt-nASe4v7PRwOirxczwE1Yni1TdMYNHij (V4R2 wallet)      --- 0.123456 TON -->      0QCc6ls--YZh8WpSr6m1B9kX4EsNfmE3xDGJ93xxaRdOxAhM

这个 Tx 是通过 RPC sendBocReturnHash 提交上链的（注：这个 RPC 返回的是 Message Hash V8Y4wRJOdKphKnSjkBcWYTbIMTTcPrOq/1VA0zH1o4c=，不是 Tx Hash），提交 Tx 时的具体参数如下：

$ curl https://testnet.toncenter.com/api/v2/sendBocReturnHash -X POST -H "Content-Type: application/json" -d '{
  "boc": "te6cckEBAgEAswAB4YgBGeJu2exoYFt42/TgJPcX9no4HRV4uZ4CasTxapumMGgC7o4rP3HdzxLAj0eioBQ5O3hk4wCk884JPnEN2UBWdILxynlD6bzD7EctVOl8OqSn9oa3tqtRlpJpS7itpE54CU1NGLsyjn4gAAAAGAAcAQB6QgBOdS2ffMMw+LUpV9Tag+yL8CWGvzCb4hjE+744tIunYiA63lAAAAAAAAAAAAAAAAAAAAAAAABIZWxsb86+YLo="
}'
{"ok":true,"result":{"@type":"raw.extMessageInfo","hash":"V8Y4wRJOdKphKnSjkBcWYTbIMTTcPrOq/1VA0zH1o4c=","@extra":"1716637630.853718:6:0.03332699648976334"}}

上面命令中提到的 Base64 编码的 Tx 数据可以分解为下面这种更清晰的表达方式：

注 1：flags and size（在上面例子中就是二进制 01000001）的前 3 bits 表示 has_idx/has_crc32c/has_cache_bits（如果 has_idx 为 1，则在 root cell list 后面会在额外的 index 数据。has_cache_bits 仅当 has_idx 为 1 时才有意义）；中间 2 bits 均为 0；最后 3 bits 表示编码 Cell 的数量所需的最小字节数（上面例子中为 1）。

注 2：refs descriptor 的计算公式为： r+8s+32l ，其中 r 表示当前 Cell 的引用的个数，所以 0≤r≤4 ； s 的可选值为 0/1，分别表示 Ordinary Cell/Exotic Cell； l 是 level of Cell。

注 2：bits descriptor 的计算公式为： floor(b/8)+ceil(b/8) ，其中 b 是 Cell data 的二进制位数，由于一个 Cell 最多有 1023 位数据，所以 0≤b≤1023 。

1.1.1. Cell 0

前面介绍中提到了 Cell 0 由下面数据组成（下面十六进制数据共有 904 bits，需要根据 Cell 的 bits descriptor 信息才知道 padding 的比特位数是 3，才能知道 Cell 0 真正比特位数是 901：

0x880119e26ed9ec68605b78dbf4e024f717f67a381d1578b99e026ac4f16a9ba6306802ee8e2b3f71ddcf12c08f47a2a014393b7864e300a4f3ce093e710dd940567482f1ca7943e9bcc3ec472d54e97c3aa4a7f686b7b6ab519692694bb8ada44e78094d4d18bb328e7e2000000018001c

Cell 0 数据可分解为下面更易读的形式：

注 1：TON 的钱包合约是在用户自己首次提交 Tx 时才会被部署（别人给你转币的场景，并不会帮你部署合约），上面例子中，由于 seqno 为 3，所以不是首次提交 Tx 了，钱包合约早就已经部署了。

注 2：对于 V4R2 版本的钱包来说，op 为 0 表示原生币发送，参考： https://github.com/ton-blockchain/wallet-contract/blob/4111fd9e3313ec17d99ca9b5b1656445b5b49d8f/func/wallet-v4-code.fc#L94

注 3：对于 V4R2 版本的钱包来说，body 中的 signature 在 signing message 的前面（V5R1 钱包恰恰相反，signature 在 signing message 的后面）。这是由 V4R2/V5R1 合约中的代码决定的，参考： https://github.com/ton-blockchain/wallet-contract/blob/4111fd9e3313ec17d99ca9b5b1656445b5b49d8f/func/wallet-v4-code.fc#L73 和 https://github.com/ton-blockchain/wallet-contract-v5/blob/88557ebc33047a95207f6e47ac8aadb102dff744/contracts/wallet_v5.fc#L165

注 4：上面数据中既有二进制表示，又有十六进制表示。并且这些数据没有按字节（或半字节）对齐，所以如果直接在 Tx 的十六进制表达中搜索签名数据，会找不到（因为没有按半字节对齐，它们错位了）。

1.1.2. Cell 1

Cell 0 有且只有一个引用，就是 Cell 1。前面介绍中提到了 Cell 1 由下面 488 bits 数据组成：

0x42004e752d9f7cc330f8b52957d4da83ec8bf02586bf309be218c4fbbe38b48ba762203ade5000000000000000000000000000000000000048656c6c6f

Cell 1 数据可分解为下面更易读的形式：

注：Cell 1 一共有 414+1+1+72 = 488 bits 数据。

1.2. Tx 解析实例 2（V5R1 钱包部署及原生币转帐）

下面介绍测试网上另一个 Tx b35192b5d7c975d3c86903059964e38775aa6cf271cd6923d0c9ef21e79e2413 的细节。

这个交易的功能是测试网上 V5R1 钱包进行原生币 TON 的转帐（注：由于这是帐户 0QBu6dyecFJBVzjtTEUTTPcZpdJhCDnIMQ3To4PZS0DrVqp_ 的首个 Tx，所以这个 Tx 中还会部署钱包合约）：

0QBu6dyecFJBVzjtTEUTTPcZpdJhCDnIMQ3To4PZS0DrVqp_ (V5R1 wallet)      --- 0.1234 TON -->      0QASPuJu9dYvKyQuV-vQL4YKOEa9uXNkslh0qRbU5quI7TTU

这个 Tx 是通过 RPC sendBoc 提交上链的，提交 Tx 时的具体参数如下：

$ curl 'https://testnet.toncenter.com/api/v2/jsonRPC' \
-X POST \
-H 'Content-Type: application/json' \
--data-raw '{"id":"1","jsonrpc":"2.0","method":"sendBoc","params":{"boc":"te6cckECGQEAA3UAA+eIAN3TuTzgpIKucdqYiiaZ7jNLpMIQc5BiG6dHB7KWgdasEY5tLO3P////v////+AAAAAW8m9QlO0hQ8Io17rpq2NooiJiF5nEC4ADFcikdU2QvJ/x6LwsurKdCxkgJdhRsQbnbQY7ERPoMFSpNLGeXLsoPAEVFgEU/wD0pBP0vPLICwICASADDgIBSAQFAtzQINdJwSCRW49jINcLHyCCEGV4dG69IYIQc2ludL2wkl8D4IIQZXh0brqOtIAg1yEB0HTXIfpAMPpE+Cj6RDBYvZFb4O1E0IEBQdch9AWDB/QOb6ExkTDhgEDXIXB/2zzgMSDXSYECgLmRMOBw4hEQAgEgBg0CASAHCgIBbggJABmtznaiaEAg65Drhf/AABmvHfaiaEAQ65DrhY/AAgFICwwAF7Ml+1E0HHXIdcLH4AARsmL7UTQ1woAgABm+Xw9qJoQICg65D6AsAQLyDwEeINcLH4IQc2lnbrry4Ip/EAHmjvDtou37IYMI1yICgwjXIyCAINch0x/TH9Mf7UTQ0gDTHyDTH9P/1woACvkBQMz5EJoolF8K2zHh8sCH3wKzUAew8tCEUSW68uCFUDa68uCG+CO78tCIIpL4AN4BpH/IygDLHwHPFsntVCCS+A/ecNs82BED9u2i7fsC9AQhbpJsIY5MAiHXOTBwlCHHALOOLQHXKCB2HkNsINdJwAjy4JMg10rAAvLgkyDXHQbHEsIAUjCw8tCJ10zXOTABpOhsEoQHu/Lgk9dKwADy4JPtVeLSAAHAAJFb4OvXLAgUIJFwlgHXLAgcEuJSELHjDyDXShITFACWAfpAAfpE+Cj6RDBYuvLgke1E0IEBQdcY9AUEnX/IygBABIMH9FPy4IuOFAODB/Rb8uCMItcKACFuAbOw8tCQ4shQA88WEvQAye1UAHIw1ywIJI4tIfLgktIA7UTQ0gBRE7ry0I9UUDCRMZwBgQFA1yHXCgDy4I7iyMoAWM8Wye1Uk/LAjeIAEJNb2zHh10zQAFGAAAAAP////tlBsCnz1yWP/sjO5CFA7bkxE/CSaZC7YJQuMiwpiYnQoAIKDsPIbQIXGAAAAIZCAAkfcTd66xeVkhcr9egXwwUcI17cubJZLDpUi2pzVcR2okxqxAAAAAAAAAAAAAAAAAAAAAAAAEhlbGxvIHdvcmxkv4KlZg=="}}'
{
  "ok": true,
  "result": {
    "@type": "ok",
    "@extra": "1722675676.5674324:1:0.5131636309140121"
  },
  "id": "1",
  "jsonrpc": "2.0"
}

上面命令中提到的 Base64 编码的 Tx 数据可以分解为下面这种更清晰的表达方式：

可见，这个 Tx 中一共编码了 25 个 Cell，为什么这么多呢？这是由于这个 Tx 是帐户 0QBu6dyecFJBVzjtTEUTTPcZpdJhCDnIMQ3To4PZS0DrVqp_ 的首个 Tx，所以这个 Tx 中还包含了钱包合约的 Init Code 和 Init Data，所以导致 Cell 会比较多。

1.2.1. Cell 0

前面介绍中提到了 Cell 0 由下面数据组成：

8800ddd3b93ce0a482ae71da988a2699ee334ba4c2107390621ba74707b29681d6ac118e6d2cedcfffffffbfffffffe00000
0016f26f5094ed2143c228d7bae9ab6368a222621799c40b800315c8a4754d90bc9ff1e8bc2cbab29d0b192025d851b106e7
6d063b1113e83054a934b19e5cbb283c

下面把 Cell 0 数据分解为更易读的形式：

从上面的分析中可知 Cell 0 共有 3 个 refs（Cell 0 的 cell refs 数据为 0x011516）：

1. Init Code，对应的 Cell Index 是 0x01，即 Cell 1

2. Init Data，对应的 Cell Index 是 0x15，即 Cell 21

3. Basic Actions，对应的 Cell Index 是 0x16，即 Cell 22

下面我们重点分析一下 Cell 22。

1.2.2. Cell 22/23/24

通过前面的介绍可知 Cell 22 保存着 Wallet V5R1 钱包的 Basic Actions，这节将分析它。

Basic Actions 是 Out List 结构，它在 @ton/core 中是这样序列化的：

/*
out_list_empty$_ = OutList 0;
out_list$_ {n:#} prev:^(OutList n) action:OutAction
  = OutList (n + 1);
 */
export function storeOutList(actions: OutAction[]) {
    const cell = actions.reduce((cell, action) => beginCell()
            .storeRef(cell)                    // Cell 23 保存在 Cell 22 的 refs 中。Cell 22 的第 1 个 ref
            .store(storeOutAction(action))
            .endCell(),
        beginCell().endCell()                  // Begin with empty cell，就是我们这个例子中的 Cell 23（空 Cell）
    );

    return (builder: Builder) => {
        builder.storeSlice(cell.beginParse());
    }
}

/*
action_send_msg#0ec3c86d mode:(## 8)
  out_msg:^(MessageRelaxed Any) = OutAction;
*/
const outActionSendMsgTag = 0x0ec3c86d;
function storeOutActionSendMsg(action: OutActionSendMsg) {
    return (builder: Builder) => {
        builder.storeUint(outActionSendMsgTag, 32)     // Cell 22 的数据部分 1
            .storeUint(action.mode, 8)                 // Cell 22 的数据部分 2
            .storeRef(beginCell().store(storeMessageRelaxed(action.outMsg)).endCell()); // Cell 22 的第 2 个 ref
    }
}

Cell 22 数据可分解为下面更易读的形式：

Cell 22 的两个 refs 分别为：

1. Cell 23，这是一个空 Cell，是序列化 Out List 时的首个 Cell。

2. Cell 24，Send Message 主要内容在这个 Cell 中。

注：Cell 22 中指定的 send mode 为 2，并没有包含 +1 flag。这会导致：尽量转账数量指定的是 1.234 TON，但目标地址真正收到的 TON 的数量会在 1.234 的基础上扣除手续费（会小于 1.234）。我们查询目标地址余额也会发现确实比 1.234 要少：

$ curl 'https://testnet.toncenter.com/api/v2/getAddressBalance?address=0QASPuJu9dYvKyQuV-vQL4YKOEa9uXNkslh0qRbU5quI7TTU'
{"ok":true,"result":"1233600000"}

Cell 24 数据可分解为下面更易读的形式：

1.3. Tx 解析实例 3（V5R1 钱包 Jetton 转账）

下面以 TON 主网上的 Tx edc724b8b3733afc5133d62c2b65bafa3fae31df876d87b576050ce3369e15b4 为例介绍一下这个 Tx 的细节。

这个交易的功能是主网上 V5R1 钱包进行 USDT 的转帐：

UQCh41gQP1A4I0lnAn6yAfitDAIYpXG6UFIXqeSz1TVxNOJ_ (V5R1 wallet)             --- 0.11 USDT -->          UQAU3o5-Sp1MYRpw3U7b_wmARxqI49LxiFhEoVCxpUKjTYXk
                 ^                                                                                                           ^
                 |                                                                                                           |
                 v                                                                                                           v
EQDg4AjfaxQBVsUFueenkKlHLhhYWrcBvCEzbEgfrT0nxuGC (USDT jetton wallet)                                 EQCQZAeLOM3kwjdn1CTVmRThDro138uxqvGeLfB1sFTNhA5J (USDT jetton wallet)

提交 Tx 时的具体参数如下：

$ curl https://toncenter.com/api/v2/sendBocReturnHash -X POST -H "Content-Type: application/json" -d '{
  "boc": "te6cckECBgEAASIAAUWIAUPGsCB+oHBGks4E/WQD8VoYBDFK43SgpC9TyWeqauJoDAEBoXNpZ25///8RZro7egAAAAGYUu8+ZHZK/wWb9ojB++h5tz2ie7e4GktWZfr475zJcnpRLZADd9wbyuuV7GXr8QzKeqvQbSDVJlgv4bcdnjwDYAICCg7DyG0DAwQAAAFoYgBwcARvtYoAq2KC3PPTyFSjlwwsLVuA3hCZtiQP1p6T4yAvrwgAAAAAAAAAAAAAAAAAAQUAyA+KfqUAAAAAAAAAADAa2wgAKb0c/JU6mMI04bqdt/4TAI41Ecel4xCwiUKhY0qFRpsAKHjWBA/UDgjSWcCfrIB+K0MAhilcbpQUhep5LPVNXE0CAgAAAAB0ZXN0IGNvbW1lbnQIl4du"
}'

上面命令中提到的 Base64 编码的 Tx 数据可以分解为下面这种更清晰的表达方式：

1.3.1. Cell 0

前面介绍中提到了 Cell 0 由下面数据组成：

880143c6b0207ea0704692ce04fd6403f15a1804314ae374a0a42f53c967aa6ae2680c

下面把 Cell 0 数据分解为更易读的形式：

1.3.2. Cell 1

上面例子中 Cell 0 的 body ref flag 为 1，表示 Body 保存在 Cell 0 的 ref 中，而 Cell 0 只有一个 ref（Cell 1），所以 Cell 1 保存的就是 Body。

下面把 Cell 1 数据分解为更易读的形式：

1.3.3. Cell 2/3/4/5

通过前面的介绍可知 Cell 2 保存着 Wallet V5R1 钱包的 Basic Actions，这节将分析它。Basic Actions 是 Out List 结构，细节可参考节 1.2.2。

Cell 2 数据可分解为下面更易读的形式：

Cell 2 的两个 refs 分别为：

1. Cell 3，这是一个空 Cell，是序列化 Out List 时的首个 Cell。

2. Cell 4，Send Message 主要内容在这个 Cell 中。

Cell 4 数据（62007070046fb58a00ab6282dcf3d3c854a3970c2c2d5b80de1099b6240fd69e93e3202faf080000000000000000000000000001）可分解为下面更易读的形式：

Message Body 保存在 Cell 4 的 ref（即 Cell 5）中，下面我们介绍 Cell 5 的内容。

1.3.4. Cell 5（Jetton 转帐时的 Message body）

Cell 5 数据可分解为下面更易读的形式：

2. 附录

2.1. Message Hash 计算

通过 RPC sendBocReturnHash 提交 Tx 时会返回 Message Hash。

Message Hash 就是 Root Cell 的“标准 Cell 表示哈希”，其具体规则可参考： Standard Cell representation hash。

下面是节 1.1 中 Message Hash 为 V8Y4wRJOdKphKnSjkBcWYTbIMTTcPrOq/1VA0zH1o4c= ，下面演示一下它的计算过程：

import hashlib
import base64

## Standard Cell representation hash calculation
## https://docs.ton.org/develop/data-formats/cell-boc#standard-cell-representation-hash-calculation

cell_1_refs_descriptor = '00'
cell_1_bits_descriptor = '7a'
cell_1_data = '42004e752d9f7cc330f8b52957d4da83ec8bf02586bf309be218c4fbbe38b48ba762203ade5000000000000000000000000000000000000048656c6c6f'
## cell 1 has no refs, so skip the refs descriptor and refs hashes
cell_1_cell_hash = hashlib.sha256(
    bytes.fromhex(cell_1_refs_descriptor
                  + cell_1_bits_descriptor
                  + cell_1_data
                  )).hexdigest()

cell_0_refs_descriptor = '01'
cell_0_bits_descriptor = 'e1'
cell_0_data = '880119e26ed9ec68605b78dbf4e024f717f67a381d1578b99e026ac4f16a9ba6306802ee8e2b3f71ddcf12c08f47a2a014393b7864e300a4f3ce093e710dd940567482f1ca7943e9bcc3ec472d54e97c3aa4a7f686b7b6ab519692694bb8ada44e78094d4d18bb328e7e2000000018001c'
cell_0_refs_depth = '0000'
cell_0_refs_hashes = cell_1_cell_hash

cell_0_cell_hash = hashlib.sha256(
    bytes.fromhex(cell_0_refs_descriptor
                  + cell_0_bits_descriptor
                  + cell_0_data
                  + cell_0_refs_depth
                  + cell_0_refs_hashes
                  )).digest()

print(cell_0_cell_hash.hex())  # 57c638c1124e74aa612a74a39017166136c83134dc3eb3aaff5540d331f5a387
print(base64.b64encode(cell_0_cell_hash))  # V8Y4wRJOdKphKnSjkBcWYTbIMTTcPrOq/1VA0zH1o4c=

2.2. Tx 解析实例 1 中的签名计算（Python）

节 1.1 中的交易的 Ed25519 签名数据是：

0x5dd1c567ee3bb9e25811e8f4540287276f0c9c60149e79c127ce21bb280ace905e394f287d37987d88e5aa9d2f875494fed0d6f6d56a32d24d297715b489cf01

下面 Python 代码演示了它是如何计算出来的：

import hashlib
import nacl.encoding          # pip install pynacl
import nacl.signing

## 生成要签名的数据，它是 signing message 的 Standard Cell representation hash
## See https://docs.ton.org/develop/data-formats/cell-boc#standard-cell-representation-hash-calculation
def get_data_to_be_signed():
    cell_1_refs_descriptor = '00'
    cell_1_bits_descriptor = '7a'
    cell_1_data = '42004e752d9f7cc330f8b52957d4da83ec8bf02586bf309be218c4fbbe38b48ba762203ade5000000000000000000000000000000000000048656c6c6f'
    cell_1_hash = hashlib.sha256(
        bytes.fromhex(cell_1_refs_descriptor + cell_1_bits_descriptor + cell_1_data)).hexdigest()

    signing_message_refs_descriptor = '01'  # signing message has one reference to cell 1
    signing_message_bits_descriptor = '1c'
    signing_message_data = ('29a9a317'  # wallet id, you can get it from the cell 0
                            + '6651cfc4'  # expire time, you can get it from the cell 0
                            + '00000003'  # seqno, you can get it from the cell 0
                            + '00'  # op, you can get it from the cell 0
                            + '03'  # send mode, you can get it from the cell 0
                            + '0000'  # max depth as array
                            + cell_1_hash)

    return hashlib.sha256(bytes.fromhex(signing_message_refs_descriptor
                                        + signing_message_bits_descriptor
                                        + signing_message_data)).digest()

## Ed25519 私钥
private_key = bytes.fromhex('e36740a50f44ae14fdc3682f14361f7a686738dd624c0e9b9bc9183b7ef6b7cb')

## 使用指定的私钥生成签名密钥
signing_key = nacl.signing.SigningKey(private_key, encoder=nacl.encoding.RawEncoder)

## 生成验证密钥
verify_key = signing_key.verify_key
print("public key:", verify_key.encode().hex())  # 6091a31d2acd5b5eb42a29888d106043796c1a438d1e000406e688f3d831056e

## 要签名的消息
data = get_data_to_be_signed()
print("data to be signed:", data.hex())  # 468e22fbaf2cf2578ecd879334eaf4bb80feb8e2f07d2c1e6f80201a50616ed9

## 对 data 进行签名
signature = signing_key.sign(data).signature
print("signature:",
      signature.hex())  # 5dd1c567ee3bb9e25811e8f4540287276f0c9c60149e79c127ce21bb280ace905e394f287d37987d88e5aa9d2f875494fed0d6f6d56a32d24d297715b489cf01

## 验证签名
try:
    verify_key.verify(data, signature)
    print("Signature verified")
except nacl.exceptions.BadSignatureError:
    print("Signature verification failed")

2.3. 帐户合约部署 VS Jetton 合约部署

往目标地址转账 Jetton 时，如果目标地址还没有部署 Jetton 合约，则会先为目标地址部署 Jetton 合约。这是因为用户的 Jetton 余额保存在用户的 Jetton 合约中， 不部署 Jetton 合约的话，就无法为目标地址用户记录 Jetton 余额。

这一点和原生币不一样！我们给某目标地址转账原生币时，如果目标帐户合约还没有部署也无需帮他部署，因为在目标合约部署之前 TON 链上有能力为这个地址记录原生币 TON 的余额（即 TON 链可以为处于 uninitialized 状态的合约记录原生币余额，也就是说原生币 TON 余额并不是保存在合约中）。其实就算你在转账 TON 时想帮目标帐户合约部署也很难实现，因为你没有目标帐户合约的 Init Code 和 Init Data，你最多只是猜测它可能是 V4R2/V5R1 等合约，如果目标合约完全是用户自已定制的，这种情况是没有办法帮忙部署的，除非他在链下发送给你。

关于钱包帐户合约和 Jetton 合约的部署时机的对比可以参考表 1。

Table 1: 钱包帐户合约部署时机 VS Jetton 合约部署时机

考虑场景：Address 1 往 Address 2 转账 Jetton USDT，这会涉及到几个合约的部署呢？

1. Address 1 曾经往外发过交易（帐户合约已经部署），Address 2 以前收过 Jetton USDT。这时不会有合约被部署。

2. Address 1 曾经往外发过交易（帐户合约已经部署），但 Address 2 以前没有收过 Jetton USDT。在这种情况下这个 Tx 会部署一个合约，即别人（即 Address 2）的 Jetton USDT 合约。

3. Address 1 以前没有往外发过交易（Address 1 帐户合约未部署过），Address 2 以前收过 Jetton USDT。在这种情况下这个 Tx 会部署一个合约，即自己（即 Address 1）的帐户合约。

4. Address 1 以前没有往外发过交易（Address 1 帐户合约未部署过），而且恰好 Address 2 是首次收到 Jetton USDT。在这种情况下这个 Tx 会部署两个合约：一是自己（即 Address 1）的帐户合约；二是部署别人（即 Address 2）的 Jetton USDT 合约。链上就有这样的例子，比如 Tx 00defd4857b646c31b46049c1c8f61cc17d6cf3df1d0a22f40e325126dd2296c 。

注意：上面讨论的是最简单的场景，没有考虑 Mintless Jetton 的情况，也没有考虑由于 Transfer Notification 触发其它合约部署的情况。

• 本文转载自： aandds.com/blog/ton-tx.h... , 如有侵权请联系管理员删除。