CodeChain의 Scalability Solution — Sharding

Kiyun Kim
5 min readJun 25, 2018

--

암호화폐의 확장성 이슈는 암호화폐 태동기부터 꾸준히 제기되어 왔다. 비트코인의 뒤를 잇는 이더리움도 확장성 문제를 해결하기 위해 꾸준히 고민하고 있다.

이더리움이 scalability를 해결하기 위해 제시한 해법은 sharding이다. 현재 이더리움은 모든 노드에서 모든 트랜잭션을 처리하고 있다. sharding은 전체 네트워크를 shard라는 여러 개의 소규모 네트워크로 나누고, 트랜잭션이 특정한 shard에서만 처리가 되게 하여 전체 네트워크의 트랜잭션 처리량을 높이겠다는 것이 기본적인 목표이다. 이론적으로는, 기존 네트워크가 1초에 처리할 수 있는 트랜잭션이 m개였다면, n개의 shard로 나뉘어진 네트워크가 처리할 수 있는 트랜잭션은 1초에 최대 n*m-c까지 만큼 늘어날 수 있게 된다. 여기서 c는 네트워크를 shard로 나눔으로써 인해 생긴 부하로 인해 줄어드는 처리량이다.

이렇게만 보면 sharding이 완벽한 해결 방안인 것 같지만, sharding이 도입되기 전에 해결해야 하는 여러 문제들이 있다. 가장 큰 문제는 sharding간 트랜잭션이 발생했을 때이다. 각각의 shard에서 일어나는 트랜잭션은 다른 shard에 반영이 되지 않기 때문에, 거래에 쓰이는 돈이 이중 지불이 되었는지, 그리고 거래 내역이 똑바로 반영이 되었는지를 확인하기 위해 별도의 장치가 필요하다. receipt 이라는 개념을 도입하면 shard간 거래까지는 구현이 가능하지만, shard간 스마트 컨트랙 호출 같은 좀 더 복잡한 문제들은 아직까지 미구현 상태이다. 앞으로 이더리움이 로드맵을 따라 미구현된 개념들을 성공적으로 구현할 수 있을지, sharding으로 성공적으로 트랜잭션 처리량을 늘릴 수 있을지는 좀 더 지켜봐야 한다.

CodeChain’s Sharding

CodeChain에서는 sharding의 부작용을 줄이기 위해 여러 방법을 도입했다.

첫째, shard에 account를 저장하는 대신 asset을 저장하는 것이다. 위에서도 언급했듯이 shard 방식을 도입하였을 때 문제는 shard간의 트랜잭션인데, account 대신 asset을 저장함으로써 shard간의 트랜잭션을 최소화 시킬 수 있다. 대부분의 거래는 동일한 서비스 안에서 일어날 것이기 때문에, shard에 같은 서비스의 asset을 저장한다면 다른 shard와 거래를 할 일이 최소화되어 부담을 줄일 수 있다.

둘째, shard간의 거래를 할 때 receipt를 쓰기보다는, CAS와 유사한 방식으로 같은 샤드에서 두 트랜잭션이 동시에 실행되지 못하도록 하였다.

마지막으로, world라는 개념을 도입하였다. World는 shard의 하위 개념으로, 하나의 shard에는 여러 개의 world가 존재할 수 있다. world의 특징으로는 world의 소유자는 asset을 만들 수 있다는 점이다. shard와 world가 어떻게 적용될 수 있는지 예를 들어 보자면, 하나의 shard를 따로 만들 만큼 크지는 않은 서비스 개발사 A와 B가 같이 shard를 만들고, A와 B는 각각 world를 만들어 서비스에 필요한 자산을 각각 만들어 낼 수 있다. 구조를 이런 식으로 만들면 같은 서비스에서 만들어진 asset의 경우 같은 world, shard 안에 존재하도록 하였다.

sharding 이외에도, scalablity를 해결하기 위해 도입할 수 있는 여러 가지 다른 방안들도 있다. SegWit처럼 서명 부분을 따로 떼어내어 한 블록에 저장될 수 있는 거래량을 늘려 TPS(transaction per second)를 높일 수도 있고, 여러 블록체인을 연결시켜 총 블록체인의 TPS를 높일 수도 있고, openess를 제약함하여 합의에 참여하는 노드 수를 줄여 TPS를 높일 수도 있다. scalability를 높이기 위한 방안들을 도입하기 전에 고민해 봐야 할 점은, TPS를 높이기 위해 취하는 방법들은 거의 대부분 기회 비용이 있다는 점이다. TPS를 높이기 위해 보안성을 희생할 수도 있고, 탈중앙화를 희생할 수도 있다. 무작정 TPS를 높이는 데에 집중하기보다는 그 기회 비용이 무엇 인지를 생각해보고 알맞은 방법을 도입하는 것이 중요하다.

샤딩에 대해 보다 자세히 알고 싶으시면 슬라이드를 참고, 코드는 여기서 확인하시면 됩니다.

CodeChain 소스코드는 github repo에서 확인 가능합니다. 개발자간 실시간 소통을 위해 gitter channel도 운영중이니 어서 들어오세요!

--

--