홈 BlockChain Core - Sharding on Blockchain 6
포스트
취소

BlockChain Core - Sharding on Blockchain 6

게시 2023-07-20
By
49 분읽는 시간


자료 : SoK: Sharding on Blockchain
지난 포스트 - SoK: Sharding on Blockchain 5


4 CONSENSUS PROTOCOLS 본문


Sharding on blockchain requires consensus protocols to agree on the proposed blocks. However, capturing a rep- resentative and longitudinal view of a topic in blockchain consensus is challenging [13]. Different consensus protocols function differently in the overall sharding procedure. This section presents the state-of-the-art consensus protocols for blockchain sharding in a general way.


4.1 Consensus Classification

In general, protocols can be put in two categories when being used in the blockchain sharding: PoX and BFT. We know Proof-of-Work (PoW) mechanism on Bitcoin [107] and Proof-of-Stake (PoS) on Ethereum [85]. Technically speaking, PoW and PoS are not the decent “consensus protocol", whose mechanisms are used for determining the membership or the stake in a Sybil-attack-resistant fashion. Due to historical reasons, e.g., Bitcoin used PoW as a “consensus" protocol to build a bitcoin blockchain, we literally categorize them into consensus protocols. For example, in a hybrid consensus (e.g., ByzCoin [90] and Hybrid Consensus [110]), the decent consensus protocol (the algorithm for agreement on a shared history) is separable from and orthogonal to the membership Sybil-resistance scheme (e.g., PoW). Here we use Proof-of-X (PoX) to represent all alternatives of proof-of-something (in- cluding PoW and PoS), and use BFT to represent Byzantine- based consensus protocols. In a sharding scheme, both PoX and BFT work together to achieve the consensus process. Roughly speaking, both protocols have different tasks in an overall sharding scheme, which is a dynamic committee based scheme. PoX is typically used for committee formation (e.g., PoW in Elastico [100]) to establish the committee mem- bers and these corresponding identifies, while BFT is used for the intra-committee consensus, which is used within a com- mittee to form the blocks. Thus, it is necessary to introduce both PoX and BFT separately.

4.1.1 PoX. Most PoX-based consensus protocols require that the participating node has some kinds of efforts or re- sources to prove its validity as a miner. We take PoW and PoS as examples to illustrate the PoX mechanisms.
PoW is also called Nakamoto consensus in blockchain after its originator [62], proposed in 1992, for spam Email protec- tion. In PoW, the nodes that generate hashes are called miners and the process is referred to as mining. When applying PoW as a general consensus in blockchain, it is subject to vari- ous kinds of attacks [107], such as forks, double-spending attacks, and 51% attacks. These are the general problems in PoW consensus. However, when implementing PoW into blockchain sharding protocols, due to running PoW locally, special care is required, e.g., selfish mining [65]. Selfish min- ing allows colluding miners to generate more valid blocks than their computing power would normally allow if they were following the standard protocol. These valid blocks are typically generated ahead of time, so that the colluding miners withhold blocks that they have found, and then select a favorite one to maximize these advantages, e.g., controlling one shard. Thus, applying PoW into blockchain sharding requires an agreed epoch randomness for each epoch. Still, most of the state-of-the-art sharding protocols use PoW to establish the membership for a shard.

Compared to PoW, PoS protocols replace wasteful com- putations with useful “work" derived from the alternative commonly accessible resources. For example, participants of PoS vote on new blocks weighted by their in-band invest- ment such as the amount of currency held in the PPCoin blockchain [87]. In general, PoS has a candidate pool which contains all qualified participants called stakeholders (e.g., the amount of stake is larger than a threshold value) [17] [57]. A common approach is to randomly elect a leader from the stakeholders, which then appends a block to the blockchain. However, in blockchain sharding, PoS may be subject to the grinding attacks [45], in which a miner re-creates a block multiple times until it is likely that the miner can create a second block shortly afterward. We should mention that PoS is not just one but instead a collection of protocols. There exist many PoS alternatives, such as Algorand [72], Ouroboros [85], Ouroboros Praos [57], Ethereum [139], etc.

Besides the main PoS protocol, there exist other PoX-based alternatives, which require miners to hold or prove the own- ership of assets. We list three alternatives: proof-of-deposit (PoD) [93], proof-of-burn (PoB) [111] and proof-of-coin-age (PoCA) [86]. Readers are referred to the corresponding papers for their details.

4.1.2 BFT. Most shard-based systems use classic BFT con- sensus protocols, e.g., PBFT, as its intra-shard consensus protocol. In this section, we focus on discussing the poten- tial BFT consensus protocols, or their novel compositions which can be tailored for use as the consensus protocols, in blockchains. Roughly speaking, BFT protocols can be clas- sified into two categories: leader-based BFT and leaderless BFT. Most BFT protocols are leader-based, e.g., PBFT or BFT- SMaRt [18]; and leaderless protocols include SINTRA [32] and HoneyBadger [106].

Actual systems that implement PBFT or its variants are much harder to find than systems which implement Paxos/VSR [131]. BFT-SMaRt [126], launched around 2015, is a widely tested implementation of BFT consensus protocols. Similar to Paxos/VSR, Byzantine consensus, such as PBFT and BFT- SMaRt, expects an eventually synchronous network to make progress. Without this assumption, only randomized pro- tocols for Byzantine consensus are possible, e.g., SINTRA (relying on distributed cryptography) [32] and HoneyBad- ger [106], which can achieve ennventual consensus on an asynchronous network.

Still, many well-known blockchain projects use PBFT and BFT-SMaRt protocols. For example, Hyperledger Fabric [3] and Tendermint Core [26] implement PBFT as these consen- sus protocols; Symbiont [129] and R3 Corda [80] use BFT- SMaRt as their consensus protocols. We briefly discuss these two leader-based BFT consensus protocols, which can be used as intra-shard consensus process.

PBFT. PBFT can tolerate up to 1/3 Byzantine faults. We briefly describe its consensus procedures. One replica, the primary/leader replica, decides the order for clients’ requests, and forwards them to other replicas, the secondary replicas. All replicas together then run a three-phase (pre-prepare/ prepare/commit) agreement protocol to agree on the order of requests. Each replica processes every request and sends a response to the corresponding client. The PBFT protocol has the important guarantee that safety is maintained even during periods of timing violations, progress only depends on the leader. On detecting that the leader replica is faulty through the consensus procedure, the other replicas trigger a view-change protocol to select a new leader. The leader- based protocol works very well in practice and is suitable in blockchain, however, it is subject to scalability issues.

BFT-SMaRt. BFT-SMaRt implements a BFT total-order mul- ticast protocol for the replication layer of coordination ser- vice [18]. It assumes a similar system model as BFT SMR [36] [46]: n ≥ 3f + 1 replicas to tolerate f Byzantine faults, and unbounded number of faulty-prone clients and eventual syn- chrony to ensure liveness. Typically, the BFT-SMaRt consists three key components: Total Order Multicast [123], State Transfer [19], and Reconfiguration [29]. We refer interested readers to [19, 29, 123] for the details.

Besides the above legacy leader-based BFT protocols and the mentioned BFT protocols in Section 2.2, there exist sev- eral variants or newly invented algorithms, e.g., Hotstuff [140], Tendermint [26], and Ouroboros-BFT [84]. Due to the page limit, we refer interested readers to the corresponding refer- ences for the details.

We now briefly discuss the leaderless BFT protocols. This type of BFT protocols mainly target on the asynchronous set- tings, which are based on the randomized atomic broadcast protocols. Unlike existing weakly/partially synchronous pro- tocols, in an asynchronous network, messages are eventually delivered but no other timing assumption is made, as defined in Section 2.1. We take SINTRA [32] and HoneyBadger [106] as examples to describe the leaderless BFT protocols.

SINTRA [32]. SINTRA is a Secure INtrusion-Tolerant Repli- cation Architecture for coordination in asynchronous net- works subject to Byzantine faults. It is a system implemen- tation based on the asynchronous atomic broadcast proto- col [30], which consists of a reduction from atomic broadcast (ABC) to common subset agreement (ACS), as well as a reduc- tion from ACS to multi-value validated agreement (MVBA). Security is achieved through the use of threshold public-key cryptography, in particular through a cryptographic com- mon coin based on the Diffie-Hellman problem that undelies the randomized protocols in SINTRA.

HoneyBadger [106]. HoneyBadgerBFT essentially follows asynchronous secure computing with optimal resilience [16], which uses reliable broadcast (RBC) and asynchronous bi- nary Byzantine agreement (ABA) to achieve ACS. HoneyBad- ger cherry-picks a bandwidth-efficient, erasure-code RBC (AVID broadcast) [33] and the most efficient ABC to realize. Specifically, HoneyBadger uses threshold signature to pro- vide common coins for randomized ABA protocol, which achieves a higher throughput by aggressively batching client transactions.

Besides the above two leaderless BFT protocols, there exist some other peer-reviewed and non-peer-reviewed works, such as BEAT [61], and DBFT [51].

4.2 Committee Configuration

In the sharding protocol, the membership of a shard is dy- namically changed in each epoch to guarantee safety and security. A reconfigurable committee needs some mecha- nisms to track committee membership. This is related to how to configure the committees. Typically, there are four ways to configure a committee within the consensus process: static, rolling (single), full, and rolling (multiple).

Static: In a static setting, the committee members are not periodically changed, which is a typical configuration in permissioned systems. For example, Hyperledger [3] and RSCoin [55] are based on this setting, where committee mem- bers have known and trusted identities and its threat model does not include Sybil attacks.

Rolling (Single): The committee is updated in a sliding window fashion, where new nodes are added to the current committee and the oldest members are ejected. ByzCoin [90] adopts this scheme, in which each node has a voting power proportional to the number of mining blocks it has in the current window.

Full: This scheme is a lottery-based mechanism, such as Algorand [72] and SnowWhite [54], to select the committee members for each epoch using randomness generated based on previous blocks.

Rolling (Multiple): The committee swaps out multiple mem- bers each time. For example, Omniledger [91] uses cryp- tographic sortition to select a subset of committees to be swapped out and replaced with new members. This is done in a way that the ratio between honest and Byzantine mem- bers in a committee is maintained.

We should mention that many blockchain mechanisms for committee configuration are not orthogonal and potentially complementary, instead of mutually exclusive. For example, a large HyperLedger-like permissioned system could serve as a big “directory" from which an OmniLedger-like random committee selection could take place. Similarly, a ByzCoin- like rolling committee selection mechanism based on PoX (e.g., PoW or PoS) could be used to drive the selection of mul- tiple independent committees for OmniLedger-like sharded consensus, not just a signle committee as in ByzCoin.

In a sharding-based protocol, to maintain the committee’s safety and security, it typically adopts either full or rolling (multiple) committee configuration schemes. To configure or reconfigure the committees, a good epoch randomness is required.

4 CONSENSUS PROTOCOLS

샤딩은 블록체인의 확장성을 향상시키기 위한 기술로, 전체 네트워크를 작은 그룹인 샤드로 분할하여 처리량을 증가시킨다. 이 때, 샤드는 각각 독립적인 상태와 합의 메커니즘을 가질 수 있다. 샤딩에서는 PoW, PoS와 같은 다양한 합의 알고리즘을 사용할 수 있다.

이번 챕터에서는 샤딩에서 쓰이는 다양한 합의 메커니즘을 소개한다.

4.1 Consensus Classification

블록체인 샤딩에서 사용되는 프로토콜은 두 가지 유형으로 나눌 수 있다.

  • Proof-of-X(무언가)
    • PoX는 일반적으로 위원회 형성에 사용되며 (예: Elastico에서의 PoW), 위원회 구성원과 그에 해당하는 신원을 설정하는 데 사용된다.
  • BFT
    • BFT는 위원회 내 합의에 사용되며, 위원회 내에서 블록을 형성하는 데 사용된다.


PoX(Proof-of-X)

대부분의 PoX 기반 합의 프로토콜은 참여하는 노드가 마이너로서의 유효성을 증명하기 위해 어떤 형태의 노력이나 자원을 가져야 한다는 요구사항에 따른 합의 프로토콜이다.

1) PoW(Proof-of-Work)

샤딩에서 PoW (Proof of Work) 합의 프로토콜을 사용하는 경우, 다음과 같은 이점과 보완해야 할 점이 있을 수 있다.

이점:

  • 보안성: PoW는 컴퓨팅 작업을 수행하여 블록을 생성하므로, 블록체인 네트워크를 공격하기 위해서는 컴퓨팅 자원의 다수를 통제해야 한다. 이는 분산된 네트워크에서 공격을 어렵게 만든다.
  • 분산성: PoW는 다수의 참여자들이 동시에 작업을 수행하여 블록을 생성할 수 있도록 한다. 이로 인해 네트워크의 분산성이 확보되며, 중앙 집중화를 피할 수 있다.
  • 이전 블록의 무효화 방지: PoW에서는 이전 블록에 대한 수정이 어렵기 때문에, 한 번 추가된 블록은 거의 무효화되지 않는다. 이는 블록체인의 안정성을 높여준다.

보완해야 할 점:

  • 이기적인 마이닝:
    • 이기적인 마이닝 예.
      • 마이너는 채굴 과정에서 자신의 블록이 다른 블록보다 빠르게 추가될 가능성이 낮을 경우, 더 빠른 속도로 다음 블록을 채굴하기 위해 현재 블록의 채굴을 중단하고 다음 블록에 집중한다.
      • 또한, 자신이 채굴한 블록을 다른 마이너들보다 늦게 공개하여 더 긴 체인이 형성되기를 기다린다.
    • 해결책
      • 각 에포크마다 합의된 무작위성이 필요.
  • 에너지 소모: PoW는 컴퓨팅 작업을 수행하기 위해 많은 양의 전기 에너지를 소모한다. 이로 인해 블록체인 네트워크가 환경에 부정적인 영향을 미칠 수 있고, 에너지 비용이 높아질 수 있다.
  • 낮은 처리량: PoW에서는 작업 증명을 위해 시간과 자원이 소모되므로, 블록 생성 속도가 상대적으로 느릴 수 있습니다. 이는 네트워크 내에서 트랜잭션 처리량을 제한할 수 있습니다.
  • 중앙화 위험: PoW에서는 높은 컴퓨팅 자원을 가진 참여자들이 블록을 더 쉽게 생성할 수 있습니다. 이로 인해 일부 개인이 많은 컴퓨팅 파워를 통제하게 되어 중앙 집중화의 위험성이 존재할 수 있습니다.
  • 마이닝 난이도 조절: PoW에서는 마이닝 난이도를 조절해야 합니다. 난이도가 너무 낮으면 네트워크의 보안성이 약해질 수 있고, 너무 높으면 블록 생성 속도가 느려질 수 있습니다. 따라서 적절한 난이도 조절이 필요합니다.


2) PoS(Proof-of-Stake)

샤딩에서 PoS 프로토콜을 사용했을 시의 이점과 보완해야 할 점

이점:

  • 에너지 효율성: PoS 프로토콜은 PoW와 달리 작업 증명에 필요한 계산량과 전력 소비를 크게 줄일 수 있다.
  • 분산성 강화: PoS에서는 참여자들이 자산을 스테이킹하고 보증금을 예치함으로써 네트워크 보안을 강화한다. 이는 분산된 참가자들의 참여를 장려하고 중앙집중화를 방지하는 데 도움이 된다.
  • 효율적인 블록 생성: PoS에서는 리더를 선출하여 블록 생성을 담당하는데, 이는 빠른 블록 생성과 높은 처리량을 가능하게 한다. 이로 인해 거래 확인 시간이 단축되고 블록체인의 확장성이 향상될 수 있다.

보완해야 할 점:

  • 그라인딩 공격: PoS에서 그라인딩 공격이라는 취약점이 있다. 그라인딩 공격은 마이너가 블록을 재생성하여 리더로 선출될 가능성을 높이는 공격이다. 이는 합의 과정에서의 공정성을 약화시킬 수 있다.
    • 랜덤 변수값이 ‘블록’에서 나온다고 한다.
  • 부자 부의 위험(a.k.a. 부익부빈익빈): PoS에서는 자산을 기반으로 리더를 선출하기 때문에 자산을 많이 보유한 참가자들이 합의 과정에서 더 큰 영향력을 가질 수 있다. 이는 부자 부의와 같은 문제를 야기할 수 있다.

이러한 이점과 보완해야 할 점을 고려하여 PoS 프로토콜을 사용할 때에는 보안과 분산성 강화를 위해 추가적인 조치가 필요하며, 그라인딩 공격과 부자 부의와 같은 문제에 대한 대응책을 마련해야 한다.


3) PoD(Proof-of-Deposit)

PoD(Proof-of-Deposit)는 네트워크 참여자가 특정 금액의 예치물을 보증금으로 내어 블록 생성 권한을 얻을 수 있는 합의 프로토콜이다.

PoD 작동방식

  • 네트워크 참여자는 일정량의 암호화폐를 예치하고, 이를 블록체인 네트워크에 보증금으로 제출
    • 예치한 보증금은 네트워크 보안을 유지하고 거부할 수 없는 작업을 수행하는 동안 안전하게 보관된다.
  • 블록 생성 권한은 보증금을 가진 참여자들에게 주어지며, 참여자들은 일정한 주기로 블록을 생성하는 역할을 수행
    • 참여자는 보증금을 잃지 않기 위해 정당한 블록을 생성하고 네트워크 규칙을 준수해야 한다. 만약 참여자가 부정행위를 저지르거나 네트워크 규칙을 위반한다면, 보증금을 일부 혹은 전부 잃게 될 수 있다.

PoD는 보증금을 통해 네트워크 보안을 강화하고 부정행위에 대한 경제적 동기를 제공하는 방식으로 작동한다. 이를 통해 신뢰성 있는 블록 생성을 유도하고 네트워크의 분산성과 보안성을 강화할 수 있다.

블록체인 샤딩에서 “Proof-of-Deposit” (PoD) 프로토콜을 사용하는 경우, 다음과 같은 이점과 보완해야 할 점이 있을 수 있다.

이점:

  • 분산성 강화: PoD 프로토콜은 네트워크 참여자가 일정량의 보증금을 예치해야 함을 요구한다. 이는 블록 생성 권한을 얻기 위한 경제적 장벽을 만들어, 참여자들이 공정하고 분산된 방식으로 네트워크에 참여하도록 유도할 수 있다.
  • 보안 강화: PoD는 보증금을 통해 네트워크 보안을 강화한다. 보증금은 참여자가 부정행위를 저지를 경우 일부 혹은 전부를 잃게 될 위험을 의미한다. 이러한 경제적인 동기는 참여자들에게 정당한 블록 생성과 네트워크 규칙 준수를 유도하며, 네트워크의 신뢰성과 안전성을 증가시킬 수 있다.
  • 스케일링 용이성: PoD는 블록체인 샤딩에서 스케일링을 용이하게 할 수 있는 잠재력을 가지고 있다. 샤딩은 네트워크의 작업 부하를 분산시키는 방법으로, PoD 프로토콜과 함께 사용될 경우 각 샤드는 독립적인 보증금과 블록 생성 권한을 가질 수 있다. 이를 통해 네트워크의 처리량을 증가시키고 확장성을 향상시킬 수 있다.

보완해야 할 점:

  • 보증금 요구: PoD 프로토콜은 참여자들이 일정량의 보증금을 예치해야 한다는 요구사항이 있다. 이는 참여자들에게 추가적인 경제적 부담을 요구할 수 있으며, 일부 사용자들이 참여를 주저하게 할 수 있다.
  • 중심화 위험: PoD에서 보증금을 예치한 참여자들이 블록 생성 권한을 획득하는 경우, 이들이 블록 생성의 주도권을 가지게 된다. 이로 인해 일부 참여자들이 지나치게 많은 권력을 획득하거나 중앙 집중화되는 위험이 있을 수 있다. 이러한 위험은 분산성과 탈중앙화의 원칙에 위배될 수 있다.
  • 그라인딩 공격: PoD에서는 그라인딩 공격(grinding attack)이 발생할 수 있다. 그라인딩 공격은 참여자가 여러 번의 재시도를 통해 블록을 임의로 조작하여 블록 생성 권한을 높이는 공격이다. 이는 프로토콜의 합의 과정을 손상시키고 블록체인의 신뢰성을 약화시킬 수 있다.

PoD는 합의 프로토콜로서 여러 장점을 가지지만, 위와 같은 단점과 보안적인 고려사항을 고려해야 합니다. 특히 그라인딩 공격과 중앙화 위험에 대한 대비책을 마련하여 PoD 프로토콜을 구현하고 사용해야 한다.


4) PoB(Proof-of-Burn)

PoB(Proof-of-Burn)는 참여자가 암호화폐를 소각(Burn)함으로써 블록 생성 권한을 얻는 방식으로 작동한다.

PoB 작동방식

  • 참여자가 일정량의 암호화폐를 소모하여 특정 주소로 송금하는 과정을 거친다.
    • 이런 소모 행위는 실제로 암호화폐를 소멸시키는 것을 의미하며, 이를 통해 참여자들은 자신들의 경제적 가치를 입증해야 한다.
  • 블록 생성 권한은 소모된 암호화폐의 양에 비례하여 부여.
    • 즉, 암호화폐를 더 많이 소모한 참여자일수록 블록 생성 권한을 더 많이 획득.

블록체인의 샤딩에서 “Proof-of-Burn” 합의 프로토콜을 사용하는 경우, 다음과 같은 이점과 보완해야 할 점이 있을 수 있다.

이점:

  • 분산성 강화: Proof-of-Burn은 경제적 투자에 의존하므로, 암호화폐를 소모한 참여자들이 신뢰할 수 있는 블록 생성자로 선발된다. 이는 블록체인의 분산성을 강화하고 중앙 집중화를 방지하는 데 도움을 줄 수 있다.
  • 비용 효율성: Proof-of-Burn은 암호화폐를 실제로 소멸시키는 방식으로 작동한다. 이는 참여자들이 실제로 돈을 지불하는 대신 암호화폐를 소모함으로써 블록 생성 권한을 얻을 수 있게 한다. 이렇게하여 블록체인 네트워크의 운영 비용을 줄일 수 있는 장점을 가질 수 있다.

보완해야 할 점:

  • 자원 낭비: Proof-of-Burn은 암호화폐를 소모하여 작동하기 때문에 일부 사람들은 이를 자원의 낭비로 간주할 수 있다. 암호화폐를 실제로 소멸시키는 것은 그 자체로 낭비로 여겨질 수 있기 때문이다.
  • 초기 분배의 어려움: Proof-of-Burn은 초기 암호화폐 분배를 위해 사용될 수 있다. 그러나 이는 이미 존재하는 암호화폐를 소모하는 것을 요구하기 때문에 초기 참여자들이 어려움을 겪을 수 있다.
  • 보안 취약성: 일부 암호화폐에서는 Proof-of-Burn을 사용할 때 보안적인 취약성이 있을 수 있다. 특히 그라인딩 공격과 같은 공격 벡터에 취약할 수 있으며, 이는 블록 생성자가 블록을 재생성하고 여러 번 추가하는 것을 가능하게 한다.


5) PoCA(Proof-of-Coin-Age)

PoCA(Proof-of-Coin-Age)는 코인의 나이를 증거로 사용하여 블록 생성 권한을 부여하는 합의 프로토콜이다.

PoCA(Proof-of-Coin-Age) 작동방식

  • 코인 연령 계산: 각 참여자가 보유한 코인의 연령을 계산. 코인의 연령은 코인이 생성된 후 경과한 시간으로 측정.
  • 투표권 계산: 코인 연령을 기반으로 각 참여자에게 투표권을 할당. 일반적으로 코인의 연령이 높을수록 더 많은 투표권이 부여. 이는 오랫동안 코인을 보유한 참여자에게 더 큰 영향력을 부여하는 것을 의미.
  • 투표 및 블록 생성: 각 참여자는 부여된 투표권을 사용하여 블록에 대한 투표를 진행. 투표는 합의 과정에서 참여자들이 블록의 유효성을 확인하고 새로운 블록을 생성하는 데 사용.
  • 투표권 소모: 투표권을 사용하면 해당 투표권의 코인 연령은 0으로 초기화. 이는 코인이 사용되거나 전송되면 코인의 연령이 다시 쌓이기 시작해야 한다는 것을 의미.

블록체인의 샤딩에서 “PoCA(Proof-of-Coin-Age)” 합의 프로토콜을 사용하는 경우, 다음과 같은 이점과 보완해야 할 점이 있을 수 있다.

이점:

  • 경제적 보상: PoCA는 코인의 연령을 고려하여 합의 과정에 참여하는 참여자에게 경제적 보상을 제공한다. 오랫동안 코인을 보유한 참여자에게 더 많은 투표권이 주어지므로, 보상을 통해 참여와 보유를 장려할 수 있다.
  • 분산성: PoCA는 코인 보유자의 경제적 투자를 고려하여 투표권을 할당한다. 이로 인해 보다 분산된 합의 과정이 이루어지며, 네트워크에 중앙 집중화 현상이 줄어들 수 있다.
  • 예방된 부자 부의: PoCA는 코인의 연령을 고려하여 투표권을 부여하기 때문에, 샤딩 네트워크에서 부자 부의 문제를 예방할 수 있다. 오랫동안 코인을 보유한 참여자에게만 투표권이 주어지므로, 코인을 많이 보유한 사람들이 지배력을 행사하는 것을 방지할 수 있다.

보완해야 할 점:

  • 코인 노화 문제: PoCA에서는 코인의 연령이 중요한 역할을 한다. 코인의 연령이 쌓이지 않으면 투표권이 제한되거나 보상이 감소할 수 있다. 이는 오랫동안 코인을 보유하지 않은 참여자들에게는 불리한 요소가 될 수 있다.
  • 보안 공격 위험: PoCA는 코인의 연령을 기반으로 합의를 진행하므로, 코인의 연령을 조작하는 공격에 취약할 수 있다. 예를 들어, 공격자가 오랫동안 코인을 보유한 것처럼 가장할 수 있어서 보다 많은 투표권을 얻을 수 있다.
  • 확장성 문제: PoCA는 투표권을 코인의 연령에 기반하여 할당하므로, 참여자들의 코인 보유량에 따라 리소스의 부담이 발생할 수 있다.


BFT

대부분의 샤드 기반 시스템은 PBFT와 같은 전통적인 BFT(비잔틴 장애 허용) 합의 프로토콜을 사용하여 샤드 내 합의 프로토콜로 사용한다. 이 섹션에서는 블록체인에서 합의 프로토콜로 사용될 수 있는 BFT 합의 프로토콜 또는 그들의 새로운 구성에 대해 알려준다.

BFT 프로토콜은 리더 기반 BFT와 리더리스 BFT 두 가지 범주로 분류된다.

1. 리더 기반 BFT

리더 기반 BFT는 리더라고 불리는 특정 참여자가 합의 프로세스를 주도하는 비잔틴 합의 알고리즘이다. 합의를 달성하기 위해 리더가 참여자들에게 명령을 내리고, 참여자들은 이 명령에 대해 합의를 이루는 방식으로 동작한다.

텐더민트가 리더 기반 BFT!

대표적인 프로토콜 ‘PBFT’와 ‘BFT-SMaRt’를 샤딩에 사용했을때, 이점과 보완해야 할 점.

  • PBFT
    • 이점:
      • 높은 성능: PBFT는 빠른 합의를 가능하게 한다. 참여자들 간의 메시지 교환을 효율적으로 수행하여 높은 처리량과 낮은 지연 시간을 제공한다.
      • 안정성과 신뢰성: PBFT는 비잔틴 오류에 대해 내성이 있으며, 악의적인 참여자에 의한 공격에도 시스템의 안정성과 신뢰성을 유지할 수 있다.
      • 최종 일관성: PBFT는 모든 참여자들이 동일한 순서의 블록체인을 유지하여 최종 일관성을 제공한다.
      • 비잔틴 실패 내성: PBFT는 참여자들 중 일부가 오류를 발생시키거나 악의적인 행위를 할 경우에도 시스템이 계속해서 동작하고 합의를 이룰 수 있도록 한다.
    • 보완해야 할 점:
      • 네트워크 대역폭: PBFT는 참여자들 간의 많은 메시지 교환을 요구한다. 이는 네트워크 대역폭을 많이 소모할 수 있으며, 대규모 네트워크에서는 문제가 될 수 있다.
      • 참여자 수 제한: PBFT는 참여자들 간의 통신과 합의에 기반하므로, 참여자의 수가 제한될 수 있다. 참여자 수가 많아지면 합의 과정이 복잡해지고 성능이 저하될 수 있다.
      • 중앙화된 리더: PBFT에서는 리더가 참여자들을 주도하고 합의를 이끌게 된다. 이로 인해 단일 리더에 대한 의존성이 생기고, 리더의 오류나 악의적인 행위가 전체 시스템에 영향을 줄 수 있다.
      • 초기 설정 비용: PBFT를 구현하려면 초기에 참여자들 간에 상호 신뢰 관계를 설정해야 한다. 이를 위해서는 공개키 인프라(PKI)나 신뢰할 수 있는 인증 기관(TA)과 같은 보안 인프라가 필요할 수 있다.

  • BFT-SMaRt(State Machine Replication)

    비잔틴 오류 내성 상태 기계 복제를 위한 프레임워크.

    • 이점:
      • 안전한 분산 합의: BFT-SMaRt는 Byzantine Fault Tolerance (BFT)를 제공하여 악의적인 참여자 또는 잘못된 동작을 하는 참여자에 대해 내성을 가지고 있다. 이로써 샤딩된 블록체인에서 안전한 분산 합의를 달성할 수 있다.
      • 신뢰성과 일관성: BFT-SMaRt는 높은 신뢰성을 제공하며, 모든 참여자들이 동일한 합의 결과를 도출한다. 이는 샤딩된 블록체인에서 데이터의 일관성을 유지하고 모든 참여자 간의 동기화를 보장하는 데 도움이 된다.
      • 유연성과 확장성: BFT-SMaRt는 다양한 응용 분야에서 사용될 수 있으며, 샤딩된 블록체인에서도 활용될 수 있다. 이는 시스템의 유연성과 확장성을 향상시키는 데 도움이 된다.
    • 단점:
      • 대역폭 사용량: BFT-SMaRt은 합의를 위해 참여자들 간에 메시지 교환을 진행하므로 네트워크 대역폭을 많이 사용한다. 따라서 대규모 샤딩된 블록체인에서는 대역폭 제약이 있을 수 있다.
      • 초기 설정 비용: BFT-SMaRt을 사용하기 위해서는 초기 설정이 필요하다. 각 참여자의 인증 및 신뢰 설정 등에 비용이 소요될 수 있다.


2. 리더리스 BFT

리더리스 BFT는 리더가 없는 상황에서 참여자들 간에 합의를 형성하고 블록을 생성하는 방식을 채택한다. 따라서 모든 참여자들이 동등한 권한과 역할을 갖는 특징이 있다.

대표적인 프로토콜 ‘SINTRA’와 ‘HoneyBadger’를 샤딩에 사용했을때, 이점과 보완해야 할 점.

  • SINTRA

    SINTRA는 분산 암호학을 기반으로하여 비동기 네트워크에서 안전하게 합의를 달성하는 메커니즘을 제공한다.

    • 이점:

      • 보안성: SINTRA는 분산 암호학을 기반으로 하여 보안을 강화한다. Threshold public-key 암호화를 사용하여 임의의 공개 키 암호화에 기반한 암호화된 공통 동전을 구현함으로써 보안성을 보장한다.

        Threshold public-key 암호화: 여러 개의 비밀 키 또는 개인 키를 사용하여 암호화 및 복호화를 수행하는 방법

      • 비동기 네트워크 지원: SINTRA는 비동기 네트워크에서 동작할 수 있도록 설계되었다. 따라서, 네트워크의 지연, 분할, 연결 손실 등과 같은 비동기성 문제에 대처할 수 있다.
      • Byzantine 장애 허용: SINTRA는 비잔틴 장애에 대해서도 내성을 갖추어 안정적인 합의를 달성할 수 있다.
    • 보완해야 할 점:
      • 성능: SINTRA는 암호학적 기법과 복잡한 합의 메커니즘을 사용하기 때문에 일부 성능 저하가 발생할 수 있다. 특히, 암호화 연산 및 안전성 검증이 추가적인 계산 비용을 요구할 수 있다.
      • 구현 복잡성: SINTRA는 구현하기가 상대적으로 복잡할 수 있다. 분산 암호학 기법과 복잡한 합의 알고리즘을 이해하고 구현해야 하기 때문에 개발자에게 일정한 지식과 노력을 요구한다.

  • HoneyBadger

    HoneyBadger는 비잔틴 오류에 대응하는 분산 합의 알고리즘인 HoneyBadgerBFT를 의미한다. HoneyBadgerBFT는 암호학적으로 안전한 브로드캐스트와 이중 교환을 기반으로 합의를 도출하는 프로토콜이다.

    • 이점:
      • 안전한 합의: HoneyBadger는 비잔틴 오류에 대응하는 합의 알고리즘이므로 악의적인 노드 또는 네트워크 문제로부터 보호될 수 있다. 이를 통해 블록체인의 신뢰성과 보안성을 강화할 수 있다.
      • 비동기 네트워크 지원: HoneyBadger는 비동기 네트워크에서 동작할 수 있는 합의 프로토콜이다. 이는 네트워크의 지연이나 불안정성에 영향을 받지 않고 합의를 이룰 수 있음을 의미한다.
      • 높은 처리량: HoneyBadger는 클라이언트 트랜잭션을 적극적으로 배치 처리하여 높은 처리량을 달성할 수 있다. 이는 블록체인 시스템의 성능을 향상시킬 수 있다.
    • 단점:
      • 복잡성: HoneyBadger는 비잔틴 오류에 대응하기 위해 복잡한 암호학적 기술과 프로토콜을 사용한다. 이는 구현과 유지보수의 어려움을 초래할 수 있다.
      • 네트워크 부하: HoneyBadger는 비동기 네트워크에서 작동하기 때문에 추가적인 네트워크 부하가 발생할 수 있다. 이는 전체 네트워크의 성능에 영향을 줄 수 있다.
      • 확장성: HoneyBadger는 일부 확장성 제한이 있을 수 있으며, 대규모 네트워크에서의 사용에 제약이 있을 수 있다.


4.2 Committee Configuration

샤딩 프로토콜에서는 매 에포크마다 샤드의 멤버십이 동적으로 바뀌어 안전하고 보안을 유지한다. 위원회 구성을 추적하기 위해 재구성 가능한 메커니즘이 필요하고, 이는 어떻게 위원회를 구성하는지와 관련이 있다.

“재구성 가능한 매커니즘”은 위원회 구성이나 멤버십 변경과 같은 프로세스를 추적하고 조정하기 위해 사용되는 메커니즘

  • 위원회의 구성원을 추가하거나 제거하고, 새로운 멤버를 선출하고, 적절한 규칙과 알고리즘을 통해 위원회를 유지

보통 콘센서스 프로세스 내에서 위원회를 구성하는 네 가지 방법이 있다.

1) 정적(static)

정적 방식은 에포크마다 멤버십을 변경하지 않고 고정된 위원회를 유지하는 방식. 멤버십은 사전에 정해지고 변하지 않으며, 일반적으로 작은 규모의 네트워크에서 사용된다.

2) 롤링 (단일, rolling (single))

롤링 방식은 매 에포크마다 위원회에 새로운 노드를 추가하고 가장 오래된 멤버를 제외하는 방식이다. 이는 연속적인 업데이트를 통해 위원회를 유지하며, ByzCoin과 같은 프로토콜에서 사용된다. 각 노드의 투표 권한은 현재 창에 있는 채굴 블록의 수에 비례한다.

3) 풀(full)

풀 방식은 Algorand나 SnowWhite와 같은 프로토콜에서 사용되는 추첨 기반 메커니즘을 의미한다. 각 에포크마다 랜덤성을 기반으로 위원회 멤버를 선출하는 방식이다. 이는 이전 블록에 기반한 무작위성을 생성하여 사용된다.

4) 롤링 (다중, rolling (multiple))

롤링 다중 방식은 Omniledger와 같은 프로토콜에서 사용된다. 이 방식은 여러 개의 멤버를 한 번에 교체한다. 암호학적인 분배 방식을 사용하여 교체될 위원회의 하위 집합을 선택하고 새로운 멤버로 교체하게 된다. 이를 통해 위원회 내의 선량한 노드와 악의적인 노드 비율을 유지한다.

다음에 계속…

Blogging, Blockchain
BlockChain Core Consensus Sharding
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.
최근 업데이트
바로가기