이더리움 - Consensus

Consensus(합의)

• 블록체인에서 합의는 모든 노드간의 합의를 도출하는 프로세스를 가리킨다.

• 분산 시스템에서 중요한 개념으로, 중앙화된 조직이 없기 때문에 합의 알고리즘이 필요하다.

• 여러 참가자 간의 동일한 데이터 상태를 유지하기 위해 필요하다.
• 이더리움의 경우 네트워크의 노드 중 최소 66%가 동의해야 합의가 완료된다.
• 분산형 블록체인 시스템에서는, 모든 사람이 거래 순서에 동의하는지 확인해야 한다.
• 채굴자들은 블록을 생성하기 위해 계산적으로 어려운 퍼즐을 풀고, 공격으로부터 네트워크를 보호함으로써 이를 도왔다.

작업 증명(POW)

• 비트코인에서 사용, 이더리움은 2022년 이후 지분증명으로 전환

• 작업 증명은 체인에 유효한 블록을 추가하는 행위로써, 점점 난이도가 높아진다.

채굴 방식

1. 채굴자는 계정의 개인 키를 사용하여 거래 요청을 작성하고 서명

2. 거래 요청을 전체 이더리움 네트워크로 브로드캐스트

3. 새로운 거래 요청을 받으면, 이더리움의 각 노드는 요청을 자신의 로컬 mempool 에 추가

4. 채굴 노드는 블록 가스 한도를 유지하며 얻는 거래 수수료를 최대화하는 방식으로 수십/수백개의 트랜잭션 요청을 블록으로 집계
1. 각각의 트랜잭션 요청의 유효성 확인 후 요청 코드를 실행하여 그들의 로컬 EVM 상태 변경, 거래 수수료를 자신의 account에 지급
2. 블록의 모든 거래 요청이 확인되고 로컬 EVM 복사본에서 실행되면 블록에 대한 작업 증명 인증서를 생성

5. 채굴자는 블록 인증서 생성 완료 후 완성된 블록을 브로드캐스트

6. 다른 노드들은 새 블록을 받아 인증서 확인, 트랜잭션 실행, EVM의 체크섬이 일치하는지 확인

7. 네트워크에 합류하는 새로운 노드는 새 블록이 포함하여 모든 블록을 순서대로 다운로드, 각 블록의 상태 체크섬을 확인해야 함.

지분 증명(POS)

• 지분증명은, 무작위로 선정된 검증인이 블록을 생산하고 승인할 목적으로 네트워크의 토큰을 스테이킹하여 진행한다. 스테이킹의 경우 두 가지 옵션이 있다.
• 검증인
• 자체 노드 전체의 실행을 담당하여, 블록체인에 추가되기 전 들어오는 각 블록의 유효성을 확인
• 최소 32개의 이더리움 스테이킹이 필요
• 적은 양의 이더를 가진 사람들은, 협업하여 스테이킹 풀에 참여하여 검증인이 될 수 있다.

• 검증인은 총 지분에 따라 보상을 받는다.

• 검증에는 실행 클라이언트, 합의 클라이언트, 검증 클라이언트가 필요하다.

지분 증명에서 트랜잭션이 실행되는 과정

1. 사용자는 개인 키를 사용하여 트랜잭션 생성, 서명
1. ether.js, web3.js와 같은 라이브러리를 통해 JSON-RPC API를 통해 노드로 요청을 보냄
2. 이 과정에서 gas의 priority fee 가 검증인에게 지급, 나머진 소각

2. 트랜잭션은 실행 클라이언트에게 전송됨, 올바른 트랜잭션인지 확인
1. 보통 Validator들은 생성된 이전 블록들 중 반드시 하나를 가리켜야 하는데, 보편적으로 길이가 가장 긴 체인의 마지막 블록을 가리키게 된다.
2. 결과적으로 대부분의 블록들은 단일 체인에 모이게 된다.

3. 트랜잭션이 유효하면, 실행 클라이언트는 이를 로컬 mempool 에 추가 후 gossip 를 통해 다른 노드에게 브로드캐스팅
1. mempool: 아직 거래가 성립되지 않은 트랜잭션들이 저장되는 공간
2. 다른 노드도 트랜잭션을 받으면 로컬 mempool 에 추가

4. 그렇게 다수의 노드들이 검증을 승인하면, 해당 블록은 finalized 가 되어 블록체인에 영구적으로 연결된다.

• 브로드캐스팅 : 네트워크 상 모든 노드에게 메세지를 전달함

• 가십(Gossip) : 랜덤으로 선택한 일부 노드들에게만 정보를 전달하고, 그 노드들이 또 이웃 노드들에게 전달하고 하는 방식으로 진행

비콘 체인

• 비콘 체인은 샤드 체인들이 병렬적으로 작동하면서, 동기화 상태를 유지할 수 있도록 하는 블록체인을 의미한다.

• 기존의 채굴자 대신 거래 검증인이 토큰(지분)을 걸고 투표한 뒤 투표 결과에 따라 거래를 검증, 네트워크를 운영하는 방식의 이더리움 거래 검증 시스템이다.

• 비콘체인은 POS의 유효성 검증을 위한 검증인들을 관리하고 검증 작업을 수행한다.
• 이더리움 2.0은 샤딩을 가종하는데, 비콘체인은 각 샤드에 노드를 무작위로 배정해 담합/공격을 방지한다.

작업 증명과의 비교

1. 에너지 효율성이 좋아짐 → 진입 장벽이 낮아지고, 하드웨어 요구 사항 감소

2. 에너지 요구량이 낮기 때문에, 참여 촉진을 위한 새로운 ETH 발행이 덜 필요해짐

3. 51% 공격에 더 안전해짐 → 51% 공격을 위해선 총 이더리움의 51%를 소유해야 가능

Raft

1. Raft 합의 알고리즘은 리더를 중심으로 동작하며, 선거를 통해 리더를 선택합니다.

2. 리더가 클라이언트의 요청을 처리하고 모든 노드에 로그를 복제하여 일관성을 유지합니다.

3. 리더가 다운되면 다른 노드가 리더 선출을 요청하여 시스템의 연속성을 보장합니다.

1. Leader-Follower

• Leader-Candidate-Follower의 클러스터 구조를 사용
• Leader
• 클러스터에서 이뤄지는 모든 변화를 기록하고 관리하는 역할
• Follower
• 데이터를 읽는 기능과, 자신이 처리할 수 없는 요청을 리더로 전달하는 기능
• Candidate
• 현재 클러스터에서 리더에 문제가 생긴 경우, 리더가 될 자격을 갖춘 팔로워 노드

2. 로그 복제

• 클라이언트로 부터 새로운 요청이 전달되면, 리더는 로컬에 해당 로그를 저장하고 로그를 복제하여 팔로워 노드들에게 전송한다. 모든 로그는 고유한 인덱스 값을 갖는다.

• 요청의 순서가 올바른 경우, 팔로워는 해당 로그를 복제하고 성공 응답을 리더에게 전달한다.

• 요청 순서가 올바르지 않거나 장애가 생긴 경우, 팔로워는 실패 응답을 리더에게 전달한다.

• 리더는 상태를 파악하고 밀린 로그들을 팔로워에게 다시 진행하여 복구를 진행한다.

• 과반수 이상의 노드에서 성공 응답이 도착하면, 리더가 마지막으로 해당 로그를 커밋하고, 클라이언트에게 성공 응답을 전송한다.

3. Election

• 리더는 클라이언트로부터 새로운 요청이 없더라도, 지속적으로 팔로워에게 자신이 살아있음을 알린다.

• 만약 리더에 문제가 생겨 응답이 없으면, 팔로워는 리더가 되기 위한 후보자가 되어 투표를 실시한다.

• 과반의 응답을 얻은 노드는 리더로 선출된다.

BFT, PBFT

• 비잔틴 장군 문제
• 제국에 두 명 이상의 장군들이 적군을 무찌르기 위해 동시에 공격하는 상황에서 발생하는 상황에 대한 시나리오를 분산 시스템에 대비해 제시한 문제점

비잔틴 장군 문제는 비잔틴 군대의 여러 부대가 그들이 포위한 도시 밖에서 서로 상당히 떨어진 위치에 진을 치고 있는 상황을 가정한다. 각 부대를 통솔하는 장군은 공격 시점과 후퇴 시점을 알아서 결정해야 한다. 각각의 부대들이 때를 맞춰 유기적으로 공격해야 전쟁에서 승리할 수 있기 때문에 장군들의 결정은 아주 중요하다. 만약 동시에 공격하지 못할 경우 패배로 끝날 확률이 높다. 

문제는 이 전장에 컨트롤타워가 없다는 것이다. 그러나 장군들끼리 (횃불이나 연기 또는 오늘날의 휴대폰처럼) 신호를 맞출 만한 안전한 통신 방법도 없다. 엉뚱한 수단을 사용했다가 아군 사이에 있는 첩자가 장군들 사이에 보내는 신호를 가로채고, 파괴하거나 조작할수도 있고, 보낸 메시지가 중간에 소실될수도 있다. 반면, 메시지가 성공적으로 전달되더라도 다음과 같은 질문이 남아있다. 이 메시지를 신뢰할 수 있을까? 혹시 장군을 속이기 위해 반역자가 전령을 납치한 후 메시지를 바꾼 것은 아닐까? 복잡하다. 그렇다면 각 부대의 장군은 어떻게 대처해야 할까.

• PBFT(프랙티컬 비잔틴 장애 허용)
• 비잔틴 장애란 네트워크에서 악의적인 행위를 하는 노드가 있을 때 발생하는 문제를 의미한다.
• 일부 노드들이 합의를 형성해 블록을 생성하고, 악의적인 행위를 하는 노드를 식별하여 처리한다.
• 높은 신뢰성과 성능을 제공하지만, 네트워크 내 노드 수가 고정되어 있어야 해 대규모 네트워크엔 적합하지 않을 수 있다.
• 과정
• 매 시간마다 리더를 선출한다. 리더는 클라이언트의 요청을 노드들에게 전파하는 역할을 한다.
• 클라이언트가 리더 노드에 요청을 보낸다.
• 리더 노드는 메시지를 백업 노드로 전달한다.
• 모든 노드(리더 및 보조)가 클라이언트 요청을 실행한 뒤 클라이언트에게 응답한다.
• 클라이언트가 “m+1” 응답을 수신하면 요청이 성공한 것이다(여기서 m은 허용되는 결함 노드의 최대 수를 나타냄).