Danksharding을 ‘최대한’ 이해해보자

12 min readApr 1, 2022

이더리움 로드맵에서 가장 중요한 단어

출처 코인이지 공식 작가 MOYED: https://moyed.substack.com/p/danksharding-?s=r

서론

주의할 점

제목과 같이 나는 Danksharding을 최대한 이해하려고 노력하였으나, 잘못된 내용이 있을 수 있다. 이 글은 Danksharding의 큰 흐름을 이해하는데 도움을 주는 용도로, 자세한 내용은 직접 Rabbithole를 타고 내려가기를 바란다.

이더리움

멀티체인 내러티브가 주목받고, 이더리움의 가스비가 치솟으면서, 이더리움에 대한 관심이 과거에 비하여 떨어진 것 같은 느낌이 든다. 하지만, 여전히 이더리움은 가장 성공한 L1이며, 미래에도 그러할 확률이 매우 높다.

새로운 내러티브가 계속해서 등장할 동안, 이더리움은 PoS로의 전환, 그리고 scalability를 증가시키기 위한 여러 업데이트를 꾸준히 계획해오고 있었다. 그중에서도, danksharding은 가장 최근에 제안된 것으로, 이더리움의 성능을 크게 업그레이드시킬 것으로 많은 관심을 받고 있다. (Danksharding을 제외하고는, ZK-SNARK 기술이 가장 핫한 것 같아서, 나중에 다뤄보고 싶다.)

용어 정리

샤딩
샤딩은 데이터베이스를 여러 부분으로 쪼개는 것을 말하는데, 쪼개진 부분을 샤드라고 한다.
slot
12초로, 새로운 비콘 블록과 샤드의 blob이 제안되는 시간의 단위로, 32slots이 1 epoch이다.
validator & proposer
PoS에서는 validator들이 블록 생성과 검증을 함꼐 담당하는데, 블록 생성의 권리를 얻은 validator를 proposer라 부른다.
blob
매 slot에 갹 샤드의 proposer에 의해 제안되는 512kb의 데이터 덩어리이다.
committee
랜덤하게 선택된 128명의 validator들로, 각 샤드에 배정된다.
MEV
Miner Extractable Value, 혹은 Maximal Extractable Value로, miner(PoS에서는 proposer)가 블록을 생성할 때, 포함시킬 트랜젝션을 재정렬, 추가, 제외 같은 활동을 통해 이득을 보는 행위이다.
mempool
아직 블록에 포함되지 않은 트랜젝션들이 모여있는 공간

Danksharding 이전의 상황

롤업의 등장

기존에 이더리움은 “The Merge”와 함께 샤딩을 도입하여서, 유저들은 64개의 샤드 체인을 트랜젝션 실행과 스마트 컨트랙트 연산의 execution layer로 사용하려 했다.

하지만, 몇가지 이유로, 로드맵을 수정하여서 샤드들을 롤업의 데이터를 저장하는 data availability layer로 사용하기로 하였다,

이러한 변화의 가장 큰 이유는 롤업의 성능이 생각보다 훨씬 뛰어났기 때문이다. 비탈릭의 rollup-centric roadmap에 의하면, eth2의 샤드를 execution layer로 사용하였을 때 1000~5000 TPS가 예상되는데, 이미 롤업은 3000 TPS가 가능하고, 롤업 + 샤드를 data availability layer로 사용할 경우 ~10000 TPS가 가능하다고 한다. 그렇기 때문에, 굳이 성능이 더 뛰어난 롤업을 두고, 샤드를 execution layer로 사용할 이유가 없다.

이에 추가적인 이유로, EVM 연산을 샤딩하는 것보다, data availability를 샤딩하는 것이 훨씬 안전하다. 아무래도 데이터를 연산하는 것이 그냥 저장하는 것보다 훨씬 복잡하기 때문에 보안 측면에서도 차이가 있는 것 같다.

샤딩 + DAS

그렇다면 롤업을 통해 저장된 엄청난 양의 데이터의 availability를 노드들이 어떻게 효율적으로(전체 데이터를 다운로드하지 않고도) 확인할 수 있을까? 비탈릭의 An explanation of the sharding + DAS proposal에 따르면, 솔루션은 샤딩과 Data availability sampling(DAS)이다.

샤딩

샤딩의 메커니즘은 다음과 같다.

전체 데이터를 여러 blob들로 나눈다.
전체 validator들을 랜덤하게 여러 committee들로 나눈다.
각 committee에 해당하는 validator들은 자신이 배정받은 blob의 availability를 검증한다.
만약 해당 검증에 문제가 없으면, 서명을 남긴다.

여기서 중요한 것은 committee가 랜덤하게 골라져야 한다는 것이다. 아무래도, 샤딩의 약점은 단일 체인보다 51% 공격에 취약하다는 것이다. 만약 committee가 랜덤하게 샘플링되지 않으면, 한 committe의 과반수 이상을 포섭한 뒤에 해당 샤드를 지배할 수 있다. 그렇기 때문에, 난수 생성 알고리즘을 통하여 validator를 배정한다.

DAS

Data availability sampling은 과거 이 글에서 자세히 다룬적이 있다.

Data availability sampling은 각 validator들이 blob에서 일부 데이터 chunk만을 랜덤하게 고른 뒤에 다운로드하여서 만약 해당 데이터가 접근가능하면 전체 blob의 data availability가 유효하다고 판단하는 방식이다. 하지만, 이 경우, 악의적인 block producer가 99%의 데이터는 공개하였지만, 1%는 공개하지 않고, 이 1%의 데이터에 악의적인 트랜젝션을 숨기면, validator는 이를 발견하지 못할 수 있다. 이를 방지하기 위하여 Erasure coding을 사용한다.

Erasure coding이라는 것을 사용하여서 blob을 인코딩하면, 50%의 데이터만으로도 전체 blob을 복구하는 것이 가능해진다. 결국 block producer가 blob안에 악의적인 트랜젝션을 숨기고 싶으면, 최소 51%의 데이터를 숨겨야 하고, 이는 여러 validator들의 DAS를 통해 발견하기 쉽다.(그렇기 때문에, DAS를 사용하기 위해서는 어느정도 이상의 honest validator들이 필요하다.)

마지막으로 DAS에서 고려해야 되는 것은 ‘어떻게 erasure coding이 올바르게 되었는지 확인하는가?’이다. 과거에 내가 쓴 글에서는 다차원의 Reed-Solomon code를 통해서 확인한다고 하였는데, 이더리움의 경우에는 KZG commitment라는 것을 사용한다.

전체 큰 그림

앞서 우리가 살펴본 내용들을 합치면 다음과 같다.

롤업의 데이터들을 샤드에 저장한다.
각 샤드에 대하여 각 proposer들은 blob을 제안하고, committee의 멤버들은 해당 blob의 데이터가 available하면 투표를 한다.
committee의 2/3 이상의 해당 blob이 available하다고 투표하면, blob은 유효하다고 판단되어, blob의 헤더가 비콘 체인에 포함된다.

Danksharding

Danksharding 개요

가장 큰 차이점은 기존에는 각 샤드별로 blob을 제안하는 proposer가 있어서, blob들이 독립적으로 제안되었다면, danksharding은 모든 샤드의 blob들이 비콘 블럭 안에 포함되어서 함께, 한번에 제안된다. 다만, 여전히 committee의 validator들은 전체 데이터 중 자신들이 해당하는 샤드의 blob만 검증한다.

장점

Danksharding의 장점은 무엇일까?

샤딩의 디자인이 간단해진다.
각 샤드별로 blob을 처리하는 것보다는, 한번에 처리하는 것이 훨씬 간단할 것이다. 이는 보안 측면에서도, 개발 측면에서도 큰 장점이다.
네트워크의 딜레이가 없어진다.
기존의 디자인에서는 특정 샤드의 blob에 대한 committee의 투표가 한 slot안에 완료되지 않아서 이를 블록이 기다려야 하는 상황이 있을 수 있다. 하지만, danksharding에서는 한 블록 안에 모든 샤드의 blob이 담겨있기 때문에 기다릴 필요가 없다.
L2와 L1의 synchronous call이 가능하다.
한 비콘 블록 안의 트랜젝션이 롤업의 데이터까지 접근 가능하기 때문에, L1과 L2의 atomic 트랜젝션이 가능할지도 모른다.

Danksharding이 기존에 불가능했던 이유

Danksharding에는 치명적인 약점이 있다. 만약 danksharding처럼 모든 데이터를 하나의 블록으로 처리한다면, 블록의 크기가 커져서, validator에게 높은 요구사항을 강요하게 되고, 이는 중앙화로 이어져서 체인의 보안성을 떨어트린다. 이 문제를 해결해주는 것이 PBS이다.

Proposer/builder seperation(PBS)

PBS에 대하여 설명하기 전에 먼저, 비탈릭의 엔드게임에 대하여 소개하고 싶다.

엔드게임

비탈릭의 Endgame에서 비탈릭은 블록체인이 최종적으로 취할 형태에 대하여 이야기하였는데, 요지는 결국에는 블록 생성은 중앙화될 수 밖에 없고, 블록 검증은 탈중앙화되어야 한다는 것이다.

블록 생성이 중앙화될 수 밖에 없는 이유는 여러가지인데, 첫번째로는 danksharding처럼 많은 트랜젝션을 처리할 수록, 그에 따라서 블록 크기가 커지고, validator에게 요구사항의 수준이 높아져서 중앙화로 이어지게 된다. 두번째는 cross-domain MEV 때문이다. Cross-domain MEV는 여러 체인 간의 차익거래를 통해 이득을 보는 형태인데, 여러 체인의 블록 생성을 담당하는 사람이 cross-domain MEV를 챙길 확률이 높다. 이에 따라서, Arbitrum 블록 생성자가 Optimism 블록 생성도 하고, Polygon 블록도 생성하는 중앙화가 일어날 수 밖에 없다. 결국 블록 생성 시장은 매우 특화된 형태로, 소수의 전문가들이 여러 체인을 담당하는 형태가 될 것이다.

결국 블록 생성이 중앙화될 수 밖에 없다면, 체인의 보안성을 지키기 위해서는 블록 검증을 탈중앙화한 형태로 만들어서 이 블록 생성자가 자신의 힘을 남용할 수 없게 만드는 것이 중요하다.

기존의 방식에서 불가능한 이유

그렇다면, 어떻게 비탈릭의 엔드게임처럼 블록 생성은 중앙화되어도, 블록 검증은 탈중앙화된 형태를 유지할 수 있을까?

기존의 PoS에서는 불가능하다. PoS에서 validator는 proposer로 선택을 받는 경우, 트랜젝션을 mempool로부터 모아서 블록을 생성하고, 다른 validator들은 이를 검증한다. validator가 블록 생성과 검증의 역할을 함께 수행하기 때문에, 블록 생성과 검증을 분리하는 것은 불가능하다.

PBS 개요

PBS는 기존의 proposer의 역할을 proposer와 builder로 나눠서 블록 생성과 블록 검증의 역할을 디커플링시킨다. PBS의 메커니즘은 다음과 같다.

Proposer는 mempool로부터 트랜젝션을 모은 리스트를 Builder들에게 전달한다.
각 Builder들은 proposer로부터 받은 리스트 안의 트랜젝션을 각자 재정렬하여서 블록을 만들고, 옥션에 입찰한다.
Proposer는 각 Builder들의 입찰 금액을 보고, 가장 높이 입찰한 builder의 블록을 선택 후, 전파한다.

Builder 역할은 실제로 블록을 생성해야 되기 때문에, 높은 자격요건과 MEV의 네트워크 효과로 인해 중앙화되어, 소수의 전문가들이 하게될 것이다. 하지만, proposer의 역할은 누구나 낮은 하드웨어를 가지고도 할 수 있어서 탈중앙화되고, proposer가 곧 validator이므로, 네트워크의 보안도 지킬 수 있게 된다.

추가적인 효과로, 기존에는 MEV에 대하여 전문적인 지식과 하드웨어를 갖춘 proposer만 MEV 수익을 얻었다면, PBS를 통해, MEV 수익은 builder뿐만 아니라, 낮은 하드웨어를 가지고 있는 proposer에게도 나눠진다.

결국, PBS를 통하여 블록 생성은 중앙화되어도, 블록 검증이 탈중앙화할 수 있기 때문에, danksharding이 문제 없이 모든 샤드의 blob들을 비콘 블록과 함께 처리할 수 있게 되었다.

crList

한가지 남은 문제점은, builder가 의도적으로 proposer가 보낸 리스트 중 특정 트랜젝션을 포함시키지 않는 검열의 가능성이 있다는 것이다. 이를 방지하는 것이 crList이다. Proposer가 트랜젝션을 모아서 보내는 리스트를 crList라고 하는데, Builder가 블록을 만든 이후, proposer는 실제 블록에 포함된 트랜젝션들과 자기가 보낸 crList를 비교하여서, 만약에 두개가 다르면, 이를 거부한다. 그렇기 때문에, builder는 crList 안의 트랜젝션을 모두 블록에 포함시킬 수 밖에 없다.

정리

롤업의 성능 덕분에 이더리움은 샤드들을 데이터 저장 레이어로 사용하고, 트랜젝션의 실행은 롤업에게 맡기는 디자인을 선택하였다. 이후, PBS와 crList를 통하여, 블록 생성과 블록 검증을 분리할 수 있게 되었고, 블록 생성이 중앙화되어도, 검증은 탈중앙화 형태를 유지하여 높은 연산력과 보안성을 동시에 가질 수 있게 되었다. 이에 따라 모든 샤드의 blob들을 비콘 블록안에 포함시키는 danksharding이 가능해졌고, danksharding은 기존 디자인의 단점을 보완하고, 불가능하던 여러 것들을 가능케 한다.