SEARCH

검색창 닫기
  • BTC
  • ETH
  • XRP
  • BCH
bithumb제공 bithumb제공
  • BTC
  • ETH
  • XRP
  • BCH
bithumb제공 bithumb제공

[이드콘 한국 2019]블록체인 개발자가 말하는 콘트랙트 설계 시 주의할 점

이진호 헥슬란트 개발자./사진=도예리 기자

“(개발자는) 자기가 설계한 기능만 잘 돌아가는지 확인해선 안 됩니다. 내가 설계한 기능 이외의 것도 테스트해야 합니다.”

27일 코엑스 그랜드볼룸에서 열린 ‘이드콘 한국 2019’에서 이진호 헥슬란트(Hexlant) 개발자는 ‘스마트 콘트랙트 케이스 스터디(Case Study)’를 주제로 발표하며 이같이 말했다.

헥슬란트는 블록체인 엑셀러레이티과 콘트랙트 개발 및 안정성 검증, 블록체인 투자 플랫폼 등 기술 기반의 비즈니스를 진행하는 블록체인 기술 연구소다. 이 중에서도 헥슬란트의 대표 기술력은 블록체인 프로젝트 안전성 검증과 콘트랙트(Smart Contract) 개발이다. 안전성 검증이란 자체 개발한 테스트넷을 바탕으로 설계의 오류나 문제점을 살피는 오딧(Audit)서비스를 일컫는다. 또 계약 조건을 블록체인에 기록하고 조건이 충족되었을 경우에만 계약이 실현되는 기술을 설계하는 것을 스마트 콘트랙트 개발이라 말한다.



비잔티움 하드포크 발생하기 전(좌)에는 스테이터스 필드가 없다. 비잔티움 하드포크가 발생한 후(우)로 스테이터스 필드가 생겼다./사진=김연지 기자

이 개발자는 “지난해부터 올해까지 약 30~40여 개 프로젝트 감사를 진행해왔다”며 세 가지 케이스를 구분 지었다. 그는 첫 번째로 거래소 입금 처리 오류 사례를 들었다. 그는 “‘비잔티움 하드포크’ 이후에 이더스캔(Etherscan)에 스테이터스 필드(Status Field·현 상황을 보여주는 창)가 생겼다”며 “거래소가 이 부분만 보고 트랜잭션 성공 여부를 따질 때 문제가 발생한다”고 했다. 지난 2017년 10월 이더리움은 ‘비잔티움’ 하드포크를 단행했다. 그는 “실제 거래가 성사되지 않더라도, 함수 자체가 정상적으로 종료되면 스테이터스 필드에 ‘성공(success)’이라 뜬다”며 “개발자가 이 부분에 더 주의를 기울여야 한다”고 했다.

두 번째 사례로는 논리적 오류 결함을 들었다. 이 개발자는 “이더리움 콘트랙트에선 한번 코드가 배포되면 수정이 불가능하다”며 “특히 조건문 실수에 주의해야 한다”고 강조했다. 그는 “‘나(관리자)만 할 수 있고 넌(일반 사용자) 할 수 없지’란 조건문을 ‘나(관리자)만 할 수 없고, 넌(일반 사용자) 할 수 있지’로 잘못 입력한 실수가 대표적 예”라고 밝혔다.

마지막으로 그는 “블록체인 이더리움 콘트랙트에 와서 가스비(Gas fee·이더리움상에서 스마트 콘트랙트를 처리할 때 이용자에게 부과되는 수수료)를 단순히 수수료로 생각할 때 문제가 발생한다”고 말했다. 코드상으론 문제가 없어 보여도 “이더리움은 가스비 리미트(limit)가 정해져 있다”며 “블록체인에서 처리할 수 있는 수행 연산의 단위에 한계가 있기 때문에 이를 고려하지 않으면, 수 천만 원 비용만으로도 (암호화폐) 거래소 하나를 망가뜨릴 수도 있다”고 했다.

이 개발자는 이러한 문제들을 방지하기 위해선 “정상적 값을 넣었을 때 정상적 값이 나오는지 테스트하는 것뿐 아니라, 비정상적 값을 넣었을 때도 예외 처리되거나 문제는 없는지 테스트해야 한다”고 강조했다. 또한 “항상 기술 업데이트에 관심을 두고 테스트 검증 과정을 거쳐야 한다”고 덧붙였다.
/도예리기자 yeri.do@decenter.kr

도예리 기자
yeri.do@decenter.kr
< 저작권자 ⓒ 디센터, 무단 전재 및 재배포 금지 >

이메일보내기