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

원저자: @웹3마리오

소개: TON 생태계에서 가장 큰 게임인 Notcoin이 Binance에 출시되고 완전히 유통된 토큰 경제 모델로 인해 엄청난 부의 효과가 발생하면서 TON은 단시간에 큰 주목을 받았습니다. 친구와 이야기를 나눈 후 TON의 기술적 한계가 비교적 높고 DApp 개발 패러다임이 주류 퍼블릭 체인 프로토콜과 매우 다르다는 것을 알게 되었습니다. 따라서 관련 주제를 심도 있게 연구하는 데 시간을 투자했고, 여러분과 공유할 수 있는 몇 가지 경험이 있습니다. 간단히 말해서 TON의 핵심 설계 개념은 기존 블록체인 프로토콜을 하향식으로 재구성하고 상호 운용성을 포기하는 대가로 높은 동시성과 높은 확장성을 궁극적으로 추구하는 것입니다.

TON의 핵심 설계 개념 – 높은 동시성과 높은 확장성

TON에서 모든 복잡한 기술 선택의 목적은 높은 동시성과 높은 확장성을 추구하는 데서 비롯된다고 할 수 있습니다. 물론, 탄생 배경에서 이를 이해하는 것은 어렵지 않습니다. TON 또는 The Open Network는 L1 블록체인과 여러 구성 요소로 구성된 분산 컴퓨팅 네트워크입니다. TON은 원래 Telegrams 창립자 Nikolai Durov와 그의 팀이 개발했으며, 현재는 전 세계의 독립적인 기여자 커뮤니티에서 지원 및 유지 관리하고 있습니다. TON의 탄생은 Telegram 팀이 스스로 블록체인 솔루션을 모색하기 시작한 2017년으로 거슬러 올라갑니다. 당시 Telegrams의 9자리 사용자 기반을 지원할 수 있는 기존 L1 블록체인이 없었기 때문에 그들은 당시 Telegram Open Network라고 불렸던 자체 블록체인을 설계하기로 결정했습니다. 2018년이 왔습니다. TON을 실현하는 데 필요한 리소스를 확보하기 위해 Telegram은 2018년 1분기에 Gram 토큰(나중에 Toncoin으로 이름 변경) 판매를 시작했습니다. 2020년 규제 문제로 인해 Telegram 팀은 TON 프로젝트에서 철수했습니다. 이후 소수의 오픈 소스 개발자와 Telegram 대회 수상자가 TON 코드베이스를 인수하고 프로젝트 이름을 The Open Network로 변경했으며, 원래 TON 백서에 설명된 원칙에 따라 오늘날까지 블록체인을 적극적으로 개발하고 있습니다.

설계 목표가 Telegram의 분산 실행 환경이기 때문에 자연스럽게 두 가지 문제에 직면하게 됩니다. 높은 동시 요청과 방대한 데이터입니다. 알다시피, 기술의 발전으로 가장 높은 TPS를 주장하는 Solana는 측정된 최대 TPS가 65,000에 불과하여 수백만 TPS가 필요한 Telegram 생태계를 지원하기에 충분하지 않습니다. 동시에 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비트 이진수로 고유하게 식별할 수 있습니다. 이 구조에서 이진 표현에서 단 하나의 비트만 다르면 두 정점은 인접합니다. 예를 들어, 3차원 하이퍼큐브에서 정점 000과 정점 001은 마지막 비트만 다르기 때문에 인접합니다. 위의 예는 2차원 하이퍼큐브입니다.

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

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

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

의심하기 쉬운 또 다른 점이 있습니다. 메인 체인과 각 작업 체인이 연결되어 있다는 것을 알아차렸을 것입니다. 그러면 모든 크로스 체인 정보가 코스모스처럼 메인 체인을 통해 전달될 수 있습니다. TON의 설계 개념에서 메인 체인은 가장 중요한 작업을 처리하는 데만 사용됩니다. 즉, 많은 작업 체인의 최종성을 유지하는 데 사용됩니다. 메인 체인을 통해 메시지를 라우팅하는 것은 불가능한 것은 아니지만 결과적으로 발생하는 처리 수수료는 매우 비쌀 것입니다.

마지막으로, 합의 알고리즘에 대해 간단히 언급하겠습니다. TON은 BFT+PoS 방식을 사용합니다. 즉, 모든 스테이커가 블록 패키징에 참여할 수 있는 기회가 있습니다. TON의 선거 거버넌스 계약은 정기적으로 모든 스테이커에서 패키징 검증자 클러스터를 무작위로 선택합니다. 검증자라고 하는 선택된 노드는 BFT 알고리즘을 통해 블록을 패키징합니다. 잘못된 정보를 패키징하거나 악행을 저지르면 스테이킹된 토큰이 몰수되고, 그렇지 않으면 블록 보상을 받습니다. 이는 기본적으로 일반적인 선택이므로 여기서는 소개하지 않겠습니다.

Actor 기반 스마트 계약 및 완전 병렬 실행 환경

TON과 주류 블록체인 프로토콜의 또 다른 차이점은 스마트 계약 실행 환경입니다. 주류 블록체인 프로토콜의 TPS 한계를 극복하기 위해 TON은 하향식 설계 방식을 채택하고 Actor 모델을 사용하여 스마트 계약과 실행 방법을 재구성하여 완전한 병렬 실행 기능을 갖출 수 있었습니다.

대부분의 주류 블록체인 프로토콜이 단일 스레드 직렬 실행 환경을 사용한다는 것을 알고 있습니다. 이더리움을 예로 들면, 실행 환경 EVM은 트랜잭션을 입력으로 받는 상태 머신입니다. 블록 생성 노드가 블록을 패키징하여 트랜잭션을 정렬하면 이 순서대로 EVM을 통해 트랜잭션을 실행합니다. 전체 프로세스는 완전히 직렬이고 단일 스레드입니다. 즉, 한 번에 하나의 트랜잭션만 실행할 수 있습니다. 이것의 장점은 트랜잭션 순서가 확인되는 한 실행 결과가 광범위한 분산 클러스터에서 일관적이라는 것입니다. 동시에, 한 번에 하나의 트랜잭션만 직렬로 실행되므로 실행 프로세스 동안 다른 트랜잭션이 액세스할 상태 데이터를 수정할 수 없으므로 스마트 계약 간의 상호 운용성을 달성할 수 있습니다. 예를 들어, USDT를 사용하여 Uniswap을 통해 ETH를 구매합니다. 트랜잭션이 실행되면 트랜잭션 쌍의 LP 분포가 특정 값이므로 특정 수학적 모델을 통해 해당 결과를 얻을 수 있습니다. 그러나 그렇지 않고 본딩 커브 계산을 실행할 때 다른 LP가 새로운 유동성을 추가하게 되면 계산 결과가 오래된 결과가 되며, 이는 당연히 용납할 수 없습니다.

하지만 이 아키텍처는 또한 분명한 한계를 가지고 있습니다. 즉, TPS 병목 현상이며, 이 병목 현상은 현재 멀티코어 프로세서에서는 매우 오래되어 보입니다. 마치 최신 PC를 사용하여 Red Alert와 같은 오래된 컴퓨터 게임을 하는 것과 같습니다. 전투 유닛 수가 일정 수준에 도달하면 여전히 멈춰 있는 것을 알게 될 것입니다. 이는 소프트웨어 아키텍처의 문제입니다.

일부 프로토콜이 이미 이 문제에 주의를 기울이고 자체 병렬 솔루션을 제안했다는 소식을 들었을 것입니다. 예를 들어, 현재 가장 높은 TPS를 가진 것으로 알려진 Solana도 병렬로 실행할 수 있는 기능이 있습니다. 그러나 설계 개념은 TON과 다릅니다. Solana에서 핵심 아이디어는 모든 트랜잭션을 실행 종속성에 따라 여러 그룹으로 나누는 것이며, 다른 그룹 간에 상태 데이터가 공유되지 않습니다. 즉, 동일한 종속성이 없으므로 충돌을 걱정하지 않고 다른 그룹의 트랜잭션을 병렬로 실행할 수 있습니다. 동일한 그룹의 트랜잭션의 경우 여전히 기존의 직렬 방법을 사용하여 실행합니다.

그러나 TON에서는 직렬 실행 아키텍처를 완전히 포기하고 병렬 처리를 위해 설계된 개발 패러다임인 Actor 모델을 채택하여 실행 환경을 재구성합니다.소위 Actor 모델은 1973년 Carl Hewitt가 처음 제안한 것으로, 메시지 전달을 통해 기존 동시 프로그램에서 공유 상태의 복잡성을 해결하는 것을 목표로 합니다.각 Actor는 고유한 개인 상태와 동작을 가지고 있으며 다른 Actor와 상태 정보를 공유하지 않습니다.Actor 모델은 메시지 전달을 통해 병렬 컴퓨팅을 구현하는 동시 컴퓨팅을 위한 컴퓨팅 모델입니다.이 모델에서 Actor는 수신된 메시지를 처리하고, 새로운 Actor를 만들고, 더 많은 메시지를 보내고, 다음 메시지에 응답하는 방법을 결정할 수 있는 기본 작업 단위입니다.Actor 모델은 다음과 같은 특성을 가져야 합니다.

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

• 메시지 전달: 행위자는 메시지를 보내고 받는 방식으로만 상호 작용하며, 메시지 전달은 비동기적으로 수행됩니다.

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

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

하지만 이 디자인은 몇 가지 새로운 영향도 가져온다. DApp 개발자의 경우, 익숙한 개발 패러다임이 다음과 같이 깨질 것이다.

1. 스마트 계약 간 비동기 호출: TON의 스마트 계약 내에서 외부 계약을 호출하거나 외부 계약 데이터에 원자적으로 액세스하는 것은 불가능합니다. Solidity에서 계약 A의 함수 1에서 계약 B의 함수 2를 호출하거나 계약 C의 읽기 전용 함수 3을 통해 특정 상태 데이터에 액세스하는 것은 전체 프로세스가 원자적이고 하나의 트랜잭션에서 실행된다는 것을 알고 있습니다. 이는 매우 쉬운 일입니다. 그러나 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가

그러나 더 복잡한 경우에는 이 규칙이 깨질 것입니다. 공식 문서에 그러한 예가 있습니다. 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은 다른 깊이에서 데이터 처리에 대해 다른 Gas 가격을 설정합니다. Cell 데이터 처리가 깊을수록 필요한 Gas가 높아집니다. 따라서 TON에는 DOS 공격 패러다임이 있습니다. 즉, 일부 악의적인 사용자가 많은 수의 스팸 메시지를 보내 스마트 계약의 모든 얕은 Cell을 점유하여 정직한 사용자의 저장 비용이 점점 더 높아집니다. EVM에서 해시맵의 쿼리 복잡도는 o(1)이므로 Gas가 동일하고 비슷한 문제가 없습니다. 따라서 TON Dapp 개발자는 스마트 계약에서 무제한 데이터 유형을 피해야 합니다. 무제한 데이터 유형이 나타나면 샤딩을 통해 조각화해야 합니다.

5. 일부 기능은 그다지 특별하지 않습니다. 예를 들어, 저장소 임대료를 지불하기 위해 스마트 계약이 필요하다는 것, 스마트 계약이 TON에서 자연스럽게 업그레이드 가능하다는 것, 네이티브 추상 계정 기능, 즉 TON의 모든 지갑 주소는 스마트 계약이지만 초기화되지 않는다는 것 등은 개발자가 세심한 주의를 기울여야 합니다.

위에 나열한 내용은 이 기간 동안 TON 관련 기술을 배우면서 제가 경험한 몇 가지입니다. 여러분과 공유하고 싶습니다. 실수가 있다면 바로잡아 주셨으면 합니다. 동시에, Telegram의 방대한 트래픽 리소스로 TON 생태계가 Web3에 새로운 애플리케이션을 확실히 가져올 것이라고 믿습니다. TON DApp 개발에 관심이 있는 친구들도 저에게 연락하여 논의할 수 있습니다.

X 링크: https://x.com/web3_mario

텔레그램 핸들: @MarioChin Web3

이 기사는 인터넷에서 발췌한 것입니다: TON의 기술적 특징과 스마트 계약 개발 패러다임에 대한 자세한 설명

관련 항목: 기반 밈 해석 및 기반 기관: 기반 생태계의 미래는 어디에 있을까?

원본 출처: 제시 폴락 편집: 오데일리 플래닛 데일리 웬저 편집자 주: 2024년 가장 인기 있는 L2 생태계 중 하나인 Base의 부상은 적절한 시기, 적절한 장소, 적절한 사람들의 결과라고 할 수 있습니다. Memecoin 열풍이 가져온 신의 선물 기회뿐만 아니라 OP 생태계를 기반으로 하고 Coinbase가 지원하는 L2 저가스 네트워크와 프로토콜 리더 제시 폴락과 생태계 구축자 그룹의 노고도 있습니다. TVL이 55억 달러에 달한 Base 생태계에 대해 제시는 최근 뉴욕 밈 해커톤에서 간략한 리뷰와 요약을 제공했으며, 최근 NFT 형태로 Zora에 콘텐츠를 올렸고, 4,000개 이상을 주조했습니다…