Meeiro

Meeiroプラットフォームは、Aptos上の分散型IDOローンチパッドです。このプラットフォームでは、Aptosエコシステムに分散型資金調達、トークンステーキング、ガバナンス投票を導入する予定です。

私たちはUIとUXに多くの力を入れています。なぜなら、この2つの最も重要な特徴は、DeFiスペースに欠けている、あるいは十分に力を入れられていないと感じているからです。これらは、新しいユーザーをAptosのエコシステムに統合する際に、考慮すべき最も重要な要素です。

Meeiroについて知りましょう！

このポータルは、Meeiroプラットフォームの知識ベースとして機能します。私たちのトークノミクスとロードマップを読むことができ、現在パイプラインにある様々な製品に深く知ることができます。またこのドキュメントでは、チームのビジョンや、任意の時点で導入される可能性のある新しい機能、または実装について説明します。

🚀 IDO ローンチパッド

Meeiroローンチパッドの使命は、新しいプロジェクトが急成長し、長期的に成功するための強固な基盤を築くために、必要なあらゆるものを提供することです。

アロケーション配分

このローンチパッドはMeeiro ステーキングに接続されます。私たちは、忠実なホルダーに報酬を与えながら、コミュニティを成長させるために、このローンチパッドを設計しました。

より多くの $MEEトークンをステークすればするほど、より多くのIDO割り当てを受けることができます。 ユーザーが受け取る割当は、以下の通りです。

• 各$MEEは1つの「シェア 」を提供します。

シェアとは何ですか？

各シェアを持っていると、Meeiroで販売されているトークンを購入できる可能性があります。各シェアの価格は、トークン発売の直前に決定されます。

MEEをステークせずにシェアを持つことはできますか？

各IDOでは、総シェアの10％がコミュニティプールに分配されます。このプールは、抽選でアクセスできるようになります。各IDOでは、コミュニティプールのシェアを獲得するために、ユーザーにいくつかのソーシャルタスクを課す予定です。より多くのソーシャルタスクをこなせばこなすほど、コミュニティプールから選ばれる確率は高くなります。

各アロケーションはどのように決定されるのですか？

各IDOごとに、アロケーション量が変わります。以下の式で決定されます。

調達額とは、プロジェクトがMeeiroを通じて調達したい金額です。

シェア数は、IDOに参加している人の持つシェア数の合計です（自分のシェアを考慮してもらうためには、IDOに登録する必要があります）。 調達額は、目標達成の可能性を最大化するために4倍されます。目標金額を上回る資金が集まった場合、ユーザーには比例して返金されます。

ℹ️ 例えば、私たちは200,000USDCのハードキャップのIDOを運営しており、各トークンのコストは1USDCで、5,000,000シェアが登録されています。

ユーザーである私は、5ヶ月前から3000MEEをステークしており、3000シェアを持っていることになります。

これで自分のアロケーションを計算することができます。

[アロケーション] = (200,000*4/5,000,000)*3000 = 480 USDC のアロケーション、つまり480トークン です。

各IDOについて、4つのシナリオを想定しています。

すべてのアロケーションを満たす

もし、すべてのアロケーションが満たされた場合、400％のオーバーサブスクリプションとなることを意味します。

ℹ️ この例では、アロケーションの1/4しか受け取れず、3/4が返金されます。つまり、120トークンを受け取り、360USDCが返金されることになります。 これは最悪のケースで、受け取るトークンが少なくなるケースです。

すべてのアロケーションが満たされないが、IDOはオーバーサブスクリプションである

すべてのアロケーションが満たされないが、IDOがオーバーサブスクリプション（調達額＞目標調達額）となった場合、私が受け取るトークン数は以下の式で定義されることになります。

ℹ️ 200％のオーバーサブスクリプションでゴールに到達したとしましょう。

[受け取ったトークンの数] = 480*1/2 = 240トークン

よって、240トークンを受け取り、240USDCを返金されることになります。

目標値以下の調達

もし、目標調達額を下回った場合（調達額＜目標額）、支払ったトークンをすべて受け取ることができます。

ℹ️ この場合、480トークンを受け取ることになります。

目標額の半分以下しか集められない

万が一、IDOが調達目標の50％を超えられなかった場合、USDCは全額返金されます。

ℹ️ この場合、480USDCが返金されます。

Meeiro Shieldで安心

Meeiroの全てのVested IDOは、Meeiro Shieldで保護されます。当社のチームは、投資家とMeeiroで立ち上げられたプロジェクトが、最も倫理的な機会とプラットフォームの完全性を確保するために、この機能を開発しました。

Meeiro Shieldを使用すると、あなたのオリジナルのIDO投資がMeeiroによって保護されますが、その方法は以下の通りです。

• プロジェクトのトークン価格が、権利確定スケジュール内のいずれかの権利確定アンロック日にプレセール価格を下回った場合、IDOセール参加者はMeeiroから、そのアンロックに対するプレセール価格と同額のUSDCで、当初の投資額を払い戻されます。

• プロジェクトのトークン価格が2回連続の権利確定アンロック日（例：2ヶ月目、3ヶ月目）にプレセール価格を下回った場合、参加者は残りのアンロック分についてMeeiroからUSDCで投資額が払い戻され、権利確定スケジュールは終了させられます。

Meeiro Shieldはどのように機能するのですか？

トークンIDOを例として、Meeiro Shieldの実践例をご紹介します。

セールのタイプ： 権利確定｜TGEで50％、2ヶ月の線形権利確定（毎月25％）

トークン価格：1 USDC

ここでは、Meeiro Shieldの仕組みを3つの例でご紹介します。

Meeiro Shieldを使用した成功した / 通常権利確定IDOの内訳はこのようになります。

つまり、IDO期間中にトークンを1USDCで100USDC分購入していた場合、合計で100トークンを請求することができます。まず、2022年9月14日のTGEで50％（50トークン）、その次の2ヶ月で25％（例：11月15日に25トークン、10月15日に25トークン）です。

Meeiro Shieldで一部返金 権利確定IDOの内訳はこんな感じです。

ただし、権利確定アンロックの期間が2ヶ月より長い場合（例えば3ヶ月、トークンが2ヶ月連続でプレセール価格を満たさない、または上回ることができなかった場合）、権利確定スケジュールは終了し、残りのアンロック分はすべて投資家に払い戻されます。

Meeiro Shieldがプロジェクトと投資家に与える影響

権利確定セールは、明確な開発計画を持ち、長期的な成功を目指すプロジェクトに最適な手段です。プロジェクトが早期に安定し、略奪的な上昇＆下落を防止するのに役立ちます。これにより、プロジェクトが軌道に乗り、ユーザーや投資家にその有用性を証明する機会を確保することができます。

同様に、個人投資家向けの権利確定IDOは、フルアンロックIDOよりも懐疑的に捉えられることが多いです。これは、適切な管理体制がないまま、過去に一部のプロジェクトが権利確定IDOの仕組みを悪用したり、機能的なプロトコルとしての責任を果たさず、IDOの数ヶ月後のアンロック時に、投資家の手元には何も残らないくらいの価値になってしまったりしたからです。

Meeiro Shieldは、プロジェクトと投資家の双方にとって、この2つの痛手ポイントを解決します。Meeiroが立ち上げる意欲的で厳選されたプロジェクトが、立ち上げ戦略の中で権利確定のIDOを利用することを可能にし、同時にMeeiroの投資家を権利確定IDOに関連するあらゆるFUDから保護することができるのです。

🤝 MEE ステーキング

MEEの保有者は、トークンを当社のステーキングプールにステークすると、さまざまな特典を利用することができます。

• IDO セール

• ガバナンス

MEEトークンは、ステーキングページにステークすることで、プロトコル収益から利回りを得ることができます。プロトコル収益の一部は買い戻しに使われ、ステイカーに分配されます。

ステークされると、IDOへのアクセスと同様に当社のガバナンスプロセスに使用される$sMEEを受け取ることができます。

sMEEは、ステーキングを解除して請求できるようになるまで2週間の時間が必要です。アンステークプロセスを開始すると、トークンは2週間かけて直線的にアンロックされます。この間には利回りは発生せず、トークンはガバナンスやIDOへの参加に使用できません。

また、ユーザーは即座に撤退することも可能です。ただこれには15％のペナルティが付きます。つまり、Meeiroは$MEEトークンのステークされたポジションの、15%に相当する手数料を取ることになります。この手数料はDAOの収益に追加され、残りのステークホルダーへの報酬に使用されます。

ステーキングのAPYは、先週のAPYと累積APY(年間)で表示されます。多くの要因があるため、APYは指標であり、将来のパフォーマンスを反映するものではありません。

🏛 ガバナンス

Meeiro DAOの背後にある目標は、我々のコミュニティをすべての意思決定の中心に置くことです。DAOを導入することで、プリンシパル・エージェント問題に対する解決策を提供します。このジレンマは、個人またはグループが意思決定を行い、彼らのために行動する人々と優先順位が競合している場合に発生します。DAOは、コミュニティガバナンスを通じて、このジレンマを解決します。

DAOは、この2つのユーザー交流の中心になるのです。

• プロジェクトの投票：今後プロジェクトを立ち上げる前に、私たちはまずDAOの投票を通過させる予定です。もしコミュニティが、あるプロジェクトを立ち上げるに値しないと考えた場合、反対票を投じて拒否することができます。

• プロポーザル投票：財務管理、スマートコントラクトの更新など、Meeiroに関連するあらゆる種類の決定に適用できます。

DAOに参加するには？

DAOへの参加は$sMEE（ステークした$MEEを表すトークン）でアクセスでき、各$sMEEは1票に対応する。

🪙 トークノミクス

MEEネイティブAptos-トークン

$MEEトークンはAptosのネイティブトークンで、Aptosメインネットが稼動した時に発売される予定です。$MEEはMeeiroのプラットフォーム全体とガバナンスに力を発揮します。

権利確定と分配

トークンの供給量は50,000,000トークンに固定されており、トークンの最大流通量はこの量を超えることはありません。

トークン配布テーブル

$MEEトークンは、2,162,500MEEの初期流通供給量で発売される予定です。

$MEEトークノミクスは、その核となる部分が持続可能であるように設計されており、非循環トークンを使用したあらゆるタイプの報酬（流動性マイニング、ステーキング報酬など）を避けるように変換されています。その代わりに、ユーザーへの報酬に使用されるすべてのトークンは、トークンの高い希釈から私たちのトークン所有者とステーカーを保護し、オープンマーケットバイバック、またはインスタント引き出し手数料から来るでしょう。

私たちは、ユーザーに大量のトークンを与えることで、プラットフォームの使用とトークンの使用を抑制するのではなく、トークンに大きな有用性をもたらし、その普及を促進させることに賭けるのです。

MEEの初期流通量は2,162,500.00 MEEとなります。トークン価格は後日発表される予定です。

$MEE 流動性構築

流動性管理は、オンチェーンで発展するすべてのプロジェクトにおいて重要です。ほとんどのプロジェクトは、高速かつ「無料」であるため、イールドファーミングによってそれを構築します（プロジェクトは自身のトークンで流動性を直接借用します）。しかし、これは長期的に見るとプロジェクトにいくつかの弊害をもたらします。

• これは、トークンが継続的に市場に放出されることを意味し、その結果、トークンが大幅に希釈され、ほとんどの流動性プロバイダーが報酬を販売するため、常に売り圧力がかかることになります。

• 放出を停止すると、流動性プールの流動性はすべてすぐに削除されます。流動性プロバイダーは、AMMの無常な損失にさらされ続けるインセンティブがなくなってしまうからです。これにより、トークンのボラティリティが上昇し、市場の変動に対する耐性が弱くなります。

これを避けるために、私たちは独自の流動性を構築し、それをユーザーから買い取ります。つまり、ユーザーは、ネイティブなsMEEトークンと引き換えに、プラットフォームであるMEE-APTOS流動性プールトークン（LPトークン）を、割引価格で売却するオプションを持つことになるのです。これにより、ユーザーはIDOに低価格でアクセスできるようになり、MEE DAOはPOL（プロトコル自身の流動性）を高めることができるようになります。

なぜsMEEトークンを販売するのですか？

割引価格で販売されるMEEトークンは、販売するために14日間のロック解除を実行しなければなりません。これにより、直接的な利益を得るためだけにMEEを購入するマーセナリーを回避し、代わりにIDOに参加しようとする長期保有者に報いることができます。

プロトコル自身の流動性にはいくつかの利点がある。

• トークンの高騰を避ける。たとえこの結果、新しいトークンが市場に放出されたとしても、これらのトークンは既得権であり、流動性マイニングのように「無料で」得られるものではなく、ユーザーは購入しなければならない。

• 流動性はMeeiro.xyz DAOが所有し、買い戻しを止めても市場から消えることはないため、持続的な流動性を生み出すことができる。

デメリットは、イールドファーミングで構築した流動性と比較すると、流動性の構築に時間がかかることです。

また、MEE-APTOSを当社のステーキングに参加させることで、当社のIDOに参加できるようにします。これにより、IDOへのアクセスを得る能力を与えることで、流動性提供のインセンティブとなります。

$MEE 保有動機づけ

$MEEトークノミクスでは、新しいトークンを公開市場に導入することに関連する、多くのインセンティブを避けたいと考えています。そのため、私たちはインスタント引き出しによって獲得したトークンのみでステイカーに報酬を与え、DAOが直接所有する流動性を持つプロトコルの開発に力を注ぐことにしました。

主な保有動機づけは、IDOにアクセスできるMEEユーティリティであることは明らかです。

🛣 ロードマップ

Meeiro.xyzのロードマップのスケジュールは、私たちがプロジェクトに割り当てられるリソースと資金に完全に依存しています。ロードマップは4分の1に分割されています。

2022

Q2

✅ コンセプトの作成

✅ プラットフォーム／スマートコントラクトの定義

✅ 開発開始

✅ Meeiroブランディング開始

✅ ホワイトペーパー

✅ ピッチデッキ

Q3

✅ Meeiroブランディング最終決定

✅ ソーシャルメディア開設

◻️ ランディングページ公開

◻️ ディスコードオープン

Q4

◻️ プラットフォームライブ

◻️ MEE IDO

◻️ MEE TGE（トークン生成イベント）

◻️ DEX/CEXへのMEEリスティング

◻️ MEEのステーキングライブ

◻️ Meeiroでの初のIDO

2023

Q1

◻️ MEE流動性買い戻し開始 ◻️ IDO参加に向けたMEE LPトークンのステーキング

Q2

◻️ DAOライブ ◻️ MEE ガバナンス開始 ◻️ プロジェクトIDO ガバナンスによる投票

＊オリジナルのホワイトペーパーはこちら

https://docs.meeiro.xyz/

ここに記載された内容は、あくまでオリジナルを日本語訳にしたものであり、私KeiCryptoによるものではありません。著作権はオリジナルの作成者のものです。

The content herein is only a Japanese translation of the original and is not by me, KeiCrypto. The copyright belongs to the original author.

8月14日

8ヶ月ほど前、Sam WilliamsのMechanism Designに関するビデオ（下記リンク）に出会いました。このことがきっかけで、この分野に興味を持ち、特にSam自身が開発したデータストレージのブロックチェーンであるArweaveに興味を持つようになりました。私は、TwitterのコールドDMで、彼と一緒に仕事ができないかどうかコンタクトを取りました。その結果、彼と一緒に仕事ができることがわかりました。この数ヶ月、私はこれまでの人生の中で最も興味深い仕事をしました。😃

この投稿で、web3で実績を上げようとしている開発者やオペレーターに、Arweaveのエコシステムの大まかな概要をお伝えできればと思います。ブロックチェーン（Bitcoin/Proof-of-work）の基本的な理解を前提としています。この投稿はまた、先週ローンチした新しいイノベーションの文脈を設定し、今後のスレッドで概要を説明する予定です。この投稿の最後には、Arweaveに飛び込むのに役立つリソースのリストも集めました。

Arweaveを理解する

Arweaveは、歴史上初めて、知識の永久的なデジタルストアの作成を可能にします。アルウィーブを理解するためには、2つの基本的なことを理解する必要があります。

1. 分散型ストレージです。Arweaveにファイルをアップロードすると、世界中の多数のマイナーのハードディスクに複製され保存されます。これらのマイナーは、ビットコインにおける報酬と同様に、（マイニング中に）あなたのデータを保持していることを証明すると、ARトークンで報酬を得ることができます。ArweaveはProof-of-Accessと呼ばれるProof-of-Workの変種を採用しており、過去のデータのランダムなチャンクの保存を証明することが要求されます。

2. 寄付金モデル。Arweaveのストレージファイナンスは、永続的な寄附モデルで動いています。データをアップロードする際、200年分のストレージをAR（Arweaveのネイティブトークン）で前払いする。その大部分は寄付金となり、ブロックごとにデータの保存コストに比例して、時間の経過とともに採掘者に支払われる。ここで重要なのは、データの保存コストは技術の進歩により恒常的に低下していることです。この割合が0.5%であれば、0.005*200=1年なので、あなたの前払い金は永久的なものです。

この基本的なメンタルモデルがあれば、エコシステム内のプロジェクトに飛び込んでいくことができます。まずコアとなるインフラ・プロジェクトについて説明し、次にpermawebアプリやアトミック・アセットなど、Arweaveの他の興味深い開発について説明します。

インフラ

Bundlers

次の画像は、Arweaveのトランザクションの内容を示しています。ここで注目すべきは、quantityとdata_のフィールドです。この2つのフィールドは、Arweaveのトランザクションの2つのタイプ、転送（数量で表示）とデータアップロード（データで表示）のみを表しています。

{ "format": 2, "id": "3pXpj43Tk8QzDAoERjHE3ED7oEKLKephjnVakvkiHF8", "last_tx": "NpeIbi93igKhE5lKUMhH5dFmyEsNGC0fb2Qysggd-kM", "owner": "posmE...psEok", "tags": [], "target": "pEbU_SLfRzEseum0_hMB1Ie-hqvpeHWypRhZiPoioDI", "quantity": "10000000000", "data_root": "PGh0b...RtbD4", "data_size": "234234", "data": "VGVzdA", "reward": "321579659", "signature": "fjL0N...f2UMk" }

Arweaveでは、このようなトランザクションを1ブロックあたり1000件までと制限しており、これは平均ブロック時間2分の場合、約8tpsに相当します。これでは、すべての人のデータ保存の要件を満たすには十分ではありません。

これを解決するために、約1年前、Arweaveエコシステムの立ち上げ以来、おそらく最大のステップ機能改善として、ANS-104バンドル標準が定義されました。このサブトランザクション（DataItems）のフォーマットにより、トランザクションは多くのデータアップロードを1つに束ねて構築することができます。

Arweaveのベースレイヤーtxnとは対照的に、DataItemはこのような形をしています。

バンドルは様々なイノベーションを可能にするので、ここでは詳細を説明しませんが、signature_typeフィールドの出現に注目してください。データアイテムに任意のタイプの署名を許可することで、バンドルは任意のキーを使った署名を可能にします。

この機能により、bundlr.network（Arweaveの上にある最大のバンドルサービス）のようなバンドラーが、他のL1と統合することが可能になった。つまり、Arweaveのストレージにお金を払い、EthereumやSolanaなどの秘密鍵を使って署名することができるのです。Ever Financeが最近、ANS-104のバンドルをサービスとしてサポートするArseeding 1.0を出荷したように、現在では他のバンドルも出現しています。

まとめると、バンドルは

1. Arweaveデータのアップロードを任意にスケーリングできるようにします。

2. 他のブロックチェーンウォレットでArweaveデータへの署名と支払いを可能にする。

3. AR転送を行うことができない。

ゲートウェイ

Arweaveプロトコルはノード間でデータを共有するためのインセンティブが組み込まれていますが、このデータはしばしばハードディスクに保存され、瞬時に検索や問い合わせをするのに適しているとは言えません。

バンドルがデータをArweaveに取り込むためのデフォルトの方法であるなら、ゲートウェイはデータをArweaveから取り出すための方法です。ゲートウェイは、Arweaveに保存されたデータに素早く、きめ細かくアクセスする方法であり、リレーショナル・リード・データベースのような役割を果たすのです。

DMac（ArweaveのDiscordを見たことがある人なら知っていると思いますが）はゲートウェイをArweaveのデータレイクの上にあるデータウェアハウスに例えています。

これは便利な単純化ですが、ゲートウェイの機能はさまざまで、多くの場合、インデックス作成に加えて、Arweaveの上に以下のような多くのサービスを提供することになります。

• アンバンドリング

• トランザクション/ブロックヘッダークエリ(GraphQL経由)

• キャッシング

• セキュアソケット

• アプリのレンダリング

AR.IOチームは最近、デフォルトのarweave.netゲートウェイ（長年コミュニティに貢献してきた）を引き継ぎましたが、他にも多くのゲートウェイが構築されています。textury チームは最近独自のゲートウェイ・サービスをリリースしましたし、別のチームは Arweave 上でエンタープライズ・グレードのゲートウェイを構築しています。

Smartweave

Arweaveのスマートコントラクトは面白いデザインをしています。プロトコル自体は実行を指定せず、一般的なスマートコントラクトチェーンとは大きく異なりますが、スマートコントラクトは遅延評価を使って行われます。

ここで、Cは契約コードを含むtxnを表し、Iは初期状態を含むtxnを表し、Tsは契約と相互作用するトランザクションの順序付きリストを表します。状態は、Cのコード、Iの初期状態、および契約コードに基づくそれ以降のすべてのトランザクション（それが有効なトランザクションであることが前提）を使用して、クライアント上で遅延的に評価される。以下は設計の概要である。

Smartweaveはアーキテクチャであり、Arweave上で信頼性が高く高速で生産可能なスマートコントラクトエンジンを作るビジネスを行っている多くのエコシステムチームが存在します。その中で最も先進的なのは、おそらくRedstoneのWarp Smartweaveエンジンでしょう。Arweaveに来る新しいプログラマーのために、Redstoneはまた、絶対にチェックアウトする必要があります素晴らしいオンボーディングチュートリアルを持っています。

Arweaveのもう一つの新進気鋭のスマートウィーブエンジンは、ArConnect（最も有名なArweaveウォレット）の背後にあるチームと会社であるCommunity Labsによって構築された3emです。

バンドラー、ゲートウェイ、スマートウィーブという3つの基本インフラを理解すれば、Arweaveが可能にするすべてのことと、現在エコシステムで行われている興味深い開発を理解するために必要な構成要素を手に入れることができます。

エコシステム

最近の開発事例を紹介する前に、Arweaveのエコシステムと重要なユースケースについて簡単に説明します。

NFT

Arweaveの永続性の品質は、すべてのNFTプロジェクトのメタデータ＆メディアを暗号で保存するためのプラットフォームとして選ばれ続けていることを保証します。本格的なNFTプロジェクトは、そのデータが永久に保存され、永遠に利用できることを保証する必要があり、Arweaveは今日、これを可能にする唯一のブロックチェーンです。その結果、Solana NFTの圧倒的多数とEthereum NFTのかなりの部分がArweaveに恒久的に保存されています。

アトミックNFT

SmartWeaveとArweaveのデータアップロード機能を組み合わせると、データ（音楽/ビデオファイルまたは猿のJPEG）がそのメタデータと契約状態にアトミックにリンクされたNFTを作成することができます。これは、他のスマートコントラクトチェーンでは、「NFT」はメディアが実際に保存されている外部データソースにリンクする契約コードの一部に過ぎないのとは全く対照的です。これを図にすると以下のようになります。

タグについて

この機会にArweaveタグについて触れておきましょう。ArweaveタグはArweaveのユニークな機能で、データと任意のメタデータを同じトランザクションIDでリンクさせることができます。つまり、Arweave、ひいてはパーマウェブ上に保存されているあらゆるデータは、そのメタデータとアトミックにリンクされているのです。

これにより、（Atomic NFTのように）契約状態とデータを関連付ける、ライセンスなどの機能が可能になります。

Permaweb

Arweaveのエコシステムに長く携わっている方なら、「Permaweb」という言葉を聞いたことがあるのではないでしょうか。Permawebとは、相互にリンクされたウェブアプリケーション、ファイル、メディアのコレクションで、これらはすべてArweave上に永久に保存され、変異することなく永遠に（ゲーム理論的に保証されて）存在し続けます。これは、Arweave上に構築された分散型パーマネント・ウェブです。このように、Arweave上のアプリケーションは、一度デプロイされると、現在の形で永遠に使用することができるのです。Naderの超構造体/アプリケーションの説明と、texturyの非常に役に立つpermaweb dropperで、簡単なpermawebアプリケーションの例をチェックしてみてください。また、Permaweb wikiもチェックしてみてください。

permawebはどのように動くのですか？Arweaveゲートウェイは、トランザクションに保存されたデータを使ってウェブアプリをレンダリングします。完全なウェブアプリを、ウェブアプリのレンダリング方法を指定するマニフェストとともにアップロードすることができます。

TL;DR. 2007年のGmailがpermawebアプリケーションとしてデプロイされていたなら（あなたの活動や情報を悪用することを許す条件なしで）、今日、あなたはすべての個人データを彼らに共有し、彼らがそれを売ることでマネタイズすることはなかったでしょう。

Apps

Permawebアプリケーションや、ストレージにArweaveを使用するアプリケーションは、ここで詳しく紹介しきれないほどたくさんあります。例えば、permapages, akord, pianity, ardrive, permacastなどです。

今回はここまでです。このArweaveの概要が参考になった方は、この記事をWeb3/ブロックチェーン開発者仲間とシェアして、もっと知りたいことを以下（オリジナルの記事にシェアのボタンがあります）に教えてください。

＊オリジナルの記事はこちら

https://abhav.substack.com/p/arweave-state-of-the-ecosystem?utm_source=substack&utm_medium=email&utm_content=share

ここに記載された内容は、あくまでオリジナルを日本語訳にしたものであり、私KeiCryptoによるものではありません。著作権はオリジナルの作成者のものです。

The content herein is only a Japanese translation of the original and is not by me, KeiCrypto. The copyright belongs to the original author.

１　はじめに

Suiは、アセットの低レイテンシー管理に特化した、パーミッションレスの分散型スマートコントラクトプラットフォームです。Suiは、Moveプログラミング言語を使用して、アセットをアドレスが所有する可能性のあるオブジェクトとして定義しています。Moveプログラムは、これらの型付けされたオブジェクトに対して、その作成、新しい所有者へのこれらのアセットの譲渡、およびアセットを変異させる操作のためのカスタムルールを定義します。

Suiは、他のブロックチェーンシステムにおけるバリデーターやマイナーのような役割を果たす、無許可の当局によって維持されています。資産に対する共通の操作の安全性を確保するために、当局間の Byzantine consistent ブロードキャストプロトコルを使用し、Byzantine協定と比較して、低レイテンシーと優れたスケーラビリティを確保します。共有オブジェクトの安全性については、Byzantine合意にのみ依存しています。ガバナンス操作やチェックポイントと同様に、クリティカルなレイテンシーパスを外れて実行されます。スマートコントラクトの実行も、可能な限り自然に並列化されます。Suiは、読み取りを認証できるライトクライアントと、完全性のためにすべてのトランジションを監査できるフルクライアントをサポートしています。これらの設備により、他のブロックチェーンへの信頼最小化の橋渡しが可能です。

ネイティブアセットSUIは、すべての操作のためのガス代を支払うために使用されます。また、その所有者は、エポック内でSuiを操作するために当局にステークを委任するために使用され、定期的に当局は委任されたステークに従って再構成されます。使用済みのガスは、ステークとSuiの運用への貢献度に応じて、当局とその委任者に分配されます。

このホワイトペーパーは2部構成になっており，第2章ではMove言語を用いたSuiのプログラミングモデルについて、第4章ではSuiの安全性、活性化、性能を保証するパーミッションレス分散型システムの運用を説明します。

２　SUIスマートコントラクトのプログラミング

SuiスマートコントラクトはMove言語で書かれています。Moveは安全で表現力が豊かであり、その型システムとデータモデルは、Suiをスケーラブルにする並列合意/実行戦略を自然にサポートします。Moveは、もともとFacebookでDiemブロックチェーン用に開発されたスマートコントラクト構築用のオープンソースプログラミング言語です。この言語はプラットフォームに依存せず、Suiに採用されただけでなく、他のプラットフォーム（0L、StarCoinなど）でも人気を博しています。

このセクションでは、Move言語の主な特徴について説明し、それがSui上の資産の作成と管理にどのように使用されているかを説明します。Moveの機能のより詳細な説明はMove Programming Language bookに、よりSuiに特化したMoveの内容はSui Developer Portalにあります。また、Suiの文脈におけるMoveのより正式な説明は第3章にあります。

２.１　概要

Suiのグローバル状態には、Move関数と型を含むMoveモジュール（詳細は2.1.1項参照）の集合体であるMoveパッケージによって生成、管理されるプログラマブルオブジェクトのプールが含まれています。移動パッケージ自体もオブジェクトです。したがって、Suiオブジェクトは次の2つに分類されます。

• 構造体データ値 ：Moveモジュールが管理する型付きデータ。各オブジェクトは、プリミティブ型（整数、アドレスなど）、他のオブジェクト、非オブジェクトの構造体を含むことができるフィールドを持つ構造体値です。

• パッケージコード値：関連するMoveバイトコードモジュールの集合で、原子単位として発行されます。パッケージ内の各モジュールは、そのパッケージ内の他のモジュールと、以前に公開されたパッケージのモジュールとの両方に依存することができます。

オブジェクトは、アセット（例：ファンジブル、またはノンファンジブルトークン）、特定の関数を呼び出したり他のオブジェクトを作成したりする権限を付与する機能、他のアセットを管理する「スマートコントラクト」などをコード化できます（決定するのはプログラマー次第です）。カスタムSuiオブジェクトタイプを宣言するMoveコードは、次のようになります。

struct Obj has key { id: VersionedID, // globally unique ID and version f: u64 // objects can have primitive fields g: OtherObj // fields can also store other objects }

２.１.１　モジュール

Moveプログラムは、構造体宣言と関数宣言のリストからなるモジュールの集合として構成されます。モジュールは、他のモジュールから構造体をインポートしたり、他のモジュールが宣言した関数を呼び出すことができます。

例えば、上の例のモジュール OtherObj は、Obj を定義しているモジュールとは別のモジュールで定義することができます。 これは、契約の境界を越えて流れることができるのは非構造化バイトだけである、多くのスマートコントラクト言語とは異なる点です。しかし、Moveは、プログラマが堅牢で安全なコードを書けるようにカプセル化機能を提供しているため、これをサポートすることができるのです。具体的には、Moveの型システムは、上記の Obj のような型は、その型を宣言したモジュール内部の関数によってのみ生成、破壊、コピー、読み込み、書き込みができることを保証しています。これにより、モジュールは宣言された型に対して、スマートコントラクトの信頼境界を越えて流れても保持され続ける強い不変性を強制することができます。

２.１.２　トランザクションとエントリーポイント

グローバルオブジェクトプールは、オブジェクトの作成、破棄、読み取り、書き込みが可能なトランザクションによって更新されます。トランザクションは、操作を希望する既存の各オブジェクトを入力として受け取らなければなりません。さらに、トランザクションは、パッケージオブジェクトのバージョンID、そのパッケージ内のモジュール名と関数名、関数への引数（入力オブジェクトを含む）を含める必要があります。例えば、

public fun entrypoint( o1: Obj, o2: &mut Obj, o3: &Obj, x: u64, ctx: &mut TxContext ) { ... }

という関数を呼び出す場合、トランザクションは、タイプがObjである3つの異なるオブジェクトのIDと、xにバインドするための整数を提供しなければなりません。TxContextはランタイムによって満たされる特別なパラメータで、送信者アドレスと新しいオブジェクトを作成するために必要な情報を含んでいます。

エントリーポイントへの入力は（より一般的には Move関数への入力も）、型にエンコードされた異なる変更許可を持って渡されることがあります。Obj 入力は、読み取り、書き込み、転送、破棄が可能です。&mut Obj 入力は、読み取りまたは書き込みのみ可能で、&Objは読み取りのみ可能です。トランザクションの送信者は、指定されたミュータビリティパーミッションで各入力オブジェクトを使用する権限がなければなりません。

２.１.３　オブジェクトの作成と転送

プログラマーは、エントリーポイントに渡された TxContext を使用して、オブジェクトの新鮮なIDを生成することにより、オブジェクトを作成することができます。

public fun create_then_transfer( f: u64, g: OtherObj, o1: Obj, ctx: &mut TxContext ) { let o2 = Obj { id: TxContext::fresh_id(ctx), f, g }; Transfer::transfer(o1, TxContext:sender()); Transfer::transfer(o2, TxContext:sender()); }

このコードは、OtherObj 型と Obj 型の2つのオブジェクトを入力として受け取り、最初のオブジェクトと生成されたIDを使用して新しい Obj を作成し、両方の Obj オブジェクトをトランザクション送信者に転送します。オブジェクトが転送されると、それはグローバルオブジェクトプールに流れ、トランザクションの残りの部分のコードによってアクセスされることはありません。TransferモジュールはSui標準ライブラリの一部で、オブジェクトをユーザアドレスや他のオブジェクトに転送するための関数が含まれています。 もしプログラマーコードが転送呼び出しの一つを含むことを怠った場合、このコードはMove型システムによって拒絶されることに注意してください。Moveは、オブジェクトが勝手に作られたり、コピーされたり、誤って破壊されたりしないように、リソースセーフティ保護を実施しています。リソースセーフティのもう一つの例として、同じオブジェクトを2回転送しようとすると、これもMoveタイプシステムによって拒否されます。

３　SUIプログラミングモデル

本節では、第2章で述べたSuiプログラミングモデルの非公式な記述を発展させ、 詳細な意味的定義を示します。前節ではMoveのソースコードの例を示したが、ここではMoveのバイトコードの構造を定義します。開発者は、ローカルでMoveソースコードを記述し、テストし、形式的に検証します。Moveソースコードをローカルで書き、Moveバイトコードにコンパイルしてからブロックチェーンに公開します。ブロックチェーン上で公開されるMoveバイトコードは、型、メモリ、リソースの安全性といった主要な特性を満たすことを保証するために、バイトコード検証器を通過する必要があります。 第2章で述べたように、Moveはプラットフォームに依存しない言語であり、コア言語をフォークすることなく、異なるシステムの特定のニーズに適合させることができます。以下の説明は、Move言語のコアとなる概念（黒文字で表記）と、Moveのコアとなる言語を拡張するSui独自の機能（オレンジ色の文字で示す）です。

Moveコードは、表1に定義された構造を持つモジュールに編成されています。モジュールは、名前付き構造体宣言と名前付き関数宣言の集合から構成されます（これらの宣言の例は2.1節で説明しています）。また、モジュールはモジュール初期化子として特別な関数宣言を含んでいます。この関数は、モジュールがオンチェーンで公開されるときに一度だけ呼び出されます。

構造体宣言は、フィールド名が格納可能な型にマッピングされた、名前付きフィールドの集合体です。構造体宣言には、オプションで能力のリストも含まれます（格納可能な型と能力の説明については、第2章を参照してください）。構造体宣言には、能力制約を持つ汎用的なパラメーターのリストを含めることもでき、例えば、 struct Wrapper<T: copy>{ t: T } のような場合は、汎用構造体宣言と呼びます。ジェネリック・パラメーターは、構造体フィールドの宣言時に使われる型を表します。構造体宣言時には未知数で、構造体のインスタンス化時（つまり、構造体の値が生成される時）に具体的な型が提供されます。

関数宣言には、パラメータの型、戻り値の型、関数本体を構成する命令のリストが含まれます。関数宣言には、能力制約のある一般的なパラメーターのリストを含めることもでき、その場合は、例えば、 fun unwrap<T: copy>(p: Wrapper){} のような場合は、一般関数宣言と呼んでいます。構造体宣言と同様に、汎用パラメータは、関数宣言時には未知の型ですが、関数パラメータ、戻り値、関数本体（具体的な型は関数が呼ばれたときに提供されます）を宣言するときに使われる型を表します。 関数本体で使用できる命令には、グローバルストレージ命令（move_to, move_from, borrow_global など）を除く、通常のすべてのMove命令が含まれます。コアMoveの命令とそのセマンティクスの完全なリストについては[Marco Patrignani and Sam Blackshear. 2021. Robust Safety for Move. CoRR abs/2110.05043 (2021). arXiv:2110.05043 https://arxiv.org/abs/2110.05043\] を参照してください。Suiでは、コアMoveのアカウントベースのグローバルストレージではなく、Suiのグローバルオブジェクトプールを介して永続ストレージがサポートされています。 Sui特有のオブジェクト操作は4つあります。これらの操作はそれぞれオブジェクトの所有権メタデータを変更し（3.3節参照）、それをグローバルなオブジェクトプールに戻します。最も簡単には、SuiオブジェクトはSuiエンドユーザーのアドレスに転送することができます。オブジェクトは別の親オブジェクトに転送することもできます。この操作では、呼び出し側が、子オブジェクトに加えて、親オブジェクトへの変更可能な参照を与える必要があります。最後に、オブジェクトはSuiシステム内の誰でも読むことができるが、誰でも書くことができないように、不変に共有することができます。 異なる種類の所有権を区別する機能は、Suiのユニークな機能です。私たちが知っている他のブロックチェーン・プラットフォームでは、すべての契約とオブジェクトはミュータブルに共有されています。セクション4で説明するように、Suiはこの情報を活用して、（すべてのトランザクションの）並列トランザクション実行と（共有されたミュータビリティを持たないオブジェクトを含むトランザクションの）並列合意を実現します。 ３.２　タイプとアビリティ 表2：タイプとアビリティ Moveプログラムは、Suiグローバルオブジェクトプールに格納されたデータと、Moveプログラムの実行時に作成されるトランジェントデータの両方を操作します。オブジェクトもトランジェントデータも言語レベルではMoveの値です。しかし、すべての値が同じように作られるわけではなく、型によって規定された異なる特性や異なる構造を持つ場合があります。 Moveで使用される型は表2に定義されています。Moveは他のプログラミング言語でサポートされているものと同じプリミティブ型、例えばブーリアン型や様々な大きさの符号なし整数型などを多くサポートしています。さらに、Moveのコアには、システム内のエンドユーザーを表すアドレス型があり、これはトランザクションの送信者や（Suiでは）オブジェクトの所有者を特定するのにも使われます。最後に、SuiはSuiオブジェクトのIDを表すid型を定義しています（詳細は3.3節を参照）。 struct type は、あるモジュールで宣言された構造体（構造体宣言については第3.1節を参照）の インスタンス（すなわち値）を記述するものです。一般的な構造体宣言（generic struct type）を表す構造体タイプには、格納可能なタイプのリストが含まれます。このリストは、構造体宣言の一般的なパラメータリストと対応するものです。格納可能な型には、具象型（プリミティブ型、構造体型）、汎用型のいずれかがあります。このような型をストア（保存）可能型と呼びますが、これは、参照型がストアできないのに対して、 構造体のフィールドやオン・チェーンで永続的に保存されるオブジェクトに表示することができるからです。 例えば、Wrapper構造体型は、格納可能な具象（プリミティブ）型u64をパラメータとする汎用構造体型で、この型は、構造体のインスタンス(値)を生成するために使用することができます。一方、同じ汎用構造体でも、囲む構造体や関数宣言の汎用パラメータから来る汎用型（例えば、struct Parent { w: Wrapper }）でパラメータ化でき、この種の型は、構造体フィールドや関数パラメータなどの宣言に使うことができます。構造的には、汎用型は、構造的には、汎用型は、構造体または関数宣言を包含する汎用パラメータリストへの整数インデックス（表5でNと定義）である。 Moveのベクトル型は、均質な値の可変長の集合を記述します。ベクトル型は、格納可能な型のみ格納でき、それ自体も格納可能な型です。 Moveプログラムでは、値を直接操作することも、参照を介して間接的にアクセスすることもできます。参照型は参照される保存可能な型と、与えられた型の値が読み書きができる (mut) か読み出しのみができる (immut) かを決定（強制）するために使われる変異性修飾子の両方を含んでいます。その結果、Moveの値型（表2のType）の最も一般的な形は、保存可能な型でも参照可能な型でもよいのです。 最後に、Moveの能力は、与えられた型の値をコピー（複製）できるかどうかなど、与えられた型の値に対してどのような動作が許されるかを制御します。アビリティは構造体宣言と汎用型パラメータを制約します。Moveバイトコードベリファイアは、コピーなどの重要な操作が対応する能力を持つ型に対してのみ実行可能であることを保証する責任を負っています。 ３.３　オブジェクトと所有権 表3：オブジェクトと所有権 各Suiオブジェクトはグローバルに一意な識別子（表3のObjlD）を持ち、所有者間や他のオブジェクトとの間でフローする際に、オブジェクトの永続的なアイデンティティとして機能します。このIDは、オブジェクトを作成するトランザクションによってオブジェクトに割り当てられます。オブジェクトIDは、現在のトランザクションのコンテンツと、そのトランザクションが作成したオブジェクトの数を記録するカウンターに、耐衝突性のハッシュ関数を適用して作成されます。トランザクション（したがってそのダイジェスト）は、後で説明するように、トランザクションの入力オブジェクトに対する制約により一意であることが保証されます。 IDに加え、各オブジェクトはその所有権に関するメタデータを持ちます。オブジェクトは、アドレスまたは他のオブジェクトによって一意に所有されるか、書き込み/読み取り権限で共有されるか、読み取り権限のみで共有されるかのいずれかです。オブジェクトの所有権は、トランザクションがそれを入力として使用できるかどうか、またどのように使用できるかを決定します。大まかには、一意に所有されるオブジェクトは、その所有者によって開始されたトランザクション、またはその親オブジェクトを入力として含むトランザクションにおいてのみ使用できます。一方、共有オブジェクトは任意のトランザクションによって使用できるが、特定の変更可能性パーミッションによってのみ使用できます。完全な説明は第4.4節を参照してください。 オブジェクトには、パッケージコードオブジェクトと構造体データオブジェクトの2種類があります。パッケージオブジェクトには、モジュールのリストが含まれます。構造体オブジェクトには、Move構造体の値とその値のMove型が含まれます。オブジェクトの内容は変化しても、そのID、オブジェクトの型（パッケージか構造体か）、Move構造体の型は不変です。これにより、オブジェクトは強く型付けされ、永続的なアイデンティティを持つことが保証されます。 最後に、オブジェクトはバージョンを持っています。生成されたばかりのオブジェクトはバージョン0であり、トランザクションがオブジェクトを入力として受け取るたびに、オブジェクトのバージョンはインクリメントされます。 ３.４　アドレスと認証子 表4：アドレスと認証子 アドレスは、Suiのエンドユーザーの永続的なアイデンティティです（ただし、1人のユーザーが任意の数のアドレスを持つことができることに注意してください）。オブジェクトを他のユーザーに転送するには、送信者は受信者のアドレスを知っている必要があります。 後ほど説明しますが、Suiのトランザクションは、トランザクションを送信する(すなわち、開始する)ユーザーのアドレスと、そのアドレスにダイジェストがマッチする認証子を含まなければなりません。アドレスと認証子を分離することで、暗号の俊敏性を高めることができます。認証子は、たとえ異なる鍵長を使用する署名方式であっても(例：ポストクアンタム署名をサポートするため)、任意の署名方式の公開鍵にすることができます。さらに、認証子は単一の公開鍵である必要はなく、(例えば) K-of-Nマルチシグナル鍵であっても大丈夫です。 ３.５　トランザクション 表5：トランザクション Suiには、新しいMoveパッケージの公開と、既に公開されているMoveパッケージの呼び出しという2つの異なるトランザクションタイプがあります。公開トランザクションは、パッケージ（単一のオブジェクトとして一緒に公開されるモジュールのセット）と、このパッケージ内のすべてのモジュールの依存関係（すでに公開されたパッケージオブジェクトを参照する必要があるオブジェクト参照のリストとしてエンコードされる）を含みます。公開トランザクションを実行するために、Suiランタイムは各パッケージに対してMoveバイトコード検証を実行し、パッケージをその依存関係に対してリンクし、各モジュールのモジュール初期化器を実行する。モジュールイニシャライザーは、パッケージによって実装されたアプリケーションの初期状態をブートストラップするのに有用です。 コールトランザクションの最も重要な引数は、オブジェクトの入力です。オブジェクトの引数は、オブジェクト参照（単一所有者および共有不変オブジェクトの場合）またはオブジェクトID（共有可変オブジェクトの場合）で指定します。オブジェクトリファレンスは、オブジェクトID、オブジェクトバージョン、オブジェクト値のハッシュから構成されます。Suiランタイムは、オブジェクトIDとオブジェクト参照の両方を、グローバルオブジェクトプールに格納されたオブジェクト値に解決します。オブジェクト参照の場合、ランタイムは参照のバージョンをプール内のオブジェクトのバージョンと照合し、また、参照のハッシュがプールオブジェクトと一致するかどうかを確認します。これにより、ランタイムのオブジェクトに対する見解が、トランザクション送信者のオブジェクトに対する見解と一致することが保証されます。 さらに、呼び出しトランザクションは、型引数および純粋な値引数を受け入れます。型引数は、呼び出されるエントリポイント関数の汎用型パラメータをインスタンス化する（例えば、エントリポイント関数が send_coin(c: Coin, ...) の場合、汎用型パラメータTは、Suiネイティブトークンを送るための型引数SUIでインスタンス化することが可能です）。純粋な値にはプリミティブ型とプリミティブ型のベクトルを含めることができますが、構造体型は含められません。 呼び出しによって呼び出される関数は、オブジェクト参照（パッケージオブジェクトを参照しなければならない）、そのパッケージのモジュール名、そのパッケージの関数名によって指定されます。呼び出しトランザクションを実行するために、Suiランタイムは関数を解決し、型、オブジェクト、および値の引数を関数パラメータにバインドし、Move VMを使用して関数を実行します。 コール・トランザクションとパブリッシュ・トランザクションの両方が、ガス・メータリングとガス料金の対象となります。メータリングの上限は、最大ガスバジェットで表されます。ランタイムはバジェットに達するまでトランザクションを実行し、バジェットを使い果たした場合は（手数料を差し引き、アボートコードを報告する以外）何もせずにアボートします。 手数料は、オブジェクト参照として指定されたガスオブジェクトから差し引かれます。このオブジェクトはSuiネイティブトークンでなければなりません（つまり、そのタイプはCoinでなければなりません）。SuiはEIP15594スタイルの手数料を使用しています。プロトコルは、エポック境界でアルゴリズム的に調整される基本手数料（Suiトークンごとのガス単位で表示）を定義し、トランザクションの送信者はオプションのチップ（Suiトークン単位で表示）も含むことができます。通常のシステム負荷であれば、チップなしでも取引は迅速に処理されます。しかし、システムが混雑している場合は、より多くのチップを含む取引が優先されます。ガス・オブジェクトから差し引かれる料金は、（GasUsed * BaseFee） + Tip となります。 ３.６　トランザクションの効果 表6：トランザクションの効果 トランザクションの実行は、トランザクションの実行が成功した場合（表6のSuccessEffects）と失敗した場合（表6のAbortEffects）とで異なるトランザクション効果を発生させます。 トランザクションが正常に実行されると、トランザクションの効果には、Suiのグローバルオブジェクトプールに加えられた変更に関する情報（既存のオブジェクトに対する更新と新しく作成されたオブジェクトの両方を含む）と、トランザクション実行中に生成されたイベントが含まれます。トランザクションの実行が成功した場合の別の効果として、グローバルプールからのオブジェクトの削除（すなわち、削除）と、あるオブジェクトを別のオブジェクトにラップ（すなわち、埋め込み）することができます。これは削除と同様の効果があり、ラップしたオブジェクトはグローバルプールから消え、それをラップしたオブジェクトの一部分としてのみ存在することになります。削除されたオブジェクトやラップされたオブジェクトはグローバルプールからアクセスできなくなるので、これらの効果はオブジェクトのIDとバージョンで表現されます。 イベントは、グローバルオブジェクトプールの更新を超えた、トランザクションの正常な実行の副次的効果を符号化します。構造的に、イベントはMove構造体とその型から構成されます。イベントはブロックチェーン外のアクターによって消費されることを意図していますが、Moveプログラムによって読み取られることはありません。 Moveのトランザクションはall-or-nothingのセマンティクスを持ちます。トランザクションの実行がある時点で中断した場合（例えば、予期せぬ障害によって）、その時点以前にオブジェクトへの何らかの変更が起こっていた（あるいは何らかのイベントが生成されていた）としても、これらの効果は中断したトランザクションには持続しません。その代わり、中断されたトランザクションの効果には、数値の中断コードとトランザクションの中断が発生したモジュールの名前が含まれます。ガス料金は、中断されたトランザクションに対して引き続き課金されます。 ４　SUIシステム 本節では、Suiをシステムの観点から説明します。Byzantine障害にもかかわらず、権威間の安全性と活性を保証する機構を含みます。また、システムの完全な状態を検証することなく、システムの状態について何らかの保証を必要とするライトクライアントを含む、クライアントの動作について説明します。 簡単な背景　システムレベルでは、SuiはFastPayの低遅延決済システムを進化させたもので、ユーザー定義のスマートコントラクトを通じて任意のオブジェクトで動作するように拡張し、許可なしの委任証明によるプルーフ・オブ・ステーク コミッティ構成で構成しています。オブジェクト所有者による基本的な資産管理は、Byzantine合意の従来の実装と比較してレイテンシーが低く、多くのマシン間でスケールしやすいByzantine一貫ブロードキャストの変種に基づいています。完全合意が必要な場合、異なる共有オブジェクトでの実行は並列化されていますが、ロック管理のために高処理DAGベースの合意、例えば [George Danezis, Eleftherios Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2021. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. CoRR abs/2105.11827] を使用します。 プロトコルの概要　図1は、トランザクションをコミットするための、クライアントとSui当局間の高レベルなインタラクションを示す図です。ここでは、それらを簡単に説明します。 秘密署名鍵を持つユーザーは、Sui内で自分が所有するオブジェクトや共有オブジェクトを変異させるためのユーザートランザクションを作成し、署名します。その後、ユーザー署名鍵は不要となり、残りの処理はユーザー・クライアント、またはユーザーに代わってゲートウェイが行うことができます（図ではキーレス操作と表記）。 ユーザトランザクションはSui当局に送られ、当局はそれぞれトランザクションの有効性をチェックし、成功したら署名してクライアントに署名付きトランザクションを返します。クライアントは、トランザクション証明書を形成するために、当局の定数から 応答を収集します。 トランザクション証明書は次にすべての機関に送り返され、もしトランザクションが共有オブジェクトを含んでいれば、それはSui機関によって運営されるByzantine合意プロトコルにも送られます。当局は証明書をチェックし、共有オブジェクトが関与している場合には、合意プロトコルが他の共有オブジェクトトランザクションとの関連でそれをシーケンスするのを待ち、その後トランザクションを実行し、その効果を署名された効果応答にまとめます。 当局の定足数が証明書を実行すると、その効果は最終的なものとなります（図では最終と表記されています）。クライアントは、権限応答の定足数を集めて効果証明書を作成し、それをトランザクション効果の最終性の証明として使用することができます。 このセクションでは、これらの各操作の詳細と、当局間で状態を再構成および管理するための操作について説明します。 ４.１　システムモデル Suiは、𝑒 ∈ {0, . . .}で示される一連のエポックにおいて動作します。各エポックは委員会𝐶𝑒 = (𝑉𝑒, 𝑆𝑒 (·)) によって管理され，ここで 𝑉𝑒 は既知の公開検証キーとネットワークエンドポイントを持つ権威の集合です。関数 𝑆𝑒 (𝑣) は，各権威 𝑣 ∈ 𝑉𝑒 t を委任されたステークの単位数に対応付けます。各エポックの 𝐶𝑒 は，エポックe-1における権威ステークのクォーラム（下記参照）により署名されていると仮定します(4.7節で委員会の形成と管理について述べます)。エポック内では，ある権威は正しく（プロトコルに忠実に従い，生きている）、ある権威はByzantine（プロトコルから任意に逸脱する）です。安全性の仮定は、正直な当局の集合 𝐻𝑒 ⊆ 𝑉𝑒 はエポック内でステークがクォーラムに割り当てられること、すなわちi.e. Í ℎ∈𝐻𝑒 𝑆𝑒 (ℎ) > 2/3 Í 𝑣∈𝑉𝑒 𝑆𝑒 (𝑣) (そして、3分の2以上のステークを持つ当局の集合をクォーラムと呼ぶ)であることです。 正直な当局間の各証明書(4.3節参照)のリレーとして機能する、少なくとも1つの生きていて正しいパーティが存在します。これは、ライブ性を保証し、ビザンチン放送に最終的な配信特性を提供します(参考文献[Christian Cachin, Rachid Guerraoui, and Luís Rodrigues. 2011. Introduction to reliable and secure distributed programming. Springer Science & Business Media]の信頼できる放送の全体像)。各権威はこのようなリレーを、個別に、または集合的な発信プロトコルを介して運用します。また、Suiライトクライアント、レプリカ、サービスなどの外部エンティティもこの役割を担うことがあります。受動的な権威の中核と、信頼性や信用度の低い内部または外部の能動的な中継コンポーネントを区別することで、Suiの安全性と活気に依存するトラステッドコンピューティング基盤を明確に区分し、最小化することを保証しているのです。 ４.２　権限とレプリカのデータ構造 Sui権限では、状態を表現するために多くのデータ構造に依存しています。我々は、これらの構造を、それらがサポートする操作に基づいて定義します。これらはすべて決定論的なバイト表現を持っています。 オブジェクト（Obj）は、ユーザーのスマートコントラクトとデータをSui内に保存します。これは、第2章で紹介したMoveオブジェクトをSuiのシステムレベルでエンコードしたものです。 図1：トランザクションをコミットするためのインタラクションの概要。 ref(Obj)は、オブジェクトの参照（ObjRef）、すなわちトリプレット（ObjID, Version, ObjDigest）を返します。ObjlDは新しく作成されるすべてのオブジェクトに対して実質的に一意であり、Versionは変異しているオブジェクトのバージョンを表す正の増加する整数です。 owner(Obj) は、そのオブジェクトの所有者の認証子 Auth を返します。最も単純なケースでは、 Auth はアドレスで、このオブジェクトを使用することができる公開鍵を表します。より複雑な認証子も利用可能です (4.4節を参照ください)。 read-only(Obj) はオブジェクトが読み取り専用であれば真を返します。読み取り専用のオブジェクトは決して変異させたり、ラップしたり、削除したりすることはできません。また、その所有者だけでなく、誰でも使用することができます。 parent(Obj) は、オブジェクトを最後に変異または作成したトランザクションダイジェスト (TxDigest) を返します。 contents(Obj)は、トランザクションの有効性を確認し、オブジェクトのアプリケーション固有の情報を運ぶために使用できるオブジェクトのタイプTypeとデータDataを返します。 オブジェクト参照（ObjRef）は、オブジェクトのインデックスを作成するために使用されます。また、ObjDigestはその完全な内容に対するコミットメントであるため、オブジェクトを認証するためにも使用されます。 トランザクション（Tx）は、1つまたは複数のオブジェクトの状態遷移を表す構造体である。これらは以下の操作のセットをサポートします。 digest(Tx)はTxDigestを返します。これは、トランザクションに対する拘束力の あるcryptoグラフィックのコミットメントです。 epoch(Tx) は、このトランザクションが実行される可能性のあるエポキシドを返します。 inputs(Tx) は、トランザクションの実行に必要なオブジェクト(ObjRef)の列を返します。 payment(Tx) は、ガス料金の支払いに使用される ObjRef への参照と、ガス料金の上限、およびガス料金の単位とガス料金のオブジェクトの値の単位との間の変換レートを返します。 valid(Tx, [Obj]) は、提供された要求された入力オブジェクトが与えられたときに、トランザクショ ンが有効であればtrueを返します。有効性については4.4節で説明します。4.4節で議論され、トランザクションが入力オブジェクトに作用することを承認されていること、およびその実行コストをカバーするために十分なガスが利用可能であることに関連します。 exec(Tx, [Obj]) はトランザクションを実行し、その効果を表す構造体を返します。有効なトランザクションの実行は確実であり、その出力は決定論的です。 取引はそのTxDigestによってインデックス化され、それはまたその全内容を認証するために使用されるかもしれません。すべての有効なトランザクション(特別にハードコードされたgenesisトランザクションを除く)は、少なくとも1つの所有する入力、すなわち、ガス代を支払うために使用するオブジェクトを持ちます。 トランザクション効果(Effects)構造体は、トランザクション実行の結果を要約します。これは、以下の操作をサポートする。 digest(Effects) は、Effects 構造体へのコミットメント EffDigest であり、インデックス付けや認証に使用されることがあります。 transaction(Effects) は、効果をもたらす実行されたトランザクションのTxDigestを返します。 dependencies(Effects) は、これらの効果を持つトランザクションが実行される前に実行される べき依存関係 [TxDigest] のシーケンスを返します。 contents(Effects)は、実行の概要を返す。Statusは、スマートコントラクトの実行結果を報告します。Created、Mutated、Wrapped、Unwrapped、Deletedの各リストは、それぞれの操作を受けたオブジェクト参照をリストアップしています。そして、Events は、実行によって発行されたイベントをリストアップします。 トランザクションに関するトランザクション証明書 TxCert は、トランザクション自体と、 権威の定足数からの識別子と署名を含みます。同じ論理的な証明書が、定足数を形成する異なるセットの機関によって表 現されるかもしれないという点で、証明書は一意ではないかもしれないことに注意します。さらに、証明書は厳密には定足数の3分の2以上によって署名されないかもしれませんが、より多くの当局が応答する場合はそれ以上となる可能性もあリマス。しかし、同じトランザクション上の2つの異なる有効な証明書は、意味的に同じ証明書を表すものとして扱われるべきです。部分証明書(TxSign)は、同じ情報を含みますが、要求される定足数よりも低いステークを表す当局の集合からの署名で、通常は単一の当局であす。署名者の識別子は、証明書を処理する準備ができている権威を識別するために、または証明書を処理するために必要な過去の情報をダウンロードするために使用されるかもしれない証明書（説明可能な署名[？]）に含まれています（4.8項参照）。 同様に、エフェクト構造上のエフェクト証明書 EffCert は、エフェクト構造それ自体と、トランザクションが有効なエポックの定足数を代表する当局からの署名を含みます。非一意性と同一性については、トランザクション証明書と同じ注意事項が適用されます。部分的なエフェクト証明書は、通常、単一の機関の署名とエフェクト構造を含み、EffSign と表記されます。 永続的なストア　各権威とレプリカは，永続ストアのセットを保持します。ストアは永続的なマップセマンティックを実装しており，キーと値のペアのセット (𝑚𝑎𝑝 [𝑘𝑒𝑦] → 𝑣𝑎𝑙𝑢𝑒 と表記) として表現することができ，与えられたキーを持つペアは1つだけです。ペアが挿入される前にcontains(key)を呼び出すとfalseを返し、get(key)はエラーを返します。ペアが挿入された後，contains(key)コールは真を返し，get(key)は値を返します。権威は以下の永続ストアを保持します。 オーダーロックマップ Locko [ObjRef] → TxSignOption は、所有するオブジェクトバージョン ObjRef に対して権威が署名した最初の有効なトランザクション Tx を記録し、またはオブジェクトバージョンが存在するが、それを入力とする有効なトランザクションが見られない場合は None を記録します。また、このオブジェクトを入力として見た最初の証明書を記録することもあります。このテーブルとその更新規則は、Sui当局にまたがるオブジェクトの分散ロックの状態を表し、トランザクションの同時処理下での安全性を保証します。 証明書マップ Cty[TxDigest] → (TxCert, Effsign) は，有効期間内に権威によって処理されたすべての完全な証明書 TxCert（Txも含む）を、その署名付き効果 EffSign と共に記録します。これらはトランザクションダイジェスト TxDigest によってインデックス化されます。 オブジェクトマップ Obj, [ObjRef] → Obj は、ObjRef でインデックスされたCty内の証明書に含まれるトランザクションによって作成されたすべてのオブジェクト Obj を記録します。このストアは、Cty 内のすべての証明書を再実行することで完全に導き出すことができます。Objld をこのIDを持つ最新のオブジェクトにマップする二次インデックスが維持されます。これは新しいトランザクションを処理するために必要な唯一の情報であり、古いバージョンは読み取りと監査を容易にするためにのみ維持されます。 同期マップ p Sync𝑣 [ObjRef] → TxDigest は、Cty 内のすべての証明書を、それらが作成、変更、または削除するオブジェクトごとに、タプル ObjRef としてデキシングするものです。この構造は、Cty内のすべての証明書を処理することで完全に再作成することができ、クライアントが気にするオブジェクトに影響を与えるトランザクションの同期を助けるために使用されます。 オーソリティは4つの構造すべてを維持し、また、他のオーソリティやレプリカが処理済みの証明書一式をダウンロードできるように、その証明書マップのローカルチェックポイントへのアクセスを提供します。レプリカはトランザクションを処理せず、証明書のみを処理し、オーソリティと同様に他のテーブルを更新するために証明書を再実行します。また、順序ロックマップを維持し、非同期化を監査します。 オーソリティは、読み取りと同期を容易にするために4つのストア（およびチェックポイント）を維持する完全なレプリカと、新しいトランザクションと証明書を処理するために使用される、オブジェクトの最新バージョンのオブジェクトロックと、オブジェクトのみを維持する最小限のオーソリティコアとして組み合わせて設計することができます。これにより、安全性のために依存するトラステッド・コンピューティング・ベースが最小化されます。 すなわち、キーの読み取りは、存在するキーに対して値またはNoneが存在するかどうかを常に返す必要があり、そのようなチェックはロックをNone以外の値に設定する更新とアトミックでなければなりません。これは、キー間の強い一貫性よりも弱い特性であり、スケーリングのためにストアを効率的にシャーディングすることを可能にします。他のストアは、安全性に影響を与えることなく、最終的に一貫性を保つことができます。 ４.３　権限ベース操作 トランザクションの処理　トランザクションを受信すると、Txan 権限はいくつかのチェックを実行します。 (1) epoch(Tx)が現在のエポックであることを確認します。 (2) すべてのオブジェクト参照入力(Tx)と支払い(Tx)のガスオブジェクト参照がObj内に存在することを確認し、それらを[Obj]にロードします。所有オブジェクトの場合は、正確な参照が可能であるべきで、読み取り専用または共有オブジェクトの場合は、オブジェクトID が存在しなければなりません。 (3)取引実行のコストをカバーするために、十分なガスがガスオブジェクトで利用可能であることを確認します。 (4) valid(Tx, [Obj])が true であることをチェックします。このステップでは、トランザクションの認証情報が の認証情報が所有するオブジェクトにアクセスできることを確認します。 (5）所有するすべてのinputs（Tx）オブジェクトの Lock𝑣 [ObjRef] が存在し、それがNoneか同じTxに設定され、TxSignにアトミックに設定されていることをチェックします(これらを「ロックチェック」と呼びます）。 いずれかのチェックに失敗した場合、処理は終了し、エラーが返されます。しかし、Lockyの部分更新は安全に存続します(ただし、我々の現在の実装では部分更新ではなく、すべてのロックの原子更新を行います)。 すべてのチェックが成功した場合、権威はトランザクションの署名、つまり部分証明書 TxSign を返します。注文の処理は成功するとべき等であり、部分証明書(TxSign)、または完全な証明書(TxCert)が利用可能であれば、それを返します。 いずれの当事者も、エポックeの定足数を形成する一連の当局について、トランザクションと署名 （TxSign）を照合し、トランザクション証明書 TxCert を形成することができます。 証明書を処理する　証明書を受け取ると、当局は、ロックに関連するもの(いわゆる「ロックチェック」)を除く、トランザクションのすべての有効条件をチェックします。代わりに以下のチェックを行う：inputs(Tx)の各所有入力オブジェクトについて、ロックが存在すること、およびそれがNoneであるか、任意のTxSignに設定されているか、または現在の証明書と同じトランザクションの証明書に設定されているかをチェックします。この修正されたロックのチェックが失敗した場合，当局は回復不可能なByzantine障害を検出し，通常の運用を停止し，災害復旧プロセスを開始します。共有オブジェクト（4.4項参照）については、当局は、使用する共有オブジェクトのバージョンを決定するために、証明書がコンセンサスでシーケンスされることによってロックが設定されたことを確認します。もしそうなら、トランザクションは実行されるかもしれません。そうでない場合は、まずそのような順序付けを待つ必要があります。 チェックに成功した場合、当局は証明書を、その実行の結果もたらされる効果とともに、証明書マップに追加します。ie. Ct𝑣 [TxDigest] → (TxCert, EffSign); ロックが証明書に設定されていない所有する全ての入力オブジェクトの証明書 Lock𝑣 [ObjRef] → TxCert を記録するようにロックマップを更新している。Input(Tx) の全オブジェクトが Obj𝑣 に挿入されると同時に、EffSign の全効果も ObjRef と内容を Obj𝑣 に追加して実体化されます。最後に EffSign で作成または変異されたすべてのものに対して、同期マップが更新され、Tx にマップされます。 備考　トランザクションと証明書を処理するロジックは、多くの重要なプロパティを導きます。 因果関係と並列性　トランザクションと証明書の両方の処理条件は因果関係のある実行を保証します。当局は、トランザクションが依存するオブジェクトを作成するすべての証明書（所有、共有、読み取り専用）を処理した場合にのみ、トランザクションに署名することで「投票」します。同様に、権威は、それが依存するすべての入力オブジェクトがそのローカルオブジェクトマップに存在する場合にのみ、証明書を処理します。これは因果関係のある実行順序を課すが、互いに因果関係のないトランザクションを異なるコアやマシンで並列に実行することも可能にします。 署名は一度だけ、そして安全　Lock𝑣 [·] 内のすべての所有する入力オブジェクトのロックは、それを使ってチェックをパスした最初のトランザクションTxに設定され、次にそのオブジェクトを入力として使った最初の証明書に設定されます。これをこのトランザクションに対するオブジェクトのロックと呼び、1つのエポック内でロックが解除されることはありません。その結果、権威はロックごとに1つのトランザクションにしか署名しない。これは一貫性のあるブロードキャストの必須要素であり、したがってSuiの安全性です。 災害復旧　同じロックに対して2つの矛盾した証明書を検出した権威は、回復不可能なByzantine行動の証明、すなわちクォーラムの正直な権威の仮定が成立しないことの証明を持ちます。この矛盾する2つの証明書は詐欺の証明であり、すべての権威とレプリカに共有され、災害復旧プロセスを起動させることができます。権威はまた、証明書の不正な実行を表すエフェクト（EffSign）に対する1/3以上の署名のような、回復不可能なByzantine行動の証明を他の形で得ることができます。あるいは、以前に処理された証明書の正しい出力を表さない入力オブジェクトを持つ証明書です。これらはまた、不正行為の証明としてパッケージ化され、すべての当局及びレプリカと共有することができます。これらは、許容できる少数派の当局（出資比率1/3未満）またはオブジェクトの所有者（任意の数）がByzantineまたは衡平法であるという証明とは異なるものであり、サービスの中断なしに許容されるものであることに注意してください。 最終的なもの　当局は、n Lock𝑣 、Ct𝑣、およびObj𝑣、Sync𝑣 のインデックスに対する読み取り要求に対して、証明書(TxCert)と署名済み効果(EffSign)を返します。トランザクションは、Ctyストアに含まれるTxを報告する機関の数が一定以上であれば、最終的なものとみなされます。これは、エフェクト証明書（EffCert）が最終性の譲渡可能な証明となることを意味します。ただし、あるオブジェクトを使用した証明書は、その因果関係のある経路にあるすべての従属証明書も最終的なものであることを証明するものでもあります。証明書を任意の当事者に提供し、その当事者はそれを処理のために超多数の当局に提出することができ、証明書の効果の最終性を保証します。最終性は、再構成時の安全性を確保するために、fastpay よりも遅いことに注意してください。しかし、権威はコミットを待つのではなく、証明書を見た時点でトランザクションの効果を適用することができます。 ４.４　所有者、認可、および共有オブジェクト トランザクションの有効性（4.3項参照）は、トランザクションが指定されたすべての入力 オブジェクトをトランザクションに含めることを認可されていることを保証します。このチェックは、所有者フィールドと同様に、オブジェクトの性質に依存します。 読み取り専用のオブジェクトは、変異や削除ができず、トランザクションで同時に、すべてのユーザーが使用することができます。例えば、Moveモジュールは読み取り専用です。このようなオブジェクトは、スマートコントラクトの一部として使用されるかもしれない所有者を持つが、それはそれらを使用するための権限に影響しない。それらはあらゆるトランザクションに含まれることができます。 所有するオブジェクトは、owner フィールドを持ちます。所有者には、公開鍵を表すアドレスを設定することができます。その場合、トランザクションは、そのアドレスによって署名されていれば、そのオブジェクトを使用し、それを変異させることを許可されます。トランザクションは1つのアドレスによって署名され、したがってそのアドレスが所有する1つ以上のオブジェクトを使用することができます。しかし、1つのトランザクションは、複数のアドレスによって所有されるオブジェクトを使用することはできません。子オブジェクトと呼ばれるオブジェクトのオーナーは、親オブジェクトと呼ばれる別のオブジェクトのObjIDに設定することができます。その場合、親オブジェクトがトランザクションに含まれ、トランザクションがそのオブジェクトの使用を許可されている場合にのみ、子オブジェクトを使用することができます。この機能は、コントラクトが効率的なコレクションや他の複雑なデータ構造を構築するために使用することができます。 共有オブジェクトは、変更可能ですが、特定の所有者を持ちません。その代わりに、異なる当事者によるトランザクションに含まれることができ、いかなる承認も必要としません。その代わり、彼ら自身の認証ロジックを実行します。このようなオブジェクトは、安全性と活性を確保しながら複数の書き込み者をサポートしなければならないため、安全に使用するために完全な合意プロトコルを必要とします。したがって、実行前に追加のロジックを必要とする。当局は、4.3節に規定されるようにトランザクションを処理します。4.3節に規定されたトランザクションを、所有オブジェクトと読み取り専用オブジェクトのために処理し、ロックを管理します。しかし、当局は、共有オブジェクトのロックを管理するために、一貫性のあるブロードキャストに依存しません。その代わり、共有オブジェクトを含むトランザクションの作成者は、そのトランザク ションに関する証明書を、例えば [George Danezis, Eleftherios Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2021. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. CoRR abs/2105.11827 (2021)] のような高スループットのコンセンサスシステムに挿入します。すべての権威はそのような証明書の一貫したシーケンスを観察し、このシーケンスに従って各トランザクションで使用される共有オブジェクトのバージョンを割り当てます。その後、実行を進めることができ、すべての機関にわたって一貫していることが保証されます。当局は、トランザクションの実行に使用される共有オブジェクトのバージョンを、Effects証明書内に含めます。 上記のルールにより、読み取り専用および所有のオブジェクトを含むトランザクションの実行には、一貫したブロードキャストと単一の証明書のみが必要であり、Byzantine合意は共有オブジェクトを含むトランザクションにのみ必要であることが保証されます。そのため、スマートコントラクトの作成者は、単一ユーザーのオブジェクトに対する転送やその他の操作をより低レイテンシーに最適化するように型とその操作を設計できる一方、複数のユーザーからアクセスされる必要があるロジックを実装するために共有オブジェクトを使用する柔軟性を享受することができるのです。 ４.５　クライアント フルクライアントとレプリカ　レプリカはフルクライアントとも呼ばれ、新しいトランザクションを検証しないが、監査目的のためにシステムの有効な状態の一貫したコピーを維持し、またトランザクションを構築したり、ライトクライアントクエリー用の読み取りインフラストラクチャを含むサービスを運営したりします。 ライトクライアント　オブジェクト参照とトランザクションの両方は、その作成または実行に至るトランザクションの完全な因果関係の認証を可能にする情報を含んでいます。具体的には、オブジェクト参照（ObjRef）には、オブジェクトの完全な状態を認証するObjDigestが含まれ、parent(Obj)、つまりオブジェクトを作成したTxDigestを取得する機能も含まれます。同様に、TxDigestは、入力オブジェクトのオブジェクト参照をinputs(Tx)を通じて抽出する機能を含む、トランザクションを認証するものです。したがって、オブジェクトと証明書のセットは、自己認証可能な2部グラフを形成します。さらに、効果構造も署名され、トランザクションの実行結果を直接証明する効果証明書に照合されることがあります。 これらの設備は、完全なレプリカノードを維持することなく、Suiの状態に対して高い完全性の読み取りを実行できるライトクライアントをサポートするために使用されるかもしれない。具体的には、権威ノードまたは完全ノードは、トランザクションTxに関する証明書TxCertとinputs(Tx)に対応する入力オブジェクト［Obj］からなる簡潔な証拠の束を提供して、Sui内でトランザクションが行われうることをライトクライアントに納得させることができる。ライトクライアントはその後、この証明書を提出するか、最終性を確保するために当局の定足数またはサンプルによって見られたかどうかをチェックすることができる。あるいは、実行の結果得られたオブジェクトを使用してトランザクションを作成し、それが成功したかどうかを観察することもできる。 より直接的には、あるサービスが、Sui内の遷移の存在と最終性を確信させるために、システム内でそれ以上の動作や相互作用をすることなく、クライアントに効果証明書を提供することができます。エポック境界などで、確定した証明書のチェックポイントが利用できる場合、チェックポイントに証明書が含まれていることの証明と一緒に、入力オブジェクトと証明書を含む証拠の束もまた、最終性の証明となります。 当局は、定期的なチェックポイント機構を使用して、確定したトランザクションの集合的なチェックポイントを作成し、また、時間の経過とともにSuiの状態を作成することができます。チェックポイントに対する定足数のステークを持つ証明書は、オブジェクトと放出されたイベントの最近の状態を効率的に検証するために、ライトクライアントによって使用されることができます。チェックポイント機構はエポック間の委員会再構成のために必要です。より頻繁なチェックポイントはライトクライアントにとって有用であり、また、当局が内部データ構造を圧縮し、他の当局とより効率的に状態を同期するために使用することもできます。 4.6 ブリッジ ライトクライアントとByzantine合意で管理される共有オブジェクトのネイティブサポートにより、Suiは他のブロックチェーンとの双方向ブリッジをサポートすることができます。このようなブリッジの信頼前提は、Suiと他のブロックチェーンの信頼前提を反映し、他のブロックチェーンもライトクライアントをサポートする場合は、信頼できるオラクルやハードウェアに頼る必要はありません。 ブリッジは、他のブロックチェーンで発行されたアセットをインポートして表現し、Suiシステム内でラップアセットとして使用するために使用されます。最終的には、ラップされたアセットをロック解除して、ネイティブブロックチェーン上のユーザーに転送することができます。ブリッジは、Sui上で発行されたアセットをロックし、他のブロックチェーン上でラップされたアセットとして使用することも可能です。最終的には、他のシステム上のラップされたオブジェクトを破棄し、Sui上のオブジェクトを更新して状態や所有権の変更を反映させ、ロックを解除することができます。 ラップされた資産が有用であることを保証するために、ブリッジされた資産のセマンティクスはある程度の重要性を持っています。ブロックチェーン間でブリッジされたFungibleアセットは、よりリッチなラップ表現を提供することができ、ラップされたときに分割可能で譲渡可能であることを可能にします。Nonfungibleアセットは、分割可能ではなく、譲渡可能なだけです。また、ラップ時に状態を制御された方法で変異させる他の操作をサポートしている場合があり、ブリッジバックしてラップを解除する際に実行されるカスタムスマートコントラクトロジックが必要になる場合があります。ブリッジはSuiのネイティブな概念ではなく、Moveで実装されたスマートコントラクトであるため、Suiは柔軟で、スマートコントラクトの作者がそのような経験を定義することを可能にします - したがって、Moveが提供する組み合わせ可能性と安全性を利用して拡張することができます。 ４.７　Committeeの再構成 Committee 𝐶𝑒 がCommittee 𝐶𝑒 ′ に置き換えられるとき、エポック間で再構成が発生します（𝑒 ′ = 𝑒 + 1）。再構成の安全性は、トランザクションTxがeまたはそれ以前にコミットされた場合、eの後に競合するトランザクションをコミットすることができないことを保証し、有効性は、Tx が e またはそれ以前にコミットされた場合、それは e の後にもコミットされなければならないことを保証します。 私たちは、Suiスマートコントラクトシステムを利用して、再構成に必要な多くの作業を実行します。Suiでは、システム・スマートコントラクトにより、ユーザーはステークをロックし、権限候補に委譲することができます。エポック中、コインの所有者は、トークンをロックすることで委任し、トークンをアンロックすることで委任を解除し、1つ以上の当局への委任を自由に変更することができます。 エポックeの定足数のステークがエポックを終了することに投票すると、当局はチェックポイントにコミットし、次の委員会を決定し、エポックを変更するために情報を交換します。まず当局は、エポックeの終了のための認証されたチェックポイントに合意するために、合意プロトコルの助けを借りてチェックポイントプロトコルを実行します。その結果、あるトランザクションが当局の定足数によって処理された場合、それを処理した少なくとも1つの正直な当局は、エポック終了時のチェックポイントにその処理されたトランザクションが含まれ、トランザクションとその効果がエポック間で永続することが保証されます。さらに、このような認定チェックポイントは、すべてのトランザクションがエポックeの正直な当局に利用可能であることを保証しています。 そして、エポック終了時のチェックポイントにおけるステーク委任は、エポックe + 1のための新しい権威のセットを決定するために使用されます。旧権限者のステークと新権限者のステークの定足数の両方が、新しい Committee 𝐶𝑒 ′ と、新しいエポックの開始点となるチェックポイントに署名します。両方の署名が利用可能になると、新しいエポックに対するトランザクションの処理が開始され、古い当局はエポック署名鍵を削除することができます。 リカバリー　クライアントエラーまたはクライアントアイコボケーションにより、あるエポック内で所有オブジェクトが「ロック」され、それに関するトランザクションが認証（または確定）されなくなることがあり得ます。例えば、クライアントが同じ所有オブジェクトのバージョンを使用して2つの異なるトランザクションに署名し、半分の当局がそれぞれに署名している場合、2つの証明書のいずれにも署名の定足数を必要とする証明書を形成することができないことになります。リカバリーは、エポックが変更されると、そのようなオブジェクトが再びトランザクションで使用できる状態になることを保証します。証明書が形成されないので、元のオブジェクトは次のエポックの開始時に操作可能です。トランザクションはエポック番号を含むので、古い等価トランザクションはオブジェクトを再びロックしないので、その所有者にそれを使用する機会を与えることができます。 報酬とクリプト経済　Suiには、供給量が固定されたネイティブトークンSUIがあります。SUIはガスの支払いに使用され、またエポック内の当局の委任された株式として使用されます。このエポック内の当局の投票力は、この委任されたステーク（出資比率）の関数です。エポックの終わりには、処理されたすべてのトランザクションを通じて集められた手数料が、Suiの運営への貢献度に応じて当局に分配され、次に当局は手数料の一部を、彼らにステークを委任したアドレスに報酬として分配します。Suiのトークンエコノミクスの完全な説明は、専用の論文に延期します。 ４.８　権限とレプリカの更新 クライアント主導型　クライアントの障害または非Byzantine認証機関の障害により、一部の認証機関はすべての証明書を処理していない可能性があります。その結果、これらの証明書によって生成された欠落したオブジェクトに依存する因果関係のあるトランザクションは拒否されるでしょう。しかし、クライアントは常に、正しいトランザクションを処理できる時点まで、誠実な機関 を更新することができます。これは、それ自身の過去の証明書のストアを使用するか、過去の証明書のソースとして1つ以上の他の誠実な権威を使用して行うことができます。 証明書cと、cとその因果関係の履歴を含む 𝐶𝑡𝑣 ストアが与えられると、クライアントは正直な権威 𝑣 ′ をcも適用されるポイントにアップデートすることができます。これは、𝑣 ′ のオブジェクトが適用されたときにcのすべての入力を含むような、𝑣 ′ にない証明書の最小のセットを見つけることを含みます。証明書TxCertを含むストアCtを使用して、遅れている権威Bを更新することは、以下を含みます。 クライアントは、同期する証明書のリストを保持し、初期状態ではTxCertのみを含むように設定されています。 クライアントは、同期を必要とする最後のTxCertを考慮する。TxCert内のTxを抽出し、そのすべての入力オブジェクトを導出します（Input(Tx)を使用）。 各入力オブジェクトについて、最後に生成または変異したTx（CtuのSync, indexを使用）がB内に証明書を持つかどうかをチェックし、そうでなければその証明書をCtから読み取って、同期する証明書のリストに追加します。 これ以上証明書を追加できない場合（Bからの入力がないため）、証明書リストは因果関係順にソートされ、Bに提出されます。 上記のアルゴリズムは、新しいトランザクションを有効にするために、オブジェクトを特定のバージョンに アップデートする場合にも適用されます。この場合、オブジェクトのバージョンを生成したTxの証明書(n Sync𝑣 [ObjRef]にある)が、遅れている権威に提出されます。それがB上で実行されると、正しいバージョンのオブジェクトが使用できるようになります。 この操作を行うクライアントをリレイヤーと呼びます。複数のリレイヤーが独立して同時に動作することも可能です。これらは完全性の点では信頼されず、その動作はキーレスです。クライアント以外にも、権威はリレイヤーロジックを実行して互いに更新し合うことができます。また、サービスを運用するレプリカもリレーヤとして機能し、遅れている権威を更新することができます。 バルク　オーソリティは、フォロワーが証明書を処理する際に、アップデートを受け取るための設備を提供します。これにより、レプリカはオーソリティの状態を最新に保つことができます。さらに、当局は、短期的には、処理された最新のトランザクションを互いに更新するためにプッシュプルゴシップネットワークを使用し、この機能を実行するための中継者の必要性を減らすことができます。長期的には、遅れている当局は、あるチェックポイントまでの証明書の完全なセットを処理したことを確認するために、エポック境界またはより頻繁に、定期的なステートコミットメントを使用することができます。 ５　スケーリングとレイテンシー Suiシステムは、当局がより多くのリソース、すなわちマシン内または複数のマシンにわたってCPU、メモリ、ネットワーク、ストレージをトランザクション処理に割り当てることにより、スケーリングすることができます。リソースの増加はトランザクションの処理能力の向上につながり、これらのリソースを賄うための手数料収入の増加にもつながります。また、リソースが増えれば、必要なリソースが利用可能になるのを待たずにオペレーションが実行されるため、レイテンシーが低くなります。 スループット　より多くのリソースが準線形に容量を増やすことを保証するため、Suiの設計では、ボトルネックや、オーソリティ内のグローバルロックを必要とする同期ポイントを積極的に減らしています。トランザクションの処理は、（1）トランザクションが特定のバージョンで所有または共有オブジェクトへの排他的アクセスを持つことを保証し、（2）その後、トランザクションを実行してその効果をコミットするという2つのフェーズにきれいに分離されています。 フェーズ（1）では、トランザクションがオブジェクトの粒度で分散ロックを取得することが必要です。所有オブジェクトの場合、これは信頼できるブロードキャストプリミティブによって実行され、権限内のグローバルな同期を必要としないため、ObjIDによって複数のマシン間でロック管理をシャーディングすることでスケーリングすることができます。共有オブジェクトを含むトランザクションでは、コンセンサスプロトコルを用いた順序付けが必要です。これは、これらのトランザクションにグローバルな順序を課し、ボトルネックとなる可能性を秘めています。しかし、最近の高スループットのコンセンサスプロトコルのエンジニアリングの進歩により、ステートマシン複製におけるボトルネックはシーケンシャル実行であり、シーケンシングではないことが実証されています。Suiでは、シーケンシャル実行ではなく、入力された共有オブジェクトのバージョンを決定するためにのみ、すなわちオブジェクトのバージョン番号をインクリメントし、それをトランザクションダイジェストに関連付けるためにシーケンシャル実行が使用されます。 フェーズ（2）は、すべての入力オブジェクトのバージョンが当局に知られ(そして当局間で安全に合意され)、Moveトランザクションの実行とその効果のコミットを伴うときに行われます。入力オブジェクトのバージョンが分かれば、完全な並列実行が可能です。複数のコアまたは物理マシン上の仮想マシンを動かし、バージョン管理された入力オブジェクトを読み、実行し、結果のオブジェクトをストアから、またはストアに書き込みます。オブジェクトやトランザクションのストアに対する一貫性要件（オーダーロックマップ以外）は非常に緩く、各機関内部でスケーラブルな分散キーバリューストアを使用することができます。実行は偶発的であり、実行を扱うコンポーネントのクラッシュやハードウェア障害からの回復が容易です。 その結果、互いに因果関係のないトランザクションの実行を並行して進めることができます。したがって、スマートコントラクトの設計者は、この並列性を利用するために、コントラクト内のオブジェクトや操作のデータモデルを設計することができます。 チェックポイントと状態のコミットメントは、新しいトランザクションの処理を妨げないよう、クリティカルなトランザクション処理パスから外れて計算されます。これらは、トランザクションが完了する前に計算と合意を必要とするのではなく、コミットされたデータに対する読み取り操作を伴います。したがって、新しいトランザクションの処理のレイテンシーやスループットに影響を与えず、それ自体を利用可能なリソースに分散させることができます。 読み取りは、非常にアグレッシブでスケーラブルなキャッシュの恩恵を受けることができます。認証局は、ライトクライアントが読み込みに必要とするすべてのデータに署名し、利用可能にします。これらのデータは、静的データとして分散ストアから提供される場合があります。証明書は、トランザクションとオブジェクトの完全な因果関係の履歴に対する信頼の根源として機能します。さらにステート・コミットメントにより、システム全体が、少なくともエポック毎、あるいはより頻繁に処理されるすべてのステートとトランザクションに対して、定期的にグローバルな信頼の根を持つことができるようになります。 レイテンシー　スマートコントラクトの設計者は、定義したオペレーションが所有オブジェクトと共有オブジェクトのどちらを含むかによって、レイテンシーを制御する柔軟性を与えられています。所有オブジェクトは、実行とコミットの前に信頼できるブロードキャストに依存し、最終的に到達するために当局のクォーラムへの2回のラウンドトリップを必要とします。一方、共有オブジェクトを含む操作は、証明書を作成するために一貫したブロードキャストを必要とし、その後コンセンサスプロトコル内で処理されるため、レイテンシが増加します（[George Danezis, Eleftherios Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2021. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. CoRR abs/2105.11827 (2021)]の時点でクォーラムへの4～8回のラウンドトリップ）。 ＊オリジナルのホワイトペーパーはこちら https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf ここに記載された内容は、あくまでオリジナルを日本語訳にしたものであり、私KeiCryptoによるものではありません。著作権はオリジナルの作成者のものです。 The content herein is only a Japanese translation of the original and is not by me, KeiCrypto. The copyright belongs to the original author.

2022年8月11日

v1.0

法的免責事項：本ホワイトペーパーとその内容は、トークンの販売や購入の申し出の勧誘を目的としたものではありません。私たちは、一般の方々からフィードバックやコメントをいただくためにのみ、このホワイトペーパーを発行しています。この文書のいかなる部分も、Aptosブロックチェーンまたはそのトークン（もしあれば）がどのように発展し、利用され、または価値を生むかを保証または約束するものとして読んだり解釈してはなりません。Aptosは現在の計画を概説しているだけであり、その計画は同社の裁量で変更可能であり、その成功は同社の管理外の多くの要因に依存します。このような将来の記述は、必然的に既知および未知のリスクを伴い、将来の期間における実際のパフォーマンスや結果は、このホワイトペーパーで説明または暗示したものと大きく異なる可能性があります。Aptosは、計画を更新する義務を負いません。実際の結果や将来の出来事が大きく異なる可能性があるため、ホワイトペーパーのいかなる記述も正確であることを保証するものではありません。将来の記述に過度の信頼を置かないようにお願いします。

概要

新しいインターネットインフラとしてのブロックチェーンの台頭により、開発者は何万もの分散型アプリケーションを急速にデプロイしています。残念ながら、ブロックチェーンの利用は、頻繁な停止、高いコスト、低いスループット制限、および多くのセキュリティ上の懸念のために、まだユビキタスではありません。Web3時代に大量導入を可能にするためには、ブロックチェーンインフラは、広く利用されるアプリケーションを構築するための信頼性の高い、拡張性の高い、コスト効率の良い、継続的に改善されるプラットフォームとして、クラウドインフラの道を歩む必要があります。

これらの課題を解決するために、スケーラビリティ、安全性、信頼性、アップグレード可能性を重要な原則として設計されたAptosブロックチェーンを発表します。Aptosブロックチェーンは、世界中の350人以上の開発者によって、過去3年間にわたり開発されてきました。コンセンサス、スマートコントラクト設計、システムセキュリティ、パフォーマンス、および分散化において、新しく斬新なイノベーションを提供しています。これらの技術の組み合わせは、web3を大衆に届けるための基本的なビルディングブロックを提供します。

• まず、Aptosブロックチェーンは、Move言語をネイティブに統合し、内部で使用して、高速で安全なトランザクションを実行します。Move言語で記述されたスマートコントラクトのための正式な検証機であるMove proverは、コントラクトの不変量と動作にさらなる安全策を提供します。このようにセキュリティを重視することで、開発者は自分たちのソフトウェアを悪意ある存在からよりよく保護することができます。開発者は、悪意のあるエンティティからソフトウェアをよりよく保護することができます。

• 第二に、Aptosのデータモデルは、柔軟なキー管理とハイブリッドカストディアルオプションを可能にします。これは、署名前のトランザクションの透明性と実用的な軽量クライアントプロトコルと共に、より安全で信頼できるユーザーエクスペリエンスを提供します。

• 第三に、高いスループットと低レイテンシーを実現するために、Aptosブロックチェーンはトランザクション処理の主要段階において、パイプライン化されたモジュール式のアプローチを活用しています。具体的には、取引の普及、ブロックメタデータの順序付け、並列取引の実行、バッチストレージ、元帳の認証のすべてが同時に動作します。このアプローチにより、利用可能なすべての物理リソースをフルに活用し、ハードウェア効率を向上させ、高度な並列実行を可能にします。

• 第四に、他の並列実行エンジンでは、読み書きの対象となるデータについて前もって知る必要があるため、トランザクションの原子性が壊れてしまいますが、Aptosブロックチェーンでは、開発者にそのような制限を設けていません。任意に複雑なトランザクションの原子性を効率的にサポートし、実世界のアプリケーションでより高いスループットと低レイテンシーを実現し、開発を簡素化することが可能です。

• 第5に、Aptosのモジュラーアーキテクチャ設計は、クライアントの柔軟性をサポートし、頻繁かつ即時のアップグレードに最適化されています。さらに、新しい技術革新を迅速に展開し、新しいWeb3のユースケースをサポートするために、Aptosブロックチェーンは、組み込みのオンチェーン変更管理プロトコルを提供します。

• 最後に、Aptosブロックチェーンは、個々のバリデータの性能を超えるスケールアップのための将来のイニシアチブを実験しています。そのモジュール設計と並列実行エンジンはバリデータの内部シャーディングをサポートし、同種の状態シャーディングは、ノードオペレータに複雑さを追加することなく水平方向のスループット拡張性の可能性を提供します。

１　はじめに

Web2版インターネットでは、メッセージング、ソーシャルメディア、金融、ゲーム、ショッピング、オーディオ/ビデオストリーミングなどのサービスが、ユーザーデータへの直接アクセスを制御する中央集権的企業（Google、Amazon、Apple、Metaなど）によって提供されています。これらの企業は、対象となるユースケースに最適化されたアプリケーション固有のソフトウェアを使用してインフラを開発し、クラウドインフラストラクチャを活用してこれらのアプリケーションをユーザーに展開します。クラウドインフラは、世界中のデータセンター（例：AWS、Azure、Google Cloud）で稼働するレンタル仮想マシン（VM）やベアメタルハードウェアなど、仮想化・物理化されたインフラサービスへのアクセスを提供します。その結果、何十億人ものユーザーに対応できるweb2インターネットサービスの構築が、今日ほど容易になったことはありません。しかし、web2では、ユーザーが中央集権的なエンティティに明示的な信頼を置く必要があり、この要件は社会的にますます懸念されるようになってきています。

web3では、ブロックチェーンが登場し、分散化された不変の台帳を提供することで、ユーザー同士が安全かつ確実にやりとりできるようになり、仲介者や中央集権的なエンティティを信頼する必要がありません。Web2インターネットサービスやアプリケーションがビルディングブロックとしてクラウドインフラに依存しているのと同様に、分散型アプリケーションはブロックチェーンを分散型インフラ層として利用し、世界中の何十億ものユーザーにリーチすることができます。

しかし、今日、多くのブロックチェーンが存在するにもかかわらず、web3の広範な採用はまだ行われていません。テクノロジーは業界を進歩させ続けていますが、既存のブロックチェーンは信頼性が低く、ユーザーに高い取引手数料を課し、スループットの制限が低く、セキュリティ問題による定期的な資産損失に苦しみ、リアルタイムの応答性をサポートすることができないのです。クラウドインフラがWeb2サービスを数十億人に届けることを可能にしたのに比べ、ブロックチェーンはWeb3アプリケーションを同じように実現するには至っていません。

２　Aptosのビジョン

Aptosのビジョンは、Web3に主流をもたらし、実世界のユーザーの問題を解決する分散型アプリケーションのエコシステムを強化することができるブロックチェーンを提供することです。私たちの使命は、柔軟でモジュール化されたブロックチェーンアーキテクチャを提供することにより、ブロックチェーンの信頼性、安全性、性能における最先端を前進させることです。このアーキテクチャは、頻繁なアップグレード、最新の技術の進歩の迅速な採用、新しいユースケースや新興のユースケースに対するファーストクラスのサポートをする必要があります。

私たちは、分散型で安全かつスケーラブルなネットワークが、それを利用するコミュニティによって管理・運営されることを想定しています。世界中でインフラの需要が高まれば、ブロックチェーンの計算資源は水平方向にも垂直方向にもスケールアップして、そのニーズに応えます。新しいユースケースや技術的な進歩が生じると、ネットワークはユーザーを中断させることなく、頻繁にシームレスにアップグレードされるはずです。そしてインフラに関する懸念も、背景に薄れていくはずです。開発者とユーザーは、キーの復元、データモデリング、スマートコントラクトの標準、リソース使用のトレードオフ、プライバシー、およびコンポーザビリティに関する多くの異なるオプションにアクセスすることができます。ユーザーは、自分の資産が安全で、常に利用可能であり、ほぼ原価（低料金）でアクセスできることを知ることができます。そして、誰もが安全、簡単、かつ不変に世界中の信頼できない相手と取引することができます。ブロックチェーンは、クラウドインフラと同じようにユビキタスな存在です。

このビジョンを達成するためには、大幅な技術的進歩を遂げる必要があります。過去3年間にわたるDiemブロックチェーン（Aptosブロックチェーンの前身）の構築、開発、進歩、展開の経験から、ネットワークはクライアントを混乱させることなくプロトコルを継続的にアップグレードできることが証明されています。Diemメインネットは、2020年初頭に複数のウォレットプロバイダーとともに10数社のノードオペレーターに展開されました。その後の1年間で、私たちのチームはコンセンサスプロトコルとコアフレームワークを変更する2つのメジャーアップグレードを発行しました。どちらのアップグレードも、ユーザーにダウンタイムを与えることなく完了しました。Aptosブロックチェーンでは、Diemブロックチェーンに触発され、安全かつ透明で頻繁なアップグレードを中核機能として取り入れながら、技術スタックに一連の抜本的な改良を施したのです。特に、（セクション7で説明する）トランザクション処理の斬新な手法と、分散化とネットワークガバナンスへの新たなアプローチを強調しています。

Aptosブロックチェーンが改善され成長し続けるにつれ、私たちはこのホワイトペーパーの最新版を発行し、私たちのプロトコルと設計の選択を更新していく予定です。この文書の残りの部分では、Aptosブロックチェーンの現在の状態と将来の計画について説明します。

３　概要

Aptosブロックチェーンは、図1に示すように、byzantineフォールトトレラント（BFT）、プルーフオブステーク合意メカニズムを使用してユーザーからの取引を共同で受信し処理するバリデーターのセットで構成されています。トークン保有者は、選択したバリデーターにトークンをステークし、ロックします。各バリデーターのコンセンサス投票の比重は、そのバリデーションに賭けられた金額に比例します。バリデータはアクティブであり、コンセンサスに参加することができます。同様に、バリデータは、参加するのに十分なステークがない場合、バリデータセットから外れる場合、 ブロックチェーンの状態を同期するためにオフラインになる場合、あるいは過去のパフォーマンスが 低いためにコンセンサスプロトコルから不参加とみなされた場合、非アクティブになることがあります。 クライアントとは、取引を提出したり、ブロックチェーンの状態や履歴を照会したりする必要があるシステムのあらゆる部分を指します。

クライアントは、照会されたデータのバリデータ署名付き証明をダウンロードし、検証することを選択できます。フルノードは、バリデータまたはネットワーク上の他のフルノードから取引とブロックチェーンの 状態を複製するクライアントです。また、必要に応じて取引履歴やブロックチェーンの状態を削除し、ストレージを再利用することも可能です。ライトクライアントは現在のバリデータのみを保持し、部分的なブロックチェーンの状態を、通常フルノードから安全に問い合わせることができます。ウォレットはライトクライアントの一般的な例です。

安全、高速、信頼性が高く、アップグレード可能なWeb3インフラの普及のニーズを満たすため、Aptosブロックチェーンは以下のコア設計原則に基づいて構築されています。

• 新しいスマートコントラクトプログラミング言語Moveを介して、高速で安全な実行と簡単な監査可能性、機械的な分析可能性を実現します。 Aptosブロックチェーンの前身から始まり、このプロジェクトの進化とともに進歩し続けています。

• バッチ処理、パイプライン処理、並列処理によるトランザクション処理で、極めて高いスループットと低レイテンシーを実現します。

• 読み書きの対象となるデータ位置を前もって知る必要がある既存の並列実行エンジンとは異なり、Block-STMによって任意に複雑なトランザクションの原子性を効率的にサポートする新規な並列トランザクション処理します。

• 迅速なステークウェイトバリデータセットのローテーションとレピュテーショントラッキングにより、パフォーマンスと分散化のための最適化を実現します。

• モジュール設計により、コンポーネントレベルでの厳格なテスト、適切な脅威のモデル化、シームレスな展開を実現し、高い安全性と信頼性のある運用を保証します。

• コンポーネントレベルでの厳格なテスト、適切な脅威のモデル化、シームレスな展開を可能にするモジュール設計です。

• シャーディングは、ユーザーに公開され、プログラミングとデータモデルにネイティブなファーストクラスのコンセプトであるため、分散化を維持したまま水平方向のスループット拡張が可能です。

セクション4では、開発者がAptosブロックチェーンのMoveとどのようにやり取りするかを説明します。セクション5では、論理データモデルについて説明します。セクション6では、Aptosブロックチェーンが強力な検証方法を通じて安全なユーザーエクスペリエンスを可能にする方法を詳しく説明します。セクション7では、パイプライン、バッチ処理、並列化に関する主要なパフォーマンス革新について説明します。セクション8では、異なるクライアントが他のノードと状態を同期させるための様々なオプションについて詳しく説明します。セクション9では、コミュニティのオーナーシップとガバナンスのための計画について説明します。最後に、セクション10では、分散化を維持しつつ、将来の性能の方向性について議論します。

４　Move言語

Moveは、安全性と柔軟性に重点を置いた新しいスマートコントラクトプログラミング言語です。Aptosブロックチェーンは、Moveのオブジェクトモデルを使用して台帳の状態を表現し（セクション5.5参照）、Moveコード（モジュール）を使用してステートトランザクションのルールを符号化します。ユーザーは、新しいモジュールの公開、既存のモジュールのアップグレード、モジュール内で定義されたエントリ関数の実行、またはモジュールのパブリックインターフェースと直接対話できるスクリプトを含むトランザクションを提出します。

Moveのエコシステムには、コンパイラー、仮想マシン、その他多くの開発者向けツールが含まれます。Moveはプログラミング言語Rustにインスパイアされており、線形型のような概念によってデータの所有権を言語内で明示することができます。Moveはリソースの希少性、保存性、アクセス制御を重視しています。Moveのモジュールは、すべてのリソースの寿命、保存、アクセスパターンを定義しています。これにより、コインのようなリソースが適切な認証情報なしに生成されたり、二重に消費されたり、消滅したりすることがないようにします。

Moveはバイトコード検証器を活用し、信頼されていないコードが存在する場合でも、型とメモリの安全性を保証します。より信頼できるコードを書くために、Moveには形式検証器Move Proverがあり、Moveに統合された仕様言語で定式化された仕様に対してMoveプログラムの機能が正しいかどうかを検証することができます。

ユーザーアカウントと対応するアカウントコンテンツに加え、台帳の状態にはAptosブロックチェーンのオンチェーン構成も含まれます。このネットワーク構成には、アクティブなバリデータのセット、ステーキングプロパティ、およびAptosブロックチェーン内のさまざまなサービスの構成が含まれます。Moveのモジュールアップグレード可能性と包括的なプログラム可能性のサポートは、シームレスな構成変更を可能にし、Aptosブロックチェーン自体のアップグレードをサポートします（アップグレードの両方のセットは、プライベートメインネット上でゼロダウンタイムで複数回実行されています）。

Aptosチームは、より広範なWeb3のユースケースをサポートすることで、Moveをさらに強化しました。セクション5.5で後述するように、Aptosブロックチェーンはきめ細かなリソース制御を可能にします。これは実行の並列化をサポートするだけでなく、データへのアクセスや変異に関連するほぼ固定されたコストを実現します。さらに、Aptosブロックチェーンは、きめ細かいストレージの上に構築されたテーブルサポートを提供し、単一のアカウントで大規模なデータセット（例えば、NFTの大規模なコレクション）を使用できるようにします。さらに、Aptosは、完全にオンチェーンで表現される共有または自律アカウントに対応しています。これにより、複雑な分散型自律組織（DAO）が共同でアカウントを共有したり、これらのアカウントをリソースの異種コレクションのコンテナとして使用したりすることができます。

５　論理データモデル

Aptosブロックチェーンの元帳の状態は、すべてのアカウントの状態を表します。台帳の状態は、システムが実行した取引数に対応する符号なし64ビット整数を使用してバージョン管理されています。誰でもAptosブロックチェーンにトランザクションを提出し、元帳の状態を変更することができます。トランザクションが実行されると、トランザクション出力が生成されます。トランザクション出力は、台帳の状態を操作するゼロ以上の操作（書き込みセットと呼ばれる）、結果イベントのベクトル（セクショ ン 5.1.1 参照）、消費されたガスの量、および実行されたトランザクションの状態を含んでいます。

５.１ トランザクション

署名されたトランザクションは、以下の情報を含みます。

• トランザクション認証機能：送信者は、トランザクションが認証されたことを確認するために、1つまたは複数のデジタル署名を含むトランザクション認証機能を使用します。

• 送信者アドレス：送信者のアカウントアドレス。

• ペイロード：ペイロードは、チェーン上の既存のエントリ関数を参照するか、インライン バイトコードとして実行される関数を含みます（スクリプトと呼ばれます）。さらに、入力引数のセットはバイト配列でエンコードされます。peer-to-peer取引の場合、入力には受取人の情報とその受取人に送金される金額が含まれます。

• ガス価格（指定通貨/ガス単位）：取引実行のために、送り手がガス1単位あたり支払う金額です。ガスとは、計算機、ネットワーク、ストレージの代金を支払う方法です。ガス単位は計算の抽象的な測定値であり、現実世界での固有の価値はありません。

• 最大ガス量：最大ガス量は、トランザクションが中断される前に消費することが許される最大ガス単位です。アカウントは少なくともガス価格に最大ガス量を掛けたものを持っていなければならず、さもなければ検証中にトランザクションが破棄されます。

• Sequence番号：トランザクションのSequence番号です。これは、取引実行時に送信者のアカウントに保存されているSequence番号と一致しなければなりません。トランザクションが正常に実行されると、リプレイ攻撃を防ぐためにアカウントのSequence番号がインクリメントされます。

• 有効期限：トランザクションが有効でなくなるまでのタイムスタンプです。

• チェーンID：このトランザクションが有効なブロックチェーンを特定するもので、署名ミスを防ぐためにユーザーをさらに保護します。

各バージョンiにおいて、状態変化はタプル(Ti, Oi, Si)で表され、それぞれ取引、取引出力、結果の元帳状態を含みます。決定論的関数Applyが与えられると、元帳状態Si-1を持つトランザクションTiの実行は、トランザクション出力Oiと新しい元帳状態Siを生成します。すなわち、Apply(Si-1,Ti) →(Oi, Si)です。

５.１.１　イベント

イベントはトランザクションの実行中に発行されます。各Moveモジュールは独自のイベントを定義し、実行時にそのイベントを発するタイミングを選択することができます。例えば、コインの送金時には、送り手と受け手の両方のアカウントからそれぞれSentEventとReceivedEventが発信されます。このデータは台帳内に保存され、Aptosノード経由で照会することができます。登録されたイベントにはそれぞれ固有のキーがあり、そのキーを使ってイベントの詳細を照会することができます。

同じイベントキーに発行された複数のイベントは、イベントストリーム、0から始まる順次増加する番号、タイプ、およびデータを含む各エントリを持つイベントのリストを生成します。各イベントは、何らかの型によって定義されなければなりません。特にジェネリックを使用している場合、同じまたは類似の型によって定義された複数のイベントが存在する可能性があります。イベントには関連するデータがあります。Moveモジュール開発者にとって一般的な原則は、データを変更しイベントを放出したトランザクションの実行前と実行後の基礎となるリソースの変更を理解するために必要なすべてのデータを含めることです。

トランザクションはイベントを生成することだけが可能で、イベントを読み取ることはできません。この設計により、トランザクションの実行は、履歴情報（例えば、以前に生成されたイベント）ではなく、現在の状態とトランザクションの入力のみの関数であることができます。

５.２　アカウント

各アカウントは、アカウントアドレスと呼ばれる256ビットの一意の値で識別されます。新しいアカウントは、既存のアカウントから送信されたトランザクションがcreate_account (addr) Move関数を呼び出したときに、元帳状態（セクション5.5参照）に作成されます。これは通常、トランザクションがまだ作成されていないアカウントアドレスにAptosトークンを送信しようとするときに起こります。利便性のために、Aptosは、転送前にまだ存在しない場合、暗黙的にアカウントを作成するtransfer(from, to, amount)関数もサポートしています。

新しいアカウントを作成するために、ユーザはまず署名鍵ペア(uk, sk)を生成します。次に、公開検証鍵vkの暗号ハッシュHを署名方式識別子（ssid）と結合して、所定の署名方式の新しいアカウントアドレスを導出します：addr = H（uk, ssid）。

アドレスaddrに新しいアカウントが作成された後、ユーザーはプライベート署名キーskを使ってaddrのアカウントから送信されるトランザクションに署名することができます。またユーザーは、skを積極的に変更するため、または漏洩の可能性に対応するため、skをローテートすることができます。アカウントアドレスは、作成時に公開検証キーから一度だけ導出されるため、これによってアカウントアドレスが変更されることはありません。

Aptosブロックチェーンは、アカウントを実世界のアイデンティティにリンクさせません。ユーザーは複数のキーペアを生成することで複数のアカウントを作成することができます。同じユーザーによって管理されるアカウントは、互いに本質的なつながりを持ちません。しかし、1人のユーザーが複数のアカウントを1つのウォレットで管理し、簡単な資産管理を行うことは可能です。この柔軟性により、将来のリリースに向けてプライバシーを保護するプリミティブを実験している間、ユーザーには仮名性が提供されます。一人のユーザーまたは一組のユーザーによって所有される複数のアカウントは、セクション7.4で説明するように、実行の並行性を高めるためのチャンネルも提供します。

５.３　Moveモジュール

Moveモジュールは、データ型（構造体）と手続きを宣言したMoveバイトコードを含みます。モジュールの識別は、モジュールが宣言されているアカウントのアドレスとモジュール名で行います。例えば、図2の最初の通貨モジュールの識別子は Ox1::coin です。モジュールは、図 2 のウォレットモジュールのように、他のオンチェーンモジュールに依存することができ、コードの再利用が可能になります。

つまり、各アカウントは最大で一つのモジュールを任意の名前で宣言することができます。例えば、図2のアドレス0x1にあるアカウントは、coinという名前の別のモジュールを宣言することができません。一方、アドレス 0x3 のアカウントは coin という名前のモジュールを宣言することができ、このモジュールの識別子は 0x3::coin となります。0x1::coin::Coin と 0x3::coin::Coin は異なる型であり、互換性はなく、共通のモジュールコードを使用することもできないことに注意してください。一方、0x1::coin::Coin<0x2::wallet::USD> と 0x1::coin:: Coin<0x2::wallet::JPY> は同じ汎用型の異なるインスタンスで、互換性を持って使用することはできませんが、共通のモジュールコードを使用することはできます。

モジュールは、同じアドレスにあるパッケージにまとめられます。このアドレスの所有者は、バイトコードとパッケージのメタデータを含むパッケージを全体としてオンチェーンに公開します。パッケージのメタデータは、パッケージがアップグレード可能か、不変かを決定します。アップグレード可能なパッケージでは、アップグレードが許可される前に互換性チェックが行われます。既存のエントリポイント関数を変更してはならず、リソースをメモリに保存してはなりません。ただし、新しい関数やリソースを追加することは可能です。

Aptosブロックチェーンのコアライブラリと構成からなるAptosフレームワークは、モジュールの通常のアップグレード可能なパッケージとして定義されています（セクション9.2参照）。

５.４　リソース

モジュールと同様に、アカウントアドレスにもデータ値を関連付けることができます。各アカウントアドレス内では、値はそのタイプによってキーが付けられており、各タイプの最大1つの値がアカウントに属しています。図3はその例です。アドレス0x50には1つの値が格納され、0x3::coin:.Coinが完全修飾された値です。コインが完全修飾型です。0x3 はコインモジュールが格納されているアドレス、coinはモジュール名、Coinはデータ型名です。汎用型の値も許容され、異なるインスタンス化されたものは異なる型として扱われます。これは拡張性のために不可欠であり、異なるインスタンスで同じ機能コードを共有することができます。

値の変更、削除、公開のルールは、データ型を定義するモジュールに記述されます。Moveの安全性と検証ルールにより、他のコードやエンティティが他のモジュールで定義されたデータ型のインスタンスを直接作成、変更、削除することを防ぐことができます。

アドレスの下に各タイプのトップレベルの値を1つだけ持つことは、一見制限的に聞こえるかもしれません。しかし、プログラマは他のデータを内部フィールドとするラッパータイプを定義することで、この制限を回避できるため、実際には問題にはなりません。図3のWallet構造体は、ラッパー型の使用方法の一例です。

また、すべてのデータ型がオンチェーンに格納できるわけではないことにも注意が必要です。データインスタンスをトップレベルの値として認定するには、そのデータ型にキー機能が必要です。同様に、ネストされた値にはストア能力が必要です。両方の能力を持つデータ型は、リソースとも呼ばれます。

５.５　元帳状態

Move仮想マシン（Move VM）の観点から、各勘定は値のセットとキー-値データ構造で構成されます。これらのデータ構造はテーブルエントリーと呼ばれ、BCS（Binary Canonical Serialization）形式で保存されます。このデータレイアウトにより、開発者は、多数のアカウントに複製された少量のデータや、少数のアカウントに保存された大量のデータに対して効率的に動作するスマートコントラクトを記述することができます。Moveモジュールは、アカウントデータと同様に、独立した名前空間の下に格納されます。Genesis ledger stateは、ブロックチェーン初期化時のアカウントとその関連する状態の初期セットを定義します。

発売当初は、Aptosブロックチェーンは単一の台帳状態によって表されます。しかし、採用が進み技術が発展するにつれ、Aptosはシャードの数をスケールアップしてスループットを高め（つまり、複数の元帳状態を可能にし）、シャード間で資産を移動またはアクセスするトランザクションをサポートする予定です。各元帳の状態は、特定のシャードのすべてのオンチェーン資産を維持し、ストレージへのアクセスにほぼ固定費を提供する、きめの細かいキーバリューデータストアで同じアカウントモデルを提供します。

６　安全なユーザーエクスペリエンス

何十億ものインターネットユーザーにアクセスするために、web3のユーザーエクスペリエンスは安全でアクセスしやすいものでなければなりません。以下のセクションでは、Aptosブロックチェーンが提供する、この目標に向けたいくつかの革新的な技術について説明します。

６.１　取引の実行可能性保護

取引に署名することは、署名者がその取引をブロックチェーンにコミットし実行することを承認することを意味します。時折、ユーザーは意図せず、または自分の取引が操作される可能性のあるすべての方法を十分に考慮せずに取引に署名することがあります。このリスクを減らすため、Aptosブロックチェーンはすべての取引の実行可能性を制約し、署名者を無制限の有効性から保護します。現在、Aptosブロックチェーンが提供する保護は、送信者のシーケンス番号、取引の有効期限、指定されたチェーン識別子の3種類です。

• トランザクションのシーケンス番号は、各送信者のアカウントに対して正確に1度だけコミットすることができます。その結果、送信者は、現在のアカウントのシーケンス番号が取引tのシーケンス番号より大きい場合、tはすでにコミットされているか、tがコミットされることはない（tが使用するシーケンス番号はすでに他の取引によって消費されているため）ことを観察することができます。

• ブロックチェーンの時間は、セクション7.3.2で説明したように、高い精度と周波数（通常はサブ秒）で進みます。 ブロックチェーン時間が取引tの有効期限を超えた場合、同様にtは既にコミットされているか、あるいはtがコミットされることはありません。

• すべての取引は、悪意のあるエンティティが異なるブロックチェーン環境間（例えば、テストネットとメインネット間）で取引を再生することを防ぐために、指定されたチェーン識別子を持ちます。

６.２　Moveベースのキー管理

セクション5.2で説明したように、Aptosアカウントはキーローテーションをサポートしており、秘密鍵の侵害、長距離攻撃、および既存の暗号アルゴリズムを破る可能性がある、将来の進歩に関連するリスクを減らすのに役立つ重要な機能となっています。さらに、Aptosアカウントは、新しいハイブリッドカストディモデルを可能にするのに十分な柔軟性を持っています。そのようなモデルでは、ユーザーはアカウントの秘密鍵を回転させる能力を、1人以上のカストディアンや他の信頼できるエンティティに委譲することができます。Moveモジュールは、これらの信頼できるエンティティに、特定の状況下で鍵を回転させる権限を与えるポリシーを定義することができます。例えば、エンティティは多くの信頼できる当事者によって保持されるk-out-of-n multi-sigキーによって表され、ユーザーの鍵紛失を防ぐために鍵回復サービスを提供するかもしれません（例えば、現在ビットコインの20%が回復不能なアカウントにロックアップされています）。

さらに、多くのウォレットは、クラウドインフラへの秘密鍵のバックアップ、マルチパーティ計算、ソーシャルリカバリーなど、様々な鍵回復スキームをサポートしていますが、それらは通常、ブロックチェーンをサポートせずに（すなわちオフチェーンで）実装されています。その結果、各ウォレットは独自の鍵管理インフラを実装する必要があり、関連する操作はユーザーにとって不透明なものとなっています。対照的に、Aptosブロックチェーン層で鍵管理機能をサポートすると、すべての鍵関連操作の完全な透明性が得られ、豊富な鍵管理機能を持つウォレットの実装がより簡単になります。

６.３　事前署名のトランザクションの透明性

今日、ウォレットは署名するトランザクションについてほとんど透明性を提供していません。その結果、ユーザーはしばしば簡単に騙されて、資金を盗み、壊滅的な結果をもたらすかもしれない悪意のある取引に署名してしまいます。これは、各取引によってアクセスされる、すべてのオンチェーンデータを列挙する必要があるブロックチェーンにも当てはまります。そのため、現在、ユーザーのセーフガードはほとんどなく、ユーザーはさまざまな攻撃にさらされやすくなっています。

これに対処するため、Aptosエコシステムは、トランザクションの事前実行のためのサービスを提供します。これは、署名の前にトランザクションの結果を（人間が読める形で）ユーザーに説明する予防措置です。これと、過去の攻撃や悪意のあるスマートコントラクトの既知の履歴を組み合わせることで、不正を減らすことができます。さらに、Aptosでは、ウォレットが実行中の取引に制約を指示することも可能です。これらの制約に違反すると、悪意のあるアプリケーションやソーシャルエンジニアリング攻撃からユーザーをさらに保護するために、トランザクションが中止されることになります。

６.４　実用的なライトクライアントプロトコル

ブロックチェーンクライアントとサーバー間の信頼を確立するためにAPIプロバイダーのTLS/SSL証明書のみに依存することは、クライアントを十分に保護することができません。有効な証明書がある場合でも、ウォレットとクライアントは提示されるデータの真正性と完全性に関して何の保証もありません。

その結果、APIプロバイダーは不正確な、または悪意のあるブロックチェーンデータを返し、第三者を欺き、二重支出攻撃を行う可能性があります。

これを防ぐため、Aptosは状態証明とライトクライアント検証プロトコルを提供し、ウォレットとクライアントが信頼できない第三者サーバーから提示されるデータの妥当性を検証するために使用できます。さらに、セクション7.6.2のタイムスタンプベースの状態証明を活用することで、ライトクライアントは常にアカウント状態の鮮度（例えば、数秒以内）の厳しい境界を保証することができ、ネットワーク構成の変更（エポック変化）を追跡するか、現在の信頼できるチェックポイント（ウェイポイント）を使用して最新状態に保つだけでよいのです。高頻度のタイムスタンプと安価な状態証明を組み合わせることで、Aptosブロックチェーンはクライアントにセキュリティ保証の向上を提供します。

さらにAptosノードは、チェーン上の特定のデータやアカウントを対象とした証明へのサブスクリプションを可能にするために、さらに細かく調整できるリッチで高性能なストレージインターフェースも公開します。これは、フルノードの実行や相当数のトランザクションを処理する必要なく、最小限の検証可能なデータを保持するためにライトクライアントによって活用されることができます。

７　パイプライン化、バッチ処理、並列トランザクション処理

スループットを最大化し、並行性を高め、エンジニアリングの複雑さを軽減するために、Aptosブロックチェーン上のトランザクション処理は、個別のステージに分割されています。各ステージは完全に独立しており、個別に並列化可能で、現代のスーパースカラー・プロセッサー・アーキテクチャに似ています。これは性能面で大きな利点をもたらすだけでなく、Aptosブロックチェーンがバリデータとクライアントの新しい相互作用のモードを提供することを可能にします。例えば、以下のようなものです。

• 特定のトランザクションが永続化されたトランザクションのバッチに含まれる場合、クライアントに通知することができます。永続化された有効なトランザクションは、間もなくコミットされる可能性が高いです。

• 永続化されたトランザクションのバッチが注文されたときに、クライアントに通知することができます。したがって、実行されたトランザクション出力を決定する待ち時間を短縮するために、クライアントは、バリデータがリモートで実行を完了するのを待つのではなく、ローカルでトランザクションを実行するように選択することができます。

• クライアントは、バリデータによる認証済みトランザクションの実行を待ち、 認証済み結果に対して状態同期を実行することを選択できます(たとえばセクション8を参照)。

Aptosのモジュール設計は、単一のモノリシックなアーキテクチャではなく、個々のモジュールに変更を加えることができるため、開発速度を助け、より速いリリースサイクルをサポートします。同様に、モジュール設計は、バリデータを単一マシンから拡張するための構造化されたパスを提供し、追加の計算、ネットワーク、およびストレージリソースへのアクセスを提供します。図4は、さまざまな処理段階におけるトランザクションのライフサイクルを示しています。

７.１ バッチ処理

バッチ処理は、Aptosブロックチェーンにおける操作のあらゆる段階の一部である重要な効率最適化です。取引は、取引の普及中に各バリデータによってバッチにグループ化され、バッチはコンセンサス中にブロックに結合されます。また、実行、保存、台帳認証の各フェーズでは、バッチ処理により、順序の入れ替え、演算の削減（重複計算や署名検証など）、並列実行の機会が提供されます。

トランザクションをバッチにまとめると、例えば、配信を実行する前にトランザクションのバッチを蓄積するために200ミリ秒待つなど、わずかな遅延が発生する可能性があります。しかし、バッチングは最大待ち時間や最大バッチサイズに関して簡単に設定できるため、分散型ネットワークは待ち時間と効率性を自動的に最適化することができます。バッチングはまた、トランザクションに優先順位をつけ、熱狂的なクライアントからの意図しないサービス拒否（DoS）攻撃を避けるための効率的な手数料市場も可能にします。

７.２　継続的な取引の普及

Narwhal & Tuskの主要な洞察に従い、Aptosブロックチェーンにおける取引の普及はコンセンサスから切り離されています。バリデータはトランザクションのバッチを継続的に互いに配信し、利用可能なネットワーク資源をすべて同時に利用します。バリデータvによって配信された各バッチは永続化され、バッチダイジェストへの署名がvに送り返されます。セクション7.3で定義された合意要件に従い、バッチダイジェストへの任意の2f + 1ステーク加重署名は、可用性の証明（PoAv）を形成しています。この証明は、少なくともf +1個のステークに応じた誠実なバリデータが バッチを保存していることを保証するものであり、したがって、すべての誠実なバリデータが実行前にそれを取得することができるようになります。

トランザクションのバッチを無限に持続させると、バリデータが記憶装置を使い果たしてクラッシュすることで、DoS攻撃ベクトルを開くことができます。これを防ぐため、トランザクションの各バッチには関連するタイムスタンプを設定します。バッチのタイムスタンプは、各バリデータでの効率的なガベージコレクションを可能にします。さらに、バリデータごとのクォータメカニズムは、潜在的なビザンチン攻撃のような極端な状況においても、バリデータの容量不足を防ぐように設計されています。バッチはまた、安定したストレージへの永続化に合意する前に検証されるサイズ制約を持ちます。最後に、トランザクションの重複を排除しキャッシュするためのいくつかの最適化により、ストレージコストを削減し、並列実行エンジンとの性能の良い統合を保証します。

７.３　ブロックメタデータの順序付け

一般的な誤解の一つは、コンセンサスが遅いため、ブロックチェーンのスループットとレイテンシー（遅延時間）の主要なボトルネックになっているというものです。Aptosブロックチェーンの重要な革新的技術の一つは、取引の普及、取引の実行/保存、元帳の証明など、合意に関連しない作業を合意段階から切り離すことです。取引の普及を合意段階から切り離すことで、非常に低い帯域幅（ブロックメタデータと証明のみ）で注文を行うことができ、高い取引スループットと最小限のレイテンシーを実現しています。

今日、Aptosブロックチェーンは、楽観的に反応するBFTコンセンサスプロトコルであるDiemBFTv4の最新版を活用しています。一般的なケースでのコンセンサスは、2回のネットワーク往復で済み（往復時間は世界中で通常300ミリ秒未満）、リーダーの評価メカニズムを通じて欠陥のあるバリデータに動的に調整されます。オンチェーンリーダーレピュテーションメカニズムは、ウィンドウ内でブロックのコミットに成功したバリデータを昇格させ、参加していないバリデータを降格させます。この新しいメカニズムは、分散環境における性能を大幅に向上させ、それに応じて適切なインセンティブのためのインフラを提供し、失敗したバリデータがスループットとレイテンシーに与える影響を迅速に最小化します。

DiemBFTv4は部分的な同期のもとで有効性を保証し、非同期のもとで安全性を保証します。このときバリデータの総ステークが > 3f +1であり、ステークに応じた最大f個の欠陥バリデータが存在します。DiemBFT04は、2019年以降、数十のノードオペレータとマルチウォレットエコシステムを使用して、いくつかのイテレーションで広範囲にテストされています。また、私たちの最近の研究（例えば、Bullshark）や、ブロックメタデータの順序と最終性を決定するためにブロック履歴と関連する通信に依存する他のプロトコルの実験も行っています。

図5に示すように、コンセンサスブロックと提案タイムスタンプはリーダーが提案し、他のバリデータによって合意されます。各コンセンサスブロックには、バッチメタデータとプルーフのみが含まれることに注意してください。実際のトランザクションはブロック内に必要ありません。PoAVはトランザクションのバッチが注文後の実行フェーズで利用可能になることを保証しているからです（セクション7.2参照）。バリデーターは、証明とブロックメタデータの基準を満たした後、リーダーの提案に投票できます(例: 提案タイムスタンプ < ブロック有効期限)。

７.３.１ ブロックチェーンの時間

Aptosブロックチェーンは、提案されたすべてのブロックと、それに対応するそのブロック内のすべての取引について、おおよその、合意された、物理的なタイムスタンプを採用します。このタイムスタンプは、多くの重要なユースケースを可能にします。例えば、以下のようなものです。

• スマートコントラクトにおける時間依存のロジックです。例えば、あるオークションの入札はすべて木曜日の正午までに受けなければならない、というエンコードを開発者が希望しているとします。

• オラクルはオンチェーンデータを公開するため、イベントの関連付けや実世界のデータからの遅延を処理するために、正確で信頼できるオンチェーンタイムスタンプが必要とされます。

• クライアントは、ブロックチェーンに対して自分がどれだけ最新であるかを見分けることができます。セキュリティ上の理由から、古いデータや長距離攻撃を避けるために、クライアントはアカウントの状態が更新されたときの高精度のタイムスタンプにアクセスできる必要があります。

• 信頼性の高いタイムスタンプでブロックチェーンを監査することで、法的に強制される支払いが期待される要件を満たすことを保証するなど、オフチェーンイベントとの強い相関性を実現します。

• トランザクションの有効期限は、直近のコミットされたタイムスタンプに基づく。クライアントのトランザクションに対する追加の保護として、クライアントはトランザクションの有効期限を選択することができます。セクション6.1で説明します。

Aptosブロックチェーンは、ブロック内の全取引のタイムスタンプに関して、以下の保証を提供します。

• ブロックチェーンでは、時間は単調に増加します。つまり、ブロックB1 < ブロックB2 であればB1.T ime < B2.T ime となります。

• ある取引ブロックがタイムスタンプTで合意された場合、少なくともf + 1人の誠実なバリデータはTが過去であると判断しています。正直なバリデータは、自身のクロック≧タイムスタンプTのときのみ投票します。セクションを7.2参照。

• ある取引ブロックがタイムスタンプTで署名のクォーラムを満たす場合、正直なバリデ ータはそのようなブロックを提供しません。 バリデータは、自分の時計がタイムスタンプTを超えるまで、 そのようなブロックを他のバリデータに提供しません。

最新のタイムスタンプはコミットされたブロックごとに更新され、そのブロック内のすべてのトランザクションのタイムスタンプとして使用されます。ネットワークが同期の場合、トランザクションのブロックはネットワークの1往復ごとにコミットされ、高速更新と高い信頼性を持つクロックを提供します。 トランザクションのブロック内の順序は、必要に応じてより細かい粒度を決定することができます。

７.４　トランザクションの並列実行

コンセンサスブロックメタデータが発注されると、どのバリデータ、フルノード、 クライアントでもトランザクションを実行することができます。少なくとも2f +1 stakeの重み付けをしたバリデータが、提案されたバッチのトランザクションを検証可能な状態で持続しています。トランザクションの配布は継続的に行われるため、時間の経過とともに、誠実なバリデ ータはトランザクションバッチをさらに受信することになります。もしある誠実な検証者が、実行段階に達するまでに注文したバッチの取引を受け取っていない場合、少なくともf +1 人のステークウェイト付きバリデータ（ステークウェイト付き PoAV署名者の半数以上）が誠実であることを知っているので、2f +1 人のステークウェイト付きバリデータから取引をダウンロードすることが可能です。

ブロックチェーンの重要な目標は、可能な限り並列実行を可能にすることです。Aptosブロックチェーンは、データモデルと実行エンジンの両方からこの方向性を前進させます。

７.４.１　並列データモデル

Moveデータモデルは、データとモジュールのグローバルアドレッシングをネイティブにサポートします。データやアカウントに重複する競合がないトランザクションは、並行して実行することができます。Aptosブロックチェーンで使用されるパイプライン設計を考えると、トランザクションのグループを並べ替えることで競合の数を減らし、それによって並行性を向上させることができます。

トランザクションが同じオンチェーン値のセットを変更する場合でも、トランザクション実行プロセスの多くを並列化することが可能です。Aptosブロックチェーンは、変更されたアカウント状態ではなく、アカウント状態への変更を記述する新しい概念、デルタライトを導入しています（例えば、最終値を単純に決定するのではなく、整数をインクリメントします）。すべてのトランザクション処理を並行して完了し、その後、デルタライトを競合する値に対して正しい順序で適用することで、決定論的な結果を確保することが可能です。

Aptosブロックチェーンは、時間をかけて、並行性を向上させる方法（例えば、読み取り/書き込みヒントを活用する）でデータモデルを強化し、また人間工学を改善し、開発者がオンチェーン値を作成、変更、構成することをより自然にすることを継続します。Moveは、言語レベルだけでなく、プラットフォーム固有の機能によって、このような改善を柔軟に行うことができます。

７.４.２　並列実行エンジン

Block-STMの並列実行エンジンは、特定の順序が与えられた場合に最大の並列性を可能にする楽観的同時実行制御とともに、順序付けられた一連のトランザクションの競合を検出して管理します。

トランザクションのバッチは楽観的に並列実行され、実行後に検証されます。検証に失敗すると、再実行されます。Block-STMは書き込みと書き込みの競合を避けるため、複数バージョンのデータ構造を使用します。同じ場所へのすべての書き込みは、そのトランザクションIDと書き込みトランザクションが最適に再実行された回数を含むバージョンと一緒に保存されます。トランザクションtxがメモリロケーションを読み取るとき、あらかじめ設定された順序でtxの前に現れる最も高いトランザクションによってこのロケーションに書き込まれた値を、関連するバージョンとともにマルチバージョンデータ構造から取得します。

Block-STMは、すでにAptosブロックチェーンに統合されています。Block-STMの性能の可能性を完全に理解するために、インメモリデータベースを用いた実行のみの（エンドツーエンドではない）独立したベンチマークとして、非自明なピアツーピアMoveトランザクション（すなわち、トランザクションごとに8回の読み取りと5回の書き込み）の実験を実行しました。図6では、Block-STMの実行結果を示しています。各ブロックは10kトランザクションを含み、アカウント数によってコンフリクトとコンテンションのレベルが決定されます。

Block-STMは、低競争下では32スレッドの逐次実行に比べて16倍のスピードアップを達成し、高競争下では8倍以上のスピードアップを達成しています。Block-STMは、ブロックチェーン分野の他の並列実行エンジンとは異なり、あらゆるワークロードから固有の並列性を動的かつ透過的に（ユーザーからのヒントなしに）抽出することができます。読み書きの対象となるデータ位置を前もって知っておく必要がある並列実行環境と比較して、Block-STMはより複雑なトランザクションを同時にサポートすることができます。この特性により、トランザクションの数が少なくても効率的で、コストを削減し、ユーザーに低遅延を提供することができます。おそらく最も重要なことは、アトミックトランザクションを複数の小さなトランザクションに分割することで、複雑な状態の結果を伴う単一トランザクションのall-or-nothingセマンティクスを壊すことです。Block-STMで表現力豊かなトランザクションセマンティクスと並列実行を組み合わせることで、開発者は両者の長所を享受することができます。

ブロックメタデータの順序付けステップは、並列実行フェーズでのトランザクションの再順序付けを妨げないことに注意してください。トランザクションは、並列実行の同時実行性を最適化するために、1つまたは複数のブロックにわたって並べ替えが可能です。唯一の要件は、並べ替えはすべての誠実なバリデータに対して決定論的でなければならないことです。並列実行を最適化すると同時に、並べ替えにランダム性を持たせることで、性能を向上させることができ、また最大抽出値 (MEV) 技術による有益なバリデータの並べ替えを阻止できる可能性があります。このパイプライン化された設計には、「Order-then-reveal」MEV耐性戦略も組み込むことができます。

ブロックSTMとトランザクションの並べ替えは、実行の並列性を高めるための補完的な技術です。これらは、トランザクションの読み取り/書き込みアクセスヒントと組み合わせて、さらに並行性を高めることができます。

７.５　バッチストレージ

並列実行フェーズでは、グループ内の全トランザクションの書き込みセットが生成されます。これらの書き込みセットは、実行速度を最大化するためにメモリに保存され、次に実行されるブロックまたはブロックのセットのためのキャッシュとして使用されることができます。重複する書き込みは、安定したストレージに一度だけ書き込まれれば大丈夫です。バリデータがメモリ内の書き込みセットを保存する前に失敗した場合、ブロックメタデータの順序付け段階から並列実行を再開するだけで大丈夫です。書き込みセットのバッチ保存を並列実行のステップから切り離すことで、並列実行を効率的に行えるようになります。要約すると、書き込みセットをバッチ処理することで、ストレージ操作の回数を減らし、より効率的で大規模なI/O操作を利用することができます。

ライトセットキャッシングのために確保されるメモリ量は、マシンごとに手動で設定でき、自然なバックプレッシャーメカニズムを提供します。特定の I/O およびメモリ環境に合わせてチューニングするために、必要に応じてバッチの粒度を並列実行ブロックの粒度と異ならせることができます。

７.６ 台帳認証

パイプラインのこの時点で、個々の検証者はコミットされたトランザクションのブロックに ついて新しい状態を計算しました。しかし、検証済みライトクライアントと状態の同期を効率的にサポートするために、Aptosブロックチェーンは、元帳の状態と同様に元帳の履歴のための元帳認証を実装しています。Aptosブロックチェーンの1つの重要な違いは、元帳認証がトランザクション処理のクリティカルパス上になく、必要であれば完全にアウトオブバンドで実行することも可能であるということです。

７.６.１　台帳の履歴認証

バリデータは、トランザクションをその実行結果と共に、グローバルな認証済み台帳データ構造に追加します。トランザクション出力の一部は、Moveによってアクセス可能なグローバルな状態に対して行われた変更からなる状態書き込みセットです。このデータ構造の短い認証子は、新たに実行されたトランザクションのバッチを含む元帳履歴へのバインディングコミットメントです。トランザクションの実行と同様に、このデータ構造の生成は決定論的です。

各バリデータは、生成されたデータベースの新バージョンに対して、短い認証子に署名します。バリデータは最近の署名済み短認証子のセットを互いに共有し、クォーラム署名済み短認証子を一括して集約し、さらに最近のクォーラム署名済み短認証子を互いに共有します。

この集合署名を使用することで、クライアントはプロトコルのBFT特性に従って、データベースのバージョンが、完全で有効かつ不可逆な元帳の履歴を表していると信頼することができます。クライアントは、任意のバリデータ(またはフルノードなどのサードパーティのデータベース複製)に問い合わせてデータベースの値を読み取り、その結果を認証子と目的のデータの証明書を使用して検証することができます。

７.６.２　定期的な状態の認証

Moveからアクセス可能なグローバルステートの全体は、台帳の履歴の要約と同様に、歴史のどの時点でも短い認証子に要約することが可能です。グローバル状態はランダムアクセスのため（追記のみの台帳履歴と異なり）、この認証の維持には大きなコストがかかります。とはいえ、データ構造を大量に一括して更新する場合、更新を並列に計算し、さらに個々の状態の値が変化したときに更新しなければならない部分の重複を利用することができます。Aptosブロックチェーンは、共有更新の重複を減らすために、意図的にグローバル状態を定期的に認証するだけです。

決定論的かつ設定された間隔の間、ネットワークは、その出力の一部としてグローバル状態の認証子を含む状態チェックポイントトランザクションを発行します。このようなバージョンはステートチェックポイントと呼ばれます。2つのチェックポイント間のギャップが大きいほど、トランザクションごとに状態認証データ構造を更新するための償却コストは低くなります。

状態チェックポイントを用いると、グローバルな状態をすべて保存することなく、チェックポイントから任意の状態値を信頼できる方法で読み出すことができます。この機能は、状態のインクリメンタルな同期、バリデータ間のシャード化されたストレージ、 ステートレスバリデータノード、ストレージに制約のあるライトクライアントなどの用途に有用です。

しかし、ステートチェックポイントは定期的に行われるため、元帳の状態の特定のバージョンに対する証明を得るには、欠落した状態の代替のための追加のトランザクションを実行するか、認証された元帳の履歴からそれらを含める証明を行う必要があります。

ステートチェックポイントは、元帳履歴の特定の取引バージョンに関連付けられ、それゆえ、セクション7で述べた取引バッチに関連付けられたタイムスタンプに束縛されます。タイムスタンプがあれば、ライトクライアントは証明されたステート値の最新性を理解することができます。タイムスタンプがなければ、ライトクライアントの証明は、はるか過去の状態の有効性しか保証できず、関連性の保証はほとんどありません。また、ステート証明のタイムスタンプは、過去のアクセスの追跡や監査目的（トークン備蓄の時間ごとの平均残高の計算など）に必要です。

ステートチェックポイントは、以前のステートチェックポイントと、それ以降のトランザクション出力における状態交替に基づいて導き出すことができます。したがって、ステートチェックポイントを安定したストレージに保存することは、トランザクション処理のクリティカルパスである必要はありません。また、ステートチェックポイントを永続化する際にも、有益なバッチング効果が存在します。最近のステートチェックポイント（というよりその間の差分）をメモリにキャッシュし、定期的なステートチェックポイントのみを安定したストレージにダンプすれば、ストレージ帯域の消費を大幅に抑えることができます。チェックポイントを永続化するために選択する方法は、認証済みデータ構造の計算には影響しません。したがって、これはノードごとの選択となります。ノードオペレータは、メモリ容量とストレージ帯域幅の適切なトレードオフを設定することができます。

８　状態の同期化

Aptosブロックチェーンは、エコシステムのすべての参加者に高スループット、低レイテンシーシステムを提供することを目的としています。その結果、ブロックチェーンは、ライトクライアント、フルノード、およびバリデーターにブロックチェーンデータを普及、検証、および持続させるための効率的な状態同期プロトコルを提供する必要があります。さらに、同期プロトコルは、異なるユーザーやユースケースを考慮し、ネットワーク内のリソース制約や異質性にも寛容でなければなりません。たとえば、アーカイブフルノードがブロックチェーンの履歴と状態全体を検証して持続することを可能にする一方で、ライトクライアントがAptosブロックチェーンの状態の小さなサブセットのみを効率的に追跡することを可能にしなければなりません。

この特性を実現するために、Aptosブロックチェーンは、バリデータ、フルノード、および他の複製者によって提供される認証済み台帳履歴と認証済み状態証明（セクション7.6.1参照）を活用して、柔軟で設定可能な同期プロトコルを提供します。具体的には、ネットワークの参加者は、それぞれのユースケースと要件に最適化するために、異なる同期戦略を選択することができます。

例えばフルノードの場合、Aptosは時間の始まりからのすべてのトランザクションを処理する機能や、ブロックチェーンの履歴を完全にスキップし、ウェイポイントを使用して最新のブロックチェーンの状態のみを同期する機能など、複数の同期ストラテジーを許可しています。ライトクライアントの場合、戦略には、特定のアカウントやデータ値など、部分的なブロックチェーンの状態の同期や、検証済みアカウントバランスのフェッチなど、検証済み状態の読み込みの有効化などがあります。どのような場合でも、Aptosは参加者がフェッチ、処理、保持するデータの量と年齢を設定することを可能にします。

状態の同期に柔軟で設定可能なアプローチを採用することで、Aptosは様々なクライアントの要件に適応し、将来的に新しく、より効率的な同期戦略を提供し続けることができるのです。

９　コミュニティの所有権

Aptosブロックチェーンは、幅広く多様なコミュニティによって所有、運営、管理されます。ネイティブAptosトークンは、取引とネットワーク手数料、プロトコルアップグレードとオンチェーン/オフチェーンプロセスに関するガバナンス投票、およびプルーフオブステークモデルによるブロックチェーンの安全確保に使用される予定です。アプトストークンエコノミクスの完全な説明は、将来の出版物に続きます。

９.１　取引とネットワーク料金

すべてのAptosトランザクションにはガス単価（Aptosトークンで指定）があり、バリデータはネットワーク内で最も価値の高いトランザクションを優先的に処理することができるようになっています。さらに、パイプライン化されたモデルの各段階で、価値の低いトランザクションを破棄する機会が複数あります（システム容量があるときにブロックチェーンが効率的に動作することを可能にします）。時間の経過とともに、アプトスブロックチェーンの使用コストが、ハードウェアの展開、メンテナンス、ノード運用の現実のコストに比例するように、ネットワーク料金が展開される予定です。さらに、開発者は、計算、ストレージ、ネットワーキングの間で異なるコストのトレードオフを持つアプリケーションを設計する機会を得ることができます。

９.２　ネットワークガバナンス

Aptosブロックチェーンの重要な機能変更と改善はすべて、提案、実装、テスト、展開など、いくつかの段階を経て行われます。この構造により、関係者や利害関係者がフィードバックを提供し、懸念を共有し、提案を行う機会が生まれます。最終段階である配備は、通常2つのステップで達成されます。まず、新機能を搭載したソフトウェアリリースを各ノードに配備し、次に、機能フラグやオンチェーン構成変数などを介して機能を有効にします。

ノードオペレータによる各ソフトウェアの配備は、新しいソフトウェアがサポートされているリリースと相互運用できるように、後方互換性がなければなりません。新しいソフトウェア・バージョンのデプロイは、異なるタイムゾーンのオペレータや外部の問題を考慮し、数日にわたって行われることもあります。十分な数のノードがアップグレードされると、合意されたブロック高やエポック変化などの同期ポイントによって、新機能の有効化がトリガーされる可能性があります。緊急時（ダウンタイムが避けられない場合など）には、ノードオペレータによる手動かつ強制的な変更、最悪の場合はネットワークのハードフォークによって有効化されることもあります。

他のブロックチェーンと比較して、Aptosブロックチェーンはその構成をオンチェーンでエンコードしています。すべてのバリデータはブロックチェーンの現在の状態と同期し、現在のオンチェーン値に基づいて正しい構成（コンセンサスプロトコルやAptosフレームワークのバージョンなど）を自動的に選択する機能を備えています。Aptosブロックチェーンのアップグレードは、この機能によりシームレスかつ瞬時に行われます。

イネーブルメントプロセスに柔軟性と設定可能性を提供するために、Aptosブロックチェーンは、トークン保有者が自分のステークトークンウェイトに関して投票することができるオンチェーンガバナンスをサポートする予定です。オンチェーン投票プロトコルは公開され、検証可能であり、瞬時に行うことができます。オンチェーンガバナンスは、ソフトウェアを導入することなく、二項対立のない結果を実現することも可能です。例えば、オンチェーンリーダー選挙プロトコルのパラメータは、オンチェーンガバナンスによって変更することができます。一方、事前に知られている同期ポイントでは、すべての変更を事前に知っていなければならないため、動的な変更を扱うことはできません。

オンチェーンガバナンスは、時間をかけてアップグレード管理プロセス全体に展開することができます。例としては、

1. トークン保有者は、新しい量子抵抗性署名方式への移行についてオンチェーン投票

2. 開発者は新しい署名方式を実装・検証し、新しいソフトウェアリリースを作成

3. バリデータは、ソフトウェアを新しいリリースにアップグレード

4. トークン保有者が新しい署名方式を有効にするためにオンチェーンで投票すると、オンチェーン構成が更新され、変更が有効

オープンソースプロジェクトであるAptosブロックチェーンは、コミュニティの強力なフィードバックに依存し、適切なプロセスを管理するためにオンチェーンガバナンスを使用する予定です。オフチェーンアップグレードの有効化は、特定の条件下ではまだ必要かもしれませんが、時間の経過とともに最小化される予定です。

９.３　プルーフオブステーク コンセンサス

Aptosブロックチェーン上の取引検証に参加するには、検証者は必要最低限のステークされたAptosトークンを持っている必要があります。ステークされた金額は、ブロックメタデータの順序付けの際の投票重みとリーダー選択だけでなく、取引普及の際の2f +1ステーク重み付けPoAvに比例して影響します。バリデータは、自分とそれぞれのステイカーとの間で報酬の分配を決定します。ステーカーは事前に合意した報酬の分配を行うために、任意の数のバリデータを選択し、そのトークンをステークすることができます。各エポック終了時に、バリデータとそれぞれのステーカーは、関連するオンチェーン移動モジュールを介して報酬を受け取ります。

十分なステークを持つバリデータ・オペレーターは誰でも自由にAptosブロックチェーンに参加することができます。必要な最低ステークを含むすべてのパラメータは、セクション 9.2 で説明するオンチェーン有効化プロセスによって設定することができます。

１０　パフォーマンス

セクション7で述べたように、Aptosブロックチェーンは、その並列、バッチ最適化、およびモジュール式のトランザクション処理パイプラインによって最適なスループットとハードウェア効率を達成することができます。コンセンサスアップグレード、デルタライト、トランザクションヒント、クリティカルパスキャッシングなどの追加のパフォーマンスイニシアティブは、時間の経過とともにスループットを増加させ、効率を向上させ続けるでしょう。

今日、ブロックチェーンのスループットは通常、1秒あたりのトランザクション数で測定されます。しかし、トランザクションやインフラにかかるコストや複雑さが多岐に渡ることを考えると、これはシステムを比較するための不正確な方法と言えるでしょう。トランザクションのレイテンシーも、提出から確定までの開始点と終了点が実験によって異なるため、同様に欠陥があります。

さらに、システムによっては、トランザクションの入出力に関する事前知識を必要とし、論理トランザクションをより小さな、より複雑でないトランザクションに分割することを余儀なくされます。トランザクションを分割すると、開発者が何を達成しようとしているのかを考慮することなく、ユーザー体験が低下し、レイテンシーとスループットに人為的な影響を与える結果となります。これに対し、Aptosのアプローチは、開発者が制限なく自由に構築できるようにし、合成トランザクションではなく、現実のユースケースに関してスループットとレイテンシーを測定することです。

Aptosブロックチェーンは、個々のバリデータの性能を最適化するとともに、ネットワークにバリデータを追加するスケーリング手法の実験も続けていく予定です。どちらの方向にも明確なトレードオフがあります。並列実行機能を持つブロックチェーンであれば、より強力なハードウェアを必要とするか、あるいは各バリデータを個々のマシンのクラスタとして構成することで、さらなる並列実行をサポートすることができます。しかし、バリデータ運用者のコストと複雑さに見合ったグローバルバリデータの数には、現実的な限界があります。クラウドサービスにおけるサーバーレスデータベースの台頭と普及は、 この種の複雑な分散システムを効率的に展開・維持できる事業者がいかに少ないかを例示しています。

１０.１　同質的ステートシャーディング

最初は、Aptosブロックチェーンは単一の元帳状態で起動されます。時間の経過とともに、Aptosネットワークは分散性を維持しながら水平方向のスケーラビリティを確保するための独自のアプローチを取ることになります。これは、それぞれが同質のAPIと第一級の概念としてのシャーディングを提供する、複数のシャーディングされた元帳状態を通じて行われます。Aptosトークンは、すべてのシャードにおける取引手数料、ステーキング、およびガバナンスに使用されます。

データは同種のブリッジを通じてシャード間で転送することができます。ユーザーと開発者は、ニーズに応じて独自のシャーディングスキームを選択することができます。例えば、開発者は新しいシャードを提案したり、既存のシャード内にユーザーを集めて高いシャード内接続を実現したりすることができます。また、シャードのシステム特性は様々です。1つのシャードは、以下のように計算を最適化することができます。あるシャードはSSDに最適化し、別のシャードは大型ハードディスクに最適化し、演算性能は低くすることができます。異なるシャード間でハードウェアの柔軟性を提供することで、開発者はアプリケーションに適したシステム特性を利用することができます。

まとめると、同種のステート・シャーディングは水平方向のスループット拡張の可能性を提供し、開発者はシャード間で単一のユニバーサル・ステートでプログラムすることができ、ウォレットはそのユーザーのためにシャーディングされたデータを簡単に取り込むことができます。これにより、Moveスマートコントラクトプラットフォームのシンプルさだけでなく、性能面でも大きなメリットが得られます。

＊オリジナルのホワイトペーパーはこちら

https://github.com/aptos-labs/aptos-core/blob/main/developer-docs-site/static/papers/whitepaper.pdf

ここに記載された内容は、あくまでオリジナルを日本語訳にしたものであり、私KeiCryptoによるものではありません。著作権はオリジナルの作成者のものです。

The content herein is only a Japanese translation of the original and is not by me, KeiCrypto. The copyright belongs to the original author.