Gas Golfing

Gas golfing là gì?

Gas golfing là việc thực hiện những thay đổi nhỏ, tập trung vào một phần cụ thể của mã hợp đồng thông minh để giảm mức tiêu thụ gas.

Thuật ngữ này bắt nguồn từ code golf, một thử thách lập trình trong đó nhà phát triển cố gắng giải quyết vấn đề bằng lượng mã nguồn ít nhất có thể.

Trong quá trình phát triển tiền mã hóa, mục tiêu không nhất thiết là viết ít ký tự nhất.

Mục tiêu là tạo ra bytecode tiêu thụ ít tài nguyên blockchain hơn nhưng vẫn giữ nguyên hành vi cần thiết của hợp đồng.

Gas golfing thường gắn liền nhất với Ethereum và các mạng khác thực thi hợp đồng thông minh thông qua Ethereum Virtual Machine.

Nhà phát triển có thể tối ưu gas cho hợp đồng bằng cách giảm thao tác lưu trữ, đơn giản hóa phép tính, rút gọn dữ liệu revert, tránh sao chép bộ nhớ không cần thiết hoặc chọn các lệnh EVM có chi phí thấp hơn.

Gas golfing thường tập trung vào các tối ưu vi mô thay vì thiết kế lại toàn bộ ứng dụng.

Vì vậy, phạm vi của gas golfing hẹp hơn tối ưu gas nói chung, vốn có thể bao gồm kiến trúc hợp đồng, gộp giao dịch, triển khai trên Layer 2, thiết kế ứng dụng và tính toán off-chain.

Thay đổi gas golfing hiệu quả phải giữ được tính bảo mật, tính chính xác, khả năng đọc hiểu và tính tương thích.

Tiết kiệm một lượng gas nhỏ không đáng để đánh đổi nếu thay đổi đó tạo ra lỗ hổng hoặc khiến hợp đồng không thể được bảo trì an toàn.

Tại sao gọi là gas golfing?

Từ “golfing” nói đến mục tiêu đạt điểm số thấp hơn.

Trong môn golf truyền thống, số lần đánh bóng càng ít càng tốt.

Trong gas golfing cho hợp đồng thông minh, nhìn chung lượng gas càng thấp càng tốt nếu mã đã tối ưu vẫn thực hiện cùng một tác vụ một cách an toàn.

Nhà phát triển có thể so sánh hai cách triển khai bằng cách đo gas triển khai, gas khi chạy, kích thước bytecode hoặc tổng chi phí trong vòng đời dự kiến của hợp đồng.

Một thử thách gas golfing có thể yêu cầu người tham gia triển khai một hàm với lượng gas thấp nhất có thể.

Phát triển sản phẩm thực tế phức tạp hơn vì giải pháp dùng ít gas nhất có thể không phải là giải pháp an toàn nhất hoặc dễ kiểm toán nhất.

Đây là thuật ngữ không chính thức, không chỉ một giao thức Ethereum, token, loại giao dịch hay tiêu chuẩn lập trình chính thức nào.

Cách gas golfing hoạt động

Ethereum quy định chi phí gas cho mọi thao tác mà Ethereum Virtual Machine thực hiện.

Tài liệu gas chính thức của Ethereum giải thích rằng gas đo lường mức độ tính toán cần thiết để thực thi giao dịch và thao tác hợp đồng thông minh.

Phép toán số học, sử dụng bộ nhớ, lưu trữ lâu dài, nhật ký sự kiện, lệnh gọi hợp đồng, khởi tạo hợp đồng và dữ liệu giao dịch đều góp phần làm tăng lượng gas tiêu thụ.

Gas golfing tìm một chuỗi thao tác ít tốn kém hơn nhưng vẫn cho ra kết quả cần thiết tương tự.

Ví dụ, nhà phát triển có thể thay nhiều lần đọc dữ liệu lưu trữ bằng một lần đọc, rồi tái sử dụng giá trị đã tải vào biến cục bộ.

Nhà phát triển khác có thể thay chuỗi revert dài bằng custom error ngắn gọn.

Ở cấp thấp hơn, nhà phát triển có thể thay vòng lặp sao chép bộ nhớ được tạo thủ công bằng lệnh EVM chuyên dùng cho việc sao chép bộ nhớ.

Cần đo lường bytecode sau khi biên dịch để xác nhận mức cải thiện cuối cùng, vì mã Solidity ngắn hơn về mặt trực quan không phải lúc nào cũng giúp EVM thực thi với chi phí thấp hơn.

Gas golfing và tối ưu gas

Tối ưu gas là quá trình tổng thể nhằm giảm chi phí triển khai và thực thi hợp đồng thông minh.

Gas golfing là một hình thức tối ưu hẹp hơn, thường nhấn mạnh vào những khoản tiết kiệm nhỏ ở cấp độ mã.

Một dự án tối ưu gas toàn diện có thể thiết kế lại mô hình lưu trữ của ứng dụng, chuyển phần tính toán phù hợp sang off-chain, sử dụng mạng Layer 2 hoặc giảm số giao dịch cần thiết cho mỗi người dùng.

Gas golfing có thể chỉ so sánh hai cấu trúc vòng lặp, hai cách xử lý lỗi hoặc hai phương thức tải cùng một giá trị.

Tối ưu kiến trúc thường mang lại mức tiết kiệm lớn hơn tối ưu vi mô.

Tuy nhiên, khoản tiết kiệm nhỏ nhưng lặp lại có thể trở nên đáng kể nếu một hàm được thực thi hàng triệu lần.

Nhà phát triển chuyên nghiệp nên loại bỏ công việc không cần thiết ở cấp kiến trúc trước, sau đó mới tối ưu gas cho các luồng thực thi quan trọng còn lại.

Gas golfing và code golf

Code golf cố gắng giảm độ dài mã nguồn, thường không ưu tiên khả năng đọc hiểu hoặc bảo trì lâu dài.

Gas golfing cố gắng giảm chi phí thực thi trên blockchain.

Biểu thức Solidity ngắn nhất có thể được biên dịch thành nhiều lệnh hơn một biểu thức dài và rõ ràng hơn.

Trình biên dịch cũng có thể chuyển đổi nhiều kiểu viết mã nguồn khác nhau thành bytecode giống hệt nhau.

Vì vậy, nhà phát triển nên so sánh đầu ra đã biên dịch và lượng gas đo được thay vì đếm ký tự trong mã nguồn.

Giải pháp code golf có thể thú vị nhưng không phù hợp với hợp đồng kiểm soát tiền mã hóa có giá trị.

Gas golfing cho sản phẩm thực tế phải luôn đi kèm kiểm thử bảo mật, tài liệu và đánh giá mã.

Gas golfing và giảm giá gas

Gas golfing làm giảm số đơn vị gas mà một giao dịch tiêu thụ.

Việc này không trực tiếp làm giảm giá thị trường phải trả cho mỗi đơn vị gas.

Có thể biểu diễn phí giao dịch bằng công thức: Gas Charged × Effective Gas Price.

Thay đổi gas golfing tác động vào phần lượng gas bị tính phí trong công thức này.

Nhu cầu mạng, phí cơ sở của giao thức và phí ưu tiên của người dùng ảnh hưởng đến giá gas hiệu dụng.

Một hợp đồng được tối ưu tốt vẫn có thể tốn kém khi sử dụng trong giai đoạn mạng tắc nghẽn nghiêm trọng.

Hợp đồng tối ưu kém cũng có thể tiếp tục lãng phí tài nguyên ngay cả khi giá gas tạm thời thấp.

Tại sao nhà phát triển thực hiện gas golfing?

Gas golfing có thể giảm chi phí mà mỗi người dùng phải trả khi tương tác với một hàm hợp đồng thông minh được gọi thường xuyên.

Chi phí giao dịch thấp hơn có thể giúp nhiều người tiếp cận tài chính phi tập trung, chuyển token, game blockchain, thao tác NFT và hệ thống quản trị hơn.

Gas golfing cũng có thể giảm chi phí triển khai hợp đồng nếu tối ưu hóa làm giảm công việc khởi tạo hoặc kích thước bytecode khi chạy.

Các chiến lược tiền mã hóa tự động có thể phụ thuộc vào khoản tiết kiệm gas nhỏ vì phí giao dịch trực tiếp làm giảm lợi nhuận kỳ vọng.

Các giao thức thực hiện nhiều thao tác nội bộ lặp lại có thể tiết kiệm đáng kể dù mỗi cải thiện riêng lẻ đều nhỏ.

Mức sử dụng gas thấp hơn cũng dành thêm sức chứa trong block cho các giao dịch khác.

Tuy nhiên, việc tối ưu nên dựa trên mức sử dụng dự kiến thay vì cố đạt kết quả benchmark thấp nhất có thể trong một trường hợp thử nghiệm phi thực tế.

Đo lường trước khi gas golfing

Nhà phát triển nên đo mức sử dụng gas trước khi thử tối ưu vi mô.

Trình biên dịch hiện tại có thể đã loại bỏ thao tác tưởng như không cần thiết đó.

Thay đổi giúp giảm gas ở phiên bản Solidity cũ có thể không mang lại lợi ích nào khi dùng trình biên dịch hiện tại.

Một thay đổi khác có thể giảm gas khi chạy nhưng lại làm tăng chi phí triển khai hợp đồng.

Kiểm thử gas nên bao gồm các hàm người dùng gọi thường xuyên nhất.

Kiểm thử cũng nên bao gồm đầu vào tối thiểu, đầu vào tối đa được hỗ trợ, trường hợp thực thi thành công và các nhánh lỗi.

Tài liệu trình biên dịch Solidity mô tả các tùy chọn đầu ra và ước tính gas.

Ước tính của trình biên dịch có thể chưa đầy đủ nếu vòng lặp, lệnh gọi bên ngoài hoặc trạng thái blockchain động ảnh hưởng đến quá trình thực thi.

Do đó, nhà phát triển nên kết hợp đầu ra của trình biên dịch với kiểm thử giao dịch thực tế và execution trace.

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

Các phiên bản Solidity mới thường bổ sung tối ưu hóa, hỗ trợ EVM, tính năng ngôn ngữ và bản sửa lỗi bảo mật.

Thông báo phát hành Solidity 0.8.36 chính thức xác định phiên bản 0.8.36 là bản hiện hành vào tháng 7 năm 2026.

Bản phát hành này bao gồm các bản sửa lỗi bảo mật và những cải tiến tiếp theo cho pipeline tạo mã theo dạng SSA đang trong giai đoạn thử nghiệm.

Kết quả gas golfing từ một phiên bản trình biên dịch có thể khác kết quả từ phiên bản khác.

Nhà phát triển nên cố định phiên bản trình biên dịch, cấu hình optimizer, mục tiêu EVM và phiên bản dependency được dùng cho các bản dựng sản phẩm.

Trước khi triển khai hợp đồng tiền mã hóa có giá trị, họ cũng nên xem danh sách lỗi chính thức của trình biên dịch Solidity.

Chỉ cập nhật trình biên dịch để giảm gas mà không kiểm thử lại toàn bộ ứng dụng có thể dẫn đến hành vi hoặc bytecode khác ngoài dự kiến.

Sử dụng Solidity optimizer trước khi tối ưu thủ công

Solidity optimizer có thể đơn giản hóa biểu thức, loại bỏ thao tác dư thừa, gộp phép tính và giảm kích thước bytecode.

Tài liệu optimizer chính thức của Solidity giải thích rằng tối ưu hóa có thể giảm cả kích thước triển khai lẫn chi phí thực thi.

Gas golfing thủ công cần tính đến những gì optimizer đã thực hiện.

Hai hàm Solidity trông khác nhau rõ rệt có thể được biên dịch thành cùng một bytecode đã tối ưu.

Cài đặt runs của optimizer ảnh hưởng đến sự đánh đổi giữa mã triển khai nhỏ hơn và chi phí thực thi lặp lại thấp hơn.

Giá trị runs thấp thường ưu tiên giảm kích thước mã triển khai.

Giá trị runs cao hơn thường ưu tiên thực thi lặp lại với chi phí thấp hơn.

Cài đặt phù hợp nhất phụ thuộc vào tần suất triển khai hợp đồng và tần suất gọi từng hàm.

Nhà phát triển nên so sánh một số cấu hình đã kiểm thử thay vì chọn một giá trị thường dùng mà không đo lường.

Cache các lần đọc dữ liệu lưu trữ lặp lại

Truy cập dữ liệu lưu trữ lâu dài thường tốn kém hơn việc sử dụng giá trị đã có trên stack EVM hoặc trong bộ nhớ.

Một kỹ thuật gas golfing thường dùng là tải giá trị lưu trữ vào biến cục bộ một lần rồi tái sử dụng.

Ethereum áp dụng chi phí truy cập cold và warm theo EIP-2929.

Lần đầu truy cập một ô lưu trữ trong giao dịch thường tốn kém hơn những lần truy cập tiếp theo vào cùng ô đó.

Có thể tránh cả lần đọc storage warm nếu hợp đồng đã có bản sao cục bộ chính xác.

Nhà phát triển cũng có thể tính kết quả cuối cùng ở cục bộ rồi ghi storage một lần thay vì lưu từng giá trị trung gian.

Cache không an toàn nếu một lệnh gọi bên ngoài có thể thay đổi trạng thái liên quan trước khi giá trị đã cache được sử dụng lại.

Cần cân nhắc reentrancy, callback, delegate call và hành vi kế thừa trước khi áp dụng kỹ thuật này.

Giảm số lần ghi storage

Ghi trạng thái lâu dài là một trong những thao tác phổ biến tốn kém nhất trong hợp đồng thông minh.

Hợp đồng nên tránh ghi giá trị nếu giá trị cần lưu đã tồn tại.

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

Trong một số trường hợp, có thể biểu diễn nhiều giá trị liên quan bằng một chỉ số tích lũy hoặc mốc kế toán duy nhất.

Hàm cũng có thể tính toán cục bộ và chỉ ghi kết quả cuối cùng vào storage.

Những thay đổi này có thể tiết kiệm nhiều gas hơn việc viết lại một biểu thức số học nhỏ.

Nhà phát triển phải xác nhận mô hình trạng thái đơn giản hóa vẫn hỗ trợ số dư, quyền hạn, hạch toán lịch sử và nâng cấp một cách chính xác.

Đóng gói biến lưu trữ

Ethereum chia storage của hợp đồng thành các ô 32 byte.

Solidity có thể đóng gói nhiều biến kiểu giá trị nhỏ hơn vào một ô nếu thứ tự và tổng kích thước của chúng cho phép.

Tài liệu bố cục storage của Solidity giải thích cách phân bổ và đóng gói biến.

Trong trường hợp phù hợp, giảm số ô storage cần thiết có thể hạ gas triển khai và gas khi chạy.

Kiểu số nguyên nhỏ hơn không tự động tiết kiệm gas nếu được lưu riêng.

EVM thường thực hiện phép toán bằng từ 256 bit, vì vậy kiểu nhỏ hơn có thể cần thêm thao tác mask hoặc chuyển đổi.

Đóng gói hiệu quả nhất khi các giá trị trong cùng gói thường được truy cập hoặc thay đổi cùng nhau.

Không được sắp xếp lại biến storage trong hợp đồng có thể nâng cấp đã triển khai vì bố cục mới có thể diễn giải sai dữ liệu hiện có.

Sử dụng giá trị constant và immutable

Biến trạng thái thông thường phát sinh chi phí storage khi cần đọc giá trị từ trạng thái lưu trữ lâu dài.

Giá trị đã biết tại thời điểm biên dịch có thể được khai báo là

.

Giá trị được chọn khi khởi tạo và không thay đổi sau khi triển khai có thể được khai báo là

.

Tài liệu hợp đồng Solidity giải thích rằng các giá trị này không dùng ô storage thông thường giống như biến trạng thái có thể thay đổi.

Địa chỉ cố định, giá trị toán học và giới hạn cấu hình không đổi thường là những lựa chọn phù hợp.

Không nên chuyển một giá trị thành immutable nếu ứng dụng thực sự cần quy trình cập nhật được ủy quyền.

Tiết kiệm gas bằng cách loại bỏ tính linh hoạt cấu hình cần thiết có thể tạo ra hạn chế vận hành tốn kém hoặc nguy hiểm.

Sử dụng calldata cho đầu vào chỉ đọc

Đầu vào của hàm external không cần chỉnh sửa thường có thể được giữ trong

.

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

Tài liệu vị trí dữ liệu của Solidity giải thích sự khác nhau giữa calldata, memory, storage và transient storage.

Kỹ thuật này hữu ích nhất với đầu vào external động mà hàm chỉ đọc.

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

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

Mã hóa giá trị gọn hơn có thể tiết kiệm gas calldata, nhưng cần tính cả chi phí tính toán giải mã khi so sánh.

Sử dụng custom error

Custom error có thể giảm bytecode hợp đồng và chi phí dữ liệu revert so với chuỗi thông báo lỗi dài.

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

Tài liệu custom error chính thức của Solidity mô tả đây là phương thức tiết kiệm gas để báo lỗi.

Ví dụ, lỗi có thể bao gồm địa chỉ người gọi và số dư cần thiết mà không phải nhúng một câu dài vào bytecode khi chạy.

Custom error không giúp luồng thực thi thành công miễn phí vì hợp đồng vẫn phải đánh giá điều kiện.

Lỗi cần đủ dễ hiểu để ví, giao diện, kiểm toán viên và nhà phát triển chẩn đoán giao dịch tiền mã hóa thất bại.

Sắp xếp điều kiện để đánh giá ngắn mạch

Biểu thức Boolean trong Solidity có thể dừng sớm khi đã xác định được kết quả cuối cùng.

Trong biểu thức dùng AND logic, quá trình đánh giá có thể dừng sau điều kiện false đầu tiên.

Trong biểu thức dùng OR logic, quá trình đánh giá có thể dừng sau điều kiện true đầu tiên.

Đặt điều kiện rẻ trước điều kiện tốn kém có thể giảm gas trung bình nếu điều kiện rẻ thường đã quyết định kết quả.

Kỹ thuật này phải giữ nguyên logic dự kiến và mọi giả định về hàm có thể revert hoặc gây tác dụng phụ.

Không nên tùy tiện đổi thứ tự điều kiện nếu thứ tự đó liên quan đến an toàn hoặc thông báo lỗi.

Tối ưu vòng lặp một cách thận trọng

Vòng lặp có thể tiêu thụ lượng gas lớn khi xử lý nhiều phần tử.

Nhà phát triển có thể cache độ dài mảng được truy cập nhiều lần nếu tập hợp không thể thay đổi trong lúc chạy vòng lặp.

Họ cũng có thể cache các giá trị storage được dùng ở mỗi vòng lặp.

Bộ đếm vòng lặp có thể dùng phép tăng

nếu chứng minh được về mặt toán học rằng không thể xảy ra tràn số.

Trình biên dịch hiện đại đã tối ưu một số kiểu tăng biến phổ biến, vì vậy cần đo mức tiết kiệm trên trình biên dịch đã chọn.

Nhận định phổ biến rằng tăng tiền tố luôn rẻ hơn tăng hậu tố không phải quy tắc đáng tin cậy cho mã Solidity hiện đại đã tối ưu.

Vòng lặp không giới hạn trên tập hợp storage ngày càng tăng là vấn đề kiến trúc, không phải cơ hội gas golfing nhỏ.

Nên chia khối lượng công việc lớn thành các batch có giới hạn hoặc thiết kế lại để người dùng xử lý trạng thái độc lập của riêng họ.

Chỉ dùng phép toán unchecked khi có chứng minh

Solidity 0.8 trở lên thường kiểm tra tràn số và thiếu số trong phép toán số nguyên.

Các kiểm tra này tiêu tốn một phần gas nhưng giúp ngăn ngừa những nhóm lỗi lập trình quan trọng.

Khối

loại bỏ kiểm tra tự động đối với các phép toán bên trong.

Cách này có thể tiết kiệm gas nếu giới hạn toán học đã chứng minh rằng không thể xảy ra tràn số.

Bộ đếm vòng lặp có giới hạn là ví dụ thường gặp, dù lập luận an toàn cụ thể phụ thuộc vào thiết kế vòng lặp.

Không nên dùng unchecked chỉ vì đầu vào thường dự kiến nhỏ.

Mã cần có kiểm thử và tài liệu rõ ràng cho thấy mọi đầu vào có thể xảy ra đều an toàn.

Sử dụng transient storage cho trạng thái tạm thời

Transient storage cung cấp trạng thái chỉ tồn tại trong phạm vi một giao dịch và tự động được xóa khi giao dịch kết thúc.

Ethereum giới thiệu các thao tác

và thông qua EIP-1153.

Transient storage có thể rẻ hơn storage lâu dài khi dữ liệu cần dùng qua nhiều lệnh gọi nhưng không cần giữ lại giữa các giao dịch.

Khóa reentrancy là ví dụ phổ biến về thông tin chỉ cần trong phạm vi giao dịch.

Transient storage không thể thay thế số dư lâu dài, quyền sở hữu, khoản nợ hoặc cấu hình cần thiết trong các giao dịch sau.

Nhà phát triển phải hiểu trạng thái transient hoạt động thế nào khi gọi hàm, delegate call và revert.

Thay một biện pháp kiểm soát bảo mật đã được kiểm chứng bằng cách triển khai transient rẻ hơn đòi hỏi kiểm thử và đánh giá đầy đủ.

Sử dụng lệnh EVM hiện đại

Các bản nâng cấp Ethereum có thể bổ sung lệnh thay thế chuỗi thao tác cũ tốn kém hơn.

EIP-3855 giới thiệu

, lệnh đưa giá trị 0 lên stack bằng một instruction gọn nhẹ.

EIP-5656 giới thiệu

, thao tác chuyên dụng để sao chép bộ nhớ.

Trình biên dịch Solidity hiện hành có thể tự động sử dụng các lệnh EVM được hỗ trợ khi chọn đúng phiên bản EVM.

Thông thường, nhà phát triển không nên thay mã do trình biên dịch tạo ra bằng assembly viết tay chỉ để ép dùng một lệnh.

Hợp đồng biên dịch cho mục tiêu EVM mới có thể không chạy được trên mạng chưa kích hoạt các lệnh cần thiết.

Do đó, kết quả gas golfing cần nêu chính xác trình biên dịch và mục tiêu EVM được sử dụng để đo lường.

Giảm số lệnh gọi bên ngoài

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

Hợp đồng có thể tiết kiệm gas bằng cách tránh lặp lại lệnh gọi trả về cùng một giá trị trong một giao dịch.

Đôi khi có thể gộp nhiều lần đọc liên quan vào một lệnh gọi trả về kết quả có cấu trúc.

Tuy nhiên, thay đổi cấu trúc lệnh gọi có thể ảnh hưởng đến reentrancy, xử lý lỗi, khả năng kết hợp và ranh giới hợp đồng.

Vẫn phải kiểm tra chính xác giá trị trả về và điều kiện thành công.

Lệnh gọi rẻ nhưng tạo ra giả định không an toàn không phải là một tối ưu hợp lệ.

Dùng event thay storage khi phù hợp

Log sự kiện thường ít tốn kém hơn storage lâu dài đối với thông tin chỉ được ứng dụng off-chain sử dụng.

Event có thể hỗ trợ lịch sử giao dịch, phân tích, bảng tin hoạt động và thông báo trên giao diện người dùng.

Nhìn chung, quá trình thực thi hợp đồng thông minh sau này không thể tìm kiếm các log sự kiện lịch sử.

Vì vậy, số dư, quyền hạn, quyền sở hữu, tài sản thế chấp và trạng thái có hiệu lực khác phải vẫn có thể được hợp đồng truy cập.

Chỉ nên dùng event để gas golfing khi giá trị storage bị xóa không cần thiết cho các quyết định on-chain sau này.

Khi thiết kế event, nhà phát triển cũng nên cân nhắc chi phí của topic event được lập chỉ mục và dữ liệu log.

Giảm bytecode triển khai

Ethereum tính gas khi bytecode chạy của hợp đồng được lưu trong quá trình triển khai.

Loại bỏ hàm không dùng, logic trùng lặp, chuỗi revert dài và dữ liệu nhúng không cần thiết có thể giảm chi phí triển khai.

Custom error, thư viện nội bộ, cách triển khai dùng chung và cấu hình tối ưu trình biên dịch phù hợp có thể giúp giảm kích thước mã.

EIP-170 quy định giới hạn mã chạy được triển khai thông thường của Ethereum.

Mã khởi tạo có cơ chế tính gas và giới hạn riêng theo EIP-3860.

Hợp đồng nhỏ hơn không tự động rẻ hơn trong toàn bộ vòng đời vì chia mã giữa nhiều hợp đồng có thể làm phát sinh chi phí lệnh gọi bên ngoài lặp lại.

Nhà phát triển nên đánh giá đồng thời chi phí triển khai và chi phí thực thi lặp lại.

Hiểu các giới hạn của hoàn gas

Một số chiến lược gas golfing cũ trên Ethereum từng phụ thuộc nhiều vào việc tạo rồi xóa storage.

Quy tắc Ethereum hiện hành giới hạn đáng kể cách làm này.

EIP-3529 giảm mức hoàn gas khi xóa storage, loại bỏ khoản hoàn trước đây cho

và giới hạn lượng hoàn được áp dụng ở mức 20% tổng gas tiêu thụ.

Hợp đồng không nên tạo trạng thái không cần thiết với hy vọng sau này sẽ nhận được khoản hoàn tương đương hoặc lớn hơn.

Gas refund được áp dụng sau khi thực thi và không thể ngăn lỗi hết gas.

cũng không còn là kỹ thuật gas golfing hiện đại vì không được hoàn gas và hành vi xóa đã bị hạn chế.

Tối ưu calldata và EIP-7623

Đôi khi nhà phát triển tối ưu gas dữ liệu đầu vào giao dịch bằng kiểu dữ liệu gọn, bit packing, mã hóa tùy chỉnh hoặc biểu diễn ngắn hơn.

Giảm số byte giao dịch có thể hạ gas nội tại, đặc biệt khi loại bỏ được nhiều giá trị lặp lại.

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

Các thao tác giải mã cần thiết cho định dạng gọn cũng tiêu tốn gas.

Mã hóa tùy chỉnh có thể giảm chi phí cho khối lượng công việc lớn, lặp lại nhưng không mang lại lợi ích cho giao dịch nhỏ.

Mã hóa không theo chuẩn có thể gây khó khăn hơn cho ví, kiểm toán, tích hợp và gỡ lỗi.

Nhà phát triển nên benchmark toàn bộ quá trình mã hóa và giải mã theo quy tắc giao thức hiện hành.

Khi nào nên dùng inline assembly?

Inline assembly cho phép nhà phát triển kiểm soát trực tiếp lệnh EVM, bộ nhớ, storage, lệnh gọi và dữ liệu trả về.

Kỹ thuật này có thể tiết kiệm gas khi Solidity cấp cao không thể biểu diễn hiệu quả một thao tác chuyên biệt.

Assembly thường được cân nhắc cho các quy trình mật mã, phân tích dữ liệu gọn, thao tác bộ nhớ đặc biệt và hàm cấp thấp được lặp lại nhiều lần.

Assembly cũng bỏ qua nhiều biện pháp bảo vệ về kiểu dữ liệu, bộ nhớ và an toàn mà Solidity cung cấp.

Lỗi assembly có thể làm hỏng bộ nhớ, mã hóa dữ liệu sai, xử lý sai giá trị trả về hoặc khiến tiền mã hóa bị đánh cắp.

Mọi cách triển khai bằng assembly nên được so sánh với một cách triển khai tham chiếu rõ ràng ở cấp cao.

Kiểm thử cần xác nhận hành vi giống nhau với đầu vào thông thường, đầu vào biên, đầu vào độc hại và các trường hợp revert.

Khi nào gas golfing trở nên nguy hiểm?

Gas golfing trở nên nguy hiểm khi chi phí gas được ưu tiên hơn tính bảo mật và sự rõ ràng của hợp đồng.

Loại bỏ kiểm tra quyền truy cập để tiết kiệm gas có thể cho phép người dùng trái phép kiểm soát hợp đồng.

Bỏ guard reentrancy có thể khiến số dư bị khai thác thông qua các lệnh gọi bên ngoài lặp lại.

Bỏ giới hạn trượt giá hoặc thời hạn có thể khiến người dùng phải chịu mức thực thi tiền mã hóa bất lợi.

Gộp nhiều giá trị vào một từ được đóng gói có thể dẫn đến lỗi mask bit và chuyển đổi.

Thay mã hóa tiêu chuẩn bằng định dạng tùy chỉnh có thể tạo ra lỗ hổng chữ ký, replay hoặc phân tích dữ liệu.

Tối ưu tiết kiệm 100 gas nhưng tạo ra khả năng khiến người dùng mất tiền sẽ có giá trị thực tế âm.

Lời khuyên gas golfing lỗi thời

Lời khuyên gas golfing có thể lỗi thời khi Solidity và EVM thay đổi.

Trình biên dịch có thể bắt đầu tự tối ưu một mẫu mã trước đây cần viết lại thủ công.

Bản nâng cấp mạng có thể thay đổi giá opcode hoặc bổ sung lệnh hiệu quả hơn.

Khuyến nghị cũ dùng

để nhận hoàn gas không còn phù hợp với Ethereum hiện hành.

Nhận định rằng một kiểu tăng biến luôn rẻ hơn kiểu còn lại có thể không đúng với bytecode hiện đại đã tối ưu.

Khuyến nghị dùng số nguyên rất nhỏ có thể không tiết kiệm gas nếu không đóng gói storage.

Trước khi áp dụng mẹo gas golfing, nhà phát triển nên yêu cầu benchmark hiện hành và cài đặt trình biên dịch có thể tái lập.

Cách đánh giá thay đổi gas golfing

Trước tiên, bản triển khai đã tối ưu phải cho ra hành vi cần thiết giống bản gốc.

Nhà phát triển nên so sánh gas triển khai, gas khi chạy thành công, gas của nhánh lỗi và tổng chi phí vòng đời dự kiến.

Họ cần xác định trình biên dịch, cài đặt optimizer, phiên bản EVM và trạng thái blockchain được dùng trong kiểm thử.

Unit test nên xác minh hành vi thông thường của hàm.

Fuzz test nên khảo sát đầu vào bất ngờ và điều kiện biên.

Invariant test nên xác nhận các thuộc tính thiết yếu về kế toán và bảo mật vẫn đúng.

Execution trace cần xác nhận khoản tiết kiệm đến từ các thao tác dự kiến chứ không phải do vô tình bỏ qua một yêu cầu.

Người đánh giá nên xác định thay đổi đó có còn dễ hiểu và bảo trì hay không.

Gas golfing trong hợp đồng sản phẩm thực tế

Gas golfing cho sản phẩm thực tế nên tập trung vào các hàm được dùng thường xuyên và nút thắt đã được đo lường rõ ràng.

Khoản tiết kiệm nhỏ trong hàm được thực thi hàng triệu lần có thể đáng để đầu tư triển khai cẩn thận.

Khoản tiết kiệm tương tự trong hàm quản trị chỉ dùng một lần có thể không đáng để tăng độ phức tạp.

Giao diện công khai và hành vi dự kiến nên được giữ ổn định, trừ khi tối ưu là một phần của kế hoạch nâng cấp giao thức.

Hợp đồng có thể nâng cấp phải giữ nguyên bố cục storage và mô hình phân quyền.

Hợp đồng có giá trị lớn nên được đánh giá bảo mật độc lập sau khi thực hiện tối ưu cấp thấp đáng kể.

Bytecode đã triển khai cần có thể được tái tạo từ mã nguồn và cấu hình build đã công bố.

Các lỗi gas golfing thường gặp

Một lỗi phổ biến là so sánh độ dài mã nguồn thay vì lượng gas của mã đã biên dịch.

Lỗi khác là kiểm thử mà không bật cùng cài đặt optimizer được dùng cho môi trường sản phẩm.

Nhà phát triển có thể chỉ đo giao dịch thành công và bỏ qua nhánh revert có chi phí cao bất thường.

Họ có thể tối ưu một hàm hiếm khi dùng mà bỏ qua thao tác ghi storage lặp lại trong mọi giao dịch.

Họ có thể dùng kiểu số nguyên nhỏ hơn nhưng không nhận được lợi ích đóng gói storage.

Họ có thể thay Solidity rõ ràng bằng assembly trước khi xác nhận mã do trình biên dịch tạo ra thực sự tốn kém.

Họ có thể dựa vào lịch gas cũ không còn phản ánh EVM hiện tại.

Lỗi nghiêm trọng nhất là chấp nhận kết quả gas thấp hơn mà không chứng minh phiên bản tối ưu có hành vi an toàn giống hệt bản gốc.

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

Gas golfing là gì, nói đơn giản?

Gas golfing là thực hiện những thay đổi nhỏ ở cấp mã để giảm lượng gas mà hợp đồng thông minh tiêu thụ mà không làm thay đổi hành vi dự kiến.

Gas golfing có giống tối ưu gas không?

Không. Gas golfing thường là một dạng tối ưu vi mô có phạm vi hẹp, còn tối ưu gas còn bao gồm kiến trúc, thiết kế storage, tính toán off-chain, gộp giao dịch và lựa chọn mạng.

Gas golfing có phải tính năng giao thức Ethereum không?

Không. Đây là thuật ngữ không chính thức của nhà phát triển, không phải opcode, loại giao dịch hay tiêu chuẩn Ethereum chính thức.

Mã Solidity ngắn hơn có luôn dùng ít gas hơn không?

Không. Độ dài mã nguồn không dự đoán đáng tin cậy kích thước hoặc chi phí thực thi của bytecode EVM đã biên dịch.

Solidity optimizer có thể tự gas golfing không?

Optimizer thực hiện nhiều phép biến đổi tương tự, nhưng nhà phát triển vẫn cần thiết kế hiệu quả storage, luồng dữ liệu và kiến trúc hợp đồng.

Kỹ thuật gas golfing nào tốt nhất?

Kỹ thuật mang lại giá trị cao nhất thường phụ thuộc vào hợp đồng, nhưng giảm truy cập storage lặp lại thường hữu ích hơn thay đổi biểu thức số học nhỏ.

Số nguyên nhỏ hơn có luôn rẻ hơn không?

Không. Số nguyên nhỏ hơn hữu ích nhất khi cho phép nhiều giá trị dùng chung một ô storage.

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

Calldata thường rẻ hơn với đầu vào external chỉ đọc vì tránh được việc sao chép, nhưng vị trí dữ liệu phù hợp phụ thuộc vào cách sử dụng dữ liệu.

Tại sao custom error hữu ích cho gas golfing?

Custom error dùng selector và tham số gọn thay vì nhúng và trả về chuỗi revert dài.

Cache giá trị storage có luôn tiết kiệm gas không?

Cách này có thể tiết kiệm gas nếu giá trị vẫn còn hợp lệ, nhưng cache có thể không an toàn nếu lệnh gọi bên ngoài làm thay đổi trạng thái.

Phép toán unchecked có phải cách tối ưu an toàn không?

Chỉ an toàn khi nhà phát triển chứng minh được rằng tràn số hoặc thiếu số không thể xảy ra với mọi đầu vào có thể có.

Người tối ưu gas có nên dùng inline assembly không?

Chỉ nên dùng inline assembly cho các nút thắt đã được đo lường vì kỹ thuật này có thể gây lỗi nghiêm trọng về bộ nhớ, mã hóa và bảo mật.

Tăng tiền tố có luôn tốn ít gas hơn tăng hậu tố không?

Không. Trình biên dịch hiện tại có thể tạo mã tương đương, vì vậy cần đo kết quả cụ thể.

Event có thể thay thế storage hợp đồng không?

Event chỉ có thể thay storage cho 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 xác minh.

Gas golfing có thể giúp giao dịch miễn phí không?

Không. Mọi giao dịch vẫn phải trả phí cho hoạt động thực thi, dữ liệu và trạng thái cần thiết theo quy tắc tính phí của mạng.

Gas golfing có giảm giá gas không?

Không. Gas golfing giảm lượng gas sử dụng, còn giá gas thay đổi theo nhu cầu mạng và cài đặt phí giao dịch.

Hoàn gas có phải một phương pháp gas golfing không?

Xóa storage đủ điều kiện có thể được hoàn gas ở mức giới hạn, nhưng quy tắc hiện hành giới hạn khoản hoàn và không còn hỗ trợ các chiến lược cũ phụ thuộc nhiều vào hoàn gas.

Gas golfing có thể tạo ra rủi ro bảo mật không?

Có. Nén quá mức, phép toán unchecked, assembly và việc loại bỏ bước xác thực có thể tạo lỗ hổng nếu không được đánh giá kỹ.

Nên kiểm thử kết quả gas golfing như thế nào?

Cần kiểm thử với cài đặt trình biên dịch cố định, đầu vào thực tế, execution trace, fuzz test, invariant và đánh giá bảo mật.

Khi nào gas golfing đáng thực hiện?

Gas golfing đáng thực hiện nhất khi một thay đổi an toàn giúp giảm chi phí của hàm được người dùng hoặc hệ thống tự động gọi thường xuyên.

Kết luận

Gas golfing là việc thực hiện những thay đổi tập trung vào hợp đồng thông minh để giảm gas triển khai hoặc thực thi.

Khái niệm này liên quan đến tối ưu gas nhưng thường tập trung vào cải thiện nhỏ ở cấp mã thay vì thiết kế lại toàn bộ ứng dụng.

Các phương pháp gas golfing phổ biến gồm cache lượt đọc storage, giảm lượt ghi storage, đóng gói biến, dùng calldata, chọn custom error, đơn giản hóa vòng lặp và sử dụng tính năng EVM hiện đại.

Hiệu quả của từng phương pháp phụ thuộc vào phiên bản trình biên dịch, cài đặt optimizer, mục tiêu EVM, giá trị đầu vào và trạng thái blockchain.

Lời khuyên từng giúp tiết kiệm trong môi trường Ethereum cũ có thể không còn hiệu quả theo quy tắc giao thức và trình biên dịch hiện hành.

Nhà phát triển nên đo bytecode đã biên dịch thay vì đánh giá hiệu quả dựa trên hình thức hoặc độ dài mã Solidity.

Thông thường, nên cân nhắc cải thiện kiến trúc trước khi tối ưu vi mô cấp thấp.

Chỉ nên dùng inline assembly và thao tác unchecked khi mức tiết kiệm đo được và tính an toàn có thể chứng minh.

Mọi thay đổi gas golfing phải giữ nguyên hành vi, tính bảo mật, khả năng đọc hiểu và tính tương thích của hợp đồng.

Kết quả gas golfing tốt nhất không đơn thuần là con số gas thấp nhất, mà là chi phí thấp nhất có thể đạt được một cách an toàn để cung cấp chức năng tiền mã hóa cần thiết.