TON: 텔레그램 오픈 네트워크. 2부: 블록체인, 샤딩

이 텍스트는 올해 출시를 준비 중인 분산 네트워크 TON(Telegram Open Network)의 구조를 조사한 일련의 기사의 연속입니다. 안에 이전 부분 가장 기본적인 수준, 즉 노드가 서로 상호 작용하는 방식을 설명했습니다.

만일을 대비해, 저는 이 네트워크의 개발과 아무 관련이 없으며 모든 자료는 공개된(비록 검증되지는 않았지만) 소스에서 수집되었음을 상기시켜 드리겠습니다. 문서 (동봉된 내용도 있습니다. 팜플렛, 주요 내용을 간략하게 설명), 작년 말에 게재되었습니다. 제 생각에는 이 문서에 포함된 정보의 양은 이에 대한 공식적인 확인은 없지만 그 진위성을 나타냅니다.

오늘은 TON의 주요 구성 요소인 블록체인을 살펴보겠습니다.

기본 개념

계정 (계정). 256비트 숫자로 식별되는 데이터 세트 계정 ID (대부분 이는 계정 소유자의 공개 키입니다.) 기본 사례(아래 참조) 제로 워크체인), 이 데이터는 사용자의 잔액을 나타냅니다. "점령" 특정 계정 ID 누구나 할 수 있지만 그 가치는 특정 규칙에 따라서만 변경될 수 있습니다.

똑똑한 계약 (스마트 계약). 본질적으로 이는 스마트 계약 코드와 변수 저장으로 보완되는 계정의 특별한 경우입니다. "지갑"의 경우 상대적으로 간단하고 미리 결정된 규칙에 따라 돈을 입금하고 인출할 수 있는 경우 스마트 계약의 경우 이러한 규칙은 코드 형식으로 작성됩니다(특정 Turing-complete에서). 프로그래밍 언어).

블록체인 상태 (블록체인의 상태). 모든 계정/스마트 계약의 상태 집합(추상적인 의미에서 해시 테이블, 여기서 키는 계정 식별자이고 값은 계정에 저장된 데이터입니다).

메시지 (메시지). 위에서 나는 "신용 및 직불 돈"이라는 표현을 사용했습니다. 이것은 메시지의 특별한 예입니다("이체"). N그램 계좌로부터 account_1 계정당 account_2"). 분명히 계정의 개인 키를 소유한 노드만이 그러한 메시지를 보낼 수 있습니다. account_1 - 서명으로 이를 확인할 수 있습니다. 이러한 메시지를 일반 계정에 전달하면 잔액이 증가하고, 스마트 계약의 결과는 해당 코드(메시지 수신을 처리하게 됨)가 실행되는 것입니다. 물론 다른 메시지도 가능합니다(금전적 금액이 아닌 스마트 계약 간 임의의 데이터 전송).

거래 (거래). 메시지가 전달된다는 사실을 트랜잭션이라고 합니다. 거래는 블록체인의 상태를 변경합니다. 블록체인에서 블록을 구성하는 것은 거래(메시지 전달 기록)이다. 이와 관련하여 블록체인의 상태를 증분 데이터베이스로 생각할 수 있습니다. 모든 블록은 데이터베이스의 현재 상태를 얻기 위해 순차적으로 적용되어야 하는 "차이점"입니다. 이러한 "차이점"을 패키징하는 방법(및 전체 상태를 복원하는 방법)에 대한 자세한 내용은 다음 기사에서 설명합니다.

TON의 블록체인: 정의와 이유

이전 글에서 언급했듯이, 블록체인은 데이터 구조로, 그 요소(블록)는 "체인"으로 정렬되며 체인의 각 후속 블록에는 이전 블록의 해시가 포함됩니다.. 의견에서는 다음과 같은 질문을 했습니다. 분산 해시 테이블인 DHT가 이미 있는데 왜 그러한 데이터 구조가 필요한가요? 분명히 일부 데이터는 DHT에 저장될 수 있지만 이는 너무 "민감한" 정보가 아닌 경우에만 적합합니다. 암호화폐 잔액은 DHT에 저장할 수 없습니다. 주로 확인이 부족하기 때문입니다. 무결성. 실제로 블록체인 구조의 전체 복잡성은 그 안에 저장된 데이터에 대한 간섭을 방지하기 위해 증가합니다.

그러나 TON의 블록체인은 대부분의 다른 분산 시스템보다 훨씬 더 복잡해 보입니다. 그 이유는 두 가지입니다. 첫 번째는 필요를 최소화하려는 욕구입니다. 포크. 전통적인 암호화폐에서는 모든 매개변수가 초기 단계에서 설정되며 이를 변경하려는 시도는 실제로 "대체 암호화폐 세계"의 출현으로 이어집니다. 두 번째 이유는 분쇄(샤딩, 샤딩) 블록체인. 블록체인은 시간이 지나도 작아질 수 없는 구조입니다. 일반적으로 네트워크 운영을 담당하는 각 노드는 이를 완전히 저장해야 합니다. 전통적인(중앙 집중식) 시스템에서는 샤딩이 이러한 문제를 해결하는 데 사용됩니다. 데이터베이스의 레코드 중 일부는 한 서버에 있고 일부는 다른 서버에 있습니다. 암호화폐의 경우 이러한 기능은 여전히 ​​매우 드뭅니다. 특히 원래 계획되지 않은 시스템에 샤딩을 추가하기가 어렵기 때문입니다.

TON은 위의 두 가지 문제를 어떻게 해결할 계획인가요?

블록체인 콘텐츠. 작업 체인.

먼저, 블록체인에 무엇이 저장될 예정인지부터 이야기해 보겠습니다. 계정 상태(기본 사례에서는 "지갑")와 스마트 계약이 여기에 저장됩니다(단순화를 위해 이것이 계정과 동일하다고 가정합니다). 본질적으로 이것은 일반 해시 테이블이 될 것입니다. 그 안의 키는 식별자가 됩니다. 계정 ID, 값은 다음과 같은 내용을 포함하는 데이터 구조입니다.

• 밸런스;
• 스마트 계약 코드(스마트 계약에만 해당)
• 스마트 계약 데이터 저장(스마트 계약에만 해당)
• 통계;
• (선택적) 계정에서 전송을 위한 공개 키, 기본적으로 account_id;
• 발신 메시지 대기열(수신자에게 전달하기 위해 여기에 입력됨)
• 이 계정으로 전달된 최신 메시지 목록입니다.

위에서 언급했듯이 블록 자체는 다양한 account_id 계정으로 전달되는 메시지인 트랜잭션으로 구성됩니다. 그러나 account_id 외에도 메시지에는 32비트 필드도 포함됩니다. 작업체인_id - 소위 식별자 작업 체인 (작업 체인, 작동하는 블록체인). 이를 통해 서로 다른 구성으로 서로 독립적인 여러 블록체인을 가질 수 있습니다. 이 경우 workchain_id = 0은 특수한 경우로 간주되며, 제로 워크체인 — TON(Grams) 암호화폐에 해당하는 잔액입니다. 아마도 처음에는 다른 작업 체인이 전혀 존재하지 않을 것입니다.

샤드체인. 무한 샤딩 패러다임.

그러나 블록체인 수의 증가는 여기서 끝나지 않습니다. 샤딩을 다루겠습니다. 각 계정(account_id)에 자체 블록체인이 할당되어 있고 여기에 들어오는 모든 메시지가 포함되어 있으며 이러한 모든 블록체인의 상태가 별도의 노드에 저장되어 있다고 가정해 보겠습니다.

물론 이는 매우 낭비적인 일입니다. 샤드체인 (샤드체인, 샤드 블록체인) 트랜잭션은 매우 드물게 발생하며 강력한 노드가 많이 필요할 것입니다. (앞으로 우리는 휴대폰 클라이언트에 대해서만 이야기하는 것이 아니라 심각한 서버에 대해 이야기하고 있다는 점에 주목합니다.)

따라서 샤드체인은 식별자의 바이너리 접두사로 계정을 결합합니다. 샤드체인의 접두사가 0110이면 이 숫자로 시작하는 모든 account_id의 트랜잭션이 포함됩니다. 이것 샤드_접두사 0에서 60비트까지의 길이를 가질 수 있으며 가장 중요한 것은 동적으로 변경될 수 있다는 것입니다.

샤드체인 중 하나가 너무 많은 트랜잭션을 수신하기 시작하자마자 해당 작업을 수행하는 노드는 미리 결정된 규칙에 따라 이를 두 개의 하위 항목으로 "분할"합니다. 접두사는 0비트 더 길어집니다(그 중 하나의 경우 이 비트는 1과 같고 다른 하나는 - XNUMX). 예를 들어, 샤드_접두사 = 0110b는 다음과 같이 분할됩니다. 01100b 및 01101b. 결과적으로 두 개의 "이웃" 샤드체인이 (한동안) 충분히 편안함을 느끼기 시작하면 다시 병합됩니다.

따라서 샤딩은 "아래에서 위로" 수행됩니다. 각 계정에 자체 샤드가 있다고 가정하지만 당분간은 접두사로 "함께 접착"됩니다. 이것이 의미하는 바입니다 무한 샤딩 패러다임 (무한 샤딩 패러다임).

이와 별도로, 워크체인은 사실상 가상으로만 존재한다는 점을 강조하고 싶습니다. 작업체인_id 이는 특정 샤드체인 식별자의 일부입니다. 공식적으로 각 샤드체인은 숫자 쌍으로 정의됩니다(작업체인_id, 샤드_접두사).

오류 수정. 수직형 블록체인.

전통적으로 블록체인의 모든 거래는 "석이 된" 것으로 간주됩니다. 그러나 TON의 경우 누군가(소위. 어부의 매듭)는 블록 중 하나가 잘못 서명되었음을 증명합니다. 이 경우, 수정 중인 블록 자체의 해시를 포함하는 특수 수정 블록이 해당 샤드체인에 추가됩니다(샤드체인의 마지막 블록이 아님). 샤드체인을 수평으로 배열된 블록 체인으로 생각하면, 수정 블록이 잘못된 블록에 오른쪽이 아닌 위에서 부착된다고 말할 수 있습니다. 따라서 작은 “수직형 블록체인”의 일부가 되는 것으로 간주됩니다. . 따라서 우리는 샤드체인이 다음과 같다고 말할 수 있습니다. XNUMX차원 블록체인.

잘못된 블록 이후 해당 블록에 의해 변경된 내용이 후속 블록에서 참조되는 경우(즉, 잘못된 블록을 기반으로 새 거래가 생성된 경우) 수정 내용도 해당 블록의 "상단"에 추가됩니다. 블록이 "영향을 받는" 정보에 영향을 미치지 않으면 이러한 "수정 파동"은 해당 블록에 적용되지 않습니다. 예를 들어, 위 그림에서 첫 번째 블록의 거래인 C 계좌의 잔액을 늘리는 거래가 잘못된 것으로 인식되었으므로 세 번째 블록에서 이 계좌의 잔액을 줄이는 거래도 취소되어야 하며, 수정 블록이 필요합니다. 블록 자체 위에 커밋되어야 합니다.

수정 블록은 원래 블록 "위"에 있는 것으로 표시되지만 실제로는 해당 블록체인의 끝(연대순으로 있어야 함)에 추가된다는 점에 유의해야 합니다. XNUMX차원 위치는 블록체인의 어느 지점에 "연결"될 것인지만 표시합니다(그 안에 위치한 원래 블록의 해시를 통해).

"과거를 바꾸겠다"는 결정이 얼마나 좋은지에 대해 별도로 철학적으로 생각할 수 있습니다. 샤드체인에 잘못된 블록이 나타날 가능성을 인정한다면, 잘못된 수정 블록이 나타날 가능성도 피할 수 없을 것 같습니다. 여기서 제가 알 수 있는 한, 차이점은 새 블록에 대한 합의에 도달해야 하는 노드 수에 있습니다. 각 샤드체인에서 작업하는 사람의 수는 상대적으로 적습니다."실무그룹» 노드(구성이 자주 변경됨) 및 수정 블록을 도입하려면 모든 사람의 동의가 필요합니다. 검증인 노드. 다음 기사에서는 검증자, 작업 그룹 및 기타 노드 역할에 대해 자세히 설명하겠습니다.

모든 것을 지배하는 하나의 블록체인

위에 나열된 다양한 유형의 블록체인에 대한 많은 정보가 있으며, 이 정보 자체도 어딘가에 저장되어야 합니다. 특히 다음 정보에 대해 이야기하고 있습니다.

• 작업 체인의 수와 구성에 대해
• 샤드체인 수와 접두사에 대해
• 현재 어떤 노드가 어떤 샤드체인을 담당하고 있는지
• 모든 샤드체인에 마지막 블록의 해시가 추가됩니다.

짐작하셨겠지만 이 모든 것들은 또 다른 블록체인 저장소에 기록됩니다. 마스터체인 (마스터체인, 마스터 블록체인). 해당 블록에 있는 모든 샤드체인 블록의 해시가 존재하기 때문에 시스템의 연결성이 높습니다. 이는 무엇보다도 샤드체인에서 블록이 생성된 직후 마스터체인에서 새 블록이 생성된다는 것을 의미합니다. 샤드체인의 블록은 약 5초마다 거의 동시에 나타나고 다음 블록은 샤드체인에서 나타날 것으로 예상됩니다. 마스터체인 - 그로부터 XNUMX초 후.

하지만 메시지 전송, 스마트 계약 실행, 샤드체인과 마스터체인의 블록 형성, 블록 오류 확인까지 이 모든 거대한 작업의 구현을 누가 책임질까요? 이 모든 것이 Telegram 클라이언트가 설치된 수백만 명의 사용자 휴대폰에서 비밀리에 수행됩니까? 아니면 Durov 팀이 분산화 아이디어를 포기하고 서버가 기존 방식으로 이를 수행하게 될까요?

사실 둘 중 어느 쪽도 정답이 아닙니다. 하지만 이 기사의 여백은 빠르게 부족하므로 다음 부분에서는 노드의 다양한 역할(이미 일부에 대해 언급했음을 눈치챘을 수도 있음)과 해당 작업의 메커니즘에 대해 설명하겠습니다.

출처 : habr.com