Copy English

Why

The article is thin and the reading is the point. "The SLA is under legal review" is one status line in a documentation page, and the piece is that line inflated to a headline. Nothing about the data changed on 2026-09-01: the same tables answered the same queries the day before. What the line actually announces is a change of category — from Preview, where the vendor promises nothing, to something with a signed sentence about who bears the cost when the service is late. This is the-only-commitment-is-the-issuer seen from the vendor's side: every verb is explore until a document says otherwise, and the document is what is being written.

Then ask what Google is selling, because it is not the bytes. On-chain data is the one dataset in the world that is free, public and replicated by thousands of nodes; anyone can run an indexer against it. So the product is the promise — that the table is within N blocks of the head, that a reorg is handled one specific way, that the schema will not rename a column under a dashboard, and that a credit is owed when any of that fails. Those four things have no definitions in a Preview. The SLA is the first document in which the words available and unavailable acquire a meaning for a chain dataset, and the meaning is the interesting part: a warehouse SLA usually promises the endpoint answers, not that the data is current — which is bandwidth-not-capacity again, the serving guarantee separated from the thing served.

For a builder the consequence is short. "The query works today" is not a dependency you can put billing, settlement or a liquidation trigger on. supported-means-three-things made the same point about chains: a testnet proves the chain, a fork proves the protocol, only production proves the operator. Preview proves the tables exist. Read the SLA for the definition of unavailable, and expect the gap to sit exactly where a chain application lives — freshness is what the app needs and what a data warehouse's contract is least likely to promise.

How it works

What the product is

Only the last row is scarce. It is also the only row the news is about.

Preview vs. GA — what actually changes

What a chain-dataset SLA would have to define

Four questions for the day it is published

1. What is the unit of availability — request, minute, or block?
2. Is freshness measured at all, and against what head?
3. What happens to an orphaned block, and is that behaviour in the contract or in the docs?
4. What is the credit ceiling — because that number, not the uptime percentage, is the promise's actual size.

Where it lands in Jayverse

• Devnet: never treat a third-party data source's "Preview" status as a promise. Any service that reads chain data from an external warehouse or indexer for Devnet or Sepolia should record freshness (lag vs block head), completeness (reorg handling), and schema stability separately, and not build a settlement or liquidation trigger on an unSLA'd source.
• Auditor: define "available" and "unavailable" before consuming external data. Write down what freshness lag and reorg handling the Auditor row expects from any indexer or data provider it relies on, the same methodology-first discipline the row already claims for markets.
• Number: run the three-measurement checklist on any distributed reading's data source. Freshness gap, completeness under reorg, and schema diff are cheap tests to run on any external chain-data feed before Number republishes numbers derived from it.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

데이터는 원래 공개였다 — SLA 가 제품이다

구글 클라우드의 Blockchain Analytics 는 몇 년째 BigQuery 에서 조회할 수 있었고, 뉴스는 그 SLA 가 법무팀 손에 있다는 것입니다. 방향을 바로 잡고 읽어야 합니다: 데이터는 아무것도 바뀌지 않았습니다. 지금 만들어지고 있는 것은 책임 — 체인이 테이블보다 앞서 있을 때 누가 값을 치르는가 — 이고, 그 문장에 서명이 붙기 전까지 "프리뷰"는 약속이 0 이라는 뜻입니다.

아직 범위 미정 — 그리고 산출물은 시스템이 아니라 한 쪽짜리 표입니다: SLA 가 재는 것 대 체인 애플리케이션이 필요한 것. 측정 셋, 전부 SLA 가 나오기 전에 돌릴 수 있어서 문서가 도착하는 날 표에 이미 숫자가 들어 있게 합니다. 신선도. 하루 동안 1 분마다 데이터셋의 SELECT MAX(block_number) 와 라이브 RPC 의 eth_blockNumber 를 나란히 기록합니다. 그 간격의 분포 — 중앙값·p99·최악 — 이 진짜 SLA 라면 약속해야 할 숫자이고, 대부분의 웨어하우스 SLA 가 입을 다무는 숫자입니다. 완전성. 알려진 리오그(Sepolia 에는 많습니다)를 하나 잡아 고아 블록의 해시가 테이블에 아직 있는지, 교체됐는지, 애초에 없었는지 확인합니다. 절대 지우지 않는 데이터셋은 한 정의로는 완전하고 다른 정의로는 *틀립니다* — SLA 는 하나를 골라야 합니다. 스키마. 오늘 떠 둔 사본과 테이블 스키마를 diff 합니다. 이름이 바뀐 컬럼은, 아무도 테스트를 안 쓴 쿼리에게는 곧 장애입니다. SLA 가 나오면 정의된 용어 — available, unavailable, monthly uptime, credit — 를 이 세 줄에 대응시키고 무엇이 보장되는지 표시합니다. 예상 결과: availability 는 쿼리 엔드포인트가 응답한다는 뜻이고, 세 줄 중 어느 것도 약속되지 않는다. 그것이 결과물입니다. 출처: 디지털애셋(digitalasset.works), 2026-09-01, 구글 클라우드 문서의 Blockchain Analytics SLA 상태 줄에 대한 보도; 구글 클라우드 Blockchain Analytics 문서 자체(Preview 상태, GA 일정 미공개).

왜

기사는 얇고, 읽는 방향이 핵심입니다. "SLA 가 법무 검토 중"은 문서 페이지의 상태 줄 하나이고, 이 기사는 그 줄을 헤드라인으로 키운 것입니다. 2026-09-01 에 데이터는 아무것도 바뀌지 않았습니다 — 같은 테이블이 전날과 같은 쿼리에 답합니다. 그 줄이 실제로 알리는 것은 범주의 변화입니다 — 벤더가 아무것도 약속하지 않는 프리뷰에서, 서비스가 늦을 때 누가 비용을 지는지에 대한 서명된 문장이 있는 무언가로. 이것은 the-only-commitment-is-the-issuer 를 벤더 쪽에서 본 것입니다: 문서가 달리 말하기 전까지 모든 동사는 탐색이고, 지금 쓰이고 있는 것이 바로 그 문서입니다.

그다음 구글이 무엇을 파는지 물어야 합니다 — 바이트가 아니니까요. 온체인 데이터는 세상에서 유일하게 공짜이고 공개이며 수천 노드에 복제된 데이터셋입니다; 누구나 인덱서를 돌릴 수 있습니다. 그러니 제품은 약속입니다 — 테이블이 헤드에서 N 블록 안에 있다, 리오그는 정해진 한 방식으로 처리된다, 대시보드 밑에서 컬럼 이름이 바뀌지 않는다, 그중 하나라도 어기면 크레딧을 준다. 이 넷은 프리뷰에서는 정의가 없습니다. SLA 는 체인 데이터셋에 대해 available 과 unavailable 이 처음으로 뜻을 갖는 문서이고, 그 뜻이 흥미로운 부분입니다: 웨어하우스 SLA 는 보통 엔드포인트가 응답한다는 것을 약속하지 데이터가 최신이라는 것을 약속하지 않습니다 — bandwidth-not-capacity 의 반복, 서빙 보장이 서빙되는 물건과 분리되는 것.

빌더에게 결론은 짧습니다. "오늘 쿼리가 된다"는 청구·정산·청산 트리거를 얹을 수 있는 의존성이 아닙니다. supported-means-three-things 가 체인에 대해 같은 말을 했습니다: 테스트넷은 체인을, 포크는 프로토콜을, 운영자는 프로덕션만이 증명합니다. 프리뷰는 테이블이 존재한다는 것을 증명합니다. SLA 에서 unavailable 의 정의를 읽고, 그 빈틈이 체인 애플리케이션이 사는 바로 그 자리에 있을 것을 예상하십시오 — 신선도는 앱이 필요한 것이자 데이터 웨어하우스 계약이 가장 약속하지 않을 것입니다.

동작 방식

제품이 무엇인가

마지막 줄만 희소합니다. 그리고 뉴스가 다루는 줄도 그것뿐입니다.

프리뷰 vs. GA — 실제로 바뀌는 것

체인 데이터셋 SLA 가 정의해야 할 것

발표되는 날 물을 질문 넷

1. 가용성의 단위는 무엇인가 — 요청, 분, 블록?
2. 신선도를 재기는 하는가, 어느 헤드를 기준으로?
3. 고아 블록은 어떻게 되는가, 그 동작은 계약에 있는가 문서에 있는가?
4. 크레딧 상한은 얼마인가 — 가동률 퍼센트가 아니라 그 숫자가 약속의 실제 크기이니까.

Jayverse에서의 위치

• Devnet: 외부 데이터 소스의 "Preview" 상태를 약속으로 여기지 않는다. Devnet이나 Sepolia용 체인 데이터를 외부 웨어하우스나 인덱서에서 읽는 서비스는 신선도(블록 헤드 대비 지연), 완전성(리오그 처리), 스키마 안정성을 각각 기록하고, SLA 없는 소스 위에 정산이나 청산 트리거를 얹지 않는다.
• Auditor: 외부 데이터를 소비하기 전에 "available"과 "unavailable"을 정의해둔다. Auditor 행이 의존하는 인덱서나 데이터 제공자에게 기대하는 신선도 지연과 리오그 처리 방식을 적어두는 것은, 이 행이 마켓에 대해 이미 주장하는 방법론 우선 원칙과 같다.
• Number: 배포되는 모든 외부 체인 데이터 피드에 세 가지 측정을 돌린다. 신선도 격차, 리오그 하에서의 완전성, 스키마 diff는 Number가 파생 수치를 다시 배포하기 전에 돌려볼 값싼 테스트다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑