More Related Content
What's hot
What's hot (16)
Similar to Hyperledger Tokyo Meetup 22/07/2020
Similar to Hyperledger Tokyo Meetup 22/07/2020 (20)
Hyperledger Tokyo Meetup 22/07/2020
- 1. Hyperledger Communityにおける OSS活動で得たもの 富士通ソフトウェアテクノロジーズ Fujitsu Australia Software Technology 根木 敦史
- 2. 自己紹介 2010 組込Linux時代 2018 ストレージ開発時代 2020 Blockchain時代 主にHyperledger Fabric 2014 Android端末開発時代 Illustration by Stories by Freepik nekia nekia nekia
- 3. Hyperledger Communityでの主な活動 2019年にHyperledger Fabric向けアーカイブ機能を提案 Hyperledger Labsで正式機能化を目指し、 Fabricのコントリビュータと議論しながら活動 2018年からHyperledger Explorerプロジェクトに参加 Hyperledgerの各プラットフォーム向けダッシュボード 現在ではMaintainer（計4名）の1人として活動中 Illustration by Stories by Freepik
- 8. どんな機能を提案したのか ● 古いブロックをレポジトリにアーカイブし各ノードのストレージ消費を抑える ● アーカイブされたデータは引き続き標準のI/Fでシームレスにアクセス可能 Overview of block archiving enabled HL Fabric network
- 9. アーカイブ機能開発に至る経緯 ● 成長し続けるブロックサイズに対し てリソース消費量を抑える仕組み が必要 ● コミュニティも開発初期段階から課 題として提起 [FAB-106] Ledger snapshot and checkpoint - Hyperledger JIRA ● ストレージ容量の少ないデバイス もネットワークに参加可能にするこ とで適用範囲を拡大 source: https://youtu.be/MkCQM-5l-r4 View from the Trenches: Practical Issues In Enterprise Blockchain Implementations and Potential Solutions - Baohua Yang, Oracle
- 10. アーカイブ機能の仕組み Overview of interaction among peer nodes ● Archiver peer：ブロックをRepositoryにアーカ イブし、ステータスを組織内の他ノードに通知 するノード ● Repository：アーカイブしたブロックが格納さ れるノード（Archiver peerが兼務） ● Client peer：通知されるアーカイブステータス に基づきローカルに保持するブロックを削除 するノード ● 各ノードに対して削除済みデータにクエリが発 生した場合、リクエストが Repositoryにリダイ レクトされ、リモートからデータを取得する。 アーカイブ後もユーザはシームレスにデータ アクセス可能
- 11. 新機能採用に向けた活動 5 コ ア コ ン トリ ビ ュ ー タ の 承 認 取 得 HL Fabricの 正 式 機 能 に 晴 れ て 採 用 !! 4 フ ィー ドバ ッ ク に 基 づ く機 能 改 善 開 発 イ テ レ ー シ ョン を 数 サ イ ク ル 回 す 3 コ ア コ ン トリ ビ ュ ー タ と 議 論 メ ー リ ン グ リ ス ト、チ ャ ッ ト、電 話 会 議 で 議 論 。 隔 週 の ContributorM eetingに 参 加 HL Labs 配 下 で Prj始 動 21 HL Labsに プ ロ ジ ェ ク ト申 請 W hite paper作 成 、ス ポ ン サ ー の 確 保 、 Githubへ ソ ー ス 公 開 想定： ４～６ヶ月 現実： 肯定的なフィードバックを得て 幸先良いスタート コミュニティとの議論の中で既存の Fabric実装 との不整合が判明し設計一部見直し クリアにすべき仕様や他コンポーネントとの整合 性の確認等、埋めるべきギャップ多数 承認依頼するレベルに現時点では到達せず ... コミュニティ側でも類似機能開発（ Ledger checkpoint and pruning/archiving）がスタート
- 12. 足りなかったもの 時間 03 ● 急ぐなら単独でリソース投じて推進することも選択肢 としてはあるが、より効率よく、より大きな成果に結び 付けたいならコミュニティと共に推進するのが良い 説得力 02 ● 提案のアプローチがベターなのか判断するための情 報を十分用意できていない ● 別アプローチ、本アプローチの良し悪し比較から、本 アプローチに到達した経緯 等 コミュニケーション 01 ● コミュニティの知恵を活かしきれていない ● より早い段階でコミュニティに入り込むことで様々な角 度からのフィードバックをデザインに反映できたはず コミュニティは常にオープン。相談しながら何度でもトライすればいい ● 今後の予定 ○ Ledger checkpoint機能の開発に参加することでより緊密な関係を構築する ○ コア機能からは独立したユーティリティツールとして実装を見直すことも検討中 ○ kubernetes等のCloud Native環境に特化したアプローチを検討
- 13. 参考: Ledger snapshot and checkpoint (WIP) ● 用途： 新たなPeer（組織）がチャネルに参加した際、ス トレージ消費量を抑える、ブロックデータ同期に 要する時間を短縮するのが目的 ● 指定ブロック番号に到達した時点でチャネルの スナップショットを取る機能 ● どのブロック番号でスナップショットを取得する か、はチャネルに参加する組織間で別途合意 形成する ● 当該チャネルに新規組織もしくは既存の組織に 新規のPeerが参加する場合、取得したスナップ ショットからブロックチェーンを開始
- 15. どんなプロジェクトか ● Hyperledgerのブロックチェーンプラットフォーム向けダッシュボード ● React frontend and a Node/Express backend ● Using fabric-sdk-node to access HL Fabric network ● 以下をサポート ○ Hyperledger Fabric (v1.4.8 LTS, v2.1.1) ○ Hyperledger Iroha (v1.1.1) alpha release
- 16. OSS向けエコシステムのフル活用 ● コミュニティにサポート受けながらモダンな 開発のベストプラクティスを実践 ● 利用するツールの多くが無償利用可能 （OSSであれば） ● 様々なプロセスを自動化し、個人のスキル に依存せず品質を維持できる ● OSSプロジェクトの維持でとても重要。誰が 参加しても（抜けても）プロジェクトの健康状 態への影響を最小化
- 17. ユーザ体験の改善による好循環を生む取組み 機能が改善されることで ユーザ体験が向上し ユーザ数増につながる クイックなユーザ対応と ドキュメントの改善を通じて 導入障壁を下げてユーザ数を増やす コミュニティが活気づき ユーザからのフィードバックや 新たなコントリビュータの獲得に繋がる ユーザとの継続的な コミュニケーションが重要 ● 以下のチャネルを利用 ○ メーリングリスト ○ チャットルーム ○ Stackoverflow ● 徐々にユーザ数を増やす ○ 実運用での利用事例も ○ DockerイメージのPull数が200万突破 ○ 今年のコントリビュータは8名
- 18. プロジェクト運営のガバナンス 四半期毎にTSC*へ プロジェクト状況と プランを報告 @Zoom & Confluence ２週間のスプリント計画をチー ムでシェア @JIRA Pull Request毎に コア開発者による 議論&承認 @Github *TSC: The Technical Steering Committee
- 19. Hyperledger Bootcamp @ 香港, 2019 Hyperledger umbrella
- 20. 個人的に Hyperledger Community は... と思う
- 21. QA