a16z：블록체인 성능 평가의 기본 원칙

작성자：Joseph Bonneau，a16z crypto 연구원

편집：Amber，Foresight News

성능과 확장성에 대한 논의는 암호화폐 세계에서 가장 오랜 논쟁 중 하나입니다.

1계층과 2계층 솔루션의 장단점 및 유효성에 대한 논쟁은 계속되고 있지만, 표준화된 지표와 평가 기준이 부족하여 논쟁에 참여하는 각 측의 데이터는 종종 일관성이 결여되어 있으며, 이는 분명히 견해의 차이를 더욱 심화시킵니다.

간단히 말해, 우리는 성능 비교를 위해 보다 세밀하고 철저한 접근 방식이 필요합니다. 예를 들어, 성능을 여러 차원으로 나누어 각각 비교하고 종합적인 균형 기준을 찾아야 합니다. 본문에서는 기본 용어부터 시작하여 현재 시장이 직면한 도전 과제를 개괄하고, 블록체인 성능을 평가할 때 기억해야 할 몇 가지 기본 원칙을 다루겠습니다.

확장성 및 성능

먼저 두 가지 용어, 확장성과 성능을 정의해 보겠습니다. 이 두 단어는 표준 컴퓨터 과학적 의미를 가지고 있지만, 블록체인 환경에서는 자주 남용됩니다. 성능은 일반적으로 시스템이 달성할 수 있는 목표 효율성을 측정하는 데 사용되며, 성능 지표에는 초당 처리할 수 있는 프로세스 수 또는 특정 요구 사항에 필요한 시간 등이 포함될 수 있습니다. 반면 확장성은 시스템이 특정 자원을 추가하여 성능을 향상시킬 수 있는 능력을 측정하는 데 사용됩니다.

왜 먼저 명확히 정의해야 하는가 하면, 실제로 많은 성능 향상 방법이 확장성을 향상시키지 않기 때문입니다. 간단한 예로, BLS 서명과 같은 보다 효율적인 디지털 서명 방식을 사용하는 것입니다. BLS 서명의 크기는 Schnorr 또는 ECDSA 서명의 절반 정도입니다. 비트코인이 ECDSA에서 BLS로 전환된다면, 각 블록의 거래 수는 20-30% 증가할 수 있으며, 이는 하룻밤 사이에 성능을 향상시킬 수 있습니다. 그러나 우리는 이것을 한 번만 할 수 있습니다. 더 공간을 절약할 수 있는 서명 방식으로 전환할 수는 없습니다(또한 BLS 서명은 더 많은 공간을 절약하기 위해 집합할 수 있지만, 이것도 또 다른 일회성 기술일 뿐입니다).

실제로 블록체인 네트워크에는 일회성 기술이 많이 존재합니다(예: SegWit). 그러나 우리가 진정으로 필요한 것은 지속적인 성능 개선을 위한 확장 가능한 아키텍처입니다. 그래야만 지속적으로 자원을 추가하여 성능을 지속적으로 향상시킬 수 있습니다. 실제로 Web2 시대에는 이것이 일반적인 수단이었습니다. 서버를 구축하는 예를 들면, 우리는 충분히 빠른 서버를 직접 구축할 수 있지만, 결국 일반적으로 다중 서버 아키텍처로 업그레이드해야 하며, 이 과정에서 지속적으로 새로운 서버를 추가하여 증가하는 데이터 저장/처리 요구를 충족해야 합니다.

이러한 차이를 이해하는 것은 "어떤 블록체인이 높은 확장성을 가지고 있으며, 초당 얼마나 많은 거래를 처리할 수 있는가!"와 같은 진술에서 상식적인 오류를 피하는 데 도움이 됩니다. 이러한 언급은 자극적일 수 있지만, 실제로 얼마나 많은 거래를 처리할 수 있는가는 성능 지표이지 확장성 지표가 아닙니다.

확장성은 본질적으로 병렬성을 활용해야 합니다. 블록체인 분야에서 1계층 확장은 종종 샤딩 또는 샤딩처럼 보이는 것을 필요로 합니다. 샤딩의 기본 개념은 상태를 여러 조각으로 나누어 서로 다른 검증자가 그 중 일부를 독립적으로 처리할 수 있도록 하는 것입니다. 이는 확장성의 정의와 매우 잘 맞아떨어집니다. 물론 2계층에는 체인 외부 채널, 롤업, 사이드체인 등 병렬 처리를 추가할 수 있는 더 많은 옵션이 있습니다.

지연 및 처리량

과거에는 지연과 처리량 두 가지 차원으로 블록체인의 성능을 평가하는 것이 일반적이었습니다. 지연은 단일 거래가 얼마나 빨리 확인될 수 있는지를 측정하는 데 사용되며, 처리량은 특정 시간 내에 확인할 수 있는 거래의 총량을 측정하는 데 사용됩니다. 이러한 측정 방식은 1계층 및 2계층 네트워크에 모두 적용되며, 심지어 블록체인 외부의 다른 유형의 컴퓨터 시스템에도 완전히 적용됩니다.

불행히도 지연과 처리량 이 두 차원은 실제로 측정하고 비교하기가 매우 어렵습니다. 그리고 또 하나 중요한 점은, 개별 사용자는 실제로 처리량에 관심이 없으며, 그들이 진정으로 관심 있는 것은 지연과 거래 수수료입니다. 거래 수수료는 블록체인 시스템에서 중요한 차원이며, 이는 전통적인 컴퓨터 분야에서는 존재하지 않습니다.

지연 측정의 도전

지연 측정은 간단해 보입니다: 거래가 확인되기까지 얼마나 걸리나요? 그러나 실제로는 문제가 드러납니다. 첫째, 우리가 서로 다른 시점에서 측정한 지연은 종종 다릅니다. 우리는 사용자가 로컬에서 제출 버튼을 클릭하는 순간부터 계산할까요? 아니면 작업이 메모리 풀에 도달하는 순간부터 계산할까요? 블록이 확인될 때 즉시 시간을 멈춰야 할까요? 서로 다른 작업 세부 사항은 서로 다른 결과를 초래할 수 있습니다.

가장 일반적인 방법은 검증자의 관점에서 측정하는 것입니다. 고객이 거래를 처음 방송한 시점부터 거래가 합리적으로 확인될 때까지의 시간(어떤 의미에서는 현실 세계의 상인이 결제를 받고 상품을 발송하는 것을 고려할 수 있습니다). 물론 서로 다른 상인은 서로 다른 수용 기준을 사용할 수 있으며, 심지어 단일 상인도 거래 금액에 따라 서로 다른 기준을 사용할 수 있습니다.

검증자 중심의 접근 방식은 실제로 중요한 몇 가지 사항을 간과합니다. 첫째, 이는 피어 투 피어 네트워크의 지연(클라이언트가 거래를 방송한 후 대부분의 노드가 이를 듣기까지 얼마나 걸리나요?)과 클라이언트 지연(거래를 준비하는 데 얼마나 걸리나요? 클라이언트의 로컬 머신에서 얼마나 오랫동안 로드해야 하나요?)을 무시합니다. 이더리움 결제와 같은 간단한 거래의 경우 클라이언트 지연은 매우 작고 예측 가능할 수 있지만, 더 복잡한 경우(예: 개인 거래가 올바른지 증명하는 경우)에는 다릅니다.

우리가 지연 측정의 시간 창을 표준화하더라도, 최종 답변은 여전히 상황에 따라 다릅니다. 어떤 암호화폐 시스템도 일정한 거래 지연을 보장할 수 없습니다. 기억해야 할 기본 경험 법칙은 지연은 숫자가 아니라 분포입니다.

네트워크 연구 커뮤니티는 이미 이 점을 인식하고 있으며, 긴 꼬리가 매우 중요하다고 지적했습니다. 0.1%의 프로세스가 지연되더라도 최종 사용자 경험에 심각한 영향을 미칠 수 있습니다.

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

배치 처리: 대부분의 시스템은 어떤 방식으로든 거래를 배치 처리하며, 이는 가변 지연을 초래합니다. 특정 거래는 배치 처리 대기열이 가득 차기까지 기다려야 처리됩니다. 네트워크 참여자는 해당 배치의 마지막 기회를 잡을 수 있습니다. 이러한 거래는 즉시 확인되며 추가 지연이 발생하지 않지만, 대기열에 먼저 들어간 사람들은 확인을 기다리는 데 더 오랜 시간을 소모해야 합니다.

불확실한 혼잡: 대부분의 시스템은 혼잡 상태를 경험하며, 이는 발행된 거래가 시스템이 즉시 처리할 수 있는 수를 초과함을 의미합니다. 거래가 예측할 수 없는 시간(일반적으로 포아송 과정으로 추상화됨)에 방송되거나, 새로운 거래의 속도가 하루 또는 일주일 내에 변화할 때, 또는 외부 사건에 반응할 때 혼잡 정도는 달라질 수 있습니다.

합의 계층 차이: 1계층에서 거래를 확인하려면 일반적으로 분산된 노드 집합이 블록에 대해 합의해야 하며, 이는 가변 지연을 증가시킬 수 있습니다. 작업 증명 시스템은 예측할 수 없는 시간에 블록을 발견합니다. 지분 증명 시스템은 다양한 지연을 추가할 수 있습니다.

이러한 이유로, 좋은 지침은 지연에 대한 진술은 확인 시간의 분포로 제시되어야 하며, 평균값이나 중앙값과 같은 단일 숫자가 되어서는 안 됩니다.

평균값, 중앙값 또는 백분위수와 같은 요약 통계는 일부 패턴을 나타낼 수 있지만, 시스템을 정확하게 평가하려면 전체 분포를 고려해야 합니다. 특정 응용 프로그램에서 지연 분포가 상대적으로 간단하다면 평균 지연은 좋은 통찰력을 제공할 수 있습니다. 그러나 암호화폐에서는 이러한 이상적인 상황이 드물게 발생합니다: 일반적으로 확인 시간이 길어집니다.

결제 채널 네트워크(예: 라이트닝 네트워크)는 좋은 예입니다. 고전적인 L2 확장 솔루션으로서, 이러한 네트워크는 대부분의 경우 매우 빠른 결제 확인 서비스를 제공하지만, 때때로 채널 재설정이 필요하며, 이는 지연을 몇 배로 증가시킬 수 있습니다.

정확한 지연 분포에 대한 좋은 통계 데이터가 있더라도, 시스템과 시스템 요구 사항의 변화에 따라 시간이 지남에 따라 변할 수 있으며, 경쟁 시스템 간의 지연 분포를 비교하는 것도 매우 모호합니다. 예를 들어, 거래의 균일한 분포 지연이 1분에서 2분 사이(평균 및 중앙값 90초)인 시스템을 고려해 보십시오. 만약 경쟁 시스템이 1분 내에 95%의 거래를 정확하게 확인하고, 11분 내에 나머지 5%를 확인했다면(평균 90초, 중앙값 60초), 어떤 시스템이 더 나은가요? 답은 서로 다른 범주의 응용 프로그램이 선택할 수 있는 것이 일관되지 않을 수 있습니다.

마지막으로, 대부분의 시스템에서 모든 거래의 우선 순위가 동일하지 않다는 점에 유의해야 합니다. 사용자는 더 높은 포함 우선 순위를 얻기 위해 더 많은 수수료를 지불할 수 있으므로, 위의 모든 것 외에도 지연은 지불한 거래 수수료에 따라 달라집니다. 요약하자면: 지연은 복잡합니다. 전제 조건의 세부 사항이 많을수록 좋습니다. 이상적으로는 서로 다른 혼잡 조건에서 전체 지연 분포를 측정해야 합니다. 지연을 서로 다른 구성 요소(로컬, 네트워크, 배치, 합의 지연)로 분해하는 것도 도움이 됩니다.

처리량 측정의 도전

처리량은 처음에는 간단해 보입니다: 시스템이 초당 처리할 수 있는 거래 수는 얼마인가요? 그러나 사실 문제는 수면 아래에 숨겨져 있습니다. 어려움은 주로 두 가지 측면에서 발생합니다. 첫째, 무엇이 거래로 간주되는가? 우리는 시스템이 오늘 무엇을 했는지를 측정하고 있나요? 아니면 그가 할 수 있는 것을 측정하고 있나요?

초당 거래 수(TPS)는 블록체인 성능을 측정하는 일반적인 기준이지만, 거래를 측정 단위로 사용하는 것은 문제가 있습니다. 일반적인 프로그래밍 가능성(스마트 계약)을 제공하는 시스템이나 비트코인의 다중 거래 또는 다중 서명 검증 옵션과 같은 제한된 기능을 가진 시스템에서는 가장 기본적인 질문이 있습니다: 모든 거래가 평등한 것은 아닙니다.

이더리움 네트워크에서 거래는 임의의 코드와 임의의 상태를 포함할 수 있습니다. 이더리움의 Gas 개념은 거래가 실행되는 총 작업량을 정량화(및 요금 부과)하는 데 사용되지만, 이는 EVM 실행 환경에 매우 제한적입니다. EVM 거래 집합이 완료하는 작업 총량을 BPF 환경을 사용하는 Solana 거래 집합과 직접 비교하는 간단한 방법은 없습니다. 이들 중 어떤 것도 비트코인 거래 집합과 직접 비교하는 것은 합리적이지 않습니다.

거래 계층을 합의 계층과 실행 계층으로 나누는 블록체인은 이 점을 더욱 명확하게 할 수 있습니다. (순수) 합의 계층에서는 처리량을 단위 시간당 체인에 추가된 바이트 수로 측정할 수 있습니다. 그러나 실행 계층은 훨씬 복잡합니다.

지불 거래만 지원하는 롤업 서버와 같은 더 간단한 실행 계층은 정량화 계산의 어려움을 피합니다. 그러나 이러한 경우에도 지불의 입력 및 출력 수는 다를 수 있습니다. 지불 채널 거래에 필요한 가변 매개변수 수는 다를 수 있으며, 이는 처리량에 영향을 미칠 수 있습니다. 롤업 서버의 처리량은 일괄 거래가 얼마나 작은 데이터 패킷으로 "축소"될 수 있는지에 따라 달라질 수 있습니다.

처리량의 또 다른 도전은 오늘날의 성능을 경험적으로 측정하여 이론적 용량을 평가하는 것입니다. 이는 잠재적 용량을 평가하기 위한 다양한 모델링 문제를 도입합니다. 첫째, 우리는 실행 계층의 실제 거래 작업 부하를 결정해야 합니다. 둘째, 실제 시스템은 이론적 용량에 거의 도달하지 않으며, 특히 블록체인 시스템에서는 더욱 그렇습니다. 견고성을 위해, 우리는 노드가 실제로 이질적이고 다양하게 구현되기를 원합니다(모든 클라이언트가 동일한 소프트웨어 구현을 실행하지 않도록). 이는 블록체인 처리량의 정확한 시뮬레이션을 더욱 어렵게 만듭니다.

전반적으로, 처리량을 평가하려면 거래 작업량과 검증자의 수를 신중하게 설명해야 합니다. 명확한 기준이 없는 경우, 이더리움과 같은 비교적 인기 있는 네트워크의 역사적 부하를 기준으로 삼아야 합니다.

지연과 처리량의 종합적 고려

지연과 처리량 각각을 통계적으로 분석한 후, 우리는 두 가지 사이에서 종합적인 균형을 맞춰야 합니다. Lefteris Kokoris-Kogias가 설명한 바와 같이, 이러한 균형은 일반적으로 순조롭지 않으며, 시스템 부하가 최대 처리량에 가까워질 때 지연이 급격히 증가합니다.

ZK 롤업 시스템은 처리량/지연 균형의 자연스러운 예를 제공합니다. 대량 거래는 증명 시간을 증가시켜 지연을 증가시킵니다. 그러나 증명 크기와 검증 비용 측면에서 체인상의 계산 능력은 더 큰 규모의 거래 클러스터로 기울어져 처리량을 증가시킵니다.

거래 수수료

이해할 수 있듯이, 최종 사용자는 지연과 비용 간의 균형에 더 관심이 있으며, 지연과 처리량 간의 균형에는 관심이 없습니다. 사용자는 처리량에 대해 걱정할 필요가 없으며, 그들은 가능한 한 낮은 비용으로 거래를 신속하게 확인하기를 원합니다(일부 사용자는 비용에 더 관심이 있고, 다른 사용자는 지연에 더 관심이 있습니다). 전반적으로 비용은 여러 요인의 영향을 받습니다:

• 시장 수요는 얼마나 큰가요?

• 시스템이 달성할 수 있는 총 처리량은 얼마인가요?

• 해당 시스템이 검증자 또는 채굴자에게 얼마나 많은 수익을 제공하나요?

• 이 수익 중 얼마나 많은 부분이 거래 수수료와 인플레이션 보상에 기반하고 있나요?

간단히 말해, 다른 조건이 동일하다면 더 높은 처리량은 더 낮은 비용으로 이어져야 합니다. 그러나 위에서 언급한 3번과 4번은 블록체인 시스템 설계의 기본 문제입니다. 블록체인 합의 프로토콜에 대한 많은 경제 분석이 이루어졌지만, 검증자가 필요로 하는 수익에 대한 합의된 모델은 아직 없습니다. 오늘날 대부분의 시스템은 검증자가 성실하게 행동할 수 있도록 충분한 수익을 제공하는 한편, 사용자에게 네트워크의 매력을 유지할 수 있는 정도의 수익을 제공하는 데 기반한 추측 위에 세워져 있습니다. 단순화된 모델에서는 51% 공격을 시작하는 비용을 검증자의 보상과 비례하도록 설정하면 됩니다.

공격 비용을 높이는 것은 좋은 일이지만, 우리는 얼마나 많은 안전성이 "충분한지" 알지 못합니다. 상상해 보십시오, 당신이 두 개의 놀이공원을 고려하고 있습니다. 한 곳은 다른 곳보다 유지보수 비용이 50% 더 적다고 주장합니다. 이 공원에 가는 것이 좋은 생각일까요? 아마도 그들이 더 효율적이며 적은 비용으로 동등한 안전성을 제공할 수 있습니다. 어쩌면 다른 곳은 놀이기구의 안전을 유지하는 데 필요한 비용을 초과하고 있으며, 아무런 이점도 없을 수 있습니다. 그러나 첫 번째 공원이 위험할 수도 있습니다. 블록체인 시스템도 비슷합니다. 처리량을 고려하면, 비용이 낮은 블록체인은 낮은 보상을 제공하기 때문에 비용이 낮습니다. 우리는 오늘날 이것이 실행 가능한지, 아니면 시스템이 공격에 취약하게 만들 것인지 평가할 좋은 도구가 없습니다. 전반적으로: 시스템 간의 비용을 비교하는 것은 어느 정도 오해를 초래할 수 있습니다. 거래 수수료는 사용자에게 중요하지만, 시스템 설계 자체 외에도 여러 요인의 영향을 받습니다. 처리량은 전체 시스템을 분석하는 데 더 나은 지표입니다.

결론

공정하고 정확하게 성능을 평가하는 것은 매우 어렵습니다. 블록체인을 측정하는 것은 자동차를 구매할 가치가 있는지를 평가하는 것만큼 복잡합니다. 서로 다른 사람들은 서로 다른 것에 관심을 가지며, 자동차의 경우 일부 사용자는 최고 속도나 100km/h 가속 성능에 관심이 있고, 다른 사람들은 연비에 관심이 있으며, 또 다른 사람들은 이 자동차가 얼마나 많은 짐을 실을 수 있는지에만 관심이 있습니다. 이러한 이유로 미국 환경 보호청은 자동차 평가 기준에 대한 지침을 직접 제정하기도 했습니다.

블록체인 분야에서는 아직 표준화된 기준을 제정할 수 있는 시점에 도달하지 않았습니다. 어떤 때는 표준 작업 부하를 찾아 블록체인 네트워크의 처리량과 지연 분포에 대한 "표준 차트"를 그릴 수 있을지도 모르지만, 현재 연구자와 구축자에게 가장 좋은 방법은 가능한 한 많은 데이터를 수집하고, 의견을 발표하기 전에 테스트 환경을 가능한 한 상세하게 묘사하는 것입니다. 그래야만 우리는 상대적으로 객관적인 비교 결과를 얻을 수 있습니다.