솔라나 SIMD-0649 — 수수료 순서 규칙, 머지 없이 닫혔어요

솔라나 블록 안의 거래 순서를 프로토콜 규칙으로 못 박자는 제안이 일단 멈췄어요. Anza 의 맥스 레스닉(Max Resnick)이 올린 SIMD-0649 는 2026년 9월 21일 풀 리퀘스트로 열렸고, 9월 25일 머지 없이 닫혔어요. 저장소 관리자는 "논의가 더 필요해서 닫아요, 클라이언트 개발자들의 동의가 더 필요해요"라고만 남겼어요.

SIMD-0649 가 만들려던 규칙 두 개

제안서는 블록이 유효한지 판단하는 규칙을 두 개 새로 넣자고 했어요.

첫째는 순서 규칙이에요. 리더(leader) — 그 슬롯에 블록을 만드는 검증자예요 — 는 엔트리 배치 안의 거래를 우선순위가 낮아지는 방향으로만 기록해야 해요. 엔트리 배치(entry batch)는 블록을 쪼갠 데이터 묶음 하나예요. 뒤에 적힌 거래가 앞 거래보다 우선순위가 높으면 그 블록은 무효가 돼요.

둘째는 배치 최소 크기 규칙이에요. 블록의 마지막 엔트리 배치를 뺀 모든 배치는 FEC 세트 2개, 데이터 슈레드 64개 이상을 차지해야 해요. 제안서는 이게 엔트리 데이터로 약 63KB 라고 적었어요.

무효가 된 블록은 검증자가 투표하지 않아요. 지금 블록 비용 한도를 넘긴 블록을 죽은 슬롯으로 처리하는 것과 같은 방식이에요.

우선순위를 계산하는 식

제안서가 쓴 계산식은 이래요.

priority = reward × 1,000,000 ÷ (cost + 1)

• reward 는 리더가 그 거래로 받는 램포트예요. 지금 수수료 규칙으로는 우선순위 수수료 전액에, 기본 수수료에서 태우지 않은 절반을 더한 값이에요. 기본 수수료는 50% 를 태워요.
• cost 는 실행 전에 계산하는 요청 비용 단위예요. 블록 공간을 미리 잡을 때 쓰는 바로 그 값을 써야 해요.

계산은 모두 부호 없는 64비트 정수로 하고, 나눗셈도 정수 나눗셈이에요. 우선순위가 같은 거래끼리는 순서를 어떻게 둬도 괜찮아요.

투표 거래는 빠져요. 블록 단위 투표 비용 한도가 쓰는 분류를 그대로 가져와서, 단순 투표 거래는 배치 어디에 있어도 돼요. 제안서는 투표가 수수료보다 지연 시간에 따라 움직이기 때문이라고 설명해요. 리더 자기 거래를 포함해 나머지는 전부 규칙을 지켜야 해요.

이 규칙을 만들려던 이유

제안서는 지금 솔라나 메인넷에 서로 다른 스케줄러 구현이 최소 13개 돌고 있다고 적었어요. 스케줄러(scheduler)는 리더가 어떤 거래를 넣고 어떤 순서로 줄 세울지 정하는 부분이에요. 구현이 이만큼 갈리면 어떤 리더가 내 거래를 어디에 놓을지 밖에서 알기 어려워요. 리더 행동을 예측하던 도구도 계속 따라가기 힘들어졌다고 적었어요.

순서를 리플레이(replay) — 다른 검증자가 블록을 다시 실행해 확인하는 단계 — 에서 검사하게 만들면, 클라이언트가 무엇이든 같은 규칙이 걸려요. 비용은 거래당 정수 비교 한 번이라 이미 하는 서명 검증에 비하면 거의 없다고 봤어요.

이 제안이 막지 못하는 것

제안서가 "목표가 아니다"라고 직접 적어 둔 것들이에요.

• 어떤 거래를 블록에 넣을지는 여전히 리더가 정해요. 슬롯 전체의 순서도 정해지지 않아요. 리더는 거래를 다음 배치로 미룰 수 있어요.
• 리더가 자기 거래를 앞으로 당기는 것도 막지 못해요. 우선순위 수수료는 SIMD-0096 이후 전액 리더에게 돌아가요. 그래서 리더는 자기한테 수수료를 내서 우선순위를 원하는 만큼 올릴 수 있어요. 실제로 드는 비용은 기본 수수료에서 태우는 몫뿐이에요.
• 리플레이가 순서를 고쳐 주지도 않아요. 기록된 순서가 원본이고, 규칙에 어긋나면 블록을 버려요. getBlock 같은 RPC 응답도 지금처럼 기록된 순서를 그대로 돌려줘요.
• 리더가 자기 저가 거래로 배치를 채워 일찍 닫는 것도 그대로 가능해요. 제안서는 이걸 막으려 하지 않았고, 대신 그런 행동이 리더의 수수료 예산과 블록 공간을 쓰고 원장에 흔적을 남긴다고만 적었어요.

대가로 생기는 지연

단점 항목에도 숫자가 적혀 있어요. 리더는 배치 하나의 내용을 먼저 확정하고 정렬한 다음에 기록해요. 그래서 창이 닫힌 뒤에 도착한 높은 우선순위 거래는 지금 배치 앞으로 끼어들지 못하고 다음 창으로 가요. 바쁜 리더에서 배치를 최소 크기 가까이 유지하면 이 지연은 수십 밀리초 수준이라고 적었어요.

거래가 적을 때는 반대 문제가 생겨요. 마지막이 아닌 배치는 FEC 세트 2개가 찰 때까지 내보낼 수 없어요. 다만 Agave 와 Firedancer 둘 다 이미 이 크기를 목표로 배치를 만들고 있어서 바뀌는 폭은 작다고 봤어요.

닫힌 과정과 지금 상태

이 제안은 2026년 8월 20일 열린 논의 605번 "Enforce priority ordering within each EntryBatch" 에서 시작했어요. 제안서 문서의 작성일은 9월 2일, 상태는 초안(Draft)이었어요. 풀 리퀘스트는 9월 21일에 열렸어요.

솔라나 SIMD 는 머지하려면 Anza 팀원 1명 이상과 Firedancer 팀원 1명 이상의 승인이 필요해요. 9월 25일 저장소 관리자가 논의 605번을 가리키며 "클라이언트 개발자들의 동의가 더 필요해요"라고 적고 닫았어요.

그래서 지금 메인넷에는 이 규칙이 없어요. 제안서 자체도 기능 게이트로 켜는 방식이라, 켜지기 전까지 리플레이는 두 규칙을 검사하지 않고 블록을 지금처럼 처리해요. 거래 형식, RPC 응답, 실행 방식도 바뀌지 않아요.

정리

• SIMD-0649 는 엔트리 배치 안의 거래를 우선순위 수수료 순으로 기록하게 만들고, 어기면 블록을 무효로 하자는 제안이었어요. 9월 21일 열려 9월 25일 머지 없이 닫혔어요.
• 통과했더라도 리더의 거래 선택권, 슬롯 전체 순서, 리더의 자기 거래 우대는 그대로 남아요. 제안서가 직접 그렇게 적어 뒀어요.
• 지금 솔라나 메인넷 동작은 달라진 게 없어요. 기능 게이트로 켜기 전까지는 검사 자체가 없어요.

솔라나에서 거래 순서에 민감한 주문을 넣고 있다면, 논의 605번과 풀 리퀘스트 649번의 댓글을 직접 열어 보세요. 제안이 다시 올라올 때 무엇이 바뀌는지는 그 두 곳에 먼저 적혀요.