Hàm dự phòng (Fallback Function)

Fallback Function là gì?

Fallback function là một hàm Solidity đặc biệt xử lý các lệnh gọi từ bên ngoài không khớp với bất kỳ hàm nào khác được định nghĩa trong hợp đồng thông minh.Hàm này là lựa chọn định tuyến cuối cùng của hợp đồng khi Solidity không thể xác định hàm thông thường dựa trên dữ liệu giao dịch được cung cấp.Fallback function cũng có thể chạy khi lệnh gọi không có dữ liệu và hợp đồng không có hàm receive riêng.Hàm này được sử dụng rộng rãi trong ứng dụng tiền mã hóa, gồm hợp đồng thông minh có thể nâng cấp, hệ thống proxy, ví mô-đun, hợp đồng thanh toán và bộ định tuyến lệnh gọi tùy chỉnh.

Theo tài liệu Solidity chính thức, một hợp đồng không thể có quá một fallback function.

Fallback function phải có phạm vi hiển thị external vì được thiết kế để phản hồi các lệnh gọi từ bên ngoài hợp đồng.Hàm có thể được đánh dấu payable khi hợp đồng cần nhận tiền mã hóa gốc thông qua lệnh gọi không khớp.Hàm cũng có thể kiểm tra toàn bộ dữ liệu giao dịch và trả về dữ liệu phản hồi thô khi sử dụng dạng nâng cao.Fallback function không phải bộ xử lý lỗi chung cho mọi thao tác hợp đồng thông minh thất bại.Hàm chỉ chạy trong những điều kiện định tuyến cụ thể do Solidity và Ethereum Virtual Machine xác định.

Vì sao được gọi là Fallback Function?

Từ fallback mô tả hành động thay thế được sử dụng khi hành động ưu tiên hoặc dự kiến không khả dụng.Khi người dùng gọi một hàm hợp đồng thông minh thông thường, Solidity trước tiên cố khớp dữ liệu giao dịch được cung cấp với một trong các hàm đã khai báo của hợp đồng.Nếu không khớp, hợp đồng chuyển sang fallback function.Hành vi này cho phép nhà phát triển xác định điều gì sẽ xảy ra khi ví, hợp đồng thông minh hoặc ứng dụng gửi một lệnh gọi không được hỗ trợ.Fallback function có thể từ chối lệnh gọi, nhận khoản thanh toán, ghi nhận sự kiện, trả về dữ liệu hoặc chuyển tiếp lệnh gọi đến hợp đồng khác.Nếu hợp đồng không có fallback function phù hợp, lệnh gọi không được hỗ trợ thường bị hoàn tác (revert).

Khi nào Fallback Function được gọi?

Fallback function được gọi khi lệnh gọi bên ngoài đến hợp đồng thông minh nhưng không có hàm thông thường nào khớp với function selector được cung cấp.Hàm cũng được gọi khi lệnh gọi không có calldata và hợp đồng không định nghĩa hàm receive.Lệnh gọi có dữ liệu khác rỗng có thể đến fallback function dù có chuyển tiền mã hóa gốc hay không.Fallback function phải là payable khi lệnh gọi kèm theo một lượng tiền mã hóa khác 0.Fallback function không phải payable sẽ từ chối lệnh gọi không khớp có ý định chuyển giá trị.Nếu hợp đồng định nghĩa hàm receive, lệnh gọi không có dữ liệu sẽ đến hàm receive.Do đó, fallback function có vai trò khác nhau tùy hợp đồng có đồng thời hàm receive hay không.

Cách định tuyến hàm trong hợp đồng thông minh

Lệnh gọi hợp đồng thông minh bên ngoài thường chứa dữ liệu giao dịch đã mã hóa, gọi là calldata.Bốn byte đầu tiên của lệnh gọi hàm tiêu chuẩn chứa function selector.

Đặc tả ABI Solidity định nghĩa selector là bốn byte đầu tiên của hash Keccak-256 từ chữ ký chuẩn của hàm.

Chữ ký chuẩn kết hợp tên hàm với kiểu tham số.Solidity so sánh selector nhận được với selector của các hàm public và external trong hợp đồng.Nếu có selector khớp, hàm tương ứng sẽ xử lý lệnh gọi.Nếu không có selector khớp, Solidity định tuyến lệnh gọi đến fallback function nếu có.Calldata ngắn hơn bốn byte thường không thể xác định một hàm Solidity thông thường, do đó có thể được chuyển đến fallback function.Calldata rỗng tuân theo quy tắc định tuyến riêng, ưu tiên hàm receive.

Fallback Function và Receive Function

Fallback function và receive function là hai điểm truy cập Solidity riêng biệt với mục đích khác nhau.Receive function được thiết kế riêng để xử lý lệnh gọi có calldata rỗng.Fallback function chủ yếu xử lý lệnh gọi có dữ liệu nhưng không khớp với hàm đã khai báo.Receive function luôn là payable vì mục đích chính là nhận tiền mã hóa gốc.Fallback function chỉ payable khi nhà phát triển chủ động cho phép nhận giá trị.Nếu hợp đồng định nghĩa cả hai hàm, giao dịch chuyển tiền không có dữ liệu sẽ đến receive function.Lệnh gọi không khớp có dữ liệu sẽ đến fallback function.Nếu hợp đồng không có receive function, fallback function payable có thể xử lý giao dịch chuyển tiền không có dữ liệu.

Hướng dẫn hiện hành của Solidity về nhận tiền mã hóa khuyến nghị định nghĩa receive function khi đã có fallback function payable.

Việc tách riêng giúp phân biệt khoản thanh toán có chủ đích với lệnh gọi hàm được mã hóa không đúng.

Fallback Function và hàm thông thường

Hàm Solidity thông thường có tên được khai báo và thường có function selector riêng.Ứng dụng có thể gọi hàm thông thường thông qua giao diện hợp đồng đã biết.Fallback function không có tên gọi thông thường để gọi.Hàm không có selector riêng mà người dùng gọi trực tiếp.Thay vào đó, hàm xử lý các lệnh gọi không khớp với giao diện thông thường của hợp đồng.Một hợp đồng có thể có nhiều hàm thông thường nhưng chỉ có một fallback function.Logic kinh doanh chính của ứng dụng phi tập trung thông thường nên nằm trong các hàm thông thường.Nếu không được chủ ý dùng làm bộ định tuyến proxy, fallback function nên có mục đích giới hạn và được mô tả rõ ràng.

Fallback Function và xử lý lỗi

Fallback function không chạy mỗi khi một hàm hợp đồng thông minh khác thất bại.Nếu calldata khớp với hàm thông thường nhưng hàm đó sau đó revert, fallback function sẽ không được gọi.Nếu hàm đã khớp từ chối khoản thanh toán vì không phải payable, Solidity không chuyển khoản thanh toán sang fallback function.Nếu function selector chính xác nhưng đối số sai định dạng, lệnh gọi đã khớp thường revert trong lúc giải mã.Điều kiện require thất bại, kiểm tra số học, quy tắc kiểm soát quyền truy cập, lệnh gọi bên ngoài hoặc lỗi tùy chỉnh cũng không kích hoạt fallback function.Nhà phát triển phải xử lý các lỗi này bằng cơ chế xử lý lỗi thông thường, kiểm tra giá trị trả về, lỗi tùy chỉnh hoặc logic try-catch phù hợp.Fallback function xử lý lệnh gọi không khớp, không xử lý lỗi bên trong lệnh gọi đã khớp.

Fallback Function payable là gì?

Fallback function payable có thể nhận tiền mã hóa gốc được đính kèm trong lệnh gọi bên ngoài không khớp.Lượng tiền gửi kèm theo lệnh gọi có thể được truy cập thông qua trường giá trị giao dịch.Fallback function cũng có thể truy cập địa chỉ người gửi.Fallback payable có thể cập nhật trạng thái, phát sự kiện, chuyển tiếp lệnh gọi hoặc thực hiện hành động được phép khác khi có đủ gas.Đánh dấu fallback function là payable khiến hợp đồng phải chịu trách nhiệm tài chính.Hợp đồng có thể cần hạch toán số dư đáng tin cậy, rút tiền có kiểm soát, quy trình khẩn cấp và biện pháp chống reentrancy.Hợp đồng không được thiết kế để nắm giữ tiền mã hóa thông thường nên từ chối các khoản thanh toán ngoài dự kiến.Chỉ nên cho phép payable khi phục vụ mục đích xác định của giao thức.

Fallback Function không payable là gì?

Fallback function không payable có thể xử lý lệnh gọi không khớp nhưng không chuyển tiền mã hóa gốc.Lệnh gọi không khớp có giá trị khác 0 sẽ revert nếu fallback function không phải payable.Thiết kế này hữu ích khi hợp đồng cần định tuyến hoặc ghi nhận tùy chỉnh nhưng không nên nhận tiền.Fallback function không payable cũng có thể chủ động từ chối function selector không được hỗ trợ.Từ chối lệnh gọi không xác định có thể giúp người dùng và ứng dụng phát hiện giao diện đang dùng không chính xác.

Fallback Function có thể đọc thông tin nào?

Fallback function có thể truy cập địa chỉ khởi tạo lệnh gọi hiện tại.Nếu là payable, hàm có thể truy cập lượng tiền mã hóa gốc đính kèm lệnh gọi.Hàm có thể kiểm tra toàn bộ calldata do bên gọi cung cấp.Calldata đầy đủ bao gồm selector có thể có và mọi giá trị bổ sung đã mã hóa.Dạng fallback function có tham số có thể nhận dữ liệu này dưới dạng chuỗi byte.Hàm cũng có thể trả về trực tiếp các byte thô.Solidity không tự động mã hóa ABI thông thường cho dữ liệu thô do fallback trả về.Hành vi này đặc biệt hữu ích với hợp đồng proxy cần trả chính xác dữ liệu mà hợp đồng triển khai đã trả về.

Fallback Function có nên giải mã calldata không?

Fallback function có thể kiểm tra và giải mã calldata theo cách thủ công.Bốn byte đầu tiên có thể được so sánh với các selector dự kiến.Các byte còn lại có thể được giải mã thành kiểu tham số dự kiến.Tuy nhiên, tài liệu Solidity khuyến nghị chỉ giải mã thủ công trong fallback như phương án cuối cùng.Hàm có tên thông thường tạo giao diện rõ ràng hơn, tự động giải mã an toàn hơn và dễ tích hợp hơn.Giải mã thủ công phải xác minh độ dài calldata, offset, kiểu dữ liệu và selector được hỗ trợ.Cần từ chối dữ liệu sai định dạng trước khi thay đổi trạng thái nhạy cảm.Giải mã sai có thể gây hành vi ngoài dự kiến, giao dịch thất bại hoặc lỗ hổng bảo mật.

Fallback Function trong hợp đồng proxy có thể nâng cấp

Hợp đồng proxy có thể nâng cấp là một trong những ứng dụng quan trọng nhất của fallback function trong ứng dụng tiền mã hóa.Proxy tách địa chỉ hợp đồng và trạng thái lưu trữ khỏi mã chứa logic kinh doanh của ứng dụng.Người dùng gửi giao dịch đến địa chỉ proxy.Proxy lưu địa chỉ của hợp đồng triển khai chứa logic hiện hành.Lệnh gọi không khớp với hàm được định nghĩa trực tiếp trong proxy sẽ đến fallback function của proxy.Fallback function chuyển tiếp lệnh gọi đến hợp đồng triển khai bằng delegatecall.

Tài liệu Ethereum về nâng cấp proxy giải thích cấu trúc này cho phép thay đổi logic kinh doanh trong khi người dùng tiếp tục tương tác với cùng địa chỉ proxy.

Proxy giữ nguyên số dư và dữ liệu ứng dụng sau khi hợp đồng triển khai được thay đổi.Cách này có thể hỗ trợ sửa lỗi và bổ sung tính năng mới mà không cần chuyển mọi người dùng sang địa chỉ hợp đồng mới.

Delegatecall là gì?

Delegatecall là một thao tác của Ethereum Virtual Machine, thực thi mã từ hợp đồng khác trong ngữ cảnh của hợp đồng gọi.Trong hệ thống proxy, hợp đồng triển khai cung cấp mã.Proxy cung cấp địa chỉ, số dư tiền mã hóa và bộ nhớ lưu trữ lâu dài.Địa chỉ người gửi ban đầu và giá trị giao dịch vẫn khả dụng trong quá trình thực thi được ủy quyền.Vì vậy, hợp đồng triển khai hoạt động như thể logic của nó là một phần của proxy.

EIP-7 giới thiệu delegatecall như thao tác cấp thấp để thực thi mã bên ngoài nhưng vẫn giữ ngữ cảnh người gửi và giá trị của bên gọi.

Delegatecall mạnh vì hợp đồng triển khai có thể đọc và sửa bộ nhớ lưu trữ của proxy.Chính lý do đó cũng khiến delegatecall nguy hiểm.Hợp đồng triển khai độc hại hoặc không tương thích có thể làm sai lệch số dư, quyền hạn, dữ liệu sở hữu hoặc trạng thái quan trọng khác.

Fallback Function của proxy định tuyến lệnh gọi như thế nào?

Proxy trước tiên nhận toàn bộ calldata của người dùng.Fallback function xác định địa chỉ hợp đồng triển khai hiện tại.Proxy chuyển calldata ban đầu đến hợp đồng triển khai thông qua delegatecall.Hợp đồng triển khai thực thi logic bằng bộ nhớ lưu trữ của proxy.Proxy nhận dữ liệu phản hồi từ hợp đồng triển khai.Nếu lệnh gọi được ủy quyền thành công, proxy trả nguyên phản hồi đó cho bên gọi ban đầu.Nếu lệnh gọi thất bại, proxy nên chuyển tiếp thông tin lỗi ban đầu lại cho bên gọi.Chuyển tiếp sai có thể che giấu lỗi, sửa dữ liệu trả về hoặc khiến tích hợp diễn giải kết quả không chính xác.

Slot lưu trữ của proxy

Proxy phải lưu địa chỉ hợp đồng triển khai ở đâu đó trong bộ nhớ lưu trữ lâu dài của hợp đồng.Vị trí lưu trữ không được trùng với biến của hợp đồng triển khai.

ERC-1967 xác định các slot lưu trữ chuẩn cho thông tin hợp đồng triển khai, beacon và quản trị viên của proxy.

Các vị trí này được chọn để tránh những slot thông thường do trình biên dịch Solidity gán.Slot chuẩn cũng giúp block explorer và công cụ phát triển nhận diện mối quan hệ proxy.Sử dụng slot lưu trữ đã thiết lập giúp giảm va chạm ngoài ý muốn nhưng không loại bỏ mọi rủi ro nâng cấp.Các phiên bản hợp đồng triển khai vẫn phải duy trì bố cục lưu trữ tương thích.

Rủi ro về bố cục lưu trữ

Proxy giữ dữ liệu hiện có khi hợp đồng triển khai được nâng cấp.Hợp đồng triển khai mới phải diễn giải dữ liệu đã lưu theo cùng cách với phiên bản trước.Thay đổi thứ tự biến trạng thái hiện có có thể khiến một giá trị bị đọc thành giá trị khác.Thay đổi kiểu biến có thể làm sai ý nghĩa hoặc khiến biến không thể truy cập.Thay đổi kế thừa cũng có thể làm thay đổi bố cục lưu trữ dự kiến.Cần thêm biến trạng thái mới theo quy tắc lưu trữ của kiến trúc proxy đã chọn.Giao dịch nâng cấp có thể thành công ở cấp độ giao dịch nhưng âm thầm làm hỏng dữ liệu lưu trữ hợp đồng.Vì vậy, phải kiểm tra tính tương thích của bộ nhớ lưu trữ trước mỗi lần cập nhật hợp đồng triển khai.

Va chạm function selector

Function selector chỉ có bốn byte.Về lý thuyết, hai chữ ký hàm khác nhau có thể tạo cùng selector.Hiện tượng này gọi là va chạm selector.Va chạm đặc biệt quan trọng khi cả proxy lẫn hợp đồng triển khai đều định nghĩa các hàm có thể gọi.Proxy có thể chặn selector mà người dùng dự kiến gửi đến hợp đồng triển khai.ERC-1967 giải thích rằng xung đột selector có thể tạo phản hồi ngoài dự kiến và thậm chí che giấu hành vi độc hại của proxy.Nhà phát triển nên kiểm thử toàn bộ selector giữa hàm proxy, hàm hợp đồng triển khai, hàm quản trị và các bản nâng cấp dự kiến.Chỉ dựa vào tên hàm không đủ để chứng minh selector là duy nhất giữa nhiều hợp đồng.

Rủi ro quyền nâng cấp

Proxy có thể nâng cấp thường có tài khoản hoặc cơ chế quản trị được quyền thay đổi địa chỉ hợp đồng triển khai.Bên kiểm soát quyền đó có thể thay đổi mã được thực thi thông qua fallback function.Khóa nâng cấp bị xâm phạm có thể cài đặt hợp đồng triển khai chuyển tài sản hoặc thay đổi số dư tài khoản.Quản trị viên độc hại cũng có thể thay logic hợp lệ bằng logic gây hại.Người dùng nên kiểm tra địa chỉ quản trị viên, ngưỡng người ký, quy trình quản trị, thời gian trì hoãn thực thi, quyền khẩn cấp và lịch sử nâng cấp.Fallback function của proxy đã được xác minh không bảo đảm mọi hợp đồng triển khai trong tương lai đều an toàn.Khả năng nâng cấp kéo theo nhu cầu tin cậy liên tục vào quản trị và vận hành.

Fallback Function trong hợp đồng Diamond

Hợp đồng Diamond định tuyến các function selector khác nhau đến nhiều hợp đồng triển khai được gọi là facet.Fallback function kiểm tra selector đầu vào và xác định facet phụ trách hàm đó.Sau đó, hàm chuyển tiếp lệnh gọi đến facet đã chọn thông qua delegatecall.

ERC-2535 xác định kiến trúc proxy đa facet cho hệ thống hợp đồng thông minh mô-đun.

Thiết kế này có thể hỗ trợ ứng dụng chứa lượng logic lớn hơn khả năng đáp ứng thuận tiện của một hợp đồng triển khai.Các nhóm hàm riêng lẻ cũng có thể được thêm, thay thế hoặc gỡ bỏ.Tính linh hoạt làm tăng độ phức tạp về selector, bộ nhớ lưu trữ, khởi tạo, quyền hạn và nâng cấp.Chỉ kiểm tra một facet sẽ không cho thấy mọi hành vi có thể truy cập thông qua địa chỉ Diamond.

Fallback Function trong tài khoản thông minh mô-đun

Tài khoản hợp đồng thông minh có thể dùng bộ xử lý fallback để bổ sung tính năng mô-đun.Bộ xử lý có thể hỗ trợ chữ ký, callback token, khôi phục tài khoản, quyền phiên hoặc giao diện dành riêng cho ứng dụng.

ERC-7579 mô tả fallback handler là mô-đun mở rộng chức năng tài khoản thông minh.

Tài khoản phải kiểm soát mô-đun nào được cài đặt, thay thế và gỡ bỏ.Handler không được ủy quyền có thể tạo đường dẫn dẫn đến hành vi tài khoản ngoài dự kiến.Người dùng ví nên hiểu rằng thay đổi mô-đun fallback có thể làm thay đổi cách tài khoản phản hồi lệnh gọi bên ngoài.

Gas và Fallback Function

Fallback function có thể thực hiện thao tác phức tạp nếu bên gọi cung cấp đủ gas.Hàm không nên giả định mọi bên gọi đều cung cấp cùng lượng gas.Một số phương thức chuyển tiền mã hóa cũ chỉ chuyển một lượng gas nhỏ cho hợp đồng nhận.Tài liệu Solidity hiện hành cảnh báo send và transfer đã bị đánh dấu lỗi thời và dự kiến bị loại bỏ.Lượng gas nhỏ có thể không đủ để cập nhật lưu trữ, chuyển tiền bổ sung, tạo hợp đồng hoặc gọi bên ngoài tốn kém.Chi phí gas cũng có thể thay đổi sau các lần nâng cấp mạng.Vì vậy, đường dẫn thanh toán không nên phụ thuộc vào logic fallback phức tạp.Nhà phát triển không nên xem giới hạn gas nhỏ là biện pháp duy nhất chống callback độc hại.

Rủi ro reentrancy trong Fallback Function

Fallback function có thể gọi hợp đồng khác khi có đủ gas.Hàm có thể gọi lại hợp đồng ban đầu gửi tiền mã hóa hoặc khởi tạo tương tác.Điều này có thể tạo reentrancy nếu hợp đồng gửi chưa hoàn tất hạch toán trước lệnh gọi bên ngoài.

Hướng dẫn bảo mật Solidity về reentrancy giải thích rằng lệnh gọi hợp đồng bên ngoài có thể trả quyền điều khiển lại trước khi thao tác ban đầu hoàn tất.

Hợp đồng nên xác thực điều kiện trước khi thực hiện lệnh gọi bên ngoài.Hợp đồng nên cập nhật trạng thái nội bộ quan trọng trước khi trao quyền điều khiển cho hợp đồng không đáng tin cậy.Biện pháp chống reentrancy phù hợp có thể tạo thêm một lớp bảo vệ.Cần xem mọi lệnh gọi bên ngoài là khả năng thực thi mã không đáng tin cậy.

Rủi ro từ chối dịch vụ

Fallback function có thể revert do cố ý hoặc vô tình.Nếu hợp đồng khác yêu cầu khoản thanh toán phải thành công trước khi hoàn tất thao tác lớn hơn, bên nhận có thể chặn thao tác đó.Fallback function cũng có thể tiêu thụ quá nhiều gas hoặc thực hiện lệnh gọi bên ngoài tốn kém.Điều này đặc biệt nguy hiểm khi một lần thanh toán thất bại khiến toàn bộ vòng lặp phân phối bị revert.

Hướng dẫn của Solidity về gửi và nhận tiền mã hóa khuyến nghị dùng thiết kế cho phép rút tiền đối với nhiều hệ thống thanh toán.

Mô hình rút tiền cho phép từng người nhận tự nhận tiền.Khi đó, hành vi fallback của một người nhận ít có khả năng cản trở khoản thanh toán của người khác.

Lệnh gọi cấp thấp thành công ngoài dự kiến

Lệnh gọi cấp thấp báo liệu việc thực thi mục tiêu thành công hay revert.Kết quả thành công không chứng minh hàm có tên được yêu cầu thực sự tồn tại.Selector không xác định có thể đến fallback function dễ dãi và hoàn tất thành công.Hợp đồng gọi chỉ kiểm tra trạng thái thành công có thể nhầm rằng thao tác được yêu cầu đã diễn ra.Nhà phát triển nên xác thực dữ liệu trả về và các thay đổi trạng thái dự kiến khi dùng lệnh gọi cấp thấp.Giao diện định kiểu thường an toàn hơn khi đã biết hàm mục tiêu.

Fallback Function và tiền mã hóa gốc

Fallback function payable có thể nhận tiền mã hóa gốc qua lệnh gọi không khớp.Nếu không có receive function, hàm cũng có thể xử lý giao dịch chuyển tiền thông thường với calldata rỗng.Hợp đồng không có receive hoặc fallback function payable thường từ chối giao dịch chuyển tiền trực tiếp thông thường.Tuy nhiên, hợp đồng không thể bảo đảm số dư luôn bằng không.EVM có các cách đặc biệt để tăng số dư hợp đồng mà không thực thi logic receive hoặc fallback.Hạch toán nội bộ của hợp đồng không nên giả định số dư thực luôn bằng tổng số dư được ghi nhận qua các hàm xử lý thanh toán.

Fallback Function và token ERC-20

Chuyển token ERC-20 thông thường không gọi fallback function của hợp đồng nhận.Hợp đồng token thay đổi số dư trong bộ nhớ lưu trữ của chính nó.Hợp đồng nhận có thể có số dư token mà không thực thi bất kỳ mã nào.

ERC-20 định nghĩa việc chuyển thông qua hợp đồng token, không yêu cầu bắt buộc callback đến bên nhận.

Hợp đồng không nên phụ thuộc vào việc fallback chạy để phát hiện mọi khoản nạp token.Ứng dụng thường dùng hàm nạp riêng hoặc quy tắc hạch toán số dư khác.

Fallback Function và NFT

Một số phương thức chuyển NFT an toàn gọi hàm nhận cụ thể trên hợp đồng đích.Hàm nhận này khác fallback function chung.Nếu thiếu hàm nhận dự kiến, lệnh gọi có thể đến fallback vì selector không khớp.Fallback dễ dãi không nên giả lập hỗ trợ nhận NFT trừ khi hợp đồng chủ ý triển khai hành vi cần thiết.Phản hồi không chính xác có thể khiến giao dịch chuyển bị revert hoặc gây vấn đề thu hồi tài sản.

Fallback Function có thể phát sự kiện không?

Fallback function có thể phát sự kiện khi nhận khoản thanh toán hoặc lệnh gọi không được hỗ trợ.Sự kiện có thể ghi lại người gửi, số tiền chuyển, selector hoặc giá trị hữu ích khác.Thông tin này có thể giúp nhà phát triển theo dõi tích hợp và điều tra hoạt động ngoài dự kiến.Phát sự kiện tiêu tốn gas và có thể thất bại nếu bên gọi cung cấp lượng gas rất hạn chế.Sự kiện on-chain là công khai, không nên xem là hồ sơ bảo mật.Ghi toàn bộ calldata cũng có thể gây chi phí không cần thiết vì dữ liệu giao dịch vốn đã có thể quan sát công khai.

Fallback Function có thể sửa bộ nhớ lưu trữ không?

Fallback function có thể sửa bộ nhớ lưu trữ hợp đồng khi có đủ gas.Hàm có thể cập nhật bộ đếm, hồ sơ thanh toán, quyền hạn, thông tin định tuyến hoặc trạng thái khác.Sửa bộ nhớ lưu trữ làm tăng mức tiêu thụ gas và mở rộng ảnh hưởng bảo mật của hàm.Fallback thay đổi trạng thái quan trọng cần có kiểm soát quyền truy cập rõ ràng và điều kiện được kiểm thử kỹ.Không nên để hành vi nhận thanh toán phụ thuộc vào thao tác ghi bộ nhớ lưu trữ khi bên gọi có thể chỉ cung cấp lượng gas hạn chế.

Fallback Function có thể được kế thừa không?

Fallback function có thể tham gia cơ chế kế thừa của Solidity.Hàm có thể được khai báo virtual và thay thế trong hợp đồng dẫn xuất.Hàm cũng có thể sử dụng modifier.Kế thừa có thể khiến hành vi gọi cuối cùng khó hiểu khi nhiều hợp đồng cùng đóng góp logic liên quan.Kiểm toán viên nên xem xét toàn bộ cấu trúc kế thừa đã biên dịch thay vì chỉ đọc một tệp mã nguồn.

Cách kiểm thử Fallback Function

Nhà phát triển nên kiểm thử lệnh gọi có selector bốn byte không xác định.Cần kiểm thử calldata ngắn hơn bốn byte.Cần kiểm thử calldata rỗng không đính kèm tiền mã hóa.Cần kiểm thử calldata rỗng có đính kèm tiền mã hóa.Cần kiểm thử calldata không rỗng, không khớp, có và không có giá trị đính kèm.Cần xác minh sự khác biệt định tuyến khi có receive function.Proxy cần được kiểm thử để bảo đảm chuyển tiếp chính xác dữ liệu trả về và dữ liệu lỗi.Kiểm thử nâng cấp phải xác nhận toàn bộ dữ liệu lưu trữ hiện có vẫn hợp lệ.Kiểm thử bảo mật cần bao gồm reentrancy, va chạm selector, calldata sai định dạng, nâng cấp trái phép và thiếu gas.

Cách kiểm toán Fallback Function

Trước tiên, cuộc kiểm toán cần xác định mọi loại lệnh gọi có thể đến fallback function.Kiểm toán viên cần xác định hàm có phải payable hay không.Cần kiểm tra hợp đồng có receive function riêng hay không.Cần xem xét mọi thao tác cập nhật lưu trữ, lệnh gọi bên ngoài, modifier, thao tác assembly và kiểm tra quyền hạn.Kiểm toán proxy phải xác minh cách chọn địa chỉ hợp đồng triển khai.Người dùng trái phép không được phép thay đổi mục tiêu delegatecall.Dữ liệu trả về và dữ liệu lỗi phải được chuyển tiếp chính xác.Các lần nâng cấp hợp đồng triển khai phải duy trì khả năng tương thích của bộ nhớ lưu trữ.Quy trình rà soát cũng cần kiểm tra quản trị viên, quy trình quản trị, thời gian trì hoãn nâng cấp và biện pháp kiểm soát khẩn cấp.

Thực tiễn tốt nhất khi dùng Fallback Function

Khi có thể, hãy dùng hàm có tên thông thường cho hành vi ứng dụng thường ngày.Định nghĩa receive function riêng nếu hợp đồng chủ ý nhận khoản chuyển tiền mã hóa gốc thông thường.Từ chối selector không được hỗ trợ nếu không cần định tuyến tùy chỉnh.Giữ logic fallback liên quan đến thanh toán đơn giản.Xem mọi calldata và bên gọi là không đáng tin cậy.Xác thực selector và độ dài dữ liệu trước khi giải mã thủ công.Dùng tiêu chuẩn proxy đã được kiểm chứng thay vì tự tạo logic chuyển tiếp chưa kiểm thử.Bảo vệ các vị trí lưu trữ của hợp đồng triển khai, quản trị viên và beacon.Duy trì bố cục lưu trữ tương thích qua các lần nâng cấp.Áp dụng kiểm soát quyền truy cập rõ ràng cho mọi hàm nâng cấp.Chuyển tiếp chính xác dữ liệu thành công và dữ liệu lỗi khi định tuyến lệnh gọi.Cập nhật trạng thái theo thứ tự an toàn và áp dụng biện pháp chống reentrancy phù hợp.Kiểm thử các lệnh gọi bất thường mà giao diện ví thông thường có thể không bao giờ tạo ra.

Dùng trình biên dịch Solidity ổn định mới nhất và xem danh sách lỗi trình biên dịch đã biết chính thức.

Các lỗi thường gặp với Fallback Function

Một lỗi thường gặp là cho rằng fallback chạy sau khi hàm đã khớp bị revert.Lỗi khác là đánh dấu hàm payable nhưng không có hệ thống rút tiền an toàn.Một số hợp đồng nhận khoản chuyển thông thường thông qua fallback mà không định nghĩa receive function rõ ràng hơn.Giải mã calldata thủ công có thể được thực hiện mà không kiểm tra độ dài dữ liệu.Bên gọi cấp thấp có thể nhầm việc fallback thực thi thành công với việc hàm được yêu cầu thực thi thành công.Proxy có thể lưu địa chỉ hợp đồng triển khai ở vị trí trùng với trạng thái ứng dụng.Nâng cấp có thể sắp xếp lại biến và làm hỏng số dư hoặc quyền hạn.Địa chỉ delegatecall không bị hạn chế có thể cho phép thực thi mã tùy ý trong ngữ cảnh proxy.Fallback phức tạp có thể thất bại khi nhận ít gas hơn dự kiến.Nhà phát triển có thể nhầm rằng giao dịch chuyển ERC-20 sẽ kích hoạt fallback.

Những hiểu lầm phổ biến về Fallback Function

Fallback function không phải bộ xử lý lỗi hợp đồng thông minh toàn diện.Hàm không được gọi sau mọi giao dịch thất bại.Hàm không tự động là payable.Hàm không phải lúc nào cũng phù hợp để nhận khoản chuyển tiền mã hóa thông thường.Một hợp đồng chỉ có thể chứa một fallback function.Fallback function không có function selector thông thường.Hàm có thể xử lý calldata không khớp ngay cả khi không chuyển tiền mã hóa.Fallback thành công không chứng minh bên gọi đã sử dụng giao diện hợp đồng chính xác.Fallback proxy có thể đưa người dùng đến mã không được lưu tại địa chỉ proxy.Chỉ xác minh mã nguồn của proxy không chứng minh hợp đồng triển khai hiện tại an toàn.

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

Fallback function trong Solidity là gì?

Đây là hàm external đặc biệt xử lý lệnh gọi không khớp với hàm khác trong hợp đồng thông minh.

Khi nào fallback function chạy?

Hàm chạy khi không có hàm đã khai báo nào khớp selector được cung cấp, hoặc khi calldata rỗng và không có receive function.

Một hợp đồng có thể có nhiều fallback function không?

Không. Hợp đồng Solidity chỉ có thể có tối đa một fallback function.

Fallback function có tên không?

Không. Hàm được khai báo bằng từ khóa fallback thay vì tên hàm thông thường.

Fallback function bắt buộc phải là external không?

Có. Fallback function phải có phạm vi hiển thị external.

Fallback function có tự động là payable không?

Không. Hàm chỉ nhận tiền mã hóa gốc khi được đánh dấu payable rõ ràng.

Điều gì xảy ra khi gửi giá trị đến fallback không payable?

Lệnh gọi không khớp sẽ revert khi cố chuyển một lượng khác 0.

Fallback khác receive như thế nào?

Receive xử lý calldata rỗng, còn fallback chủ yếu xử lý lệnh gọi không khớp với hàm đã khai báo.

Hàm nào xử lý giao dịch chuyển tiền mã hóa thông thường?

Nếu có, receive function sẽ xử lý; fallback payable chỉ xử lý khi không có receive function.

Fallback có chạy sau khi hàm khác thất bại không?

Không. Lỗi bên trong hàm đã khớp không chuyển việc thực thi sang fallback.

Fallback có thể kiểm tra dữ liệu giao dịch không?

Có. Hàm có thể truy cập toàn bộ calldata do bên gọi cung cấp.

Fallback có thể trả dữ liệu không?

Có. Dạng nâng cao có thể trả byte thô trực tiếp cho bên gọi.

Vì sao hợp đồng proxy dùng fallback?

Proxy dùng fallback để chuyển tiếp lệnh gọi của người dùng đến hợp đồng triển khai qua delegatecall.

Delegatecall duy trì những gì?

Delegatecall duy trì người gửi và giá trị ban đầu, đồng thời thực thi mã hợp đồng triển khai trên bộ nhớ lưu trữ và số dư của proxy.

Delegatecall có sửa bộ nhớ lưu trữ của hợp đồng triển khai không?

Không. Mã hợp đồng triển khai được gọi ủy quyền thường đọc và ghi bộ nhớ lưu trữ của proxy gọi nó.

Hợp đồng triển khai là gì?

Đây là hợp đồng chứa logic kinh doanh được thực thi thông qua proxy có thể nâng cấp.

Va chạm selector là gì?

Hiện tượng này xảy ra khi các chữ ký hàm khác nhau tạo cùng selector bốn byte.

Vì sao bố cục lưu trữ quan trọng?

Bố cục không tương thích có thể khiến hợp đồng triển khai sau nâng cấp đọc sai hoặc ghi đè dữ liệu proxy hiện có.

Fallback có thể gây reentrancy không?

Có. Khi có đủ gas, hàm có thể gọi lại một hợp đồng khác.

Fallback có thể từ chối khoản thanh toán không?

Có. Fallback không payable hoặc fallback chủ động revert có thể từ chối khoản thanh toán thông thường qua message-call.

Hợp đồng có thể ngăn mọi trường hợp tăng số dư không?

Không. Một số cơ chế EVM có thể tăng số dư hợp đồng mà không thực thi logic receive hoặc fallback.

Giao dịch chuyển ERC-20 có kích hoạt fallback không?

Thông thường là không, vì hợp đồng token cập nhật số dư mà không gọi hợp đồng nhận.

Fallback có thể phát sự kiện không?

Có, nếu lệnh gọi cung cấp đủ gas cho thao tác phát sự kiện.

Fallback có thể cập nhật bộ nhớ lưu trữ không?

Có, nhưng thao tác này làm tăng chi phí và có thể thất bại khi lượng gas khả dụng hạn chế.

Fallback có thể dùng modifier không?

Có. Fallback function có thể sử dụng modifier Solidity.

Fallback có thể được kế thừa không?

Có. Hàm có thể được khai báo virtual và ghi đè trong hợp đồng dẫn xuất.

Lệnh gọi cấp thấp thành công có chứng minh hàm được yêu cầu tồn tại không?

Không. Selector không xác định có thể đã được fallback function chấp nhận.

Mọi hợp đồng thông minh có nên có fallback function không?

Không. Chỉ nên định nghĩa hàm này khi cần xử lý tùy chỉnh các lệnh gọi không khớp.

Fallback function có an toàn trong hợp đồng có thể nâng cấp không?

Hàm có thể an toàn khi logic chuyển tiếp, bố cục lưu trữ, hợp đồng triển khai và quyền nâng cấp được thiết kế cũng như kiểm toán chính xác.

Rủi ro lớn nhất của Fallback Function là gì?

Rủi ro lớn nhất tùy thuộc mục đích sử dụng, nhưng ủy quyền proxy, lệnh gọi bên ngoài không giới hạn, nâng cấp không an toàn và hành vi thanh toán ngoài dự kiến đều có thể nghiêm trọng.

Kết luận

Fallback function là điểm truy cập Solidity đặc biệt dành cho lệnh gọi bên ngoài không khớp với hàm hợp đồng thông minh đã khai báo khác.Hàm cũng có thể xử lý calldata rỗng nếu hợp đồng không định nghĩa receive function.Fallback payable có thể nhận tiền mã hóa gốc, còn fallback không payable từ chối lệnh gọi không khớp có đính kèm giá trị.Receive function thường là lựa chọn rõ ràng hơn cho giao dịch chuyển tiền mã hóa thông thường có chủ đích.Fallback function thiết yếu với proxy có thể nâng cấp vì có thể chuyển tiếp lệnh gọi đến hợp đồng triển khai thông qua delegatecall.Quy trình này giữ nguyên người gửi và giá trị ban đầu trong khi thực thi mã hợp đồng triển khai trên bộ nhớ lưu trữ của proxy.Định tuyến fallback dựa trên proxy tạo ra rủi ro về bố cục lưu trữ, va chạm selector, quyền nâng cấp và delegatecall.Fallback function cũng có thể dẫn đến vấn đề reentrancy, từ chối dịch vụ, gas, giải mã và lệnh gọi ngoài dự kiến nhưng thành công.Nhà phát triển nên giới hạn phạm vi hoạt động của fallback, từ chối lệnh gọi không được hỗ trợ khi phù hợp và dùng hàm có tên thông thường cho logic ứng dụng thường ngày.Hiểu fallback function là điều thiết yếu khi đánh giá hợp đồng thông minh tiền mã hóa vì điểm truy cập không tên này có thể kiểm soát thanh toán, định tuyến proxy, hành vi tài khoản mô-đun và quá trình thực thi toàn bộ ứng dụng phi tập trung.