Kỹ thuật tối ưu gas

Kỹ thuật tối ưu gas là gì?

Kỹ thuật tối ưu gas là các phương pháp giúp giảm tài nguyên tính toán và dung lượng lưu trữ blockchain cần thiết cho một giao dịch tiền mã hóa hoặc hợp đồng thông minh.

Trên Ethereum và các mạng tương thích với EVM khác, mỗi thao tác của Ethereum Virtual Machine đều có chi phí gas.

Đọc dữ liệu lưu trữ của hợp đồng, thay đổi trạng thái blockchain, sao chép dữ liệu, gọi hợp đồng khác, phát sự kiện và triển khai bytecode đều có thể tiêu thụ gas.

Người gửi giao dịch thường trả phí dựa trên lượng gas bị tính phí và giá gas hiệu dụng của giao dịch.

Công thức cơ bản là: Phí giao dịch = Gas bị tính phí × Giá gas hiệu dụng.

Tối ưu gas giúp giảm phần gas bị tính phí trong công thức này.

Việc tối ưu không trực tiếp kiểm soát giá thị trường của mỗi đơn vị gas; mức giá này thay đổi theo nhu cầu sử dụng không gian block.

Hợp đồng được tối ưu tốt có thể giảm chi phí cho người dùng, tăng số lượng hoạt động có thể đưa vào mỗi block, cải thiện độ tin cậy của giao dịch và giúp ứng dụng phi tập trung thiết thực hơn khi nhu cầu mạng cao.

Tuy nhiên, tối ưu gas không bao giờ được làm suy yếu quyền kiểm soát truy cập, độ an toàn của phép tính, biện pháp bảo vệ khỏi reentrancy, độ chính xác của kế toán hoặc các thuộc tính bảo mật khác.

Thông thường, phương án tối ưu tốt nhất là thiết kế đơn giản hơn, thực hiện ít công việc hơn thay vì viết mã phức tạp chỉ để tiết kiệm một lượng nhỏ gas.

Tại sao tối ưu gas quan trọng trong crypto?

Mỗi thao tác on-chain không cần thiết đều tạo ra chi phí cho người hoặc ứng dụng gửi giao dịch.

Mức chênh lệch nhỏ có thể không đáng kể với một giao dịch, nhưng sẽ trở nên đáng kể khi hợp đồng thông minh xử lý hàng nghìn hoặc hàng triệu lượt tương tác.

Lượng gas thấp hơn có thể giúp các giao dịch chuyển token, thao tác DeFi, hoạt động NFT, bỏ phiếu quản trị và trò chơi blockchain có chi phí hợp lý hơn.

Hợp đồng hiệu quả cũng có thể dễ xử lý hơn đối với validator và node vì cần ít thao tác đọc, ghi dữ liệu lưu trữ và tính toán hơn.

Tối ưu gas đặc biệt quan trọng với ứng dụng chạy vòng lặp lặp lại, cập nhật nhiều số dư, tạo hợp đồng mới hoặc gọi nhiều hệ thống bên ngoài trong một giao dịch.

Việc này cũng quan trọng với các chiến lược tiền mã hóa tự động vì chi phí thực thi cao có thể xóa sạch lợi nhuận dự kiến từ giao dịch hoặc thanh lý.

Tối ưu gas không thể đảm bảo giao dịch sẽ rẻ khi quy đổi sang tiền tệ quốc gia vì giá gas và giá thị trường của tiền mã hóa gốc vẫn có thể tăng.

Việc tối ưu giúp giảm lượng công việc mạng mà người dùng phải trả phí.

Tìm hiểu gas được sử dụng ở đâu

Nhà phát triển nên nắm rõ các nguồn tiêu thụ gas chính trước khi thay đổi mã hợp đồng thông minh.

Dữ liệu lưu trữ lâu dài thường là một trong những tài nguyên tốn kém nhất vì dữ liệu tạo ra phải tiếp tục là một phần của trạng thái blockchain.

Memory là dữ liệu tạm thời được dùng trong một lần thực thi và thường rẻ hơn dữ liệu lưu trữ lâu dài, dù chi phí tăng khi vùng memory được cấp phát mở rộng.

Calldata chứa dữ liệu đầu vào của giao dịch hoặc hàm bên ngoài và không trở thành memory có thể sửa đổi của hợp đồng trừ khi được sao chép.

Triển khai hợp đồng tiêu thụ gas để chạy mã khởi tạo và lưu bytecode runtime được tạo ra.

Lệnh gọi hợp đồng bên ngoài phát sinh thêm chi phí truy cập tài khoản, mã hóa đối số, xử lý dữ liệu trả về và công việc do hợp đồng được gọi thực hiện.

Các phép tính mật mã, nhật ký sự kiện, quá trình tạo hợp đồng và vòng lặp lớn cũng có thể đóng góp đáng kể vào tổng lượng gas sử dụng.

Tài liệu gas chính thức của Ethereum giải thích cách gas đo lường công việc tính toán cần thiết của giao dịch và thao tác EVM.

Đo lượng gas trước khi tối ưu

Nên bắt đầu tối ưu gas bằng cách đo lường thay vì dựa trên giả định.

Nhà phát triển nên ghi lại chi phí triển khai và chi phí runtime của các hàm quan trọng trước khi thay đổi mã.

Các bài kiểm thử cần bao gồm quy mô giao dịch thực tế, hành vi người dùng thông thường, đầu vào tối đa được hỗ trợ, các trường hợp thất bại và trạng thái blockchain bất thường.

Hàm chỉ tốn ít gas với một phần tử trong mảng có thể trở nên không an toàn hoặc quá đắt khi xử lý một nghìn phần tử.

Ảnh chụp lượng gas có thể dùng để so sánh chi phí hàm giữa các phiên bản mã và phát hiện mức tăng ngoài dự kiến.

Execution trace có thể cho thấy opcode, storage slot, lệnh gọi nội bộ và lệnh gọi bên ngoài nào tiêu thụ nhiều gas nhất.

Trình biên dịch Solidity có thể đưa ra ước tính gas, như mô tả trong tài liệu trình biên dịch, nhưng một số ước tính không khả dụng hoặc thiếu độ tin cậy khi quá trình thực thi phụ thuộc vào vòng lặp động hoặc hành vi của hợp đồng bên ngoài.

Kiểm thử trên blockchain cục bộ hoặc testnet công khai đang được duy trì có thể cung cấp số đo thực tế hơn.

Nhà phát triển nên tối ưu các luồng tốn kém mà người dùng thực sự thực hiện, thay vì dành thời gian cho đoạn mã hiếm khi được gọi.

Sử dụng phiên bản trình biên dịch Solidity hiện hành

Các phiên bản trình biên dịch Solidity mới hơn thường có cải tiến trong quá trình tạo mã, sửa lỗi tối ưu hóa, hỗ trợ opcode EVM mới và khắc phục vấn đề bảo mật.

Trang web Solidity chính thức liệt kê phiên bản 0.8.36 là phiên bản trình biên dịch mới nhất được phát hành vào tháng 7 năm 2026.

Trước khi chọn trình biên dịch cho môi trường production, nhà phát triển nên kiểm tra trang web Solidity chính thức và danh sách lỗi trình biên dịch đã biết.

Cần cố định phiên bản đã chọn trong cấu hình build để mọi nhà phát triển, hệ thống kiểm thử và quy trình triển khai đều tạo ra bytecode nhất quán.

Sử dụng pragma rộng mà không kiểm soát môi trường build thực tế có thể khiến các phiên bản trình biên dịch khác nhau tạo ra mã khác nhau.

Vẫn cần kiểm thử kỹ trình biên dịch mới hơn vì các tối ưu hóa và thay đổi ngôn ngữ có thể ảnh hưởng đến bytecode, chi phí triển khai và hành vi hợp đồng.

Bật và cấu hình trình tối ưu Solidity

Trình tối ưu Solidity đơn giản hóa biểu thức, loại bỏ thao tác không cần thiết, kết hợp phép tính lặp lại và có thể giảm cả kích thước bytecode triển khai lẫn lượng gas runtime.

Tài liệu về trình tối ưu Solidity giải thích rằng tối ưu hóa có thể giảm kích thước mã và chi phí thực thi.

Cài đặt runs của trình tối ưu thể hiện tần suất nhà phát triển dự kiến mã đã triển khai sẽ được thực thi.

Giá trị runs thấp thường chú trọng hơn đến việc giảm kích thước bytecode triển khai.

Giá trị runs cao thường cho phép trình biên dịch tạo mã có thể lớn hơn khi triển khai nhưng rẻ hơn trong các lần gọi runtime lặp lại.

Không có giá trị runs nào phù hợp nhất với mọi hợp đồng tiền mã hóa.

Hợp đồng được triển khai nhiều lần nhưng hiếm khi được gọi có thể cần cài đặt khác với hợp đồng dự kiến xử lý hàng triệu giao dịch.

Nhà phát triển nên so sánh một số cấu hình bằng các bài kiểm thử thực tế và đánh giá tổng chi phí trong toàn bộ vòng đời thay vì chỉ xét chi phí triển khai hoặc runtime.

Quy trình biên dịch via-IR có thể tạo ra các kiểu tối ưu khác với quy trình cũ, nhưng việc chuyển quy trình cần được xem là thay đổi build quan trọng và phải kiểm thử đầy đủ.

Giảm số lần ghi dữ liệu lưu trữ lâu dài

Ghi dữ liệu lưu trữ lâu dài thường là cơ hội lớn nhất để tiết kiệm gas.

Hợp đồng nên tránh lưu thông tin có thể được tính toán an toàn từ trạng thái hiện có hoặc do người dùng cung cấp khi cần.

Nên tránh ghi lặp lại cùng một giá trị nếu hợp đồng có thể kiểm tra trước rằng không cần thay đổi.

Hợp đồng cập nhật năm biến trạng thái riêng biệt có thể tốn kém hơn mô hình kế toán đơn giản hơn với ít thao tác ghi hơn.

Nhà phát triển cũng nên cân nhắc thông tin có cần sẵn có cho các hợp đồng thông minh khác hay chỉ cần cho ứng dụng off-chain.

Dữ liệu cần ảnh hưởng đến quá trình thực thi hợp đồng trong tương lai thường phải được lưu trong storage.

Thông tin chỉ cần cho ví, giao diện hoặc phân tích đôi khi có thể được ghi lại dưới dạng sự kiện.

Xóa storage có thể tạo khoản hoàn gas giới hạn theo quy tắc Ethereum hiện hành, nhưng khoản hoàn bị giới hạn và không nên được xem là cách khiến storage miễn phí.

Hợp đồng nên xóa trạng thái lỗi thời vì lý do thiết kế hợp lý, thay vì tạo dữ liệu không cần thiết với hy vọng nhận khoản hoàn sau này.

Lưu vào bộ nhớ đệm các lần đọc storage lặp lại

Đọc một storage slot nhiều lần tốn kém hơn so với đọc một lần rồi dùng lại giá trị cục bộ, nếu trạng thái nền không cần thay đổi giữa các lần đọc.

Ethereum phân biệt truy cập trạng thái cold và warm theo EIP-2929.

Lần đầu truy cập một storage slot chưa được sử dụng trong giao dịch là truy cập cold và bị tính phí cao hơn.

Các lần truy cập tiếp theo vào cùng slot trong giao dịch đó là warm và tốn ít phí hơn.

Ngay cả thao tác đọc storage warm cũng có thể tốn kém hơn việc sử dụng giá trị trên stack hoặc trong memory đã có sẵn cho hàm.

Hàm thường có thể sao chép biến trạng thái được dùng thường xuyên vào biến cục bộ, thực hiện các phép tính rồi chỉ ghi kết quả cuối cùng một lần.

Không nên áp dụng phương pháp này nếu lệnh gọi bên ngoài có thể thay đổi trạng thái liên quan hoặc khiến giá trị đã lưu vào bộ nhớ đệm bị lỗi thời.

Nhà phát triển nên tuân theo nguyên tắc checks-effects-interactions và phân tích kỹ reentrancy trước khi lưu trạng thái vào bộ nhớ đệm quanh các lệnh gọi bên ngoài.

Sắp xếp biến trạng thái vào cùng slot một cách thận trọng

Storage trên Ethereum được tổ chức thành các slot 32 byte.

Nhiều biến kiểu giá trị nhỏ có thể dùng chung một slot nếu thứ tự và tổng kích thước cho phép.

Ví dụ, một số giá trị số nguyên hoặc Boolean nhỏ có thể nằm trong cùng một slot thay vì chiếm nhiều slot riêng.

Tài liệu bố cục storage của Solidity giải thích cách biến, struct, mảng, kế thừa và việc sắp xếp biến vào cùng slot ảnh hưởng đến vị trí slot.

Vì vậy, thứ tự biến có thể làm thay đổi số slot mà hợp đồng cần dùng.

Tuy nhiên, dùng kiểu số nguyên nhỏ nhất có thể không phải lúc nào cũng rẻ hơn.

EVM thường thực hiện phép tính với word 256 bit, vì vậy kiểu số nguyên nhỏ hơn có thể cần thêm thao tác che bit hoặc chuyển đổi.

Việc sắp xếp vào cùng slot đem lại lợi ích rõ nhất khi một số giá trị trong slot thường được đọc hoặc ghi cùng nhau.

Chỉ cập nhật một giá trị trong slot dùng chung có thể đòi hỏi đọc slot, sửa một phần word rồi ghi lại giá trị tổng hợp.

Bố cục storage cũng là một phần của khả năng tương thích ở hợp đồng có thể nâng cấp, vì vậy nhà phát triển không nên sắp xếp lại các biến trạng thái hiện có chỉ để tiết kiệm gas sau khi triển khai.

Sử dụng biến constant và immutable

Giá trị không bao giờ thay đổi sau khi biên dịch thường nên được khai báo là

nếu Solidity cho phép.

Giá trị được chọn trong quá trình khởi tạo hợp đồng nhưng cố định sau đó có thể được khai báo là

.

Constant và immutable tránh truy cập storage lâu dài thông thường vì giá trị được nhúng hoặc lưu cùng mã hợp đồng.

Tài liệu hợp đồng Solidity chính thức giải thích sự khác nhau giữa các biến này và biến trạng thái thông thường.

Các ứng viên thường gặp gồm giá trị cấu hình cố định, địa chỉ vĩnh viễn, hằng số toán học và giới hạn không thể thay đổi sau khi triển khai.

Không nên đặt biến thành immutable nếu ứng dụng thực sự cần quản trị hoặc quy trình được ủy quyền khác để cập nhật biến.

Loại bỏ tính linh hoạt cần thiết chỉ để tiết kiệm gas có thể tạo ra vấn đề vận hành lớn hơn về sau.

Dùng calldata cho đầu vào bên ngoài chỉ đọc

Đối số của hàm bên ngoài không cần chỉnh sửa thường có thể sử dụng vùng dữ liệu

.

Calldata chỉ đọc và tránh phải sao chép toàn bộ dữ liệu đầu vào vào memory khi bắt đầu thực thi.

Hướng dẫn về vùng dữ liệu của Solidity khuyến nghị dùng calldata khi có thể vì cách này tránh sao chép và ngăn chỉnh sửa dữ liệu.

Kỹ thuật này đặc biệt hữu ích với mảng, chuỗi byte, chuỗi văn bản và struct được truyền cho hàm bên ngoài.

Memory vẫn phù hợp khi hợp đồng cần chỉnh sửa dữ liệu hoặc tạo giá trị mới trong bộ nhớ.

Không nên cho rằng đổi tham số hàm từ

sang kiểu số nguyên nhỏ hơn sẽ tự động giảm kích thước calldata.

Mã hóa ABI tiêu chuẩn thường đặt giá trị tĩnh vào các word 32 byte, còn kiểu nhỏ hơn có thể phát sinh thêm công việc chuyển đổi hoặc xác thực.

Cần xác nhận mức tiết kiệm gas bằng cách đo lường thay vì chỉ suy đoán từ tên kiểu dữ liệu ở cấp mã nguồn.

Giảm calldata của giao dịch

Mỗi byte trong calldata của giao dịch đều góp phần vào chi phí giao dịch nội tại.

Mảng không cần thiết, trường dữ liệu trùng lặp, chuỗi văn bản dài và cách mã hóa kém hiệu quả có thể làm giao dịch của người dùng tốn kém hơn.

Đôi khi nhà phát triển có thể thay các giá trị đầy đủ được lặp lại bằng mã định danh gọn hơn để hợp đồng ánh xạ đến cấu hình đã lưu.

Họ cũng có thể tránh gửi thông tin mà hợp đồng có thể suy ra an toàn từ trạng thái hiện có hoặc người gửi giao dịch.

Nén có thể hữu ích trong các hệ thống chuyên biệt, nhưng giải nén cũng tiêu thụ gas và có thể làm mất khoản tiết kiệm dự kiến.

Pectra đã kích hoạt EIP-7623, đưa ra mức sàn gas cao hơn cho giao dịch có nhiều dữ liệu.

Điều này khiến hiệu quả calldata đặc biệt quan trọng với giao dịch mang lượng dữ liệu lớn nhưng thực hiện tương đối ít thao tác EVM.

Nhà phát triển nên so sánh chi phí calldata gọn với lượng công việc thực thi bổ sung cần thiết để giải mã.

Dùng transient storage cho trạng thái chỉ cần trong giao dịch

Transient storage cho phép hợp đồng lưu các giá trị có thể được truy cập trong những lệnh gọi nội bộ suốt một giao dịch, nhưng tự động bị xóa khi giao dịch kết thúc.

Ethereum giới thiệu các opcode

và thông qua EIP-1153.

Transient storage rẻ hơn storage lâu dài vì dữ liệu không trở thành một phần của trạng thái blockchain vĩnh viễn.

Một trường hợp sử dụng phổ biến là khóa chống reentrancy chỉ cần thiết trong lúc một giao dịch đang chạy.

Các phiên bản Solidity hiện tại hỗ trợ biến trạng thái kiểu giá trị transient khi hợp đồng nhắm đến EVM Cancun hoặc phiên bản mới hơn tương thích.

Không nên dùng transient storage cho thông tin cần được giữ lại sang giao dịch tiếp theo.

Cũng cần hiểu kỹ hành vi của transient storage với lệnh gọi thông thường, delegate call và các hợp đồng có thể kết hợp.

Tài liệu transient storage của Solidity lưu ý rằng trạng thái transient chỉ tồn tại trong phạm vi giao dịch và có quy tắc sở hữu cụ thể giữa các loại lệnh gọi.

Nhà phát triển không nên thay thế cơ chế bảo mật đã được chứng minh bằng transient storage cho đến khi triển khai mới được kiểm thử và kiểm toán kỹ lưỡng.

Dùng custom error thay cho chuỗi lỗi revert dài

Custom error là phương thức tiết kiệm gas để trả về thông tin lỗi có cấu trúc.

Chuỗi revert dài trở thành một phần của bytecode hợp đồng đã triển khai và tạo dữ liệu trả về được mã hóa khi điều kiện thất bại.

Custom error sử dụng selector bốn byte cùng các tham số được khai báo, có thể giảm kích thước triển khai và chi phí của luồng thất bại.

Tài liệu custom error của Solidity mô tả đây là cơ chế xử lý lỗi tiện lợi và tiết kiệm gas.

Tên lỗi và tham số vẫn cần rõ ràng để ví, nhà phát triển và hệ thống giám sát có thể chẩn đoán vấn đề.

Loại bỏ toàn bộ thông tin lỗi hữu ích có thể tiết kiệm một lượng gas nhỏ nhưng khiến việc điều tra giao dịch tiền mã hóa thất bại khó khăn hơn nhiều.

Tối ưu vòng lặp và xử lý mảng

Vòng lặp có thể trở nên cực kỳ tốn kém khi số lần lặp phụ thuộc vào một mảng hoặc tập hợp lưu trữ có thể tăng mà không có giới hạn nghiêm ngặt.

Vòng lặp không giới hạn có thể cuối cùng cần nhiều gas hơn mức một giao dịch có thể cung cấp, khiến một hàm quan trọng của hợp đồng không thể sử dụng.

Nếu có thể, nên chia khối lượng công việc lớn thành các batch có giới hạn.

Vòng lặp liên tục đọc độ dài mảng từ storage đôi khi có thể lưu độ dài đó vào một biến cục bộ.

Cũng có thể lưu các giá trị storage được dùng trong mỗi lần lặp vào bộ nhớ đệm nếu việc đó an toàn.

Nhà phát triển có thể dùng phép tính số học

cho biến đếm vòng lặp chỉ khi chứng minh được rằng tràn số là không thể xảy ra.

Các trình biên dịch Solidity hiện đại đã tối ưu một số mẫu vòng lặp phổ biến, vì vậy cần benchmark thay đổi thủ công trước khi áp dụng.

Phân chia công việc qua nhiều giao dịch có thể cải thiện độ tin cậy, nhưng hợp đồng phải theo dõi tiến độ an toàn và ngăn bỏ sót, lặp lại hoặc đảo thứ tự công việc.

Tránh các lệnh gọi bên ngoài trùng lặp

Gọi một hợp đồng khác tiêu thụ gas và khiến giao dịch phụ thuộc vào hành vi thực thi của hợp đồng được gọi.

Hàm nên tránh yêu cầu cùng một giá trị bên ngoài nhiều lần nếu có thể gọi một lần an toàn rồi dùng lại kết quả.

Đôi khi có thể kết hợp nhiều thao tác liên quan thành một lệnh gọi hợp đồng.

Tuy nhiên, gộp thao tác làm tăng lượng công việc có thể cùng thất bại và có thể tạo payload calldata lớn hơn.

Lệnh gọi bên ngoài cũng có thể tạo điều kiện cho reentrancy, trả về dữ liệu bất ngờ, tiêu thụ nhiều gas hoặc khiến toàn bộ giao dịch revert.

Không bao giờ nên đánh đổi việc tiết kiệm gas để loại bỏ kiểm tra giá trị trả về hoặc cơ chế xử lý lệnh gọi an toàn.

Nhà phát triển cần xác định liệu giá trị bên ngoài đã lưu vào bộ nhớ đệm còn hợp lệ trong suốt quá trình thực thi hay không và liệu hệ thống bên ngoài có thể thay đổi giá trị thông qua callback hay không.

Dùng sự kiện thay cho storage khi phù hợp

Sự kiện ghi lại thông tin trong nhật ký giao dịch và có thể được ứng dụng off-chain lập chỉ mục.

Ghi sự kiện thường ít tốn kém hơn lưu thông tin tương đương trong trạng thái hợp đồng.

Sự kiện phù hợp với lịch sử hoạt động, thông báo giao diện, phân tích và dữ liệu mà quá trình thực thi hợp đồng thông minh sau này không cần đọc.

Sự kiện không thể thay thế trạng thái quyết định số dư, quyền sở hữu, quyền hạn, khoản nợ, tài sản thế chấp hoặc hành vi khác của hợp đồng.

Hợp đồng thông minh thường không thể truy xuất nhật ký lịch sử trong quá trình thực thi EVM thông thường.

Hệ thống chỉ lưu thông tin kế toán quan trọng trong sự kiện sẽ cần một dịch vụ off-chain để khôi phục dữ liệu và không thể thực thi trực tiếp dữ liệu đó on-chain.

Cũng cần thiết kế cẩn thận các tham số sự kiện vì topic được lập chỉ mục và dữ liệu log có chi phí gas cũng như đặc tính tìm kiếm khác nhau.

Giảm kích thước triển khai hợp đồng

Triển khai hợp đồng phát sinh phí cho việc chạy logic khởi tạo và lưu bytecode runtime.

Hàm không dùng đến, logic trùng lặp, chuỗi revert dài và dữ liệu nhúng có thể làm tăng chi phí triển khai.

Nhà phát triển nên loại bỏ mã chết và tránh nhập thư viện lớn nếu chỉ cần một phần nhỏ của thư viện đó.

Thư viện bên ngoài có thể giảm bytecode trùng lặp giữa nhiều lần triển khai, nhưng việc gọi chúng có thể tạo thêm chi phí runtime và phụ thuộc vận hành.

Mẫu factory và clone có thể giảm chi phí triển khai nhiều phiên bản hợp đồng tương tự bằng cách dùng chung mã triển khai.

Mẫu proxy hỗ trợ nâng cấp và triển khai lặp lại, nhưng làm tăng chi phí delegate call và tạo ra các vấn đề nghiêm trọng về bố cục storage, quản trị và bảo mật.

Ethereum giới hạn bytecode runtime được triển khai thông thường theo EIP-170, trong khi EIP-3860 đo lường và giới hạn mã khởi tạo.

Chỉ tách mã để nằm dưới giới hạn kích thước có thể làm tăng chi phí lệnh gọi, vì vậy cần đánh giá kiến trúc trong toàn bộ vòng đời hợp đồng.

Chọn đúng phiên bản EVM

Đầu ra của trình biên dịch phụ thuộc vào phiên bản EVM được chọn.

Trình biên dịch nhắm đến EVM mới hơn có thể sử dụng các chỉ thị không khả dụng trên mạng cũ.

Ví dụ, Shanghai giới thiệu chỉ thị

thông qua EIP-3855, cho phép đưa giá trị 0 vào stack bằng một chỉ thị nhỏ và ít tốn kém hơn.

Dencun giới thiệu

thông qua EIP-5656, cung cấp phương thức sao chép memory hiệu quả hơn.

Trình biên dịch hiện đại có thể tự động dùng các chỉ thị này khi được cấu hình cho mạng tương thích.

Thông thường, nhà phát triển không nên tự viết lại các tối ưu hóa của trình biên dịch bằng assembly.

Hợp đồng được biên dịch cho một đợt nâng cấp giao thức chưa kích hoạt trên mạng đích có thể không triển khai hoặc thực thi được.

Do đó, hệ thống build cần đặt đúng phiên bản EVM cho từng chain mục tiêu.

Chỉ cân nhắc access list sau khi kiểm thử

Access list cho phép giao dịch xác định các tài khoản và storage key dự kiến sẽ truy cập.

Các mục được liệt kê được xem là warm khi bắt đầu thực thi, giúp giảm mức phí truy cập cold về sau.

EIP-2930 tính phí cho từng địa chỉ và storage key có trong danh sách.

Access list chính xác có thể giảm chi phí cho một số giao dịch có thể dự đoán.

Danh sách không đầy đủ hoặc không cần thiết có thể làm tăng tổng phí vì người dùng phải trả cho các mục không đem lại đủ lợi ích hoặc không được sử dụng.

Access list có thể khó tạo khi đường thực thi chính xác phụ thuộc vào trạng thái blockchain thay đổi.

Nhà phát triển nên mô phỏng toàn bộ giao dịch có và không có access list thay vì cho rằng tải trước trạng thái lúc nào cũng rẻ hơn.

Gộp thao tác người dùng một cách thận trọng

Kết hợp nhiều thao tác trong một giao dịch có thể tránh phải trả phí cơ bản của giao dịch nhiều lần.

Ví dụ, ứng dụng có thể cho phép người dùng phê duyệt và thực hiện thao tác trong một quy trình phối hợp.

Pectra đã kích hoạt EIP-7702, cho phép tài khoản sở hữu bên ngoài ủy quyền thực thi cho mã hợp đồng thông minh và hỗ trợ các tính năng ví như gộp giao dịch và tài trợ gas.

Gộp giao dịch không tự động giảm mọi chi phí thực thi vì từng thao tác vẫn cần thực hiện công việc hợp đồng của mình.

Batch lớn có thể vượt giới hạn gas thực tế, tạo thêm calldata hoặc khiến mọi thao tác revert nếu một bước thất bại.

Ứng dụng nên xác định có cho phép hoàn tất một phần hay không và cách báo cáo các thao tác phụ thất bại.

Cần xem xét kỹ việc ủy quyền của ví và mã được ủy quyền vì hệ thống gộp có thể có quyền rộng đối với tài sản người dùng.

Sử dụng mạng Layer 2 khi phù hợp

Tối ưu ở cấp ứng dụng làm giảm số đơn vị gas tiêu thụ, trong khi mạng Layer 2 có thể giảm mức giá người dùng phải trả cho việc thực thi và dữ liệu.

Rollup xử lý hoạt động bên ngoài Ethereum mainnet rồi đăng dữ liệu hoặc bằng chứng trở lại Ethereum.

Dencun giới thiệu giao dịch mang blob thông qua EIP-4844, tạo cho rollup một kênh dữ liệu chuyên biệt và tạm thời.

Pectra và Fusaka sau đó tiếp tục mở rộng khả năng mở rộng quy mô và tính khả dụng của dữ liệu trên Ethereum.

Hướng dẫn mới nhất dành cho nhà phát triển Ethereum giải thích cách các nâng cấp gần đây làm thay đổi phí mainnet, khả năng tài khoản và kinh tế của rollup.

Triển khai lên mạng Layer 2 không loại bỏ nhu cầu tối ưu hợp đồng vì storage và tính toán không cần thiết vẫn làm tăng phí người dùng và giảm dung lượng mạng.

Nhà phát triển cũng nên đánh giá yêu cầu về bridge, rút tài sản, thanh khoản, bảo mật và khả năng tương tác trước khi chọn mạng.

Chỉ dùng inline assembly khi cần thiết

Inline assembly có thể giúp nhà phát triển kiểm soát chính xác các thao tác EVM và đôi khi giảm gas.

Cách này cũng loại bỏ hoặc bỏ qua một số kiểm tra kiểu dữ liệu, biện pháp bảo vệ memory và tính năng an toàn cấp cao hơn của Solidity.

Một đoạn assembly ngắn có thể khó hiểu đối với người đánh giá và gây lỗi bộ nhớ, mã hóa sai hoặc hành vi gọi không an toàn.

Trình biên dịch có thể đã tối ưu Solidity thông thường thành mã hiệu quả tương đương cách triển khai thủ công.

Vì vậy, chỉ nên dùng assembly cho các nút thắt đã được đo lường, mật mã chuyên biệt, xử lý dữ liệu cấp thấp hoặc chức năng Solidity không thể biểu đạt hiệu quả.

Mỗi tối ưu hóa bằng assembly cần có bài kiểm thử so sánh đầu ra với cách triển khai tham chiếu rõ ràng.

Đánh giá bảo mật độc lập đặc biệt quan trọng khi assembly kiểm soát số dư token, chữ ký, quyền hạn hoặc lệnh gọi bên ngoài.

Không đánh đổi bảo mật để tiết kiệm gas

Hợp đồng rẻ hơn không phải là hợp đồng tốt hơn nếu có thể làm mất tiền mã hóa của người dùng.

Nhà phát triển không nên loại bỏ kiểm tra quyền truy cập, xác thực đầu vào, bảo vệ reentrancy, xác minh thời hạn, bảo vệ trượt giá hoặc kiểm tra kế toán chỉ để tiết kiệm gas.

Chỉ nên sử dụng phép tính unchecked khi có thể chứng minh bằng toán học rằng tràn số và thiếu số không thể xảy ra trong mọi điều kiện có thể tiếp cận.

Gộp nhiều biến vào một giá trị nén có thể tiết kiệm storage nhưng làm tăng nguy cơ lỗi thao tác bit.

Sử dụng proxy có thể giảm chi phí triển khai nhưng tạo ra rủi ro về quyền nâng cấp và xung đột storage.

Chữ ký off-chain có thể giảm số giao dịch nhưng đòi hỏi xử lý chính xác nonce, thời hạn, phân tách miền và bảo vệ chống phát lại.

Mỗi tối ưu hóa cần được đánh giá về khả năng đọc, kiểm toán, rủi ro vận hành và bảo trì sau này, ngoài chi phí gas.

Các lỗi tối ưu gas thường gặp

Một lỗi phổ biến là chọn kiểu số nguyên nhỏ hơn nhưng không sắp xếp chúng cùng các giá trị khác vào chung slot.

EVM hoạt động với word 256 bit, vì vậy kiểu nhỏ hơn có thể không tự giảm chi phí runtime.

Một lỗi khác là sao chép toàn bộ calldata vào memory dù hàm chỉ cần đọc dữ liệu.

Lỗi thứ ba là xóa storage chỉ để cố nhận khoản hoàn trong khi dự định tạo lại cùng trạng thái sau đó.

Lỗi thứ tư là dùng vòng lặp không giới hạn trên mảng storage tăng dần.

Lỗi thứ năm là chọn runs của trình tối ưu ở mức cao mà không so sánh chi phí triển khai và runtime.

Lỗi thứ sáu là tự viết assembly trước khi phân tích hiệu năng hợp đồng.

Lỗi thứ bảy là cho rằng một tối ưu hóa vẫn phù hợp sau khi nâng cấp trình biên dịch hoặc mạng làm thay đổi hành vi opcode.

Lỗi thứ tám là chỉ đo giao dịch thành công mà bỏ qua các luồng revert tốn kém.

Lỗi thứ chín là xem ước tính gas thấp hơn như bằng chứng cho thấy hai cách triển khai có logic nghiệp vụ và bảo mật giống hệt nhau.

Cách xây dựng quy trình tối ưu gas

Quy trình đáng tin cậy bắt đầu bằng việc xác định hành vi cần có và các thuộc tính bảo mật của hợp đồng.

Nhóm phát triển nên tạo các bài kiểm thử chức năng trước khi bắt đầu tối ưu cấp thấp.

Sau đó, nhóm cần đo chi phí triển khai và lượng gas sử dụng cho từng luồng giao dịch quan trọng.

Thông qua phân tích hiệu năng, cần xác định các thao tác ghi storage, vòng lặp, đầu vào calldata và lệnh gọi bên ngoài tốn kém nhất.

Nhà phát triển có thể đơn giản hóa kiến trúc, giảm thay đổi trạng thái, chọn vùng dữ liệu phù hợp và bật các cài đặt tối ưu hóa trình biên dịch đã được kiểm thử.

Mỗi thay đổi cần được đo lường so với phiên bản ban đầu và đánh giá về rủi ro bảo mật mới.

Các bài kiểm thử hồi quy gas nên được giữ lại trong dự án để quá trình phát triển sau này không âm thầm xóa bỏ phần tiết kiệm.

Bytecode production cuối cùng cần được biên dịch bằng trình biên dịch đã cố định phiên bản, cấu hình được xác minh, mục tiêu EVM chính xác và phiên bản dependency đã được xem xét.

Hợp đồng tiền mã hóa có giá trị cao nên được kiểm toán bảo mật độc lập, ngay cả khi mã đã tối ưu vượt qua các bài kiểm thử nội bộ.

Câu hỏi thường gặp

Kỹ thuật tối ưu gas nào tốt nhất?

Thông thường, kỹ thuật hiệu quả nhất là giảm thao tác storage lâu dài và đơn giản hóa lượng công việc on-chain mà mỗi giao dịch thực hiện.

Trình tối ưu Solidity có luôn giảm gas không?

Không. Cài đặt tối ưu có thể giảm gas runtime nhưng làm tăng chi phí triển khai, vì vậy nhà phát triển nên kiểm thử toàn bộ vòng đời của hợp đồng.

Cài đặt runs của trình tối ưu có ý nghĩa gì?

Cài đặt này cho trình biên dịch biết tần suất dự kiến thực thi mã runtime và ảnh hưởng đến sự đánh đổi giữa kích thước triển khai với chi phí thực thi lặp lại.

Storage có tốn kém hơn memory không?

Có. Storage lâu dài thường tốn kém hơn nhiều vì dữ liệu tiếp tục là một phần của trạng thái blockchain sau khi giao dịch kết thúc.

Calldata có rẻ hơn memory không?

Calldata có thể rẻ hơn với đầu vào bên ngoài chỉ đọc vì hợp đồng có thể truy cập dữ liệu mà không cần sao chép toàn bộ vào memory trước.

Kiểu số nguyên nhỏ hơn có luôn tiết kiệm gas không?

Không. Chúng hữu ích nhất khi nhiều giá trị có thể được sắp xếp vào cùng một storage slot, còn các số nguyên nhỏ đứng riêng có thể cần thêm thao tác chuyển đổi.

Tại sao nhà phát triển nên lưu giá trị storage vào bộ nhớ đệm?

Việc lưu vào bộ nhớ đệm có thể tránh đọc storage lặp lại khi giá trị không đổi và có thể được sử dụng lại an toàn từ stack hoặc memory.

Transient storage là gì?

Transient storage là storage EVM chỉ tồn tại trong phạm vi một giao dịch, tự động được xóa và có thể hỗ trợ trạng thái tạm thời ít tốn kém hơn, chẳng hạn như khóa chống reentrancy.

Custom error có rẻ hơn chuỗi revert không?

Custom error thường tiết kiệm gas hơn vì sử dụng selector gọn và tham số được mã hóa thay vì lưu trữ rồi trả về chuỗi văn bản dài.

Sự kiện có thể thay thế storage không?

Sự kiện chỉ có thể thay thế storage đối với thông tin mà quá trình thực thi hợp đồng thông minh trong tương lai không cần đọc hoặc thực thi.

Xóa storage có hoàn lại toàn bộ chi phí gas không?

Không. Khoản hoàn khi xóa storage bị giới hạn và chịu mức trần hoàn gas trên toàn giao thức.

Nhà phát triển có nên dùng phép tính unchecked để tiết kiệm gas không?

Chỉ nên dùng phép tính unchecked khi có thể chứng minh rằng tràn số hoặc thiếu số là không thể xảy ra, đồng thời lập luận an toàn được ghi lại và kiểm thử.

Gộp giao dịch có luôn tiết kiệm gas không?

Không. Gộp giao dịch có thể giảm chi phí giao dịch lặp lại nhưng cũng có thể làm tăng calldata, độ phức tạp thực thi và rủi ro thất bại toàn bộ.

Mạng Layer 2 có thể thay thế việc tối ưu hợp đồng không?

Không. Phí mạng thấp hơn có thể giảm chi phí người dùng, nhưng hợp đồng kém hiệu quả vẫn lãng phí dung lượng thực thi và tốn kém hơn hợp đồng được tối ưu trên cùng mạng.

Access list có luôn giảm gas không?

Không. Các mục trong access list có chi phí riêng và có thể làm tăng phí nếu không chính xác hoặc không cần thiết.

Inline assembly có luôn dùng ít gas hơn không?

Không. Trình biên dịch có thể tạo ra mã hiệu quả tương đương, trong khi assembly thiếu an toàn có thể gây ra vấn đề nghiêm trọng về bảo mật và bảo trì.

Nhà phát triển có thể đo lượng gas sử dụng như thế nào?

Họ có thể dùng ước tính của trình biên dịch, ảnh chụp gas tự động, kiểm thử giao dịch cục bộ, execution trace và công cụ phân tích hiệu năng.

Tại sao chi phí gas có thể thay đổi sau khi nâng cấp mạng?

Các đợt nâng cấp Ethereum có thể bổ sung opcode, định giá lại thao tác hiện có, thay đổi quy tắc calldata hoặc giới thiệu tính năng lưu trữ và memory hiệu quả hơn.

Tối ưu gas có thể ngăn phí mạng cao không?

Việc này làm giảm số đơn vị gas tiêu thụ nhưng không thể ngăn giá gas thị trường tăng khi nhiều người dùng cạnh tranh không gian block.

Hợp đồng rẻ nhất có luôn là hợp đồng tốt nhất không?

Không. Tính chính xác, bảo mật, khả năng đọc và khả năng bảo trì quan trọng hơn khoản tiết kiệm gas nhỏ.

Kết luận

Kỹ thuật tối ưu gas giúp giảm tài nguyên tính toán, storage, calldata và triển khai cần thiết cho hợp đồng thông minh tiền mã hóa.

Phần tiết kiệm lớn nhất thường đến từ việc giảm thao tác ghi storage lâu dài, lưu an toàn các lần đọc storage vào bộ nhớ đệm, chọn đúng vùng dữ liệu, giảm calldata không cần thiết và tránh lệnh gọi bên ngoài trùng lặp.

Trình biên dịch Solidity hiện đại có thể tự động tối ưu bytecode, nhưng cần chọn cài đặt tối ưu bằng cách đo lường thực tế thay vì phỏng đoán.

Các tính năng Ethereum hiện tại như transient storage,

, , mã tài khoản được ủy quyền và cách định giá calldata mới đã làm thay đổi cách nhà phát triển nên tiếp cận việc tối ưu.

Nhà phát triển nên nhắm đến đúng phiên bản EVM và cập nhật trình biên dịch, bài kiểm thử cũng như kiến thức về quy tắc giao thức.

Các kỹ thuật như sắp xếp biến vào cùng slot, custom error, vòng lặp có giới hạn, gộp thao tác, sự kiện, thư viện và triển khai trên Layer 2 có thể giảm chi phí nếu phù hợp với thiết kế ứng dụng.

Access list, proxy, inline assembly, phép tính unchecked và storage nén cần được sử dụng thận trọng hơn vì lợi ích gas nhỏ có thể đi kèm độ phức tạp hoặc rủi ro đáng kể.

Mỗi tối ưu hóa cần được đo lường trong quá trình triển khai, thực thi thành công, các luồng thất bại và suốt thời gian sử dụng hợp đồng.

Không bao giờ được loại bỏ biện pháp kiểm tra bảo mật chỉ để giảm số liệu gas.

Chiến lược tối ưu gas hiệu quả nhất là chỉ thực hiện lượng công việc on-chain tối thiểu cần thiết để vận hành tiền mã hóa an toàn và có thể xác minh.