이제 오랜 기다림이 끝났습니다: 저희 c-lightning 팀은 기쁜 마음으로 프로젝트의 주요 성공 과제인 c-lightning 0.6 출시를 발표합니다. 이전 구현을 완벽히 개선했고, 사양이 완전 호환된 최초의 c-lightning입니다. 사양을 설계할 때 사용된 프로토콜에서 새롭고 확장 가능한 모듈식 아키텍처로 마이그레이션하여 사용자의 니즈와 인프라에 더욱 잘 적응합니다.
Lightning Network 성장 통계
또한 오늘은 Lightning Network의 성장과 발전을 기념하는 중요한 날입니다: 현재 세 가지 Lightning 구현(Eclair, lnd, c-lightning)이 베타 버전으로 출시되었습니다! 지난 1월 Blockstream 스토어가 오픈한 이래, Lightning Network는 엄청난 성장을 이뤘습니다. Blockstream 스토어가 발표될 즈음 Lightning Network는 총 46개의 오픈 채널과 0.682 BTC의 용량을 보유하고 있었습니다. 현재 오픈 채널의 개수는 약 7,800개이고 용량은 26 BTC에 달합니다. 6개월 만에 채널은 16,856%, 채널 용량은 4,084% 증가한 것입니다!
새로운 기능
버전 0.6에 포함된 새로운 기능은 일일이 나열하기엔 너무나 많은데, 가장 흥미롭고 눈에 띄는 기능은 다음과 같습니다:
● 경량 노드: 이전 버전에서는 비트코인 네트워크에 대한 액세스를 제공하기 위해 c-lightning과 함께 실행되는 전체 비트코인 노드가 필요했습니다. 이번 버전도 역시 bitcoin-cli 유틸리티가 필요하지만, 이제는 spruned 같은 일부 경량 노드 등 원격 노드와 통신할 수도 있습니다. 이를 통해 Raspberry Pis뿐만 아니라 다른 저전력 장치에서도 c-lightning 노드를 실행할 수 있습니다.
● 가십 프로토콜은 이전 버전처럼 전체 네트워크 보기를 교체하는 것이 아니라, 특정 정보를 요구하는 더욱 가벼운 대역폭 메커니즘을 사용하도록 업데이트 되었습니다. 이러한 업데이트가 없다면 저전력 장치와 모바일 장치는 이미 가지고 있는 정보를 다운로드하고 검증하는 데 많은 대역폭과 에너지를 소비하기 때문에 더욱 중요한 새로운 기능입니다.
● API 안정성: c-lightning JSON-RPC 인터페이스와 지원 라이브러리는 향후 버전의 변경을 최소화하기 위해 재설계되었습니다. 앞으로 얼마 간은 다른 변경 사항이 있을 경우 하위 호환성을 유지하며 이 버전의 API를 지원할 예정이기 때문에, 다른 프로젝트들은 이 API 안정성을 통해 c-lightning을 기반으로 쉽게 구축되어야 합니다.
● 지갑 및 동기화: 이제 c-lightning은 온체인 자금과 오프체인 자금을 모두 관리하는 완전한 지갑을 제공합니다. 더 이상 원시 거래(raw transaction)를 처리할 필요가 없습니다! 모든 자금은 자동으로 추적되어 사용자 상호 작용 없이도 최대한 빨리 내부의 지갑으로 반환됩니다. 또한 이제 블록체인 추적은 긴 블록체인 재스캔을 끝내고 블록체인의 내부 보기를 유지합니다.
● TOR 지원: 이제 c-lightning은 TOR 네트워크를 통한 노드 연결, 숨겨진 서비스로서 자동 등록, TOR을 통한 수신 연결 허용을 지원합니다.
● 결제 로직은 라우팅 실패 후 자동 재시도, 라우트 선택의 무작위화, 현재 결제 상태에 대한 더 나은 피드백을 지원하기 위해 대대적인 점검을 마쳤습니다.
● 늘 그렇듯: 성능, 성능, 성능.
모듈 방식을 통한 유연성
c-lightning 아키텍처는 수많은 독립 커뮤니케이션 프로세스를 기반으로 하는데, 각 프로세스는 각자의 책임을 갖습니다. 이를 통해 고객의 인프라와 보다 잘 통합되고 필요에 맞게 잘 조정될 수 있습니다. 모든 채널에 대해 범용적인 두 개의 데몬인 gossdd와 hsmd의 모듈식 설계는 특히 주목할 만합니다.
gossipd는 네트워크의 로컬 뷰를 관리하고 결제 소스에서 목적지까지의 경로를 찾는 작업을 수행합니다. 기본 구현은 수수료, 시간 초과, 안정성 간 적정 균형을 유지하는 경로 탐색을 시도합니다. 또한 결제의 종단점을 숨기기 위해 여러 후보 경로 중 무작위로 선택하고 금액과 시간 초과를 변경함으로써 경로를 혼란스럽게 만듭니다. 특정 라우팅 요구 사항이 있거나 특정 라우팅 정책(예를 들어, 항상 최소 시간 초과나 최저 수수료로 경로 선택)을 시행하고자 할 경우 기본 구현을 쉽게 전환할 수 있습니다.
hsmd는 암호화 자료를 다루는 모든 작업을 관리하고 채널의 자금을 통제합니다. hsmd는 노드의 비밀 키에 액세스할 수 있는 유일한 서브 시스템입니다. 즉, 다른 서브 시스템은 어떠한 기밀 정보도 보유하지 않고 서명이나 암호 해독을 위해서는 hsmd 데몬과 통신해야 합니다. 이러한 방식으로 암호화 작업을 중앙 집중화하면 보안이 필요한 표면이 줄어들고 수많은 응용 프로그램을 이용할 수 있습니다. 이미 기본 hsmd 구현은 프로세스 분리, SELinux 및 AppArmor 같은 OS 수준 보안을 통한 추가 보안 기능을 통해 우수한 보안을 제공하지만, 이는 물리적 HSM과 통신하는 구현으로 쉽게 대체될 수 있습니다. 또한 hsmd 구현을 교체하면 비밀 키를 관리하고 결제를 시작하거나 인보이스를 생성하는 페어링 된 모바일 앱으로 헤드리스(headless) 작업(집에서 c- lightning 노드 실행 등)을 할 수 있습니다.
이렇게 c-lightning 기능을 여러 데몬으로 분리하면 공격자가 비밀 키를 다루는 그 어떤 것도 직접 접속할 수 없기 때문에 유연성이 크게 향상될 뿐만 아니라 노드 보안이 크게 향상됩니다. 각 서브 시스템은 내부 상태의 일관성을 개별적으로 확인하며, 비일관성이 감지되면 피어 연결을 끊고 프로세스를 종료시킵니다. 멀티 데몬 아키텍처를 통해 Docker, SELinux, AppArmor를 사용하여 각 데몬이 액세스할 수 있는 정보와 수행할 수 있는 작업을 잠글 수 있습니다.
향후 계획은?
c-lightning 개발 작업은 여전히 진행 중입니다; 저희는 성능, 안정성, 사용성 개선뿐만 아니라 기능과 성능 개선에 지속적인 노력을 기울이고 있습니다. 마음에 드는 기능을 찾지 못하셨나요? 도움이 될 만한 피드백을 주고 싶으신가요? Github에 문제를 제기하시거나, 메일링 리스트로 메일을 보내주시거나, IRC를 통해 문의 바랍니다.
동시에, 저희는Lightning 사양 자체를 개선하는 데에도 기여하고 저희의 eltoo 제안, SIGHASH_NOINPUT 등 업스트림 비트코인 제안 같은 계획을 통해 프로토콜의 다음 반복은 어떤 모습일지 적극적으로 연구하고 있습니다.
c-lightning에 코드를 제공해 주신 분들, 어떤 기능이 작동하는지, 무엇을 개선해야 하는지 #적극적으로 테스트하고 피드백을 주신 분들께 감사의 말씀을 드립니다. 마지막으로, 다른 Lightning Network 팀인 ACINQ, Lightning Labs와 Lightning Network 커뮤니티를 즐겁고 협력 적이며 개방적인 환경으로 만드는 데 기여한 모든 분들께 감사의 말씀을 전합니다!