데이터셋

데이터셋은 ZooBC에 데이터를 올리는 가장 단순한 방법입니다. 한 계정이 어떤 계정(보통 자기 자신) 아래에 기록하는 속성 이름과 그 값으로 된 작은 기록입니다. 모든 노드가 이 행을 체인 상태의 일부로 보관하므로, 어떤 앱이든 어느 노드의 API를 통해서나 이를 읽을 수 있습니다. 앱들은 행을 프로필, 설정, 릴리스 공지, 청구서, 토큰 아이콘에 씁니다.

행

SetupAccountDataset 트랜잭션(유형 3)은 다음 세 가지를 키로 하는 행 하나를 기록합니다.

• 설정자: 트랜잭션을 보내는 계정
• 수신자: 행이 놓이는 계정. 보통 설정자 자신입니다(빈 수신자도 유효한 키입니다).
• 속성: 1~256바이트의 이름이며, 결코 비어 있을 수 없습니다.

값은 최대 65,536바이트의 트랜잭션 본문 안에서 최대 4,096바이트를 담습니다. 행에는 버전이 있습니다. 같은 키로 다시 기록하면 현재 행을 대체하며, RemoveAccountDataset(유형 259)은 행을 비활성화합니다.

행은 공개됩니다. 누구나 읽을 수 있으므로 데이터셋은 비밀을 둘 곳이 아닙니다. 큰 파일을 보관하는 방법도 아닙니다. 작은 파일은 체인 위의 파일 (DFS)로, 큰 파일은 분산 저장소 풀로 갑니다.

누가 기록했는지가 중요합니다

누구나 결제를 어느 주소로든 보낼 수 있는 것과 마찬가지로, 어떤 계정이든 어느 수신자 아래에든 행을 기록할 수 있으며 수신자에게 묻지 않습니다. 따라서 행은 설정자가 수신자에 대해 하는 진술입니다. 체인은 누가 언제 그렇게 말했는지 증명하지만, 그 진술이 사실인지는 알 수 없습니다.

노드는 GET /api/v1/accounts/<address>/datasets에서 계정의 행을 보여 주며, ?property=<prefix>로 걸러 볼 수도 있습니다. 목록은 그 주소가 설정자나 수신자인 모든 행을 돌려주며, 각 행에는 설정자, 수신자, 둘 다 중 하나를 나타내는 role이 붙습니다. 사용자 아래에서 "verified = yes"를 찾은 앱은 설정자가 자신의 검증 계정처럼 신뢰하는 계정일 때만 이를 받아들여야 하며, 그런 행이 없으면 "검증되지 않음"으로 답해야 합니다(체인 데이터는 신뢰할 수 없는 입력이다).

객체와 소유자

모든 행은 그것을 만든 트랜잭션의 해시로 이름이 붙는 데이터셋 객체에 속합니다. 객체에는 소유자(처음에는 생성자), 대기 중인 소유자, 관리 방식이 있습니다.

• 넘겨주기는 두 단계로 이루어집니다. 소유자가 새 소유자를 지정한 TransferDataset(유형 42)을 보내면, 체인은 대기 중인 소유자만 기록합니다. 그 계정이 AcceptDataset(유형 44)을 보내면 넘겨주기가 완료됩니다. 다른 사람이 보낸 AcceptDataset이나, 대기 중인 소유자가 없는 객체에 대한 AcceptDataset은 수수료를 내는 무동작입니다. 수수료가 부과되고 아무것도 바뀌지 않습니다. 따라서 누구도 요청하지 않은 계정에 객체와 그에 딸린 임대료를 떠넘길 수 없으며, 새 소유자가 수락할 때까지 이전 소유자가 소유자로 남습니다.
• 삭제. 소유자가 보내는 DeleteDataset(유형 45)은 객체의 모든 행을 비활성화하며, 객체의 예치금은 롱제비티 풀로 쓸려 갑니다.
• 정책. SetDatasetPolicy(유형 43)는 객체에 관리 방식(소유자 전용, 화이트리스트, 블랙리스트, 공개)과 접근 목록을 저장하지만, 어떤 합의 규칙도 이를 읽지 않으므로 아무것도 제한하지 않습니다.

각 객체에는 예치금 주소도 있습니다. 유형 10의 계정으로 ZBS_…로 적으며, 그 바이트는 0A000000 뒤에 객체 id를 붙인 것입니다. 누구나 일반 SendZBC로 여기에 자금을 넣을 수 있으므로, 여러 사용자가 함께 공유 기록을 유지할 수 있습니다. 이는 자금이 들어 있는 일반 계정이므로 계정 임대료도 냅니다. GET /api/v1/dataset-address/<hash or ZBS_ address>가 이를 보여 줍니다.

임대료

mainnet에서 과금 기간인 172,800블록(약 30일)마다 한 번, 체인은 각 객체에 활성 행의 바이트에 대한 비용을 청구합니다.

bytes = sum of (property + value) over the object's active rows
rent  = ceil(bytes × price per MiB ÷ 1,048,576), then × storage multiplier, rounded up

시작 가격은 MiB당 5,000,000 원자 단위(0.05 ZBC)이고, 저장 배수는 1.0에서 시작합니다. 행 1 MiB 전체는 기간당 정확히 0.05 ZBC를 냅니다. 14바이트 속성과 300바이트 값으로 이루어진, 모두 314바이트인 행은 1,498단위를 냅니다. 314 × 5,000,000 ÷ 1,048,576은 1,497.27이며, 요금 계산의 단계마다 올림하기 때문입니다.

임대료는 먼저 예치금에서, 그다음 소유자의 잔액에서 가져갑니다. 둘을 합쳐도 낼 수 없으면 객체의 모든 행이 비활성화되고 남은 예치금은 롱제비티 풀로 갑니다. 수신자에게는 결코 청구하지 않습니다. 모든 데이터셋 임대료는 매 블록 노드들에게 한 조각씩 지급하는 롱제비티 풀에 입금됩니다. ZBC는 결코 소각되지 않습니다.

과금 기간은 스냅샷 간격을 따릅니다. 가격은 좌석들이 투표로 정하며 원자 단위 하나까지 내려갈 수 있습니다. 스냅샷 주기마다 한 번, 정해진 범위 안에서 집계 대상 좌석들의 투표 평균으로 움직입니다(가격 투표).

예약된 접두사

몇몇 속성 접두사는 예약되어 있으며, 체인은 그 행을 받아들이기 전에 검사합니다. 검사는 속성 앞부분의 원시 바이트를 비교하므로, invoice:는 inv:가 아닙니다.

따라서 토큰의 아이콘은 URL 뒤가 아니라 체인 위, 행 안에 있습니다. 이 검사들 중 누군가의 서명을 필요로 하는 것은 없습니다. 모든 노드가 같은 규칙을 적용합니다.

같이 보기

• 체인 위의 파일 (DFS)
• 체인 데이터는 신뢰할 수 없는 입력이다
• 데이터 보관 비용 (롱제비티)
• 계정 임대료와 정리
• 데이터와 저장소