Tối ưu gas

Tối ưu gas là gì?

Tối ưu gas là quá trình giảm tài nguyên blockchain cần thiết để triển khai hoặc thực thi hợp đồng thông minh tiền mã hóa.

Trên Ethereum, mỗi giao dịch và thao tác của Ethereum Virtual Machine đều tiêu thụ một lượng gas được đo lường.

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

Cách tính 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 lượng gas bị tính phí bằng cách làm cho mã hợp đồng, việc sử dụng storage, dữ liệu giao dịch và luồng thực thi hiệu quả hơn.

Việc này không trực tiếp kiểm soát giá gas, vốn thay đổi theo nhu cầu về dung lượng blockchain.

Hợp đồng được tối ưu phù hợp có thể giúp các giao dịch chuyển token, thao tác DeFi, hoạt động quản trị, hoạt động NFT và các giao dịch crypto khác có chi phí hợp lý hơn.

Tuy nhiên, tối ưu gas không bao giờ được loại bỏ bước kiểm tra bảo mật hoặc khiến hành vi của hợp đồng khó hiểu.

Mục tiêu là thực hiện lượng công việc on-chain an toàn và có thể xác minh ở mức tối thiểu mà ứng dụng yêu cầu.

Tối ưu gas hoạt động như thế nào?

Ethereum tính lượng gas khác nhau cho từng loại công việc tính toán và thao tác liên quan đến trạng thái.

Các phép tính đơn giản thường ít tốn kém, trong khi thay đổi storage lâu dài, tạo hợp đồng, thao tác mật mã và lệnh gọi bên ngoài có thể tốn kém hơn đáng kể.

Tài liệu gas chính thức của Ethereum giải thích rằng gas đo lường công việc tính toán cần thiết để xử lý giao dịch blockchain.

Tối ưu gas bắt đầu bằng việc xác định thao tác nào tiêu thụ nhiều gas nhất và xem liệu ứng dụng có thể thực hiện ít công việc hơn mà không làm thay đổi hành vi dự kiến hay không.

Nhà phát triển có thể giảm các lần đọc storage lặp lại, gộp thay đổi trạng thái, rút ngắn dữ liệu giao dịch, loại bỏ phép tính trùng lặp hoặc sử dụng tính năng EVM hiệu quả hơn.

Trình biên dịch cũng có thể chuyển mã nguồn Solidity thành bytecode hiệu quả hơn.

Một số tối ưu hóa giảm chi phí triển khai hợp đồng, trong khi các cách khác giảm chi phí cho mỗi lần người dùng tương tác.

Phương pháp phù hợp nhất phụ thuộc vào tần suất triển khai hợp đồng và mức độ thường xuyên các hàm được gọi.

Tối ưu gas và tối ưu giá gas

Tối ưu gas và tối ưu giá gas tác động đến những phần khác nhau của phí giao dịch.

Tối ưu gas làm giảm số đơn vị gas mà giao dịch tiêu thụ.

Tối ưu giá gas nhằm gửi giao dịch vào lúc mỗi đơn vị gas có chi phí thấp hơn.

Hợp đồng tiêu thụ 100,000 gas vẫn cần nhiều tài nguyên tính toán hơn hợp đồng thực hiện cùng tác vụ an toàn với 60,000 gas.

Tuy nhiên, hợp đồng rẻ hơn vẫn có thể tạo ra phí cao khi quy đổi sang tiền tệ quốc gia nếu mạng tắc nghẽn hoặc giá trị ETH cao.

Đôi khi người dùng có thể giảm giá gas bằng cách chờ nhu cầu mạng hạ nhiệt, nhưng nhà phát triển kiểm soát lượng gas sử dụng thông qua thiết kế hợp đồng và ứng dụng.

Kết hợp cả hai phương pháp có thể giảm tổng chi phí giao dịch hiệu quả hơn so với chỉ dựa vào một phương pháp.

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

Chi phí giao dịch cao có thể khiến người dùng không thể tương tác với ứng dụng tiền mã hóa, ngay cả khi dịch vụ nền tảng hữu ích.

Mức giảm gas nhỏ có ý nghĩa kinh tế đáng kể khi cùng một hàm được thực thi hàng nghìn hoặc hàng triệu lần.

Lượng gas thấp hơn có thể giúp người dùng có số dư crypto nhỏ dễ tiếp cận hơn.

Điều này cũng có thể giúp giao dịch nhạy cảm về thời gian cạnh tranh cơ hội được đưa vào block mà không cần tổng phí quá lớn.

Hiệu quả gas đặc biệt quan trọng với chiến lược tiền mã hóa tự động vì chi phí thực thi có thể vượt lợi nhuận dự kiến từ một giao dịch hoặc đợt thanh lý.

Hợp đồng hiệu quả cũng sử dụng ít dung lượng block có giới hạn hơn, cho phép mạng đưa nhiều giao dịch hơn vào tài nguyên sẵn có.

Vì vậy, tối ưu hóa có thể mang lại lợi ích cho cả người dùng cá nhân lẫn hệ sinh thái blockchain nói chung.

Đo lượng gas trước khi thay đổi mã

Nhà phát triển nên đo lượng gas tiêu thụ trước khi quyết định phần nào của hợp đồng cần tối ưu.

Mã nguồn có vẻ kém hiệu quả có thể đã được trình biên dịch đơn giản hóa.

Phím tắt ở cấp mã nguồn cũng có thể tạo ra bytecode tốn kém hơn cách triển khai rõ ràng hơn.

Báo cáo gas cần bao gồm chi phí triển khai hợp đồng, giao dịch thành công, giao dịch bị hoàn nguyên, đầu vào kích thước tối đa và các nhánh thực thi hiếm gặp.

Hàm tốn ít gas với một người dùng có thể trở nên quá đắt khi xử lý mảng lớn hoặc nhiều mục storage.

Ảnh chụp gas tự động có thể so sánh chi phí giữa các phiên bản phần mềm và phát hiện mức tăng bất ngờ.

Execution trace có thể xác định opcode, storage slot, việc mở rộng memory và lệnh gọi hợp đồng bên ngoài gây tốn kém.

Tài liệu trình biên dịch Solidity mô tả đầu ra, cài đặt tối ưu hóa và ước tính gas hiện có của trình biên dịch.

Nhà phát triển nên xem các mức ước tính là thông tin tham khảo vì vòng lặp động và lệnh gọi bên ngoài có thể khiến lượng gas thực tế phụ thuộc vào trạng thái blockchain.

Tối ưu kiến trúc hợp đồng thông minh

Phần tiết kiệm gas lớn nhất thường đến từ việc thay đổi kiến trúc hợp đồng thay vì viết lại từng biểu thức.

Hợp đồng lưu thông tin không cần thiết vẫn sẽ tốn kém ngay cả khi các phép tính được tối ưu rất tốt.

Nhà phát triển nên xác định thông tin nào cần được thực thi on-chain và thông tin nào có thể tính toán hoặc lập chỉ mục bên ngoài hợp đồng.

Số dư quan trọng, quyền hạn, hồ sơ quyền sở hữu và dữ liệu tài sản thế chấp thường cần trạng thái on-chain lâu dài.

Thông tin hiển thị, hoạt động lịch sử và dữ liệu phân tích có thể phù hợp với nhật ký sự kiện nếu quá trình thực thi hợp đồng trong tương lai không cần đọc chúng.

Nhà phát triển cũng nên cân nhắc liệu có thể biểu diễn nhiều lần cập nhật trạng thái bằng một giá trị tích lũy hoặc chỉ số kế toán hay không.

Mô hình trạng thái đơn giản hơn thường cần ít thao tác storage hơn và dễ kiểm toán hơn.

Giảm số lần ghi storage lâu dài

Storage lâu dài là một trong những tài nguyên tốn kém nhất mà hợp đồng thông minh Ethereum sử dụng.

Dữ liệu storage vẫn là một phần trạng thái Ethereum sau khi giao dịch hoàn tất.

Node mạng phải xử lý và duy trì mọi giá trị storage mới hoặc đã thay đổi.

Hợp đồng nên tránh ghi thông tin có thể tính toán an toàn từ trạng thái hiện có.

Hợp đồng cũng nên tránh ghi một giá trị nếu giá trị yêu cầu đã được lưu.

Đôi khi có thể thay nhiều lần cập nhật trung gian bằng một lần ghi storage cuối cùng sau khi hoàn tất toàn bộ phép tính.

Nhà phát triển không nên lưu các bản sao trùng lặp của cùng dữ liệu trừ khi việc này đem lại lợi ích bảo mật hoặc hiệu năng cần thiết.

Giảm số lần ghi storage thường tiết kiệm nhiều hơn các thay đổi nhỏ trong phép tính.

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

Đọc đi đọc lại cùng một giá trị từ storage có thể lãng phí gas nếu giá trị đó không thay đổi trong quá trình thực thi.

Hợp đồng thường có thể đọc giá trị một lần vào biến cục bộ rồi dùng lại trong các phép tính sau đó.

Ethereum áp dụng chi phí khác nhau cho truy cập trạng thái cold và warm theo EIP-2929.

Lần đầu truy cập một tài khoản hoặc storage slot trong giao dịch thường tốn kém hơn các lần truy cập tiếp theo vào cùng vị trí.

Tuy nhiên, ngay cả đọc storage warm cũng có thể tốn kém hơn sử dụng giá trị trên stack hoặc trong memory đã có sẵn.

Không nên lưu giá trị vào bộ nhớ đệm nếu lệnh gọi bên ngoài có thể thay đổi trạng thái hợp đồng liên quan trước khi sử dụng giá trị đó.

Cần xem xét reentrancy và hành vi callback mỗi khi lưu trạng thái vào bộ nhớ đệm qua một tương tác bên ngoài.

Sắp xếp biến trạng thái vào cùng slot

Storage Ethereum được chia thành các slot rộng 32 byte.

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

Tài liệu bố cục storage chính thức của Solidity giải thích cách biến được gán vào các storage slot.

Sắp xếp biến cẩn thận có thể giảm số slot mà hợp đồng cần sử dụng.

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

Dùng kiểu số nguyên nhỏ hơn không tự động giảm gas runtime vì EVM thường thực hiện phép tính bằng word 256 bit.

Việc sắp xếp vào cùng slot có lợi nhất khi nhiều giá trị trong slot thường được đọc hoặc ghi cùng nhau.

Chỉ cập nhật một trường trong slot dùng chung có thể cần thêm thao tác che bit và kết hợp giá trị.

Nhà phát triển không được sắp xếp lại biến storage hiện có trong hợp đồng có thể nâng cấp vì việc này có thể làm hỏng dữ liệu đã lưu.

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

Giá trị không bao giờ thay đổi không nên được lưu dưới dạng biến trạng thái mutable thông thường.

Solidity cho phép khai báo giá trị xác định tại thời điểm biên dịch bằng từ khóa

.

Giá trị được chọn khi khởi tạo hợp đồng và cố định sau đó thường có thể dùng từ khóa

.

Constant và immutable tránh thao tác đọc storage thông thường vì giá trị được nhúng vào hoặc tham chiếu thông qua bytecode hợp đồng.

Tài liệu Solidity về biến constant và immutable giải thích sự khác nhau giữa các khai báo này.

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

Biến cần giữ mutable nếu ứng dụng thực sự cần quản trị hoặc quản trị viên được ủy quyền cập nhật biến đó.

Chọn đúng vùng dữ liệu

Dữ liệu Solidity có thể nằm trong storage, memory, calldata hoặc transient storage tùy theo cách sử dụng.

Storage tồn tại qua nhiều giao dịch và thường là vùng tốn kém nhất.

Memory là vùng tạm thời, chỉ tồn tại trong lần thực thi hiện tại.

Calldata chứa đầu vào bên ngoài chỉ đọc được cung cấp cùng giao dịch hoặc lệnh gọi hợp đồng.

Transient storage tồn tại qua các lệnh gọi trong một giao dịch nhưng tự động bị xóa khi giao dịch kết thúc.

Chọn vùng dữ liệu tốn kém hơn mức cần thiết sẽ làm tăng chi phí giao dịch mà không cải thiện chức năng.

Tài liệu về vùng dữ liệu của Solidity giải thích tác động của các vùng này đến việc sao chép, khả năng thay đổi và thời gian tồn tại.

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

Tham số hàm bên ngoài không cần chỉnh sửa thường có thể được giữ trong calldata.

Dùng calldata có thể tránh sao chép các mảng lớn, chuỗi, chuỗi byte hoặc struct vào memory.

Cách này có thể giảm gas khi hàm chỉ cần kiểm tra các giá trị đã gửi.

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

Nhà phát triển cũng nên giảm dữ liệu giao dịch không cần thiết vì mỗi byte calldata đều góp phần vào chi phí gas nội tại.

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

Cần đo lường cẩn thận hiệu quả nén vì công việc giải mã dữ liệu có thể tốn nhiều hơn khoản tiết kiệm.

Tính đến cách định giá calldata hiện tại

Nâng cấp Pectra của Ethereum được kích hoạt vào ngày 7 tháng 5 năm 2025, bao gồm các thay đổi ảnh hưởng đến kinh tế của giao dịch nhiều dữ liệu.

EIP-7623 đưa ra mức sàn gas cao hơn cho giao dịch mang lượng calldata lớn nhưng thực hiện tương đối ít thao tác EVM.

Quy tắc này được thiết kế để giới hạn kích thước tối đa của các block nhiều dữ liệu và cải thiện khả năng chống chịu của mạng.

Nhà phát triển không nên cho rằng giao dịch có ít tính toán luôn rẻ nếu chứa payload calldata lớn.

Ứng dụng gửi bằng chứng, chữ ký, batch hoặc thông tin giao dịch đã nén nên benchmark theo hành vi giao thức hiện tại.

Các đợt nâng cấp mạng mới có thể thay đổi chi phí tương đối của calldata, tính toán, storage và những tài nguyên khác.

Dùng transient storage khi trạng thái chỉ mang tính tạm thời

Transient storage được thiết kế cho thông tin cần truy cập trong một giao dịch nhưng không nên được giữ lại sau đó.

Ethereum giới thiệu các opcode

và thông qua EIP-1153.

Giá trị transient tự động bị loại bỏ khi giao dịch kết thúc.

Transient storage rẻ hơn storage lâu dài vì dữ liệu không cần được lưu vĩnh viễn.

Một trường hợp sử dụng phổ biến là khóa chống reentrancy dùng chung qua nhiều lệnh gọi nội bộ hoặc bên ngoài trong một giao dịch.

Transient storage cũng có thể hỗ trợ kế toán tạm thời, callback và quyền chỉ tồn tại trong phạm vi giao dịch.

Không thể dùng transient storage thay storage cho số dư hoặc thông tin cần tiếp tục tồn tại trong giao dịch sau.

Nhà phát triển cần hiểu hành vi của transient storage qua lệnh gọi thông thường và delegate call trước khi dùng trong các ứng dụng crypto có thể kết hợp.

Sử dụng trình tối ưu Solidity

Trình tối ưu Solidity có thể đơ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 và giảm kích thước bytecode.

Tài liệu chính thức về trình tối ưu Solidity mô tả một số giai đoạn tối ưu được áp dụng cho mã đã tạo.

Trình tối ưu có thể giảm gas triển khai, gas runtime hoặc cả hai.

Cài đặt runs thể hiện ước tính về tần suất mã đã triển khai dự kiến được thực thi.

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

Giá trị runs cao thường cho phép triển khai lớn hơn để đổi lấy chi phí thực thi lặp lại thấp hơn.

Không có cài đặt runs nào phù hợp với mọi hợp đồng thông minh.

Nhà phát triển nên so sánh các cấu hình dựa trên kỳ vọng triển khai và mức sử dụng thực tế của hợp đồng.

Quy trình biên dịch dựa trên IR có thể cho kết quả khác quy trình cũ và cần được đánh giá bằng kiểm thử đầy đủ.

Sử dụng trình biên dịch hiện hành và đã xác minh

Các phiên bản trình biên dịch Solidity có thể bao gồm cải tiến gas, hỗ trợ EVM mới, sửa lỗi và khắc phục vấn đề bảo mật.

Nhà phát triển nên xem trang web Solidity chính thức trước khi chọn trình biên dịch để triển khai production.

Tài liệu Solidity nhìn chung khuyến nghị dùng phiên bản mới nhất đã phát hành, trừ khi dự án có lý do tương thích cụ thể để không sử dụng.

Nhà phát triển cũng nên xem danh sách lỗi trình biên dịch Solidity đã biết chính thức.

Cần cố định phiên bản trình biên dịch và cài đặt tối ưu trong quy trình build.

Biên dịch lại cùng mã nguồn bằng trình biên dịch khác có thể tạo ra bytecode và hành vi gas khác nhau.

Dùng custom error

Custom error thường tiết kiệm gas hơn chuỗi revert dài.

Chuỗi revert làm tăng bytecode triển khai và tạo văn bản được mã hóa khi giao dịch thất bại.

Custom error sử dụng selector gọn và có thể chứa tham số có cấu trúc.

Tài liệu custom error của Solidity giải thích cách hợp đồng định nghĩa và trả về custom error.

Lỗi vẫn cần cung cấp đủ thông tin để ví, người dùng và nhà phát triển hiểu nguyên nhân thất bại.

Loại bỏ thông tin lỗi hữu ích để tiết kiệm một lượng gas rất nhỏ có thể khiến việc hỗ trợ và kiểm toán ứng dụng khó hơn.

Tối ưu vòng lặp

Vòng lặp có thể trở nên tốn kém đến mức nguy hiểm khi số lần lặp phụ thuộc vào tập hợp 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 cuối cùng có thể cần nhiều gas hơn mức một giao dịch có thể cung cấp.

Nếu có thể, nên chia khối lượng công việc lớn thành các batch có quy mô dự đoán được.

Vòng lặp có thể lưu độ dài mảng hoặc giá trị được dùng lặp lại vào bộ nhớ đệm nếu thông tin đó không thể thay đổi trong quá trình thực thi.

Đôi khi nhà phát triển có thể dùng phép tính unchecked cho biến đếm vòng lặp nếu tràn số là không thể xảy ra về mặt toán học.

Mã unchecked cần đi kèm bài kiểm thử và giải thích an toàn rõ ràng.

Trình biên dịch hiện đại đã tối ưu nhiều mẫu vòng lặp phổ biến, vì vậy cần đo lường thay đổi thủ công thay vì mặc định rằng chúng rẻ hơn.

Giảm lệnh gọi hợp đồng bên ngoài

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

Hợp đồng nên tránh gọi lặp lại cùng một hàm bên ngoài nếu một lệnh gọi an toàn có thể cung cấp giá trị cần thiết.

Đôi khi có thể kết hợp nhiều thao tác liên quan trong một lệnh gọi hoặc một giao dịch.

Tuy nhiên, gộp thao tác có thể làm tăng calldata, độ phức tạp thực thi và khối lượng công việc bị hoàn nguyên khi một bước thất bại.

Lệnh gọi bên ngoài cũng tạo ra các vấn đề bảo mật liên quan đến reentrancy, dữ liệu trả về độc hại, mức tiêu thụ gas và lỗi bất ngờ.

Tối ưu gas không bao giờ được loại bỏ kiểm tra giá trị trả về hoặc các mẫu tương tác an toàn.

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

Sự kiện có thể ghi lại hoạt động blockchain cho ví, giao diện, hệ thống phân tích và trình lập chỉ mục off-chain.

Ghi sự kiện thường ít tốn kém hơn lưu cùng thông tin đó dưới dạng trạng thái hợp đồng lâu dài.

Sự kiện phù hợp khi 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 thông tin đó.

Lịch sử giao dịch, thông báo hoạt động và metadata mô tả có thể phù hợp với log.

Không nên chỉ lưu số dư, quyền hạn, khoản nợ, tài sản thế chấp và quyền sở hữu trong sự kiện vì quá trình thực thi EVM thông thường không thể tìm kiếm log lịch sử.

Hợp đồng phải giữ mọi thông tin cần thiết cho quyết định trong tương lai ở trạng thái có thể truy cập.

Giảm chi phí triển khai hợp đồng

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

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

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

Thư viện có thể giảm bytecode trùng lặp giữa một số hợp đồng, dù lệnh gọi thư viện bên ngoài tạo ra chi phí runtime và dependency riêng.

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

Mẫu proxy cũng có thể dùng chung mã triển khai, nhưng tạo ra chi phí delegate call, quyền nâng cấp và rủi ro về bố cục storage.

Nên chọn kiến trúc dựa trên nhu cầu bảo mật và vòng đời thay vì chỉ dựa vào gas triển khai.

Nhắm đến đúng phiên bản EVM

Trình biên dịch Solidity có thể tạo bytecode khác nhau tùy theo phiên bản EVM được chọn.

Phiên bản EVM mới hơn có thể hỗ trợ các chỉ thị hiệu quả hơn mà mạng cũ không thể thực thi.

Ví dụ, EIP-3855 giới thiệu chỉ thị

gọn hơn để đưa giá trị 0 lên stack.

EIP-5656 giới thiệu

để sao chép memory hiệu quả hơn.

Trình biên dịch hiện tại có thể tự động dùng các chỉ thị được hỗ trợ nếu được cấu hình cho đúng mạng.

Hợp đồng được biên dịch cho EVM mới hơn có thể thất bại trên mạng chưa kích hoạt bản nâng cấp cần thiết.

Do đó, nhà phát triển phải chọn mục tiêu EVM tương thích với chain dự kiến triển khai.

Tìm hiểu về khoản hoàn gas

Khoản hoàn gas có thể giảm lượng gas cuối cùng bị tính phí sau một số thao tác storage đủ điều kiện.

Quy tắc Ethereum hiện hành giới hạn khoản hoàn cấp giao thức ở mức 20% tổng gas đã sử dụng.

EIP-3529 giảm khoản hoàn khi xóa storage đủ điều kiện và loại bỏ khoản hoàn trước đây dành cho

.

Xóa storage vẫn có thể đem lại lợi ích giới hạn, nhưng không khiến việc tạo rồi xóa trạng thái trở nên miễn phí.

Nhà phát triển không nên ghi dữ liệu không cần thiết chỉ để xóa sau này nhằm nhận khoản hoàn.

Khoản hoàn cũng chỉ được áp dụng sau khi thực thi nên không thể ngăn lỗi hết gas.

không phải phương pháp tối ưu gas hiện đại và có hành vi bị giới hạn theo EIP-6780.

Cân nhắc gộp giao dịch một cách thận trọng

Gộp nhiều thao tác vào một giao dịch có thể tránh phải trả đi trả lại chi phí cơ bản của giao dịch.

Việc này cũng có thể cải thiện trải nghiệm người dùng bằng cách giảm số lần xác nhận trong ví.

Tuy nhiên, mỗi thao tác vẫn tiêu thụ lượng gas cần thiết cho tính toán và thay đổi trạng thái riêng.

Batch lớn có thể tiến sát giới hạn gas giao dịch hoặc tạo ra rủi ro thất bại toàn bộ với chi phí cao.

Ứng dụng nên xác định liệu thao tác phụ thất bại có làm toàn bộ batch revert hay cho phép hoàn tất một phần.

Cần thiết kế cẩn thận việc ủy quyền vì chữ ký batch có phạm vi rộng có thể cho phép nhiều thao tác hơn người dùng dự kiến.

EIP-7702 của Pectra, được nêu tại 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, hỗ trợ các tính năng ví như gộp giao dịch và tài trợ gas.

Cần xem xét logic tài khoản được ủy quyền kỹ như mọi hợp đồng khác có quyền kiểm soát tiền mã hóa.

Sử dụng mạng Layer 2 để tiết kiệm thêm

Tối ưu hợp đồng thông minh làm giảm lượng tính toán ứng dụng cần thực hiện.

Triển khai trên mạng Layer 2 phù hợp có thể giảm thêm mức giá phải trả cho hoạt động tính toán và dữ liệu liên quan.

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

Nâng cấp Dencun giới thiệu blob thông qua EIP-4844, tạo thị trường dữ liệu tạm thời riêng cho rollup.

Phí Layer 2 thấp hơn không loại bỏ nhu cầu tối ưu gas vì hợp đồng kém hiệu quả vẫn lãng phí dung lượng và tốn kém hơn hợp đồng hiệu quả trên cùng mạng.

Nhà phát triển cũng cần đánh giá bảo mật bridge, quy tắc rút tiền, thanh khoản, tính hoàn tất và cách tính phí riêng của mạng.

Tránh tối ưu cấp thấp quá sớm

Nhà phát triển không nên bắt đầu bằng inline assembly hoặc thao tác bit phức tạp trước khi đo mã Solidity thông thường.

Trình biên dịch có thể đã tạo bytecode hiệu quả từ cách triển khai cấp cao rõ ràng.

Assembly đôi khi giảm được gas cho thao tác chuyên biệt, nhưng bỏ qua một số biện pháp bảo vệ ở cấp ngôn ngữ.

Lỗi trong assembly có thể gây hỏng memory, mã hóa sai, lệnh gọi không an toàn hoặc khiến người dùng mất tiền.

Tối ưu cấp thấp cần có cách triển khai tham chiếu dễ đọc và bài kiểm thử chứng minh hành vi tương đương.

Đánh giá bảo mật độc lập đặc biệt quan trọng khi assembly xử lý số dư, 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ẻ nhất cũng vô ích nếu kẻ tấn công có thể đánh cắp tiền mã hóa của hợp đồng.

Không nên loại bỏ quyền kiểm soát truy cập, xác thực đầu vào, bảo vệ reentrancy, kiểm tra trượt giá, thời hạn và kiểm tra kế toán chỉ để giảm lượng gas sử dụng.

Chỉ dùng phép tính unchecked khi 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.

Storage nén có thể tiết kiệm gas nhưng làm tăng khả năng xảy ra lỗi ở cấp bit.

Proxy có thể giảm chi phí triển khai nhưng cũng tạo ra quyền nâng cấp tập trung hoặc xung đột storage.

Chữ ký off-chain có thể loại bỏ một giao dịch nhưng phát sinh yêu cầu về nonce, thời hạn, chống phát lại và phân tách miền.

Cần đánh giá quyết định tối ưu hóa về bảo mật, khả năng đọc, khả năng nâng cấp và rủi ro vận hành.

Kiểm thử tối ưu gas

Mỗi tối ưu hóa cần được kiểm thử so với cách triển khai ban đầu.

Kiểm thử chức năng cần xác nhận cả hai phiên bản tạo ra thay đổi trạng thái và đầu ra giống nhau.

Kiểm thử gas cần đo lượng sử dụng trung bình, mức sử dụng tối đa được hỗ trợ và các điều kiện thất bại.

Kiểm thử fuzz có thể tìm kiếm đầu vào bất thường làm lộ ra luồng thực thi tốn kém hoặc không chính xác.

Kiểm thử bất biến có thể xác nhận các thuộc tính kế toán và bảo mật thiết yếu vẫn được duy trì sau khi tối ưu.

Nhà phát triển cũng nên kiểm thử bằng đúng phiên bản trình biên dịch, cài đặt tối ưu và mục tiêu EVM dự kiến dùng trong production.

Nên lưu ảnh chụp gas để quá trình phát triển sau này không âm thầm đảo ngược phần cải thiện.

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

Một lỗi thường gặp là cho rằng mọi kiểu số nguyên nhỏ hơn đều giảm gas.

Một lỗi khác là sao chép dữ liệu bên ngoài chỉ đọc từ calldata vào memory mà không có nhu cầu chức năng.

Nhà phát triển cũng có thể tạo vòng lặp không giới hạn trên tập hợp storage, khiến vòng lặp không thể thực thi khi ứng dụng phát triển.

Một số nhóm tối ưu hàm hiếm khi dùng nhưng bỏ qua một khoản chi phí nhỏ lặp lại trong mọi giao dịch của người dùng.

Các nhóm khác chọn cài đặt tối ưu mà không kiểm thử sự đánh đổi giữa triển khai và runtime.

Assembly tự viết có thể được thêm vào trước khi xác định thao tác thực sự gây tốn kém.

Nhà phát triển cũng có thể dựa vào lịch gas lỗi thời sau khi một đợt nâng cấp Ethereum đã định giá lại thao tác.

Lỗi nguy hiểm nhất là loại bỏ bước kiểm tra bảo mật cần thiết để tạo ra kết quả benchmark gas ấn tượng.

Cách xây dựng chiến lược tối ưu gas

Chiến lược tối ưu gas nên bắt đầu bằng việc xác định rõ hành vi hợp đồng và yêu cầu bảo mật.

Nhóm phát triển nên tạo bộ kiểm thử đầy đủ trước khi thay đổi cách triển khai.

Sau đó, nhóm cần đo chi phí triển khai và giao dịch trong điều kiện thực tế.

Cần ưu tiên các thao tác storage, vòng lặp, payload calldata và lệnh gọi bên ngoài tốn kém nhất.

Nên cân nhắc đơn giản hóa kiến trúc trước khi viết lại mã cấp thấp.

Cần kiểm thử và ghi lại cài đặt trình biên dịch cũng như phiên bản EVM mục tiêu.

Mỗi tối ưu hóa cần được đánh giá về chức năng, gas và bảo mật.

Lần triển khai cuối cùng cần sử dụng bytecode có thể tái tạo, được build bằng công cụ và dependency đã cố định phiên bản.

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

Tối ưu gas là gì, nói một cách đơn giản?

Tối ưu gas là giảm lượng tính toán, storage và dữ liệu giao dịch blockchain cần thiết để thực thi hợp đồng thông minh một cách an toàn.

Tối ưu gas có làm giảm giá gas không?

Không. Tối ưu gas làm giảm lượng gas sử dụng, còn giá gas được quyết định bởi nhu cầu mạng và cài đặt phí giao dịch.

Cách tối ưu gas hiệu quả nhất là gì?

Giảm thao tác storage lâu dài không cần thiết và đơn giản hóa kiến trúc hợp đồng thường đem lại khoản tiết kiệm lớn nhất.

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 vì vẫn 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ì không cần sao chép toàn bộ giá trị vào memory.

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

Không. Chúng thường chỉ giúp tiết kiệm storage đáng kể khi nhiều giá trị có thể được sắp xếp vào cùng một storage slot.

Transient storage là gì?

Transient storage là storage EVM chỉ tồn tại trong phạm vi giao dịch, được tự động xóa và có thể giảm chi phí cho trạng thái tạm thời của hợp đồng.

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

Không. Một cấu hình tối ưu có thể giảm gas runtime nhưng làm tăng chi phí triển khai, vì vậy cần đo lường từng cấu hình.

Optimizer runs có ý nghĩa gì?

Cài đặt runs ảnh hưởng đến sự đánh đổi mà trình biên dịch lựa chọn giữa bytecode triển khai nhỏ hơn và chi phí thấp hơn khi thực thi lặp lại.

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

Custom error thường hiệu quả hơn vì dùng selector gọn và tham số được mã hóa thay 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 khi 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 thông tin đó.

Xóa storage có tạo khoản hoàn gas không?

Xóa storage đủ điều kiện có thể tạo khoản hoàn giới hạn, nhưng khoản hoàn bị khống chế và không thu hồi toàn bộ chi phí storage ban đầu.

Khoản hoàn gas có thể ngăn lỗi hết gas không?

Không. Khoản hoàn gas được tính sau khi thực thi và không thể bổ sung gas trong lúc giao dịch đang chạy.

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í lặp lại nhưng làm tăng calldata, độ phức tạp và rủi ro thất bại.

Nhà phát triển có nên dùng inline assembly để tối ưu không?

Chỉ nên dùng inline assembly cho các nút thắt đã được đo lường vì cách này có thể tạo ra rủi ro nghiêm trọng về bảo mật và bảo trì.

Mạng Layer 2 có thể thay thế việc tối ưu gas không?

Không. Mạng Layer 2 có thể giảm phí, nhưng hợp đồng kém hiệu quả vẫn tiêu thụ nhiều tài nguyên hơn hợp đồng được tối ưu trên cùng mạng.

Tại sao chi phí gas thay đổi theo thời gian?

Các đợt nâng cấp Ethereum có thể bổ sung opcode mới, định giá lại thao tác hiện có, thay đổi quy tắc calldata hoặc mở rộng dung lượng mạng.

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

Nhà phát triển có thể dùng báo cáo gas, biên lai giao dịch, execution trace, đầu ra trình biên dịch, ảnh chụp tự động và bài kiểm thử thực tế.

Phiên bản dùng ít gas nhất có luôn là tốt nhất không?

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

Người dùng có thể tối ưu gas mà không thay đổi hợp đồng không?

Người dùng có thể chọn thời điểm nhu cầu thấp hơn hoặc mạng phù hợp, nhưng chỉ nhà phát triển hợp đồng mới có thể thay đổi hiệu quả thực thi nền tảng của ứng dụng.

Kết luận

Tối ưu gas là quá trình kỹ thuật nhằm giảm tài nguyên mà hợp đồng thông minh và giao dịch tiền mã hóa tiêu thụ.

Việc này làm giảm lượng gas sử dụng, chứ không trực tiếp thay đổi giá thị trường của mỗi đơn vị gas.

Các tối ưu hóa hiệu quả nhất thường đến từ kiến trúc đơn giản hơn, ít thao tác storage hơn, chọn vùng dữ liệu hiệu quả, giới hạn vòng lặp và giảm lệnh gọi bên ngoài.

Tối ưu hóa trình biên dịch, biến constant, giá trị immutable, custom error, sắp xếp biến vào cùng slot, transient storage và gộp thao tác phù hợp có thể giúp tiết kiệm thêm.

Nhà phát triển nên dùng trình biên dịch hiện hành, kiểm tra lỗi trình biên dịch đã biết và nhắm đến đúng phiên bản EVM.

Mọi tối ưu hóa đều cần được kiểm thử với giao dịch thành công, trường hợp thất bại, đầu vào lớn và luồng thực thi bất thường.

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

Hợp đồng được tối ưu tốt chỉ thực hiện những công việc on-chain cần thiết để cung cấp chức năng tiền mã hóa an toàn, minh bạch và đáng tin cậy.