이 글은 Thinking Decentralized시리즈의 일부입니다. 이번 글에서는 왜 단일형식 어플리케이션 구조 – 메인넷 전체 내의 거래에 기반한 것이든, 메인넷과 연결된 하나의 사이드체인을 사용하는 것이든- 를 피하고 싶은지에 대해 살펴보고자 합니다. 대신, 우리는 인터체인 메시징 또는 이와 유사한 방법을 통해 퍼블릭 메인넷에 연결되는 다수의 탄력적인 사이드체인을 사용하는 것이 왜 훨씬 좋은 방식이며 더욱 유연한 방식인지에 대해 살펴보겠습니다.

사이드체인의 정의

사이드체인은 이더리움 메인넷 같은 주요 퍼블릭 블록체인에 연결된 블록체인 네트워크입니다. 사이드체인은 거래 블록들의 체인을 통한 거래의 보존을 한다는 점에서는 퍼블릭 체인과 동일한 철학을 가지고 있지만, 퍼블릭 체인과 상이한 합의 알고리즘이나 검증 방식을 사용할 수 있습니다. 또한, 사이드체인은 메인넷에서 찾을 수 없는 추가 기능을 포함하기도 합니다. 이러한 기능에는 추가 스토리지 옵션, 허가형 접근, 영지식증명, 대안적인 수수료 메커니즘 등을 예로 들 수 있습니다.

다수의 탄력적 사이드체인을 사용하여 블록체인 솔루션을 구성하고 생성하라는 조언은 최신 어플리케이션 개발 상황에서의 아키텍처 패턴을 본다면 전혀 놀랍지 않습니다. 이번 포스트에서 몇 가지 주목할 만한 패턴을 공유하겠습니다.

데이터베이스로부터 얻을 수 있는 교훈

데이터베이스 작업을 하면서 얻는 교훈은 어플리케이션 내 모든 데이터에 대해 하나의 데이터베이스를 사용하는 것이 현명하지 않다는 것입니다. 테스트용 어플리케이션이나 서비스에는 괜찮을 수도 있지만, 시스템에 상당한 양의 거래나 데이터 로드가 있는 경우, 데이터의 저장과 접근 방식을 맞춤형으로 구성하는 것이 성공적인 시스템 구축 및 확장에 있어 필수적일 것입니다.

거의 대부분의 어플리케이션은 유저 정보, 거래 정보, 로그인 정보, 미디어 파일, 사용자의 인풋, 관계 데이터, 분석 데이터 등 다양한 종류와 형태의 데이터를 가지고 있을 것입니다. 이런 모든 형태의 데이터를 위해 하나의 데이터베이스만을 사용하는 것은 실용적이지 않을 뿐만 아니라 현재의 기술 수준을 고려했을 때 거의 불가능할 가능성이 큽니다. 모든 앱 쿼리를 하나의 데이터베이스에서 실행하는 것은 얼마나 상세하게 샤딩이나 인덱싱이 되어있든 간에, 데이터베이스를 무너뜨리고 향후 개발을 완전히 힘들게 만들 수 있습니다.

그 대신, 대부분의 아키텍트들은 데이터 형식뿐만 아니라 데이터 위에서 이루어지는 거래에 따라 데이터 스토리지의 구조를 구성하고 최적화합니다. 사용자 정보는 빠른 읽기 액세스를 위해 수평적으로 샤딩된 NoSQL 데이터베이스에 보관하고, 거래 정보는 빠른 쿼리를 위해 아주 많이 인덱싱이 된 관계형 데이터에 저장하고, 미디어 파일은 블록 스토리지에, 분석 데이터는 시리즈 데이터에, 관계 데이터는Graph DB 등에 저장하는 방식입니다. 각 데이터베이스는 읽기-쓰기 로드, 데이터 사이즈와 형식, 데이터 스키마, 커밋 시간, 지연속도에 대한 요구사항, 쿼리 종류, 보안 조건, 그리고 다수의 파라미터에 따라 최적화되어 있을 것입니다. 저장된 데이터의 양 증가뿐만 아니라 수행하는 쿼리 수나 종류에 대해서도 신경쓰고 있을 것이구요.

데이터 사이언스와 CAP Theorem

CAP theorem은 데이터 사이언스 분야에서 분산 시스템에서는 일관성, 가용성, 분할 용인이라는 세 가지 조건을 동시에 두 가지 이상 만족할 수 없다는 이론입니다. 따라서, 어플리케이션 및 데이터베이스 엔지니어들은 특정한 앱 기능 또는 서비스에 있어 가장 중요한 점을 보장하기 위한 최적화를 위해 특정 데이터 스토리지 종류를 선택할 때 절충해야 합니다.

대부분의 애플리케이션 개발자 및 아키텍트들에게 데이터 종류와 사용에 따라 상이한 데이터베이스를 사용하는 것은 당연합니다.

스토리지의 종류와 특징

마이크로서비스부터 얻을 수 있는 교훈

이벤트 및 거래 처리와 관련하여 동일한 깨달음이 현실이 되고 있습니다. 하나의 어플리케이션이 하나의 CPU에 컴파일 또는 연결되어 모든 사용자의 작업과 사이드 이벤트를 다루도록 하기보다는, 앱 개발자들은 보통 여러 개의 어플리케이션이 하나의 서비스 세트가 되도록 개발합니다. 이러한 서비스는 각기 기능적으로 분리되어 있으며 API, 원격 프로시저 호출(RPC), 대기열, 데이터베이스, 서버리스 함수 호출, 또는 기타 다른 방법을 통해서 어플리케이션 워크플로우를 조정합니다.

마이크로서비스를 사용하는 것이 일을 더 복잡하게 만드는 것처럼 보일 수도 있지만, 사실은 정반대입니다. 마이크로 서비스를 사용해서 어플리케이션을 개발하면 팀이 더 빠르게 움직일 수 있을 뿐만 아니라 어플리케이션의 확장과 새로운 기능 추가를 더 쉽게 할 수 있습니다.

단일 형식 어플리케이션을 사용하면 코드베이스가 지속적으로 다른 코드로 변경되고 업데이트되기 때문에, 계속해서 테스트 시 충돌을 겪게 됩니다. 테스트 양의 증가와 의도치 않은 결과에 대한 리스크의 증가로 인해, 어떠한 종류의 스케줄을 따르던지 간에 업데이트를 적시에 하는 것이 어려워 집니다. 마이크로서비스를 사용하면 변경 내용을 보다 쉽게 ​​분리할 수 ​​있으므로 개발 속도가 빨라지고 위험이 줄어들며 업데이트 주기가 더 빨라집니다.


블록체인 네트워크를 이용한 탈중앙화 어플리케이션을 개발할 때 역시 관심사 분리(separation of concerns)와 관련하여 동일한 원칙이 많이 적용됩니다. 단일 블록체인 네트워크 또는 사이드체인 (예: 이더리움 메인넷)을 사용하는 것 보다는, 하나의 퍼블릭 메인넷에 연결된 여러 개의 사이드체인을 사용하는 것이 좋습니다.

많은 사람들이 레이어-1 확장을 통해 레이어-2 솔루션의 필요성을 없앨 것이라고 하지만, 이는 확장가능한 디앱을 구축하는 이들의 견해는 아닙니다. 2019년 10월 Scalar Capital Summit에서 Dharma의 CEO이자 공동 창립자인 Nadav Hollander는 확장가능한 Layer 1의 시작에도 불구하고 레이어-2 솔루션의 지속적인 필요성에 대해 이야기했습니다.

“차세대 블록체인의 주요 셀링포인트는 확장성, 특히 레이어-1 확장성입니다. 하지만 이들 모두 확장성을 위해 샤딩만을 얘기하고 있죠. 샤딩의 문제점은 이 기술이 디파이 확장성을 해결하는 만병통치약이 되지 않을 것이란 점입니다. 여기서 기술적인 내용을 깊게 다루진 않겠지만 이더리움 2.0만 하더라도 트래픽이 많은 디파이 프로토콜들은 확장성을 위해서 수준 높은 레이어-2 시스템이 필요해질 겁니다. 이 모든 것으로 봤을 때, L1의 확장성은 상당한 이점이 존재하지만 디파이의 문제를 모두 해결하지 못합니다.”

- Nadav Hollander, Dharma의 CEO및 공동 창립자

레이어-2 솔루션(예: 탄력적인 사이드체인)을 사용하는 것은 모든 종류의 확장가능한 탈중앙화 솔루션을 구축하는데 있어 필수적입니다. 디앱 역시 앱이기 때문에 다양한 종류의 사용자 이벤트, 처리 요건, 중앙화된 앱으로써의 데이터 액세스 방식 등을 다뤄야 할 것입니다. 탈중앙화를 다루는 개발자들 역시 스토리지, 기능 개발, 데이터 종류, 거래, 커밋 지연시간 등에 대해 고민해야만 할 것입니다.

블록체인을 이용함으로써 생기는 복잡성(커밋 시간, 거래 수수료, 스토리지 및 처리 제약, 스마트 컨트랙트의 영속성 등)은 문제를 더욱 어렵게 만들 것입니다. 단일 형식 마인드셋과 대비되는 다수의 사이드체인을 사용하는 방식의 지혜가 필요할 것입니다.

다수의 사이드체인을 사용하는 여러가지 이유

개발 민첩성 향상

탄력적 사이드체인을 사용하면 분산화된 앱과 프로토콜을 보다 쉽게 개발할 수 있기 때문에 적용이 빨라집니다. 사이드체인을 사용하면 처리 및 데이터 문제를 분리할 수 있고 개발팀의 상호작용에도 도움이 됩니다. 중앙화된 앱의 단일 형식 앱 작업은 팀원들이 동일한 코드베이스 또는 데이터베이스를 가지고 교류함으로써 마찰이 생깁니다. 이처럼 모든 거래를 단일 메인넷 또는 사이드체인에서 구동하는 것은 하나의 작업이 실질적으로 다른 작업들의 처리를 막는 상황을 만들 수 있습니다.

개발이 고도로 동기화되어 일어날 때의 커뮤니케이션 방식 혹은 팀 관리는 개발에 필요한 시간을 빼앗아갈 뿐만 아니라, 가장 느린 팀의 속도에 맞춰 개발속도가 덩달아 지연되게 합니다. 상태 관리와 작업 동기화를 위한 효과적인 인터체인 메시징 솔루션을 사용하면서 다수의 사이드체인을 이용한다면 개발과정에서의 마찰이 줄어들고 런칭은 훨씬 빨라질 것입니다.

신규 디앱 vs. 기존 디앱

탄력적 사이드체인을 사용하면 기존의 디앱과 신규 디앱 모두에 도움이 된다는 점 역시 주목할 만 합니다.

신규 디앱의 경우, 출시와 동시에 사이드체인을 사용하는 것이 합당한 생각입니다. 개발자들이 개발에 중대한 (잠재적인) 차질 없이 시작부터 확장가능한 시스템을 구축할 수 있기 때문입니다. 사이드체인의 사용은 가스비와 커밋 시간을 줄여줌으로써 더 성공적인 게임 플레이나 디앱 경제를 가능하게 합니다.

기존 디앱의 경우, 신규 기능의 추가나 메인넷에서 탄력적 사이드체인으로 기존의 기능을 이전하는 것을 쉽게 할 수 있을 뿐만 아니라 리스크를 줄여줍니다(사이드체인과 스마트 컨트랙트를 제대로 설정하는 것이 물론 중요하죠). 사이드체인으로 이전해야 하는 이유는 거래처리량 증가, 가스비 절감, 더 복잡한 스마트 계약 지원 또는 더 큰 사이드체인 스토리지의 활용 등이 있습니다. 특정 거래 셋이나 데이터 종류에 대한 사이드체인을 만들면, 개발자가 해당 체인을 기능에 맞게 크기를 조정하고 최적화할 수 있습니다.

탄력적인 사이드체인은 개발 민첩성을 향상시킵니다

성능 향상

거래 커밋 시간과 응답 지연시간은 모든 어플리케이션에서 중요한 요소이지만, 특히 탈중앙화 어플리케이션에서는 더욱 중요합니다. 중앙화된 앱에서의 커밋 시간은 대략 밀리세컨드 또는 마이크로세컨드 단위입니다.  탈중앙화된 앱에서의 커밋 시간은 대략 분 단위(혹은 네트워크 로드와 가스비에 따라 시간 단위)입니다. 레이어-1 확장 솔루션이 도움은 되지만, 아주 단순한 디앱을 제외하고는 모든 종류의 거래나 커밋 시간에 도움이 되지는 않을 것입니다.

탄력적 사이드체인을 사용하면 거래 종류에 맞게 최적화가 가능합니다. 자산의 담보화 측면에서는 특정 이벤트나 거래 종류가 중요할 수 있고, 시장 조성이나 게임 플레이와 관련해서는 다른 종류가 중요하고, 나머지는 중요하지 않을 수도 있습니다. 후자의 예시는 탈중앙화된 미디어 스트리밍 앱에서의 소셜 액션(좋아요, 팔로우, 공유, 또는 낙관적으로 성공적인 커밋을 가정했을 때 백그라운드 이벤트로 처리될 수 있는 다른 액션들)이 될 수 있습니다.

따라서 각 이벤트의 종류는 각기 상이한 거래 커밋 시간을 가집니다. 자산 전송의 우선순위는 높을 수 있기 때문에 커밋 시간의 단축을 위한 최적화가 필요합니다. 앱 내에서 이루어지는 작업 역시도 성능에 대한 요구사항이 매우 높을 수도 있지만, 데이터나 거래 종류에 맞게 하나 혹은 여러 개의 사이드체인에서 실행될 수도 있습니다.

다만, 모든 사이드체인이 비슷한 것은 아닙니다. 여러분 자신의 성능 니즈만 지원하는 것이 아니라, 거래의 적합성과 디앱의 무결성을 확보하기 위한 적절한 합의 메커니즘과 보안 조치를 검증할 수 있는 검증 모델이 있는 사이드체인을 이용해야 합니다.

네트워크의 경제성 향상

중앙화된 어플리케이션과 탈중앙화된 어플리케이션 간의 주목할 만한 차이점은 거래비용과 관련이 있습니다. 중앙화된 앱에서는 거래비용이 극도로 낮습니다. 물론 처리와 스토리지 관련 비용도 있지만, 그 비용은 극도로 미미한 정도입니다. 이러한 저비용은 퍼블릭 블록체인 네트워크를 사용하여 거래를 완료시키는 데 필요한 가스비의 규모와 직접적으로 비교됩니다. 예를 들어 이더리움에서의 가스비는 거래 하나 당 몇 센트에서 5~10배까지 이를 수 있습니다.

이러한 비용이 있기 때문에 시스템의 모든 거래를 메인넷에 담는 것은 비현실적입니다. 따라서 사이드체인은 최종 상태의 거래를 상태간 거래에서 분리할 수 있는 최고의 메커니즘을 제공함으로써 운영 비용을 줄이고 어플리케이션 또는 프로토콜과 관련된 경제성을 향상시킵니다. 다시 말하자면, 탄력적인 사이드체인으로 옮겨감으로써, 앱 사용자들의 가스비가 현저히 절감되거나 제거됩니다. 자산의 생성 또는 전송과 같은 중요한 상태 변화는 여전히 메인넷에 커밋이 되겠지만, 대부분의 기타 거래는 사이드체인에서 실행될 수 있습니다.

스토리지 향상

중앙화된 앱의 경우와 마찬가지로, 탈중앙화된 앱에도 다양한 데이터 종류와 형식, 인덱싱, 읽기-쓰기 로드가 존재할 것입니다. 이러한 차이는 어떤 것이 메인넷에 쓰여지고, 어떤 것이 사이드체인 스토리지에 저장되고, 어떤 것이 탈중앙화된(또는 중앙화된) 스토리지에 저장될 것인지를 결정하게 됩니다. 메인넷은 암호자산, 토큰, 또는 기타 디지털 자산의 소유를 기록하고 모든 이전, 처분 또는 기타 상태 변화를 기록하는데 쓰일 것입니다. 이러한 자산의 다른 이용 또는 상태 변화는 적절한 인터체인 메시징이나 자산 락업 메커니즘을 이용해 사이드체인에 반영될 것입니다.

일례로 디앱 카드 게임을 들 수 있습니다. 베팅은 메인넷에서 이루어지지만 (각 플레이어가 판돈을 거는 경우) 카드딜링이나 이동은 사이드체인에 기록되고, 이 때 각 사용자는 각각의 카드 플레이에 대해 서명하고 다른 플레이어에게 이를 전송할 것입니다. 메인넷은 막판일 때와 베팅 금액 정산시에만 관여됩니다.

다른 예로 탈중앙화된 미디어 스트리밍 어플리케이션을 들 수 있습니다. 탈중앙화된 음악 서비스나 탈중앙화된 유튜브 플랫폼 말이죠. 이러한 시스템 종류에 대한 데이터는 미디어 파일, 파일에 대한 메타 데이터(제목, 아티스트, 설명, 길이), 재생 지표, 소셜 지표(좋아요, 공유, 팔로우), 사용자 정보(리뷰, 플레이리스트), 지불 정보 등이 포함될 것입니다. 이런 종류의 데이터는 여러 가지 이유(가스비, 스토리지의 제약, 쓰기 지연속도 등등)로 인해 데이터 전체가 메인넷에 저장될 수는 없습니다

그러나 다수의 사이드체인의 사용은 데이터 처리를 단순화하고 운영 비용을 현저히 절감시킬 수 있습니다. 그 이유는 앱 개발자가 스토리지 요금, 커밋 시간, 액세스 및 조회 메커니즘 등을 고려하여 적절한 스토리지 위치로 데이터 읽기 및 쓰기를 최적화할 수 있기 때문입니다.

메인넷에서 사이드체인, 탈중앙화 (및 중앙화) 스토리지에 이르기까지 다양한 스토리지 옵션이 존재합니다.

처리 복잡성의 향상

탄력적인 사이드체인 사용에 있어 자주 간과되지만 한 가지 중요한 측면은 처리 복잡성입니다. 메인넷 내에서의 처리는 상당히 제한적일 수 있습니다. 자산에 대한 변경(생성, 이전, 소멸)보다 복잡한 처리는 가스비를 높이고 커밋 시간을 증가시킬 수 있습니다. 메인넷에서의 스마트 컨트랙트의 공개적인 특성을 고려하면, 복잡성으로 인해 리스크가 증가할 수도 있습니다. 사이드체인의 사용이 언제나 열악한 컨트랙트 로직의 리스크를 제거하는 것은 아니지만, 실수의 심각성으로 인한 영향을 줄일 수 있습니다.

보다 복잡한 스마트 컨트랙트를 작성하는 것의 주된 이점은 이를 통해 개발자가 (이 부상하고 있는 공간 내에서 계속해서 증가하고 있는) 풍부한 역량을 활용할 수 있게 해 준다는 점입니다. 풀 스테이트 컨트랙트 처리는 체인에 대한 완전한 액세스가 있다는 것을 의미합니다. 즉, 상태 변경은 체인의 완전한 상태에 대한 지식이 있기 때문에 더 정교하고 적시에 이루어 질 수 있다는 뜻이죠. 가스비로부터 자유로워지면 타 프로토콜을 호출하여 오라클의 사용 또는 기제공된 사이드체인 기능의 사용(예: 난수 생성기) 등이 가능해짐을 의미합니다. 이러한 작업을 사이드체인 내에서 수행하는 것은 필수적으로 안전망을 제공합니다. 개발자들이 가스비를 더 엄격하게 처리하면서도 더 빠르게 움직이고 더 빨리 혁신할 수 있는 자유를 얻게 되는 것입니다.

SKALE Network 사용하기

SKALE Labs는 탄력적인 블록체인 네트워크 프로토콜인 SKALE Network의 제작자입니다. 우리의 미션은 풀 스테이트 스마트 컨트랙트를 구동시키는 비용 효과적인, 고성능 사이드체인을 쉽고 빠르게 만들 수 있도록 하는 것입니다. 우리는 보안이나 탈중앙화를 포기하지 않으면서도 속도와 기능을 제공하는 개발자들에게 고능률 경험을 제공하는 것을 목표로 합니다. 텔레그램, 트위터, 디스코드에서 저희를 팔로우 하시고, SKALE 웹사이트를 방문하시고, 저희의 개발자 문서를 확인해 보십시오.

SKALE Network 개발의 기본 철학은 여러 개의 탄력적인 사이드체인 사용이라는 관점과 직접적으로 연관되어 있습니다. 사이드체인의 신속한 배포와 확장, 종속 체인 검증을 위한 풀로 운영되는 검증 모델의 사용(작은 사이드체인이라도), 확장 가능한 노드 설정, 풀 스테이트 스마트 컨트랙트 처리 등은 SKALE Network를 탄력적 사이드체인으로 이용함으로써 얻는 수 많은 장점 중 일부일 뿐입니다.

저희는 여러분이 SKALE의 장점을 살펴보시고, 개발자 옹호자들과 연락하시기를 바랍니다. 여러분들의 질문을 받거나 온라인 hacksession을 통해 이러한 아이디어를 나눌 준비가 되어있습니다. 탄력적 사이드체인은 실재할 뿐만 아니라 여러분이 더 빠른 런칭을 하고, 확장성에 대한 고민을 해결하고, 운영비용을 절감하고, 위대한 탈중앙화 앱을 만들기 위한 좋은 선택이 될 것입니다.

고지사항 – 본 문서는 정보공유를 위한 목적으로만 사용되며 N.O.D.E. Foundation, SKALE Labs, Inc., 또는 기타 회사의 지분 또는 증권에 대한 제안 또는 권유가 아닙니다. 그러한 제안 또는 권유는 해당 증권 또는 기타 법률에 따라 기밀 제안 문서를 통해서만 이루어집니다.