bản tóm tắt
Supra tích hợp nhiều năm đổi mới vào một kiến trúc mạnh mẽ và hiệu suất cao, được tích hợp hoàn toàn theo chiều dọc với sự hỗ trợ hợp đồng thông minh MultiVM và các dịch vụ gốc, bao gồm dự báo giá, số ngẫu nhiên trên chuỗi, giao tiếp xuyên chuỗi và khả năng tự động hóa.
Trên cơ sở đó, bài viết trình bày chi tiết về quy trình giao dịch từ đầu đến cuối của chuỗi khối Supra và chỉ ra cách giảm thiểu rủi ro kiểm duyệt và mối đe dọa từ các cuộc tấn công Giá trị có thể trích xuất tối đa (MEV) một cách hiệu quả.
Mạng Supra cung cấp nhiều dịch vụ và khả năng dựa trên nền tảng bảo mật chung. Chúng bao gồm các công nghệ tiên tiến: Giao thức Oracle phân tán (DORA), Hàm ngẫu nhiên có thể xác minh phân tán (DVRF), mạng tự động có độ trễ khối bằng 0, kiến trúc vùng chứa lấy cảm hứng từ AppChain, hỗ trợ nhiều VM và được tối ưu hóa thông qua xử lý giao dịch song song Thực thi khối. Ngoài ra, thiết kế chuỗi chéo của Supra - HyperLoop và HyperNova - biến Supra trở thành IntraLayer đầu tiên trên thế giới hiện thực hóa kết nối đa chuỗi thông qua logic nền tảng hợp đồng thông minh.
1. Tích hợp theo chiều dọc và hoàn chỉnh các dịch vụ blockchain
Supra cam kết thúc đẩy quá trình chuyển đổi công nghệ blockchain thông qua nghiên cứu đột phá và khả năng kỹ thuật xuất sắc. Mục tiêu là xây dựng chuỗi khối lớp 1 hiệu quả, tích hợp đầy đủ các dịch vụ liên quan đến chuỗi khối để cung cấp cho người dùng cá nhân, khách hàng tổ chức và Nhà phát triển cung cấp các giải pháp tích hợp và. trải nghiệm người dùng mượt mà.
Trong bài viết này, chúng tôi sẽ chỉ ra cách công nghệ Supra diễn giải câu nói nổi tiếng của triết gia Hy Lạp cổ đại Aristotle: Tổng thể lớn hơn tổng các phần của nó. Tuân thủ khái niệm tích hợp theo chiều dọc hoàn chỉnh, Supra cung cấp một bộ chức năng blockchain toàn diện và dịch vụ , hỗ trợ phát triển hệ sinh thái phong phú và các kịch bản ứng dụng đa dạng.
Tổng quan về chức năng cốt lõi
Các dịch vụ gốc được cung cấp bởi chuỗi khối Supra cho dApps (được hiển thị trong Hình 1) bao gồm các chức năng cốt lõi sau:
Chuỗi khối lớp 1
Hỗ trợ nhiều loại tài sản, bao gồm mã thông báo gốc, mã thông báo có thể lập trình được và không thể thay thế được cũng như mã thông báo chuỗi chéo được tiêu chuẩn hóa.
Môi trường thực hiện hợp đồng thông minh
Cung cấp nhiều nền tảng hợp đồng thông minh hoàn chỉnh Turing trên chuỗi, phù hợp với nhiều ứng dụng blockchain công khai khác nhau như giao thức DeFi, trò chơi blockchain, xổ số, theo dõi chuỗi cung ứng, v.v.
Dịch vụ dữ liệu ngoài chuỗi
Cung cấp các dịch vụ dữ liệu dựa trên nhu cầu (kéo) và truyền phát (đẩy), bao gồm dự báo giá tiền điện tử, tỷ giá hối đoái, chỉ số chứng khoán, dữ liệu thời tiết, v.v. Những dữ liệu này được truyền qua Giao thức Oracle phân tán (DORA) của Supra, không chỉ phục vụ chuỗi khối Supra mà còn hỗ trợ các mạng chuỗi khối khác.
Hình 1 Tích hợp toàn diện theo chiều dọc
Dịch vụ số ngẫu nhiên đẩy và kéo trên chuỗi <br/>Cung cấp các hàm ngẫu nhiên có thể xác minh phân tán (dVRF) ở định dạng phát trực tuyến và theo yêu cầu cho người dùng Web 2.0 và Web 3.0 để tạo và phân phối dịch vụ số ngẫu nhiên.
Mạng tự động hóa <br/>được sử dụng để lên lịch thực hiện giao dịch dựa trên các nút thời gian cụ thể, các sự kiện trên chuỗi hoặc các sự kiện ngoài chuỗi được cung cấp thông qua DORA. Ví dụ: khách hàng có thể đưa ra yêu cầu: Vào chính xác 12:00 EST ngày 1 tháng 6 năm 2025, hãy bán DOGE của tôi nếu giá ETH trên 4.000 USD.
Chuỗi dành riêng cho ứng dụng (AppChain)
Các container trên Supra mang lại sự linh hoạt và quyền tự chủ cho AppChain với chi phí triển khai thấp hơn đáng kể và được hưởng lợi từ hiệu suất cao, bảo mật chung và tính thanh khoản thống nhất của mạng Supra.
2. IntraLayer: Kết nối Supra và các blockchain khác
Mặc dù Supra cung cấp một loạt dịch vụ gốc nhưng chúng tôi hiểu sâu sắc thực tế và giá trị của hệ sinh thái đa chuỗi. Để cải thiện khả năng tương tác, chúng tôi đã thiết kế cấu trúc liên kết hình sao (xem Hình 2). Trong cấu trúc này, chuỗi khối L1 của Supra và các dịch vụ tích hợp của nó đóng vai trò là cốt lõi của mạng IntraLayer, giải quyết các vấn đề thông qua các Giải pháp tương tác HyperLoop và HyperNova kết nối các chuỗi khối L1 và L2 khác. .
Là một nền tảng hợp đồng thông minh MultiVM độc lập, Supra không chỉ cung cấp các dịch vụ của riêng mình mà còn cam kết đóng vai trò quan trọng trong hệ sinh thái đa chuỗi. Vai trò này được phản ánh trong việc trao đổi giá trị giữa hoặc “trong mạng”, cho phép giao tiếp an toàn và hiệu quả thông qua các hợp đồng thông minh gốc, chức năng tự động hóa và dịch vụ oracle.
siêu vòng lặp
Dựa trên giao thức chuỗi chéo đa chữ ký truyền thống, HyperLoop là một giải pháp bảo mật đã được phân tích và xác minh nghiêm ngặt bằng lý thuyết trò chơi. Đây là thiết kế sáng tạo đầu tiên trong ngành nhằm đảm bảo độ tin cậy của các giao dịch chuỗi chéo.
siêu tân tinh
Là một giải pháp tương tác không cần tin cậy, HyperNova cung cấp tính bảo mật cao cho giao tiếp xuyên chuỗi, tạo nền tảng vững chắc cho việc trao đổi thông tin và giá trị trong hệ sinh thái đa chuỗi.
Thông qua HyperLoop và HyperNova, Supra đạt được kết nối liên chuỗi rộng rãi, cung cấp cho người dùng và nhà phát triển các công cụ mạnh mẽ, đồng thời thúc đẩy sự tích hợp và phát triển chuyên sâu của hệ sinh thái đa chuỗi.
Hình 2 IntraLayer của Supra
Tính bảo mật của các chuỗi được kết nối không dựa vào các giả định bảo mật của các nút chuyển tiếp hoặc chuỗi chéo truyền thống. Ở đây chúng tôi phác thảo các tình huống cụ thể trong đó HyperLoop và HyperNova phù hợp nhất.
siêu vòng lặp
Chúng tôi nhận thấy rằng giải pháp chuỗi chéo HyperLoop đặc biệt phù hợp để kết nối Optimistic Rollup với Supra vì nó loại bỏ giai đoạn thử thách bằng chứng gian lận cần thiết để đạt được kết quả cuối cùng.siêu tân tinh
Thích hợp để kết nối bất kỳ chuỗi khối L1 Proof-of-Stake (PoS) nào với Supra vì nó duy trì bảo mật L1-to-L1 bằng cách tính toán lại sự đồng thuận của chuỗi tương tác Supra để duy trì tính bảo mật của chuỗi được kết nối. Chuỗi khối L1 của Supra được thiết kế đặc biệt để hỗ trợ giao tiếp chuỗi chéo an toàn và hiệu quả.
Kế hoạch của chúng tôi bao gồm việc sử dụng HyperNova để liên kết chéo Bitcoin với Supra, đồng thời cho phép kết nối ngược thông qua HyperLoop. Ngoài ra, chúng tôi đang khám phá cách triển khai các giao dịch hoán đổi nguyên tử trong môi trường này để cải thiện hơn nữa khả năng tương tác giữa các chuỗi.
Dưới đây là một số tính năng cốt lõi được hỗ trợ bởi nhóm công nghệ Supra IntraLayer:
Lớp nội bộ DeFi
Là một “nền tảng trên nền tảng”, Supra gói gọn nhiều giao thức DeFi chính thống (chẳng hạn như AMM). Các nhà phát triển dApp có thể dễ dàng truy cập tài sản và thông tin từ nhiều chuỗi khối, đơn giản hóa quá trình phát triển chuỗi chéo.Dịch vụ tự động hóa chuỗi chéo
Chúng tôi cho phép người dùng thiết lập các tác vụ tự động dựa trên các sự kiện và dữ liệu từ nhiều chuỗi khối, từ đó cải thiện đáng kể trải nghiệm người dùng và hiệu quả hoạt động.
Chúng tôi tin chắc rằng việc tích hợp hoàn toàn theo chiều dọc nhiều dịch vụ gốc vào chuỗi khối L1 hiệu suất cao rất phù hợp với tầm nhìn của chúng tôi về việc tạo ra IntraLayer chuỗi chéo đầu tiên trên thế giới. Khi nhu cầu về dịch vụ của chúng tôi tiếp tục tăng trên các blockchain khác, tiện ích của mạng Supra, bao gồm mã thông báo và tài sản trên chuỗi, sẽ tạo ra những biến động tự nhiên về giá trị, khuyến khích hơn nữa người dùng và khách hàng áp dụng cơ sở hạ tầng của chúng tôi.
Đồng thời, do kiến trúc IntraLayer được sử dụng rộng rãi trong các hệ sinh thái khác nhau, nên ngày càng nhiều nhà phát triển sẽ bị thu hút bởi các dịch vụ gốc và hiệu suất tuyệt vời của chúng tôi, sau đó chọn phát triển và xây dựng ứng dụng trực tiếp trên chuỗi khối Supra. Điều này sẽ không chỉ nâng cao lớp DeFi của chúng tôi, bao gồm các giao thức được phát triển nội bộ của chúng tôi và các giao thức của bên thứ ba, mà còn thúc đẩy việc áp dụng và thu hút tổng thể mạng.
Chúng tôi tin rằng với hiệu suất tuyệt vời và các dịch vụ đa dạng, trọn gói, Supra sẽ mang lại làn sóng phổ biến công nghệ Web 3.0 tiếp theo cho cộng đồng nhà phát triển và giúp phát triển nhanh chóng toàn bộ hệ sinh thái.
3. Cốt lõi của Supra - mô hình nút Tribe and Clan
Triết lý cơ bản của Supra là tích hợp hoàn toàn theo chiều dọc, cung cấp hầu như tất cả các dịch vụ liên quan đến blockchain trên một nền tảng duy nhất. Giải pháp này đảm bảo rằng người dùng và nhà phát triển có trải nghiệm thống nhất và mượt mà.
Tích hợp dọc hoàn toàn so với Lớp 2 mô-đun
Supra áp dụng kiến trúc tích hợp theo chiều dọc, khác với các giải pháp L2 mô-đun truyền thống:
Trong L2, các chức năng cốt lõi (chẳng hạn như sự đồng thuận, thực thi và tính khả dụng của dữ liệu) được phân tán trong các mạng độc lập. Mặc dù thiết kế này được gọi là lợi thế mô-đun nhưng nó mang lại nhiều vấn đề:
Độ trễ tăng: Giao tiếp qua mạng gây ra sự chậm trễ về thời gian;
An ninh kinh tế được phân cấp: các mạng khác nhau có mã thông báo riêng và không thể chia sẻ bảo mật;
Độ phức tạp cao: Kiến trúc tổng thể khó duy trì và phối hợp hơn.
Ngược lại, thiết kế tích hợp hoàn toàn theo chiều dọc của Supra hợp nhất tất cả các thành phần thành một chuỗi khối duy nhất:
Chia sẻ an ninh kinh tế và nền kinh tế mã thông báo thống nhất;
Giảm đáng kể độ trễ liên lạc và cải thiện hiệu suất hệ thống;
Cơ chế khuyến khích thống nhất tăng cường an ninh mạng;
Giảm chi phí vận hành tổng thể.
Đột phá về dung sai lỗi Byzantine
Nghiên cứu hệ thống phân tán cho thấy rằng trong các mạng không đồng bộ hoặc đồng bộ một phần, các giao thức Dung sai lỗi Byzantine (BFT) truyền thống chỉ có thể chấp nhận tối đa một phần ba số nút là nút độc hại. Nhưng bước đột phá đổi mới của Supra đã tăng khả năng chịu đựng đó lên một nửa, mang lại sự an toàn và hiệu quả chưa từng có.
Dịch vụ sắp xếp và chuỗi toàn vẹn
Cốt lõi của chuỗi khối Supra L1 là dịch vụ đặt hàng. Giao thức đồng thuận của nó chịu trách nhiệm đặt hàng giao dịch và việc phổ biến dữ liệu giao dịch được tách biệt khỏi dịch vụ đặt hàng. Vì vậy:
Các khối chỉ chứa siêu dữ liệu của các lô giao dịch (chẳng hạn như bản tóm tắt và bằng chứng về tính sẵn có của dữ liệu), không chứa dữ liệu giao dịch cụ thể;
Điều này làm cho các khối của chuỗi khối Supra trở nên rất nhỏ, cải thiện đáng kể hiệu quả hoạt động.
Vì dịch vụ đặt hàng là nền tảng cốt lõi cho tất cả các dịch vụ khác nên chúng tôi gọi Supra Blockchain là Chuỗi toàn vẹn.
Tại sao việc chấp nhận nhiều nút Byzantine hơn lại quan trọng?
Những lợi ích trực tiếp của việc chấp nhận nhiều nút Byzantine hơn là:
Ủy ban nhỏ hơn: Ví dụ: để dung nạp 50 nút độc hại, phương pháp truyền thống yêu cầu 151 thành viên, trong khi Supra chỉ cần 101 thành viên;
Giảm chi phí: Giảm số lượng nút đồng thuận có nghĩa là cần ít nút được đền bù hơn, dẫn đến phí người dùng thấp hơn;
Cải thiện tốc độ thực thi: Với ít nút đồng thuận hơn, quy trình sẽ nhanh hơn trong khi vẫn duy trì tính bảo mật mạnh mẽ.
Hình 3 Bộ lạc, thị tộc và gia đình
Bộ tộc, dòng họ và gia đình
Lõi này tạo điều kiện tích hợp theo chiều dọc hiệu quả và đầy đủ nhiều dịch vụ trên chuỗi khối Supra. Supra đề xuất một khung mạng mới hỗ trợ thực hiện nhiều thuật toán khác nhau ở cấp độ bộ lạc, thị tộc hoặc gia đình.
Như được hiển thị trong Hình 3:
Bộ lạc là một ủy ban gồm các nút chấp nhận tới một phần ba số nút Byzantine;
Clan là một ủy ban nút chấp nhận tối đa một nửa số nút Byzantine;
Gia đình là một ủy ban gồm các nút yêu cầu ít nhất một nút chính xác.
Để đạt được hiệu suất tối ưu và bảo mật mạnh mẽ, mạng của chúng tôi được cấu trúc như sau: các nút hoạt động được tổ chức thành một nhóm chạy giao thức đồng thuận, hỗ trợ dịch vụ đặt hàng và chấp nhận tới một phần ba số nút Byzantine.
Điểm quan trọng trong thiết kế của chúng tôi là toàn bộ nhóm Supra không bắt buộc phải tham gia thực hiện giao dịch hoặc duy trì trạng thái Supra đầy đủ. Thay vào đó, một tập hợp con nhỏ hơn—được gọi là “nhóm”—quản lý trạng thái, thực hiện các giao dịch, tính toán trạng thái sau của một khối và ký các cam kết trạng thái. Do đó, việc phổ biến dữ liệu giao dịch ban đầu chỉ diễn ra ở cấp bang hội và sau đó được phổ biến rộng rãi hơn.
Kiến trúc này rất phù hợp để phân chia trạng thái hiệu quả, trong đó các nhóm khác nhau quản lý các phân đoạn trạng thái khác nhau, có thể sử dụng các máy ảo riêng biệt. Thiết kế này cải thiện khả năng mở rộng, cho phép chúng tôi điều chỉnh thông lượng bằng cách thêm nhiều nhóm (hoặc phân đoạn) hơn. Do đó, tất cả các giao thức không phải là sự đồng thuận (chẳng hạn như phổ biến dữ liệu, thực thi phân đoạn, dịch vụ tiên tri và dịch vụ số ngẫu nhiên phân tán) đều được chạy trong các ủy ban nhỏ (nhóm) chỉ yêu cầu phần lớn các nút chính xác.
Chúng tôi tổ chức các nhóm có trật tự và nhiều nhóm dịch vụ lại với nhau bằng cách chọn ngẫu nhiên các nút thành các nhóm để các nhóm này thực sự tạo thành một phân vùng của bang hội. Sự đồng thuận hoặc trật tự toàn cầu được thực hiện trên các bộ lạc, trong khi các dịch vụ tính toán có thể kiểm chứng khác nhau được thực hiện trên các bộ tộc. Việc lựa chọn các nút ngẫu nhiên này cho phép chúng tôi thực hiện ở cấp bang hội và đưa một yếu tố xác suất vào hệ thống. Ví dụ: giả sử bộ lạc bao gồm 625 nút, với tối đa 208 nút Byzantine. Nếu bộ lạc được chia thành 5 thị tộc, mỗi thị tộc có 125 nút, thì xác suất có hơn một nửa (tức là 62) nút trong bất kỳ một thị tộc nào là các nút Byzantine là khoảng 35 × 10 ⁻⁶. Nói cách khác, khi một bộ tộc có 33% nút Byzantine, xác suất xuất hiện một tộc xấu chỉ là 35 trên một triệu. Trong thực tế, những xác suất này là cực kỳ thấp. Chúng ta sẽ phân tích những xác suất này sâu hơn khi thảo luận về các khoảng thời gian và khoảng thời gian và chỉ ra rằng chúng hầu như không đáng kể trong thực tế.
4. Quy trình giao dịch
Quy trình giao dịch trên chuỗi Supra đại khái như sau và các bước cụ thể sẽ được mô tả chi tiết trong các chương tiếp theo:
Hình 4 cho thấy quy trình giao dịch end-to-end trong chuỗi khối Supra
Người dùng gửi giao dịchttt thông qua ví Starkey của Supra [3] hoặc dApp. Ví được kết nối với nút RPC cổng mà giao dịch ttt được gửi tới.
Nút RPC cổng gửi giao dịch ttt đến nhóm chính của một người đề xuất lô cụ thể dựa trên xác minh và phân loại cơ bản của nó, đồng thời gửi giao dịch đến nhóm phụ của một số người đề xuất lô khác.
Người đề xuất hàng loạt đóng gói các giao dịch từ nhóm chính và thêm các giao dịch đã hết thời gian chờ từ nhóm phụ vào lô. Xem Phần 5 để biết chi tiết.
Lô được truyền đến nút nhóm thực thi tương ứng thông qua giao thức xRBC và Chứng chỉ đại biểu sẵn sàng dữ liệu (DAQC) phải được hình thành trước khi có thể đưa lô vào khối. Các chứng chỉ này được truyền đi khắp nhóm và các đợt được truyền đến nút RPC cổng.
Các nút bộ lạc chạy giao thức đồng thuận Moonshot của Supra. Người đề xuất chặn xây dựng các khối bằng cách đóng gói các DAQC này và siêu dữ liệu lô liên quan.
Giao thức đồng thuận đặt hàng chặn và do đó gián tiếp đặt hàng các giao dịch theo lô. Khi các khối được hoàn thiện, chúng sẽ hiển thị với tất cả các nút bộ tộc đang chạy giao thức đồng thuận, cũng như đối với tất cả các nút bang hội. Các khối hoàn thiện cũng được truyền tới nút RPC cổng.
Nút clan thực hiện lô giao dịch tương ứng từ khối cuối cùng và cập nhật trạng thái blockchain ở cuối blockchain hiện tại. Sau đó, họ tính toán trạng thái sau, thực hiện các hoạt động Merkleization và tính toán các gốc Merkle mới. Lưu ý rằng các clan khác nhau sẽ thực hiện song song các đợt khác nhau. Nút clan ký tên gốc Merkle này và truyền bá nó đến toàn bộ clan cũng như nút RPC cổng.
Nút RPC cổng thực thi khối, tính toán trạng thái hậu và gốc Merkle của nó, xác minh rằng nó phù hợp với gốc Merkle đã ký đã nhận và thông báo cho ví khi giao dịch hoàn tất.
giai đoạn xác nhận cuối cùng
Trong quy trình làm việc của chúng tôi, các giao dịch ttt trải qua ba giai đoạn cuối cùng khác nhau sau đây, mỗi giai đoạn cung cấp sự đảm bảo mạnh mẽ hơn về trạng thái giao dịch trên blockchain:
giai đoạn xác nhận trước
Khi bbb lô chứa giao dịch ttt nhận được Chứng chỉ số lượng sẵn có dữ liệu (DAQC), đảm bảo rằng giao dịch ttt sẽ được đưa vào chuỗi khối. Ở giai đoạn này, mặc dù việc thực hiện giao dịch được đảm bảo nhưng vị trí chính xác và kết quả thực hiện của nó vẫn chưa được xác định.sắp xếp cuối cùng
Khi giao thức đồng thuận hoàn tất xác nhận cuối cùng của khối chứa lô bbb, vị trí của giao dịch ttt trong chuỗi khối sẽ trở nên cố định và không thể thay đổi, do đó xác định thứ tự thực hiện của nó so với các giao dịch khác.quyết định thực hiện
Đây là sự kết thúc của giai đoạn cuối cùng. Nút clan thực thi bbb hàng loạt, cập nhật trạng thái blockchain với kết quả thực hiện giao dịch ttt, tạo phiên bản Merkleized của trạng thái mới, ký tên gốc Merkle đã tạo và phát sóng để hình thành cam kết trạng thái. Sau khi hoàn thành giai đoạn này, kết quả thực hiện giao dịch là cuối cùng và không thể thay đổi được.
Supra L1 hỗ trợ thời gian hoàn thiện nhanh chóng. Thời gian quan sát cho các giai đoạn cuối cùng khác nhau này trong các thí nghiệm của chúng tôi được báo cáo trong Phần 7.
Các chương sau sẽ trình bày chi tiết các bước quan trọng trong quy trình giao dịch trên.
Hình 5 Sơ đồ nhóm không có nhóm bộ nhớ
5. Giải pháp Bucket không có bộ nhớ
Trước tiên, chúng tôi thảo luận về các giao thức mempool hiện có của Ethereum và Solana, sau đó chỉ ra cách Supra cải thiện chúng.
Giải pháp nhóm bộ nhớ Ethereum
Quy trình giao thức nhóm bộ nhớ Ethereum truyền thống như sau:
Máy khách (ví) gửi một giao dịch đến nút RPC, nút này sẽ phát giao dịch thông qua giao thức Gossip để nó đến được tất cả các trình xác thực đồng thuận.
Khi người xác thực trở thành người đề xuất khối, nó sẽ cố gắng đóng gói các giao dịch đã nhận.
Những người đề xuất khối có thể cố gắng kiểm duyệt các giao dịch bằng cách không đưa chúng vào khối, nhưng vì tất cả những người xác thực đồng thuận đều nắm giữ các giao dịch này nên vòng xác thực tiếp theo trở thành người đề xuất khối sẽ bao gồm các giao dịch bị bỏ sót hoặc bị kiểm duyệt. Do đó, giao thức này có khả năng chống kiểm duyệt.
Trong kiến trúc blockchain điển hình, máy khách (ví Web3) gửi giao dịch đến nút RPC công khai. Sau đó, nút RPC sẽ truyền giao dịch đến toàn bộ mạng nút RPC và mạng xác thực đồng thuận thông qua giao thức tin đồn điểm-điểm. Các nút này duy trì cấu trúc dữ liệu được gọi là mempool để lưu trữ tạm thời các giao dịch do khách hàng gửi.
Tiếp theo, trình tạo khối lấy các giao dịch từ mempool, đóng gói chúng thành các khối và xử lý chúng thông qua giao thức đồng thuận. Khi một khối đạt đến trạng thái cuối cùng, tất cả các giao dịch được bao gồm cũng được coi là cuối cùng.
Do có lượng lớn các giao dịch chưa được xử lý tồn đọng trong mempool của Bitcoin và Ethereum, nên trung bình, các giao dịch sẽ ở trong mempool trong một khoảng thời gian dài hơn trước khi được người xây dựng khối chọn. Ngoài ra, các giao thức tin đồn điểm-điểm sẽ làm tăng thêm độ trễ khi truyền bá giao dịch.
Giải pháp Solana không có bộ nhớ
Để giảm độ trễ nhóm bộ nhớ, Solana áp dụng giao thức không có nhóm bộ nhớ, quy trình như sau:
Các khối được tạo theo một lịch trình cố định, được xác định trước bởi người đề xuất khối.
Máy khách (chẳng hạn như ví) gửi giao dịch đến nút RPC. Nút RPC đính kèm dữ liệu phụ trợ như thông tin truy cập đọc và ghi vào giao dịch và gửi nó cho một số người đề xuất sắp đề xuất khối. Nếu người đề xuất bỏ lỡ giao dịch, những người đề xuất khác sẽ đưa giao dịch đó vào khối tiếp theo.
Điều quan trọng cần lưu ý là mạng Solana yêu cầu 32 xác nhận khối để đạt được tính hữu hạn hoàn toàn. Mặc dù Solana được thiết kế để tối ưu hóa độ trễ từ đầu đến cuối nhưng việc trùng lặp giao dịch đôi khi vẫn xảy ra và có thể gây ra tình trạng ngừng hoạt động mạng. So với giao thức mempool của Ethereum, Solana sử dụng giao tiếp trực tiếp đến những người đề xuất khối dự định, một cách tiếp cận giúp giảm thiểu hiệu quả độ trễ truyền tải giao dịch.
Giải pháp giao thức không dùng chung bộ nhớ Supra
Giống như Solana, Supra sử dụng giao thức không có mempool, nhưng chúng tôi thay thế giao thức buôn chuyện truyền thống trên toàn mạng bằng giao tiếp có mục tiêu. Tuy nhiên, cách tiếp cận của Supra khác nhau ở hai điểm chính:
1. Quyết định ngay lập tức
Không giống như hệ thống dựa trên khe thời gian của Solana, Supra sử dụng giao thức đồng thuận kiểu PBFT Byzantine Fault Tolerance (BFT) cổ điển được gọi là Moonshot (xem bên dưới để biết chi tiết). Trong giao thức Moonshot, có thể đạt được tính hữu hạn ngay lập tức khi một khối nhận được chứng chỉ gửi (QC) mà không phải chờ 32 xác nhận khối như Solana. Điều này rút ngắn đáng kể thời gian xác nhận cuối cùng của giao dịch và cải thiện hiệu suất hệ thống.
2. Lưu trữ siêu dữ liệu hàng loạt
Trong thiết kế đồng thuận của Supra, khối không chứa trực tiếp dữ liệu giao dịch mà lưu trữ DAQC và siêu dữ liệu của lô giao dịch (xem Phần 6 để biết chi tiết). Trong giao thức mempoolless của chúng tôi, các giao dịch từ ví khách hàng được đưa vào các nhóm được quản lý bởi những người đề xuất hàng loạt được chỉ định, như trong Hình 5.
Các tính năng của giải pháp xô của chúng tôi như sau:
1) Cơ chế chống trùng lặp
Mỗi giao dịch được chỉ định một người đề xuất lô chính duy nhất, người chịu trách nhiệm đưa giao dịch vào một lô. Mô hình trách nhiệm duy nhất này tự nhiên ngăn chặn các giao dịch trùng lặp được đóng gói vào blockchain.
2) Sự dư thừa và khả năng chống kiểm duyệt
Để đảm bảo rằng các giao dịch không bị bỏ sót, chúng tôi đã giới thiệu những người đề xuất theo lô phụ để dự phòng. Nếu người đề xuất lô chính không bao gồm giao dịch kịp thời thì người đề xuất lô phụ sẽ bao gồm giao dịch đó trong lô sau khi hết thời gian chờ.
Mặc dù nhiều người đề xuất thứ cấp xử lý giao dịch đồng thời có thể dẫn đến việc đóng gói trùng lặp nhưng hệ thống Supra vẫn duy trì tính nhất quán thông qua lần xuất hiện giao dịch đầu tiên.
Các giao dịch lặp lại sẽ tự động bị chấm dứt trong giai đoạn thực hiện do số thứ tự giao dịch không hợp lệ mà không ảnh hưởng đến trạng thái trên chuỗi.
3) Hồ sơ trách nhiệm không thể thay đổi
Nếu người đề xuất phụ đưa giao dịch vào khối thành công, nó sẽ tạo ra một bản ghi bất biến chứng minh rằng người đề xuất chính không thực hiện được nhiệm vụ của mình. Bản ghi này có thể được sử dụng để phân tích mạng sau này nhằm xử phạt những người đề xuất hàng loạt kiểm duyệt giao dịch hoặc gây ra sự chậm trễ không cần thiết để đảm bảo tính công bằng và độ tin cậy của hệ thống.
Quy trình cụ thể của giải pháp tạo nhóm không có nhóm bộ nhớ như sau:
Mỗi người đề xuất theo lô duy trì hai nhóm: nhóm chính và nhóm phụ.
Đối với mỗi giao dịch ttt, hệ thống sẽ gán nó cho một nhóm đề xuất lô cụ thể dựa trên mã định danh duy nhất và không thể đoán trước (băm) của nó. Trong họ này, một nút được chỉ định làm nút đề xuất lô chính cho giao dịch ttt và các nút còn lại là nút đề xuất lô phụ.
Khi nút RPC nhận được giao dịch ttt từ ví hoặc giao diện người dùng dApp, nó sẽ chuyển tiếp nó đến nhóm đề xuất lô tương ứng dựa trên mã định danh của giao dịch. Người đề xuất lô chính lưu trữ ttt giao dịch trong nhóm chính của nó, trong khi người đề xuất lô phụ lưu trữ ttt giao dịch trong nhóm phụ tương ứng của chúng.
Khi xây dựng một lô mới, người đề xuất lô phải đưa tất cả các giao dịch vào nhóm chính của nó. Để bảo vệ chống lại hành vi của Byzantine (chẳng hạn như kiểm duyệt các giao dịch cụ thể bằng cách loại trừ chúng khỏi nhóm chính), những người đề xuất hàng loạt thứ cấp hoạt động như một cơ chế dự phòng.
Khi một lô được người đề xuất lô hoàn thiện và giám sát, người đề xuất sẽ xóa các giao dịch được đưa vào lô khỏi nhóm chính và phụ của nó.
Ngoài ra, mỗi giao dịch ttt đều có thời gian chờ có thể định cấu hình. Nếu ttt không được bao gồm trong lô cuối cùng trước khi hết thời gian chờ, thì những người đề xuất lô phụ trong dòng của nó phải bao gồm ttt từ nhóm phụ khi xây dựng lô tiếp theo. Cơ chế này đảm bảo các giao dịch không bị bỏ sót và tăng khả năng chống kiểm duyệt của hệ thống.
Hình 6 So sánh khái niệm với các giải pháp hiện có
Thiết kế hai lớp này tạo ra sự cân bằng thông minh giữa khả năng chống trùng lặp hiệu quả và khả năng chống kiểm duyệt mạnh mẽ. Ngoài ra, khi người đề xuất lô phụ kết hợp thành công một giao dịch vào lô, một bản ghi bất biến sẽ được tạo để chứng minh rằng người đề xuất chính không thực hiện được nhiệm vụ của mình. Hồ sơ này có thể được sử dụng để phân tích tiếp theo và áp dụng hình phạt đối với những người đề xuất hàng loạt kiểm duyệt giao dịch hoặc gây ra sự chậm trễ không cần thiết.
6. Kiến trúc không có nhóm bộ nhớ: đạt được khả năng tách rời hiệu quả của việc phổ biến dữ liệu giao dịch và sắp xếp giao dịch
Tiếp theo, chúng tôi giới thiệu cách Supra đạt được sự phân tách hiệu quả trong việc phổ biến dữ liệu giao dịch và sắp xếp giao dịch thông qua kiến trúc nhóm-bộ lạc.
Trong những năm gần đây, một số giao thức (như Narwhal/Tusk [11] và Bullshark [20]) đã nhận ra tầm quan trọng của việc truyền dữ liệu giao dịch và áp dụng mô hình thiết kế mới để tách việc truyền dữ liệu khỏi thứ tự giao dịch. Thiết kế này thực hiện truyền và sắp xếp dữ liệu tương ứng thông qua hai giao thức con chạy song song:
Trong trường hợp không có yêu cầu về thứ tự, việc truyền dữ liệu sẽ giảm xuống mức phát sóng đáng tin cậy (RBC), đây là hoạt động cơ bản được nghiên cứu rộng rãi trong các hệ thống phân tán.
Cụ thể, các nút liên tục đề xuất và truyền bá các khối dữ liệu mới thông qua giao thức con RBC, sau đó, các khối dữ liệu này được xác định và xuất ra thông qua giao thức con thứ tự.
Thiết kế này tối ưu hóa hiệu quả việc sử dụng tài nguyên băng thông và cải thiện đáng kể thông lượng hệ thống so với các phương pháp truyền thống. Supra cũng tuân theo nguyên tắc này và tách riêng việc truyền dữ liệu và thứ tự giao dịch. Tuy nhiên, chúng tôi nhận thấy rằng ngay cả trong các giao thức đồng thuận tiên tiến nhất hiện nay, trọng tâm của việc tối ưu hóa vẫn chủ yếu tập trung vào giao thức phụ đặt hàng, điều này thực sự trái ngược với nút thắt cổ chai thực tế của hệ thống.
Ví dụ, ưu điểm chính của Tusk [11] và Bullshark [20] là cái gọi là sắp xếp không có tin nhắn, giúp loại bỏ hoàn toàn chi phí liên lạc trong giai đoạn sắp xếp. Nhưng như chúng tôi đã chỉ ra trước đây, nguồn chi phí truyền thông chính không phải là đặt hàng mà là truyền dữ liệu.
Hình 6 so sánh cách tiếp cận của chúng tôi với các giải pháp hiện có. Mục tiêu của chúng tôi là giảm khối lượng truyền của từng nút trong giai đoạn truyền dữ liệu, đặc biệt là giảm tải truyền tối đa của bất kỳ nút nào. Trong các ứng dụng thực tế, băng thông mạng thường là yếu tố hạn chế chính về thông lượng hệ thống. Do đó, bằng cách tối ưu hóa quá trình truyền dữ liệu, chúng tôi có thể cải thiện hơn nữa hiệu suất và hiệu quả tổng thể của hệ thống.
Giao thức xRBC của Supra
Chúng tôi giảm đáng kể chi phí liên lạc khi truyền dữ liệu thông qua việc đổi mới sử dụng dịch vụ đặt hàng độc lập được điều hành bởi cùng một bộ nút.
Theo cách tiếp cận truyền thống, việc truyền dữ liệu thường được thực hiện thông qua giao thức Phát sóng đáng tin cậy (RBC). RBC yêu cầu hơn 2/3 số nút trung thực trong hệ thống để ngăn các đài truyền hình gửi các lô dữ liệu khác nhau đến các nút khác nhau (tức là vấn đề mơ hồ về người gửi).
Tuy nhiên, chúng tôi nhận thấy rằng việc truyền dữ liệu có thể được cải thiện thành hoạt động RBC thoải mái, được gọi là xRBC, bằng cách tận dụng dịch vụ đặt hàng độc lập. Trong xRBC, chỉ cần hơn 1/2 số nút trung thực để hoàn thành việc truyền dữ liệu, điều này giúp giảm đáng kể chi phí truyền thông.
Ưu điểm thiết kế của xRBC
Trong xRBC, chỉ các nút tham gia là không đủ để ngăn chặn hoàn toàn sự mơ hồ của người gửi. Để giải quyết vấn đề này, dịch vụ đặt hàng sẽ xác nhận lô của đài truyền hình, đảm bảo sự đồng thuận giữa các nút trung thực và do đó loại bỏ những bất đồng. Mặc dù dịch vụ đặt hàng vẫn yêu cầu sự đảm bảo của đa số (hơn 2/3 số nút trung thực), nhưng xRBC có những lợi thế đáng kể so với RBC truyền thống ở các khía cạnh sau:
Chi phí liên lạc thấp hơn: Bằng cách giảm sự phụ thuộc vào phần lớn các nút trung thực, độ phức tạp trong giao tiếp trong hoạt động của giao thức sẽ giảm xuống.
Hiệu suất được cải thiện: xRBC được thiết kế để xử lý việc truyền dữ liệu hiệu quả hơn trong khi vẫn duy trì tính bảo mật tương đương với RBC truyền thống.
Sử dụng phổ biến dữ liệu phân tán của bang hội
Vì các giao dịch chỉ được thực hiện trong một bang hội (một hội đồng phụ ngẫu nhiên của một bộ tộc), dữ liệu giao dịch ban đầu chỉ được chuyển đến nút thực thi bang hội đó. Điều này làm giảm đáng kể tải trên băng thông mạng và hiệu quả hơn so với việc truyền bá dữ liệu khắp bộ lạc. Trong mỗi nhóm thực thi, chúng tôi chỉ định một tập hợp con các nút làm người đề xuất lô, chịu trách nhiệm xây dựng các lô giao dịch từ nhóm tương ứng của chúng và truyền chúng đến tất cả các nút trong nhóm.
Điều đáng nói là những người đề xuất hàng loạt từ các nhóm khác nhau có thể truyền bá các lô giao dịch một cách độc lập và song song mà không cần đồng bộ hóa hoặc chờ đợi các bước giao thức. Cơ chế truyền không đồng bộ song song này tối đa hóa hiệu quả sử dụng băng thông mạng khi đẩy dữ liệu.
Ngoài ra, dữ liệu giao dịch có thể được phổ biến thêm khắp nhóm trong các giai đoạn tiếp theo để đạt được sự đồng bộ hóa trạng thái (để tạo điều kiện phân phối lại nút giữa các kỷ nguyên, xem Phần 9 để biết chi tiết). Thiết kế phổ biến dữ liệu theo giai đoạn này đảm bảo tính nhất quán và linh hoạt của hệ thống đồng thời đảm bảo hiệu suất mạng.
Hình 7 giao thức xRBC
Quy trình cụ thể (minh họa trên hình 7)
Những người đề xuất hàng loạt có trách nhiệm xây dựng các lô giao dịch và gửi chúng đến tất cả các nút trong bang hội.
Khi nút bang hội nhận được một lô hợp lệ, nó sẽ bỏ phiếu về tính sẵn có của dữ liệu của lô đó và truyền kết quả bỏ phiếu tới tất cả các nút trong bang, các nút khác trong bang và nút RPC cổng được chỉ định.
Sau khi bỏ phiếu đa số đơn giản được thông qua, hệ thống sẽ tạo Chứng chỉ sẵn có dữ liệu (DAQC), đảm bảo rằng ít nhất một nút trung thực có dữ liệu giao dịch hoàn chỉnh.
Nếu một nút thiếu một phần dữ liệu lô, nó có thể yêu cầu dữ liệu từ phần lớn các nút bang hội và DAQC đảm bảo rằng yêu cầu này sẽ được đáp ứng.
Đối với các lô vượt quá ngưỡng kích thước hoặc khi không phải tất cả các nút bang hội đều đóng vai trò là người đề xuất lô, chúng tôi giới thiệu mã hóa xóa để đảm bảo phân phối dữ liệu đồng đều trong bang và tối ưu hóa hiệu quả sử dụng băng thông.
Chặn nội dung và tính hữu hạn
Chỉ các chứng chỉ hàng loạt mới được bao gồm trong khối. Khi trình xác thực (nút bộ lạc) của giao thức đồng thuận đóng vai trò là người đề xuất khối, nó sẽ đóng gói tất cả các lô DAQC mà nó nhận được vào khối. Khi một khối đạt đến trạng thái cuối cùng và được người xác thực xác nhận, người xác thực sẽ xóa các DAQC đi kèm này khỏi bộ nhớ đệm vì chúng đã được ghi lại trong khối cuối cùng và không cần phải giữ lại nữa.
Vì các khối chỉ chứa chứng chỉ lô và không lưu trữ trực tiếp dữ liệu giao dịch nên chuỗi khối Supra thực sự là một chuỗi khối cực kỳ nhẹ. Thiết kế này giúp giảm đáng kể kích thước khối và cải thiện hiệu quả truyền dữ liệu.
7. Giao thức đồng thuận
Giao thức đồng thuận Byzantine Fault Tolerance (BFT): Cốt lõi của Blockchain
Giao thức đồng thuận BFT là thành phần cốt lõi của blockchain và chịu trách nhiệm cung cấp thứ tự tiêu chuẩn cho các khối, từ đó đảm bảo rằng các giao dịch trong khối cũng có thứ tự tiêu chuẩn. Chúng tôi đã thiết kế một cách sáng tạo một giao thức đồng thuận BFT mới có tên là Moonshot SMR, được lấy cảm hứng từ giao thức Dung sai lỗi Byzantine thực tế (PBFT) cổ điển và đã thực hiện tối ưu hóa hiệu suất trên cơ sở này.
Như đã đề cập trước đó, các giao thức đồng thuận được thực thi trong nhóm, trong khi việc thực hiện giao dịch được giới hạn trong nhóm. Do đó, Moonshot áp dụng thiết kế đàn hồi và có thể thích ứng linh hoạt theo yêu cầu thông lượng giao dịch thực tế. Điều đáng chú ý là khối không chứa trực tiếp dữ liệu giao dịch mà chỉ chứa chứng chỉ lô, giúp hệ thống hoạt động hiệu quả và nhẹ hơn.
Hiệu suất ánh trăng
Moonshot đạt được các chỉ số hiệu suất chính sau:
Độ trễ đề xuất liên tiếp (độ trễ tối thiểu giữa hai đề xuất khối): độ trễ 1 tin nhắn (md).
Độ trễ nộp hồ sơ: 3 md.
Độ trễ tích lũy để truyền hàng loạt và tạo chứng chỉ sẵn có của dữ liệu: 2 md.
Vì các khối được đề xuất ở mỗi bước nhảy mạng nên các chứng chỉ về tính khả dụng của dữ liệu cần phải được xếp hàng đợi để chờ đề xuất khối tiếp theo, với độ trễ xếp hàng trung bình là 0,5 md.
Do đó, độ trễ tổng thể từ đầu đến cuối của hệ thống là 5,5 md.
Xác minh chính thức: đảm bảo an ninh giao thức
Các giao thức phân tán thường có hành vi phức tạp và không gian trạng thái vô hạn, điều này khiến việc chứng minh tính chính xác của chúng trở nên vô cùng khó khăn. Xác minh chính thức là tiêu chuẩn vàng để đảm bảo an ninh giao thức vì nó có thể chứng minh về mặt toán học rằng không có lỗi trong giao thức.
Để đạt được mục đích này, chúng tôi đã sử dụng trình xác minh IvY của Microsoft để xác minh chính thức các thuộc tính bảo mật của giao thức đồng thuận Moonshot, chứng minh nghiêm ngặt tính năng không bao giờ phân nhánh của nó và cung cấp các đảm bảo về mặt toán học cho tính chính xác và bảo mật của giao thức.
Đánh giá thực nghiệm
Chúng tôi đã tiến hành đánh giá sâu rộng trên Google Cloud Platform (GCP), phân bổ đồng đều các nút trên năm khu vực khác nhau:
us-đông 1-b (Nam Carolina)
Mỹ-tây 1-a (Oregon)
châu Âu-bắc 1-a (Hamina, Phần Lan)
Châu Á-Đông Bắc 1-a (Tokyo)
Úc-Đông Nam 1-a (Sydney)
Các cài đặt thử nghiệm như sau:
Nút máy khách và nút đồng thuận được đặt cùng vị trí
Mỗi giao dịch bao gồm 512 byte dữ liệu ngẫu nhiên và kích thước lô được đặt thành 500 KB
Mỗi thử nghiệm chạy trong 180 giây
Đo độ trễ: Tính thời gian trung bình từ khi tạo giao dịch đến khi gửi bởi tất cả các nút không bị lỗi để xác định độ trễ từ đầu đến cuối
Đo lường thông lượng: Được đánh giá dựa trên số lượng giao dịch hoàn tất mỗi giây
Kiến trúc mà chúng tôi đã thử nghiệm bao gồm 300 nút được chia thành 5 nhóm, mỗi nhóm có 60 nút (12 nút được triển khai trên mỗi vùng GCP). Trong cấu hình này, xác suất một clan (60 nút) trong mạng 300 nút sẽ thất bại do đa số không trung thực nội bộ là 0,0107.
Tuy nhiên, mục tiêu của chúng tôi không chỉ là chứng minh hiệu suất cao của kiến trúc này mà còn chứng minh rằng nó có thể duy trì thông lượng cao và độ trễ thấp ngay cả trong các hệ thống lớn hơn.
Cấu hình phần cứng:
Chúng tôi đã sử dụng 2 máy tiêu chuẩn 32, mỗi máy được trang bị 32 vCPU, bộ nhớ 128 GB và băng thông đầu ra lên tới 16 Gbps.
Thông qua những thử nghiệm này, chúng tôi đã xác minh được khả năng mạnh mẽ của kiến trúc Supra về mặt hiệu suất và khả năng mở rộng.
Hình 8 Thông lượng và độ trễ từ đầu đến cuối
Chúng tôi đã quan sát mối quan hệ giữa thông lượng hệ thống và độ trễ từ đầu đến cuối, như trong Hình 8:
Khi thông lượng đạt 500.000 TPS, độ trễ từ đầu đến cuối vẫn dưới 1 giây.
Ở tốc độ 300.000 TPS, độ trễ xấp xỉ 650 mili giây, gần với giới hạn lý thuyết trong thiết kế kiến trúc của chúng tôi.
Ngoài ra, chúng tôi đã đo thời gian tạo Chứng chỉ sẵn có dữ liệu (DAQC), khoảng 160 mili giây.
Tóm lại:
Độ trễ xác nhận trước cho các giao dịch là khoảng 160 mili giây;
Sắp xếp độ trễ cuối cùng nhỏ hơn 1 giây.
Giao thức đồng thuận DAG
Lấy cảm hứng từ nghiên cứu về các giao thức đồng thuận DAG (Directed Acycle Graph), chúng tôi đã thiết kế một giao thức đồng thuận DAG mới có tên là Sailfish. Giao thức này tối ưu hóa độ trễ gửi thành 1 lần phát sóng đáng tin cậy + 1 độ trễ tin nhắn (md) mà không làm giảm thông lượng hệ thống, vượt qua hiệu suất của giao thức đồng thuận DAG hiện đại nhất hiện nay.
Ngoài ra, chúng tôi đã phát triển một biến thể của Sailfish và kết hợp nó với kiến trúc clan-bộ lạc để cải thiện hơn nữa thông lượng hệ thống. Chúng tôi hiện đang tiến hành thử nghiệm rộng rãi thiết kế này. Nếu Sailfish vượt trội hơn giao thức Moonshot hiện tại trong môi trường mạng quy mô lớn, chúng tôi dự định chuyển giao thức đồng thuận cốt lõi sang Sailfish để đạt được quy trình đồng thuận hiệu quả hơn.
Hình 9 Phương thức thực thi song song của Supra
8.Thực thi
Trạng thái hiện tại của blockchain chứa tất cả tài sản và thông tin quyền sở hữu của chúng, cũng như dữ liệu mới nhất cho tất cả các hợp đồng thông minh. Khi thực hiện giao dịch khối cuối cùng, bạn cần tải phần trạng thái có liên quan, cập nhật trạng thái theo thứ tự các giao dịch trong khối và lưu trữ liên tục trạng thái đã sửa đổi.
Trong các blockchain hiện đại, với sự cải tiến liên tục về khả năng xử lý giao dịch, thời gian thực hiện đã trở thành một yếu tố quan trọng không thể bỏ qua trong sự chậm trễ từ đầu đến cuối của việc xác nhận giao dịch cuối cùng. Xu hướng này đặc biệt rõ ràng trong các chuỗi như Solana, Sui, Aptos và Monad, giúp giảm độ trễ một cách hiệu quả bằng cách thực thi song song.
Kiến trúc clan-clan của chúng tôi cũng cho phép thực hiện các giao dịch song song nhưng được tối ưu hóa ở cấp độ mạng. Cụ thể, việc thực hiện các giao dịch được giới hạn trong nội bộ nhóm và các nhóm khác nhau xử lý song song các lô giao dịch của riêng họ, do đó cải thiện đáng kể hiệu quả thực hiện của hệ thống (xem Hình 9).
8.1 Thực hiện các giao dịch song song
Ngoài việc đạt được tính song song ở cấp độ mạng, chúng tôi cũng nghiên cứu kỹ cách thực hiện hiệu quả các giao dịch song song bằng cách sử dụng đầy đủ các bộ xử lý đa lõi trong một nút duy nhất. Hiện nay, các phương pháp thực hiện song song phổ biến trong tài liệu và công nghiệp chủ yếu được chia thành hai loại:
Kỹ thuật thực hiện lạc quan/suy đoán
Các kỹ thuật được xác định trước dựa trên sự phụ thuộc xác định
Bộ nhớ giao dịch phần mềm (STM)
Công nghệ STM được sử dụng rộng rãi trong lĩnh vực điện toán truyền thống để thực hiện song song các chương trình đa lõi. BlockSTM của Aptos giới thiệu công nghệ STM vào việc thực hiện giao dịch blockchain. Ý tưởng cốt lõi của nó là:
Thực hiện song song các giao dịch một cách tối ưu trên tất cả các lõi có sẵn;
Sau đó xác minh xem có xung đột phụ thuộc giữa các giao dịch hay không;
Nếu tìm thấy xung đột, giao dịch xung đột sẽ được thực hiện lại thông qua bộ lập lịch hợp tác.
Giải pháp sáng tạo siêu việt
Chúng tôi đề xuất một thuật toán thực thi song song STM cải tiến Khác với BlockSTM của Aptos, thiết kế của chúng tôi có thể giải quyết xung đột một cách hiệu quả mà không cần bộ lập lịch. Cách tiếp cận này có thể so sánh với BlockSTM về hiệu suất và kiến trúc, đồng thời chúng tôi hiện đang tiến hành đánh giá chuyên sâu về thiết kế để xác minh những ưu điểm của nó trong các ứng dụng thực tế.
Song song hóa dựa trên thông số kỹ thuật truy cập
Một số blockchain triển khai song song hóa bằng cách chỉ định các mẫu truy cập cho các giao dịch:
Sealevel của Solana yêu cầu các giao dịch khai báo rõ ràng các tài khoản cần được đọc và ghi vào.
Sui yêu cầu các giao dịch chỉ định các đối tượng được đọc và ghi vào (thông qua mã định danh đối tượng) và khai báo xem các đối tượng này là độc quyền hay chia sẻ.
Cách tiếp cận của Polygon thì khác. Người đề xuất khối sử dụng công nghệ BlockSTM để thực thi khối, tính toán trước sự phụ thuộc giữa các giao dịch và đưa các thông tin phụ thuộc này vào khối, cho phép các trình xác thực khác thực hiện song song các giao dịch độc lập.
Tuy nhiên, điều quan trọng cần lưu ý là việc khai báo rõ ràng chế độ truy cập trong giao dịch hoặc bao gồm thông tin phụ thuộc trong khối sẽ làm tăng đáng kể kích thước khối. Điều này có thể khiến băng thông bão hòa nhanh hơn, hạn chế thông lượng tối đa mà hệ thống có thể đạt được.
Dựa trên các phương pháp này, chúng tôi đang phát triển một thuật toán thực thi song song xác định để phân tích tĩnh các hợp đồng thông minh, tự động lấy thông số truy cập của chúng khi hợp đồng được triển khai và lưu trữ các thông số này ở trạng thái blockchain mà không cần nút RPC hoặc cung cấp chế độ truy cập. . Các thông số kỹ thuật này cho phép chúng tôi tối ưu hóa thứ tự tuyến tính của các giao dịch trong khối cuối cùng thành thứ tự một phần (thoải mái), cho phép thực hiện song song các giao dịch độc lập. Phương pháp này không chỉ làm giảm mức sử dụng băng thông mà còn cải thiện thông lượng và hiệu quả của toàn bộ hệ thống.
phương pháp hỗn hợp
Chúng tôi tin rằng phương pháp kết hợp giúp cải thiện thuật toán STM bằng cách tận dụng các thông số truy cập có nguồn gốc tĩnh là hình thức tối ưu của các kỹ thuật thực thi được tối ưu hóa (xem Hình 9). Hiện chúng tôi đang tiến hành đánh giá toàn diện về thiết kế này.
8.2 Công bằng trong trình tự thực hiện
Để đảm bảo tính công bằng trong việc đặt hàng giao dịch, chúng tôi đã thiết kế quy trình gồm hai bước:
Thứ tự ngẫu nhiên ban đầu: Giao thức đồng thuận trước tiên tạo ra thứ tự ngẫu nhiên ban đầu của các giao dịch.
Thứ tự cuối cùng: Thông qua giao thức số ngẫu nhiên trên chuỗi được tạo bởi chữ ký ngưỡng BLS dựa trên khối, thứ tự giao dịch cuối cùng được rút ra và thứ tự thực hiện thực tế của các giao dịch được xác định.
Lớp ngẫu nhiên bổ sung này giảm thiểu một cách hiệu quả các cuộc tấn công Giá trị có thể trích xuất tối đa (MEV) vì những người đề xuất hàng loạt hoặc những người đề xuất khối không thể dự đoán hay thao túng thứ tự thực hiện giao dịch ngẫu nhiên cuối cùng.
Để giải quyết vấn đề thư rác, chúng tôi đã giới thiệu thị trường phí địa phương. Trong tình trạng tranh chấp, chi phí giao dịch sẽ tăng theo cấp số nhân, từ đó nâng cao khả năng chống can thiệp của hệ thống đồng thời đảm bảo tính hiệu quả và công bằng trong việc đặt hàng giao dịch.
8.3 Đa VM
Ethereum đã giới thiệu EVM, một môi trường lập trình trên chuỗi hoàn chỉnh Turing, đã giải phóng đáng kể khả năng sáng tạo trong phát triển dApp, đặc biệt là cung cấp hỗ trợ mạnh mẽ cho các ứng dụng DeFi. EVM mượn kinh nghiệm từ các ngôn ngữ lập trình Web 2.0 và cho ra đời Solidity. Tuy nhiên, với sự phát triển của công nghệ blockchain, cộng đồng dần nhận ra rằng cần có một ngôn ngữ lập trình được thiết kế đặc biệt để chuyển tài sản và quản lý tài sản trên chuỗi. Do đó, nhóm Metas Diem đã phát triển ngôn ngữ Move, ngôn ngữ này sau này sinh ra các biến thể như Aptos Move và Sui Move.
Supra nhận thức sâu sắc tầm quan trọng của các ngôn ngữ lập trình giao dịch trên chuỗi tùy chỉnh, vì vậy họ đã chọn ngôn ngữ Move làm lựa chọn đầu tiên cho nền tảng hợp đồng thông minh của chúng tôi và sẽ ra mắt chuỗi khối L1 với sự hỗ trợ của Move.
Đồng thời, chúng tôi cũng nhận thấy tiềm năng to lớn trong hệ sinh thái đa VM. Các nhà phát triển dưới các máy ảo khác nhau có thể bổ sung cho nhau và cùng nhau thúc đẩy sự đổi mới và phát triển của ngành công nghiệp blockchain. Vì vậy, chúng tôi đã thiết kế một kiến trúc đa VM hiệu quả.
Dựa trên các đặc điểm phân mảnh tự nhiên của kiến trúc bộ tộc-bộ lạc, mỗi bang hội lưu trữ một phân đoạn trạng thái và các bang khác nhau có thể lưu trữ các máy ảo khác nhau.
Sau khi tích hợp nền tảng hợp đồng thông minh Move, Supra sẽ tiếp tục mở rộng sang Máy ảo Ethereum (EVM) để đạt được khả năng tương thích với hệ sinh thái Ethereum khổng lồ. Tiếp theo, chúng tôi sẽ tích hợp Máy ảo Solana (SVM) để hỗ trợ các nhà phát triển sử dụng các ngôn ngữ lập trình được sử dụng rộng rãi như Rust, C và C++ để xây dựng hợp đồng thông minh.
Cuối cùng, Supra cũng sẽ hỗ trợ CosmWasm, cho phép kết nối liền mạch với hệ sinh thái Cosmos đang hoạt động.
Giao tiếp giữa các máy ảo
Trong môi trường nhiều VM, người dùng có thể có nhiều tài khoản trên các máy ảo khác nhau và muốn chuyển tài sản qua các máy ảo. Ngoài ra, mã thông báo gốc $SUPRA của Supra phải được quản lý thống nhất trên tất cả các máy ảo. Để giải quyết vấn đề này, chúng tôi đề xuất quy trình làm việc gồm ba bước đơn giản và hiệu quả:
Gửi giao dịch chuyển giao tài sản máy ảo chéo. Giao dịch này bao gồm hai phần:
Giao dịch ghi nợ tdt_dtd của máy ảo nguồn
Giao dịch đến tct_ctc của máy ảo đích.
Giao dịch ttt lần đầu tiên được thực hiện trên máy ảo nguồn, quá trình khấu trừ hoàn tất và sự kiện tương ứng được kích hoạt.
Giám sát và gửi sự kiện: Chọn ngẫu nhiên một họ từ nhóm của máy ảo nguồn (họ chứa ít nhất một nút trung thực). Các nút này giám sát các sự kiện khấu trừ và chịu trách nhiệm gửi giao dịch tài khoản tct_ctc.
Thực thi máy ảo mục tiêu để ghi nợ cho máy ảo mục tiêu. Nhóm của máy ảo mục tiêu nhận và thực thi tct_ctc để hoàn tất việc ghi nợ tài sản. Tại thời điểm này, quá trình chuyển máy ảo chéo đã hoàn tất.
9. Kỷ nguyên và chu kỳ
Trong kiến trúc của Supra, việc thêm các nút mới vào nhóm hoặc loại bỏ các nút hiện có chỉ được phép ở ranh giới của kỷ nguyên. Khoảng thời gian của một kỷ nguyên có thể được cấu hình và thường được xác định theo số khối hoặc thời gian thực. Chúng tôi dự định đặt thời lượng của kỷ nguyên là khoảng một tuần. Trong mỗi kỷ nguyên, tất cả các nút trong nhóm thực hiện các dịch vụ đặt hàng bằng cách chạy giao thức đồng thuận.
Như được hiển thị trong Hình 10, một kỷ nguyên được chia thành nhiều chu kỳ (Chu kỳ), với thời lượng thông thường của mỗi chu kỳ là khoảng một ngày. Trong mỗi chu kỳ, các nút trong bộ lạc sẽ được phân ngẫu nhiên vào các nhóm khác nhau thông qua VRF (chức năng ngẫu nhiên có thể xác minh) của Supra. Ví dụ:
Trong giai đoạn 2 của kỷ nguyên 1 (e 1 c 2), một nút có thể đóng vai trò là trình xác nhận DORA;
Trong giai đoạn 3 của kỷ nguyên 1 (e 1 c 3), cùng một nút có thể chịu trách nhiệm thực hiện nhiệm vụ thực hiện các giao dịch EVM.
Cơ chế gán lại vai trò nút ngẫu nhiên mỗi chu kỳ này giúp cải thiện đáng kể tính bảo mật của hệ thống và có thể bảo vệ hiệu quả trước các cuộc tấn công của các tác nhân độc hại đang cố gắng nhắm mục tiêu vào các vai trò hoặc chức năng cụ thể.
Hình 10 Thời đại và tuần
Kẻ tấn công tấn công một dịch vụ cụ thể (chẳng hạn như SSS dịch vụ) có thể cố gắng phá hoại dịch vụ đó bằng cách vô hiệu hóa một số nút của nhóm cung cấp SSS dịch vụ.
Để chống lại mối đe dọa này, giao thức tạo khóa phân tán (DKG) được chạy theo mỗi chu kỳ để tổ chức lại bang hội. Chúng tôi có thể đạt được sự tái hợp thường xuyên này nhờ vào sự đổi mới của chúng tôi trong lĩnh vực DKG - sự phát triển của giao thức DKG dựa trên lớp nhóm hiệu suất cao.
Khả năng xuất hiện clan xấu
Như đã đề cập trong Phần 3, chúng tôi phân tích tác động bảo mật của việc lấy một nhóm gồm 625 nút và chia nó thành 5 nhóm (mỗi nhóm 125 nút):
Định nghĩa bang hội xấu: Các nút Byzantine chiếm phần lớn trong bang hội.
Xác suất hình thành bang hội xấu: Xác suất hình thành bang hội xấu ngẫu nhiên là khoảng 35 trên một triệu.
Giả sử rằng mỗi giai đoạn là một ngày và clan phân phối lại các nút thông qua việc tổ chức lại mỗi ngày. Điều này có nghĩa là ngay cả trong trường hợp cực đoan nhất (33% nút trong bộ tộc được điều khiển bởi các tác nhân Byzantine), xác suất một bang hội xấu xuất hiện là cực kỳ thấp, dự kiến chỉ xảy ra 78 năm một lần.
Xác suất cực thấp này gần như không đáng kể và thể hiện đầy đủ độ tin cậy của cơ chế thành lập bang hội của chúng tôi trong việc cung cấp bảo mật mạnh mẽ.
10. Thùng chứa
Supra Container là một tính năng quan trọng được thiết kế cho cộng đồng nhà phát triển và được lấy cảm hứng từ khái niệm Appchain phổ biến hiện nay.
Chúng tôi hoàn toàn nhận ra những lợi thế của chuỗi ứng dụng, đặc biệt là giá trị độc đáo của chúng trong việc cung cấp khả năng có chủ quyền cho các nhà phát triển dApp và cộng đồng của họ. Ngoài ra, chuỗi ứng dụng cũng có thể hỗ trợ các mô hình kinh doanh dựa trên ứng dụng. Hiện tại, Lớp 2, chuỗi bên, chuỗi parachain Polkadot, chuỗi vùng Cosmos (Vùng) và mạng con Avalanche (Mạng con) là những giải pháp hàng đầu trong lĩnh vực chuỗi ứng dụng.
Tuy nhiên, chúng tôi cũng nhận ra rằng những giải pháp này không lý tưởng trong bối cảnh các chuỗi khối có thông lượng cao như Supra L1. Chuỗi ứng dụng thường cần cung cấp các chức năng chính sau:
Hạn chế triển khai hợp đồng thông minh
Mã thông báo khí tùy chỉnh
Định giá khí tùy chỉnh
Khi các chuỗi ứng dụng này được lưu trữ trên các chuỗi thứ cấp (như chuỗi parachain, chuỗi khu vực, mạng con, v.v.), giá Gas của chúng sẽ không giống với giá của các chuỗi chính tương ứng (chẳng hạn như Chuỗi chuyển tiếp Polkadot, Cosmos Hub hoặc Avalanche C -Giá gas tạo ra sự cạnh tranh và sẽ không biến động theo giá chuỗi chính. Thị trường phí địa phương hóa này cung cấp cho người dùng trải nghiệm phí giao dịch dễ dự đoán hơn, lý tưởng cho các ứng dụng thực tế.
Thông qua Supra container, chúng tôi mong muốn kết hợp lợi thế của các chuỗi ứng dụng này với khả năng của chuỗi khối L1 hiệu suất cao để tạo ra một môi trường sinh thái linh hoạt và ổn định hơn cho các nhà phát triển và người dùng.
Hình 11 Thùng chứa
Supra Container là một khái niệm hoàn toàn mới trong lĩnh vực blockchain. Chúng tôi định nghĩa nó là một tập hợp hoặc một gói hợp đồng thông minh phục vụ một hoặc một nhóm dApp có liên quan. Thông qua bộ chứa Supra, chúng tôi đã tối ưu hóa khung thời gian chạy của Supra để cung cấp cho các nhà phát triển dApp trải nghiệm giống như Appchain, với các tính năng đáng chú ý sau:
Mã thông báo khí tùy chỉnh
Định giá khí tùy chỉnh
Hạn chế triển khai hợp đồng thông minh
Tất cả điều này có thể đạt được với chi phí cực thấp, loại bỏ hoàn toàn quy trình rườm rà khi khởi chạy một mạng thứ cấp hoàn toàn mới (chẳng hạn như mạng xác thực yêu cầu khuyến khích đặt cược).
Giải quyết vấn đề phân mảnh thanh khoản
Quan trọng hơn, chúng tôi đã khắc phục được một vấn đề lớn mà các chuỗi ứng dụng thường gặp phải - sự phân mảnh thanh khoản - bằng cách hỗ trợ khả năng kết hợp nguyên tử của các lệnh gọi phương thức vùng chứa chéo. Thiết kế này đảm bảo sự tương tác hiệu quả giữa các container trong khi vẫn duy trì sự tập trung thanh khoản.
Tạo điều kiện thực hiện song song
Trong mô hình Ethereum EVM, mỗi hợp đồng thông minh có một không gian lưu trữ độc lập. Sau khi đưa vùng chứa Supra vào mô hình EVM, trạng thái blockchain có thể được chia thành nhiều phân vùng:
Các giao dịch nội bộ container chỉ truy cập trạng thái của vùng chứa mục tiêu mà không ảnh hưởng đến trạng thái của các vùng chứa khác.
Sự cô lập trạng thái này tối ưu hóa thời gian thực hiện các giao dịch trong một vùng chứa và giảm xung đột giữa các vùng chứa khác nhau.
Dựa trên tính năng này, chúng tôi đã xây dựng hàng đợi chia sẻ công việc đơn giản và hiệu quả để tối ưu hóa việc thực thi song song. Thông qua thiết kế này, các thùng chứa Supra cải thiện đáng kể hiệu quả thực thi của chuỗi khối, đơn giản hóa trải nghiệm của nhà phát triển và thúc đẩy cải thiện hiệu suất của toàn bộ hệ sinh thái.
11. Kết luận
Tầm nhìn đầy tham vọng của Supra như một IntraLayer tích hợp hoàn toàn theo chiều dọc đang hình thành sau nhiều năm nghiên cứu nghiêm ngặt. Chúng tôi đã công bố một số lượng lớn kết quả nghiên cứu tại nhiều hội nghị học thuật hàng đầu, như Bảo mật Quyền riêng tư của IEEE, Hội nghị chuyên đề về bảo mật mạng và phân tán (NDSS), Hội nghị ACM về bảo mật máy tính và truyền thông (CCS), v.v. Ngoài ra, chúng tôi đã xuất bản một loạt sách trắng về các thành phần cốt lõi của mình, bao gồm:
Giao thức đồng thuận Moonshot và Sailfish
Giao thức Oracle phân tán (DORA)
Hàm ngẫu nhiên có thể xác minh được phân phối (DVRF)
Tạo khóa phân tán cụm hiệu quả (DKG)
Thùng siêu cấp
siêu vòng lặp
siêu tân tinh
Lần đầu tiên, Supra trình bày đầy đủ tầm nhìn của chúng tôi về cơ sở hạ tầng blockchain được tích hợp hoàn toàn theo chiều dọc. Hệ thống này kết hợp nhiều giao thức đổi mới được phát triển qua nhiều năm để tạo ra một chuỗi khối tất cả trong một, hiệu suất cực cao.
