[리퀴댑스] 전문가를위한 vRAM 가이드 (네트워크의 분산 스토리지 솔루션에 대한 기술적 가이드)
EOS — 디앱들의 집
EOS 블록 체인은 완전히 분산되어 있으며 대중들에게 서비스를 제공하는 확장 가능한 앱을 수용하기 위해 시작되었습니다. 메인넷을 출시한 지 불과 몇 달 만에 EOS는 블록체인 활성화 측면에서 경쟁사를 앞질렀습니다. DPoS(위임 증명)와 500ms 블록타임은 EOS에게 차세대 패러다임 변화 디앱을 지원할 수있는 최적의 프로토콜로서 자신을 구별할 수 있는 완벽한 처리 능력을 주었습니다.
RAM이 제대로 사용되고 있지 않다.
뛰어난 성능에도 불구하고 EOS에서 네트워크 자원의 비용과 한계는 디앱 개발자가 자신의 디앱을 구축하고 확장하는 것을 제한합니다.특히 디앱 스마트 컨트랙트와 각 사용자의 밸런스와 같은 상태 정보를 RAM에 영구적으로 저장해야한다는 요구 사항 때문에 디앱 확장성에 장벽이 되고 있습니다.EOS RAM은 실제 작동과 관련된 데이터를 저장하는 역할을 하는 랜덤 액세스 메모리 장치보다 하드 디스크 드라이브에 더 가깝기 때문에 오해의 소지가 있는 용어입니다.
EOS 메인넷은 64GB의 RAM으로 시작되었으며 블록 프로듀서(BP)는 연간 총 64GB의 RAM을 추가로 공급할 것을 결정했습니다. 그러나 오늘날 사용자 프로필, 계정 잔고 및 업데이트 된 상태 정보를 저장해야하는 디앱은 때론 몇 기가 바이트(GB)의 RAM 요구 사항을 가질 수 있습니다. 이는 근본적으로 현재 RAM 모델과 호환되지 않는 제약 조건 입니다.
vRAM 시스템 소개
vRAM 시스템은 RAM과 호환되는, EOS 디앱을 구축하는 개발자를 위한 엔드 투 엔드 분산형 대체 스토리지 솔루션입니다. 그것은 잠재적으로 무한한 양의 데이터를 저렴하고 효율적으로 저장하고 검색할 수 있도록 하는 것을 목표로 합니다.
vRAM 시스템을 사용하면 EOS RAM을 의도했던대로 사용중인 디앱 데이터만 저장하기위한 경량 캐시 레이어로 사용할 수 있습니다. EOS RAM에서 영구적인 데이터 저장 기능을 제거하여 사용 중인 데이터만의 화이트보드 역할을 할 수 있습니다.
vRAM은 DAPP 네트워크 인프라를 활용하여 기존 기술 스택의 시스템적 제한으로 인해 상상할 수 없었던 다양한 디앱을 지원하는 최초의 프로덕트입니다. DAPP 네트워크는 디앱 개발자에게 추가 스토리지용량, 보안 통신 및 기타 중요한 유틸리티를 제공하는 서비스를 빌드하기위한 기반을 형성하는 프로비저닝 레이어와 DAPP 서비스 레이어로 구성됩니다.이 DAPP 기초 위에 개발자에게 효율적인 데이터 검색이 최적화된 친숙한 데이터 구조인 다중 인덱스 테이블을 사용할 수 있는 고유한 vRAM 라이브러리와 IPFS 서비스 레이어가 있습니다.
프로비저닝 레이어 (Provisioning Layer)
DAPP 네트워크의 중심에는 개발자가 EOS 디앱을 개발하는 데 중요한 서비스를 제공하는 디앱 서비스 제공자(DSP)가 있습니다.DSP는 자유 시장에서 개발자에게 제공 할 수있는 서비스 패키지를 생성합니다. 특정 서비스 패키지에 액세스하려면 디앱 스마트 컨트랙트에서 DSP가 설정 한 서비스 컨트랙트에 따라 충분한 양의 DAPP 토큰을 스테이크 해야합니다. ‘dappservices’ 스마트 컨트랙트는 스테이킹 메커니즘, 패키지 프로비저닝 및 할당량 관리를 담당합니다. 각 서비스 요청은 온-체인에 기록되며 디앱 스마트 컨트랙트에서 사용할 수 있는 액션의 남은 할당량을 줄입니다.
DSP는 다음을 제공 할 수 있습니다 :
다음 섹션에서 설명하는 온-체인 기반 서비스.
클라이언트 측 어플리케이션에서 액세스 할 수있는 오프 체인 기반 서비스 (이 글에서 설명하는 히스토리 서비스 활용 같은)
오프 체인 서비스의 경우 DSP는 프로비저닝 레이어를 사용하여 사용량을보고하고 할당량을 관리합니다.
DAPP 서비스 레이어
디앱 스마트 컨트랙트(백서에서는 사용자 컨트랙트라고 함)와의 상호 작용이 필요한 DSP 서비스의 경우 DAPP 서비스 레이어에는 사용자 컨트랙트가 DSP의 특정 서비스를 요청할 수있는 프로토콜이 포함되어 있습니다.
서비스 요청은 특정 파라미터를 가지며 특정 결과로 컨트랙트에 대한 응답을 다시 트리거 할 수 있다는 점에서 DSP에 대한 “함수 식(function-like)”호출입니다
서비스 요청에는 두 가지 종류가 있습니다. :
synchronous(동기식) 그리고 asynchronous(비동기식)
동기식 요청(synchronous Requests) (blocking): 동기식 요청(Synchronous requests)은 사용자 컨트랙트가 트랜잭션 실행을 블락하고 요청이 컨트랙트에 대한 응답을 리턴 할 때까지 피어 투 피어 네트워크에 이를 전파합니다. vRAM 시스템에서 DSP 노드는 트랜잭션을 수신하고 처음에 로컬로 실행합니다. 이는 트랙잭션에서 참조하는 RAM 테이블에서 필요한 데이터를 사용할 수 없기 때문에 예외(exception)를 발생시킵니다. 예외(exception)는 거래가 아직 준비되지 않았다는 신호를 DSP에 보내어 서비스를 요청하는 방법입니다 (예 : 로컬 IPFS 클러스터 파일 리터닝, 웹 오라클 요청 처리 또는 난수 생성) DSP가 필요한 데이터를 RAM에 로드하면 트랜잭션을 블록 생산 노드에 릴레이 할 수 있습니다. 만약 사용자가 비 DSP API 노드(non-DSP API node)에 직접 서비스를 필요로하는 트랜잭션을 전송하면 고유 DSP 노드 만 서비스 요청으로 예외를 구문 분석(parsing) 할 수 있으므로 실패하게 됩니다.
비동기식 요청(Asynchronous Requests): 컨트랙트는 서비스 요청을 나타내는 이벤트를 전달(dispatch)하고 실패없이 트랜잭션을 계속 실행합니다. 비동기식 요청이 vRAM 시스템의 DAPP 서비스 레이어에서 작동하는 방식은 다음과 같습니다 : DSP는 온-체인 이벤트 스트림을 청취하고 그러한 요청을 실행함으로써 컨트랙트가 서비스를 요청했음을 감지합니다 (예 : IPFS 서비스 정리 및 커밋, 이벤트 로그, 트랜잭션 요청 스케줄) 비동기 요청은 요청 응답 수신에 종속되지 않으므로 직접 DSP API 노드로 전송할 필요가 없습니다. 오히려이 요청은 모든 EOSIO 노드에서 전송할 수 있으며 블록 체인에서 이벤트를 수신하는 DSP 노드에 의해 구문 분석(parsing)됩니다.
IPFS 서비스 레이어
로컬 IPFS 클러스터는 콘텐츠 기반 어드레싱(addressing)을 사용하여 파일에 액세스하는 분산 데이터 스토리지 솔루션입니다. 기존 클라이언트-서버 모델과는 다르게, 각 파일이 특정 IP 주소를 가진 서버에 있고 그 주소를 요청하는 클라이언트에 의해 검색되는 경우, 로컬 IPFS 클러스터 파일은 주어진 파일에 대한 포인터의 역할을 하는 URI(Unique Resource Identifier)를 제공하기 위해 해시 됩니다. DAPP 네트워크는 로컬 IPFS 클러스터의 성능을 활용하여 분산화 된 피어 투 피어 네트워크에 파일을 저장하고 안전하고 효율적으로 검색 할 수있는 세 가지 서비스 요청을 지원합니다.
IPFS 서비스 레이어에서 vRAM 시스템은 당세 가지 종류의 서비스 요청을 사용합니다. :
웜업 요청(Warmup Requests), 클린업 요청(Cleanup Requests), 커밋 요청(Commit Requests).
웜업 요청(Warmup Requests) : 사용자 컨트랙트는 URI를 사용하여 로컬 IPFS 클러스터에서 파일을 검색하는 서비스 요청을 보냅니다. 서비스 요청을 구문 분석(Parsing)하면 DSP가 파일을 포함하는 페이로드를 컨트랙트로 리턴합니다. URI도 파일의 해시이기 때문에 컨트랙트에서 데이터를 해싱하고 식별자와 비교하여 파일의 무결성을 쉽게 확인할 수 있습니다. 웜업 요청(Warmup Requests)은 동기식이며 응답이 컨트랙트에 리턴 될 때까지 컨트랙트 실행을 차단합니다.
클린업 요청(Cleanup Request):클린업 요청(Cleanup Request)은 캐시에서 파일을 제거하기 위해 DSP에 요청을 전송합니다. 이는 비동기식 요청입니다.
커밋 요청(Commit Requests): 커밋 요청은 DSP가 로컬 IPFS 클러스터 노드에 새로운 데이터를 쓰도록 지시합니다. 개발자는 스마트 컨트랙트 내에서 setData 함수를 활용하여 DSP 노드가 포착 한 커밋 요청을 보내기 전에 먼저 URI를 반환하기 위해 새 데이터를 해싱 할 수 있습니다.
비슷한 방법으로 getData 함수를 활용하여 스마트 컨트랙트의 데이터를 가져 오거나 누락 된 경우 웜업(Warmup)을 요청할 수 있습니다.
vRAM 레이어
vRAM 레이어는스마트 컨트랙트에서 개발자에게 친숙한 인터페이스를 제공합니다.(다중 인덱스 테이블) vRAM은 로컬 IPFS 클러스터에서 정보를 검색하는 디앱 개발자에게 익숙한 방식으로 훨씬 효율적이게 만듭니다. DSP는 vRAM 레이어에 노출되지 않습니다. 이는 vRAM 라이브러리를 사용하는 사용자 컨트랙트내에서만 존재하므로 DSP 소프트웨어를 변경하지 않고 시스템을 업그레이드하고 최적화 할 수 있습니다. vRAM은 머클 트리(Merkle tree)를 사용하여 전체 데이터베이스를 나타냅니다.머클 트리의 각 노드는 로컬 IPFS 클러스터에있는 파일로 표시되며, 증명이 필요할 때만 요청시 요청됩니다. 특정 파일을 찾기 위해서는 필요한 데이터를 나타내는 리프 노드(leaf noe)에 도달할 때까지 트리를 탐색해야 합니다.전체 데이터베이스를 나타내는 현재 루트 노드만 RAM에서 유지하면 됩니다.
머클 트리 기반 구조는 vRAM 계층에서 이중 역할을 하며,데이터의 유효성을 검증할 수 있는 무결성의 증명뿐만 아니라 더 빠른 데이터베이스 쿼리가 가능한 인덱스 역할을 합니다.
vRAM의 이면
vRAM이 개발자들에게 어떻게 새로운 세대의 디앱을 만들 수 있는지 설명하기 위해, 우리는 당신에게 슈퍼 마리오 스타일의 런너 게임을 안내할 것이다.
이걸 슈퍼 디앱라고 부르 자(🍄). 슈퍼 디앱 스마트 컨트랙트는 2가지 액션을 가지고 있습니다 : 새로운 게임 세션이 시작되기 전에 플레이어의 진행상황과 현재 점수를 로드하는 “게임 시작”과 게임 세션이 끝나면 플레이어의 점수를 업데이트하는 “점수 수정”
이 예제의 트랜잭션 순서는 5 단계로 수행됩니다. :
- 시그널 (Signal)
- 웜-업 (Warm-Up)
- 로드 및 트랜잭션 (Load and Transact)
- 수정 (Modify)
- 캐시 클리어(Clear Cache)
시그널 (Signal)
(1) vRAM을 사용하는 디앱 스마트 컨트랙트(백서에서는 ‘사용자 컨트랙트’)는 DSP 노드의 EOSIO API를 통해 클라이언트에서 트랜잭션을 수신합니다.
(2) 트랜잭션을 수행하는 데 필요한 데이터는 RAM에서 찾을수 없고, vRAM에서 있기 때문에 디앱 스마트 컨트랙트는 예외(exception)를 두는 트랜잭션을 실행합니다. 이 실패는 DSP에 서비스가 필요하다는 신호를 보내는 수단입니다.
(3) 서비스 요청을 구문 분석(Parsing)하면 DSP가 vRAM에 있지만 RAM에는 없는 모든 데이터를 감지합니다.
클라이언트의 App (eosjs 인스턴스)은 DSP API 노드를 통해 트랜잭션을 보냅니다. 트랜잭션은 DSP에 의해 로컬로 실행될 때 실패합니다. 이 예외는 서비스 요청을 시그널하는 방법입니다.
🍄 이 그림에서 Alice는 ‘슈퍼 디앱’의 새로운 라운드를 시작할 준비가되어 슈퍼 디앱 커너트랙트에 ‘게임 시작’ 트랙잭션을 보냅니다.그러나 트랜잭션이 DSP 노드에서 로컬로 실행될 때, 그녀의 마지막 체크 포인트와 현재 점수가 RAM에서 누락됩니다.새로운 게임 세션을 로드하기 위해서는 이러한 데이터 포인트가 필요하기 때문에, 그 트랜잭션은 어서션(assertion) 실패를 초래합니다. 트랜잭션을 실행 한 DSP는 시그널을 받아서 서비스 요청을 구문 분석(Parsing)합니다.
웜-업(Warm-Up)
(1) DSP는 디앱 스마트 컨트랙트에 특정 서비스 패키지에 대해 충분한 양의 DAPP 토큰이 스테이크 되었는지와 충분히 사용 가능한 할당량이 있는지 확인합니다.
(2) DSP 노드는 누락 된 데이터 포인트를 나타내는 로컬 IPFS 클러스터 파일을 중계(relay)합니다.전체 데이터 세트의 현재 상태를 나타내는 머클 루트 만이 RAM에 영구적으로 저장되므로 데이터를 나타내는 리프 노드(leaf node)에 도달 할 때까지 데이터 세트를 나타내는 머클 트리를 다시 검증하여 데이터 무결성을 확인합니다.
(3) 암호화 증명을 사용하여 디앱 스마트 컨트랙트는 요청 된 데이터가 변경되지 않았는지 검증합니다. 이것으로 “웜-업 요청(Warm-Up Request)”단계를 종료합니다.
DSP는 로컬 IPFS 클러스터에서 요청 된 파일을 가져오고 EOS RAM에서 데이터 세트의 무결성에 대한 암호 증명을 검색합니다. 그런 다음 “웜-업 요청(Warm-Up Request)’으로 알려진 파일을 디앱 스마트 컨트랙트에 전달(relay)합니다.
🍄 그림으로 돌아 가서, DSP가 서비스 요청을 구문 분석(Parsing)하면 로컬 IPFS 클러스터에서 Alice의 데이터를 가져옵니다.컨트랙트에서 데이터의 무결성을 확인할 수있는 암호화 증명과 함께 그녀의 마지막 체크 포인트와 현재 점수를 슈퍼 디앱 컨트랙트에 전달(relay)합니다.
로드 및 트랜잭션 (Load and Transact)
(1) 디앱 스마트 컨트랙트는 필요한 데이터를 RAM에있는 임시 캐시 테이블로 로드합니다.
(2) 모든 필요한 데이터가 현재 RAM에서 발견되므로 블록 체인에서 블록 생산 노드로 전달되기 전에 트랜잭션을 성공적으로 처리 할 수 있습니다.
(3) 트랜잭션이 다른 이유로 실패한 경우 클린업 프로세스(cleanup process)가 수행되어 사용하지 않는 캐시를 지 웁니다.
데이터의 유효성을 확인한 후 DSP는이를 EOS RAM에 로드하고 트랜잭션을 블록 체인으로 보냅니다. 이번에는 필요한 모든 데이터를 RAM에서 사용할 수 있기 때문에 성공합니다.
🍄 우리의 그림을 다시보면, 데이터를 검증한 후 DSP는 거래를 BP의 P2P 엔드 포인트에 전송함으로써 Alice의 점수와 체크포인트를 RAM의 임시 캐시 테이블로 로드합니다. 이제 RAM에서 필요한 모든 데이터를 사용할 수있게 되었으므로 블록 생성자(BP) 노드로 트랜잭션을 보낼 수 있습니다.
수정(Modify)
(1) 스마트 컨트랙트가 vRAM 기반 멀티 인덱스 테이블의 데이터를 수정할 때마다 변경된 데이터와 해당 변경의 영향을 받은 머클 트리 노드를 사용하여 커밋 이벤트를 전달(dispatch)합니다.데이터 포인트와 머클 트리 노드는 로컬 IPFS 클러스터 파일로 표현됩니다.
잘 따라오고 있습니까? 좋아요, 정말 멋진 부분이 다가오고 있습니다! 🍩
(2) 로컬 IPFS 클러스터 URI와 데이터의 해시가 동일하기 때문에 (머클 트리 이중 역할, 기억합니까?) 컨트랙트는 데이터가 실제로 DSP에 의해 로컬 IPFS 클러스터에 커밋되기 전에 예상되는 URI를 알고 있습니다. 동일한 논리에 의해 동일한 데이터를 독립적으로 캐싱하거나 히스토리를 리플레이 하는 두 개의 다른 DSP는 동일한 로컬 IPFS 클러스터 URI로 로컬 IPFS 클러스터에 데이터를 고정시킵니다.
(3) 이 컨트랙트는 새 데이터와 새 머클 트리 노드를 RAM 캐시 테이블에 저장합니다.
(4) 이 컨트랙트는 새로운 머클 루트를 RAM에 영구 저장합니다.
(5) 블록 체인의 모든 이벤트와 마찬가지로 데이터가 있는 커밋 이벤트는 체인 히스토리의 일부가 됩니다. 이렇게하면 히스토리를 재생(recovered)하여 모든 DSP에서 데이터를 복구 할 수 있습니다.
(6) DSP는 demux 서비스를 사용하여 체인에서 오는 이벤트 스트림을 수신하여 이벤트를 포착합니다. 이벤트가 감지되면 DSP는 신속한 검색을 위해 로컬 IPFS 클러스터의 파일을 캐싱 및 인덱스합니다.
(7) DSP는 컨트랙트에 커밋 응답을 보냅니다.
이 프로세스가 끝나면 머클 루트는 EOS RAM에서 수정되고 새로운 데이터 포인트는 DSP의 분산화 파일 스토리지 시스템에 캐시됩니다.
디앱 스마트 컨트랙트는 인라인 액션을 통해 EOS RAM의 데이터를 수정한다.DSP는 수정 이벤트를 수신하고 로컬 IPFS 클러스터 노드에 새 파일을 작성합니다.
🍄 우리의 비유를 계속해보면, 앨리스는 레벨을 마치고 그녀의 진도를 저장합니다. 그녀는 이제 포인트 스코어와 체크 포인트 진행 면에서 모두 증가했습니다. 슈퍼 디앱 컨트랙트는 EOS RAM의 데이터를 수정하는 새로운 데이터로 이벤트를 보냅니다. 동시에 DSP는 이벤트를 수신하고 로컬 IPFS 클러스터의 데이터를 수정하여 RAM의 데이터에 따라 Alice의 최신 점수와 체크 포인트를 반영합니다.
클리어 캐시(Clear Cache)
(1) DSP는 트랜잭션이 끝난 후 디앱 스마트 컨트랙트에 클린업 이벤트를 배포하여 RAM에서 데이터를 빼냅니다.
(2) DSP는 디앱 스마트 컨트랙트에 클린업 액션을 전송하고, RAM에서 데이터를 삭제합니다.
(3)디앱 스마트 컨트랙트는 암호화 서명(merkle root)을 RAM에 남겨 둡니다. 이건 다음 워밍업 요청(Warm-Up Request.)의 무결성을 검증하는 데 필요합니다.
데이터는 EOS RAM에서 삭제되어 해당 작업이 수행되었음을 증명하는 암호화 증명(Merkle root)이 남습니다.
🍄 게임이 끝난 후 슈퍼 디앱 컨트랙트는 RAM에서 데이터를 삭제하고 다음 워밍업 요청을 확인하는 데 필요한 암호화 증명을 남깁니다.
엔드 -투 -엔드 분산 스토리지
데이터가 수정 될 때마다 RAM에 저장된 데이터 세트의 머클 루트가 업데이트됩니다. 컨트랙트 내에서 해당 데이터가 필요하면 머클 증명이 DSP 노드에 의한 디앱 스마트 컨트랙트에 필요한 데이터 포인트와 함께 릴레이됩니다.
데이터베이스 전체를 나타내는 단일 머클 루트는 디앱 스마트 컨트랙트가 ‘웜-업 요청(Warm-Up Request)’로 알려진 프로세스에서 현재 작업과 관련된 데이터 세트의 특정 부분의 유효성을 검증 할 수 있도록 합니다. 이 방법으로, 스마트 컨트랙트는 전체 데이터 세트를 다운로드하거나 추가적인 신뢰 요구사항을 도입할 필요 없이 테라바이트의 데이터를 가진 대형 데이터베이스에서 싱글 엔트리를 ‘웜-업’할 수 있습니다.또한, 스마트 컨트랙트에서 vRAM을 이용해 데이터를 커밋하거나 수정할 때마다, 그 데이터는 체인 히스토리의 일부가 되고, 예기치 않은 상황으로 인해 데이터를 이용할 수 없을 경우, 앞서 말한 데이터를 재생함으로써 재생산할 수 있다.
미래를 향한 DAPP
vRAM은 DSP, 개발자 및DAPP 토큰의 힘을 활용하여 디앱 확장성을 확보하는DAPP 네트워크의 첫 번째 구현 일뿐입니다.
DAPP 네트워크의 채택이 계속 증가함에 따라 개발자의 DAPP 커뮤니티는 vRAM 시스템의 새로운 사용 사례를 설계하여 DAPP 서비스의 기능을 확장 할 것으로 기대합니다.
리퀴댑스는 디앱 개발자가 Devs Telegram 채널에 참여하고 피드백을 제공하며 진행중인 토론에서 적극적인 역할을하도록 초대합니다. vRAM 시스템의 기술적 측면에 대해 자세히 알아 보려면GitHub Repository를 확인하십시오.
리퀴댑스 ENG
Website | Twitter | Telegram| Github | LinkedIn