Nghiên cứu sâu về cấu trúc công nghệ và rủi ro an ninh của Hyperliquid
Gần đây, Hyperliquid đã thu hút được nhiều sự chú ý như một trong những sàn giao dịch order book trên chuỗi có ảnh hưởng nhất, với tổng giá trị khóa đã vượt 2 tỷ USD, được ngành công nghiệp đánh giá là "phiên bản trên chuỗi của một sàn giao dịch tập trung nổi tiếng", đồng thời cũng khơi lại cuộc thảo luận về Layer3 và chuỗi ứng dụng. Nhờ vào hiệu suất ấn tượng với giá trị dự án đạt 30 tỷ USD chỉ trong một tháng ra mắt, Hyperliquid đã nhận được sự quan tâm rộng rãi. Hiện tại, trên thị trường đã có không ít báo cáo phân tích về Hyperliquid, nhưng phần lớn tập trung vào chức năng sản phẩm và cơ chế giao dịch, thiếu đi sự phân tích sâu sắc về kiến trúc kỹ thuật và các mối nguy cơ tiềm ẩn về an ninh.
Bài viết này nhằm lấp đầy khoảng trống này, phân tích Hyperliquid từ góc độ kỹ thuật và an ninh, giúp người đọc hiểu rõ hơn về cấu trúc và nguyên lý bên trong của dự án ngôi sao này. Chúng tôi sẽ tập trung phân tích thiết kế và rủi ro của hợp đồng cầu nối chuỗi chéo Hyperliquid, cũng như kiến trúc đôi HyperEVM và HyperL1, khám phá sâu hơn cách thức thực hiện công nghệ phía sau.
Phân tích cầu liên chuỗi Hyperliquid
Do vì Hyperliquid không mở mã nguồn cho các thành phần cốt lõi, nhưng đã mở mã nguồn cho các hợp đồng cầu liên quan, nên chúng tôi có hiểu biết nhiều hơn về rủi ro liên quan đến hợp đồng cầu. Hyperliquid đã triển khai một hợp đồng cầu trên một mạng Layer2, để lưu trữ tài sản USDC mà người dùng gửi vào, chúng tôi có thể quan sát một phần hành vi của các nút Hyperliquid qua thành phần Bridge.
Tập hợp người xác thực
Về mặt phân chia danh tính nút, Hyperliquid có 4 nhóm xác thực viên, bao gồm hotValidatorSet, coldValidatorSet, finalizers và lockers, mỗi nhóm đảm nhận những trách nhiệm khác nhau. hotValidatorSet chịu trách nhiệm phản hồi các thao tác tần suất cao của người dùng như rút tiền, thường sử dụng ví nóng để kịp thời xử lý yêu cầu của người dùng.
coldValidatorSet chủ yếu được sử dụng để thay đổi cấu hình hệ thống, chẳng hạn như cập nhật danh sách các bộ xác thực khác, hoặc xử lý trạng thái khóa của hợp đồng cầu, và có quyền trực tiếp làm cho một số yêu cầu rút tiền không hợp lệ.
lockers là một nhóm các xác thực có quyền đặc biệt, tương tự như "ủy ban an ninh" phổ biến trong Layer2, có thể bỏ phiếu quyết định có tạm dừng hoạt động của cầu nối liên chuỗi trong trường hợp khẩn cấp. Hiện tại, tập hợp lockers của cầu Hyperliquid bao gồm 5 địa chỉ, chỉ cần 2 locker bỏ phiếu là có thể tạm dừng hợp đồng cầu.
finalizers cũng là một nhóm các xác thực viên đặc biệt, chủ yếu được sử dụng để xác nhận sự thay đổi trạng thái của cầu nối chuỗi chéo, chẳng hạn như các thao tác gửi và rút tiền của người dùng. Cầu nối chuỗi chéo của Hyperliquid áp dụng cơ chế "gửi - xác nhận", sau khi người dùng khởi động giao dịch rút tiền, cần phải chờ một khoảng thời gian "thời gian tranh chấp", sau khi hết thời gian này, finalizers sẽ thực hiện giao dịch rút tiền.
Nếu gặp vấn đề, như một yêu cầu rút tiền vượt quá số dư thực tế của người dùng, nút Hyperliquid có thể bỏ phiếu để tạm dừng hợp đồng cầu thông qua các lockers trong thời gian tranh chấp, hoặc do coldValidatorSet trực tiếp làm cho yêu cầu rút tiền vấn đề trở nên vô hiệu.
Hiện tại Hyperliquid chỉ có 4 nút xác thực, vì vậy hotValidatorSet và coldValidatorSet tương ứng với 4 địa chỉ trên chuỗi. Khi khởi tạo, Hyperliquid tự động đăng ký các địa chỉ trong hotValidatorSet làm thành viên của lockers và finalizers, trong khi coldValidatorSet được điều khiển bởi chính thức, sử dụng ví lạnh để lưu trữ khóa.
gửi tiền
Hợp đồng cầu của Hyperliquid được xử lý theo phương pháp Permit của EIP-2612 cho các khoản tiền gửi của người dùng, và chỉ hỗ trợ một loại tài sản duy nhất là USDC. So với mô hình Approve-Transfer truyền thống, Permit đơn giản hơn và thuận tiện cho các thao tác hàng loạt.
Hợp đồng cầu sử dụng hàm batchedDepositWithPermit để xử lý nhiều khoản gửi một cách hàng loạt, quy trình đơn giản và không có rủi ro an toàn tài chính, chủ yếu là tận dụng phương pháp Permit để tối ưu hóa trải nghiệm người dùng.
Rút tiền
So với tiền gửi, rút tiền là một hoạt động có rủi ro cao hơn, do đó logic cũng phức tạp hơn. Sau khi người dùng khởi xướng yêu cầu rút tiền, nút Hyperliquid sẽ gọi hàm batchedRequestWithdrawals của hợp đồng cầu. Lúc này yêu cầu mỗi yêu cầu rút tiền phải nhận được 2/3 trọng số chữ ký từ hotValidatorSet, lưu ý là "trọng số chữ ký 2/3" chứ không phải "số lượng chữ ký 2/3". Hiện tại, Hyperliquid chỉ có 4 nút có trọng số giống nhau, vì vậy việc kiểm tra trọng số chữ ký và số lượng chữ ký tạm thời nhất quán, nhưng trong tương lai có thể sẽ có thêm các nút có trọng số cao.
Sau khi gửi yêu cầu rút tiền, cầu nối liên chuỗi sẽ không ngay lập tức chuyển USDC, mà sẽ có "thời gian tranh chấp" 200 giây. Trong thời gian này có thể xảy ra hai tình huống:
lockers cho rằng yêu cầu rút tiền có vấn đề nghiêm trọng, có thể trực tiếp bỏ phiếu đóng băng hợp đồng;
Các nút cho rằng một số khoản rút tiền có vấn đề, các thành viên trong coldValidatorSet có thể gọi hàm invalidateWithdrawals để làm cho khoản rút tiền này không hợp lệ.
Nếu trong thời gian tranh chấp không có bất thường, sau khi kết thúc, các thành viên finalizers có thể gọi hàm batchedFinalizeWithdrawals để xác nhận trạng thái cuối cùng, lúc này USDC mới được chuyển vào địa chỉ ví của người dùng trên Layer2.
Từ góc độ mô hình an ninh, nếu kẻ tấn công độc hại muốn làm hại trong quy trình rút tiền của Hyperliquid, họ cần vượt qua ba lớp bảo vệ:
Nắm giữ quyền ký 2/3 của hotValidatorSet, tức là có đủ khóa riêng hoặc thông đồng. Hiện tại chỉ có 4 người xác thực, khả năng bị kiểm soát hoặc thông đồng không thấp;
Tránh giao dịch ác ý bị phát hiện trong thời gian tranh chấp, nếu không có thể kích hoạt hợp đồng khóa.
Lấy ít nhất một khóa riêng của thành viên finalizers, xác nhận rút tiền. Hiện tại, các thành viên finalizers về cơ bản tương đồng với các thành viên hotValidatorSet, thỏa mãn điều kiện 1 thì cũng thỏa mãn điều kiện 3.
Khóa hợp đồng cầu
Hyperliquid đã thiết lập chức năng khóa hợp đồng cầu liên chuỗi. Cụ thể, cần có thành viên lockers gọi hàm voteEmergencyLock để bỏ phiếu, hiện tại 2 thành viên lockers bỏ phiếu là đủ để khóa và tạm dừng hợp đồng cầu.
Điều đáng chú ý là cầu Hyperliquid còn cung cấp hàm unvoteEmergencyLock, cho phép những người khóa rút lại phiếu bầu. Một khi hợp đồng cầu đã bị khóa, chỉ có thể mở khóa thông qua hàm emergencyUnlock, cần thu thập hơn 2/3 trọng số chữ ký từ các thành viên coldValidatorSet.
emergencyUnlock sẽ cập nhật tập hợp địa chỉ xác thực hotValidatorSet và coldValidatorSet đồng thời khi mở khóa, và có hiệu lực ngay lập tức.
Cập nhật tập người xác thực
So với việc vượt qua quy trình rút tiền, việc sử dụng trực tiếp hàm updateValidatorSet để cập nhật tập hợp các xác thực viên là một phương thức tấn công hiệu quả hơn. Điều này yêu cầu tất cả các thành viên hotValidatorSet ký tên, và có thời gian tranh chấp là 200 giây.
Sau khi kết thúc thời gian tranh chấp, các thành viên của finalizers cần gọi hàm finalizeValidatorSetUpdate để hoàn thành cập nhật cuối cùng.
Tóm tắt các rủi ro tồn tại trong hợp đồng cầu Hyperliquid:
Hacker có thể phớt lờ sự ngăn cản và đánh cắp tài sản của người dùng sau khi kiểm soát coldValidatorSet. Vì coldValidatorSet có quyền emergencyUnlock, có thể làm cho các lockers bị khóa không còn hiệu lực và ngay lập tức cập nhật danh sách nút. Hiện tại chỉ có 4 nút xác thực, rủi ro bị đánh cắp khóa riêng không hề thấp;
finalizers từ chối xác nhận giao dịch rút tiền của người dùng, mở rộng cuộc tấn công xem xét. Lúc này, tài sản của người dùng an toàn nhưng có thể không thể rút ra;
Các khoá bị khóa độc hại trên cầu nối chuỗi chéo, ngăn chặn tất cả các giao dịch rút tiền được thực hiện, chỉ có thể chờ coldValidatorSet mở khóa.
HyperEVM và kiến trúc tương tác chuỗi đôi
Để đạt được khả năng lập trình cho giao dịch sổ lệnh, như việc giới thiệu các giao dịch bảo mật cần có sự hỗ trợ của hợp đồng thông minh, Hyperliquid đã giới thiệu giải pháp HyperEVM. Nó có hai ưu điểm lớn so với EVM truyền thống: có thể đọc trạng thái sổ lệnh của Hyperliquid, và hợp đồng thông minh bên trong có thể tương tác với hệ thống sổ lệnh, mở rộng đáng kể các trường hợp ứng dụng.
Ví dụ, nếu người dùng cần đảm bảo tính riêng tư của lệnh đặt, họ có thể thêm lớp riêng tư thông qua hợp đồng tương tự như Tornado Cash trên HyperEVM, sau đó kích hoạt lệnh đặt trong hệ thống sổ lệnh Hyperliquid thông qua giao diện cụ thể.
Hyperliquid đã thiết kế một kiến trúc đặc biệt cho HyperEVM. Với việc hệ thống sổ lệnh tùy chỉnh có hiệu suất vượt trội hơn so với môi trường EVM, nhằm tránh giảm tốc độ, Hyperliquid sử dụng "giải pháp hai chuỗi": mỗi nút cùng lúc chạy hai chuỗi, lưu trữ dữ liệu của hai chuỗi cục bộ và xử lý giao dịch riêng biệt.
Hyperliquid thiết lập chuỗi chuyên dụng cho hệ thống sổ lệnh (HyperL1, có giấy phép ), đồng thời thiết lập chuỗi tương thích EVM (HyperEVM, không có giấy phép ). Dữ liệu của hai chuỗi được truyền qua cùng một giao thức đồng thuận, tồn tại như một trạng thái thống nhất, nhưng hoạt động trong môi trường khác nhau. Tốc độ tạo khối của HyperL1 nhanh hơn HyperEVM, nhưng các khối vẫn được thực hiện theo thứ tự. Hợp đồng trên chuỗi EVM có thể đọc dữ liệu khối L1 trong quá khứ và ghi dữ liệu vào các khối L1 trong tương lai.
HyperL1 và HyperEVM tương tác chủ yếu thông qua Precompiles và Events.
Precompiles
Tiền biên dịch ( Precompiles ) thực hiện các thao tác phức tạp trực tiếp ở tầng dưới, sử dụng các ngôn ngữ như C/C++ để xử lý các phép toán không thân thiện với Solidity. Tiền biên dịch về cơ bản là hợp đồng thông minh đặc biệt, các hợp đồng khác có thể gọi và nhận kết quả thực thi. Hiện tại, EVM gốc đã sử dụng tiền biên dịch để thực hiện chỉ thị ecRecover ( địa chỉ ).
HyperEVM cũng đã thêm mã biên dịch trước, cho phép đọc trạng thái của hệ thống sổ lệnh Hyperliquid. Địa chỉ biên dịch trước đã biết là 0x0000000000000000000000000000000000000800, có thể đọc vị thế hợp đồng vĩnh cửu của người dùng trong khối L1 gần đây.
Sự kiện
HyperEVM ghi dữ liệu vào HyperL1 phụ thuộc vào Events. Events là khái niệm gốc của EVM, cho phép hợp đồng gửi thông tin nhật ký ra bên ngoài. Ví dụ, khi chuyển ERC-20, sẽ phát sinh sự kiện Transfer để tiện theo dõi. Nhiều tình huống đa chuỗi cũng sử dụng Events để truyền tham số.
Nút HyperLiquid lắng nghe các sự kiện được phát ra từ địa chỉ 0x3333333333333333333333333333333333333333, dựa trên thông tin để biết được ý định của người dùng và chuyển đổi thành hành động giao dịch, ghi vào khối L1 trong tương lai. Nếu địa chỉ đó cung cấp chức năng, khi được gọi sẽ phát ra sự kiện IocOrder, khi khối L1 được tạo, nút sẽ tìm thấy sự kiện IocOrder mới và chuyển đổi thành thao tác đặt lệnh trong L1.
HyperBFT
Về mặt giao thức đồng thuận, Hyperliquid sử dụng giao thức HyperBFT dựa trên HotStuff. Ban đầu sử dụng thuật toán Tendermint, nhưng hiệu suất kém, mỗi giai đoạn cần trao đổi thông điệp All-to-All, độ phức tạp O(n²).
Để đạt được tốc độ của sàn giao dịch tập trung, đội ngũ đã phát triển HyperBFT và triển khai bằng Rust, lý thuyết có thể xử lý 2 triệu đơn hàng mỗi giây. Tất cả thông điệp trong HyperBFT được tổng hợp và phát đi bởi Leader, loại bỏ việc trao đổi thông điệp giữa các nút, giảm đáng kể độ phức tạp.
Nói một cách đơn giản, HyperBFT là giao thức đồng thuận mà trong đó leader hiện tại tạo khối, tất cả các nút bỏ phiếu và gửi kết quả thống nhất cho Leader, sau đó luân phiên leader tiếp theo.
Lưu ý cho nhà phát triển
Cơ chế đọc dữ liệu dựa trên Precompiles khá hoàn thiện, nhưng cần chú ý đến vấn đề msg.sender. Khi người dùng tương tác với hợp đồng hệ thống L1 và gián tiếp kích hoạt giao dịch EVM, msg.sender trong EVM là địa chỉ hợp đồng hệ thống L1 chứ không phải địa chỉ của người dùng.
Vấn đề không nguyên tử trong tương tác giữa EVM và L1. Ví dụ, nếu người dùng đặt lệnh trên L1 thông qua EVM nhưng tài sản không đủ, giao dịch sẽ thất bại nhưng không có thông báo lỗi khi gọi hàm. Các nhà phát triển cần xử lý tình huống thất bại trong việc đặt lệnh ở phía hợp đồng EVM và thiết lập hàm thu hồi vốn.
Địa chỉ hợp đồng EVM trên L1 cần có tài khoản ánh xạ. Sau khi triển khai hợp đồng EVM, cần chuyển một lượng nhỏ USDC đến địa chỉ ánh xạ L1 để tạo tài khoản.
Lưu ý các tình huống đặc biệt như số dư token. L1 có địa chỉ đặc biệt để tài sản xuyên chuỗi, nhưng sau khi xuyên chuỗi, EVM có thể không kịp thời tạo khối, người dùng tạm thời không thể đọc số dư. Các nhà phát triển nên xử lý các tình huống như vậy để tránh gây hoảng loạn cho người dùng.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
22 thích
Phần thưởng
22
6
Chia sẻ
Bình luận
0/400
LazyDevMiner
· 07-12 07:14
Nguy hiểm nhiều như vậy mà còn 20 tỷ Vị thế bị khóa, thật là vô lý.
Xem bản gốcTrả lời0
PumpDoctrine
· 07-11 11:56
啥时候能 mua đáy nó啊
Xem bản gốcTrả lời0
Web3ExplorerLin
· 07-09 10:39
nói một cách kỹ thuật, một L3 moonshot khác đang được hình thành...smh
Xem bản gốcTrả lời0
RugResistant
· 07-09 10:38
Chờ đợi ăn dưa
Xem bản gốcTrả lời0
WalletInspector
· 07-09 10:32
Tin đồn, tiền mở hộp quà bí ẩn thật không phải chuyện đùa.
Xem bản gốcTrả lời0
WalletDoomsDay
· 07-09 10:20
Bạn có thể giải thích rõ ràng các mối nguy hiểm an ninh không? Cả ngày nói về việc tăng lên và giảm không có ý nghĩa.
Phân tích sâu về Hyperliquid: Thảo luận về an toàn cầu nối Cross-chain và kiến trúc hai chuỗi HyperEVM
Nghiên cứu sâu về cấu trúc công nghệ và rủi ro an ninh của Hyperliquid
Gần đây, Hyperliquid đã thu hút được nhiều sự chú ý như một trong những sàn giao dịch order book trên chuỗi có ảnh hưởng nhất, với tổng giá trị khóa đã vượt 2 tỷ USD, được ngành công nghiệp đánh giá là "phiên bản trên chuỗi của một sàn giao dịch tập trung nổi tiếng", đồng thời cũng khơi lại cuộc thảo luận về Layer3 và chuỗi ứng dụng. Nhờ vào hiệu suất ấn tượng với giá trị dự án đạt 30 tỷ USD chỉ trong một tháng ra mắt, Hyperliquid đã nhận được sự quan tâm rộng rãi. Hiện tại, trên thị trường đã có không ít báo cáo phân tích về Hyperliquid, nhưng phần lớn tập trung vào chức năng sản phẩm và cơ chế giao dịch, thiếu đi sự phân tích sâu sắc về kiến trúc kỹ thuật và các mối nguy cơ tiềm ẩn về an ninh.
Bài viết này nhằm lấp đầy khoảng trống này, phân tích Hyperliquid từ góc độ kỹ thuật và an ninh, giúp người đọc hiểu rõ hơn về cấu trúc và nguyên lý bên trong của dự án ngôi sao này. Chúng tôi sẽ tập trung phân tích thiết kế và rủi ro của hợp đồng cầu nối chuỗi chéo Hyperliquid, cũng như kiến trúc đôi HyperEVM và HyperL1, khám phá sâu hơn cách thức thực hiện công nghệ phía sau.
Phân tích cầu liên chuỗi Hyperliquid
Do vì Hyperliquid không mở mã nguồn cho các thành phần cốt lõi, nhưng đã mở mã nguồn cho các hợp đồng cầu liên quan, nên chúng tôi có hiểu biết nhiều hơn về rủi ro liên quan đến hợp đồng cầu. Hyperliquid đã triển khai một hợp đồng cầu trên một mạng Layer2, để lưu trữ tài sản USDC mà người dùng gửi vào, chúng tôi có thể quan sát một phần hành vi của các nút Hyperliquid qua thành phần Bridge.
Tập hợp người xác thực
Về mặt phân chia danh tính nút, Hyperliquid có 4 nhóm xác thực viên, bao gồm hotValidatorSet, coldValidatorSet, finalizers và lockers, mỗi nhóm đảm nhận những trách nhiệm khác nhau. hotValidatorSet chịu trách nhiệm phản hồi các thao tác tần suất cao của người dùng như rút tiền, thường sử dụng ví nóng để kịp thời xử lý yêu cầu của người dùng.
coldValidatorSet chủ yếu được sử dụng để thay đổi cấu hình hệ thống, chẳng hạn như cập nhật danh sách các bộ xác thực khác, hoặc xử lý trạng thái khóa của hợp đồng cầu, và có quyền trực tiếp làm cho một số yêu cầu rút tiền không hợp lệ.
lockers là một nhóm các xác thực có quyền đặc biệt, tương tự như "ủy ban an ninh" phổ biến trong Layer2, có thể bỏ phiếu quyết định có tạm dừng hoạt động của cầu nối liên chuỗi trong trường hợp khẩn cấp. Hiện tại, tập hợp lockers của cầu Hyperliquid bao gồm 5 địa chỉ, chỉ cần 2 locker bỏ phiếu là có thể tạm dừng hợp đồng cầu.
finalizers cũng là một nhóm các xác thực viên đặc biệt, chủ yếu được sử dụng để xác nhận sự thay đổi trạng thái của cầu nối chuỗi chéo, chẳng hạn như các thao tác gửi và rút tiền của người dùng. Cầu nối chuỗi chéo của Hyperliquid áp dụng cơ chế "gửi - xác nhận", sau khi người dùng khởi động giao dịch rút tiền, cần phải chờ một khoảng thời gian "thời gian tranh chấp", sau khi hết thời gian này, finalizers sẽ thực hiện giao dịch rút tiền.
Nếu gặp vấn đề, như một yêu cầu rút tiền vượt quá số dư thực tế của người dùng, nút Hyperliquid có thể bỏ phiếu để tạm dừng hợp đồng cầu thông qua các lockers trong thời gian tranh chấp, hoặc do coldValidatorSet trực tiếp làm cho yêu cầu rút tiền vấn đề trở nên vô hiệu.
Hiện tại Hyperliquid chỉ có 4 nút xác thực, vì vậy hotValidatorSet và coldValidatorSet tương ứng với 4 địa chỉ trên chuỗi. Khi khởi tạo, Hyperliquid tự động đăng ký các địa chỉ trong hotValidatorSet làm thành viên của lockers và finalizers, trong khi coldValidatorSet được điều khiển bởi chính thức, sử dụng ví lạnh để lưu trữ khóa.
gửi tiền
Hợp đồng cầu của Hyperliquid được xử lý theo phương pháp Permit của EIP-2612 cho các khoản tiền gửi của người dùng, và chỉ hỗ trợ một loại tài sản duy nhất là USDC. So với mô hình Approve-Transfer truyền thống, Permit đơn giản hơn và thuận tiện cho các thao tác hàng loạt.
Hợp đồng cầu sử dụng hàm batchedDepositWithPermit để xử lý nhiều khoản gửi một cách hàng loạt, quy trình đơn giản và không có rủi ro an toàn tài chính, chủ yếu là tận dụng phương pháp Permit để tối ưu hóa trải nghiệm người dùng.
Rút tiền
So với tiền gửi, rút tiền là một hoạt động có rủi ro cao hơn, do đó logic cũng phức tạp hơn. Sau khi người dùng khởi xướng yêu cầu rút tiền, nút Hyperliquid sẽ gọi hàm batchedRequestWithdrawals của hợp đồng cầu. Lúc này yêu cầu mỗi yêu cầu rút tiền phải nhận được 2/3 trọng số chữ ký từ hotValidatorSet, lưu ý là "trọng số chữ ký 2/3" chứ không phải "số lượng chữ ký 2/3". Hiện tại, Hyperliquid chỉ có 4 nút có trọng số giống nhau, vì vậy việc kiểm tra trọng số chữ ký và số lượng chữ ký tạm thời nhất quán, nhưng trong tương lai có thể sẽ có thêm các nút có trọng số cao.
Sau khi gửi yêu cầu rút tiền, cầu nối liên chuỗi sẽ không ngay lập tức chuyển USDC, mà sẽ có "thời gian tranh chấp" 200 giây. Trong thời gian này có thể xảy ra hai tình huống:
lockers cho rằng yêu cầu rút tiền có vấn đề nghiêm trọng, có thể trực tiếp bỏ phiếu đóng băng hợp đồng;
Các nút cho rằng một số khoản rút tiền có vấn đề, các thành viên trong coldValidatorSet có thể gọi hàm invalidateWithdrawals để làm cho khoản rút tiền này không hợp lệ.
Nếu trong thời gian tranh chấp không có bất thường, sau khi kết thúc, các thành viên finalizers có thể gọi hàm batchedFinalizeWithdrawals để xác nhận trạng thái cuối cùng, lúc này USDC mới được chuyển vào địa chỉ ví của người dùng trên Layer2.
Từ góc độ mô hình an ninh, nếu kẻ tấn công độc hại muốn làm hại trong quy trình rút tiền của Hyperliquid, họ cần vượt qua ba lớp bảo vệ:
Nắm giữ quyền ký 2/3 của hotValidatorSet, tức là có đủ khóa riêng hoặc thông đồng. Hiện tại chỉ có 4 người xác thực, khả năng bị kiểm soát hoặc thông đồng không thấp;
Tránh giao dịch ác ý bị phát hiện trong thời gian tranh chấp, nếu không có thể kích hoạt hợp đồng khóa.
Lấy ít nhất một khóa riêng của thành viên finalizers, xác nhận rút tiền. Hiện tại, các thành viên finalizers về cơ bản tương đồng với các thành viên hotValidatorSet, thỏa mãn điều kiện 1 thì cũng thỏa mãn điều kiện 3.
Khóa hợp đồng cầu
Hyperliquid đã thiết lập chức năng khóa hợp đồng cầu liên chuỗi. Cụ thể, cần có thành viên lockers gọi hàm voteEmergencyLock để bỏ phiếu, hiện tại 2 thành viên lockers bỏ phiếu là đủ để khóa và tạm dừng hợp đồng cầu.
Điều đáng chú ý là cầu Hyperliquid còn cung cấp hàm unvoteEmergencyLock, cho phép những người khóa rút lại phiếu bầu. Một khi hợp đồng cầu đã bị khóa, chỉ có thể mở khóa thông qua hàm emergencyUnlock, cần thu thập hơn 2/3 trọng số chữ ký từ các thành viên coldValidatorSet.
emergencyUnlock sẽ cập nhật tập hợp địa chỉ xác thực hotValidatorSet và coldValidatorSet đồng thời khi mở khóa, và có hiệu lực ngay lập tức.
Cập nhật tập người xác thực
So với việc vượt qua quy trình rút tiền, việc sử dụng trực tiếp hàm updateValidatorSet để cập nhật tập hợp các xác thực viên là một phương thức tấn công hiệu quả hơn. Điều này yêu cầu tất cả các thành viên hotValidatorSet ký tên, và có thời gian tranh chấp là 200 giây.
Sau khi kết thúc thời gian tranh chấp, các thành viên của finalizers cần gọi hàm finalizeValidatorSetUpdate để hoàn thành cập nhật cuối cùng.
Tóm tắt các rủi ro tồn tại trong hợp đồng cầu Hyperliquid:
Hacker có thể phớt lờ sự ngăn cản và đánh cắp tài sản của người dùng sau khi kiểm soát coldValidatorSet. Vì coldValidatorSet có quyền emergencyUnlock, có thể làm cho các lockers bị khóa không còn hiệu lực và ngay lập tức cập nhật danh sách nút. Hiện tại chỉ có 4 nút xác thực, rủi ro bị đánh cắp khóa riêng không hề thấp;
finalizers từ chối xác nhận giao dịch rút tiền của người dùng, mở rộng cuộc tấn công xem xét. Lúc này, tài sản của người dùng an toàn nhưng có thể không thể rút ra;
Các khoá bị khóa độc hại trên cầu nối chuỗi chéo, ngăn chặn tất cả các giao dịch rút tiền được thực hiện, chỉ có thể chờ coldValidatorSet mở khóa.
HyperEVM và kiến trúc tương tác chuỗi đôi
Để đạt được khả năng lập trình cho giao dịch sổ lệnh, như việc giới thiệu các giao dịch bảo mật cần có sự hỗ trợ của hợp đồng thông minh, Hyperliquid đã giới thiệu giải pháp HyperEVM. Nó có hai ưu điểm lớn so với EVM truyền thống: có thể đọc trạng thái sổ lệnh của Hyperliquid, và hợp đồng thông minh bên trong có thể tương tác với hệ thống sổ lệnh, mở rộng đáng kể các trường hợp ứng dụng.
Ví dụ, nếu người dùng cần đảm bảo tính riêng tư của lệnh đặt, họ có thể thêm lớp riêng tư thông qua hợp đồng tương tự như Tornado Cash trên HyperEVM, sau đó kích hoạt lệnh đặt trong hệ thống sổ lệnh Hyperliquid thông qua giao diện cụ thể.
Hyperliquid đã thiết kế một kiến trúc đặc biệt cho HyperEVM. Với việc hệ thống sổ lệnh tùy chỉnh có hiệu suất vượt trội hơn so với môi trường EVM, nhằm tránh giảm tốc độ, Hyperliquid sử dụng "giải pháp hai chuỗi": mỗi nút cùng lúc chạy hai chuỗi, lưu trữ dữ liệu của hai chuỗi cục bộ và xử lý giao dịch riêng biệt.
Hyperliquid thiết lập chuỗi chuyên dụng cho hệ thống sổ lệnh (HyperL1, có giấy phép ), đồng thời thiết lập chuỗi tương thích EVM (HyperEVM, không có giấy phép ). Dữ liệu của hai chuỗi được truyền qua cùng một giao thức đồng thuận, tồn tại như một trạng thái thống nhất, nhưng hoạt động trong môi trường khác nhau. Tốc độ tạo khối của HyperL1 nhanh hơn HyperEVM, nhưng các khối vẫn được thực hiện theo thứ tự. Hợp đồng trên chuỗi EVM có thể đọc dữ liệu khối L1 trong quá khứ và ghi dữ liệu vào các khối L1 trong tương lai.
HyperL1 và HyperEVM tương tác chủ yếu thông qua Precompiles và Events.
Precompiles
Tiền biên dịch ( Precompiles ) thực hiện các thao tác phức tạp trực tiếp ở tầng dưới, sử dụng các ngôn ngữ như C/C++ để xử lý các phép toán không thân thiện với Solidity. Tiền biên dịch về cơ bản là hợp đồng thông minh đặc biệt, các hợp đồng khác có thể gọi và nhận kết quả thực thi. Hiện tại, EVM gốc đã sử dụng tiền biên dịch để thực hiện chỉ thị ecRecover ( địa chỉ ).
HyperEVM cũng đã thêm mã biên dịch trước, cho phép đọc trạng thái của hệ thống sổ lệnh Hyperliquid. Địa chỉ biên dịch trước đã biết là 0x0000000000000000000000000000000000000800, có thể đọc vị thế hợp đồng vĩnh cửu của người dùng trong khối L1 gần đây.
Sự kiện
HyperEVM ghi dữ liệu vào HyperL1 phụ thuộc vào Events. Events là khái niệm gốc của EVM, cho phép hợp đồng gửi thông tin nhật ký ra bên ngoài. Ví dụ, khi chuyển ERC-20, sẽ phát sinh sự kiện Transfer để tiện theo dõi. Nhiều tình huống đa chuỗi cũng sử dụng Events để truyền tham số.
Nút HyperLiquid lắng nghe các sự kiện được phát ra từ địa chỉ 0x3333333333333333333333333333333333333333, dựa trên thông tin để biết được ý định của người dùng và chuyển đổi thành hành động giao dịch, ghi vào khối L1 trong tương lai. Nếu địa chỉ đó cung cấp chức năng, khi được gọi sẽ phát ra sự kiện IocOrder, khi khối L1 được tạo, nút sẽ tìm thấy sự kiện IocOrder mới và chuyển đổi thành thao tác đặt lệnh trong L1.
HyperBFT
Về mặt giao thức đồng thuận, Hyperliquid sử dụng giao thức HyperBFT dựa trên HotStuff. Ban đầu sử dụng thuật toán Tendermint, nhưng hiệu suất kém, mỗi giai đoạn cần trao đổi thông điệp All-to-All, độ phức tạp O(n²).
Để đạt được tốc độ của sàn giao dịch tập trung, đội ngũ đã phát triển HyperBFT và triển khai bằng Rust, lý thuyết có thể xử lý 2 triệu đơn hàng mỗi giây. Tất cả thông điệp trong HyperBFT được tổng hợp và phát đi bởi Leader, loại bỏ việc trao đổi thông điệp giữa các nút, giảm đáng kể độ phức tạp.
Nói một cách đơn giản, HyperBFT là giao thức đồng thuận mà trong đó leader hiện tại tạo khối, tất cả các nút bỏ phiếu và gửi kết quả thống nhất cho Leader, sau đó luân phiên leader tiếp theo.
Lưu ý cho nhà phát triển
Cơ chế đọc dữ liệu dựa trên Precompiles khá hoàn thiện, nhưng cần chú ý đến vấn đề msg.sender. Khi người dùng tương tác với hợp đồng hệ thống L1 và gián tiếp kích hoạt giao dịch EVM, msg.sender trong EVM là địa chỉ hợp đồng hệ thống L1 chứ không phải địa chỉ của người dùng.
Vấn đề không nguyên tử trong tương tác giữa EVM và L1. Ví dụ, nếu người dùng đặt lệnh trên L1 thông qua EVM nhưng tài sản không đủ, giao dịch sẽ thất bại nhưng không có thông báo lỗi khi gọi hàm. Các nhà phát triển cần xử lý tình huống thất bại trong việc đặt lệnh ở phía hợp đồng EVM và thiết lập hàm thu hồi vốn.
Địa chỉ hợp đồng EVM trên L1 cần có tài khoản ánh xạ. Sau khi triển khai hợp đồng EVM, cần chuyển một lượng nhỏ USDC đến địa chỉ ánh xạ L1 để tạo tài khoản.
Lưu ý các tình huống đặc biệt như số dư token. L1 có địa chỉ đặc biệt để tài sản xuyên chuỗi, nhưng sau khi xuyên chuỗi, EVM có thể không kịp thời tạo khối, người dùng tạm thời không thể đọc số dư. Các nhà phát triển nên xử lý các tình huống như vậy để tránh gây hoảng loạn cho người dùng.