기술 지식이 없는 사람이 분산 시스템에 대해 가장 좋아하는 질문은 "블록체인에 몇 개의 tps가 있습니까?"입니다. 그러나 응답으로 주어진 숫자는 일반적으로 질문자가 듣고 싶어하는 것과 거의 공통점이 없습니다. 실제로 그는 "당신의 블록체인이 내 비즈니스 요구 사항에 맞는지" 묻고 싶었고 이러한 요구 사항은 하나의 숫자가 아니라 많은 조건입니다. 여기에는 네트워크 내결함성, 최종성 요구 사항, 크기, 트랜잭션 특성 및 기타 여러 매개 변수가 있습니다. 따라서 "몇 tps"라는 질문에 대한 대답은 간단하지 않을 가능성이 높으며 거의 완전하지 않습니다. 매우 복잡한 계산을 수행하는 수십 또는 수백 개의 노드가 있는 분산 시스템은 네트워크 상태, 블록체인의 내용, 기술적 오류, 경제적 문제, 네트워크에 대한 공격 및 기타 여러 이유와 관련하여 수많은 다른 상태에 있을 수 있습니다. . 성능 문제가 발생할 수 있는 단계는 기존 서비스와 다르며, 블록체인 네트워크 서버는 데이터베이스, 웹 서버 및 토렌트 클라이언트의 기능을 결합한 네트워크 서비스이므로 모든 하위 시스템의 로드 프로필 측면에서 매우 복잡합니다. : 프로세서, 메모리, 네트워크, 스토리지

분산형 네트워크와 블록체인은 중앙 집중형 소프트웨어 개발자에게 매우 구체적이고 특이한 소프트웨어입니다. 따라서 저는 분산형 네트워크의 성능과 지속 가능성, 이를 측정하고 병목 현상을 찾는 접근 방식의 중요한 측면을 강조하고 싶습니다. 블록체인 사용자에게 서비스 제공 속도를 제한하는 다양한 성능 문제를 살펴보고 이러한 유형의 소프트웨어의 특징을 살펴보겠습니다.

블록체인 클라이언트의 서비스 요청 단계

다소 복잡한 서비스의 품질에 대해 솔직하게 말하려면 평균 값뿐만 아니라 최대/최소, 중앙값, 백분위수도 고려해야 합니다. 이론적으로 일부 블록체인에서는 1000tps에 대해 이야기할 수 있지만, 900개의 트랜잭션이 엄청난 속도로 완료되고 100개가 몇 초 동안 "멈췄다"면 모든 트랜잭션에 대해 수집된 평균 시간은 클라이언트에게 완전히 공정한 측정 기준이 아닙니다. 몇 초 안에 거래를 완료할 수 없었습니다. 합의 라운드 누락이나 네트워크 분할로 인해 발생하는 일시적인 "구멍"은 테스트 벤치에서 뛰어난 성능을 보여준 서비스를 크게 망칠 수 있습니다.

이러한 병목 현상을 식별하려면 실제 블록체인이 사용자에게 서비스를 제공하는 데 어려움을 겪을 수 있는 단계를 잘 이해해야 합니다. 클라이언트가 자신의 트랜잭션이 처리되고 설명되었는지 확인할 수 있는 블록체인의 새로운 상태를 얻는 것뿐만 아니라 트랜잭션을 전달하고 처리하는 주기를 설명하겠습니다.

트랜잭션은 클라이언트에서 형성됩니다.
거래가 클라이언트에서 서명되었습니다.
클라이언트는 노드 중 하나를 선택하고 해당 노드로 트랜잭션을 보냅니다.
클라이언트는 노드의 상태 데이터베이스에 대한 업데이트를 구독하고 트랜잭션 결과가 나타날 때까지 기다립니다.
노드는 p2p 네트워크를 통해 트랜잭션을 배포합니다.
여러 개 또는 하나의 BP(블록 생산자)가 누적된 트랜잭션을 처리하여 상태 데이터베이스를 업데이트합니다.
BP는 필요한 트랜잭션 수를 처리한 후 새로운 블록을 형성합니다.
BP는 p2p 네트워크를 통해 새로운 블록을 배포합니다.
새 블록은 클라이언트가 액세스하는 노드로 전달됩니다.
노드 업데이트 상태 데이터베이스
노드는 클라이언트에 관한 업데이트를 보고 그에게 트랜잭션 알림을 보냅니다.

이제 이러한 단계를 자세히 살펴보고 각 단계에서 잠재적인 성능 문제를 설명하겠습니다. 중앙 집중식 시스템과 달리 네트워크 클라이언트에서의 코드 실행도 고려할 것입니다. TPS를 측정할 때 트랜잭션 처리 시간은 클라이언트가 아닌 노드에서 수집되는 경우가 많습니다. 이는 완전히 공평하지 않습니다. 클라이언트는 노드가 자신의 거래를 얼마나 빨리 처리하는지 신경 쓰지 않으며, 그에게 가장 중요한 것은 블록체인에 포함된 이 거래에 대한 신뢰할 수 있는 정보를 사용할 수 있게 되는 순간입니다. 본질적으로 트랜잭션 실행 시간이 바로 이 측정항목입니다. 이는 동일한 트랜잭션을 전송하더라도 서로 다른 클라이언트가 채널, 로드 및 노드의 근접성에 따라 완전히 다른 시간을 수신할 수 있음을 의미합니다. 따라서 클라이언트에서 이 시간을 측정하는 것이 절대적으로 필요합니다. 이것이 최적화되어야 하는 매개변수이기 때문입니다.

클라이언트 측에서 트랜잭션 준비

처음 두 가지 사항부터 시작해 보겠습니다. 트랜잭션은 클라이언트에 의해 형성되고 서명됩니다. 이상하게도 이는 클라이언트의 관점에서 볼 때 블록체인 성능의 병목 현상이 될 수도 있습니다. 이는 모든 계산과 작업을 데이터로 처리하는 중앙 집중식 서비스에서는 이례적이며, 클라이언트는 단순히 대량의 데이터나 계산을 요청할 수 있는 짧은 요청을 준비하여 기성 결과를 얻습니다. 블록체인에서 클라이언트 코드는 점점 더 강력해지고, 블록체인 코어는 점점 더 가벼워지며, 일반적으로 대규모 컴퓨팅 작업이 클라이언트 소프트웨어로 이전됩니다. 블록체인에는 꽤 오랜 시간 동안 하나의 거래를 준비할 수 있는 클라이언트가 있습니다(다양한 머클 증명, 간결한 증명, 임계값 서명 및 클라이언트 측의 기타 복잡한 작업에 대해 이야기하고 있습니다). 손쉬운 온체인 검증과 클라이언트의 거래에 대한 철저한 준비의 좋은 예는 Merkle-tree를 기반으로 한 목록의 멤버십 증명입니다. 기사.

또한 클라이언트 코드는 단순히 트랜잭션을 블록체인에 보내는 것이 아니라 먼저 블록체인의 상태를 쿼리한다는 점을 잊지 마세요. 이 활동은 네트워크와 블록체인 노드의 정체에 영향을 미칠 수 있습니다. 따라서 측정을 수행할 때 클라이언트 코드의 동작을 최대한 완벽하게 에뮬레이트하는 것이 합리적입니다. 블록체인에 일부 자산을 전송하기 위해 가장 간단한 거래에 일반 디지털 서명을 하는 일반 라이트 클라이언트가 있더라도 매년 클라이언트에 대한 더 많은 계산이 이루어지고 암호화 알고리즘은 점점 더 강력해지고 있으며 이 처리 부분은 다음과 같은 작업을 수행할 수 있습니다. 앞으로 심각한 병목 현상이 발생합니다. 따라서 3.5초 동안 지속되는 트랜잭션에서 트랜잭션 준비 및 서명에 2.5초, 네트워크로 전송하고 응답을 기다리는 데 1.0초가 소요되는 상황을 놓치지 않도록 주의하세요. 이 병목 현상의 위험을 평가하려면 블록체인 노드뿐만 아니라 클라이언트 시스템에서 지표를 수집해야 합니다.

트랜잭션 보내기 및 상태 모니터링

다음 단계는 선택한 블록체인 노드로 트랜잭션을 보내고 트랜잭션 풀에 수락된 상태를 받는 것입니다. 이 단계는 일반 데이터베이스 액세스와 유사합니다. 노드는 풀에 트랜잭션을 기록하고 p2p 네트워크를 통해 이에 대한 정보 배포를 시작해야 합니다. 여기에서 성능을 평가하는 접근 방식은 기존 웹 API 마이크로서비스의 성능을 평가하는 것과 유사하며, 블록체인의 트랜잭션 자체를 업데이트하고 상태를 적극적으로 변경할 수 있습니다. 일반적으로 일부 블록체인의 거래 정보 업데이트는 체인 포크 간 전환이나 BP가 블록에 거래를 포함하겠다는 의사를 발표할 때와 같이 여러 번 발생할 수 있습니다. 이 풀의 크기와 트랜잭션 수에 대한 제한은 블록체인 성능에 영향을 미칠 수 있습니다. 트랜잭션 풀이 가능한 최대 크기까지 채워지거나 RAM에 맞지 않으면 네트워크 성능이 급격히 떨어질 수 있습니다. 블록체인에는 대량의 정크 메시지로부터 보호할 수 있는 중앙 집중식 수단이 없으며, 블록체인이 대량 거래와 낮은 수수료를 지원하는 경우 거래 풀이 오버플로될 수 있습니다. 이는 또 다른 잠재적인 성능 병목 현상입니다.

블록체인에서 클라이언트는 자신이 좋아하는 블록체인 노드에 트랜잭션을 보내고, 트랜잭션의 해시는 일반적으로 보내기 전에 클라이언트에게 알려지므로 클라이언트가 해야 할 일은 연결을 달성하고 전송 후 블록체인이 변경될 때까지 기다리는 것뿐입니다. 그의 거래를 가능하게 하는 상태입니다. "tps"를 측정하면 블록체인 노드에 연결하는 다양한 방법에 대해 완전히 다른 결과를 얻을 수 있습니다. 이는 "구독" 패턴을 구현할 수 있는 일반 HTTP RPC 또는 WebSocket일 수 있습니다. 두 번째 경우, 클라이언트는 더 일찍 알림을 받게 되며 노드는 트랜잭션 상태에 대한 응답에 더 적은 리소스(주로 메모리 및 트래픽)를 사용하게 됩니다. 따라서 "tps"를 측정할 때는 클라이언트가 노드에 연결하는 방식을 고려해야 합니다. 따라서 이러한 병목 현상의 위험을 평가하려면 벤치마크 블록체인은 WebSocket 및 HTTP RPC 요청을 모두 사용하여 실제 네트워크에 해당하는 비율로 클라이언트를 에뮬레이션하고 트랜잭션의 성격과 크기를 변경할 수 있어야 합니다.

이 병목 현상의 위험을 평가하려면 블록체인 노드뿐만 아니라 클라이언트 시스템에서도 지표를 수집해야 합니다.

P2P 네트워크를 통한 트랜잭션 및 블록 전송

블록체인에서는 P2P(Peer-to-Peer) 네트워킹을 사용하여 참가자 간에 트랜잭션과 블록을 전송합니다. 트랜잭션은 노드 중 하나에서 시작하여 피어 블록 생산자에게 도달할 때까지 네트워크 전체로 확산됩니다. 피어 블록 생산자는 트랜잭션을 블록으로 묶고 동일한 p2p를 사용하여 새 블록을 모든 네트워크 노드에 배포합니다. 가장 현대적인 p2p 네트워크의 기본은 Kademlia 프로토콜의 다양한 수정입니다. 여기에 이 프로토콜에 대한 좋은 요약 여기에 - BitTorrent 네트워크의 다양한 측정값이 포함된 기사를 통해 이러한 유형의 네트워크가 중앙 집중식 서비스의 엄격하게 구성된 네트워크보다 더 복잡하고 예측하기 어렵다는 것을 이해할 수 있습니다. 또한, 여기에 Ethereum 노드에 대한 다양하고 흥미로운 지표를 측정하는 방법에 대한 기사입니다.

간단히 말해서, 이러한 네트워크의 각 피어는 콘텐츠로 처리되는 정보 블록을 요청하는 다른 피어의 자체 동적 목록을 유지 관리합니다. 피어가 요청을 받으면 필요한 정보를 제공하거나 목록에서 다음 의사 난수 피어에게 요청을 전달하고 응답을 받은 후 요청자에게 전달하고 잠시 동안 캐시하여 다음과 같은 결과를 제공합니다. 다음번에는 더 일찍 정보를 차단하세요. 따라서 인기 있는 정보는 다수의 피어의 다수의 캐시에 쌓이게 되고, 인기 없는 정보는 점차적으로 대체됩니다. 피어는 누가 누구에게 얼마나 많은 정보를 전송했는지 기록을 유지하며 네트워크는 등급을 높이고 더 높은 수준의 서비스를 제공하여 활성 배포자를 자극하려고 시도하며 비활성 참가자를 피어 목록에서 자동으로 대체합니다.

따라서 이제 트랜잭션은 블록 생산자가 이를 보고 블록에 포함할 수 있도록 네트워크 전체에 분산되어야 합니다. 노드는 새로운 트랜잭션을 모든 사람에게 적극적으로 "배포"하고 네트워크를 수신하며 대기 중인 클라이언트에게 알리기 위해 필요한 트랜잭션이 나타날 인덱스의 블록을 기다립니다. 네트워크가 p2p 네트워크에서 새로운 트랜잭션과 블록에 대한 정보를 서로 전송하는 데 걸리는 시간은 매우 많은 요인에 따라 달라집니다. 이러한 노드의 캐시, 블록 크기, 트랜잭션, 변경 성격, 네트워크 지리, 노드 수 및 기타 여러 요인에 따라 달라집니다. 이러한 네트워크에서 성능 지표를 복잡하게 측정하는 것은 복잡한 문제이므로 클라이언트와 피어(블록체인 노드) 모두에서 요청 처리 시간을 동시에 평가해야 합니다. p2p 메커니즘의 문제, 잘못된 데이터 제거 및 캐싱, 활성 피어 목록의 비효율적인 관리 및 기타 여러 요인으로 인해 전체 네트워크의 효율성에 영향을 미치는 지연이 발생할 수 있으며 이 병목 현상은 분석하기 가장 어렵습니다. , 테스트 및 결과 해석.

블록체인 처리 및 상태 데이터베이스 업데이트

블록체인의 가장 중요한 부분은 합의 알고리즘, 네트워크에서 수신된 새 블록에 적용, 상태 데이터베이스에 결과 기록을 통한 트랜잭션 처리입니다. 체인에 새 블록을 추가한 다음 메인 체인을 선택하면 최대한 빨리 작동해야 합니다. 그러나 실제 생활에서 "해야 한다"는 것이 "작동한다"는 의미는 아니며, 예를 들어 두 개의 긴 경쟁 체인이 끊임없이 서로 전환하여 각 스위치에서 풀에 있는 수천 개의 트랜잭션의 메타데이터를 변경하는 상황을 상상할 수 있습니다. , 상태 데이터베이스를 지속적으로 롤백합니다. 병목 현상을 정의하는 측면에서 이 단계는 p2p 네트워크 계층보다 간단합니다. 트랜잭션 실행 및 합의 알고리즘은 엄격하게 결정적이므로 여기에서 무엇이든 측정하는 것이 더 쉽습니다.
가장 중요한 것은 이 단계의 성능 저하를 네트워크 문제와 혼동하지 않는 것입니다. 노드는 메인 체인에 대한 블록 및 정보를 전달하는 속도가 느리고 외부 클라이언트의 경우 이는 느린 네트워크처럼 보일 수 있지만 문제는 다음과 같습니다. 완전히 다른 곳.

이 단계에서 성능을 최적화하려면 노드 자체에서 메트릭을 수집 및 모니터링하고 상태 데이터베이스 업데이트와 관련된 메트릭(노드에서 처리된 블록 수, 크기, 트랜잭션 수 등)을 포함하는 것이 유용합니다. 체인 포크 간 스위치 수, 유효하지 않은 블록 수, 가상 머신 작동 시간, 데이터 커밋 시간 등 이렇게 하면 네트워크 문제가 체인 처리 알고리즘의 오류와 혼동되는 것을 방지할 수 있습니다.

트랜잭션을 처리하는 가상 머신은 블록체인의 운영을 최적화할 수 있는 유용한 정보 소스가 될 수 있습니다. 메모리 할당 수, 읽기/쓰기 명령 수, 계약 코드 실행 효율성과 관련된 기타 지표는 개발자에게 많은 유용한 정보를 제공할 수 있습니다. 동시에 스마트 계약은 프로그램이므로 이론적으로 CPU/메모리/네트워크/스토리지 등 모든 리소스를 소비할 수 있으므로 트랜잭션 처리는 다소 불확실한 단계이며 버전 간 이동 시 크게 변경됩니다. 그리고 계약 코드를 변경할 때. 따라서 블록체인 성능을 효과적으로 최적화하려면 트랜잭션 처리와 관련된 메트릭도 필요합니다.

블록체인에 거래가 포함된다는 알림을 클라이언트로부터 수신

이는 블록체인 클라이언트가 서비스를 받는 마지막 단계로, 다른 단계에 비해 간접비가 크지 않으나, 클라이언트가 노드로부터 대량의 응답(예: 스마트 컨트랙트)을 받을 가능성도 고려해 볼 만하다. 데이터 배열을 반환합니다). 어쨌든, “당신의 블록체인에는 몇 개의 tps가 있습니까?”라는 질문을 한 사람에게는 이 점이 가장 중요합니다. 이때 서비스를 받은 시간이 기록됩니다.

이 곳에서는 항상 클라이언트가 블록체인의 응답을 기다리는 데 소비해야 했던 전체 시간이 전송됩니다. 이때 사용자는 자신의 애플리케이션에 대한 확인을 기다립니다. 개발자의 주요 임무.

결론

결과적으로 우리는 블록체인에서 수행되는 작업 유형을 설명하고 여러 범주로 나눌 수 있습니다.

암호화 변환, 증명 구성
PXNUMXP 네트워킹, 트랜잭션 및 블록 복제
거래 처리, 스마트 계약 실행
블록체인의 변경 사항을 상태 데이터베이스에 적용하고, 트랜잭션 및 블록에 대한 데이터를 업데이트합니다.
상태 데이터베이스, 블록체인 노드 API, 구독 서비스에 대한 읽기 전용 요청

일반적으로 최신 블록체인 노드에 대한 기술적 요구 사항은 매우 심각합니다. 즉, 암호화를 위한 빠른 CPU, 상태 데이터베이스를 저장하고 빠르게 액세스하기 위한 대용량 RAM, 동시에 열려 있는 다수의 연결을 사용하는 네트워크 상호 작용 및 대용량 저장소입니다. 이러한 높은 요구 사항과 다양한 유형의 작업으로 인해 필연적으로 노드에 충분한 리소스가 부족할 수 있으며 위에서 설명한 단계 중 하나가 전체 네트워크 성능에 또 다른 병목 현상이 될 수 있습니다.

블록체인의 성능을 설계하고 평가할 때 이러한 모든 사항을 고려해야 합니다. 이를 위해서는 클라이언트와 네트워크 노드에서 지표를 동시에 수집 및 분석하고, 이들 사이의 상관 관계를 찾고, 클라이언트에 서비스를 제공하는 데 걸리는 시간을 추정하고, 모든 주요 리소스인 CPU/메모리/네트워크/스토리지를 고려해야 합니다. , 그들이 어떻게 사용되는지 이해하고 서로 영향을 미칩니다. 이 모든 것은 엄청나게 많은 구성과 상태가 있기 때문에 "TPS 수"라는 형태로 다양한 블록체인의 속도를 비교하는 것을 매우 감사할 일이 아닌 작업으로 만듭니다. 수백 대의 서버로 구성된 클러스터인 대규모 중앙 집중식 시스템에서는 이러한 문제도 복잡하고 다양한 측정 항목을 많이 수집해야 하지만 블록체인에서는 p2p 네트워크, 가상 머신 처리 계약, 내부 경제, 학위 수로 인해 자유도가 훨씬 커서 여러 서버에서도 테스트가 가능하지만 지표가 아니며 현실과 거의 관련이 없는 극히 대략적인 값만 표시합니다.

따라서 블록체인 코어에서 개발할 때 성능을 평가하고 "지난번에 비해 개선되었습니까?"라는 질문에 대답하기 위해 우리는 수십 개의 노드로 블록체인의 출시를 조율하고 자동으로 벤치마크를 시작하고 지표를 수집하는 매우 복잡한 소프트웨어를 사용합니다. ; 이 정보가 없으면 여러 참가자와 함께 작동하는 프로토콜을 디버깅하는 것이 매우 어렵습니다.

따라서 "블록체인에 몇 개의 TPS가 있습니까?"라는 질문을 받으면 대화 상대에게 차를 제공하고 XNUMX개의 그래프를 볼 준비가 되었는지 물어보고 블록체인 성능 문제에 대한 세 가지 상자와 제안 사항을 모두 들어보십시오. 그것들을 해결하다...

출처 : habr.com

귀하의 블록체인에는 몇 개의 TPS가 있습니까?