목차
리서처
Key Takeaways
Simperby는 PDAO에서 개발한 오픈소스 블록체인 엔진으로, 이를 통해 개별 OO들은 자신의 의사결정을 위한 독립적인 체인을 만들 수 있다. 이는 Cosmos SDK가 코스모스 앱체인을 생성할 수 있게 해주는 것과 유사하다.
Simperby는 3S, 즉 Standalone, Sovereign, and Self-hosted의 원리를 지향한다. 이를 통해 OO들은 다른 체인이나 프로토콜에 의존하지 않고, 자신들의 의사결정과 거버넌스를 원하는 방식으로 진행할 수 있다.
Simperby는 멀티체인 구조 지원에 특화된 거버넌스 툴로서, 이는 OO들이 여러 체인에 걸쳐 확장하려는 구조에 매우 적합하다.
해당 글을 검토하고, 피드백해주신 @junha_yang님꼐 감사의 말을 전합니다.
1. OO(Onchain Organization)
1.1 DAO 말고 OO
개인적으로 나는 블록체인 기술을 사용하는 조직들을 통틀어서 Onchain Organization, OO라고 부르는 것을 선호한다. 특정 DAO ‘A’가 실제로 DAO인지, 아닌지에 대한 논의를 이어나가는 것보다는 그 모든 것들을 OO라 칭한 뒤에 OO 내의 다양성을 인정하고, 여러 조직들을 포용적인 관점에서 바라보는 것이 더 건설적인 방향이라고 생각한다. 최종적인 목표는 뭐가 어쨋든 결국 블록체인 기술을 통해서 인간끼리의 협업을 더 용이하게 만드는 것이기 때문이다.
OO에 포함되는 조직들의 형태는 각양각색이다. 우리가 DAO라고 부르는 완벽히 탈중앙화된 형태의 OO부터, AI랑 스마트 컨트랙트를 사용하며 사람의 오류는 최대한 줄이면서 현 규제에도 부합하는 형태의 BORG, 단순히 공동의 자금을 온체인 트레져리로 관리하는 소규모의 모임까지 모두 OO에 포함된다. 각 OO들은 해당 조직이 설립된 목적과 상황에 따라서 어느정도 수준의 블록체인 기술을 레버리지할지 자연스레 정하게 된다.
1.2 다양한 OO 툴
아래의 표에서 볼 수 있는 것처럼, OO의 형태만큼이나 다양한 OO 툴들이 존재한다. OO 툴 중에서 가장 흔한 것은 쉽게 OO를 만들고 운영할 수 있도록 도와주는 OO 프레임워크로, 대표적인 예시로는 Snapshot + SAFE나 Aragon이 있다.
Source: 1kxnetwork
1.2.1 Snapshot + SAFE
Snapshot는 오프체인 거버넌스 플랫폼으로, OO의 구성원들은 자신의 지갑을 통하여 안건에 서명하여서 투표권을 행사할 수 있다. Snapshot을 사용하는 OO들 대부분은 온체인 상에서 자금을 관리하기 때문에, 멀티시그를 통한 트레져리 관리 솔루션인 SAFE를 함께 많이 사용한다. Snapshot은 오프체인, SAFE는 온체인 솔루션이기 때문에, Snapshot에서 나온 결과가 직접 SAFE에 집행되지 않고, 중간에 인간이 한번 더 개입해야된다는 것은 특정 OO들에게는 아쉬운 부분일 수 있다.
이러한 점을 의식하였는지, Snapshot은 Optimistic Oracle 프로토콜인 UMA와의 협업을 통하여 oSnap이라는 모듈을 공개하였다. oSnap을 사용하면, 누구나 Snapshot에서 나온 결과를 실행하는 트랜젝션을 제출할 수 있고, 챌린지 기간 동안 fraud proof가 발생하지 않으면 SAFE에 적용된다. 따라서, oSnap을 사용하면 기존 Snapshot + SAFE 조합의 단점인 멀티시그 구성원들에 대한 의존도를 줄일 수 있다. 이외에도, ZK 기반의 레이어 2인 StarkNet 위에서 만든 투표 프레임워크인 Snapshot X를 통해서 OO들은 최소한의 비용으로 레이어 1에서 온체인 투표를 진행하였을 때와 비슷한 보안 수준을 가질 수 있다.
1.2.2 Aragon
Aragon은 조금 더 일반화된 프레임워크를 통해서 OO를 쉽게 만들고, 관리하는데 초점을 둔 프로젝트이다. Aragon은 두 가지 종류의 서비스, Aragon OSx와 Aragon App으로 구성되어 있다.
먼저, Aragon OSx는 모듈러 스택으로, OSx 프로토콜의 스마트 컨트랙트와 거버넌스 플러그인을 사용하여 상상할 수 있는 모든 OO의 형태를 만들 수 있는데, OSx 프로토콜의 핵심인 권한 관리 시스템을 통해 거버넌스 플러그인을 쉽게 적용하고 바꿀 수 있다. 이는 Aragon OSx 기반의 OO들이 쉽고 빠르게 다양한 거버넌스 실험을 할 수 있도록 도와준다. 반면, Aragon App은 유저 친화적인 서비스로 코드 작성이 필요하지 않으며, Aragon App의 인터페이스를 사용하여 몇 분만 OO를 생성할 수 있도록 한다.
1.3 Simperby는 다르다
앞서 소개한 두 프로젝트 외에도, DAOHaus, Colony, Syndicate 등의 기존 OO 툴들은 OO의 생성과 운영의 UX를 향상시키는데 집중하였고, 다양한 형태의 OO를 지원하는데 초점을 맞추었다. 해당 프로젝트들은 이를 위하여 사용하기 쉬운 인터페이스, 미니멀하고, 일반화된 OO 뼈대를 제공함과 동시에 각 OO들이 원하는대로 커스터마이징을 할 수 있도록 플러그인이나 익스텐션 등을 제공하였다.
오늘 소개할 Simperby가 흥미로운 이유는 기존의 OO 프레임워크들과 방법론, 목표, 타겟 등이 다르기 때문이다. 따라서, Simperby가 기존의 OO 프레임워크들에 비해서 우월하다고 얘기하기는 어렵지만, 분명히 몇몇 OO들에게 Simperby는 기존의 OO 프레임워크들보다 매력적일 것이다.
2. Simperby에 대하여
2.1 개요
Simperby는 오픈소스 재단인 PDAO에서 개발한 OO를 위한 블록체인 엔진이다. 비유하자면, Cosmos SDK를 통하여 코스모스 앱체인을 찍어낼 수 있는 것처럼, Simperby를 통해서 각 OO들은 각자의 의사결정을 위한 자신만의 체인을 가질 수 있게 된다. Simperby를 통해 만들어지는 체인은 오직 OO의 의사결정과 그 의사결정의 합의만을 위한 체인으로 스마트 컨트랙트를 지원하지 않을 뿐만 아니라, permissioned OO만을 대상으로 하기 때문에, 토큰이나 가스비도 존재하지 않는다.
2.1.1 대상
Simperby은 다음과 같은 특성, 혹은 니즈를 가지는 OO들에게 가장 적합한 솔루션이다.
Simperby는 새로운 구성원을 추가할 때, 기존 구성원들의 동의를 필요로 하는 permissioned OO를 타겟으로 한다. 따라서, 토큰만 있으면 자유롭게 거버넌스에 참여할 수 있는 OO들은 Simperby를 사용하기에 적합하지 않다. 일반적으로 현실 세계의 조직들은 대부분 permissioned OO에 해당하고, 온체인 네이티브 OO들은 permissionless OO에 해당하는 것 같지만, 또 항상 그런것은 아니다. FWB DAO의 경우, 단순히 $FWB 토큰을 소유하고 있다고 참여할 수 있는 것이 아니라 커미티 멤버들의 동의도 필요로 하기 때문에, 일부 permissioned OO의 특성을 가진다고 볼 수 있다.
또한, Simperby는 3S의 가치를 우선시하는 OO들에게 가장 적합하다. 3S란, Standalone, Sovereign, and Self-hosted를 의미한다. Simperby를 통해서 OO들은 의사소통과 거버넌스를 위한 자신만의 체인을 가질 수 있기에 다른 체인이나 프로토콜에 의존성을 가지지 않고, 자신들이 원하는대로 의사결정과 거버넌스를 진행할 수 있다.
Standalone과 Sovereign의 경우, 각 OO마다 자신만의 체인을 가짐으로써 달성되었다고 이해할 수 있다. 하지만, 여기서 한가지 의문이 들 수 있는 것이 3S 중에 바로 Self-hosted이다. 일반적으로 블록체인의 노드를 운영하는 것은 어려울 뿐만 아니라, 비용과 리소스 측면에서도 굉장히 비효율적이기 때문에, 일반인들에게 노드 운영을 요구하는 것은 불가능에 가깝다.
이를 위해서 Simperby 팀은 일반인들이 Simperby에 의해서 만들어진 체인의 노드를 최대한 쉽고, 간편하게 운영할 수 있도록 여러가지 기술적인 메커니즘을 추가하였다. 이따 자세히 알아보겠지만, OO의 구성원들은 노트북으로도 쉽게 노드를 운영할 수 있고, 해당 라운드의 리더가 아닐시에는 가끔만 온라인이면 되고, 언제 온라인이여야할지도 미리 쉽게 예측할 수 있다. 이렇게 노드 운영에 대한 부담을 확 줄임으로써, Standalone, Sovereign, 그리고 Self-hosted를 모두 가능케 한다.
2.1.2 용어 정리
Simperby에 대한 더 많은 논의를 하기 전에 헷갈릴 수 있는 몇가지 용어들을 정리하자.
Simperby chain: Simperby를 통해 만들어진 체인으로, 각 OO들은 각각의 Simperby chain을 갖게 된다.
아젠다: 거버넌스 안건으로, OO의 멤버들은 아젠다에 투표한다.
멤버: 거버넌스 과정의 참여자를 의미한다.
검증자: 합의 과정의 참여자를 의미한다. 검증자는 멤버의 부분 집합이다.
Settlement chain: Simperby chain을 사용하는 OO가 상호작용하는 다른 체인으로, 예를 들어, OO가 이더리움에 트레져리를 가지고 있다면, 이더리움은 settlement chain이다.
2.2 기능
Simperby chain를 통하여 OO 멤버들은 의사소통, 아젠다에 대한 표결, 그리고 해당 결과에 대한 합의를 이룰 수 있다.
2.2.1 채팅
Simperby chain는 P2P 네트워크를 통하여 노드들끼리 서로 디스코드처럼 소통할 수 있는 커뮤니케이션 채널을 제공한다. 누구나 자신의 공개키의 서명을 통해서 메시지를 전달할 수 있고, 각 메시지들은 이전 메시지의 해시값을 포함하여서 체인을 이루게 되고, 우리는 이를 챗 체인(chat chain)이라고 부른다.
챗 체인의 경우, longest chain rule을 통해서 정식(canonical) 체인이 정해지는데, 각 라운드의 블록 제안자는 챗 체인을 semifinalize하는 역할을 수행한다. 블록 제안자들은 주기적으로 자신이 보기에 가장 긴 체인에 ‘ack’라는 채팅을 제출하고, 다른 멤버들은 해당 체인에서 채팅을 이어나가게 된다.
2.2.2 거버넌스
거버넌스는 실제로 OO의 멤버들이 함께 아젠다를 통과시키는 과정이다. 누구나 아젠다를 제안할 수 있고, 이 아젠다는 앞서 살펴본 채팅의 P2P 네트워크를 통해서 전파된다. 멤버들은 해당 아젠다에 동의할 시 서명을 통해서 투표권을 행사하게 된다. 전체 멤버의 50% 이상이 동의한 아젠다는 블록에 포함될 수 있는 자격을 얻게 되고, 우리는 이를 적법한 아젠다(eligible agenda)라고 부른다.
2.2.3 합의
합의는 분산화된 네트워크에서 특정 아젠다를 블록에 포함시키고, 해당 블록을 확정함으로써 OO의 상태가 정해지는 과정을 말한다. 블록 제안자는 적법한 아젠다가 발생한 순간, 즉각적으로 해당 아젠다를 포함시킨 블록을 제안해야한다. 부득이하게 여러 개의 적법한 아젠다들이 있는 경우, 이들 중에서 하나를 골라서 블록에 포함시킨다. 보통은 가장 먼저 적법한 아젠다가 된 것을 포함시키는 것이 일반적일 것이다. 이때 아젠다들끼리의 연관성이 있을 때 벌어지는 문제들 때문에, 블록에는 오직 하나의 아젠다만 포함시킬 수 있다.
블록 제안자는 아젠다를 제외하고, 거버넌스를 통한 의결이 필요로 하지 않는 몇 가지 정보들을 블록에 포함시킬 수 있다.
블록 제안자는 특정 아젠다가 적법한 아젠다가 되는 순간의 챗 체인을 semifnalize하고, 이를 블록에 포함시킬 수 있다.
이전 라운드의 블록 제안자가 악의적인 행동을 할시에 이를 고발할 수 있고, 이는 해당 검증자의 슬래싱으로 이어진다.
특정 멤버의 투표권에 대한 위임, 혹은 재위임을 할 수 있다. 이는 해당 멤버의 서명을 필요로 한다.
2.2.4 유저 플로우
종합해보자면, Simperby chain을 사용하는 OO의 멤버들은 다음과 같은 과정을 거치게 된다.
OO의 멤버 중 누군가가 새로운 아젠다를 제안한다.
멤버들은 새롭게 제안된 아젠다에 대해서 P2P 네트워크를 통해서 채팅과 투표를 이어간다.
아젠다가 충분한 멤버들의 동의를 얻게 되면, 해당 아젠다는 적법한 아젠다가 되고, 해당 라운드의 블록 제안자는 해당 챗 체인을 semifinalize하여서 체크포인트를 만들어놓는다.
블록 제안자는 해당 적법한 아젠다를 포함하는 새로운 블록을 제안한다.
OO의 검증자들은 합의 과정을 거쳐서 해당 블록에 대한 합의를 이룬다.
새로운 블록에 포함된 아젠다의 종류에 따라서 다르게 실행된다. 아젠다의 종류는 해당 OO의 거버넌스 파라미터를 수정하는 것부터, 특정 멤버의 악의적인 행동에 대한 고발, 다른 체인의 트레져리 사용 등 다양하다.
3. 합의 메커니즘 살펴보기
3.1 동기
앞서 얘기한 것과 같이 Simperby가 self-hosted의 가치를 실현하기 위해선 OO에 포함된 개인들이 각각 노드를 운영할 수 있어야 하고, 그러기 위해선 노드 운영이 간단하고, 리소스적으로 부담이 없어야 한다.
3.1.1 필요할 때만 온라인
Simperby chain의 검증자들은 항상 온라인일 필요 없이, 채팅이나 아젠다 투표과정, 혹은 합의 과정에 참여하는 것과 같이 필요할때만 온라인이면 된다. 일반적인 블록체인이라면, 멈추지 않고, 블록을 계속 생성해야하기 때문에, 24/7의 uptime을 가져가야 하지만, Simperby chain의 경우, permissioned set에 의한 거버넌스 안건만 처리하기 때문에, 항상 블록을 생성하는 것이 아니라, 필요할 때만(on-demand) 블록을 생성하여서 문제가 발생하지 않는다. 다만, 이를 위해선 각 라운드의 타임아웃이 충분히 길어서(ex: 2주) 모든 노드들이 타임아웃 전에 등장할 수 있도록 해야한다.
3.1.2 누가 블록을 제안할 것인가?
일반 검증자와 달리 블록 제안자들은 상대적으로 더 높은 업타임을 가져가야하는데, 이는 블록 제안자가 계속해서 챗 체인을 모니터하면서 semifinalize해주고, 적법한 아젠다가 생성되었을 때 이를 포함한 블록을 제안해야하기 때문이다. 이러한 부담을 모든 검증자들이 아닌, 소수의 검증자들에게 예측 가능하게 부여하기 위해서 Simperby는 leader-based와 stable leader 방식을 사용한다.
Leader-based: Leaderless와 달리 아무나 블록을 제안할 수 없고, Round Robin 방식과 같이 누가 언제 블록을 제안할지가 결정론적(deterministic)하게 정해져있다. 해당 방식의 장점은 커뮤니케이션 비용이 줄어드는 효율적 방식이라는 것이지만, 단점은 DOS 공격이나 해당 블록 제안자가 악의적일 경우에 성능이 크게 떨어질 수 있다는 것이다.
Stable-leader: 명시적으로 블록 제안자를 교체하지 않는 한, 기존 블록 제안자가 계속해서 이어가는 방식이다. 해당 방식은 현실적으로 모든 멤버들이 블록 제안자를 하기에 적합한 환경이 아닐 수 있다는 사실을 반영하여서 몇몇의 멤버들에게 조금 더 많은 책임과 권한을 부여한다. 또한, Stable leader 방식을 통하여 각 검증자들은 stable leader 리스트에 따라서 언제 자신이 블록 제안자의 역할을 맡게 될지 쉽게 예측할 수 있다.
3.1.3 부작용
Simerby는 Leader-based, 그리고 stable-leader 방식을 사용하기 때문에, 자체적으로 현재 블록 제안자가 성실하게 자신의 책임과 권한을 수행하지 않았을 때, 이를 교체할 수 있는 메커니즘을 필요로 한다. 사실 일반적인 Tendermint에서는 그냥 라운드가 끝나길 기다리면 되지만, Simperby의 경우, 라운드 시간이 엄청나게 길기 때문에 마냥 라운드가 끝나기를 기다리면, 사용성이 너무 떨어진다.
또한, 블록 제안자의 악의적인 행동 중에서는 pogrammable slashing이 불가능한 케이스들도 많다. 예를 들어, 일부러 특정 적법한 아젠다를 블록에 포함시키지 않거나, 적법한 아젠다가 있어도 일부로 블록을 생성하지 않는 경우는 전부 악의적인 행동에 포함되지만, 이를 코드 단에서 인식할 수가 없다.
이를 해결하기 위하여 Simperby 팀은 Tendermint를 변형한 Simperby 만의 고유한 합의 메커니즘인 Vetomint를 고안해내었다. Vetomint의 핵심은 Simperby chain의 검증자들이 합의 과정 중에 현 블록 제안자가 성실하지 않을 경우, 투표를 통해서 이를 거부(veto), 혹은 교체할 수 있다는 것이다.
3.2 Vetomint
앞서 언급한 것처럼, Vetomint는 기존의 Tendermint를 Simperby만의 특수한 환경에 맞춰서 변형한 형태이다. Vetomint가 Tendermint가 가지는 주요 차이점은 다음과 같다.
3.2.1 라운드가 끝나기전에 Nil Prevotes 행사 가능
기존에 Tendermint에서는 검증자들이 블록 제안자가 시간 내에 블록을 제안하지 못할 경우, nil prevote를 행사한다. 이와 달리, Vetomint에서는 검증자들이 해당 라운드의 타임아웃이 끝나기 전에 nil prevote를 행사할 수 있다. 검증자들은 만약 현재 리더가 제대로 행동하지 않다고 생각되면, nil prevote를 행사하면 되고, 이는 블록 제안자가 실제로 블록을 제안했는지 여부와는 무관하게 행사할 수 있다. Vetomint는 Tendermint와 마찬가지로 전체 검증자 집합의 2/3을 초과하는 nil prevote들이 모일 경우, 새로운 리더와 함께 다음 라운드로 넘어간다.
3.2.2 Early Termination
기존에 Tendermint에서는 2/3을 초과하는 non-nil prevote들이 모일 경우, precommit 단계로 넘어간다. 이와 달리, Vetomint에서는 검증자가 nil인지, non-nil인지 여부와 관계 없이 전체 검증자 집합의 5/6을 초과하는 prevote들 모으는 경우, 해당 표들을 바탕으로 precommit 단계를 진행한다.
이렇게 설계한 이유는 Simperby의 경우, 각 라운드들의 타임아웃이 매우 길고, 검증자들이 주관적으로 nil prevotes를 행사할 수 있기 때문이다. 예를 들어, 전체 검증자 중에서 반은 non-nil prevotes를, 나머지는 nil prevote를 행사한 경우, 기존의 Tendermint를 그대로 사용하면, 2/3을 초과하는 non-nil prevote들이 모이지 않았기 때문에, precommit으로 넘어갈 수 없고, 긴 타임아웃을 기다리는 수 밖에 없다. 따라서, Vetomint의 경우, 특정 검증자에게 전체의 5/6을 초과하는 prevote들이 모였다면, 해당 시점에서 non-nil prevotes가 전체 pre-votes의 2/3을 초과하는지 확인하고, 그럴 경우에만 non-nil precommit을 전파한다.
Tendermint의 경우, 한 라운드의 타임아웃이 짧고, 정직한(non-byzantine) 노드들끼리는 non-nil prevote인지, nil prevote인지 여부다 다를 수가 없기 때문에 Vetomint와 같은 문제가 발생하지 않는다.
3.2.3 그렇다면 왜 하필 5/6일까?
앞서 살펴본 5/6을 우리는 early termination을 실행하기 위한 임계값, 즉 early termination threshold라고 부른다. 왜 early termination threshold 값을 5/6로 설정하였을까?
일단 왜 2/3이 안되는지부터 알아보자. 만약 early termination threshold가 2/3이라면, 정상적인 상황에서 한 명의 비잔틴 노드라도 일부러 non-nil prevotes를 행사하면, 이를 받은 검증자들은 다음 단계로 넘어갈 수가 없게 된다.
Early termination threshold을 ‘x’라고 하였을 때, 비잔틴 노드의 임계값인 byzantine threshold 값이 '1-x'보다 크면, 비잔틴 노드들은 prevote를 하지 않아도 다음 단계로 진행을 방해할 수 있다. 이러한 이유로, byzantine threshold는 '1-x'보다 작거나 같아야만 한다. 우리의 목적은 2/3 초과의 non-nil prevotes가 있을 때, 비잔틴 노드들의 행동에 영향받지 않고 precommit 단계로 진행하는 것이다. 따라서, x는 다음과 같은 등식을 만족하여야 한다.
x - (1-x) ≥ 2/3, x ≥ 5/6
x개의 prevote들 중에서 비잔틴 노드들의 표는 1-x보다 작을 수 밖에 없고, 정직 노드들의 표는 최소한 전체의 2/3을 넘겨야 한다. 따라서, 가능한 x의 최소 값은 5/6이 된다. 즉, Vetomint는 기존의 Tendermint와 같이 1/3 미만의 비잔티 노드가 있을 때 safety가 보장되고, 1/6 미만의 비잔틴 노드가 있는 경우에 liveness가 보장된다.
4. 멀티체인
Simperby의 Standalone, Sovereign, Self-hosted라는 특징 덕분에 Simperby는 여러 체인으로 확장하려는 OO들에게 굉장히 매력적인 거버넌스 툴이다.
미래에는 대부분의 OO들이 멀티체인 OO의 형태를 가질 것으로 예상된다. 일단 리스크 분산의 측면에서도 하나의 체인에 종속되는 것보다는, 다양한 체인에 존재하는 트레져리에 자금을 보유하는 것이 훨씬 안전하다. dApp을 다스리는 OO들의 경우에는 새로운 체인에 자신의 dApp을 확장해나갈때, 한번에 여러 체인에 거버넌스 결정을 적용하기 위해서는 멀티체인 OO의 형태를 가질 수 밖에 없다. 이에 대한 가장 대표적인 예시가 바로 Uniswap V3이다. 새롭게 BNB 체인으로 확장한 Uniswap은 이더리움 체인에서 진행되고 있는 Uniswap DAO의 거버넌스 결정을 BNB 체인으로 전달하기 위한 써드 파티 브릿지를 골라야 했고, 여러 과정들을 거쳐서 결국 Wormhole이 선정되었다.
Simperby는 라이트 클라이언트 방식을 통하여 멀티체인 OO들이 trust-minimized하게 Settlement chain으로 메시지를 전달할 수 있도록 한다. Settlement chain에 존재하는 Simperby의 라이트 클라이언트는 새로운 헤더가 Simperby chain에서 실제로 finalized될 때만 업데이트하고, 이는 헤더가 전체 검증자 집합의 2/3을 초과하는 pre-commit을 가졌는지로 확인한다. 라이트 클라이언트는 이 헤더 내의 머클 루트와 함께 풀 노드로부터 받은 머클 증명을 통해서 특정 트랜젝션이 실제로 블록에 포함되었는지 확인할 수 있다.
예를 들어, 특정 OO의 Simperby chain에서 해당 OO의 이더리움 체인의 트레져리에서 3 ETH를 출금하는 아젠다를 블록에 포함시켰다고 하자. 이때 이더리움 체인에 스마트 컨트랙트 형태로 존재하는 라이트 클라이언트를 통해서 Simperby chain의 검증자들의 서명을 확인하고, trust-minimized된 방식으로 필요한 트랜젝션을 실행할 수 있다.
Source: Simperby Deck
Simperby chain은 오직 거버넌스와 관련된 의사결정만 진행하고, Settlement chain에서 지시한 사항이 일어났는지는 OO의 멤버들이 직접 확인하면 되기 때문에, 체인 간 연결은 Simperby chain에서 Settlement chain으로의 일방향이기만 하면 된다. 따라서, Simperby를 사용하는 OO들은 언제나 원하면 특정 체인에 연결되었다가, 또 다른 체인으로 떠날 수 있는 극강의 자유도를 가지게 된다.
5. Git 기반의 데이터 저장공간
Simperby는 거버넌스를 위한 블록체인이기도 하지만, 구글 드라이브와 같은 분산 파일 저장소의 역할도 함께 수행할 수 있다. Simperby의 모든 finalized된 데이터(아젠다, 채팅, 블록)들은 깃 레포지토리의 ‘finalized’ 브랜치에 저장된다. 각 Simperby chain의 노드들은 각자의 깃 레포지토리를 운영하고, ‘git fetch’ 를 통해서 다른 노드들의 데이터를 읽어와서 검증하거나, 동기화할 수 있다.
Simperby와 깃은 흥미로운 일대일 대응 관계를 가지고 있다. 예를 들어, 아젠다는 ‘git commit’, 블록 제안은 ‘git branch’, 블록 확정은 ‘git rebase’ 등의 상관관계를 가지고 있다. 이러한 사실 덕분에 Simperby는 단순한 거버넌스 툴을 넘어서서, OO들을 위한 분산 파일 저장소로 기존의 깃 생태계의 써드 파티 도구들과도 좋은 시너지를 낼 수 있다.
6. 마무리하며
이렇듯 Simperby는 분명 기존의 OO 프레임워크들과는 사뭇 다르다. 거버넌스를 위한 체인을 만들고, 이를 OO 멤버들이 직접 노드를 운영할 수 있도록 자체적인 합의 메커니즘을 만들어냈다는 것부터 심상치 않은데, Simperby를 단순히 거버넌스만을 위한 것이 아니라, Git을 통한 분산 데이터 저장소로 쓸 수 있다는 것 역시 매우 흥미롭다. 현재 이미 Simperby를 개발한 오픈소스 재단인 PDAO는 SImperby를 통해 운영되고 있고, 앞으로도 여러 크고, 작은 조직들이 Simperby를 통해서 의사결정을 할 예정이다.
기존의 온체인 거버넌스에 익숙한 사람들에게는 Simperby가 처음은 어색할 수 있겠지만, 오히려 블록체인을 처음 접하는 현실의 조직 및 단체들에게는 가스비를 신경쓰지 않아도 되고, 이더리움과 같은 기존 블록체인의 사용법을 몰라도 된다는 점에서 Simperby가 가장 매력적인 OO 프레임워크가 될 수 있다고 생각한다.
7. 출처
이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.
