TRON Whitepaper v2.1

TRON DAO

Whitepaper TRON

Sách trắng TRON (Whitepaper TRON) (v2.1) cung cấp nền tảng kỹ thuật cho một trong những hệ điều hành phi tập trung lớn nhất thế giới. Tài liệu này trình bày chi tiết kiến trúc 3 lớp, cơ chế đồng thuận DPoS và TVM — động cơ hỗ trợ thông lượng cao cho các giao dịch toàn cầu.

TRON: Nền tảng Blockchain Phi tập trung Tiên tiến

Phiên bản Whitepaper: 2.1
Phiên bản Giao thức TRON: 4.8.0

1 Giới thiệu

1.1 Tầm nhìn

TRON là một dự án đầy tham vọng dành riêng cho việc thiết lập một mạng Internet thực sự phi tập trung cùng cơ sở hạ tầng của nó. Giao thức TRON, một trong những hệ điều hành dựa trên blockchain lớn nhất thế giới, cung cấp hỗ trợ blockchain công khai với thông lượng cao, khả năng mở rộng cao và tính sẵn sàng cao cho tất cả các Ứng dụng phi tập trung (dApp) trong hệ sinh thái TRON. Kể từ khi thành lập, TRON đã liên tục mở rộng khả năng của mình, đạt được sự chấp nhận đáng kể trong các lĩnh vực như chuyển nhượng stablecoin và nuôi dưỡng một cộng đồng thịnh vượng, củng cố vị thế nổi bật trong ngành công nghiệp blockchain.

1.2 Bối cảnh

Sự ra đời của Bitcoin vào năm 2009 đã cách mạng hóa nhận thức của xã hội về hệ thống tài chính truyền thống sau cuộc Đại suy thoái (2007-2008). Khi các quỹ phòng hộ (hedge funds) và ngân hàng tập trung sụp đổ do đầu cơ vào các công cụ tài chính phái sinh mờ ám, công nghệ blockchain đã cung cấp một sổ cái phổ quát minh bạch mà bất kỳ ai cũng có thể thu thập thông tin giao dịch. Các giao dịch được bảo mật bằng mật mã bằng cách sử dụng cơ chế đồng thuận Proof of Work (PoW), qua đó ngăn chặn các vấn đề chi tiêu kép (double-spending).

Vào cuối năm 2013, sách trắng Ethereum đã đề xuất một mạng lưới trong đó các Hợp đồng thông minh và Máy ảo Ethereum (EVM) Turing hoàn chỉnh sẽ cho phép các nhà phát triển tương tác với mạng lưới thông qua dApp. Tuy nhiên, khi khối lượng giao dịch trong Bitcoin và Ethereum đạt đỉnh vào năm 2017, điều hiển nhiên từ thông lượng giao dịch thấp và Phí giao dịch cao là các loại tiền mã hóa như Bitcoin và Ethereum ở trạng thái hiện tại không thể mở rộng để áp dụng rộng rãi. Do đó, TRON được thành lập và được hình dung như một giải pháp sáng tạo cho những thách thức về khả năng mở rộng cấp bách này.

1.3 Lịch sử

1.3.1 Nguồn gốc của một Internet Phi tập trung (2017)

Hành trình của TRON bắt đầu vào tháng 7 năm 2017 với việc thành lập tại Singapore, được thúc đẩy bởi một tầm nhìn cốt lõi: tạo ra một internet thực sự phi tập trung. Đề án tham vọng này nhanh chóng được hỗ trợ bởi Đợt phát hành tiền xu ban đầu (ICO) thành công vào tháng 8 năm 2017, đảm bảo nguồn vốn phát triển quan trọng. Cam kết ban đầu về tính minh bạch và sự hợp tác cởi mở đã được thể hiện bằng việc ra mắt giao thức nguồn mở vào tháng 12 năm 2017, mời gọi sự tham gia của cộng đồng ngay từ khi thành lập.

1.3.2 Phát triển Lõi (2018)

Sự tiến bộ công nghệ nhanh chóng đã diễn ra vào năm 2018. Việc ra mắt Testnet Shasta vào tháng 3 đã mở đường cho đợt Ra mắt Mainnet mang tính bước ngoặt, Odyssey 2.0, vào tháng 5, thiết lập TRON như một blockchain Layer-1 độc lập, hiệu suất cao, có khả năng hỗ trợ một thế hệ dApp mới. Ưu tiên hiệu quả mạng và quản trị phi tập trung, TRON đã triển khai cơ chế đồng thuận Delegated Proof-of-Stake (DPoS) và bầu chọn các Super Representative (SR) vào tháng 6 năm 2018. Năm nền tảng này cũng chứng kiến sự mở rộng chiến lược bằng việc mua lại BitTorrent vào tháng 7, khuếch đại đáng kể phạm vi tiếp cận và tiềm năng của TRON trong việc phân phối nội dung phi tập trung. Nửa cuối năm chứng kiến việc ra mắt Máy ảo TRON (TVM) tương thích với Ethereum vào tháng 10, một chất xúc tác quan trọng để thu hút các nhà phát triển và thúc đẩy sự phát triển của hệ sinh thái. Hỗ trợ sự phát triển này, bản nâng cấp Odyssey-v3.2 vào tháng 11 đã giới thiệu tính năng ủy quyền tài nguyên, tối ưu hóa tiện ích mạng. Đến tháng 12 năm 2018, hệ sinh thái đang bùng nổ của TRON đã thu hút hơn 1 triệu tài khoản người dùng. Việc giới thiệu các tiêu chuẩn token TRC-10 và TRC-20 trong suốt năm 2018 đã cung cấp cơ sở hạ tầng cơ bản cho việc token hóa tài sản và đổi mới dApp trên nền tảng.

1.3.3 Mở rộng Chức năng và Áp dụng (2019 - 2021)

TRON tiếp tục sự phát triển của mình với các nâng cấp giao thức quan trọng vào năm 2019, bao gồm Odyssey-v3.5 vào tháng 3, tăng cường bảo mật và tính linh hoạt của tài khoản, và Odyssey-v3.6.5 vào tháng 10, tối ưu hóa cơ chế Khóa TRX và quản trị. Giai đoạn này cũng đánh dấu sự vươn lên mạnh mẽ của TRON như một mạng lưới hàng đầu cho các khoản chuyển tiền stablecoin, với sự áp dụng rộng rãi của TRC-20 USDT bắt đầu từ năm 2019, tận dụng tốc độ và Phí mạng thấp của nó. Tiện ích này đã trở thành động lực chính thúc đẩy sự tăng trưởng người dùng. Đến tháng 9 năm 2020, nền tảng này đã tích hợp hơn 10 triệu tài khoản. Vị thế ngày càng nổi bật của TRON trong hệ sinh thái stablecoin được nhấn mạnh thêm bằng sự gia tăng nhanh chóng của lượng phát hành TRC-20 USDT, vượt mức 10 tỷ vào đầu năm 2021 và đạt hơn 30 tỷ vào tháng 5 năm 2021.

1.3.4 Tăng trưởng Bền vững và Sự thống trị của Hệ sinh thái (2022 - Hiện tại)

Giai đoạn này thể hiện sự tăng trưởng mạnh mẽ liên tục trong cả việc áp dụng của người dùng và sự thống trị của stablecoin. Cơ sở người dùng của TRON đã trải qua sự gia tăng đáng kể, mở rộng quy mô lên hơn 100 triệu tài khoản vào tháng 6 năm 2022 và vượt qua 300 triệu vào tháng 4 năm 2025. Đồng thời, lượng phát hành TRC-20 USDT tiếp tục quỹ đạo đi lên, đạt hơn 70 tỷ vào tháng 4 năm 2025, củng cố vị thế của TRON như một cơ sở hạ tầng quan trọng trong bối cảnh stablecoin toàn cầu. Sự mở rộng này được bổ sung bằng cam kết liên tục của TRON trong việc tăng cường tính ổn định, khả năng mở rộng, hiệu suất của nền tảng cốt lõi và điều chỉnh mô hình kinh tế để đáp ứng các động lực của thị trường.

Những tiến bộ quan trọng của giao thức trong giai đoạn này bao gồm một loạt các bản nâng cấp lớn bắt buộc. Bản phát hành GreatVoyage-v4.7.0.1 (Aristotle) đã giới thiệu cơ chế Stake 2.0 và mô hình Năng lượng động cho TVM, tăng cường quản lý tài nguyên và hiệu quả thực thi. Bản phát hành GreatVoyage-v4.7.2 (Periander) sau đó đã nâng cấp mô-đun mạng lưới của TRON lên Libp2p v1.2.0, cải thiện giao tiếp P2P và đồng bộ hóa khối. Nó cũng giới thiệu các bản cập nhật quan trọng cho Stake 2.0 và Chỉ thị PUSH0 EIP-3855 trong TVM. Bản phát hành GreatVoyage-v4.8.0 (Kant) tiếp tục nâng cao Máy ảo TRON (TVM) bằng cách thích ứng với những cải tiến chính từ các bản nâng cấp gần đây của Ethereum, nhằm cải thiện hiệu quả Hợp đồng thông minh và giảm Phí giao dịch, duy trì khả năng cạnh tranh của TRON như một blockchain tương thích với EVM.

1.3.5 Nhìn về Tương lai

Dựa trên cơ sở hạ tầng đã được thiết lập, TRON vẫn cam kết tăng cường khả năng tương tác, thúc đẩy sự áp dụng rộng rãi hơn và củng cố vị thế của mình như một blockchain hàng đầu với một hệ sinh thái phát triển mạnh mẽ và hiệu quả vượt trội trong việc chuyển stablecoin trong bối cảnh các công nghệ phi tập trung đang phát triển.

1.4 Thuật ngữ

Để xem định nghĩa của các thuật ngữ chính và từ viết tắt được sử dụng trong tài liệu này, hãy tham khảo Phụ lục A: Thuật ngữ.

Hình 1: *Dòng thời gian Phát triển TRON & Cột mốc (2017-Hiện tại)*

2 Kiến trúc

TRON áp dụng kiến trúc 3 lớp bao gồm Lớp Cốt lõi (Core Layer), Lớp Lưu trữ (Storage Layer) và Lớp Ứng dụng (Application Layer). Giao thức TRON tuân thủ Protocol Buffers (Protobuf) của Google, vốn hỗ trợ mở rộng đa ngôn ngữ.

2.1 Lớp Cốt lõi (Core Layer)

Lớp Cốt lõi bao gồm một số mô-đun chính chịu trách nhiệm cho các chức năng bao gồm Hợp đồng thông minh, quản lý tài khoản và sự đồng thuận. TRON triển khai một máy ảo dựa trên ngăn xếp (stack-based virtual machine), Máy ảo TRON (TVM), sử dụng một bộ lệnh được tối ưu hóa. Để hỗ trợ tốt hơn cho các nhà phát triển dApp, Solidity đã được chọn làm ngôn ngữ Hợp đồng thông minh, tiếp theo là hỗ trợ các ngôn ngữ tiên tiến khác trong tương lai. Ngoài ra, cơ chế đồng thuận của TRON dựa trên Delegated Proof of Stake (DPoS), kết hợp nhiều đổi mới để đáp ứng các yêu cầu riêng biệt của nó.

2.2 Lớp Lưu trữ (Storage Layer)

Giao thức lưu trữ phân tán độc đáo của TRON bao gồm Lưu trữ Khối (Block Storage) và Lưu trữ Trạng thái (State Storage). Khái niệm cơ sở dữ liệu đồ thị (graph database) đã được đưa vào thiết kế của Lớp Lưu trữ để đáp ứng tốt hơn nhu cầu lưu trữ dữ liệu đa dạng trong thế giới thực.

2.2.1 Lưu trữ Blockchain

Lưu trữ blockchain TRON sử dụng LevelDB, được phát triển bởi Google và đã được chứng minh là thành công với nhiều công ty và dự án. Nó có hiệu suất cao và hỗ trợ các mảng byte tùy ý làm cả khóa (key) và giá trị (value), các thao tác trên từng khóa riêng lẻ (get, put, delete), các thao tác hàng loạt (put, delete), các trình vòng lặp hai chiều (bidirectional iterators) và nén đơn giản bằng thuật toán Snappy tốc độ cao.

2.2.2 Lưu trữ Trạng thái

TRON có một KhaosDB trong bộ nhớ Node đầy đủ (full-node) có thể lưu trữ tất cả các chuỗi phân nhánh (forked chains) mới được tạo trong một khoảng thời gian nhất định. Điều này cho phép các SR chuyển đổi nhanh chóng từ chuỗi hoạt động của riêng họ sang một chuỗi chính (main chain) mới. Nó cũng bảo vệ việc lưu trữ blockchain bằng cách làm cho nó ổn định hơn khỏi bị chấm dứt bất thường ở trạng thái trung gian.

2.3 Lớp Ứng dụng (Application Layer)

Các nhà phát triển có thể tạo ra nhiều dApp đa dạng và các Ví tùy chỉnh trên TRON. Vì TRON cho phép các Hợp đồng thông minh được triển khai và thực thi, nó hỗ trợ một phổ rộng các trường hợp sử dụng tiềm năng.

2.4 Giao thức

Giao thức TRON tuân thủ Google Protocol Buffers, đây là một cách thức trung lập với ngôn ngữ, trung lập với nền tảng và có thể mở rộng để tuần tự hóa (serializing) dữ liệu có cấu trúc cho mục đích sử dụng trong các giao thức truyền thông, lưu trữ dữ liệu và hơn thế nữa.

2.4.1 Protocol Buffers

Protocol Buffers (Protobuf) là một cơ chế linh hoạt, hiệu quả, tự động để tuần tự hóa dữ liệu có cấu trúc, tương tự như JSON hoặc XML, nhưng nhỏ gọn hơn, nhanh hơn và đơn giản hơn đáng kể.

Định nghĩa Protobuf (.proto) có thể được sử dụng để tạo mã cho các ngôn ngữ C++, Java, C#, Python, Ruby, Golang và Objective-C thông qua các trình tạo mã chính thức. Nhiều triển khai của bên thứ ba cũng có sẵn cho nhiều ngôn ngữ khác. Protobuf đơn giản hóa việc phát triển máy khách bằng cách thống nhất các định nghĩa API và cũng tối ưu hóa việc truyền dữ liệu. Khách hàng có thể sử dụng API.proto từ kho lưu trữ giao thức của TRON và tích hợp thông qua các thư viện mã được tạo tự động.

Theo so sánh, Protocol Buffers nhỏ hơn 3 đến 10 lần và nhanh hơn 20 đến 100 lần so với XML, với cú pháp ít mơ hồ hơn. Protobuf tạo ra các lớp truy cập dữ liệu (data access classes) dễ sử dụng hơn về mặt lập trình.

2.4.2 HTTP

Giao thức TRON cung cấp một API HTTP RESTful thay thế cho API Protobuf. Chúng dùng chung một giao diện nhưng API HTTP có thể được sử dụng dễ dàng trong các máy khách JavaScript.

2.5 Máy ảo TRON (TVM)

TVM là một máy ảo Turing hoàn chỉnh, nhẹ, được phát triển cho hệ sinh thái của TRON. TVM kết nối liền mạch với hệ sinh thái phát triển hiện có để cung cấp cho hàng triệu nhà phát triển toàn cầu một hệ thống blockchain được tùy chỉnh, hiệu quả, thuận tiện, ổn định, bảo mật và có thể mở rộng.

3 Đồng thuận

3.1 Delegated Proof of Stake (DPoS)

Cơ chế đồng thuận sớm nhất là cơ chế đồng thuận Proof of Work (PoW). Giao thức này hiện được triển khai trong Bitcoin và Ethereum. Trong các hệ thống PoW, các giao dịch được phát tán trên mạng lưới được nhóm lại thành các khối mới sinh để các thợ đào (miner) xác nhận. Quá trình xác nhận này liên quan đến việc băm (hashing) các giao dịch bằng cách sử dụng các thuật toán băm mật mã cho đến khi đạt được một thư mục gốc merkle (merkle root), tạo ra một cây merkle (merkle tree):

8 giao dịch TRX được băm vào merkle root — Hình 3: 8 giao dịch TRX được băm vào thư mục gốc merkle. Gốc merkle này sau đó được bao gồm trong tiêu đề khối (block header), được đính kèm vào các khối đã được xác nhận trước đó để tạo thành một blockchain. Điều này cho phép theo dõi dễ dàng và minh bạch các giao dịch, dấu thời gian (timestamps) và các thông tin liên quan khác.

Các thuật toán băm mật mã rất hữu ích trong việc ngăn chặn tấn công mạng vì chúng sở hữu một số thuộc tính:

Kích thước chiều dài Đầu vào/Đầu ra: Thuật toán có thể truyền vào một đầu vào có độ dài bất kỳ và đầu ra là một giá trị băm (hash) có độ dài cố định.
Hiệu quả: Thuật toán tương đối dễ dàng và tính toán nhanh chóng.
Kháng tiền ảnh (Preimage resistance): Đối với một đầu ra $z$ cho trước, không thể tìm thấy bất kỳ đầu vào $x$ nào sao cho $h(x) = z$ . Nói cách khác, thuật toán băm $h(x)$ là hàm một chiều trong đó chỉ có thể tìm thấy đầu ra khi cho một đầu vào. Điều ngược lại là không thể.
Kháng va chạm (Collision resistance): Về mặt tính toán là không khả thi để tìm bất kỳ cặp $x_1 \neq x_2$ nào sao cho $h(x_1) = h(x_2)$ . Nói cách khác, xác suất tìm thấy hai đầu vào khác nhau băm ra cùng một đầu ra là cực kỳ thấp. Thuộc tính này cũng ngụ ý khả năng kháng tiền ảnh thứ hai.
Kháng tiền ảnh thứ hai: Cho trước $x_1$ , và do đó là $h(x_1)$ , về mặt tính toán là không khả thi để tìm thấy bất kỳ $x_2$ nào sao cho $h(x_1) = h(x_2)$ . Mặc dù thuộc tính này tương tự như kháng va chạm, nhưng sự khác biệt là nó nói rằng một kẻ tấn công với $x_1$ cho trước sẽ thấy không khả thi về mặt tính toán để tìm bất kỳ $x_2$ nào băm ra cùng một đầu ra.
Tính xác định (Deterministic): ánh xạ mỗi đầu vào đến một và chỉ một đầu ra.
Hiệu ứng tuyết lở (Avalanche effect): một thay đổi nhỏ ở đầu vào dẫn đến một đầu ra hoàn toàn khác biệt.

Những thuộc tính này mang lại cho mạng lưới tiền mã hóa giá trị nội tại của nó bằng cách đảm bảo các cuộc tấn công không làm tổn hại đến mạng lưới. Khi thợ đào xác nhận một khối, họ được thưởng token như một động lực tích hợp sẵn để tham gia mạng lưới. Tuy nhiên, khi giá trị vốn hóa thị trường tiền mã hóa toàn cầu liên tục tăng, các thợ đào trở nên tập trung và tập trung tài nguyên tính toán của họ vào việc tích trữ token làm tài sản, thay vì cho mục đích tham gia mạng lưới. Các thợ đào CPU nhường chỗ cho GPU, và GPU nhường chỗ cho ASIC mạnh mẽ.

Để giải quyết vấn đề lãng phí năng lượng, cơ chế đồng thuận Proof of Stake (PoS) đã được đề xuất bởi nhiều mạng lưới mới. Trong các mạng PoS, những người nắm giữ token khóa số dư token của họ để trở thành các trình xác thực khối (block validators). Các trình xác thực thay phiên nhau đề xuất và biểu quyết về khối tiếp theo. Tuy nhiên, vấn đề với PoS tiêu chuẩn là tầm ảnh hưởng của trình xác thực tương quan trực tiếp với số lượng token bị khóa. Điều này dẫn đến việc các bên tích trữ số lượng lớn tiền tệ cơ sở của mạng lưới sẽ nắm giữ ảnh hưởng quá lớn trong hệ sinh thái của mạng.

Cơ chế đồng thuận của TRON sử dụng hệ thống Delegated Proof of Stake sáng tạo, trong đó 27 SR tạo khối cho mạng lưới. Cứ sau 6 giờ, những người sở hữu tài khoản TRX có Đóng băng (Freeze) tài khoản của họ có thể bầu chọn cho một nhóm các ứng cử viên SR, với 27 ứng cử viên hàng đầu được coi là SR. Cử tri có thể chọn SR dựa trên các tiêu chí như các dự án được SR tài trợ để tăng cường việc sử dụng TRX và phần thưởng được phân phối cho cử tri. Điều này cho phép một hệ sinh thái dân chủ hóa và phi tập trung hơn. Tài khoản của SR là tài khoản bình thường, nhưng sự tích lũy phiếu bầu cho phép họ tạo khối. Với tốc độ thông lượng thấp của Bitcoin và Ethereum do cơ chế đồng thuận PoW và các vấn đề về khả năng mở rộng, hệ thống DPoS của TRON cung cấp một cơ chế sáng tạo dẫn đến 2000 Giao dịch Mỗi Giây (TPS) so với 3 TPS của Bitcoin và 15 TPS của Ethereum.

Mạng lưới giao thức TRON tạo ra một khối mỗi ba giây, với mỗi khối trao thưởng 16 TRX cho SR. Tổng cộng 168.192.000 TRX sẽ được trao thưởng hàng năm cho 27 SR. Mỗi khi một SR hoàn thành việc tạo khối, phần thưởng được gửi đến một tài khoản phụ trong siêu sổ cái (super-ledger). SR có thể kiểm tra, nhưng không thể sử dụng trực tiếp các token TRX này. Mỗi SR có thể thực hiện rút tiền một lần mỗi 24 giờ, chuyển phần thưởng từ tài khoản phụ sang tài khoản SR được chỉ định.

Ba loại Node (Nút) trên mạng lưới TRON là Witness Node, Full Node và Lite Full Node. Các Witness node được thiết lập bởi SR và chịu trách nhiệm chính về việc tạo khối cũng như tạo/bầu chọn đề xuất. Các Full node cung cấp API và phát tán các giao dịch và khối. Các Solidity node đồng bộ khối từ các Full Node khác và cũng cung cấp các API có thể lập chỉ mục (indexable APIs).

4 Tài khoản

4.1 Phân loại

Mạng lưới TRON có hai loại tài khoản chính:

Tài khoản sở hữu bên ngoài (Externally Owned Accounts - EOAs): Các tài khoản này được kiểm soát bởi một private key (khóa riêng tư). Chúng được sử dụng để gửi TRX và token, biểu quyết cho Super Representative và triển khai Hợp đồng thông minh. Tài khoản EOA có thể nắm giữ số dư TRX, token TRC-10 và token TRC-20/TRC-721 (thông qua tương tác với tài khoản hợp đồng). Đây là loại tài khoản phổ biến nhất, được sử dụng bởi tất cả người dùng Ví.
Tài khoản Hợp đồng (Contract Accounts): Đây là các tài khoản Hợp đồng thông minh được kiểm soát bởi logic mã của chúng. Một tài khoản hợp đồng không có khóa riêng tư và được kích hoạt khi tạo. Các chức năng của nó có thể được gọi bởi bất kỳ EOA hoặc hợp đồng nào khác, theo sự cho phép của mã.

4.2 Khởi tạo

Có ba cách để tạo tài khoản TRON:

Tạo tài khoản ngoại tuyến (offline) bằng Ví dòng lệnh wallet-cli;
Tạo tài khoản ngoại tuyến bằng SDK, chẳng hạn như Trident SDK;
Tạo một khóa riêng tư (private key) và địa chỉ (address) tương ứng thông qua một ứng dụng Ví.

Tài khoản có thể được kích hoạt bằng hai cách sau:

Gửi bất kỳ lượng TRX hoặc token TRC-10 nào từ một tài khoản hiện có sang tài khoản mới;
Gọi API wallet/createaccount của Java-tron để tạo giao dịch từ tài khoản hiện có, sau đó ký giao dịch và phát tán nó lên mạng lưới TRON.

Một cặp khóa (key pair) ngoại tuyến bao gồm một địa chỉ (khóa công khai - public key) và một khóa riêng tư, không được ghi lại bởi mạng TRON, cũng có thể được tạo ra. Thuật toán tạo địa chỉ người dùng bao gồm việc tạo một cặp khóa và sau đó trích xuất khóa công khai (mảng byte 64-byte đại diện cho tọa độ x, y). Băm khóa công khai bằng hàm SHA3-256 (giao thức SHA3 được áp dụng là KECCAK-256) và trích xuất 20 byte cuối cùng của kết quả. Thêm 41 vào đầu mảng byte và đảm bảo độ dài địa chỉ ban đầu là 21 byte. Băm địa chỉ hai lần bằng hàm SHA3-256 và lấy 4 byte đầu tiên làm mã xác minh. Thêm mã xác minh vào cuối địa chỉ ban đầu và thu được địa chỉ ở định dạng base58check thông qua mã hóa base58. Một địa chỉ Mainnet được mã hóa bắt đầu bằng chữ T và có độ dài 34 byte.

4.3 Cấu trúc

Ba loại tài khoản khác nhau là Normal, AssetIssue và Contract. Một Tài khoản chứa 7 tham số:

account_name: Tên của tài khoản - ví dụ: BillsAccount;
type: Loại tài khoản - ví dụ: 0 (đại diện cho loại ‘Normal’);
address: Định danh duy nhất cho tài khoản trên mạng lưới TRON - ví dụ: T9yD… 9mGg;
balance: Số dư TRX của tài khoản - ví dụ: 4213312;
vote: Số phiếu bầu mà tài khoản nhận được - ví dụ: {("0x1b7w. . . 9xj3",323), ("0x8djq. . . j12m",88), . . . ,("0x82nd. . . mx6i",10001)};
asset: Các tài sản khác, bên cạnh TRX, được giữ trong tài khoản - ví dụ: {<"WishToken", 66666>, <"Dogie", 233>}.
latest_operation_time: Dấu thời gian (timestamp) của thao tác gần đây nhất của tài khoản.

Cấu trúc dữ liệu Protobuf:

message Account {
  message Vote {
    bytes vote_address = 1;
    int64 vote_count = 2;
  }
  bytes accout_name = 1;
  AccountType type = 2;
  bytes address = 3;
  int64 balance = 4;
  repeated Vote votes = 5;
  map<string, int64> asset = 6;
  int64 latest_operation_time = 10;
}

enum AccountType {
  Normal = 0;
  AssetIssue = 1;
  Contract = 2;
}

5 Khối (Block)

Một khối thường chứa tiêu đề khối (block header) và một vài giao dịch. Cấu trúc dữ liệu Protobuf:

message Block {
  BlockHeader block_header = 1;
  repeated Transaction transactions = 2;
}

5.1 Tiêu đề khối (Block Header)

Tiêu đề khối chứa dữ liệu thô (raw data), chữ ký witness (witness signature) và blockID. Cấu trúc dữ liệu Protobuf:

message BlockHeader {
  message raw {
    int64 timestamp = 1;
    bytes txTrieRoot = 2;
    bytes parentHash = 3;
    int64 number = 7;
    int64 witness_id = 8;
    bytes witness_address = 9;
    int32 version = 10;
    bytes accountStateRoot = 11;
  }
  raw raw_data = 1;
  bytes witness_signature = 2;
}

5.1.1 Dữ liệu thô (Raw Data)

Dữ liệu thô được ký hiệu là raw_data trong Protobuf. Nó chứa dữ liệu thô của một tin nhắn, gồm 8 tham số:

timestamp: dấu thời gian của tin nhắn này - ví dụ: 1543884429000.
txTrieRoot: gốc cây Merkle - ví dụ: 7dacsa… 3ed.
parentHash: mã băm (hash) của khối trước đó - ví dụ: 7dacsa… 3ed.
number: chiều cao khối (block height) - ví dụ: 4638708.
version: được bảo lưu - ví dụ: 5.
witness_address: địa chỉ của witness đã đóng gói (pack) khối này - ví dụ: 41928c…4d21.
witness_id: ID của witness đã đóng gói khối này - ví dụ: ” 0xu82h… 7237 ”.
accountStateRoot: địa chỉ của witness đã đóng gói khối này - ví dụ: ” 0xu82h… 7237 “.

5.1.2 Chữ ký Witness

Chữ ký witness được ký hiệu là witness_signature trong Protobuf, đây là chữ ký cho tiêu đề khối này từ Witness node.

5.1.3 ID Khối

ID khối được ký hiệu là blockID trong Protobuf. Nó chứa định danh nguyên tử của một khối. Một Block ID chứa 2 tham số:

hash: mã băm của khối.
number: mã băm và chiều cao của khối.

5.2 Giao dịch (Transaction)

5.2.1 Ký (Signing)

Quá trình ký giao dịch của TRON tuân theo thuật toán mật mã chuẩn ECDSA, với đường cong lựa chọn SECP256K1. Một khóa riêng tư là một số ngẫu nhiên, và khóa công khai là một điểm trên đường cong elip. Quá trình tạo khóa công khai bao gồm việc đầu tiên tạo ra một số ngẫu nhiên làm khóa riêng tư, sau đó nhân điểm cơ sở của đường cong elip với khóa riêng tư để thu được khóa công khai. Khi một giao dịch xảy ra, dữ liệu thô của giao dịch trước tiên được chuyển đổi sang định dạng byte. Dữ liệu thô sau đó trải qua quá trình băm SHA-256. Khóa riêng tư tương ứng với địa chỉ hợp đồng sau đó sẽ ký kết quả của hàm băm SHA256. Kết quả chữ ký sau đó được thêm vào giao dịch.

5.2.2 Mô hình Băng thông (Bandwidth Model)

Các giao dịch thông thường chỉ tiêu tốn Băng thông (Bandwidth Points), nhưng các hoạt động của Hợp đồng thông minh tiêu tốn cả Năng lượng (Energy) và Băng thông. Có hai loại Băng thông có sẵn. Người dùng có thể nhận được Băng thông từ việc Khóa TRX (freezing TRX), trong khi một lượng Băng thông miễn phí hàng ngày cũng có sẵn mỗi ngày.

Khi một giao dịch TRX được phát tán, nó được truyền và lưu trữ dưới dạng mảng byte trên mạng lưới. Băng thông tiêu tốn cho một giao dịch = số byte của giao dịch nhân với tỷ lệ Băng thông. Ví dụ, nếu chiều dài mảng byte của một giao dịch là 200, thì giao dịch tiêu tốn 200 Băng thông. Tuy nhiên, nếu một khoản chuyển TRX hoặc token dẫn đến việc tạo tài khoản đích, thì chỉ Băng thông tiêu tốn để tạo tài khoản bị trừ đi và không bị trừ thêm Băng thông nào nữa. Khi một khoản chuyển tiền tạo ra một tài khoản mà không có đủ Băng thông khả dụng, một khoản Phí tạo tài khoản do đề xuất kiểm soát là 0.1 TRX sẽ bị trừ. Các giao dịch tạo tài khoản hiện có giới hạn kích thước là 1000 byte, cũng được điều chỉnh bởi đề xuất. Trong kịch bản tạo tài khoản, trước tiên mạng lưới sẽ tiêu tốn Băng thông mà người khởi tạo giao dịch có được từ việc Khóa TRX. Nếu số lượng này không đủ, mạng lưới sẽ tiêu tốn TRX của người khởi tạo giao dịch.

Trong kịch bản chuyển TRX tiêu chuẩn từ tài khoản TRX này sang tài khoản TRX khác, trước tiên mạng lưới sẽ tiêu tốn Băng thông người khởi tạo giao dịch có được nhờ việc Khóa TRX. Nếu số lượng này không đủ, nó sẽ lấy từ Băng thông miễn phí hàng ngày. Nếu vẫn chưa đủ, mạng lưới sẽ tiêu tốn TRX của người khởi tạo giao dịch. Số tiền được tính bằng số byte trong giao dịch nhân với chi phí TRX mỗi byte. Do đó, đối với hầu hết những người nắm giữ TRX có thể không nhất thiết phải Khóa TRX của họ để tham gia biểu quyết SR, bước đầu tiên sẽ tự động bị bỏ qua (vì số dư TRX bị khóa = 0) và Băng thông miễn phí hàng ngày sẽ tạo năng lượng cho giao dịch.

Đối với các khoản chuyển token TRC-10, trước tiên mạng lưới sẽ xác minh xem tổng số Băng thông miễn phí của tài sản token được phát hành có đủ hay không. Nếu không, Băng thông có được từ việc Khóa TRX sẽ bị tiêu tốn. Nếu vẫn không đủ Băng thông, mạng lưới sẽ tiêu tốn TRX của người khởi tạo giao dịch.

5.2.3 Phí

Mạng lưới TRON nhìn chung không tính phí cho hầu hết các giao dịch, tuy nhiên, do những hạn chế của hệ thống và tính công bằng, việc sử dụng Băng thông và các giao dịch sẽ phải chịu một số Phí mạng nhất định.

Chi phí mạng được chia thành các loại sau:

Các giao dịch thông thường tiêu tốn Băng thông. Người dùng có thể sử dụng lượng Băng thông miễn phí hàng ngày hoặc Khóa TRX để có thêm Băng thông. Khi Băng thông không đủ, TRX sẽ được trừ trực tiếp từ tài khoản gửi. Số TRX cần thiết là: số byte * chi phí TRX mỗi byte.
Hợp đồng thông minh tiêu tốn Năng lượng (Phần 6) nhưng cũng sẽ cần Băng thông để giao dịch được phát tán và xác nhận. Chi phí Băng thông tương tự như trên.
Tất cả các giao dịch truy vấn (query) đều miễn phí. Nó không tiêu tốn Năng lượng hay Băng thông.

Mạng lưới TRON cũng xác định một bộ Phí cố định cho các giao dịch sau (để có các giá trị mới nhất, vui lòng tham khảo TRON Chain Parameters API):

Phát hành một token TRC-10: 1,024 TRX (xem getAssetIssueFee)
Đăng ký làm ứng cử viên SR: 9,999 TRX (xem getAccountUpgradeCost)
Tạo giao dịch Bancor: 1,024 TRX (xem getExchangeCreateFee)
Cập nhật quyền hạn tài khoản: 100 TRX (xem getUpdateAccountPermissionFee)
Kích hoạt tài khoản: 1 TRX (xem getCreateNewAccountFeeInSystemContract); thiếu Băng thông thu được thông qua Khóa TRX (staking) trong tài khoản của người tạo sẽ phải chịu thêm khoản phí 0.1 TRX để thanh toán cho Băng thông (xem getCreateAccountFee)
Giao dịch đa chữ ký (Multisig): 1 TRX (xem getMultiSignFee)
Ghi chú giao dịch: 1 TRX (xem getMemoFee)

5.2.4 Giao dịch dưới dạng Proof of Stake (TaPoS)

TRON sử dụng TaPoS để đảm bảo tất cả các giao dịch đều xác nhận blockchain chính, đồng thời gây khó khăn cho việc làm giả các chuỗi sao chép (counterfeit chains). Trong TaPoS, các mạng lưới yêu cầu mỗi giao dịch bao gồm một phần mã băm của tiêu đề khối gần đây. Yêu cầu này ngăn các giao dịch bị lặp lại (replayed) trên các phân nhánh (forks) không bao gồm khối được tham chiếu, và cũng báo hiệu cho mạng lưới biết rằng một người dùng cụ thể và số lượng Khóa TRX của họ đang nằm trên một phân nhánh cụ thể. Cơ chế đồng thuận này bảo vệ mạng lưới chống lại các cuộc tấn công Từ chối dịch vụ (DoS), 51%, khai thác ích kỷ (selfish mining) và chi tiêu kép (double-spending).

5.2.5 Xác nhận Giao dịch

Một giao dịch được đưa vào một khối sau khi được phát tán lên mạng lưới. Giao dịch được coi là đã xác nhận (confirmed) sau khi khối của nó được theo sau bởi 19 khối liên tiếp, mỗi khối được tạo bởi một Super Representative khác nhau.

Mỗi khối mất $\sim3$ giây để được đào trên blockchain. Thời gian có thể thay đổi một chút đối với mỗi SR do điều kiện mạng và cấu hình máy. Nhìn chung, một giao dịch được coi là hoàn toàn được xác nhận sau $\sim1$ phút.

5.2.6 Cấu trúc

Các API giao dịch bao gồm các hàm sau:

message Transaction {
  message Contract {
    enum ContractType {
      AccountCreateContract = 0; // Create account/wallet
      TransferContract = 1; // Transfer TRX
      TransferAssetContract = 2; // Transfer TRC-10 token
      VoteWitnessContract = 4; // Vote for SR
      WitnessCreateContract = 5; // Create a new SR account
      AssetIssueContract = 6; // Create a new TRC-10 token
      WitnessUpdateContract = 8; // Update SR information
      ParticipateAssetIssueContract = 9; // Purchase TRC-10 token
      AccountUpdateContract = 10; // Update account/wallet information
      FreezeBalanceContract = 11; // Freeze TRX for Bandwidth or Energy
      UnfreezeBalanceContract = 12; // Unfreeze TRX
      WithdrawBalanceContract = 13; // Withdraw SR rewards, once per day
      UnfreezeAssetContract = 14; // Unfreeze TRC-10 token
      UpdateAssetContract = 15; // Update a TRC-10 token's information
      ProposalCreateContract = 16; // Create a new network proposal by any SR
      ProposalApproveContract = 17; // SR votes yes for a network proposal
      ProposalDeleteContract = 18; // Delete a network proposal by owner
      CreateSmartContract = 30; // Deploy a new smart contract
      TriggerSmartContract = 31; // Call a function on a smart contract
      GetContract = 32; // Get an existing smart contract
      UpdateSettingContract = 33; // Update a smart contract's parameters
      ExchangeCreateContract = 41; // Create a token trading pair on DEX
      ExchangeInjectContract = 42; // Inject funding into a trading pair
      ExchangeWithdrawContract = 43; // Withdraw funding from a trading pair
      ExchangeTransactionContract = 44; // Perform token trading
      UpdateEnergyLimitContract = 45; // Update origin_energy_limit on a smart contract
      AccountPermissionUpdateContract = 46; // Update account permissions
      ClearABIContract = 48; // Clear a smart contract's ABI
      UpdateBrokerageContract = 49; // Update SR brokerage commission rate
      MarketSellAssetContract = 52; // Place a market sell order
      MarketCancelOrderContract = 53; // Cancel an existing market order
      FreezeBalanceV2Contract = 54; // Freeze TRX to get resources
      UnfreezeBalanceV2Contract = 55; // Cancel freezed TRX
      WithdrawExpireUnfreezeContract = 56; // Withdraw TRX after the unfreeze waiting period has expired
      DelegateResourceContract = 57; // Delegate Bandwidth or Energy to another account
      UnDelegateResourceContract = 58; // Cancel delegated resource
      CancelAllUnfreezeV2Contract = 59; // Cancel all pending unfreeze operations
    }
    ContractType type = 1;
    google.protobuf.Any parameter = 2;
    bytes provider = 3;
    bytes ContractName = 4;
    int32 Permission_id = 5;
  }
}

6 Máy ảo TRON (TVM)

6.1 Giới thiệu

Máy ảo TRON (TVM) là một máy ảo Turing hoàn chỉnh, nhẹ, được phát triển cho hệ sinh thái TRON. Mục tiêu của nó là cung cấp một hệ thống blockchain tùy chỉnh hiệu quả, thuận tiện, ổn định, bảo mật và có khả năng mở rộng.

TVM ban đầu được phân nhánh (forked) từ EVM và có thể kết nối liền mạch với hệ sinh thái phát triển Hợp đồng thông minh Solidity hiện có. Dựa trên đó, TVM bổ sung thêm sự hỗ trợ cho đồng thuận DPoS.

TVM giới thiệu khái niệm Năng lượng (Energy) để quản lý tài nguyên tính toán, khác với cơ chế Gas của EVM. Trên TVM, việc thực thi các Hợp đồng thông minh sẽ tiêu tốn Năng lượng. Người dùng có thể nhận Năng lượng bằng cách Khóa TRX (staking TRX). Khi một tài khoản có đủ Năng lượng, việc thực thi các hoạt động Hợp đồng thông minh không yêu cầu Đốt TRX trực tiếp. Khi lượng Năng lượng có sẵn không đủ, hệ thống sẽ Đốt TRX từ tài khoản để trang trải chi phí tính toán.

6.2 Quy trình làm việc (Workflow)

Trình biên dịch trước tiên dịch Hợp đồng thông minh Solidity thành bytecode có thể đọc và thực thi trên TVM. TVM sau đó xử lý dữ liệu thông qua opcode, tương đương với việc vận hành logic của một máy trạng thái hữu hạn (finite state machine) dựa trên ngăn xếp (stack-based). Cuối cùng, TVM truy cập dữ liệu blockchain và gọi Giao diện Dữ liệu Bên ngoài (External Data Interface) thông qua Lớp Tương tác (Interoperation layer).

6.3 Hiệu suất

6.3.1 Kiến trúc Nhẹ (Lightweight Architecture)

TVM áp dụng một kiến trúc nhẹ với mục đích giảm tiêu thụ tài nguyên để đảm bảo hiệu suất hệ thống.

6.3.2 Mạnh mẽ (Robust)

TRON sử dụng mô hình tài nguyên kép (bao gồm Băng thông và Năng lượng) để xử lý giao dịch và thực thi Hợp đồng thông minh. Người dùng có thể thu được các tài nguyên này chủ yếu mà không mất Phí giao dịch trực tiếp bằng cách Khóa TRX. Khi vượt quá giới hạn tài nguyên, TRX sẽ bị tiêu tốn (Đốt) tương ứng với mức sử dụng vượt mức. Hệ thống quản lý tài nguyên này tăng cường bảo mật mạng lưới bằng cách làm tăng đáng kể chi phí kinh tế của các hoạt động độc hại và đảm bảo mức tiêu thụ tài nguyên có thể dự đoán được do chi phí đơn vị cố định cho mỗi hoạt động.

6.3.3 Khả năng Tương thích Cao

TVM tương thích với EVM và sẽ tương thích với nhiều VM (máy ảo) phổ biến hơn trong tương lai. Nhờ đó, tất cả các Hợp đồng thông minh trên EVM đều có thể thực thi trên TVM.

6.3.4 Chi phí Thấp

Nhờ thiết lập Băng thông của TVM, chi phí phát triển được giảm bớt và các nhà phát triển có thể tập trung vào việc phát triển logic cho mã hợp đồng của họ. TVM cũng cung cấp các giao diện tất cả trong một để triển khai, kích hoạt và xem hợp đồng nhằm mang lại sự tiện lợi cho các nhà phát triển.

7 Hợp đồng Thông minh (Smart Contract)

7.1 Giới thiệu

Một Hợp đồng thông minh là một giao thức xác minh bằng kỹ thuật số việc đàm phán hợp đồng. Chúng định nghĩa các quy tắc và hình phạt liên quan đến một thỏa thuận và cũng tự động thực thi các nghĩa vụ đó. Mã Hợp đồng thông minh tạo điều kiện, xác minh và thực thi việc đàm phán hoặc thực hiện một thỏa thuận hoặc giao dịch. Từ góc độ token hóa, các Hợp đồng thông minh cũng tạo điều kiện cho việc chuyển tiền tự động giữa các bên tham gia nếu đáp ứng một số tiêu chí nhất định.

Hợp đồng thông minh TRON được viết bằng ngôn ngữ Solidity. Sau khi được viết và thử nghiệm, chúng có thể được biên dịch thành bytecode, sau đó được triển khai lên mạng lưới TRON cho Máy ảo TRON. Sau khi được triển khai, các Hợp đồng thông minh có thể được truy vấn thông qua các địa chỉ hợp đồng của chúng. Giao diện nhị phân ứng dụng (Application Binary Interface - ABI) của hợp đồng hiển thị các hàm gọi (call functions) của hợp đồng và được sử dụng để tương tác với mạng lưới.

7.2 Mô hình Năng lượng

Giới hạn Năng lượng tối đa để triển khai và kích hoạt một Hợp đồng thông minh là một hàm số của một số biến:

Giới hạn Năng lượng Động (Dynamic Energy) từ việc Khóa 1 TRX = Tổng giới hạn Năng lượng (Total Energy Limit) / (Tổng trọng số Năng lượng)
Giới hạn Năng lượng (Energy limit) là giới hạn Năng lượng hàng ngày của tài khoản từ việc Khóa TRX
Năng lượng tài khoản hàng ngày còn lại từ việc Khóa TRX được tính bằng Giới hạn Năng lượng - Năng lượng đã sử dụng
Giới hạn Phí mạng bằng TRX (Fee limit in TRX) được thiết lập trong lệnh gọi triển khai/kích hoạt Hợp đồng thông minh
TRX khả dụng còn lại trong tài khoản
Năng lượng mỗi TRX nếu mua trực tiếp (210 SUN = 1 Năng lượng) = 100,000, các SR có thể biểu quyết để điều chỉnh

Có hai kịch bản tiêu thụ cần tính toán để giới hạn Năng lượng tối đa khi triển khai và kích hoạt. Logic có thể được biểu thị như sau:

const R = Dynamic Energy Limit // Giới hạn Năng lượng Động
const F = Daily account Energy from freezing TRX // Năng lượng hàng ngày của tài khoản từ việc Khóa TRX
const E = Remaining daily account Energy from freezing TRX // Năng lượng tài khoản hàng ngày còn lại từ việc Khóa TRX
const L = Fee limit in TRX set in deploy/trigger call // Giới hạn Phí mạng bằng TRX được thiết lập trong lệnh gọi triển khai/kích hoạt
const T = Remaining usable TRX in account // TRX khả dụng còn lại trong tài khoản
const C = Energy per TRX if purchased directly // Năng lượng mỗi TRX nếu mua trực tiếp
// Calculate M, defined as maximum Energy limit for deployment/trigger of a smart contract (Tính toán M, được định nghĩa là giới hạn Năng lượng tối đa để triển khai/kích hoạt Hợp đồng thông minh)
if F > L*R
    let M = min(E+T*C, L*R)
else
    let M = E+T*C

Kể từ ngày 5 tháng 2 năm 2023, mạng lưới TRON đã triển khai một mô hình Năng lượng động mới, được kích hoạt bởi đề xuất của ủy ban số 83 do cộng đồng nhà phát triển TRON khởi xướng. Mô hình này tự động điều chỉnh mức tiêu thụ Năng lượng của mỗi hợp đồng tùy theo mức độ chiếm dụng tài nguyên của hợp đồng đó. Điều này nhằm mục đích làm cho việc phân bổ tài nguyên Năng lượng trên chuỗi trở nên hợp lý hơn và để ngăn chặn sự tập trung quá mức các tài nguyên của mạng lưới vào một số ít các hợp đồng phổ biến.

7.3 Triển khai (Deployment)

Khi một Hợp đồng thông minh Solidity của TRON được biên dịch, Máy ảo TRON sẽ đọc bytecode đã biên dịch. Bytecode bao gồm một phần cho việc triển khai mã, mã hợp đồng và Auxdata. Auxdata là dấu vân tay mật mã của mã nguồn, được sử dụng để xác minh. Bytecode triển khai chạy hàm khởi tạo (constructor function) và thiết lập các biến lưu trữ ban đầu. Mã triển khai cũng tính toán mã hợp đồng và trả về cho TVM. ABI là một tệp JSON mô tả các chức năng của một Hợp đồng thông minh TRON. Tệp này xác định tên các hàm, khả năng thanh toán (payability) của chúng, giá trị trả về của hàm và khả năng thay đổi trạng thái (state mutability) của chúng.

7.4 Hàm kích hoạt (Trigger Function)

Sau khi các Hợp đồng thông minh TRON được triển khai, các hàm của chúng có thể được kích hoạt riêng lẻ thông qua Tronide hoặc thông qua các lệnh gọi API. Các hàm làm thay đổi trạng thái (State-changing functions) yêu cầu Năng lượng trong khi các hàm chỉ đọc (read-only functions) được thực thi mà không tiêu tốn Năng lượng.

7.5 TRON Solidity

TRON Solidity là một nhánh (fork) từ ngôn ngữ Solidity của Ethereum. TRON sửa đổi dự án gốc để hỗ trợ các đơn vị TRX và SUN (1 TRX = 1,000,000 SUN). Phần còn lại của cú pháp ngôn ngữ tương thích với Solidity 0.8.23. Do đó, Máy ảo TRON (TVM) gần như tương thích 100% với các lệnh của EVM.

8 Token

8.1 Token TRC-10

Trong mạng lưới TRON, mỗi tài khoản có thể phát hành token với chi phí là 1024 TRX. Để phát hành token, tổ chức phát hành cần chỉ định tên token, tổng vốn hóa, tỷ giá quy đổi sang TRX, thời gian lưu thông, mô tả, trang web, mức tiêu thụ Băng thông tối đa trên mỗi tài khoản, tổng mức tiêu thụ Băng thông và lượng token bị Đóng băng. Mỗi lần phát hành token cũng có thể định cấu hình Băng thông chuyển token tối đa hàng ngày của mỗi tài khoản, Băng thông chuyển token tối đa hàng ngày của toàn mạng lưới, tổng cung token, thời gian khóa tính bằng ngày và tổng lượng token bị khóa.

8.2 Token TRC-20

TRC-20 là một tiêu chuẩn kỹ thuật được sử dụng cho các Hợp đồng thông minh triển khai token được Máy ảo TRON hỗ trợ. Nó hoàn toàn tương thích với ERC-20.

Giao diện như sau:

contract TRC20Interface {
    function totalSupply() public constant returns (uint);
    function balanceOf(address tokenOwner) public constant returns (uint balance);
    function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
    function transfer(address to, uint tokens) public returns (bool success);
    function approve(address spender, uint tokens) public returns (bool success);
    function transferFrom(address from, address to, uint tokens) public returns (bool success);
    event Transfer(address indexed from, address indexed to, uint tokens);
    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
}

Các khoản chuyển token TRC-10 chủ yếu tiêu tốn Băng thông, trong khi chuyển token TRC-20 tiêu tốn cả Băng thông và Năng lượng. Sự khác biệt trong tiêu thụ tài nguyên này thường dẫn đến Phí giao dịch cho token TRC-10 thấp hơn đáng kể so với TRC-20. Mặc dù các lệnh gọi chuyển khoản qua API và ký gửi (deposits) token TRC-10 sẽ phát sinh chi phí Băng thông, nhưng chi phí nhìn chung vẫn thấp hơn tổng Băng thông và Năng lượng của giao dịch TRC-20. Chuyển khoản và ký gửi bằng Hợp đồng thông minh đối với token TRC-10 tiêu tốn cả Băng thông và Năng lượng. Ngược lại, TRC-20 luôn tiêu tốn cả Băng thông và Năng lượng cho các khoản chuyển và ký gửi, dù là thông qua các lệnh gọi API hay Hợp đồng thông minh.

8.3 Những mở rộng khác

Vì TRON sử dụng cùng phiên bản Solidity như Ethereum, nên nhiều tiêu chuẩn token hơn có thể dễ dàng được port (chuyển) sang TRON.

9 Quản trị (Governance)

9.1 Super Representative

9.1.1 Tổng quát

Mọi tài khoản trong mạng lưới TRON đều có thể đăng ký và có cơ hội trở thành Super Representative (SR). Mọi người đều có thể bầu chọn cho các ứng cử viên SR. 27 ứng cử viên hàng đầu có số phiếu bầu nhiều nhất sẽ trở thành SR với quyền và nghĩa vụ tạo ra các khối. Các phiếu bầu được kiểm mỗi 6 giờ và các SR sẽ thay đổi tương ứng.

Để ngăn chặn các cuộc tấn công độc hại, sẽ có một chi phí để trở thành ứng cử viên SR. Khi đăng ký, 9999 TRX sẽ bị Đốt từ tài khoản của người nộp đơn. Sau khi thành công, tài khoản đó có thể tham gia cuộc bầu cử SR.

9.1.2 Bầu cử

TRON Power (được ký hiệu là TP) là cần thiết để bỏ phiếu và số lượng TP phụ thuộc vào tài sản bị Đóng băng (TRX) của cử tri.

TP được tính theo cách sau:

$1 \text{ TP} = 1 \text{ TRX frozen to get Energy/Bandwidth}$

Mọi tài khoản trong mạng TRON đều có quyền bầu chọn cho các SR của riêng họ.

Sau khi giải phóng (Hủy đóng băng, khả dụng sau 14 ngày), người dùng sẽ không còn bất kỳ tài sản bị Đóng băng nào và mất tất cả TP tương ứng. Do đó, tất cả các phiếu bầu đều trở nên không hợp lệ đối với vòng bỏ phiếu đang diễn ra và trong tương lai trừ khi TRX lại được Đóng băng để bỏ phiếu.

Lưu ý rằng mạng lưới TRON chỉ ghi lại lượt bỏ phiếu gần đây nhất, điều đó có nghĩa là mỗi phiếu bầu mới sẽ phủ định tất cả các phiếu bầu trước đó.

9.1.3 Phần thưởng

a. Phần thưởng biểu quyết (Vote Reward)

Còn được gọi là Phần thưởng Ứng cử viên (Candidate Reward), 127 ứng cử viên hàng đầu (cập nhật 6 giờ một lần) sẽ chia nhau 921.600 TRX được đào. Phần thưởng sẽ được chia theo tỷ lệ phần trăm phiếu bầu mà mỗi ứng cử viên nhận được. Mỗi năm, tổng phần thưởng cho các ứng cử viên sẽ là 1.345.536.000 TRX.

Tổng phần thưởng biểu quyết mỗi vòng

Tại sao lại là 921.600 TRX mỗi vòng?

$921,600 \text{ TRX} = \text{total vote reward per round } (VR/round)$

$VR/round = 128 \text{ TRX/block} \times 20 \text{ blocks/min} \times 60 \text{ mins/hr} \times 6 \text{ hrs/round}$

Lưu ý: điều này được thiết lập bởi WITNESS_127_PAY_PER_BLOCK = 128 TRX. Xem các tham số mạng động (dynamic network parameters).

Tổng phần thưởng biểu quyết mỗi năm

Tại sao lại là 1.345.536.000 TRX mỗi năm?

$1,345,536,000 \text{ TRX} = \text{total vote reward per year } (VR/year)$

$VR/year = 921,600 \text{ TRX/round} \times 4 \text{ rounds/day} \times 365 \text{ days/year}$

b. Phần thưởng Khối (Block Reward)

Còn được gọi là Phần thưởng Super Representative, 27 ứng cử viên hàng đầu (SR) được bầu chọn mỗi vòng (6 giờ) sẽ chia nhau khoảng 57.600 TRX được đào. Phần thưởng sẽ được chia đều cho 27 SR (trừ đi tổng phần thưởng các khối bị bỏ lỡ do lỗi mạng). Tổng cộng 84.096.000 TRX sẽ được trao thưởng hàng năm cho 27 SR.

Tổng phần thưởng khối mỗi vòng

Tại sao lại là 57.600 TRX mỗi vòng?

$57,600 \text{ TRX} = \text{total block reward per round } (BR/round)$

$BR/round = 8 \text{ TRX/block} \times 20 \text{ blocks/min} \times 60 \text{ mins/hr} \times 6 \text{ hrs/round}$

Lưu ý: phần thưởng khối trên mỗi đơn vị được thiết lập bởi WITNESS_PAY_PER_BLOCK = 8 TRX. Xem các tham số mạng động.

Tổng phần thưởng khối mỗi năm

Tại sao lại là 84.096.000 TRX mỗi năm?

$84,096,000 \text{ TRX} = \text{total block reward per year } (BR/year)$

$BR/year = 57,600 \text{ TRX/round} \times 4 \text{ rounds/day} \times 365 \text{ days/year}$

c. Tính toán Phần thưởng

Tính toán phần thưởng cho SR

$\text{total reward} = \text{vote reward}(VR) + \text{block reward}(BR)$

$VR = \text{total } VR \times \frac{\text{votes SR candidate received}}{\text{total votes}}$

$BR = \frac{\text{total } BR}{27} - \text{block missed} \times 32$

Lưu ý: phần thưởng được tính cho mỗi SR mỗi vòng (6 giờ)

Tính toán phần thưởng cho ứng cử viên SR hạng 28 đến 127

$\text{total reward} = \text{vote reward}(VR)$

$VR = \text{total } VR \times \frac{\text{votes SR candidate received}}{\text{total votes}}$

Lưu ý: phần thưởng được tính cho mỗi ứng cử viên SR mỗi vòng (6 giờ)

9.2 Ủy ban (Committee)

9.2.1 Tổng quát

Ủy ban được sử dụng để sửa đổi các tham số mạng động của TRON, chẳng hạn như phần thưởng tạo khối, Phí giao dịch, v.v. Ủy ban bao gồm 27 SR trong vòng hiện tại. Mỗi SR có quyền đề xuất và biểu quyết về các đề xuất. Khi một đề xuất nhận được 19 phiếu bầu trở lên, nó sẽ được thông qua và các tham số mạng mới sẽ được áp dụng trong đợt bảo trì tiếp theo (3 ngày).

9.2.2 Tham số mạng động (Dynamic Network Parameters)

Vui lòng xem Phụ lục B để biết thêm chi tiết.

9.2.3 Tạo Đề xuất

Chỉ các tài khoản SR mới có quyền đề xuất thay đổi các tham số mạng động.

9.2.4 Bỏ phiếu Đề xuất

Chỉ các thành viên ủy ban (SR) mới có thể bỏ phiếu cho một đề xuất và thành viên không bỏ phiếu kịp thời sẽ bị coi là không đồng ý. Đề xuất sẽ có hiệu lực trong 3 ngày sau khi được tạo. Phiếu bầu có thể được thay đổi hoặc rút lại trong khoảng thời gian 3 ngày bỏ phiếu này. Khi khoảng thời gian kết thúc, đề xuất sẽ thành công (hơn 19 phiếu) hoặc thất bại (và kết thúc).

9.2.5 Hủy Đề xuất

Người đề xuất có thể hủy bỏ đề xuất trước khi nó có hiệu lực.

9.3 Cấu trúc

Các SR là witness (người làm chứng) của các khối mới được tạo ra. Một witness chứa 8 tham số:

address: địa chỉ của witness này - ví dụ: 0xu82h… 7237.
voteCount: số lượng phiếu bầu nhận được của witness này - ví dụ: 234234.
pubKey: khóa công khai cho witness này - ví dụ: 0xu82h… 7237.
url: url cho witness này - ví dụ: https://www.noonetrust.com.
totalProduced: số lượng khối mà witness này đã sản xuất - ví dụ: 2434.
totalMissed: số lượng khối mà witness này đã bỏ lỡ - ví dụ: 7.
latestBlockNum: chiều cao gần nhất của khối - ví dụ: 4522.
isjobs: một cờ boolean (boolean flag).

Cấu trúc dữ liệu Protobuf:

message Witness {
  bytes address = 1;
  int64 voteCount = 2;
  bytes pubKey = 3;
  string url = 4;
  int64 totalProduced = 5;
  int64 totalMissed = 6;
  int64 latestBlockNum = 7;
  bool isJobs = 8;
}

10 Phát triển dApp

10.1 API

Mạng lưới TRON cung cấp nhiều lựa chọn với hơn 60+ cổng (gateway) API HTTP để tương tác với mạng lưới thông qua Full Nodes. Ngoài ra, TronWeb là một thư viện JavaScript toàn diện chứa các hàm API cho phép các nhà phát triển triển khai Hợp đồng thông minh, thay đổi trạng thái blockchain, truy vấn thông tin hợp đồng và blockchain, giao dịch trên DEX và nhiều hơn thế nữa. Các cổng API này có thể được chuyển hướng (directed) đến một privatenet cục bộ, testnet Shasta, testnet Nile, hoặc TRON Mainnet.

10.2 Mạng lưới (Networks)

TRON có một testnet Shasta, một testnet Nile, cũng như một Mainnet. Các nhà phát triển có thể kết nối với mạng lưới bằng cách triển khai các Node, tương tác thông qua Fullnode API của dịch vụ TronGrid. Dịch vụ TronGrid bao gồm các cụm Node cân bằng tải (load balanced node clusters) được lưu trữ trên các máy chủ AWS trên toàn thế giới. Khi quy mô phát triển dApp tăng lên và khối lượng gọi API tăng lên, TronGrid vẫn đáp ứng thành công sự gia tăng lưu lượng API.

10.3 Tài nguyên (Resources)

TRON Developer Hub là một trang tài liệu API toàn diện được thiết kế riêng cho các nhà phát triển muốn xây dựng trên mạng lưới TRON. Developer Hub cung cấp hiểu biết cấp cao về khái niệm TRON và hướng dẫn người dùng qua các chi tiết về việc tương tác với mạng lưới. Các hướng dẫn chỉ dẫn các nhà phát triển thông qua việc thiết lập Node, triển khai và tương tác với các Hợp đồng thông minh, tương tác và triển khai API, xây dựng dApp mẫu và cách sử dụng từng công cụ dành cho nhà phát triển.

11 Kết luận

TRON là một giải pháp blockchain có khả năng mở rộng đã áp dụng các phương pháp sáng tạo để giải quyết các thách thức mà các mạng blockchain cũ (legacy) phải đối mặt. Từng đạt được hơn 2 triệu giao dịch mỗi ngày, với hơn 700,000 tài khoản TRX, và vượt quá 2,000 TPS, TRON đã trao quyền cho cộng đồng trong việc tạo ra một mạng lưới phi tập trung và dân chủ hóa.

Phụ lục A: Thuật ngữ

Address/Wallet (Địa chỉ/Ví) Một địa chỉ hoặc Ví bao gồm thông tin xác thực tài khoản trên mạng lưới TRON được tạo bởi một cặp khóa (key pair), bao gồm một khóa riêng tư và một khóa công khai, trong đó khóa công khai được bắt nguồn từ khóa riêng tư thông qua một thuật toán. Khóa công khai thường được sử dụng để mã hóa khóa phiên (session key encryption), xác minh chữ ký và mã hóa dữ liệu mà có thể được giải mã bằng khóa riêng tư tương ứng.

Application Binary Interface (ABI) - Giao diện nhị phân ứng dụng ABI là một giao diện giữa hai mô-đun chương trình nhị phân; thông thường một trong những mô-đun này là thư viện hoặc một phương tiện hệ điều hành, và mô-đun kia là chương trình do người dùng chạy.

Application Programming Interface (API) - Giao diện lập trình ứng dụng Một API chủ yếu được sử dụng để phát triển máy khách (user clients) cho người dùng. Với sự hỗ trợ của API, các nền tảng phát hành token cũng có thể được thiết kế bởi chính các nhà phát triển.

Asset (Tài sản) Trong các tài liệu của TRON, asset giống với token, vốn cũng được ký hiệu là token TRC-10.

Bandwidth Points (BP) - Điểm Băng thông Để giữ cho mạng lưới hoạt động trơn tru, các giao dịch mạng TRON sử dụng BP làm nhiên liệu. Mỗi tài khoản nhận được một lượng BP miễn phí hàng ngày, được xác định bởi tham số freeNetLimit trong TRON Chain Parameters API, và có thể nhận được nhiều hơn bằng cách Khóa TRX để lấy BP. Cả chuyển TRX và chuyển token TRC-10 đều là các giao dịch bình thường tiêu tốn BP. Giao dịch triển khai và thực thi Hợp đồng thông minh tiêu tốn cả BP và Năng lượng.

Block (Khối) Các khối chứa hồ sơ kỹ thuật số của các giao dịch. Một khối hoàn chỉnh bao gồm mã magic (magic number), kích thước khối, tiêu đề khối, bộ đếm giao dịch và dữ liệu giao dịch.

Block Reward (Phần thưởng Khối) Phần thưởng tạo khối được gửi đến một tài khoản phụ (địa chỉ/Ví). SR có thể nhận (claim) phần thưởng của họ trên Tronscan hoặc thông qua API trực tiếp.

Block Header (Tiêu đề Khối) Tiêu đề khối là một phần của khối. Các tiêu đề khối TRON chứa mã băm của khối trước đó, gốc Merkle, dấu thời gian, phiên bản và địa chỉ witness.

Cold Wallet (Ví Lạnh) Ví lạnh, còn được gọi là Ví ngoại tuyến (offline wallet), giữ cho khóa riêng tư hoàn toàn ngắt kết nối với bất kỳ mạng nào. Ví lạnh thường được cài đặt trên các thiết bị “lạnh” (ví dụ: máy tính hoặc điện thoại di động ngoại tuyến) để đảm bảo an ninh cho khóa riêng tư TRX.

Decentralized Application (dApp) - Ứng dụng Phi tập trung dApp là một ứng dụng hoạt động mà không cần một bên tập trung đáng tin cậy. Một ứng dụng cho phép tương tác/thỏa thuận/giao tiếp trực tiếp giữa người dùng cuối và/hoặc các tài nguyên mà không cần thông qua một bên trung gian.

gRPC Remote Procedure Calls (gRPC) gRPC là một hệ thống gọi thủ tục từ xa (RPC) nguồn mở được phát triển ban đầu tại Google. Nó sử dụng HTTP/2 để truyền tải, Protocol Buffers làm ngôn ngữ mô tả giao diện và cung cấp các tính năng như xác thực, kiểm soát luồng và phát trực tuyến hai chiều (bidirectional streaming), liên kết chặn hoặc không chặn (blocking or nonblocking bindings), và tính năng hủy và thời gian chờ (cancellation and timeouts). Nó tạo ra các liên kết chéo nền tảng (cross-platform client and server bindings) cho nhiều ngôn ngữ. Các tình huống sử dụng phổ biến nhất bao gồm kết nối các dịch vụ trong kiến trúc kiểu vi dịch vụ (microservices) và kết nối thiết bị di động, cũng như các máy khách của trình duyệt với các dịch vụ phụ trợ (backend services).

Hot Wallet (Ví Nóng) Ví nóng, còn được gọi là Ví trực tuyến, cho phép các khóa riêng tư của người dùng được sử dụng trực tuyến, do đó nó có thể dễ bị tổn thương trước các lỗ hổng tiềm ẩn hoặc bị các tác nhân độc hại đánh chặn.

Java Development Kit (JDK) JDK là Java SDK được sử dụng cho các ứng dụng Java. Đây là cốt lõi của việc phát triển Java, bao gồm môi trường ứng dụng Java (JVM + thư viện lớp Java) và các công cụ Java.

KhaosDB TRON có một KhaosDB trong bộ nhớ Full-node có thể lưu trữ tất cả các chuỗi phân nhánh (forked chains) mới được tạo trong một khoảng thời gian nhất định và hỗ trợ các witness chuyển từ chuỗi đang hoạt động của riêng họ sang một chuỗi chính mới một cách nhanh chóng. Xem Phần 2.2.2 Lưu trữ Trạng thái để biết thêm chi tiết.

LevelDB LevelDB ban đầu được áp dụng với mục tiêu chính là đáp ứng các yêu cầu R/W nhanh và phát triển nhanh chóng. Sau khi ra mắt Mainnet, TRON đã nâng cấp cơ sở dữ liệu của mình thành một cơ sở dữ liệu hoàn toàn tùy chỉnh được đáp ứng nhu cầu của riêng nó. Xem Phần 2.2.1 Lưu trữ Blockchain để biết thêm chi tiết.

Merkle Root (Gốc Merkle) Gốc Merkle là mã băm của tất cả các mã băm của tất cả các giao dịch được bao gồm như một phần của khối trong mạng blockchain. Xem Phần 3.1 Delegated Proof of Stake (DPoS) để biết thêm chi tiết.

Public Testnet (Shasta, Nile) Một phiên bản của mạng đang chạy trong cấu hình một Node duy nhất (single-node). Các nhà phát triển có thể kết nối và kiểm tra các tính năng mà không cần lo lắng về tổn thất kinh tế. Testnet token không có giá trị và bất kỳ ai cũng có thể yêu cầu thêm từ công cụ vòi (faucet) công khai.

remote procedure call (RPC) Trong điện toán phân tán, một lệnh gọi RPC là khi một chương trình máy tính khiến một thủ tục (chương trình con) thực thi trong một không gian địa chỉ khác (thường là trên máy tính khác trong mạng dùng chung), được mã hóa như thể đó là một lệnh gọi thủ tục (cục bộ) bình thường, mà lập trình viên không mã hóa chi tiết các thủ tục rõ ràng cho sự tương tác từ xa.

Scalability (Khả năng mở rộng) Khả năng mở rộng là một tính năng của Giao thức TRON. Đây là khả năng của một hệ thống, mạng hoặc quy trình để xử lý khối lượng công việc ngày càng tăng hoặc tiềm năng của nó được mở rộng để phù hợp với sự phát triển đó.

SUN SUN đã thay thế drop làm đơn vị nhỏ nhất của TRX. 1 TRX = 1,000,000 SUN.

Throughput (Thông lượng) Thông lượng cao là một tính năng của TRON Mainnet. Nó được đo bằng Transactions Per Second (TPS), cụ thể là khả năng giao dịch tối đa trong một giây.

Timestamp (Dấu thời gian) Thời gian gần đúng của quá trình sản xuất khối được ghi lại dưới dạng dấu thời gian Unix, là số mili giây đã trôi qua kể từ 00:00:00 01 tháng 1 năm 1970 UTC.

TRC-10 Một tiêu chuẩn của tiền mã hóa token trên nền tảng TRON. Cần tuân theo các quy tắc và giao diện nhất định khi tổ chức đợt phát hành tiền xu ban đầu (ICO) trên blockchain TRON.

TRX TRX là viết tắt của Tronix, đây là loại tiền mã hóa chính thức của TRON.

Phụ lục B: Tham số Mạng Động (Dynamic Network Parameters)

0. MAINTENANCE_TIME_INTERVAL

Mô tả: Sửa đổi thời gian khoảng thời gian bảo trì, cũng là khoảng thời gian để SR tính toán và phân phối phần thưởng biểu quyết.
Ví dụ: [6 * 3600 * 1000] ms - tức là 6 giờ.
Phạm vi: [3 * 27 * 1000, 24 * 3600 * 1000] ms

1. ACCOUNT_UPGRADE_COST

Mô tả: Sửa đổi chi phí cho một tài khoản đăng ký trở thành ứng cử viên Super Representative.
Ví dụ: [9 999 000 000] SUN - tức là 9999 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

2. CREATE_ACCOUNT_FEE

Mô tả: Sửa đổi khoản phí cho việc tạo một tài khoản mới bằng cách gửi TRX đến một địa chỉ mới.
Ví dụ: [100 000] SUN - tức là 0.1 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

3. TRANSACTION_FEE

Mô tả: Sửa đổi tỷ lệ Phí cho việc tiêu tốn Băng thông khi lượng Băng thông miễn phí/được Khóa của một tài khoản không đủ.
Ví dụ: [10] SUN/byte.
Phạm vi: [0, 100 000 000 000] SUN/byte

4. ASSET_ISSUE_FEE

Mô tả: Sửa đổi khoản Phí một lần để phát hành một token TRC-10 mới.
Ví dụ: [1 024 000 000] SUN - tức là 1024 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

5. WITNESS_PAY_PER_BLOCK

Mô tả: Sửa đổi phần thưởng được trả cho Super Representative để sản xuất thành công một khối.
Ví dụ: [16 000 000] SUN - tức là 16 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

6. WITNESS_STANDBY_ALLOWANCE

Mô tả: Sửa đổi tổng phần thưởng được phân phối cho 127 Super Representative và Đối tác hàng đầu mỗi vòng.
Ví dụ: [115 200 000 000] SUN - tức là 115,200 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT

Mô tả: Sửa đổi khoản Phí cho việc tạo một tài khoản mới thông qua lệnh gọi hợp đồng hệ thống (system contract call).
Ví dụ: [0] SUN.
Phạm vi: [0, 100 000 000 000 000 000] SUN

8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

Mô tả: Sửa đổi hệ số nhân tiêu thụ Băng thông cho việc tạo một tài khoản mới.
Ví dụ: [1].
Phạm vi: [0, 100 000 000 000 000 000]

9. ALLOW_CREATION_OF_CONTRACTS

Mô tả: Kích hoạt (Enable) hoặc vô hiệu hóa (disable) việc tạo các Hợp đồng thông minh mới.
Ví dụ: True
Loại: True/False

10. REMOVE_THE_POWER_OF_THE_GR

Mô tả: Xóa bỏ quyền biểu quyết ban đầu do Genesis Representatives (GRs) nắm giữ.
Ví dụ: True
Loại: True/False - Lưu ý: không thể thiết lập lại thành False từ True.

11. ENERGY_FEE

Mô tả: Sửa đổi tỷ lệ Phí cho việc tiêu tốn Năng lượng khi lượng Năng lượng của một tài khoản không đủ.
Ví dụ: [10] SUN.
Phạm vi: [0, 100 000 000 000 000 000] SUN

12. EXCHANGE_CREATE_FEE

Mô tả: Sửa đổi khoản Phí cho việc tạo một cặp giao dịch TRC-10 mới trong sàn giao dịch phi tập trung.
Ví dụ: [1 024 000 000] SUN - tức là 1024 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

13. MAX_CPU_TIME_OF_ONE_TX

Mô tả: Sửa đổi thời gian thực thi CPU tối đa được phép cho một giao dịch.
Ví dụ: [50] ms.
Phạm vi: [0, 1000] ms

14. ALLOW_UPDATE_ACCOUNT_NAME

Mô tả: Bật hoặc tắt khả năng cập nhật tên của các tài khoản.
Ví dụ: False
Loại: True/False

15. ALLOW_SAME_TOKEN_NAME

Mô tả: Cho phép các token TRC-10 khác nhau được tạo với cùng tên.
Ví dụ: True
Loại: True/False

16. ALLOW_DELEGATE_RESOURCE

Mô tả: Kích hoạt hoặc vô hiệu hóa chức năng ủy quyền tài nguyên (staking v1.0).
Ví dụ: True
Loại: True/False

18. ALLOW_TVM_TRANSFER_TRC10

Mô tả: Cho phép các Hợp đồng thông minh truyền tải (transfer) trực tiếp token TRC-10 bằng cách sử dụng lệnh gọi transferToken.
Ví dụ: True
Loại: True/False

19. TOTAL_CURRENT_ENERGY_LIMIT

Mô tả: Sửa đổi tổng lượng Năng lượng hiện tại có sẵn trên mạng lưới.
Ví dụ: [50 000 000 000].
Phạm vi: [0, 100 000 000 000 000 000]

20. ALLOW_MULTI_SIGN

Mô tả: Bật hoặc tắt tính năng đa chữ ký cho các tài khoản.
Ví dụ: True
Loại: True/False

21. ALLOW_ADAPTIVE_ENERGY

Mô tả: Bật hoặc tắt mô hình Năng lượng thích ứng (adaptive Energy model).
Ví dụ: True
Loại: True/False

22. UPDATE_ACCOUNT_PERMISSION_FEE

Mô tả: Sửa đổi khoản Phí cho việc cập nhật cấu trúc quyền hạn (permission structure) của một tài khoản.
Ví dụ: [100 000 000] SUN - tức là 100 TRX.
Phạm vi: [0, 100 000 000 000] SUN

23. MULTI_SIGN_FEE

Mô tả: Sửa đổi khoản Phí bổ sung được tính cho việc xử lý giao dịch đa chữ ký.
Ví dụ: [1 000 000] SUN - tức là 1 TRX.
Phạm vi: [0, 100 000 000 000] SUN

24. ALLOW_PROTO_FILTER_NUM

Mô tả: Kích hoạt hoặc vô hiệu hóa việc lọc tin nhắn giao thức (protocol message filtering).
Ví dụ: False
Loại: True/False

26. ALLOW_TVM_CONSTANTINOPLE

Mô tả: Bật các tính năng của bản nâng cấp Ethereum Constantinople trong TVM.
Ví dụ: True
Loại: True/False

29. ADAPTIVE_RESOURCE_LIMIT_MULTIPLIER

Mô tả: Sửa đổi hệ số nhân (multiplier) được sử dụng trong mô hình tài nguyên thích ứng (adaptive resource model).
Ví dụ: [1000].
Phạm vi: [1, 10000]

30. ALLOW_CHANGE_DELEGATION

Mô tả: Cho phép người dùng thay đổi người nhận tài nguyên được ủy quyền của họ mà không cần hủy Đóng băng.
Ví dụ: True
Loại: True/False

31. WITNESS_127_PAY_PER_BLOCK

Mô tả: Sửa đổi phần thưởng tạo khối cho các Đối tác được xếp hạng từ 28-127.
Ví dụ: [160 000 000] SUN - tức là 160 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

32. ALLOW_TVM_SOLIDITY_059

Mô tả: Bật tính năng hỗ trợ TVM cho các hợp đồng được biên dịch bằng Solidity v0.5.9 trở lên.
Ví dụ: True
Loại: True/False

33. ADAPTIVE_RESOURCE_LIMIT_TARGET_RATIO

Mô tả: Sửa đổi tỷ lệ mục tiêu (target ratio) được sử dụng trong thuật toán mô hình tài nguyên thích ứng.
Ví dụ: [10].
Phạm vi: [1, 1000]

35. FORBID_TRANSFER_TO_CONTRACT

Mô tả: Cấm các khoản chuyển TRX trực tiếp đến một hợp đồng không có chức năng dự phòng có thể thanh toán (payable fallback function).
Ví dụ: True
Loại: True/False

39. ALLOW_SHIELDED_TRC20_TRANSACTION

Mô tả: Bật hoặc tắt các giao dịch được che chắn (shielded transactions) nhằm bảo vệ quyền riêng tư cho các token TRC-20.
Ví dụ: True
Loại: True/False

40. ALLOW_PBFT

Mô tả: Bật hoặc tắt cơ chế đồng thuận PBFT để có tốc độ hoàn thành giao dịch (transaction finality) nhanh hơn.
Ví dụ: True
Loại: True/False

41. ALLOW_TVM_ISTANBUL

Mô tả: Bật các tính năng của bản nâng cấp Ethereum Istanbul trong TVM.
Ví dụ: True
Loại: True/False

44. ALLOW_MARKET_TRANSACTION

Mô tả: Bật hoặc tắt các giao dịch theo lệnh thị trường trên sàn giao dịch phi tập trung.
Ví dụ: True
Loại: True/False

45. MARKET_SELL_FEE

Mô tả: Sửa đổi khoản Phí được tính khi thực thi lệnh bán trên sàn giao dịch phi tập trung.
Ví dụ: [0] SUN.
Phạm vi: [0, 10 000 000 000] SUN

46. MARKET_CANCEL_FEE

Mô tả: Sửa đổi khoản Phí cho việc hủy bỏ một lệnh đang mở trên sàn giao dịch phi tập trung.
Ví dụ: [0] SUN.
Phạm vi: [0, 10 000 000 000] SUN

47. MAX_FEE_LIMIT

Mô tả: Sửa đổi fee_limit (Giới hạn Phí mạng) tối đa mà người dùng có thể thiết lập cho một giao dịch.
Ví dụ: [15 000 000 000] SUN - tức là 15,000 TRX.
Phạm vi: [0, 100 000 000 000 000 000] SUN

48. ALLOW_TRANSACTION_FEE_POOL

Mô tả: Kích hoạt hoặc vô hiệu hóa cơ chế hồ chứa Phí giao dịch (transaction fee pool mechanism).
Ví dụ: False
Loại: True/False

49. ALLOW_BLACKHOLE_OPTIMIZATION

Mô tả: Kích hoạt hoặc vô hiệu hóa một sự tối ưu hóa trong đó các token bị Đốt tiêu tốn lượng Năng lượng tối thiểu.
Ví dụ: True
Loại: True/False

51. ALLOW_NEW_RESOURCE_MODEL

Mô tả: Bật hoặc tắt mô hình tài nguyên mới (Staking 2.0).
Ví dụ: True
Loại: True/False

52. ALLOW_TVM_FREEZE

Mô tả: Bật hoặc tắt các lệnh TVM liên quan đến mô hình tài nguyên/Khóa TRX mới (Staking 2.0).
Ví dụ: True
Loại: True/False

53. ALLOW_ACCOUNT_ASSET_OPTIMIZATION

Mô tả: Bật tối ưu hóa cho cách lưu trữ số dư tài sản (TRC-10) của tài khoản.
Ví dụ: True
Loại: True/False

59. ALLOW_TVM_VOTE

Mô tả: Bật hoặc tắt khả năng cho các Hợp đồng thông minh thực hiện các hoạt động biểu quyết.
Ví dụ: True
Loại: True/False

60. ALLOW_TVM_COMPATIBLE_EVM

Mô tả: Bật hoặc tắt các tính năng tương thích của TVM với EVM.
Ví dụ: True
Loại: True/False

61. FREE_NET_LIMIT

Mô tả: Sửa đổi lượng Băng thông miễn phí mà mỗi tài khoản nhận được hàng ngày.
Ví dụ: [5000].
Phạm vi: [0, 100000]

62. TOTAL_NET_LIMIT

Mô tả: Sửa đổi tổng số Băng thông được cung cấp bởi mạng lưới từ số TRX bị Đóng băng.
Ví dụ: [43 200 000 000].
Phạm vi: [0, 1 000 000 000 000]

63. ALLOW_TVM_LONDON

Mô tả: Bật các tính năng của bản nâng cấp Ethereum London trong TVM.
Ví dụ: True
Loại: True/False

65. ALLOW_HIGHER_LIMIT_FOR_MAX_CPU_TIME_OF_ONE_TX

Mô tả: Cho phép đề xuất một giá trị tối đa cao hơn cho tham số MAX_CPU_TIME_OF_ONE_TX.
Ví dụ: True
Loại: True/False

66. ALLOW_ASSET_OPTIMIZATION

Mô tả: Kích hoạt hoặc vô hiệu hóa tối ưu hóa lưu trữ tài sản tài khoản.
Ví dụ: True
Loại: True/False

67. ALLOW_NEW_REWARD

Mô tả: Bật hoặc tắt thuật toán phần thưởng mới cho các SR và cử tri.
Ví dụ: True
Loại: True/False

68. MEMO_FEE

Mô tả: Sửa đổi khoản Phí được tính trên mỗi byte khi thêm bản ghi nhớ (memo) vào một giao dịch.
Ví dụ: [1 000 000] SUN - tức là 1 TRX.
Phạm vi: [0, 1 000 000 000] SUN

69. ALLOW_DELEGATE_OPTIMIZATION

Mô tả: Kích hoạt hoặc vô hiệu hóa tối ưu hóa cho lưu trữ ủy quyền tài nguyên (resource delegation storage).
Ví dụ: True
Loại: True/False

70. UNFREEZE_DELAY_DAYS

Mô tả: Sửa đổi số ngày tài sản bị khóa khi sử dụng cơ chế Khóa TRX mới.
Ví dụ: [14] Ngày.
Phạm vi: [1, 365] Ngày

71. ALLOW_OPTIMIZED_RETURN_VALUE_OF_CHAIN_ID

Mô tả: Bật tính năng tối ưu hóa cho giá trị trả về của opcode CHAINID.
Ví dụ: True
Loại: True/False

72. ALLOW_DYNAMIC_ENERGY

Mô tả: Bật hoặc tắt mô hình Năng lượng động.
Ví dụ: True
Loại: True/False

73. DYNAMIC_ENERGY_THRESHOLD

Mô tả: Sửa đổi ngưỡng tiêu thụ Năng lượng của hợp đồng trước khi áp dụng hình phạt động (dynamic penalty).
Ví dụ: [5 000 000 000].
Phạm vi: [0, 9223372036854775807]

74. DYNAMIC_ENERGY_INCREASE_FACTOR

Mô tả: Sửa đổi hệ số phần trăm theo đó chi phí Năng lượng sẽ tăng đối với một hợp đồng vượt quá ngưỡng.
Ví dụ: [2000].
Phạm vi: [0, 10000]

75. DYNAMIC_ENERGY_MAX_FACTOR

Mô tả: Sửa đổi hệ số nhân (multiplier) tối đa cho chi phí Năng lượng theo mô hình Năng lượng động.
Ví dụ: [34000].
Phạm vi: [0, 100000]

76. ALLOW_TVM_SHANGHAI

Mô tả: Bật các tính năng của bản nâng cấp Ethereum Shanghai trong TVM.
Ví dụ: True
Loại: True/False

77. ALLOW_CANCEL_ALL_UNFREEZE_V2

Mô tả: Bật khả năng hủy bỏ tất cả các yêu cầu Hủy đóng băng đang chờ xử lý trong Stake 2.0.
Ví dụ: True
Loại: True/False

78. MAX_DELEGATE_LOCK_PERIOD

Mô tả: Sửa đổi thời gian khóa tối đa (maximum lock-up period) cho việc ủy quyền tài nguyên.
Ví dụ: [864000].
Phạm vi: (86400, 10512000]

79. ALLOW_OLD_REWARD_OPT

Mô tả: Bật tính năng tối ưu hóa cho thuật toán rút phần thưởng cho hệ thống phần thưởng cũ.
Ví dụ: True
Loại: True/False

81. ALLOW_ENERGY_ADJUSTMENT

Mô tả: Bật hoặc tắt các chức năng điều chỉnh Năng lượng.
Ví dụ: True
Loại: True/False

82. MAX_CREATE_ACCOUNT_TX_SIZE

Mô tả: Sửa đổi kích thước giao dịch tối đa cho việc tạo một tài khoản mới.
Ví dụ: [1000].
Phạm vi: [500, 10000]

83. ALLOW_TVM_CANCUN

Mô tả: Bật các tính năng của bản nâng cấp Ethereum Cancun trong TVM.
Ví dụ: True
Loại: True/False

87. ALLOW_STRICT_MATH

Mô tả: Di chuyển các phép toán học TVM sang java.lang.StrictMath để đảm bảo tính nhất quán trên nhiều nền tảng.
Ví dụ: True
Loại: True/False

88. CONSENSUS_LOGIC_OPTIMIZATION

Mô tả: Bật hoặc tắt các tính năng tối ưu hóa trong logic đồng thuận.
Ví dụ: True
Loại: True/False

89. ALLOW_TVM_BLOB

Mô tả: Bật hoặc tắt hỗ trợ TVM cho các giao dịch blob (EIP-4844).
Ví dụ: True
Loại: True/False