Jetton 아키텍처

Jetton 인스턴스가 Shiba-Inu 또는 줄여서 SHIB 토큰용이라고 가정해 보겠습니다 . SHIB를 보유하고 있는 두 명의 사용자가 있습니다. Alison과 Becky입니다. 우리는 이미 각 사용자의 잔액이 자체 컨트랙트 인스턴스에 보관된다고 말했습니다. 즉, 인스턴스가 2개 (자식, children) 있음을 의미합니다. SHIB (부모, parent)에 대한 글로벌 공유 정보를 보유하기 위한 또 다른 인스턴스도 필요합니다.

이로 인해 다음과 같은 아키텍처가 나타납니다.

실용적인 예시를 보여드리겠다고 앞에서 저는 약속했습니다. 이제 실제 Jetton 코드를 같이 읽어 보겠습니다! TON 코어 팀이 정리 한 Jetton 표준의 내용은 여기에서 찾을 수 있습니다 . 코드에 익숙해질 수 있도록 둘러 보세요.

코드를 보면 크게 두 가지 FunC 스마트 컨트랙트를 볼 수 있습니다.

• jetton-minter.fc - 이 코드는 토큰에 대한 전역 공유 정보 (global shared information)를 보유하는 부모이고 토큰의 이름 및 기호를 저장합니다. 부모는 단일 인스턴스만 있습니다. 사견 인데, TON 코어팀이 jetton-minter 라는 이름을 선택한 이유를 저로써는 완전히 이해 할수 없지만, 저라면 jetton-parent 라는 이름을 선호했을 것입니다. 이 컨트랙트가 민팅 (minting)을 담당하고 있는 것은 사실이지만, 민팅이 비활성화되더라도 여전히 필요하기 때문에 다소 혼란스럽습니다.

• jetton-wallet.fc - 단일 사용자 (single user)의 토큰 잔액을 보유하는 자식입니다. 이 컨트랙트에는 각 사용자 주소마다 하나씩, 즉 여러 인스턴스가 있습니다. TON 코어팀이 이 컨트랙트의 이름으로 jetton-wallet를 선택했지만, 저라면 jetton-child 이란 이름을 선호했을 것입니다.

만약 1,000,000명의 각기 다른 사용자가 토큰을 보유하고 있다면 정확히 1,000,001개의 컨트랙트 인스턴스가 배포됩니다. 여기에서 자동 샤딩의 마법이 발생합니다. 기본적으로 모든 컨트랙트 인스턴스는 단일 샤드체인에서 찾을 수 있습니다. 그러나 이러한 사용자가 많은 수의 트랜잭션을 발행하기 시작하고, 이 단일 샤드체인의 부하가 높은 경우 TON은 이를 자동으로 더 작은 샤드체인으로 분할합니다. 이론적으로 시스템은 모든 컨트랙트 인스턴스가 전용 샤드에서 발견될 때까지 분할 및 분할을 계속할 수 있습니다. 이것이 TON이 수십억 명의 사용자로 확장할 수 있는 비결입니다.