KuCoin Exchange Japanese

22 августа 2024 16:56

これ、一応ワンチャンあるんで参加登録するのは面白そう
国外の人は登録しない気がする？

KuCoin Exchange Japanese

22 августа 2024 16:38

❤️

KuCoin Exchange Japanese

22 августа 2024 15:54

🔔イベント期間： 2024/8/22 10:00:01 – 2024/8/26 10:00:01 （UTC）

上の「参加する」をクリックして、このキャンペーンに登録しましょう！日本のプロトレーダーの皆様には、$50,000のトレーディングプライズプールから賞金が当たるチャンスがあります！トップ3のトレーダーには、東京でのプライベートミートアップへの招待状も贈られます！

KuCoin Exchange Japanese

22 августа 2024 15:28

ありがとうございました！
レイヤー２奥が深い！

KuCoin Exchange Japanese

22 августа 2024 15:28

次回もここを引き続き勉強します！！！！！！

KuCoin Exchange Japanese

22 августа 2024 15:24

データ可用性問題とは？
ブロックチェーンにおけるデータ可用性問題とは、ブロックチェーンの取引履歴や状態を構成するデータが、ネットワークの参加者からアクセスできなくなるリスクのことです。
なぜデータ可用性が重要か？
ブロックチェーンは、分散型システムであるため、特定の中央集権的な管理者を必要としません。その代わり、ネットワーク上の多数の参加者がデータを保持し、相互に検証し合うことで、システム全体の整合性と信頼性を維持しています。
もし、ブロックチェーンのデータが一部の参加者からアクセスできなくなると、
取引の検証: 新しいトランザクションが過去のトランザクションと矛盾していないか検証できなくなり、ブロックチェーンの整合性が保てなくなります。
状態の更新: ブロックチェーンの状態（例：各アカウントの残高）を正しく更新できなくなり、システム全体が機能不全に陥ります。
セキュリティの低下: 攻撃者が意図的にデータを隠蔽することで、不正を隠したり、システムを混乱させたりすることが可能になります。
データ可用性問題が発生するケース
ネットワークの分断: 大規模なネットワーク障害や意図的な攻撃などにより、ネットワークが分断され、一部のノードが最新データにアクセスできなくなる。
データの消失: ハードウェアの故障や人的ミスなどにより、一部のノードがデータを失ってしまう。
意図的な隠蔽: 悪意のあるアクターが、報酬を得るため、あるいはシステムを攻撃するために、意図的にデータを隠蔽する。
データ可用性問題への対策
データの冗長化: 複数のノードにデータを複製して保持することで、一部ノードでデータが失われても、他のノードから復元できるようにする。
データ可用性証明: データが実際にネットワーク上で利用可能であることを証明する仕組みを導入する。例えば、Erasure Codingなどの技術を用いることで、データの一部が失われても復元できるようにする。
インセンティブ設計: ノードがデータを誠実に保持し、提供することを促すようなインセンティブ設計を行う。
まとめ
データ可用性問題は、ブロックチェーンの安全性と信頼性を揺るがす重要な問題です。
そのため、多くのブロックチェーンプロジェクトでは、様々な対策を講じることで、データ可用性問題のリスクを最小限に抑える努力をしています。
特に、スケーラビリティの向上を目指したレイヤー2ソリューションなどでは、データ可用性問題への対応がより重要となります。

KuCoin Exchange Japanese

22 августа 2024 15:21

espressoを採用してたらオフラインはダメだね！

KuCoin Exchange Japanese

22 августа 2024 15:19

なるほど、面白い視点ですね！ あなた専用のブロックチェーンのような、非常に小規模で限定された環境であれば、理論上はオフラインでのロールアップも不可能ではありません。
この場合、以下のような条件を満たせば、現実的に機能する可能性があります。
信頼できる環境: あなたが単独で管理し、外部からの干渉を受けない、完全に信頼できる環境であること。
限定的な規模: トランザクション数やデータ量が限られており、オフライン環境でも処理・保存が可能であること。
簡素化された仕組み: データ可用性やセキュリティに関する要件を緩和し、シンプルな仕組みで運用できること。
例えば、あなた個人の支出を記録するだけの、非常にシンプルなロールアップであれば、オフラインでも実現できるかもしれません。この場合、データの整合性やセキュリティは、あなた自身が責任を持って管理することになります。
しかし、それでも考慮すべき点があります
単一障害点: あなたの管理する環境に問題が発生した場合、システム全体が停止するリスクがあります。
拡張性の限界: 将来的に規模を拡大したり、他の参加者を加えたりすることが難しくなります。
外部との連携: 他のブロックチェーンやシステムとの連携が難しく、孤立した環境になってしまいます。
まとめ
あなた専用のブロックチェーンのように、極めて限定された環境であれば、オフラインでのロールアップも不可能ではありません。
しかし、信頼性、規模、機能などの面で大きな制約があり、一般的なロールアップの代替となるものではありません。あくまで、特定のユースケースに限定された、特殊なソリューションと言えるでしょう。

KuCoin Exchange Japanese

22 августа 2024 15:17

ＤＡを何でしてるかによっても変わると思うけど

KuCoin Exchange Japanese

22 августа 2024 15:17

鋭い指摘ですね！ 確かに、最終結果だけをL1に書き込めば良いという考え方であれば、理論上はオフラインでのロールアップも不可能ではありません。
しかし、現実的にはいくつかの大きな課題が存在します。
1. データ可用性の保証
ロールアップの安全性を担保するためには、トランザクションデータの可用性を保証する必要があります。
オフライン環境では、このデータがどこかに保管され、必要な時にアクセスできる状態を維持しなければなりません。
しかし、誰がどのようにデータを保管し、その整合性をどのように保証するのか、という課題が arise します。
また、悪意のあるアクターがデータを改ざんしたり、隠蔽したりする可能性も考慮する必要があります。
2. 計算の正当性検証
オフライン環境で計算された最終結果が正しいことを、L1がどのように検証するかが問題となります。
単純に結果だけを書き込むことを許してしまうと、不正な計算結果をL1に書き込むことが容易になってしまいます。
検証コストを抑えつつ、不正を防ぐための効率的な仕組みが必要となります。
3. 参加者間の合意形成
オフライン環境では、参加者間での情報伝達や合意形成が困難になります。
いつ計算を開始し、誰が参加し、どのように結果をまとめるのか、といったプロセスを明確に定義し、参加者間で合意する必要があります。
しかし、通信が制限されるオフライン環境では、この合意形成が非常に難しいものとなります。
これらの課題を解決するためには、複雑なメカニズムや追加のインフラストラクチャが必要となり、現状の技術では実現が困難です。
まとめ
最終結果だけをL1に書き込むというアイデアは興味深いですが、オフライン環境でのデータ可用性、計算の正当性検証、合意形成などの課題を克服することが不可欠です。現時点では、ロールアップはオンライン環境を前提とした技術と言えます。

KuCoin Exchange Japanese

22 августа 2024 15:15

HotShotを含むロールアップ（Optimistic Rollupのようなタイプ）は、オフラインでは成り立ちません。 理由は、ロールアップがその仕組み上、常にメインチェーン（L1）と接続している必要があるからです。
オフライン環境では、以下の理由により、ロールアップは機能しません。
状態の更新と検証: ロールアップは、トランザクションデータを圧縮してメインチェーンに記録し、そのデータに基づいて状態を更新・検証します。オフラインでは、メインチェーンとの通信が途絶えるため、状態の更新や検証が不可能になります。
セキュリティの担保: ロールアップのセキュリティは、最終的にはメインチェーンに依存しています。不正が行われた場合でも、メインチェーンに異議を申し立てることで、不正を無効化し、安全性を確保します。オフラインでは、メインチェーンにアクセスできないため、このセキュリティメカニズムが機能しません。
データの可用性: ロールアップは、トランザクションデータの可用性を保証する必要があります。HotShotのようなファイナリティガジェットも、データがネットワーク上で共有されていることを前提としています。オフラインでは、このデータ可用性が保証されず、システム全体が機能不全に陥ります。
例：オンラインゲーム
ロールアップをオンラインゲームに例えてみましょう。
メインチェーン（L1）: ゲームのサーバー
ロールアップ: プレイヤーのゲーム機
プレイヤーは、自分のゲーム機でゲームをプレイし、その情報はサーバーに送信されます。サーバーは、すべてのプレイヤーの情報に基づいてゲームの状態を管理し、不正がないか監視しています。
もしゲーム機がオフラインになったら、
サーバーとの通信ができなくなり、ゲームの進行状況やアイテム情報が反映されなくなります。
不正行為をしても、サーバーに報告されず、ペナルティを受けることもありません。
他のプレイヤーと協力プレイ もできなくなります。
このように、ロールアップは、メインチェーンという「サーバー」との接続が不可欠であり、オフラインでは成り立ちません。

KuCoin Exchange Japanese

22 августа 2024 15:15

HotShotのようなファイナリティガジェットは、オフラインでは成り立ちません。
HotShotは、ブロックチェーンネットワーク上で動作し、そのセキュリティと信頼性は、ネットワーク参加者の多数決によって保証されています。オフライン環境では、
ネットワーク参加者の合意形成 が行えない
ブロックの正当性検証 ができない
データ可用性の保証 ができない
ため、HotShotの機能を果たすことができません。
例：裁判所の判決
再び、裁判所の例えで考えてみましょう。
裁判所がオフライン、つまり外部との通信が遮断された状態では、
他の裁判官との協議 ができない
証拠の確認 ができない
判決文の公開 ができない
ため、判決を確定することができません。
HotShotも同様に、ブロックチェーンネットワークという「オンラインの場」 が不可欠なのです。
まとめ
HotShotは、オンラインのブロックチェーンネットワーク上で動作することで、高速かつ安全なファイナリティを提供します。オフライン環境では、その機能を果たすことはできません。

KuCoin Exchange Japanese

22 августа 2024 15:14

な気がするけどな、クレジットとかそうじゃん

KuCoin Exchange Japanese

22 августа 2024 15:12

トランザクションの実行を伴わないって
オフラインでも使えるって事かな🤔

KuCoin Exchange Japanese

22 августа 2024 15:09

実行を伴わないファイナリティガジェット：HotShotの仕組み
Espressoのファイナリティガジェット「HotShot」が「実行を伴わない」というのは、ブロック内のトランザクションを実際に実行せずに、正当性を検証することを意味します。
従来のPoSとの違い
従来のPoS: ブロックの正当性を検証するために、バリデーターと呼ばれるノードがブロック内のトランザクションを実際に実行します。
HotShot: トランザクションの実行は行わず、暗号技術を用いてブロックの正当性を証明します。
例え：レストランの領収書
レストランで食事をしたとします。
従来のPoS: 領収書の金額が正しいか確認するため、店員が注文内容と値段を一つ一つ確認します。
HotShot: 店員は注文内容を確認しません。代わりに、領収書に印字された特別なQRコードを読み取り、それがお店のシステムと一致するかを確認します。
HotShotでは、トランザクションの実行結果ではなく、ブロック生成過程の正当性を検証します。そのため、トランザクションの実行処理が不要となり、高速かつ軽量なファイナリティを実現できます。
メリット
高速なファイナリティ: トランザクション実行が不要なため、従来のPoSよりも高速にブロックを確定できます。
軽量な処理: バリデーターはトランザクションを実行する必要がないため、リソース消費を抑えられます。
スケーラビリティ向上: トランザクション実行が不要なため、処理能力のボトルネックが解消され、スケーラビリティが向上します。
まとめ
HotShotは、「実行を伴わない」という革新的なアプローチを採用することで、従来のPoSの課題であった速度とスケーラビリティの問題を解決しました。これにより、より高速で安全なrollupの実現に貢献しています。

KuCoin Exchange Japanese

22 августа 2024 16:52

Hey!😎

KuCoin Exchange Japanese

22 августа 2024 16:29

🕺🕺🕺

KuCoin Exchange Japanese

22 августа 2024 15:38

いやほんとに奥が深い…！
みんなも詳しい！

KuCoin Exchange Japanese

22 августа 2024 15:28

めちゃ勉強なるねほんと毎度、ありがとうございます！

KuCoin Exchange Japanese

22 августа 2024 15:25

ブロックチェーンにおけるデータ可用性問題：具体的な例
データ可用性問題が、実際にどのように起こりうるのか、具体的なブロックチェーンの例を挙げながら説明します。
例1：Bitcoinにおける51%攻撃
Bitcoinでは、悪意のあるマイナー集団がネットワークのハッシュレートの過半数を占拠してしまう「51%攻撃」によって、データ可用性問題が引き起こされる可能性があります。
攻撃者のブロック生成: 攻撃者は、自身の管理下にあるノードだけで構成されたブロックチェーンの分岐を作り、そこでトランザクションを処理します。
データの隠蔽: 攻撃者は、この分岐を他のノードに公開せず、秘密裏にトランザクションを処理し続けます。
攻撃者のブロックチェーンが優勢に: 攻撃者は、十分なハッシュパワーを使って、自身のブロックチェーンをより長く成長させます。
二重支払い: 攻撃者は、自身のブロックチェーンが優勢になった時点で、本来使用できないはずのBitcoinを使って二重支払いを行います。
データ可用性問題発生: 攻撃者が生成したブロックには、他のノードがアクセスできないため、二重支払いの事実を検証できず、データ可用性問題が発生します。
Bitcoinの場合、51%攻撃は非常に困難ですが、ハッシュレートの集中が進むと、リスクが高まる可能性があります。
例2：Ethereumにおける状態データの膨張
Ethereumでは、スマートコントラクトの実行状態を記録する「状態データ」が、年々増大しています。
状態データの増大: DeFiやNFTなどのアプリケーションの利用が増えるにつれて、状態データが肥大化し、全てのノードがデータを保持することが困難になります。
軽量ノードの増加: 状態データの保存容量が限られる「軽量ノード」が増加します。軽量ノードは、必要なデータのみを他のノードから取得して検証します。
データの欠落: 悪意のあるノードが、軽量ノードが必要とする状態データを提供しなかったり、改ざんしたデータを提供したりする可能性があります。
データ可用性問題発生: 軽量ノードは、完全なデータにアクセスできないため、トランザクションや状態遷移の正当性を検証できず、データ可用性問題が発生します。
Ethereumでは、この問題に対処するため、状態データを効率的に管理・検証する仕組みや、データ可用性を向上させるための技術開発が進められています。
まとめ
データ可用性問題は、ブロックチェーンの設計や運用、外部環境など、様々な要因によって引き起こされる可能性があります。
そのため、各ブロックチェーンプロジェクトでは、それぞれの特性に合わせた対策を講じることで、データ可用性問題のリスクを最小限に抑える努力をしています。

KuCoin Exchange Japanese

22 августа 2024 15:22

espressoの中での話とちょっと違う！　ありがと🍑

KuCoin Exchange Japanese

22 августа 2024 15:20

あ～でもそうかL2がDA色々採用してるから、若干意味のニュアンスが違うのも分かる

KuCoin Exchange Japanese

22 августа 2024 15:19

L2をコピー不可にしたら
L1でトランザクション使って
L2でオフライン環境出来ないかな

KuCoin Exchange Japanese

22 августа 2024 15:17

ＤＡをＬ１（ＥＴＨ）で使ってる場合はオフラインはだめだよね

KuCoin Exchange Japanese

22 августа 2024 15:16

L1はオンラインで
L2はオフラインみたいな

KuCoin Exchange Japanese

22 августа 2024 15:15

ホットショットの場合はオフライン、ダメなんだね

KuCoin Exchange Japanese

22 августа 2024 15:14

今後そのオフラインでも使えるのが増えてくる気がします

KuCoin Exchange Japanese

22 августа 2024 15:13

ロールアップと絡めてるからオフラインってことかなとかも思ったけど

KuCoin Exchange Japanese

22 августа 2024 15:12

実行を伴わないファイナリティガジェット：HotShotのデメリット
革新的なファイナリティガジェットであるHotShotですが、「実行を伴わない」という特性によって、いくつかのデメリットも存在します。
1. データ可用性問題への対応の難しさ
HotShotは、ブロックの正当性検証にトランザクションの実行を用いないため、データ可用性問題への対応がより複雑になります。
データ可用性問題: ブロックに含まれるトランザクションデータが、ネットワークの一部ノードからアクセスできなくなる問題。
従来のPoSでは、バリデーターがトランザクションを実行するため、データ可用性を暗に保証しています。一方、HotShotでは、別の仕組みでデータ可用性を保証する必要があるため、システムの複雑化や追加コストが発生する可能性があります。
2. 実行結果に依存した機能の実装が難しい
HotShot単体では、トランザクションの実行結果に依存した機能の実装が困難です。
例えば、「スマートコントラクトの状態変化」や「イベントログ」といった情報は、トランザクションの実行結果から得られます。HotShotでは、これらの情報を直接扱うことができません。
ただし、Espressoでは、HotShotとは別にrollupがトランザクションを実行する仕組みを持っているため、これらの機能を実現することは可能です。
3. 新しい技術への依存
HotShotは、従来のPoSとは異なる新しい技術であるため、まだ発展途上の技術と言えます。そのため、
予期せぬ脆弱性 が発見される可能性
効率性や安全性の面で改善の余地 が残っている可能性
などが考えられます。
まとめ
HotShotは、高速性とスケーラビリティのメリットがある一方で、データ可用性問題への対応や、実行結果に依存した機能の実装などが課題として挙げられます。
これらのデメリットを克服するために、Espressoでは、HotShotとrollupのトランザクション実行を組み合わせることで、安全性と効率性を両立させています。また、HotShot自体も継続的に研究開発が進められており、今後の発展が期待されます。

KuCoin Exchange Japanese

22 августа 2024 15:05

Espressoにおけるファイナリティガジェットとは？
Espressoのファイナリティガジェット「HotShot」は、rollupのブロックのファイナリティ（確定性）を保証する仕組みです。従来のプルーフ・オブ・ステーク（PoS）とは異なり、実行を伴わない点が特徴です。
分かりやすく例えると…
例えるなら、裁判所の「判決確定」のようなものです。
裁判所 = HotShot
判決 = rollupのブロック
確定 = ファイナリティ
裁判所は、証拠などを元に審議し、判決を下します。一度確定した判決は覆すことができません。
HotShotは、シーケンサーが提案したrollupのブロックが正当であるかを検証し、「確定」させます。一度確定したブロックは、後から変更したり、順番を変えたりすることはできません。
ファイナリティガジェットの役割
シーケンサーの決定と周知: 特定のシーケンスタイムスロットに誰がブロック生成権を得たかを確定し、ネットワーク全体に周知します。
ブロックフォークの防止: シーケンサーが正当に生成したブロックが、フォークによって無効になることを防ぎます。
シーケンサー交代の円滑化: シーケンスタイムスロットが切り替わる際、新しいシーケンサーが最新の確定済みブロックに基づいてブロック生成できるようにします。
高速なブリッジの実現: ユーザーやアプリケーションは、複数のrollupの最新状態に対する強い事前確認を得ることができ、rollup間の高速なブリッジを促進します。
メリット
高速なファイナリティ: 従来のPoSと比べて、より高速にブロックを確定できます。
軽量な処理: 実行を伴わないため、リソース消費を抑えられます。
安全性向上: ブロックの確定性を保証することで、rollupの安全性を向上させます。
まとめ
ファイナリティガジェットは、Espressoの安全性と効率性を支える重要な要素です。高速かつ安全なrollupの実現に大きく貢献しています。