ThunderCoreについて


#1

ThunderCore追います。

LitePaper: https://docs.thundercore.com/thunder-litepaper.pdf
WhitePaper: https://docs.thundercore.com/thunder-whitepaper.pdf


#2
  • EVMと互換性あり。EthereumのDAppsをThunderCore上で実行できる。

  • TPS +1200

  • ファイナリティがすぐに得られる


#3

As long as a) the Accelerator is acting honestly, b) network conditions are good,
and c)> 3/4 of the committee are honest, we barely need to use the slow-chain at all; instead,
transactions can be confirmed on the fast-path by the committee using an extremely simple and
lean fast-path protocol. This protocol offers both high throughput and instant confirmation of
transactions. But the fast-path only confirms new transactions assuming the above mentioned
good conditions are met. When they are not (e.g., the Accelerator misbehaves or is under attack),
we leverage the “slow chain” to recover in a provably sound manner.

ThunderにはSlow-chainとfast-pathという2つの概念があり、fast-pathはStakeしたCommittee(PoSのような概念?)によって選出されるAcceleratorによって支えられている。Acceleratorが正直に動き、ネットワークが正常な上で3/4以上のcommitteeが正直であればslow-chainを使う必要がない。この場合、高いスケーラビリティと早いファイナリティをえる。上記の環境が整わないときはslow-chainで承認を行い。このchainは一般的なパブリックチェーンと変わらない。コンセンサスアルゴリズムを普段はPOAにしてやばい時はPOWに切り替えるイメージかな。


#4

This blockchain currently is based on proof-of-work, but there are ongoing plans to replace
it with a proof-of-stake system. In our initial deployment, we will also only rely on a single
Accelerator; in later versions, we will extend the system to support multiple shards, each having
their own dedicated Accelerator. Allowing anyone to create their own shards will also help establish
a healthy ecosystem where accelerators are incentivized to provide faster and more reliable service
(and accelerators providing poor service will die out).

◯現在Slow-chainはPoWによって支えられているが、PoSに移行予定。
◯現在Accelerator(合意形成Nodeと理解している)は1つ。めちゃセントラライズw。将来的にはシャーディングできるようにする。そのためのPoS化だと考えられる。


#5

ConsensusにおけるPaperのこの定義すばらしい。

Consensus: A consensus protocol enables maintaining a “linearly ordered log” of transactions in
a distributed fashion such that the following two properties hold:

"linearly ordered log"は言われてみれば当たり前だけど、すごくしっくりくる。


#6

最悪のケース→Slow-Chainで対応
・Nakamotoコンセンサス。マジョリティーが正直であれば問題ない
・しかし、処理速度とリアルタイム性は落ちる

通常のケース→fast-pathで対応
・Slow-chainが安全で有ることが前提
・Acceleraterがオンラインにいて、正直な振る舞いをする
・マイナーの内、3/4が正直
・1ブロック2秒ほど

基本的にfast-pathで対応して不都合が起きた際にはslow-chainで対応する。