전문가용 크로스 체인 브릿지 가이드

DAPP 네트워크의 상호 운용성 혁신에 대한 기술적 심층 분석

CREAM ER
리퀴댑스(Liquidapps) Kor
11 min readOct 20, 2020

--

DAPP 네트워크의 크로스 체인 브릿지는 데이터와 토큰이 자유롭게 흐를 수 있도록 블록체인 간의 벽을 허물고 있는 서비스와 기능을 제공합니다. 개발자는 멀티체인 유동성 풀이나 자동화된 마켓 메이커(AMM)와 같은 새로운 세대의 DeFi 제품을 만들기 위해 코드를 구현할 수 있으며, 모든 구성요소는 표준화된 방식으로 구축되어 개발자가 다른 체인용 어댑터를 가능한 한 쉽게 추가할 수 있습니다. 보편적인 크로스 체인 브릿지는 이더리움의 우수한 유동성을 다른 체인들에게 개방할 수 있습니다. 이더리움 개발자는 차례로 DAPP 네트워크의 범용 레이어 2를 활용하여 확장을 위한 디앱을 구축하는 동시에 토큰을 메인넷에 유지할 수 있습니다.

이 글에서는 다양한 구성 요소가 어떻게 결합되어 크로스 체인 토큰 및 데이터 전송이 가능한지 이해하기 위해 브리지 아키텍처에 대해 자세히 살펴보겠습니다.

크로스 체인 브릿지 아키텍처 연구

DAPP 네트워크 서비스는 자유 시장 기반으로 개발자에게 소프트웨어 서비스를 제공하는 DAPP 서비스 제공 업체 (DSP)를 통해 제공됩니다. 이러한 서비스는 독립 실행 형 방식으로 사용할 수있을뿐만 아니라 시너지 플러그 앤 플레이 방식으로 함께 활용할 수 있습니다. 크로스 체인 브리지는 DAPP 네트워크의 새로운 서비스가 아닙니다. 오히려 그것은 빠른 완결성으로 체인간에 메시지를 전달하기 위해 함께 활용되는 서비스의 조합입니다.

크로스 체인 브리지에서 사용되는 서비스는 다음과 같습니다.

  1. LiquidScheduler(리퀴드 스케쥴러):작업 스케줄러 및 자동화 된 작업 서비스는 EOSIO 체인에서 사용되어 브릿지 계약의 분산되고 지속적인 실행을 보장합니다. 체인 사이의 메시지 및 수신 전달을 예약하고 프로세스에 관련된 체인에서 주기적으로 읽기를 담당합니다.
  2. LiquidOracles(리퀴드 오라클): 페어를 이루는 체인 및 계약에 대한 상태 정보를 검색하는 데 사용되는 탈중앙화 무신뢰 웹 오라클입니다.
  3. The vRAM System(vRAM 시스템): 제한 없이 분산되고 경제적인 온체인 메모리로, EOSIO 체인에 사용되어 RAM 리소스 비용을 최소화하는 방식으로 메시지 및 수신 압축을 용이하게 합니다.
  4. LiquidLink(리퀴드 링크):EOSIO 체인에 사용되어 구현된 비 EOSIO 체인에 트랜잭션을 퍼블리시합니다. 리퀴드 링크는 현재 이더리움에서 완전히 기능하고 있으며, 스테이크 홀더 또는 커뮤니티뿐만 아니라 다른 체인에서도 쉽게 수정할 수 있습니다.
이더리움과 EOSIO를 연결하는 크로스 체인 브릿지를 구성하는 DAPP 네트워크 서비스.

크로스 체인 브릿지 살펴보기

크로스체인 브릿지가 신세대 DeFi 애플리케이션의 성능을 향상시키는 방법을 설명하기 위해 EOSIO와 이더리움 간의 토큰 전송 예를 살펴보겠습니다.

파트 1: EOSIO에서 이더리움으로 메시지 보내기

EOSIO에 가지고 있는 토큰을 이더리움으로 옮기고자 하는 사례 연구를 해보겠습니다.

EOSIO에서 이더리움으로 전송하는 동안, 다음 용어를 사용하여 체인 간에 데이터와 토큰을 전송하는 것과 관련된 스마트 계약을 설명할 것입니다.

  • 발신 계약 : EOSIO에서 트랜잭션을 수집하고 확인 된 후 이더리움에 게시하고 완결성을 달성하기 위해 영수증을 처리하는 EOSIO의 스마트 계약입니다.
  • 수신 계약 : 트랜잭션이 이더리움에서 성공적으로 실행되면 트랜잭션을 처리하고 영수증을 게시하는 이더리움 스마트 계약입니다.

다음 사항에 유의하시기 바랍니다. 이러한 스마트 계약을 직접 소유할지, 아니면 DAPP 네트워크 DSP가 구축한 브릿지의 경우와 같이 다중 서명 계약이 될지를 선택하는 것은 브릿지를 만드는 개발자의 몫입니다.

전송의 첫 번째 부분은 다음 단계로 구성됩니다.

  1. 브릿지 구성
  2. 메시지 작성
  3. 메시지 확인
  4. 메시지를 전달
  5. 영수증 생성
  6. 완결성

1단계 — 브릿지 구성

전송을 수행하기 전에 원본 계약에서는 다음을 정의합니다.

  1. 페어로 구성된 도착지 계약의 이더리움 주소
  2. 이더리움 체인 이름 입력
  3. 합의 임계값(값이 유효한 것으로 간주되기 위해 일치하는 오라클 결과로 응답해야하는 DSP 수)

참고 : 토큰이 EOSIO와 이더리움 사이를 왕복 할 수 있으려면 양쪽에 해당 토큰 계약이 배포되어 있어야합니다 (예 : EOSIO 측의 발신 계약 및 이더리움 측의 수신 계약). 누구나 이러한 스마트 계약을 배포하고 크로스 체인 전송을위한 단계를 설정할 수 있습니다.

2 단계-메시지 생성

발신 계약은 블록 타임 스탬프별로 그룹화 된 다중 인덱스 테이블의 대기열에 보류중인 메시지를 추가합니다. 메시지는 메시지 페이로드에 포함 된 금액 및 수신자와 같은 트랜잭션 파라미터와 함께 대상 계약으로 주소가 지정된 바이트 코드로 올바르게 구성된 이더리움 트랜잭션입니다.

3 단계-메시지 확인

  1. 발신 계약은 리퀴드 오라클 서비스를 사용하여 발신 계약 체인의 마지막 비가역 블록 (LIB) 시간을 주기적으로 요청하는 리퀴드 스케줄러 서비스 작업을 생성합니다. LIB는 EOS에서 완결성에 도달 한 블록을 의미하며, 이더리움에서 트랜잭션을 트리거하기 전에 필수적입니다.
  2. LIB 시간이 보류중인 메시지 그룹의 블록 타임 스탬프를 초과하면 메시지 그룹이 압축되어 vRAM 시스템을 사용하여 IPFS에 저장됩니다.
  3. IPFS URI는 멀티 인덱스 테이블의 확인 된 메시지 대기열에 추가되며, 이는 이더리움으로 전송 될 메시지에 대한 온 체인 포인터와 유사합니다.
  4. 보류중인 메시지는 보류중인 메시지 대기열에서 삭제됩니다.

4 단계-메시지 통과

  1. 발신 계약은 리퀴드링크 서비스를 사용하여 확인 된 메시지를 대상 계약에 게시하도록 DSP에 주기적으로 알리는 리퀴드 스케줄러 서비스 작업을 생성합니다.
  2. 발신 계약은 리퀴드 링크 서비스를 사용하여 확인 된 메시지를 대상 계약에 게시하도록 DSP에 주기적으로 알리는 리퀴드 스케줄러 서비스 작업을 생성하며, 알림을받은 DSP는 미결 확인 메시지를 요청하고 이를 검색하여 분석합니다. 파싱은 대상 계약의 마지막 수신 메시지를 비교하여 파일 내용 간의 차이를 계산하고 최신 메시지만 가져와 IPFS에서 최신 메시지 데이터를 압축 해제하고 이더 리움 트랜잭션을 구성하여 수행됩니다.
  3. 그런 다음 DSP는 트랜잭션을 대상 계약으로 보냅니다. 대상 계약이 합의 임계 값에 구성된 충분한 수의 DSP로부터 메시지를 수신하면 (예 : 위의 예에서 ⅔) 포함 된 트랜잭션이 대상 계약에 대해 실행됩니다.

5 단계-영수증 생성

대상 계약이 메시지 트랜잭션을 실행할 때 메시지를 처리하고 수신 확인을 생성 한 다음 저장소에 추가합니다. 영수증에는 원본 메시지와 응답이 모두 포함됩니다.

6 단계-완결성

  1. 발신 계약은 리퀴드 오라클 서비스를 사용하여 대상 계약으로부터 영수증을 주기적으로 요청하는 리퀴드 스케줄러 작업을 생성합니다.
  2. 발신 계약은 영수증을 처리하여 통신 프로세스를 완료합니다.

파트2: 이더리움에서 EOSIO로 메시지 보내기

사례 연구의 두 번째 부분에서 이더리움에서 필요한 작업을 수행했으며 이제 토큰을 EOSIO로 다시 보내고 싶습니다.

이제 EOSIO에 트랜잭션을 게시하고 영수증을 처리하여 최종성을 달성하는 이더리움 계약을 참조하는 발신 계약으로 역할이 역전됩니다. 수신 계약은 EOSIO에 있으며 트랜잭션 처리를 담당하고 성공하면 영수증을 발행합니다.

이번에는 프로세스에 7 단계가 포함됩니다.

  1. 브릿지 구성
  2. 메시지 생성
  3. 메시지 전달
  4. 영수증 생성
  5. 영수증 확인
  6. 영수증 통과
  7. 완결성

1 단계 : 브릿지 구성

전송이 발생하기 전에 원래 계약은 다음을 정의합니다.

합의 임계 값 (값이 유효한 것으로 간주되기 위해 일치하는 오라클 결과로 응답해야하는 DSP 수).

합의 멤버

2 단계 : 메시지 생성

이더리움 스마트 계약 (발신 계약)은 쌍을 이루는 EOSIO 브릿지계약 (수신 계약)과 EOSIO 리퀴드X 체인 이름을 정의합니다 (이를 통해 브리지가 모든 EOSIO 체인을 지원할 수 있음).

발신 계약은 확인 된 메시지를 저장소에 추가합니다.

3 단계 : 메시지 전달

  1. 수신 계약은 리퀴드 오라클 서비스를 사용하여 발신 계약에서 새 메시지를 주기적으로 요청하는 리퀴드 스케줄러 서비스 작업을 생성합니다.
  2. 리퀴드 스케줄러 서비스 작업을 수신하는 DSP는 이더리움에서 새 메시지를 검색합니다.
  3. 그런 다음 DSP는 새 메시지를 대상 계약으로 전송하며, 이는 또한 미결 확인 메시지를 주기적으로 처리하는 리퀴드 스케줄러 서비스 작업을 생성합니다.

4 단계 : 영수증 생성

수신 계약은 메시지를 처리하고 블록 타임 스탬프별로 그룹화 된 다중 인덱스 테이블의 대기열에 보류중인 확인을 추가합니다. 영수증은 메시지 페이로드를 포함하는 트랜잭션 파라미터와 함께 발신 계약으로 주소가 지정된 바이트 코드로 올바르게 구성된 이더리움 트랜잭션입니다.

5 단계 : 영수증 확인

  1. 수신 계약은 리퀴드 오라클 서비스를 사용하여 발신 계약 체인의 마지막 비가역 블록 시간 (LIB)을 주기적으로 요청하는 리퀴드 스케줄러 서비스 작업을 생성합니다. LIB는 EOS에서 트랜잭션을 트리거하기 전에 필수적인 이더리움에서 완결성에 도달 한 블록을 의미합니다.
  2. LIB 시간이 보류중인 수신 그룹의 블록 타임 스탬프를 초과하면 그룹이 압축되어 VRAM 서비스를 사용하여 IPFS에 저장됩니다.
  3. IPFS URI는 멀티 인덱스 테이블의 확인 된 영수증 대기열에 추가되며, 이는 이더 리움으로 전송 될 영수증에 대한 온 체인 포인터와 유사합니다.
  4. 보류중인 영수증은 보류중인 영수증 대기열에서 삭제됩니다.

6 단계 : 영수증 통과

  1. 수신 계약은 리퀴드 링크 서비스를 사용하여 확인 된 영수증을 발신 계약에 게시하도록 DSP에 주기적으로 알리는 리퀴드 스케줄러 서비스 작업을 생성합니다.
  2. 알림을 받은 DSP는 미결 확인 영수증을 요청하고 이를 검색하여 구문 분석합니다. 파싱은 대상 계약의 마지막 수신 영수증을 비교하여 파일 내용 간의 차이를 계산하고 최신 영수증 만 가져오고 IPFS에서 영수증 데이터를 압축 해제하고 이더 리움 트랜잭션을 구성하여 수행됩니다.
  3. 그런 다음 DSP는 영수증을 발신 계약으로 다시 보냅니다.

7 단계 : 완결성

발신 계약은 영수증을 처리하여 통신 프로세스를 완료합니다.

블록체인 용 브로드밴드

블록체인을 위한 광대역 전화 접속 인터넷 시대에 있었던 사람들은 아마도 네트워크 연결에 선행 할 삐걱 거리는 소리를 떠 올릴 것입니다. 되돌아 보면 이러한 수동 연결 프로세스는 5G 연결 시대에 구식으로 보입니다. 하지만 그 당시에는 인터넷에 접속할 수있는 유일한 방법이었습니다. 블록체인의 경우 체인 간의 원활한 상호 운용성 부족과 그로 인한 한계는 언젠가 전화 접속 인터넷의 시도와 유사한 맥락에서 볼 수 있습니다.

DAPP 네트워크의 교차 체인 브리지는 블록 체인의 광대역 순간입니다. 상시 연결, 무제한 연결의 출현으로 인터넷이 막히지 않고 개발자가 자신의 아이디어를 현실로 구현할 수 있었던 것처럼, 체인 간 커뮤니케이션도 블록체인 분야의 개발자에게 유동성과 확장성의 길을 열어줍니다.

브릿지 코드로 이동하여 DAPP 개밸자 텔레그램 채널에서 채팅하고 해당 브리지가 작동시켜봅시다!

[리퀴댑스]
텔레그램 :
https://t.me/liquidapps_kr
홈페이지 :
https:/liquidapps.io
미디엄 :
https://bit.ly/2Xpdx7q
*리퀴댑스는 EOS, EOSIO의 확장성 개선과 블록체인간 상호 운영성(+IBC)을 위한 서비스들을 제공합니다.

--

--