Solana đã đủ nhanh, khối lượng đủ lớn. Vậy thì thực sự "đủ" rồi sao?
Khi chúng ta xem xét những giao dịch đó, có một câu hỏi luôn tồn tại: Những giao dịch này có thực sự tạo ra giá trị không?
Khối lượng giao dịch của Solana không đến từ nhu cầu giao dịch thực sự, mà là từ các nhà đầu tư chênh lệch giá cao tần lợi dụng sự chênh lệch thông tin trong mili giây để kiếm lợi nhuận. Những "nhà giao dịch độc hại" (Toxic-takers) này lợi dụng lợi thế kỹ thuật, khi các nhà tạo lập thị trường (Maker) sắp rút đơn hàng, họ tăng Gas để giao dịch của mình được đóng gói trước, hoàn thành việc chênh lệch giá, khiến các nhà tạo lập thị trường phải chịu thiệt hại. Để bù đắp thiệt hại, các nhà tạo lập thị trường chỉ có thể mở rộng chênh lệch giá mua bán.
Cuối cùng, người dùng bình thường phải trả giá cho điều này. Solana luôn có một giấc mơ thực hiện sổ lệnh trên chuỗi, thay thế CEX. Nhưng như vậy, "nhà giao dịch độc hại" trở thành rào cản để thực hiện giấc mơ. Đây là thách thức mới mà Solana phải đối mặt: khối lượng ≠ thanh khoản. Một thị trường thực sự khỏe mạnh không cần nhiều giao dịch hơn, mà cần giao dịch tốt hơn.
Làm thế nào để loại bỏ giao dịch độc hại, bảo vệ tính thanh khoản tốt hơn?
Trong hệ thống hiện tại, người ăn đơn (Takers) được hưởng quyền ưu tiên thực tế do cơ chế đấu giá chu kỳ đồng thuận Solana, khiến cho MEV ác ý ảnh hưởng đến tính công bằng của thị trường.
Làm thế nào để hiểu?
Trong sự đồng thuận hiện tại của Solana, trong mỗi khoảng thời gian Slot, các giao dịch được sắp xếp theo phí Gas ưu tiên đã trả, ai trả giá cao hơn thì giao dịch của họ sẽ được thực hiện trước. Cuộc đấu giá này là định kỳ, mỗi 400 mili giây một Slot.
Trong quá trình này, các nhà tạo lập thị trường cần thường xuyên điều chỉnh báo giá, hủy đơn hàng và đặt lại đơn hàng. Khi giá thị trường thay đổi, cần cập nhật ngay lập tức.
Còn người ăn đơn (Taker), đặc biệt là những người đầu cơ chênh lệch tần suất cao, thì theo dõi sự chênh lệch giá cả, phát hiện cơ hội là ngay lập tức thực hiện giao dịch. Do đó, những người đầu cơ chênh lệch có thể thông qua việc trả phí cao hơn để thực hiện giao dịch trước khi bị rút đơn. Điều này dẫn đến việc các nhà tạo lập thị trường thường bị "săn lùng", chịu thiệt hại.
Đối với sổ lệnh DEX, thứ tự lý tưởng nên là, khi giá biến động, đầu tiên thực hiện tất cả các lệnh hủy, sau đó thực hiện các lệnh mới, cuối cùng thực hiện giao dịch. Đây là điều hiện tại mà sự đồng thuận của Solana không thể làm được ở cấp độ vi mô.
Và trên phương diện báo giá của oracle cũng vậy, tình huống lý tưởng là cập nhật giá của oracle trước, sau đó thực hiện các giao dịch phụ thuộc vào giá đó. Nhưng trong khoảng thời gian 400 mili giây hiện tại, thị trường có thể dao động mạnh, dẫn đến việc giao dịch vẫn được thực hiện theo giá ban đầu.
Đối với giao thức cho vay, tốt nhất là bổ sung ký quỹ trước, sau đó tiến hành thanh lý.
Vì vậy, tốt nhất là có một cách để các giao thức khác nhau sắp xếp giao dịch theo nhu cầu, đó là điều mà Solana luôn nhấn mạnh về việc thực hiện điều khiển ứng dụng (Application-Controlled Execution) ACE.
BAM (Block Assembly Marketplace, thị trường lắp ráp khối) chính là câu trả lời của Solana.
BAM đã xây dựng một lớp sắp xếp, hay còn gọi là lớp tiền xử lý, giữa ứng dụng trên chuỗi Solana và mạng chính.
Sử dụng Môi trường Thực thi Đáng tin cậy (Trusted Execution Environments, TEEs) để xây dựng hộp cát riêng tư, trong hộp cát tiến hành sắp xếp giao dịch theo các quy tắc sắp xếp đã được xác định trước, hoặc FIFO (trước vào trước ra).
Cung cấp dịch vụ tốt hơn cho sổ lệnh (CLOBs), sàn giao dịch hợp đồng vĩnh viễn (Perpetual Exchanges), và giao thức hồ tối (Dark Pools).
Solana thường gói giao dịch so với chế độ BAM
Làm thế nào để hiểu BAM đã xây dựng một lớp sắp xếp giữa các ứng dụng Solana và mạng chính? Hãy bắt đầu với một so sánh trực quan.
Quy trình giao dịch Solana bình thường,
1）Người dùng xác nhận giao dịch trong ví,
2）Gửi giao dịch đến nút RPC,
3）RPC gửi đến nút Leader của mạng chính Solana trong thời gian Slot hiện tại,
4）Leader thu thập các giao dịch trong pool giao dịch, sắp xếp, đóng gói thành khối và phát sóng,
5）Các nút còn lại bỏ phiếu.
Nếu một ứng dụng kết nối với BAM, quy trình giao dịch như sau,
1）Người dùng xác nhận giao dịch trong ví,
2）Gửi giao dịch đến nút RPC,
3）Chuyển giao dịch sang mạng BAM, sắp xếp trong quyền riêng tư TEE. Trong quá trình này, các nút có thể thêm giao dịch bổ sung thông qua các plugin, chẳng hạn như cập nhật giá oracle, sau đó tạo ra chứng minh,
4）Gói dữ liệu giao dịch được gửi đến nút Leader của mạng chính Solana,
5）Leader thu thập giao dịch, thu thập gói dữ liệu BAM, sau đó đóng gói thành khối và phát sóng,
6）Các nút còn lại bỏ phiếu.
Vì vậy, thực ra BAM không mâu thuẫn với quá trình đồng thuận của mạng chính Solana hiện tại, mà là một "tùy chọn". BAM không chạy trực tiếp trên mạng chính Solana, mà theo cách gọi là "ngoài chuỗi", hoàn thành việc sắp xếp giao dịch trước, đóng gói giao dịch, rồi gửi đến mạng chính Solana.
BAM khối lượng giao dịch
BAM hỗ trợ ba chế độ vận hành,
1）Chế độ mặc định Solana；
2）Chế độ Block-Engine; Giải pháp MEV hiện tại của Jito, cốt lõi là cơ chế đấu giá.
3）Chế độ BAM, người xác thực tuân theo thứ tự FIFO (đến trước, phục vụ trước).
Cốt lõi của chế độ BAM có những điểm sau:
1）Môi trường thực thi đáng tin cậy TEEs: Bảo mật và Công bằng Sử dụng môi trường thực thi đáng tin cậy TEEs, xây dựng môi trường bảo mật, sắp xếp các giao dịch. Mặt khác của bảo mật gọi là công bằng.
2）Hệ thống plugin Plugin：Sắp xếp phức tạp Thông qua hệ thống plugin, BAM cho phép ứng dụng xây dựng logic sắp xếp giao dịch tùy chỉnh. Và sắp xếp tùy chỉnh này không phải là các nút muốn sắp xếp như thế nào thì sắp xếp, mà là sắp xếp theo các quy tắc đã được thiết lập trước.
Kế hoạch plugin thực hiện sắp xếp giao dịch phức tạp, đồng thời duy trì các đảm bảo an toàn của môi trường TEE. Hiện đang ở giai đoạn phát triển sớm.
Như đã đề cập trước đó,
Đối với sổ lệnh DEX, thứ tự lý tưởng nên là, với sự biến động giá, trước tiên thực hiện tất cả các lệnh hủy, sau đó thực hiện các lệnh mới, và cuối cùng thực hiện các giao dịch. Đây là điều mà đồng thuận của Solana hiện tại không thể đạt được ở cấp độ vi mô.
Và ở mức báo giá của oracle cũng tương tự, tình huống lý tưởng là cập nhật giá oracle trước, sau đó thực hiện giao dịch phụ thuộc vào giá đó. Nhưng trong khoảng thời gian 400 mili giây hiện tại, thị trường có thể biến động mạnh, dẫn đến việc giao dịch vẫn được thực hiện theo giá ban đầu.
Đối với giao thức cho vay, tốt nhất là nên bổ sung ký quỹ trước, sau đó mới thực hiện thanh lý. Điều này thực sự thực hiện chức năng kiểm soát thực thi ứng dụng ACE.
Vậy, BAM thực sự đã đạt được điều gì?
Ví dụ như,
1）Bảo vệ thanh lý cho vay
Đối với các giao thức cho vay, sau khi phát hiện rủi ro thanh lý, ưu tiên thực hiện các thao tác bổ sung tài sản thế chấp, sau đó tiến hành kiểm tra thanh lý.
2）组合 giao dịch mức nguyên tử
Đối với DEX, trước tiên cập nhật giá oracle, thực hiện giao dịch phụ thuộc vào giá đó. Nếu là DEX hợp đồng, thì còn có thể thanh toán các sản phẩm phái sinh liên quan. Tất cả các thao tác trên đều được hoàn thành trong cùng một khoảng thời gian.
3）Bảo vệ biến động giá
Đối với DEX, phát hiện các lệnh lớn bất thường, chia lệnh lớn thành các khối nhỏ, thực hiện theo từng đợt, cho thị trường thời gian phản ứng, tránh tình trạng thanh lý liên tiếp hoặc chênh lệch giá gây ra vòng xoáy tử thần.
4）Bảo vệ nhà tạo lập thị trường
Sự cố bất ngờ xảy ra, hủy đơn trong vòng mili giây, oracle cập nhật giá, nhà tạo lập thị trường treo lại đơn hàng. Tránh bị chênh lệch giá xấu, giảm thiểu chênh lệch giá.
BAM ban đầu sẽ được ra mắt vào cuối tháng 7.
Và, với việc triển khai BAM, trải nghiệm giao dịch Solana sẽ được cải thiện đáng kể. BAM sẽ làm cho trải nghiệm ứng dụng trên mạng chính Solana gần hơn với CEX.
Tóm lại,
BAM đã mang lại khả năng xác minh, bảo vệ quyền riêng tư và tính linh hoạt cho quy trình xử lý giao dịch của Solana, cho phép các nhà phát triển xây dựng sổ đặt hàng giới hạn trung tâm (CLOBs), sàn giao dịch hợp đồng vĩnh viễn (Perpetual Exchanges), bể tối (Dark Pools) và các cơ sở hạ tầng tài chính khác cần kiểm soát thứ tự, thực thi chắc chắn và bảo vệ quyền riêng tư, từ đó thúc đẩy sự phát triển đổi mới của hệ sinh thái Solana.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Giải thích thị trường lắp ráp khối Solana BAM: Khi tốc độ không còn là mục tiêu duy nhất
Solana đã đủ nhanh, khối lượng đủ lớn. Vậy thì thực sự "đủ" rồi sao?
Khi chúng ta xem xét những giao dịch đó, có một câu hỏi luôn tồn tại: Những giao dịch này có thực sự tạo ra giá trị không?
Khối lượng giao dịch của Solana không đến từ nhu cầu giao dịch thực sự, mà là từ các nhà đầu tư chênh lệch giá cao tần lợi dụng sự chênh lệch thông tin trong mili giây để kiếm lợi nhuận. Những "nhà giao dịch độc hại" (Toxic-takers) này lợi dụng lợi thế kỹ thuật, khi các nhà tạo lập thị trường (Maker) sắp rút đơn hàng, họ tăng Gas để giao dịch của mình được đóng gói trước, hoàn thành việc chênh lệch giá, khiến các nhà tạo lập thị trường phải chịu thiệt hại. Để bù đắp thiệt hại, các nhà tạo lập thị trường chỉ có thể mở rộng chênh lệch giá mua bán.
Cuối cùng, người dùng bình thường phải trả giá cho điều này. Solana luôn có một giấc mơ thực hiện sổ lệnh trên chuỗi, thay thế CEX. Nhưng như vậy, "nhà giao dịch độc hại" trở thành rào cản để thực hiện giấc mơ. Đây là thách thức mới mà Solana phải đối mặt: khối lượng ≠ thanh khoản. Một thị trường thực sự khỏe mạnh không cần nhiều giao dịch hơn, mà cần giao dịch tốt hơn.
Làm thế nào để loại bỏ giao dịch độc hại, bảo vệ tính thanh khoản tốt hơn?
Trong hệ thống hiện tại, người ăn đơn (Takers) được hưởng quyền ưu tiên thực tế do cơ chế đấu giá chu kỳ đồng thuận Solana, khiến cho MEV ác ý ảnh hưởng đến tính công bằng của thị trường.
Làm thế nào để hiểu?
Trong sự đồng thuận hiện tại của Solana, trong mỗi khoảng thời gian Slot, các giao dịch được sắp xếp theo phí Gas ưu tiên đã trả, ai trả giá cao hơn thì giao dịch của họ sẽ được thực hiện trước. Cuộc đấu giá này là định kỳ, mỗi 400 mili giây một Slot.
Trong quá trình này, các nhà tạo lập thị trường cần thường xuyên điều chỉnh báo giá, hủy đơn hàng và đặt lại đơn hàng. Khi giá thị trường thay đổi, cần cập nhật ngay lập tức.
Còn người ăn đơn (Taker), đặc biệt là những người đầu cơ chênh lệch tần suất cao, thì theo dõi sự chênh lệch giá cả, phát hiện cơ hội là ngay lập tức thực hiện giao dịch. Do đó, những người đầu cơ chênh lệch có thể thông qua việc trả phí cao hơn để thực hiện giao dịch trước khi bị rút đơn. Điều này dẫn đến việc các nhà tạo lập thị trường thường bị "săn lùng", chịu thiệt hại.
Đối với sổ lệnh DEX, thứ tự lý tưởng nên là, khi giá biến động, đầu tiên thực hiện tất cả các lệnh hủy, sau đó thực hiện các lệnh mới, cuối cùng thực hiện giao dịch. Đây là điều hiện tại mà sự đồng thuận của Solana không thể làm được ở cấp độ vi mô.
Và trên phương diện báo giá của oracle cũng vậy, tình huống lý tưởng là cập nhật giá của oracle trước, sau đó thực hiện các giao dịch phụ thuộc vào giá đó. Nhưng trong khoảng thời gian 400 mili giây hiện tại, thị trường có thể dao động mạnh, dẫn đến việc giao dịch vẫn được thực hiện theo giá ban đầu.
Đối với giao thức cho vay, tốt nhất là bổ sung ký quỹ trước, sau đó tiến hành thanh lý.
Vì vậy, tốt nhất là có một cách để các giao thức khác nhau sắp xếp giao dịch theo nhu cầu, đó là điều mà Solana luôn nhấn mạnh về việc thực hiện điều khiển ứng dụng (Application-Controlled Execution) ACE.
BAM (Block Assembly Marketplace, thị trường lắp ráp khối) chính là câu trả lời của Solana.
BAM đã xây dựng một lớp sắp xếp, hay còn gọi là lớp tiền xử lý, giữa ứng dụng trên chuỗi Solana và mạng chính.
Sử dụng Môi trường Thực thi Đáng tin cậy (Trusted Execution Environments, TEEs) để xây dựng hộp cát riêng tư, trong hộp cát tiến hành sắp xếp giao dịch theo các quy tắc sắp xếp đã được xác định trước, hoặc FIFO (trước vào trước ra).
Cung cấp dịch vụ tốt hơn cho sổ lệnh (CLOBs), sàn giao dịch hợp đồng vĩnh viễn (Perpetual Exchanges), và giao thức hồ tối (Dark Pools).
Solana thường gói giao dịch so với chế độ BAM
Làm thế nào để hiểu BAM đã xây dựng một lớp sắp xếp giữa các ứng dụng Solana và mạng chính? Hãy bắt đầu với một so sánh trực quan.
Quy trình giao dịch Solana bình thường,
1）Người dùng xác nhận giao dịch trong ví,
2）Gửi giao dịch đến nút RPC,
3）RPC gửi đến nút Leader của mạng chính Solana trong thời gian Slot hiện tại,
4）Leader thu thập các giao dịch trong pool giao dịch, sắp xếp, đóng gói thành khối và phát sóng,
5）Các nút còn lại bỏ phiếu.
Nếu một ứng dụng kết nối với BAM, quy trình giao dịch như sau,
1）Người dùng xác nhận giao dịch trong ví,
2）Gửi giao dịch đến nút RPC,
3）Chuyển giao dịch sang mạng BAM, sắp xếp trong quyền riêng tư TEE. Trong quá trình này, các nút có thể thêm giao dịch bổ sung thông qua các plugin, chẳng hạn như cập nhật giá oracle, sau đó tạo ra chứng minh,
4）Gói dữ liệu giao dịch được gửi đến nút Leader của mạng chính Solana,
5）Leader thu thập giao dịch, thu thập gói dữ liệu BAM, sau đó đóng gói thành khối và phát sóng,
6）Các nút còn lại bỏ phiếu.
Vì vậy, thực ra BAM không mâu thuẫn với quá trình đồng thuận của mạng chính Solana hiện tại, mà là một "tùy chọn". BAM không chạy trực tiếp trên mạng chính Solana, mà theo cách gọi là "ngoài chuỗi", hoàn thành việc sắp xếp giao dịch trước, đóng gói giao dịch, rồi gửi đến mạng chính Solana.
BAM khối lượng giao dịch
BAM hỗ trợ ba chế độ vận hành,
1）Chế độ mặc định Solana；
2）Chế độ Block-Engine; Giải pháp MEV hiện tại của Jito, cốt lõi là cơ chế đấu giá.
3）Chế độ BAM, người xác thực tuân theo thứ tự FIFO (đến trước, phục vụ trước).
Cốt lõi của chế độ BAM có những điểm sau:
1）Môi trường thực thi đáng tin cậy TEEs: Bảo mật và Công bằng Sử dụng môi trường thực thi đáng tin cậy TEEs, xây dựng môi trường bảo mật, sắp xếp các giao dịch. Mặt khác của bảo mật gọi là công bằng.
2）Hệ thống plugin Plugin：Sắp xếp phức tạp Thông qua hệ thống plugin, BAM cho phép ứng dụng xây dựng logic sắp xếp giao dịch tùy chỉnh. Và sắp xếp tùy chỉnh này không phải là các nút muốn sắp xếp như thế nào thì sắp xếp, mà là sắp xếp theo các quy tắc đã được thiết lập trước.
Kế hoạch plugin thực hiện sắp xếp giao dịch phức tạp, đồng thời duy trì các đảm bảo an toàn của môi trường TEE. Hiện đang ở giai đoạn phát triển sớm.
Như đã đề cập trước đó,
Đối với sổ lệnh DEX, thứ tự lý tưởng nên là, với sự biến động giá, trước tiên thực hiện tất cả các lệnh hủy, sau đó thực hiện các lệnh mới, và cuối cùng thực hiện các giao dịch. Đây là điều mà đồng thuận của Solana hiện tại không thể đạt được ở cấp độ vi mô.
Và ở mức báo giá của oracle cũng tương tự, tình huống lý tưởng là cập nhật giá oracle trước, sau đó thực hiện giao dịch phụ thuộc vào giá đó. Nhưng trong khoảng thời gian 400 mili giây hiện tại, thị trường có thể biến động mạnh, dẫn đến việc giao dịch vẫn được thực hiện theo giá ban đầu.
Đối với giao thức cho vay, tốt nhất là nên bổ sung ký quỹ trước, sau đó mới thực hiện thanh lý. Điều này thực sự thực hiện chức năng kiểm soát thực thi ứng dụng ACE.
Vậy, BAM thực sự đã đạt được điều gì?
Ví dụ như,
1）Bảo vệ thanh lý cho vay
Đối với các giao thức cho vay, sau khi phát hiện rủi ro thanh lý, ưu tiên thực hiện các thao tác bổ sung tài sản thế chấp, sau đó tiến hành kiểm tra thanh lý.
2）组合 giao dịch mức nguyên tử
Đối với DEX, trước tiên cập nhật giá oracle, thực hiện giao dịch phụ thuộc vào giá đó. Nếu là DEX hợp đồng, thì còn có thể thanh toán các sản phẩm phái sinh liên quan. Tất cả các thao tác trên đều được hoàn thành trong cùng một khoảng thời gian.
3）Bảo vệ biến động giá
Đối với DEX, phát hiện các lệnh lớn bất thường, chia lệnh lớn thành các khối nhỏ, thực hiện theo từng đợt, cho thị trường thời gian phản ứng, tránh tình trạng thanh lý liên tiếp hoặc chênh lệch giá gây ra vòng xoáy tử thần.
4）Bảo vệ nhà tạo lập thị trường
Sự cố bất ngờ xảy ra, hủy đơn trong vòng mili giây, oracle cập nhật giá, nhà tạo lập thị trường treo lại đơn hàng. Tránh bị chênh lệch giá xấu, giảm thiểu chênh lệch giá.
BAM ban đầu sẽ được ra mắt vào cuối tháng 7.
Và, với việc triển khai BAM, trải nghiệm giao dịch Solana sẽ được cải thiện đáng kể. BAM sẽ làm cho trải nghiệm ứng dụng trên mạng chính Solana gần hơn với CEX.
Tóm lại,
BAM đã mang lại khả năng xác minh, bảo vệ quyền riêng tư và tính linh hoạt cho quy trình xử lý giao dịch của Solana, cho phép các nhà phát triển xây dựng sổ đặt hàng giới hạn trung tâm (CLOBs), sàn giao dịch hợp đồng vĩnh viễn (Perpetual Exchanges), bể tối (Dark Pools) và các cơ sở hạ tầng tài chính khác cần kiểm soát thứ tự, thực thi chắc chắn và bảo vệ quyền riêng tư, từ đó thúc đẩy sự phát triển đổi mới của hệ sinh thái Solana.
Trên đây.