Avail 데이터 가용성 증명: KZG commitment와 light client가 확인하는 것

Avail은 블록 데이터에 대한 다항식 약속값(polynomial commitment)을 헤더에 둡니다. 경량 클라이언트(light client)는 무작위 셀(cell)과 KZG 증명을 요청해, 약속된 데이터의 조각들이 실제로 공개됐는지 표본 검사합니다. 올바른 응답이 쌓이면 정해진 신뢰도로 데이터 가용성을 판단합니다. 하지만 그 바이트를 실행했을 때 상태 전이가 올바른지까지 증명하지는 않습니다. 포함 여부, 가용성, 완결성, 유효성은 저마다 따로 확인해야 합니다.

약속값은 데이터를 짧게 묶어 둡니다

커다란 데이터 행렬을 헤더에 통째로 넣을 수는 없습니다. 그래서 Avail은 확장한 블록 데이터를 다항식으로 보고 KZG 약속값을 씁니다. 약속값은 짧은 값 하나로 특정 다항식에 묶이며, 검증자는 한 평가점의 셀과 증명을 받아 그 값이 약속된 다항식과 맞는지 확인할 수 있습니다.

이 성질 덕분에 ‘증명이 맞는 셀’과 ‘충분한 데이터가 공개됨’을 나눠 볼 수 있습니다. KZG 증명 하나가 유효해도 다른 셀 상당수는 숨겨져 있을 수 있습니다. 그래서 소거 부호화(erasure coding)와 여러 번의 무작위 표본 조회가 함께 필요합니다. 약속값은 실행 결과가 참인지보다 바이트가 일관된지에 답합니다.

KZG는 받은 조각이 약속한 다항식의 조각인지 확인합니다. 표본 검사는 충분한 조각이 공개됐을 가능성을 따집니다.

JOBCOIN 해설

그림으로 보기체인 사이의 검증 과정

1. 01
   약속값은 데이터를 짧게 묶어 둡니다

   커다란 데이터 행렬을 헤더에 통째로 넣을 수는 없습니다.

2. 02
   경량 클라이언트는 헤더와 표본을 차례로 검증합니다

   경량 클라이언트는 먼저 자신이 따라가는 Avail 체인 헤더의 완결성을 확인하고, 헤더에 담긴 데이터 약속값을 기준으로 셀을 표본 추출합니다.

3. 03
   앱 ID는 선택 조회의 경계선입니다

   Avail에 올라오는 애플리케이션 데이터는 앱 ID(App ID)로 구분될 수 있고, 경량 클라이언트의 앱 전용 모드는 해당 ID의 데이터만 골라 받을 수 있습니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

경량 클라이언트는 헤더와 표본을 차례로 검증합니다

경량 클라이언트는 먼저 자신이 따라가는 Avail 체인 헤더의 완결성을 확인하고, 헤더에 담긴 데이터 약속값을 기준으로 셀을 표본 추출합니다. 무작위 좌표의 셀과 증명이 올바르게 돌아오면 신뢰도가 올라갑니다. API가 finished 상태와 신뢰도를 돌려주더라도 어느 블록 번호와 헤더 해시를 대상으로 했는지 함께 저장해야 합니다.

상태값에는 pending, verifying-header, verifying-confidence, verifying-data, finished 같은 처리 단계가 있을 수 있습니다. finished라는 문자열만 보고 앱 데이터 묶음까지 내려받았다고 단정하면 안 됩니다. 경량 클라이언트의 동작 방식과 데이터 수집 설정에 따라 헤더, 신뢰도, 앱 데이터의 범위가 달라지므로 응답 필드를 확인합니다.

앱 ID는 선택 조회의 경계선입니다

Avail에 올라오는 애플리케이션 데이터는 앱 ID(App ID)로 구분될 수 있고, 경량 클라이언트의 앱 전용 모드는 해당 ID의 데이터만 골라 받을 수 있습니다. 그렇다고 올바른 앱 ID로 조회했다는 사실만으로 제출 거래의 발신자나 롤업 배치의 의미가 저절로 검증되지는 않습니다. 블록 번호, 외부 호출(extrinsic) 순번, 포함 자료를 함께 보관합니다.

같은 바이트를 여러 앱이 서로 다른 뜻으로 읽을 수 있으므로, 롤업은 자체 프레이밍과 배치 해시, 서명자 규칙을 적용해야 합니다. 데이터 가용성 계층은 데이터가 공개되고 약속됐다는 바탕을 제공하지만 앱 프로토콜의 인증·순서·실행 검사는 그 위에 그대로 남습니다.

• 경량 클라이언트가 따라간 네트워크·블록 번호·헤더 해시를 고정합니다
• 셀 좌표·KZG 증명과 신뢰도를 원래 응답 그대로 보관합니다
• 앱 ID와 외부 호출·데이터 포함 자료를 이어 둡니다
• 롤업 배치 약속값과 유효성 증명은 따로 검증합니다

신뢰도 숫자는 설정과 표본 이력에 달려 있습니다

신뢰도 99% 이상이라는 표시는 어디서나 통하는 상수가 아닙니다. 숨겨야 하는 비율, 표본 수, 좌표의 독립성, 피어 응답에 대한 가정으로 계산한 값입니다. 여러 클라이언트가 같은 제공자에 기대거나 표본 선택을 예측할 수 있다면 운영상의 독립성이 약해질 수 있습니다.

대시보드에는 신뢰도와 함께 표본 셀 수, 실패한 조회, 재시도, 피어 수, 동기화 깊이를 보여 주는 편이 낫습니다. 오래된 블록이 unavailable로 표시될 때 공격 때문인지, 경량 클라이언트의 보관·동기화 범위를 벗어났기 때문인지 API 설명을 확인해야 합니다.

유효성 증명과 가용성 증명을 하나로 묶지 않습니다

롤업의 유효성 증명은 공개된 입력으로 특정 상태 전이가 규칙대로 계산됐는지에 답합니다. 가용성 표본 검사는 그 입력 바이트를 참여자들이 얻을 수 있었는지를 묻습니다. 올바르지만 숨겨진 상태 전이도 문제이고, 공개됐지만 잘못 실행된 배치도 문제입니다. 두 증거는 대체재가 아닙니다.

실무에서는 Avail 완결성, 데이터 약속값, 표본 신뢰도, 앱 포함, 롤업 유효성을 다섯 열로 나눠 둡니다. 한 열이 성공했다고 나머지를 자동으로 완료 처리하지 않아야 브리지와 롤업 모니터링에서 증명의 범위를 부풀리지 않게 됩니다.

자주 묻는 질문