입회 속도

ZooBC는 새 노드를 노드 레지스트리에 한 번에 하나씩, 의도적으로 느리게 움직이는 타이머에 따라 받아들입니다. 운영자의 블록 생산 몫은 좌석의 몫이므로, 좌석을 얻을 수 있는 속도는 곧 누군가가 체인에 대한 권한을 얻을 수 있는 속도입니다. 프로토콜이 그 속도를 정하며, 누구나 이를 지켜볼 수 있습니다.

왜 천천히인가

작업 증명에서는 블록 생산의 몫을 하드웨어를 사는 속도만큼, 지분 증명에서는 코인을 사는 속도만큼 빠르게 살 수 있습니다. ZooBC에서는 그 몫이 입회를 거쳐야 하며, 입회 주기마다 노드 하나씩, 프로토콜이 정한 속도로만 주어집니다. 따라서 예를 들어 결제를 되돌리기 위한 갑작스러운 장악은 단지 비싼 것이 아니라 원리적으로 불가능합니다(참여 증명이 방어하는 위협).

이 느림은 체인의 속도와는 아무 관계가 없습니다. 새 노드는 전체 이력 대신 최근 스냅샷에서 시작할 수 있고, 운영자를 면접하는 사람도 없으며, 체인은 노드가 몇 개든 15초마다 블록 하나를 만듭니다.

공식

두 입회 사이의 지연은 다음과 같습니다.

delay = clamp(base ÷ counted seats, minimum, maximum)

mainnet에서 기준값(base)은 600일, 최소값은 7일, 최대값은 90일입니다. testnet도 같은 값을 씁니다. 첫 신규 노드는 제네시스 7일 뒤에 입회할 수 있습니다. 타이머는 블록 타임스탬프를 읽으며 주기마다 최대 한 노드를 입회시키고, 노드를 대기열에 넣은 바로 그 블록에서는 입회시키지 않습니다. 어느 노드를 입회시킬지는 대기열이 정합니다.

다음 입회까지의 지연은 신규 노드가 입회할 때, 그 신규 노드 이전의 좌석 수를 세어 정해집니다.

어떤 좌석이 집계되는가

• 제네시스 좌석은 최대 11개로 집계됩니다(제네시스 값이며, 모든 체인에서 11).
• 신규 노드는 모두 집계됩니다.
• 정지된 좌석은 어느 쪽에서도 집계되지 않습니다.

이 상한은 큰 제네시스가 레지스트리를 빠르게 여는 것을 막습니다. 상한이 없다면 제네시스 좌석 100개로 출시된 체인은 600 ÷ 100 = 6일을 계산하고, 이를 최소값 7일로 올려 처음부터 매주 신규 노드를 받아들일 것입니다. 상한이 있으면 집계는 11에서 시작하며, 일정은 좌석 11개 체인과 같습니다. 정지된 좌석을 빼면 일하는 좌석만 속도를 정하게 됩니다.

일정

대기열이 비지 않고 아무도 떠나지 않는다면, 신규 노드는 다음과 같이 들어옵니다.

첫해에 신규 노드 9개, 2년 차 말까지 25개, 3년 차까지 54개, 5년 차까지 약 155개가 됩니다. 집계 대상 좌석이 86개부터는 600 ÷ 86이 7일 미만이므로 최소값이 적용됩니다. 약 77번째 신규 노드부터, 즉 제네시스 약 3.5년 뒤부터 입회는 매주 이루어집니다. 모든 입회를 하나도 빠짐없이 차지한 신청자라도 제네시스 좌석 11개보다 많아지는 12번째 좌석은 437일째 무렵에야 갖게 됩니다.

기준값 항이 지연을 결정하는 동안에는 레지스트리가 단위 시간마다 일정한 비율로 커집니다. 입회마다 좌석이 하나씩 늘고, 지연은 기준값을 좌석 수로 나눈 값이기 때문입니다. 따라서 레지스트리가 두 배가 되는 데는 크기와 상관없이 약 기준값 × ln 2, mainnet에서 약 416일이 걸립니다.

특별한 경우

• 작은 레지스트리. 활성 노드가 min_registry_size(mainnet에서 7)보다 적은 동안에는 최대 지연이 7일로 제한됩니다.
• 긴 정체 뒤에는 타이머가 노드 하나를 입회시킨 다음 평소의 주기를 다시 이어 갑니다.
• devnet(개발 체인)은 같은 공식을 쓰되 기준값 180초, 최소값 60초, 최대값 300초를 사용하므로, 입회가 몇 분 간격으로 이루어집니다.

모든 입력이 체인에 있으므로, 누구나 다음 입회가 언제인지 다시 계산할 수 있습니다.

같이 보기

• 대기열
• 노드 레지스트리와 좌석
• 참여 증명과 PoW·PoS의 비교
• 참여 증명이 방어하는 위협
• mainnet의 노드 파라미터