Thư Viện Câu Hỏi Phỏng Vấ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 vấn đề

Khi duyệt cây bằng đệ quy, mỗi lần gọi hàm, hệ thống sẽ tạo một Stack Frame mới để lưu trữ biến cục bộ và địa chỉ trả về. Nếu cây có độ sâu quá lớn (ví dụ cây bị lệch - Skewed Tree), số lượng Stack Frame sẽ vượt quá dung lượng bộ nhớ Stack được cấp phát, gây ra lỗi Stack Overflow.

Phân tích hiệu năng

1. Hash Table: Mặc dù tìm kiếm theo khóa chính mất O(1), nhưng không hỗ trợ tìm kiếm tiền tố (Prefix Search) hiệu quả. Để tìm các từ bắt đầu bằng 'uni', bạn phải duyệt qua toàn bộ bảng băm, gây lãng phí tài nguyên.
2. Mảng: Tìm kiếm nhị phân trên mảng đã sắp xếp mất O(k * log n) với k là độ dài từ. Tuy nhiên, việc chèn thêm từ mới rất tốn kém do phải dịch chuyển phần tử.
3. Trie (Prefix Tree):
   • Độ phức tạp tìm kiếm là O(m) với m là độ dài của tiền tố, độc lập với số lượng từ có trong tập dữ liệu.
   • Chia sẻ tiền tố chung giữa các từ, giúp tiết kiệm bộ nhớ khi lưu trữ tập từ vựng lớn.

Ứng dụng thực chiến

Trong các hệ thống Enterprise, Trie thường được tối ưu bằng cách sử dụng Compressed Trie (Radix Tree) để giảm số lượng nút trung gian, từ đó giảm thiểu số lần truy cập bộ nhớ (Cache Misses) và tăng tốc độ phản hồi cho người dùng.

Bản chất của BST

Cây tìm kiếm nhị phân (BST) duy trì tính chất: mọi nút ở nhánh trái đều nhỏ hơn nút gốc, và mọi nút ở nhánh phải đều lớn hơn nút gốc. Tính chất này được bảo toàn đệ quy trên toàn bộ các cây con.

Lỗi logic thường gặp

Nhiều lập trình viên Junior thường chỉ kiểm tra điều kiện: node.left.val < node.val < node.right.val. Cách này sai vì nó không kiểm tra được các nút ở nhánh con xa hơn. Ví dụ: một nút bên phải của gốc có thể nhỏ hơn gốc, vi phạm tính chất BST.

Các trường hợp xóa nút

1. Nút lá: Chỉ cần xóa trực tiếp.
2. Nút có một con: Thay thế nút đó bằng nút con duy nhất.
3. Nút có hai con: Đây là trường hợp phức tạp nhất.

Tại sao chọn In-order Successor?

In-order Successor là nút nhỏ nhất trong cây con bên phải. Việc thay thế nút bị xóa bằng giá trị này đảm bảo:

Sự khác biệt giữa Push và Pull nằm ở việc ai là người kiểm soát luồng dữ liệu:

Priority Queue cho phép xử lý các tác vụ quan trọng trước các tác vụ thông thường dựa trên giá trị ưu tiên (Priority level).

Việc phân biệt này ảnh hưởng trực tiếp đến tính toàn vẹn dữ liệu (Data Integrity):

Head-of-Line Blocking xảy ra khi một message ở đầu hàng đợi mất quá nhiều thời gian để xử lý, làm chặn toàn bộ các message phía sau, dù các message đó có thể xử lý rất nhanh.

Cài đặt Queue bằng hai Stack (Stack In và Stack Out) là một kỹ thuật kinh điển để giải quyết bài toán FIFO (First-In-First-Out) bằng cấu trúc LIFO (Last-In-First-Out).