​

アルゴランドのスマートコントラクト・アーキテクチャ　by シルビオ・ミカリ

 

この投稿では、Jing Chen、Maurice Herlihy、Victor Luchangco、Silvio Micali、Liuba Shriraが開発したアルゴランドのスマートコントラクト・アーキテクチャのオフチェーン・コンポーネントに焦点を当てています。完全なテクニカルペーパーは近い将来公開される予定です。

 

スマートコントラクトはブロックチェーンをプログラム可能にします。自動販売機のように、スマートコントラクトは、資産を譲渡するための明確に定義された手順を確立します。たとえば、アリスはボブが発行したトークンを購入したいので、ボブのスマートコントラクトにコインを送ります。コントラクトのコードはコインを数え、おそらくアリスが資格のある投資家のコントラクトのデータベースにあることを確認してから、正しい数のトークンをアリスのアカウントに転送します。交換は透明です。アリスはコントラクトのコードを検査でき、コードはボブの参加なしで実行されます。

 

この投稿では、アルゴランドのスマートコントラクト・アーキテクチャについて説明し、アルゴランドが以前のアプローチと大きく異なる理由を説明します。特に、アルゴランドのユーザーは複数の種類の問題を解決する必要があるため、アルゴランドのスマートコントラクト・アーキテクチャには複数の種類のツールが含まれています。

 

​

2層アーキテクチュア

 

まず、日常的なニーズに対して、アルゴランドはレイヤー1スマートコントラクトを提供しています。一般的な日常のトランザクションのための安全な高速パスです。（そのようなスマートコントラクトをすぐに思い出します。）2番目に、アルゴランドは、よりカスタマイズが必要なスマートコントラクトの「ロングテール」に対して、（レイヤー2）オフチェーン・コントラクトを提供します。これらが、このブログで紹介するスマートコントラクトです。

 

​

イーサリアムのスマートコントラクトの比較

 

イーサリアム・ブロックチェーンはスマートコントラクトの機能を最初に実証したものであるため、イーサリアム・スマートコントラクトは後継技術を分析するための自然な出発点です。彼らの長所と短所はブロックチェーン・コミュニティで広く議論されており、その議論はスマートコントラクト言語のさまざまな新しいデザインを生み出しました。ここでは、アルゴランド・ブロックチェーンで特に重要な2つの問題に焦点を当てます。

 

1．単純な問題は、しばしば複雑で壊れやすい解決策を必要とします

 

アリスとボブが、アリスが100の「ドルコイン」をボブに送信すると、ボブが100の「ボブトークン」をアリスに転送することに同意するとします。アリスは、コインを送金した場合にトークンを確実に取得できることを、またボブも同様の安心を求めます。この種のトランザクションは、相互に疑わしいパーティによって制御される転送が両方とも発生するか、または両方が発生しないかのどちらかであり、アトミック・スワップと呼ばれます。イーサリアムのスマートコントラクトを使用してアトミック・スワップをプログラミングするには、ハッシュされたタイムロック・コントラクト（または同様の何か）が必要です。これは微妙なタイミングのあるマルチフェーズ・プロトコルで、プログラミングエラーは致命的です。対照的に、以前の投稿で説明したように、アルゴランドのレイヤー1スマートコントラクトは、アトミック・スワップおよび関連する問題に対するシンプルで安全なソリューションを提供します。

 

2．誰もが他の誰もを待たなければならない

 

魅力的な地方のフランスのチーズショップを考えてみましょう。ここでは、顧客が自分で選択することはできません。代わりに、すべてのチーズは店主が管理するカウンターの後ろに保管されます。客はカウンターの前に並びます。ラインの先頭にいるお客は、特定の地域からの山羊チーズを探しています。店主はそのようなチーズを3つ持っていると説明しす。1つはマイルド、1つはミディアム、もう一つはシャープですが、ミディアムの者は少しソルティーです。それらのチーズの相対的なメリットを慎重に検討した後、お客は選択を行います。店主はチーズをスライスして計量し、それを紙とひもで包み、価格を計算します。お客は小銭を集めて支払い、小包を受け取り、購入に満足して去ります。ボンジュール、次のお客様どうぞ。

 

従来のフランスのチーズショップと同様に、スマートなイーサリアムのスマートコントラクトを実行するたびに、ブロックチェーン全体の進行がブロックされます。さらに悪いことに、すべてのマイナーはすべてのコントラクト呼び出しを再実行する必要があり、すべての新しいマイナーはこれまでに発生したすべてのコントラクト呼び出しを再実行する必要があります。イーサリアムの従来の「チーズショップ」アーキテクチャはスケーラビリティの問題であり、新しいブロックを生成できる速度を大幅に制限します。

 

アルゴランドのオフチェーン・コントラクトは、現代のスーパーマーケットのように構成されていることがわかります。ここでは、お客は店主に依頼することなく自分で選択を行います。お客が何を購入するかを決定すると、彼女はちょっと行列に並んでレジで支払います。さまざまな種類のヤギチーズの間で迷う優柔不断な買い物客は、他の買い物客を遅らせることはなく、お客にサービスを提供できる率を制限することもありません。

 

注：アルゴランドのオフチェーン・コントラクトを、ライトニング・ネットワークなどのレイヤー2支払いネットワークと混同しないでください。支払いネットワークは特殊化されています。それらは、ある当事者から別の当事者に支払いを送るためにのみ存在します。対照的に、アルゴランドのオフチェーン・コントラクトは、柔軟で汎用的なプログラムです。

 

アルゴランドのレイヤー1（オンチェーン）スマートコントラクト

 

アルゴランドのレイヤー1スマートコントラクトは、多くの一般的な単純なトランザクションをブロックチェーン自体で直接実行します。たとえば、アルゴランドのレイヤー1スマートコントラクトは、前述のアトミック・スワップ・トランザクションをほとんど取るに足らないものにします。レイヤー1コントラクトは、アトミック転送を提供します。これは、相互に疑わしい当事者によって承認された複数のトランザクションが単一のアトミック・ユニットとして実行されることを保証する組み込みメカニズムです。全てが成功するか、しないかのいずれかです。例では、アリスはボブへの支払いとボブの彼女への支払いの両方を含むアトミック転送を作成します。彼女は自分の支払いに署名し、ボブは自分の支払いに署名し、両方の支払いを含む二重署名されたアトミック転送がブロックチェーンに送信されます。

 

別の例として、アリスが自分のトークンを発行したいとします。各トークンは、たとえば、彼女のレストランの将来の利益の分配を表します。イーサリアムのスマートコントラクトは、独自のイーサ通貨に対する組み込みサポートを提供しますが、独自の通貨のようなトークンを作成したいクライアントは、独自のデバイスに任されます。イーサリアムのユーザー定義トークンの標準と規約は進化していますが、そのようなコードを書くことは依然としてリスクを伴う可能性があり、イーサリアムのユーザー定義トークンへの攻撃の成功には長い歴史があります。

 

対照的に、アルゴランドのスマートコントラクト・アーキテクチャは、アルゴランドのネイティブ・アルゴ通貨（ALGO）と同じレベルで、ユーザー定義のアルゴランド標準資産（ASA）の組み込みサポートを提供します。アルゴランド・ブロックチェーンは、不注意によるトークンの作成または破棄に対する組み込みの保護を提供し、オプションでトークンの凍結、クロールバック、ミント、および書き込みを直接サポートします。

 

以前の投稿で説明したように、アルゴランドのレイヤー1コントラクトは、一般的な種類の「ポスト・アンド・セール」トランザクション、証券化ローン、クラウド・ファンディング、認定のみのトランザクション、マルチシグ・ウォレット、およびその他の単純な定期トランザクションも直接サポートします。

 

レイヤー1スマートコントラクトは、アセンブリのようなスタックマシン言語であるTEALで記述されています。 TEALは、前述の一般的なトランザクションの種類を実装するための表現力をプログラマーに提供します。2020年夏までに準備されるTEALの「ステートフル」拡張がまもなく登場することで、プログラムはレイヤー1に状態を保存し、アカウントの残高やその他のブロックチェーンの状態を検査してさらに表現力を高めることができます。 TEALは、オフチェーン・コントラクトのセキュリティ保証も強化します。実際、これは、以下で説明するオフチェーン・コントラクトの強力な基盤を提供します。

 

アルゴランドの（レイヤー2）オフチェーン・コントラクト

 

多くの単純なブロックチェーン・トランザクションがレイヤー1高速パスに適していますが、より専門的なツールを必要とするアプリケーションの「ロングテール」もあります。例えば：

 

• コントラクトが大きすぎる可能性があります。たとえば、個人の株式配置を管理するコントラクトでは、参加を許可されている認定投資家のデータベースを参照する必要があるかもしれません。そして同時に参加を許可されない投資家のブラックリストも参照する必要があることでしょう。これらのデータベースは、チェーン上に維持するには大きすぎるか、公開するには機密性が高すぎる可能性があります。

• コントラクトは、計算上非常に厳しい場合があります。たとえば、高度なプライバシーを提供するトークンを管理するコントラクトでは、ZK-STARK、ZK-SNARKなどの計算集中型のライブラリが必要になる場合があります。同様に、貴重な資産を処理する複雑なコントラクトでは、データ構造の整合性をチェックするアサーションを自由に使用できます。このような長い計算は、他のクライアントによる進行を妨げ、全員のブロック率を低下させる可能性があります。

• コントラクトが複雑すぎる可能性があります。TEALは、シンプルなレイヤー1トランザクションをプログラミングするための強力で安全なツールですが、より複雑なアプリケーションには高水準の言語が必要です。多くの場合、ソフトウェア・エンジニアリングの優れた実践では、アプリケーションを複数のコントラクトに分割する必要があり、それは異なる当事者によって提供されることもあります。モジュール構造を必要とするほど複雑なアプリケーションは、高水準言語で管理するのが最適です。

 

オンチェーン対オフチェーン・コントラクト

 

アルゴランド・ブロックチェーンでは、アルゴランドの暗号化自己選択アルゴリズムによって安全かつランダムに選択されたコンセンサス・コミッティーによって新しいブロックが選択されることを思い出してください。ユーザーがオフチェーン・コントラクトを呼び出す場合、呼び出しはコンセンサス・コミッティーによって直接実行されません。代わりに、コールは、コントラクト実行委員会と呼ばれる並列のコミッティーによって実行および検証されます。そのコミッティーの各バリデーターは、コントラクト呼び出しを実行し、一連の効果（コントラクト呼び出しによって生成されたブロックチェーン・トランザクションのシーケンス）を生成します。次に、コントラクト実行コミッティーは、呼び出しの影響を承認する署名付き証明書を作成します。効果の簡単なリストは、署名された証明書およびその他の検証条件とともに、コンセンサス・コミッティーに提出されます。効率を上げるために、複数のコントラクト呼び出しをバッチで実行できるため、それらすべてを単一の証明書で保証できます。コンセンサス・コミッティーの検証者は、オンチェーン・コントラクト・アーキテクチャのように、ユーザー定義のコントラクト・コードを実行することはありません。代わりに、コンセンサス・コミッティーの検証者は、トランザクションの効果を適用する前に、証明書と検証条件を確認するだけで済みます。

 

オンチェーン・コントラクトを必要とするブロックチェーンは、すべての金融取引をレジ係の小切手で行うことを要求する銀行のようなものです。お金を使う前に、顧客は他のすべての顧客と並んで、出納係が1人だけの銀行のオフィスで、小切手の金額をエスクローするために並んで待つ必要があります。対照的に、オフチェーン・コントラクトを使用するブロックチェーンは、通常の当座預金口座を使用するようなものです。顧客は銀行で並ぶことなく独自の小切手を作成し、小切手が決済されると後で資金が送金されます。

​