성능과 확장성은 레이어 1 프로젝트(독립 블록체인) 및 레이어 2 솔루션(예: 롤업 및 오프체인 채널)과 관련하여 암호화폐 공간에서 많이 논의되는 문제입니다. 그러나 표준화된 지표나 벤치마크가 없습니다. 수치는 일관되지 않고 불완전한 방식으로 보고되는 경우가 많아 프로젝트를 정확하게 비교하기 어렵고 실제로 가장 중요한 것이 무엇인지 모호하게 만드는 경우가 많습니다.
성능을 측정하고 비교하려면 성능을 여러 구성 요소로 나누고 여러 축에 걸쳐 장단점을 비교하는 보다 미묘하고 철저한 접근 방식이 필요합니다. 이 게시물에서는 기본 용어를 정의하고, 과제를 간략하게 설명하며, 블록체인 성능을 평가할 때 염두에 두어야 할 지침과 주요 원칙을 제공합니다.
확장성 대 성능
먼저, 블록체인 맥락에서 종종 오용되는 표준 컴퓨터 과학 의미를 갖는 확장성과 성능이라는 두 가지 용어를 정의해 보겠습니다. 퍼포먼스 시스템이 무엇인지 측정 현재 달성 가능한. 아래에서 설명하겠지만 성능 지표에는 초당 트랜잭션 또는 중간 트랜잭션 확인 시간이 포함될 수 있습니다. 확장성, 반면에 자원을 추가하여 성능을 향상시키는 시스템의 능력.
이러한 구별은 중요합니다. 성능을 향상하기 위한 많은 접근 방식은 적절하게 정의되면 확장성을 전혀 향상시키지 않습니다. 간단한 예는 Schnorr 또는 ECDSA 서명 크기의 대략 절반인 BLS 서명과 같은 보다 효율적인 디지털 서명 체계를 사용하는 것입니다. 비트코인이 ECDSA에서 BLS로 전환하면 블록당 거래 수가 20~30% 증가하여 하룻밤 사이에 성능이 향상될 수 있습니다. 하지만 이 작업은 한 번만 수행할 수 있습니다. 전환할 수 있는 공간 효율적인 서명 방식은 없습니다(BLS 서명을 집계하여 더 많은 공간을 절약할 수도 있지만 이는 또 다른 일회성 트릭입니다).
블록체인에서는 여러 가지 일회성 트릭(예: SegWit)이 가능하지만, 더 많은 리소스를 추가하면 시간이 지남에 따라 성능이 향상되는 지속적인 성능 향상을 달성하려면 확장 가능한 아키텍처가 필요합니다. 이는 웹 서버 구축과 같은 다른 많은 컴퓨터 시스템에서도 통념입니다. 몇 가지 일반적인 트릭을 사용하면 하나의 매우 빠른 서버를 구축할 수 있습니다. 그러나 궁극적으로는 지속적으로 서버를 추가하여 계속 증가하는 수요를 충족할 수 있는 다중 서버 아키텍처가 필요합니다.
차이점을 이해하면 "블록체인 X는 확장성이 뛰어나 초당 Y개의 트랜잭션을 처리할 수 있습니다!"와 같은 진술에서 발견되는 일반적인 범주 오류를 피하는 데 도움이 됩니다. 두 번째 주장은 인상적일 수 있지만 성능 확장성 지표가 아닌 지표입니다. 리소스를 추가하여 성능을 향상시키는 능력을 말하는 것은 아닙니다.
확장성은 본질적으로 병렬성을 활용해야 합니다. 블록체인 공간에서 레이어 1 확장에는 샤딩 또는 샤딩과 유사한 것이 필요한 것으로 보입니다. 샤딩의 기본 개념(상태를 여러 조각으로 분할하여 여러 유효성 검사기가 독립적으로 처리할 수 있음)은 확장성의 정의와 밀접하게 일치합니다. 레이어 2에는 오프체인 채널, 롤업 서버 및 사이드체인을 포함하여 병렬 처리를 추가할 수 있는 더 많은 옵션이 있습니다.
지연 시간과 처리량
일반적으로 블록체인 시스템 성능은 대기 시간과 처리량이라는 두 가지 측면에서 평가됩니다. 대기 시간은 개별 트랜잭션이 얼마나 빨리 확인되는지를 측정하는 반면, 처리량은 시간에 따른 총 트랜잭션 속도를 측정합니다. 이러한 축은 레이어 1 및 레이어 2 시스템뿐만 아니라 기타 여러 유형의 컴퓨터 시스템(예: 데이터베이스 쿼리 엔진 및 웹 서버)에도 적용됩니다.
불행하게도 대기 시간과 처리량은 모두 측정하고 비교하기가 복잡합니다. 게다가 개별 사용자는 실제로 처리량(시스템 전체 측정값)에 관심이 없습니다. 그들이 정말로 관심을 갖는 것은 대기 시간과 거래 수수료입니다. 보다 구체적으로 말하면 거래가 가능한 한 빠르고 저렴하게 확인되는 것입니다. 다른 많은 컴퓨터 시스템도 비용/성능 기준으로 평가되지만 거래 수수료는 기존 컴퓨터 시스템에는 실제로 존재하지 않는 블록체인 시스템의 성능에 대한 다소 새로운 축입니다.
지연 시간 측정의 과제
처음에는 지연 시간이 단순해 보입니다. 거래가 확인되는 데 시간이 얼마나 걸리나요? 하지만 이 질문에 대답하는 방법에는 항상 여러 가지가 있습니다.
첫째, 서로 다른 시점 간의 지연 시간을 측정하여 서로 다른 결과를 얻을 수 있습니다. 예를 들어, 사용자가 로컬에서 "제출" 버튼을 누를 때 또는 트랜잭션이 멤풀에 도달할 때 대기 시간 측정을 시작합니까? 그리고 거래가 제안된 블록에 있을 때, 아니면 후속 블록 1개 또는 6개로 블록이 확인될 때 시계를 멈추나요?
가장 일반적인 접근 방식은 유효성 검사기의 관점에서 클라이언트가 처음으로 거래를 방송하는 시간부터 거래가 합리적으로 "확인"되는 시간(실제 판매자가 수령한 지불금을 고려하고 상품을 출시한다는 의미)까지 측정합니다. . 물론, 가맹점마다 승인기준이 다를 수 있으며, 단일 가맹점이라도 거래금액에 따라 다른 기준을 적용할 수 있습니다.
검증자 중심 접근 방식은 실제로 중요한 몇 가지 사항을 놓치고 있습니다. 첫째, P2P 네트워크의 대기 시간(클라이언트가 트랜잭션을 브로드캐스트하는 시점부터 대부분의 노드가 이를 들을 때까지 걸리는 시간)과 클라이언트 측 대기 시간(트랜잭션을 준비하는 데 걸리는 시간)을 무시합니다. 클라이언트의 로컬 컴퓨터에 있습니까?). 클라이언트 측 대기 시간은 Ethereum 지불에 서명하는 것과 같은 간단한 거래의 경우 매우 작고 예측 가능하지만, 보호된 Zcash 거래가 올바른지 증명하는 것과 같은 보다 복잡한 경우에는 중요할 수 있습니다.
대기 시간으로 측정하려는 시간 창을 표준화하더라도 대답은 거의 항상 다음과 같습니다. 그것은 따라 달라집니다. 지금까지 구축된 어떤 암호화폐 시스템도 고정된 거래 대기 시간을 제공하지 않았습니다. 기억해야 할 기본 경험 법칙은 다음과 같습니다.
지연 시간은 단일 숫자가 아닌 분포입니다.
네트워킹 연구 커뮤니티는 오랫동안 이를 이해해 왔습니다(예를 들어 다음을 참조하십시오). 길 테네의 훌륭한 강연). 0.1%의 트랜잭션(또는 웹 서버 쿼리)에서도 지연 시간이 크게 증가하면 배포의 "롱테일"에 특히 중점을 둡니다. 충격 최종 사용자.
블록체인을 사용하면 확인 대기 시간이 여러 가지 이유로 달라질 수 있습니다.
일괄 처리: 대부분의 시스템은 어떤 방식으로든 트랜잭션을 일괄 처리합니다(예: 대부분의 레이어 1 시스템의 블록). 일부 트랜잭션은 배치가 가득 찰 때까지 기다려야 하기 때문에 이로 인해 지연 시간이 가변적으로 발생합니다. 다른 사람들은 운이 좋아서 마지막에 배치에 참여할 수도 있습니다. 이러한 거래는 즉시 확인되며 추가 대기 시간이 발생하지 않습니다.
다양한 혼잡도: 대부분의 시스템은 혼잡으로 인해 어려움을 겪습니다. 즉, 시스템이 즉시 처리할 수 있는 것보다 더 많은 트랜잭션이 게시됩니다(적어도 일정 시간 동안). 트랜잭션이 예측할 수 없는 시간에 브로드캐스트될 때 혼잡 정도가 달라질 수 있습니다(종종 포아송 과정) 또는 하루 또는 일주일 동안 새로운 거래 비율이 변경되거나 인기 있는 NFT 출시와 같은 외부 이벤트에 대한 반응으로 변경되는 경우입니다.
합의 계층 분산: 레이어 1에서 트랜잭션을 확인하려면 일반적으로 분산된 노드 집합이 블록에 대한 합의에 도달해야 하며, 이로 인해 정체와 관계없이 다양한 지연이 추가될 수 있습니다. 작업 증명 시스템은 예측할 수 없는 시간에 블록을 찾습니다(추상적으로는 포아송 프로세스이기도 함). 지분 증명 시스템은 또한 다양한 지연을 추가할 수 있습니다(예를 들어, 라운드에서 위원회를 구성하기에 온라인 상태인 노드 수가 부족한 경우 또는 리더 충돌에 대한 응답으로 보기 변경이 필요한 경우).
이러한 이유로 좋은 지침은 다음과 같습니다.
지연 시간에 대한 주장은 평균이나 중앙값과 같은 단일 숫자가 아닌 확인 시간의 분포(또는 히스토그램)를 제시해야 합니다.
평균, 중앙값, 백분위수와 같은 요약 통계는 부분적인 그림을 제공하지만 시스템을 정확하게 평가하려면 전체 분포를 고려해야 합니다. 일부 애플리케이션에서는 지연 시간 분포가 비교적 단순한 경우(예: 가우스) 평균 지연 시간을 통해 좋은 통찰력을 얻을 수 있습니다. 그러나 암호화폐에서는 이런 일이 거의 발생하지 않습니다. 일반적으로 확인 시간이 오래 걸립니다.
결제 채널 네트워크(예: 라이트닝 네트워크)가 좋은 예입니다. 고전적인 L2 확장 솔루션인 이러한 네트워크는 대부분의 경우 매우 빠른 결제 확인을 제공하지만 때로는 채널 재설정이 필요하여 대기 시간이 엄청나게 늘어날 수 있습니다.
정확한 대기 시간 분포에 대한 좋은 통계가 있더라도 시간이 지남에 따라 시스템과 시스템에 대한 수요가 변화함에 따라 통계가 달라질 수 있습니다. 또한 경쟁 시스템 간의 지연 시간 분포를 비교하는 방법이 항상 명확하지는 않습니다. 예를 들어, 1~2분(평균 및 중앙값 90초)의 균일하게 분산된 대기 시간으로 트랜잭션을 확인하는 시스템을 생각해 보세요. 경쟁 시스템이 정확히 95분 안에 1%의 거래를 확인하고 나머지 5%를 11분 안에 확인한다면(평균 90초, 중앙값 60초) 어떤 시스템이 더 좋나요? 대답은 아마도 일부 응용 프로그램은 전자를 선호하고 일부 응용 프로그램은 후자를 선호한다는 것입니다.
마지막으로, 대부분의 시스템에서 모든 트랜잭션의 우선순위가 동일하게 지정되지는 않는다는 점에 유의하는 것이 중요합니다. 사용자는 더 높은 포함 우선순위를 얻기 위해 더 많은 비용을 지불할 수 있으므로 위의 모든 사항 외에도 지불한 거래 수수료에 따라 지연 시간이 달라집니다. 요약하자면:
지연 시간은 복잡합니다. 보고된 데이터가 많을수록 좋습니다. 이상적으로는 다양한 혼잡 상황에서 전체 지연 시간 분포를 측정해야 합니다. 지연 시간을 다양한 구성 요소(로컬, 네트워크, 일괄 처리, 합의 지연)로 분류하는 것도 도움이 됩니다.
처리량 측정의 과제
처리량 역시 언뜻 보면 단순해 보입니다. 시스템이 초당 몇 개의 트랜잭션을 처리할 수 있습니까? 두 가지 주요 어려움이 발생합니다. "트랜잭션"이란 정확히 무엇이며, 현재 시스템이 수행하는 작업이나 수행할 수 있는 작업을 측정하고 있습니까?
"초당 트랜잭션 수"(또는 tps)는 블록체인 성능을 측정하는 사실상의 표준이지만 트랜잭션은 측정 단위로서 문제가 있습니다. 범용 프로그래밍 기능(“스마트 계약”)을 제공하거나 비트코인의 다중 거래 또는 다중 서명 확인 옵션과 같은 제한된 기능을 제공하는 시스템의 경우 근본적인 문제는 다음과 같습니다.
모든 거래가 동일한 것은 아닙니다.
이는 트랜잭션이 임의의 코드를 포함하고 상태를 임의로 수정할 수 있는 Ethereum에서 분명히 사실입니다. 이더리움의 가스 개념은 거래가 수행하는 전체 작업량을 정량화(및 수수료 청구)하는 데 사용되지만 이는 EVM 실행 환경에 매우 구체적입니다. EVM 트랜잭션 세트가 수행한 총 작업량을 BPF 환경을 사용하는 솔라나 트랜잭션 세트와 비교할 수 있는 간단한 방법은 없습니다. 비트코인 거래 세트와 비교하는 것도 비슷하게 어렵습니다.
트랜잭션 계층을 합의 계층과 실행 계층으로 분리하는 블록체인은 이를 더욱 명확하게 할 수 있습니다. (순수한) 합의 계층에서 처리량은 단위 시간당 체인에 추가되는 바이트 단위로 측정될 수 있습니다. 실행 계층은 항상 더 복잡합니다.
결제 거래만 지원하는 롤업 서버와 같은 더 간단한 실행 계층은 계산을 정량화하는 데 어려움을 겪지 않습니다. 하지만 이 경우에도 지불금은 입력 및 출력 수에 따라 달라질 수 있습니다. 결제 채널 트랜잭션은 처리량에 영향을 미치는 필요한 "홉" 수에 따라 달라질 수 있습니다. 그리고 롤업 서버 처리량은 트랜잭션 일괄 처리가 더 작은 요약 변경 사항 집합으로 "상쇄"될 수 있는 정도에 따라 달라질 수 있습니다.
처리량과 관련된 또 다른 과제는 오늘날의 성능을 경험적으로 측정하는 것 이상으로 이론적 용량을 평가하는 것입니다. 이는 잠재적 용량을 평가하기 위한 모든 종류의 모델링 질문을 소개합니다. 먼저 실행 계층에 대한 현실적인 트랜잭션 워크로드를 결정해야 합니다. 둘째, 실제 시스템, 특히 블록체인 시스템은 이론적 용량을 거의 달성하지 못합니다. 견고성을 이유로 우리는 노드 구현이 실제로 (단일 소프트웨어 구현을 실행하는 모든 클라이언트가 아니라) 이질적이고 다양하기를 바랍니다. 이로 인해 블록체인 처리량에 대한 정확한 시뮬레이션을 수행하기가 더욱 어려워졌습니다.
전체 :
처리량에 대한 주장에는 트랜잭션 작업량과 검증자 모집단(수량, 구현 및 네트워크 연결)에 대한 주의 깊은 설명이 필요합니다. 명확한 표준이 없으면 Ethereum과 같은 인기 있는 네트워크의 과거 워크로드로 충분합니다.
지연 시간 처리량 절충
지연 시간과 처리량은 일반적으로 절충안입니다. 처럼 Lefteris Kokoris-Kogias 개요, 시스템 로드가 최대 처리량에 도달함에 따라 대기 시간이 급격히 증가하는 변곡점이 있어 이러한 절충은 원활하지 않은 경우가 많습니다.
영지식 롤업 시스템은 처리량/지연 시간 균형의 자연스러운 예를 제시합니다. 대량의 트랜잭션 배치는 증명 시간을 증가시켜 지연 시간을 증가시킵니다. 그러나 증명 크기와 검증 비용 측면에서 온체인 공간은 더 큰 배치 크기로 더 많은 트랜잭션을 통해 분할되어 처리량이 증가합니다.
거래 수수료
당연히 최종 사용자는 지연 시간과 지연 시간 사이의 균형에 더 관심을 갖습니다. 요금, 대기 시간 및 처리량이 아닙니다. 사용자는 처리량에 전혀 관심을 가질 직접적인 이유가 없으며 가능한 가장 낮은 수수료로 신속하게 거래를 확인할 수 있다는 것뿐입니다(일부 사용자는 수수료에 더 관심을 갖고 다른 사용자는 대기 시간에 더 관심을 가짐). 높은 수준에서 수수료는 여러 요인의 영향을 받습니다.
- 거래를 하기 위한 시장 수요는 얼마나 됩니까?
- 시스템이 달성하는 전체 처리량은 얼마입니까?
- 시스템이 검증인이나 채굴자에게 제공하는 전체 수익은 얼마입니까?
- 이 수익 중 거래 수수료와 인플레이션 보상을 기준으로 계산한 금액은 얼마입니까?
처음 두 가지 요소는 대략 시장 청산 가격으로 이어지는 공급/수요 곡선입니다. 광부는 이 지점 이상으로 수수료를 인상하기 위해 카르텔 역할을 합니다.). 다른 모든 조건이 동일하다면 처리량이 많을수록 수수료가 낮아지는 경향이 있지만 더 많은 일이 벌어지고 있습니다.
특히 위의 3번과 4번은 블록체인 시스템 설계의 근본적인 질문이지만 둘 중 하나에 대한 좋은 원칙이 부족합니다. 우리는 인플레이션 보상과 거래 수수료로 채굴자에게 수익을 제공하는 것의 장점과 단점을 어느 정도 이해하고 있습니다. 그러나 블록체인 합의 프로토콜에 대한 많은 경제적 분석에도 불구하고 검증자에게 얼마나 많은 수익이 필요한지에 대해 널리 받아들여지는 모델은 아직 없습니다. 오늘날 대부분의 시스템은 시스템의 실제 사용을 방해하지 않고 검증인이 정직하게 행동할 수 있도록 충분한 수익이 얼마나 되는지에 대한 교육받은 추측을 기반으로 구축됩니다. 단순화된 모델에서는 51% 공격을 수행하는 데 드는 비용은 검증자에 대한 보상에 따라 증가한다는 것을 알 수 있습니다..
공격 비용을 높이는 것은 좋은 일이지만, 보안이 얼마나 "충분"한지도 모릅니다. 두 개의 놀이공원에 가는 것을 고려하고 있다고 상상해 보세요. 그 중 하나는 다른 것보다 차량 유지 관리에 50% 더 적은 비용을 지출한다고 주장합니다. 이 공원에 가는 것이 좋은 생각인가요? 더 효율적이고 더 적은 비용으로 동등한 안전성을 얻을 수 있습니다. 아마도 다른 사람은 아무런 이익도 없이 안전한 놀이기구를 유지하는 데 필요한 것보다 더 많은 비용을 지출하고 있을 것입니다. 하지만 첫 번째 공원이 위험한 경우도 있을 수 있습니다. 블록체인 시스템도 비슷합니다. 처리량을 고려하면 수수료가 낮은 블록체인은 검증자에게 보상(따라서 인센티브)을 덜 주기 때문에 수수료가 더 낮습니다. 현재로서는 이것이 괜찮은지 또는 시스템이 공격에 취약한지 평가할 수 있는 좋은 도구가 없습니다. 전반적인:
시스템 간 수수료를 비교하는 것은 오해의 소지가 있습니다. 거래 수수료는 사용자에게 중요하지만 시스템 설계 자체 외에도 많은 요인의 영향을 받습니다. 처리량은 시스템 전체를 분석하는 데 더 나은 측정 기준입니다.
결론
성과를 공정하고 정확하게 평가하는 것은 어렵습니다. 이는 자동차의 성능을 측정하는 경우에도 마찬가지입니다. 블록체인과 마찬가지로, 사람들은 서로 다른 것에 관심을 갖습니다. 자동차의 경우 일부 사용자는 최고 속도나 가속도에 관심을 갖고, 다른 사용자는 연비에 관심을 갖고, 다른 사용자는 견인 능력에 관심을 갖습니다. 이 모든 것들은 평가하기가 쉽지 않습니다. 예를 들어, 미국에서는 환경 보호국(Environmental Protection Agency)이 연비를 평가하는 방법과 대리점에서 사용자에게 이를 제시하는 방법에 대한 자세한 지침을 유지합니다.
블록체인 공간은 이러한 표준화 수준과는 거리가 멀습니다. 특정 영역에서는 미래에 시스템 처리량을 평가하기 위한 표준화된 워크로드나 대기 시간 분포를 표시하기 위한 표준화된 그래프를 통해 목표를 달성할 수 있습니다. 당분간 평가자와 구축자를 위한 최선의 접근 방식은 평가 방법론에 대한 자세한 설명과 함께 가능한 한 많은 데이터를 수집하고 게시하여 다른 시스템과 재현 및 비교할 수 있도록 하는 것입니다.
