Connext v2.0 is on Mainnet

tl;dr: We shipped the thing! 8804>

v2.0は、人々がv1から好きなものを倍増させ、ウォレットをネイティブにサポートし、v1の痛点を軽減し、信頼性の仮定を向上させるという、素晴らしいものです。 8804>

Rinkeby テスト、監査、およびバグ修正の長い 2 か月の後、私たちは Connext の v2.0 をデプロイしました！Dai Card はここで入手できます。 🌟

• 飛び込むのに最適な場所は、私たちのドキュメントのクイックスタートガイドです。
• 何か質問があれば、私たちのディスコードに話しに来てください。 https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card は、次の場所で公開されています。 https://rinkeby.indra.connext.network

メインネット v2.0 Dai Card はどうでしょうか？ もうすぐです。

V2.0 は Counterfactual 上で実行されます。

How Does It Work?

Check out our testnet post for an overview of the tech!

Why Does V2.0 Matter?

“How can we bring 1 billion users to Ethereum?”

この質問によって、スケーラビリティ、UX、Ethereum 転送の合流点で、多くの製品イテレーションを経験することになりました。 私たちは、エンド ユーザーは、ガスに Eth を使用しているかどうか、ブロックチェーンがどれほど混雑しているか、あるいはどのサイドチェーン/プラズマチェーン/シャードにいるかにかかわらず、ウォレットおよびアプリケーションでシームレスで一貫したエクスペリエンスを求めているという仮説を立てました。

今年初めに v1 Dai Card を出荷し、次のような反応を見たとき、私たちは何か重要なことを発見したと確信しました：

v2.0 を構築するにあたり、目標はシンプルなものでした。 まず、ユーザーが Connext についてすでに気に入っていることをさらに強化することです。 これは、コネクストの統合をさらに簡素化し、デフォルトでリンクを介した簡単なオンボーディングを再実装し、最も重要なことですが、すでに魔法のような転送をさらに高速化する作業を継続することを意味します。 私たちは、ウォレットが v1 で可能になったユーザー エクスペリエンスを気に入っていることを発見し、キー管理とストレージに関して既存のウォレット開発パラダイムとよりシームレスに動作するように Connext クライアントの設計をやり直しました。 v1 では、Connext の最も困難な部分は、当然のことながら、チャネル オンチェーンへの入金とチャネルからの出金のプロセスでした。 v2.0では、入出金をシンプルにしただけでなく、ウォレットがユーザーのチャンネルのプロバイダをdAppに注入することを可能にし、ユーザーが複数のチャンネルに入金する必要性をそもそも無くしたのです。 また、v1ではプロトコルの柔軟性に欠け、ユーザーからのフィードバックに対応するのに数週間から数ヶ月かかるという大きな問題がありました。 v2.0 では、代わりに、新しいアプリケーションや機能のサポートを数日で追加できます。

第四に、より信頼できる最小限の分散型システムになるために、信頼できる意味のある進歩を遂げることです。 真の分散化はまだ少し先ですが、私たちは完全に非親告罪化することに成功し、将来あまり多くのプロトコルを変更することなく Lightning スタイルのマルチホップを実装するための基礎を築きました。 Connext の v2.0 は、コミュニティからこれまでに受け取ったすべての素晴らしいフィードバックの集大成であり、日常的に使用できる Ethereum レイヤー 2 への最初のステップでもあります。

これまでの私たちの素晴らしい旅に参加してくださった皆様に感謝します！

信頼前提

Connext の v1 で Dai Card を発売したとき、私たちのネットワークの主要な信頼前提をリストアップしました。 8804>

飛行中は、一部の支払いはカストディアン

v1では、ユーザー資金は常に非カストディアンでしたが、飛行中の転送自体はハブによって保持されていることがありました。 これは、リンク支払いやオフラインの受信者への転送など、より条件付きの転送で特に当てはまりました。

v2.0 では、すべての転送は、飛行中であっても完全に非保管されます。 ハブには、あなたの資金を盗む能力はありません。 これは、v2.0 がチャネルでの一般化された状態の更新をネイティブにサポートし、チャネルにはるかに多くの柔軟性を与えるためです。

状態の「マスター」コピーを保持するハブ、およびデフォルトで状態をバックアップしないクライアント

v1 では、オフラインになった場合、ハブが状態を保持する唯一のエンティティでした。 これは、クロス デバイスの互換性には優れていましたが、状態を正確に復元し、論争の際に正直に話すことをハブに依存することを意味します。 私たちは当初、IPFS に状態をバックアップすることでこれを解決するつもりでしたが、別の方向に進むことにしました。

v2.0 では、状態の保存とバックアップはウォレットに任されています。 ユーザーは、状態の永続的な「作業コピー」として機能するチャネルを実行するために、状態のローカル コピーを持つ必要がありますが、ウォレットはさらにリモート バックアップを作成できますし、おそらく作成する必要があります。 クライアントは、デフォルトではハブから状態を回復しませんが、エンドユーザが選択すれば、オプションでそうすることができます。 これは、ウォレットプロバイダがユーザーのための監視塔として機能することを可能にします。

更新はhttp経由で起こり、検閲可能です

v1では、ハブはRESTサーバで、クライアントはhttp POSTで更新を通信しました。 これは、物事をシンプルに保つための良い戦術でしたが、ハブが状態を更新するために不格好なリクエストベースのフローを義務付け、それらの更新を検閲できることを意味しました。

v2.0 では、NATS に移動しました – 非常に拡張性の高い、軽量でオープン ソースの p2p メッセージング システムです。 NATS は、http-request パラダイムからハブを移動させ、状態の複数の独立したコピーを持つことが可能になります。 しかし、残念ながら、正常に動作させるためには、メッセージングサーバー（現在はハブがホストしています）を実装する必要があります。 これは、P2P になったとはいえ、集中型 v2.0 ハブのメッセージは v1.

特に NATS を使用するという決定は、この問題の解決に向けた一歩となります。 NATS は、多くのメッセージング サーバーを一緒にクラスタリングすることにより、分散化された (メッシュ) メッセージングをサポートします。

転送はハブを介して行われ、検閲可能です。

V1 では、すべてのユーザーはハブのチャネルに入金し、ハブを介して互いに転送をルーティングしました (0x リレーの動作に類似しています)。 これは、ユーザー データを収集し、さまざまな異なる使用例をテストしている間に、信頼性が高く、簡単に反復できるシステムを作成するためのブートストラップ テクニックでした。 しかし、これはまた、私たちのハブが検閲されたり、DDoS 攻撃を受けたり、停止したりして、私たちの決済サービスがオフラインになることを意味します (ただし、ユーザーの資金は失われません!)。 私たちが真に分散化されたネットワークになる前に、行う必要のある作業がまだあります。 しかし、P2Pメッセージングと一般化された状態の追加は、正しい方向への大きな一歩です。 8804>

Redlock にアクセスするためのハブのインターフェイスを介したクライアントのプロキシ

ユーザー状態のストレージを分散化することにより、状態を同時に更新することに関する複雑さが導入されました。 集中型サーバーでは、並行処理は操作ごとに状態をロック/アンロックすることで処理されます。 私たちの分散パラダイムでは、Redis の分散ロックをハブに統合しました。

効率的に出荷するために、クライアントが状態をロック/アンロックするために、ハブによってホストされるプロキシ インターフェイスを構築しました。 短期から中期的には、分散ロックを使用するように Webdis を再実装または修正する予定です。

技術的詳細

契約は独立して監査されています:

• Provide Audit Report
• Decenter Audit Report

メインネット契約：

• ChallengeRegistry.sol
• ConditionalTransactionDelegateTarget.sol
• CoinBalanceRefundApp.sol
• MultiAssetMultiPartyCoinTransferInterpreter.sol
• IdentityApp.sol
• MinimumViableMultisig.Sol
• MultiPartyDelegateTarget.sol
• Co-AssetRefund.Sol
• MultiBalanceRefundApp.Sol
• ProxyFactory.sol
• SingleAssetTwoPartyCoinTransferInterpreter.sol
• TimeLockedPassThrough.sol
• TwoPartyFixedOutcomeInterpreter.sol
• TwoPartyFixedOutcomeFromVirtualAppInterpreter.Sol
• TwoPartyFixedOutcomeInterpreter.Sol

(シングルトン)sol

• SimpleTwoPartySwapApp.sol
• SimpleLinkedTransferApp.sol

契約コード：

• 対価型資金調達プロトコル契約
• 対価型裁決契約