작성자: lukechilds
출처: https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff
개요
이 제안은 기존 이캐시(eCash) 민트에 설치할 수 있는 자체 보관 포인트 시스템을 소개합니다. 사용자의 잔액은 신뢰할 필요 없는 포인트 계약에 보관되며, 언제든(예: 결제 시) 이캐시 토큰으로 오프체인 교환할 수 있습니다. 위탁 리스크는 결제 처리 중에만 존재하며, 일반적으로 몇 초 내에 해결됩니다. 사용자의 잔액은 항상 자체 보관되므로, 민트가 사라지거나 협력을 거부하더라도 사용자가 일방적으로 탈퇴하여 온체인에서 자신의 포인트를 찾을 수 있습니다.
이 프로토콜은 비트코인(BTC) 상에서 구현할 수 있으며, 소프트 포크나 새로운 OP_CODE가 필요하지 않습니다. 사실 OP_CODE가 필요하지 않습니다. 전체 프로토콜은 거의 완전히 오프체인이며, 신뢰할 필요 없는 포인트 계약을 실행할 수 있는 모든 방법이 MuSig2 taproot 키 지출 경로로 이어집니다. 비트코인 스크립트는 필요하지 않습니다.
문제
표준적인 사용자 흐름은 사용자가 월급을 받으면 매달 사용할 금액을 이캐시(eCash) 민트에 예치하고, 점진적으로 소액 결제를 시작하는 것입니다. 이 화폐 흐름은 주로 단방향이며, 월급 외에는 최종 사용자가 돈을 받는 경우가 거의 없습니다.
사용자가 하루에 4건의 10달러 거래를 해야 한다면 한 달에 120건의 거래를 해야 합니다. 총 1,200달러 규모입니다. 그들은 매월 초에 1,200달러 가치의 자금을 특정 이캐시(eCash) 민트에 예치할 수 있으며, 한 달 동안 자유롭게 사용할 수 있습니다. 이 시스템은 의미가 있습니다. 왜냐하면 매월 120건의 경제 거래를 온체인 거래 1건으로 압축할 수 있기 때문입니다.
단점은 이러한 효율성 향상이 엄청난 리스크와 함께 온다는 것입니다. 모든 잔액이 민트에 위탁되므로 사용자는 그들이 자금을 훼손하지 않을 것이라고 신뢰해야 합니다. 1,000명의 사용자가 이렇게 하는 민트가 있다면 총 120만 달러의 자금을 관리하게 됩니다. 민트 운영자가 도망갈 수 있다고 생각하면 이는 상당한 금액입니다. 민트 운영자가 정직하더라도 공격자가 그들을 노릴 수 있습니다.
해결책
민트가 잔액을 관리하는 대신 사용자와 민트 간의 신뢰할 필요 없는 포인트 계약에 자금을 예치할 수 있습니다. 이 포인트는 자체 보관되며 사용자와 민트 모두 상대방의 협조 없이 일방적으로 계약을 탈퇴할 수 있습니다. 포인트는 오프체인에서 즉시 민트에 전달되어 이캐시(eCash) 토큰으로 교환될 수 있습니다. 결제 시에만 포인트가 이캐시(eCash) 토큰과 교환되며, 이 토큰도 즉시 사용됩니다. 위탁 리스크는 여전히 존재하지만 결제 처리 중에만 존재(일반적으로 몇 초 내에 완료)하며, 거래에 사용된 금액만 리스크에 노출됩니다.
이 신뢰할 필요 없는 포인트 시스템은 Spillman 지불 채널(단방향 지불 채널)을 사용하여 구현할 수 있습니다. Spillman 채널은 두 가지 주요 단점 때문에 널리 사용되지 않았습니다: 단방향이며 사전 정의된 시간 내에 실패합니다. 그러나 이러한 단점은 이 사용 사례에 매우 적합합니다. 사용자가 주로 지출하고 수령하지 않기 때문에 자금이 단방향으로만 흐르는 것이 문제가 되지 않습니다. 또한 사용자가 매월 민트에 자금을 예치해야 하므로 채널이 한 달만 지속되는 것도 문제가 되지 않습니다.
이러한 단점이 우리를 방해하지 않으므로 Spillman 채널의 장점이 매우 명확합니다. 사용자 입장에서는 노드를 실행할 필요가 없고, 온라인 요구 사항이 없으며, 복잡한 상태 백업이 필요하지 않고, 수령 한도를 관리할 필요도 없습니다. 사용자는 단순히 채널에 자금을 예치하고 사전 서명된 거래를 민트에 보내기만 하면 채널을 통해 결제할 수 있습니다.
이 프로토콜에서는 비트코인의 새로운 기능을 활용하여 Spillman 채널의 새로운 변형을 제안합니다. 가능한 모든 지출 조건을 충족할 수 있는 MuSig2 taproot 키 지출 경로로 Spillman 채널을 구현합니다. 단점은 결제 시 양측 간 상호 작용이 필요하다는 것입니다. 그러나 이캐시(eCash) 토큰 발행 자체가 민트와의 상호 작용을 필요로 하므로 이로 인한 복잡성 증가는 크지 않습니다.
프로토콜
신뢰할 필요 없는 포인트 계약은 사용자와 민트 간의 2-of-2 MuSig2 다중 서명 장치입니다. 사용자는 계약에 1개월 동안 사용할 자금을 제공하지만, 이 입금 거래는 아직 브로드캐스트하지 않습니다. 그런 다음 사용자는 계약 내 모든 잔액을 자금에 다시 전송하는 환불 거래를 생성하지만, 이 환불 거래의 nLockTime(절대 시간 잠금)은 1개월 후로 설정됩니다. 그런 다음 환불 거래에 사용자와 민트가 함께 서명해야 합니다. 이것이 사용자의 일방적 탈퇴 거래입니다. 환불 거래에 서명한 후 사용자는 안전하게 입금 거래를 브로드캐스트할 수 있습니다. 입금 거래가 블록에 확인되면 이 신뢰할 필요 없는 포인트 계약이 활성화되며, 사용자는 해당 민트에서 1개월 동안 사용할 수 있는 자금을 포인트 형태로 보유하게 됩니다.
사용자가 민트를 통해 결제를 시작하려면 신뢰할 필요 없는 포인트를 신뢰가 필요한 이캐시(eCash) 토큰으로 교환해야 합니다. 사용자는 새 거래를 생성하여 입금 거래를 소비하고, 민트가 요구하는 포인트 금액을 민트에 전송하며, 계약의 나머지 잔액을 자신에게 다시 전송합니다. 사용자는 musig 조각 서명을 생성하여 민트에 보내며, 민트는 자신의 조각 서명을 병합하여 유효한 서명을 얻습니다. 민트는 자신의 조각 서명(또는 유효한 서명 거래)을 사용자에게 다시 전송하지 않습니다. 이것이 민트의 일방적 탈퇴 거래이며, 이를 통해 그들은 언제든 신뢰할 필요 없는 포인트 계약을 실행할 수 있습니다. 이제 민트는 이 사용자에게 동일한 금액의 이캐시(eCash) 토큰을 기록합니다. 이 토큰은 위탁 리스크가 있지만 사용자는 즉시 이를 사용하여 완전한 자체 보관 상태로 돌아갈 수 있습니다(나머지 잔액은 신뢰할 필요 없는 포인트 계약에 있습니다).
다음에 사용자가 결제를 시작하려면 동일한 프로세스를 반복하여 새 거래를 생성하고 이번에는 이전 거래 금액과 현재 금액을 합한 금액을 민트에 지불합니다. 각 상태 업데이트에 대해 민트에 새 일방적 탈퇴 거래가 생성되며, 새 거래가 항상 이전 거래보다 더 가치 있으므로 민트는 최신 일방적 탈퇴 거래만 보관하면 됩니다. 복잡한 상태 관리가 필요하지 않습니다.
월말이 되면 이 신뢰할 필요 없는 포인트 계약을 다음 달로 연장하고 더 많은 포인트를 예치할 수 있습니다. 사용자와 민트가 함께 입금 거래를 소비하여 민트에 이미 사용된 포인트를 지불하고 나머지 잔액을 새 계약에 예치합니다. 사용자는 이 거래에 새 입력을 추가하여 새 계약에 더 많은 포인트를 예치할 수 있습니다. 결과적으로 매월 온체인 거래는 1건뿐이며, 이 거래는 다음 달 새 포인트를 예치하고 지난달 사용된 포인트를 민트에 지불합니다.
이 신뢰할 필요 없는 포인트 계약을 실행하는 모든 방법 - 일방적 탈퇴, 협력 탈퇴, 협력 연장 - 은 musig 키 지출 경로로만 이루어지므로 온체인 흔적이 매우 적습
이 무신뢰 크레딧 계약을 떠나기
양측은 언제든 협력적으로 이 계약을 종료할 수 있습니다. 민트는 언제든 최신 상태로 일방적으로 종료할 수 있습니다. 사용자는 계약이 실패한 후에만 일방적으로 종료할 수 있습니다. 중요한 것은, 계약이 협력적으로 종료되지 않으면 민트는 계약 실패 전에 일방적으로 종료해야 하며, 그렇지 않으면 사용자가 일방적으로 종료하고 계약의 모든 자금을 회수할 수 있다는 것입니다.
더 깊이 생각해보기
프라이버시 영향
이캐시(eCash)의 가장 좋은 점 중 하나는 거의 완벽한 프라이버시를 제공한다는 것입니다. 이러한 프라이버시를 얻는 부분적인 이유는 민트에 묵묵히 있는 시간입니다. 만약 동일한 민트 내 사용자에게 이 프로토콜을 사용하여 지불하면 프라이버시를 유지할 수 있습니다. 그러나 민트 외부의 라이트닝 인보이스에 지불하면 이캐시(eCash)의 프라이버시 특성을 상속받을 수 없습니다. 여전히 온체인 프라이버시와 라이트닝 네트워크의 송금자 프라이버시를 얻을 수 있습니다. 그러나 민트 운영자가 민트로 들어오는 크레딧-토큰 교환과 민트에서 나가는 토큰-라이트닝 지불 교환의 시간과 금액 분석을 쉽게 수행할 수 있습니다. 민트 운영자의 관점에서 볼 때 프라이버시가 없습니다.
그러나 이는 민트 내에서 소량의 에스크로 이캐시(eCash) 토큰을 보유함으로써 해결할 수 있습니다. 예를 들어, 무신뢰 크레딧 계약에서 약 95%의 잔액을 보유하고 이캐시(eCash) 토큰 형태로 5%의 잔액을 보유하면 금액 관계를 흐릴 수 있고 민트 진입/퇴출의 시간/금액 연관성을 깰 수 있습니다. 사용자는 5%의 잔액만 에스크로 리스크에 노출되면서도 이캐시(eCash)의 뛰어난 프라이버시를 복원할 수 있습니다. 흥미로운 점은 이것이 사용자가 구성할 수 있는 것이라는 것입니다. 사용자는 프라이버시/에스크로 리스크에 대한 선호도에 따라 이 비율을 조정할 수 있습니다.
무신뢰 수금이 불가능
이 프로토콜은 무신뢰 지불 경험을 열었지만 무신뢰 수금 경험은 제공하지 않습니다. 앞서 설명한 표준 사용 흐름에서 언급했듯이, 수금은 많은 사용자에게 자주 필요한 작업이 아닐 수 있으므로 문제가 되지 않을 수 있습니다. 사용자는 에스크로 이캐시(eCash) 토큰을 직접 수령한 후 우선적으로 사용할 수 있습니다(크레딧 사용을 미룸).
앞의 예를 들면, 사용자가 매일 10달러 가치의 4건의 거래를 해야 한다면 한 달에 최대 1,200달러가 필요할 것입니다. 만약 그 중 한 건의 지불이 환불되면 10달러(전체 잔액의 0.8%)만 에스크로 리스크에 노출되며, 하루의 1/4 시간(곧 돈을 사용할 기회가 생길 것)만 노출됩니다.
무신뢰 수금으로 확장
이 프로토콜을 반대 방향으로 복사하여 무신뢰 수금 경험을 활성화할 수 있지만, 이것이 너무 복잡하다고 생각하며 앞서 설명한 이유로 필요하지 않다고 생각합니다. 이캐시(eCash) 민트를 통해 수금하려는 상인에게는 의미가 있을 수 있습니다. 이 경우 민트는 사용자와 상인 간의 빠르고 소액의 신뢰 최소화 지불 허브가 될 것입니다.
민트에서 상인으로 가는 반대 방향의 무신뢰 크레딧 채널을 설정할 수 있습니다. 이 경우 민트가 Spillman 채널을 상인에게 열어야 합니다. 이 역방향 구조에서 민트는 상인에게 예상되는 유동성을 미리 제공하고 수수료를 받아야 합니다. 상인은 민트가 처리 중인 지불을 훼손하지 않을 것을 신뢰해야 하지만, 일단 지불이 도착하면 잔액은 자체 관리됩니다. 또한 민트가 협력하지 않으면 상인은 일방적으로 계약을 종료하고 자금을 회수할 수 있습니다. 상인이 계약 실패 전에 계약을 종료하거나 연기하지 않으면 민트가 지난 달 받은 지불을 훼손할 수 있습니다.
이 역방향 구조의 추가 복잡성으로 인해 상인이 직접 라이트닝 채널을 사용하는 것보다 명확한 이점이 없다고 생각합니다.
유동성
이 프로토콜은 민트에 추가적인 유동성 요구사항을 부과하지 않습니다. 민트에 이미 많은 에스크로 사용자와 비에스크로 사용자가 있다면, 이 사용자들이 간헐적으로 크레딧을 추가하고 사용하면서 민트가 유동성 문제에 직면할 가능성은 낮습니다. 그러나 많은 비에스크로 사용자가 갑자기 등장하고 라이트닝 네트워크를 통해 대량의 자금을 지불하려 한다면 민트의 라이트닝 지불 능력이 고갈될 수 있습니다.
주목할 점은 이 경우 민트가 부분 준비금 체계를 사용할 수 없다는 것입니다. 민트는 사용자의 인출 요구를 처리할 수 있을 만큼 충분한 자금을 보유해야 하며, 단지 일부 자금만 크레딧 계약에 배치됩니다. 자금이 민트를 떠나면 민트는 다른 사용자의 인출을 지급하기 위해 일부 크레딧 계약을 종료해야 할 수 있습니다. 사용자와 계약을 종료하는 것이 번거로우므로 민트는 추가적인 유동성을 준비하거나 라이트닝 지불을 제3자에게 아웃소싱하고 월별로 정산할 수 있습니다.
계약 만료
계약 존속 기간은 임의적입니다. 우리는 1개월을 제안했는데, 이는 월급 지급 회계 관행과 일치시키기 위해서입니다. 그러나 이는 크레딧 계약에 여전히 많은 잔액이 있더라도 매월 온체인 거래가 필요함을 의미합니다. 만료 기간을 1년으로 늘릴 수 있어 1년 동안 계약이 유지될 수 있습니다. 그러나 이에는 단점이 있는데, 민트가 협력하지 않으면 사용자의 자금이 최대 1년 동안 잠길 수 있습니다. 이는 현재의 에스크로 모델에서 민트가 협력하지 않으면 모든 자금이 손실되는 것에 비해 명확한 개선이므로 합리적인 절충점일 수 있습니다.
감사의 말
@tiero와 @ArkLabsHQ 팀이 Ark에서 Spillman 채널의 역할에 대해 수행한 연구에 감사드립니다. 이 연구는 이 프로토콜의 개념을 이끌어내는 데 도움이 되었습니다.
@moonsettler와 크레딧 기반 이캐시(eCash)를 사용하여 동일한 문제를 해결하려는 연
감사합니다 @tiero, @robinlinus, @stevenroose, @kukks, @mayankchhabra, @nmfretz 및 @gandlafbtc님께서 이 제안을 읽고 피드백을 주셔서 감사합니다.
(완)
