Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
webエンジニア向けブロックチェーンの技術的「へぇ」 / Blockchain tech ...
Search
hitsuji-haneta
January 16, 2019
Technology
0
160
webエンジニア向けブロックチェーンの技術的「へぇ」 / Blockchain tech tips for web developers
hitsuji-haneta
January 16, 2019
Tweet
Share
More Decks by hitsuji-haneta
See All by hitsuji-haneta
SSIで覗き見るPWAの世界 / SSI on PWA
hitsuji_haneta
2
1.1k
GoとMicroserviceでDDDやってみました
hitsuji_haneta
0
380
やってみたよVueNative
hitsuji_haneta
2
470
これもフロントエンド!画面つきスピーカーで遊んでみた
hitsuji_haneta
0
100
VueではじめるWeb Components
hitsuji_haneta
1
550
Other Decks in Technology
See All in Technology
Four Keysから始める信頼性の改善 - SRE NEXT 2025
ozakikota
0
410
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
120
スタックチャン家庭用アシスタントへの道
kanekoh
0
120
本当にわかりやすいAIエージェント入門
segavvy
1
340
Delegating the chores of authenticating users to Keycloak
ahus1
0
190
CDK Vibe Coding Fes
tomoki10
1
630
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
730
ClaudeCode_vs_GeminiCLI_Terraformで比較してみた
tkikuchi
1
1k
VS CodeとGitHub Copilotで爆速開発!アップデートの波に乗るおさらい会 / Rapid Development with VS Code and GitHub Copilot: Catch the Latest Wave
yamachu
3
460
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
110
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
190
Digitization部 紹介資料
sansan33
PRO
1
4.5k
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
96
6.1k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
700
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
BBQ
matthewcrist
89
9.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Designing Experiences People Love
moore
142
24k
Building Applications with DynamoDB
mza
95
6.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Transcript
XFCエンジニア 向け ブロックチェーンの技術的 へぇ 髙橋翔太 thinkShake製作所 2019/1/16 @wack hack sendai
XIZ 最近ブロックチェーンの勉強を始めたが 「?」と思うことが多かった 一般向けな入門記事は多いが 技術的な入門記事はあまりない
(0"- webエンジニアの方が 「コード書いたことないけど、 中身はだいたいイメージできるよ」 という状態になることを目指す
લఏࣝ 3)公開鍵暗号について知っている 2)ハッシュ化について知っている 1)クライアントサーバ知っている 公開鍵:みんな見れる 秘密鍵:自分しか知らない 公開鍵で暗号化したら秘密鍵で複合 秘密鍵で暗号化したら公開鍵で複合 元のデータを規則性のないハッシュ値(16進数)を作る 同じデータからは同じハッシュ値が生成されるが、
変換後のハッシュ値からは元のデータを復元できない
ϒϩοΫνΣʔϯͱʁ ヘッダー 取引データ 取引データ ヘッダー 取引データ 取引データ ヘッダー 取引データ 取引データ
複数の取引データをブロックという単位で ひとかたまりにして、どんどん繋げていく ·ͣ؆୯ʹ
ϒϩοΫνΣʔϯͱʁ Client - Server Peer to Peer (P2P) ·ͣ؆୯ʹ 中央サーバーがなく、全てのノードで情報を共有
ϒϩοΫνΣʔϯͱʁ ·ͣ؆୯ʹ 改ざんや不正がむずい 1)みんながデータを持っているから ▶「中央サーバーのデータを改ざんしたら成功」ではない 2)過去の取引も全てチェーンで繋がっているから ▶ 全ての過去データを改ざんしないと整合性がとれない
͢ίτ 伝えておきたい 混乱ポイント どういう形式で データを 持ってるの? どうやって データを 保証しているの?
͢ίτ 伝えておきたい 混乱ポイント どういう形式で データを 持ってるの? どうやって データを 保証しているの?
ࠞཚϙΠϯτ 一口にブロックチェーンと言っても 色んなプラットフォームがあり 結構中身が違う 共通する仕様とプラットフォーム独自の仕様を 区別して理解することが重要!
දతͳ̎ͭ
දతͳ̎ͭ BitCoin - サトシ・ナカモト氏が考案 - 仮想通貨の先駆け - UTXOベース - PoW
後述
දతͳ̎ͭ Ethereum - Vitalik Buterin氏が考案 - スマートコントラクト の先駆け (プログラムが実行できる)
- アカウントベース - PoW(PoSに移行予定) 後述
伝えておきたい 混乱ポイント どういう形式で データを 持ってるの? どうやって データを 保証しているの?
σʔλͷอূ 1)過去のブロックを改ざんできない仕組み 2)不正なブロックを追加できない仕組み ▶ ブロックハッシュ ▶ コンセンサスアルゴリズム
ϒϩοΫϋογϡ ヘッダー 取引データ 取引データ ヘッダー 取引データ 取引データ ヘッダー 取引データ 取引データ
ハッシュ化 5eb127… 5eb127… 66f3a2… 66f3a2… 直前のブロックをハッシュ化しヘッダーに保有
ヘッダー 偽データ 取引データ ヘッダー 取引データ 取引データ ヘッダー 取引データ 取引データ ハッシュ化
3f1a58… 5eb127… 66f3a2… 66f3a2… 過去データを改ざんするとハッシュ値が変わり 後続のブロックと繋がらなくなる ϒϩοΫϋογϡ
ίϯηϯαεΞϧΰϦζϜ 条件を満たした(合意がとれた)ブロックのみを チェーンに追加する仕組み PoW PoS PoI DPoS PoC いろいろな種類がある 不正ブロック追加にコストがかかるため
不正が見合わなくなる
1SPPGPG8PSL 新しいブロックを作る際、ブロックハッシュが規定 値以下でないとチェーンに追加できない ヘッダー 取引データ nonce: 3 66f3a2… 取引データ >
000100… 既定値 00003f… < 000100… ▶「nonce」という値を変えてブロック化しまくる (=マイニング) ヘッダー 取引データ nonce: 5 計算コスト(時間、電気代)がかかるので 不正が見合わない
1SPPGPG4UBLF ・ブロックの承認者が承認しなければチェーンに追加できない ・承認者は都度ランダムに決定される ・コインの保有量が大きいほど承認者に選ばれやすくなる 不正をするにはコインの保有が必要& コインの信用がなくなると価値が下がるため 不正が見合わない 追加OK!!
伝えておきたい 混乱ポイント どういう形式で データを 持ってるの? どうやって データを 保証しているの?
σʔλͷߏ UTXOベース アカウントベース お金を中心 とした考え方 (現金に近い) 人を中心 とした考え方 (銀行口座に近い)
ΞΧϯτϕʔε 人(アカウント※)が状態を持ち、所持金は状態の一つ 主:アカウント 従:お金 ID:Bさん 所持金:20コイン ※Ethereumではプログラム(コントラクト)もアカウントとして存在している ▶ コントラクトがお金を預かり、条件成立時に送金することが可能 webエンジニア的には「普通」 ID:Aさん
所持金:27コイン ID:コントラクトC 所持金:42コイン
6590ϕʔε お金(UTXO)が状態を持ち、人(アドレス)は状態の一つ 主:お金 従:人 ID:1 金額:20コイン 持ち主:Aさん ID:2 金額:7コイン 持ち主:Aさん ID:3
金額:20コイン 持ち主:Bさん 20コイン 7コイン 合計:27コイン 持ち主ごとにお金を合算することで所持金がわかる
UTXOとは? unspent transaction output ະ༻ͷτϥϯβΫγϣϯग़ྗ Aさん Bさん Cさん 10コイン 8コイン
おつり2コイン (例) 取引1 取引2 金額:10コイン 持ち主:Aさん *OQVU 0VUQVU 金額:10コイン 持ち主:Bさん 取引1 金額:10コイン 持ち主:Bさん *OQVU 0VUQVU 金額:8コイン 持ち主:Cさん 取引2 金額:2コイン 持ち主:Bさん 使用済 未使用 未使用 6590ϕʔε
ブロックチェーンって全てのデータを 公開してるんでしょ? ならアカウントとかUTXOとかを 他人でも操作できちゃう? そこで公開鍵暗号 ですよ! ٙ
ެ։ݤ҉߸ 公開鍵 秘密鍵 アドレス (IDのようなもの) 誰でも見れるが 秘密鍵がないと 使えない 自分の秘密鍵であけて… 送金先の公開鍵でロック
秘密鍵がないと 操作できない お金を送れるようになる
これって全部のノードが トランザクションとかアカウントの データ持ってんの? いいえ!! ٙ
.FSLMF5SFF Merkle Root Hash01 Hash23 Hash2 Hash3 確認したい データ ※1
UTXOベースならトランザクション、 アカウントベースなら各アカウント の状態 ※2 ノードにも種類がある。 フルノード:全てのブロックを保有 軽量ノード:一部のブロックのみ Hash0 Hash2 Data0 Data1 Data2 この辺のデータは別にいらない 各データ(※1)のハッシュ値を 全て足し合わせたMerkle Rootが ブロックヘッダーに含まれている 他のノードに もらう(※2) ブロックヘッダー&他ノードとの通信で 確認できるため、全部のデータを持つ必要はない
·ͱΊ ブロックチェーンは奥が深い…
͋Γ͕ͱ͏͍͟͝·ͨ͠ 一緒にブロックチェーンの勉強しましょう!