톤(TON) 코인
오픈 네트워크(TON)는 여러 구성 요소로 구성된 분산형 개방형 인터넷 플랫폼입니다. 여기에는 TON 블록체인, TON DNS, TON 스토리지 및 TON 사이트가 포함됩니다. TON 블록체인은 TON의 기본 인프라를 함께 연결하여 더 큰 TON 생태계를 형성하는 핵심 프로토콜입니다.
TON은 확장성이 뛰어난 보안 프레임워크에서 운영하면서 광범위한 크로스체인 상호 운용성을 달성하는 데 중점을 두고 있습니다. TON은 궁극적으로 수억 명의 사용자에게 다가가는 것을 목표로 초당 수백만 건의 트랜잭션(TPS)을 처리하도록 설계되었습니다.
TON 블록체인은 새로운 인터넷에 대한 분산형 비전 개발에 기여하기 위해 다양한 제품과 서비스를 제공하기 위한 분산형 슈퍼컴퓨터 또는 " 슈퍼서버 "로 설계되었습니다.
TON 블록체인의 6가지 고유한 측면
1. 귀하의 스마트 계약은 임대료를 지불하고 사용자에게 비용을 청구해야 합니다.
불변하고 영원한 데이터 저장소인 블록체인은 서류상으로는 훌륭한 개념이지만 곧 알게 되겠지만 확장하기에는 상당히 비실용적입니다. 이더리움의 수수료 모델은 은행의 수수료 모델에서 영감을 받았습니다 . 돈을 보내려면 은행에 거래 수수료를 지불해야 합니다. 수수료 지불 책임은 누구에게 있나요? 전송을 시작한 사용자입니다.
블록체인에 데이터를 저장하는 것은 어떻습니까? 예를 들어 새로운 스마트 계약을 위한 바이트코드 배포는 어떻습니까? 이더리움 모델에서는 배포 트랜잭션을 보내는 사람이 수수료를 지불하도록 규정합니다. 하지만 이 수수료는 한 번만 지불되지만, 체인의 데이터가 영원하다면 채굴자는 이 데이터를 앞으로 몇 년 동안 유지하기 위해 인프라 비용을 계속 지불해야 합니다. 이러한 수수료 경제는 합산되지 않으며 수십억 명의 사용자로 확장하려고 하면 결국 무너질 것입니다.
은행에서 인스턴트 메신저로 이동
TON의 수수료 모델은 상당히 다릅니다. TON은 은행 계좌를 에뮬레이트하는 대신 *인스턴트 메신저*와 같은 웹 앱에서 영감을 받았습니다. Facebook 메신저로 메시지를 보내는 데 드는 비용은 누가 지불합니까? 전송을 시작하는 사람은 확실히 아닙니다. 앱 개발자인 Facebook Inc(또는 Meta Inc, 팔로우하지 않고 Telegram을 직접 사용함)가 실제로 비용을 부담하고 있으며, 이러한 비용을 어떻게든 회수하고 자체 자금을 조달하는 것은 Facebook Inc의 몫입니다.
따라서 TON에서는 dapp 자체가 자체 리소스 비용을 지불해야 합니다. 모든 스마트 계약은 TON 토큰 잔액을 보유하고 있으며 이 잔액을 사용하여 임대료를 지불합니다. 스마트 계약에 자금이 부족하면 결국 삭제됩니다(걱정하지 마세요. 모든 것이 복구 가능합니다). 체인스토리지 비용은 한 번만 지불하는 것이 아니라, 임대료 지불이 계속적으로 이루어지므로 주의하세요. 단기간 동안만 데이터를 보유한다면 훨씬 적은 비용을 지불하게 됩니다. 이러한 수수료 경제는 채굴자의 비용과 더 일치하므로 확장이 더 쉽습니다.
Facebook Inc와 매우 유사하게 TON의 계약 개발자는 운영 자금 조달 방법을 선택할 수 있는 자유가 많습니다. 개발자는 TON 토큰으로 계약 자금을 조달하고 사용자에게 보조금을 지급할 수 있습니다. 또는 다양한 작업에 대해 사용자에게 가스를 청구하고 향후 임대료 지불을 위해 이 가스를 균형있게 유지할 수 있습니다.
2. 스마트 계약 간의 호출은 비동기적이고 원자적이지 않습니다.
이더리움의 강력한 DeFi 생태계를 가능하게 하는 가장 큰 요소 중 하나는 계약의 원활한 구성 가능성입니다. 단일 거래에서 일부 WBTC를 가져오고 이를 컴파운드 계약과 함께 담보로 제공 하고 이를 사용하여 USDC를 빌리고 Uniswap 계약 과 이 USDC를 더 많은 WBTC로 거래하여 WBTC 포지션을 활용할 수 있습니다. 전체 프로세스는 심지어 원자적입니다. 이러한 단계 중 하나라도 실패하면 마지막 단계라도 전혀 발생하지 않은 것처럼 전체 트랜잭션이 롤백됩니다.
귀하의 스마트 계약이 다른 스마트 계약의 메소드를 호출하는 경우 해당 호출은 동일한 트랜잭션에서 즉시 처리됩니다. 이 점에서 Ethereum은 단일 서버에서 전체 백엔드를 실행하는 것과 매우 유사합니다. 백엔드의 모든 부분은 다른 모든 부분에 동기적으로 액세스할 수 있습니다. 이는 추론하기 매우 쉬운 접근 방식입니다. 한 가지 주의 사항이 있는데, 한 장소에 딱 맞는 만큼만 자랄 수 있다는 것입니다.
단일 서버에서 마이크로서비스 클러스터로 이동
Ethereum을 단일 서버의 단일체로 상상한다면 TON은 마이크로서비스 클러스터와 더 유사합니다. 모든 스마트 계약이 다른 시스템에서 실행될 수 있다고 생각해보세요. 두 개의 마이크로서비스가 통신하는 것처럼 두 개의 스마트 계약이 서로 호출하려는 경우 네트워크를 통해 메시지를 보낼 수 있습니다. 이 메시지는 이동하는 데 시간이 걸리므로 통신이 갑자기 비동기화됩니다! 이는 귀하의 스마트 계약이 다른 스마트 계약의 메소드를 호출할 때 트랜잭션이 종료된 후 다른 미래 블록에서 호출이 처리된다는 것을 의미합니다.
이것은 추론하기가 훨씬 더 어렵습니다. 메시지가 전송된 시점부터 수신될 때까지 조건이 변경되면 어떻게 되나요? 예를 들어 호출 계약 잔액에는 하나의 값이 있었지만 두 번째 계약이 호출을 처리할 때 잔액이 변경되었습니다. 일관성을 유지하는 것이 더 어렵고 버그가 발생할 수 있습니다. 원자성은 어떻습니까? 세 번의 통화를 연결했는데 마지막 통화만 실패하면 어떻게 되나요? 모든 변경 사항을 롤백해야 하는 경우 수동으로 롤백해야 합니다.
3. 귀하의 스마트 계약은 다른 계약에서 getter 메소드를 실행할 수 없습니다.
이것은 실제로 목록의 이전 항목과 다른 면입니다. 계약 간의 호출이 동기식인 Ethereum에서는 다른 스마트 계약에서 데이터를 읽는 것이 간단합니다. 내 계약에 USDC 잔액이 있다고 가정해 보겠습니다. USDC도 그 자체로 계약이므로 자체 잔액을 알기 위해서는 내 계약에서 getBalanceUSDC 계약의 메소드를 호출해야 합니다.
단일 서버에서 실행되는 모놀리스를 기억하시나요? 이 접근 방식의 가장 큰 이점 중 하나는 모든 서비스가 다른 모든 서비스의 상태 메모리를 직접 읽을 수 있다는 것입니다.
단일 서버에서 마이크로서비스 클러스터로 이동
서로 다른 시스템에서 실행되는 별도의 마이크로서비스가 있는 경우 서비스 전체에서 상태 메모리를 읽는 것이 갑자기 불가능합니다. TON의 스마트 계약은 비동기 메시지 전송을 통해서만 통신할 수 있습니다. 다른 계약의 데이터를 쿼리해야 하고 즉시 답변이 필요한 경우 운이 좋지 않습니다.
실제로는 더욱 이상해집니다. TON 스마트 계약에서 다음과 같은 getter 메서드를 볼 경우 getBalance이러한 메서드는 다른 스마트 계약에서 액세스할 수 없습니다. Getter 메소드는 Ethereum 지갑이 Infura와 같은 전체 노드를 사용하여 스마트 계약 상태를 쿼리할 수 있는 방법과 유사하게 오프체인 클라이언트에서만 호출할 수 있습니다.
4. 스마트 계약 코드는 불변이 아니며 쉽게 수정할 수 있습니다.
Ethereum의 dapp에 대한 원래 영감은 변호사가 작성한 법률 문서에서 비롯되었습니다 . 따라서 "스마트 계약"이라는 이름이 붙었습니다. 개발자는 법적 계약 조건을 코드로 프로그래밍하며, 아시다시피 코드는 법입니다. 현실 세계의 두 당사자가 계약에 서명하면 계약은 변경할 수 없습니다. 당사자 중 누군가가 계약 조건을 변경하려는 경우 대신 새 계약서를 작성합니다.
이러한 접근 방식에 따라 이더리움의 스마트 계약 코드는 변경 불가능하고 절대 수정되지 않도록 설계되었습니다. 수년에 걸쳐 개발자 커뮤니티는 이러한 제한을 극복하는 방법을 배웠으며 업그레이드를 구현하기 위해 다른 계약을 가리키는 프록시 계약과 같은 트릭에 의존하는 몇 가지 성가신 패턴을 생성했습니다.
변호사에서 소프트웨어 엔지니어로 전환
변호사와 달리 소프트웨어 엔지니어는 모든 코드에 버그가 있다는 것을 배웁니다. 실수가 절대 발생하지 않더라도 요구사항은 시간이 지남에 따라 계속 변경되며 코드를 업그레이드하고 수정해야 하는 경우도 많습니다.
TON에서는 계약이 불변이어야 한다는 주장이 완전히 사라졌습니다. 스마트 계약은 다른 상태 변수에 쓰는 것처럼 자체 코드를 자유롭게 수정할 수 있습니다. 계약이 코드 변수에 쓰면 변경 가능하고, 그렇지 않으면 불변입니다. 실제로 이는 큰 변화가 아니며 단지 번거로운 프록시 패턴을 중복하게 만들 뿐입니다.
5. 계약 상태에 무제한의 데이터 구조가 있어서는 안 됩니다.
이것은 이해하는 데 시간이 걸리는 까다로운 문제이지만 TON의 일부 스마트 계약이 왜 그런 방식으로 설계되었는지 설명할 것입니다.
무제한 데이터 구조는 무한정 증가할 수 있는 스마트 계약의 상태 변수입니다. USDC 토큰을 구현하는 ERC20 계약을 고려해보세요. 이 계약은 사용자 주소당 잔액 지도를 유지해야 합니다. USDC는 대량으로 발행되고 작은 조각으로 분해될 수 있으므로 다양한 USDC 보유자의 수는 무한정 늘어날 수 있습니다. 즉, 맵의 키 수는 원하는 만큼 커질 수 있습니다.
공격자가 점점 더 많은 항목을 추가하여 계약에 스팸을 보내려고 하면 어떻게 됩니까? DoS 공격을 일으키고 다른 정직한 사용자가 이 계약을 사용하는 것을 막을 수 있습니까? Ethereum은 스마트 계약 개발자를 위해 이 문제를 매우 우아하게 해결합니다. 이더리움 수수료 모델은 새로운 상태 데이터를 작성하는 사용자가 이 데이터에 대한 수수료를 지불하도록 규정합니다. 이는 공격자가 스팸에 대해 높은 비용을 지불해야 함을 의미합니다. 또한, 이더리움 지도에 쓰기 위한 가스 비용은 일정하며 이 지도에 포함된 데이터의 양에 좌우되지 않습니다. 이는 다른 사용자가 스팸으로 인해 고통받지 않는다는 것을 의미합니다. 결론은 이더리움의 스팸 맵은 경제적이지 않으며 시스템에서 보호 기능을 제공한다는 것입니다.
무제한 지도에서 무제한 계약으로 이동
TON 스마트 계약 개발자에게는 불행하게도 시스템은 계약 상태의 무제한 데이터 구조 스팸으로부터 보호하지 못합니다. TON 가스 요금 모델에 따르면 쓰기 비용은 일정하지 않으며 비용은 일반적으로 데이터 구조에 존재하는 데이터 양에 비례합니다. 이 동작은 TON이 "Bag of Cells" 아키텍처에 의존하기 때문에 발생합니다. 계약 상태는 개발자가 유지 관리해야 하는 "셀"이라는 1023비트 청크로 나누어집니다. 맵은 셀 트리로 구현되며 트리의 리프에 쓰려면 전체 높이를 따라 새 해시를 작성해야 합니다. 공격자가 맵에서 키를 스팸하는 경우 일부 사용자 잔액이 트리에서 너무 낮게 푸시되어 이를 업데이트하면 가스 한도를 초과하게 됩니다.
따라서 TON의 모범 사례는 상태에서 무제한 데이터 구조를 피하는 것입니다. 이는 교묘한 DoS 취약성으로부터 계약을 보호합니다. 이 주제는 아마도 자체적인 독립적인 블로그 게시물이 필요할 것입니다. 그러나 간단히 말해서 해결책은 계약 샤딩에 의존하는 것입니다. USDC 계약에 잠재적으로 무한한 수의 사용자 잔액이 있는 경우 단일 계약을 여러 하위 계약으로 나누어 각 하위 계약이 단일 사용자의 잔액을 보유해야 합니다.
이는 TON의 NFT 수집 계약이 모든 항목을 별도의 계약에 배치하는 이유를 설명해야 합니다 (항목 수는 무제한일 수 있음). 그리고 TON의 대체 가능한 토큰 계약이 모든 사용자의 잔액을 별도의 계약에 배치하는 이유를 알아보세요.
우리는 일반적으로 TON이 왜 이런 방식으로 설계되었는지에 대한 약간의 추론을 제공합니다. 맵 쓰기가 고정되고 맵 크기와 무관한 이더리움 가스 요금 모델은 지나치게 단순화되었습니다. 실제로 지도의 크기가 커짐에 따라 채굴자는 지도의 내용을 변경하는 데 더 많은 노력이 필요합니다. 지도가 작은 한 이러한 추가 노력은 무시할 수 있지만 지도가 수십억 개의 항목으로 성장할 수 있는 경우에는 더 이상 그렇지 않습니다.
6. 지갑은 계약이며 하나의 공개 키로 여러 지갑을 배포할 수 있습니다.
이더리움에서 사용자의 지갑은 주소와 동의어이며 주소는 공개 키(및 해당 개인 키)에서 직접 파생됩니다. 이는 1:1 관계이며 공개 키당 하나의 주소가 있고 주소당 하나의 공개 키가 있습니다. 사용자가 개인 키를 알고 있는 한 지갑을 잃어버릴 일은 없습니다.
게다가 이더리움 사용자는 지갑을 갖기 위해 특별한 조치를 취할 필요가 없습니다. 이더리움 주소는 지갑입니다. 주소는 기본 통화인 ETH를 보유할 수 있고, 주소는 ERC20 토큰 및 NFT를 보유할 수 있으며, 주소는 다른 스마트 계약에 직접 거래를 보내고 서명할 수 있습니다.
주소에서 계약으로 이동
TON에서 지갑은 암시되지 않으며 다른 스마트 계약처럼 배포되어야 하는 독립적인 스마트 계약입니다. 신규 사용자가 TON 블록체인 사용을 시작하려는 경우 첫 번째 단계는 온체인 지갑을 배포하는 것입니다. 이 지갑의 주소는 지갑 계약 코드와 사용자의 공개 키와 같은 다양한 초기화 매개변수에서 파생됩니다.
이는 사용자가 각각 고유한 주소를 가진 두 개 이상의 지갑을 배포할 수 있음을 의미합니다. 지갑은 코드(재단에서 수시로 다른 공식 코드 버전을 게시함) 또는 초기화 매개변수(이러한 매개변수 중 하나는 일반적으로 시퀀스 번호임)가 다를 수 있습니다. 이는 또한 자신의 개인 키를 알고 있는 사용자가 지갑 주소(또는 지갑 구성에 사용된 초기화 매개변수)를 기억하기 위해 의식적인 노력을 기울여야 함을 의미합니다.
TON의 일부 dapp에 트랜잭션을 보내는 것은 사용자의 개인 키를 사용하여 메시지에 서명하는 것을 포함합니다. 이더리움과 달리 이 거래는 Dapp 스마트 계약으로 전송되지 않고 사용자의 지갑 계약으로 전송되며, 이는 다시 메시지를 Dapp 스마트 계약으로 전달합니다.
이 설계 접근 방식은 TON에 새로운 차원의 유연성을 열어줍니다. 시간이 지남에 따라 커뮤니티에서 새로운 지갑 계약을 고안할 수 있습니다. 예를 들어, 사전 동기화 없이 여러 클라이언트에서 여러 트랜잭션을 병렬로 보낼 수 있는 nonce(트랜잭션 시퀀스 번호)가 없는 지갑을 생각해 보세요. 또한 다중 서명 지갑(이더리움에서도 배포하려면 특별한 스마트 계약이 필요함)과 같은 특수 지갑은 일반 지갑과 동일하게 작동합니다.