Constellation: Đề xuất về MCP trên Solana

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

• Constellation là đề xuất chính thức đầu tiên ở cấp giao thức nhằm triển khai Multiple Concurrent Proposers (MCP) trên một blockchain thực tế ở quy mô lớn.
• Constellation giới thiệu hai vai trò mới (tức proposer và attester) để hạn chế quyền tự quyết của leader trong quá trình xây dựng block. Khoảng 16 proposer hoạt động đồng thời theo chu kỳ 50ms, tập hợp các transaction thành những pslice được mã hóa xóa rồi phân phối cho 256 attester. Bản ghi chứng thực ràng buộc leader bằng mật mã với tập hợp transaction mà leader đưa vào. Nếu một pslice được đủ số lượng attester chứng thực, leader không thể loại transaction đó nếu không tạo ra một block không hợp lệ và bị mạng từ chối.
• Constellation có thuộc tính chống kiểm duyệt có chọn lọc: trong mỗi chu kỳ, hoặc tất cả transaction có mức phí cạnh tranh đều được đưa vào, hoặc không transaction nào được đưa vào.
• Các cuộc tấn công sắp xếp dựa trên nội dung hiển thị và thao túng thời điểm vẫn chưa được giải quyết. Transaction trong Constellation hiển thị với mọi proposer nhận được transaction tại thời điểm gửi. Do kiến trúc nhiều proposer của MCP, điều này thực tế có thể mở rộng các bề mặt tấn công thay vì thu hẹp chúng. Thiết kế hiện tại thừa nhận rằng các thủ thuật độ trễ dựa trên thời gian không thể bị trừng phạt.
• Constellation tái cấu trúc các khoản phí hiện có—phí đưa vào tương ứng với phí cơ sở hiện nay, còn phí sắp xếp tương ứng với phí ưu tiên hiện tại. Thay đổi kinh tế đáng kể hơn là hoạt động hiện đi qua các dịch vụ đưa transaction vào block ngoài giao thức và các thỏa thuận phí off-chain sẽ quay lại giao thức. Việc lựa chọn vai trò theo trọng số stake đồng nghĩa với động lực tập trung hiện tại vẫn tiếp diễn, và chưa thể mô hình hóa tác động ròng lên từng validator cho đến khi SIMD sau cùng của Constellation được công bố.
• MCP làm tăng độ trễ trình tự nhưng giảm độ trễ đưa vào. Vòng attester, cửa sổ chu kỳ 50ms và quá trình tập hợp batch đều làm tăng thời gian so với đường gửi trực tiếp đến TPU hiện nay. Hiện tại, độ trễ cao hơn với những validator đóng gói ngay transaction từ TPU và thấp hơn với những validator trì hoãn việc này. Với Constellation, các transaction hợp lệ có được bảo đảm đưa vào trong một giới hạn xác định và được giao thức thực thi.
• Constellation được thiết kế rõ ràng là không tương thích với các mô hình Proposer-Builder Separation (PBS). Khi bản ghi chứng thực đã hạn chế quyền tự quyết của leader, không còn gì để một builder chuyên biệt bán. Cách tiếp cận này thể hiện một triết lý hoàn toàn khác với cách Ethereum hiện xử lý MEV.
• Chưa có benchmark thực nghiệm trong điều kiện mạng thực tế. Dữ liệu quan trọng nhất mà Anza có thể cung cấp là dự báo so sánh độ trễ của slot 200ms giữa giao thức hiện tại và Constellation. Cho đến khi có dữ liệu này, cộng đồng vẫn đang tranh luận về những đánh đổi chưa thể định lượng. 
• Constellation được xây dựng trên Alpenglow, giao thức đang hướng tới ra mắt mainnet vào quý 3 năm 2026.

Giới thiệu

Dù sa mạc chẳng có mấy cây thùa, Brennan Watt, CEO của Anza, đã đến sa mạc California để công bố Constellation—một đề xuất đưa Multiple Concurrent Proposers (MCP) lên Solana. Đây là nâng cấp tham vọng nhất về mặt cấu trúc và có thể là đề xuất MCP ở cấp giao thức có ảnh hưởng sâu rộng nhất mà bất kỳ blockchain thực tế nào đưa ra cho đến nay. Đề xuất này hướng tới giải quyết thế độc quyền tạm thời của leader đối với việc sắp xếp transaction và giá trị có thể khai thác mà thế độc quyền đó tạo ra. Constellation dân chủ hóa không gian block trên Solana.

Bài viết này phân tích phản biện Constellation: những gì đề xuất giải quyết, những gì chủ động để lại sau và những gì thực sự vẫn chưa có lời giải. Chúng tôi giới thiệu một khung ba lớp để đánh giá khả năng chống kiểm duyệt, so sánh Constellation với bối cảnh MCP hiện tại và xem xét liệu những đánh đổi mà đề xuất này mang lại có tương thích với bản sắc hiệu năng mà Solana đã xây dựng hay không.

Bài viết giả định người đọc đã có kiến thức về Alpenglow. 

Vấn đề mà Constellation giải quyết

Transaction là huyết mạch của Solana. Chúng được nhóm lại và ghi vĩnh viễn lên mạng dưới dạng block. Nhưng quá trình quyết định transaction nào được đưa vào các block đó và theo thứ tự nào không phải là một quá trình trung lập. 

Thế độc quyền sản xuất block của leader

Việc sản xuất block luân phiên theo lịch leader, trong đó mỗi lần một validator chịu trách nhiệm sản xuất block trong một khoảng thời gian nhất định.

Trong thời gian này, transaction được chuyển tiếp trực tiếp đến Transaction Processing Unit (TPU) của leader, nơi leader thường nhận được chúng trước bất kỳ ai khác.

Leader nắm giữ một vị thế quyền lực khác thường. Cụ thể, họ có thể quan sát các transaction đến trước khi chúng hiển thị công khai.

Leader có thể quyết định không đưa một số transaction vào, tùy ý sắp xếp lại chúng hoặc thêm transaction của riêng mình.

Đây là một đặc điểm cấu trúc trong cách cơ chế đồng thuận một leader hiện hoạt động và xuất hiện ở nhiều mức độ khác nhau trong gần như mọi blockchain Proof of Stake đang vận hành thực tế hiện nay.

Việc Solana không có mempool công khai làm bất cân xứng này rõ nét hơn thay vì giảm bớt nó. Mempool công khai của Ethereum cho phép các bên tham gia phần nào thấy được các transaction đang chờ xử lý, qua đó tạo ra một sân chơi tương đối bình đẳng giữa những tác nhân tinh vi đang cạnh tranh để khai thác việc sắp xếp transaction.

Trên Solana, lợi thế thông tin của leader khó bị cạnh tranh hơn do bản chất của cơ chế chuyển tiếp transaction. 

Maximal Extractable Value (MEV)

Trong điều kiện bình thường và với các validator trung thực, quyền lực này phần lớn không bị khai thác. Tuy nhiên, vấn đề là validator là những tác nhân kinh tế duy lý. Khi Solana trưởng thành và hoạt động tài chính tiếp tục tăng trưởng, lợi nhuận có thể thu được từ việc khai thác thế độc quyền tạm thời của leader cũng tăng theo. Một validator chọn không khai thác vị thế này đơn giản là đang bỏ tiền lại trên bàn. Những node hành xử đúng bị đặt vào thế bất lợi về kinh tế—một bất lợi khuyến khích họ làm suy giảm chất lượng của chính hệ thống mà họ tham gia.

Khoản lợi nhuận có thể khai thác này được gọi là Maximal Extractable Value (MEV), thuật ngữ lần đầu được Daian và cộng sự định nghĩa chính thức trong Flash Boys 2.0 dưới tên Miner Extractable Value, trước khi được áp dụng cho các mạng Proof of Stake. Khái niệm này bao gồm mọi thứ từ kinh doanh chênh lệch giá và giao dịch chạy trước đến tấn công sandwich, kiểm duyệt có chọn lọc và bất kỳ chiến lược nào khai thác lợi thế thông tin cũng như vị thế của leader so với những người dùng có transaction được họ xử lý.

Phản ứng chính của ngành đối với MEV là mô hình Proposer-Builder Separation (PBS), được triển khai trên Ethereum thông qua MEV-Boost. Trong PBS, các builder chuyên biệt cạnh tranh để xây dựng những block tối đa hóa giá trị có thể khai thác, còn proposer chỉ cần chọn block sinh lời cao nhất để sản xuất. Đây là cách định hình lại vấn đề theo hướng thực dụng nhằm dân chủ hóa quyền tiếp cận MEV và phân phối lại lợi ích từ MEV trên toàn bộ tập validator, thay vì tập trung vào những tác nhân tinh vi nhất, bởi mô hình này giả định rằng việc khai thác MEV là không thể tránh khỏi.

Vấn đề của cách định hình này là PBS không giảm tác hại đối với người dùng—việc khai thác vẫn diễn ra, chỉ có đối tượng hưởng lợi thay đổi. PBS giải quyết một số tác động tiêu cực của MEV đối với các node mạng, nhưng không giảm tác hại đối với người dùng mạng.

Solana cũng có mối quan hệ đang phát triển với MEV. Sự kết hợp giữa thời gian tạo block nhanh, gửi trực tiếp đến TPU và một tập validator cạnh tranh đã tạo ra một bối cảnh MEV riêng biệt, đặc trưng bởi spam, đấu giá phí ưu tiên và việc sắp xếp lại transaction ở cấp validator. Block engine của Jito có thể được xem là phần nào tương tự MEV-Boost, vì nó cung cấp một cơ chế đấu giá off-chain, trong đó các searcher đặt giá cho việc sắp xếp transaction và lợi nhuận được chia sẻ giữa validator và staker. Nói cách khác, giống PBS, Jito quản lý và phân phối lại MEV theo cách dân chủ hơn thay vì loại bỏ hoàn toàn.

Constellation hướng tới khắc phục điều này. Thay vì chấp nhận thế độc quyền của leader và quản lý hệ quả của nó, Constellation tìm cách kiềm chế thế độc quyền về mặt cấu trúc, khiến những hình thức MEV gây hại nhất trở nên bất khả thi ngay từ thiết kế. Sách trắng của Constellation mô tả tham vọng này là “cơ sở hạ tầng của Thị trường Vốn Internet, một không gian chung cho hoạt động kinh tế, nơi người dùng có thể tin tưởng rằng cấu trúc thị trường là công bằng.”

Các thị trường tài chính truyền thống cố gắng thực thi những biện pháp bảo vệ tương tự thông qua quy định và giám sát theo thẩm quyền pháp lý. Những biện pháp bảo vệ này mang tính phản ứng, không đồng đều và nhiều lần được chứng minh là không đủ. Tham vọng của Constellation là thực thi tính công bằng ở cấp giao thức để không thể bị lách hoặc áp dụng có chọn lọc. Constellation hướng tới thực hiện điều này bằng cách triển khai Multiple Concurrent Proposers (MCP) trên Solana.

Multiple Concurrent Proposers

Trong một blockchain một leader truyền thống, một validator chịu trách nhiệm sản xuất từng block. Validator này (tức leader) tạm thời nắm toàn quyền kiểm soát việc đưa transaction vào và sắp xếp chúng. Trong thời gian validator này được ủy quyền sản xuất block, tất cả bên tham gia khác trong mạng đều là những người quan sát thụ động. Cuối cùng, leader quyết định transaction nào được đưa vào và theo thứ tự nào.

Thiết kế này hấp dẫn vì tính đơn giản. Một validator duy nhất giám sát việc sản xuất block đồng nghĩa với việc không có chi phí điều phối, không có các đề xuất xung đột cần giải quyết và có một mô hình trách nhiệm rõ ràng. Tuy nhiên, điều đó cũng tạo ra một điểm khai thác duy nhất. Thế độc quyền tạm thời của leader là nguyên nhân gốc rễ của MEV, và mọi biện pháp giảm thiểu lớn cho đến nay đều chấp nhận cấu trúc này rồi tìm cách quản lý hệ quả của nó.

Multiple Concurrent Proposers (MCP) là một nhóm thiết kế giao thức phá vỡ thế độc quyền này ở cấp cấu trúc. Thay vì luân phiên đến một leader duy nhất nắm độc quyền sản xuất block, MCP cho phép nhiều node đồng thời đề xuất transaction. Không proposer nào kiểm soát toàn bộ tập transaction. Thay vào đó, các đề xuất của họ được kết hợp, thường bởi một vai trò lắp ráp bị giới hạn quyền, theo các quy tắc của giao thức.

Người dùng gửi một transaction đến nhiều proposer cùng lúc không còn phụ thuộc vào một node duy nhất vì giờ đây họ có nhiều đường độc lập để transaction được đưa vào. Một leader cố gắng loại bỏ transaction của họ phải đối mặt với thực tế rằng các proposer khác đã thấy nó và các attester đã chứng thực nó. Một leader duy nhất lắp ráp block cuối cùng, nhưng quyền tự quyết của họ bị giới hạn chặt chẽ.

Đánh đổi chính của MCP là độ phức tạp trong điều phối. Việc cho phép nhiều node đồng thời đề xuất transaction làm nảy sinh những câu hỏi mà thiết kế một leader hoàn toàn tránh được. Các transaction xung đột được giải quyết thế nào khi hai proposer đưa vào cùng một transaction? Thứ tự giữa các đề xuất được xác định ra sao? Làm thế nào để ngăn một proposer tinh vi lợi dụng các quy tắc kết hợp? Điều này làm tăng đáng kể độ phức tạp của giao thức—các đội ngũ phải xử lý những thách thức điều phối liên quan đến vai trò node mới, logic lập lịch, các giả định mật mã và chế độ lỗi, tất cả đều đòi hỏi kiểm thử nghiêm ngặt.

Cần diễn đạt chính xác ở đây vì MCP thường được dùng khá lỏng lẻo trong toàn ngành để chỉ nhiều thiết kế có các thuộc tính khác biệt đáng kể. Ở mức thấp, MCP cung cấp khả năng chống kiểm duyệt theo xác suất—một transaction được gửi đến nhiều proposer sẽ khó bị kiểm duyệt hơn vì việc đó đòi hỏi sự phối hợp giữa nhiều node. Ở mức cao hơn, MCP có thể cung cấp khả năng chống kiểm duyệt về mặt cấu trúc—leader không thể về mặt toán học tạo ra một block kiểm duyệt transaction đã được một số lượng đủ lớn attester chứng thực. Đây là mục tiêu của Constellation, và khác biệt này cực kỳ quan trọng đối với các ứng dụng tài chính cần bảo đảm chắc chắn.

Constellation: Cách hoạt động

Constellation là một giao thức triển khai MCP trên Solana. Giao thức này bổ trợ cho Alpenglow: Alpenglow xử lý đồng thuận (tức tính an toàn, tính sống và tính chung cuộc), còn Constellation xử lý cấu trúc thị trường—ai được đề xuất transaction, cách các đề xuất đó được xác nhận và leader được phép làm gì với chúng. Constellation tạo ra payload mà Alpenglow hoàn tất.

Kiến trúc

Constellation giới thiệu hai vai trò mới vào ngăn xếp giao thức của Solana, mỗi vai trò có một trách nhiệm riêng, đồng thời điều chỉnh vai trò của leader và validator.

Proposer là điểm tiếp nhận transaction. Tại bất kỳ thời điểm nào, khoảng 16 proposer hoạt động đồng thời, được chọn ngẫu nhiên theo stake và luân phiên sau mỗi 32 chu kỳ (tức ~1,6 giây). Người dùng gửi transaction trực tiếp đến một hoặc nhiều proposer do họ lựa chọn. Proposer có thể tự do chấp nhận hoặc từ chối bất kỳ transaction nào, với điều kiện các transaction được chấp nhận phải hợp lệ. Không có quy tắc giao thức nào bắt buộc đưa transaction vào ở giai đoạn này; bảo đảm chống kiểm duyệt xuất hiện ở phần sau của quy trình. Mỗi proposer hoạt động theo chu kỳ 50 mili giây. Trong mỗi chu kỳ, proposer tập hợp các transaction đã chấp nhận vào một cấu trúc gọi là pslice—tiền tố “p” không được phát âm và chỉ dùng để phân biệt với slice của Alpenglow. Pslice được mã hóa xóa thành 256 phần nhỏ hơn gọi là pshred, và mỗi pshred được phân phối đến một trong 256 attester đang hoạt động. Mã hóa xóa sử dụng ngưỡng khôi phục là 64, nghĩa là bất kỳ 64 trong số 256 pshred nào cũng đủ để tái tạo toàn bộ pslice. Mỗi pshred chứa một cam kết hàm băm mật mã đối với danh sách transaction đầy đủ, bảo đảm leader không thể thay thế bằng các transaction khác hoặc thay đổi thứ tự trong pslice sau khi attester đã phê duyệt.

Attester nhận pshred từ một proposer rồi lập tức chuyển tiếp chúng đến khoảng ~2 leader tiếp theo để dự phòng lỗi hoặc vắng mặt, đồng thời ghi lại hàm băm cam kết của pslice đã nhận. Vào cuối mỗi chu kỳ, attester ký một chứng thực—một tuyên bố có tính ràng buộc mật mã, liệt kê mọi hàm băm cam kết pslice mà họ quan sát được trong chu kỳ đó. Chứng thực này được gửi đến leader và đóng vai trò là bản ghi bằng chứng giới hạn những transaction mà leader có thể đưa vào. Bản ghi này được tính theo trọng số stake và có chữ ký, nghĩa là không thể bị giả mạo hoặc âm thầm bỏ qua. 

Leader trong Constellation cũng chính là leader của Alpenglow—node chịu trách nhiệm sản xuất block cuối cùng đi vào cơ chế đồng thuận. Điểm khác biệt trong Constellation là quyền tự quyết của leader bị bản ghi chứng thực giới hạn chặt chẽ. Constellation thực thi hai ngưỡng riêng biệt. Để chứng thực tổng hợp hợp lệ, ít nhất 60% attester phải tham gia. Nếu không đạt ngưỡng này, toàn bộ block sẽ bị bỏ qua. Trong số đó, bất kỳ pslice nào được ít nhất 40% attester chứng thực đều phải được leader đưa vào. Nếu không, block tạo ra sẽ không hợp lệ và bị mạng từ chối. Thiết kế hai ngưỡng này tách biệt tính hợp lệ ở cấp block với việc đưa vào theo từng proposer. Nói cách khác, leader có thể tạo một block hợp lệ ngay cả khi dữ liệu của một số proposer không đến được đủ số attester, nhưng không thể loại bỏ có chọn lọc những proposer có dữ liệu đã đến đủ số attester. Sau khi tổng hợp tất cả pslice đã được chứng thực thành một batch, leader truyền batch đó đến validator thông qua Rotor của Alpenglow. 

Validator nhận các batch từ leader qua Rotor và thực thi theo pipeline khi từng batch đến. Khi đã nhận đầy đủ block, validator đối chiếu nó với bản ghi chứng thực để xác nhận rằng mọi pslice đã được chứng thực đều có một nội dung gửi tương ứng trong block. Chỉ khi mọi bước kiểm tra đều đạt, validator mới bỏ phiếu hoàn tất block; nếu kiểm tra thất bại, validator sẽ bỏ phiếu để bỏ qua toàn bộ khoảng thời gian của leader bằng lời gọi TrySkipWindow. 

Chu kỳ và block

Chu kỳ là đơn vị thời gian cơ bản của Constellation. Đây là một cửa sổ 50 mili giây được suy ra từ thời gian thực UTC bằng cách chia dấu thời gian Unix tính theo nano giây cho 50.000.000. Điều quan trọng là các chu kỳ không căn chỉnh với slot của Alpenglow. Một slot chứa nhiều chu kỳ, và các batch được tạo trong những chu kỳ đó cấu thành payload của block do leader tạo. Sự khác biệt này quan trọng vì chu kỳ 50ms là nhịp kinh tế (tức cửa sổ mà trong đó khả năng chống kiểm duyệt được thực thi), còn slot vẫn là đơn vị đồng thuận của Alpenglow.

Sách trắng quy định mức dung sai cho độ lệch đồng hồ giữa proposer và attester, đồng thời điều chỉnh cửa sổ chứng thực tương ứng. Để minh họa vì sao điều này quan trọng, giả sử đồng hồ của một proposer chạy nhanh hơn tập attester 5ms. Pshred của proposer này có thể đến attester sớm hơn dự kiến so với ranh giới chu kỳ, giúp các transaction trong pslice đó có cửa sổ dài hơn một chút để tích lũy chứng thực. Ngược lại, proposer có đồng hồ chạy chậm có thể thấy pshred của mình đến muộn đến mức hoàn toàn nằm ngoài cửa sổ chứng thực, dù proposer đã gửi chúng “đúng giờ”. Trong môi trường trung tâm dữ liệu sử dụng các công cụ như chrony hoặc bộ thu GPS, việc đồng bộ đồng hồ là hoạt động thông thường và độ lệch thường dưới một mili giây, hoàn toàn nằm trong giới hạn dung sai của Constellation. Điều đáng lo ngại là Constellation đưa vào một biến số mới không tồn tại trong mô hình thời gian thuần logic của Alpenglow, và SIMD sau cùng của Constellation nên quy định các giới hạn giám sát cho biến số này.

Khi Constellation tiến gần đến cuối một epoch, proposer và attester có thể tạm thời không chắc epoch tiếp theo đã bắt đầu hay chưa. Trong cửa sổ này, Constellation hoạt động đồng thời ở cả hai epoch với hai tập proposer và attester cùng hoạt động. Cơ chế đồng thuận của Alpenglow tự nhiên xác định chu kỳ nào thuộc epoch nào.

Vòng đời và phí transaction

Một transaction phải vượt qua bốn cổng trước khi được thực thi:

• Transaction phải được một proposer chấp nhận và đưa vào pslice.
• Pslice đó phải tích lũy đủ số chứng thực để được đưa vào batch của leader.
• Transaction phải có mức giá đủ cao để được chọn thực thi trong giới hạn tài nguyên tính toán của batch.
• Block chứa batch phải được cơ chế đồng thuận của Alpenglow xác nhận.

Mỗi transaction mang một mức giá (tức phí thực thi trên mỗi đơn vị tính toán) để xác định thứ tự của nó trong cùng một batch. Mức giá cao hơn được thực thi trước.

Constellation chia chi phí của một transaction thành hai khoản phí riêng biệt:

• Phí đưa vào.
• Phí sắp xếp.

Phí đưa vào là một khoản phí nhỏ, cố định dựa trên kích thước và số chữ ký của transaction. Khoản phí này được trả cho proposer đã đưa transaction vào pslice và được tính từ thời điểm transaction vượt qua ngưỡng chứng thực, bất kể cuối cùng transaction có được thực thi hay không. Khoản phí này tương tự phí cơ sở trong hệ thống hiện tại của Solana, nhưng có một lưu ý quan trọng: nếu người dùng gửi cùng một transaction đến ba proposer để dự phòng, họ phải trả phí đưa vào ba lần (tức một lần cho mỗi proposer), vì mỗi proposer đã độc lập thực hiện công việc đưa transaction vào. Do đó, nếu người dùng gửi cùng một transaction đến n proposer khác nhau để dự phòng, họ phải trả phí đưa vào n lần.

Phí sắp xếp là thành phần lớn hơn, dựa trên mức độ ưu tiên, được tính bằng tổng số đơn vị tính toán của transaction nhân với mức giá của nó. Khoản phí này chỉ được tính một lần vì transaction chỉ có thể được thực thi một lần, bất kể có bao nhiêu proposer đưa nó vào. Ví dụ, một transaction yêu cầu 200.000 đơn vị tính toán với mức giá 0,00001 SOL cho mỗi đơn vị tính toán sẽ trả phí sắp xếp là 2 SOL. Nếu cùng transaction đó được gửi đến bốn proposer để dự phòng, người dùng sẽ trả bốn khoản phí đưa vào cộng với một khoản phí sắp xếp duy nhất là 2 SOL. Phí sắp xếp được hoàn trả cho hệ sinh thái theo tỷ lệ stake của node—sách trắng để dành thiết kế của cơ chế này cho SIMD sau cùng.

Mọi account trả phí phải duy trì số dư dự trữ tối thiểu khoảng 0,001 SOL để ngăn chặn việc thao túng phí giữa các proposer hoạt động đồng thời. Điều này bảo đảm phí đưa vào luôn có thể được thanh toán, ngay cả khi nhiều proposer đồng thời đưa vào các transaction tác động đến cùng một account.

Constellation và Alpenglow

Alpenglow là giao thức đồng thuận của Solana. Giao thức này xác định block nào hợp lệ, thứ tự hoàn tất của chúng và cách mạng phục hồi sau lỗi. Các thành phần Votor và Rotor thay thế Tower BFT cùng cơ chế truyền bá phiếu bầu dựa trên gossip, giúp giảm đáng kể thời gian đạt tính chung cuộc. Alpenglow không quy định ai đề xuất transaction hoặc cách xác định thứ tự trong một block.

Constellation là một lớp cấu trúc thị trường giới hạn những gì leader của Alpenglow được phép làm với các block mà họ lắp ráp—lớp này xác định ai đề xuất transaction và cách xác định thứ tự trong mỗi block. Các batch do Constellation tạo ra trở thành payload của block Alpenglow. Sau đó, Votor của Alpenglow công chứng các block đó theo những quy tắc bỏ phiếu được định trước. Hai giao thức được kết hợp sao cho Alpenglow cung cấp tính an toàn và tính sống, còn Constellation bảo đảm tính công bằng về thứ tự.

Khả năng kết hợp này cũng đồng nghĩa với việc Constellation kế thừa các giả định bảo mật của Alpenglow mà không làm suy yếu chúng. Constellation không thay đổi các bảo đảm của Alpenglow. Thay vào đó, trong mô hình thời gian dựa trên chu kỳ mới, Constellation bổ sung các bảo đảm và giả định mới cho vai trò proposer và attester, cũng như cho việc đồng bộ hóa theo thời gian thực UTC.

Constellation là đề xuất chính thức đầu tiên ở cấp giao thức nhằm triển khai MCP trên một blockchain có khả năng mở rộng và đang vận hành thực tế. Đây là một bước bổ sung quan trọng để đưa khả năng chống kiểm duyệt đến Solana—chương tiếp theo trong lộ trình giao thức mà Alpenglow mở ra.

Khả năng chống kiểm duyệt thực sự đòi hỏi điều gì

Các nghiên cứu về MEV từ trước đến nay đã tiếp cận vấn đề qua nhiều góc nhìn riêng biệt. Khi kết hợp lại, chúng tạo nên một bức tranh thống nhất hơn về những gì mà bất kỳ đề xuất chống kiểm duyệt nào thực sự cần giải quyết. Dựa trên hệ thống phân loại nền tảng của Eskandari và cộng sự về các cuộc tấn công chạy trước, khung hai thuộc tính chính thức của Garimidi và cộng sự dành cho các giao thức MCP, cùng phân tích của Landers và Marsh về các kênh MEV đặc thù của MCP, chúng tôi đề xuất chia bề mặt tấn công thành ba lớp riêng biệt, mỗi lớp đòi hỏi một nhóm giải pháp khác nhau. Đây là khung tổng hợp của riêng chúng tôi, được giới thiệu tại đây để đánh giá thiết kế của Constellation.

Lớp 1: Kiểm duyệt cứng

Kiểm duyệt cứng là khả năng một leader hoặc bên đề xuất từ chối đưa vào một giao dịch mà họ đã xác định. Đây là hình thức thao túng dễ nhận biết nhất và cũng là vấn đề mà Constellation giải quyết ở cấp độ cấu trúc. Với Constellation, một leader không thể tạo ra khối hợp lệ nếu khối đó loại bỏ một giao dịch có mức phí cạnh tranh và đã được một nhóm đủ lớn các bên chứng thực xác nhận. Việc này không cần slashing vì cơ chế thực thi đã được tích hợp trong kiến trúc.

Lớp 2: Sắp xếp khi nội dung hiển thị

Lớp thứ hai khó xử lý hơn. Dù không thể kiểm duyệt hoàn toàn, các bên đề xuất vẫn có thể quan sát nội dung giao dịch trước khi thứ tự cuối cùng được xác định và tìm cách khai thác khả năng hiển thị đó, chẳng hạn như sandwich một giao dịch lớn. Đây là điều Garimidi và cộng sự chính thức hóa thành thuộc tính che giấu—đối thủ không được phép nhìn thấy nội dung giao dịch trước khi chúng được xác nhận. Constellation triển khai khả năng che giấu một phần. Theo đó, giao dịch chỉ hiển thị với bên đề xuất nhận được giao dịch đó—không phải mọi bên đề xuất—và leader chỉ thấy nội dung giao dịch sau khi thời hạn của chu kỳ kết thúc. Điều này tốt hơn khả năng hiển thị hoàn toàn nhưng chưa đáp ứng đầy đủ thuộc tính che giấu của Garimidi và cộng sự, vốn yêu cầu nội dung giao dịch phải ẩn với tất cả các bên trước khi xác nhận. Bên đề xuất tiếp nhận vẫn có thể quan sát và khai thác nội dung của các giao dịch mà họ nhận được.

Mối lo sâu hơn với Constellation là MCP kết hợp với việc gửi giao dịch công khai có thể khuếch đại hành vi khai thác nội dung hiển thị. Hệ thống này cho phép mỗi bên đề xuất quan sát các giao dịch mình nhận được và khai thác khả năng hiển thị đó trong pslice của riêng mình. Bề mặt tấn công khác với mô hình một leader vì nhiều thực thể có thể nhìn thấy từng tập con riêng. Người dùng gửi cho một bên đề xuất duy nhất chỉ để lộ giao dịch với bên đó. Nhưng người dùng gửi cho nhiều bên đề xuất để tăng tính dự phòng sẽ mở rộng phạm vi lộ thông tin theo tỷ lệ tương ứng. Landers và Marsh đã chính thức hóa động lực này: việc sản xuất khối đồng thời tạo ra các trò chơi về thời điểm, cơ hội sao chép trong cùng một tick và sự thiếu vắng mang tính cấu trúc của một điểm nghẽn builder duy nhất—yếu tố hiện đang giới hạn số lần khai thác có thể tác động lên mỗi giao dịch nạn nhân. Phi tập trung hóa tập hợp bên đề xuất mà không xử lý khả năng hiển thị nội dung sẽ nhân rộng bề mặt tấn công MEV thay vì thu hẹp nó.

Phân tích của Landers và Marsh về các kênh MEV đặc thù của MCP giả định khả năng hiển thị nội dung rộng hơn mức Constellation cung cấp. Với cơ chế che giấu một phần của Constellation, mức độ khuếch đại hành vi khai thác nội dung hiển thị phụ thuộc vào chiến lược gửi giao dịch của người dùng chứ không phải hệ quả tất yếu của kiến trúc. Người dùng gửi cho một bên đề xuất đáng tin cậy duy nhất có mức độ lộ nội dung gần tương đương mô hình một leader hiện nay. Đổi lại, việc chỉ gửi cho một bên đề xuất làm mất tính dự phòng mà khả năng chống kiểm duyệt phụ thuộc vào. 

Lớp 3: Thao túng thời điểm và độ trễ

Lớp tinh vi nhất và khó trừng phạt nhất liên quan đến việc thao túng thời điểm và độ trễ. Với Constellation, một bên đề xuất có thể trì hoãn việc chuyển tiếp pshreds đến các bên chứng thực vừa đủ để giao dịch của đối thủ nằm ngoài cửa sổ chứng thực, hoặc khai thác độ lệch đồng hồ UTC để thao túng những giao dịch nào tích lũy đủ chứng thực. Lỗ hổng này được sách trắng Constellation thừa nhận trực tiếp: việc chuyển thông điệp muộn “không thể bị trừng phạt” vì không thể phân biệt với độ trễ mạng thực sự. Đây là lớp mà slashing có thể trở nên cần thiết và là câu hỏi mở chính mà SIMD sau này của Constellation cần giải quyết. 

Một giả định nền tảng trong thiết kế của Constellation là mối quan hệ giữa bên đề xuất và người dùng không ẩn danh—đó là tương tác lặp lại, trong đó niềm tin có thể đo lường và danh tiếng có ý nghĩa. Với khoảng 16 bên đề xuất hoạt động tại một thời điểm, người dùng thường xuyên bị một bên đề xuất đối xử không tốt có thể chuyển sang gửi cho một trong 15 bên còn lại. Dù điều này không tạo ra bất kỳ bằng chứng onchain nào để trực tiếp trừng phạt tác nhân xấu, nó vẫn tạo ra hậu quả kinh tế đối với những bên đề xuất lạm dụng vị thế của mình. Liệu áp lực danh tiếng này có đủ để ngăn chặn thao túng thời điểm so với một giải pháp như slashing hay không vẫn là câu hỏi mở, nhiều khả năng phụ thuộc vào mức độ minh bạch của hành vi bên đề xuất đối với người dùng theo thời gian. 

Tác động đối với trình xác thực và người dùng

Trình xác thực

Constellation phân phối lại các cơ hội MEV giữa các trình xác thực thay vì loại bỏ hoàn toàn chúng. Nguồn doanh thu dễ nhận biết và có thể khai thác trực tiếp nhất dành cho các leader hiện nay—tức kiểm duyệt cứng—bị vô hiệu hóa theo thiết kế. Tuy nhiên, nó được thay thế bằng một tập hợp các kênh thời điểm tinh vi hơn và khó trừng phạt hơn, có lợi cho những trình xác thực sở hữu ưu thế về độ trễ, đồng bộ đồng hồ chính xác và đủ năng lực để liên tục khai thác các cửa sổ chuyển tiếp pshred. Tác động ròng là thay đổi cách trình xác thực khai thác giá trị, chứ không phải giảm tổng bề mặt khai thác. Điểm cần lưu ý duy nhất là việc khai thác trở nên khó hơn đáng kể.

Constellation không tạo ra các luồng phí hoàn toàn mới mà chủ yếu tái cấu trúc những luồng hiện có. Phí đưa vào tương tự phí cơ sở hiện nay, còn phí sắp xếp tương ứng với phí ưu tiên hiện có. Tỷ lệ phân chia dự kiến sẽ gần giống thu nhập hiện tại của các trình xác thực. Khác biệt chủ yếu nằm ở vận hành. Cụ thể, các đơn vị vận hành tốt sẽ giành được nhiều phí đưa vào hơn khi đóng vai trò bên đề xuất, tạo ra một thang lợi ích dựa trên hiệu suất trong cơ chế kinh tế hiện tại thay vì một danh mục doanh thu riêng. Vai trò bên chứng thực không được trả thù lao riêng trong thiết kế hiện tại. Lý do là, giống như việc tham gia Turbine hiện nay, vai trò này được kỳ vọng sẽ được thực hiện vì mang lại lợi ích ròng cho mạng. Thay đổi kinh tế đáng kể hơn nằm ở hoạt động hiện đi qua các dịch vụ đưa giao dịch vào khối ngoài giao thức, các phiên đấu giá dựa trên thị trường và thỏa thuận phí off-chain; những hoạt động này sẽ quay trở lại trong giao thức để mang lại lợi ích trực tiếp hơn cho các trình xác thực. Tuy nhiên, cho đến khi SIMD quy định cơ chế chính xác, tác động kinh tế ròng lên từng trình xác thực—đặc biệt là các trình xác thực nhỏ hơn, nơi cơ chế lựa chọn theo trọng số stake làm giảm tần suất được chọn làm bên đề xuất và chi phí hạ tầng làm tăng mức chi phí tối thiểu—vẫn là câu hỏi mở.

Các bên đề xuất và bên chứng thực được lựa chọn theo trọng số stake, nghĩa là những động lực tập trung đang định hình kinh tế trình xác thực cũng chi phối việc tham gia các vai trò này. Nếu một số ít trình xác thực có stake lớn chi phối việc lựa chọn bên đề xuất, bảo đảm chống kiểm duyệt vẫn nguyên vẹn về mặt hình thức, nhưng tính đa dạng thực tế của tập hợp bên đề xuất sẽ bị thu hẹp, dù vẫn là một bước tiến so với tình trạng hiện tại của Solana (tức chọn 1 trong n so với chọn 16 trong n). Giả định về tính độc lập bắt đầu suy yếu trong thực tế, ngay cả khi vẫn đúng trên lý thuyết. Đây là mối lo đáng lưu ý trước sự xuất hiện của các dịch vụ Validator-as-a-Service (VaaS), theo đó một thực thể duy nhất có thể vận hành nhiều trình xác thực có lượng stake lớn. Liệu SIMD có đưa vào cơ chế chống tập trung hoặc ưu đãi nào cho việc lựa chọn bên đề xuất hay không là một câu hỏi thiết kế có tác động trực tiếp đến độ vững chắc của các bảo đảm mà Constellation công bố. 

Người dùng

Lần đầu tiên, một giao dịch có mức phí cạnh tranh được gửi đến đủ số lượng bên đề xuất sẽ được bảo vệ bằng bảo đảm cứng ở cấp giao thức trước hành vi loại trừ có chọn lọc. Giờ đây, các ứng dụng tài chính có thể được xây dựng với những bảo đảm trước đây đơn giản là không tồn tại, qua đó thay đổi những gì chỉ có thể thực hiện trên Solana. 

Người dùng giao dịch tần suất cao và nhạy cảm với giá giờ đây phải gửi giao dịch đến nhiều bên đề xuất để có tính dự phòng. Mối lo là việc phi tập trung hóa tập hợp bên đề xuất mà không giải quyết khả năng hiển thị nội dung có thể làm tăng nguy cơ bị tấn công sandwich—mỗi bên đề xuất đều có thể quan sát và hành động dựa trên các giao dịch được gửi đến họ. Vì vậy, người dùng gửi cho nhiều bên đề xuất để dự phòng sẽ làm tăng tương ứng số bên nhìn thấy nội dung giao dịch. Điều này vốn dĩ loại bỏ điểm nghẽn một leader và phát tán ý định giao dịch đến một tập hợp đối thủ tiềm năng rộng hơn. Trong thực tế, người dùng tinh vi hơn sẽ cần phát triển các chiến lược gửi mới để cân bằng giữa tính dự phòng và mức độ lộ thông tin, nhiều khả năng bằng cách nhắm mục tiêu có chọn lọc đến các bên đề xuất dựa trên danh tiếng hoặc stake, thay vì sử dụng chiến lược gửi rộng rãi đến nhiều bên.

Riêng với các nhà tạo lập thị trường, bảo đảm đưa vào của Constellation loại bỏ rủi ro đối kháng rằng hạ tầng quyết định chất lượng thực thi. Phần còn lại chỉ là bất cân xứng thông tin, cũng chính là hồ sơ rủi ro mà các nhà tạo lập thị trường phải đối mặt tại những địa điểm giao dịch truyền thống tốt nhất hiện nay. Sự hội tụ này biến lập luận ủng hộ việc giảm độ trễ đưa vào trở nên cụ thể thay vì chỉ mang tính kỳ vọng. Chúng tôi thảo luận kỹ hơn về sự hội tụ này trong phần “Câu hỏi mở”.

Thay đổi ròng trong trải nghiệm cảm nhận của người dùng trung bình có thể không đáng kể, nhưng bảo đảm đưa vào là một cải thiện có ý nghĩa về độ tin cậy. Trong khi chờ các phép đo hiệu năng tương lai, tác động ròng lên độ trễ trình tự vẫn là một câu hỏi thực nghiệm còn bỏ ngỏ.

Toàn cảnh: So sánh Constellation

Sei Giga

Sei Giga là mô hình gần với Constellation nhất trong bối cảnh MCP hiện nay. Đây là một blockchain cấp độ sản xuất theo đuổi MCP như ưu tiên kiến trúc hàng đầu thay vì mục tiêu nghiên cứu trong tương lai. Việc so sánh hai hệ thống rất hữu ích vì chúng đưa ra những đánh đổi khác nhau ở cùng một lớp.

Nền tảng đồng thuận của Giga có tên Autobahn, một giao thức BFT đa bên đề xuất, trong đó mỗi trình xác thực vận hành “lane” đề xuất liên tục của riêng mình theo cách song song. Thay vì phụ thuộc vào một leader duy nhất, mỗi node liên tục phổ biến luồng đề xuất dữ liệu riêng trên các lane độc lập, còn lớp đồng thuận định kỳ cam kết một “tip cut”—ảnh chụp nhanh nhỏ gọn tổng hợp các đề xuất mới nhất từ mọi lane. Kiến trúc này khác với mô hình của Constellation, nơi khoảng 16 bên đề xuất được chọn hoạt động theo chu kỳ cố định 50ms. Mô hình dựa trên lane của Autobahn cho phép mọi trình xác thực duy trì một lane đề xuất liên tục, thay vì được chọn từ một tập con luân phiên theo trọng số stake, qua đó mở rộng đáng kể sự tham gia vào quá trình sản xuất khối.

Khác biệt quan trọng nhất liên quan đến việc sắp xếp khi nội dung hiển thị. Autobahn cho phép thực thi bất đồng bộ bằng cách tách việc sắp xếp giao dịch khỏi quá trình thực thi, một lựa chọn thiết kế mà Constellation trì hoãn. Như được thảo luận trong phần tiếp theo, thực thi bất đồng bộ thu hẹp bề mặt tấn công của việc sắp xếp khi nội dung hiển thị bằng cách ngăn bên đề xuất mô phỏng kết quả thực thi dựa trên một trạng thái cuối đã biết tại thời điểm sắp xếp.

Giga cung cấp khả năng chống kiểm duyệt theo xác suất, trong khi Constellation đưa ra bảo đảm mang tính cấu trúc. Niềm tin nền tảng của Giga là một giao dịch được gửi đến nhiều bên đề xuất sẽ khó bị kiểm duyệt hơn vì mỗi bên đề xuất hoạt động với thông tin không đầy đủ, và lợi ích của việc kiểm duyệt có thể mất đi nếu một bên đề xuất khác đưa giao dịch vào cùng tick. Trong khi đó, với Constellation, một leader loại bỏ giao dịch đã được chứng thực đầy đủ sẽ tạo ra khối không hợp lệ. Khả năng chống kiểm duyệt theo xác suất làm tăng chi phí kiểm duyệt, còn khả năng chống kiểm duyệt mang tính cấu trúc khiến việc kiểm duyệt không thể xảy ra về mặt mật mã. Đối với các ứng dụng tài chính mà cả hai giao thức đang hướng tới, sự khác biệt này rất quan trọng. 

Cần thẳng thắn về sự khác biệt trong tham vọng của hai thiết kế. Constellation là một đặc tả giao thức chứng minh các thuộc tính đúng đắn, xác định điều kiện lỗi, quy định ngưỡng quorum và được dự kiến trình thành đề xuất chính thức cho một mạng sản xuất có khả năng mở rộng với giá trị stake lên đến hàng tỷ. Sách trắng Sei Giga có định hướng khác, tập trung vào các tuyên bố về throughput và khả năng tương thích EVM, trong khi MEV và khả năng chống kiểm duyệt được xem là lợi ích phát sinh từ kiến trúc đa bên đề xuất thay vì các bảo đảm được đặc tả chính thức. Thực thi bất đồng bộ là đúng hướng, nhưng Giga không cung cấp mức độ bảo đảm chính thức về các ràng buộc sắp xếp, quorum của bên chứng thực hoặc điều kiện lỗi ngang với Constellation. Đây không hẳn là lời chỉ trích đối với lựa chọn trình tự của Giga mà phản ánh những bối cảnh khác nhau—Constellation đang được đề xuất trên blockchain sản xuất có throughput cao nhất thế giới, do đó đòi hỏi và cung cấp tiêu chuẩn đặc tả cao tương ứng.

Mô hình lý tưởng trong học thuật

Chuẩn lý thuyết cho thiết kế MCP là Nhiều bên đề xuất đồng thời: Tại sao và bằng cách nào (2025) của Garimidi và Neu thuộc a16z Crypto Research cùng Max Resnick thuộc Anza. Bài nghiên cứu đề xuất một giao thức MCP có hai thuộc tính mà các tác giả cho rằng mọi thiết kế chống kiểm duyệt đều phải đáp ứng: khả năng chống kiểm duyệt có chọn lọc và che giấu. Thuộc tính thứ nhất bảo đảm đối thủ không thể trì hoãn giao dịch có chọn lọc, còn thuộc tính thứ hai bảo đảm nội dung giao dịch vẫn được ẩn trước khi xác nhận. Đây là thiết kế MCP duy nhất trong các nghiên cứu hiện nay chính thức đạt được cả hai thuộc tính cùng lúc.

Cơ chế cho phép che giấu là HECC—Hiding Erasure-Correcting Code. Cơ chế này được tham số hóa sao cho bất kỳ T shred nào cũng không tiết lộ thông tin về lô giao dịch bên dưới, trong khi K + T shred cho phép tái tạo hoàn chỉnh. Chi tiết then chốt là các relay chỉ phát những shred được lưu trữ sau khi đồng thuận đã xác nhận những lô nào được đưa vào. Điều này ngăn mọi hành vi quan sát nội dung giao dịch trước khi xác nhận, qua đó loại bỏ hoàn toàn bề mặt tấn công sắp xếp khi nội dung hiển thị bằng một bảo đảm theo lý thuyết thông tin. 

Khi đối chiếu với khung đã xây dựng ở trên, thiết kế giao thức này là thiết kế duy nhất xử lý Lớp 1 bằng khả năng chống kiểm duyệt mang tính cấu trúc, Lớp 2 bằng che giấu và giới hạn Lớp 3 nhờ các bảo đảm chống kiểm duyệt do cơ chế che giấu cung cấp. Cả Constellation lẫn Giga đều chưa đạt được đầy đủ điều này.

Điều khiến phép so sánh này đặc biệt thú vị là Resnick, đồng tác giả của mô hình lý tưởng về lý thuyết, cũng là đồng tác giả của Constellation—một giao thức chủ động đi chệch khỏi mô hình đó. Điều này phản ánh đánh giá có chủ đích rằng thiết kế đầy đủ dựa trên HECC chưa thể triển khai trên mạng sản xuất ở quy mô của Solana, và khả năng chống kiểm duyệt mang tính cấu trúc là vấn đề cấp thiết hơn cần giải quyết trước. Bài nghiên cứu đóng vai trò sao Bắc Đẩu cho Constellation: một đặc tả chính thức về đích đến mà giao thức đang hướng tới, ngay cả khi chưa thể cung cấp tất cả cùng một lúc. 

Ethereum Braid

Braid là đề xuất MCP chính của Ethereum, do Max Resnick giới thiệu, và hiện đang được xem xét trong lộ trình Scourge của Ethereum cùng với thiết kế danh sách đưa vào FOCIL cạnh tranh. Việc đưa Braid vào đây không nhằm so sánh kỹ thuật mà chủ yếu để cung cấp bối cảnh; toàn ngành đang cố gắng giải quyết cùng những vấn đề cấu trúc nhưng từ các điểm khởi đầu khác nhau.

Braid triển khai MCP bằng cách cho phép nhiều bên đề xuất đồng thời xây dựng khối trên các chain song song trong cùng một slot, còn lớp thực thi sẽ tổng hợp, loại bỏ trùng lặp và sắp xếp giao dịch theo các quy tắc định trước. Braid không đưa thêm vai trò giao thức nào. Khác biệt quan trọng nhất là tính an toàn của Braid phụ thuộc nhiều vào mempool được mã hóa, khiến che giấu trở thành điều kiện tiên quyết thay vì vấn đề có thể trì hoãn. Braid vẫn là một đề xuất nghiên cứu chưa được triển khai và cộng đồng Ethereum chưa đạt đồng thuận về việc nên theo đuổi nó thay vì FOCIL hay không.

Điều Braid cuối cùng xác nhận là lập luận cấu trúc ủng hộ MCP vượt ra ngoài bất kỳ chain riêng lẻ nào. Cũng cần lưu ý rằng Resnick đã tham gia ba trong bốn dự án ở phần này. Đây có lẽ là tín hiệu rõ ràng nhất cho thấy Constellation là sản phẩm của quá trình tư duy bền bỉ, xuyên bối cảnh và nghiêm ngặt về mặt học thuật đối với một vấn đề lâu nay chưa có giải pháp đơn giản.

Lưu ý về PBS

Proposer-Builder Separation (PBS) đáng được đề cập ở đây như một đối trọng thay vì một thiết kế có thể so sánh trực tiếp. Trong khi mọi dự án ở phần này đều tìm cách giới hạn độc quyền tạm thời của leader ở cấp cấu trúc, PBS chấp nhận nó và tối ưu xung quanh nó để phân phối lại doanh thu MEV. Constellation hoàn toàn không tương thích với PBS—một khi quyền quyết định của leader bị hồ sơ chứng thực giới hạn, specialized builder không còn gì để bán. Việc PBS trở thành biện pháp giảm thiểu MEV chủ đạo trên Ethereum dù không làm gì để giảm thiệt hại cho người dùng chính là kiểu thất bại mà MCP được thiết kế để tránh.

Tiền lệ ngoài giao thức

Trước khi Constellation ra mắt, hệ sinh thái Solana đã mô phỏng một số khía cạnh của MCP ngoài giao thức. Ví dụ, Harmonic là một lớp tổng hợp xây dựng khối mở, liên tục thu thập và đánh giá các đề xuất khối từ nhiều builder độc lập rồi trình chúng cho các trình xác thực để lựa chọn cạnh tranh theo thời gian thực. Đây không phải MCP theo nghĩa chính thức vì không có khả năng chống kiểm duyệt do giao thức thực thi, quorum chứng thực hay ràng buộc mật mã đối với quyền quyết định của leader. Tuy nhiên, các trình xác thực chạy Harmonic đã lựa chọn giữa nhiều đề xuất khối đồng thời, chính là cơ chế cốt lõi mà MCP muốn đưa vào giao thức. Cùng với BAM, hai hệ thống này đại diện cho nỗ lực của hệ sinh thái nhằm giải quyết các vấn đề cấu trúc thị trường mà không chờ cơ chế thực thi ở cấp giao thức. Những hệ thống ngoài giao thức này cho thấy nhu cầu đối với các thuộc tính giống MCP đủ thực tế để các builder không chờ Constellation ra mắt.

Câu hỏi mở

Sách trắng của Constellation là một đặc tả giao thức. Tài liệu chứng minh các thuộc tính đúng đắn theo những giả định đã nêu và hợp lý khi để lại mọi vấn đề khác cho sau này, điều phù hợp với một đề xuất v0.9. Phần dưới đây không phải danh sách những thất bại của Constellation, mà là bản đồ về những vấn đề SIMD cuối cùng và các phiên bản tương lai cần giải quyết để đưa MCP lên Solana một cách hiệu quả. 

Những câu hỏi này không khó như nhau. Một số chỉ là công việc đặc tả—các quyết định thiết kế mà Anza có thể và nên giải quyết thông qua quy trình SIMD thông thường. Những câu hỏi khác là vấn đề mở thực sự mà cộng đồng nghiên cứu MCP rộng lớn hơn vẫn chưa giải quyết được, nhưng chúng ta phải nhận thức rõ khi tiên phong trở thành blockchain quy mô lớn đầu tiên triển khai MCP. Không SIMD đơn lẻ nào có thể giải quyết những vấn đề này. Việc phân biệt hai nhóm rất quan trọng, vì đánh đồng chúng có nguy cơ либо phóng đại các thiếu sót của Constellation hoặc đánh giá thấp khối lượng công việc còn lại.

Các hạng mục SIMD tương đối rõ ràng bao gồm:

• Phân phối phí: cách phân chia phí ưu tiên giữa các bên đề xuất, bên chứng thực và toàn bộ tập hợp trình xác thực đã được mô tả nhưng chưa được trình bày đầy đủ. Sách trắng cho biết phí ưu tiên được hoàn lại cho hệ sinh thái theo tỷ lệ stake, nhưng cơ chế phân phối chính xác giữa các bên đề xuất, bên chứng thực và trình xác thực chưa được xác định.
• Cơ cấu phần thưởng cho trình xác thực: cách các bên đề xuất được trả thưởng so với phần thưởng hiện có của trình xác thực, và liệu việc loại bỏ phí giao dịch biểu quyết trong Alpenglow có thay đổi bài toán đối với các trình xác thực nhỏ hơn hay không.
• Trình tự triển khai: Constellation phụ thuộc vào Alpenglow, dự kiến ra mắt vào quý 3 năm 2026. SIMD cần nêu rõ sự phụ thuộc này và giải quyết những gì xảy ra trong giai đoạn chuyển tiếp từ Alpenglow nguyên bản sang Constellation+Alpenglow. Có SIMD tiên quyết nào cần được triển khai trên mainnet trước không?
• Quản trị tham số vai trò: số lượng bên đề xuất (p ≈ 16), số lượng bên chứng thực (q ≈ 256), thời lượng chu kỳ (△cycle = 50ms) và các tham số khác trong Bảng 1 của sách trắng Constellation chỉ được trình bày như các đề xuất. SIMD cần quy định cách thiết lập, quản trị và có thể thay đổi các tham số này theo thời gian.

Các câu hỏi khó hơn, chẳng hạn như thực thi bất đồng bộ, slashing và quyền riêng tư ở lớp gửi, được đề cập trong những tiểu mục tiếp theo. Đây là các vấn đề mà cộng đồng nghiên cứu MCP đang tích cực giải quyết và chúng ta phải cân nhắc, bởi các lựa chọn thiết kế của Constellation có thể thu hẹp hoặc mở rộng con đường dẫn đến một số giải pháp sau cùng.

Thực thi bất đồng bộ

Trong mô hình thực thi đồng bộ, bên đề xuất nhận được giao dịch dưới dạng văn bản thuần hoặc có thể giải mã sớm theo mô hình gửi đơn giản sẽ biết nội dung giao dịch và có thể mô phỏng kết quả. Bên đề xuất có thể chạy giao dịch dựa trên trạng thái hiện tại để tính toán chính xác kết quả thực thi, bao gồm giá swap, thay đổi số dư tài khoản và các cơ hội arbitrage tiếp theo. Đây là yếu tố khiến tấn công sandwich có độ chính xác cao về mặt cơ chế. Kẻ tấn công có thể nhìn thấy các giao dịch swap lớn và tính toán số tiền cần chạy trước để tối đa hóa lợi nhuận.

Thực thi bất đồng bộ loại bỏ nửa sau của lợi thế đó, nhưng chỉ khi kết hợp với MCP. Nếu đồng thuận cam kết thứ tự giao dịch trước khi thực thi, một bên đề xuất nhìn thấy nội dung giao dịch sẽ không thể mô phỏng kết quả thực thi dựa trên trạng thái cuối đã biết, vì trạng thái đó chưa tồn tại tại thời điểm sắp xếp. Lợi thế thông tin thực tế thu hẹp từ “Tôi biết giao dịch này làm gì và được thực thi theo thứ tự nào” thành “Tôi biết đây là giao dịch gì, nhưng không biết nó sẽ có tác động ra sao so với tập hợp được sắp xếp cuối cùng”. Lợi ích này phụ thuộc vào việc bên đề xuất không kiểm soát thứ tự cuối cùng. Trong mô hình một leader, chỉ riêng thực thi bất đồng bộ không cung cấp khả năng bảo vệ này, vì leader vẫn có toàn quyền quyết định thứ tự và có thể đặt giao dịch của mình vào vị trí có lợi bất kể việc thực thi diễn ra khi nào. Chính sự kết hợp giữa thứ tự bị ràng buộc và thực thi trì hoãn mới thu hẹp bề mặt tấn công.

Lưu ý rằng thực thi bất đồng bộ không loại bỏ hoàn toàn Lớp 2. Một bên đề xuất tinh vi vẫn có thể suy luận theo phân loại. Chẳng hạn, họ vẫn có thể thấy một giao dịch tương tác với một pool thanh khoản cụ thể và suy ra hướng biến động có khả năng xảy ra mà không biết chính xác kết quả. Điều này nâng đáng kể rào cản đối với những hình thức khai thác mang tính cơ học và sinh lời cao nhất, đồng thời là con đường kiến trúc rõ ràng nhất để thu hẹp Lớp 2 mà không cần che giấu bằng mật mã ở lớp đồng thuận. Đáng chú ý, Sei Giga đã chọn cách tiếp cận này, theo đuổi thực thi bất đồng bộ như một ưu tiên kiến trúc hàng đầu cùng với MCP.

Điều này đặt ra một câu hỏi tự nhiên đáng suy ngẫm: Tại sao thực thi bất đồng bộ không được theo đuổi trước? Nó thu hẹp Lớp 2 và về nguyên tắc có thể được triển khai như một thay đổi khép kín ở lớp thực thi mà không đưa thêm độ phức tạp giao thức của MCP, bao gồm vai trò node mới, yêu cầu đồng bộ đồng hồ UTC, thiết kế slashing chưa được giải quyết và chi phí shredding tăng gấp đôi. 

Lập luận mạnh nhất cho trình tự này là thực thi bất đồng bộ và MCP giải quyết các vấn đề khác nhau. MCP cung cấp các ràng buộc thứ tự mang tính cấu trúc mà chỉ riêng thực thi bất đồng bộ không thể tạo ra—một trình xác thực không thể mô phỏng kết quả thực thi nhưng vẫn nhìn thấy nội dung giao dịch vẫn có thể tùy ý sắp xếp trong cửa sổ mà giao thức cho phép. Lý do theo đuổi MCP trước là nó giới hạn Lớp 1 ở cấp cấu trúc, trong khi Lớp 1 là mối đe dọa dễ nhận biết và cấp bách hơn về kinh tế. Việc tích hợp thực thi bất đồng bộ vào mô hình thực thi đồng bộ hiện có của Solana là bài toán kỹ thuật khó hơn so với xây dựng ngay từ đầu trên một chain mới, xét đến các giả định về khả năng kết hợp và kiến trúc program. Sei Giga có lợi thế được thiết kế cho thực thi bất đồng bộ ngay từ ngày đầu, còn Solana thì không. Sự bất cân xứng thực tế này có thể quan trọng không kém lập luận ưu tiên về mặt lý thuyết khi giải thích tại sao MCP được theo đuổi trước. Kiến trúc của Alpenglow cũng khiến MCP khả thi hơn so với dưới Tower BFT, điều chúng tôi phân tích trong tiểu mục tiếp theo về độ phức tạp giao thức.

Liệu trình tự đó có đúng hay không vẫn là một câu hỏi mở hợp lý. Constellation giữ nguyên Lớp 2, điều đáng lo ngại vì các vector tấn công mới mà MCP đưa vào Lớp 3. Đổi lại, điều này có thể làm các cuộc tấn công Lớp 2 sinh lời hơn vì hai bề mặt tấn công bổ trợ cho nhau. Ví dụ, một bên đề xuất nhìn thấy giao dịch DEX lớn có thể trì hoãn pshreds của giao dịch đó để đẩy nó ra khỏi cửa sổ lô hiện tại, đồng thời chạy trước bằng giao dịch của riêng mình trong cùng cửa sổ. Khả năng hiển thị của Lớp 2 và các trò chơi thời điểm ở Lớp 3 là những vũ khí gắn liền trong cùng một bề mặt tấn công và sẽ chỉ trở nên tinh vi hơn khi Solana trưởng thành.

Slashing

Thực thi bằng mật mã hoạt động tốt khi hành vi sai trái của một tác nhân tạo ra bằng chứng có thể xác minh, chẳng hạn như chữ ký xung đột, kiểm tra tính hợp lệ thất bại hoặc cam kết sai định dạng có thể chứng minh. Constellation giải quyết mối lo chống kiểm duyệt ở Lớp 1 rất gọn gàng vì leader loại bỏ giao dịch đã được chứng thực sẽ tạo ra khối không hợp lệ, và tính không hợp lệ đó có thể được chứng minh bằng toán học. Các trò chơi thời điểm và thao túng độ trễ không tạo ra bằng chứng tương tự. Khó khăn nằm ở chỗ loại hành vi sai trái này không thể phân biệt với độ trễ mạng trung thực khi xét từng hành động riêng lẻ. Hành vi sai trái tồn tại dưới dạng sự vắng mặt và không thể được chứng minh bằng mật mã. Đòn bẩy duy nhất hiện có là răn đe kinh tế, điều đòi hỏi slashing. 

Thách thức với slashing là cơ chế này theo truyền thống đòi hỏi hành vi vi phạm có thể chứng minh. Cơ chế nhân chứng lỗi của Constellation xử lý được trường hợp một bên đề xuất ký hai pshreds xung đột, cho phép xác định và loại bỏ họ. Tuy nhiên, thao túng độ trễ có chiến lược không tạo ra nhân chứng lỗi. Không equivocation, không ký hai lần, không dấu vết onchain. Một bên đề xuất chỉ trì hoãn việc chuyển tiếp pshreds vài mili giây một cách nhất quán và có chọn lọc sẽ không để lại gì để slashing. 

Nếu pshreds của một bên đề xuất liên tục đến các bên chứng thực trong vài mili giây cuối của cửa sổ chu kỳ—qua nhiều chu kỳ và đối với những giao dịch tình cờ cạnh tranh với giao dịch của chính bên đề xuất—một cơ chế slashing được đặc tả tốt có thể xem mẫu hành vi này là bằng chứng thao túng có hệ thống dù không có hành động đơn lẻ nào chứng minh được là ác ý. Slashing truyền thống không thể trực tiếp xử lý điều này. Ở dạng chuẩn, slashing đòi hỏi bằng chứng rõ ràng và độc lập, nhưng không tồn tại bằng chứng như vậy đối với một bên đề xuất chỉ trì hoãn chuyển tiếp vài mili giây. Điểm khác biệt nằm ở mẫu hành vi.

Đây là nơi tài chính truyền thống có thể cung cấp bài học hữu ích cho tài chính phi tập trung về cách cơ quan quản lý xử lý thao túng dựa trên độ trễ. Chẳng hạn, việc thực thi chống spoofing theo Đạo luật Dodd-Frank dựa vào việc phát hiện các mẫu thống kê, như tỷ lệ hủy trên khớp lệnh, phân bố thời điểm hủy và tương quan tác động giá, thay vì chứng minh ý định của từng lệnh riêng lẻ. Không trường hợp riêng lẻ nào có thể được chứng minh là cố ý. Tuy nhiên, mẫu hành vi thì có thể. Cùng logic đó được áp dụng vì tính đều đặn thống kê là khách quan ngay cả khi từng hành động riêng lẻ không khách quan. Đồng thời, động lực kinh tế để thao túng hiện diện trong tập hợp bên đề xuất không cần cấp phép cũng mạnh như giữa các trader tần suất cao trong tài chính truyền thống. Điểm phép so sánh không còn phù hợp nằm ở cơ chế thực thi. Dodd-Frank dựa vào cơ quan quản lý có quyền triệu tập, còn bối cảnh không cần tin cậy đòi hỏi cơ chế phát hiện và xử phạt phải được tích hợp ngay trong giao thức.

Chúng tôi đề xuất điều chỉnh fisherman nodes thành một cơ chế tiềm năng để giải quyết lỗ hổng này. Ban đầu được giới thiệu trong nghiên cứu của Vitalik về tính khả dụng dữ liệu, fisherman nodes có thể được điều chỉnh thành một nhóm quan sát viên theo dõi dữ liệu chứng thực qua nhiều chu kỳ và gửi bằng chứng gian lận thống kê đến một giao thức phân xử tích hợp sẵn. Một lần đến muộn riêng lẻ mang tính chủ quan. Tuy nhiên, mẫu được tính toán theo cách tất định qua n chu kỳ là khách quan. Đây cũng là nguyên lý nền tảng của bằng chứng gian lận trong optimistic rollups, nhưng được áp dụng cho hành vi thời điểm thay vì chuyển đổi trạng thái. Ngoài ra, một giao thức phân xử tích hợp cho bằng chứng gian lận thống kê không khác biệt hoàn toàn về bản chất so với công cụ quản trị mới đang được phát triển, vốn sẽ cho phép người stake ghi đè phiếu bầu của trình xác thực trong các đề xuất quản trị tương lai. Nếu Solana sẵn sàng xây dựng hạ tầng cho việc ghi đè phiếu bầu của người stake, nền tảng kỹ thuật cho hệ thống phân xử dựa trên fisherman có thể gần hơn chúng ta nghĩ.

Hướng nghiên cứu fisherman nodes này đáng tin cậy hơn so với việc mở rộng slashing chuẩn để bao phủ các hành vi không để lại dấu vết onchain đơn lẻ, đồng thời có thể đã phù hợp với hạ tầng quản trị mà giao thức đang phát triển. Dù vậy, bất kỳ đặc tả cụ thể nào cũng cần giải quyết ba hạn chế. Thứ nhất, phân tích thống kê dữ liệu thời điểm chứng thực qua hàng nghìn chu kỳ không hề đơn giản và có thể dễ dàng làm tăng yêu cầu phần cứng của trình xác thực. Điều này làm tăng chi phí vận hành và có nguy cơ khiến vai trò phát hiện gian lận tập trung vào một nhóm nhỏ tác nhân tinh vi. Thứ hai, mọi đặc tả ngưỡng phải đủ vững chắc để phân biệt biến động mạng thực sự với thao túng có chiến lược mà không quá bảo thủ đến mức tạo ra kết quả dương tính giả. Thứ ba, bản thân giao thức phân xử tạo ra một bề mặt tấn công mới, qua đó hệ thống dựa trên fisherman có thể bị thao túng bằng báo cáo phối hợp. Thiết kế của bất kỳ giao thức phân xử nào cũng cần tính đến điều này, có thể thông qua cơ chế khuyến khích giúp các bên tham gia nhỏ hơn có thể vận hành fisherman hoặc các cơ chế tổng hợp để phân phối tác vụ tính toán trên toàn bộ tập hợp fisherman.

Câu hỏi nghiên cứu cụ thể mà chúng tôi đặt ra là: Liệu có thể đặc tả một khung bằng chứng gian lận thống kê—xác định tham số ngưỡng, tính đến biến động mạng và cách quy mô hình phạt thay đổi—đủ vững chắc để ngăn chặn thao túng độ trễ có hệ thống, đủ thận trọng để tránh trừng phạt biến động trung thực và đủ đơn giản để chống lại hành vi thao túng của các đơn vị vận hành tinh vi hay không? Đây là một trong những vấn đề mở đòi hỏi kỹ thuật cao nhất trong các nghiên cứu MCP và cộng đồng nghiên cứu rộng lớn hơn vẫn chưa giải quyết được.

Che giấu

Slashing không phải giải pháp duy nhất cho các trò chơi thao túng thời điểm và độ trễ. Che giấu xử lý cả việc sắp xếp khi nội dung hiển thị lẫn thao túng thời điểm-độ trễ, những vấn đề mà cả thực thi bất đồng bộ lẫn slashing đều không thể tự giải quyết. Constellation triển khai che giấu một phần, tức nội dung giao dịch chỉ hiển thị với bên hoặc các bên đề xuất tiếp nhận và với leader sau thời hạn chu kỳ, nhưng không đạt thuộc tính che giấu đầy đủ. Bề mặt tấn công tăng theo số lượng bên đề xuất mà người dùng chọn để gửi giao dịch. Dù che giấu một phần thu hẹp bề mặt tấn công so với hiển thị hoàn toàn, nó không loại bỏ bề mặt này. Che giấu đầy đủ, trong đó không bên nào quan sát được nội dung giao dịch trước khi xác nhận, vẫn là vấn đề mở đối với Constellation.

Mô hình lý tưởng về lý thuyết là cách tiếp cận được Garimidi và cộng sự trình bày, sử dụng Hiding Erasure-Correcting Code (HECC) làm primitive. Không giống Reed-Solomon tiêu chuẩn của Constellation, HECC cung cấp bảo đảm theo lý thuyết thông tin rằng đối thủ thu thập ít hơn số shred theo ngưỡng sẽ không biết gì về nội dung giao dịch. Constellation chọn tiếp tục sử dụng cơ chế erasure coding hiện đang hoạt động trên Solana thông qua Turbine.

Diễn biến gần đây phù hợp nhất là Block Assembly Marketplace (BAM) của Jito, sử dụng Trusted Execution Environments (TEEs) để tạo mempool được mã hóa, nơi giao dịch được giữ riêng tư cho đến khi thực thi. BAM cho thấy nhu cầu thực tế đối với quyền riêng tư nội dung trên Solana đang tăng lên. Tuy nhiên, cơ chế che giấu dựa trên TEE cũng có hạn chế vì chuyển giả định tin cậy sang các nhà sản xuất phần cứng, một ràng buộc đáng kể đối với giao thức hướng đến hoạt động không cần tin cậy. Cần nghiên cứu kỹ lưỡng hướng sử dụng mã hóa ngưỡng để cung cấp một giải pháp thay thế có cơ sở nguyên tắc vững chắc hơn.

BAM có ý nghĩa vì đại diện cho nỗ lực ngoài giao thức nhằm giải quyết vấn đề hiển thị nội dung mà Constellation trì hoãn. Jito có vị thế vận hành để cung cấp quyền riêng tư giao dịch ở quy mô lớn thông qua BAM trước cả khi Constellation ra mắt. Điều này đặt ra câu hỏi liệu che giấu ở cấp giao thức còn cấp thiết hay không nếu giải pháp ở lớp ứng dụng đã có thể cung cấp tính năng đó. Câu trả lời hoàn toàn phụ thuộc vào các giả định tin cậy và liệu các nhà sản xuất phần cứng có được tin cậy “đủ mức” so với những gì giao thức có thể bảo đảm về lý thuyết hay không. Dù vậy, đây không thể được xem là giải pháp vĩnh viễn. Hướng đi có khả năng xảy ra là BAM sẽ cung cấp quyền riêng tư trong ngắn hạn, còn các phiên bản Constellation sau này sẽ nghiên cứu mã hóa ngưỡng như một giải pháp thay thế dài hạn.

Đối với một giao thức muốn trở thành hạ tầng của Thị trường vốn Internet, che giấu một phần là bước tiến đáng kể nhưng chưa phải đích đến. Khoảng cách còn lại là sự khác biệt giữa một cấu trúc thị trường công bằng và một cấu trúc chỉ đơn thuần bớt bất công hơn cấu trúc đang tồn tại hiện nay. 

Độ phức tạp của giao thức

Constellation là bản nâng cấp có tham vọng lớn nhất về mặt cấu trúc từng được đề xuất cho Solana kể từ khi mạng ra đời. Nó đưa vào ba vai trò node mới, một mô hình thời gian mới phụ thuộc vào việc đồng bộ đồng hồ UTC thực, các lượt erasure coding mới, các loại thông điệp mới và các chế độ lỗi mới. Tất cả đều được xây dựng trên Alpenglow, vốn chưa hoạt động trên mainnet. Câu hỏi liệu đây có phải thời điểm thích hợp để gánh thêm độ phức tạp này hay không là vấn đề nghiêm túc, cần được xem xét kỹ hơn thay vì chỉ dựa vào sự lạc quan.

Trong quá khứ, Solana từng mang tiếng xấu vì nhiều sự cố ngừng hoạt động ảnh hưởng đến mạng trong năm 2021 và 2022. Các sự cố này có điểm chung—chúng xuất phát từ khó khăn cố hữu khi phân tích các trường hợp biên trong một giao thức mới, có throughput cao dưới tải thực tế. Hơn hai năm hoạt động liên tục mà mạng đạt được kể từ đó là một cột mốc thực sự, được tôi luyện qua quá trình lặp lại đầy khó khăn. Thành tích này tạo cơ sở để tin tưởng vào độ trưởng thành của Solana. 

Hiện nay, mọi thay đổi cấp giao thức có quy mô như Constellation đều cần được triển khai đồng thời trên cả Agave và Firedancer. Điều này đòi hỏi hai đội ngũ phát triển độc lập phải thống nhất về ngữ nghĩa giao thức, các trường hợp biên và giả định thời gian còn mới với cả hai. Chỉ riêng việc đạt được điều này cho Alpenglow đã rất phức tạp, và Constellation sẽ tiếp tục gia tăng độ phức tạp đó. Đây không phải lập luận phản đối việc tiếp tục. Thay vào đó, nó cho thấy SIMD cuối cùng của Constellation phải bao gồm kế hoạch rõ ràng cho việc triển khai đa client.

Các tổ chức tài chính đang bắt đầu chuyển hoạt động lên onchain. Hậu quả của một sự cố ngừng hoạt động nghiêm trọng hiện lớn hơn đáng kể so với năm 2021, cả về tổn hại danh tiếng lẫn kinh tế. Với tư cách cộng đồng, chúng ta cần thẳng thắn về độ phức tạp mà Constellation đưa vào. SIMD cuối cùng phải được tiếp cận với mức độ nghiêm ngặt tương xứng với một hệ thống tài chính toàn cầu. 

Tất nhiên, câu hỏi tại sao phải triển khai ngay lúc này sẽ xuất hiện. Chúng ta có thực sự muốn chấp nhận rủi ro của một bản nâng cấp như vậy không? Chẳng phải có thể thực hiện các nâng cấp tăng dần theo thời gian để giảm nhẹ thay đổi này sao? Chẳng hạn, những nghiên cứu nói trên về thực thi bất đồng bộ và slashing cho thấy có thể tồn tại một phương án tăng dần. Một phiên bản lộ trình Constellation trong đó hệ sinh thái hưởng lợi từ việc triển khai theo giai đoạn nhiều bản nâng cấp bổ trợ là hoàn toàn khả thi. Việc xem đây là sự thận trọng hay chủ nghĩa giảm tốc không chỉ là vấn đề kỹ thuật mà còn là câu hỏi về giá trị, và những người có lý trí có thể bất đồng. Chúng ta đang xây dựng một hệ thống ý nghĩa không kém gì đang xây dựng một hệ thống tài chính.

Điều này đã xảy ra trong thực tế. Anza đã xác nhận rằng slot 200ms và cửa sổ leader hai slot sẽ ra mắt trước Constellation. Điều này có nghĩa Solana sẽ có những cải thiện hiệu suất đáng kể, xử lý một số lo ngại về độ trễ trình tự mà cộng đồng đã nêu và sẽ được thảo luận trong phần tiếp theo, mà không cần toàn bộ độ phức tạp của MCP. Nếu slot 200ms đưa đường dẫn xác nhận của Solana đủ gần với chi phí dự kiến của Constellation để chi phí biên của MCP ở mức thấp, lập luận chính trị sẽ dễ thuyết phục hơn đáng kể. Tuy nhiên, nếu các bên giao dịch hiện tại xem 200ms là “đủ tốt”, mức độ cấp thiết của Constellation sẽ giảm. Các dự báo độ trễ so sánh giữa slot 200ms đơn thuần với slot 200ms kết hợp Constellation có thể giúp cộng đồng đánh giá chi phí tăng thêm so với bảo đảm tăng thêm. Dĩ nhiên, chúng ta sẽ phải chờ SIMD cuối cùng và phương án triển khai được đề xuất của Constellation.

Lập luận mạnh nhất để tiếp tục là cơ hội mà Alpenglow tạo ra. Constellation kế thừa mô hình bảo mật của Alpenglow, sử dụng Rotor làm lớp phổ biến dữ liệu và hưởng lợi từ việc loại bỏ độ phức tạp của Tower BFT. Chi phí biên để thêm MCP lên Alpenglow thấp hơn chi phí bắt đầu lại từ đầu với một thiết kế đồng thuận tương lai. Chờ đợi không phải không có chi phí, xét đến việc các đối thủ đang nghiên cứu cách đưa MCP lên onchain và thực tế rằng trì hoãn khả năng chống kiểm duyệt sang một chu kỳ nâng cấp tương lai chắc chắn sẽ tạo ra độ phức tạp và trở lực chính trị riêng.

Nếu không phải bây giờ thì khi nào?

Độ phức tạp này là hợp lý, nhưng tính hợp lý đó phải được chứng minh bằng đặc tả nghiêm ngặt, triển khai theo giai đoạn và xác thực thực nghiệm các tuyên bố về độ trễ và băng thông mà cộng đồng hiện mới chỉ tranh luận dựa trên lý thuyết. 

Constellation có phù hợp với IBRL không?

Độ trễ trình tự và độ trễ đưa vào

Phản ứng ban đầu của cộng đồng Solana đối với Constellation có thể nói là rất phân cực. Phản ứng này đã làm nổi bật một cuộc tranh luận quan trọng cần câu trả lời chính xác thay vì mang tính ngoại giao. Cách diễn đạt gay gắt nhất đến từ bài đăng của Cavey, cho rằng “MCP và IBRL về cơ bản không tương thích”. Cavey lập luận rằng MCP trực tiếp và chắc chắn làm giảm băng thông cũng như tăng độ trễ nhằm cải thiện cấu trúc thị trường. Phản hồi của Toly cũng trực tiếp không kém: “Bạn sai rồi. Không có cách nào giảm độ trễ đưa vào nếu không có MCP.”

Về mặt kỹ thuật, cả hai đều đúng; họ đang đo lường những thứ khác nhau.

MCP giảm độ trễ đưa vào và tăng độ trễ trình tự. Đây không phải cùng một thuộc tính, và việc đánh đồng chúng là nguồn gốc của phần lớn sự nhầm lẫn trong cuộc tranh luận hiện tại.

Độ trễ trình tự là thời gian từ khi giao dịch được gửi đến khi được thực thi. Chỉ số này vốn dĩ tăng dưới MCP vì vòng chứng thực, cửa sổ chu kỳ 50ms và bước lắp ráp lô đều bổ sung thời gian không tồn tại trong đường dẫn gửi TPU hiện tại đến một leader hợp tác. Nhận định rằng các tác nhân hợp lý gửi giao dịch đến nhiều bên đề xuất sẽ tiêu thụ nhiều băng thông hơn là chính xác. Nhận định rằng cửa sổ hợp nhất làm tăng độ trễ cũng chính xác. Đây đều là chi phí thực cần được đo lường và trình bày với cộng đồng như những đánh đổi để loại bỏ kiểm duyệt cứng.

Độ trễ đưa vào là khoảng thời gian được bảo đảm mà trong đó một giao dịch hợp lệ, có mức phí cạnh tranh sẽ được đưa vào. Trong mô hình một leader hiện nay, bảo đảm này về cơ bản không có giới hạn. Cụ thể, leader muốn trì hoãn hoặc loại bỏ một giao dịch nhất định có thể làm vậy và không có cơ chế giao thức nào ngăn cản. Độ trễ mà người dùng đang trải nghiệm đã bao gồm mọi ma sát từ việc giữ lại, lập lịch và các trò chơi thời điểm, cũng như thứ tự có chọn lọc do leader áp đặt. Lập luận phản biện rằng thời gian xác nhận trong thực tế bao gồm cả độ trễ từ những trò chơi này, nên trải nghiệm ròng của người dùng có thể được cải thiện, là đúng hướng theo cách diễn giải này và được hỗ trợ bởi các cuộc thảo luận cộng đồng hiện đang diễn ra trên X. 

Câu hỏi thực sự là nên tối ưu loại độ trễ nào.

FIFO so với FCFS so với FBO

Trước khi xem xét nên tối ưu loại độ trễ nào, cần hiểu một cuộc tranh luận liên quan mà cộng đồng đang đồng thời xử lý: liệu MCP có tương thích với FIFO hay không.

FIFO (First In, First Out, tức vào trước ra trước) là nguyên tắc sắp thứ tự chung, trong đó các giao dịch được xử lý theo thứ tự chúng đến. Umberto đã phân tích rất kỹ rằng câu trả lời vốn dĩ có nhiều sắc thái. MCP có thể tạo ra cơ chế được gọi là “FIFO xác suất”, nhưng chỉ trong những điều kiện hạ tầng cụ thể. Về cơ bản, nếu người dùng ở đủ gần nhiều bên đề xuất để tránh bị kiểm duyệt, và các bên đề xuất đó đủ gần các bên chứng thực để nhanh chóng đạt ngưỡng chứng thực 40% nhằm bảo đảm giao dịch được đưa vào, thì trên thực tế người dùng sẽ trải nghiệm cơ chế đưa vào theo FIFO. Nghĩa là giao dịch của họ được đưa vào trước khi bất kỳ đối thủ nào có thời gian quan sát và phản ứng. Cuộc đua kết thúc tại thời điểm giao dịch được đưa vào thay vì khi được thực thi. Trong những điều kiện đó, MCP xấp xỉ FIFO như một đặc tính tự phát thay vì một quy tắc giao thức.

Vấn đề là hạ tầng hiện tại của Solana không đáp ứng các điều kiện đó. Stake tập trung ở một số ít khu vực, nghĩa là quá trình hình thành số đại biểu cần thiết bị thắt nút do phải tiếp cận các cụm stake dày đặc. Sự tập trung này tạo ra một khoảng thời gian để bên quan sát có “lợi thế địa lý” chạy trước một giao dịch đang được truyền đi. Việc triển khai Constellation có đi kèm với mức độ phân bố địa lý và mật độ bên chứng thực cần thiết cho FIFO xác suất hay không cũng quan trọng không kém bản thân thiết kế giao thức. Một giao thức bảo đảm khả năng chống kiểm duyệt nhưng lại cho phép chạy trước dựa trên độ trễ do hạ tầng phân bố thưa thớt sẽ không mang lại sự công bằng thị trường như sách trắng đã hứa hẹn.

Một câu hỏi có liên quan nhưng khác biệt là liệu Constellation có thể triển khai FCFS nhưng đã chọn không làm vậy hay không. Trong khi FIFO là một đặc tính tự phát của hạ tầng, FCFS (First Come, First Served, tức đến trước được phục vụ trước) là một quy tắc giao thức cụ thể bảo đảm giao dịch đến đầu tiên được xử lý theo cách tất định. Cần lưu ý rằng Constellation thực sự sắp thứ tự một cách tất định—các giao dịch được sắp xếp theo phí ưu tiên trong từng lô—nên câu hỏi không phải là liệu thứ tự có được giao thức thực thi hay không, mà là thời điểm đến có nên quyết định thứ tự đó so với phí ưu tiên hay không.

Cuộc tranh luận gần đây đã làm nổi lên một phản đối căn bản hơn so với vấn đề được nêu ban đầu—FCFS có thể hoàn toàn không thể thực thi trong bối cảnh không cần niềm tin. Các trình xác thực có thể đơn giản khai sai thứ tự giao dịch đến mà không để lại bất kỳ dấu vết nào trên chuỗi. Đây cũng là vấn đề thiếu bằng chứng khiến hành vi thao túng thời điểm không thể bị phạt cắt giảm theo nghĩa truyền thống, và có thể đòi hỏi các giải pháp sáng tạo hơn (ví dụ: phương pháp phát hiện mẫu thống kê được phát triển trong tiểu mục về phạt cắt giảm). Một quy tắc giao thức mà trình xác thực trung thực sẽ tuân theo còn trình xác thực không trung thực có thể âm thầm bỏ qua không phải là một bảo đảm có ý nghĩa. Điều này định hình lại việc Constellation không triển khai FCFS: thay vì một lựa chọn thiết kế cần được giải thích, đó là sự thừa nhận rằng với một tập hợp trình xác thực không cần cấp quyền, FCFS có thể chưa thể được triển khai trên Solana như một đặc tính giao thức cứng, ít nhất là theo các giả định hiện tại. Nếu FCFS thực sự không thể thực thi trong một tập hợp trình xác thực không cần cấp quyền theo các giả định hiện tại, thì nhiệm vụ của SIMD là nêu rõ ràng hạn chế này và giải thích vì sao sắp thứ tự theo phí ưu tiên là lựa chọn thiết kế mặc định đúng đắn. Nếu để cộng đồng tranh luận về FCFS như thể đây là một phương án khả thi mà Constellation đã chọn không triển khai, thay vì xác định nó là một đặc tính có thể không triển khai được, thì sẽ càng gây thêm xung đột trong cộng đồng.

Sắp thứ tự theo phí ưu tiên trong một khoảng thời gian cố định không phải là một sự thỏa hiệp mới. Cơ chế này được gọi là đấu giá theo lô thường xuyên (FBA), một thiết kế vi cấu trúc thị trường nhận được sự ủng hộ đáng kể từ giới học thuật. Chẳng hạn, Budish, Cramton và Shim lập luận trong Cuộc chạy đua vũ trang giao dịch tần suất cao: Đấu giá theo lô thường xuyên như một giải pháp thiết kế thị trường (2015) rằng đấu giá theo lô trong thời gian rời rạc với giá khớp lệnh đồng nhất sẽ loại bỏ cuộc chạy đua tốc độ do thị trường thời gian liên tục tạo ra. Cơ chế này thay thế cạnh tranh dựa trên độ trễ bằng cạnh tranh dựa trên giá. Dựa trên đó, Constellation giới thiệu cơ chế sắp thứ tự theo lô cố định (FBO) dựa trên phí ưu tiên. Vì vậy, chu kỳ 50ms của Constellation hiện thực hóa cơ chế này: các giao dịch cạnh tranh bằng phí thay vì thời điểm đến trong từng lô, và tất cả giao dịch trong cùng một lô được áp dụng cùng một cách xử lý thứ tự. Đây chính xác là nhóm ứng dụng đã được xác định trước đó là chưa tồn tại ở quy mô lớn trên Solana. 

Các cuộc tranh luận về FIFO, FCFS và FBO phần lớn đều xoay quanh cùng một mối quan ngại cốt lõi: ai kiểm soát thứ tự sau khi khả năng chống kiểm duyệt được bảo đảm, và liệu cấu trúc thị trường mà Constellation muốn tạo ra có thực sự công bằng hay chỉ bớt bất công hơn so với hiện nay. Constellation loại bỏ hình thức thao túng dễ nhận thấy nhất. Điều gì thay thế nó sẽ phụ thuộc vào những lựa chọn mà sách trắng dành lại cho SIMD quyết định.     

Vậy chúng ta đang tối ưu hóa điều gì?

Độ trễ sắp thứ tự quan trọng nhất đối với các ứng dụng giao dịch hiện có (tức AMM, bộ phận tự doanh và CLOB). Những ứng dụng này được thiết kế dựa trên giả định rằng bên nhanh nhất và cạnh tranh nhất về phí sẽ thắng, đồng thời đã xây dựng hạ tầng theo đó. Giao dịch chỉ nên bị giới hạn bởi các định luật vật lý, qua đó mang lại trải nghiệm người dùng vượt trội trên Solana. Với một số người dùng này, Constellation là một bước lùi ở chỉ số quan trọng nhất đối với họ. Mối lo ngại là Solana có thể đang lặp lại sai lầm chí mạng mà Ethereum từng mắc phải: ưu tiên cấu trúc thị trường hơn hiệu năng, điều có thể khiến hoạt động thực thi rời khỏi chuỗi. Đây là một rủi ro chính đáng cần được thảo luận.

Đối với các ứng dụng tài chính mà Constellation được thiết kế để hỗ trợ (tức đấu giá trên chuỗi, sổ lệnh có bảo đảm đưa vào đáng tin cậy và các giao thức DeFi chống kiểm duyệt), độ trễ đưa vào mới là chỉ số phù hợp. Một lệnh giới hạn có thể bị chạy trước hoặc trì hoãn có chọn lọc mang lại bảo đảm yếu hơn so với lệnh kiểu sàn giao dịch, bất kể thời gian xác nhận danh nghĩa nhanh đến đâu. Solana giờ đây có thể hỗ trợ các ứng dụng giao dịch đấu giá theo lô với giá khớp lệnh đồng nhất, trong đó thứ tự không nên ảnh hưởng đến giá thực thi. Đây là nhóm ứng dụng gần như chưa tồn tại trên Solana hiện nay, chính vì chưa có các bảo đảm đưa vào. Có thể nói Constellation quá chú trọng một thiết kế được tối ưu hóa cho nhóm người dùng chưa tồn tại ở quy mô lớn trên Solana, gây bất lợi cho những người dùng hiện có; một lập luận đã được các cộng tác viên cốt lõi đưa ra.   

Mối lo về độ trễ sắp thứ tự cần được đặt trong bối cảnh Solana hiện đang mất đi vị thế đáng kể trong giao dịch hợp đồng vĩnh cửu vào tay Hyperliquid—một sàn giao dịch hợp đồng vĩnh cửu có bộ sắp thứ tự tập trung, được xây dựng chuyên biệt, không hề che giấu việc thiếu tính phi tập trung nhưng lại cung cấp trải nghiệm thực thi hấp dẫn dưới một mili giây mà các nhà giao dịch và ứng dụng chuyên nghiệp yêu cầu. Hyperliquid đã chủ ý chọn xây dựng một sản phẩm mà giới chuyên nghiệp thực sự muốn sử dụng, đổi lại bằng việc hy sinh những nguyên tắc cốt lõi thực sự khiến crypto là “crypto.” Rủi ro ngầm của Constellation là việc bổ sung chi phí giao tiếp và các vòng chứng thực vào lộ trình xác nhận cũng là sự đánh đổi mà Hyperliquid đang thực hiện, nhưng theo hướng ngược lại. Những người chỉ trích đánh giá tiêu cực và lên tiếng mạnh mẽ về việc hy sinh bất kỳ lợi thế hiệu năng tiềm năng nào hiện giúp Solana cạnh tranh với các ứng dụng giao dịch tập trung, trong khi vẫn chưa có các ứng dụng tài chính đủ để biện minh cho sự đánh đổi đó.

Đây không phải là mối lo nên bị gạt bỏ quá dễ dàng. Có thể diễn đạt lại câu hỏi trước đó về việc nên tối ưu hóa độ trễ sắp thứ tự hay độ trễ đưa vào thành câu hỏi liệu Solana có đủ khả năng thực hiện sự đánh đổi đó hay không, xét đến nguồn cạnh tranh hiện tại.

Tuy nhiên, ở đây còn có một vấn đề sâu xa hơn. Phép so sánh với Hyperliquid cho thấy ý nghĩa của IBRL có thể đã thay đổi theo thời gian. Động lực ban đầu của Toly và Raj khi xây dựng Solana là khả năng chống kiểm duyệt: “Để các sản phẩm DeFi có thể thu hút hàng tỷ người dùng và thiết bị, chúng ta cần mở rộng khả năng chống kiểm duyệt….Đây là vấn đề quan trọng nhất cần giải quyết và là toàn bộ động lực để chúng tôi xây dựng Solana.” IBRL xuất hiện muộn hơn nhiều như cách diễn đạt sứ mệnh đó dưới góc độ kỹ thuật: xây dựng đủ nhanh để một mạng phi tập trung có thể vượt qua hạ tầng tập trung ở những chỉ số quan trọng. Kể từ đó, IBRL đã tự mang một ý nghĩa lạc quan về công nghệ và trở nên phổ biến trong tinh thần văn hóa của Solana. Nó vừa là mệnh lệnh kỹ thuật, vừa là dấu hiệu nhận diện văn hóa, vừa là lời cầu nguyện thế tục. Với nhiều người, nó đã trở thành mục tiêu thay vì phương tiện, trong đó việc giảm thiểu độ trễ sắp thứ tự là mục đích tự thân, tách rời khỏi mục tiêu chống kiểm duyệt mà nó vốn được thiết kế để phục vụ.

Nếu sự dịch chuyển này đã xảy ra, và dường như đúng là vậy, Constellation sẽ vấp phải sự phản kháng mạnh mẽ về văn hóa. Đây không phải là một động lực mới, xét đến việc cộng đồng bác bỏ SIMD-228, một đề xuất giảm lạm phát gây tranh cãi đã không vượt qua cuộc bỏ phiếu quản trị. Ngay cả những đề xuất mang lại lợi ích rộng rãi nhất cũng có thể thất bại khi xung đột với những định kiến đã ăn sâu trong cộng đồng. Constellation phức tạp hơn vì chi phí băng thông và độ trễ của nó là có thật, nhưng tác động ròng đối với trải nghiệm người dùng vẫn chưa được định lượng. Sẽ là quá sớm để đưa ra kết luận chắc chắn theo bất kỳ hướng nào khi chưa có dữ liệu. Điều cộng đồng còn thiếu, và điều Anza cần cung cấp để tạo nên một SIMD thuyết phục, là dữ liệu thực nghiệm về lộ trình xác nhận trong các điều kiện mạng thực tế. Alpenglow không gặp phải vấn đề này vì phù hợp với IBRL: giảm 100 lần thời gian để giao dịch đạt trạng thái hoàn tất và tinh giản cơ chế đồng thuận. Lập luận cho Constellation khó tạo sức thuyết phục theo trực giác hơn, nhưng vẫn hoàn toàn xác đáng nếu các phép đo chuẩn trong tương lai chứng minh điều đó.

Có vẻ cộng đồng sẽ đánh giá một bản nâng cấp chống kiểm duyệt bằng chỉ số hiệu năng mà nó chưa bao giờ được thiết kế để tối ưu hóa. Câu hỏi hữu ích hơn là liệu sự đánh đổi có xứng đáng hay không. Có một chi phí thực tế và có thể đo lường: tăng thêm một phần độ trễ sắp thứ tự và băng thông để đổi lấy bảo đảm cứng do giao thức thực thi rằng không leader nào có thể loại trừ giao dịch một cách có chọn lọc. Đây là điều kiện tiên quyết cho các ứng dụng tài chính mà Solana hiện đang cố gắng thu hút.

Quan điểm của chúng tôi là Constellation phù hợp với IBRL nếu diễn giải đúng mục tiêu mà IBRL vốn luôn hướng đến. Việc cộng đồng có đi đến cùng kết luận hay không sẽ phụ thuộc ít hơn vào giá trị kỹ thuật và nhiều hơn vào việc có xây dựng được lập luận thực nghiệm cũng như giải thích rõ các lựa chọn thiết kế hay không.  

Kết luận

Constellation là đề xuất chính thức đầu tiên ở cấp giao thức nhằm đưa MCP vào một blockchain vận hành thực tế ở quy mô lớn. Nó giải quyết kiểm duyệt cứng về mặt cấu trúc, để các giao dịch có mức phí cạnh tranh và được một số đại biểu đủ lớn chứng thực không thể bị loại khỏi block hợp lệ. Bảo đảm mật mã này thay đổi những gì có thể được xây dựng trên Solana. 

Những gì Constellation chủ động để lại cho tương lai cũng quan trọng không kém. Việc sắp thứ tự khi nội dung hiển thị được giảm thiểu một phần nhờ mô hình gửi giao dịch của Constellation, trong đó chỉ bên đề xuất nhận giao dịch mới thấy nội dung giao dịch, nhưng bề mặt tấn công còn lại tăng theo số lượng bên đề xuất mà người dùng gửi đến. Thao túng thời điểm và độ trễ vẫn là vấn đề chưa được giải quyết lớn nhất và hiện không thể bị trừng phạt theo thiết kế hiện tại. Các hướng đi tiềm năng (tức thực thi bất đồng bộ, phạt cắt giảm và che giấu) đã được xác định nhưng chưa được quy định cụ thể, và mỗi hướng đều tạo ra những yếu tố phức tạp riêng. Sách trắng của Constellation trình bày trung thực về các giới hạn này, và SIMD sau cùng cũng nên như vậy.

Câu hỏi khó nhất mà Constellation đặt ra là liệu Solana có đủ khả năng chấp nhận những sự đánh đổi mà nó mang lại hay không. Có một chi phí thực tế và có thể đo lường về độ trễ sắp thứ tự cùng băng thông, nhưng vẫn chưa được định lượng. Đồng thời, các bảo đảm đưa vào cũng mang lại lợi ích thực tế nhưng chưa được đo lường, trong khi chưa có nền tảng ứng dụng đủ để biện minh cho chúng ở quy mô lớn. Cộng đồng đang được đề nghị đầu tư vào hạ tầng cho các ứng dụng tài chính mà phần lớn chưa tồn tại trên Solana hiện nay, với cái giá tiềm tàng là gây bất lợi cho những ứng dụng giao dịch đang tồn tại. Đây là tầm nhìn xa hay một bước đi quá sớm sẽ phụ thuộc vào dữ liệu mà cộng đồng chưa có.

Lập luận ủng hộ Constellation cuối cùng sẽ thành công hay thất bại dựa trên các phép đo chuẩn thực nghiệm trong tương lai dưới những điều kiện thực tế. Lộ trình xác nhận trông như thế nào khi chỉ có slot 200ms so với slot 200ms dưới Constellation là con số quan trọng nhất mà Anza có thể cung cấp. Cho đến lúc đó, cộng đồng vẫn đang tranh luận về những sự đánh đổi mà họ không thể định lượng.

Quan điểm của chúng tôi là Constellation đại diện cho bước đi đúng đắn tiếp theo trong lộ trình giao thức mà Alpenglow đã mở ra. Nó phù hợp với IBRL theo cách diễn giải về IBRL mà Solana ban đầu được xây dựng để phục vụ. Tuy nhiên, quan điểm này phụ thuộc vào việc SIMD có đạt được độ nghiêm ngặt xứng đáng với một hệ thống tài chính toàn cầu hay không—trong đặc tả, quá trình triển khai theo giai đoạn, kiểm thử và lập luận thực nghiệm được trình bày cho cộng đồng mà nó đề nghị chấp nhận.

Tài liệu bổ sung

• Budish, E., Cramton, P., và Shim, J. (2015). Cuộc chạy đua vũ trang giao dịch tần suất cao: Đấu giá theo lô thường xuyên như một giải pháp thiết kế thị trường. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., và cộng sự (2019). Flash Boys 2.0: Chạy trước, sắp xếp lại giao dịch và sự bất ổn đồng thuận trên các sàn giao dịch phi tập trung. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., và Clark, J. (2019). SoK: Sự gian dối minh bạch: Các cuộc tấn công chạy trước trên blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., và Resnick, M. (2025). Nhiều bên đề xuất đồng thời: Tại sao và bằng cách nào. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., và Wattenhofer, R. (2026). Solana Constellation: Thị trường vốn Internet. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. và Marsh, B. (2025). MEV trong các blockchain có nhiều bên đề xuất đồng thời. https://arxiv.org/abs/2511.13080
• Yakovenko, T., và Gokal, R. Các nhà phát triển blockchain đang tập trung vào sai vấn đề. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem