Constellation: Solana의 MCP 제안

실행 가능한 인사이트

• Constellation은 대규모 프로덕션 블록체인에 Multiple Concurrent Proposers(MCP)를 구현하기 위한 최초의 공식 프로토콜 수준 제안입니다.
• Constellation은 블록 구성에 대한 리더의 재량을 제한하는 두 가지 새 역할, 즉 제안자와 증명자를 도입합니다. 약 16명의 제안자가 50ms 주기로 동시에 작동하며, 트랜잭션을 소거 코딩된 pslice로 조합해 256명의 증명자에게 배포합니다. 증명 기록은 리더가 포함할 트랜잭션 집합을 암호학적으로 구속합니다. 충분한 수의 증명자가 pslice를 증명하면 리더는 네트워크가 거부할 무효 블록을 만들지 않고서는 해당 트랜잭션을 제외할 수 없습니다.
• Constellation은 선택적 검열 저항성을 제공합니다. 각 주기에서 수수료 경쟁력이 있는 트랜잭션은 모두 포함되거나 모두 제외됩니다.
• 콘텐츠가 노출된 상태의 순서 조작 및 타이밍 조작 공격은 여전히 해결되지 않았습니다. Constellation의 트랜잭션은 제출 시점에 이를 수신한 모든 제안자에게 보입니다. MCP의 다중 제안자 아키텍처로 인해 공격 표면이 줄어들기는커녕 오히려 넓어질 수 있습니다. 시간 기반 지연 시간 게임은 현재 설계에서 처벌할 수 없는 것으로 인정됩니다.
• Constellation은 기존 수수료를 재구성합니다. 포함 수수료는 현재의 기본 수수료에, 순서 수수료는 기존 우선순위 수수료에 대응합니다. 더 중요한 경제적 변화는 현재 프로토콜 외부의 랜딩 서비스와 오프체인 수수료 계약을 통해 흐르는 활동이 프로토콜로 돌아와야 한다는 점입니다. 지분 가중 역할 선정으로 기존 집중화 역학이 이어지며, Constellation의 최종 SIMD가 나오기 전에는 개별 검증인에 대한 순효과를 모델링할 수 없습니다.
• MCP는 순서 지연 시간을 늘리지만 포함 지연 시간은 줄입니다. 증명자 라운드, 50ms 주기 창, 배치 조합은 모두 현재의 직접 TPU 제출 경로보다 시간을 더 소모합니다. 현재 지연 시간은 TPU 트랜잭션을 즉시 패킹하는 검증인에서 더 높고, 이를 지연하는 검증인에서 더 낮습니다. Constellation에서는 유효한 트랜잭션에 프로토콜이 강제하는 제한된 포함 보장이 생깁니다.
• Constellation은 Proposer-Builder Separation(PBS) 모델과 명시적으로 호환되지 않습니다. 증명 기록이 리더의 재량을 제한하면 전문 빌더가 판매할 것이 남지 않습니다. 이 접근법은 Ethereum의 현재 MEV 접근법과 근본적으로 다른 철학을 나타냅니다.
• 현실적인 네트워크 조건에서의 실증 벤치마크는 아직 없습니다. Anza가 제공할 수 있는 가장 중요한 단일 데이터 포인트는 현재 프로토콜의 200ms 슬롯과 Constellation이 적용된 200ms 슬롯의 비교 지연 시간 전망입니다. 이 데이터가 나오기 전까지 커뮤니티는 정량화할 수 없는 절충안을 논의하게 됩니다. 
• Constellation은 2026년 3분기 메인넷 출시를 목표로 하는 Alpenglow 위에 구축됩니다.

소개

놀랍게도 Agave 식물은 하나도 없었지만, Anza CEO Brennan Watt는 Constellation을 공개하기 위해 캘리포니아 사막으로 향했습니다. Constellation은 Multiple Concurrent Proposers(MCP)를 Solana에 도입하기 위한 제안입니다. 지금까지 제시된 업그레이드 중 구조적으로 가장 야심 차며, 프로덕션 블록체인이 내놓은 프로토콜 수준 MCP 제안 중 가장 중대한 제안이라고도 할 수 있습니다. 트랜잭션 순서에 대한 리더의 일시적 독점과 여기서 발생하는 추출 가능 가치를 해결하려 합니다. Constellation은 Solana 블록 공간을 민주화합니다.

이 글은 Constellation이 해결하는 문제, 의도적으로 미룬 문제, 실제로 미해결 상태인 문제를 비판적으로 분석합니다. 검열 저항성을 평가하는 3계층 프레임워크를 소개하고, Constellation을 현재 MCP 생태계와 비교하며, 그 절충안이 Solana가 구축해 온 성능 정체성과 양립할 수 있는지 살펴봅니다.

Alpenglow에 관한 사전 지식이 있다고 가정합니다. 

Constellation이 해결하는 문제

트랜잭션은 Solana의 생명선입니다. 트랜잭션은 묶여 블록 형태로 네트워크에 영구 기록됩니다. 하지만 어떤 트랜잭션을 블록에 넣고 어떤 순서로 배치할지 결정하는 과정은 중립적이지 않습니다. 

블록 생성에 대한 리더의 독점

블록 생성은 리더 일정에 따라 순환하며, 특정 시간 창에는 한 명의 검증인이 블록 생성을 담당합니다.

이 시간 동안 트랜잭션은 리더의 Transaction Processing Unit(TPU)으로 직접 전달되며, 일반적으로 리더가 다른 누구보다 먼저 이를 받습니다.

리더는 이례적으로 강력한 위치를 차지합니다. 즉, 공개되기 전에 유입되는 트랜잭션을 관찰할 수 있습니다.

리더는 일부 트랜잭션을 포함하지 않거나, 순서를 임의로 바꾸거나, 자신의 트랜잭션을 추가할 수 있습니다.

이는 현재 단일 리더 합의가 작동하는 방식의 구조적 특성이며, 오늘날 거의 모든 프로덕션 Proof of Stake 블록체인에 정도의 차이는 있지만 존재합니다.

Solana에 공개 멤풀이 없다는 점은 이 비대칭을 완화하기보다 심화합니다. Ethereum의 공개 멤풀은 참여자에게 대기 중인 트랜잭션을 어느 정도 보여주므로, 트랜잭션 순서를 이용하려는 고도화된 주체들이 경쟁할 때 일종의 공정한 장을 만듭니다.

Solana에서는 트랜잭션 전달 방식의 특성상 리더의 정보 우위에 맞서기가 더 어렵습니다. 

최대 추출 가능 가치(MEV)

정상적인 조건과 정직한 검증인 아래에서는 이 권력이 대부분 악용되지 않습니다. 하지만 검증인은 합리적인 경제 주체입니다. Solana가 성숙하고 금융 활동이 계속 성장하면 리더의 일시적 독점을 악용해 얻을 수 있는 수익도 함께 증가합니다. 이 지위를 악용하지 않는 검증인은 돈을 포기하는 셈입니다. 올바르게 행동하는 노드는 경제적 불이익을 받으며, 이는 자신이 참여하는 시스템의 품질을 훼손하도록 유도합니다.

이렇게 추출할 수 있는 수익을 Maximal Extractable Value(MEV)라고 합니다. 이 용어는 Proof of Stake 네트워크에 적용되기 전 Daian 등이 Flash Boys 2.0에서 Miner Extractable Value로 처음 공식화했습니다. 차익거래와 프런트러닝부터 샌드위치 공격, 선택적 검열, 그리고 처리 대상 사용자의 트랜잭션보다 리더가 가진 정보 및 지위의 우위를 이용하는 모든 전략을 포괄합니다.

업계가 MEV에 대응해 온 주된 방식은 Ethereum에서 MEV-Boost로 구현된 Proposer-Builder Separation(PBS) 모델입니다. PBS에서는 전문 빌더가 추출 가능 가치를 극대화하는 블록을 구성하기 위해 경쟁하고, 제안자는 생성할 블록 중 가장 수익성이 높은 것을 선택하기만 합니다. 이 모델은 MEV 추출이 불가피하다고 가정합니다. 따라서 가장 고도화된 주체에게 수익을 집중하는 대신 MEV 접근을 민주화하고 그 수익을 검증인 집합 전체에 재분배하는 실용적 재구성입니다.

이 관점의 문제는 PBS가 사용자 피해를 줄이지 않는다는 점입니다. 추출은 여전히 발생하며 수혜자만 바뀝니다. PBS는 네트워크 노드에 미치는 MEV의 일부 부정적 영향을 해결하지만 네트워크 사용자의 피해는 줄이지 않습니다.

Solana도 MEV와의 관계가 계속 변화하고 있습니다. 빠른 블록 시간, 직접 TPU 제출, 경쟁적인 검증인 집합이 결합되어 스팸, 우선순위 수수료 경매, 검증인 수준의 트랜잭션 재정렬로 특징지어지는 고유한 MEV 환경이 형성되었습니다. Jito의 블록 엔진은 탐색자가 트랜잭션 순서에 입찰하고 수익을 검증인과 스테이커가 나누는 오프체인 경매 메커니즘을 제공한다는 점에서 MEV-Boost와 일부 유사합니다. 즉, PBS처럼 MEV를 완전히 없애는 대신 더 민주적인 방식으로 관리하고 재분배합니다.

Constellation은 이를 바로잡으려 합니다. 리더의 독점을 받아들이고 그 결과를 관리하는 대신 독점을 구조적으로 억제해 가장 해로운 형태의 MEV가 설계상 불가능하도록 합니다. Constellation 백서는 이 목표를 “사용자가 시장 구조의 공정성을 신뢰할 수 있는 보편적 경제 활동 장소인 Internet Capital Markets의 인프라”라고 표현합니다.

전통 금융 시장은 규제와 관할권의 감독을 통해 유사한 보호 장치를 시행하려 합니다. 이러한 보호는 사후 대응적이고 일관되지 않으며, 반복적으로 불충분하다는 사실이 드러났습니다. Constellation은 우회하거나 선택적으로 적용할 수 없도록 프로토콜 수준에서 공정성을 강제하려 합니다. 이를 위해 Solana에 *Multiple Concurrent Proposers(MCP)*를 구현합니다.

Multiple Concurrent Proposers

전통적인 단일 리더 블록체인에서는 각 블록을 한 명의 검증인이 생성합니다. 이 검증인, 즉 리더는 일시적으로 트랜잭션 포함과 순서를 독점적으로 통제합니다. 이 검증인이 블록 생성을 승인받은 동안 네트워크의 다른 모든 참여자는 수동적인 관찰자에 머뭅니다. 어떤 트랜잭션을 어떤 순서로 포함할지는 궁극적으로 리더가 결정합니다.

이 설계는 단순하다는 장점이 있습니다. 블록 생성을 한 명의 검증인이 담당하므로 조정 오버헤드가 없고, 충돌하는 제안을 해결할 필요가 없으며, 책임 모델도 명확합니다. 그러나 악용 지점이 하나로 집중됩니다. 리더의 일시적 독점은 MEV의 근본 원인이며, 지금까지의 주요 완화책은 모두 이 구조를 수용한 채 그 결과를 관리하려 했습니다.

Multiple Concurrent Proposers(MCP)는 이러한 독점을 구조적 수준에서 깨는 프로토콜 설계 유형입니다. 독점적인 블록 생성 권한을 가진 단일 리더를 순환시키는 대신 여러 노드가 동시에 트랜잭션을 제안할 수 있게 합니다. 어느 한 제안자도 전체 트랜잭션 집합을 통제하지 않습니다. 대신 일반적으로 제약을 받는 조합자 역할이 프로토콜 규칙에 따라 제안을 결합합니다.

트랜잭션을 여러 제안자에게 동시에 제출한 사용자는 더 이상 단일 노드에 의존하지 않습니다. 포함될 수 있는 독립적인 경로가 여러 개 생기기 때문입니다. 트랜잭션을 제외하려는 리더는 다른 제안자들이 이미 이를 확인했고 증명자들도 이미 증명했다는 사실을 감수해야 합니다. 최종 블록은 한 명의 리더가 조합하지만 재량은 엄격히 제한됩니다.

MCP의 주된 절충안은 조정 복잡성입니다. 여러 노드가 동시에 트랜잭션을 제안하게 하면 단일 리더 설계에서는 전혀 발생하지 않는 문제가 생깁니다. 두 제안자가 같은 트랜잭션을 포함하면 충돌을 어떻게 해결해야 할까요? 제안 간 순서는 어떻게 결정할까요? 고도화된 제안자가 결합 규칙을 악용하지 못하게 하려면 어떻게 해야 할까요? 이는 프로토콜 복잡성을 크게 높입니다. 팀은 새로운 노드 역할, 일정 로직, 암호학적 가정, 장애 모드와 관련된 조정 문제를 해결해야 하며, 모두 엄격한 테스트가 필요합니다.

여기서는 정확한 구분이 중요합니다. 업계 전반에서 MCP라는 용어가 실질적으로 다른 속성을 가진 여러 설계를 느슨하게 가리키는 데 사용되기 때문입니다. 가장 낮은 수준에서 MCP는 확률적 검열 저항성을 제공합니다. 여러 제안자에게 제출된 트랜잭션을 검열하려면 여러 노드의 공조가 필요하므로 검열이 더 어려워집니다. 더 높은 수준에서 MCP는 구조적 검열 저항성을 제공할 수 있습니다. 충분한 정족수의 증명을 받은 트랜잭션을 검열하는 블록을 리더가 생성하는 것이 수학적으로 불가능해집니다. Constellation이 목표로 하는 속성이 바로 이것이며, 강력한 보장이 필요한 금융 애플리케이션에는 이 차이가 매우 중요합니다.

Constellation의 작동 방식

Constellation은 Solana에 MCP를 구현하는 프로토콜입니다. Alpenglow를 보완합니다. Alpenglow는 합의, 즉 안전성, 활성, 최종성을 처리하고, Constellation은 누가 트랜잭션을 제안하는지, 제안이 어떻게 승인되는지, 리더가 제안을 어떻게 처리할 수 있는지와 같은 시장 구조를 담당합니다. Constellation은 Alpenglow가 최종 확정할 페이로드를 생성합니다.

아키텍처

Constellation은 Solana 프로토콜 스택에 각기 다른 책임을 가진 두 가지 새 역할을 도입하고, 리더와 검증인의 역할을 수정합니다.

제안자는 트랜잭션의 진입점입니다. 언제든 약 16명의 제안자가 동시에 활성화되며, 지분에 따라 무작위로 선정되고 32주기마다, 즉 ~1.6초마다 교체됩니다. 사용자는 자신이 선택한 하나 이상의 제안자에게 트랜잭션을 직접 제출합니다. 제안자는 유효한 트랜잭션만 수락해야 한다는 제약 아래 어떤 트랜잭션이든 자유롭게 수락하거나 거부할 수 있습니다. 이 단계에는 트랜잭션 포함을 강제하는 프로토콜 규칙이 없습니다. 검열 저항성 보장은 파이프라인의 후반부에서 적용됩니다. 각 제안자는 50밀리초 주기로 작동합니다. 각 주기 안에서 제안자는 수락한 트랜잭션을 pslice라는 구조로 조합합니다. “p” 접두사는 발음하지 않으며 Alpenglow의 slice와 구분하기 위해서만 사용됩니다. pslice는 소거 코딩을 통해 pshred라는 256개의 작은 조각으로 나뉘고, 활성 증명자 256명에게 하나씩 배포됩니다. 소거 코딩의 복구 임계값은 64입니다. 즉, 256개 pshred 중 아무 64개만 있으면 전체 pslice를 복원할 수 있습니다. 각 pshred에는 전체 트랜잭션 목록에 대한 암호학적 해시 커밋이 들어 있습니다. 따라서 증명자가 서명한 뒤에는 리더가 다른 트랜잭션으로 바꾸거나 pslice 내부의 순서를 변경할 수 없습니다.

증명자는 제안자로부터 pshred를 받으면 장애나 부재에 대비해 다음 ~2명의 리더에게 즉시 전달하고, 수신한 pslice의 커밋 해시를 기록합니다. 각 주기가 끝나면 증명자는 해당 주기 동안 관찰한 모든 pslice 커밋 해시를 나열한 암호학적 구속력이 있는 진술인 증명에 서명합니다. 이 증명은 리더에게 전송되며 리더가 포함할 수 있는 트랜잭션을 제한하는 증거 기록이 됩니다. 기록에는 지분 가중치가 적용되고 서명되므로 위조하거나 조용히 무시할 수 없습니다. 

Constellation의 리더는 Alpenglow의 리더와 같습니다. 합의에 들어갈 최종 블록을 생성하는 노드입니다. 차이점은 Constellation에서 증명 기록이 리더의 재량을 엄격히 제한한다는 것입니다. Constellation은 서로 다른 두 임계값을 적용합니다. 집계 증명이 유효하려면 증명자의 최소 60%가 참여해야 합니다. 이 임계값을 충족하지 못하면 블록 전체를 건너뜁니다. 그 안에서 증명자의 최소 40%가 증명한 모든 pslice는 리더가 반드시 포함해야 합니다. 포함하지 않으면 네트워크가 거부할 무효 블록이 생성됩니다. 이중 임계값 설계는 블록 수준 유효성과 제안자별 포함을 분리합니다. 즉, 일부 제안자의 데이터가 충분한 증명자에게 도달하지 않아도 리더는 유효한 블록을 생성할 수 있지만, 충분히 도달한 제안자의 데이터는 선택적으로 제외할 수 없습니다. 리더는 증명된 모든 pslice를 배치로 묶은 뒤 Alpenglow의 Rotor를 통해 검증인에게 전송합니다. 

검증인은 Rotor를 통해 리더로부터 배치를 받고, 배치가 도착하는 대로 파이프라인 방식으로 실행합니다. 전체 블록을 수신하면 증명 기록과 대조해 증명된 모든 pslice에 대응하는 제출물이 블록에 있는지 확인합니다. 모든 검사를 통과해야만 검증인이 최종 확정에 투표합니다. 검사에 실패하면 검증인은 TrySkipWindow 호출을 통해 리더의 전체 시간 창을 건너뛰도록 투표합니다. 

주기와 블록

주기는 Constellation의 기본 시간 단위입니다. Unix 나노초 타임스탬프를 50,000,000으로 나눠 UTC 실제 시각에서 도출한 50밀리초 시간 창입니다. 중요한 점은 주기가 Alpenglow 슬롯과 정렬되지 않는다는 것입니다. 한 슬롯에는 여러 주기가 있고, 각 주기에서 생성된 배치가 리더 블록의 페이로드를 구성합니다. 이 구분은 중요합니다. 50ms 주기는 검열 저항성이 강제되는 시간 창인 경제적 틱이고, 슬롯은 여전히 Alpenglow의 합의 단위이기 때문입니다.

백서는 제안자와 증명자 간 시계 오차 허용치를 명시하고 이에 따라 증명 시간 창을 조정합니다. 이것이 왜 중요한지 예를 들어 보겠습니다. 제안자의 시계가 증명자 집합보다 5ms 빠르다고 가정해 보겠습니다. 이 제안자의 pshred는 주기 경계를 기준으로 예상보다 일찍 증명자에게 도착할 수 있으며, 해당 pslice의 트랜잭션은 증명을 모을 시간이 조금 더 늘어납니다. 반대로 시계가 뒤처진 제안자의 pshred는 제안자가 “제시간에” 제출했더라도 증명 시간 창을 완전히 벗어날 만큼 늦게 도착할 수 있습니다. chrony나 GPS 수신기 같은 도구를 사용하는 데이터 센터 환경에서는 시계 동기화가 일상적이며, 오차는 일반적으로 1밀리초 미만이므로 Constellation의 허용 범위 안에 충분히 들어옵니다. 문제는 Alpenglow의 순수 논리 시간 모델에는 없던 새 변수가 Constellation에 도입된다는 점입니다. Constellation의 최종 SIMD는 이 변수의 모니터링 범위를 명시해야 합니다.

Constellation이 에포크 종료에 가까워지면 제안자와 증명자는 다음 에포크가 시작됐는지 잠시 확신하지 못할 수 있습니다. 이 시간 창에는 두 제안자 및 증명자 집합이 동시에 활성화되어 Constellation이 두 에포크에서 병행 작동합니다. 어떤 주기가 어느 에포크에 속하는지는 Alpenglow 합의가 자연스럽게 결정합니다.

트랜잭션 생명주기와 수수료

트랜잭션은 실행되기 전에 네 관문을 통과해야 합니다.

• 제안자가 트랜잭션을 수락해 pslice에 포함해야 합니다.
• 해당 pslice가 리더의 배치에 포함될 만큼 충분한 증명을 모아야 합니다.
• 배치의 컴퓨트 한도 안에서 실행 대상으로 선정될 만큼 트랜잭션 입찰가가 높아야 합니다.
• 해당 배치를 포함한 블록이 Alpenglow 합의로 확인되어야 합니다.

각 트랜잭션에는 동일 배치 내 순서를 결정하는 입찰가, 즉 컴퓨트 단위당 실행 수수료가 있습니다. 입찰가가 높을수록 먼저 실행됩니다.

Constellation은 트랜잭션 비용을 두 가지 수수료로 나눕니다.

• 포함 수수료.
• 순서 수수료.

포함 수수료는 트랜잭션 크기와 서명 수에 따라 정해지는 소액의 고정 수수료입니다. 트랜잭션을 pslice에 포함한 제안자에게 지급되며, 트랜잭션이 최종 실행되는지와 관계없이 증명 임계값을 넘는 순간 부과됩니다. Solana 현행 시스템의 기본 수수료와 유사하지만 중요한 차이가 있습니다. 사용자가 중복성을 위해 같은 트랜잭션을 세 제안자에게 제출하면 포함 수수료를 세 번, 즉 제안자마다 한 번씩 냅니다. 각 제안자가 독립적으로 포함 작업을 수행했기 때문입니다. 따라서 사용자가 중복성을 위해 같은 트랜잭션을 서로 다른 n명의 제안자에게 제출하면 포함 수수료를 n번 냅니다.

순서 수수료는 더 큰 우선순위 기반 구성 요소이며, 트랜잭션의 총 컴퓨트 단위에 입찰가를 곱한 값입니다. 제안자가 몇 명이든 트랜잭션은 한 번만 실행될 수 있으므로 한 번만 부과됩니다. 예를 들어 컴퓨트 단위당 0.00001 SOL의 입찰가로 200,000 컴퓨트 단위를 요청하는 트랜잭션의 순서 수수료는 2 SOL입니다. 같은 트랜잭션을 중복성을 위해 네 제안자에게 제출했다면 사용자는 네 번의 포함 수수료와 한 번의 2 SOL 순서 수수료를 냅니다. 순서 수수료는 노드 지분에 비례해 생태계로 반환됩니다. 백서는 이 메커니즘의 설계를 최종 SIMD에 맡깁니다.

모든 수수료 납부 계정은 동시 제안자 간 수수료 조작을 방지하기 위해 약 0.001 SOL의 최소 준비금 잔액을 유지해야 합니다. 여러 제안자가 같은 계정에 영향을 주는 트랜잭션을 동시에 포함해도 포함 수수료를 항상 낼 수 있게 합니다.

Constellation과 Alpenglow

Alpenglow는 Solana의 합의 프로토콜입니다. 어떤 블록이 유효한지, 어떤 순서로 최종 확정되는지, 네트워크가 장애에서 어떻게 복구하는지를 결정합니다. Votor와 Rotor 구성 요소가 Tower BFT와 가십 기반 투표 전파를 대체해 최종 확정 시간을 크게 줄입니다. Alpenglow는 누가 트랜잭션을 제안하는지 또는 블록 내부의 순서를 어떻게 정하는지 다루지 않습니다.

Constellation은 Alpenglow 리더가 조합하는 블록으로 무엇을 할 수 있는지 제한하는 시장 구조 계층입니다. 누가 트랜잭션을 제안하고 각 블록 안에서 순서를 어떻게 정하는지 정의합니다. Constellation이 생성한 배치는 Alpenglow 블록의 페이로드가 됩니다. 이후 Alpenglow의 Votor가 사전 정의된 투표 규칙에 따라 해당 블록을 공증합니다. 두 프로토콜은 Alpenglow가 안전성과 활성을 제공하고 Constellation이 순서 공정성을 제공하도록 결합됩니다.

이러한 조합 가능성 덕분에 Constellation은 Alpenglow의 보안 가정을 약화하지 않고 그대로 이어받습니다. Constellation은 Alpenglow의 보장을 건드리지 않습니다. 대신 새로운 제안자 및 증명자 역할과 새로운 주기 기반 타이밍 모델의 UTC 실제 시각 동기화에 관한 새 보장과 가정을 도입합니다.

Constellation은 확장 가능한 프로덕션 블록체인에 MCP를 구현하기 위한 최초의 공식 프로토콜 수준 제안입니다. Alpenglow가 연 프로토콜 로드맵의 다음 장으로, Solana에 검열 저항성을 도입하는 의미 있는 발전입니다.

검열 저항성에 실제로 필요한 것

MEV 문헌은 역사적으로 여러 관점에서 이 문제에 접근해 왔으며, 이를 종합하면 검열 저항성 제안이 실제로 해결해야 할 사항을 더 통합적으로 파악할 수 있습니다. Eskandari 등의 프런트러닝 공격에 관한 기초 분류 체계, Garimidi 등의 MCP 프로토콜에 관한 공식적인 2속성 프레임워크, Landers와 Marsh의 MCP 특화 MEV 채널 분석을 바탕으로 공격 표면을 서로 다른 세 계층으로 구성할 것을 제안합니다. 각 계층에는 서로 다른 유형의 해결책이 필요합니다. 이 프레임워크는 Constellation의 설계를 평가하기 위해 여기서 제시하는 자체적인 종합 모델입니다.

계층 1: 강경 검열

강경 검열은 리더나 제안자가 식별한 트랜잭션의 포함을 거부할 수 있는 능력을 뜻합니다. 가장 분명한 형태의 조작이며 Constellation이 구조적으로 해결하는 문제입니다. Constellation에서는 충분한 증명자 정족수가 증명한 수수료 경쟁력 있는 트랜잭션을 제외하면서 유효한 블록을 생성하는 것이 리더에게 암호학적으로 불가능해집니다. 집행이 아키텍처에 내장되므로 슬래싱이 필요하지 않습니다.

계층 2: 콘텐츠가 노출된 상태의 순서 조작

두 번째 계층은 해결하기가 더 어렵습니다. 제안자는 노골적으로 검열할 수 없지만 최종 순서가 정해지기 전에 트랜잭션 내용을 관찰하고 그 가시성을 악용할 수 있습니다. 예를 들어 대규모 거래를 샌드위치 공격할 수 있습니다. Garimidi 등이 은닉 속성으로 공식화한 문제입니다. 적대자는 트랜잭션이 확인되기 전에 내용을 볼 수 없어야 합니다. Constellation은 부분 은닉을 구현합니다. 트랜잭션은 이를 받은 제안자에게만 보이고 모든 제안자에게 보이지 않으며, 리더는 주기 기한이 지난 뒤에만 트랜잭션 내용을 봅니다. 완전한 가시성보다는 낫지만, 확인 전에 모든 당사자에게 트랜잭션 내용을 숨겨야 한다는 Garimidi 등의 은닉 속성을 완전히 충족하지는 않습니다. 수신 제안자는 여전히 자신이 받은 트랜잭션 내용을 관찰하고 악용할 수 있습니다.

Constellation에서 더 깊이 우려되는 점은 공개 트랜잭션 제출을 사용하는 MCP가 콘텐츠 노출 악용을 증폭할 수 있다는 것입니다. 각 제안자가 자신이 받은 트랜잭션을 관찰하고 자신의 pslice 안에서 그 가시성을 악용할 수 있는 시스템이 됩니다. 여러 주체가 각자 일부를 볼 수 있으므로 공격 표면은 단일 리더 모델과 다릅니다. 한 제안자에게 제출한 사용자는 해당 제안자에게만 트랜잭션을 노출합니다. 하지만 중복성을 위해 여러 제안자에게 제출하면 노출도 그에 비례해 늘어납니다. Landers와 Marsh는 이 역학을 공식화했습니다. 동시 블록 생성은 타이밍 게임과 동일 틱 중복 기회를 만들고, 피해 트랜잭션마다 성공할 수 있는 추출 시도 횟수를 현재 제한하는 단일 빌더 병목 지점을 구조적으로 없앱니다. 콘텐츠 가시성을 해결하지 않고 제안자 집합을 탈중앙화하면 MEV 공격 표면이 줄어드는 대신 늘어납니다.

Landers와 Marsh의 MCP 특화 MEV 채널 분석은 Constellation이 제공하는 것보다 더 광범위한 콘텐츠 가시성을 가정합니다. Constellation의 부분 은닉에서는 콘텐츠 노출 악용의 증폭이 아키텍처상 불가피한 결과가 아니라 사용자의 제출 전략에 따라 달라집니다. 신뢰하는 단일 제안자에게 제출하는 사용자의 콘텐츠 노출 양상은 현재의 단일 리더 모델과 대체로 같습니다. 대신 단일 제안자 제출은 검열 저항성에 필요한 중복성을 포기합니다. 

계층 3: 타이밍 및 지연 시간 조작

가장 미묘하고 처벌하기 어려운 계층은 타이밍과 지연 시간 조작입니다. Constellation에서 제안자는 경쟁자의 트랜잭션이 증명 시간 창을 벗어나도록 pshred의 증명자 전달을 아주 조금 지연하거나, UTC 시계 오차를 악용해 어떤 트랜잭션이 충분한 증명을 모으는지 조작할 수 있습니다. Constellation 백서도 이 공백을 직접 인정합니다. 늦은 메시지 전달은 실제 네트워크 지연과 구별할 수 없으므로 “처벌할 수 없습니다.” 슬래싱이 관련될 수 있는 계층이며 Constellation의 최종 SIMD가 해결해야 할 주된 미결 과제입니다. 

Constellation 설계의 근본 가정은 제안자와 사용자의 관계가 익명이 아니라는 것입니다. 신뢰를 측정할 수 있고 평판이 중요한 반복적 상호작용입니다. 언제든 약 16명의 제안자가 활성화되어 있으므로 한 제안자로부터 지속해서 좋지 않은 대우를 받은 사용자는 다른 15명 중 한 명에게 제출하기 시작할 수 있습니다. 악의적인 주체를 직접 처벌하는 데 사용할 온체인 기록은 생기지 않지만, 지위를 악용하는 제안자에게 경제적 결과를 발생시킵니다. 슬래싱 같은 해결책과 비교할 때 이러한 평판 압력이 타이밍 조작을 억제하기에 충분한지는 미결 과제입니다. 시간이 지나며 사용자에게 제안자 행동이 얼마나 투명해지는지에 따라 달라질 가능성이 큽니다. 

검증인과 사용자에게 미치는 영향

검증인

Constellation은 MEV 기회를 완전히 없애는 대신 검증인 사이에 재분배합니다. 현재 리더가 활용할 수 있는 가장 명확하고 직접적인 수익원인 강경 검열은 설계상 불가능해집니다. 하지만 이를 대신하는 것은 지연 시간 우위, 정밀한 시계 동기화, pshred 전달 시간 창을 지속해서 악용할 역량을 가진 검증인에게 유리한 더 미묘하고 처벌하기 어려운 타이밍 채널입니다. 총 추출 표면이 감소하기보다 검증인이 가치를 추출하는 방식이 바뀝니다. 다만 추출이 훨씬 어려워집니다.

Constellation은 완전히 새로운 수수료 흐름을 도입하기보다 기존 흐름을 재구성합니다. 포함 수수료는 현재의 기본 수수료와 유사하고, 순서 수수료는 기존 우선순위 수수료에 대응합니다. 분배 비율은 검증인이 현재 얻는 수익과 비슷할 것으로 예상됩니다. 차이는 주로 운영에 있습니다. 우수한 운영자는 제안자로서 더 많은 포함 수수료를 얻을 것이므로, 별도 수익 범주를 만들기보다 기존 경제 구조 안에 성과 기반 차등이 생깁니다. 현재 설계에서는 증명자 역할에 별도 보상이 없습니다. 현재 Turbine 참여처럼 네트워크에 순이익이므로 수행될 것으로 보기 때문입니다. 더 중요한 경제적 변화는 현재 프로토콜 외부의 랜딩 서비스, 시장 기반 경매, 오프체인 수수료 계약을 통해 흐르는 활동입니다. 이 활동은 프로토콜 안으로 돌아와 검증인에게 더 직접적인 혜택을 제공해야 합니다. 하지만 SIMD가 정확한 메커니즘을 명시하기 전까지 개별 검증인에 대한 순경제 효과는 미결 과제입니다. 특히 지분 가중 선정으로 제안자 선정 빈도가 낮고 인프라 오버헤드로 최소 비용이 높아지는 소규모 검증인에게 그렇습니다.

제안자와 증명자는 지분 가중치에 따라 선정됩니다. 따라서 검증인 경제를 형성하는 집중화 역학이 이 역할의 참여에도 그대로 적용됩니다. 소수의 고지분 검증인이 제안자 선정을 장악해도 검열 저항성 보장은 형식적으로 유지됩니다. 그러나 현재 Solana보다 여전히 개선되었음에도, 즉 n개 중 1개를 고르는 대신 n개 중 16개를 고르더라도 제안자 집합의 실질적인 다양성은 줄어듭니다. 독립성 가정은 이론적으로 유지되더라도 실제로 약해지기 시작합니다. 단일 주체가 고지분 검증인을 여러 개 운영할 수 있는 Validator-as-a-Service(VaaS)가 등장했다는 점에서 주목할 우려입니다. SIMD가 집중 방지 메커니즘이나 제안자 선정을 위한 인센티브를 도입할지는 Constellation이 내세우는 보장의 강도에 직접적인 영향을 주는 설계 문제입니다. 

사용자

충분한 수의 제안자에게 제출된 수수료 경쟁력 있는 트랜잭션은 처음으로 선택적 배제를 막는 강력한 프로토콜 보장을 받습니다. 이전에는 없던 보장을 갖춘 금융 애플리케이션을 구축할 수 있으며, Solana에서만 가능한 것의 범위가 달라집니다. 

고빈도 및 가격 민감형 사용자는 중복성을 위해 여러 제안자에게 트랜잭션을 제출해야 합니다. 콘텐츠 가시성을 해결하지 않은 채 제안자 집합을 탈중앙화하면 샌드위치 공격에 대한 노출이 늘 수 있습니다. 각 제안자는 자신에게 제출된 트랜잭션을 관찰하고 대응할 수 있으므로, 중복성을 위해 여러 제안자에게 제출하는 사용자는 트랜잭션 내용을 보는 당사자 수를 그에 비례해 늘립니다. 이는 본질적으로 단일 리더 병목 지점을 없애고 더 광범위한 잠재적 적대자에게 트랜잭션 의도를 알립니다. 실질적으로 고도화된 사용자는 중복성과 노출 사이에서 균형을 잡는 새로운 제출 전략을 개발해야 합니다. 예를 들어 광범위한 다중 제출 대신 평판이나 지분을 기준으로 제안자를 선별해 제출할 수 있습니다.

특히 시장 조성자에게 Constellation의 포함 보장은 인프라가 실행 품질을 좌우하는 적대적 위험을 없앱니다. 남는 것은 순수한 정보 비대칭이며, 이는 오늘날 시장 조성자가 최고의 전통 거래소에서 마주하는 것과 같은 위험 양상입니다. 이 수렴 덕분에 포함 지연 시간 단축을 지지하는 주장은 희망 사항이 아니라 구체적인 주장이 됩니다. “미결 과제” 섹션에서 이 수렴을 더 자세히 다룹니다.

평균 사용자가 체감하는 경험의 순변화는 크지 않을 가능성이 높지만, 포함 보장은 신뢰성을 의미 있게 개선합니다. 향후 벤치마크가 나오기 전까지 순서 지연 시간에 미치는 순효과는 실증적으로 미결인 문제입니다.

생태계 비교: Constellation의 위치

Sei Giga

Sei Giga는 현재 MCP 생태계에서 Constellation과 가장 유사합니다. MCP를 미래 연구 목표가 아니라 최우선 아키텍처 과제로 추진하는 프로덕션급 블록체인입니다. 같은 계층에서 서로 다른 절충안을 택한다는 점에서 둘의 비교는 유익합니다.

Giga의 합의 기반은 Autobahn입니다. 모든 검증인이 각자 지속적인 제안 “레인”을 병렬로 운영하는 다중 제안자 BFT 프로토콜입니다. 단일 리더에 의존하는 대신 모든 노드가 독립적인 레인에서 자체 데이터 제안 스트림을 계속 전파하고, 합의 계층은 주기적으로 각 레인의 최신 제안을 집계한 압축 스냅샷인 “팁 컷”을 커밋합니다. 이는 약 16명의 선정된 제안자가 고정된 50ms 주기로 작동하는 Constellation 모델과 아키텍처가 다릅니다. Autobahn의 레인 기반 모델은 순환하는 지분 가중 하위 집합에서 선정되는 대신 모든 검증인이 지속적인 제안 레인을 유지할 수 있게 하므로 블록 생성 참여 범위를 크게 넓힙니다.

가장 중대한 차이는 콘텐츠가 노출된 상태의 순서 조작에 있습니다. Autobahn은 트랜잭션 순서 결정과 실행을 분리해 비동기 실행을 지원합니다. Constellation은 이 설계 선택을 미룹니다. 다음 섹션에서 설명하듯 비동기 실행은 제안자가 순서를 정하는 시점에 알려진 최종 상태를 기준으로 실행 결과를 시뮬레이션하지 못하게 하여 콘텐츠 노출 순서 조작의 공격 표면을 줄입니다.

Giga는 확률적 검열 저항성을 제공하지만 Constellation은 구조적 보장을 제공합니다. Giga의 기반 가정은 여러 제안자에게 제출한 트랜잭션을 검열하기가 더 어렵다는 것입니다. 각 제안자가 불완전한 정보를 가지고 작동하며, 다른 제안자가 같은 틱에 트랜잭션을 포함하면 검열의 효용이 사라질 수 있기 때문입니다. 반면 Constellation에서 충분한 증명을 받은 트랜잭션을 제외한 리더는 무효 블록을 생성합니다. 확률적 저항성은 검열 비용을 높이지만 구조적 저항성은 검열을 암호학적으로 불가능하게 합니다. 두 프로토콜이 지원하려는 금융 애플리케이션에는 이 차이가 중요합니다. 

두 설계의 목표 수준이 다르다는 점을 솔직히 인정할 필요가 있습니다. Constellation은 정확성 속성을 증명하고, 장애 조건을 정의하고, 정족수 임계값을 명시하며, 수십억 달러 규모의 가치가 스테이킹된 확장 가능한 프로덕션 네트워크에 공식 제안으로 제출하기 위한 프로토콜 명세입니다. Sei Giga 백서는 다르게 읽힙니다. 처리량 주장과 EVM 호환성에 초점을 맞추며, MEV와 검열 저항성을 공식적으로 명시된 보장이라기보다 다중 제안자 아키텍처에서 발생하는 이점으로 다룹니다. 비동기 실행의 방향은 옳지만 Giga는 순서 제약, 증명자 정족수, 장애 조건에 관해 Constellation과 같은 수준의 공식 보장을 제공하지 않습니다. 이는 Giga의 순서 결정 방식을 비판하기보다 서로 다른 맥락을 반영합니다. Constellation은 세계에서 처리량이 가장 높은 프로덕션 블록체인 위에 제안되므로 그에 걸맞게 더 높은 명세 기준을 요구하고 충족합니다.

학문적 이상형

MCP 설계의 이론적 기준은 a16z Crypto Research의 Garimidi와 Neu, Anza의 Max Resnick이 쓴 Multiple Concurrent Proposers: Why and How(2025)입니다. 이 논문은 검열 저항성을 갖춘 모든 설계가 충족해야 한다고 주장하는 두 속성, 선택적 검열 저항성과 은닉을 제공하는 MCP 프로토콜을 제안합니다. 전자는 적대자가 트랜잭션을 선택적으로 지연할 수 없도록 보장하고, 후자는 확인 전에 트랜잭션 내용이 보이지 않도록 보장합니다. 현재 문헌에서 두 속성을 동시에 공식적으로 달성한 유일한 MCP 설계입니다.

은닉을 가능하게 하는 메커니즘은 HECC, 즉 Hiding Erasure-Correcting Code입니다. 임의의 T개 샤드로는 기반 트랜잭션 배치에 관한 정보를 전혀 알 수 없지만 K + T개 샤드로는 전체를 복원할 수 있도록 매개변수화됩니다. 핵심은 합의가 포함할 배치를 확인한 뒤에만 릴레이가 저장된 샤드를 브로드캐스트한다는 점입니다. 확인 전에 트랜잭션 내용을 관찰하지 못하게 하여 콘텐츠 노출 순서 조작 공격 표면을 정보 이론적 보장으로 완전히 차단합니다. 

앞서 개발한 프레임워크에 대입하면 이 프로토콜 설계만이 구조적 검열 저항성으로 계층 1을, 은닉으로 계층 2를 해결하며, 은닉이 제공하는 검열 저항성 보장으로 계층 3의 범위를 제한합니다. Constellation과 Giga 모두 이를 완전히 달성하지 못합니다.

이 비교가 특히 흥미로운 이유는 이론적 이상형의 공동 저자인 Resnick이 이를 의도적으로 벗어나는 프로토콜인 Constellation의 공동 저자이기도 하기 때문입니다. 이는 완전한 HECC 기반 설계가 아직 Solana 규모의 프로덕션 네트워크에 배포될 수 없으며, 구조적 검열 저항성이 먼저 해결해야 할 더 긴급한 문제라는 의도적인 판단을 반영합니다. 이 논문은 Constellation의 북극성 역할을 합니다. 프로토콜이 한 번에 전부 제공할 수 없더라도 궁극적으로 무엇을 향해 구축하는지를 공식적으로 명시합니다. 

Ethereum Braid

Braid는 Max Resnick이 소개한 Ethereum의 주된 MCP 제안입니다. 현재 경쟁 설계인 FOCIL 포함 목록과 함께 Ethereum의 Scourge 로드맵 일부로 검토되고 있습니다. 여기서 다루는 이유는 기술 비교보다 맥락에 있습니다. 업계 전체가 서로 다른 출발점에서 같은 구조적 문제를 해결하려 하고 있습니다.

Braid는 같은 슬롯 안에서 여러 제안자가 병렬 체인에 걸쳐 동시에 블록을 구축하도록 MCP를 구현합니다. 실행 계층은 사전 정의된 규칙에 따라 트랜잭션을 집계하고 중복을 제거하며 정렬합니다. 추가 프로토콜 역할은 도입하지 않습니다. 가장 중대한 차이는 Braid의 안전성이 암호화된 멤풀에 크게 의존한다는 점입니다. 은닉을 미룰 수 있는 요소가 아니라 전제 조건으로 둡니다. Braid는 아직 배포되지 않은 연구 제안이며, Ethereum 커뮤니티는 FOCIL 대신 이를 추진할지 합의하지 못했습니다.

Braid가 궁극적으로 확인하는 점은 MCP의 구조적 논거가 특정 체인을 초월한다는 것입니다. Resnick이 이 섹션의 네 사례 중 세 가지에 참여했다는 점도 주목할 만합니다. 이는 Constellation이 쉬운 해결책을 거부해 온 문제를 여러 맥락에서 지속적이고 학문적으로 엄밀하게 고민한 결과라는 가장 분명한 신호일 수 있습니다.

PBS에 관한 참고 사항

Proposer-Builder Separation(PBS)은 비교 가능한 설계라기보다 대조군으로 언급할 가치가 있습니다. 이 섹션의 모든 사례가 리더의 일시적 독점을 구조적으로 제한하려는 반면, PBS는 이를 받아들이고 그 주변을 최적화해 MEV 수익을 재분배합니다. Constellation은 PBS와 명시적으로 호환되지 않습니다. 증명 기록이 리더의 재량을 제한하면 전문 빌더가 판매할 것이 남지 않습니다. 사용자 피해를 줄이는 데 아무런 역할을 하지 않는데도 PBS가 Ethereum의 지배적인 MEV 완화책이 된 것은 MCP가 피하려는 실패 유형을 정확히 보여줍니다.

프로토콜 외부의 선례

Constellation이 출시되기 전부터 Solana 생태계는 이미 프로토콜 외부에서 MCP의 일부 측면을 구현하고 있습니다. 예를 들어 Harmonic은 여러 독립 빌더의 블록 제안을 지속해서 수집하고 평가하며, 검증인이 실시간으로 경쟁 선택할 수 있게 제시하는 개방형 블록 구축 집계 계층입니다. 프로토콜이 강제하는 검열 저항성, 증명 정족수, 리더의 재량에 대한 암호학적 제약이 없으므로 공식적인 의미의 MCP는 아닙니다. 하지만 Harmonic을 실행하는 검증인은 이미 여러 동시 블록 제안 중 하나를 선택하고 있으며, 이는 MCP가 프로토콜에 확립하려는 핵심 메커니즘입니다. BAM과 함께 이 둘은 프로토콜 수준 집행을 기다리지 않고 시장 구조 문제를 해결하려는 생태계의 시도입니다. 이러한 프로토콜 외부 시스템은 MCP와 유사한 속성에 대한 수요가 실제로 존재하며, 빌더들이 Constellation 출시를 기다리지 않을 정도임을 보여줍니다.

미결 과제

Constellation 백서는 프로토콜 명세입니다. 명시된 가정 아래 정확성 속성을 증명하고 나머지는 적절히 미룹니다. v0.9 제안으로서 적절한 접근입니다. 다음 내용은 Constellation의 실패 목록이 아닙니다. MCP를 Solana에 효과적으로 도입하기 위해 최종 SIMD와 이후 반복 버전이 해결해야 할 사항을 정리한 지도입니다. 

이 질문들의 난이도는 같지 않습니다. 일부는 명세 작업이며 Anza가 일반적인 SIMD 절차를 통해 해결할 수 있고 해결해야 하는 설계 결정입니다. 다른 일부는 더 광범위한 MCP 연구 커뮤니티도 아직 해결하지 못한 진정한 미결 문제입니다. 하지만 대규모 MCP를 구현하는 최초의 블록체인으로 나아가는 과정에서 반드시 인식해야 합니다. SIMD 하나만으로 해결할 수 없습니다. 둘을 혼동하면 Constellation의 공백을 과장하거나 남은 작업량을 과소평가할 위험이 있으므로 이 구분이 중요합니다.

명확한 SIMD 작업은 다음과 같습니다.

• 수수료 분배: 우선순위 수수료를 제안자, 증명자, 전체 검증인 집합에 어떻게 나눌지는 설명되어 있지만 완전히 구체화되지 않았습니다. 백서는 우선순위 수수료가 지분에 비례해 생태계에 반환된다고 명시하지만 제안자, 증명자, 검증인 사이의 정확한 분배 메커니즘은 정의하지 않습니다.
• 검증인 보상 구조: 기존 검증인 보상과 비교해 제안자에게 어떻게 보상할지, Alpenglow에서 투표 트랜잭션 수수료를 없애면 소규모 검증인의 계산이 달라지는지 정해야 합니다.
• 배포 순서: Constellation은 2026년 3분기로 예정된 Alpenglow에 의존합니다. SIMD는 이 의존성을 명시하고 기본 Alpenglow에서 Constellation+Alpenglow로 전환하는 시간 창에 어떤 일이 발생하는지 다뤄야 합니다. 먼저 메인넷에 적용해야 할 선행 SIMD가 있을까요?
• 역할 매개변수의 거버넌스: Constellation 백서 표 1의 제안자 수(p ≈ 16), 증명자 수(q ≈ 256), 주기 길이(△cycle = 50ms)와 기타 매개변수는 제안값으로만 제시됩니다. SIMD는 이러한 매개변수를 설정하고 관리하며 향후 변경할 방식을 명시해야 합니다.

더 어려운 질문, 예를 들어 비동기 실행, 슬래싱, 제출 계층 프라이버시는 다음 하위 섹션에서 다룹니다. MCP 연구 커뮤니티가 활발히 연구하는 문제이며 반드시 고려해야 합니다. Constellation의 설계 선택에 따라 특정한 궁극적 해결책으로 향하는 길이 좁아지거나 넓어질 수 있기 때문입니다.

비동기 실행

동기 실행에서는 평문 트랜잭션을 받거나 단순한 제출 모델에서 이를 일찍 디코딩할 수 있는 제안자가 트랜잭션 내용을 알고 결과를 시뮬레이션할 수 있습니다. 제안자는 현재 상태를 기준으로 트랜잭션을 실행해 스왑 가격, 계정 잔액 변화, 후속 차익거래 기회 등 정확한 실행 결과를 계산할 수 있습니다. 이 때문에 샌드위치 공격이 기계적으로 정밀해집니다. 공격자는 대규모 스왑을 보고 수익을 극대화하려면 얼마나 앞서 거래해야 하는지 계산할 수 있습니다.

비동기 실행은 MCP와 결합할 때만 이 우위의 후반부를 제거합니다. 실행 전에 합의가 트랜잭션 순서를 커밋하면, 트랜잭션 내용을 본 제안자도 알려진 최종 상태를 기준으로 실행 결과를 시뮬레이션할 수 없습니다. 순서를 정하는 시점에는 그 상태가 존재하지 않기 때문입니다. 정보 우위는 사실상 “이 트랜잭션이 무엇을 하며 어떤 순서로 실행되는지 안다”에서 “이 트랜잭션이 무엇인지는 알지만 최종 순서 집합과 비교해 어떤 결과를 낼지는 모른다”로 줄어듭니다. 이 이점은 제안자가 최종 순서를 통제하지 않아야 성립합니다. 단일 리더 모델에서는 비동기 실행만으로 이러한 보호를 제공하지 못합니다. 실행 시점과 관계없이 리더는 여전히 순서를 완전히 재량으로 정하고 자신의 트랜잭션을 유리하게 배치할 수 있기 때문입니다. 제한된 순서 결정과 지연 실행이 결합되어야 공격 표면이 줄어듭니다.

비동기 실행도 계층 2를 완전히 차단하지는 못합니다. 고도화된 제안자는 여전히 범주적 추론을 할 수 있습니다. 예를 들어 트랜잭션이 특정 유동성 풀에 영향을 준다는 사실을 보고 정확한 결과를 몰라도 가능한 방향을 추론할 수 있습니다. 그래도 가장 기계적이고 수익성 높은 악용 방식에 대한 장벽을 의미 있게 높입니다. 합의 계층에서 암호학적 은닉을 요구하지 않고 계층 2를 줄일 수 있는 가장 명확한 아키텍처 경로입니다. 특히 Sei Giga는 이 접근법을 선택해 MCP와 함께 비동기 실행을 최우선 아키텍처 과제로 추진했습니다.

여기서 숙고할 만한 자연스러운 질문이 생깁니다. 왜 비동기 실행을 먼저 추진하지 않았을까요? 비동기 실행은 계층 2를 줄이며, 원칙적으로 MCP의 추가 프로토콜 복잡성, 즉 새로운 노드 역할, UTC 시계 동기화 요구 사항, 미해결 슬래싱 설계, 두 배가 된 샤딩 오버헤드 없이 제한된 실행 계층 변경으로 추진할 수도 있었습니다. 

이 순서를 가장 강하게 뒷받침하는 논거는 비동기 실행과 MCP가 서로 다른 문제를 해결한다는 것입니다. MCP는 비동기 실행만으로 제공할 수 없는 구조적 순서 제약을 제공합니다. 실행 결과를 시뮬레이션할 수 없지만 트랜잭션 내용을 볼 수 있는 검증인은 프로토콜이 허용한 시간 창 안에서 여전히 순서에 재량을 행사할 수 있습니다. MCP를 먼저 추진하는 근거는 계층 1을 구조적으로 제한하며, 계층 1이 더 명확하고 경제적으로 즉각적인 위협이라는 점입니다. Solana의 기존 동기 실행 모델에 비동기 실행을 개조하는 것은 조합 가능성 가정과 프로그램 아키텍처를 고려하면 새 체인에 처음부터 구축하는 것보다 어려운 엔지니어링 문제입니다. Sei Giga는 첫날부터 비동기 실행을 고려해 설계할 수 있지만 Solana는 그렇지 않습니다. MCP가 먼저 추진된 이유를 설명할 때 이 실질적 비대칭은 이론적 우선순위 논거만큼 중요할 수 있습니다. Alpenglow 아키텍처도 Tower BFT 아래에서보다 MCP를 더 다루기 쉽게 합니다. 다음 프로토콜 복잡성 하위 섹션에서 이를 살펴봅니다.

이 순서가 옳은지는 합리적인 미결 과제입니다. Constellation은 계층 2를 그대로 남기며, MCP가 계층 3에 도입하는 새로운 공격 벡터를 고려하면 문제가 됩니다. 두 공격 표면은 상호 보완적이므로 계층 2 공격의 수익성도 높아질 수 있습니다. 예를 들어 대규모 DEX 트랜잭션을 본 제안자는 pshred를 지연해 현재 배치 시간 창 밖으로 밀어내는 동시에 같은 시간 창에 자신의 트랜잭션을 넣어 프런트러닝할 수 있습니다. 계층 2의 가시성과 계층 3의 타이밍 게임은 같은 공격 표면의 핵심 무기이며 Solana가 성숙할수록 더욱 고도화될 것입니다.

슬래싱

암호학적 집행은 주체의 악의적 행동이 검증 가능한 기록을 남길 때 잘 작동합니다. 예를 들어 충돌하는 서명, 유효성 검사 실패, 증명 가능한 비정상 커밋이 있습니다. Constellation이 계층 1의 검열 저항성 문제를 깔끔하게 해결하는 이유는 증명된 트랜잭션을 제외한 리더가 무효 블록을 생성하고, 그 무효성을 수학적으로 증명할 수 있기 때문입니다. 타이밍 게임과 지연 시간 조작은 그러한 기록을 남기지 않습니다. 개별 행위 수준에서 이런 악의적 행동은 정직한 네트워크 지연과 구별할 수 없습니다. 악의적 행동이 부재의 형태로 존재하므로 암호학적으로 증명할 수 없습니다. 사용할 수 있는 유일한 수단은 경제적 억제이며, 이를 위해서는 슬래싱이 필요합니다. 

슬래싱의 문제는 전통적으로 증명 가능한 위반이 필요하다는 것입니다. Constellation의 장애 증거 메커니즘은 충돌하는 두 pshred에 서명한 제안자를 식별하고 제외할 수 있습니다. 하지만 전략적 지연 시간 조작은 장애 증거를 만들지 않습니다. 이중 진술도, 이중 서명도, 온체인 흔적도 없습니다. pshred 전달을 지속적으로 선택해 몇 밀리초 지연하는 제안자는 슬래싱할 흔적을 남기지 않습니다. 

여러 주기에 걸쳐 제안자 자신의 제출물과 경쟁하는 트랜잭션에서 pshred가 지속해서 주기 시간 창의 마지막 몇 밀리초에 증명자에게 도착한다면, 잘 정의된 슬래싱 메커니즘은 하나의 증명 가능한 악의적 행위가 없어도 이 패턴을 체계적 조작의 증거로 간주할 수 있습니다. 전통적인 슬래싱은 이를 직접 다룰 수 없습니다. 정형적인 슬래싱에는 명백하고 독립된 증명이 필요하지만, 단순히 전달을 몇 밀리초 늦춘 제안자에게는 그런 증명이 없습니다. 다른 것은 패턴입니다.

지연 시간 기반 조작에 대한 규제 기관의 접근법에서는 전통 금융이 탈중앙 금융에 유용한 교훈을 줄 수 있습니다. 예를 들어 Dodd-Frank Act에 따른 스푸핑 집행은 개별 주문의 의도를 증명하는 대신 취소 대비 체결 비율, 취소 시점 분포, 가격 영향 상관관계 같은 통계적 패턴을 탐지합니다. 단일 사례는 의도적이라고 증명할 수 없습니다. 하지만 패턴은 증명할 수 있습니다. 개별 행위가 객관적이지 않아도 통계적 규칙성은 객관적이므로 같은 논리를 적용할 수 있습니다. 조작의 경제적 인센티브도 전통 금융의 고빈도 트레이더만큼 무허가 제안자 집합에 존재합니다. 이 비유가 성립하지 않는 부분은 집행입니다. Dodd-Frank는 소환 권한이 있는 규제 기관에 의존하지만, 무신뢰 환경에서는 탐지와 처벌 메커니즘이 프로토콜 자체에 확립되어야 합니다.

이 공백을 해결할 후보 메커니즘으로 피셔맨 노드의 적용을 제안합니다. 데이터 가용성에 관한 Vitalik의 연구에서 처음 소개된 피셔맨 노드는 여러 주기의 증명 데이터를 감시하고 프로토콜에 내장된 중재 시스템에 통계적 사기 증명을 제출하는 관찰자 유형으로 변형할 수 있습니다. 개별적인 늦은 도착은 주관적입니다. 하지만 n개 주기에 걸쳐 결정론적으로 계산한 패턴은 객관적입니다. 옵티미스틱 롤업의 사기 증명과 같은 통찰을 상태 전환 대신 타이밍 행동에 적용합니다. 통계적 사기 증명을 위한 내장형 중재 프로토콜은 현재 개발 중인 새 거버넌스 도구와 본질적으로 완전히 다르지도 않습니다. 이 도구는 향후 거버넌스 제안에서 스테이커가 검증인의 투표를 무효화할 수 있게 합니다. Solana가 스테이커 투표 재정의를 위한 인프라를 마련할 준비가 되었다면 피셔맨 기반 중재 시스템의 기술적 토대도 예상보다 가까울 수 있습니다.

피셔맨 노드에 대한 이 탐구는 단일 온체인 흔적을 남기지 않는 행위까지 정형적 슬래싱을 확장하는 것보다 신뢰할 만한 방향입니다. 현재 프로토콜이 개발 중인 거버넌스 인프라도 이미 이를 지원할 수 있는 위치에 있을지 모릅니다. 다만 구체적인 명세에서는 세 가지 한계를 해결해야 합니다. 첫째, 수천 주기에 걸친 증명 타이밍 데이터를 통계적으로 분석하는 작업은 간단하지 않으며 검증인 하드웨어 요구 사항을 쉽게 높일 수 있습니다. 운영 비용이 늘고 사기 탐지 역할이 소수의 고도화된 주체에게 집중될 가능성이 있습니다. 둘째, 임계값 명세는 지나치게 보수적이어서 오탐을 만들지 않으면서 실제 네트워크 변동과 전략적 조작을 구별할 만큼 견고해야 합니다. 셋째, 중재 프로토콜 자체가 새로운 공격 표면을 만듭니다. 조직적인 보고를 통해 피셔맨 기반 시스템을 조작할 수 있습니다. 모든 중재 프로토콜은 이를 고려해 설계해야 합니다. 소규모 참여자도 피셔맨을 운영할 수 있게 하는 인센티브 메커니즘이나 피셔맨 집합 전체에 컴퓨트를 분배하는 집계 방식을 활용할 수 있습니다.

우리가 제시하는 구체적인 연구 질문은 다음과 같습니다. 임계값 매개변수를 정의하고 네트워크 변동을 고려하며 처벌의 확대 방식을 정하는 통계적 사기 증명 프레임워크를 명시할 수 있을까요? 이 프레임워크는 체계적 지연 시간 조작을 억제할 만큼 견고하고, 정직한 변동을 처벌하지 않을 만큼 보수적이며, 고도화된 운영자의 적대적 악용을 막을 만큼 단순해야 합니다. MCP 문헌에서 기술적으로 가장 까다로운 미결 문제 중 하나이며, 더 넓은 연구 커뮤니티도 아직 해결하지 못했습니다.

은닉

슬래싱만이 타이밍 및 지연 시간 조작 게임의 해결책은 아닙니다. 은닉은 비동기 실행이나 슬래싱만으로는 각각 해결할 수 없는 콘텐츠 노출 순서 조작과 타이밍 및 지연 시간 조작을 모두 다룹니다. Constellation은 부분 은닉을 구현합니다. 트랜잭션 내용은 수신 제안자와 주기 기한 후 리더에게만 보입니다. 하지만 완전한 은닉 속성은 달성하지 못합니다. 공격 표면은 사용자가 제출하기로 선택한 제안자 수에 따라 커집니다. 부분 은닉은 완전한 가시성보다 공격 표면을 줄이지만 완전히 차단하지는 않습니다. 확인 전에 어느 당사자도 트랜잭션 내용을 보지 못하는 완전 은닉은 Constellation의 미결 과제로 남습니다.

이론적 이상형은 Hiding Erasure-Correcting Code(HECC)를 기본 요소로 사용하는 Garimidi 등의 접근법입니다. Constellation의 표준 Reed-Solomon과 달리 HECC는 임계값보다 적은 샤드를 수집한 적대자가 트랜잭션 내용에 관해 아무것도 알 수 없다는 정보 이론적 보장을 제공합니다. Constellation은 Turbine을 통해 현재 Solana에서 운영 중인 소거 코딩을 계속 사용하기로 했습니다.

최근 가장 관련성 높은 발전은 Trusted Execution Environments(TEE)를 사용해 트랜잭션이 실행 전까지 비공개로 유지되는 암호화된 멤풀을 만드는 Jito의 Block Assembly Marketplace(BAM)입니다. BAM은 Solana에서 콘텐츠 프라이버시에 대한 실질적 수요가 커지고 있음을 보여줍니다. 하지만 TEE 기반 은닉에도 한계가 있습니다. 신뢰 가정을 하드웨어 제조사로 옮기기 때문에 무신뢰 운영을 지향하는 프로토콜에는 중요한 제약입니다. 더 원칙적인 대안으로 임계값 암호화를 사용하는 경로를 철저히 검토해야 합니다.

BAM은 Constellation이 미룬 콘텐츠 가시성 문제를 해결하려는 프로토콜 외부의 시도라는 점에서 중요합니다. Jito는 Constellation 출시 전에도 BAM을 통해 대규모 트랜잭션 프라이버시를 제공할 운영 역량을 갖췄습니다. 애플리케이션 계층 해결책이 이미 프라이버시를 제공할 수 있다면 프로토콜 수준 은닉이 여전히 시급한지 의문이 생깁니다. 답은 전적으로 신뢰 가정과 프로토콜이 이론적으로 보장할 수 있는 것에 비해 하드웨어 제조사를 “충분히” 신뢰할 수 있는지에 달려 있습니다. 그렇더라도 이를 영구적 해결책으로 볼 수는 없습니다. 단기적으로는 BAM이 프라이버시를 제공하고, 향후 Constellation 버전은 장기 대안으로 임계값 암호화를 검토할 가능성이 큽니다.

Internet Capital Markets의 인프라를 지향하는 프로토콜에서 부분 은닉은 의미 있는 진전이지만 종착지는 아닙니다. 남은 공백은 공정한 시장 구조와 현재보다 덜 불공정할 뿐인 시장 구조의 차이입니다. 

프로토콜 복잡성

Constellation은 Solana 출범 이후 제안된 가장 구조적으로 야심 찬 업그레이드입니다. 세 가지 새 노드 역할, UTC 실제 시각 동기화에 의존하는 새 타이밍 모델, 새로운 소거 코딩 단계, 새 메시지 유형, 새 장애 모드를 도입합니다. 모두 아직 메인넷에 출시되지 않은 Alpenglow 위에 추가됩니다. 지금이 이 복잡성을 감수할 적기인지에 관한 질문은 단순한 낙관론 이상으로 진지하게 검토해야 합니다.

Solana는 2021년과 2022년에 네트워크를 괴롭힌 여러 중단 사태로 악명 높은 평판을 얻었습니다. 이 중단에는 공통점이 있습니다. 실제 부하 조건에서 새롭고 처리량이 높은 프로토콜의 예외 상황을 추론하기가 본질적으로 어려워 발생했습니다. 이후 최근까지 네트워크가 달성한 2년 이상의 가동 시간은 반복 개선의 고통스러운 과정에서 얻은 진정한 이정표입니다. 이 실적은 Solana의 성숙도를 신뢰할 근거가 됩니다. 

이제 Constellation 규모의 모든 프로토콜 수준 변경은 Agave와 Firedancer에 동시에 구현되어야 합니다. 두 독립 개발팀이 모두에게 새로운 프로토콜 의미론, 예외 상황, 타이밍 가정에 합의해야 합니다. Alpenglow만으로도 이를 달성하는 복잡성이 이미 상당하며 Constellation은 이를 더욱 높입니다. 진행에 반대한다는 뜻이 아닙니다. Constellation의 최종 SIMD에 다중 클라이언트 구현을 위한 명확한 계획이 포함되어야 한다는 주장입니다.

금융 기관이 온체인으로 진입하기 시작했습니다. 대규모 중단이 초래할 평판 및 경제적 피해는 2021년보다 실질적으로 커졌습니다. 커뮤니티는 Constellation이 도입하는 복잡성을 솔직히 인정해야 합니다. 최종 SIMD는 글로벌 금융 시스템에 걸맞은 엄밀함으로 접근해야 합니다. 

자연스럽게 왜 지금이어야 하는지 의문이 생깁니다. 정말 이런 업그레이드의 위험을 감수해야 할까요? 변화를 완화하기 위해 점진적으로 적용할 업그레이드는 없을까요? 앞서 살펴본 비동기 실행과 슬래싱은 점진적 대안이 가능함을 시사합니다. 다양한 보완 업그레이드를 단계적으로 배포해 생태계가 혜택을 얻는 Constellation 로드맵도 가능합니다. 이를 신중함으로 볼지 감속주의로 볼지는 기술만큼 가치관의 문제이며, 합리적인 사람도 의견이 다를 수 있습니다. 우리는 금융 시스템만큼이나 의미의 시스템을 구축하고 있습니다.

실제로 이미 그렇게 진행되고 있습니다. Anza는 200ms 슬롯과 2슬롯 리더 시간 창이 Constellation보다 먼저 출시된다고 확인했습니다. 즉, Solana는 MCP의 모든 복잡성을 도입하지 않고도 커뮤니티가 제기한 순서 지연 시간 우려 일부를 해결하는 의미 있는 성능 개선을 먼저 얻게 됩니다. 다음 섹션에서 이를 다룹니다. 200ms 슬롯으로 Solana의 확인 경로가 Constellation의 예상 오버헤드에 충분히 가까워져 MCP의 한계 비용이 작아진다면 정치적 설득은 훨씬 쉬워집니다. 하지만 기존 거래 주체들이 200ms를 “충분히 좋다”고 인식하면 Constellation의 시급성은 줄어듭니다. 200ms 슬롯과 Constellation이 적용된 200ms 슬롯을 비교한 지연 시간 전망은 커뮤니티가 추가 비용과 추가 보장을 비교하는 데 도움이 됩니다. 물론 Constellation의 최종 SIMD와 구현 제안이 나올 때까지 기다려야 합니다.

진행을 지지하는 가장 강력한 논거는 Alpenglow가 만드는 기회입니다. Constellation은 Alpenglow의 보안 모델을 이어받고, Rotor를 데이터 전파 계층으로 사용하며, Tower BFT의 복잡성 제거에서 이점을 얻습니다. Alpenglow 위에 MCP를 추가하는 한계 비용은 미래 합의 설계에서 처음부터 시작하는 비용보다 낮습니다. 경쟁자들도 MCP의 온체인 도입을 검토하고 있으며, 검열 저항성을 향후 업그레이드 주기로 미루면 자체적인 복잡성과 정치적 역풍이 필연적으로 발생하므로 기다리는 데도 비용이 듭니다.

지금이 아니라면 언제일까요?

복잡성에는 타당한 이유가 있지만, 엄밀한 명세와 단계적 배포, 그리고 현재 커뮤니티가 이론만으로 논의하는 지연 시간 및 대역폭 주장에 대한 실증 검증을 통해 그 타당성을 입증해야 합니다. 

Constellation은 IBRL에 부합하는가?

순서 지연 시간과 포함 지연 시간

Constellation에 대한 Solana 커뮤니티의 초기 반응은 적어도 매우 양극화되었습니다. 이 반응을 통해 외교적 답변이 아니라 정확한 답변이 필요한 중요한 논쟁이 드러났습니다. 가장 날카로운 표현은 “MCP와 IBRL은 근본적으로 양립할 수 없다”고 주장한 Cavey의 게시물이었습니다. 그는 MCP가 시장 구조를 개선하려는 시도로 대역폭을 명백하게 줄이고 지연 시간을 늘린다고 주장합니다. 이에 대한 Toly의 답변도 똑같이 직설적이었습니다. “틀렸습니다. MCP 없이는 포함 지연 시간을 줄일 방법이 없습니다.”

기술적으로는 둘 다 맞습니다. 서로 다른 것을 측정하고 있습니다.

MCP는 포함 지연 시간을 줄이고 순서 지연 시간을 늘립니다. 둘은 같은 속성이 아니며, 이를 혼동하는 것이 현재 논쟁에서 발생하는 혼란 대부분의 원인입니다.

순서 지연 시간은 트랜잭션 제출부터 실행까지 걸리는 시간입니다. MCP에서는 필연적으로 늘어납니다. 증명자 라운드, 50ms 주기 시간 창, 배치 조합 단계가 모두 협조적인 리더에게 직접 제출하는 현재 TPU 경로에는 없는 시간을 더하기 때문입니다. 합리적 주체가 여러 제안자에게 전송하면 대역폭을 더 소비한다는 비판은 맞습니다. 병합 시간 창이 지연 시간을 더한다는 주장도 맞습니다. 모두 강경 검열을 제거하기 위한 절충 비용이며, 측정해 커뮤니티에 제시해야 합니다.

포함 지연 시간은 유효하고 수수료 경쟁력이 있는 트랜잭션의 포함이 보장되는 시간 창입니다. 현재의 단일 리더 모델에서는 이 보장에 사실상 상한이 없습니다. 특정 트랜잭션을 지연하거나 제외하려는 리더는 그렇게 할 수 있으며, 이를 막을 프로토콜 메커니즘이 없습니다. 사용자가 이미 겪는 지연 시간에는 보류, 일정 조정, 타이밍 게임에서 발생하는 모든 마찰과 리더가 강제하는 선택적 순서가 포함됩니다. 실제 확인 시간에는 이러한 게임의 지연이 포함되므로 순사용자 경험이 개선될 수 있다는 반론은 이 관점에서 방향상 맞으며, 현재 X에서 진행 중인 커뮤니티 논의도 이를 뒷받침합니다. 

진짜 질문은 어떤 지연 시간을 최적화할지입니다.

FIFO, FCFS, FBO 비교

어떤 지연 시간을 최적화할지 살펴보기 전에 커뮤니티가 동시에 논의해 온 관련 쟁점을 이해할 필요가 있습니다. MCP가 FIFO와 호환되는지에 관한 문제입니다.

FIFO(First In, First Out)는 트랜잭션이 도착한 순서대로 처리되는 일반적인 순서 원칙입니다. Umberto는 그 답이 본질적으로 복합적이라고 상세히 주장했습니다. MCP는 “확률적 FIFO”를 만들 수 있지만 특정 인프라 조건에서만 가능합니다. 사용자가 검열을 피할 만큼 충분한 제안자와 지리적으로 가깝고, 해당 제안자들이 보장된 포함에 필요한 40% 증명 임계값에 빠르게 도달할 만큼 증명자와 가까우면 사용자는 실질적으로 FIFO 포함을 경험합니다. 즉, 경쟁자가 트랜잭션을 관찰하고 대응할 시간을 갖기 전에 트랜잭션이 포함됩니다. 경쟁은 실행이 아니라 포함에서 끝납니다. 이 조건에서 MCP는 프로토콜 규칙이 아니라 창발적 속성으로 FIFO에 근접합니다.

문제는 Solana의 현재 인프라가 이 조건을 충족하지 못한다는 것입니다. 지분이 소수 지역에 집중되어 있어 정족수 형성은 지분이 밀집한 지점에 도달해야 한다는 제약을 받습니다. 이러한 집중은 “지리적 우위”를 가진 관찰자가 전달 중인 트랜잭션을 프런트러닝할 수 있는 시간 창을 만듭니다. Constellation 배포와 함께 확률적 FIFO에 필요한 지리적 분산과 증명자 밀도가 확보되는지는 프로토콜 설계 자체만큼 중요합니다. 검열 저항성을 보장하지만 인프라가 드물게 배치되어 지연 시간 기반 프런트러닝을 허용하는 프로토콜은 백서가 약속한 시장 공정성을 제공하지 못합니다.

관련은 있지만 별개의 질문은 Constellation이 FCFS를 구현할 수 있었지만 선택하지 않았는지입니다. FIFO가 창발적인 인프라 속성이라면 FCFS(First Come, First Served)는 먼저 도착한 트랜잭션이 결정론적으로 먼저 처리되도록 하는 구체적인 프로토콜 규칙입니다. Constellation도 결정론적으로 순서를 정한다는 점에 유의해야 합니다. 각 배치 안에서 우선순위 수수료에 따라 트랜잭션을 정렬합니다. 따라서 쟁점은 프로토콜이 순서를 강제하는지가 아니라 도착 시간이 우선순위 수수료보다 순서를 우선 결정해야 하는지입니다.

최근 논쟁에서는 처음 제기된 것보다 더 근본적인 반론이 나왔습니다. 무신뢰 환경에서는 FCFS를 전혀 강제할 수 없을지 모릅니다. 검증인은 온체인 기록을 남기지 않고 트랜잭션 도착 순서를 허위로 표현할 수 있습니다. 전통적 의미에서 타이밍 조작을 슬래싱할 수 없게 만드는 것과 같은 증거 부재 문제이며, 슬래싱 하위 섹션에서 다룬 통계적 패턴 탐지 접근법 같은 더 창의적인 해결책이 필요할 수 있습니다. 정직한 검증인은 따르지만 부정직한 검증인은 조용히 무시할 수 있는 프로토콜 규칙은 의미 있는 보장이 아닙니다. 이에 따라 Constellation이 FCFS를 제외한 이유도 설명이 필요한 설계 선호에서, 최소한 현재 가정 아래 무허가 검증인 집합에서는 FCFS를 Solana의 강력한 프로토콜 속성으로 아직 구현할 수 없다는 인식으로 바뀝니다. 현재 가정 아래 무허가 검증인 집합에서 FCFS를 실제로 강제할 수 없다면 SIMD는 이 제약을 명시하고 우선순위 수수료 기반 순서를 올바른 기본 설계로 정당화해야 합니다. FCFS를 구현 불가능할 수 있는 속성으로 설명하지 않고 Constellation이 선택하지 않은 실행 가능한 대안인 것처럼 커뮤니티가 논의하게 두면 더 큰 마찰이 생깁니다.

고정된 시간 안에서 우선순위 수수료로 순서를 정하는 방식은 새로운 절충안이 아닙니다. 이는 상당한 학문적 지지를 받는 시장 미시구조 설계인 빈번한 배치 경매(FBA)로 알려져 있습니다. 예를 들어 Budish, Cramton, Shim은 The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response(2015)에서 균일 청산 가격을 사용하는 이산 시간 배치 경매가 연속 시간 시장이 만드는 속도 경쟁을 없앤다고 주장합니다. 지연 시간 기반 경쟁을 가격 기반 경쟁으로 대체합니다. Constellation은 이를 바탕으로 우선순위 수수료에 기반한 Fixed Batch Ordering(FBO)을 도입합니다. Constellation의 50ms 주기가 이를 구현합니다. 각 배치 안에서 트랜잭션은 도착 시간이 아니라 수수료로 경쟁하며 같은 배치의 모든 트랜잭션은 동일한 순서 처리 방식을 적용받습니다. 앞서 Solana에서 아직 대규모로 존재하지 않는다고 설명한 바로 그 애플리케이션 유형입니다. 

FIFO, FCFS, FBO 논쟁은 대부분 같은 근본적인 우려를 다룹니다. 검열 저항성이 보장된 뒤 누가 순서를 통제하며, Constellation이 만들려는 시장 구조가 실제로 공정한지 아니면 현재보다 덜 불공정할 뿐인지에 관한 문제입니다. Constellation은 가장 분명한 형태의 조작을 막습니다. 무엇이 이를 대체할지는 백서가 SIMD의 결정으로 미룬 선택에 달려 있습니다.     

그렇다면 무엇을 최적화해야 할까요?

순서 지연 시간은 기존 거래 애플리케이션, 즉 AMM, 자기자본 거래 데스크, CLOB에 가장 중요합니다. 이러한 애플리케이션은 가장 빠르고 수수료 경쟁력이 높은 주체가 이긴다는 가정에 맞춰 설계되었고, 이에 따라 인프라를 구축했습니다. 거래는 물리 법칙의 제약만 받아야 하며 Solana에서 비할 데 없는 사용자 경험을 제공해야 합니다. 일부 사용자에게 Constellation은 가장 중요한 지표에서 퇴보입니다. Solana가 Ethereum이 한때 저지른 치명적인 실수를 반복할 수 있다는 우려가 있습니다. 성능보다 시장 구조를 우선하면 실행이 체인 밖으로 떠날 수 있습니다. 논의할 가치가 있는 실질적 위험입니다.

Constellation이 지원하려는 금융 애플리케이션, 즉 온체인 경매, 신뢰할 수 있는 포함 보장을 갖춘 오더북, 검열 저항성 DeFi 프로토콜에는 포함 지연 시간이 올바른 지표입니다. 명목상 확인이 아무리 빨라도 프런트러닝되거나 선택적으로 지연될 수 있는 지정가 주문은 거래소 방식 주문보다 보장이 약합니다. 이제 Solana는 순서가 실행 가격에 영향을 주지 않아야 하는 균일 청산 가격 기반 배치 경매 거래 애플리케이션을 지원할 수 있습니다. 현재 Solana에는 포함 보장이 없기 때문에 이러한 애플리케이션 유형이 거의 존재하지 않습니다. Constellation은 Solana에서 아직 대규모로 존재하지 않는 사용자에게 최적화한 설계에 지나치게 집중하고, 현재 존재하는 사용자를 희생한다고도 볼 수 있습니다. 핵심 기여자들도 이미 이 주장을 제기하고 있습니다.   

순서 지연 시간 우려는 Solana가 현재 무기한 선물 거래에서 Hyperliquid에 상당한 입지를 잃고 있다는 맥락에서 봐야 합니다. Hyperliquid는 탈중앙화를 표방하지 않는 중앙화된 시퀀서를 사용하는 전용 무기한 선물 거래소지만, 고도화된 트레이더와 애플리케이션이 요구하는 매력적인 1밀리초 미만 실행 경험을 제공합니다. Hyperliquid는 암호화폐를 진정한 “암호화폐”로 만드는 핵심 원칙을 희생하면서 전문가가 실제로 사용하고 싶은 제품을 구축하기로 의도적으로 선택했습니다. Constellation의 잠재적 위험은 확인 경로에 통신 오버헤드와 증명 라운드를 추가함으로써 Hyperliquid와 같은 절충안을 반대 방향으로 택한다는 점입니다. 비판자들은 현재 Solana가 중앙화된 거래 애플리케이션과 경쟁할 수 있게 하는 잠재적 성능 우위를 희생하면서도 그 절충안을 정당화할 금융 애플리케이션은 아직 없다는 점을 부정적으로 바라보며 강하게 비판합니다.

이는 쉽게 일축해서는 안 될 우려입니다. 순서 지연 시간과 포함 지연 시간 중 무엇을 최적화해야 하는지에 관한 앞선 질문을, 현재 경쟁 상대를 고려할 때 Solana가 그런 절충을 감당할 수 있는지로 바꿔 물을 수 있습니다.

하지만 더 깊은 문제가 있습니다. Hyperliquid와의 비교는 IBRL의 의미가 시간이 지나며 바뀌었을 수 있음을 보여줍니다. Toly와 Raj가 Solana를 구축한 원래 동기는 검열 저항성이었습니다. “DeFi 제품이 수십억 명의 사용자와 기기를 유치하려면 검열 저항성을 확장해야 합니다….해결해야 할 가장 중요한 단일 문제이며, Solana를 구축한 모든 동기입니다.” IBRL은 훨씬 나중에 이 사명을 엔지니어링 관점에서 표현한 것입니다. 중요한 지표에서 탈중앙 네트워크가 중앙화 인프라를 능가할 만큼 빠르게 구축하자는 뜻입니다. 이후 IBRL은 자체적인 기술 낙관주의적 의미를 얻어 Solana의 문화적 시대정신 전반에 퍼졌습니다. 엔지니어링 명령이자 문화적 암호이며 세속적 기도입니다. 많은 사람에게 IBRL은 수단이 아니라 목표가 되었습니다. 순서 지연 시간 최소화가 원래 지원하려던 검열 저항성 목표와 분리된 그 자체의 목적이 되었습니다.

이러한 변화가 실제로 발생했다면, 그리고 발생한 것으로 보인다면 Constellation은 강한 문화적 저항에 부딪힐 것입니다. 논쟁적인 인플레이션 감축 제안으로 거버넌스 투표를 통과하지 못한 SIMD-228을 커뮤니티가 거부한 전례를 보면 새로운 역학도 아닙니다. 대체로 유익한 제안도 고착된 커뮤니티의 선입견과 충돌하면 실패할 수 있습니다. Constellation은 대역폭 및 지연 시간 비용이 실제로 존재하지만 사용자 경험에 대한 순효과는 정량화되지 않았다는 점에서 더 복합적입니다. 데이터 없이 어느 쪽으로든 확정적인 결론을 내리기는 이릅니다. 커뮤니티에 부족하고 Anza가 설득력 있는 SIMD를 위해 제공해야 하는 것은 현실적인 네트워크 조건에서 확인 경로가 어떻게 나타나는지 보여주는 실증 데이터입니다. Alpenglow는 IBRL에 부합했기 때문에 이런 문제를 겪지 않았습니다. 트랜잭션 최종 확정 시간을 100배 줄이고 합의를 간소화했습니다. Constellation은 직관적으로 설득하기가 더 어렵지만, 향후 벤치마크가 뒷받침한다면 실질성은 결코 떨어지지 않습니다.

커뮤니티는 검열 저항성 업그레이드를 애초에 최적화 대상으로 삼지 않은 성능 지표로 평가할 것으로 보입니다. 더 생산적인 질문은 그 절충이 가치가 있는지입니다. 실제로 측정 가능한 비용이 있습니다. 일부 추가 순서 지연 시간과 대역폭을 대가로 어떤 리더도 트랜잭션을 선택적으로 제외할 수 없다는 강력하고 프로토콜이 강제하는 보장을 얻습니다. Solana가 현재 유치하려는 금융 애플리케이션의 전제 조건입니다.

IBRL이 원래 지향하려 했던 바를 올바르게 해석하면 Constellation은 IBRL에 부합한다고 봅니다. 커뮤니티가 같은 결론에 도달할지는 기술적 장점보다 실증적 근거를 제시하고 설계 선택을 충분히 설명하는지에 더 크게 좌우될 것입니다.  

결론

Constellation은 대규모 프로덕션 블록체인에 MCP를 도입하기 위한 최초의 공식 프로토콜 수준 제안입니다. 강경 검열을 구조적으로 해결해 충분한 정족수의 증명을 받은 수수료 경쟁력 있는 트랜잭션을 유효한 블록에서 제외할 수 없게 합니다. 이 암호학적 보장은 Solana에서 구축할 수 있는 것의 범위를 바꿉니다. 

Constellation이 의도적으로 미룬 문제도 똑같이 중요합니다. 수신 제안자만 트랜잭션 내용을 보는 제출 모델을 통해 콘텐츠 노출 순서 조작을 부분적으로 완화하지만, 남은 공격 표면은 사용자가 제출하는 제안자 수에 따라 커집니다. 타이밍 및 지연 시간 조작은 현재 설계에서 처벌할 수 없는 가장 큰 미해결 문제로 남습니다. 비동기 실행, 슬래싱, 은닉 같은 잠재적 해결 경로는 확인되었지만 구체화되지 않았으며, 각각 고유한 복잡성을 도입합니다. Constellation 백서는 이러한 한계를 솔직하게 밝히며, 최종 SIMD도 그래야 합니다.

Constellation이 제기하는 가장 어려운 질문은 도입하는 절충안을 Solana가 감당할 수 있는지입니다. 아직 정량화되지 않은 실제적이고 측정 가능한 순서 지연 시간 및 대역폭 비용이 있습니다. 마찬가지로 아직 대규모로 이를 정당화할 애플리케이션 기반이 없는 포함 보장이라는 실제적이지만 측정되지 않은 이점도 있습니다. 커뮤니티는 현재 Solana에 거의 존재하지 않는 금융 애플리케이션을 위한 인프라에 투자하라는 요청을 받고 있으며, 그 대가로 현재 존재하는 거래 애플리케이션이 피해를 볼 수 있습니다. 선견지명인지 시기상조인지는 커뮤니티가 아직 갖지 못한 데이터에 달려 있습니다.

Constellation의 성패는 궁극적으로 현실적인 조건에서 수행할 향후 실증 벤치마크에 달려 있습니다. 200ms 슬롯만 사용할 때와 Constellation을 적용한 200ms 슬롯에서 확인 경로가 어떻게 달라지는지는 Anza가 제공할 수 있는 가장 중요한 단일 수치입니다. 그전까지 커뮤니티는 정량화할 수 없는 절충안을 논의하게 됩니다.

Constellation은 Alpenglow가 연 프로토콜 로드맵에서 올바른 다음 단계라고 봅니다. Solana가 처음 지원하려 했던 IBRL의 의미에 따르면 IBRL에 부합합니다. 다만 이 견해는 SIMD가 명세, 단계적 배포, 테스트, 그리고 도입을 요청받는 커뮤니티에 제시할 실증적 근거에서 글로벌 금융 시스템에 걸맞은 엄밀함을 확보한다는 조건에 달려 있습니다.

추가 자료

• Budish, E., Cramton, P., and Shim, J. (2015). 고빈도 거래 군비 경쟁: 시장 설계 대응책으로서의 빈번한 배치 경매. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: 탈중앙 거래소의 프런트러닝, 트랜잭션 재정렬, 합의 불안정성. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., and Clark, J. (2019). SoK: 투명한 부정행위: 블록체인 프런트러닝 공격. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., and Resnick, M. (2025). Multiple Concurrent Proposers: 그 이유와 방법. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., and Wattenhofer, R. (2026). Solana Constellation: Internet Capital Markets. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. and Marsh, B. (2025). Multiple Concurrent Proposer 블록체인의 MEV. https://arxiv.org/abs/2511.13080
• Yakovenko, T., and Gokal, R. 블록체인 개발자는 잘못된 문제에 집중하고 있습니다. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem