본문으로 건너뛰기
Change page

상태 채널

상태 채널을 사용하면 참가자가 이더리움 메인넷과의 상호작용을 최소화하면서 오프체인에서 안전하게 트랜잭션을 수행할 수 있습니다. 채널 피어는 채널을 열고 닫기 위해 단 두 번의 온체인 트랜잭션만 제출하면서 임의의 횟수만큼 오프체인 트랜잭션을 수행할 수 있습니다. 이를 통해 트랜잭션 처리량을 극도로 높이고 사용자의 비용을 낮출 수 있습니다.

전제 조건

이더리움 확장성 및 레이어 2 (l2)에 대한 페이지를 읽고 이해해야 합니다.

채널이란 무엇인가요?

이더리움과 같은 퍼블릭 블록체인은 분산된 아키텍처로 인해 확장성 문제에 직면합니다. 온체인 트랜잭션은 모든 노드에서 실행되어야 하기 때문입니다. 노드는 네트워크를 탈중앙화된 상태로 유지하기 위해 트랜잭션 처리량에 제한을 두면서, 적당한 하드웨어를 사용하여 블록 내 트랜잭션 볼륨을 처리할 수 있어야 합니다. 블록체인 채널은 사용자가 오프체인에서 상호작용하면서도 최종 정산을 위해 메인 체인의 보안에 의존할 수 있도록 하여 이 문제를 해결합니다.

채널은 두 당사자가 서로 간에 많은 트랜잭션을 수행한 다음 최종 결과만 블록체인에 게시할 수 있도록 하는 간단한 피어 투 피어 프로토콜입니다. 채널은 암호학을 사용하여 생성된 요약 데이터가 유효한 중간 트랜잭션 세트의 결과임을 증명합니다. "다중서명" 스마트 컨트랙트는 트랜잭션이 올바른 당사자에 의해 서명되었음을 보장합니다.

채널을 사용하면 상태 변경이 이해관계자에 의해 실행되고 검증되므로 이더리움의 실행 계층에서의 연산이 최소화됩니다. 이는 이더리움의 혼잡을 줄이고 사용자의 트랜잭션 처리 속도를 높입니다.

각 채널은 이더리움에서 실행되는 다중서명 스마트 컨트랙트에 의해 관리됩니다. 채널을 열기 위해 참가자는 채널 컨트랙트를 온체인에 배포하고 자금을 예치합니다. 양 당사자는 채널의 상태를 초기화하기 위해 상태 업데이트에 공동으로 서명하며, 이후 오프체인에서 빠르고 자유롭게 트랜잭션을 수행할 수 있습니다.

채널을 닫기 위해 참가자는 합의된 채널의 마지막 상태를 온체인에 제출합니다. 그 후 스마트 컨트랙트는 채널의 최종 상태에 있는 각 참가자의 잔액에 따라 잠긴 자금을 분배합니다.

피어 투 피어 채널은 미리 정의된 일부 참가자가 눈에 띄는 오버헤드 없이 높은 빈도로 트랜잭션을 수행하고자 하는 상황에 특히 유용합니다. 블록체인 채널은 지불 채널(payment channels)과 상태 채널(state channels)의 두 가지 범주로 나뉩니다.

지불 채널

지불 채널은 두 사용자가 공동으로 유지 관리하는 "양방향 원장"으로 가장 잘 설명할 수 있습니다. 원장의 초기 잔액은 채널 개설 단계에서 온체인 컨트랙트에 잠긴 예치금의 합계입니다. 지불 채널 전송은 초기 일회성 온체인 생성 및 최종적인 채널 종료를 제외하고는 실제 블록체인 자체의 개입 없이 즉각적으로 수행될 수 있습니다.

원장 잔액(즉, 지불 채널의 상태)에 대한 업데이트는 채널 내 모든 당사자의 승인이 필요합니다. 모든 채널 참가자가 서명한 채널 업데이트는 이더리움의 트랜잭션과 마찬가지로 완결된 것으로 간주됩니다.

지불 채널은 단순한 사용자 상호작용(예: ETH 전송, 아토믹 스왑, 소액 결제)의 값비싼 온체인 활동을 최소화하도록 설계된 초기 확장성 솔루션 중 하나였습니다. 채널 참가자는 전송의 순 합계가 예치된 토큰을 초과하지 않는 한 서로 간에 무제한의 즉각적이고 수수료 없는 트랜잭션을 수행할 수 있습니다.

상태 채널

오프체인 지불을 지원하는 것 외에, 지불 채널은 일반적인 상태 전환 로직을 처리하는 데 유용하지 않은 것으로 입증되었습니다. 상태 채널은 이 문제를 해결하고 범용 연산을 확장하는 데 채널을 유용하게 만들기 위해 만들어졌습니다.

상태 채널은 여전히 지불 채널과 많은 공통점을 가지고 있습니다. 예를 들어, 사용자는 암호학적으로 서명된 메시지(트랜잭션)를 교환하여 상호작용하며, 다른 채널 참가자도 이에 서명해야 합니다. 제안된 상태 업데이트가 모든 참가자에 의해 서명되지 않으면 유효하지 않은 것으로 간주됩니다.

그러나 채널은 사용자의 잔액을 보유하는 것 외에도 컨트랙트 스토리지의 현재 상태(즉, 컨트랙트 변수의 값)도 추적합니다.

이를 통해 두 사용자 간에 스마트 컨트랙트를 오프체인에서 실행할 수 있습니다. 이 시나리오에서 스마트 컨트랙트의 내부 상태 업데이트는 채널을 생성한 피어의 승인만 필요합니다.

이것은 앞서 설명한 확장성 문제를 해결하지만, 보안에 영향을 미칩니다. 이더리움에서 상태 전환의 유효성은 네트워크의 합의 프로토콜에 의해 강제됩니다. 이로 인해 스마트 컨트랙트의 상태에 대한 유효하지 않은 업데이트를 제안하거나 스마트 컨트랙트 실행을 변경하는 것이 불가능해집니다.

상태 채널은 동일한 보안 보장을 갖지 않습니다. 어느 정도 상태 채널은 메인넷의 축소판입니다. 제한된 수의 참가자가 규칙을 강제하므로 악의적인 행동(예: 유효하지 않은 상태 업데이트 제안)의 가능성이 커집니다. 상태 채널은 에 기반한 분쟁 중재 시스템에서 보안을 도출합니다.

상태 채널의 작동 방식

기본적으로 상태 채널에서의 활동은 사용자와 블록체인 시스템이 관련된 상호작용 세션입니다. 사용자는 주로 오프체인에서 서로 통신하며, 채널을 열거나 닫거나 참가자 간의 잠재적인 분쟁을 해결하기 위해서만 기본 블록체인과 상호작용합니다.

다음 섹션에서는 상태 채널의 기본 워크플로를 간략하게 설명합니다.

채널 열기

채널을 열려면 참가자가 메인넷의 스마트 컨트랙트에 자금을 약정해야 합니다. 예치금은 가상의 외상 장부 역할도 하므로, 참여하는 행위자는 즉시 결제를 정산할 필요 없이 자유롭게 트랜잭션을 수행할 수 있습니다. 채널이 온체인에서 완결된 경우에만 당사자들은 서로 정산하고 장부에 남은 금액을 인출합니다.

이 예치금은 각 참가자의 정직한 행동을 보장하는 보증금 역할도 합니다. 분쟁 해결 단계에서 예치자가 악의적인 행동을 한 것으로 판명되면 컨트랙트는 그들의 예치금을 삭감(slash)합니다.

채널 피어는 모두가 동의하는 초기 상태에 서명해야 합니다. 이것은 상태 채널의 제네시스 역할을 하며, 이후 사용자는 트랜잭션을 시작할 수 있습니다.

채널 사용

채널의 상태를 초기화한 후, 피어는 트랜잭션에 서명하고 승인을 위해 서로에게 전송하여 상호작용합니다. 참가자는 이러한 트랜잭션으로 상태 업데이트를 시작하고 다른 사람의 상태 업데이트에 서명합니다. 각 트랜잭션은 다음으로 구성됩니다.

  • 트랜잭션의 고유 ID 역할을 하고 재생 공격을 방지하는 논스. 또한 상태 업데이트가 발생한 순서를 식별합니다(이는 분쟁 해결에 중요합니다).

  • 채널의 이전 상태

  • 채널의 새로운 상태

  • 상태 전환을 트리거하는 트랜잭션(예: 앨리스가 밥에게 5 ETH를 보냄)

채널의 상태 업데이트는 사용자가 메인넷에서 상호작용할 때 일반적으로 발생하는 것처럼 온체인에 브로드캐스트되지 않으며, 이는 온체인 공간 차지를 최소화하려는 상태 채널의 목표와 일치합니다. 참가자가 상태 업데이트에 동의하는 한, 이는 이더리움 트랜잭션만큼이나 완결성을 갖습니다. 참가자는 분쟁이 발생할 경우에만 메인넷의 합의에 의존하면 됩니다.

채널 닫기

상태 채널을 닫으려면 합의된 채널의 최종 상태를 온체인 스마트 컨트랙트에 제출해야 합니다. 상태 업데이트에서 참조되는 세부 정보에는 각 참가자의 이동 횟수와 승인된 트랜잭션 목록이 포함됩니다.

상태 업데이트가 유효한지(즉, 모든 당사자가 서명했는지) 확인한 후, 스마트 컨트랙트는 채널을 완결하고 채널의 결과에 따라 잠긴 자금을 분배합니다. 오프체인에서 이루어진 지불은 이더리움의 상태에 적용되며 각 참가자는 잠긴 자금 중 남은 몫을 받습니다.

위에서 설명한 시나리오는 이상적인 경우(happy case)에 일어나는 일을 나타냅니다. 때로는 사용자가 합의에 도달하지 못하고 채널을 완결하지 못할 수도 있습니다(sad case). 다음 중 하나가 이 상황에 해당할 수 있습니다.

  • 참가자가 오프라인 상태가 되어 상태 전환을 제안하지 못함

  • 참가자가 유효한 상태 업데이트에 공동 서명하기를 거부함

  • 참가자가 온체인 컨트랙트에 이전 상태 업데이트를 제안하여 채널을 완결하려고 시도함

  • 참가자가 다른 사람이 서명하도록 유효하지 않은 상태 전환을 제안함

채널에 참여하는 행위자 간에 합의가 결렬될 때마다, 마지막 옵션은 메인넷의 합의에 의존하여 채널의 최종적이고 유효한 상태를 강제하는 것입니다. 이 경우 상태 채널을 닫으려면 온체인에서 분쟁을 해결해야 합니다.

분쟁 해결

일반적으로 채널의 당사자들은 사전에 채널을 닫는 데 동의하고 마지막 상태 전환에 공동 서명하여 스마트 컨트랙트에 제출합니다. 업데이트가 온체인에서 승인되면 오프체인 스마트 컨트랙트의 실행이 종료되고 참가자는 자금을 가지고 채널을 종료합니다.

그러나 한 당사자는 상대방의 승인을 기다리지 않고 스마트 컨트랙트의 실행을 종료하고 채널을 완결하라는 온체인 요청을 제출할 수 있습니다. 앞서 설명한 합의 결렬 상황이 발생하면 어느 당사자든 온체인 컨트랙트를 트리거하여 채널을 닫고 자금을 분배할 수 있습니다. 이는 무신뢰성을 제공하여 정직한 당사자가 상대방의 행동과 관계없이 언제든지 예치금을 가지고 종료할 수 있도록 보장합니다.

채널 종료를 처리하려면 사용자는 애플리케이션의 마지막 유효한 상태 업데이트를 온체인 컨트랙트에 제출해야 합니다. 이것이 확인되면(즉, 모든 당사자의 서명이 포함되어 있으면) 자금이 그들에게 유리하게 재분배됩니다.

그러나 단일 사용자 종료 요청을 실행하는 데는 지연이 있습니다. 채널 종료 요청이 만장일치로 승인된 경우 온체인 종료 트랜잭션은 즉시 실행됩니다.

사기 행위의 가능성 때문에 단일 사용자 종료 시 지연이 발생합니다. 예를 들어, 채널 참가자가 온체인에 이전 상태 업데이트를 제출하여 이더리움에서 채널을 완결하려고 시도할 수 있습니다.

이에 대한 대응책으로, 상태 채널은 정직한 사용자가 채널의 최신 유효 상태를 온체인에 제출하여 유효하지 않은 상태 업데이트에 이의를 제기할 수 있도록 합니다. 상태 채널은 합의된 최신 상태 업데이트가 이전 상태 업데이트보다 우선하도록 설계되었습니다.

피어가 온체인 분쟁 해결 시스템을 트리거하면 상대방은 제한 시간(이의 제기 기간, challenge window) 내에 응답해야 합니다. 이를 통해 사용자는 특히 상대방이 오래된 업데이트를 적용하는 경우 종료 트랜잭션에 이의를 제기할 수 있습니다.

어떤 경우이든 채널 사용자는 항상 강력한 완결성 보장을 갖습니다. 그들이 소유한 상태 전환이 모든 구성원에 의해 서명되었고 가장 최근의 업데이트라면, 일반적인 온체인 트랜잭션과 동일한 완결성을 갖습니다. 그들은 여전히 온체인에서 상대방에게 이의를 제기해야 하지만, 가능한 유일한 결과는 그들이 보유한 마지막 유효한 상태를 완결하는 것입니다.

상태 채널은 이더리움과 어떻게 상호작용하나요?

상태 채널은 오프체인 프로토콜로 존재하지만, 채널을 열 때 이더리움에 배포되는 스마트 컨트랙트라는 온체인 구성 요소를 가지고 있습니다. 이 컨트랙트는 채널에 예치된 자산을 제어하고, 상태 업데이트를 검증하며, 참가자 간의 분쟁을 중재합니다.

상태 채널은 레이어 2 (l2) 확장성 솔루션과 달리 트랜잭션 데이터나 상태 약정(state commitments)을 메인넷에 게시하지 않습니다. 그러나 사이드체인과 같은 것보다 메인넷에 더 많이 연결되어 있어 다소 더 안전합니다.

상태 채널은 다음 사항에 대해 메인 이더리움 프로토콜에 의존합니다.

1. Liveness

채널을 열 때 배포된 온체인 컨트랙트는 채널의 기능을 담당합니다. 컨트랙트가 이더리움에서 실행 중이라면 채널은 항상 사용할 수 있습니다. 반대로 사이드체인은 메인넷이 작동 중이더라도 언제든지 실패할 수 있어 사용자 자금을 위험에 빠뜨릴 수 있습니다.

2. Security

어느 정도 상태 채널은 보안을 제공하고 악의적인 피어로부터 사용자를 보호하기 위해 이더리움에 의존합니다. 이후 섹션에서 논의하겠지만, 채널은 사용자가 유효하지 않거나 오래된 업데이트로 채널을 완결하려는 시도에 이의를 제기할 수 있는 사기 증명 메커니즘을 사용합니다.

이 경우 정직한 당사자는 검증을 위해 온체인 컨트랙트에 사기 증명으로서 채널의 최신 유효 상태를 제공합니다. 사기 증명은 서로 불신하는 당사자들이 그 과정에서 자금을 위험에 빠뜨리지 않고 오프체인 트랜잭션을 수행할 수 있게 해줍니다.

3. Finality

채널 사용자가 공동으로 서명한 상태 업데이트는 온체인 트랜잭션만큼이나 유효한 것으로 간주됩니다. 그럼에도 불구하고 채널 내의 모든 활동은 채널이 이더리움에서 닫힐 때만 진정한 완결성을 달성합니다.

낙관적인 경우, 양 당사자는 협력하여 최종 상태 업데이트에 서명하고 온체인에 제출하여 채널을 닫을 수 있으며, 그 후 자금은 채널의 최종 상태에 따라 분배됩니다. 누군가 온체인에 잘못된 상태 업데이트를 게시하여 속이려고 시도하는 비관적인 경우, 그들의 트랜잭션은 이의 제기 기간이 경과할 때까지 완결되지 않습니다.

가상 상태 채널

상태 채널의 단순한 구현은 두 사용자가 오프체인에서 애플리케이션을 실행하고자 할 때 새로운 컨트랙트를 배포하는 것일 것입니다. 이는 실현 불가능할 뿐만 아니라 상태 채널의 비용 효율성을 무효화합니다(온체인 트랜잭션 비용이 빠르게 누적될 수 있음).

이 문제를 해결하기 위해 "가상 채널(virtual channels)"이 만들어졌습니다. 열고 종료하기 위해 온체인 트랜잭션이 필요한 일반 채널과 달리, 가상 채널은 메인 체인과 상호작용하지 않고도 열고, 실행하고, 완결할 수 있습니다. 이 방법을 사용하면 오프체인에서 분쟁을 해결하는 것도 가능합니다.

이 시스템은 온체인에서 자금이 조달된 이른바 "원장 채널(ledger channels)"의 존재에 의존합니다. 두 당사자 간의 가상 채널은 기존 원장 채널 위에 구축될 수 있으며, 원장 채널의 소유자가 중개자 역할을 합니다.

각 가상 채널의 사용자는 새로운 컨트랙트 인스턴스를 통해 상호작용하며, 원장 채널은 여러 컨트랙트 인스턴스를 지원할 수 있습니다. 원장 채널의 상태에는 둘 이상의 컨트랙트 스토리지 상태도 포함되어 있어, 서로 다른 사용자 간에 오프체인에서 애플리케이션을 병렬로 실행할 수 있습니다.

일반 채널과 마찬가지로 사용자는 상태 머신을 진행시키기 위해 상태 업데이트를 교환합니다. 분쟁이 발생하지 않는 한, 중개자는 채널을 열거나 종료할 때만 연락하면 됩니다.

가상 지불 채널

가상 지불 채널은 가상 상태 채널과 동일한 아이디어로 작동합니다. 동일한 네트워크에 연결된 참가자는 온체인에 새 채널을 열 필요 없이 메시지를 전달할 수 있습니다. 가상 지불 채널에서 가치 전송은 하나 이상의 중개자를 통해 라우팅되며, 의도된 수신자만이 전송된 자금을 받을 수 있다는 보장이 있습니다.

상태 채널의 활용

지불

초기 블록체인 채널은 두 참가자가 메인넷에서 높은 트랜잭션 수수료를 지불하지 않고도 오프체인에서 빠르고 수수료가 낮은 전송을 수행할 수 있도록 하는 간단한 프로토콜이었습니다. 오늘날 지불 채널은 이더와 토큰의 교환 및 예치를 위해 설계된 애플리케이션에 여전히 유용합니다.

채널 기반 지불은 다음과 같은 장점이 있습니다.

  1. 처리량: 채널당 오프체인 트랜잭션의 양은 다양한 요인, 특히 블록 크기와 블록 타임의 영향을 받는 이더리움의 처리량과 무관합니다. 트랜잭션을 오프체인에서 실행함으로써 블록체인 채널은 더 높은 처리량을 달성할 수 있습니다.

  2. 프라이버시: 채널은 오프체인에 존재하기 때문에 참가자 간의 상호작용 세부 정보는 이더리움의 퍼블릭 블록체인에 기록되지 않습니다. 채널 사용자는 채널에 자금을 조달하고 닫거나 분쟁을 해결할 때만 온체인에서 상호작용하면 됩니다. 따라서 채널은 더 프라이빗한 트랜잭션을 원하는 개인에게 유용합니다.

  3. 지연 시간: 채널 참가자 간에 수행되는 오프체인 트랜잭션은 양 당사자가 협력할 경우 즉시 정산될 수 있어 지연이 줄어듭니다. 대조적으로, 메인넷에서 트랜잭션을 보내려면 노드가 트랜잭션을 처리하고, 트랜잭션이 포함된 새 블록을 생성하고, 합의에 도달할 때까지 기다려야 합니다. 사용자는 트랜잭션이 완결된 것으로 간주하기 전에 더 많은 블록 확인을 기다려야 할 수도 있습니다.

  4. 비용: 상태 채널은 일련의 참가자가 장기간에 걸쳐 많은 상태 업데이트를 교환하는 상황에서 특히 유용합니다. 발생하는 유일한 비용은 상태 채널 스마트 컨트랙트를 열고 닫는 것뿐입니다. 채널을 열고 닫는 사이의 모든 상태 변경은 정산 비용이 그에 따라 분산되므로 이전보다 저렴해집니다.

롤업과 같은 레이어 2 (l2) 솔루션에 상태 채널을 구현하면 지불에 있어 더욱 매력적일 수 있습니다. 채널은 저렴한 지불을 제공하지만, 개설 단계에서 메인넷에 온체인 컨트랙트를 설정하는 비용은 특히 가스 수수료가 급등할 때 비싸질 수 있습니다. 이더리움 기반 롤업은 더 낮은 트랜잭션 수수료 (opens in a new tab)를 제공하며 설정 수수료를 낮춤으로써 채널 참가자의 오버헤드를 줄일 수 있습니다.

소액 결제

소액 결제(Microtransactions)는 기업이 손실을 보지 않고는 처리할 수 없는 소액 지불(예: 1달러 미만)입니다. 이러한 주체는 지불 서비스 제공업체에 비용을 지불해야 하는데, 고객 지불에 대한 마진이 너무 낮아 수익을 낼 수 없다면 그렇게 할 수 없습니다.

지불 채널은 소액 결제와 관련된 오버헤드를 줄임으로써 이 문제를 해결합니다. 예를 들어, 인터넷 서비스 제공업체(ISP)는 고객과 지불 채널을 열어 고객이 서비스를 사용할 때마다 소액의 지불을 스트리밍하도록 할 수 있습니다.

채널을 열고 닫는 비용 외에 참가자는 소액 결제에 대해 추가 비용(가스 수수료 없음)을 부담하지 않습니다. 이는 고객이 서비스에 지불하는 금액에 대해 더 많은 유연성을 갖고 기업이 수익성 있는 소액 결제를 놓치지 않기 때문에 윈윈(win-win) 상황입니다.

탈중앙화 애플리케이션

지불 채널과 마찬가지로 상태 채널은 상태 머신의 최종 상태에 따라 조건부 지불을 할 수 있습니다. 상태 채널은 임의의 상태 전환 로직도 지원할 수 있어 일반적인 앱을 오프체인에서 실행하는 데 유용합니다.

상태 채널은 종종 단순한 턴 기반 애플리케이션으로 제한되는데, 이는 온체인 컨트랙트에 약정된 자금을 관리하기 더 쉽기 때문입니다. 또한 제한된 수의 당사자가 간격을 두고 오프체인 애플리케이션의 상태를 업데이트하므로 부정직한 행동을 처벌하는 것이 비교적 간단합니다.

상태 채널 애플리케이션의 효율성은 그 설계에 따라 달라집니다. 예를 들어, 개발자는 앱 채널 컨트랙트를 온체인에 한 번 배포하고 다른 플레이어가 온체인으로 이동할 필요 없이 앱을 재사용하도록 허용할 수 있습니다. 이 경우 초기 앱 채널은 여러 가상 채널을 지원하는 원장 채널 역할을 하며, 각 가상 채널은 오프체인에서 앱의 스마트 컨트랙트의 새 인스턴스를 실행합니다.

상태 채널 애플리케이션의 잠재적인 사용 사례는 게임 결과에 따라 자금이 분배되는 간단한 2인용 게임입니다. 여기서의 이점은 플레이어가 서로를 신뢰할 필요가 없으며(무신뢰성), 플레이어가 아닌 온체인 컨트랙트가 자금 할당 및 분쟁 해결을 제어한다는 것입니다(탈중앙화).

상태 채널 앱의 다른 가능한 사용 사례로는 ENS 이름 소유권, NFT 원장 등이 있습니다.

아토믹 전송

초기 지불 채널은 두 당사자 간의 전송으로 제한되어 사용성이 제한되었습니다. 그러나 가상 채널의 도입으로 개인은 온체인에 새 채널을 열 필요 없이 중개자(즉, 여러 p2p 채널)를 통해 전송을 라우팅할 수 있게 되었습니다.

일반적으로 "멀티 홉 전송(multi-hop transfers)"으로 설명되는 라우팅된 지불은 아토믹(atomic)합니다(즉, 트랜잭션의 모든 부분이 성공하거나 완전히 실패함). 아토믹 전송은 특정 조건이 충족될 때만 지불이 해제되도록 보장하기 위해 해시 타임락 컨트랙트(HTLC) (opens in a new tab)를 사용하여 거래 상대방 위험을 줄입니다.

상태 채널 사용의 단점

Liveness assumptions

효율성을 보장하기 위해 상태 채널은 채널 참가자가 분쟁에 응답할 수 있는 시간에 제한을 둡니다. 이 규칙은 피어가 항상 온라인 상태여서 채널 활동을 모니터링하고 필요할 때 이의 제기에 대응할 것이라고 가정합니다.

실제로 사용자는 통제할 수 없는 이유(예: 인터넷 연결 불량, 기계적 결함 등)로 오프라인 상태가 될 수 있습니다. 정직한 사용자가 오프라인 상태가 되면 악의적인 피어는 판정 컨트랙트에 오래된 중간 상태를 제시하고 약정된 자금을 훔쳐 상황을 악용할 수 있습니다.

일부 채널은 다른 사람을 대신하여 온체인 분쟁 이벤트를 감시하고 관련 당사자에게 경고하는 등 필요한 조치를 취하는 주체인 "감시탑(watchtowers)"을 사용합니다. 그러나 이는 상태 채널 사용 비용을 증가시킬 수 있습니다.

Data unavailability

앞서 설명했듯이 유효하지 않은 분쟁에 이의 제기하려면 상태 채널의 최신 유효 상태를 제시해야 합니다. 이것은 사용자가 채널의 최신 상태에 접근할 수 있다는 가정에 기반한 또 다른 규칙입니다.

채널 사용자가 오프체인 애플리케이션 상태의 사본을 저장할 것으로 기대하는 것은 합리적이지만, 이 데이터는 오류나 기계적 결함으로 인해 손실될 수 있습니다. 사용자가 데이터를 백업하지 않은 경우, 상대방이 소유한 이전 상태 전환을 사용하여 유효하지 않은 종료 요청을 완결하지 않기만을 바랄 수밖에 없습니다.

이더리움 사용자는 네트워크가 데이터 가용성에 대한 규칙을 강제하기 때문에 이 문제를 다룰 필요가 없습니다. 트랜잭션 데이터는 모든 노드에 의해 저장 및 전파되며 필요할 때 사용자가 다운로드할 수 있습니다.

Liquidity issues

블록체인 채널을 설정하려면 참가자는 채널의 수명 주기 동안 온체인 스마트 컨트랙트에 자금을 잠가야 합니다. 이는 채널 사용자의 유동성을 감소시키며, 메인넷에 자금을 잠가둘 여유가 있는 사람으로 채널을 제한합니다.

그러나 오프체인 서비스 제공업체(OSP)가 운영하는 원장 채널은 사용자의 유동성 문제를 줄일 수 있습니다. 원장 채널에 연결된 두 피어는 원할 때 언제든지 완전히 오프체인에서 열고 완결할 수 있는 가상 채널을 생성할 수 있습니다.

오프체인 서비스 제공업체는 여러 피어와 채널을 열 수도 있어 지불 라우팅에 유용하게 만들 수 있습니다. 물론 사용자는 OSP의 서비스에 대해 수수료를 지불해야 하며, 이는 일부에게는 바람직하지 않을 수 있습니다.

Griefing attacks

그리핑 공격(Griefing attacks)은 사기 증명 기반 시스템의 일반적인 특징입니다. 그리핑 공격은 공격자에게 직접적인 이익을 주지는 않지만 피해자에게 고통(즉, 피해)을 주기 때문에 이런 이름이 붙었습니다.

사기 증명은 정직한 당사자가 유효하지 않은 분쟁을 포함한 모든 분쟁에 응답해야 하며, 그렇지 않으면 자금을 잃을 위험이 있기 때문에 그리핑 공격에 취약합니다. 악의적인 참가자는 온체인에 오래된 상태 전환을 반복적으로 게시하기로 결정하여 정직한 당사자가 유효한 상태로 응답하도록 강제할 수 있습니다. 이러한 온체인 트랜잭션 비용은 빠르게 누적되어 그 과정에서 정직한 당사자가 손실을 입게 될 수 있습니다.

Predefined participant sets

설계상 상태 채널을 구성하는 참가자 수는 수명 주기 내내 고정되어 있습니다. 참가자 세트를 업데이트하면 특히 채널에 자금을 조달하거나 분쟁을 해결할 때 채널 운영이 복잡해지기 때문입니다. 참가자를 추가하거나 제거하려면 추가적인 온체인 활동도 필요하므로 사용자의 오버헤드가 증가합니다.

이로 인해 상태 채널을 추론하기는 더 쉬워지지만, 애플리케이션 개발자에게 채널 설계의 유용성을 제한합니다. 이는 상태 채널이 롤업과 같은 다른 확장성 솔루션을 위해 왜 버려졌는지를 부분적으로 설명합니다.

Parallel transaction processing

상태 채널의 참가자는 교대로 상태 업데이트를 보내며, 이것이 "턴 기반 애플리케이션"(예: 2인용 체스 게임)에 가장 잘 작동하는 이유입니다. 이는 동시 상태 업데이트를 처리할 필요성을 없애고 오래된 업데이트 게시자를 처벌하기 위해 온체인 컨트랙트가 해야 할 작업을 줄여줍니다. 그러나 이 설계의 부작용은 트랜잭션이 서로 종속되어 지연 시간이 증가하고 전반적인 사용자 경험이 저하된다는 것입니다.

일부 상태 채널은 오프체인 상태를 두 개의 단방향 "단순(simplex)" 상태로 분리하여 동시 상태 업데이트를 허용하는 "전이중(full-duplex)" 설계를 사용하여 이 문제를 해결합니다. 이러한 설계는 오프체인 처리량을 향상시키고 트랜잭션 지연을 줄입니다.

상태 채널 사용

여러 프로젝트에서 탈중앙화 애플리케이션 (dapp)에 통합할 수 있는 상태 채널 구현을 제공합니다.

더 읽어보기

상태 채널

도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하고 추가해 주세요!