지난 블로그에서는 “댕크샤딩(Danksharding)은 무엇일까?”에 대한 첫 번째 시리즈로 이더리움 확장성 솔루션에 관해 다뤄봤습니다. 이더리움 확장성 로드맵을 통해 확장성 문제를 해결하는 데의 중요성을 이야기해 보았는데요, 이번 블로그 포스팅에서는 블록체인 확장성 문제를 해결하기 위한 기술적인 접근 방식 중 하나인 샤딩(Sharding)과 이의 발전된 형태인 댕크샤딩(Danksharding)에 대해 더욱 깊숙히 파고들어 보겠습니다.
샤딩
샤딩(Sharding)이라는 것 자체는 데이터베이스나 분산 시스템에서 에서 사용되는 용어입니다. 데이터를 한 곳에 모두 모아놓으면, 그 데이터가 늘어날 수록 점점 커지게 됩니다. 그러면, 데이터를 처리하기에 굉장히 무겁고, 그 데이터 자체를 관리하기도 부담이 됩니다. 그래서 데이터를 여러 조각으로 나눠서 저장하거나, 나눠서 처리하자는 기술을 샤딩이라고 부릅니다.
- Sharding : 데이터를 여러 조각으로 나누어 저장하거나 처리하는 기술
이더리움의 샤딩
이더리움에서의 샤딩은, 블록체인을 여러 개의 샤드 체인으로 나눠보자는 것입니다.
아래 그림을 보면, 합의 레이어가(Coordination Layer)되는 비콘 체인(Beacon Chain)을 메인으로 두고, 그 비콘체인에 의존하는 여러 개의 샤드 체인들(Shard Chains)로 나눠 놓았습니다. 이 때, 제안되었던 것은 그림처럼 64개의 샤드 체인으로 나누고, 각각의 체인에서 트랜잭션을 나눠서 처리하는 것입니다. 예를 들어, 6만4천개의 트랜잭션을 처리해야 하는 경우, 한 체인에서 6만 4천 개를 모두 다 처리하는 것보다, 64개의 체인이 그걸 1000개씩 나눠서 처리하면 더 데이터를 빨리 처리하거나, 더 효율적으로 처리할 수 있게 됩니다. 트랜잭션의 처리나 데이터의 저장을, 한 체인에서 하지말고 각 샤드체인로 분산해서 처리하는 것이 이더리움 샤딩의 목표였습니다.
샤딩 이전에는, 트랜잭션이 발생하면 모든 밸리데이터가 모든 들어오는 블록들을 모두 검증해야 했습니다. 샤딩 이후에는, 샤드 체인 별로 밸리데이터가 나눠져 있고, 그 각각의 벨리데이터는 자기가 속한 샤드 체인만 검증하면 되기 때문에, 자신이 처리해야 되는 데이터의 양 들이 줄어 들 수가 있게 됩니다. 이렇게 된다면, 낮은 하드웨어 사양으로도 밸리데이션을 수행하는 노드 운영을 할 수 있게 되는 것이 가능해집니다.
하지만, 위 처럼 64개의 샤드체인으로 나누는 방식의 이 아이디어는 폐기 되었습니다. 그 뒤이어 나온 새로운 아이디어가 댕크샤딩(DankSharding) 입니다.
위 방식이 폐기되고 댕크샤딩으로 이동하게 된 이유중 하나는, 앞서 말했듯이 롤업 중심으로 이더리움의 확장성을 확보하자는 방향성입니다. 방금 설명했듯이, 샤드체인들은 각 샤드체인들이 직접 트랜잭션을 처리하기도 하고, 저장공간으로도 사용하게 됩니다. 그런데 롤업 중심으로 이동하게 되면, 데이터에 대한 처리는 모두 롤업 Layer 2에서 모두 수행하기 때문에, 샤드체인의 필요성이 떨어지고, 이러한 샤드 방식을 구현하는 중에 또 다른 여러 가지 이유들이 생기면서 폐기되었다고 합니다.
- L1 블록체인을 여러 개의 샤드 체인으로 쪼개는 것
트랜잭션 처리와 데이터 저장을 각 샤드로 분산.
- 샤딩 이전
- 모든 밸리데이터가 모든 블록을 검증했다면
- 샤딩 이후
- 밸리데이터는 본인이 속한 샤드체인만 검증하면 됨.
- 하드웨어 사양이 낮아도 됨.
그러나, 이방식은 폐기됨 ⇒ 그리고 롤업 중심으로 이동.
PBS (Proposer-Builder Separation)
댕크샤딩을 이해하려면 PBS라는 것을 알아야 합니다. PBS 는 Proposer-Builder Separation 의 약자입니다. 간단히 설명하자면 프로포저(Proposer)와 빌더(Builder)를 나누자는 것입니다.
POS 체인으로 넘어온 이후, 밸리데이터가 하는 일들에 대해 먼저 살펴보겠습니다. 밸리데이터는, 몇 이더를 송금하겠다, 디파이에 예치하겠다 하는 등의 여러 트랜잭션들을 모읍니다. 예를 들어, 트랜잭션 3개가 담긴 블럭을 다음 블럭으로 하자라고 제안을 하면, 이 제안된 블럭에 대해 다른 밸리데이터들이 이 블럭에 담긴 것들이 트랜잭션들은 맞는지 등을 검증하고 투표를 합니다. 이것이 통과되면 다음 블록을 생성합니다.
밸리데이터가 하는 일 – 높은 수수료 위주로 트랜잭션 선택
밸리데이터가 하는 일 – 높은 수수료 위주로 트랜잭션 선택
트랜잭션을 모아서 새로운 블록제안을 검증 및 투표, 그리고 블록생성
위에서 살펴 보았듯이, 밸리데이터의 역할은 블록을 제안하는 것과 그 블록을 검증하는 것으로 나눠져 있습니다.
밸리데이터 중에 커미티(Commitee)를 랜덤으로 뽑습니다. 예를 들어, 만 명 중에 150명을 커미티로 선정했을 때, 그 중 1명을 프로포저(Proposer)로서 제안자로 지목하고, 나머지는 어테스터(Attesters)로서 증명하는 자로 구분합니다. 프로포저는 트랜잭션들을 선택해서 새로운 블록을 만들어, 다음 블럭으로 제안을 합니다. 나머지 어테스터들이 제안된 블록이 제대로 된 블록인지 검증하고 투표를 해서, 다음 블록이 생성되도록 합니다. 프로포저가 하는 일이 훨씬 많아, 어테스터보다 받는 수수료도 차이가 납니다.
만약에 프로포저가 강력한 경우는 블록체인에서 분산된 결정을 내리는 과정에서 문제가 발생할 수 있습니다. 프로포저가 강력하다는 것은 블록 제안 과정에서 이 프로포저가 선정될 확률이 높다는 것을 의미합니다.
이러한 경우, 프로포져는 트랜잭션을 모아 새로운 블록을 제안할 때, 이 과정에서 트랜잭션 안을 주시하고 있다가 이더리움을 대량으로 매수하는 트랜잭션이 있다는 것을 알게 되면, 이득을 취할 수 있습니다. 이더리움의 대량 매수가 있다는 것은, 대량 매수 전 후에 이더리움 가격이 달라질 수 있을 것이기 때문에, 그 트랜잭션이 처리되기 전 트랜잭션에는 이더리움을 매수하는 트랜잭션을 프로포져가 껴놓고, 그리고 실제로 이더리움이 대량으로 매수돼어 가격이 올라가는 상황이 되면, 그 뒤 이어 이더리움을 다시 파는 트랜잭션을 넣어버리면 위험 없이 그 차액을 얻을 수 있는 기회들을 얻게 됩니다. 이러한 것들을 MEV라고 합니다. MEV 는 maximum extractable value 의 약자 입니다. 마이너가 이득을 취할 수 있는 행동들을 할 수 있게 됩니다. 프로포져가 중앙화되면서 이러한 부작용들이 발생할 수 있습니다.
밸리데이터가 하는 일 – 높은 수수료 위주로 트랜잭션 선택
이 문제점을 해결하기 위해서 나온 개념이 PBS 입니다. 본래 프로포져가 하고 있는 역할을, 프로포져(Proposer) 라는 역할과 빌더(Builder) 라는 역할로 이렇게 둘로 나누자는 개념입니다. 아직 도입되어 있는 것은 아니고, 이런 방식으로 도입되면 좋을 것 같다고 제안된 상황이고, 이에 대해 논의중인 상태입니다.
PBS 가 도입된다면, 트랜잭션들을 모아서 이 묶음을 블록으로 해야해 하고 트랜잭션을 모으는 주체가 빌더가 됩니다. 이 빌더들 역시, 아까 언급했던 MEV 형태로 이득을 위한 트랜잭션의 모음으로 블록을 만들 수는 있습니다. 여기서, 빌더들은 여러 명이 될 수가 있습니다. 이 빌더들이 각각 자신이 원하는 블록을 만들어, 프로포져에게 보냅니다. 그러면 여러 블록의 후보군들 중에 제일 마음에 드는 블록을 하나 선택하여, 어테스터한테 보냅니다. 프로포져가 여러 개의 블록을 제안받았을 때, 그 중 하나의 블록을 선택하는 기준은 다음과 같습니다. 빌더들이 프로포저에게 블록을 전달하면서 프로포저 수수료(Fee)를 함께 전달합니다. 그러면 프로포저 입장에서는, 내가 받을 수 있는 수수료가 가장 높은 블록을, 다음 블록으로 제안을 하게 됩니다.
이제 이러한 모델을 도입해보자고 논의되고 있는 와중에 나온 개념이 댕크샤딩 입니다.
Proposer의 역할을 Proposer 와 Builder 로 나누고, PBS 도입.
기존 샤딩 모델의 문제점
기존 샤딩 모델이 폐기된 이유에 대해 앞에서 조금 언급했었습니다. 기존에는 샤딩체인을 처리하려면, 각각의 별도의 체인들이 각자의 트랜잭션을 처리한 다음, 그 처리된 트랜잭션이 실제 비콘체인 합의 레이어로 들어오는 과정을 거쳐야 합니다. 이 때, 64개의 샤드의 모든 데이터를 집계하는 과정에서 모든 샤드의 데이터를 읽어야 해서, 노드가 무거워지는 문제점이 있습니다. 또, 이더리움이 POS로 전환되면서, 비콘체인을 합의레이어로 사용하게 되어 12초마다 한번씩 블록을 생성할 수 있는 슬롯(Slot)들이 생깁니다. 하지만, 모든 샤드들이 동시에 12초마다 한번씩 각 샤드의 블록들을 만들어줘야하고, 64개가 동시에 그런 타이밍을 맞추기가 쉽지 않고, 이 모든 걸 맞추기 위한 기술적인 복잡성이 필요하게 되었습니다. 앞으로 롤업 중심 로드맵을 보니, 트랜잭션 실행은 롤업 Layer 2에서 하고, 데이터 저장만 Layer 1 이더리움에 넣으면 되기 때문에, 굳이 샤드체인에서 트랜잭션 실행을 할 필요가 없어지게 되었습니다.
- 각 샤드의 트랜잭션을 집계하는 과정에서 모든 샤드의 데이터를 읽어야 함.
- 모든 샤드의 블록 생성 타이밍을 맞추기 어려움.
- 트랜잭션 실행은 롤업에서, 데이터 저장만 L1에. → 굳이 샤드에서 트랜잭션 실행할 필요가 없음.
댕크샤딩
기존 샤딩 모델을 개선하여 나온 개념이 댕크 샤딩입니다. 댕크 샤딩은, Dankrad Feist 가 제안한 샤딩 방식으로, 그의 이름을 따서 댕크 샤딩이라고 부릅니다.
댕크 샤딩의 핵심 아이디어는, 트랜잭션 실행과 데이터 저장을 할 수 있는 별도의 샤드 체인을 만들지 말고, 비콘체인의 합의 레이어 안에 데이터를 저장할 수 있는 공간만 확장할 수 있도록 하자는 것입니다.
롤업은, 보통 롤업의 데이터들을 저장하기 위해 콜데이터(Calldata)에 저장한다고 앞서 언급했었습니다. 롤업의 데이터라는 것은, 롤업 안에 있는 계정의 잔액 상태나, 롤업에서 실행된 트랜잭션들을 가리킵니다. 댕크 샤딩은, 롤업의 데이터를 콜데이터에 저장하지 말고, 데이터블랍(Data blob)이라는 것을 만들어, 그 데이터블랍 안에 저장하자는 의견입니다.
그림에서 보면, 각각의 데이터블랍 안에는 트랜잭션들이 들어가 있습니다. Regular tx는 우리가 알고 있는 일반적인 트랜잭션을 가리킵니다. 그리고 Data tx는, 아직 적용되어 있지 않지만, 별도의 트랜잭션 폼을 만들어, 그안에서 데이터블롭의 위치를 연결시켜 놓자는 방식입니다.
콜데이터(Calldata)는 일반적인 트랜잭션인 Regular tx 안에 저장되어 있습니다. 그래서 데이터블랍 안에 직접 들어가 있어, 더 저렴한 가격에 데이터를 더 많이 넣을 수 있는 구조를 데이터블랍을 통해 이루려는 게 댕크샤딩의 목적입니다.
: Dankrad Feist 가 제안한 샤딩
- 핵심 아이디어:
- 트랜잭션 실행과 데이터 저장을 위한 별도의 샤드 체인을 만들지 말고.
- 비콘 체인 내에 데이터 저장만 할 수 있는 샤드를 만들자.
- calldata 대신 blob data
- Data blob
- Regular TX
- Data TX
- Data blob
- blob data 는 트랜잭션 실행에 사용되지 않기 때문에 가스가 더 저렴함.
- 결국 블록의 크기가 커지는 데. 이럴거면 그냥 현재 블록크기를 늘리면 되는거 아닌가?
- 블록의 크기가 커지면 → 노드 및 벨리데이터가 중앙화 될 수 있음.
앞 부분에서 PBS를 설명했었습니다. 빌더, 프로포저, 어테스터로 나누어져 있습니다. 앞으로, 댕크샤딩의 데이터블랍이 적용되면, 커지는 많은 데이터를 무겁게 처리해야 하는 건 빌더들이 됩니다. 데이터블랍이 커질 수록 빌더들은 고성능의 하드웨어를 사용해야 하고, 프로포저나 어테스터는 그 데이터가 커지더라도 영향을 적게 받게 됩니다.
PBS
비탈릭 부테린이 최근 자신의 블로그에 이더리움과 블록체인 네트워크의 엔드게임에 대한 의견을 공유했습니다. 미래의 블록체인 네트워크 주요 요소들을 다음과 같이 구성될 것으로 예상하고 있습니다.
중앙화된 블록 생성 프로세스(Centralized Block Production), 탈중앙화된 블록 검증 프로세스(Decentralized Block Validation), 트랜잭션 검열 방지의 강화(Strong anti-censorship protection).
아래 그림은, 이더리움이 롤업 기반 확장되기 때문에, 점점 블록 생성은 중앙화가 될 것이고, 블록의 검증은 탈중앙화가 될 것이라는 것입니다. 그래서 댕크샤딩이 주요 로드맵 중에 하나로 떠오르게 된 이유입니다.
- 비탈릭 부테린이 고안한 “End Game”
- 중앙화된 블록 생성 프로세스 (Centralized Block Production)
- 탈중앙화된 블록 검증 프로세스 (Decentralized Block Validation)
- 트랜잭션 검열 방지의 강화 (Strong anti-censorship protection)
트랜잭션 검열 방지의 강화 (Strong anti-censorship protection)
위에서 언급된 트랜잭션 검열 방지의 강화(Strong anti-censorship protection)를 위해, Censorship Resistance List을 이용합니다. 빌더가 블록 생성 과정에서 특정한 트랜잭션을 제외하지 못하도록 프로포저가 빌더에게 제공하는 트랜젝션 리스트입니다.
탈중앙화된 블록 검증 프로세스 (Decentralized Block Validation)
데이터블랍(Data blob)을 도입하기로 했지만, 데이터를 무한하게 무겁게 만들 수 없으니, 그 데이터블랍들을 가볍게 만드는 방법이 필요합니다.
데이터블랍을 가볍게 하기 위한 첫번 째 제안은, 데이터블랍을 일정 기간 이후에 삭제 하자는 아이디어 입니다. EIP-4844 라는 Shard Blob Transactions 에 정의된 내용입니다. 이 규격은 Proto-DankSarding 이라고 불립니다. 댕크 샤딩이 적용되려면, PBS 도 있어야 하고, 합의레이어에서 지원해줘야 할 것들도 많기 때문에, 이 모든 작업들이 다 될 때까지 기다리지 말고, 지금 할 수 있는 방법들을 해보자는 의미에서 나온 아이디어 입니다.
EIP-4844는, 데이타블랍을 일정 시간 이후에 삭제할 수 있도록 하는 규격입니다.
일정 기간 이후에 데이터를 지운다는 것은, 트랜잭션 검증 타이밍에 검증해야할 데이터가 없어질 수도 있습니다. 그래서 그 데이터가 있는지 없는지를 체크해야 하는데, 이를 위해 나온 개념이 DAS(Data Avaliality Sampling) 입니다. DAS는 데이터블랍의 일부만 샘플링하더라도 전체를 이용할 수 있는 데이터인지 아닌지 샘플링을 통해 확인할 수 있는 기법입니다. 그리고 데이터블랍 안에 특정 데이터가 존재하는지 확인할 수 있는 개념이, KZG commitment 입니다. 일부 데이터만으로도 검증할 수 있는 기법입니다.
데이터의 이용 가능 여부는 DAS 를 통해 확인할 수 있고, KZG commitment 를 이용하여, 일부 데이터만으로도 검증 가능하게 함으로써, 검증 과정을 가볍게 할 수 있어 검증 과정을 탈중앙화할 수 있게 됩니다.
- 데이터를 가볍게 만들기 위한 방법 필요
- EIP-4844: Shard Blob Transactions
Blob 데이터를 일정 기간 지난 후에 삭제하자.
30~60일 이후에 지울까
(Proto-Danksharding)
Data Blob
- 일정 기간 이후에 삭제할 수 있도록 만들어야 하고,
- 검증할 때 데이터가 없을 수도 있으니, 데이터를 이용할 수 있는지 여부를 체크해야 함. ⇒
DASData Availability Sampling - 데이터의 일부만 샘플링하는 것으로도, 데이터가 이용 가능한지 확인할 수 있는 기법
KZG commitment
Blob 데이터 안에 특정 데이터가 존재하는지 확인 가능
→ 일부의 데이터만으로도 검증 가능
데이터가 이용가능하다는 것을 DAS 를 통해 알고, 일부 데이터만 가지고 검증이 가능하게 함으로써 (KZG Commitment) 검증과정을 가볍게 만들수 있음 ⇒ 검증 과정의 탈중앙화
마치며
이더리움은 롤업 기술을 기반으로 Layer 2 기술과 댕크샤딩 기술들을 조합하여, 확장성을 확보하고 높은 처리량과 낮은 수수료를 제공하도록 노력하고 있습니다. 이를 통해 이더리움은 블록체인 기술의 발전과 함께 더욱 성숙된 스마트 컨트랙트 플랫폼으로 발전할 것으로 예상됩니다.
Links
