하나의 주소를 쓰는 세 가지 방법

내부적으로 모든 TON 주소는 두 개의 숫자입니다. 워크체인(basechain은 0, masterchain은 -1)과 컨트랙트 초기 상태의 256비트 해시입니다. raw 형태는 정확히 그것을 씁니다: 0:83dfd552…0f31a8. 모호함이 없고 get 메서드와 저수준 도구가 기대하는 형태이지만 체크섬이 없습니다. 한 글자만 틀려도 완벽히 유효해 보이는 다른 주소가 됩니다.

user-friendly 형태는 같은 두 숫자를 36바이트로 묶습니다. 플래그 바이트, 워크체인, 해시, 2바이트 CRC16 체크섬이며, 이를 48개의 base64 문자로 씁니다. 체크섬 덕분에 오타는 코인을 허공으로 보내는 대신 검증에 실패하고, 플래그 바이트 때문에 문자열이 EQ, UQ, kQ, 0Q로 시작합니다.

접두사 플래그 의미
EQ 0x11 bounceable, 메인넷
UQ 0x51 non-bounceable, 메인넷
kQ 0x91 bounceable, 테스트넷
0Q 0xd1 non-bounceable, 테스트넷

같은 36바이트를 두 가지 base64 문자 집합으로 쓸 수 있습니다. 표준(+와 /)과 URL 안전(-와 _)입니다. 지갑과 익스플로러는 URL 안전 문자 집합을 사용합니다. 도구는 둘 다 받아들이고 둘 다 출력합니다.

bounceable인지 아닌지: 플래그가 하는 일

EQ와 UQ는 두 개의 주소가 아닙니다. 같은 컨트랙트와 같은 잔액을 가리키며, 플래그는 발신자의 지갑에게 발신 메시지의 bounce 비트에 무엇을 넣을지 알려줄 뿐입니다.

bounceable 전송은 이렇게 말합니다. 대상이 이 메시지를 처리할 수 없다면(컨트랙트가 배포되지 않았거나, 예외를 던지거나, gas가 부족하면) 수수료를 뺀 코인을 나에게 돌려보내라. 스마트 컨트랙트로 보낼 때의 올바른 기본값이며, 그래서 익스플로러와 DEX 인터페이스는 EQ 주소를 보여줍니다.

non-bounceable 전송은 대상 계정에 처리할 코드가 없어도 그 계정에 남습니다. 지갑에 올바른 형태이며, 새 지갑으로의 첫 입금에는 유일하게 올바른 형태입니다. 새 지갑 컨트랙트는 자신의 첫 발신 트랜잭션으로 배포되므로, 그 전까지는 주소에 bounceable 메시지를 받아줄 것이 없어 코인이 곧바로 되돌아옵니다. 주소 형식 글이 예시와 함께 전체 이야기를 다룹니다.

검증기가 확인하는 것

user-friendly 주소의 경우: 길이(48자), 문자 집합, 처음 34바이트에 대한 CRC16 체크섬, 플래그 바이트. raw 주소의 경우: 워크체인 범위와 정확히 64자리 16진수. 각 검사에는 고유한 메시지가 있어서 잘린 붙여넣기와 오타가 다르게 보입니다.

확인할 수 없는 것은 체인입니다. 그 주소에 계정이 배포되었는지, 잔액이 있는지, 생각하는 그 컨트랙트가 맞는지는 노드(liteserver를 통한 getAccountState 호출)나 익스플로러가 필요합니다.

일괄 모드

일괄 모드로 전환해 한 줄에 주소 하나씩 붙여 넣으면 각 줄이 독립적으로 변환되고 검증됩니다. 잘못된 줄은 오류와 함께 제자리에 남으므로, 입금 주소 천 개의 목록도 한 번의 붙여넣기로 확인하고 잘못된 것을 줄 번호로 찾을 수 있습니다. 모든 것이 브라우저에서 이루어지며 목록은 업로드되지 않습니다.