← 모든 글

읽는 데 10분

웹사이트 없이 CardanoWall 사용하기

웹사이트는 하나의 인터페이스일 뿐, 제품 전체가 아닙니다. CLI, SDK, 게이트웨이 API, 데스크톱 앱, 또는 직접 운영하는 서비스를 통해 Label 309 레코드를 게시하고 검증할 수 있습니다.

웹사이트를 한 번도 열지 않고도 CardanoWall을 사용할 수 있습니다. 동일한 존재 증명 레코드를 명령줄 도구, 애플리케이션 코드 속의 SDK, 게이트웨이 API, 데스크톱 앱, 또는 직접 운영하는 서비스에서 생성하고 게시하고 검증할 수 있습니다. 웹사이트는 개방형 표준인 Label 309 위에 놓인 하나의 프런트엔드일 뿐이며, 실제로 중요한 것은 그 표준입니다.

이 구분이 핵심입니다. 존재 증명은 한 번으로 끝나는 사람의 수작업인 경우는 많지 않습니다. 빌드 파이프라인, 컴플라이언스 절차, AI 출처 증명 시스템, 법적 증거 워크플로, 또는 다른 누군가가 만든 제품 안에 자리 잡습니다. 이 가운데 어느 것도 사람이 단일 웹 UI를 일일이 클릭해야만 하도록 만들어서는 안 됩니다.

웹사이트는 실제로 무엇을 합니까?

웹사이트는 존재 증명을 쉽게 다가갈 수 있도록 해 줍니다. 시각적 컴포저(작성 화면), 계정과 잔액 화면, 레코드 페이지, 신원 관리, 업로드 흐름, 안내형 게시 기능을 제공합니다. 대부분의 사람에게는 여기가 시작하기 좋은 곳입니다.

하지만 이것이 표준을 사용하는 유일한 방법이 되어서는 안 됩니다. 사람이 하나의 인터페이스를 클릭해 거쳐야만 작동하는 증명은 인프라가 될 수 없습니다. 기업에는 자동화가 필요합니다. 개발자에게는 API와 SDK가 필요합니다. 운영 팀과 보안 팀에는 반복 가능하고 스크립트로 작성할 수 있는 워크플로가 필요합니다. 어떤 사용자는 자신의 레코드와 파일을 자기 기기에 두고 싶어 합니다. 어떤 운영자는 전체 파이프라인을 직접 운영하고 싶어 합니다.

웹 앱은 정문입니다. 건물 전체가 아닙니다.

다른 사용 방법에는 무엇이 있습니까?

여러 가지가 있으며, 모두 동일한 산출물로 수렴합니다. 바로 Cardano에 고정되어 누구나 독립적으로 검증할 수 있는 표준 Label 309 레코드입니다.

  • CardanoWall 웹 앱;
  • 오픈 소스 cardanowall 명령줄 도구;
  • 애플리케이션 코드를 위한 공식 SDK(TypeScript, Python, Rust);
  • 계정별 토큰으로 접근하는 Label 309 게이트웨이 API;
  • 오픈 소스 로컬 우선 클라이언트인 CardanoWall Desktop;
  • 직접 셀프 호스팅하는 게이트웨이;
  • 게이트웨이 위에 직접 만든 제품.

인터페이스는 바뀔 수 있습니다. 증명 형식은 바뀌지 않습니다. 이 모든 코드는 github.com/cardanowall에서 오픈 소스로 공개되어 있으며, Apache-2.0 라이선스를, 명세 텍스트는 CC-BY-4.0 라이선스를 따릅니다.

게이트웨이 API는 언제 사용해야 합니까?

증명을 게시하거나 읽는 일이 수동 단계가 아니라 시스템의 일부가 되어야 할 때 API를 사용하십시오. 예를 들면 다음과 같습니다.

  • SaaS 제품이 고객 문서마다 증명을 생성하는 경우;
  • 빌드 파이프라인이 빌드할 때마다 릴리스 증거를 게시하는 경우;
  • AI 플랫폼이 생성된 출력물을 배치 단위로 고정하는 경우;
  • 컴플라이언스 시스템이 일일 통제 스냅샷을 게시하는 경우;
  • 워크플로가 특정 수신자를 위해 증거를 봉인하는 경우;
  • 내부 대시보드가 게시 상태와 계정 잔액을 읽는 경우;
  • 파트너 통합이 CardanoWall UI를 거치지 않고 레코드를 제출하는 경우.

API 경로를 통해 여러분의 소프트웨어가 게이트웨이를 직접 호출하면서도 고유한 사용자 경험은 그대로 유지할 수 있습니다. CardanoWall 자체의 웹 앱과 워커도 정확히 이 동일한 공개 엔드포인트를 통해 게이트웨이에 접근합니다. 별도의 비공개 출입구가 없으므로, 레퍼런스 제품이 할 수 있는 일은 여러분도 모두 할 수 있습니다. 이 부분을 더 깊이 살펴보려면 CardanoWall API 위에 구축하기를 참고하십시오.

API 토큰과 스코프는 어떻게 동작합니까?

게이트웨이는 두 종류의 자격 증명을 구분하며, 이 둘을 분리해 두는 것이 가장 중요하게 지켜야 할 점입니다.

계정 토큰은 여러분의 사용자 중 한 명으로서 동작합니다. 백엔드가 특정 계정에 대한 수명이 짧은 토큰을 발급하고, 호출은 그 토큰 아래에서 진행됩니다. 견적 요청, 콘텐츠 업로드, 게시, 해당 계정의 잔액 읽기가 이에 해당합니다. 스크립트, CI 작업, 통합에 들어가야 하는 것은 바로 이 토큰들과, 동일한 모델 위에 만들어진 API 키입니다. 이들은 의도적으로 좁게 설계되어 있습니다. 현재 스코프 집합은 작고 목적에 맞춰 만들어져 있습니다.

  • poe:create — 견적 요청, 콘텐츠 업로드, 레코드 게시;
  • poe:read — 레코드와 게시 상태 읽기;
  • inbox:read — 암호화된 받은편지함 동기화 북마크 읽기;
  • account:read — 계정 잔액 읽기.

이것이 프로그래밍 가능한 표면 전부이며, 의도적으로 스코프가 좁혀져 있습니다. 읽기 전용 대시보드 위젯에는 account:read만 있으면 됩니다. 게시 작업에는 poe:create가 필요합니다. 어느 쪽도 나머지 하나를 필요로 하지 않습니다. 서버에서 복호화하는 스코프는 의도적으로 존재하지 않습니다. 봉인과 봉인 해제는 클라이언트 측 작업이므로, 수신자의 개인 키는 결코 게이트웨이에 도달하지 않으며, 어떤 API 키도 서버가 여러분을 대신해 봉인된 콘텐츠를 읽도록 허가할 수 없습니다. 마찬가지로 CI 작업은, 로컬 서명이 여러분 자신의 설계와 통제 아래에서 의도적으로 포함된 경우가 아니라면, 사용자의 신원 시드(Identity Seed)를 결코 보유해서는 안 됩니다. 시드와 개인 키는 설계상 클라이언트에 머무르며, 게이트웨이가 보는 대상이 아닙니다.

운영자 자격 증명은 두 번째 종류이며, 이것은 API 키가 아닙니다. 이 자격 증명은 제어 플레인을 허가합니다. 즉, 계정을 프로비저닝하고, 여러분의 결제 시스템이 대금을 수금할 때 잔액을 조정하고, 마진을 설정하고, 앞서 언급한 계정 토큰을 발급하는 일을 허가합니다. 이 자격 증명은 신뢰할 수 있는 백엔드에만 존재해야 하며, 브라우저, 모바일 앱, 스크립트에는 결코 두어서는 안 됩니다. 유출된 계정 토큰은 수명이 짧은 골칫거리에 그쳐야 하지만, 유출된 운영자 자격 증명은 실제 보안 사고가 됩니다.

요령은 이렇습니다. 클라이언트에는 필요한 만큼 좁은 계정 스코프 토큰만 넘겨주고, 운영자 권한은 여러분 자신의 백엔드 뒤에 두십시오.

CLI는 언제 사용해야 합니까?

증명이 스크립트 안에 자리 잡아야 할 때 명령줄 도구를 사용하십시오. cardanowall 바이너리는 게이트웨이 비종속적이고 원시 시드를 우선하므로, 다음과 같은 경우에 자연스럽게 들어맞습니다.

  • 어떤 웹사이트도 열지 않고 로컬에서 레코드를 검증하는 경우;
  • 여러 파일에 대한 Merkle 증명을 빌드하고 확인하는 경우;
  • 레코드에 서명하는 경우;
  • 자동화에서 레코드를 제출하는 경우;
  • 터미널에서 받은편지함 동기화와 시험 복호화를 수행하는 경우.

CLI가 가장 중요한 이유는, 존재 증명을 산출물을 만들어 내는 시스템 가까이에 두기 때문입니다. 빌드 파이프라인은 출력물을 해시하고 릴리스의 일부로 레코드를 게시할 수 있습니다. 컴플라이언스 작업은 일일 매니페스트를 커밋할 수 있습니다. 로컬 사용자는 오프라인에서 레코드를 검증할 수 있습니다. 웹사이트는 사람에게 훌륭하고, CLI는 반복 가능한 작업에 훌륭합니다. 패턴과 예시는 자동화에서 CLI 사용하기를 참고하십시오.

SDK는 언제 사용해야 합니까?

Label 309가 여러분의 애플리케이션의 일부가 되어야 할 때 SDK를 사용하십시오. TypeScript, Python, Rust SDK는 레코드 구성, 콘텐츠 해시, 트랜잭션 검증, 호스트 외부 서명, 페이로드 봉인과 복호화, 시드에서 신원 도출, 그리고 모든 게이트웨이와의 통신을 돕습니다.

세 가지 SDK를 두는 목적은 편의가 아니라 상호 운용성입니다. 이들은 같은 정규 테스트 벡터로 검증된, 바이트 단위까지 동일한 쌍둥이입니다. 그래서 하나가 게시하거나 서명한 레코드는 나머지 SDK에서도 똑같이 검증됩니다. 이것이 개방형 표준이 서로 호환되지 않는 "호환" 형식으로 쪼개지는 대신 개방형 표준으로 남는 방식입니다. 짚어 둘 만한 유용한 속성이 하나 있습니다. 스탠드얼론 검증기는 트랜잭션 메타데이터, 선택적으로 콘텐츠 바이트, 그리고 공개 Cardano 탐색기만 있으면 되며, 발행자 서버가 신뢰 경로에 끼어들지 않습니다.

웹사이트 대신 Desktop은 언제 사용해야 합니까?

로컬 소유가 중요할 때 데스크톱 앱을 사용하십시오. CardanoWall Desktop은 Rust SDK 위에 Tauri와 Rust로 만들어진 오픈 소스 크로스 플랫폼 오프라인 우선 클라이언트이며, 메일 클라이언트처럼 동작합니다. 다음을 제공합니다.

  • 로컬에 저장되는 암호화된 신원 볼트;
  • 이미 동기화된 모든 항목에 대한 오프라인 접근;
  • 봉인된 받은편지함 탐색과 자기 기기에 캐시된 암호문;
  • 공개 레코드 인덱스에 대한 로컬 검색;
  • 다중 신원과 원하는 게이트웨이 제공자 선택.

웹사이트는 빠르고 편리한 상태를 유지하지만, 레코드와 신원과 캐시된 파일을 로컬에 두고 네트워크 없이도 계속 동작하게 하고 싶다면 데스크톱 앱이 더 나은 보금자리입니다. 많은 사람에게는 둘 다가 답이 될 것입니다. 설계에 대한 더 자세한 내용은 CardanoWall Desktop과 오프라인 증명에서 다룹니다.

게이트웨이는 언제 셀프 호스팅해야 합니까?

컴플라이언스, 비용 구조, 처리량, 데이터 처리 정책, 인프라 통제, 또는 제품 전략을 위해 게시 파이프라인을 직접 운영하고 싶다면 셀프 호스팅하십시오.

셀프 호스팅한 게이트웨이도 여전히 표준 Label 309 레코드를 게시합니다. 차이점은, 게시를 견적하고, 업로드하고, 제출하고, 확정하고, 색인하고, 회계 처리하는 서비스를 여러분이 직접 운영한다는 점입니다. 게이트웨이는 오픈 소스 Rust 단일 바이너리에 Postgres를 더한 것으로, 자체 Cardano 트랜잭션 빌더를 갖추고 있어 빌드하고, 제출하고, 확정하고, 체인 재구성(reorg)을 처리하며, 영구 실패 시 자동으로 환불합니다.

셀프 호스팅은 "공짜"가 아닙니다. 여전히 그 아래의 Cardano 및 Arweave 비용을 부담하며, 운영에 대한 책임도 떠안게 됩니다. 사라지는 것은 게시를 위해 호스팅된 CardanoWall 게이트웨이에 의존할 필요뿐입니다. 직접 게이트웨이 운영하기와 Label 309 게이트웨이란 무엇입니까?를 참고하십시오.

게이트웨이 위에 직접 제품을 만들 수 있습니까?

네. 그리고 바로 그 분리가 게이트웨이를 웹 앱과 구별되는 독자적인 계층으로 둔 이유입니다. Label 309 게이트웨이 위에 공증 제품, 증거 포털, 컴플라이언스 아카이브, 게시 도구, AI 출처 증명 서비스, 또는 내부 대시보드를 만들 수 있습니다.

게이트웨이는 기반 플레인을 소유합니다. 체인, 스토리지, 가격 책정, 공유 온체인 레코드 인덱스, 잔액, 게시 상태가 여기에 속합니다. 여러분의 제품은 벤더 플레인을 소유합니다. 사용자, 결제, UI, 워크플로, 알림, 지원, 그리고 레코드 위에 부여하는 제품 고유의 의미가 여기에 속합니다. 덕분에 모든 팀이 Cardano 트랜잭션 및 스토리지 운영자가 되지 않고도 훨씬 많은 제품이 하나의 증명 표준을 공유할 수 있습니다. 단계별 설명은 Label 309 게이트웨이 위에 구축하기에 있습니다.

CardanoWall 없이도 검증할 수 있습니까?

그것이 목표이며, 나머지가 존재하는 가장 강력한 이유입니다. 검증은 CardanoWall 웹사이트에 의존해서는 안 됩니다. 누구나 트랜잭션 메타데이터를 읽고, Label 309 레코드를 재구성하고, 그 구조를 검증하고, 레코드 서명을 확인하고, 콘텐츠 해시를 다시 계산하고, 올바른 키가 있다면 봉인된 레코드를 로컬에서 복호화할 수 있어야 합니다.

오직 하나의 웹사이트만 검증할 수 있는 증명은 약한 증명입니다. 개방형 SDK, 개방형 CLI, 개방형 명세야말로 Label 309 증명을, CardanoWall을 한 번도 거치지 않은 제삼자를 포함해 누구나 검증할 수 있게 만드는 것입니다. 직접 해 보고 싶다면 Label 309 레코드 검증하기부터 시작하십시오.

가격은 어떻게 됩니까?

인터페이스를 바꾼다고 해서 그 아래의 비용이 사라지지는 않습니다. 웹사이트, 데스크톱 앱, CLI, API, 또는 직접 만든 제품 중 무엇으로 게시하든, 누군가는 여전히 실제 Cardano 트랜잭션 수수료에 더해 파일이나 암호문에 사용된 스토리지 비용을 지불합니다. 호스팅된 게이트웨이는 운영, 자금 조달, 인프라, 지원을 충당하기 위해 그 위에 마진을 더하므로, 가격은 비용 전가에 그 마진을 더한 것입니다.

CardanoWall의 호스팅된 게이트웨이를 사용한다면 그 선불 잔액 및 가격 모델을 사용합니다. 셀프 호스팅한다면 자신의 게이트웨이를 직접 운영하고 자금을 조달합니다. 어느 쪽이든 표준은 레코드를 이식 가능하게 만들 뿐, 블록체인이나 스토리지를 공짜로 만들지는 않습니다. 그 근거는 게시에 가격이 붙는 이유에서 풀어 설명합니다.

한 가지 중요한 한계

Label 309 증명은 특정 바이트가 특정 공개 시점까지 존재했으며 그 이후로 바뀌지 않았음을 보여 줍니다. 다만 누가 콘텐츠를 작성했는지, 누가 소유하는지, 그것이 진실인지, 또는 누구에게 그에 대한 권리가 있는지를 증명하지는 않습니다. 봉인된 레코드는 평문을 의도된 키 보유자에게만 읽을 수 있도록 유지하지만, 익명성을 보장할 수는 없으며, 수신자가 일단 복호화한 뒤에 평문을 유출하는 것을 막을 수는 없습니다. 어떤 인터페이스에서 게시하든 이 경계를 염두에 두십시오.

요약

CardanoWall은 웹사이트만이 아닙니다. 웹사이트는 가장 쉬운 사람용 인터페이스이고, 게이트웨이는 게시 계층이며, CLI와 SDK는 개발자 표면이고, 데스크톱 앱은 로컬 오프라인 우선 클라이언트이며, 셀프 호스팅은 운영자 경로입니다. 이 모두는 동일한 결과물을 만들어 냅니다. 바로 그것을 생성한 인터페이스 바깥에서도 검증할 수 있는 표준 Label 309 레코드입니다.

작업에 맞는 인터페이스를 선택하십시오. 사람에게는 웹사이트를, 스크립트에는 CLI를, 제품에는 SDK를, 시스템에는 API를, 그리고 벤더 독립성이나 운영 통제가 필요할 때는 셀프 호스팅한 게이트웨이를 사용하십시오.

더 읽어보기

developersapigatewayself-hosting