brunch

매거진 개발썰

You can make anything
by writing

C.S.Lewis

by 한상훈 Sep 28. 2024

이더리움 샤딩과 데이터 가용성

최근 이더리움 포럼에서 논의되고 있는 논제에 관하여

이더리움 개발자 포럼: https://ethresear.ch/


최근 이더리움 개발자들의 논제는 굉장히 다양하지만 내가 관심 있게 보고 있는 주제는 다음의 3가지 주제이다.


Sharding(샤딩)

MEV(Maximal Extractable Value < Miner Extractable Value)

Restaking(리스테이킹)


그중에서 이번 글에서는 샤딩에 대해서 깊게 다뤄보고자 하며, 샤딩을 이야기하면 나오는 데이터가용성과 리스테이킹 문제도 두루두루 설명해 보았다.




샤딩의 경우 비탈릭 부테린이 과거부터 제안했고 설명하기도 했었지만 여전히 이를 이더리움에 적용하는 데에는 현실적인 고민이 있는 게 사실이다. 샤딩에 대해서는 여러 공개된 자료가 많지만 이해를 돕기 위해 간단히 설명해 보겠다.


샤딩은 데이터베이스에서 자주 사용되는 개념인데 분산하여 저장하고자 하는 욕망에서 출발한다. 왜 분산하여 저장하고자 할까. 예를 들어 우리가 페이스북을 운영하는 메타 개발자라고 해보자. 전체 유저 데이터 베이스를 하나의 테이블과 데이터베이스에 몰아서 넣게 된다면 족히 20억 명의 유저가 담긴 DB를 조회해야 할 것이다. 이렇게 하나의 데이터베이스에 많은 데이터가 존재하면 CRUD 퍼포먼스가 곤란해질 수 있다. 


이를 해결하기 위해 국가 또는 지역별로 데이터베이스를 나눈다면 어떨까. 한국인인 나는 페이스북의 대부분의 친구가 한국인이고, 당연히 한국인만 모아둔 데이터베이스에서 자료를 참조한다면 데이터의 row 숫자도 적을 것이고, 당연히 조회 과정에서 속도의 향상이 발생할 것이다. 물론 외국인 친구가 있다면 이 경우는 예외가 되겠지만 샤딩의 근본적 목표는 위와 같다.


블록체인은 근본적으로 과거 기록이 Update, Delete가 불가능한 데이터베이스에 해당한다. 우리는 데이터가 담기는 최소 묶음인 블록을 잘 처리해야 하는데, 이 블록이 커지면 퍼포먼스는 오르지만 올라간 퍼포먼스에 따라 생기는 문제점도 존재한다. 이를 블록체인 트릴레마라고 부르게 된다.


돌아가서 이더리움에서 샤딩이 필요한 이유는 앞서 페이스북의 케이스처럼 더 빠르게, 많은 처리를 하기 위한 전략 중 하나로 제안된 것이다. 이더리움은 아쉽게도 TPS(Transaction Per Second, 초당 트렌젝션 수)가 경쟁하는 많은 블록체인보다 낮은 편에 속하는데 점점 커지는 규모를 고려한다면 이 정도의 TPS는 반드시 해결되어야 할 과제이다. 또한 후술 할 리스테이킹 관련해서도 연결되는 문제지만, 이더리움은 구조적으로 너무 많은 자본이 고정된 상태로, 초기 투자자들이 너무 많은 수익을 거두는 구조를 방지하기 위해 무한 발행 구조를 택했다. 커뮤니티에 따라 발행 속도의 조정은 가능하지만 근본적으로 무한 발행을 하고 있고, 이와 같은 배경 중 하나는 이더리움의 화폐인 이더(ETH)를 페이먼트 레벨까지 가져오는 것이 궁극적인 목표이기 때문이다.


앞서 참조한 비탈릭의 2017년 글에서 볼 수 있듯 샤딩은 트릴레마를 모두 해결할 수 있는 아이디어가 될 수도 있으면서 동시에 많은 구현 아이디어가 존재한다. 그는 예시로 비트코인에 제안된 Merklix 트리 아이디어나 BFT 샤딩 제안 등을 예로 들었다. 그가 이 글을 작성한 2017년부터 지금까지도 샤딩에 대한 논의는 끝이 나고 있지 않은데 이유는 대부분의 구현 방식이 불완전하고 위험성이 내포되어 있기 때문이다. 


무작위 샘플링과 벨리데이터 노드


이더리움 블록의 샤딩의 큰 골자는 검증을 담당하는 벨리데이터 노드(Validator Node)가 전체가 아닌 할당된 일부만 검증하여 성능을 끌어올린다는 것에서 시작한다. 기본적으로 블록체인의 메커니즘은 블록이 하나 생성될 때 모든 원장에서 일어난 모든 거래의 전후 상태를 비교하여, 모든 전후 상태의 변동이 문제없음이 결정되고 나면 블록이 생성되는 방식이다. 그러나 샤딩이 적용된다면 벨리데이터 노드가 전체가 아닌 일부만 완전히 검증하고, 또한 일부를 검증할 때도 무작위 샘플링을 통해 검증하는 과정에서 악의적 거래 기록이 들어오는 것을 방지하는 전략을 골자로 한다. 


출처: https://vitalik.eth.limo/general/2021/04/07/sharding.html


이해를 돕기 위해 무작위 샘플링이 없는 경우를 생각해 보자. 벨리데이터 노드가 적은 숫자라면 악의적 공격자는 특정 벨리데이터 노드에 포함된 노드만 공격하여 거래를 위변조 할 수 있게 되고, 이는 블록체인에서 51% 공격을 통해 위변조 하는 기준을 크게 낮추게 되어 위험성을 극도로 높일 수 있게 된다. 다르게 표현하자면 전체를 다 잡아먹기에는 전체 시스템의 51%를 잠식하기에 비용이 극단적으로 올라가지만 작게 나눠진 부분 부분(각각의 샤드)을 공격한다면 공격 비용이 지수적으로 감수함을 뜻한다. 하지만 이것은 앞서 설명한 무작위 샘플링을 사용하여 지속적으로 섞어버림을 통해 특정성을 불가하게 만드는 전략을 사용할 수 있는 것이다. 


데이터 가용성(Data Availability, DA) 문제

샤딩에 대한 논의를 깊게 들어가다 보면 결국 데이터 가용성 문제와 직결된다. 앞서 예시로 들은 "페이스북의 유저 데이터베이스를 국가별로 샤드한 다면 외국인 친구는 어떻게 조회하는가?"의 연장선이라 생각하면 된다. 이를 블록체인으로 치환하여 생각하면 다음과 같다.


"앨리스는 밥에게 1 ETH를 송금했는데, 이쪽 샤드에는 기록이 되어 있고, 다른 쪽에는 없어. 어떤 게 맞는 거야?"


우리가 다루고 있는 데이터는 실시간으로 셀 수 없이 많은 거래와 온체인 데이터의 덮어쓰기가 이뤄지고 있는 시스템이라는 점을 고려해 본다면 데이터의 저장 단위가 분산되었을 때, 해당 데이터의 실시간 접근 과정에서 그 데이터의 유효성을 검증하는 것은 중요한 문제이다. 과거와 같이 전체가 모두 검증되고 업데이트되는 방식이라면 문제가 없겠지만 샤드 된 형태라면 또 다르다. 


이 문제를 낚시꾼 딜레마라고 부르는데 이를 해결하기 위한 전략으로 비탈릭은 DAS를 제안하였다. 이 DAS 제안에 대해서 깊게 이야기하자면 이야기가 한도 끝도 없이 길어지니 이쯤에서 샤드와 데이터 가용성, 그리고 이와 연결되는 또 다른 주제이자 제품인 아이겐레이어(EigenLayer)로 넘어가 보고자 한다.



EigenLayer와 리스테이킹 문제

아직까지 이야기한 내용은 현재까지도 논의되고 있는 이더리움 플랫폼의 샤딩과 거기에서 파생된 데이터 가용성 문제가 있다는 것을 설명하였다. 그러나 데이터 가용성으로 넘어가게 되면 오히려 이더리움 블록 내에서 생길 수 있는 문제가 아닌 그 위의 레이어에서 발생하는 데이터 가용성 문제도 무시할 수 없다. 이를 해결하기 위해 나타난 것이 아이겐레이어라 할 수 있다.


이더리움은 당연하게도 강력한 보안을 현재까지도 제공하고 있고, 데이터 가용에도 문제가 없다. 다만 앞서 샤드 등의 개선이 적용됐을 때 야기될 문제들에 대해 개발자들이 논의하고 있는 상태인데, 이더리움의 데이터 가용성은 문제가 없다는 전제 하에서 이더리움 위에 올린 모든 DApp들은 별도의 검증 없이 데이터를 처리하고, 리스테이킹 되고 있다. 여기서 문제가 바로 리스테이킹이다.


리스테이킹이란 이더리움의 스테이킹을 대신해주는 서비스를 의미한다. 왜 대신해 주는 서비스가 필요할까? 이더리움을 스테이킹해서 보상을 얻기 위해서는 여러 준비가 필요하다. 적절한 하드웨어 준비도 필요하지만 예치 기준이 되는 32개의 ETH가 일반 사용자에게는 큰 부담이다. 32 ETH는 현재 기준으로 약 1.1억 원에 해당하는 큰돈이다. 일반 투자자들에게는 이 금액을 예치하는 것은 쉽지 않다. 이러한 문제점을 해결하기 위해 여러 리스테이킹 서비스는 자신들에게 32 ETH보다 적은 ETH를 예치하더라도 보상을 받을 수 있고, 또한 언제든 예치한 자산도 뺄 수 있도록 하는 리스테이킹 서비스를 출시했다.


여기서 발생할 수 있는 주요한 문제는 해당 서비스들의 보안은 완전하지 않을 수 있다는 점이다. 해당 서비스가 만약 해커에게 공격을 받아 그곳에 예치된 엄청난 ETH와 벨리데이터 노드 파워를 바탕으로 공격이 이뤄진다면 이더리움 생태계 전체에 큰 위협이 될 수 있다. 이를 해소하기 위해 각각의 리스테이킹 DApp의 보안을 EigenLayer를 통해 확장한다. 이 과정에서 보안과 검증 서비스를 EigenLayer의 외부 모듈에 제공하게 되는데, 이때 보안을 제공하는 모듈에게는 추가적인 보상을 EigenLayer에서 제공해 주는 것이다.



다양한 리스테이킹

주제와는 벗어나지만 리스테이킹에 대해 조금 더 설명해 보자면, 리스테이킹은 개념적으로 스테이킹된 것을 다시 스테이킹한다는 것은 같지만 구현 방법 측면에서 몇 가지 옵션이 존재한다. 대표적으로 Lido와 같은 서비스는 유동화된 스테이킹으로 다른 말로 LSD(Liquid Staking Dereivatives)라고도 부르며, 이더리움의 기준 스테이킹 양보다 적은 양을 스테이킹이 가능하며, 언제는 스테이킹을 취소할 수 있는 유동화 토큰을 제공한다. 그렇게 발행된 유동화된 스테이킹 토큰이 stETH다. 그 외에도 유동화된 스테이킹과 조금 다른 유동화된 '리'스테이킹 서비스도 존재한다. 대표적으로 Renzo와 같은 서비스이다. 



그러나 결과적으로 스테이킹을 직접 하지 않는 서비스들은 앞서 서술한 보안상의 문제점을 야기할 수 있고, 이것이 시스템 전체에 퍼졌을 때 생길 수 있는 문제에 대해 나름의 해결책을 제시하고 있다. 이들의 관계가 직접적이면서 동시에 직접적이지 않다는 점이 흥미로운데, EigenLayer는 사실상 최초의 적극적 검증자(AVS)로 이더리움 생태계에 등장했고, 자신들을 통해 이더리움을 더 안전하고, 블록 데이터를 사용할 수 있도록 만드는데 주력하고 있다. 반대로 이더리움에서는 EigenLayer와는 별개로 자신들의 구조적 개선을 통해서 이를 해결하려는 노력과 동시에 트릴레마까지 잡겠다는 방향으로 논의가 진행되고 있는 점이다.




브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari