ICON 생태계에 있어서 ICON 2.0이 가지는 의미

* 오역과 의역 많음 (제보는 추천 후, 댓글로 남겨주세요~)

 

* 이 글은 열정적인 아이코니스트(ICON 커뮤니티 유저/홀더)인 BrianLi 의 글을 번역한 것입니다.

 

 

 

ICON 2.0은 ICON 블록체인과 더 넓은 ICON 생태계에 있어 기념비적인 변화입니다. ICON 2.0은 상호운용성을 위한 BTP, Java SCORE 지원, 완전히 새로운 코어 블록체인 엔진, EVM 호환 사이드체인 등과 같은 수많은 새로운 기술을 제공합니다. 이 글에서는 ICON 2.0이 ICON의 채택(선택)에 어떤 영향을 미칠 수 있는지 기술적인 관점에서 살펴보겠습니다.

 

* 상호운용성:(Interoperability, 相互運用性) 하나의 시스템이 동일 또는 이기종의 다른 시스템과 아무런 제약이 없이 서로 호환되어 사용할 수 있는 성질을 말한다.

* BTP: ICON 블록체인 연결 / 인터체인(상호운용성) 기술

* SCORE: ICON의 향상된 스마트 컨트랙트 기능

* EVM: 이더리움 가상머신

 

 

 

 

블록체인 전송 프로토콜 (BTP / Blockchain Transmission Protocol)

 

많은 ICON 커뮤니티원들에게 BTP는 ICON 2.0의 향상된 기술 중 단연코 가장 흥미로운 기능일 것입니다. BTP는 "블록체인 전송 프로토콜"의 줄임말인 ICON의 크로스-체인 상호운용성 솔루션입니다. BTP를 사용하면 ICON이 연결된 (타 프로젝트 / 코인) 블록체인 간에 정보들을 쉽게 전송할 수 있습니다. 실제로 BTP는 사용자가 토큰, NFT, 메시지 등을 BTP 지원 체인 간에 이동할 수 있도록 허용합니다. 현재, (공식적인) BTP 통합은 폴카닷(Polkadot), 쿠사마(Kusama), 하모니(Harmony), 니어(NEAR), 바이낸스 스마트 체인(Binance Smart Chain)에서 개발되고 있습니다.

 

 

BTP는 사용 사례(use cases)는 거의 무제한(near-limitless)에 가깝지만, ICON에서 널리 사용되고 있는 DeFi dApp인 밸런스드(Balanced)의 기능을 확장하는 데 BTP를 활용하는 방법을 예를 들어 보겠습니다. 밸런스드에는 예치한 담보를 통해 bnUSD를 발행하고, 밸런스드에서 기본 제공되는 DEX(탈중앙화된 거래소)에서 지원하는 자산을 거래하는 두 가지 핵심 기능이 있습니다. 현재 밸런스드는 ICX, BALN, USDS와 같은 ICON 고유 자산만을 지원하며. 크로스-체인 전송을 위한 오르빗 브릿지(Orbit Bridge)와 같은 솔루션이 있지만(이것이 IUSDC를 사용하는 방법입니다), 아직 완벽하게 신뢰할 수는 없는 방식으로, ICON과 주고받는 크로스-체인 활동을 수행하는 방법은 없습니다.

 

 

현존하는 가장 섹시한 DeFi dApp인 밸런스드는 BTP와 함께라면 더욱 섹시해질 것입니다.

 

이 모든 것은 BTP가 출시되면서 바뀔 것입니다. BTP를 통해 밸런스드는 지원되는 모든 (타 프로젝트) 체인들의 자산을 쉽게 상장(list assets / 지원) 할 수 있게 됩니다! 즉, 가까운 미래에 DOT/bnUSD, NEAR/sICX 및 ONE/bnUSD와 같은 추가 거래 쌍이 나타날 것으로 예상합니다. 또한 BTP는 bnUSD(밸런스드 스테이블 코인)가 sICX 이외의 여러 담보들을 지원할 수 있도록 하여 bnUSD의 관련 위험들(risk profile)을 줄일 수 있습니다.

 

 

ICON은 상호 운용성에 중점을 둔 유일한 프로젝트는 아닙니다. 코스모스(Cosmos), 폴카닷(Polkadot), 솔라나(Solana)등도 크로스-체인 통신을 제공합니다. 그렇다면, BTP가 다른 상호 운용성 솔루션과 어떻게 다른지 빠르게 살펴보겠습니다.

 

 

 

 

 

아이콘 vs. 코스모스와 폴카닷

암호화폐 트위터(Crypto Twitter)들에서는 상호 운용성 논쟁이 있을 때마다 코스모스와 아이콘의 비교를 보는 것을 흔히 볼 수 있습니다. 실제로 코스모스(ATOM)와 아이콘(ICX)을 비교하는 것은 자전거와 스쿠터를 비교하는 것과 비슷합니다. 둘 다 운송 수단이지만 완전히 다릅니다.

 

 

ICON은 BTP(Interoperability Solution)가 내장된 스마트 컨트랙트가 가능한 L1 블록체인이고 코스모스는 독립적(independent)이지만 상호 운용 가능한 블록체인 네트워크입니다.

 

 

코스모스에서는 개발자가 코스모스 SDK(소프트웨어 개발 키트)를 이용해 텐더민트 합의 알고리즘을 사용하는 블록체인을 시작할 수 있습니다. 코스모스 SDK로 블록체인을 시작한 후, 코스모스의 IBC(Inter-Blockchain Communication Protocol)을 통해 다른 코스모스 기반(Cosmos-based) 블록체인들과 연결할 수 있습니다. 간단히 말해서, 코스모스는 개발자들이 코스모스 생태계 내의 다른 체인과 통신하고, 활용할 수 있는(deploy) 프레임워크와 도구 모음을 제공합니다.

 

 

폴카닷은 코스모스와 많은 부분에서 유사점을 가지지만, 몇 가지 주요 차이점이 있습니다. 폴카닷에서 개발자들은 폴카닷 릴레이(전달) 체인을 통해 서로 통신할 수 있는 "다양한 개별 레이어-1 블록체인들"인 파라체인을 활용할 수 있습니다. 코스모스와 비슷하게 폴카닷 파라체인들은 다른 파라체인들과 통신하도록 설계되었지만, 폴카닷 생태계 외부의 체인(예: 이더리움, 아발란체, 솔라나 등)과 통신하는 파라체인을 개발하는 것도 가능합니다.

 

 

이쯤에서 아이콘(ICX), 코스모스(ATOM), 폴카닷(DOT)의 차이를 더 명확하게 이해하길 바랍니다. 

코스모스와 폴카닷은 각각의 생태계 내에서 상호 운용 가능한 애플리케이션-레이어(application-layer) 블록체인을 구축하기 위한 프레임워크, 아키텍처 및 도구를 제공합니다. 반면 ICON은 프레임워크나 합의 알고리즘 요구 사항 없이 스마트 컨트랙트가 가능한 다른 블록체인들과 연결할 수 있는 애플리케이션-레이어 블록체인입니다.

 

 

 

 

 

아이콘 vs. 솔라나 웜홀(Wormhole)

솔라나의 웜홀은 연결된 체인 간에 메시지를 전달(relay) 하기 위해 "가디언(Guardians)"들에 의존하는 상호 운용성 솔루션입니다. 웜홀의 가디언은 솔라나 검증인의 엄선된 하위 집합으로 구성되어 있습니다. 설계상, 분산형 신뢰 기반 시스템(decentralized trust-based system)입니다. 왜냐하면 그것은 대부분의 가디언들이 항상 네트워크의 이익을 위해 행동할 것이라고 가정하기 때문입니다.

 

 

 

 

ICON의 BTP는 웜홀과 달리 신뢰를 기반으로하는 솔루션이 아닙니다. BTP 메시지는 릴레이어(relayers / 중계자)들에 의해 체인 간 소통(communicated)합니다. 웜홀의 가디언들은 메시지 검증(verification)과 중계(relaying)를 모두 수행해야하지만, BTP의 중계자는 메시지만 중계합니다. 

ICON의 BTP 모델에서 메시지 검증은 중계된 메시지가 정확히 도착했는지 확인하기 위해 발신-체인(source chain)의 합의 내역을 "재생(play back)"하는 기능이 있는 검증 컨트랙트(계약)에 의해 착신-체인(destination chain)에서 수행됩니다. 따라서, (중계자들의 신뢰를 기반으로 검증까지 맡겨야하는 솔라나와 달리) ICON의 BTP에서 중계자의 작업은 단순하게 메시지를 중계하는 것 뿐이기에 중계자들이 공모(결탁)하는 것을 불가능하게 합니다.

 

BTP, 폴카닷, 코스모스, 웜홀 등의 차이점에 대한 자세한 설명을 보려면 Iconographer의 BTP 가이드를 읽는 것을 추천합니다.

 

 

 

 

 

Goloop – 새로운 블록체인 엔진

ICON 2.0의 핵심은 Go 라는 언어로 작성된 새로운 블록체인 엔진인 Goloop입니다. Golang이라고도 알려진 Go는 원래 고성능 네트워킹 및 다중처리(Concurrency)을 위해 구글(Google)에서 개발한 컴파일된 프로그래밍 언어입니다. 이제 ICON 2.0의 Goloop가 큰 이슈가 되는 이유를 살펴보겠습니다.

 

 

ICON 1.0의 "loopchain" 블록체인 엔진은 파이썬(Python)으로 구현되었습니다. 파이썬은 세계에서 가장 인기 있는 프로그래밍 언어 중 하나이지만(쉽게 시작할 수 있습니다), 다중(여러개의) CPU 코어 또는, 스레드의 병렬 처리를 통해 얻을 수 있는 빠른 반응 속도(latency) 성능이 많이 부족했습니다.

 

그렇다면 Golang, Rust, C++와 같이 성능이 더 뛰어난 언어가 있는데 왜 ICON 1.0이 파이썬으로 구현되었을까요? 아이콘루프(ICONLOOP)의 내부 의사 결정 프로세스에 대해서 알 수는 없지만 반복 속도와 효율성에서 비롯된 것 같습니다. 파이썬은 작성하기 쉽기 때문에 신속한 프로토타이핑 및 초기 제작 배포에 이상적이긴합니다.

 

예를 들어 유튜브와 드랍박스는 모두 초기에 파이썬을 주로 사용하는 응용 프로그램으로 시작했습니다. 지난 몇 년 동안 두 회사는 Go에서 많은 핵심 백엔드 서비스를 다시 작성했습니다. ICON이 정확히 이 작업을 수행하고 있습니다. 아이콘 1.0에서 아이콘 2.0으로의 전환.

 

 

 

 

 

파이썬 성능 병목 현상

 

지연 시간이 짧은 블록체인 컨텍스트에서 파이썬의 성능 병목 현상은 프로그래밍 언어의 두 가지 특성, 즉 글로벌 인터프리터 잠금(GIL)과 해석된 특성에서 비롯됩니다.

 

간단히 말해서, 파이썬의 GIL은 주어진 시간에 오직 하나의 스레드만 코드를 실행할 수 있도록 보장한다. 사용 사례에 따라 파이썬의 GIL은 엄청난 성능 병목 현상이 될 수 있습니다. 파이썬과 달리 Go에는 GIL이 없다. 대신 Go는 "goroutins"를 통해 최고 수준의 동시처리(concurrent)를 지원하므로 코드가 진정으로 동시에 여러개의 수평적으로 확장 가능한 방식으로 실행될 수 있는 1등급 동시처리 성능을 제공합니다.

 

 

인터프리터 스크립팅 언어인 파이썬과 달리 Go는 컴파일 언어입니다. 컴파일된 언어로 작성된 프로그램은 컴파일해야 실행할 수 있습니다. 컴퓨터 공학의 기본 원리를 이해하지 않고, 컴파일은 프로그래밍 언어를 컴퓨터의 고유어인 기계어로 번역하는 것을 말한다. 반면에 인터프리터 언어는 컴파일되지 않고 파이썬, 자바스크립트 또는 Perl과 같은 인터프리터에 의해 실시간으로 처리되고 실행됩니다.

 

컴파일된 언어와 인터프리터 스크립팅 언어의 차이점을 이해하려면 영어만 말하는 사람이 일본어만 말하는 사람과 의사 소통을 하려고 한다고 상상해 보십시오. 이 비유에서 컴파일된 언어는 일본어를 배우는 것과 유사하므로 직접적이고 효율적으로 의사 소통할 수 있습니다. 한편, 인터프리터 스크립팅 언어는 의사 소통을 위해 전문 번역가에게 의존하는 것과 같습니다.

 

 

 

 

 

ICON 1.0 vs. ICON 2.0 성능

ICON 2.0은 아직 메인넷에 출시되지 않았기 때문에 Goloop가 얼마나 빠를지 정확히 알려드릴 수는 없지만, 일반적으로 Go는 파이썬 보다 기하급수적으로 빠를 수 있습니다. Stream.io 블로그 게시물에서, 그들은 파이썬에서 Go로 전환 한 후 40배의 성능 향상을 관찰했다고 합니다.

 

블록체인과 관련하여 기하급수적인 성능 향상을 논의할 때는 성능과 블록 시간을 구분하는 것이 중요합니다. 즉, 성능이 40배 향상된다고 해서 ICON의 블록생성 시간이 2초에서 0.05초로 빨라지는 것은 아닙니다. 이것이 의미하는 바는 ICON 2.0 노드가 동일한 시간에 더 많은 부하를 처리할 수 있다는 것입니다. 궁극적으로 파이썬에서 Go로의 전환은 ICON 블록체인에 더 많은 처리량과 블록당 더 많은 트랜잭션을 처리할 수 있는 기능을 제공할것입니다.

 

 

 

 

 

 

Java SCOREs

ICON 2.0에서 파이썬이 더 이상 사용되지 않는 또 다른 영역있습니다. ICON의 스마트 컨트랙트 실행 환경인 SCORE입니다.

ICON 1.0에서 스마트 컨트랙트는 빠른 프로토타이핑 및 초기 제작 배포를 위한 훌륭한 언어인 파이썬으로 작성되었습니다. 파이썬과 비교하여 자바(Java)는 몇 가지 장점이 있습니다. Go와 마찬가지로 Java도 컴파일된 언어입니다. 즉, Java 프로그램은 일반적으로 파이썬 프로그램보다 훨씬 빠르다는 것을 의미합니다.

 

 

파이썬과 자바의 또 다른 차이점은 입력입니다. 파이썬은 동적으로 입력되는 반면, 자바는 정적으로 입력됩니다. 간단히 말해, Java의 정적 유형 특성으로 인해 런타임이 아닌 컴파일 시간에 오류가 발견되기 때문에 미션 크리티컬 애플리케이션을 개발할 때 보다 안전한 선택이 가능합니다. 스마트 컨트랙트에 있어서 오류가 없는 코드 실행이 매우 중요합니다!

 

실질적으로 Java SCORE는 ICON 생태계의 개발자들에게 환영할만한 변화일것입니다. 이전에는 파이썬 SCORE들은 ICON에 의해 모두 수동으로 감사를 받아야 했습니다. 앞으로 Java SCORE는 스마트 컨트랙트를 실행할 수 있는 안전한 환경을 제공하는 JVM(Java Virtual Machine) 내에서 실행되므로 더 이상 수동 감사를 받지 않아도 됩니다.

 

 

 

 

 

 

ICE = EVM × eWASM × BTP

 

올해 초 ICON 재단은 EVM(이더리움) 및 eWASM(이더리움2.0)과 호환되는 새로운 BTP 지원 블록체인인 ICE를 공개했습니다. EVM은 "Ethereum Virtual Machine"의 약자로 이더리움의 계산 계층(computational layer)입니다. 이더리움의 스마트 컨트랙트 프로그래밍 언어인 솔리디티(Solidity)로 작성 컴파일된 스마트 컨트랙트를 실행하는 데 필요한 모든 기본 요소로 구성됩니다.

 

 

블록체인 공간에서 EVM 호환성은 이더리움 dApp을 다른(종종 더 빠르고 저렴한) 블록체인들에 배포할 수 있게 해주기 때문에 중요합니다. EVM 호환 체인은 이더리움 가상 머신의 네이티브 구현 내에서 솔리디티 스마트 컨트랙트를 실행할 수 있는 체인입니다. 에이브(Aave)는 여러 EVM 호환 블록체인에 배포된 dApp의 예입니다. 이더리움에서 시작한 에이브는 폴리곤(Polygon), 가장 최근에는 아발란체(Avalanche)로 나아갔습니다.

 

 

아발란체에 배치된 Aave.

 

 

폴리곤과 아발란체의 EVM 호환성이 없었다면 Aave를 마이그레이션하는 것이 불가능하거나 경제적이지 못했을 것입니다.

 

이 점을 더 자세하게 설명하기 위해, Aave를 EVM과 호환되지 않는 블록체인인 ICON으로 마이그레이션하는 프로세스를 상상해 보십시오. 이를 위해서는, Aave 스마트 컨트랙트를 ICON의 스마트 컨트랙트 언어인 Java로 완전히 다시 작성해야 합니다. 이것은 상당한 자원(resources)을 필요로 하며, EVM 호환 체인에 Aave를 배포하는 것이 훨씬 쉽기 때문에 아마 절대 일어나지 않았을 것입니다.

 

 

폴리곤과 아발란체와 마찬가지로 ICE를 통해 개발자는 이더리움용으로 설계된 솔리디티 컨트랙트를 활용할 수 있습니다.

 

그 보다 더 좋은 점은! ICE는 출시부터 BTP를 사용할 수 있다는 것입니다. 즉, 아이콘(ICX), 폴카닷(DOT), 쿠사마(KSM), 바이낸스 스마트 체인(BSC), 니어(NEAR), 하모니(ONE) 등과 같은 주요 프로젝트와 직접 연결되는 최초의 EVM 호환 블록체인이 될 것입니다.

 

ICE의 BTP 연결은 개발자들에게도 엄청난 매리트가 될 것이라고 생각합니다. 생각해 보십시오. 크로스-체인 통합이 없는 EVM 호환 체인을 배포하시겠습니까? 아니면 크로스-체인 통합이 많은 EVM 호환 체인을 배포하시겠습니까?

 

 

 

그렇다면, ICE는 ICON 블록체인에 어떤 혜택을 줄까요? 머리에 떠오르는 몇 가지 시나리오는 다음과 같습니다:

 

- ICE 거버넌스(운영/경영)는 ICE 토큰이 아닌 ICX 토큰에 의해 처리됩니다. 즉, 아직 ICX를 보유하지 않은 ICE의 검증인은 공개 시장에서 ICX를 구매해야 합니다.

- ICE는 이더리움 dApp이 서로 다른 체인들의 자산과 상호 작용할 수 있습니다. 예를 들어, Aave의 ICE 버전은 폴카닷, 니어 및 하모니에서 대규모로 래핑(wrapped)된 자산의 차용 및 대출을 지원할 수 있습니다. 이와 같은 사용 사례들은 BTP 사용을 촉진하여 ICON에 도움이 됩니다. (BTP 사용 수수료는 ICX)

- ICE는 ICX 보유자에게 수익을 극대화할 수 있는 또 다른 전략을 제공합니다. ICON과 ICE는 모두 지분 증명(proof-of-stake) 블록체인이기 때문에 ICX 보유자는 시장 상황에 따라 두 체인 간에 ICX 스테이킹(stake)을 재할당할 수 있습니다.

 

 

많은 EVM 호환 블록 체인들과 달리 ICE는 eWASM 호환이 될 것이다. eWASM은 "Ethereum WebAssembly"의 줄임말로, 코드 실행을 위한 오픈 소스 명령어 집합인 WebAssembly의 하위 집합입니다. eWASM은 이더리움 2.0에서 EVM을 대체하게됩니다. EVM과 비해 eWASM은 개발자들을 위한 더 많은 웹어셈블리 기반 도구에 대한 액세스와 함께 스마트 컨트랙트를 위한 훨씬 빠른 실행 환경을 제공합니다.

 

 

처음부터 eWASM 지원을 포함함으로써 ICE는 출시부터 이더리움 2.0용으로 설계된 dApp과 호환됩니다. ICE의 BTP 연결과 결합된 eWASM 호환성은 업계에 있는 다른 EVM 호환 체인에 비해 몇 가지 뚜렸한 이점들을 제공합니다. 이러한 점을 염두에 두고, 잃을 것은 거의 없고 얻을 것들이 더 많기 때문에 꽤 많은 이더리움 dApp들이 ICE로 마이그레이션되는 것을 보게 될 것이라고 예상합니다.

 

 

 

 

 

 

요약

ICON 2.0은 단순한 블록체인 업그레이드가 아닙니다. ICON 생태계의 경우 ICON 2.0은 원래 ICON 백서에서부터 강조된 비전 즉, "hyperconnect the world(세계를 초연결)"하기 위한 비전입니다. ICON 2.0에는 많은 여러 가지 기술 향상이 이루어지므로, 다음과 같이 진행해야 합니다.

 

 

- BTP는 신뢰할 수 없는(a fully-trustless) 이기종 블록체인도 연결이 가능한 상호 운용성 솔루션입니다. 웜홀과 달리 BTP는 신뢰할 수 있는 유효성 검사기에만 의존하여 메시지를 확인하지 않습니다. 내부 생태계(코스모스 SDK 블록체인 및 폴카닷 파라체인)에 중점을 둔 폴카닷 및 코스모스와 달리 BTP는 블록체인에 구애받지 않으며 스마트 컨트랙트를 지원하는 모든 스마트 퍼블릭 및 프라이빗 블록체인에서 작동합니다.

 

- Java SCORE는 성능과 안전성에 중점을 둔 새로운 스마트 컨트랙트 실행 환경입니다. 이를 통해 개발자들은 더 안전한 코드를 작성하고 컨트랙트를 더 빠르게 배포할 수 있습니다. 인프라 측면에서 Java SCORE는 파이썬보다 빠르게 실행되어야 합니다.

 

- Goloop는 더 많은 처리량과 동시처리 성능을 가진 재설계된 핵심 블록체인 엔진입니다. 이를 통해 ICON은 채택(선정)에 영향이 있는 초당 더 많은 트랜잭션을 처리할 수 있습니다.

 

- ICE는 EVM(이더리움) 및 eWASM(이더리움2.0) 호환 "애플리케이션 체인"으로 BTP에 대한 1등급 지원을 제공합니다. 이를 통해 개발자는 이더리움 dApps를 배포하고 크로스 체인을 통해 기능을 확장할 수 있습니다.

 

 

 

 

출처: https://brianli.com/what-icon-2-0-means-for-the-icon-ecosystem/