메시지와 트랜잭션

TON은 다른 블록체인과 매우 다른 복잡한 구조를 가진 비동기 블록체인입니다. 이러한 이유로 새로운 개발자들은 종종 TON의 저수준 요소들에 대해 궁금해합니다. 이 글에서는 메시지 전달과 관련된 이러한 요소들 중 하나를 살펴보겠습니다.

메시지란 무엇인가?

메시지는 행위자들(사용자, 애플리케이션, 스마트 컨트랙트) 간에 전송되는 데이터 패킷입니다. 일반적으로 저장소 업데이트나 새 메시지 전송과 같은 수행할 작업에 대한 수신자 지침 정보를 포함합니다.

이러한 유형의 통신 작업은 우주로 위성을 발사하는 것과 비슷합니다. 우리가 형성한 메시지는 알고 있지만, 발사 후에는 어떤 결과를 얻을지 알아내기 위해 별도의 관찰이 필요합니다.

트랜잭션이란 무엇인가?

TON의 트랜잭션은 다음으로 구성됩니다:

• 처음에 컨트랙트를 트리거하는 수신 메시지(특별한 트리거 방법이 존재)
• 컨트랙트의 저장소 업데이트와 같은 수신 메시지로 인한 컨트랙트 작업(선택사항)
• 다른 행위자에게 전송되는 발신 생성 메시지(선택사항)

기술적으로 컨트랙트는 Tick-Tock과 같은 특수 함수를 통해 트리거될 수 있지만, 이 함수는 내부 TON 블록체인 코어 컨트랙트에서 더 많이 사용됩니다.

모든 트랜잭션이 발신 메시지나 컨트랙트의 저장소 업데이트를 초래하는 것은 아닙니다 - 이는 컨트랙트 코드에 정의된 작업에 따라 다릅니다.

Ethereum이나 다른 대부분의 동기식 블록체인을 보면, 각 트랜잭션에 여러 개의 스마트 컨트랙트 호출이 포함될 수 있습니다. 예를 들어, DEX는 선택한 거래 쌍에 유동성이 없는 경우 하나의 트랜잭션에서 여러 번의 교환을 수행합니다.

비동기 시스템에서는 같은 트랜잭션에서 대상 스마트 컨트랙트로부터 응답을 받을 수 없습니다. 소스와 대상 사이의 경로 길이에 따라 컨트랙트 호출이 처리되는 데 몇 개의 블록이 걸릴 수 있습니다.

무한 샤딩 패러다임을 달성하기 위해서는 완전한 병렬화를 보장해야 합니다. 이는 각 트랜잭션의 실행이 다른 모든 트랜잭션으로부터 독립적이라는 것을 의미합니다. 따라서 한 번에 많은 컨트랙트의 상태에 영향을 주고 변경하는 트랜잭션 대신, TON의 각 트랜잭션은 단일 스마트 컨트랙트에서만 실행되며 스마트 컨트랙트는 메시지를 통해 통신합니다. 이렇게 하면 스마트 컨트랙트는 특별한 메시지로 함수를 호출하고 나중에 다른 메시지를 통해 응답을 받는 방식으로만 상호작용할 수 있습니다.

정보

트랜잭션 레이아웃 페이지에서 더 자세하고 정확한 설명을 확인할 수 있습니다.

트랜잭션 결과

계산 단계가 있는 트랜잭션에는 TVM 종료 코드가 있으며, 0 또는 1이 아닌 경우 오류가 있었다는 것을 의미합니다. 또한, 자금이나 상태가 없는 등의 이유로 TVM 계산 단계가 건너뛰어질 수 있습니다.

toncenter api v3용

성공적인 트랜잭션을 결정하려면 tx.description.action.success && tx.description.compute_ph.success를 사용해야 합니다:

"transactions": [
    {
      "description": {
        . . . . . . . .
        "action": {
          "valid": true,
          "success": true,
         . . . . . . . .
          },
. . . . . . . .
        "destroyed": false,
        "compute_ph": {
          "mode": 0,
          "type": "vm",
          "success": true,

트랜잭션은 세 가지 결과 중 하나를 가질 수 있습니다:

• 성공, 종료 코드 0 또는 1
• 실패, 실행 없이 aborted: true
• 실패, 종료 코드, aborted: true

toncenter api v3용

aborted: true는 toncenter 필드이며, 트랜잭션에는 이러한 필드가 없습니다

논리적 시간이란 무엇인가?

비동기 및 병렬 스마트 컨트랙트 호출이 있는 이러한 시스템에서는 처리할 작업의 순서를 정의하기가 어려울 수 있습니다. 그래서 TON의 각 메시지에는 논리적 시간 또는 Lamport 시간(이하 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_는 나열된 샤드 블록의 _lt_보다 높습니다. 마스터 블록이 나열된 샤드 블록에 의존하기 때문입니다. 각 샤드 블록은 최신(샤드 블록 생성 시점)의 마스터 블록에 대한 정렬된 참조를 포함하므로 샤드 블록 _lt_는 참조된 마스터 블록 _lt_보다 높습니다.

메시지 전달

다행히도 TON은 모든 내부 메시지가 반드시 대상 계정에 의해 수신되는 방식으로 작동합니다. 메시지는 소스와 목적지 사이 어디에서도 손실될 수 없습니다. 외부 메시지는 블록에 대한 수락이 검증자의 재량에 달려 있기 때문에 약간 다르지만, 일단 메시지가 수신 메시지 대기열에 수락되면 전달됩니다.

전달 순서

따라서 _lt_가 메시지 전달 순서에 대한 문제를 해결하는 것처럼 보입니다. _lt_가 낮은 트랜잭션이 먼저 처리될 것이라는 것을 알기 때문입니다. 하지만 이는 모든 시나리오에서 작동하지는 않습니다.

두 개의 컨트랙트 _A_와 _B_가 있다고 가정해봅시다. _A_는 _B_에 두 개의 내부 메시지를 보내도록 트리거하는 외부 메시지를 받습니다. 이 메시지들을 _1_과 _2_라고 합시다. 이 간단한 경우에, _1_이 _2_보다 낮은 _lt_를 가지기 때문에 _1_이 _2_보다 먼저 _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'가 적용될 것입니다. 이러한 트랜잭션에 대해 두 가지 가능한 순서가 있습니다.

1. 첫 번째 가능한 순서는 tx1'_lt < tx2'_lt:

2. 두 번째 가능한 순서는 tx2'_lt < tx1'_lt:

역방향의 경우에도 같은 일이 발생합니다. 두 컨트랙트 _B_와 _C_가 하나의 컨트랙트 _A_로 메시지를 보내는 경우입니다. B -> A 메시지가 C -> A 메시지보다 먼저 보내졌더라도, 어느 것이 먼저 전달될지 알 수 없습니다. B -> A 경로가 더 많은 샤드 체인 홉을 필요로 할 수 있습니다.

스마트 컨트랙트 상호작용에는 많은 가능한 시나리오가 있을 수 있으며, 2개 이상의 컨트랙트가 있는 모든 시나리오에서 메시지 전달 순서는 임의적일 수 있습니다. 유일한 보장은 어떤 컨트랙트 _A_에서 어떤 컨트랙트 _B_로의 메시지가 논리적 시간 순서대로 처리된다는 것입니다. 아래에 몇 가지 예시가 있습니다.

결론

TON 블록체인의 비동기 구조는 메시지 전달 보장에 대한 과제를 만듭니다. 논리적 시간은 이벤트와 트랜잭션 순서를 설정하는 데 도움을 주지만, 샤드 체인의 다양한 경로로 인해 여러 스마트 컨트랙트 간의 메시지 전달 순서를 보장하지는 않습니다. 이러한 복잡성에도 불구하고, TON은 내부 메시지 전달을 보장하여 네트워크 신뢰성을 유지합니다. 개발자들은 혁신적인 분산 애플리케이션을 구축하는 데 TON의 전체 잠재력을 활용하기 위해 이러한 특성에 적응해야 합니다.