Thư Viện Câu Hỏi Phỏng Vấn

Trong lập trình giải thuật với Blockchain, việc làm chủ Smart Contracts yêu cầu lập trình viên hiểu rõ cấu trúc vật lý trong bộ nhớ và độ phức tạp tính toán:

Việc sử dụng tx.origin để kiểm tra quyền truy cập là một lỗ hổng bảo mật kinh điển vì nó đại diện cho địa chỉ tài khoản đã khởi tạo giao dịch ban đầu, không phải địa chỉ của Smart Contract đang gọi hàm. Kẻ tấn công có thể tạo một hợp đồng trung gian (Attacker Contract) để lừa người dùng (hoặc chủ sở hữu hợp đồng) thực hiện một giao dịch gọi vào hợp đồng của kẻ tấn công. Khi đó, tx.origin vẫn là địa chỉ của người dùng, khiến các hàm kiểm tra quyền bị vượt qua. Thay vào đó, hãy luôn sử dụng msg.sender để xác thực vì nó đại diện cho thực thể trực tiếp gọi vào hàm hiện tại. Ví dụ: thay vì require(tx.origin == owner), hãy dùng require(msg.sender == owner).

Shadowing xảy ra khi một biến trong phạm vi con (ví dụ: biến cục bộ hoặc biến trong hợp đồng kế thừa) có cùng tên với một biến trong phạm vi cha hoặc phạm vi toàn cục. Điều này khiến trình biên dịch ghi đè hoặc gây nhầm lẫn khi truy xuất giá trị, dẫn đến việc hợp đồng đọc sai dữ liệu lưu trữ. Để tránh điều này, cần tuân thủ quy tắc đặt tên rõ ràng, sử dụng tiền tố (như hoặc m) cho các biến trạng thái hoặc biến tham số. Trình biên dịch Solidity hiện đại sẽ đưa ra cảnh báo (warning) khi phát hiện shadowing; nhà phát triển tuyệt đối không được bỏ qua các cảnh báo này để đảm bảo tính toàn vẹn của dữ liệu.

Blockchain là môi trường tất định (deterministic), nghĩa là mọi node đều phải tính toán ra cùng một kết quả. Các biến như block.timestamp, block.difficulty hay blockhash đều có thể bị thao túng bởi các thợ đào (miners) hoặc validator để thay đổi kết quả ngẫu nhiên theo ý muốn. Để tạo số ngẫu nhiên an toàn trong Enterprise, cần sử dụng các giải pháp Oracle phi tập trung như Chainlink VRF (Verifiable Random Function). Chainlink VRF cung cấp bằng chứng mã hóa chứng minh tính ngẫu nhiên của con số được tạo ra, đảm bảo tính công bằng và không thể bị can thiệp bởi bất kỳ bên nào.

Lưu trữ dữ liệu vào Storage (biến trạng thái) là thao tác tốn kém nhất trong Solidity vì dữ liệu được ghi vĩnh viễn vào trạng thái của blockchain và mọi node đều phải lưu trữ. Ngược lại, Event là cơ chế ghi dữ liệu vào log của giao dịch. Dữ liệu trong Event không thể được truy cập bởi các Smart Contract khác, nhưng nó rẻ hơn đáng kể và cho phép các ứng dụng Frontend (thông qua Web3.js hoặc Ethers.js) truy vấn dữ liệu lịch sử một cách hiệu quả. Kinh nghiệm thực chiến là chỉ lưu trữ vào Storage những dữ liệu cần thiết cho logic của hợp đồng, còn lại hãy sử dụng Event để lưu trữ dữ liệu phục vụ mục đích hiển thị hoặc phân tích.

Modifier giúp tách biệt logic kiểm tra (validation logic) ra khỏi logic nghiệp vụ chính của hàm, giúp mã nguồn trở nên sạch sẽ, dễ đọc và dễ bảo trì (DRY - Don't Repeat Yourself). Về mặt bảo mật, nó đảm bảo các điều kiện tiên quyết (như kiểm tra quyền, trạng thái hợp đồng) được thực thi nhất quán trước khi code chính của hàm chạy. Nếu không sử dụng modifier, việc lặp lại các câu lệnh require() ở đầu mỗi hàm dễ dẫn đến sai sót hoặc quên kiểm tra trong các bản cập nhật sau này. Ví dụ: modifier onlyOwner { require(msg.sender == owner); _; } giúp đảm bảo tính an toàn cho các hàm quản trị quan trọng.

Bản chất của Mapping

Mapping trong Solidity hoạt động như một bảng băm (hash table) ảo. Các khóa (key) không được lưu trữ trực tiếp mà được sử dụng để tính toán vị trí lưu trữ thông qua hàm băm Keccak-256. Do đó, không có danh sách các khóa tồn tại trong bộ nhớ, khiến việc duyệt qua (iteration) là không thể.

Phân tích kỹ thuật

• Memory: Là vùng nhớ tạm thời, dữ liệu có thể thay đổi được (mutable). Khi truyền tham số vào hàm, dữ liệu được copy từ nguồn vào vùng nhớ memory.
• Calldata: Là vùng nhớ chỉ đọc (read-only), chứa dữ liệu đầu vào của giao dịch. Dữ liệu này không thể thay đổi và không tốn chi phí copy vào memory.

Tại sao ưu tiên calldata?

• Tiết kiệm Gas: Sử dụng calldata giúp tránh việc copy dữ liệu tốn kém vào memory.
• An toàn: Vì là read-only, nó đảm bảo dữ liệu đầu vào không bị thay đổi ngoài ý muốn trong quá trình thực thi hàm.

Ví dụ

function processData(string calldata input) external pure {
    // Sử dụng calldata cho tham số đầu vào không thay đổi
}

Lưu ý

Chỉ sử dụng calldata cho các tham số đầu vào của hàm (external/public). Nếu bạn cần sửa đổi dữ liệu bên trong hàm, bạn buộc phải copy nó sang memory hoặc storage.

Nguyên nhân

Các hàm transfer() và send() có giới hạn cố định là 2300 gas. Giới hạn này được thiết kế để ngăn chặn Reentrancy Attack trong quá khứ. Tuy nhiên, với các bản cập nhật của Ethereum (như EIP-1884), chi phí của các opcode có thể thay đổi, khiến 2300 gas không còn đủ để thực hiện các logic cần thiết (ví dụ: ghi vào storage hoặc gọi hàm khác).

Định nghĩa

• Gas Limit: Là số lượng gas tối đa mà người dùng sẵn sàng chi trả cho việc thực thi giao dịch. Nó đóng vai trò như một cơ chế an toàn để ngăn chặn các vòng lặp vô tận.
• Gas Price: Là số tiền (tính bằng Gwei) mà người dùng trả cho mỗi đơn vị gas để các validator ưu tiên xử lý giao dịch.

Khi vượt quá Gas Limit

Nếu giao dịch tiêu tốn nhiều gas hơn mức Gas Limit đã thiết lập, máy ảo Ethereum (EVM) sẽ dừng thực thi giao dịch ngay lập tức. Trạng thái của Smart Contract sẽ được hoàn tác (revert) về trạng thái ban đầu, nhưng toàn bộ lượng gas đã sử dụng cho đến thời điểm đó sẽ bị mất và không được hoàn lại cho người gửi.

Phân biệt

• view: Hàm được phép đọc dữ liệu từ trạng thái (storage) của contract nhưng không được phép thay đổi trạng thái đó.
• pure: Hàm không được phép đọc cũng như không được phép thay đổi trạng thái của contract. Nó chỉ thực hiện tính toán dựa trên các tham số đầu vào.

Tầm quan trọng đối với hiệu năng

• Khi gọi các hàm này từ bên ngoài (off-chain) thông qua các node, chúng không tốn gas vì không cần tạo giao dịch trên mạng lưới.
• Việc khai báo đúng giúp trình biên dịch tối ưu hóa mã bytecode và giúp các công cụ phân tích bảo mật hiểu rõ hành vi của hàm.

Ví dụ

uint256 public value;
function getValue() public view returns (uint256) { return value; } // Đọc storage
function add(uint256 a, uint256 b) public pure returns (uint256) { return a + b; } // Chỉ tính toán

Lưu ý

Nếu bạn khai báo hàm là view hoặc pure nhưng lại thực hiện ghi dữ liệu (ví dụ: thay đổi giá trị biến state), trình biên dịch sẽ báo lỗi.

Trong máy ảo Ethereum (EVM), các biến được lưu trữ trong các slot có kích thước 32 bytes (256 bits). Khi bạn sử dụng các kiểu dữ liệu nhỏ hơn như uint8, EVM vẫn phải dành ra một slot 32 bytes để lưu trữ giá trị đó. Để thực hiện các phép toán trên các kiểu dữ liệu nhỏ hơn này, EVM phải thực hiện thêm các thao tác chuyển đổi (masking) để đảm bảo dữ liệu nằm trong phạm vi cho phép, điều này tiêu tốn thêm Gas. Do đó, việc sử dụng uint256 giúp tối ưu hóa Gas bằng cách loại bỏ các bước tính toán dư thừa và tận dụng tối đa không gian lưu trữ của một slot.

Cả hai hàm đều được sử dụng để xử lý các tương tác không xác định hoặc nhận Ether trực tiếp: 1. receive(): Được kích hoạt khi một contract nhận Ether mà không kèm theo dữ liệu (data). Hàm này bắt buộc phải có từ khóa external và payable. 2. fallback(): Được kích hoạt khi một lời gọi hàm đến contract không khớp với bất kỳ hàm nào đã định nghĩa, hoặc khi nhận Ether kèm theo dữ liệu nhưng không có hàm receive. Hàm này cũng cần từ khóa external. Lưu ý: fallback có thể thực hiện các logic phức tạp hơn nhưng bị giới hạn về lượng Gas tiêu thụ nếu được gọi thông qua một lời gọi từ bên ngoài.

Mỗi giao dịch trên Ethereum đều có một giới hạn Gas (Gas Limit). Nếu một vòng lặp phụ thuộc vào độ dài của một mảng động (dynamic array) mà mảng này có thể tăng kích thước không giới hạn, thì tại một thời điểm nào đó, chi phí thực thi vòng lặp sẽ vượt quá Gas Limit của block. Điều này dẫn đến lỗi Out of Gas, khiến giao dịch bị revert hoàn toàn. Giải pháp thực chiến là sử dụng mô hình Pull-over-Push, trong đó người dùng tự rút tiền hoặc thực hiện thao tác thay vì ép buộc contract phải lặp qua một danh sách lớn để xử lý cho từng người.