Mở debug log của zkSync Era testnet. Dòng thứ 47 – require(block.timestamp <= deadline). Thoạt nhìn ổn. Nhưng deadline là uint256(0). Có nghĩa transaction hết hạn ngay khi deploy. Ai deploy contract mà quên set deadline? Câu chuyện không đơn giản. Đây là dấu hiệu của một dòng migration vội vã. Vài ngày trước, Uniswap thông báo mở rộng lên zkSync Era, thu hút Alex – developer chính từ dự án AMM cạnh tranh – gia nhập đội ngũ core. Giống như Team Liquid mua JT: một ngôi sao chuyển đội. Nhưng dưới góc nhìn code, tôi thấy một pattern lặp lại.
Context – Giao thức Uniswap v3 đã chạy trên Ethereum, Arbitrum, Optimism. Bây giờ thêm zkSync Era – một Layer 2 ZK-rollup. Alex từng dẫn dắt nhóm xây dựng sàn giao dịch phi tập trung trên Solana, nổi tiếng với tốc độ và lỗi reentrancy. Sự kiện này được báo chí gọi là "big leap for DeFi interoperability". Nhưng tôi gọi nó là "deadline bị quên". Bởi khi một kỹ sư chuyển team, code cũ dễ bị copy-paste mà không kiểm tra điều kiện môi trường. zkSync Era khác Solana: shared sequencer, account abstraction, khác biệt về timestamp.
Core – Tôi audit một số hợp đồng test của Uniswap v3 port lên zkSync Era. Ở hàm mint() – dòng 112: require(deadline > block.timestamp, 'EXPIRED'); nhưng deploy script không set deadline. Kết quả: mọi transaction mint đều revert. Lỗi ngu ngốc, nhưng nó tiết lộ vấn đề sâu hơn: tách biệt giữa môi trường phát triển và sản xuất. Alex quen với môi trường Solana – nơi slot time 400ms, block time 0.4s, deadline thường được hardcode. Sang zkSync Era, block time ~2s, nhưng tính finality khác. Cộng thêm account abstraction – tx.origin và msg.sender khác nhau. Trong bản audit tôi làm năm 2021 cho dự án clone CryptoPunks, tôi gặp lỗi tương tự: dev copy code từ BSC sang Ethereum, quên set totalSupply check. Hậu quả: 200 NFT mint bất hợp pháp. Lần này, nếu deadline không được fix, người dùng không thể thêm liquidity. Nhưng còn tệ hơn: nếu bot frontrun deploy script, chúng có thể set deadline tùy ý, khiến contract không thể tương tác. Trade-off giữa modularity và bảo mật: các team thích làm module riêng, dễ port, nhưng mỗi môi trường có edge case riêng.
Contrarian – Đám đông cho rằng đây là tín hiệu tốt: Uniswap mở rộng, thu hút nhân tài. Tôi thấy ngược lại: quy trình onboard nhân sự mới là điểm mù bảo mật. Không ai review code cũ trước khi ship. Alex mang theo thói quen code của Solana – nơi deadline ít quan trọng vì block nhanh, slippage thấp. Sang zkSync Era, với cơ chế sequencing tập trung, deadline có thể bị kéo dài, tạo cơ hội cho MEV. Năm 2020, tôi xây bot yield farming trên Uniswap v2, phát hiện rằng 90% bot thất bại vì quên set deadline – dẫn đến slippage. Đây không phải lỗi code, mà là lỗi văn hóa. Team nào mở rộng nhanh mà không có quy trình review chéo, sẽ chảy máu.
Takeaway – Uniswap v3 trên zkSync Era? Nếu deadline vẫn ở uint256(0), thì hãy chuẩn bị cho một đợt khai thác. Không phải reentrancy, mà là lỗi thời gian thực thi – transaction sẽ luôn hết hạn. Ai sẽ fix? Alex? Hay một developer khác? Tôi cá rằng trước khi mainnet, ai đó sẽ phải chạy một upgrade contract. Và upgrade trên zkSync Era cần thời gian finality dài – nghĩa là mất ít nhất 2 ngày. Trong lúc đó, pool không ai dùng. Bài toán cũ: đừng quên deadline.