Description
TON 스마트 계약을 샤딩하는 방법과 그 이유 - TON의 Jettons 분석 연구
탈 콜
TON의 궁극적인 임무는 블록체인을 대량 채택하는 것입니다. 지금까지 세계에서 얼마나 많은 사람들이 실제로 블록체인을 사용했습니까? 이더리움의 통계는 수백만 명을 언급하므로 지금까지 블록체인에 대한 5천만 명의 글로벌 사용자라는 수치를 취하는 것은 아마도 관대할 것입니다. 이 숫자를 어떻게 10억으로 늘릴 수 있습니까?
현재 버전의 이더리움은 최대 용량에서 하루에 약 100만 건의 트랜잭션을 처리합니다. 2016년에 우리가 목표로 하는 수치에 근접한 대량 채택을 기록한 메시징 앱인 Telegram은 하루에 150억 개의 메시지 를 전달했습니다 . 이 엄청난 양의 데이터는 TON 블록체인의 설계에 채택된 아키텍처 설계 선택으로 이어졌습니다. 시스템 x10000의 확장성 증가는 일반적으로 단순한 프로토콜 개선으로 달성되지 않으며, 이 위업에는 접근 방식의 급격한 변화가 필요합니다.
샤딩의 개념
샤딩은 데이터베이스 설계 에서 비롯된 성숙한 개념입니다 . 여기에는 아무 것도 공유하지 않고 여러 서버에 배포할 수 있는 여러 데이터베이스에 하나의 논리적 데이터 세트를 분할 및 배포하는 작업이 포함됩니다. 간단히 말해서, 샤딩은 수평적 확장성을 허용합니다 . 데이터를 병렬로 처리할 수 있는 고유하고 독립적인 조각으로 분할합니다. 이것은 데이터에서 빅 데이터 로 전 세계를 전환하는 핵심 개념입니다 . 데이터 세트가 기존 방식으로 처리하기에 너무 커지면 데이터 세트를 더 작은 조각으로 나누는 것 외에는 확장할 수 있는 다른 방법이 없습니다.
샤딩을 블록체인에 적용한 것은 TON이 처음이 아니다. Ethereum 2.0은 고정된 수의 64개 샤드를 지원합니다 . TON의 접근 방식은 샤드 수가 더 많아서가 아니라 두 가지 고유한 개념적 변화 때문에 급진적입니다.
샤드의 수는 고정되어 있지 않습니다. TON은 2^60(워크체인당)의 상한선으로 필요에 따라 점점 더 많은 샤드를 추가하도록 지원합니다. 이 숫자는 사실상 무한하며, 전 세계 모든 사람에게 1억 개의 샤드가 할당되고 여전히 여유가 있습니다.
샤드의 수는 탄력적입니다. TON은 로드가 높을 때 샤드체인을 두 개로 자동 분할하고 로드가 낮을 때 다시 병합하는 것을 지원합니다. 사전 예측이 불가능한 동적 확장 요구 사항을 처리하는 유일한 방법입니다.
TON 백서 에서 이러한 참신한 아이디어에 대해 자세히 알아볼 수 있습니다 .
근본적인 방식으로 세상을 바꾸려는 노력은 대가 없이 이루어지는 경우가 거의 없습니다. 이 급진적인 접근 방식을 사용하려면 TON 스마트 계약 개발자는 계약을 다르게 설계해야 합니다. 예를 들어 Solidity에서 이전 스마트 계약 경험이 있는 경우 TON의 아키텍처는 이질적으로 느껴질 것입니다. 이전 게시물인 Solidity 개발자를 놀라게 할 TON 블록체인의 6가지 고유한 측면을 읽어 전환을 용이하게 하는 것이 좋습니다.
샤딩 TON 스마트 계약
TON 블록체인의 기본 원자 단위는 스마트 계약 인스턴스입니다. 스마트 계약 인스턴스에는 주소, 코드 및 데이터 셀(영구 상태)이 있습니다. 스마트 계약은 항상 모든 영구 상태에 대한 원자적 동기 액세스를 갖기 때문에 이 단위를 원자적이 라고 합니다 .
TON의 스마트 계약 인스턴스 간의 통신은 원자적이거나 동기적이지 않습니다. 마이크로 서비스 와 같은 TON의 스마트 계약을 생각하십시오 . 각 마이크로 서비스에는 로컬 데이터에 대한 원자적 동기 액세스만 있습니다. 두 마이크로 서비스 간의 통신에는 네트워크를 통한 비동기 메시지 전송이 포함됩니다.
모든 시스템 설계자가 알고 있듯이 더 큰 시스템에는 모놀리식 아키텍처 에서 마이크로서비스로의 전환이 필요합니다 . 이 분산 방식을 채택하려면 약간의 노력이 필요하지만 몇 가지 바람직한 이점을 얻을 수 있습니다. 최신 시스템 패러다임은 Kubernetes 와 같은 오케스트레이터 를 사용하여 컨테이너화된 마이크로서비스 그룹을 가져와 필요에 따라 자동으로 새 인스턴스를 시작하고(자동 크기 조정) 시스템 간에 효율적으로 분할합니다.
Kubernetes 비유가 마음에 듭니다. 이것이 정확히 TON이 하는 일이기 때문입니다. 특정 샤드체인의 부하가 증가하면 둘로 나뉩니다. 스마트 계약 인스턴스는 원자성이기 때문에 반으로 깨지지 않습니다. 이는 한때 동일한 샤드체인에 존재했던 일부 스마트 계약 인스턴스가 언젠가는 다른 샤드체인에 상주할 수 있음을 의미합니다!
정리하면 TON의 가상머신(TVM)은 분산 마이크로서비스 개념을 이더리움 EVM의 모놀리스에 적용하고 있다.
샤딩을 위한 스마트 계약 설계
초보 시스템 설계자가 자주 묻는 질문은 "마이크로서비스가 얼마나 커야 합니까?"입니다. - 또는 다른 말로 "마이크로서비스가 너무 획일적이고 두 개로 분할되어야 하는 경우는 언제입니까?"
이 질문에 대한 답은 없습니다. 예술입니다. 아이디어는 Kubernetes가 작업을 수행하도록 지원하는 것입니다. 마이크로서비스가 작을수록 Kubernetes가 새 인스턴스를 생성하고 필요에 따라 이동하여 시스템을 최적화하기가 더 쉽습니다. 그러나 크기가 작을수록 더 많은 작업이 비동기화되므로 개발자가 복잡한 흐름을 구현하기가 더 어려워집니다.
동일한 추론이 TON 계약 샤딩에도 적용된다는 사실을 발견했습니다. 아이디어는 TON 자동 샤딩이 그 일을 하도록 하는 것입니다. 상태 데이터를 여러 스마트 계약 인스턴스로 분할하여 로드가 증가할 때 더 작은 조각으로 분해하고 다른 샤드체인으로 효율적으로 이동할 수 있도록 하는 것입니다. 하지만 너무 적극적으로 샤딩을 하면 비동기성 증가로 인해 너무 많은 복잡성을 처리해야 합니다.
실제 예 - TON의 Jetton 계약
이 게시물은 지금까지 매우 이론적이었습니다. 나는 실용성으로 급격하게 전환하고 싶습니다. 이 아키텍처를 이해하기 위해 실제 사례를 분석해 보겠습니다. 우리가 사용할 예제는 TON의 Jetton 스마트 계약입니다. Jetton은 대체 가능한 토큰을 구현하는 스마트 계약입니다(TON 코인 자체와 매우 유사함). 이것은 이더리움의 인기 있는 ERC20 토큰 표준 의 TON 버전입니다 .
토큰을 구현하는 것은 매우 간단합니다. 소유자가 일부 토큰 금액을 다른 소유자에게 전송할 수 있도록 하는 하나의 기본 작업인 전송이 필요합니다 . 우리는 또한 새로운 토큰을 순환에 추가하는 기능인 민트 조치와 순환에서 토큰을 제거하는 반대 소각이 필요합니다 . 영구 상태는 어떻습니까? 또한 모든 사용자의 잔액을 저장해야 합니다. 이더리움에서는 일반적으로 키가 사용자의 지갑 주소이고 값이 잔액인 맵이 필요합니다.
TON에서 이 스마트 계약의 설계자로서 우리는 자동 샤딩을 효과적으로 지원하기 위해 이 스마트 계약을 여러 개의 작은 인스턴스로 분할해야 하는지 여부와 방법을 결정해야 합니다. Jetton의 사용자가 10억 명이라면 어떻게 될까요? 이 경우 아키텍처가 유지됩니까?
Jetton을 여러 스마트 계약에 배포
Jetton에 대한 "올바른" 샤딩 양을 찾기 위해 위에서 설명한 추론을 적용해 보겠습니다. 나는 이것이 너무 이론적이라는 것을 알고 있습니다. 운 좋게도 꽤 잘 작동하는 매우 실용적인 테스트가 있습니다.
무제한 데이터 구조로 스마트 계약을 설계하는 경우 이 계약을 여러 인스턴스로 분할해야 할 가능성이 높습니다.
무제한 데이터 구조는 무한정 커질 수 있는 배열 또는 맵입니다. Ethereum에서 우리의 스마트 계약에는 모든 사용자 잔액을 보유하는 지도가 필요합니다. 이 지도는 우리 토큰 보유자의 수가 제한이 없기 때문에 무한정 커질 수 있습니다. 새로운 계정은 사실상 무기한으로 생성될 수 있으며 수치 정밀도가 매우 높기 때문에 모든 계정에 소량의 토큰을 전송할 수 있습니다.
실제 규칙을 적용해 봅시다. TON의 단일 스마트 계약에서 모든 잔액을 유지한다면 무한한 데이터 구조를 갖게 될 것입니다. 이것은 우리가 샤딩을 위한 훌륭한 후보가 있다는 것을 의미합니다!
어떻게 샤딩합니까? 이것은 매우 간단합니다. 모든 잔액이 단일 스마트 계약 인스턴스에 나열되는 것을 원하지 않는 경우 모든 잔액이 전용 스마트 계약 인스턴스에 보관되도록 목록을 분할하면 어떻게 될까요?
Jetton 아키텍처
Jetton 인스턴스가 Shiba-Inu 또는 SHIB줄여서 토큰용이라고 가정해 보겠습니다 . SHIB를 보유하고 있는 두 명의 사용자가 있습니다. Alison과 Becky입니다. 우리는 이미 각 사용자의 잔액이 자체 계약 인스턴스에 보관된다고 말했습니다. 즉, 인스턴스가 2개("하위") 있음을 의미합니다. SHIB("상위")에 대한 글로벌 공유 정보를 보유하기 위한 또 다른 인스턴스도 필요합니다.
이로 인해 다음 아키텍처가 나타납니다.
실천하겠다고 다짐했습니다. 실제 Jetton 코드 읽기를 시작하겠습니다! TON 핵심 팀은 여기에서 찾을 수 있는 Jetton 표준의 공식 구현을 가지고 있습니다 . 코드에 익숙해질 수 있도록 열어보세요.
코드에서 두 가지 주요 FunC 스마트 계약을 볼 수 있습니다.
jetton-minter.fc- 이름 및 기호와 같은 토큰에 대한 전역 공유 정보를 보유하는 부모입니다. 부모의 단일 인스턴스만 있습니다. 핵심 팀이 이름을 선택한 이유를 완전히 확신할 수 없습니다 jetton-minter. 이름을 선호했을 것입니다 jetton-parent. 이 컨트랙트가 민팅을 담당하고 있는 것은 사실이지만, 민팅이 비활성화되더라도 여전히 필요하기 때문에 다소 혼란스럽습니다.
jetton-wallet.fc- 단일 사용자의 토큰 잔액을 보유하는 자식입니다. 이 계약에는 각 사용자 주소에 대해 하나씩 여러 인스턴스가 있습니다. 핵심 팀이 이 jetton-wallet계약의 이름을 선택했습니다. 저는 이 이름을 선호했을 것입니다 jetton-child.
1,000,000명의 다른 사용자가 토큰을 보유하고 있다면 정확히 1,000,001개의 계약 인스턴스가 배포됩니다. 여기에서 자동 샤딩의 마법이 발생합니다. 기본적으로 모든 계약 인스턴스는 단일 샤드체인에서 찾을 수 있습니다. 그러나 이러한 사용자가 많은 수의 트랜잭션을 발행하기 시작하고 이 단일 샤드체인의 부하가 높은 경우 TON은 이를 자동으로 더 작은 샤드체인으로 분할합니다. 이론적으로 시스템은 모든 계약 인스턴스가 전용 샤드에서 발견될 때까지 분할 및 분할을 계속할 수 있습니다. 이것이 TON이 수십억 명의 사용자로 확장할 수 있는 비결입니다.
다양한 Jetton 사용자 스토리
이제 기본 아키텍처를 이해했으므로 몇 가지 다른 시나리오를 살펴보겠습니다. 예를 들어 한 사용자가 다른 사용자에게 토큰을 전송할 때 어떤 일이 발생하는지 살펴보겠습니다.
TON에서 참여하는 엔터티는 항상 스마트 계약 인스턴스입니다. 어떤 계약이 역할을 할까요?
당신은 이미 처음 세 개를 만났습니다. 이에 대한 소스 코드는 Jetton repo 에서 찾을 수 있습니다 . 오른쪽에 있는 3개의 계약은 어떻습니까? 우리의 사용자 스토리에는 세 명의 다른 사용자가 참여합니다. Alison과 Becky는 SHIB의 보유자입니다. 사용자 Admin은 SHIB를 배포한 생성자입니다. 관리자는 새로운 SHIB를 발행할 수 있는 유일한 사용자이기 때문에 특별한 역할을 합니다(이것이 새로운 SHIB 토큰이 탄생하는 방식입니다). 이는 가능한 총 공급량을 제한하기 위해 토큰 거래가 시작되면 일반적으로 취소(제로 주소로 변경)해야 하는 신뢰할 수 있는 역할입니다.
TON의 사용자는 스마트 계약으로도 표시됩니다. 이들은 일반적으로 TonKeeper 와 같은 지갑 앱에 의해 사용자를 위해 배포되는 지갑 스마트 계약입니다 . TON에서 지갑 계약이 작동하는 방식에 익숙하지 않은 경우 이전 게시물인 TON 지갑 작동 방식 및 JavaScript에서 액세스하는 방법을 읽어보세요 . Alison, Becky 및 Admin은 각각 이 지갑에 TON 코인 잔액을 보유합니다. 이 지갑은 특별히 Jetton 코드와 관련이 없습니다. 다음은 핵심 TON 저장소의 지갑 계약에 대한 구현 예 입니다 .
사용자 스토리 1: Alison은 SHIB를 가지고 있으며 일부를 Becky에게 보냅니다.
우리의 사용자 스토리는 항상 SHIB Jetton으로 어떤 작업을 수행하기로 결정한 사용자 중 한 명(이 경우 Alison)으로 시작됩니다. 이 경우 Alison은 Becky에게 일부 토큰을 보내기로 결정했습니다. Alison은 선택한 지갑 앱(예: TonKeeper)을 열고 작업을 승인합니다. 이 일이 발생하면 지갑 앱은 서명된 트랜잭션을 Alison의 지갑 계약으로 보냅니다.
트랜잭션에는 일부 대상 계약을 위한 메시지가 포함되어 있습니다. 메시지는 스마트 계약이 TON에서 통신하는 방식입니다. 메시지는 본질적으로 압축된 이진 형식인 셀 백 으로 인코딩됩니다 . 메시지의 키 필드 중 하나는 op이 메시지의 작업 유형을 설명하는 32비트 정수입니다.
transfer이 예에서 Alison은 일부 토큰을 보내려고 하기 때문에 SHIB 잔액을 보유하고 있는 스마트 계약 인스턴스에 op 유형의 메시지를 보냅니다 . 이 메시지는 그녀가 지갑 계약으로 보내는 트랜잭션에 인코딩됩니다. 그녀의 지갑 계약이 트랜잭션 [code] 의 서명을 확인하면 Alison의 메시지를 그녀가 요청한 목적지 [code] 로 전달합니다 .
transfer메시지가 목적지 [code] 에 도달 하면 Alison의 SHIB 잔액을 보유하는 계약에서 이 계약은 메시지를 처리하고 지속 상태를 변경합니다(Alison의 SHIB 잔액을 보낸 금액 [code] 만큼 줄임 ). 계약이 다른 계약에 연결해야 하는 경우 추가 메시지를 보낼 수 있습니다. 우리의 경우 계약은 Becky의 SHIB 잔고 [code]internal transfer 를 보유하고 있는 계약에 op 유형의 메시지를 보낼 것입니다 .
internal transfer메시지가 목적지 [code] 에 도달 하면 이 계약은 이제 메시지를 처리하고 지속 상태를 변경합니다(Becky의 SHIB 잔액을 보낸 금액 [code] 만큼 증가 ). excesses이 계약은 일반적 으로 남은 가스를 Alison의 지갑 계약으로 환불하고 전송이 완료되었음을 알리기 위해 op 유형의 마지막 메시지를 보냅니다 [code] .
다음은 메시지 흐름입니다.
TON의 메시지는 비동기식입니다. 언제 처리될지는 정확히 알 수 없습니다. 모든 메시지가 단일 블록에서 처리될 가능성이 있고 각 메시지가 다른 블록에서 처리될 가능성이 있습니다. 이는 전송을 처리하는 데 다소 시간이 걸릴 수 있음을 의미합니다. 첫 번째 거래가 성공적으로 확인되더라도 여전히 이체가 실패할 수 있습니다.
사용자 스토리 2: Alison은 SHIB를 가지고 있으며 일부를 Becky에게 보내고 이에 대해 Becky에게 알립니다.
SHIB 수령인 베키가 단순한 사람이 아니라 돈을 받을 때 뭔가를 해야 하는 온라인 상점 계약이라면? 예를 들어 새 소유자를 가리키도록 DNS 레코드를 변경합니다. 전용 메시지로 이 스마트 계약을 트리거할 수 있다면 좋을 것입니다.
다행히 transfer메시지는 이 동작을 지원합니다. 이를 통해 원래 발신자는 수신자 SHIB 지갑 소유자에게 전달될 일부 알림 페이로드를 지정할 수 있습니다.
이 경우의 흐름은 마지막 단계를 제외하고는 거의 동일합니다. op 유형 메시지를 보내기 전에 Becky의 SHIB 잔액을 보유한 계약은 먼저 Becky의 SHIB 지갑 소유자인 Becky의 지갑 계약 [code]excesses 에게 op 유형의 메시지를 보냅니다 . 이 이야기는 "Becky"의 이름을 "DNS-Superstore"와 같은 온라인 상점으로 바꾸면 더 이해가 될 것입니다. 이 경우 컨트랙트 "DNS-Superstore"는 "DNS-Superstore"에 대한 SHIB 지갑의 소유자이기 때문에 이 알림을 받게 됩니다. 이 계약은 메시지를 수신하면 메시지에 제공된 데이터에 따라 DNS 레코드 소유권을 변경하는 동작을 구현합니다.transfer notification
다음은 메시지 흐름입니다.
메시지에서 지원하는 다른 기능을 어떻게 알 수 있습니까 transfer? 메시지는 일반적으로 TL-B 라는 언어로 인코딩됩니다 . 가장 좋은 방법은 계약 작성자가 계약에서 처리하는 모든 메시지에 대한 TL-B 사양을 게시하는 것입니다. 관련 TL-B 사양 [코드] 는 다음과 같습니다 .
transfer query_id:uint64 amount:(VarUInteger 16) destination:MsgAddress
response_destination:MsgAddress custom_payload:(Maybe ^Cell)
forward_ton_amount:(VarUInteger 16) forward_payload:(Either Cell ^Cell)
= InternalMsgBody;
amount전송할 SHIB 토큰 수
destinationBecky의 지갑 계약 주소입니다.
response_destinationexcesses(일반적으로 Alison의 지갑 계약) 수신자의 주소입니다.
forward_payload"DNS-Superstore" 사용 사례에 대한 알림 페이로드입니다.
사용자 스토리 3: 앨리슨이 SHIB를 가지고 있고 태워버렸습니다.
이 사용자 스토리에서 Alison은 자신이 보유한 SHIB의 일부를 소각하기로 결정합니다. SHIB를 태우면 순환에서 제거됩니다. 그녀는 왜 이것을 할 것입니까? 소각은 토큰의 총 공급량을 줄입니다. 사용자는 토큰의 시가 총액을 계산하는 데 도움이 되기 때문에 토큰의 총 공급에 관심을 갖습니다 . 소각 토큰은 주식의 주식 환매와 같으며 주식 가치를 높입니다.
총 공급량은 어디에 저장됩니까? 짐작하셨겠지만 이 영구 상태 데이터는 전역적으로 공유되므로 부모 아래에 저장하는 것이 좋습니다 jetton-minter.
소각을 시작하기 위해 Alison은 burnSHIB 잔액을 보유하고 있는 스마트 계약 인스턴스에 op 유형의 메시지를 보냅니다. 이 메시지는 그녀가 이전과 같이 지갑 계약으로 보내는 트랜잭션에 인코딩되어 서명을 확인한 후 목적지로 전달합니다.
burn메시지가 목적지 [code] 에 도달 하면 Alison의 SHIB 잔액을 보유하는 계약에서 이 계약은 메시지를 처리하고 지속 상태를 변경합니다(Alison의 SHIB 잔액을 소각량[code]만큼 줄임 ) . 그런 다음 컨트랙트는 op 유형의 메시지를 burn notification부모 minter 컨트랙트 [code] 로 보냅니다 .
burn notification메시지가 목적지 [code] 에 도달 하면 이 계약은 이제 메시지를 처리하고 지속 상태를 변경합니다(소각량 [code] 만큼 총 공급량 감소 ). excesses이 계약은 일반적 으로 남은 가스를 Alison의 지갑 계약으로 환불하고 소각이 완료되었음을 알리기 위해 op 유형의 마지막 메시지를 보냅니다 [code] .
다음은 메시지 흐름입니다.
상위 채굴자 계약을 통해 사용자는 Getter 메서드 [코드] 를 사용하여 토큰의 총 공급량을 쿼리할 수 있습니다 .
사용자 스토리 4: 관리자가 Becky를 위해 SHIB를 발행합니다.
모든 계약이 초기에 배포되면 총 SHIB 공급은 0이고 아무도 토큰을 가지고 있지 않습니다. 토큰은 어떻게 생성되나요? 새 토큰을 만드는 작업을 발행 이라고 합니다 . 특별한 관리 역할인 Admin 사용자만 수행할 수 있습니다. 관리 사용자는 관리 권한을 다른 주소로 이전할 수도 있습니다. 가장 좋은 방법은 토큰 거래를 시작하기 전에 관리자 권한을 제로 주소로 이전하여 아무도 새 토큰을 발행하고 총 공급량을 부풀릴 수 없도록 하는 것입니다.
민트를 시작하기 위해 관리자는 op 유형의 메시지를 mint부모에게 보냅니다 jetton-minter. 이 메시지는 관리자가 서명을 확인한 후 목적지로 전달하는 지갑 계약으로 전송하는 트랜잭션에 인코딩됩니다.
mint메시지가 목적지 [code] 에 도달 하면 부모 minter 계약인 이 계약은 메시지를 처리하고 실제로 Admin [code] 에서 발생한 메시지를 확인합니다 . 그런 다음 계약은 지속 상태를 변경합니다(발행된 양 [code] 만큼 총 공급량 증가 ). internal transfer컨트랙트는 Becky의 SHIB 잔액 [code] 을 보유하고 있는 컨트랙트에 op 유형의 메시지를 보낼 것입니다 .
internal transfer메시지가 목적지 [code] 에 도달 하면 이 계약은 이제 메시지를 처리하고 지속 상태를 변경합니다(Becky의 SHIB 잔액을 발행된 금액 [code] 만큼 증가 ). excesses이 계약은 일반적 으로 남은 가스를 관리자의 지갑 계약으로 환불하고 조폐국이 완료되었음을 알리기 위해 op 유형의 마지막 메시지를 보냅니다 [code] .
다음은 메시지 흐름입니다.
이 흐름의 마지막 단계는 전송 흐름과 거의 동일합니다. 전송 흐름과 유사하게 SHIB 수신자에게 전용 메시지를 통지하여 결제를 처리할 수 있도록 하는 것도 가능합니다. "DNS-Superstore" 예를 기억하십니까? 이 경우에 대해 다른 전체 사용자 스토리를 추가하지는 않겠지만 다음은 경우를 대비한 메시지 흐름입니다.
누가 하위 계약을 배포합니까?
SHIB 계약 아키텍처를 떠올려 봅시다. jetton-minter부모의 배포된 인스턴스 하나와 jetton-wallet계약의 SHIB 보유자당 배포된 인스턴스 하나입니다.
상위 발행자 계약은 자연스럽게 SHIB의 생성자, 아마도 Admin 사용자에 의해 배포됩니다. 그러나 배포하는 자식 계약은 어떻습니까? 디자인은 효율적입니다. 하위 계약은 소유자가 처음으로 SHIB를 받을 때만 배포됩니다. 수신자는 자신이 SHIB를 받았다는 사실을 반드시 인식하지 못하기 때문에 다소 까다롭게 들릴 수 있습니다.
위의 전송 사용자 스토리를 기억하면 메시지에 의해 SHIB 수신이 트리거됩니다 internal transfer. 이 메시지의 수신자 자식 계약이 배포된 적이 없는 경우 이 메시지를 보낸 사람이 자식을 배포해야 합니다! 여기 코드에서 이런 일이 일어나는 것을 볼 수 있습니다 . state_init메시지 섹션은 실제로 배포를 담당합니다 . 여기에서 자식의 초기 코드 셀(이 계약 구현을 위해 컴파일된 TVM 바이트코드)과 초기 데이터 셀에서 계산된 것을 볼 수 있습니다 .
메시지 발신자는 internal transfer수신자가 배포되었는지 여부를 확신할 수 없기 때문에 항상 배포 부분을 포함합니다. TON은 계약이 이전에 배포된 경우 배포 요소를 무시할 만큼 영리합니다.
부모와 자녀 간의 메시지 인증
위의 사용자 사례에서 우리는 전체 흐름이 여러 메시지에 분산되어 있음을 확인했습니다. 예를 들어, 메시지는 internal transfer수신자가 SHIB 잔액을 늘리도록 합니다(기억하시겠지만 이 메시지는 전송 흐름의 끝에서 전송되었습니다). 공격자가 이 메시지를 위조하여 자신의 SHIB 잔액을 보유하고 있는 계약으로 보내려고 하면 어떻게 될까요? 우리가 주의하지 않으면 그러한 위조로 인해 공격자가 허공에서 스스로 새 토큰을 생성할 수 있는 능력이 생길 수 있습니다!
이 위조로부터 계약을 보호하려면 잔액을 변경하는 이러한 중요한 메시지가 실제로 유효한 발신자로부터 온 것인지 인증해야 합니다. 여기에서 확인 코드를 볼 수 있습니다.
jetton_master_address컨트랙트는 생성자 부모( 어떤 이유로 레이블이 지정됨) 또는 유효한 자식 중 하나가 메시지를 보낸 경우에만 메시지를 처리합니다 .
이것은 매우 흥미로운 질문으로 이어집니다. 임의의 주소가 유효한 자식 jetton 주소인지 어떻게 알 수 있습니까? 잠깐만요, 아까 앨리슨이 베키에게 메시지를 보내려고 했을 때 처음에 베키의 계약 주소를 어떻게 알았죠?
이것은 다시 아름다운 시스템 설계입니다. TON의 스마트 계약에 대한 주소는 계약의 초기 코드 셀(구현의 컴파일된 TVM 바이트코드)과 계약의 초기 데이터 셀(초기 지속 상태)에서 파생됩니다. 건설). 이 두 값을 알면 컨트랙트가 배포되기 전에도 컨트랙트의 주소를 계산할 수 있습니다. 이 계산은 결정론적이며 변경할 수 없습니다.
Jetton 코드에는 Alison의 주소를 기반으로 자녀의 주소(Alison의 SHIB 잔액을 보유한 계약의 주소)를 계산하는 유틸리티 함수가 포함되어 있습니다. 여기에서 이 기능을 볼 수 있습니다 . 보시다시피 실제로 자식의 초기 코드 셀 과 초기 데이터 셀 에 따라 달라집니다 .
이 메커니즘이 안전한 이유를 이해하는 것은 약간 까다롭습니다. 공격자가 법적 자녀 중 하나의 주소에 악의적인 계약을 배포하지 못하도록 막는 것은 무엇입니까? 법적 주소에 도달하려면 악의적인 계약에 공식 자식의 초기 코드 셀이 있어야 합니다. 이것은 이미 공격자가 이 구현에 악성 코드를 추가할 수 있는 능력을 제한했습니다. 또한 초기 데이터 셀은 초기 데이터 셀에 주소가 포함되어 있기 때문에 자식이 올바른 생성자 부모에게만 복종하도록 보장합니다.
일이 잘못되었을 때 부분 변경 처리
기억하시겠지만 전송 흐름은 여러 비동기 메시지에 분산됩니다. 첫 번째 메시지는 보낸 사람의 SHIB 잔액을 줄이고 두 번째 메시지는 받는 사람의 SHIB 잔액을 늘립니다. 이것은 모든 것이 순조롭게 진행되는 행복한 흐름에서 의미가 있지만 두 번째 메시지가 어떻게든 실패하면 어떻게 됩니까?
Ethereum의 EVM과 같은 대부분의 스마트 계약 시스템은 트랜잭션을 완전히 원자적이고 동기식으로 처리합니다. 따라서 이후 단계 중 하나가 실패하면 전체 트랜잭션이 되돌려지고 이 트랜잭션으로 인한 모든 상태 변경도 되돌려집니다. 이 메커니즘은 실제로 이해하기 매우 쉽습니다. 불행하게도 TON의 메시지는 원자적이거나 동기적이지 않기 때문에 이 자동 되돌리기 기능을 사용할 수 없습니다.
그래서 우리가 뭘 할 수 있지? 되돌리기 흐름을 직접 처리해야 합니다. 이것은 TON에서 스마트 계약 개발을 조금 더 어렵게 만드는 예입니다.
발생한 예외로 인해 TON에서 메시지 처리가 실패할 때 이 메시지의 bounce플래그가 설정되어 있으면 시스템은 실패한 메시지를 플래그가 설정된 발신자에게 자동으로 다시 보냅니다 bounced. 여기에서 이 메시지 수신 거부 메커니즘 에 대한 사양을 읽을 수 있습니다 .
위의 예인 전송 흐름에서 두 번째 메시지의 실패로 돌아가 보겠습니다. 이 메시지는 SHIB 발신자가 SHIB 잔액을 보낸 금액만큼 줄인 후에 실패합니다. 시스템의 일관성을 유지하려면 실패 시 이 감소를 실행 취소해야 합니다. 어떻게 작동할까요? 두 번째 메시지가 플래그가 설정된 상태로 전송되었다고 가정하면 bounce반송된 두 번째 메시지가 수신되면 보낸 사람의 감소를 취소할 수 있습니다. 여기에서 반송된 메시지를 처리하는 공식 Jetton 코드를 볼 수 있고 여기에서 감소를 실행 취소할 수 있습니다 .
이 작업을 신중하게 수행하십시오! TON에서 복잡한 메시지 흐름을 디자인할 때 화이트보드를 꺼내 이 게시물에서 했던 것처럼 다양한 메시지 흐름 다이어그램을 그립니다. 이 작업에서 제가 가장 좋아하는 도구는 훌륭한 오픈 소스 Excalidraw 입니다 . 그런 다음 흐름의 모든 단계에서 잠재적인 실패 및 메시지 바운스 시뮬레이션을 시작하여 코드가 실행 취소를 올바르게 처리하는지 확인합니다.
즐거운 코딩하세요!
Tal은 Orbs Network 의 창립자입니다 . 그는 열정적인 블록체인 개발자이자 오픈 소스 지지자이자 TON 생태계의 기여자입니다. 그는 또한 TONcoin Fund 의 주요 개발자 중 한 명입니다 . TON에 대한 Tal의 작업은 GitHub 에서 팔로우하십시오 . Tal의 개인 작업을 보려면 GitHub 및 Twitter를 팔로우하세요 .
탈 콜
