Service&Tech

미시경제에 대한 이야기: 이더리움&내부 원장이전 기사에서 언급된 바와 같이, 쿠엔데는 이더리움 블록체인과 내부원장이 혼합된 형대의 쿠엔데만의 미시 경제를 발전시키기로 결정했다. 본 연재 기사에서 우리는 우리만의 경제의 메카니즘을 살펴볼 것이며, 입출금부터 창출, 큐레이션, 참여 등 실행 가능한 모든 측면에서의 이의를 제기하고자 한다. 사용자들은 우리의 내부장부과 자신들이 개별적으로 사용하고 있는 스마트 컨트랙트를 통해 상호작용을 하게 된다. 이 컨트랙트는 유저들이 원하는 만큼의 쿠엔데(KUE) 토큰을 지정한 컨트랙트 주소로 예금하는 것을 가능하게 해준다. 예치된 토큰은 유저가 토큰을 출금하고자 할 때까지 컨트랙트 주소안에 보관된다. 컨트랙트는 다음과 같은 형태다. 사용자들이 우리의 내부장부와 상호작용할 수 있는 방법은 두 가지다. 하나는 각각의 사용자를 위해 하나의 스마트 컨트랙트를 활용하는 것이고, 다른 하나는 각각의 사용자가 하나의 지갑(월렛)을 통하는 방법이다. 이는 우리가 사용자들이 지갑의 주소를 우선 알지 못해도 복수의 지갑을 통해 입출금을 할 수 있도록 하기 위함이기도 하다. -스마트 컨트랙트 VS 사용자 개별 지정 지갑 주소:스마트 컨트랙트우리는 그 어떤 사용자에게도 지정되지 않은 스마트 컨트랙트 풀을 배치해 놓고 있다. 예를 들어, 사용자가 입금 버튼을 눌렀다면 수많은 비지정 컨트랙트 중 하나가 바로 그 사용자에 바로 지정되게 된다. 만약 사용자가 이미 과거 입금을 한 내역이 있다면 우리는 동일한 스마트 컨트랙트 주소로 돌아가, 이를 사용한다. 사용자는 그 컨트랙트 주소에 아무때나 입금하는 것이 가능하며 우리는 그 내역을 체크해 우리의 내부장부에 잔액을 조정하게 된다.이렇게 되면, 사용자는 쿠엔데(KUE) 토큰을 컨트랙트 주소로 보낼 수 있게 된다. 우리는 모든 KUE 토큰의 트랜잭션을 확인하고 있다. 그러므로 입금주소로 트랜잭션이 이뤄졌음이 확인되면, 우리는 사용자의 내부장부의 잔금을 바로 조정하는 트랜잭션을 진행할 것이다. 사용자가 잔고에서 토큰을 출금하려고 할 경우, 스테이크(Stake) 상태가 현재 아니라는 것을 확인한 후, 사용자가 요청한 액수 만큼을 출금할 수 있는지 결정하게 된다. 만약 그렇다고 한다면, 이 상태는 스마트 컨트랙트 수수료 포함 인출 방식(withdraw_with_fee method)이라 말할 수 있다. 이 기능은 수수료인 가스(gas)를 부과되기 때문인데, 우리는 이 수수료를 이더리움/쿠엔데 비율에 기반해 토큰으로 계산한다. 이렇게 계산된 토큰은 출금이 진행된 그 순간부터 30 블록과 트랜잭션이 블록체인에 확정된 시점까지 우리의 내부 장부에 기록으로 저장된다. - 사용자가 자금을 인출할 때, 우리는 하나의 트렉젝션에 해당하는 부분만 지불한다. - 출금 트랜잭션 시 발생하는 수수료 가스(gas)는 컨트랙트가 배치된 해당 주소에서 지불된다. -지갑이 실행에 앞서 우선적으로 설치되어야 한다. (스마트 컨트랙트를 만드는 것은 일반적으로 1~2분 정도가 소요된다.)-스마트 컨트랙트를 구축하는 것은 소액의 이더리움 (컨트랙트를 만들 때 지불하게 되는 수수료)만을 필요로 한다:지갑사용자가 쿠엔데(KUE) 코인을 우리의 플랫폼에 예치시키기로 했다면 우리는 지갑을 생성시킨다. 이 지갑의 퍼블릭/프라이빗 키는 우리의 데이터베이스에 저장된다. 그럼, 사용자가 KUE 토큰을 해당 주소로 보낼 수 있고, 승인 과정은 위에서 언급된 스마트 컨트랙트 예치법과 비슷하다. 사용자가 잔고에서 잔액을 인출하고자 했을 경우, 우리는 내부 지갑에서 그 사용자의 외부 지갑으로의 트랜젝션을 요청한다. 또한, 이 경우에 우리는 수수료 명목으로 해당 내부 지갑에서 우리의 지갑으로의 트랜잭션을 요청시킬 필요가 있다. -지갑 생성시에 우리가 별도로 지불할 것이 없다. -수수료에 따라 우리가 인출 로직을 알맞게 수정 가능하다.-우리가 하나가 아닌 두 개에 해당하는 트랜잭션 수수료를 내야한다. -내부 지갑은 출금 트랜잭션 수수료 가스(gas)를 지불하기 위한 이더리움(ETH)가 필요하다. -우리가 각각의 내부 지갑의 퍼블릭/프라이빗 키를 안전하게 보관해야만 한다. -실행 실제 실행에 관해 깊이 알아보기 전에, 우리의 내부 애플리케이션 스테이크에 대해 소개하고자 한다. 쿠엔데는 모놀리식(monolithic) 형식으로 루비 온 레일즈(Ruby on Rails) 환경에서 시작된 것이다. 따라서, 프로토타입 시연까지는 상당히 빠르게 진행되었으나 그 이후 관리에서는 어려움에 봉착했다. 초기 투자 유치 이후(2016), 우리는 마이크로 서비스를 도입하고 모놀리식 메인 애플리케이션의 로직을 추출, 소규모 서비스 형태로 만들기로 했다. 그 때부터, 루비(Ruby) 환경은 수 많은 비즈니스 로직과 동시성을 포함한 애플리케이션의 경우, 속도가 느려졌다. 이에, 우리는 루비가 아닌 스칼라와 고(Go)를 메인 언어로 도입하게 됐다. 스칼라와 트위터의 핀에이글(Finagle)은 우리의 마이크로 서비스를 개발시키는데, 고(Go)는 대부분 인프라스트럭쳐와 관련된 부분에 각각 사용되었다(이와 관련된 부분은 후속 기사에서 자세히 다루도록 하겠다).우리는 우리의 마이크로 서비스를 위해 루비(Ruby)와 스칼라(Scala)를 사용했다는 부분이 고려되어 이 플랫폼에서 분상 웹인 웹3(web3) 라이브러리도 관리하게 되었다. 그러나, 루비는 그러나 웹3 라이브러리에 대한 좋은 유지 환경을 가지고 있지 못하고 스칼라의 경우 내부에 이미 존재하는 web3.js 스칼라 라이브러리가 자바 공식 web3.js 라이브러리에 겹쳐진다. 유감스럽게도, web3.js 라이브러리가 싱크 콜즈나 옵저버블스(observables)에 기반하고 있는 우리의 에이씽크 스테이크와 잘 융합되지 않으면서 (현재 우리는 동시성_콘커런시 보델로 에이씽크 퓨쳐스를 사용하고 있다) 우리는 루비와 웹3를 통합시켜보는 방안을 살펴보게 되었다. 또 다른 프로그래밍 언어인 러스트(Rust)로 패리티(Parity)가 써졌다는 것과 러스트가 힐리스(Helix) 라이브러리를 사용할 경우 루비와 잘 통합될 수 있다는 지식에 기반해, 우리는 이러한 루트를 선택하기로 결정했다. 결론적으로 스마트 컨트랙트 구축, 웹3 이벤트 관리, 스마트 컨트랙트 콜 구성 등 모든 블록체인 파트는 러스트 라이브러리를 활용해 실행되게 되었다. 우리는 기능성(functionality)을 모두 루비에 기반하고 있는 동시에 현재 다른 서비스에도 이와 같은 애플리케이션 프레임워크를 유지하고 있다. "이 것은 우리가 우리의 커뮤니티와의 완전한 투명성을 확보하기 위함입니다. 우리는 커뮤니티와 목표지점까지의 걸어가는 과정, 기술적으로 직면한 도전, 과거의 결정과 미래를 위한 중요한 결정을 공유할 것입니다."여러분들의 지지에 감사드리며, 우리는 이 곳 미디엄(Medium)에 올린 어떠한 것에 대한 여러분의 첨언, 피드백 등에 열려있습니다. 원문:https://medium.com/kuende/the-tale-of-our-micro-economy-ethereum-internal-ledger-8c55b2140933