Sự bùng nổ đã qua, phân tích hợp đồng cầu nối Hyperliquid, HyperEVM và các vấn đề tiềm ẩn từ góc độ kỹ thuật

Nguồn bài viết: Tiên Nhưỡng GodRealmX

Tác giả: Shew, Tiên Nhưỡng GodRealmX

Gần đây, Hyperliquid đã thu hút nhiều sự chú ý từ thị trường, là một trong những sàn giao dịch sổ lệnh trên chuỗi có ảnh hưởng nhất, với TVL đã vượt quá 2 tỷ đô la Mỹ, được Messari đánh giá là "Binance trên chuỗi", thậm chí còn kéo lại câu chuyện Layer3 và chuỗi ứng dụng đã mờ nhạt trong mắt công chúng vào tâm điểm chú ý. Với thành tích FDV đạt 30 tỷ đô la chỉ trong một tháng kể từ khi Token ra mắt, Hyperliquid đã thu hút sự chú ý rộng rãi từ người dùng bình thường đến những người trong ngành, trong khi số lượng báo cáo nghiên cứu về Hyperliquid cũng đã tăng lên đáng kể, nhưng những bài viết này chủ yếu tập trung vào các đặc điểm của sản phẩm sổ lệnh và cơ chế giao dịch mà không đi sâu vào cấu trúc kỹ thuật và các rủi ro tiềm ẩn của nó.

Tác giả bài viết này mong muốn bổ sung vào sự thiếu hụt này, chỉ từ góc độ cấu trúc kỹ thuật và an toàn để khảo sát Hyperliquid, giúp nhiều người hiểu rõ hơn về cấu trúc và nguyên lý của dự án nổi bật này. Chúng tôi sẽ từ hai góc độ là cấu trúc và rủi ro của hợp đồng cầu nối đa chuỗi Hyperliquid, và cấu trúc hai chuỗi HyperEVM và HyperL1 để giúp mọi người hiểu rõ hơn về kiến trúc và phương pháp thực hiện phía sau.

(Hiện tại, Hyperliquid chiếm tới 67% tổng nguồn cung USDC trên Arbitrum)

Phân tích cầu nối đa chuỗi HyperLiquid

Vì HyperLiquid không mã nguồn mở các thành phần cốt lõi, nhưng đã mã nguồn mở các hợp đồng cầu nối liên quan, nên chúng tôi hiểu rõ hơn về rủi ro liên quan đến hợp đồng cầu nối. Hyperliquid đã triển khai một hợp đồng cầu nối trên Arbitrum để lưu trữ tài sản USDC mà người dùng gửi vào, chúng tôi có thể thấy một phần hành vi của nút Hyperliquid trong thành phần Bridge.

Tập hợp người xác thực

Từ góc độ phân chia danh tính nút, Hyperliquid có 4 nhóm người xác thực, bao gồm 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 để phản hồi các hoạt động rút tiền của người dùng và các hành vi tần suất cao khác, thường sử dụng ví nóng để phản hồi kịp thời yêu cầu rút tiền của người dùng Hyperliquid.

Trong khi đó, coldValidatorSet chủ yếu được sử dụng để sửa đổi cấu hình hệ thống, chẳng hạn như thay đổi danh sách người xác thực 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 trực tiếp vô hiệu hóa một số yêu cầu rút tiền.

Trong khi đó, lockers là một nhóm người xác thực có quyền đặc biệt, tương tự như "ủy ban an ninh" thông dụng trong Layer2, sẽ quyết định thông qua bỏ phiếu có cho phép cầu nối đa chuỗi tạm dừng hoạt động trong một số tình huống khẩn cấp. Hiện tại, trong tập hợp lockers của cầu nối Hyperliquid có 5 địa chỉ, chỉ cần 2 locker bỏ phiếu là có thể tạm dừng hoạt động của hợp đồng cầu nối.

Còn về finalizers thực tế cũng là một nhóm người xác thực đặc biệt, chủ yếu để xác nhận sự thay đổi trạng thái của cầu nối đa chuỗi, từ góc độ hợp đồng chủ yếu xác nhận là tiền gửi và rút tiền của người dùng. Cầu nối đa chuỗi Hyperliquid sử dụng cơ chế "gửi- xác nhận", chẳng hạn như khi người dùng khởi xướng rút tiền sẽ không được thực hiện ngay lập tức, mà cần chờ một khoảng thời gian (thời gian này được gọi là thời gian tranh chấp). Sau khi thời gian tranh chấp kết thúc, các thành viên trong finalizers thực hiện giao dịch rút tiền, rút tiền mới có thể được thực hiện bình thường.

Và một khi cầu nối đa chuỗi gặp vấn đề, chẳng hạn như một yêu cầu rút tiền yêu cầu rút tài sản lớn hơn số dư thực tế mà người dùng sở hữu, các nút Hyperliquid có thể sử dụng các lockers để bỏ phiếu tạm dừng hoạt động của hợp đồng cầu nối trong thời gian tranh chấp, hoặc coldValidatorSet có thể trực tiếp vô hiệu hóa yêu cầu rút tiền có vấn đề.

Hiện tại Hyperliquid chỉ có 4 nút người xác thực, vì vậy hotValidatorSet và coldValidatorSet chỉ tương ứng với 4 địa chỉ trên chuỗi. Hyperliquid trong quá trình khởi tạo, tự động đăng ký các địa chỉ trong hotValidatorSet là thành viên của lockers và finalizers, trong khi coldValidatorSet do chính Hyperliquid kiểm soát, 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à trong hợp đồng cầu nối chỉ cho phép người dùng gửi vào một loại tài sản là USDC. So với mô hình truyền thống là Approve—Transfer, Permit đơn giản hơn và cũng dễ dàng hỗ trợ các hoạt động hàng loạt.

Hợp đồng cầu nối của Hyperliquid sử dụng hàm batchedDepositWithPermit để xử lý nhiều lần gửi tiền một cách hàng loạt, ở đây hành động gửi tiền tương đối đơn giản, không có rủi ro an toàn tài chính, quy trình xử lý rất đơn giản, chỉ sử dụng phương pháp Permit để tối ưu hóa UX.

Rút tiền

So với việc gửi tiền, rút tiền là một thao tác có độ nguy hiểm cao, vì vậy 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 khởi xướng yêu cầu rút tiền, nút Hyperliquid sẽ gọi hàm batchedRequestWithdrawals trong hợp đồng cầu nối. Lúc này, hợp đồng cầu nối sẽ yêu cầu mỗi yêu cầu rút tiền phải đáp ứng 2/3 trọng số chữ ký của hotValidatorSet, lưu ý rằng nhiều tài liệu ở đây mô tả là "tập hợp 2/3 chữ ký", nhưng thực tế hợp đồng cầu nối kiểm tra là "trọng số 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à kiểm tra số lượng chữ ký tạm thời là tương đương, nhưng trong tương lai, HyperLiquid có thể đưa vào các nút có trọng số cao hơn.

Khi yêu cầu rút tiền được khởi xướng, cầu nối đa chuỗi sẽ không ngay lập tức chuyển USDC mà hợp đồng kiểm soát, mà sẽ có một "thời gian tranh chấp", giống như "thời gian thách thức" trong giao thức chứng minh gian lận. Hiện tại, thời gian tranh chấp của hợp đồng cầu nối Hyperliquid là 200 giây, trong thời gian tranh chấp có thể xảy ra hai tình huống:

1. Các lockers cho rằng yêu cầu rút tiền hiện tại có vấn đề nghiêm trọng, lúc này có thể trực tiếp bỏ phiếu để tạm dừng/đóng băng hợp đồng.

2. Các nút cho rằng một số hành vi rút tiền có vấn đề, lúc này thành viên coldValidatorSet có thể gọi hàm invalidateWithdrawals, khiến yêu cầu rút tiền đó trở nên vô hiệu.

Nếu không có vấn đề 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 trong finalizers có thể gọi hàm batchedFinalizeWithdrawals trong hợp đồng cầu nối để chốt lại trạng thái cuối cùng, chỉ sau khi hàm này được kích hoạt, USDC mới được chuyển vào địa chỉ ví của người dùng trên Arbitrum.

Vì vậy, từ góc độ mô hình an ninh, nếu có kẻ tấn công ác ý muốn thao túng quy trình rút tiền của Hyperliquid, họ cần vượt qua ba rào cản:

1. Nắm giữ 2/3 trọng số chữ ký trong hotValidatorSet, nói cách khác cần có một số lượng khóa riêng nhất định hoặc thông đồng; hiện tại HyperLiquid chỉ có 4 người xác thực, khả năng bị kẻ tấn công kiểm soát hoặc thông đồng là không nhỏ.

2. Trong thời gian tranh chấp, kẻ tấn công nên tránh để giao dịch ác ý của mình bị phát hiện, một khi bị phát hiện, rất có thể khiến các lockers ra tay khóa hợp đồng. Chúng tôi sẽ thảo luận riêng về phần này ở phần dưới.

3. Có được ít nhất một khóa riêng của thành viên finalizers, để hành vi rút tiền của mình được xác nhận cuối cùng. Hiện tại, thành viên finalizers và thành viên hotValidatorSet về cơ bản là giống nhau, vì vậy chỉ cần kẻ tấn công thỏa mãn điều kiện 1 ở trên, thì tự động thỏa mãn điều kiện 3.

Khóa hợp đồng cầu nối

Trước đó, chúng tôi đã nhiều lần đề cập đến việc Hyperliquid đã thiết lập chức năng khóa hợp đồng cầu nối đa chuỗi. Cụ thể, để khóa cầu nối đa chuỗi, các thành viên lockers cần gọi hàm voteEmergencyLock trong hợp đồng cầu nối đa chuỗi để bỏ phiếu, hiện tại khi 2 lockers gọi hàm này để đưa ra phiếu bầu, hợp đồng cầu nối đa chuỗi sẽ bị khóa và ngừng hoạt động.

Nhưng cần lưu ý, cầu nối đa chuỗi HyperLiquid cũng cung cấp hàm unvoteEmergencyLock, cho phép thành viên lockers rút lại phiếu bầu. Khi hợp đồng cầu nối đa chuỗi đã bị khóa thành công, chỉ có thể giải phóng khóa thông qua hàm có tên là emergencyUnlock, cần thu thập 2/3 trọng số chữ ký của thành viên coldValidatorSet.

Chức năng emergencyUnlock trong khi giải phóng khóa cũng sẽ nhập địa chỉ mới của hotValidatorSet và coldValidatorSet, và sẽ ngay lập tức cập nhật.

Cập nhật tập hợp người xác thực

So với việc cố gắng vượt qua các rào cản hiện có trong quy trình rút tiền, một phương thức tấn công tốt hơn là trực tiếp sử dụng hàm updateValidatorSet để cập nhật tập hợp người xác thực hotValidatorSet và coldValidatorSet. Điều này yêu cầu người gọi phải cung cấp chữ ký của tất cả thành viên hotValidatorSet, và thao tác này có thời gian tranh chấp 200 giây.

Khi thời gian tranh chấp kết thúc, cần có thành viên finalizers gọi hàm finalizeValidatorSetUpdate để hoàn thành việc cập nhật trạng thái cuối cùng.

Đến đây, chúng ta đã giới thiệu hầu hết các chi tiết về cầu nối đa chuỗi Hyperliquid. Bài viết này không đề cập đến logic cập nhật của các lockers và finalizers, cả hai đều cần chữ ký của hotValidatorSet để cập nhật, trong khi việc loại bỏ một thành viên cụ thể cần chữ ký của coldValidatorSet.

Tóm lại, hợp đồng cầu nối của Hyperliquid chứa các rủi ro sau:

1. Nếu hacker kiểm soát coldValidatorSet, họ có thể phớt lờ mọi rào cản để đánh cắp tài sản của người dùng. Vì coldValidatorSet có quyền truy cập vào hàm emergencyUnlock, có thể khiến các lockers vô hiệu hóa hành động khóa hợp đồng, và có thể ngay lập tức cập nhật danh sách các nút. Hiện tại Hyperliquid chỉ có 4 nút người xác thực, khả năng bị đánh cắp khóa riêng là không nhỏ.

2. finalizers từ chối xác nhận cuối cùng cho giao dịch rút tiền của người dùng, tiến hành tấn công kiểm tra; 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 có thể không thể rút từ hợp đồng cầu nối.

3. Các lockers cố tình khóa cầu nối đa chuỗi, lúc này tất cả các giao dịch rút tiền đều không thể thực hiện, chỉ có thể chờ coldValidatorSet mở khóa.

Kiến trúc tương tác giữa HyperEVM và hai chuỗi

Để làm cho giao dịch sổ lệnh trở nên có thể lập trình, chẳng hạn như đưa vào giao dịch bảo mật cần thực hiện bằng hợp đồng thông minh, Hyperliquid đã giới thiệu giải pháp có tên HyperEVM. So với EVM truyền thống, nó có hai lợi thế đặc biệt: một là HyperEVM có thể đọc trạng thái sổ lệnh của HyperLiquid, hai là hợp đồng thông minh trong HyperEVM có thể tương tác với hệ thống sổ lệnh Hyperliquid, điều này mở rộng đáng kể các trường hợp sử 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 tính riêng tư của thao tác đặt hàng, lúc này có thể trên HyperEVM thông qua hợp đồng thông minh tương tự như Tornado Cash để thêm một lớp bảo mật, sau đó thông qua giao diện đặc biệt kích hoạt thao tác đặt hàng trong hệ thống sổ lệnh của HyperLiquid.

Trước khi giới thiệu HyperEVM, chúng ta cần giới thiệu kiến trúc đặc biệt mà Hyperliquid chuẩn bị cho HyperEVM. Bởi vì Hyperliquid có một hệ thống sổ lệnh siêu hiệu suất tùy chỉnh, trong khi tốc độ xử lý giao dịch trong môi trường EVM chậm hơn nhiều. Để tránh việc tốc độ làm việc của hệ thống sổ lệnh bị chậm lại, Hyperliquid đã sử dụng "giải pháp hai chuỗi", thực chất là cho phép các thiết bị nút Hyperliquid chạy đồng thời hai chuỗi blockchain trên tầng phần mềm, mỗi nút đều lưu trữ dữ liệu của hai chuỗi tại chỗ, xử lý giao dịch của hai chuỗi riêng biệt.

Hyperliquid đã thiết lập một chuỗi dành riêng cho hệ thống sổ lệnh tùy chỉnh của mình, đồng thời tăng cường một chuỗi tương thích với EVM (HyperEVM). Dữ liệu của hai chuỗi này được phát tán giữa các nút bằng 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 chạy trong các môi trường thực thi khác nhau. Chúng ta gọi chuỗi sổ lệnh là Hyperliquid L1 (L1), chuỗi này là có giấy phép; trong khi chuỗi dành cho HyperEVM là HyperEVM (EVM), chuỗi này không có giấy phép, bất kỳ ai cũng có thể triển khai hợp đồng, những hợp đồng này có thể truy cập thông tin trong L1 thông qua mã biên dịch trước.

Cần lưu ý rằng tốc độ tạo khối của Hyperliquid L1 lớn hơn chuỗi HyperEVM, nhưng những khối này vẫn sẽ được thực hiện theo thứ tự. Các hợp đồng trên chuỗi EVM có thể đọc dữ liệu từ các khối L1 trước đó và ghi dữ liệu vào các khối L1 trong tương lai. Như hình dưới đây:

Để thực hiện tương tác giữa HyperL1 và HyperEVM, Hyperliquid đã sử dụng hai phương pháp kỹ thuật là Biên dịch trước và Sự kiện.

Biên dịch trước

Những gì được gọi là biên dịch trước (Precompiles), nói một cách đơn giản là việc chuyển một số hoạt động khó thực hiện trong hợp đồng thông minh, có độ phức tạp cao, trực tiếp xuống tầng thấp hơn để thực hiện, đưa quy trình tính toán không thân thiện với Solidity và khá phiền phức ra bên ngoài hợp đồng thông minh thông thường để xử lý, mã biên dịch trước này có thể được thực hiện bằng các ngôn ngữ như C, C++ gần gũi hơn với thiết bị.

Phương pháp biên dịch trước cho phép EVM hỗ trợ các chức năng cao cấp và phức tạp hơn, thuận tiện cho nhu cầu của các nhà phát triển hợp đồng thông minh. Về hình thức, biên dịch trước thực chất là một nhóm hợp đồng thông minh đặc biệt, các hợp đồng khác có thể gọi trực tiếp các hợp đồng đặc biệt này, truyền vào tham số và nhận kết quả trả về từ việc thực hiện biên dịch trước. Hiện tại, trong EVM đã thực hiện chỉ thị ecRecover thông qua phương pháp biên dịch trước, có thể kiểm tra xem chữ ký secp256k1 có chính xác hay không, chỉ thị này nằm tại địa chỉ 0x01.

Sử dụng biên dịch trước để tăng cường một số chức năng đặc biệt là phương pháp phổ biến hiện nay, chẳng hạn như Base đã thêm mã biên dịch trước P256 để thuận tiện cho người dùng thực hiện xác thực danh tính WebAuth.

(Hình này được lấy từ trang web Rollup Codes)

Tương tự như các giải pháp chính hiện tại, HyperEVM cũng đã thêm một loạt mã biên dịch trước để thực hiện việc EVM đọc trạng thái hệ thống sổ lệnh Hyperliquid. Hiện tại, một địa chỉ mã biên dịch trước của Hyperliquid được biết là 0x0000000000000000000000000000000000000800, địa chỉ biên dịch trước này có thể đọc thông tin về vị trí hợp đồng vĩnh viễn của người dùng trong khối L1 gần 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, hành vi ghi này phụ thuộc vào các sự kiện được thực hiện. Sự kiện là khái niệm nguyên thủy trong EVM, cho phép hợp đồng thông minh gửi thông tin nhật ký ra bên ngoài (như ứng dụng frontend hoặc trình giám sát) trong quá trình thực thi, thuận tiện cho việc bên ngoài theo dõi tình hình hoạt động của hợp đồng thông minh.

Chẳng hạn như 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ẽ phát ra sự kiện Transfer tương ứng, để các trình khám phá khối và các ứng dụng frontend khác biết được tình hình chuyển token. Những thông tin sự kiện này sẽ được bao gồm trong khối, và việc lắng nghe và truy xuất nhật ký sự kiện có nhiều giải pháp trưởng thành.

Hiện nay, nhiều tình huống liên quan đến cầu nối đa chuỗi đều sử dụng các sự kiện để truyền tải các tham số cầu nối đa chuỗi, chẳng hạn như hợp đồng cầu nối triển khai trên mạng chính Ethereum của Arbitrum, người dùng có thể gọi các hàm liên quan để phát ra sự kiện kích hoạt giao dịch trên Arbitrum.

Thông tin đã biết cho thấy, nút HyperLiquid sẽ lắng nghe

0x3333333333333333333333333333333333333333 (địa chỉ sự kiện) phát ra các sự kiện, dựa trên thông tin chứa trong các sự kiện để biết được ý định của người dùng, và từ đó chuyển đổi ý định thành hành động giao dịch, ghi vào khối Hyperliquid L1 trong tương lai.

Chẳng hạn, địa chỉ sự kiện được đề cập ở 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ẽ phát ra một sự kiện có tên là IocOrder. Khi khối Hyper L1 được tạo ra, nút HyperLiquid sẽ kiểm tra các sự kiện gần đây được phát ra bởi địa chỉ sự kiện trong HyperEVM, khi tìm thấy sự kiện IocOrder mới, nó sẽ chuyển đổi thành thao tác đặt hàng trong Hyper L1.

HyperBFT

Về mặt giao thức đồng thuận, Hyperliquid đã áp dụng một giao thức có tên HyperBFT, đây là một phương pháp phát sinh từ HotStuff. Hiện tại, HotStuff-2 đã là một trong những giao thức đồng thuận có độ phức tạp thấp nhất và mới nhất.

Theo tài liệu cho thấy, ban đầu HyperLiquid đã sử dụng thuật toán đồng thuận Tendermint, là thuật toán đồng thuận mặc định trong hệ thống Cosmos, nhưng thuật toán này có hiệu suất khá thấp, mỗi giai đoạn đều cần trao đổi tin nhắn All-to-All, mỗi nút phải gửi tin nhắn đến tất cả các nút khác, độ phức tạp truyền thông là O(n²), trong đó n là số lượng nút.

Nếu sử dụng Tendermint, Hyperliquid có thể xử lý tối đa 20,000 đơn hàng mỗi giây. Để đạt được tốc độ của 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 bằng Rust, lý thuyết có thể xử lý tối đa 2 triệu đơn hàng mỗi giây.

Hình dưới đây minh họa cách thức truyền tin của giao thức HyperBFT trong trường hợp không song song, có thể thấy, tất cả các thông điệp được Nhà lãnh đạo tổng hợp và phát sóng đồng nhất, loại bỏ bước trao đổi tin nhắn 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 đó nhà lãnh đạo hiện tại tạo khối, tất cả các nút tham gia bỏ phiếu và gửi kết quả bỏ phiếu về phía Nhà lãnh đạo, sau đó để cho nhà lãnh đạo tiếp theo xoay vòng. 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 do giới hạn về độ dài không đi sâu vào.

Các điểm cần lưu ý cho các nhà phát triển

Cơ chế đọc dữ liệu dựa trên Precompiles ở trên là khá hoàn hảo, các nhà phát triển Solidity không cần phải viết mã tương ứng khi đọc trạng thái Hyper L1, nhưng cần lưu ý vấn đề msg.sender. Giống như hầu hết các lớp hai của Ethereum, HyperLiquid cũng cho phép người dùng tương tác trực tiếp với các hợp đồng hệ thống trong Hyper L1, gián tiếp kích hoạt các hành động giao dịch trên chuỗi HyperEVM, lúc này nếu hợp đồng thông minh đọc trường msg.sender trong giao dịch đó, sẽ phát hiện msg.sender tương ứng với địa chỉ hợp đồng hệ thống HyperL1, chứ không phải địa chỉ của người dùng đã phát động giao dịch trên HyperL1 ban đầu.

Và đối với tương tác giữa EVM và L1, các nhà phát triển cần chú ý đến một loạt vấn đề. Vấn đề đầu tiên là tính phi nguyên tử của tương tác, nếu người dùng tạo đơn hàng gián tiếp trong L1 thông qua địa chỉ sự kiện đã đề cập trên HyperEVM, nhưng trong L1 không có tài sản đủ, thì giao dịch chắc chắn sẽ thất bại, nhưng khi người dùng gọi hàm của địa chỉ sự kiện, sẽ không có thông báo lỗi trả lại. Vấn đề phi nguyên tử của tương tác có thể dẫn đến thiệt hại cho tài sản của người dùng. Lúc này, đối với nhà phát triển, cần xử lý thủ công tình huống thất bại của đơn hàng tại phía hợp đồng thông minh EVM. Hơn nữa, hợp đồng thông minh trong EVM nên có hàm để thu hồi tài sản cuối cùng, tránh việc tài sản của người dùng không thể rút ra từ L1.

Thứ hai, địa chỉ hợp đồng tương ứng với EVM trong L1 phải tồn tại tài khoản ánh xạ, khi người dùng triển khai hợp đồng thông minh trong EVM, cần chuyển một lượng nhỏ USDC vào địa chỉ ánh xạ trong L1, buộc L1 phải tạo tài khoản cho địa chỉ hợp đồng. Phần thao tác này có thể liên quan đến sự đồng thuận nền tảng của HyperLiquid, có yêu cầu rõ ràng trong tài liệu của Hyperliquid.

Cuối cùng, các nhà phát triển cần chú ý đến một số tình huống đặc biệt, đặc biệt là tình trạng số dư của token. Hyper L1 tồn tại một địa chỉ đặc biệt dành cho việc 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 đó, tài sản sẽ được chuyển từ L1 sang chuỗi HyperEVM. Do các nút HyperLiquid thực tế thực hiện đồng thời chuỗi EVM và chuỗi L1, có thể sau khi người dùng chuyển tài sản, HyperEVM vẫn chưa tạo khối được trong một thời gian dài, lúc này người dùng không thể đọc số dư của mình trên chuỗi EVM.

Nói một cách đơn giản, tài sản của người dùng lúc này bị kẹt trong cầu nối đa chuỗi, không thể tra cứu trong cả L1 lẫn chuỗi EVM, giao thức mà nhà phát triển xây dựng nên cần xử lý các tình huống đặc biệt trên, tránh để người dùng phát sinh tâm lý hoảng loạn.

Tóm lại, HyperEVM tương tự như lớp thứ hai dựa trên Hyperliquid L1, HyperEVM phụ thuộc vào mã biên dịch trước để đọc trạng thái L1, cũng phụ thuộc vào các 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 giao dịch trong HyperEVM, hoặc thực hiện việc chuyển tài sản qua lại giữa các chuỗi. Nhưng không giống như kiến trúc Layer1 - Layer2 thông thường, Hyperliquid cung cấp cho HyperEVM tính tương tác cao hơn.

Tài liệu tham khảo

Hyperliquid: Sổ lệnh tối ưu hóa cao

hyperliquid-dex/contracts

Hướng dẫn không chính thức về các Biên dịch trước của Hyperliquid.

Sự khác biệt giữa PBFT, Tendermint, HotStuff và HotStuff-2 là gì?