# Eth2.0, cosmos, polkadot などまとめ ###### tags: `Research` # Ethreum 2.0 ## 設計 Eth2.0 では以下の図のように二つのチェーンに種類が分かれる。 BeaconChain(ビーコンチェーン)とShardChain(シャードチェーン)である。 イメージとしてはスマートコントラクトの実行などstateの更新を行うユーザーが直接目に触れるチェーン群(ShardChain)と、その複数からなるチェーン群をまとめ管理するチェーン(BeaconChain)である。 ![https://docs.google.com/presentation/d/1G5UZdEL71XAkU5B2v-TC3lmGaRIu2P6QSeF8m3wg6MU/edit#slide=id.g3c326bb661_0_58](https://i.imgur.com/z2p71UO.png) 参考: [What you can do forEthereum 2.0 a.k.a. sharding, Q2 2018 ](https://docs.google.com/presentation/d/1G5UZdEL71XAkU5B2v-TC3lmGaRIu2P6QSeF8m3wg6MU/edit#slide=id.g3c326bb661_0_58) ### BeaconChain  BeaconChainはネットワークの維持・ブロック生成(PoS)・ShardChainの管理など、システム維持をする役割を持つ。一方で、アカウント管理やスマートコントラクトの実行などstateの更新は行わない。また乱数生成によってバリデーターを各Shardに割り当て、管理する役割もあり、Shardにて更新されたstateのMerlke root を保持し、Merkle prooofを用いて検証も行うことも出来る。これは後述するクロスシャードコミュニケーションの基幹部分にもなっている。  BeaconChainは既にメインネットにて稼働(12/1~)しており、バリデーターとして参加するにはEthに32ETHのステーキングする必要がある。バリデーターとなることで報酬を貰え、これは一定の報酬額をバリデーター全体で山分けする形になる。したがって、バリデーターが増えるほど個人が受け取る報酬は少なくなる。また、ブロック・TXの承認作業を怠ることがある場合、ステークされているETHから最大で60%が没収される。 ### ShardChain  ShardChainは既存のEth1と同様にアカウント管理やスマートコントラクトの実行などstateの更新が行われるチェーンである。それらのstateの更新を、BeaconChainによってバリデーターとして指定されたShardがブロック生成(PoS)を行う。  では何が既存と異なるのかというと、このシャードチェーンは1つではなく複数のチェーンが並列に存在することになる(最初は64のチェーン数から開始。徐々に増える予定)。複数の同一コンセンサスの元に稼働するチェーンが並列で稼働することで大幅なスケールが可能になると期待されている。  しかし、シャードによって複数のチェーンに分かれた場合、スケールが改善される一方でセキュリティが下がってしまう。 例えば64個のShardChainが稼働するとき、ShardChain全体が持つステークのうち、各Shard単体が占める割合は単純計算で`1/64 = 0.0156`(1.56%)である。するとEth2全体のstakeのうち、それらの過半数である約0.78%を持っていれば、それらのstakeを一つのShardに集めることで改ざんが容易にできてしまう。  これに対する対策として、BeaconChainのバリデーターがShardChainのバリデーターを乱数生成によってシャッフルし、割り当てるという仕組みあがある。 以下の図のように、赤が攻撃者、緑が善人だとすると、割り振りをランダムにすることによって、多少の偏りは発生するものの、統計的に赤のバリデーターは分散され、攻撃耐性が高まと考えられる。 ![The supposed simple solution](https://i.imgur.com/uNOujjd.png) 参考:[The supposed simple solution](https://medium.com/nearprotocol/unsolved-problems-in-blockchain-sharding-2327d6517f43) ### クロスシャードトランザクション (参考:[Ethereumのシャーディング概論](https://www.slideshare.net/bitbankink/ethereum-132664122)) ShardChainは複数のチェーンが並列で稼働するが、それらのstateはそれぞれのShardで独立したものである。そのため、他Shardでのstateの更新はBeaconChainの持つState rootを介して知ることになります。 例えば、AというShardに入っている通貨をBというShardに送金する場合、通常通りに行うことは出来ない。そこで、このような異なるShard同士の通信はBeaconChainを介して非同期的に行われる。 AからBに10ETH送金する場合、以下のようになる 1. AからBに10ETH送金するというトランザクションをBeaconChainに送信 2. BeaconChainは、Aが発行したトランザクションを含むstate rootを保持し、証明する 3. BはBeaconChainの持つstate rootからMerkle proofによって、任意のトランザクションの存在を確認 4. 確認できたトランザクションを元にBに存在するアカウントに10ETH追加する しかし課題として、他Shardでのトランザクションが承認されstateを更新し、ブロックに取り込まれた後に他Shardはそのトランザクションを知ることができる。という時間差が発生するため、跨ぐShardの数だけブロック生成される必要があり、遅延が発生してしまう。 この課題に対して、以下のような解決手法が提案されている。 - Yanking - スマートコントラクト自体を異なるシャードに移動させてしまうというアイデア - 手順としては、あるコントラクトを削除し、そのコピーを別Shardに移す - コードやストレージなどを含めて丸ごと移動させる - (課題)移動中はコントラクトを実行できない・移動コストがかかるなどの課題あり - Shard Pairings - ブロック生成のたびにランダムにShardのペアを作るアイデア - ペア同士は互いのStateにアクセス可能 - (課題)特定の希望であるシャードとペアになる確率は低い - (課題)3つ以上のシャードと関われない - Shard Zones - Shard Paieingsのペアをグループとして拡張するアイデア - 複数シャードを横断したコントラクトの実行が可能 - (課題)多くのシャードがStateを共有すると、そもそものShardingの利点が薄くなる ### PoS Eth2でのPoSにおけるブロック生成に関する役割として、Block Proposer と Committee が存在する。 - Block Proposer - 事前にBeaconChainによってバリデーターから抽選される - BeaconChainと各ShardChainにそれぞれ1名ずつ割り当てられる - Committeeの投票によって、正当なブロックチェーンを判断する - 正当なブロックチェーンの最後尾に新たなブロックを生成する - Committee - 事前にBeaconChainによってバリデーターから抽選される - BeaconChainと各ShardChainにそれぞれ複数名ずつ割り当てられる - 合意形成のために正当なブロックチェーンに投票する このように、ランダムで選ばれたブロック生成者とランダムで選ばれた投票者の2種の役割によってPoSは成り立つ。 ## 課題 (技術的な課題ではないが)Eth1.0をそのまま使いたいという人は必ず一定数存在するため、同じものが共存し混乱する。という事態は想定される。 また前述したとおり、クロスシャードトランザクションの遅延などに対する明確な解決策。というものは未だ定まっていないようなので、今後とも研究されていく部分であると思われる。 ## リンク - [[Japanese] Ethereum TOC](https://github.com/ethereum/wiki/wiki/%5BJapanese%5D-Ethereum-TOC) - [「Ethereum 2.0」の仕様と研究動向についてLayerX R&Dチームが解説](https://logmi.jp/tech/articles/323017) - [Sharding](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/sharding/) - [シャーディング技術の全体像と研究動向 @20200403 blockchain.tokyo Online#2](https://docs.google.com/presentation/d/1aTghdwY78hrXPFPDufiL-GpQvwbSj-IzAjW34pppDyM/edit#slide=id.p1) - [Ethereumの近況・Ethereum 2.0 @第2回BSEC研究会 2020/9/23](https://docs.google.com/presentation/d/1Dg9d1qoXT_mTk9z1_ZqPN71z6POCSNBZE9UdV9_DT0o/edit#slide=id.p) - [On sharding blockchains FAQs](https://eth.wiki/sharding/Sharding-FAQs) - [Eth2 sharding mindmap](https://www.mindomo.com/zh/mindmap/eth2-sharding-4408ec348bee4501aa125c3e3cd251d3) - [Ethereum Sharding Research Compendium](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) - [The Beacon Chain](https://ethereum.org/en/eth2/beacon-chain/) - [Unsolved Problems in Blockchain Sharding](https://medium.com/nearprotocol/unsolved-problems-in-blockchain-sharding-2327d6517f43) - [What you can do forEthereum 2.0 a.k.a. sharding, Q2 2018](https://docs.google.com/presentation/d/1G5UZdEL71XAkU5B2v-TC3lmGaRIu2P6QSeF8m3wg6MU/edit#slide=id.g3c326bb661_0_58) - [Ethereumのシャーディング概論](https://www.slideshare.net/bitbankink/ethereum-132664122) - [Ethereum2.0 コンプリートガイド(2020年11月版)仕組み・ロードマップ・ステーキングの要件・マーケットへの影響](https://hashhub-research.com/articles/2019-08-01-ethereum2-overview) - [What’s New in Eth2](https://hackmd.io/@benjaminion/eth2_news/https%3A%2F%2Fhackmd.io%2F%40benjaminion%2Fwnie2_201212) - [LayerX Ethereum 2.0 scrapbox](https://scrapbox.io/layerx/Ethereum_2.0) # Cosmos ## 概要  CosmosはTendermintというBFTコンセンサスアルゴリズムによって動いている、それぞれ独立した併存関係であるブロックチェーン同士のネットワークである。  Cosmosでは個々のブロックチェーンを**Zone**と呼び、このネットワーク上の始祖のZoneを**Cosmos Hub**と呼び、Cosmosにて定義された新しいZone間のコミュニケーションプロトコルを通じて他のZoneと接続される。またCosmos Hubは各Zoneに紐づく各トークンをトラッキングし、各Zoneにどれだけのトークンが流通しているかについての履歴を保持する。  現在、このCosmos Hub以外の全てのZoneは異なるZoneとトランザクションを共有する際には、必ずCosmos Hubを介することになる。したがって、CosmosというネットワークのHub的役割を担う。という意味でCosmos Hubという名前なのではないか。(将来的には全てのZoneが非循環グラフを作るためのHubとして機能できるよう目指している。)Eth2と比較すると、BeaconChain ≓ Cosmos Hub、ShardChain = Zone 。という役割で似ていると言える(設計などは勿論異なる)。  Cosmosは単一の分散台帳ではなく、またCosmos HubもCosmosネットワークの中心でもない。Cosmosはこのプロトコルを暗号学的見地、健全な経済原理、合意形成に関する理論、透明性や、責任追跡可能な性質などの原則に基づいた新しい未来の金融システムの土台となるオープンな分散型台帳としてデザインする。  またブロックチェーンをより簡単に、拡張しやすく開発するためのツールとしてCosmos SDKというものが存在する。 ## 設計 ### Tendermint / Tendermint Core  BFTにおいては各ノードは平等なのに対し、Tendermintでは各ノードはネガティブな投票券は持たずポジティブな投票券しか持たず、バリデーターと呼ぶ。バリデーターはブロックへの署名をネットワークにブロードキャストすることでTendermintの合意形成プロトコルに参加する。各バリデーターの投票券は、初期ではgenesisブロックによって規定され、次にTendermintを利用したアプリケーションが使用するブロックチェーンの設計によって変更されうる。Cosmos Hubのバリデーターとデリゲーターはシステム設計(gas limitなど)の変更の提案に投票したり、規約の修正案に投票したりなどが出来き、各Zoneは独自の規約・ガバナンス機構を持つことも出来る。  TendermintのアルゴリズムはDLSコンセンサスアルゴリズムから派生した部分的に同時進行型のBFTコンセンサスアルゴリズムであり、シンプルさ・高いパフォーマンス、フォークした場合の過去の履歴が追跡可能であるなどの点で優れている。ブロック生成の合意形成は、まず一つのブロックの合意形成をラウンドと呼ぶ。1回のラウンドにはラウンド・リーダーが存在し、新たなブロックを提案する。バリデーター達は投票を行い、賛成・非賛成を選ぶ。ラウンド・リーダーは順序付けされたバリデーターからPoSアルゴリズムによって事前に決められる。  Tendermintはバリデーターが事前に特定されていることから不特定多数のノードを相手にする必要がない。特定多数のバリデーターのステータスを確認し、最新ブロックステータスを決めるために2/3を超えるプレコミット(事前コミット)を証明すれば良い。したがってネットワーク負荷がかかりにくい。  TendermintはP2Pネットワークに対する典型的攻撃手法であるロングレンジアタック・Nothing-at-stake・2重使用・センサーチップなどに対し、未然防止の措置を講じることが可能である。  TendermintのコンセンサスアルゴリズムはTendermint Coreと呼ばれるプログラム上で実装されている。Tendermint Coreはコンセンサス・エンジンといえるものであり、これは決定論的にブラックボックスされたアプリケーションを分散的に複製されたブロックチェーン上に展開可能にする技術である。Tendermint CoreとアプリケーションはApplication Blockchain Interface(ABCI)を通じて接続される。ABCIはブロックチェーンとアプリケーションの境界線を定義するインターフェースとして機能する。これによって別プロセス同士で動いているアプリケーションの状態を管理可能になる。  まとめると、Tendermintはアプリケーションレイヤーとコンセンサスレイヤー間にシンプルなAPIを提供し、プログラマがブロックチェーンのアーキテクチャデザインを分解して使えるようにするソフトウェアである。 ### Inter-blockchain Communication (IBC) IBCはブロックチェーン向けのUDP・TCPに相当するような役割を担い、ブロックチェーン間のコミュニケーションを行うためのプロトコルである。 HubとZoneがどのようにコミュニケーションを行うかを見る。例として3つのブロックチェーン Z_A, Z_B, Hub があり、Z_AからHubを介してZ_Bに行くパケットを作るとする。 1. Z_AからHubにパケットを発行したことの証明(Z_A -> Hub とうパケットを生成した)を送信する 2. Hubは証明の検証を行うため、Z_Aの最新ブロックヘッダを常に監視することで、その証拠と同じ情報を持つブロックが存在することを確認する 3. Z_A -> Hub にパケットの送信 4. Hub - Z_B 間で1~3と同様の手順を行う このIBCプロトコルを実現するため、「IBCBlockCommitTx」・「IBCPacketTx」という2タイプのトランザクションを用いる。 またIBCはまだ正式にリリースはされておらず、Cosmos Hubのテストネットなどに実装はされているものの、まだ実際に使われているものではない(近いうちに利用できるとは言われている)。 ## Cosmos SDK  Cosmos SDKとはPoS・PoAを実装したチェーンを開発するためにOSSフレームワークであり、SDKを用いて構築されたチェーンは一般的にapplication-specific blockchains と呼ばれる。  このCosmos SDKが作られた目的は、インターオペラビリティを持つブロックチェーンをより簡単に開発できるようにするものである。Cosmos SDKは様々なモジュールを組み合わせることで成り立つ仕様で、殆どのモジュールはOSSであり、それらのモジュールを用いることでより簡単にブロックチェーンの開発をすることが出来る。 ### CosmWasm  Cosmos SDK上で作られるapplication-specific blockchains で wasmによりスマートコントラクトを実装するためのライブラリである。wasmによりスマートコントラクトを実装出来るということから、単純なパフォーマンスの向上が見込める。また、wasmはc/c++, go, rustなどの言語を用いて開発が可能なため、より多くの人がスマートコントラクトの開発に参加することが出来る。蛇足ではあるが、EthereumやPolkadotでも同様にwasmを利用する動きが存在する。 #### WebAssembly(wasm) WebAssemblyはwebブラウザのクライアントスクリプトとして高速実行するための新しいバイナリコードのフォーマットであり、様々なプログラミング言語でのサポートが進められている。 ## 課題・欠点 - 独自ブロックチェーンを作れるものの、その独自チェーンを維持するための独自バリデーターを用意する必要がある - Ethなどに乗っかるアプリケーションなどの場合、バリデーターの存在は無視できる - Tendermintによってある程度の共通規格が決まっているものの、各Zone毎に独自ガバナンスを設定できることから、完全に一致しないガバナンスを持つZone同士の連携は問題ないのか少々疑問 - Cosmos Hub以外の全ZoneがHubとなれることを目指す・IBCが近いうちに利用できるようになるなど、ある種目玉としているようなところはまだ利用できる状態ではない ## リンク - [Cosmos](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md) - [COSMOSホワイトペーパー日本語訳1](https://cc-res.com/2018/12/23/cosmos-whitepaper-en-ja-translation-1/) - [異なるブロックチェーンを相互通信するcosmosの仕組みを理解する(2019年8月改訂版)](https://hashhub-research.com/articles/2019-08-22-cosmos-overview) - [Tendermint – ブロックチェーンアプリケーションエンジン](https://gaiax-blockchain.com/tendermint) - [Cosmos SDKをちゃんと知る その1](https://medium.com/blockchain-engineer-blog/cosmos-sdk%E3%82%92%E3%81%A1%E3%82%83%E3%82%93%E3%81%A8%E7%9F%A5%E3%82%8B-%E3%81%9D%E3%81%AE%EF%BC%91-69c2a9a6aa81) - [Tendermint Essentials Vol.1 ~Tendermint Core & ABCI~](https://medium.com/blockchain-engineer-blog/tendermint-essentials-vol-1-tendermint-core-abci-69f1a3524820) - [トヨタ、自動車ID活用し中古車の流通を追跡](https://crypto.watch.impress.co.jp/docs/news/1241115.html) # Polkadot ## 概要  cosmosと同様に異なる複数のブロックチェーンを繋ぎ、スケールや相互互換性などを高めることを目的としたプロジェクト。あるいはそのネットワーク全体。  cosmosは個々のチェーンが個々のセキュリティを持つのに対し、Poladotは全体として一つのセキュリティプールを持つ。なぜなら個々のセキュリティで分かれている場合、最もセキュリティの弱いチェーンのセキュリティが全体のセキュリティになってしまうからである(cosmosはこれに対し対策ができるとしている)。  Polkadotのチェーンの役割はEth2.0のが近く、システム全体を管理・維持し中心であるチェーンと、そこに繋がる個々の独自性を持ったチェーンという構造になっている。しかし、個々のチェーンは独自の専門性を持つことを想定しているため、Eth2.0とcosmosの中間のようなイメージと言えるかもしれない。 cosmosにおけるcosmos SDKのように、PolkadotにもSubstrateという、開発支援のツールが存在する。 ## 設計 Polkadotは以下の3つのチェーンから成り立つ。 - Relaychain - 異なるチェーンを繋ぐ中心のチェーン - Parachain - Relaychainにつながる個々のチェーン - Bridge - Polkadotの外のチェーンとPolkadotを繋ぐチェーン ![全体の設計](https://i.imgur.com/t5uslid.png) 参考: [PolkadotWP](https://github.com/staketechnologies/PolkadotWP/blob/to-pdf/pdf/wp.pdf) ### Relaychain Relaychainは接続されているParachain, Bridgeのセキュリティを管理し、異なるチェーン間のやりとりを保証する役割を持つ。Relaychainはスマートコントラクトのデプロイなどが出来ず、チェーン間コミュニケーションの保証・システム全体の維持などを行う。また攻撃対策としてethereumのgasと同様のもはあるが、ethのようにトランザクション数に応じてgasが増えるということはない。各Parachainから送信されるトランザクションをまとめたブロックが追加されていく。 ### Parachain ParachainはRelaychainに並列に繋がる個々が独自なチェーンである。セキュリティはRelaychainによってもたらされるものの、チェーン内の計算処理などは各Parachain内のみで行われる。スマートコントラクトなどの実装も可能であり、各Parachainが自由な機能を持たせられる。 このParachainとして参加できるスロットは無制限ではなく限定した数しかない。したがって、ParachainとしてブロックチェーンがPolkadotに参加するためにはオークションで権利を勝ち取り、多額のDOT(Polkadotのネイティブトークン)を一定期間(最大2年)ステーキングする必要がある。常にParachainとしてRelaychainに繋がる必要は無いが、一時的に接続したい場合がるという時のため、Parathreadという仕組みも存在する。 #### Parathread  一言で言えば「低コスト版Parachain」である。Parachainは多額のステーキングが必要であり、Relaychainと常に繋がる利点が薄い場合、この多額のステーキングは無駄で割りに合わないコストになりうる。そこでブロック単位で手数料を払い、Relaychainに繋がることでPoヵどのエコシステムを受けることができる仕組みである。 ### Bridge BridgeはPolkadotの外の世界のブロックチェーンとの橋渡しをするチェーンである。BitcoinやEthereumなど異なるコンセンサスを持つチェーンをスマートコントラクトを用いて外部チェーンのイベント履歴を確認し、コミュニケーションを行う。 ### まとめ Eth2.0と比較すると、 - Relaychain ≒ Beaconchain - Parachain ≒ 各Shardが異なる機能・専門性を持つShardchain - Bridge ≒ 外部ブロックチェーンとのやりとりを行うParachain のようなイメージである。 ## ステイクホルダー Polkadotのシステムを維持する役割として4つのものがある - Validator - Collator - Nominator - Fisherman ![ステークホルダー](https://i.imgur.com/UKJW4t9.png) 参考: [PolkadotWP](https://github.com/staketechnologies/PolkadotWP/blob/to-pdf/pdf/wp.pdf) ### Validator Relaychainに滞在し、Collatorから送信されるブロックを検証・ファイナライズしRelaychainに取り込む役割を持つ。ValidatorはDOTをステークすることで参加することができ、ブロック報酬を受け取ることができる。Validatorとしての仕事を全うしなかったり、悪意ある行動をするとステークしたDOTや報酬が減少させられる。Validatorは一日数回、Validator志望者の中から数十人セットで選出され、選ばれる確率はNominatorにサポートされると増える。 ### Collator 各Parachainに滞在し、そのチェーンのフルノードを持ち、チェーン内のトランザクションをブロックにまとめてValidatorに送信する。この時点でブロックは確定されておらず、確定させるのがValidatorの役割である。自身の送信したブロックがRelaychainに取り込まれると報酬を貰える。CollatorになるにはDOTをステークする必要があり、送信先Validatorが問題を起こした場合、CollatorのステークしたDOTも没収される。 ### Numinator Validatorに投票を行うことができる。Validatorと異なりNuminatorに数の制限は無く、こちらもDOTをステークする必要があるが、Validatorなどのように検証やノードの運用などを行う必要はない。投票したValidatorが選出されると報酬の一部が受け取れる(該当選出者への全Numinatorで山分け)ため、インセンティブが働き偏りを無くすことができる。 ### Fisherman 成果報酬型の自警団のような役割。Validatorが悪意ある行動をしないか監視し、違反行為などを発見・通報すると、そのValidatorのステークしたDOTの一部、あるいは全てを受け取ることができる。こちらも同様にDOTをステークする必要がある。 ## 異なるチェーンのでのトランザクション処理の一例 Parachain A(P_A)とParachain B(P_B)が存在し、P_A -> P_B という送金トランザクションを作成するとする。 1. P_A内にて送金トランザクションを作成 2. P_A内に滞在するCollatorにトランザクションを送信 3. Collatorが検証後、承認されればP_Aに対応したValidatorにState transition proofと共に送信 4. Validatorが検証を行い、承認されればDOTをそのブロックにstake 5. 十分なDOTがValidatorとNominatorによってstakeされたらRelaychainに送信され、ブロックを追加 6. P_Bがそのブロックを確認し、該当トランザクションを実行 ## Substrate Substrateはブロックチェーンを開発しやすくるためのモジュールセットツールである。SubstrateはRustを用いており、wasmを用いた開発も可能である。 また、以下がSubstrateを用いて開発できるチェーンの種類(前述したRelaychainなどとは異なり、Polkadot内での役割というよりはPolkadotとの接続方法の種類)である。 - Solo Chain - どの異なる独自チェーンとも繋がらない閉じたチェーン - Solo Chain + Bridge - Parachainではないが、Bridgeを介してPolkadotのネットワークに限定的に接続できるチェーン。インセンティブ設計などはPolkadotとは異なるものを独自に用意する必要がある - Parachain - 前述の通り ### Substrateの利用レベル Substrateには3つの利用レベル(以下の紹介では4つ)が存在する。 - Polkadot Core - Substrateを用いないもの - Substrate Core - 基幹機能のみをSubstrateを用いて実装されたもの - Substrate Runtime Module Library(SRML) - そのチェーン特有のRuntimeを開発するのに便利なモジュールを用いて実装されたもの - Substrate Node - JSON fileを用いてconfigを用意するだけでスマートコントラクトを用いたチェーンが作れるもの ## 課題・欠点 - ParachainになるためのオークションでParachainに成れなかった場合、そのチェーンはどうなるのか - オークションで勝ち取り続ける保証は無い=システムが半永続的に動き続けるか分からないとなるのではないか - ## リンク - [Polkadot and Cosmos](https://wiki.polkadot.network/docs/en/learn-comparisons-cosmos) - [【Polkadot for dummies】初心者のためのPolkadot](https://medium.com/unchained-tokyo/polkadot-for-dummies-%E5%88%9D%E5%BF%83%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEpolkadot-7193831c2d2c) - [Polkadot-Whitepaper-JP](https://github.com/staketechnologies/PolkadotWP/blob/to-pdf/pdf/wp.pdf) - [Architecture](https://wiki.polkadot.network/docs/en/learn-architecture) - [Parachains](https://wiki.polkadot.network/docs/en/learn-parachains) - [Parathreadとは](https://medium.com/unchained-tokyo/parathread-japanese-a0f647f2bb9f) - # その他(横断的なもの・上記とは異なるもの等) ## リンク - [【比較】Polkadot vs Ethereum vs Cosmos](https://medium.com/unchained-tokyo/polkadot%E3%81%A8%E4%BB%96%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E6%AF%94%E8%BC%83-b3cbf077d522) - [COSMOSとPolkadotの比較](https://lifeforearth.com/?p=8323) - [LayerXが提供する新たなインターオペラビリティソリューション Cordage のご紹](https://medium.com/layerx-jp/cordage-introduction-a3a9259b69e) - [About Blockchain Interoperability](https://eprint.iacr.org/2020/643.pdf) - [Blockchain Interoperability: Towards a Connected Future](https://www.seba.swiss/research/blockchain-interoperability-towards-a-connected-future) - [Assessing Interoperability Solutions for Distributed Ledgers Extended version](https://www.ingwb.com/media/2667864/assessing-interoperability-solutions-for-distributed-ledgers.pdf) -