(ICDE '23) Scaling Blockchain Consensus via a Robust Shared Mempool

Personal

논문 제목에 “Robust” “Shared” Mempool 이라는 단어가 등장한다. 제목을 아주 잘 지었다는 생각이 드는데, 논문의 기본 아이디어가 다음과 같기 때문이다.

1. Shared Mempool : Mempool의 내용을 모든 레플리카가 공유한다는 가정을 통해 leader의 broadcast 부담을 줄이면서 네트워크 관점에서 컨센서스를 경량화
2. Robust Mempool : Mempool 내용이 서로 다른 경우를 방지하기 위한 여러 장치(PAB, DLB)를 도입 (네트워크가 불안정하거나 많은 작업이 한 노드로 몰릴 때, 혹은 비잔틴 레플리카가 존재할 때 대응) Shared mempool abstraction을 사용한 부분은 Sei를 비롯한 다른 시스템들이랑 비슷하지만, 거기서 발생할 수 있는 예외 상황들을 더 정교화했다는 점, 그리고 그것들을 해결하기 위한 효율적인 장치를 마련했다는 점에서 novelty가 있었다. 또한, evaluation에 공을 정말 많이 들인 점이 특징적이었다. 논문의 구조, 논리를 쌓아가는 방식도 아주 좋았고 논문을 위해 리서치를 많이 한 것이 드러나서 정말 많은 것을 배울 수 있었다. 최하단에 적어두었듯이 light client를 어떻게 지원할 것인지도 생각해 볼 만한 것 같다.

Motivation

이 논문은 Leader based permissioned BFT를 타겟으로 하고 있다. 기본적으로 LBFT는 확장성이 떨어지는데, 위 표가 그러한 현상을 나타내고 있다. 표는 Streamlet, Hotstuff, 2CHS(Two chain hotstuff)의 replica 수 증가(4개부터 64개까지)에 따른 throughput의 감소를 나타낸다. 이 중 Streamlet은 예전에 나온 합의 알고리즘이고 현재 많이 사용되는 것은 Hotstuff 및 2CHS이다. Streamlet은 throughput이 급격히 떨어지는 것을 볼 수 있고, Hotstuff 및 2CHS의 throughput은 4개 레플리카에서 120K TPS였으나 64개 레플리카에서는 20K TPS로 떨어지는 것을 볼 수 있다.

Scalability Challenge: Leader Bottleneck

왜 이런 현상이 발생하는 것일까? 원인은 바로 leader bottleneck이다. 왼쪽 그림은 Hotstuff의 컨센서스 과정을 나타낸 것인데, 매 phase마다 리더의 broadcast가 필요한 것을 알 수 있다. 그 결과 오른쪽 표에서 보이는 것처럼 리더의 bandwidth가 non-leader에 비해 많이 소모된다. 따라서 많은 논문[]이 리더의 부담을 줄이는 방향으로 컨센서스 최적화를 시도하고 있다.

Leader: Propose & Commit

앞서 리더의 부담을 줄이는 방향으로 최적화가 이루어지고 있다고 했는데, 리더의 job에는 크게 아래 두 가지가 있다고 할 수 있다.

1. Proposing phase
   • Leader : Forms a proposal and broadcasts it to the other replicas
   • Replicas : Verify the proposal
2. Commit phase
   • Leader : Checks whether all correct replicas have committed to the same proposal 지금까지는 commit phase를 최적화하는 연구가 많았는데, 최근에는 Narwhal이나 RCC 와 같이 proposing phase를 최적화하는 연구도 많이 나오고 있다. 그리고 실제로도 proposing phase의 bottelneck이 더 심하다고 한다. 이건 이 논문에는 디테일이 없지만, arxiv에서 이 논문의 예전 버전(Devouring~)을 보면 appendix에 관련 formal analysis가 있다. 수식이 많아서 핵심만 요약하자면 commit phase에서는 vote를 날리기 때문에 message size가 작고, proposal phase는 proposal을 날리기 때문에 message size가 크다. 따라서 Proposal의 크기가 vote의 크기보다 아주 크다고 가정하면 propose phase가 bottleneck이 되는 것이다.

Note

이런 식의 분류를 처음 보긴 했는데, 아래 hotstuff 그림에서 빨간 부분이 proposing phase이고 그 이후가 다 commit phase인듯 하다. 두개의 중요한 역할로 분류가 되는 거니까 괜찮은 분류인 것 같다. 제안하는 시스템이 4개 phase 중 하나만 수정했다는 점을 생각해 보면 이 분류를 쓰는 게 더 보기가 좋긴 하다.

Contribution

주요 컨트리뷰션은 다음과 같다.

1. Shared Mempool Abstraction 제안
2. 트랜잭션 가용성(Transaction Availability) 보장을 위한 프로토콜 PAB(Provably Available Broadcast) 제안
3. 레플리카 간의 로드밸런싱을 위한 프로토콜 DLB(Distributed Load Balancing) 제안
4. Hotstuff, PBFT 등과 논문에서 제안하는 시스템인 Stratus를 결합하여 기존 시스템과 비교 분석

System architecture

Shared Mempool Abstraction

Shared mempool abstraction은 트랜잭션 전파와 컨센서스 알고리즘을 분리하는 목적으로 만들어졌다. 그 이유는 앞서 말했듯 컨센서스에서 리더의 proposal 전파가 병목이기 때문이고, proposal은 트랜잭션으로 구성되어 있기 때문이다. 보다 구체적으로 아래와 같은 방식으로 트랜잭션 전파와 컨센서스 알고리즘을 분리한다.

• 트랜잭션 데이터는 클라이언트로부터 수집되는 대로 레플리카 사이에 전파한다
  • 전파 단위는 트랜잭션 하나일 수도 있고, 트랜잭션의 배치(미니블록)일 수도 있다
  • 전파받은 트랜잭션은 각자의 로컬 멤풀에 저장된다
• Proposal은 트랜잭션의 id만을 포함한다
  • 따라서 proposal size가 매우 줄어들며, batch 크기가 커질수록 더 많이 줄어든다 (그러나 배치처리로 인한 대기시간 때문에 trade-off가 존재)
• Non-leader 레플리카는 자신의 로컬 멤풀에서 트랜잭션을 끌어와 실제 트랜잭션으로 proposal을 채운다
  • 로컬 멤풀에 트랜잭션이 없는 경우, 다른 레플리카에게 트랜잭션을 요청
  • 이 과정은 컨센서스 알고리즘과는 독립적으로 작동한다
    • 이것이 가능한 이유는 PAB에서도 나오겠지만 트랜잭션이 없어도 대부분의 레플리카들이 그 트랜잭션을 가지고 있다는 사실이 검증되면 해당 트랜잭션에 vote할 수 있기 때문이다. 대부분의 레플리카들이 트랜잭션을 받았다는 사실을 검증하는 것은 뒤에서 나오겠지만 signature aggregation을 통해 수행된다. 정리하자면 propose phase는 다음과 같은 순서로 진행된다

1. 네트워크로부터 트랜잭션을 받은 레플리카는 자신의 멤풀에 해당 트랜잭션을 저장한다
2. 만약 해당 트랜잭션이 클라이언트로부터 온 경우, 이를 broadcast한다
   • 중복 전파 방지를 위해 gossip 대신 broadcast 방식을 이용한다
3. 리더는 로컬 멤풀에서 proposal을 구축한다
4. 리더는 proposal을 제안한다. 즉, 레플리카들에게 broadcast한다
5. 리더가 아닌 레플리카는 로컬 멤풀을 기반으로 받은 proposal을 재구축한다
6. 이후 commit phase를 진행하고, executor에게 commit된 proposal을 보낸다

Data Structure

Microblcok, Proposal, Block의 세가지 개념이 등장하기 때문에 한번 정리를 하고 넘어가려고 한다. 먼저 Microblock은 트랜잭션이 단순 배치된 결과이고, unique한 microblock id(txid들로부터 파생)를 가진다. Proposal은 microblock id를 포함하고 있으며, 해당 id에 상응하는 microblock들을 로컬 멤풀에서 찾아서 대치하면 block이 된다. 모든 microblock을 찾지 못한 경우 일부 microblock만 대치된 상태로 대기하면서 다른 레플리카에게 요청을 보내게 되는데, 이를 partial block이라고 부르기도 한다.

Challenge 1: Missing Transaction

Shared mempool protocol을 나이브하게 사용하면 발생하는 문제가 두 가지 있는데, 그 중 첫번째가 missing transaction 문제이다. Missing transaction이란 proposer의 proposal에 있는 microblock id가 reference하고 있는 microblock이, 프로포절을 받은 레플리카의 멤풀에 없는 경우를 의미한다. 단순히 말해 내가 레플리카인데 프로포절을 채우려고 microblock id 를 로컬 멤풀에 검색했더니 그런 microblock이 없다고 나오는 것이다. 예를 들어 악의적인 레플리카가 자신이 받은 트랜잭션(or microblock)을 broadcast하는 것이 아니라, 리더에게만 보낸다고 해 보자. 리더는 이후 자신의 proposal에 해당 microblock id를 넣을 것이다. 그렇다면 다른 레플리카들은 해당 트랜잭션을 가지고 있지 않기 때문에 1) 뷰체인지가 자주 일어나거나 2) 리더를 향한 fetch 요청이 쏟아지게 된다.

Solution 1: PAB(Provably Available Broadcast)

위 문제를 극복하기 위한 방안이 PAB이다. 기본 아이디어는 유효한 microblock이 되기 위해서는 쿼럼 q개의 서명을 받아야 한다는 규칙을 적용하는 것이다. 이 서명은 proposal에도 첨부되어서 레플리카들에 의해 검증받는다. Missing transaction이 발생하더라도 이 서명이 검증되기만 하면 레플리카는 proposal이 유효하다고 판단한다. 그리고 별도의 프로세스로 서명을 한 q개 레플리카 중 하나에게 microblock을 요청한다. 위 예시에 PAB를 적용해 보면, 1) 유효한 서명을 가지고 있는 이상 뷰체인지는 일어나지 않으며 2) missing transaction에 대한 요청은 리더에게 집중되는 것이 아니라 서명한 q개 레플리카들에게 분산된다.

보다 구체적으로 PAB는 push phase, recovery phase의 두가지 단계로 진행된다.

Push Phase

• 리더가 마이크로블록을 broadcast한다 꼭 리더가 할 필요가 있을까? 지금은 서명을 리더가 가지고 있어야 하니 리더가 해야 하지만, 이걸 분산해서 병목을 더 줄일 수 있지 않을까? 결국 레플리카가 리더한테 tx를 전송하고 다시 리더가 broadcast 해야 하니 불필요한 전송이 하나 추가되는 것 아닌가? 만약 누구나 하게 하려면 어떻게 해야 하지?
  • 그러면 리더에게 서명이 없으니, 서명만 보고 투표할 수 없는 점, 누구로부터 가져와야 하는지 모르는 점 등이 문제가 됨
  • 뭔가 약속을 해서 모두가 각자의 미니블록을 만들고 그걸 합쳐서 블록을 만드는 건 어떨까? 마치 허니배저 비슷하네
  • 근데 쓸모없을 것 같은게, 리더한테 tx를 전송할 필요 없이 자기가 리더되면 제안하려고 하는거같음. 그니까 unbalance workload 이야기도 나오는 거고. 자기가 리더 아닐때 서명을 모아두면 되니까 별로 병목이 되지 않음
  • 근데 여기서 gossip 쓸 수 있지 않나? 서명한 애한테는 안보내고, 내가 q번째 서명자면 처음 보낸 애한테 다시 보내주는거지 → 그러면 DLB도 더 간단해질거 같기도 하고 모르겠네
• 레플리카는 {PAB-Ack|microblock id}에 대한 서명으로 응답한다
• 리더는 이러한 서명 q개를 모아 succint proof σ 를 생성한다.

Recovery Phase

• 리더는 서명 σ를 전파한다
• Missing transaction이 발생한 레플리카는 σ 에 서명한 q개 레플리카 중 하나에게 fetch 요청을 보낸다

주의할 점은 PAB는 컨센서스 알고리즘의 일부가 아니라는 것이다. PAB, DLB는 모두 컨센서스 알고리즘이 아니라 shared mempool protocol에 정의된 멤풀의 역할에 해당한다.

Decoupling via PAB

여기까지 합쳐서 어떻게 decoupling이 이루어졌는지 설명하기 위해, 레플리카가 proposal을 받으면 어떤 과정이 일어나는지 보자.

1. Proposal 내의 PAB proof를 모두 검증한다
   1. 검증 실패시 → View change 과정 진입 (여기서 중단됨)
   2. 검증 성공시 → Commit phase 진입 (이후 3~ 동시 진행)
2. Proposal과 관련된 microblock을 로컬 멤풀에서 끌어와 블록 생성
3. Missing transaction이 발생하면 fetch
4. Commit 상태 확인 후 commit되면 실행 여기서의 핵심은 1-2와 3 이후가 독립적으로 돌아간다는 사실이다. 즉 commit phase를 진행하면서 동시에 3 이후를 실행한다. 따라서 트랜잭션 전파와 컨센서스가 분리된 것이다!

Challenge 2: Unbalanced Workload

두번째 챌린지는 워크로드의 불균형이다. 여기서의 워크로드는 클라이언트의 트랜잭션을 의미하며, 워크로드의 불균형이란 노드의 리소스가 다 다르고 (가까운 노드를 선호할 것으로 예상되는) 클라이언트의 지리적 위치가 불균형한 상황을 의미한다. 리소스 대비 워크로드가 많은 레플리카들은 트랜잭션을 전파하는 것 역시 늦어지기 때문에 병목이 될 수 있다. 이를 해결하기 위한 나이브한 솔루션은 broadcast 대신 gossip을 사용하는 것이다. Gossip을 사용하면 트랜잭션의 전파 책임을 모든 레플리카가 나누어 가지므로 워크로드의 balance를 맞추는 효과가 있다. 그러나 redundancy가 많이 발생하기 때문에 적절하지 않다.

Solution 2: DLB(Distributed Load Balancing)

이를 해결하기 위해 바쁘지 않은 레플리카를 프록시로 사용하여 바쁜 레플리카 대신 트랜잭션을 전파하는 DLB를 제안한다. 레플리카들은 DLB 프로토콜을 돌리면서 다음과 같은 일을 수행한다.

1. 바쁜 레플리카는 랜덤 d개의 레플리카를 뽑는다
2. 뽑힌 레플리카들 중 가장 덜 바쁜 레플리카에게 트랜잭션을 넘긴다
3. 프록시 레플리카는 트랜잭션을 전파하고 PAB proof까지 만들어 다시 돌려준다 여기서 프록시가 트랜잭션 전파를 거부할 수 있으니 timeout을 두고 응답이 오지 않으면 1)부터 다시 시작한다. 그런데 문제는 레플리카가 ‘바쁜 정도’를 어떻게 정량적으로 평가할 수 있는가 하는 것이다.

Workload Estimation: ST(Stable Time)

Stable time이라는 개념으로 레플리카의 바쁜 정도를 평가한다. Stable time이란 레플리카가 트랜잭션을 broadcast한 뒤에 쿼럼 시그니처 q개를 받기까지 걸린 시간이다. 이렇게 측정하는 이유는 네트워크 딜레이가 평소에는 거의 일정한데 레플리카의 워크로드가 많을 때 튀는 모습을 보이기 때문이다. 따라서 네트워크 딜레이를 반영한 ST를 측정하여 ST가 길면 레플리카가 바쁘고, 짧으면 바쁘지 않다고 판단한다. 이 때 ST가 길다는 것은 기준값 $\alpha +ϵ$ 보다 큰 경우를 의미하며, 자세한 설명이 나와있지는 않았으나 평균적인 딜레이를 측정하여 $\alpha$와 $ϵ$ 을 구한다고 한다.

Implementation

Status

구현체의 이름은 Stratus이며, Bamboo라는 툴으로 프로토타입을 만들었다고 한다. 해당 툴은 이 논문의 1저자가 예전에 썼던 논문에서 제안한 것으로, BFT 프로토콜의 벤치마킹이나 프로토타이핑 등을 편하게 해 주는 툴이라고 한다. 또한 Boldyreva’s threshold signature라고 하는 널리 쓰이는 threshold signature가 있는데, 이것보다 ECDSA 서명을 concat하는것이 더 computationally 효율적이었기 때문에 후자를 선택했다고 한다. 아마 proposal의 사이즈를 크게 줄인 이상 공간적으로 더 최적화할 필요는 없다고 판단한 것 같다.

Testbed & Metrics

테스트 환경으로는 4vGPU와 8GB 메모리 인스턴스에 레플리카를 실행했으며, LAN환경과 WAN환경을 모두 실험하였다. Metric으로는 latency와 throughput을 측정했다. 여기서 latency는 레플리카가 (아마 클라이언트로부터) 트랜잭션을 처음 전파받은 시점부터 해당 트랜잭션이 커밋되는 시점까지를 의미한다. End-to-end 딜레이는 네트워크 딜레이의 영향을 제거하기 위해 측정하지 않았다고 한다. Throughput은 구체적으로 나와있지 않았지만 뒤에 TPS 단위가 나오는 것을 보면 1초에 얼마나 많은 트랜잭션이 커밋되었는지를 측정한 것으로 보인다.

Evaluation

Protocols

Evaluation에서 많은 프로토콜들의 성능을 실험했는데, 아래 표에 간단한 설명이 나와 있다. 이 이름들은 아래와 같은 네이밍 규칙이 있어서 규칙만 알면 구분하기 쉽다.

• N- : Native version
  • N-HS와 N-PBFT는 수정이나 최적화 없이 원 논문에서 쓴 알고리즘을 그대로 사용한 Hotstuff 및 PBFT이다
• SMP- : Shared mempool version (w/o PAB, DLB)
  • SMP-HS-*는 Hotstuff에 나이브한 버전의 shared mempool protocol을 적용한 것으로, PAB나 DLB가 없는 버전이다
• -G : Gossip version
  • Transaction 및 proposal을 전달할 때 broadcast 대신 gossip을 사용하는 버전이다
  • 로드밸런싱이 약간 가능하다
• -Even : Even workload
  • 워크로드가 모든 레플리카 사이에 동일한 버전이다
• S- : Stratus version (this paper)
  • Stratus 멤풀을 적용한 것으로, PAB나 DLB가 붙어있는 버전이다. 또한 Narwhal과 MirBFT라는 최근 등장한 shared mempool 프로토콜들과도 비교를 진행한다.(Narwhal은 아마 Narwhal and Tusk를 의미하는 듯 하다. Tusk에 대한 언급은 없지만, 당연히 그렇지 않을까 하는…)

Scalability

전체적인 scalability는 N-, S-, MirBFT와 Narwhal을 비교하면 알 수 있다. 본 논문에서는 DLB와 PAB가 발생시키는 컨센서스 오버헤드가 없다는 사실을 보여주기 위해 SMP-HS와도 비교를 진행한다. LAN 환경과 WAN 환경에서 측정을 진행했다고 하며, batch size는 최적화 가능한 지점으로 골랐다고 한다. 그 결과 다음 사실을 알 수 있다.

1. N-HS, N-PBFT는 확장성이 떨어진다 (주황색과 초록색)
   • 우선 LAN 환경에서는 16개 이상의 레플리카부터 현저히 throughput이 떨어지는 모습을 보였고, latency도 급격히 올랐다
   • WAN 환경에서도 마찬가지로 낮은 throughput을 보여줬고, 레플리카가 많아질수록 latency가 급격히 올라가는 모습을 보여준다.
2. Narwhal은 broadcast primitive가 무겁기 때문에 확장성이 낮다
3. MirBFT는 PBFT 자체가 메시지 컴플렉시티가 높기 때문에 throughput이 낮다
   • Stratus를 결합한 S-PBFT 역시 MirBFT와 유사한 성능을 보인다
   • 이것을 굳이 언급한 이유는 S-PBFT로 아주 큰 이득을 보지는 않지만 기본구현보다는 확실히 낫고, 레플리카가 많은 상황에서 MirBFT랑 비슷하다 정도를 말하려고 한 거 아니었을까 싶다.
4. SMP-HS와 S-HS는 성능이 비슷하다. 즉, PAB나 DLB가 성능적으로 오버헤드를 발생시키지 않는다 따라서 S-HS가 짱짱맨이다.

Missing transactions (PAB)

PAB의 효과를 측정하기 위해서는 SMP-HS-Even와 S-HS를 비교하면 될 것이다. 그런데 이상하게도 논문에서는 PAB의 효과를 SMP-HS vs S-HS로 측정하는데, 해당 실험에서 워크로드는 평등하게 분배되기 때문에 SMP-HS-Even이나 다름없다. 왜 이렇게 쓴 건지는 의문이다.

Case 1) Byzantine replica

실험을 위해 앞서 말한것과 같은 비잔틴 레플리카의 예시를 가정한다. 공격자의 목표는 리더로 하여금 리더의 proposal안에 missing transaction을 포함하게 하는것이다. PAB가 없는 SMP-HS에서는 공격자가 리더한테만 트랜잭션을 보내면 된다. 그러면 missing transaction에 대한 fetch 요청이 리더한테만 전송될 것이다. 반면 PAB를 같이 쓰는 S-HS에서는 리더에게 트랜잭션을 보내는 것만으로는 공격이 성립하지 않는다. 쿼럼 이상의 사인을 받아야 해당 마이크로블록이 proposal에 들어갈 수 있기 때문이다. 따라서 쿼럼이 f+1이면 리더랑 f개의 다른 레플리카한테 트랜젝션을 보내줘야한다. 논문에서는 100개 레플리카, 200개 레플리카에 대해 비잔틴 노드 수를 늘려가면서 테스트를 진행했다. 결과적으로 당연히 PAB를 쓰는게 더 좋았다. 쿼럼 수를 f+1, 2f+1로 바꿔가며 테스트를 해봤는데, 쿼럼이 많아지면 proof 생성 및 proposal까지 시간이 그만큼 걸리므로 latency가 높아진다. 하지만 악의적인 레플리카 수가 throughput에 미치는 영향이 상대적으로 적은 것을 볼 수 있다.

Case 2) Network Asynchrony

Missing transaction이 발생할 수 있는 또다른 환경으로 네트워크 fluctuation이 심한 경우가 있다. 네트워크가 좋지 않은 레플리카는 그만큼 마이크로블록을 전달받지 못할 확률이 높다. 실험을 위해 NetEm을 이용해 네트워크 fluctuation을 발생시켰으며, 10초동안 평균이 200ms라고 하면 100ms에서 300ms 사이로 계속 fluctuate하게 만들었다. 당연히 PAB를 쓰는 것이 좋았다. S-HS는 마이크로블록에 missing transaction이 있어도 증거만 통과하면 컨센서스는 그대로 진행시키고 따로 트랜잭션을 받아오기 때문에 뷰 변경이 발생하지 않아서 성능이 크게 변하지 않았다.

Unbalanced Workload (DLB)

DLB의 효과를 측정하기 위해서는 S-HS-Even(ideal case), SMP-HS(without DLB), SMP-HS-G(naive solution)과 S-HS(with DLB)를 비교하면 된다. 실험을 위해 지피안 분포로 워크로드를 분배하였다. 이 분포를 이용한 이유는 실제로 워크로드가 power law distribution이라는 분포를 따른다는 연구 결과가 있는데, Zipfian 분포가 이 power law 분포의 일종이라서 쓴 것으로 보인다. 두개의 지프 분포가 있고 각자 s, v 를 다르게 해서 분포의 skew된 정도를 바꿔가며 테스트했다. 이 s,v는 분포의 모양이랑 오프셋을 결정하는 파라미터들인데, 간단히 말해 S=1.01, v=1 일 때는 한쪽에 워크로드가 더 많이 몰려있는 상태고, v = 10일때는 덜 몰려있는 상태라고 보면 된다. Unbalance 정도가 심할 때는 Stratus가 SMP-HS보다 100 개 레플리카에 대해 5배, 400개 레플리카에 대해 10배 좋은 것으로 나타났다. 여기서 d = 1, 2, 3은 샘플링 개수로, d = 3이면 세개의 랜덤 레플리카를 뽑아서 그 중 가장 덜 바쁜 레플리카를 프록시로 쓰는 것이다. 특이한 점은 Unbalance 정도가 심하지 않을때도 Stratus의 성능이 좋았는데, 특히 gossip의 경우에는 성능이 확 낮아지는걸 볼 수 있었다. 이건 메시지 redundancy가 성능을 저하시키기 때문이다.

Personal Thoughts

No Support with Light Client?

본 시스템은 vote가 트랜잭션 데이터 없이 이루어질 수 있다는 가정에 기반하는 것으로 보인다. 따라서 commit phase와 missing transaction fetch가 동시에 일어날 수 있다. 해당 가정은 light client를 지원하는 많은 블록체인 프로젝트에 적용하기 어려워 보인다. 예를 들어 대표적인 블록체인 이더리움을 생각해 보자. 이더리움의 블록에는 트랜잭션 데이터 뿐만 아니라 state root, reciept, transaction root 등이 담겨 있다. 이더리움의 검증자들은 이를 바탕으로 1) 트랜잭션의 유효성(signature, structure …)과 2) state transition의 유효성을 검증한 후, 두 검증이 통과하는 경우에만 해당 블록에 vote한다. 이 중 두번째 유효성은 light client를 지원하기 위한 과정으로, state root 같은 정보를 블록에 넣는 이유 역시 light client를 지원하기 위함이다. (Light client가 머클 루트를 통해 상태의 유효성를 검증해야 하기 때문) Light client는 블록체인 데이터에 접근하는 중요한 수단이며 “Don’t trust, verify”를 달성하기 위한 필수적인 요소이다. 따라서 어떻게 light client를 사용하면서 Stratus의 컨셉을 적용할 수 있을지 생각해볼 필요가 있을 것 같다. (Sei는 트랜잭션을 천천히 나눠서 받는 듯 하다. 이게 얼마나 효과가 있을지도 궁금하다.) 또 생각나면 쓰러 올게요. 생각이 났었는데 까먹었어 배고파서 머리가 안돌아가네여;;

Censorship resistance?

Narwhal에서 발췌하자면, SMP에는 다음과 같은 두 가지 문제가 존재한다.

Censorship issue in SMP

(i) A very fast validator may force others to perform large downloads by generating blocks at a high speed; (ii) honest validators may not get enough bandwidth to share their blocks with others – leading to potential censorship

즉 성능이 좋은 밸리데이터가 그렇지 않은 밸리데이터의 밴드위쓰를 장악하여 전체 체인이 특정 주체의 트랜잭션만 담는, 검열 상황이 발생할 수 있다는 것이다. 아마 이 부분 때문에 이 논문이 permissioned network를 가정한 것으로 보인다. 그러나 permissionless network로 확장하기 위해서는 검열저항성에 대한 부분을 반드시 해명해야 할 것으로 보인다.

Comparison with Narwhal?

읽으면서 두 가지 의문점이 들었는데, 둘 다 narwhal과의 비교가 공정한가에 대한 의문점이었다.

• Narwhal은 tusk에 최적화되어있는데, Narwhal + Hotstuff를 비교 대상으로 삼는 것이 공정한가?
• Narwhal은 asynchronous network model을 가정하며, 이 때문에 reliable boadcast(RB 혹은 RBC)의 사용이 필수적이다. 이에 대해 “consistency와 totality는 합의 알고리즘 레벨에서 보장되므로 RB 대신 PAB를 사용해도 된다”는 논리를 펼치는데, 이는 asynchronous model에서는 정당화되지 않는 것처럼 보인다. 즉, 이러한 주장은 이 논문이 가정하는 partially synchronous model 하에서만 가능한 논변이다. 그렇다면 먼저 partially synchronous model을 가정하는 것이 마땅함을 보여야 하는 것 아닌가?

Narwhal + Hotstuff?

Narwhal은 Tusk에 최적화되어 있으며, Tusk의 communication overhead를 줄여주는 역할을 한다. 반면 본 논문은 Tusk가 아닌 Hotstuff를 Narwhal과 결합하여 실험을 진행한다. 물론 본 논문이 partially synchronous model을 가정한다는 점에서 어느정도 참작이 가능하나 진정 의미있는 비교일지는 의문스럽다.

Replacing RB with PAB?

본 논문은 Narwhal의 RB를 PAB로 대체하면서 다음과 같은 문구를 덧붙인다

Quote

We observe that some properties of reliable broadcast are not needed by SMP since they can be provided by the consensus protocol itself (i.e., consistency and totality).

그러나 이는 해당 모델이 가정하는 partially synchronous model에서나 가능한 주장이다. Narwhal은 asynchronous network model을 가정하는데, 해당 모델은 브로드캐스트 결과 얼마만큼의 메시지가 드랍될지, 언제 메시지가 도착할지 모른다는 특징을 가지고 있다. 따라서 RB를 사용하여 브로드캐스트 메시지가 전달된다는 보장을 얻는 것이고, 이것이 RB가 asynchronous model에서 핵심적인 primitive로 사용되는 이유이다. 만약 asynchronous model을 사용하지 않고 partially synchronous model을 사용한다면 자연스럽게 RB는 오버엔지니어링이 되고, 이를 PAB와 같은 가벼운 프로토콜로 대체할 수 있게 된다. Narwhal과의 비교에서 본 논문이 제안하는 시스템이 더 좋은 성능을 내는 이유가 RB를 PAB로 대체한 지점에 있는 것처럼 보이는데, 이는 고유한 노벨티라기보다도 상대적으로 덜 엄격한 네트워크 모델을 가정하여 나타난 자연스러운 결과라고 이해해야 할 것 같다. (물론 많은 논문과 블록체인 프로토콜들이 partially synchronous model을 가정한다는 점에서 이러한 시도가 유용하고 필요하다고 생각한다)

MEV?

보다시피 microblock마다 id가 존재하고, microblock 단위로 트랜잭션을 배열하니 MEV 효율성이 떨어진다. 하나의 microblock 내에서도 트랜잭션을 정렬할 수 없고, microblock 간 정렬도 불가능하다. 이는 블록으로 트랜잭션을 전파하는 SMP의 특성상 항상 발생하는 문제로 보인다. Txid로 제안하되, microblock id도 병기하여 microblock을 끌어왔을 때 해당 tx들이 들어있는지를 확인하는 방식으로 어느 정도 해결 가능해 보이지만, microblock의 일부를 제안할 수 없기 때문에 좀 더 복잡한 구현이 필요하게 될 것 같다.