블록체인 플랫폼을 만들려면 합의 알고리즘 외에도 트랜잭션 포맷, P2P 네트워크, 직렬화, 스토리지, 키 관리, 암호 알고리즘 등 여러 요소들을 고민해야 합니다. 하지만 보통 블록체인 기술 백서는 합의 알고리즘 위주로 1-2개의 주요 기술 요소만 설명하고 다른 요소에 대해서는 언급을 하지 않는 경우가 많습니다.

블록체인 기술을 직접 만들려면 이런 요소들도 간과할 수가 없는데, 비트코인, 이더리움 소스 코드를 보는 방법 외에는 마땅한 리소스가 없는 것도 사실입니다. 블록체인 구현 기술에 대해 궁금한 분에게 추천 드리는 문서는 Tendermint의 CTO인 Ethan Buchman가 석사 논문으로 작성한 Tendermint: Byzantine Fault Tolerance in the Age of Blockchains입니다.

Tendermint 합의 알고리즘 뿐만 아니라 블록체인 구현에 필요한 여러 기술 요소들에 대해 간결하게 잘 설명하고 있고, 배경 지식, 다른 블록체인 플랫폼과의 비교 등도 포함되어 있어서 블록체인 기술을 구현 수준에서 공부하시는 분들에게 좋은 가이드가 될 것 같습니다.

Go 언어로 구현된 Tendermint 소스 코드도 참고하세요!

이더리움은 ECDSA 이용하여 트랜잭션을 서명하고 서명값(r, s, v)를 트랜잭션에 붙여서 보냅니다. 트랜잭션 해시는 서명을 포함하기 때문에 서명값에 따라 트랜잭션의 해시 값도 달라집니다.

이더리움 블록 헤더의 transactions root 필드는 각 블록 내의 트랜잭션 인덱스를 키로 각 트랜잭션의 해시를 저장해서 만든 merkle patricia tree 루트입니다. 블록을 검증할 때 헤더의 transactions root가 실제 트랜잭션으로 계산한 transactions root와 같은지 확인하는 방법으로 트랜잭션의 위변조 여부를 검사하고 있습니다.

그런데 서명 데이터 중 하나인 s는 타원곡선 상의 점이기 때문에 x축에 대칭인 타원곡선의 특징상 하나의 서명에 대해 high s, low s 두 개의 값이 모두 유효한 서명이 됩니다. 따라서 트랜잭션을 받아서 low s를 high s로 바꾸는 것만으로 서명의 유효성을 해치지 않고 트랜잭션의 해시 값을 바꿀 수 있게 됩니다.

이러한 문제를 트랜잭션 malleability라고 부르는데, 이더리움에서는 이 문제를 해결하기 위해 두 개의 s 값 중에 low_s만을 유효한 서명으로 인정하고 있습니다. 비트코인에서도 같이 같은 이유로 트랜잭션 malleability 문제가 있었고 역시 low_s만 유효한 서명으로 인정하는 방법으로 문제를 해결하였습니다.

비트코인의 BIP-62도 이 문제에 대해 설명하고 있으니 관심 있으신 분은 읽어보시기 바랍니다.

이더리움은 타원곡선디지털서명(ECDSA) 알고리즘을 이용하여 트랜잭션을 서명합니다. 비트코인과 마찬가지로 secp256k1 곡선을 사용하고 있습니다. ECDSA로 서명한 메시지를 검증하려면 서명에 사용한 비밀키에 대응하는 공개키가 필요합니다.

그런데 네트워크로 전송되는 이더리움 트랜잭션 포맷을 보면 서명자의 공개키가 포함되어 있지 않습니다. 트랜잭션에 보낸 사람의 주소는 포함되어 있지만 이더리움 주소는 공개키의 해시값이기 때문에 주소만 가지고 공개키를 복원하는 것은 불가능합니다.

그럼 이더리움은 어떻게 트랜잭션이 서명이 유효한지 검증할 수 있을까요? 놀랍게도 ECDSA는 메시지(트랜잭션의 해시)와 서명만 있으면 서명에 사용된 공개키를 복원하는 게 가능합니다. 완벽한 복원은 아니고 후보를 4개까지 줄일 수 있습니다.

그래서 이더리움은 4개의 후보 중에 어떤 공개키를 써야 하는지를 트랜잭션에 포함시켜서 보냅니다. 이더리움 트랜잭션 서명은 r, s, v 컴포넌트로 이루어져 있는데 여기서 r, s는 각각 32바이트로 이루어진 서명 데이터이고, v는 1바이트로 4개의 후보 중에 어떤 공개키를 사용해야 하는지 지정합니다.

자세한 내용이 궁금하신 분은 SEC 문서의 4.1.6 Public Key Recovery Operation을 읽어보시기 바랍니다.