Khi nâng cấp Cancun đang đến gần, có những điểm cần lưu ý và rủi ro tiềm ẩn nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Khi nâng cấp Cancun đang đến gần, có những điểm cần lưu ý và rủi ro tiềm ẩn nào?
Việc nâng cấp坎昆 đã được hoàn thành lần lượt vào ngày 17 tháng 1, ngày 30 tháng 1 và ngày 7 tháng 2 trên các mạng thử nghiệm Goerli, Sepolia và Holesky của Ethereum, và dự kiến sẽ được kích hoạt trên mạng chính Ethereum vào ngày 13 tháng 3.
Chuyên sâu báo cáo Web3Tác giả: Salus Insights
Tóm tắt: Nâng cấp Cancun đang đến gần, đợt nâng cấp này chủ yếu bao gồm sáu thay đổi ở lớp thực thi do các EIP đề xuất: EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 và EIP-7516. EIP-4844 là tâm điểm của lần nâng cấp này, nhằm cải thiện khả năng mở rộng của Ethereum, giúp giảm chi phí giao dịch và tăng tốc độ cho các L2. Nâng cấp Cancun đã được triển khai thành công trên các mạng thử nghiệm Goerli, Sepolia và Holesky của Ethereum vào các ngày 17 tháng 1, 30 tháng 1 và 7 tháng 2, và dự kiến sẽ được kích hoạt trên mạng chính Ethereum vào ngày 13 tháng 3. Trước thời điểm nâng cấp, Salus đã tổng hợp những lưu ý quan trọng về an toàn để các nhà phát triển tự kiểm tra.
Tổng quan về các đề xuất EIP
EIP-1153
EIP-1153 giới thiệu các mã vận hành (opcode) lưu trữ tạm thời, dùng để thao tác trạng thái với hành vi gần giống như lưu trữ thông thường, nhưng dữ liệu lưu trữ tạm thời sẽ bị xóa sau mỗi giao dịch. Điều này có nghĩa là lưu trữ tạm thời không cần giải trình tự hay trình tự hóa giá trị từ/vào bộ nhớ lưu trữ, do đó chi phí thấp hơn vì không cần truy cập ổ đĩa. Thông qua hai mã vận hành mới là TLOAD và TSTORE (trong đó "T" đại diện cho "tạm thời"), các hợp đồng thông minh có thể truy cập vào bộ nhớ tạm thời. Đề xuất này nhằm cung cấp một giải pháp chuyên biệt và hiệu quả cho việc giao tiếp giữa nhiều khung thực thi lồng ghép trong quá trình thực thi giao dịch của Ethereum.
EIP-4788
EIP-4788 nhằm phơi bày gốc cây băm của khối chuỗi Beacon vào bên trong EVM, cho phép các hợp đồng thông minh truy cập trực tiếp các gốc này. Việc này cho phép truy cập trạng thái tầng đồng thuận một cách không cần tin cậy, hỗ trợ nhiều trường hợp sử dụng như nhóm stake, cơ chế restaking, cầu nối hợp đồng thông minh, giảm thiểu MEV,... Đề xuất này sử dụng một hợp đồng thông minh để lưu trữ các gốc này, kết hợp với bộ đệm vòng để hạn chế tiêu thụ bộ nhớ, đảm bảo rằng mỗi khối thực thi chỉ cần không gian cố định để biểu diễn thông tin.
EIP-4844
EIP-4844 giới thiệu một định dạng giao dịch mới gọi là "giao dịch blob phân mảnh", nhằm đơn giản và tương thích về sau để mở rộng tính sẵn có dữ liệu của Ethereum. Đề xuất này đưa ra các "giao dịch mang blob" chứa lượng lớn dữ liệu – dữ liệu này không thể được EVM truy cập trực tiếp khi thực thi, nhưng cam kết của nó thì có thể truy cập được. Định dạng này hoàn toàn tương thích với định dạng sẽ dùng trong phân mảnh đầy đủ trong tương lai, và cung cấp giải pháp tạm thời nhưng đáng kể để giảm tải cho việc mở rộng quy mô theo kiểu rollup.
EIP-5656
EIP-5656 giới thiệu một lệnh EVM mới là MCOPY, dùng để sao chép hiệu quả các vùng bộ nhớ. Đề xuất này nhằm giảm chi phí thực hiện thao tác sao chép bộ nhớ trên EVM bằng cách dùng lệnh MCOPY để trực tiếp sao chép dữ liệu giữa các vùng bộ nhớ. MCOPY cho phép địa chỉ nguồn và đích trùng nhau, thiết kế chú trọng tính tương thích ngược và nhằm nâng cao hiệu suất thực thi trong nhiều tình huống như xây dựng cấu trúc dữ liệu, truy cập và sao chép đối tượng bộ nhớ một cách hiệu quả.
EIP-6780
EIP-6780 sửa đổi chức năng của mã vận hành SELFDESTRUCT. Theo đề xuất này, SELFDESTRUCT chỉ xóa tài khoản và chuyển toàn bộ ether nếu được thực thi trong cùng giao dịch với việc tạo hợp đồng; ngoài ra, khi thực thi SELFDESTRUCT, hợp đồng sẽ không bị xóa mà chỉ chuyển toàn bộ ether tới địa chỉ đích. Thay đổi này nhằm chuẩn bị cho việc sử dụng cây Verkle trong tương lai, giúp đơn giản hóa việc triển khai EVM, giảm độ phức tạp của các thay đổi trạng thái, đồng thời vẫn giữ lại một số trường hợp sử dụng phổ biến của SELFDESTRUCT.
EIP-7516
EIP-7516 giới thiệu một lệnh EVM mới là BLOBBASEFEE, trả về giá cơ sở blob hiện tại trong khối đang thực thi. Lệnh này tương tự như opcode BASEFEE trong EIP-3198, khác biệt ở chỗ nó trả về giá cơ sở blob được định nghĩa bởi EIP-4844. Tính năng này cho phép các hợp đồng lập trình xem xét giá gas của dữ liệu blob, ví dụ như cho phép các hợp đồng rollup tính toán chi phí sử dụng blob một cách không cần tin cậy, hoặc triển khai các sản phẩm phái sinh về gas blob nhằm san bằng chi phí.
Các cân nhắc về an toàn từ phía chính thức
EIP-1153
Các nhà phát triển hợp đồng thông minh cần hiểu rõ vòng đời của biến lưu trữ tạm thời trước khi sử dụng. Vì lưu trữ tạm thời sẽ tự động xóa sạch khi giao dịch kết thúc, nên các nhà phát triển có thể cố gắng tránh xóa slot trong quá trình gọi để tiết kiệm gas. Tuy nhiên, điều này có thể ngăn chặn việc tương tác thêm với hợp đồng trong cùng giao dịch (ví dụ như trong trường hợp khóa chống reentrancy), hoặc gây ra lỗi khác. Do đó, các nhà phát triển cần thận trọng, chỉ lưu giá trị khác không vào slot tạm thời khi giá trị đó được dự định dùng cho các lời gọi trong tương lai cùng giao dịch. Về hành vi, các opcode này giống hệt SSTORE và SLOAD, do đó tất cả các lưu ý an toàn phổ biến đều áp dụng, đặc biệt là rủi ro reentrancy.
Các nhà phát triển cũng có thể cố gắng dùng lưu trữ tạm thời như một phương án thay thế ánh xạ bộ nhớ. Họ cần nhận thức rằng, khi lời gọi trả về hoặc rollback, lưu trữ tạm thời sẽ không bị xóa như bộ nhớ, và do đó nên ưu tiên dùng bộ nhớ trong các trường hợp này để tránh hành vi bất ngờ khi có reentrancy trong cùng giao dịch. Chi phí dùng lưu trữ tạm thời thay cho bộ nhớ nhất định rất cao, điều này lẽ ra đã ngăn chặn kiểu sử dụng này. Phần lớn các trường hợp dùng ánh xạ trong bộ nhớ có thể được thực hiện tốt hơn bằng danh sách các mục sắp xếp theo khóa, và việc dùng ánh xạ trong bộ nhớ hiếm khi cần thiết trong hợp đồng thông minh (theo tác giả, hiện chưa có trường hợp nào nổi bật trong môi trường sản xuất).
EIP-4844
EIP này làm tăng yêu cầu băng thông tối đa khoảng 0,75 MB cho mỗi khối Beacon. So với kích thước lý thuyết tối đa hiện nay của khối (30 triệu gas / 16 gas mỗi byte calldata = 1,875 triệu byte), con số này lớn hơn 40%, do đó không làm tăng mạnh băng thông trong trường hợp xấu nhất. Sau khi sáp nhập, thời gian khối là cố định chứ không còn là phân bố Poisson khó đoán, đảm bảo khoảng thời gian ổn định để truyền các khối lớn.
Ngay cả khi dữ liệu calldata bị giới hạn, tải trọng liên tục của EIP này vẫn thấp hơn nhiều so với các phương án thay thế có thể giảm chi phí calldata, vì blob không cần được lưu trữ lâu như tải trọng thực thi. Điều này cho phép triển khai chiến lược buộc các blob phải được giữ lại ít nhất một khoảng thời gian. Giá trị cụ thể được chọn là MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, khoảng 18 ngày, ngắn hơn nhiều so với thời gian luân chuyển lịch sử tải trọng thực thi được đề xuất là một năm (hiện chưa triển khai).
EIP-5656
Các client cần lưu ý rằng việc triển khai không dùng bộ đệm trung gian (ví dụ như hàm memmove trong C stdlib không dùng bộ đệm trung gian), vì đây là một vector tấn công từ chối dịch vụ (DoS) tiềm tàng. Hầu hết các hàm dựng sẵn/ngôn ngữ thư viện tiêu chuẩn dùng để di chuyển byte đều có đặc tính hiệu suất phù hợp ở đây.
Ngoài ra, phân tích về DoS và tấn công làm cạn kiệt bộ nhớ giống như các opcode thao tác bộ nhớ khác, vì việc mở rộng bộ nhớ tuân theo cùng quy tắc định giá.
EIP-6780
Các ứng dụng sau đây sử dụng SELFDESTRUCT sẽ bị ảnh hưởng, và các ứng dụng dùng theo cách này sẽ không còn an toàn:
Trường hợp CREATE2 được dùng để triển khai lại hợp đồng tại cùng vị trí nhằm nâng cấp hợp đồng. Chức năng này không còn được hỗ trợ, và nên chuyển sang dùng ERC-2535 hoặc các loại hợp đồng proxy khác.
Nếu hợp đồng phụ thuộc vào việc đốt ether bằng cách dùng chính bản thân nó làm người thụ hưởng thông qua SELFDESTRUCT, trong khi hợp đồng không được tạo ra trong cùng giao dịch.
Các rủi ro liên quan đến hợp đồng thông minh
EIP-1153
Hãy hình dung hai kịch bản sử dụng các opcode TLOAD và TSTORE:
-
Hợp đồng bị gọi sử dụng opcode này
-
Hợp đồng khởi tạo lời gọi sử dụng opcode này
Rủi ro 1:
So với SSTORE và SLOAD truyền thống, lưu trữ tạm thời mới được thêm vào chủ yếu thay đổi thời hạn lưu trữ dữ liệu — dữ liệu được lưu bằng tstore sẽ được đọc bằng tload, và sẽ bị giải phóng sau khi giao dịch kết thúc, thay vì được ghi vĩnh viễn vào hợp đồng như sstore. Các nhà phát triển khi dùng opcode này cần nhận thức rõ đặc tính này, tránh việc sử dụng sai dẫn đến dữ liệu không được ghi đúng vào hợp đồng và gây thiệt hại. Ngoài ra, dữ liệu tstore là biến riêng tư, chỉ chính hợp đồng mới truy cập được. Nếu muốn bên ngoài sử dụng dữ liệu này, chỉ có thể truyền qua tham số hoặc tạm lưu vào một biến public storage.
Rủi ro 2:
Một rủi ro tiềm tàng khác là nếu nhà phát triển hợp đồng thông minh không quản lý đúng vòng đời của biến lưu trữ tạm thời, có thể dẫn đến dữ liệu bị xóa sai thời điểm hoặc bị giữ lại sai cách. Nếu hợp đồng kỳ vọng sử dụng dữ liệu trong lưu trữ tạm thời ở các lời gọi sau trong cùng giao dịch nhưng không quản lý đúng vòng đời, có thể dẫn đến việc chia sẻ sai hoặc mất dữ liệu giữa các lời gọi, gây lỗi logic hoặc lỗ hổng bảo mật. Ví dụ, dữ liệu balance hoặc allowance của token nếu không được lưu đúng cách có thể dẫn đến lỗi logic hợp đồng và gây thiệt hại. Hoặc khi thiết lập địa chỉ owner mà dùng opcode này có thể khiến địa chỉ đặc quyền không được ghi đúng, dẫn đến mất quyền kiểm soát các tham số quan trọng của hợp đồng.
Xét một hợp đồng thông minh dùng lưu trữ tạm thời để ghi tạm giá giao dịch trên một sàn giao dịch tiền mã hóa. Hợp đồng cập nhật giá sau mỗi giao dịch và cho phép người dùng truy vấn giá mới nhất trong thời gian ngắn. Tuy nhiên, nếu thiết kế hợp đồng không tính đến đặc tính dữ liệu trong lưu trữ tạm thời sẽ bị xóa tự động khi giao dịch kết thúc, thì trong khoảng thời gian từ khi một giao dịch kết thúc đến giao dịch tiếp theo bắt đầu, người dùng có thể nhận được giá sai hoặc đã lỗi thời. Điều này không chỉ khiến người dùng ra quyết định dựa trên thông tin sai, mà còn có thể bị lợi dụng độc hại, ảnh hưởng đến uy tín nền tảng và an toàn tài sản người dùng.
EIP-6780
Đề xuất này thay đổi hành vi của opcode selfdestruct trước đây: không hủy hợp đồng mà chỉ chuyển token, chỉ những hợp đồng được tạo ra trong cùng giao dịch mới bị hủy. Tác động của EIP này khá lớn.
Dùng create2 để triển khai lại hợp đồng tại cùng địa chỉ nhằm nâng cấp hợp đồng. Chức năng này không còn được hỗ trợ, cần chuyển sang dùng ERC-2535 hoặc các loại hợp đồng proxy khác. (Điều này có thể ảnh hưởng đến hợp đồng trên chuỗi dùng create2 để triển khai hợp đồng nâng cấp được)
Opcode SELFDESTRUCT trong hợp đồng thông minh cho phép hợp đồng tự hủy và chuyển số dư ether đến một địa chỉ đích. Trong trường hợp này, hợp đồng dùng SELFDESTRUCT để hủy ether và gửi ether đã hủy đến chính nó. Tuy nhiên, chỉ những hợp đồng được tạo ra trong cùng giao dịch (do chính hợp đồng hoặc hợp đồng khác tạo) mới bị hủy. Trường hợp khác, chỉ chuyển ether mà không hủy hợp đồng (ví dụ tự hủy và người thụ hưởng là chính nó — sẽ không thay đổi gì). Điều này ảnh hưởng đến mọi hợp đồng phụ thuộc vào selfdestruct để rút tiền hoặc thực hiện thao tác khác (hợp đồng).
Một cơ chế tương tự Gas Token CHI của 1inch: duy trì một offset, luôn thực hiện CREATE2 hoặc SELFDESTRUCT tại offset đó. Sau bản cập nhật này, nếu hợp đồng tại offset hiện tại chưa tự hủy đúng cách, thì các lệnh CREATE2 sau đó sẽ không thể triển khai thành công.
Việc triển khai đề xuất này không trực tiếp tạo ra cuộc tấn công vào hợp đồng, nhưng sẽ làm tổn hại đến logic hoạt động bình thường của các hợp đồng đã triển khai trước đó vốn phụ thuộc vào opcode selfdestruct (các hợp đồng chỉ dựa vào selfdestruct để chuyển tiền thì không bị ảnh hưởng; nếu thao tác sau đó yêu cầu bắt buộc hợp đồng bị xóa thì sẽ bị ảnh hưởng), dẫn đến hoạt động ngoài dự kiến, có thể gây tê liệt hợp đồng, mất tiền... (ví dụ: các hợp đồng trước đây dùng create2 để triển khai hợp đồng mới tại địa chỉ cũ, tự hủy hợp đồng cũ để nâng cấp, giờ đây sẽ không thể triển khai thành công). Về dài hạn, việc thay đổi chức năng của một opcode có thể tạo ra vấn đề tập trung hóa.
Ví dụ: hiện có một hợp đồng vault cần cập nhật:
-
Dùng create2 để triển khai tạm thời một hợp đồng để dự trữ tiền từ vault
-
Tự hủy hợp đồng vault, chuyển tiền sang hợp đồng tạm thời (chỉ chuyển tiền, không hủy hợp đồng vault)
-
Dùng create2 tại địa chỉ cũ để triển khai vault mới (thất bại, vì vault cũ chưa bị hủy)
-
Tự hủy hợp đồng tạm thời để trả tiền về vault (mất tiền, vì vault chưa được tạo)
Tài liệu tham khảo mở rộng
Nâng cấp Cancun sẽ tiếp tục tăng cường lợi thế cạnh tranh của Ethereum. Tuy nhiên, những thay đổi lần này ở tầng hợp đồng thông minh cốt lõi cũng đi kèm rủi ro, ảnh hưởng đến việc vận hành an toàn của các DApp hiện tại. Trong quá trình phát triển hợp đồng thông minh, những thay đổi và rủi ro tiềm tàng này cần được đặc biệt lưu tâm.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@salus_sec
