전문가를위한 vRAM 가이드

네트워크의 분산 스토리지 솔루션에 대한 기술적 가이드

EOS — 디앱들의 집

RAM이 제대로 사용되고 있지 않다.

EOS 메인넷은 64GB의 RAM으로 시작되었으며 블록 프로듀서(BP)는 연간 총 64GB의 RAM을 추가로 공급할 것을 결정했습니다. 그러나 오늘날 사용자 프로필, 계정 잔고 및 업데이트 된 상태 정보를 저장해야하는 디앱은 때론 몇 기가 바이트(GB)의 RAM 요구 사항을 가질 수 있습니다. 이는 근본적으로 현재 RAM 모델과 호환되지 않는 제약 조건 입니다.

vRAM 시스템 소개

vRAM 시스템을 사용하면 EOS RAM을 의도했던대로 사용중인 디앱 데이터만 저장하기위한 경량 캐시 레이어로 사용할 수 있습니다. EOS RAM에서 영구적인 데이터 저장 기능을 제거하여 사용 중인 데이터만의 화이트보드 역할을 할 수 있습니다.

vRAM은 DAPP 네트워크 인프라를 활용하여 기존 기술 스택의 시스템적 제한으로 인해 상상할 수 없었던 다양한 디앱을 지원하는 최초의 프로덕트입니다. DAPP 네트워크는 디앱 개발자에게 추가 스토리지용량, 보안 통신 및 기타 중요한 유틸리티를 제공하는 서비스를 빌드하기위한 기반을 형성하는 프로비저닝 레이어와 DAPP 서비스 레이어로 구성됩니다.이 DAPP 기초 위에 개발자에게 효율적인 데이터 검색이 최적화된 친숙한 데이터 구조인 다중 인덱스 테이블을 사용할 수 있는 고유한 vRAM 라이브러리와 IPFS 서비스 레이어가 있습니다.

프로비저닝 레이어 (Provisioning Layer)

DSP는 다음을 제공 할 수 있습니다 :

  • 다음 섹션에서 설명하는 온-체인 기반 서비스.
  • 클라이언트 측 어플리케이션에서 액세스 할 수있는 오프 체인 기반 서비스 (이 글에서 설명하는 히스토리 서비스 활용 같은)

오프 체인 서비스의 경우 DSP는 프로비저닝 레이어를 사용하여 사용량을보고하고 할당량을 관리합니다.

DAPP 서비스 레이어

서비스 요청은 특정 파라미터를 가지며 특정 결과로 컨트랙트에 대한 응답을 다시 트리거 할 수 있다는 점에서 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 서비스 레이어에서 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의 이면

이걸 슈퍼 디앱라고 부르 자(🍄). 슈퍼 디앱 스마트 컨트랙트는 2가지 액션을 가지고 있습니다 : 새로운 게임 세션이 시작되기 전에 플레이어의 진행상황과 현재 점수를 로드하는 “게임 시작”과 게임 세션이 끝나면 플레이어의 점수를 업데이트하는 “점수 수정”

이 예제의 트랜잭션 순서는 5 단계로 수행됩니다. :

  • 시그널 (Signal)
  • 웜-업 (Warm-Up)
  • 로드 및 트랜잭션 (Load and Transact)
  • 수정 (Modify)
  • 캐시 클리어(Clear Cache)

시그널 (Signal)

(2) 트랜잭션을 수행하는 데 필요한 데이터는 RAM에서 찾을수 없고, vRAM에서 있기 때문에 디앱 스마트 컨트랙트는 예외(exception)를 두는 트랜잭션을 실행합니다. 이 실패는 DSP에 서비스가 필요하다는 신호를 보내는 수단입니다.

(3) 서비스 요청을 구문 분석(Parsing)하면 DSP가 vRAM에 있지만 RAM에는 없는 모든 데이터를 감지합니다.

클라이언트의 App (eosjs 인스턴스)은 DSP API 노드를 통해 트랜잭션을 보냅니다. 트랜잭션은 DSP에 의해 로컬로 실행될 때 실패합니다. 이 예외는 서비스 요청을 시그널하는 방법입니다.

🍄 이 그림에서 Alice는 ‘슈퍼 디앱’의 새로운 라운드를 시작할 준비가되어 슈퍼 디앱 커너트랙트에 ‘게임 시작’ 트랙잭션을 보냅니다.그러나 트랜잭션이 DSP 노드에서 로컬로 실행될 때, 그녀의 마지막 체크 포인트와 현재 점수가 RAM에서 누락됩니다.새로운 게임 세션을 로드하기 위해서는 이러한 데이터 포인트가 필요하기 때문에, 그 트랜잭션은 어서션(assertion) 실패를 초래합니다. 트랜잭션을 실행 한 DSP는 시그널을 받아서 서비스 요청을 구문 분석(Parsing)합니다.


웜-업(Warm-Up)

(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)

(2) 모든 필요한 데이터가 현재 RAM에서 발견되므로 블록 체인에서 블록 생산 노드로 전달되기 전에 트랜잭션을 성공적으로 처리 할 수 ​​있습니다.

(3) 트랜잭션이 다른 이유로 실패한 경우 클린업 프로세스(cleanup process)가 수행되어 사용하지 않는 캐시를 지 웁니다.

데이터의 유효성을 확인한 후 DSP는이를 EOS RAM에 로드하고 트랜잭션을 블록 체인으로 보냅니다. 이번에는 필요한 모든 데이터를 RAM에서 사용할 수 있기 때문에 성공합니다.

🍄 우리의 그림을 다시보면, 데이터를 검증한 후 DSP는 거래를 BP의 P2P 엔드 포인트에 전송함으로써 Alice의 점수와 체크포인트를 RAM의 임시 캐시 테이블로 로드합니다. 이제 RAM에서 필요한 모든 데이터를 사용할 수있게 되었으므로 블록 생성자(BP) 노드로 트랜잭션을 보낼 수 있습니다.


수정(Modify)

잘 따라오고 있습니까? 좋아요, 정말 멋진 부분이 다가오고 있습니다! 🍩

(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)

(2) DSP는 디앱 스마트 컨트랙트에 클린업 액션을 전송하고, RAM에서 데이터를 삭제합니다.

(3)디앱 스마트 컨트랙트는 암호화 서명(merkle root)을 RAM에 남겨 둡니다. 이건 다음 워밍업 요청(Warm-Up Request.)의 무결성을 검증하는 데 필요합니다.

데이터는 EOS RAM에서 삭제되어 해당 작업이 수행되었음을 증명하는 암호화 증명(Merkle root)이 남습니다.

🍄 게임이 끝난 후 슈퍼 디앱 컨트랙트는 RAM에서 데이터를 삭제하고 다음 워밍업 요청을 확인하는 데 필요한 암호화 증명을 남깁니다.

엔드 -투 -엔드 분산 스토리지

데이터베이스 전체를 나타내는 단일 머클 루트는 디앱 스마트 컨트랙트가 ‘웜-업 요청(Warm-Up Request)’로 알려진 프로세스에서 현재 작업과 관련된 데이터 세트의 특정 부분의 유효성을 검증 할 수 있도록 합니다. 이 방법으로, 스마트 컨트랙트는 전체 데이터 세트를 다운로드하거나 추가적인 신뢰 요구사항을 도입할 필요 없이 테라바이트의 데이터를 가진 대형 데이터베이스에서 싱글 엔트리를 ‘웜-업’할 수 있습니다.또한, 스마트 컨트랙트에서 vRAM을 이용해 데이터를 커밋하거나 수정할 때마다, 그 데이터는 체인 히스토리의 일부가 되고, 예기치 않은 상황으로 인해 데이터를 이용할 수 없을 경우, 앞서 말한 데이터를 재생함으로써 재생산할 수 있다.

미래를 향한 DAPP

DAPP 네트워크의 채택이 계속 증가함에 따라 개발자의 DAPP 커뮤니티는 vRAM 시스템의 새로운 사용 사례를 설계하여 DAPP 서비스의 기능을 확장 할 것으로 기대합니다.

리퀴댑스는 디앱 개발자가 Devs Telegram 채널에 참여하고 피드백을 제공하며 진행중인 토론에서 적극적인 역할을하도록 초대합니다. vRAM 시스템의 기술적 측면에 대해 자세히 알아 보려면GitHub Repository를 확인하십시오.

리퀴댑스

리퀴댑스 KOR

리퀴댑스(Liquidapps) Kor

리퀴댑스는 EOS 네트워크 확장성 문제를 해결 할 솔루션 입니다.

1

1 clap
CREAM ER

Written by

CREAM ER

DEXEOS.io / Everipedia.org / Liquidapps.io/ eosDAC.io / eosCHROME.io

리퀴댑스(Liquidapps) Kor

리퀴댑스는 EOS 네트워크 확장성 문제를 해결 할 솔루션 입니다.