원저자: @Web3 Mario
소개: TON 생태계 최대 게임인 Notcoin이 바이낸스에 출시되고, 완전 순환하는 토큰 경제 모델로 인한 막대한 부의 효과로 TON은 짧은 시간 내에 큰 주목을 받았습니다. 친구와 이야기를 나눈 후 TON의 기술 수준이 상대적으로 높고 DApp 개발 패러다임이 주류 퍼블릭 체인 프로토콜과 매우 다르다는 사실을 알게 되었기 때문에 관련 주제에 대해 심층적인 연구를 수행하는 데 시간을 투자하고 몇 가지 통찰력을 공유했습니다. 간단히 말해서, TON의 핵심 설계 개념은 전통적인 블록체인 프로토콜을 상향식 방식으로 재구성하고 상호 운용성을 희생하면서 높은 동시성과 높은 확장성을 달성하는 것입니다.
TON의 핵심 디자인 아이디어 - 높은 동시성 및 높은 확장성
TON의 모든 복잡한 기술 선택의 목적은 높은 동시성과 높은 확장성을 추구하는 데서 나온다고 할 수 있다. 물론, 탄생 배경부터 이를 이해하는 것은 어렵지 않다. TON(The Open Network)은 L1 블록체인과 여러 구성 요소를 포함하는 분산형 컴퓨팅 네트워크입니다. TON은 원래 Telegram 창립자 Nikolai Durov와 그의 팀이 개발했으며 현재는 독립적인 기여자로 구성된 글로벌 커뮤니티에서 지원하고 유지관리하고 있습니다. 텔레그램의 탄생은 텔레그램 팀이 스스로 블록체인 솔루션을 탐색하기 시작한 2017년으로 거슬러 올라갑니다. 당시 기존 L1 블록체인은 Telegram의 9자리 사용자 기반을 지원할 수 없었기 때문에 Telegram Open Network라고 불리는 자체 블록체인을 설계하기로 결정했습니다. 2018년이 왔습니다. TON을 구현하는 데 필요한 자원을 확보하기 위해 Telegram은 2018년 1분기에 Gram 토큰(나중에 Toncoin으로 이름 변경) 판매를 시작했습니다. 2020년 텔레그램 팀은 규제 문제로 인해 TON 프로젝트에서 탈퇴했습니다. 그 후, 소규모 오픈 소스 개발자 그룹과 텔레그램 대회 우승자들이 TON의 코드 베이스를 인수하고 프로젝트 이름을 The Open Network로 변경했으며, 원본 TON 백서에 설명된 원칙을 준수하면서 오늘날까지 블록체인을 적극적으로 개발하고 있습니다.
그래서 텔레그램을 위한 분산 실행 환경으로 설계되었기 때문에 당연히 높은 동시 요청과 대용량 데이터라는 두 가지 문제에 직면할 수 밖에 없습니다. 현재까지의 기술 발전으로 인해 최고 TPS로 알려진 솔라나는 측정된 TPS는 65,000으로 가장 높으며 이는 수백만 TPS가 필요한 Telegram 생태계를 지원하기에는 충분하지 않습니다. 동시에 텔레그램의 대규모 적용으로 인해 생성되는 데이터의 양은 이미 하늘을 넘어섰습니다. 극도로 중복된 분산 시스템인 블록체인은 네트워크의 모든 노드에서 데이터의 전체 복사본을 저장해야 합니다. 또한 비현실적이다.
따라서 위의 두 가지 문제를 해결하기 위해 TON은 주류 블록체인 프로토콜에 대해 두 가지 최적화를 수행했습니다.
무한 샤딩 패러다임을 채택하여 시스템을 설계함으로써 데이터 중복 문제를 해결하여 빅 데이터를 전달하고 성능 병목 현상 문제를 완화할 수 있습니다.
Actor 모델을 기반으로 한 완전한 병렬 실행 환경을 도입함으로써 네트워크 TPS가 크게 향상되었습니다.
블록체인 체인 만들기 - 무제한 샤딩 기능을 통해 각 계정에는 독점적인 계정 체인이 있습니다.
이제 우리는 샤딩이 성능을 향상하고 비용을 절감하기 위해 대부분의 블록체인 프로토콜에 대한 주류 솔루션이 되었음을 알고 있으며, TON은 이를 극한으로 끌어 올려 소위 무한 샤딩 패러다임인 무한 샤딩 패러다임을 제안했습니다. 네트워크 부하에 따라 샤드 수를 동적으로 늘리거나 줄입니다. 이 패러다임을 통해 TON은 높은 성능을 유지하면서 대규모 거래와 스마트 계약 운영을 처리할 수 있습니다. 이론적으로 TON은 각 계정에 대한 독점 계정 체인을 구축하고 특정 규칙을 통해 이러한 체인 간의 상호 운용성을 보장할 수 있습니다.
추상적으로 이해하기 위해 TON에는 총 4가지 수준의 체인 구조가 있습니다.
계정 체인: 이 레이어 체인은 계정과 관련된 일련의 트랜잭션으로 구성된 체인을 나타냅니다. 트랜잭션이 체인 구조를 형성할 수 있는 이유는 상태 머신의 경우 실행 규칙이 일관적인 한 상태 머신이 동일한 순서로 지시를 받은 후 얻은 결과는 일관되므로 모든 블록체인 분산 시스템에서는 트랜잭션의 체인 순서가 필요하며 TON도 예외는 아닙니다. 계정 체인은 TON 네트워크의 가장 기본적인 구성 단위입니다. 일반적으로 계정 체인은 가상 개념이며 실제로 독립적인 계정 체인이 존재할 가능성은 거의 없습니다.
샤드 체인: 대부분의 경우 샤드 체인은 TON의 실제 구성 요소 단위입니다. 소위 샤드 체인은 계정 체인의 모음입니다.
WorkChain: EVM 기반 작업 체인을 생성하고 이에 대해 Solidity 스마트 계약을 실행하는 등 사용자 지정 규칙이 있는 샤딩 체인 세트라고도 할 수 있습니다. 이론적으로는 커뮤니티의 모든 사람이 자신만의 작업 체인을 만들 수 있습니다. 실제로 이를 구축하는 것은 (비싼) 수수료를 지불하고 검증인의 2/3 표를 얻어 작업 체인 생성을 승인하기 전에 다소 복잡한 작업입니다.
메인 체인(MasterChain): 마지막으로 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차원 하이퍼큐브입니다.
하이퍼큐브 라우팅 프로토콜에서 소스 작업 체인에서 대상 작업 체인으로의 메시지 라우팅 프로세스는 소스 작업 체인과 대상 작업 체인 주소의 이진 표현을 비교하여 수행됩니다. 라우팅 알고리즘은 이 두 주소 사이의 최소 거리(즉, 이진 표현의 서로 다른 비트 수)를 찾고 대상 작업 체인에 도달할 때까지 인접한 작업 체인을 통해 정보를 점진적으로 전달합니다. 이 방법은 데이터 패킷이 최단 경로를 따라 전송되도록 보장하여 네트워크의 통신 효율성을 향상시킵니다.
물론, 이 프로세스를 단순화하기 위해 TON은 사용자가 일반적으로 머클 트리 루트인 특정 라우팅 경로에 대한 유효한 증거를 제공할 수 있는 경우 노드가 해당 경로의 신뢰성을 직접 인식할 수 있는 낙관적인 기술 솔루션도 제안했습니다. 사용자 속성이 제출한 메시지로, 이를 인스턴트 하이퍼큐브 라우팅이라고도 합니다.
따라서 TON의 주소와 다른 블록체인 프로토콜 간에는 명백한 차이가 있음을 알 수 있습니다. 대부분의 다른 주류 블록체인 프로토콜은 타원형 암호화 알고리즘에 의해 생성된 공개 키와 개인 키에 해당하는 해시를 주소로 사용하기 때문입니다. 주소는 고유한 주소로만 사용되며 라우팅 주소 지정 기능을 수행할 필요가 없으며 TON의 주소는 두 부분(workchain_id, account_id)으로 구성됩니다. 여기서 workchain_id는 하이퍼큐브 라우팅 알고리즘 주소에 따라 인코딩됩니다. 여기서는 자세히 다루지 않겠습니다.
의심을 불러일으키기 쉬운 또 다른 점이 있습니다. 메인 체인은 각 작업 체인과 링크 관계를 갖고 있으므로 모든 크로스체인 정보가 메인 체인을 통해 전달되는 것만으로도 충분하지 않을까요? 코스모스처럼. TON의 설계 개념에서 메인 체인은 가장 중요한 작업, 즉 많은 작업 체인의 최종성을 유지하는 데에만 사용됩니다. 메인 체인을 통해 메시지를 라우팅하는 것이 불가능하지는 않지만 결과적으로 처리 비용이 매우 비쌉니다. .
마지막으로 합의 알고리즘에 대해 간략히 설명하면 TON은 BFT+PoS 방식을 채택합니다. 즉, 모든 스테이커는 블록 패키징에 참여할 수 있습니다. TON의 선거 거버넌스 계약은 정기적으로 모든 스테이커 중에서 패키징 검증자를 무작위로 선택합니다. 클러스터에서 검증자로 선택된 노드는 BFT 알고리즘을 통해 블록을 패키징하고 생성합니다. 잘못된 정보를 패키징하거나 악의적인 행위를 하면 스테이크 토큰이 몰수되고 그렇지 않으면 블록 보상을 받게 됩니다. 이는 기본적으로 일반적인 선택이므로 여기서는 소개하지 않겠습니다.
Actor 모델 기반의 스마트 계약 및 완전 병렬 실행 환경
TON과 주류 블록체인 프로토콜의 또 다른 차이점은 스마트 계약 실행 환경입니다. 주류 블록체인 프로토콜 TPS의 한계를 극복하기 위해 TON은 상향식 설계 아이디어를 채택하고 행위자 모델을 사용하여 스마트 계약과 실행 방법을 재구성하여 완전히 병렬화할 수 있는 능력을 갖췄습니다.
우리는 대부분의 주류 블록체인 프로토콜이 단일 스레드 직렬 실행 환경을 사용한다는 것을 알고 있습니다. Ethereum을 예로 들면, EVM의 실행 환경은 블록 생성 노드가 정렬 후 블록을 패키징하여 트랜잭션을 완료하는 상태 머신입니다. , 트랜잭션은 EVM을 통해 이 순서대로 실행됩니다. 전체 프로세스는 완전히 직렬이며 단일 스레드입니다. 즉, 특정 시간에 하나의 트랜잭션만 실행할 수 있다는 장점이 있습니다. 광범위한 분산 클러스터에는 일관성이 있습니다. 동시에 하나의 트랜잭션만 동시에 직렬로 실행되므로 실행 프로세스 중에 다른 트랜잭션이 실행될 수 없습니다. 액세스할 특정 상태 데이터를 수정하여 스마트 계약 간의 상호 운용성을 달성합니다. 예를 들어 USDT를 사용하여 Uniswap을 통해 ETH를 구매하면 거래 쌍의 LP 분포가 특정 값이 됩니다. 이렇게 하면 특정 수학적 모델을 통해 해당 결과를 얻을 수 있지만 이를 가정하면 다음과 같습니다. 그렇지 않은 경우, 특정 결합 곡선의 계산을 수행할 때 다른 LP가 새로운 유동성을 추가하면 계산 결과는 낡은 결과가 되며 이는 분명히 받아들일 수 없습니다.
그러나 이 아키텍처에는 TPS의 병목 현상이라는 분명한 한계가 있으며, 이 병목 현상은 현재 멀티 코어 프로세서에서 매우 오래된 것으로 보입니다. 마치 최신 PC를 사용하여 Red Alert와 같은 오래된 컴퓨터 게임을 하는 것과 같습니다. 전투 유닛 수가 특정 숫자에 도달하더라도 여전히 정체되는 것을 알 수 있습니다. 이는 소프트웨어 아키텍처의 문제입니다.
일부 프로토콜은 이미 이 문제에 관심을 기울이고 있으며 자체 병렬 솔루션을 제안했다는 소식을 들을 수 있습니다. 현재 가장 높은 TPS를 가지고 있다고 주장하는 Solana를 예로 들면 병렬 실행 기능도 있습니다. 그러나 디자인 아이디어는 TON과 다릅니다. 솔라나의 핵심 아이디어는 모든 트랜잭션을 실행 종속성에 따라 여러 그룹으로 나누고, 상태 데이터를 다른 그룹 간에 공유하지 않는다는 것입니다. 즉, 동일한 종속성이 없으므로 서로 다른 그룹의 트랜잭션은 충돌 걱정 없이 병렬로 실행될 수 있으며, 동일한 그룹 내의 트랜잭션은 여전히 전통적인 직렬 방식으로 실행됩니다.
TON에서는 직렬 실행 아키텍처를 완전히 버리고 대신 병렬성을 위해 특별히 설계된 개발 패러다임인 액터 모델을 채택하여 실행 환경을 재구성합니다. 소위 행위자 모델은 메시지 전달을 통해 전통적인 동시 프로그램의 공유 상태의 복잡성을 해결하기 위해 1973년 Carl Hewitt에 의해 처음 제안되었습니다. 각 액터에는 고유한 비공개 상태와 동작이 있으며 다른 액터와 상태 정보를 공유하지 않습니다. Actor 모델은 메시지 전달을 통해 병렬 컴퓨팅을 구현하는 동시 컴퓨팅 컴퓨팅 모델입니다. 이 모델에서 액터는 수신된 메시지를 처리하고, 새 액터를 생성하고, 더 많은 메시지를 보내고, 후속 메시지에 응답하는 방법을 결정할 수 있는 기본 작업 단위입니다. Actor 모델에는 다음과 같은 특성이 있어야 합니다.
캡슐화 및 독립성: 각 행위자는 메시지를 처리할 때 완전히 독립적이며 서로 간섭하지 않고 메시지를 병렬로 처리할 수 있습니다.
메시징: 행위자는 메시지를 보내고 받는 방식으로만 서로 상호 작용하며 메시지 전달은 비동기식입니다.
동적 구조: 액터는 런타임에 더 많은 액터를 생성할 수 있습니다. 이러한 동적 특성을 통해 액터 모델은 필요에 따라 시스템을 확장할 수 있습니다.
TON은 이 아키텍처를 채택하여 스마트 계약 모델을 설계합니다. 이는 TON에서 각 스마트 계약이 완전히 독립적인 저장 공간을 갖춘 행위자 모델임을 의미합니다. 외부 데이터에 의존하지 않기 때문입니다. 또한 동일한 스마트 계약에 대한 호출은 수신 대기열의 메시지 순서에 따라 계속 실행되므로 TON의 트랜잭션은 충돌 걱정 없이 효율적으로 병렬로 실행될 수 있습니다.
그러나 이러한 설계 방식은 DApp 개발자에게 다음과 같이 익숙한 개발 패러다임을 깨뜨릴 수도 있습니다.
1. 스마트 계약 간 비동기 호출: TON의 스마트 계약 내에서 외부 계약을 원자적으로 호출하거나 외부 계약 데이터에 액세스하는 것은 불가능합니다. Solidity에서는 계약 A의 함수 1이 계약 B의 함수 2를 호출합니다. 또는 특정 상태 데이터에 액세스할 수 없습니다. 계약 C의 읽기 전용 기능 n3을 통해. 전체 프로세스는 원자적이고 하나의 트랜잭션으로 실행됩니다. 그러나 TON에서는 이것이 불가능합니다. 외부 스마트 계약과의 모든 상호 작용이 실행됩니다. 새로운 트랜잭션을 패키징하여 비동기적으로 스마트 계약에 의해 시작된 트랜잭션을 내부 메시지라고도 합니다. 그리고 실행 결과를 얻기 위해 실행 중에 차단할 수 없습니다.
예를 들어 DEX를 개발하는 경우 EVM에 공통 패러다임을 채택하면 일반적으로 트랜잭션 라우팅을 관리하는 데 사용되는 통합 라우터 계약이 있으며 각 풀은 특정 거래 쌍과 관련된 LP 데이터를 독립적으로 관리하므로 가정합니다. 현재 USDT-DAI와 DAI-ETH 두 개의 풀이 있습니다. 사용자가 USDT를 통해 직접 ETH를 구매하려는 경우 라우터 계약을 통해 한 트랜잭션에서 이 두 풀을 순차적으로 요청하여 아토믹 트랜잭션을 완료할 수 있습니다. 그러나 TON에서는 구현하기가 그리 쉽지 않습니다. 이 패러다임이 계속 재사용된다면 이 요청에는 다음과 같은 외부 메시지가 수반될 수 있습니다. 사용자 및 세 개의 내부 메시지가 완료됩니다(이는 차이점을 설명하기 위해 사용됩니다. 실제 개발에서는 ERC 20의 패러다임도 재설계해야 합니다).
2. 계약 간 호출 시 실행 오류에 대한 처리 프로세스를 신중하게 고려하고 계약 간 호출마다 해당 바운스 기능을 설계해야 합니다. 우리는 주류 EVM에서 트랜잭션 실행 중에 문제가 발생하면 전체 트랜잭션이 롤백, 즉 실행 초기 상태로 재설정된다는 것을 알고 있습니다. 이는 직렬 단일 스레드 모델에서 이해하기 쉽습니다. 그러나 TON에서는 컨트랙트 간의 호출이 비동기적으로 실행되기 때문에 후속 링크에서 오류가 발생하더라도 이전에 성공적으로 실행된 트랜잭션이 이미 실행 및 확인된 상태이기 때문에 문제가 발생할 수 있다. 따라서 TON에는 바운스 메시지라고 하는 특별한 메시지 유형이 설정됩니다. 즉, 내부 메시지에 의해 트리거된 후속 실행 프로세스에서 오류가 발생하면 트리거된 계약이 바운스 기능을 통해 계약 내 특정 이벤트를 트리거할 수 있습니다. 트리거 계약에 의해 예약됨 일부 상태가 재설정됩니다.
3. 일부 복잡한 상황에서는 먼저 수신된 트랜잭션이 먼저 실행되지 않을 수 있으므로 이러한 타이밍 관계를 미리 설정할 수 없습니다. 비동기 및 병렬 스마트 계약 호출 시스템에서는 작업이 처리되는 순서를 정의하는 것이 어려울 수 있습니다. 이것이 바로 TON의 각 메시지가 논리적 시간 Lamport 시간(이하 lt라고 함)을 갖는 이유입니다. 이는 어떤 이벤트가 다른 이벤트를 촉발했는지, 유효성 검사기가 먼저 처리해야 하는 것이 무엇인지 이해하는 데 사용됩니다. 간단한 모델의 경우 먼저 수신된 트랜잭션이 먼저 실행되어야 합니다.
이 모델에서 A와 B는 각각 두 개의 스마트 계약을 나타내며 msg 1 _lt < msg 2 _lt이면 tx 1 _lt < tx 2 _lt와 같은 타이밍 관계가 있습니다.
그러나 더 복잡한 상황에서는 이 규칙이 깨집니다. 공식 문서에 이에 대한 예가 있습니다. A, B, C 세 개의 계약이 있다고 가정해 보겠습니다. 트랜잭션에서 A는 두 개의 내부 메시지 msg 1과 msg 2를 보냅니다. 하나는 B로, 다른 하나는 C로 보냅니다. 정확한 순서(msg 1 먼저, 그 다음 msg 2)로 생성되지만, msg 1이 msg 2보다 먼저 처리될 것이라고 확신할 수 없습니다. 이는 A에서 B로의 경로와 A에서 C로의 경로의 길이와 유효성 검사기 세트가 다를 수 있기 때문입니다. 이러한 계약이 다른 샤드 체인에 있는 경우 메시지 중 하나가 대상 계약에 도달하는 데 여러 블록이 걸릴 수 있습니다. 즉, 그림에 표시된 것처럼 두 가지 가능한 거래 경로가 있습니다.
4. TON에서 스마트 계약의 영구 저장은 데이터 구조로서 Cell을 단위로 하는 방향성 비순환 그래프를 사용합니다 . 데이터는 인코딩 규칙에 따라 동시에 Cell로 압축됩니다. 방향성 비순환 그래프의 방향은 EVM의 해시맵 기반 상태 데이터 구조 구성과 다릅니다. TON은 데이터 처리 깊이에 따라 가스 가격을 다르게 설정합니다. 셀 데이터를 처리할수록 더 많은 가스가 필요하므로 TON에는 DOS 공격의 패러다임이 있습니다. 즉, 일부 악의적인 사용자가 대량의 스팸 메시지를 보내 특정 스마트 계약의 모든 얕은 셀을 점유합니다. 이는 정직한 사용자의 저장 비용이 점점 더 높아진다는 것을 의미합니다. EVM에서는 해시맵의 쿼리 복잡도가 O(1)이므로 동일한 Gas를 가지며 비슷한 문제가 발생하지 않습니다. 따라서 TON Dapp 개발자는 스마트 계약에서 무제한 데이터 유형을 피하려고 노력해야 합니다. 제한되지 않은 데이터 유형이 나타나면 샤딩을 통해 분할해야 합니다.
5. 보관을 위해 임대료를 지불해야 하는 스마트 계약, TON의 스마트 계약은 자연스럽게 업그레이드 가능하고 기본 추상 계정 기능, 즉 TON의 모든 지갑 주소가 스마트 계약인 등 덜 특수한 일부 기능도 있습니다. 초기화되지 않은 것 등입니다. 개발자는 세심한 주의를 기울여야 합니다.
위 내용은 제가 이 기간 동안 TON 관련 기술을 학습하면서 얻은 경험 중 일부입니다. 동시에 제가 실수한 부분이 있으면 수정해 주시기 바랍니다. 동시에 Telegram의 엄청난 트래픽 리소스도 마찬가지입니다. , TON 생태계는 확실히 Web3의 플랫폼 역할을 할 것입니다. 새로운 애플리케이션을 도입하면 TON DApp 개발에 관심이 있는 친구들도 저에게 연락하여 논의할 수 있습니다.
X 링크: https://x.com/web3_mario
텔레그램 핸들: @MarioChin Web3
