Giải thích công nghệ siêu lỏng: HyperEVM và các vấn đề tiềm ẩn của nó

Tác giả: Shew, Xianyang GodRealmX

Hyperliquid là một trong những thứ có ảnh hưởng nhất trao đổi sổ đặt hàng trực tuyến. 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 bao gồm Lớp 3 và các chuỗi ứng dụng đã mờ nhạt trong mắt công chúng. trở lại ánh đèn sân khấu. 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, một số 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 đặt hàng 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 thuần túy từ góc độ cấu trúc kỹ thuật và an toàn, để giúp nhiều người hiểu hơn về ngôi sao này cấu trúc và nguyên tắc của dự án. Chúng tôi sẽ trình bày 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 chuỗi Hyperliquid cũng như cấu trúc chuỗi kép 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ó.

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

Phân tích cầu nối chuỗi chéo HyperLiquid

VìHyperLiquid không có các thành phần cốt lõi nguồn mở nhưng có các thành phần lõi mở Hợp đồng cầu nối có nguồn gốc liên quan,Vì vậy, chúng tôi hiểu rõ hơn về những rủi ro liên quan đến hợp đồng cầu đường. 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 minh

Từ góc độ phân chia danh tính nút Có vẻ như Hyperliquid có 4 nhóm trình xác nhận là hotValidatorSet, coldValidatorSet, và finalizers và lockers, tương ứng với chức năng khác nhau. Trong số đó, hotValidatorSet được sử dụng để đáp ứng các hành vi có 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 cứ lúc nào.

Và 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 hotValidatorSet hoặc Locker chờ danh sách các bộ xác thực 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 nhất định.

Và lockers là một nhóm người xác minh có các quyền đặc biệt, tương tự như "ủy ban bảo mật" được Layer2 sử dụng, sẽ được sử dụng trong một số trường hợp khẩn cấp, trong trường hợp xảy ra sự cố, một cuộc bỏ phiếu sẽ được sử dụng để quyết định có nên tạm dừng hoạt động của cầu nối chuỗi hay không. Hiện tạiTủ khóaSiêu lỏng của Bridgetủ khóa Bộ này chứa5 địa chỉ và chỉ cần 2 phiếu bầu đểtạm dừngkết nối hợp đồngHoạt động.

Đối với người hoàn thiện, 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ác cầu nối chuỗi chéo. Từ góc độ hợp đồng, xác nhận chính là người dùng tiền gửi và rút tiền. Cầu nối chuỗi chéo của Hyperliquid sử dụng"Xác nhận gửi"cơ chế ,Ví dụ: người dùngbắt đầuviệc rút tiền sẽ khôngđượcthực hiện ngay lập tức ,< /strong>Bạn cần đợi 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, các thành viên trong người quyết toánthực hiện giao dịch rút tiềnvà rút tiền< /strong>< strong>có thểđượcthực thi bình thường.

Ví dụ: khi có vấn đề với cầu nối chuỗi chéo, một tuyên bố rút tiền nhất định tuyên bố rằng tài sản cần rút lớn hơn số dư tài sản thực tế thuộc sở hữu của người dùng, các nút Hyperliquid có thể Trong thời gian tranh chấp, sử dụng tủ khóa để bỏ phiếu đình chỉ hoạt động của hợp đồng cầu nối chuỗi hoặc sử dụng coldValidatorSet để trực tiếp vô hiệu hóa hợp đồng 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 chuỗi Địa chỉ. Trong quá trình khởi tạo, Hyperliquid tự động đăng ký địa chỉ trong hotValidatorSet với tư cách là thành viên của lockers và finalizers, trong khi coldValidatorSet là Hyperliquid chính thức kiểm soát nó và sử dụng ví lạnh để lưu trữ chìa khóa.

Gửi tiền

Hợp đồng cầu nối của Hyperliquid dựa trên EIP- 2612 Phương thức Giấy phép được sử dụng để xử lý 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 ở đây tương đối đơn giản và không có bảo mật quỹ. Rủi ro, 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 gửi tiền, rút ​​tiền là một hoạt động cực kỳ nguy hiểm nên tính logic của việc rút tiền sẽ cao hơn so với việc rút tiền tiền gửi Nó phức tạp hơn rất nhiều. 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 bắc cầu. Tại thời điểm nàyhợp đồng bắc cầusẽyêu cầu mọi sự rút luiyêu cầuphải gặp nhauh otValidatorSet2/3Trọng lượng chữ ký,Lưu ý rằng nhiều tài liệu mô tả nó ở đây là "Bộ 2 / 3 chữ ký", nhưng trên thực tế hợp đồng bridge kiểm tra "trọng lượng 2/3 chữ ký". Hiện tại HyperLiquid chỉ có 4 node có trọng số như nhau nên việc kiểm tra trọng số 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 ra các node có trọng số cao hơn.

Khi yêu cầu rút tiền được bắt đầu, cầu nối chuỗi chéo sẽ không chuyển ngay được kiểm soát theo hợp đồng USDC được chuyển ra ngoài, nhưng có “ Thời gian tranh chấp ” , tương tự như bằng chứng gian lận The “ thời gian thử thách” trong thỏa thuận. Thời gian tranh chấp hiện tại của hợp đồng cầu Hyperliquid là 200 giây có thể xảy ra hai tình huống trong thời gian tranh chấp:

1.lockers tin rằng. rằng hiện tại Có vấn đề nghiêm trọng với yêu cầu rút tiền Tại thời điểm này, bạn có thể trực tiếp bỏ phiếu để đình chỉ/đóng băng hợp đồng;

2. có vấn đề với một số hành vi rút tiền. Tại thời điểm này, các thành viên< code>coldValidatorSet có thể gọi. Hàm invalidateWithdrawals làm mất hiệu lực việc rút tiền.

Nếu không có vấn đề gì phát sinh trong thời gian tranh chấp,sau khithời gian tranh chấp kết thúc,người quyết địnhCác thành viên trong có thể gọi < trong hợp đồng bắc cầu code>batchedFinalizeWithdrawalsChức năngđểhoàn tấtcuối cùngcủa >Trạng thái, USDC sẽ chỉ được chuyển đến địa chỉ ví của người dùng trong Arbitrum sau khi chức năng này được kích hoạt.

Vì vậy, từ góc độ mô hình bảo mật, Nếu có kẻ tấn côngđộc hạimuốn sử dụng quy trình rút tiền của Hyperliquid để thực hiện thủ đoạn , chỉ cần xuyên thủng ba tuyến phòng thủ:

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

2. Trong thời gian tranh chấp, kẻ tấn công nên tránh bị phát hiện các giao dịch độc hại của mình. bị phát hiện rất có khả năng khiến tủ khóa 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 khóa riêng của ít nhất một thành viên người hoàn thiện để 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, các thành viên finalizers về cơ bản giống như các thành viên hotValidatorSet, do đó, 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 nối

Chúng tôi đã đề cập điều này đã nhiều lần trước đây Now Hyperliquid đã thiết lập chức năng khóa các hợp đồng cầu nối chuỗi chéo. Cụ thể, việc khóa một cầu nối chuỗi chéo yêu cầungười khóacác thành viên gọi hợp đồng cầu nối chuỗi chéo strong>Chức năngvoteEmergencyLocktiến hànhbỏ phiếu< /strong>< strong>,Hiện đang giữ vai trò thứ 2 tủ khóaGọichức năngđược cung cấp > strong>Sau khi bỏ phiếu, hợp đồng cầu nối chuỗi chéosẽ bị khóavà bị đình chỉ.

Nhưng cần lưu ý rằng cầu nối chuỗi chéo của HyperLiquid cũng cung cấp chức năng unvoteEmergencyLock, cho phép khóa code>Thành viên rút phiếu bầu. Sau khi hợp đồng cầu nối chuỗi chéo được khóa thành công, nó chỉ có thể được mở khóa thông qua chức năng có tên emergencyUnlock, yêu cầu thu thập hơn 2/3 trọng số chữ ký của coldValidatorSet các thành viên.

emergencyUnlock cũng sẽ nhập hotValidatorSet và coldValidatorSet mới trong khi mở khóa A thu thập các địa chỉ xác thực và sẽ được cập nhật ngay lập tức.

Cập nhật bộ xác minh

So với việc cố gắng vượt qua các tuyến phòng thủ hiện có trong quá trình rút lui, 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 bộ trình xác thực hotValidatorSet và coldValidatorSet. Điều này yêu cầu người gọi cung cấp chữ ký của tất cả các thành viên hotValidatorSet và thao tác này có thời gian tranh chấp là 200 giây.

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

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 chuỗi chéo Hyperliquid. Bài viết này không giới thiệu logic cập nhật của lockers và finalizers. Các bản cập nhật của cả hai đều yêu cầu chữ ký hotValidatorSet và việc xóa một thành viên nhất định cần có . chữ ký >coldValidatorSet.

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

1. Sau khi tin tặc 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 hoạt động của chức năng emergencyUnlock nên nó có thể vô hiệu hóa hành động khóa của tủ khóa trên hợp đồng cầu nối và cập nhật nó trong danh sách nút. Hiện tại chỉ có 4 nút xác thực trong Hyperliquid và khả năng bị đánh cắp khóa riêng 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 một 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 xác định cầu nối chuỗi chéo một cách độc hạ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ể đợi coldValidatorSet được mở khóa;< /p>

HyperEVM và kiến ​​trúc tương tác chuỗi kép

Để lập trình các giao dịch trong sổ đặt hàng, 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 thực hiện hợp đồng thông minh, Hyperliquid đã triển khai một chương trình có tên HyperEVM< mạnh>Kế hoạch. 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ổ đặt hàng của HyperLiquid và thứ hai, hợp đồng thông minh trong HyperEVM có thể tương tác với hệ thống sổ đặt hàng 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 thao tác đặt lệnh chờ xử lý, thì một lớp quyền riêng tư có thể được triển khai 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 hàng đang chờ xử lý trong hệ thống sổ đặt hàng 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 môi trường EVM chậm hơn nhiều. Để tránh hệ thống sổ đặt hàng bị chậm lại, Hyperliquid sử dụng "giải pháp chuỗi kép", về cơ bản cho phép< /strong> Siêu thanh khoảnThiết bị nút chạy hai chuỗi khối ở cấp phần mềm cùng một lúc. Mỗi nút lưu trữ dữ liệu của hai chuỗi cục bộ và xử lý các giao dịch của cả hai chuỗi các chuỗi riêng biệt.

Hyperliquid đã đặc biệt thiết lập 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 một chuỗi tương thích với 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 các môi trường thực thi khác nhau. Chúng tôi gọi chuỗiSổ đặt hàngRiêng tưHyperliquid L1 (L1) ,Chuỗi này được cấp phép; và đối vớiHyperEVM Chuỗi này là HyperEVM(EVM). Chuỗi này không được phép và bất kỳ ai cũng có thể triển khai các hợp đồng có thể truy cập thông tin trong L1 thông qua mã được 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 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

Cái gọi làBiên dịch trước, nói một cách thẳng thắn, 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,để loại bỏ các vấn đề không thân thiện với Solidity và quá trình tính toán rắc rối hơn được chuyển ra ngoài hợp đồng thông minh thông thường. 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 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 nhằm đáp ứng 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 có chính xác trong EVM hay không và lệnh này nằm ở . code>0x01 trong địa chỉ.

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 hiện đang là phương pháp phổ biến. Ví dụ: Base đã thêm mã biên dịch sẵn P256 để hỗ trợ người dùng. Hoạt động xác thực danh tính WebAuth.

(Hình ảnh này đến từtrang web Mã cuộn)

Cùng với giải pháp chủ đạo hiện nay, HyperEVM cũng đã thêm một loạtmã được biên dịch trướcđể triển khai sự hỗ trợ của EVM cho sổ đặt hàng Hyperliquid< strong>Đọc trạng thái hệ thống. Địa chỉ mã được biên dịch trước Hyperliquid hiện được biết đến là 0x00000000000000000000000000000000000800 Địa chỉ được biên dịch trước này có thể đọc vị trí 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 mã thông báo của hợp đồng ERC-20, hợp đồng sẽ đưa ra Sự kiện Chuyển để Nhận trạng thái chuyển mã thông báo từ các ứng dụng giao diện người dùng như trình khám phá khối. Những thông tin Sự kiện này sẽ được đưa vào khối và có một số 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.

Hiện cónhiềuvàcác kịch bản liên quan đến chuỗi chéoMọi người sẽ >sử dụng Sự kiệnđểchuyển các tham số chuỗi chéo,ví dụ: Arbitrum được triển khai trên mạng chính Ethereum Trong hợp đồng cầu nối, người dùng có thể gọi các chức năng liên quan ném các sự kiện để kích hoạt giao dịch trên Arbitrum.

Thông tin đã biết cho biết các nút HyperLiquid sẽ lắng nghe

0x333333333333333333333333333333333 & nbsp; ( Địa chỉ sự kiện ) Mục đích của người dùng là biết ý định của người dùng theo thông tin có trong Sự kiện và ý định đó sẽ như thế nào. Chuyển thành các hành động giao dịch, ghi vào các 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ẽ ném ra một đối tượng có tên IocOrder Sự kiện. 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 một sự kiện trong Hyper L1. Lệnh đang chờ xử lý.

HyperBFT

Ở cấp độ giao thức đồng thuận, Hyperliquid sử dụng giao thức có tên HyperBFTlà một giao thức phái sinh của 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 kém hiệu quả hơn và mỗi thuật toán đều kém hiệu quả hơn. Giai đoạn Trao đổi tin nhắn từ tất cả đến tất cả là bắt buộc. 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 của giao tiếp là O(n²), trong đó n là nút. Số lượng.

Sử dụng Tendermint, Hyperliquid có thể xử lý tới 20.000 đơn hàng mỗi giây. Để đạt được tốc độ trao đổi tập trung, nhóm 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 minh họa phương thức gửi tin nhắn 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ổng hợp và phát sóng thống nhất. , loại bỏ sự cần thiết của Nó loại bỏ các 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à một giao thức đồng thuận trong đó người lãnh đạo hiện tại tạo ra một khối, tất cả cá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 người lãnh đạo, sau đó người lãnh đạo 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

Những điều nêu trên Cơ chế đọc dữ liệu dựa trên Precompiles tương đối hoàn hảo. Các nhà phát triển Solidity không cần viết code tương ứng khi đọc trạng thái Hyper L1 mà cần chú ý đến vấn đề msg.sender. Tương tự như hầu hết các lớp thứ hai của 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 msg.sender trong giao dịch <. /code>, bạn sẽ thấy rằng msg.sender tương ứng với địa chỉ của hợp đồng hệ thống HyperL1, chứ 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 EVMvàL1, các nhà phát triển cần chú ý đến một hàng loạt 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ó đơn hàng nào trong L1. Nếu không có đủ tài sản, giao dịch chắc chắn sẽ thất bại nhưng sẽ không có thông báo trả về lỗi khi người dùng gọi hàm của địa chỉ sự kiện. 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ùngbị xâm phạm. Đối với các nhà phát triển tại thời điểm này, họ 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ờ bị rút trong L1.

Thứ hai, địa chỉ hợp đồng tương ứng với EVM phải tồn tại trong tài khoản L1Map,< /strong>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 đến địa chỉ được ánh xạ trong L1, buộc L1 phải tạo tài khoản cho đị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ư của 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 HyperEVM có thể không tạo 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 số dư của mình trên EVM. xích.

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 chuỗi chéo và không thể truy vấn được trong chuỗi L1 hoặc chuỗi EVM. các nhà phát triển đã xây dựng giao thức nên xử lý các tình huống đặc biệt trên để tránh gây hoang mang cho người dùng.

Tóm lại, HyperEVM tương tự nhưdựa trênHyperliquid Đối với lớp thứ hai của L1HyperEVM dựa vàomã được biên dịch trướcđể đọc trạng thái L1 và cũng dựa vào Sự kiện đểtương tác với Hyper L1Tạo ra sự tương tács. L1 cũng có một số hợp đồng hệ thống để giúp người dùngkích hoạtgiao dịchtrongHyperEVM hoặc CóThực hiện chuỗi tài sản chéo. Nhưng không giống như kiến ​​trúc Layer1-Layer2 thông thường, Hyperliquid cung cấp khả năng tương tác cao hơn cho HyperEVM.

Tài liệu tham khảo

1. Siêu thanh khoản: Sổ lệnh siêu tối ưu hóa L1

2. hyperliquid-dex/contracts< /p>

3. Hướng dẫn chưa chính xác về tiền biên dịch siêu lỏng.

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