Consensus
리더 선출
메타디움은 RAFT 컨센서스 알고리즘에 기반하여 만들어졌습니다. 사용자는 META 토큰을 사용하여 네트워크에 액세스할 수 있으며, 자신의 메타 ID를 생성하고 업데이트하는 등 신원과 관련된 기능을 사용할 수 있습니다. 블록 생성자(노드)가 가진 권한은 메타디움이 인정하고 지정한 권한으로 제한되며, 노드는 동기부여를 통해 블록을 생성하고 네트워크를 보호합니다.
합의 알고리즘
Stake based Proof of Authority (SPoA)
메타디움의 블록생성은 메타디움 코인인 Meta를 특정량 이상 staking을 하고 사전에 허가받은 Authority Member들에 의해서만 가능합니다.
Authority
메타디움의 Authority는 Bitcoin/ Ethereum등의 합의 알고리즘 PoW의 마이너와 같은 역할을 수행하는 consortium을 의미합니다. 메타디움에서 Authority에 포함되거나 삭제되는 과정은 기존 authority member들의 voting에 의해서 결정됩니다. 이후 Staking이 확인되면 기존 authority member중 누구라도 member add proposal을 governance contract에 제안하고 기존 authority member들의 50%이상의 찬성이 있으면 새로운 authority member로 등록되게 됩니다.
Authority는 사용자들이 생성한 거래를 수신하게 되면 거래 내역을 검증하여 검증이 통과된 거래들을 mempool에 임시로 저장합니다. Authority member는 RAFT에 의해 leader로 선출되었을때 이전 블록의 hash 정보를 포함한 블록해더를 생성합니다. 이 과정은 소프트웨어적으로 자동적으로 이루어지며, authority member가 지속적으로 네트워크의 상태를 모니터링할 필요는 없습니다. 하지만 authority member는 블록을 생성하는 컴퓨터가 악의적으로 사용되지 않도록 방화벽 및 account의 private key관리에 책임을 져야합니다.
Leader Selection
Bitcoin의 PoW를 예로 들자면, 프로토콜에 의해 계산된 difficulty를 만족하는 block header hash를 생성한 마이너가 블록생성과 블록전파를 할 수 있도록 되어있습니다. 블록생성의 권한이라는 것이 따로 존재하지 않기 때문에 상호 경쟁에 의해 블록을 생성하게 됩니다. 이러한 이유로 블록생성 경쟁을 위해 resource가 낭비될수밖에 없으며 difficulty 조건을 만족하는 work를 증명해야만 하므로 블록생성 시간에 물리적인 제약(평균 비트코인 10분/ 이더리움 15초)을 주게됩니다. 결과적으로 PoW는 scalability trilemma를 가지고 있으며 이를 해결하기 위한 현실적인 방안으로 PoS의 도입이라든지 Sharding등이 제안되어 연구되고 있습니다.
메타디움은 ID 서비스는 global하게 제공하는 목적을 가지고 시작되었기 때문에 PoW나 PoS같은 방식을 사용해서는 원하는 서비스를 퍼블릭 도메인에서 제공하는 것이 불가능하다고 판단하였습니다. 초기에는 DPoS, PoA, PBFT등의 합의 방식이 고려되었으나, 메타디움은 가장 적합한 합의 알고리즘으로 DPoS와 PoA의 장점을 차용한 새로운 Consortium 합의 알고리즘인 SPoA(Stake based PoA)를 고안하였습니다. SPoA는 기본적으로 투명한 신원 정보 및 법률 계약을 통하여 Authority를 구성하고 참여한 authority member들의 부적절한 행동을 막기위해 staking 개념을 도입하고 있습니다.
메타디움은 블록을 생성하는 leader를 선정하기 위하여 leader selection algorithm으로 RAFT의 구현체인 etcd를 사용하고 있습니다.
Reward Distribution
기존 합의 알고리즘들은 블록을 생성한 주체가 블록보상(block reward)과 취합한 fee를 모두 가져가는 구조를 가지고 있습니다. 이러한 이유로 DPoS와 PoA같이 경쟁을 기반으로 하지 않는 시스템에서는 블록생성의 권한을 공평하게 나누는것이 해결해야하는 가장 중요한 문제입니다. 하지만 이러한 제약은 고속으로 거래를 처리하여 블록을 생성해야하는 BP(Block Producer)들간 주고 받아야하는 메시지를 증가시키고 traffic이 queue에 쌓여있는 상황에서 블록생성의 기회를 균일하게 나누기 위하여 자주 leader를 변경하게되면 최상의 성능을 뽑아내지 못하는 문제를 발생시킵니다. 이러한 단점을 보완하기 위해서 SPoA는 authority member중 누가 블록을 생성하더라도 항상 동일하게 member들에게 reward가 주어질수있도록 설계되었습니다. 즉, 현재 버젼에서는 staking의 양과 상관없이 블록이 생성될때마다 블록보상과 collect된 fee를 공평하게 1/n(n은 authority member수)로 분배하도록 되어있습니다.
reward를 받게되는 account(member당 1개)는 governance contract에 최초 system contract들을 배포한 governance coinbase account를 제외하고 모두 voting에 의해 등록되어 있으며 블록을 생성하는 authority member는 해당 account들의 balance state를 update하여 patricia trie의 root hash값에 계산 결과를 반영시킵니다.
authority member를 포함하여 모든 full node는 전송받은 블록의 header를 검증하여 governance contract에 기록되어있는 rule이 정확하게 반영되지 않는 것이 감지되면 해당 블록을 폐기하고 member중 한명이 voting을 통해서 해당 member를 제거하고 staking된 Meta를 몰수하는 작업을 수행할 수 있게 됩니다.
Block Generation
자기 주권 신원 인증에 맞춰 DID 생성 시 즉시성을 갖추기 위하여, 트랜잭션이 발생하는 경우 100ms 이내에 블록을 생성하고 트랜잭션이 없는 경우 5초 간격의 블록 생성 로직을 유지해왔습니다. 하지만, 이는 메타디움 초기 의도와는 달리 DID로 발생하는 트랜잭션 뿐만 아니라 다른 트랜잭션들에 대해서도 많은 리소스가 사용되었으며, 이는 메타디움 블록체인이 무분별하게 Garbage 데이터를 축적되는 상황을 야기하였습니다.
메타디움 블록체인은 블록 생성 주기를 2초로 고정함으로써, 더 많은 컴퓨팅 파워를 보유한 악의적인 공격자가 블록을 수정하는 것을 어렵게 만들도록 네트워크 보안을 강화하고, 블록 생성 시간을 늘림으로써 네트워크에 가해지는 부하 또한 조절합니다. 또한 블록 생성 시간 조정으로 인하여, 네트워크의 안정성과 합의 프로세스의 신뢰성을 가지도록 합니다.
Block Verification
Leader에 의해 생성된 블록이 p2p를 통하여 네트워크에 전파되면 이를 수신한 각각의 full node(authority member포함)는 블록의 유효성을 스스로 검증하고 판단하여야 합니다. Leader가 아닌 authority node들은 governance에 기록된 member중 leader로 선정된 member가 생성한 블록인지를 확인하고 reward가 정상적으로 분배되어 있으며 거래 내역이 전체 시스템의 상태(state)에 반영되었다고 스스로 검증하여 판단되면 해당 블록을 이웃 노드들에게 전파하게 됩니다.
이를 전파받은 non-authority full node는 header에 포함된 member의 signature가 올바른지를 확인하고 거래내역을 검증한 후 블록에 기록된 거래가 rule에 따라 생성되었다고 판단되면 블록을 local disk에 저장하고 이웃노드에게 전파합니다.
전파되는 블록을 검증할때 위의 과정을 진행하기 전에 모든 full node가 먼저 검증해야하는 것이 두 가지 있는데 이는 Leader_Limit과 Max_Consecutive_Blocks입니다.
Leader_Limit은 아래와 같이 정의되는데 RAFT에서 특정 member가 leader로 결정되면 블록을 생성 할수있는 epoch가 주어지는데, 이 epoch가 연속으로 주어질 수 없도록 하는 것을 목적으로 합니다. 즉, 모든 블록은 아래의 Leader_Limt을 만족하는 경우에만 유효합니다.
Leader_Limit = floor(SIGNER_COUNT / 2) + 1 (Number of consecutive epochs out of which a leader may only occupy one)
Max_Consecutive_Blocks는 한 epoch에서 동일 leader가 최대 연속으로 생성할수있는 블록의 개수입니다. 이값은 member node의 hacking으로 네트워크가 분기될때 분기된 블록이 자라날수있는 height를 제한하기 위하여 도입된 변수이다. 두 가지 값은 governance contract에 의해 관리되며 voting에 의해 변경 가능합니다.
위의 두가지 값은 block finality를 보장하기 위한 방법이며 악의적으로 행동하는 authority member가 네트워크에 줄수있는 피해를 최소화하기 위하여 고안되었습니다.
Staking
Authority member가 되기 위해서는 META staking이 선결조건 중 하나입니다. Staking방법은 시스템 레벨에서 알려져있는 goverance contract에 pre-define된 함수를 호출하면서 META를 전송하면 가능합니다. META는 Governance Dapp을 통해서만 Staking 할 수 있으며, Staking 가능한 Minimum / Maximum 양은 Voting에 의해 변경 가능합니다. Voting Power는 Lock된 META Staking양에 따라 결정이 되며, Staking된 META의 Lock / Unlock 여부는 Voting의 결과에 따라 결정됩니다.
Voting (On-Chain Governance)
메타디움 governance contract는 기본적으로 voting에 의해 변경 가능한 시스템 변수들을 저장하고 있으며, Authority member의 참여, 탈퇴, 교체와 관련된 기능을 수행하는 함수들을 가지고 있습니다. 각각의 Authority는 Staking한 양에 비례하여 Voting Power를 가지게 되며, 각 Voting은 Voting Duration(1일~7일)동안 Staking된 Meta 전체 총량의 50% 이상의 찬성표를 획득하게 될 시 통과됩니다.
메타디움 Governance dApp: https://governance.metadium.com/
Authority member만이 voting을 신청을 할 수 있습니다. 신청시 voting duration을 최소/최대값 범위 안에서 정할 수 있고 미지정시 최소값으로 지정됩니다. voting의 시작과 끝은 신청 목록에서 member가 처음 투표할때 부터 시작 되어 최대 voting duration 동안 진행 됩니다. voting duration 이내라 하더라도 50%초과의 찬반 의견이 나올 경우, voting은 종료 되고, 후속 작업이 진행이 됩니다. 기본적으로 한번에 하나의 voting만 진행되므로, 기존에 진행 중인 voting이 있을 경우 새로운 voting을 시작할 수 없습니다.
Last updated