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

Odaily资深作者

2022-08-10 03:31

이 기사는 약 4907자로, 전체를 읽는 데 약 8분이 소요됩니다

이러한 성과 지표를 사용하고 비교하는 방법에 대해 자세히 알아보십시오.

이 기사는 a16z이 기사는

, 원저자: Joseph Bonneau, 오데일리 번역가 Katie Koo가 편집.

성능을 측정하고 비교하기 위해 보다 미묘하고 철저한 접근 방식이 필요합니다. 즉, 성능을 구성 요소로 분류하고 여러 데이터 축에서 장단점을 비교하는 것입니다. 이 백서는 블록체인 성능의 의미를 정의하고 해당 과제를 설명하며 블록체인 성능을 평가할 때 염두에 두어야 할 지침과 핵심 원칙을 제공합니다.

보조 제목

확장성 대 성능

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

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

일부 다른 원샷 트릭(예: SegWit)은 블록체인에서도 사용할 수 있지만 지속적인 성능 향상을 위해 확장 가능한 아키텍처가 필요합니다. 여기서 더 많은 리소스를 추가하면 시간이 지남에 따라 성능이 향상됩니다. 이것은 또한 웹 서버 구축과 같은 다른 많은 컴퓨터 시스템에 대한 일반적인 생각입니다. 몇 가지 일반적인 트릭을 사용하면 빠르게 실행되는 서버를 구축할 수 있습니다. 그러나 궁극적으로 추가 서버를 추가하여 증가하는 수요를 따라잡기 위해서는 궁극적으로 다중 서버 아키텍처가 필요합니다.

확장성은 본질적으로 병렬성을 이용해야 합니다. 블록체인 공간에서 L1 스케일링에는 포크 또는 포크와 유사한 것이 필요한 것 같습니다. 분기의 기본 개념은 상태를 청크로 분할하여 여러 유효성 검사기가 독립적으로 처리할 수 있도록 하는 것입니다. 이는 확장성의 정의와 매우 잘 일치합니다. L2에는 오프체인 채널, 롤업 서버 및 사이드체인을 포함하여 병렬 처리를 추가할 수 있는 더 많은 옵션이 있습니다.

보조 제목

대기 시간 대 처리량

그러나 대기 시간과 처리량을 측정하고 비교하는 것은 복잡합니다. 또한 개별 사용자는 처리량에 대해 별로 신경쓰지 않습니다(시스템 전체 메트릭임). 그들이 정말로 신경 쓰는 것은 대기 시간과 거래 수수료입니다. 보다 구체적으로, 그들의 거래는 가능한 한 빠르고 저렴하게 확인됩니다. 다른 많은 컴퓨터 시스템도 비용/성능 기준으로 평가되지만 트랜잭션 수수료는 기존 컴퓨터 시스템에는 실제로 존재하지 않는 블록체인 시스템의 새로운 성능 축입니다.

보조 제목

대기 시간 측정의 과제

대기 시간은 처음에는 단순해 보입니다. 거래가 확인되는 데 얼마나 걸립니까? 하지만 이 질문에 대답하는 몇 가지 다른 방법이 있습니다.

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

가장 일반적인 접근 방식은 사용자가 트랜잭션을 처음 방송한 시점부터 유효성 검사기의 관점에서 합리적으로 "확인"될 때까지의 시간을 측정하는 것입니다. 물론 가맹점마다 수용 기준이 다를 수 있으며, 단일 가맹점이라도 거래 금액에 따라 기준이 다를 수 있다.

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

대기 시간을 측정하려는 기간을 정규화하더라도 대답은 다릅니다. 현재까지 고정 트랜잭션 대기 시간을 제공하는 암호화폐 시스템은 없습니다. 기본적인 경험 법칙은 다음과 같습니다.

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

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

블록체인에서 확인 대기 시간은 다음과 같은 여러 가지 이유로 다릅니다.일괄 처리:

대부분의 시스템은 어떤 방식으로 트랜잭션을 일괄 처리합니다. 예를 들어 대부분의 L1 시스템에서는 트랜잭션을 블록으로 일괄 처리합니다. 일부 트랜잭션은 배치가 채워질 때까지 기다려야 하므로 대기 시간이 가변적입니다. 다른 사람들은 운 좋게도 마지막에 합류할 수 있습니다. 이러한 거래는 즉시 확인되며 추가 지연이 발생하지 않습니다.가변 혼잡:

대부분의 시스템은 혼잡을 경험하며 이는 시스템이 즉시 처리할 수 있는 것보다 더 많은 트랜잭션이 발행됨을 의미합니다. 정체 수준은 트랜잭션이 예측할 수 없는 시간에 브로드캐스팅되거나 새로운 트랜잭션 비율이 하루 또는 일주일 동안 변경되거나 인기 있는 NFT 출시와 같은 외부 이벤트에 대한 응답으로 변경될 수 있습니다.합의 계층 차이점:

L1에서 트랜잭션을 확인하려면 일반적으로 블록에 대한 합의에 도달하기 위해 분산된 노드 집합이 필요하며, 이로 인해 정체에 관계없이 가변 대기 시간이 추가될 수 있습니다. 작업 증명 시스템은 예측할 수 없는 시간에 블록을 찾습니다. PoS 시스템은 또한 다양한 지연을 추가할 수 있습니다(예: 라운드에서 위원회를 구성하기에 온라인 노드가 충분하지 않거나 리더의 붕괴에 대한 응답으로 의견 변경이 필요한 경우).

이러한 이유로 좋은 지침 원칙은 다음과 같아야 합니다.

대기 시간에 대한 주장은 평균이나 중앙값과 같은 단일 숫자가 아니라 확인 시간의 분포를 보여야 합니다.

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

라이트닝 네트워크와 같은 결제 채널 네트워크가 좋은 예입니다. 이것은 고전적인 L2 스케일링 솔루션이며, 이러한 네트워크는 대부분의 경우 매우 빠른 지불 확인을 제공하지만 때때로 채널 재설정이 필요하여 대기 시간이 수십 배 증가할 수 있습니다.

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

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

보조 제목

처리량 측정의 과제

처리량도 표면적으로는 간단해 보입니다. 시스템이 처리할 수 있는 초당 트랜잭션 수는 얼마입니까? 그러나 두 가지 주요 어려움이 있습니다. 정확히 "트랜잭션"이란 무엇이며 시스템이 현재 수행하는 작업 또는 수행할 수 있는 작업을 측정하고 있습니까?

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

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

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

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

결제 거래만 지원하는 롤업 서버와 같은 간단한 실행 계층은 정량적 계산의 어려움을 피합니다. 이 경우에도 투입량과 산출량에 따라 지급액이 달라진다. 결제 채널 트랜잭션은 처리량에 영향을 미치는 필요한 "홉" 수에 따라 다를 수 있습니다. 롤업 서버 처리량은 트랜잭션 배치가 더 작은 집계 변경 집합으로 "네트워킹"되는 정도에 따라 달라집니다.

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

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

보조 제목

대기 시간 및 처리량 절충

보조 제목

거래 수수료

당연하게도 최종 사용자는 대기 시간과 처리량보다 대기 시간과 비용 간의 상충 관계에 더 관심이 있습니다. 사용자는 처리량에 대해 즉각적인 관심을 가질 이유가 전혀 없으며 트랜잭션을 신속하고 가능한 가장 낮은 수수료로 확인할 수 있는 것에만 관심이 있습니다(일부 사용자는 수수료에 더 관심이 있고 일부는 대기 시간에 더 관심이 있음). 높은 수수료는 다음과 같은 여러 요인의 영향을 받습니다.
거래할 수 있는 시장 수요는 얼마나 됩니까?
시스템에서 달성한 전체 처리량은 얼마입니까?
시스템이 유효성 검사기 또는 채굴자에게 제공하는 총 수익은 얼마입니까?

이 수익 중 거래 수수료 또는 인플레이션 보상을 기반으로 하는 금액은 얼마입니까?

처음 두 가지 요소는 시장 청산 가격으로 이어지는 대략적인 공급 및 수요 곡선입니다(일부에서는 연합과 같은 광부들이 이 지점 이상으로 수수료를 부과한다고 주장하지만). 다른 모든 조건이 같다면 더 높은 처리량은 더 낮은 수수료로 이어져야 하지만 처리해야 할 더 많은 요소가 있습니다.

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

보조 제목

결론적으로

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