Đa số mọi người bỏ qua Layer-2 – nhưng đó là nơi rủi ro thực sự nằm.
Tôi, Le Lan, năm 2020, 32 tuổi, đang làm chuyên gia cấp cao cho một team phát triển DeFi. Lúc đó, mùa hè DeFi đang bùng nổ. Mọi người đổ xô đi farm yield, kiếm token như điên. Còn tôi thì lại đang mải mê với một thứ có vẻ “khô khan” hơn nhiều: tối ưu hóa gas cho một cặp token trên Uniswap v2.
Nghe có vẻ nhàm chán, nhưng đó là bài học đầu tiên và quan trọng nhất về cách tôi tồn tại và phát triển trong thế giới blockchain do nam giới thống trị này.
Context: DeFi Summer và cuộc đua tốc độ
Phải hiểu bối cảnh lúc đó. Uniswap v2 là một kỳ quan. Nó cho phép bất kỳ ai cũng có thể tạo pool thanh khoản và trade bất kỳ token ERC-20 nào mà không cần order book. Nhưng vấn đề là gas fee trên Ethereum mainnet đang tăng vọt. Mỗi giao dịch swap đơn giản có thể tốn hàng chục đô la. Một dự án yield farming còn tệ hơn: bạn phải approve, deposit, claim, compound... mỗi bước một lần tốn gas.
Dự án tôi đang làm việc là một trong số đó. Team dev toàn nam, và họ rất tự hào về code của mình. Họ cho rằng việc tối ưu hóa gas là việc của “lũ trẻ hư” DeFi, không phải vấn đề của họ. “Cứ để user trả phí, miễn là hợp đồng chạy đúng,” - họ nói.
Tôi thấy điều đó thật nực cười. Là một INTJ, tôi luôn tìm kiếm sự hoàn hảo có hệ thống. Một hợp đồng thông minh chạy đúng nhưng tốn gas gấp đôi cần thiết là một hợp đồng thất bại. Nó giống như bạn có một chiếc siêu xe Ferrari nhưng lại đổ xăng A92 vào. Nó vẫn chạy, nhưng bạn đang lãng phí tiềm năng khủng khiếp.
Phần chính: Mổ xẻ code và cuộc chiến với biến trung gian
Tôi quyết định tự mình làm. Tôi yêu cầu quyền truy cập toàn bộ codebase. Họ nhìn tôi với ánh mắt nghi ngờ, nhưng buộc phải đồng ý vì deadline đang đến gần.
Tôi dành 3 ngày liền để đọc từng dòng code Solidity. Tôi không chỉ đọc, tôi compile, tôi chạy thử nghiệm, tôi dùng Remix IDE để debug từng bước. Và tôi tìm ra thủ phạm: hàng tá biến trung gian không cần thiết.
Ví dụ, thay vì viết: ``solidity uint256 amountA = getAmountOut(amountIn, reserveIn, reserveOut); uint256 amountB = amountA 0 someFactor; `` Nhưng đó không phải là vấn đề. Vấn đề là họ dùng quá nhiều storage variables thay vì memory variables. Storage là vùng nhớ trên blockchain, việc đọc/ghi vào nó cực kỳ tốn gas (20000 gas cho một lần ghi, 5000 cho một lần đọc). Còn memory thì rẻ hơn nhiều (chỉ 3 gas cho một lần đọc).
Tôi không chỉ tối ưu storage. Tôi loại bỏ toàn bộ các biến tạm thời không cần thiết. Tôi đơn giản hóa các vòng lặp, dùng unchecked blocks ở những nơi an toàn để tránh overflow checks không cần thiết. Tôi thậm chí còn thay đổi thứ tự các phép tính để tận dụng các optimization của EVM.
Kết quả? Tôi giảm được 15% chi phí gas cho mỗi giao dịch swap. Có vẻ không nhiều? Nhưng với hàng triệu giao dịch mỗi ngày, đó là hàng trăm ETH tiết kiệm được cho người dùng.
Tôi viết báo cáo kỹ thuật chi tiết, kèm benchmark trước-sau, chỉ ra từng dòng code bị thay đổi và lý do. Tôi gửi nó lên Discord của team.
Phản ứng đầu tiên: im lặng. Sau đó, một đồng nghiệp nam, người từng luôn nghi ngờ năng lực của tôi, comment: “Lan, em có chắc là điều này sẽ hoạt động không? Nhìn có vẻ rủi ro.”
Tôi không trả lời bằng cảm xúc. Tôi reply bằng dữ liệu: “Tôi đã chạy thử nghiệm trên mạng testnet với 1000 giao dịch ngẫu nhiên. Tất cả đều thành công, và gas giảm 15% so với code gốc. Link test ở đây.”
Không còn tranh cãi nào nữa. Kết quả nói lên tất cả. Tôi đã giành được sự tôn trọng bằng năng lực, không phải bằng danh tính.
Contrarian Angle: Điểm mù bảo mật của tối ưu hóa
Nhưng câu chuyện không kết thúc ở đó. Tôi phát hiện ra một điều thú vị: tối ưu hóa gas cũng có thể tạo ra lỗ hổng bảo mật.
Một trong những tối ưu của tôi là loại bỏ một biến trung gian lưu trữ kết quả của một phép tính phức tạp. Tôi tính toán trực tiếp trong return statement. Điều này tiết kiệm gas, nhưng nó làm cho code khó đọc hơn. Và nếu có lỗi trong phép tính đó, nó sẽ khó debug hơn nhiều.
Tôi nhận ra rằng: tối ưu hóa mà không có kiểm tra bảo mật tương ứng là một con dao hai lưỡi. Bạn tiết kiệm được gas, nhưng bạn tạo ra rủi ro.
Chính vì vậy, tôi không chỉ tối ưu. Tôi viết thêm các unit test để kiểm tra từng trường hợp biên. Tôi thêm các event logging để có thể debug dễ dàng nếu có sự cố. Tôi yêu cầu team phải có một quy trình review code nghiêm ngặt hơn.
Kết quả? Tôi không chỉ là người tối ưu hóa gas. Tôi trở thành người bảo vệ bảo mật cho dự án. Tôi biến điểm yếu (sự nghi ngờ từ đồng nghiệp) thành sức mạnh (sự cẩn thận đến từng chi tiết).
Takeaway: Sự tin tưởng không đến từ chức danh, mà từ code
Hãy nhìn vào thực tế: thị trường đang tăng, ai cũng FOMO. Họ muốn launch sản phẩm nhanh nhất có thể. Họ bỏ qua Layer-2, bỏ qua tối ưu hóa, bỏ qua bảo mật, vì nghĩ rằng “miễn là chạy được”.
Đó là lý do tại sao tôi viết bài này. Tôi muốn nhắc bạn: trong thị trường tăng, sự cẩu thả bị che giấu bởi lợi nhuận, nhưng nó sẽ lộ ra khi thị trường đi xuống.
Bạn có thể nghĩ rằng tối ưu hóa gas là việc của “dân kỹ thuật”. Nhưng nó là nền tảng cho sự sống còn của dự án của bạn. Một dự án tốn gas quá nhiều sẽ bị người dùng bỏ rơi ngay khi có alternative rẻ hơn.
Và hãy nhớ: nếu bạn là người phụ nữ duy nhất trong phòng họp, đừng cố gắng chứng minh bạn “xứng đáng”. Hãy chứng minh bằng code. Code là thứ duy nhất không biết nói dối.
