T
Teach Me AnythingTMA
Video History
Page 32 / 43
▶
3、人的本性是“先天”决定的吗？ （鲍查德和莱肯的“双生子”研究） 主要内容：通过比较同卵双胞胎（基因100%相同）和异卵双胞胎在分开抚养和一起抚养情况下的心理与行为特质，惊人地发现对于许多特性（如智商、人格、兴趣），遗传的影响力远超我们的想象。这引发了关于先天与后天的深刻讨论。
▶
第7课：理解卦象的关键（一）——卦位关系 主要内容： 上下卦（内外卦）的概念及其相互作用。 “承”、“乘”、“比”、“应”的爻位关系。 通过这些关系理解卦爻辞为何有吉凶悔吝的判断。
▶
第6课：解剖一个卦——卦的构成与读法 主要内容： 认识卦的各个部分：卦画、卦名、卦辞、爻辞。 “爻”的位置与称呼：初、二、三、四、五、上；九（阳爻）、六（阴爻）。 实战：以“乾卦”或“坤卦”为例，学习如何正确地读出每一爻。
▶
4：八卦的丰富意涵——八卦进阶 主要内容： 八卦的延伸象征（动物、方位、季节等）。 先天八卦（伏羲八卦）与后天八卦（文王八卦）的方位图及其意义。 练习画八卦，并尝试用八卦的基本象征进行简单联想。
▶
5、从八卦到六十四卦 主要内容： 什么是“重卦”？八卦两两相重，构成六十四卦。 六十四卦的结构：每个卦有卦画、卦名、卦辞、爻辞。 《易经》上经与下经的划分及其大致主题。
▶
1、一个脑还是两个脑？ （罗杰·斯佩里与加扎尼加的“割裂脑”研究） 主要内容：通过对切断连接左右脑的胼胝体的癫痫患者进行研究，发现大脑两半球具有功能不对称性。左半球长于语言、逻辑，右半球长于空间、知觉。这项研究证明了大脑两半球可以拥有独立的意识。
▶
discrete math 16 tree 16.2 spanning tree
▶
discrete math 16 Tree 16.1 What Is a Tree?
▶
第5课：从八卦到六十四卦 主要内容： 什么是“重卦”？八卦两两相重，构成六十四卦。 六十四卦的结构：每个卦有卦画、卦名、卦辞、爻辞。 《易经》上经与下经的划分及其大致主题。
![我们一步步把 TRON 的转账过程和底层原理讲清楚，理解之后你就会知道为什么最初版本需要 3 个接口，以及它们在协议层各自负责什么。
---
一、TRON 转账的逻辑分层
TRON 网络底层是一个基于 账户模型 (Account Model) 的区块链，每个账户有：
一个 Base58 地址（由 secp256k1 公钥推导）；
对应的余额（以 SUN 为单位，1 TRX = 1,000,000 SUN）；
一对公私钥（椭圆曲线 secp256k1）。
一次转账要完成以下三个阶段：
阶段 对应接口 作用 责任
① 创建交易 /wallet/createtransaction 生成未签名交易 (raw_data)，确定交易结构 节点构造出原始交易模板
② 签名交易 /wallet/gettransactionsign 或本地签名 使用私钥对 raw_data 的哈希签名，生成 signature 私钥持有方（你）
③ 广播交易 /wallet/broadcasttransaction 把已签名交易发到网络 节点接收并传播交易
---
二、每个阶段的详细机制
① 创建交易 (createtransaction)
请求参数包括：
{
"to_address": "...",
"owner_address": "...",
"amount": 1000000,
"visible": true
}
节点会根据这些字段构造出交易的 raw_data 和 raw_data_hex，内容包括：
{
"contract": [{
"parameter": {
"value": {
"amount": 1000000,
"owner_address": "41....",
"to_address": "41...."
}
},
"type": "TransferContract"
}],
"ref_block_bytes": "XXXX",
"ref_block_hash": "XXXX",
"expiration": 1730000000000,
"timestamp": 1730000000123
}
注意这里的 "ref_block_bytes" 和 "ref_block_hash" 是防重放字段，用来指向当前区块高度附近的块，防止旧交易重复广播。
生成的返回体含有：
{
"visible": true,
"txID": "xxxxx",
"raw_data": {...},
"raw_data_hex": "..."
}
但这里的 txID 是暂时的（节点计算出来的），核心在于 raw_data_hex，它是交易内容的十六进制序列化。
---
② 签名交易 (gettransactionsign 或本地签名)
在 TRON 中，签名算法是 ECDSA(secp256k1)，签名目标是：
txID = SHA256(raw_data)
signature = ECDSA_sign(txID, privateKey)
signature 是由 r || s || v 组成的 65 字节，通常转为 hex 放到 signature 数组：
"signature": ["abcdef1234..."]
官方 API /wallet/gettransactionsign 本质上帮你调用了节点端的 secp256k1 签名逻辑。
缺点：需要把私钥明文发到远程节点（严重不安全）。
因此生产环境应改为 本地签名，也就是我们刚写的版本。
---
③ 广播交易 (broadcasttransaction)
把签名过的交易广播给 TRON 网络。
节点验证签名：
用公钥从 signature 中恢复出公钥；
验证 ECDSA_verify(SHA256(raw_data), signature, pubKey)；
如果通过，则将交易加入到交易池；
之后矿工（出块节点）会在新区块中打包执行。
成功响应一般是：
{
"result": true,
"txid": "xxxx"
}
---
三、为什么需要 3 个接口？
在区块链底层的设计里，每个环节都有明确的职责：
接口 职责 为什么要分离
/wallet/createtransaction 生成标准交易结构 确保交易格式和字段正确，由节点负责构造合法模板
/wallet/gettransactionsign 签名（可替换为本地签名） 签名必须由私钥持有方完成；为了兼容钱包或 SDK
/wallet/broadcasttransaction 网络传播 节点验证签名并广播，不修改交易内容
→ 这样分层有几个优势：
1. 安全性：签名阶段可以完全隔离（你可以在离线设备本地签名）。
2. 一致性：交易格式由官方节点生成，减少结构错误。
3. 模块化：SDK/钱包可灵活替换签名方式（离线、硬件钱包、热钱包）。
---
四、底层验证过程（共识节点视角）
当交易被广播到节点：
1. 节点解析交易；
2. 计算 SHA256(raw_data)；
3. 用 signature 恢复公钥并推导出 owner_address；
4. 检查签名对应的地址是否与交易中的 owner_address 匹配；
5. 验证余额、资源（带宽、能量）是否足够；
6. 如果合法，加入交易池，等待打包。
区块打包后执行虚拟机合约或余额转移，写入状态树中。
---
五、总结流程图
你(客户端)
│
│ POST /wallet/createtransaction
▼
获得 raw_data
│
│ 本地 ECDSA(secp256k1) 签名
▼
组装 signature
│
│ POST /wallet/broadcasttransaction
▼
节点验证签名并广播 -> 共识 -> 打包上链
所以：
3 个接口并非多余，而是体现了 交易生命周期的 3 个核心阶段；
实际生产环境中，第 2 步（签名）推荐本地执行，只用第 1 和第 3 个接口。](https://manimvideo.explanation.fun/video/cover/577152495361814529.png)
▶
我们一步步把 TRON 的转账过程和底层原理讲清楚，理解之后你就会知道为什么最初版本需要 3 个接口，以及它们在协议层各自负责什么。 --- 一、TRON 转账的逻辑分层 TRON 网络底层是一个基于 账户模型 (Account Model) 的区块链，每个账户有： 一个 Base58 地址（由 secp256k1 公钥推导）； 对应的余额（以 SUN 为单位，1 TRX = 1,000,000 SUN）； 一对公私钥（椭圆曲线 secp256k1）。 一次转账要完成以下三个阶段： 阶段 对应接口 作用 责任 ① 创建交易 /wallet/createtransaction 生成未签名交易 (raw_data)，确定交易结构 节点构造出原始交易模板 ② 签名交易 /wallet/gettransactionsign 或本地签名 使用私钥对 raw_data 的哈希签名，生成 signature 私钥持有方（你） ③ 广播交易 /wallet/broadcasttransaction 把已签名交易发到网络 节点接收并传播交易 --- 二、每个阶段的详细机制 ① 创建交易 (createtransaction) 请求参数包括： { "to_address": "...", "owner_address": "...", "amount": 1000000, "visible": true } 节点会根据这些字段构造出交易的 raw_data 和 raw_data_hex，内容包括： { "contract": [{ "parameter": { "value": { "amount": 1000000, "owner_address": "41....", "to_address": "41...." } }, "type": "TransferContract" }], "ref_block_bytes": "XXXX", "ref_block_hash": "XXXX", "expiration": 1730000000000, "timestamp": 1730000000123 } 注意这里的 "ref_block_bytes" 和 "ref_block_hash" 是防重放字段，用来指向当前区块高度附近的块，防止旧交易重复广播。 生成的返回体含有： { "visible": true, "txID": "xxxxx", "raw_data": {...}, "raw_data_hex": "..." } 但这里的 txID 是暂时的（节点计算出来的），核心在于 raw_data_hex，它是交易内容的十六进制序列化。 --- ② 签名交易 (gettransactionsign 或本地签名) 在 TRON 中，签名算法是 ECDSA(secp256k1)，签名目标是： txID = SHA256(raw_data) signature = ECDSA_sign(txID, privateKey) signature 是由 r || s || v 组成的 65 字节，通常转为 hex 放到 signature 数组： "signature": ["abcdef1234..."] 官方 API /wallet/gettransactionsign 本质上帮你调用了节点端的 secp256k1 签名逻辑。 缺点：需要把私钥明文发到远程节点（严重不安全）。 因此生产环境应改为 本地签名，也就是我们刚写的版本。 --- ③ 广播交易 (broadcasttransaction) 把签名过的交易广播给 TRON 网络。 节点验证签名： 用公钥从 signature 中恢复出公钥； 验证 ECDSA_verify(SHA256(raw_data), signature, pubKey)； 如果通过，则将交易加入到交易池； 之后矿工（出块节点）会在新区块中打包执行。 成功响应一般是： { "result": true, "txid": "xxxx" } --- 三、为什么需要 3 个接口？ 在区块链底层的设计里，每个环节都有明确的职责： 接口 职责 为什么要分离 /wallet/createtransaction 生成标准交易结构 确保交易格式和字段正确，由节点负责构造合法模板 /wallet/gettransactionsign 签名（可替换为本地签名） 签名必须由私钥持有方完成；为了兼容钱包或 SDK /wallet/broadcasttransaction 网络传播 节点验证签名并广播，不修改交易内容 → 这样分层有几个优势： 1. 安全性：签名阶段可以完全隔离（你可以在离线设备本地签名）。 2. 一致性：交易格式由官方节点生成，减少结构错误。 3. 模块化：SDK/钱包可灵活替换签名方式（离线、硬件钱包、热钱包）。 --- 四、底层验证过程（共识节点视角） 当交易被广播到节点： 1. 节点解析交易； 2. 计算 SHA256(raw_data)； 3. 用 signature 恢复公钥并推导出 owner_address； 4. 检查签名对应的地址是否与交易中的 owner_address 匹配； 5. 验证余额、资源（带宽、能量）是否足够； 6. 如果合法，加入交易池，等待打包。 区块打包后执行虚拟机合约或余额转移，写入状态树中。 --- 五、总结流程图 你(客户端) │ │ POST /wallet/createtransaction ▼ 获得 raw_data │ │ 本地 ECDSA(secp256k1) 签名 ▼ 组装 signature │ │ POST /wallet/broadcasttransaction ▼ 节点验证签名并广播 -> 共识 -> 打包上链 所以： 3 个接口并非多余，而是体现了 交易生命周期的 3 个核心阶段； 实际生产环境中，第 2 步（签名）推荐本地执行，只用第 1 和第 3 个接口。
▶
第5课：从八卦到六十四卦——重卦与卦序 主要内容： 什么是“重卦”？八卦两两相重，构成六十四卦。 六十四卦的结构：每个卦有卦画、卦名、卦辞、爻辞。 《易经》上经与下经的划分及其大致主题。
▶