트루빗 편집하기

[[파일:트루빗 로고.png|썸네일|200픽셀|'''트루빗'''(Truebit) 로고]]
[[파일:트루빗 글자.png|썸네일|300픽셀|'''트루빗'''(Truebit) 로고와 글자]]

'''트루빗'''<!--트루비트-->(Truebit)<!--True bit-->은 [[이더리움]]의 연산 성능을 올리기 위한 [[오프체인 솔루션]]이다.<ref>도예리 기자, 〈[https://decenter.sedaily.com/NewsView/1VJ8NP79S8  서울대 연구원이 말하는 이더리움 연산력 한계 극복하기]〉, 《디센터》, 2019-05-22</ref>

==개요==
최근 다양하게 제시되고 있는 확장성 솔루션들은 메인체인의 트랜잭션 처리성능을 개선하여 TPS를 높이는데 중점을 둔 경우가 많다. 샤딩이나 플라즈마 등 많은 솔루션들이 이에 해당한다. 이에 반해 트루빗은 이더리움의 TPS가 아닌, 이더리움에서 처리할 수 있는 연산 성능의 한계를 극복하기 위해 등장한 확장성 오프체인 솔루션이다. 

;배경
이더리움에서 프로그램을 실행하기 위해서는 복잡도가 높아질수록 수수료가 증가하게 되는데 한 블록 안에 담길 수 있는 가스의 양이 제한되어 있다. 또한, 많은 연산 작업을 필요로 하기 때문에 블록 당 처리 가능한 연산에도 한계가 있다. 이로 인해 이더리움의 연산 성능 문제가 지속적으로 제기되어 왔다. <ref> 강민승 기자,〈[https://www.mk.co.kr/news/economy/view/2019/07/502822/  도지더리움으로 보는 인터체인의 역사1 - 도지더리움의 탄생]〉,《매일경제》2019-07-11</ref>

;검증자의 딜레마
이더리움 채굴자는 다음 블록 채굴을 시작하기 전, 새로운 블록이 정확한 블록인지 검증할 필요가 있다. 하지만 해당 검증에 대해서 보상(수수료)은 받지 못한다. 그렇다고 해서 검증을 하지 않고 바로 그 위에 블록을 붙였다가는 잘못된 체인에 시간만 낭비하는 셈이 될 수 있다. 그렇기 때문에 검증할지, 건너뛸지에 대한 두 가지 상반된 행위 사이에서 고민하게 되는데 블록 가스 제한이 늘어날수록 심해지는 양상을 나타낸다. 

블록체인의 확장성 문제를 해결하는 방법에는 크게 [[온체인 솔루션]]과 [[오프체인 솔루션]]으로 나눌 수 있다. 온체인 솔루션은 블록체인 상에서 확장성 문제를 해결하는 것으로 거래 처리 속도나 용량을 늘리는 등 처리 방식의 효율화를 의미하며, 오프체인 솔루션은 블록체인 외부에서 거래를 처리하여 네트워크가 효율적으로 돌아가는 것을 의미한다. <ref name="트루빗"> 트루빗- https://medium.com/decipher-media/truebit-681181846d93 </ref>

==기술==
;원리
DApp이 블록 가스제한보다 많은 가스가 소모되는 연산을 수행하고 싶을 때, 트루빗 프로토콜로 넘긴 다음 트루빗 네트워크 참여자들이 복잡한 연산을 대신 수행하고 결과값만을 전달하여 온체인에 다시 반영하는 형태이다. 

;Solver(문제를 푸는 채굴자)
스마트 컨트랙트에 보증금(토큰)을 예치하고 연산을 처리한다. 연산을 올바르게 처리했을 경우 예치해 두었던 보증금과 보상을 받는다.

;Solver의 답이 틀렸다고 판단될 경우 
Challenger가 보증금을 예치하고 Solver의 답에 이의를 제기한다. 이후 검증 게임을 실시한다. (Solver와 Challenger의 결과가 다르게 나타나는 부분만 검증한다.)

Solver의 연산이 틀리면 Solver의 보증금에서 삭감되며, Solver의 연산이 맞으면 검증 게임에 발생된 비용을 Challenger의 보증금에서 삭감한다. 

===트루빗 컨트랙트===
[[파일:트루빗1.png|450픽셀|오른쪽|'''트루빗 컨트랙트'''(Truebit Contracts)]]

;[[아라곤]](Aragon) 예시

[[온체인]]에서 투표 결과를 집계하는 연산처리는 비싸고 블록 가스 제한도 초과하므로 트루빗 프로토콜로 넘긴다.
DApp과 트루빗 프로토콜이 상호작용하기 위한 API이다. 트루빗 스마트 컨트랙트 안에는 createTask라는 함수가 있다. DApp은 createTask함수를 호출할 때 아래의 3가지 변수를 전달한다. 

* '''Program'''
실행하고 싶은 코드. 트루빗은 WebAssembly VM코드를 사용한다. DApp은 bytecode를 넘길 수 있고, IPFS 해시값이나 코드가 저장된 다른 콘텐츠 주소로 전달할 수 있다.

* '''Input'''
실행할 프로그램의 입력 값이다.
DApp은 input값을 직접 제공하거나 input값이 저장된 다른 콘텐츠 주소로 전달할 수 있다.

* '''Reward''' 
프로그램을 실행한 사람에게 지급할 보상

트루빗 클라이언트를 설치한 사람 누구나 트루빗 네트워크의 채굴자가 될 수 있으며, 이들은 트루빗 컨트랙트의 이벤트를 주시한다.

===트루빗 네트워크===
[[파일:트루빗3.png|450픽셀|오른쪽|'''트루빗 네트워크'''(Truebit Network)]]

트루빗 채굴자들은 새로운 Task가 생기면 코드를 다운로드하고, 제공된 입력값과 함께 Truebit WebAssembly VM을 로컬로 실행하여 결과값을 컨트랙트에 제출한다. 
(이 때, 문제를 푼 채굴자를 문제 해결자(Solver)라고 하고, 결과값을 제출할 때 일정량의 보증금도 함께 제출해야 한다. 보증금을 통해 자신이 올바른 결과값을 제출했다고 간주하는 것이다.)

;Challenge가 없을 경우 
문제 해결자가 결과 값을 제출한 시기부터 타이머가 시작된다. 타이머 동안 제출된 결과값을 검증하여 틀린 결과라고 생각된다면 누구나 챌린지를 다시 신청할 수 있다. 이 때, 챌린지를 신청한 검증자 역시 보증금을 함께 지불해야 한다. 또한, 타이머 동안 아무 챌린지도 제출되지 않았을 경우 문제 해결자가 올바르게 코드 연산을 수행했다고 생각할 것이다. 따라서 트루빗 컨트랙트가 DApp 컨트랙트로 해당 결과값을 다시 콜백하여 준다.

;Challenge가 있을 경우 
Challenger가 보증금을 걸고 challenge 제출 시, 트루빗 컨트랙트에는 ①Task Giver가 제시한 보상, ②문제 해결자(Solver)의 보증금, ③ Challenger (검증자)의 보증금이 예치되어 있다.

이제 문제 해결자와 챌린지를 제출한 검증자 사이에서 누구의 연산 결과값이 옳은지에 대한 검증게임이 시작된다. 

==검증게임==
트루빗에 처리하는 모든 task의 프로그램 코드는 웹어셈블리 프로그램이며, 웹어셈블리는 매 명령어들이 하나씩 순서대로 실행된다. (물론, 예외도 존재한다.) 결국 몇 번째 명령어를 실행할 때 서로의 연산 결과가 달라지기 시작했는지를 알아내고 이를 온체인에서 실행하여 누가 맞았는지를 확인하는 것이 게임의 요지이기 때문이다. 또한 검증게임에서는 세 분류의 참여자가 존재한다. 

;Solver(문제 해결자) 
task에 대한 연산을 수행하고 결과값을 제출한 사람 
;챌린저 (challenger)
문제 해결자의 결과값이 틀렸음을 주장하는 사람
;Judges(판사)
제한된 능력을 지녔으며 결과값이 맞았는지 아닌지를 판단해줄 주체

현재 트루빗은 판사를 이더리움 네트워크로 설정하고 있다. (실제 이더리움 네트워크가 망가진다면, 언제든지 다른 네트워크로 옮길 수 있다고 말하고 있다.) 따라서 최종적으로 이더리움 네트워크는 연산 능력이 제한되어 있으므로 부담을 최소해야 한다. 

;실행
문제 해결자와 챌린저 모두 같은 프로그램 코드와 입력값을 다운로드 했으며

[[파일:검증1.png||600픽셀|]]
시작 일치(0번) : 해결자(Solver), 챌린저(Challenger) 모두 초기화된 VM을 부팅하고 같은 프로그램 입력값을 가진다.
마지막 불일치(14번) : 14개의 명령어로 구성되어 있다면 마지막인 14번째는 서로 다른 결과를 가질 것이다.  

[[파일:검증1.png||600픽셀|]]
챌린저는 중간지점인 7번째 명령어 실행 결과를 질문 (여러 번 시도하면 중간 지점부터 묻는 것이 가장 효율적)
해결자(Solver)는 트루빗 WebAssembly VM을 사용하여 7번째 해시값을 계산하여 응답한다.
(7번째 해시값: 7번 째 명령어 실행 시 스택, 메모리, 해결자(Solver)의 WebAssembly VM의 전체 상태에서 파생된 머클 루트)

챌린저(Challenger)는 자신의 머클 루트를 계산하여 Solver(해결자)의 값과 비교한다.
두 값이 같으면 8~14번째에서 불일치가 발생한다. (7번째까지의 결과는 일치하므로)
두 값이 다르면 1~7번째에서 불일치가 발생한다.  (중간값인 3 or 4번째부터 질문)
[[파일:검증1.png||600픽셀|]]

Solver(해결자)값 일치할 경우, 중간값인 10번째 명령어 실행 결과 질문 10번째도 같으면 다시 남은 구간의 중간값(12번째)을 찾아 질문한다.

결국 챌린저는 문제 해결자와의 불일치가 시작되는 지점을 찾아내기 위하여 이진 탐색(binary search)하므로 전체 프로그램이 n개의 명령어로 이루어져 있다면 총 O(log(n))만큼의 단계가 필요하다. 문제 해결자와 챌린저 사이의 불일치가 시작되는 지점인 상태다.

그러면 온체인에서 해당 연산을 어떻게 수행하고 검증할까?  트루빗 스마트 컨트랙트에는 웸어셈블리 인터프리터가 내장되어 있다. 해당 가상머신을 13번째 명령어를 시작하기 직전 상태로 초기화한 후에 13번째 명령어에 해당하는 연산을 수행한다. 그 다음 스택, 메모리, 가상머신 상태에 대해 똑같이 머클 루트를 계산하고 이를 Solver(문제 해결자)의 머클 루트와 비교한다. 만약, 그 값이 서로 다르다면 문제 해결자의 연산이 틀렸다는 뜻으로 연산 보유자의 뜻으로 Solver(문제 해결자)의 보증금을 삭감함으로써 검증 게임을 마무리한다.

트루빗은 전체 연산을 오프체으로 수행하고, 연산 결과에 대해 논쟁이 발생했을 때, 단일 지점에 대한 연산만을 이더리움 온체인에서 수행하도록 설계하였다. 트루빗 재단은 이러한 트루빗 프로토콜의 합의 메카니즘이 과반수가 정직해야 하는 나카모토 컨센서스나 3분의 2이상이 정직해야 하는 BFT 합의 알고리즘보다 강력하다고 주장한다. 그 이유는 1명의 정직한 검증자만 존재한다면 적어도 틀린 연산 결과가 제출될 일은 없기 때문이다. 하지만 이러한 설계 의도대로 네트워크가 움직이기 위해서는 여러 경제적인 요인에 대한 고민이 필요하다. 검증자가 항상 문제 해결자의 답안 제출을 검증해야 할 요인, 위험을 감수하도 검증자가 아닌 문제 해결자로 활동할 요인, 검증자와 문제 해결자 사이의 역할 분배 등의 설계가 필요하다.

==인센티브 구조==
먼저, 검증자들이 항상 문제 해결자들이 제출한 답안을 검증할 요인이 필요하다. 검증자들이 잘못된 답안을 찾아낼 때만 보상을 받는다고 가정하면 네트워크의 균형을 유지하기가 힘들다. 문제 해결자가 틀린 답을 내면 검증자들의 기대 수익이 높아지기 때문에 검증자들이 유입될 것이다. 검증자들이 많아질수록 문제해결자들은 잘못된 답안을 제출하지 않으려 할 것이며, 이는 다시 검증자들이 이탈한다면, 다시 문제 해결자들은 잘못된 답안을 제출할 수 있다. 간단히 말해 네트워크가 균형을 유지하지 않을 가능성이 높다. 이를 해결하기 위해 트루빗은 [[강제 오류와 잭팟]](forced error and jackpot)이라는 개념을 도입하였다.

==전망==

{{각주}}

==같이 보기==
* [[블록체인]]
* [[트랜잭션]]
* [[이더리움]]
* [[확장성]]
* [[오프체인]]
* [[DApp]]
* [[스마트 컨트랙트]]

{{블록체인 기술|검토 필요}}