FLoBC: A Decentralized Blockchain-Based Federated Learning Framework

시작 하기에 앞서 논문 소개는 단락별 요약으로 진행할 예정입니다.
원문 필요시, 아래 링크로 접근 하시면 됩니다.

FLoBC: A Decentralized Blockchain-Based Federated Learning Framework

초록

• 데이터의 급속한 확장으로 광범위한 규모의 기계학습을 위한 분산 솔루션 필요
• 모든 ML모델이 학습 가능한 FLoBC 솔루션 제안 및 구현(블록체인 기반 연합학습 시스템)
• Trainer와 Validator로 구성된 시스템 설계/ 학습 방법론 제시

1. Introduction

• 연합학습은 각각의 로컬 데이터를 사용하여 서로 다른 노드와 협업, 모델 업데이트를 공유하여 훈련된 단일 모델 실현.
• 연합학습은 단일기계의 데이터 부족을 해결
• 블록체인(BC)을 이용한 연합학습(FL) 시스템을 구축하기 위한 FLoBC 제안
  • 개인 정보보호, 효율성, BFT에 대한 솔루션 제시

2. 연구의 배경

• BC는 탈중앙화 실현을 목표로 하는 기술
• FL과 BC는 탈중앙화를 실현한다는 입장에서 잠재적인 장점(상호 보완적)이 보임.
• 이전의 BC + FL 연구
  • 공통 핵심 목표
    • 중앙서버가 데이터 수집 x
    • 네트워크 전체에 계산 분산(최소한의 계산)
  • 훈련 노드가 시스템 모든 노드와 업데이트를 공유하여 $O(n^2)$의 통신 비용이 발생 하는 문제 를 해결하고자 함(FL 개념에서 생기는 문제)
    • 통신 비용을 줄이고자 링, 토폴로지, 트리 토폴로지, 그래프 토폴로지 이용
    • 전체에게 코델을 공유하는게 아닌 일부끼리만 모델 전달
    • 수렴속도가 늦어지는 문제 발생
  • 분산형 통신 인프라 BC 연구
    • 노드가 로컬 교육 후 글로벌 체인에 추가하기 위해 컨센서스(Validator 역할)에 전달 하는 연구 케이스
    • 훈련노드에 검증자가 할당/ 노드의 학습을 작업증명 후 보상을 주는 연구
    • Trainer가 Validator에 업데이트를 보내며 보상은 모델 소유자가 제공하는 연구

3. 방법론

• 시스템 설계에 기반에 되는 표준
  • Generality : 모든 모델에 적용 가능함
  • Decenralization : 탈중앙화된 합의 이용
  • No data sharing : 데이터 공유 없음
• 솔루션의 목표
  • 지도학습 관점에서 시스템 성능과 관련된 문제를 다룸
  • 병렬, 중앙집중화, 동기화에 대한 논의

3.A 병렬

ML은 학습이 무겁다는 것이 가장 문제
병렬성에 대한 두가지 패러다임 제시

• 1) 모델 병렬
  • 구조적 병렬 제공
  • Split Learning
  • 컷 레이어를 통한 레이어 분할
    • 장점 : 개인 정보 보호 및 낮은 컴퓨팅 파워를 가진 기기도 학습 참여 가능
    • 단점 : 모델에 따른 컷레이어 변경등의 이슈로 범용시스템에 활용이 어려움
• 2) 데이터 병렬성
  • 데이터를 나눠서 학습
  • 장점 : SGD 같은 방법으로 학습 처리 가 우수, 쉽게 일반화 가능

3.B 중앙 집중화 정도

• 중앙 집중식 : end to end 중앙 서버가 처리
• 고전 FL : 중앙서버 클러스터를 이용
• BC + FL : 중앙 서버 x / Traniner + Validator로 구성
  • Train 결과물이 업데이트 허용 되는지 Validator의 투표로 결정(Validator dataset 이용)
    • Validator의 2/3이상 허용 (비잔틴)
    • Correlate 한 데이터 이용
  • 실험에는 FedAvg 이용 예정

3.C 동기화

• 동기화 되지 않은 변수들로인해 성능 저항이 발생
• 동기화 방법 소개
• 1) BSP(Bulk Synchronous Parallel)
  • 라운드와 통신을 번갈아가며 학습
  • 장점 : 간단함/ 일관성/ 빠른 수렴 성능
  • 단점 : 모든 작업자가 끝날때까지 기다려야함(병목성) / 정해진 학습 라운드 이후 학습 x
• 2) SSP(Stale Synchronous Parallel)
  • BSP에 대한 절충안
  • 특정 시간에 도달하면 모든 작업자가 학습 중지
  • 목표 학습라운드에 도달했음에도 시간이 남았다면 추가 훈련
• 3) BAP(Barrierless Asynchronous Parrallel)
  • 노드 간 비동기 통신
  • 완전한 탈중앙화
  • 수렴 시간 지연/ 부정확한 수렴
  • 주기적인 학습 모델 공유
• 4) ASP(Approximate Synchronos Parallel)
  • 앙상블 러닝 느낌
  • 매개변수 제한
  • 동기화 비용 절약을 위해 업데이트 무시
  • 구현이 복잡하여 지원 X

3.D BFT

• 악의적인 학습을 막기 위함.
  • 악의적인 학습 : 학습을 제공하지 않거나, 잘못된 데이터 제공
• 신뢰점수라는 패널티 정책 제공. 신뢰점수는 학습의 가중치로 이용
  • 신뢰점수는 합이 1이기 때문에 상대적 경쟁성 제공

4.구조

4.A 시스템 구성

FLoBC는 Trainer와 Validator로 구성. Vlidator가 더 높은 책임

• 1) 블록체인 서비스
  • Validator node에서 통신 및 데이터 저장의 패브릭 구성
  • 탈중앙화를 위한 스키마 사용 투표/선거 기반 PBFT
• 2) 스토리지 스키마
  • 블록체인 정보가 저장된 로컬 스토리즈를 액세스 /수정 용이하게함
• 3) 머신러닝 서비스
  • 블록체인 위에 머신러닝 레이어 표시
  • 그레디언트 공유와 같은 머신러닝 트렌젝션 실행 서비스 구축
• 4) 훈련 검증
  • BC 와 Traniner의 하이브리드 계층
  • Gradient의 유효성 검증(Pass or no)
• 5) 평판 관리
  • 비잔틴 투표를 통한 악의적인 학습자 퇴출
• 6) 모델 훈련
  • fedavg된 모델과 그라디언트를 주고 받음
• 7) Traing flow management
  • 유효성 훈련 관리 및 동기화

4.B 구현 기술

• pBFT 합의 알고리즘을 이용하는 Exonum 블록체인 위에 구축
  • 일반적인 PoW보다 훨씬 가법기 때문에 채택
• 대부분의 시스템은 rust로 구현
• lightweight 클라이언트는 javascript
• train/validate는 python + tensorflow

4.C 시스템 뷰

4.C.1 Actor 뷰

• 가장 높은 수준의 뷰
  • Validator는 서로 모두 연결 되어 있지만, Trainer는 아님
  • Validator, Trainer의 역할은 고정 된게 아님. 동일한 목적을 가지는 학습에서 두 역할이 모두 가질수는 없지만, 다른 일을 겸업 가능
    

4.C.2 모듈/서비스 뷰

• 모듈 뷰
  • Trainer는 Http를 통해 Validtor와 통신
    
• 서비스 뷰
  • 시스템 전반의 일들을 여러 서비스로 분리
    • Storage Schema는 Validator 서비스의 중심/ Trainer 통합/ 동기화
    • Validation Service는 Trainer 평가
    • Wire api는 블록체인 인터페이스 외에 보조쿼리제공( 최신 모델 가져오기)
      

결과

• MNIST 기준

  • decentralized vs centralized
    * 비슷한 성능
    

  • Trainer / Validater

    • 3 validator 7 rainer 26iter에서 0.9874 성능
      

  • 비잔틴 투표에 의한 학습 누락 과정
    * 트레이닝 라운드에 따라 탈락하는 Trainer발생
    

  • 학습 전략에 따른 성능