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

저자 : @Web3Mario

소개

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

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

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

텔레그램을 위한 탈중앙화된 실행 환경으로 설계되었기 때문에 자연스럽게 높은 동시성 요청과 방대한 양의 데이터라는 두 가지 문제에 직면할 수밖에 없었으며, 현재까지 기술 개발로 인해 가장 높은 TPS를 가지고 있다고 주장되는 솔라나의 측정된 최대 TPS는 65,000에 불과하여 텔레그램의 백만 TPS 요구 사항을 지원하기에는 분명히 부족하다는 것을 우리는 알고 있습니다. 생태계. 동시에 텔레그램의 대규모 적용으로 인해 생성되는 데이터의 양은 이미 하늘을 넘어섰고, 네트워크의 모든 노드에 완전한 데이터를 저장하라고 요구한다면 극도로 이중화된 분산 시스템으로서의 블록체인은 비현실적일 수 밖에 없습니다.

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

• 인피니트 샤딩 패러다임을 채택하여 블록체인 프로토콜을 보다 효율적으로 설계했습니다. 데이터 중복 문제를 해결하기 위해 '샤딩 패러다임' 설계 시스템을 도입하여 성능 병목 현상을 완화하면서 빅데이터를 전송할 수 있으며,

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

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

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

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

• AccountChain: 특정 계정과 관련된 일련의 트랜잭션으로 구성된 체인을 나타내는 계층으로, 트랜잭션이 체인 구조로 구성될 수 있는 이유는 상태 머신의 경우 실행 규칙만 일정하다면 상태 머신은 동일한 시퀀스의 명령을 받은 후 동일한 결과를 얻게 되기 때문입니다. 명령을 받으면 동일한 결과를 얻을 수 있기 때문에 모든 블록체인 분산 시스템에서 트랜잭션의 연쇄적 순서는 필수이며, TON도 예외는 아닙니다. 계정 체인은 TON 네트워크의 가장 기본적인 구성 요소이며, 일반적으로 가상의 개념으로 별도의 계정 체인이 실제로 존재할 가능성은 거의 없습니다.

• 샤드체인: 대부분의 맥락에서 샤드체인은 계정 체인의 집합인 TON의 실제 단위입니다.

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

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

이러한 패러다임을 채택함으로써 TON 네트워크는 다음 세 가지 기능을 지원합니다.

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

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

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

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

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

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

이미지 src="https://img.jinse.cn/7238604_image3.png" alt="TON의 기술적 특징 및 스마트 컨트랙트 개발 패러다임 상세 설명">

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

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

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

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

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

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

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

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

그러나이 아키텍처에는 TPS의 병목 현상이라는 명확한 한계가 있으며,이 병목 현상은 최신 PC를 사용하여 레드 얼럿과 같은 오래된 컴퓨터 게임을 플레이하는 경우 특정 수의 전투 유닛이있을 때 여전히 멈추는 것처럼 현재의 멀티 코어 프로세서에서는 오래된 것처럼 보이며 이는 소프트웨어 아키텍처의 문제입니다.

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

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

• 캡슐화와 독립성

액터 모델에는 다음과 같은 특징이 필요합니다: 각 액터는 메시지를 처리할 때 완전히 독립적이며 서로 간섭하지 않고 메시지를 병렬로 처리할 수 있습니다.

• 메시징: 액터는 메시지를 주고받는 방식으로만 상호작용하며, 메시징은 비동기식입니다.

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

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

그러나 이 설계 솔루션은 디앱 개발자들에게 다음과 같이 기존 개발 패러다임을 깨는 몇 가지 새로운 시사점을 제공합니다.

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

예를 들어 탈중앙 거래소를 개발한다고 가정할 때, EVM의 일반적인 패러다임을 채택한다면 일반적으로 거래 라우팅을 관리하는 통합 라우터 컨트랙트가 존재하고, 각 풀은 특정 쌍의 거래와 관련된 LP 데이터를 개별적으로 관리한다고 가정할 때 현재 USDT-DAI와 DAI-ETH의 두 풀이 있고, 사용자가 USDT로 ETH를 직접 구매하고자 할 때 라우터 컨트랙트를 이용해 USDT로 ETH를 직접 구매할 수 있습니다. 사용자가 USDT를 통해 이더를 직접 구매하고자 하는 경우 라우터 컨트랙트를 통해 한 번의 트랜잭션으로 두 풀을 순차적으로 요청하여 원자적으로 트랜잭션을 완료할 수 있습니다. 그러나 이는 TON에서는 달성하기 쉽지 않으며 새로운 개발 패러다임을 고려해야 합니다. 이 패러다임을 여전히 재사용한다면 정보의 흐름은 다음과 같을 수 있으며, 요청에는 사용자가 시작한 외부 메시지와 세 개의 내부 메시지가 수반됩니다(실제 개발에서도 ERC20 패러다임이 사용되지만 차이를 설명하기 위해 사용됨을 참고하시기 바랍니다). 실제 개발에서는 ERC20 패러다임을 다시 설계해야 합니다.)

이미지 src="https://img.jinse.cn/7238605_image3.png" alt="TON의 기술적 특징과 스마트 컨트랙트 개발 패러다임에 대한 자세한 설명">

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

이미지 src="https://img.jinse.cn/7238606_image3.png" alt="TON의 기술적 특징 및 스마트 컨트랙트 개발 패러다임에 대한 상세 설명">

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

이미지 src="https://img.jinse.cn/7238607_image3.png" alt="TON의 기술적 특징과 스마트 컨트랙트 개발 패러다임에 대한 자세한 설명">

이 모델에서 A와 B는 두 개의 스마트 컨트랙트를 나타내며, 만약 msg1_lt < msg2_ lt, tx1_lt < tx2_lt의 시간적 관계가 있습니다.

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

이미지 src="https://img.jinse.cn/7238608_image3.png" alt="TON의 기술적 특징과 스마트 컨트랙트 개발 패러다임에 대한 자세한 설명">

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

이미지 src="https://img.jinse.cn/7238609_image3.png" alt="TON의 기술적 특징과 스마트 컨트랙트 개발 패러다임에 대한 자세한 설명">

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