글 작성자:@Web3Mario
서론: 바이낸스가 TON 생태계 최대 게임인 Notcoin을 상장하고 전량 유통 토큰 경제 모델이 초래한 막대한 부의 효과로 인해 TON은 단시간 내에 큰 관심을 받게 되었다. 친구와 대화를 나누면서 TON 기술 장벽이 높고 DApp 개발 패러다임이 주류 공공 블록체인 프로토콜과 큰 차이가 있다는 것을 알게 되어 관련 주제를 깊이 있게 연구해 본 소감을 여러분과 공유하고자 한다. 요약하자면 TON의 핵심 설계 철학은 전통적인 블록체인 프로토콜을 '하향식'으로 재구성하면서 상호 운용성을 포기함으로써 고병렬 처리 및 고확장성을 극대화하는 것이다.
TON의 핵심 설계 사상 — 고병렬 처리와 고확장성
이렇게 말할 수 있다. TON에서 모든 복잡한 기술 선택은 고병렬 처리와 고확장성을 추구하기 위한 것이며, 그 배경을 살펴보면 이를 이해하기 어렵지 않다. TON(The Open Network)은 L1 블록체인과 여러 구성요소를 포함하는 탈중앙화 컴퓨팅 네트워크이다. TON은 처음에는 텔레그램 창립자 니콜라이 두로프(Nikolai Durov)와 그의 팀이 공동 개발하였으며, 현재는 전 세계 독립 기여자 커뮤니티가 지원하고 유지 관리하고 있다. 이는 2017년으로 거슬러 올라가며, 텔레그램 팀이 자체적으로 블록체인 솔루션을 탐색하기 시작한 시점이다. 당시 어떤 기존 L1 블록체인도 텔레그램의 9자리 수 사용자 기반을 지원할 수 없었기 때문에, 그들은 자신만의 블록체인을 설계하기로 결정했고, 당시에는 Telegram Open Network라고 불렸다. 2018년에는 TON 구현에 필요한 자원을 확보하기 위해 텔레그램이 2018년 1분기에 그램(Gram) 토큰(나중에 Toncoin으로 이름 변경) 판매를 시작했다. 2020년 규제 문제로 인해 텔레그램 팀이 TON 프로젝트에서 철수하였다. 이후 일부 오픈소스 개발자들과 텔레그램 콘테스트 우승자들이 TON 코드베이스를 인수하여 프로젝트 이름을 The Open Network로 변경하고 원본 TON 백서에 명시된 원칙에 따라 지금까지 계속해서 블록체인을 적극적으로 개발해왔다.
따라서 텔레그램의 탈중앙화 실행 환경으로서의 설계 목표를 가지고 있기 때문에 자연스럽게 두 가지 문제, 즉 고병렬 요청과 방대한 데이터량에 직면하게 된다. 현재 기술 발전 수준에서 가장 높은 TPS를 자랑한다고 알려진 솔라나(Solana)조차 실측 최고 TPS가 65,000에 불과하다는 점을 알고 있으며, 이는 백만 단위 TPS 요구를 가진 텔레그램 생태계를 지원하기에 분명히 부족하다. 동시에 텔레그램의 대규모 활용으로 발생하는 데이터 양은 이미 천문학적 수준을 넘어섰으며, 블록체인은 극도로 중복적인 분산 시스템이므로 네트워크 내 각 노드가 완전한 데이터의 복사본을 보관하도록 요구하는 것은 현실성이 없다.
따라서 위의 두 가지 문제를 해결하기 위해 TON은 주류 블록체인 프로토콜에 대해 다음 두 가지 측면에서 최적화를 수행한다:
-
‘무한 샤딩 패러다임(Infinite Sharding Paradigm)’을 도입하여 시스템을 설계함으로써 데이터 중복 문제를 해결하고 대용량 데이터를 처리할 수 있을 뿐 아니라 성능 병목 현상도 완화한다.
-
액터 모델(Actor Model) 기반의 완전 병렬 실행 환경을 도입하여 네트워크 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은 체인 간 메시지 통신 라우팅 발견을 위해所谓 ‘초입방체 라우팅 알고리즘(Hypercube Routing Algorithm)’을 선택했다.所谓 초입방체 구조란 특수한 네트워크 토폴로지 구조로서, n차원 초입방체는 2^n개의 꼭짓점으로 구성되며, 각 꼭짓점은 n비트 이진수로 유일하게 식별할 수 있다. 이 구조에서 임의의 두 꼭짓점이 이진 표현에서 한 자리만 다를 경우 인접하다고 한다. 예를 들어 3차원 초입방체에서 꼭짓점 000과 꼭짓점 001은 마지막 한 자리만 다르므로 인접하다. 위 예시는 2차원 초입방체에 해당한다.
초입방체 라우팅 프로토콜에서 메시지는 소스 워크체인에서 목적지 워크체인까지의 라우팅 과정을 소스와 목적지 워크체인 주소의 이진 표현을 비교함으로써 수행한다. 라우팅 알고리즘은 두 주소 사이의 최소 거리(즉, 이진 표현에서 다른 비트 수)를 찾아내고 인접한 워크체인을 통해 정보를 점진적으로 전달하여 최종적으로 목적지 워크체인에 도달한다. 이 방법은 데이터 패킷이 최단 경로를 따라 전송되도록 보장하여 네트워크 통신 효율을 높인다.
물론 이 과정을 단순화하기 위해 TON은 낙관적인 기술 방안도 제시한다. 사용자가 특정 라우팅 경로에 대한 유효한 증명(Merkle Trie Root 등)을 제공할 수 있으면, 노드는 사용자가 제출한 메시지의 신뢰성을 직접 인정할 수 있는데, 이를 즉시 초입방체 라우팅이라고 부른다.
따라서 TON의 주소는 다른 블록체인 프로토콜과 명백한 차이가 있음을 알 수 있다. 다른 주류 블록체인 프로토콜은 대부분 타원 곡선 암호화 알고리즘으로 생성된 공개키-비밀키 쌍 중 공개키의 해시값을 주소로 사용한다. 주소는 단순히 고유성 구분만 하면 되기 때문에 라우팅 주소 지정 기능을 담당할 필요가 없다. 반면 TON의 주소는 두 부분으로 구성되는데, (workchain_id, account_id)이며 workchain_id는 초입방체 라우팅 알고리즘 주소 방식으로 인코딩된다. 여기서는 자세한 설명을 생략하겠다.
또한 혼란스러울 수 있는 점은 메인체인과 각 워크체인 간 연결 관계가 존재한다는 점이다. 그렇다면 모든 체인 간 정보를 메인체인을 통해 릴레이하면 되지 않을까? 코스모스(Cosmos)처럼 말이다. 그러나 TON의 설계 철학에 따르면 메인체인은 가장 중요한 작업—다수의 워크체인 최종성 유지—만을 처리하는 데 사용된다. 메인체인을 통해 메시지를 라우팅하는 것도 가능하지만, 그로 인해 발생하는 수수료가 매우 비쌀 것이다.
마지막으로 간단히 합의 알고리즘에 대해 언급하자면, TON은 BFT+PoS 방식을 채택한다. 즉 모든 스테이커(staker)는 블록 생성 기회를 가질 수 있으며, TON의 선거 거버넌스 계약은 일정 시간 간격으로 모든 스테이커 중에서 무작위로 블록 생성 검증자 클러스터를 선택한다. 검증자로 선정된 노드는 BFT 알고리즘을 통해 블록을 생성하며, 잘못된 정보를 생성하거나 악의적인 행위를 할 경우 스테이킹한 토큰이 몰수되며, 반대로는 블록 생성 보상을 받는다. 이는 이미 비교적 일반적인 선택이 되었으므로 여기서는 추가 설명을 생략하겠다.
액터 모델 기반 스마트 계약과 완전 병렬 실행 환경
TON의 또 다른 주류 블록체인 프로토콜과의 차이점은 스마트 계약 실행 환경이다. 주류 블록체인 프로토콜의 TPS 한계를 돌파하기 위해 TON은 하향식 설계 접근법을 채택하여 액터 모델을 통해 스마트 계약과 그 실행 방식을 재구성함으로써 완전한 병렬 실행 능력을 갖추었다.
주류 블록체인 프로토콜 대부분은 단일 스레드의 직렬 실행 환경을 채택하고 있다는 것을 알고 있다. 예를 들어 이더리움(Ethereum)의 실행 환경인 EVM은 거래를 입력으로 하는 상태 머신이며, 블록 생성 노드가 블록을 패키징하여 거래 순서를 결정한 후 그 순서에 따라 EVM을 통해 거래를 실행한다. 이 전체 과정은 완전히 직렬화되고 단일 스레드로 이루어지며, 특정 순간에는 하나의 거래만 실행될 수 있다. 이렇게 하는 장점은 거래 순서가 확정되면 광범위한 분산 클러스터 내에서도 실행 결과의 일관성이 보장된다는 점이다. 동시에 하나의 거래만 직렬로 실행되기 때문에 실행 중 다른 거래가 특정 상태 데이터를 수정할 수 없으므로 스마트 계약 간 상호 운용성이 실현된다. 예를 들어 유니스왑(Uniswap)을 통해 USDT로 ETH를 구매할 때 해당 거래가 실행되는 순간 LP 풀의 분포 상태는 확정된 값이 되며, 이를 통해 특정 수학 모델로 결과를 도출할 수 있다. 그러나 만약 그렇지 않다고 가정하자. bonding curve 계산을 수행하는 중 다른 LP가 유동성을 추가한다면 계산 결과는 오래된 정보가 되어 받아들일 수 없는 결과가 될 것이다.
그러나 이러한 아키텍처에는 명백한 한계가 있는데, 바로 TPS 병목 현상이다. 이 병목 현상은 현재 멀티코어 프로세서 환경에서 매우 낡아 보인다. 최신 PC로 레드얼럿(Red Alert) 같은 오래된 컴퓨터 게임을 플레이할 때 병력 수가 일정 수준 이상이 되면 여전히 느려지는 현상을 경험하는 것과 같다. 이는 소프트웨어 아키텍처의 문제다.
어떤 프로토콜이 이미 이 문제에 주목하여 자체 병렬 방안을 제시했다는 말을 들었을 수도 있다. 현재 TPS가 가장 높다고 알려진 솔라나(Solana)도 병렬 실행 기능을 갖추고 있다. 다만 그 설계 사고방식이 TON과 다르다. 솔라나의 핵심 아이디어는 모든 거래를 실행 의존성 관계에 따라 여러 그룹으로 나누는 것으로, 서로 다른 그룹은 상태 데이터를 공유하지 않는다. 즉 동일한 의존성이 없기 때문에 서로 다른 그룹의 거래는 충돌 없이 병렬로 실행될 수 있으며, 동일 그룹 내 거래는 여전히 기존의 직렬 방식으로 실행된다.
반면 TON은 직렬 실행 아키텍처를 완전히 포기하고, 병렬 처리를 위해 특별히 설계된 개발 패러다임인 액터 모델을 통해 실행 환경을 재구성한다.所谓 액터 모델은 1973년 칼 휴윗(Carl Hewitt)이 처음 제안한 것으로, 기존 동시성 프로그램에서 공유 상태의 복잡성을 메시지 전달을 통해 해결하려는 목적을 가진다. 각 액터는 자신의 비공유 상태와 행동을 가지며, 다른 액터와는 어떠한 상태 정보도 공유하지 않는다. 액터 모델은 메시지 전달을 통해 병렬 계산을 실현하는 동시성 계산 모델이다. 이 모델에서 '액터'는 기본 작업 단위로서 수신한 메시지를 처리하고, 새로운 액터를 생성하며, 더 많은 메시지를 전송하고, 다음 메시지에 어떻게 응답할지 결정할 수 있다. 액터 모델은 다음의 특성을 가져야 한다:
-
캡슐화 및 독립성: 각 액터는 메시지를 처리할 때 완전히 독립적이며, 서로 간섭 없이 메시지를 병렬로 처리할 수 있다.
-
메시지 전달: 액터 간 상호작용은 메시지 전송 및 수신을 통해서만 이루어지며, 메시지 전달은 비동기적이다.
-
동적 구조: 액터는 런타임 중에 더 많은 액터를 생성할 수 있으며, 이러한 동적 특성 덕분에 액터 모델은 필요에 따라 시스템을 확장할 수 있다.
TON은 이 아키텍처를 채택하여 스마트 계약 모델을 설계했다. 즉 TON에서 각 스마트 계약은 액터 모델이며, 완전히 독립적인 저장 공간을 가진다. 외부 데이터에 의존하지 않기 때문이다. 또한 동일한 스마트 계약에 대한 호출은 수신 큐의 메시지 순서에 따라 실행되므로 TON의 거래는 충돌 문제 없이 효율적으로 병렬 실행될 수 있다.
그러나 이러한 설계 방식은 개발자들에게 새로운 영향을 미친다. DApp 개발자의 익숙한 개발 패러다임이 깨지게 되는 것이다. 구체적으로 다음과 같다:
1. 스마트 계약 간 비동기 호출: TON의 스마트 계약 내부에서는 외부 계약을 원자적으로 호출하거나 외부 계약 데이터에 접근할 수 없다. 솔리디티(Solidity)에서 계약 A의 function1이 계약 B의 function2를 호출하거나 계약 C의 읽기 전용 function3을 통해 특정 상태 데이터를 조회하는 것은 전체 과정이 원자적이며 하나의 거래 안에서 실행되는 것이 매우 쉬운 일이다. 그러나 TON에서는 이것이 불가능하며, 외부 스마트 계약과의 모든 상호작용은 새로운 거래를 패키징하여 비동기적으로 실행되어야 하며, 이러한 스마트 계약이 발행한 거래를 내부 메시지(internal message)라고 부른다. 또한 실행 중 결과를 얻기 위해 블로킹(blocking)할 수 없다.
예를 들어 DEX를 개발한다고 가정하자. EVM에서 흔히 사용되는 패턴을 따른다면 일반적으로 거래 라우팅을 관리하는 통합 라우터 계약이 있으며, 각 풀(Pool)은 특정 거래쌍 관련 LP 데이터를 별도로 관리한다. 현재 USDT-DAI와 DAI-ETH 두 개의 풀이 있다고 가정하자. 사용자가 USDT로 직접 ETH를 구매하고자 한다면, 라우터 계약을 통해 한 번의 거래 안에서 두 풀에 순차적으로 요청하여 원자적 거래를 완료할 수 있다. 그러나 TON에서는 그렇게 쉽게 구현되지 않으며, 새로운 개발 패러다임을 고민해야 한다. 만약 여전히 기존 패턴을 재사용한다면 정보 흐름은 다음과 같을 수 있다. 이 요청은 사용자가 발행한 external message와 세 개의 internal message를 통해 완료될 것이다(이것은 차이점을 설명하기 위한 것이며, 실제 개발에서는 ERC20 패턴조차 다시 설계해야 한다는 점에 유의하라).
2. 크로스 계약 호출 시 실행 오류 처리 절차를 신중히 고려하고, 각 계약 호출마다 대응하는 반송(bounce) 함수를 설계해야 한다. 주류 EVM에서 거래 실행 중 문제가 발생하면 전체 거래가 롤백되어 초기 상태로 되돌아간다는 것을 알고 있다. 이것은 직렬 단일 스레드 모델에서 이해하기 쉽다. 그러나 TON에서는 계약 간 호출이 비동기 방식으로 실행되기 때문에 후속 단계에서 오류가 발생하더라도 이미 성공적으로 실행된 거래는 이미 실행 및 확인되었기 때문에 문제가 발생할 수 있다. 따라서 TON은 '반송 메시지(bounce message)'라는 특수한 메시지 유형을 설정한다. 즉 어떤 내부 메시지가 트리거한 후속 실행 과정에서 오류가 발생하면, 트리거된 계약은 트리거 계약에 예약된 반송 함수를 통해 트리거 계약의 일부 상태를 초기화할 수 있다.
3. 복잡한 경우 먼저 수신된 거래가 반드시 먼저 실행 완료되는 것은 아니므로 이러한 시퀀스 관계를 가정해서는 안 된다. 이런 비동기 및 병렬 스마트 계약 호출 시스템에서 작업 순서를 정의하는 것은 어렵다. 이것이 바로 TON에서 각 메시지에 Lamport time(이하 lt)이라는 논리적 시간이 부여되는 이유이다. 이는 어떤 사건이 다른 사건을 유발했는지 이해하고 검증자가 무엇을 먼저 처리해야 하는지를 판단하는 데 사용된다. 간단한 모델에서는 먼저 수신된 거래가 반드시 먼저 실행 완료된다.
이 모델에서 A와 B는 각각 두 개의 스마트 계약을 나타내며, msg1_lt < msg2_lt이면 tx1_lt < tx2_lt의 시퀀스 관계가 성립한다.
그러나 더 복잡한 상황에서는 이 규칙이 깨질 수 있다. 공식 문서에는 다음과 같은 예가 있다. 세 개의 계약 A, B, C가 있다고 가정하자. 한 거래에서 A는 B에게 msg1, C에게 msg2라는 두 개의 내부 메시지를 보낸다. 정확한 순서로 생성되었음에도 불구하고(msg1 먼저, 그 다음 msg2), msg1이 msg2보다 먼저 처리된다는 보장은 없다. A에서 B로, A에서 C로의 라우팅 경로 길이나 검증자 집합이 다를 수 있기 때문이다. 만약 이 계약들이 서로 다른 샤드 체인에 위치한다면, 한 메시지는 목표 계약에 도달하는 데 여러 블록이 걸릴 수 있다. 즉 두 가지 가능한 거래 경로가 존재한다.
4. TON에서 스마트 계약의 영속 저장소는 Cell 단위의 방향성 비순환 그래프(DAG)를 데이터 구조로 사용한다. 데이터는 인코딩 규칙에 따라 컴팩트하게 압축되어 하나의 Cell로 저장되며, 방향성 비순환 그래프 방식으로 아래로 확장된다. 이는 EVM에서 상태 데이터가 해시맵 기반으로 조직되는 구조와 다르다. 데이터 요청 알고리즘이 다르기 때문에 TON은 깊이가 다른 데이터 처리에 대해 서로 다른 가스 가격을 설정한다. 더 깊은 Cell일수록 처리에 더 많은 가스가 필요하다. 따라서 TON에서는 악의적인 사용자가 많은 쓰레기 메시지를 보내 특정 스마트 계약의 모든 얕은 Cell을 점유함으로써 정직한 사용자의 저장 비용이 점점 더 높아지는 DoS 공격 패턴이 존재한다. 반면 EVM에서는 해시맵 조회 복잡도가 O(1)이므로 동일한 가스를 사용하며, 이런 문제는 없다. 따라서 TON DApp 개발자는 스마트 계약 내 무제한 데이터 유형(unbounded data type)의 출현을 피해야 한다. 무제한 데이터 유형이 발생하면 샤딩 방식으로 분산시켜야 한다.
5. 그 외에도 특별하지 않은 특징들이 있다. 예를 들어 스마트 계약은 저장 공간에 대해 임대료를 지불해야 하며, TON에서 스마트 계약은 본질적으로 업그레이드 가능하고, 원시 추상 계정 기능을 내장하고 있다. 즉 TON에서 모든 지갑 주소는 스마트 계약이며, 단지 초기화되지 않았을 뿐이다. 이러한 점들을 개발자들은 주의 깊게 살펴야 한다.
지금까지 TON 관련 기술을 공부하면서 느낀 점들을 공유하였다. 틀린 점이 있으면 지적해주기 바라며, 동시에 텔레그램의 막대한 트래픽 자원을 바탕으로 TON 생태계가 Web3에 새로운 애플리케이션을 가져올 것이라 믿는다. TON DApp 개발에 관심 있는 분은 연락 주시기 바라며 함께 토의할 수 있기를 바란다.
@web3_mario
