Klaytn 사용성 개선 Series #5: 명시적인 타입 도입
전체 포스팅 목록은 여기에서 확인하세요.
Klaytn은 블록체인 플랫폼의 사용성을 개선하기 위해 다양한 노력들을 했습니다. 아래의 포스팅을 통해 사용성 개선 기능들을 살펴보고자 합니다.
지난 포스팅에서는 role-based key에 대해서 알아보았습니다. Role-based key를 이용하여 계정의 권한을 분산함으로써 다양한 서비스 개발 시나리오가 만들어질 수 있다고 생각합니다. 이번 포스팅에서는 명시적인 타입(explicit types)에 대해서 알아보겠습니다.
앞의 네 가지 기능들은 사용자 또는 서비스 개발사의 입장에서 필요한 기능이라면, 명시적인 타입은 플랫폼 개발자의 사용성을 개선하기 위하여 설계되었습니다. 기본적으로 자료구조에 타입이라는 필드를 명시하게 되면, 각 타입별 자료구조를 다른 형태로 가져갈 수 있습니다. 이러한 설계는 자료구조의 유연함을 가져오고, 따라서 미래에 기존 자료구조와 호환성을 유지하면서 새로운 형태의 자료구조를 쉽게 추가하고 유지할 수 있다는 장점이 있습니다. 하지만 당연히 단점도 존재합니다. 타입을 먼저 해석하고 자료구조를 해석해야 하는 로직이 들어가게 되고, 이는 성능에 영향을 끼치게 됩니다.
저희는 타입 분석 로직에 대한 오버헤드보다 자료구조의 유연함을 가져가는 것이 더 중요하다고 생각했습니다. 앞으로 계속 Klaytn이 발전하고 개발이 계속 될 예정인데, 이러한 유연함을 미리 설계해 놓지 않으면 나중에 유지보수가 더 어렵다고 판단했습니다.
이러한 고민을 통해 명시적인 타입이 설계되고 구현되었습니다. 현재 명시적인 타입은 세 가지 자료구조에 반영이 되어 있습니다: 계정(account), 계정 키(account key), 트랜잭션(transaction).
계정(account)
계정은 기본적으로 사용자 계정(user account)와 컨트랙트 계정(contract account)로 구분됩니다. 사용자 계정에는 code hash나 storage root같이 컨트랙트와 연관된 데이터는 가지고 있을 필요가 없습니다. 명시적인 타입을 도입하면 이러한 데이터를 제거하여 저장 공간을 절약할 수 있습니다. 사용자 계정이 컨트랙트 계정보다는 많이 생성되기 때문에, 이러한 저장 공간 절약이 큰 효과를 발휘할 수 있습니다. 실제로 이더리움의 경우에도 2019년 9월 기준 전체 계정의 80%가 사용자 계정이었습니다. 또한, 앞으로 새로운 형태의 계정이 필요해지더라도 쉽게 추가해 나갈 수 있습니다.
아래의 그림은 컨트랙트 계정과 사용자 계정이 가지고 있는 자료구조를 보여주고 있습니다. 더 자세한 정보는 KlaytnDocs에서 확인하실 수 있습니다.
계정 키(account key)
계정 키는 계정 자료구조 내 키를 저장하기 위한 자료구조이며, 이 키도 다양한 종류를 지원하기 때문에 명시적인 타입을 도입하였습니다. 이 계정 키 타입을 통해 한 계정에서 다양한 키 형태(single public key, multisig, role-based key)를 지원할 수 있습니다. 더 자세한 정보는 KlaytnDocs에서 확인하실 수 있습니다.
트랜잭션(Transaction)
트랜잭션은 Klaytn network의 상태를 변화시키는 기본 동작 단위입니다. 상태를 변화시키는 기능은 아래 테이블에서 볼 수 있듯이 다양합니다. 각 기능에 대한 설명은 KlaytnDocs에서 확인하실 수 있습니다. 이러한 다양한 기능들을 명시적인 타입으로 분리하면 다양한 장점이 있습니다.
첫번째는 최적화가 가능하다는 점입니다. 각 트랜잭션 타입이 명확하게 한 가지 일을 수행하기 때문에 그에 맞는 최적화가 가능합니다. 예를 들어, KLAY를 전송하는 트랜잭션의 경우에는 컨트랙트를 실행하는 기능이 필요없기 때문에, 이 부분을 제거하는 최적화가 가능해집니다.
두번째는 새로운 트랜잭션 기능을 만들기 쉽다는 점 입니다. 다른 파라미터가 필요한 새로운 트랜잭션 기능이 필요하다고 할 때, 새로운 트랜잭션 타입을 추가하여 쉽게 구현이 가능합니다. 예를 들어, 트랜잭션 풀에 들어 있는 트랜잭션을 취소시키고 싶을 때, 이 기능을 수행할 수 있는 새로운 트랜잭션 타입(TxTypeCancel)을 정의할 수 있습니다. 또는, 서비스 체인을 위한 별도의 트랜잭션 타입(TxTypeChainDataAnchoring)을 정의할 수도 있습니다. 물론, 각 트랜잭션 타입이 필요한 필드들만 가지도록 설계하는 것도 가능합니다.
트랜잭션의 경우, 매 블록마다 여러번 실행되기 때문에, 실행 성능이 중요합니다. 타입을 도입하더라도 실행성능이 크게 저하되지 않아야 합니다. 아래 도표에서는 타입이 없던 기존의 트랜잭션 자료구조와 타입을 도입한 자료구조 간의 실행 성능을 비교하였습니다. 트랜잭션 타입 분석 로직에 대한 오버헤드와 계정 키에 따른 확인 로직에 대한 오버헤드로 인해 성능이 저하되었으나, 그 비율은 10% 미만으로 매우 작은 수준임을 확인할 수 있습니다.
이번 포스팅에서는 명시적인 타입을 도입하여 각 자료구조 별로 어떻게 반영했는지 알아보았습니다. 명시적인 타입 도입을 통해 자료구조의 유연함과 확장성, 그리고 저장공간의 최적화를 얻어낼 수 있었습니다. 반면, 타입 분석 로직이 추가되어 성능 오버헤드를 발생시키지만 그것은 매우 작은 수준임을 확인했습니다.
이 포스팅으로 Klaytn 사용성 개선 시리즈는 마치도록 하겠습니다. 이후 Klaytn의 다양한 기술들에 대해 설명할 수 있는 문서들을 계속 추가해 나가도록 하겠습니다. 감사합니다.
