Avail은 블록 데이터에 대한 polynomial commitment를 header에 두고 light client가 무작위 cell과 KZG proof를 요청해 committed 데이터의 조각이 공개됐는지 샘플링합니다. 유효한 응답이 쌓이면 설정된 confidence로 데이터 가용성을 판단하지만, 그 bytes를 실행했을 때 올바른 state transition인지까지 증명하지는 않습니다. inclusion, availability, finality, validity를 각각 확인해야 합니다.
commitment는 데이터를 짧게 약속한다
큰 데이터 행렬을 header에 그대로 넣을 수 없으므로 Avail은 확장된 block data를 polynomial로 보고 KZG commitment를 사용합니다. commitment는 짧은 값으로 특정 polynomial에 묶이며, 검증자는 한 평가점의 cell과 proof를 받아 그 값이 committed polynomial과 일치하는지 확인할 수 있습니다.
이 성질은 ‘proof가 맞는 cell’과 ‘충분한 데이터가 공개됨’을 구분하게 합니다. 단일 KZG proof가 유효해도 다른 많은 cell이 숨겨졌을 수 있습니다. 그래서 erasure coding과 여러 무작위 sampling query가 함께 필요합니다. commitment는 진실한 실행 결과보다 bytes 일관성에 답합니다.
KZG는 받은 조각이 약속한 다항식의 조각임을 확인하고, sampling은 충분한 조각이 공개됐을 가능성을 묻는다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- commitment는 데이터를 짧게 약속한다
큰 데이터 행렬을 header에 그대로 넣을 수 없으므로 Avail은 확장된 block data를 polynomial로 보고 KZG commitment를 사용합니다.
- light client는 header와 표본을 순서대로 검증한다
light client는 먼저 자신이 추적하는 Avail chain header의 finality를 확인하고, header가 담은 data commitment를 기준으로 cell을 샘플링합니다.
- App ID는 선택 조회의 경계다
Avail에 제출되는 application data는 App ID로 구분될 수 있고 light client의 app-client mode는 해당 ID 데이터를 선택해 받을 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
light client는 header와 표본을 순서대로 검증한다
light client는 먼저 자신이 추적하는 Avail chain header의 finality를 확인하고, header가 담은 data commitment를 기준으로 cell을 샘플링합니다. 무작위 좌표의 cell과 proof가 유효하게 돌아오면 confidence가 올라갑니다. API가 finished 상태와 confidence를 반환하더라도 어느 block number와 header hash를 대상으로 했는지 함께 저장해야 합니다.
status에는 pending, verifying-header, verifying-confidence, verifying-data, finished 같은 처리 단계가 있을 수 있습니다. finished라는 문자열만 보고 앱 blob을 내려받았다고 단정하면 안 됩니다. light client mode와 data fetching 설정에 따라 header·confidence·app data 범위가 달라질 수 있으므로 응답 필드를 확인합니다.
| 증거 | 확인하는 것 | 별도 확인 |
|---|---|---|
| header finality | canonical Avail block 추적 | 앱 blob 내용 |
| KZG cell proof | cell과 commitment 일치 | 전체 가용성 |
| sampling confidence | 코딩 가정 아래 공개 가능성 | rollup state validity |
| app inclusion proof | 특정 app data 포함 | 장기 보존 |
App ID는 선택 조회의 경계다
Avail에 제출되는 application data는 App ID로 구분될 수 있고 light client의 app-client mode는 해당 ID 데이터를 선택해 받을 수 있습니다. 그러나 올바른 App ID로 조회했다는 사실만으로 제출 transaction의 sender나 rollup batch 의미가 자동 검증되지는 않습니다. block number, extrinsic index와 inclusion 자료를 함께 보관합니다.
동일 bytes가 여러 앱 의미로 해석될 수 있으므로 rollup은 자체 framing, batch hash, signer 규칙을 적용해야 합니다. DA는 데이터가 공개되고 committed됐다는 기반을 제공하지만 앱 프로토콜의 인증·순서·실행 검사는 위에 남습니다.
- light client가 추적한 network·block number·header hash를 고정한다
- cell 좌표·KZG proof와 confidence를 원 응답으로 보관한다
- App ID와 extrinsic·data inclusion을 연결한다
- rollup batch commitment와 validity proof를 별도 검증한다
confidence 숫자는 설정과 표본 이력에 의존한다
confidence가 99% 이상이라는 표시는 보편 상수가 아닙니다. 필요한 숨김 비율, 표본 수, 좌표 독립성과 peer 응답 가정으로 계산됩니다. 여러 클라이언트가 같은 제공자에 의존하거나 표본 선택이 예측 가능하면 운영상 독립성이 약해질 수 있습니다.
대시보드는 confidence와 함께 sampled cells, failed queries, retry, peer 수와 sync depth를 보여 주는 편이 낫습니다. 오래된 block이 unavailable 상태로 표시되는 것이 공격 때문인지 light client의 보관·sync window 밖인지 API 설명을 확인해야 합니다.
validity proof와 DA proof를 합치지 않는다
rollup validity proof는 공개된 입력으로 특정 state transition이 규칙대로 계산됐는지 답합니다. DA sampling은 그 입력 bytes를 참여자가 얻을 수 있었는지 묻습니다. 유효하지만 숨겨진 state transition도 문제이고, 공개됐지만 잘못 실행된 batch도 문제입니다. 두 증거는 대체재가 아닙니다.
실무 판단은 Avail finality, data commitment, sampling confidence, app inclusion, rollup validity를 다섯 열로 둡니다. 한 열이 성공했다고 나머지를 자동 완료 처리하지 않으면 bridge와 rollup 모니터링에서 proof 범위를 과장하지 않게 됩니다.
자주 묻는 질문
KZG proof 하나가 맞으면 블록 전체가 available한가요?
아닙니다. 특정 cell의 commitment 일치를 확인하며 전체 가용성은 여러 무작위 표본과 coding 가정으로 판단합니다.
light client의 finished는 rollup 실행까지 검증했다는 뜻인가요?
아닙니다. header·confidence·data fetching 단계의 완료이며 rollup validity는 별도입니다.
App ID만 알면 내 blob 포함을 증명할 수 있나요?
App ID는 선택 기준이며 block·extrinsic과 commitment에 연결되는 inclusion 자료가 추가로 필요합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
