A16z: 블록체인 성능을 측정하기 어려운 이유는 무엇입니까?

원본: https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

조셉 보노

성능과 확장성은 레이어 1 프로젝트(독립형 블록체인)와 롤업 및 오프체인 채널과 같은 레이어 2 솔루션 모두와 관련하여 암호화 공간에서 많이 논의되는 과제입니다. 그러나 표준화된 메트릭이나 벤치마크가 없습니다. 숫자는 종종 일관성이 없고 불완전하게 보고되어 프로젝트의 정확한 비교를 어렵게 만들고 실제로 가장 중요한 것을 모호하게 만듭니다.

우리는 성능을 측정하고 비교하기 위해 보다 세분화되고 철저한 접근 방식이 필요합니다. 즉, 성능을 구성 요소로 분류하고 여러 축을 따라 절충점과 비교하는 접근 방식입니다. 이 게시물에서는 블록체인 성능을 평가할 때 염두에 두어야 할 기본 용어를 정의하고 과제를 설명하며 지침과 핵심 원칙을 제공합니다.

확장성 및 성능

먼저 표준 컴퓨터 과학 의미를 가지며 블록체인 맥락에서 종종 오용되는 확장성과 성능이라는 두 가지 용어를 정의해 보겠습니다. 성능은 시스템이 현재 달성할 수 있는 것을 측정합니다. 아래에서 논의하겠지만 성능 메트릭에는 초당 트랜잭션 또는 중간 트랜잭션 확인 시간이 포함될 수 있습니다. 반면에 확장성은 리소스를 추가하여 성능을 향상시키는 시스템의 능력을 측정합니다.

이 구별은 중요합니다. 잘 정의된 경우 성능을 개선하는 많은 방법은 확장성을 전혀 개선하지 않습니다. 간단한 예는 Schnorr 또는 ECDSA 서명 크기의 약 절반인 BLS 서명과 같은 보다 효율적인 디지털 서명 체계를 사용하는 것입니다. 비트코인이 ECDSA에서 BLS로 전환되면 블록당 트랜잭션 수가 20-30% 증가하여 하룻밤 사이에 성능이 향상될 수 있습니다. 그러나 이 작업은 한 번만 수행할 수 있습니다. 더 이상 전환할 공간 효율적인 서명 체계가 없습니다(더 많은 공간을 절약하기 위해 BLS 서명을 집계할 수도 있지만 이는 일회성 트릭입니다).

다른 많은 일회성 트릭(예: 분리된 증인)은 블록체인에서 가능하지만 지속적인 성능 향상을 달성하려면 확장 가능한 아키텍처가 필요합니다. 여기서 더 많은 리소스를 추가하면 시간이 지남에 따라 성능이 향상됩니다. 이것은 또한 웹 서버 구축과 같은 다른 많은 컴퓨터 시스템의 일반적인 통념입니다. 몇 가지 일반적인 트릭을 사용하면 매우 빠른 서버를 구축할 수 있지만 궁극적으로 증가하는 수요를 충족하기 위해 추가 서버를 계속 추가하는 다중 서버 아키텍처가 필요합니다.

이 구분을 이해하면 "블록체인 X는 확장성이 뛰어나며 초당 Y 트랜잭션을 처리할 수 있습니다!"와 같은 문장에서 발견되는 일반적인 클래스 오류를 피하는 데 도움이 됩니다. 두 번째 진술은 인상적일 수 있지만 확장성 메트릭이 아니라 성능 메트릭입니다. 리소스를 추가하여 성능을 높이는 기능은 고려하지 않습니다.

확장성은 본질적으로 병렬성을 이용해야 합니다. 블록체인 공간에서 계층 1 확장에는 샤딩 또는 샤딩처럼 보이는 것이 필요한 것 같습니다. 샤딩의 기본 개념(상태를 여러 검증자가 독립적으로 처리할 수 있도록 청크로 분할)은 확장성의 정의와 잘 맞습니다. 레이어 2에는 오프체인 채널, 롤업 서버 및 사이드체인을 포함하여 병렬 처리를 추가할 수 있는 더 많은 옵션이 있습니다.

대기 시간 대 처리량

전통적으로 블록체인 시스템 성능은 대기 시간과 처리량이라는 두 가지 차원으로 평가됩니다. 대기 시간은 개별 트랜잭션을 얼마나 빨리 확인할 수 있는지를 측정하는 반면 처리량은 시간 경과에 따른 총 트랜잭션 속도를 측정합니다. 이러한 축은 계층 1 및 계층 2 시스템뿐만 아니라 데이터베이스 쿼리 엔진 및 웹 서버와 같은 다른 많은 유형의 컴퓨터 시스템에 적용됩니다.

불행히도 대기 시간과 처리량은 모두 측정하고 비교하기 어렵습니다. 또한 개별 사용자는 처리량에 대해 별로 신경 쓰지 않습니다(시스템 전체 측정). 그들이 정말로 관심을 갖는 것은 대기 시간과 거래 수수료입니다. 보다 구체적으로는 거래가 가능한 한 빠르고 가능한 한 저렴하게 확인되는 것입니다. 다른 많은 컴퓨터 시스템도 비용/성능 기준으로 평가되지만 거래 수수료는 기존 컴퓨터 시스템에는 존재하지 않는 블록체인 시스템의 새로운 성능 축을 나타냅니다.

대기 시간 측정의 과제

지연은 처음에는 간단해 보입니다. 트랜잭션이 확인되는 데 얼마나 걸립니까? 하지만 이 질문에 대답하는 방법에는 항상 여러 가지가 있습니다.

첫째, 서로 다른 시점 사이의 지연을 측정하고 다른 결과를 얻을 수 있습니다. 예를 들어 사용자가 로컬 "제출" 버튼을 누를 때 또는 트랜잭션이 mempool에 도달할 때 대기 시간 측정을 시작합니까? 트랜잭션이 제안된 블록에 있을 때 또는 블록이 하나 또는 여섯 개의 후속 블록에 의해 확인될 때 시계를 중지합니까?

이를 측정하는 가장 일반적인 방법은 유효성 검사기의 관점에서 클라이언트가 거래를 처음 브로드캐스트하는 시간부터 합리적으로 "확인"(실제 판매자가 지불을 받고 항목을 보내는 것을 고려한다는 의미에서)할 때까지입니다. 물론 가맹점마다 수용 기준이 다를 수 있으며, 단일 가맹점이라도 거래 금액에 따라 기준이 다를 수 있습니다.

유효성 검사기 중심 접근 방식은 실제로 중요한 몇 가지 사항을 무시합니다. 첫째, P2P 네트워크의 대기 시간(대부분의 노드가 들을 때까지 클라이언트가 트랜잭션을 브로드캐스트하는 데 얼마나 걸립니까?) 및 클라이언트 측 대기 시간(트랜잭션이 처리되는 데 걸리는 시간)을 무시합니다. 클라이언트의 로컬 컴퓨터에서 준비해야 합니까?). 이더리움 결제 서명과 같은 간단한 트랜잭션의 경우 클라이언트 측 대기 시간은 매우 작고 예측 가능할 수 있지만 차폐된 Zcash 트랜잭션이 올바른지 증명하는 것과 같은 보다 복잡한 경우에는 중요할 수 있습니다.

대기 시간으로 측정하려는 시간 창을 정규화하더라도 대답은 거의 항상 그것에 달려 있습니다. 고정 트랜잭션 대기 시간을 제공하는 암호 화폐 시스템은 없었습니다. 기억해야 할 기본 규칙은 다음과 같습니다.

대기 시간은 숫자가 아니라 분포입니다.

네트워크 연구 커뮤니티는 오랫동안 이것을 이해해 왔습니다. 트랜잭션(또는 웹 서버 쿼리)의 0.1%라도 높은 대기 시간이 최종 사용자에게 심각한 영향을 미칠 수 있으므로 분포의 "롱테일"에 특히 중점을 둡니다.

블록체인에서 확인 지연은 여러 가지 이유로 달라질 수 있습니다.

일괄 처리: 대부분의 레이어 1 시스템의 블록과 같은 대부분의 시스템 일괄 처리 트랜잭션입니다. 이로 인해 일부 트랜잭션은 일괄 처리가 채워질 때까지 대기해야 하므로 가변 대기 시간이 발생합니다. 다른 사람들은 운이 좋아 마지막에 배치에 합류할 수 있습니다. 이러한 거래는 추가 지연 없이 즉시 확인됩니다.

가변 정체: 대부분의 시스템은 정체를 겪고 있습니다. 이는 시스템이 한 번에 처리할 수 있는 것보다 처리해야 할 트랜잭션이 (적어도 일부는) 더 많다는 것을 의미합니다. 혼잡 수준은 트랜잭션이 예측할 수 없는 시간에 방송되거나(종종 푸아송 프로세스로 추상화됨) 새로운 트랜잭션 비율이 하루 또는 일주일 동안 변경되거나 인기 있는 NFT 발행과 같은 외부 이벤트에 대한 응답으로 증가할 수 있습니다. .

합의 레이어 차이점: 레이어 1에서 트랜잭션을 확인하려면 일반적으로 블록에 대한 합의에 도달하기 위해 분산된 노드 세트가 필요하며, 이는 혼잡의 영향을 받지 않고 가변 대기 시간을 추가할 수 있습니다. 작업 증명 시스템은 예측할 수 없는 시간에 블록을 발견합니다(포아송 프로세스로도 추상화됨). 지분 증명 시스템은 또한 다양한 지연을 추가할 수 있습니다(예: 라운드에서 위원회를 구성하기에 온라인 노드가 충분하지 않거나 리더 충돌에 대한 응답으로 보기를 변경해야 하는 경우).

이러한 이유로 좋은 지침은 다음과 같습니다.

대기 시간에 대한 설명은 평균이나 중앙값과 같은 단일 숫자가 아니라 확인 시간의 분포(또는 히스토그램)를 나타내야 합니다.

평균, 중앙값 또는 백분위수와 같은 요약 통계는 그림의 일부를 제공하지만 시스템을 정확하게 평가하려면 전체 분포를 고려해야 합니다. 일부 애플리케이션에서 평균 대기 시간은 대기 시간 분포가 상대적으로 단순할 경우(예: 가우시안) 좋은 통찰력을 제공할 수 있습니다. 그러나 암호 화폐에서는 거의 그렇지 않습니다. 일반적으로 확인 시간이 매우 깁니다.

라이트닝 네트워크와 같은 결제 채널 네트워크가 좋은 예입니다. 기존의 L2 확장 솔루션으로서 이러한 네트워크는 대부분의 경우 매우 빠른 결제 확인을 제공하지만 때로는 채널 재설정이 필요하여 지연 시간이 크게 증가할 수 있습니다.

정확한 대기 시간 분포에 대한 좋은 통계가 있더라도 시스템 및 시스템 요구 사항이 변경됨에 따라 시간이 지남에 따라 달라질 수 있습니다. 또한 경쟁 시스템 간의 대기 시간 분포를 비교하는 방법이 항상 명확한 것은 아닙니다. 예를 들어 1~2분(평균 및 중앙값 90초)의 대기 시간이 균일하게 분산된 트랜잭션을 확인하는 시스템을 생각해 보십시오. 경쟁 시스템이 1분 이내에 거래의 95%를 정확하게 확인하고 나머지 5%를 11분(평균 90초, 중앙값 60초) 이내에 정확하게 확인한다면 어떤 시스템이 더 좋을까요? 대답은 일부 앱은 전자를 선호하고 일부는 후자를 선호한다는 것입니다.

마지막으로, 대부분의 시스템에서 모든 트랜잭션이 동일한 우선 순위를 갖는 것은 아니라는 점에 유의해야 합니다. 사용자는 더 높은 포함 우선 순위를 얻기 위해 더 많은 비용을 지불할 수 있으므로 위의 모든 항목 외에도 지불된 거래 수수료에 따라 대기 시간이 달라집니다. 요컨대:

대기 시간은 복잡합니다. 보고된 데이터가 많을수록 좋습니다. 이상적으로는 완전한 지연 프로파일이 서로 다른 혼잡 조건에서 측정되어야 합니다. 대기 시간을 여러 구성 요소(로컬, 네트워크, 배치, 합의 대기 시간)로 나누는 것도 도움이 됩니다.

처리량 측정의 과제

처리량도 언뜻 보기에는 간단해 보입니다. 시스템이 처리할 수 있는 초당 트랜잭션 수는 얼마입니까? 두 가지 주요 어려움이 발생합니다. 정확히 "트랜잭션"이란 무엇이며 오늘날 시스템이 수행하는 작업 또는 수행할 수 있는 작업을 측정하고 있습니까?

"초당 거래 수"(tps)는 사실상 블록체인 성능의 척도이지만 측정 단위로서의 거래는 문제가 있습니다. 일반적인 프로그래밍 가능성("스마트 계약") 또는 비트코인의 다중 트랜잭션 또는 다중 서명 검증 옵션과 같은 제한된 기능을 제공하는 시스템의 경우 근본적인 질문은 다음과 같습니다.

모든 거래가 동일하게 생성되는 것은 아닙니다.

이것은 트랜잭션이 임의의 코드를 포함하고 상태를 임의로 수정할 수 있는 이더리움에서 분명히 사실입니다. 이더리움의 가스 개념은 트랜잭션의 총 작업을 정량화(및 수수료 부과)하는 데 사용되지만 이는 EVM 실행 환경과 매우 관련이 있습니다. BPF 환경을 사용하는 솔라나 트랜잭션 세트와 EVM 트랜잭션 세트가 수행한 총 작업량을 쉽게 비교할 수 있는 방법은 없습니다. 이들 중 하나를 일련의 비트코인 거래와 비교하는 것도 마찬가지로 걱정스러운 일입니다.

트랜잭션 레이어를 합의 레이어와 실행 레이어로 분리하는 블록체인은 이를 더 명확하게 할 수 있습니다. (순수한) 합의 계층에서 처리량은 단위 시간당 체인에 추가된 바이트로 측정할 수 있습니다. 실행 계층은 항상 더 복잡합니다.

결제 거래만 지원하는 롤업 서버와 같은 간단한 실행 계층은 정량적 계산의 어려움을 피합니다. 그러나 이 경우에도 지급되는 인풋과 아웃풋의 금액은 다를 것이다. 결제 채널 트랜잭션에 필요한 "홉" 수는 다양할 수 있으며 이는 처리량에 영향을 미칩니다. 롤업 서버의 처리량은 트랜잭션 배치가 더 작은 집합 변경으로 "분할"될 수 있는 정도에 따라 달라질 수 있습니다.

처리량과 관련된 또 다른 문제는 이론적 용량을 평가하기 위해 오늘날의 성능을 경험적으로 측정하는 것 이상입니다. 이는 잠재적 용량을 평가하기 위한 다양한 모델링 문제를 소개합니다. 먼저 실행 계층에서 실제 트랜잭션 워크로드를 결정해야 합니다. 둘째, 실제 시스템, 특히 블록체인 시스템은 이론적 용량에 거의 도달하지 못합니다. 견고성을 이유로 우리는 노드 구현이 실질적으로 이질적이고 다양하기를 원합니다(단일 소프트웨어 구현을 실행하는 모든 클라이언트와 반대). 이로 인해 블록체인 처리량의 정확한 시뮬레이션이 더 어려워집니다.

전반적인:

처리량 클레임에는 트랜잭션 워크로드 및 유효성 검사기 수(해당 수, 구현 및 네트워크 연결)에 대한 신중한 설명이 필요합니다. 명확한 표준이 없는 경우 Ethereum과 같은 인기 있는 네트워크의 과거 워크로드로 충분합니다.

대기 시간 처리량 절충

대기 시간과 처리량은 종종 트레이드 오프입니다. Lefteris Kokoris-Kogias가 지적한 바와 같이 시스템 부하가 최대 처리량에 도달함에 따라 대기 시간이 급격히 증가하여 이러한 절충이 원활하지 않은 경우가 많습니다.

영지식 롤업 시스템은 처리량/지연 시간 절충의 자연스러운 예를 제공합니다. 대량의 거래 배치는 증명 시간과 대기 시간을 증가시킵니다. 그러나 증명 크기 및 검증 비용 측면에서 온체인 풋프린트는 더 큰 배치의 더 많은 거래에서 상각되어 처리량이 증가합니다.

거래 수수료

최종 사용자는 당연히 대기 시간과 처리량보다 대기 시간과 비용 간의 균형에 더 관심이 있습니다. 사용자는 처리량에 대해 전혀 관심을 가질 직접적인 이유가 없으며 가능한 가장 낮은 수수료로 트랜잭션을 신속하게 확인할 수 있습니다(일부 사용자는 수수료에 더 관심이 있고 다른 사용자는 대기 시간에 관심이 있음). 전반적으로 비용은 여러 요인의 영향을 받습니다.

• 거래할 수 있는 시장 수요는 얼마나 됩니까?
• 시스템에서 달성한 총 처리량은 얼마입니까?
• 시스템이 유효성 검사기 또는 채굴자에게 제공하는 총 수익은 얼마입니까?
• 이 수익 중 거래 수수료 대 인플레이션 보상을 기반으로 하는 금액은 얼마입니까?

처음 두 가지 요인은 대략적으로 시장 청산 가격으로 이어지는 수요와 공급 곡선입니다(광부들이 이 지점 이상으로 수수료를 부과하기 위해 카르텔 역할을 한다는 주장이 있지만). 다른 모든 조건이 같다면 더 많은 처리량은 더 낮은 수수료로 이어져야 하지만 더 많은 이점이 있습니다.

특히 위의 3번과 4번 항목은 블록체인 시스템 설계의 기본 문제이지만 이에 대한 좋은 원칙이 부족합니다. 우리는 채굴자에게 인플레이션 보상과 거래 수수료로 수입을 주는 것의 장단점을 어느 정도 이해하고 있습니다. 그러나 블록체인 합의 프로토콜에 대한 많은 경제적 분석에도 불구하고 검증자에게 얼마만큼의 수익이 흘러야 하는지 결정하기 위해 널리 받아들여지는 모델이 아직 없습니다. 오늘날 대부분의 시스템은 검증자가 시스템의 실제 사용을 방해하지 않고 정직하게 행동하기에 충분한 수익이 얼마인지에 대한 교육적인 추측을 기반으로 구축됩니다. 단순화된 모델에서는 51% 공격을 시작하는 비용이 검증자에 대한 보상에 비례한다는 것을 보여줄 수 있습니다.

공격 비용을 높이는 것은 좋은 일이지만 얼마나 많은 보안이 "충분한지"도 모릅니다. 두 개의 놀이공원에 가는 것을 고려하고 있다고 상상해 보십시오. 그들 중 하나는 다른 것보다 승차 유지 관리에 50% 적은 비용을 지출한다고 주장합니다. 이 공원에 가는 것이 좋은 생각인가요? 더 효율적이고 더 적은 비용으로 동일한 보안을 얻을 수 있습니다. 다른 사람은 아무 혜택 없이 놀이기구를 안전하게 유지하는 데 필요한 것보다 더 많은 비용을 지출하고 있을 수 있습니다. 그러나 첫 번째 공원이 위험할 수도 있습니다. 블록체인 시스템도 비슷합니다. 처리량이 고려되면 수수료가 낮은 블록체인은 더 적은 수의 검증자에게 보상(따라서 인센티브를 제공)하기 때문에 수수료가 더 낮습니다. 오늘날 이것이 가능한지 또는 시스템을 취약하게 만들지 여부를 평가할 수 있는 좋은 도구가 없습니다. 전반적인:

서로 다른 시스템 간의 수수료 비교는 오해의 소지가 있습니다. 거래 수수료는 사용자에게 중요하지만 시스템 설계 자체 외에도 많은 요인의 영향을 받습니다. 처리량은 전체 시스템을 분석하기 위한 더 나은 메트릭입니다.

결론적으로

성과를 공정하고 정확하게 평가하는 것은 어렵습니다. 자동차의 성능을 측정할 때도 마찬가지입니다. 블록체인과 마찬가지로 사람들마다 다른 것에 관심을 가질 것입니다. 자동차를 사용하면 일부 사용자는 최고 속도나 가속도에 관심을 가질 것이고, 다른 사용자는 연료 소비에 관심을 가질 것이며, 또 다른 사용자는 견인 용량에 관심을 가질 것입니다. 이 모든 것은 평가하기 쉽지 않습니다. 예를 들어, 미국 환경보호청(EPA)은 연비를 평가하는 방법과 대리점에서 사용자에게 제시해야 하는 방법에 대한 자세한 지침을 제공합니다.

블록체인 공간은 이러한 표준화 수준에서 아직 멀었습니다. 일부 영역에서는 향후 대기 시간 분포를 나타내는 정규화된 워크로드 또는 정규화된 그래프를 통해 시스템의 처리량을 측정할 수 있습니다. 현재 평가자 및 빌더의 최선의 조치는 가능한 한 많은 데이터를 수집 및 게시하고 다른 시스템과 복제 및 비교할 수 있도록 평가 방법론을 자세히 설명하는 것입니다.