솔라나는 JSON이 아닌 바이트를 저장한다. 실제 의미는?

Source: Dev.to

몇 주 동안 탐색기와 RPC 호출을 통해 Solana 계정을 살펴보며, 깔끔하게 포맷된 토큰 잔액, 권한자, 공급량 등을 보고 “이게 Solana가 저장하는 데이터구나”라고 생각했습니다.
그렇지 않습니다. Solana는 원시 바이트를 저장합니다.

#100DaysOfSolana의 24일 차에 이 점을 뼈저리게 체감했습니다.
이번 챌린지는 메인넷에 있는 Wrapped SOL 민트 계정을 가져와서 세 가지 방법으로 디코딩하는 것이었습니다: SPL Token 디코더 사용, 바이트를 하나씩 수동으로 해석, 그리고 RPC의 jsonParsed 출력 이용.

원시 계정 데이터를 가져왔을 때는 이렇게 보였습니다:
82바이트의 아무것도 없는 데이터. 필드 이름도, 라벨도 없습니다. 그냥 숫자들뿐.

하지만 이 82바이트 안에 모든 것이 들어 있습니다: Wrapped SOL의 총 공급량, 소수점 자리수, 민트 권한자, 동결 권한자, 그리고 민트가 초기화되었는지 여부 등. 모두가 평평한 배열에 촘촘히 압축돼 있습니다.

핵심 인사이트: 계정을 소유한 프로그램이 그 바이트가 무엇을 의미하는지 정의합니다.
Token Program은 바이트 0–3은 구분자(discriminator), 바이트 4–35는 민트 권한자 옵션, 바이트 36–43은 공급량, 바이트 44는 소수점 자리수 등이라고 알고 있습니다. 이는 프로그램 코드에 내장된 바이너리 스키마와 같습니다.

SPL 코덱, 수동 해석, jsonParsed 세 가지 방법으로 계정을 디코딩했을 때 모두 같은 결과가 나왔습니다:

{
  "mintAuthority": null,
  "supply": "0",
  "decimals": 9,
  "isInitialized": true,
  "freezeAuthority": null
}

세 가지 접근법, 하나의 진실. 바이트가 원래부터 진실이었습니다.

왜 이것이 온체인 데이터를 바라보는 방식을 바꾸는가

Solana 탐색기는 여러분이 눈치채지 못하는 호의를 베풀고 있습니다. explorer.solana.com을 열어 깔끔하게 포맷된 토큰 계정을 볼 때마다, 탐색기는 해당 프로그램이 알려진 스키마를 사용해 원시 바이트를 디코딩하고, 그 결과를 읽기 쉬운 JSON 형태로 보여줍니다.

하지만 여러분이 직접 인덱서를 만들든, 프로그램을 만들든, 도구를 만들든 이 호의는 자동으로 제공되지 않습니다. 스키마를 알아야 하고, 바이트를 직접 디코딩해야 합니다. 그래서 Solana 프로그램은 IDL(Interface Definition Language) 을 공개합니다. 클라이언트가 프로그램이 쓰는 데이터를 어떻게 디코딩해야 하는지 알 수 있게 해 주는 것이죠. IDL이 없으면 차마 차를 읽는 것과 같습니다.

더 큰 그림

• Web2에서는 데이터베이스가 타입이 지정된 필드를 저장합니다. VARCHAR, BIGINT, BOOLEAN 등 데이터베이스 엔진이 타입을 강제하고, ORM이 이를 자동으로 객체에 매핑합니다.
• Solana에서는 “데이터베이스”가 단순히 바이트일 뿐입니다. “ORM”은 프로그램의 코덱이며, “스키마”는 프로그램 개발자가 정하고 (가능하면) 문서화한 내용입니다.

이는 훨씬 큰 권한이자, 동시에 큰 책임을 의미합니다.
원시 바이트가 들어가고, 구조화된 데이터가 나옵니다. 그 사이에 무엇이 있는지를 이해하는 것이 Solana를 단순히 사용하는 사람과, Solana를 진정으로 이해하는 사람을 구분 짓는 핵심입니다.