Road to Web3 (22) 멀티체인 기초: EVM vs SVM 서명 주소 트랜잭션

이 글은 Ethereum 및 EVM 계열, 그리고 Solana의 SVM을 기준으로 설명합니다.

 

목표는 둘 중 어느 쪽이 더 낫다를 말하는 것이 아니라, 멀티체인 지원이 왜 난이도 폭증인지 운영 관점에서 이해하는 것입니다.

 

0) 요약

• EVM은 계정 nonce 기반 직렬화와 컨트랙트 호출 중심
• SVM은 트랜잭션에 명시된 계정 집합과 병렬 실행 중심

같은 결제나 서명 기능을 만든다고 해도

• 키 타입
• 주소 표현
• 서명 포맷
• 트랜잭션 구조
• 실패 모델
• 인덱싱 방법

이 전부가 달라집니다.

---

 

1) 서명부터 다르다: secp256k1 ECDSA vs Ed25519

1.1 EVM의 기본 서명

• 보통 secp256k1 ECDSA
• 해시 함수는 Keccak-256 계열을 많이 사용
• 트랜잭션 서명은 chain id와 nonce를 포함한 특정 인코딩을 서명한다

1.2 SVM의 기본 서명

• 보통 Ed25519
• 트랜잭션은 메시지 바이트열을 만들고, 거기에 여러 서명이 붙는 형태가 일반적이다

1.3 멀티체인에서 폭발하는 포인트

• 키가 다르면 하드웨어 지갑과 라이브러리 스택이 갈라진다
• 서명 검증 로직도 갈라진다
• 동일한 서명 증거라는 말이 체인마다 다른 바이트 레벨 의미를 가진다

---

 

2) 주소도 다르다: 20바이트 vs 32바이트

2.1 EVM 주소

• 공개키에서 파생된 20바이트 주소를 주로 사용
• 보통 16진수 문자열로 표시한다

2.2 Solana 주소

• 공개키 자체가 32바이트로 주소 역할을 한다
• 보통 base58 문자열로 표시한다

2.3 운영상 함정

• UI 입력 검증이 체인별로 완전히 다르다
• 체크섬, 대소문자 규칙, 인코딩이 서로 다르다
• 같은 문자열이라도 체인에 따라 유효 여부가 갈린다

---

 

3) 트랜잭션이 완전히 다르다: 호출 중심 vs 인스트럭션과 계정 목록

여기서부터 멀티체인이 진짜 어렵습니다.
동일한 결제를 한다고 해도 트랜잭션이 담는 정보가 구조적으로 다릅니다.

3.1 EVM 트랜잭션의 생각 방식

EVM에서 트랜잭션은 보통 다음을 담습니다.

• from, to
• value
• data: 컨트랙트 호출 데이터
• gas 관련 필드
• nonce

즉, 한 문장으로

• 어떤 주소로 무엇을 호출할지와, 얼마를 보낼지를 담는다

입니다.

3.2 SVM 트랜잭션의 생각 방식

SVM에서 트랜잭션은 대략 이렇게 보입니다.

• 최근 블록 해시 또는 nonce 계열 참조값
• 여러 개의 instruction
• instruction마다 프로그램 id와 계정 목록
• 여러 서명자

즉, 한 문장으로

• 어떤 프로그램을 실행할지와, 실행에 필요한 계정들을 명시적으로 나열한다

입니다.

---

 

4) 동시성과 직렬화가 다르다: nonce 큐 vs 계정 락

4.1 EVM은 계정 단위 직렬화가 기본

• 같은 EOA에서 보낸 트랜잭션은 nonce 순서로 직렬화된다
• 멤풀에서도 nonce 갭이 있으면 뒤 nonce 트랜잭션은 막히기 쉽다

4.2 SVM은 계정 집합을 기준으로 병렬 실행을 시도

• 트랜잭션이 어떤 계정들을 읽고 쓰는지 명시한다
• 읽기 전용과 쓰기 계정이 충돌하지 않으면 병렬로 실행될 수 있다
• 충돌하면 그 계정 집합에 대한 락처럼 동작하며 순서가 생긴다

즉

• EVM은 순서가 먼저고, 그 순서를 맞추는 것이 기본
• SVM은 병렬이 먼저고, 충돌하는 부분만 순서가 생기는 방식

입니다.

 

web2 비유로 바꾸면

• EVM은 하나의 사용자 세션에 대해 단일 스레드로 커밋 로그를 만드는 방식
• SVM은 테이블 또는 레코드 집합을 잠그고 충돌이 없으면 병렬 커밋을 허용하는 방식

에 더 가깝습니다.

---

 

5) 토큰도 같아 보이지만 다르다: ERC-20 vs SPL Token

5.1 EVM의 토큰

• 토큰은 컨트랙트다
• 전송은 transfer 함수 호출이다
• 잔액은 컨트랙트 스토리지에 저장된다

5.2 Solana의 토큰

• 토큰은 프로그램과 계정 레이아웃으로 표현된다
• 사용자는 보통 token account라는 별도 계정을 가진다
• 전송은 토큰 프로그램에 대한 instruction 호출이다

5.3 멀티체인 지원에서 생기는 문제

• 같은 USDC라도 체인마다 다른 인스턴스다
• 체인마다 잔액 조회 방식, 이벤트 인덱싱 방식이 달라진다
• 입금 주소 생성, 최소 단위, 소수점, 수수료 단위가 달라진다

---

 

6) 메시지 서명도 다르게 읽힌다: 서명 증거 설계가 갈린다

x402처럼 메시지 서명 기반 증거를 쓰는 설계에서는 특히 중요합니다.

6.1 EVM 쪽에서 흔한 선택지

• 사람이 읽는 메시지 서명
• 구조화된 데이터 서명
  둘 다 도메인 분리와 컨텍스트 바인딩이 핵심이다

6.2 Solana 쪽에서 흔한 선택지

• 지갑이 제공하는 signMessage, signTransaction의 의미가 다르고
• 프로그램과 계정 목록이 포함되는 서명 흐름이 자주 등장한다

멀티체인에서 가장 흔한 사고는 이겁니다.

• 서명은 동일한 승인으로 보이지만, 실제로는 체인별로 다른 범위와 의미를 가진다

그래서 오프체인 서명 증거는

• 체인 id 또는 네트워크 식별자
• 서비스 도메인
• 리소스 범위
• nonce
• 만료 시간

을 반드시 포함시키는 쪽이 안전합니다.

---

 

7) 멀티체인 난이도가 폭증하는 체크리스트

아래 항목 중 하나만 달라도 난이도가 크게 증가합니다.

구분	EVM 계열	SVM 계열
서명	secp256k1 ECDSA	Ed25519
주소	20바이트 파생	32바이트 공개키
트랜잭션	nonce, gas, calldata	blockhash, instructions, account list
실행 모델	전역 직렬화 성격 강함	계정 충돌 기반 병렬
토큰	컨트랙트 스토리지	프로그램 + token account
인덱싱	로그 이벤트 중심	계정 변화와 프로그램 로그 혼합

그리고 서비스 팀이 실제로 겪는 문제는 보통

• 체인별 지갑 연결 UX가 다르다
• 체인별 수수료 단위와 실패 메시지가 다르다
• 체인별 재시도와 확정 정책이 다르다
• 체인별 인덱서가 따로 필요하다

로 요약됩니다.

---

 

8) 결론: 멀티체인은 기능 추가가 아니라 제품 2개를 만드는 일에 가깝다

• EVM과 SVM은 표면적으로는 둘 다 지갑 서명과 트랜잭션 전송이지만
• 바이트 레벨, 계정 모델, 실패 모델, 운영 모델이 다르다

그래서 멀티체인을 한다는 말은

• 지갑 및 서명 스택을 복수로 운영하고
• 인덱서 및 모니터링을 복수로 운영하고
• 제품 정책과 상태 머신을 체인별로 분기

한다는 뜻에 가깝습니다.