메시지 개요
TON은 다른 블록체인과 매우 다른 복잡한 구조를 가진 비동기식 블록체인입니다. 이 때문에 신규 개발자들은 종종 TON의 낮은 레벨에 대해 궁금해합니다. 이 글에서는 메시지 전송과 관련된 질문 중 하나를 살펴보겠습니다.
메시지란 무엇인가요?
메시지는 행위자(사용자, 애플리케이션, 스마트 컨트랙트) 간에 전송되는 데이터 패킷입니다. 일반적으로 저장소 업데이트 또는 새 메시지 전송과 같이 수신자에게 수행할 작업을 지시하는 정보를 포함합니다.
이러한 유형의 커뮤니케이션 작업은 위성을 우주로 발사하는 것을 연상시킵니다. 우리는 우리가 만든 메시지를 알고 있지만 발사 후에는 어떤 결과를 얻을 수 있는지 알아보기 위해 별도의 관측을 수행해야 합니다.
트랜잭션이란 무엇인가요?
TON의 트랜잭션은 다음과 같이 구성됩니다:
- 컨트랙트를 처음 트리거하는 수신 메시지(트리거하는 특별한 방법이 존재함)
- 컨트랙트 저장소 업데이트와 같은 수신 메시지로 인한 컨트랙트 작업(선택 사항)
- 다른 액터에게 전송되는 발신 생성 메시지(선택 사항)
기술적으로는 Tick-Tock과 같은 특수 기능을 통해 컨트랙트를 트리거할 수 있지만, 이 기능은 TON 블록체인 내부의 핵심 컨트랙트에 더 많이 사용됩니다.
모든 트랜잭션이 나가는 메시지나 컨트랙트의 저장소로 업데이트되는 것은 아니며, 이는 컨트랙트의 코드에 정의된 작업에 따라 달라집니다.
이더리움이나 다른 거의 모든 동기식 블록체인을 살펴보면, 각 트랜잭션에는 여러 스마트 콘트랙트 호출이 포함될 수 있습니다. 예를 들어, 탈중앙 거래소는 선택한 거래 쌍에 유동성이 없는 경우 하나의 트랜잭션에서 여러 번의 교환을 수행합니다.
비동기 시스템에서는 동일한 트랜잭션에서 대상 스마트 콘트랙트로부터 응답을 받을 수 없습니다. 컨트랙트 호출은 소스와 목적지 사이의 경로 길이에 따라 처리하는 데 몇 블록이 걸릴 수 있습니다.
무한 샤딩 패러다임을 달성하기 위해서는 완전한 병렬화를 보장해야 하는데, 이는 각 트랜잭션의 실행이 서로 독립적이라는 것을 의미합니다. 따라서 한 번에 많은 트랜잭션의 상태에 영향을 미치고 변경하는 트랜잭션 대신 TON의 각 트랜잭션은 하나의 스마트 컨트랙트에서만 실행되고 스마트 컨트랙트는 메시지를 통해 통신합니다. 따라서 스마트 컨트랙트는 특수 메시지로 함수를 호출하고 나중에 다른 메시지를 통해 응답을 받는 방식으로만 서로 상호작용할 수 있습니다.
트랜잭션 레이아웃](/개발/데이터 형식/트랜잭션 레이아웃) 페이지에서 더 자세하고 정확한 설명을 확인할 수 있습니다.
논리적 시간이란 무엇인가요?
비동기식 병렬 스마트 컨트랙트 호출이 있는 시스템에서는 처리할 작업의 순서를 정의하기 어려울 수 있습니다. 그렇기 때문에 TON의 각 메시지에는 논리적 시간 또는 램포트 시간(이후에는 lt로만 표기)이 있습니다. 이는 어떤 이벤트가 다른 이벤트를 발생시켰는지, 유효성 검사기가 먼저 처리해야 하는 것이 무엇인지 이해하는 데 사용됩니다.
메시지로 인해 발생하는 트랜잭션의 lt가 메시지의 lt보다 크다는 것은 엄격하게 보장됩니다. 마찬가지로, 어떤 트랜잭션에서 전송된 메시지의 lt는 그 원인이 된 트랜잭션의 lt보다 엄격하게 더 큽니다. 이뿐만 아니라 한 계정에서 보낸 메시지와 한 계정에서 발생한 트랜잭션도 엄격하게 순서가 정해집니다.
이미지의 경우는 다음과 같습니다: IN_MSG_LT < TX0_LT < OUT_MSG_LT입니다.
덕분에 모든 계정에 대해 거래, 메시지 수신, 메시지 발신 순서를 항상 파악할 수 있습니다.
또한 A 계정이 B 계정으로 두 개의 메시지를 보낸 경우 lt가 낮은 메시지가 먼저 처리될 수 있도록 보장됩니다:
만약 msg1_lt < msg2_lt => tx1_lt < tx2_lt.
그렇지 않으면 전송 동기화를 시도하려면 하나의 샤드를 처리하기 전에 다른 모든 샤드의 상태를 알아야 하므로 병렬화가 깨지고 효율적인 샤딩이 파괴됩니다.
각 블록에 대해 첫 번째 트랜잭션에서 시작하여 블록의 마지막 이벤트(메시지 또는 트랜잭션)의 lt로 끝나는 것으로 lt 범위를 정의할 수 있습니다. 블록은 TON의 다른 이벤트와 동일한 방식으로 정렬되므로 한 블록이 다른 블록에 의존하는 경우, 그 블록의 lt가 더 높습니다. 샤드의 자식 블록은 부모 블록보다 lt가 더 높습니다. 마스터 블록은 나열된 샤드 블록에 의존하기 때문에 마스터 체인 블록의 lt는 나열된 샤드 블록의 lts보다 높습니다. 각 샤드 블록은 최신(샤드 블록 생성 시점의) 마스터 블록에 대한 순서대로 참조를 포함하므로 샤드 블록 lt는 참조된 마스터 블록 lt보다 높습니다.
메시지 전달
다행히 TON은 모든 내부 메시지를 대상 계정에서 확실히 수신할 수 있는 방식으로 작동합니다. 메시지는 발신자와 수신자 사이 어디에서도 손실될 수 없습니다. 외부 메시지는 블록에 대한 수락 여부가 검증자의 재량에 달려 있기 때문에 조금 다르지만, 일단 메시지가 수신 메시지 대기열에 수락되면 전달됩니다.
배송 주문
따라서 lt가 낮은 트랜잭션이 먼저 처리된다는 것을 알기 때문에 lt가 메시지 전달 순서에 대한 문제를 해결하는 것처럼 보입니다. 하지만 모든 시나리오에서 이 방법이 통하는 것은 아닙니다.
A와 _B라는 두 개의 컨트랙트가 있다고 가정해봅시다. A가 외부 메시지를 수신하여 _B로 두 개의 내부 메시지를 보내도록 트리거하는 경우, 이 메시지를 1과 2라고 부르겠습니다. 이 간단한 경우, 1이 2보다 lt가 낮기 때문에 1이 B보다 먼저 처리될 것이라는 것을 100% 확신할 수 있습니다.
하지만 이것은 계약이 두 개뿐인 간단한 경우입니다. 더 복잡한 경우에는 시스템이 어떻게 작동할까요?
여러 스마트 컨트랙트
A, _B, C라는 세 개의 컨트랙트가 있다고 가정해봅시다. 트랜잭션에서 _A는 두 개의 내부 메시지 1과 2를 보내는데, 하나는 B에게, 다른 하나는 C에게 보냅니다. 정확한 순서(_1, 2)로 생성되었지만 1이 2보다 먼저 처리될지는 확신할 수 없습니다. 이는 A에서 B로, A에서 _C로 가는 경로의 길이와 검증자 세트가 다를 수 있기 때문입니다. 이러한 컨트랙트가 서로 다른 샤드 체인에 있는 경우, 메시지 중 하나가 대상 컨트랙트에 도달하기 위해 여러 블록이 필요할 수 있습니다.
더 명확하게 이해하기 위해 B와 C 컨트랙트가 msg1과 msg2를 실행한 후 msg1'과 msg2메시지를 다시 보낸다고 가정해 보겠습니다. 결과적으로 컨트랙트A에 tx2'와 `tx1'이 적용될 것입니다.
이 트랜잭션에 대해 두 가지 가능한 추적이 있습니다,
- 첫 번째 가능한 순서는
tx1'_lt < tx2'_lt입니다:
- 두 번째 가능한 순서는
tx2'_lt < tx1'_lt입니다:
두 개의 컨트랙트 B와 _C가 하나의 컨트랙트 A에 메시지를 보내는 반대의 경우에도 같은 일이 발생합니다. B -> A메시지가C -> A보다 먼저 전송되었더라도 어느 쪽이 먼저 전달될지는 알 수 없습니다. B -> A 경로에는 더 많은 샤드 체인 홉이 필요할 수 있습니다.
스마트 콘트랙트 상호작용에는 다양한 시나리오가 있을 수 있으며, 2개 이상의 콘트랙트가 있는 모든 시나리오에서 메시지 전달 순서는 임의적일 수 있습니다. 유일한 보장은 모든 컨트랙트 A에서 컨트랙트 B로 보내는 메시지가 논리적 시간 순서대로 처리된다는 것입니다. 몇 가지 예는 아래와 같습니다.
결론
TON 블록체인의 비동기식 구조는 메시지 전송 보장에 문제를 야기합니다. 논리적 시간은 이벤트 및 트랜잭션 순서를 설정하는 데 도움이 되지만, 샤드 체인의 다양한 경로로 인해 여러 스마트 컨트랙트 간의 메시지 전달 순서를 보장하지는 못합니다. 이러한 복잡성에도 불구하고 TON은 내부 메시지 전달을 보장하여 네트워크 안정성을 유지합니다. 개발자는 혁신적인 탈중앙화 애플리케이션을 구축할 때 TON의 잠재력을 최대한 활용하기 위해 이러한 뉘앙스에 적응해야 합니다.