최초의 다중 머신 스마트 계약 실행 엔진인 Pilotfish는 다음을 가능하게 합니다.Sui 네트워크 유효성 검사기는 여러 머신을 사용하고 자동 크기 조정을 사용하여 부하가 증가할 때 더 많은 트랜잭션을 실행합니다. 이는 안정성이나 기능 완성도를 손상시키지 않고 달성됩니다. 

Pilotfish는 내부 실행 머신의 장애를 복구하고 Sui의 전체 동적 작업. 스트리밍 아키텍처는 대기 시간 오버헤드가 매우 낮습니다. Pilotfish와의 통합에 대한 성능 평가 Sui 실행에 8개의 서버를 사용할 때 최대 8배의 처리량 증가를 보여 주어 컴퓨팅 바인딩된 부하에 대한 선형 크기 조정을 보여 줍니다. 

실행의 과제

게으른 블록체인은 트랜잭션 주문(합의)과 실행을 분리하는 유망한 신흥 설계 아키텍처입니다. 이 디자인에서 순서 지정 계층은 트랜잭션을 시퀀싱한 다음 나중에 실행 계층이 트랜잭션 시퀀스를 실행합니다. 이를 통해 최첨단 블록체인 시스템은 Bullshark 및 Hammerhead와 같은 최신 합의 알고리즘을 사용하여 많은 수의 트랜잭션(초당 100,000개 트랜잭션 정도)을 주문할 수 있습니다. 그러나 실행 성능이 뒤처지고 있으며 요즘에는 실행이 병목 현상입니다. 예를 들어 Ethereum 가상 머신은 단순 트랜잭션을 실행할 때 초당 최대 20,000개의 트랜잭션으로 보고 됩니다.

일괄 처리: 대기 시간이 긴 솔루션

실행 병목 현상에 대한 한 가지 해결책은 일괄 처리입니다. 많은 수의 트랜잭션의 배치 또는 블록을 구성하고 실행할 단위로 제출하면 아키텍처에 큰 변경 없이 높은 처리량을 달성할 수 있습니다. 그러나 일괄 처리는 대기 시간이 길어집니다. 일괄 실행의 대기 시간이 수백 밀리초인 것은 드문 일이 아니며, 이는 다음과 같은 대기 시간이 짧은 블록체인에서는 무시할 수 없는 수준입니다 Sui. 

Pilotfish는 이미 채택된 스트림 처리 접근 방식에 따라 수백 밀리초가 아닌 수십 밀리초 범위에서 무시할 수 있는 대기 시간 오버헤드만 도입하면서 높은 처리량을 달성합니다. Sui 다중 코어 실행용.

스케일 업과 스케일 아웃 비교

지연 시간을 낮게 유지하면서 높은 처리량을 달성하는 한 가지 방법은 스케일 업입니다. 단일 시스템에서의 병렬 트랜잭션 실행, 그리고 다음을 포함한 일부 블록체인 Sui, 이 모델을 성공적으로 사용합니다. 큰 아키텍처 변경이 필요하지 않다는 장점이 있습니다. 유효성 검사기는 이미 완전히 단일 시스템에 위치하므로 트랜잭션 인과 관계를 유지하면서 순차적으로 트랜잭션을 실행하는 대신 병렬로 트랜잭션을 실행하는 문제만 있으면 됩니다. 

스케일 업 접근 방식을 사용하면 현재 부하가 현재 기계가 처리할 수 있는 수준을 초과하면 더 강력한 기계로 업그레이드하는 것이 유일한 선택입니다. 그러나 이 솔루션에는 활주로가 제한되어 있습니다. 서버에 들어갈 수 있는 CPU 코어가 너무 많고 RAM이 너무 많습니다. 따라서 부하가 계속 증가하면 결국 단일 기계가 따라잡을 수 있는 범위를 넘어서게 됩니다. 부상에 모욕을 더하면 CPU뿐만 아니라 컴퓨터의 단일 리소스가 소진될 수 있습니다. 현재 유효성 검사기 머신이 현재 로드에 대해 CPU 측면에서 포화 상태가 아니더라도 RAM 용량이 부족하여 느린 영구 스토리지에 의존해야 할 수 있으므로 전체 파이프라인 속도가 느려질 수 있습니다. 마지막으로, 강력한 단일 시스템에 의존하는 것은 블록체인 공간에 비우호적인데, 이는 두툼한 시스템이 드물고 소수의 데이터 센터 제공업체에서만 지원하기 때문입니다. 

Pilotfish가 블록체인 공간에서 개척한 실행 병목 현상을 해결하는 유일한 다른 방법은 여러 시스템에서 분산 트랜잭션 실행을 통해 확장하는 것입니다. 수평 확장 접근 방식의 장점은 무한정 확장할 수 있다는 것입니다. 부하가 현재 시스템 수의 용량을 초과하여 증가하면 더 많은 시스템을 가동할 수 있으므로 기본적으로 용량이 부족하지 않고 중요 경로에서 느리고 지속적인 스토리지에 의존할 필요가 없습니다. 이 접근 방식의 또 다른 장점은 스케일 업 접근 방식과 직교하고 호환된다는 것입니다. 마지막으로, 더 쉬운 탈중앙화를 허용하여 하드웨어 공급자의 "단일 문화"를 방지합니다. 단일 초강력 기계보다 여러 대의 소형 기계에 대한 더 큰 시장이 있습니다.

Pilotfish의 작동 원리

Pilotfish가 트랜잭션 실행을 여러 시스템에 분산하는 방법은 다음과 같습니다. 각 검증자는 내부적으로 세 가지 논리적 역할로 나뉩니다: (1) 합의를 처리하는 Primary, (2) 트랜잭션을 저장하고 실행을 위해 디스패치하는 SequencingWorkers(SW); (3) ExecutionWorkers(EW)는 블록체인 상태를 저장하고 SW에서 수신한 트랜잭션을 실행합니다. 

이러한 각 역할은 항상 단일 컴퓨터인 기본 컴퓨터를 제외하고 하나 이상의 컴퓨터에서 인스턴스화됩니다. 검증자를 구성하는 머신은 서로를 신뢰하므로(동일한 엔터티에 의해 실행됨) 조정하기 위해 무거운 BFT(Byzantine Fault Tolerant) 프로토콜이 필요하지 않습니다. 기본만 다른 노드와 상호 작용할 때 BFT가 필요합니다.

Pilotfish가 확장할 수 있는 것은 SW와 EW가 상태를 샤딩하기 때문입니다. 각 트랜잭션은 단일 SW에 할당되고 각 블록체인 객체는 단일 EW에 할당됩니다. 이는 검증자에게 상태의 다른 하위 집합이 할당되는 유효성 검사기 간 샤딩과 동일하지 않습니다. Pilotfish에서는 모든 검증자에게 전체 상태가 할당되고 샤딩은 많은 머신을 사용하는 각 검증자 내에서 발생합니다.

완벽한 환경에서 각 트랜잭션은 단일 샤드의 오브젝트에만 액세스하므로 트랜잭션 실행을 분산하는 것은 각 트랜잭션을 적절한 EW 샤드로 디스패치하는 것만큼 간단합니다. 그러나 현실 세계에서 트랜잭션은 종종 둘 이상의 샤드에서 객체에 액세스합니다. 이러한 크로스 샤드 트랜잭션을 처리하기 위해 Pilotfish EW는 필요에 따라 오브젝트 데이터를 교환하므로 지정된 트랜잭션을 실행하도록 지정된 EW는 실행을 시작하기 전에 항상 필요한 오브젝트 데이터를 보유합니다.

위의 다이어그램에서 Primary는 다른 검증자의 프라이머리와 상호 작용하여 트랜잭션을 정렬합니다(➊). SW는 프라이머리로부터 트랜잭션 순서 정보를 수신하여 해당 EW로 트랜잭션을 디스패치한다(➋). 위의 예에서 현재 트랜잭션 T는 샤드 EW1 및 EW3의 입력 오브젝트에 액세스하므로 SW는 해당 EW에만 T를 디스패치합니다. 그런 다음 EW1과 EW3은 각각 T와 충돌할 수 있는 다른 트랜잭션에 대해 T를 예약합니다(전체 논문의 스케줄링 알고리즘에 대한 자세한 내용)(➌). T를 실행할 준비가 되면 EW1 및 EW3은 T의 지정된 실행기에 적절한 개체 데이터를 보냅니다(이 경우 지정된 실행기는 EW1이므로 EW3만 개체를 보내면 됨). EW1에 필요한 모든 오브젝트 데이터가 있으면 T(➍)를 실행하고 출력 효과를 모든 EW에 보냅니다. 각 EW는 자신이 소유한 객체(➎)에 로컬 변경 사항을 적용합니다.

추가 기본 정보

이 기본적인 거래 흐름 외에도 전체 백서를 읽고 다음을 알아보세요.

• 충돌하지 않는 트랜잭션의 병렬 실행을 허용하기 위해 트랜잭션을 예약하는 방법.
• 샤드 크래시를 처리하고 복구하는 방법.
• 동적 필드에 대한 읽기 및 쓰기를 활성화하는 방법.

결과 간략히 살펴보기

여기서 우리는 실험 결과를 간략하게 살펴 봅니다. 이 백서에는 실험 설정 및 결과에 대한 자세한 내용이 포함되어 있습니다. 

아래의 대기 시간 대 처리량 그래프에서 각 데이터 요소는 SequencingWorker가 5분 동안 고정된 속도로 트랜잭션을 제출하는 실험적 실행을 나타냅니다. 시스템으로 전송되는 트랜잭션의 부하를 실험적으로 늘리고 실행된 트랜잭션의 중간 처리량과 대기 시간을 기록합니다. 결과적으로, 모든 플롯은 부하가 낮은 모든 시스템의 정상 상태 지연 시간과 해당 시스템이 제공할 수 있는 최대 처리량을 보여주며, 그 이후에는 지연 시간이 빠르게 증가합니다. 대기 시간이 최대 20밀리초 이상으로 증가하는 처리량입니다.

모든 실험에서 트랜잭션은 일괄 처리되지 않고 스트리밍 방식으로 도착하기 때문에 실행을 위해 개별적으로 제출된다는 점을 강조합니다. 이것은 특히 중요합니다. Sui- 빠른 경로 트랜잭션이 인증되는 즉시 합의 커밋에서 일괄 처리되기 전에 비동기적으로 처리합니다. Pilotfish alo는 일괄 처리를 지원하므로 처리량이 크게 증가하지만 (물론) 대기 시간이 길어집니다.

이 첫 번째 워크로드에서 각 트랜잭션은 한 주소에서 다른 주소로 코인을 간단히 전송하는 것입니다. 두 트랜잭션이 충돌하지 않도록 트랜잭션을 생성합니다. 각 트랜잭션은 다른 트랜잭션과 다른 개체 집합에서 작동합니다. 따라서 이 워크로드는 완전히 병렬화할 수 있습니다. 

실행 작업자(EW) 수에 관계없이 Pilotfish는 20밀리초 미만의 낮은 지연 시간 범위를 유지하는 것을 관찰할 수 있습니다. 중요한 것은 더 많은 EW를 추가함에 따라 트랜잭션당 대기 시간이 감소하는 것도 관찰된다는 것입니다. 6-7밀리초의 낮은 대기 시간에서 8개의 EW 구성은 하나의 EW 구성보다 5-6배 더 많은 개별 전송을 처리합니다.

대기 시간은 주로 트랜잭션 대기열의 영향으로 인해 단일 ExecutionWorker에 대한 워크로드가 증가함에 따라 선형적으로 증가합니다. 좀 더 구체적으로 말하자면, 단일 시스템에는 워크로드의 병렬 처리를 완전히 활용하기에 충분한 코어가 없으므로 일부 트랜잭션은 예약될 때까지 기다려야 합니다. 이 효과는 더 많은 수의 ExecutionWorkers에 대해 더 이상 존재하지 않으며, 더 많은 하드웨어를 추가하면 실행 대기 시간을 줄여 서비스 시간에 유익한 영향을 미친다는 것을 보여줍니다.

Pilotfish의 확장성은 이 워크로드에서 완벽하게 선형적이지 않습니다. 특히 처리량의 미미한 향상은 두 개의 ExecutionWorkers 후에 감소합니다. 이는 계산이 간단한 전송 워크로드와 처리량이 계산에 바인딩되지 않기 때문입니다. 따라서 더 많은 CPU 리소스를 추가해도 더 이상 성능이 비례적으로 향상되지 않습니다. 아래 표시된 다음 그래프는 워크로드가 컴퓨팅 바인딩된 경우 ExecutionWorkers 수를 늘릴 경우의 이점을 보여줍니다.

계산 강도의 효과를 설명하기 위해 각 트랜잭션에 몇 가지 합성 계산을 추가합니다. 단순화를 위해 반복 피보나치 계산을 합성 계산으로 사용합니다. 예를 들어, 아래 그래프에서 "Fib-2500"은 각 트랜잭션이 2,500번째 피보나치 수를 계산한다는 것을 의미합니다. 그래프는 Pilotfish의 최대 처리량이 세 가지 수준의 계산 강도(Fib-2500이 가장 낮고 Fib-10000이 가장 높음)에 대한 EW 수에 따라 확장되는 방식을 보여줍니다. 기준으로, 우리는 Sui baseline - 단일 컴퓨터에서 실행되며 추가 하드웨어를 활용할 수 없습니다. 

그래프에서 볼 수 있듯이 이 경우 Pilotfish의 처리량은 사용 가능한 EW 수에 따라 선형적으로 확장되며, 8개의 EW를 사용하면 처리량의 최대 8배까지 확장되며, 이는 이상에 가깝습니다. 

다음 단계는 무엇인가요?

현재 Pilotfish는 지연 시간을 손상시키지 않고 지연 블록체인에서 우수한 스케일 아웃 실행 확장성을 달성하는 것이 가능하다는 것을 보여주는 개념 증명입니다. 특히, 고도로 분산된 실행기는 간단한 전송의 경우에도 실행 대기 시간이 짧고 처리량이 높아진다는 것을 보여줍니다. 또한, 컴퓨팅 집약적인 스마트 컨트랙트의 경우, 더 많은 실행 리소스를 추가함에 따라 처리량이 거의 이상적으로 증가한다는 것을 보여줍니다. 

Pilotfish는 하나의 CPU 바운드 컨트랙트의 실행이 다른 스마트 컨트랙트에 부정적인 영향을 미칠 것이라는 우려 없이 스마트 컨트랙트에서 더 저렴한 계산을 위한 길을 열어줍니다.

다음 반복에서는 둘 이상의 SW, 샤드 복제 및 크래시 복구, 초고속 원격 직접 메모리 액세스 네트워킹에 대한 지원도 구현하고 테스트할 계획입니다. 우리는 이러한 기능을 추가하고 엔지니어링 최적화를 통해 엔드 투 엔드 성능을 개선하여 프로토타입을 개선하기 위해 노력하고 있습니다.