KASANEの考察 - SYMBOL
自分なりに現時点でのKASANEの解釈と感想を書き連ねてみる。解説ではなく考察であることに注意。ちなみに僕は趣味でSymbolを触ってるだけで仕事はエンジニアじゃないし、技術者と言われてもそんなつもりはないんだけどなーと体がむず痒くなります。なので知ってる技術用語はSymbolで学んだ言葉が多く、有識者の方と比較しても幼稚な表現しかできないこと多々。
また、僕はXYMPOSIUMに参加しておらず基本的にはスライドのみを基にしています。自分だけで満足しようかと思ってましたが、多分同じようによくわかんねぇって方も沢山いると思うので少しでも役に立てばと思い公開すると思います。
他のブロックチェーンに関する知識はほとんどないので「それ当たり前やん」みたいなのもあるかもだし、想像や感想を多く含むので気分を害する場合はそっと閉じてみてください。
間違っても投資判断に使ったりはしないでください。妄想の世界だよ。
エアリプ苦手なので、間違いや指摘などあればメンション付けてお願いします。その指摘によって改善されるのはありがたい限りです。
よし、これだけ保険をかけとけば大丈夫だろう。
※ ここは最後に追記した箇所です。何が出来るようになるのか?はうっすら分かったような気はするけど、どうやってやるか?は全然分かりません。今後のドキュメント公開を待ちます
スライドを翻訳しながら進めます。翻訳は主にDeepLに任せますが多少編集するかも。スライドを翻訳しながら考察していきます。なので途中で書いたことをその後に訂正したりしています。
This may be the direction we’e charted, but you steer the ship.
これが我々の描いた方向かもしれないが、船の舵を取るのは君だ。
Before we begin, it’s important to fefine an anchor. While a purpose or a mission can change with the captain or the tides, an anchor is what keeps us grounded. In times of turmoil, frustration, or uncertainty one can always return to their anchor to realign them as to why they’re here.
Our anchor is, and always will be, Symbol. Much like the projects before us(and the many to follow), we believe blockchain to be the most suitable technology to power a new economy - and Symbol is our contribution to that pursuit. As a protocol, it’s characterized by a consensus algorithm that seeks to reward users of a chain preferentially over hoarders of wealth. As a system it’s characterized by an arcihtecture that extends functionaloty through system - lebel plugins, as opposed to opcodes in a help define our design philosophy - that is, a user-first, service-orientated approach. We believe blockchain to be human-centric technology, and everything we seek to do with Symbol must under score this.
This document isn’t intended to be a whitepaper, a litepaper, a business document or even a manifesto. Human-centric technology is developed by its users, after all, and we intend to define, design and develop Symbol right alongside the community. instead, think of this as a north star that we can use to navigate the way forward - for although an anchar might keep us grounded, it’s the constellations that help us set sain to new lands."
その前に、錨を定めることが重要だ。目的や使命は船長や潮の満ち引きによって変わるものだが、錨は私たちを地に足をつけさせるものだ。混乱や挫折、不安のとき、人はいつでも錨に立ち返り、自分がなぜここにいるのかを再確認することができる。
私たちの錨はSymbolである。私たちは、ブロックチェーンが新しい経済に最も適したテクノロジーであると信じています。プロトコルとしてのブロックチェーンは、コンセンサス・アルゴリズムによって特徴付けられ、富をため込む人よりもチェーンの利用者に優先的に報酬を与えようとするものです。システムとしては、私たちの設計哲学を定義するのに役立つオペコードとは対照的に、システム-リーベル・プラグイン-を通して機能性を拡張するアーキテクチャが特徴です。私たちはブロックチェーンが人間中心の技術であると信じています。
この文書は、ホワイトペーパー、ライトペーパー、ビジネス文書、あるいはマニフェストになることを意図したものではありません。人間中心のテクノロジーは、結局のところユーザーによって開発されるものであり、私たちはコミュニティとともにSymbolを定義し、設計し、開発するつもりです。代わりに、これは私たちが進むべき道をナビゲートするための北極星だと思ってください。
ポエム。序章的なの。まだまだ未定義・未設計な箇所は多く、これからコミュニティと共に…とのこと。あくまでも北極星であり指針であると。この冒頭の文章がこのスライドの序章なのか、それとも他の用意している技術書の序章なのかも?とちょっと思ったり。
Symbol’s guiding design philosophy was that for 80% of blockchain use-cases, most applications only needed three simple building blocks: tokens, transactions, and accounts; and rules around how these pieces could interact with each other.
Symbolの設計思想は、ブロックチェーンのユースケースの80%において、ほとんどのアプリケーションは3つのシンプルな構成要素- トークン、トランザクション、アカウント - と、これらの要素が互いにどのように相互作用できるかをめぐるルールだけが必要である。というものであった。
ここは結構気になってて、たぶん後で書くけど要するに「なんでもできるぜ!」って感じなので、Symbolの目指してた所は元々そこだっけ🤔という疑問。ジャガーさんやGimreさんはどう考えてるんだろうなって思った
※そういやハチェ姐のXの投稿にここ二年はジャガーさんと一緒にうんぬんかんぬんってあったので、そこは大丈夫なんかな
With Symbol 2.0, we wanted to address the ask for cross-chain compatibility and open the design space to more complex products, without compromising on our core ideology behind protocol design.
シンボル2.0では、プロトコル設計の核となる理念を損なうことなく、クロスチェーン互換性の要求に応え、より複雑な製品にも対応できるよう設計の幅を広げたいと考えました。
>プロトコル設計の核となる理念を損なうことなく
上の文章を早速否定してくれる一文があるので少しは安心はした
Developers should be free to use the components they need to create their ideas - whether that’s the EVM; SVM; MoveVM, or more.
開発者は、EVMであれ、SVMであれ、MoveVMであれ、アイデアを生み出すために必要なコンポーネントを自由に使うことができるはずだ。
EVM = Ethereum Virtual Machine、イーサリアム・ブロックチェーン上でスマートコントラクトを実行するためのソフトウェア環境
つまり、他のブロックチェーン上のスマコンをSymbolのトランザクション内で使用できるようになるということであろう。できることの幅が拡がることは容易に想像できる
Scalability is not a one-dimensional problem. Match validators and their hardware to their appropriate purpose.
スケーラビリティは一次元の問題ではない。バリデータとそのハードウェアを適切な目的に適合させる。
スケーラビリティ = 「トランザクションの処理量の拡張性」つまり、どれだけ多くの取引記録を同時に処理できるかの限界値のこと、おそらくノードの保存量の限界値も含むと思う
あくまでも個人的にはスケーラビリティの問題ってあんまり考えたこと無くて(だって今スカスカだから)、気分が盛り上がらない。予防って苦手よね
KASANE builds upon Symbol’s principles the design space for developers.
KASANEは、Symbolの原則に基づいて開発者のためのデザインスペースを構築しています。
Built for Scale. Built for Symbol.
KASANE for the next decade(and beyond); expanding the design space for developers with their choice of virtual machines; and adding a whole new set of features with curated chains.
It consists of four key components: an appChain, a subChain, a settlement layer, and an orchestration layer.
KASANEは、次の10年(そしてそれ以降)に向けて、仮想マシンの選択によって開発者の設計領域を拡大し、選別されたチェーンによってまったく新しい機能を追加します。
KASANEは、appChain、subChain、決済レイヤー、オーケストレーション・レイヤーの4つの主要コンポーネントで構成されています。
次の10年、それ以上ともなればまぁスケーラビリティのことを考えるのは当然か
デザインスペースってなんだろうと思ったけど、開発者のできることを拡大しようということか
Meet appChains.
Application chains are focused spaces for developers to execute their ideas.
appChains can roll-up and roll-down based on demand, allowing us to ‘load balance’ and save state space for applications that are not generating demand.
アプリケーション・チェーンは、開発者がアイデアを実行するための集中スペースです。
appChainsは、需要に応じてロールアップとロールダウンが可能で、「ロードバランス」を行い、需要のないアプリケーションの状態領域を節約することができます。
さて、わからなくなってきた。appChainsという概念があるようだが、これはつまりアプリケーション一つにつき、一つのチェーンが存在するということなのか?これはあまり現実的じゃないのかなと思った。が、「ロールアップ」「ロールダウン」「ロードバランス」という3つの単語から、そうではなくてappChainsとは大枠で見ると一つのチェーンだけど、アプリ単位など使用する領域がノードごとに違ったりするのでは?という妄想が始まる。
太郎さんのノードはアプリAを花子さんのはアプリBをみたいな。これは後ほど出てくるシャーディングやゼロ知識証明にも関連してくる
Meet subChains.
subChains are curated transaction layers designed arounde the needs of specific industires: gaming; documentation; music; images; videos; stablecoins; payments; and more.
Validators can specialize in processing for a specific set of subChains in order to earn additional fees on top of base block rewards.
subChainは、特定の業界のニーズを中心に設計された、キュレーションされたトランザクションレイヤーです。
バリデーターは、特定のサブチェーンのセットに特化して処理を行うことで、基本的なブロック報酬に加えて追加の手数料を得ることができます。
スライドを見る限りsubChainの中に複数のappChainがあるのよね、つまりゲームに特化したsubChainの中に複数のゲームアプリに関するデータが保存されたり、そのチェーンを使用したりするって感じだろうか
特定のサブチェーンのセットに特化して処理を行うことで
この一文を見て想像したのは、ここまでappChainsやsubChainsのようにいかにも沢山のチェーンが存在するように見えたけど、ノーダーの視点から見ると実はそうではなくて、あくまでも単一のSymbolのノードを立ち上げておきながら、個別の設定で自身のノードがどのチェーンを支持するか選べるのではないかと。妄想がすぎる?うーん、どうだろう。
ちなみに事前知識として、Symbolにはプラグインとエクステンションという概念があるので、それをちょっと説明しておきます。
KASANEで言っているプラグインは Symbol解体新書の2章のシステムを読むと理解度が深まると思う。#symbolhttps://t.co/1xVB5ukxSy
— Daoka (@DaokaTrade) September 27, 2024
ぜひ、解体新書を読んでもらいたいのですがここでは大事なところだけ
プラグイン
ネットワークを形成するすべてのノードは、同じタイプのトランザクションおよびプロセスを正確にサポートしなければならない。
拡張機能(エクステンション)
ネットワークを形成する個別ノードは、それぞれが違った機能を提供することができる。
確かプラグインにはトランザクション以外もあった気がするので、ネットワーク上のノード全てが同じでなければフォークしちゃうのがプラグインで、ノード単位でそれぞれ別の機能を追加したりできるのが拡張機能って感じかな
つまり、拡張機能は同じチェーンであってもノード単位で選択できるので、自分のノードがどのチェーンのデータを残すのか選べたら面白いなと
※ここは違うっぽい、オーケストレーションレイヤーの話で気づく
んで、当然選択数が多ければノードへの負担は大きくなるので、その分追加の報酬が得られる、おっ、さっきの話と辻褄が合う
スライドに戻って
Functional finality.
The source of truth for the ecosystem, the settlement layer keeps record of KASANE’s entire complex state.
This layer is capped at a fixed state size, enabling consumer grade hardware to quickly validate finality.
NEM and Symbol’s historical state is also queryable here, ensuring that legacy applications will have no impact to operation.
エコシステムの真実の源である決済レイヤーは、KASANEの複雑な状態全体の記録を保持する。
このレイヤーの状態サイズは固定されており、コンシューマーグレードのハードウェアで最終性を迅速に検証することができます。
NEMとSymbolの過去の状態もここで照会可能で、レガシーアプリケーションが運用に影響を与えないことを保証します。
決済レイヤーは、例えばトランザクションのハッシュと保存先の情報を持っていて参照するとか?で、データとハッシュを基に検証を行い、そのデータの正否を判定する
多分、STARK再帰とかの話がここで出てくるような気はするが後ほど
決済レイヤーはNEMやSymbol 1.0の情報も持っているので違和感なく2.0でも使えるようになる。とかそんなイメージ
Meet the Matchmaker.
The orchestration layer is a ‘matchmaking’ service for validators, intelligently profiling a nodes hardware and assigning them to the most appropriate appChains and subChains, based on a combination of demand projection (for the chain) and fee earnings (for the validator).
オーケストレーションレイヤーは、バリデーターのための「マッチメイキング」サービスであり、ノードのハードウェアをインテリジェントにプロファイリングし、(チェーンにとっての)需要予測と(バリデーターにとっての)手数料収益の組み合わせに基づいて、最適なappChainとsubChainに割り当てます。
バリデーターについて: 現Symbolの場合はpeer nodeがブロック生成を担っていて、APIノードはオプションなので、現状全ノード = バリデーターなのかな、このへんが2.0で変わるのかどうかは不明
そういえば今でもharvesting機能は拡張機能でオフにできる、オフにしたことないんだけど、これだとブロック生成せずにpeerとして他と同期するだけになるのかも🤔
このスライドではオーケストレーションレイヤーの話がされていて、こいつが頭が良くて良い感じに計算しながらどのノードをどのチェーンに割り当てるか、とかをノードのスペックや各Chainの需要などで判断するのかな
なので、上で書いたようなノード運用者が自身でChainを選択するわけではなさそうとここで気づく
KASANE improves on Symbol’s existing throughput to ensure both vertical and horizontal scalability.
KASANEはSymolの既存のスループットを改善し、垂直方向と水平方向の両方のスケーラビリティを確保する。
appChains provide Symbol with horizontal scalability; the Orchestration Layer provides Symbol with vertical scalability.
appChainはSymbolに水平方向のスケーラビリティを提供し、オーケストレーション・レイヤーはSymbolに垂直方向のスケーラビリティを提供する。
スライドに画像があって、それぞれのレイヤーやチェーンの構造が示されている。※ここ、後で戻ってきそう
スライドは以下投稿より拝借してて、その画像を掲載するのはちょっと違うと思うので、ツリーを探って探してください
技術的部分の理解が追いつききらないので
— のののん @nononon.symbol (@_nononon__) September 27, 2024
解読モトム
(リプに続く) pic.twitter.com/VwlXKwOLki
KASANE adds a rich economic ecosystem without compromising the developer or user experience.
KASANEは、開発者やユーザーの体験を損なうことなく、豊かな経済エコシステムを追加します。
Both validators and subChains can split their block rewards with appChains. No need to go raise capital - build enough value, and the protocol will reward you natively.
バリデータもサブチェーンも、appChainでブロック報酬を分割することができる。資本を調達する必要はありません - 十分な価値を構築すれば、プロトコルがネイティブに報酬を与えます。
これまでのように全てのノードがバリデータではなく、サブチェーンとしてストレージを提供する物もいればバリデータとして計算してブロックを生成するノードも存在するようになるのかな
そういうわけじゃなく、全ノードはバリデータだけどここでは分かりやすくブロック生成したノードとNFT-Driveを分けてるってことかも
スライドではNFT-Driveさんが掲載されているんだけどこれはサブチェーンなんだと思う、その下にappChainがあって、例えばNFT-Driveを利用しているアプリケーションに関するブロック報酬はバリデータとサブチェーンであるNFT-Driveで分けることが出来るようになる、、、みたいな?
KASANE design enables us to quickly import existing solutions and stacks, without picking or choosing a winner.
KASANEデザインは、勝者を選んだり選んだりすることなく、既存のソリューションやスタックを素早くインポートすることを可能にする。
次のスライドは画像のみ、ここにはappChainと書かれていて
Application
ProgramID: simpleswap.symbol
Extensions: aggregateTx, atomicTx, …
Plugins: chainlink
Rules: allowlist, doNotTrade
Data Availability: Optimism, Celestia
External Storage: IPFS, Arweave, FileCoin
Contract: MoveVM, EVM
と書かれていますが、特に説明はなさそうなので会場に居た人は何か知ってるのかもしれない
ちなみに僕はほとんどよく分かってないけどchainlinkなるものは面白そうでふぁーさんがDiscordに書いてくれてたので興味あれば読んでみると良き
Pluginの中にあるので、これが使えるようになるトランザクションが出来るのかな
atomicTxってのはみんな大好きDEX的な?
これらが一番したのappChain層で使えるようになるぜ!って話の箇所だと思う。なんでも出来ます!な箇所で、ここは結構長期的な話じゃないかなー
KASANE enables retention of NEM and Symbol’s current state without the fragmentation of liquidity.
KASANEは、流動性を分断することなく、NEMとシンボルの現状を維持することを可能にします。
KASANE’s STARK recursion allows us to take the entire state of a blockchain at a given block height, compress, and archive it.
Applications can continue to query; and nodes can unroll historical data when they need it. Pointers to existing headers and succinct proofs link back to subChains to prove province of prior data.
KASANEのSTARK再帰は、あるブロックの高さにおけるブロックチェーンの状態全体を取得し、圧縮し、アーカイブすることを可能にする。
アプリケーションは問い合わせを続けることができ、ノードは必要なときに過去のデータを展開することができる。既存のヘッダーへのポインタと簡潔な証明は、サブチェーンにリンクし、以前のデータの州を証明する。
ここでも妄想を始める。上で[それぞれのレイヤーやチェーンの構造が示されている。]と書いたスライドには
[appChain -> zk-SNARK -> subChain -> zk-STARK -> settlementLayer]
みたいなことが書かれていた。zk-SNARKやzk-STARKについては詳細は省くけど、データを圧縮して、元データが改ざんされていないか検証する仕組み、ゼロ知識証明の一種。ぐらいの認識で良いと思う。
— Hatchet (@0x6861746366574) October 1, 2024
二個使い分けてるので適切な技術を適切な箇所にってことだろう。
ちょっと話をそらすけど、なんでこんなことしてるのかと言うといわゆるシャーディング?
'''
シャーディングとは、データを小さな部分(シャード)に分けて、複数のサーバーやコンピュータに保存する方法です。これによって、たくさんの人が同時にデータを使っても、処理が早くなります。例えば、大きな図書館を考えてみてください。一つの部屋にすべての本を詰め込むのではなく、テーマごとに分けて複数の部屋に置くことで、必要な本をすぐに見つけられるようにするイメージです。こうすることで、全体の負担が減り、効率が良くなります。
'''
で、さっきの話に戻るけど、完全なデータはappChainにのみ残っていて、それをzk-SNARKにより圧縮、圧縮されたデータはsubChainに送られ、これがブロックを生成する、さらにその生成されたブロックデータはzk-STARKにより圧縮され、決済レイヤーに残る。
もしくは、データストレージはIPFSのようなストレージに保存し、appChainではその圧縮されたデータを保持する、もちろんそれはzk-SNARKで圧縮されているのでチェーン外にある元データは検証可能、、とか?
決済レイヤーに問い合わせると必要な情報は何か?を基にその箇所を教えてくれる。データ全てがほしければロールダウンされデータが手に入るし、詳細は不要で大枠がほしければ(具体的にはどういう用途か知らんが)appChainまで及ばないのかもしれない
と考えると再帰という言葉を使ってるのも納得が行く
各ノーダーはどの層に割り当てられるかはオーケストレーションレイヤーがスペックや需要を基に決める
うん、なんとなくだけど遠からず近からずな気はしてきた
subChains are purpose-built around common use cases and optimized for specific transaction sets.
サブチェーンは、一般的なユースケースに特化して構築され、特定のトランザクションセットに最適化されている。
サブチェーンごとに必要なトランザクションは選別されセットされる、例えばMessaging subChainにはTransferTransactionは必須だけど(もしかしたらもっと専用になるかもだけど)、mosaicDefineTransactionなどモザイクを作成する機能はいらんよね、みたいな?
Transactions can now have their logic expanded to support complex events scheduling.
Want to kick off a transaction when a set criteria is met, or schedule a set of transactions in the far future, without an off-chain listener? We’ve got you covered.
トランザクションのロジックを拡張し、複雑なイベントのスケジューリングをサポートできるようになりました。
オフチェーンリスナーなしで、設定された条件が満たされたときにトランザクションをキックオフしたり、遠い将来のトランザクションのセットをスケジューリングしたいですか?私たちはそれをサポートします。
ここはおそらくこの投稿のほうが分かりやすいかな
The first feature we want to add to Symbol is 'event-based' and 'time-based' transactions.
— Hatchet (@0x6861746366574) September 28, 2024
Currently, Symbol has the ability to perform a HashLock etc. at some block height in the future, but it has a limit of how many blocks into the future it can be scheduled for.
What if you…
イベントベースのトランザクションは非常に可能性があります。
— KICN-FT@kicnft.symbol (@kicnft) September 28, 2024
今でもハッシュロックという、特定のトランザクションを即時承認せずに待機させる方法がありますが、その条件が「AliceがBobに送金したとき」といった出来事(イベント)をきっかけにすることができそうです。 https://t.co/KwfU8i2TUi
今は、とある秘密を知っていてそれをトリガーにトランザクションが成立する、的なのはあるけど、もっと自由に例えば「AliceがBobに送金したとき」をトリガーにトランザクションが成立したりできるぽい、面白そう
…and many, many more features that we ran out of time to illustrate and build slides for.Technical documentation coming soon™️, soon as SegFaultXavi finishes building his video game.
......そして、私たちが説明したりスライドを作ったりする時間がなくなってしまった、もっともっとたくさんの機能がある。
SegFaultXaviがビデオゲームを作り終わり次第、技術的なドキュメントを近日中に公開する予定だ。
ここはジョークね、soonはsoonだ。
SegFaultXaviさんは以前は海賊チームだったXaviさん。今、ゲーム作ってるのかな?
KASANE builds upon Symbols’s core philosophy: master 80% of use cases, while also enabling developers to take advantage of the technologies in the broader ecosystem.
KASANEはSymbolsの基本理念である、80%のユースケースをマスターし、同時に開発者がより広いエコシステムで技術を活用できるようにすることを基盤としています。
To kickstart the activity, we’re buildging right alongside you...
この活動をスタートさせるために、私たちは皆さんと一緒に建設しています。
Davy Jones Ledger
がデザインされたスライド。Davy Jonesってパイレーツ・オブ・カリビアンに出てくるタコ?の船長だと思うんだけど、これが何を示すのかは会場に居た人だけが知るのかな
…and opening the doors for the world to come shape this with us.
......そして、世界が私たちと一緒にこれを形作るための扉を開く。
Our biggest haters say Symbol is an island.
Embrace it.
Let’s make it the #1 travel destination.
私たちの最大の嫌われ者は、シンボルは島だと言う。
それを受け入れなさい。
ナンバーワンの旅行先にしよう。
終盤はポエム、最後のスライドは面白いね。日本人におけるハワイになろう!ってことか?余談だけど私が住むキプロス共和国はEUやロシア圏の人にとってヨーロッパのハワイと言われてる(らしい
さて、以上になります。
冒頭にあったように
> まだまだ未定義・未設計な箇所は多く
だと思うので全てを鵜呑みにするわけではなく、こういうことを考えている程度の解釈で、可能なら自分もクルーになってやろう!という意気込みを持てば楽しいね。
とは言え、2年ぐらい前からサブチェーン構想はあったと思うし、色々考えてきた末で今に至ると思うので、「見えてきている」んだと思う。
ドキュメント等は順に公開していく、もしくは全てが整えば公開する。とのことなのでそれを待つのもアリかな
これをPluginとExtensionだけで賄えるのか?それとももっと大きな改変が必要なのか?は分からない。前者だと凄いと思う。でもCatapult自体は空っぽの箱で全てPluginとExtensionで構成されてるような気もするから可能なのかな
ここまで初稿、radioさんから正しい翻訳が出る
ここでははっきりL2,L3と分かれてるので別のチェーンなんだろうけど、例えばmessageChainもstable chainも別チェーンでさらにはアプリケーション単位でチェーンが存在するのかな
ノード運用者の観点から考えるとそんなに無数のチェーンがあったら、運用できなくない?めちゃめちゃエコシステムが拡大されてノーダーの数が居て、Symbol自体の価値が上がればあり得るのかもしれないけど
と、最初は考えたけどオーケストレーションレイヤーの話を思い出すと、このレイヤーでは需要などに従って各ノードの振る舞いを制御するみたいな話しだったので、実はノードは一つだけど、その中に複数チェーンが混在しているような状況を考えると辻褄が合う。
なんだかすごい話なんだけどそういうことなのかな🤔もちろん妄想だけども。
さて、最後に。。。
繰り返しになりますが本記事はXYMPOSIUMのスライドを基に僕が妄想を繰り広げた物です。なので、間違ってることも多々あるかもだし、絶対に投資判断の一つなどにせず、一緒にあーだこーだ言えたらいいですね
それと、KASANEの話は主にシャーディングやスケーラビリティのことに焦点を当てていますが、これらは中長期的には必須になるかもしれません。しかし、現時点では目の前で困っているわけではありません。(もちろんそうじゃない箇所もあるから楽しみは倍増してる)
もっと現Symbolで実現できることはたくさんある(はずです)ので、そちらに注力するほうが今は効率的で建設的だと思います。さまざまなアプリケーションがもっと出てきて、活用されて社会に実装されていくことを願っています!