Author: @Web3Mario (https://x.com/web3_mario)
Abstract: TON에 대한 이전 기사에 이어 기술 소개 기사 , 저는 이 기간 동안 TON 공식 개발 문서를 깊이 있게 연구해 왔는데, 아직 학습에 장벽이 있는 것 같습니다. 현재 문서 내용은 그다지 많지 않은 내부 개발 문서에 가까운 것 같습니다. 그래서 TON Chain 프로젝트 개발에 대한 일련의 기사를 나만의 학습 궤적을 바탕으로 정리하려고 노력합니다. 이 글이 모든 사람이 TON DApp을 빨리 시작하는 데 도움이 되기를 바랍니다. 개발. 혹시 글에 틀린 부분이 있으면 바로잡아주시고 함께 배워가셔도 좋습니다.
을 개발하는 것의 차이점은 무엇인가요? FT 또는 NFT It 일반적으로 DApp 개발자에게 가장 기본적인 요구사항입니다. 그래서 저는 이것을 학습의 시작점으로도 사용합니다. 먼저 EVM 기술 스택과 TON Chain에서 NFT을 개발하는 것 사이의 다음 차이점을 이해해 보겠습니다.NFT 기반 EVM은 일반적으로 ERC-721 표준을 상속하도록 선택합니다. 소위 NFT는 분할할 수 없는 유형의 암호화 자산을 말하며 각 자산은 고유합니다. 즉, 특정한 독점적 특성을 가지고 있습니다. 그리고 ERC-721은 이러한 유형의 자산에 대한 일반적인 개발 패러다임입니다. 공통 ERC721 컨트랙트가 어떤 기능을 구현해야 하는지, 어떤 정보가 기록되는지 살펴보겠습니다. 아래 사진은 ERC721 인터페이스입니다. FT와 달리 이체 인터페이스에 입력해야 하는 것은 금액 대신 이체할 tokenId임을 알 수 있습니다.이 tokenId는 NFT의 고유성을 구현하는 가장 기본적인 구현이기도 합니다. 물론 더 많은 속성을 전달하기 위해 일반적으로 각 tokenId에 대해 metadata가 기록됩니다. metadata 는 PFP 사진에 대한 링크, 특정 속성 이름 등과 같은 NFT의 다른 확장 가능한 데이터를 저장하는 외부 링크입니다.
Solidity에 익숙하거나 객체지향에 익숙한 개발자라면 다음과 같이 계약에 필요한 데이터 유형이 정의되어 있는 한 이러한 스마트 계약을 쉽게 구현할 수 있습니다. 몇 가지 주요 매핑 관계 mapping을 수행하고 필요한 기능에 따라 이러한 데이터에 해당 수정 로직을 개발하면 NFT을 구현할 수 있습니다.
그러나 TON Chain에서는 모든 것이 다릅니다. 차이점에는 두 가지 핵심 이유가 있습니다.
TON과 EVM의 스마트 계약 개발 간에 큰 차이를 만듭니다.초기 논의에서 우리는 NFT 계약이 NFT 관련 데이터를 저장하기 위해 일부 매핑 관계, 즉 mapping을 정의해야 한다는 것을 알고 있습니다. 가장 중요한 것은 owners입니다. 이 mapping은 NFT에 해당하는 특정 tokenID의 소유자 주소 매핑 관계를 저장하며, 이는 NFT의 소유권과 이전을 결정합니다. 해당 소유권의 수정입니다. 이는 이론상 무한정이 가능한 자료구조이므로 최대한 피하는 것이 필요하다. 따라서 무한한 데이터 구조의 존재를 샤딩의 표준으로 사용하는 것이 공식적으로 권장됩니다. 즉, 유사한 데이터 저장 요구 사항이 있는 경우 마스터-슬레이브 계약 패러다임 이 대신 사용되며 각 key에 해당하는 데이터는 하위 계약을 생성하여 관리됩니다. 그리고 주 계약을 통해 전역 매개 변수를 관리하거나 하위 계약 간의 내부 정보 상호 작용을 처리하는 데 도움을 줍니다.
이것은 또한 TON의 NFT도 유사한 아키텍처로 설계되어야 함을 의미합니다. 각 NFT은 소유자 주소와 같은 항목을 저장하는 독립적인 하위 계약입니다. metadata 및 기타 독점 데이터를 사용하며, 메인 컨트랙트는 NFT 이름, symbol, 총 공급량 등과 같은 글로벌 데이터를 관리하는 데 사용됩니다.
아키텍처를 명확히 한 후 다음 단계는 핵심 기능 요구 사항을 해결하는 것입니다. 이러한 마스터-슬레이브 계약 방식의 채택으로 인해 그래서 주 계약이 어떤 기능을 수행하는지, 어떤 기능을 담당하는지 명확히 할 필요가 있습니다. 기능은 하위 계약에 의해 수행되며 둘 사이에 어떤 내부 정보가 전달되는지, 실행 오류가 발생하면 이전 데이터를 어떻게 롤백하는지. 일반적으로 복잡한 대규모 프로젝트를 개발하기 전에 클래스 다이어그램을 전달하고 서로 간의 정보 흐름을 명확히 해야 하며, 내부 호출 실패 후 롤백 로직에 대해 신중하게 생각해야 합니다. 물론 위의 NFT. 개발은 간단하지만 유사한 검증도 수행할 수 있습니다.
smart 스마트 계약으로 등급
공식 문서에서 NFT 예제를 선택하여 소개하고 있습니다. 너 자신. 이 케이스에는 간단한 TON NFT 예제가 구현되어 있습니다. 2개의 기능 계약과 3개의 필수 라이브러리로 구분된 계약 구조를 살펴보겠습니다. 이 두 가지 주요 기능 계약은 위의 원칙에 따라 설계되었습니다. 먼저 기본 계약 nft-collection의 코드를 살펴보겠습니다. 여기에서는 TON 스마트 계약에 데이터를 지속적으로 저장하는 방법에 대한 첫 번째 지식 포인트를 소개합니다. 우리는 Solidity에서 데이터의 영구 저장이 매개변수에 따라 EVM에 의해 수행된다는 것을 알고 있습니다. 일반적으로 스마트 계약의 상태 변수는 실행 후 최신 값을 기준으로 자동으로 유지되고 저장됩니다. 하지만 Func에서는 그렇지 않습니다. 개발자가 해당 처리 로직을 직접 구현해야 합니다. 이 상황은 GC를 고려해야 하는 C 및 C++ 프로세스와 다소 유사합니다. . 하지만 다른 새로운 개발 언어는 일반적으로 논리의 이 부분을 자동화합니다. 먼저 코드를 살펴보겠습니다. 먼저 몇 가지 필수 라이브러리를 소개한 다음 첫 번째 함수 load_data가 지속적으로 저장된 데이터를 읽는 데 사용된다는 것을 알 수 있습니다. 해당 논리는 먼저 를 통해 영구 데이터를 반환하는 것입니다. get_data 계약 저장 cell. 이는 표준 라이브러리 stdlib.fc에 의해 구현됩니다. 일반적인 상황에서는 일부 기능을 시스템 기능으로 사용할 수 있습니다. 이 함수의 반환 값 유형은 cell이며, 이는 TVM의 cell 유형입니다. 이전 소개에서 우리는 TON 블록체인의 모든 영구 데이터가 cell 트리에 저장된다는 것을 이미 알고 있었습니다. 각 cell에는 최대 1023 비트의 임의 데이터와 다른 cell에 대한 최대 4개의 참조가 있습니다. cell은 스택 기반 TVM 에서 메모리로 사용됩니다.cell은 긴밀하게 인코딩된 데이터를 저장합니다. 특정 일반 텍스트 데이터를 얻으려면 cell을 slice이라는 유형으로 변환해야 합니다. cell은 begin_parse 함수를 사용하여 slice 유형으로 변환할 수 있습니다. 그런 다음 slice에서 데이터 비트 및 다른 cell에 대한 참조를 로드하여 얻을 수 있습니다. . 15 코드 줄의 이 호출 메서드는 첫 번째 함수의 반환 값으로 두 번째 함수를 직접 호출할 수 있는 func의 설탕 구문입니다. 그리고 마지막으로 데이터 지속 순서에 따라 해당 데이터를 순서대로 로드합니다.이 프로세스는 solidity와 다르며 hashmap을 기반으로 호출되지 않으므로 호출 순서가 엉망이 될 수 없습니다. save_data 함수에서 논리는 비슷하지만 이것이 다음 지식 포인트인 새로운 유형 builder을 도입하는 역 프로세스라는 점만 제외하면 셀 유형입니다. 빌더. 다른 cell에 대한 데이터 비트와 참조는 빌더에 저장될 수 있으며, 그런 다음 새로운 cell으로 마무리될 수 있습니다. 먼저 표준 함수 begin_cell를 통해 builder를 만들고, store 관련 함수를 통해 저장 관련 함수를 차례로 위의 호출 순서가 여기의 저장 순서와 일치해야 합니다.마지막으로 end_cell을 통해 새로운 cell이 생성됩니다. 이때 cell은 마지막으로 가장 바깥쪽에 있는 set_data을 통해 관리됩니다. cell의 영구 저장 공간입니다. 다음으로 비즈니스 관련 기능을 살펴보겠습니다. 먼저 방금 소개한 마스터-슬레이브 아키텍처에서 자주 사용하게 될 계약을 통해 새로운 계약을 생성하는 방법에 대한 지식 포인트를 소개해야 합니다. 우리는 TON에서 스마트 계약 간의 호출이 내부 메시지를 전송하여 구현된다는 것을 알고 있습니다. 이는 send_raw_message라는 파일을 통해 이루어집니다. 첫 번째 매개변수는 message인코딩된 cell이고 두 번째 매개변수는 트랜잭션을 나타내는 데 사용되는 식별 비트입니다. 실행 방법, 내부 메시지 전송의 다양한 실행 방법은 TON에 설정되어 있으며, 에는 현재 3 종류의 메시지Modes와 3종류의 메시지Flags가 있습니다. 단일 Mode를 여러(아마도 없음) 플래그와 결합하여 원하는 mode을 얻을 수 있습니다.조합은 단지 값의 합계 를 채우는 것을 의미합니다. Modes 및 Flags의 설명 테이블 은 다음과 같습니다. 첫 번째 주요 기능인 deploy_nft_item을 살펴보겠습니다. 이름에서 알 수 있듯이 이것은 기능입니다. for 새로운 NFT 인스턴스를 생성하거나 캐스팅하는 함수입니다. msg을 인코딩하는 몇 가지 작업을 수행한 후 send_raw_message를 통해 내부 계약이 전송되고 flag 1이 전송됩니다. 가 선택되었습니다. 인코딩에 지정된 fee만 이 실행의 가스 요금으로 사용됩니다. 위의 소개 후에 우리는 이 코딩 규칙이 새로운 스마트 계약을 생성하는 방법과 일치해야 한다는 것을 쉽게 알 수 있습니다. 그럼 어떻게 구현되는지 살펴보겠습니다. 51 라인을 직접 살펴보겠습니다. 위 두 함수는 message에 필요한 정보를 생성하는 데 사용되는 보조 함수이므로 나중에 살펴보겠습니다. 스마트 계약 생성 인코딩 과정에서 중간에 있는 일부 숫자는 실제로 내부 메시지의 요구 사항을 설명하는 데 사용되는 일부 식별 비트입니다. 여기서는 TON 유형을 선택했습니다. -B 바이너리 언어는 메시지가 실행되는 방식과 다양한 플래그 비트 설정을 기반으로 특정 특정 기능을 구현하는 내부 메시지를 설명하는 데 사용됩니다. 가장 쉽게 생각되는 두 가지 사용 시나리오는 새로운 계약 생성과 배포된 계약 함수 호출입니다. 51 라인의 방법은 전자에 해당하며 새로운 nft item 계약을 생성하며 주로 55, 56, 57을 통해 수행됩니다. 세 라인은 다음과 같습니다. 지정.우선 55 줄의 큰 숫자는 일련의 식별 비트입니다. store_uint의 첫 번째 입력 매개변수는 숫자 값이고 두 번째는 비트 길이입니다. 내부 메시지가 계약에 의해 생성되었는지 여부를 결정하는 것은 마지막 세 개의 표시 비트이고 해당 이진 값 비트는 111(10진수는 4+2+1)입니다. 두 개는 메시지에 StateInit 데이터가 함께 제공된다는 것을 나타냅니다. 이 데이터는 새 계약의 소스 코드이자 초기화에 필요한 데이터입니다. 후자의 플래그 비트는 내부 메시지 첨부를 나타냅니다. 즉, 관련 논리 및 필수 매개변수가 실행될 것으로 예상됩니다. 따라서 배포된 계약에 대한 함수 호출을 나타내는 3자리 데이터가 66 줄에 설정되지 않은 것을 볼 수 있습니다. 자세한 코딩 규칙은 여기에서 확인할 수 있습니다. 그러면 StateInit의 인코딩 규칙은 calculate_nft_item_state_init을 통해 계산된 49 코드 라인에 해당합니다. stateinit데이터의 인코딩도 설정된 규칙을 따릅니다. TL- B일부 플래그 비트를 제외한 인코딩 규칙은 주로 새 계약 코드과 초기화 data의 두 부분을 포함합니다. data의 인코딩 순서는 새 계약에서 지정한 영구 cell의 저장 순서와 일치해야 합니다.36 줄에서 볼 수 있듯이 초기화 데이터에는 erC721의 tokenId과 유사한 item_index과 표준 함수 가 포함됩니다. 내 _ address 반환된 현재 계약 주소는 collection_address입니다. 이 데이터의 순서는 nft-item의 설명과 일치합니다. 다음 지식 포인트는 TON에서 생성되지 않은 모든 스마트 계약이 생성된 주소를 미리 계산할 수 있다는 것입니다. 이는 Solidity의 create2 기능과 유사합니다. TON에서는 workchain 식별 비트와 stateinit의 해시 값 두 부분으로 구성됩니다. 우리는 전자가 해당 TON에 대한 것임을 이미 알고 있습니다. 무한 샤딩 아키텍처의 경우 현재 통합된 값입니다. 표준 함수 workchain에서 가져옵니다. 후자는 표준 함수 cell_hash로 얻습니다. 다시 이 예시로 돌아가면, calculate_nft_item_address는 새로운 컨트랙트 주소를 미리 계산하는 함수입니다. 그리고 53 라인에서 생성된 값을 내부 메시지의 수신 주소로 message로 인코딩합니다.그리고 nft_content는 생성된 컨트랙트에 대한 초기화 호출에 해당합니다. 구체적인 구현은 다음 글에서 소개하겠습니다. send_royalty_params의 경우 읽기 전용 요청의 내부 메시지에 대한 응답이어야 합니다. 이전 소개에서 TON의 내부 메시지는 그뿐만 아니라 가능한 수정 사항이 포함되어 있습니다. 데이터 작업과 읽기 전용 작업도 이러한 방식으로 구현되어야 하므로 이 계약은 가장 먼저 주목해야 할 점은 67 라인이 이후 요청자의 콜백 함수 표시를 나타냅니다. 요청에 응답하는 것은 요청한 item index 및 해당 royalty 데이터인 반환된 데이터입니다. 다음 지식 포인트를 소개하겠습니다. TON에는 recv_internal과 recv_external이라는 두 개의 통합 입구만 있습니다. 여기서 전자는 모든 내부 메시지의 통합입니다. 호출 항목(후자는 모든 외부 메시지에 대한 통합 호출 항목)입니다. 개발자는 message에 지정된 다양한 플래그 비트를 기반으로 다양한 요청에 응답하기 위해 함수 내에서 switch와 유사한 메서드를 사용해야 합니다. 여기서 마크 비트는 위 라인 67의 콜백 함수 마크입니다. 이 예시로 돌아가서 먼저 message에서 공석 확인을 수행한 다음 message의 정보를 각각 구문 분석합니다. 먼저 83 행을 구문 분석하여 sender_address를 얻습니다. . 매개변수는 후속 권한 확인에 사용됩니다. 여기서 ~ 연산자는 또 다른 구문입니다. 여기서는 더 이상 설명하지 않겠습니다.다음으로 op 작업 플래그 비트가 구문 분석된 후 해당 요청이 다른 플래그 비트에 따라 처리됩니다. 그 중 위의 함수들은 각각 일정한 논리에 따라 호출됩니다. 예를 들어, royalty 매개변수에 대한 요청에 응답하거나 새로운 nft을 생성하고 전역 index을 증가시킵니다. 다음 지식 포인트는 108 라인에 해당합니다. 이름을 지정하면 이 함수의 처리 논리를 알 수 있습니다. 이는 Solidity, 의 require 함수와 유사합니다. Func 표준 함수 throw_unless를 통해 예외가 발생합니다. 첫 번째 입력 매개변수는 오류 코드이고 두 번째는 비트 부울 값을 확인하는 것입니다. 오류 코드와 함께 표시됩니다. 이 줄에서는 equal_slices을 사용하여 위에서 구문 분석한 sender_address가 컨트랙트 영구 저장소의 owner_address와 동일한지 확인하고 허가 여부를 판단합니다. 마지막으로 코드 구조를 더 명확하게 하기 위해 지속성 정보를 얻는 데 도움이 되는 일련의 보조 기능이 개발되었습니다. 여기서는 개발자가 자신의 스마트한 개발을 위해 이 구조를 참조할 수 없습니다. 계약.
TONecological DApp개발은 정말 흥미로운 일이고 EVM의 개발 패러다임과는 많이 다르기 때문에 TON Chain에서 개발하는 방법을 시리즈를 통해 소개하겠습니다. 기사 DApp에서 개발되었습니다. 모두와 함께 배우고 이러한 기회의 물결을 포착하세요. twitter에서 저와 소통하여 새롭고 흥미로운 dapp 아이디어를 접하고 함께 개발할 수도 있습니다. 
위 내용은 TON 프로젝트 개발 튜토리얼(1): 소스 코드 관점에서 TON 체인에서 NFT를 생성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
