본문으로 이동
Financial Context Wiki

상태 채널

상태 채널은 고정된 참여자들이 서명된 상태 업데이트를 오프체인에서 교환하면서 최신 유효 결과를 온체인에서 강제할 경로를 유지하게 합니다.

업데이트

교육 목적으로만 제공되며 투자 또는 보안 조언이 아닙니다. 키, 최신 상태 데이터, 모니터링 또는 온체인 대응 제출 능력을 이용할 수 없으면 채널 자금을 잃을 수 있습니다.

직접 답변

상태 채널은 고정된 참여자 집합이 블록체인에 자산을 잠그거나 강제 가능한 규칙을 설정한 뒤, 인증된 상태 업데이트를 오프체인에서 교환하는 프로토콜입니다. 블록체인은 모든 업데이트를 처리하지 않고, 채널을 닫거나 의견이 엇갈릴 때 최종 판정자 역할을 합니다.

승인된 각 업데이트는 특정 채널, 애플리케이션 상태 또는 배분, 그리고 단조 증가하는 턴 번호나 nonce 같은 순서 값에 커밋됩니다. 채널 규칙에 따라 더 새로운 유효 상태가 이전 상태를 대체합니다. 결제 채널은 주로 잔액을 추적하는 좁은 유형이고, 범용 상태 채널은 게임 수, 거래 또는 기타 결정론적 애플리케이션 데이터도 표현할 수 있습니다.

상태 채널은 짧은 지연 시간, 공개 거래 이력으로부터의 일정한 프라이버시, 일반 업데이트마다 기본 계층 수수료가 들지 않는다는 장점이 있습니다. 그러나 보통 세션 동안 참여자와 자본이 고정되고, 모두가 최신 상태를 강제할 증거를 보관해야 하며, 분쟁 시 기본 체인이 사용 가능하고 비용을 감당할 수 있어야 합니다.

작동 방식

  1. 개설 및 자금 예치. 참여자는 신원, 애플리케이션 규칙, 도전 기간, 초기 배분에 합의하고 온체인 판정 계약에 자금을 잠그거나 이미 예치된 채널에서 새 채널을 파생합니다. 예치금은 채널을 담보하는 동안 일반 지갑 잔액처럼 쓸 수 없습니다.
  2. 서명된 상태 교환. 다음 유효 상태를 계산하고 이를 뒷받침하는 서명 또는 프로토콜 메시지를 교환합니다. 상태를 고유 채널 식별자와 증가하는 순서 값에 묶어 다른 채널이나 이전 라운드의 서명이 조용히 대체되지 못하게 합니다.
  3. 강제 집행 자료 보관. 지갑이나 노드는 최신 지원 상태, 서명, 보류 중인 조건부 전송, 프로토콜이 요구하는 폐기 정보나 비밀 자료를 저장합니다. 시드 문구가 키를 복구해도 계속 변하는 오프체인 데이터까지 복구하는 것은 아닙니다.
  4. 오프체인으로 계속. 기본 계층 거래 없이 많은 업데이트가 가능하지만 전송은 용량 제한을 받습니다. 한 방향으로 보낼 수 있는 금액은 현재 배분과 프로토콜 준비금 범위 이내입니다. 여러 결제 채널을 경유하면 각 홉에서 유동성과 가동성 의존성이 늘어납니다.
  5. 가능하면 협력 종료. 참여자들이 최종 결과에 서명하고 프로토콜이 요구하는 최소 온체인 거래를 제출합니다. 협력 종료는 보통 도전 경쟁을 피하며 일방 종료보다 빠르거나 저렴합니다.
  6. 분쟁을 온체인으로 확대. 참여자가 사라지거나 오래된 상태를 제시하면 다른 참여자가 강제 가능한 증거를 냅니다. 판정 계약은 순서, 시간 초과, 전환 규칙을 적용합니다. 새 상태로 옛 상태에 이의를 제기하는 설계도 있고, Lightning 방식처럼 일반적인 최고 nonce 경쟁 대신 커밋먼트와 폐기 규칙을 쓰는 설계도 있습니다.
  7. 기한 후 확정. 관련 도전 기간이나 타임록이 끝나면 결과를 청구합니다. 모든 출력이 해결될 때까지 소프트웨어는 체인을 감시하고 재구성에 대응하며 시간 민감 거래의 수수료를 높여야 할 수 있습니다.

예시

Alice와 Bob이 각각 5 ETH로 단순한 양자 결제 채널을 열면 채널은 10 ETH를 관리합니다. 공동 서명한 개설 상태는 턴 0이며, 결제 시 Alice는 5 ETH, Bob은 5 ETH를 받습니다.

Alice가 Bob에게 1 ETH를 지급하고 둘은 전환을 검증해 턴 1에 서명합니다. Alice에게 4 ETH, Bob에게 6 ETH가 배분됩니다. 이후 Bob이 Alice에게 2 ETH를 지급하면 턴 2는 Alice에게 6 ETH, Bob에게 4 ETH를 배분합니다. 협력 운용 중 기본 체인에 올라갈 필요가 있는 것은 자금 예치와 최종 결제뿐입니다.

나중에 Bob이 턴 1을 제출했다고 가정합니다. 최고 턴을 기준으로 판정하는 설계에서 Alice는 도전 기한 전에 완전한 지지를 받은 턴 2를 제시해야 합니다. 성공하면 계약은 오래된 결과를 거부하고 턴 2로 결제합니다. 그러나 턴 2를 잃었거나 서명 키를 쓸 수 없거나 수수료용 기본 자산이 없거나 기한을 넘겨 오프라인이라면 프로토콜은 비공개 이력을 추론할 수 없습니다. 따라서 강제되는 결과가 실제 최신 합의와 다를 수 있습니다.

이 예시는 개념 설명용입니다. 실제 프로토콜은 상태를 지지하는 서명, 유효한 전환, 조건부 지급 해결, 온체인 호출과 기한을 정확히 정의합니다. 이 단순 계산만 믿고 자금을 이전하지 마십시오.

위험과 통제

  • 오래된 상태로 결제. 최신의 완전한 강제 자료를 보관하고 복원을 시험합니다. 호환 워치타워가 받는 데이터와 권한을 이해한 후 사용합니다.
  • 도전 기간 누락. 모든 출력이 확정될 때까지 올바른 체인을 감시합니다. 장애, 재구성, 혼잡, 사람의 대응 시간을 현실적으로 반영합니다.
  • 수수료와 혼잡 위험. 잠기지 않은 기본 자산과 수수료 인상 수단을 유지합니다. 동시 분쟁은 긴급한 탈출 시점에 시스템을 비싸게 만들 수 있습니다.
  • 키 또는 상태 데이터 손실. 구현 문서의 방식대로 상태를 백업합니다. 프로토콜이 안전하다고 명시하지 않는 한 가동 중인 채널을 오래된 스냅샷에서 복구하지 않습니다.
  • 용량과 라우팅 실패. 입출금 유동성, 준비금, 조건부 전송 상한, 만료 여유, 모든 중개자를 확인합니다. 지갑 총액은 사용 가능한 채널 용량이 아닙니다.
  • 상대방과 가동성 위험. 상대방은 올바르게 보호된 결과를 보통 바꿀 수 없지만 업데이트나 협력 종료를 거부해 느린 분쟁 경로를 강제할 수 있습니다.
  • 구현 위험. 클라이언트, 판정 계약, 서명 도메인, 전환 로직, 업그레이드 통제의 버그가 보장을 무너뜨릴 수 있습니다. 실제 배포와 감사를 검증합니다.
  • 프라이버시 유출. 오프체인 업데이트가 자동으로 익명인 것은 아닙니다. 피어, 라우터, 관찰자, 백업, 최종 분쟁 거래가 관계나 데이터를 드러낼 수 있습니다.

흔한 오해

  • “오프체인은 블록체인 없이도 무신뢰다.” 상대방 신뢰를 제한하는 것은 신뢰할 수 있는 온체인 강제 경로이며 그 보안, 가용성, 수수료는 여전히 중요합니다.
  • “양쪽이 서명한 상태는 무엇이든 결제된다.” 강제할 증거는 프로토콜별 순서, 유효성, 최종성, 폐기, 시간 초과 규칙이 정합니다.
  • “시드 문구로 채널 전체를 복구한다.” 보통 키만 복구하며 최신 상태, 폐기 비밀, 보류 전송, 피어 DB는 복구되지 않을 수 있습니다.
  • “사용자는 무기한 오프라인이어도 된다.” 많은 설계는 직접 또는 위임 감시 서비스를 통해 제한된 기간 안에 관찰하고 대응해야 합니다.
  • “채널 용량은 지갑 잔액과 같다.” 자금을 채널에 커밋해야 하며 사용 용량은 방향, 준비금, 보류 전송, 라우팅 유동성에 좌우됩니다.
  • “상태 채널은 Rollup을 전부 대체한다.” 알려진 참여자 간 반복 상호작용에 가장 적합합니다. 공개 참여, 전역 공유 상태, 폭넓은 조합성이 필요하면 Rollup이나 일반 온체인 실행이 더 적합할 수 있습니다.

관련 주제

출처

탐색

위키 검색...