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

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

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

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

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

대량 전송의 세 가지 형태

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

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

다대다 도구가 세 번째 형태이자, 짝을 아는 유일한 형태입니다. 첫 줄에는 첫 줄의 출처가 있고 둘째 줄에는 다른 출처가 있습니다. 공동 자금도 없고 줄끼리 서로를 메워 주는 일도 없습니다.

한 줄에 드는 비용

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

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

세 번째 줄은 두 번 읽어 둘 만합니다. 사람들이 걸리는 지점이 정확히 여기입니다. SPL 토큰을 한 번도 그 토큰을 만져 본 적 없는 주소로 보낸다는 것은 그것을 담을 계정을 새로 만든다는 뜻이고, 솔라나는 그 계정에 rent 예치금을 매깁니다. 예치금은 네트워크 수수료의 약 이백 배, 플랫폼 수수료의 두 배입니다.

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

건너뛰는 줄

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

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

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

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

금액을 깎지 않는 이유

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

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

줄마다 트랜잭션 하나, 그게 중요한 이유

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

대가는 있습니다. 마흔 쌍이면 서명 마흔 번, 플랫폼 수수료 마흔 번입니다. 대신 줄 단위로 읽히는 결과가 남습니다. 그 거래들이 얼마나 빨리 들어가는지 궁금하다면 숫자는 솔라나 우선순위 수수료 글에 정리해 두었습니다.

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

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

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

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

목록을 준비하는 순서

첫 실행은 두 줄로 돌려 보는 편이 낫습니다. 결과 표가 한 줄에 실제로 얼마가 들었는지, 토큰 계정 예치금까지 포함해서 알려 줍니다. 이천 줄을 보내기 전에요.

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

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

잔액에 관한 마지막 한 가지. 보내는 지갑마다 자기 금액보다 조금 더 남겨 두는 편이 낫습니다. 소수점 끝자리까지 딱 맞춰 두면 rent 검사가 그 줄을 밀어내고 다시 자금을 넣어야 하는데, 처음부터 여유를 둔 것보다 느립니다.

목록이 커지면 달라지는 것

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

첫째는 자금 넣기입니다. 보내는 지갑마다 시작 전에 자기 금액과 수수료가 있어야 하고, 한 줄이 다른 줄을 메울 방법은 없습니다. 그래서 보통 금고 하나에서 나가는 사전 배분 실행이 한 번 필요하고, 딱 맞추기보다 여유를 두고 하는 편이 낫습니다.

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

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

계획할 때 자주 놓치는 것

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

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

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

자주 묻는 질문

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

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

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

붙지 않습니다. 사전 검사를 통과하지 못한 줄은 서명 자체를 하지 않으므로 네트워크 수수료도 플랫폼 수수료도 발생하지 않습니다.

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

됩니다. 한 지갑이 어떤 줄에서는 보내고 다른 줄에서는 받을 수 있습니다. 줄마다 따로 검사합니다.

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

보내는 지갑의 잔액이 0과 0.00089088 SOL 사이에 떨어졌을 것이기 때문입니다. 잔액을 전부 보내거나 금액을 낮추면 됩니다.

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

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

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

실무에서 걸리는 쪽은 도구가 아니라 준비입니다. 보내는 지갑은 전부 미리 자금이 들어가 있어야 합니다. 그래서 실제 상한은 사전 배분을 어디까지 감당하느냐로 정해집니다.

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

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

한 줄로 판단하기

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