Sứ mệnh ban đầu của Solana là xây dựng một “xương sống” phi tập trung cho Internet Capital Markets (ICM). Việc tăng băng thông và giảm độ trễ (IBRL) là hoàn toàn cần thiết — nhưng vẫn chưa đủ để đạt mục tiêu này. Trụ cột thứ ba trong lộ trình của Solana phải giải quyết tính phức tạp của cấu trúc vi mô thị trường. Trong các thị trường tài chính, có vô vàn yếu tố chuyển động, mỗi yếu tố đều gây ảnh hưởng lớn — đôi khi khó lý giải — tới trạng thái cân bằng chung. Cho tới nay, vẫn chưa rõ cấu trúc vi mô của ICM nên khác biệt ra sao so với tài chính truyền thống (TradFi).
Hiện hệ sinh thái đang hội tụ quanh một tầm nhìn chung: Application‑Controlled Execution (ACE). Mục tiêu cuối cùng của ACE là trao cho Smart Contract quyền kiểm soát thứ tự giao dịch của chính chúng ở cấp độ milli‑giây. Qua đối thoại với các đội ngũ trong hệ sinh thái, chúng tôi nhận thấy cấu trúc vi mô thị trường là vấn đề quan trọng nhất của Solana hiện nay.
Tất cả các bên trong hệ sinh thái Solana đều đang nỗ lực giải quyết vấn đề này từ mọi góc độ.
Lúc này, Solana rõ ràng là nơi tốt nhất trong lĩnh vực Crypto để xây dựng ứng dụng nếu bạn cần lượng người dùng lớn, thanh khoản dồi dào, môi trường pháp lý rõ ràng, ví chất lượng và hạ tầng Onboarding toàn cầu. Dẫu vậy, một số ứng dụng vẫn tự xây công nghệ riêng vì muốn thử nghiệm cấu trúc thị trường mới. Solana phải trở thành nền tảng lý tưởng cho cả hai mục tiêu: tận dụng sẵn người dùng hiện có và tự do thử nghiệm cấu trúc vi mô mới.
Phần còn lại của bài viết gồm hai mục lớn:
- Tổng quan về các đánh đổi lớn trong thiết kế cấu trúc vi mô thị trường
- Các giải pháp cụ thể trong ngắn hạn, trung hạn và dài hạn nhằm hỗ trợ cấu trúc thị trường vi mô linh hoạt trên Solana Mainnet.
Những Đánh Đổi Trong Cấu Trúc Vi Mô Thị Trường
Cấu trúc vi mô thị trường có rất nhiều khía cạnh khác nhau đến mức không thể liệt kê hết trong một danh sách hoàn chỉnh. Tuy nhiên, dưới đây là một số cặp đánh đổi phổ biến nhất mà các ứng dụng trong ngành đang cân nhắc hiện nay:
Riêng tư & Minh bạch
Một câu hỏi mọi người đặt ra ở cả hai phía của thị trường là: liệu các lệnh đặt hàng có nên được ẩn đi trước khi thực thi hay không? Đối với những lệnh lớn từ nhà đầu tư cá nhân, việc công khai giao dịch của bạn có thể cải thiện kết quả khớp lệnh vì nó giảm bất cân xứng thông tin giữa bạn và các nhà tạo lập thị trường. Ngược lại, tính thanh khoản ẩn có thể dẫn tới các thị trường thanh khoản hơn vì ẩn lệnh giúp bảo vệ các nhà tạo lập thị trường khỏi tình trạng chọn lọc bất lợi độc hại. Tuy nhiên, sự bảo vệ này phải trả giá: thanh khoản ẩn làm giảm mức độ minh bạch và khiến các nhà giao dịch khó biết được họ sẽ được khớp lệnh ở mức giá nào trước khi lệnh được thực thi.
Speedbumps (Chặn tốc độ) & Unrestricted Trading (Giao dịch không giới hạn)
Các Speedbump bảo vệ phía Taker nên làm giảm chọn lọc bất lợi, dẫn đến chênh lệch giá hẹp hơn và các thị trường thanh khoản hơn; tuy vậy, Speedbump dành cho Taker cũng làm giảm khối lượng giao dịch (vì có ít giao dịch độc hại hơn) và làm chậm quá trình khám phá giá (vì những giao dịch có thông tin sẽ diễn ra nhanh hơn trên những sàn không có Speedbump). Nhưng khối lượng giao dịch chỉ là một chỉ số phù phiếm. Điều người dùng thực sự quan tâm là thanh khoản; nghĩa là họ giao dịch ở nơi có mức giá tốt nhất. Một phần khối lượng là tốt vì nó giúp thị trường hiệu quả hơn, phần khối lượng khác—đặc biệt là khối lượng từ các Taker độc hại—làm thị trường kém thanh khoản. Khi các nhà tạo lập thị trường liên tục mất tiền do các Taker độc hại khai thác những chênh lệch giá rất nhỏ giữa các sàn, họ sẽ bù đắp bằng cách đưa ra mức giá tệ hơn cho người dùng. Nếu bạn thực hiện các thay đổi nhằm giảm khối lượng từ các Taker độc hại, bạn có thể làm giảm khối lượng tổng thể nhưng lại tăng thanh khoản trên sàn.
Solana nên là nơi lưu trữ các thị trường thanh khoản nhất thế giới, chứ không phải những thị trường có khối lượng giao dịch cao nhất.
Inclusion & Finality & Execution Latency
Mặc dù dòng tweet kể trên xem ba yếu tố này như một “cuộc đánh đổi”, thực tế chúng không phải là ba lựa chọn loại trừ lẫn nhau.
- Time‑to‑inclusion (thời gian để một giao dịch được “nhặt” vào khối) chủ yếu phụ thuộc vào chu trình xử lý giao dịch trước khi chúng xuất hiện trên chuỗi và vào slot‑time (khoảng 400 ms hiện nay).
- Time‑to‑finality (thời gian để khối được xác nhận chắc chắn) chủ yếu do thuật toán đồng thuận quyết định.
Finality nhanh hơn rất quan trọng vì giúp Market Maker không phải bận tâm đến các nhánh Fork phức tạp; tuy vậy, rút ngắn time‑to‑inclusion còn quan trọng hơn đối với thanh khoản, vì nó quyết định tốc độ Market Maker có thể cập nhật báo giá. Khi time‑to‑inclusion càng nhỏ, Market Maker càng ít gặp “Gap Risk”—giá đã biến động off‑chain trong khi họ chưa kịp hủy báo giá cũ và bị taker “vớt” mất.
Hiện tại Solana cung cấp Optimistic Finality khoảng 1 giây. Sau bản nâng cấp Alpenglow (dự kiến triển khai Mainnet đầu 2026), time‑to‑inclusion được kỳ vọng giảm còn 50–100 ms, và finality chỉ khoảng 150 ms.
Colocation & Geographic Decentralization
Bề ngoài, nhiều người tin rằng colocation (đặt tất cả Validator cùng một vị trí) sẽ nhanh hơn, nhưng cách làm đó không đảm bảo đưa mọi thông tin toàn cầu lên chuỗi với tốc độ cao nhất. Giả sử tất cả Validator của một blockchain đều ở New York; nếu chính phủ Nhật Bản đột ngột công bố nới lỏng hạn chế thương mại với ô‑tô Mỹ, thì phải mất hơn 100 ms để phản ứng thị trường ở Nhật “chạy” đến cụm Validator Mỹ.
Với phân tán địa lý và cơ chế nhiều Leader đồng thời (Multiple Concurrent Leaders – MCL), thông tin từ khắp thế giới về lý thuyết có thể được nạp vào hệ thống trong cùng một tick thực thi 20 ms.
Bằng cách phi tập trung quy trình inclusion qua MCL và đẩy khâu “nhặt” giao dịch ra rìa mạng, Solana càng rút ngắn thời gian để thông tin mới ảnh hưởng đến quá trình hình thành giá, bất kể nguồn gốc thông tin ở đâu.
Mô hình colocation còn tạo ra bất cân xứng thông tin nghiêm trọng, khiến bản chất mỗi cụm colocation chỉ là một thị trường “khu vực theo thời gian”. Giao dịch tập trung tận dụng arbitrage giữa các sàn, trông có vẻ như một thị trường toàn cầu, nhưng thực chất mỗi “cụm” lại vận hành như một thị trường cục bộ.
Phân tán địa lý còn mang những lợi thế khác ngoài việc đồng bộ thông tin nhanh nhất có thể:
- Giúp mạng kháng thiên tai và sự cố lưới điện ở từng địa phương.
- Làm mạng khó bị thao túng bởi các thực thể thù địch.
- Giảm thời gian truyền tin cho người dùng, vì họ có thể gửi giao dịch tới Leader gần mình thay vì phải chuyển đến Leader ở nửa kia thế giới.
Ưu tiên Maker hay Taker
Chênh lệch giá (spread) được xác lập bởi điều kiện lợi nhuận bằng không, cân bằng giữa hai lực đối kháng: doanh thu thu được từ các nhà giao dịch thiếu thông tin và chi phí bị các nhà giao dịch có thông tin “hớt tay trên”. Trong hầu hết thị trường khác, việc ưu tiên maker tạo ra môi trường lành mạnh hơn với spread hẹp hơn so với ưu tiên taker, bởi vì khi taker được ưu tiên, mức độ chọn lọc bất lợi tăng mạnh, làm spread giãn rộng.
Thực tế trên Solana hiện nay, hệ thống không tuyên bố ưu tiên rõ ràng bên nào. Tuy nhiên, do các phiên đấu giá định kỳ của bộ lập lịch (scheduler), taker ngầm nắm lợi thế. Một số blockchain L1 phi tập trung khác còn tệ hơn, vì chu kỳ đấu giá của họ kéo dài hơn nữa.
Trong phần “Giải pháp” bên dưới, chúng tôi sẽ trình bày chi tiết cách ACE cho phép từng ứng dụng tự thiết lập quy tắc riêng giữa maker và taker (ví dụ: speedbump, xử lý lệnh hủy của maker trước lệnh mới của taker,…)
Nhà đầu tư cá nhân & Nhà đầu tư tổ chức
Các sàn giao dịch nên hướng tới việc thu hút càng nhiều trader thiếu thông tin càng tốt, vì họ tạo ra spread chặt nhất. Trong trường hợp nhu cầu kiến trúc của nhà đầu tư cá nhân và tổ chức khác nhau, Solana kỳ vọng sẽ có những ứng dụng riêng biệt phục vụ từng nhóm, và cả hai đều phát triển song song trên Solana mainnet.
Linh hoạt & Định kiến cứng nhắc
Trong hệ sinh thái Solana không có chỗ cho sự cuồng tín; chỉ có các kỹ sư thực dụng muốn xây dựng một nền tảng hỗ trợ những thị trường tài chính thanh khoản nhất thế giới. Nếu cộng đồng thực sự tin rằng chỉ có một cấu trúc thị trường tối ưu, hẳn họ đã đưa thẳng nó vào giao thức. Nhưng thực tế, điều đó chưa hề diễn ra.
Cách duy nhất để xác định cấu trúc thị trường tốt nhất ở một thời điểm là triển khai thực tế, thu thập dữ liệu, lặp lại và cải tiến. Solana đang xây dựng nền tảng linh hoạt nhằm hỗ trợ ACE, vì chúng tôi tin rằng đây là con đường nhanh nhất dẫn đến sự hội tụ tối ưu của cấu trúc vi mô.
Các ứng dụng chạy trên Solana sẽ thử nghiệm song song với tất cả các đánh đổi kể trên, từ đó nhanh chóng đạt tới trạng thái cân bằng dài hạn tốt nhất.
Kết hợp & Hoàn toàn on‑chain
Solana được thiết kế để phục vụ các thị trường 100 % on‑chain—không chỉ đóng vai trò là lớp tất toán (settlement) cho sàn tập trung chạy off‑chain. Không tồn tại rào cản kỹ thuật hay “bài toán mở” nào ngăn cộng đồng đạt được điều đó; việc còn lại chỉ là tiếp tục xây dựng.
Ưu tiên số một của Solana là đưa càng nhiều thanh khoản lên mainnet càng tốt.
Lộ Trình Phát Triển Ngắn, Trung & Dài hạn Của ICM
Hiện tại, Solana mainnet vẫn chưa phải môi trường lý tưởng cho các sổ lệnh giới hạn tập trung (Central Limit Order Books – CLOB) vì nhiều lý do khác nhau — nhưng điều đó sẽ sớm thay đổi. Các đội ngũ trong toàn hệ sinh thái đang làm việc xuyên suốt mọi tầng của ngăn xếp để giúp CLOB phát triển mạnh mẽ trên mainnet, và một số cập nhật quan trọng sẽ được triển khai ngay trong tháng tới; những cải tiến bổ sung sẽ tiếp tục xuất hiện ở giai đoạn trung hạn và dài hạn.
Phần dưới đây sẽ trình bày chi tiết các phát triển ngắn, trung và dài hạn nhằm bảo đảm CLOB hoạt động tối ưu trên Solana, qua đó giúp các chương trình giao dịch on‑chain có thể cạnh tranh với những nền tảng tập trung.
Ngắn hạn: Block Assembly Marketplace (BAM) của Jito và cải tiến “Transaction Landing” của Anza
Ngắn hạn được định nghĩa là 1–3 tháng kế tiếp . Điều này đồng nghĩa với việc các dự án đã được phát triển suốt một thời gian và sắp được triển khai lên mainnet trong tương lai rất gần.
Block Assembly Marketplace
Block Assembly Marketplace của Jito (BAM) là một hệ thống xử lý giao dịch thế hệ mới, hiệu năng cao, cung cấp cho các Validator, trader và ứng dụng trên Solana những công cụ mạnh mẽ nhằm tối ưu hiệu suất và tạo ra giá trị mới.
Jito Labs bắt đầu phát triển BAM vào cuối năm 2024 sau khi nhận thấy nhu cầu cấp bách về tính xác định thứ tự giao dịch ở cấp độ nội‑slot. Mạng thử nghiệm (testnet) của BAM sẽ được khởi chạy trong vài ngày tới.
Trong ngắn hạn, BAM mang lại trải nghiệm gần như ACE đầy đủ. Các đối tác thiết kế—bao gồm Drift, Pyth và Dflow—đã bắt đầu xây dựng plugin cho BAM ngay lúc này.
BAM vận hành qua một mạng lưới phi tập trung gồm các Operator chạy bộ phần mềm BAM bên trong các Môi trường Thực thi Tin cậy (TEE). Validator chỉ cần kết nối tới các node BAM bằng Client Jito‑Solana mới, hoàn toàn không cần tích hợp phức tạp. Các TEE của BAM thiết lập một lớp riêng tư đặc biệt: giữ bí mật giao dịch cho đến khi thực thi, đồng thời bảo đảm quá trình xếp thứ tự giao dịch minh bạch, có thể kiểm chứng nhờ mã nguồn mở và chứng thực TEE. BAM tạo ra bằng chứng mật mã cho mọi thao tác, trở thành hệ thống xử lý giao dịch minh bạch nhất hiện nay.
Thông qua cơ chế plugin, BAM cho phép nhà phát triển xác định quy tắc sắp xếp giao dịch ngay trong từng slot—về bản chất chính là ACE, nhưng chạy trong BAM thay vì trực tiếp trên Mainnet Solana.
BAM biến Blockspace của Solana thành một “hộp cát” mở, nơi lập trình viên có thể xây dựng các chương trình mô‑đun bổ sung chức năng cho Pipeline giao dịch. Lần đầu tiên, ứng dụng có thể áp dụng quy tắc xếp lệnh tùy biến, giúp các CLOB on‑chain đạt chất lượng ngang sàn giao dịch truyền thống. Plugin CLOB chạy trong BAM, kết hợp Logic Off‑chain và On‑chain, bảo đảm tính minh bạch và kết quả tất định. Khác với cách tiếp cận truyền thống—phải fork Client Validator và đàm phán với từng Validator – Developer chỉ cần viết plugin trong BAM và lập tức khai thác được hiệu ứng mạng toàn cầu của Solana, bảo đảm mọi giao dịch đều được xác thực mật mã và xếp thứ tự minh bạch ngay từ ngày đầu.
Validator thu về nhiều phí hơn nhờ khối được xây dựng tối ưu. Người dùng nhận được khớp lệnh nhanh hơn, rẻ hơn và tin cậy hơn. Trader chuyên nghiệp nâng cao niềm tin vào hạ tầng Solana vì BAM mã nguồn mở và có thể kiểm chứng, bảo đảm tính công bằng, không có “chiêu trò” hay “cửa sau”. Tất cả các bên đều hưởng lợi khi hiệu ứng mạng được khuếch đại, tạo vòng xoáy đổi mới và gia tăng giá trị.
BAM sẽ bắt đầu triển khai vào cuối tháng Bảy. Khi được kích hoạt, BAM sẽ đem lại cải thiện đáng kể về trải nghiệm giao dịch, giúp các ứng dụng trên Solana mainnet tiến gần hơn tới chất lượng của các sàn giao dịch tập trung.
Cải tiến “Transaction Landing” của Anza
Song song với BAM, Anza đang nỗ lực nâng cao độ tin cậy của quá trình “đặt chân” giao dịch, nhằm bảo đảm các giao dịch ổn định rơi vào đúng một slot.
Cách đây một năm, việc để một giao dịch vượt qua giai đoạn ingest đã rất khó; quá trình lập lịch hầu như ngẫu nhiên. Sau khi sửa hàng loạt lỗi trong triển khai QUIC và giới thiệu bộ lập lịch hợp nhất (Unified Scheduler), Pipeline xử lý giao dịch của Solana hiện đã cải thiện đáng kể.
Phiên bản Agave 2.3 (khuyến nghị dùng cho Mainnet hiện tại) tích hợp khách hàng TPU mới hoàn toàn, giúp giảm rõ rệt độ trễ khi gửi giao dịch. Bên cạnh đó, các kỹ sư Anza đã phối hợp với những Market Maker hàng đầu và nhà cung cấp RPC để vá lỗi QUIC và khắc phục vấn đề “nhắm Leader” (Leader Targeting) vốn làm giảm tỷ lệ giao dịch rơi đúng slot. Một thay đổi cụ thể trong cơ chế “Transaction Landing” của Triton cũng phản ánh điều này. Phần lớn các bản vá đã được triển khai; hiện nay, các Market Maker ghi nhận độ trễ p95 bằng 0 slot khi gửi giao dịch qua đường TPU tiêu chuẩn.
Trung hạn: DoubleZero, Alpenglow, Async Program Execution (APE)
Trong phần này, “trung hạn” được hiểu là 3–9 tháng tới — tức các dự án đã được công bố, đang tiến triển và dự kiến ra mắt mainnet vào quý IV / 2025 hoặc quý I / 2026.
DoubleZero
DoubleZero (DZ) là mạng cáp quang chuyên dụng hiệu năng cao dành cho các hệ thống phân tán, được thiết kế đặc biệt để giúp các blockchain như Solana đạt tới băng thông và độ trễ mà Internet công cộng không thể đáp ứng. Ngoài việc giảm độ trễ đáng kể và tăng băng thông, DoubleZero còn đóng vai trò lớp lọc mạnh mẽ: bảo vệ mạng Solana khỏi các cuộc tấn công từ chối dịch vụ và giảm tải xử lý lưu lượng cho Validator và RPC, nhờ đó họ có thể tập trung nguồn lực vào việc rút ngắn độ trễ thực thi và mở rộng Blockspace, qua đó tăng doanh thu (Network REV) cho mạng. DoubleZero cho phép giao dịch, khối và thông điệp đồng thuận của Solana được truyền qua Multicast—một dạng tăng tốc phần cứng cho việc nhân bản gói tin—từ đó tiếp tục giảm gánh xử lý lưu lượng trong toàn mạng và nâng cao tính công bằng. Khi kết hợp độ trễ truyền dẫn thấp và độ dao động gần bằng 0 (Near‑zero Jitter), Solana sẽ có hạ tầng xương sống đủ mạnh để cải tiến các primitive giao thức, đồng thời thu hút và giữ chân các Market Maker chất lượng cao cùng lưu lượng giao dịch bán lẻ bổ sung.
Nhìn chung, DoubleZero kỳ vọng hiệu năng thực tế trên Mainnet sẽ được cải thiện đáng kể khi mạng này được cụm Validator chấp nhận: giảm độ trễ tới 100 ms (bao gồm việc loại bỏ dao động) trên một số tuyến, và tăng băng thông cho một Validator Solana trung bình lên gấp mười lần.
Hiện tại, DoubleZero đã chạy testnet với hơn 100 Validator, chiếm ~3 % tổng stake Mainnet, và dự kiến ra mắt Mainnet vào giữa tháng 9 / 2025. Sau khi DoubleZero chính thức hoạt động, sẽ mất vài tuần để các Validator “đuôi dài” trên Mainnet áp dụng mạng DZ; khi đó, các lập trình viên cốt lõi của Solana có thể bắt đầu tăng các giới hạn giao thức.
Cộng đồng Solana nên kỳ vọng thời gian đưa giao dịch vào khối (time‑to‑inclusion) sẽ được cải thiện rõ rệt khi ngày càng nhiều Validator Mainnet triển khai DZ trong tháng 9 và suốt quý IV / 2025.
Alpenglow
Alpenglow là giao thức đồng thuận hoàn toàn mới, hiện đại của Solana. Mô hình đồng thuận hiện tại cần 32 slot (~12,8 giây) để đạt finality; với Alpenglow, một khối sẽ được xác nhận chỉ trong 1–2 slot, tức khoảng 150 ms.
Alpenglow bao gồm một loạt thay đổi sâu rộng đối với cơ chế đồng thuận và lan truyền khối, nhằm giảm mạnh độ trễ end‑to‑end. Giao thức mới cũng dễ hiểu hơn so với mô hình đồng thuận hiện tại của Solana, giúp quá trình phát triển đơn giản hơn và mở đường thuận lợi cho các cải tiến tương lai như nhiều Leader đồng thời (MCL) và thực thi bất đồng bộ (Async Execution).
Anza đặt mục tiêu kích hoạt Alpenglow trên Mainnet vào cuối 2025 hoặc đầu 2026
Đọc thêm về Alpenglow tại đây và tại đây.
Asynchronous Program Execution (APE)

Asynchronous Program Execution (APE) loại bỏ bước “Replay” (lặp lại) trong chu trình then chốt của việc đưa giao dịch lên chuỗi, nhờ đó giảm độ trễ.
APE đã là mục tiêu của Solana suốt gần bốn năm qua, và với những đơn giản hóa trong đồng thuận do Alpenglow mang lại, phần lớn độ phức tạp cần thiết để triển khai APE—chủ yếu liên quan đến xử lý đặc biệt cho chương trình bỏ phiếu (vote program)—sẽ được loại bỏ.
Trong vài tuần gần đây, hàng loạt đề xuất SIMD mới đã được đệ trình hướng tới APE. Các SIMD 192, 290, 297, 298 và 301 chứa thêm chi tiết về cơ chế này. Anza dự kiến APE sẽ được kích hoạt trên Mainnet ngay sau khi Alpenglow triển khai, tức vào đầu hoặc giữa năm 2026.
Dài hạn: Multiple Concurrent Leaders and Protocol-Enforced Application Controlled Execution (ACE)
Kế hoạch dài hạn là những lộ trình nhắm tới mốc năm 2027 — tức các dự án hiện đang được các lập trình viên cốt lõi của Anza cùng nhiều nhóm trong toàn hệ sinh thái tích cực phát triển.
MCL và ACE
Để xây dựng những thị trường có thanh khoản cao nhất trên chuỗi, chúng ta cần hội đủ ba điều kiện:
- Chuỗi phải có dư địa băng thông để tiếp nhận toàn bộ thông tin liên quan đến thị trường theo thời gian thực ở tốc độ đường truyền.
- Chuỗi phải xác nhận giao dịch rất nhanh và sở hữu slot‑time (Tick Rate) còn nhanh hơn nữa.
- Chuỗi phải cho phép ứng dụng tự kiểm soát thứ tự thực thi giao dịch của chính mình, nhằm tạo điều kiện thử nghiệm các cấu trúc vi mô thị trường mới.
Trong một blockchain đơn Leader (hầu hết các chuỗi hiện nay đều như vậy), ở bất kỳ thời điểm nào chỉ một Leader quyết định quyền truy cập và thứ tự sắp xếp giao dịch trong “cửa sổ lãnh đạo” (Leader window) của họ. Điều này đồng nghĩa: nếu chuỗi muốn trao quyền sắp xếp giao dịch cho ứng dụng, nó phải trông cậy vào sự hợp tác của những Leader “thân thiện”. Trong một hệ thống toàn cầu, Permissionless, bạn không thể kỳ vọng mọi Leader đều “chơi đẹp” với các ứng dụng tài chính trị giá hàng tỷ đô la.

Multiple Concurrent Leaders (MCL) là lời giải cho bài toán “một Leader duy nhất”. Dù chuỗi có thể áp đặt việc xếp lại thứ tự trong giai đoạn Replay, biện pháp đó không ngăn được Validator chọn lọc giao dịch có lợi cho họ hoặc cảm những giao dịch khác để thao túng thứ tự cuối cùng vì mục đích riêng.
Để khắc phục tình trạng kiểm duyệt có chọn lọc này, cần tăng số lượng Leader có quyền thêm giao dịch vào chuỗi trong cùng một cửa sổ Leader. Khi một Leader cố tình chặn một giao dịch, Leader khác vẫn có thể đưa giao dịch đó vào, khiến không Leader nào có thể đơn phương kiểm soát kết quả thực thi cuối cùng.

Việc gộp các khối do nhiều Leader khác nhau tạo ra hết sức đơn giản: chỉ cần sắp xếp chúng theo mức phí ưu tiên (Priority Fee) giảm dần.

Khi các giao dịch trong khối đã được xếp lại theo thứ tự ưu tiên, ứng dụng tự động có nhiều khoảng linh hoạt để quyết định trình tự thực thi của riêng mình: chỉ việc đọc phí ưu tiên rồi kích hoạt logic điều kiện tương ứng. Cách bố trí này khiến việc ưu tiên xử lý lệnh hủy trở nên dễ dàng; nếu nhà phát triển sáng tạo, họ thậm chí có thể tổ chức đấu giá tuỳ ý ngay trong khối.

Đồng bộ hóa thông tin toàn cầu
Cơ chế nhiều Leader đồng thời cho phép Solana tiếp nhận thông tin từ khắp thế giới cùng lúc, nhanh hơn hạ tầng Colocation tập trung. Nhờ Smart Contract là ngôn ngữ đa dụng, các Market Maker giờ đây có thể kết hợp dữ liệu thời gian thực sinh ra ở New York và Tokyo vào chiến lược báo giá, chỉ bằng cách đọc hai luồng thông tin trong cùng một hợp đồng thông minh.
Đây là đặc tính của các Blockchain đa người đề xuất mà không máy chủ tập trung nào trên thế giới có thể tái tạo. Nói cách khác, Solana sẽ cung cấp cho Internet Capital Markets những công cụ độc nhất vô nhị của hệ phi tập trung, thứ mà các đối thủ tập trung không thể sao chép.