Token Model Simulation #1 바보들의 합의 Part 1
Token Model Simulation
#0 Why Simulation?
#1 바보들의 합의 Part 1: 바보들의 합의 문제 및 시뮬레이션 환경 소개
#1 바보들의 합의 Part 2: 시뮬레이션 결과 분석
이전 글, ‘Token Model Simulation #0 : Why Simulation?’에서 토큰 모델 설계 과정에서 시뮬레이션이 왜 필요할 지에 대해서 알아보았습니다. 디콘에서는 토큰 설계를 위한 시뮬레이션 시스템 연구를 하고 있는데, 앞으로 글을 통해서 저희가 진행하는 강화학습 에이전트 기반 시뮬레이션(Reinforcement Agent Based Simulation) 분석에 대해 소개하겠습니다.
디콘 시뮬레이션 시리즈의 첫번째 주제는 “바보들의 합의” 문제입니다. 시뮬레이션 분석에 들어가기 전에 “바보들의 합의”가 무엇인지와 블록체인에서 이 문제가 발생할 수 있는 이유 등의 배경에 대해 파악하셔야 합니다. 그리고 나서 시뮬레이션 환경에 대해 설명드리겠습니다.
“바보들의 합의” 문제와 시뮬레이션 목표
오라클의 중요성
스마트 컨트랙트를 기반으로 운영되는 서비스에서는 블록체인 외부 정보를 관찰하고 이를 블록체인에 입력해줄 주체가 필요합니다. 이 역할을 해주는 주체를 보통 오라클이라고 합니다. 오라클이 가져온 외부 정보는 블록체인과 외부 세계를 연결해주는 다리 역할을 해주기 때문에 블록체인 서비스 운영에 있어 핵심이 됩니다.
하지만 블록체인 내부에서 일어난 트랜잭션과는 다르게 오라클이 가져온 외부 정보에 대해서는 블록체인을 통해 사실 여부를 검증하지 못합니다. 그렇다고 해서 서비스 내에 운영 기관을 두고 외부 정보에 대해 검증하게 하는 것은 서비스 탈중앙화의 의미를 퇴색시킬 수 있습니다. 이러한 이유로 외부 정보의 진위성은 블록체인의 무결성과는 별개로 블록체인 서비스 입장에서 취약점이 될 수 있으며, 서비스의 정상적인 운영에 큰 위협이 되기도 합니다.
따라서 매커니즘적인 설계를 통해 블록체인 서비스가 오라클이 외부 정보를 제대로 가져오도록 하는 것은 매우 중요합니다. 이 문제를 오라클 문제라고 하겠습니다.
오라클 메커니즘의 전제 : “과반수가 동의하면 진실이다”
대부분의 서비스에서는 참여자들의 투표를 통해서 오라클 문제를 해결하려고 합니다. 투표는 주로 토큰을 기반으로 진행됩니다. 투표자들은 자신이 옳다고 생각하는 정보에 토큰을 예치함으로써 투표를 하고 스마트 컨트랙트는 더 많은 토큰을 받은 정보를 옳은 외부 정보라고 결정합니다.
이러한 오라클 메커니즘들은 다수의 합의를 통해 외부 데이터의 진위 여부를 판단하고 있으며, “과반수가 선택한 것이 진실이다”라는 전제에 근거하고 있습니다.
“과반수가 동의하면 진실이다”라는 전제가 틀릴 수 있는 경우
투표 메커니즘들이 사용하고 있는 “과반수가 동의하면 진실이다”라는 전제는 취약점을 가지고 있습니다. 바로 몇몇 상황에서는 과반수의 선택이 정보의 옳음을 보장해주지 못한다는 겁니다.
먼저, 투표율이 낮을 때에는 과반수의 선택이 크게 의미가 없습니다. 왜냐하면 투표율이 낮을 때에는 적은 비용으로도 투표 결과를 좌지우지할 수 있기 때문입니다. 예를 들어 1000명이 참가하는 투표에서는 투표를 조작하기 위해서는 100명 단위의 사람이 필요합니다. 하지만 10명이 참가하는 투표에서는 3, 4명의 담합으로도 투표 결과를 쉽게 조작할 수 있습니다.
투표율이 높더라도 투표 참가자들이 심사숙고하지 않고 아무렇게나 투표를 할 때에도 투표 결과의 정확도를 보장하기가 힘듭니다. 만약 반장 투표, 대통령 선거에서 대다수의 투표자들이 각 후보에 대해서 조사하지 않고 투표한다면 학급과 나라에서 정말로 필요로 하는 후보가 당선되기 힘들겁니다. 진실에 대한 투표도 마찬가지입니다. 다수의 참가자들이 외부 정보의 진위 여부를 심사숙고하지 않고 아무렇게나 블록체인에 입력한다면 이 정보의 진위성을 확신하기 힘들기 때문입니다.
실제로 많은 블록체인 프로젝트에서 위의 두 상황을 막기 위해 여러 메커니즘들을 도입하고 있습니다. 이번 시뮬레이션에서는 두번째 상황을 막기 위해 도입할 수 있는 여러 메커니즘들과 그 결과를 분석해보려 합니다.
“바보들의 합의” (Fools’ Agreement)
참여자들이 아무렇게나 투표하여서 외부 정보에 대한 투표가 잘못된 결과를 배출하는 상황을 바보들의 합의라고 부르겠습니다. 그럼 실제 서비스에서 바보들의 합의 문제가 왜 발생할 수 있는지 알아보겠습니다.
이상적으로 오라클 정보에 대한 투표가 제대로 작동하기 위해서는 모든 투표자들이 투표가 다루는 정보에 대해서 조사를 해본 후에 투표를 하는 것이 가장 좋습니다. 하지만 투표자들의 조사는 어떠한 형태로든 연구 비용을 수반합니다. 이러한 비용은 정보 검색에 드는 시간과 노력이 될 수도 있고 정보 검색에 드는 금전적인 비용이 될 수도 있습니다. 연구 비용에도 불구하고 투표 메커니즘들은 오라클 각 투표자들이 투표에 따른 처벌/보상과 같은 경제적인 유인에 의해 조사를 한 후 제대로 된 투표를 할 것이라고 가정하고 있습니다.
하지만 각 참여자들이 연구 비용을 들이지 않고 대충 투표를 하고도 보상을 받을 수 있거나, 연구를 하고 제대로 투표를 했음에도 보상을 제대로 받지 못하는 상황이 생긴다면 이야기는 달라집니다. 여기서는 많은 참가자들이 조사를 하지 않으려고 할 것이고, 아무렇게나 투표를 하는 참여자들이 많아질 것니다. 이후의 투표들은 말 그대로 바보들의 합의가 되어서 투표 결과의 진위성이 떨어질 겁니다. 결국 잘못된 투표로 인해 잘못된 외부 정보가 입력되는 상황이 빈번해지고 이는 서비스에 치명적인 영향을 줄 겁니다.
시뮬레이션 목표 : “바보들의 합의” 해결 메커니즘 분석
“바보들의 합의” 문제를 막기 위한 메커니즘에서는 서비스 참여자 중에서 조사를 한 후 투표를 하는 참여자의 비율을 최대한 높이는 것이 초점이 됩니다. 그리고 이를 통해 참여자들의 투표가 외부 정보의 사실 여부를 최대한 잘 반영하도록 하는 것이 목표가 됩니다.
각 메커니즘의 유효성을 판단하기 위하여 시뮬레이션에 기반한 분석을 하였습니다. 분석의 초점으로는 메커니즘마다 참여자들의 research rate이 어떻게 변화하는지, 메커니즘마다 오라클이 옳은 결과를 잘 만들어 내는지를 보았습니다. 더 나아가 각 메커니즘이 잘 작동하지 않는다면 왜 메커니즘이 실패했는지와 잘 작동한 메커니즘에 대해서는 왜 이 메커니즘이 성공적으로 작동했는지에 대해서도 시뮬레이션을 통해 살펴보았습니다.
시뮬레이션 환경 세팅
시뮬레이션 결과 분석에 앞서 시뮬레이션 환경에 대해 설명드리겠습니다. 저희가 설정한 세팅에 대해서 의견이 있다면 피드백을 주셔도 좋고 저희 세팅대로 구현하고 실험해봄으로써 저희 분석의 유효성에 대해서 검증해보셔도 좋을 것 같습니다.
환경 내에서 가능한 투표 결과
시뮬레이션 환경 내에서 투표 결과는 최대한 간략화 시켜서 True/False만 나오도록 하였습니다. True와 False의 의미는 다음과 같습니다.
- True : 사실에 부합하는 정보가 투표 결과로 선택된 경우
- False : 사실과 부합하지 않는 거짓 정보가 투표 결과로 선택된 경우
환경 설정과 관련한 변수
환경 설정과 관련한 변수는 Objectivity, 연구비용, Lockup Period 가 있습니다.
Objectivity는 정보 판단의 난이도로 생각하시면 됩니다. 오라클이 다루고 있는 정보 판단의 난이도가 높아진다면 많은 서비스 참여자들이 research를 했음에도 옳은 정보를 판단해내지 못하게 될 겁니다. 예를 들어 objectivity가 0.9라면 research를 한 투표자도 10%의 확률로 False에 투표하게 됩니다.
연구 비용은 어떤 에이전트가 research를 한 후 투표를 할 때 이 에이전트에게 발생하는 비용을 말합니다. 연구 비용은 에이전트들의 토큰 변화량에는 영향을 안 주지만 학습하는 정도에 영향을 줍니다.
투표에서 이긴 에이전트는 토큰 보상을 바로 받는 것이 아니라 Lockup Period만큼 지난 이후에 자신이 투표할 때 예치했던 토큰과 보상 토큰을 받게 됩니다. 실제 서비스에서도 오라클 투표가 지난 후 일정 기간이 지난 이후에 토큰이 참여자들에게 배분되는 경우가 많은데 이를 반영하였습니다.
에이전트 수는 말 그대로 시뮬레이션 환경 속에서 투표에 참여하는 에이전트 수를 의미합니다.
위의 변수들은 다음과 같은 값으로 설정하고 시뮬레이션을 진행하였습니다.
- Objectivity : 0.8
- 연구 비용: 50
- Lockup Period : 3
- 에이전트 수 : 30명
에이전트 설명
강화 학습에서 에이전트는 환경 내에서 행동을 하고 이에 수반되는 보상/처벌를 기반으로 학습을 해나가는 주체를 말합니다. 저희는 시뮬레이션 내의 각 에이전트들을 오라클에 대해서 투표를 하고 그 보상/처벌에 따라 행동 경향을 학습해나가는 강화 학습 에이전트로 설정하였습니다.
에이전트들은 다음의 두가지 행동 선택지를 가지고 있습니다.
- Random Vote : 무작위 투표. 에이전트는 50 : 50의 확률로 True와 False를 선택하게 됩니다
- Research : 조사를 한 후 투표. objectivity : 1-objectivity의 확률로 True와 False를 선택하게 됩니다
모든 에이전트들은 자신의 토큰 보유량을 최대화 시키는 걸 목적으로 학습해나가도록 설정해두었고, Multi-armed Bandit을 학습 알고리즘으로 사용하였습니다. 에이전트들은 Multi-armed Bandit 알고리즘에 따라 위의 두 행동 선택지에 대한 기대 수익을 업데이트하고, 다음 투표에서는 이 업데이트된 기대 수익에 따라 투표를 합니다.
토큰과 관련된 환경 설정(초기 분배, 투표에 예치하는 토큰량)
토큰 초기 분배는 최대한 실제 토큰 분배를 반영하기 위해서 AUGUR 토큰 분배 현황을 참고하였습니다. AUGUR 토큰 보유자 중 상위 1000명의 토큰 보유 비율에서 상위 50 계정 정도는 거래소 계정이라 판단하여 제외한 후, 나머지 950명의 토큰 보유 비율에서 에이전트 수만큼 랜덤하게 뽑아서 각 에이전트에게 토큰을 분배하였습니다.
에이전트들이 투표에 예치하는 토큰량은 가지고 있는 토큰에서 매 투표마다 0.5를 평균으로 하는 가우시안 분포에서 뽑은 값만큼 예치하도록 설정하였습니다.
시뮬레이션 시간축(episode, timestep)과 데이터 도출
저희 세팅에서 하나의 시뮬레이션은 300개의 episodes로 이루어져있고 각 에피소드는 50 timesteps으로 구성됩니다. Episode와 timestep의 개념을 정확히 파악하는 것은 저희 시뮬레이션 데이터와 자료를 분석하고 여기서 의미를 도출해내는데 매우 중요하기 때문에 episode와 timestep에 대해서 정확히 이해하셔야 합니다.
Timestep은 시뮬레이션의 최소 기본 단위입니다. Timestep을 각각의 오라클 투표라고 생각하시면 이해하기 좀 더 쉬울 겁니다. 그래서 매 timestep마다 에이전트들은 외부 정보에 대해서 투표를 하고 투표 결과에 따라 토큰 보상/처벌을 받고 이를 기반으로 학습을 합니다. 즉, 매 timestep마다 에이전트들의 토큰 보유량이 변화하고 행동 양식도 바뀝니다.
Episode는 에이전트들이 학습을 하는 일련의 timestep 묶음입니다. episode마다 에이전트들이 가지고 있는 토큰은 초기화 되고 에이전트들은 이전에 학습한 결과에 이어서 계속해서 학습을 해나가게 됩니다. 에이전트들의 학습 경향성과 이에 따른 오라클 시장의 경향성 변화 등의 정보는 주로 episode를 단위로 분석하였습니다.
다음 글에서 설명할 시뮬레이션 결과의 자료들은 위에서 설명한 timestep과 episode로 이루어진 시뮬레이션을 50번씩 반복하여 얻은 결과를 통계화하여 생성하였습니다.
마무리
이번 글에서는 시뮬레이션을 통해 분석하려는 “바보들의 합의” 문제에 대해서 설명을 드렸고, 저희가 설정한 시뮬레이션 환경에 대해서도 간략하게 소개를 드렸습니다. 다음 글에서는 시뮬레이션 결과에 대한 분석이 다루어집니다.
