TON의 기술적 특징과 스마트 컨트랙트 개발 패러다임에 대한 자세한 설명

출처:MarioWatchWeb3

소개: 코인온 생태계에서 가장 큰 게임인 Notcoin의 출시와 완전 순환 토큰 경제 모델이 촉발한 엄청난 부의 효과로 TON은 단시간에 큰 주목을 받았습니다. TON은 단기간에 많은 관심을 받았습니다. 친구들과 대화를 나누다 보니 TON의 기술적 문턱이 상대적으로 높고, 디앱 개발 패러다임이 주류 퍼블릭 체인 프로토콜과 매우 다르다는 것을 알게 되었습니다. 그래서 관련 주제를 심도 있게 연구하는 시간을 가졌고, 제가 얻은 통찰력을 여러분과 공유하고자 합니다. 요컨대, TON의 핵심 설계 개념은 기존 블록체인 프로토콜을 "상향식" 방식으로 재구성하고 상호운용성을 희생하면서 높은 동시성과 높은 확장성을 궁극적으로 추구하는 것입니다.

TON의 핵심 설계 이념 - 높은 동시성과 확장성

TON의 모든 복잡한 기술적 선택은 높은 동시성과 확장성을 달성하기 위한 목적으로 이루어졌다고 할 수 있습니다. TON, 즉 오픈 네트워크는 L1 블록체인과 여러 구성 요소로 구성된 탈중앙화 컴퓨팅 네트워크로, 원래 텔레그램 창립자 니콜라이 두로프와 그의 팀이 개발하였으며, 현재는 전 세계의 독립적인 기여자들에 의해 개발되고 있습니다. TON은 원래 텔레그램 창립자 니콜라이 두로프와 그의 팀에 의해 개발되었으며, 독립적인 기여자들로 이루어진 글로벌 커뮤니티의 지원과 유지보수를 통해 발전해왔습니다. TON의 탄생은 2017년으로 거슬러 올라가, 텔레그램 팀이 자체적으로 블록체인 솔루션을 모색하기 시작하였습니다. 텔레그램의 9자리 수 사용자 기반을 지원할 수 있는 기존 L1 블록체인이 없었기 때문에, 이들은 자체 블록체인을 설계하기로 결정했고, 그 당시 텔레그램 오픈 네트워크라고 불렸습니다. 2018년이 되어, TON 구현에 필요한 자원을 확보하기 위해 텔레그램은 2018년 1분기에 그램 토큰(이후 톤코인으로 명칭 변경) 판매를 시작하였습니다. 2020년, 텔레그램 팀은 규제 문제로 인해 TON 프로젝트에서 철수했습니다. 이후, 소수의 오픈소스 개발자들과 텔레그램 콘테스트 우승자들이 TON의 코드베이스를 인수하여, 프로젝트의 이름을 오픈 네트워크로 변경하고, 원래 TON 백서에 명시된 원칙에 따라 현재까지도 활발하게 블록체인 개발을 이어가고 있습니다.

따라서 텔레그램을 위한 탈중앙화된 실행 환경으로 설계되었기 때문에, 자연스럽게 높은 동시성과 방대한 양의 데이터라는 두 가지 문제를 해결해야 했으며, 기술이 발전하면서 최고 TPS를 자랑하던 솔라나도 측정된 최대 65,000에 불과하여 필요한 수백만 TPS를 지원하기에는 분명히 충분하지 않다는 것을 알 수 있습니다. 이는 수백만 TPS가 필요한 텔레그램 생태계를 지원하기에는 분명히 충분하지 않습니다. 동시에, 텔레그램의 대규모 적용으로 인해 텔레그램에서 생성되는 데이터의 양은 이미 하늘을 넘었으며, 네트워크의 각 노드가 데이터의 완전한 사본을 보관해야 한다면 극도로 중복된 분산 시스템으로서의 블록체인 역시 비현실적일 수 있습니다.

이러한 두 가지 문제를 해결하기 위해 TON은 두 가지 방식으로 주류 블록체인 프로토콜을 최적화했습니다.

• TON은 '무한 노드 수'를 채택함으로써 두 가지 방식으로 블록체인 프로토콜을 최적화할 수 있게 되었습니다. ">시스템 설계에 무한 샤딩 패러다임을 도입하여 데이터 중복 문제를 해결함으로써 성능 병목현상을 완화하면서 빅데이터를 처리할 수 있도록 했으며,

• 액터 모델 기반의 완전 병렬 실행 환경을 도입하여 시스템의 성능을 크게 향상시켰습니다. 액터 모델 기반의 완전 병렬 실행 환경을 도입하여 네트워크 TPS를 크게 향상시켰습니다.

블록체인을 하는 체인 - 무제한 샤딩 기능을 통해 각 계정에 독점 계정 체인을 부여

블록체인을 하는 체인 - 무한한 샤딩 기능을 통해 각 계정에 독점 계정 체인을 부여

오늘날 샤딩은 대부분의 블록체인 프로토콜에서 성능 향상과 비용 절감을 위한 주류 솔루션이 되었으며, TON은 이를 극단적으로 발전시켜 네트워크 부하에 따라 블록체인이 샤드 수를 동적으로 늘리거나 줄일 수 있는 무한 샤딩 패러다임을 제안합니다. 이 패러다임을 통해 TON은 고성능을 유지하면서 대규모 거래와 스마트 컨트랙트 운영을 처리할 수 있으며, 이론적으로 각 계정마다 전용 계정 체인을 설정하고 특정 규칙을 통해 이러한 체인의 일관성을 보장할 수 있습니다.

추상적으로 말하면 TON에는 4계층의 체인 구조가 있습니다. 4계층 체인 구조:

• AccountChain: 이 계층의 체인은 계정과 관련된 트랜잭션의 사슬을 나타냅니다. 스테이트 머신의 경우 실행 규칙이 일관된 한, 스테이트 머신은 동일한 순서의 명령을 받은 후 동일한 결과를 얻으므로 모든 블록체인 분산 시스템은 트랜잭션을 체인화해야 하며, TON도 예외는 아닙니다. 계정 체인은 TON 네트워크의 가장 기본적인 구성 요소이며, 계정 체인은 가상의 개념으로 실제로는 별도의 계정 체인이 존재하지 않는 경우가 많습니다.

• 샤드체인: 대부분의 상황에서 샤드체인은 계정 체인의 모음인 TON의 실제 구성 요소입니다.

• 작업체인: 솔리디티 스마트 콘트랙트를 실행하기 위한 EVM 기반 작업체인 생성 등 사용자 지정 규칙이 있는 샤드 체인 집합이라고도 할 수 있습니다. 이론적으로는 커뮤니티의 모든 사람이 자신만의 워크체인을 만들 수 있습니다. 사실, 이를 구축하는 것은 상당히 복잡한 작업으로, (비싼) 수수료를 지불하고 검증자로부터 작업 체인 생성을 승인하는 2/3의 투표를 받아야 합니다.

• 마스터체인: 마지막으로, TON에는 모든 샤딩된 체인에 최종성을 부여하는 마스터체인이라는 특별한 체인이 있습니다. 샤딩된 체인 블록의 해시가 마스터 체인의 블록에 병합되면, 해당 샤딩된 체인 블록과 모든 부모 블록은 최종성을 가진 것으로 간주되며, 이는 고정되고 불변하는 것으로 간주되어 샤딩된 체인의 모든 후속 블록에서 참조할 수 있다는 것을 의미합니다.

이러한 패러다임을 채택함으로써 TON 네트워크는 다음 세 가지 기능을 사용할 수 있습니다.

• 동적 샤딩: TON은 부하 변화에 따라 자동으로 샤딩 체인을 분할하고 병합할 수 있습니다. 이는 새로운 블록이 항상 빠르게 생성되고 트랜잭션 대기 시간이 길어지지 않는다는 것을 의미합니다.

• 높은 확장성: 무한 샤딩 패러다임을 통해 TON은 이론적으로 2의 60승까지 사실상 무제한의 샤드 수를 지원할 수 있습니다.

• 적응형: 네트워크 일부의 부하가 증가하면 해당 부분을 더 많은 슬라이스로 세분화하여 증가된 트랜잭션 양을 처리할 수 있습니다. 반대로 부하가 감소하면 슬라이스를 병합하여 효율성을 높일 수 있습니다.

이러한 멀티체인 시스템에서 가장 먼저 직면해야 하는 것은 크로스체인 통신 문제인데, 특히 무제한으로 슬라이스를 가질 수 있기 때문에 네트워크의 슬라이스 수가 일정 규모에 도달하면 체인 간 정보 라우팅이 어려워지게 됩니다. 네트워크에 4개의 노드가 있고, 각 노드는 독립적인 작업 체인을 유지할 책임이 있으며, 링크 관계는 노드가 트랜잭션 시퀀싱 작업 외에도 자체 작업 체인을 담당하지만 달성할 메시지의 출력 큐를 청취하여 TON에서 대상 체인의 상태 변화를 듣고 처리해야 함을 나타내는

작업 체인 1의 계정 A가 작업 체인 3의 계정 C에게 메시지를 보내고 싶다고 가정해 보겠습니다. 작업 체인 3에 있는 계정 C로 메시지가 전송됩니다. 이 예에서는 작업 체인 1 - 작업 체인 2 - 작업 체인 3과 작업 체인 1 - 작업 체인 4 - 작업 체인 3의 두 가지 라우팅 경로가 있습니다.

더 복잡한 시나리오에서는 매우 효율적이고 비용이 적게 드는 라우팅이 필요합니다. 더 복잡한 상황에 직면했을 때 메시지 통신을 신속하게 완료하기 위해 효율적이고 저렴한 라우팅 알고리즘이 필요하며, TON은 크로스 체인 메시지 통신 경로 검색을 달성하기 위해 소위 "하이퍼큐브 라우팅 알고리즘"을 선택했습니다. 소위 하이퍼큐브 구조는 특별한 종류의 네트워크 토폴로지를 말합니다. n차원 하이퍼큐브는 2^n개의 정점으로 구성되며 각 정점은 n비트 이진수로 고유하게 식별할 수 있습니다. 이 구조에서 두 정점은 이진 표현에서 1비트만 다르면 인접한 정점입니다. 예를 들어 3차원 하이퍼큐브에서 정점 000과 정점 001은 마지막 비트만 다르기 때문에 인접한 정점입니다. 위의 예는 2차원 하이퍼큐브입니다.

하이퍼큐브 라우팅 프로토콜에서, 메시지가 소스 작업 체인에서 목적지 작업 체인으로 라우팅되는 과정은 소스 및 목적지 작업 체인의 주소의 이진 표현을 비교하여 수행됩니다. 라우팅 알고리즘은 이 두 주소 사이의 최소 거리(즉, 이진 표현의 서로 다른 비트 수)를 찾아 목적지 작업 체인에 도달할 때까지 인접한 작업 체인을 통해 메시지를 점진적으로 전달합니다. 이 접근 방식은 패킷이 최단 경로를 따라 전송되도록 하여 네트워크의 통신 효율을 향상시킵니다.

물론 이 과정을 단순화하기 위해 TON은 사용자가 특정 라우팅 경로에 대한 유효성 증명을 제공할 수 있는 경우 노드가 사용자가 제출한 메시지의 신뢰성을 직접 인정하는 낙관적인 기술 솔루션도 제안하는데, 이는 일반적으로 인스턴트 하이퍼라고도 알려진 머클 트라이 루트입니다. 큐브 라우팅이라고도 합니다.

따라서 TON의 주소는 다른 블록체인 프로토콜과 분명한 차이가 있음을 알 수 있습니다. 대부분의 다른 주류 블록체인 프로토콜은 해시에 해당하는 공개 키의 공개 키에서 생성된 타원 암호화 알고리즘을 주소로 사용하기 때문에 주소는 단지 구별의 고유성을 수행하기 위한 것이며 라우팅 주소의 기능을 수행할 필요가 없는 반면 TON의 주소는 두 부분을 가지고 있습니다. TON의 주소는 하이퍼큐브 라우팅 알고리즘 주소에 따라 인코딩된 두 부분(workchain_id, account_id)으로 구성되며, 여기서는 자세히 설명하지 않겠습니다.

또 하나 쉽게 의심할 수 있는 점이 있는데, 메인체인과 각 워크체인이 링크 관계를 가지고 있기 때문에 메인체인을 통해 모든 크로스체인 정보가 코스모스처럼 릴레이를 하는 것이 아니냐는 것입니다. TON의 설계 철학에서 마스터 체인은 많은 작업 체인의 최종성을 유지하는 가장 중요한 작업에만 사용되며, 마스터 체인을 통해 메시지를 라우팅하는 것이 불가능한 것은 아니지만 그렇게하려면 비용이 많이 듭니다.

마지막으로 합의 알고리즘에 대해 간단히 언급하자면, TON은 BFT + PoS, 즉 모든 스테이커가 블록 패킹에 참여할 수 있는 기회를 가지며, 모든 스테이커로부터 무작위로 패키지화된 검증자 클러스터를 선택하기 위해 TON의 선거 거버넌스 계약이 일정한 간격으로 이루어지며 검증자 노드는 BFT + PoS를 통과할 것이라고 선택되었습니다. 검증자로 선정된 노드는 BFT 알고리즘에 따라 블록을 패키징하게 되며, 잘못된 정보를 패키징하거나 악의적인 행위를 하면 지분 토큰을 몰수당하고 반대로 블록을 패키징한 것에 대한 보상을 받게 됩니다. 이는 기본적으로 일반적인 선택이므로 여기서는 자세히 설명하지 않겠습니다.

액터 모델 기반 스마트 컨트랙트와 완전 병렬 실행 환경

TON과 주류 블록체인 프로토콜의 또 다른 차이점은 스마트 컨트랙트를 위한 실행 환경입니다. 주류 블록체인 프로토콜의 TPS 한계를 극복하기 위해 TON은 상향식 설계 방식을 채택하여 액터 모델을 사용하여 스마트 컨트랙트와 그 실행 방식을 재구성함으로써 완전한 병렬 실행이 가능하도록 합니다.

대부분의 주류 블록체인 프로토콜은 단일 스레드 직렬 실행 환경을 사용합니다. 이더리움을 예로 들면, 이더리움의 실행 환경인 EVM은 트랜잭션을 입력으로 하는 상태 머신으로, 노드가 블록을 패킹하여 거래 순서를 완성하면 그 순서대로 EVM을 통해 거래를 실행하는 방식이죠. 전체 프로세스가 완전히 직렬적이고 단일 스레드로 진행되어 특정 순간에 하나의 트랜잭션만 실행될 수 있기 때문에 트랜잭션의 순서만 확인되면 광범위한 분산 클러스터에서 실행 결과가 일관된다는 장점이 있으며, 동시에 하나의 트랜잭션만 동시에 직렬적으로 실행되므로 실행 과정 중에 다른 트랜잭션이 특정 상태 데이터에 접근하여 변경하는 것이 불가능하여 다음과 같은 장점이 있습니다. 스마트 콘트랙트 간의 상호 운용성. 예를 들어 USDT를 사용하여 유니스왑을 통해 이더를 구매하는 경우, 거래가 실행될 때 해당 쌍의 LP 분포는 수학적 모델에서 도출할 수 있는 확실한 값이지만, 그렇지 않고 본딩 곡선 계산을 실행하는 동안 다른 LP가 새로운 유동성을 추가한다고 가정하면 계산의 결과는 다음과 같습니다. 명백히 받아들일 수 없는 오래된 결과입니다.

하지만이 아키텍처에는 명백한 한계가 있는데, 이는 현재 멀티 코어 프로세서에서 매우 오래된 TPS의 병목 현상이며, 최신 PC를 사용하여 Red Alert와 같은 오래된 컴퓨터 게임을 할 때와 마찬가지로 특정 유닛이 있으면 카드가 작동하지 않는 소프트웨어 아키텍처의 문제인 TPS가 여전히 존재합니다. 문제는 소프트웨어 아키텍처에 있습니다.

이미 일부 프로토콜은 이 문제에 초점을 맞추고 있으며 현재 가장 높은 TPS를 주장하고 있으며 병렬 실행 기능도 갖춘 Solana와 같은 자체 병렬 솔루션을 내놓았다는 소식을 들을 수 있습니다. 설계 아이디어만 TON과 다른 솔라나의 핵심 아이디어는 모든 트랜잭션을 실행 종속성에 따라 여러 그룹으로 나누고 서로 다른 그룹은 서로 상태 데이터를 공유하지 않는다는 것입니다. 즉, 동일한 종속성이 없기 때문에 서로 다른 그룹의 트랜잭션은 충돌 걱정 없이 병렬로 실행할 수 있으며, 같은 그룹의 트랜잭션은 여전히 기존의 직렬 방식으로 실행됩니다.

TON에서는 직렬 실행 아키텍처를 완전히 버리고 병렬 처리를 위해 설계된 개발 패러다임인 액터 모델을 채택하여 실행 환경을 재구성했습니다. 액터 모델은 메시지 전달을 통해 기존 동시 프로그램에서 공유 상태의 복잡성을 해결하기 위해 1973년 칼 휴잇이 처음 제안했습니다. 액터 모델은 메시지 전달을 통해 병렬 계산을 구현하는 동시 계산을 위한 계산 모델로, 각 액터는 고유한 상태와 동작을 가지며 다른 액터와 어떠한 상태 정보도 공유하지 않습니다. 이 모델에서 액터는 수신 메시지를 처리하고, 새 액터를 생성하고, 더 많은 메시지를 보내고, 다음 메시지에 응답할 방법을 결정하는 기본 작업 단위입니다.

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

• 메시징: 액터는 비동기식 메시지 송수신을 통해서만 상호 작용합니다.

• 동적 아키텍처: 액터는 런타임에 더 많은 액터를 생성할 수 있으며, 이러한 역동성을 통해 액터 모델은 필요에 따라 시스템을 확장할 수 있습니다.

TON은 이 아키텍처를 사용하여 스마트 컨트랙트 모델을 설계하는데, 이는 TON에서 각 스마트 컨트랙트가 완전히 독립적인 스토리지를 가진 액터 모델이라는 것을 의미합니다. 즉, TON의 각 스마트 컨트랙트는 외부 데이터에 의존하지 않기 때문에 완전히 독립적인 저장 공간을 가진 액터 모델입니다. 또한 동일한 스마트 컨트랙트에 대한 호출은 수신 대기열에 있는 메시지 순서대로 실행되기 때문에 충돌에 대한 걱정 없이 효율적으로 트랜잭션을 병렬로 실행할 수 있습니다.

그러나 이러한 설계 방식은 디앱 개발자들에게도 다음과 같이 기존의 패러다임을 깨는 몇 가지 새로운 함의를 가지고 있습니다.

1. 스마트 컨트랙트 간 비동기 호출: TON의 스마트 컨트랙트 내부에서는 스마트 컨트랙트를 호출할 수 있는 방법이 없습니다. TON의 스마트 컨트랙트는 외부 컨트랙트를 원자적으로 호출하거나 외부 컨트랙트 데이터에 접근할 수 없으며, 솔리디티에서는 컨트랙트 A의 함수1이 컨트랙트 B의 함수2를 호출하거나 컨트랙트 C의 읽기 전용 함수3를 통해 특정 상태 데이터에 접근하는 등 전체 프로세스가 원자적이며 하나의 트랜잭션으로 실행되는 것을 알 수 있습니다. 전체 프로세스가 원자적이며, 하나의 트랜잭션으로 실행되는 매우 쉬운 방식이지만, TON에서는 이것이 불가능하고 외부 스마트 컨트랙트와의 상호작용은 내부 메시지라고도 하는 새로운 트랜잭션을 패킹하여 비동기적으로 실행되며, 실행 중 블록을 하지 못하도록 하여 계약이 블록화되는 것을 방지할 수 있습니다. 또한 실행 결과를 얻기 위해 실행을 차단할 수 없습니다.

예를 들어, 거래 라우팅을 관리하는 단일 라우터 컨트랙트가 있고 각 풀이 특정 페어와 관련된 LP 데이터를 관리하는 EVM의 일반적인 패러다임을 사용하여 DEX를 개발하는 경우, USDT-DAI와 DAI-ETH라는 두 개의 풀이 있다고 가정해 봅시다. 사용자가 USDT를 통해 이더를 직접 구매하고자 할 때, 라우터 콘트랙트를 통해 단일 트랜잭션에서 두 풀을 순차적으로 요청하여 아토믹 트랜잭션을 완료할 수 있습니다. 그러나 이는 TON에서는 달성하기 쉽지 않으며 새로운 개발 패러다임을 고려해야 합니다. 이 패러다임을 그대로 사용한다면 정보의 흐름은 다음과 같이 보일 수 있습니다: 요청에는 사용자가 시작한 외부 메시지와 3개의 내부 메시지가 수반됩니다(실제 개발에서는 ERC20 패러다임도 사용해야 하므로 차이점을 설명하기 위해 사용됨을 유의하세요). (이는 차이점을 설명하기 위한 것으로, 실제 개발에서는 ERC20 패러다임도 다시 설계해야 합니다).

2. 왼쪽;">2. 컨트랙트 간 호출 시 실행 오류 상황을 어떻게 처리할지 신중하게 고려하고, 각 컨트랙트 간 호출에 해당하는 바운스 기능을 설계해야 합니다. 주류 EVM에서는 트랜잭션이 실행 중에 문제가 발생하면 전체 트랜잭션이 롤백, 즉 초기 실행 상태로 재설정된다는 것을 알고 있습니다. 이는 직렬 단일 스레드 모델에서는 쉽게 이해할 수 있습니다. 그러나 TON에서는 컨트랙트 간 호출이 비동기적으로 실행되기 때문에 후속 단계 중 하나에서 오류가 발생하더라도 이미 성공적으로 실행된 트랜잭션이 이미 실행되어 확인되었기 때문에 문제가 발생할 수 있습니다. 따라서 TON은 내부 메시지에 의해 트리거된 후속 실행 프로세스에서 오류가 발생하면 트리거 컨트랙트가 예약한 바운스 기능을 사용하여 트리거 컨트랙트의 일부 상태를 리셋할 수 있도록 바운스 메시지라는 특수 메시지 타입을 설정했습니다.

3. 왼쪽;">3. 일부 복잡한 경우, 먼저 수신된 트랜잭션이 반드시 먼저 실행되지 않을 수 있으므로 이러한 타이밍 관계를 미리 정할 수 없습니다. 이러한 비동기식 병렬 스마트 컨트랙트 호출 시스템에서는 처리 작업의 순서를 정의하기 어려울 수 있습니다. 이것이 바로 TON의 각 메시지에 논리적 시간인 램포트 시간(나중에 lt라고 함)이 있는 이유입니다. 이는 어떤 이벤트가 다른 이벤트를 트리거하는지, 검증자가 먼저 처리해야 하는 것이 무엇인지 이해하는 데 사용됩니다. 간단한 모델의 경우 먼저 수신된 트랜잭션이 먼저 실행되어야 합니다.

이 모델에서 A와 B는 각각 두 개의 스마트 컨트랙트를 나타내며, tx1_lt < tx2_lt if msg1_lt < msg2_lt의 시간적 관계가 존재합니다.

그러나 좀 더 복잡한 경우에는 이 규칙이 무너집니다. 공식 문서에서 A, B, C라는 세 개의 컨트랙트가 있다고 가정해 보겠습니다. 한 트랜잭션에서 A가 내부 메시지인 msg1과 msg2를 두 개 보내면 하나는 B에게, 다른 하나는 C에게 보냅니다. 이 메시지들이 생성된 정확한 순서(먼저 msg1, 다음 msg2)대로 생성되더라도 msg1이 msg2 이전에 처리될지 확신할 수는 없습니다. 이는 A에서 B로, A에서 C로 가는 경로의 길이와 검증자 집합이 다를 수 있기 때문입니다. 이러한 컨트랙트가 서로 다른 조각 체인에 있는 경우, 메시지 중 하나가 대상 컨트랙트에 도달하는 데 여러 블록이 걸릴 수 있습니다. 즉, 그림과 같이 두 가지 가능한 트랜잭션 경로가 있습니다.

4. TON에서 스마트 컨트랙트의 영구 저장은 데이터 구조로 셀 기반의 방향성 비순환 그래프를 채택하여 인코딩 규칙에 따라 데이터가 셀로 압축됨과 동시에 방향성 비순환 그래프에 따라 아래로 확장되는 구조로, 데이터 요청 알고리즘의 차이로 인해 상태 데이터의 해시맵을 기반으로 하는 EVM의 구조 구성과는 차이가 있습니다. 데이터 요청 알고리즘이 다르기 때문에 TON은 데이터 처리 깊이에 따라 가스 가격을 다르게 설정하고 셀이 깊을수록 데이터 처리에 필요한 가스도 높아집니다. 따라서 일부 악의적인 사용자가 스팸 메시지를 대량으로 전송하여 특정 스마트 컨트랙트의 얕은 셀을 모두 차지하면 정직한 사용자의 저장 비용이 점점 더 높아지는 DOS 공격 패러다임이 TON에 존재하게 되는 것이죠. 반면, EVM에서는 해시맵의 쿼리 복잡도가 o(1)이므로 동일한 가스를 가지며 비슷한 문제가 발생하지 않습니다. 따라서 톤 댑 개발자는 스마트 컨트랙트에서 무제한 데이터 타입을 피해야 합니다. 제한되지 않은 데이터 유형이 나타나면 슬라이싱을 통해 분할해야 합니다.

5. 스마트 컨트랙트가 스토리지 임대료를 지불해야 한다는 점, 스마트 컨트랙트가 TON에서 자연스럽게 확장 가능하다는 점, TON의 모든 지갑 주소가 초기화되지 않은 스마트 컨트랙트인 기본 추상 계정 기능 등과 같이 덜 구체적인 기능도 있습니다. 개발자들이 주의해서 살펴봐야 할 사항들이 있습니다.

위는 제가 TON 관련 기술 경험의 일부를 배운 기간이며, 여러분과 공유하기 위해 잘못된 위치에 쓰여진 것이 있으니 수정해주시길 바라며, 동시에 텔레그램의 엄청난 양의 트래픽 자원으로 TON 생태계가 Web3의 새로운 애플리케이션을 가져올 것이라고 생각하며, TON DApp 개발 파트너에도 관심이 있습니다. TON 디앱 개발에 관심이 있으신 분들은 저에게 연락을 주시면 논의해 보겠습니다.