| 최신판 |
당신의 편집 |
| 1번째 줄: |
1번째 줄: |
| − | [[파일:㈜파라메타 글자.png|썸네일|300픽셀|'''㈜파라메타'''(Parameta)]]
| + | '''루프체인'''(Loopchain)<!--루프 체인, Loopchain, Loop chain-->은 [[㈜더루프]](theloop)가 독자 개발한 프라이빗 블록체인 엔진이다. 금융거래를 지원하는 것을 목적으로 개발되고 있으며, 추후 [[IoT]]환경 등 블록체인이 적용 가능한 다양한 서비스를 구성하기 위한 엔진 개발을 목표로 하고 있다. |
| − | | |
| − | '''루프체인'''(loopchain)<!--루프 체인, Loopchain, Loop chain-->은 '''[[㈜파라메타]]'''(구 ㈜아이콘루프)가 독자 개발한 블록체인 엔진이다. 금융거래 지원을 목표로 개발되고 있으며, 추후 사물인터넷([[IoT]]) 환경 등 블록체인을 적용할 수 있는 다양한 서비스를 구성하기 위한 엔진을 개발하고 있다. | |
| | | | |
| | ==개요== | | ==개요== |
| − | 루프체인은 [[하이퍼레저 패브릭]](Hyperledger Fabric)이나 R3 코다(R3 Corda)보다 블록체인의 기본에 더욱 충실한 구조로 되어 있다. 하이퍼레저 패브릭의 컨센서스 서비스나 공증인(Notary)처럼 중앙에서 [[트랜잭션]] 순서를 정해주며, 체인은 이 내용을 검증해주는 구조와 달리, 기본 비트코인 블록체인처럼 이해관계자들의 트랜잭션 순서를 합의 보증 하는 방식으로 순서를 정해주고 있다. | + | [[파일:루프체인 모듈 방식.png|썸네일|300픽셀|'''루프체인'''(Loopchain) 모듈 방식]] |
| | + | 루프체인은 [[하이퍼레저 패브릭]](Hyperledger Fabric)이나 R3 코다에 비해 블록체인의 기본에 더욱 충실한 구조를 가지고 있다. 하이퍼레저 패브릭의 컨센서스 서비스나 공증인(Notary)처럼 중앙에서 [[트랜잭션]] 순서를 정해주며, 체인은 이 내용을 검증해주는 구조와 달리, 기본 비트코인 블록체인처럼 이해관계자들의 트랜잭션 순서를 합의 보증 하는 방식으로 순서를 정해주고 있다. |
| | | | |
| − | [[㈜아이콘루프]]는 금융권 요구사항을 만족하면서 새로운 요구사항에 맞게 시스템을 변화하기 위해 루프체인을 유연한 구조로 만들고자 했다. 루프체인 모듈에서 [[어드민 레이어]]는 주로 [[블록체인]] [[네트워크]] 관리를 위해 [[노드]]의 장애 상황을 감독하고, [[스마트 계약]]의 버전을 관리하고, 각 노드의 권한을 감독한다. [[엔진 레이어]]는 블록체인 노드의 주 역할인 분산 합의, 원장 저장, 스마트 계약 실행을 담당하며, 특히 분산 합의를 위한 엔진 모듈인 블록체인과 실제 블록체인에 올라가는 서비스와 실행환경인 [[스코어]](Smart Contract on Reliable Environment; SCORE)가 분리되어 있다. 인터페이스 레이어는 다른 비즈니스 애플리케이션이 블록체인 네트워크에 접속할 수 있는 환경을 만들어준다.<ref name="블로터">더루프, 〈[http://www.bloter.net/archives/275305 (블록체인 톺아보기) 더루프, 루프체인]〉, 《블로터》, 2017-03-28</ref>
| + | ㈜더루프는 금융권 요구사항을 만족하면서 새로운 요구사항에 맞게 시스템을 변화하기 위해 루프체인을 유연한 구조로 만들고자 했다. 루프체인 모듈에서 어드민 레이어는 주로 블록체인 네트워크 관리를 위해 노드의 장애 상황을 감독하고, 스마트 계약의 버전을 관리하고, 각 노드의 권한을 감독한다. 엔진 레이어는 블록체인 노드의 주 역할인 분산합의, 원장 저장, 스마트 계약 실행을 담당하며, 특히 분산합의를 위한 엔진 모듈인 블록체인과 실제 블록체인에 올라가는 서비스와 실행환경인 스코어(Smart Contract on Reliable Environment; SCORE)가 분리되어 있다. 인터페이스 레이어는 다른 비즈니스 애플리케이션이 블록체인 네트워크에 접속할 수 있는 환경을 만들어준다.<ref name="블로터">더루프, 〈[http://www.bloter.net/archives/275305 (블록체인 톺아보기) 더루프, 루프체인]〉, 《블로터》, 2017-03-28</ref> |
| | | | |
| | ==특징== | | ==특징== |
| − | 루프체인의 1차 목표는 금융권을 위한 [[블록체인]]이기 때문에 이해당사자끼리만 데이터를 볼 수 있는 [[프라이빗]] 채널 기능, 블록체인 네트워크 참여 기관별로 다른 기능을 가지게 하는 트라이드 시스템, 마지막으로 다양한 금융 서비스를 원활하게 지원하기 위한 빠른 속도를 목표로 개발한 블록체인이다. | + | [[파일:루프체인 특징.png|썸네일|500픽셀|'''루프체인'''(Loopchain) 특징]] |
| − | | + | 루프체인의 1차 목표는 금융권을 위한 블록체인이기 때문에 이해당사자끼리만 데이터를 볼수 있는 프라이빗 채널 기능, 블록체인 네트워크 참여 기관별로 다른 기능을 가지게 하는 트라이드 시스템, 마지막으로 다양한 금융 서비스를 원할하게 지원하기 위한 빠른 속도를 목표로 개발한 블록체인이다. |
| − | [[어드민 레이어]]에서는 각 네트워크에 참여하는 노드들을 관리·감독한다. 어드민 레이어에서 각 [[노드]]의 권한을 제한하고, [[암호화]] 프로토콜을 통한 메시지 교환 방식, 또 [[비트코인]] [[라이트닝 네트워크]] 프로토콜을 이용해 트라이드 시스템과 프라이빗 채널을 구현하고 있다. 현재 각 특징을 구현하는 두 가지 방식이 있는데 이 방식은 추가될 수도, 한 가지 방식으로 통합될 수도 있다.
| |
| − | | |
| − | 루프체인에서는 높은 성능을 보장하기 위해 [[프랙티컬 비잔틴 장애 허용]](Practical Byzantine Fault Tolerance; PBFT) 방식과는 다른, 리더 중심의 분산 합의 방식과 리더 장애 극복 알고리즘을 통해 [[비잔틴 장애 허용]](Byzantine Fault Tolerance; BFT) 문제를 해결하고 있다. 또한, 블록체인 서비스를 동작하는 부분(SCORE)과 합의 엔진을 완전히 분리했고, 합의 엔진 내에서도 모듈 및 가용성 요구사항에 따라 프로세스를 여러 개 분리하는 방식으로 고성능 블록체인이 구현되었다.
| |
| − | | |
| − | 그 밖의 중요한 특징으로는 '[[포털]]'이라는 자체 개발한 프로토콜을 이용해 리더 노드를 통한 블록체인 외부 데이터(외부 블록체인) 접근 및 분산 합의 방법, 스코어의 버전 방식과 마이그레이션 없이 동작하는 네트워크에서의 업데이트 및 하위 호환성 지원, 스코어 스토어를 통한 스마트 계약 배포 및 버전 관리 등의 특징이 있다. 또한, 아이콘루프는 블록체인 내에서 인증서를 발급하는 독자 기술을 개발해 이번에 금융투자업권 컨소시움의 첫 번째 시범 모델로 사용할 예정이다.<ref name="블로터"></ref>
| |
| − | | |
| − | ===스코어===
| |
| − | [[파일:루프체인 모듈 방식.png|썸네일|400픽셀|'''루프체인'''(Loopchain) 모듈 방식]]
| |
| − | 루프체인 [[스코어]](SCORE)의 가장 큰 특징은 개발 친화적 언어를 통해 자유롭게 개발환경을 구성할 수 있다는 점이다. 대표적인 블록체인 기반 [[스마트 계약]] 플랫폼인 [[이더리움]]의 경우, 특수한 가상머신 [[EVM]](Ethereum Virtual Machine)에서 사용 가능한 언어로만 스마트 계약을 작성할 수 있다. 즉 [[솔리디티]](Solidty), [[서펀트]](Serpent), [[저급언어]](Low Level Language; LLL)를 통해서 스마트 계약을 개발 해야 하고 데이터 접근 및 저장 또한 EVM 내부 변수를 통해서만 저장할 수 있다.
| |
| − | | |
| − | 루프체인 스코어는 합의 엔진과 의존성을 최대한 떨어뜨린 별도의 모듈로 개발되었다. 합의 엔진과 스코어는 내부 [[gRPC]]로 구현된 인터페이스를 통하여 통신을 하기 때문에 인터페이스만 맞으면 어떠한 언어로도 구현이 가능하나 현재는 [[파이썬]] 구현체만 허용하고 있다. [[데이터베이스]] 또한 자유롭게 사용할 수 있다. 다만 이더리움처럼 변수의 모든 데이터가 저장되지는 않고 데이터베이스에 직접 읽고 쓴 결과만 저장된다.
| |
| − | | |
| − | * '''스코어 코드 구성'''
| |
| − | <font color="#80808B">''#!/usr/bin/env python''</font>
| |
| − |
| |
| − | <font color="blue">from</font> loopchain.blockchain <font color="blue">import</font> ScoreBase
| |
| − |
| |
| − | <font color="blue">class</font> UserScore(ScoreBase);
| |
| − | <font color="#80808B"><nowiki>''' UserScore → 기본 SCORE 코드
| |
| − | 기본 SCORE 코드는 아무런 역할을 하지 않는다.'''</nowiki></font>
| |
| − |
| |
| − | <font color="blue">def</font> invoke(<font color="#9F558D">self</font>, transaction, block);
| |
| − | <font color="blue">pass</font>
| |
| − |
| |
| − | <font color="blue">def</font> query(<font color="#9F558D">self</font>, **kargs);
| |
| − | <font color="blue">pass</font>
| |
| − | | |
| − | # <code>invoke()</code> : 검증이 완료된 블록의 데이터를 내장된 별도의 데이터베이스에 추가한다.
| |
| − | # <code>query()</code> : 내부 데이터를 조회한다.<ref name="아이콘 백서">아이콘, 〈[https://icon.foundation/resources/whitepaper/ICON-Whitepaper-KO-Draft.pdf ''ICON Hyperconnect the World'']〉, 《''아이콘 백서''》, 2018-01-31</ref>
| |
| − | | |
| − | * '''스코어 기반 채팅 서비스'''
| |
| − | : 채팅 서비스는 중계자가 필요한 대표적인 서비스이다. 채팅 참여자는 각자가 직접 연결되지 않고 채팅 서버와 연결한 후 채팅 서버에서 보내주는 다른 참여자의 말을 믿고 대화를 진행한다. 즉, 대화 당사자가 아닌 채팅 서버라는 별도의 [[TTP]](Trusted Third Party)가 대화라는 거래를 중계해주는 방식이라고 할 수 있다. 이를 스마트 계약으로 구성한다면, 채팅 참여자가 각각 블록체인 노드를 구성하고 대화 내용을 포함하고 서명을 하여 거래를 발생시키면 해당 거래가 동기화되고 거래 내역이 정당하면(채팅 참여자의 서명이 맞으면) 거래에 포함된 대화 내용을 전체 대화록에 추가하는 방식이다.<ref name="아이콘루프">아이콘루프, 〈[https://blog.theloop.co.kr/category/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8/ LFT – loopchain consensus algorithm]〉, 《아이콘루프 블로그》, 2017-07-04</ref>
| |
| − | | |
| − | ===루프 장애 허용===
| |
| − | [[파일:루프 장애 허용.png|썸네일|500픽셀|'''루프 장애 허용'''(Loop Fault Tolerance; LFT)]]
| |
| − | [[루프 장애 허용]](Loop Fault Tolerance; LFT)은 현재 루프체인에서 사용하는 [[합의 알고리즘]]이다. 그러나 루프체인은 [[플러그인]](Pulgin) 형태로 합의 알고리즘이 구현되어 있기 때문에 필요에 따라 [[프랙티컬 비잔틴 장애 허용]]과 같은 다른 합의 알고리즘을 사용할 수 있다. 다음에 루프체인은 [[깃허브]](Github)를 통해 오픈소스 프로젝트로 공개될 것이기 때문에 직접 다운로드 받고 실행 시킬 수 있다.
| |
| − | | |
| − | 루프 장애 허용은 기존 [[프랙티컬 비잔틴 장애 허용]]을 사용하는 합의 알고리즘에서 발생하는 통신 오버헤드를 [[피기배킹]](Piggybacking)을 이용하여(네트워크에서 메시지를 통합하여 통신 오버헤드를 감소시키는 방법) 줄였으며, 스피닝(Spinning) 기법(리더를 매번 교체하는 기법)을 이용하여 악의적인 [[노드]]가 네트워크의 [[합의]]를 해치지 않는 범위에서 네트워크에 문제를 일으킬 수 있는 특정 노드의 [[트랜잭션]] 거부 문제, 리더에 의한 네트워크 지연과 같은 문제를 해결했다. 또한, 기존 알고리즘들이 가지고 있던 지나치게 복잡한 리더 선정 알고리즘을 단순화하였다.
| |
| − | | |
| − | 네트워크가 시작되면 검증 노드(검증을 통해 합의에 참여하는 노드)들은 사전에 결정된 리더 노드에게 처리를 원하는 트랜잭션을 전송한다. 리더 노드는 수집한 [[트랜잭션]]을 이용하여 블록을 생성하고 자신의 서명과 함께 다른 모든 검증 노드에게 전송한다. 각 검증 노드들은 [[블록]]을 받으면 현 리더가 블록을 생성했는지 확인하고, 블록의 높이와 [[이전 블록 해시]]가 올바른지 확인하며, 블록의 데이터가 올바른지 확인한다. 검증 노드는 위 세 가지 방법이 옳다면 투표 데이터를 생성하여 네트워크의 모든 노드들에게 전파한다. 투표 데이터를 전체 노드에게 전파하는 것은 매우 중요한데, 이는 리더 노드가 비잔틴일 경우 정족수 이상의 노드들에게만 블록을 전파하여 특정 노드들을 네트워크로부터 분리하도록 시도할 수 있기 때문이다. 이러한 문제를 방지하기 위해 모든 피어에게 투표 데이터를 전파하며 이는 기존 [[Raft 알고리즘]]과 다른 부분이다. 이 과정에서 블록을 못 받은 노드는 블록이 생성되었는지에 대한 정보를 알 수 있고 다른 노드에게 블록을 요청할 수 있다.<ref name="아이콘루프"></ref>
| |
| − | | |
| − | ===멀티채널===
| |
| − | [[멀티채널]](Multi-channel)은 하나의 독립적인 블록체인 네트워크 내에서 업무별로 채널이라는 가상의 네트워크를 구성하여 채널별로 거래 요청, 합의 및 스마트 계약을 수행할 수 있는 기능이다. 하나의 노드에 여러 업무별로 해당 업무 당사자들만 연결된 다양한 채널을 형성하기 때문에 채널별로 무결성 보장 및 합의가 이루어지며 거래 데이터를 실제 거래 당사자들만 보유하게 되어 다양한 규제에 대응할 수 있다.
| |
| − | | |
| − | ===계층형 시스템===
| |
| − | 블록체인 네트워크 참여를 위한 인증과 함께 거래 별로 PKI 기반 인증을 통해 거래내역 검증 및 보안이 이루어진다. 또한, 거래에 참여하지 않지만, 필요에 따라 거래 내역에 대한 감사를 수행할 수 있는 기능을 특정 노드에 부여하는 기능도 지원한다.<ref name="아이콘 백서"></ref>
| |
| − | | |
| − | [[파일:계층형 시스템 구조.png|썸네일|500픽셀|계층형 시스템 구조]]
| |
| − | * '''1계층''' : 관리감독 단위(Supervision Unit)로서, 관리와 감독을 총괄하고 전체 노드들의 활동을 관리 및 지원한다. 다음은 1계층의 예이다.
| |
| − | # 감독당국 각종 증권거래 관리/감독
| |
| − | # 세금계산 및 소득공제 등의 1계층 서비스 제공
| |
| − | | |
| − | * '''2계층''' : 조율 단위(Adjustment Unit)로서, 1계층과 3계층을 연결 및 조율하며 협회/조합 등으로 구성된다. 다음은 2계층의 예이다.
| |
| − | # 금융투자협회 등
| |
| − | # 1계층의 관리감독 및 의사결정 지원
| |
| − | # 3계층 구성원들의 활동 지원 및 유관 서비스 창출
| |
| − | | |
| − | * '''3계층''' : 사업 단위(Business Unit)로서, 실질적인 사업기능을 보유한 노드로 구성된다. 다음은 3계층의 예이다.
| |
| − | # 은행/증권사 등의 각 개별 금융사
| |
| − | # 노드 간 블록 공유를 통한 인프라 비용 및 보안 리스크 감소 추구
| |
| − | # 각 노드의 이상 징후/불법 행위 사전 감지 및 대응
| |
| | | | |
| − | ===모듈화 구조===
| + | 어드민 레이어에서는 각 네트워크에 참여하는 노드들을 관리·감독한다. 어드민 레이어에서 각 노드의 권한을 제한하고, 암호화 프로토콜을 통한 메세지 교환 방식, 또 비트코인 라이트닝 네트워크 프로토콜을 이용해 트라이드 시스템과 프라이빗 채널을 구현하고 있다. 현재, 각 특징을 구현하는 2가지 방식이 있는데 추후에 늘어날 수도, 한가지 방식으로 통합될 수도 있다. |
| − | 루프체인의 모듈화 구조는 [[노드]] 검증, [[합의 알고리즘]], [[스마트 계약]] 등을 위한 모듈의 커스텀화를 필요할 때 언제든 가능하게 한다.<ref>ICON Project, 〈[https://brunch.co.kr/@helloiconworld/14 ICON 프로젝트 #6. Inside ICON (3)]〉, 《브런치》, 2017-08-11</ref>
| |
| | | | |
| − | ==비교==
| + | 루프체인에서는 높은 성능을 보장하기 위해 프랙티컬 비잔틴 장애 허용(Practical Byzantine Fault Tolerance; PBFT) 방식과는 다른, 리더 중심의 분산합의 방식과 리더 장애 극복 알고리즘을 통해 비잔틴 장애 허용(Byzantine Fault Tolerance; BFT) 문제를 해결하고 있다. 또한 블록체인 서비스를 동작하는 부분(SCORE)과 합의엔진을 완전히 분리했고, 합의엔진 내에서도 모듈 및 가용성 요구사항에 따라 프로세스를 여러 개 분리하는 방식으로 고성능 블록체인이 구현되었다. |
| − | {| class="wikitable" width="100%" style="color:balck; height:250px; text-align:center; background-color:#F8F9FA;"
| |
| − | |+ style="height:35px;" | <big>퍼블릭 블록체인과 엔터프라이즈 블록체인 비교</big>
| |
| − | |-
| |
| − | ! rowspan="2" colspan="2" width="15%" | 특성 항목 || 엔터프라이즈 블록체인 || colspan="2" | 퍼블릭 블록체인
| |
| − | |-
| |
| − | ! width="29%" | 루프체인 || width="28%" | 비트코인 || width="28%" | 이더리움
| |
| − | |-
| |
| − | | colspan="2" | 시멘틱 데이터 구조 || 바로 이전 블록의 해시값, 트랜잭션 리스트, 블록 생성 노드 ID, 블록 검증 피어의 서명, 블록 생성 노드의 서명 등
| |
| − | | 바로 이전 블록의 해시값, 트랜잭션 리스트, 블록 생성 노드 ID, 블록 검증 피어의 서명, 블록 생성 노드의 서명 등
| |
| − | | 바로 이전 블록의 해시값, 트랜잭션 리스트, 엉클 블록 리스트를 포함하는 헤더
| |
| − | |-
| |
| − | | colspan="2" | 네트워크 타입 || 프라이빗, 컨소시엄 || 퍼블릭 || 노드의 배치에 따라 프라이빗, 컨소시엄, 퍼블릭 형태 지원
| |
| − | |-
| |
| − | | colspan="2" | 참여자 || 신원이 판명된 참여자 || 불특정 다수<br>(신뢰할 수 없는 사용자 포함) || 노드의 배치에 따라 상이<br>(불특정 다수/신원이 판명된 참여자)
| |
| − | |-
| |
| − | | rowspan="2" | 합의 || 알고리즘 || 프랙티컬 비잔틴 장애 허용 || 작업증명(Proof of Work; PoW) || 작업증명/지분증명(Proof of Stake; PoS)
| |
| − | |-
| |
| − | | 완결성 || 비잔틴 장애 허용 알고리즘으로 분기가 존재하지 않는다. 하나의 블록 검증 시 즉시 완결
| |
| − | | 시간의 흐름에 따라 새 블록의 검증 시 거래 역분개의 가능성 존재
| |
| − | | 시간의 흐름에 따라 새 블록의 검증 시 거래 역분개의 가능성 존재
| |
| − | |-
| |
| − | | rowspan="2" | 계약 || 계산력 || 튜링 완전성 지원 || 스택 기반 언어<br>(단순한 인스트럭션만 제공) || 튜링 완전성 지원
| |
| − | |-
| |
| − | | 프로그래밍<br>언어 || 파이썬 || 스크립트(Script)|| 솔리디티, 서펀트, 저급언어 등 처리되는 다양한 언어 지원
| |
| − | |-
| |
| − | | 지연<br>시간 || 블록 확정<br>시간 || 1초 미만 || 10분당 1블록 || 14초당 1블록
| |
| − | |-
| |
| − | | colspan="2" | 최대 트랜잭션<br>/계약 크기 || 애플리케이션에 따라 유동적 || 100KB || 가스 사용량에 따라 유동적
| |
| − | |-
| |
| − | | colspan="2" | 확장성/트랜잭션 처리량 || 1,000TPS 이상 || 7TPS || 15TPS
| |
| − | |-
| |
| − | | colspan="2" | 프라이버시 || 서비스 채널 암호화를 통해 프라이버시 보호 || 개방 || 개방
| |
| − | |-
| |
| − | |}
| |
| | | | |
| − | {| class="wikitable" width="100%" style="color:balck; height:250px; text-align:center; background-color:#F8F9FA;"
| + | 그 밖의 중요한 특징으로는 '포털'이라는 자체 개발한 프로토콜을 이용해 리더 노드를 통한 블록체인 외부 데이터(외부 블록체인) 접근 및 분산합의 방법, 스코어의 버전 방식과 마이그레이션 없이 동작하는 네트워크에서의 업데이트 및 하위 호환성 지원, 스코어 스토어를 통한 스마트 계약 배포 및 버전관리 등의 특징이 있다. 또한 더루프는 블록체인 내에서 인증서를 발급하는 독자 기술을 개발해 이번에 금융투자업권 컨소시움의 첫 번째 시범 모델로 사용할 예정이다.<ref name="블로터"></ref> |
| − | |+ style="height:35px;" | <big>프라이빗 블록체인 간의 비교</big>
| |
| − | |-
| |
| − | ! width="20%" | 항목 || width="25%" | 루프체인 || width="25%" | 하이퍼레저 패브릭 || width="25%" | R3 코다
| |
| − | |-
| |
| − | | 허가된 사용자만 접근 가능 || ○ || ○ || ○
| |
| − | |-
| |
| − | | 스마트 계약 지원 || ○ || ○ || ○
| |
| − | |-
| |
| − | | 다양한 합의 알고리즘 지원 || ○ || ○ || ○
| |
| − | |-
| |
| − | | 스마트 계약 버전 지원 || ○ || Ｘ || Ｘ
| |
| − | |-
| |
| − | | 장애 허용 || ○ || Ｘ || Ｘ
| |
| − | |-
| |
| − | | 트랜잭션 커스터마이징 || ○ || Ｘ || Ｘ
| |
| − | |-
| |
| − | | SDK 지원 플랫폼 || 자바, C, 파이썬, Node.js || Go, 자바 || 코틀린(Kotlin)
| |
| − | |-
| |
| − | | 비고 || 거래 및 규제에 따라<br>전체 스택 커스터마이징 가능 || 0.x 버전과 1.0 버전 호환이 불가하며,<br>1.0 버전에 대한 릴리즈 일정 미정
| |
| − | | R3 회원사가 아니면<br>기술지원 불가
| |
| − | |-
| |
| − | |}<ref>〈[https://site.ieee.org/bcsummitkorea-2018/files/2018/06/D2_loopchain101_DHLee.pdf loopchain 101]〉, 《theloop》</ref>
| |
| | | | |
| | {{각주}} | | {{각주}} |
| | | | |
| | ==참고자료== | | ==참고자료== |
| − | * 더루프, 〈[http://www.bloter.net/archives/275305 (블록체인 톺아보기) 더루프, 루프체인]〉, 《블로터》, 2017-03-28 | + | * 더루프, 〈[http://www.bloter.net/archives/275305 (블록체인 톺아보기) 더루프, 루프체인]〉, 《블로터》, 2017-03-28</ref> |
| − | * 아이콘루프, 〈[https://blog.theloop.co.kr/category/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8/ LFT – loopchain consensus algorithm]〉, 《아이콘루프 블로그》, 2017-07-04
| |
| − | * 〈[https://site.ieee.org/bcsummitkorea-2018/files/2018/06/D2_loopchain101_DHLee.pdf loopchain 101]〉, 《theloop》
| |
| − | * 아이콘, 〈[https://icon.foundation/resources/whitepaper/ICON-Whitepaper-KO-Draft.pdf ''ICON Hyperconnect the World'']〉, 《''아이콘 백서''》, 2018-01-31
| |
| − | * ICON Project, 〈[https://brunch.co.kr/@helloiconworld/14 ICON 프로젝트 #6. Inside ICON (3)]〉, 《브런치》, 2017-08-11
| |
| | | | |
| | ==같이 보기== | | ==같이 보기== |
| − | * [[㈜아이콘루프]]
| |
| − | * [[㈜더루프]]
| |
| − | * [[루프 장애 허용]]
| |
| − | * [[스코어]]
| |
| − | * [[하이퍼레저 패브릭]]
| |
| − | * [[프랙티컬 비잔틴 장애 허용]]
| |
| − | * [[비잔틴 장애 허용]]
| |
| − | * [[스마트 계약]]
| |
| − | * [[IoT]]
| |
| | | | |
| | {{블록체인 기술|검토 필요}} | | {{블록체인 기술|검토 필요}} |
위키원
