Cơ chế lãnh đạo đồng thời của người đồng sáng lập Solana: Giải quyết MEV và xây dựng động cơ phát hiện giá toàn cầu
Tuyển chọn TechFlowTuyển chọn TechFlow
Cơ chế lãnh đạo đồng thời của người đồng sáng lập Solana: Giải quyết MEV và xây dựng động cơ phát hiện giá toàn cầu
Tầm nhìn lớn hơn của Solana là xây dựng một động cơ khám phá giá toàn cầu không cần sự cho phép, có khả năng cạnh tranh với hiệu suất tốt nhất của bất kỳ sàn giao dịch tập trung (CEX) nào.
Chuyên sâu báo cáo Web3Tác giả:Anatoly Yakovenko
Biên dịch: TechFlow
Tổng quan
MEV là một vấn đề cơ bản trong các blockchain không cần cho phép. Cũng giống như hầu hết các blockchain không cần cho phép khác, Solana hướng tới mục tiêu giảm thiểu MEV mà các nhà vận hành chuỗi thu thập từ người dùng.
Phương pháp của Solana là giảm MEV bằng cách tối đa hóa sự cạnh tranh giữa các nhà lãnh đạo (tức là những người sản xuất khối). Điều này có nghĩa là rút ngắn thời gian khe (slot), giảm số lượng khe liên tiếp do một nhà lãnh đạo duy nhất sắp xếp, và tăng số lượng nhà lãnh đạo đồng thời trên mỗi khe.
Nói chung, càng nhiều nhà lãnh đạo mỗi giây thì người dùng sẽ có thêm lựa chọn sau T giây chờ đợi để chọn ra mức giá tốt nhất từ các nhà lãnh đạo sắp tới. Nhiều nhà lãnh đạo hơn cũng đồng nghĩa với việc chi phí dành cho không gian khối do các nhà lãnh đạo tốt cung cấp thấp hơn, giúp người dùng dễ dàng chỉ thực hiện giao dịch với các nhà lãnh đạo tốt và loại trừ giao dịch của những nhà lãnh đạo xấu. Thị trường nên quyết định cái nào là tốt, cái nào là xấu.
Tầm nhìn lớn hơn của Solana là xây dựng một động cơ phát hiện giá toàn cầu không cần cho phép, có khả năng cạnh tranh với hiệu suất tốt nhất của bất kỳ sàn giao dịch tập trung (CEX) nào.
Nếu một sự kiện ảnh hưởng đến thị trường xảy ra tại Singapore, thông tin vẫn cần được truyền qua cáp quang với tốc độ ánh sáng tới CEX ở New York. Trước khi tin tức đến New York, các nhà lãnh đạo trong mạng Solana đã phải phát tán tin tức này vào khối. Trừ khi đồng thời xảy ra phân vùng vật lý Internet, nếu không thì khi tin tức đến New York, trạng thái của Solana đã phản ánh nội dung đó rồi. Do đó, sẽ không tồn tại cơ hội chênh lệch giá giữa CEX tại New York và Solana.
Để đạt được mục tiêu này một cách toàn diện, Solana cần rất nhiều nhà lãnh đạo hoạt động song song và đảm bảo xác nhận cực kỳ lạc quan.
Cấu hình nhiều nhà lãnh đạo
Giống như lịch trình nhà lãnh đạo hiện tại, hệ thống sẽ cấu hình mỗi khe thành 2 nhà lãnh đạo thay vì 1 nhà lãnh đạo. Để phân biệt hai nhà lãnh đạo này, một kênh được đánh dấu là A và một kênh là B. A và B có thể luân chuyển độc lập. Việc triển khai kế hoạch này cần trả lời các câu hỏi sau:
-
Nếu khối A và B đến vào các thời điểm khác nhau hoặc thất bại thì sao?
-
Làm thế nào để hợp nhất thứ tự giao dịch trong khối A và B?
-
Làm cách nào để phân bổ dung lượng khối giữa A và B?
Truyền tải khối song song
Để hiểu quy trình cụ thể, chúng ta cần nhanh chóng tìm hiểu về Turbine.
Khi nhà lãnh đạo xây dựng khối, họ chia khối thành các mảnh nhỏ. Một lô gồm 32 mảnh nhỏ là mã xóa lỗi (erasure code) gồm 32 mảnh dữ liệu. Một lô 64 mảnh nhỏ được đưa vào Merkle và ký gốc, những cái này được liên kết với lô trước đó.
Mỗi mảnh nhỏ được gửi đi theo một đường dẫn ngẫu nhiên xác định riêng biệt. Mỗi người lặp lại (retransmitter) của lô cuối cùng đều ký gốc.
Từ góc nhìn của người nhận, mỗi người nhận cần nhận được 32 mảnh nhỏ từ các bộ lặp lại đã được xác minh. Các mảnh bị thiếu sẽ được sửa chữa ngẫu nhiên.
Con số này có thể tăng hoặc giảm, ảnh hưởng rất nhỏ đến độ trễ.
Giả sử rằng đường dẫn mẫu mảnh nhỏ của bộ lặp lại đủ ngẫu nhiên và được trọng số theo cổ phần, thì cổ phần cần thiết để phân vùng mạng phối hợp sẽ vượt xa ε cổ phần, cả về thời gian đến lẫn dữ liệu. Nếu người nhận phát hiện 32/64 mảnh (có thể cấu hình) của mỗi lô đến trong khoảng thời gian T, thì khả năng cao là mọi nút khác cũng vậy. Bởi vì 32 nút ngẫu nhiên là đủ lớn để khó có thể tình cờ rơi vào cùng một phân vùng.
Nếu xảy ra phân vùng, cơ chế đồng thuận cần giải quyết nó. Điều này không ảnh hưởng đến bảo mật, nhưng tốc độ tương đối chậm.
Sản xuất nhiều khối
Nếu truyền một khối đơn, mỗi người nhận (bao gồm cả nhà lãnh đạo tiếp theo) sẽ thấy từng lô mảnh nhỏ của khối đến. Nếu khối không đầy đủ trong vòng T mili giây, nhà lãnh đạo hiện tại sẽ bỏ qua khối đó và xây dựng một phân nhánh không có nó. Nếu nhà lãnh đạo sai, tất cả các nút khác sẽ bỏ phiếu cho khối, và khối của nhà lãnh đạo sẽ bị bỏ qua. Nhà lãnh đạo không gặp lỗi sẽ lập tức chuyển sang phân nhánh nặng nhất do phiếu bầu chỉ định.
Trong trường hợp truyền nhiều khối, mỗi nút sẽ cần chờ tối đa T mili giây, sau đó bỏ phiếu cho phân vùng khối đã quan sát được. Với hai nhà lãnh đạo đồng thời, các trường hợp có thể xảy ra là: A, B hoặc A và B. Chỉ khi khối bị trễ mới làm tăng thêm độ trễ. Trong hoạt động bình thường, tất cả các khối nên đến cùng lúc, mỗi bộ xác thực có thể bỏ phiếu ngay sau khi cả hai khối đều đến. Do đó, T trong thực tế có thể gần bằng không.
Cuộc tấn công cần đặc biệt phòng thủ là: liệu một nhà lãnh đạo đặt cược lượng token cực nhỏ có thể truyền khối muộn hơn một chút ở ranh giới khe để đáng tin cậy gây ra sự chia rẽ mạng, buộc mạng mất nhiều thời gian để giải quyết thông qua cơ chế đồng thuận hay không. Một phần mạng sẽ bỏ phiếu cho A, một phần cho B, và một phần cho cả A và B. Ba trường hợp phân chia này đều cần được giải quyết thông qua cơ chế đồng thuận.
Cụ thể, mục tiêu vùng lân cận bằng không nên là đảm bảo các nút phục hồi khối đồng thời. Nếu kẻ tấn công có một nút phối hợp trong vùng lân cận bằng không, chúng có thể truyền bình thường 31/64 mảnh, và để kẻ tấn công truyền chọn lọc mảnh cuối cùng nhằm cố gắng tạo phân vùng. Các nút trung thực có thể phát hiện những bộ lặp lại nào bị trễ và ngay lập tức đẩy mảnh bị thiếu đến họ ngay sau khi một nút trung thực bất kỳ phục hồi khối. Bộ lặp lại có thể tiếp tục, nếu họ nhận được mảnh hoặc phục hồi nó từ bất cứ đâu. Do đó, khối nên được tất cả các nút phục hồi trong thời gian ngắn sau khi một nút trung thực phục hồi. Cần thử nghiệm để xác định thời gian chờ, liệu nó là tuyệt đối hay được tính trọng số theo thời gian đến của từng mảnh, có nên sử dụng uy tín nút cổ phần hay không.
Xác suất có nhà lãnh đạo và bộ lặp lại phối hợp trong mỗi khối khoảng P * cổ phần nhà lãnh đạo * (64P * cổ phần bộ lặp lại). 1% cổ phần có thể thử tấn công trong ½ lô mảnh do nhà lãnh đạo là kẻ tấn công sắp xếp. Do đó, việc phát hiện và giảm thiểu cần đủ mạnh.
Loại tấn công này ảnh hưởng rất ít đến nhà lãnh đạo tiếp theo, vì thực thi bất đồng bộ cho phép dung lượng chưa dùng được dồn lại. Do đó, nếu nhà lãnh đạo hiện tại buộc nhà lãnh đạo tiếp theo bỏ qua một khe, mà nhà lãnh đạo tiếp theo có 4 khe liên tiếp, dung lượng chưa dùng của khe bị bỏ có thể được dồn lại, cho phép nhà lãnh đạo tái bao gồm các giao dịch của khe bị bỏ.
Hợp nhất các khối đồng thời
Nếu người dùng gửi cùng một giao dịch đồng thời đến cả nhà lãnh đạo A và B nhằm tăng cơ hội được bao gồm hoặc đứng đầu khối, điều này sẽ gây lãng phí tài nguyên. Nếu xảy ra tình huống này, việc tăng số lượng nhà lãnh đạo đồng thời sẽ mang lại hiệu quả nâng cao hiệu suất rất hạn chế, bởi vì họ chỉ đang xử lý gấp đôi số giao dịch rác.
Để tránh giao dịch trùng lặp, N bit đầu tiên của người trả phí sẽ quyết định giao dịch hợp lệ ở kênh nhà lãnh đạo nào. Trong ví dụ này, bit cao nhất sẽ chọn A hoặc B. Người trả phí phải được phân bổ vào một kênh độc quyền, để nhà lãnh đạo có thể xác định người trả phí là hợp lệ và chưa tiêu hết lamports (đơn vị tiền tệ nhỏ nhất trên blockchain Solana) ở nhà lãnh đạo khác.
Việc này sẽ buộc kẻ gửi thư rác phải trả phí ít nhất hai lần cho các giao dịch về mặt logic giống nhau, tuy nhiên để tăng xác suất trở thành giao dịch đầu tiên, kẻ gửi thư rác vẫn có thể gửi các giao dịch giống nhau về mặt logic.
Để ngăn chặn hành vi này, người dùng có thể chọn thêm một khoản phí đơn hàng bị phá hủy hoàn toàn 100%, ngoài phí ưu tiên cho nhà lãnh đạo. Giao dịch có phí đơn hàng cao nhất sẽ được thực hiện trước. Nếu không, sẽ dùng cách sắp xếp FIFO (vào trước ra trước). Trong trường hợp hòa, dùng hoán vị ngẫu nhiên xác định để giải quyết thứ tự. Do đó, đối với kẻ gửi thư rác, tăng phí đơn hàng và thực hiện trước sẽ tiết kiệm chi phí hơn so với việc trả hai lần phí bao gồm.
Để xử lý các gói và dãy giao dịch được sắp xếp lại, hệ thống cần hỗ trợ giao dịch nhóm, có thể thêm một phí đơn hàng để bao phủ toàn bộ chi phí sắp xếp dãy giao dịch. Người trả phí chỉ hợp lệ trong kênh được chỉ định, do đó việc nhóm chỉ có thể thao tác dãy trong chính kênh của nó.
Hoặc, phí đơn hàng có thể không cần thiết. Nếu dùng sắp xếp FIFO và kẻ gửi thư rác luôn bị tính phí ưu tiên trên mọi kênh, có thể chỉ cần cho phép thị trường quyết định chi phí trả cho N nhà lãnh đạo để tăng cơ hội được bao gồm so với chi phí trả cho nhà lãnh đạo gần đây nhất có khả năng cao nhất bao gồm giao dịch đầu tiên.
Quản lý tài nguyên khối
Trong mạng blockchain, khi có hai nhà lãnh đạo đồng thời, mỗi giới hạn dung lượng khối trên toàn hệ thống cần được phân bổ đều. Cụ thể, không chỉ tổng dung lượng, mà còn cả mỗi giới hạn cụ thể, ví dụ như giới hạn khóa ghi – không tài khoản nào được ghi quá 6 triệu đơn vị tính toán (CUs), và mỗi nhà lãnh đạo chỉ được sắp xếp tối đa 24 triệu CUs giao dịch. Như vậy, ngay cả trong trường hợp xấu nhất, khối hợp nhất cũng sẽ không vượt quá giới hạn dung lượng tổng thể của hệ thống.
Cơ chế này có thể dẫn đến dao động phí và sử dụng tài nguyên chưa hiệu quả, vì phí ưu tiên lập lịch sẽ do dung lượng của từng nhà lãnh đạo quyết định, trong khi mỗi nhà lãnh đạo biết rất ít về trạng thái lập lịch của các nhà lãnh đạo đồng thời khác.
Để giảm nhẹ việc sử dụng tài nguyên chưa đầy đủ và tình trạng phí tăng vọt do đó, bất kỳ dung lượng khối chưa dùng nào nên được dồn sang các khối tương lai. Nghĩa là, nếu khối hợp nhất hiện tại sử dụng ít hơn X về khóa ghi, tổng byte hoặc tổng đơn vị tính toán (CUs), thì nên thêm K*X vào khối tiếp theo, với 0 < K < 1, cho đến một giá trị tối đa nào đó. Thực thi bất đồng bộ có thể chậm hơn đỉnh chuỗi tới một epoch, do đó việc dồn dung lượng có thể khá mạnh tay.
Theo dữ liệu khối gần đây, hầu hết các khối thường được điền khoảng 80%, trong khi giới hạn khóa ghi thấp hơn xa 50%. Nhìn chung, các khối tương lai luôn nên có một lượng dự trữ dung lượng nhất định. Vì khối có thể tạm thời vượt quá giới hạn dung lượng, thực thi phải diễn ra bất đồng bộ với quá trình đồng thuận. Để biết chi tiết về đề xuất thực thi bất đồng bộ, hãy tham khảo bài viết APE.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
