Sui 창립자의 친필: "버스를 타는 것"을 예로 들어 Sui의 성능 장점을 설명하다
병행 효율화.저자: Mysten Labs CEO이자 공동 창립자 Evan Cheng
출처: https://twitter.com/EvanWeb3/status/1569414553322274818
편집: Azuma, Odaily 별자리 일보
최근 Sui에 대한 해석 기사가 많이 등장했지만, 이들 기사는 대부분 가장 중요한 혁신인 Sui의 데이터 모델 및 거래 처리 경로를 놓치고 있습니다. 저는 다음 트윗에서 이를 세 부분으로 나누어 설명하겠습니다:
Part1: 전통적인 블록체인의 거래 처리 경로
Part2: Sui의 거래 처리 경로
Part3: Sui의 장점
블록체인의 운영 논리는 시간이 지남에 따라 검증자들이 함께 체인에 새로운 블록을 추가하는 것입니다. 거래 처리 경로는 "블록 구축------합의------실행------머클 트리 업데이트"라는 프로세스의 가장 앞부분에 위치하며, 모든 거래는 이 프로세스의 하류로 계속 진행되기 전에 반드시 처리되어야 합니다. 새로운 블록이 구축되기 시작하면 거래 처리는 중단됩니다.
아래는 전통적인 블록체인의 거래 처리 경로 및 그 문제에 대한 개념도입니다. 우리는 많은 프로젝트가 이러한 문제를 해결하기 위해 다양한 방법을 시도하고 있는 것을 보았습니다.
Sui의 접근 방식은 "객체(objects)"를 통해 데이터를 구분하고 조직하는 것입니다. 특정 NFT, 특정 토큰의 잔액, 특정 스마트 계약 등은 모두 서로 다른 객체(유형으로 이해할 수 있음)로, 이는 Sui 체인에서 거래가 객체에 따라 그룹화되어 처리될 수 있음을 의미합니다.
아래 그림은 3그룹으로 나눌 수 있는 5개의 서로 다른 거래를 설명하는 간단한 예입니다(조금 후에 특정 객체와 공유 객체에 대해 다시 이야기하겠습니다). 이 3그룹의 거래는 완전히 병렬 처리될 수 있습니다.
반면 다른 전통적인 블록체인에서는 단일 블록 내의 모든 관련 없는 거래가 순차적으로 처리되어야 합니다. 예를 들어, Bob이 Bruce에게 BAYC NFT를 전송하고, Alice가 Alex에게 Punk NFT를 전송하며, Jane이 특정 DEX를 사용하는 등의 모든 거래는 합의에 따라 집단적으로 정렬되고 실행되며, 최종적으로 머클 트리에 반영됩니다.
비유하자면, 이는 버스를 타는 것과 같습니다. 전통적인 블록체인에서는 모든 승객이 줄을 서서(합의) 탑승해야 하며, 각 승객은 출발 전에 검표(실행)를 받아야 하고, 모두 같은 장소에서 하차(머클 트리 업데이트)해야 합니다. 버스가 다시 비어야만 새로운 승객을 계속 수용할 수 있고, 체인은 계속 진행될 수 있습니다. 반면 Sui에서는 체인이 목적지(객체)에 따라 모든 승객을 그룹화하고, 각 그룹의 승객의 티켓을 병렬로 검사한 후, 서로 다른 차량이 병렬로 목적지로 운송됩니다.
Sui의 혁신은 단순히 거래의 병렬 처리에 그치지 않습니다(이 점에 대해서는 앞으로 더 많은 내용을 공유할 예정입니다). 거래 결과는 실행 후 객체에 제출되며(예: 특정 토큰의 잔액이 10이고, 5를 전송하면 잔액은 5가 남습니다), 이는 미래 거래의 입력(input)으로 즉시 사용될 수 있습니다. Sui는 머클 트리를 새로운 블록의 일부 체크포인트로 사용하며, 일련의 관련 거래가 최종적으로 확정된 후에만 장부에 기록됩니다.
또한 주목해야 할 점은, 앞서 언급한 사례에서 일부 거래는 특정 객체에만 해당합니다. 예를 들어, Bob만이 그가 소유한 BAYC NFT에 대한 거래를 시작할 수 있습니다. 특정 객체 유형의 거래는 합의를 건너뛸 수 있습니다(단지 비잔틴 합의 방송만 필요함), 왜냐하면 소유자가 거래 순서를 확인할 수 있기 때문입니다.
반면, 공유 객체형 거래(예: DEX 스마트 계약)와 같은 다른 유형의 거래는 합의가 필요합니다. 왜냐하면 순서를 결정할 단일 소유자가 없기 때문입니다. 이것이 우리가 Narwhal & Bullshark 합의의 필요성입니다.
간단히 말해, 특정 객체형 거래는 병렬로 실행될 수 있으며, 공유 객체형 거래도 서로 병렬로 실행될 수 있지만, 각 공유 객체는 순차적으로 실행되어야 합니다(여기서 다른 정적/동적 기술이 적용됩니다).
결론적으로, 당신은 다음과 같이 이해할 수 있습니다:
일반적인 블록체인에서는 모든 거래가 집단적으로 정렬된 후 실행되어야 합니다.
Sui에서는 모든 거래가 특정 논리에 따라 구분되고 정리된 후 정렬되어 실행됩니다. 데이터 모델은 서로 다른 거래 간의 의존 관계를 더 명확하게 하며, 공유 객체의 거래만이 집단적으로 정렬될 필요가 있고, 특정 객체의 거래는 이러한 합의 협상 과정을 필요로 하지 않습니다.
그렇다면 Sui의 이러한 구조가 어떤 제품 문제를 해결할 수 있을까요? 계속 살펴보겠습니다.
첫째, 수평 확장 능력입니다. Sui 위에서는 각 그룹의 거래가 병렬 처리되므로, 앞서 언급한 것처럼 각 그룹의 승객이 서로 다른 차량을 타는 것과 같습니다. 따라서 더 많은 그룹의 승객(거래)이 있을 경우, Sui는 더 많은 차량만 추가하면 됩니다. 이 점에서 Sui는 내부 검증자를 통해 샤딩 확장을 할 수 있습니다 ------ 더 많은 작업자가 더 많은 거래를 처리합니다.
왜 수평 확장 능력이 중요한가요? 일부 대형 프로젝트가 기본 구조를 고려할 때의 요구 사항을 생각해 보세요. 그들은 기본 구조가 지속적인 성장 규모를 수용할 수 있도록 보장해야 합니다. 성능 한계가 있는 블록체인은 이러한 프로젝트의 입주를 방해할 수 있으며, Sui의 설계는 이러한 수요 급증에 대응하기 위해 만들어졌습니다.
둘째, 조합 가능성입니다. Sui에서 가능한 것 중 다른 스마트 계약 플랫폼에서는 불가능한 것은 무엇인가요? 예를 들어, 자산을 함수의 매개변수로 전달하거나, 함수에서 특정 자산을 반환하거나, 자산을 데이터 구조 내에 저장하거나, 다른 자산 내에 직접 저장하는 것입니다.
앞으로 조합 가능성에 대한 별도의 트윗을 작성할 가능성이 있습니다. 이는 상당히 복잡한 주제이기 때문입니다. 제가 하고 싶은 말은, Sui는 계약 수준과 자산 수준(서로 다른 유형의 객체가 다른 객체 내에 중첩될 수 있음)에서 조합 가능성을 크게 향상시켰다는 것입니다.
그리고 부분 재생 능력이 있습니다. 블록체인은 모든 거래의 역사 기록을 제공하며, 이는 과거 정보를 확인하는 데 매우 유용합니다. 그러나 특정 제품이 체인 상의 데이터를 신경 써야 할 경우, 읽는 것이 매우 비쌀 수 있습니다. Sui의 구조는 이러한 프로젝트가 관심 있는 객체의 진화에만 집중할 수 있도록 허용합니다. 즉, 부분 재생이 가능합니다.
예를 들어, 모든 캐릭터를 Sui에 배치한 RPG 게임은 이러한 캐릭터를 나타내는 객체를 간단히 관찰할 수 있습니다. 그들은 머클 트리 데이터 구조에서 모든 데이터를 발굴할 필요가 없습니다.
마지막으로 체인 상 저장입니다. 게임의 종족, 레벨, 경험치 등 다양한 자산 데이터는 Sui의 객체 내에 저장될 수 있습니다. Sui는 전통적인 방법을 사용하여 체인 상 저장을 확장할 수 있으며, 현재 체인 상 자산을 업데이트하는 비용이 훨씬 낮아졌습니다.
이 긴 트윗은 여기서 마칩니다. 이러한 내용은 차원은 높지만, 그리 포괄적이지는 않습니다. 그러나 저는 여러분이 이러한 내용을 통해 Sui에 대한 이해를 깊이기를 바랍니다.
