Tác giả: Shew, GodRealmX
Hyperliquid, đã thu hút sự chú ý rộng rãi của thị trường gần đây, là một trong sàn giao dịch đặt hàng trực Chuỗi có ảnh hưởng nhất. TVL của nó đã vượt quá 2 tỷ đô la Mỹ. Mặc dù được Messari đánh giá là "Binance trên Chuỗi", nó thậm chí còn mờ nhạt. của công chúng. Quan điểm của Lớp 3 và câu chuyện Chuỗi ứng dụng đã trở lại được chú ý. Với thành tích rực rỡ là nâng FDV lên 30 tỷ USD trong vòng một tháng kể từ khi ra mắt Token, Hyperliquid đã thu hút được sự chú ý rộng rãi từ người dùng thông thường đến những người thực hành. Đồng thời, lượng lớn các báo cáo nghiên cứu về Hyperliquid đã xuất hiện trên thị trường, nhưng đó là những báo cáo này. Các bài viết về cơ bản chỉ tập trung vào các tính năng của nó trong chức năng sổ lệnh sản phẩm và cơ chế giao dịch, chưa đi sâu vào cấu trúc kỹ thuật và các rủi ro bảo mật đằng sau nó.
Tác giả bài viết này nhằm mục đích lấp đầy khoảng trống này và xem xét Hyperliquid hoàn toàn từ góc độ cấu trúc kỹ thuật và an toàn, nhằm giúp nhiều người hiểu hơn về cấu trúc và nguyên tắc của dự án ngôi sao này. Chúng tôi sẽ giải thích chi tiết về cấu trúc và những mối nguy hiểm tiềm ẩn của hợp đồng cầu nối xuyên chuỗi Hyperliquid cũng như cấu trúc Chuỗi kép của HyperEVM và HyperL1 để giúp mọi người hiểu kiến trúc kỹ thuật và cách triển khai đằng sau nó.
( Siêu thanh khoản hiện chiếm 67% tổng lượng cung ứng USDC trên Arbitrum )
Cầu nối xuyên chuỗi HyperLiquid
Vì HyperLiquid không có các thành phần cốt mã nguồn mở nhưng mã nguồn mở nên chúng tôi hiểu rõ hơn về rủi ro liên quan đến các hợp đồng cầu nối. Hyperliquid đã triển khai hợp đồng cầu nối trên Arbitrum để lưu trữ tài sản USDC do người dùng gửi. Chúng ta có thể thấy một phần hoạt động của nút Hyperliquid trong thành phần Cầu.
bộ xác thực
Từ góc độ phân chia danh tính nút, Hyperliquid có bốn nhóm trình xác nhận, cụ thể là hotValidatorSet , coldValidatorSet , finalizers và lockers , tương ứng với các chức năng khác nhau. Trong đó, hotValidatorSet được sử dụng để đáp ứng các hành vi tần suất cao như hoạt động rút tiền của người dùng. Ví nóng thường được sử dụng để đáp ứng yêu cầu rút tiền của người dùng Hyperliquid bất kỳ lúc nào.
coldValidatorSet chủ yếu được sử dụng để sửa đổi cấu hình hệ thống, chẳng hạn như viết lại danh sách các bộ xác thực như hotValidatorSet hoặc lockers hoặc xử lý trạng thái khóa của hợp đồng cầu nối và coldValidatorSet có quyền vô hiệu hóa trực tiếp một số yêu cầu rút tiền nhất định.
lockers là một nhóm người xác thực có các quyền đặc biệt, tương tự như "ủy ban bảo mật" được Layer2 sử dụng. Họ sẽ bỏ phiếu để quyết định xem có nên đình chỉ hoạt động của cầu nối xuyên chuỗi trong một số trường hợp khẩn cấp hay không. Hiện tại, bộ lockers của cầu Hyperliquid có 5 địa chỉ và chỉ cần 2 tủ để bỏ phiếu đình chỉ hoạt động của hợp đồng cầu .
Đối với finalizers , họ thực sự là một nhóm người xác minh đặ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 xuyên chuỗi. Từ góc độ hợp đồng, xác nhận chính là tiền gửi và rút tiền của người dùng. Cầu nối xuyên chuỗi của Hyperliquid sử dụng cơ chế " gửi xác nhận " . Ví dụ: sau khi người dùng bắt đầu rút tiền, nó sẽ không được thực thi ngay lập tức và cần phải chờ trong một khoảng thời gian (khoảng thời gian này được gọi là thời gian tranh chấp). Sau khi chờ thời gian tranh chấp kết thúc và các thành viên finalizers thực hiện giao dịch rút tiền , việc rút tiền có thể được thực hiện bình thường .
Ví dụ: khi xảy ra sự cố cầu nối xuyên chuỗi, một tuyên bố rút tiền nhất định nói rằng tài sản cần rút lớn hơn số dư tài sản thực sự thuộc sở hữu của người dùng, nút Hyperliquid có thể sử dụng lockers để bỏ phiếu đình chỉ hoạt động của hợp đồng cầu nối xuyên chuỗi trong thời gian tranh chấp hoặc sử dụng trực tiếp coldValidatorSet Vô hiệu hóa các yêu cầu rút tiền có vấn đề.
Hiện tại, Hyperliquid chỉ có 4 nút validator nên hotValidatorSet và coldValidatorSet chỉ tương ứng với 4 địa chỉ trên Chuỗi. Trong quá trình khởi tạo, Hyperliquid tự động đăng ký các địa chỉ trong hotValidatorSet với tư cách là thành viên của lockers và finalizers , trong khi coldValidatorSet được chính Hyperliquid kiểm soát chính thức và sử dụng ví lạnh để lưu trữ khóa.
tiền gửi
Hợp đồng cầu nối của Hyperliquid dựa trên phương pháp Permit của EIP-2612 để xử lý các hoạt động gửi tiền của người dùng và hợp đồng cầu nối chỉ cho phép người dùng gửi USDC làm tài sản. So với chế độ Phê duyệt-Chuyển giao truyền thống, Giấy phép đơn giản hơn và dễ dàng hơn để hỗ trợ các hoạt động hàng loạt.
Hợp đồng cầu nối của Hyperliquid sử dụng chức năng batchedDepositWithPermit để xử lý hàng loạt nhiều khoản tiền gửi. Hành động gửi tiền ở đây tương đối đơn giản, không có rủi ro bảo mật quỹ và quy trình xử lý rất đơn giản. Nó chỉ sử dụng phương pháp Permit để tối ưu hóa UX.
Rút tiền
So với gửi tiền, rút tiền là một hoạt động có rủi ro cao nên logic rút tiền sẽ phức tạp hơn nhiều so với gửi tiền. Khi người dùng bắt đầu yêu cầu rút tiền, nút Hyperliquid sẽ gọi hàm batchedRequestWithdrawals của hợp đồng cầu nối. Lúc này, hợp đồng bridge sẽ yêu cầu mỗi yêu cầu rút tiền phải thu thập 2/3 tỷ trọng của hotValidatorSet . Lưu ý rằng nhiều tài liệu mô tả ở đây là "thu thập 2/3 chữ ký", nhưng thực tế hợp đồng bridge sẽ kiểm tra ". Tỷ trọng 2/3 chữ ký ”. Hiện tại HyperLiquid chỉ có 4 nút có tỷ trọng như nhau nên việc kiểm tra tỷ trọng chữ ký và kiểm tra số lượng chữ ký tạm thời giống nhau, tuy nhiên trong tương lai HyperLiquid có thể sẽ đưa vào nút có tỷ trọng cao hơn.
Khi yêu cầu rút tiền được bắt đầu, cầu nối xuyên chuỗi sẽ không chuyển ngay USDC do hợp đồng kiểm soát nhưng sẽ có một " thời gian tranh chấp " , tương tự như "thời gian thử thách" trong giao thức chống gian lận. Thời gian tranh chấp hiện tại của hợp đồng cầu Hyperliquid là 200 giây. Trong thời gian tranh chấp, hai tình huống có thể xảy ra:
1.lockers cho rằng yêu cầu rút tiền hiện tại có vấn đề nghiêm trọng. Tại thời điểm này, họ có thể trực tiếp bỏ phiếu đình chỉ/ đóng băng hợp đồng;
2. Nút cho rằng có vấn đề với một số lần rút tiền. Tại thời điểm này, thành viên coldValidatorSet có thể gọi hàm invalidateWithdrawals để vô hiệu hóa việc rút tiền.
Nếu không có vấn đề gì xảy ra trong thời gian tranh chấp, sau khi thời gian tranh chấp kết thúc, các thành viên của người finalizers có thể gọi hàm batchedFinalizeWithdrawals trong hợp đồng bắc cầu để quyết định trạng thái cuối cùng . Chỉ sau khi chức năng này được kích hoạt, USDC mới được chuyển đến địa chỉ ví của người dùng. Arbitrum.
Vì vậy, từ góc độ mô hình bảo mật, nếu kẻ tấn công độc hại muốn thao túng quá trình rút tiền của Hyperliquid , chúng cần vượt qua ba tuyến phòng thủ:
1. Nắm vững 2/3 tỷ trọng chữ ký trong hotValidatorSet . Nói cách khác, bạn cần phải có được một số private key hoặc thông đồng nhất định; hiện tại HyperLiquid chỉ có 4 trình xác thực và khả năng bị kẻ tấn công kiểm soát hoặc thông đồng là không. thấp;
2. Trong thời gian tranh chấp, những kẻ tấn công nên ngăn chặn các giao dịch độc hại của mình bị phát hiện. Sau khi bị phát hiện, rất có thể lockers sẽ khóa hợp đồng. Chúng tôi sẽ thảo luận cụ thể về phần này bên dưới.
3. Lấy private key của ít nhất một thành viên finalizers để cuối cùng hành vi rút tiền của bạn có thể được xác nhận. Hiện tại, finalizers và hotValidatorSet về cơ bản là giống nhau, vì vậy miễn là kẻ tấn công đáp ứng điều kiện 1 ở trên thì điều kiện 3 sẽ tự động được đáp ứng.
Khóa hợp đồng cầu
Chúng tôi đã đề cập lần trước đó rằng Hyperliquid đã thiết lập chức năng khóa các hợp đồng cầu nối xuyên chuỗi. Cụ thể, việc khóa cầu nối xuyên chuỗi yêu cầu các thành viên lockers phải gọi hàm voteEmergencyLock trong hợp đồng cầu nối xuyên chuỗi để bỏ phiếu . Hiện tại, khi hai lockers gọi chức năng này để bỏ phiếu, hợp cầu nối xuyên chuỗi sẽ bị khóa và tạm dừng .
Tuy nhiên, cần lưu ý rằng cầu nối xuyên chuỗi của HyperLiquid cũng cung cấp chức năng unvoteEmergencyLock , cho phép các thành viên rút phiếu lockers của họ. Sau khi hợp đồng cầu nối xuyên chuỗi được khóa thành công, nó chỉ có thể được mở khóa thông qua một chức năng có tên là emergencyUnlock , yêu cầu thu thập hơn 2/3 tỷ trọng chữ ký của các thành viên coldValidatorSet .
Khi chức năng emergencyUnlock mở khóa, nó cũng sẽ nhập các bộ địa chỉ trình xác thực hotValidatorSet và coldValidatorSet mới và nó sẽ được cập nhật ngay lập tức.
Cập nhật bộ xác thực
Thay vì cố gắng vượt qua các tuyến phòng thủ hiện có trong quá trình rút tiền, một phương pháp tấn công tốt hơn là sử dụng trực tiếp hàm updateValidatorSet để cập nhật các bộ trình xác thực hotValidatorSet và coldValidatorSet . Điều này yêu cầu người gọi phải ký tất cả các thành viên hotValidatorSet và hoạt động có thời gian tranh chấp là 200 giây.
Khi thời gian tranh chấp kết thúc, các thành viên finalizers cần gọi hàm finalizeValidatorSetUpdate để hoàn tất cập nhật trạng thái cuối cùng.
Cho đến nay, chúng tôi đã giới thiệu hầu hết các chi tiết về cầu nối xuyên chuỗi Hyperliquid. Bài viết này không giới thiệu logic cập nhật của lockers và finalizers . Việc cập nhật cả hai đều yêu cầu chữ ký hotValidatorSet và việc xóa một thành viên nào đó yêu cầu chữ ký coldValidatorSet .
Tóm lại, hợp đồng cầu nối của Hyperliquid chứa đựng rủi ro sau:
1. Sau khi hacker kiểm soát coldValidatorSet chúng có thể bỏ qua mọi cản trở và đánh cắp tài sản của người dùng. Vì coldValidatorSet có quyền vận hành chức năng emergencyUnlock nên nó có thể vô hiệu hóa hành động khóa của lockers trên hợp đồng cầu nối và cập nhật danh sách nút trong thời gian thực. Hiện tại, chỉ có 4 nút xác thực trong Hyperliquid và khả năng bị đánh private key là không thấp;
2.finalizers từ chối hoàn tất giao dịch rút tiền của người dùng và tiến hành các cuộc tấn công kiểm duyệt; trong trường hợp này, tài sản của người dùng sẽ không bị đánh cắp, nhưng người dùng có thể không rút được tiền từ hợp đồng bắc cầu;
3.lockers nhắm mục tiêu độc hại cầu nối xuyên chuỗi. Tại thời điểm này, tất cả các giao dịch rút tiền không thể được thực hiện và chỉ có thể chờ coldValidatorSet được mở khóa;
HyperEVM và kiến trúc tương tác Chuỗi
Để lập trình các giao dịch sổ lệnh, chẳng hạn như giới thiệu các giao dịch riêng tư và các tình huống khác yêu cầu hợp đồng thông minh, Hyperliquid đã đưa ra một giải pháp có tên HyperEVM . Nó có hai ưu điểm đặc biệt so với EVM truyền thống: Thứ nhất, HyperEVM có thể đọc trạng thái sổ lệnh của HyperLiquid và thứ hai, các hợp đồng thông minh trong HyperEVM có thể tương tác với hệ thống sổ lệnh Hyperliquid, giúp mở rộng đáng kể các kịch bản ứng dụng của Hyperliquid.
Để đưa ra một ví dụ đơn giản, nếu người dùng cần đảm bảo quyền riêng tư cho các hoạt động đặt lệnh đang chờ xử lý, họ có thể triển khai một lớp quyền riêng tư trên HyperEVM thông qua hợp đồng thông minh tương tự như Tornado Cash, sau đó kích hoạt hành động đặt lệnh đang chờ xử lý trong hệ thống sổ lệnh của HyperLiquid thông qua một giao diện cụ thể.
Trước khi giới thiệu HyperEVM, chúng tôi cần giới thiệu kiến trúc đặc biệt được Hyperliquid chuẩn bị cho HyperEVM. Vì Hyperliquid có hệ thống sổ đặt hàng hiệu suất cực cao được tùy chỉnh nên tốc độ xử lý giao dịch trong hoàn cảnh EVM chậm hơn nhiều. Để ngăn hệ thống sổ lệnh bị chậm lại, Hyperliquid sử dụng " giải pháp Chuỗi ", về cơ bản cho phép thiết bị nút Hyperliquid nút hai blockchain cùng lúc ở cấp độ phần mềm và mỗi nút lưu trữ dữ liệu của hai Chuỗi cục bộ. Các giao dịch trên hai Chuỗi được xử lý riêng biệt.
Hyperliquid đã thiết lập đặc biệt một Chuỗi cho hệ thống sổ đặt hàng tùy chỉnh của mình và cũng đã thêm Chuỗi tương thích EVM (HyperEVM). Dữ liệu của hai Chuỗi này được trải rộng giữa các nhóm nút thông qua cùng một giao thức đồng thuận và tồn tại dưới dạng trạng thái thống nhất nhưng chạy riêng biệt trong hoàn cảnh thực thi khác nhau. Chúng tôi gọi sổ đặt hàng dành riêng cho chuỗi Hyperliquid L1 (L1), Chuỗi này được cấp phép; chuỗi được sử dụng cho HyperEVM Chuỗi HyperEVM (EVM) , Chuỗi này không được phép, bất kỳ ai cũng có thể triển khai hợp đồng và các hợp đồng này có thể được truy cập thông qua mã thông tin được biên dịch trước trong L1.
Cần lưu ý rằng tốc độ tạo khối của Hyperliquid L1 lớn hơn tốc độ tạo khối của Chuỗi HyperEVM nhưng các khối này vẫn sẽ được thực thi theo thứ tự. Các hợp đồng trên Chuỗi EVM có thể đọc dữ liệu trong các khối L1 trước đây và ghi dữ liệu vào các khối L1 trong tương lai. Như được hiển thị bên dưới:
Để đạt được sự tương tác giữa HyperL1 và HyperEVM, Hyperliquid sử dụng hai phương tiện kỹ thuật: Biên dịch trước và Sự kiện.
Biên dịch trước
Nói một cách thẳng thắn, cái gọi là biên dịch trước (Precompiles) là chuyển một số thao tác khó thực hiện và có độ phức tạp cao trong hợp đồng thông minh trực tiếp sang lớp bên dưới và chuyển các quy trình tính toán không thân thiện với Solidity và hơn thế nữa. gây rắc rối cho các hợp đồng thông minh thông thường. Để xử lý bên ngoài, loại mã được biên dịch trước này có thể được triển khai bằng C, C++ và các ngôn ngữ khác gần với thiết bị cơ bản hơn Solidity.
Phương pháp được biên dịch trước cho phép EVM hỗ trợ các chức năng phức tạp và nâng cao hơn để dễ dàng hỗ trợ nhu cầu của các nhà phát triển hợp đồng thông minh. Về hình thức, quá trình biên dịch trước về cơ bản là một tập hợp các hợp đồng thông minh đặc biệt. Các hợp đồng thông minh khác có thể gọi trực tiếp các hợp đồng đặc biệt này, truyền tham số và thu được kết quả trả về của quá trình thực thi được biên dịch trước. Hiện tại, lệnh ecRecover được triển khai trong EVM gốc thông qua quá trình biên dịch trước. Bạn có thể kiểm tra xem chữ ký secp256k1 bên trong EVM có chính xác hay không và lệnh này nằm ở địa chỉ 0x01 .
Hiện tại, phương pháp chủ đạo là sử dụng tính năng biên dịch trước để thêm một số chức năng đặc biệt. Ví dụ: Base đã thêm mã biên dịch trước P256 để hỗ trợ người dùng thực hiện các hoạt động xác thực danh tính WebAuth.
(Hình ảnh này đến từ trang web Rollup Code )
Cùng với giải pháp chủ đạo hiện nay, HyperEVM cũng đã bổ sung sê-ri mã được biên dịch trước để cho phép EVM đọc trạng thái của hệ thống sổ đặt hàng Hyperliquid . Địa chỉ mã được biên dịch trước Hyperliquid hiện được biết đến là 0x0000000000000000000000000000000000000800 . Địa chỉ được biên dịch trước này có thể đọc vị thế hợp đồng vĩnh viễn của người dùng trong khối L1 mới nhất.
Sự kiện
Chúng tôi đã đề cập ở trên rằng HyperEVM có thể ghi dữ liệu vào khối HyperL1 và hành vi ghi phụ thuộc vào Sự kiện. Sự kiện là một khái niệm gốc trong EVM, cho phép hợp đồng thông minh gửi thông tin nhật ký ra bên ngoài (chẳng hạn như ứng dụng ngoại vi hoặc trình nghe) trong quá trình thực thi, để thế giới bên ngoài có thể theo dõi trạng thái hoạt động của hợp đồng thông minh.
Ví dụ: khi người dùng sử dụng chức năng chuyển token của hợp đồng ERC-20, hợp đồng sẽ đưa ra một Sự kiện tương ứng với Transfer , để các ứng dụng front-end như Block Explorer có thể tìm hiểu tình huống chuyển token. Những thông tin Sự kiện này sẽ được đưa vào khối và có lượng lớn các giải pháp hoàn thiện để theo dõi và truy xuất nhật ký Sự kiện.
Ngày nay, nhiều tình huống liên quan đến chuỗi Chuỗi sử dụng Sự kiện để chuyển các tham số chuỗi Chuỗi. Ví dụ: Arbitrum được triển khai trong hợp đồng cầu nối trên mạng chính ETH. Người dùng có thể gọi các chức năng liên quan để ném các sự kiện nhằm kích hoạt giao dịch trên Arbitrum.
Thông tin đã biết chỉ ra rằng nút HyperLiquid sẽ lắng nghe
0x3333333333333333333333333333333333333333 ( địa chỉ sự kiện ) Sự kiện, biết ý định của người dùng dựa trên thông tin có trong Sự kiện và chuyển ý định đó thành hành động giao dịch theo điều này và ghi nó vào khối L1 Hyperliquid trong tương lai.
Ví dụ: địa chỉ sự kiện ở trên sẽ cung cấp một hàm Khi người dùng gọi hàm này, địa chỉ sự kiện sẽ đưa ra một Sự kiện có tên IocOrder . Khi khối Hyper L1 được tạo, nút HyperLiquid trước tiên sẽ truy vấn các Sự kiện được gửi bởi địa chỉ sự kiện gần đây trong HyperEVM. Khi một sự kiện IocOrder mới được truy xuất, nó sẽ được chuyển đổi thành thao tác đặt hàng đang chờ xử lý trong Hyper L1.
HyperBFT
Ở cấp độ giao thức đồng thuận, Hyper Liquid áp dụng giao thức có tên Hyper BFT , đây là một phương pháp phái sinh dựa trên HotStuff. Hiện tại, HutStuff-2 là một trong những giao thức đồng thuận mới nhất có độ phức tạp thấp nhất.
Theo dữ liệu, HyperLiquid ban đầu sử dụng thuật toán đồng thuận Tendermint, đây là thuật toán đồng thuận mặc định được sử dụng trong hệ thống Cosmos. Tuy nhiên, thuật toán này không hiệu quả khi cần phải trao đổi thông báo từ Tất cả đến Tất cả ở mỗi giai đoạn và mỗi nút phải báo cáo cho. Tất cả nút khác đều gửi tin nhắn và độ phức tạp trong giao tiếp là O(n²) , trong đón là số lượng nút.
Sử dụng Tendermint, Hyperliquid có thể xử lý tới 20.000 đơn hàng mỗi giây. Để đạt được tốc độ sàn giao dịch tập trung, đội ngũ HyperLiquid đã phát triển thuật toán HyperBFT dựa trên HotStuff và triển khai nó trong Rust, về mặt lý thuyết có thể xử lý tới 2 triệu đơn hàng mỗi giây.
Hình dưới đây thể hiện phương thức truyền thông điệp của sự đồng thuận HyperBFT trong tình huống không song song. Có thể thấy rằng tất cả các tin nhắn đều được Leader tóm tắt và phát sóng thống nhất, giúp loại bỏ bước trao đổi tin nhắn giữa nút và giảm thiểu độ phức tạp đáng kể.
Nói một cách đơn giản, HyperBFT là một giao thức đồng thuận trong đó nút dẫn đầu hiện tại tạo ra một khối, tất cả nút tham gia biểu quyết và kết quả biểu quyết được gửi thống nhất đến nút dẫn đầu, sau đó nút chỉ huy tiếp theo sẽ được luân chuyển. Trên thực tế, các chi tiết cụ thể liên quan đến Hotstuff và Tendermint phức tạp hơn nhiều. Bài viết này bị giới hạn bởi độ dài và trọng tâm và sẽ không đi sâu vào chi tiết ở đây.
Những điểm cần lưu ý dành cho nhà phát triển
Cơ chế đọc dữ liệu dựa trên Precompiles nói trên tương đối hoàn hảo. Các nhà phát triển Solidity không cần phải viết code tương ứng khi đọc trạng thái Hyper L1 nhưng họ cần chú ý đến vấn đề msg.sender . Tương tự như hầu hết các lớp thứ hai Ethereum, HyperLiquid cũng cho phép người dùng tương tác trực tiếp với hợp đồng hệ thống trong Hyper L1 và gián tiếp kích hoạt các hành động giao dịch trên Chuỗi HyperEVM. Tại thời điểm này, nếu hợp đồng thông minh đọc trường msg.sender trong giao dịch, nó sẽ hoạt động. will Người ta thấy rằng msg.sender tương ứng với địa chỉ của hợp đồng hệ thống HyperL1, không phải địa chỉ của người dùng ban đầu thực hiện giao dịch trên HyperL1.
Về sự tương tác giữa EVM và L1, các nhà phát triển cần chú ý đến sê-ri vấn đề. Vấn đề đầu tiên là tính không nguyên tử của tương tác . Nếu người dùng gián tiếp đặt hàng trong L1 thông qua địa chỉ sự kiện nói trên trên HyperEVM, nhưng không có đủ tài sản trong L1 thì giao dịch chắc chắn sẽ thất bại, nhưng người dùng vẫn gọi. địa chỉ sự kiện. Sẽ không có lời nhắc trả về lỗi khi sử dụng chức năng này. Các vấn đề về tính phi nguyên tử của các tương tác có thể khiến tài sản của người dùng bị xâm phạm . Tại thời điểm này, các nhà phát triển cần xử lý thủ công lỗi của các đơn đặt hàng đang chờ xử lý ở phía hợp đồng thông minh EVM. Hơn nữa, hợp đồng thông minh trong EVM phải có chức năng thu hồi vốn cuối cùng để ngăn tài sản của người dùng không bao giờ rút trong L1.
Thứ hai, địa chỉ hợp đồng tương ứng với EVM phải có tài khoản ánh xạ ở L1. Sau khi người dùng triển khai hợp đồng thông minh trong EVM, anh ta cần chuyển một lượng nhỏ USDC sang địa chỉ ánh xạ ở L1, buộc L1 phải tạo một tài khoản cho địa chỉ đó. địa chỉ hợp đồng. Phần hoạt động này có thể liên quan đến sự đồng thuận cơ bản của HyperLiquid, được yêu cầu rõ ràng trong tài liệu của HyperLiquid.
Cuối cùng, nhà phát triển cần chú ý đến một số tình huống đặc biệt, đặc biệt là số dư token . Hyper L1 có một địa chỉ đặc biệt để chuyển tài sản, nhưng khi người dùng gửi tài sản đến địa chỉ đặc biệt này, tài sản sẽ được chuyển từ L1 sang Chuỗi HyperEVM. Vì nút HyperLiquid thực sự thực thi Chuỗi EVM và Chuỗi L1 cùng lúc, nên có thể HyperEVM đã không tạo ra khối trong một thời gian dài sau khi người dùng chuyển tài sản . Tại thời điểm này, người dùng không thể đọc được khối của mình. số dư trên Chuỗi EVM.
Nói một cách đơn giản, tài sản của người dùng tại thời điểm này bị kẹt trong cầu nối xuyên chuỗi và không thể truy vấn trong chuỗi L1 hoặc Chuỗi EVM. Giao thức do nhà phát triển xây dựng sẽ xử lý các tình huống đặc biệt ở trên để tránh cho người dùng tâm lý.
Tóm lại, HyperEVM tương tự như lớp thứ hai dựa trên Hyperliquid L1 . HyperEVM dựa vào mã được biên dịch sẵn để đọc trạng thái L1 và cũng dựa vào Sự kiện để tương tác với Hyper L1 . L1 cũng có một số hợp đồng hệ thống để giúp người dùng kích hoạt các giao dịch trong HyperEVM hoặc thực hiện tài sản xuyên Chuỗi. Nhưng không giống như kiến trúc Layer1- Layer2 chung, Hyperliquid cung cấp khả năng tương tác cao hơn cho HyperEVM.
Tham khảo
Siêu thanh khoản: Sổ đặt hàng siêu tối ưu hóa L1
siêu thanh khoản-dex/hợp đồng
Hướng dẫn chưa chính xác về tiền biên dịch siêu lỏng.
Sự khác biệt giữa PBFT, Tendermint, HotStuff và HotStuff-2 là gì?
