Pactus Berlin: 프루닝 뒤에 남는 앵커의 의미

소프트웨어 출시와 프로토콜 전환 사이

2026년 10월 28일 Pactus가 Berlin이라는 이름의 1.17.0을 출시했다. 네이티브 상태 앵커는 계정에 외부 데이터를 가리키는 현재의 약속을 남길 자리를 마련한다. 릴리스와 구현은 공개됐지만 PIP-50은 기능 적용 조건을 protocol v5로 정한다. 이 글은 공개 설계와 출시된 코드를 해설하며, 메인넷이 v5로 전환됐음을 독립적으로 확인한 보도는 아니다.^[1][2][3]

PIP-51에 따르면 제안자는 자신이 관측한 지원 신호가 위원회 검증 권한의 75%를 초과하면 블록 버전을 올린다. 노드 수의 75%라는 뜻이 아니다. PIP-50은 중요한 조건을 덧붙인다. 이는 제안자의 전환 규칙이지, 각 노드가 따로 본 지원 비율로 블록의 유효성을 판단하는 규칙이 아니다. 관측값은 노드마다 다를 수 있다. 노드는 유효하고 인증된 v5 블록을 받아들이며, 필요한 인증서를 만들려면 위원회 권한의 3분의 2를 초과하는 몫이 v5 지원 소프트웨어를 실행해야 한다. 릴리스 태그나 지원 비율만으로 전환 완료를 입증할 수 없는 이유다.^[3][4]

과거 영수증과 현재의 표시

거래 메모는 계정이 과거에 어떤 해시를 기록했는지 보여 줄 수 있다. 지금도 그 해시를 지지하는지는 다른 질문이다. PIP-50은 계정의 현재 상태에 선택적인 앵커 하나를 넣고, 기존 계정 머클 트리와 전체 상태 루트에 포함한다. 오래된 거래 본문을 프루닝한 노드도 살아 있는 슬롯은 읽을 수 있다.^[3]

슬롯에는 길이가 제한된 해시, 외부 데이터의 선택적 위치, 유형 힌트, 잠긴 예치금, 생성·갱신 필드가 들어간다. 문서 원본이나 앱 데이터베이스, 검색 인덱스는 저장하지 않는다. 예를 들어 서비스 명세서를 다루는 앱은 옛 거래가 있다는 이유만으로 명세서가 여전히 유효하다고 보는 대신, 외부 문서를 계정의 현재 해시와 대조할 수 있다. 이는 PIP가 설명하는 응용 방식이며 실제 서비스 도입을 입증하는 사례는 아니다.^[3]

예치금은 슬롯을 차지하는 동안 잠긴다

상세 규칙은 생성·갱신 예치를 묶어 설명한 발표문보다 구체적이다. 슬롯을 처음 만들 때는 최소 1 PAC를 잠근다. 기존 슬롯을 갱신할 때 추가 예치는 0이어도 된다. 기존 예치금은 유지되고 거래 수수료는 적용된다. v1.17.0 실행 코드는 앵커가 없을 때만 최소 예치 검사를 적용한다. 슬롯을 삭제하면 잠긴 예치금에서 삭제 수수료를 뺀 금액이 돌아온다. 현재 상태의 점유에 따른 반환 가능한 잠금이지, 이자나 수익 또는 모든 동작이 무료라는 약속이 아니다.^[3][5]

블록의 시각과 독립적인 시계

생성 높이와 시각은 슬롯을 만든 블록에서 가져온다. 서명자가 임의의 타임스탬프 필드를 넣을 수 없다. 갱신 필드는 현재 루트 해시를 설정한 블록을 가리킨다. 해시를 유지한 채 위치, 유형 힌트, 예치금만 바꾸면 그 날짜를 다시 쓰지 않는다. PIP-50과 릴리스 태그의 실행 코드 모두 이 구분을 유지한다.^[3][5]

따라서 거래 작성자가 앵커 페이로드에 원하는 날짜를 적어 넣는 일은 막는다. 그렇다고 타임스탬프가 신뢰할 수 있는 외부 시계가 되지는 않는다. Unix 시각은 제안자의 블록 헤더에서 오며 프로토콜이 허용하는 시간 범위의 제약을 따른다. PIP-50은 순서를 판단하는 기준으로 블록 높이를 든다. 해시에 붙은 날짜는 체인에서의 관측 기록이지, 현실의 정확한 순간을 독립적으로 증명하는 값으로 읽어서는 안 된다.^[3]

앵커를 지우면 날짜도 사라진다

프루닝에 견딘다는 약속의 범위는 좁다. 현재 상태에 남은 슬롯은 최초 거래 없이도 읽을 수 있다. 삭제 뒤 GetAnchor는 활성 슬롯이 없다고 답하며 타임스탬프 필드도 사라진다. 현재 상태만 보면 한 번도 앵커를 만들지 않은 계정과 만들었다가 지운 계정을 구분할 수 없다. 삭제 시점도 알 수 없다. 그 증거는 삭제 거래에 있고, 프루닝한 노드는 이미 그 거래를 보관하지 않을 수 있다.^[3]

이 차이는 폐기 기록에 중요하다. 슬롯을 없애면 현재의 증명 상태는 끝나지만, 그 자리에 날짜가 붙은 영구 폐기 표식이 남는 것은 아니다. PIP는 프루닝 뒤에도 폐기 근거가 필요할 때 쓸 다른 응용 방식을 설명한다. 슬롯을 유지하고 현재 루트가 폐기 목록을 담도록 하는 것이다. 목록의 의미와 뒷받침하는 데이터는 여전히 앱이 책임진다.^[3]

해시가 일치해도 남는 질문

외부 데이터와 기록된 해시를 대조하면 선택한 해시 규약 아래에서 무결성을 확인할 수 있다. 문서 내용이 사실인지, 주소가 특정 인물의 것인지, 외부 파일이 계속 제공될지는 증명하지 못한다. 선택적으로 넣는 위치 정보도 신뢰할 수 없는 입력이며, 합의 과정은 이를 가져오거나 해석하지 않는다. 여러 항목을 오프체인 머클 트리 하나로 묶어 약속할 수 있지만 파일과 포함 증명은 여전히 체인 밖에서 전달된다.^[3]

상태에 담긴 약속과 화면에 나온 응답도 구분해야 한다. PIP-50의 GetAnchor에는 상태 루트에 대한 증명이 붙지 않는다. 다른 사람의 RPC 서버나 탐색기에 묻는 클라이언트는 그 서비스의 답을 신뢰하며, 메서드 하나로 그 신뢰가 없어지지 않는다. Berlin 설계의 가치는 계정의 현재 표시와 과거 영수증을 구분하는 데 있다. 이를 정확히 읽으려면 문서의 무결성, 신원, 시각, 가용성, 조회 응답의 출처를 각각의 질문으로 남겨 두어야 한다.^[3]