Liquid Network

안나가 파벨에게 돈을 보내려 한다고 해 봅시다. 두 사람 모두 Liquid Network를 지원하는 지갑이 있고, 빠른 확인과 금액의 비공개 처리를 원합니다. 안나는 일반 Bitcoin 결제를 더 빠른 지름길로 보내는 것이 아닙니다. 별도의 이력과 규칙을 가진 네트워크, 즉 Sidechain을 사용합니다. 여기서는 Liquid Bitcoin이라는 자산이 비트코인을 나타내며, L-BTC 또는 LBTC로 표기합니다. 새로 채굴한 비트코인이 아니라 준비금에 있는 BTC와 1:1로 대응하도록 설계한 자산입니다. 거래는 블록에 묶여 기록되며 Liquid만의 거래 이력을 이룹니다. 네트워크는 아직 사용하지 않은 거래 출력인 UTXO도 관리합니다. 각 출력은 자산 종류, 금액, 다음 지출에 필요한 조건을 정합니다. 따라서 Bitcoin 지갑이 Liquid도 지원한다고 가정해서는 안 되며, 받는 사람은 올바른 네트워크를 선택해야 합니다. [2] [3]

안나는 다른 보유자나 서비스를 통해 L-BTC를 얻을 수 있습니다. Bitcoin에서 직접 들어오는 과정은 peg-in이라고 합니다. 예를 들어 Liquid 운영자 집단인 연합이 관리하는, 별도로 생성한 Bitcoin 주소에 0.1 BTC를 보냅니다. Bitcoin에서 102회 확인되면 Liquid에서 이에 해당하는 0.1 L-BTC를 청구할 수 있습니다. 이해를 돕기 위해 여기서는 수수료를 제외합니다. 블록당 평균 10분이면 약 17시간이지만 실제 대기 시간은 달라집니다. 근거로 원래 거래와 그 거래가 블록에 포함됐음을 보이는 Merkle proof를 제출합니다. 돈이 두 배가 된 것은 아닙니다. 안나는 원래 BTC를 혼자 쓸 수 없게 되고 대신 L-BTC를 통제합니다. 이미 존재하는 L-BTC를 구매하는 것은 다른 경로이며, 구매자마다 새로운 peg-in이 필요한 것은 아닙니다. [4] [9]

파벨에게 Bitcoin 메인넷의 BTC가 필요해져도 L-BTC의 키만으로 준비금을 풀 수는 없습니다. 개인 키는 지갑이 Liquid의 해당 자금을 지출하도록 승인하는 디지털 서명을 만드는 데 쓰는 비밀 데이터입니다. 이 키가 파벨에게 Bitcoin 준비금을 지출하는 서명 권한까지 주는 것은 아닙니다. 직접 돌아오는 peg-out은 Peg-out Authorization Key, 줄여서 PAK가 있는 승인된 참여자에게 허용됩니다. 해당 L-BTC를 사용할 수 없게 만드는 처리를 보통 소각이라고 부르며, 운영자는 승인된 주소로 BTC를 지급합니다. 일반 사용자는 대개 이런 참여자나 교환 서비스, 또는 자산 맞교환인 swap을 이용합니다. Swap이 꼭 직접 peg-out인 것은 아닙니다. 상대방이 이미 보유한 BTC를 줄 수도 있습니다. 따라서 서비스 이용 가능 여부, 수수료, 교환에 쓸 수 있는 자금인 유동성, 이용 조건이 중요합니다. 준비금 비율 1:1이 무료·즉시 교환을 약속하지는 않습니다. [5] [9]

안나는 거래를 조회하는 웹사이트인 탐색기에 접속한 누구나 파벨에게 얼마를 냈는지 아는 상황을 원하지 않을 수 있습니다. Confidential Transactions는 보낸 금액과 자산 종류를 숨길 수 있습니다. 네트워크 규칙을 검증하는 컴퓨터인 노드는 여전히 암호학적 증명으로 보유량보다 많이 쓰지 않았는지 확인합니다. 권한이 있는 수취인은 숨겨진 정보를 읽는 blinding key로 내용을 확인합니다. 이 키 자체가 자금을 쓸 권한을 주지는 않습니다. 일부 정보는 회계 담당자 등에게 자발적으로 공개할 수도 있습니다. 그러나 거래 사이의 연결, 시간과 일부 정보는 여전히 공개되며 peg-in과 peg-out은 Bitcoin에도 흔적을 남깁니다. 따라서 Confidential Transactions가 자동적인 익명성이나 모든 작업의 비가시성을 뜻하지는 않습니다. [6] [10]

평상시 운영은 Strong Federation이 담당합니다. 운영자의 역할은 둘로 나뉩니다. blocksigners는 블록에 서명하고, watchmen은 준비금 BTC의 키와 인출을 관리합니다. Proof of Work(Bitcoin 블록을 찾는 데 필요한 계산 작업)를 이용한 채굴자의 공개 경쟁이 아닙니다. 결정을 내리려면 정해진 수의 서명이 필요하므로 보통 운영자 한 명이 모두를 대신해 결정할 수 없습니다. 키는 서명 가능한 내용을 제한하는 전용 보안 장치인 HSM으로도 보호합니다. 장부가 정상 작동하는 것과 준비금이 안전한 것은 별개입니다. 결제가 올바르게 확인되었다고 해서 BTC 출금이 항상 가능하다는 증거가 되지는 않습니다. 누구나 검증 노드를 운영할 수 있지만 준비금 관리자가 되는 것은 아닙니다. [2]

정상 상태에서 Liquid는 약 1분마다 블록을 만드는 것을 목표로 합니다. 두 번 확인되면 연합의 보안 가정이 성립하는 범위에서 거래가 최종 확정된 것으로 간주합니다. 서명 장치의 규칙이 더 깊은 과거 이력을 다시 쓰지 못하게 하기 때문입니다. 모든 공격과 고장을 막는 무조건적인 보장은 아닙니다. 2020년 whitepaper는 15명 중 11명의 서명, 즉 3분의 2를 넘는 서명이 필요한 구성을 설명합니다. 이 예시는 현재 회원 명단이 아닙니다. 참여 가능한 서명자가 부족하면 새 블록 생성이 멈출 수 있습니다. Liquid 안에서 빠르다고 해서 peg-in 대기나 Bitcoin으로 돌아가는 처리 과정이 없어지는 것도 아닙니다. 안나는 네트워크 사이의 전체 이동이 1분 만에 끝나리라 기대해서는 안 됩니다. [1] [2]

검증 노드는 Liquid의 규칙과 거래 증명을 확인합니다. peg-in 검증을 켜 두면 Bitcoin 노드를 통해 Bitcoin 쪽 근거도 확인합니다. 따라서 L-BTC의 준비금 뒷받침은 운영자 웹사이트에 표시된 숫자에만 의존하지 않습니다. 그렇다고 안나가 준비금 BTC의 키를 가지거나 네트워크가 항상 작동한다는 뜻은 아닙니다. 블록 서명이 중단되거나 준비금 지급에 문제가 생기거나 보안 장치가 침해될 수 있습니다. 연합의 비상 복구 절차는 모든 L-BTC 보유자가 독립적으로 BTC를 인출하는 버튼이 아닙니다. 개인 지갑은 사용자 계정의 수탁업체가 파산하는 위험을 줄일 수 있지만, 네트워크 사이의 연결 장치에 대한 의존까지 없애지는 못합니다. [1] [2] [9]

L-BTC 외에도 디지털 상품권이나 발행자가 다른 재산과 교환해 주겠다고 약속하는 토큰 같은 자산을 발행할 수 있습니다. 자산마다 고유한 asset ID가 있으므로 이름이나 아이콘이 비슷하다고 같은 자산인 것은 아닙니다. 발행자는 추가 발행 권한을 주는 reissuance token도 만들 수 있습니다. 이름 등록부는 자산 식별에 도움이 되지만 발행자의 지급 능력이나 약속의 법적 이행 가능성을 입증하지는 않습니다. L-BTC의 준비금 규칙이 다른 토큰에 자동으로 적용되는 것도 아닙니다. 파벨이 디지털 상품권을 받았을 때 네트워크는 이전을 정확히 기록했어도 발행자는 나중에 의무를 이행하지 못할 수 있습니다. [7] [11]

Liquid는 Bitcoin Core 코드에서 출발해 여러 자산과 기밀 거래를 지원하도록 확장한 오픈소스 소프트웨어 Elements를 기반으로 합니다. 숙련된 사용자는 elementsd 노드를 실행해 직접 규칙을 검증할 수 있습니다. PSET, Partially Signed Elements Transaction은 준비된 거래를 도구 사이에서 전달하는 형식으로, 검토와 금액 숨김, 서명에 필요한 정보를 모아 둡니다. 이것만으로 결제가 이미 전송됐다는 뜻은 아닙니다. 다른 자산을 보내더라도 네트워크 수수료는 L-BTC로 냅니다. 일반 지갑은 대부분의 기술적인 부분을 감추지만 해당 네트워크와 자산, 사용할 서명 장치를 지원하는지는 확인해야 합니다. [8] [13]

큰돈을 옮기기 전에 안나는 호환되는 지갑을 고르고 수취 네트워크를 확인한 뒤, 비용을 포함한 구체적인 BTC 복귀 경로를 알아봅니다. 백업은 사용하는 지갑의 요구에 맞춰 준비합니다. 지출 키뿐 아니라 숨겨진 금액을 읽는 정보도 복원할 수 있어야 합니다. 시드는 지갑이 키를 만들어 내는 바탕이 되는 비밀 데이터입니다. 일부 지갑은 SLIP-0077 등의 방식으로 시드에서 blinding keys를 만들지만 다른 구성은 추가 백업이 필요할 수 있습니다. 따라서 모든 키를 일일이 수동으로 내보내라는 지침이 항상 맞는 것은 아닙니다. 잔액만 보는 것보다 소액을 왕복시켜 보는 편이 실제 문제를 찾는 데 낫습니다. 제공되는 속도와 기밀성, 그에 따르는 조건을 이해한다면 Liquid는 특정 결제와 자산 용도에 도움이 될 수 있습니다. [9] [12]