작동 원리2026-10-19약 4분

IoTeX 잔지바르: 투표자 보상은 누가 계산할까?

IoTeX의 보상 이체는 이미 체인에 기록됐다. 잔지바르는 그 계산과 분배를 체인의 규칙 안으로 옮긴다. 스냅샷과 참여 조건, 여러 블록에 나눠 처리하는 방식이 핵심이다.

AI로 만든 개념 일러스트. 두 사람이 고정된 기준표로 같은 배분을 재현한다. 계산용 조각은 공통 규칙의 비유이며, 실제 지급이나 모든 투표자에게 같은 보상을 준다는 뜻이 아니다.

핵심 요약

IoTeXScan은 잔지바르 활성화 블록 53,533,081의 시각을 2026년 10월 19일 02:28:37 UTC로 기록한다. 공지의 02:00은 예상 시각이었다.
IIP-59는 참여 조건을 충족한 대표자의 투표자 보상 계산·분배를 프로토콜 규칙 안으로 옮긴다. Hermes도 이체 자체는 이미 온체인에 기록했다.
배포 설정은 보상 기간을 24에포크, 블록당 처리 예산을 투표자 256명으로 둔다. 이전 여부·배분 비율·지급 목적지에는 여전히 조건이 있다.

사건의 흐름 한눈에 보기

2026-09-24활성화 높이 변경

공식 노트가 10월 8일 예상을 블록 53,533,081과 10월 19일 예상으로 바꿨다.

2026-10-04일정을 유지한 유지보수 릴리스

v2.5.1이 잔지바르 높이를 유지하고 별도 하드포크를 추가하지 않은 채 공개됐다.

2026-10-19예정된 블록이 기록됨

IoTeXScan과 재단의 공개 RPC가 블록 53,533,081의 시각을 02:28:37 UTC로 동일하게 반환했다.

보상이 지갑에 도착하기 전에

지갑에 보상이 들어오기까지는 여러 계산이 필요하다. 어떤 스테이킹이 집계됐는지, 어느 대표자에게 투표했는지, 그 대표자가 투표자에게 얼마의 비율을 배분했는지, 돈을 어디로 보낼지를 정해야 한다. IoTeX의 Hermes는 참여한 대표자를 위해 이 과정을 자동화했다. 분배에는 이미 스마트 계약을 사용했고 온체인 기록도 남겼다. 잔지바르를 보상이 처음 체인에 보이게 된 사건이라고 설명하면 핵심을 놓친다.^[5]

잔지바르는 참여한 대표자의 보상 계산과 분배를 프로토콜 자체의 일로 만든다. 별도 서비스가 계산한 결과를 제출하기를 기다리는 대신, 검증자들이 체인에 확정된 상태로부터 결과를 계산하며 블록을 처리한다. IIP-59의 중심 생각은 지급에 앞선 계산까지 노드들이 함께 재현하는 규칙에 넣는 것이다.^[1][3]

시각은 예상이고 블록은 기록이다

메인넷 활성화 지점은 블록 53,533,081이었다. IoTeXScan에 기록된 생성 시각은 2026년 10월 19일 02:28:37 UTC다. 배포 코드도 Zanzibar·Zanzibar Beta·Zanzibar Gamma를 모두 같은 높이에 배치한다. 이 블록 기록은 활성화 지점에 도달했음을 뒷받침한다. 앞서 공지한 02:00 UTC는 예상치였으며 실제 블록 시각이 아니다.^[2][4]

중간에 일정도 바뀌었다. 9월 24일 문서 커밋은 10월 8일로 예상했던 블록 53,155,801 대신 더 뒤의 높이를 지정했다. 10월 4일 공개된 유지보수 버전 v2.5.1도 새 일정을 유지했다. 테스트넷에서는 각 단계가 따로 활성화됐지만, 메인넷은 Beta·Gamma의 수정사항을 잔지바르와 함께 받는다. 소프트웨어 공개일, 예상 포크 시각, 실제 활성화 블록은 서로 다른 단계를 가리킨다.^[9][8][1]

계산 기준을 고정하고 작업을 나눈다

보상 처리는 쌓는 단계와 정산하는 단계로 나뉜다. 대표자 몫은 바로 지급하고, 투표자 몫은 해당 대표자에 연결된 풀에 모은다. 보상 기간의 경계에서는 대표자 설정과 스테이킹 상태 등 정산에 필요한 기준을 고정한다. 배포 설정의 한 보상 기간은 24에포크다. 이것이 매일 정해진 시각에 지급한다는 약속은 아니다.^[3][4]

그다음 여러 블록에 걸쳐 작업을 나눠 지급한다. 배포된 기본값은 한 작업 묶음이 처리할 서로 다른 투표자를 256명으로 제한한다. 전체 분배를 한 블록에 몰아넣지 않는 방식이다. 그사이 스테이킹 상태가 달라져도 스냅샷은 해당 정산의 계산을 앞선 기준에 묶어 둔다. 비유하면 확정된 배분표를 조금씩 처리하는 셈이다. 현재 장부에 나중에 적힌 변화가 이미 정산 중인 배분표까지 몰래 바꾸지는 않는다.^[3][4]

한 번의 포크가 모두를 같은 경로로 옮기지는 않는다

Hermes 자동 이전은 활성화 때 한 번 실행된다. 지정된 Hermes 보관 주소를 보상 주소로 사용하는 후보를 고르되, DelegateProfile에 투표자 보상 비율 필드 두 개가 모두 있어야 한다. 설정이 빠진 후보는 기존 Hermes 경로에 남는다. 다른 후보는 소유자가 승인한 동작으로 참여할 수 있다. 릴리스 노트의 과거 후보 집계는 포크 전 한 시점의 관측이며, 10월 19일 실제로 이전한 대상을 감사한 수치가 아니다.^[1][6]

여러 대표자로부터 계산된 한 투표자의 몫은 하나의 지급으로 합칠 수 있다. 지급 경로 코드는 설정된 목적지 계정의 잔액을 늘리거나, 자동 예치 조건을 충족하면 자격 있는 네이티브 스테이킹 버킷에 금액을 더한다. 배정된 보상이 도착하는 목적지가 다른 것이다. IOTX를 보유했다는 사실만으로 참여 여부나 보상액, 자동 재예치 권리가 생기지는 않는다.^[3][7]

활성화 다음에 확인할 것

활성화 블록과 배포 규칙으로 확인한 것은 예정된 전환 지점에 도달했다는 사실이다. 모든 대상 투표자에게 이미 지급됐다는 사실까지 입증한 것은 아니다. 포크 뒤에도 보상 기간의 경계, 나눠 처리하는 과정과 대표자 설정이 영향을 준다. 이 글은 활성화 기록을 확인하고 배포된 설계를 설명한다. 개별 지급 내역이나 실현 수익을 감사한 결과는 아니다.^[1][2][4]

특정 지급을 확인할 때 질문은 구체적이어야 한다. 대표자가 새 방식에 참여했는지, 해당 정산에서 어떤 설정과 스테이킹 상태를 고정했는지, 어떤 잔액 증가나 예치가 기록됐는지를 봐야 한다. 잔지바르는 그 계산의 연결을 공통 실행 규칙에 넣는다. 참여 조건을 충족한 스테이킹이 기록된 지급으로 이어지는 과정을 같은 규칙으로 따져 볼 수 있게 된 것이 변화의 가치다. 누가 얼마를 받는지는 여전히 그 규칙과 입력값이 결정한다.^[3][6][7]

다음 질문으로