원작자: 요한
배경
TON(The Open Network)은 원래 Telegram 팀이 설계하고 개발한 분산형 블록체인 플랫폼입니다. TON의 목표는 대규모 분산 애플리케이션(DApp) 및 스마트 계약을 지원하기 위한 확장 가능한 고성능 블록체인 플랫폼을 제공하는 것입니다.
TON은 매우 특별하고 사용하기 쉬우며 Telegram과 긴밀하게 통합되어 일반 사람들이 토큰을 쉽게 사용할 수 있습니다. 또한 복잡하고 다른 블록체인과 완전히 다른 아키텍처를 가지며 비주류 FunC를 사용합니다. 스마트 계약 언어. 오늘은 TON의 특징과 사용자 자산 보안 문제를 계정, 토큰, 거래 관점에서 논의합니다.
톤의 특징
계정 생성
TON 계정 주소는 대부분의 블록체인과 다르게 생성됩니다. 스마트 계약 주소입니다. 먼저 개인 키를 생성합니다. TON은 주로 Ed 25519 알고리즘을 사용하여 공개 키를 생성합니다.
공개 키에는 두 가지 형태가 있습니다. 하나는 개인 키에서 계산된 원래 공개 키입니다.
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
다른 하나는 Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2 형식으로 공개 키의 일부 정보와 확인 숫자를 전달하는 미화된 공개 키입니다.
단순히 사용자의 공개키를 가지고 있다는 것만으로는 사용자의 계정 주소를 계산하기에는 이더리움처럼 계정 주소를 얻을 수 있다고 생각하는 것은 너무 순진한 생각입니다. 방금 사용자의 계정 주소가 스마트 계약 주소라고 했는데 계정도 없는데 어떻게 스마트 계약을 배포할 수 있나요? 올바른 순서는 먼저 주소를 계산하고 초기 토큰 양을 받은 다음 계약을 배포하는 것입니다. 계정 주소의 계산 과정은 아래 그림과 같습니다.
사용자의 주소는 다양한 형태로 제공됩니다. 첫 번째는 다음과 같은 원래 형태입니다.
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
다음과 같은 사용자 친화적인 형식을 사용합니다.
메인넷:
바운싱 가능:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
반송 불가:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
테스트넷:
바운싱 가능:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
반송 불가:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
이 주소들을 주의 깊게 관찰해 보면 첫 번째와 마지막 문자만 다를 뿐이고 중간의 `account_id`는 동일한 것을 알 수 있습니다. 그러나 여전히 공개 키와 계정 주소 간의 관계를 확인할 수 없습니다. 사실 미스터리는 시작 부분에 있는 초기 데이터에는 사용자가 지갑 계약의 소유권을 통제하는 사용자의 공개 키가 포함되어 있다는 것입니다. workchainId는 이해하기 쉽습니다. TON은 단순한 단일 체인이 아닙니다. 각 샤드는 전체 네트워크의 일부이며 특정 계정 및 트랜잭션 집합을 처리합니다. 스마트 계약을 찾아 관리하려면 해당 계약이 어느 샤드에 있는지 명확하게 표시해야 합니다. 바운스 가능과 바운스 불가의 차이점은 무엇인가요? 이는 스마트 계약의 작동 메커니즘과 관련이 있습니다. 아래에서 계속 살펴보겠습니다.
지갑 계약
다음은 사용자의 메시지를 수신할 때 4개의 매개변수(stored_seqno,stored_subwallet,public_key,plugins)를 읽는 것을 볼 수 있는 사용자 지갑 계약의 소스 코드입니다.
지갑-v4-code.fc
() recv_external(slice in_msg) 불순한 {
var 서명 = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint( 32), cs~load_uint( 32), cs~load_uint( 32));
throw_if( 36, valid_until <= 지금());
var ds = get_data().begin_parse();
var (stored_seqno, Stored_subwallet, public_key, 플러그인) = (ds~load_uint( 32), ds~load_uint( 32), ds~load_uint( 256), ds~load_dict()) ;;##초기 데이터
ds.end_parse();
throw_unless( 33, msg_seqno == 저장된_seqno);
throw_unless( 34, subwallet_id == 저장된_subwallet);
throw_unless( 35, check_signature(slice_hash(in_msg), 서명, public_key));
//...
}
그렇습니다. 이 사용자의 지갑 계약을 배포할 때 256비트 public_key 정보를 포함하는 일부 초기 매개변수를 전달해야 합니다. 이는 동일한 계약 주소를 사용할 때 각 사용자가 독립적인 계약을 갖도록 보장합니다. 사용자가 시작한 모든 거래는 `in_msg`에 서명해야 하며, 자신의 지갑 계약을 통해 서명(check_signature)을 확인한 다음 계약이 체인의 모든 작업을 호출합니다. 여기에서 우리는 사용자의 공개 키가 실제로 수많은 지갑 주소와 일치할 수 있다는 것을 추론할 수 있습니다. 완전히 다른 계약 주소를 얻으려면 다른 소스 코드나 다른 초기화 데이터를 사용하여 지갑을 배포하기만 하면 됩니다.
제튼 토큰
토큰은 체인상의 자산을 표현하는 것이므로 우리가 이해해야 할 기본 요소입니다. Jetton은 TON 토큰의 표준 형식입니다. Jetton은 Jetton-minter와 Jetton-wallet이라는 두 가지 계약으로 구성됩니다.
토큰이 발행되면 Jetton-minter 계약이 생성됩니다. 계약 초기화에는 총 토큰 금액, 관리자, 지갑 코드 및 기타 정보가 기록됩니다.
토큰이 사용자에게 배포되면 Minter 계약은 사용자를 위한 지갑 계약을 배포하고 계약이 초기화될 때 사용자의 잔액, 소유권, 토큰 Minter 계약 주소, 사용자 지갑 코드 및 기타 정보를 기록합니다. 독립적으로. 여기서 생성된 컨트랙트는 특정 Jetton 토큰을 관리하는 데 사용되는 지갑 컨트랙트로 사용자의 계정 지갑 컨트랙트와는 다르므로 여기서 owner_address는 사용자의 계정 지갑 주소를 기록합니다.
사용자 Alice가 사용자 Bob에게 돈을 이체할 때 호출 관계는 다음과 같습니다.
앨리스는 오프체인 앱에 서명하고 지갑 계약을 호출하여 작업 지침을 발행합니다. 이 지침은 추가로 그녀의 토큰 지갑을 호출하여 전송을 수행합니다. Bob의 토큰 지갑이 토큰을 수신하면 Bob의 지갑 계약(즉, Bob Jetton-wallet의 소유자 주소)을 알립니다. 거래 중 남은 가스가 있는 경우 일반적으로 Alice의 계정 계약인 응답 주소로 반환됩니다.
이것은 Tonviewer 브라우저에서 구문 분석한 Jetton 토큰 전송입니다.
ERC 20 전송은 최소한 하나의 계약만 호출하면 되는 반면, Jetton 토큰 전송은 최소한 4개의 계약을 호출해야 합니다. 이는 전송이 체인에서 동시에 수행되고 거래 효율성을 향상시키기 위해 수행됩니다.
거래
TON의 계정에 어떤 일이 발생하면 거래가 시작됩니다. 가장 일반적인 이벤트는 메시지 수신입니다.
처음에 계약을 트리거하는 수신 메시지(특별한 트리거 방법이 있음)
계약 저장소 업데이트와 같은 수신 메시지로 인한 계약 작업(선택 사항)
다른 참가자에게 보내는 메시지(선택 사항)
거래 시 주의해야 할 몇 가지 특성이 있습니다.
1. 비동기식: TON 트랜잭션은 한 번의 호출로 완료되지 않습니다. 일련의 호출을 실행하려면 여러 다른 스마트 계약에 메시지를 전달해야 할 수도 있습니다. 샤드 체인의 라우팅이 다르기 때문에 TON은 여러 스마트 계약 간의 메시지 전달 순서를 보장할 수 없습니다.
2. 처리 수수료: 비동기적 성격으로 인해 소비된 처리 수수료를 추정하기 어렵다는 문제도 발생합니다. 따라서 거래를 시작할 때 지갑은 일반적으로 처리 수수료로 더 많은 토큰을 보냅니다. 호출된 계약에 양호한 처리 수수료 메커니즘이 있는 경우 남은 처리 수수료는 결국 사용자의 지갑으로 반환됩니다. 사용자는 지갑 토큰이 갑자기 줄어들다가 몇 분 후에 늘어나는 것을 볼 수 있습니다.
3. 반송: 반송은 호출 계약이 존재하지 않거나 오류가 발생하는 경우 계약의 오류 처리 메커니즘입니다. 트랜잭션이 반송으로 설정된 경우 반송된 메시지가 호출 계약으로 다시 반송됩니다. 예를 들어 사용자가 이체를 시작했는데 호출 과정에서 오류가 발생한 경우 사용자의 지갑 계약이 잔액을 복원할 수 있도록 반송 메시지가 필요합니다. 스마트 계약 간에 전송되는 거의 모든 내부 메시지는 반송 가능해야 합니다. 즉, 반송 비트가 설정되어야 합니다.
자산 보안
TON에는 보안 문제를 일으킬 수 있는 많은 기능이 있으므로 사용자는 몇 가지 일반적인 함정도 알고 있어야 합니다.
수수료 가로채기 공격
위에서 언급했듯이 지갑은 거래 실행 실패를 방지하기 위해 더 많은 처리 수수료를 보내야 하는 경우가 많으며, 이로 인해 공격자는 악행을 저지를 기회를 찾을 수 있습니다. TON 지갑을 사용하시는 분들이라면 이런 상황을 겪으셨을텐데요, 지갑에 항상 다양한 NFT나 토큰이 들어있는데 그냥 정크토큰 에어드랍인줄 알았는데 거래정보를 확인해보니 그렇지 않더군요. 팔아요. 돈이 적나요? 그러나 거래를 시작할 때 요구되는 수수료가 매우 높다는 것을 알게 됩니다(1TON). 이때는 수수료 사기일 수 있으므로 주의가 필요합니다.
공격자는 신중하게 구성된 토큰 계약을 사용하여 지갑의 예상 이체 수수료를 극도로 높게 만들었으나 실제 실행 중에는 수수료만 보류하고 이체 메시지를 보내지 않았습니다.
처음이자 마지막 숫자낚시
머리 및 꼬리 번호 피싱은 TON에만 국한된 것이 아닙니다. 이러한 종류의 피싱 공격은 모든 주요 공개 체인에 존재합니다. 공격자는 전체 네트워크의 모든 사용자 주소에 대해 동일한 첫 번째와 마지막 번호를 가진 높은 모방 계정을 생성합니다. 사용자가 이체를 보낼 때 공격자는 또한 높은 모방 계정을 사용하여 사용자의 소액 이체를 보냅니다. 영수증. 결제기록에 기록을 남겨주세요. 수신 사용자가 토큰을 다시 전송하려고 할 때, 과거 기록에서 주소를 복사할 수 있으며, 이때 공격자의 주소로 복사되어 공격자가 잘못된 주소로 전송될 가능성이 높습니다. 사용자의 행동.
댓글 낚시
TON은 송금 시 거래 정보를 메모하기 위해 메모를 추가할 수 있습니다. 이 기능은 거래소에서 충전할 때 일반적으로 사용자가 충전할 때 사용자 ID를 메모하도록 요구합니다. 하지만 이 기능은 악의적으로 악용되는 경우가 많아 공격자가 노트에 허위 정보를 적어 사용자의 자산을 사취하는 경우가 많습니다. 그림과 같이:
사용자는 익명 텔레그램 번호 NFT에 특별한 주의가 필요합니다. 사용자가 익명 텔레그램 번호를 사용하여 TG 계정을 개설했지만 2단계 인증을 열지 않은 경우 NFT가 피싱되면 해커가 대상 TG에 직접 로그인할 수 있습니다. 계정을 생성하고 후속 자산 추출 및 사기 행위를 수행합니다.
스마트 계약 취약점
스마트 계약의 보안 취약성은 스마트 계약에 있는 사용자의 자금에 피해를 줄 수 있습니다. 사용자는 프로젝트를 선택할 때 잘 감사된 프로젝트를 선택해야 합니다. TON의 스마트 계약은 주로 FunC 언어를 사용하여 프로그래밍되지만, 매우 독창적인 언어인 고급 Tact 또는 하위 수준 Fift도 사용합니다. 새로운 프로그래밍 언어는 새로운 보안 위험을 가져올 것입니다. 특히 개발자에게는 안전한 프로그래밍 습관을 갖고, 최상의 보안 관행을 숙지하고, 공간 제한으로 인해 프로덕션 환경에 배포하기 전에 엄격한 보안 감사를 거쳐야 합니다. 지금은 계약 보안에 대해 논의하지 마세요.
가짜 재충전 공격
지갑이나 거래소 사용자는 허위 충전 공격에 주의해야 합니다. 일반적으로 허위 충전 공격에는 두 가지 유형이 있습니다.
위조 동전의 경우, 공격자는 대상 토큰과 동일한 메타데이터를 가진 토큰을 발행합니다.자동 입력 프로그램이 이것이 올바른 민트 계약인지 확인하지 않으면 잘못된 입력으로 이어집니다.
Bounce, TON의 전송 프로세스에는 두 사용자의 지갑 계약 간의 호출 관계가 필요합니다. 수신자의 지갑 계약이 존재하지 않고 거래가 Bounceable로 설정된 경우 메시지가 반송되고 원래 자금이 차감됩니다. 수수료를 발송인에게 반환합니다. 자세한 내용이 궁금하신 친구들은 저희가 이전에 공개했던 가짜 충전 기사를 확인하실 수 있습니다.
요약
이 글은 TON의 공개 및 개인 키 생성, 지갑 계약, 토큰 형태, 거래 특성 등의 관점에서 TON의 몇 가지 기본 기술 원칙을 소개하고, TON을 사용하는 과정에서 발생할 수 있는 보안 문제에 대해서도 논의하는 데 도움이 되기를 바랍니다. 모두들 영감을 얻으세요.
참조 링크:
