1) 로컬 수수료로 전 네트워크 ‘가스 폭탄’ 방지
- 이더리움은 인기 민팅 하나로 가스비 폭등
- 솔라나는 ‘계정 단위’ 수수료라 특정 앱 혼잡이 전체로 퍼지지 않음
- 단, 아직 수수료 책정 최적화는 미비
→ 예: TRUMP·MELANIA 밈코인 때 일부 과도 지불 사례
2) Jump의 Firedancer(새 밸리데이터 클라이언트)
- 지금 검증자 대부분 @jito_sol 클라이언트 사용
- Jump가 ‘Firedancer’라는 초고성능 대안 개발 중 → 메인넷 가동되면 네트워크 다양성↑, 안정성↑
- 빌더 입장에선 직접 작성할 필요 없지만, MEV 등 새 기능 가능성 열림
3) 계정 구조로 인한 병렬처리, 장점 vs 복잡함
- 솔라나는 데이터·실행 분리해 대규모 병렬 트랜잭션 가능 (초고속 TPS)
- 단, 트랜잭션에 필요한 모든 계정을 미리 지정해야 → 예: Raydium 스왑 시 20개 계정?
- 속도 얻었지만, 구현 난이도도 어려워짐
4) 앵커(Anchor) 프레임워크
- 솔라나 네이티브 코딩은 빡셈 → 앵커가 보일러플레이트 제거, 훨씬 편리
- 단점: 리소스 사용 많아, 복잡 대규모 로직(오더북 등)은 compute 제한에 부딪힐 수도
- “일반 dApp엔 앵커가 완전 꿀, 초고성능 프로젝트엔 신중”
5) PDA(Program Derived Address)
- 솔라나의 컨트랙트엔 프라이빗키가 없음
- 대신 PDA(프로그램 유도 주소)로 트랜잭션 서명 권한 행사
- 예: Orca 풀에 입금 시, 입금자+풀PDA가 함께 상태 변경
이거 이해하면 솔스캔 추적할 때 편함
6) 컴퓨트 버젯(Compute Budget)
- 솔라나 트랜잭션이 소비할 최대 연산량(컴퓨팅 리소스) 제어
- 복잡 로직·루프 많은 트랜잭션은 트랜잭션에 Compute Budget 인스트럭션 추가해 한도 상향 가능
- EVM의 gas limit 느낌. 병렬처리에 특화된 솔라나지만, 리소스 관리는 여전히 중요
7) 렌트(Rent) 수수료
- 솔라나는 체인에 데이터 남길 때 임시 보증금(=렌트) 내야 → 계정 닫을 땐 돌려받음
- 그래서 전송 후 토큰 계정 닫으면 SOL이 ‘조금 더’ 생기는 경우도
- dApp 만들 때 “렌트 환급” 로직 챙기면 유저 친화적
8) token-2022: 새 토큰 스탠다드
- 메타플렉스 등이 만든 기존 SPL 토큰 외에 token-2022 도입 → 프라이버시 기능·장기 권한 위임 등 새 기능 가능
- 다만 지갑·DEX 호환 아직 낮아 실제 사용은 좀 더 기다려야
9) 리워드형 LST(예: jitosol)
- stETH처럼 “rebase로 갯수 늘리는” 구조 대신, 솔라나는 가격이 오르는 식(병렬 처리 구조상 rebase가 귀찮음)
- 예: jitosol은 수량 고정, 대신 SOL 대비 교환비율이 올라가며 이자·MEV 수익 반영
10) SIMD: 솔라나판 EIP
- 이더리움 EIP처럼, 솔라나에는 SIMD(Solana Improvement Docs)
- “SIMD-96” 같은 이슈 뜨면 솔라나 핵심 개선안일 가능성 큼 → 주시하면 솔라나 미래 예측 도움