DID 확장성을 위한 Sidetree 프로토콜
본 글은 DIF(Decentralized identity Foundation)에서 소개한 Sidetree 프로토콜에 대한 내용입니다. 보다 상세한 내용은 Sidetree spec에서 확인하실 수 있습니다.
블록체인 확장성 문제가 DID에 미치는 영향
확장성(Scalability)이란 시스템의 규모가 커질 때 얼마나 효율적으로 운영할 수 있는지를 나타내는 성능 지표입니다. 블록체인에서는 확장성을 나타내는 수치로 TPS (Transaction Per second)가 주로 논의됩니다(이외에도 합의 참여 노드나 스토리지 용량에 관한 확장성 문제도 있습니다) TPS 는 네트워크 용량을 의미하는 throughput과 블록체인에 저장되기까지의 지연 시간을 의미하는 latency도 함께 포함된 지표입니다. 현재 주요 블록체인 플랫폼인 비트코인이나 이더리움 메인넷의 속도는 100 TPS에도 미치지 못하는 매우 낮은 수준입니다.
DID(Decentralized ID) 에서 인증을 수행할 때 블록체인을 기반으로 프로세스가 진행되는데 VC(Verifiable Credential)의 발급, 등록, 검증 등의 절차에서 블록체인에 접근하게 됩니다. 새로운 발급과 등록 등 블록체인에 데이터를 쓰는 과정에서는 On-chain TX이 필요한데, 이 때 마다 블록의 지연시간을 기다려야 하는 것은 장기적으로 문제가 될 수 있습니다. 예를 들어 Bitcoin을 기반으로 DID를 구성한다고 했을 경우, 블록 생성 주기인 10분을 기다려야 믿고 처리할 수 있는 상태가 됨을 의미합니다. 즉, DID에서 블록체인의 확장성 문제가 영향을 미칠 수 있습니다.
확장성 문제는 탈중앙성(Decentralization)과 보안(Security)을 함께 고려해서 해결되어야 하기 때문에 특정 부분을 향상시키기 위해서 다른 부분의 손해를 감안해야 하는 것을 가리켜 트릴레마(Trilemma)라고 얘기합니다. 탈중앙성과 보안을 해치지 않으면서 확장성 문제를 해결하기 위해 제시된 방법으로 Bitcoin Lightning Network, State Channel, Sidechain 등이 있습니다. 이들의 공통점은 다른 확장성 솔루션인 Sharding이 메인넷의 수정을 요구하는 것과는 달리 메인넷을 그대로 유지한채 추가 네트워크를 운영하여 확장성 향상을 가져가는 기술이라는 것입니다. 메인넷을 Layer 1, 추가로 구현된 네트워크를 Layer 2라고 하여 L2 솔루션이라고도 말합니다.
Layer 2 network
이 중 State Channel은 payment channel의 확장버전으로 볼 수 있는데요. 주요 원리는 하나의 트랜잭션이 하나의 거래를 나타내는 반면, off-chain 상에서 일어난 거래를 종합하여 한번에 처리 할 수 있도록 채널을 형성하는 것입니다. On-chain 트랜잭션 수를 최소화하여 메인넷의 TPS 한계를 극복하기 위한 것으로, Bitcoin Lightning network는 아래 그림과 같이 각 노드의 연결된 채널을 Off-chain 상에서 거래하여 채널을 닫는 시점에 한 번에 처리가 되는 원리입니다.
예를 들어, A와 B의 거래가 총 10건이 있었다고 할 때, 원래는 10개의 on-chain TX이 필요하지만 채널을 열고 닫을 때 단 두 번의 TX으로 동일한 효과를 낼 수 있습니다. 이것을 A와 B, B와 C, C와 D로 연결된 채널을 확장하면 서로 채널을 연결하지 않은 A와 D도 간적접으로 거래가 가능합니다. State Channel은 각 노드에 연결된 금액 뿐만 아니라, 채널에 등록된 계정의 블록체인 상에서 관리되는 모든 상태(e.g. 스마트 컨트트로 구현될 수 있는 변수 등)를 채널을 열고 닫는 시점에서 업데이트 하는 개념으로 작동합니다. 채널 내에서의 off-chain TX은 채널을 형성한 양자 혹은 경로 상의 노드들의 서명이 포함되어 채널을 닫을 때 부인 방지 효과를 가집니다. 또한, 각 TX들이 발생한 순서에 의해 Off-chain에서는 모든 노드가 하나의 상태에 도달하기 때문에 결정론적(Deterministic)이 됩니다.
DIF에서 제시한 Sidetree는 DID에서 블록체인을 활용할 때 확장성 문제를 해결하기 위하여 L2 Network를 구현하기 위한 프로토콜입니다. DIF에서 규격을 관리하고 있고, 최근 Microsoft는 Sidetree 프로토콜에 기반한 ION network를 비트코인에 베타버전으로 공개한 바 있습니다.
Sidetree
DID 에서는 ID 값을 가지고 관리되는 일련의 정보를 DID document에 표기하여 관리됩니다. 따라서 주소를 Key 로, 잔액을 Value로 관리하는 것처럼 ID 값(Key)과 DID Document(Value)가 관리됩니다. DID document는 블록체인 혹은 중앙화되지 않은 스토리지에 저장(e.g. IPFS)되는 것으로, DID 인프라에 참여하는 개체들이 쉽게 접근할 수 있어야하고, 상태 관리가 유지되어야 합니다.
Sidetree 프로토콜은 별도의 합의 알고리즘을 사용하지 않고 DID에 관한 상태를 업데이트 합니다. DID의 operation인 CRUD(Create, Recover, Update, Deactivate)가 발생할 때, DID document의 상태 변경이 발생하고, Sidetree 네트워크를 구성하는 노드에서는 이를 반영하기 위한 역할을 합니다. 네트워크는 DID와 연결된 상태 관리를 위해 블록체인 외부의 통신 과정에서 서명과 상태 일치에 도달하기 위한 정의가 필요합니다. 예를 들어 ION에서는 JWS (JSON Web Signature)와 delta based CRDT(Conflict-free Replicated Data Type)를 사용합니다.
Network Topology
아래 그림은 Sidetree에 기반한 DID 오버레이 네트워크를 나타냅니다. 네트워크를 구성하기 위해서 필요한 (1) 블록체인과 (2) Sidetree 네트워크 (3) 파일을 관리하는 CAS(Content Addressable Storage) 네트워크로 구성됩니다. CAS는 네트워크 상의 모든 파일을 식별할 수 있는 값을 부여한 스토리지로 IPFS와 같은 p2p 스토리지 네트워크를 의미합니다. IPFS는 DHT(Distributed Hash Table)에 기반하여 파일의 해시값 자체를 주소로 사용하기 때문에 CAS 네트워크의 URI(Uniform resource Identifier) 정의에 활용됩니다.
그림에서 보면, Sidetree 네트워크의 peer는 블록체인 트랜잭션을 쓰기 위한 ‘Batch Txn Writer’와 프로토콜을 준수하기 위한 Core에 해당하는 ‘Operation Processor’, CAS 네트워크와 동기화를 위한 로컬 형태의 ‘CAS Node’로 구성됩니다. Peer 간에 공유된 자원을 CAS에서 읽어와서 블록체인에 저장된 내역과 비교하여 검증하고, 상태를 유지하여 관리합니다. 데이터 흐름을 살펴보면 다음과 같이 정리할 수 있습니다.
- 최초의 Peer 노드는 자신의 공개키 주소로 생성된 블록체인 TX으로 sidetree 프로토콜을 활성화 시킵니다. 이 때, 초기 DID Document를 등록하여 최초의 상태가 결정됩니다.
- DID 주소와 매핑되는 CAS상의 상태의 변화가 Peer 간에 전파 및 공유되어 서명의 유효성을 검증합니다. (쉽게 생각하면 토렌트와 같은 p2p 파일 스토리지로 볼 수 있습니다.)
- Peer간에 공유된 상태는 즉시 다운로드 가능하며, 블록 생성 주기에 도달하면 블록체인 상에 명확한 상태의 결정에 이르게 됩니다.
- 최종적으로 DID와 연결된 CAS 상의 상태와 블록체인의 상태는 동기화를 이루어 신뢰성을 가집니다.
File Structure
Sidetree는 IPFS와 같은 CAS의 상태를 블록체인에 등록(Create), 갱신(Update), 복구(Recover), 비활성화(deactivate) 등을 수행하는 프로토콜입니다. Sidetree 프로토콜에서는 세 가지의 파일 구조를 활용하며 각 파일의 내용은 다음과 같습니다.
- Anchor File : 블록체인에 연결된 인덱스 및 데이터에 대한 최소한의 정보를 포함하고, 등록(create), 복구(recover), 비활성화(deactivate) 값으로 변경되는 CAS 링크 포함
- MAP File : 갱신(update) 값을 포함하며 Anchor File과 Chunk File을 연결
- Chunk File : 세부 DID operation data를 포함하는 파일
DID document를 IPFS에 저장함으로써 생성되는 URI 값을 블록체인 TX에 포함하여 저장하면, Anchor File에 의해 관리가 됩니다. DID document에 직접 표현되지 않는 기타 데이터의 관리는 모두 Chunk File에 의해 관리되고, Anchor File과 Chunk File의 연결은 MAP File에서 구성합니다.
ION network
Sidetree 프로토콜을 직접적으로 구현한 ION network의 동작을 알아보도록 하겠습니다. 아래 그림은 Microsoft에서 개발한 Bitcoin에 적용한 ION network에 대한 설명을 나타냅니다. ION 노드는 sidetree 프로토콜을 기반으로 구성되어 있으며(Processor) 블록체인에 연결을 위한 bitcoin 어댑터, IPFS storage로 구성됩니다.
아래 그림에서는 (1) ION Node 1이 최초의 DID Document를 블록체인에 등록하고, IPFS 스토리지(Sidetree의 CAS)를 통해 저장 및 전파합니다. (2) ION Node 2에서는 블록체인을 모니터링하여 IPFS상에서 공유된 트랜잭션 값을 찾아 상태 변경에 대한 검증을 위해 가져옵니다. (3) 블록체인에 저장된 해시값으로부터 IPFS의 DID Document를 분석하고 구현된 프로토콜의 규칙을 적용하여 최종 상태를 출력합니다.
ION network에서 전파될 때, 블록체인에 상태가 결정되기 전에 IPFS상으로 먼저 공유가 되기 때문에 보안상 공백기가 발생할 수 있습니다. 하지만, 기본적으로 IPFS상에서 공유되는 데이터도 서명 정보가 포함되어 있기 때문에 위변조에서는 안전하며, .CRDT에 의해 결국에 동일한 상태에 도달하는 것을 보장할 수 있습니다. 주변 노드가 공격할 수 있는 방법은 전파하지 않는 것 뿐입니다. 다만 이 과정에서 생길 수 있는 지연 문제는 앞으로 해결되어야 할 주요 이슈로 보입니다.
마치며 ..
본 글에서는 DID 확장성을 해결하기 위한 L2 layer 프로토콜인 Sidetree에 대해 분석하였습니다. 2020년 6월에 Microsoft는 비트코인 메인넷에 sidetree 프로토콜에 기반한 ION network를 제한적으로 운영할 수 있도록 공개하였고, 자사 클라우드인 Azure에서 이를 지원하도록 서비스하여 Azure에서 Bitcoin을 실행하면 실제 ION을 설치하지 않고 이용할 수 있습니다. 최근 DID는 더욱 발전이 가속화 되고 있는 가운데, DID에서 블록체인 활용을 더욱 용이하게 해줄 Sidetree 프로토콜이 얼마나 큰 역할을 할지 기대됩니다.
디센트 채널 링크
공식 웹사이트 : https://dcentwallet.com/
미디엄 : https://medium.com/dcentwallet
트위터 : https://twitter.com/DCENTwallets
페이스북 : https://www.facebook.com/dcentwallet
유튜브 : https://www.youtube.com/channel/UCKnYqiM3g3iaaAKcRZf-kbA
