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

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 các hệ thống Enterprise, dữ liệu thường đến từ nhiều nguồn quốc tế hóa khác nhau. Việc sử dụng indexOf hoặc includes chỉ so sánh dựa trên giá trị mã code point (mã số của ký tự) đơn thuần. Vấn đề phát sinh khi một ký tự có thể được biểu diễn bằng nhiều cách khác nhau trong Unicode (ví dụ: ký tự 'é' có thể là một ký tự đơn hoặc tổ hợp của 'e' và dấu sắc). Nếu không thực hiện chuẩn hóa (Normalization) trước khi so sánh, hai chuỗi trông giống nhau có thể bị coi là khác biệt. Giải pháp là sử dụng phương thức normalize('NFC') hoặc 'NFD' để đưa các chuỗi về cùng một định dạng chuẩn trước khi thực hiện so sánh hoặc tìm kiếm.

Trong hầu hết các ngôn ngữ như Java hoặc C#, kiểu dữ liệu String là immutable (bất biến). Khi một chuỗi được tạo ra, nó sẽ nằm trong String Pool của bộ nhớ cho đến khi Garbage Collection thực hiện thu dọn. Nếu dữ liệu nhạy cảm nằm trong String, chúng ta không thể chủ động xóa sạch (zero-out) bộ nhớ sau khi sử dụng xong. Nếu xảy ra hiện tượng dump bộ nhớ, các thông tin nhạy cảm này sẽ bị lộ. Ngược lại, với mảng ký tự (char array), lập trình viên có thể chủ động ghi đè các giá trị bằng 0 ngay sau khi xử lý xong, giúp giảm thiểu rủi ro lộ thông tin nhạy cảm trong bộ nhớ.

Do tính chất bất biến (immutability) của chuỗi trong nhiều ngôn ngữ lập trình, mỗi khi bạn thực hiện các thao tác như nối chuỗi (+), thay thế (replace) hoặc cắt chuỗi, một đối tượng chuỗi mới sẽ được tạo ra trong bộ nhớ thay vì sửa đổi chuỗi cũ. Trong một vòng lặp lớn, việc này tạo ra hàng ngàn đối tượng tạm thời (temporary objects) không cần thiết. Điều này làm tăng áp lực lên cơ chế Garbage Collection, dẫn đến việc ứng dụng thường xuyên bị khựng (Stop-the-world) để dọn dẹp bộ nhớ. Giải pháp tối ưu là sử dụng các lớp chuyên dụng như StringBuilder hoặc StringBuffer để thao tác trên cùng một vùng nhớ.

Dữ liệu người dùng nhập vào thường chứa các khoảng trắng thừa ở đầu hoặc cuối do sơ suất khi gõ phím hoặc copy-paste. Nếu không sử dụng trim(), các khoảng trắng này sẽ được lưu vào cơ sở dữ liệu. Điều này dẫn đến các lỗi logic nghiêm trọng như: 1. Sai lệch khi so sánh dữ liệu (ví dụ: 'admin ' không bằng 'admin'). 2. Lỗi khi kiểm tra tính duy nhất (Unique constraint) trong database. 3. Gây khó khăn cho việc tìm kiếm dữ liệu. Trong Enterprise, việc chuẩn hóa dữ liệu ngay tại tầng tiếp nhận (Input Validation) bằng cách trim() là quy tắc bắt buộc để đảm bảo tính toàn vẹn của dữ liệu.

Khi các dịch vụ giao tiếp với nhau, nếu không thống nhất chuẩn mã hóa (Encoding), dữ liệu chuỗi có thể bị lỗi hiển thị (mojibake) hoặc mất mát thông tin khi chuyển đổi qua lại giữa các hệ thống có cấu hình mặc định khác nhau (ví dụ: Windows-1252 vs UTF-8). UTF-8 là chuẩn công nghiệp cho phép biểu diễn mọi ký tự Unicode, đảm bảo tính tương thích cao nhất. Việc không tuân thủ chuẩn này không chỉ gây lỗi hiển thị mà còn có thể dẫn đến các lỗ hổng bảo mật khi các ký tự đặc biệt bị hiểu sai trong quá trình xử lý tại tầng Middleware hoặc Database, gây ra các lỗi Injection không mong muốn.

Trong quá trình phát triển phần mềm, việc lựa chọn đúng phương thức xử lý mảng đóng vai trò quyết định đến hiệu năng và tính chính xác của mã nguồn, đặc biệt khi xử lý các tập dữ liệu lớn.

Khi làm việc với các cấu trúc dữ liệu phức tạp, việc sao chép mảng là nhu cầu thường xuyên. Tuy nhiên, lập trình viên cấp độ Junior thường hay vướng phải lỗi liên quan đến bản sao nông (Shallow Copy) và bản sao sâu (Deep Copy).

Việc lựa chọn đúng phương thức kiểm tra mảng giúp mã nguồn ngắn gọn, dễ đọc và tối ưu hóa thời gian thực thi của chương trình.

Một trong những cạm bẫy kinh điển đối với lập trình viên mới bắt đầu khi làm việc với mảng trong JavaScript là cơ chế sắp xếp mặc định của phương thức sort().

Trong các ứng dụng web hiện đại, đặc biệt là khi làm việc với các thư viện quản lý trạng thái hoặc framework như React, việc thay đổi trực tiếp mảng gốc (Mutation) gây ra nhiều hệ lụy nghiêm trọng về mặt kiểm soát luồng dữ liệu và hiệu năng render.