뉴스
솔라나 트랜잭션 크기 4,096바이트로 — 9월 15일 에폭 1035 적용
솔라나가 한 트랜잭션에 담을 수 있는 최대 크기를 1,232바이트에서 4,096바이트로 늘렸어요. 메인넷 에폭 1035, 한국 시간 9월 15일 오전 10시에 켜졌어요. 지갑에서 SOL 보내는 건 그대로예요.

3줄 요약
- 1솔라나 최대 트랜잭션 크기가 1,232바이트에서 4,096바이트로 늘었어요. 약 3.3배예요.
- 2메인넷 에폭 1035, 세계 표준시 9월 15일 새벽 1시(한국 시간 오전 10시)에 적용됐어요.
- 3v1이라는 새 형식이 생겼고 기존 형식도 그대로 써요. 지갑에서 SOL을 보내는 일상적인 사용은 바뀌지 않아요.
AI가 쓴 글이에요. 출처를 바탕으로 자동으로 작성·발행돼요. 사람이 검수하지 않으니 사실과 다를 수 있어요. 중요한 내용은 아래 출처 링크에서 원문을 확인해 주세요.
솔라나가 한 트랜잭션에 담을 수 있는 최대 크기를 1,232바이트에서 4,096바이트로 늘렸어요. 메인넷 에폭 1035, 세계 표준시 9월 15일 새벽 1시(한국 시간 같은 날 오전 10시)에 켜졌어요. 지갑에서 SOL이나 토큰을 보내는 일상적인 사용에는 바뀌는 게 없고, 앱이나 데이터 서비스를 만드는 분만 준비할 게 있어요.
이번 변경은 솔라나 개선 제안(SIMD) 두 건으로 나뉘어요. SIMD-0296이 크기 상한을 올리고, SIMD-0385가 v1이라는 새 트랜잭션 형식을 정해요. 솔라나 공식 안내에 따르면 메인넷·테스트넷·데브넷 모두 적용이 끝난 상태예요.
1,232에서 4,096바이트로
트랜잭션 — 블록체인에 한 번에 기록되는 작업 묶음이에요. 솔라나는 이 묶음 하나가 1,232바이트를 넘지 못하게 막아 뒀어요. 이번에 그 상한이 4,096바이트가 됐어요. 약 3.3배예요. 4,096바이트는 컴퓨터가 메모리를 다루는 기본 단위인 4KiB 페이지와 크기가 같아요.
상한이 낮으면 작업 하나를 여러 트랜잭션으로 쪼개야 했어요. 쪼개면 중간에 하나만 실패해도 앞뒤가 어긋나요. 솔라나 재단은 코인텔레그래프에 영지식 증명, 다중 서명, 새로운 서명 방식처럼 예전에는 여러 번에 나눠 보내야 했던 작업을 한 번에 담을 수 있게 됐다고 설명했어요.
- 영지식 증명(ZK proof) — 내용을 밝히지 않고 "맞다"는 것만 증명하는 방식이에요. 증명 데이터가 커서 1,232바이트에 잘 안 들어갔어요.
- 다중 서명(멀티시그) — 여러 명이 함께 승인해야 돈이 나가는 지갑이에요. 서명이 늘수록 용량을 많이 써요.
- 여러 단계를 묶은 거래 — 전부 되거나 전부 안 되게, 한 덩어리로 처리할 수 있어요.
v1 형식은 무엇이 다른가
새 v1 형식은 맨 앞에 0x81이라는 구분 바이트를 붙여요. 이걸로 기존 트랜잭션과 구분해요. 안쪽 구조도 바뀌었어요.
| 항목 | 기존(legacy·v0) | 새 형식(v1) |
|---|---|---|
| 최대 크기 | 1,232바이트 | 4,096바이트 |
| 서명 위치 | 앞쪽 | 트랜잭션 끝 |
| 컴퓨트 유닛·데이터 크기 한도 | ComputeBudget 명령으로 지정 | 정해진 자리에 직접 적음 |
| 우선 수수료 단위 | 컴퓨트 유닛당 마이크로램포트 | 총 램포트 |
| 주소 조회 테이블 | 쓸 수 있음 | 못 씀 |
| 계정 개수 한도 | 64개 | 64개 |
기존 형식이 없어지는 건 아니에요. 공식 안내는 v1이 legacy 트랜잭션과 완전히 호환된다고 적어 뒀어요. 지금 쓰던 방식 그대로 보내도 돼요.
개발하는 분이 확인할 것
솔라나 공식 페이지가 최소 버전을 정리해 뒀어요.
- 자바스크립트 @solana/kit 8.0.0 이상, @solana/web3.js 3.x 는 3.0.0-rc.3 이상
- 러스트 solana 계열 크레이트 4.2.x
- 파이썬 solders 0.29.0
- Go 는 solana-foundation/solana-go 1.23.0
- RPC 노드와 밸리데이터는 Agave 또는 Jito-Solana v4.2.2 이상
트랜잭션을 읽는 쪽은 getTransaction, getBlock, blockSubscribe 를 부를 때 maxSupportedTransactionVersion 값을 1로 넘겨야 해요. 이걸 안 하면 v1 트랜잭션이 하나라도 들어 있는 블록을 통째로 못 읽어요. 코인데스크도 서비스가 v1을 못 읽으면 블록 단위로 실패가 날 수 있다고 짚었어요.
v1으로 보내는 쪽은 세 가지를 챙기면 돼요. 첫째, 컴퓨트 유닛 한도와 불러올 계정 데이터 크기를 직접 적어야 해요. 기본값이 0이라 안 적으면 그대로 0이에요. 둘째, ComputeBudget 명령과 주소 조회 테이블(ALT)은 빼야 해요. 셋째, 우선 수수료를 컴퓨트 유닛당 마이크로램포트가 아니라 총 램포트로 바꿔 적어야 해요.
지갑에 트랜잭션을 넘기기 전에는 그 지갑이 알려 주는 supportedTransactionVersions 를 먼저 확인해 보세요. 지갑이 v1을 아직 안 받으면 기존 형식으로 보내면 돼요.
SOL을 들고만 있는 분은
할 일이 없어요. 거래소에서 SOL을 사고팔거나 지갑끼리 보내는 건 지금까지 쓰던 형식 그대로 돌아가요. 이번 변경은 담을 수 있는 크기를 늘린 것이지, 수수료 계산 방식이나 보유한 SOL 수량에 손을 대는 업그레이드가 아니에요.
다만 쓰는 지갑이나 블록 탐색기에서 일부 거래 내역이 안 보이거나 오류가 뜬다면, 그 서비스가 v1 읽기를 아직 안 붙였을 수 있어요. 앱을 최신 버전으로 올려 보고, 그래도 그러면 해당 서비스 공지를 확인해 보세요.
솔라나는 최근 성능 쪽 변경을 이어 왔어요. 코인텔레그래프에 따르면 2026년 8월에 슬롯 시간을 400밀리초에서 350밀리초로 줄였고, 6월에는 200밀리초까지 더 줄이겠다는 계획을 밝혔어요.
정리
- 솔라나 최대 트랜잭션 크기가 1,232바이트에서 4,096바이트로 늘었어요. 에폭 1035, 한국 시간 9월 15일 오전 10시에 적용됐어요.
- SIMD-0296이 크기를, SIMD-0385가 v1 형식을 정해요. 기존 형식도 계속 쓸 수 있어요.
- 영지식 증명, 멀티시그, 여러 단계를 묶은 거래를 한 트랜잭션에 담을 수 있게 됐어요.
솔라나 위에서 서비스를 만드는 분이라면 오늘 RPC 노드와 라이브러리 버전부터 확인해 보세요. 읽는 쪽에서 maxSupportedTransactionVersion 을 1로 올리는 것만으로도 블록 읽기 실패는 막을 수 있어요.
출처 (4개)
이 글은 아래 출처를 바탕으로 작성됐어요
- 공식
- 공식
- Solana transactions just got more than 3 times bigger, narrowing the gap with Ethereum(2026-09-15)
www.coindesk.com
함께 보면 좋아요

코인풀이 텔레그램 소통방
차트 공부부터 실시간 분석까지, 같이 이야기해요. 새 글도 여기 가장 먼저 올라가요.