SNARK (Succinct Non-interactive Arguments of Knowledge) は、ブロックチェーンのスケーラビリティ (L2 ロールアップなど) とプライバシーへのアプリケーションを見つける重要な暗号プリミティブです。 SNARK は、誰かが信頼できない検証者に証明できるようにします V (例: イーサリアム ブロックチェーン) 彼らがいくつかのデータ (例: 有効なトランザクションのバッチ) を知っていること。 これを証明する簡単な方法は、データを V、その有効性を直接確認できます。 SNARK は同じことを達成しますが、コストが高くなります。 V. 特に、SNARK プルーフは、データ自体を構成するナイーブ プルーフよりも短くする必要があります。 （詳しくは、私の教科書のドラフトを参照してください。 証明、議論、ゼロ知識. SNARK の概要については、Sarah Meicklejohn の プレゼンテーション a16z暗号で サマーリサーチシリーズ.)
SNARK の検証コストは変動する可能性がありますが、十分に理解されており、多くの場合非常に優れています。 例えば、 PlonK 校正費用について 290,000ガス StarkWare のプルーフには約 5 万ガスの費用がかかります。 SNARK は、ブロックチェーンの外でもさまざまな設定に適用できる可能性があります。たとえば、高速だが信頼できない サーバ & ハードウェア.
しかし、SNARK 検証は一般的に安価であるため、適用可能性の主な決定要因は SNARK 証明者のコストです。 P. この投稿では、これらのコストを見積もって、SNARK を使用するのが妥当な時期と、SNARK が将来どのように改善されるかを判断する方法について説明します。 これは動きの速い分野であり、この投稿で説明したプロジェクトのいくつかは積極的にパフォーマンスを改善していることに注意してください。
しかしその前に: SNARK の展開方法
SNARK の展開では、開発者は通常、コンピューター プログラムを作成します。 ψ データを入力として受け取る w 証明者が知っていると主張すること (w の略 目撃者)、そしてそれをチェックします w 有効です。 たとえば、ロールアップでは、プログラムはすべてのトランザクションが w デジタル署名されていること、アカウントの残高がゼロを下回らないことなどです。 プログラム ψ 次に、 SNARK フロントエンド SNARK テクノロジーの適用により適したフォーマットにコンパイルします。 この SNARK に適した形式は、 中間表現 （IR）。
通常、IR はある種の回路充足可能性インスタンスであり、これは次と同等です。 ψ。 これは、回路が C データを入力として受け取る w、および通常「非決定論的アドバイス」と呼ばれるいくつかの追加入力、および実行 ψ on w. アドバイス入力は、支援するために使用されます C ラン ψ、維持しながら C 小さな。 例えば毎回 ψ XNUMX つの数を割ります x & y、商 q および残り r へのアドバイスとして提供することができます C, C 簡単に確認できます x = qy + r. この小切手は、作るよりも安価です C 除算アルゴリズムを実行して計算する q & r ゼロから。
最後に、回路充足可能性のための SNARK が適用されます。 C。 これは SNARK バックエンド. 次のような高度に構造化されたいくつかの問題の場合 行列乗算, 畳み込み, いくつかのグラフの問題、このフロントエンド/バックエンドのパラダイムを回避し、それによって非常に高速な証明者を実現する既知の SNARK が存在します。 しかし、この投稿の焦点は、汎用 SNARK にあります。
これから見ていくように、SNARK バックエンドの証明者のコストは、 C〜の サイズ。 飼っている C 回路は計算を表現するための非常に限られた形式であるため、小さいことは困難な場合があります。 それらはで構成されています ゲート、 によって接続 ワイヤー. 各ゲート g いくつかの値が与えられ、 非常に これらの値に対する単純な関数。 結果は、から出ているワイヤを介して「下流」のゲートに供給されます。 g.
SNARK のスケーラビリティ: 実際にかかる時間は?
重要な問題は、単純に再実行する場合と比較して、SNARK 証明者にどれくらいの時間がかかるかということです。 ψ データに？ 答えは、 証明者のオーバーヘッド SNARK の 直接の証人確認. 後者の表現は、以下の単純な証明において、 P 送る w 〜へ V, V チェック wの実行による有効性 ψ その上に。
証明者のオーバーヘッドを「フロントエンドのオーバーヘッド」と「バックエンドのオーバーヘッド」に分けると役に立ちます。 回路を評価する場合 C ゲートバイゲートは F ランニングの何倍もお金がかかる ψの場合、フロントエンドのオーバーヘッドは F. バックエンド証明を適用する場合 C is B 評価より何倍も高い C バックエンドのオーバーヘッドは B. 証明者の総オーバーヘッドは、 製品、 F·B. この乗算オーバーヘッドは、たとえ F & B 一人一人控えめです。
実際には、 F & B どちらもおおよそ 1000 以上になる可能性があります。 これは、直接の証人チェックに関連する証明者の総オーバーヘッドが 1 万から 10 万またはそれ以上になる可能性があることを意味します。 ラップトップでわずか XNUMX 秒間実行されるプログラムは、数十日または数百日の計算時間 (シングルスレッド) を必要とする SNARK 証明器に簡単につながる可能性があります。 幸いなことに、この作業は通常、さまざまな範囲で並列化できます (SNARK によって異なります)。
要約すると、今日のアプリケーションで SNARK を使用する場合は、次の XNUMX つのいずれかが満たされている必要があります。
- ラップトップでは、直接の証人チェックにかかる時間は XNUMX 秒未満です。
- 直接の証人チェックは、回線での表現に特に適しているため、フロントエンドのオーバーヘッドは小さくなります。
- SNARK 証明器が完了するまで数日待つか、膨大な並列計算リソースに料金を支払うか、またはそのいずれかを受け入れます。
Tこの投稿の残りの部分では、フロントエンドとバックエンドのオーバーヘッドがどこから発生するか、およびさまざまな SNARK でそれらをどのように見積もるかについて説明します。 次に、改善の見通しに目を向けます。
フロントエンドとバックエンドの分離
フロントエンドをバックエンドから完全に分離することは、バックエンドが異なればサポートされる回線の種類も異なるため、困難な場合があります。 したがって、フロントエンドは、インターフェースするバックエンドによって異なる場合があります。
SNARK バックエンドは一般に、いわゆる算術回路をサポートします。つまり、回路への入力は有限体の要素であり、回路のゲートは XNUMX つの体要素の加算と乗算を実行します。 これらの回路は、本質的に代数的である直線的なコンピューター プログラム (分岐や条件ステートメントなどがない) にほぼ対応します。つまり、それらのプリミティブ データ型は体元です。
ほとんどのバックエンドは実際には、Rank-1 Constraint Satisfaction (R1CS) インスタンスと呼ばれることが多い算術回路の一般化をサポートしています。 顕著な例外を除いて グロス16 およびその前身であるこれらの SNARK は、他の IR もサポートするように作成できます。 たとえば、StarkWare は代数中間表現 (AIR) と呼ばれるものを使用します。 PlonKish 算術演算 PlonK やその他のバックエンドでサポートできます。 より一般的な IR をサポートする一部のバックエンドの機能により、それらの IR を生成するフロントエンドのオーバーヘッドを削減できます。
バックエンドは、ネイティブにサポートする有限フィールドに関しても異なります。 これについては、次のセクションで詳しく説明します。
フロントエンドへのさまざまなアプローチ
一部の (非常に特殊な) コンピュータ プログラムは、自然に算術回路に対応します。 XNUMX つの例は、ある体に対して単純な行列の乗算を実行するコンピューター プログラムです。 しかし、ほとんどのコンピューター プログラムは直線的でも代数的でもありません。 多くの場合、条件付きステートメント、整数除算や浮動小数点演算など、有限体演算に自然に対応しない演算などが含まれます。 このような場合、フロントエンドのオーバーヘッドは相当なものになります。
一般的なフロントエンド アプローチの XNUMX つは、仮想マシン (VM) とも呼ばれる単純な CPU を基本的に段階的に実行する回路を作成することです。 フロントエンドの設計者は、実際のコンピュータ プロセッサのアセンブリ命令に類似した一連の「プリミティブ オペレーション」を指定します。 フロントエンドを使用したい開発者は、アセンブリ言語で直接「監視プログラム」を作成するか、Solidity などの高水準言語で作成し、プログラムをアセンブリ コードに自動的にコンパイルします。
たとえば、StarkWare の カイロ 非常に制限されたアセンブリ言語であり、アセンブリ命令は大まかに言って、有限体に対する加算と乗算、関数呼び出し、および不変 (つまり、一度だけ書き込み) メモリへの読み取りと書き込みを許可します。 Cairo VM は von Neumann アーキテクチャです。つまり、フロントエンドによって生成された回路は、基本的に Cairo プログラムを公開入力として受け取り、そのプログラムを「実行」します。 Cairo 言語はチューリング完全です。限られた命令セットにもかかわらず、より標準的なアーキテクチャをシミュレートできますが、そうすると費用がかかる場合があります。 Cairo フロントエンドは Cairo プログラムを実行させます T 「学位」と呼ばれるものへの原始的な指示2 との空気 T 行と約 50 列。 何 まさにこれが意味する この投稿では重要ではありませんが、SNARK の証明者に関する限り、これは、それぞれに 50 から 100 のゲートを持つ回路に相当します。 T カイロCPUのステップ。
RISCゼロ Cairo と同様のアプローチを取りますが、仮想マシンはいわゆる RISC-Vアーキテクチャは、人気が高まっている豊富なソフトウェア エコシステムを備えたオープンソース アーキテクチャです。 非常に単純な命令セットとして、それをサポートする効率的な SNARK フロントエンドを設計することは、(少なくとも x86 や ARM などの複雑なアーキテクチャに比べて) 比較的扱いやすいかもしれません。 XNUMX月現在、RISC Zero プログラムを回しています 実行 T 次数-5 AIR へのプリミティブ RISC-V 命令 3T 行と 160 列。 これは、少なくとも 500 RISC-V CPU のステップあたりのゲート。 近い将来、さらなる改善が期待されます。
さまざまな zkEVM プロジェクト (zkSync 2.0、Scroll、Polygon の zkEVM など) は、仮想マシンを (当然のことながら) イーサリアム仮想マシンと見なします。 すべての EVM 命令を同等の「ガジェット」 (つまり、命令を実装する最適化された回路) に変換するプロセスは、より単純な Cairo および RISC-V アーキテクチャの場合よりもはるかに複雑です。 この理由およびその他の理由により, zkEVM プロジェクトの一部 EVM命令セットを直接実装するのではなく、高レベルのSolidityプログラムを他のアセンブリ言語にコンパイルしてから回路に変換します. これらのプロジェクトのパフォーマンス結果は保留中です。
RISC-V や Cairo などの「CPU エミュレーター」プロジェクトは、関連するアセンブリ言語ですべてのプログラムを処理できる単一の回路を生成します。 代替アプローチは「ASIC のようなもの」であり、プログラムごとに異なる回路を生成します。 この ASIC のようなアプローチは、特にプログラムが各タイムステップで実行するアセンブリ命令がプログラムの入力に依存しない場合に、一部のプログラムに対してより小さな回路を生成できます。 たとえば、単純な行列乗算などの直線的なプログラムの場合、フロントエンドのオーバーヘッドを完全に回避できる可能性があります。 しかし、ASIC アプローチも非常に制限されているようです。 私の知る限り、事前に決められた反復境界なしでループをサポートするためにそれを使用する方法はわかりません。
フロントエンド オーバーヘッドの最後の要素は、すべての SNARK が有限フィールド上で動作する回路を使用するという事実に由来します。 ラップトップの CPU は、XNUMX つのマシン命令で XNUMX つの整数を乗算または加算できます。 フロントエンドが十分に大きな特性のフィールドで回路を出力する場合、対応するフィールド操作を介してその乗算または加算を本質的にシミュレートできます。 ただし、実際の CPU でフィールド操作を実装するには、通常、多くのマシン命令が必要になります (ただし、最新のプロセッサの中には、特定のフィールドをネイティブでサポートしているものもあります)。
一部の SNARK バックエンドでは、他のものよりも柔軟なフィールド選択が可能です。 たとえば、バックエンドが暗号化グループを利用する場合 G、回路のフィールドは要素の数と一致する必要があります G、制限することができます。 さらに、すべてのフィールドが実用的な FFT アルゴリズムをサポートしているわけではありません。
実装されている SNARK は XNUMX つだけです。 ブレーキダウン、任意の (十分な大きさの) フィールドに対する計算をネイティブにサポートします。 それに伴い 子孫、他の SNARK がサポートする分野でさえ、既知の最速の具体的な証明者のパフォーマンスを持っていますが、その証明は現在、多くのブロックチェーン アプリケーションには大きすぎます。 最近の作品 証明サイズを改善しようとしますが、証明者は漸近的に遅くなり、 そう見える 障壁 実用性に。
一部のプロジェクトでは、特に高速な演算でフィールドを処理することを選択しました。 例えば、 ポンキー2 その他は特性 2 のフィールドを使用します64 - 232 + 1 は、このフィールドの演算は、構造化されていないフィールドよりも数倍高速に実装できるためです。ただし、このような小さな特性を使用すると、フィールド演算による整数演算を効率的に表現する際に課題が生じる可能性があります (たとえば、32 つの XNUMX ビット符号なし整数を乗算するとフィールド特性より大きな結果が得られる可能性があります)。
しかし、いずれにしても、現在普及しているすべての SNARK が 128 ビットのセキュリティを達成するには (検証コストを大幅に増加させることなく)、2 より大きいサイズのフィールドで動作する必要があります。128. 私が知る限り、これは各フィールド演算で少なくとも約 64 回の XNUMX ビット機械乗算と、さらに多くの加算とビット演算が必要になることを意味します。 したがって、有限フィールド上で動作する回路が必要なため、少なくとも XNUMX 桁のフロントエンド オーバーヘッドを考慮に入れる必要があります。
要約すると、仮想マシンの抽象化を使用する既存のフロントエンドは、仮想マシンのステップごとに 100 倍から 1000 倍のゲートを持つ回路を生成し、より複雑な仮想マシンではそれ以上になる可能性があります。 その上、有限体演算は、最新のプロセッサの類似の命令よりも少なくとも 10 倍遅くなります (プロセッサに特定のフィールドのサポートが組み込まれている場合は例外となる可能性があります)。 「ASIC フロントエンド アプローチ」は、これらのオーバーヘッドの一部を削減する可能性がありますが、現在、サポートできるプログラムの種類が限られています。
バックエンドのボトルネックは何ですか?
回路充足可能性のための SNARK は、通常、「多項式 IOP」と呼ばれる暗号化プロトコルで多項式コミットメントスキーム」 ほとんどの場合、証明者の具体的なボトルネックは多項式コミットメント スキームです。 特に、これらの SNARK では、次数が (少なくとも) |C|、回路内のゲート数 C.
次に、多項式コミットメント スキーム内の具体的なボトルネックは、使用されるスキームと回路サイズに依存します。 ただし、常に次の XNUMX つの操作のいずれかになります: FFT の計算、暗号グループでの累乗、または マークルハッシュ. マークルハッシュは通常、回路が小さい場合にのみボトルネックになるため、これ以上説明しません。
離散対数に基づく多項式コミットメント
暗号群における離散対数問題の難しさに基づく多項式コミットメント G (KZG, 防弾, ドーリー, Hyrax コミット）、証明者は計算する必要があります ペダーセンのベクトルコミットメント 多項式の係数に。 これには、多項式の次数に等しいサイズの複数べき乗が含まれます。 SNARK では、この程度は通常サイズです。 |C| 回路の C.
素朴に行われた、サイズの複数べき乗 |C| 約1.5が必要です·|C|·ログ |G| ≈ 400·|C| グループ操作、ここで |G| グループ内の要素の数を示します G. ただし、ピッペンジャーのアルゴリズムと呼ばれるアプローチがあり、これをおおよそ対数の係数で減らすことができます |C|. 大規模な回路の場合 (たとえば、 |C| | ≥ 225)、このログ |C| factor は具体的には 25 以上になる可能性があります。つまり、大規模な回路の場合、Pedersen ベクトル コミットメントは 10 強で計算できると予想されます。·|C| グループ操作。 各グループ操作は、(非常に大まかな球場として) 有限フィールド操作よりも約 10 倍遅くなる傾向があります。 これらの多項式コミットメントを使用する SNARK は、 P 約100として·|C| フィールド操作。
残念ながら、既存の SNARK には、上記の 100 倍の係数に加えて追加のオーバーヘッドがあります。 例えば：
- スパルタのHyrax 多項式コミットメントを使用する の証明者は、次のことを行う必要があります。 |C|½ それぞれのサイズの多数の累乗 |C|½、ピッペンジャーのアルゴリズムによるスピードアップを約 XNUMX 倍弱めます。
- In グロス16, P ペアリングに適したグループで動作する必要があります。その操作は通常、ペアリングに適していないグループよりも少なくとも 2 倍遅くなります。 P また、3 回ではなく 1 回の複数べき乗を実行する必要があります。これらを組み合わせると、6 に比べて少なくとも 100 倍の速度低下が発生します。·|C| 上で見積もります。
- マーリン & PlonK また、ペアリングが必要であり、それらの証明者は 3 つをはるかに超える多項式にコミットする必要があります。
- を使用するすべての SNARK の場合 防弾 （例えば、 Halo2、これはおおよそ PlonK ですが、KZG 多項式コミットメントではなく Bulletproofs を使用しています)、証明者はコミットメントスキームの「開始」フェーズ中に対数的に多くの多重累乗を計算する必要があり、これにより Pippenger の高速化が大幅に消去されます。
要約すると、Pedersen ベクトル コミットメントを使用する既知の SNARK には、少なくとも 200 倍、最大で 1000 倍以上のバックエンド オーバーヘッドがあるようです。
その他の多項式コミットメント
他の多項式コミットメントを使用する SNARK の場合 ( FREE & リゲロコミット)、ボトルネックは、証明者が大きな FFT を実行する必要があることです。 たとえば、カイロによって作成された次数 2 の AIR (51 列と T 行、Cairo CPU のステップごとに 2 つ)、StarkWare の展開された証明者は列ごとに少なくとも XNUMX つの FFT を実行します。 16、XNUMX・T & 32、XNUMX・T。 定数 16 & 32 StarkWare によって設定された FRI の内部パラメーターに依存し、削減することができますが、検証コストが増加します。
楽観的に言えば、長さ 32 の FFT·T 約64かかります·T·log（32T) 体の乗算。 これは、比較的小さな値の場合でも、 T （例えば、 T ≥ 220)、列ごとのフィールド操作の数は少なくとも 64 です。·25·T= 1600·T. したがって、バックエンドのオーバーヘッドは少なくとも数千のようです。 さらに、大規模な FFT では、フィールド操作よりもメモリ帯域幅がボトルネックになる可能性があります。
状況によっては、大規模な FFT を実行する SNARK のバックエンド オーバーヘッドは、プルーフ アグリゲーションと呼ばれる手法で軽減できます。 ロールアップの場合、これは次のことを意味します。 P (ロールアップ サービス) トランザクションの大きなバッチを、たとえば 10 個の小さなバッチに分割します。 小ロットごとに i, P SNARKプルーフを生成する πi バッチの有効性。 しかし P これらのプルーフを Ethereum に投稿しません。これは、ガス コストが 10 倍近く増加することにつながるからです。 代わりに、SNARK が再び適用され、今回は証明が作成されます。 π それを確立する P 知っている π1 、…、π10. つまり証人は P 知っていると主張するのは XNUMX の証明 π です1、…、π10、および直接の証人チェックは、各プルーフに SNARK 検証手順を適用します。 このたったひとつの証拠 π イーサリアムに投稿されます。
FRI や Ligero-commit などの多項式コミットメントでは、 P 時間と V 内部パラメーターは、一方を他方と交換できるノブとして機能します。 以来 π1 、…、π10 イーサリアムに投稿されていないため、ノブを調整できるため、これらの証明 は大きく、それらの生成はより高速です。 SNARK の最終的なアプリケーションでのみ、集約する π1 、…、π10 一つの証明に π, 小さな証拠を確保するためにコミットメントスキームを構成する必要がありますか？
StarkWare はプルーフ アグリゲーションの展開を計画しています 差し迫って. これは、次のようなプロジェクトの焦点でもあります。 ポンキー2.
SNARK のスケーラビリティに対するその他のボトルネックは何ですか?
この投稿は証明者に焦点を当てています 時間、しかし他の証明者コストもスケーラビリティのボトルネックになる可能性があります。 たとえば、多くの SNARK バックエンドでは、証明者は各ゲートのいくつかのフィールド要素を C、そしてこのスペースコストは莫大になる可能性があります。 たとえば、プログラム ψ ラップトップで XNUMX 秒間実行すると、最新のプロセッサでおそらく XNUMX 億のプリミティブ操作を実行できます。 これまで見てきたように、一般的には C このような操作ごとに 100 をはるかに超えるゲートが必要です。 これは 100 億ゲートを意味し、SNARK によっては、数十または数百テラバイトのスペースを意味する可能性があります。 P.
別の例: 多くの人気のある SNARK (例: PlonK, マーリン, グロス16) 構造化された「証明鍵」を生成するために、複雑な「信頼できる設定式」が必要です。 これは証明者によって保存されなければなりません。 私の知る限り、 そのような最大の儀式 約 2 の回路をサポートできる証明キーを生成しました28≈250億XNUMX万ゲート。 証明鍵のサイズは数十ギガバイトです。
証明の集約が可能なコンテキストでは、これらのボトルネックを大幅に軽減できます。
今後の見通し: よりスケーラブルな SNARK の見通し
フロントエンドとバックエンドの両方のオーバーヘッドは、XNUMX 桁以上になる可能性があります。 近い将来、これらが大幅に減少すると期待できますか?
ある程度まではそうすると思います。 まず、現在最速のバックエンド (例: スパルタの & ブレーキダウン、およびその他の SNARK を組み合わせた サムチェックプロトコル 多項式コミットメントを使用する場合) には大きな証明 (通常は回路のサイズの平方根) があるため、人々は実際にはそれらを使用していません。 近い将来、小さな証明の SNARK を使用した深さ XNUMX の構成によって、証明のサイズと検証者の時間が大幅に短縮されると期待しています。 証明集約と同様に、これは証明者が最初に SNARK 証明を生成することを意味します。 π 「高速証明者、大規模証明」SNARK を使用するが、送信しない π 〜へ V。 むしろ、 P 小さな証明SNARKを使用して証明を生成します π' それが知っていること π, 送信します π' 〜へ V. これにより、現在普及している SNARK のバックエンド オーバーヘッドが大幅に削減される可能性があります。
次に、ハードウェア アクセラレーションが役立ちます。 非常に大まかな一般的なルールは、GPU は CPU の 10 倍のスピードアップを購入でき、ASIC は GPU の 10 倍のスピードアップを購入できるというものです。 ただ、この点に関してはXNUMXつの懸念があります。 第 XNUMX に、大規模な FFT は、フィールド操作ではなくメモリ帯域幅によってボトルネックになる可能性があるため、そのような FFT を実行する SNARK は、専用のハードウェアからの限られた速度向上しか見られない可能性があります。 第 XNUMX に、この記事では多項式コミットメントのボトルネックに焦点を当てましたが、多くの SNARK では、証明者が他の操作を実行する必要がありますが、コストはわずかに低くなります。 したがって、多項式コミットメントのボトルネックを解消します (例: 多重累乗の高速化 離散ログベースの SNARK では) 古いものよりもはるかに優れていない新しいボトルネック操作が残る可能性があります。 (たとえば、Groth16、Marlin、および PlonK を含む SNARK では、多重累乗に加えて、証明者が FFT を実行します。) 最後に、最も効率的な SNARK につながるフィールドと楕円曲線は、しばらくの間進化し続ける可能性があり、ASIC ベースの証明者の高速化に課題をもたらす可能性があります。
フロントエンド側では、Cairo、RISC Zero、zkEVMs などのプロジェクトの「CPU エミュレーター」アプローチが、CPU 命令セットの複雑さに応じて (パフォーマンスの点で) 実際に非常にうまくスケーリングすることがますますわかるかもしれません。 実際、これはまさにさまざまな zkEVM プロジェクトの希望です。 これは、フロントエンドのオーバーヘッドが XNUMX 桁以上にとどまる一方で、フロントエンドが実際の CPU アーキテクチャにますます一致する VM をサポートできることを意味する可能性があります。 相殺される懸念は、ますます複雑な命令を実装するハンドコーディングされたガジェットが急増するにつれて、フロントエンドが複雑になり、監査が困難になる可能性があることです。 正式な検証方法は、この懸念に対処する上で重要な役割を果たす可能性があります。
最後に、少なくともブロックチェーン アプリケーションでは、実際に出回っているスマート コントラクトのほとんどが、主にシンプルで SNARK に適した命令を使用していることに気付くかもしれません。 これにより、Solidity などの高レベル プログラミング言語や EVM などの豊富な命令セットのサポートに伴う汎用性と開発者エクスペリエンスの向上を維持しながら、実際にはフロントエンド オーバーヘッドを低く抑えることができます。
***
ジャスティン・セイラー is ジョージタウン大学准教授。 ジョージタウン大学に入社する前は、ニューヨークの Yahoo Labs で XNUMX 年間研究科学者として働いていました。 シモンズ コンピューティング理論研究所 UCバークレーで。
***
謝辞: 感謝します エレナバーガー この投稿のトピックを提案するため、および アラス・アルン、 ジョセフ・ボノー, サム・ラグスデール 洞察力のあるコメントのために。 編集者にも感謝します。 ティム·サリバン.
***
ここに示されている見解は、引用された個々のAH Capital Management、LLC（「a16z」）の担当者の見解であり、a16zまたはその関連会社の見解ではありません。 ここに含まれる特定の情報は、a16zが管理するファンドのポートフォリオ企業を含むサードパーティの情報源から入手したものです。 a16zは、信頼できると思われる情報源から取得したものですが、そのような情報を独自に検証しておらず、情報の永続的な正確性や特定の状況に対するその適切性について表明していません。 さらに、このコンテンツにはサードパーティの広告が含まれる場合があります。 a16zはそのような広告をレビューしておらず、そこに含まれる広告コンテンツを推奨していません。
このコンテンツは情報提供のみを目的として提供されており、法律、ビジネス、投資、または税務に関するアドバイスとして信頼されるべきではありません。 これらの問題については、ご自身のアドバイザーにご相談ください。 証券またはデジタル資産への言及は、説明のみを目的としたものであり、投資の推奨または投資顧問サービスの提供を構成するものではありません。 さらに、このコンテンツは、投資家または将来の投資家による使用を目的としたものではなく、a16zが管理するファンドへの投資を決定する際にいかなる状況においても信頼されない場合があります。 （a16zファンドへの投資の申し出は、私募覚書、サブスクリプション契約、およびそのようなファンドの他の関連文書によってのみ行われ、その全体を読む必要があります。）言及、参照、または記載されているのは、a16zが管理する車両へのすべての投資を代表するものではなく、投資が有益である、または将来行われる他の投資が同様の特性または結果をもたらすという保証はありません。 アンドリーセンホロウィッツが管理するファンドが行った投資のリスト（発行者がa16zに公開を許可していない投資、および公開されているデジタル資産への未発表の投資を除く）は、https：//a16z.com/investmentsで入手できます。 /。
記載されているチャートおよびグラフは、情報提供のみを目的としており、投資を決定する際に信頼することはできません。 過去の実績は将来の結果を示すものではありません。 内容は、示された日付の時点でのみ話されています。 これらの資料に記載されている予測、推定、予測、目標、見通し、および/または意見は、予告なしに変更される場合があり、他の人が表明した意見と異なる場合があります。 その他の重要な情報については、https：//a16z.com/disclosuresを参照してください。
