Hyperledger Fabric을 활용한 블록체인 투표시스템 구현 방안

하이퍼레저  패브릭의  동작  방식

하이퍼레저 패브릭은 체인코드를 실행하는 Orderer 서버와 체인코드를 초기화하고 실행할 내용을 검증하는 Peer 서버로 구성한다. 여기에 인증과 인가를 담당하는 CA(Certification Authority)서버를 운영하기도 하는데 사용자 및 조직 구성이 운영 환경에서 거의 변동이 없는 경우는 CA 서버를 운영하지 않고 초기에 수동으로 생성한 인증서 정보로만 운영하기도 한다.

하이퍼레저 패브릭의 동작 흐름

1. 위의 그림에서 ‘A’로 명명된 클라이언트 어플리케이션은 체인코드 실행을 위해 Peer에 연결한다. 
2. Peer에 체인코드에 실행할 내용을 전달한다.
3. Peer는 어플리케이션으로 부터 전달받은 트랜잭션에 대해 사전 검증하고 검증 결과를 어플리케이션으로 회신한다.(원장에는 반영하지 않는 시뮬레이션 행위)
4. 어플리케이션은 사전 검증 결과가 이상 없음을 확인하고 트랜잭션을 수행해 달라는 요청을 Orderer에 전송한다.
5. Orderer에서 체인코드를 실행하여 원장을 갱신하고 해당 결과를 회신한다.

투표 시스템을 구현할 때 고려해야 할 사항들

투표 시스템 전체 아키텍처

- 시스템 아키텍처 측면에서)

• 하이퍼레저 패브릭은 허가형 블록체인으로 허가받은 사용자만 접근이 가능하도록 시스템을 구축한다. 따라서 허가 받은 사용자를 하이퍼레저 패브릭으로 전달하는 시스템도 시스템 설계 단계에서 식별이 되어야 하고 허가된 시스템만 블록체인 네트워크에서 통신이 허용되어야 한다.
• 시스템 구성을 위한 통신 정책과 조직 구성
  1. 허가된 시스템 고유정보 식별(IP, 도메인 등)
  2. 방화벽 구성하여 허가된 시스템간 통신만 허용
  3. 허가된 시스템간 통신시 하이퍼레저 패브릭 네트워크의 통신 포트 이외에는 차단
  4. 신규 추가 시스템에 대해서도 동일 정책 적용
  5. 부하 분산을 위한 다중의 Orderer 및 Peer 서버, 메시징 분산처리 솔루션 적용 고려
• 최소 2개 이상의 논리적 조직을 구성하여 1개의 조직은 투표를 위한 원장 쓰기 권한을 부여하고 이외 조직은 투표 상황을 모니터링하고 결과를 조회하기 위한 읽기 권한만 부여해야 한다. (원장에 읽기 권한을 가진 조직은 별도의 통신 채널을 추가 구성하여 투표를 검증하거나 검증 정보를 다른 시스템과 연계해도 무방하나, 원장에 쓰기 권한을 부여받은 조직은 투표를 위한 하나의 채널만 유지해 원장 관리에 대한 일관성을 확보해야 한다.

- 체인코드와 원장관리 측면에서)

• 사용자의 투표 기록 저장 이외에 사용자를 특정하지 않는 범위에서 고유 번호를 채번해 관리할 필요가 있다 for 최종 특표 검증
  1. 투표 행위에 대한 고유 번호 채번 및 저장
  2. 고유 번호는 사전 지정된 서버의 현재 시각과 채번하는 Peer 서버 정보를 조합하여 생성하여 사후 검증시 채번된 번호로 생성된 시각과 채번한 서버를 추적할 수 있도록 설계
  3. 투표 고유 번호의 갯수와 사용자의 투표 기록 총합 비교를 위한 채번 기록 저장 -> 개표때 수 맞추기 위해
  4. 사용자의 투표 기록 저장(사용자를 특정하는 정보는 기록하지 않음)

- 인증관리 측면에서)

• 하이퍼레저 패브릭의 인증 절차와 별도로 투표 시스템 앞단에서 별도로 인증을 구축할 필요가 있다.
• 하이퍼레져 인디를 통해 고유 사용자를 인증하고 인증된 결과를 하이퍼레저 패브릭으로 전달해야 한다.
• 사용자의 인증 결과 값을 하이퍼레저 패브릭의 원장에 저장하여 사용자가 투표 시스템 에 진입하여 인증한 결과도 추가로 같이 저장하여 중복 투표를 방지하기 위한 자료로 활용하도록 구성해야 한다.

Viimpt 가 보완해야 할 점

투표 및 개표 정보를 다수의 조직에 지정된 Peer 서버에서 실시간 조회 및 검증 가능하기 때문에 개표 결과를 투표 이해관계자가 실시간에 가깝게 취득할 수 있다.

-> '투명성과 신뢰성을 확보하면서 투표를 진행할 수 있다.'는 장점이 있지만 대선의 경우 투표가 종료될 때까지 결과를 알 수 없어야 하므로 이를 막는 프로세스가 추가로 필요하다.