Bạn nghĩ một bản cập nhật Oracle chỉ là bảo trì thường lệ? Sai rồi. Khi Lido hoàn thành rebase stETH và phát hành bản vá Oracle, tôi nhìn thấy một cuộc chiến thầm lặng giữa hiệu quả và rủi ro tập trung hóa. 28 năm trong ngành dạy tôi một điều: không có bản vá nào vô hại, đặc biệt là khi nó chạm vào cốt lõi của liquid staking.
Lido, giao thức liquid staking lớn nhất trên Ethereum, vừa thực hiện hai thao tác: rebase stETH (phân phối phần thưởng validator cho người nắm giữ) và cập nhật thành phần Oracle để cải thiện độ chính xác báo cáo. Rebasing là cơ chế cốt lõi của stETH: mỗi ngày, Oracle ghi nhận số dư validator trên Beacon Chain, tính toán phần thưởng và điều chỉnh số dư stETH tương ứng. Điều này làm stETH trở thành một ERC-20 tái định giá liên tục, khác với rETH của Rocket Pool không có rebase. Oracle ở đây đóng vai trò cầu nối giữa lớp đồng thuận Ethereum (lớp 0) và lớp thực thi (lớp 1). Độ chính xác của báo cáo quyết định tính chính xác của giá stETH, và do đó, ảnh hưởng đến hàng tỷ USD thanh khoản DeFi.
Hãy đào sâu vào mã nguồn. Bản cập nhật này không được tiết lộ chi tiết, nhưng dựa trên kinh nghiệm audit của tôi với các hệ thống Oracle (bao gồm cả lỗ hổng trong EtherDelta v2 năm 2017), tôi tin rằng nó xoay quanh việc xử lý dữ liệu từ Shapella upgrade. Sau Shapella, việc rút tiền từ Beacon Chain trở nên phức tạp hơn: validator có thể rút một phần tiền gốc và phần thưởng, tạo ra nhiều loại giao dịch rút khác nhau. Oracle của Lido phải báo cáo chính xác số dư sau mỗi epoch (khoảng 6.4 phút), nhưng nếu có lỗi trong việc giải mã bằng chứng rút tiền, số dư stETH có thể sai lệch. Bản cập nhật này có thể là để giảm độ trễ báo cáo hoặc thêm cơ chế xác thực chéo giữa các node Oracle. Mã nguồn không bao giờ hết lỗi, và mỗi lần cập nhật là một cơ hội cho lỗi mới – đó là sự thật phũ phàng mà 90% developer không muốn đối mặt.
Ngược với suy nghĩ thông thường rằng cập nhật Oracle là tin tốt cho độ tin cậy, tôi cho rằng nó làm tăng bề mặt tấn công. Oracle của Lido hiện có 21 node, yêu cầu 2/3 chữ ký để tạo báo cáo. Bản cập nhật này, nếu thay đổi logic đồng thuận hoặc tần suất báo cáo, có thể vô tình tạo ra vector tấn công mới. Hãy nhìn vào bài học từ lịch sử: năm 2022, một lỗi trong Oracle của một giao thức lending đã khiến giá sụp đổ. Khi bạn kiểm tra mã nguồn, bạn sẽ thấy sự thật phũ phàng: không có code sạch, chỉ có code ít lỗi hơn. Lido là giao thức an toàn nhất trong liquid staking, nhưng điều đó không có nghĩa là miễn nhiễm với lỗi logic – đặc biệt khi Oracle là điểm tập trung hóa duy nhất trong thiết kế phi tập trung.
Vậy takeaway là gì? Lido đang chơi trò cân bằng: càng cải thiện độ chính xác, càng phụ thuộc vào Oracle – và Oracle là một tập hợp các node có thể bị tấn công hoặc thao túng. Trong 28 năm quan sát ngành, tôi chưa từng thấy một Oracle nào hoàn hảo. Điều này đặt ra câu hỏi: đến khi nào Lido phải đối mặt với áp lực phi tập trung hóa Oracle, thậm chí dẫn đến hard fork hay tách rời? Có thể bản cập nhật này chỉ là bước đi nhỏ, nhưng nó phơi bày mâu thuẫn nội tại của mọi liquid staking protocol: chính xác hay phi tập trung? Bạn không thể có cả hai.