Đạt được tốc độ 1 gigas/giây, hệ thống EVM nguồn mở mới nhất của Gravity có trí tưởng tượng gì?
Nguồn gốc: Gravity
Giới thiệu
Kể từ tháng 8 năm 2024 Gravity Alpha Main Kể từ khi ra mắt Ra mắt, mạng đã xử lý hơn 275 triệu giao dịch, với khối lượng giao dịch trung bình hàng ngày là 2,6 triệu và đạt thành công phí giao dịch 30 triệu G. Với việc phát hành Litepaper, chúng tôi đặt nhiều kỳ vọng vào kế hoạch chi tiết trong tương lai của chuỗi EVM hiệu suất cao này. Bài viết này sẽ cung cấp phân tích chuyên sâu về Litepaper và tiết lộ cách Gravity xây dựng kiến trúc chuỗi khối Lớp 1 hiệu suất cao tuyệt vời cho các ứng dụng trong thế giới thực.
Gravity là chuỗi khối lớp 1 tương thích với EVM, hiệu suất cao được xây dựng bởi Galxe. Gravity được phát triển dựa trên nhu cầu phát triển của Galxe. Là nền tảng phân phối trực tuyến lớn nhất thế giới, nền tảng Galxe kết nối một hệ sinh thái đa chuỗi khổng lồ và thu hút hơn 25 triệu người dùng. Trong quá trình phát triển không ngừng của mình, Galxe đã phát triển thành một siêu ứng dụng phi tập trung, tích hợp các công cụ đổi mới như Quest, Passport, Score, Compass và Alva, đồng thời cung cấp điểm khách hàng thân thiết, NFT sự kiện, phần thưởng mã thông báo, xác minh danh tính zk và các dịch vụ phong phú như tiết kiệm thông minh xuyên chuỗi. Khi nó tiếp tục phát triển, khối lượng giao dịch cao của Galxe là một yếu tố quan trọng trong việc thúc đẩy việc xây dựng Gravity—hệ thống điểm khách hàng thân thiết của nó hỗ trợ 51,2 giao dịch mỗi giây và chiến dịch phần thưởng mã thông báo của nó hỗ trợ 32,1 giao dịch mỗi giây. Điều này đã thôi thúc chúng tôi chuyển sang chuỗi khối EVM khi phân cấp phần phụ trợ Galxe trong khi vẫn duy trì trải nghiệm người dùng tốt nhất.
Với sự phát triển triển khai toàn diện trên chuỗi của Galxe, dự kiến sẽ có sự tăng trưởng hơn nữa về khối lượng giao dịch. Yêu cầu về thông lượng dự kiến sẽ đạt 50 triệu khí mỗi giây, đồng thời đáp ứng các nhu cầu sinh thái rộng hơn (chẳng hạn như thanh toán xuyên chuỗi, giao dịch điểm khách hàng thân thiết và thị trường NFT) có thể yêu cầu công suất xử lý 500 triệu khí mỗi giây. Để đạt được mục tiêu này, Gravity đặt mục tiêu hỗ trợ thông lượng 1 gigagas mỗi giây để đáp ứng nhu cầu mở rộng quy mô của các ứng dụng sử dụng nhiều tài nguyên.
Trong số các giải pháp hiện có, nhiều nền tảng đạt được khả năng mở rộng thông qua Ethereum, nhưng giai đoạn thử thách của L2 Rollup chắc chắn dẫn đến sự chậm trễ trong giao dịch, điều này rất quan trọng đối với Galxe và các nền tảng khác Các ứng dụng yêu cầu xác nhận giao dịch ngay lập tức không thân thiện với người dùng. Mặc dù một số DApp cố gắng bù đắp độ trễ thông qua các mô hình tin cậy hoặc giám sát bên ngoài, nhưng các phương pháp này gây ra sự phức tạp và rủi ro bổ sung và rõ ràng là không lý tưởng cho các kịch bản ứng dụng cốt lõi.
Trong bối cảnh này, Gravity ra đời. Gravity lấy EVM song song làm cốt lõi và thu hẹp khoảng cách hiệu suất giữa L2 và L1 bằng cách phát triển Grevm, hiện là hệ thống thực thi EVM song song nguồn mở nhanh nhất. Ngoài ra, Gravity mô-đun hóa kiến trúc Aptos và tích hợp các công cụ đồng thuận như Quorum Store và AptosBFT. các thành phần đã được chứng minh khác. Tận dụng kiến trúc hoàn thiện của AptosBFT, Gravity tránh được sự phức tạp và rủi ro tiềm ẩn khi phát triển từ đầu. Cuối cùng, Gravity không chỉ xây dựng chuỗi khối L1 hiệu suất cao mang lại trải nghiệm toàn chuỗi mà còn ra mắt SDK chuỗi khối đường ống đầu tiên, giúp đơn giản hóa đáng kể quá trình tương tác giữa nhà phát triển và người dùng.
Gravity mang đến khả năng mở rộng, phân quyền chưa từng có và tốc độ giao dịch gần như ngay lập tức. Công nghệ của nó kết hợp các ưu điểm của L1 và L2 để đạt được 10.000 giao dịch mỗi giây và độ chính xác dưới giây. Đồng thời, bằng cách tích hợp các giao thức đặt cược lại như EigenLayer và Babylon, Gravity không chỉ đảm bảo tính bảo mật mạnh mẽ trong giai đoạn ra mắt mà còn giảm rủi ro hệ thống khi phụ thuộc lâu dài vào một tài sản duy nhất.
Trong tương lai, Gravity sẽ phát triển theo lộ trình sau:
· Ra mắt Devnet Giai đoạn 1, Kiểm tra hiệu suất thời gian thực;
· Khởi động Testnet trường thọ để xác minh độ ổn định lâu dài của mạng;
· Chuyển đổi từ mạng chính Gravity Alpha sang hoạt động đầy đủ Mạng chính Gravity đặt nền tảng cho ứng dụng quy mô lớn của công nghệ phi tập trung.
Sau đây là toàn văn tổng hợp của Gravity Litepaper.
Tóm tắt
Trọng lực là vùng Lớp 1 tương thích với EVM, hiệu suất cao được tạo bởi Galxe Blockchain được thiết kế cho các ứng dụng quy mô lớn và hệ sinh thái đa chuỗi. Các tính năng của nó bao gồm thông lượng 1 gigagas mỗi giây, xác nhận cuối cùng của giao dịch dưới giây và cơ chế đồng thuận PoS dựa trên giao thức cam kết lại. Thiết kế của Gravity dựa trên hai thành phần nguồn mở cốt lõi: (1) Gravity SDK, là công cụ đồng thuận AptosBFT PoS được điều khiển dựa trên việc đặt lại; (2) Gravity reth, một lớp thực thi được điều khiển bởi EVM Grevm (Gravity EVM) song song. Những công cụ này cung cấp cho các ứng dụng Web3 khả năng xây dựng Lớp 1 thay thế và Lớp 2 hiệu quả, đặc biệt là trên chuỗi EVM. Bài viết này xem xét sâu về thiết kế kỹ thuật và đổi mới kỹ thuật của Gravity, cho thấy cách triển khai nó thông qua kiến trúc quy trình, thuật toán đồng thuận nâng cao, công nghệ thực thi song song và cơ chế lưu trữ được tối ưu hóa (thông qua reth và cải tiến Aptos công cụ đồng thuận) để đáp ứng nhu cầu hiệu suất cao.
Giới thiệu
Sự phát triển của Gravity phát triển vượt qua những thách thức trong hoạt động mà Galxe gặp phải. Galxe là ứng dụng Web3 hàng đầu cung cấp cho người dùng các dịch vụ như điểm khách hàng thân thiết, NFT sự kiện, phần thưởng mã thông báo, xác thực không cần kiến thức và tiết kiệm thông minh đa chuỗi. Galxe đang phát triển nhanh chóng, với hệ thống điểm khách hàng thân thiết xử lý trung bình 51,2 giao dịch mỗi giây và chiến dịch thưởng mã thông báo xử lý trung bình 32,1 giao dịch mỗi giây. Trong quá trình phân quyền dần dần Galxe, việc di chuyển các trường hợp sử dụng này sang chuỗi khối EVM đồng thời đảm bảo trải nghiệm người dùng mượt mà đã trở thành một bài toán khó. Do đó, việc phát triển chuỗi khối EVM hiệu suất cao có thể đáp ứng (1) thông lượng giao dịch cao và (2) xác nhận giao dịch gần như ngay lập tức đã trở nên quan trọng.
Trong bối cảnh này, việc chọn giải pháp Lớp 2 hiện có hoặc phát triển Lớp 1 mới là điểm quyết định quan trọng. Lớp-1 sử dụng thuật toán đồng thuận để đạt được tính hữu hạn, trong khi Lớp-2 sử dụng giao thức Rollup để giải quyết vấn đề này. Có sự cân bằng giữa hai lớp: Lớp 1 thường hy sinh một phần thông lượng do những hạn chế của thuật toán đồng thuận, nhưng nó có thể đạt được xác nhận giao dịch cuối cùng nhanh hơn. Ví dụ: thuật toán đồng thuận dựa trên AptosBFT có thể xác nhận các giao dịch trong vài giây, trong khi quá trình tổng hợp lạc quan có thể có thời gian thử thách lên tới bảy ngày. Mặc dù bằng chứng không có kiến thức có thể đẩy nhanh quá trình nhưng việc xác nhận cuối cùng vẫn có thể mất vài giờ. Xem xét nhu cầu xác nhận cuối cùng dưới giây của Gravity (đặc biệt là giao thức mục đích toàn chuỗi), chúng tôi đã chọn xây dựng Lớp 1.
Mặc dù Lớp-2 có lợi thế riêng trong việc giao tiếp với Ethereum, nhưng Lớp-1 như Gravity có thể được triển khai thông qua giao thức mục đích Gravity và khả năng tương tác xuyên chuỗi. với Ethereum và các blockchain khác. Thiết kế này không chỉ hoạt động liền mạch với Ethereum mà còn tăng cường khả năng kết nối của toàn bộ hệ sinh thái Web3.
Ngoài ra, giao thức đặt lại giúp giảm đáng kể khó khăn trong việc xây dựng chuỗi khối PoS Lớp 1. Tận dụng các giao thức như EigenLayer và Babylon, Gravity tích hợp tài sản đặt cược của Ethereum và Bitcoin với mạng lưới trình xác thực mở rộng của chúng. Điều này cung cấp bảo mật kinh tế cho sự đồng thuận PoS, làm cho tính phân cấp và bảo mật của Gravity có thể so sánh với Ethereum.
Tóm lại, Gravity được xây dựng dưới dạng chuỗi khối Lớp 1 tương thích với EVM, hiệu suất cao để đáp ứng khả năng mở rộng và yêu cầu của các yêu cầu về Hiệu suất Web3 hiện đại. Mặc dù ban đầu nó được phát triển để phục vụ Galxe, nhưng khung linh hoạt do Gravity SDK và Grevm (Gravity EVM) cung cấp phù hợp để xây dựng bất kỳ Lớp 1 nào và Lớp 2 hiệu quả, với các chức năng tương tự như Tendermint/Cosmos SDK.
Chúng ta cần thông lượng 1 gigagas/giây
Đối với blockchain, thông lượng là quan trọng nhất. Các chỉ số hiệu suất chính thường là được đo bằng số giao dịch mỗi giây (TPS) hoặc mức sử dụng gas mỗi giây (gas/s). Lấy hệ thống điểm khách hàng thân thiết của Galxe làm ví dụ, hệ thống này cần ít nhất 4 triệu gas/s để hoạt động ổn định. Con số này được tính toán dựa trên thực tế là mỗi giao dịch điểm khách hàng thân thiết tiêu thụ trung bình 80.000 gas và có thể xử lý khoảng 51,2 giao dịch mỗi giây.
Dự đoán này được hỗ trợ bởi dữ liệu thực tế từ Gravity Alpha Mainnet. Là mạng Lớp 2 trong các thử nghiệm của chúng tôi, các giao dịch điểm khách hàng thân thiết của Gravity Alpha Mainnet cho thấy thông lượng của nó có thể đạt mức ổn định 4 triệu gas/s, xác thực tính chính xác của ước tính trước đó.
Mặc dù trên chuỗi hoạt động Chi phí cao có thể dẫn đến nhu cầu giảm nhẹ, nhưng xu hướng mở rộng của Galxe cho thấy nhu cầu có thể tăng lên gấp hai đến ba lần mức hiện tại trong thời kỳ cao điểm. Ngoài ra, với việc bổ sung các kịch bản ứng dụng khác, chẳng hạn như NFT, phần thưởng mã thông báo và các nhiệm vụ toàn chuỗi trong tương lai được hỗ trợ bởi bằng chứng không có kiến thức, nếu Galxe hoạt động hoàn toàn trên chuỗi, nhu cầu thông lượng dự kiến sẽ đạt 50 triệu gas/ S. Giả sử rằng việc sử dụng gas của ứng dụng trên chuỗi Gravity tuân theo phân phối Pareto (tương tự như Uniswap luôn tiêu thụ 10% gas của Ethereum), để đáp ứng các nhu cầu sinh thái rộng hơn, chẳng hạn như thanh toán xuyên chuỗi, giao dịch điểm khách hàng thân thiết và thị trường NFT, lý tưởng nhất là nó sẽ hỗ trợ thông lượng 500 triệu khí/s. Do đó, để đáp ứng những nhu cầu tiềm năng này, blockchain phải có công suất xử lý 1 gigagas mỗi giây, đảm bảo rằng nó có thể mở rộng quy mô với các ứng dụng sử dụng nhiều tài nguyên.
Để đạt được thông lượng cao như vậy, điều quan trọng là phải triển khai EVM song song. Chúng tôi đã phát triển Grevm, hiện là hệ thống thực thi EVM song song nguồn mở nhanh nhất. Để biết hiệu suất cụ thể, vui lòng tham khảo các chương tiếp theo.
Thời gian xác nhận dưới giây
Ngoài thông lượng, tốc độ xác nhận giao dịch cũng rất nhanh quan trọng đối với trải nghiệm người dùng cũng rất quan trọng. Người dùng hiện đại đã quen với các phản hồi gần như tức thời giống như Web2 và đây vẫn là một thách thức đối với blockchain. Lấy Galxe làm ví dụ, nó tương tự như một trò chơi hoàn toàn trên chuỗi và có những yêu cầu nhất định về độ trễ thấp. Hiện tại, thời gian xác nhận giao dịch của hầu hết các chuỗi khối EVM dao động từ vài giây đến vài ngày, còn lâu mới đáp ứng được yêu cầu này. Chúng tôi chọn thuật toán đồng thuận AptosBFT để đạt được thời gian xác nhận dưới giây.
Mặc dù về mặt lý thuyết, Bản tổng hợp L2 có thể cải thiện thông lượng nhưng giai đoạn thử thách của chúng có thể gây ra sự chậm trễ trong giao dịch, điều này rất bất lợi cho các ứng dụng yêu cầu xác nhận giao dịch ngay lập tức (chẳng hạn như Galxe). Mặc dù một số DApp cố gắng tối ưu hóa điều này thông qua các mô hình tin cậy hoặc giám sát bên ngoài, nhưng điều này gây ra sự phức tạp và rủi ro bổ sung và không lý tưởng cho các ứng dụng quan trọng. Gravity SDK song song hóa quy trình đồng thuận và thực thi bằng cách thiết kế quy trình gồm 5 giai đoạn, rút ngắn khoảng cách hiệu suất giữa L2 và L1 (xem bên dưới để biết chi tiết về thiết kế cụ thể).
Bảo mật PoS dựa trên việc đặt lại
Gravity SDK cung cấp bảo mật Phương pháp mở rộng Ethereum là không giới hạn ở L2 Rollup mà chọn kiến trúc L1 được bảo vệ bằng cách đặt lại để cân bằng hiệu suất, khả năng tương tác và bảo mật. Mô-đun cốt lõi tích hợp các giao thức cam kết lại như EigenLayer và Babylon, cung cấp hỗ trợ niềm tin kinh tế và đảm bảo xây dựng sự đồng thuận bằng chứng cổ phần mạnh mẽ.
Với tài sản thế chấp trị giá 45 tỷ USD của Ethereum và 850.000 trình xác thực cũng như 600 tỷ USD tài sản được kết nối với Bitcoin thông qua Babylon, Gravity có thể bắt đầu lại từ đầu. tránh các vấn đề khởi động thường gặp và rủi ro bảo mật của các chuỗi khối mới, đồng thời giảm rủi ro hệ thống do một tài sản duy nhất mang lại trong dài hạn.
Kiến trúc chuỗi trọng lực
Gravity Chain bao gồm hai thành phần chính: Gravity SDK và Gravity reth. Gravity SDK là một khung blockchain được cải tiến từ chuỗi Aptos hiện là chuỗi khối PoS tiên tiến nhất dựa trên họ thuật toán đồng thuận HotStuff của nó cải thiện đáng kể thông lượng và hiệu quả tài nguyên. Gravity reth là lớp thực thi dựa trên reth chạy dưới dạng Block Stream Reactor (BSR) để nhận các khối được đề xuất từ lớp đồng thuận. Bằng cách tối ưu hóa reth, Gravity reth đạt được khả năng thực thi song song, tính toán gửi trạng thái không đồng bộ hàng loạt và cải thiện hiệu quả lưu trữ. Hai thành phần này được tích hợp chặt chẽ thông qua Giao diện công cụ đồng thuận trọng lực (GCEI) và bộ chuyển đổi reth, đồng thời tiến trình của từng giai đoạn được bộ điều khiển đường ống quản lý linh hoạt.
Thiết kế này tách biệt việc thực thi khối khỏi sự đồng thuận của khối, khiến lớp thực thi đóng vai trò là người tiêu dùng các đề xuất khối. Việc tối ưu hóa reth của chúng tôi khiến nó trở nên hoàn toàn phù hợp với quy trình đề xuất khối theo đường dẫn do Block Stream Reactor (BSR) quản lý.
Quy trình giao dịch của Gravity Chain như sau:
1 Giao dịch được gửi thông qua Gravity reth. Giao diện JSON RPC, hoàn toàn tương thích với Ethereum.
2. Sau đó, giao dịch sẽ đi vào nhóm bộ nhớ của Gravity SDK và lan truyền trong mạng. Trình xác thực sẽ xử lý giao dịch theo nhóm và tạo chứng chỉ Quorum Store (QS). .
3. Người đứng đầu mỗi vòng đề xuất một đề xuất khối, bao gồm siêu dữ liệu khối và các giao dịch được đặt hàng được chọn từ nhóm bộ nhớ và QS.
4. Sau khi đề xuất được đánh dấu là đã ra lệnh, nó sẽ vào lớp thực thi.
5. Grevm trong lớp thực thi xử lý các giao dịch song song, tạo ra kết quả thực thi và chuyển trạng thái mới cho mô-đun quản lý trạng thái.
6. Mô-đun trạng thái tính toán gốc trạng thái và chuyển nó đến công cụ đồng thuận để đạt được sự đồng thuận gốc trạng thái.
7. Sau khi trạng thái gốc cuối cùng được xác nhận, mô-đun lưu trữ vẫn duy trì trạng thái gốc và chặn dữ liệu.
Các chương sau mô tả chi tiết từng thành phần.
Gravity SDK: Thực tiễn đổi mới về chuỗi khối đường ống nguồn mở
Gravity SDK là một mô-đun mở khung blockchain nguồn được phát triển dựa trên chuỗi khối Aptos sẵn sàng sản xuất. Mục tiêu là mô-đun hóa kiến trúc của Aptos, dựa trên các thành phần đã được chứng minh như Quorum Store và công cụ đồng thuận AptosBFT, để tạo ra SDK chuỗi khối quy trình đầu tiên.
Những lý do Gravity SDK chọn Aptos làm nền tảng bao gồm:
· Kiến trúc kỹ thuật hàng đầu : Aptos Đây là một blockchain PoS tiên tiến dựa trên sự đồng thuận của gia đình HotStuff.
· Hiệu suất cực cao: Aptos cung cấp thông lượng 160.000 giao dịch mỗi giây, với thời gian xác nhận cuối cùng chưa đến 1 giây.
· Độ tin cậy thực tế: Aptos đã được kiểm chứng trong môi trường sản xuất và cho thấy tính ổn định cũng như hiệu quả tuyệt vời.
· Tránh phát minh lại bánh xe: Sử dụng kiến trúc hoàn thiện của Aptos có thể tránh được sự phức tạp và rủi ro tiềm ẩn khi phát triển từ đầu, trong khi những nỗ lực khác để vượt qua Aptos hầu hết chỉ mang tính lý thuyết và Thực hành không đầy đủ.
· Lợi ích tổng hợp: Khi Aptos tiếp tục phát triển, Gravity SDK có thể tích hợp liền mạch các tính năng mới của nó, chẳng hạn như API số ngẫu nhiên và cả thông qua kiến trúc mô-đun và Cơ chế bảo mật tiên tiến phản hồi lại Aptos.
Chuỗi khối dựa trên Gravity SDK được kết nối với công cụ đồng thuận quy trình thông qua Giao diện công cụ đồng thuận trọng lực (GCEI). Mặc dù GCEI tương thích với nhiều lớp thực thi nhưng Gravity SDK hiện chủ yếu hỗ trợ Gravity reth. Thông tin chi tiết về GCEI sẽ được thảo luận trong các chương tiếp theo.
Giao diện công cụ đồng thuận trọng lực (GCEI)
Giao thức GCEI (Giao diện thực thi đồng thuận trọng lực) là Cầu nối giao tiếp giữa lớp đồng thuận và lớp thực thi. Nó tiêu chuẩn hóa sự tương tác giữa hai lớp và đảm bảo rằng các quá trình đồng thuận và thực thi được đồng bộ hóa thông qua bộ điều khiển đường ống.
SDK blockchain truyền thống Chính sự khác biệt so với Gravity SDK là công cụ đồng thuận theo đường dẫn của nó. Lớp thực thi phải được triển khai dưới dạng Lò phản ứng dòng khối, nghĩa là nó cần có khả năng tiêu thụ liên tục luồng các khối được đề xuất và các cam kết trạng thái phải được tính toán không đồng bộ với việc thực hiện giao dịch. Ngoài ra, lớp thực thi cần có khả năng cung cấp tín hiệu áp suất ngược cho lớp đồng thuận để điều chỉnh linh hoạt nhịp điệu của các đề xuất khối.
Ngoài ra, do tính chất quy trình của Gravity SDK, lớp thực thi phải có khả năng xử lý các giao dịch không thể thực hiện được trong các khối được đề xuất vì nhóm bộ nhớ không thể truy cập vào trạng thái mới nhất trên thế giới. Không thể kiểm tra chặt chẽ tính hợp lệ của bất kỳ giao dịch nào: việc thực thi có thể chưa được hoàn thành. Đồng thời, kết quả thực thi sẽ không chặn việc tạo các khối tiếp theo, vì sau khi Gravity SDK song song hóa sự đồng thuận khối và đồng thuận trạng thái, lớp thực thi sẽ trở thành lò phản ứng cho luồng khối được đề xuất và có thể tự do trả về kết quả Thực thi tiếp theo.
Đặc tả giao thức GCEI xác định hai nhóm API:
· API lớp đồng thuận: những API do Gravity SDK triển khai, nó được lớp thực thi sử dụng để phản hồi các khối do công cụ đồng thuận đề xuất và gửi các cam kết trạng thái.
· API lớp thực thi: Các API này phải được lớp thực thi triển khai. Công cụ đồng thuận sẽ sử dụng các API này để thực hiện xác minh nỗ lực tốt nhất trước khi đề xuất giao dịch cho các khối, truyền phát các khối được đề xuất và thông báo cho lớp thực thi về các cam kết trạng thái cuối cùng.
Từ góc độ vòng đời giao dịch, giao thức GCEI xác định những điều sau:
1. check_txn (API lớp thực thi)
· Đầu vào: Nhận giao dịch (GTxn) làm đầu vào.
· Đầu ra: Trả về địa chỉ người gửi, số nonce và giới hạn gas của giao dịch.
Mục đích: Phương pháp này được công cụ đồng thuận sử dụng để chạy xác minh với nỗ lực cao nhất trước khi đề xuất giao dịch cho một khối. Phương thức này có thể được gọi nhiều lần trên cùng một giao dịch, chẳng hạn như khi giao dịch đi vào mempool, trước khi được đề xuất vào một khối và khi cam kết trạng thái được hoàn tất.
2. submit_txn (API lớp đồng thuận)
Đầu vào: Nhận giao dịch từ quá trình thực thi lớp (GTxn).
Đầu ra: Trả về Kết quả<()>, cho biết liệu giao dịch có được thêm thành công vào nhóm bộ nhớ hay không.
Mục đích: Lớp thực thi có thể sử dụng phương thức này để gửi các giao dịch tới vùng bộ nhớ. Sau đó, công cụ đồng thuận sẽ truyền bá giao dịch qua mạng và hình thành Cửa hàng đại biểu sau khi nhận được một loạt giao dịch.
3. recv_ordered_block (API lớp thực thi)
Đầu vào: Nhận order_block (loại BlockBatch ), chứa giao dịch được sắp xếp và siêu dữ liệu khối.
Đầu ra: Kết quả trả về<()>, cho biết lớp thực thi đã nhận và chấp nhận khối thành công hay chưa.
Mục đích: Sau khi công cụ đồng thuận đề xuất một khối, khối đó sẽ được gửi đến lớp thực thi để thực hiện giao dịch. Phương pháp này cho phép lớp thực thi nhận và xử lý các khối được đề xuất.
4. update_state_commitment (API lớp đồng thuận)
Đầu vào: trạng thái của một khối nhất định số Cam kết (StateCommitment).
Đầu ra: Trả về Kết quả<()>, cho biết liệu cam kết trạng thái có được công cụ đồng thuận cục bộ chấp nhận thành công hay không.
Mục đích: Sau khi lớp thực thi tính toán cam kết trạng thái, nó sẽ được gửi đến lớp đồng thuận để hoàn thiện, nghĩa là đạt được sự đồng thuận nhẹ 2f+1 với những người xác nhận khác. Nếu khoảng cách tiến độ giữa sự đồng thuận cam kết cấp nhà nước và khối được đề xuất quá lớn, bộ điều khiển quy trình sẽ điều chỉnh nhịp độ của các đề xuất khối.
5. commit_block_hash (API lớp thực thi)
Đầu vào: Nhận một tập hợp các vectơ block_ids, đại diện cho các khối cần được gửi.
Đầu ra: Trả về Kết quả<()>, cho biết thao tác có thành công hay không.
Mục đích: Khi cam kết trạng thái được hoàn tất, lớp đồng thuận sẽ thông báo cho lớp thực thi để gửi hàm băm khối vào bộ lưu trữ blockchain.
Đường dẫn Blockchain
Gravity SDK sử dụng kiến trúc đường dẫn năm giai đoạn để tối đa hóa việc sử dụng tài nguyên phần cứng dẫn đến thông lượng cao hơn và độ trễ thấp hơn. Quy trình xen kẽ các nhiệm vụ giữa các khối khác nhau và người quản lý quy trình sử dụng cơ chế phản hồi để đảm bảo rằng chuỗi khối tiến triển ổn định. Ba giai đoạn đầu tiên thuộc về lớp đồng thuận, trong khi hai giai đoạn cuối thuộc về lớp thực thi.
Mỗi giai đoạn được giải thích như sau:
· Giai đoạn 1: Tuyên truyền giao dịch: Giai đoạn này Tuyên truyền hiệu quả các giao dịch giữa những người xác nhận, đảm bảo bao gồm các giao dịch kịp thời và đáng tin cậy trong quá trình xây dựng khối. Thiết kế này tách riêng cơ chế đồng thuận và truyền bá giao dịch, đồng thời tuân theo Narwhal & Tusk và Ý tưởng của Aptos là người xác thực liên tục chia sẻ các lô giao dịch, sử dụng tất cả tài nguyên mạng để chạy đồng thời. Khi một lô giao dịch nhận được chữ ký trọng số 2f+1 (tạo thành PoAv hoặc bằng chứng về tính khả dụng), đảm bảo rằng lô giao dịch đó được lưu trữ bởi ít nhất f+1 người xác minh trung thực, để tất cả những người xác minh trung thực có thể truy xuất những thông tin này. giao dịch để thực hiện.
· Giai đoạn 2: Sắp xếp siêu dữ liệu khối: Giai đoạn này thiết lập một trật tự giao dịch nhất quán và được chấp nhận cũng như chặn siêu dữ liệu trong mạng. Cơ chế đồng thuận (AptosBFT) tuân theo quy tắc 2 chuỗi để cung cấp các khối chịu lỗi Byzantine. Các khối sau đó sẽ chuyển sang giai đoạn thực thi, sẵn sàng để xử lý song song.
· Giai đoạn 3 (BSR): Thực thi giao dịch song song: Giai đoạn này là một phần của lớp thực thi, trong đó các giao dịch được thực hiện song song. Kết quả thực hiện sẽ được chuyển sang giai đoạn cam kết trạng thái.
· Giai đoạn 4: Cam kết của Nhà nước: Giai đoạn này hoàn thành các thay đổi trạng thái do thực hiện giao dịch gây ra và chuẩn bị cho việc hoàn thiện khối. Cam kết trạng thái và thực hiện giao dịch được tính toán không đồng bộ để đảm bảo rằng việc thực hiện khối tiếp theo không bị cản trở bởi cam kết trạng thái khối hiện tại.
· Giai đoạn 5: Tính bền vững của trạng thái: Giai đoạn này tiếp tục duy trì các thay đổi trạng thái đã cam kết đối với việc lưu trữ trên blockchain. Trạng thái gốc cuối cùng và dữ liệu liên quan được lưu trữ trong Gravity Store, sử dụng công cụ lưu trữ được tối ưu hóa cao được thiết kế để truy cập nhanh và đáng tin cậy. Đồng thời, mempool và Quorum Store được thông báo để xóa các giao dịch không thể đưa vào trong tương lai nữa.
Các mô-đun đặt cược và đặt lại
Xây dựng khu vực Lớp 1 Bằng chứng cổ phần (PoS) an toàn Blockchain là một nhiệm vụ phức tạp, đặc biệt là khi chỉ dựa vào các token cụ thể trên chuỗi để đặt cược. Phương pháp này có thể gặp phải các vấn đề về an ninh kinh tế không đủ trong giai đoạn đầu, chẳng hạn như biến động giá trị mã thông báo hoặc sự tham gia hạn chế của người xác nhận. Để giải quyết vấn đề này, Gravity SDK cung cấp mô-đun Đặt cọc và Đặt lại linh hoạt được thiết kế để cải thiện tính bảo mật của mạng thông qua các cơ chế đặt cược cục bộ và bên ngoài.
Một trong những chiến lược chính của Gravity SDK là giới thiệu EigenLayer
Mô-đun này không chỉ hỗ trợ Đặt lại tài sản mà còn hỗ trợ đặt cược Mã thông báo ERC20 tùy chỉnh trên các chuỗi được hỗ trợ, chẳng hạn như G Token trên Ethereum. Người xác thực có thể tham gia vào sự đồng thuận bằng cách cam kết các Token được phép này và đóng góp vào tính bảo mật của mạng. Quyền biểu quyết của người xác thực được tính dựa trên tổng giá trị cổ phần của họ, bao gồm các mã thông báo và tài sản tùy chỉnh trong giao thức Đặt lại. Tính toán này dựa trên cấu hình cụ thể của chuỗi, đảm bảo rằng mỗi chuỗi có thể linh hoạt thiết lập các quy tắc đặt cược và cam kết lại theo nhu cầu riêng.
Trình quản lý Epoch trong công cụ đồng thuận cộng tác trực tiếp với mô-đun Đặt cược để tính toán trọng số của vòng bộ xác thực tiếp theo. Nó đảm bảo rằng quy trình đồng thuận phản ánh chính xác động lực đặt cược mới nhất bằng cách lấy giá trị cam kết từ lớp thực thi. Trong kiến trúc này, các tài sản chuỗi chéo (chẳng hạn như tài sản đặt cọc từ Ethereum) trước tiên phải được kết nối với lớp thực thi trước khi chúng có thể được sử dụng để tính tổng giá trị cổ phần của người xác thực. Lớp thực thi chịu trách nhiệm thực hiện cơ chế bắc cầu, có thể xử lý giao tiếp xuyên chuỗi linh hoạt hơn. Các giải pháp khả thi bao gồm cầu nối PoS, bằng chứng không có kiến thức về trạng thái chuỗi và nhắn tin xuyên chuỗi tự khởi động được nhúng.
Các chi tiết kỹ thuật khác, thiết kế API và mô tả đầy đủ về cơ chế Đặt cọc và Đặt lại sẽ được giới thiệu trong các tài liệu tiếp theo.
Gravity Reth: Lớp thực thi EVM của Block Stream Reactor
Trong kiến trúc Gravity SDK Tích hợp Lớp thực thi Máy ảo Ethereum (EVM) đặt ra những thách thức đặc biệt, đặc biệt là khi tận dụng toàn bộ khả năng của công cụ đồng thuận theo đường dẫn của nó. Để đạt được sự tích hợp liền mạch và nhận ra toàn bộ tiềm năng của kiến trúc này, chúng tôi cần thực hiện một số tối ưu hóa quan trọng đối với ứng dụng khách Ethereum nguồn mở. Những tối ưu hóa này về cơ bản biến đổi reth thành Gravity reth, một lớp thực thi EVM được tối ưu hóa đường ống được thiết kế riêng cho các công cụ đồng thuận đường ống.
Cấu trúc blockchain truyền thống xử lý các khối một cách tuần tự, đảm bảo rằng mỗi khối được xác minh và thực thi đầy đủ trước khi khối tiếp theo được đề xuất. Tuy nhiên, Gravity SDK áp dụng cơ chế đồng thuận quy trình phân tách các giai đoạn xử lý khối khác nhau để cải thiện hiệu suất. Sự thay đổi mô hình này gây ra sự phức tạp:
Giao dịch không mong đợi: Trong chuỗi đường ống, mempool không thể truy cập khối mới nhất do quá trình thực thi khối trước đó có thể chưa hoàn thành. tình trạng của thế giới. Do đó, các giao dịch có trong các khối được đề xuất có thể không được thực hiện tại thời điểm đề xuất vì tính hợp lệ của chúng không thể được xác minh một cách nghiêm ngặt nếu không có trạng thái mới nhất.
Kết quả thực thi không chặn: Để ngăn đường ống bị đình trệ, kết quả thực thi không được ngăn cản việc tạo khối tiếp theo. Lớp thực thi phải có khả năng xử lý các khối được đề xuất một cách không đồng bộ và trả về kết quả thực thi ở giai đoạn sau mà không cản trở quá trình đồng thuận. Đối với EVM, điều này có nghĩa là blockhash cần được xác định lại để loại bỏ sự phụ thuộc vào trường stateRoot trong tiêu đề khối.
Để giải quyết những vấn đề này, chúng tôi đã giới thiệu bốn giải pháp tối ưu hóa chính:
· Block Block Stream Lò phản ứng (BSR): BSR được thiết kế để thích ứng với quy trình đề xuất khối theo đường dẫn của Gravity SDK. Nó cho phép lớp thực thi liên tục sử dụng luồng các khối được đề xuất, hoạt động như một lò phản ứng xử lý các khối không đồng bộ. BSR thiết lập vòng phản hồi động với cơ chế đồng thuận, kết hợp với các tín hiệu áp suất ngược thích hợp. Các tín hiệu này điều chỉnh tốc độ của các đề xuất khối và cam kết trạng thái trong thời gian thực dựa trên thông lượng và độ trễ của lớp thực thi. Nếu lớp thực thi bị chậm do các giao dịch phức tạp hoặc hạn chế về tài nguyên, cơ chế áp lực ngược sẽ giảm tỷ lệ đề xuất khối để đảm bảo tính ổn định của hệ thống.
· Tách rời việc gửi trạng thái và thực hiện giao dịch: Tối ưu hóa thứ hai liên quan đến việc tách tính toán gửi trạng thái khỏi thực hiện giao dịch. Bằng cách tách các quy trình này, chúng tôi đạt được sự không đồng bộ hóa các tính toán gửi trạng thái, do đó việc thực thi các khối tiếp theo không cần phải chờ hoàn thành việc gửi trạng thái của khối hiện tại. Chúng tôi đã xác định lại blockhash để loại bỏ sự phụ thuộc vào trường stateRoot trong tiêu đề khối nhằm đảm bảo rằng việc tính toán gốc trạng thái không ngăn cản việc tạo khối tiếp theo.
· Tối ưu hóa lớp lưu trữ: Trong kiến trúc đường ống, bộ nhớ đệm hiệu quả và tính bền vững của các giá trị trạng thái nhiều phiên bản cũng như việc gửi trạng thái là rất quan trọng. Tối ưu hóa thứ ba tập trung vào việc tăng cường lớp lưu trữ để đáp ứng những nhu cầu này mà không gây ra tắc nghẽn. Bằng cách tối ưu hóa cơ chế lưu trữ, chúng tôi đảm bảo rằng dữ liệu trạng thái có thể được ghi và truy xuất nhanh chóng với tính đồng thời cao. Điều này bao gồm việc xây dựng các công cụ lưu trữ nhiều phiên bản và hỗ trợ I/O không đồng bộ từ cơ sở dữ liệu đến API lưu trữ.
· EVM song song: Tối ưu hóa cuối cùng liên quan đến việc thực hiện giao dịch song song trong EVM. Chúng tôi đã phát triển Grevm, một thời gian chạy EVM song song giúp tăng tốc đáng kể quá trình xử lý giao dịch bằng cách thực hiện đồng thời các giao dịch. Grevm tận dụng các gợi ý phụ thuộc dữ liệu thu được từ mô phỏng giao dịch để tối ưu hóa việc thực thi song song, giảm việc thực hiện lại giao dịch và tăng thông lượng.
Grevm (Trọng lực EVM) - Thực thi EVM song song
Grevm là một dự án nguồn mở được lưu trữ trên GitHub (nếu nó chưa phải là nguồn mở thì trong tương lai nó sẽ là nguồn mở). Vui lòng xem README để biết thêm thông tin.
Grevm (Gravity EVM) dựa trên trên Thời gian chạy EVM song song nguồn mở cho revm. Thuật toán của Grevm được lấy cảm hứng từ BlockSTM và được cải tiến bằng cách giới thiệu các biểu đồ phụ thuộc dữ liệu giao dịch thu được từ kết quả mô phỏng. Cơ chế này giúp việc lập kế hoạch thực hiện song song hiệu quả hơn và giảm thiểu việc thực hiện lại giao dịch.
Trong các điểm chuẩn của chúng tôi, Grevm hiện là triển khai EVM song song nguồn mở nhanh nhất. Đối với các giao dịch không có xung đột, Grevm nhanh hơn 4,13 lần so với thực thi tuần tự, chạy ở tốc độ 26,50 gigagas/s. Nếu bạn mô phỏng độ trễ I/O trong thế giới thực là 100 μs thì tốc độ này nhanh hơn 50,84 lần so với thực thi tuần tự với thông lượng là 6,80 gigagas/s. Sự tăng vọt hiệu suất này là do sự tích hợp giữa thực thi song song và các hoạt động I/O không đồng bộ - việc song song hóa cho phép các hoạt động I/O chồng chéo một cách hiệu quả, giúp tăng tốc hiệu suất hơn nữa.
Ý tưởng cốt lõi của Grevm là khai thác sự phụ thuộc dữ liệu giữa các giao dịch để tối ưu hóa việc thực thi song song thông qua các bộ đọc/ghi giao dịch suy đoán. Mặc dù không phải tất cả các mẹo đều hoàn toàn chính xác nhưng các mẹo dựa trên mô phỏng này thường đủ hữu ích. Ví dụ: trên mạng chính Ethereum, dựa trên lịch sử sử dụng Gas, khoảng 30% giao dịch là chuyển Ether đơn giản và 25%-30% khác là chuyển mã thông báo ERC20. Các giao dịch này thường chỉ liên quan đến việc đọc và ghi một số lượng tài khoản hạn chế. các khe lưu trữ. Đối với các giao dịch này, kết quả mô phỏng luôn chính xác.
Dựa trên những hiểu biết sâu sắc này, chúng tôi đã phát triển khung thực thi song song ba giai đoạn cho Grevm như một phần tiếp theo của mô hình Block-STM, kết hợp với phần phụ thuộc Dữ liệu gợi ý:
· Giai đoạn 1: Tạo gợi ý và tải trước trạng thái - mô phỏng các giao dịch để thu thập các gợi ý phụ thuộc và khởi động bộ nhớ đệm. Giai đoạn này có thể được thực hiện tại các thời điểm khác nhau, tùy thuộc vào thiết kế của blockchain. Ví dụ: khi một giao dịch mới đến mempool, một mô phỏng có thể được chạy ngay lập tức để chuẩn bị trước các gợi ý phụ thuộc.
· Giai đoạn 2: Phân tích phụ thuộc – Chuyển đổi các gợi ý phụ thuộc được thu thập trong giai đoạn mô phỏng thành Đồ thị chu kỳ có hướng (DAG) thể hiện sự phụ thuộc giữa các giao dịch. DAG này được sử dụng để lập kế hoạch lập lịch giao dịch trong các lần thực hiện song song tiếp theo.
· Giai đoạn 3: Thực thi song song với giải quyết xung đột - Giao dịch được thực hiện song song bằng cách sử dụng phiên bản sửa đổi của thuật toán BlockSTM dựa trên DAG phụ thuộc. Bộ lập lịch không còn lựa chọn các giao dịch theo đúng số thứ tự của giao dịch trong khối (chẳng hạn như 1, 2, 3, ..., n) mà ưu tiên các giao dịch theo DAG để giảm thiểu xung đột và giảm nhu cầu tái lập lịch trình. -thi hành.
Gửi trạng thái lô không đồng bộ
Việc tạo ra các cam kết trạng thái vẫn là một nút thắt chính trong quy trình blockchain, xuất phát từ tính chất tuần tự vốn có của Merkleization. Mỗi tính toán cây con phải được hoàn thành trước khi cam kết trạng thái cuối cùng có thể được tạo ra, điều này dẫn đến độ trễ đáng kể. Mặc dù các giải pháp hiện có như ,-We%20recently%20wrote" target="">reth Song song cấp tài khoản) đưa ra một mức độ song song nhất định nhưng vẫn còn nhiều chỗ để tối ưu hóa. Trong bối cảnh lớp thực thi Block Stream Reactor (BSR) của Gravity reth, sự đồng thuận gửi trạng thái được tách rời khỏi thực thi giao dịch và các tính toán gửi trạng thái bị trì hoãn và theo đợt có thể được thực hiện không đồng bộ mà không chặn việc thực thi.
Để giải quyết những vấn đề này, khung đề xuất đưa ra những cải tiến quan trọng sau:
Tính toán băm hàng loạt không đồng bộ: Lấy Tận dụng lợi thế của việc tách rời sự đồng thuận gửi trạng thái và thực hiện giao dịch, khung này thực hiện tính toán không đồng bộ về việc gửi trạng thái. Cập nhật gốc trạng thái được thực hiện theo đợt (ví dụ: được tính 10 khối một lần) để giảm tần suất tính toán gốc trạng thái. Phương pháp xử lý hàng loạt này cho phép tính toán băm hiệu quả bằng cách tổng hợp các nút bẩn được chia sẻ, từ đó giảm thiểu chi phí cập nhật thường xuyên và giảm chi phí tính toán tổng thể. Đối với các khối nhỏ, việc xử lý hàng loạt có thể làm tăng đáng kể tính song song; đối với các khối lớn, nó có thể giảm chi phí tính toán tổng thể.
Song song hóa hoàn toàn: Khung mở rộng song song hóa cho toàn bộ cây trạng thái chứ không chỉ một cây tài khoản. Đối với các nút được đánh dấu là "bẩn", khung sử dụng thuật toán tính toán trạng thái song song để chia cây thành các cây con độc lập và xử lý đồng thời các cây con này. Kết quả được tổng hợp ở cấp cao nhất để tính toán gốc cuối cùng một cách hiệu quả. Cách tiếp cận này đảm bảo rằng các khối lớn với số lượng giao dịch và thay đổi trạng thái lớn có thể tận dụng tối đa lợi thế của đa luồng để tối đa hóa thông lượng.
Thay thế gốc trạng thái nhanh: Để thích ứng với tiêu đề khối và mã opcode BLOCKHASH của Ethereum (yêu cầu quyền truy cập vào gốc trạng thái của 256 khối cuối cùng), chúng tôi đã xác định lại Trạng thái gốc. Thay vì dựa vào các cam kết trạng thái cuối cùng (không có sẵn trong quá trình thực hiện giao dịch), chúng tôi tính toán gốc trạng thái dưới dạng hàm băm của tập thay đổi khối kết hợp với gốc trạng thái trước đó. Cách tiếp cận này làm cho việc tính toán gốc trạng thái nhanh hơn mà không cần phải đợi cam kết trạng thái hoàn chỉnh.
Cửa hàng trọng lực
Để đáp ứng nhu cầu về blockchain hiệu suất cao cho việc quản lý dữ liệu quy mô lớn, Gravity Store nổi lên như một lớp lưu trữ nhiều phiên bản được tối ưu hóa. Nó dựa trên thiết kế của reth, giúp giảm vấn đề mở rộng trạng thái bằng cách tách biệt lưu trữ gửi trạng thái và lưu trữ dữ liệu trạng thái, đồng thời giảm chi phí đọc và ghi dữ liệu. Tuy nhiên, lớp thực thi của Gravity reth cần hỗ trợ thêm cho việc xử lý song song và gửi trạng thái không đồng bộ, điều này đặt ra nhiều yêu cầu kỹ thuật hơn.
Để giải quyết những thách thức này, Gravity Store đề xuất cấu trúc cây nhiều phiên bản hiệu quả , được thiết kế riêng cho kiến trúc BSR (Lò phản ứng dòng khối) của chúng tôi. Cấu trúc cây này hỗ trợ quản lý cập nhật trạng thái nhiều phiên bản. Khác với thông lệ truyền thống là cập nhật giá trị băm ngay sau khi sửa đổi, Gravity Store sẽ đánh dấu nút đã sửa đổi là "nút bẩn" để trì hoãn quá trình xử lý và thực hiện hàng loạt các phép tính băm. Thiết kế này cho phép nhanh chóng tạo các phiên bản mới, truy vấn hiệu quả dữ liệu phiên bản được chỉ định và dọn sạch các phiên bản cũ dưới độ cao được chỉ định, cải thiện đáng kể hiệu suất quản lý trạng thái blockchain.
Chúng tôi cũng đang nghiên cứu phát triển độc lập công cụ lưu trữ Gravity DB, được thiết kế để cung cấp lớp lưu trữ được tối ưu hóa cho các ứng dụng blockchain và hỗ trợ các hoạt động I/O không đồng bộ hoàn toàn. Thiết kế của công cụ này được lấy cảm hứng từ LETUS, nhật ký hiệu suất cao cho chuỗi khối có cấu trúc chung- công cụ cơ sở dữ liệu mục đích. Nhà phát triển chính của chúng tôi, Richard, một trong những tác giả chính của LETUS, sẽ trình bày chi tiết về thiết kế của nó trong một bài đăng blog sắp tới.
Kết luận
Gravity Chain là blockchain lớp đầu tiên tương thích với EVM hiệu suất cao, được thiết kế đặc biệt để đáp ứng nhu cầu về khả năng mở rộng và hiệu suất của các ứng dụng web3 hiện đại. Kết hợp Gravity SDK, công cụ đồng thuận AptosBFT PoS theo đường dẫn và lớp thực thi Block Stream Reactor Gravity reth do Grevm điều khiển, Gravity đạt được thông lượng giao dịch 1 gigagas mỗi giây, thời gian xác nhận giao dịch dưới giây và cơ chế cam kết lại. Bảo mật PoS. Thiết kế của các thành phần kỹ thuật này cung cấp nền tảng vững chắc cho các ứng dụng web3 để tạo ra các chuỗi khối L1 thay thế tùy chỉnh hoặc các giải pháp L2 hiệu quả hơn và đặc biệt phù hợp để tối ưu hóa các kịch bản sử dụng chuỗi EVM.
Bài viết này được gửi đi và không thể hiện quan điểm của BlockBeats
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
Bài viết liên quan
