Achieving Consensus on the Internet Computer 日本語訳
Medium の DFINITY 公式の記事 Achieving Consensus on the Internet Computer (2021/5/18) の日本語訳です。
ブロックチェーンの新しいコンセンサスプロトコルの非同期ファイナリティは信じられないほど速く、1秒以内に行われます。
By Manu Drijvers, Engineering Manager (Consensus) | DFINITY
世界初のウェブスピードであり、インターネットスケールのパブリックブロックチェーンである Internet Computer のビジョンには、セキュリティと信頼性が不可欠です。スマートコントラクトにより、インタラクティブなウェブコンテンツをエンドユーザーのブラウザに直接的に安全に提供することができます。Internet Computer は、パブリックインターネットの機能を拡張し、ソフトウェアをホストできるようにすることで、次世代のDappsとオープンインターネットサービスを可能にします。
世界中のデータセンターに設置されたマシンが、Internet Computer Protocol (ICP) を通じて通信することで、Internet Computer は、動作しています。このように協働することで、マシンは仮想 Internet Computer を形成し、開発者はセキュアで信頼性の高い方法でキャニスタースマートコントラクトと呼ばれるソフトウェアの断片を書いてデプロイすることができるようになるのです。”セキュア“ とは、キャニスターのステートがキャニスターのルールに従ってのみ変化し、改ざんされないことです。”信頼性 “とは、キャニスターが突然動かなくなることがないことを意味します。
Internet Computer は、今までにない新しいコンセンサスプロトコルを用いてこれらの特性を実現しています。異なるマシン または レプリカ が、一貫したステートを維持するために、どの入力をどの順番で処理するかについてコンセンサスを得る必要があります。各ソフトウェアは、1台のマシンではなく、世界中の多くのマシンによって実行され、そのマシンの大多数がソフトウェアの真のステートを定義します。個々のレプリカが改ざんされたステートを報告したり、接続に問題があったり、あるいは悪意があったりしても、大多数のレプリカがソフトウェアを正しく実行している限り、違いは生じないのです。
さらに、私たちはInternet Computerをスケールさせたいと考えています。つまり、プラットフォーム上のキャニスタースマートコントラクトという形で、より多くの分散型アプリケーションを実行できるようにしたいということです。このスケーラビリティの要件を達成するために、私たちはキャニスターをより小さなグループに分割し、各グループは私たちがサブネットと呼ぶものの上で動作します。サブネットは世界中の様々なレプリカによって運営されており、それらはすべてそのサブネット上で実行されているキャニスターを実行します。また、異なるサブネット上のキャニスターは安全に通信することもできます。 私達はいつでもサブネットを Internet Computer へ追加することができ、それによって容量を増やすことができます。
なぜコンセンサスが重要なのか
いくつものレプリカが利用できなくなる または 悪意を持つ可能性がありますが、大多数のマシンが正常に機能する限り、サブネットの正しいステートに影響を与えることはありません。このようにレプリケーション（複製）を利用してセキュリティを確保するアプローチには、コンセンサスプロトコルが必要です。サブネットは異なるメッセージ、すなわちユーザーからキャニスターへのメッセージ、キャニスターからキャニスターへのメッセージを処理しなければなりません。そして、すべてのレプリカが常に同じステートになるように、同じメッセージを同じ順序で全て処理しなければなりません。しかし、サブネットを動かす各レプリカは、実際には異なる順序でメッセージを見ることになるかもしれません。そこで、サブネットを構成するすべてのノードが、処理するメッセージの順序を合意できるよう、コンセンサスプロトコルを利用します。
（上図の文）コンセンサスの特性
（上図の文）メッセージはブロックに入れられます。ブロックチェーンを使って合意に達します。
（上図の文）n個のレプリカが一緒にサブネットを動かしていると仮定します。
（上図の文）Safety: もし2つの（正直な）レプリカが i 番目のブロックが合意されたと思うならば、彼らは同じブロックを持っているはずです。
（上図の文）Liveness:ある時点で、すべての（正直な）レプリカは、任意の i において、i 番目のブロックが合意されたと思うようになります。
（上図の文）Validity:合意したすべてのブロックは有効です
（上図の文）n個のノードのうちf個までが誤動作しても、n = 3f + 1で、このようにしたいです。
（上図の文）このスライドの例では n = 4, f = 1 としています。
ブロックチェーンを利用することでコンセンサスを得ようと思います。サブネットが処理すべきメッセージをまとめてブロックに入れて、各ブロックが前のブロックを指すことで、ブロックのチェーンが形成されます。すべてのレプリカがブロックチェーンに合意することで、実行すべきメッセージの順序が与えられ、セキュリティの特性が実現されます。
より正確には、私たちが ”safety” と呼んでいるものを求めています。つまり、2人の正直なレプリカが、ある時点までのブロックチェーンに同意していると考えるならば、実際にその時点までのブロックチェーンについて同じ見解を持っていなければならない、ということです。
第二に、ブロックチェーンが成長し続け、より多くのブロックに合意し続け、継続的に追加のメッセージを処理することを意味する “liveness” を求めています。
第三に、私たちが ”validity” と呼んでいるもの、つまり、すべてのブロックとブロック内のメッセージが実際に有効であることが求められます。例えば、ブロックに含まれるすべてのメッセージが送信者によって正しく署名されていることを保証します。
ここで難しいのは、サブネットを構成するノードの一部が故障したり、オフラインになったり、あるいは積極的に悪意を持ったりしても、これら3つの特性が維持されるようにしたいのです。より正確には、サブネット内のノードの3分の1未満がオフラインまたは悪意を持っている限り、これらの特性はすべて維持されることが望まれます。以下の例では、私達はしばしば4つのノードを使用しますが、そのうち最大 で１つまで悪意がある場合、これらの特性を満たす必要があります。Genesis では、Internet Computer は破損したレプリカを複数許容できるような より大きなサブネットを使用します。
ここでは、単一のサブネットにズームインし、コンセンサスを得るためにどのようにブロックチェーンを使用するかを見ていきますが、Internet Coputer は多くのサブネット、ひいては多くのブロックチェーンで構成されていることを覚えておくことは重要です。私たちは、ピアツーピアのゴシップネットワーク上に構築することで、私たちのコンセンサスプロトコルを提示します。私たちはしばしば、レプリカが “このメッセージを送る “と言うでしょう。これは、ゴシップネットワークを使って、サブネット上の他のレプリカとメッセージを交換することを意味します。また、メッセージの順序のみに焦点を当てます。メッセージの処理については、プロトコル以外の部分が処理します。
ここで重要なのは、私達がコンセンサスプロトコルを Internet Computer のニーズに合わせて設計することを選んだことです。スループット、レイテンシー、そしてプロトコルのシンプルさを最適化しようとしています。私達のプロトコルは下記の4つの主要なパートからなっています。
- １つ目は、ブロック作成 です。このパートでは、ブロックチェーンを組み立てるための候補となるブロックを形成します。
- 2つ目は、公証 です。このパートには、有効なブロックを識別する責務があり、そこから有効なブロックチェーンを組み立てることができます。
- 3つ目は、ランダムビーコン です。ランダムビーコンは、プロトコルをさらに強化するために利用できるランダム性を与えてくれます。
- 最後に、ファイナライゼーション ですが、これは実際に合意に至ったことを示すものです。
ブロック作成
サブネット上のレプリカはブロック作成者となり、チェーンを伸ばすためのブロックを提案できます。このサブネット上で動作するキャニスターによって処理されるべき、いくつかのメッセージを利用できるようになります。それはある高さ（例えば29）までのブロックチェーンを持つかもしれません。処理待ちのメッセージを集め、それらをブロックにまとめ、このゴシップネットワーク上で他のレプリカへ送ることでブロックチェーンを伸ばす提案をします（訳注 例えば30を提案するということ）。
（上図の文）ブロック作成者は、利用可能なメッセージを選び、それらをブロックにまとめます。
（上図の文）現在のブロックのチェーンを伸ばすために、そのブロックの提案をブロードキャストします。
（上図の文）注：各ラウンドでブロック作成者としての役割を果たすには、十分な数のレプリカが必要です。もし、1つしか選ばなかった場合、フォールトトレラントにはならないでしょう。
ここで重要なのは、一部の参加者が実際に悪さをしたとしても、このプロトコルが機能するようにしたい、ということです。つまり、ブロックチェーンを伸ばすためにある１つのブロック作成者を選ぶことはできません。この１つのブロック作成者が実際に悪意を持っている可能性があり、私たちは行き詰まってしまう可能性があり、livenessを損なうことになるためです。そのため、ブロック作成者となるレプリカを多数用意する必要があります。
公証
同じ理由で、これらのブロック提案が実は無効になるかもしれません。それに対処するために、ラウンド単位で動く公証プロセスがあり、どのラウンドでもブロックチェーンを伸ばすことができる有効なブロックが少なくとも1つあることを保証しているのです。
例として、レプリカ1が高さ29までの公証済みブロックチェーンを持っているとします。ここで、ブロックチェーンを高さ30に伸ばすブロックを見つけた場合、そのブロックを検証することになります。レプリカ1はこのブロックが有効であることを確認すると、公証シェアと呼ばれる暗号署名をこのブロックに付与するかもしれません。公証シェアは他のレプリカとサブネットに送信され、レプリカ1がこのブロックを有効だと考えていることを表明します。
（上図の文）ブロック提案は無効になる可能性があります。チェーン上の全てのブロックは公証されなければなりません。毎ラウンド、有効なブロック提案が公開されることが、公証プロセスにより保証されます。
（上図の文）Step1: レプリカ1は、ある公証された高さ29のブロックの上に、高さ30へのブロック提案を受けます。
（上図の文）Step2: レプリカ1はブロックが有効であることを確認し、署名し、その公証シェアをブロードキャストします。
（上図の文）Step3: レプリカ1は、レプリカ3と4もブロック上で公証シェアを公開したことを確認します。
（上図の文）Step4: 3つの公証シェアは十分な承認です: シェアは1つの完全な公証に集約されます。今ブロック30が公証されると、公証人は高さ31のブロックを待ちます。
もしかしたら、Replica 3とReplica 4もその同じブロックに公証シェアを作成するかもしれません。この例では、4つのうち3つが、私たちが望む最高の承認率であることに注意してください。ノートの1つが誤動作またはオフラインになったりしてもプロトコルは進行するはずです。この3つの公証を1つの生成物にまとめたものを、公証と呼び、ブロック30が公証されたことを意味します。公証人は次のラウンドに進み、高さ31のブロックの探索を開始します。
これらの公証シェアには、マルチシグネチャと呼ばれる特殊な署名を使用します。マルチシグネチャは、同じメッセージに対する多くの署名を、すべてのノードがメッセージに署名したことを証明する単一の一定サイズの署名に圧縮できるという優れた特性を持っています。つまり、非常に大きなサブネットに多くの公証人がいたとしても、公証は小さな生成物となるのです。
（上図の文）公証人は複数のブロックに公証署名するかもしれません
（上図の文）少なくとも1つのブロックが完全に公証されるように、公証人は複数のブロックに公証署名するかもしれません。
（上図の文）Step1:レプリカ1は、ある公証された高さ29のブロックの上に、高さ30のブロック提案を受け取ります。
（上図の文）Step2: レプリカ1はブロックが有効であることを確認し、署名し、その公証シェアをブロードキャストします。
（上図の文）Step3: レプリカ1は別の高さ30のブロックを見て、これも有効であるため、ここで別の公証をブロードキャストします。
（上図の文）Step4: 両方の高さ30のブロックは、公証されるのに十分な支持を得ます。
公証は、今説明したように常にうまく機能するわけではありません。レプリカは有効なブロックを見て、そのブロックに公証シェアを作成するかもしれません。しかし、同じ高さの別の候補のブロックを見せられ、それも有効である可能性があります。レプリカがどちらかのブロックにのみ署名する場合、ある公証人はあるブロックを支持し、別の公証人は別のブロックを支持し、どちらも十分な承認を得られないため、実際には行き詰まってしまうかもしれません。liveness の特性を満たすために、公証人は両方のブロックに実際に署名し、少なくともどちらかが公証されるようにします。つまり、1つの高さで複数の公証済みブロックを得てもよいのです。
ランダムビーコン
ブロック作成者と公証人は有効なブロックを識別することができますが、高さごとに複数の公証済みブロックが存在する可能性があるため、まだ合意には至りません。ということで、有効なブロックがたくさん集まったツリーのように見えるかもしれません。最終的にブロックチェーン上で合意を得るには、私たちのプロトコルにランダムビーコンというものを追加することで、毎ラウンド得られる公証済みブロックの数を減らします。すべての高さで、ランダムビーコンと呼ばれる、予測不可能な値を持つランダムな人工物を用意します。
レプリカは高さ29のランダムビーコンを持っているかもしれません。ラウンド29の公証処理が終了すると、次のランダムビーコンを作成する時が来たと判断します。このときレプリカは、前のランダムビーコンの値に対して、ランダムビーコンシェアと呼ばれる特別な署名を作成します。これもゴシップネットワークで共有するもう１つの人工物です。
（上図の文）各高さで、レプリカが共有する予測不可能なランダム値であるランダムビーコンがあります。
（上図の文）Step1：レプリカ1はランダムビーコン29を持っており、ランダムビーコン30の構築を手伝いたい。
（上図の文）Step2: レプリカ1は、閾値署名スキーマを用いてRB29に署名し、ランダムビーコン30のシェアを得る。
（上図の文）Step3: レプリカ1は、レプリカ2もランダムビーコン30のシェアを公開していることを確認します。
（上図の文）Step4: 完全な閾値署名を再構成するためには、2個のランダムビーコンシェアで十分であり、これはランダムビーコン30である。
ここで、別のランダムビーコンのシェアが得られたら、そのシェアを組み合わせて次のランダムビーコンの値を構成することができます。これは特殊な署名、すなわち閾値BLS署名を用いて行います。この署名は一意であり、どのレプリカが値を構成するのに参加しても構わないという特別な性質を持っています。しかし、レプリカが単独でその値を構築することはできないため、予測不可能でもあります。この閾値BLS署名には、当事者間で秘密鍵を共有する特殊な鍵の材料が必要であり、我々は noninteractive distributed key generation というプロトコルを用いてこれをセットアップしました。
さて、この共通のランダム性を用いて、ブロック作成者を毎ラウンドランク付けしていきます。
例えば、ラウンド23で作成したランダムビーコンを使って、ラウンド24でブロック作成者をランク付けします。ラウンド24では、レプリカ1が最優先のブロック作成者（つまりランク0のブロック作成者）であることに合意することができます。もちろん、レプリカ1がうまく機能しないかもしれないので、フォールバックを用意する必要があります。例えば、Replica 4をランク1のブロックメーカとして選び、最初のフォールバックになるかもしれません。そして、それが動作しない場合は、Replica 3をランク2のブロック作成者とします。そして最後に、Replica 2が最後の手段です。ランダムビーコンは共通のランダム性を提供するので、すべてのレプリカはブロック作成者の順序に同意します。
(上図の文)ブロック作成者ランキングによる公証
(上図の文)公証人が公証プロセスにおいてブロック作成者ランキングを利用することで、1ラウンドあたりの公証ブロック数を削減することができます。
・ラウンド開始後の時間は、タイムスロットで区切られます。
・まず、タイムスロット0において、公証人はランク0のブロック作成者からのブロック提案にのみ公証署名を行います。
・しばらくして、有効なランク0のブロック提案をまだ見ていなければ、スロット1が始まり、公証人はランク1のブロック提案に公証署名する意思はあります。さらに時間が経過すると、スロット2が始まり、より良いブロック提案が観察されない場合、公証人はランク2のブロックを受け入れることになります。
・ネットワークがうまく機能し、ランク0のブロックメーカーが有効なブロックを送り、公証人が他のブロックに公証署名する前に公証に到達すれば、その高さで唯一の公証済みブロックとなります。
(上図の左から１番目)自分がラウンドxにいることを観測し、ランク0のブロック提案を探します。
(上図の左から２番目)ランク1ブロックの公証を開始します。
(上図の左から３番目)ランク2ブロックの公証を開始します。
(上図の左から４番目)ランク3ブロックの公証を開始します。
これから、このブロック作成者ランキングを利用して、公証人の動作をさらに強化します。より正確には、公証人がラウンドに入ると、タイマーをスタートさせます。タイマーが始まると、ランク0のブロック作成者によるブロックの公証シェアを作成したいだけです。一定時間が経過して失敗した場合のみ、公証人はランク1のブロック作成者からのブロック提案にフォールバックします。さらに一定時間経過すると、ランク2またはランク3のブロック作成者にさらにフォールバックするでしょう。
公証人がブロック作成者の順位を考慮することで、毎ラウンド、公証されたブロックの数を減らすことを目的としています。例を見てみましょう。レプリカ1はラウンド30で、高さ30の有効なブロックの提案を受け取りますが、ブロック作成者はランク1しかいません。レプリカ1はまだランク1のブロックにサインする気はないので、待つことにします。うまくいけば、今度はランク0のブロック作成者からブロックの提案を受けるかもしれません。さて、公証人はランク1のブロックではなく、このブロックに対して公証シェアを作成します。もし他の公証人が十分に多く同じことをすれば、ランク0のブロックだけが完全に公証されることになります。このシナリオでは、公証されるブロックの数を実際に減らすことができました。これにより、よりコンセンサスに近づくことができます。
(上図の文)ブロックランクによる公証
(上図の文)ブロックランクを考慮することで、公証されるブロックの量を減らすことができます
(上図の文)Step 1: 公証された高さ29のブロックの上に、レプリカ1は高さ30のランク1のブロック提案を受けます。
(上図の文)Step 2:レプリカ1はまだタイムスロット0なので、ランク1の公証署名をする気はまだありません。
(上図の文)Step 3: レプリカ1は有効なランク0高さ30のブロックを確認し、公証シェアをブロードキャストします。
(上図の文)Step4: 最終的には、ランク0のブロックだけが公証されるようになります。
いくつかのラウンドで複数の公証済みブロックがあるかもしれません。しかし、ほとんどのラウンドでは、ランク0のブロック作成者からの公証済みブロックは1つだけであることが望まれます。実際、公証人が一人しかいなければ、実はすでに合意に達しているのです。なぜなら、どのラウンドでも公証済みブロックの有効なチェーンが存在しなければならず、候補のブロックが1つしかない場合、そのポイントを通過するチェーンはすべてそのブロックを通らなければならないからです。したがって、そのブロックを含んだチェーンは、実際に合意されたものでなければなりません。
Finalization
課題が残っています。合意に至ったことをどのように確認するのでしょうか？レプリカはどのようにして、そのチェーンを受け入れることができると知ることができるのでしょうか？一つの選択肢は、レプリカが単純にある時間だけ待ち、この時間の後に存在するすべての公証済みブロックを見たことになり、ある高さにおいてたった一つの公証済みブロックがあれば、その高さまでのチェーンは合意されたと見なすというものです。
しかし、これは非常に危険なアプローチです。もしかしたら、ネットワークが正常に機能しておらず、単にまだ見ていないだけで、実際には他の公証済みブロックが存在するかもしれません。つまり、十分な時間待たないと、安全性に反するかもしれません。これは非常に困難な状況に置かれています。サブネットの応答性を高めるためにブロックの合意を迅速に行いたいですが、同時に安全性を保証するために長い時間待つ必要があることも分かっています。
このトレードオフを避けるため、別のメカニズムで合意を監視します。私たちは、合意に達したことを検出するのに役立つ、別の非同期ファイナライゼーションプロセスを持っています。1つのブロックが完全に公証されたことを確認するまで、公証人が公証シェアを作成し、その時点で次のラウンドに移ることを思い出してください。今度は、何ブロック公証したかという情報を公証人が共有することで、合意形成に役立てようと思います。より正確には、公証人がそのラウンドで受け取った最初の公証ブロック以外のブロックの公証シェアを作成しなかった場合、ファイナライゼーションシェアと呼ぶ別の種類の署名を作成します。
(上図の文)ファイナライゼーション
公証人は、その高さで他のブロックに公証署名していない場合、あるブロックに ”ファイナライゼーションシェア” を作成します。
Step1:レプリカ1は高さ30でブロックbに公証署名します。
Step2: レプリカ1はブロックbが完全に公証されたことを観測し、高さ≦30のブロックには公証署名しないようにします。
Step3: レプリカ1はブロックb以外のブロックに公証署名していないので、ブロックbに署名し、bのファイナリゼーションシェアを作成します。
Step4: レプリカ2と4もブロックbにファイナライゼーションシェアをキャストします。
Step5: ファイナライゼーションシェアは十分な承認: シェアは1つの完全なファイナライゼーションに集約されます。
レプリカ1からの 高さ30のブロックに対するファイナライズシェアは、基本的にレプリカ1がこのブロック以外の高さ30のブロックに公証署名していないことを意味します。これは、残りのサブネットにゴシップする別のアーティファクトです。十分な数のレプリカが同じブロックのファイナライズシェアも作成する場合、それらを1つのファイナライゼーションに集約することができます。ブロック上でこのようなファイナライゼーションを見るたびに、その時点までのブロックチェーンを信頼できることがわかります。ファイナライゼーションは、その高さの公証済みブロックが他に存在し得ないことを証明するものだからです。ネットワークがうまく振る舞えば、これらのファイナリゼーションシェアを素早く作って合意に至ることができるので、従来のブロックチェーンに比べて、実は非常に早くブロックの合意に至ることができることを意味します。この非同期ファイナライゼーションのアプローチでは、提案されてから1秒以内にブロックをファイナライズすることができます。
さらには、ネットワーク攻撃のリスクもありません。ネットワークがうまく動作しなくても、署名にのみ依存し、すべてのメッセージを見たという仮定には依存しないので、安全であることがわかります。
(上図の文)
ファイナライゼーションセーフティ証明
高さhのブロックbの完全なファイナライゼーションは、高さ h には他の公証されたブロックが存在しないことを証明するものです。
・bの完全なファイナライゼーションには、ファイナリティ署名に3つのレプリカが必要です（構成上）
・ファイナリティ署名 b を行った3つのレプリカのうち、少なくとも2つは正直でなければならない（≦ 1 のレプリカが不正であるという仮定により）。
・ファイナリティ署名 b が b 以外の高さhのブロックに公証署名していない正直なレプリカ（構成上）。
・少なくとも2つのレプリカが、b以外の高さhのブロックに公証署名をしていない（ (2)と (3) によって）。
・完全公証には、3つの公証シェアが必要です（構造上）
・高さhブロック’b’に公証署名された可能性のある残りのレプリカ4 -2 = 2は、公証閾値3に達するには不十分です（(4)、(5)により）
想定：4つのレプリカのうち、最大1つが破損しています。
完全なファイナライゼーションとは、サブネットのノードの3分の1以下が破損している限り、他の公証済みブロックが存在できないことを意味します。4つのノードのシナリオで実際になぜそうなるのか、少し理論的に考えてみましょう。ノードが4つあるので、あるブロックでファイナライズされた場合、3つの公証人がこのブロックのファイナライゼーションシェアを作成したことを意味することがわかります。そのうち1台が破損していると仮定しても、少なくとも2台のレプリカが正直で、そのブロックでファイナライゼーションシェアを作成したことが確実に分かるということです。また、正直なレプリカは、その高さで他のブロックに署名していない場合にのみ、そのようなファイナライゼーションシェアを作成することも分かっています。
つまり、2つのレプリカは、この高さでファイナライズしたブロック以外のブロックの公証シェアを作成していないことになります。また、公証には3つの公証シェアが必要なことが分かっています。つまり、それに到達するためには3つのレプリカが参加しなければなりませんが、サブネットには4つのレプリカしかありません。さらに、そのうちの2つは間違いなく他のブロックの公証に貢献していないと言ったので、2つのレプリカだけ残っています。そして、2つではこの公証のしきい値である3つに到達するのに十分ではなく、それによって、ファイナライゼーションはその高さでは他に公証されたブロックがないことを意味するという証明を結論づけることができるのです。
これは、レプリカの3分の1以下が破損しているという前提での話です。上記のデモンストレーションでは、サブネットのサイズは4つのレプリカで、破損しているレプリカはせいぜい1つでしたが、”f “ が “n “ の3分の1以下であれば、 “n “個のレプリカのうち ”f “が破損しているというケース に同じように議論を容易に拡張できます。
まとめると、4つの要素からなるコンセンサスプロトコルがあります。ブロック作成者がブロックチェーンを伸ばすための候補ブロックを作成します。有効なブロックが特定されるように公証プロセスを設けています。そして、ブロック作成者をランク付けし、毎ラウンドで取得する公証済みブロックの数を減らすために、私達が使用するランダムビーコンを追加します。最後に、ブロックチェーンが実際に合意されたときに、ネットワーク上の仮定に全く頼ることなく知ることができる非同期ファイナライゼーションメカニズムを私達は使用します。
このコンセンサスプロトコルにより、サブネット内でレプリケーションを使用することができ、Internet Computer に求められるセキュリティと信頼性を実現することができるのです。
_____
Intenet Computer を支える技術の詳細については、今後のリリースにご期待ください。
sdk.dfinity.orgでビルドを開始し、forum.dfinity.orgで開発者コミュニティに参加しましょう。
