EOS.IO 기술 백서에서 블록체인의 몇가지 기능에 대하여 다루었습니다. 이번 문서에서는 자원 할당 (역주:resource allocation; 컴퓨터의 하드디스크 용량, 램, CPU 등의 자원을 분배하는 것) 방법을 설명합니다. EOS.IO는 토큰의 보유량에 비례하여 자원을 할당합니다. 만약에 1%의 토큰을 가지고 있다면, 남아있는 용량의 1%를 할당하는 방법입니다. 예를 들어, 10억(10의 9승)개의 토큰이 존재하고 1테라바이트(10의 12승)의 저장공간이 있다면 1KB(10의 3승)당 비용은 1토큰이 됩니다. 시총이 30억달러(3조3천억원)인 경우 1킬로바이트 당 3달러(3천3백원)의 비용이 필요합니다. 이더리움의 시총에 도달하면, 1킬로바이트당 비용은 30달러(3만3천원), 바이트당 비용은 3센트(33원)가 됩니다.
EOS.IO 소프트웨어에서 계정을 생성할 때 권한, 잔액 등의 정보를 저장하기 위해 대략 1,000바이트가 필요합니다. 1바이트당 3센트로 가정하면, 하나의 계정당 30달러(3만3천원)의 비용이 드는데, 좀 많이 비쌉니다.
(역주 : 이번 글에서 저장비용은 1바이트당 3센트(33원)로 계산합니다. 게섯거라 이더리움)
토큰 가격이 비싸질 때 저장비용을 잡기 위해서 저장공간을 늘릴 필요가 있습니다. 계정당 비용을 0.01달러(11원)로 줄이기 위해서 3,000테라바이트의 저장공간이 필요합니다. 우리가 SSD를 사용한다면 저장공간을 만들기 위한 비용은 100만달러(11억원)에 육박할 것입니다.
EOS.IO 블록체인이 300억달러33조의 가치를 가진다면, (5%의 인플레이션을 고려했을 때) 매년 블록 생산자에게 15억달러(1조5천5백억원)가 지급되므로 100만달러(11억원)는 큰 비용이 아닐 것입니다.
안타깝게도 SSD는 램(RAM)에 비해 2,500배 느립니다. 운영체제에서 메모리가 부족하여 SSD 상의 가상메모리(swap)로 데이터를 올릴 때 엄청난 성능저하가 발생합니다. 스팀에서 chainbase(스팀 내부의 트랜잭션 DB)로 업그레이드를 하였을 때 다수의 증인 노드에서 이와같은 현상이 발견되었습니다.
즉, 충분한 성능을 확보하기 위해서 우리는 3,000테라바이트 용량을 가지면서 램만큼 빠른 저장장치가 필요합니다. 구글은 모든 데이터베이스를 램에서 보관하기에 말도 안 되는 이야기는 아닙니다. 다만, 새로운 플랫폼을 위해 그만큼의 램을 사용하는 것은 조금 말도 안 됩니다.
인텔은 최근 3D XPoint 기술의 옵테인 SSD를 출하하였습니다. 이것은 램처럼 활용할 수 있으며 기존의 램보다 현저히 느렸던 SSD의 성능을 매우 큰 폭으로 향상한 최초의 SSD 입니다. 연말 1.5테라바이트 용량이 출시될 예정입니다.
이러한 새로운 기술로 고성능 메모리의 가격이 큰폭으로 내려가고 블록 생산자들은 더욱 저렴한 비용으로 메모리 공간을 늘릴 것으로 생각합니다. 토큰의 가치가 높아지면 블록 생산자가 감당할 수 있는 메모리의 양도 늘어날 것입니다.
EOS.IO 소프트웨어에서 램 저장공간을 토큰화하면 저장의 가치에 추가로 화폐적 가치를 얻게됩니다. 화폐적 가치가 추가되면 그렇지 않은 경우에 비해서 비싼 저장 비용을 치르게 됩니다. 금의 경우 일반적으로 화폐적 가치가 원자재로 사용하는 것보다 가치 있기 때문에 원자재로 많이 활용하지 않습니다. EOS.IO 소프트웨어를 사용해서 토큰을 만들 경우 선출된 블록 생산자들에게 성능증명(Proof-of-performance)을 요구하여 램 저장공간을 화폐화 합니다.
은행이 금을 보관할 때 처럼 대부분 시간은 대비만 하고 있고 사용하지 않습니다. 블록 생산자는 3테라바이트의 저장공간을 가지고 있을 때 1000배의 비율인 "3000테라바이트까지 가용"하다고 홍보할 수 있습니다. 이 모형으로 저장 비용은 "금 보증 채권"의 가격이 부분 지급 준비금으로 가격이 하락하듯이 줄어들게 됩니다. (역주: 준비율에 비례하여 더 많이 판매할 수 있으므로, 공급이 적어도 큰 수요를 감당할 수 있습니다. 예시의 경우 지급준비율은 0.1%입니다. 대한민국의 법정지급준비율은 7%입니다.) 잘 동작하지만, "뱅크런"이 일어나게 되어 모든 화폐를 일괄 구매하고, 3테라바이트가 준비되어 있을 때 30테라바이트를 요구할 때 문제가 됩니다. (역주:즉, 지급준비 용량 이상의 메모리 할당 요청이 들어오게 될 때 문제가 발생합니다.)
https://upload.wikimedia.org/wikipedia/commons/5/54/Bundesarchiv_Bild_102-12023%2C_Berlin%2C_Bankenkrach%2C_Andrang_bei_der_Sparkasse.jpg 베를린의 뱅크런 사태, 1931년
네트워크는 대부분의 사람이 요청한 용량을 사용하려 하지 않을 때 토큰 대비 "저렴한 저장소"로 동작할 수 있습니다. 사용할 수 있는 용량이 줄어들 때 가격은 증가합니다. 누군가 100%의 용량을 사용하려 할 때 100%의 유동 토큰을 내야 할 수 있습니다. 반면에 1%의 가용 용량만 필요하다면 0.01%의 유동 토큰을 내기만 하면 됩니다. 실제 사용할 정확한 산정 수식은 모델링과 근사 과정이 필요합니다. 그렇지만 저장소의 첫 번째 바이트에 대한 초기 가격은 전체 공간을 사용하는 비용보다 1,000배 저렴하게 할 수 있습니다.
간단하게 준비 비율을 1,000배로 설정한 후 실제 메모리 사용량에 따라 1배까지 감소시키는 방안이 있습니다. 만약에 1테라바이트의 실제 램이 있다면 1,000테라바이트의 가상메모리를 가지게 됩니다. 100기가바이트(10%의 메모리)를 사용한 후 준비 비율은 100배로 줄어들며, 가상메모리는 100테라바이트가 됩니다. 500기가바이트(50%의 메모리)를 사용하면 준비 비율 20배로 줄어들며, 가상메모리는 20테라바이트가 됩니다. 가상메모리가 줄어들면 토큰당 가상메모리 역시 줄어들게 됩니다. 자동으로 저장소 단가가 상승하게 됩니다.
자원의 수요와 공급이 균형을 이룰 때까지 시장의 가격은 지속적으로 변동됩니다. 만약 저장소의 초기 가격이 너무 저렴했다면 빠르게 소비되며 가격은 가치 있는 데이터만 저장될 수준까지 올라갈 것입니다. 이 시점에서 블록 생산자는 저장 가능 용량을 늘리거나, 지급준비율을 조정하여 가격을 낮출 것입니다. 토큰 보유자들은 가장 저렴하게 메모리를 공급하는 블록 생산자에게 투표할 것입니다. 그리고 토큰의 가치가 올라가면 블록 생산자들은 추가 저장 용량을 확충할 여지가 생길 것입니다.
가격 변동은 다른 측면은 사용하지 않는 메모리를 반납할 경제적 동기부여입니다. 토큰의 가치가 올라가면 토큰을 사용하여 저장공간을 확보하는 비용이 증가합니다. 현명한 개발자라면 최소한의 메모리 사용량과 최대한의 메모리 해제가 가능하도록 애플리케이션을 설계할 것입니다.
제안하는 알고리즘의 부작용은 많은 메모리를 사용하려는 사람이 최초로 메모리를 사용한 이점을 가지는 것입니다. 한번 메모리를 소비하면 계약서에 어긋나지 않는 선에서 재사용할 수 있습니다. 자금이 필요하다면 메모리를 해제하면 됩니다. 메모리를 "처음" 가지려는 것은 추측 수요와 실제 수요가 만나는 지점으로 빠르게 가격을 올릴 것입니다.
다행히도 할당된 메모리는 "넘기는게 불가능"하며, 초기 가격은 실제 램을 구매하는 것보다 100배 비싸므로 선점 공격은 완화될 것입니다. 네트워크 메모리의 모든 바이트는 복제되어 100개 이상의 풀 노드와 일부 부분 노드에 저장이 될 것입니다. 네트워크는 저장하는 사람들에게 실제 드는 비용에 준하게 청구할 것입니다. 그러므로, 100개 이상의 노드들에 대한 탈중앙화 램 복제는 일반 PC의 램에 저장하는 것에 비해 기본적으로 100배 비쌀 것입니다. 블록 생산자들은 준비 비율을 세심하게 관리하여 바이트당 비용이 네트워크를 유지하는 실제 비용보다 낮지 않도록 해야 합니다.
시장은 EOS.IO 소프트웨어의 토큰이 가지는 자본적 속성을 자연스레 받아들일 것입니다. 실제 애플리케이션 개발이 가능한 금액으로 메모리가 판매되기 위해 가격을 동적으로 제어하는 구현이 필요합니다. 새로운 메모리 기술과 연계하여 탈중앙화 애플리케이션 개발자들에게 EOS.IO 블록체인에 저장하는 것이 합당하도록 보장할 것입니다.