위키원
"기여도증명"의 두 판 사이의 차이
잔글 |
잔글 |
||
| (사용자 2명의 중간 판 4개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| + | [[파일:네뷸러스 글자.png|썸네일|300픽셀|'''[[네뷸러스]]'''(Nebulas)]] | ||
| + | |||
'''기여도증명'''(PoD, Proof of Devotion)은 건강한 생태계를 구축하기 위해 [[네뷸러스]](Nebulas)만의 새로운 합의 알고리즘으로 신속성, 비가역성, 공정성이라는 세 가지 주요 포인트를 제안한다. <ref name="백서">Nebulas 재단, 〈[https://www.nebulas.io/docs/NebulasTechnicalWhitepaperKr.pdf Nebulas 기술백서, 가치 기반 블록체인 운영 및 검색엔진]〉, ''nebulas'', 2018-04</ref> | '''기여도증명'''(PoD, Proof of Devotion)은 건강한 생태계를 구축하기 위해 [[네뷸러스]](Nebulas)만의 새로운 합의 알고리즘으로 신속성, 비가역성, 공정성이라는 세 가지 주요 포인트를 제안한다. <ref name="백서">Nebulas 재단, 〈[https://www.nebulas.io/docs/NebulasTechnicalWhitepaperKr.pdf Nebulas 기술백서, 가치 기반 블록체인 운영 및 검색엔진]〉, ''nebulas'', 2018-04</ref> | ||
| 16번째 줄: | 18번째 줄: | ||
=== 검증자 무리 교체 매커니즘 === | === 검증자 무리 교체 매커니즘 === | ||
검증자 무리는 한 Dynasty(시대)의 방식으로 교체되므로 무리별로 다른 Dynasty로 나뉘며, 한 시대 내의 검증자 무리는 교체되지 않는다. 한 Dynasty 안에서 급격한 교체는 있을 수 없으며 일정 기간 내에 교체되지 않아야 한다. 따라서 Nebulas는 모든 X 블록을 특정 Epoch(세대)로 정하고, 동일한 Epoch에서는 어떤 교체도 일어나지 않는다. 그러므로 Dynasty의 변화는 하나의 Epoch에서 다른 Epoch로 넘어갈 때에만 발생한다. Epoch 교체가 일어날 때 이전 Epoch의 첫 번째 블록은 조사를 받게 된다. 첫 번째 블록이 Finality(최종) 상태에 돌입한다면 현재 Epoch가 다음 D1 Dynasty에 진입하게 된다. 만일 조사가 이루어지지 않는다면 기존의 D0 Dynasty가 그대로 유지된다. | 검증자 무리는 한 Dynasty(시대)의 방식으로 교체되므로 무리별로 다른 Dynasty로 나뉘며, 한 시대 내의 검증자 무리는 교체되지 않는다. 한 Dynasty 안에서 급격한 교체는 있을 수 없으며 일정 기간 내에 교체되지 않아야 한다. 따라서 Nebulas는 모든 X 블록을 특정 Epoch(세대)로 정하고, 동일한 Epoch에서는 어떤 교체도 일어나지 않는다. 그러므로 Dynasty의 변화는 하나의 Epoch에서 다른 Epoch로 넘어갈 때에만 발생한다. Epoch 교체가 일어날 때 이전 Epoch의 첫 번째 블록은 조사를 받게 된다. 첫 번째 블록이 Finality(최종) 상태에 돌입한다면 현재 Epoch가 다음 D1 Dynasty에 진입하게 된다. 만일 조사가 이루어지지 않는다면 기존의 D0 Dynasty가 그대로 유지된다. | ||
| − | + | [[파일:검증자무리교체.png|썸네일|800픽셀|가운데|검증자 무리의 교체(X=100으로 가정)]] | |
Dynasty 변경이 발생할 시, 네트워크 지연으로 인해 각 노드에서 블록 G의 Finality(최종) 상태가 동일하지 않을수 있다. 검증자 무리 교체 매커니즘을 기반으로 각 Dynasty(시대)의 합의 과정은 현재와 이전 Dynasty의 검증자 무리가 함께 결정한다. 따라서 어떤 Dynasty에서도 적절한 계정은 Dynasty D+2의 검증자 무리에 합류하거나 해지 신청만 진행할 수 있으며, Dynasty가 Dynasty D+2로 진화하면 새로운 블록의 합의 과정에 참여할 수 있게 된다.<ref name="백서"></ref> | Dynasty 변경이 발생할 시, 네트워크 지연으로 인해 각 노드에서 블록 G의 Finality(최종) 상태가 동일하지 않을수 있다. 검증자 무리 교체 매커니즘을 기반으로 각 Dynasty(시대)의 합의 과정은 현재와 이전 Dynasty의 검증자 무리가 함께 결정한다. 따라서 어떤 Dynasty에서도 적절한 계정은 Dynasty D+2의 검증자 무리에 합류하거나 해지 신청만 진행할 수 있으며, Dynasty가 Dynasty D+2로 진화하면 새로운 블록의 합의 과정에 참여할 수 있게 된다.<ref name="백서"></ref> | ||
=== 합의 과정 === | === 합의 과정 === | ||
| − | 새로운 블록이 제안된 후 현재 Dynasty의 검증자 무리에 있는 모든 이들은 현재 블록의 정당성을 결정하기 위해 [[비잔틴 | + | 새로운 블록이 제안된 후 현재 Dynasty의 검증자 무리에 있는 모든 이들은 현재 블록의 정당성을 결정하기 위해 [[비잔틴 장애허용]]스타일(BFT, Byzantine-Fault-Tolerant Style) 투표에 참여한다. 투표 시작 시, 해당블록 합의에 참여하는 각 검증자는 보증금으로 2x(x는 인센티브 보너스 비율)가 청구되고 두 단계의 투표 과정이 시작된다. |
* 첫 번째 단계: 모든 검증자는 새 블록에 대하여 Prepare tickets(프리페어 티켓)을 제안해야 한다. Prepare tickets을 제안한 후, 검증자는 1.5배의 보너스를 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새로운 블록에 대한 Prepare tickets을 제안하면 해당 블록은 투표의 두 번째 단계로 들어서게 된다. 주의해야할 점은 기본적으로 새 블록의 제안자가 새 블록에 대한 Prepare tickets을 해당 새 블록에 제안해야 한다는 점이다. | * 첫 번째 단계: 모든 검증자는 새 블록에 대하여 Prepare tickets(프리페어 티켓)을 제안해야 한다. Prepare tickets을 제안한 후, 검증자는 1.5배의 보너스를 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새로운 블록에 대한 Prepare tickets을 제안하면 해당 블록은 투표의 두 번째 단계로 들어서게 된다. 주의해야할 점은 기본적으로 새 블록의 제안자가 새 블록에 대한 Prepare tickets을 해당 새 블록에 제안해야 한다는 점이다. | ||
* 두 번째 단계: 모든 검증자가 새 블록에 대한 Commit tickets(커밋 티켓)을 제안해야 한다. Commit tickets을 제안한 후, 검증자는 1.5배의 보너스를 다시 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새 블록에 대한 Commit tickets을 제안하면 해당 블록이 Finality(최종) 상태에 도달한다. | * 두 번째 단계: 모든 검증자가 새 블록에 대한 Commit tickets(커밋 티켓)을 제안해야 한다. Commit tickets을 제안한 후, 검증자는 1.5배의 보너스를 다시 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새 블록에 대한 Commit tickets을 제안하면 해당 블록이 Finality(최종) 상태에 도달한다. | ||
| 25번째 줄: | 27번째 줄: | ||
=== 포크 선택 === | === 포크 선택 === | ||
PoD 알고리즘은 각 높이에서 블록 스코어에 따라 표준 체인을 선택한다. PoD 알고리즘은 항상 캐노니컬 체인(Canonical Chain)에 합류하기 위해 가장 높은 점수를 가진 블록을 선택하며, 높이 h에서 블록 b의 점수는 다음과 같다: | PoD 알고리즘은 각 높이에서 블록 스코어에 따라 표준 체인을 선택한다. PoD 알고리즘은 항상 캐노니컬 체인(Canonical Chain)에 합류하기 위해 가장 높은 점수를 가진 블록을 선택하며, 높이 h에서 블록 b의 점수는 다음과 같다: | ||
| − | + | [[파일:포크선택.png|썸네일|700픽셀|가운데|높이 h에서 블록 b의 점수는 다음과 같다]] | |
즉, 해당 블록과 그 하위 블록 모두가 수신한 Commit tickets(커밋 티켓)에 상응하는 예금의 합계는 다음과 같다:<ref name="백서"></ref> | 즉, 해당 블록과 그 하위 블록 모두가 수신한 Commit tickets(커밋 티켓)에 상응하는 예금의 합계는 다음과 같다:<ref name="백서"></ref> | ||
| − | + | [[파일:포크선택예제.png|썸네일|800픽셀|가운데|포크 선택 예제]] | |
=== 투표 규칙 === | === 투표 규칙 === | ||
합의 실패 및 생태계 발전에 있어서 문제들을 초래할 수 있는 악의적인 손상을 피하기 위해, PoD는 캐스퍼(Casper)의 최소 삭감(Slashing) 조건을 참조하여 검증자의 합의 활동을 제한한다. | 합의 실패 및 생태계 발전에 있어서 문제들을 초래할 수 있는 악의적인 손상을 피하기 위해, PoD는 캐스퍼(Casper)의 최소 삭감(Slashing) 조건을 참조하여 검증자의 합의 활동을 제한한다. | ||
| 42번째 줄: | 44번째 줄: | ||
검증자가 위 규칙을 위반했다는 사실이 보고되고 위반 사실 여부가 확인이 된다면, 해당 검증자는 처벌을 받게 되고 모든 예금이 압수되며, 압수된 금액의 4%는 내부 신고자에게 보상으로 제공되고 나머지 금액은 처분된다.<ref name="백서"></ref> | 검증자가 위 규칙을 위반했다는 사실이 보고되고 위반 사실 여부가 확인이 된다면, 해당 검증자는 처벌을 받게 되고 모든 예금이 압수되며, 압수된 금액의 4%는 내부 신고자에게 보상으로 제공되고 나머지 금액은 처분된다.<ref name="백서"></ref> | ||
| − | == | + | == 부정적인 영향 == |
| − | 네뷸러스 기여도증명 합의 알고리즘은 블록체인 기술에는 아직 비슷한 개념이 없다. 기여도증명의 본질은 네뷸러스에서 디앱(dApps)을 개발하는 인력과 팀을 장려하는 것이다. | + | [[네뷸러스]]의 기여도증명 합의 알고리즘은 블록체인 기술에는 아직 비슷한 개념이 없다. 기여도증명의 본질은 네뷸러스에서 [[디앱]](dApps)을 개발하는 인력과 팀을 장려하는 것이다. 기여도증명(PoD)은 개발 인력에게 엄청난 수익 잠재력을 부여하지만, 최상위 개발 인력에게 이익이 된다. 예를 들어 [[기프토]](Gifto)가 네뷸러스 네트워크에 곧 디앱을 배포할 것이라고 발표하면 적어도 기프토(Gifto)는 처음부터 다른 디앱 창작자의 유력한 경쟁자가 되는 것이다. |
| − | |||
| − | 개발자들이 경외감을 주는 | + | 개발자들이 경외감을 주는 디앱을 만들어 내도록 자극하고, 동시에 블록체인에서 직접 이익을 얻도록 하기 때문에 디앱 창작자는 더 이상 [[ICO]]를 필요로 하지 않으며 다른 수입원도 필요하지 않는다. 그러나 기여도증명 참여가 개발업자의 다른 수입에서 오는 혜택을 막지 않는다는 점에서는 일거양득이다.<ref>〈[https://www.zhongbi.net/news/blocknews/115750.html 深度解析：星云链（NAS）]〉, 《中币网》, 2018-10-15</ref> |
{{각주}} | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
| − | * 네뷸러스 홈페이지 - https://nebulas.io/ | + | * 네뷸러스 공식 홈페이지 - https://nebulas.io/ |
| − | * | + | * 네뷸러스 기술 한글 백서 – https://www.nebulas.io/docs/NebulasTechnicalWhitepaperKr.pdf |
| − | * | + | * 네뷸러스 기술 중문 백서 - https://nebulas.io/docs/NebulasTechnicalWhitepaperZh.pdf |
| − | * taevely, 〈[https://steemit.com/coinkorea/@taevely/nebulas-nas NEBULAS (NAS) 분석]〉, | + | * taevely, 〈[https://steemit.com/coinkorea/@taevely/nebulas-nas NEBULAS (NAS) 분석]〉, 《스팀잇》, 2018-08-27 |
* 〈[https://www.zhongbi.net/news/blocknews/115750.html 深度解析：星云链（NAS）]〉, 《中币网》, 2018-10-15 | * 〈[https://www.zhongbi.net/news/blocknews/115750.html 深度解析：星云链（NAS）]〉, 《中币网》, 2018-10-15 | ||
| − | == | + | == 같이 보기 == |
* [[네뷸러스]] | * [[네뷸러스]] | ||
* [[작업증명]] | * [[작업증명]] | ||
* [[지분증명]] | * [[지분증명]] | ||
* [[중요도증명]] | * [[중요도증명]] | ||
| − | * [[비잔틴 | + | * [[비잔틴 장애허용]] |
{{합의 알고리즘|검토 필요}} | {{합의 알고리즘|검토 필요}} | ||
2019년 8월 28일 (수) 09:26 기준 최신판
기여도증명(PoD, Proof of Devotion)은 건강한 생태계를 구축하기 위해 네뷸러스(Nebulas)만의 새로운 합의 알고리즘으로 신속성, 비가역성, 공정성이라는 세 가지 주요 포인트를 제안한다. [1]
목차
개요[편집]
계정 기여도를 기반으로 하는 합의 알고리즘인 기여도증명( Proof of Devotion, PoD)은 NR 점수가 높은 상위 N 개의 계정에게 블록을 생성할 기회가 주어지고 일정금액(NAS)을 보증금으로 입금 시 블록생성 검증자가 된다. 노드로 참여하게 되면 각각 해당하는 블록에서 NAS를 1배로 보상 받고 열악한 네트워크 트래픽이나 부정행위가 있을 경우 0.5배를 잃게 된다. 기여도증명을 통해 빠른 처리속도와 부정방지 기능을 만들었고 nf(dapp기능)를 제공해 dapp을 개발할 수 있다.[2]
설계 목표[편집]
합의 알고리즘은 블록체인의 초석이며, 신속성과 비가역성이 Nebulas의 주안점이다. Nebulas 블록체인 상의 보다 나은 생태계를 구축하기 위해 공정성 또한 매우 중요하게 생각한다. 대규모의 자본을 통해 Nebulas의 블록 합의 알고리즘을 쉽게 통제할 수 있다면, 많은 개발자와 사용자의 이익이 손상될 것이다. 또한, 기여자의 이익을 보장할 수 없는 생태계는 보다 고차원적인 가치를 창출하는 것이 어렵다. 따라서 합의 알고리즘은 Nebulas 생태계를 위해 기여하는 모든 이들의 이익을 보장하기 위해 가능한 공정성을 추구하는 기반 위에서 신속성과 비가역성을 보장하도록 설계되어야 한다.[1]
등장배경[편집]
작업증명(PoW, Proof of Work), 지분증명(PoS), 중요도증명(PoI, Proof of Importance) 등 널리 사용되는 합의 알고리즘과 이에 대한 네뷸러스의 목표가 불일치함으로, 포괄적으로 계정의 영향력과 기여도를 평가하는 PoI와 엄격한 경제적 패널티를 포함하는 PoS를 결합한 새로운 기여도 증명(PoD) 알고리즘을 개발하고자 한다. PoS는 PoI의 비가역성을 향상시키고, PoI는 PoS의 독점을 예방할 수 있다.[1]
PoD 합의 알고리즘의 설계[편집]
새로운 블록의 생성[편집]
중요도가 높은 순위에 따라 계정을 선정하는 PoI 합의 알고리즘과 유사하지만, PoD는 생태계에 대한 영향력과 기여도에 따라 계정을 선정한다. 또한 한쪽으로만 치우쳐진 권한을 막기 위해, PoD를 통해 선정된 계정은 북키핑의 권한을 부여받으며 새로운 블록 생성을 위한 참여 기회도 똑같이 주어진다. 영향력과 기여도가 큰 계정을 선정 시 Nebulas Rank를 사용한다. Nebulas Rank의 알고리즘 설계에서 계정의 유동성과 전파성을 강조했다. 이러한 속성을 포함한 계정이 Nebulas의 생태계 구축과 관련하여 높은 영향력과 기여도를 가질 것이라고 할 수 있다. 따라서 PoD를 통해 Nebulas Rank의 상위 계정이 선정되며 이 계정은 자발적으로 일정 금액(NAS)를 보증금으로 입금하면 북키핑에 참여할 시 새로운 블록 생성에 대한 검증자 자격이 부여된다. 여러 검증자가 선정되어 무리가 이루어지면 PoD 알고리즘은 의사 무작위(pseudo-random) 숫자를 사용하여 검증자 무리 중 누가 새로운 블록 생성자인지, 어떤 트랜잭션을 압축하여 새 블록을 생성해야 하는지 결정한다. 검증자는 바뀔 수 있으며 검증자 조건을 충족시키는 계정은 검증자로서의 권한을 요청하거나 또는 권한을 취소요청 할 수 있다. 또한 검증자 조건을 충족시키는 계정은 Nebulas Rank의 정기적인 변경사항에 따라 달라질 수 있다. 따라서 Nebulas는 검증자 무리의 교체를 구현하기 위해 PoD를 기반으로 하는 검증자 무리 교체 매커니즘을 설계했다.[1]
검증자 무리 교체 매커니즘[편집]
검증자 무리는 한 Dynasty(시대)의 방식으로 교체되므로 무리별로 다른 Dynasty로 나뉘며, 한 시대 내의 검증자 무리는 교체되지 않는다. 한 Dynasty 안에서 급격한 교체는 있을 수 없으며 일정 기간 내에 교체되지 않아야 한다. 따라서 Nebulas는 모든 X 블록을 특정 Epoch(세대)로 정하고, 동일한 Epoch에서는 어떤 교체도 일어나지 않는다. 그러므로 Dynasty의 변화는 하나의 Epoch에서 다른 Epoch로 넘어갈 때에만 발생한다. Epoch 교체가 일어날 때 이전 Epoch의 첫 번째 블록은 조사를 받게 된다. 첫 번째 블록이 Finality(최종) 상태에 돌입한다면 현재 Epoch가 다음 D1 Dynasty에 진입하게 된다. 만일 조사가 이루어지지 않는다면 기존의 D0 Dynasty가 그대로 유지된다.
Dynasty 변경이 발생할 시, 네트워크 지연으로 인해 각 노드에서 블록 G의 Finality(최종) 상태가 동일하지 않을수 있다. 검증자 무리 교체 매커니즘을 기반으로 각 Dynasty(시대)의 합의 과정은 현재와 이전 Dynasty의 검증자 무리가 함께 결정한다. 따라서 어떤 Dynasty에서도 적절한 계정은 Dynasty D+2의 검증자 무리에 합류하거나 해지 신청만 진행할 수 있으며, Dynasty가 Dynasty D+2로 진화하면 새로운 블록의 합의 과정에 참여할 수 있게 된다.[1]
합의 과정[편집]
새로운 블록이 제안된 후 현재 Dynasty의 검증자 무리에 있는 모든 이들은 현재 블록의 정당성을 결정하기 위해 비잔틴 장애허용스타일(BFT, Byzantine-Fault-Tolerant Style) 투표에 참여한다. 투표 시작 시, 해당블록 합의에 참여하는 각 검증자는 보증금으로 2x(x는 인센티브 보너스 비율)가 청구되고 두 단계의 투표 과정이 시작된다.
- 첫 번째 단계: 모든 검증자는 새 블록에 대하여 Prepare tickets(프리페어 티켓)을 제안해야 한다. Prepare tickets을 제안한 후, 검증자는 1.5배의 보너스를 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새로운 블록에 대한 Prepare tickets을 제안하면 해당 블록은 투표의 두 번째 단계로 들어서게 된다. 주의해야할 점은 기본적으로 새 블록의 제안자가 새 블록에 대한 Prepare tickets을 해당 새 블록에 제안해야 한다는 점이다.
- 두 번째 단계: 모든 검증자가 새 블록에 대한 Commit tickets(커밋 티켓)을 제안해야 한다. Commit tickets을 제안한 후, 검증자는 1.5배의 보너스를 다시 받게 된다. 현재와 이전 Dynasty의 총 예금 중 2/3 이상을 보유하고 있는 검증자가 새 블록에 대한 Commit tickets을 제안하면 해당 블록이 Finality(최종) 상태에 도달한다.
생태계 전체의 발전을 가속화하기 위해 블록 b Prepare tickets 및 Commit tickets과 블록 b 타임스탬프의 차이가 T를 초과하면 이 tickets은 만료된 것으로 간주되어 바로 무시된다.[1]
포크 선택[편집]
PoD 알고리즘은 각 높이에서 블록 스코어에 따라 표준 체인을 선택한다. PoD 알고리즘은 항상 캐노니컬 체인(Canonical Chain)에 합류하기 위해 가장 높은 점수를 가진 블록을 선택하며, 높이 h에서 블록 b의 점수는 다음과 같다:
즉, 해당 블록과 그 하위 블록 모두가 수신한 Commit tickets(커밋 티켓)에 상응하는 예금의 합계는 다음과 같다:[1]
투표 규칙[편집]
합의 실패 및 생태계 발전에 있어서 문제들을 초래할 수 있는 악의적인 손상을 피하기 위해, PoD는 캐스퍼(Casper)의 최소 삭감(Slashing) 조건을 참조하여 검증자의 합의 활동을 제한한다. 합의 과정에서 Prepare투표와 Commit투표가 다음의 구조로 이루어져 있다고 가정한다:
- Prepare(H, v, vs): H는 현재 블록의 해시 값이고, v는 현재 블록의 높이를 나타내며, vs는 v의 특정 이전 블록의 높이를 나타낸다.
- Commit(H, v): H는 현재 블록의 해시 값이고, v는 현재 블록의 높이를 나타낸다.
PoD 알고리즘은 전체 투표 과정에 대해 다음과 같은 4가지 기본 규칙을 규정한다:
- 단일 블록의 두 단계 합의 과정에는 엄격한 순서가 있다. 첫 단계에서 Prepare(H, v, vs)투표의 총 예금이 2/3에 달했을 경우에만, 검증자가 Commit(H, v)투표를 두 번째 단계로 전달할 수 있다.
- 여러 블록의 경우, 한 블록의 합의 과정이 완료될 때만 다음 블록의 합의 과정이 시작될 수 있다는 필수 규칙은 없다. 특정 순서에 따라 수행될 경우, 결합한 합의(interwoven consensus)가 제공 될 수 있다. 결합한 합의의 안정된 진행을 보장하기 위해 높이 vs에 대한 과정의 첫 번째 단계가 끝나고 Prepare(H, v, vs)투표의 비율이 2/3에 도달한 후에만 에 기반을 둔 Prepare(H, v, vs)가 이후 블록에 전달될 수 있다.
- 결합한 합의를 악용한 모든 노드의 악성 크로스 블록 투표를 피하기 위해, Prepare(H, v, vs)투표를 u의 높이를 기준으로 전달 후, 모든 Commit(H, v)투표는 u에서 w까지의 범위 내의 높이로는 모든 블록에서 전달 될 수 없으므로 합의 과정의 높은 효율성과 질서를 보장한다.
- Nothing at Stake이라는 문제를 일으킬 수 있으므로 노드가 동시에 여러 지점에 하나의 예금으로 이체하는 것
을 방지하기 위해 Prepare(H1, v, vs1) 투표가 특정 높이에 도달한 후, 다른 Prepare(H2, v, vs2)투표를 다시 전달할 수 없다.
검증자가 위 규칙을 위반했다는 사실이 보고되고 위반 사실 여부가 확인이 된다면, 해당 검증자는 처벌을 받게 되고 모든 예금이 압수되며, 압수된 금액의 4%는 내부 신고자에게 보상으로 제공되고 나머지 금액은 처분된다.[1]
부정적인 영향[편집]
네뷸러스의 기여도증명 합의 알고리즘은 블록체인 기술에는 아직 비슷한 개념이 없다. 기여도증명의 본질은 네뷸러스에서 디앱(dApps)을 개발하는 인력과 팀을 장려하는 것이다. 기여도증명(PoD)은 개발 인력에게 엄청난 수익 잠재력을 부여하지만, 최상위 개발 인력에게 이익이 된다. 예를 들어 기프토(Gifto)가 네뷸러스 네트워크에 곧 디앱을 배포할 것이라고 발표하면 적어도 기프토(Gifto)는 처음부터 다른 디앱 창작자의 유력한 경쟁자가 되는 것이다.
개발자들이 경외감을 주는 디앱을 만들어 내도록 자극하고, 동시에 블록체인에서 직접 이익을 얻도록 하기 때문에 디앱 창작자는 더 이상 ICO를 필요로 하지 않으며 다른 수입원도 필요하지 않는다. 그러나 기여도증명 참여가 개발업자의 다른 수입에서 오는 혜택을 막지 않는다는 점에서는 일거양득이다.[3]
각주[편집]
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Nebulas 재단, 〈Nebulas 기술백서, 가치 기반 블록체인 운영 및 검색엔진〉, nebulas, 2018-04
- ↑ taevely, 〈NEBULAS (NAS) 분석〉, Steemit, 2018-08-27
- ↑ 〈深度解析：星云链（NAS）〉, 《中币网》, 2018-10-15
참고자료[편집]
- 네뷸러스 공식 홈페이지 - https://nebulas.io/
- 네뷸러스 기술 한글 백서 – https://www.nebulas.io/docs/NebulasTechnicalWhitepaperKr.pdf
- 네뷸러스 기술 중문 백서 - https://nebulas.io/docs/NebulasTechnicalWhitepaperZh.pdf
- taevely, 〈NEBULAS (NAS) 분석〉, 《스팀잇》, 2018-08-27
- 〈深度解析：星云链（NAS）〉, 《中币网》, 2018-10-15
같이 보기[편집]
