출처: Rick and Morty, S2E9, 2015

며칠 전 Mike Kelly님이 트위터를 통해 (1) 재구성 공격으로 인해 이중 지급이 발생할 가능성이 있는지, (2) 이로 인해 비트코인이 위험해지는지 질문하셨습니다. 다소 복잡하지만 굉장히 흥미로운 질문입니다. 그래서 이번 기회에 단계별로 살펴보고자 합니다.

간략하게 요약하면 아래와 같습니다.

  1. Replace-By-Fee 는 메모리풀(비트코인 트랜잭션의 “대기 영역”)의 기존 트랜잭션을 대체하는 정책입니다.
  2. 트랜잭션 대체는 Zeroconf 정책을 갖춘 판매자에게 이중 지급을 할 때 사용할 수 있습니다(Zeroconf가 안전하지 않은 이유가 여기에 있습니다).
  3. 재구성 공격 시 공격자는 이전에 확정된 트랜잭션을 메모리풀로 돌려보내어 트랜잭션으로 가득한 블록을 텅 빈 블록으로 대체할 수 있습니다.
  4. 이 시나리오에서는 최소한의 기술 지식이 있거나 공용 도구를 이용할 수 있는 사람 누구나 자신을 대상으로 트랜잭션을 되돌려 이중 지급 기회를 잡을 수 있습니다.
  5. 이러한 공격이 광범위한 절도를 목적으로 하는 경우, 이를 통틀어 퍼지 공격(Purge Attack)이라고 부릅니다. 살인을 포함한 모든 범죄가 매년 하룻밤 동안 합법이 된다는 디스토피아 영화 “The Purge”에서 이름을 따온 것입니다.
  6. 퍼지 공격은 흥미로운 유형의 사보타주 공격이며, 특히 공격에 대응할 때 비트코인 사용자 사이에서 인센티브가 조정되지 않도록 합니다.

모든 것은 메모리풀에서 시작됩니다.

1. 메모리풀

메모리풀은 각 비트코인 노드가 유효한 트랜잭션이 블록에 포함되기까지 기다리면서 해당 트랜잭션을 저장해두는 로컬 데이터베이스입니다.

이미지: 메모리풀, Jochen Hoenicke

노드는 서로 다른 주문 내에서 네트워크의 트랜잭션을 볼 수 있습니다. 따라서 확정되지 않은 트랜잭션 조회 결과는 네트워크의 다른 노드와 서로 달라질 수 있습니다. 비트코인은 모든 노드의 원장 상태를 동기화하기 위해 나카모토 컨센서스를 채택했습니다. 그러나 첫 확인 이후에만 강력한 일관성이 효력을 발휘합니다.

2. 수수료 범핑

사용자는 트랜잭션을 네트워크에 전파할 때마다 최고가 경매에 참여하게 됩니다. 사용자들은 트랜잭션에 수수료를 추가하면서 채굴자가 트랜잭션을 블록에 추가해주길 바랍니다. 합리적인 채굴자는 수수료가 가장 높은 트랜잭션으로 블록을 채우려고 합니다. 그래야 이익이 가장 크기 때문입니다.

그러나 일반적인 경매와 달리 블록 시장의 경매는 유별난 특징을 지니고 있습니다. 입찰에 응한 블록 공간에서 호가가 입찰되지 않은 경우, 호가가 취소되는 것이 아니라 자동으로 다음 경매로 넘어갑니다. 블록에 포함되기에 호가가 너무 낮아 트랜잭션(과 해당하는 코인)이 오랫동안 처리되지 못하면 큰 문제가 될 수 있습니다.

따라서 사용자가 이미 게시된 트랜잭션의 수수료를 범핑(즉, 수수료를 추가할) 수단이 필요합니다. 유용한 부작용으로는 사용자가 트랜잭션 수수료율을 낮게 호가했다가 나중에 범핑할 옵션을 갖게 된다는 것이 있습니다. 이를 통해 블록 경매가 더욱 효율적으로 작동합니다.

마지막으로 수수료 범핑은 결제 채널을 종결(예: 라이트닝 네트워크)하는 데 필요할 수 있습니다. 비협조적인 종결의 경우 마감 시간이 엄격하며, 수수료가 부족한 경우 사용자가 자금을 잃을 수 있어 마감 시간을 놓치기도 합니다.

사용자는 세 가지 방법으로 트랜잭션을 범핑할 수 있습니다.

  1. Child-Pays-For-Parent(CPFP)
  2. 트랜잭션 액셀러레이터
  3. Replace-By-Fee(RBF)

처음 두 가지는 간략하게만 살펴보고, 세 번째 RBF는 자세히 알아보도록 하겠습니다.

Child-Pays-For-Parent 는 송신자가 수수료를 부족하게 추가한 경우, 수신하는 측의 사용자가 트랜잭션 속도를 높이도록 해줍니다. 이를 위해 수신자는 확정되지 않은 트랜잭션의 출력값을 입력값으로 사용하는 2차 트랜잭션을 전파하고, 평소보다 더 큰 수수료를 결제합니다. 채굴자가 모(母) 트랜잭션의 포함 여부에 따라 유효 여부가 달라지는 자(子) 트랜잭션의 수수료를 원하는 경우, 해당 채굴자는 두 트랜잭션 모두의 인센티브를 받게 됩니다. (CPFP 트랜잭션의 예시를 보려면 여기를 참조하십시오.)

트랜잭션 액셀러레이터 는 온체인 마켓의 부족한 수수료를 지급해 트랜잭션을 확정하는 오프체인 마켓입니다. 일반적으로 채굴 풀에서 트랜잭션 액셀러레이터를 제공하며, 유료/무료 옵션이 존재합니다. 사용자가 액셀러레이터에 트랜잭션 ID를 복사하면 채굴 풀이 높은 우선순위를 두고 해당 트랜잭션을 블록에 포함시킵니다. 서명이 필요없는 관계로 송신자와 수신자 외 모든 사람이 액셀러레이터를 사용할 수 있습니다(예: ViaBTCBTC.com.).

이미지: ViaBTC의 트랜잭션 액셀러레이터

3. RBF로 트랜잭션 대체하기

RBF는 사용자가 처리되지 않은 트랜잭션과 같은 입력값을 최대한 하나 이상 사용하되, 추가 수수료를 지급하는 대체 트랜잭션을 생성하도록 해줍니다. (같은 입력값을 사용하지 않는 경우 전부 별개의 트랜잭션이 됩니다.)

처리되지 않은 트랜잭션의 수수료 범핑과 달리, 트랜잭션 대체는 반복형 결제 배치 설정 등의 강력한 활용 사례에 유용하게 쓰일 수 있습니다. 일반적인 배치 설정 시에는 여러 결제를 같은 트랜잭션에 묶은 다음 게시합니다. 그러나 트랜잭션이 전파되었지만 채굴자가 블록에 포함시키기 전에 일단 트랜잭션을 게시하고, 입력값과 출력값을 추가해 트랜잭션을 반복하는 작업도 마찬가지로 가능합니다.

트랜잭션 대체는 흥미로운 역사를 보여줍니다. 초기 비트코인에서는 트랜잭션 대체가 가능했지만, 이후 사토시는 기능을 비활성화했습니다. 네트워크 내의 노드에 대한 공격 벡터를 막기 위해서였습니다. 수수료율 제한 수단이 부족해지자 공격자가 네트워크에 높은 수수료를 포함하지 않는 대체 트랜잭션을 마구 전파할 수 있게 되었습니다.

이후 Peter Todd가 스팸 방지 및 원래의 트랜잭션보다 높은 수수료를 지급해 트랜잭션을 대체하도록 했을 때의 인센티브 문제를 모두 해결한 BIP125를 선보이면서, 비트코인 코어에서 RBF가 다시 사용되기 시작했습니다.

비트코인 코어에서 이전에 RBF를 금지했다고는 하지만, 사실 RBF가 이전에 완전히 불가능했다는 의미는 아닙니다. RBF는 모든 노드가 자유롭게 선택할 수 있는 메모리풀 정책입니다. 컨센서스 규칙과는 전혀 관련이 없다는 뜻입니다.

합리적인 채굴자는 대체 트랜잭션까지 고려하여 수수료가 가장 높은 트랜잭션을 블록에 포함시키려 합니다. 따라서 BIP125 이전에 맞춤형 정책을 사용할 수도 있었습니다. 채굴자들은 수수료가 높은 트랜잭션을 놓치지 않도록 체크하는 차원에서, 메모리풀에서 다른 채굴자가 포함시킨 트랜잭션을 제외해 채굴자 본인의 성과를 제한하고 있지는 않는지 확인하고자 합니다.
.

4. 확정되지 않은 트랜잭션의 안전에 미치는 영향

RBF는 몇 년 동안 뜨거운 감자였습니다. 확정되지 않은(소위 “Zeroconf”) 트랜잭션이 근본적으로 위험하다고 보는 시각(1, 2, 3)과 이러한 트랜잭션을 어떻게든 처리해야 한다고 보는 시각(4, 5, 6)이 충돌했기 때문입니다. 후자는 비트코인 트랜잭션 속도를 높여 세컨드 레이어 기술 없이도 상용으로 사용할 수 있도록 만들고자 했습니다.

RBF로 이중 지급을 발생시키는 방법: 먼저 사용자가 Zeroconf를 승인하는 판매자를 대상으로 트랜잭션을 생성합니다. 상품을 받은 다음, 판매자 대신 사용자 본인을 대상으로 같은 입력값을 사용하는 두 번째 트랜잭션을 게시합니다. 이 트랜잭션의 수수료가 더 높으므로 채굴자는 두 번째 트랜잭션을 블록에 포함시키며, 따라서 이전 트랜잭션은 효력을 잃습니다.

확정되지 않은 트랜잭션을 대체하는 기능과 판매자가 확정되지 않은 트랜잭션을 받는 상황이 조합되어, 사용자가 해시율을 조절하지 않고도 이중 지급을 할 수 있게 되는 것입니다. 이중 지급을 원하는 사용자에게는 일반적으로 두 가지 옵션이 존재합니다.

첫째, 맞춤형 대체 트랜잭션을 만들 수 있습니다. 기본 내장형으로 이 기능을 지원하는 지갑을 알지는 못합니다만, 기술 지식이 많은 사용자는 자체 소프트웨어를 만들거나, 이미 공개된 트랜잭션 구성 도구튜토리얼을 활용할 수 있습니다.

이미지: 실제 오픈소스 도구로 이중 지급 트랜잭션을 생성하는 가이드

두 번째로 Electrum처럼 기성품으로 제작된 지갑을 사용하되 약간의 추가 설정을 적용할 수 있습니다. 이 경우, 목표는 판매자에게 확정되지 않은 모(母) 트랜잭션의 출력값을 사용하는 자(子) 트랜잭션으로 결제를 진행하는 것입니다. 상품을 받은 후 사용자는 모(母) 트랜잭션에 RBF를 사용해 자(子) 트랜잭션의 효력을 상실시킵니다.

실제로 Zeroconf 트랜잭션을 사용해 이중 지급을 하는 방법을 안내하는 가이드가 널리 퍼진 현실을 고려했을 때, 실제 문제 규모는 얼마나 클까요?

비트코인 캐시는 토큰을 상업용으로 사용할 수 있도록 판매자에게 Zeroconf 트랜잭션을 받아들이도록 적극적으로 권장하는 네트워크입니다. Doublespend.cash에서는 이중 지급 시도 중 성공한 사례와 실패한 사례를 추적하고 있습니다. 2019년 12월에 기록된 이중 지급 시도는 5500건이며, 약 900건(16%)이 성공하였습니다.

이미지: BCH에 대한 이중 지급 시도를 추적하는 doublespend.cash

그러니 시스템을 크게 보았을 때(BCH는 매월 약 100만 건의 트랜잭션을 처리합니다), 이중 지급이 성공하는 확률은 여전히 매우 낮습니다. 그중 판매자와 관련된 트랜잭션이 몇 건인지는 정확히 알 수 없지만, 신용 카드 사기에 비교하면 엄두도 내지 못할 정도로 위험한 문제는 아닌 것처럼 보입니다.

5. 메모리풀 정책으로 이중 지급을 방지할 수 있는가?

RBF 정책에는 다양한 변종이 있습니다. 트랜잭션을 대체하려면 원본 트랜잭션과 동일한 출력값을 전부 사용해야 한다는 조건을 설정하는 First-Seen-Safe RBF(FSS RBF)가 그중 하나입니다. 이 정책에서는 원래의 수신자가 최소한 이전과 같은 금액의 돈을 받게 되므로 이중 지급이 불가능합니다.

그러나 메모리풀 정책이 로컬 기반으로 작동한다는 사실을 다시 떠올려봅시다. 모든 채굴자는 최종 가격을 최대화하는 정책을 선택할 수 있고, 그래야만 합니다. 그러므로 정책의 효과는 채굴자가 자발적으로 얼마나 정책을 많이 선택하느냐에 따라 달라집니다.

FSS는 이중 지급이 없는 시나리오에서 새로운 문제점을 야기해, 실생활에서는 매력도가 매우 떨어집니다. 모든 출력값이 결제금으로 표시되므로(프로토콜이 어떤 결제가 어떻게 바뀌었는지 알 방법이 없기 때문입니다), 출력값을 약간 낮추고 수수료를 높게 설정할 수는 없습니다. 대신 사용자가 새로운 코인을 추가해야만 합니다. 이 코인은

  • 보유하지 않은 코인일 수도 있으며,
  • 트랜잭션의 바이트 크기를 늘리고,
  • 필요한 것 이상으로 코인을 연결하면서 프라이버시를 침해합니다.

결과적으로 기본 시나리오에서 RBF에서 이중 지급을 방지할 방법은 없습니다. 풀 RBF 등의 다른 변종 역시 채굴자가 자발적으로 채택해야 하는데, 이에 따른 인센티브를 특별히 주지는 않습니다. 판매자는 여전히 Zeroconf 트랜잭션을 받아들이고 이따금씩 발생하는 이중 지급을 사업비용으로 처리할 수 있습니다(오늘날의 신용 카드 사기와 유사합니다). 그러나 유의미한 자금이 이동하는 경우에는 최소한 1건 이상의 확인을 받기까지 기다려야 합니다.

6. 기회주의적인 이중 지급

오늘날 대부분의 비트코인 사용자와 사업체는 Zeroconf 트랜잭션의 위험을 이해하고 있습니다. 위험을 알면서도 비트코인을 사용하는 사람은 거래상대방을 신뢰하거나(법적으로 도난의 위험에서 보호받기 때문입니다), 가끔씩 일어나는 도난 사건을 사업비용으로 간주하는 것입니다. 하지만 지난 트랜잭션에서 누구나 이중 지급을 하도록 허용하는 공격이 발생한다면 어떻게 될까요?

재구성 공격 시, 공격자(일반적으로 해시 파워의 대부분을 차지하나 꼭 그럴 필요는 없습니다)는 기존 블록체인을 더 긴 체인으로 교체합니다. 모든 노드가 가장 긴 체인을 따르므로, 노드 역시 사용하는 체인을 자동 전환합니다.

이중 지급 문제에서 재구성을 꽤 자주 언급한 바 있습니다. 이중 지급 공격의 경우, 공격자는 공격자에게서 판매자에게로 이행된 트랜잭션 한 개 혹은 여러 개를 공격자 본인에 대한 트랜잭션으로 대체합니다.

이 경우 기술적으로는 이제 대체된 트랜잭션이 단순히 사라지는 것이 아니라 대기 영역으로 돌아갑니다. 이중 지급 사례에서만 유일하게 대체된 트랜잭션이 더 이상 유효하지 않습니다. 새 트랜잭션이 이미 입력값을 사용했기 때문입니다. 따라서 대체된 트랜잭션은 블록에 포함되지 못합니다.

공격자가 이중 지급 없이 트랜잭션을 대체하는 경우, 대체된 트랜잭션은 여전히 유효하며 메모리풀로 돌아가서 채굴자가 다시 채굴해주기를 기다리게 됩니다. 따라서 공격자가 트랜잭션으로 가득한 최근 블록 10개를 텅 빈 블록으로 대체하면 블록 10개 분량의 트랜잭션이 대기 영역으로 돌아간다는 것을 쉽게 알 수 있습니다.

이미지: 길이가 더 길지만 내용은 없는 체인으로 기존 체인을 대체하는 공격자. 이전에 확정된 트랜잭션은 메모리풀로 돌아가며, 여기에서는 사용자가 트랜잭션을 이중 지급할 수 있습니다.

다른 일이 생기지 않는다면 이 트랜잭션도 결국 다시 블록체인의 일부로 편입될 것입니다. 하지만, 그 사이에 소급성 Zeroconf 정책이 전체 네트워크에 적용됩니다.

이전에 확정되어 블록에 정착한 트랜잭션도 조금 전 작업을 통해 고의로 만들어낸 Zeroconf 트랜잭션과 동일한 상태가 되는 것입니다. 결과적으로 일반적인 Zeroconf 트랜잭션을 이중 지급하는 방법을 똑같이 사용하기만 하면 사용자가 모든 트랜잭션을 이중 지급할 수 있습니다. 중요한 차이점은 거래상대방이 이러한 위험에 준비하지 않았다는 점입니다. 따라서 공격에 걸리는 판돈 역시 훨씬 많아집니다.

이러한 공격을 개인적으로는 퍼지 공격이라고 부릅니다. 공격자가 (처음에는) 돈을 훔치지 않다가 단기간에 걸쳐 네트워크에서 발생하는 절도를 합법으로 만들기 때문입니다.

7. 퍼지 공격의 도입

퍼지 공격을 하기 좋은 때는 언제일까요?

공격자가 이중 지급하고 싶을 때 이러한 퍼지 공격 시나리오를 보게 될 확률은 낮다고 생각합니다. 공격으로 인해 영향을 받는 사람이 많아질수록 공격자에게 불리한 반응의 범위와 이러한 반응이 나타날 확률(예: 직접 체인을 거부하거나 PoW를 변경)이 높아집니다. 이러한 이유에서 수익을 BTC로 계산하는 공격자는 관련이 없는 트랜잭션을 전부 재현하여 네트워크 분열과 기회주의적인 이중 지급의 확률을 막을 동인이 생깁니다.

그러나 퍼지 공격은 흥미로운 사보타주 공격의 유형으로서 비트코인의 확실성에(예: 앞으로의 트랜잭션 종결성) 대한 신뢰를 손상시킨다는 목적을 추구할 수 있습니다. 잠재적인 공격자는 국가가 될 가능성도 존재합니다. 국가는 테러 조직뿐만 아니라 비트코인도 적대적으로 보기 때문입니다.

8. 퍼지 공격과 기타 사보타주 공격의 비교

이미지: 걸프만에서 발생한 사보타주 공격으로 손상된 대형 선박, AFP photo

흥미로운 부분은 퍼지 공격과 공격자가 텅 빈 블록만을 채굴하는 서비스 거부(DoS) 등의 다른 사보타주 공격의 차이점입니다. 사보타주 공격은 네트워크에 큰 부차적 피해를 발생시키며, 따라서 전문가들 입장에서도 침입성이 덜한 공격보다 대응하기가 쉽다고 간주합니다.

예를 들어 Greg Maxwell은 “[검열이 사보타주보다] 더 큰 걱정거리입니다. [검열은] 서브세트를 표적으로 하므로, 비용이 많이 들거나 위험한 문제를 고칠 때보다 정치적 의지를 모으기가 훨씬 어려울 수 있습니다.”라고 밝힌 바 있습니다.

Paul Sztorc은 이렇게 말했습니다. “침입성이 강한 공격은 채굴에서의 “극단적 선택”이라 할 수 있으며, PoW 알고리즘을 바꾸는 사용자의 극단적 선택과 일치시킬 수 있다. 채굴자의 선택에 따라 네트워크가 사용자에게 무용해지므로, 이에 맞서 사용자는 PoW를 바꾸어도 잃을 것이 없다. 최소한 PoW를 변경하면 네트워크의 트랜잭션 처리 기능을 살릴 확률이 조금이라도 존재한다.”

두 전문가 모두 사전 조정(Pre-coordination)이라는 개념에 주목하는 경향이 있습니다. 사전 조정은 방어자에게 최선의 대응책이 자연스럽게 셸링 포인트가 되는지 묻습니다. 모든 사용자가 특정 대응책(예: PoW 변경)이 필요하다는 데 동의하면 이 선택지를 실행하기가 쉬워집니다.

완전한 DoS 공격 대신 퍼지 공격은 이러한 사전 조정에 간섭할 가능성이 있습니다. 공격자는 일반 사용자가 파괴로 인해 혜택을 볼 수 있는 길을 열어주어 커뮤니티 내에서 조정이 이루어지지 않게 합니다. 그 결과 공격자에게 맞서자고 나서는 사람이 적어질 수 있고, 이제 체인을 롤백하려는 경우 사용자가 이중 지급을 포기해야 합니다.

이런 방식으로 공격자가 일부 사용자에게 “이익을 주어” 공격을 지지하게 만든다는 것을 알 수 있습니다. (근처에서 푸드 뱅크를 운영하는 마피아나 차량으로 도망치다가 창문에서 현금을 뿌려 대중의 지지를 얻는 것과 크게 다르지 않습니다.) 이러한 형식의 연맹을 맺으면 정직한 네트워크 사용자가 대응책을 조정하기가 더욱 어려워집니다.

9. 퍼지 공격의 예방

퍼지 공격을 막는 방어의 최전선은 다른 사보타주 공격 때와 같습니다. 사용자는 공격자가 “강제로 입는 피해”를 최대화하고자 합니다.

공격자가 스스로 입는 피해는 공격자의 계좌잔고에서 BTC로 표시한 자산의 양을 기반으로 합니다. 채굴 작업이 미래의 블록 보상을 현재로 끌어오는 것임을 고려했을 때, 블록의 시장 가치는 전적으로 기반이 되는 비트코인 네트워크의 시장 가치에 달려 있습니다. 네트워크에 대한 공격은 공격자 자신의 자산에 대한 공격이 됩니다.

결과적으로 비트코인의 첫 번째 방어벽은 미래 블록 보상의 총합입니다. 이는 공격자가 비트코인을 사보타주하면서 소각해야 하는 자금의 양을 의미합니다. 현재 전문가들은 실제로 대부분의 공격 의지를 꺾을 정도로 방어벽이 비트코인의 네트워크 가치와 균형을 이루지도, 충분히 높지도 않다고 합니다.

두 번째 방어벽은 공격을 당했을 때 비트코인의 사전 조정이 지닌 힘입니다. 지도자가 없는 집단에서는 대부분의 개인이 적절한 대응이 무엇인지 자명하다고 여길 때 효과적으로 공격을 방어해내기가 더 쉽습니다.

공격이 빈 체인을 전파한 직후 정직한 채굴자들 또한 임시로 메모리풀 정책을 바꾸어 초기부터 이중 지급 시도를 막을 수 있습니다. 각 이중 지급이 가격에 미치는 영향에 따라 채굴자들이 추가 수수료를 “그대로 보류해” 장기적인 투자금을 보호하기로 결정할 수도 있습니다. 하지만 이것은 공격자가 사용자의 이중 지급 트랜잭션을 스스로 채굴하지 않았을 때를 가정한 것으로, 현실에서는 일어나지 않는 시나리오입니다.

마지막으로, 공격자의 이중 지급 권유를 받아들일 사람이 얼마나 될지는 불명확합니다. 많은 트랜잭션은 법적 조치, 사용자와 판매자 사이의 상호작용 반복, 기술적 균열의 부족, 또는 단순히 절도 의지 상실로 인해 추가로 보호를 받습니다. 이는 신용 카드의 지불거절로 판매자를 사취할 수 있는 사람이 많지만, 그럼에도 판매자를 공격하지 않는 사람이 존재한다는 사실로 뒷받침할 수 있습니다. 달리 말하면 약간의 사람들만으로도 충분히 동기를 부여한다면 큰 소리를 낼 수 있다는 것입니다.

10. 결론

대체로 퍼지 공격은 기타 유명한 사보타주 공격과 비교했을 때 더욱 위험한 요소는 아닙니다. 그러나 공격자가 방어자의 사전 조정을 특별히 노린다는 점에서 흥미로운 시사점을 던진다고 할 수 있습니다.

사실상 지금까지 발생한 모든 암호화폐 공격은 한 개 이상의 채굴자 트랜잭션에서 이중 지급을 발생시키는 것을 목표로 했습니다. 이중 지급 공격에서 채굴자는 사보타주 공격의 반대되는, 불리한 커뮤니티 반응이 발생할 위험을 최소화하기 위해 부수적 피해를 줄이고자 합니다.

앞으로 이러한 상황이 바뀔 수 있는 원인은 두 가지가 있습니다.

  1. 비용: 미래의 블록 보상 총합(인센티브 + 수수료의 총합)이 감소하면 공격자의 계좌잔고 역시 줄어들 수 있습니다.
  2. 장점: 비트코인이 지정학적으로 중요해진다면 네트워크를 사보타주했을 때의 인센티브가 커질 수 있습니다.

이러한 두 트렌드가 앞으로 계속되면 사보타주 공격의 비용/장점 비율 역시 더욱 매력적인 요인이 될 것입니다.

ARTICLE BY:

Hasu
@hasufl

THANKS FOR FEEDBACK TO:

Su Zhu
@zhusu

James P.
@_prestwich

nic carter
@nic__carter

Mike Co
@burningw0rds

Tarun C.
@tarunchitra

Paul Sztorc
@Truthcoin

Georgios K.
@gakonst

Eric Wall
@ercwl

David V.
@DavidVorick

Mike Kelly
@mikekelly85

Arjun Balaji
@arjunblj

Eli T

RECENT & RELATED ARTICLES: