# 　Suiスマートコントラクト　プラットフォーム By [KeiCrypto](https://paragraph.com/@keicryptomoon) · 2022-08-19 --- **The MystenLabs Team**　[hello@mystenlabs.com](mailto:hello@mystenlabs.com) １　はじめに ------ 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独自の機能（オレンジ色の文字で示す）です。 ![表1：モジュール](https://storage.googleapis.com/papyrus_images/bb921765d6f8797a64fa8488f5a9cc1f8659d65e996601288186371a8b741eac.png) 表1：モジュール Moveコードは、表1に定義された構造を持つモジュールに編成されています。モジュールは、名前付き構造体宣言と名前付き関数宣言の集合から構成されます（これらの宣言の例は2.1節で説明しています）。また、モジュールはモジュール初期化子として特別な関数宣言を含んでいます。この関数は、モジュールがオンチェーンで公開されるときに一度だけ呼び出されます。 構造体宣言は、フィールド名が格納可能な型にマッピングされた、名前付きフィールドの集合体です。構造体宣言には、オプションで能力のリストも含まれます（格納可能な型と能力の説明については、第2章を参照してください）。構造体宣言には、能力制約を持つ汎用的なパラメーターのリストを含めることもでき、例えば、 struct Wrapper{ t: T } のような場合は、汎用構造体宣言と呼びます。ジェネリック・パラメーターは、構造体フィールドの宣言時に使われる型を表します。構造体宣言時には未知数で、構造体のインスタンス化時（つまり、構造体の値が生成される時）に具体的な型が提供されます。 関数宣言には、パラメータの型、戻り値の型、関数本体を構成する命令のリストが含まれます。関数宣言には、能力制約のある一般的なパラメーターのリストを含めることもでき、その場合は、例えば、 fun unwrap(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\\\]](https://arxiv.org/abs/2110.05043%5C%5D) を参照してください。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](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. --- *Originally published on [KeiCrypto](https://paragraph.com/@keicryptomoon/sui)*