Thị trường Lắp ráp Khối (BAM)

Những điểm chính có thể áp dụng

• Hiện nay, các leader của Solana có toàn quyền sắp xếp giao dịch trong slot của mình, trong khi cách các khối được xây dựng thiếu tính minh bạch. BAM giới thiệu một giải pháp thay thế phi tập trung, có thể kiểm chứng, giúp logic sắp xếp có thể được kiểm tra.
• Mạng BAM phân tách rõ ràng các trách nhiệm: node BAM quản lý việc thu thập, ưu tiên và lọc giao dịch Solana, còn trình xác thực BAM xử lý khâu thực thi, đồng thuận và quản lý trạng thái. Cách tiếp cận này đưa Solana đến gần hơn với kiến trúc Tách biệt Bên đề xuất-Bên xây dựng (Proposer-Builder Separation, PBS).
• Framework plugin của BAM cho phép nhà phát triển xác định logic sắp xếp tùy chỉnh và đưa vào các nguyên mẫu lập lịch mới. Điều này hỗ trợ Thực thi do Ứng dụng Kiểm soát (Application-Controlled Execution, ACE), trong đó ứng dụng có thể áp dụng các quy tắc lập lịch giao dịch riêng.
• Jito cam kết cuối cùng sẽ mã nguồn mở BAM và thiết kế hệ thống với tính minh bạch làm trọng tâm. Đây là bước cải thiện lớn so với block engine hiện tại của Jito, vốn có mã nguồn đóng và do một bên đáng tin cậy duy nhất vận hành.
• Các node BAM sẽ chạy trên bộ xử lý AMD có hỗ trợ Secure Encrypted Virtualization nâng cao với Secure Nested Paging (SEV-SNP). Nhờ khả năng tăng tốc bằng phần cứng, SEV-SNP chỉ tạo ra mức chi phí bổ sung 2–5%, đủ nhanh để xử lý theo thời gian thực.
• Bộ lập lịch đầu tiên được triển khai cho các node BAM sẽ tổ chức đấu giá định kỳ trong từng khối tại mempool, chia khối thành N slot và phân bổ CU đồng đều cho mỗi phiên đấu giá.
• Thực thi do Ứng dụng Kiểm soát (ACE) có thể làm giảm nhu cầu sử dụng rollup hoặc phần mở rộng mạng để thực thi logic tùy chỉnh, qua đó giúp giữ lại nhiều hoạt động hơn trên mainnet Solana. Cơ chế này cũng mở rộng đáng kể không gian thiết kế cho các ứng dụng mới tận dụng không gian khối có thể lập trình.
• Jito dự định chuyển 100% phí giao thức từ cả Block Engine và hệ thống BAM sắp ra mắt vào Kho bạc Jito DAO. Hiện tại, Jito thu phí 6% trên tiền tip và chia đều giữa Jito Labs với DAO. Trong quý 2 năm 2025, DAO đã kiếm được 22.391,31 SOL (~4 triệu USD) từ các khoản phí này thông qua Tip Router.
• BAM lấy cảm hứng từ BuilderNet của Flashbots và áp dụng cách tiếp cận tương tự để xây dựng khối trong môi trường thực thi đáng tin cậy. Trên mainnet Ethereum, khoảng 40% số khối đã được xây dựng trong TEE.

Giới thiệu

Thị trường Lắp ráp Khối (BAM) của Jito là lần tái thiết kế đầy tham vọng nhất từ trước đến nay đối với quy trình xây dựng khối của Solana. Sau hơn tám tháng phát triển, BAM ra đời từ mong muốn tăng cường quyền riêng tư, tính minh bạch và khả năng thực thi có tính xác định trong từng slot trên Solana, nhằm hỗ trợ làn sóng ứng dụng nâng cao tiếp theo. Kết quả là một pipeline giao dịch được tái hình dung, thay thế mô hình sắp xếp thiếu minh bạch và do trình xác thực chi phối hiện nay bằng một hệ thống sắp xếp giao dịch riêng tư, có thể lập trình và công bằng theo cách có thể kiểm chứng.

BAM giới thiệu một mempool được mã hóa chạy bên trong Môi trường Thực thi Đáng tin cậy (TEE), nơi mọi giao dịch được giữ bí mật cho đến khi thực thi. Kiến trúc bảo vệ quyền riêng tư này nhằm giảm đáng kể, thậm chí loại bỏ, nhiều hình thức MEV mang tính khai thác nhất, mang lại cho người dùng sự đảm bảo thực thi mạnh mẽ hơn và mức giá tốt hơn. Trình xác thực có thể cung cấp chất lượng thực thi cao hơn, còn nhà phát triển và searcher có thể xây dựng trực tiếp trên một lớp không gian khối có thể lập trình mới.

BAM đưa logic thực thi do ứng dụng kiểm soát (ACE) vào hệ thống thông qua plugin. Điều này hỗ trợ các trường hợp sử dụng như khớp lệnh ưu tiên market maker cho hợp đồng vĩnh cửu, cập nhật oracle đúng thời điểm, thực thi lệnh time-in-force cùng các hình thức định tuyến và thực thi tùy chỉnh khác. Với khả năng kiểm soát chi tiết thứ tự giao dịch, nhà phát triển có thể xây dựng các nguyên mẫu tài chính tinh vi và đáng tin cậy hơn trên Solana, bao gồm sổ lệnh giới hạn tập trung, dark pool và các lớp tổng hợp.

Qua đó, BAM trực tiếp giải quyết nhiều chỉ trích lâu nay đối với mô hình sản xuất khối của Solana: hành vi thiếu minh bạch của trình xác thực, chất lượng thực thi không nhất quán và sự gia tăng của các thị trường xám thông qua mempool riêng tư cùng những thỏa thuận ngoài băng. Hiện nay, các leader của Solana có toàn quyền kiểm soát thứ tự giao dịch trong slot của mình, trong khi rất khó biết các khối cuối cùng được lắp ráp như thế nào. BAM thay thế mô hình này bằng một giải pháp phi tập trung, có thể kiểm chứng nhưng vẫn tích hợp liền mạch với runtime hiệu năng cao của Solana.

BAM dựa trên tiền lệ thực tế và lấy cảm hứng từ BuilderNet của Flashbots, áp dụng cách tiếp cận tương tự để xây dựng khối trong môi trường thực thi đáng tin cậy. Trên mainnet Ethereum, khoảng 40% số khối đã được xây dựng trong TEE, còn trên Unichain (L2 tùy chỉnh của Uniswap), con số này đạt 100%. BAM mở rộng mô hình này sang Solana, với lợi thế hỗ trợ sẵn khả năng lập trình ở cấp ứng dụng, thực thi có độ trễ thấp và tích hợp sâu với các client trình xác thực Jito, hiện đang bảo mật hơn 89% tổng lượng stake trên Jito-Agave và Jito-Firedancer.

Điều quan trọng là Jito đã cam kết cuối cùng sẽ mã nguồn mở BAM và thiết kế hệ thống với tính minh bạch làm trọng tâm. Đây là bước cải thiện lớn so với block engine hiện tại của Jito, vốn có mã nguồn đóng và do một bên đáng tin cậy duy nhất vận hành. BAM tạo ra các chứng thực on-chain—bằng chứng được ký bằng mật mã, xác nhận chính xác đoạn mã nào đã chạy và các giao dịch được sắp xếp ra sao—cho phép bất kỳ người quan sát nào cũng có thể xác minh tính công bằng của quá trình thực thi.

Tổng quan cấp cao về BAM

Về cốt lõi, BAM là một mạng sắp xếp giao dịch. Các node BAM xử lý việc thu thập, ưu tiên và lọc giao dịch Solana, trong khi trình xác thực BAM tập trung vào thực thi, đồng thuận và quản lý trạng thái. Việc phân tách trách nhiệm này giữ lại các nhiệm vụ cốt lõi có ý nghĩa thiết yếu với khả năng hoạt động liên tục của mạng trong trình xác thực, đồng thời tạo thêm tính linh hoạt và không gian thử nghiệm cho logic sắp xếp trong các node BAM.

Bản thân node BAM gồm một đơn vị xử lý giao dịch (TPU) và một bộ lập lịch giao dịch, hoạt động trong TEE. Node cũng chạy một server gRPC để giao tiếp với các trình xác thực được kết nối. Client Jito-validator đã sửa đổi có bộ thực thi vào trước-ra trước (FIFO), được tối ưu hóa cho khả năng đồng thời và song song thông qua cơ chế khóa có nhận biết account.

Mỗi node BAM có thể hỗ trợ nhiều trình xác thực, dù mỗi trình xác thực chỉ kết nối với một node BAM tại một thời điểm. Hiện tại, Jito vận hành bảy block engine. Với BAM, mạng hướng đến mở rộng quy mô đáng kể, đặt mục tiêu có từ 50 đến hơn 100 node BAM phân bổ trên tất cả khu vực địa lý chính để tăng tính phi tập trung và khả năng dự phòng. Node BAM và trình xác thực giao tiếp qua một stream gRPC hai chiều, trong đó kết quả thực thi được stream ngược từ trình xác thực về node BAM để cung cấp phản hồi theo thời gian thực.

Mọi giao dịch trong các node BAM đều được mã hóa bên trong Môi trường Thực thi Đáng tin cậy (TEE) cho đến thời điểm thực thi, bảo đảm luồng giao dịch được giữ riêng tư cho đến khi thực sự được thực thi.

Để đảm bảo thực thi công bằng, thứ tự giao dịch được ghi lại theo cách có thể kiểm chứng bằng các chứng thực. Đây là các bằng chứng mật mã được node BAM ký và đóng dấu thời gian nhằm xác nhận những sự kiện hoặc điều kiện cụ thể đã được quan sát. Kết quả là một dấu vết kiểm toán bất biến, cho phép người quan sát chứng minh rằng các giao dịch đã được thực thi đúng thứ tự.

Dấu vết kiểm toán bao gồm các giao dịch được chuyển tiếp đến trình xác thực và trình tự của chúng, chẳng hạn như giao dịch A, B và C đã được gửi tới trình xác thực Helius trong slot này. Hệ thống cung cấp các công cụ giám sát và phân tích theo thời gian thực, giúp người dùng theo dõi giao dịch từ lúc gửi đến lúc thực thi. Người dùng và ứng dụng sẽ có thể xác minh liệu trình xác thực BAM có tuân thủ thứ tự hay không, đồng thời biết chính xác đoạn mã nào đã chạy trong node BAM.

Các node BAM hiển thị minh bạch trên mạng, tương tự những relayer Jito hiện có. Khi một trình xác thực kết nối với BAM, trình xác thực đó quảng bá phiên bản BAM thông qua các cổng TPU và TPU forward, vốn đóng vai trò là điểm truy cập để nhận giao dịch.

Người dùng vẫn có thể gửi giao dịch qua các client RPC thường dùng. Tuy nhiên, để tăng cường bảo mật, họ có thể chọn gửi giao dịch trực tiếp đến các phiên bản BAM, ngăn trình xác thực độc hại chặn hoặc xem các gói giao dịch.

Khi một giao dịch đi vào BAM, giao dịch đó trải qua quy trình làm sạch tiêu chuẩn, bao gồm loại bỏ trùng lặp, xác minh chữ ký và kiểm tra định dạng, blockhash, bên trả phí, nonce cùng Address Lookup Tables có hợp lệ hay không.

Sau khi được xác thực, các giao dịch đi vào mempool của BAM và tham gia những phiên đấu giá định kỳ diễn ra thường xuyên. Khi một phiên đấu giá kết thúc, giao dịch được chuyển tới các trình xác thực. Toàn bộ trình tự giao dịch được phần mềm BAM ký và ghi vào cơ sở dữ liệu. Sau đó, trình xác thực stream kết quả thực thi trở lại thông qua một API được xây dựng theo API do bộ lập lịch mô-đun của Anza đề xuất.

Với môi trường lập lịch an toàn và thị trường phí cục bộ, các trình xác thực giờ đây hoạt động theo một hợp đồng tự nguyện tham gia chặt chẽ hơn nhiều. Họ nhận được một trình tự giao dịch xác định trước và phải lập lịch chính xác như được cung cấp, qua đó loại bỏ cơ hội chèn hoặc sắp xếp lại giao dịch vì mục đích xấu.

Một số cơ chế thực thi đang được xem xét để xử lý mọi trường hợp trình xác thực có hành vi sai trái, chẳng hạn như tấn công sandwich, dựa trên bằng chứng từ dấu vết kiểm toán. Dù chưa được hoàn thiện, các biện pháp có thể áp dụng gồm:

• Loại trình xác thực vi phạm khỏi mạng BAM.
• Yêu cầu trình xác thực cung cấp tài sản thế chấp dưới dạng bond, có thể bị phạt cắt giảm nếu có hành vi sai trái (dù điều này có thể làm tăng rào cản gia nhập đối với trình xác thực mới).
• Áp dụng danh sách đen hoặc danh sách xám để hạn chế toàn bộ hoặc một phần quyền tham gia của bên vi phạm.

Phí

Jito Labs và Jito Foundation đang cùng soạn thảo một Đề xuất Cải tiến Jito (JIP), theo đó 100% phí giao thức thu được từ cả Block Engine và hệ thống BAM sắp ra mắt sẽ được chuyển vào Kho bạc Jito DAO. Đề xuất này dự kiến được chính thức trình trong vài tuần tới, đánh dấu một thay đổi đáng kể trong mô hình kinh tế của Jito và cần được DAO phê duyệt. Nếu được thông qua, đề xuất sẽ củng cố vai trò trung tâm của DAO và những người nắm giữ token JTO trong hệ sinh thái Jito.

Hiện tại, giao thức Jito thu phí 6% trên tiền tip và chia đều giữa Jito Labs với DAO. Chỉ riêng trong quý 2 năm 2025, DAO đã kiếm được 22.391,31 SOL (~4 triệu USD) từ các khoản phí này thông qua Tip Router. Nguồn doanh thu chính khác của DAO đến từ phí jitoSOL, đạt tổng cộng 13.223,73 SOL (~2,38 triệu USD) trong cùng kỳ.

Môi trường Thực thi Đáng tin cậy (TEE)

Môi trường Thực thi Đáng tin cậy (TEE) là một kiến trúc được bảo vệ bằng phần cứng, được thiết kế để bảo đảm tính bí mật và toàn vẹn của cả hoạt động tính toán lẫn bộ nhớ. Còn được gọi là enclave, TEE cô lập việc thực thi mã khỏi hệ điều hành, kernel và hypervisor của hệ thống máy chủ, thường thông qua cơ chế phân tách ở cấp phần cứng. Sự cô lập này làm giảm đáng kể bề mặt tấn công, khiến việc quan sát hoặc can thiệp vào hoạt động của enclave trở nên cực kỳ khó khăn, dù không phải là bất khả thi.

TEE đã được sử dụng từ những năm 2000 trong các lĩnh vực như quản lý quyền kỹ thuật số, bảo vệ nội dung và hệ thống thanh toán an toàn. Ngày nay, TEE được dùng rộng rãi trên các thiết bị tiêu dùng và dịch vụ đám mây để xử lý dữ liệu cùng mã nhạy cảm một cách an toàn. Trên điện thoại thông minh và máy tính xách tay, Secure Enclave của Apple và TrustZone của Android bảo vệ dữ liệu sinh trắc học, thông tin xác thực thanh toán và khóa mã hóa. Các máy chơi game như PlayStation và Xbox sử dụng bộ xử lý AMD hoặc Pluton để ngăn can thiệp và vi phạm bản quyền. Trên đám mây, các nhà cung cấp như Azure và Google Cloud tận dụng AMD SEV-SNP, Intel TDX hoặc AWS Nitro Enclaves để cô lập workload và hỗ trợ điện toán bảo mật. Các ví tiền mã hóa như Ledger và Trezor sử dụng phần tử bảo mật để bảo vệ khóa riêng tư, còn điện thoại Solana Seeker mới dựa vào TEE cho cùng mục đích.

TEE là phương pháp tiêu chuẩn dựa trên phần cứng để xử lý dữ liệu riêng tư, cung cấp một giải pháp thay thế thực tế cho các phương pháp thuần mật mã như mã hóa đồng cấu hoàn toàn (FHE) và tính toán đa bên an toàn (MPC). Dù FHE và MPC mang lại sự bảo đảm mạnh mẽ về mặt lý thuyết, chúng thường không thực tế trong môi trường thực tế do độ phức tạp và chi phí hiệu năng cao.

BAM dựa vào hai thuộc tính cốt lõi của TEE:

Tính bí mật: Mã và dữ liệu bên trong TEE được mã hóa và cô lập khỏi phần còn lại của hệ thống. Hệ điều hành, hypervisor lẫn bất kỳ phần mềm bên ngoài nào đều không thể truy cập hoặc kiểm tra những gì chạy trong enclave.

Khả năng chứng thực: TEE hỗ trợ chứng thực, một cơ chế tạo ra bằng chứng mật mã về nguồn gốc và trạng thái hiện tại của enclave. Cơ chế này cho phép bên thứ ba xác minh rằng kết quả được tạo ra bởi một TEE thực sự đang thực thi mã đáng tin cậy, thay vì bởi một môi trường bị xâm phạm hoặc mô phỏng.

Triển khai TEE trong BAM

BAM sẽ chạy trên các bộ xử lý AMD hỗ trợ Secure Encrypted Virtualization với Secure Nested Paging (SEV-SNP) nâng cao. Không giống các phương pháp dựa trên enclave nhỏ hơn, SEV-SNP bảo vệ toàn bộ ứng dụng BAM với chi phí hiệu năng tối thiểu, rất phù hợp với các hệ thống giao dịch có thông lượng cao và độ trễ thấp.

Nhờ khả năng tăng tốc bằng phần cứng, SEV-SNP chỉ tạo ra mức chi phí bổ sung 2–5%, đủ nhanh để xử lý theo thời gian thực. Công nghệ này có thể hỗ trợ các ứng dụng kết nối mạng phức tạp, có trạng thái, chứ không chỉ những tác vụ tính toán cô lập. Đây là công nghệ đã được kiểm chứng trong thực tế, được triển khai trên các nhà cung cấp đám mây lớn như Google Cloud, Azure và AWS, đồng thời được hậu thuẫn bởi nhiều năm nghiên cứu bảo mật và kinh nghiệm vận hành.

SEV-SNP được sử dụng trong BAM cung cấp một số bảo đảm bảo mật quan trọng. Mỗi phiên bản TEE chạy bên trong máy ảo riêng được cô lập bằng phần cứng, với bộ nhớ được mã hóa trong thời gian chạy để bảo đảm khả năng cô lập mạnh mẽ ở cấp VM. BAM tận dụng cơ chế chứng thực bắt nguồn từ phần cứng, cho phép mỗi TEE chứng minh bằng mật mã rằng nó đang thực thi mã chính hãng, chưa bị sửa đổi. Chuỗi chứng thực này được neo vào các khóa gốc phần cứng của AMD, vốn được nhúng vật lý vào CPU trong quá trình sản xuất. Ngoài ra, các khóa TLS được tạo bằng trình tạo số ngẫu nhiên phần cứng nội bộ của bộ xử lý, bảo đảm chúng không bao giờ bị lộ trong bộ nhớ chưa mã hóa.

Khi một client kết nối với BAM, client đó nhận được chứng chỉ TLS chứa chứng chỉ kết nối tiêu chuẩn, báo cáo chứng thực AMD SEV-SNP và bằng chứng mật mã cho thấy khóa riêng tư TLS được tạo bên trong TEE đã chứng thực. Chuỗi chứng chỉ này được ràng buộc bằng mật mã với gốc tin cậy phần cứng của AMD. Không thể làm giả chuỗi này nếu không có quyền truy cập vào khóa gốc riêng tư của AMD, qua đó loại bỏ nhu cầu tin tưởng bất kỳ bên trung gian nào ngoài quy trình sản xuất chip của AMD.

Plugin

Hiện nay, các ứng dụng trên Solana chỉ có thể tác động đến thứ tự giao dịch thông qua phí ưu tiên hoặc các giao dịch được đóng gói kèm tiền tip. Khi có nhiều bộ sắp xếp tham gia trên các client như Agave và Firedancer, không có gì bảo đảm logic sắp xếp nào sẽ được áp dụng, khiến ứng dụng chỉ có quyền kiểm soát hạn chế đối với cách giao dịch của mình được sắp xếp.

Plugin giải quyết vấn đề này.

Thông qua framework plugin của BAM, nhà phát triển có thể triển khai logic sắp xếp chuyên biệt và đưa vào các nguyên mẫu lập lịch mới. Chúng hỗ trợ Thực thi do Ứng dụng Kiểm soát (ACE), cho phép ứng dụng xác định chính sách lập lịch giao dịch tùy chỉnh. Dù ACE có nhiều ứng dụng tiềm năng, trường hợp sử dụng được biết đến và thảo luận rộng rãi nhất là ưu tiên hủy lệnh trong sổ lệnh—một cơ chế giúp giảm lựa chọn bất lợi và thu hẹp chênh lệch giá.

Ưu tiên lệnh hủy của market maker trong sổ lệnh

Hiện nay, các market maker dùng sổ lệnh on-chain trên Solana đang gặp bất lợi. Market maker quản lý rủi ro bằng cách liên tục cập nhật hoặc hủy các báo giá lỗi thời khi giá hợp lý thay đổi. Khi giá thị trường biến động, họ cần hủy các lệnh hiện có trước khi những taker nắm nhiều thông tin hơn có thể tận dụng cơ hội.

Nếu không thể kiểm soát chi tiết thứ tự giao dịch, báo giá của họ dễ bị luồng độc hại khai thác mức giá lỗi thời. Market maker có thể chịu thiệt ngay cả khi phản ứng nhanh, vì phiên đấu giá Jito ưu tiên giá thầu hơn ý định. Về cơ bản, bên nào trả nhiều hơn sẽ được xếp trước.

Động lực này buộc market maker phải nới rộng chênh lệch giá để quản lý rủi ro, qua đó làm giảm thanh khoản tổng thể và khiến người dùng nhận được mức giá kém hơn. Những giao dịch độc hại này—trong đó taker kiếm lợi từ mức giá lỗi thời còn đối tác gần như lập tức hối tiếc sau khi giao dịch được thực hiện—hầu như không cải thiện trải nghiệm người dùng nhưng lại làm tăng đáng kể trở ngại cho market maker và nhà cung cấp thanh khoản.

Các plugin BAM cho phép thực thi chính sách "hủy trước khi khớp" ở cấp ứng dụng. Bằng cách trao cho chương trình quyền kiểm soát chi tiết thứ tự giao dịch, ứng dụng có thể chọn xử lý lệnh hủy của maker trước giao dịch của taker. Thay đổi chính sách đơn giản này mang lại tác động sâu rộng:

• Giảm lựa chọn bất lợi: Maker không còn thường xuyên bị tận dụng khi thị trường biến động.
• Lọc luồng độc hại: Dù tổng khối lượng có thể giảm do có ít giao dịch độc hại hơn, chất lượng luồng và khả năng thực thi sẽ được cải thiện.
• Cho phép chênh lệch giá hẹp hơn: Khi rủi ro giảm, maker có thể báo giá cạnh tranh hơn.
• Cải thiện thanh khoản: Cả maker chuyên nghiệp lẫn nhà giao dịch nhỏ lẻ đều tự tin hơn khi cung cấp báo giá, qua đó tạo ra thanh khoản sâu hơn.

Cập nhật oracle đúng thời điểm

Một ví dụ khác về plugin dành riêng cho ứng dụng là kế hoạch triển khai cập nhật oracle đúng thời điểm của Pyth. Là nhà cung cấp oracle hàng đầu trên Solana, Pyth duy trì hơn 1.700 nguồn cấp giá riêng lẻ. Việc cập nhật tất cả nguồn cấp trong mỗi khối sẽ cực kỳ tốn kém và kém hiệu quả về không gian khối.

Với BAM, Pyth có thể cập nhật chính xác các nguồn cấp giá cụ thể khi cần bằng cách chèn bản cập nhật oracle ngay trước giao dịch của người dùng trong cùng một khối. Điều này làm giảm rủi ro liên quan đến dữ liệu oracle lỗi thời, chẳng hạn như thanh lý kém hiệu quả và thao túng oracle, giúp các ứng dụng DeFi hoạt động đáng tin cậy và cạnh tranh hơn.

Các plugin khác

Mục tiêu cuối cùng của BAM là trở thành một nền tảng không cần cấp quyền, nơi nhà phát triển ứng dụng có thể xây dựng, kiểm thử và triển khai plugin để kiểm soát trình tự giao dịch. Dự kiến sẽ có thêm nhiều plugin, và cuối cùng các node BAM sẽ hỗ trợ hàng trăm phần mở rộng có thể tùy chỉnh. Dù phần lớn ứng dụng sẽ tiếp tục hoạt động bằng bộ lập lịch mặc định, những ứng dụng cần logic sắp xếp tùy chỉnh sẽ chịu trách nhiệm phát triển và duy trì plugin riêng.

Ngoài ra, các ứng dụng sẽ có thể kiếm tiền từ chức năng plugin bằng cách thu phí, với khả năng chia sẻ một phần doanh thu cho người nắm giữ token quản trị hoặc trình xác thực.

Plugin đa dụng tiềm năng

Plugin không chỉ giới hạn ở một ứng dụng duy nhất. Jito đã đề xuất một số ví dụ về plugin đa dụng, dùng được trên nhiều ứng dụng, có thể được phát triển cho BAM:

Hợp đồng tương lai không gian khối: Cho phép người dùng và ứng dụng đặt trước hoặc giao dịch quyền sử dụng không gian khối tại một thời điểm trong tương lai, mang lại khả năng truy cập và mức giá có thể dự đoán ngay cả trong những giai đoạn nhu cầu mạng cao.

Thời gian hiệu lực (TIF): chỉ khoảng thời gian một lệnh duy trì trạng thái hoạt động trước khi tự động bị hủy nếu chưa được thực thi đầy đủ, chẳng hạn như quy định một giao dịch trong sổ lệnh chỉ có hiệu lực trong 20 mili giây. Hiện có thể triển khai một phiên bản thô sơ của cơ chế này trên Solana bằng cách chủ động sử dụng blockhash cũ hơn để bảo đảm giao dịch chỉ có hiệu lực trong một hoặc một số khối gần nhất.

Xác nhận trước: Người dùng có thể nhận thông báo khi giao dịch của họ được chuyển tiếp tới trình xác thực trước khi giao dịch được thực thi và truyền ra mạng. Qua đó, giao dịch được xác nhận sớm hơn với một mức độ tin cậy nhất định.

Giao dịch không mất phí: cho phép người dùng thanh toán chi phí giao dịch bằng token SPL (ví dụ: stablecoin) thay vì SOL, trừu tượng hóa yêu cầu về token gốc và hỗ trợ thanh toán phí linh hoạt.

Bộ tổng hợp độ trễ thấp và Yêu cầu báo giá (RFQ): Người dùng gửi ý định giao dịch trực tiếp tới BAM, nơi một bộ tổng hợp chạy cục bộ xác định tuyến đường tối ưu.

Hủy và thay thế giao dịch: Người dùng có thể gửi giao dịch kèm các dấu hiệu đặc biệt cho phép họ hủy, loại bỏ hoặc thay thế giao dịch đã gửi trước đó.

Triển khai

Trong giai đoạn ra mắt, Jito Labs sẽ vận hành tập hợp node BAM ban đầu để bảo đảm tính ổn định, hiệu năng và bảo mật. Một nhóm đối tác trình xác thực ban đầu được cấp quyền, bao gồm Helius, SOL Strategies, Triton One và Figment, sẽ chạy client BAM và bảo mật tỷ lệ stake ở mức gần 10% trên toàn mạng ngay sau khi ra mắt.

Song song đó, nhóm ứng dụng Solana ban đầu, bao gồm Drift, Pyth và DFlow, sẽ bắt đầu thiết kế và kiểm thử làn sóng plugin đầu tiên. Đến cuối giai đoạn ra mắt, BAM dự kiến sẽ xác thực được chức năng cốt lõi và thiết lập nền tảng để các đơn vị vận hành node cùng trình xác thực tham gia rộng rãi hơn.

Các trình xác thực, nhà phát triển ứng dụng hoặc searcher muốn tham gia BAM có thể điền vào biểu mẫu này.

Một Ủy ban Cố vấn Hệ sinh thái gồm các bên liên quan nổi bật trong cộng đồng trình xác thực và nhà phát triển Solana, bao gồm Solana Foundation, sẽ cố vấn cho Jito Labs. Ủy ban này sẽ giúp định hướng quá trình mở rộng của BAM, thúc đẩy tính phi tập trung và nuôi dưỡng đổi mới do cộng đồng dẫn dắt.

Hiện tại, codebase của BAM vẫn có mã nguồn đóng, với kế hoạch mở mã nguồn trong tương lai gần để hỗ trợ phát triển plugin của bên thứ ba. Sau khi được mã nguồn mở, BAM sẽ chào đón đóng góp của cộng đồng trong một số lĩnh vực chính:

• Phát triển plugin: Xây dựng plugin tùy chỉnh để mở rộng khả năng của BAM.
• Thuật toán lập lịch: Thiết kế và đóng góp các chiến lược sắp xếp giao dịch mới phù hợp với từng trường hợp sử dụng cụ thể.
• Thư viện tích hợp: Phát triển SDK bằng nhiều ngôn ngữ lập trình để đơn giản hóa việc tích hợp BAM.
• Công cụ phân tích: Tạo dashboard và hệ thống giám sát tận dụng dữ liệu chứng thực của BAM.
• Đóng góp nghiên cứu: Đề xuất và triển khai các phương pháp mới để giảm thiểu MEV và tối ưu hóa hệ thống.

Các hệ quả

BAM đánh dấu một bước ngoặt đối với Solana, có tiềm năng mở ra làn sóng đổi mới bằng cách giải quyết những lo ngại về việc khai thác MEV và đóng gói block hiệu quả. Cơ chế sắp xếp thứ tự được TEE bảo vệ và framework plugin của BAM có thể làm giảm động lực để các nhóm ứng dụng xây dựng phần mở rộng mạng, rollup hoặc Môi trường Solana được cấp quyền nhằm thực thi logic tùy chỉnh hoặc blockspace theo quan điểm riêng, qua đó duy trì nhiều hoạt động hơn trên mainnet Solana. Ngoài ra, nhờ tăng giới hạn tính toán trên mỗi block và nhu cầu về các chương trình token cùng framework hiệu quả hơn, sử dụng ít CU hơn (ví dụ: mức độ phổ biến ngày càng tăng của Pinocchio và p-token), mainnet sẽ có thêm băng thông, tiếp tục làm giảm động lực để nhà phát triển xây dựng các giải pháp tùy chỉnh.

Các tính năng bảo mật của BAM cũng sẽ làm giảm đáng kể mức độ phổ biến của các cuộc tấn công sandwich vì giao dịch được ẩn cho đến khi thực thi, qua đó hạn chế khả năng frontrun người dùng của bot. Điều này có khả năng cải thiện hiệu quả của DEX và mang lại mức giá cạnh tranh hơn cho người dùng. Tuy nhiên, BAM khó có thể loại bỏ hoàn toàn MEV. Về bản chất, MEV là một trò mèo vờn chuột và những kẻ thực hiện sandwich sẽ thích nghi, có thể thông qua các cách khai thác plugin tinh vi hoặc thao túng oracle bên ngoài (tức là oracle không có plugin riêng), vì chúng không thuộc pipeline được mã hóa.

Việc giảm MEV thông qua BAM có thể ảnh hưởng tiêu cực đến doanh thu của Jito, tương tự như đợt đóng mempool năm 2024, vốn làm giảm thu nhập ngắn hạn nhưng cuối cùng lại mang lại lợi ích cho mạng. Những cải tiến của BAM có thể bù đắp tác động này bằng cách thúc đẩy tổng khối lượng giao dịch và phí plugin tăng lên, từ đó gia tăng doanh thu dài hạn nhờ tỷ lệ chấp nhận cao hơn. Tuy nhiên, cách triển khai cụ thể, lộ trình phát hành theo giai đoạn và mô hình kinh tế của BAM đặt ra những rủi ro tập trung hóa cùng các câu hỏi còn bỏ ngỏ mà chúng tôi sẽ phân tích trong những phần tiếp theo. Dẫu vậy, các rủi ro và câu hỏi này được cân bằng bởi nhiều lợi ích, mỗi lợi ích đều có những hệ quả riêng liên quan đến việc phân phối lại MEV, PBS và quá trình phát triển một client “mới”.

Phân phối lại MEV

BAM định hình lại căn bản bối cảnh MEV của Solana, từ việc khai thác không kiểm soát sang một mô hình phân phối lại có cấu trúc hơn. Trong các mô hình truyền thống, MEV thường làm thất thoát giá trị của người dùng thông qua frontrunning hoặc spam, khi trình xác thực hoặc bot thu lợi bằng các chiến thuật gây hại như tấn công sandwich. Tuy nhiên, mempool được TEE mã hóa của BAM ẩn giao dịch cho đến khi thực thi, qua đó hạn chế khả năng quan sát để thực hiện MEV tiêu cực. Thay vào đó, giá trị được giữ lại trong hệ thống thông qua plugin và cơ chế sắp xếp thứ tự tùy chỉnh. Nhờ đó, ứng dụng, nhà phát triển và bên tìm kiếm có thể thu được các dạng MEV tích cực giúp nâng cao hiệu quả của hệ sinh thái (ví dụ: chênh lệch giá DeFi thấp hơn, giảm spam oracle).

Quá trình phân phối lại này chuyển lợi nhuận MEV về cho các bên liên quan, khi phí plugin được chia sẻ giữa đơn vị vận hành BAM Node, trình xác thực, người stake và DAO của Jito. Điều này có tiềm năng tạo ra các nguồn doanh thu bền vững. Ví dụ, một DEX có thể sở hữu plugin tối ưu hóa việc khớp lệnh và chuyển MEV tiềm năng do trình xác thực khai thác thành phí do ứng dụng tạo ra, sau đó phân phối lại cho người nắm giữ token. Cách tiếp cận “được bảo vệ” đối với hoạt động giao dịch này có thể biến MEV từ một trò chơi có tổng bằng không thành động lực tăng cường thanh khoản và thu hút vốn tổ chức.

Tuy nhiên, việc phân phối lại cũng đi kèm rủi ro. Điểm quan trọng cần lưu ý là BAM không xóa bỏ MEV mà chỉ di chuyển nó. Sự dịch chuyển này có thể giúp những tác giả plugin tiên phong, đơn vị vận hành BAM Node và các tổ chức liên kết với Jito thu được lợi ích vượt trội. Dù bị ràng buộc bởi các chứng thực mật mã, nếu lỗ hổng TEE (ví dụ: tấn công kênh kề) xuất hiện, quyền truy cập đặc biệt dành cho bên tìm kiếm có thể tạo ra các phương thức khai thác tinh vi mới, cuối cùng làm suy yếu những cam kết về quyền riêng tư. Điều này cũng mở đường cho các hình thức backrunning “được bảo vệ”, trong đó bên tìm kiếm có thể triển khai mã để nối thêm giao dịch sau giao dịch của người dùng (ví dụ: thu lợi từ chênh lệch giá do một giao dịch hoán đổi làm thay đổi giá) mà không để lộ chiến lược hoặc tạo điều kiện cho frontrunning. Hơn nữa, khi không có cơ chế slashing theo chương trình, những kẻ tấn công có khả năng thích nghi có thể theo đuổi các chiến lược gây hại xoay quanh chứng thực, vốn được tạo sau khi thực thi và hiện phụ thuộc vào sự giám sát của cộng đồng.

Sau cùng, dù việc phân phối lại MEV giúp BAM trở thành chất xúc tác cho mục tiêu tối thượng của Solana (tức một NASDAQ phi tập trung), thành công của nó phụ thuộc vào việc áp dụng các mô hình phí công bằng và cơ chế bảo mật TEE vững chắc. Nếu được xử lý không đúng cách, BAM có thể gây phân mảnh mạng, làm xói mòn niềm tin của người dùng và khiến hoạt động “được bảo vệ” nhưng thiếu minh bạch của các bên tìm kiếm bị giám sát chặt chẽ.

Tách biệt bên đề xuất và bên xây dựng (PBS)

Hầu hết blockchain được thiết kế để cùng một thực thể vừa đề xuất vừa xây dựng block, qua đó trao cho họ quyền kiểm soát độc quyền đối với thứ tự và việc đưa giao dịch vào các slot được chỉ định. Điều này có lợi cho các thực thể đó vì họ có thể tự do kiểm duyệt hoặc thao túng luồng giao dịch theo những cách khác. Ví dụ, họ có thể đề xuất và xây dựng block bằng các chiến lược tinh vi nhưng gây hại để đưa giao dịch vào theo một thứ tự cụ thể, từ đó tối đa hóa MEV.

Tách biệt bên đề xuất và bên xây dựng (PBS) là một mẫu thiết kế giải quyết vấn đề này bằng cách tách việc xây dựng block khỏi việc đề xuất block. Theo thiết kế này, bên xây dựng block tạo danh sách giao dịch đã được sắp thứ tự và gửi giá thầu cho các block đó. Bên đề xuất block, thường là trình xác thực, sau đó chấp nhận và xác nhận block có giá thầu cao nhất, phân phối lại MEV thông qua đấu giá hoặc tiền tip mà không cần tự vận hành các chiến lược sắp xếp thứ tự phức tạp.

PBS đã được triển khai ngoài giao thức thông qua MEV-Boost trên Ethereum kể từ The Merge năm 2022. MEV-Boost là một “sidecar” chạy cùng phần mềm client hai lớp của trình xác thực, gồm lớp thực thi và lớp đồng thuận. Các trình xác thực chạy MEV-Boost có thể kết nối với nhiều relay và chấp nhận các block được bên xây dựng block tạo sẵn. Họ không thấy nội dung của block trước khi nó được đưa lên on-chain vì chỉ nhận số tiền thưởng block và header block từ các relay. Lưu ý rằng thiết kế này vẫn đang trong giai đoạn nghiên cứu tích cực vì PBS còn chờ được tích hợp đầy đủ vào giao thức (ePBS), có thể bao gồm các tính năng như danh sách đưa vào để tiếp tục giảm thiểu kiểm duyệt.

Với BAM, Solana đang tiến tới một tương lai tương tự PBS, tách việc xây dựng block (tức sắp xếp thứ tự trong các BAM Node được TEE bảo vệ) khỏi việc thực thi, vốn vẫn thuộc trách nhiệm của trình xác thực. Điều này có tiềm năng dân chủ hóa các dạng MEV tích cực cho ứng dụng và bên tìm kiếm thông qua plugin. Tuy nhiên, nó cũng có nguy cơ làm trầm trọng thêm tình trạng tập trung stake của Solana nếu mô hình kinh tế plugin ưu ái các bên đã có vị thế. Điều này thể hiện rõ trên Ethereum, nơi ba bên xây dựng (tức Titan Builder, BuilderNet, Beaverbuild) hiện chi phối hơn ~90% tổng số block, tạo ra vấn đề về niềm tin vào relay và rào cản đối với các bên tham gia nhỏ hơn.

Mặc dù MEV-Boost đã đưa PBS đến Ethereum, một đối tượng so sánh phù hợp hơn ở đây là BuilderNet, mạng xây dựng block phi tập trung ra mắt vào tháng 11 năm 2024 và do Flashbots, Beaverbuild cùng Nethermind vận hành. BuilderNet sử dụng TEE để xây dựng block riêng tư, qua đó phân tán quy trình cho nhiều đơn vị vận hành node nhằm vô hiệu hóa các thỏa thuận luồng lệnh độc quyền và giảm sự tập trung hóa. Mạng này tập trung vào việc tạo ra giá trị (tức chia sẻ khoản hoàn trả MEV với các nhà cung cấp luồng lệnh, chẳng hạn như người dùng, ví và ứng dụng), thay vì các cuộc cạnh tranh luồng lệnh (ví dụ: tranh giành thỏa thuận riêng tư). BuilderNet vẫn sử dụng relay MEV-Boost, nhưng chúng không hoàn toàn bắt buộc, nghĩa là tương tác trực tiếp giữa bên xây dựng và bên đề xuất có thể diễn ra trong TEE.

Lộ trình phát hành BAM theo từng giai đoạn và có cấp quyền phải ưu tiên mức phí công bằng cùng các plugin mã nguồn mở để giảm thiểu những hạn chế này của Ethereum, đặc biệt khi BAM phụ thuộc vào phần cứng (tức TEE thay vì relay phần mềm của Ethereum), dẫn đến nguy cơ bị khóa vào nhà cung cấp và phát sinh chi phí bảo trì. Solana hy vọng bỏ qua các cuộc cạnh tranh luồng lệnh để tiến thẳng đến một hệ thống tương tự BuilderNet, tập trung vào việc tạo ra giá trị.

Sau cùng, sự thay đổi trong việc xây dựng và đề xuất block này làm giảm vai trò của trình xác thực, chuyển bớt độ phức tạp của khâu sắp xếp thứ tự nhưng có thể làm giảm quyền chủ động và doanh thu của họ nếu phí không được chia sẻ rộng rãi. Chúng tôi phân tích chi tiết hơn trong phần Vai trò suy giảm của trình xác thực.

Trên đây: so sánh PBS của Ethereum với BAM của Solana

Một client “mới” xuất hiện

Client Jito-Agave bám sát codebase cốt lõi của Agave, với điểm khác biệt chính là bổ sung các khả năng MEV. Mô hình “Agave cộng MEV” của Jito cho phép client này tích hợp liền mạch với hệ sinh thái trình xác thực hiện có của Solana, tăng phần thưởng trong khi giảm thiểu thay đổi đối với kiến trúc cốt lõi. Nhờ đó, tại thời điểm viết bài, client Jito-Agave đang dẫn đầu mạng với 79% tỷ lệ được trình xác thực sử dụng. Vì vậy, trình xác thực có thể dựa vào logic nền tảng của Agave trong khi hưởng lợi từ các nguồn doanh thu bổ sung của Jito.

BAM đánh dấu sự khác biệt so với cách tiếp cận trước đây của Jito là bám sát Agave. Việc ra mắt một mạng lưới BAM Node chuyên biệt thiết lập một lớp cơ sở hạ tầng mới. Sự phát triển này đưa Jito từ một “Agave được nâng cấp” đơn thuần trở thành một client khác biệt hơn, hoàn chỉnh với hệ sinh thái có thể lập trình riêng để nhúng logic dành riêng cho từng ứng dụng.

Sự khác biệt này thể hiện rõ qua scheduler bindings sắp ra mắt của Agave, được Anza công bố vào tháng 5. Các cách triển khai scheduler tùy chỉnh ngày càng phổ biến khi MEV trên Solana trưởng thành. Dù scheduler tùy chỉnh có thể tăng doanh thu cho đơn vị vận hành, các cách triển khai hiện tại vẫn có một số nhược điểm, bao gồm yêu cầu chạy binary của một phiên bản trình xác thực khác, phụ thuộc vào mã nguồn đóng và tiềm ẩn lo ngại về khả năng hoạt động liên tục.

Scheduler bindings sắp ra mắt của Anza mang lại tính mô-đun bằng cách cho phép trình xác thực kết nối với các dịch vụ xây dựng block bên ngoài mà không cần thay đổi binary cốt lõi của trình xác thực, qua đó hỗ trợ scheduler tùy chỉnh. Thiết kế này thúc đẩy tính minh bạch, an toàn và giúp DevOps dễ dàng hơn. Tuy nhiên, BAM loại bỏ nhu cầu sử dụng các binding này đối với người dùng Jito vì việc sắp xếp thứ tự được scheduler của BAM Node xử lý ở thượng nguồn. Cách này bỏ qua scheduler bindings theo kế hoạch của Agave, có thể tinh giản hoạt động nhưng cũng làm dấy lên câu hỏi về nguy cơ phân mảnh hệ sinh thái trong tương lai do đi chệch khỏi nỗ lực tiêu chuẩn hóa của Anza (ví dụ: khiến việc tích hợp Firedancer trở nên phức tạp hơn).

Tuy nhiên, Jito đang định vị BAM như một phần của client trình xác thực hợp nhất. Các trình xác thực BAM sẽ chạy phiên bản cập nhật của client Agave có tích hợp scheduler BAM, chỉ chấp nhận giao dịch từ BAM Node theo thứ tự FIFO. Thiết kế này tránh phân mảnh client trong khi tăng cường khả năng phục hồi của hệ thống. Jito dự định phát hành client tương thích với BAM trước khi Anza triển khai scheduler mô-đun. Động thái này làm nổi bật tác động kép của BAM: thúc đẩy đổi mới và phát triển cơ sở hạ tầng MEV của Solana, nhưng cũng có nguy cơ tiếp tục củng cố vị thế của Jito với tư cách client trình xác thực thống trị.

BAM cũng có thể sử dụng các binding này. Nếu BAM hoạt động trong scheduler mô-đun, việc hỗ trợ Firedancer sẽ trở nên đơn giản và một câu hỏi mới sẽ xuất hiện: Jito có thực sự cần một client trình xác thực hay không. Chỉ thời gian mới trả lời được khi chúng ta chờ đợi việc triển khai mã nguồn mở và phát hành BAM.

Các câu hỏi còn bỏ ngỏ

Vai trò suy giảm của trình xác thực

Thiết kế của BAM làm thay đổi căn bản bối cảnh trình xác thực của Solana bằng cách chuyển việc sắp xếp thứ tự giao dịch sang một mạng riêng gồm các BAM Node được TEE bảo vệ. Điều này khiến trình xác thực chủ yếu chịu trách nhiệm về thực thi, đồng thuận và quản lý trạng thái. Sự tách biệt như vậy có lợi cho ứng dụng vì cho phép sắp xếp thứ tự tùy chỉnh và mở ra khả năng chia sẻ doanh thu với người nắm giữ token. Nó cũng mang lại lợi ích cho người dùng bằng cách giảm MEV tiêu cực và cung cấp mức giá thuận lợi hơn. Tuy nhiên, điều này đặt ra câu hỏi về quyền chủ động và động lực kinh tế ngày càng suy giảm của trình xác thực.

Khi sản xuất block với vai trò leader, trình xác thực hiện có toàn quyền quyết định thứ tự giao dịch, cho phép họ chạy scheduler tùy chỉnh để tối ưu hóa block theo ý muốn. BAM loại bỏ trách nhiệm này khỏi trình xác thực. Giờ đây, trình xác thực nhận các giao dịch đã được sắp xếp trước để thực thi theo thứ tự FIFO nghiêm ngặt, khiến họ mất quyền tự chủ trong việc xây dựng block. Ở kịch bản cực đoan nhất, nếu mọi giao dịch đều đi qua BAM, trình xác thực sẽ chỉ còn là những “con dấu cao su”, khiến người ta đặt câu hỏi liệu còn cần các trình xác thực phi tập trung hay không.

Tuy nhiên, vẫn có những yếu tố đối trọng. Cụ thể, phí plugin tạo ra các nguồn doanh thu mới được chia sẻ với trình xác thực và người stake. Client hợp nhất và cơ chế dự phòng tự động của BAM giúp lợi ích cá nhân đồng nhất với sức khỏe của mạng, qua đó cải thiện khả năng phục hồi tổng thể. Lộ trình phát hành theo giai đoạn và tự nguyện tham gia cũng duy trì quyền lựa chọn, còn việc mở mã nguồn về lâu dài cho phép trình xác thực có tiếng nói trong quá trình phát triển BAM, thúc đẩy các cải tiến do cộng đồng dẫn dắt và duy trì một phần quyền chủ động. Trình xác thực cũng có thể đề xuất cải tiến scheduler cho BAM, qua đó có khả năng mở ra cơ hội thu phí từ khối lượng cao hơn. Hơn nữa, việc coi trình xác thực chỉ là những con dấu cao su có lẽ là cường điệu, vì họ vẫn đóng vai trò then chốt trong đồng thuận và lựa chọn fork. Câu hỏi thực sự là trình xác thực sẽ thực sự mất bao nhiêu quyền chủ động? Liệu BAM có thể giúp trình xác thực tập trung tốt hơn vào khả năng hoạt động liên tục và tính toàn vẹn của trạng thái hay không?

Một số câu hỏi vẫn còn bỏ ngỏ:

• Nếu BAM Node xử lý việc sắp xếp thứ tự và khai thác MEV, trình xác thực sẽ cạnh tranh bằng cách nào ngoài phần cứng và thời gian hoạt động?
• Trong kịch bản được áp dụng rộng rãi, việc trình xác thực chỉ tập trung vào thực thi có làm giảm mức độ phi tập trung tổng thể của Solana không, và nếu có thì có thể dùng chỉ số nào để đo lường sự suy giảm này?
• Nếu BAM đẩy trình xác thực đến những con đường bất chính hơn để tìm kiếm doanh thu, biện pháp bảo vệ nào ngoài chứng thực có thể ngăn chặn điều này mà không tiếp tục làm giảm động lực?
• Lỗ hổng TEE hoặc việc khai thác plugin có thể khiến trình xác thực bị phạt không công bằng không?
• Từ kinh nghiệm của Ethereum với PBS, Solana có thể làm gì để chống lại sự suy giảm quyền chủ động của trình xác thực?

Đơn vị vận hành node độc hại

Kiến trúc của BAM đưa ra những giả định tin cậy mới liên quan đến trình xác thực. Cụ thể, giả định rằng trình xác thực sẽ không hành động ác ý khi tương tác với BAM Node, chẳng hạn như can thiệp vào các giao dịch đã được sắp xếp trước hoặc làm rò rỉ dữ liệu. Khi ra mắt, BAM sẽ dựa vào một nhóm đơn vị vận hành được cấp quyền do những hạn chế của TEE. Nhóm được cấp quyền này sẽ được giao nhiệm vụ chạy client Jito-Solana đã cập nhật và thực thi trung thực các giao dịch được chuyển tiếp. Các trình xác thực này phải tin rằng BAM Node không thao túng dữ liệu đầu vào, tạo ra hai lớp tin cậy (tức BAM Node trước TEE và trình xác thực sau TEE), làm tăng rủi ro trong mô hình được cấp quyền. Câu hỏi quan trọng là: điều gì ngăn đơn vị vận hành BAM Node xem trộm giao dịch trước khi chúng đến TEE? Câu trả lời là mã hóa QUIC dành cho các node đã được xác minh — họ sẽ nhúng chứng thực vào chứng chỉ QUIC. Một cách khác để xác định BAM Node có trung thực hay không là đối chiếu hash của chúng với kho lưu trữ mã nguồn mở của BAM để kiểm tra xem một BAM Node nhất định có đang chạy đúng phần mềm mà nó tuyên bố hay không. Giả sử chưa có ai phá được TEE, các chứng chỉ QUIC cho TPU sẽ được tạo bên trong TEE. Do đó, toàn bộ lưu lượng vào và ra đều sẽ được mã hóa.

Tuy nhiên, việc kiểm duyệt và thao túng có chọn lọc các gói giao dịch tại điểm vào và ra của mạng là những vấn đề đáng lưu ý. Đơn vị vận hành độc hại vẫn có khả năng kiểm duyệt đáng kể dù không thể xem chi tiết giao dịch đã mã hóa. Đơn vị vận hành có thể xác định loại giao thức thông qua chữ ký TLS, lọc dựa trên endpoint kết nối, thực hiện phân tích thời gian để nhận diện một số mẫu nhất định và chặn toàn bộ dữ liệu mã hóa khớp với những đặc điểm cụ thể. Vì vậy, đơn vị vận hành độc hại có thể không biết chính xác giao dịch nào đang được truyền, nhưng vẫn có thể loại bỏ gói dựa trên metadata và một số mẫu lưu lượng. Để giảm thiểu điều này, có thể tăng cường tính minh bạch bằng cách tích hợp khả năng lọc gói và đóng dấu thời gian của DoubleZero. Sau cùng, việc giảm thiểu các cuộc tấn công kiểm duyệt mạng là một lý do hợp lý để phát hành theo mô hình được cấp quyền.

Quyền truy cập vật lý cũng tạo ra những giả định tin cậy mới, vì đây gần như luôn là một điểm yếu bảo mật và TEE cũng không ngoại lệ. Dù TEE cung cấp các cam kết bảo mật mạnh mẽ, chúng vẫn có thể bị xâm phạm nếu kẻ tấn công có quyền truy cập vật lý vào máy chủ. Quan hệ đối tác độc quyền với các nhà cung cấp tuân thủ SOC 2 sẽ giúp giảm thiểu rủi ro này, bảo đảm khả năng bảo mật mạnh mẽ theo nhiều lớp ở cấp trung tâm dữ liệu.

Một số câu hỏi vẫn còn bỏ ngỏ:

• Nếu một đơn vị vận hành độc hại kiểm duyệt gói hoặc làm rò rỉ dữ liệu, cơ chế thực thi sẽ hoạt động như thế nào?
• Trong giai đoạn được cấp quyền, quy trình lựa chọn đơn vị vận hành sẽ tránh thông đồng bằng cách nào và có thể dùng chỉ số nào để đo lường tiến trình hướng tới phi tập trung hóa?

Khả năng kết hợp và tương tác giữa các plugin

Một trong những câu hỏi bỏ ngỏ quan trọng nhất đối với BAM là cách các plugin tương tác với nhau trong thực tế. Một giao dịch có thể phụ thuộc đồng thời vào nhiều plugin, chẳng hạn như sử dụng plugin oracle để cập nhật giá đúng lúc, plugin DEX để xác định lộ trình hoán đổi tối ưu và plugin token để xử lý các hành vi cụ thể của token SPL. Việc bảo đảm các thành phần này hoạt động cùng nhau một cách có thể dự đoán và an toàn là vô cùng quan trọng.

Plugin có thể cần truy xuất dữ liệu bên ngoài để hoạt động hiệu quả. Tuy nhiên, điều này tạo ra một bề mặt tấn công tiềm ẩn vì plugin độc hại có thể lạm dụng các lệnh gọi bên ngoài để làm rò rỉ thông tin giao dịch nhạy cảm. Việc xác định ranh giới nghiêm ngặt về những gì plugin có thể truy cập và chia sẻ là điều thiết yếu để duy trì niềm tin vào hệ thống.

Một lớp phức tạp khác đến từ sự tương tác giữa logic plugin ở cấp ứng dụng và cơ chế phí của Solana. Thứ tự thực thi plugin, tiền tip Jito và phí ưu tiên tương tác như thế nào khi nhiều plugin cạnh tranh để tác động đến quá trình xây dựng block? Các động lực kinh tế này phải được xác định rõ ràng và thực thi minh bạch để tránh hành vi thao túng hoặc lạm dụng ngoài dự kiến.

Để quản lý những rủi ro này, các plugin BAM dự kiến sẽ được phát hành trước tiên trong một môi trường được cấp quyền. Điều này cho phép thử nghiệm ban đầu và kiểm tra hành vi plugin trước khi dần chuyển sang mô hình không cần cấp quyền.

Niềm tin và trách nhiệm pháp lý của TEE

Việc phụ thuộc vào TEE đưa ra những giả định tin cậy mới vì hệ thống sử dụng enclave phần cứng chuyên dụng thay vì tạo ra một hệ thống không cần tin cậy để bảo đảm khả năng tính toán có thể xác minh. Phụ thuộc vào một nhà cung cấp phần cứng duy nhất như Intel hoặc AMD tạo ra rủi ro độc canh — một đợt thu hồi firmware hoặc một lỗ hổng có thể khiến BAM ngừng hoạt động và có thể gây thời gian ngừng hoạt động trên toàn mạng tùy theo mức độ áp dụng. Nếu không thể khắc phục các lỗ hổng này bằng bản cập nhật firmware, microcode hoặc BIOS, việc thay thế phần cứng sẽ mất thời gian và tạo ra chi phí vốn định kỳ cho đơn vị vận hành BAM Node, tiếp tục làm trầm trọng thêm tác động của thời gian ngừng hoạt động tiềm ẩn.

Những lo ngại này dựa trên các lỗ hổng trong quá khứ cho thấy TEE có thể gặp sự cố và có khả năng làm lộ dữ liệu mã hóa. Ví dụ, Software Guard Extensions (SGX) của Intel đã gặp nhiều vấn đề ảnh hưởng đến blockchain. Vào tháng 8 năm 2022, Secret Network đã bị ảnh hưởng bởi các lỗ hổng xAPIC và MMIO. Khi kết hợp, những lỗ hổng này có thể được dùng để trích xuất consensus seed — khóa giải mã chính cho các giao dịch riêng tư được thực thi trên mạng.

Hàng loạt vấn đề khác cuối cùng đã khiến Intel ngừng hỗ trợ SGX trên các bộ xử lý Intel Core thế hệ 11 và 12. Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) của AMD cũng có một số lỗ hổng đã được công bố. Đáng chú ý, vào tháng 2, CVE-2024-56161 đã được công bố — một lỗ hổng cho phép chèn microcode độc hại khi có quyền admin.

Các bản cập nhật nhằm giảm thiểu lỗ hổng không phải lúc nào cũng tương thích ngược và có thể yêu cầu nâng cấp vật lý. Ví dụ, việc công bố CVE02020-12967 và CVE-2021-26311 cho thấy có khả năng thực thi mã tùy ý bên trong các máy ảo khách trên máy AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), phiên bản triển khai TEE thế hệ trước của công ty. AMD không phát hành firmware cập nhật để xử lý các lỗ hổng này mà cung cấp biện pháp giảm thiểu trong tính năng SEV-SNP, vốn chỉ được hỗ trợ trên bộ xử lý AMD EPYC thế hệ 3 (tức “Milan”).

Cơ sở hạ tầng TEE của BAM được xây dựng trên kiến trúc SEV-SNP thế hệ mới nhất, bao gồm các biện pháp bảo vệ ở cấp phần cứng cần thiết để ngăn chặn những phương thức khai thác đã biết này. Cũng cần lưu ý rằng nếu phát hiện lỗ hổng zero-day, mạng vẫn có thể tiếp tục hoạt động vì Jito-Validator có thể tự động chuyển về TPU riêng khi mất kết nối với BAM Node. Cơ chế chuyển đổi dự phòng này bảo đảm trình xác thực tiếp tục chạy trong khi các bản vá bảo mật được áp dụng.

Một số câu hỏi vẫn còn bỏ ngỏ:

• Việc BAM phụ thuộc vào các nhà cung cấp phần cứng ảnh hưởng thế nào đến niềm tin dài hạn khi xét đến những vụ khai thác trước đây? Có thể sử dụng các giải pháp thay thế như Môi trường thực thi Zero Trust (ZTEE) để giảm sự phụ thuộc này không?
• Ai phải chịu trách nhiệm pháp lý đối với tổn thất tài chính nếu dữ liệu giao dịch riêng tư bị rò rỉ từ một TEE đã bị xâm phạm?
• Niềm tin sẽ được khôi phục như thế nào nếu TEE gặp sự cố? Có thể cung cấp một giải pháp thay thế không?

Kết luận

Sau cùng, các validator có toàn quyền chạy phần mềm họ lựa chọn. Là những doanh nghiệp hướng đến lợi nhuận hoạt động trong một thị trường có tính cạnh tranh cao, quyết định của họ chịu ảnh hưởng bởi lợi nhuận tiềm năng cho cả chính họ lẫn những người ủy quyền stake. Những người này có thể tự do chuyển stake đến nơi mang lại lợi suất cao nhất. Việc Jito-client được áp dụng rộng rãi phản ánh động lực này, khi thành công của nó phần lớn đến từ khả năng tạo thêm doanh thu cho cả bên vận hành và người ủy quyền stake. Việc áp dụng BAM cũng sẽ phụ thuộc vào những động lực tương tự. Nếu chạy BAM liên tục mang lại nhiều lợi nhuận hơn hiện trạng, các validator sẽ áp dụng nó. Nếu không, họ có thể do dự chuyển đổi, ngay cả khi BAM mang lại những lợi ích đáng kể cho các bên liên quan khác.

Do BAM chỉ mới được công bố gần đây, nhiều câu hỏi về thiết kế và cách vận hành vẫn chưa có lời giải đáp. Chúng tôi mong đợi thêm thông tin chi tiết, tài liệu và các cuộc thảo luận cộng đồng về bước phát triển đầy hứa hẹn này trong những tháng tới.

Tài nguyên khác

• Giới thiệu BAM: Tương lai của việc xây dựng block trên Solana - Jito
• Loạt bài thảo luận trên bảng trắng về BAM - Jito Learn
• Jito BAM và tương lai của Solana - 0xResearch