솔라나 다대다 전송: 지갑을 짝지어 보내기

솔라나에서 여러 건을 한 번에 보내는 방법은 세 가지고, 이 셋은 끊임없이 서로 헷갈립니다. 멀티센더는 지갑 하나에서 목록으로 지급합니다. 컬렉터는 여러 지갑을 하나로 끌어모읍니다. 그리고 둘 중 어느 쪽으로도 표현되지 않는 경우가 하나 남습니다.

다대다 전송은 보내는 지갑마다 자기 수신자를 붙여 둡니다. 보내는 지갑 7은 수신 주소 7에게, 지갑 8은 수신 주소 8에게 지급하고, 두 줄은 서로를 전혀 모릅니다.

사소한 차이처럼 들립니다. 실제로는 자금 출처가 하나인 것과 서로 독립된 출처가 마흔 개인 것의 차이입니다.

• 한 줄이 트랜잭션 하나입니다. 그 줄의 보내는 지갑이 그 줄에 붙은 비용을 전부 냅니다.
• 플랫폼 수수료는 전송당 0.001 SOL, 네트워크 수수료는 0.000005 SOL입니다.
• 해당 토큰을 한 번도 보유한 적 없는 수신자에게는 토큰 계정이 새로 필요하고, 보내는 쪽이 0.00149 SOL의 rent 예치금을 더 냅니다.
• 통과하지 못한 줄은 금액이 깎이는 대신 통째로 건너뜁니다.

대량 전송의 세 가지 형태

멀티센더 도구는 일대다입니다. 지갑 하나, 수신자 목록 하나, 지급 주체 하나. 에어드롭에 필요한 형태가 이것입니다.

일괄 회수 도구는 다대일입니다. 지갑 스무 개, 목적지 하나, 그리고 끝나면 모든 것이 한자리에 모입니다.

다대다 도구가 세 번째 형태이자, 줄마다 보내는 지갑과 받는 주소를 짝지어 처리하는 유일한 형태입니다. 첫 줄에는 첫 줄의 출처가 있고 둘째 줄에는 다른 출처가 있습니다. 공동 자금도 없고 줄끼리 서로를 메워 주는 일도 없습니다.

한 줄에 드는 비용

한 줄에는 항목이 세 개까지 붙을 수 있고, 그 줄의 보내는 지갑이 셋 다 부담합니다. 공동으로 자금을 대는 계정이 없으니, 자기 줄을 감당하지 못하는 지갑이 윗줄에서 빌려 오지도 않습니다. 네트워크 항목은 서명 하나당 5,000 lamport라는 기본 수수료이고, 솔라나 자체 수수료 문서가 그 계산을 설명합니다.

항목	SOL 모드	토큰 모드
플랫폼 수수료	0.001 SOL	0.001 SOL
네트워크 수수료	0.000005 SOL	0.000005 SOL
수신자 토큰 계정	해당 없음	0.00149 SOL, 그 수신자가 이 토큰을 한 번도 보유한 적 없을 때만

세 번째 줄은 두 번 읽어 둘 만합니다. 사람들이 가장 놀라는 지점이 정확히 여기입니다. 어떤 SPL 토큰을 한 번도 받아 본 적 없는 주소로 보낸다는 것은 그 토큰을 담을 계정을 새로 만든다는 뜻이고, 솔라나는 그 계정에 rent 예치금을 매깁니다. 예치금은 네트워크 수수료보다 훨씬 큽니다.

새 수신자가 백 명이면 청구서에서 0.149 SOL쯤을 차지하는데, 같은 조건에서 플랫폼 수수료는 0.1에서 멈춥니다. 예치금은 소각되지 않습니다. 수신자의 토큰 계정에 남아 있다가 나중에 그 계정을 닫는 쪽에게 돌아갑니다.

건너뛰는 줄

서명 전에 검사가 두 번 돌고, 둘 다 줄을 바꾸는 대신 멈춰 세웁니다.

첫 번째는 단순한 산수입니다. 보내는 지갑이 자기 금액과 수수료, 그리고 열어야 할 수도 있는 토큰 계정까지 감당하지 못하면 그 줄에는 표시가 붙고 그대로 남습니다. 절반만 나가는 일은 없습니다.

두 번째는 더 낯설고 알아 둘 만합니다. 처음 보면 버그처럼 보이기 때문입니다. 솔라나는 잔액이 0보다 크면서 rent 면제 최소액보다 작은 계정을 그대로 남기는 것을 허용하지 않습니다. 일반 지갑에서 그 최소액은 0.00065 SOL이고, 솔라나 계정 문서에 실린 공식에서 나옵니다.

계정을 완전히 비우는 것은 허용됩니다. 0.00005 SOL을 남겨 두는 것은 허용되지 않습니다. 지갑을 그 틈으로 밀어 넣는 줄에는 rent dust 표시가 붙고 전송되지 않은 채 남습니다.

금액을 깎지 않는 이유

대안은 들어맞을 때까지 금액을 깎는 것이고, 그쪽이 더 나쁩니다. 숫자는 사람이 직접 적어 넣은 것입니다. 말없이 다른 숫자를 보내는 도구는 그다음부터 어떤 정산표와도 맞출 수 없는 도구입니다.

잔액을 전부 보내거나, 남는 금액이 최소액을 넘도록 금액을 낮추면 됩니다. 미리보기가 어느 줄이 걸리는지 먼저 알려 주고, 도구는 무엇에든 서명하기 전에 목적지 계정 전체를 한 번의 호출로 조회합니다.

줄마다 트랜잭션 하나가 중요한 이유

줄마다 자기 트랜잭션이니 실패한 줄은 혼자 넘어집니다. 전부를 한 트랜잭션에 쌓아 넣는 묶음이라면 30번째 줄의 오류가 앞선 29줄까지 함께 끌고 갑니다.

대가는 작습니다. 마흔 쌍이면 네트워크 수수료가 서명마다 따로 붙어 0.000005 SOL씩 나갑니다. 대신 줄 단위로 읽히는 결과가 남습니다. 그 거래들이 얼마나 빨리 들어가는지 궁금하다면 숫자는 솔라나 우선순위 수수료 글에 정리해 두었습니다.

다대다 전송이 맞는 형태일 때

지갑 교체가 대부분의 사용자에게 가장 흔한 경우입니다. 뒤에 두고 싶은 이력이 붙은 지갑 묶음이 있고, 지갑 대량 생성기로 새 묶음을 만들고, 옛 지갑 7이 새 지갑 7에만 자금을 넣기를 바라는 상황입니다.

두 번째는 줄마다 지급 주체가 바뀌는 정산 목록입니다. 프로젝트 여러 개, 금고 여러 개, 시트 하나. 멀티센더로는 아예 표현되지 않습니다. 출처가 정확히 하나뿐이기 때문입니다.

세 번째는 스냅샷 이후의 재분배입니다. 홀더마다 미리 지정해 둔 지갑에서 지급이 나갑니다. 나누기 전에 그 분포를 읽는 방법은 토큰 홀더 분포 보는 법에 적어 두었습니다.

목록을 준비하는 순서

첫 실행은 두 줄로 돌려 보는 편이 낫습니다. 결과 표가 한 줄에 실제로 얼마가 들었는지, 토큰 계정 예치금까지 포함해서 알려 줍니다. 목록 전체를 보내기 전에 그 숫자를 먼저 알 수 있습니다.

수신자들이 이미 그 토큰을 들고 있는지도 확인해 두면 좋습니다. 절반이 기존 홀더인 목록에서는 예치금 항목이 반으로 줄고, 백 줄 규모에서는 그 항목이 청구서에서 큰 비중을 차지합니다.

어느 지갑이 어느 줄을 내는지도 시작 전에 적어 두는 편이 좋습니다. 실행이 끝난 뒤에 그 대응을 되살리는 일은 지금 들리는 것보다 성가십니다. 특히 보내는 지갑들이 방금 만들어져 서로 구별할 이력이 아직 없을 때 그렇습니다.

잔액에 관한 마지막 한 가지. 보내는 지갑마다 금액과 수수료를 합한 만큼을 채워 완전히 비우거나, 남길 거라면 최소액인 0.00065 SOL 이상을 남겨 두는 편이 낫습니다. 어중간하게 조금만 남기면 rent 검사가 그 줄을 밀어내고 다시 자금을 넣어 돌려야 해서, 처음부터 맞춰 둔 것보다 느립니다.

목록이 커지면 달라지는 것

열 줄이라면 여기까지의 이야기는 편한 이론에 가깝습니다. 이천 줄이 되면 두 가지가 진짜 작업이 되고, 둘 다 도구 바깥에서 벌어집니다.

첫째는 자금 넣기입니다. 보내는 지갑마다 시작 전에 자기 금액과 수수료가 있어야 하고, 한 줄이 다른 줄을 메울 방법은 없습니다. 그래서 보통 금고 하나에서 나가는 사전 배분 실행이 한 번 필요하고, 이때 보낼 금액만이 아니라 수수료까지 넣어서 채우는 편이 낫습니다.

둘째는 끝난 뒤의 대사입니다. 마흔 줄이면 표를 보면 그만입니다. 이천 줄이면 결과를 내보내서 원본 시트와 줄 단위로 맞춰 보고 싶어집니다. 건너뛴 줄은 익스플로러에 아예 나타나지 않기 때문입니다. 트랜잭션으로 존재한 적이 없으니까요.

덜 눈에 띄는 세 번째 효과도 있습니다. 목록에 새 수신자와 기존 수신자가 섞여 있으면 줄당 비용이 일정하지 않습니다. 앞쪽 열 줄로 낸 평균은 전체 비용과 닮지 않습니다. 계정을 새로 여는 수신자가 몇 명인지 세고, 그 수만 0.00149 SOL과 곱하는 편이 맞습니다.

계획할 때 자주 놓치는 것

이 작업을 자주 하는 사람이 막히는 지점은 대체로 셋으로 좁혀집니다. 첫째는 모자란 줄에 도구가 알아서 자금을 채워 줄 것이라는 기대입니다. 채우지 않고, 채우지 않는 것이 의도입니다. 다른 지갑에서 돈을 끌어와 모자란 줄을 메우는 순간 짝이라는 개념 자체가 사라지기 때문입니다.

둘째는 보낼 금액만 보고 계획을 세우다가, 수수료와 예치금도 같은 보내는 지갑에서 나간다는 사실을 잊는 것입니다. 보낼 금액에 딱 맞춰 둔 지갑은 언제나 모자랍니다. 차이는 크지 않지만 모든 줄에서 동시에 생깁니다.

셋째는 결과를 잘못 읽는 것입니다. 건너뛴 줄은 실패한 트랜잭션이 아니라 만들어진 적 없는 트랜잭션입니다. 익스플로러에서 찾아도 아무것도 나오지 않고, 그것은 무언가 고장 났다는 신호가 아닙니다.

자주 묻는 질문

멀티센더를 여러 번 돌리는 것과 무엇이 다릅니까?

멀티센더는 실행 한 번에 출처가 정확히 하나입니다. 출처가 마흔이면 실행 마흔 번과 손으로 지갑을 마흔 번 바꾸는 일이 됩니다. 여기서는 실행 한 번에 줄이 마흔입니다.

실패한 줄에도 비용이 붙습니까?

경우에 따라 다릅니다. 사전 검사를 통과하지 못한 줄은 서명 자체를 하지 않으므로 네트워크 수수료도 플랫폼 수수료도 발생하지 않습니다. 서명하고 전송한 뒤 체인에서 실패한 줄은 실패한 다른 솔라나 트랜잭션처럼 네트워크 수수료를 냅니다. 플랫폼 수수료는 같은 트랜잭션 안에 있어서 전송이 성공해야만 정산됩니다.

보내는 쪽과 받는 쪽이 겹쳐도 됩니까?

됩니다. 한 지갑이 어떤 줄에서는 보내고 다른 줄에서는 받을 수 있습니다. 줄마다 따로 검사하고 따로 서명하므로 줄 사이의 순서는 보장되지 않습니다. 2번 줄이 1번 줄이 보낸 돈을 써야 한다면 실행을 둘로 나누십시오.

왜 제 줄에 rent dust 표시가 붙었습니까?

그 금액을 보내면 보내는 지갑의 잔액이 0과 0.00065 SOL 사이에 남게 되기 때문입니다. 잔액을 전부 보내거나 금액을 낮추면 됩니다.

토큰만 보내는 지갑에도 SOL이 필요합니까?

필요합니다. 옮기는 대상이 토큰이어도 네트워크 수수료와 플랫폼 수수료는 SOL로 나갑니다.

짝의 개수에 상한이 있습니까?

정해진 상한은 없고, 수천 쌍을 붙여 넣어도 막히지 않습니다. 100줄씩 묶어 서명하고 전송하므로 긴 실행에는 몇 초가 아니라 몇 분이 걸릴 수 있습니다. 지켜볼 수 있는 실행이어야 고칠 수도 있으니, 아주 긴 목록은 몇 번의 작은 실행으로 나누는 편이 다루기 쉽습니다. 실무에서 먼저 걸리는 쪽은 도구가 아니라 준비입니다. 보내는 지갑은 전부 미리 자금이 들어가 있어야 하므로, 사전 배분을 어디까지 감당하느냐가 현실적인 상한입니다.

줄 순서가 결과에 영향을 줍니까?

주지 않습니다. 줄마다 서명이 따로 나가고 검사도 따로 도는 만큼, 서로 기대지 않는 줄이라면 순서를 바꿔도 통과하는 줄과 건너뛰는 줄은 그대로입니다. 결과 표에서 원본 시트와 맞춰 보기 편하도록 입력 순서를 유지할 뿐입니다.

한 줄로 판단하기

시트에 지급 주체 열이 있다면 필요한 형태가 이것입니다. 모든 줄이 같은 지갑에서 나간다면 멀티센더를 쓰고 마흔 번 대신 한 번만 돌리면 됩니다. 그리고 결과에서 줄 하나가 빠져 있다면 버그로 짐작하기 전에 rent 최소액부터 확인해 보는 편이 낫습니다. 그 최소액에 관해서는 rent 예치금 부족 오류 설명에 더 적어 두었습니다.