Solana 트랜잭션은 내가 기대한 것과 다르다 (EVM에서 온 경우)
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Korean while preserving all formatting, markdown, and code blocks.
내가 알았다고 생각했던 것
On EVM chains, a transaction is mostly a wrapper. You have:
to주소- Some
value(ETH) - Optional
data(the encoded function call) - A signature from your wallet
The RPC figures out what to do with it. You don’t think too hard about the structure—ethers.js handles most of it.
Solana transactions look structurally similar at first glance. You sign something, you broadcast it. But once you actually build one from scratch, the differences become hard to ignore.
해부학이 더 명확합니다
Solana 트랜잭션은 instructions(명령)로 구성되며, 각 명령은 정확히 어떤 계정을 건드리는지와 해당 계정이 서명자(signer), 쓰기 가능(writable), 혹은 읽기 전용(read‑only)인지 명시합니다. 단순히 함수를 호출하고 런타임이 상태를 추론하도록 두는 것이 아니라, 미리 선언합니다: “이 명령은 계정 A에서 읽고 계정 B에 씁니다.”
간단한 전송을 구성했을 때는 다음과 같이 작성했습니다:
const transaction = new Transaction().add(
SystemProgram.transfer({
fromPubkey: sender.publicKey,
toPubkey: recipient,
lamports: LAMPORTS_PER_SOL * 0.001,
})
);
transaction.recentBlockhash = (
await connection.getLatestBlockhash()
).blockhash;
transaction.feePayer = sender.publicKey;ethers.js가 자동으로 처리해 주는 세 가지를 직접 설정해야 합니다: instruction, blockhash, 그리고 fee payer. Solana에서는 개발자가 더 낮은 수준에 가까워집니다.
블록해시가 나를 당황하게 만들었다
모든 Solana 트랜잭션에는 recentBlockhash가 포함됩니다. 선택 사항이 아닙니다. 이 값은 트랜잭션을 특정 시점에 묶어 주며, 만료됩니다. 트랜잭션이 대략 60–90 초 이내에 처리되지 않으면 사라집니다. 새 블록해시를 받아 다시 빌드하고 다시 시도해야 합니다.
EVM 체인에서는 논스와 가스 가격 전쟁을 다루며, 트랜잭션이 메모풀에 몇 분씩 머물 수 있습니다. Solana의 모델은 의도적으로 짧은 수명을 갖습니다: 트랜잭션이 빠르게 처리되든지, 아니면 전혀 처리되지 않든지 말이죠.
저는 실제로 devnet에서 블록해시를 가져온 뒤 너무 오래 기다렸다가 전송을 시도해 이 현상을 경험했습니다. 트랜잭션이 invalid 상태로 돌아왔습니다. 왜 그런지 이해하고 나니 말이 되었어요—Solana는 속도와 최종성을 최적화할 뿐, 트랜잭션이 대기열에 오래 머무는 것을 허용하지 않습니다.
트랜잭션을 깨뜨리는 것이 구축하는 것보다 더 많은 것을 가르쳐 주었다
제가 작업하던 과제는 실패 모드를 이해하기 위해 의도적으로 트랜잭션을 깨뜨리는 것이었습니다. 이것이 가장 유용한 부분이었습니다.
제가 일부러 깨뜨린 사례들:
- 임대‑면제 잔액을 위한 충분한 SOL 없이 전송하기
- 컴퓨트 예산 초과하기 (Solana는 트랜잭션당 컴퓨트 유닛을 할당하는데, 이는 가스와 비슷하지만 더 명시적입니다)
- 하나의 트랜잭션에 너무 많은 인스트럭션 포함하기 (Solana는 트랜잭션에 대해 1,232 바이트의 하드 제한을 가지고 있습니다)
마지막 항목은 EVM에 직접적인 대응이 없습니다. 이더리움에서는 calldata에 많은 데이터를 담을 수 있습니다. Solana에서는 1,232 바이트가 한계이며, 이것이 전부입니다. 이는 프로그램 설계 방식에 영향을 줍니다: 많은 작업이 필요하면 여러 트랜잭션에 걸쳐 배치하거나 로직을 재구성해야 합니다.
실패한 트랜잭션은 Solana Explorer에 명확한 오류 로그와 함께 표시됩니다. 이는 EVM에서 종종 “execution reverted”라고만 표시되고 유용한 정보가 전혀 없는 경우보다 실제로 더 나은 편입니다.
결국 클릭된 사고 모델
EVM에서는 트랜잭션을 계약에 메시지를 보내는 것이라고 생각합니다.
Solana에서는 상태 변경 배치를 제출하는 것에 가깝습니다. 이 배치는 모두 성공하거나 모두 실패합니다. 계정은 상태이며, 인스트럭션은 연산이고, 트랜잭션은 이를 감싸는 원자적 단위입니다.
큰 개념적 도약은 아니지만, 이를 구현하는 방식은 다릅니다. 로직을 생각하기 전에 먼저 계정을 생각합니다. 런타임이 알아내도록 두는 대신 의도를 미리 선언합니다.
나는 아직 초기 단계입니다—100일 중 20일 차. 하지만 트랜잭션은 Solana가 “더 빠른 이더리움”처럼 느껴지던 시점에서 벗어나 자체적인 느낌을 주기 시작한 부분입니다.
100 Days of Solana 챌린지를 진행 중입니다. 같은 과정을 하고 있다면 언제든지 연결해 주세요.