TON의 기술 특징 및 스마트 계약 개발 패러다임 상세 설명

저자 ：@Web3Mario

서론 ：바이낸스가 TON 생태계에서 가장 큰 게임인 Notcoin을 출시하고, 전면 유통 토큰 경제 모델로 인해 발생한 대규모 부의 효과로 인해 TON은 짧은 시간 안에 큰 주목을 받게 되었습니다. 친구와 이야기하면서 TON의 기술 장벽이 비교적 높고, DApp 개발 패러다임이 주류 공공 블록체인 프로토콜과 큰 차이가 있다는 것을 알게 되어, 관련 주제를 깊이 연구하는 데 시간을 좀 할애했습니다. 몇 가지 소감을 여러분과 공유하고자 합니다. 간단히 말해, TON의 핵심 설계 이념은 "하향식" 방식으로 전통적인 블록체인 프로토콜을 재구성하고, 상호 운용성을 포기하는 대가로 고성능과 높은 확장성을 극도로 추구하는 것입니다.

TON의 핵심 설계 사상------고성능과 높은 확장성

TON에서 모든 복잡한 기술 선택의 목적은 고성능과 높은 확장성에 대한 추구에서 비롯된다고 할 수 있습니다. 물론 그 탄생 배경을 보면 이해하기 어렵지 않습니다. TON, 즉 The Open Network는 분산된 계산 네트워크로, L1 블록체인과 여러 구성 요소를 포함합니다. TON은 처음에 텔레그램의 창립자 니콜라이 두로프와 그의 팀에 의해 공동 개발되었으며, 현재는 전 세계 독립 기여자 커뮤니티에 의해 지원되고 유지되고 있습니다. 그 탄생은 2017년으로 거슬러 올라가며, 텔레그램 팀은 자신들을 위한 블록체인 솔루션을 탐색하기 시작했습니다. 당시 텔레그램의 9자리 사용자 기반을 지원할 수 있는 기존 L1 블록체인이 없었기 때문에, 그들은 자신의 블록체인을 설계하기로 결정했고, 당시 이를 텔레그램 오픈 네트워크(Telegram Open Network)라고 불렀습니다. 시간이 지나 2018년, TON을 실현하기 위해 필요한 자원을 확보하기 위해 텔레그램은 2018년 1분기에 Gram 토큰(후에 Toncoin으로 이름 변경)의 판매를 시작했습니다. 2020년 규제 문제로 인해 텔레그램 팀은 TON 프로젝트에서 철수했습니다. 이후 소수의 오픈 소스 개발자와 텔레그램 대회 우승자가 TON의 코드베이스를 인수하여 프로젝트 이름을 The Open Network로 변경하고, 원래 TON 백서에 개요된 원칙을 따르며 블록체인 개발을 계속하고 있습니다.

따라서 텔레그램의 분산 실행 환경을 설계 목표로 삼았기 때문에, 자연스럽게 두 가지 문제인 고성능 요청과 대량 데이터에 직면하게 됩니다. 우리는 기술 발전이 이루어진 현재, TPS가 가장 높은 솔라나(Solana)의 실측 TPS가 65000에 불과하다는 것을 알고 있습니다. 이는 분명히 백만 TPS 요구를 충족할 수 없는 수치입니다. 동시에 텔레그램의 대규모 사용으로 인해 발생하는 데이터 양은 이미 천문학적인 수치를 초과했으며, 블록체인은 극도로 중복된 분산 시스템으로, 네트워크의 각 노드가 완전한 데이터를 저장해야 한다는 요구는 비현실적입니다.

따라서 위의 두 가지 문제를 해결하기 위해, TON은 주류 블록체인 프로토콜에 대해 두 가지 측면에서 최적화를 수행했습니다:

• "무한 분할 패러다임"(Infinite Sharding Paradigm)을 채택하여 시스템을 설계하고 데이터 중복 문제를 해결하여 대량 데이터를 수용할 수 있도록 하며, 성능 병목 문제를 완화합니다;
• 액터 모델 기반의 완전한 병렬 실행 환경을 도입하여 네트워크 TPS를 크게 향상시킵니다;

블록체인의 체인------무한 분할 능력을 통해 각 계정에 전용 계정 체인을 부여하다

현재 우리는 분할(sharding)이 대부분의 블록체인 프로토콜에서 성능을 향상시키고 비용을 절감하는 주류 솔루션이 되었다는 것을 알고 있으며, TON은 이를 극대화하여 무한 분할 패러다임을 제안했습니다. 무한 분할 패러다임이란 블록체인이 네트워크 부하에 따라 동적으로 분할 수를 늘리거나 줄일 수 있도록 허용하는 것을 의미합니다. 이러한 패러다임 덕분에 TON은 높은 성능을 유지하면서 대규모 거래와 스마트 계약 작업을 처리할 수 있으며, 이론적으로 TON은 각 계정에 전용 계정 체인을 구축할 수 있고, 일정한 규칙을 통해 이러한 체인 간의 일관성을 보장할 수 있습니다.

추상적으로 이해하자면, TON에는 총 네 가지 체인 구조가 존재합니다:

• 계정 체인(AccountChain) ：이 체인은 특정 계정과 관련된 일련의 거래로 구성된 체인을 나타냅니다. 거래가 체인 구조를 형성할 수 있는 이유는 상태 기계에 대해 규칙이 일관되기만 하면, 상태 기계가 동일한 순서의 지시를 수신했을 때 결과가 일관되기 때문입니다. 따라서 모든 블록체인 분산 시스템에서 거래는 체인식으로 정렬되어야 하며, TON도 예외는 아닙니다. 계정 체인은 TON 네트워크에서 가장 기본적인 구성 단위이며, 일반적으로 계정 체인은 가상의 개념으로, 독립적인 계정 체인이 실제로 존재할 가능성은 낮습니다.

• 분할 체인(ShardChain) ：대부분의 맥락에서 분할 체인은 TON의 실제 구성 단위입니다. 분할 체인이란 일련의 계정 체인의 집합을 의미합니다.

• 작업 체인(WorkChain) ：사용자 정의 규칙이 있는 분할 체인의 집합이라고도 할 수 있습니다. 예를 들어 EVM 기반의 작업 체인을 생성하여 그 위에서 Solidity 스마트 계약을 실행할 수 있습니다. 이론적으로 커뮤니티의 모든 사람이 자신의 작업 체인을 생성할 수 있습니다. 사실, 이를 구축하는 것은 상당히 복잡한 작업이며, 이를 생성하기 위해서는 (비싼) 비용을 지불하고 검증자의 2/3의 투표를 얻어야 합니다.

• 마스터 체인(MasterChain) ：마지막으로 TON에는 마스터 체인이라는 특별한 체인이 있으며, 이 체인은 모든 분할 체인에 최종성을 제공합니다. 분할 체인의 블록 해시가 마스터 체인의 블록에 병합되면, 해당 분할 체인 블록 및 모든 부모 블록은 최종성을 가지게 되며, 이는 고정되고 변경할 수 없는 내용으로 간주되어 모든 분할 체인의 후속 블록에서 참조됩니다.

이러한 패러다임을 채택함으로써 TON 네트워크는 다음 세 가지 특징을 갖추게 됩니다:

• 동적 분할 : TON은 부하 변화에 따라 분할 체인을 자동으로 분할하고 병합할 수 있습니다. 이는 새로운 블록이 항상 빠르게 생성되고, 거래가 긴 대기 시간을 발생시키지 않음을 의미합니다.

• 높은 확장성: 무한 분할 패러다임을 통해 TON은 거의 무한한 수의 분할을 지원할 수 있으며, 이론적으로 2의 60승 개의 작업 체인에 도달할 수 있습니다. 적응성 : 네트워크의 특정 부분의 부하가 증가하면 해당 부분은 더 많은 분할로 세분화되어 증가된 거래량을 처리할 수 있습니다. 반대로 부하가 감소하면 분할이 병합되어 효율성을 높일 수 있습니다.

이렇게 다중 체인 시스템에서는 먼저 직면해야 할 문제는 크로스 체인 통신 문제입니다. 특히 무한 분할 능력으로 인해 네트워크의 분할 수가 일정 수준에 도달하면 체인 간 정보 라우팅이 어려워질 것입니다. 예를 들어 네트워크에 4개의 노드가 있고, 각 노드가 1개의 독립적인 작업 체인을 유지하고 있다고 가정해 보겠습니다. 이 경우 링크 관계는 해당 노드가 자신의 작업 체인에서 거래 정렬 작업을 수행하는 것 외에도 목표 체인에서 상태 변화를 모니터링하고 처리해야 함을 나타냅니다. TON에서는 구체적으로 출력 큐의 메시지를 모니터링하여 이를 구현합니다.

작업 체인 1의 계정 A가 작업 체인 3의 계정 C에 메시지를 보내고 싶다고 가정해 보겠습니다. 이 경우 메시지 라우팅 문제가 발생하며, 이 예에서는 두 개의 라우팅 경로가 있습니다: 작업 체인 1 -> 작업 체인 2 -> 작업 체인 3, 작업 체인 1 -> 작업 체인 4 -> 작업 체인 3.

더 복잡한 상황에 직면할 때는 효율적이고 저렴한 라우팅 알고리즘이 메시지 통신을 신속하게 완료해야 합니다. TON은 이른바 "초입방체 라우팅 알고리즘"을 선택하여 크로스 체인 메시지 통신 라우팅 발견을 구현합니다. 초입방체 구조란 특별한 네트워크 토폴로지를 의미하며, n차원 초입방체는 2^n개의 정점으로 구성되며, 각 정점은 n비트의 이진수로 고유하게 식별될 수 있습니다. 이 구조에서 임의의 두 정점이 이진 표현에서 한 비트만 다르다면, 그들은 인접해 있습니다. 예를 들어, 3차원 초입방체에서 정점 000과 정점 001은 마지막 비트에서만 다르기 때문에 인접해 있습니다. 위의 예는 2차원 초입방체입니다.

초입방체 라우팅 프로토콜에서 메시지는 소스 작업 체인에서 목표 작업 체인으로의 라우팅 과정이 소스 작업 체인과 목표 작업 체인의 주소의 이진 표현을 비교하여 이루어집니다. 라우팅 알고리즘은 이 두 주소 간의 최소 거리를 찾아내고(즉, 이진 표현에서 다른 비트의 수), 인접한 작업 체인을 통해 정보를 점진적으로 전달하여 목표 작업 체인에 도달합니다. 이 방법은 데이터 패킷이 최단 경로를 따라 전송되도록 보장하여 네트워크의 통신 효율성을 높입니다.

물론 이 과정을 단순화하기 위해 TON은 낙관적인 기술 솔루션을 제안했습니다. 사용자가 특정 라우팅 경로에 대한 유효한 증명을 제공할 수 있는 경우, 이는 일반적으로 특정 머클 트라이 루트로, 노드는 해당 사용자가 제출한 메시지의 신뢰성을 즉시 인정할 수 있습니다. 이를 즉시 초입방체 라우팅이라고도 합니다.

따라서 우리는 TON의 주소가 다른 블록체인 프로토콜과 뚜렷한 차이를 보인다는 것을 알 수 있습니다. 다른 주류 블록체인 프로토콜은 대부분 타원 곡선 암호 알고리즘으로 생성된 공개 키의 해시를 주소로 사용합니다. 이는 주소가 유일성을 구분하는 데만 필요하고 라우팅 주소 지정 기능을 수용할 필요가 없기 때문입니다. 반면 TON의 주소는 두 부분으로 구성됩니다. (workchainid, accountid)에서 workchain_id는 초입방체 라우팅 알고리즘 주소로 인코딩됩니다. 여기서는 자세히 설명하지 않겠습니다.

또한 쉽게 의문이 생길 수 있는 점은, 여러분은 아마도 마스터 체인과 각 작업 체인 간에 링크 관계가 있다는 것을 발견했을 것입니다. 그렇다면 모든 크로스 체인 정보는 마스터 체인을 통해 중계하면 되지 않을까요? 마치 코스모스처럼. TON의 설계 이념에서 마스터 체인은 여러 작업 체인의 최종성을 유지하는 가장 중요한 작업만 처리하는 데 사용됩니다. 메시지를 마스터 체인을 통해 라우팅하는 것도 가능하지만, 이로 인해 발생하는 수수료는 매우 비쌀 것입니다.

마지막으로 그 합의 알고리즘에 대해 간단히 언급하자면, TON은 BFT+PoS 방식을 채택하고 있습니다. 즉, 임의의 스테이커가 블록 패킹에 참여할 기회를 가집니다. TON의 선거 거버넌스 계약은 일정 시간마다 모든 스테이커 중에서 무작위로 블록을 패킹할 검증자 집단을 선택합니다. 선택된 검증자 노드는 BFT 알고리즘을 통해 블록을 패킹하며, 잘못된 정보로 패킹하거나 악의적인 행동을 할 경우, 그 스테이크의 토큰은 몰수됩니다. 반대로 블록 생성 보상을 받게 됩니다. 이는 기본적으로 비교적 일반적인 선택이므로 여기서 더 이상 설명하지 않겠습니다.

액터 모델 기반의 스마트 계약과 완전 병렬 실행 환경

TON에서 또 다른 주류 블록체인 프로토콜과 다른 점은 스마트 계약 실행 환경입니다. 주류 블록체인 프로토콜의 TPS 제한을 극복하기 위해, TON은 하향식 설계 사고를 채택하고 액터 모델을 사용하여 스마트 계약 및 그 실행 방식을 재구성하여 완전한 병렬 실행 능력을 갖추게 되었습니다.

우리는 주류 블록체인 프로토콜이 대부분 단일 스레드 직렬 실행 환경을 채택하고 있다는 것을 알고 있습니다. 이더리움을 예로 들면, 그 실행 환경인 EVM은 거래를 입력으로 하는 상태 기계입니다. 블록 생성 노드가 블록 패킹을 통해 거래를 정렬한 후, 해당 순서로 EVM을 통해 거래를 실행합니다. 전체 과정은 완전히 직렬적이며 단일 스레드로, 특정 시점에 한 거래만 실행될 수 있습니다. 이렇게 하면 거래 순서를 확인하면, 실행 결과가 광범위한 분산 클러스터에서 일관성을 가지게 됩니다. 동시에 한 번에 하나의 거래만 직렬 실행되므로, 실행 과정에서 다른 거래가 특정 상태 데이터에 대한 접근을 수정할 수 없게 되어 스마트 계약 간의 상호 운용성을 실현할 수 있습니다. 예를 들어, 우리는 유니스왑을 통해 USDT로 ETH를 구매할 때, 해당 거래가 실행될 때 LP의 분포 상황은 확정된 값이 됩니다. 따라서 특정 수학 모델을 통해 해당 결과를 도출할 수 있습니다. 그러나 상황이 이렇지 않다면, 특정 본딩 곡선 계산을 실행할 때 다른 LP가 새로운 유동성을 추가하면, 계산 결과는 구식이 될 것입니다. 이는 분명히 받아들일 수 없는 상황입니다.

하지만 이러한 구조는 명백한 한계를 가지고 있으며, 바로 TPS의 병목 현상입니다. 현재 다중 코어 프로세서에서 이 병목 현상은 매우 구식으로 보입니다. 최신 PC로 오래된 컴퓨터 게임을 실행할 때, 예를 들어 레드얼럿과 같은 게임에서 전투 유닛이 일정 수 이상이 되면 여전히 끊기는 현상이 발생하는 것과 같습니다. 이는 소프트웨어 아키텍처의 문제입니다.

일부 프로토콜이 이 문제에 주목하고 있으며, 자신의 병렬 솔루션을 제안하고 있다는 이야기를 들었을 것입니다. 현재 TPS가 가장 높은 솔라나의 경우도 병렬 실행 능력을 갖추고 있습니다. 다만 그 설계 사고는 TON과 다릅니다. 솔라나에서는 모든 거래를 실행 의존 관계에 따라 몇 개의 그룹으로 나누고, 서로 다른 그룹 간에는 어떤 상태 데이터도 공유하지 않습니다. 즉, 동일한 의존성이 존재하지 않기 때문에 서로 다른 그룹 내의 거래는 충돌이 발생하지 않고 병렬 실행될 수 있습니다. 그러나 동일 그룹 내의 거래는 여전히 전통적인 직렬 방식으로 실행됩니다.

TON에서는 직렬 실행 아키텍처를 완전히 포기하고, 병렬 실행을 위해 특별히 설계된 개발 패러다임인 액터 모델을 채택하여 실행 환경을 재구성했습니다. 액터 모델은 1973년 칼 휴잇(Carl Hewitt)에 의해 처음 제안된 것으로, 메시지 전달을 통해 전통적인 동시 프로그램에서 공유 상태의 복잡성 문제를 해결하는 것을 목표로 합니다. 각 액터는 자신의 개인 상태와 행동을 가지며, 다른 액터와 상태 정보를 공유하지 않습니다. 액터 모델은 메시지 전달을 통해 병렬 계산을 구현하는 동시 계산 모델입니다. 이 모델에서 "액터"는 기본 작업 단위로, 수신한 메시지를 처리하고, 새로운 액터를 생성하며, 더 많은 메시지를 전송하고, 다음 메시지에 어떻게 응답할지를 결정할 수 있습니다. 액터 모델은 다음과 같은 몇 가지 특성을 가져야 합니다:

• 캡슐화 및 독립성: 각 액터는 메시지를 처리할 때 완전히 독립적이며, 서로 간섭 없이 병렬로 메시지를 처리할 수 있습니다.

• 메시지 전달: 액터 간의 상호 작용은 오직 메시지를 보내고 받는 것을 통해 이루어지며, 메시지 전달은 비동기적입니다.

• 동적 구조: 액터는 실행 중에 더 많은 액터를 생성할 수 있으며, 이러한 동적 특성 덕분에 액터 모델은 필요에 따라 시스템을 확장할 수 있습니다.

TON은 이 아키텍처를 채택하여 스마트 계약 모델을 설계했습니다. 이는 TON에서 각 스마트 계약이 액터 모델로 구성되어 있으며, 완전히 독립적인 저장 공간을 갖추고 있음을 의미합니다. 외부 데이터에 의존하지 않기 때문입니다. 또한 동일한 스마트 계약의 호출은 여전히 수신 큐의 메시지 순서에 따라 실행되므로, TON의 거래는 효율적으로 병렬 실행될 수 있으며 충돌 문제에 대한 걱정이 필요 없습니다.

그러나 이러한 설계 솔루션은 몇 가지 새로운 영향을 미치게 됩니다. DApp 개발자에게는 기존의 개발 패러다임이 깨지게 됩니다. 구체적으로는 다음과 같습니다:

1. 스마트 계약 간의 비동기 호출 : TON의 스마트 계약 내부에서는 외부 계약을 원자적으로 호출하거나 외부 계약 데이터를 접근할 수 없습니다. 우리는 솔리디티(Solidity)에서 계약 A의 function1이 계약 B의 function2를 호출하거나, 계약 C의 읽기 전용 function3을 통해 특정 상태 데이터를 접근하는 경우, 전체 과정이 원자적이며 한 거래에서 실행되는 것이 매우 쉬운 일이라는 것을 알고 있습니다. 그러나 TON에서는 이를 구현할 수 없습니다. 외부 스마트 계약과의 모든 상호 작용은 새로운 거래를 패킹하여 비동기적으로 실행되어야 하며, 이러한 스마트 계약이 시작한 거래는 내부 메시지라고도 불립니다. 실행 과정에서 실행 결과를 얻기 위해 차단할 수 없습니다.

예를 들어, 우리가 DEX를 개발한다고 가정해 보겠습니다. EVM에서 일반적인 패러다임을 채택하면, 보통 거래 라우팅을 관리하기 위해 통합된 라우터 계약이 있으며, 각 풀은 특정 거래 쌍 관련 LP 데이터를 개별적으로 관리합니다. 현재 USDT-DAI와 DAI-ETH라는 두 개의 풀을 가정해 보겠습니다. 사용자가 USDT를 통해 ETH를 직접 구매하고 싶다면, 라우터 계약을 통해 한 거래에서 이 두 풀에 순차적으로 요청하여 원자적 거래를 완료할 수 있습니다. 그러나 TON에서는 그렇게 쉽게 구현할 수 없습니다. 새로운 개발 패러다임을 생각해야 하며, 여전히 해당 패러다임을 재사용하려고 한다면, 정보 흐름은 다음과 같을 수 있습니다. 이 요청은 사용자가 시작한 외부 메시지와 세 개의 내부 메시지로 완료됩니다(참고: 이는 차이점을 설명하기 위한 것이며, 실제 개발에서는 ERC20 패러다임도 재설계해야 할 수 있습니다).

2. 크로스 계약 호출 시 발생할 수 있는 실행 오류 상황 처리 흐름을 신중하게 고려해야 하며, 각 계약 간 호출에 대해 적절한 되돌리기(bounce) 함수를 설계해야 합니다. 우리는 주류 EVM에서 거래 실행 중 문제가 발생하면 전체 거래가 롤백되어 실행 초기 상태로 재설정된다는 것을 알고 있습니다. 이는 직렬 단일 스레드 모델에서 이해하기 쉬운 일입니다. 그러나 TON에서는 계약 간 호출이 비동기 방식으로 실행되기 때문에, 후속 단계에서 오류가 발생하더라도 이전에 성공적으로 실행된 거래는 이미 실행되고 확인되었기 때문에 문제가 발생할 수 있습니다. 따라서 TON에서는 특별한 메시지 유형인 되돌리기 메시지를 설정하여, 특정 내부 메시지가 촉발한 후속 실행 과정에서 오류가 발생할 경우, 촉발 계약은 촉발 계약에 예약된 되돌리기 함수를 통해 특정 상태를 재설정할 수 있습니다.

3. 일부 복잡한 경우, 먼저 수신된 거래가 반드시 먼저 실행 완료되지 않으므로 이러한 시퀀스 관계를 미리 설정할 수 없습니다. 이렇게 비동기 및 병렬 스마트 계약 호출 시스템에서 처리 작업 순서를 정의하는 것은 매우 어려울 수 있습니다. 그래서 TON의 각 메시지에는 논리적 시간인 램포트 시간(Lamport time, 이하 lt)이 있습니다. 이는 어떤 사건이 다른 사건을 유발했는지 이해하고, 검증자가 무엇을 먼저 처리해야 하는지를 검증하는 데 사용됩니다. 간단한 모델에서는 먼저 수신된 거래가 반드시 먼저 실행 완료됩니다.

이 모델에서 A와 B는 각각 두 개의 스마트 계약을 나타내며, msg1lt < msg2lt이면 tx1lt < tx2lt의 시퀀스 관계가 성립합니다.

그러나 더 복잡한 경우에는 이 규칙이 깨질 수 있습니다. 공식 문서에는 다음과 같은 예가 있습니다. A, B, C라는 세 개의 계약이 있다고 가정해 보겠습니다. 한 거래에서 A는 두 개의 내부 메시지 msg1과 msg2를 보냅니다: 하나는 B에게, 다른 하나는 C에게. 이들은 정확한 순서로 생성되었지만(먼저 msg1, 그 다음 msg2), msg1이 msg2보다 먼저 처리될 것인지 확실히 알 수 없습니다. 이는 A에서 B로, A에서 C로의 라우팅이 길이와 검증자 집합에서 다를 수 있기 때문입니다. 이러한 계약이 서로 다른 분할 체인에 위치해 있다면, 한 메시지가 목표 계약에 도달하는 데 몇 개의 블록이 필요할 수 있습니다. 즉, 우리는 두 가지 가능한 거래 경로가 있습니다.

4. TON에서 스마트 계약의 지속적 저장소는 Cell 단위의 방향성 비순환 그래프를 데이터 구조로 사용하며, 데이터는 인코딩 규칙에 따라 압축되어 하나의 Cell로 변환되고, 방향성 비순환 그래프 방식으로 아래로 확장됩니다. 이는 EVM에서 상태 데이터가 해시맵 기반 구조로 조직되는 것과 다릅니다. 데이터 요청 알고리즘의 차이로 인해, TON에서는 서로 다른 깊이의 데이터 처리에 대해 서로 다른 가스 가격을 설정합니다. 깊이가 깊은 Cell 데이터 처리는 더 많은 가스를 필요로 하며, 따라서 TON에서는 특정 악의적인 사용자가 많은 쓰레기 메시지를 보내 특정 스마트 계약의 모든 얕은 Cell을 차지하는 DOS 공격 패러다임이 존재합니다. 이는 정직한 사용자의 저장 비용이 점점 더 높아짐을 의미합니다. EVM에서는 해시맵의 조회 복잡도가 O(1)이기 때문에 동일한 가스를 가지며, 유사한 문제가 발생하지 않습니다. 따라서 TON DApp 개발자는 스마트 계약에서 무한 데이터 유형이 발생하지 않도록 주의해야 합니다. 무한 데이터 유형이 발생할 경우, 분할 방식을 통해 이를 분산시켜야 합니다.

5. 몇 가지 특성은 그리 특별하지 않습니다. 예를 들어 스마트 계약은 저장소에 대한 임대료를 지불해야 하며, TON에서 스마트 계약은 자연스럽게 업그레이드 가능하고, 원주율의 추상 계정 기능이 있습니다. 즉, TON에서 모든 지갑 주소는 스마트 계약입니다. 다만 초기화되지 않은 것일 뿐입니다. 이러한 점들은 개발자가 주의해야 할 사항입니다.

이상은 제가 TON 관련 기술을 학습하면서 얻은 몇 가지 소감입니다. 잘못된 부분이 있다면 지적해 주시기 바랍니다. 동시에 텔레그램의 방대한 트래픽 자원을 바탕으로, TON 생태계는 Web3에 새로운 응용 프로그램을 가져올 것이라고 믿습니다. TON DApp 개발에 관심이 있는 분들은 저에게 연락해 주시면 함께 논의해 보겠습니다.