Mặc dù Sei Network đã thực hiện nhiều tối ưu hóa và đổi mới trong việc cải thiện tốc độ giao dịch nhưng nó cũng đã hy sinh một phần tính phi tập trung.
Được viết bởi: Delphi Digital
Biên soạn bởi: Babywhale, Foresight News
Vào ngày 4 tháng 1, sàn giao dịch crypto MEXC đã công bố ra mắt quỹ đặc biệt trị giá 20 triệu USD để hỗ trợ phát triển các dự án trọng điểm của Sei Network. Ngay từ ngày 31 tháng 8, Sei Labs đã thông báo rằng họ đã hoàn thành vòng tài trợ ban đầu trị giá 5 triệu đô la Mỹ , do Multicoin Capital dẫn đầu, với các nhà đầu tư tham gia bao gồm Coinbase Ventures, GSR, Flow Traders, Hudson River Trading, Delphi Digital, Tangent, v.v. Một tháng sau khi có thông báo chính thức về việc hoàn tất cấp vốn, Sei Network đã ra mắt quỹ sinh thái trị giá 50 triệu USD để hỗ trợ các ứng dụng DeFi được phát triển trên đó.
Là một trong những nhà đầu tư của Sei Network, Delphi Digital đã viết báo cáo giải thích lý do lạc quan về Sei Network. Tác giả sau đây tóm tắt những nội dung chính của báo cáo để mọi người cùng thảo luận.
Mạng được thiết kế cho DeFi
Khi xây dựng blockchain, chúng tôi thường cố gắng phân loại chúng thành hai loại khác nhau: Chuỗi đích chung hoặc Chuỗi ứng dụng. Chuỗi phổ quát được sử dụng để đổi mới không cần xin phép, trong khi Chuỗi ứng dụng được sử dụng cho các trường hợp sử dụng cụ thể yêu cầu quyền. Nhưng “Chuỗi ứng dụng” không phải là trắng đen mà do chính Chuỗi đó quyết định. Sei là một Chuỗi sinh thái Cosmos sắp ra mắt nhằm mục đích trở thành blockchain Lớp 1 “được thiết kế cho DeFi”.
“Được thiết kế cho DeFi” có nghĩa là thực hiện các thay đổi cơ bản (và đánh đổi) đối với lớp cơ sở để các ứng dụng DeFi có thể phát triển. Sei có công cụ khớp lệnh tích hợp, tốc độ quyết toán dưới giây, xử lý lệnh song song, thực hiện lệnh đơn khối, v.v. Tất cả các chức năng tùy chỉnh này được hoàn thành ở lớp cơ sở. Điều bạn cần biết là Sei không phải là DEX, nó là blockchain Lớp 1 được tối ưu hóa cho DeFi. Đồng thời, Sei không phải là một Chuỗi ứng dụng thuần túy, không giống như THORChain , chỉ tập trung vào Chuỗi chuỗi Chuỗi , mà là một blockchain được phát triển cho các đặc tính của sản phẩm như DEX, hợp đồng và tương lai.
Để hiểu lý do tại sao chúng tôi muốn thực hiện những thay đổi này trong mạng cơ bản, chúng tôi có thể xem xét Serum và Solana. Solana là một blockchain Lớp 1 có mục đích chung được quảng cáo là “Nasdaq trên Chuỗi ” nhắm mục tiêu thời gian xác nhận khối 400 mili giây và thông lượng cực cao. Quan điểm chính của Solana là nền tảng giao dịch sổ lệnh cuối cùng sẽ tiếp quản AMM và chỉ báo trên Solana ủng hộ quan điểm này. Serum là ứng dụng sổ lệnh được xây dựng trên Solana . Đây là ứng dụng được sử dụng nhiều nhất trong hệ sinh thái Solana , chiếm khoảng 1/3 số giao dịch trên Solana . Serum là "lớp sổ lệnh " trên Solana và được sử dụng bởi các dự án như Mango Markets, Zeta, Atrix, Bonfida và Jupiter. Khi mọi người nghĩ đến Solana , họ thường nghĩ đến Serum.
Tuy nhiên, kiến trúc này cũng có một số nhược điểm, đáng chú ý nhất là do Solana là một Chuỗi phổ quát, Serum (và các ứng dụng được xây dựng trên nó) liên tục cạnh tranh tài nguyên với các ứng dụng khác. Các hoạt động không liên quan đến Serum, chẳng hạn như chơi game và đúc NFT, có thể gây ra tắc nghẽn trên Chuỗi , như chúng tôi đã từng trải qua với lần “ngưng hoạt động” của Solana trước đây. Sei đã chọn cách “cắt chân cho vừa đôi giày” và loại bỏ mọi hoạt động không phải DeFi khỏi Chuỗi của họ. Một lời giải thích đơn giản là Sei tương đương với việc Serum tung ra blockchain Lớp 1 của riêng mình: thực hiện các đánh đổi cụ thể để làm cho lớp cơ sở được tối ưu hóa cho DeFi và mang lại cho các ứng dụng DeFi được xây dựng trên đó nhiều lợi thế không công bằng hơn”.
Sự đánh đổi chính ở đây là Sei sẽ không được phép như Solana , vì việc phát triển các ứng dụng trên nó đòi hỏi phải đưa vào danh sách trắng thông qua quản trị. Mặc dù mất đi một số lợi thế của đổi mới không cần xin phép, nhưng bạn có thể tạo ra một hoàn cảnh tối ưu hơn. Công cụ khớp lệnh gốc, oracle giá, thực thi lệnh song song và thực thi lệnh một khối là một số trong những thứ mà Sei đã xây dựng ở cấp cơ sở hạ tầng. Sei là một Chuỗi ứng dụng, nhưng sổ lệnh trên Chuỗi của Sei tạo ra một kiến trúc có thể tổng hợp, cho phép khả năng kết hợp đồng bộ giữa các ứng dụng CosmWasm trên Sei và chia sẻ thanh khoản thông qua công cụ khớp đơn hàng gốc. Là một Chuỗi Cosmos hỗ trợ IBC, nó vốn có khả năng kết hợp không đồng bộ.
Sei đã triển khai một số tối ưu hóa của họ thông qua ABCI++, một nâng cấp sắp tới của Cosmos ' ABCI giúp cho mọi bước của sự đồng thuận đều có thể lập trình được. Sei đã cố gắng sử dụng ABCI++ để thực hiện ba cải tiến: sản xuất khối được tối ưu hóa, phát sóng khối thông minh và thực hiện song song lệnh.
Tối ưu hóa Sei với ABCI++
Đối với giao dịch sổ lệnh tập trung, thời gian sản xuất khối, quyết toán giao dịch và độ trễ là quan trọng nhất đối với nhà tạo lập thị trường. Nhà tạo lập thị trường cần cập nhật giá của họ trong mỗi khối, vì vậy thời gian tạo khối ngắn hơn có nghĩa là khoảng cách giá giữa các khối nhỏ hơn, chênh lệch nhỏ hơn và ít rủi ro hơn cho nhà tạo lập thị trường . Bất cứ điều gì vượt quá vài trăm mili giây đều không thể chấp nhận được (và về lâu dài, vài trăm mili giây có thể vẫn là quá cao). Chuỗi Cosmos tiêu chuẩn có thời gian xác nhận khối khoảng 6 giây, điều này khiến cho sổ lệnh trở thành một giải pháp chưa tối ưu. Tuy nhiên, cái hay của Cosmos là khả năng tùy chỉnh của nó và Sei đã tập trung vào việc thực hiện các thay đổi để tối ưu hóa sự đồng thuận và làm cho nó nhanh nhất có thể (nhắm mục tiêu khoảng 300-600 mili giây). Ba lĩnh vực trọng tâm chính của Sei là:
Tối ưu hóa việc sản xuất khối, phát sóng khối thông minh và thực hiện song song lệnh.
Sei thực hiện điều này bằng cách tận dụng ABCI++. ABCI là giao diện giữa các ứng dụng và sự đồng thuận. Chức năng chính của nó là thực thi các khối được xác định bởi sự đồng thuận. Với ABCI, các ứng dụng chỉ tương tác với sự đồng thuận để ra quyết định và có ít quyền kiểm soát đối với những giao dịch nào được chọn từ mempool. ABCI++ bổ sung khả năng lập trình cho từng bước đồng thuận, cho phép các ứng dụng sắp xếp, sửa đổi, loại bỏ, trì hoãn hoặc thêm giao dịch cũng như giảm thời gian sản xuất khối bằng cách giới thiệu khả năng tối ưu hóa sản xuất khối.
Sau bước Đề án đồng thuận, các ứng dụng có thể bắt đầu tối ưu hóa việc xử lý các khối, song song với các giai đoạn bỏ phiếu trước và tiền cam kết. Sei sau đó sẽ bắt đầu thay đổi trạng thái "thông qua tối ưu hóa" thành trạng thái ứng cử viên tạm thời cho đến khi được đồng thuận chấp nhận. Nếu không được chấp nhận (hiếm khi), khối sẽ bị hủy. Ở bước này, có lượng lớn nhiều dữ liệu cần xử lý và có thể khá chậm. Nhưng bằng cách tối ưu hóa quá trình xử lý thay đổi trạng thái, chúng ta có thể rút ngắn thời gian tạo khối và giảm đáng kể độ trễ (giảm khoảng 300ms).
Ngoài việc tối ưu hóa việc sản xuất khối, Sei còn cải thiện việc phát sóng thông tin khối. Trong Tendermint, khi người xác thực đề xuất một khối, khối này sẽ bao gồm tất cả các chi tiết giao dịch và lượng dữ liệu sẽ rất lớn, nhưng người xác nhận đã thu được khoảng 99,9% số giao dịch này thông qua mempool cục bộ của họ, vì vậy không cần thiết để chờ nhận lại dữ liệu này từ người đề xuất khối. Thay vì gửi tất cả thông tin chi tiết, giờ đây những người đề xuất sẽ chỉ cần gửi hàm băm của từng giao dịch trong khối và người xác thực sẽ có thể nhanh chóng xây dựng lại khối bằng cách sử dụng mempool cục bộ của riêng họ.
Sei đặt tên cho hai tối ưu hóa này là "Đồng thuận Twin-Turbo" và cho biết thông qua việc triển khai hai tối ưu hóa này (tối ưu hóa sản xuất khối và phát sóng khối thông minh), thông lượng đã tăng 83%.
Tối ưu hóa thứ ba cho quy trình sản xuất khối xoay quanh việc thực hiện giao dịch. Việc xử lý giao dịch trên Chuỗi Cosmos sử dụng ABCI được thực hiện tuần tự. Trong quy trình này, các giao dịch được xử lý từng giao dịch một bất kể chúng ở thị trường nào, điều này cản trở rất nhiều đến thông lượng. Và khi tải tăng thì độ trễ cũng sẽ tăng theo cấp số nhân. Bằng cách sử dụng xử lý song song, các thị trường độc lập không chồng chéo có thể được xử lý đồng thời. Thay vì xử lý giao dịch đầu tiên ở Thị trường B sau giao dịch ở Thị trường A, tốt hơn là xử lý chúng đồng thời. Các giao dịch trong một thị trường cụ thể vẫn cần được xử lý để tránh tính không xác định, xảy ra khi hai trình xác thực khác nhau nhận được kết quả khác nhau cho cùng một trạng thái (ví dụ: một trình xác thực xử lý trước lệnh của người dùng B Người dùng A, nhưng một trình xác thực khác xử lý lệnh của Người dùng B trước A, khiến giá quyết toán của người dùng xung đột).
Sei đã thực hiện một số thử nghiệm tải xung quanh việc song song hóa (đồng thời lưu trữ các trình xác thực) để xem những cải tiến nào có thể được thực hiện về thời gian khối, độ trễ và thông lượng. Nói chung, thông qua thực thi song song, thời gian khối có thể giảm 75-90% so với xử lý tuần tự, với độ trễ song song là 40-120 mili giây và độ trễ tuần tự là 200-1370 mili giây. Với 10.000 lệnh/khối và 20 hợp đồng (thị trường) khác nhau, tính song song có thể giảm thời gian tạo khối từ 1,33 giây xuống 0,81 giây, độ trễ từ 371 mili giây xuống 48 mili giây và thông lượng từ 7500 lệnh/giây xuống 12.200 lệnh/giây. Những cải tiến đáng kể được thấy ở tất cả các cấp độ tải (đơn hàng/khối), với mức tối ưu hóa cận biên lớn hơn khi khối lượng tải tăng lên.
Ngoài 3 cải tiến lớn nêu trên, Sei còn bổ sung thêm các tính năng khác cho lớp cơ sở, chẳng hạn như:
Oracle về giá gốc . Oracle được tích hợp vào lớp cơ sở; người xác nhận cần phải thống nhất về giá khi sản xuất một khối. Các khối không được tạo cho đến khi người xác thực đồng ý về giá. Cho phép mô-đun khác có được thông tin giá đáng tin cậy từ thị trường trên Chuỗi.
Thực hiện lệnh khối đơn . Cho phép đặt lệnh trong một khối duy nhất (yêu cầu nhiều khối trong Serum).
Gói đơn hàng . Nhà tạo lập thị trường có thể cập nhật giá ở nhiều thị trường trong một giao dịch.
Đấu giá lô thường xuyên . Lệnh thị trường có thể được tổng hợp ở cuối khối để thanh lý ở một mức giá duy nhất; mục đích là cố gắng giảm thiểu việc chạy trước.
Ngoài những cải tiến về phần mềm, Sei cũng đang thử nghiệm các cấu trúc xác thực nhỏ hơn và yêu cầu phần cứng cao hơn. Mặc dù có sự đánh đổi trong phi tập trung, nhưng những điều này đi kèm với những cải tiến hiệu suất đáng kể và một lần nữa nêu bật điều khiến Cosmos trở nên độc đáo: khả năng tùy chỉnh.
Sử dụng trình xác nhận cấu hình phần cứng hiệu suất cao
Trong phiên bản đầu tiên của tài liệu dự án Sei , các thông số kỹ thuật được đề xuất tương tự như Chuỗi Cosmos tiêu chuẩn. Sau đó, các yêu cầu về phần cứng đã tăng lên và trong một số thử nghiệm tải nhất định, các yêu cầu còn tăng hơn nữa. Mô hình sổ lệnh có yêu cầu phần cứng cao, máy có hiệu suất thấp sẽ làm giảm hiệu suất chung của mạng. Mặc dù không phải là yêu cầu ở cấp độ Solana nhưng Sei đã nói rõ rằng họ muốn trình xác thực của họ hoạt động tốt hơn blockchain thông thường. Ngoài ra, họ đang thúc đẩy việc tập trung hóa các khu vực địa lý của người xác thực để giảm độ trễ hơn nữa.
Tại sao Colocation? Nếu những người xác nhận bị phân tán về mặt địa lý, thông tin sẽ mất nhiều thời gian hơn để truyền tải, dẫn đến độ trễ cao hơn trong việc đạt được sự đồng thuận và tạo khối. Nền tảng giao dịch sổ lệnh cần giảm độ trễ càng nhiều càng tốt. Sei đã một lần nữa công bố một số kết quả thử nghiệm của họ xung quanh việc colocation:
1. So với sự phân tán về mặt địa lý, việc colocation có thể giảm độ trễ khoảng 46%.
2. 50 trình xác nhận là giới hạn độ trễ có thể chấp nhận được.
Rõ ràng có sự đánh đổi khi có tất cả các trình xác nhận trong cùng một khu vực địa lý, nhưng khó có thể bỏ qua việc cải thiện hiệu suất. Khi Sei ra mắt mainnet , họ có thể sẽ chuyển sang tập hợp các trình xác thực nhỏ hơn, tập trung này. Trong biểu đồ bên dưới, p50/p75/p95 đề cập đến xác suất x% yêu cầu sẽ nhanh hơn một giá trị cụ thể. Ví dụ: p50 có nghĩa là 50% yêu cầu sẽ nhanh hơn giá trị p50 cho thử nghiệm đó. Vì vậy p95 có nghĩa là 95% yêu cầu sẽ nhanh hơn giá trị p95.
Tóm tắt
Báo cáo của Delphi Digital cũng bao gồm các nội dung về hệ sinh thái, token, v.v. Bài viết này sẽ tạm thời bỏ qua chúng và chỉ trình bày những đổi mới về công nghệ và cơ chế của Sei Network. Điều có thể thấy là Sei đã có những đổi mới trong xử lý song song và phát sóng khối để cải thiện tốc độ xác nhận giao dịch mạng nhưng mặt khác, Sei yêu cầu các trình xác thực có cấu hình phần cứng hiệu suất cao và vị trí địa lý của các trình xác nhận này tương đối tập trung. Để đáp ứng hơn nữa sự hỗ trợ của mình đối với nền tảng giao dịch mô hình sổ lệnh , Delphi cũng thừa nhận vấn đề tập trung của giải pháp trong báo cáo, nhưng nói rằng không thể bỏ qua việc cải thiện hiệu suất của nó.
Tác giả cho rằng , như đã đề cập trong bài viết, Chuỗi ứng dụng sinh thái Cosmos có khả năng tùy biến cực kỳ cao và Web3 phải đủ bao gồm hệ tư tưởng về cách trình bày blockchain. Chúng tôi có thể hỗ trợ các dự án có mức độ phi tập trung cao. hy sinh một số phi tập trung để có hiệu quả cũng có thể được chấp nhận. Tuy nhiên, liệu Sei Network có thể “nhanh” như người ta nói hay không, chúng ta vẫn cần sử dụng dữ liệu thực tế để đưa ra câu trả lời sau khi mainnet ra mắt.
