BSV 개발자이신 준님의 미디엄 글입니다.
https://medium.com/@joonyeongpark/op-return을-db처럼-쓸-때의-세-가지-특징-e3e0546fdc13* 주의 1: 이 글은 웹 어플리케이션 개발자였던 제가 비트코인 개발에 입문하면서 느낀 것들입니다. 웹 어플리케이션 개발자의 관점에서의 주관이 아주 많이 포함되어있으며, 비트코인의 아주 근본적인 부분까지는 자세하게 알지 못하므로 틀린 내용이 있을 수 있습니다. 피드백은 언제나 웰컴입니다.
* 주의 2: 내년에 있을 BSV Genesis 업데이트를 위해 OP_RETURN 앞에 OP_FALSE를 붙여주셔야합니다. OP_RETURN을 이용하면 비트코인에 데이터를 기록 할 수 있습니다. 이 데이터를 이용하면 비트코인을 데이터베이스처럼 쓸 수 있고, 당연히 이걸 이용해서 서비스를 구현 할 수도 있습니다.
OP_RETURN으로 트랜잭션을 발생시키는건 기본적으로 DB에 Write하는 행위라고 생각하면 됩니다. 다만 블록체인 위에서 돌아가기 때문에 다음과 같은 특성이 있죠.
쓰기만 가능한 DB (append-only database)
기존의 DB처럼 수정/삭제는 하지 못합니다. 따라서 수정/삭제가 필요한 서비스라면 별도의 레이어를 만들어주어야합니다. 간단한 진행을 위해 실습은 생성만 필요한 서비스로 진행할 예정이지만, 수정/삭제에 대한 방법도 소개하고 넘어갈게요.
하나의 OP_RETURN은 하나의 사용자 Action이라고 볼 수 있어요. 예를 들어 캘린더앱에서 일정을 생성하는 프로토콜을 HTTP method에 대입하자면 아래와 같이 정의할 수 있겠죠.
OP_FALSE OP_RETURN [캘린더 프로토콜] PUT [일정ID] [일정 정보]수정은, 단순히 PUT을 한번 더 하면 되겠죠. (다만, 이 두 트랜잭션이 같은 Block에 포함된다면 순서의 문제가 생기는데, 아래 3번 항목을 봐주세요.)
OP_FALSE OP_RETURN [캘린더 프로토콜] PUT [일정ID][일정 정보]
OP_FALSE OP_RETURN [캘린더 프로토콜] PUT [일정ID][수정된 일정 정보]삭제는 DELETE로 해볼게요. 물론 정하기 나름입니다. 당신의 프로토콜이니까요.
OP_FALSE OP_RETURN [캘린더 프로토콜] PUT [일정ID] [일정 정보]
OP_FALSE OP_RETURN [캘린더 프로토콜] PUT [일정ID] [수정된 일정 정보]
OP_FALSE OP_RETURN [캘린더 프로토콜] DELETE [일정ID]이런 DELETE Action이 감지되면 당신의 서비스에서 해당 ID의 일정을 지워진 것으로 표시하고, 조회 요청이 들어왔을 때 해당 일정을 빼고 표시해주면 됩니다.
물론 삭제 되었다고 표시만 한 거라, 실제 블록체인 상에서 삭제가 된 건 아니죠. 그러나 이러한 투명성은 블록체인 앱이 갖는 중요한 특징입니다. ‘그런거 없었어’라고 발뺌 할 수 없어요. 언제, 누가, 어떻게 수정 했는지 다 남으니까요.
이런 관점에서 블록체인은 DB라기 보다는 글로벌 Event Log에 가까울 수 있겠네요.
모두에게 공개 되는, 그러나 권한(Authorization)은 확실하게
OP_RETURN으로 기록되는 모든 데이터는 투명하게 노출되기 때문에, 민감한 데이터라면 암호화가 필요합니다. (그렇다고 전 세계 모든 사람이 눈에 불을 켜고 지켜보고있는건 아니에요. 트랜잭션이 늘어나면 늘어날 수록 사막에서 바늘찾기가 될테니까요.)
보통 DB는 여러개의 instance가 있을 수 있고, DB에 접근하는건 엄격하게 제한되기 때문에, 기존의 어플리케이션 개발자라면 이 개념에 대한 적응이 필요합니다. 그러나 이건 아주 중요한 일이기도 해요. 당신의 서비스는 단 하나의 진실의 방 (Single Source of Truth)을 기반으로 동작 하게 되니까요.
사람들이 비트코인에 투자를 하고 가치를 부여하게 된 중요한 의미 중 하나는 완벽한 권한 처리입니다. 만약 구글코인이라는게 있었다면, 구글 직원이나 개발자는 어떻게든 옮길 수 있지 않을까요? 구글에서 자체적으로 암호화해서 처리한다고 홍보를 해도, 그 말을 믿을 것인지에 대한 ‘신뢰’의 문제는 피할 수 없습니다. 반면 비트코인은 특정 주소에 부여된 나의 돈은, 지구상에서 그 Private Key를 알고있는 나만 옮길 수 있죠.
OP_RETURN도 마찬가지입니다. PrivateKey를 소유한 사람만이 트랜잭션을 발생시킬 수 있고, 이런 특성을 이용하면 세상에서 가장 안전한 서비스를 사용자에게 제공 할 수 있어요. 지금의 비트코인은 ‘돈’ 이라는 서비스에 집중되어있을 뿐이지만, 어떤 서비스로도 확장 될 수 있습니다.
OP_RETURN으로 서비스에 권한처리를 넣는 방법에는 몇가지가 있는데, 저는 다음 세가지 정도를 알고있습니다.
- 같은 주소(=같은 Key)에서만 OP_RETURN을 발생시킴
가장 간단하지만, 원래 하나의 주소는 일회용으로만 사용 되도록 설계 되었기 때문에 권장되지 않습니다. 이 방법을 쓰려면 (주소 = Identity)로 쓰는걸 피할 수가 없는데, 이는 BSV 커뮤니티에서 반복적으로 비판받고있어요. MoneyButton은 트랜잭션을 발생시킬 때마다 주소가 바뀌기 때문에, 기존에 존재하는 서비스들을 쉽게 연동시키기도 어려워요.
다만 직관적이고 쉽기 때문에 과거에는 이 방식으로 권한처리를 넣은 경우가 많았으며 Memo가 이런 형태로 구현되어있습니다.
OP_RETURN 안에 서명값을 넣을 수 있게 설계된 프로토콜입니다. 비트코인상의 주소와 Identity 주소를 분리해서 처리하게 해주어서, MoneyButton처럼 새로운 주소를 생성하는 도구로도 권한 처리를 넣어줄 수 있습니다.
다만 OP_RETURN 끝에 서명이 붙기 때문에 프로토콜이 조금 복잡지고, 해당 서명의 진위 여부를 사용자 (혹은 당신이 만들 서버)가 직접 검증해야하는 번거로움이 있습니다. 이게 무거워지면 성능에도 영향을 주겠죠. 누군가가 가짜 서명을 발생시켜서 의도적으로 성능을 저하시키는 공격을 할 수도 있구요. (자기 돈을 써가면서까지…!)
- Metanet
‘비트코인은 메타넷을 위한 것이었다’고 말 할 정도로 크레이그 라이트의 야심작이죠. 조금 어렵지만 가장 좋은 방법이며, 위에서 언급된 문제점들이 대부분 해결되었을 뿐만 아니라 많은 활용 가능성이 있어 미래가치가 높은 방향입니다.
다만 도구들이 아직은 완전하지 않아, 학습과 삽질을 조금 하셔야될거에요. 시간과 의지가 있다면 충분히 도전할만한 방법입니다.
어느 방법을 택하든 복잡한 처리(특히 사용자의 PrivateKey 처리)가 들어가기 때문에, 실습은 권한이 없는 아주 간단한 채팅앱으로 진행할 예정입니다.
같은 블록 안에서는 시간이 모두 같은 DB
비트코인 트랜잭션의 세계에서 시간의 단위는 블록입니다. 이 부분은 _unwriter의 Neon Genesis, Chronos 소개글에 아주 자세하게 설명되어있습니다.
시간의 단위가 블록이기 때문에,같은 블록 안에서 트랜잭션들간의 정확한 순서는 알 수 없어요. 물리적으로는 먼저 발생한 트랜잭션이 있을지 몰라도, 채굴자들이 신이 아닌 이상 이걸 알 수는 없죠. (먼저 sign한 TX가 네트워크 환경이 안좋은 곳에서 발생해 채굴자에게 늦게 도달한다면?)
다만 Neon Genesis는 TTOR의 순서를 제공합니다. 트랜잭션간의 정확한 순서는 알 수 없지만, [어떤 트랜잭션의 Input이 다른 트랜잭션의 Output에 의존적인 경우]에는 그 순서는 보장해준다는거죠. 이 순서에 대한 부분은 비트코인 캐시 & 비트코인 SV 간의 의견차이가 되었던 부분이며 당시에 많은 논의가 되었었죠. CTOR vs TTOR?
Chronos는 해당 노드가 해당 Tx를 발견한 시간 기준으로 timestamp를 넣어주기 때문에, 노드들마다 timestamp 값이 달라요.
요약하자면 다음과 같습니다. 모든 트랜잭션의 정확한 순서는 알 수 없습니다. 블록체인 안에서 유일하게 의존 할 수 있는 정보는 블록 단위의 height, timestamp와, 그 블록에 포함된 트랜잭션들의 TTOR입니다.
다만 노드가 해당 Tx를 발견한 시점 기준으로의 timestamp 근사치를 제공하는 서비스(ex> Chronos), TTOR의 순서를 제공하는 서비스(ex> Neon Genesis)는 이미 존재합니다.
당신의 서비스에게 Tx의 순서가 중요하다면, 이런 도구들을 조합해서 근사치의 Ordering을 구현해서 쓰면 되겠죠. 많은 경우에는 이렇게 해도 충분해요.
결론
위에서 언급한 것들은 비트코인에서 갖는 기본적인 사항들입니다. 하지만 비트코인 자체는 가장 Low 레벨의 Layer에요. 필요한 경우 이 비트코인 레이어 위에 당신의 Application Layer를 구현해서 상호보완적인 설계를 할 수도 있습니다.
위 몇가지 사항만 주의한다면, 기존의 Database 기반 서비스를 개발하는 것에 비해서 크게 다르지 않습니다. 불과 1년 전까지만 해도 진입장벽이 아주 높았어요. OP_RETURN을 적절하게 Indexing 해주고 내려주는 서비스들이 많지 않았거든요.
그러나 점점 도구들이 좋아지고있고, 특히 _unwriter의 Planaria 노드들은 기존의 어플리케이션 개발에서 크게 다르지 않을 정도의 수준의 개발자 경험을 제공합니다. 바야흐로 비트코인 개발의 캄브리아기 폭발이 도래하고있습니다. 이제는 뛰어들어도 좋을 때입니다.